Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

March 2019

1 participants
62 discussions

ffmpeg-devel.log.20190330
by burek 31 Mar '19

31 Mar '19

[07:42:36 CET] <cone-130> ffmpeg 03Gyan Doshi 07master:5282cbae61cc: doc/filters: mention input requirements for ebur128 [16:56:01 CET] <philipl> BtbN: https://github.com/philipl/FFmpeg/commit/c0b6e4cb6d6d41dbf2684891ed9dd43d9d… [16:56:12 CET] <philipl> Removing an unnecessary stream sync [16:57:31 CET] <BtbN> Is it really unnecessary? There's also a few calls in cuvid, in the copy path, which I'm not sure if they are needed. [17:08:47 CET] <philipl> BtbN: well, none of the other cuda filters sync and kernels are inherently asynchronous [17:09:17 CET] <philipl> In practice, the next stage either doesn't care or syncs implicitly by not using async calls [17:09:36 CET] <philipl> Until you reach the encoder [17:10:07 CET] <philipl> It's also true that the copy out of cuvid is synced when it might not need to be. [17:22:55 CET] <BtbN> patch looks good to go though! [17:24:05 CET] <philipl> BtbN: thanks [17:25:47 CET] <cone-543> ffmpeg 03Philip Langdale 07master:c0b6e4cb6d6d: avfilter/vf_yadif_cuda: Remove unnecessary stream synchronisation [18:34:04 CET] <philipl> BtbN: so yeah, I don't think we need to the sync in cuvid - it's safe for a filter or nvenc to pick up the frame without the sync. And I see a 33% speedup in a dvd encoding pipeline (with yadif_cuda). [18:34:17 CET] <philipl> I also think the sync when doing hwupload is also unnecessary. [18:34:32 CET] <philipl> The one for download is surely necessary or the host will read incomplete data. [18:35:06 CET] <BtbN> Yeah, download to software is the only path where I'm sure it's neccesary. [18:35:25 CET] <philipl> Will have changes shortly [18:57:13 CET] <philipl> BtbN: not shortly. Have to run out for a bit. Will push changes later. [21:11:08 CET] <cone-543> ffmpeg 03Philip Langdale 07master:5d90d1e36ef3: avcodec/cuviddec: Remove unnecessary stream synchronisation [21:11:09 CET] <cone-543> ffmpeg 03Philip Langdale 07master:52d8f35b14bc: avutil/hcontext_cuda: Remove unnecessary stream synchronisation [00:00:00 CET] --- Sun Mar 31 2019

1 0

ffmpeg.log.20190330
by burek 31 Mar '19

31 Mar '19

[00:00:39 CET] <kevinnn> BtbN: okay let me see if I can tweak it to do that [00:01:08 CET] <BtbN> There could also be a network send queue at some point. Or the encoder could be going slow [00:01:14 CET] <BtbN> real-time encoding is insanely complex [00:01:20 CET] <BtbN> or streaming, rather [02:20:55 CET] <HickHoward> uhh [02:20:58 CET] <HickHoward> you guys awake? [02:21:40 CET] <DHE> no, sleeptyping [02:22:51 CET] <HickHoward> whatever [02:22:52 CET] <HickHoward> so [02:22:55 CET] <HickHoward> i've made this thing [02:23:12 CET] <HickHoward> https://ghostbin.com/paste/aehkn [02:23:56 CET] <HickHoward> it's a WIP .bms script based on both m35's amazing work at documenting the STR format and some exe from a game i loaded up using Cutter, a radare2 gui program [02:39:05 CET] <kevinnn> Can anyone tell me why tuning b_vfr_input is crashing my encoding program? [02:43:40 CET] <kevinnn> I am sending raw annexb [02:43:46 CET] <kevinnn> as well, don't know if that effects things [02:56:34 CET] <kepstin> kevinnn: probably a good idea to check with a debugger if you're actually getting a crash. but if you have b_vfr_input=1 set, then you should be providing a timebase and pts values, so make sure you're doing that. [02:57:55 CET] <kevinnn> kepstin: hmm, timebase and pts? can you provide an example? [02:58:48 CET] <faLUCE> do you know if opus decoder produces interleaved or non-interleaved audio frames? [02:59:42 CET] <kepstin> which opus decoder? [03:01:00 CET] <kepstin> and i assume you mean samples, not frames [03:01:26 CET] <kepstin> you can tell the the sample format in ffmpeg, there's different types for interleaved vs planar [03:01:27 CET] <faLUCE> kepstin: yes, frames with interleaved samples [03:01:37 CET] <kepstin> e.g. 'flt' is interleaved, 'fltp' is planar [03:01:57 CET] <kevinnn> kepstin: what is i_timebase_num equivalent to? [03:01:57 CET] <kepstin> i assume there's some way to programmatically see the number of planes and whatnot [03:02:20 CET] <kepstin> kevinnn: that's the numerator of the timebase, which is a rational number. [03:02:43 CET] <kevinnn> kepstin: rational number that represents what? [03:02:55 CET] <faLUCE> kepstin: so, it produces interleaved or non-interleaved depending on the content of the opus packets? [03:03:09 CET] <kepstin> faLUCE: no, opus codec itself has no concept of anything like that [03:03:35 CET] <kepstin> whether you get interleaved or non-interleaved depends on the implementation of the decoder, they'll do whichever they think is more efficient [03:03:57 CET] <faLUCE> kepstin: I wonder if there's some constraint for opus dec [03:03:57 CET] <kepstin> i think the libopus decoder will give you back interleaved samples, I dunno about ffmpeg's internal decoder. [03:04:13 CET] <faLUCE> sorry: [03:04:28 CET] <faLUCE> I wonder if there's some constraint for ffmpeg's internal dec [03:04:34 CET] <kepstin> strangely, "ffmpeg -h decoder=opus" doesn't print the supported sample formats [03:05:40 CET] <kepstin> looks like ffmpeg's internal decoder is hardcoded to give you fltp [03:05:55 CET] <kepstin> ... which it sets on the avctx, so you already knew that [03:06:23 CET] <faLUCE> [03:05] <kepstin> looks like ffmpeg's internal decoder is hardcoded to give you fltp <--- non interleaved then [03:06:37 CET] <faLUCE> so I just found a bug for gstreamer's wrap [03:06:51 CET] <kepstin> yeah. but don't hardcode that assumption - check the sample format on the frames you get from the decoder, and behave appropriately [03:07:09 CET] <faLUCE> kepstin: unfortunately I'm using the gstreamer's wrap [03:07:30 CET] <faLUCE> it claims to output both interleaved and non interleaved, but this is a bug due to what you just noted [03:07:48 CET] <kepstin> why would you be using gstreamer's ffmpeg wrapper to decode opus rather than gstreamer's libopus wrapper? [03:08:12 CET] <faLUCE> kepstin: is opusdec the libopus wrapper? [03:08:18 CET] <kepstin> yes [03:08:24 CET] <faLUCE> it doesn't work for realtime [03:08:27 CET] <faLUCE> high latency [03:08:53 CET] <kepstin> well, that's a bug. it really should work fine for realtime, they're promoting gstreamer for webrtc and whatnot [03:09:43 CET] <faLUCE> so, the only solution for realtime is to use the libav wrapper [03:09:53 CET] <faLUCE> but it requires a conversion [03:10:03 CET] <faLUCE> from non-interleaved to interleaved [03:10:14 CET] <kepstin> i hope you're helping the gstreamer folks out by reporting these issue to them, instead of to ffmpeg folks when this has nothing to do with us [03:10:19 CET] <faLUCE> so the pipe is opusdec ! audioconvert ! audiosink [03:10:26 CET] <faLUCE> yes, I'll talk to them tomorrow, [03:10:30 CET] <faLUCE> now the channel is idel [03:10:31 CET] <kepstin> opusdec isn't ffmpeg [03:10:43 CET] <faLUCE> so the pipe is avdec_opus ! audioconvert ! audiosink [03:10:58 CET] <faLUCE> with opusdec I don't need audioconvert, but it's buggy for realtime [03:12:48 CET] <kepstin> so.. what's your problem? [03:13:45 CET] <faLUCE> my problem is that I don't want to make a conversion [03:14:16 CET] <kepstin> it looks like avdec_opus is correctly outputting planar audio (although gst-inspect says it outputs interlaced, but when it runs it correctly identifies what the decoder is giving it.) [03:14:33 CET] <kepstin> so if you want to send that to something that needs interleaved audio, you need an audioconvert [03:15:11 CET] <kepstin> general best practice with gstreamer is to stick audioconverts around here and there where you might need conversions, iirc it's basically a no-op if it doesn't need to do anything [03:15:46 CET] <kepstin> ffmpeg's filter chain automatically inserts conversions where needed by default, using aresample (which more or less does the same thing as gstreamer's audioconvert) [03:16:15 CET] <faLUCE> kepstin: the problem is that gst-inspect avdec_opus claims to produce both non-interleaved and interleaved [03:16:27 CET] <faLUCE> which is not true [03:16:37 CET] <kepstin> faLUCE: at runtime it'll correctly negotiate non-interleaved. [03:16:57 CET] <faLUCE> kepstin: this doesn't mean that gst-inspect has not a bug [03:17:18 CET] <kepstin> the ffmpeg codec wrappers in gstreamer are generic - it's a single C file used to wrap all the audio codecs. [03:17:18 CET] <faLUCE> if I gst-inspect and see both caps, then I expect to use both [03:17:55 CET] <faLUCE> kepstin: yes, but in this case, caps are not correctly set for avdec_h264 [03:18:06 CET] <faLUCE> so, it would trivial to fix it [03:18:10 CET] <kepstin> gstreamer is very heavily built around runtime negotiation for stuff like this, since in many cases stuff like formats can't be fully identified until the decoder's acutally running [03:18:32 CET] <faLUCE> kepstin: please... gst-launch doesn't have to output both caps. That's all [03:18:45 CET] <faLUCE> gst-inspect [03:18:48 CET] <kepstin> avdec_h264 says it supports I420 and RGB and Y444 [03:18:51 CET] <faLUCE> (not gst-launch) [03:18:59 CET] <kepstin> but which one you get at runtime depends on the media you're decoding [03:19:06 CET] <kepstin> it doesn't use whichever one you request [03:19:15 CET] <faLUCE> kepstin: of course [03:19:18 CET] <kepstin> it's the exact same thing. [03:19:21 CET] <faLUCE> read agai what I wrote [03:19:24 CET] <kepstin> (well, almost) [03:19:24 CET] <faLUCE> no, it's not [03:19:57 CET] <faLUCE> gst-inspect doesn't have to output both caps. That's all [03:20:11 CET] <kepstin> but if it doesn't output both, what should it say? none? [03:20:29 CET] <kepstin> (note that ffmpeg -h decoder=opus doesn't say any, fwiw, so that would at least be consistent) [03:20:33 CET] <faLUCE> kepstin: it should say what you just noted is hardcoded [03:20:46 CET] <faLUCE> otherwise it's misleading [03:21:05 CET] <kepstin> it's hardcoded in the *codec initializer* - so something using the ffmpeg apis doesn't know what format it's going to get until it has *initialized the decoder* [03:21:16 CET] <kepstin> so the gstreamer wrapper is correct as it is [03:21:39 CET] <faLUCE> I understand that but a note could be added [03:21:58 CET] <kepstin> it advertises the possible options, and then when the encoder is initialized at runtime it negotiates down to a supported one [03:22:24 CET] <kepstin> that's just how gstreamer works, on all codec formats audio and video, it doesn't need a note [03:22:56 CET] <faLUCE> then it should be fixed on libavcodec? [03:24:59 CET] <kepstin> nothing's broken, so it doesn't need to be fixed, but you could certainly improve libavcodec to have opusdec put a list of sample formats into the AVCodec struct. [03:25:47 CET] <faLUCE> kepstin: don't be overkill with concepts. you got the idea ;-) [03:27:26 CET] <kepstin> anyways, even if that gets set, you'd still need the audioconvert in your gstreamer pipeline [03:27:37 CET] <kepstin> because avdec_opus will still generate non-interleaved audio [03:27:39 CET] <faLUCE> kepstin: of course [03:28:11 CET] <faLUCE> but at least I'm not misleaded by the gstreamer'sAPI [03:28:59 CET] <faLUCE> kepstin: anyway, I'll see tomorrow if to send a note to the ml or a patch [03:29:11 CET] <kepstin> you're not being mislead. the gstreamer api says "the decoder will produce either interleaved or non-interleaved audio", and then when you run it, it gives you one of those. [03:29:55 CET] <faLUCE> kepstin: but from what we saw, it doesn't produce interleaved in any case [03:30:12 CET] <kepstin> sure, but gstreamer doesn't know that. [03:30:34 CET] <faLUCE> kepstin: then it doesn't have to write that it produces BOTH [03:30:47 CET] <kepstin> no, it says it produces one of the things in the list [03:30:50 CET] <kepstin> not both [03:31:03 CET] <faLUCE> no, because they are called "capabilities" [03:31:18 CET] <faLUCE> for example, if you gst_inspect opusdec [03:31:27 CET] <faLUCE> it prints "interleaved" only [03:31:50 CET] <kepstin> just like flacdec says it'll produce s8, s16le, s24_32le, s32le - but then when you decode a flac file, it won't let you use any of them, it'll only let you use one that matches the bit depth of the file you're decoding [03:31:58 CET] <kepstin> all gstreamer capabilities work like that [03:32:26 CET] <faLUCE> kepstin: you are not following what I said... [03:32:29 CET] <kepstin> runtime negotiation will pick one of the options from the list or range [03:32:43 CET] <kepstin> and it might not be the one you wanted [03:33:01 CET] <faLUCE> kepstin: I'm talking about gst-inspect [03:33:09 CET] <pridkett> does ffmpeg site use third party hub to report bugs ? [03:33:10 CET] <faLUCE> not RUNTIME [03:33:16 CET] <faLUCE> and not gst-launch [03:33:18 CET] <faLUCE> ok? [03:33:30 CET] <faLUCE> now, look at the output of gst-inspect opusdec [03:33:41 CET] <kepstin> faLUCE: exactly. since gst-inspect isn't doing runtime things, it can't tell you what you'll get at runtime [03:33:45 CET] <faLUCE> and compare it with the outut of gst-inspect avdec_opus [03:33:51 CET] <faLUCE> kepstin: wait [03:34:01 CET] <faLUCE> follow what I'm saying [03:34:21 CET] <faLUCE> now: the output of gst-inspect of opusdec says that it produces interleaved only [03:34:24 CET] <faLUCE> ok? [03:34:53 CET] <kepstin> sure, because opusdec in gstreamer knows that the libopus decoder it uses internally will always produce interleaved, so it doesn't put interleaved in the caps [03:34:53 CET] <faLUCE> BUT the output of gst-inspect avdec-opus claims to be able to produce both [03:35:41 CET] <faLUCE> yes. now, in case of avcodec_opus, gstreamer doesn't obtain a list of layers, right? [03:35:48 CET] <kepstin> the output of gst-inspect avdec_opus says "the output layout will at runtime be negotiated to one of the values from this list: interleaved, non-interleaved" [03:36:00 CET] <kepstin> the output of gst-inspect opusdec says "the output layout will at runtime be negotiated to one of the values from this list: interleaved" [03:36:20 CET] <kepstin> both are correct. [03:36:58 CET] <faLUCE> kepstin: so, you think that "layout: { (string)interleaved, (string)non-interleaved }" [03:37:15 CET] <faLUCE> as output of gst-inspect avdec_h264 is correct ? [03:37:26 CET] <faLUCE> as output of gst-inspect avdec_opus is correct ? [03:37:50 CET] <faLUCE> (capabilities part) [03:38:14 CET] <furq> the sentence as worded is correct [03:38:33 CET] <kepstin> given the knowledge avdec_opus has of the opus decoder in ffmpeg, it's behaving correctly - the avcodec structure says that the sample format is "unknown" (it's not set until encoder initialization), so gstreamer advertises both possible options, and negotiates at runtime after the sample format is known. [03:38:36 CET] <faLUCE> furq: but there 's also the OTHER sentence [03:39:32 CET] <faLUCE> kepstin: then also capabilities should be "unknown" for the "layer" field [03:39:48 CET] <kepstin> faLUCE: that's not how gstreamer works. [03:42:13 CET] <faLUCE> I'm asking in the gstreamer channel [03:42:27 CET] <kepstin> hmm, well, maybe it is, i forget whether the gstreamer stuff lets you leave a capability like that unset and add it later [03:42:31 CET] <kepstin> they could confirm that [03:43:03 CET] <kepstin> but the current way that works isn't wrong. [03:43:18 CET] <faLUCE> kepstin: in fact they already told me that I was correct and should send a patch [03:43:43 CET] <faLUCE> now, I'm asking again because you are insisting so much [03:44:48 CET] <kepstin> i assume they're also wondering why you're using avdec_opus instead of opusdec, and if you're having issues with that you *really* should get help with that [03:44:59 CET] <faLUCE> kepstin: they already know [03:45:05 CET] <faLUCE> and I also told you why [03:45:07 CET] <kepstin> libopus is an encoder/decoder designed for realtime usage, and used in gstreamer for realtime stuff already [03:45:15 CET] <faLUCE> and they confirmed there's a latency problem for realtime [03:45:15 CET] <kepstin> so... ? i dunno. [03:45:21 CET] <faLUCE> with opusdec [03:47:33 CET] <kepstin> anyways, the one-line patch to avcodec/opusdec.c to throw a list of supported sample_fmts into the avcodec struct will improve this situation... eventually [03:47:50 CET] <faLUCE> kepstin: yes, in fact I agree with that [03:48:14 CET] <faLUCE> and then, accordingly, the gst_inspect wrap could be automatically fixed [03:49:15 CET] <kepstin> if they think that the gstreamer ffmpeg wrapper should not set the layout capability when an ffmpeg codec says its supported sample formats are unknown, then they need to fix that on their end. [03:50:10 CET] <faLUCE> kepstin: yes, agree with that too [03:51:00 CET] <kepstin> oh wow, i think it's actually even buggier than that. on my system with gst 1.14 the gst-inspect avdec_opus is *only* returning layout: interleaved [03:51:05 CET] <kepstin> and that's definitely wrong [03:52:21 CET] <faLUCE> kepstin: with GStreamer 1.15.2 (GIT) it shows both [03:52:35 CET] <kepstin> well, at least that's an improvement [03:52:56 CET] <faLUCE> yes, maybe they are working on that [03:53:03 CET] Action: kepstin assumes that avdec_opus is mostly untested, because people mostly use opusdec [03:53:20 CET] <faLUCE> it works well, I tested it [03:53:37 CET] <kepstin> opusdec has a much higher rank, so it's autoselected when you use pipelines based on playbin/decodebin, etc. [03:54:21 CET] <faLUCE> ok, time to bed now [03:54:24 CET] <faLUCE> have a good night [04:16:14 CET] <pridkett> everybody big news [04:16:41 CET] <FishPencil> I'd like to add some random "sensor like" noise to an image, is FFmpeg able to do this (and if so how), and is FFmpeg the right tool for this? [04:25:31 CET] <kepstin> FishPencil: it's really hard to say, depends on the type of noise you want to add. https://www.ffmpeg.org/ffmpeg-filters.html#noise might be able to do it [04:25:40 CET] <kepstin> would have to play around with options. [04:26:01 CET] <kepstin> if you have an external image or video of just the "noise", you can also use ffmpeg filters to blend it onto a video. [04:27:08 CET] <pridkett> everybody i have big news [04:28:14 CET] <FishPencil> kepstin: I'm looking to do some de-noising algo stuff, so it probably need to be implemented in a way that I can rely on the result [04:29:03 CET] <kepstin> ah, denoising is hard. you probably want to avoid artificial noise for that sort of thing :/ [04:29:24 CET] <FishPencil> kepstin: that's how you normally asses the effectiveness of an algo [04:29:32 CET] <kepstin> (especially if you're doing neural net type stuff, it'll probably overfit to match the characteristics of the artificial noise) [04:30:41 CET] <kepstin> I'd suggest finding some sources of real noise (like, filmed blank/neutral grey video) that can be merged onto clean video if you really need a clean source to compare to the result of denoising. [04:31:23 CET] <kepstin> although getting that right would be tricky, i don't really know if the characteristics of say ccd noise in low light would work well like that :) [04:31:44 CET] <FishPencil> kepstin: It will actually be for DNN training, but what's the difference between "random" noise and actually random noise? [04:32:29 CET] <kepstin> well, real noise depends on the physical characteristics of the devices being used, so it's quite biased [04:33:01 CET] <kepstin> plain artificial random noise just adds a random amount of error to each pixel in an image. [04:33:42 CET] <FishPencil> kepstin: over a large sample size though wouldn't that get close to all the different sensors out there? [04:34:11 CET] <FishPencil> Or do all sensors have some sort of common noise pattern that cannot be duplicated [04:34:15 CET] <kepstin> FishPencil: probably not without manual tweaking [04:34:28 CET] <kepstin> your first step should be to analyze and model the type of noise that you want to remove, tbh [04:34:46 CET] <kepstin> it might be that you can build an artificial noise generator that will work well [04:34:50 CET] <FishPencil> I think it's just Gaussian sensor noise? [04:35:35 CET] <kepstin> FishPencil: I can't answer, i dunno how this works. start researching some papers, I'm sure people have modelled this kind of thing before :) [09:33:28 CET] <pridkett> dongs hey [09:47:51 CET] <dongs> well hello [10:05:20 CET] <pridkett> dongs so how do you feel? [10:07:58 CET] <dongs> pretty good until you started chatting [10:08:30 CET] <pridkett> dongs lol [10:08:37 CET] <pridkett> dongs so how do you feel to be busted [10:08:42 CET] <dongs> ? [10:08:50 CET] <dongs> still no idea what yo're on [10:08:52 CET] <pridkett> [dongs VERSION reply]: irssi v0.8.19 [10:08:58 CET] <dongs> i dont get it [10:08:59 CET] <dongs> and? [10:09:02 CET] <pridkett> what kind of linux hater uses irssi [10:10:00 CET] <dongs> as if there's no irssi port for windows [10:10:00 CET] <pridkett> that makes no sense to me: please make some sense into me [10:10:23 CET] <pridkett> dongs why would you want to use irssi period especially in windows [10:15:13 CET] <dongs> i donno man, ask dongs [10:15:28 CET] <pridkett> huh [10:15:44 CET] <pridkett> everybody big news: neural vocoder using LPCNet https://people.xiph.org/~jm/demo/lpcnet_codec/ [10:16:17 CET] <pridkett> dongs did you hear about that [10:17:41 CET] <pridkett> everybody big news: neural vocoder using LPCNet https://people.xiph.org/~jm/demo/lpcnet_codec/ [10:19:49 CET] <dongs> why are big news spaced like 2 minutes apart in your chats [10:20:03 CET] <pridkett> sorry [10:20:48 CET] <pridkett> dongs so what do you think? [10:21:07 CET] <dongs> about? [10:21:14 CET] <dongs> i dont care bout opus/xiph [10:21:20 CET] <dongs> like at al [10:21:21 CET] <dongs> l [10:22:12 CET] <pridkett> dongs look how low the kbps is [10:24:39 CET] <dongs> By contrast, the complexity of this 1.6 kb/s LPCNet-based codec is just 3 GFLOPS [10:24:42 CET] <dongs> 3 fucking niggaflops [10:24:42 CET] <dongs> comeon [10:24:50 CET] <dongs> nobody is gonna use that in real life [10:25:01 CET] <dongs> how is CIA gonna tap every mobile phone converstaion [10:25:05 CET] <dongs> if all the carriers switch to this [10:26:53 CET] <dongs> anyway the nubmers are completely unreasonable [10:27:05 CET] <dongs> to be used for anything beyond academic wank [10:28:52 CET] <pridkett> dongs what is GFlops of current typical VOIP use then [10:29:08 CET] <dongs> its not even in G-anything range [10:29:13 CET] <pridkett> i see [10:29:36 CET] <pridkett> what does 2k Video use then? [10:29:39 CET] <dongs> https://www.adaptivedigital.com/g-729/ [10:29:50 CET] <dongs> 1st random hit for g729 which is still poular [10:29:58 CET] <pridkett> does 4k video use 3 Gflops ? [10:30:00 CET] <dongs> like aroudn 12mips or so [10:30:04 CET] <dongs> 4K video of what [10:30:15 CET] <dongs> 4K video has hardware decoders that uses little power compared to CPU [10:30:16 CET] <pridkett> decoding/watching 4k video [10:30:28 CET] <pridkett> decoding/watching 4k video without using hardware decoder [10:30:34 CET] <dongs> nobody normal does that [10:32:04 CET] <dongs> i have some i7 and im almost certain software-only impementation (like vlc or wahtever) wil use 100% cpu [10:32:16 CET] <dongs> to the point wehre i dont even care about trying [10:32:20 CET] <pridkett> i see [10:32:26 CET] <pridkett> but how do you calcuate gflops [10:32:36 CET] <pridkett> when i get 100 cpu suage [10:32:45 CET] <pridkett> when i get 100 cpu usage [10:33:08 CET] <dongs> https://www.pugetsystems.com/pic_disp.php?id=32669 [10:33:45 CET] <pridkett> i7 920 does 40 gflops [10:33:52 CET] <pridkett> so 3 Gflops is nothing then [10:34:07 CET] <pridkett> why are you crying about 3 gFlops [10:34:23 CET] <dongs> thats 40gflops of highly optimized benchmark shit [10:34:32 CET] <dongs> your own link says it uses something like 13% of a threadcrapper [10:34:48 CET] <dongs> at 3ghz [10:34:49 CET] <dongs> thats a LOT [10:34:55 CET] <dongs> for a fucking voice codec [10:35:13 CET] <pridkett> not sure what Gflop is threadripper [10:35:22 CET] <dongs> software based G729 implemnentations on voip gateways run hundreds of not thousands of calls transocding 711 to 729 [10:35:24 CET] <pridkett> not sure what Gflop is threadripper 3ghz [10:38:13 CET] <pridkett> AMD A1100 (Cortex-A57) 1.7 GHz 102% 0.98x [10:40:48 CET] <dongs> yeah, 100% cpu usage for a voice codec [10:40:51 CET] <dongs> on a mobile processor [10:40:58 CET] <dongs> for a single stream [10:41:17 CET] <pridkett> lol [10:41:55 CET] <pridkett> but cpu is getting powerful every year [10:42:18 CET] <dongs> software dvelopers are getting lazier by the minute] [10:42:36 CET] <dongs> using shit tools , shit languages and writing (or rather copy pasting) shit code [10:44:19 CET] <pridkett> what does your HD camera use for audio? [10:44:29 CET] <dongs> lpcm [10:44:39 CET] <pridkett> what bit/samplerate [10:44:55 CET] <dongs> 16/48 iirc [10:45:21 CET] <pridkett> that's a lot of data , [10:45:25 CET] <pridkett> just for audio [10:45:37 CET] <dongs> it does video up to 200mbit so thats fine [10:45:56 CET] <pridkett> what video codec? [10:46:03 CET] <dongs> h264 [10:46:08 CET] <pridkett> which one [10:46:14 CET] <dongs> there is only one [10:46:27 CET] <pridkett> there are several h264 encoders [10:46:32 CET] <dongs> wot [10:46:39 CET] <pridkett> apple has their own [10:46:43 CET] <pridkett> ms has their own [10:46:45 CET] <dongs> its a camera dude. [10:47:35 CET] <pridkett> dongs let me see the quality, upload a sample [10:48:22 CET] <dongs> https://www.panasonic.com/global/consumer/camcorder/gallery.html [10:48:42 CET] <pridkett> wow 4k? [10:49:05 CET] <pridkett> can you even play it on a smartphone? [10:49:27 CET] <dongs> i don't play contents i record on a phone [10:49:49 CET] <pridkett> dongs these retards uploaded the sample on youtube [10:49:57 CET] <dongs> yea well [10:49:59 CET] <pridkett> youtube degrades quality [10:50:12 CET] <pridkett> they should know that [10:50:30 CET] <dongs> nobody is gonna download several gigs of shit and try to play it back on a random desktop pc [10:50:34 CET] <dongs> just to see the quality [10:50:56 CET] <pridkett> people who is interested in buying would [10:51:09 CET] <dongs> no [10:51:35 CET] <dongs> youtube gives a perfectly useful sample of what the optics/dynamic range/colors its capable of [10:51:37 CET] <pridkett> dongs wouldn't you care to see the samples before buying that camera [10:51:45 CET] <dongs> its hard to fuck up video when you're doing it at 200mbit [10:51:49 CET] <dongs> no [10:51:51 CET] <pridkett> they reencode everything to shit quality [10:53:11 CET] <pridkett> dongs how much YEN did it cost you, may i ask [10:53:51 CET] <dongs> i paypal'd it from teh jews in new york (b&hphoto) for around 3.5k iirc. [10:53:56 CET] <dongs> usd [10:54:01 CET] <dongs> back wehn it was new [10:54:06 CET] <dongs> i think its about ~2k now [10:54:15 CET] <pridkett> aren't you in Japan? [10:54:22 CET] <dongs> yes, but it was too expensive in japan [10:54:27 CET] <pridkett> i see [10:54:36 CET] <pridkett> it's panasonic [10:54:42 CET] <pridkett> it should be cheaper [10:54:46 CET] <pridkett> since it's panasonic [10:54:52 CET] <dongs> i recently had it serviced to replace the lens assembly as the zoom motor crapped out [10:55:01 CET] <dongs> and there was no issue wiht the warranty/whatever [10:56:19 CET] <dongs> https://www.bhphotovideo.com/c/product/1451846-REG/panasonic_ag_cx350_4k_ca… this is the new hot shit [10:57:51 CET] <pridkett> what is the disk space does it come with [10:58:20 CET] <dongs> sdxc cards, so any [10:58:31 CET] <dongs> and there's 2 slots so you can swap stuff out while its recording on the other slot. [10:58:38 CET] <pridkett> so none [10:58:44 CET] <pridkett> you have to rely on sdxc [10:58:52 CET] <pridkett> cheap bastards [10:59:03 CET] <pridkett> what filesystem does sdxc cards even use these days [10:59:28 CET] <dongs> exfat [10:59:36 CET] <dongs> at least thats what i use on mine [10:59:45 CET] <dongs> i think it can also read NTFS-formatted USB3 hdd [10:59:45 CET] <pridkett> that's what i thought, because i know you cannot use fat32 [10:59:48 CET] <dongs> read/write [11:00:03 CET] <pridkett> people don't seem to like exfat [11:00:15 CET] <pridkett> "linux people" [11:00:18 CET] <dongs> by "people" you probably mean " [11:00:19 CET] <dongs> yes exactly [11:00:22 CET] <dongs> normal people don't care. [11:00:29 CET] <pridkett> lol yeah "linux people" [11:01:33 CET] <pridkett> i don't like the idea of swapping sdxc cards though [11:01:42 CET] <pridkett> why can't it have a 512 GB SSD on it [11:01:52 CET] <dongs> because you can have 1TB SD card [11:01:55 CET] <dongs> or two of them [11:02:11 CET] <pridkett> SDcard is not realizble [11:02:16 CET] <dongs> ? [11:02:29 CET] <pridkett> they are not as reliable as ssd [11:02:37 CET] <pridkett> it's true [11:03:06 CET] <pridkett> trying to fit 1TB on that small space [11:03:07 CET] <dongs> removable 512gb unreliable media is orders of magnitude more useful than non-removable SSD [11:04:20 CET] <pridkett> also it's slow [11:04:45 CET] <dongs> non-issue [11:05:58 CET] <pridkett> 1tb sdxc would be super expensi e [11:06:11 CET] <pridkett> and can you imagine if you lost it [11:08:03 CET] <dongs> you'd be surprised [11:08:26 CET] <pridkett> dongs stop using irssi [11:08:52 CET] <dongs> cheap 1tb sdxc (certainly not capable of doing 400mbit for that panasonic cam) is half price of last gen samsung 860 evo 1tb [11:09:41 CET] <pridkett> $200 for samsung evo 1tb [11:10:04 CET] <pridkett> 1tb sdxc is not $100 [11:10:20 CET] <dongs> it is [11:12:23 CET] <pridkett> aren't you the guy who does JAV AV ? [11:14:12 CET] <dongs> i am [11:14:29 CET] <pridkett> editing or shooting? [11:14:37 CET] <dongs> both [11:14:49 CET] <pridkett> what camera do you use? [11:14:59 CET] <dongs> we literally just finished discussing cameras [11:15:07 CET] <pridkett> or is it the same one we were dicussing [11:15:17 CET] <dongs> yes [11:15:19 CET] <pridkett> dongs sorry [11:15:49 CET] <pridkett> do you think everybody should be shooting with 4k these days even if final product is 2k ? [11:18:28 CET] <pridkett> you have this? Panasonic 4K Camcorder WXF990/WXF991 but you want to upgrade to: Panasonic AG-CX350 4K Camcorder ?? [11:18:46 CET] <dongs> no i have HC-HX1000 [11:18:52 CET] <dongs> and yeah cx350 looks nice [11:19:06 CET] <pridkett> what is better? HC-HX1000 or WXF991 [11:19:10 CET] <dongs> yeah definitely shoot in 4K and downrez in post [11:19:17 CET] <dongs> i dont know, wxf is some consume shit i think [11:20:14 CET] <pridkett> wow AG-CX350 is way more expensive than HC-HX1000 [11:20:22 CET] <dongs> it is now, yes [11:20:26 CET] <dongs> launch price for x1000 was same [11:20:28 CET] <dongs> around 3.5k [11:20:34 CET] <pridkett> i see [11:20:52 CET] <pridkett> you better upgrade very soon, to satisfy your customers [11:24:42 CET] <pridkett> dongs do you shoot in PAL mode or NTSC mode [11:42:10 CET] <`mist> hey guys, i'm trying to hw transcode plex using ffmpeg but i've got an interesting message in my plex log [11:42:22 CET] <`mist> Mar 30, 2019 11:33:54.876 [0x7f0db77fe700] ERROR - [FFMPEG] - Cannot load libcuda.so.1 [11:42:46 CET] <`mist> So i would assume that means it can't find libcuda, however if i do ldconfig -p | fgrep cuda, i can see it there [11:47:17 CET] <pridkett> `mist what is the exact command are you typing [11:47:36 CET] <pridkett> for your transcoding [11:50:08 CET] <`mist> nvm, i solved it [11:50:19 CET] <`mist> i had forgotten to create my docker container with the nvidia runtime [12:55:49 CET] <dongs> pridkett: lol. [12:55:55 CET] <dongs> can you stop trolling or something [12:56:01 CET] <pridkett> what is funny? [12:56:11 CET] <pridkett> did i say something funny? [14:32:41 CET] <pink_mist> dongs: he's not even capable of holding a coherent conversation, so stopping trolling seems like you're asking for a mountain when he can't even give you a pebble [14:32:59 CET] <dongs> arent you the same guy? [14:33:14 CET] <pink_mist> ??? [14:33:56 CET] <pink_mist> how in hell did you get that idea? [14:34:09 CET] <pink_mist> I think that's the most insulted I've ever been [14:34:14 CET] <pink_mist> mistaking me for fucking pridkett [14:34:17 CET] <dongs> haha [00:00:00 CET] --- Sun Mar 31 2019

