Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

April 2019

1 participants
60 discussions

ffmpeg-devel.log.20190419
by burek 20 Apr '19

20 Apr '19

[00:00:23 CEST] <JEEB> probably [00:00:28 CEST] <mkver> One of those "via ffmpeg-devel" commits is mine (namely 18a851aca766ff8c7199c9e0c37d8fa642e41920). [00:00:43 CEST] <mkver> Then it is time to change the email provider. [00:01:57 CEST] <JEEB> yea, basically your name should be correct because the mailing list only rewrites the e-mail (and the "via xxx"), so at least that part should be OK [00:02:19 CEST] <JEEB> of course it still was a mistake on part of whomever pushed. but most likely nobody expected the patches to come out like that [00:02:35 CEST] <JEEB> then patchwork doing the name attribution incorrectly is another thing :D [00:03:02 CEST] <JEEB> not sure if it actually also rewrites the patches if you try to get the patches from it [00:03:14 CEST] <JEEB> if yes, then that's bad. I've sometimes used patchwork to curl | git am patches [00:03:39 CEST] <mkver> Which (free) provider doesn't implement DMARC? [00:22:58 CEST] <cone-741> ffmpeg 03Steven Liu 07master:608d5fd8b616: add tests/ref/fate/hls-segment-size for the fate test [00:22:59 CEST] <cone-741> ffmpeg 03Steven Liu 07master:55619f30122e: rename hls_segment_filename in fate-hls-segment-size for fate [01:15:07 CEST] <mkver> I have just found out that googlemail.com had a different DMARC policy than gmail.com. I thought googlemail was just an alias for gmail; apparently it's not so easy. [01:15:38 CEST] <mkver> It's v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:mailauth-reports@google.com for googlemail vs. v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com for gmail. [01:16:02 CEST] <mkver> Hopefully using @gmail will fix the problems in the future. [01:17:32 CEST] <cone-741> ffmpeg 03Carl Eugen Hoyos 07master:96fc0cbfde24: tests: Add EXESUF to program calls. [01:27:53 CEST] <BtbN> It affects it for a lot more servers than just googlemail.com [01:28:04 CEST] <BtbN> google.com protonmail are the first ones that come up [01:29:59 CEST] <cehoyos> I succeeded building and testing qsv on Windows but I wonder how this is supposed to work without the patch I just sent... [01:32:18 CEST] <BtbN> You mean the EXECSUF for fate? [01:32:46 CEST] <BtbN> That's a WSL specialty. Everywhere else you can just omit the .exe suffix and it'll run. [01:33:29 CEST] <BtbN> oh, no, the mfx one, nvm [01:34:01 CEST] <cehoyos> The mfx one, yes [01:34:15 CEST] <BtbN> I remember that weird -llibmfx being there very intentionally for some horrid weird closed source version of the Media SDK [01:34:21 CEST] <cehoyos> Although I also wonder why nobody ever used wsl for fate, I find it very useful [01:34:44 CEST] <BtbN> Every other case is supposed to be covered by pkg_config [01:34:45 CEST] <cehoyos> So there is another version of the same library that is called liblibmfx.a or similar? [01:35:15 CEST] <BtbN> Pretty much, yes [01:35:26 CEST] <cehoyos> Cool, where can I find it? [01:35:40 CEST] <BtbN> Need to register with Intel and dig in their closed source media SDKs [01:35:54 CEST] <cehoyos> I'll ask them to comment [01:36:16 CEST] <BtbN> It's the issue of lib???.so -> ???.lib on Windows. But someone didn't pay attention and named the .lib lib???.lib [01:36:20 CEST] <BtbN> so that's where that comes from [01:40:40 CEST] <BtbN> See comment of 164e2773261451ef33c4616296ec5bebecff42af [01:48:21 CEST] <cehoyos> BtbN: Thank you. I wonder how I am going to fix this for the "normal" case... [01:50:23 CEST] <BtbN> Every other case should have a proper pkg-config file, you you probably just need to adjust your PKG_CONFIG_PATH? [01:54:05 CEST] <cehoyos> I still need to see a toolchain for win32 that supports pkg-config by default [01:54:44 CEST] <cehoyos> I don't like it, I use it if available but forcing users to install it when it is not needed still seems absurd to me. [01:55:33 CEST] <cehoyos> Especially for a library like mfx that has exactly one constant dependency. [04:29:46 CEST] <BBB> kierank: don't you ever sleep? :D [04:29:54 CEST] <kierank> BBB: i'm in the usa [04:30:01 CEST] <BBB> yay [04:30:08 CEST] <BBB> east or west coast? [04:30:12 CEST] <kierank> BBB: not really, it's hard to eat well in florida [04:30:21 CEST] <BBB> ah [04:30:21 CEST] <kierank> I saw my first vegetable for a week [04:30:44 CEST] <kierank> was a joy to see broccoli on a plate [04:30:46 CEST] <BBB> why wouldn't they say "we're adding chromecast support to prime video app" instead of "we're bringing prime video app to chromecast" [04:31:13 CEST] <BBB> is my english so sub-standard? [04:31:26 CEST] <kierank> BBB: chromecast doesn't have apps per-se [04:31:41 CEST] <kierank> but yeah [04:31:42 CEST] <kierank> oh [04:31:42 CEST] <BBB> exactly, so I have no idea what it means [04:31:43 CEST] <kierank> hmm [04:31:58 CEST] <kierank> I read it as you can cast to chromecast from the app [04:32:18 CEST] <BBB> I want to read it that way, but it very specifically does not say that [04:32:26 CEST] <BBB> that's why I said, it seems written by a marketing dude [04:32:31 CEST] <kierank> I don't see what it can mean otherwise [04:32:48 CEST] <kierank> but yeah maybe marking to make amazon sound more "dominant" [04:33:07 CEST] <BBB> I could interpret it as "our prime video app player in your browser will allow casting to chromecast" [04:33:20 CEST] <BBB> which would be incredibly underwhelming [04:33:32 CEST] <kierank> I would be happy with that [04:33:33 CEST] <BBB> but technically consistent with the message in the press release [04:33:35 CEST] <kierank> that's better than nothing [04:33:48 CEST] <BBB> we write all this software so we can get better than nothing [04:34:05 CEST] <BBB> yeah, I know I still need dvd players, but hey, at least the dvd was encoded with x264 [04:34:23 CEST] <kierank> x264 blu-ray still (!) is a big deal [04:34:46 CEST] <BBB> it's a big deal for blu-ray, but blu-ray still sucks [04:34:56 CEST] <kierank> it's better quality than netflix [04:35:00 CEST] <kierank> or all streaming [04:35:10 CEST] <BBB> yes that's sadly true [04:35:11 CEST] <kierank> and can't be revoked [04:35:40 CEST] <BBB> I hope you're right and android app will support casting :) [04:36:09 CEST] <BBB> we'll see "in the coming months" [04:36:14 CEST] Action: BBB gonna sleep now [04:36:19 CEST] <BBB> g'nite [11:34:32 CEST] <durandal_1707> Nicolas George is full of shit, he thinks he is smartest asshole on planet, and have opinion about anything [11:43:57 CEST] <j-b> durandal_1707: this is not a correct way to speak about anyone [11:55:03 CEST] <ubitux> you just have to say "he's french", that's enough [13:18:08 CEST] <BradleyS> it is better to upsample, do all processing, and then downsample, than to up/downsample for each audio filter [13:19:35 CEST] <BradleyS> most quality audio plugins do both, if sample rate <= 48kHz, upsample+process+downsample, if > 48kHz only process [13:20:18 CEST] <durandal_1707> yes, it is faster. Note this is different than resampling - which is basically interpolation [13:20:21 CEST] <BradleyS> with multiple filters it makes sense to manually upsample and downsample before and after to limit the amount of sample rate changes [13:21:21 CEST] <BradleyS> yes [13:21:32 CEST] <BradleyS> just saying, paul is correct in this case [13:22:08 CEST] <BradleyS> not sure what others' objections are about but it seems they might be applying video thinking to audio [13:23:27 CEST] <BradleyS> patches look fine to me [13:25:36 CEST] <BradleyS> it's not much different that processing 8-bit pixels in 32-bit, for instance [13:25:47 CEST] <BradleyS> it's not about negotiation at all [13:41:26 CEST] <cone-962> ffmpeg 03Gyan Doshi 07master:3bef1dab6e88: avutil/colorspace: add macros for RGB->YUV BT.709 [13:57:23 CEST] <cone-962> ffmpeg 03Carl Eugen Hoyos 07master:dd06f022b074: lavf/utils: Allow url credentials to contain a slash. [13:59:10 CEST] <cone-962> ffmpeg 03Paul B Mahol 07master:78c8a765369d: avcodec/get_bits: unbreak get_bits_le() with cached reader [14:02:24 CEST] <cone-962> ffmpeg 03Carl Eugen Hoyos 07master:53064e134ca6: lavc/alac: Make a variable unsigned. [14:08:05 CEST] <cone-962> ffmpeg 03Carl Eugen Hoyos 07master:32215b21407e: lavf/vc1dec: Reduce probe score for streams with invalid frames. [14:09:13 CEST] Action: BradleyS gives durandal_1707 a cookie [14:20:59 CEST] <cone-962> ffmpeg 03Carl Eugen Hoyos 07master:a24a1523e8d7: lavu/hwcontext_d3d: Cast src pointers calling av_image_copy*(). [16:13:41 CEST] <cehoyos> nevcairiel: Is the new patch (with hostexesuf) ok? Tested with mingw64 and cl.exe from wsl. [16:14:46 CEST] <nevcairiel> looks ok on first glance [16:19:04 CEST] <cehoyos> nevcairiel: Thank you, I sent one more that I believe should be non-controversial, do you agree? [16:19:57 CEST] <nevcairiel> probably also need the .exe in the cl_major_ver= line [16:20:05 CEST] <cehoyos> The remaining issue is that out-of-tree builds need mklink run after configure, I wonder why configure overwrites a "src" symlink [16:20:31 CEST] <cehoyos> fate fails for me with cl.exe 64bit, works with 32bit, but both work for you, right? [16:21:01 CEST] <cehoyos> indeed [16:21:13 CEST] <nevcairiel> there is a bug in fate that i sent a patch for that makes one test fail [16:21:17 CEST] <nevcairiel> i should push that [16:21:34 CEST] <nevcairiel> although its probably fine if you run on wsl anyway [16:22:19 CEST] <cehoyos> Is that related to png or to mov/aac-fixed/rotate? [16:22:24 CEST] <nevcairiel> apng [16:22:42 CEST] <cehoyos> The problem I see is with the rotate-test that also tests aac wich outputs one different frame [16:22:55 CEST] <cehoyos> I don't have zlib yet... [16:23:19 CEST] <cehoyos> one different audio frame [16:24:15 CEST] <cehoyos> Is it possible that I use a newer cl.exe than you? [16:24:40 CEST] <nevcairiel> if you got vs2019, then i havent setup new stations for that yet [16:24:46 CEST] <nevcairiel> if its 2017, i run the latest of that [16:25:08 CEST] <cehoyos> I use vc2019 [16:25:11 CEST] <nevcairiel> 2019 only came out two weeks ago or so [16:25:21 CEST] <cehoyos> Installed tonight... [16:25:36 CEST] <cehoyos> Is it possible to uninstall the (huge) ide? [16:25:59 CEST] <cone-962> ffmpeg 03Hendrik Leppkes 07master:a87774636b87: tests: don't include TARGET_PATH in the sample path needlessly [16:26:11 CEST] <cehoyos> I chose "selected components" and only the compiler but it also installs the ide [16:26:23 CEST] <nevcairiel> presumably its supposed to, but i dont know how to do it exactly [16:26:32 CEST] <cehoyos> ok [16:26:41 CEST] <JEEB> yea not sure the IDE is separately installable/uninstallable. mozilla and friends used to have scripts to archive just the compiler/SDK though [16:27:19 CEST] <cehoyos> Does building from a separate directory work with msys? [16:27:43 CEST] <nevcairiel> it also works with msvc, my fate boxes all do it [16:27:43 CEST] <cehoyos> I mean out-of-tree builds [16:27:50 CEST] <JEEB> yea, out of tree should work [16:27:58 CEST] <cehoyos> you mean it works with msys and msvc, no? [16:28:06 CEST] <nevcairiel> but the detection to not do a symlink my fail on wsl [16:28:10 CEST] <nevcairiel> may* [16:28:11 CEST] <JEEB> ah [16:28:17 CEST] <cehoyos> as opposed to wsl and msvc [16:28:34 CEST] <JEEB> well, at least it should be relatively easy to check if the result seems sane? [16:28:37 CEST] <nevcairiel> indeed [16:28:42 CEST] <cehoyos> I need a symlink: The full paths are completely incompatible [16:28:54 CEST] <cehoyos> Windows "mklink" makes symlinks that work fine in wsl [16:29:30 CEST] <cehoyos> wsl does not understand "C:\" [16:29:40 CEST] <nevcairiel> this is true [16:30:12 CEST] <cehoyos> But everything works fine if I run configure and then make a symlink with mklink [16:30:28 CEST] <cehoyos> I just believe that if such a symlink exists, configure should not delete it [16:32:11 CEST] <nevcairiel> i actually have vs2019 installed here locally for testing, lets see what happens in fate [16:35:08 CEST] <cehoyos> Please! [16:35:29 CEST] <nevcairiel> didnt really get around to testing it much yet the last two weeks [16:35:40 CEST] <cehoyos> fate-filter-meta-4560-rotate0 [16:35:48 CEST] <cehoyos> is the test that fails with 64bit here [16:40:20 CEST] <nevcairiel> i get that too [16:48:04 CEST] <nevcairiel> only one audio frame being different is a bit weird, if it were to miscompile one would expect more then one error like that, and its not even floating point to generate inaccuracies there. but then, the aac fixed point decoder is rather hacky in various places, so who knows [17:35:39 CEST] <cone-962> ffmpeg 03Andreas Hakon 07master:e750dc9de61b: libavformat: improve logs with cur_dts [18:06:56 CEST] <cehoyos> nevcairiel: Thank you for the confirmation, I had similar thoughts... [18:25:55 CEST] <cone-962> ffmpeg 03Dan Sanders 07master:fac761dae927: avformat/apetag: tag values are unsigned [19:50:45 CEST] <JEEB> +This protocol provides most functionalities of the UDP protocol RTMFP : [19:50:45 CEST] <JEEB> +unicast, direct p2p and multicast (via NetGroup). [19:50:53 CEST] <JEEB> is this the zombie of RTMP going around? [19:51:11 CEST] <JEEB> or I guess this is something new with a name resembling Adobe's still-walking zombie protocol [20:33:46 CEST] <mkver> Can someone please confirm that my mails sent via gmail (the two sent today) are actually working properly and are not munged with "via ffmpeg-devel"? [20:34:04 CEST] <JEEB> mkver: which thread? [20:34:21 CEST] <mkver> E.g. this email: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242818.html [20:34:39 CEST] <JEEB> yea, that is how it was received [20:35:08 CEST] <JEEB> think the via things get munged at a point before writing them onto the pipermail [20:35:30 CEST] <JEEB> or maybe not [20:35:36 CEST] <mkver> Good. Then I can now resend the munged patches. [20:35:57 CEST] <JEEB> just trying to figure out if there were any munged mails from your name on the pipermail [20:36:47 CEST] <JEEB> and yes, that mail you linked in my mail client shows up without the via ... [20:36:50 CEST] <JEEB> thing [20:36:53 CEST] <mkver> All mails on the mailing list archive are ok; but apparently those sent to other subscribers of the list were not. [20:37:16 CEST] <mkver> And patchwork is affected, too. [20:38:00 CEST] <JEEB> yeh, my (gmail) interface shows it as coming from your e-mail [20:39:34 CEST] <mkver> Good. Thanks for the confirmation. [21:10:19 CEST] <cone-962> ffmpeg 03Michael Niedermayer 07master:837820f385af: avcodec/diracdec: Use 64bit in intermediate of global motion vector field generation [21:10:20 CEST] <cone-962> ffmpeg 03Michael Niedermayer 07master:110dce963315: avcodec/ivi: Move buffer/block end check to caller of ivi_dc_transform() [21:10:21 CEST] <cone-962> ffmpeg 03Michael Niedermayer 07master:bcf9d2a17242: avcodec/wmv2dec: Check that the P frame secondary header fit in the input [21:10:22 CEST] <cone-962> ffmpeg 03Michael Niedermayer 07master:3ed360ea5cba: avcodec/pictordec: avoid pointers in picmemset() [21:10:23 CEST] <cone-962> ffmpeg 03Michael Niedermayer 07master:838710bd6c5f: avcodec/pictordec: Only recalculate d when y changes in picmemset() [22:14:45 CEST] <durandal_1707> cehoyos: you are back! [22:21:02 CEST] <cehoyos> Correct [00:00:00 CEST] --- Sat Apr 20 2019

1 0

ffmpeg.log.20190419
by burek 20 Apr '19

20 Apr '19

