Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

May 2018

1 participants
62 discussions

ffmpeg-devel.log.20180510
by burek 11 May '18

11 May '18

[00:20:08 CEST] <durandal_1707> atomnuker: i need 1, 2, 3, 4, 5, .., 256 dct [00:30:08 CEST] <atomnuker> eh, there's already a 5-point fft, I suppose I could use that to make a dct [00:30:50 CEST] <atomnuker> the rest (3, and those above 5) will be very complicated [00:47:47 CEST] <cone-942> ffmpeg 03Timo Rothenpieler 07master:2e700b082c81: Revert "avcodec/nvenc: make hw_frames_ctx fully optional" [00:47:48 CEST] <cone-942> ffmpeg 03Timo Rothenpieler 07master:baabd3c2adb0: avcodec/nvdec: avoid needless copy of output frame [00:47:49 CEST] <cone-942> ffmpeg 03Timo Rothenpieler 07master:c85568342741: avutil/hwcontext_cuda: add CUstream in cuda hwctx [00:47:50 CEST] <cone-942> ffmpeg 03Timo Rothenpieler 07master:880236e898fd: avcodec/nvdec: pass CUstream in vpp parameters [00:47:51 CEST] <cone-942> ffmpeg 03Timo Rothenpieler 07master:9b82e333b7c4: avutil/hwcontext_cuda: explicitly synchronize cuMemcpy calls [00:47:52 CEST] <cone-942> ffmpeg 03Timo Rothenpieler 07master:93d1756af290: avcodec/cuviddec: explicitly synchronize cuMemcpy calls [00:47:53 CEST] <cone-942> ffmpeg 03Timo Rothenpieler 07master:41a18982d092: avutil/hwcontext_cuda: add support for nvenc rgb formats [00:47:54 CEST] <cone-942> ffmpeg 03Timo Rothenpieler 07master:ece068a771ac: avutil/hwcontext_cuda: use generic size and pointer assignment functions [00:47:55 CEST] <cone-942> ffmpeg 03Timo Rothenpieler 07master:1c15d266150c: avfilter/vf_hwupload_cuda: update supported pix_fmts [01:14:54 CEST] <klaxa> grml, apart from heisenbugs i think i'm ready to send the httpd-independent ffserver to the ML, will look through it tomorrow after having slept and clean it up a bit [01:20:54 CEST] <tmm1> JEEB: woohoo http://0x0.st/sjjR.txt [01:22:40 CEST] <JEEB> interesting [01:31:52 CEST] <JEEB> that said completely new PIDs appear as well so a client needs to be dynamic. so in that sense I'm not sure if I have thought enough about abstracting this. esp. since A/V/S formats can switch between PMT updates with switching PIDs [01:32:29 CEST] <JEEB> I'll try to review your PMT thing tomorrow^Wtoday after I get some sleep [01:34:47 CEST] Action: JEEB hits the sack [02:52:15 CEST] <cone-942> ffmpeg 03Thomas Mundt 07master:a3a6d4da6253: avformat/mxfenc: add h264 profiles [03:28:16 CEST] <philipl> BtbN: found the hevc problem. bug in scaling list handling. [11:36:31 CEST] <durandal_1707> atomnuker: have you answered my question about 2-256 dct? maybe I missed it? [11:40:53 CEST] <BtbN> philipl, it's always scaling lists. It was when I implemented HEVC for vaapi. Those things are a mess [11:53:25 CEST] <nevcairiel> took multiple tries for dxva as well, mostly because the way we store them disagrees with how hardware wants them, apparently [12:03:51 CEST] <BtbN> it's also not a commonly used feature it seems [12:03:58 CEST] <BtbN> so them being broken can go unnoticed for quite a while [12:05:56 CEST] <BtbN> hm, I wonder if I should/can backport the cuvid frame mapping to 4.0 [12:06:13 CEST] <BtbN> it does not change any behaviour to the outside [12:06:23 CEST] <BtbN> *nvdec [12:06:32 CEST] <BtbN> And it makes it go fast [12:06:47 CEST] <nevcairiel> its still a "feature" with potential new bugs [12:07:56 CEST] <BtbN> I'm actually amazed how nothing broke with doing that [12:08:08 CEST] <BtbN> I expected it to break at least something, but it really didn'T [12:25:57 CEST] <atomnuker> durandal_1707: I think I did, but anyway, even-numbered DCTs will be done as usual, of the odd-numbered ones a 5-point (there's already an fft), a 15-point (already an fft), and maybe a 3-point if I can find a kernel [12:34:03 CEST] <durandal_1707> atomnuker: i need at least: every number between 2 and 16 [13:00:09 CEST] <atomnuker> ok, I'll leave a naive dft for anything prime-numbered (which it will be optimal for) or unoptimized [13:04:00 CEST] <cone-593> ffmpeg 03Jun Zhao 07master:1655e1096e53: lavf/network: fix doxygen comments. [13:38:34 CEST] <cone-593> ffmpeg 03Jun Zhao 07master:b30575bc982f: checkasm/sw_rgb: fix the function declaration warning [13:38:35 CEST] <cone-593> ffmpeg 03Jun Zhao 07master:74a7ddd985c4: lavfi/tests/filtfmts: fix the build warning. [13:38:40 CEST] <durandal_1707> why i get heavy block artifacts when I do inverse dct of filtered coefficients? [13:38:51 CEST] <durandal_1707> should I remove mean or something? [13:45:16 CEST] <durandal_1707> i'm just doing hard thresholding - changing some too low coefficients to 0 [14:09:34 CEST] <durandal_1707> found it! [14:15:13 CEST] <durandal_1707> if there is no comments i will apply fftdnoiz [14:33:54 CEST] <durandal_1707> all denoisers that operates on blocks sucks, they need big overlap to be useful [14:46:39 CEST] <cone-593> ffmpeg 03Paul B Mahol 07master:974eb4aaaa7d: avfilter: add fftdnoiz filter [14:54:01 CEST] <atomnuker> durandal_1707: its just an inherent property of ordniary DCTs, you can't fix it [15:44:03 CEST] <kierank> durandal_1707: hmmm gagandeep don't spent much time on irc [16:02:44 CEST] <durandal_1707> kierank: he appeared for short time [16:02:58 CEST] <kierank> he needs irc bouncer [16:27:09 CEST] <durandal_1707> i wrote basic denoising for bm3d - its pretty good [16:41:44 CEST] <BtbN> When backporting to 4.0, do I also backport the fix for the const warning? Even though it's not technically required, it fixes a warning and can't possibly cause any harm [16:47:33 CEST] <philipl> BtbN: I would. [16:48:36 CEST] <JEEB> right, that libbluray thing I should back-port as well [16:49:25 CEST] <BtbN> Not sure if I should wait for longer with the const fix, or just push it. Can't think of anything it could possibly break or any unintended side-effects. [16:56:26 CEST] <philipl> It's a compiler thing - either it leads to warnings/errors or it doesn't. :-) [16:56:57 CEST] <philipl> And I want to push mine so I don't have to think about it anymore [17:00:09 CEST] <JEEB> oh yes, cherry-pick -x is useful [17:00:20 CEST] <JEEB> thank you to the kind people here for making me find it <3 [17:00:58 CEST] <cone-593> ffmpeg 03Jan Ekström 07release/4.0:8fde71acd9d1: lavf/bluray: translate a read of 0 to EOF [17:01:08 CEST] <JEEB> I think I did it right [17:44:53 CEST] <durandal_1707> ubitux: have you debuged why it can get bad edges in nlmeans filter? [17:45:36 CEST] <ubitux> no, i haven't reproduced anything like that [17:47:45 CEST] <durandal_1707> ubitux: with sample i sent you, i can only get blurry results, and not detailed like their filter [17:48:11 CEST] <durandal_1707> if not blurry, then it have messed edges [17:52:15 CEST] <ubitux> i don't know, i need time to work on this, i try to look at subtitles currently [17:59:09 CEST] <gagandeep> kierank: i have obtained a progressive ip frame structured file [17:59:22 CEST] <gagandeep> the one in ffmpeg samples is really messed up [17:59:44 CEST] <gagandeep> also adobe after effects has only implemented i-frame structure currently [18:00:07 CEST] <kierank> I thought you said ffmpeg file played in after effects [18:00:14 CEST] <gagandeep> they don't support intra and inter(p-frame) encoding [18:00:14 CEST] <kierank> gagandeep: btw you need to be on irc all the time [18:00:21 CEST] <kierank> gsoc is a full time job [18:00:50 CEST] <gagandeep> ok i will use my cell for irc during commute [18:01:48 CEST] <gagandeep> and i confirmed with david newmann that group is the naming scheme for p frames [18:01:53 CEST] <JEEB> I recommend grabbing one of those student benefit packages from github or whatever [18:01:56 CEST] <kierank> gagandeep: so the ffmpeg file is not legal? [18:02:10 CEST] <gagandeep> not legal? meaning [18:02:12 CEST] <JEEB> which gives you a year's worth of free stuff like virtual servers [18:02:39 CEST] <JEEB> so you can just have a client there and connect to it so you have a 24/7 client from which you can look at the backlog [18:02:47 CEST] <JEEB> if you want something simpler there's also irccloud [18:02:56 CEST] <JEEB> but that costs money for a constant connection [18:03:17 CEST] <gagandeep> kierank:i mean the file on ffmpeg was not getting parsed correctly through TestCFHD [18:03:27 CEST] <gagandeep> JEEB: i will look into it [18:03:38 CEST] <kierank> gagandeep: yes and I think you should fix testcfhd to decode the file [18:03:41 CEST] <kierank> it's a file in the wild [18:03:48 CEST] <kierank> or fix it at ffmpeg level i guess [18:03:54 CEST] <kierank> now that you have another p-frame sample [18:04:39 CEST] <gagandeep> yeah [18:05:14 CEST] <gagandeep> i mean ffmpeg and adobe was able to handle but TestCFHD being a bit simple decoder couldn't [18:06:03 CEST] <kierank> I think you should figure out and patch TestCFHD to fix the problem [18:06:12 CEST] <kierank> otherwise we can never bitexact verify the file [18:08:22 CEST] <gagandeep> kierank: yeah and it might require looking into ffmpeg source as to how packets are handled [18:08:51 CEST] <gagandeep> well i can't look into after effects [18:09:22 CEST] <kierank> does anything actually decode the file correctly? [18:10:04 CEST] <gagandeep> ffmpeg gives the error that a certain transform type 2 is not implemented [18:10:15 CEST] <kierank> gagandeep: please answer the question [18:10:51 CEST] <gagandeep> after effects was playing the file but the data is corrupt after half the file [18:10:56 CEST] <kierank> ok [18:11:11 CEST] <kierank> there is also mplayer binary loader I guess [18:11:20 CEST] <gagandeep> what is that [18:11:39 CEST] <kierank> gagandeep: MT_BeartoothHighway_1min_Cineform.avi [18:11:40 CEST] <kierank> this file? [18:11:52 CEST] <gagandeep> yeah i am talking about this file [18:12:10 CEST] <kierank> what about timelapse-pt-momsapt.avi [18:13:32 CEST] <gagandeep> timelapse also has issues in after effects (corrupt data or something else) and the output in ffplay with this file i don't know if it is correct [18:14:37 CEST] <gagandeep> timelapse file does not even output anything in testcfhd [18:14:46 CEST] <gagandeep> maybe also problems in container [18:15:19 CEST] <kierank> I would guess these files work in mplayer binary loader [18:15:22 CEST] <kierank> maybe worth setting that up [18:15:35 CEST] <kierank> ask Compn [18:15:42 CEST] <JEEB> nostalgy line [18:16:46 CEST] <JEEB> was the OSS implementation from gopro in any way or form integrate'able? it might be useful to be able to compare the internal thing and that through FFmpeg? [18:16:57 CEST] <JEEB> or am I thinking of the wrong format? [18:17:14 CEST] <kierank> could be integrated yes, fair point [18:17:23 CEST] <kierank> gagandeep: that's another approach JEEB suggests [18:17:31 CEST] <kierank> might be easier than mplayer binary loader [18:18:25 CEST] <gagandeep> i mean they have provided sdk so yes [18:20:10 CEST] <kierank> gagandeep: yes, I think you should fork ffmpeg and integrate their sdk, would need to remove internal decoder or disable it somehow for that [18:21:03 CEST] <JEEB> just disabling the internal one might be enough [18:22:11 CEST] <gagandeep> let me get this straight, this is only for testing purposes [18:22:43 CEST] <gagandeep> still the internal decoder needs to be written afterwards [18:23:34 CEST] <JEEB> yes [18:26:01 CEST] <gagandeep> i probably will need to hook the sdk after demuxers seperate packets or something like that [18:26:09 CEST] <durandal_1707> JEEB: why disabling internal one? do not advise bad stuff [18:26:32 CEST] <JEEB> did you miss the context? [18:27:01 CEST] <durandal_1707> nope [18:27:03 CEST] <JEEB> let me read it out for you then: he was recommended that he'd make a wrapper decoder for the official OSS decoder [18:27:22 CEST] <durandal_1707> it can have both just fine [18:27:31 CEST] <kierank> durandal_1707: sure but not for upstream [18:27:36 CEST] <JEEB> ok, can you make ffmpeg.c prefer one or the other? [18:27:37 CEST] <kierank> official decoder has simd-only codepaths [18:27:45 CEST] <kierank> JEEB: i guess so because prores did it [18:27:55 CEST] <JEEB> ok, then yes - that is the best alternative [18:28:02 CEST] <JEEB> I just didn't remember about things in containers [18:28:12 CEST] <JEEB> since I've had issues trying to override video or audio formats read from containers [18:28:19 CEST] <JEEB> but I guess decoders are a different thing [18:28:31 CEST] <gagandeep> yeah that simd threading [18:28:38 CEST] <durandal_1707> kierank: sure, otherwise gagandeep would not be here [18:29:00 CEST] <JEEB> but in any case, I don't see disabling the internal one for development purposes in a configure line as evil [18:29:08 CEST] <durandal_1707> JEEB: there is options to select decoder in ffmpeg [18:29:10 CEST] <JEEB> and I don't see that as necessarily *bad* *Advice* [18:29:31 CEST] <durandal_1707> he can not compare their output easily [18:29:31 CEST] <JEEB> yes, I goddamn know c:v perkele [18:29:37 CEST] <JEEB> agreed [18:29:45 CEST] <JEEB> I do fucking agree with you for fuck's sake [18:29:53 CEST] <JEEB> stop arguing [18:29:54 CEST] <JEEB> thank you [18:30:21 CEST] <gagandeep> chill out guys, i am looking into it [18:30:35 CEST] <JEEB> at the point of writing I was not 100% sure and the two alternatives kierank mentioned was removal from code base and disabling in configure [18:30:45 CEST] <JEEB> so I pointed at the less hard of those [18:30:48 CEST] <JEEB> jesus [18:30:54 CEST] Action: durandal_1707 thinks mpv devs are nothing compared to mplayer ones [18:31:04 CEST] <JEEB> lol [18:31:54 CEST] <JEEB> I don't know what's your issue today, but you're getting pretty childish there [18:32:09 CEST] <gagandeep> kierank: by the way how do you have all this knowledge regarding p-frames [18:33:21 CEST] <gagandeep> i have no idea how reverse engineering works but did you get hands on some internal team doc, just asking [18:33:42 CEST] <kierank> gagandeep: I saw file and saw that it had smaller frames [18:33:46 CEST] <kierank> so assumed it must be p-frame [18:33:54 CEST] <kierank> and I met david newman once and he said i was kinda right [18:34:05 CEST] <durandal_1707> gagandeep: seriously it is not that hard, except if you look at VC-1 [18:34:32 CEST] <gagandeep> i mean i also had to confirm with david newmann about the ip structure [18:35:02 CEST] Action: wm4 thinks durandal_1707 is a dumbass [18:35:41 CEST] <wm4> annoyed me for weeks with some shitty bug reports that couldn't be reproduced [18:35:53 CEST] <wm4> and broke stuff in libavformat trying to incompetently fix it [18:36:20 CEST] <durandal_1707> i broke nothing, the seeking code is correct [18:36:23 CEST] <wm4> and completely fucking unable to describe his problems accurately [18:37:18 CEST] <gagandeep> kierank: ok will look into the virtual server cause frankly at campus while moving around the connection breaks and keeps reconnecting because of proxy [18:38:16 CEST] <JEEB> gagandeep: https://education.github.com/pack [18:38:19 CEST] <kierank> gagandeep: how long at university do you have left? [18:38:32 CEST] <JEEB> I think this provides some credit for some VPS providers [18:39:04 CEST] <gagandeep> i will be staying at university with summer stay [18:39:24 CEST] <gagandeep> i mean the environment is more work friendly [18:39:27 CEST] <JEEB> although depending on your capability of setting up something like a bouncer or irssi (and if you have the cash for it), irccloud might be a less technical alternative [18:40:11 CEST] <kierank> gagandeep: ok [18:40:24 CEST] <kierank> gagandeep: what are your working hours [18:41:30 CEST] <gagandeep> currently from 2pm to 11pm [18:42:04 CEST] <gagandeep> i take a bit of break in between for lunch or refreshments [18:42:55 CEST] <cone-593> ffmpeg 03Timo Rothenpieler 07master:46c1ee19171c: avcodec/hevcdec: make ff_hevc_frame_nb_refs take a const pointer [18:42:56 CEST] <cone-593> ffmpeg 03Philip Langdale 07master:126100370032: avcodec/nvdec_hevc: fix scaling lists [18:43:11 CEST] <kierank> gagandeep: ok [18:45:41 CEST] <gagandeep> from your uk standards that would be 8:30 - 17:30 [18:50:41 CEST] <kierank> ok good, quite convenient for me [18:56:49 CEST] <cone-593> ffmpeg 03Timo Rothenpieler 07release/4.0:61b673b1f101: avcodec/hevcdec: make ff_hevc_frame_nb_refs take a const pointer [18:56:50 CEST] <cone-593> ffmpeg 03Philip Langdale 07release/4.0:2a44f706aa14: avcodec/nvdec_hevc: fix scaling lists [20:07:13 CEST] <aakravchenko188> Hi [20:20:12 CEST] <akravchenko188> Hello guys, I would like to support AMF encoder + implement few new AMF components in FFmpeg. [20:21:13 CEST] <akravchenko188> I sent patch 2 weeks ago, but didn't receive any comments [20:22:45 CEST] <akravchenko188> could you help me what to do? [20:24:15 CEST] <akravchenko188> I could propose myself as maintainer of amf at the beginning and other HW support later [20:36:23 CEST] <akravchenko188> is this ok? [20:38:24 CEST] <BtbN> ping it [20:48:58 CEST] <atomnuker> akravchenko188: too soon, you're not going to push anything without review! [20:49:18 CEST] <atomnuker> ping the patchset again until someone's bothered enough to review it [20:50:29 CEST] <atomnuker> last time someone nominated themselves as a maintainer for something few cared about we got dash and hls issues [20:51:56 CEST] <JEEB> but coming to the IRC is a good idea; generally you can catch different people here :P [20:52:43 CEST] <JEEB> unfortunately I have nfi about AMF so I cannot be of help [20:53:29 CEST] <JEEB> tmm1: I'm finally getting to looking at your PMT fixup :| so many darn distractions [21:03:57 CEST] <cone-593> ffmpeg 03Haihao Xiang 07master:7e78801fa580: vaapi_encode: Add an assert in vaapi_encode_truncate_gop() [21:03:58 CEST] <cone-593> ffmpeg 03Haihao Xiang 07master:bed670a1de29: hwcontext_vaapi: Add an assert in vaapi_map_from_drm() [21:05:54 CEST] <jkqxz> akravchenko188: I need to reconstitute a Windows+AMD machine to try it, I'm intending to do that this weekend. [21:06:43 CEST] <jkqxz> If you have any following patch using it then I suggest sending it. It's easier to review things when the use is there as well. [21:16:16 CEST] <jkqxz> Is the Sony_4K_Camp HDR demo video meant to contain random shit in the HDR metadata fields? [21:16:22 CEST] <JEEB> yes [21:16:30 CEST] <JEEB> it has like 0.05 nits or something set for max brightness [21:16:39 CEST] <JEEB> that's the reason why mpv got some sanity checks on those fields [21:16:43 CEST] <JEEB> you'd think sony got that stuff right [21:16:53 CEST] <JEEB> they probably meant 5000 nits but got the range wrong or something [21:17:02 CEST] <JEEB> since the value is literally five if I recall correctly [21:18:03 CEST] <jkqxz> <https://0x0.st/sj45.txt>. I like those display primaries, too. [21:19:03 CEST] <JEEB> lol [21:19:35 CEST] <jkqxz> (The unit is *10^-4 nits, yeah.) [21:20:08 CEST] <JEEB> yup [21:33:06 CEST] <jkqxz> Apparently LG and Samsung are better at this. (Or at least, the values look vaguely sensible.) [21:34:02 CEST] <JEEB> yea [21:50:52 CEST] <durandal_1707> atomnuker: when to expect that dct patch? [21:52:24 CEST] <JEEB> tmm1: can you remind me which point of the H.222 spec that stuff you poked was in? [21:53:49 CEST] <akravchenko188> thanks for your answers [21:56:18 CEST] <cone-593> ffmpeg 03Haihao Xiang 07master:56ed01169269: cbs_h265: read/write HEVC PREFIX SEI [21:56:19 CEST] <cone-593> ffmpeg 03Haihao Xiang 07master:345b6962b68b: vaapi_encode_h265: Insert mastering display colour volume [21:56:20 CEST] <cone-593> ffmpeg 03Haihao Xiang 07master:2943dd35b759: cbs_h265: read/write content light level information SEI message [21:56:21 CEST] <cone-593> ffmpeg 03Haihao Xiang 07master:0612e29b59d4: vaapi_encode_h265: Insert content light level information [21:58:59 CEST] <tmm1> JEEB: i didnt check the spec, not sure if its in there or this is something only my cable provider does [21:59:47 CEST] <JEEB> if something like dvb inspector implements it, it's in the spec [21:59:59 CEST] <JEEB> of course the usage of the spec is up to the broadcasters [22:01:25 CEST] <JEEB> but yea, will need to figure what structure it is that your [22:01:28 CEST] <JEEB> *you're parsing [22:02:40 CEST] <tmm1> sure, it should be wherever it describes the contents of PMT [22:02:51 CEST] <akravchenko188> I just proposed myself as maintainer of amf, because nobody listed in maintainers for amfenc and I know architecture of AMF quite well. probably I need more experience in FFmpeg development but it is matter of time. may be later [22:03:21 CEST] <JEEB> oh, so that was PMT itself... let's see [22:03:49 CEST] <JEEB> I'm really thankful for ITU-T that they mistakenly opened access to H.222 back in 2012 :P [22:03:58 CEST] <JEEB> was really nice for the young student me [22:06:41 CEST] <kierank> yes, same [22:07:58 CEST] <JEEB> kierank: btw in your cases would you drop or buffer all packets that come for a program before you got PCR? [22:08:08 CEST] <atomnuker> durandal_1707: this weekend [22:08:12 CEST] <kierank> JEEB: pcr? [22:08:18 CEST] <JEEB> Program Clock Reference [22:08:21 CEST] <JEEB> which you probably knew [22:08:37 CEST] <kierank> yeah, i mean the question is strange [22:09:04 CEST] <kierank> i would just parse packets as normal, wouldn't need pcr for anything [22:09:05 CEST] <JEEB> basically I'm thinking of the best way of fixing an issue that happens when weirdly timestamped packets get ingested before PCR is around to help the demuxer unmangle the timestamps [22:09:39 CEST] <JEEB> because I've seen some people mux unrelated subtitle streams with their original PTS [22:09:46 CEST] <kierank> some teletext has no pt [22:09:47 CEST] <kierank> pts [22:10:03 CEST] <JEEB> yea, I've checked that the PTS is there, but it's 8.5h before video PTS :D [22:10:13 CEST] <JEEB> after you receive PCR there's some logic to fix that [22:10:40 CEST] <JEEB> but the framework goes berserk if you ingest multiple streams' packets before you get PCR [22:11:11 CEST] <JEEB> "oh we just got 8xxxxx, and now we got 5xxxxx - there must have been a wrap-around!" and then you suddenly you have timestamps way in the future [22:11:35 CEST] <JEEB> so I need to either decide on dropping packets before PCR, or buffering them so that they can be re-adjusted if needed after PCR is received [22:11:46 CEST] <tmm1> what if read_header doesnt return until it sees pcr? [22:12:04 CEST] <tmm1> so pcr is always set after probe finishes [22:12:54 CEST] <JEEB> that sounds like one way of doing it [22:12:59 CEST] <kierank> JEEB: in my use case i wouldn't be able to handle that kind of stuff [22:13:14 CEST] <JEEB> ok [22:13:36 CEST] <JEEB> I did tell the people muxing this stuff to not do it, but it seems like they just really like to have teletext in a mux [22:15:01 CEST] <kierank> teletext I can handle [22:15:06 CEST] <kierank> well upipe and vlc can [22:15:11 CEST] <kierank> they do pcr+offset [22:15:24 CEST] <JEEB> yea [22:15:29 CEST] <JEEB> I mean, the demuxer does handle that [22:15:42 CEST] <JEEB> but I get stuff like video packet - teletext packet - PCR - teletext packet [22:15:57 CEST] <JEEB> and the framework gets really confused at the second packet [22:15:57 CEST] <JEEB> :D [22:16:18 CEST] <JEEB> the second teletext packet gets fixed with the PCR [22:16:40 CEST] <JEEB> which is why I thought I'd either discard packets until PCR, or buffer them [22:16:45 CEST] <akravchenko188> guys, one more question, could you recomment mobile irc chat software. for ios? [22:17:04 CEST] <JEEB> akravchenko188: if you don't like mobile ssh clients, irccloud seems to be alright? [22:17:12 CEST] <JEEB> they basically keep a session open for you for 2 hours for free [22:17:21 CEST] <JEEB> (as in, when you are not connected) [22:17:38 CEST] <JEEB> and if you pay some they just give you eternal connections [22:18:24 CEST] <JEEB> and of course tmm1's way of making sure PCR is set at probe is also a good idea I guess [22:18:44 CEST] <akravchenko188> thanks, I will try [22:21:14 CEST] <JEEB> lol, just ran static analysis on mpegts.c [22:21:49 CEST] <JEEB> au_end_flag is not utilized anywhere in read_sl_header. I guess it's from the spec, but still kind of funny :) [22:41:44 CEST] <cone-593> ffmpeg 03Anton Leontiev 07master:94818025394b: lavd/v4l2: Add ARGB and XRGB packed pixel formats [22:44:10 CEST] <jkqxz> akravchenko188: I replied with what I can see from just reading it; I will try to actually test it later this week. [23:04:44 CEST] <cone-593> ffmpeg 03Carl Eugen Hoyos 07master:6dc79637f34f: lavc/qdrw: Read PixMap palette. [23:14:09 CEST] <akravchenko188> jkqxz: thanks, I will send answer and fixes tomorrow [23:17:05 CEST] <kierank> JEEB: btw, in my use case i don't buffer [23:17:10 CEST] <kierank> variable latency and all that [23:17:29 CEST] <JEEB> yea [23:18:01 CEST] <JEEB> the only reason I'd do that is because people would start complaining about "lost" packets if I just dropped everything from before PCR arrives [23:18:11 CEST] <kierank> true [23:18:13 CEST] <JEEB> I think vlc drops things before [23:18:19 CEST] <JEEB> although I'm not 100% sure [00:00:00 CEST] --- Fri May 11 2018

1 0

ffmpeg.log.20180510
by burek 11 May '18

11 May '18