1 0

ffmpeg-devel.log.20190329
by burek 30 Mar '19

30 Mar '19

[02:02:01 CET] <cone-957> ffmpeg 03Michael Niedermayer 07n3.4.6:HEAD: swscale/swscale_unscaled: Fix chroma slice height [02:55:25 CET] <cone-957> ffmpeg 03Zhong Li 07master:520226b6835f: lavc/hevc_ps_enc: fix vps nal issues [03:14:44 CET] <cone-957> ffmpeg 03Zhong Li 07master:9dece050ef01: lavc/qsvenc: fix hevc vps extradata issues [10:10:41 CET] <j-b> 'morning [10:13:16 CET] <durandal_1707> good day! [10:25:03 CET] <thardin> is amuse graphics movie a game codec? [10:39:10 CET] <durandal_1707> thardin: nope, its japanese crap [11:04:30 CET] <thardin> another format related to cantonese wood carvings? [11:04:59 CET] <JEEB> sounds like a screen capture format or something - but even more obscure than amarecoco [15:20:08 CET] <pymit> Hi, I'm Amit Kumar , a third year CSE undergraduate . I'm really excited about the project "Use deep learning derain techniques to implement a filter ..." , I have experience in Deep learning . I would be glad to discuss about this project more. [15:36:17 CET] <thilo> pymit: Don't know if the corresponding mentor is around here much - try to contact Steven via mail directly. Also you are in a hurry, application deadline is April 9th and a qualification task is necessary to be done before that. [15:37:51 CET] <pymit> what are the qualification task ? [15:38:23 CET] <thilo> pymit: https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2019#DerainFilter [15:38:41 CET] <thilo> pymit: No very specific description, get details from the mentor in question [15:39:09 CET] <pymit> Thank you thilo [15:39:25 CET] <thilo> pymit: You're welcome, good luck! [18:56:24 CET] <cone-324> ffmpeg 03Sam John via ffmpeg-devel 07master:995889abbf31: avcodec/libaomenc: Added more commandline options [18:56:25 CET] <cone-324> ffmpeg 03James Almer 07master:0856c5da0716: avcodec/libaomenc: fix default value for row-mt option [18:57:50 CET] <jamrial> ugh, forgot to amend the author name [18:58:06 CET] <jamrial> why are mails from google obfuscated like that? [19:01:40 CET] <nevcairiel> not sure why it messes with the sender name, but the sender address is being changed because googles domains dont allow other mail servers (ie. our list server) to send mails on their behalf [19:02:40 CET] <nevcairiel> in a perfect world it would instead insert a From line into the patch [19:02:44 CET] <nevcairiel> but thats too smart [00:00:00 CET] --- Sat Mar 30 2019

1 0

ffmpeg.log.20190329
by burek 30 Mar '19

30 Mar '19