[01:32:55 CEST] <t-mullen> My raw video input has frames of variable size. How would I change the input size dynamically? Are video filters relevant here? [01:35:10 CEST] <cehoyos> That cannot work, where do the frames come from? [01:36:33 CEST] <t-mullen> They're dumped from an RTCVideoSink. Should I just scale the frames before passing them as input? [01:37:18 CEST] <cehoyos> I don't see how any application (not necessarily ffmpeg) is supposed to know where one frame ends and the next begins if they are not all the same size. [01:37:45 CEST] <t-mullen> I don't expect it to know, I wanted to know if there was a way to specify frame size alongside the frame. [01:38:01 CEST] <cehoyos> If it is one frame, you have no problem [02:41:23 CEST] <DHE> he's gone, but the raw swscale interface is probably the best bet. if resolutions are in a fixed set of possibilities, keep the contexts around I guess... [14:41:53 CEST] <shibboleth> some application using ffmpeg for streaming expects rtsp over udp [14:42:15 CEST] <shibboleth> is there any envvar that will use rtsp over tcp by default? [14:43:54 CEST] <JEEB> no, you just set the AVOption [14:44:34 CEST] <JEEB> rtsp_transport is one of udp, tcp, udp_multicast, http [14:44:40 CEST] <JEEB> default is udp [14:45:09 CEST] <JEEB> you set that to TCP and you get rtsp over tcp [14:45:16 CEST] <shibboleth> yeah, but the application doesn't let me specify rtsp transport [14:45:40 CEST] <JEEB> that is then a problem in the application rather than in the framework [14:45:47 CEST] <shibboleth> sure [14:47:02 CEST] <JEEB> if it's an open source application you can patch it of course. if it's not, then you will have to get the source code they used for FFmpeg (since by LGPL rules they have to give you it to be able to replace it) [14:47:17 CEST] <JEEB> and replace the copy used by the application :P [14:47:52 CEST] <JEEB> of course in any case I would recommend making a bug report to the application's vendor [16:56:04 CEST] <logicWEB> just thought I'd throw this out there, I spent the last few days developing this: https://gist.github.com/logiclrd/287140934c12bed1fd4be75e8624c118 [16:56:11 CEST] <logicWEB> I wanted film grain that wasn't just straight HD pixels [16:56:25 CEST] <logicWEB> I'm now running an encode and we'll see what it looks like but my previews looked hopeful :-) [17:00:39 CEST] <logicWEB> the one thing I'm unsure about is aq-strength -- someone on a forum said high aq-strength is great for preserving grain, he said to use 1.8 or 1.9, but -tune grain uses aq-strength 0.5, where the default is 1.0? [17:00:53 CEST] <durandal_1707> logicWEB: you should avoid use of geq at all costs, it is _bad_ [17:02:04 CEST] <durandal_1707> geq=lum='255-lum(X,Y)':cb=128:cr=128 this can be done much faster with lut filter [17:02:56 CEST] <logicWEB> bad as in slow or bad as in doesn't actually do what you were expecting? [17:03:05 CEST] <durandal_1707> geq=red_expr=random(1)*256:green_expr=random(1)*256:blue_expr=random(1)*256 --- this one you could use real noise like /dev/random [17:03:12 CEST] <durandal_1707> it is very slow [17:03:49 CEST] <logicWEB> I'm running on Windows so I don't have /dev/random :-P [17:07:02 CEST] <durandal_1707> logicWEB: you do not like noise filter grain? [17:07:57 CEST] <logicWEB> is `noise=alls=100:allf=t+u` equivalent to that `geq` thing? [17:08:29 CEST] <logicWEB> I just changed my command line to that and it is, as expected, much faster that 3 per-pixel general expressions at twice the video resolution :-P [17:09:08 CEST] <logicWEB> okay I just tested with ffplay, it's not the same [17:09:13 CEST] <logicWEB> even with alls=100 the noise is very dark [17:12:41 CEST] <durandal_1707> that is because you are supposed to use it directly on video [17:15:25 CEST] <furq> logicWEB: also just use c0s and omit hue [17:18:43 CEST] <durandal_1707> ffmpeg -f lavfi -i color=gray:s=vga,noise=alls=100:allf=t,hue=s=0,deflate=threshold0=15,dilation=threshold0=10,eq=contrast=3,scale=320x240 [17:18:47 CEST] <JEEB> squirrel: /25 [17:18:51 CEST] <JEEB> asdf [17:19:15 CEST] <durandal_1707> use that if you really need big noise patches [17:23:26 CEST] <logicWEB> also looks like my `geq=lum='256-lum(X,Y)'` can be done with `negate` instead more quickly [17:24:03 CEST] <durandal_1707> negate is actually lut filter :-) [17:36:29 CEST] <logicWEB> just did some tests, I can't actually tell the difference between aq-strength 0.5 and aq-strength 1.9, maybe because the CRF is so high? I guess I'll just go with what -tune grain recommends? [17:37:11 CEST] <furq> it's doubtful you'll notice the difference between any x264 settings at crf 12 [17:37:31 CEST] <furq> you could probably run ultrafast and not notice [17:37:47 CEST] <logicWEB> except I'd notice the filesize :-P [17:38:20 CEST] <furq> you'd be surprised [17:39:04 CEST] <logicWEB> oh yeah? I mean, I compared veryfast with veryslow and got a file that was twice the size... [17:39:54 CEST] <logicWEB> also I was reading about it in a little bit of depth a week or two back and read that while the _intent_ is for the speeds to have virtually no effect on the quality in CRF mode, _in practice_ veryslow turns some features on that _in some rare cases_ will find better solutions for things and actually look better [17:40:09 CEST] <logicWEB> if there's even a tiny effect I'm willing to pay an extra day of CPU time :-P [17:53:15 CEST] <scottchiefbaker> What is the current status of the native AAC encoder? [17:53:29 CEST] <JEEB> it's pretty usable for LC-AAC [17:53:29 CEST] <scottchiefbaker> Is it still sub-par quality compared to the fdk one? [17:54:17 CEST] <JEEB> there are some specific use cases where it seems to handle some things worse but in general I would have no issues utilizing it given that the binaries can be re-distributed with GPL stuff like x264/5 enabled [17:54:39 CEST] <scottchiefbaker> JEEB: Ok good. [17:54:40 CEST] <scottchiefbaker> https://trac.ffmpeg.org/wiki/Encode/AAC#NativeFFmpegAACEncoder [17:54:57 CEST] <scottchiefbaker> Do you know anything about the VBR stuff? Is the VBR still a work-in-progress? [17:55:03 CEST] <scottchiefbaker> or should I just stick to CBR [17:55:20 CEST] <scottchiefbaker> "This VBR is experimental and likely to get even worse results than the CBR." [17:55:34 CEST] <JEEB> not sure when that line was written or by whom - and I haven't checked myself [17:55:56 CEST] <JEEB> so can't say anything one way or another [17:56:11 CEST] <JEEB> (esp. since I generally just set a bit rate like 96-192k) [17:56:27 CEST] <scottchiefbaker> a range? or a specific bitrate? [17:57:07 CEST] <JEEB> specific [17:57:13 CEST] <JEEB> something from that area [17:57:39 CEST] <JEEB> for local usage I usually go 192k since I don't generally re-encode unless I absolutely have to, and if I have to for local usage I have no real need to skimp on bits [20:50:52 CEST] <irwiss> i've been looking at https://ffmpeg.org/doxygen/4.1/hw__decode_8c_source.html and it seems to grab the hw device type from the cli args, ffmpeg returns all of cuda, dxva2, qsv, d3d11va "available" on this laptop but afaik intel integrated gpus can't use cuda? trying to open it seems to fail at av_hwdevice_ctx_create, so my question is; what's the s [20:50:52 CEST] <irwiss> trategy for detecting the correct type to open, a list sorted by priority and just trying until success or fallback to software? [20:53:01 CEST] <irwiss> also qsv seems to fail as well though it looks like it should work, is my hardware not compatible (Iris 540) or do i need the Intel Media SDK which https://trac.ffmpeg.org/wiki/Hardware/QuickSync warns not to install unless you need it, but i guess that folds into the question; how do i figure out which hw type out of the ones ffmpeg lists to open [20:53:46 CEST] <JEEB> you as an API or otherwise user should know what you should attempt on a specific piece of hardware. what is available is just what's available in the build of FFmpeg you have around [20:54:10 CEST] <JEEB> for decoding in Windows you generally want to use either dxva2 or d3d11va in any case [20:54:11 CEST] <irwiss> ah so "available" is just compile time "flags" [20:54:22 CEST] <JEEB> yes, they're available in the build [20:54:34 CEST] <JEEB> so when you attempt them the framework will attempt to utilize them [20:54:53 CEST] <JEEB> and then fail in case where you don't have the required stuff [20:55:19 CEST] <JEEB> but yea, on windows it's pretty simple since pretty much everything puts their hardware decoding into the windows APIs [20:55:27 CEST] <JEEB> thus dxva2 or d3d11va [20:57:04 CEST] <irwiss> i suppose if on windows i should try d3d11 then dxva2(which seems to be dx9) then fall back to software, can i just try opening them one by one until i succeed? or do i need to destroy the format/codec context [20:57:48 CEST] <JEEB> avformat context is separate anyways so no real need to close that [20:58:04 CEST] <JEEB> just keep the AVPackets around to feed the same stuff into the decoder [20:59:03 CEST] <JEEB> also I think your hw decoding context creation generally fails way before you start feeding it AVPackets I think? [20:59:20 CEST] <JEEB> (into the AVCodecContext [20:59:35 CEST] <irwiss> it looks like i'm not feeding packets yet by the time this fails, yep i was just wondering if trying to open hw context changes some internal ffmpeg state on those structures [21:00:10 CEST] <irwiss> guess i'll try and find out, hopefully it crashes before someone reports it doesn't work on their machine, thanks for the help! [21:00:11 CEST] <JEEB> avformat instance should be quite separate from the avcodec instance(s) you initiate [21:00:38 CEST] <JEEB> yea, unfortunately some hardware decoders have been less fun to deal with - but that could happen even without any mistake on your side :) [21:00:50 CEST] <JEEB> feed some funky bit stream to the hw decoder and receive bacon in the sense of BSoD [21:01:13 CEST] <JEEB> thankfully lately such drivers or hw decoders on PCs are starting to become more rare [21:01:17 CEST] <irwiss> yeah i'll try restarting just the codecs first, the startup sequence seems to be blazing fast [21:01:35 CEST] <irwiss> and fingers crossed no driver bugs with bsods :D [21:03:37 CEST] <JEEB> in mpv I think after X amount of failures with hwdec we fall back and create a swdec instance [21:04:20 CEST] <JEEB> also I've found that hwdecs are much more likely to bail out with a broken/unsupported bit stream [21:04:37 CEST] <JEEB> the FFmpeg swdec is trying quite hard :) [21:07:22 CEST] <JEEB> also the biggest difference between d3d11va and dxva2 seem to be indeed the newer/older back-end on the D3D side. which also means that with dxva2 you can get native D3D9 GPU surfaces, and with d3d11va you can get native GPU D3D11 surfaces [21:17:10 CEST] <irwiss> yeah my follow up task is trying to figure out if i can somehow supply my own d3d11 surface into the decoder, even with hw decoding but then juggling the buffers through system ram appears to be too slow for 4k videos on this laptop though vlc and mpv run the video just fine and so it looks like the roundtrip through system ram kills performance, s [21:17:10 CEST] <irwiss> earching the intertubes provides very little info on the subject but ffmpeg apis in the docs look promising [21:28:54 CEST] <__raven__> hi [21:30:08 CEST] <__raven__> processing images to video clips sometimes leads to an endless loop caused by "invalid data found..." due to negative duration. how to exit that? [00:00:00 CEST] --- Sat Apr 20 2019

1 0

ffmpeg-devel.log.20190418
by burek 19 Apr '19

19 Apr '19