[00:00:20 CEST] <Purebes> It's possible I could setup that build chain and fix it but I'm not really sure how I'd maintain it since I have 4-5 different flavors to support [00:02:00 CEST] <tuxuser> I see, hmm.. sorry, no idea then [00:03:04 CEST] <tuxuser> its confusing tho, since ffmpeg detects #0.1 as audio [00:03:22 CEST] <tuxuser> can you maybe post a -loglevel debug pastebin? [00:03:30 CEST] <Satao> is there anything similar to the prft (presenter reference time box) from mp4 when outputing in mpegts? [00:03:36 CEST] <tuxuser> with: -i video="Blackmagic WDM Capture" [00:04:30 CEST] <JEEB> Satao: PCR is supposed to be the program clock reference [00:04:57 CEST] <JEEB> do note that standard MPEG-TS clock is a 90k time base with 33bit field [00:05:04 CEST] <JEEB> so every ~26 hours there's a wrap-around [00:05:26 CEST] <JEEB> not sure how big the PCR is, but the value is on a time base of 27 megahurtz [00:05:33 CEST] <JEEB> so 300 times 90000 [00:07:13 CEST] <Purebes> I can do that, https://pastebin.com/MVi9xX3R [00:07:38 CEST] <Purebes> Here's another one where I tried setting the crossbar pin numbers https://pastebin.com/VR2u7K4Z [00:10:50 CEST] <dragmore88> anyone got any tips on why i get silence in left and right channels with this syntax? -filter_complex "[0:a:6][0:a:7]amerge=inputs=2,pan=stereo[aout]" -map "[aout]" -codec:a aac -b:a 128k [00:14:05 CEST] <Satao> thks for the info JEEB. I was reading about that and I'm failing to understand how to achieve what I need [00:14:28 CEST] <Satao> to explain, I want to calculate the overall latency between encoder and presentation [00:16:05 CEST] <Satao> using isobmff I add an prft box with encoder localtime to each segment and read it in the player [00:16:25 CEST] <Satao> compare client time with encoder time [00:17:00 CEST] <Satao> now... if I'm using mpegts between encoder and packager... I loose that info [00:21:04 CEST] <Mista_D> tuxuser: https://pastebin.ca/4024153 its FFOUT var, I think arrows couse bash to add single quotes... [00:31:51 CEST] <tuxuser> Mista_D: Use $(FFOUT) instead of $FFOUT [00:33:21 CEST] <Mista_D> tuxer: My hat's off to you sir. Thanks! [00:33:40 CEST] <tuxuser> you're welcome [01:06:42 CEST] <Purebes> Turns out everything I said earlier was wrong, apparently the computers soundcard died a couple hours earlier... definitely did not expect that. [04:29:13 CEST] <brandor5> hello everyone: I'm looking to build an rpm for ffmpeg for fedora 28 and I'd like to use --enable-libfdk-aac... From the docs I see that I need to use --enable-nonfree as well, but how to enable those in the spec file is over my head... can anyone help a noob out? [04:32:33 CEST] <brandor5> hmm actually i just figured it out.... simply add `%global _with_nonfree 1` in the globals section at the top... :) [11:59:29 CEST] <cryptopsy> can ffmpeg be built with -O3 -flto -pipe ? [11:59:42 CEST] <cryptopsy> err, ffmpeg-4 [12:06:35 CEST] <furq> lto definitely [12:07:10 CEST] <furq> --enable-lto [12:07:46 CEST] <furq> --optflags=O3 but it's probably not guaranteed to work properly [12:32:56 CEST] <cryptopsy> i think i got 3.4 to build with O3 lto but 4 doesn't seem to work even without O3 [12:52:10 CEST] <cryptopsy> is 4.0.0 stable on gentoo? [13:19:47 CEST] <PureTryOut[m]> hey guys, ffmpeg segfaults for me when trying to use an file from sftp as input. turning on verbose logging doesn't show any interesting errors or warnings... [17:12:28 CEST] <tuna> does the output of av_log print to console or a file? [17:13:32 CEST] <c_14> normally console [17:14:33 CEST] <c_14> If you're using the API you can specify an av_log_callback though [17:26:58 CEST] <tuna> Thanks [17:30:21 CEST] <tuna> How often does the windows build of ffmpeg happen...if I requested some code changes to help me debug, how long till I would see these changes in the downloadable binaries? [17:32:18 CEST] <JEEB> we don't build official binaries at all [17:32:25 CEST] <JEEB> so I have no idea whom you requested help from [17:32:56 CEST] <JEEB> I think the quickest way to test is to have a local linux system in either a VM or in the Windows Subsystem for Linux running a cross-compilation [17:33:10 CEST] <JEEB> (or you can of course build natively, but welcome to "configure script takes 15 minutes") [17:33:35 CEST] <tuna> Yea I just tried building with mingw and had an awful time...haha [17:33:41 CEST] <tuna> couldnt get it to work [17:35:08 CEST] <JEEB> no idea what you hit, but it shouldn't be too hard unless someone failed at packaging/installing something [17:49:49 CEST] <friki_> Hi. I'm testing ffplay against an https url and it works even with an invalid certificate [17:50:30 CEST] <JEEB> yes, many of the TLS things in FFmpeg seem to disable CA checking by default [17:51:58 CEST] <friki_> IMAO, it should be fixed [17:52:49 CEST] <cryptopsy> '<portage.util._dyn_libs.LinkageMapELF._ObjectKey object at 0x7f0c2853c328> (/usr/lib64/libavutil.so.55.78.100) not in object list' [17:53:07 CEST] <JEEB> not sure if there's been discussions about that, but to be honest I'm not sure if invalid certificates are a major issue with FFmpeg's use cases [17:53:24 CEST] <JEEB> there's an AVOption which you can set of course to force validation [17:53:41 CEST] <JEEB> you can even propose a patch that sets that option to 1 by default [17:53:53 CEST] <JEEB> as I said, I haven't ctrl+F'd the mailing list archives about this [17:54:39 CEST] <friki_> it may become critical in some common situations like "hls push". Even downloading the wrong video may envolve security problems [17:54:51 CEST] <friki_> ok, i'll take a look arround, thanks for your time, JEEB [17:56:07 CEST] <JEEB> friki_: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/tls.h;h=beb19d6d… [17:56:19 CEST] <JEEB> so -tls_verify is the common option [17:56:38 CEST] <philipp64> what's an example of taking a separate audio and video stream and multiplexing them together programmatically? [17:56:41 CEST] <JEEB> depending on the TLS library you may or may not need to specify a CA file [17:57:58 CEST] <JEEB> philipp64: open avformat contexts for both, open up an output avformat context. add streams to it as needed, call the write headers function and then read both while feeding the AVPackets from streams you "picked" to the streams in the output avformat context [17:58:51 CEST] <JEEB> that's the gist of it and expects that your timestamps on both inputs are somehow relevant. if they are off-sync, you will have to deal with that by adjusting timestamps so that the streams' timestamps are aligned so that they make sense [17:59:19 CEST] <philipp64> i figured the multiplexor would read from the contributing streams... is there a snippet out there in an example of doing this? I figure it's something reasonably common... [17:59:22 CEST] <JEEB> for example, if you just have 2 seconds extra of audio and you somehow know that, then you have to make sure that the video timestamps start with the 2 second mark [18:00:57 CEST] <JEEB> there are examples under docs/examples [18:01:14 CEST] <JEEB> one of them has demuxing at least, and then there's a remuxing example as well? [18:01:27 CEST] <JEEB> also googling `site:ffmpeg.org doxygen trunk KEYWORD` [18:01:28 CEST] <JEEB> generally helps [18:06:41 CEST] <tuna> I found something interesting in the code...the EINVAL possible return of av_pix_fmt_count_planes is not handled on line 753 of frame.c..........this is not a bug to me, just something that seems off [18:07:30 CEST] <tuna> But I guess that should never really return, at least the route I have taken...becuase the check that returns that error is checked before this func is called....prob non issue [18:54:12 CEST] <tuna> BtnB: I Found the mysterious EINVAL I believe...seems its on line 98 of imgutils....its an if that checks: [18:54:14 CEST] <tuna> if (!desc || desc->flags & AV_PIX_FMT_FLAG_HWACCEL) [18:54:39 CEST] <tuna> inside of av_image_fill_linesizes [18:55:00 CEST] <BtbN> why are you calling that? [18:55:46 CEST] <tuna> damnit....nvm...seems its not possible [18:56:04 CEST] <tuna> because of !frame->linesize[0] [18:56:08 CEST] <BtbN> btw., ffmpeg master can now give you the two nvenc rgb formats from the CUDA hwframes ctx [18:56:11 CEST] <tuna> line 219 of frame.c [18:56:43 CEST] <tuna> ah ok, thanks [18:56:47 CEST] <pablo__> Hello, I want to add a 5.1 .flac audio track to a .ts file that already has three audio tracks. I with ffmpeg with unsuccessful results. Everything seems to work fine until the very last moment when I check the file and the .flac audio track is not included in the "output.ts". The .flac track is about 3GB and its lenght is around two and a half hours. Thank you! [18:57:07 CEST] <JEEB> is FLAC in MPEG-TS even standardized? [18:57:37 CEST] <pablo__> JEEB: I don't know, I also used ffmpeg to converted it from a .wav file [18:58:34 CEST] <pablo__> I tried first with the .wav and decided to try it with flac, I thought size could be quite problematic [18:59:04 CEST] <JEEB> well, I am not 100% sure what on earth the mpegts muxer is doing, but it might jsut be muxing unknown stuff as "data" tracks [19:00:17 CEST] <JEEB> yes, seems like it would fit under "STREAM_TYPE_PRIVATE_DATA" [19:00:19 CEST] <pablo__> I don't know. It works flawlessly with smaller files but not with bigger ones [19:00:21 CEST] <JEEB> good luck reading that out [19:00:44 CEST] <JEEB> at most ffmpeg.c could maybe figure out and probe the stream, but I have my doubts [19:00:55 CEST] <JEEB> or well, libavformat I guess, since that's doing the probing :P [19:01:09 CEST] <JEEB> what I'm trying to tell thee is that FLAC in MPEG-TS is not going to work [19:01:26 CEST] <JEEB> if it has ever worked for you that has been a miracle [19:06:10 CEST] <furq> 17:59:04 ( JEEB) well, I am not 100% sure what on earth the mpegts muxer is doing, but it might jsut be muxing unknown stuff as "data" tracks [19:06:24 CEST] <furq> this is exactly what ffmpeg does so i guess lavf does the same [19:07:04 CEST] <JEEB> ffmpeg.c just feeds it to lavf [19:07:08 CEST] <JEEB> thus, it is lavf that does that [19:07:08 CEST] <furq> it's quite happy to mux it and then ffprobe just gives unsupported codec [19:07:21 CEST] <JEEB> since I don't see it having a format check [19:07:31 CEST] <JEEB> just cases for various known-working things [19:09:14 CEST] <^Neo> hello [19:09:40 CEST] <^Neo> can I chain encodes together in a single FFmpeg command? [19:09:47 CEST] <pablo__> is there any size limitation when adding a .wav track? [19:10:10 CEST] <^Neo> so do something like input > scale > encode > decode > scale > encode > output [19:12:49 CEST] <JEEB> pablo__: none other than in WAV itself :P [19:13:01 CEST] <JEEB> WAV after all is a RIFF format and thus has its own size limitation [19:13:13 CEST] <JEEB> some applications work around that by having multiples of something in the WAV file [19:13:23 CEST] <JEEB> then there are extensions/improved formats like WAV like W64 [19:14:42 CEST] <pablo__> Oh okay, I'm gonna try w64 then [19:14:45 CEST] <pablo__> thank you! [19:15:37 CEST] <furq> ^Neo: no [19:15:44 CEST] <furq> unless piping counts [19:16:05 CEST] <^Neo> furq: OK, that's what I thought... thanks! [19:17:09 CEST] <furq> is there a list of supported mpegts codecs somewhere [19:17:23 CEST] <furq> google's not helping [19:17:38 CEST] <JEEB> it's in multiple specs just to make it funnier for you [19:17:42 CEST] <JEEB> the general ITU-T H.222 spec [19:17:49 CEST] <JEEB> and then the DVB specs (thankfully freely available) [19:17:56 CEST] <JEEB> and the ATSC/ARIB/china/whatever specs [19:18:00 CEST] <furq> i mean i could just ask in here [19:18:11 CEST] <furq> does it support any lossless/uncompressed audio codec that ffmpeg has an encoder for [19:18:42 CEST] <JEEB> I would rather read the switch statement in the mpegtsenc.c file in that case [19:18:48 CEST] <JEEB> in the write PMT function [19:18:49 CEST] <furq> apparently pcm doesn't work so the best thing i can think of is mp4 als and dtsma [19:18:56 CEST] <ariyasu_> ac3/aac/mp2 = only broadcast audio i have ever seen [19:18:58 CEST] <furq> and neither of those are in ffmpeg last i checked [19:18:59 CEST] <JEEB> huh, PCM doesn't work? [19:19:08 CEST] <JEEB> MPEG-TS most definitely has extensions for raw PCM [19:19:09 CEST] <furq> doesn't look like it [19:19:19 CEST] <JEEB> ok, then that's a limitation in the muxer [19:19:40 CEST] <JEEB> I mean, blu-ray uses it just fine and I'm pretty sure it's specified somewhere :P [19:20:03 CEST] <JEEB> mpegts_write_pmt [19:20:18 CEST] <^Neo> s302m is dual channel pcm? [19:20:19 CEST] <JEEB> this is the function that has the switch around st->codecpar->codec_id [19:20:34 CEST] <JEEB> ^Neo: yea but not even going there (that's codec bit stream in PCM) [19:20:40 CEST] <JEEB> *coded bit stream [19:20:49 CEST] <^Neo> fair [19:20:49 CEST] <JEEB> there is actual PCM support in MPEG-TS [19:21:43 CEST] <furq> yeah i forgot about bluray audio [19:22:22 CEST] <furq> i wonder if that's new in the bdav spec or whatever they call m2ts [19:23:22 CEST] <JEEB> m2ts is just 192 byte MPEG-TS [19:23:26 CEST] <JEEB> nothing really special to be honest [19:23:38 CEST] <JEEB> heck, they even used it in H.222 with DVDs, so it's *old* [19:23:54 CEST] <JEEB> (DVDs were MPEG-PS though, not -TS) [19:23:58 CEST] <furq> i was about to say [19:24:53 CEST] <JEEB> but it's the same spec, just different type of stream [19:25:06 CEST] <JEEB> most likely case is that nobody needed raw PCM support [19:25:13 CEST] <JEEB> so nobody implemented it in mpegtsenc [19:25:20 CEST] <furq> that would also make sense [19:25:54 CEST] <JEEB> file an issue about it, see if someone cares enough (I've got enough things on my todo list to now being over two months late with various more fun things than coding open source) [19:33:29 CEST] <pablo__> Yay, it works flawlessly with .w64! Thanks again :) [20:18:57 CEST] <SpeakerToMeat> what do you guys consider is the best quality scaling algo for upscaling? Lanczos? [20:21:01 CEST] <philipp64> JEEB: sorry for being a bit thick-headed... I'm actually a kernel hacker and don't play with ffmpeg (or libavcodec) much... can I then read from the output stream? I'd figure that taking 2 input streams and multiplexing them together would result into another input stream... or maybe I'm just thinking too much in the GStreamer paradigm of things... I looked in doc/examples and couldn't... [20:21:03 CEST] <philipp64> ...find an example like you talked about, but maybe I missed it or your talking of some other examples... [20:21:46 CEST] <JEEB> philipp64: I don't think you want to be reading too much into the output context's streams [20:21:47 CEST] <philipp64> my scenario is I have two sockets open with video/webm and audio/webm and I want to create a single, synchronized stream that I can then read from. [20:22:17 CEST] <JEEB> ok, is anything synchronizing the timestamps in those webm inputs? [20:23:00 CEST] <philipp64> they should both be zero based... they'll have different ts's, but that shouldn't be a problem, should it? [20:23:15 CEST] <JEEB> or is it just that you have to note that you received the first packet from input X at monotonic clock stamp Y, and for Z at Q - and hope those two mean what time they contain? [20:23:23 CEST] <JEEB> and then adjust accordingly [20:23:37 CEST] <JEEB> yes, timestamps are a problem if your input doesn't synchronize them [20:23:52 CEST] <philipp64> in the trivial case, it's YT content and I'm using the adaptive content, pairing the matching video and audio so the duration, etc. should all match up... [20:24:45 CEST] <JEEB> ok, if they match up then it's just a case of reading the packets from each input and pushing them to the matched up output streams [20:24:47 CEST] <philipp64> oh, I was thinking that the multiplexer would synchronize the 2 sources... [20:25:02 CEST] <JEEB> uhhh [20:25:10 CEST] <SpeakerToMeat> if it had something to sync on.... [20:25:23 CEST] <JEEB> like, yes. it will synchronize the output on the timestamps it receives [20:25:42 CEST] <JEEB> but what I was asking is if the timestamps actually mean something or not together [20:26:27 CEST] <JEEB> now, if you are just ripping the crap out of youtube then yes, most likely that is not a problem [20:27:24 CEST] <SpeakerToMeat> And if it's not a live stream, youtube-dl will probably take care of it (using ffmpeg) for you [20:27:27 CEST] <JEEB> you just feed the demultiplexed AVPackets through and just make sure your timestamps are accordingly adjusted for input/output AVStream time_base differences (there's a function for that) - although with matroska that would be most likely a no-change change since most likely youtube is using the default time_Base [20:27:43 CEST] <JEEB> yes, youtube-dl can call ffmpeg.c to re-multiplex the separate audio and video [20:28:10 CEST] <philipp64> let's say the video is 60fps and the audio is 44.1KHz... I guess the duration of the audio will need to be 1/60s (which is probably isn't) otherwise I'll need to apply some gating function to packets to apply a merge-sort. [20:28:45 CEST] <JEEB> the streams are generally separate [20:28:54 CEST] <JEEB> as long as the packets' timestamps are correct it's all good [20:29:08 CEST] <kepstin> the timestamps on the youtube audio and video streams should align correctly, so just doing "ffmpeg -i video.webm -i audio.opus output.mkv" or whatever should do the right thing :/ [20:29:11 CEST] <JEEB> generally you receive packets with a single audio packet anyways, and you can't "cut" that any more than that anyways [20:29:19 CEST] <SpeakerToMeat> at 60fps 44.1khz adio comes out at 735 unites per frame [20:29:23 CEST] <JEEB> since it's compressed packets [20:29:48 CEST] <SpeakerToMeat> audio, units [20:29:50 CEST] <JEEB> so don't really care about the FPS and the audio rate being separate [20:29:52 CEST] <philipp64> sorry, I need to do this programmatically, not CLI... [20:29:59 CEST] <JEEB> they are separate streams [20:30:28 CEST] <philipp64> I actually don't ever both to render the content... I'm performing broadband measurements (stalls, etc). [20:30:31 CEST] <JEEB> philipp64: I haven't read too much into this, but there's this example http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/examples/remuxing.c;h=9e… [20:30:57 CEST] <klaxa> i think i used that a lot [20:31:40 CEST] <klaxa> yeah my muxing stuff is basically remuxing.c :P [20:31:55 CEST] <JEEB> but yea, the gist is - make one AVFormatContext for input, another for output. figure out the streams you want from the input, create streams in output that match, then write the "header" (there's a function for that), and then start pushing AVPackets into the output [20:31:55 CEST] <kepstin> philipp64: hmm, are you trying to analyze network behaviour of a simulated player? [20:31:59 CEST] <JEEB> and at the end you flush it [20:32:08 CEST] <JEEB> that's how you re-multiplex [20:32:20 CEST] <philipp64> kepstin: something like that, yeah. [20:32:21 CEST] <JEEB> from FFmpeg's perspective that's all that there is [20:32:41 CEST] <kepstin> philipp64: note that unlike the real youtube player, ffmpeg won't dynamically switch quality levels and whatnot, that's up to you to decide how to handle [20:32:56 CEST] <JEEB> also if you're simulating playback, players never re-multiplex [20:32:59 CEST] <JEEB> they just play [20:33:13 CEST] <JEEB> so I'm not sure why you'd be re-multiplexing? [20:33:19 CEST] <JEEB> other than if you want to check the results [20:33:22 CEST] <kepstin> philipp64: but you can do this pretty much completely independently for the audio video streams - read each stream separately in its own thread or process or whatever, and slow it down by timing it to the system clock [20:33:25 CEST] <JEEB> for data corruption [20:33:56 CEST] <kepstin> (a real video player would usually time to the sound card clock, but system clock's good enough for this) [20:33:59 CEST] <philipp64> JEEB: actually, I'd want to "read" the output packets as if it were another input... since that's the way way the code is structured... i.e. if it's a multiplexed stream like the YT classic format with MP4 video and audio combined, then read from that stream... [20:34:15 CEST] <JEEB> you lost me [20:34:22 CEST] <philipp64> if it's two separate streams, multiplex them together into a new pseudo-stream and read from that. [20:34:29 CEST] <kepstin> philipp64: ffmpeg abstracts the multiplexing away - you just read separately from each stream [20:35:09 CEST] <kepstin> philipp64: and then time each stream to the system clock to slow it down to simulate realtime playback. done. [20:36:09 CEST] <philipp64> okay, I want to read from a single AVFormatContext, but have packets interleaved that have their stream_index and PTS/DTS all sorted out for me... just like it was coming from a container that held all of the combined content. [20:36:54 CEST] <JEEB> then you need something separate that puts your multiple inputs into a single thing :P [20:37:09 CEST] <philipp64> kepstin: I already have something that does that, but it expects a single AVFormatContext, as above... reading from 2 different ones will require adding another thread, rewriting the code, etc. [20:37:17 CEST] <JEEB> PTS/DTS synchronization is all sorted for you... if your input makes sense when put together [20:37:26 CEST] <kepstin> philipp64: well, just run two copies of it, one with the video one with the audio :/ [20:37:36 CEST] <kepstin> should give basically the same results. [20:37:44 CEST] <philipp64> JEEB: yes, that's what I'm asking for... a Y-connector that got knocked over... [20:38:10 CEST] <JEEB> ok, then just look at the remuxer example and add another avformatcontext [20:38:16 CEST] <philipp64> this would be so much easier in GStreamer.... [20:38:18 CEST] <JEEB> then output to whatever abomination you want with the AVIO stuff [20:38:23 CEST] <JEEB> oh really? [20:38:49 CEST] <philipp64> well, that might just be because I'm much less versed in ffmpeg... [20:39:35 CEST] <JEEB> anyways, I don't see the reason why you need the Y connector because couldn't you just read from both input avformatcontexts during each loop or something? [20:39:46 CEST] <JEEB> if you're not having to do any extra timestamp adjustments then that should just work [20:39:51 CEST] <philipp64> JEEB: the code as it stands expects to read MPEG with audio and video as 2 streams in the same format context... [20:40:26 CEST] <JEEB> anyways, I've given you enoug hints already and it's almost ten PM and I've still not reviewed the bloody code I thought I'd review today [20:40:29 CEST] <philipp64> I want to trick it to think it's getting a single format context (which I'm cobble together) from separate network streams of audio/webm video/webm. [20:41:10 CEST] <philipp64> I'll start coding and look at remux.c again and maybe it will start to make sense once I start throwing things together... [20:41:19 CEST] <philipp64> * remuxing.c [20:41:52 CEST] <philipp64> too bad there's not a canned function to setup the merge for me... [20:42:32 CEST] <kepstin> it's not needed, since in almost all cases you want to demultiplex audio and video streams to handle them separately. You're doing something really unusual :/ [20:42:54 CEST] <philipp64> kepstin: PM? [20:43:02 CEST] <kepstin> no. [20:43:43 CEST] <philipp64> well, for the adaptive bit, we don't have to try that. we just try lower and lower quality streams until we find one that doesn't cause buffer underruns. [20:47:11 CEST] <kepstin> so anyways, I guess you could write some code that downloads, demultiplexes, multiplexes, then hands of to your other code that demultiplexes again [20:47:38 CEST] <kepstin> but it would probably be easier just to adapt the existing code so you can run it on multiple parallel streams :/ [20:49:10 CEST] <JEEB> yes, that's what was my feeling as well :P [20:49:43 CEST] <JEEB> just have N AVFormatContexts. it will hurt at first, but IMHO much better than just making some sort of multiplexing [21:04:30 CEST] <philipp64> I thought about that... problem is that (a) I don't know how much data the next av_read_packet() is going to take, and (b) when I call it and we don't have enough data, it's going to block... [21:05:21 CEST] <philipp64> would be nicer if I could "feed" data to a function and it would tell me when it had a complete frame/packet ready for me. [21:06:26 CEST] <philipp64> when you're reading from a disk file, all the data is already available before you start so you can just read it as you go. with a network stream, data arrives asynchronously of course... [21:06:53 CEST] <JEEB> if you want to control the reading from network etc, you could just implement your own AVIO wrapper [21:07:07 CEST] <JEEB> you implement the callbacks for read/seek/write (according to what you actually support) [21:07:09 CEST] <philipp64> work-around is have N threads, one for each network connection... but this is running on an extremely resource-constrained embedded device. [21:07:29 CEST] <JEEB> https://github.com/jeeb/matroska_thumbnails/blob/master/src/istream_wrapper… [21:07:31 CEST] <philipp64> JEEB: what would that look like? what's an example? [21:07:40 CEST] <JEEB> there's an avio example in the examples dir [21:07:43 CEST] <JEEB> for the record :P [21:07:51 CEST] <JEEB> but that's what I coded up almost five years ago [21:08:25 CEST] <JEEB> you'd probably log with av_log or something in reality [21:08:39 CEST] <JEEB> (since you most likely set up your logging handling with a callback for that, too) [21:09:27 CEST] <philipp64> you're talking about http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/examples/avio_reading.c;… ? [21:09:34 CEST] <JEEB> yes [21:09:45 CEST] <JEEB> I've never looked at it, but I think the name implies it uses custom AVIO callbacks [21:10:24 CEST] <JEEB> and IIRC returning zero now is not an EOF I think? although you'd have to test it [21:10:32 CEST] <philipp64> well, it uses the read_packet() callback to drain data from a buffer... [21:10:44 CEST] <JEEB> yes, and you control what that calls [21:10:59 CEST] <JEEB> (AVERROR_EOF is now the EOF marker) [21:11:20 CEST] <philipp64> if you don't have enough data for a frame them it just keeps calling the read_packet() function until it does... [21:11:51 CEST] <philipp64> which makes it hard to poll multiple streams. [21:11:55 CEST] <JEEB> yes, that could be true, I don't remember the wrapper that calls read_packet and if it will keep looping for zeroes [21:12:15 CEST] <JEEB> but yea, if you think there are better ways for lavf to do IO I think new API proposals are welcome [21:12:26 CEST] <JEEB> we all know the current design is not perfect [21:12:51 CEST] <philipp64> well, if I did return zero... how would I signal back to it, "okay, I've got more data now"... not seeing how the API would accommodate that. [21:14:17 CEST] <JEEB> without longer thinking I would be looping over both inputs and if one didn't have anything I'd check the next one. and you get the usual loop with that. or you have an off-band marker for "I have more data" [21:14:37 CEST] <JEEB> and you call read on the input(s) when you know you've got some data in the buffers that you have for your AVIO [21:14:55 CEST] <philipp64> still doesn't fix it... having "more data" isn't the same as having "enough data", i.e. a full-packet. [21:15:25 CEST] <JEEB> sure [21:16:06 CEST] <JEEB> but for a full packet you need a parser for that format to begin with. and as I noted, if you have better ideas for IO interfaces design recommendations are welcome at the mailing list [21:18:34 CEST] <philipp64> I'm guessing av_get_packet() isn't relevant here, either. [21:19:32 CEST] <JEEB> I'm honestly not too sure what that was again [21:39:07 CEST] <SpeakerToMeat> Is there any "I can't believe it's not offitial", "all you could ever want ever!" "wow this is very current" build repo for debian stretch? [21:39:53 CEST] <JEEB> I'd guess not since setting up compilation on *nix is generally straightforward [21:40:13 CEST] <JEEB> and it's not like you don't know which things you need out of the kitchen sink (quite few in the end game) [21:40:45 CEST] <SpeakerToMeat> hm [21:40:46 CEST] <JEEB> because a default ../configure --disable-autodetect already gives you like 99% of all decoders etc [21:40:57 CEST] <JEEB> so that generally leaves you with "what encoders you need?" [21:41:08 CEST] <JEEB> as in, external ones [21:41:20 CEST] <JEEB> most popular one is probably libx264 [21:42:01 CEST] <SpeakerToMeat> Nod [21:42:08 CEST] <SpeakerToMeat> Makes sense [21:43:10 CEST] <SpeakerToMeat> Sigh I can't wait until either on the fly 22:1 lossless compression, or $15 20Tb ssd drives are a thing [21:48:24 CEST] <djk> SMB 1 turned off and the win10 machine aren't seeing each other or connecting with net use [21:51:17 CEST] <djk> sorry wrong channel [22:36:13 CEST] <Plippz> In some assignment we should run some ffmpeg.exe command in Windows, but I'd rather use Linux, so I tried the same in Linux: https://bpaste.net/show/ca77d0950dff no luck. Does the windows and linux versions have different command line argument syntax? Or must the windows version have an old version or something [22:36:53 CEST] <JEEB> no, that sounds like something that wouldn't work in windows, either [22:37:00 CEST] <JEEB> the keyword for input height IIRC was something like ih? [22:37:27 CEST] <JEEB> also I would recommend to specify which options for the filter you are setting [22:37:37 CEST] <JEEB> like scale=w=-1:h=ih [22:37:52 CEST] <klaxa> i want a class where you are supposed to use ffmpeg [22:38:08 CEST] <JEEB> (most likely you either needed to script that, or put the height you wanted where the text "height" is mentioned :P [22:40:31 CEST] <Plippz> JEEB: ah, I may indeed just need to replace 'height' :D [22:40:52 CEST] <Plippz> Yes indeed.. thanks! [22:40:55 CEST] <JEEB> but yea, the usage of unnamed options is not recommended [22:41:07 CEST] <JEEB> and might be removed in the future [22:41:14 CEST] <JEEB> (although I bet it won't be removed :P) [22:41:32 CEST] <JEEB> any new stuff you write should have name_of_option=value key-value list [23:23:15 CEST] <zerodefect> So I've been using the C-API to create a simple graph which uses the overlay filter. I'm overlaying an image which is 253x253 over a frame that is 720x576. What I've noticed is that when I create the 'buffer' filter for the overlay, I have to set the w/h to the size of the image otherwise the image/AVFrame's true dimensions are not respected during compositing. That caught me by surprise. [23:23:55 CEST] <zerodefect> Having looked at the activate() method in the overlay, I believe that the w/h of the overlay should be dynamic. [23:25:46 CEST] <durandal_1707> zerodefect: w/h on input image of overlay is not dynamic [23:26:34 CEST] <zerodefect> Yeah, I figured out after writing some sample code (as you suggested) - https://github.com/zerodefect/ffmpeg_overlay_demo :) [23:26:38 CEST] <durandal_1707> dynamic is only position where to overlay [23:27:29 CEST] <zerodefect> Isn't the w/h of overlay being updated in do_blend() method though? [23:30:02 CEST] <kepstin> the normal method for writing filters like that is to set the outlink w/h once at filter initialization, and use the same value during runtime [23:30:18 CEST] <kepstin> I don't think the filter chain system supports changing image size on filter links at run time at all? [23:30:21 CEST] <durandal_1707> zerodefect: for case it is partially not visible [23:31:01 CEST] <zerodefect> Darn [23:32:31 CEST] <zerodefect> Out of interest, is this the sort of problem that people regularly run into? [23:34:45 CEST] <zerodefect> It would be quite nice if there was an API that could be used to overlay AVFrames outside the filter graph (like the scaler). Thoughts? [23:35:23 CEST] <durandal_1707> zerodefect: i do not know what you are attempting to do [23:39:19 CEST] <zerodefect> Looking for a compositor to compose one overlay (or more?) frame at pos (x,y) over another; however, looking for something that is dynamic such that I can change both the x,y and dimensions of the overlay (so modify the properties of the overlay on the fly. Any actual modifications of the overlay would be done upstream). [23:40:20 CEST] <zerodefect> It makes for an easy way to implement simple(!) video effects (DVE). [23:47:41 CEST] <vlt> Hello. Id like to encode a video and space is not so much a concern but I want to avoid any "you CPU is too slow to play this" messages by mplayer. Which x264 preset or setting would you recommend? [23:48:29 CEST] <vlt> Does -preset ultrafast also affect CPU consumption during playback? [23:48:30 CEST] <JEEB> vlt: resolution, frame rate and your CPU are? [23:48:35 CEST] <JEEB> no [23:48:45 CEST] <durandal_1707> zerodefect: use multiple overlays, or something like shotcut [23:48:47 CEST] <vlt> JEEB: Full HD, 25 fps [23:48:50 CEST] <kepstin> vlt: it's rare for any settings on x264 to increase complexity enough to cause issues on modern computers - frame rate and resolution are the main issue. [23:48:50 CEST] <JEEB> I mean, it does but there is a separate tune [23:48:55 CEST] <JEEB> -tune fastdecode [23:49:11 CEST] <vlt> Intel(R) Atom(TM) x5-Z8300 CPU @ 1.44GHz [23:49:21 CEST] <vlt> JEEB: Perfect, thanks! [23:49:26 CEST] <JEEB> doesn't that have hwdec? [23:49:48 CEST] <kepstin> intel arc doesn't list quicksync on that, which is kinda weird [23:49:50 CEST] <JEEB> you can try with mpv and --hwdec=d3d11va-copy or the one without -copy [23:50:14 CEST] <JEEB> this one contains a quite recent build since lachs0r only builds releases https://github.com/mpv-player/mpv/pull/5804 [23:50:26 CEST] <vlt> JEEB: Maybe it has but I still got that message from mplayer (Ubuntu 16.04) on a "-preset slow" video. [23:50:33 CEST] <JEEB> oh, ubuntu [23:50:47 CEST] <JEEB> --hwdec=vaapi-copy then [23:50:57 CEST] <JEEB> although 16.04 will have an ancient mpv [23:51:37 CEST] <zerodefect> @durandal_1707, not familiar with shotcut. Is that some sort of API associated with open source video editor (just done web search) [23:52:09 CEST] <JEEB> for broadcast live overlays there was some norwegian thing [23:52:48 CEST] <vlt> JEEB: "oh, ubuntu"? What might be the problem there? Can you suggest something? [23:53:03 CEST] <JEEB> no, your initial comments just sounded like windows [23:53:04 CEST] <JEEB> :P [23:53:13 CEST] <JEEB> which is why I linked a windows build [23:53:16 CEST] <zerodefect> @JEEB: sounds interesting. Any more info? [23:53:19 CEST] <kepstin> zerodefect: honestly, I'd consider just converting the image to a pixel format you can use with, i dunno, cairo or something - then just use that to draw on top of the buffer. [23:54:25 CEST] <JEEB> zerodefect: I actually tried googling for it as I didn't remember the name of the open source project, but OBS basically overtook my keywords, and it's not that one [23:54:52 CEST] <zerodefect> @kepstin: not familiar with that project, but tht does look _very_ interesting. Thanks! [23:55:45 CEST] <zerodefect> Ok, no worries JEEB. I'll go down the route kepstin suggested [23:57:28 CEST] <durandal_1707> zerodefect: shotcut is gui video editor [00:00:00 CEST] --- Fri May 11 2018

1 0

ffmpeg-devel.log.20180509
by burek 10 May '18

10 May '18