[01:19:13 CET] <dablitz> good evening channel. I am wondering if it is possible to stream audio only with G.711 codec via RTP with ffmpeg [03:50:01 CET] <pridkett> does ffmpeg support converting 60 fps to 30 fps ? [07:09:06 CET] <pridkett> what does 64bit application offer that 32bit application does not offer [12:09:10 CET] <faLUCE> dablitz: did you try the command? [12:13:27 CET] <dablitz> faLUCE: yes i dis but -a g.711 didnt work [12:16:52 CET] <faLUCE> dablitz: paste the command [12:27:09 CET] <dablitz> ffmpeg -i hw,1:0 -acodec g.711 -ar 11025 --f rtp rtp://fc79:85f6:a2b5:1c5a:91d5:a11b:6ca8:692f:54000 [12:34:17 CET] <faLUCE> dablitz: I see pcm_alaw and pcm_mulaw from encoders' list [12:34:48 CET] <faLUCE> so, replace g.711 with pcm_mulaw [13:00:42 CET] <dablitz> faLUCE: i will try that thank you [13:00:56 CET] <JEEB> dongs: sorry I've been busy posing my waifus in a 3-D modeling thing :) but feel free to ask anyways, in case I can be of use [15:43:40 CET] <kevinnn> Hi all, what kind of effect on performance does interlacing have on x264? [15:46:40 CET] <pridkett> kevinnn you mean if you when you want to encode a interlaced video using x264 ? [15:47:39 CET] <kevinnn> pridkett: does x264 offer an interlaced option? I see many references to interlacing throughout x264.h [15:47:54 CET] <kevinnn> like will it only process half the pixels every cycle [15:48:03 CET] <kevinnn> which should double the performance right? [15:48:09 CET] <pridkett> i am not sure, but ffmpeg does [15:48:13 CET] <kevinnn> and halve the size of the output [15:48:13 CET] <pridkett> why not just use ffmpeg [15:48:35 CET] <JEEB> kevinnn: remember field rate vs frame rate :P [15:48:48 CET] <JEEB> fields might be half the height but then you get 2x of them [15:48:57 CET] <JEEB> also usually x264 encodes in MBAFF mode [15:49:02 CET] <JEEB> which means that two fields get coded together [15:49:51 CET] <kevinnn> JEEB: so does that mean that there is no advantage to tuning interlaced in x264? [15:50:15 CET] <JEEB> you use interlaced coding when you absolutely need to pass content through interlaced (and you need to re-encode) [15:50:31 CET] <JEEB> otherwise zarro reason to encode interlaced :P [15:50:45 CET] <JEEB> some features get disabled in x264 to make it an even sweeter deal [15:51:30 CET] <kevinnn> JEEB: what do you mean by absolutely need to? I want to get a bit more performance out of x264, is that not a good use case for interlaced? [16:04:44 CET] <kevinnn> JEEB? [16:06:42 CET] <dongs> JEEB: well, still same shit. i can't figure out which layer TLV-NIT is at [16:06:48 CET] <DHE> if the source input is interlaced and that's what needs to be encoded, you use interlace mode. it's easy as that [16:06:51 CET] <dongs> i thought it was TLV type FE but im not getting anythign there [16:07:00 CET] <DHE> but yes, there are quality/performance impacts of interlaced mode [16:07:01 CET] <dongs> i forget if your paste showed nit parsing or not [16:07:16 CET] <DHE> (I have a build of x264 with interlacing support disabled) [16:07:43 CET] <kevinnn> DHE: if the source is not interlaced is there any performance impacts? [16:07:56 CET] <dongs> btw, after fixing hardware, 8K capture is flawless now [16:08:04 CET] <dongs> nothing i have plays it t ho [16:08:08 CET] <dongs> it uses 100% nvdec [16:08:12 CET] <dongs> to play at like 15-20fps [16:08:14 CET] <dongs> if even that [16:08:18 CET] <kevinnn> DHE: also if the source is interlaced... does it process even lines first or odd lines first? [16:08:43 CET] <DHE> kevinnn: x264 supports tff and bff interlace modes [16:09:28 CET] <kevinnn> DHE: tff? [16:09:41 CET] <DHE> the performance impact of non-interlaced modes would be pretty theoretical. all the conditions that say "if (is_interlaced) {...}" would always fail, but it's probably a 1 millionth of a slowdown fraction [16:09:47 CET] <DHE> top field first, bottom field first [16:10:34 CET] <DHE> I'm building a custom application. very optimized. the configure commandline is 1000 bytes by itself [16:10:52 CET] <DHE> call it 1400 [16:11:09 CET] <kevinnn> DHE: so, enabling interlaced on a non interlaced stream shows no performance increase nor does it make the individual NAL units any smaller? [16:11:19 CET] <kevinnn> I don't understand how that could be possible [16:11:24 CET] <kevinnn> wow [16:11:30 CET] <kevinnn> I'd like to see that :) [16:11:31 CET] <DHE> oh, you mean mis-setting the parameter [16:11:51 CET] <kevinnn> DHE: well sort of [16:12:02 CET] <kevinnn> it should only process half the pixels right? [16:12:11 CET] <kevinnn> every cycle [16:12:16 CET] <DHE> I don't know enough about h264 to make the call. I'm just a user with requirements who did a lot of research specific to that [16:12:35 CET] <kevinnn> you did research specific to interlacing? [16:13:11 CET] <DHE> fortunately I'm just deinterlacing everything so I can build x264 with --disable-interlaced, makes x264 a bit smaller and should be a hair faster [16:15:28 CET] <kevinnn> hmm, so if I mis-enable interlacing on my x264 config right now is there any changes I need to make to my source buffer? Any changes I need to make to the client processing the NAL units? [16:19:34 CET] <kepstin> kevinnn: the main thing incorrectly enabling interlaced parameter on a progressive frame might do is cause the decoded video to have the chroma processed incorrectly, giving slight artifacts on edges of coloured objects. It will likely also slightly reduce the coding efficiency. [16:21:13 CET] <kevinnn> kepstin: interesting, so there is no advantage at all to using interlaced video? Even if enabled correctly? [16:22:33 CET] <kepstin> if your video is actually interlaced, then enabling interlaced mode on the x264 encoder will preserve the interlacing. If you don't use interlaced mode, it might introduce artifacts that blend fields [16:22:46 CET] <kepstin> and the decoder won't know it's interlaced, so might not run a deinterlacer [16:23:53 CET] <kepstin> an interlaced digital "frame" contains two fields from different times on alternate lines ("combed" together) [16:24:50 CET] <kepstin> so a 60 field per second interlaced video will be stored as 30 frames per second, and each frame will contain two fields - one field on the even lines, one on the odd lines. [16:26:55 CET] <kepstin> setting the interlaced mode on the x264 encoder just tells the encoder "the frames i'm giving you aren't a single image, they actually have two pictures combed together", and then the x264 encoder uses a less efficient encoding mode that keeps the two images from getting blended together. [16:29:07 CET] <kevinnn> kepstin: thank you very much, that was exactly what I was looking for [16:56:10 CET] <kepstin> anyways, to summarize: enabling interlaced mode makes the x264 encoder slower and makes the individual nal units bigger. [16:56:17 CET] <iive> actually the decoder decides on its own whenever to encode the image as single picture or two fields. so in effect it would use the most efficient encoding. [16:56:50 CET] <iive> it comes at price of slower encoding. [16:58:15 CET] <kepstin> iive: not sure why you mention a decoder. anyways, last i checked, x264 only supported mbaff encoding which encodes both fields together into one frame. [16:58:49 CET] <iive> i meant encoder. [17:45:29 CET] <Muchoz> I've been wondering whether it is possible to mix tiling and non-tiling SHVC's layers. So that you could download a base layer that isn't tiled and download tiled enhancement layers. Is this possible? [17:46:46 CET] <JEEB> not sure if many people have looked into scalable coding [17:47:15 CET] <JEEB> I know that some paytv companies are starting to look into it as means of coding a free base layer, and then having the higher resolution extra layer paid [17:47:22 CET] <JEEB> which might make people implement it, but I don't know [17:47:40 CET] <JEEB> since I don't know if there's any support for SVC or SHVC in hw decoders right now [17:47:49 CET] <JEEB> I know in software pretty much just the reference decoder exists [17:50:10 CET] <Muchoz> I'm researching HAS for VR video and was interested in seeing whether this was just "possible" for now and whether I could generate these files already. I'm atm not really interested in the playback of it. [17:51:38 CET] <Muchoz> So the most important aspect for me right now is streaming the data over multiple types of networks. [17:51:56 CET] <JEEB> anyways, I guess check H.265's limitations regarding tiling, esp. regarding additional layers [17:52:30 CET] <Muchoz> It's not something that could perhaps already be done using mp4box? [17:53:03 CET] <JEEB> ? [17:53:15 CET] <JEEB> that's a container thing [17:53:33 CET] <JEEB> if it was a container level thing then no coding things would be required [17:54:21 CET] <JEEB> with SVHC and separate transmission you'd have to figure out how different containers handle the signaling [17:54:42 CET] <Muchoz> Handle the signaling of what? [17:55:05 CET] <JEEB> "there's a separate layer available on track X which you can merge with your current track" [17:55:24 CET] <JEEB> you have to signal that somehow if you are transferring it in some separate way [17:55:55 CET] <Muchoz> Ah right [17:56:08 CET] <JEEB> or if you handle it before demuxing and just merge things into a single track for the player then however you handle that part [17:56:28 CET] <JEEB> (Aka "make a single track out of samples coming from this and that source") [17:56:46 CET] <Muchoz> Okay I'm speculating now [17:57:01 CET] <JEEB> not sure how many things have standardized such signaling so that you could have X completely separate sources [17:57:03 CET] <Muchoz> Let's say I have a base layer that is not tiled and a base layer that IS tiled. [17:57:20 CET] <JEEB> because in MPEG-TS your broadcast either has the full set of PIDs, or it doesn't [17:57:33 CET] <Muchoz> Can enhancements layers be applied to either of those base layers? [17:57:42 CET] <JEEB> and then you have a signaling thing that says "for PID 123 there's also PID 345 which has the enhancement layer" [17:57:42 CET] <Muchoz> Those enhancements layers ARE tiled then. [17:57:54 CET] <Muchoz> I'm currently not looking into making it actually work. [17:58:03 CET] <JEEB> but you want separately transferred things soo... :| [17:58:09 CET] <Muchoz> I'm looking at the feasibility of streaming this in the first place. [17:58:28 CET] <JEEB> multiple base layers... no idea [17:58:40 CET] <JEEB> for actual SHVC I recommend taking a dive into H.265's limitations :P [17:58:41 CET] <Muchoz> No not multiple base layers [17:58:55 CET] <Muchoz> https://www.utdallas.edu/~afshin/publication/360.pdf [17:58:58 CET] <JEEB> > I have a base layer that is not tiled and a base layer that is tiled [17:59:09 CET] <Muchoz> They're working with a base layer that is tiled [17:59:56 CET] <Muchoz> I'm asking whether I can make 1 single base layer that is not tiled. [18:00:26 CET] <Muchoz> But leave the enhancement layers tiled. Do these enhancements layers "depend" on how the base layer was encoded or...? [18:01:03 CET] <Muchoz> My apologies for trying to dumb it down, I don't know _that_ much about it [18:01:05 CET] <JEEB> read the H.265 spec? it's free :P [18:01:26 CET] <JEEB> also the tiling in this article seems to be for the purposes of not having to transfer all of it necessarily [18:01:36 CET] <JEEB> at least that's how it feels like [18:01:52 CET] <JEEB> althought not sure where hte SVHC comes up there [18:02:23 CET] <Muchoz> See 4.1 in there [18:04:28 CET] <JEEB> anyways, if the spec doesn't say that all layers have to share their tiling configuration then that's it :P [18:04:31 CET] <JEEB> please refer to the spec [18:05:01 CET] <JEEB> and yes, it seems like they're using tiles just for the purpose of not sending all things from the enhancement layer [18:05:41 CET] <Muchoz> Alright, thank you. I'll read the spec. [18:06:52 CET] <JEEB> http://www.itu.int/rec/T-REC-H.265 [18:07:01 CET] <JEEB> includes the scalable extensions etc [18:07:24 CET] <Muchoz> Ya, I had it open. It's just a bit overwhelming to see 700 pages :p [18:07:53 CET] <JEEB> also you can always ask the development mailing list for it and see if you get a response [18:08:02 CET] <Muchoz> The extension itself seems to cover 30 pages. I'll check there first [18:08:05 CET] <JEEB> SVHC is really not used outside of academia [18:08:24 CET] <Muchoz> Where is that mailing list? [18:08:35 CET] <JEEB> jct-vc is the base HEVC mailing list [18:08:46 CET] <JEEB> scalable coding might have a separate one, although it's part of the spec now [18:09:16 CET] <Muchoz> Thank you, I'll figure out how to work with mailing lists as welel [18:09:28 CET] <JEEB> I think for SVC the only "real" use case I've seen so far was cisco telecalls [18:09:34 CET] <JEEB> where for some reason they utilized SVC :) [18:11:11 CET] <JEEB> and looking at that player they seem to have utilized some out-of-band signaling of layers or so - it's really unclear if they actually tested their setup [18:11:48 CET] <JEEB> because they don't have link towards whatever they utilized to play the thing etc [18:12:03 CET] <JEEB> granted I did just scroll through it rather quickly :P [18:12:07 CET] <JEEB> including the references at the end [18:14:33 CET] <Muchoz> JEEB, it's because the focus is on streaming it. Not playing it back. [18:14:41 CET] <JEEB> well they didn't stream [18:14:45 CET] <JEEB> the encoder was the reference encoder [18:14:50 CET] <JEEB> that's not going to stream anything for you [18:15:05 CET] Action: JEEB still has memories of one-frame-per-minute for HM [18:15:33 CET] <JEEB> and I don't think SHVC's reference encoder is any better [18:16:14 CET] <Muchoz> With streaming I mean downloading [18:16:43 CET] <Muchoz> Just using HAS [18:16:56 CET] <JEEB> also they included all sorts of funk stuff like "this will be X times faster" etc etc - which you should back up with some implementation [18:17:05 CET] <JEEB> you can't just say it is magically faster :P [18:17:22 CET] <Muchoz> JEEB, don't complain to me about their paper :p [18:17:35 CET] <Muchoz> I agree completely, I would want to open source my work. [18:17:58 CET] <Muchoz> The scalable extension section of the spec is also just filled with code and it's really just useless to me. [18:18:11 CET] <JEEB> see profiles section [18:18:13 CET] <Muchoz> I would have to read the entire spec to really just know what is going on. [18:18:45 CET] <Muchoz> Alright, I'll read the profiles section more thoroughly [18:19:09 CET] <JEEB> scalable main it seems [18:20:33 CET] <Muchoz> It's just throwing around a lot of references to variables that I have no idea what they mean. [22:56:42 CET] <kevinnn> is there anyone here who might know anything about live555? [23:04:32 CET] <kevinnn> also does anyone know how can I force x264_encoder_encode to only produce 1 NAL unit each cycle [23:26:51 CET] <BtbN> I don't think that's possible. You can just split them though. [23:29:09 CET] <kevinnn> BtbN: what do you mean split them? [23:29:31 CET] <BtbN> NALs are pretty easy to identify, is they start with their usual start code [23:30:07 CET] <kevinnn> BtbN: for my particular use case I'd like there only to be one NAL unit produced each call to encode [23:30:14 CET] <BtbN> why? [23:30:23 CET] <kevinnn> well.. it is a bit complex [23:31:17 CET] <kevinnn> so I am creating a streaming protocol of sorts. I am noticing that the system latency goes up everytime there are more than one NAL units produced [23:31:29 CET] <kevinnn> by an encode cycle [23:31:50 CET] <kevinnn> so I wanted to test to see if I adjust it down to 1 NAL unit per cycle if my latency will go back down [23:32:19 CET] <BtbN> The amount of NALs it generated per frame depends on a lot of settings. You can't just set "1 NAL please" [23:32:25 CET] <BtbN> And what do you mean by system latency? [23:32:27 CET] <BtbN> Encode delay? [23:32:44 CET] <kevinnn> no, sending, it takes longer to send more NAL units [23:32:53 CET] <BtbN> That makes no sense [23:33:01 CET] <kevinnn> I am using live555 rtsp to send each NAL unit [23:33:20 CET] <kevinnn> and for some reason it takes a really long time to send more NAL units then it does fewer [23:33:38 CET] <BtbN> Why would the transport protocol care about codec specifics like that? [23:33:50 CET] <BtbN> I can see it care about I/P/B frame types, but NALs? [23:34:10 CET] <kevinnn> I honestly have no idea... it is just a trend I noticed [23:34:24 CET] <kevinnn> I wanted to see if the multiple NAL units was causing the latency [23:41:25 CET] <BtbN> You could try disabling slice threading and force a single slice, that should reduce the amount of NALs [23:41:37 CET] <BtbN> But I really have high doubts about that causing latency [23:46:29 CET] <kevinnn> BtbN: x264_encoder->parameters.b_sliced_threads = 0; x264_encoder->parameters.i_slice_count = 1; x264_encoder->parameters.i_slice_count_max = 1; [23:46:51 CET] <kevinnn> I tuned these and I am still seeing a few times where more NAL units are produced [23:47:08 CET] <BtbN> Yes, IDR frames are bound to have multiple, nothing can be done about that. [23:48:14 CET] <kevinnn> BtbN: hmm, ya oddly enough it seems that the latency is a bit better this time around though... [23:48:25 CET] <kevinnn> I am doing to adjust keyintmax and see what happens [23:48:47 CET] <BtbN> That can only be a matter of single digit milliseconds really [23:51:08 CET] <kevinnn> BtbN: perhaps it is the placebo effect [23:51:20 CET] <kevinnn> it doesn't feel any less latenc [23:51:24 CET] <kevinnn> latent* [23:51:30 CET] <kevinnn> and I've tuned key int [23:51:36 CET] <kevinnn> so it is mostly just 1 NAL unit [23:51:40 CET] <BtbN> Are you trying to do real time gaming via streaming there? [23:51:46 CET] <kevinnn> god what could be the issue [23:51:49 CET] <kevinnn> gaming? [23:51:55 CET] <kevinnn> no, remote desktop [23:52:03 CET] <BtbN> Yeah... that'll be a pain to do [23:52:11 CET] <kevinnn> why? [23:52:17 CET] <BtbN> ffmpeg is not designed for ultra low latency at all [23:52:22 CET] <BtbN> it has buffers for everything left and right [23:52:32 CET] <kevinnn> this set up was actually working pretty well on 30 fps [23:52:37 CET] <kevinnn> also not using ffmpeg [23:52:50 CET] <kevinnn> it is raw c++ with x264 [23:52:57 CET] <BtbN> I assume you did put x264 in zerolatency mode already? [23:53:04 CET] <kevinnn> yea.. [23:54:11 CET] <kevinnn> I am timing the receives on the client end and they are pretty high for some reason. I noticed that if I commented out my fps limiting code (at 60fps) then the receiving end would receive quicker for a little but the screen would quickly lag out [23:55:55 CET] <BtbN> You need to make sure your player does not buffer frames, same for the encoder [23:56:06 CET] <BtbN> if it goes slow, drop frames, don't buffer [23:56:43 CET] <kevinnn> live555 should use UDP for transport so when it drops frames it shouldn't buffer [23:56:54 CET] <BtbN> But your player or the encoder could [23:57:15 CET] <BtbN> If the player can't keep up for a short moment because of system load, it needs to skip frames [23:57:58 CET] <kevinnn> BtbN: okay let me see if I can get the player to drop some frames [23:58:36 CET] <BtbN> Pretty much, just don't have any buffer at all. Play the latest frame, drop anything else [23:59:14 CET] <BtbN> For that to work you either need to send only I frames, or implement logic to re-request an IDR frame if stuff was lost [00:00:00 CET] --- Sat Mar 30 2019

1 0

ffmpeg-devel.log.20190328
by burek 29 Mar '19

29 Mar '19

[00:45:49 CET] <cone-552> ffmpeg 03Carl Eugen Hoyos 07master:9fa757ad7c7f: lavc/vaapi_hevc: Do not initialize fields twice. [00:51:38 CET] <cone-552> ffmpeg 03Carl Eugen Hoyos 07master:f8fa8bbf225f: lavc/vaapi_h264: Do not set FMO fields. [01:49:45 CET] <cone-552> ffmpeg 03Carl Eugen Hoyos 07n4.0.4:HEAD: lavc/vaapi_h264: Do not set FMO fields. [02:24:26 CET] <philipl> lrusak: I mean something like what's in nvdec_mjpeg.c where decode_slice just returns 0 and does nothing. [02:53:45 CET] <lrusak> philipl, gotcha, I saw that too :) [04:40:52 CET] <jya> anyone with H264 sample using bt2020 , or HDR ? [07:29:14 CET] <jya> never mind, discovered that nice -f lavfi -r 1 -i testsrc=s=1280x720 utility [11:31:06 CET] <thardin> .. bink patches? [11:36:13 CET] <JEEB> hey, I get to test out my Chinese cartoon openings for games :) [12:15:53 CET] <J_Darnley> JEEB: I must need better chinese cartoon games because the ones I have are in a "sensible" format [12:26:59 CET] <thardin> RoQ? [12:30:31 CET] <J_Darnley> I've seen avi and wmv [12:44:18 CET] <BradleyS> the download button on this page has the correct text but links to an old version: http://ffmpeg.org/download.html [13:19:21 CET] <J_Darnley> Wow, that AVX2 v210dec patch is a good improvement over a naive one [13:19:50 CET] <J_Darnley> 652 vs 507 decicycles [15:01:03 CET] <cone-469> ffmpeg 03Zhong Li 07master:81ae387a265d: configure: include pkgconfig path as vaapi header search [15:01:04 CET] <cone-469> ffmpeg 03Zhong Li 07master:b47446cc39d9: lavc/qsvenc: make the queried libmfx version easily reused [15:01:05 CET] <cone-469> ffmpeg 03Zhong Li 07master:4131b0619c22: qsv: fix the dangerous macro definitions [15:01:06 CET] <cone-469> ffmpeg 03Zhong Li 07master:b9a066ae23cb: lavc/qsvenc: use the common option "trellis" of AVCodecContext [15:01:07 CET] <cone-469> ffmpeg 03Zhong Li 07master:391f884675f3: lavc/qsvenc_h264: remove the privite option trellis [17:35:04 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:f3404f6b90ef: avcodec/mpegaudio_parser: Consume more than 0 bytes in case of the unsupported mp3adu case [17:35:05 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:a6e6b866694e: avcodec/cavsdec: Propagate error codes inside decode_mb_i() [17:35:06 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:e8aaadd41ea5: avcodec/shorten: Fix integer overflow with offset [17:35:07 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:4376377c5133: fftools/ffmpeg: Repair reinit_filter feature [17:35:08 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:5e1133920f52: avcodec/pngdec: Check compression method [17:35:09 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:940c6f3fb189: avcodec/truemotion2: fix integer overflows in tm2_low_chroma() [17:35:10 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:506b9c88c739: avcodec/truemotion2rt: Fix rounding in input size check [17:35:11 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:f06485063df0: avcodec/msmpeg4dec: Skip frame if its smaller than 1/8 of the minimal size [17:35:12 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:d6aac086b61c: avcodec/wmv2dec: Skip I frame if its smaller than 1/8 of the minimal size [17:35:13 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:a6d25b6ba548: avcodec/msvideo1: Check for too small dimensions [17:35:14 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:04fe02bd80bc: avcodec/ppc/hevcdsp: Fix build failures with powerpc-linux-gnu-gcc-4.8 with --disable-optimizations [17:35:15 CET] <cone-469> ffmpeg 03chcunningham 07release/3.4:cb901e183608: lavf/mov: ensure only one tkhd per trak [17:35:16 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:f9b7c87145d2: avformat/nutenc: Document trailer index assert better [17:35:17 CET] <cone-469> ffmpeg 03chcunningham 07release/3.4:96062eb3cc82: lavf/id3v2: fail read_apic on EOF reading mimetype [17:35:18 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:e657e8e8d69b: avcodec/mjpegdec: Fix indention of ljpeg_decode_yuv_scan() [17:35:19 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:53d34fad0dd0: tests/fate/filter-video: increase fuzz for fate-filter-refcmp-psnr-rgb [17:35:20 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:f51a271f206b: avformat/mpegts: Fix side data type for stream id [17:35:21 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:4556f7c8a210: avcodec/avcodec: Document the data type for AV_PKT_DATA_MPEGTS_STREAM_ID [17:35:22 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:3ca0a8e077fc: avcodec/rpza: Move frame allocation to a later point [17:35:23 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:728f14265126: avcodec/rpza: Check that there is enough data for all the blocks [17:35:24 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:7df1c9361992: postproc/postprocess_template: Avoid using %4 for the threshold compare [17:35:25 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:30046553a5a3: postproc/postprocess_template: remove FF_REG_sp from clobber list [17:35:26 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:d99a3f9792ec: avcodec/fic: Fail on invalid slice size/off [17:35:27 CET] <cone-469> ffmpeg 03gxw 07release/3.4:4656ad1e9625: avcodec/mips: Fix failed case: hevc-conformance-AMP_A_Samsung_* when enable msa [17:35:28 CET] <cone-469> ffmpeg 03David Bryant 07release/3.4:24438427ef59: avformat/wvdec: detect and error out on WavPack DSD files [17:35:29 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:8490652c9cef: avcodec/mjpegbdec: Fix some misplaced {} and spaces [17:35:30 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:8349bcb526eb: avcodec/v4l2_m2m: fix cant typo [17:35:31 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:d43b48834010: avcodec/4xm: Fix returned error codes [17:35:32 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:b2fd3250c4a5: avcodec/exr: Check for duplicate channel index [17:35:33 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:980ad512910a: avcodec/exr: set layer_match in all branches [17:35:34 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:84ef2bba6c51: avcodec/h264_slice: Fix integer overflow in implicit_weight_table() [17:35:35 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:c4f2a8c6c125: avcodec/tests/rangecoder: initialize array to avoid valgrind warning [17:35:36 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:e726cd332dcf: avcodec/diracdec: Check component quant [17:35:37 CET] <cone-469> ffmpeg 03James Almer 07release/3.4:6c2e465f62c8: configure: bump year [17:35:38 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:9e5cb0df494b: avutil/mem: Optimize fill32() by unrolling and using 64bit [17:35:39 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:532b6c2b25c1: avutil/imgutils: Optimize memset_bytes() by using av_memcpy_backptr() [17:35:40 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:23f6170f1bdb: avcodec/tiff: Check for 12bit gray fax [17:35:41 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:ae4148b89539: avcodec/fic: Check that there is input left in fic_decode_block() [17:35:42 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:d3aab6332065: avformat/rtsp: Clear reply in every iteration in ff_rtsp_connect() [17:35:43 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:136ec39a2f81: avformat/rtsp: Check number of streams in sdp_parse_line() [17:35:44 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:4946bda47302: avcodec/pgssubdec: Check for duplicate display segments [17:35:45 CET] <cone-469> ffmpeg 03chcunningham 07release/3.4:0063964f84b1: avformat/mov.c: require tfhd to begin parsing trun [17:35:46 CET] <cone-469> ffmpeg 03chcunningham 07release/3.4:08b159fd0d9d: avformat/mov: validate chunk_count vs stsc_data [17:35:47 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:80603682ff59: avcodec/sbrdsp_fixed.c: remove input value limit for sbr_sum_square_c() [17:35:48 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:3ae6063f5ac3: avformat/mov: Do not use reference stream in mov_read_sidx() if there is no reference stream [17:35:49 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:f9067108708a: avformat/matroskadec: Do not leak queued packets on sync errors [17:35:50 CET] <cone-469> ffmpeg 03Kevin Backhouse via RT 07release/3.4:9191218d1168: avcodec/htmlsubtitles: Fixes denial of service due to use of sscanf in inner loop for tag scaning [17:35:51 CET] <cone-469> ffmpeg 03Kevin Backhouse via RT 07release/3.4:e2ae3419ff47: avcodec/htmlsubtitles: Fixes denial of service due to use of sscanf in inner loop for handling braces [17:35:52 CET] <cone-469> ffmpeg 03Wenxiang Qian 07release/3.4:e62abf939863: avformat/ftp: Fix Out-of-Bounds Access and Information Leak in ftp.c:393 [17:35:53 CET] <cone-469> ffmpeg 03Wenxiang Qian 07release/3.4:3b4630c181cb: avformat/http: Fix Out-of-Bounds access in process_line() [17:35:54 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:1613b1669d02: avformat/webmdashenc: Check id in adaption_sets [17:35:55 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:8ddad9f9cdac: avcodec/h264_direct: Fix overflow in POC comparission [17:35:56 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:3891dbf4cf65: avcodec/jvdec: Check available input space before decode8x8() [17:35:57 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:edf0297c6147: avcodec/zmbv: obtain frame later [17:35:58 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:49f8873f8b89: avcodec/mlpdec: Insuffient typo [17:35:59 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:902c96ae16a0: avcodec/error_resilience: Use a symmetric check for skipping MV estimation [17:36:00 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:7a25b3192de6: avcodec/jpeg2000dwt: Fix integer overflow in dwt_decode97_int() [17:36:01 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:6abc6acd50ae: avcodec/bethsoftvideo: Check block_type [17:36:02 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:98fa61c02072: avcodec/gdv: Check for truncated tags in decompress_5() [17:36:03 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:7cc9a207919f: avcodec/aic: Check remaining bits in aic_decode_coeffs() [17:36:04 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:f2e3eae20418: avcodec/qpeg: Limit copy in qpeg_decode_intra() to the available bytes [17:36:05 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:66894351909f: avcodec/scpr: Fix use of uninitialized variable [17:36:06 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:2d825946a397: avformat/gdv: Check fps [17:36:07 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:d2fd2921e342: avcodec/cdgraphics: Use ff_set_dimensions() [17:36:08 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:51d29541cb22: avcodec/dvbsubdec: Check object position [17:36:09 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:5e09dc8afebb: avcodec/dfa: Check the chunk header is not truncated [17:36:10 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:807d443c7eb4: avcodec/truemotion2: Fix integer overflow in tm2_null_res_block() [17:36:11 CET] <cone-469> ffmpeg 03Carl Eugen Hoyos 07release/3.4:d31940f04e86: lavc/bmp: Avoid a heap buffer overwrite for 1bpp input. [17:36:12 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:9ccc633068c6: avcodec/hevcdec: Avoid only partly skiping duplicate first slices [17:36:13 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/3.4:0ac9001ab9f2: Update for 3.4.6 [22:21:45 CET] <cone-320> ffmpeg 03Dong, Jerry 07master:c47fada298e6: swscale/swscale_unscaled: fixed the issue that when width/height is not 2-multiple, transition of nv12 to u/v planes is not completed. [22:21:45 CET] <cone-320> ffmpeg 03Thierry Foucu 07master:0ac3befd4798: fftools/ffmpeg: Check if we do have also a filter_complex filter. [22:21:45 CET] <cone-320> ffmpeg 03Michael Niedermayer 07master:4daec0c6777a: avcodec/dxv: Check remaining space in CHECKPOINT() [22:31:16 CET] <thardin> hm XDCAM ticket [22:32:19 CET] <thardin> 3 years old even [22:49:41 CET] <cone-320> ffmpeg 03Michael Niedermayer 07master:8865ae959b18: swscale/swscale_unscaled: Fix chroma slice height [00:00:00 CET] --- Fri Mar 29 2019