[09:41:24 CEST] <cone-591> ffmpeg 03Sam John 07master:88325f4b34dd: Updated documentation for libaom encoder options. [13:41:18 CEST] <cone-915> ffmpeg 03Carl Eugen Hoyos 07master:09f8b21deb16: doc/encoders: Fix libvpx option name arnr-maxframes. [14:45:43 CEST] <cehoyos> Hi! vaapi works fine here, can anybody explain to me what I have to do to use qsv? I did install libmfx, what else is needed? Where do I get the necessary shared library? [14:47:00 CEST] <BtbN> iirc you need a special kernel and the Intel Media SDK for Linux from their Developer Resources [14:47:15 CEST] <BtbN> There isn't really any reason to use QSV on Linux [14:47:27 CEST] <cehoyos> So on Linux qsv never works without a patched kernel? So I don't want to use it, correct? [14:47:48 CEST] <BtbN> libva just works and offers almost the exact same features [14:47:59 CEST] <cehoyos> On Windows, qsv is the only hardware acceleration (with Intel) for encoding, right? [14:48:04 CEST] <BtbN> yes [14:48:12 CEST] <BtbN> Well, and d3d11va for decoding [14:48:22 CEST] <cehoyos> (And dxva2) [14:48:30 CEST] <BtbN> Same thing but kinda dead [14:48:35 CEST] <cehoyos> And do I need anything apart from libmfx on Windows? [14:48:43 CEST] <cehoyos> It worked when I tested it yesterday. [14:48:53 CEST] <cehoyos> Patching the kernel maybe? [14:48:56 CEST] <BtbN> Everything comes with the driver. If you use libmfx_dispatch, that's all you need. [14:49:05 CEST] <cehoyos> Ok, will test, thank you! [14:51:08 CEST] <BtbN> https://github.com/Intel-Media-SDK/MediaSDK also seems to be an official open source dispatcher library for both OS [14:52:54 CEST] <cehoyos> But several docs suggest to use libmfx [14:53:27 CEST] <cehoyos> Once you find out that the CMake.txt file is just a trap, it is not difficult to install (at least on Linux, I wonder how to autobuild on Windows) [14:58:21 CEST] <nevcairiel> i dont think the k ernel patches are needed anylonger on recent drivers [14:59:32 CEST] <BtbN> You crosscompile it from Linux or use MinGW I guess [14:59:59 CEST] <cehoyos> I use the subsystem now, works really great imo. [15:00:08 CEST] <nevcairiel> the official mediasdk from intel has a visual studio solution, you can also use that if you are not into mingw [15:00:13 CEST] <cehoyos> nevcairiel: So what is needed? [15:00:22 CEST] <cehoyos> On Linux, I mean. [15:00:37 CEST] <cehoyos> I don't have installed VS yet on this system [15:00:45 CEST] <cehoyos> Want to avoid it a little longer;-) [15:04:44 CEST] <nevcairiel> apparently qsv on linux is still as undocumented as ever [15:04:56 CEST] <nevcairiel> maybe jkqxz has some hints [15:05:39 CEST] <nevcairiel> a more portable encoding solution on linux is using vaapi [15:14:30 CEST] <JEEB> ya [15:14:43 CEST] <JEEB> thankfully intel added support for it as well, instead of trying to keep to qsv only [15:14:50 CEST] <JEEB> windows is the thing where you get sad [15:15:34 CEST] <BtbN> QSV works just fine on Windows though, as it comes with the driver you install anyway [15:15:43 CEST] <JEEB> yup [15:15:45 CEST] <BtbN> So the thin dispatcher is all you need [15:19:05 CEST] <cehoyos> Ok, will test [15:19:24 CEST] <cehoyos> Since there are many qsv reports that nobody ever tested, I would have liked to also install it on Linux though. [15:21:06 CEST] <BtbN> That chain of github stuff is what you need to figure out then [15:21:15 CEST] <cehoyos> I am building it right now. [15:21:24 CEST] <cehoyos> I wonder how to install: Won't it overwrite libmfx [15:21:26 CEST] <cehoyos> ? [15:21:41 CEST] <BtbN> I'd just install it somewhere in your homedir [15:21:50 CEST] <BtbN> never even giving it the change to install anything as root [15:24:11 CEST] <cehoyos> Ok, it loads the library now. [15:24:30 CEST] <cehoyos> It seems to be implemented so smart that it only works with additional parameters;-) [15:24:48 CEST] <wbs> nevcairiel: re patchwork, you're right with how it associates usernames; it stores a email->realname mapping, with the first sender name for each email address that it has gotten. and then, as you guessed, rewrites patches with a realname based on only the email address in the mail [15:31:38 CEST] <nevcairiel> yeah it seemed logical to do that [15:31:48 CEST] <nevcairiel> multiple people dont usually share mail addresses [15:32:08 CEST] <BtbN> So if you Typo your name the first time you send a patch, you're stuck with it forever? [15:32:57 CEST] <nevcairiel> presumably it updates the name [15:33:05 CEST] <nevcairiel> but there is still only one global record for every mail address [15:33:54 CEST] <nevcairiel> ultimately that rewrite script should really learn to insert From: lines into the pathc c ontent itself to fix it [15:34:18 CEST] <nevcairiel> .. and my spacebar is going crazy again [21:10:09 CEST] <wbs> BtbN: true. if you typo your name in the first patch, you need to ask the patchwork admin to reset it for you [22:04:25 CEST] <cone-741> ffmpeg 03Lou Logan 07master:d7e8e62797d8: doc/mailing-list-faq: add DMARC munging [23:37:04 CEST] <mkver> I just found out that I am affected by the mailing list name mangling. [23:37:45 CEST] <mkver> In fact, I am the author of the majority of the commits by "Oliver Collyer via ffmpeg-devel" on patchwork (https://patchwork.ffmpeg.org/project/ffmpeg/list/?submitter=776) [23:38:35 CEST] <mkver> But googlemail is just another name for gmail and plenty of people use gmail without issue. Does anyone have a clue why I could be different? [23:42:38 CEST] <durandal_1707> dunno, if pushed patch was wrongly attributed raise it on mailing list [23:49:57 CEST] <JEEB> we right now seem to have four mistakenly committed patches in the repo find'able with `git log |grep "via ffmpeg-devel"` [23:50:29 CEST] <durandal_1707> only four? what about Elvis ones? [23:50:42 CEST] <JEEB> this is specific to the "via ffmpeg-devel" stuff :P [23:56:30 CEST] <JEEB> mkver: it seems like those who committed ffmpeg-devel(a)ffmpeg.org e-mail addressed people at least downloaded the patches from the mailing list, and not patchwork. since the author name seems to be correct [23:57:03 CEST] <JEEB> so while patchwork doing not-so-nice things is bad, it doesn't seem to have been affected wrong name being put onto commits in the repo [23:59:13 CEST] <JEEB> or at least that's how it looks because there's no Oliver Collyer there, and just one occurence of each name [23:59:42 CEST] <mkver> Is the reason that e.g. Jamrial is not affected that he commits his stuff himself? [00:00:00 CEST] --- Fri Apr 19 2019

1 0

ffmpeg.log.20190418
by burek 19 Apr '19

19 Apr '19

[00:01:21 CEST] <nickster> ffserver command not found? Every solution I find just states to install ffmpeg but I already have that installed. [00:02:01 CEST] <another> ffserver has long been deprecated and recently dropped [00:03:40 CEST] <nickster> is it still possible to output to a website like with ffserver? [00:15:17 CEST] <another> output to a website? what do you mean by that [00:20:37 CEST] <nickster> ffserver gave one the option to throw up an http host or something, by the looks of it, and ffmpeg can stream right to it. [00:20:49 CEST] <nickster> It seems I am just going to have to work with udp/rtmp [00:21:34 CEST] <kepstin> for modern setups you normally want to serve up e.g. hls or dash for live streaming, and ffmpeg can output that directly to a directory, and any webserver works [00:21:55 CEST] <kepstin> or you can use something like the nginx-rtmp module, that's pretty popular [00:23:50 CEST] <another> or something like icecast [00:36:29 CEST] <friendofafriend> Yeah, icecast works great with MPEG-TS. [02:33:13 CEST] <analogical> I [02:34:51 CEST] <analogical> I've noticed something strange. Using ffpmpeg to download a files is much faster on Windows 10 and on Linux than it is on Windows 7 using the same computer. [02:35:26 CEST] <analogical> there shouldn't be any difference should there? [02:36:44 CEST] <another> hmm.. maybe the overhead of process spawning on windows? [02:37:47 CEST] <another> but that should apply to w10 too [06:09:35 CEST] <logicWEB> huh, curious. "... [a]; color=c=black:s=whatever:d=whatever [b]; [1][a] alphamerge [c]; [b][c] overlay" is almost twice as fast as just "... [a]; [1][a] blend=c0_mode=multiply" [07:09:05 CEST] <Mrjoker> what is better ? 720p or 1080i [07:21:16 CEST] <Buster> if deinterlacing is enabled then 1080i is better [07:23:18 CEST] <Mrjoker> buster can you even see the video if "deinterlacing" is not "enabled"? [07:25:16 CEST] <Buster> if there are a lot of dynamic scenes, it will look bad [08:27:33 CEST] <another> aaand he's back [09:16:45 CEST] <aleek> sup guys! ABR live streaming here! So I am able to generate a mp4 segment file with one frame - h264 key frame. I'd like to covert it to png/jpg/bmp - without ffmpeg. Code should be in c/c++. Any ideas? [09:17:07 CEST] <aleek> I have trouble finding any valuable information on the Internet ;( [09:21:20 CEST] <aleek> As I understand now, I have to dig into mp4's mdat segment, and treat it as h264 block [14:00:25 CEST] <kepstin> aleek: in order to turn that frame into a png/jpg/whatever, you're going to need an h264 decoder [14:01:02 CEST] <kepstin> aleek: probably the easiest h264 encoder to get is the one built in to ffmpeg... so why not just use ffmpeg? [14:02:15 CEST] <another> ffmpeg has no builtin avc encoder. it uses libx264 [14:03:03 CEST] <kepstin> er, typo. i meant decoder [14:03:04 CEST] <another> oh wait. i think you meant DEcoder [14:28:27 CEST] <aleek> so I can use x264 lib in this case [16:12:52 CEST] <Hello71> no. [16:13:04 CEST] <Hello71> well you can but it won't really help [16:14:37 CEST] <kepstin> aleek: x264 is an encoder only, it's not a decoder [18:49:54 CEST] <logicWEB> MrJoker: there's a trade-off to be made between the different options. 720p video will always "play nicely", with the caveat that you only have 720 scans of video. this is actually pretty good, really, but if you're frequently watching 1080p or 2160p content on a very large screen, your eye might be attuned enough to notice a slighty fuzziness about 720p video [18:50:04 CEST] <logicWEB> MrJoker: but... 1080i has some challenges in being played back well. an interlaced format presenting X frames per second is actually really 2X frames per second, but you're only getting half of each frame. so, with 30fps 1080i, you'll get a new picture 30 times per second, but each picture has (e.g.) all the even scans from one frame and the odd scans from another frame that comes after [18:50:20 CEST] <logicWEB> MrJoker: if you just play it like that, you'll see "combing" during motion, which, I mean, it's totally _possible_ to just put up with it and still enjoy the content, but it can be really annoying [18:50:31 CEST] <logicWEB> MrJoker: the other way to play 1080i content is to use a "deinterlacer", which splits that combined frame apart into the "parts of" the two original frames it was made up from. since each of these is only _half_ the original frame (even scans vs. odd scans), they aren't called "frames" per se, but "fields" of the combined frame in the 1080i source [18:50:59 CEST] <logicWEB> MrJoker: these split-out fields will then typically be played by using a heuristic to "guess" the pixels from the scans that aren't part of the field. so, basically, you're taking 540 scans and "guessing" the other 540 in between. the result is a frame with 1080 scans to put on your screen, but it doesn't actually have 1080 rows of detail. it's essentially 540 rows of detail [18:51:13 CEST] <logicWEB> MrJoker: so, you can think of 720p 30fps as just that, 720p 30fps, but 1080i 30fps as really more like 540p 60fps [18:51:35 CEST] <logicWEB> MrJoker: in my personal opinion, just going with 720p is a better experience than the artefacts that result from deinterlacing 1080i video [18:51:57 CEST] <logicWEB> MrJoker: but... this loss of resolution only happens vertically, so from left to right, a 720p video has 1280 pixels, while a 1080i video has 1920 pixels, so even though the 1080i video may be less sharp vertically, it can still be more sharp horizontally [18:52:16 CEST] <logicWEB> MrJoker: if you're trying to make a decision, I recommend trying it both ways and making a value judgment based on your own personal experience [18:53:59 CEST] <logicWEB> one thing I've seen is naively-encoded interlaced video where the frame is treated as progressive, and _that_ makes a mess because the combing is generally far too high frequency to fit into the bitrate constraints -- the result is that the fields interfere with each other, so even after they're split out by the deinterlacer, each one can suffer from a "ghost" of the other frame [18:54:21 CEST] <logicWEB> I don't have firsthand experience, but I'm pretty sure with proper settings, the encoder doesn't try to naively encode the alternating scans this way, and the issue _can_ be avoided [19:07:28 CEST] <irwiss> is it normal to get sporadic AVFrames where values for pts look like -9223372036854775808 1 90000 ? (pts first, the other 2 are time based num/denominator) do i just throw away such frames or i can somehow estimate pts in another way? [19:07:45 CEST] <irwiss> time base* [19:10:06 CEST] <JEEB> is it the NOPTS value? [19:10:26 CEST] <JEEB> AV_NOPTS_VALUE [19:12:58 CEST] <ChocolateArmpits> logicWEB, I find that with proper deinterlacing 1080i to be markedly better than 720p50/60. When having to key greenscreen footage the higher resolution really goes a mile. It's only really with poor deinterlacing that issues crop up. I personally advocate for QTGMC when quality is concerned. [19:15:15 CEST] <DHE> I've seen some mpegts streams where some packets have no timing data at all... [19:15:32 CEST] <JEEB> yes [19:15:45 CEST] <JEEB> for teletext f.ex. PTS is optional IIRC [19:16:04 CEST] <JEEB> so then all you can do is put it somewhere around pcr [19:21:02 CEST] <irwiss> NOPTS_VALUE seems to be 0x8000000000000000 which i guess is -1 signed? that weird -922.... number is sitting inside the frame->pts, and as far as i can see the stream does have pts usually, but some frames come with mangled one :( [19:25:30 CEST] <irwiss> yep looks to be no pts value for one specific frame [19:26:36 CEST] <DHE> JEEB: I've seen one feed where this is happening in the h264 video stream... :/ [19:27:09 CEST] <DHE> 0x8000000000000000 is the smallest possible integer. -1 has representation 0xFFFFFFFFFFFFFFFF [19:29:39 CEST] <irwiss> oh right, largest positive, but well the pts value on some frames appears to have the no_pts constant, while previous frame and the next appears to be fine, and time base is also preserved, guess i need to throw away the pts on frames like these if they come in a stream that normally provides pts [21:12:50 CEST] <kepstin> irwiss: consider using av_frame_get_best_effort_timestamp() which might give you something a bit more usable [21:13:55 CEST] <kepstin> er, let me double check that function name, i had some really old ffmpeg docs open [21:15:45 CEST] <irwiss> i think i used that before, but upgraded to 4.1 recently it claimed to be obsolete, unless i still need it [21:16:03 CEST] <kepstin> ah, just read the best_effort_timestamp directly from the frame struct now [21:45:25 CEST] <logicWEB> ChocolateArmpits: mm, yeah I guess it really make a big difference what you're using it for. but, it is really important that it be done right in the first place. here's a concrete example of it being done _really not right_: [21:45:27 CEST] <logicWEB> https://imgur.com/a/wGezjnG [21:46:01 CEST] <logicWEB> the first image comes off of the DVD of Pink Floyd's The Wall, that's exactly how the frame is on the DVD (except resized from 720x480 to 853x480 for aspect ratio) [21:46:24 CEST] <logicWEB> but the DVD is encoded as though it is progressive, and it just can't accurately represent the stark contrast from one scan to the next as it flips between the fields [21:46:46 CEST] <logicWEB> the second and third images are reconstructions of the fields (just using bicubic interpolation after extracting the relevant scans) [21:47:23 CEST] <ChocolateArmpits> I'd expect such a source to be telecined albeit with a field shift [21:51:21 CEST] <ChocolateArmpits> But while that's more common with improperly prepared DVD material, I don't really think high definition suffers from such mistakes simply because of more format options in terms of delivery. In my case having control over the video format makes for no problems in further interlace processing [00:00:00 CEST] --- Fri Apr 19 2019

1 0

ffmpeg-devel.log.20190417
by burek 18 Apr '19

18 Apr '19

[00:14:19 CEST] <cehoyos> durandal_1707: I want to but this is true for a long time... [00:25:50 CEST] <cone-514> ffmpeg 03James Almer 07master:cfe220332a8f: avcodec/cbs_av1: add support for Scalability Metadata [01:48:09 CEST] <cone-514> ffmpeg 03James Almer 07master:5006dcdf9af1: avcodec/cbs: add helper functions and macros to read and write signed values [01:48:10 CEST] <cone-514> ffmpeg 03James Almer 07master:3dc6adf326c8: avcodec/cbs_h2645: add helper macros for signed values [01:48:11 CEST] <cone-514> ffmpeg 03James Almer 07master:9bf520d04d61: avcodec/cbs_h264: fix storage type for time_offset in Pic Timing SEI [01:48:12 CEST] <cone-514> ffmpeg 03James Almer 07master:137c0fcad151: avcodec/cbs_h265: fix storage type for time_offset_value in Time Code SEI [01:48:13 CEST] <cone-514> ffmpeg 03James Almer 07master:e2f766e13f03: avcodec/cbs_av1: use the new signed value read/write functions [09:08:08 CEST] <seastar> hello, when I configure ffmpeg with --enable-libopenh264 parameter on windows using either msys2 or mysys, I get the following error: ERROR: openh264 not found using pkg-config [09:08:23 CEST] <seastar> how can I configure ffmpeg with --enable-libopenh264 parameter on msys2? [09:10:31 CEST] <rcombs> jkqxz: think you can get someone to take a look at this? https://github.com/intel/libva/pull/266 [09:15:52 CEST] <mkver> @seastar: You can take a look at the "media autobuild suite" https://github.com/jb-alvarado/media-autobuild_suite (in paticular build/media-suite_compile.sh) to see how they do it there. [09:18:07 CEST] <seastar> is the only solution media autobuild suite? [09:19:42 CEST] <mkver> Of course not. It's just a suggestion. [09:22:07 CEST] <seastar> I consider to use that solution but I am curious about any other solution [10:11:59 CEST] <cone-972> ffmpeg 03Steven Liu 07master:2a50f1d9e414: tests/fate: add fate-hls-segment-size for hls_segment_size test [16:39:14 CEST] <cone-580> ffmpeg 03Paul B Mahol 07master:a0559fcd81f4: avfilter/af_sidechaincompress: implement mode option [20:12:14 CEST] <mkver> @jkqxz: In ff_cbs_alloc_unit_content the opaque pointer for the free function is set equal to the CodedBitstreamContext. But in the actual free functions the (unused) opaque pointer is called "unit" (which would also make more sense to me). [23:43:12 CEST] <cone-858> ffmpeg 03Paul B Mahol 07master:8a3ed5a31364: avfilter/af_agate: implement mode option [00:00:00 CEST] --- Thu Apr 18 2019

1 0

ffmpeg.log.20190417
by burek 18 Apr '19

18 Apr '19

[00:25:35 CEST] <cehoyos> jamie_1: Combining --enable-shared with --static most likely makes no sense, what are you trying to do? [01:12:11 CEST] <TheSashmo> @kepstin I was thinking about that, but had no clue where to start..... any direction? google is coming up short on that search... LOLOL [03:30:14 CEST] <xyz111> Hi Guys, I wanted to validate this idea with people more knowledgeable than me: I want to create a little video editor on linux, which piggybacks on ffmpeg. Basically, the front end would be a shell issuing commands to ffmpeg. I want the software to be able to cut videos, fade videos, extract audio etc etc. Most importantly, I want to be able to see the composited results in realtime. Would all this be viable, or am I oversimplifying the proble [03:32:54 CEST] <klaxa> i think most open-source non-linear video editors already use ffmpeg for that [03:33:02 CEST] <klaxa> those that don't probably use gstreamer [03:35:59 CEST] <klaxa> i don't think you can offload real-time compositing very well through the cli though [03:46:03 CEST] <xyz111> thanks klaxa, what is usually used for realtime compositing? [03:48:03 CEST] <klaxa> hmm, not sure, opengl? i might be way off, but as i understand it, a non-linear video editor would just use ffmpeg for decoding/demuxing and encoding/muxing, so you'd have to write your timeline which holds all the frames yourself [03:48:13 CEST] <klaxa> that would then be displayed with whatever GUI framework you are using [03:50:45 CEST] <klaxa> it may be a good idea to look at other software that does similar things? kdenlive and pitivi come to mind [03:51:58 CEST] <klaxa> https://en.wikipedia.org/wiki/List_of_video_editing_software#Free_and_open-… might also be a good point to start looking? [04:18:09 CEST] <klaxa> it feels like after watching wataten my life is now complete and i can die in peace [04:34:05 CEST] <klaxa> oh shit, wrong channel [04:54:33 CEST] <xyz111> thanks again klaxa - I will investigate further! [05:05:07 CEST] <nickster> dealing with a.... weird issue here [05:05:15 CEST] <nickster> https://youtu.be/kiRLVcEaw74 [05:05:33 CEST] <nickster> using x11grab and trying to use that as a webcam with v4l2loopback [05:06:17 CEST] <nickster> > ffmpeg -f alsa -i pulse -f x11grab -r 15 -s 1280x720 -i :0.0+0,0 -f v4l2 /dev/video0 [05:06:38 CEST] <nickster> only thing i could get to recognize the video is obs [05:06:52 CEST] <nickster> it records to file fine so im thinking this may be an v4l2 issue [08:48:40 CEST] <ossifrage> Does ffmpeg support a simple ycrcb file format (like pnm) that has embedded image dimension data? [08:52:44 CEST] <JEEB> ossifrage: y4m and NUT are usually utilized for raw video without or with timestamps [08:52:52 CEST] <JEEB> y4m is a relatively simple, constant frame rate thing [08:54:48 CEST] <ossifrage> JEEB, that would work, thanks [08:58:35 CEST] <ossifrage> JEEB I never managed to get my DTS timestamps to work right when trying to generate fmp4, ended up punting and switching to rtsp until I can come back and look at it [09:05:28 CEST] <seastar> hello, when I configure ffmpeg with --enable-libopenh264 parameter on windows using either msys2 or mysys, I get the following error: ERROR: openh264 not found using pkg-config [09:06:07 CEST] <seastar> how can I configure ffmpeg with --enable-libopenh264 parameter on msys2? [09:06:28 CEST] <seastar> could anybody please help me? [09:27:11 CEST] <JEEB> seastar: look at ffbuild/config.log ; it should show you what failed in the configure check [09:38:54 CEST] <seastar> gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1 -D__printf__=__gnu_printf__ -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -std=c11 -fomit-frame-pointer -ID:/msys64/mingw64/include -LD:/msys64/mingw64/lib -c -o /tmp/ffconf.mFXThrca/test.o /tmp/ffconf.mFXThrca/test.c [09:38:54 CEST] <seastar> D:/msys64/tmp/ffconf.mFXThrca/test.c:1:10: fatal error: wels/codec_api.h: No such file or directory [09:38:54 CEST] <seastar> #include <wels/codec_api.h> [09:38:54 CEST] <seastar> ^~~~~~~~~~~~~~~~~~ [09:38:54 CEST] <seastar> compilation terminated. [09:38:56 CEST] <seastar> ERROR: openh264 not found using pkg-config [09:40:46 CEST] <seastar> JEEB: config.log file contains error lines above [09:42:36 CEST] <JEEB> either you're lacking a header, the pkg-config pc file doesn't contain the correct location (or you haven't defined a sysroot) or openh264 changed their API [09:45:28 CEST] <seastar> I copied the pc file to another location so that pkg-config command can show location of the library, but I still get the same message [09:46:22 CEST] <seastar> should I define sysroot on msys2? how can I verify it? [09:48:23 CEST] <JEEB> changing the location of the pc file does not change the result [09:48:58 CEST] <JEEB> if you defined a custom --prefix when building openh264 that should have added the needed -I/-L [09:49:01 CEST] <JEEB> into the pc file [09:49:02 CEST] <JEEB> OR [09:49:14 CEST] <JEEB> if you are utilizing a reusable sysroot [09:49:22 CEST] <JEEB> then you will have to tell pkg-config about it [09:49:23 CEST] <JEEB> :P [09:49:37 CEST] <JEEB> which is PKG_CONFIG_SYSROOT_DIR as an env var [09:49:44 CEST] <JEEB> if I recall correctly [09:56:01 CEST] <seastar> openh264 doesn't have configure file, and I didn't change prefix line of its makefile. [09:56:21 CEST] <seastar> PKG_CONFIG_SYSROOT_DIR variable is undefined [09:58:06 CEST] <seastar> I also tried to change prefix line, and to use -L and -I parameters to configure ffmpeg, but the result hasn't changed [09:59:24 CEST] <seastar> I mean I built openh264 with another prefix to provide with it to ffmpeg using -I and -L parameters [09:59:39 CEST] <seastar> but nothing has changed. I got the same error [10:06:48 CEST] <logicWEB> I'm trying to encode video with film grain in it. I know the source video is pristine, because it's the output of a timeline in kdenlive. kdenlive does its video rendering using the MLT framework, which, as I understand it, ultimately wraps ffmpeg and the related encoding libraries at its core. so, I have this video to which I am _adding film grain_ using a kdenlive filter, and I'm trying to produce an output file -- at any cost -- t [10:07:40 CEST] <logicWEB> based on tweaking after reading various forum posts, I am currently using settings: preset=veryslow g=120 crf=1 tune=film aq-strength=1.8 [10:08:52 CEST] <logicWEB> this is _pretty good_, but it's not perfect -- the film grain does sort of a global shift about every 5-7 frames, and otherwise is kept the same frame-to-frame with a little bit of flickering [10:09:22 CEST] <logicWEB> does anyone have any advice on how to tweak the settings in order to actually preserve the unique grain in every frame? framerate is ntsc-film in case that matters [10:09:55 CEST] <logicWEB> I was wondering whether it might be an option to disable P and B frames entirely? [10:13:11 CEST] <logicWEB> complicating matters is that I'm not sure if my video encoder options are being passed through to the underlying encoder by MLT -- I tried "keyint=1 weightp=0 weightb=0 bframes=0 scenecut=0 no-open-gop=1" and it didn't seem to make a difference [10:13:32 CEST] <logicWEB> (that is the syntax MLT uses for other options) [10:15:28 CEST] <redliondj> hi there does any1 know why am I getting the following error ? [10:15:32 CEST] <redliondj> Error while decoding stream #1:0: Invalid data found when processing input [10:16:18 CEST] <logicWEB> okay another complicating factor is that the Grain filter in kdenlive might not actually be producing unique grain per frame, I just jacked up the grain amount so I could see it easily and stepped through the early video frame by frame and it doesn't appear to be updating every frame, so that certainly doesn't help! :-/ [10:18:01 CEST] <logicWEB> so maybe the video encoding is doing exactly what I want and the source isn't what I expect, guess I need to go sort this out with the kdenlive folks first :-P [10:21:55 CEST] <redliondj> https://pastebin.com/PsR5KcZ9 [10:22:14 CEST] <redliondj> I am tring to add a turkish subtitle [10:22:38 CEST] <redliondj> I tried to change my locale settings bw exporting LC_ALL and LANG [14:59:08 CEST] <Zgrokl> I currently save a stream from dvb and sometime the sound got desync with video with the error : Non-monotonous DTS in output stream 0:0; [14:59:24 CEST] <Zgrokl> since it's random it means that it source that is fucked up or not ? [15:09:10 CEST] <JEEB> Zgrokl: use something like multicat to dump the input and then inspect problematic points with DVB Inspector or so. [15:09:39 CEST] <JEEB> multicat has examples in its repo on how to set up a window of X hours or whatever for dumping [17:37:09 CEST] <redliondj> hi I am tring to add a turkish subtitle but I get following issue [17:37:11 CEST] <redliondj> https://pastebin.com/PsR5KcZ9 [17:47:40 CEST] <nickster> oh hey i got a legit ffmpeg question now [17:47:47 CEST] <nickster> fixed the weird v4l2 issue though [17:48:03 CEST] <furq> redliondj: did you try using -sub_charenc [17:48:12 CEST] <nickster> anyway, what about recording input from certain applications as a "virtual" microphone? [17:48:26 CEST] <nickster> i know how to record certain applications [17:48:54 CEST] <furq> that's more of an alsa/pulse question [17:48:58 CEST] <nickster> but i cant find out how to make a virtual microphone with it [17:49:14 CEST] <nickster> https://trac.ffmpeg.org/wiki/Capture/ALSA [17:49:42 CEST] <nickster> i can get the alsa / pulse stuff but just as there is a /dev/video0 is there a /dev/audio0 or smth? [17:49:45 CEST] <nickster> or am i just naive [17:50:01 CEST] <kepstin> with alsa, you can set up an aloop device and have your application output audio to that rather than to speakers (or maybe both, if you set up your alsa config appropriately) [17:50:14 CEST] <kepstin> with pulseaudio, easiest is to capture from the output monitor device [17:50:30 CEST] <kepstin> (that's not a single application, rather it's all the audio being output by your computer) [17:50:38 CEST] <nickster> ye I looked into that but the issue is because this machine is a virtual machine and I haven't gotten any virtualized audio devices to work. [17:50:54 CEST] <kepstin> aloop should work for that use case [17:51:08 CEST] <nickster> It can record audio to file no problem, but I can't configure a loopback with any tested configuration so far. [17:51:26 CEST] <furq> there's a pulseaudio loopback module that should do what you want [17:52:12 CEST] <kepstin> on a virtual machine with no sound card, pulseaudio should start with a dummy device by default, and you can just record off the monitor of that [17:54:13 CEST] <furq> 16:49:42 ( nickster) i can get the alsa / pulse stuff but just as there is a /dev/video0 is there a /dev/audio0 or smth? [17:54:17 CEST] <furq> there was back in the oss days [17:54:24 CEST] <furq> i guess this is still a thing on freebsd [17:54:46 CEST] <furq> there are alsa compat modules that reinstate /dev/dsp etc but i don't think they'll help you much [17:57:00 CEST] <nickster> my goal is to get hangouts to recognize the loopback [17:57:10 CEST] <nickster> its not behaving thoough. [18:00:06 CEST] <nickster> most all things im finding say to edit the recording device and enable loopback [18:00:24 CEST] <nickster> but that isnt an option for me [18:00:31 CEST] <nickster> i may ask alsa/pulse [18:00:34 CEST] <nickster> thanks for the help though [18:14:11 CEST] <redliondj> furq I looked in the documentation but could not find any ifno on the option [18:14:58 CEST] <redliondj> I remember ahving seen something like this when using special filters that "hardburns" the sub [18:19:44 CEST] <furq> redliondj: -sub_charenc ISO8859-9 -i foo.srt [18:19:49 CEST] <furq> or whatever the subtitle encoding is [18:22:38 CEST] <redliondj> ok furq [18:25:29 CEST] <redliondj> thx that seems to have done the trick [20:16:48 CEST] <friendofafriend> ls -l [20:17:00 CEST] <friendofafriend> Oh no. Is the trac.ffmpeg.org site down? [20:17:40 CEST] <ChocolateArmpits> doesn't work for me as well [20:18:33 CEST] <friendofafriend> I never realized how totally helpless I am without it. [20:19:02 CEST] <zeromind> just slow for me, takes ~1min to load per page [20:19:27 CEST] <ChocolateArmpits> friendofafriend, try web.archive.org for cached pages [20:19:58 CEST] <friendofafriend> Yeah, no results. https://web.archive.org/web/*/http://trac.ffmpeg.org/wiki/Encode/H.264 [20:21:20 CEST] <ChocolateArmpits> try https :) [20:21:26 CEST] <ChocolateArmpits> Or http://archive.fo/epBXJ [20:21:55 CEST] <ChocolateArmpits> through web archive should provide links to other pages as well [20:22:07 CEST] <friendofafriend> Oh sorry, I thought it was just HTTPS-Everywhere giving me that address. http works great. Thank you so much. [20:22:44 CEST] <friendofafriend> Is there an archive of trac somewhere? I'm referencing it enough that I should probably have it offline. [20:22:55 CEST] <furq> it's back up now [20:23:12 CEST] <furq> it was actually timing out for a minute there [20:23:36 CEST] <friendofafriend> I don't know, I'm still heckuva long load times. [20:24:08 CEST] <furq> maybe not then [20:36:59 CEST] <friendofafriend> Maybe we could pass around a mirror of trac in a torrent. [20:39:17 CEST] <furq> i'm sure it's backed up [20:42:17 CEST] <friendofafriend> I just don't want to mirror it without permission. I know that's not very nice. :) [22:28:00 CEST] <budRich> hello, something is acting up when im trying to make a screenrecording, when my mic is turned on.. never had problems with this before. error code: [22:28:24 CEST] <budRich> ALSA lib pcm_dsnoop.c:638:(snd_pcm_dsnoop_open) unable to open slave [22:28:39 CEST] <budRich> [alsa @ 0x5582d7ad1c00] cannot open audio device default (Device or resource busy) [22:29:22 CEST] <budRich> command used to start recroding: ffmpeg -y -f x11grab -s 1600x900 -i :0.0+0,0 -f alsa -i default -c:v libx264 -preset ultrafast -crf 0 -acodec mp3 [22:29:56 CEST] <budRich> works when i disable the microphone in pavucontrol.. [22:30:32 CEST] <budRich> it's like the mic is already being used.. can i see what's using it somehow? [22:30:47 CEST] <another> try using pulse instead of alsa [22:31:17 CEST] <budRich> another: just replace -f alsa with -f pulse? [22:33:23 CEST] <budRich> another, thanks that worked, but still strange, i have been using the same command for years never any issues, i get the feeling, something is not right with my where my microphone.. [23:56:46 CEST] <friendofafriend> Hello. I've got this MPEG-TS stream from a live source, works great but over time there's more and more delay. Is there a way to reduce the amount of delay clients experience after watching for a long time? [00:00:00 CEST] --- Thu Apr 18 2019

1 0

ffmpeg-devel.log.20190416
by burek 17 Apr '19

17 Apr '19

[00:44:14 CEST] <cone-842> ffmpeg 03Carl Eugen Hoyos 07master:c3aa4844f393: lavfi/fspp: Remove two unused macros. [02:03:05 CEST] <cehoyos> JEEB: Please push if the patch is ok. [02:52:23 CEST] <cone-842> ffmpeg 03fumoboy007 07master:036b4b0f8593: avcodec/videotoolbox: add support for 10bit pixel format [05:25:08 CEST] <unlord> I'm sure you all saw https://www.reddit.com/r/AV1/comments/bdmk6h/32bit_ffmpeg_and_libaom_curren… [08:37:19 CEST] <JEEB> unlord: interesting if only 32bit is borked and not from libaom's side. funny enough when I used avisynth more getting the extra speed from 64bit encoding was worth it so I would utilize avs2pipe and friends to get the video data into a 64bit encoder process :) [11:40:16 CEST] <nevcairiel> I really don't see how that could be our crash [11:40:39 CEST] <nevcairiel> It reads like all of those people use some pre-built third-party binary [11:40:52 CEST] <cehoyos> which crash? [11:40:58 CEST] <nevcairiel> so presumably what really changed is the libaom version [11:41:12 CEST] <nevcairiel> https://www.reddit.com/r/AV1/comments/bdmk6h/32bit_ffmpeg_and_libaom_curren… https://trac.ffmpeg.org/ticket/7844 [11:41:33 CEST] <cehoyos> You could build locally and test... [11:42:01 CEST] <nevcairiel> I could, but that would go against my prime directive of being lazy! [11:42:51 CEST] <nevcairiel> mostly because i dont have libaom handy anyway [11:46:58 CEST] <cehoyos> There is no repo? [11:47:00 CEST] <cehoyos> ;-) [12:06:23 CEST] <nevcairiel> crashes in some simd function in libaom, so unless they changed their padding or alignment requirements without a major bump and didn't tell anyone, its likely their bug [12:15:20 CEST] <JEEB> nevcairiel: it's probably zeraenoe's binaries [12:16:17 CEST] <nevcairiel> crashes in my build as well [12:17:27 CEST] <JEEB> yea, that's how you were able to get the SIMD function [12:17:54 CEST] <nevcairiel> i just dont see how any change in ffmpeg might've caused this to start [12:18:04 CEST] <nevcairiel> especially between 4.1.0 and 4.1.1 as is claimed [12:18:04 CEST] <JEEB> yea [12:19:41 CEST] Action: JEEB just started getting angry comments about FFmpeg sucking with regards to SVT-AV1 and AOM crashes too, for some reason [12:19:48 CEST] <JEEB> I guess AV1 is popular today? :P [12:20:10 CEST] <JEEB> and getting more information from these people isn't exactly the simplest of things always [12:20:30 CEST] <nevcairiel> of course [12:20:37 CEST] <nevcairiel> oh well back to writing this config parser [12:20:48 CEST] <nevcairiel> i'm still wondering if i should bother to l earn some parser generator or just do it manually [12:27:45 CEST] <j-b> config parser? [12:29:15 CEST] <nevcairiel> basically an advanced ini file [12:29:45 CEST] <cone-857> ffmpeg 03Karthick J 07master:bcde9ec02056: avformat/dashenc: Disable streaming for webm output [12:30:37 CEST] <nevcairiel> meh i'll just do it manually, it only has like 5 syntax elements [12:59:13 CEST] <cehoyos> How do I build 32-bit libaom? [12:59:45 CEST] <cehoyos> JEEB: Is there a reason you did not push 2/2? [13:05:06 CEST] <JEEB> cehoyos: still needs a bump I think [13:05:15 CEST] <JEEB> and I was going to talk with the author [13:07:41 CEST] <cehoyos> A bump? [13:07:41 CEST] <JEEB> also it was late and I hadn't looked as much into the second patch :P [13:07:47 CEST] <JEEB> cehoyos: it adds a new av_* function [13:07:56 CEST] <cehoyos> Of course. [13:07:57 CEST] <JEEB> as far as I can see [13:07:59 CEST] <JEEB> :/ [13:08:05 CEST] <cehoyos> (In that case, I mean) [13:08:09 CEST] <JEEB> yea [13:08:30 CEST] <cehoyos> To answer my question: cmake -DCMAKE_CXX_FLAGS=-m32 -DCMAKE_C_FLAGS=-m32 ../aom [13:08:46 CEST] <JEEB> yes, with multiarch that should work :) [13:09:02 CEST] <JEEB> otherwise you have to either define a lot of stuff or a full cross-file [13:09:18 CEST] Action: JEEB kind of dislikes build systems with cross-files because mostly you just need --cross-prefix or something like it [13:09:37 CEST] <JEEB> of course if you need to override more stuff a separate file does start making sense [13:09:49 CEST] <nevcairiel> yeah the cross-file concept is weird, rather stick to cross-prefix, thats how most stuff works anyway [13:10:01 CEST] <cehoyos> I do not consider compiling x86_32 Linux on x86_64 Linux cross-compiling. [13:10:14 CEST] <JEEB> well yes, esp. with multiarch [13:10:32 CEST] <JEEB> I think my comments were more towards general cross-compilation with cmake/meson [13:10:45 CEST] <cehoyos> I still hope I can avoid this. [13:10:52 CEST] <cehoyos> (I won't test on Windows) [14:02:13 CEST] <cehoyos> Has anybody ever installed libmfx? [14:02:33 CEST] <cehoyos> FFmpeg and the github source disagree about the header location: I just wonder why this was never reported... [14:03:59 CEST] <BtbN> You are supposed to use mfx_dispatch [14:04:11 CEST] <cehoyos> And have you tried it? [14:04:19 CEST] <BtbN> On Windows on Cygwin, yes. Worked fine. [14:04:39 CEST] <cehoyos> Where did it install the header files? [14:04:50 CEST] <BtbN> No idea anymore [14:05:19 CEST] <cehoyos> The reason I ask is that the header files cannot be found by FFmpeg where the installer puts them. [14:05:30 CEST] <BtbN> Looking at the Makefile.am, they'd end up in /usr/include/mfx/*.h [14:05:54 CEST] <cehoyos> They ended up in /usr/include here [14:05:57 CEST] <cehoyos> (No mfx) [14:06:18 CEST] <BtbN> When you installed https://github.com/lu-zero/mfx_dispatch via autotools? [14:06:30 CEST] <cehoyos> via autotools? [14:06:38 CEST] <cehoyos> How do I install via autotools? [14:06:42 CEST] <cehoyos> Aaaaaaaaaaa [14:06:47 CEST] <BtbN> Yeah, it also supported cmake, which I didn't test [14:07:03 CEST] <cehoyos> The cmake is just for deception, well it hit me;-)) [14:07:20 CEST] <cehoyos> But that's really smart, I couldn't guess! [14:07:37 CEST] <nevcairiel> the cmake is vastly out of date [14:08:43 CEST] <nevcairiel> Personally on Windows I use the official intel variant though, since they fixed a bunch of stuff related to their new driver versions and finding the runtime libraries [14:09:00 CEST] <cehoyos> As said, this is a smart deception, not something that can be immediately understood [14:09:23 CEST] <BtbN> cmake and autotools supposedly both work (and haven't been touched in years) [14:09:37 CEST] <cehoyos> I don't think that is true [14:09:49 CEST] <nevcairiel> cmake doesnt work properly [14:10:11 CEST] <nevcairiel> at least the .pc.cmake is wrong in some ways [14:10:44 CEST] <nevcairiel> i had to deal with that only weeks ago [14:10:52 CEST] <nevcairiel> when i tried to figure out why the new drivers didnt work anymore [14:10:58 CEST] <nevcairiel> and ended up building with t he official one instead [14:11:31 CEST] <nevcairiel> i tried to copy its cmake thing to the official one so i could build it with gcc, so i noticed it needed some work =p [14:15:01 CEST] <cehoyos> Why is mfx not auto-detected? [14:22:10 CEST] <cone-857> ffmpeg 03Carl Eugen Hoyos 07master:1e8475b507ee: lavc/libaomenc: Mark a potentially unused variable as av_unused. [14:29:39 CEST] <cone-857> ffmpeg 03Carl Eugen Hoyos 07master:5ba769214f91: lavu/hwcontext_qsv: Mark a pointer as const. [14:32:10 CEST] <thardin> libmxf or libMXF ? [14:32:19 CEST] <nevcairiel> the intel one [14:32:25 CEST] <nevcairiel> mfx [14:36:04 CEST] <thardin> oh joy, another library called exactly "libmxf" [14:36:14 CEST] <JEEB> yea [14:36:15 CEST] <JEEB> :/ [14:36:19 CEST] <JEEB> unfortunate [14:37:00 CEST] <nevcairiel> mfx [14:37:04 CEST] Last message repeated 1 time(s). [14:37:04 CEST] <nevcairiel> :P [14:37:30 CEST] <nevcairiel> its a different order! [14:37:37 CEST] <nevcairiel> its not like its new though [14:37:43 CEST] <JEEB> ah right :D [14:37:43 CEST] <nevcairiel> it probably exists for 8 years by now [14:37:48 CEST] <JEEB> also yes, the library is old [14:37:52 CEST] <thardin> aha [14:37:57 CEST] <thardin> lol [14:38:02 CEST] <JEEB> (it shows that I deffo didn't get enough sleep) [14:38:22 CEST] <nevcairiel> i never get enough sleep, you get used to i t [14:38:26 CEST] <cehoyos> nevcairiel: gcc claims here that strftime() does not understand %s on mingw either [14:38:35 CEST] <nevcairiel> this is true [14:38:39 CEST] <cehoyos> hlsenc.c:1693 [14:38:40 CEST] <nevcairiel> because thats not gccs doing [14:38:51 CEST] <nevcairiel> gcc on mings compiles against the MS crt [14:38:54 CEST] <nevcairiel> mingw* [14:39:10 CEST] <cehoyos> Then why do we use %z on mingw? [14:39:29 CEST] <cehoyos> Didn't you block my patch changing this? Or do I misremember? [14:39:32 CEST] <nevcairiel> mingw likes to override some functions with its own variants [14:39:43 CEST] <nevcairiel> for better gcc-style compat [14:39:50 CEST] <nevcairiel> but not strftime afaik [14:40:25 CEST] <cehoyos> So what is the solution? [14:40:49 CEST] <nevcairiel> configure should really test this instead of some runtime test being performed [14:41:02 CEST] <nevcairiel> i recommended that to the author at the ti me, but apparently that never came as a follow up [14:41:16 CEST] <cehoyos> How can configure test this? [14:41:27 CEST] <nevcairiel> make a binary, execut it, see what happens [14:41:34 CEST] <cehoyos> When cross-compiling? [14:41:38 CEST] <cehoyos> As I do atm [14:42:38 CEST] <nevcairiel> we could also just adjust that guard there to account for mingw [14:42:42 CEST] <nevcairiel> or generally all windows in that case [14:43:06 CEST] <cehoyos> What is our preferred check for Windows in c files? [14:43:46 CEST] <nevcairiel> #ifdef _WIN32 typically, but you can't use that inline like the existing check [14:57:14 CEST] <cehoyos> How does "CYGWIN" relate here? Can CYGWIN target MSVCRT? [14:57:32 CEST] <BtbN> no, Cygwin is Linux for most things ffmpeg cares about [14:58:08 CEST] <BtbN> _WIN32 is also not defined on Cygwin [15:09:06 CEST] <cehoyos> nevcairiel: How do you know where libaom crashed when encoding on win32? [15:09:24 CEST] <cehoyos> I can reproduce the crash with wine but I don't get very useful debug information... [15:10:08 CEST] <nevcairiel> i just ran it through gdb and it showed that [15:11:25 CEST] <cehoyos> Found gdb in the packager... [20:56:49 CEST] <faLUCE> JEEB and others: (about patching when a patch includes also a modification to a file which is frequently changed, like configure) before format-patch, should I rebase my-dev-branch against local master or against origin/master ? [20:57:42 CEST] <nevcairiel> against the central master of course, thats what the patch has to apply against [20:59:12 CEST] <JEEB> faLUCE: the end result is what nevcairiel says. the branch you rebase against can be local or remote branch, but main thing is that you're rebasing against current central master :P [20:59:48 CEST] <faLUCE> nevcairiel JEEB: ok, then should I call: "git format-patch -o patches origin/master..HEAD" or is the last token unnecessary given that I already rebased? [21:32:24 CEST] <mkver> AVPacket's duration field says that a duration of 0 means "unknown". But how does one distinguish the case of an unknown duration (which probably means "show until the next subtitle (of this stream) is to be displayed) from a zero duration subtitle (like a comment that is not to be displayed at all)? [21:36:04 CEST] <JEEB> usually you decode the subtitle and then you get an AVSubtitle [21:36:35 CEST] <JEEB> which has its own fields [21:37:36 CEST] <mkver> I am more interested in the case of (de)muxing. [21:38:02 CEST] <JEEB> then you're usually at the behest of your input container [21:38:19 CEST] <JEEB> for example MPEG-TS just has zero [21:38:27 CEST] <JEEB> for pkt_duration [21:38:52 CEST] <mkver> But how should the demuxer set the duration field for a subtitle with an explicit duration of zero (as opposed to an unknown length duration)? [21:39:22 CEST] <nevcairiel> Also Set it to zero, not like you have options [21:39:42 CEST] <mkver> If the demuxer can't signal this, the information is lost and whatever works with this data will not be able to handle it properly. [21:40:16 CEST] <mkver> Duration is signed, so one could signal it by using a negative value or so. [21:40:20 CEST] <durandal_1707> cehoyos: you gonna add new codecs to mplayer svn code? [21:42:03 CEST] <JEEB> mkver: yea it's unfortunate - for AVSubtitles I noticed -1/UINT32_MAX is what got utilized [21:42:27 CEST] <nevcairiel> Is there really an actual semantic difference between unknown and no duration from a demuxer perspective? The decoder will figure out if there is a subtitle to show forever, or some other content [21:44:06 CEST] <nevcairiel> Ultimately both mean "I have no duration' [21:45:13 CEST] <mkver> Duration zero can also mean "I should not be shown at all." This way one could add comments. [21:46:17 CEST] <JEEB> yea, that's really format specific [21:46:21 CEST] <JEEB> unfortunately [21:46:54 CEST] <JEEB> if you then decode that and it actually has a subtitle that is supposed to be shown or not then that should be signaled in the decoded AVSubtitle [21:47:15 CEST] <JEEB> what formats are you specifically talking about btw, for reference? [21:48:34 CEST] <nevcairiel> The decoder will know that [21:48:40 CEST] <mkver> Matroska. It can distinguish between duration zero (for comments) and unknown duration. [21:48:40 CEST] <nevcairiel> Does the container have to? [21:50:17 CEST] <mkver> How should the decoder be able to find out when a subtitle is not to be shown? [21:50:40 CEST] <mkver> If said information is only stored at the container level and can't be forwarded? [21:50:45 CEST] <nevcairiel> The codec would have a way to signal comments of course [21:51:01 CEST] <JEEB> like ASS, which most likely are what have comment lines [21:51:10 CEST] <JEEB> the actual line contents contain a comment [21:51:36 CEST] <JEEB> also I'm trying to check what the matroska spec exactly says just out of interest [21:51:36 CEST] <nevcairiel> Trying to rely on duration 0 not being shown instead of shown until next seems very specific and likely to break in 90% of all software [21:51:52 CEST] <mkver> Really? What way do e.g. srt subtitles (S_TEXT/UTF8 in Matroska) have for this? [21:52:35 CEST] <nevcairiel> I don't really get the point of this feature. It's not like you have video frames that get silently skipped for no reason [21:52:49 CEST] <nevcairiel> On a demuxer controlled level no less [21:52:55 CEST] <mkver> Ok, then there is also the invisible flag in the (Simple)Block header, but this can't be exported either. [21:53:51 CEST] <JEEB> SRT IIRC has had all sorts of stuff put into it, I wouldn't be surprised if there's some ways of putting a comment into a line [21:53:54 CEST] <JEEB> but yes [21:53:57 CEST] <nevcairiel> Matroska likes to invent nonsensical features tbh [21:53:58 CEST] <JEEB> SRT is a format with an exact start and end time [21:54:07 CEST] <mkver> For videos, this feature (whether through duration zero or no the invisible flag) could be used for frame-accurate cutting, similar to edit lists for mov/mp4. [21:54:23 CEST] <JEEB> we already have virtual time lines, though? [21:54:29 CEST] <JEEB> in matroska [21:54:37 CEST] <JEEB> as part of chapters [21:55:11 CEST] <mkver> And if said start and end time coincide, it will be indistinguishable from a subtitle packet without a duration at all. [21:56:06 CEST] <nevcairiel> btw AV_PKT_FLAG_DISCARD exists for frames that should not be shown, but decoded [21:56:14 CEST] <nevcairiel> but good luck hoping that anyone implements that properly [21:57:25 CEST] <JEEB> mkver: anyways yea - currently the "unknown" duration thing is a mess [21:58:13 CEST] <JEEB> if you really need to hold that info on the demuxer/muxer level and can't decode [21:58:22 CEST] <JEEB> since a lot of stuff is thus format-specific :P [22:01:26 CEST] <mkver> @nev: You are right. That info can be exported. Thanks. Sorry for the noise. [22:01:29 CEST] <JEEB> and if we want to differentiate unknown (say, -1) and zero. we'd have to change quite a few [22:01:52 CEST] <nevcairiel> yeah something like that is unlikely to get changed without reaaaaally good reasons [22:01:58 CEST] <JEEB> or actually I'm not sure how many demuxers use -1 and which use 0 already [22:02:02 CEST] <nevcairiel> since its very hard to deprecate and inform callers [22:02:05 CEST] <JEEB> the default value is probably 0 [22:07:11 CEST] <JEEB> we do have some -1s although I'm not sure for how long those stay like that [22:07:21 CEST] <JEEB> git grep is not perfect [22:07:48 CEST] <nevcairiel> AVPacket->duration of -1 is technically invalid [22:09:02 CEST] <JEEB> looked with `git grep -E "duration\s*=\s*" -- libavformat/` [22:09:16 CEST] <JEEB> which isn't perfect but it has some seeming AVPacket sets [22:09:26 CEST] <mkver> @JEEB: If by "we" you mean FFmpeg, then I have to say that Matroska ordered chapters (the virtual timelines) are not really supported (just like the file linking stuff). The current code basically ensures that only the first edition will be used. [22:09:52 CEST] <nevcairiel> the subtitle queue stuff uses -1 as a special marker that means "set me to the start time of the next subtitle" [22:09:55 CEST] <nevcairiel> it should never reach the caller [22:10:25 CEST] <JEEB> mkver: yes I know, there was a lot of hurf and durf about it back in the day, and nowadays I think we kind of have a consensus'ish about making it metadata/side data [22:10:42 CEST] <JEEB> mkver: which is how seemingly ISOBMFF edit lists should have been implemented like [22:11:01 CEST] <nevcairiel> the edit list stuff constantly causes issues [22:11:06 CEST] <JEEB> yes [22:11:15 CEST] <JEEB> quite a few API users just disable the "advanced" edit list code [22:11:16 CEST] <JEEB> :) [22:11:24 CEST] <nevcairiel> indeed i do that myself [22:11:35 CEST] <mkver> In LAV? [22:11:40 CEST] <nevcairiel> i also was one to push for that option even being present [22:11:47 CEST] <JEEB> mkver: aye [22:12:00 CEST] <JEEB> mpv also disables it because it does things on the wrong layer [22:12:06 CEST] <JEEB> (it's a presentation layer thing) [22:12:51 CEST] <nevcairiel> technically the same applies to mkv [22:13:12 CEST] <JEEB> yes [22:13:15 CEST] <nevcairiel> but mkv is far more limited by implementation, and most files and tools around that were build against how haali made it work on a demuxer level, so it sort of works out [22:13:22 CEST] <JEEB> yup [22:14:51 CEST] <nevcairiel> for mp4 .. i dont remember ever getting a real request for such files anyway [22:18:02 CEST] <mkver> So all the edit lists that you encounter are of the type that just shift the pts of the first packet to zero? [22:18:41 CEST] <nevcairiel> something like that yea [22:18:45 CEST] <JEEB> that's 99% of it all. then there's both borked samples (clearly not meant to be what the edit list says), and some which might be output from a video editor... as a project file [22:18:58 CEST] <JEEB> because MOV files were also supposedly utilized as at least partial project files [22:23:26 CEST] <JEEB> anyways, exported to the presentation layer (API client), and then that layer can handle it in ways it requires/knows [22:23:59 CEST] <JEEB> I'm just happy that it's pretty rare we get people actually having issues with the on-by-default advanced edit list stuff [22:24:41 CEST] <JEEB> every now and then, like once in a few months or so on the user channel I have to explain people how to disable it [22:25:31 CEST] <mkver> @Nev: If there is no next subtitle packet and the duration is still -1, what does it get set to? [22:26:29 CEST] <JEEB> which layer? [22:26:37 CEST] <JEEB> or what was the context? :) [22:27:14 CEST] <mkver> "<nevcairiel> the subtitle queue stuff uses -1 as a special marker that means "set me to the start time of the next subtitle"" [22:45:29 CEST] <nevcairiel> would have to read the code, so you can do that too :D [22:46:30 CEST] <mkver> Ok. [00:00:00 CEST] --- Wed Apr 17 2019

1 0

ffmpeg.log.20190416
by burek 17 Apr '19

17 Apr '19

[00:25:27 CEST] <phinxy> I'd like to know if any of the libav* libraries uses libmp3lame. Maybe that's what you are trying to say. [00:26:33 CEST] <c_14> No, the problem is that the ffmpeg you built is being linked at runtime to your system's libav* libraries which aren't linked against lame [00:27:04 CEST] <c_14> So you either need to link the binary statically, or make sure they're linked at runtime to the libraries you built and not the system ones [00:58:52 CEST] <jamie_1> hey im trying to compile ffmpeg with nvidia and the script im using is https://pastebin.com/raw/AKvCRuHf but i keep getting ERROR: nvenc requested, but not all dependencies are satisfied: ffnvcodec [00:59:04 CEST] <jamie_1> anyone know what im missing? [00:59:38 CEST] <cehoyos> You have to install https://git.videolan.org/?p=ffmpeg/nv-codec-headers.git;a=summary [01:00:18 CEST] <jamie_1> im going and getting the nv headers and setting up the the nvcodec includes but it doesnt seem to recognise the nvcodec [01:01:28 CEST] <jamie_1> roughly lines 70-80 [01:01:44 CEST] <jamie_1> sorry roughly lines 60-70 [01:02:12 CEST] <cehoyos> Did you see the link that I posted? [01:02:18 CEST] <jamie_1> function InstallNvcoedIncluedERROR: nvenc requested, but not all dependencies are satisfied: ffnvcodec [01:02:27 CEST] <jamie_1> sorry [01:02:47 CEST] <jamie_1> didnt mean to send that again... scrolled in my terminal and bumped enter [01:04:24 CEST] <jamie_1> cehoyos: ill aim at that git instead and see how it goes [01:07:11 CEST] <Atlenohen> kepstin: gop size of 0 didn't made a difference with x264 [01:08:05 CEST] <Atlenohen> Ofcourse with other codecs such as FFV1 it's all fine, and by the way FFV1 is being described as an intra-frame codec, doesn't that mean that setting GOP anything higher than 0 for FFV1 doesn't make any sense? [01:08:43 CEST] <cehoyos> FFV1 allows setting gop-size but ths usually makes no difference for the output file, it may make a difference in the future [01:09:09 CEST] <jamie_1> any suggestions on how to point that scrip to use that source? i know how to do it from the videolan github but not sure how to do it from that git [01:09:11 CEST] <cehoyos> It is very hard to believe that setting a gop size to different values makes no difference with x264... [01:09:40 CEST] <Atlenohen> cehoyos: the x264 case was a context from 1 to 0 [01:09:55 CEST] <Atlenohen> probably is a difference, i meant practically no difference [01:10:40 CEST] <Atlenohen> The video quality gets horrible after a few seconds and progressively turns more murky even starting to look like weird corruption, even tho the bitrate is like 10K [01:10:40 CEST] <jamie_1> nvm... got it [01:11:45 CEST] <jamie_1> i will win against this ffmpeg compile XD [01:15:13 CEST] <jamie_1> even pointed and using that as the compile header for ffmpeg it still fails [01:17:55 CEST] <cehoyos> Yes, gop size 0 and 1 (both very unusual values) have the same effect with x264 [01:19:04 CEST] <cehoyos> jamie_1: "still fails" is not a very useful description of your issue. Please understand that scripts (and FFmpeg) are generally not supported. Install the nvheaders, run configure with current FFmpeg git head and tell us if nvenc gets enabled. [01:19:57 CEST] <jamie_1> oaky, ill go back and start there [01:27:18 CEST] <another> cehoyos: setting the gop for FFV1 absolutely makes a difference [01:28:16 CEST] <another> a larger gop compresses better [01:40:00 CEST] <cehoyos> another: I heard that but I never found an input sample that allowed me to reproduce. [01:41:39 CEST] <another> really? i'm pretty sure i have [01:45:06 CEST] <another> just did a quick encode of the sintel trailer in 480p [01:46:19 CEST] <another> with default GOP of 12: 84137977 bytes [01:46:32 CEST] <another> GOP 1: 85146234 bytes [01:49:05 CEST] <cehoyos> Good to know, thank you! [01:52:09 CEST] <another> there's also a wiki page which explicitly mentions GOP: https://trac.ffmpeg.org/wiki/Encode/FFV1 [02:01:28 CEST] <jamie_1> cehoyos: do i need to enable it in the config for nvcodec or will it do it based on that it's installed already [02:03:21 CEST] <cehoyos> It should be auto-detected. [02:03:47 CEST] <cehoyos> --disable-nvdec disable Nvidia video decoding acceleration (via hwaccel) [autodetect] [02:03:54 CEST] <cehoyos> Similar for nvenc [02:04:13 CEST] <jamie_1> okay [02:04:43 CEST] <jamie_1> running now :D [02:05:23 CEST] <jamie_1> thanks for the help btw cehoyos [02:05:31 CEST] <cehoyos> Was the detection successful? [02:05:58 CEST] <jamie_1> well see [02:06:02 CEST] <jamie_1> im compiling now [02:06:14 CEST] <cehoyos> You don't have to compile, didn't I write that above? [02:06:24 CEST] <jamie_1> i might have missed it... sorry [02:06:28 CEST] <cehoyos> run configure with current FFmpeg git head and tell us if nvenc gets enabled [02:07:04 CEST] <cehoyos> grep CONFIG_NVDEC config.h [02:07:20 CEST] <cehoyos> grep CONFIG_NVENC config.h [02:07:45 CEST] <cehoyos> ? [02:09:05 CEST] <jamie_1> cehoyos: i was reading the console output and it is there [02:09:07 CEST] <jamie_1> :D [02:09:10 CEST] <jamie_1> thanks! [02:09:34 CEST] <jamie_1> i also added/made all the extra packages, any i could make from source resonable i did [02:09:40 CEST] <jamie_1> and it looks like all of them are there [02:32:39 CEST] <jamie_1> so the only issue im having now is when i go to reference ffmpeg for compile i get recompile with -fPIC how would i do that with ffmpeg? [02:38:47 CEST] <furq> jamie_1: you build all the external libs you're trying to link to with fPIC [02:39:45 CEST] <jamie_1> ooff... so i have to go back to the beginning [02:40:48 CEST] <jamie_1> furq: is it possible to pass the --enable-static in the build config and do it that way? [02:41:32 CEST] <furq> maybe [02:42:00 CEST] <jamie_1> ehh, ill give it a go and find ouyt [02:42:17 CEST] <furq> if you actually want a fully static build then that should work [02:42:32 CEST] <furq> it'll be a lot quicker to find that out anyway [02:42:50 CEST] <jamie_1> furq: obs doesnt like the shared libraries [02:43:57 CEST] <jamie_1> furq: ill let you know [02:55:44 CEST] <jamie_1> furq: no good :( [02:56:04 CEST] <jamie_1> any ideas how to overcome the relocation R_X86_64_PC32 against symbol `ff_pw_9' can not be used when making a shared object; recompile with -fPIC without having to recompile EVERYTHING [02:56:19 CEST] <jamie_1> like the deps i have [02:56:31 CEST] <jamie_1> i dont mind compiling ffmpeg again... but all the deps would take a good minute [05:24:43 CEST] <unlord> I'm sure you all saw https://www.reddit.com/r/AV1/comments/bdmk6h/32bit_ffmpeg_and_libaom_curren… [05:35:22 CEST] <furq> i don't think that many people are really concerned about whether av1 and avisynth work properly together [05:35:49 CEST] <furq> Well there are plenty of filters that don't work with Vapoursynth. Like QTGMC, [05:35:53 CEST] <furq> this guy's done his homework [07:34:09 CEST] <Atlenohen> Hmm, weird, on windows libavutil/avconfig.h and libavutil/ffversion.h are not CRFL but LF ... this intended or just forgoten to be converted ? [07:37:16 CEST] <Atlenohen> Not sure if it's Git on windows or MSYS2 or the make build process responsible for this, these are include headers that are part of the finished build (make install) but maybe .h just get copied as is, not sure yet, [08:02:16 CEST] <Atlenohen> Wait so what's on the ffmpeg's repo in previous releases aren't the stable ones, only the tarball links on the front page are regarded stable? [08:03:08 CEST] <Atlenohen> For example 4.1.3-3 state which is like 2 weeks old from the release of 4.1.3, is not considered stable ? [08:04:35 CEST] <furq> huh [08:07:41 CEST] <Atlenohen> I cloned from 4.1, not from master, built and got the full version as 4.1.3-3-abcabcabc [08:09:14 CEST] <Atlenohen> A stable 4.1.3 was released on 4th April, today is 16 april and 4.1 branch has received more commits, is 4.1.3-3 right now considered stable or not? [08:09:54 CEST] <Atlenohen> My guess is not, by pure logic, but I'm just double checking [08:15:52 CEST] <furq> the 4.1 branch isn't stable, no [08:15:56 CEST] <furq> there's a tag for 4.1.3 [08:16:57 CEST] <furq> old branches don't get any new features but they are still actively worked on for bugfixes [08:18:41 CEST] <Atlenohen> Oh tags, right. Well in this case the difference shouldn't be that big to bother, but just to be sure, thanks. [08:29:23 CEST] <Atlenohen> Thanks guys for all the help, pretty much done with this chore, I'll probably be more personally interested in getting to know FFmpeg deeper later on when I'll be doing some of my own projects/ideas for myself that I've been having in the past, glad I got this job which finally got me over the hardest part that I kept delaying. [13:49:19 CEST] <Zucca> Hi. I have a looooooong video. I'd like to convert it to a time-lapse video. The video has 30fps frame rate, and I'd like to only take every 30th frame (essentially convert it to 1fps video) and then speed it up to 60fps so that one second is one minute in video. [13:49:35 CEST] <Zucca> Can this archieved losslessly? [13:51:01 CEST] <Zucca> When I think of it: drop 29 of 30 frames, then speed up by x60. That should not need any re-enconding. Right? [13:52:10 CEST] <Zucca> Also I don't have any audio to consider. [13:57:15 CEST] <cehoyos> Zucca: Please provide "ffmpeg -i" console ouput for your video. [13:57:20 CEST] <cehoyos> In most cases, this cannot be done. [13:57:37 CEST] <cehoyos> In most cases, what you ask for cannot be done. [13:58:08 CEST] <DHE> making a video of only keyframes might be doable, but it will at best constrain the speedup and/or output framerate. and the video bitrate will be rather high [13:58:51 CEST] <Zucca> It's ffv1 encoded. [13:58:54 CEST] <Zucca> Stream #0:0: Video: ffv1 (FFV1 / 0x31564646), yuv422p(progressive), 640x480, 30 fps, 30 tbr, 1k tbn, 1k tbc (default) [14:00:15 CEST] <Zucca> To to be able to do this I'd need to choose kayframing and codec propely or capture 1fps to begin with? [14:01:07 CEST] <DHE> a bit of both. there's -skip_frames nokey but that'll just produce a stuttering video [14:01:45 CEST] <cehoyos> Where is the problem? Simply re-encode to ffv1 (you cannot do codec copy for your usecase) [14:01:45 CEST] <Zucca> But since I have it as ffv1 already I can just re-encode it as ffv1 and lose onlt the dropped frames. [14:02:07 CEST] <DHE> yeah, being ffv1 at least you're not losing image quality here [14:02:47 CEST] <Zucca> cehoyos: I thought to get some speedups by doing stream copy. ;) But I'll go with re-encoding since it's the easiest way. [14:03:01 CEST] <DHE> so... ffmpeg -skip_frames nokey -r 3600 -i input.mkv -c ffv1 -r 30 output.mkv [14:03:10 CEST] <cehoyos> It is the only way because there is no raw ffv1 that you can feed into image2 [14:03:14 CEST] <DHE> I think... never tried this before [14:03:24 CEST] <cehoyos> This is not related to skip_frames [14:03:41 CEST] <DHE> but it would speed up the decoding step, hopefully providing at least some speedup [14:03:46 CEST] <DHE> assuming your GOP setting is sane-ish [14:04:35 CEST] <DHE> it may make the output video less consistent though [14:04:46 CEST] <Zucca> I have only used -c:v ffv1 when creating the video. [14:05:00 CEST] <furq> does -skip_frame nokey speed up ffv1 noticeably [14:05:19 CEST] <Zucca> I could test it... [14:05:41 CEST] <DHE> it's described as "skip decoding for the selected frames", so if you're dropping 90%+ of all frames, it sounds worthwhile [14:06:19 CEST] <cehoyos> Can we please agree that this is not the use-case for skip_frame? [14:06:35 CEST] <furq> it's not that uncommon of a use for skip_frame really [14:06:38 CEST] <furq> it is a hack though [14:07:05 CEST] <DHE> there's definite unknowns that prevent us from being sure it's a good idea [14:07:19 CEST] <Zucca> Sure it is. The only reason I like it a bit is the speedup... But I think I'll avoid it. [14:07:28 CEST] <furq> what is even the default gop size for ffv1 [14:08:37 CEST] <furq> apparently 12 [14:10:59 CEST] <King_DuckZ> hi, I have an AVCodecContext c on which I set c->profile = 1 and c->profile = 4, but that doesn't seem to have any effect on the output file [14:11:05 CEST] <King_DuckZ> codec is prores_ks [14:11:30 CEST] <King_DuckZ> how can I achieve the same effect that -profile:v X on the command line would have? [14:13:50 CEST] <cehoyos> It is supposed to work with prores_aw [14:14:16 CEST] <King_DuckZ> ah, so is it just not supported by prores_ks? [14:15:21 CEST] <cehoyos> Not in the way you tested it. [14:17:41 CEST] <King_DuckZ> ffprobe -show_streams is still reporting profile=unknown tho, even if I use prores_aw [14:18:03 CEST] <King_DuckZ> but I mean, if it can be made to work with prores_ks, then how do I do it? [14:18:26 CEST] <durandal_1707> via AVOptions [14:20:00 CEST] <DHE> AVDictionary *dict = NULL; av_dict_set(&dict, "profile", "auto", 0); avcodec_open2(avc_ctx, codec, &dict); [14:20:23 CEST] <DHE> (yes, AVDictionary** is intentional) [14:20:51 CEST] <King_DuckZ> DHE: ah I think I understand that, thanks [14:21:07 CEST] <King_DuckZ> so should I just leave c->profile to just 0 all the time? [14:21:57 CEST] <DHE> setting c->profile manually requires knowing the numerical codes for the profiles and they're not exported in a user header file. I would use the dictionary method [14:24:15 CEST] <DHE> (a very large number of options can be set this way - both codec-specific and otherwise) [14:25:02 CEST] <King_DuckZ> ah, I thought it was the constants from FF_PROFILE_* macros [14:25:15 CEST] <King_DuckZ> damn ok, I'll delete that and use the dictionary approach [14:26:38 CEST] <DHE> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/proresenc_kostya.c#… Oh? That's kinda interesting, because the source includes these duplicates. [14:26:55 CEST] <DHE> and those are what the AVDictionary code will expand them out to... [14:27:31 CEST] <DHE> at least they seem to be in the same order and all that [14:27:50 CEST] <King_DuckZ> T_T [14:27:54 CEST] <DHE> ikr [14:42:37 CEST] <Zucca> Since I still need to re-encode my video to get the time-lapse... I could set "keyframerate" to a very low value to save space. Right? [14:43:14 CEST] <Zucca> I ment for the video when I'm doing the initial capturing. [14:46:47 CEST] <furq> Zucca: a lower gop size will use more space [14:46:55 CEST] <furq> also it doesn't make a huge amount of difference with ffv1 [14:47:06 CEST] <Zucca> Hm. [14:47:10 CEST] <Zucca> Ok. [14:47:22 CEST] <furq> it obviously depends a lot on the content so you might as well try it on a short chunk [14:47:32 CEST] <furq> but i wouldn't expect more than a few percent [14:47:33 CEST] <Zucca> furq: [14:47:39 CEST] <Zucca> Well it's static mostly. [14:47:53 CEST] <Zucca> Timelapse from my yard. [14:48:12 CEST] <furq> you might want to use something like x264 lossless then [14:48:16 CEST] <furq> since that actually does inter compression [14:48:48 CEST] <Zucca> I've been trying out with vp9. But eventually went with ffv1. [14:49:28 CEST] <furq> i would definitely use x264 over vp9 for this [14:49:42 CEST] <Zucca> Why's so? [14:49:53 CEST] <furq> speed, mostly [14:50:12 CEST] <furq> also i know x264's lossless mode is fairly widely used whereas i don't think vp9's is [14:50:22 CEST] <furq> or libvpx's is rather [14:50:55 CEST] <furq> ffv1 is pretty nice but if you have a mostly static image then x264 should compress a lot better [14:51:27 CEST] <Zucca> Yeah. With vp9 I need to drop then capturing frame rate a bit. Although I might do it anyway. Since I'm doing timelapse I really don't need 30fps input. [14:52:22 CEST] <Zucca> 30fps is there because if somathing interesting happens I could extract it from the "master" and still get 30fps. [14:52:57 CEST] <Zucca> Oh well... I'll test out different options and see what suits the best. [14:53:25 CEST] <furq> if you don't get a decent size reduction with x264 then just stick with ffv1 [14:54:11 CEST] <Zucca> Yeah. ffv1 is suprisingly light with this task. Although the resolution isn't high. :P [15:00:15 CEST] <nicoulaj> could anyone tell me if HEVC hardware encoding is possible on Linux + AMD ? looks like AMF does not support Linux, and VAAPI/MESA only supports H264 if I'm reading the wiki correctly ? [15:50:06 CEST] <faLUCE> hello, are there cases in which AVFrame->pkt_duration of a demuxed packet is wrong? [15:51:25 CEST] <faLUCE> (pts are right, and evaluating the duration with pts - prev_pts gives ~3000, which is 33,3ms (30fps) if rescaled according to the demuxer time_base) [15:51:34 CEST] <faLUCE> but pkt_duration gives 6000 [15:52:10 CEST] <JEEB> generally that means that the value in the container might be incorrect (otherwise a bug) [15:53:07 CEST] <faLUCE> JEEB: ok, thanks. I wondered if there could be other reasons [15:54:55 CEST] <JEEB> I'm not sure if lavf tries to guesstimate you a value if the demuxer doesn't give you one. but I would think it wouldn't [15:56:11 CEST] <faLUCE> do you mean "if the muxer doesn't give you one" ? [15:56:26 CEST] <JEEB> if the muxer itself doesn't set the field [15:56:32 CEST] <faLUCE> ok [15:56:40 CEST] <JEEB> I recall MPEG-TS not setting pkt_duration so I would guess not :P [16:04:17 CEST] <kepstin> nicoulaj: vaapi can to hevc, needs fairly recent mesa i think. On nvidia cards with the binary driver, nvenc can do hevc [16:04:38 CEST] <Numline1> Hey folks, I suck at ffmpeg. Can someone please help me with this command, so it extracts an image about every 5 seconds? ffmpeg -i AMBA0273.MOV -vf thumbnail=100 -frames:v 1 thumb%04d.jpg [16:04:50 CEST] Action: kepstin has done some test hevc encodes w/vaapi on his rx 560 and they worked fine, better than the h264 encoder in fact :/ [16:04:59 CEST] <cehoyos> Why did you choose 100? Why vframes 1? [16:05:32 CEST] <Numline1> cehoyos I wasn't sure how to combine that. 100 was supposed to be every x frames, vframes was in the original command and I wasn't sure what to do with it [16:05:58 CEST] <kepstin> Numline1: "-vframes 1" means "output a single frame then exit" [16:06:06 CEST] <Numline1> oh [16:06:17 CEST] <Numline1> well okay, I removed it :) Now it seems to create a thumbnail every 100 frames [16:06:37 CEST] <Numline1> I'm trying to find a way to extract a reasonable amount of images for each video [16:06:57 CEST] <Numline1> I'm not exactly sure how to scale it properly [16:10:53 CEST] <cehoyos> Only you know the input video, only you can decide what is "reasonable" [16:12:02 CEST] <Numline1> Yeah I was thinking - 10 "thumbnails" for first 10 seconds, then 1 thumbnail every 5 seconds [16:12:13 CEST] <Numline1> although I'm not sure if that's even possible in a single command [16:12:23 CEST] <Numline1> I assume I'd have to set -ss for the second part [16:12:43 CEST] <Numline1> cehoyos btw, just to verify - the thumbnail filter thingie - does it take 100 frames and looks for the best one? [16:14:10 CEST] <cehoyos> https://ffmpeg.org/ffmpeg-filters.html#thumbnail [16:14:16 CEST] <cehoyos> It picks one of 100 [16:17:15 CEST] <Numline1> okay, thanks [16:17:19 CEST] <Numline1> one more thing I'm wondering about [16:17:20 CEST] <Numline1> ffmpeg -ss 00:00:10 -i AMBA0273.MOV -t 1 -vf thumbnail thumb%04d.jpg [16:17:35 CEST] <Numline1> This creates 30 thumbnails, probably one for each frame. Why;s that? [16:21:30 CEST] <furq> you need to set the output framerate to match [16:22:45 CEST] <Numline1> oh, I removed the =100 [16:22:48 CEST] <Numline1> I'm a dumbass [16:22:48 CEST] <Numline1> thanks [16:23:47 CEST] <furq> it defaults to 100 anyway [16:24:05 CEST] <Numline1> oh. Then I'm not sure I follow [16:25:05 CEST] <furq> the thumbnail filter doesn't actually change the output framerate so it just outputs a bunch of duplicate frames [16:25:16 CEST] <furq> you want something like -vf thumbnail,fps=30/100 [16:25:38 CEST] <kepstin> I think "-vsync 0" would work here as well [16:26:01 CEST] <cehoyos> Yes, and it is recommended [16:26:07 CEST] <furq> oh yeah that's a less dumb way of doing it [16:27:49 CEST] <Numline1> I'll go with the less dumb way then :) Thanks folks [16:28:11 CEST] <Numline1> ffmpeg -ss 00:00:10 -i AMBA0273.MOV -t 10 -vf thumbnail=50 -vsync 0 thumb%04d.jpg is the final version, seems to be fine [17:05:59 CEST] <superware> can an AVPacket contain more than a single video frame? [17:14:32 CEST] <kepstin> superware: i think with most video codecs that'll hold, although there might be some cases where a parser of some sort has to be run before that's true [17:14:53 CEST] <kepstin> (and I'm not sure how things like vp9's alternate reference frame, which is decoded but not displayed, is handled) [17:15:28 CEST] <kepstin> in general, when decoding video, you cannot assume that if you pass one packet to the decoder, that it'll give you one frame back [18:01:57 CEST] <King_DuckZ> DHE: I fixed my program, I get different file sizes now depending on which profile I set [18:02:26 CEST] <King_DuckZ> but if I run ffprobe -show_streams myfile.mov the profile field shown there is always set to unknown, is that normal? [18:13:17 CEST] <Cracki> cheers. I can't be assed to deal with understanding and using the library, but I'd like to generate a video from specified bitmaps at specified times, and pipe that to ffmpeg for compression. I remember there was a binary format for just such purposes... anyone remember it? haven't found it yet in the docs [18:14:09 CEST] <Cracki> my source material is quite sparse, maybe a few hundred different pictures over an hour. ATM I'm piping in raw bitmaps at a fixed frame rate, which is very very wasteful. [18:14:33 CEST] <King_DuckZ> yeah I did something like that myself, it's called y4m [18:15:33 CEST] <King_DuckZ> Cracki: https://wiki.multimedia.cx/index.php?title=YUV4MPEG2 this was my source of wisdom, plus some gotchas that are not clear from there and I found out by reading the code from some other project on the internet [18:16:17 CEST] <Cracki> I would prefer a variable frame rate, i.e. just PTS [18:16:38 CEST] <Cracki> I already have a solution for fixed frame rate [18:19:03 CEST] <King_DuckZ> https://alarmpi.no-ip.org/kamokan/fo?cpp this is my code for the header, you'll have to work out the details for yourself [18:19:15 CEST] Action: King_DuckZ shrugs [18:19:29 CEST] <King_DuckZ> that's the y4m specs [18:20:33 CEST] <Cracki> uh no thanks, I think I'm not making myself clear [18:20:42 CEST] <Cracki> I do NOT want fixed frame rate [18:21:36 CEST] <King_DuckZ> yeah, and what I said is that's what the y4m specs look like, wheter it supports that or not my fault [18:22:13 CEST] <Cracki> I never mentioned y4m, I am just looking for a better solution than I have [18:22:21 CEST] <Cracki> if that isn't a solution, fine? [18:22:26 CEST] <King_DuckZ> maybe you want to dig if there's anything else than y4m then [18:22:35 CEST] <Cracki> we're in #ffmpeg, right? [18:22:48 CEST] <King_DuckZ> yes? [18:23:47 CEST] <Cracki> ah, there it is https://ffmpeg.org/nut.html [19:01:10 CEST] <yug_blop> Hi, is there a device like gdigrab for macos that allows you to specify a window title to record? [19:12:20 CEST] <coolhp48> Whould anyone know when I might find some documentation or an example of resampling using the AVSAMPLE API ? [19:13:03 CEST] <JEEB> doc/examples [19:13:27 CEST] <JEEB> that has swresample example, although I think it doesn't utilize the AVFrame-based API [19:14:33 CEST] <coolhp48> Hi Jeeb. You are correct. That's the example I was reading but it doesnt use AVFrame-based API calls. [19:16:13 CEST] <coolhp48> I think I might have found something in the group_lavr documentation (detailed description section). Its still sample based and not frame based but it seems simpler than the resample example from the doc folder. [19:26:31 CEST] <tablerice> trying to convert .R3D footage into anything else (prores MOV, h264 mp4) but I'm getting an error "Invalid data found when processing input". How can I find more info about the error? [19:30:08 CEST] <JEEB> tablerice: just `ffprobe -v verbose -i "FILE"` and pastebin that. then link here. might just be that the file is in a format that's not supported by FFmpeg (yet) [19:33:35 CEST] <tablerice> https://pastebin.com/kf4q1G4W [19:33:57 CEST] <JEEB> that's an older version of FFmpeg, but yea - exactly what I thought :) [19:34:12 CEST] <JEEB> FFmpeg couldn't figure out what that is [19:34:14 CEST] <tablerice> I saw something while researching, ffpmeg only supports a certain version of red footage? [19:34:23 CEST] <tablerice> version 3 i think? [19:34:25 CEST] <JEEB> it supports exactly what was reverse engineered ;) [19:34:35 CEST] <tablerice> Ha ha no worries [19:34:37 CEST] <JEEB> it's not like R3D publishes what they create [19:34:53 CEST] <tablerice> Nah, they're proprietary to the max [19:36:41 CEST] <JEEB> check if there's any similar ticket on trac.ffmpeg.org. if there isn't and you have some samples you can share, feel free to upload some short sample that you can share somewhere sane (like f.ex. 0x0.st with curl - curl -F'file=@FILE' https://0x0.st ) and make an issue [19:36:48 CEST] <JEEB> (or well, feature request to be exact) [19:37:11 CEST] <JEEB> https://wiki.videolan.org/Bounties [19:37:20 CEST] <JEEB> videolan bounty page doesn't seem to have one for modern R3D [19:37:48 CEST] <JEEB> it has contact info if you or your employer might be interested in sponsoring a bounty [19:39:28 CEST] <tablerice> Sounds good. Thanks for the help JEEB! [19:57:44 CEST] <tablerice> Okay so apparently the team at RED has some linux users because I just came across this little gem for anyone else trying to convert R3d footage on linux while keeping all the raw goodness: https://www.red.com/downloads/options?itemInternalId=16146&version=1 [21:30:22 CEST] <TheSashmo> has anyone at all ever seen a player that can support mpeg2 in browser other than vlc plugin? [22:16:05 CEST] <ChocolateArmpits> TheSashmo, windows media player embed supports it [22:16:17 CEST] <ChocolateArmpits> but of course only on internet exploder [22:18:23 CEST] <ChocolateArmpits> quicktime browser plugin should also support it [22:18:34 CEST] <TheSashmo> ChocolateArmpits: oh snap! never thought of that [22:32:17 CEST] <TheSashmo> ChocolateArmpits: but chrome and firefox are my go to browsers obv.... [22:32:35 CEST] <ChocolateArmpits> What's so bad about VLC then? [22:32:50 CEST] <ChocolateArmpits> Maybe there are some proprietary solutions for this, but I really can't name any more [22:40:10 CEST] <ChocolateArmpits> I can only guess what you're doing, but usually for large collections of videos that need to be previewed in the browser a compatible format version is transcoded [22:53:56 CEST] <alexozer> ffmpeg seems to output the entire video starting at "-ss" instead of ending at "-to": [22:53:58 CEST] <alexozer> ffmpeg -ss 929.363 -noaccurate_seek -i practice1.mp4 -to 939.681 -c copy -y part-1-practice1.mp4 [22:54:11 CEST] <alexozer> so in this case, the video should only be 10 seconds long but it's much longer than that [22:54:37 CEST] <c_14> either use -t and a duration or add -copyts [22:55:11 CEST] <kepstin> TheSashmo: you could always compile ffmpeg to wasm and run a decoder in the browser that way [22:56:54 CEST] <kepstin> alexozer: when you use -ss before the -i, ffmpeg cli runs some timestamp cleanup code that changes the timestamps to start at 0 [22:57:18 CEST] <kepstin> alexozer: so that command will grab 939.681s of video starting at 929.363 seconds in [22:57:51 CEST] <alexozer> kepstin: ah interesting. Would providing -i before -ss work in this case as well then? [22:58:16 CEST] <kepstin> alexozer: that would work, but it would be a *lot* slower, since -ss after -i has to decode the entire video up to the start point [22:59:09 CEST] <alexozer> kepstin: interesting thank you! [22:59:41 CEST] <kepstin> alexozer: there's some options to change the timestamp behaviour in ffmpeg, depending on what exactly you want to do [22:59:59 CEST] <kepstin> (note that you generally do want the encoded output to have timestamps starting at 0) [23:01:35 CEST] <kepstin> for example, the "-copyts" option disables the input timestamp processing, and the result will be 10 seconds of video - but the timestamps in the output will start at 939.681s [23:03:39 CEST] <alexozer> so to get the optimal seek performance as well as zero-based timestamps for the output videos, I could provide the duration to -to in my command, correct? [23:04:14 CEST] <kepstin> alexozer: the duration in the -to or -t option would work, yeah (with 0-based timestamps, both options have the same behaviour) [23:04:34 CEST] <kepstin> alexozer: note that you can also use -to as an input option (before -i), and you might want to see how that compares as well [23:07:53 CEST] <alexozer> kepstin: using -to before -i seems most reasonable I think [23:09:25 CEST] <jamie_1> so i am working on compiling ffmpeg from scratch and i have done it fine before, but i nuked my dir since i made a few whoopsies i was having a hard time fixing, so im working on a 100% fresh install folling the ffmpeg compile instructions and i keep running into https://pastebin.com/S0EM508X [23:10:39 CEST] <kepstin> jamie_1: please share your configure line, linux distro and arch, and more of the build log [23:10:49 CEST] <jamie_1> okay one sec [23:13:43 CEST] <irwiss> good time of day, i'm trying to figure out how to convert numeric pixel format into the short string identifier, looking at https://ffmpeg.org/doxygen/4.0/pixfmt_8h_source.html there seems to be an #ifdef block in the middle , do these numbers then float around as compiler defines are set or are they constants? [23:14:10 CEST] <kepstin> jamie_1: I'm guessing a bit, but it looks like you're trying to build the ffmpeg libraries (libavcodec.so, etc.) but have it set to statically link in the C library, which isn't gonna work [23:17:14 CEST] <kepstin> irwiss: the way to get the name from the number is to call https://ffmpeg.org/doxygen/4.0/pixdesc_8h.html#afe0c3e8aef5173de28bbdaea429… which returns the descriptor structure, and that has a name string in it. [23:18:36 CEST] <kepstin> irwiss: if the numbers change, the soversion of the ffmpeg libs will be changed as well, so you'd have to rebuild to link to the new lib [23:18:40 CEST] <irwiss> that seems to be what i'm looking for, google for some reason referred to https://ffmpeg.org/doxygen/4.0/group__lavc__misc__pixfmt.html which hasn't got that method listed, thanks! [23:18:54 CEST] <jamie_1> kepstin: how would have it not statically link the c libraies [23:19:10 CEST] <kepstin> jamie_1: please share your configure line, linux distro and arch, and more of the build log [23:19:17 CEST] <jamie_1> kepstin: im still working on it [23:19:32 CEST] <kepstin> jamie_1: you probably have something on the configure line which is incorrect [23:19:35 CEST] <jamie_1> i had to do a make clean and make to get the output again so i could link it [23:19:51 CEST] <jamie_1> https://pastebin.com/pS5v47jy is my config line [23:20:03 CEST] <jamie_1> im still working on getting a build log [23:20:35 CEST] <jamie_1> thats gonna be a few minutes though [23:21:29 CEST] <kepstin> jamie_1: hmm. that actually looks correct for the use of pkg-config; i'm guessing that some of the libraries you're trying to link into ffmpeg weren't built with -fPIC [23:22:10 CEST] <jamie_1> kepstin: if you give me just a sec, i should be able to find out [23:22:33 CEST] <jamie_1> its libaom but i honestly dont have a darn clue how to work with that one [23:22:41 CEST] <kepstin> to build a library like libx264 statically, but in such a way that it can be linked into a shared library, often requires special prep [23:23:26 CEST] <jamie_1> im trying to build one for obs that includes latest nvenc and nvida sdk [23:23:27 CEST] <kepstin> (do you actually need the libavcodec.so, etc. libraries? or only the ffmpeg cli tool?) [23:24:04 CEST] <jamie_1> im building for obs compile from scratch so it depends on libav for encoding in x264 [23:24:17 CEST] <jamie_1> at least from what i understand [23:24:20 CEST] <kepstin> tbh, it would be easiest if you just remove the --pkg-config-flags="--static" and link to the various libraries dynamically [23:24:27 CEST] <furq> jamie_1: if it helps you're not going to be needing libaom for obs [23:24:30 CEST] <jamie_1> obs doesnt allow you to [23:24:36 CEST] <furq> unless you want to capture your screen at 0.01fps [23:24:43 CEST] <jamie_1> yeah no.... [23:24:56 CEST] <jamie_1> that would be pretty funny though [23:25:00 CEST] <jamie_1> do that for a day [23:25:33 CEST] <kepstin> it would certainly be a low bitrate livestream ;) [23:25:57 CEST] <jamie_1> what would be the best way to dissable libaom? [23:26:05 CEST] <furq> remove --enable-libaom from configure [23:26:10 CEST] <jamie_1> im not sure exactly what it does to start with but it was listed as part of the standard ffmpeg [23:26:30 CEST] <jamie_1> was hoenstly one of the few parts i didnt at least know what they do [23:26:37 CEST] <furq> libaom encodes av1 [23:26:50 CEST] <kepstin> specifically, libaom encodes av1 very slowly [23:26:53 CEST] <jamie_1> yeah... not planning on doing that any time soon [23:27:15 CEST] <jamie_1> i have no use for av1 personnaly [23:27:24 CEST] <furq> not many people do yet [23:27:51 CEST] <jamie_1> would be cool to look into, still working on understand x264 and x265 better before that XD [23:28:04 CEST] <jamie_1> *working on understanding [23:28:38 CEST] <jamie_1> so im assuming the best course of action would be to remove libaom from my user libs? [23:32:58 CEST] <jamie_1> just removed libaom from my config and removed it from my bin [23:33:10 CEST] <jamie_1> didnt know if it would catch it in the autoconfigure so i wanted to make sure it didnt [23:33:39 CEST] <jamie_1> thanks for the help kepstin snf furq [23:33:46 CEST] <jamie_1> not sure where the snf came from [23:41:01 CEST] <jamie_1> screwed up fdk-aac too :/ had to change that to --enable-shared [00:00:00 CEST] --- Wed Apr 17 2019

1 0

ffmpeg-devel.log.20190415
by burek 16 Apr '19

16 Apr '19

[00:05:15 CEST] <jamrial> anyway, patch sent [09:26:49 CEST] <cone-690> ffmpeg 03Steven Liu 07master:f502bd5432c9: lavf/rtsp.c: Fix stimeout option not applied on http tunnel [11:02:28 CEST] <superware> how can I detect (from AVFormatContext/AVStream) that the opened media is a file OR a real-time stream? [11:03:45 CEST] <funman> try seeking? [11:05:41 CEST] <superware> can't RTSP seek? [11:06:43 CEST] <funman> I guess it might [11:06:58 CEST] <JEEB> there's no flag for "live stream" in lavf as far as I know [13:44:39 CEST] <cone-690> ffmpeg 03Steven Liu 07master:bbae8d08f592: Revert "lavf/rtsp.c: Fix stimeout option not applied on http tunnel" [13:44:40 CEST] <cone-690> ffmpeg 03Signed-off-by: Jun Li 07master:1ae8a1073ba8: lavf/rtsp.c: Fix stimeout option not applied on http tunnel [13:45:15 CEST] <nevcairiel> someone needs to stop sucking =p [13:47:12 CEST] <cone-690> ffmpeg 03Steven Liu 07master:7f78a1b1caea: Revert "lavf/rtsp.c: Fix stimeout option not applied on http tunnel" [13:47:13 CEST] <cone-690> ffmpeg 03Jun Li 07master:32148b5ac96b: lavf/rtsp.c: Fix stimeout option not applied on http tunnel [13:47:18 CEST] <durandal_1707> why this guy have commit access? [13:47:42 CEST] <JEEB> o_O [13:47:59 CEST] <JEEB> that's quite... unfortunate [14:04:33 CEST] <BtbN> What even is that? Revert and immediate re-apply of the same commit, from a different author? [14:05:09 CEST] <ubitux> Author: Signed-off-by: ... [14:05:11 CEST] <ubitux> lol [14:05:22 CEST] <ubitux> wonky [14:06:59 CEST] <BtbN> It changes not a single line of code? What? Why? [14:07:33 CEST] <ubitux> it's applying 3x the "same" commit, and revert it twice [14:07:40 CEST] <ubitux> i think the patch is applied [14:09:38 CEST] <BtbN> It's Revert + Apply same patch again, twice [15:38:34 CEST] <cone-690> ffmpeg 03Jun Zhao 07master:abfeba97241e: lavf/hls: Cleanup the applehttp [21:04:11 CEST] <faLUCE> Hello. I would like to send a patch containing a new API usage example, which I think is very useful for libavcodec users. Unfortunately, adding a new example requires one new file (new_example.c), and requires to modify configure, Makefile and Makefile.example. I can create a patch with all 4 files, but if one of them change meanwhile, I have to create a new patch. I was told that a patch often has to be pinged a [21:04:13 CEST] <faLUCE> lot before it is considered/accepted, so what can I do in order to create this patch in an easy way? [21:05:39 CEST] <JEEB> if you have the commits in a branch locally then you just rebase against master. if there are actual merge conflicts git will tell you [21:05:47 CEST] <JEEB> then you just commit and finish rebase [21:06:16 CEST] <JEEB> the examples directory though isn't as much touched so not sure how likely it is that it will hit a conflict? [21:06:39 CEST] <faLUCE> JEEB: but the patch touches configure [21:07:05 CEST] <JEEB> ok, then it's more likely [21:07:19 CEST] <JEEB> but if there's no merge conflict it will just get done automagically [21:07:33 CEST] <JEEB> at the worse part you just fix a (most likely minor) merge conflict [21:07:36 CEST] <faLUCE> with rebase? [21:07:39 CEST] <JEEB> yes [21:07:51 CEST] <JEEB> you have your own xxx_example branch locally [21:07:53 CEST] <faLUCE> I see, then I have to understand how rebase works [21:07:54 CEST] <JEEB> you update your local master [21:08:19 CEST] <JEEB> faLUCE: I didn't say that there is no merge conflicts if someone changed something right next to your place and git can't figure it out by itself [21:08:29 CEST] <JEEB> in that case it will ask you which parts to keep :P [21:08:39 CEST] <JEEB> still, should be relatively quick [21:08:48 CEST] <JEEB> commit and tell rebase to --continue, done [21:09:15 CEST] <faLUCE> ok, so, I pull in local master, then I rebase my_branch (with the new example) against LOCAL master [21:09:26 CEST] <JEEB> well local or remote [21:09:29 CEST] <JEEB> either is fine [21:09:36 CEST] <JEEB> usually you just have a copy of master around locally too :P [21:09:48 CEST] <faLUCE> yes [21:09:49 CEST] <JEEB> and at least I generally update local master when I fetch [21:10:16 CEST] <faLUCE> but why is it needed a local personal branch for rebasing? [21:10:24 CEST] <faLUCE> (because I rebase all the branch?) [21:10:42 CEST] <faLUCE> (instead of specifying the files?) [21:11:11 CEST] <JEEB> well I would rather keep master clean, no? [21:11:22 CEST] <JEEB> and you are handling a patch set and thus a branch makes sense IMHO [21:11:28 CEST] <faLUCE> of course [21:11:30 CEST] <JEEB> yup [21:11:46 CEST] <JEEB> that way you can work in git, and then export patches with git format-patch when needed [21:12:07 CEST] <faLUCE> but when addind to stage the modified files, do I have to git add file1 file2 etc. each time? [21:13:08 CEST] <JEEB> in which sense? if you have a merge conflict in a single file then that's all you add? [21:13:30 CEST] <faLUCE> sorry, the question was meaningless [21:13:42 CEST] <JEEB> also I think there's a shortcut to add all currently changed but unstaged files [21:14:03 CEST] <JEEB> but the more you use something like that the more likely you are to "oh, I didn't mean to add that one to *this* commit" [21:14:06 CEST] <JEEB> :) [21:14:35 CEST] <faLUCE> yes, I'll use git add ... [21:15:06 CEST] <TheAMM> git add -u [21:15:29 CEST] <JEEB> and that I will guess is the shortcut [21:15:36 CEST] <JEEB> "unstaged", I guess? [21:15:57 CEST] <TheAMM> probably, I think it as "update" [21:16:05 CEST] <TheAMM> Adds all changes from tracked files [21:16:20 CEST] <JEEB> yea, changed but unstaged [21:16:22 CEST] <JEEB> :) [21:16:33 CEST] <JEEB> if you open up gitk or so you'll see how it calls those things [21:16:36 CEST] <JEEB> (or git status, even) [21:17:13 CEST] <TheAMM> git add -u && git commit -m "wip" && git push prod [21:17:24 CEST] <TheAMM> lifehack [21:17:56 CEST] <TheAMM> (I have some history of abusing git as a file transport on personal projects) [23:21:22 CEST] <cone-842> ffmpeg 03Marton Balint 07master:e036b8dcf46d: avdevice/decklink_dec: set configs before listing formats [23:21:23 CEST] <cone-842> ffmpeg 03Marton Balint 07master:f3e22e320142: avdevice/decklink_common: properly check DoesSupportVideoMode result when trying VANC flag [23:21:24 CEST] <cone-842> ffmpeg 03Marton Balint 07master:63c2c83f6eb4: avdevice/decklink_common: add support for DeckLink SDK 11 [23:36:26 CEST] <faLUCE> JEEB and others: I don't get a point. The devel documentation says: "When you submit your patch, please use git format-patch OR git send-email. We cannot read other diffs :-). " But from what I read, git format-patch doesn't send any email" .... is it a typo error, and "OR" should be replaced with "AND" ? [23:37:24 CEST] <nevcairiel> git send-email will do everything in one step [23:37:39 CEST] <nevcairiel> but you can also manually attach the patch as an attachment, for that use git format-patch [23:38:27 CEST] <faLUCE> I see (then the webpage should be updated with a more clear description, IMHO) [23:38:36 CEST] <JEEB> well, format-patch makes something you can attach and send. send-email does format-patch + send e-mail. so technically it could say "and send the patches as attachment" to the format-patch part, but the person writing the text probably thought the sending part was obvious [23:38:55 CEST] <faLUCE> ok, got it [00:00:00 CEST] --- Tue Apr 16 2019

1 0

ffmpeg.log.20190415
by burek 16 Apr '19

16 Apr '19

[00:09:00 CEST] <DHE> ffmpeg's libs are static, but what other 3rd party libs (eg: x264) end up used remain in their original form and are pulled in as needed during compiling of real aps [00:15:26 CEST] <Atlenohen> Yeah I also had to modify the x264 header so that it doesn't use X264_API _dllImport thingy, and then rebuild ffmpeg [00:16:23 CEST] <Atlenohen> DHE: Cehoyos and others forgot this when they talked about BCrypt.lib with me, they kept telling me ffmpeg did not compile it [00:16:45 CEST] <Atlenohen> That apparently ffmpeg did not had a message about it it supposed to (about missing bcrypt.lib [00:27:00 CEST] <ncouloute> Concat Demuxer - 11.253-59.940 variable fps + frames shifting. [00:27:01 CEST] <ncouloute> Concat Protocol - 59.920-59.940 varible fps + no frame shifting [00:27:01 CEST] <ncouloute> . Concat Filter - 59.940 constant fps + frames shifting [00:27:01 CEST] <ncouloute> . My guess is since concat Protocol method first involves going from mp4 to ts then concat then remix back to mp4. [00:27:02 CEST] <ncouloute> Concat just doesnt work very well for h264 mp4s. [00:27:04 CEST] <ncouloute> Strangely enough h264_nvenc/h264_qsv encoded files dont have the frame shifting. [00:41:29 CEST] <cehoyos> That FFmpeg did not compile what? [01:49:35 CEST] <Atlenohen> cehoyos: Well, I got other people telling me bcrypt.lib wasn't suppose to be compiled with ffmpeg anyway as it's a standard practice that static libraries don't pack other libraries, unless specifically instructed. [01:50:48 CEST] <Atlenohen> I remember you thought that ffmpeg had to "compile" it and that there was a no error/warning about it being "missing". [01:55:19 CEST] <chinknot> I tried using a file with square brackets in its path with ffprobe but the terminal returns "No such file or directory". Is it possible this is a ffprobe related issue? I tried opening an issue on git-for-windows github but using the same path with other commands work without problems [01:57:44 CEST] <Ariyasu> encase the path in " [01:57:50 CEST] <Ariyasu> "path to input" [01:58:04 CEST] <chinknot> I tried that but same result [01:58:09 CEST] <Ariyasu> or caret the [] like ^[ and ^] [01:58:17 CEST] <chinknot> I'll try ^ [01:58:38 CEST] <chinknot> anyway sorry if I didn't mention it but I launched it via git-for-windows [01:59:45 CEST] <chinknot> ^ and \ didn't work [01:59:55 CEST] <chinknot> also replacing ' with " didn't help [02:20:40 CEST] <cehoyos> Atlenohen: You definitely don't "compile" bcrypt with FFmpeg, you need it to link the final executable, since you only build static libraries, you never need it. But FFmpeg's pkg-config file tells you that bcrypt is a dependency of libavutil. [02:21:30 CEST] <cehoyos> None of this is secret in any way and none of this is difficult in any way. You just manage to always mix your issue reports with some unrelated and wrong opinions (possibly of others) making helping you more difficult than necessary. [02:22:33 CEST] <Atlenohen> I didn't say it's secret, I obviously had no idea PKGCONFIG reports that ... if that's the standard place fine, but I'd have it in the terminal at the end of the build [02:24:51 CEST] <Atlenohen> You certainly didn't explain this back then, I was then looking what's making ffmpeg not get bcrypt, in the process I found other bugs and also figured out the whole thing I either would need to anyway so I lost no time and I'm actually glad now I went as deep as I did, I'm not blaming you, just asking if you have meant something else, or misunderstood the situation at the time. [02:26:31 CEST] <HickHoward> https://www.v-nova.com/tryPERSEUS/ [02:26:38 CEST] <HickHoward> perseus is going real live this time around [02:26:45 CEST] <Atlenohen> Because that day we concluded "it doesn't have an error for bcrypt, patch welcome", there were 3 other guys looking into bcrypt is needed, none of them mentioned it's not suppose to pack bcrypt.lib inside FFmpeg's libs. [02:33:17 CEST] <cehoyos> You reported a link error with your application yesterday and as I told you yesterday, it took me (who had never heard of this library) a minute to find out what you were missing. This simply isn't FFmpeg-related, the fact that the library doesn't show up in a list of external libraries that you most likely would have missed anyway is a bug but not one that ranks high on any list. [03:03:49 CEST] <Kaedenn> Are there Python bindings for libffmpeg or libavconv? [04:06:11 CEST] <Atlenohen> Cehoyos: sure that's right, I just wanted to clear out we both understand the same, I see now brcrypt.lib reported in the EXTRALIBS-avutil variable inside config.mak, not sure how do you guys feel about printing extralibs that at the end of thhe configuration process but it be kinda handy, for future new people dealing with it for example. [08:34:26 CEST] <pranayvshah> Is there a way to explicitly set the shaper when using the subtitles filter? I know there is for the ass filter. FFmpeg v4.1.3 sets ass->shaping to 0 with my subtitles filter command; if I use ass and set shaper to complex everything works [08:35:07 CEST] <pranayvshah> Even if there isn't a way, what can I do to have a value of 1 for ass->shaping [11:02:56 CEST] <superware> how can I detect (from AVFormatContext/AVStream) that the opened media is a file OR a real-time stream? [11:04:03 CEST] <while> I find vlc is having trouble playing a udp stream from ffmpeg, but it can be played with ffplay, is there a way to stream udp that vlc can read? [11:04:22 CEST] <while> (both audio and video) [11:05:20 CEST] <superware> while: output to "udp://ip:port?pkt_size=1316", and then try VLC [11:06:11 CEST] <JEEB> superware: I think lavf didn't have a flag for that [11:06:32 CEST] <JEEB> the previous mpv maintainer was pretty heavily herping a derp about that [11:07:02 CEST] <Mavrik> superware: that would be a property of AVIOContext more [11:07:04 CEST] <Mavrik> so something like [11:07:23 CEST] <JEEB> seeking was already mentioned but something rtsp might have support for seeking [11:07:26 CEST] <Mavrik> avformatcontext->pb->seekable == 0 [11:07:37 CEST] <JEEB> and yes, usually a protocol thing [11:07:45 CEST] <JEEB> although then you have the stuff on top of HTTP etc [11:12:50 CEST] <superware> while: output to "udp://ip:port?pkt_size=1316", I have a MediaInput raising PacketReady events, and a MediaPlayer receiving each packet, decoding the video stream and delaying (current_pkt_pts - last_pkt_pts), all that in a single thread. then I have a render thread being signaled for each delayed frame... [11:13:15 CEST] <superware> Problem is the video isn't smooth at all, so I guess the pts sync is wrong.. [11:13:41 CEST] <superware> (forget the "output to" :) [11:13:50 CEST] <while> I am trying your suggestion of output [11:14:04 CEST] <while> $ ffmpeg -re -i output.ogg -vcodec mpeg4 -f mpegts 'udp://127.0.0.1:10000?pkt_size=1316' [11:14:21 CEST] <while> is how I am currently issuing the command [11:14:41 CEST] <JEEB> you probably want to do multicast into localhost [11:14:50 CEST] <JEEB> that way multiple things can connect to it methinks [11:15:01 CEST] <superware> I was asking about detecting a real-time streams because I thought frames sync should be different for file vs. stream [11:15:30 CEST] <JEEB> yes, you may attempt low latency sync (aka ignoring some sync) with live streams [11:15:57 CEST] <JEEB> so that you show video f.ex. as fast as possible [11:16:03 CEST] <JEEB> as you receive the images from the decoder [11:17:33 CEST] <superware> from my experience you must do some syncing since incoming packets can be received at different times [11:18:37 CEST] <superware> only with syncing video will be smooth, otherwise they simply jitter, am I wrong? [11:20:00 CEST] <Mavrik> What's syncing in this case? [11:20:08 CEST] <Mavrik> You'll need to obey PTS for playback [11:20:28 CEST] <superware> that's what I mean [11:23:59 CEST] <while> so far adding the pkt_size option doesn't seem to have fixed it for VLC, but it still works in ffplay [11:23:59 CEST] <superware> what's the most simple syncing method? [11:24:30 CEST] <superware> while: I experienced VLC-udp issues, for me it worked [11:27:54 CEST] <while> I notice in Wireshark, is seems the udp packets are coming right before icmp port unreachable messages [11:28:24 CEST] <superware> while VLC is opening stream? [11:28:44 CEST] <while> here is vlc's log if it helps: https://wieldfield.com/downloads/20190415_ISO8601_vlclog.txt [11:28:56 CEST] <while> I have the VLC window open, and it still has the orange bouncing bar [11:29:29 CEST] <superware> try udp://@:10000 [11:29:56 CEST] <while> superware: yes it works! [11:33:01 CEST] <while> thank you [11:34:42 CEST] <superware> while: update your blog posts regarding ffmpeg/udp/vlc :) [11:35:12 CEST] <superware> it doesn't work without the "?pkt_size=1316", right? [11:35:21 CEST] <while> I haven't tried it without that yet [11:35:53 CEST] <while> I read that suggestion 2 other places, although trying with or without, both didn't work at the time [11:36:44 CEST] <while> to answer your question though, it is working without the "?pkt_size=1316" [11:37:21 CEST] <superware> Mavrik: after avcodec_receive_frame on the input thread, how should I calculate the delay in order to sync frames? [11:42:18 CEST] <superware> until now, what USED to work for me was no sycning on input thread (since I only played realtime streams) and syncing the frames from queue on a render thread. but now since I want to play files, I MUST sync on the input thread or else it will read frames at the speed of light [11:59:53 CEST] <superware> can someone please help me with how to sync frames (video-only)? [12:00:31 CEST] <superware> how much should I delay before rendering current frame? [12:02:05 CEST] <BtbN> Until the pts of the frame you want to present is reached [12:14:15 CEST] <superware> and when is that for the first frame? [12:18:52 CEST] <pk08> hello again [12:18:52 CEST] <pk08> i am developing an application which scales (scale filter) muliple input streams and overlay on single nullsrc filter using complex filter [12:18:52 CEST] <pk08> now i have problems in dts in output stream (outputing in h264(libx264) codec), Error: Application provided invalid, non monotonically increasing dts to muxer in stream [12:18:52 CEST] <pk08> and it only outputs I frames, no B or P frames. Log: [libx264 @ 0xea9b40] frame= 0 QP=11.24 NAL=3 Slice:I Poc:0 I:8160 P:0 SKIP:0 size=4038 byte [12:18:54 CEST] <pk08> can anyone please tell me how to fix these? [12:20:30 CEST] <pk08> output stream config: https://pastebin.com/e9QpvHhb [12:33:33 CEST] <pk08> rescaling packet: https://pastebin.com/QmR3MuCv [13:14:34 CEST] <superware> BtbN? [13:30:50 CEST] <pranayvshah> How/from where is this config_input function in vf_subtitles.c called please? https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_subtitles.c#L141 [13:35:36 CEST] <superware> How should I calculate delay between video frames in order to sync them for playback? [13:40:46 CEST] <superware> (with the master clock) [13:41:49 CEST] <BtbN> Like I said, based on the pts, presentation timestamps. [13:41:55 CEST] <BtbN> If you substract them, you get your delay. [13:46:21 CEST] <superware> but for real-time streams, frames can only be on-time OR late, so the delay isn't only based on pts subtraction, am I wrong? [13:47:11 CEST] <superware> when you open a file, you always get frames before their presentation time [13:55:13 CEST] <t3st3r> btw... does anyone knows if ffmpeg + VP9 supports "constrained quality" (CQ) mode in 2-pass mode and is it works with ffmpeg? Man/faqs/search results weren't conclusive. [13:55:56 CEST] <t3st3r> That is - what happens with ffmpeg + livbpx if I both specify -crf and non-zero bitrate? [13:56:10 CEST] <t3st3r> while doing 2 pass [13:56:55 CEST] <JEEB> that's up to libvpx [13:58:06 CEST] <JEEB> and the results differ between VP8 and VP9 most likely [13:58:13 CEST] <JEEB> since google changed the behavior of various options in libvpx [13:59:00 CEST] <pranayvshah> Hey JEEB, would you know how is this function called ? https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_subtitles.c#L141 [13:59:40 CEST] <t3st3r> This question about VP9 and how this particular combo + ffmpeg could/would perform. [14:00:31 CEST] <JEEB> t3st3r: ok, then you should first request info from folk who know libvpx better. you could guesstimate how it works from the libvpx vp9 wrapper but after all the final decision making is up to libvpx [14:00:34 CEST] <t3st3r> I've got idea I overall like CRF/CQ idea but I also like 2-pass. However I don't want "potentially unrestricted" bitrate. [14:01:24 CEST] <t3st3r> hmm any ideas of better channel to ask this question? [14:01:37 CEST] <t3st3r> do libvpx haves channel in freenode? [14:24:05 CEST] <Atlenohen> Hey guys, these are all the warnings I get in my FFmpeg build, there's no problem, just checking if anyone thinks anything's worth taking a look at https://pastebin.com/6v9d2FWN [14:28:43 CEST] <JEEB> t3st3r: I think at one point there was a #vp8 channel at least, also check the webm project's site [14:39:52 CEST] <t3st3r> JEEB> it really here, let's see if someone here got idea, thanks. [14:43:07 CEST] <kuznetsss> Hello, I am writing C++ application using FFmpeg libraries. [14:43:09 CEST] <kuznetsss> Here is part my code: https://pastebin.com/UEeEvZwq [14:43:11 CEST] <kuznetsss> I don't understand which function should initialize flags in AVOutputFormat which is inside AVFormatContext (format_context->oformat->flags)? [14:52:51 CEST] <t3st3r> interesting, google's developer pages actually recommend doing what I described and at 1st glance it does more or less what could be expected. [14:53:22 CEST] <Atlenohen> cehoyos: pkgconfig for ffmpeg isn't autogenerated so I couldn't have found out about bcrypt.lib that way, and in many places there doesn't appear to be windows compatible arguments, it uses /L almost everwhere instead of /LIBPATH: [14:57:48 CEST] <t3st3r> Also ... I've got rather odd problem. I did realtime vp9 encode and managed to box it into some strange (bugged?) bitrate allocation. [14:58:19 CEST] <t3st3r> At the end of day I've got some videos which look virtually perfect except some few frames that are AWFUL. [14:58:27 CEST] <JEEB> libvpx's rate control is known to be funky [14:58:29 CEST] <JEEB> have fun :) [14:58:32 CEST] <t3st3r> (likely very low quantizer) [14:59:03 CEST] <t3st3r> So the real quation is: are there way to programmatically detect such frames and chop 'em out under software control? [14:59:14 CEST] <t3st3r> and could ffmpeg do that? :D [15:00:04 CEST] <JEEB> nothing is impossible but do you really want to be working around libvpx's rate control in FFmpeg's wrapper or in your own API client :P [15:01:03 CEST] <t3st3r> No, I don't want to work it around :). Seems thx to google dev pages and #vp8 I got idea I know how to make it more or less behave. [15:01:48 CEST] <t3st3r> But I did few captures where I boxed rate-control decision pretty badly - and it elected to make perfect sequence at expence of few totally borkz0r3d frames :D [15:02:27 CEST] <t3st3r> I'm 100% fine with just throwing these away (as they cause very unpleasant "oscillation" but I'm not sure how to detect 'em software way. [15:02:38 CEST] <t3st3r> (and if ffmpeg can do it) [15:02:53 CEST] <JEEB> theoretically everything is possible with enough code, the question is whether it's worth the while [15:03:18 CEST] <JEEB> also if your results are due to boxing the rate control too much then maybe that should be tweaked instead :P [15:03:32 CEST] <JEEB> or if there's a global "don't use quantizer higher/lower than X" option in libvpx [15:03:35 CEST] <JEEB> :P [15:03:43 CEST] <t3st3r> Hmm good answer. I've hoped it could be done by just ffmpeg commands. Say some filter "if ...quantizer is bogusly high ... drop it" [15:04:17 CEST] <t3st3r> I've ofc tweaked it - but I have some captures I don't stand chance to recapture :D [15:04:47 CEST] <JEEB> also the problem is if some other picture used that as reference [15:04:52 CEST] <JEEB> that's now completely broken [15:04:55 CEST] <t3st3r> at which point I've both sorted out bitrate control but also 2nd part is fixing what I already had. [15:05:16 CEST] <JEEB> also I'm not sure if dropping random packets is OK in VP9; I don't remember if the coding engine's state is dependant on the pictures in the GOP [15:05:27 CEST] <JEEB> you should ask the libvpx/VP9 folk regarding that to begin with :P [15:05:36 CEST] <t3st3r> <JEEB> also the problem is if some other picture used that as reference <- not seems so. Somehow it did full-frames with very low Q [15:05:55 CEST] <JEEB> otherwise even if you take a bad picture out, you might just cause regressions until the end of GO [15:05:58 CEST] <JEEB> *GOP [15:06:16 CEST] <t3st3r> er I mean it used very high q, so frame is grossly overcompressed and looks like tetris. But all frames around are fine. [15:06:30 CEST] <t3st3r> (so bitrate control did really strange way of controlling bitrate) [15:07:19 CEST] <t3st3r> so most obvious idea would be just drop these few offending frames and re-encode rest using more sane parameters :) [15:08:32 CEST] <t3st3r> I've failed to find major damage on other frames - seems to be localized to certain frames - just them alone. I'd be damned, never seen such way to control bitrate in my whole life. [15:09:45 CEST] <t3st3r> technically idea to notice you've exceeded allowed bitrate and grossly overcompress few frames is valid, but result looks ... strange. [15:15:47 CEST] <t3st3r> I would surely use more sane bitrate control next time. Yet fixing few movies is an issue. Can ffmpeg filters see quantizers? -vf select is almost what I need. Except I can't readily formulate drop criterion. [19:58:14 CEST] <Atlenohen> Hi [19:58:30 CEST] <Atlenohen> Does x264 even support GOP = 1 ? [19:59:02 CEST] <Atlenohen> I get High Intra(a)L4.2 [19:59:29 CEST] <Atlenohen> But the quality quicly boggles down to sometihng like worse than old nokia phone quality [19:59:57 CEST] <Atlenohen> bitrate at 3000 kbps at around 1200x900 [20:01:18 CEST] <furq> just because it's intra-only doesn't mean it'll look good [20:01:33 CEST] <furq> you still need to set appropriate quality settings [20:03:54 CEST] <Atlenohen> Any other way to improve seeking then without having this quality destroying effect? [20:04:22 CEST] <furq> use a higher bitrate [20:05:02 CEST] <Atlenohen> Oh, okay, just checking if such a low GOP may be breaking some things, compat, stability ? [20:05:17 CEST] <Atlenohen> maybe i could use 2,4 later on but we'll see [20:05:30 CEST] <furq> i assume it has lower compatibility if it's using one of the intra profiles [20:05:37 CEST] <furq> it obviously has a very negative effect on compressibility [20:06:18 CEST] <furq> i assume you're doing this to feed into an NLE or something [20:08:44 CEST] <Atlenohen> No rush tho I can play with it and see what I like, oh and I just played them with MVP this time, didn't test with other players yet [20:13:48 CEST] <Atlenohen> It feels a bit better but the longer video plays the worse it gets [20:50:59 CEST] <kepstin> Atlenohen: most of the efficiency of codecs like h264 comes from its ability to use predicted frames (P,B frames). if you turn that off by setting -g 1 then either your video will be *much* lower quality at the same bitrate, or it'll be *much* larger [20:51:24 CEST] <kepstin> the gradual quality loss in 1-pass encode mode with bitrate set is just the bitrate controls taking a while to adapt to the situation. [20:51:47 CEST] <kepstin> (if you did a 2-pass encode, the video would be consistently low quality) [20:53:58 CEST] <kepstin> rather than setting gop size to 1, you'll normally want to compromise between seekability and file size. The default gop size for x264 is very large - lowering it down to ~1 second (e.g. -g 30 in a 30fps video) might be worth trying. [21:27:49 CEST] <Atlenohen> kepstin: thanks for the explanation, I'll have to figure out the basics yes, aren't intra frames full ones or I have mistaken them? [21:28:31 CEST] <kepstin> intra frames refers to frames that can be decoded on their own, without referring to data from other previously decoded frames. [21:28:37 CEST] <Atlenohen> kepstin: efficiency in compression, efficency in encoding, that's different then, if it's just compression, then it just be a size thing, not a quality one but I goess it's a bit more complicated [21:29:39 CEST] <kepstin> when referring to "efficiency" of a video codec, that almost always refers to "the bitrate required to achieve a certain quality level" [21:31:06 CEST] <kepstin> note that x264 has an encoding mode (using the "crf" parameter) where you can (approximately) set a quality level you want, and let the encoder choose the bitrate required to achieve that. [21:31:33 CEST] <kepstin> in many use cases, that's preferred over setting a bitrate [21:32:03 CEST] <Atlenohen> Oh, this is an older implementation that uses fixed bitrate, not crf, I do actually know a thing about video transcoding since I did a lot of archiving in the past but I have to refresh some memory [21:32:49 CEST] <Atlenohen> So I'm modifying the implementation, the ffmpeg api has probably changed since this was initially designed [21:34:46 CEST] <Atlenohen> Oh 0 is for intra only, interesting. [21:40:22 CEST] <cahoots> hi, do i need to pay royalties or anything if using ffmpeg's h.264 encoder? [21:42:13 CEST] <kepstin> cahoots: ffmpeg doesn't include an h264 encoder, it normally uses the implementation from the x264 library [21:42:38 CEST] <kepstin> cahoots: nobody here can give you a definitive answer on whether you need to pay patent royalties. [21:45:23 CEST] <JEEB> cahoots: for software licensing the open source licenses under which we have modules (LGPL and/or GPL) are rather simple. if you're talking about patent licensing then unfortunately you will not find an answer in here [21:48:43 CEST] <DHE> I would suggest googling "MPEG LA" and contacting your legal council [22:23:30 CEST] <cahoots> kk thanks [23:17:48 CEST] <phinxy> I can not get mp3 encoding recognized. There is a /usr/lib/libmp3lame.so and I've configured with --extra-cflags='-I/usr/include --enable-libmp3lame'. Could the reason ffmpeg does not find the lame encode have something to do with the error "WARNING: Libarary configuration mismatch"? avutil, avcodec, avformat does not have the extra --enable-libmp3lame flag (WHY NOT?). [23:20:24 CEST] <kepstin> phinxy: you should not need to set extra-cflags - you need to ensure your distribution's devel package for the lame library (which includes headers and pkg-config file) is installed [23:20:48 CEST] <kepstin> phinxy: what command are you running that gives this library configuration mismatch error? [23:22:07 CEST] <BtbN> --enable-libmp3lame inside of extra-cflags is also not going to do any good [23:22:46 CEST] <phinxy> BtbN: Right -- It's not in the cflags [23:22:58 CEST] <kepstin> phinxy: in your paste it was in the cflags [23:24:10 CEST] <kepstin> (if you copy-paste text, please copy-paste it rather than retyping where possible to avoid typos, since that can really affect the meaning of the command) [23:24:15 CEST] <phinxy> Let me get you the corrent ./configure flags I have used: https://termbin.com/q652e [23:25:17 CEST] <kepstin> right, that looks fine. what does the output of ./configure with those options look like? [23:25:42 CEST] <kepstin> although note that you shouldn't ever have to specify -I/usr/include [23:26:15 CEST] <kepstin> because the include paths are loaded from pkg-config and set automatically [23:27:15 CEST] <kepstin> if that doesn't work, it usually means that you need to install the -dev or -devel package from your distro (e.g. on ubuntu "apt-get install libmp3lame-dev" [23:28:15 CEST] <kepstin> also note that after re-running configure with changed options, it's sometimes a good idea to "make clean" and do a fresh build (even tho that'll be pretty slow on a little arm box like that...) [23:29:40 CEST] <kepstin> also, raspberry pis make terrible media processing platforms, when people come around with problems with them, the best advice is often "get a faster computer" :( [23:30:46 CEST] <phinxy> Perhaps the installation of libmp3lame was not correctly done. I might have put the headers in the wrong place or something [23:34:06 CEST] <phinxy> I recall having difficulty compiling libmp3lame so I fetched the .so and the single header file from a ftp server. [23:34:47 CEST] <kepstin> doesn't the distro you're running have it packaged? [23:35:39 CEST] <phinxy> I just checked ftp.slackware.org.uk/slackwarearm-14.2 , cant find it [23:36:07 CEST] <phinxy> hmm my package manager have it. [23:36:14 CEST] <phinxy> why have I not installed it from there? [23:37:25 CEST] <phinxy> I might have wanted to compile it "for fun" with my own configuration options. I'll try get it from the package manager without overwriting the previous, customized version. [23:39:10 CEST] <c_14> phinxy: what's the actual error you're getting [23:43:21 CEST] <phinxy> c_14: https://termbin.com/hrlc https://termbin.com/rtwi [23:44:34 CEST] <c_14> looks like you built a shared ffmpeg binary and it's linking against your system builds at runtime [23:44:57 CEST] <c_14> either rebuild static (--disable-shared) or use LD_RUNTIME_PATH to set the correct lib path [23:50:37 CEST] <phinxy> output of ./configure says "static yes" and libmp3lame is listed under External libraries. https://termbin.com/rjvg [23:51:49 CEST] <c_14> I'm not entirely sure what the preference is when both are enabled, you can always check by running `ldd' on the ffmpeg binary and checking if it links the libav* libraries [23:51:56 CEST] <c_14> s/links/lists/ [00:00:00 CEST] --- Tue Apr 16 2019

1 0