[00:00:00 CEST] <cone-738> ffmpeg 03Michael Niedermayer 07master:293a6e83325a: avformat/mxfenc: Write transfer characteristic [05:36:38 CEST] <philipl> BtbN: I'm trying out your patches with mpv and I'm seeing glitched playback [05:36:54 CEST] <philipl> I tried forcing up the pool size but that didn't change anything so not immediately clear what the issue is. [05:37:21 CEST] <philipl> I'm seeing incorrect macroblocks at various points - like you'd expect if information was missing. [05:47:03 CEST] <philipl> BtbN: Mind you, I'm only seeing this with the infamous Sony 4k Camp video. I've got other 4k hevc stuff here that looks fine. [05:57:42 CEST] <philipl> BtbN: ok - scratch that. It was always broken. I guess I never tried it before. [05:58:05 CEST] <philipl> The sample plays correctly with cuvid, so I guess we're doing something wrong populating all the pic params. So unrelated issue. [05:58:11 CEST] <philipl> Other samples all played fine. [08:14:55 CEST] <lrusak> jkqxz, I've looked over your comments on my patch [08:15:41 CEST] <lrusak> I've no idea how AVCodecContext.get_format works. I assume if rkmpp outputted anything other than AV_PIX_FMT_DRM_PRIME that it would have to use that too? [08:17:48 CEST] <lrusak> we check avbuf->num_planes > 1 because well, that's what the existing code did and also because we will need special handling for NV12M [08:19:41 CEST] <lrusak> plane_info[n].bytesperline set for n > 0 <<< no, as we currently only work with single plane [08:20:07 CEST] <lrusak> no 10bit handling (I'm not sure if any driver supports 10bit output) [08:20:27 CEST] <lrusak> I've split out the cosmetic changes for the next round [08:21:05 CEST] <lrusak> I'll have to look into the hw_frames_ctx reference [08:22:08 CEST] <lrusak> and no hwdownload doesn't work and I have no idea what that is for [10:50:30 CEST] <BtbN> philipl, interesting, so even without the series applies, it's broken with nvdec? [11:00:51 CEST] <durandal_1707> ubitux: so you wanna implement bm3d too? [11:03:42 CEST] <ubitux> nah [12:43:10 CEST] <BtbN> philipl, do you see any increase in performance/decrease in CPU/system load when commenting out this line and doing a transcode? http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/nvenc.c;h=d61955c… [12:44:04 CEST] <BtbN> Someone is reporting that his system load "went from 15 to about 55" after the patch introducing it, and reverting it fixes it. [12:44:10 CEST] <BtbN> 32bc4e77f61a5483c83a360b9ccbfc2840daba1e [12:51:51 CEST] <durandal_1707> bm3d can use dct, we already have that it appears [13:02:11 CEST] <durandal_1707> anyone willing to comment on fftdnoiz filter? [13:18:37 CEST] <durandal_1707> gagandeep_: are you active? [13:19:19 CEST] <gagandeep_> yeah, i am looking in p frames [13:19:40 CEST] <gagandeep_> i just downloaded the samples in ffmpeg directory but 2 of them are intra frames [13:19:48 CEST] <gagandeep_> and 2 have buggy containers [13:21:17 CEST] <gagandeep_> initially i was trying to stop threaded tasks in Testcfhd [13:22:27 CEST] <gagandeep_> but bayer.c file has been used in decoder.c file such that on turning off THREADED macro in cineform compilation errors occur [13:26:10 CEST] <gagandeep_> durandal_1707: for the last 2 days i have been looking in the code for p-frames, and since they aren't exactly consistent with their naming scheme it takes time to find connections in code [13:27:09 CEST] <BtbN> Anyone have a better idea how to do this version checking? https://github.com/BtbN/FFmpeg/commit/39fca52122bbfda7a9b6a966b37b6296dba73… [13:33:17 CEST] <kierank> gagandeep_: should be temporal transform files in FFmpeg cfhd samples directory [13:34:58 CEST] <gagandeep_> kierank: i tried opening 2 files of samples even in after effects on my friends pc, but those 2 were not working, also not in TestCFHD, and the rest of files (2) are using intra frame function in TestCFHD [13:35:38 CEST] <gagandeep_> cineform differentiates the type of function it need based on the sample type [13:37:23 CEST] <gagandeep_> i think it uses group of frames (or gop) for p-frames [13:37:27 CEST] <kierank> I need to find the name of the file, but I had some picture of a mountain [13:37:30 CEST] <kierank> It doesn't use gop [13:37:48 CEST] <kierank> It has repeat frame flags but then it uses different transform type [13:37:54 CEST] <kierank> And it does a 3d transform [13:38:57 CEST] <gagandeep_> i don't mean gop as in mpeg [13:39:18 CEST] <gagandeep_> i think here they use gop as their own naming scheme [13:40:42 CEST] <kierank> Link? [13:43:49 CEST] <gagandeep_> https://github.com/gopro/cineform-sdk/blob/master/Codec/codec.h#L964 [13:44:07 CEST] <gagandeep_> sample struct only contains iframe and group [13:44:28 CEST] <gagandeep_> they only use group naming all over codec.h [13:45:19 CEST] <gagandeep_> only in 2 or 3 places in codec.h they use p-frame or inter frame [13:48:54 CEST] <kierank> gagandeep_: https://samples.ffmpeg.org/V-codecs/CFHD/MT_BeartoothHighway_1min_Cineform.… [13:49:24 CEST] <gagandeep_> yeah i have downloaded it, it gives error with testcfhd but opened in after effects [13:49:48 CEST] <kierank> I would try fixing testcfhd then [13:49:54 CEST] <kierank> otherwise you have no way of testing the clip [13:49:55 CEST] <gagandeep_> you sure this is p-frame [13:49:57 CEST] <kierank> yes [13:50:03 CEST] <kierank> it doesn't play in ffmpeg iirc [13:50:04 CEST] <gagandeep_> i will then focus on this file [13:51:12 CEST] <gagandeep_> kierank: i need to go afk, anything else you want to ask [13:51:21 CEST] <kierank> nothing [15:16:59 CEST] <jkqxz> lrusak: Yes, it would (rkmpp avoids needing get_format by only supporting the DRM object output). I'm not sure what the best reference for how to do this is, maybe the non-hwaccel hardware decoders in cuvid or qsv? Both have weird quirks, though. [15:17:39 CEST] <jkqxz> lrusak: So V4L2 NV12 /must/ have the chroma plane immediately following the luma plane in memory, and the pitch of the two planes /must/ be identical? If that's true then sure. [15:18:36 CEST] <jkqxz> I think newer things should support 10-bit output (even on mobile; Rockchip certainly does). If this isn't supported in V4L2 yet then I guess it can be ignored, though. [15:21:16 CEST] <jkqxz> hwdownload is a filter which takes a hardware frame and downloads it into a software frame, using the common hwcontext stuff. You should make it work, because that and mapping are clearly useful here once you go beyond trivial playback cases. [16:15:35 CEST] <cone-942> ffmpeg 03James Almer 07master:c6a63e11092c: avcodec/cbs_h2645: use AVBufferRef to store list of active parameter sets [16:20:58 CEST] <philipl> BtbN: So yeah - the Sony Camp video was broken before your change. I did not yet try to bisect to see if any of the recent hevc pic param changes are involved. [16:21:48 CEST] <philipl> As for register vs map. For OpenGL Interop, you are supposed to register/map/unregister at the beginning and then you unmap when you're finished with the surface. This was badly documented and I had bad CPU usage too until I changed it. [16:21:58 CEST] <philipl> I would guess it's the same here, given the terminoligy. [16:22:20 CEST] <philipl> ie: You only ned to be registered when you are mapping. [17:02:35 CEST] <jdarnley> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/vc2enc_dwt.c#L78 [17:03:14 CEST] <jdarnley> atomnuker: are the factors are right in that ^ line or am I missing something? [17:03:33 CEST] <jdarnley> The taps(?) of the filter are -1 9 9 -1 [17:04:04 CEST] <jdarnley> And the samples are mirrored at the edges. [17:05:09 CEST] <jdarnley> So shouldn't the mirroring for synthl[-2] be synthl[2]? [17:05:16 CEST] <atomnuker> not sure, those transforms came from the gsoc of 10 years ago [17:05:23 CEST] <jdarnley> Oh [17:06:32 CEST] <jdarnley> To ninish my question completely... [17:06:35 CEST] <jdarnley> *finish [17:07:09 CEST] <jdarnley> Shouldn't it be this? 9*synthl[0] + 8*synthl[2] [17:08:29 CEST] <jdarnley> I need to test against a reference [17:11:55 CEST] <philipl> BtbN: I commented it out. No change in fps but CPU usage went down 1 or 2%. fps is maxed anyway I think. nvidia-settings reports 100% utilisation. [17:12:15 CEST] <philipl> But yeah, I think you can unregister right after mapping. [17:12:40 CEST] <BtbN> I have to [17:12:51 CEST] <BtbN> the frame is unrefed right after, so not unregistering _should_ make it explode [17:12:58 CEST] <BtbN> i don't really understand why it doesn't [17:13:38 CEST] <philipl> I mean, you should unregister immediately after you *map* [17:13:58 CEST] <BtbN> hm? That seems a bit early [17:14:01 CEST] <philipl> If this works the same way as opengl interop, it only needs to be registered to map it. Nothing else. [17:14:34 CEST] <BtbN> Given that _nothing_ happens if you never unmap anything, I suspect it actually does nothing [17:17:34 CEST] <philipl> Maybe not. It's confusing. [17:17:44 CEST] <philipl> Could always ask the nvidia guys. Might even get an answer... [17:21:52 CEST] <philipl> BtbN: certainly the docs say you should register/map/use/unmap/unregister [17:22:13 CEST] <BtbN> Well, it's certainly required by the docs [17:22:22 CEST] <BtbN> but just not doing it doesn't break anything [17:22:34 CEST] <BtbN> which makes me suspect it's currently a noop [17:22:35 CEST] <philipl> I suppose it's leaking something. [17:22:45 CEST] <philipl> There's an entry somewhere that's going to stick around forever. [17:23:07 CEST] <BtbN> Well, given that in transcode-mode, there will only ever be the same ~10 frames re-used at all times... [17:23:21 CEST] <BtbN> I can see why not unregistering them makes it more efficient [17:23:56 CEST] <BtbN> hm, the only thing stopping me from pushing the series is the weird configure version thing [17:24:02 CEST] <BtbN> But I really don't think it can be done nicer [17:31:00 CEST] <philipl> BtbN: I don't see how either. [17:32:10 CEST] <philipl> BtbN: So, remind me. The frames here are being reused, ok. So you really just want to register them up front (or at least when you first see them) and then unregister when closing - that's perfectly fine and doesn't contradict anything, right? [17:43:07 CEST] <BtbN> nvenc has no idea the frames are going to be reused [17:43:38 CEST] <BtbN> for all it knows, after unref the pointers are invalid [17:54:40 CEST] <jdarnley> atomnuker: sorry about the noise. I was mistaken, they don't get mirrored, they get clipped. [18:10:05 CEST] <atomnuker> jdarnley: you're still going to verify them, right? [18:16:15 CEST] <jdarnley> yes [18:38:57 CEST] <jamrial> jkqxz: would https://pastebin.com/AufYmR2q work around the remaining case of potential dangling references? [19:21:57 CEST] <durandal_1707> can i apply dct of non power of 2 with padding do something with it and do inverse without affecting quality? [19:23:41 CEST] <jkqxz> jamrial: Seems reasonable? Though it also loses the copy property, so the user can unexpectedly change the stored SPS again. (That was also true before the previous change, so probably doesn't matter.) [19:26:04 CEST] <atomnuker> durandal_1707: no [19:26:47 CEST] <atomnuker> what are you trying to do? [19:28:35 CEST] <durandal_1707> atomnuker: 3d dct for bm3d [19:28:55 CEST] <jamrial> jkqxz: that's why i set the read_only flag, even if it's not foolproof [19:30:43 CEST] <durandal_1707> atomnuker: what are minimal and maximal bits for av_dct ? [19:34:50 CEST] <atomnuker> must be between 4 and 15 [19:35:10 CEST] <atomnuker> its limited by the rdft [19:36:45 CEST] <durandal_1707> atomnuker: why not 3? [19:44:22 CEST] <atomnuker> because of how rdft splits the transform into 2x ffts [19:44:55 CEST] <atomnuker> though looking at the code I think it would be safe to go down to 2 bits [19:50:25 CEST] <durandal_1707> atomnuker: please add it [19:55:12 CEST] <atomnuker> I'll need to test it first [19:56:07 CEST] <atomnuker> if you can go ahead, remove the limit and test it though, I'm working on detangling the FFT from lavc [19:57:26 CEST] <durandal_1707> it just needs new tables? [20:02:40 CEST] <ubitux> it seems i have temporal denoising working in nlmeans. [20:09:12 CEST] <ubitux> i used the "activate" model, but i'm not sure i'm doing it exactly right [20:12:18 CEST] <ubitux> durandal_1707: https://github.com/ubitux/FFmpeg/commits/nlmeans-temporal [20:12:21 CEST] <ubitux> if you want to test [20:12:59 CEST] <durandal_1707> ubitux: why you use activate? its only for >1 inputs [20:13:54 CEST] <ubitux> dunno, the buffering logic i needed felt a bit tricky [20:14:37 CEST] <ubitux> you think i should use request_frame callback instead? [20:16:43 CEST] <durandal_1707> ubitux: if you could peek frames from internal lavfi queue keep it [20:18:50 CEST] <durandal_1707> see ff_framequeue_peek [20:20:19 CEST] <ubitux> i guess i'll try to switch to the "legacy" model [20:20:53 CEST] <philipl> BtbN: isp fell over. Miss anything? [20:21:19 CEST] <BtbN> <BtbN> nvenc has no idea the frames are going to be reused [20:21:19 CEST] <BtbN> <BtbN> for all it knows, after unref the pointers are invalid [20:22:37 CEST] <durandal_1707> ubitux: no! [20:23:03 CEST] <ubitux> no? [20:23:14 CEST] <ubitux> legacy = filter_frame+request_frame [20:23:19 CEST] <ubitux> you want me to keep activate? [20:23:38 CEST] <durandal_1707> ubitux: i see that its nicer soluion than legacy or keeping frames in filter private struct [20:24:13 CEST] <durandal_1707> ubitux: yes, you do not need to store frame in private filter place, just use lavfis fifos [20:24:49 CEST] <durandal_1707> use #define FF_INTERNAL_FIELDS 1 [20:24:52 CEST] <ubitux> do i have the same control on the fifo? [20:25:06 CEST] <ubitux> like, i need a delay of `n` (user specified) [20:25:14 CEST] <ubitux> and that's basically it [20:25:23 CEST] <ubitux> (+ making sure the flush works) [20:25:39 CEST] <durandal_1707> you can peek any frame in fifo, and just request for more until eof [20:25:51 CEST] <ubitux> well, i don't exactly need absolute peek [20:26:00 CEST] <ubitux> it's linear, the cycling i'm using is just to avoid memmoves [20:26:34 CEST] <ubitux> it's not much code [20:26:36 CEST] <durandal_1707> i'm just saying that lavfi already provides fifo with .activate model [20:26:51 CEST] <durandal_1707> it can be rewritten latter [20:27:10 CEST] <durandal_1707> you can keep .activate .... [20:27:23 CEST] <ubitux> mmh [20:29:58 CEST] <ubitux> is there any filter currently making use of it? [20:33:06 CEST] <durandal_1707> ubitux: making use of what? [20:33:11 CEST] <ubitux> the fifo [20:33:14 CEST] <JEEB> framesync2 I guess? [20:34:00 CEST] <durandal_1707> ubitux: amerge [20:34:42 CEST] <ubitux> mmh [20:34:47 CEST] <ubitux> well, i'll check later [20:34:54 CEST] <ubitux> not sure all of this is worth the hassle [20:35:12 CEST] <ubitux> anyway, if i understand https://github.com/Khanattila/KNLMeansCL/wiki/Filter-description correctly, KNLMeansCL(clip, 6, 32, 3, 4.0) translates to nlmeans=n=13:r=33:p=3:s=4 [20:35:18 CEST] <ubitux> it's taking a while :p [20:36:14 CEST] <ubitux> it's really blurry, so i guess it's not exactly this [20:36:19 CEST] <ubitux> maybe s=0.4... [20:36:35 CEST] <ubitux> which isn't supported [20:36:37 CEST] <ubitux> oh well. [20:37:32 CEST] <BtbN> hm, is FFALIGN(x, 256)*2 the same as FFALIGN(x*2, 256)? [20:38:32 CEST] <BtbN> for all cases i tested it, it was. But I'm not sure if it's universally true [20:43:04 CEST] <jdarnley> BtbN: I think the first is FFALIGN(x*2, 512) [20:43:18 CEST] <ubitux> with x=3, FFALIGN(x, 256)*2=512 and FFALIGN(x*2, 256)=256 [20:43:40 CEST] <ubitux> it's basically false from x=1 to x=128 [20:43:53 CEST] <BtbN> ok, so the hwcontext_cuda implementation is wrong. [20:45:28 CEST] <BtbN> wrong in a not trivially fixable fashin, hm [20:48:37 CEST] <BtbN> It calculates the buffer size using "FFALIGN(width, 256) * element_size", while the code to fill the data and linesize pointers uses FFALIGN(width * element_size, 256) [20:48:47 CEST] <BtbN> the later seems more correct to me [20:54:31 CEST] <durandal_1707> ubitux: amerg4 [20:54:44 CEST] <durandal_1707> please ignore [20:55:26 CEST] <philipl> BtbN: you found a case where you get different results? [20:55:39 CEST] <BtbN> well, it's unlikely, but possible [20:55:58 CEST] <BtbN> it's also silly to have the logic duplicated [20:57:19 CEST] <philipl> certainly [21:00:06 CEST] <BtbN> hm, pixdesc isn't overly helpful for this either, as it behaves differently for RGB [21:02:36 CEST] <philipl> You have a use-case for RGB or just doing it for fun? [21:02:49 CEST] <BtbN> well, if you want to pass OpenGL frames to nvdec [21:02:54 CEST] <BtbN> You need to copy from that Array [21:03:07 CEST] <BtbN> so having a frames_ctx actually just give you the RGB frames is handy [21:03:25 CEST] <BtbN> and it's like 4 lines of code [21:05:06 CEST] <philipl> BtbN: to nvenc you mena [21:05:19 CEST] <BtbN> yeah [21:27:07 CEST] <cone-942> ffmpeg 03Aman Gupta 07master:dd77cca1c4b4: avcodec/videotoolbox: cleanups [21:27:08 CEST] <cone-942> ffmpeg 03Aman Gupta 07master:07d175d0b0b2: avcodec/videotoolbox: split h264/hevc callbacks [21:27:09 CEST] <cone-942> ffmpeg 03Aman Gupta 07master:a19bac8fc8b6: avcodec/hevc: remove videotoolbox hack [21:30:32 CEST] <cone-942> ffmpeg 03Aman Gupta 07master:12ceaf0fbacb: ffprobe: fix SEGV when new streams are added [21:34:26 CEST] <tmm1> JEEB: found an edge case bug in mpegts section parser where it ignores multiple tables in a single packet [21:34:37 CEST] <JEEB> \o/ [21:36:13 CEST] <BtbN> philipl, this logic in hwcontext_cuda is completely messed up wtf [21:36:28 CEST] <BtbN> it gets to the right result, but it's really convoluted [21:36:43 CEST] <philipl> I take no credit for it, fortunately. [21:36:52 CEST] <philipl> or is this my 10bit handling? [21:37:09 CEST] <BtbN> 10 bit is just 16 bit for this purpose [21:37:15 CEST] <BtbN> this only cares about bytes [21:37:43 CEST] <BtbN> calling it aligned_width is just incredibly confusing as well [21:38:16 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commit/6a25397a86b636c98bac3dd0c4432ea916a10… [21:38:57 CEST] <philipl> I think the CUDA alignment part was your doing :-) [21:39:11 CEST] <BtbN> I feel like all of this can also easily be generalized using pixdesc. All the info should be in there. [21:39:19 CEST] <philipl> Agreed on that. [21:39:20 CEST] <BtbN> It's just not straight forward because of the alignment [21:39:40 CEST] <BtbN> if not for the alignment, this would just be av_get_padded_bits_per_pixel() * height [21:40:02 CEST] <philipl> Did we prove that cuda alignment made a difference? [21:40:23 CEST] <BtbN> cuMemcpy2D will straight up error on you if you don't align. [21:40:28 CEST] <cone-942> ffmpeg 03Aman Gupta 07master:2c500f50972c: avformat/mpegts: skip non-PMT tids earlier [21:40:48 CEST] <BtbN> unless you use cuMemcpy2DUnaligned, which will be dirt slow in cases where the normal function would error [21:41:31 CEST] <BtbN> If not for YUV420P, this could all just use cuMemAllocPitch. [21:41:40 CEST] <BtbN> But cuMemAllocPitch does not support different line-sizes per component [21:42:25 CEST] <BtbN> I don't think we have ever tested hwframe input with YUV420P in it to nvenc though [21:42:30 CEST] <BtbN> it might be plain broken [21:42:38 CEST] <philipl> It's hard to produce that scenario [21:42:43 CEST] <JEEB> tmm1: btw that PMT thing, doesn't parse_section_header already move the pointer? [21:42:51 CEST] <JEEB> or do we put another copy of the pointer into pmt_cb [21:43:01 CEST] <JEEB> so if we early return from it, we can then just fallback [21:43:11 CEST] <BtbN> nvenc clearly only wants one pitch parameter, over all planes [21:43:16 CEST] <philipl> BtbN: anyway, change looks reasonable. [21:43:27 CEST] <BtbN> but I think it's documented that for YUV420 it will halve the pitch for plane 1 and 2 [21:44:36 CEST] <BtbN> it's also still funny that the data planes 1 and 2 are swapped, just to make ffmpeg yuv420 and nvenc yuv420 match up [21:45:14 CEST] <philipl> Yeah. More evidence of disuse... [21:45:15 CEST] <tmm1> JEEB: the issue was skip_identical changes tssf->last_ver [21:45:27 CEST] <JEEB> yea [21:45:46 CEST] <tmm1> the stream pointer doesn't matter, although i think pmt_cb has its own pointer into the buffer [21:45:52 CEST] <BtbN> philipl, hm, actually, it's pretty easy to test yuv420p hw input into nvenc [21:45:54 CEST] <JEEB> ah, ok [21:46:01 CEST] <BtbN> just putting a hwupload_cuda into any sw chain will achive it [21:46:02 CEST] <JEEB> yea, that's the only thing that kept me from going LGTM [21:46:03 CEST] <BtbN> and it works [21:46:08 CEST] <JEEB> since I didn't have the time to double-check it [21:46:30 CEST] <tmm1> yea for sections the entire thing is copied into a temp buffer anyway [21:46:31 CEST] <JEEB> but yup, then that was LGTM :) [21:46:37 CEST] <JEEB> ah, ok [21:46:44 CEST] <JEEB> I've really just begun hacking on mpegts.c [21:46:44 CEST] <tmm1> and then it only parses the first table in the buffer heh [21:46:46 CEST] <philipl> BtbN: The get_buffer stuff is confusing. [21:47:11 CEST] <BtbN> you mean the offset calculations in cuda_get_buffer? [21:47:21 CEST] <philipl> Why is data[2] taken as an offset from data[0] and data[1] an offset from data[2] [21:47:26 CEST] <JEEB> like https://github.com/jeeb/ffmpeg/commits/mpegts_arib_stuff [21:47:26 CEST] <philipl> What is data[1] originally? [21:47:38 CEST] <cone-942> ffmpeg 03Aman Gupta 07master:1a14e3914581: avformat/mpegts: use MAX_SECTION_SIZE instead of hardcoded value [21:47:39 CEST] <cone-942> ffmpeg 03Aman Gupta 07master:07d9c31055e6: avformat/mpegts: clean up whitespace [21:47:57 CEST] <BtbN> philipl, just because data[2] and data[1] are swapped [21:48:14 CEST] <BtbN> that's exactly the yuv420p special case [21:48:18 CEST] <philipl> Oh, ok. Because it starts off contiguous and then it has to be calculated relative to the previous plane. [21:48:21 CEST] <philipl> yeah, yeah. [21:54:00 CEST] <BtbN> calculating the size of a plane is not easy in a generic way [22:25:48 CEST] <BtbN> philipl, am I missing something, or should this just do it? https://github.com/BtbN/FFmpeg/commit/8eac960e89de6ce6fb614a9a401a99a043ed3… [22:30:52 CEST] <philipl> BtbN: Sure - I didn't know about av_image. [22:31:04 CEST] <BtbN> Why was this not done like this in the first place? [22:31:11 CEST] <philipl> For that reason. [22:31:15 CEST] <philipl> None of us knew about it. [22:31:41 CEST] <BtbN> I knew those functions existed. I just had no idea they could be used. [22:32:07 CEST] <BtbN> the supported pix fmt list is now kinda silly [22:32:10 CEST] <BtbN> it supports all of them [22:32:56 CEST] <philipl> Is there a way to express that? [22:33:05 CEST] <BtbN> not really [22:33:36 CEST] <BtbN> since it fills a valid_sw_formats list [22:33:38 CEST] <philipl> So. shouldn't the YUV420P swap happen inside nvenc? [22:33:44 CEST] <BtbN> can't [22:33:54 CEST] <BtbN> hwinput only wants the main pointer [22:33:56 CEST] <philipl> if you view this as generic frame storage, it shoudn't silently flip it [22:34:00 CEST] <philipl> ugly [22:34:15 CEST] <BtbN> if you don't use it for nvenc, but only for yourself, the swapping has no meaning for you [22:34:29 CEST] <BtbN> you grab the pointers from data[x], and don't even notice the swapping [22:34:42 CEST] <BtbN> it's only nvenc which registers only the data[0] pointer and goes from there that cares [22:35:34 CEST] <philipl> That's confusing. [22:35:45 CEST] <philipl> That implies the buffer is already flipped [22:35:58 CEST] <BtbN> nvenc just doesn't expect YUV420P, but I420 [22:36:05 CEST] <BtbN> which is identical, except that V comes first [22:36:26 CEST] <philipl> Yes, but I mean you say we pass data[0] to nvenc and it does everything internally. [22:36:29 CEST] <BtbN> to avoid entirely pointless and costly pix_fmt conversions, ffmpeg pretents it's YUV420P [22:36:32 CEST] <philipl> So it must already be flipped. [22:36:38 CEST] <philipl> or how can it work [22:36:43 CEST] <BtbN> no, nvenc just uses a different pix_fmt [22:36:46 CEST] <philipl> if nvenc isn't looking at the flipped data[1] and data[2] [22:36:47 CEST] <BtbN> internally [22:36:57 CEST] <BtbN> nvenc expects the planes in order Y, V and U [22:37:01 CEST] <BtbN> ffmpeg in Y, U and V [22:37:06 CEST] <philipl> yes... [22:37:29 CEST] <BtbN> and as nvenc only looks at the Y pointer, and goes from there, you can just swap the U and V pointers in ffmpeg, and you're good to go [22:37:46 CEST] <philipl> This is the part that still confuses me. [22:37:51 CEST] <philipl> When is the data actually rearranged? [22:38:03 CEST] <BtbN> never [22:38:11 CEST] <BtbN> it's always written to the place nvenc expects [22:38:17 CEST] <BtbN> ffmpeg uses 3 seperate pointers, one per plane [22:38:23 CEST] <BtbN> nvenc uses one for all 3 [22:38:30 CEST] <BtbN> which is why you can do that in the first place [22:38:46 CEST] <philipl> Ok. Ok. [22:38:55 CEST] <philipl> So, get_buffer allocates a single contiguous region. [22:39:05 CEST] <philipl> We transfer the data plane by plane [22:39:22 CEST] <philipl> so at transfer time, they are written in I420 order but the pointers are assigned as YUV420 [22:39:28 CEST] <philipl> and nvenc uses the contiguous buffer [22:39:31 CEST] <philipl> Ok. I get that. [22:40:05 CEST] <BtbN> You know what would be fun? replacing the cuMemAlloc with cuMemAllocManaged [22:40:23 CEST] <BtbN> hwupload/download would then be a matter of doing nothing [22:40:55 CEST] <BtbN> or rather, in-place converting a frame [22:42:57 CEST] <philipl> wee [22:43:00 CEST] <philipl> yeah [22:44:13 CEST] <philipl> Probably limits applicable hardware [22:45:38 CEST] <philipl> Assuming we start with a cuda allocated frame, it would be transparent download and upload. We can't adopt system memory, though. [22:47:04 CEST] <philipl> Actually - don't you mean cuMemAllocHost? [22:47:13 CEST] <philipl> cuMemAllocManaged is not transparent to regular CPU code. [22:50:13 CEST] <BtbN> no, cuMemAllocHost always allocated Host-Memory, that is then made accessible to the device, but keeps residing in host memory [22:50:14 CEST] <BtbN> -> slow [22:50:34 CEST] <philipl> How do you ensure cuMemAllocManaged memory is migrated to the host for sw access? [22:50:42 CEST] <BtbN> it is automatically [22:50:50 CEST] <philipl> It gets page-faulted in? [22:51:02 CEST] <BtbN> the driver migrates it to the device on access there, and other way around when accesses on the system [22:51:21 CEST] <BtbN> you can also give it a bunch of hints how to do the migration [22:51:32 CEST] <BtbN> if it should just leave it on the device and do DMA, or actually copy it over [22:51:43 CEST] <philipl> Ok. I didn't see a clear statement in the doc that it was directly usable as a regular memory pointer [22:51:55 CEST] <BtbN> that's the whole point with the unified memory stuff [22:52:06 CEST] <BtbN> https://docs.nvidia.com/cuda/cuda-driver-api/group__CUDA__UNIFIED.html#grou… [22:52:43 CEST] <philipl> I'll take your word for it. [22:53:20 CEST] <philipl> Docs don't link managed with unified [22:53:30 CEST] <philipl> but I can easily believe you, and obviously if it works, it works. [22:55:07 CEST] <BtbN> it's kind of the entire point of that function [22:57:46 CEST] <philipl> I buy it. [00:00:00 CEST] --- Thu May 10 2018

1 0

ffmpeg.log.20180509
by burek 10 May '18

10 May '18