1 0

ffmpeg.log.20190328
by burek 29 Mar '19

29 Mar '19

[00:09:59 CET] <retal> kepstin, i know , but i dont know that command correct usage, i found many tutorials but doest help. Thats way i am here. [00:10:06 CET] <retal> faLUCE, hi [00:10:42 CET] <faLUCE> hello retal [00:11:02 CET] <retal> faLUCE, how are you ? :) [00:11:11 CET] <faLUCE> retal: fine thanks :-) [00:11:26 CET] <retal> great ! :) [00:13:54 CET] <faLUCE> (I tried avformat_open_input(); sleep(3); avformat_flush(ic); but buffered data has not been flushed... what's wrong?) [00:14:58 CET] <retal> faLUCE, i think you remember my problem with compiling CUDA, today i fixed everything and compiled with --enable-cuda --enable-cuvid --enable-cuda-nvcc. Now i dont now wath command shuld i use for resizing scale_npp, cuda_scale or other. What the correct command for GPU resizing? [00:18:04 CET] <faLUCE> retal: wait [00:18:25 CET] <retal> :) [00:23:51 CET] <faLUCE> retal: ok, I found some options in cuviddec.c [00:24:06 CET] <retal> :) [00:24:24 CET] <faLUCE> for example, for resizing, you can just use -resize [00:24:34 CET] <faLUCE> (width)x(height) [00:25:28 CET] <retal> faLUCE, i tried it works, but you think ins using GPU acceleration ? [00:26:13 CET] <retal> its [00:26:14 CET] <faLUCE> retal: once you specify cuda for decoding it should [00:26:34 CET] <faLUCE> what is the command? [00:27:26 CET] <retal> ffmpeg -i input -vf scale=1920:960 -vcodec h264_nvenc -b:v 5M -acodec copy Output.mp4 [00:29:06 CET] <faLUCE> retal: you are not specifying nvidia for decoding [00:29:11 CET] <faLUCE> retal: look at [00:29:13 CET] <faLUCE> https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=5211 [00:29:29 CET] <faLUCE> ffmpeg.exe -y -loglevel info -c:v h264_cuvid -hwaccel nvdec -deint adaptive -resize 1920x1080 -i "[myH264_1080i.ts]" -c:v h264_nvenc -cbr true -b:v 5M -c:a aac -b:a 128k "[myresult.mp4]" [00:29:58 CET] <retal> faLUCE, thank you very much ! [00:30:11 CET] <faLUCE> yw :-) [00:30:52 CET] <retal> one more question just for knowledge. I compiled with --enable-cuda-nvcc, so next time i can compile without ? [00:31:18 CET] <faLUCE> what do you mean with "compile"? compile+ configure or compile only? [00:32:22 CET] <retal> confugue - /configure --enable-nonfree --enable-nvenc --enable-libx264 --enable-gpl --enable-cuda --enable-cuvid --enable-cuda-nvcc [00:33:04 CET] <faLUCE> retal: I mean, I don't understand the question. Where do you have to compile again that stuff? [00:33:29 CET] <furq> retal: nvcc is required for scale_cuda [00:33:41 CET] <furq> i'm not sure what -resize maps to as an nvdec option but there's no harm in keeping nvcc [00:34:24 CET] <faLUCE> furq: I checked in cuviddec.c [00:34:37 CET] <retal> furq, ok, thank you clear :) you are mi angel savior :) [00:34:41 CET] <faLUCE> furq: there's "resize" option [00:35:32 CET] <retal> resize and scale in fact doing same job under hood? I think [00:35:59 CET] <faLUCE> retal: there's not scale inside cuviddec, but I think it's inside some filter [00:36:00 CET] <furq> i would guess -resize does the same thing as scale_npp but idk [00:36:20 CET] <furq> either way try scale_cuda as well, it might be faster [00:36:39 CET] <faLUCE> anyway, in cuviddec there's "resize" [00:37:06 CET] <retal> Thank you guys! [00:37:27 CET] <retal> furq, i dont now how use scale_cuda [00:37:37 CET] <retal> doestn work [00:37:48 CET] <faLUCE> retal: it's part of the sdk, as I see [00:38:10 CET] <furq> retal: ffmpeg -h filter=scale_cuda [00:38:23 CET] <retal> may be i using wrong command [00:39:14 CET] <faLUCE> retal: then use "w" and "h" [00:39:53 CET] <faLUCE> -h filter=scale_cuda w width h height [00:39:56 CET] <faLUCE> somthing so [00:40:19 CET] <retal> les me try again [00:43:22 CET] <retal> ffmpeg -i input -vf scale_cuda=1920:1080 -vcodec h264_nvenc -b:v 5M -acodec copy Output.mp4 [00:43:24 CET] <retal> Impossible to convert between the formats supported by the filter 'graph 0 input from stream 0:0' and the filter 'auto_scaler_0' [00:43:24 CET] <retal> Error reinitializing filters! [00:43:25 CET] <retal> Failed to inject frame into filter network: Function not implemented [00:43:25 CET] <retal> Error while processing the decoded data for stream #0:0 [00:43:26 CET] <retal> Conversion failed! [00:43:47 CET] <faLUCE> retal: try with "w" and "h" [00:44:28 CET] <furq> retal: you probably need to use hwaccel for that to work [00:44:42 CET] <retal> ok [00:45:34 CET] <faLUCE> retal: did you try with w 1920 h 1080 ? [00:45:54 CET] <faLUCE> -w 1920 -h 1080, something similar... [00:49:26 CET] <retal> faLUCE, finaly found ! [00:49:31 CET] <retal> scale_cuda=-1:720 :) [00:49:36 CET] <BtbN> -2 [00:49:47 CET] <faLUCE> :-) [00:49:49 CET] <faLUCE> bbl [00:50:04 CET] <BtbN> You need to either upload your frames to the GPU, or use a decoder that decodes them right there. [00:50:43 CET] <retal> actualy i found in internet, but dont know what mean -1 in that command [00:51:06 CET] <furq> it means keep the same aspect ratio and match the other argument [00:51:19 CET] <retal> BtbN, i enabled GPU decoding -hwaccel cuvid -c:v h264_cuvid [00:51:33 CET] <retal> furq, thank you [00:51:51 CET] <furq> 1280:720 would also work fine [00:52:44 CET] <retal> furq, yeah thats also works [00:53:53 CET] <retal> Thank you wery much guys [00:53:57 CET] <retal> !!! [01:15:42 CET] <retal> Guys, i made same benchmarks with resizing i f you intrested i can show results [01:21:26 CET] <faLUCE> retal: I did not even know what is cuda until 30 mins ago [01:21:27 CET] <faLUCE> ;-) [01:21:59 CET] <retal> faLUCE, :)))))))))))))))))))))) [01:23:20 CET] <faLUCE> really [01:24:12 CET] <retal> impossible :) [01:24:17 CET] <retal> faLUCE, the interesting moment is - with scale_cuda i have 2m24sec, with scale - 2m20sec [01:25:00 CET] <retal> time ffmpeg -hwaccel cuvid -c:v h264_cuvid -i input -vf scale_cuda=-1280:720 -vcodec h264_nvenc -b:v 5M -acodec copy Output.mp4 [01:25:00 CET] <retal> real 2m24.928s [01:25:00 CET] <retal> user 0m37.019s [01:25:00 CET] <retal> sys 0m35.725s [01:25:00 CET] <retal> time ffmpeg -i input -vf scale=1280:720 -vcodec h264_nvenc -b:v 5M -acodec copy Output.mp4 [01:25:02 CET] <retal> real 2m20.570s [01:25:06 CET] <retal> user 6m43.787s [01:25:08 CET] <retal> sys 0m5.709s [01:25:52 CET] <retal> I was expecting better result from - scale_cuda [01:25:55 CET] <retal> :) [01:26:25 CET] <faLUCE> retal: did you try scale without cuda? [01:26:48 CET] <faLUCE> and did you try resize? [01:28:04 CET] <retal> 2 yeras ago i tryed it was very slow [01:28:06 CET] <retal> :) [01:28:12 CET] <furq> retal: it's worth noting one of those hit your cpu a lot harder [01:29:26 CET] <furq> at least on consumer cards, nvenc is much more about not touching your cpu than it is about outpacing your cpu [01:29:44 CET] Action: cards consume you [01:29:47 CET] <faLUCE> retal: did you try resize WITH cuda? [01:30:06 CET] <faLUCE> cards: LOL [01:30:14 CET] <retal> :))) [01:30:38 CET] <retal> faLUCE, yes ffmpeg -hwaccel cuvid -c:v h264_cuvid -i input -vf scale_cuda=-1280:720 -vcodec h264_nvenc -b:v 5M -acodec copy Output.mp4 [01:30:57 CET] <furq> retal: he means -resize [01:31:35 CET] <retal> furq, sorry i was tihink it same :) [01:33:36 CET] <retal> how use resize ? [01:36:02 CET] <faLUCE> retal: try resize with cuda dec [01:38:26 CET] <retal> ok [01:42:58 CET] <retal> faLUCE, ffmpeg -c:v h264_cuvid -hwaccel nvdec -resize 1280x720 -i input -vcodec h264_nvenc -b:v 5M -acodec copy Output.mp4 [01:43:08 CET] <retal> real 2m18.897s [01:43:08 CET] <retal> user 1m15.507s [01:43:08 CET] <retal> sys 0m11.573s [01:46:06 CET] <faLUCE> then, much better [01:47:02 CET] <faLUCE> not so much... [01:47:04 CET] <faLUCE> 6 secs [01:48:08 CET] <faLUCE> retal: what is your goal? [01:51:02 CET] <retal> faLUCE, we need transcoder. We also have transcoder in Intel VCA cards, but i dont happy with them. So i decide use GTX cards for future. Now i just testing wich command works faster ;) [01:52:44 CET] <retal> https://www.intel.com/content/www/us/en/products/servers/accelerators.html [01:52:53 CET] <faLUCE> retal: transcode from what to what? [01:55:30 CET] <retal> faLUCE, specially this server wil transcode different mp4 files with different framesizes and bitrates to 1 format 1920:1080 and bitrate [01:59:32 CET] <retal> any way, i am happy with Nvidia speed [02:00:07 CET] <faLUCE> retal: transcode means from one codec to another [02:00:25 CET] <faLUCE> or to the same codec with different params [02:00:59 CET] <faLUCE> so what interests you is the encode part [02:01:10 CET] <faLUCE> not the decode one [02:01:17 CET] <retal> faLUCE, bitrate and framesize is not different parameters ? :) [02:01:45 CET] <faLUCE> yes, but I don't understand why you are interested in decoding, if you have to transcode files [02:02:59 CET] <retal> faLUCE, i was research fast and right way to transcode :) [02:03:33 CET] <faLUCE> retal: then you have to look at the ENCODE part, not at the decode [02:03:48 CET] <faLUCE> I mean, encode is more relevant [02:04:41 CET] <retal> faLUCE, you right , i was think i can accelerate decode also i will have better result [02:05:08 CET] <retal> and make life easier for CPU [02:05:13 CET] <faLUCE> retal: you have to scale from what to what? [02:06:34 CET] <retal> faLUCE, by mistake i just deleted source file let me test with other file [02:08:06 CET] <faLUCE> in addition, you are using h264 enc without any control, instead, this is the critical part [02:12:06 CET] <retal> faLUCE, i you mean cbr, vbr , max bitrate .. i will. Now i am just testing acceleration [02:13:22 CET] <retal> faLUCE, so, just tryed ffmpeg -c:v h264_cuvid -hwaccel nvdec -resize 1920x1080 -i file -vcodec h264_nvenc -b:v 5M -acodec copy Output.mp4 [02:13:42 CET] <faLUCE> ok but you are resizing from what? [02:13:51 CET] <retal> 1280x720 to 1920 11080 [02:13:52 CET] <faLUCE> are you upscaling? [02:14:02 CET] <retal> 1920 1080 [02:14:14 CET] <retal> real 4m52.274s [02:14:15 CET] <retal> user 2m58.395s [02:14:15 CET] <retal> sys 0m18.496s [02:14:28 CET] <faLUCE> did you try x264 ? [02:14:33 CET] <retal> speed=22.7x [02:14:58 CET] <faLUCE> much will depend on the h264 presets [02:15:16 CET] <retal> with x264 will much much slower let me try [02:15:31 CET] <faLUCE> retal: you have to manage presets [02:15:42 CET] <retal> no [02:15:43 CET] <faLUCE> there's even zerolatency [02:16:00 CET] <faLUCE> with x264 you have to choose a preset [02:16:30 CET] <faLUCE> note also that speed and cpu are not the same thing for the result [02:17:25 CET] <faLUCE> what I want to say is that it is useless to do these test if you don't test the encode part firstly [02:20:30 CET] <retal> faLUCE, ffmpeg -i input -s 1920:1080 -vcodec libx264 -b:v 5M -acodec copy Output.mp4 [02:20:44 CET] <retal> speed=3.83x :)))))))))))) [02:21:01 CET] <furq> add -preset superfast [02:21:11 CET] <furq> that's something like the same quality you'll get from nvenc [02:21:37 CET] <faLUCE> furq: that is what I want to get :-) [02:21:45 CET] <faLUCE> I wanted to get [02:23:12 CET] <retal> furq, speed=9.46x [02:23:20 CET] <retal> :)) [02:23:30 CET] <faLUCE> retal: now look at the cpu [02:24:36 CET] <retal> faLUCE, i dont need CPU, i hear fan :)))))) [02:24:47 CET] <faLUCE> ?? [02:25:02 CET] <faLUCE> I mean, make a comparison for the CPU between x264 and nvidia [02:25:45 CET] <faLUCE> (then you have to check the global power consumption as well) [02:26:44 CET] <furq> you might want to try -preset slow with nvenc as well [02:27:54 CET] <faLUCE> but all these tests would not be so relevant if you don't measure the power consumption [02:28:08 CET] <retal> faLUCE, :))))) x264 very High CPU ussage, GPU speed is great. I dont care about power usage if i need transcode ~2000 files ;) [02:28:34 CET] <faLUCE> retal: high cpu with which preset? [02:29:04 CET] <faLUCE> you should care about power usage for all these files [02:29:43 CET] <faLUCE> and which percentage? [02:30:28 CET] <faLUCE> I mean: if the percentage is not overkill, then you really have to compare power consumption [02:32:56 CET] <retal> faLUCE, CPU will consume about 90w my GTX - 0% 48C P2 43W [02:33:38 CET] <retal> Even if GTX consume 150w its good for me [02:34:19 CET] <faLUCE> retal: which percentage of cpu usage ? [02:34:54 CET] <retal> ~50 [02:35:04 CET] <faLUCE> then it's not so high [02:35:17 CET] <faLUCE> then why would you prefere the gtx? [02:35:34 CET] <retal> sofor seed yes [02:35:43 CET] <faLUCE> ? [02:42:53 CET] <retal> faLUCE, with CPU i have speed=9x , with GPU speed=23x. Power usage in both cases ~45W , what metod i should prefer ? :) [02:43:24 CET] <furq> that workload will barely touch the gpu [02:43:32 CET] <furq> i'd be surprised if it even clocked up [02:43:48 CET] <faLUCE> retal: did you compare them for the SAME preset? [02:44:10 CET] <furq> the presets don't map between the two [02:44:32 CET] <faLUCE> furq: nvidia enc doesn't have presets? [02:44:39 CET] <furq> it does but they're not the same as x264 [02:44:41 CET] <retal> in GPU case i didnt use preset [02:44:44 CET] <furq> or they won't give the same quality obviously [02:44:55 CET] <furq> i think nvenc -preset slow (highest quality) is about as good as x264 -preset superfast [02:45:00 CET] <furq> but that's just something i read in here ages ago [02:45:12 CET] <furq> you'd have to do a proper comparison [02:45:35 CET] <faLUCE> yes, you have to make a proper comparison, I agree [02:45:50 CET] <faLUCE> the speed doesn't tell you much [02:46:05 CET] <faLUCE> without a precise context [02:46:24 CET] <faLUCE> you could start by setting a bitrate [02:46:28 CET] <faLUCE> (average) [02:46:43 CET] <furq> if x264 is only using 50% cpu you might want to try running two jobs simultaneously [02:46:57 CET] <furq> they ought to be a lot closer then [02:47:03 CET] <faLUCE> then use the preset that produces for both the same filesize [02:47:11 CET] <faLUCE> and compare the quality and the speed [02:47:27 CET] <retal> I dont compare visually outputs, tomorrow i will try with different presets. But dont thik they will be much diference, beacuse we are going use slow bitrate ~3mb [02:47:33 CET] <furq> you can use something libe libvmaf to do automated quality comparison [02:47:37 CET] <furq> nothing beats eyes though [02:47:47 CET] <faLUCE> and nothing beats x264 [02:47:48 CET] <faLUCE> :-) [02:47:54 CET] <furq> that too [02:48:18 CET] <faLUCE> I'm pretty sure that the x264 result would be muuuuch better than all these commercial products [02:49:25 CET] <faLUCE> retal: this is not what I intended with bitrate [02:50:02 CET] <retal> faLUCE, i totaly agree with you about x264 quality [02:50:06 CET] <faLUCE> retal you have to FORCE the bitrate to be a fixed average value [02:50:24 CET] <faLUCE> so you can produce two files with more or less the same SIZE [02:50:32 CET] <faLUCE> then compare the quality [02:50:59 CET] <retal> faLUCE, ok, it will be intresting. Tomorow i will try [02:52:11 CET] <retal> faLUCE, thank you so much bro ! [02:52:30 CET] <faLUCE> I always wonder how a small group of closed pepole, in few years can obtain the same quality of a big open source project mantained for years and years [02:52:39 CET] <faLUCE> it's impossible IMHO [02:53:28 CET] <retal> :) [03:06:38 CET] <faLUCE> is avformat_open_input() threaded? I put a big sleep(10) after it and it seems to buffer stuff even with that. Nor it seems I can flush it with avformat_flush() [03:11:36 CET] <faLUCE> https://stackoverflow.com/questions/53537270/ffmpeg-api-how-to-clear-real-t… my question is the same of that [03:11:59 CET] <faLUCE> avformat_open_input() starts reading frame.... and I don't understand how to flush it [04:00:56 CET] <dongs> hurrr what the fuck [04:01:03 CET] <dongs> to tune this S3 shit i actually need to know Stream ID [04:01:06 CET] <dongs> otherwise it doesnt evne lock [04:01:14 CET] <dongs> and i cant find where the NIT stuff is [04:01:25 CET] <dongs> JEEB: which NIT was working in your stuff? [04:02:40 CET] <dongs> trying to tune 8K directly and getting nothing but fuckoff [04:06:57 CET] <pridkett> cd-audio stereo = 1411 kbps but how is dsd-audio stereo only be 2747 kbps [04:07:15 CET] <pridkett> math doesn't add up [04:07:27 CET] <dongs> its the bits mang [04:07:29 CET] <dongs> moar bits [04:08:56 CET] <pridkett> dongs do you know how to calculate kbps [04:09:30 CET] <dongs> of what [04:09:42 CET] <pridkett> for any uncompressed audio format [04:09:45 CET] <pridkett> or video format [04:10:32 CET] <dongs> i guess? uncompressed video is like w*h*bits_per_pixel*framerate [04:10:53 CET] <dongs> DSD is that wacky 2.8mhz sampled shit right? [04:11:02 CET] <pridkett> what is "w" and "h"? [04:11:03 CET] <dongs> since its 1bit then 2847kbps sounds about right [04:11:05 CET] <dongs> or 27437 or wahtever [04:11:09 CET] <dongs> width*height [04:11:10 CET] <pridkett> yes [04:12:06 CET] <pridkett> you are right 1 x 2847 x 2 [04:12:12 CET] <pridkett> because it's stereo [04:12:29 CET] <pridkett> and you are right about video too [04:13:01 CET] <pridkett> but dsd-audio is stereo only 2747 kbps [04:14:16 CET] <pridkett> explain how that is possible [04:15:01 CET] <another> *popcorn* [04:15:09 CET] <pridkett> another explain [04:15:34 CET] <dongs> i honestly dont give a shit cuz i listen to stuff through shitty bluetooth headphones [04:15:56 CET] <pridkett> dongs so you don't care about video/audio quality at all? [04:16:12 CET] <dongs> correct [04:16:29 CET] <pridkett> dongs start caring then [04:18:31 CET] <another> pcm: 16 bit * 44100 Hz * 2 channels [04:18:44 CET] <pridkett> cd-audio stereo = 1411 kbps [04:18:53 CET] <pridkett> math adds up for that one [04:19:07 CET] <pridkett> but not for dsd-audio [04:20:29 CET] <pridkett> DSD-audio 1 bit x 2.8 mhz x 2 channels [04:22:47 CET] <dongs> then you have a mono file [04:22:54 CET] <pridkett> no, i don't [04:22:56 CET] <pridkett> i have stereo [04:22:58 CET] <dongs> how do you know [04:23:43 CET] <pridkett> Duration: 00:05:06.48, bitrate: 2692 kb/s [04:23:43 CET] <pridkett> Stream #0:0: Audio: dst (DST / 0x20545344), 352800 Hz, stereo, flt [04:24:08 CET] <pridkett> wait, that's show as DST [04:24:14 CET] <pridkett> which is compressed [04:25:51 CET] <pridkett> dongs sorry it was compressed, that's why [04:26:09 CET] <dongs> yep [04:26:34 CET] <pridkett> if album has 10 songs they compressed 5 songs but didn't compress 5 [04:26:41 CET] <pridkett> who is stupid [04:27:06 CET] <dongs> loldongs. [04:27:15 CET] <dongs> how the fuck do you even listen to this over9 000 bit DSD stuff [04:27:18 CET] <dongs> does it sound any better [04:27:32 CET] <pridkett> it's not over 9000 [04:27:49 CET] <pridkett> it's 5 645 kb/s [04:27:52 CET] <dongs> i thought it was 32767 bits [04:28:00 CET] <pridkett> 5645 kbps [04:28:43 CET] <pridkett> oh , you said 9000 bps [04:28:50 CET] <pridkett> even cd-audio is over 9000 bps [04:29:33 CET] <dongs> damnit where the fuck is this TLV-NIT table [04:30:02 CET] <pridkett> dongs what is that? [04:30:51 CET] <dongs> stuff im working on [04:31:29 CET] <pridkett> dongs who are the nice ffmpeg devs in here? and who are the mean ffmpeg devs [04:31:44 CET] <dongs> they're all pretty mean if you start talking shit about opensource not working [04:31:51 CET] <dongs> like, t hey can't take criticism [04:31:54 CET] <dongs> even if its constructive [04:31:55 CET] <pridkett> i see [04:32:10 CET] <pridkett> i am sure there are few that are nice [04:32:14 CET] <dongs> but thats literally any opensource project [04:32:27 CET] <pridkett> dongs everybody in #opus is nice [04:32:40 CET] <pridkett> which is not easy to find [04:33:19 CET] <pridkett> dongs what kind of contructive criticism did you give? [04:33:25 CET] <dongs> they have to be nice, or else their dead audio format is gonna be even more dead [04:33:39 CET] <pridkett> dongs opus is dominating in VOIP space [04:33:59 CET] Action: dongs laughs in G.729 [04:34:12 CET] <pridkett> dongs and youtube starting to use opus too [04:34:18 CET] <pridkett> what is G.729? [04:34:18 CET] <dongs> man that sucks [04:34:30 CET] <dongs> sometimes i use youtube-dl to grab jsut audio part of youtube stuff to listen to in car/whatever [04:34:44 CET] <dongs> it would really suck if opus was the only optionm [04:34:50 CET] <pridkett> and what format does it use when you do youtube-dl [04:35:02 CET] <dongs> i generally pick aac [04:35:07 CET] <pridkett> i see [04:35:18 CET] <pridkett> youtube audio quality is pretty bad though [04:35:27 CET] <pridkett> GRMrGecko welcome [04:35:36 CET] <dongs> > pretty bad [04:36:36 CET] <pridkett> the only time i downloaded song from youtube is this: https://www.youtube.com/watch?v=6kYco2Zt-cM [04:36:46 CET] <pridkett> because i have no choice [04:37:26 CET] <dongs> g729 is audio codec for voip. or at least was liek 20 years ago [04:37:32 CET] <dongs> no idea what newfag shit is now [04:37:46 CET] <dongs> i still use key system and voip to isdn converter [04:37:51 CET] <pridkett> higher quality VOIP likes to use opus [04:38:08 CET] <pridkett> i don't know about lower quality VOIP [04:42:12 CET] <pridkett> dongs i see g711u [04:42:18 CET] <pridkett> for my voip [04:42:29 CET] <dongs> thas jsut uncompressed pcm [04:42:33 CET] <dongs> 8khz/mono or wahtevef [04:42:38 CET] <pridkett> it is? [04:42:44 CET] <pridkett> let me see all my choices [04:44:13 CET] <pridkett> g711u/g711a/g729a/g723/g726-40/g726-16 : what is the best one from here [04:44:43 CET] <dongs> still all same shit [04:44:46 CET] <dongs> 8khz/mono [04:45:06 CET] <dongs> 711u is just 64kbit so anything else is below that with various terms of compression [04:45:38 CET] <dongs> 711 is 8bit samples so it takes 16bits and trims them in some math-y way to make it sound slightly better htan just truncating 16bit to 8 [04:45:54 CET] <dongs> all the other ones use some sorta lossy compression [04:46:27 CET] <pridkett> how do you know so much about VOIP compression [04:46:28 CET] <another> 711a/u is alaw/ulaw [04:46:42 CET] <dongs> another: thats the 'mathy way' part [04:46:54 CET] <dongs> of making 16bit audio samples into 8 [04:46:55 CET] <pridkett> another what is alw/ulaw mean though [04:47:11 CET] <dongs> how it converts 16bit audio samples into 8bits [04:47:13 CET] <another> wikipedia has more one that [04:48:06 CET] <another> basically it's non-linear quantization [04:48:23 CET] <another> so that human voice sound better [04:50:13 CET] <pridkett> g711u/g711a/g729a/g723/g726-40/g726-16 : what is the best one from here [04:55:57 CET] <dongs> any of the 711s [04:56:07 CET] <dongs> like i said, anything else is compressed (more than 711 [04:56:54 CET] <pridkett> okay [04:58:05 CET] <pridkett> dongs why did you type: dongs laughs in G.729 when i mentioned opus [04:59:45 CET] <dongs> becase its superior closed source payware license-needing voip codec [05:00:00 CET] <dongs> where opus is unmanaged opensource maintained by hippies [05:00:58 CET] <pridkett> so you think g729 is better than opus ? [05:01:48 CET] <dongs> no, im trolling [05:02:04 CET] <dongs> but even if opus was technically more superior, the fact that nothing supports it makes that point moot [05:02:13 CET] <dongs> like, flac is better than aac/mp3/wahtever [05:02:17 CET] <dongs> but who cares if nothing plays flac [05:02:31 CET] <pridkett> my computer plays flac fine [05:02:35 CET] <dongs> mine doesn't [05:02:55 CET] <c_14> what doesn't play opus? [05:02:57 CET] <pridkett> ffplay plays flac fine [05:03:14 CET] <c_14> everything I have plays opus just fine [05:03:25 CET] <dongs> i can't say i have a single opus audio file [05:03:26 CET] <c_14> though for some things you might have to throw it in mkv/webm [05:03:35 CET] <dongs> or even seen one [05:03:42 CET] <dongs> same goes for flac since i tend to avoid weird shit [05:04:10 CET] <dongs> JEEB: beep, im stuck here. [05:04:27 CET] <another> stuck in an argument? :D [05:04:43 CET] <another> hey c_14 [05:05:29 CET] <c_14> hey hey [05:06:15 CET] <another> gonna get a DOSE of SLEEP soon? [05:06:23 CET] <c_14> just woke up [05:07:20 CET] <fling> How to change autocrop to allow cropping borders of any color https://github.com/mpv-player/mpv/blob/master/TOOLS/lua/autocrop.lua [05:07:27 CET] <fling> eg containing logos or anything [05:07:44 CET] <fling> Like cropping non-moving parts on the sides of the video :> [05:09:58 CET] <c_14> cropdetect only does black afaik [05:10:08 CET] <c_14> you'd have to patch it to do anything else [05:11:19 CET] <fling> hmm hmmm [05:11:27 CET] <fling> Is not there anotheng tool? [05:15:48 CET] <c_14> not that I know of [05:19:51 CET] <pridkett> c_14 are you one of the top ffmpeg dev? [05:19:57 CET] <pridkett> fling are you one of the top ffmpeg dev? [05:21:03 CET] <c_14> nope [05:21:08 CET] <fling> pridkett: no, what is your question? [05:21:18 CET] <pridkett> who are the top ffmpeg dev [05:21:40 CET] <pridkett> i would like to know the hierarchy [05:23:31 CET] <pridkett> no anwer? [05:43:28 CET] <another> i'm sure you can figure it out by looking at the source [06:05:12 CET] <pridkett> another i only have the binary [06:05:15 CET] <pridkett> ffmpeg.exe [06:26:47 CET] <dongs> ok finally got 8k capture working. [06:27:12 CET] <dongs> tlv_stream_id was listed in one of the TRs [06:27:28 CET] <dongs> i wrote parser for TLV-NIT but i see no packets with it [06:27:33 CET] <dongs> or at least not where im looking [06:29:20 CET] <pridkett> dongs you have ffmpeg.exe ? [06:29:31 CET] <dongs> who doesn't [06:29:59 CET] <pridkett> people who don't use windows [06:30:16 CET] <dongs> im sure those are far and between [06:30:24 CET] <dongs> considering how windows has like 99% desktop market share [06:30:38 CET] <dongs> and the remaining 1% are probly mac idiots or statistical noise [06:30:42 CET] <pridkett> yup, windows is best OS for desktop [06:30:51 CET] <pridkett> but windows mobile is horrible [06:30:56 CET] <pridkett> mobile OS [06:31:03 CET] <pridkett> android is way way better [06:34:07 CET] <dongs> lol yeah im sure if you put it this way [06:34:36 CET] <dongs> android is undisputably garbage tho, but compared to "competition" [06:35:08 CET] <pridkett> huh? [06:35:18 CET] <pridkett> android is best mobileOS right now [06:35:27 CET] <dongs> sure, and its still garbage [06:35:32 CET] <dongs> beacuse everythign else is much, much worse [06:35:40 CET] <pridkett> then it's not garbage [06:35:43 CET] <dongs> no [06:35:53 CET] <dongs> it most definitely is [06:35:57 CET] <pridkett> what does android has to improve to satisfy you? [06:36:32 CET] <pridkett> what makes android/windows best OS is it doesn't have like 20 different distro/variation [06:36:50 CET] <dongs> 1) stop using lunix 2) stop requiring 4gb ram to open one app 3) stop using java 4) stop lazy ass coders who write apps from (2) 5) stop having 9000 different variants of the shit [06:36:53 CET] <dongs> lol wat [06:37:02 CET] <dongs> assdroid is even more fragmented than all the lunix distros [06:37:08 CET] <dongs> every retarded vendor has their own shit [06:37:29 CET] <pridkett> lunix? you mean linux? [06:37:58 CET] <pridkett> true, every vendor has their own thing that they installl, i hate that [06:45:21 CET] <pridkett> dongs i like your honesty [06:45:29 CET] <pridkett> dongs we need more people like you [06:46:30 CET] <pridkett> i think java is the slowest language; is that why you hate java [06:52:26 CET] <dongs> (4) is also a huge problem [06:52:35 CET] <dongs> typical cashgrab app these days is like 50megs instaled [06:52:41 CET] <dongs> because its written in electron or some otehr abortion [06:53:07 CET] <dongs> where you ahve one shitty hipster interpreted language being ran on top of some virtual machine to prevent hacking/cheating and which is then ran again on top of java [06:53:28 CET] <dongs> by the time you're done, you've got an app using a gig of memory to display some simple shit on screen [06:56:29 CET] <pridkett> i see, so too many apps are ram hungry [06:56:40 CET] <pridkett> what about cpu? are they CPU hungry too? [06:58:32 CET] <pridkett> fling do you agree with dongs [06:59:00 CET] <pridkett> dongs busted: you are using irssi v0.8.19 [06:59:05 CET] <pridkett> what is that about? [07:05:46 CET] <fling> pridkett: about what? [07:06:14 CET] <pridkett> fling about dongs talked about in last 2 hours [07:06:22 CET] <pridkett> or 1 hour [07:06:32 CET] <fling> I'm not going to read the log :P [07:06:52 CET] <pridkett> it's only few text [07:07:02 CET] <pridkett> nobody else was typing [07:07:06 CET] <fling> oh ok [07:07:11 CET] <fling> it is not lunix& [07:07:20 CET] <fling> Stop using linux! try free software [07:09:15 CET] <fling> pridkett: look into postmarketos as an android replacement. It is not fragmented and intended to be more like a traditional gnu distro. [07:09:36 CET] <fling> Also it has very little storage (and probably ram) footprint. [07:10:14 CET] <fling> pridkett: linux-libre is here to replace linux [07:10:29 CET] <pridkett> linux-libre? [07:10:31 CET] <pridkett> what is that [07:10:39 CET] <fling> Why are you asking things like this in #ffmpeg anyway? :P [07:11:08 CET] <pridkett> because dongs brought it up [07:11:20 CET] <fling> linux-libre is a kernel derived from linux. All the blobs are dropped, all the code is patched to not allow loading non-free firmware. [07:12:02 CET] <pridkett> by blobs? do you mean "bloat"? [07:12:36 CET] <fling> No, operational binaries embedded in the source code. [07:13:00 CET] <pridkett> can linux-libre fit on a 700M cd? [07:13:13 CET] <pridkett> because linux has become bloated [07:13:23 CET] <fling> pridkett: you are probably talkinga bout gnu. [07:13:55 CET] <pridkett> hard to find linux distro that can fit on a 700M cd [07:13:58 CET] <pridkett> these days [07:14:10 CET] <fling> pridkett: https://www.gnu.org/philosophy/words-to-avoid.html#Linux [07:16:29 CET] <fling> pridkett: I'm using gentoo on my hosts and I'm running different apps in tiny lxd containers. [07:17:34 CET] <fling> pridkett: look at the size column https://bpaste.net/show/033e77aab9dd [07:17:46 CET] <fling> pridkett: alpine gnu/linux is really small. [07:22:06 CET] <fling> pridkett: you could start with a trisquel livecd to check if it suits your needs. [07:22:29 CET] <Kuukunen> it's called linux tho :V [07:22:47 CET] <pridkett> fling is that linux-libre ? [07:23:39 CET] <fling> pridkett: https://www.fsfla.org/ikiwiki/selibre/linux-libre/ [07:23:46 CET] <Kuukunen> https://alpinelinux.org <- Alpine Linux! [07:23:54 CET] <fling> Kuukunen: https://www.gnu.org/philosophy/words-to-avoid.html#Linux [07:24:05 CET] <Kuukunen> they're wrong tho [07:24:21 CET] <fling> Kuukunen: yes [07:24:46 CET] <Kuukunen> I'm glad we agree gnu is wrong! [07:24:50 CET] <fling> haha [07:25:05 CET] <fling> or should it be busybox/linux? :P [07:25:14 CET] <fling> Kuukunen: ask at #fsf and/or #gnu [07:26:48 CET] <Kuukunen> I can assume where their opinion lies, but Alpine is clearly called "Alpine Linux" [07:27:28 CET] <fling> Kuukunen: do you understand what the linux is? [07:27:44 CET] <pridkett> linux is kernel [07:28:01 CET] <Kuukunen> yea, but also used as nane for whole distros :P [07:28:07 CET] <Kuukunen> name* [07:28:15 CET] <fling> Kuukunen: this is the problem. [07:28:17 CET] <dongs> the fact there are more than 1 "distro" means lunix has already failed [07:28:22 CET] <dongs> instead of making one thing that isn't shit [07:28:29 CET] <dongs> there are 9000 split groups making diffefent shit [07:28:43 CET] <Kuukunen> dongs: but that's also the reason why it has succeeded [07:28:55 CET] <dongs> your definiteion of "success" must be wildly different from mine [07:29:20 CET] <Kuukunen> you wouldn't have linux in bazillion places if it was tightly controlled single distro [07:29:40 CET] <dongs> i don't want it in any of those places, believe me [07:29:42 CET] <fling> if linux is a kernel then maybe you should start naming distros after OS instead? [07:30:18 CET] <fling> There is "gentoo linux" for example and linux is not even shipped by the default in stage3 which you are using to install it. [07:30:46 CET] <Kuukunen> "linux" is shorter than GNU/Linux/X [07:30:52 CET] <fling> And gentoo supports running with different kernels like freebsd's one and can also run in prefix on different oses using their kernel [07:30:56 CET] <fling> Even on windows. [07:31:14 CET] <Kuukunen> and gnu has already pretty much lost the war on naming, most people call the whole OS Linux [07:31:27 CET] <fling> so it would be wiser to call it 'gentoo gnu' or just gentoo but noone cares. [07:31:37 CET] <Kuukunen> exactly :P [07:32:11 CET] <fling> A lot of people call everything except (windows and android) as linux or even ubuntu [07:32:25 CET] <dongs> gross. [07:32:47 CET] <Kuukunen> https://en.wikipedia.org/wiki/Linux [07:32:51 CET] <fling> The page is here for a reason https://www.gnu.org/philosophy/words-to-avoid.html#Linux [07:33:10 CET] <Kuukunen> yea, but it's not really useful [07:33:45 CET] <fling> You could help improving the situation if you want ;P [07:34:30 CET] <Kuukunen> I'm trying! to unite everyone under one banner and call it just Linux! [07:34:56 CET] <fling> This channel is hilarious!! [07:35:11 CET] <fling> Can we return to the topic? [07:35:55 CET] <fling> Which branch to use if I'm going to try implementing switches for avoptions for v4l2 input devices? [07:36:34 CET] <dongs> huh, that's weird. stuff on NDxx left-polarized transponders still uses 8PSK not 16APSK [07:36:37 CET] <dongs> and bitrate is still higher [07:37:23 CET] <pridkett> dongs you are busted [07:44:14 CET] <pridkett> <another> i'm sure you can figure it out by looking at the source: i am more interested in irc name. i am guessing that will show their real name [07:44:56 CET] <pridkett> i am interested in who are the top ffmpeg dev [07:45:44 CET] <Kuukunen> (as a sidenote: lol) [07:47:06 CET] <pridkett> Kuukunen do you know? [07:47:37 CET] <dongs> the amount of people that come in here just to troll is amazing [07:47:44 CET] <dongs> there was asnother guy who had nothing but "waht if" questions that made no sense [07:47:49 CET] <dongs> like a week or two ago [07:48:04 CET] <dongs> pridkett: what are you trying t o achieve [07:48:12 CET] <dongs> will you be using ffmpeg in your work/life y/n/m [07:48:27 CET] <pridkett> dongs yes [07:48:53 CET] <pridkett> dongs who is trolling? [07:49:00 CET] <dongs> you, i think [07:49:13 CET] <pridkett> i don't understand? what am i doing? [07:51:53 CET] <pridkett> dongs i bet a lot of people use ffmpeg even by proxy [07:52:44 CET] <dongs> i dont like this kind of linux-like "usabilitiy studies" [07:53:05 CET] <dongs> "it might be in that dudes router, so he's using lunix" [07:53:16 CET] <dongs> no, he's not. and he probably hates teh shit out of that router for being slow and shit [07:53:32 CET] <pridkett> dongs you are busted [07:53:42 CET] <pridkett> you are using irssi [07:53:43 CET] <dongs> the fuck you talking about, youi repeated that sentencel ike 3 times already [07:53:45 CET] <dongs> and it still makes no sense [07:53:59 CET] <pridkett> what kind of linux hater uses irssi [07:54:15 CET] <fling> me [07:54:40 CET] <pridkett> fling that makes no sense [07:54:57 CET] <fling> I'm using irssi. I hate linux, I hate computers, I hate ffmpeg running things in single thread. [07:55:16 CET] <pridkett> linux haters should be using mirc [07:55:26 CET] <pridkett> like me [07:55:28 CET] <dongs> i fucking hate android and yet i still use it [07:55:32 CET] <fling> but mirc is a blob ;P [07:55:48 CET] <fling> And I'm not using gui. [07:56:13 CET] <pridkett> what kind of 2019 person doesn't use GUI these days [07:57:03 CET] <pridkett> dongs that's because there is nothing better than android (like you said earlier: so you have an excuse) [07:57:18 CET] <fling> This is ffmpeg support channel. Can you please stop talking about all kinds of things? :P My questions are getting lost in the flood& [07:57:36 CET] <pridkett> dongs, but as far as using irssi, you have no excuse [07:58:02 CET] <pridkett> fling sorry, but i think this is important [07:58:17 CET] <pridkett> fling feel free to repeat your question [07:58:30 CET] <fling> /query him or talk at #gnu and/or ##linux ? [07:58:56 CET] <pridkett> or repeat your question many times so it doesn't get losst: that's what i do [08:11:11 CET] <pink_mist> pridkett: and that is fucking annoying. STOP doing that. [08:11:21 CET] <pridkett> pink_mist doing what? [08:11:39 CET] <pink_mist> jesus christ, do you have the brain of an amoeba? [08:11:56 CET] <pink_mist> I was responding to your last sentence [08:12:23 CET] <pridkett> oh, but it works [08:12:33 CET] <pridkett> trying to help out my fellow fling [08:12:56 CET] <pink_mist> you're trying to make him an annoying cunt like yourself [08:13:04 CET] <pink_mist> that's not what I'd call "helping" [08:13:29 CET] <pridkett> wow, those are harsh words [08:13:49 CET] <pink_mist> you're right, they're probably a bit too harsh, so I apologise [08:14:04 CET] <pridkett> who is "they"? [08:14:09 CET] <pink_mist> and I guess I should also leave this channel for a while, give myself a timeout [08:14:16 CET] <pink_mist> ... never mind [08:14:35 CET] <pink_mist> your last line makes me reaffirm my words again [08:14:37 CET] <pink_mist> holy fuck [08:14:39 CET] <pridkett> pink_mist or just calm, don't get irc/freenode affect you too much [08:15:13 CET] <pink_mist> I'll just /ignore you, because there's no way to hold any kind of conversation with you since you don't seem to grasp language [10:03:26 CET] <another> pink_mist: behold the nick change ;) [11:34:07 CET] <AhirPK> hi, i am trying to make c application using show_volume filter [11:34:07 CET] <AhirPK> but when I push video frames and then pull from filter graph it returns AVERROR(EAGAIN) [no frames in buffer] everytime and when i pull audio frames from filter graph and convert it to jpg then it gives me output with video background like i want [11:34:07 CET] <AhirPK> but i want output in udp mutlicast stream so its not giving output in udp [11:35:16 CET] <AhirPK> filter graph: v [11:35:18 CET] <AhirPK> filter graph: https://pastebin.com/CQvcC6Nh [11:36:00 CET] <AhirPK> c code: https://www.dropbox.com/s/e6ed0ubfm759hpd/main.c?dl=0 [11:37:31 CET] <AhirPK> can anyone help me to figure out the problem? [11:37:33 CET] <AhirPK> thank you [12:35:45 CET] <faLUCE> is avformat_open_input() threaded? I put a big sleep(10) after it and it seems to buffer stuff even with that. Nor it seems I can flush it with avformat_flush() [12:50:17 CET] <pk08> faLUCE: no, avformat_open_input() not threaded [12:51:02 CET] <pk08> i need almost realtime output so i dont want to feed buffer [12:51:31 CET] <pk08> and i tried avformat_flush() but it didnt work [12:52:35 CET] <pk08> and one more thing, it returns AVERROR(EAGAIN) [no frames in buffer] every time when i pull video frame from filter graph [13:12:44 CET] <barg> I have a 3GP file MPEG-4(AVC,AAC) I want to convert it to mp4. Is this right/good ffmpeg -i input.3gp -vcodec libx264 -acodec copy output.mp4 ? [13:14:41 CET] <DHE> if you just want to convert the container, -c copy is usually all you need. or do you actually want to change the video encoding parameters? [13:15:05 CET] <barg> okay, I guess just -c copy then. Thanks [13:15:37 CET] <DHE> by specifying -vcodec libx264 you're saying you wan to have x264 transcode it, even if it's already in h264 format [13:17:12 CET] <barg> hmm, the 3gp file is quite big like 43MB and gets much smaller like 7MB when I do -vcodec libx264 [13:18:56 CET] <DHE> sure, but I suspect you're losing a lot of image quality there since you're getting transcode defaults which are fixed values [13:28:05 CET] <faLUCE> pk08: I don't understand why it's not possible to flush it after opening with that function [13:31:38 CET] <faLUCE> pk08: of course the muxer can be opened with avformat_alloc_output_context2() and custom I/O, but I would like to see if I can reduce the latency of ffplay, which uses avformat_open_input() [13:33:54 CET] <ammen99_> Hello guys, I am developing a simple recording application and I use ffmpeg for encoding. However, in some setups there is a crash (bt can be found here: https://github.com/ammen99/wf-recorder/issues/13) Have any of you had similar issues or any ideas what I might be doing wrong? [13:34:13 CET] <dongs> > vaapi haha [13:34:18 CET] <dongs> found your problem [13:40:16 CET] <ammen99_> dongs: it actually works on at least 4 different setups :) [16:10:32 CET] <aboxer_> if ffprobe does not mention that a video stream is progressive, does this mean it is interlaced ? [16:11:44 CET] <DHE> ffprobe $INPUT_FILE -show_frames | grep interlace [16:11:52 CET] <DHE> you'll want to CTRL+C it at some point [16:12:42 CET] <aboxer_> DHE thanks! [16:14:21 CET] <aboxer_> DHE: interlaced_frame=0 means progressive ? [16:14:34 CET] <aboxer_> and =1 is interlaced ? [17:52:40 CET] <Corin-EU> If anybody has administration privileges on the FFMPEG web site front page, please note that the big green DOWNLOAD button is linked to the old version v4.1 and not the latest version v4.1.2 despite the label on the button. Thank you for your attention. [17:55:51 CET] <furq> even worse, it's using bz2 in 2019 [18:01:26 CET] <Corin-EU> furq: on the actual releases directory listing page "http://ffmpeg.org/releases/" there are in fact gz, bz2, and xz archives of the latest versions [18:02:07 CET] <JEEB> Corin-EU: there's a patch to fix that on the ml [18:02:15 CET] <JEEB> so prolly will get fixed soon [18:02:47 CET] <Corin-EU> JEEB: okay, so long as somebody is aware about it. [18:03:24 CET] <Corin-EU> Just does not look good for ffmpeg if people use the convenient big green button and then find it is an old version. [18:06:40 CET] <Corin-EU> Be seeing you ....... [19:52:47 CET] <pkeroulas_> hello, I'm using libx264 for a streaming application, no file transcoding. The passlogfile is getting really large after a while (10GB/day) and eventually ffmpeg will fail "error: ratecontrol_init: can't open stats file". Is there any way to get rid of it? [19:53:15 CET] <JEEB> why are you even using multipass encoding? [19:53:19 CET] <JEEB> just don't set -pass X [19:53:37 CET] <JEEB> since you're never going to go over the stream input again [19:53:54 CET] <JEEB> which is for what the pass file is for [20:00:46 CET] <pkeroulas_> JEEB, you're right, I don't know why but I thought -pass was mandatory... [20:01:01 CET] <JEEB> nope [20:01:05 CET] <pkeroulas_> thanks [20:01:07 CET] <JEEB> specifically utilized for multipass encoding [22:31:13 CET] <faLUCE> is there a way to know if output is available before calling av_read_frame() ? [22:31:26 CET] <faLUCE> (so I can have it non-blocking) [22:49:01 CET] <kepstin> faLUCE: no. I suggest using threads instead. [22:52:18 CET] <faLUCE> kepstin: I was thinking about while (avio_read(s->pb, buf, 100) >= 0) as a way to flush the buffer [22:52:52 CET] <kepstin> well, there might be some configurations where the underlying io can run in non-blocking mode, and then av_read_frame() will return AVERROR(EAGAIN) rather than a packet. [22:53:01 CET] <kepstin> not sure exactly what makes that occur [22:54:29 CET] <faLUCE> kepstin: already checked that, it seems that non blocking is not allowed for files and lot of other stuff [22:54:48 CET] <faLUCE> then I was thinking about flushing the buffer in the way just described [22:55:16 CET] <kepstin> yeah, that's probably down to whether the os provides interfaces for it. linux doesn't have non-blocking file io at the kernel level, for example. (it's basically all simulated with threads) [22:56:03 CET] <kepstin> I'm not sure what you'rd doing, flushing the buffer seems like the opposite of checking if you could read a packet? [22:56:30 CET] <kepstin> if you flush the buffer, then you lose data, so it's gonna be corrupt input or have to resync, so it'll block longer... [22:56:37 CET] <faLUCE> kepstin: my goal is to flush the buffer and loose data [22:56:49 CET] <faLUCE> and I really don't know if is there a way to do that [22:56:57 CET] <kepstin> why do you want to do that? [22:57:22 CET] <faLUCE> kepstin: because I'm trying to patch ffplay. It buffers stuff before demuxing packets [22:57:33 CET] <faLUCE> even with -fflags nobuffer [22:57:58 CET] <faLUCE> kepstin: this because avformat_open_input() doesn't return immediatly [22:58:02 CET] <faLUCE> then it buffers stuff [22:58:48 CET] <kepstin> ah, so your problem specifically is that you want to discard the data buffered during probing so you can "catch up" to realtime? [22:59:01 CET] <faLUCE> kepstin: yes, perfect [22:59:21 CET] <faLUCE> kepstin: with custom avio I can avoid that [22:59:26 CET] <kepstin> solution is to just call av_read_frame as fast as possible until it starts blocking, i guess :/ [22:59:40 CET] <faLUCE> kepstin: not possible [23:01:14 CET] <faLUCE> kepstin: the weird thing is that avformat_flush() doesn't have any effect [23:03:55 CET] <kepstin> the docs for avformat_flush have a note that might help you there [23:05:55 CET] <faLUCE> kepstin: I called avio_flush as well [23:05:58 CET] <faLUCE> no effect [23:08:16 CET] <faLUCE> it's very strange that there's not a way to flush this stuff [00:00:00 CET] --- Fri Mar 29 2019