[00:00:11 CEST] <bencc1> I don't have a binary for ubuntu [00:00:20 CEST] <bencc1> I'm usually using the official release [00:01:45 CEST] <tuna_> BtbN: Do any of my configs look in correct?? https://pastebin.com/wP306TvJ [00:02:03 CEST] <BtbN> bencc1, there are plenty of static binaries to get easily [00:04:20 CEST] <BtbN> sw_pix_fmt is missing. [00:04:49 CEST] <BtbN> With how you're using this, copying from your array, you might as well just actually use a hw_frames_ctx to allocate the frames for you [00:06:30 CEST] <tuna_> Line 37 in the pastebin: c->sw_pix_fmt = AV_PIX_FMT_0BGR32; [00:06:58 CEST] <tuna_> allocate the input frame? [00:07:12 CEST] <tuna_> My input is an existing OGL texture [00:07:16 CEST] <BtbN> That's not on the frame... [00:07:28 CEST] <BtbN> But you are copying data into the frame from it [00:07:49 CEST] <BtbN> so might as well save you some work and use what a hw_frames_ctx is intended for, allocating frames [00:08:24 CEST] <tuna_> Ok, what are the requirements for that to work? [00:08:42 CEST] <tuna_> "Thats not on the frame..." ?? [00:08:47 CEST] <tuna_> The sw_pix_fmt? [02:10:26 CEST] <User____> Hello! Could anybody please help to investigate, what's going on? I have 52 minutes video, and try to insert intro. After that video becomes 130 hours long, which is wrong, but the size is same (video + intro). Any ideas where to start with? [05:58:24 CEST] <AppleTor> ffmpeg can work with proxy, i wonder if there any paramater to make it work with vpn [05:59:10 CEST] <AppleTor> so what i want is only ffmpeg use vpn, not the whole system [09:26:01 CEST] <wfbarksdale> wfbarksdale [12:42:09 CEST] <dimi_> Hi! Can somebody explain what bzlib and zlib used for in ffmpeg? [12:47:29 CEST] <BtbN> Well, given that compressing and decompressing is all they do: compressing and decompressing stuff [12:58:03 CEST] <dimi_> BtbN, sure, but what formats/codecs are relying on those libs? [12:58:46 CEST] <BtbN> grep zlib */*.c [12:59:23 CEST] <BtbN> or even just grep zlib configure [13:08:50 CEST] <furq> zlib is just used for png afaik [13:09:19 CEST] <BtbN> a whole bunch of filters and formats include it [13:09:38 CEST] <BtbN> *codecs and formats [13:09:44 CEST] <BtbN> not a single filter in fact [13:09:45 CEST] <furq> oh so they do [13:10:04 CEST] <BtbN> for http it's pretty obvious what it's used for [13:10:19 CEST] <furq> apparently nothing depends on bzlib but it's "suggested" for the matroska demuxer [13:10:27 CEST] <furq> i'm not entirely sure what for [13:10:45 CEST] <BtbN> matroska includes bzlib.h at least [13:11:10 CEST] <furq> zlib is suggested for a bunch of stuff but it's a hard dependency for some obscure codecs [13:11:17 CEST] <furq> and png obviously [13:17:12 CEST] <dimi_> thanks. i am considering building without zlib and bzlib for audio applications, so perhaps those obscure codecs aren't relevant for me [13:18:05 CEST] <durandal_1707> png is not obsure codec [13:19:01 CEST] <dimi_> haha sure, sorry for that [13:55:51 CEST] <mort> Is the only way to change the bitrate of an encoder just closing the encoder and opening a new one with a different bitrate setting? [13:56:45 CEST] <mort> (using the C api, not the CLI) [14:07:59 CEST] <BtbN> mort, a lot of encoders support changing some parameters on the fly [14:08:06 CEST] <BtbN> bitrate, dar, and some other things [14:13:28 CEST] <mort> BtbN: how would I do that? I'm having a hard time finding it in the docs or through google [14:13:42 CEST] <mort> I assume it's not as simple as just changing the AVCodecContext.bit_rate variable? [14:13:48 CEST] <BtbN> it should be [14:13:54 CEST] <mort> oh, neat [14:13:58 CEST] <BtbN> if the encoder cares is up to the encoder though [14:14:12 CEST] <BtbN> I only know libx264 and since recently nvenc look at it [14:14:27 CEST] <mort> is there a way to check? I'm using the v4l2m2m encoder [14:14:32 CEST] <BtbN> read its code [15:18:06 CEST] <th3_v0ice> mort: I dont think you could just do that without reconfiguring the encoder there is a method in libx264 that does just that. At least as far as I tried I needed to reconfigure encoder every time I changed the bitrate. Even after that, bitrate was not changing rapidly, instead it was more progressing to the given value. Have in mind that I was trying to do this last year, so maybe some things [15:18:06 CEST] <th3_v0ice> have changed :) [16:07:17 CEST] <tuna> BtbN: Are you around?...I think I found the source of my invalid value [16:07:31 CEST] <tuna> Line 67 of imgutils [16:07:37 CEST] <tuna> imgutils.c [16:08:56 CEST] <tuna> Well, maybe not..... [16:19:50 CEST] <tuna> BtbN: You said to use hwframe_context since I am copying from texture to cuda buffer...but it says "Pixel format 'rgb0' is not supported when I add in an init call for my hwframe ctx [16:51:33 CEST] <SirCmpwn> I'm having a weird issue with the ffmpeg command [16:51:44 CEST] <SirCmpwn> I'm calling it from another process (not a shell) and sending it SIGINT when I want it to stop [16:51:49 CEST] <SirCmpwn> but it doesn't clean up after itself when I do [16:51:56 CEST] <SirCmpwn> it just dies and leaves the video incomplete [16:52:40 CEST] <kepstin> well, it should exit and close the incomplete video file (writing indexes, etc. if needed) [16:52:49 CEST] <kepstin> but yes, leaving an incomplete file is the expected behaviour there [16:53:03 CEST] <SirCmpwn> this is an mp4 file and it doesn't end up with a moov atom [16:53:23 CEST] <SirCmpwn> if I run ffmpeg at my shell instead of from my program, it cleans up properly when I ^c it [16:53:59 CEST] <kepstin> that is a bit unexpected, yeah. are you able to see ffmpeg's output when running it from your program? [16:54:15 CEST] <kepstin> (console output) [16:54:15 CEST] <SirCmpwn> yeah, but none of the "we're cleaning up now" output I would expect shows up [16:54:22 CEST] <SirCmpwn> would you like to see the output? [16:54:30 CEST] <kepstin> yes, please. and what's the return code of the process? [16:54:34 CEST] <SirCmpwn> hold please [16:58:48 CEST] <SirCmpwn> https://sr.ht/HsAK.txt [16:58:50 CEST] <SirCmpwn> kepstin: ^ [17:03:43 CEST] <kepstin> right, on a normal exit by signal, ffmpeg should be printing "Exiting normally, received signal 2.", and the return code should be 255 [17:03:56 CEST] <SirCmpwn> I have verified via strace that it actually gets SIGINT [17:04:31 CEST] <SpeakerToMeat> If whoever(s) worked on the ffmpeg frame rate conversion/blending algorithms are here, you people are gods and I owe you a beer [17:06:02 CEST] <kepstin> SirCmpwn: with libx264, ffmpeg can take a while to finish flushing the encoder and exiting, are you sure there's not something else happening to it first? [17:06:06 CEST] <durandal_1707> SpeakerToMeat: what are you talking about? [17:06:16 CEST] <SirCmpwn> kepstin: I wait on it after I signal, so [17:06:33 CEST] <kepstin> SirCmpwn: like, if your program is reading from ffmpeg stdout, make sure you continue to do so until the process exits. [17:06:39 CEST] <SirCmpwn> aye [17:06:51 CEST] <SirCmpwn> I don't actually read from stdout, I dup2 it onto my stdout [17:06:58 CEST] <kepstin> SirCmpwn: other than that, I'm at a loss, you might have to poke around with a debugger :/ [17:07:02 CEST] <SirCmpwn> algith [17:07:03 CEST] <SirCmpwn> alright* [17:07:15 CEST] <kepstin> i dunno if anyone else has an idea. [17:09:37 CEST] <SirCmpwn> wrote q to stdin instead of signalling [17:09:39 CEST] <SirCmpwn> works [17:09:41 CEST] <SirCmpwn> ¯\_(Ä)_/¯ [17:30:12 CEST] <zevarito> I am decoding opus and then encoding aac, before encoding I am using avresample_convert_frame to resample format, but I am not able to output the audio without a minimal distortion, Ive tried any idea that came to my mind, any cloud where I should dig next? [18:10:11 CEST] <tuna> So to be able to debug my issue with using nvenc I want to build ffmpeg so I can step into the call that is erroring out...but I get an error when doing the ./configure [18:10:42 CEST] <tuna> its the cl is unable to create an executable file...c compiler test failed error...I have tried all the "fixes" in the docs and nothing change [18:11:02 CEST] <tuna> Using VS 2013 [18:27:10 CEST] <BtbN> I even told you what you were doing wrong yesterday. [18:27:30 CEST] <BtbN> Hardware frames always have the pix_fmt of the hardware type they represent [18:27:40 CEST] <tuna> Yes, and I fixed that [18:27:56 CEST] <BtbN> And the sw_pix_fmt needs to be the actual underlying pix_fmt [18:28:11 CEST] <tuna> It made my assertion error go away, but now I get a "invalid value" error [18:28:15 CEST] <tuna> I also fixed that [18:28:23 CEST] <tuna> (the sw_pix_fmt) [18:28:56 CEST] <BtbN> And since OpenGL does not seem to give you something ffmpeg understands, you might as well use the hw_frames_ctx in its intended was, as you have to copy the data anyway [18:30:43 CEST] <PureTryOut[m]> hey guys. I'm trying to use a file on a ssh share (so an sftp connection) as input, which from what I understand ffmpeg should support, but ffmpeg just segfaults. I don't see any useful error messages when running with `-v debug` [18:31:03 CEST] <tuna> Yea, I would do that...but it gives me a "Pixel format 'rgb0' is not supported" when I call init on the hw frame [18:31:20 CEST] <BtbN> oh yes, it indeed only supports YUV [18:31:21 CEST] <tuna> frameCtxPtr->sw_format = AV_PIX_FMT_0BGR32; frameCtxPtr->format = AV_PIX_FMT_CUDA; [18:31:37 CEST] <BtbN> RGB would be trivial to add though [18:32:09 CEST] <tuna> And that is the issue, OpenGL is RGB...and if I cannot use RBG input then I need to use cuda as input because Nvenc CAN handle rgb as input [18:32:21 CEST] <BtbN> you can, nvenc support it just fine [18:32:27 CEST] <tuna> exactly [18:32:28 CEST] <BtbN> just cannot use a hwframes_ctx [18:32:34 CEST] <tuna> exactly [18:32:36 CEST] <BtbN> and need to do what you are already doing [18:32:45 CEST] <tuna> yes [18:33:22 CEST] <tuna> Since I am getting invalid value, and nothing jumped out as wrong yesterday to you...I gotta figure out how to see into ffmpeg [18:33:38 CEST] <BtbN> invalid value on what call? [18:36:38 CEST] <tuna> avcodec_Send_frame [18:38:24 CEST] <tuna> (pastebin from yesterday for reference)https://pastebin.com/wP306TvJ [18:57:17 CEST] <BtbN> you never check if avcodec_open succeeds [18:59:25 CEST] <tuna> I do all the checks for all the calls, just didnt paste it [18:59:38 CEST] <tuna> Everything up to that point passes the checks [18:59:52 CEST] <tuna> that point being the erroneous call [19:00:08 CEST] <BtbN> you'll have to find what line gives you the error then. But usually it always prints something if it returns an error [19:02:06 CEST] <BtbN> the only EINVAL return that doesn't print something I find is if the cuda_ctx is not passed [19:02:33 CEST] <BtbN> do you set the device_ctx on your frames_ctx? [19:02:48 CEST] <BtbN> cause that's where it gets it from [19:04:03 CEST] <BtbN> device_ref and device_ctx need to be populated [19:05:12 CEST] <SirCmpwn> having an issue using the dash output [19:05:52 CEST] <SirCmpwn> I can stream a local (mp4) file with -re and it works as expected, and the video/mp4 <Representation> tag has codec="avc1.42c028" [19:06:13 CEST] <SirCmpwn> but when I stream from x11grab, I get codec="avc1.42c01f", which dash.js and/or chromium do not like [19:08:40 CEST] <SirCmpwn> I'm using -vcodec libx264 -vprofile baseline -pix_fmt yuv420p [19:10:48 CEST] <BtbN> a lot of decoders do not support baseline [19:10:50 CEST] <BtbN> use main or high. [19:11:14 CEST] <BtbN> also, vcodec/vprofile are deprecated, use codec:v/profile:v [19:12:10 CEST] <SirCmpwn> I'm using the baseline profile for both scenarios [19:12:16 CEST] <SirCmpwn> and it works when I'm streaming a file [19:12:21 CEST] <SirCmpwn> browsers tend to only support baseline afaik [19:12:35 CEST] <SirCmpwn> or at least baseline is the only consistently supported profile among browsers [19:13:08 CEST] <klaxa> that may be true for mobile browsers and in 2010 [19:13:18 CEST] <SirCmpwn> well, I'll give main a shot [19:13:54 CEST] <klaxa> also, i used your c bloom filter once, thank you very much :) [19:13:58 CEST] <SirCmpwn> no problem :) [19:14:45 CEST] <SirCmpwn> I still get the wrong codec with -profile:v main (01f) [19:14:52 CEST] <SirCmpwn> but something else came up, I'll come back later to do more troubleshooting [19:17:09 CEST] <tuna> BtbN: Docs for device_ctx say "Set by libavutil in av_hwframe_ctx_init()." and device_ref, although not set by me, is set to something at run time. When I do set it to the AVBufferRef for the device ctx it still returns same error [19:18:40 CEST] <BtbN> device_ctx _and_ device_ref. [19:18:49 CEST] <BtbN> You're not calling init, so you need to set it yourself [19:19:12 CEST] <BtbN> the device_ctx is not the ref, but the actual ctx [19:20:49 CEST] <jkqxz> SirCmpwn: The three bytes there are profile_idc, the constraint flags, and level_idc respectively. The difference between 42c028 and 42c01f is only the level - 4 vs. 3.1. [19:20:56 CEST] <tuna> BtbN: This is true, but same error still with both populated [19:21:08 CEST] <jkqxz> SirCmpwn: Lower levels are strictly easier to decode, so the error must be somewhere else. [19:21:10 CEST] <tuna> frameCtxPtr->device_ref = m_avBufferRefDevice; frameCtxPtr->device_ctx = (AVHWDeviceContext*)m_avBufferRefDevice->data; [19:21:29 CEST] <BtbN> weird. You'll probably have to ask a Debugger [19:23:44 CEST] <BtbN> debugging ffmpeg on msvc might be annoying though [20:04:34 CEST] <tuxuser> Hi, there is a problem for me with AAC decoding, when samples are raw and have no ADTS header prepended on the input data - Basically it cannot estimate a single sample length from the looks of it, even if given the known encoding parameters. [20:04:34 CEST] <tuxuser> Command: $ ffmpeg -loglevel debug -f aac -ac 2 -sample_fmt fltp -i no_adts_header_per_sample.aac out.mp3 [20:04:34 CEST] <tuxuser> log: https://pastebin.com/hwb8xVLy - Sample data: http://libxenon.org/input.audio.no_adts_header_per_sample.aac [20:07:51 CEST] <SirCmpwn> jkqxz: is there a way to specify the level? [20:09:52 CEST] <saml> is it better to encode to .mp4 then generate .ts chunks (hls)? or encode to .ts chunks then concat those to a single .mp4? in the end, I need both a single .mp4 and .ts chunks [20:10:35 CEST] <ChocolateArmpits> saml, you can create multiple outputs https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs [20:11:17 CEST] <ChocolateArmpits> the "tee pseudo muxer" specifically details a way to reuse same encoded content for different output formats [20:11:23 CEST] <ChocolateArmpits> section* [20:11:38 CEST] <saml> ah thank you [20:13:24 CEST] <SirCmpwn> jkqxz: found it, confirmed level isn't the issue [20:56:35 CEST] <SirCmpwn> I got it :D [20:56:42 CEST] <SirCmpwn> old ffmpeg version on debian stretch [20:59:07 CEST] <zerodefect> I'm overlaying a small image on an AVFrame which 720x576 using the C API (avfilter graph with overlay). When I overlay the image, the image is stretched to the full resolution of the main video. Initially, I suspected it was something to do with sample aspect ratio, but I can't see anything in the source code for overlay filter which takes aspect ratio into consideration. [21:00:02 CEST] <durandal_1707> zerodefect: size of overlay is? [21:00:41 CEST] <zerodefect> 253x253 [21:04:19 CEST] <durandal_1707> need source code to see [21:07:17 CEST] <zerodefect> Ok. I think I'll write a sample app. Will be easier to share. [21:28:32 CEST] <zerodefect> @durandal_1707, do you mind if I give you a shout once I've knocked some sample code together? [21:28:56 CEST] <zerodefect> I'll upload it to github so it can be pulled down [21:29:14 CEST] <durandal_1707> ok [21:30:08 CEST] <zerodefect> Thanks. [22:52:53 CEST] <Purebes> Hello, I'm able to play a WDM dshow filter as long as I use the correct settings in the dialog popped up by -show_video_device_dialog, but I need to be able to generate those settings on the fly without user interaction, is this possible? [22:53:48 CEST] <exastiken> Hi, how do I transcode YUV with HEVC to *.265 file extension? [22:56:41 CEST] <JEEB> build with libx265 and encode with it [22:56:56 CEST] <JEEB> raw YCbCr input might need you to specify the input size [23:11:02 CEST] <tuxuser> Follow-up info: When manually prepending the ADTS header to every sample, ffmpeg recognizes it fine: https://pastebin.com/nPdRekCZ [23:11:32 CEST] <tuxuser> what can I do to make ffmpeg understand the headerless data tho? Is -flags +global_header needed? [23:14:04 CEST] <tuxuser> without adts-header per sample: After avformat_find_stream_info() pos: 374 bytes read:65696 seeks:4 frames:1 --- with adts-header per sample: After avformat_find_stream_info() pos: 21290 bytes read:65696 seeks:4 frames:50 [23:17:05 CEST] <tuxuser> I actually do need the reverse of "bsf:a aac_adtstoasc" ? [23:33:48 CEST] <Purebes> Can anyone help me figure out the correct syntax for playing both audio and video from a directshow WMD capture filter? It has a video and audio pin, but it only plays the video and says it can't find the audio https://pastebin.com/sci7kuLT [23:41:34 CEST] <tuxuser> try to change "-i video="Blackmagic WDM Capture":audio="Blackmagic WDM Capture"" to just "-i "Blackmagic WDM Capture"" [23:42:33 CEST] <tuxuser> nvm, whats the output of: "ffmpeg -list_devices true -f dshow -i dummy" ? [23:43:56 CEST] <Purebes> https://pastebin.com/JPgHywPg [23:45:50 CEST] <Purebes> There are the "Decklink Video Capture" and "Decklink Audio Capture" which used to work, but apparently have become deprecated and I haven't been able to get them to work (according to the support team of the input card, I should be using the WDM one) [23:45:51 CEST] <tuxuser> ok, what happens if you just pass -i video="Blackmagic WDM Capture" [23:46:00 CEST] <tuna> Any way I could get debug files to run with visual studio for FFMPEG so I can debug a call....me trying to build ffmpeg is not working out well [23:46:25 CEST] <Purebes> Video plays but without any sound [23:48:37 CEST] <Purebes> I assume I should be using `audio_pin_name` for this somehow but none of my attempts seem to be correct [23:49:24 CEST] <Mista_D> trying to pass ">>logfile 2>&1" as variable and I get this in bash >>> ./ffmpeg -i .... '>>logfile' '2>&1' failing to recognize, Any advise please? [23:54:50 CEST] <tuxuser> Purebes: https://www.ffmpeg.org/ffmpeg-devices.html#decklink-1 this looks like the prefered way [23:58:08 CEST] <Purebes> tuxuser: Appreciate the link, however I've never been able to get any of those commands to work [23:58:39 CEST] <Purebes> I think they may require a special build of ffmpeg [23:58:46 CEST] <tuxuser> Mista_D: can you post the full command, no additional parentheses ? [23:58:53 CEST] <tuxuser> Purebes: indeed, yea [23:59:25 CEST] <Purebes> yeah, unfortunately that's complicated for me, because I'm building a plugin for a nwjs application that routes thru libmpv [23:59:37 CEST] <Purebes> which I think includes some version of ffmpeg [00:00:00 CEST] --- Thu May 10 2018

1 0

ffmpeg-devel.log.20180508
by burek 09 May '18

09 May '18