1 0

ffmpeg-devel.log.20190327
by burek 28 Mar '19

28 Mar '19

[01:17:31 CET] <cone-099> ffmpeg 03Decai Lin 07master:ec1e4a8baf1b: lavc/h264_levels: add MaxMBPS checking and update fate test. [03:33:42 CET] <Cldfire> Hello all o/ I'm a student interested in the opencl video filter GSoC project and I am stopping by to ask if anyone has any recommendations for which existing CPU filter to implement in opencl (or, as the qualification task description states, any other filter) beyond simply looking through the existing CPU filters and picking one that looks reason [03:33:42 CET] <Cldfire> ably straightforward [03:34:21 CET] <Cldfire> I also want to make sure I'm not stepping on anyone else's toes and starting on something that's already being worked on by another applicant [03:34:51 CET] <Cldfire> jkqxz, ping in regard to the above since you are listed as the mentor :) [07:57:46 CET] <cone-862> ffmpeg 03Lauri Kasanen 07master:81a4719d8eaf: swscale: Remove duplicated code [08:02:27 CET] <cone-862> ffmpeg 03Lauri Kasanen 07master:681957b88d18: swscale/ppc: VSX-optimize yuv2rgb_full [08:45:19 CET] <cone-862> ffmpeg 03Michael Niedermayer 07master:54655623a826: avcodec/hevcdec: Avoid only partly skiping duplicate first slices [10:37:20 CET] <thardin> this m264 guy is relentless [10:52:52 CET] <kurosu> His bonus depends on it [11:05:06 CET] <thardin> ooh already someone interested in AVIF [11:06:06 CET] <JEEB> I think it's a similar mess to HEIF [11:06:17 CET] <nevcairiel> it is HEIF [11:06:19 CET] <JEEB> basically HEIF with the codec as AV1 [11:06:23 CET] <JEEB> yup [11:07:06 CET] <nevcairiel> at least they didnt make a new spec entirely, but that doesnt solve the mess that is HEIF regardless [11:07:38 CET] <JEEB> true [11:08:47 CET] <thardin> sounds like I'm unwittingly getting myself into a bit of a mess [11:09:54 CET] <nevcairiel> the format is just absolutely overengineered, typical example of design by comitee [11:10:07 CET] <nevcairiel> committee* [11:10:10 CET] <thardin> so HEIF is just another word for stuffing an H.265 I-frame in a MOV [11:10:46 CET] <nevcairiel> if it was only so simple [11:12:09 CET] <thardin> either way, the AVIF task is a superset of the HEIF task [11:14:34 CET] <thardin> "Storage of still images as well as collection of images in a single container file, Storage of burst photos, Storage and efficient representation of video animations and cinemagraphs. Support for simultaneous capture of video and still images, i.e. storing still images and timed image sequences into the same file." [11:14:39 CET] <thardin> fun [11:15:39 CET] <nevcairiel> they also have a container-level tiling scheme, which for our component seperation is really no fun [11:18:02 CET] <thardin> madness [11:18:19 CET] <thardin> that kind of stuff can be done by svg [11:39:27 CET] <thardin> so I have to guy buy an empty sim card just to register a throwaway google account. unbelievable [11:57:08 CET] <JEEB> thardin: yea they really want your # these days >_> [13:02:58 CET] <thardin> jokes on them, I have everything segregated into a bajillion accounts [13:03:55 CET] <JEEB> if you use firefox you can also utilize tab containers [13:04:04 CET] <JEEB> to limit specific sites into specific groups of tabs [13:04:08 CET] <JEEB> which then have their own storage etc [13:04:26 CET] <thardin> I use umatrix [13:04:30 CET] <JEEB> :) [13:04:41 CET] <thardin> so by default it never pulls in anything except 1st party media and css [13:04:53 CET] <JEEB> yea, they started adding settings for that in firefox as well [13:05:01 CET] <JEEB> content blocking, cookie etc blocking [13:05:04 CET] <thardin> and with certain garbage sites like twitter, not even the css [13:05:13 CET] <thardin> yeah firefox has been a lot better lately [13:05:18 CET] <thardin> still doing some nonsense like the pocket thing [13:05:25 CET] <thardin> and cloudflare mitm dns [13:05:29 CET] <JEEB> I wish they'd actually advertise stuff like tab containers [13:05:31 CET] <thardin> and drm [13:05:36 CET] <JEEB> because that's actually a nice feature [13:05:46 CET] <JEEB> right now it's disabled by default unless you install an add-on that requires it [13:05:49 CET] <JEEB> :< [13:06:08 CET] <JEEB> (and then there's add-ons that limit f.ex. facebook and google etc into their little containers) [13:06:18 CET] <JEEB> the generic idea works without specific add-ons though [13:06:23 CET] <JEEB> just that the feature needs to be enabled [13:12:12 CET] <thardin> another roundabout way of doing it is having multiple users on the same machine [13:12:18 CET] <thardin> or VMs [13:50:25 CET] <thealakazam> Hello, I've been trying to work on the GSOC topic on getting HEIF support for ffmpeg, it mentions making a trivial muxer, what's that about [13:55:28 CET] <thardin> thealakazam: muxer is short for multiplexer [13:55:50 CET] <thardin> in other words the libavformat part of the output (not the codec stuff) [13:57:04 CET] <thardin> carl should be in here [14:00:11 CET] <thealakazam> Oh, thanks i got confused whether it should go in the codec part or format part, so it should enable me to write to a heif file, i guess [14:00:58 CET] <thardin> are you the guy who emailed me about avif? [14:03:10 CET] <thealakazam> no [14:05:42 CET] <thardin> k. the formats are related [14:06:45 CET] <thealakazam> can you clear what the trivial part means [14:16:16 CET] <thardin> thealakazam: probably only writing an HEIF file that is a regular old static image [14:17:11 CET] <thardin> instead of those other things HEIF can do, like multiple images, tiling, burst photos, combining video and stills etc. [14:17:36 CET] <thardin> a demuxer would potentially have to deal with all that [14:18:08 CET] <thealakazam> ok thanks for clarifying [14:54:52 CET] <cone-749> ffmpeg 03Carl Eugen Hoyos 07master:6bc800dead1e: lavf/latmenc: Return the correct error for wrong codec. [14:57:15 CET] <nevcairiel> writing files has the advantage that you get to pick which features you want to s upport [14:57:23 CET] <nevcairiel> which can be as simple as one can make it [14:57:42 CET] <nevcairiel> reading on the other hand has to support all features, so that files made with other tools actually work [14:59:34 CET] <thardin> yeah [16:30:50 CET] <nevcairiel> anyone feel like SIMDing sws yuv2nv12cX_c? my head hurts trying to think about it, it should be similar to yuv2planeX_8_c which has SIMD already [17:41:29 CET] <BtbN> Did apple seriously just remove mjpeg support from their OS? [17:41:41 CET] <BtbN> Os is "Motion JPEG A und B" something else? [18:39:51 CET] <cone-749> ffmpeg 03Michael Niedermayer 07release/4.0:d34202f4f036: avcodec/truemotion2: Fix integer overflow in tm2_null_res_block() [18:39:52 CET] <cone-749> ffmpeg 03Michael Niedermayer 07release/4.0:530286c96bd8: avformat/mov: Fix potential integer overflow in entry check in mov_read_trun() [18:39:53 CET] <cone-749> ffmpeg 03Michael Niedermayer 07release/4.0:1d44fab8c3c4: avcodec/mpegpicture: Check size of edge_emu_buffer [18:39:54 CET] <cone-749> ffmpeg 03Carl Eugen Hoyos 07release/4.0:c877b329054d: lavc/bmp: Avoid a heap buffer overwrite for 1bpp input. [18:39:55 CET] <cone-749> ffmpeg 03Michael Niedermayer 07release/4.0:494ce3da24b6: avcodec/hevcdec: Avoid only partly skiping duplicate first slices [18:39:56 CET] <cone-749> ffmpeg 03Michael Niedermayer 07release/4.0:ee66e04bc9db: Changelog: update [18:41:28 CET] <BradleyS> BtbN: sure did [18:41:38 CET] <BradleyS> all the more reason for oss [19:23:39 CET] <lrusak_> jkqxz: excuse my lack of knowledge about this. but is it possible to implement a decoder that uses the hwaccel interface but requires full frames rather than slices? [19:24:27 CET] <lrusak_> if not, is it possible to rebuild the full frame from the slices so it can be passed to the hw decoder? [19:25:15 CET] <nevcairiel> the start_frame callback gets passed the entire frame buffer [19:25:45 CET] <nevcairiel> but such a decoder still needs to act like any of the o ther slice decoders - that is, only decode the image, not doing any re-ordering or any of that stuff [19:31:05 CET] <lrusak_> nevcairiel: so can i just implement start_frame and end_frame and ignore decode_params and decode_slice? [20:47:05 CET] <philipl> lrusak_: you need to implement a stub decode_slice. You can see this being done in many of the existing hwaccels. [20:54:07 CET] <lrusak_> philipl: thanks, I'll have a look, can you think of any specific examples? [20:58:07 CET] <lrusak_> ah, maybe something like ff_nvdec_simple_decode_slice ?? [22:51:46 CET] <nevcairiel> BtbN: do you have any insight into how well spatial-aq/temporal-aq work in nvenc, quality wise? [22:52:19 CET] <BtbN> better with every generation, supposedly really good starting with Turing [22:52:38 CET] <BtbN> Like, a bunch of people claim it's better than x264 now, but I have high doubts about that. [22:52:45 CET] <BtbN> though that's about general quality [22:53:21 CET] <nevcairiel> beating x264 at a preset with similar speed on an average cpu is probably fine [22:53:34 CET] <nevcairiel> but of course x264 can go slower, nvenc cant [22:54:06 CET] <BtbN> For streaming, nvenc on Turing is really good it seems [22:54:24 CET] <nevcairiel> i got me a 1660 now to put into my streaming server [22:54:28 CET] <BtbN> though all the "Look how good nvenc looks" streams I have seen so far were obviously horrible. [22:55:25 CET] <nevcairiel> just trying to fine tune nvenc settings, that is (a) for my card specifically, but also (b) for the general public [22:55:51 CET] <nevcairiel> might need a few checkboxes maybe [22:57:12 CET] <nevcairiel> (also, the code boilerplate just to get a nvenc session to probe capabilities is really quite a lot, so instead i hacked the local copy of ffmpeg to make it just disable unsupported features instead of error out) [23:32:27 CET] <cone-552> ffmpeg 03Mark Thompson 07master:d0b174d7df88: configure: Do not enable both OpenCL-VAAPI interop modes simultaneously [23:56:25 CET] <jamrial> jkqxz: take a look at my cbs patches when you can [00:00:00 CET] --- Thu Mar 28 2019