[00:47:18 CEST] <cone-799> ffmpeg 03Rostislav Pehlivanov 07master:a72d0fb97336: mdct15: simplify the fft15 x86 SIMD [00:47:19 CEST] <cone-799> ffmpeg 03Rostislav Pehlivanov 07master:29eb1c51d735: mdct15: simplify x86 exptab permutation [01:23:12 CEST] <JEEB> hah, so we really hit the case where zvbi was doing something wrong :( [01:31:23 CEST] <tmm1> i guess so, looks like it happens even in bitmap mode [01:34:11 CEST] <kierank> ask funman about this problem [01:34:19 CEST] <kierank> we had it as well, iirc an ffmpeg implementation problem [01:35:17 CEST] <kierank> and vlc uses libzvbi [01:37:52 CEST] <kierank> tmm1: vlc looks fine with that sample [01:38:56 CEST] <kierank> depending on where you seek it looks wrong actually [01:39:23 CEST] <kierank> so maybe you found a rare zvbi bug [01:41:03 CEST] <tmm1> i was just playing normally from start [01:42:22 CEST] <tmm1> vlc here has the same issue [01:42:54 CEST] <tmm1> there are two spots in the video where top line doesn't disappear while the bottom line changes [03:38:23 CEST] <atomnuker> can I use a prefix without an underscore for the lavu fft move? [03:38:35 CEST] <atomnuker> as in avfft_init() [03:39:02 CEST] <atomnuker> since av_fft_ is already taken by the fft in lavc [03:55:29 CEST] <jamrial> no, avutil_fft() maybe [03:56:27 CEST] <jamrial> although that's currently used only for informative avutil related functions [03:57:20 CEST] <jamrial> didn't we move functions between libs at some point, retaining the namespace? [04:01:14 CEST] <atomnuker> the thing is the functions themselves need to change to accomodate non-ptwo transforms so the arguments change too [04:01:41 CEST] <atomnuker> nevcairiel told me its only possible if the ABI doesn't change [04:02:35 CEST] <atomnuker> btw does msvc support complex.h? [04:03:28 CEST] <atomnuker> seems not, I'll write an emulation layer [04:15:23 CEST] <jamrial> ah, in that case yeah, can't be the same [04:21:41 CEST] <atomnuker> btw just curious, what did we move between libs? [04:34:11 CEST] <jamrial> avframe was one thing, i recall [09:33:01 CEST] Action: JEEB puts his safety glasses back on, gets to looking at how the MPEG-TS demuxer or framework could be made to wait for PCR [10:00:38 CEST] <cone-157> ffmpeg 03Gyan Doshi 07master:0683ad709b0e: avformat/segafilmenc - set keyframe bit correctly [10:29:15 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:f1248b779585: lavfi/nlmeans: random code shuffling to help compiler [10:29:16 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:26f02c51ce97: lavfi/nlmeans: add SIMD-friendly assumptions for compute_safe_ssd_integral_image [10:29:17 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:5ba14f4f1a5e: lavfi/nlmeans: use ptrdiff_t for linesizes [10:29:18 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:5a71bce3713c: lavfi/nlmeans: add AArch64 SIMD for compute_safe_ssd_integral_image [10:29:19 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:f679711c1b51: checkasm: add vf_nlmeans test for ssd_integral_image [10:29:20 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:43d16aef6395: lavfi/nlmeans: make compute_safe_ssd_integral_image_c faster [10:29:21 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:667503ef6879: lavfi/nlmeans: switch from double to float [10:29:22 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:34e1e53e2885: lavfi/nlmeans: move final weighted averaging out of nlmeans_plane [10:29:23 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:de956198a9ec: lavfi/nlmeans: reorder memory accesses in get_integral_patch_value [10:29:24 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:4278f79ef610: lavfi/nlmeans: use unsigned for the integral patch value [10:29:25 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:e6114d21ac00: lavfi/nlmeans: inline integral patch value function [10:30:13 CEST] <ubitux> durandal_1707: farindk version seems to use a much smaller research window [10:30:24 CEST] <ubitux> assuming it's the range parameter [10:30:47 CEST] <ubitux> try r=3 with ff nlmeans [10:31:01 CEST] <ubitux> it will be much faster that way [10:31:22 CEST] <ubitux> the scale of the strength doesn't look the same too [10:31:56 CEST] <ubitux> it may have an impact [10:33:40 CEST] <ubitux> it seems to have temporal enabled, if you're making comparisons you may want to disable it on his side [10:33:55 CEST] <ubitux> (or add it in ffmpeg) [10:34:16 CEST] <durandal_1707> ubitux: how temporal works? it also searches prev/next frames? [10:34:24 CEST] <ubitux> yeah [10:34:39 CEST] <ubitux> it looks up for blocks not only in the surrounding but also in the previous frames [10:35:12 CEST] <ubitux> (and thus it's making the filter slower) [10:35:29 CEST] <ubitux> it's similar to enlarging the research window [10:35:35 CEST] <ubitux> it has a large impact on performances [10:58:05 CEST] <durandal_1707> ubitux: what you think about fftdnoiz ? [10:58:46 CEST] <ubitux> dunno, does it just blur like dctdnoiz? [11:07:12 CEST] <durandal_1707> ubitux: only if you set very high sigma (and than you can expect worse thing than just blurring), otherwise it reduces noise [11:08:55 CEST] <durandal_1707> also doing only 2d is bad, i already added 3d operation and >16 bit support [11:09:04 CEST] <durandal_1707> * >8 [11:45:09 CEST] <cone-157> ffmpeg 03Martin Vignali 07master:6ebc71847e21: fate/hapenc : remove tests due to inconsistent result [11:53:59 CEST] <ubitux> durandal_1707: what's the 3rd dimension? other frames? [11:54:43 CEST] <ubitux> how slow/fast is it? did you compare the results with other denoisers? there are many relatively advanced denoisers on ipol [12:08:56 CEST] <durandal_1707> ubitux: they are all extremly slow [12:09:27 CEST] <durandal_1707> ubitux: 3d is prev or next or both [12:45:22 CEST] <durandal_1707> imho nlmeans is very strong even at 1 [12:48:18 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:8d6354aa8284: lavfi/nlmeans: use AV_CEIL_RSHIFT instead of deprecated FF_CEIL_RSHIFT [12:48:19 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:1eb4e731fc44: lavfi/swaprect: use AV_CEIL_RSHIFT instead of deprecated FF_CEIL_RSHIFT [12:48:20 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:6876a6336893: lavc/cfhd: use AV_CEIL_RSHIFT instead of deprecated FF_CEIL_RSHIFT [12:48:46 CEST] <ubitux> durandal_1707: even with a small research window? [12:49:30 CEST] <ubitux> if you reduce the research window it will average with less stuff around [12:50:26 CEST] <durandal_1707> yes [12:53:19 CEST] <ubitux> do you have a sample? [12:54:53 CEST] <durandal_1707> not needed, its fine with lower r [12:55:08 CEST] <ubitux> ok :) [12:55:27 CEST] <durandal_1707> perhaps sigma should be scaled with p & r ? [12:55:42 CEST] <ubitux> yeah, see the todo [12:56:10 CEST] <ubitux> iirc that paper section is related to this [12:56:20 CEST] <ubitux> but i haven't bothered looking at it yet [13:09:40 CEST] <durandal_1707> you cant denoise very bad vhs tapes with only spatial filtering [13:11:19 CEST] <ubitux> feel free to add temporal support :) [13:30:31 CEST] <BtbN> Can one entry in APIchanges be used for multiple commits? Adding another one for just that one little change seems overkill. [13:31:53 CEST] <ubitux> assuming you bump only once it should be fine [13:32:28 CEST] <ubitux> the APIchanges entries are associated with a new version + a header (sometimes several?) [13:32:35 CEST] <durandal_1707> anyone have unprocessed noisy clips? [13:32:38 CEST] <BtbN> The second change is a micro bump, first change minor bump [13:32:56 CEST] <nevcairiel> if its somewhat close in time, then it should be fine [13:33:05 CEST] <BtbN> it will be in one batch of patches [13:34:48 CEST] <ubitux> durandal_1707: fate-samples/smjpeg/scenwin.mjpg? [13:34:56 CEST] <durandal_1707> please no [13:35:08 CEST] <ubitux> :D [13:37:44 CEST] <ubitux> if you're looking for picture, i like to test with http://b.pkh.me/p_009.png [13:37:53 CEST] <ubitux> but i guess you want to try the temporal stuff [13:37:58 CEST] <durandal_1707> ubitux: yes [13:38:37 CEST] <durandal_1707> i could experiment with noise filter, but that one does not emulate vhs noise [13:39:07 CEST] <ubitux> i may have shitty anime rip around [13:39:13 CEST] <ubitux> but that's a particular type of content [13:39:33 CEST] <ubitux> i have shitty vhs rip too, but you're going to get more annoyed at the blocking stuff than the noise [15:48:53 CEST] <BtbN> Is Thunderbird just confused or did I actually send that series 5 times? [15:49:26 CEST] <BtbN> seems like it's just Thunderbird [15:49:41 CEST] <JEEB> I only see a set in gmail's mobile interface [15:50:01 CEST] <BtbN> The E-Mails came out of order, and Thunderbird attached the whole thread to every out of order mail it got [15:50:05 CEST] <BtbN> So I had it 5 times [15:50:14 CEST] <BtbN> a restart fixed it [16:27:06 CEST] <BtbN> oh nice, Windows 10 1803 now lets you define the default audio input/output device per application [16:28:05 CEST] <JEEB> nice [16:28:32 CEST] <BtbN> Only in one of their horrible "modern" UI control panel apps though [16:29:09 CEST] <BtbN> It still baffles me how any ui designer can think that it's a good idea to replace a number-input-spinner with a number and up/down buttons on top of it, which inc/dec the number one step per click [16:29:18 CEST] <BtbN> with no other way to input a number in the range from 0 to 100 [17:07:21 CEST] <jamrial> nevcairiel: can you test my patch? msvc has been broken for a couple days now [17:08:44 CEST] <jamrial> maybe we should move the access wrapper from lavf os_support.h to lavu file_open.c and make it public, or at least avpriv [17:15:01 CEST] <nevcairiel> that wouldnt fix anything anyway [17:15:13 CEST] <nevcairiel> it only deals with unicode paths, not the lack of those constants [17:17:43 CEST] <jamrial> the constants can be defined as well [17:18:34 CEST] <nevcairiel> any file access should really use avio, though [17:18:53 CEST] <ubitux> jamrial: should i send a patch to revert the android/perf thing? [17:19:09 CEST] <jamrial> ubitux: why? [17:19:19 CEST] <ubitux> because it's not needed [17:19:24 CEST] <jamrial> oh, you mean my "fix" [17:19:25 CEST] <nevcairiel> in fact, it even uses avio [17:19:25 CEST] <jamrial> sure [17:19:28 CEST] <nevcairiel> except for that one call [17:19:36 CEST] <nevcairiel> so why not add that if its needed [17:19:44 CEST] <jamrial> nevcairiel: mention that to the author in the thread, then [17:19:54 CEST] <jamrial> but until he gets around to do that, we should at least make msvc compile again [17:21:25 CEST] <nevcairiel> in fact [17:21:30 CEST] <nevcairiel> we even have an avio call for that [17:21:40 CEST] <nevcairiel> avio_check(url, AVIO_FLAG_READ) [17:27:10 CEST] <wm4> wtf [17:27:32 CEST] <wm4> does that also open and close a http connection for http protocols [17:27:41 CEST] <nevcairiel> send a patch for that to the ML [17:27:42 CEST] <wm4> what does it do for udp [17:27:52 CEST] <nevcairiel> no clue, i only checked its file implementation [17:28:30 CEST] <nevcairiel> apparently it does simply try to open it w hen there is no dedicated checking function [17:43:56 CEST] <nevcairiel> hrm the .rm demuxer bug is the only one that remains in the latest msvc version, maybe i should look into whats causing that already [17:45:04 CEST] <wm4> wow so libavfilter depends on libavformat [17:45:15 CEST] <nevcairiel> better then re-implementing file access [17:45:21 CEST] <wm4> fopen is hard [17:45:22 CEST] <nevcairiel> also thats not the first [17:45:31 CEST] <kierank> wm4: been like that for a while, no? [17:45:34 CEST] <nevcairiel> the movie src filter did that since forever [17:45:41 CEST] <wm4> kierank: apparently [17:45:43 CEST] <jamrial> wm4: there are like ten filters using lavf stuff [17:46:05 CEST] <wm4> shitty mudball of bloat [17:46:12 CEST] <jamrial> movie/amovie, for example [17:49:49 CEST] <durandal_1707> wm4: what you said? [18:03:11 CEST] <cone-517> ffmpeg 03Hendrik Leppkes 07master:8007a8636393: lavfi/vf_srcnn: use avio_check instead of access [18:07:48 CEST] <durandal_1707> ubitux: i cant get nlmeans to be stable, if i change research window i need to change patch size and sigma to get good results, otherwise strange artifacts appear [18:11:43 CEST] <ubitux> yeah, but i think that's how the algorithm is supposed to be designed [18:12:05 CEST] <durandal_1707> this usually happens with very strong noise, very noiceable ringing artifacts [18:18:35 CEST] <nevcairiel> how does one pass an absolute windows paths to lavfi parameters (it contains a colon) ? no amount of quoting made it stop parsing it, and i dont know if there is other escaping magic [18:18:50 CEST] <nevcairiel> (from cli) [18:19:00 CEST] <durandal_1707> \\ ? [18:22:07 CEST] <nevcairiel> apparently quoting and escaping works [18:22:23 CEST] <nevcairiel> only one of thsoe doesnt [18:23:09 CEST] <nevcairiel> probably one for the shell and one for ffmpeg? [18:32:58 CEST] <philipl> BtbN, wm4: I took a quick look at the videotoolbox code and I think it just wastes memory in the way that BtbN is trying to avoid. [18:33:34 CEST] <philipl> It uses the hwaccel alloc_frame callback to allocate frames itself, and not get them from the hw_frame_ctx's pool, but the pool is just a normal pool. [18:33:50 CEST] <philipl> Maybe that technique would be sufficient here? [18:33:59 CEST] <BtbN> philipl, the videoboolbox hwframesctx does not have an internal AVBufferPool [18:34:01 CEST] <BtbN> but it uses it [18:34:08 CEST] <BtbN> so it relies on the pool being supplied externally [18:36:16 CEST] <wm4> wut [18:36:28 CEST] <wm4> philipl: what memory does it waste? [18:36:31 CEST] <philipl> BtbN: does it use it? It does alloc_frame and then those can work with the hw_frames_ctx but it doesn't use the ctx pool [18:36:47 CEST] <BtbN> the hwframes_ctx uses it [18:36:54 CEST] <philipl> wm4: Sorry, it doesn't, because it doesn't request anything from the pool. [18:37:29 CEST] <wm4> videotoolbox literally just uses the hwframes stuff to make it play nicely with the libavcodec infrastructure [18:37:46 CEST] <philipl> I think this works because you give videotoolbox the buffer to fill, and so alloc_frame is fine. [18:37:52 CEST] <wm4> it could just return blank AVFrames with only the videotoolbox hw reference (like it used to) [18:38:02 CEST] <philipl> for nvdec, we can't do that, so the situation is different. [18:38:10 CEST] <wm4> well then I don't get it [18:38:26 CEST] <philipl> Don't get what? This is to your question of why can't it be done the way videotoolbox does it. [18:39:45 CEST] <BtbN> It can't be done the videotoolbox way. But it can be done a way that doesn't need any API changes [18:40:49 CEST] <philipl> BtbN: as in what your patch series does? [18:41:15 CEST] <BtbN> Yes. The hwframesctx stuff will use an externally supplied BufferPool, if it's set before init is called [18:42:11 CEST] <philipl> BtbN: Sorry - losing track. Your patch series has the flag. You want to use a dummy buffer pool instead? [18:42:25 CEST] <BtbN> so I'll just pass a custom buffer pool that... does nothing [18:42:50 CEST] <philipl> OK. We discussed that yesterday. :-) [18:43:05 CEST] <BtbN> I just missed you can pass in an external buffer pool [18:43:38 CEST] <philipl> Alright. And if an API user passes their own hw_frames_ctx with a real pool, it wastes memory but works correctly. [18:44:31 CEST] <BtbN> yeah [18:44:38 CEST] <philipl> mpv only passes a device_ctx, so that's fine. [18:45:51 CEST] <BtbN> What I'm a bit confused about is: Do I need to free the buffer pool myself, or does the hwframes ctx take ownership? [18:46:13 CEST] <wm4> why does it need a buffer pool? [18:46:21 CEST] <BtbN> To allocate the frames?! [18:46:37 CEST] <wm4> but the buffer pool contains dummy objects? [18:46:40 CEST] <wm4> so it allocates nothing [18:46:46 CEST] <BtbN> ... [18:46:53 CEST] <wm4> indeed [18:46:55 CEST] <BtbN> No, a normal pool does not allocate dummies [18:47:09 CEST] <BtbN> I want it to allocate dummies, so it doesn't waste memory. That's the whole point. [18:47:32 CEST] <wm4> ????? [18:47:41 CEST] <wm4> why allocate dummies if you could just allocate nothing [18:47:50 CEST] <wm4> that's why I mentioned videotoolbox [18:48:06 CEST] <BtbN> I have no idea what you're confused about. [18:48:18 CEST] <BtbN> videotoolbox frames work entirely diffrent [18:49:26 CEST] <philipl> videotoolbox can allocate frames on demand. nvdec uses a fixed pool so it has to be modelled. [18:49:45 CEST] <BtbN> cuda frames just normally contain actual video memory [18:49:50 CEST] <BtbN> not just a mapping or handle [18:50:24 CEST] <wm4> so it's literally only about passing through initial_pool_size in a way that makes the hwaccel framework happy? or what [18:50:40 CEST] <philipl> BtbN: as for freeing - the code says it only frees an internal pool, not an external one. [18:50:56 CEST] <philipl> And I remember fiddling with this when I did my cuda array experiment way back when. [18:51:01 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/hwcontext.h;h=f5a4… this is weird. It claims "The pool will be freed strictly before this struct's free() callback is invoked." [18:51:14 CEST] <BtbN> But I don't see it ever freeing it [18:51:20 CEST] <philipl> Yeah. Only the internal pool [18:51:28 CEST] <BtbN> So the documentation is wrong? [18:51:37 CEST] <BtbN> So I guess I just add a free callback, and uninit my pool there [18:51:50 CEST] <philipl> I guess. Presumably you can't make it free it now without breaking de-facto API semantics. [18:52:07 CEST] <BtbN> well, the free callback seems to exist for that purpose [18:55:54 CEST] <philipl> yeah [19:00:48 CEST] <philipl> BtbN: I'll wait for new patch set. [19:16:17 CEST] <durandal_1707> ubitux: are you gonna add >8 bit depth support to nlmeans? do you know what in code assumes 8 bit depth? [19:24:27 CEST] <BtbN> philipl, https://github.com/BtbN/FFmpeg/commit/72e43650b67aef40bec6432b8416c17e813fa… [19:27:09 CEST] <nevcairiel> BtbN: frames basically need to be able to stay alive even after the decoder is closed or re-created for the full AVFrame lifetime semantics to be valid, does this fullfill this? [19:27:22 CEST] <BtbN> yes [19:27:32 CEST] <BtbN> That's the point of all the buffer_refs it carries around [19:27:58 CEST] <BtbN> it keeps a ref for the cuvid picture index, so it doesn't get re-used, and it carries a ref to the decoder itself, so it doesn't get freed [19:42:39 CEST] <llogan> durandal_1707: i have some noisy VHS samples (as DV) if you need any. [19:47:05 CEST] <durandal_1707> llogan: first send me single representative frame, so you do not need to pointlessly upload one [19:50:30 CEST] <ubitux> durandal_1707: i didn't plan anything on nlmeans so far, but 10-bit might be tricky [19:50:44 CEST] <ubitux> because accumulated diff is stored on u32 [19:50:51 CEST] <llogan> durandal_1707: ok. i will try to get one to you within an hour unless work gets in way [19:50:56 CEST] <ubitux> on large image, i believe it can already be an issue [19:51:20 CEST] <ubitux> you can switch to u64 but then you have to rewrite some code (+asm) [19:51:37 CEST] <ubitux> also, it will hurt speed so you want to keep the u32 version for when appropriate [20:26:11 CEST] <llogan> durandal_1707: found them. do you want a typical VHS video or one with extra noise? [20:44:50 CEST] <llogan> durandal_1707: https://0x0.st/sjAi.png [20:45:01 CEST] <llogan> found a good one for you [20:57:31 CEST] <durandal_1707> llogan: upload video with few frames somewhere, do not transcode [21:03:58 CEST] <durandal_1707> ubitux: well, one could write .c file as template? [21:04:45 CEST] <ubitux> yeah i don't think it's impossible at all [21:06:16 CEST] <ubitux> i wouldn't say it's the priority for the filter, but you can do that ofc [21:06:33 CEST] <ubitux> x86 SIMD, temporal support, and smart parameters would be nice i think [21:13:01 CEST] <durandal_1707> ubitux: what about bm3d filter? [21:16:46 CEST] <llogan> durandal_1707: https://0x0.st/sjAZ.dv [21:18:53 CEST] <philipl> BtbN: Change looks good to me. [21:19:31 CEST] <philipl> Assuming API users are required to manage decoders through buffer refs and not direct allocation... [21:20:36 CEST] <BtbN> hm? [21:20:49 CEST] <BtbN> that's how frames work? [21:20:58 CEST] <philipl> I meant the decoder instance itself. [21:21:23 CEST] <BtbN> not sure what you mean [21:21:26 CEST] <philipl> You used a ref to keep the decoder alive as long as the frame is alive. [21:22:24 CEST] <BtbN> yes, frames carry a bunch of refs around anyway [21:22:56 CEST] <durandal_1707> llogan: thanks [21:25:31 CEST] <philipl> BtbN: yeah. no concern - just needed to get this straight in my head [21:37:36 CEST] <durandal_1707> ubitux: can you denoise this: https://0x0.st/sjAm.nut without blurring? [21:52:03 CEST] <ubitux> durandal_1707: that's subjective but nlmeans=s=6:r=5 doesn't look that bad [21:53:16 CEST] <ubitux> nice sample btw [21:53:20 CEST] <ubitux> (source?) [22:06:53 CEST] <durandal11707> ubitux: from doom9, its raw float gray, but i converted it with patch to libavutil and geq to gray8 [22:08:06 CEST] <durandal11707> thing is, i want to get background to be solid gray as possible with nlmeans [22:09:01 CEST] <durandal11707> fftdnoiz have no such problems, but its algo is >20 years old [22:11:50 CEST] <durandal11707> ubitux: https://forum.doom9.org/showthread.php?t=174249&page=2 [22:12:40 CEST] <durandal11707> their nlmeans/bm3d can do it [22:16:56 CEST] <durandal11707> perhaps adding temporal part will make this possible? [22:20:36 CEST] <ubitux> yeah temporal may help here [22:22:25 CEST] <durandal11707> ubitux: but even only 2d fftdnoiz can do it 95% [22:29:23 CEST] <ubitux> i don't know, KNLMeansCL(clip, 6, 32, 3, 4.0) [22:29:28 CEST] <ubitux> what are the params here? [22:29:54 CEST] <ubitux> nb frames, research window, patch size, strength? [22:30:49 CEST] <ubitux> we probably want to add temporal support to ff nlmeans so we can actually compare with other implementations [22:30:56 CEST] <ubitux> it seems most of them have it [22:33:29 CEST] <ubitux> 32 for the research windows looks huge though [22:33:37 CEST] <ubitux> it's probably extremelly slow [22:33:45 CEST] <ubitux> especially with 6 frames [22:33:53 CEST] <ubitux> assuming i guessed the parameters right [23:07:42 CEST] <ubitux> durandal11707: i guess i'll try to implement the temporal support [23:20:54 CEST] <durandal11707> ubitux: nlmeans=r=15:s=5 did it [23:21:18 CEST] <ubitux> durandal11707: i'm not used to the new lavfi api; any modern filter i could use for reference caching frames + sending some with delay? [23:22:23 CEST] <ubitux> cool, ok for the settings [23:24:16 CEST] <durandal11707> ubitux: atadenoise, tmix(vf_mix.c) for big temporal radius [23:24:24 CEST] <ubitux> thanks [23:25:06 CEST] <durandal11707> you just keep frames in queue, can be simple array [23:25:32 CEST] <ubitux> yeah i was wondering what was the purpose of this FFBufQueue [23:28:25 CEST] <durandal11707> could also add sad in place of ssd [23:29:11 CEST] <ubitux> yeah, it would prevent some overflow [23:29:22 CEST] <ubitux> but the formula change [23:29:27 CEST] <ubitux> i'm not exactly sure how [23:33:24 CEST] <durandal11707> ? sad just takes absolute differences [23:33:48 CEST] <ubitux> yeah but it has an impact on how you interpret it [23:34:20 CEST] <ubitux> the scaling interpretation is typically different [23:34:28 CEST] <ubitux> the weighting of the patch changes [23:35:03 CEST] <ubitux> the f(x)=x² curve is not the same as f(x)=|x|, so the exponential and stuff change [23:35:11 CEST] <ubitux> i'm not sure you can get the exact same result [23:35:26 CEST] <ubitux> but i'm not a math fluent person [23:35:30 CEST] <ubitux> (far from it) [23:35:52 CEST] <ubitux> so i kept the original algorithm, even though sad was mentioned [23:42:58 CEST] <ubitux> maybe i just need pdiff_scale = 1./h [23:43:04 CEST] <ubitux> instead of 1./h² [23:43:21 CEST] <ubitux> (according to the formula @ http://avisynth.nl/index.php/TNLMeans) [23:53:40 CEST] <klaxa> phew, after some days of reading and thinking and coding, i at least managed to more or less decouple the specific network implementation from the server logic [23:53:59 CEST] <klaxa> still buggy, but first tests work [23:59:56 CEST] <cone-738> ffmpeg 03Michael Niedermayer 07master:5c705134183d: avformat/mxfenc: Correct KAG alignment of preface [23:59:56 CEST] <cone-738> ffmpeg 03Michael Niedermayer 07master:3ba1bbb4f992: avformat/mxfenc: Bump minor versions for S377-1-2009 [23:59:56 CEST] <cone-738> ffmpeg 03Michael Niedermayer 07master:86c92509231f: avformat/mxfenc: Add Product Version, Toolkit version and Platform [23:59:56 CEST] <cone-738> ffmpeg 03Michael Niedermayer 07master:1b6c89ca8db2: avformat/mxfenc: Add object model version [23:59:56 CEST] <cone-738> ffmpeg 03Michael Niedermayer 07master:77cbe698cd91: avformat/mxfenc: Fix stored width [23:59:56 CEST] <cone-738> ffmpeg 03Michael Niedermayer 07master:2bee43b67dc5: avformat/mxfenc: Add vertical subsampling support [23:59:56 CEST] <cone-738> ffmpeg 03Michael Niedermayer 07master:6d0339096e10: avformat/mxfenc: add white/black ref /color range [23:59:57 CEST] <cone-738> ffmpeg 03Michael Niedermayer 07master:1246754c80a4: avformat/mxfenc: Add Padding Bits [23:59:58 CEST] <cone-738> ffmpeg 03Michael Niedermayer 07master:530ac1e50bd7: avformat/mxfenc: Write Audio Ref Level for D10 [23:59:59 CEST] <cone-738> ffmpeg 03Michael Niedermayer 07master:c35ca7e01c88: avformat/mxfenc: Add Stored F2 Offset / Image Start/End Offset for D10 [00:00:00 CEST] --- Wed May 9 2018

1 0

ffmpeg.log.20180508
by burek 09 May '18

09 May '18

[00:00:04 CEST] <Durandal> I just want to do -af "volumedetect" on a file. On linux I would try just forwarding stdout >/dev/null, but I don't know what to do on windows [00:00:06 CEST] <Derisar> kepstin, I've changed the comand, thx [00:00:36 CEST] <kepstin> Durandal: you should be able to redirect output to the special file 'NUL', i think. Also note that if you use "-f null" then you can put anything as the output filename and it'll be ignored. [00:02:01 CEST] <Durandal> so, "ffmpeg -i input.m4a -af "volumedetect" -f null null" ? [00:02:19 CEST] <kepstin> Durandal: I ususally end up doing "-f null -" since it's less typing :) [00:03:00 CEST] <Durandal> awesome, that seems to work [00:03:46 CEST] <Durandal> It also helps to throw in -map 0:a:0 if there's video, otherwise it will try and decode the video stream [00:03:48 CEST] <Durandal> thanks [00:44:29 CEST] <TheRock> hi [00:44:39 CEST] <TheRock> got stuck in the configuration [00:44:42 CEST] <TheRock> https://nopaste.linux-dev.org/?1181246 [00:45:06 CEST] <TheRock> That file contains a png Stream #0:1: Video: png, rgba(pc), 200x200 [SAR 3780:3780 DAR 1:1], 90k tbr, 90k tbn, 90k tbc [00:45:12 CEST] <TheRock> but my ffmpeg is configured to serve png [00:45:21 CEST] <TheRock> I assume a parser/demuxer is missing, which? [00:46:07 CEST] <JEEB> that really looks like it got decoded [00:46:10 CEST] <TheRock> other than that most of the audios contain an image can be viewed [00:46:33 CEST] <TheRock> but this mp3 doesn't report an error, it just doesn't show the image [00:46:42 CEST] <TheRock> before i had not png in the configuration, there was an error at least [00:47:02 CEST] <TheRock> now i just hear the music [00:47:04 CEST] <TheRock> but no image [00:47:15 CEST] <JEEB> I'm pretty sure that's just because it's set as not a real video track but rather an attachment image kind of thing [00:47:20 CEST] <JEEB> there was a flag for that :P [00:48:44 CEST] <TheRock> VLC does show the image for exdample [00:49:09 CEST] <drathir> TheRock: how mediainfo see it ? [00:49:41 CEST] <JEEB> TheRock: the track is there and you can decode it. pretty sure it's just the flag if you're using ffmpeg.c :P [00:49:53 CEST] <TheRock> i'm actually using QtAv [00:50:24 CEST] <JEEB> anyways, it's pretty simple to open an lavf context and try decoding the track. you should be able [00:50:53 CEST] <TheRock> so, from my configuration the image is decoded and it's rather programatically thing? [00:50:54 CEST] <JEEB> I think it's like 15-20 lines [00:51:04 CEST] <JEEB> most likely yes, looking at that output [00:51:12 CEST] <JEEB> you're clearly having the png decoder [00:51:15 CEST] <TheRock> the output is from ffprobe [00:51:21 CEST] <JEEB> from your own build? [00:51:33 CEST] <TheRock> no from my own build, from apt-get ffmpeg [00:51:36 CEST] <TheRock> not* [00:51:57 CEST] <JEEB> anyways, look at the doc/examples dir, and try opening the mp3 in a lavf context, then checking for best v/a tracks [00:52:01 CEST] <JEEB> and/or iterating through the tracks [00:52:36 CEST] <JEEB> and then if you have the png decoder (however it's called), you get it decoded just fine :P [00:52:48 CEST] <TheRock> sounds like a shitload of work [00:52:51 CEST] <TheRock> just to show an image [00:52:51 CEST] <JEEB> eh [00:53:12 CEST] <JEEB> a 15-20 lines of code to check that your thing has it since you haven't built the cli tools to quickly check? [00:53:23 CEST] <JEEB> why yes, that's a fuckload of work thank you very much [00:53:23 CEST] <TheRock> I don't knwo if qtav has the bindings, it's just a wrapper around ffmpeg [00:53:29 CEST] <JEEB> jesus [00:53:41 CEST] <JEEB> let me link you the example [00:53:59 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/examples/demuxing_decodi… [00:54:02 CEST] <JEEB> there [00:54:06 CEST] <JEEB> and that's got a crapload extra [00:54:08 CEST] <JEEB> which you don't need [00:54:27 CEST] <JEEB> (also it uses the old API for decoding, which is bad) [00:55:42 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/examples/transcoding.c;h… there, you are interested of up until line 85 [00:55:59 CEST] <JEEB> you open input, finde the decoder for the image stream [00:56:11 CEST] <JEEB> allocate a decoder and if it doesn't fail - congratulations [00:56:21 CEST] <JEEB> you have the decoder and it's somewhere in what you're using [00:56:32 CEST] <TheRock> Good, I'll have a look [00:57:20 CEST] <JEEB> also the transcoding example was updated to the new push/pull decoding API which is nice [00:58:12 CEST] <JEEB> also just enabling ffprobe is another way :P [00:58:31 CEST] <JEEB> although it's good to know that the FFmpeg APIs are not exactly too complex [00:59:03 CEST] <JEEB> (details are details, but getting the basic loop going for demuxing or decoding is not) [01:00:00 CEST] <TheRock> yeah [01:00:13 CEST] <TheRock> i just run a quick full configured ffmpeg test [01:00:22 CEST] <TheRock> like i said, mjpeg is rendered as expected [01:00:34 CEST] <TheRock> but png aren't [01:00:56 CEST] <JEEB> whatever that means [01:01:06 CEST] <TheRock> just want to be sure there isn't a decoder/whatever missing [01:01:10 CEST] <TheRock> before i go programatically [01:01:27 CEST] <JEEB> stop being a lazy bum and enable ffprobe if you care that much! [01:01:34 CEST] <JEEB> then you will see if it will see it [01:02:21 CEST] <TheRock> yep [01:02:31 CEST] <JEEB> that way your own ffprobe will use your libraries and you will see if anything is amiss [01:02:54 CEST] <TheRock> that's a good plan [01:03:54 CEST] <TheRock> I already took extra work to get zlib integrated which was needed for png. [01:11:43 CEST] <JEEB> TheRock: I think it's only needed for the png encoder? [01:11:47 CEST] <JEEB> although I might misremember [01:17:49 CEST] <TheRock> not sure [01:18:18 CEST] <TheRock> probably requires zlib, since png is compressed with that [01:19:28 CEST] <JEEB> ok, both need zlib [01:19:41 CEST] <JEEB> png_decoder_deps="zlib" [01:19:41 CEST] <JEEB> png_encoder_deps="zlib" [01:21:14 CEST] <JEEB> also apng and png decoders are separate :P [01:21:24 CEST] <JEEB> so if you enabled one but not the other [01:23:26 CEST] <TheRock> i'm just looking into zlib now [01:23:33 CEST] <TheRock> i got some warnings during compliation [01:24:18 CEST] <TheRock> but i don't think that isn't the problem at all [01:26:14 CEST] <JEEB> most likely not if the library loads and you have zlib in :P I saw the "apng" decoder in your configuration but I'm not sure if I saw png [01:26:26 CEST] <JEEB> also do enable ffprobe in your FFmpeg configuration for debugging [01:28:49 CEST] <drathir> there is known any security issue with --enable-libzvbi ? [01:29:42 CEST] <TheRock> I just opened a raw .PNG in my player which used this configuration i posted [01:29:46 CEST] <TheRock> renders perfectly [01:30:05 CEST] <TheRock> so zlib and png deocder both are working [01:31:12 CEST] <TheRock> now i opened another .png *doesn't render* [01:34:50 CEST] <drathir> TheRock: file and check differencies between them, maybe some options of this files differ ? [01:35:40 CEST] <TheRock> yeah, i hope to find it out [10:46:27 CEST] <JC_Yang> when av_read_frame() encountered error when reading a stream from network, do I need to abandoned the AVFormatContext and use a new one to retry? [10:52:16 CEST] <JEEB> JC_Yang: I think it might set itself EOF [10:53:28 CEST] <JEEB> so you might have to clear and re-init one [10:53:47 CEST] <JC_Yang> okay, get it. [11:30:41 CEST] <JC_Yang> suppose I ctx = avformat_alloc_context and the avformat_open_input(&ctx...) when failed, should I call avformat_free_context or avformat_close_input() to cleanup? and how about when success? [11:36:08 CEST] <JC_Yang> I suppose the api the named properly so I'll free_context when open_input failed but close_input when success, hope this is correct usage [12:37:29 CEST] <Mavrik> jcjordyn120: don't be afraid to look at the source of those functions to answer your questions [12:37:32 CEST] <Mavrik> er. [12:37:40 CEST] <Mavrik> JC_Yang who left. :( [13:13:34 CEST] <drathir> Guys any idea if that --enable-libzvbi still working with ffmpeg build ? [13:13:39 CEST] <JEEB> yes [13:14:14 CEST] <JEEB> as in, I just built 0736f32a4facddbd953977ca614a3ee6d8a6e1d7 yesterday [13:15:08 CEST] <JEEB> and yea, there have been no zvbi-related changes since [13:15:13 CEST] <JEEB> (in master) [13:19:21 CEST] <drathir> hmmm... wonder if there extra configuration or something needed, bc builded from source started its listed but looks like still gets problems with corectly detect dvb_teletext basing at https://trac.ffmpeg.org/wiki/ExtractSubtitles [15:19:01 CEST] <BobOki> Hey guys, just got a Quadro P2000 and it is absolutely rocking so for for video... however I have a question. Does FFMPEG support HW transcode for audio? [15:19:13 CEST] <JEEB> no [15:19:24 CEST] <JEEB> also audio transcoding generally is so simple that you don't need hw encoding for it [15:19:35 CEST] <JEEB> unless you're on a first gen rpi [15:19:40 CEST] <JEEB> in that case you're hosed [15:20:14 CEST] <BobOki> I figured the same... however on my plex box I was able to EASILY handle 5 4k streams, but the audio transcoding (ac3 7.1/dts/truehd) utterly trashed my older i7-2600k cpu. [15:20:44 CEST] <BobOki> (the P2000 sat at about 6% GPU usage on those 4k streams ;P ) [15:22:16 CEST] <durandal_1707> BobOki: i only know about flac encoder that utilizes GPU [15:22:19 CEST] <BtbN> That's because the GPU is not involved [15:22:39 CEST] <BtbN> It's an extra chip doing the de/encoding [15:23:39 CEST] <BobOki> Does FFMPEG have any plans to support audio de/encoding via GPU? So far the video xcoding is working quite well, I can't think of any technical limitations that it could not support audio too. [15:24:52 CEST] <BtbN> no [15:25:06 CEST] <iive> there is one crucial, no dsp in the sound card chips. [15:25:21 CEST] <BtbN> GPUs are bad for video already, which is why there are dedicated chips on them. [15:25:39 CEST] <BtbN> Audio can be processed with a few % of CPU load even on ancient hardware [15:26:13 CEST] <BobOki> Then there has to be something else wrong... my i7-2600k was utterly crushed by only 5 audio streams. [15:26:58 CEST] <iive> i think i7 should have more cores than that [15:27:57 CEST] <BobOki> 4 core 8 threads... [15:28:11 CEST] <BobOki> Mines running at 4ghz base [15:29:49 CEST] <durandal_1707> BobOki: what codec for encoding? [15:30:17 CEST] <BobOki> At the time, it was encoding 5 different streams.. they were AC3 7.1, DTS, and TrueHD [15:30:41 CEST] <BobOki> And it looked like they were all being converted to either AAC or ac3 [15:31:15 CEST] <durandal_1707> transcoding lossy to lossy? [15:31:28 CEST] <BobOki> I beleive so, yes. [15:42:00 CEST] <furq> yeah that shouldn't trouble an i7-2600k [15:42:32 CEST] <furq> unless decoding truehd is spectacularly slow [15:43:57 CEST] <BobOki> hmmm guess I will go run some tests... try to see what's going on then. It did not make sense to me that audio would kill it.. but yeah ;P [15:43:58 CEST] <BobOki> thanks all [15:48:07 CEST] <furq> even my old core 2 at stock clocks gets 20x transcoding from dts to fdk-aac [15:48:20 CEST] <furq> and that's singlethreaded [16:02:28 CEST] Action: kepstin would guess they were also transcoding video by mistake using a software encoder. [18:06:01 CEST] <th3_v0ice> Hi guys, I have been using FFmpeg C API for some time and I just noticed that after every encode (encoder opened and closed includes filters) number of threads is rising by 3. If the input sequence is long machine locks up after it creates too many threads. I am closing my encoder and filtering contexts as shown in the transcoding.c example. Am I missing some resource deallocation that should [18:06:01 CEST] <th3_v0ice> close the threads? Thanks! [18:19:30 CEST] <akk> Is there a way to make videos with ffmpeg that will play in firefox? [18:19:54 CEST] <akk> I made one with ffmpeg -i img%2d.png -filter:v "setpts=6.0*PTS" video.mp4 [18:20:25 CEST] <akk> and firefox says "Video can't be played because the file is corrupt", and in the console, [18:20:29 CEST] <akk> "Details: mozilla::SupportChecker::AddMediaFormatChecker(const mozilla::TrackInfo&)::<lambda()>: Decoder may not have the capability to handle the requested video format with YUV444 chroma subsampling. [18:24:10 CEST] <kepstin> akk: that errors says exactly what's wrong - and ffmpeg would have printed a warning when you ran the encode telling you how to avoid the problem [18:24:32 CEST] <kepstin> akk: anyways, add "-pix_fmt yuv420p" to the encode command and it'll work. [18:28:48 CEST] <akk> I've tried that too -- let me try it again and verify the error message. [18:31:35 CEST] <akk> Hmm, no -- I was getting "height not divisible by 2" (even though it was divisible by 2), but now with a different set of images it's working. [18:32:18 CEST] <akk> And it works in firefox! I must have had some other args interfering. Thanks, kepstin. [18:43:55 CEST] <Cracki> would anyone know why "video_track_timescale" is so hard to find documentation for? [18:57:05 CEST] <JEEB> Cracki: timescales are specific to mov-style containers. everything else IIRC uses time base, not scale [18:57:26 CEST] <JEEB> and I don't think we export time scales, only time bases? [18:57:33 CEST] <Cracki> settb with -c copy complains, so this is what I used instead [18:57:47 CEST] <Cracki> had some input with a 90k or something time base [18:57:55 CEST] <JEEB> mpeg-ts I guess [18:58:13 CEST] <Cracki> this exists, it needs documentation [18:58:24 CEST] <Cracki> and all google finds is mailing lists [18:58:31 CEST] <tuna> I am back with the hardware encoding questions....my setup seems to be calling image_copy_plane...which seems in correct, given I am using hardware input (CudaDevicePtr) [18:58:32 CEST] <JEEB> right, it warns because by default it overrides time base in movenc.c, and then of course someone wanted an exact time base, so someone made up an option [18:58:45 CEST] <Cracki> no... [18:58:55 CEST] <Cracki> my input has an insane time base. -c copy copies that [18:58:55 CEST] <JEEB> yes, movenc.c overrides the video time base by default [18:59:05 CEST] <Cracki> such that the output mov container can't handle it anymore [18:59:05 CEST] <JEEB> and 1/90000 isn't insane [18:59:15 CEST] <Cracki> -filter:v settb is incompatible with -c copy [18:59:18 CEST] <JEEB> also how on earth does mov not handle it? [18:59:24 CEST] <JEEB> and yes, yes it is [18:59:33 CEST] <Cracki> the mov container doesn't like this timebase [18:59:37 CEST] <Cracki> for the duration of my material [18:59:49 CEST] <JEEB> I know there's a warning about it, but I'm not 100% sure that's correct [19:00:16 CEST] <JEEB> welcome to the area of things where "I wish I hadn't seen this" is the second thought I have about it [19:00:44 CEST] <Cracki> warning? it aborted [19:00:54 CEST] <JEEB> I didn't remember if it was an error or warning [19:01:10 CEST] <JEEB> also IIRC there was a setting to set time base that is not specific to movenc.c [19:01:15 CEST] <Cracki> anyway, source file is a little more "broken" than this, so I should reencode anyway [19:01:57 CEST] <Cracki> thanks for the response in any case [19:04:22 CEST] <JEEB> anyways, I'm pretty sure there's a way to set the time base if you don't want the input (say, MPEG-TS) time base [19:04:47 CEST] <JEEB> also I've been meaning to check if the code for saying nope to random time bases for MOV is even correct [19:04:52 CEST] <JEEB> but it's not like I have a lack of things to do [19:04:57 CEST] <JEEB> unfortunately [19:04:58 CEST] <Cracki> ;) [19:05:50 CEST] <JEEB> there's -enc_time_base which is a per-stream option, but it's in a function that starts up encoders, so -c copy probably isn't going work with that [19:07:29 CEST] <JEEB> { "time_base", HAS_ARG | OPT_STRING | OPT_EXPERT | OPT_SPEC | OPT_OUTPUT, { .off = OFFSET(time_bases) }, [19:07:43 CEST] <JEEB> so there's a per-stream time_base option [19:17:54 CEST] <dimi_> Hello! I am considering linking to static builds of ffmpeg without zlib and bzlib. How would that limit the formats/codecs i would be able to process? I work mostly with audio. [19:19:44 CEST] <Cracki> are you asking legally or practically? [19:24:38 CEST] <dimi_> practically [19:28:05 CEST] <tuna> I am back with the hardware encoding questions....my avcodec_send_frame seems to be calling image_copy_plane...which seems incorrect, given I am using hardware input (CudaDevicePtr)..the function fails with an assertion "av_assert0(abs(src_linesize) >= bytewidth);" ......................any idea why this might be happening? I am trying to trace the source but am having little luck [19:33:53 CEST] <tuna> it seems nvenc_copy_frame is being called, when it should not be [19:38:18 CEST] <tuna> avcodec_send_frame calls ff_nvenc_send_frame calls nvenc_upload_frame should call nvenc_register_frame but rather it calls nvenc_copy_frame....this happens based on a switch statement: " if (avctx->pix_fmt == AV_PIX_FMT_CUDA || avctx->pix_fmt == AV_PIX_FMT_D3D11)" when checking my avctx's pix_fmt it, in fact, is AV_PIX_FMT_CUDA...maybe this was a bug or something and this source doesnt match my download of ffmpeg??? I am on version [19:38:23 CEST] <tuna> on the github page [19:38:48 CEST] <tuna> if not switch *** [19:43:25 CEST] <tuna> It appears this module underwent much change from 3.X to 4.X version [21:17:51 CEST] <Cracki> I could puke... at uni we have these wolfvision document cameras that go to video projectors. these things are UVC devices too. the companion software can record too, but it "drifts" up and down like crazy, compared to a known good time reference [22:03:24 CEST] <tuna_> my hardware input avcodec_send_frame calls image_copy_plane...and fails the first assertion...even though I have a AV_PIX_FMT_CUDA ...any help???? [22:52:36 CEST] <tuna_> Any nvenc hardware input h264 encoder people in here that can help?? [22:59:55 CEST] <BtbN> fix what the assertion is complaining about? [23:25:10 CEST] <tuna_> Obviously, but the assertion makes no sense... [23:25:50 CEST] <tuna_> I dont have a build environment for ffmpeg setup, but based on my code tracing...it seems it shouldnt assert false [23:29:15 CEST] <tuna_> Actually... [23:29:50 CEST] <tuna_> seems like it is iterating over my data, whern really it should only be looking at my first entry [23:30:16 CEST] <tuna_> I hit line 363 or imgutils when really I should be hitting line 357 [23:30:18 CEST] <tuna_> I believe [23:30:30 CEST] <tuna_> Thats the only thing that makes sense [23:33:12 CEST] <tuna_> WEll, maybe its not a big deal...becuase although it iterates it only goes up to index 0 [23:40:06 CEST] <tuna_> BtbN: can you tell me why this is even calling image_copy_plane when its herdware input? [23:40:41 CEST] <BtbN> Because you're doing something wrong. And there are copy functions for hw frames, so it's not entirely incorrect. [23:41:42 CEST] <tuna_> Yea, but this eventaully gets to a memcpy [23:42:10 CEST] <BtbN> your pix_fmt must be wrong then. [23:42:13 CEST] <tuna_> It happens in the res = av_frame_ref(nvenc_frame->in_ref, frame); call it seams [23:42:17 CEST] <tuna_> seems* [23:42:46 CEST] <tuna_> AV_PIX_FMT_CUDA is my context's fmt and AV_PIX_FMT_0BGR32 is my AvFrame's format [23:42:49 CEST] <BtbN> that should never cause a copy [23:43:00 CEST] <BtbN> your frames format is CUDA [23:43:11 CEST] <BtbN> if it's a CUDA frame, the pix_fmt is CUDA. [23:44:07 CEST] <tuna_> Yes, my AVCodecContext's pix_format is CUDA [23:44:19 CEST] <BtbN> you just said your frame ones isn't... [23:45:20 CEST] <tuna_> Correct, my AvFrame (input frame) is AV_PIX_FMT_0BGR32 [23:45:31 CEST] <BtbN> well, there you have your problem. [23:45:40 CEST] <tuna_> So they both should be CUDA? [23:45:52 CEST] <BtbN> If you're inputting a CUDA hardware frame, yes of course [23:46:07 CEST] <BtbN> it also needs to be owned by the same context, and the sw_pix_fmt needs to be valid. [23:47:33 CEST] <tuna_> A couple weeks back you said it had to be AV_PIX_FMT_0BGR32 for the frame though.... [23:47:48 CEST] <tuna_> when its cuda for the frame i get invalid argument error... [23:51:47 CEST] <tuna_> What does " it also needs to be owned by the same context" mean? [23:52:40 CEST] <BtbN> you cannot have more than one CUDA context and share data [23:52:44 CEST] <BtbN> and yes, 0BGR32 [23:52:57 CEST] <BtbN> is one of the two supported rgb pixel formats for nvenc [23:53:26 CEST] <BtbN> But if you are giving it hardware frames, the primary pix_fmt is still CUDA. [23:56:53 CEST] <bencc1> I'm trying to convert mp3 with cover image to hls: [23:56:55 CEST] <bencc1> ffmpeg -i test.mp3 -c:a aac -b:a 128k -hls_time 2 -hls_playlist_type vod -hls_flags single_file playlist.m3u8 [23:57:05 CEST] <bencc1> ffmpeg produce non-valid hls [23:57:14 CEST] <bencc1> mp4 works and mp3 with only audio channel works [23:57:34 CEST] <bencc1> I'm using version 3.4.2 [23:57:39 CEST] <bencc1> can someone reproduce? [23:58:07 CEST] <BtbN> iirc single file playlists are kinda broken [23:58:11 CEST] <BtbN> try master [23:58:32 CEST] <kepstin> if the cover art is the problem, try -vn [23:58:36 CEST] <bencc1> BtbN: did something relevant changed in master? [23:58:46 CEST] <bencc1> 3.4.2 is almost master [23:58:51 CEST] <BtbN> no, not at all [23:58:56 CEST] <BtbN> 3.4 was branches quite a while ago [23:59:07 CEST] <bencc1> do you have master installed? [23:59:13 CEST] <bencc1> any chance you can reproduce it? [23:59:39 CEST] <BtbN> I have no idea what to possibly reproduce [23:59:44 CEST] <BtbN> just grab a binary and test [00:00:00 CEST] --- Wed May 9 2018

1 0

ffmpeg-devel.log.20180507
by burek 08 May '18

08 May '18

[00:01:25 CEST] <rcombs> isn't the whole point of 708 being in the video bitstream compatibility with SDI and analog NTSC [00:03:28 CEST] <kierank> 708 contains 608 bytes [00:03:36 CEST] <kierank> which are backwards compatible with analogue [00:03:48 CEST] <kierank> sdi can carry full 708 but it's rarely used [00:04:18 CEST] <JEEB> yup [00:04:45 CEST] <wm4> what are the 100 bytes used for [00:33:39 CEST] <kierank> it's the name of the spec [01:48:00 CEST] <cone-455> ffmpeg 03James Almer 07master:0736f32a4fac: configure: fix and simplify xlib check [01:50:36 CEST] <jamrial> nevcairiel: ping [09:13:21 CEST] <JEEB> and since I asked before about parser allocation failures, I've seen things like this "Failed to reallocate parser buffer to 2070044476", "Failed to reallocate parser buffer to 2134313519" [11:01:52 CEST] <hanna> atomnuker: btw, do you have any thoughts about maybe using libplacebo for your vulkan filters? no need to reinvent most of the wheel here for the stuff that libplacebo already implements (e.g. the scaling code, and tone mapping) [11:02:05 CEST] <hanna> you could be a good target to model the VkImage interop API around [11:02:25 CEST] <hanna> especially making sure it would also work with mapped DRM surfaces and whatnot [11:09:06 CEST] <durandal_1707> NIH [11:11:18 CEST] <hanna> I'm not saying you have to rip out your own code, but a vf_placebo provided alongside whatever you have already would be a good addition I think [11:11:32 CEST] <hanna> It's not like lavfi doesn't already have wrappers to third party libraries [13:05:25 CEST] <pkv> @Btbn Hi, was wondering if the recent changes in nvenc might elicit a micro bump to avcodec ; what is the policy towards micro bumps ? [13:05:45 CEST] <BtbN> There was already a micro bump pushed after it [13:06:06 CEST] <BtbN> So no need to push another one. It was just forgotten. [13:07:24 CEST] <pkv> oh ok great, we might need it for obs-studio [13:29:33 CEST] <BtbN> philipl, I just realized, on 64bit (Which is basically the only supported CUDA arch ffmpeg has), the CUdevptrs are also host pointers. [13:30:13 CEST] <BtbN> That means, for the extra copy to host memory we currently do with nvdec, it could just do a dummy wrapper instead, creating a new classic sw frame, with the CUDA pointers casted to normal pointers [13:30:55 CEST] <BtbN> That wrapped frame would then need to hold a reference to the original frame in its buffer, so it doesn't get de-allocated too early, but that should be absolutely possible [13:49:57 CEST] <BtbN> hm, no. That wouldn't work properly. [14:35:38 CEST] <durandal_1707> Compnn: ffmpeg used for drones again! [14:56:25 CEST] <BtbN> Can pkg-config interpret complex version ranges? [14:57:20 CEST] <BtbN> like "ffnvcodec >= 8.1.24.3 || ffnvcodec < 8.1 && ffnvcodec >= 8.0.14.3" [15:23:41 CEST] <atomnuker> also it would be kind of an obscure dependency, as if libshaderc isn't enough (still not packaged by debian after lunarg offered to maintain it there) [15:25:46 CEST] <atomnuker> and really its not that much code to scale and convert [15:29:18 CEST] <BtbN> hm, the more I tinker around with this, the more I feel like the CUDA pix fmt is not going to cut it for performant nvdec [15:29:20 CEST] <BtbN> great [15:33:58 CEST] <BtbN> although I wonder, couldn't it create a PIX_FMT_CUDA frame with a custom allocator, that just is the mapped CUVID frame? And the destructor just unmapps it [15:49:59 CEST] <JEEB> ooh, was able to create a sample that makes libavformat do weird things to timestamps. exciting~ [16:16:45 CEST] <JEEB> ok, so it tries to fix the timestamp in ff_read_packet, but its initial guess goes way the wrong way [16:32:55 CEST] <JEEB> ok, so it wrong-updates reference for wrap-around and then deros [16:32:57 CEST] <JEEB> *derps [16:39:13 CEST] <microchip_> DerpOS [16:55:21 CEST] <philipl> BtbN: Did you try it? I know cuda supports dual-use pointers if you allocate them in the right way. But IIRC, the frame we're talking about here is allocated by cuvid and you can't control how it's done. [16:56:20 CEST] <BtbN> It won't work, it would lock out pre-Pascal hardware. [16:56:48 CEST] <BtbN> And the idea with streams to at least make the copying async also won't work, because it needs the frame mapped until the async operation completes [16:58:38 CEST] <philipl> Are you trying to optimise playback or transcode? [16:59:10 CEST] <BtbN> both [16:59:18 CEST] <BtbN> I'm trying to get rid of that needless extra copy it does [16:59:49 CEST] <philipl> There are other opportunities to save copies on playback if we revist the frame-is-cuda-array idea; that lets the player pass opengl surfaces all the way through so there's just one copy. [17:00:21 CEST] <BtbN> It currently does one completely pointless extra copy when using nvdec instead of cuvid [17:00:40 CEST] <BtbN> nvdec always copies to a normal device memory cuda frame [17:00:49 CEST] <philipl> hmm. [17:00:54 CEST] <BtbN> and that then gets copied into the actually used frame, or software frame [17:01:10 CEST] <BtbN> So just turning the mapped cuvid frame into a real frame would solve that [17:01:56 CEST] <philipl> I'd have to read through and remind myself about this part. [17:01:59 CEST] <philipl> But have to dash now. [17:02:55 CEST] <philipl> It always seemed weird to me that you couldn't get cuvid to write the frame into a buffer we control from the beginning. [17:04:58 CEST] <BtbN> well, you can't [17:05:11 CEST] <BtbN> But you can turn the buffer it gives you into a frame [17:05:53 CEST] <JEEB> begesus [17:05:54 CEST] <JEEB> update_wrap_reference [17:06:03 CEST] <JEEB> even for the case where a program is found for the stream [17:06:19 CEST] <JEEB> this is something that looks rather needlessly complex [17:39:59 CEST] <wm4> <JEEB> this is something that looks rather needlessly complex <- and doesn't even work? [17:40:30 CEST] <JEEB> ok, so it works when you only get subtitle packets until you get a PCR [17:40:52 CEST] <JEEB> because by then the subtitle packets' timestamps are fixed [17:41:22 CEST] <JEEB> but if you get a video packet and a subtitle packet before you get a PCR, welp [17:46:52 CEST] <jdarnley> Fuck! Not more BBC code!? Plus it is gstreamer: garbage and garbage [17:47:14 CEST] <JEEB> now that is random [17:51:24 CEST] <atomnuker> jdarnley: what do you mean? [17:52:09 CEST] <jdarnley> I went looking for the thread discussing the patch that added rtp-vc2 decoding to see what was said. [17:52:20 CEST] <jdarnley> Especially for hot to test the thing. [17:52:23 CEST] <jdarnley> *how [17:52:42 CEST] <jdarnley> What I found was ... [17:54:36 CEST] <jdarnley> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-February/188903.html [17:54:39 CEST] <JEEB> also can someone explain to me why everyone keeps dividing PCR by 300? [17:54:52 CEST] <JEEB> int64_t pcr = f->last_pcr / 300; is something I see in multiple places [17:55:03 CEST] <JEEB> oh wait [17:55:12 CEST] <JEEB> PCR is in 27MHz, right? [17:55:14 CEST] <jdarnley> 90kHz to 29MHz? [17:55:28 CEST] <JEEB> yea, I am dumb [17:55:59 CEST] <jdarnley> It is a "magic number" [17:56:09 CEST] <JEEB> yea [17:56:19 CEST] <JEEB> I've been staring at this code for way too long :D [17:57:24 CEST] <jdarnley> I do mean 27MHz [17:58:52 CEST] <jdarnley> I should submit a patch to change every 300 I find to TWENTY_SEVEN_MEGAHERTZ_OVER_NINETY_KILOHERTZ [18:16:12 CEST] <philipl> BtbN: So if I read this right, you'd ideally want to replace the buffer pool with wrapped mapped frames? [18:16:26 CEST] <BtbN> yes [18:16:37 CEST] <BtbN> The only question is if nvdec will run out of frames then [18:16:49 CEST] <philipl> Isn't there a way to control how many frames nvdec uses? [18:17:01 CEST] <philipl> Can't you say to use the same number as the pool size? [18:17:38 CEST] <philipl> NumOutputSurfaces? right? [18:19:43 CEST] <JEEB> wonder if we need an option to either scan for a PCR first, or just drop everything until we get a PCR in MPEG-TS [18:19:52 CEST] <JEEB> because this thing seems to start fixing itself as soon as PCR is received [18:20:41 CEST] <BtbN> I used to stare at mpegts PCR logic a while ago [18:20:43 CEST] <BtbN> and gave up [18:21:18 CEST] <jdarnley> Okay, I got ffmpeg talking to ffplay but I get 1 frame displayed every ~200 frames [18:22:13 CEST] <jdarnley> Won't display anything for my own stream [18:22:31 CEST] <jdarnley> and uplay crashes with the stream from ffmpeg [18:22:55 CEST] <JEEB> :) [18:26:13 CEST] <philipl> BtbN: Yeah, seems like if numOutputSurfaces == numDecodeSurfaces == pool size, you would get sane semantics. [18:26:19 CEST] <BtbN> philipl, https://github.com/BtbN/FFmpeg/commit/cbdd183b8c9aee8f7ca15867ad63e29e9a1c3… something like this [18:26:23 CEST] <BtbN> untested yet [18:26:48 CEST] <BtbN> "Picture size 0x0 is invalid" ok, it doesn't like that [18:27:29 CEST] <philipl> Presumably you can calculate what that should be. [18:27:37 CEST] <BtbN> it's 0 [18:27:47 CEST] <BtbN> I don't want the hw_frames_ctx to waste memory [18:27:53 CEST] <philipl> Oh, this again [18:27:58 CEST] <ubitux> http://ubitux.fr/pub/pics/2018-05-07-182729_753x626_scrot.png [18:28:01 CEST] <ubitux> what can i do? :( [18:28:06 CEST] <BtbN> But it needs to exist, because the hwaccel infra expects it [18:28:16 CEST] <BtbN> I'm not 100% sure on this though [18:28:20 CEST] <philipl> Can't you change the pool implementation to not allocate instead? [18:28:25 CEST] <BtbN> It might be possible to go without a hw_frames_ctx [18:28:37 CEST] <BtbN> The pool implementation is in avutil [18:28:47 CEST] <philipl> Yes, but it can be overriden, right? [18:28:57 CEST] <BtbN> I'd have to put a whole other implementation into cuvid for that [18:29:13 CEST] <BtbN> A mostly empty one, sure, but still [18:31:19 CEST] <philipl> Didn't you also want a no-op pool for something in nvenc? Or did you remove the frames_ctx usage completely? [18:31:33 CEST] <BtbN> It's just optional entirely [18:31:49 CEST] <BtbN> in theory at least [18:32:13 CEST] <BtbN> Hm, it crashes in cuMemcpy2D if I do things this way [18:33:33 CEST] <philipl> For the later copy? [18:34:38 CEST] <BtbN> yes [18:34:47 CEST] <philipl> also: what API reference is Oscar using? He's referring to methods I don't see in the headers [18:35:01 CEST] <BtbN> hm? [18:35:13 CEST] <BtbN> Every cuMemcpy* funtion has an cuMemcpy*Async version [18:35:15 CEST] <philipl> "DecodeLockFrame" [18:37:45 CEST] <philipl> So, the hwcontext_cuda transfer stuff is calculating the planes potentially differently from the original memcpy2d you are removing. [18:37:46 CEST] <BtbN> Something no documentation google knows mentions [18:38:05 CEST] <BtbN> no, plane calculation is pretty straight forward [18:39:34 CEST] <philipl> Well, I guess I'd starting by logging the src offset and size values for the transfer and see if they match what the old copy code comes up with [18:39:46 CEST] <philipl> If the frame isn't unmapped, the copy shouldn't care if it happens early or late. [18:40:20 CEST] <philipl> and you're doing this all under a single context? [18:40:43 CEST] <BtbN> I'd hope so, wouldn't know ffmpeg.c to create more than one [18:40:59 CEST] <BtbN> otherwise copying data wouldn't work in the first place [18:42:38 CEST] <philipl> Hmm [18:45:19 CEST] <atomnuker> jdarnley: keep in mind if you're testing with kierank's old hacked up obs streamer to support vc2 you should explicitly add -an [18:46:12 CEST] <kierank> jdarnley: don't use ffmpeg to test [18:46:14 CEST] <kierank> it won't work [18:46:15 CEST] <atomnuker> when I worked on it I got streams out of it which had invalid audio timestamps or missing audio so when ffmpeg tried to sync up audio and video it just got stuck [18:46:30 CEST] <atomnuker> of course it won't work if the audio's like that [18:46:43 CEST] <kierank> receiving 300mbit/s in the same thread as your decoder won't work ever [18:46:57 CEST] <jdarnley> I'm not sending 300M! [18:47:28 CEST] <kierank> even 20 will blow it [18:47:42 CEST] <kierank> it's a fools errand testing with ffmpeg, seriously [18:48:09 CEST] <BtbN> philipl, not making a 1x1 sized frame fixes the crash. So I think something is not properly replaced, or re-replaced. gdb will tell [18:50:07 CEST] <philipl> BtbN: So the hwframes_ctx params are getting factored into the transfer [18:50:31 CEST] <BtbN> if they were, it'd just copy a 1x1 frame, and not crash [18:51:02 CEST] <BtbN> cuda_transfer_data_from doesn't even access the hw_frames_ctx [18:51:30 CEST] <BtbN> except for getting the shift_height, which should be accurate still [18:53:35 CEST] <atomnuker> kierank: it isn't, its how I rewrote the decoder [18:57:37 CEST] <wm4> kierank: why will it blow it? [18:58:06 CEST] <kierank> wm4: if the decoding thread uses too much cpu you'll drop udp packets [18:58:16 CEST] <kierank> this isn't tcp, they come whether you like it or not [18:59:05 CEST] <kierank> the rtp input doesn't have the udp thread hack [18:59:20 CEST] <wm4> wouldn't you just give the udp thread a higher priority [18:59:35 CEST] <kierank> it's all in the main thread for rtp [19:00:32 CEST] <kierank> main thread does pthread_join or similar so has to wait for the others [19:00:39 CEST] <kierank> if that's a 35ms wait you've lost a lot of packets at 300mbi [19:01:32 CEST] <wm4> is this something you'd use an embedded rtos for [19:01:43 CEST] <kierank> no [19:01:57 CEST] <kierank> you'd put the udp source in the a new thread, tune the kernel input buffers [19:02:04 CEST] <kierank> and make that thread high priority ideally [19:03:03 CEST] <wm4> all that boring bloated soft realtime desktop shit [19:10:19 CEST] <BtbN> nevcairiel, or whoever is responislbe for hwcontext_d3d11va.c: in line 166, call to av_buffer_create, shouldn't it be size(*desc) instead of just size(desc)? [19:11:11 CEST] <wm4> probably me [19:11:23 CEST] <wm4> I don't think the size matters anyway [19:11:34 CEST] <wm4> the buffer ref is only used for refcounting [19:11:52 CEST] <wm4> the size would matter if the buffer data were directly involved in COW [19:11:57 CEST] <BtbN> When would the size passed to av_buffer_create even ever matter? [19:12:07 CEST] <BtbN> When you use that, you usually do custom stuff anyway [19:12:30 CEST] <wm4> essentially it never matters [19:12:52 CEST] <wm4> it can be useful if the bufferref is a flat byte array, but even then you have separate size fields (e.g. look at AVPacket) [19:13:29 CEST] <wm4> also some clever code in lavfi vf_pad uses the bufferref data/size fields to "expend" planes in place if there's enough memory [19:13:34 CEST] <wm4> but that doesn't matter for hwaccel stuff [19:14:18 CEST] <wm4> regarding the d3d11 code, feel free to change it to *desc if that's less confusing, but it doesn't really matter [19:26:39 CEST] Action: kierank hopes someone paid michaelni to work on mxf [19:26:46 CEST] Action: kierank wouldn't work on it even with money [19:29:40 CEST] <BtbN> philipl, it basically works. Just need to do something about the memory waste [19:32:22 CEST] <BtbN> I'm tempted to introduce a special case in the cuda hw_frames_ctx, to give it a noop mode for mapped frames [19:33:48 CEST] <durandal_1707> fftdnoiz is already faster that dctdnoiz and nlmeans [19:39:53 CEST] <wm4> BtbN: like that guy suggested? [19:40:04 CEST] <BtbN> no [19:40:24 CEST] <BtbN> I basically do not want the hw_frames_ctx to do any allocations. But I need it to exist, because otherwise stuff explodes. [19:40:48 CEST] <wm4> I mean it's designed to allow user allocation [19:40:52 CEST] <wm4> or preallocation [19:40:55 CEST] <BtbN> not inside of a hwaccel. [19:40:57 CEST] <wm4> (whatever you like) [19:41:02 CEST] <wm4> huh? [19:41:20 CEST] <BtbN> I'm changing cuvid to just put the mapped cuvid frame into the AVFrame, to avoid the pointless copy [19:41:42 CEST] <BtbN> So the pre-allocation by the hw_frames_ctx is a waste of memory [19:42:12 CEST] <BtbN> so, now I'm looking for a way to communicate to the cuda hw_frames_ctx that it's not needed [19:42:37 CEST] <wm4> you mean cuda allocates frames by itself? [19:42:42 CEST] <wm4> as in nvidia's code [19:42:52 CEST] <BtbN> cuvid has a map/unmap way of accessing the frame [19:43:02 CEST] <BtbN> right now, it maps, copies to hw_frames_ctx allocated frame, unmaps [19:43:24 CEST] <BtbN> but I changed it to map, set frame->data/linesize to mapped pointer, and add a buffer_ref to unmap on frame unref [19:47:47 CEST] <BtbN> every solution I can think of for this is massively ugly [19:48:20 CEST] <wm4> I still don't really get the problem [19:48:33 CEST] <BtbN> nvdec is massively slower than cuviddec [19:48:37 CEST] <BtbN> because of that pointless copy [19:51:28 CEST] <wm4> I mean with not doing the copy [19:51:47 CEST] <BtbN> You still need the hw_frames_ctx, because the hwaccel infrastructure demands it to exist [19:52:06 CEST] <BtbN> and it has a bunch of frames in it, which can waste several GB of video memory [19:52:58 CEST] <wm4> don't you need to allocate frames for cuda anyway? [19:53:10 CEST] <wm4> or does cuda (the nvidia API) allocate frames for you [19:53:22 CEST] <BtbN> the hw_frames_ctx allocates them for me [19:53:34 CEST] <BtbN> but I don't want that, as I'm writing the mapped frame from cuvid in there [19:54:07 CEST] <wm4> ... [19:54:08 CEST] <BtbN> it's just never truely allocated, but mapped from the cuvid frame [19:54:22 CEST] <wm4> so cuda allocates some sort of frame [19:54:26 CEST] <BtbN> cuvid [19:54:28 CEST] <BtbN> not cuda [19:54:37 CEST] <wm4> uh they're the same? [19:54:44 CEST] <wm4> cuvid is a subset of cuda, sure [19:54:56 CEST] <wm4> or are you talking about the ffmpeg things [19:55:21 CEST] <BtbN> cuvid is in its own whole library [19:55:22 CEST] <wm4> cuda = nvidia's API, cuvid = the part of cuda that deals with video [19:55:22 CEST] <philipl> cuvid is functionally unrelated to cuda. it was branded part of cuda but that's now dropped. [19:55:29 CEST] <JEEB> yra [19:55:33 CEST] <philipl> Hence nvdec [19:55:49 CEST] <wm4> fine [19:56:05 CEST] <wm4> so cuvid (nvidia's API) allocates frames automatically? [19:56:12 CEST] <philipl> Yes. [19:56:16 CEST] <BtbN> it doesn't allocate them normaly [19:56:21 CEST] <BtbN> you map them to a pointer [19:56:23 CEST] <BtbN> and unmap after use [19:59:43 CEST] <philipl> BtbN: Could you add a device_ctx flag? [19:59:55 CEST] <BtbN> no [19:59:59 CEST] <BtbN> it would poison the device [20:00:17 CEST] <BtbN> filters can easily allocate another frames_ctx on it, that _does_ have to create frames [20:00:25 CEST] <philipl> lovely [20:00:42 CEST] <BtbN> the only solution I see is magic numbers, but that's absolutely not going to happen [20:00:55 CEST] <BtbN> Or changing the API, to add creation flags [20:00:58 CEST] <philipl> Can we have two frames_ctx for cuda? [20:01:14 CEST] <philipl> can nvdec chose the implementation to use? [20:01:19 CEST] <BtbN> so duplicate the whole thing, one with a dummy allocator? [20:01:22 CEST] <philipl> yeah [20:01:30 CEST] <BtbN> that's possible, but ugly [20:01:40 CEST] <philipl> of course that brings us back to might-as-well-have-dummy-allocator-inside-nvdec [20:01:49 CEST] <BtbN> that's not possible [20:02:21 CEST] <BtbN> The HWContextType which holds the hw_frames/device_ctx function pointers is avutil internal. [20:02:31 CEST] <philipl> sad panda. [20:02:48 CEST] <philipl> so duplicate frames_ctx impl it is! :-) [20:05:03 CEST] <wm4> you can make a different pixfmt, or add a frames_ctx creation parameter to control it [20:05:25 CEST] <BtbN> I don't even have access to the frames_ctx creation, as decode.c is doing most of that [20:05:35 CEST] <wm4> the more important question is, would it make sense to represent mapped frames as AVFrame, or is that just a hack to get the copy avoidance [20:05:36 CEST] <BtbN> I guess I could put it into the struct [20:05:50 CEST] <wm4> decoders can suggest creation parameters [20:05:54 CEST] <BtbN> wm4, they are 100% identical in format. They just need to be unmapped after use. [20:06:06 CEST] <BtbN> Which a buffer_ref in buf[0] can do [20:06:08 CEST] <wm4> ff_nvdec_frame_params [20:06:18 CEST] <philipl> Externally owned buffers for AVFrames are a thing elsewhere aren't they? [20:06:29 CEST] <wm4> does not unmapping them stall decoding or something stupid? [20:06:29 CEST] <BtbN> that's how most other hwaccels work [20:06:45 CEST] <BtbN> Not unmapping them will kill decoding [20:06:52 CEST] <wm4> videotoolbox in particular has the VT API allocate frames [20:07:03 CEST] <wm4> BtbN: that seems useless for most cases then [20:07:23 CEST] <BtbN> Why? You don't usually hoard frames [20:07:45 CEST] <wm4> I mean you will reference a bunch of frames (usually a low number, maybe 1-4) [20:07:56 CEST] <wm4> and unref them after display or whatever [20:07:59 CEST] <BtbN> That's fine, as long as you don't exhaust the pool [20:08:11 CEST] <wm4> so can you still control the pool size? [20:08:30 CEST] <BtbN> the user can't, but yes [20:08:58 CEST] <BtbN> it ensure like 4 + dpb_size frames to be available at all times [20:09:20 CEST] <wm4> unless the user can control it the API isn't compatible [20:09:30 CEST] <wm4> does nvidia document that 4? [20:09:43 CEST] <BtbN> Why would nvidia document ffmpeg internals? [20:09:54 CEST] <llogan> what's the minimum nasm version supported? [20:10:04 CEST] <wm4> oh, so if it's an ffmpeg internal, the user _can_ control it [20:10:16 CEST] <wm4> you should need to wire it up to the pool size [20:10:39 CEST] <wm4> (initial_pool_size) [20:10:58 CEST] <BtbN> oh indeed [20:11:04 CEST] <BtbN> avctx->extra_hw_frames already exists for exactly that [20:11:23 CEST] <BtbN> line 1234 in decode.c [20:11:53 CEST] <wm4> that's orthogonal but yes [20:12:18 CEST] <BtbN> no, the initial_pool_size is exactly the count of maximum wrapped frames at a time [20:12:57 CEST] <wm4> I mean an API user can use that to control how many extra frame he gets when allocating the hwctx manually [20:13:25 CEST] <BtbN> no, he can use that for the internal hw_frames_ctx just fine [20:13:31 CEST] <wm4> mpv allocates the hwcontext manually with decoder suggested parameters, only to "cache" hwframe pools across seeks and to add additional frames [20:13:41 CEST] <BtbN> Users can't even set the hw_frames_ctx of decoder themselves [20:14:05 CEST] <wm4> user as in API user [20:14:10 CEST] <BtbN> yes, those users [20:14:18 CEST] <wm4> uh yes, they can [20:14:20 CEST] <BtbN> there's a hard alloc for it in the code somewhere [20:16:02 CEST] <BtbN> I hope AVHWFramesContext size if not part of the ABI? [20:16:16 CEST] <wm4> no [20:16:22 CEST] <wm4> it's not [20:16:44 CEST] <BtbN> good. So I'm just gonna add a flags fields to it, and then introduce a flag for the CUDA allocator to put it in "mapped mode, do not actually allocate" [20:17:04 CEST] <wm4> yeah [20:17:17 CEST] <wm4> does anything still need actually allocated frames? filters maybe? [20:17:38 CEST] <BtbN> Yes, anything but the decoder keeps working as normal [20:17:52 CEST] <BtbN> hw_frames_ctx are not safe for re-use anyway [20:18:06 CEST] <BtbN> every producer of frames has to allocate their own one [20:19:02 CEST] <wm4> what do you mean by this? [20:19:29 CEST] <BtbN> A filter can't re-use the hw_frames_ctx of the source of its frames [20:19:52 CEST] <wm4> well it could, if the parameters are the same [20:19:58 CEST] <wm4> but in practice won't [20:20:02 CEST] <BtbN> There is no way for it to have a guarantee they won't change [20:20:34 CEST] <BtbN> There was some discussion about this a while ago, and the conclusion was that it's not safe to use a hw_frames_ctx if you're not the one who owns/controls it [21:26:59 CEST] <BtbN> philipl, wm4 yeah, this is working fine now. And it brings nvdec and cuvid to the same speed. [21:27:41 CEST] <philipl> nice. [21:27:55 CEST] <philipl> You could add this to cuvid too right? [21:28:15 CEST] <BtbN> cuvid doesn't have that extra copy in the first place [21:28:36 CEST] <philipl> But cuvid does an immediate copy of the mapped frame too doesn't it? [21:29:41 CEST] <philipl> That is what I see in the code. [21:30:55 CEST] <BtbN> I'm only testing sw download performance [21:31:40 CEST] <philipl> Ah. So what about full hardware pipelines? [21:31:56 CEST] <philipl> Presumably this is beneficial there too. [21:36:42 CEST] <BtbN> no differnce at all [21:37:57 CEST] <philipl> no measurable difference, you mean? [21:45:36 CEST] <BtbN> yeah, not a single fps even, at 350 fps [21:46:41 CEST] <philipl> Well, can't complain about that. [21:47:01 CEST] <philipl> Are you making this nvdec change conditional on sw download or always on? [21:52:10 CEST] <BtbN> nvdec has no idea about swdownload or not [21:52:13 CEST] <BtbN> that's the whole problem [21:52:22 CEST] <philipl> Right, right. I remember now. [21:52:42 CEST] <BtbN> -hwaccel nvdec -hwaccel_output_format cuda is subtly broken though [21:52:55 CEST] <BtbN> there's one macroblock of broken U/V data at the top [21:53:00 CEST] <philipl> weird. [21:53:34 CEST] <philipl> not an offset problem? the rest of the u/v is correct? [21:53:41 CEST] <BtbN> yep, rest seems correct [21:53:50 CEST] <BtbN> and the copy to sw path works, with the same offset [21:54:47 CEST] <BtbN> https://btbn.de/public/scrn/1525722858.png I mean, it's pretty obvious that the line belongs to the bottom of the screen [21:55:49 CEST] <BtbN> I'm mildly confused as to why this only happens in the no-sw-copy path [21:55:58 CEST] <BtbN> but copying the same pointers to sw is just fine?? [21:56:33 CEST] <BtbN> Unless cuvid is unhappy about the frames staying used for longer, while in the swdownload case they are pretty much freed immediately [21:57:42 CEST] <philipl> Huh. Weird. [21:58:45 CEST] <philipl> It shouldn't be unhappy if we believe their docs. The frame is mapped and there are more in the pool. Should be safe. [21:59:16 CEST] <philipl> You could try dumping some bytes early and late in the pipeline and see if they actuall change. [21:59:23 CEST] <BtbN> I'm gonna add trace logs to the map/unmap functions which logs the idx [22:02:59 CEST] <BtbN> hm, it's obviously more all over the place, but isn't even close to running out. [22:15:13 CEST] <BtbN> ok, this is weird. Even if I hilariously mess up the UV plane intentionally, the wrong bar stays in place [22:15:24 CEST] <BtbN> and the image below looks as messed up as you'd expect [22:16:16 CEST] <BtbN> https://btbn.de/public/scrn/1525724157.png like this [22:18:25 CEST] <BtbN> almost like the Y plane is wrong. But on on earth would it be? [22:19:03 CEST] <atomnuker> driver issues? there's still 1-2 frame chroma lag on my machine [22:20:03 CEST] <BtbN> Why would this only happen in this constellation? [22:20:15 CEST] <BtbN> also, I need a better test pattern tham Game of Thrones [22:21:49 CEST] <BtbN> ok _now_ things are getting weird. I added complete bullshit to the data pointer [22:21:52 CEST] <BtbN> the image is unchanged [22:22:09 CEST] <BtbN> there must be some rarely used internal magic nvdec->nvdec kicking in, being broken [22:22:15 CEST] <BtbN> *nvdec->nvenc [22:23:52 CEST] <BtbN> oh I have a suspicion what's going on [22:31:33 CEST] <BtbN> Yeah, found it. Now to find out how to fix it [22:36:31 CEST] <cone-799> ffmpeg 03Zhong Li 07master:06344f705e66: lavc/qsvenc: set corret maximum value of look_ahead_downsampling [22:36:31 CEST] <cone-799> ffmpeg 03Haihao Xiang 07master:65be65da37eb: cbs_h264: Need [] in the name when subscript is required [22:36:31 CEST] <cone-799> ffmpeg 03Haihao Xiang 07master:1b0e0578c2ed: vaapi_encode_vp8: memset the the structure to 0 [22:37:54 CEST] <BtbN> Can avctx->coded_width ever be unset? [22:38:12 CEST] <BtbN> in an encoder? [22:38:16 CEST] <BtbN> It somehow is inaccurate. [22:38:59 CEST] <BtbN> Anyway, I never intended to push the patch that broke it. So reverting it it is. [22:39:40 CEST] <jkqxz> "encoding: unused". So yeah, you shouldn't use it at all. [22:46:35 CEST] <BtbN> Yeah, it's a simple revert of the patch that broke it. [23:18:18 CEST] <philipl_> BtbN: what was the problem? [23:18:49 CEST] <BtbN> I had that patch to make hw_frames_ctx in nvenc in one of my last batches of patches, but I just forgot it in there, and I never tested it. [23:18:55 CEST] <philipl_> ah [23:19:09 CEST] <BtbN> And it uses the actual frame width/height to register the hwframe [23:19:26 CEST] <BtbN> instead of the width/height from the hw_frames_ctx, which is the coded_width/height [23:21:54 CEST] <BtbN> next on is a battle with configure [23:22:04 CEST] <BtbN> Because I have complex version requirements to ffnvcodec [23:24:58 CEST] <thardin> whew, that's a lot of mxf patches [23:30:15 CEST] <ubitux> durandal_1707: found a way to help compilers, making nlmeans slightly faster again [23:30:22 CEST] <ubitux> you may want to try nlmeans-dsp on my github [23:35:40 CEST] <BtbN> jkqxz, hm, "May be set by the user before calling av_hwframe_ctx_init().", or "To be set by the user..." or just "Can be set..." [23:35:48 CEST] <durandal_1707> ubitux: what you did this time? [23:35:54 CEST] <BtbN> no idea what most clearly describes its intend [23:36:06 CEST] <ubitux> inline the patch value computation [23:36:08 CEST] <BtbN> also, in this case, it's not even true, theoretically this flag can be changed at any time [23:36:23 CEST] <ubitux> so that it doesn't compute the position in the inner loop [23:36:31 CEST] <ubitux> also, i just experimented a branchless version [23:36:34 CEST] <ubitux> and it looks faster [23:36:46 CEST] <ubitux> i'll commit in a moment [23:41:24 CEST] <ubitux> that one needs some thinking, i'll do it tomorrow [23:41:35 CEST] <ubitux> but current state of the branch should be generally faster [23:51:28 CEST] <ubitux> yeah nah, branchless isn't faster [00:00:00 CEST] --- Tue May 8 2018

1 0

ffmpeg.log.20180507
by burek 08 May '18

08 May '18

[00:55:52 CEST] <RossW> Anyone up for a challenge with ffmpeg? I'm creating a video from static jpeg images on 4 input streams, so the resulting video is basically a "quad". [00:57:07 CEST] <RossW> My issue is that the input files come from 4 to 8 different directories, depending on which inputs are required... so each input "channel" may need to select images from one, the other, or both if its directories. [00:57:35 CEST] <RossW> It would be wonderful if there was a magic way to make ffmpeg take inputs for each channel from a file.... [00:58:24 CEST] <RossW> Part of the command line goes: [00:58:43 CEST] <RossW> /usr/local/bin/ffmpeg -hide_banner \ [00:58:49 CEST] <RossW> -start_number $sn1 -i $picsdir/$c1/%d.jpg -r $fps \ [00:58:53 CEST] <RossW> -start_number $sn2 -i $picsdir/$c2/%d.jpg -r $fps \ [00:58:59 CEST] <RossW> -start_number $sn3 -i $picsdir/$c3/%d.jpg -r $fps \ [00:59:07 CEST] <RossW> -start_number $sn4 -i $picsdir/$c4/%d.jpg -r $fps \ [00:59:54 CEST] <RossW> ... but the problem is when input stream 1 (picsdir/$c1/) needs to ALSO come from a different directory [01:01:10 CEST] <RossW> The entire command is quite complex because it adds subtitles, overlayed text, logo and other feature-specific images that relate to the input streams. [01:56:45 CEST] <poutine> I'm streaming via RTP with FEC via ffmpeg w/ prompeg and it works great, let's say from 6 hour mpegts files w/ AVC/h264 streams in them, the problem we have is those 6 hour mpegts files are dynamically created, and our current way of switching (turning off ffmpeg and restarting) is causing monitoring software issues, and admittedly seems like the wrong way to do things [01:56:58 CEST] <poutine> is there a right way of doing this seamlessly that can be achieved using ffmpeg/OSS world? [01:57:57 CEST] <JEEB> I would just recommend making your own API client instead of utilizing ffmpeg.c, if that's what you're using [01:58:19 CEST] <JEEB> ffmpeg.c is really static and made for specific use cases [01:58:29 CEST] <JEEB> it really isn't built for partial re-initializations etc [01:58:38 CEST] <poutine> JEEB, I'm not working that low level, I'm just using the command line, was hoping there was something I could pipe the ffmpegs into and it works out the stream to be sent so there's no seams [01:59:20 CEST] <JEEB> well in theory you could feed it stuff from a pipe and set -rw_timeout XXX -follow 1 [01:59:28 CEST] <JEEB> not sure how well it would work [01:59:47 CEST] <JEEB> but on the long run, I will bet you will hit a limit where ffmpeg.c will no longer cut it [02:00:03 CEST] <JEEB> as in, the FFmpeg APIs could do it, but ffmpeg.c is just not meant for that use case [02:00:44 CEST] <poutine> you're probably right, I'll check out the pipe w/ options and see what's actually going on there [02:01:06 CEST] <JEEB> at least with files rw_timeout and follow means that libavformat will keep reading [02:01:12 CEST] <JEEB> until it hitts that rw_timeout [02:01:19 CEST] <JEEB> so it works with growing files, f.ex. [02:02:18 CEST] <JEEB> but yea, I've seen plenty of examples where people start doing things with ffmpeg.c, and then at some point it no longer can facilitate what's needed. and the best hacks are when some people then start hacking stuff in the libraries just not to touch the client code... even though it's the wrong place [02:02:40 CEST] <JEEB> even something as simple as switching streams [02:02:53 CEST] <JEEB> libavformat has dynamically adding streams [02:03:23 CEST] <JEEB> and while not nice, it does let you figure out what streams to pick from MPEG-TS f.ex. at a given time [02:03:38 CEST] <JEEB> (I have had some ideas on how to improve this) [02:10:09 CEST] <poutine> JEEB, Have you heard of tsduck or multicat being used at all in this capacity? [02:10:40 CEST] <poutine> I wonder if I can get away with using ffmpeg to RTP/FEC stream the output of it pieced together elsewhere through pipes [02:22:08 CEST] <giaco> what is this? RTP: dropping old packet received too late. It happens on ffplay and mplayer when the source stops and restarts [04:15:26 CEST] <Lunchbox> hey [04:17:31 CEST] <Lunchbox> is the deblock filter not supported when encoding using nvenc? [04:21:13 CEST] <kepstin> Lunchbox: it should work fine, but depending on what you're doing you might have to use the 'hwdownload' or 'hwupload' filters to transfer the frames between gpu ram and system ram (since most ffmpeg filters run on the cpu) [04:23:34 CEST] <Lunchbox> the error i'm getting is [04:23:39 CEST] <Lunchbox> no such filter: 'deblock' [04:24:06 CEST] <Lunchbox> does hwdownload and hwupload go inside the vf params? [04:44:56 CEST] <kepstin> oh, there is no filter just named 'deblock' [04:45:27 CEST] <kepstin> maybe read through https://www.ffmpeg.org/ffmpeg-filters.html to find a filter that does what you want [04:46:09 CEST] <kepstin> the 'pp' filter can do deblocking for example [04:46:31 CEST] <Lunchbox> that's what i was using for reference [04:46:35 CEST] <Lunchbox> https://www.ffmpeg.org/ffmpeg-filters.html#deblock [04:46:50 CEST] <Lunchbox> i had specific values in mind but using the first example provided doesn't work [04:46:59 CEST] <Lunchbox> deblock=filter=weak:block=4 [04:47:50 CEST] <kepstin> oh, huh, that filter is really recent [04:47:59 CEST] <kepstin> you probably don't have a new enough ffmpeg to use it [04:48:23 CEST] <Lunchbox> shoot [04:48:25 CEST] <Lunchbox> lol [04:48:29 CEST] <kepstin> in fact, that must be a post-4.0 addition [04:52:30 CEST] Action: kepstin checks, and confirms that you'd need an ffmpeg master build from after april 21 to use that filter. [04:53:27 CEST] <kepstin> the web page filter docs are built from git master, so they're often ahead of the ffmpeg version people have on their systems. you can reference the 'ffmpeg -fitlers' output and 'man ffmpeg-filters' to see what your local ffmpeg supports. [04:53:43 CEST] <kepstin> except spell -filters correctly [04:54:10 CEST] <Lunchbox> man i just downloaded 4.0 and saw it still didn't work haha [04:54:19 CEST] <Lunchbox> i'll try to find that build specifically [04:54:27 CEST] <Lunchbox> thanks [04:55:43 CEST] <kepstin> well, you want the latest nightly build [04:57:10 CEST] <Lunchbox> ya just grabbed it [04:57:12 CEST] <Lunchbox> it works! [04:57:17 CEST] <Lunchbox> appreciate the help [05:15:27 CEST] <Lunchbox> would you happen to know how to achieve results similar to using negative deblock values using these specific parameters? [05:18:59 CEST] <Lunchbox> the gui i was using before allowed for negative values which would actually increase block visibility [05:35:27 CEST] <furq> Lunchbox: are you sure it wasn't just setting -deblock [05:39:18 CEST] <Lunchbox> yes [05:41:33 CEST] <Lunchbox> negative values are like going backwards from the default deblock values towards no-deblock [05:41:45 CEST] <Lunchbox> example being tune grain [05:41:47 CEST] <Lunchbox> https://superuser.com/questions/564402/explanation-of-x264-tune#answer-5644… [05:42:01 CEST] <furq> yeah that's -deblock [05:42:58 CEST] <furq> that's mapped to --deblock in x264, i assume nvenc has it mapped as well [05:43:35 CEST] <Lunchbox> oh sick [05:44:26 CEST] <Lunchbox> not sure how to achieve similar results with ffmpeg [05:44:39 CEST] <furq> just -deblock -1:-1 [05:45:09 CEST] <Lunchbox> oh wow [05:45:37 CEST] <Lunchbox> i assumed it had to use the new parameters since it wasn't working before but my ffmpeg version was just too old [05:48:33 CEST] <Lunchbox> doesn't appear to actually do anything after encoding [05:50:25 CEST] <furq> shrug [05:50:33 CEST] <furq> it works for x264, i have no idea about nvenc [05:51:00 CEST] <Lunchbox> i'll play around with the new options [05:51:18 CEST] <Lunchbox> hopefully it's possible i just don't understand what each value does yet [05:51:24 CEST] <Lunchbox> some don't have descriptions [09:47:11 CEST] <gloomy> Hi :) This is rather off-topic but I don't know where to ask. I have a lot of old DV tapes with family movie and want to digitalise them. The camera is connected to my computer by firewire. Any Idea what kind of software I can use to capture the video stream? Ideally command-line, so that I can pipe the output into ffmpeg and compress it on the fly (I have limited hard drive space and I read DV is around 13Gb/hour) [09:53:34 CEST] <furq> !indev iec61883 @gloomy [09:53:34 CEST] <nfobot> gloomy: http://ffmpeg.org/ffmpeg-devices.html#iec61883 [09:53:36 CEST] <furq> maybe that [09:54:21 CEST] <furq> apparently debian ffmpeg has it as standard so you might be lucky and not have to rebuild [09:55:11 CEST] <gloomy> I'm on macos which makes it extra complicated as it goes through a thunderbolt adapter, but thanks, I'll start there :) [10:32:32 CEST] <EJoker> I want to share the tutorial which I have created for FFmpeg 3.4 using latest Android NDK r16b, so that people can compile FFmpeg for android app development. [10:32:42 CEST] <EJoker> How can it be done? [10:35:52 CEST] <JEEB> I don't think FFmpeg building for NDK needs anything special [10:36:09 CEST] <JEEB> also there's a FATE instance doing the cross-compile already [10:36:24 CEST] <JEEB> but sure, a wiki article on trac is probably the most realistic [10:36:47 CEST] <JEEB> just make sure you're not using any android specific makefiles etc since those are *not* required [10:37:13 CEST] <JEEB> http://fate.ffmpeg.org/report.cgi?slot=armv7a-android-gcc-4.4-shared&time=2… [10:37:19 CEST] <JEEB> this is a darn old thing of course [11:39:19 CEST] <gloomy> Is it a bad idea/are there any contraindications to installing ffmpeg with /all/ the options? [11:39:46 CEST] <gloomy> I've been using ffmpeg for two months and I already had to recompile 4 times because of an extra feature I needed [11:52:29 CEST] <furq> it's not really possible [11:52:43 CEST] <furq> a lot of libs are platform-specific [11:53:06 CEST] <furq> and also a lot of them do the same thing [11:53:31 CEST] <furq> gnutls/openssl/libtls/schannel/securetransport being an obvious example of both of those [11:59:38 CEST] <gloomy> So any suggestion on how to get the most complete install possible for my platform (macos)? [12:00:22 CEST] <gloomy> I've been trying to install with libiec61883 as you pointed me to but from what I understand it's a linux library [12:05:55 CEST] <furq> if libiec61883 is linux only then there's probably no way to do it with ffmpeg on osx [12:06:50 CEST] <furq> oh [12:07:05 CEST] <furq> https://www.ffmpeg.org/ffmpeg-devices.html#avfoundation [12:07:06 CEST] <furq> maybe that? [13:34:47 CEST] <gloomy> I've been trying for two hours now but I can't get it to recognize the camera. I'll just import it with imovie and do the processing after... [13:41:58 CEST] <gloomy> It's the first time I do this, so I need some suggestions: I have raw DV files that take a huge amount of space despite very low quality (it's converted from an old analog camera, so, grainy 720x576 video). I want to convert them to a more reasonable size before doing some editing/trying to improve the quality a bit. Is it fine to use a modern lossy encoding like hevc or x264? [13:43:10 CEST] <gloomy> I know it's generally better to do the editing on the raw files, but I have over 800GB of them and I don't even have the necessary storage to keep them on my laptop while I do editing [13:43:39 CEST] <gloomy> Or are there good lossless compression schemes that would be better in this case? [13:45:14 CEST] <furq> dv is lossy, so anything lossless is probably going to turn out larger [13:46:11 CEST] <furq> if it was me i'd keep the originals and throw them on some cloud storage [13:47:40 CEST] <furq> on the plus side it's pal dv which means it's 4:2:0 and not 4:1:1 [13:55:12 CEST] <gloomy> But how is the editing experience with such huge files? I can't imagine the amount of ram needed for even short sequences of film [13:55:48 CEST] <gloomy> (I mean, with a GUI editing software like iMovie or final cut) [13:55:52 CEST] <Blacker47> gloomy, there is no editing software that tries to put whole video to ram. [13:56:25 CEST] <furq> you need to decode video to edit it anyway [13:56:32 CEST] <furq> so it doesn't really make much difference [13:57:20 CEST] <gloomy> ah, yes, seems legit [14:02:27 CEST] <gloomy> Alright, I'll get a new hard drive and do the editing from there. Hope iMovie was optimised for that. [14:09:05 CEST] <furq> also i'm pretty sure DV is a bit smaller than 13GB/hour [14:09:13 CEST] <furq> probably closer to 10 [14:09:23 CEST] <furq> which is still not great but it's not too bad [14:11:50 CEST] <Blacker47> furq, no it something on 13 GB/h. [14:16:40 CEST] <Blacker47> 13,7 GB/h if used with 16-bit audio. [14:16:56 CEST] <furq> fair enough [16:54:02 CEST] <YourBuddy> hey guys [16:54:05 CEST] <YourBuddy> any1 up? [16:57:27 CEST] <YourBuddy> need help with a subs hardcoded/hidden inside a media file [18:13:02 CEST] <Trel> Can ffplay be used to output video directly to the video buffer on a machine without X running? [18:14:12 CEST] <Trel> *framebuffer [18:20:09 CEST] <JEEB> you might want to look into what drm etc outputs in mpv can do? [18:20:19 CEST] <JEEB> ffplay is just a PoC thing [18:21:47 CEST] <Trel> Ah, then I'm thinking probably mplayer or vlc would be the best option for my use. I'm not opposed to X but it's going on a RPi for the sole purpose of playing a video stream, so I was looking for the lightest possible option. I've used ffplay to test video so I figured it couldn't hurt to check. [18:22:07 CEST] <Trel> (I'm 99% sure mplayer can output to framebuffer) [18:22:21 CEST] <klaxa> framebuffer is not really "light" though [18:22:24 CEST] <JEEB> mpv is basically 2nd gen fork of mplayer [18:22:40 CEST] <JEEB> and if you have DRM support you probably want DRM instead of fb [18:22:47 CEST] <JEEB> since you can do HW rendering there [18:23:05 CEST] <Trel> DRM as in digital rights, or direct rendering? [18:23:11 CEST] <JEEB> the latter [18:23:37 CEST] <JEEB> there seem to be two guys rather actively working on the opengl DRM back-end in mpv [18:23:59 CEST] <Trel> I'll check that out once we get the Pi then. I think we're ordering today. [18:24:30 CEST] <Trel> Thanks [18:24:44 CEST] <furq> i'm pretty sure mpv can output to fb on an rpi [18:28:55 CEST] <Trel> Hopefully it gets ordered with Prime so I can do it sooner rather than later. Most annoying part of the pi is swapping dhcpcd for network manager. That's the part I hate. [20:17:28 CEST] <wfbarksdale> why is the timebase for streams an AVRational, in what case would the numerator not be 1? Presumably this only applies to non ISOBMFF files? [20:51:15 CEST] <kepstin> wfbarksdale: for ntsc video, the natural timebase is something like 1001/30000. [20:52:23 CEST] <kepstin> various file formats support different timebase representations of course, or sometimes even have fixed timebases. [20:54:55 CEST] <wfbarksdale> keptin: i see, so pts for NTSC would be 1, 2, 3... instead of 1001, 2002, 3003? [20:55:58 CEST] <kepstin> usually it's nice to chose a timebase so the frame numbers are simple incrementing integers, yeah. [20:56:19 CEST] <kepstin> ffmpeg doesn't require that, of course. [20:59:35 CEST] <kepstin> the 'fps' filter, for example, works by setting the output timebase to the inverse of the requested framerate, then converts the input video to that timebase, dropping/duplicating frames so the result has nice incrementing pts values. [21:00:25 CEST] <wfbarksdale> i'm working on some c++ abstractions backed by an ffmpeg implementation, and would prefer to represent time as a simple rational [21:03:33 CEST] <kepstin> that can't be done in general, unless you're ok with having to round some oddball timestamp values (making them non-exact). Facebook wanted to do that, and they ended up picking a really oddball timebase that's just the gcd of a bunch of common rates. [21:03:38 CEST] <kepstin> https://github.com/OculusVR/Flicks if you're curious. [21:04:02 CEST] <wfbarksdale> and unfortunately std::chrono needs the "time base" part to be known at compile time. So it is sort of looking like I have to make my own little c++ library to handle the math [21:04:48 CEST] <kepstin> wfbarksdale: if that's what you want, maybe try that facebook library. It's pretty much that little c++ lib that you'd have to write. [21:06:22 CEST] <wfbarksdale> ahh, cool! will definitely look at this, thanks! [21:07:03 CEST] <kepstin> but keep in mind that it doesn't quite match how a lot of video software really works, so you're gonna have to do time conversions anytime you're moving stuff into or out of that format [21:11:19 CEST] <kepstin> note that ffmpeg internally uses a time base of 1/1000000 (microseconds) in a lot of places where it has to deal with external clocks or sometimes when combining stuff with mismatched timebases. [22:25:42 CEST] <Derisar> How can I transform a video file to make it minus heavy on the GPU resources? (possibly without reducing resolution) [22:26:36 CEST] <c_14> you decrease the resolution [22:26:41 CEST] <c_14> all other processing is usually done on the cpu [22:27:26 CEST] <Derisar> c_14 but I heard that also changing the codec can help [22:28:35 CEST] Action: drathir wonder if its planned support for: "Decoder (codec dvb_teletext) not found for input stream #0:3" and stream report as "Subtitle: dvb_teletext " [22:29:26 CEST] <kepstin> Derisar: changing the codec might change gpu resources if you're doing hardware decoding on the gpu, but note that most gpus do hardware decoding with dedicated hardware, so it doesn't really reduce available resources to other apps. [22:30:08 CEST] <drathir> Derisar: isnt it designed to not be heavy at gpu with hw acceleration in decoding? [22:30:24 CEST] <Derisar> kepstin, yes I'm doing hardware decoding [22:31:06 CEST] <Derisar> drathir I suppose that it depends on the codec [22:31:11 CEST] <drathir> Derisar: You can at least change profile used for decode but it in theory should incerase file size... [22:31:59 CEST] <Derisar> drathir also a friend tell me about that but it's a film with various special effects, explosions and such [22:32:13 CEST] <drathir> dantti: i dont think so, bc its hw acceleration, only profile i guess could get any difference in gpu load exclude resolution ofc... [22:32:36 CEST] <Derisar> So he telled me that explosions cannot be compressed much because they're entropy [22:32:41 CEST] <kepstin> Derisar: what's the actual problem that you're having? If it's using hardware decoding, then the only time you should be worrying about resources is if it's not being realtime [22:33:20 CEST] <Derisar> kepstin, i'm using mpv and audio/video goes in desync [22:33:29 CEST] <drathir> Derisar: any modern gpu should almost sleep with load on gpu even with high profiles... [22:33:46 CEST] <Derisar> drathir, my gpu is shit [22:34:05 CEST] <kepstin> Derisar: then either it's not using the hardware decoder, or the player is doing post-processing that your system can't handle. [22:34:28 CEST] <Derisar> kepstin, I've set it to do hardware decoding [22:34:31 CEST] <kepstin> if your gpu is too old, it's possible that the video is in a codec that the hardware doesn't support. [22:35:16 CEST] <drathir> Derisar: yea searched too in past solutions, but only what i found upgrade gpu was to some decent even weaks ones models... [22:35:25 CEST] <kepstin> Derisar: it would be helpful to know more about the video format and codecs and system hardware details. [22:36:25 CEST] <drathir> Derisar: atm im at old radeon which deal fine with avc x264, but after ome changes they disabled x265 decoding on it... [22:36:25 CEST] <sfan5> make a log file using --log-file=mpv.log and pastebin that, it provides all info kepstin asks for [22:37:16 CEST] <drathir> Derisar: also check few settings with mpv to tweak hw decoding... [22:38:30 CEST] <drathir> Derisar: yep it could using hw decoding but movie profile is too high for buildin decoder... [22:40:40 CEST] <drathir> Derisar: check also xv vs opengl --vo ==hwdec for vaaapi and vdpau... [22:41:44 CEST] <drathir> vainfo/vdpauinfo/xvinfo if no errors... [22:42:28 CEST] <drathir> Derisar: i dont think so You get older than r600 ;p [22:46:05 CEST] <Derisar> https://paste.debian.net/hidden/5fc0775a/ [22:46:16 CEST] <Derisar> drathir, kepstin here's the paste [22:48:33 CEST] <drathir> Derisar: check vainfo/vdpauinfo [22:48:59 CEST] <Derisar> drathir, how? [22:49:26 CEST] <drathir> Derisar: You for sure get better performance with 1080p x264... [22:49:51 CEST] <drathir> Derisar: that should be command builidin in drivers tools... [22:50:26 CEST] <drathir> Derisar: one in mesa second in nouveau if good remember... [22:53:11 CEST] <kepstin> Derisar: yep, the video is hevc codec, and your gpu (amd kabini) doesn't support hevc. [22:53:27 CEST] <Derisar> Wut [22:53:58 CEST] <drathir> Derisar: vainfo from command line any output? [22:54:10 CEST] <Derisar> drathir, what do you mean? Command buildin in driver tools? [22:54:35 CEST] <Derisar> kepstin, so I should reencode it in yuv420p? [22:54:58 CEST] <Derisar> drathir, I will try [22:55:23 CEST] <kepstin> Derisar: it's already yuv420p. You want to re-encode it to h264 codec [22:55:24 CEST] <drathir> Derisar: reencode to x264 it should be smothly but higher size... [22:55:40 CEST] <drathir> Derisar: which os? [22:55:51 CEST] <Derisar> drathir, debian linux [22:56:10 CEST] <Derisar> kepstin, isn't it hevc? [22:56:29 CEST] <kepstin> Derisar: it's hevc right now, but your gpu doesn't support hardware decoding hevc [22:56:33 CEST] <drathir> Derisar: apt-get install vainfo [22:56:57 CEST] <Derisar> drathir, I was installing it before thanks [22:57:44 CEST] <drathir> Derisar: hevc is x265 one based... [22:58:13 CEST] <drathir> Derisar: now output from console vainfo to some pate service... [22:58:19 CEST] <Derisar> https://paste.debian.net/hidden/9d484ce4/ [22:58:58 CEST] <kepstin> exactly as I expected the kaveri apu has uvd4, which supports h264 and mpeg2 and vc1 (and maybe xvid/divx, but not on linux) [22:59:39 CEST] <drathir> Derisar: interesting that mpv reporting hw decoding if there no profile for it... [23:00:05 CEST] <kepstin> Derisar: to repeat what we've been telling you: transcode the file to h264 (using e.g. the x264 encoder), then your gpu will be able to hardware decode it, and it should play back smoothly. [23:00:14 CEST] <Derisar> drathir, I've set it to auto [23:00:28 CEST] <Derisar> kepstin, command option? [23:00:31 CEST] <drathir> kepstin: honestly thats sounds sad that 10 y.o mb gpu get similar set ;/ [23:00:33 CEST] <Derisar> *options [23:01:06 CEST] <drathir> Derisar: also auto in mpv mostly not working as excepted ;p [23:01:49 CEST] <Derisar> drathir, then what should I put in hvdec? [23:02:10 CEST] <Derisar> s/hvdec=auto/???? [23:02:19 CEST] <drathir> Derisar: mpv --hwdec=vaapi path_to_file [23:02:52 CEST] <kepstin> hmm? looks like auto is working as expected.. it tries to hardware decode the file, fails because the hardware can't decode it, then falls back to software decode (which is too slow on this underpowered apu) [23:03:17 CEST] <drathir> should get something like: [23:03:19 CEST] <drathir> Using hardware decoding (vaapi). [23:03:19 CEST] <drathir> VO: [vaapi] 640x360 vaapi[nv12] [23:03:45 CEST] <Derisar> Wait [23:03:47 CEST] <kepstin> well, no it won't, because the hardware doesn't support hevc... [23:03:58 CEST] <Derisar> So that's why that HD video was running smoothly [23:04:11 CEST] <Derisar> Video: h264 (Main) [23:04:19 CEST] <kepstin> video in h264 should work fine with the hardware decoder, yes [23:04:21 CEST] <sfan5> note that vo=vaapi is different hwdec=vaapi [23:04:43 CEST] <sfan5> vo=vaapi is not required for hwdec, but can improve performance on low-end hardware [23:05:27 CEST] <drathir> Derisar: but im pretty sure as kepstin say for me stopped work with h265 when they take back/delete HEVC_MAIN from output list... [23:06:14 CEST] <drathir> when was present up to 720p was handled on gpu higher get green screen/artefacts... [23:07:11 CEST] <Derisar> drathir, so that's why vlc when playing some videos with VDPAU gets green artifacts [23:07:38 CEST] <drathir> sfan5: correct on modern better should give --vo=opengl... [23:08:03 CEST] <sfan5> you mean vo=gpu, you can just just omit that anyway since it's the default [23:09:05 CEST] <drathir> sfan5: there was in past too opengl-hq if good remember that one killed performance drastically on old devices... [23:09:30 CEST] <sfan5> yes that's called profile=gpu-hq now [23:09:57 CEST] <drathir> nice to know opengl is now default one... [23:11:21 CEST] Action: drathir need play again with settings in free time maybe some new tricks get found which incerase performance at old devices... ;p who knows... [23:12:48 CEST] <kepstin> Derisar: anyways, if you want to transcode that video to h264 so you can play it, a command like "ffmpeg -i original.mkv -map 0 -c copy -c:v libx264 h264copy.mkv" should do the trick. It'll take a while since it's doing the video transcode on the cpu, of course, but the result should be playable. [23:13:57 CEST] <drathir> and hopefully no big hit in quality too... [23:15:20 CEST] <kepstin> that'll use crf 23 by default, i think, which some people might find a little low. Should probably be good enough tho. Depends on the source. [23:15:56 CEST] Action: drathir wonder if there are present devices which support hw acceleration of encode x265? [23:16:19 CEST] <drathir> with ffmpeg ofc... [23:16:54 CEST] <kepstin> drathir: yes, most current model nvidia cards, at least some recent intel gpus, and amd rx 300 and later series. [23:17:41 CEST] <kepstin> iirc amd vega and nvidia 10xx stuff can do vp9 now, too [23:18:40 CEST] <kepstin> oh wait, you said encode [23:18:43 CEST] <kepstin> i was thinking decode [23:19:11 CEST] <drathir> kepstin: oh was surpriised, bc yea mostly is listed decode, but not saw encode yet... [23:20:15 CEST] <kepstin> hevc encode should work on a decent selection of recent nvidia stuff at least, but probably only when using the proprietary driver [23:22:41 CEST] <drathir> and probably will shoot into some low profile gtx 10xx ones, bc still should support all pcie ports i guess... and just wait for nouveau support for it... [23:23:00 CEST] <kepstin> note that the gt 1030 doesn't have any hardware encoder at all. [23:24:31 CEST] <kepstin> recent amd stuff is supposed to support hardware hevc encoding, but I have no experience with getting that to work in linux (and their h264 encoder wasn't all that good, so I wouldn't expect great results with hevc either) [23:24:33 CEST] <drathir> kepstin: woow really O.o - noted that crazy indeed... [23:25:41 CEST] <kepstin> looks like you should be able to 8-bit hevc with intel skylake and 10-bit with intel kaby/coffee lake [23:26:10 CEST] <kepstin> i dunno how well that's supported in linux, i don't have any intel chips that new :) [23:26:27 CEST] <drathir> kepstin: more pricey soolution would be just change mb to intel i5/i7 line, but that higher costs, bc all hw need to be replaced... ;p [23:26:55 CEST] <jkqxz> H.265 encoding does work on my Polaris card, but the card locks up completely (requiring reboot) in some unclear cases if you do much else with it at the same time so I wouldn't say it's production-ready yet. [23:27:00 CEST] <kepstin> if you were gonna replace all the hardware, i'd just go for a big multicore cpu so you could do software encoding :) [23:27:38 CEST] <kepstin> oh, huh, my office pc is actually skylake. Maybe I should try the hevc encoder just to see what's up. [23:28:21 CEST] <jkqxz> Intel does work fine (and stably), but it's not really any better than than H.264 encoder. [23:29:01 CEST] <drathir> kepstin: i was play with intel gpu a little on customer devices, and suprise works not bad as i thought... exclude intel driver mistakes broke gpu at all from working ;p but just that not so often still ;p [23:29:24 CEST] <jkqxz> (Though consequently it's not significantly slower either, so it might be nice for things which need H.265.) [23:31:36 CEST] <drathir> jkqxz: i saw that nvidia ones gt 740m gets too hangsup with paused video probably buffer overload or something similar randomly too... [23:33:11 CEST] <kepstin> the gt 740m is an annoying model, because there were two versions - one using gk107, one using gk208, and iirc the gk208 version doesn't have a hardware encoder, but the gk107 does. [23:33:43 CEST] <kepstin> (there's a few other 7xx models with that problem too) [23:33:46 CEST] <drathir> kepstin: yea with new hw no big deal mostly at cpu handle encoding, but more wondered if there present some nice solution for hw encode (even if its not louf about them ;p)... [23:33:55 CEST] <drathir> louf/loud* [23:34:34 CEST] <kepstin> hardware encoders are designed to solve a particular problem: encode video at realtime or faster speeds without using cpu. [23:34:56 CEST] <drathir> jkqxz: and yea if not crash every start good takes of xx% from cpu load... [23:35:02 CEST] <kepstin> as a result, they are almost always lower quality than a software encoder could do at the same bitrate. [23:37:47 CEST] <drathir> kepstin: but would be nice using eg. gpu/cuda for encode calculations too... that in theory should be still multiple times faster in processing data than cpus in theory ofc... [23:41:26 CEST] <drathir> kepstin: at least them enough cpu smoothly pplay x265 1080p [23:41:53 CEST] <drathir> kepstin: them mean gt7440m notebooks cpus... [23:46:07 CEST] <Derisar> kepstin, I used ffmpeg .i original.mkv -c:v libx264 -crf 18 -preset slow -c:a copy h264copy.mkv is it nearly the same? [23:49:31 CEST] <kepstin> Derisar: your command will be a little slower (the default is -preset medium) and higher quality (because -crf 18 is better than the default) [23:49:57 CEST] <kepstin> Derisar: since you didn't include "-map 0", if the input has multiple audio or subtitle tracks, they won't all be copied to the output. [23:50:21 CEST] <drathir> btw its interesting some sources from x264 to x265 gets huge difference in size close to 50% less filesize and other gets less than 10% lower size or sometimes even bigger than source ;p [23:50:45 CEST] <kepstin> drathir: size has nothing to do with anything [23:50:59 CEST] <kepstin> I can make an x264 file that's 50% smaller than another x264 file, no problem... [23:51:06 CEST] <kepstin> just encode at lower bitrate. [23:52:18 CEST] <drathir> kepstin: thats true, but all that on default settings with quality no visable difference... [23:53:06 CEST] <drathir> kepstin: and yea bitrate ofc lower for x265... [23:54:55 CEST] <drathir> but interesting some sources allow auto lowering bitrate other somehow prevent doing that.. [23:56:06 CEST] <kepstin> both x264 and x265 default to an encoding method that is approximately "constant quality" (-crf option), which means that the resulting bitrate will depend on how complex the video content is to encode. [23:57:08 CEST] <drathir> probably some config options matter for that behaviour, but so far not get clue which one could be that... first thought CABAC frames but looks like no valid pattern with them... [23:57:28 CEST] <Derisar> kepstin o thx [23:58:21 CEST] <drathir> kepstin: thats mean some sources could get better/easier 'compressed' other dont... [23:58:51 CEST] <kepstin> drathir: there's too many variables and encoder features to provide a simple answer, but yes, some videos are easier to compress than others for a given codec. [23:59:35 CEST] <Durandal> qq: is there a way to specify a null output file for ffmpeg on windows? [00:00:00 CEST] --- Tue May 8 2018

1 0

ffmpeg-devel.log.20180506
by burek 07 May '18

07 May '18

[00:22:42 CEST] <cone-295> ffmpeg 03James Almer 07master:08032331ac4c: fate: update fate-sws-pixdesc-query reference file [09:30:57 CEST] <cone-359> ffmpeg 03Jun Zhao 07master:4d3e9e31356b: avformat/avio: make the logic simple [09:30:57 CEST] <cone-359> ffmpeg 03Jun Zhao 07master:053ee996a03b: lavf/format: Remove the dead code in av_probe_input_buffer2. [14:49:06 CEST] <BtbN> hm, I forgot to bump lavc version for the new nvenc features. [16:29:42 CEST] <JEEB> I would like if someone would check out the zlib pkg-config thing and the libbluray protocol fix I just posted [16:29:54 CEST] <JEEB> both seem to be general quality of life improvements [16:30:27 CEST] Action: JEEB goes to have a jog [17:54:07 CEST] <cone-112> ffmpeg 03Jan Ekström 07master:b995ec078f42: lavf/bluray: translate a read of 0 to EOF [17:55:50 CEST] <JEEB> scratch one bogey [18:08:11 CEST] <JEEB> any interest for someone to poke https://patchwork.ffmpeg.org/patch/8795/ ? [19:49:29 CEST] <cone-112> ffmpeg 03Jan Ekström 07master:8d1263fa199f: configure: add pkg-config check for zlib [19:50:24 CEST] <JEEB> and that makes my configure line simpler [19:51:39 CEST] <atomnuker> JEEB: maybe you should backport that bluray patch to the release/4.0 branch too [19:51:58 CEST] <JEEB> yea I did ask about that on the ML [19:54:19 CEST] <kierank> JEEB: I think patch ok but the whole muh carl [19:55:00 CEST] <JEEB> if that's regarding the zlib thing, then that should be OK; I retain the fallback [19:55:11 CEST] <JEEB> so the non-pkg-config people can still get their fix [21:23:33 CEST] <atomnuker> ubitux: up to write a few lines of aarch64 simd for the opus mdct? [21:30:02 CEST] <cone-112> ffmpeg 03Michael Niedermayer 07master:0a4745145840: avcodec/g2meet: Change order of operations to avoid undefined behavior [21:30:03 CEST] <cone-112> ffmpeg 03Michael Niedermayer 07master:3543522d200f: avcodec/jpeg2000dec: Reduce the number of tile parts allocated [21:30:04 CEST] <cone-112> ffmpeg 03Michael Niedermayer 07master:a96c131eb53b: avcodec/jpeg2000dec: Skip init for component in CPRL if nothing is to be done [21:30:05 CEST] <cone-112> ffmpeg 03Michael Niedermayer 07master:652ba72ed312: avcodec/jpeg2000dec: Fix undefined shift in the jpeg2000_decode_packets_po_iteration() CPRL case [21:44:15 CEST] <ubitux> atomnuker: eventually [21:44:28 CEST] <ubitux> but you're going to distract me from doing the subtitles stuff [21:49:39 CEST] <atomnuker> oh, ok, I'll write it instead [21:50:07 CEST] <atomnuker> subtiltes in avframes are more important and interesting [21:57:08 CEST] <wm4> subs in lavfi are going to be such a mess [21:57:40 CEST] <atomnuker> why? multiple formats? [22:00:26 CEST] <wm4> AVSubtitle is already a mess [22:00:50 CEST] <wm4> and AVSubtitle is not suitable to transport all kinds of subtitles anyway (yeah...) [22:01:07 CEST] <wm4> and then there's the synchronization issue, because subtitles are sparse [22:01:25 CEST] <JEEB> I think the best things are those where you can get random PNGs in the middle of caption lines [22:04:59 CEST] <JEEB> although even ruby text is already welp [22:05:08 CEST] <JEEB> will have to see how that can be decoded [22:07:56 CEST] <cone-112> ffmpeg 03Marton Balint 07master:03038d4da95e: avcodec/libzvbi-teletextdec: allow -1 subtitle duration and make it the default [22:07:57 CEST] <cone-112> ffmpeg 03Marton Balint 07master:ab7692ee3594: avcodec/libzvbi-teletextdec: remove DEBUG code [22:08:05 CEST] <JEEB> najs [22:10:05 CEST] <atomnuker> JEEB: what do you mean? like base64 encoded pngs as lines? [22:10:25 CEST] <JEEB> atomnuker: not exactly base64 but yes, they have custom symbol spots [22:10:35 CEST] <JEEB> I was looking for screenshots I took before, but I couldn't quickly find them [22:12:59 CEST] <JEEB> atomnuker: I think it might have been headerless PNG with a hard-coded header specified in the spec [22:13:03 CEST] <JEEB> but let me double-check [22:26:46 CEST] <cone-112> ffmpeg 03James Almer 07master:652b857b9473: configure: add missing dependencies to vf_srcnn [22:27:43 CEST] <CoreX> is there a way to actually compile libzvbi with mingw/msys(2) [22:27:58 CEST] <JEEB> out of the box it doesn't build AFAIK [22:29:39 CEST] <CoreX> yeah got the same feeling when i was trying todo it myself ended up using an ffmpeg compiled with it but dont like using 2 diffrent versions of ffmpeg, would like just running one [22:30:02 CEST] <JEEB> also libzvbi is pretty much unmaintained at this point [22:30:06 CEST] <JEEB> unless someone forked it [22:30:14 CEST] <wm4> weren't there patches for an internal decoder [22:30:21 CEST] <JEEB> a basic one, yea [22:33:00 CEST] <kierank> JEEB: iirc it is maintained [22:33:14 CEST] <kierank> I wanted VideoLAN to fork it at one point but then he started working on it [22:33:35 CEST] <JEEB> oh I see canalplus forked it [22:33:36 CEST] <JEEB> lol [22:34:34 CEST] <kierank> They use it in their box [22:34:41 CEST] <kierank> It seems [22:34:43 CEST] <JEEB> yea [22:34:45 CEST] <kierank> For Teletext decoding [22:35:10 CEST] <JEEB> by looking at the repo's root it basically explained that those are source dumps for their STBs [22:36:39 CEST] <kierank> libzvbi is really powerful [22:36:46 CEST] <JEEB> it is [22:37:06 CEST] <JEEB> which is why it seemed so unfortunate that the last time I checked its official site etc the tarballs etc were old as hell [22:38:51 CEST] <kierank> Not as if Teletext changes much [22:39:10 CEST] <JEEB> true [22:39:36 CEST] <JEEB> but then even if you fix compilation on system X it seems like there's no upstream [22:58:28 CEST] <iive> is there still analog broadcasting ? [22:58:56 CEST] <JEEB> no, but teletext is a separate PID in MPEG-TS [22:59:01 CEST] <JEEB> there's a digital spec for it [22:59:36 CEST] <BtbN> There is Analog Broadcast on cable TV here [23:00:03 CEST] <BtbN> But they are in the process of slowly getting rid of it [23:00:21 CEST] <JEEB> well, yes - existence of analog depends on where you are. I was just pretty much answering the question "I thought teletext was analog-only? Do we still need it for something?" [23:00:22 CEST] <iive> so libzvbi can handle even rendering dvb teletext? [23:00:26 CEST] <JEEB> yes [23:00:30 CEST] <JEEB> it very much can [23:01:18 CEST] <JEEB> I wonder if there's a way to put side data into the decoded frames regarding pages. because currently you have to open a separate decoder for each page you want [23:01:28 CEST] <JEEB> (or get all the things in a single decoder) [23:01:31 CEST] <iive> vbi is the method used to encode teletex in analog tv signal, so the name implies that is what the library is about. [23:01:43 CEST] <JEEB> it also supports the analog stuff, yes [23:01:53 CEST] <JEEB> but it's general use case nowadays is the digital DVB teletext [23:01:58 CEST] <JEEB> *its general use case [23:02:09 CEST] <iive> well, it is not named libteletext ;) [23:02:20 CEST] <JEEB> you are getting close to behaving like durandal_1707 [23:02:23 CEST] <JEEB> please don't [23:02:27 CEST] <iive> maybe this is good name for a fork. [23:03:45 CEST] <iive> JEEB, i thought this is friendly chatting, i don't see why you are so disturbed. sorry. [23:04:08 CEST] <JEEB> sorry, the witty-witty stuff is something that some others have abused :P [23:11:15 CEST] <durandal_1707> JEEB: why are you bad mouthing me? [23:12:32 CEST] <JEEB> I am not. You are just a good example looking at the logs. [23:12:48 CEST] <durandal_1707> JEEB: what? [23:24:16 CEST] <durandal_1707> JEEB is violating FFmpeg's Code of Conduct [23:25:00 CEST] <Compn> durandal_1707 : some of us get tired of some of the remarks you make on a regular basis. i can point out some of them if you like [23:26:04 CEST] <JEEB> that said, you are also a very productive member of the community and I respect you for a lot of your filter etc. related work [23:26:17 CEST] <Compn> that too [23:27:16 CEST] <JEEB> But if you feel like I hurt you, I am sorry. I might have overstepped the boundaries of not being an asshole. [23:27:56 CEST] <durandal_1707> now Compn, what i did to Compn? [23:28:02 CEST] <Compn> it would be nice if everyone just stopped talking about each other and each others attitude but blah :P [23:29:09 CEST] <Compn> :PPPPPPP [08:58] <durandal_1707> Compn should kill mplayer already [23:29:11 CEST] <Compn> hehe [23:31:50 CEST] <JEEB> meanwhile, michaelni - what was the procedure for back-ports? do I just push into the release branch? [23:32:25 CEST] Action: CoreX opens up a hug circle [23:35:24 CEST] <wm4> I still don't know what's supposed to be wrong with y4m seeking (except that it's completely broken now) [23:37:46 CEST] <jamrial> JEEB: cherry pick into release branch and push, yes [23:37:58 CEST] <JEEB> ok [23:38:11 CEST] <jamrial> use -x so the commit message in the cherry pick points to the original commit [23:38:51 CEST] <JEEB> ah there was a parameter for that [23:39:02 CEST] <JEEB> I always did "This is a cherry-pick of commit X" manually or so [23:41:14 CEST] <durandal_1707> wm4: how it is broken? use --no-correct-pts [23:44:01 CEST] <wm4> or what's --no-correct-pts supposed to change [23:46:28 CEST] <Compn> isnt that an mplayer command ? did wm4 keep that for mpv ? [23:46:36 CEST] <Compn> er no, we use single dash nevermind [23:49:53 CEST] <kierank> JEEB: we still do analogue teletext [23:49:55 CEST] <kierank> a lot of it [23:55:27 CEST] <JEEB> kierank: yes, I am not surprised since you can most likely put it into things like SDI etc [00:00:00 CEST] --- Mon May 7 2018

1 0

ffmpeg.log.20180506
by burek 07 May '18

07 May '18

[01:47:48 CEST] <n000g> HACK THE PLANET! [02:04:45 CEST] <TheRock> --extra-ldflags="-LC:\zlib" [02:04:56 CEST] <TheRock> what is the windows msvc equivalent? [02:05:03 CEST] <TheRock> LINK : warning LNK4044: unrecognized option '/LC:\zlib'; ignored [06:00:07 CEST] <TheRock> hi guys when building ffmpeg [06:00:09 CEST] <TheRock> strip symbols no [06:00:09 CEST] <TheRock> optimize for size no [06:00:14 CEST] <TheRock> what are the switches ? [06:19:13 CEST] <furq> TheRock: --disable-stripping and --enable-small [06:19:30 CEST] <furq> it's unlikely you want --enable-small [06:34:23 CEST] <TheRock> anything bad about --enables-small? [06:42:44 CEST] <furq> TheRock: it disables certain optimisations [06:43:25 CEST] <TheRock> ah, i see [06:43:37 CEST] <TheRock> right now my ffmpeg is 6-7 mb [06:43:49 CEST] <TheRock> it would suprise me if that can go down further [06:44:03 CEST] <furq> are you actually building for a target where it matters [06:44:12 CEST] <TheRock> since i disabled everything and have just a few deocders enable [06:44:30 CEST] <TheRock> the ffmpeg will be linked in a statically build project [06:44:52 CEST] <TheRock> the single binary is already 22mb, which shouldnt grow more [06:45:22 CEST] <TheRock> it doesnt really matter [06:49:35 CEST] <furq> well yeah you can try --enable-small [06:49:47 CEST] <furq> --enable-lto might help as well [06:50:20 CEST] <furq> but obviously disabling stuff will have the biggest impact [06:58:38 CEST] <poutine> Anyone know how it's possible to generate the rolling survey of video bitrate in x264 videos data that you always see graphed in professional QC tools? [06:59:36 CEST] <poutine> or even a good explanation of what it usually represents? (I get a little confused with the display/decode order of things and which timeline this is affixed to usually) [12:36:51 CEST] <fooman2011> Hello. I have problem using "av_read_frame". My problem is that when the http stream is cut for some seconds (due to lag), then the data read using av_read_frame are not complete. I don't know how to restore a correct state without a full stream restart. Could you please help me ? [12:38:43 CEST] <BtbN> It should either die completely or not lose a single byte [12:38:58 CEST] <BtbN> Unless it internally reconnects or something [12:40:32 CEST] <fooman2011> my problem is that I don't know before calling "av_read_frame" if there are enought data for one frame or not [12:42:48 CEST] <fooman2011> If there any way to know if there are enoght data without reading them from the stream ? Or maybe there is a way to complete a previous incomplete "av_read_frame" ? [12:43:13 CEST] <fooman2011> BtbN: You know what I mean ? [12:43:32 CEST] <JEEB> the name of that function is anyways incorrect. it's not AVFrames, it's AVPackets. [12:43:42 CEST] <JEEB> and not all AVPackets are random access points [12:44:05 CEST] <fooman2011> I'm progressively write into the stream, while it is reading [12:44:24 CEST] <JEEB> I'm not 100% sure how you end up with broken data in there but I hope you're setting an IO timeout if it's a timeout problem [12:44:34 CEST] <JEEB> by default lavf http will never time out [12:44:37 CEST] <JEEB> which is maybe not what you want [12:44:56 CEST] <fooman2011> Ok let me explain the complete scenario [12:45:24 CEST] <BtbN> av_read_frame should never give you an incomplete packet and still report success [12:45:41 CEST] <JEEB> BtbN: I'd say "it depends on the format" [12:45:59 CEST] <JEEB> I wouldn't make that promise for all the readers in lavf to be honest :/ [12:46:14 CEST] <JEEB> many have alright parsing [12:46:19 CEST] <JEEB> that is true [12:49:41 CEST] <fooman2011> I'm reading data from internet and write them into a fifo pipe. During this, I have a player that read this fifo pipe. My problem is when there is internet lag, the data may be cut during several seconds, av_read_frame read incomplete data from the stream [12:50:34 CEST] <JEEB> if it's just dropped data, then you need to wait for initialization data to get passed through again [12:50:59 CEST] <fooman2011> how to wait for initialization data ? [12:51:16 CEST] <JEEB> avcodec should do that by default for a lot of formats [12:51:23 CEST] <JEEB> which audio/video formats are you using? [12:51:26 CEST] <JEEB> and which container? [12:51:41 CEST] <fooman2011> I think that i'm currently use an mp4 [12:52:16 CEST] <JEEB> ah, if that is not fragmented then the offsets might be all around the place [12:52:20 CEST] <JEEB> if you dropped data [12:52:32 CEST] <JEEB> which you can't really fix easily :P [12:52:50 CEST] <JEEB> in other words, have your reader figure out if the connection went poo-poo :P [12:53:00 CEST] <JEEB> then stop the processing if it did and re-start [12:55:15 CEST] <fooman2011> Ok so there is no way to have a kind of "av_peek_frame" that try to read but without remove data fromt he stream ? [12:55:31 CEST] <JEEB> I'm not sure what you would do with that? [12:55:45 CEST] <JEEB> like, what would the peeking help you at that point? [12:55:54 CEST] <JEEB> i might just be not understanding here, of course [12:56:23 CEST] <JEEB> also if you don't like the alternatives in libavformat itself for reading data, you can actually register your own AVIO callbacks btw [12:56:55 CEST] <JEEB> I have done that when I was much less experienced with windows IOStreams and it worked, so it shouldn't be mission impossible for you either [12:57:05 CEST] <JEEB> that way you don't need to pipe stuff etc [12:57:29 CEST] <JEEB> you have your own C functions that call whatever you want to get the data/seek/write the data [13:29:18 CEST] <fooman2011> re [13:29:23 CEST] <fooman2011> sorry I was away [13:29:34 CEST] <fooman2011> in fact i'm trying to patch omxplayer [13:29:45 CEST] <fooman2011> https://github.com/popcornmix/omxplayer/blob/master/OMXReader.cpp [13:29:57 CEST] <fooman2011> line 515 [13:30:17 CEST] <fooman2011> When there is an internet lag, then I enter into this if [13:30:53 CEST] <fooman2011> because of the interrupt_cb function so I have remove this one. [13:31:08 CEST] <furq> fooman2011: fyi you should be able to use rpi hwaccel with mpv if you build ffmpeg with --enable-mmal [13:31:23 CEST] <furq> and there's probably some stuff you need to do with mpv as well, i forget now [13:31:49 CEST] <fooman2011> mpv ? [13:32:55 CEST] <fooman2011> mmmh ok why not be i'm curious to understand why I have this problem [13:33:02 CEST] <fooman2011> be => but [13:34:04 CEST] <fooman2011> When I remove the interrupt_cb call, then omxplayer does not exit anymore, so that's a good point, but the stream goes very strange. [13:34:27 CEST] <fooman2011> No more sound, read super fast, pause, read super fast, pause, etc... [13:38:05 CEST] <fooman2011> do you know where it can comes from ? [14:36:38 CEST] <tth-bis> hello [14:37:20 CEST] <tth-bis> is there a way to grab a specific x11 window to a video file ? [14:42:41 CEST] <klaxa> not really, but with a bit of scripting you can use xwindowinfo to get info about a window (position and geometry) and then pass that to x11grab like: ffmpeg -f x11grab -s $widthx$height -i :0.0+$x_offset,$y_offset [...] [14:42:58 CEST] <klaxa> you can't move the window afterwards of course :S [14:48:51 CEST] <Nethe> Hi. Guys, have a question. My ffmpeg transcoding and encoding process are in sleep mode in ps, status D. Is here someone, who could have some idea, why is it happening? The hardware is very strong, 4x Nvidia P5000, 396G ram and Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz [14:49:17 CEST] <Nethe> As a note - I'm trying to transcode live stream from network source to network source for shaka packager. [14:50:25 CEST] <tth-bis> klaxa: ok, i give it a try [15:10:33 CEST] <Nethe> nobody? :) [15:17:08 CEST] <klaxa> well D is just I/O sleep [15:17:33 CEST] <klaxa> if any of your network streams is blocking it might get into that state? [15:19:30 CEST] <furq> is nfs involved by any chance [15:19:47 CEST] <JEEB> I would guess UDP multicast and multicast out since shaka packager takes in multicast [15:20:04 CEST] <JEEB> and most broadcasters push out streams as multicasts for you to ingest [15:20:10 CEST] <JEEB> unless it's VoD [15:30:01 CEST] <tth-bis> klaxa: "xdotool getwindowgeometry --shell $(xdotool selectwindow)" give good parsable information about a X window [15:54:38 CEST] <Fyr> guys, I'm trying to remux an m2ts into mp4, FFMPEG freezes in the end. -report option doesn't add anything meaningful. [15:54:57 CEST] <Fyr> the log file and with: [15:54:57 CEST] <Fyr> size= 29440kB time=02:13:51.35 bitrate= 30.0kbits/s speed=10.4x [15:55:32 CEST] <Fyr> the FFMPEG is still working, utilizing a core. [15:55:43 CEST] <JEEB> dunno, the cases I've done that it has worked, so whatever it is is most likely specific to that sample [15:55:56 CEST] <JEEB> I've been cutting samples from my two UHD BDs as well as just remuxing random crap when needed [15:56:06 CEST] <Fyr> is there a way to test the m2ts file? [15:57:05 CEST] <JEEB> I think the best you can do is try to decode it. also if you are doing -movflags faststart that /will/ take a while [15:57:14 CEST] <JEEB> since it will rewrite the whole file [15:57:43 CEST] <Fyr> the command is: [15:57:44 CEST] <Fyr> ffmpeg -i "bluray:F:\Downloads\Torrent\Man of Fire_[Blu-Ray]" -map 0:15 -c copy "e:\Man on Fire 2004.sup" [15:58:00 CEST] <JEEB> oh, libbluray [15:58:04 CEST] <JEEB> that adds another layer of "fun" [15:58:15 CEST] <JEEB> ok, and subtitles only [15:58:19 CEST] <JEEB> that's not mp4 :D [15:58:55 CEST] <Fyr> I just divided the full command into two to find what's wrong. [15:59:12 CEST] <JEEB> libbluray is useful but I'm not sure if there aren't issues in the wrapper in libavformat around it [15:59:21 CEST] <JEEB> so it isn't 100% the same as reading m2ts from a file [15:59:32 CEST] <JEEB> since it's actually using libbluray to do the basic IO [15:59:52 CEST] <JEEB> (it makes sense to use it to get what's in the playlists, that I 100% agree with) [16:00:05 CEST] <JEEB> just saying "remuxing an m2ts" generally means you're using the file protocol [16:00:07 CEST] <JEEB> :P [16:00:21 CEST] <JEEB> but I wouldn't be surprised if this was a problem with the "zero is not EOF" thing [16:00:59 CEST] <JEEB> I guess I could try it with a blu-ray I have locally [16:01:06 CEST] <JEEB> since I do have an FFmpeg built with libbluray enabled [16:01:20 CEST] <JEEB> but first, I need a run. I've done enough for today with HDR development :P [16:01:51 CEST] <furq> that reminds me, i should watch man on fire [16:05:44 CEST] <JEEB> right [16:05:45 CEST] <JEEB> http://up-cat.net/p/a777171e [16:05:50 CEST] <JEEB> I wonder what this returns for EOF ;) [16:06:05 CEST] <JEEB> I bet we will be finding these for a long time to come :| [16:06:27 CEST] <JEEB> and we can't revert that change because there's o9k other changes now on top of it fixing it. so you'd have to remember to revert ALL of them [16:07:35 CEST] <JEEB> * @return size of data read, -1 if error, 0 if EOF [16:07:35 CEST] <JEEB> yup [16:08:52 CEST] <JEEB> Fyr: I think I found your problem, will be sending out a patch to the mailing list [16:09:08 CEST] <Fyr> thanks [16:11:21 CEST] <JEEB> the whole fucking world uses zero for EOF, but asdf [16:11:46 CEST] <JEEB> and the original reason was "but UDP has zero byte packets! they are valid! it's not EOF!" [16:12:28 CEST] <JEEB> and instead of limiting it to UDP, the concept of 0 != was actually implemented into the whole goddamn IO framework [16:12:36 CEST] <JEEB> granted, the documentation seemed to note that already [16:12:39 CEST] <JEEB> but none of the code was doing that [16:13:06 CEST] <JEEB> so of course the person implementing it was like "the documentation already says that so I'm just fixing the implementation!" [16:15:02 CEST] <JEEB> but yea, it most likely is causing the eternal read() loop which takes a single core :P [16:15:19 CEST] <JEEB> read() returns zero as-is from libbluray, nothing fixes it to be AVERROR_EOF [16:15:46 CEST] <JEEB> also it sure takes a while to load up libbluray protocol's history, I want to see what prefix others have used for the thing [16:17:23 CEST] <JEEB> ok, not too many changes since it was added [16:17:31 CEST] <JEEB> so just lavf/bluray it is [16:19:55 CEST] <JEEB> there, patch sent to mailing list [16:20:56 CEST] <JEEB> Fyr: if you want to test locally https://github.com/jeeb/ffmpeg/commit/cc8e71f728ab037357baf0439c8a899ddcdfd… [16:21:21 CEST] <Fyr> JEEB, remuxing the m2ts without libbluray works. [16:21:35 CEST] <JEEB> yes, since the file protocol was fixed ages ago [16:21:43 CEST] <JEEB> the bluray protocol was not [16:22:20 CEST] <Fyr> guys, how do people call the programmers whose hands are attached to their asses? [16:24:00 CEST] <Fyr> handyassed? [16:24:06 CEST] <Fyr> asshanded? [16:25:15 CEST] <JEEB> Fyr: anyways it'd be nice if you could verify this fixes it [16:25:29 CEST] <JEEB> I'm pretty sure it will [16:25:32 CEST] <JEEB> but yunno :P [16:27:13 CEST] <Fyr> oh, the recompilation again. [16:27:34 CEST] <JEEB> it should be a small recompile [16:27:43 CEST] <JEEB> since it's a single line change and should only need a recompile of FFmpeg [16:27:49 CEST] <JEEB> and of those specific files [16:28:03 CEST] <JEEB> it should probably just re-compile that file + re-link libavformat and the command line tools [16:46:29 CEST] <ksj> is there a built-in function for converting an AVPacket to a byte array? I can't find anything but I want to be sure before trying another way [16:48:10 CEST] <klaxa> what about AVPacket.buf->data ? [16:48:14 CEST] <klaxa> it's uint8_t* [16:49:52 CEST] <ksj> klaxa: if I sent that byte array over a network, would I then lack some information for decoding? [16:50:17 CEST] <klaxa> most likely, yes [16:50:35 CEST] <klaxa> sounds like you want to do media streaming [16:51:40 CEST] <ksj> yes but I need to send my encoded data through apache kafka [16:52:36 CEST] <ksj> nd then decode on the other side [16:52:39 CEST] <ksj> *and [16:53:55 CEST] <klaxa> it sounds like you want custom IO and not send some AVPacket data through some network [16:54:57 CEST] <ksj> probably, it's just that I receive these as AVPackets [16:55:21 CEST] <klaxa> https://www.ffmpeg.org/doxygen/trunk/avio_reading_8c-example.html [16:56:10 CEST] <ksj> thanks klaxa I'll look into it [16:57:46 CEST] <klaxa> not sure what API you need to feed, maybe all things i said are irrelevant and your system "supports" sending AVPackets, but usually you write a packet to a stream with av_write_frame() or av_write_interleaved_frame() which takes care of correctly muxing it into the underlying container [16:58:40 CEST] <klaxa> maybe your kafka stuff knows enough about the packets to decode them, so no idea [17:02:06 CEST] <giaco> hello [17:02:44 CEST] <giaco> manual says in -vsync that "With -map you can select from which stream the timestamps should be taken. You can leave either video or audio unchanged and sync the remaining stream(s) to the unchanged one." but how? Is it an ordered based decision? [17:25:01 CEST] <JEEB> Fyr: back from my jog run. did you get to test it? [17:25:21 CEST] <Fyr> no. =( [17:25:33 CEST] <Fyr> I don't really want to start the recompilation. [17:25:47 CEST] <Fyr> I've just came from my jog run. [17:25:53 CEST] <JEEB> you only need to do FFmpeg, nothing else. and even there you don't even have to re-configure [17:26:09 CEST] <JEEB> anyways, I guess I can test it locally :P [17:26:45 CEST] <Fyr> magnet:?xt=urn:btih:b0320a574a735fa1f536f89b2f311064d45ea275&dn=Man%20of%20Fire_%5bBlu-Ray%5d&tr=http%3a%2f%2fbt2.t-ru.org%2fann%3fmagnet [17:26:52 CEST] <JEEB> I have plenty of blu-rays [17:26:56 CEST] <JEEB> and it should be the same with all [17:27:04 CEST] <JEEB> when it hits EOF from libbluray it will go into infinite loop [17:27:21 CEST] <Fyr> it's the bluray on which FFMPEG stammer. [17:27:38 CEST] <JEEB> pretty sure it's global, let me try with any I have [17:28:05 CEST] <Fyr> I've ripped and remuxed plenty of blurays. [17:28:14 CEST] <Fyr> it's the first time it didn't work. [17:45:37 CEST] <JEEB> Fyr: basically I'm decoding a blu-ray with libbluray and if it finishes it works :P [17:50:05 CEST] <JEEB> ok, it finished [17:50:13 CEST] <Fyr> (= [17:50:49 CEST] <JEEB> and I got a LGTM on the mailing list https://patchwork.ffmpeg.org/patch/8810/ [17:54:08 CEST] <JEEB> and pushed [00:00:00 CEST] --- Mon May 7 2018

1 0