1 0

ffmpeg.log.20190327
by burek 28 Mar '19

28 Mar '19

[01:53:18 CET] <net|> ffmpeg -y -i /dev/video1 -c:v libvpx -pix_fmt yuv420p -video_size 1280x720 -quality realtime -speed 5 -threads 2 -crf 10 -segment_time 00:00:40 -c:a libvorbis -f pulse -ac 2 -i default -f segment -reset_timestamps 1 ./authd/output%01d.webm when i try this it says default no such process [01:53:40 CET] <net|> ffmpeg -video_size 1024x768 -framerate 25 -i /dev/video1 -f pulse -ac 2 -i default output.mkv this works though [01:56:19 CET] <another> try putting the inputs before any output options [01:57:25 CET] <another> because the order matters [02:03:39 CET] <furq> some of those are input options [02:03:50 CET] <furq> -video_size needs to be before -i /dev/video1 for starters [03:28:12 CET] <net|> furq i found that on https://trac.ffmpeg.org/wiki/Capture/Desktop [03:31:25 CET] <furq> yeah that one is fine [03:31:28 CET] <furq> the other command you posted is all wrong [03:32:17 CET] <furq> ffmpeg [input1 options] -i input1 [input2 options] -i input2 [output1 options] output1 [output2 options] output2 [03:32:20 CET] <furq> etc [04:11:53 CET] <net|> ffmpeg -y -i /dev/video0 -c:v libvpx -crf 10 -c:a libvorbis -f pulse -ac 2 -i default -fs 1M output.webm says same thing here default no such process [05:03:06 CET] <another> net|: you're command line is still wrong. see furq's comment above [05:07:04 CET] <another> ffmpeg -i /dev/video0 -f pulse -ac 2 -i default -c:v .... -c:a ... output.webm [05:23:43 CET] <net|> that worked good, its a little choppy but i might be able to do something with it [16:24:42 CET] <intrac> is there a way to get ffmpeg to quit if it doesn't receive any more data over an rtsp stream in a given timeframe? [16:25:13 CET] <intrac> (but the connection may remain open) [16:26:25 CET] <JEEB> I think RTSP goes down towards UDP or TCP, so you'd have to check if the I/O timeout goes towards that. TCP I think has a timeout by default? UDP has a value of zero set by default, which maens it will just sit there even if it doesn't get any bits in [16:29:26 CET] <intrac> I'm using the -rtsp_transport tcp flag, so I don't know if that changes anything. [16:29:50 CET] <intrac> I'll need to get wireshark running and see what's actually going on. [16:32:09 CET] <intrac> I've just noticed there's a stimeout 'Set socket TCP I/O timeout in microseconds.' [16:32:13 CET] <intrac> will give that a try [17:08:40 CET] <faLUCE> is there a way to make ffplay to NOT sync audio and video ? [17:16:46 CET] <kepstin> faLUCE: why do you want to do that? [17:18:05 CET] <kepstin> i mean, if you really want to desync your audio and video, you could always throw a setpts filter in there to offset one of the streams :) [17:18:30 CET] <faLUCE> kepstin: I want to display audio + video frames got with udp as soon as they arrive [17:18:50 CET] <kepstin> ok, so that's a different thing from synced audio and video [17:19:07 CET] <faLUCE> kepstin: in fact I asked about ffplay.... [17:19:09 CET] <faLUCE> not ffmpeg... [17:19:15 CET] <kepstin> i assume you still want the audio and video to be matched up, you just want them to play at the speed when packets arrive? [17:19:21 CET] <faLUCE> kepstin: yes [17:19:21 CET] <kepstin> ffplay can use filters. [17:20:05 CET] <faLUCE> kepstin: so do I have to use the setpts filter for ffplay too? [17:20:05 CET] <kepstin> faLUCE: ok, there is an ffplay option to cause it to play inputs at the speed they're received. Use "-sync ext" [17:20:25 CET] <kepstin> faLUCE: no, why would you do that? that would cause your audio and video not to be synced. [17:20:52 CET] <aruns> Hi, is it possible to remove a solid background from an MP4 so that it is transparent? [17:21:22 CET] <faLUCE> kepstin: I don't want to play inputs at the speed they're received... I want that audio and video must be indipendent [17:21:34 CET] <faLUCE> so that I can play as soon as they arrive [17:21:50 CET] <kepstin> faLUCE: ffplay does not support that. Run two separate players or use a different player or write a player yourself. [17:22:16 CET] <kepstin> faLUCE: ffplay does support playing inputs at the speed they arrive, but keeps audio and video aligned according to relative timestamps. [17:22:57 CET] <faLUCE> kepstin: I thought there was a way to avoid that... with gstreamer I could made two indipendent subpipes from the same source [17:23:14 CET] <kepstin> faLUCE: sure, but ffplay is a simple demo player not intended for any production use [17:23:43 CET] <kepstin> faLUCE: and this is a weird circumstance to start with, so general players won't do it :/ [17:23:47 CET] <faLUCE> kepstin: I see... unfortunately other players don't seem to support that [17:24:00 CET] <faLUCE> kepstin: yes... that's the problem :-( [17:24:00 CET] <kepstin> players put a lot of effort into making sure the audio and video *are* in sync [17:24:42 CET] <kepstin> aruns: https://www.ffmpeg.org/ffmpeg-filters.html#colorkey [17:25:20 CET] <kepstin> aruns: note that very few video codecs can save transparent video, so this is mostly useful if you're doing overlays within a single ffmpeg command. [17:25:27 CET] <faLUCE> kepstin: ok, I could arrange to play two indipendent streams with two ffplay instances. For audio, I don't have any buffer with -fflags nobuffer, but for video it seems that I still have some buffer even with that option [17:26:13 CET] <kepstin> faLUCE: check your encoder settings - if you're using b-frames then the decoder needs a reorder buffer? [17:26:15 CET] <faLUCE> (but I could be wrong, let me check again) [17:26:27 CET] <JEEB> slice threads should take care of decoder delay unless there's b-frames [17:26:28 CET] <faLUCE> kepstin: I set b-frames to 0 [17:26:32 CET] <kepstin> faLUCE: also note that ffplay is kinda iffy on buffer configuration. [17:26:39 CET] <faLUCE> let me check, I could be wrong [17:26:53 CET] <JEEB> as opposed to frame threads which are faster but incur latency [17:27:01 CET] <JEEB> (and thus default) [17:31:03 CET] <faLUCE> kepstin: just checked. I set max_b_frames=0, but ffprobe shows that video packets are collected with some delay. I don't have that delay with audio packets [17:31:18 CET] <faLUCE> I don't know if it's a udp buffer size [20:51:00 CET] <retal> faLUCE, hi [20:51:50 CET] <retal> finally i installed cuda from scatch and compile with --enable-cuda-nvcc [20:53:04 CET] <retal> but didnt found how to use nvcc for resizing [20:56:20 CET] <BtbN> scale_cuda should be pretty selfexplanatory [21:03:36 CET] <retal> BtbN, tryng -vf scale_cuda=1920:1080 , but recieve error [21:31:25 CET] <retal> Guys, how to use cuda scale ? [21:31:53 CET] <retal> my ffmpeg compiled with cuda-nvcc [21:48:37 CET] <BtbN> With the lack of information, it pretty much boils down to "by using it correctly" [22:04:12 CET] <retal> BtbN, thank you for help [22:07:15 CET] <kepstin> retal: sometimes when you read errors, they'll tell you about what's going wrong. [23:02:54 CET] <faLUCE> is it possible to force the input format of ffplay to mpegts + h264, so it doesn't have to probe it? [23:03:38 CET] <faLUCE> there are lot of options while grepping "format", so I don't understand which one to use [23:09:24 CET] <DHE> I'm going to guess no. while you can use '-f mpegts' I don't think it'll speed it up that much when avformat's input detection fires anyway and wants to read enough audio and video to produce one of those info screens you normally see in ffmpeg/ffprobe output [23:09:25 CET] <faLUCE> I tried with "ffplay -fflags nobuffer -f mpegts -codec h264 " <--- format is accepted but the "-codec h264" is not recognized [23:10:02 CET] <faLUCE> DHE: the problem is that with probe_info I have one frame latency [23:10:11 CET] <faLUCE> (for h264) [23:10:17 CET] <faLUCE> I wonder if is there a way to avoid that [23:12:12 CET] <DHE> wouldn't rely on it for mpegts. the PAT & PMT only come periodically, so if you're joining a live stream you may have playable content but no codec info yet. not sure how the demuxer handles that... [23:53:56 CET] <faLUCE> DHE: thnks [23:54:37 CET] <faLUCE> well, I'm seeing that avformat_open_input() (demuxing) buffers input data and doesn't return immediatly. Is there away to avoid that? [23:55:24 CET] <faLUCE> at least, is there a way to flush the buffer? [23:55:42 CET] <faLUCE> (without allocating a custom aviocontext) [00:00:00 CET] --- Thu Mar 28 2019

1 0

ffmpeg-devel.log.20190326
by burek 27 Mar '19

27 Mar '19

[00:00:20 CET] <cone-203> ffmpeg 03James Almer 07release/4.1:abf36b76de63: avcodec/av1_parser: don't abort parsing the first frame if extradata parsing fails [00:00:21 CET] <cone-203> ffmpeg 03James Almer 07release/4.1:6972b353b4e0: avcodec/cbs_av1: fix range of values for Mastering Display Color Volume Metadata OBUs [03:04:05 CET] <giggybyte> gotcha, thanks for the information. i'll take a look at the other suggestions, then [10:15:39 CET] <thardin> grmbl google [10:17:50 CET] <thardin> maybe I can give them the hackerspace's address [10:19:15 CET] <nevcairiel> durandal_1707: i found an issue with your cached bitstream reader, specifically get_bits_le just doesn't work, i have a UtVideo file thats broken due to that, disabling cached reader makes it work. Any thoughts? [10:21:16 CET] <nevcairiel> (here is a sample file that is affected: https://files.1f0.de/samples/ut-test-t2-umrg.mkv) [10:25:20 CET] <nevcairiel> As I understand the code, the problem is that get_bits_le in the old code also refills using AV_RL, but the new reader always refills with AV_RB, so it has the bytes in a different order. [10:29:42 CET] <durandal_1707> nevcairiel: on it [10:32:49 CET] <kurosu> is there a place where it works? (not being sarcastic, just wondering if it is a specific condition) [10:32:53 CET] <kurosu> though if durandal_1707 is on it [10:33:25 CET] <nevcairiel> get_bits_le is extremely rarely used in our code [10:33:32 CET] <nevcairiel> only in like 2-3 obscure formats, and utvideo [10:34:03 CET] <nevcairiel> and I dont think it can work right now [10:34:59 CET] <kurosu> might be a refill problem that is cpu-dependent rather than codec-dependent (ie _le should invoke the _le refill?) [10:35:04 CET] <kurosu> can't try atm [10:35:33 CET] <nevcairiel> i dont know if its expected that you can mix get_bits and get_bits_le on the same reader [10:35:36 CET] <nevcairiel> in the old one you can [10:35:50 CET] <nevcairiel> in the new one, that might be very problematic if you j ust change the refill [10:36:04 CET] <nevcairiel> unless you keep track of which method you filled with and then purge and re-fill again if it changes [10:36:08 CET] <durandal_1707> no code does combination [10:36:21 CET] <durandal_1707> and should not do it anyway [14:02:15 CET] <cone-892> ffmpeg 03Jun Zhao 07master:e9c9514ce37c: avformat/avformat.h: Update the comment for AVInputFormat.flags [15:38:45 CET] <nevcairiel> man why do we not have a multithreaded software scaler, this is really holding up my flow here [15:45:44 CET] <atomnuker> but we do, just slice the frame yourself and run Nx swscale instances in separate threads [15:46:00 CET] <nevcairiel> last i tried, that didnt work for shit [15:46:15 CET] <nevcairiel> admittedly its been a while ago [15:46:20 CET] <atomnuker> you tried that!?! [15:46:44 CET] <atomnuker> without caring about potential blocking artifacts? [15:47:48 CET] <BBB> atomnuker doing a pirouette [15:48:30 CET] <nevcairiel> back then it just resulted in a lot of nonsense [15:48:46 CET] <nevcairiel> but maybe it was improved since then, i faintly remember reading something about it [15:48:51 CET] <nevcairiel> but apparently its still crap then? [15:50:55 CET] <rcombs> atomnuker: I mean if you frame-threaded it'd be fine [15:51:33 CET] <nevcairiel> I might be ok with a slight delay in this use-case, but its harder to implement as well [15:51:51 CET] <nevcairiel> i should probably favor hardware scaling, since its hardware encoding anyway [15:52:07 CET] <nevcairiel> only that i need to write a d3d11 scaler then, and i was lazy about that [15:52:32 CET] <JEEB> libplacebo or so? [15:52:43 CET] <JEEB> then use shaderc to compile to HLSL [15:52:45 CET] <JEEB> :V [15:52:52 CET] <nevcairiel> i'm fine with the fixed function d3d11 scaling [15:52:55 CET] <JEEB> :) [15:52:56 CET] <nevcairiel> can also hook up deint then [15:53:15 CET] <atomnuker> write vulkan import export for d3d11 [16:17:13 CET] <atomnuker> I'm impressed, a 53mb total vp9 beats a 140mb h264+aac for a 640x360 video [16:17:26 CET] <atomnuker> on youtube [16:18:21 CET] <atomnuker> oh wow there's an av1 version as well, nevermind, I'll watch that [17:09:20 CET] <rcombs> nevcairiel: what are you encoding with anyway [17:09:42 CET] <rcombs> (just curious about hardware pipelines on windows, since they're historically pretty awkward) [17:09:54 CET] <nevcairiel> d3d11 -> nvenc pipeline works pretty well [17:10:26 CET] <nevcairiel> but its really the only full hardware pipeline i care to support, qsv d3d11 support is broken [17:10:28 CET] <rcombs> can't use scale_cuda? [17:10:44 CET] <nevcairiel> cuda filters are nonfree at this time [17:10:50 CET] <gnafu> atomnuker: I was watching a video the other day that looked really rough in AV1, so I checked out other versions. It was even worse in VP9, but nearly unwatchable in H.264. [17:11:09 CET] <gnafu> Didn't look good in any version, though. [17:11:11 CET] <rcombs> wait, the filters are nonfree but the encoder isn't? [17:11:23 CET] <nevcairiel> yes, because of the cuda compiler [17:12:18 CET] <rcombs> huh [17:13:32 CET] <nevcairiel> right now i'm trying to figure out if supporting qsv is generally worth it, the ffmpeg encoder seems to be in a somewhat questionable state [17:15:28 CET] <rcombs> I dunno your use case but generally intel's stuff is stupidly fast [17:16:23 CET] <nevcairiel> Yeah that part is fine [17:16:57 CET] <nevcairiel> but the ffmpeg implementation is so bad, it has no runtime feature probing at all, the sdk you build with determines hardware support, which is just stupid [17:19:18 CET] <nevcairiel> i should probably round up a few older intel systems and see if i can figure out some way to make it work on them [17:19:52 CET] <nevcairiel> after i finished tweaking the nvenc stuff i guess [17:22:19 CET] <nevcairiel> maybe also figure out how the amd stuff works, although i dont think i have any hardware for that, so meh [19:21:12 CET] <lotharkript> durandal_1707: I was told you may know this answer: Should the output of a filtercomplex vs vf behave the same when using fps filter and vsync? [19:29:06 CET] <BtbN> It's just different cli syntax, the create instances of the exact same filters. [19:29:10 CET] <BtbN> *they [19:34:49 CET] <lotharkript> BtbN: we found a difference between -filtercomplex fps=fps=60 -vsync 1 and -vf fps=fps=60 -vsync 1. Looking at the code, it seems there is a path being executed with filtercomplex, but not with vf: see https://github.com/FFmpeg/FFmpeg/blob/master/fftools/ffmpeg.c#L1080 [19:35:07 CET] <BtbN> vsync is a horrible hack iirc, and it wouldn't surprise me [19:35:41 CET] <lotharkript> because the filter does not change the AVframe duration, the hack is using it for vsync [19:35:58 CET] <lotharkript> so, should the FPS filter update the AVFrame.duration field? [19:40:51 CET] <BtbN> Only the timestamps really matter anyway [21:16:46 CET] <cone-867> ffmpeg 03Carl Eugen Hoyos 07master:1e34014010db: lavc/bmp: Avoid a heap buffer overwrite for 1bpp input. [22:07:57 CET] <lotharkript> BtbN: I agreed that TimeStamp should matter , but looking at this code: https://github.com/FFmpeg/FFmpeg/blob/master/fftools/ffmpeg.c#L1080 they are using the AVFrame Duration, which is incorrect when we use FPS filter [00:00:00 CET] --- Wed Mar 27 2019

1 0

ffmpeg.log.20190326
by burek 27 Mar '19

27 Mar '19

[01:28:51 CET] <damdai> does ffmpeg support converting 5.1 to stereo ? [03:02:57 CET] <another> damdai: https://trac.ffmpeg.org/wiki/AudioChannelManipulation#a5.1stereo [14:04:34 CET] <faLUCE> hello all [15:19:36 CET] <iank> im doing a picture in picture of 2 vids with ffmpeg (for libreplanet conference),. i want the resulting video to be 24fps. here's the command i've got so far. ffmpeg -i libreplanet2019-room-123_2019-03-23_09-50-48.webm -i libreplanet2019-slides-123_2019-03-23_09-46-26.webm -filter_complex "[0]scale=iw/3:ih/3 [pip]; [1][pip] overlay=main_w-overlay_w-10:main_h-overlay_h-10" -vcodec libvpx-vp9 -to 15 output.webm [15:20:07 CET] <iank> er, accidentally hit enter too soon. slides input video is 10fps, the other is 24. [15:30:49 CET] <kepstin> iank: my recommendation would be to put an fps filter on each input to convert them to 24fps before doing the overlay. [15:31:07 CET] <kepstin> (both inputs, because the fps filter will "clean up" the timestamps and timebase so they match) [15:31:19 CET] <iank> kepstin awesome, thank you [15:31:28 CET] <iank> do you happen to know the syntax for that offhand? [15:32:13 CET] <kepstin> "[0]scale=iw/3:ih/3,fps=24[pip];[1]fps=24[base];[base][pip]overlay=&" [15:34:42 CET] <iank> thank you! [15:36:40 CET] <kepstin> without that, the output of the overlay will be variable framerate - you could fix that by putting an fps filter after the overlay to drop the extra frames, but putting it before should be slightly faster in theory. [15:37:02 CET] <kepstin> probably not a big difference either way tho [16:58:48 CET] <pridkett> does ffmpeg support converting 5.1 to stereo ? [17:00:35 CET] <pink_mist> didn't you ask that earlier with another nick and get an answer provided to you already? [17:01:12 CET] <kepstin> looks like damdai's connection dropped a few seconds after they got the answer [17:01:22 CET] <kepstin> so I could understand it being misses [17:01:47 CET] <furq> you have the patience of a saint [17:01:48 CET] <pridkett> sorry my computer crashed [17:02:07 CET] <pink_mist> kepstin: ah, you're right, I missed that part [17:02:11 CET] <pink_mist> pridkett: 03:02 <another> damdai: https://trac.ffmpeg.org/wiki/AudioChannelManipulation#a5.1stereo [17:02:58 CET] <pridkett> that picture says it splits center into left and right [17:03:07 CET] <pridkett> how is that possible [17:03:19 CET] <pink_mist> mathematics [17:03:24 CET] <pink_mist> or magic [17:03:29 CET] <pink_mist> maybe a bit of both [17:03:46 CET] <pridkett> and that picture also says LFE is ignored [17:04:42 CET] <pridkett> is LFE really ignored? [17:07:01 CET] <pridkett> i wonder how well ffmpeg does splitting "center" [17:08:00 CET] <pridkett> the topic says This channel is publicly logged' where do i see this log? [17:08:21 CET] <kepstin> i assume it center-pans the center channel into stereo (sends the signal to both channels at reduced power, probably somewhere between -3 to -6dB.) [17:08:38 CET] <pridkett> kepstin i see [17:08:49 CET] <pridkett> kepstin what about LFE? [17:09:58 CET] <kepstin> pridkett: https://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/ has logs for both this channel and #ffmpeg-devel [17:10:49 CET] <pridkett> kepstin what is the name of the bot that is doing the logging [17:12:19 CET] <pridkett> it has no join/part info [17:12:50 CET] <kepstin> seriously? the bot has literally the most obvious name :) [17:13:19 CET] <pridkett> boturk? [17:13:57 CET] <pridkett> shouldn't boturk have @ access? [17:16:01 CET] <iank> i have 2 vp8 videos im overlaying, should i keep the resulting video as vp8 or make it vp9? [17:16:48 CET] <pridkett> iank what do you mean by overlaying [17:17:05 CET] <iank> picture in picture [17:17:14 CET] <pridkett> make it vp9 [17:17:16 CET] <furq> iank: it makes no difference [17:17:21 CET] <furq> use whichever one suits you better [17:17:48 CET] <pridkett> iank if i were you, i use vp9, mine as well [17:18:01 CET] <iank> ok, thanks [17:18:20 CET] <pridkett> iank even youtube uses vp9 over x264 [17:18:36 CET] <iank> nice, ok [17:19:20 CET] <pridkett> iank is it 50/50 overlaying? [17:19:48 CET] <iank> no, the picture in picture is like 1/5th the size [17:20:08 CET] <pridkett> ok [17:22:53 CET] <kepstin> iank: vp9 generally provides better efficiency (quality per bit) than vp8, and the encoder has better multithreading so it's often faster. All current browsers that can play vp8 can also play vp9. So there's basically no reason to use vp8 any more. [17:23:17 CET] <iank> thank you! good to know. i will use it [17:23:48 CET] <pridkett> kepstin agreed [17:25:18 CET] <pridkett> kepstin did feluce come to you and talk about fixing ffmpeg for opus [17:25:45 CET] <kepstin> feluce talked about it a bit. [17:25:58 CET] <pridkett> feluce said it was easy fix [17:26:40 CET] <kepstin> from reading the opus channel log, it looks like libopus *specifically* has a resampler implementation that allows it to return the exact number of samples from the original file when the input sample rate doesn't match opus's internal coding rates. [17:27:22 CET] <kepstin> note that this wouldn't hold true for stuff decoded with ffmpeg's internal opus decoder, which doesn't use the same resampler. (i don't think it's required by the spec, from my look-through?) [17:27:23 CET] <faLUCE> kepstin: in the opus channel the devs told that the input is not resampled before processing... then ffmpeg should allow other samplerates too [17:27:38 CET] <pridkett> lol look who shows up [17:28:23 CET] <kepstin> we could certainly allow sending arbitrary sample rates to the libopus encoder in ffmpeg, to use their internal resampler rather than ffmpeg's. That would be fine [17:28:30 CET] <kepstin> probably easy to do [17:28:36 CET] <faLUCE> kepstin: yes [17:29:01 CET] <faLUCE> kepstin: they also told me that ffmpeg devs are aware of that [17:29:57 CET] <faLUCE> maybe a ticket has already been opened [17:30:01 CET] <faLUCE> I don't know [17:30:02 CET] <kepstin> but for decoding it's a trickier call to make, especially since the internal decoder is used by default i think. [17:31:15 CET] <kepstin> might need some extra stuff wired up to save the original sample rate as metadata so it can be passed to the decoder, if people care about that. [17:31:15 CET] <faLUCE> I wonder if other samplerates are not allowed because the same codec is used for output too [17:31:48 CET] <furq> 16:27:23 ( faLUCE) kepstin: in the opus channel the devs told that the input is not resampled before processing... [17:31:51 CET] <furq> are you sure they said this [17:31:58 CET] <faLUCE> furq: yes [17:32:06 CET] <pridkett> furq i have the logs [17:32:35 CET] <kepstin> the only thing i got from the linked log is that the opus devs say that it will return the same sample count after decoding as it had on the input, at arbitrary sample rates [17:32:39 CET] <faLUCE> pridkett: paste the log if you have it. Anyway, you could ask to gmaxwell [17:32:42 CET] <kepstin> they made no claim about not resampling [17:32:46 CET] <furq> what kepstin said [17:32:56 CET] <furq> opusenc stores original sample rate as metadata [17:33:03 CET] <furq> and then opusdec will resample back to that if possible [17:33:06 CET] <faLUCE> kepstin: wait, I check the log [17:33:13 CET] <pridkett> https://pastebin.com/7DpAxMUe [17:33:16 CET] <furq> you can ffprobe the output of opusenc and see that it's 48k [17:33:55 CET] <kepstin> opusenc (the command line tool) supports 44.1K input, and opusdec supports 44.1K output, and there's some metadata to pass the information from one to the other. [17:34:08 CET] <furq> right [17:34:11 CET] <furq> and they both resample [17:34:43 CET] <kepstin> they decided that having the decoder match the sample rate of the original input would be less surprising to users than e.g. always getting 48K back [17:35:03 CET] <kepstin> iirc there was some debate about that? [17:35:16 CET] <faLUCE> kepstin: [18:58] <faLUCE> gmaxwell: are you sure that the input is not resampled ? [17:35:26 CET] <faLUCE> [19:00] <+gmaxwell> faLUCE: yes, it is as part of the processing, and? [17:35:34 CET] <faLUCE> [19:00] <faLUCE> gmaxwell: then ffmpeg people must be informed [17:35:47 CET] <furq> "yes it is" is him saying it is resampled [17:35:49 CET] <faLUCE> [19:02] <+gmaxwell> I'm sure some people know. [17:35:52 CET] <kepstin> here, let me help your reading: "<+gmaxwell> faLUCE: yes, it is [resampled] as part of the processing, and?" [17:36:20 CET] <kepstin> english negatives are strange :/ [17:36:32 CET] <furq> yeah there are less confusing ways to say that [17:36:43 CET] <kepstin> it helps if you avoid asking negative questions. [17:37:09 CET] <kepstin> ask "is the input resampled", not "is the input not resampled" :) [17:37:34 CET] <faLUCE> kepstin: [17:37:37 CET] <faLUCE> [18:58] <faLUCE> gmaxwell: are you sure that the input is not resampled ? [17:37:39 CET] <faLUCE> [18:58] <faLUCE> (before processing, I mean) [17:37:57 CET] <faLUCE> and gmaxwell says "it's a part of the processing" [17:38:05 CET] <furq> i mean you can just check this yourself [17:38:27 CET] <furq> that wav > opusenc > opusdec > wav chain that results in a 44.1k wav will have a verifiably 48k opus file in the middle [17:38:43 CET] <brimestone> Anyone familiar with -progress url flag here? But not sure how it maps it to header for the receiving URL to parse the data [17:38:43 CET] <pridkett> [18:27] <damdai> i was told opusenc does not support 44.1khz : is this true? [17:38:43 CET] <pridkett> [18:31] <+gmaxwell> No. [17:38:43 CET] <pridkett> [18:32] <damdai> then why people in #ffmpeg say that [17:38:43 CET] <pridkett> [18:33] <+gmaxwell> No idea. [17:38:45 CET] <furq> with "original sample rate" metadata if you check with opusinfo [17:39:10 CET] <kepstin> in libopus, the resampler is integrated into the other processing it does when encoding. so it's no resampled before processing... [17:39:24 CET] <furq> the resampler is specifically in opusenc/libopusenc iirc [17:39:32 CET] <faLUCE> kepstin: then other samplerates should be accepted [17:39:33 CET] <furq> libopus expects 48k input [17:39:42 CET] <furq> or 24k or whatever [17:39:50 CET] <kepstin> huh, does it? I thought the libopus resampler accepted more stuff. [17:39:55 CET] <furq> i might be wrong about that [17:40:22 CET] <faLUCE> anyway, gmaxwell is a libopus dev. maybe the main one... you should ask to him [17:40:26 CET] <kepstin> anyways, the opus spec doesn't require resampling to arbitrary output rates. that's just something opusdec does. [17:40:56 CET] <furq> https://github.com/xiph/libopusenc/blob/master/src/resample.c [17:40:57 CET] <furq> yeah there you go [17:41:21 CET] <kepstin> but yeah, nobody in this channel made the claim that "opusenc (the cli tool) doesn't support 44.1K" input, I know it can do that just fine [17:41:44 CET] <furq> opus itself doesn't support 44.1k, it has to be resampled [17:41:47 CET] <furq> but the opus tools will do that for you [17:41:53 CET] <furq> because otherwise nobody would use them [17:41:54 CET] <kepstin> heh, it's just the speex resampler, because of course it is [17:41:56 CET] <faLUCE> kepstin: not only. They also said that 44.1 is NOT resampled before processing [17:42:07 CET] <furq> faLUCE: again, he said that it is resampled [17:42:20 CET] <kepstin> faLUCE: they also said it is resampled during processing [17:42:29 CET] <pridkett> maybe you people should join #opus together and ask [17:42:41 CET] <pridkett> so much confusion [17:42:43 CET] <faLUCE> kepstin: furq I asked if it was resampled BEFORE [17:42:52 CET] <faLUCE> not during processing [17:43:05 CET] <furq> well then you must have different definitions of processing [17:43:37 CET] <kepstin> faLUCE: doesn't really matter, it gets resampled at some point between the input and the output. The input is 44.1Khz wave, the output is spec opus (which runs encoding stuff at 48kHz or divisions thereof). [17:45:00 CET] <faLUCE> kepstin: if it is resampled before input it's different if it's resampled before output. I mean: in the first case you loose quality before encoding [17:45:16 CET] <kepstin> faLUCE: it's resampled when encoding, and resampled again when decoding. [17:45:21 CET] <faLUCE> but really, you should ask to #opus people [17:45:43 CET] <furq> it's resampled before encoding and then resampled again after decoding [17:45:52 CET] <furq> but if you cared about minor quality loss you wouldn't be using a lossy codec anyway [17:46:02 CET] <faLUCE> furq: no, they told me that it's not resampled BEFORE encoding [17:46:07 CET] <furq> well it is [17:46:22 CET] <kepstin> it's not resampled before encoding. it's resampled during encoding. [17:46:26 CET] <kepstin> the difference doesn't matter [17:46:32 CET] <furq> right [17:46:53 CET] <faLUCE> I'm not sure about that, but I will ask them [17:47:01 CET] <kepstin> 44.1kHz wav ->(opusenc)-> opus (internally 48KHz, with metadata saying "44.1kHz") ->(opusdec)-> 44.1kHz wav [17:47:28 CET] <faLUCE> kepstin: it could be resampled just before producing output. [17:47:46 CET] <furq> why is that different [17:48:06 CET] <faLUCE> furq: because if it is resampled before encoding, you loose quality before encoding [17:48:12 CET] <kepstin> faLUCE: it is resampled two times: once either before or during encoding (from 44.1 to 48) and again either during or after decoding (from 48 to 44.1) [17:48:31 CET] <furq> i don't see how the quality loss is any different [17:48:34 CET] <furq> it gets resampled twice either way [17:48:34 CET] <kepstin> faLUCE: you also lose quality during encoding, because it is a *lossy codec* [17:48:36 CET] <kepstin> so what [17:49:06 CET] <furq> it also still beats any lossy codec that doesn't resample in actual listening tests [17:49:07 CET] <faLUCE> kepstin: but if it's resampled before encoding you can loose more quality [17:49:17 CET] <furq> so maybe, just maybe, it doesn't actually matter [17:49:41 CET] <kepstin> there's no way you can notice a tiny amount of distortion from a 48 to 44.1 conversion compared to what a lossy codec does. [17:49:54 CET] <faLUCE> kepstin: anyway, I understand what you say, but I would ask to #opus people to be sure that doesn't make difference, for the quality, inputting 44.1 or 48 [17:50:13 CET] <faLUCE> I mean, for the "theoretical" quality [17:50:14 CET] <furq> i mean it'll probably be slightly higher quality if you input 48, but not if you just resampled it from 44.1 yourself [17:50:19 CET] <furq> emphasis on "slightly" [17:50:41 CET] <pridkett> i don't want my source 44.1khz being resampled to 48khz or 32khz being resampled to 24khz which ffmpeg's libopus does [17:50:51 CET] <furq> well bad news, that's what opusenc does [17:51:24 CET] <kepstin> pridkett: too bad, the opus codec (the codec itself, not talking about any implementations) as standardized by the ietf, does not allow arbitrary sample rates. [17:52:11 CET] <pridkett> feluce gmaxwell is active in #opus now [17:52:20 CET] <kepstin> pridkett: if ffmpeg is resampling 32kHz to 24kHz that does sound like a bug tho, that should be using 48K probably [17:52:23 CET] <pridkett> furq gmaxwell is active in #opus now [17:52:28 CET] <furq> cool [17:52:30 CET] <furq> have fun talking to him [17:53:09 CET] <pridkett> kepstin really? but it does [17:53:17 CET] <pridkett> last time i checked [17:54:04 CET] <pridkett> <+gmaxwell> Kepstin is incorrect. The opus format doesn't care about sample rates at all. [17:58:37 CET] <kepstin> right, i was kind of simplifying a bit, the concept of sample rate when combined with an mdct and the other filtering etc. done is kind of iffy [17:59:01 CET] <kepstin> anyways, ""mark4o> opusenc and libopusenc support 44.1 kHz. libopus does not." is the relevent quote; ffmpeg does not use libopusenc. [18:02:20 CET] <faLUCE> I did not even know that there was a libopusenc library :-) [18:02:36 CET] <furq> it's pretty new [18:04:02 CET] <faLUCE> anyway, for my ears 48000 and 44100 doesn't make difference [18:04:10 CET] <faLUCE> I'm not a purist [18:04:15 CET] <furq> new enough that it's not even mentioned on the opus docs page referenced in the libopusenc readme [18:04:43 CET] <furq> afaik it's just a rollup of the opus-tools stuff into a library so you don't need to bring your own resampler etc [18:04:58 CET] <kepstin> yeah, it just adds an ogg muxer, some metadata tools, and a resampler [18:05:02 CET] <furq> but ffmpeg already has a good one so it's not really of much relevance [18:16:05 CET] <jmspeex> What exactly is the issue with Opus and 44.1 kHz (I'm one of the main authors) [18:17:22 CET] <faLUCE> jmspeex: we were discussing if 44.1 sample rate has to be accepted by the input [18:17:34 CET] <faLUCE> jmspeex: you should join the #opus channel [18:17:58 CET] <jmspeex> I am obviously, and what would you not accept 44.1 kHz as input? [18:18:12 CET] <faLUCE> ? [18:18:31 CET] <jmspeex> s/what/why/ [18:18:39 CET] <furq> jmspeex: the question is whether 44.1 has to be resampled before going to libopus [18:18:50 CET] <furq> the answer is yes and i'm not sure why it's taken so long [18:19:02 CET] <jmspeex> it does (unless you use libopusenc which will do it for you) [18:19:38 CET] <pridkett> furq do you mean "if the answer is yes"? [18:19:52 CET] <jmspeex> BTW, there's an entry about 44.1 kHz in the Opus FAQ for anyone who hasn't read it yet: https://wiki.xiph.org/index.php?title=OpusFAQ [18:20:02 CET] <furq> no i mean the answer is yes. i said that exact thing 40 minutes ago [18:21:21 CET] <faLUCE> jmspeex: the are continuing the discussion on the #opus channel [18:21:35 CET] <faLUCE> you can see there what is not clear yet [18:21:41 CET] <furq> i wonder how many times a day this comes up in #opus [18:21:49 CET] <faLUCE> (they) [18:21:51 CET] <furq> i'm surprised they don't just have a bot that links to the wiki [18:23:55 CET] <pridkett> furq sorry but i trust opus dev more than you about opus [18:24:39 CET] Action: kepstin bookmarks https://wiki.xiph.org/index.php?title=OpusFAQ#How_do_I_use_44.1_kHz_or_some… for future reference. [18:25:58 CET] <furq> i accept your apology [18:26:39 CET] <kepstin> anyways, looking at libopusenc, I think there probably are some improvements that could be made to the ffmpeg libopus wrapper that may help improve the quality of gapless playback. [18:26:59 CET] <jmspeex> I guess it comes down to this. Resampler SNR: 90 to 140+ dB. Lossy codec SNR: 15 to 50 dB. [18:27:33 CET] <furq> also your dac probably resamples to 48k anyway [18:27:48 CET] <furq> or a multiple thereof [18:28:22 CET] <jmspeex> in the end it's all resampled to a few MHz and one bit (sigma-delta and the like) [18:28:28 CET] <kepstin> man, it was so annoying back in the AC'97 days when i had to run a software mixer to convert everything to 48kHz and mix multiple concurrent streams :) [18:28:38 CET] <kepstin> (now it's less annoying) [18:28:39 CET] <pridkett> furq why do you say that? [18:28:46 CET] <pridkett> dac probably resamples to 48k anyway [18:29:11 CET] <furq> because it does [18:29:19 CET] <pridkett> how do i tell if my DAC resamples to 48k [18:29:42 CET] <kepstin> i think most modern "intel hda" (azalia) desktop hardware supports being sent samples at a pretty wide range of input rates, no idea what it actually does internally. it's all a black box. [18:30:27 CET] <jmspeex> The DAC will take either 44.1 or 48 (usually software configurable). From there, the old DACs would up-sample to 96 kHz or 192 kHz (or higher) to make their lives easier. Newer DACs upsample to a few MHz with just one bit samples and noise shaping. [18:30:50 CET] <pridkett> https://hardforum.com/threads/x-fi-titanium-digital-output-sampling-rate-48… [18:32:39 CET] <jmspeex> Also, the MDCT that most codecs use *is* a resampler. It resamples a 48 kHz signal into (e.g.) 960 signals sampled at 50 Hz. [18:38:21 CET] <kepstin> anyways, as far as I can tell, the main difference between ffmpeg's libopus wrapper and libopusenc (other than possibly how some libopus ctls are configured, haven't checked them all) is that ffmpeg uses the same length for the last packet as it had for other packets and 0-fills the extra, while libopusenc may pick a shorter packet length and uses a predictor to generate the padding data. [18:40:46 CET] <pridkett> there is a huge bug in ffprobe [18:41:11 CET] <pridkett> Stream #0:0: Audio: dst (DST / 0x20545344), 352800 Hz, 5.1(side), flt [18:41:24 CET] <pridkett> that should be 2.8mhz not 3.5 [18:48:19 CET] <kepstin> oh, hmm, there's also the "decision_delay" stuff? i'm not sure exactly that that does from reading the code :/ [18:56:50 CET] <brimestone> Hey guys, im trying to output stderr to a log file, but I'm getting "Unable to find a suitable output format for '2>'" instead [18:57:50 CET] <kepstin> brimestone: you've got a typo or are using the incorrect syntax for your shell [18:58:10 CET] <kepstin> (the shell is supposed to interpret that before starting ffmpeg - but for some reason it's getting passed to ffmpeg itself) [18:58:40 CET] <DHE> yeah, you probably have quotes somewhere they don't belong [18:58:47 CET] <DHE> (or backslashes?) [18:59:15 CET] <brimestone> https://gist.githubusercontent.com/brimestoned/1ba401bc1224c847da81c0f67ef3… [18:59:58 CET] <kepstin> hmm, mac os x. presumably bash shell? [19:00:23 CET] <brimestone> Well, its runs on a docker (ubuntu) on a osx host [19:00:41 CET] <kepstin> you've got a bunch of quoting issues there - filenames containing spaces without quotes? [19:01:11 CET] <kepstin> and if you're running it in docker, depending how you do it it might not use a shell at all, so the redirection wouldn't work [19:01:16 CET] <brimestone> Yes, but that is handle via an array.. [19:01:39 CET] <kepstin> if you use the array syntax of CMD with docker, it does not use a shell, so shell redirections will not work. [19:02:05 CET] <kepstin> you may want to use a wrapper script in the docker container. [19:02:15 CET] <brimestone> Oh.. hmmm [19:03:01 CET] <brimestone> If tried to do -progress url to get stats but, it does it via sockets [19:04:46 CET] <kepstin> i.e. have docker ENTRYPOINT [ "ffmpeg-wrapper.sh" ] and then make that into a script which runs ffmpeg "${@}" 2>/path/to/save/log [19:05:13 CET] <kepstin> then CMD will just be your regular arguments [19:06:26 CET] <brimestone> thanks! [19:10:00 CET] <brimestone> This is a thinker.. I need to refactor my docker payload.. Its currently like this. https://gist.github.com/brimestoned/1ba401bc1224c847da81c0f67ef320cc [19:17:22 CET] <furq> brimestone: you can just use -report [19:17:57 CET] <brimestone> furq: doesn't that only happens at the end of ffmpeg run? [19:19:03 CET] <brimestone> Oh wow... that might worked! [19:56:49 CET] <jmspeex> Is it true that ffmpeg resamples 32 kHz audio to 24 kHz when encoding with Opus? [19:57:39 CET] <jmspeex> If so, that would be pretty dumb because 1) it destroys the 12-16 kHz band and 2) libopus will internally up-sample to 48 kHz anyway [19:58:21 CET] <furq> http://vpaste.net/hA9nX [19:58:22 CET] <furq> looks like it [19:58:28 CET] <furq> unless it got changed since 4.1.1 [19:59:00 CET] <jmspeex> :-( [19:59:26 CET] <JEEB> wonder if that's just for some reason the automated logic [19:59:28 CET] <JEEB> 48000, 24000, 16000, 12000, 8000, 0, [19:59:40 CET] <JEEB> are the sample rates marked supported by the libopus wrapper [19:59:49 CET] <JEEB> (zero being the end-of-array thing I think) [20:00:21 CET] <jmspeex> I think the save thing to do with Opus is to just resample everything to 48 kHz regardless of the original sampling rate [20:01:06 CET] <jmspeex> Even for 8 kHz, if the signal is music, Opus will internally resample to 48 kHz because that's what CELT operates at. [20:02:21 CET] <jmspeex> The only case where Opus will not internally resample to 48 kHz is for 8 or 16 kHz voice. And ffmpeg's resampler is likely better than the internal Opus one which is optimized for latency. [20:02:47 CET] <JEEB> yea, so one fix would just do the same as the internal opus encoder, which marks only 48000 as supported [20:03:23 CET] <JEEB> yup, remembered correclty [20:03:24 CET] <JEEB> .supported_samplerates = (const int []){ 48000, 0 }, [20:03:27 CET] <JEEB> for the native one [20:06:28 CET] <kepstin> there's probably a general fix that could be added to ffmpeg's automatic sample rate selection logic, to make it less likely to downsample stuff. [20:06:42 CET] <JEEB> yea I did wonder why it picked to go that way [20:06:55 CET] <JEEB> I see ffmpeg_opt copies the encoder's list into the OutputFilter [20:07:03 CET] <JEEB> but I didn't get further than that [20:12:43 CET] <kepstin> the sample rate selection logit is in swap_samplerates_on_filter in avfiltergraph.c i think, it's simply picking the rate with the smallest absolute difference from the requested rate [20:13:12 CET] <JEEB> yea, probably ffmpeg_filter.c just picks the correct list from things [20:13:26 CET] <JEEB> and passes it into the filter chain generation in lavfi [20:14:03 CET] <jmspeex> JEEB: by internal encoder you mean the one atomnuker wrote? [20:14:09 CET] <JEEB> yup [20:14:54 CET] <jmspeex> hopefully that's not the one used by default (not that it's terrible, but it doesn't match the libopus one) [20:15:25 CET] <kepstin> it's marked as experimental right now, i think? so you need to pass an extra flag to use it. We recommend people explicitly specify the libopus encoder. [20:15:59 CET] <JEEB> I think there was a preference order somehow set for encoders of a format? [20:16:26 CET] <kepstin> experimental encoders automatically get low preference, but the exact match by name takes priority iirc :/ [20:16:55 CET] <jmspeex> On the plus side, Opus is designed to make it hard to write a really bad encoder [20:17:05 CET] <kepstin> and most of the internal codec implementations have the same name as the codec name [20:18:00 CET] <jmspeex> (as in as long as you have a decent transient detector, you'll easily beat MP3 unless you do it on purpose) [20:19:04 CET] <kepstin> anyways, to fix the 3200024000 issue, I think all it needs is some better logic in https://git.videolan.org/?p=ffmpeg.git?a=blob;f=libavfilter/avfiltergraph.c… [20:19:35 CET] <kepstin> it picks 24000 because that's 8000 away, when 48000 is 16000 away. [20:20:43 CET] <JEEB> right [20:20:56 CET] <jmspeex> kepstin: I don't know if other codecs use that logic, but it's wrong in almost all cases [20:21:10 CET] <jmspeex> up-sampling doesn't lose information, but down-sampling definitely does [20:21:19 CET] <JEEB> yup [20:21:24 CET] <kepstin> this doesn't have anything to do with codecs, this is with the sample rate conversion in the automatically inserted resampler in the filter chain [20:21:27 CET] <kepstin> but yes, i agree [20:21:38 CET] <JEEB> of course there's the "best" rates etc you can do resampling at [20:21:54 CET] <JEEB> but downwards is probably wrong [20:21:56 CET] <pridkett> jmspeex doesn't upsample cause bad quality/size ratio though? [20:21:56 CET] <JEEB> in any case [20:22:26 CET] <kepstin> we already have some special logic for pixel formats for video to pick appropriate types in cases like this [20:22:44 CET] <jmspeex> pridkett: Lossy codecs don't care what the original sampling rate is. They transform to the frequency domain and ignore the useless information [20:23:05 CET] <JEEB> yet users loove to see numbers 8) [20:23:12 CET] <pridkett> jmspeex for all lossy codecs? [20:24:28 CET] <jmspeex> pridkett: all the ones worth using (including MP3) that don't have a braindead encoder [20:25:18 CET] <kepstin> pridkett: upsampling does in general reduce efficiency of lossless codecs, since the codec has to store more information (however it does it) to get a bit-exact reproduction on decoding. [20:25:52 CET] <jmspeex> Well, if you've resampled you're already not lossless, so... [20:26:08 CET] <kepstin> of course :) [20:26:14 CET] <pridkett> jmspeex so you are saying even IF opus upsampled every audio to 192khz it will still have same quality/size as what it is now? [20:26:37 CET] <jmspeex> pridkett: Yes. The first thing it does is ignore everything below 20 kHz [20:26:51 CET] <kepstin> i hope you mean "above" :) [20:27:00 CET] <jmspeex> That's (kinda) equivalent to resampling to 40 kHz [20:27:14 CET] <jmspeex> yes, I mean above [20:27:23 CET] <pridkett> jmspeex i find that very hard to believe [20:27:43 CET] <jmspeex> pridkett: what do you find hard to believe? [20:27:45 CET] <kepstin> iirc opus already runs a 20khz lowpass filter, even with 48kHz sampling input [20:27:57 CET] <jmspeex> exactly [20:28:07 CET] <pridkett> jmspeex but you are the expert, i will take your word [20:28:25 CET] <jmspeex> pridkett: IIRC opusenc supports input sampling rates up to around 1 GHz or so [20:28:36 CET] <jmspeex> have fun -- same quality [20:28:49 CET] <pridkett> i said quality/size [20:28:51 CET] <kepstin> well, if you're making a lossy encoder, the first thing you want to do is remove any signal that a human definitely cannot hear [20:28:54 CET] <jmspeex> same size too [20:29:24 CET] <pridkett> then why can't this be the same case for lossless encoder/format ? [20:29:40 CET] <kepstin> because lossless doesn't remove stuff that a person can't hear. [20:29:56 CET] <pridkett> but it still removes [20:30:02 CET] <pridkett> what is it removing then [20:30:04 CET] <jmspeex> pridkett: HAve you watched Monty's video on sampling: https://xiph.org/video/vid2.shtml ? [20:30:12 CET] <kepstin> lossless doesn't remove anything. otherwise it wouldn't be called lossless [20:30:32 CET] <pridkett> it has to remove something to shrink down the filie size [20:30:33 CET] <jmspeex> If not, then just go watch it. It's 24 minutes and will answer everything *much* better than we ever will [20:30:52 CET] <kepstin> lossless codecs don't always make the file smaller - with some inputs, they will actually make it bigger [20:30:57 CET] <pridkett> jmspeex okay i will watch [20:31:06 CET] <kepstin> that's usually limited to artifically generated noise, tho [20:31:12 CET] <pridkett> kepstin no lossless codec makes the file bigger [20:31:25 CET] <pridkett> otherwise people won't use it [20:32:35 CET] <kepstin> sounds like you need a lesson on lossless compression technology too :/ [20:32:50 CET] <kepstin> (i don't have a good reference offhand for that) [20:32:58 CET] <jmspeex> pridkett: If you encode perfectly random noise, the output will be slightly bigger. If you could create a lossless encoder that's guaranteed to make the output smaller, all you'd need to do is run it enough times to get a single bit at the end. [20:33:25 CET] <jmspeex> So yeah, you need to learn about information/compression theory. But first go watch that video [20:39:17 CET] <pridkett> jmspeex higher sample rate isn't = wanting to have information higher than 20 khz though: higher sample rate = closer to analog signal [20:39:48 CET] <jmspeex> pridkett: That statement is proof that you haven't watched the video [20:40:23 CET] <pridkett> digital can never be true analog signal, but higher it is; the closer the analog it can be [20:40:27 CET] <jmspeex> that's *exactly* what that video is about [20:41:24 CET] <jmspeex> pridkett: either you keep repeating that nonsense (based on not understanding the sampling theorem) or you just watch the video [20:41:31 CET] <kepstin> pridkett: monty even pulls out an analog oscilloscope to prove you wrong in his video ;) [20:42:44 CET] <pridkett> if that is true 48khz wouldn't have existed in the first place [20:42:52 CET] <pridkett> 44.1khz would be enough [20:43:19 CET] <jmspeex> pridkett: 48 kHz is just more convenient in many respect. That's it [20:44:14 CET] <jmspeex> after you've watched the video you can search for the weird origins of 44.1 kHz [20:50:07 CET] <kepstin> I'm actually kind of surprised we didn't end up with 44.056kHz [20:50:54 CET] <jmspeex> kepstin: you mean because color NTSC? [20:51:10 CET] <jmspeex> that would definitely have sucked! [20:51:22 CET] <kepstin> apparently it didn't use the color at all, but with NTSC equipment that was the rate you got yeah [20:52:27 CET] <kepstin> hmm, you're right, that is an exact match to the 1000/1001 factor added for color ntsc [20:52:39 CET] <kepstin> so i guess we do blame color :) [20:53:07 CET] <kepstin> I hate that we still have to deal with that for video stuff [20:53:12 CET] <jmspeex> At least with 44.1 kHz, the largest prime factor is just 7. For 44.056 kHz it would have been 5507! [20:54:11 CET] <jmspeex> where did you get the 44.056 from (other than from the 29.97 color NTSC rate)? [20:54:42 CET] <kepstin> it would be exactly 44100 * 1000/1001 (not 44056Hz) [20:55:14 CET] <jmspeex> right [20:56:14 CET] <jmspeex> I mean, it could have been worse... CDs sampled at 14*pi kHz :-) [20:57:14 CET] <kepstin> on the plus side, 441000/1.001Hz audio would have an exact number of samples per frame when used with ntsc vide video, on the minus side... everything else. [20:59:29 CET] <kepstin> i guess sony must have standardized on shipping 625line/50hz format video recorders with their pcm adapters. [00:00:00 CET] --- Wed Mar 27 2019

1 0