Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

May 2018

1 participants
62 discussions

ffmpeg-devel.log.20180515
by burek 16 May '18

16 May '18

[00:07:38 CEST] <jkqxz> akravchenko188: Do you have code for a filter using it? [00:12:29 CEST] <durandal_1707> ubitux: read james-stein type center pixel weights for non-local means image denoising [00:17:59 CEST] <durandal_1707> i just noticed, you already found it :) [00:21:34 CEST] <akravchenko188> jkqxz: not yet. [00:22:05 CEST] <akravchenko188> jkqxz: will be ready in couple of days [00:23:05 CEST] <jamrial> jkqxz: crap, forgot to mention the ticket # [00:53:34 CEST] <atomnuker> nevcairiel: which commit broke/unsupported support for msvc 2013? [00:53:43 CEST] <atomnuker> because jkqxz would like to know [00:54:02 CEST] <nevcairiel> that still works [01:00:10 CEST] <atomnuker> was it jamrial who said it didn't? [01:00:13 CEST] <atomnuker> or ubitux [01:00:57 CEST] <nevcairiel> msvc was broken for a few days recently because of some new POSIX system functions that it didnt have, but that affected all versions and was fixed [01:17:35 CEST] <JEEB> tmm1: nice. I would still fix the program update signaling to API clients, but that's one way of handling it. will test it after I get some sleep [01:23:30 CEST] <atomnuker> okay, it was JEEB [01:23:43 CEST] <atomnuker> who said apparently we don't care about the msvc c99 conversion thing [01:25:31 CEST] <JEEB> which was for 2012 and older [01:25:41 CEST] <JEEB> and IIRC we no longer test those in FATE so that was my assumption [01:26:14 CEST] <JEEB> 2013 is when MS got trolled enough to actually update their C part [01:26:26 CEST] <JEEB> aand actually advertised FFmpeg support [01:26:42 CEST] <JEEB> (although it was semi-failing until VS2013 update 1 or 2) [01:58:28 CEST] <tmm1> JEEB: yea, i think AVProgram entries are persistent so we could add a EVENT flag there [01:59:11 CEST] <tmm1> i saw mythtv's ffmpeg fork has some hacks to detect program changes.. they just added a function pointer that gets invoked on changes [02:00:56 CEST] <jamrial> tmm1: did you take a look at the valgrind error in mpegts since 9152c1e495? [02:02:24 CEST] <tmm1> i pushed a commit earlier to fix it [02:05:20 CEST] <JEEB> tmm1: right, a callback was one thing I was thinking about but I think someone here didn't like that idea [02:05:24 CEST] <jamrial> tmm1: ah cool, thanks [02:05:35 CEST] <JEEB> and yes, I just checked that AVPrograms didn't seem to get av_free'd [02:05:52 CEST] <JEEB> the most they seem to be done is in add_pat_entry [02:06:01 CEST] <JEEB> where av_reallocp_array is used [02:06:11 CEST] <JEEB> but that's Program [02:06:14 CEST] <JEEB> not AVProgram [02:06:16 CEST] <tmm1> yea callback seems pretty hacky, i think an event flag would be ok [02:06:30 CEST] <tmm1> yea i just figured that out earlier too, program vs avprogram and only programs are cleared [02:06:54 CEST] <JEEB> yea, if it seems like AVPrograms stay around behind the same memory address then a flag in it would be OK [02:07:16 CEST] <JEEB> because a client can then at first pick the AVProgram that interests it [02:07:20 CEST] <JEEB> and then keep following it [02:19:51 CEST] <klaxa> hmm, just realized i want to configure streams per server otherwise i'd have to either check and compare ports for multiple servers or disallow it making the <streamname> part in the url pointless and also seems like an unneeded restirction, however now the config file already looks a bit more complex :S https://gist.github.com/klaxa/cbb5df840746b4bed559f25d10a3d13b [02:21:11 CEST] <klaxa> atomnuker, after having looked at the glauss readme i can see where you are coming from with suggesting lua, but don't you think it's a bit overkill? [02:22:07 CEST] <klaxa> i've been mulling over this for much longer than i should have... [02:22:35 CEST] <atomnuker> that's why we ought to do it properly [02:22:59 CEST] <atomnuker> its not an overkill, lua is a common dep nowadays, and its quite lightweight [02:23:19 CEST] <atomnuker> sure its powerful, its a programming language as well [02:24:09 CEST] <atomnuker> but when you have complex issues you shouldn't implement nih programming languages in your config files [02:24:30 CEST] <atomnuker> that's how M4 came about [02:24:55 CEST] <klaxa> do we have complex issues though? i "just" need a few settings, nothing should go deeper than 2 levels [02:25:38 CEST] <klaxa> i want to configure the bind address and port per httpd and a number of streams per httpd with a number of formats [02:26:27 CEST] <klaxa> i'll read more of the configs in your repo to get an understanding of how it would look in lua [02:28:09 CEST] <atomnuker> welp, just see how complicated ffserver configure files were: https://www.ffmpeg.org/sample.html [02:28:50 CEST] <nevcairiel> they are modelled after apache config files apparently, its really not that bad [02:28:51 CEST] <klaxa> yeah i managed to get a stream working once [02:29:13 CEST] <klaxa> but i also realized that ffserver could not *not* re-encode [02:29:47 CEST] <klaxa> that's pretty much when i looked into alternatives and couldn't really find any [02:29:49 CEST] <atomnuker> this works for a fixed amount of inputs and outputs, and I think it would be nice to be able to react to any new input streams (if allowed) and dynamically change settings [02:30:58 CEST] <klaxa> dynamically as in while the server is running, add a new stream or something? i thought about that as well [02:31:13 CEST] <klaxa> or remove a stream prematurely [02:32:31 CEST] <klaxa> hmm... not sure how the config file is involved in that, but i think you got me convinced [02:32:42 CEST] <klaxa> >rng_seed = os.time(), [02:32:53 CEST] <klaxa> oh well, i can already think of tons of uses for things like that [08:19:39 CEST] <cone-397> ffmpeg 03Vishwanath Dixit 07master:e3518821c95d: avformat/dashenc: configuring container format options [09:06:56 CEST] <durandal_1707> ubitux: so how shall we proceed with nlmeans patches? [09:21:25 CEST] <kylehyde6> Hey all! i want tohire a developer to help me in devel eit tables for ffmpeg [09:58:48 CEST] <durandal_1707> atomnuker: is your non-power of 2 fft/dct anywhere near completion? this work is very important. [10:26:51 CEST] <durandal_1707> kylehyde6: i can not understand what you have written [10:27:27 CEST] <JEEB> EIT tables are a thing in MPEG-TS [10:27:49 CEST] <JEEB> Electronic program Information Table I think? [10:54:27 CEST] <kylehyde6> durandal_1707 i need somone to devel EIT tables , a developer [10:55:10 CEST] <kylehyde6> yes ! jeeb [10:55:23 CEST] <kylehyde6> and i want to devel eit tables because ffmpeg does not insert it [12:27:54 CEST] <BtbN> enabling DMARC reporting on my domains and then sending a mail to ffmpeg-devel gets me 12 responses about DMARC violations. Nice [12:29:08 CEST] <nevcairiel> mailing lists are basically screwed with all the fancy mail validation things, since they want to send mails originating from you [12:29:27 CEST] <BtbN> that's SPF, I have that disabled [12:29:33 CEST] <BtbN> or rather in "non-enforcing" mode [12:29:55 CEST] <BtbN> It's complaining about "dkim=permerror (signature verify error: message body does not hash to bh value)" [12:30:10 CEST] <nevcairiel> it also adds its footer [12:31:50 CEST] <BtbN> That should not break dkim, since the footer is in its own MIME part, and the dkim header only applies to the first one [12:32:05 CEST] <BtbN> but ffmpeg-devel breaks them somehow. It also breaks PGP/MIME signatures that way [12:32:50 CEST] <BtbN> I feel like the mailman handling ffmpeg-devel is in need of an update? [12:44:33 CEST] <jdarnley> From what I hear, the breakage started occurring "recently", so I assumed some update borked it. [12:52:56 CEST] <BtbN> also quite possible [14:35:25 CEST] <kierank> gagandeep: any progress? [15:29:28 CEST] <gagandeep> kierank: right now reading huffman coding in finite state machines for understanding [15:29:41 CEST] <gagandeep> you were right though, tables are ok [15:29:57 CEST] <gagandeep> so either problem in entropy decoding or dequantization [15:30:41 CEST] <kierank> you don't need to understand huffman tables [15:30:47 CEST] <kierank> you just need to check values match and where they don't [15:30:54 CEST] <kierank> 99% dequantisation [15:31:03 CEST] <kierank> the thing about huffman coding is that it either works or it doesn't [15:33:48 CEST] <gagandeep> also, in the comparison i did yesterday, for a range of pixel ffmpeg cfhd gave values like 5 then followed by some zeroes and then -5, but in testcfhd the same pixels were all 5 [15:34:31 CEST] <kierank> -5? [15:34:32 CEST] <kierank> pixel? [15:34:34 CEST] <kierank> impossible [15:34:37 CEST] <kierank> can't have negative pixels [15:35:20 CEST] <gagandeep> probably a problem in printf type [15:35:33 CEST] <gagandeep> but only subband 8 gave different values [15:36:06 CEST] <gagandeep> kierank: not pixels but transform values [15:36:37 CEST] <gagandeep> after that inverse is performed, my bad i didn't mean pixels here but dequantized buffer before inverse [19:13:15 CEST] <durandal_1707> atomnuker: so? [19:14:51 CEST] <atomnuker> durandal_1707: yes, I hear you, I'm working on it, I know its important (for the 3d denoiser, right?) [19:16:27 CEST] <durandal_1707> and siren [19:18:31 CEST] <atomnuker> right [19:19:20 CEST] <atomnuker> do you know of any place in the code that calls permute, does something to the coefficients and then calls to perform the transform in the standard power of two fft? [19:19:32 CEST] <atomnuker> I'm trying to figure out if I need to leave an API for that or not [19:20:11 CEST] <atomnuker> and I'm trying to figure out what to do in the case of fft vs mdct, since ffts are performed in-place but mdcts are not, and I'd like to not have 2 separate functions to do those [19:21:44 CEST] <atomnuker> right now there's a single function av_ft_tx(ctx, dst, src), where src can be NULL if the transform is in-place [19:22:45 CEST] <atomnuker> the function takes in a void pointer to a buffer since I don't want to have multiple functions for double FFTs, RDFts, or integer FFTs [19:23:42 CEST] <durandal_1707> i doubt anything use permute the way you described [19:26:35 CEST] <atomnuker> I'll keep that merged into the tx function then [20:13:55 CEST] <JEEB> durandal_1707: btw were you ever at VDD? [20:20:21 CEST] <atomnuker> nope [20:22:10 CEST] <JEEB> unfortunate [20:22:23 CEST] <atomnuker> yep [20:48:22 CEST] <cone-174> ffmpeg 03Aman Gupta 07master:64bf915cd851: avformat/mpegts: fix incorrect indentation [21:11:11 CEST] <tmm1> can someone add a sample to fate-suite for me? [21:12:01 CEST] <tmm1> >curl -o fate-suite/mpegts/pmtchange.ts http://0x0.st/secA.ts [21:12:39 CEST] <JEEB> wonder if it was jamrial or michaelni who has access to the suite [21:23:55 CEST] <jamrial> tmm1: done [21:25:17 CEST] <tmm1> jamrial: thanks! [21:35:21 CEST] <atomnuker> heh, someone just linked an explosives manual on #ffmpeg [21:40:01 CEST] <jdarnley> oooh forbidden knowledge [21:49:16 CEST] <wm4> what do they want to blow up [22:41:26 CEST] <akravchenko188> jkqxz: hi. I am implementing amf converter/scaler. I am new in FFmpeg, if you don't mind I will ask a few questions here, or better to write in forum? [22:41:58 CEST] <atomnuker> could you just map amf frames to vulkan and opencl? [22:42:08 CEST] <atomnuker> and use a scaler that's already implemented [22:44:01 CEST] <jkqxz> akravchenko188: Generally here is much easier for discussion, so sure. [22:46:22 CEST] <jkqxz> atomnuker: I meant that you should make an explicit test for the declaration-as-clause-1-of-for-loops thing. Like, actually try to compile it in configure and reject the compiler if it fails. [22:46:44 CEST] <jkqxz> Anything else leaves the danger of people managing to get further and then complaining that some files don't compile. [22:49:41 CEST] <akravchenko188> 1) amf converter/scaler I am going to integrate is hw accelerated colorspace converter;memory type converter(from/to DX9/DX11/OpenCL + Vulkan in coming);scaler;crop. what name to use? vf_scaler_amf/vf_converter_amf [22:50:39 CEST] <jkqxz> What is the actual dependency on AMF in it? [22:51:57 CEST] <akravchenko188> this component implemented in AMF [22:52:59 CEST] <akravchenko188> to use in in FFmpeg I need to implement filter which wraps is and reuses hwcontext_amf [22:53:26 CEST] <jkqxz> So the input is a DX11 texture (or one of the others), that gets mapped in to AMF, some AMF component operates on it, the output gets mapped to DX11 again and sent to the output? [22:54:16 CEST] <akravchenko188> right, but input memory type can be different then output memory type [22:54:59 CEST] <jkqxz> How will that work? Do you need AMF -> DX11/others device derivation as well? [22:56:28 CEST] <akravchenko188> yes [22:57:16 CEST] <jkqxz> Hmm, that probably means we want to distinguish device_derive_from and device_derive_to (like map_from and map_to, etc.). [22:58:12 CEST] <jkqxz> (Given that, it may be more straightforward to start with input matching output.) [22:59:12 CEST] <jkqxz> But coming back to your question, if you do both scaling and colour conversion then it should probably be called vf_scale_amf and offer at least the same interface as the other vf_scale(_foo) filters. [22:59:30 CEST] <jkqxz> It's not a problem to do more on top of that with extra private options. [22:59:55 CEST] <akravchenko188> ok, lets have vf_scale_amf name [23:01:22 CEST] <atomnuker> jkqxz: as I said, I am unaware of any compiler not supporting this, not even a 14 year old gcc version which tests on fate, apart from msvc [23:01:45 CEST] <atomnuker> so I'd like to take my chances and if someone does report an issue I'll make a test [23:02:23 CEST] <jkqxz> Did you ask on the user mailing list for anyone? [23:02:27 CEST] <atomnuker> (besides, another compile test will likely make windows people angrier as it would add a few tens of seconds to configure) [23:02:36 CEST] <atomnuker> jkqxz: ask what? [23:04:18 CEST] <jkqxz> Whether anyone uses funny compilers which might run into problems if the coding rules are changes. [23:05:44 CEST] <atomnuker> I think you're overthinking this [23:05:50 CEST] <akravchenko188> jkqxz: I have read code of QSV scaler, there is AV_PIX_FMT_QSV pixel format. I think here we dont need AV_PIX_FMT_AMF, we just need to create frame contexts of OpenCL and DX11 types in scaler amf [23:06:30 CEST] <cone-174> ffmpeg 03Marton Balint 07master:2dbe936bf7f9: avformat/webm_chunk: always use a static buffer for get_chunk_filename [23:06:31 CEST] <cone-174> ffmpeg 03Marton Balint 07master:1b2471039b23: avutil/hwcontext_cuda: fix YUV420P cuda_get_buffer [23:08:13 CEST] <akravchenko188> jkqxz: is there way to reuse hwcontext_amf created earlier in pipeline? for exampe we have decoder -> amfscaler->some opencl filters -> amfscaler -> amf_encoder [23:09:11 CEST] <akravchenko188> or any other contexts [23:09:39 CEST] <jkqxz> If the input device is derived from an AMF device then derivation will recover the original device. [23:12:04 CEST] <akravchenko188> ok, thanks. I will read hwcontext machinery more detaily [23:12:54 CEST] <jkqxz> If you have derivation the other way then you can do e.g. "-init_hw_device vaapi=a:some_args -init_hw_device d3d11va=d@a -hwaccel_device d -i ... -vf hwmap=derive_device=amf,..." and the hwmap instance will recover the original AMF device. [23:13:30 CEST] <jkqxz> Oops, s/vaapi/amf/. (This can be useful for the libmfx + opencl + vaapi/d3d cases.) [23:15:01 CEST] <akravchenko188> ok, I think I got idea [23:17:16 CEST] <akravchenko188> jkqxz: are you going to push patch with initial hwcontext_amf? or there are some issues? [23:17:53 CEST] <jkqxz> I don't think it should be pushed without an actual use-case? [23:17:53 CEST] <cone-174> ffmpeg 03Marton Balint 07release/4.0:7931e01540a1: avformat/webm_chunk: always use a static buffer for get_chunk_filename [23:18:33 CEST] <jkqxz> Remember that you are defining external API here, it can't be changed once applied. [23:21:46 CEST] <cone-174> ffmpeg 03Mark Thompson 07master:136260eb88e8: hwcontext: Do not call device_init again when deriving an existing device [23:21:47 CEST] <cone-174> ffmpeg 03Mark Thompson 07master:989c5a84acff: lavu/Makefile: Fix alignment and ordering [23:24:02 CEST] <akravchenko188> jkqxz: ok, no problem, we can postpone it until scaler is ready. I just wanted to make sure there's nothing there which breaks main concepts [23:27:51 CEST] <BBB> atomnuker: wheres your av1 decoder again? [00:00:00 CEST] --- Wed May 16 2018

1 0

ffmpeg.log.20180515
by burek 16 May '18

16 May '18

[02:31:17 CEST] <FishPencil> Is there a way to disable the linking of CoreMedia on macOS? It seems to be included regardless of the configure flags if it's available [06:20:39 CEST] <Pandela> Aye quick question. Are there any sdl/sdl2 libraries I need installed on windows 7 for ffplay or ffmpeg sdl2 output to work? If I try to play any file with ffplay or use -f sdl; everything immediately crashes.. [06:23:16 CEST] <Pandela> This is both with ffmpeg 4.0 stable, and the current nightly build [06:34:01 CEST] <Pandela> Perhaps some framework I don't have? Don't know the last time this machine was updated actually. [07:33:59 CEST] <zumba_addict> can ffmpeg receive mjpeg from an external camera via udp? [07:43:22 CEST] <Mavrik> IIRC yeah [07:44:04 CEST] <zumba_addict> i got it working [07:44:15 CEST] <zumba_addict> -i rtsp://..... [07:44:26 CEST] <zumba_addict> i'll try it with udp://... later [08:20:08 CEST] <cloud_> i got some problem when i using ffmpeg [08:20:45 CEST] <cloud_> is anybody here? [10:54:06 CEST] <ralphcor> Hi, I've a h264 that's 698x540 and I'm guessing that's why the TV won't play it. I'm intending to use ffmpeg's pad filter to make it a nice 4:3 720x540. I'm aware jpegtran(1) can manipulate a JPEG without loss and, knowing little about video formats, was wondering if a pad can work in a similar manner, or at least damaging only peripheral `blocks' at the sides. [10:55:34 CEST] <durandal_1707> ralphcor: filters need transcoding [11:05:53 CEST] <ralphcor> Ah, OK. I was seeing video ones like mpdecimate (drop similar frames) and thought some might not lossily transcode. [11:06:47 CEST] <durandal_1707> ralphcor: transcoding IS lossy unless you use lossless encoder [11:25:56 CEST] <ralphcor> OK, put another way: `some filters change frame properties but not frame contents', e.g. fps and setpts. [11:26:19 CEST] <ralphcor> I see your point WRT the definition of transcode. [11:26:49 CEST] <durandal_1707> ralphcor: yes, lossy trascoding is lossy process [12:22:11 CEST] <mort> Hey, I'm trying to cross-compile ffmpeg for aarch64. I want to enable the v4l2-based encoder and decoder, but adding '--enable-libv4l2' says that libv4l2 wasn't found using pkg-config. How can I cross compile with libv4l2? [12:22:31 CEST] <mort> I can steal libv4l2.so from the target, but how do I make the configure script find it? [12:23:00 CEST] <sfan5> steal the associated .pc file too [12:24:19 CEST] <mort> there doesn't seem to be a v4l2 .pc-file on that system [12:25:27 CEST] <mort> I suppose I could write my own. Does the configure script look in the host system's place for .pc files even when cross compiling? I can't find any in /usr/aarch64-linux-gnu [12:26:33 CEST] <jkqxz> libv4l2 isn't related to the v4l2m2m codecs. [12:27:27 CEST] <mort> Is v4l2-m2m enabled by default then? It was the only option other than --disable-v4l2-m2m I found related to v4l2 in './configure --help' [12:28:01 CEST] <jkqxz> I think it's autodetected. See if it appears in config.h. [12:34:41 CEST] <mort> it seems to be enabled by default yes [15:21:24 CEST] <baco> Hi, I am not being able to save into WebM format videos with codec AV1, I continuously receive the message "[webm @ ] Only VP8 or VP9 video and Vorbis or Opus audio and WebVTT subtitles are supported for WebM." but saving into WebM should be vialable according to AOM [15:39:57 CEST] <pgorley> baco: it's most likely not yet implemented in ffmpeg [16:52:57 CEST] <mort> What's the difference between an avframe's buf array and data array? av_frame_alloc and av_image_alloc allocates data and not buf, but the AVCodec I'm using segfaults because it uses buf[0], which is a null pointer [16:56:42 CEST] <atomnuker> buf[] contain refcounting structures, if they're missing then the frame is not refcounted, which can cause issues if you feed it into code which needs refcounted frames [16:57:18 CEST] <mort> I see [17:00:07 CEST] <mort> atomnuker: how do I get a refcounted frame? I'm using av_frame_alloc, which the encoding/decoding example code is using too [17:00:45 CEST] <mort> actually no, that uses avcodec_alloc_frame [17:05:01 CEST] <zerodefect> Using the C-API whcih I'm playing around with in my spare time. I've created a simple graph using the overlay filter. I note that when I feed the AVFrames in, the AVFrame output data address does not match the input AVFrame of the 'main' link. That surprised me a bit because I've set the 'main' frame to writable and setting the 'AV_BUFFERSRC_FLAG_KEEP_REF' flag when adding the frame to the [17:05:01 CEST] <zerodefect> graph. [17:19:48 CEST] <djk> trying to compile local and having an issue with aom "error: 'AV1_COMMON {aka struct AV1Common}' has no member named 'enhancement_layers_cnt'" [17:28:40 CEST] <kepstin> djk: well, that's just a mismatch between the libaom version and ffmpeg version. expected since libaom is still under heavy development. if it doesn't work with master git versions of both, well, patches welcome? :/ [17:29:51 CEST] <kepstin> or is that just a build error within libaom itself? [17:34:18 CEST] <djk> libaom build error and ffmpeg [17:36:17 CEST] <kepstin> ... which one? are you getting that error when building libaom, or are you getting it when building ffmpeg? [17:36:33 CEST] <djk> that error is libaom [17:37:00 CEST] <kepstin> either way i guess the answer is the same, either submit a patch upstream or wait for someone else to fix it :/ [17:37:15 CEST] <kepstin> (and report libaom build errors to them, not to ffmpeg channel) [17:42:12 CEST] <djk> kepstin: thank you I will try to let them know [17:43:46 CEST] <mort> Is there some example code showing encoding with the new API? (i.e send_frame and receive_packet instead of encode_video2) [17:54:35 CEST] <mort> it would've been really nice if https://ffmpeg.org/doxygen/trunk/encoding-example_8c-source.html had been updated to reflect the new API when the API changed [18:09:41 CEST] <duffolonious> does 2.8 still get security updates? [18:13:55 CEST] <durandal_1707> probably no [18:14:49 CEST] <durandal_1707> actually 2.8.14 is latest one [18:15:54 CEST] <duffolonious> yeah, with a February 18th, 2018 release - https://github.com/FFmpeg/FFmpeg/releases/tag/n2.8.14 [19:03:00 CEST] <GamleGaz> how do I set a custom frame->nb_samples? I tried setting the frame->nb_samples along with audio_ctx->frame_size but this produces glitchy audio, jumping in and out again, are there anything else I must do? [19:04:03 CEST] <JEEB> audio decoders generally output frames of a specific size that they are coded in, so you will have to either cut yourself, or use libavfilter to cut stuff in there [19:04:24 CEST] <GamleGaz> I meant for encoding [19:04:41 CEST] <JEEB> very few audio encoders support arbitrary frame sizes [19:04:56 CEST] <atomnuker> yep, they signal what you need to send via avctx->frame_size [19:05:18 CEST] <atomnuker> there's a fifo to buffer audio samples until you have enough [19:05:25 CEST] <JEEB> yea, right. that was a thing [20:25:28 CEST] <Jexzew> how to add a photo as a cover for a video file? [20:26:11 CEST] <BtbN> "cover for a video file"? [20:26:39 CEST] <Jexzew> yes. it work fine for audio files but not with video [20:27:15 CEST] <Jexzew> like an album cover [20:27:54 CEST] <JEEB> I don't think that's standardized in any way [20:28:12 CEST] <BtbN> videos don't have that, as they have pictures on their own [20:28:36 CEST] <kepstin> usually that's completely up to the file manager, they'll grab a frame from somewhere in the video (sometimes first frame, sometimes seek partway through) [20:28:49 CEST] <JEEB> I know some things add an extra track or maybe even not a track but an attachment [20:28:59 CEST] <JEEB> but yes, a lot of it is runtime (explorer.exe plugins etc) [20:34:05 CEST] <TheAMM> I've only seen mp4s with a cover file, never made any [20:34:34 CEST] <TheAMM> Windows has native support for the mp4 cover file though [20:34:42 CEST] <Jexzew> it exist but still a mystery task [20:35:06 CEST] <TheAMM> I'd expect mkv and webm teeechnically would support a cover file ala flac and ogg album art [20:35:31 CEST] <TheAMM> But that's technically. [20:36:16 CEST] <Jexzew> perhaps it can be done if ffmpeg not treating the photo as video stream [20:37:59 CEST] <TheAMM> I wonder if it's an id3 tag [20:38:15 CEST] <TheAMM> There really is little technical word in my google results [20:38:21 CEST] <TheAMM> But some people use "mp3tag" [20:39:07 CEST] <kepstin> you can, technically, throw an id3 tag on the end of pretty much anything, but that's a pretty horrible hack even if it does work. [20:39:30 CEST] <TheAMM> That's why I wonder if it's id3 [20:39:33 CEST] <kepstin> I would expect for mp4 files there's some specific atom that apple uses for cover images in itunes [20:39:46 CEST] <Jexzew> what about m4a? is it ID3? [20:40:13 CEST] <kepstin> no, mp4 has native tagging support (although it's poorly defined, it's pretty much "try to copy what itunes does") [20:40:34 CEST] <TheAMM> VLC seems to be able to tag mp4 metadata [20:42:17 CEST] <TheAMM> And yeah ffmpeg can at least tag the title [20:42:32 CEST] <TheAMM> Album/cover art, I wouldn't hold my breath [20:43:25 CEST] <TheAMM> Last I checked, ffmpeg can't tag ogg with albumart [20:43:33 CEST] <TheAMM> Oh, but that reminds me [20:43:41 CEST] <TheAMM> mutagen might support mp4, lessee [20:44:15 CEST] <BtbN> m4a is mp4. [20:44:26 CEST] <TheAMM> Yep, mutagen does support mp4 [20:44:35 CEST] <TheAMM> And covers as well [20:44:44 CEST] <TheAMM> https://mutagen.readthedocs.io/en/latest/api/mp4.html#mutagen.mp4.MP4Cover [20:44:50 CEST] <Jexzew> hey suddenly i found the answer [20:44:53 CEST] <kepstin> I've never tried using mutagen to put cover art into video mp4 files, but yeah, i guess it could work? :) [20:45:03 CEST] <TheAMM> I expect it would [20:45:40 CEST] <TheAMM> I wrote myself a script to encode opus with album art, by extracting (or specifying) the cover file, encoding with ffmpeg and then using mutagen to add the image [20:46:20 CEST] <jpabq> Given an AVFrame, is there a way of determining what streamid / PID it is part of? I am working on frames from a transport stream. [20:46:49 CEST] <djk> I have an rtmp stream to facebook with null audio that I would like to modify and add streaming of several audio sources. Still a novice on all the options and how they work. Here is what I have currently https://paste.ofcode.org/EYfNFNbsM8KWsnaTZKb8dr [20:47:02 CEST] <Jexzew> MP4 container + ID3 Tag with APIC frame [20:47:17 CEST] <TheAMM> Hey I was right twice [20:48:21 CEST] <atomnuker> TheAMM: you can add them, no problem [20:48:29 CEST] <atomnuker> sorry, I meant Jexzew [20:48:33 CEST] <atomnuker> to both mp4 and mkv [20:48:34 CEST] <kepstin> jpabq: no, avframes don't store any reference back to a stream. you should just remember which stream you got the frame from and store them separately or tag them somehow yourself. [20:48:49 CEST] <atomnuker> its just a secondary video stream with the cover art disposition added (and a different title) [20:48:52 CEST] <JEEB> jpabq: no. only AVPackets have a stream index [20:49:30 CEST] <JEEB> so you have to keep a handle on where the video or audio or subtitle frame came from if you need to know after-the-fact [20:49:43 CEST] <jpabq> kepstin: okay.... I am trying to do some manipulation in a filter. From within the filter, I have not been able to figure out how to access that info. [20:51:04 CEST] <Jexzew> alternatives to ID3? [20:51:09 CEST] <kepstin> jpabq: the thing that knows what stream is going into a filter is the code that sets up the filter chain. If you need that info in a filter, maybe pass it as a filter parameter? [20:51:42 CEST] <jpabq> kepstin: that sounds like the best option. Thanks. Thank you too, JEEB. [20:52:51 CEST] <Jexzew> native video tags? [20:53:10 CEST] <furq> mp4 has its own metadata [20:53:12 CEST] <furq> use that [20:53:21 CEST] <furq> also you can add album art to m4a with ffmpeg iirc [20:56:24 CEST] <Jexzew> what is it [20:56:40 CEST] <Jexzew> how to [20:57:34 CEST] <furq> -i foo.m4a -i bar.png -c copy -disposition:v attached_pic -f mp4 baz.m4a [20:57:50 CEST] <furq> for some reason you need -f mp4, apparently the ipod muxer doesn't support it [20:59:19 CEST] <Jexzew> it works for video? [20:59:28 CEST] <furq> ? [20:59:42 CEST] <Jexzew> m4a = audio [20:59:47 CEST] <Jexzew> mp4 = video [20:59:52 CEST] <furq> they're the same format [21:01:07 CEST] <Jexzew> in my case, the pic became a video stream if it muxed with video files (video audio stream) [21:01:30 CEST] <furq> that's how ffmpeg displays it, yeah [21:01:34 CEST] <furq> does it actually work in your music player [21:01:45 CEST] <Jexzew> no [21:02:07 CEST] <furq> shrug [21:02:10 CEST] <furq> https://trac.ffmpeg.org/ticket/2798 [21:02:12 CEST] <furq> should work [21:02:17 CEST] <Jexzew> not in file manager too [21:02:18 CEST] <furq> i guess you need a recent ffmpeg [21:04:18 CEST] <Jexzew> ticket still not solved [21:04:49 CEST] <Jexzew> also not showed up as thumbnail [21:11:15 CEST] <Jexzew> know how to edit ID3 frame? [21:15:18 CEST] <jpabq> kepstin: JEEB: It does no look like AVOption supports variable # of arguments. Is that correct? If so, I will need to pass the PIDs in as a string and parse them out of that. [21:16:25 CEST] <thresh> can someone explain to me why the bsymbolic flag as specified in https://ffmpeg.org/platform.html#Advanced-linking-configuration is needed? [21:20:00 CEST] <JEEB> had to scroll a bit of https://flameeyes.blog/2012/10/07/symbolism-and-elf-files-or-what-does-bsym… to figure out what that is [21:20:38 CEST] <JEEB> "What they do is duplicate the GOT entries for the symbols that are both called and defined in a shared object: the loader points to one, but the object itself points to the other. This way, itll always call its own copy. An almost identical solution is applied, just at compile-time rather than link-time, when you use protected visibility (instead of default or hidden)." [21:20:50 CEST] <JEEB> lessee when that recommendation originally got there [21:20:54 CEST] <Jexzew> ID3 implementations i use does add attached picture but not as thumbnail [21:21:05 CEST] <thresh> yeah but I don't see protected visibility in fft.o for ff_cos_32 (which I have issue with) [21:21:14 CEST] <thresh> but then again I'm not very smart [21:22:03 CEST] <JEEB> yea, I think that's to work around not having protected visibility [21:22:09 CEST] <JEEB> I just got git blame open [21:22:36 CEST] <Jexzew> hmm need to fork ffmpeg [21:22:41 CEST] <JEEB> ok, so it was by andrew keiley and commited into tree by koda [21:23:03 CEST] <JEEB> thresh: it was 2014 though so koda might not remember too well. you can always try to refresh his memory ;) [21:23:22 CEST] <thresh> ya [21:23:41 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=33a7b453a8e1f090c694ea4f36… [21:23:47 CEST] <JEEB> that's the relevant commit [21:24:03 CEST] <thresh> yeah I've seen it too :-) [21:24:12 CEST] <djk> how do I specific multiple windows playback devices for audio input to stream out rtmp? [21:24:25 CEST] <thresh> I'm wonder what actual tech/design choice lead to that being needed [21:24:42 CEST] <thresh> I don't see a lot of libraries requiring that [21:32:03 CEST] <kepstin> djk: i think you'd need to have a separate input for each audio source (use filters or whatever to combine them) [21:33:45 CEST] <Jexzew> https://archive.org/download/Mujahideen_Explosives_Handbook/Mujahideen_Expl… [21:34:05 CEST] <djk> real novice here so what would be the syntax? [21:34:55 CEST] <djk> This is what I have but it uses a null device for no audio https://paste.ofcode.org/EYfNFNbsM8KWsnaTZKb8dr [22:51:04 CEST] <exastiken> Hi, I'm having trouble doing a debug compile of ffmpeg for callgrind with x265 also debug compiled. It keeps hiding the ffmpeg function names for functions inside the ffmpeg object. [22:51:19 CEST] <exastiken> functions inside x265 are fine however. [22:51:47 CEST] <JEEB> --disable-stripping in configure [22:52:02 CEST] <JEEB> or if you are using the command line app, ffmpeg_g [22:52:14 CEST] <JEEB> (although in case of disable-stripping ffmpeg_g = ffmpeg [22:55:40 CEST] <exastiken> I have used ffmpeg_g and disable-stripping [22:58:23 CEST] <kepstin> make sure you're running the newly built ffmpeg and not another copy, e.g. system version? [22:58:42 CEST] <exastiken> yep, newly built ffmpeg [22:58:57 CEST] <kepstin> (although this should be the case with ffmpeg_g, that won't ever get installed) [23:13:33 CEST] <JEEB> dunno, it gives me debug symbols just fine if I don't strip :P [00:00:00 CEST] --- Wed May 16 2018

1 0

ffmpeg-devel.log.20180514
by burek 15 May '18

15 May '18

[05:08:20 CEST] <cone-704> ffmpeg 03Michael Niedermayer 07master:62f07825ba11: avcodec/vp3: Check that there will be sufficient input for the coded fragments in unpack_superblocks() [06:51:30 CEST] <cone-704> ffmpeg 03Karthick Jeyapal 07master:c76a6c93bfc3: avformat/dashenc: Add documentation for http method option [11:09:45 CEST] <durandal_1707> all developement appears dead [11:38:24 CEST] <cone-596> ffmpeg 03Tomas Härdin 07master:10ed9f2b1293: Add IRC nicknames [13:55:58 CEST] <BBB> does anyone agree it would be useful to know *why* ossfuzz runs out of diskspace wtih the iterate api? or is that just me? [14:03:53 CEST] <JEEB> yes, be it ossfuzz's fault or a current feature of the iteration API [14:04:02 CEST] <JEEB> it would be a NiceToKnow thing [14:05:13 CEST] <wbs> JEEB: it has been mentioned multiple times in discussions around the new iterate api [14:05:42 CEST] <JEEB> well BBB brought it up like the details aren't known [14:05:42 CEST] <wbs> previously, you could build a full libavcodec with everything, but when statically linking, if you don't call the avcodec_register() function, you can just link in the single codec you wanted to use [14:06:29 CEST] <wbs> now with the new iterate api, linking in a single codec with static linking out of a full build won't work and you'll end up linking in every single codec [14:06:31 CEST] <JEEB> and now they're all there linked which of course raises some space requirements [14:06:50 CEST] <BBB> so doesnt that mean ossfuzz should use disable-everything --enable-codec=bla? [14:06:59 CEST] <BBB> or am I totally misunderstanding things here? [14:07:06 CEST] <wbs> no, that's probably the right thing to do [14:07:16 CEST] <BBB> I also wasnt aware hd space was expensive [14:07:28 CEST] <durandal_1707> they are lazy, they do not want to do the right thing [14:07:36 CEST] <nevcairiel> its probably to simplify the setup, they can build all the codecs in one go and then just link the ones they want - at least thats how it used to work [14:07:43 CEST] <BBB> I mean I probably sound like an ass, but Ive always been of the opinion that a test build should be as identical as possible to the prod build [14:08:32 CEST] <BBB> anyway, tnx for explaining, thats all I needed to know, so its not actually a bug in ffmpeg or anything, its just a cost thing on their end [14:09:12 CEST] <BtbN> That can't be more than 100MB extra or so. Or does that multiply a lot with the fuzzer? [14:09:32 CEST] <wbs> I think it does one build per codec [14:09:48 CEST] <durandal_1707> what!!! [14:13:55 CEST] <JEEB> well, that minimizes code [14:14:10 CEST] <wbs> this is all in the normal code in git master already, do a "git grep target_dec", you can do e.g. "make target_dec_aac_fuzzer" [14:44:06 CEST] <Compn> annoying email worm finally found a correct email to spoof to the list [15:41:07 CEST] <durandal_1707> atomnuker: at what percentage is your fft/dct ? [15:41:26 CEST] <durandal_1707> ubitux: are you alive? [15:41:45 CEST] <ubitux> durandal_1707: yeah sorry, i'll look at your patch later today [15:41:55 CEST] <ubitux> patches* [15:46:36 CEST] <klaxa> ok, so first on my list is having a configuration file by the end of the week, i think we determined that .ini should be good enough for the things i want to configure, here is what i think a sample configuration could look like: https://gist.github.com/klaxa/44ae10accbbb2feef3ffd043d60fdf57 [15:47:30 CEST] <klaxa> since ini is rather simple to parse, should i just parse it myself or is there a small library i should take a look at? [15:50:45 CEST] <JEEB> probably I'd recommend not NIH'ing parsing of any config file format [15:51:05 CEST] <JEEB> I only remember a library for JSON, json-c (pkg-config 'json'), though [15:51:12 CEST] <JEEB> since that was what we used at my previous place [15:52:12 CEST] <JEEB> https://github.com/01org/murphy/blob/master/src/common/json.c [15:52:33 CEST] <JEEB> I didn't code any of this I think, but just for reference should it ever become useful [15:53:38 CEST] <klaxa> i've used json-c for another project before [15:54:07 CEST] <JEEB> did it drive you insane? [15:54:09 CEST] <klaxa> hmm... json is basically as simple to write as ini [15:54:17 CEST] <klaxa> not at all [15:54:28 CEST] <klaxa> my jsons were about as simple as i see them becoming here [15:54:34 CEST] <JEEB> :) [15:54:51 CEST] <klaxa> and json can even work with lists (for the format field) so it has some benefits over ini [15:54:58 CEST] <JEEB> yup [15:55:24 CEST] <JEEB> it seems to be the go-to thing for various configuration bits in various places due to its web origins and relative readability [15:56:06 CEST] <klaxa> true, the server even already logs in json, i think json it is [16:00:24 CEST] <klaxa> ok, updated with json https://gist.github.com/klaxa/44ae10accbbb2feef3ffd043d60fdf57 i'm wondering if i'm missing something, but especially with json and when using json-c it should be pretty easy to add things later on [16:03:19 CEST] <durandal_1707> adding uneeded depedencies is considered harmful for project [16:04:23 CEST] <klaxa> NIH'ing things is also considered harmful, which one is it? :) [16:04:58 CEST] <cone-242> ffmpeg 03Paul B Mahol 07master:e3a697eda3b7: avfilter/vf_amplify: check if array is availabe before using it [16:04:58 CEST] <cone-242> ffmpeg 03Paul B Mahol 07master:80b474875e72: avfilter/vf_srcnn: use function to get number of threads [16:05:09 CEST] <JEEB> It's a stand-alone application that might as well not be in the FFmpeg repo. So its needs should be considered. So if he already found usefulness in JSON's typing with things like arrays, then so be it [16:05:27 CEST] <JEEB> giving vague comments about things does not help, and it's not an ffmpeg.c dependency anyways. [16:05:51 CEST] <JEEB> and to be honest, NIH'ing JSON output in ffprobe.c was borderline [16:05:56 CEST] <JEEB> at least output is simpler than parsing [16:06:26 CEST] <durandal_1707> just implement stupid parsing configuration file imho [16:07:18 CEST] <gagandeep> kierank: i have found the problem with the deinterlacing, its dequantization [16:07:33 CEST] <kierank> gagandeep: ah good [16:07:46 CEST] <gagandeep> the subband 7, 8, 9 [16:07:59 CEST] <gagandeep> they have very large difference in values [16:08:37 CEST] <gagandeep> i was skeptical before jumping in p frames as i was not able to figure out deinterlacing so i took some time in it [16:08:55 CEST] <gagandeep> it will need to do something with fsm and codebook to fix it [16:09:43 CEST] <JEEB> durandal_1707: alright. you've got your opinion, klaxa's got his opinion, and most likely klaxa's mentor has an opinion. at some point it is going to get reviewed and then it will be found out how to proceed. we're all cool. [16:10:36 CEST] <gagandeep> kierank: how do i go about codebook and dequantization [16:10:40 CEST] <durandal_1707> if ffserver is separate project i do not care [16:10:55 CEST] <kierank> gagandeep: codebook is correct i think [16:11:15 CEST] <kierank> dequant maybe wrong [16:11:40 CEST] <gagandeep> kierank: i was also looking into dequant before in cineform but now i will need to see it seriously [16:12:49 CEST] <gagandeep> ok, now i can see p frames without being afraid of why interlace didn't work even after tracing the whole function [16:16:43 CEST] <gagandeep> kierank: but i am seeing only subband 8 having different values, you sure this is not a problem with tables? though i don't know how fsm is being used for dequant properly right now [16:17:41 CEST] <gagandeep> i mean subband 7 and 9 have very minor variation but subband 8 has large value variations for the same pixel when compared to testcfhd [16:18:29 CEST] <gagandeep> oh no, subband 9 is also messed up [16:24:35 CEST] <kierank> ah [16:24:43 CEST] <kierank> must be dequant, I doubt the tables are wrong [16:39:40 CEST] <atomnuker> klaxa: no ini, use lua [16:39:49 CEST] <atomnuker> no json either, use lua [16:39:57 CEST] <atomnuker> I'll give you some code to do the parsing [16:44:02 CEST] <atomnuker> klaxa: https://github.com/atomnuker/glauss/blob/master/input/parser.c#L753 [16:44:37 CEST] <atomnuker> and here is how you read a table of settings after init - https://github.com/atomnuker/glauss/blob/master/input/parser.c#L964 [16:47:54 CEST] <atomnuker> let me repeat - ffserver or in fact pretty much every project needs a script-like config file [16:48:05 CEST] <atomnuker> have you seen the insane lengths people go to have custom behaviour? [16:48:36 CEST] <atomnuker> if you wanted to have custom functions in json what would you do? [16:48:48 CEST] <atomnuker> wrap C code in strings and pass them off as values? [16:50:18 CEST] <JEEB> sure, I was going to also say that the config files were lua in that project I linked, but I had no idea what the requirements were in this case [16:50:55 CEST] <JEEB> if INI was being discussed then at least JSON would have been more typed [16:59:18 CEST] <atomnuker> lua config files look something like this - https://github.com/atomnuker/glauss/blob/master/DOCS/examples/fluid.lua#L2 [17:00:28 CEST] <wm4> lua is idiotic for config files [17:00:41 CEST] <JEEB> some people really like it [17:00:47 CEST] <JEEB> because then you can write a window manager in lua [17:00:51 CEST] <JEEB> (which I was developing) [17:01:10 CEST] <JEEB> but it really depends on the requirements [17:02:16 CEST] <atomnuker> its perfect for config files, its what it was designed for, and its a million times more readable than json [17:04:42 CEST] <sfan5> lua was designed as a programming language, not a config file syntax [17:05:12 CEST] <sfan5> sure, using it for configs matches the "embeddable" aspect. other than that, not so much [17:05:12 CEST] <iive> i like the lua config file idea/example [17:06:04 CEST] <iive> sfan5, i think the idea is that people won't have to write their own scripts to configure ffserver, they will write them directly in lua [17:07:21 CEST] <sfan5> ah, using lua does make sense in that context [17:11:30 CEST] <wm4> atomnuker: that lua example is also a subset of extended json [17:11:48 CEST] <wm4> also lua can't distinguish between objects and arrays, that's a huge wtf [17:11:56 CEST] <wm4> and its stack API is annoying and error prone [17:12:16 CEST] <wm4> and I bet you don't handle OOM and other lua errors correctly [17:12:24 CEST] <wm4> because it's fucking hard [17:12:48 CEST] <durandal_1707> should use python instead [17:13:15 CEST] <iive> let's cut directly to rust :P [17:34:50 CEST] <cone-242> ffmpeg 03Reino Wijnsma 07master:1548d2a5a547: configure: add pkg-config check for libmysofa [18:28:53 CEST] <cone-242> ffmpeg 03Paul B Mahol 07master:a27cab9eca63: avfilter/vf_blend: add timeline support to tblend filter [18:28:54 CEST] <cone-242> ffmpeg 03Paul B Mahol 07master:2bde38c0ab6c: avfilter/vf_lut2: add timeline support to tlut2 filter [18:32:20 CEST] <jdarnley> atomnuker: I [18:32:32 CEST] <jdarnley> atomnuker: I'll support you on your Lua crusade [18:33:01 CEST] <jdarnley> durandal_1707 might too. I think he wrote a bit for lavfi some time ago. [18:34:19 CEST] <durandal_1707> no, use Rust [19:08:50 CEST] <wm4> wow atomnuker got his embedtls benchmarks [19:09:59 CEST] <kierank> I don't see why atomnuker pushed back so hard [19:10:07 CEST] <kierank> it's a good ssl library [19:10:19 CEST] <kierank> or is this some kind of "older is better" fantasy [19:10:33 CEST] <nevcairiel> who knows why anyone does anything, half the people s eem to just hate everything [19:11:00 CEST] <durandal_1707> yes, i agree [19:11:29 CEST] <wm4> kierank: because we have a dozen of them already [19:11:45 CEST] <wm4> and it isn't even fully license compatible apparently? [19:11:54 CEST] <kierank> it's gpl, no? [19:12:16 CEST] <durandal_1707> we have bunch of non-free "crap" [19:12:19 CEST] <wm4> wikipedia says apache 2.0, "GPLv2 still available" [19:12:26 CEST] <nevcairiel> its apache 2.0, which is a perfectly fine license, just the gpl people hate it [19:12:32 CEST] <nevcairiel> but they also dual license as gpl [19:12:52 CEST] <wm4> I still don't know whether or not this is compatible to LGPL [19:12:58 CEST] <wm4> (2.1+) [19:13:07 CEST] <wm4> though that's all I care about [19:13:36 CEST] <durandal_1707> MIT is fine too [19:26:36 CEST] <cone-242> ffmpeg 03Aman Gupta 07master:42a03e770006: avformat/mpegts: initialize section_buf to fix valgrind test failure [20:06:34 CEST] <jdarnley> > Dear user of ffmpeg.org, administration of ffmpeg.org ... [20:06:44 CEST] <jdarnley> I doubt the veracity of that email. [20:06:45 CEST] <JEEB> :D [20:07:20 CEST] <wm4> did anyone try to use bearssl? [20:07:31 CEST] <wm4> it was suggested by nicolas and it's MIT [21:02:19 CEST] <cone-242> ffmpeg 03Carl Eugen Hoyos 07master:20b88076223b: configure: Mention the dash demuxer in the libxml2 help text. [22:41:43 CEST] <akravchenko188> jkqxz: hi, I have sent updated patch. Could you please review it? Thanks. [22:48:43 CEST] <ubitux> durandal_1707: RE patch1/2; what do you mean by "better"? [22:48:51 CEST] <ubitux> does it fix the edges or something? [22:49:34 CEST] <ubitux> is this part of the nlm litterature? [22:49:49 CEST] <durandal_1707> ubitux: it fixes smearing of edges [22:50:15 CEST] <ubitux> would you mind posting a picture for before + after? [22:50:44 CEST] <durandal_1707> ubitux: try it with: -vf nlmeans=s=4:r=65:p=7:a=.8 with that sample [22:50:54 CEST] <ubitux> ok [22:51:14 CEST] <ubitux> and what's that amount thing? [22:51:19 CEST] <ubitux> how is that different that strength? [22:51:23 CEST] <durandal_1707> less blurring [22:51:32 CEST] <ubitux> yeah but, what difference in semantic with strength? [22:52:36 CEST] <j-b> Can someone explain to me what is the pkg-config that Carl is trying to solve? [22:52:42 CEST] <j-b> I really don't get it [22:52:57 CEST] <ubitux> he doesn't want to install pkg-config because some users may not want to install it [22:53:03 CEST] <nevcairiel> he has a super broken setup himself and tries to fix all the shit [22:53:10 CEST] <JEEB> even in a local prefix? [22:53:22 CEST] <JEEB> and if pkg-config is an ass to compile into al ocal prefix, you always have pkgconf [22:53:30 CEST] <JEEB> which fedora now has used as pkg-config for at least two releases [22:53:32 CEST] <ubitux> also, he said several times he doesn't understand pkg-config [22:53:37 CEST] <j-b> pkg-config-lite is trivial to build [22:53:43 CEST] <JEEB> or that yes, j-b [22:53:51 CEST] <JEEB> I also genuinely asked which systems that would be [22:53:52 CEST] <ubitux> j-b: tbh, we tried every arguments [22:54:00 CEST] <JEEB> but seemingly he just took that as facetious [22:54:04 CEST] <JEEB> even though I specifically it was not [22:54:08 CEST] <JEEB> (Ž4@) [22:54:11 CEST] <j-b> Yeah, I read those [22:54:18 CEST] <j-b> I thought I was missing something obvious. [22:54:44 CEST] <j-b> I hate pkg-config like everyone else. But it solves a solution and is the standard now. [22:55:02 CEST] <atomnuker> it won't matter as much once meson support gets more complete [22:55:11 CEST] <j-b> true [22:56:03 CEST] <JEEB> yes, pkg-config has issues and probably pkgconf still has issues - but it's the de facto solution and even works for android compilation for me [22:56:51 CEST] <durandal_1707> ubitux: try it, it will better preserve details [22:57:14 CEST] <ubitux> but then, any reason to keep strength? [22:57:18 CEST] <ubitux> anyway, sure i'm going to test in a moment [22:57:51 CEST] <ubitux> it's a really weird semantic; does any other nlmean implementation have both options? [22:58:24 CEST] <ubitux> michaelni: i saw your report about the nlm test, i'll fix it asap, and i'm able to reproduce, sorry about the delay [23:01:34 CEST] <jkqxz> jamrial: I think we're all agreed now on using your fix for zero-length NAL units in h2645_parse. Do you want to apply it? [23:02:46 CEST] <jamrial> jkqxz: sure, one sec [23:02:50 CEST] <jkqxz> akravchenko188: The stray line with the trailing whitespace is still there? [23:04:55 CEST] <jkqxz> And there is another. (git complains about those - try applying it yourself.) [23:07:27 CEST] <ubitux> durandal_1707: wait, from the beginning you meant the shapes/content edges, not the frame edges? [23:07:49 CEST] <JEEB> &32 [23:08:09 CEST] <ubitux> durandal_1707: can you reproduce the "edge glitches" without `a` option? [23:08:32 CEST] <durandal_1707> ubitux: yes [23:09:12 CEST] <durandal_1707> ubitux: the handbrake have fixed weight for such pixels... [23:12:03 CEST] <cone-242> ffmpeg 03James Almer 07master:9a09f4c54ab8: avcodec/h2645_parse: skip NALUs with no content after stripping all the trailing zeros [23:13:37 CEST] <jamrial> jkqxz: done [23:14:23 CEST] <jkqxz> Thank you! [23:15:12 CEST] <ubitux> durandal_1707: can you provide parameters without `a` for testing patch1/2? [23:17:16 CEST] <durandal_1707> ubitux: just try without it, and with 1st patch and without 1st patch [23:23:14 CEST] <ubitux> ok i can reproduce [23:23:24 CEST] <ubitux> nlmeans=s=4:r=65:p=7 seems enough to see a difference [23:25:04 CEST] <akravchenko188> jkqxz: if I understand correctly, if you check some lines before it is another function with on the same place which looks like I added new line [23:28:10 CEST] <jkqxz> akravchenko188: <https://0x0.st/se8M.txt> [23:30:35 CEST] <ubitux> durandal_1707: so what's the logic of this patch? afaiu, you're saying the current state of the pixel weigth as much as the one from the patch with the closest difference proximity [23:31:14 CEST] <ubitux> did you take this from a paper or something? i'd say it simply smooth more [23:32:06 CEST] <akravchenko188> jkqxz: oh, I see, I will test applying patch [23:33:15 CEST] <ubitux> durandal_1707: maybe https://arxiv.org/pdf/1211.1656 ? [23:34:26 CEST] <durandal_1707> ubitux: how it smooths more? without it i see broken edges with most parameters [23:35:26 CEST] <ubitux> i'd say it looks broken but it's simply less denoised because less similar patches were found i'd [23:35:38 CEST] <ubitux> i think that's what we're observing here [23:36:44 CEST] <ubitux> and your patch, afaiu, is basically saying "ok this patch doesn't look that close, but it's best we could find so we will consider its weight equal to the current one [23:36:49 CEST] <ubitux> i'm not saying it's wrong [23:37:05 CEST] <ubitux> i'm trying to understand why it seems to help, and what's the theory here [23:37:31 CEST] <ubitux> we can't adjust such as studied algorithm randomly because it tweaking it looks better on one sample [23:37:47 CEST] <ubitux> so i was wondering where it's coming from etc [23:38:30 CEST] <ubitux> (also, this is in the inner loop, it probably makes the filter slower, better think about it) [23:38:46 CEST] <ubitux> how are other implementations behaving on this sample? [23:39:07 CEST] <ubitux> do they also have the glitches? do they fix it differently? [23:54:33 CEST] <durandal_1707> ubitux: read this docs: http://avisynth.nl/index.php/TNLMeans [23:55:49 CEST] <akravchenko188> jkqxz: I have sent updated patch fixing trailing whitespace. [23:59:23 CEST] <akravchenko188> jkqxz: I didnt know about such issues detection before. Thanks [00:00:00 CEST] --- Tue May 15 2018

1 0

ffmpeg.log.20180514
by burek 15 May '18

15 May '18

[00:01:07 CEST] <kerio> also, 8-bit yuv-rgb conversions are lossy [01:32:39 CEST] <kepstin> kerio: almost all yuv content started out as rgb and was converted to yuv [01:33:05 CEST] <kepstin> well, i suppose it depends on cameras, and some generated video or effects might be done in yuv [01:33:50 CEST] <kepstin> so all the loss was done in the rgb to yuv conversion - assuming you have a matching conversion back, there's no more loss [06:03:59 CEST] <fa0> Hello all [06:04:19 CEST] <fa0> -vcodec copy is the same as -c:v ? [06:05:27 CEST] <fa0> or actually '-c:v copy' [06:09:29 CEST] <fa0> '-c:v copy' seems to be working... :P [06:14:55 CEST] <fa0> I see now how -vcodec & -c:v are, as they work alone encoding... [09:45:19 CEST] <Hfuy> Hello. [09:45:48 CEST] <Hfuy> I have a video that's at 25fps that I'd like to frame double to 50fps, so that the output duration isn't changed and there are duplicate frames. [09:46:02 CEST] <Hfuy> I'm slightly confused by the function of the frame rate flags; can anyone advise? [10:13:21 CEST] <durandal_1707> Hfuy: use fps filter [10:46:32 CEST] <quanta-> hi guys [10:47:02 CEST] <quanta-> I need some help with some deprecated functions, I want update them [10:47:06 CEST] <quanta-> here is my code https://pastebin.com/gDhe0Zm5 [10:47:30 CEST] <quanta-> they are just four deprecated references [10:48:59 CEST] <quanta-> am sorry they are only two functions [10:49:21 CEST] <quanta-> avcodec_default_release_buffer(c, pic); [10:49:36 CEST] <quanta-> and [10:49:37 CEST] <quanta-> avcodec_default_get_buffer(c, pic); [10:49:58 CEST] <quanta-> what is the equivalent to that on the new api ? [10:57:56 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/APIchanges;hb=HEAD [12:37:49 CEST] <quanta-> Please check my repo, i'm trying to update a plugin to use the latest ffmpeg, compilation is fine but now the code won't run https://github.com/kenkit/ogre-ffmpeg-videoplayer/commit/bc986567f9d25d4893… [12:41:53 CEST] <quanta-> :( [12:42:00 CEST] <durandal_1707> quanta-: what does not work? [12:42:04 CEST] <JEEB> I would check if I wasn't at work :P [12:42:21 CEST] <quanta-> ooh, hi JEEB [12:42:33 CEST] <quanta-> it's doesn't need alot of work [12:42:49 CEST] <quanta-> I'm translating the plugin to use the latest ffmpeg [12:43:12 CEST] <quanta-> but it's crushing, maybe because of those deprecated buffer functions ? [12:44:28 CEST] <quanta-> this is the error I get "[AVBSFContext @ 06FC3A00] A non-NULL packet sent after an EOF." [12:45:34 CEST] <durandal_1707> avpicture is deprecated, you should use avframe directly [12:46:20 CEST] <quanta-> it breaks in https://github.com/kenkit/ogre-ffmpeg-videoplayer/blob/master/src/audiodeco… [12:46:57 CEST] <th3_v0ice> Hi guys, can anyone explain why av_interleaved_write_frame() would not write all packets to the output file? I called it with NULL instead of the packet so I could be sure that its flushed and I have set max_interleaved_delta to 0 but the last packet is simply not written to the file. Thanks! [12:49:26 CEST] <quanta-> :durandal_1707 how do I do that, sorry but I'm completely new to ffmpeg. Any example ? [12:50:50 CEST] <JEEB> this is the current decoding API, introduced a few years ago https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [12:50:57 CEST] <JEEB> then you get AVFrames from it [12:51:06 CEST] <JEEB> and you can put them into encoders or filters or whatever [12:51:22 CEST] <JEEB> (without further context) [12:51:44 CEST] <durandal_1707> quanta-: it appears you are still sending something after EOF, sending null packet, or packet without data [12:52:11 CEST] <quanta-> :JEEP you mean something like this https://github.com/kenkit/player-cpp-ffmpeg-sdl/blob/master/Player.cpp#L284 ? [12:53:14 CEST] <durandal_1707> that is new decoding api [12:53:38 CEST] <JEEB> can you really call it new any more :D [12:54:25 CEST] <quanta-> durandal_1707: after EOF, this code used to work with the older ffmpeg so is it that the buffers are not being filled or something ? [12:55:06 CEST] <th3_v0ice> Hi guys, can anyone explain why av_interleaved_write_frame() would not write all packets to the output file? I called it with NULL instead of the packet so I could be sure that its flushed and I have set max_interleaved_delta to 0 but the last packet is simply not written to the file. Thanks! I am sorry if this message already appeared. [12:55:56 CEST] <durandal_1707> quanta-: it looks something sends packets after null packet [12:57:31 CEST] <durandal_1707> and that usage of new api, receive_frame should loop, look at doc/examples/decode_video.c [12:58:36 CEST] <quanta-> I only got rid of avcodec_default_get_buffer() and avcodec_default_release_buffer(); I thought this were already implemented in the new api [12:58:56 CEST] <quanta-> durandal_1707: let me have a look into it [13:00:47 CEST] <quanta-> don't forget to help out th3_v0ice if you can, thanks for your help [13:03:44 CEST] <durandal_1707> th3_v0ice: what muxer end what codec? [13:05:18 CEST] <th3_v0ice> durandal_1707: Codec is x264 and output file is mp4, so default muxer for mp4. [13:05:32 CEST] <th3_v0ice> quanta-: Thanks! [13:06:28 CEST] <th3_v0ice> durandal_1707: If I change the output file to h264, first packet is written twice and last packet is written also. [13:09:52 CEST] <durandal_1707> th3_v0ice: do you call av_interleaved_write_frame() with NULL packet until you receive zero got_frame ? [13:12:24 CEST] <th3_v0ice> durandal_1707: I only call it once like this av_interleaved_write_frame(ofmt_ctx, NULL) to flush it. I am not sure what exactly do You mean by got_frame? [13:12:53 CEST] <th3_v0ice> durandal_1707: I am always getting 0 as the return value. [13:14:43 CEST] <durandal_1707> th3_v0ice: you need to send NULL packets as long as encoder give you non-zero got_frame [13:17:50 CEST] <durandal_1707> do you use send_frame/receive_packet ? [13:17:58 CEST] <th3_v0ice> durandal_1707: I have also flushed the encoder. To make sure that this error is not involving the encoder I have decoded and saved as pgm files all packets that I have received from encoder. All the pictures are there, but there is one missing from the output file. [13:18:18 CEST] <th3_v0ice> durandal_1707: Yes, I am using the new API. [13:20:08 CEST] <durandal_1707> th3_v0ice: the missing one is last one? [13:21:58 CEST] <th3_v0ice> durandal_1707: For the mp4 output, yes. For the h264 output, first packet is duplicated, and the last one is written. [13:22:42 CEST] <durandal_1707> th3_v0ice: do you keep calling receive_packet until you get EAGAIN or EOF error code? [13:23:03 CEST] <th3_v0ice> durandal_1707: Yes [13:25:02 CEST] <durandal_1707> and you also call send_frame before with NULL AVFrame for flushing? [13:25:16 CEST] <th3_v0ice> durandal_1707: The packet is received because I decoded and saved it as a picture. [13:26:15 CEST] <th3_v0ice> durandal_1707: Yes, I also call send_frame with NULL to flush it. [13:26:51 CEST] <durandal_1707> but do you call send_frame with NULL frame at end for flushing? [13:28:10 CEST] <th3_v0ice> durandal_1707: Yep [13:29:21 CEST] <durandal_1707> th3_v0ice: can source code be viewed? [13:31:30 CEST] <th3_v0ice> durandal_1707: I can paste part of the code on pastebin, but will share the link privatelly with You, is that ok? [13:34:18 CEST] <durandal_1707> th3_v0ice: ok [14:00:57 CEST] <durandal_1707> th3_v0ice: strange bug, does it still happens if you do not touch delta? [14:01:35 CEST] <th3_v0ice> durandal_1707: Yes, it does. No matter what delta is, its always the same behaviour. [14:05:54 CEST] <durandal_1707> it doesnt happen with ffmpeg? [14:11:19 CEST] <th3_v0ice> durandal_1707: Let me test [14:12:09 CEST] <th3_v0ice> durandal_1707: On a seconds thought, I am not exactly sure how to do a valid comparison. [17:05:42 CEST] <tokam> https://paste.ubuntu.com/p/YDHQfZx9Rd/ [17:05:43 CEST] <tokam> hi [17:05:48 CEST] <tokam> what is wrong with this command? [17:06:02 CEST] <tokam> ffmpeg -i record.avi -vf "select=gt(scene\,0.003),setpts=N/(25*TB)" output.mp4 [17:06:13 CEST] <tokam> Past duration 0.999992 too large [17:07:24 CEST] <tokam> sorry [17:07:27 CEST] <tokam> I used the wrong input file [17:07:28 CEST] <tokam> all fine [17:27:00 CEST] <fooman2011> Hello. Does anyone can help me to understand what does the line 322 in libavformat/avio.c please ? Before this "if" my cookie is present in "options" and after this "if" my cookie is lost. So the hls can be read correctly. [17:34:22 CEST] <plexigras> maybe you guys can help me i'm using streamlink and i want to save the stream in small chunks and i'm not sure how i can do this [17:34:53 CEST] <plexigras> it seams to work with ffmpeg when i do this `streamlink -a="" -p="ffmpeg -i - af.flv" https://www.twitch.tv/rpglimitbreak worst` [18:03:55 CEST] <Freneticks> hello how do you read rtp stream inside udp [18:05:29 CEST] <Freneticks> If i play ffplay -f rtp udp://ip [18:05:32 CEST] <Freneticks> it's working [18:06:01 CEST] <Freneticks> but if ffmpeg -i udp://ip -c copy test.ts not working [18:06:09 CEST] <Freneticks> is there a way to force input for rtp ? [18:20:25 CEST] <Freneticks> hello ? [18:28:35 CEST] <furq> Freneticks: -f rtp before -i [18:29:11 CEST] <Freneticks> yes furq but he say : could not find codec parameters [18:29:15 CEST] <Freneticks> i tried [18:33:17 CEST] <Freneticks> any idea furq ? [18:38:08 CEST] <tuna> BtbN: So I pulled the most recent code friday, and I am going to try out the hw_frame alloc/init type of approach...i set the frame context params, call init, then I need to copy data into the hw_frame...how do I get a cuda device ptr from the hw_frame_ctx?? [18:38:51 CEST] <BtbN> you get a full frame from it [18:39:01 CEST] <BtbN> the devptr(s) are in the data pointers [18:40:26 CEST] <fooman2011> any developper here who are familiar with HLS ? ffmeg fails to dec an hls stream because a cookie is needed to retrieve the key that is use to encryt segments. The cookie is correctly set but the key is not retrieved. I really need help [18:51:32 CEST] <tuna> The data pointer of the AVHWFramesContext struct? [18:54:35 CEST] <tuna> BtbN: Or do you mean it is in the AvFrame data pointer after adding the hwframecontext to the avframe and calling av_frame_get_buffer on it? [18:54:45 CEST] <BtbN> of the frame [18:55:12 CEST] <tuna> av_frame_get_buffer is where the cuda alloc actually happens then, I assume? [18:55:14 CEST] <BtbN> A CUDA frame is virtually identical to a software frame of the underlying sw format, except that it's CUDA pointers [18:55:27 CEST] <BtbN> it's a bit more involved internally, but for all you need to care, yes [18:55:35 CEST] <tuna> Ok [18:56:47 CEST] <tuna> Linesize is automagically filled out aswell? [18:59:46 CEST] <BtbN> it is allocated with proper alignment [19:00:14 CEST] <BtbN> you need to follow linesize when filling the frame, or results will be unexpected [19:01:50 CEST] <tuna> Yea, so I am asking will the AvFrame's linesize[0] (rgb input) be correct after allocating the buffer? [19:02:27 CEST] <tuna> Such that I can cuMemcpy2D with a correct line size from my GL texture into this hw_frame_ctx created buffer [19:25:30 CEST] <tuna> BtbN: Seems to still be a bug with the av_hwframe_ctx_init...i still get pixel format not supported, I have verified that I built off of the master branch, and that my VSC++ environment is pointing to the right .libs/headers [19:26:05 CEST] <BtbN> 0BGR32 and 0RGB32 are supported by the cuda hwframes ctx in master [19:26:22 CEST] <BtbN> which matches exactly with what nvenc wants [19:26:46 CEST] <tuna> One curious thing though, when It fails for AV_PIX_FMT_0RGB32 it says Pixel format 'bgr0' is not supported....and when it fails for AV_PIX_FMT_0BGR32 it says Pixel format 'rgb0' is not supported [19:27:07 CEST] <Freneticks> any help for could not find codec parameters ? [19:35:17 CEST] <tuna> BtbN: Seems like when I assign "frameCtxPtr->sw_format = AV_PIX_FMT_0BGR32" I get an actual output of "AV_PIX_FMT_RGB0 (121)" at runtime in the sw_format position [19:35:41 CEST] <BtbN> 0BGR32 is a platform specific alias for the matching underlying format [19:35:48 CEST] <BtbN> in your case that's RGB0 [19:36:25 CEST] <tuna> but that doesnt match the "supported_formats" enum in hwcontext_cuda.c, so it fails the check [19:36:34 CEST] <BtbN> it does [19:36:40 CEST] <BtbN> like I just said, it's an alias... [19:37:35 CEST] <tuna> Ok, but it is failing...and I have the source pulled up on my pc that I built from, and it matches your fix commit...so what could be the issue? [19:38:05 CEST] <BtbN> I'd guess you are using the wrong library, or that's not the cause of your error. [19:38:29 CEST] <tuna> my linker setting are pointed at my build... [19:38:36 CEST] <tuna> of this source... [22:00:02 CEST] <faLUCE> I don't know how to solve that. In myvideo.flv, at 00:10:03 , video track freezes for one second and from then, audio and video go out of sync. How can I correct the sync problem? [22:20:35 CEST] <tuna> BtbN: I worked past the issue with the library, it was using a bad DLL...but now av_frame_get_buffer returns invalid argument. My AvFrame I pass is has a hw_frame_context, width, height, format...the frame context has width, height, sw_format (AV_PIX_FMT_0BGR32), format (cuda), a device ref and device ctx ptr and has bein "init"-ed.... [22:21:19 CEST] <tuna> av_frame format is cuda as well [22:21:21 CEST] <BtbN> it gives you a frame, you don't need to init anything [22:21:29 CEST] <BtbN> that's the whole point of it [22:21:59 CEST] <tuna> av_hwframe_ctx_init creates the buffer I thought? [22:22:21 CEST] <BtbN> it creates the hw frames ctx [22:22:31 CEST] <BtbN> which gives you fully useable frames [22:23:01 CEST] <tuna> So I dont need a av_frame_get_buffer? [22:23:46 CEST] <BtbN> there is a hwframe specific get buffer [22:24:22 CEST] <BtbN> av_hwframe_get_buffer [22:24:29 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/hwcontext.h;h=f5a4… [22:26:06 CEST] <tuna> " @param frame an empty (freshly allocated or unreffed) frame to be filled with * newly allocated buffers." [22:26:21 CEST] <tuna> so I should not be setting anything in my AvFrame I pass to this function? [22:31:19 CEST] <tuna> Seems like it doesnt need anything filled in.....so the AvFrame->data should be a CUdeviceptr? I am not getting errors with my cuMemcpy2D call saying invalid value, and I suspect its the avframe->data because thats all that had changed [22:31:30 CEST] <tuna> not == now [22:32:23 CEST] <tuna> feels so close... [22:35:58 CEST] <faLUCE> I don't know how to solve that. In myvideo.flv, at 00:10:03 , video track freezes for one second and from then, audio and video go out of sync. How can I correct the sync problem? [22:41:14 CEST] <BtbN> That's the entire point of a hwframesctx [22:42:44 CEST] <BtbN> it gives you ready to use frames [22:46:51 CEST] <tuna> Gotcha [22:49:01 CEST] <tuna> So I have something working....I can receive h264 encoded stream back to my client...my demo program just rotates a texture in a circle...the output i see is half the shape rotating in the opposite direction...im thinking maybe I have a bad copy from cuda or soemthing [22:50:36 CEST] <BtbN> define half the shape [23:03:40 CEST] <SpeakerToMeat> Is there any way to vconvert to 5.1 to stereo without downmixing? to get only L and R from the 5.1 to L and R out? [23:03:55 CEST] <JEEB> yes, if you really want to [23:04:06 CEST] <JEEB> you need to basically do a manual remap [23:04:48 CEST] <tuna> BtbN: Was an issue with my cuMemCpy2D...must want me to say width is *4 not just width...seems to all work now...Thanks for all the help on this, i really appreciate it [23:04:59 CEST] <JEEB> https://trac.ffmpeg.org/wiki/AudioChannelManipulation [23:05:22 CEST] <SpeakerToMeat> ugh string... [23:12:17 CEST] <SpeakerToMeat> JEEB: -map_channel 1.0.0 -map_channel 1.0.1 ?? [23:12:50 CEST] <JEEB> not sure about that, I think you're better off figuring one of those filter chains where different channels from inputs are being re-mapped [23:13:26 CEST] <SpeakerToMeat> or maybe pan.... [23:13:47 CEST] <SpeakerToMeat> pan=stereo|c0=c0|c1=c1 [00:00:00 CEST] --- Tue May 15 2018

1 0

ffmpeg-devel.log.20180513
by burek 14 May '18

14 May '18

[00:30:12 CEST] <jkqxz> Who maintains the doxygen stuff on ffmpeg.org? The doxygen documentation for the 4.0 branch is missing - I guess that needs a manual step to add a branch somewhere? [00:32:23 CEST] <atomnuker> michaelni I think [01:05:50 CEST] <michaelni> doxygen for 4.0 should be fixed [01:13:24 CEST] <jkqxz> Yep, working now. Thank you! [09:21:47 CEST] <KTSamy> Even though it's not an issue, Just asking on curiosity.May I know why RELEASE file is not updated after 4.0 release. It still "3.4.git". [09:25:06 CEST] <KTSamy> when using the latest builds from the master branch, it always shows as 3.4.git which results in confusions sometimes 😂 [11:19:16 CEST] <JEEB> &23 [11:27:31 CEST] <BtbN> Because nobody thought update updating it so far [11:28:21 CEST] <JEEB> michaelni: I am very confused about this FLV patch and you saying LGTM to it [11:29:00 CEST] <JEEB> I mean, it could be that nobody cares and I shouldn't either, but (unsigned)pkt->dts and the function definition being "unsigned" just makes me cringe [11:30:04 CEST] <JEEB> also FLV had timestamp wrap-arounds and those are ignored completely in this fix even though figuring out if it's 32bit or 31bit shouldn't be too hard. most likely 31bit wrap-around since the spec says "starts at zero" and the value is 32bit signed integer [11:33:15 CEST] <JEEB> and no, I haven't looked outside of the context of that patch how timestamp wrap-arounds are handled in flvenc.c. maybe they aren't. in which case it might feel silly that I'm trying to require these things, but so far nobody has mentioend that. [11:33:53 CEST] <JEEB> I'm just going by the anecdotal info I have of FLV, and the thing Adobe calls a "spec" [11:34:52 CEST] <BtbN> iirc flv/rtmp just completely shit itself when the timestamp overflows [11:37:20 CEST] <JEEB> the timestamp value seems to be a signed 32bit integer (supposed to start at zero according to spec, but apparently in RTMP this initial timestamp can be nonzero according to alex?), and the time base is 1/1000. so it seems like it's 31bit unsigned integer wrap-around? [11:37:31 CEST] <JEEB> at least that's how the signed integer seems to be realistically utilized [11:37:49 CEST] <JEEB> someone splunked an "int" and then only used it for positive values [11:37:58 CEST] <JEEB> but someone would have to look at how adobe crap handles that [11:38:56 CEST] <nevcairiel> thats still like almost 600 hours at that granularity, not sure that realistically matters [11:39:09 CEST] <BtbN> all the streaming services kill your stream after ~48 hours [11:39:38 CEST] <durandal_1707> why? [11:42:03 CEST] <nevcairiel> the real question is, how are normal packet timestamps written? and is this different? if no, then its perfectly fine [11:42:48 CEST] <JEEB> as in, "if we have these issues already there, then we can make more code with the same issues?" [11:42:55 CEST] <nevcairiel> yes [11:43:07 CEST] <nevcairiel> asking people to fix pre-existing issues in a patch is generally not very nice [11:43:28 CEST] <nevcairiel> that should be separate work [11:44:12 CEST] <JEEB> and I brought up things because f.ex. he now specifically has a zero as the function parameter for the initial data, thus it feels like it's being asserted that that's the correct thing now [11:44:26 CEST] <JEEB> also I wish these things were mentioned as replies to my reviews [11:44:34 CEST] <JEEB> - we will not handle wrap-around correct because <reason> [11:44:43 CEST] <JEEB> - we will not handle other things correctly because <reason> [11:45:14 CEST] <nevcairiel> what other timestamp would it use in the header? there is none to be had there =p [11:45:50 CEST] <JEEB> also my general gist is that new code should be correct. I would not make him fix normal timestamp writing code, but if he's fixing the header update packets' timestamps then might as well figure out the correct way to do that [11:46:27 CEST] <JEEB> nevcairiel: fair point if that was in write_header [11:46:35 CEST] <nevcairiel> it is [11:46:51 CEST] <JEEB> that said I think I stopped talking about that thing on the ML some time ago [11:47:11 CEST] <JEEB> and mostly wanted to focus on finally getting the timestamps right in that specific case [11:47:35 CEST] <nevcairiel> the way I see it, the timestamps should match the way timestamps are written for normal packets [11:47:42 CEST] <nevcairiel> if they are different, its going to cause issues [11:47:47 CEST] <nevcairiel> no matter how right or wrong that method is [11:48:22 CEST] <nevcairiel> getting a packet and a header update with different timestamps even if they belogn together is clearly worse then anything else that could happen [11:49:23 CEST] <JEEB> and as far as I can see that's relatively unlikely unless the normal timestamp code does something really wonky [11:53:44 CEST] <JEEB> but sure, if it is mentioned that all these other technical concerns about "how does FLV actually work" are ignoed, then there's the nr1 issue that throws itself at my eyes which is the aversion of standardly-sized types. [11:54:12 CEST] <JEEB> we might have taken code that does (unsigned)int64_t before, but I'm pretty sure we don't any more [11:58:30 CEST] <JEEB> and seriously, maybe I should just give up at this point. my original reasoning was that I wanted to provide a nice review so that alex's patch didn't get ignored on the mailing list - with the information on FLV I had available. and now it seems like everyone thinks that I'm the bad person being a pedantic asshole. even though I've mentioned a few times that the change is good and as far as we [11:58:36 CEST] <JEEB> understand how FLV works the replies to my reviews should have been a simple case [12:00:12 CEST] <JEEB> and I feel even more sadder that I now had to quickly/hastily do a reply on the new version of the patch that just does (unsigned)int64_t for the function about the most glaring issue with it. and now I feel awful about that too. fuck life [12:00:52 CEST] <JEEB> because michaelni LGTM'd the patch with that thing [12:04:28 CEST] <michaelni> JEEB, i dont understand your concerns, the patch wirtes the timestamp the same way as other timestamps are written in flvenc. If this has issues that must be fixed and is very important but it should not be in this patch. it should either be before or afterwards [12:04:33 CEST] <michaelni> thats IMHO [12:05:51 CEST] <JEEB> ok, even if we ignore all theo ther concerns [12:06:00 CEST] <JEEB> is (unsigned)int64_t OK in new code? [12:06:34 CEST] <JEEB> like, that is the only left-over thing if we ignore all of the "how FLV actually works" discussion out of this [12:07:06 CEST] <JEEB> we're adding a *new* function parameter and that's now "unsigned", and the value we're trying to stuff in is int64_t [12:07:22 CEST] <JEEB> since it's a new and not public thing, why is everyone just OK with that?! [12:07:42 CEST] <JEEB> I know for external APIs you might have to do non-pretty things [12:07:51 CEST] <michaelni> int64_t -> unsigend is how existing timestamps are done in flvenc. If we change it it should be changed for all at once. [12:09:47 CEST] <JEEB> but this is the important part: we are now letting an example of new code in (albeit in an old module) with something that we generally would not accept [12:10:04 CEST] <JEEB> are we really OK with that? [12:10:20 CEST] <JEEB> and how different is it from just taking those 32 or 31 bits within that function from that int64_t? [12:10:37 CEST] <JEEB> but OK, clearly I don't understand anything and I should just shut up [12:10:56 CEST] <michaelni> shift & mask should be the same for int64 and unsigned [12:12:11 CEST] <michaelni> about letting bad code in, we should not. But i dont think flvenc authors considered >2^31 timestamps very deeply [12:12:36 CEST] <michaelni> this should be fixed but one fix has to be done first [12:13:50 CEST] <michaelni> fix the 0 timestamp as in the patch or fix any 32 / 31 bit issues if they exist [12:13:55 CEST] <JEEB> like, I am still boggled about this logic but I will just post "Fuck it, ignore all of my concerns, seemingly I'm the bad guy here." on the ML I guess [12:14:25 CEST] <JEEB> because it seems like most of the community has differing standards than I have, and I do not deal with FLV daily and thus cannot take this fixing forward by myself [12:16:11 CEST] <durandal_1707> it is broken before, it is broken after... [12:19:27 CEST] <michaelni> JEEB, if you suggest that the patches should use int64 for all new timestamp variables instead of unsigend but generate exactly the same file that seems possible. But if you want to write different timestamps in one field than others thats adding a worse issue IMHO [12:20:14 CEST] <JEEB> I just fucking saw one function that had a parameter added to it for eff's sake [12:20:27 CEST] <JEEB> and that parameter was unsigned while the data it takes in was clearly int64_t only [12:20:43 CEST] <JEEB> that was litearlly the only other concern I had of that patch outside of "how does FLV work" [12:20:57 CEST] <JEEB> (in the area that is not well specified in the spec) [12:23:54 CEST] <JEEB> there, I thus withdrew from that review since I'm seemingly the asshole. [12:30:36 CEST] <wm4> seems ffmpeg can't decide whether changes to a patch require v2, or if "changing before pushing" is ok [12:30:46 CEST] <wm4> I conclude anything goes [12:31:21 CEST] <michaelni> wm4, thats handled inconsistently it seems yes [12:32:27 CEST] <JEEB> but yea, I think I will just sulk somewhere because I honestly was trying to be useful. [12:33:25 CEST] <michaelni> JEEB, i think your good intentions overshoot the goal but maybe i just misunderstand which is very possible [12:34:16 CEST] <michaelni> but ive a patch locally that fixes a unsigend/int64 bug in flvenc ill post once i tested a bit [12:34:23 CEST] <JEEB> all I wanted was to figure out how FLV actually handles that, not actually fixing the whole thing. to have this as an example of how to do it right. [12:34:36 CEST] <michaelni> never would have found this bug that patch fixes without you :) [12:36:52 CEST] <JEEB> and yes, I am myself very guilty of not looking at the rest of the code of flvenc.c outside of that patch. but even with that, I think my questions regarding how these things are handled were valid since we were adding a new place where FLV timestamps were being added [12:37:30 CEST] <JEEB> or well, a new place which writes FLV timestamps. period. [16:59:43 CEST] <hanna> https://0x0.st/sjFc.txt trying to enable lv2 support fails for me -> it can't find /usr/include/lilv-0/lilv/lilv.h, since that doesn't exist. on my end the package installs to /usr/include/lilv/lilv.h [16:59:56 CEST] <hanna> It seems like the ffmpeg include should also be using #include <lilv/lilv.h> [17:00:07 CEST] <hanna> after all, on platforms where /usr/include/lilv-0 is needed, the pkg-config --cflags seems to include that [17:00:38 CEST] <JEEB> yea, that looks weird as far as a check is concerned [17:00:51 CEST] <JEEB> possibly a historical thing [17:00:59 CEST] <hanna> in fact it's just the configure check that needs fixing [17:00:59 CEST] <JEEB> time for archaeology [17:01:02 CEST] <JEEB> yes [17:01:04 CEST] <hanna> the actual source code uses <lilv/lilv.h> [17:01:08 CEST] <JEEB> lol [17:01:40 CEST] Action: JEEB waits for the historical context to pop up [17:02:12 CEST] <JEEB> basically I 100% agree, but am not sure if someone comes up with some weird case where that's somehow needed [17:02:36 CEST] <JEEB> ok, it was just added as a component by paul [17:02:42 CEST] <JEEB> and it's a pkg-config check [17:02:58 CEST] <JEEB> and it probably passed because both were there [17:03:03 CEST] <hanna> https://0x0.st/sjFT.patch if you want a patch :p [17:03:06 CEST] <JEEB> the -I flag from pc [17:03:12 CEST] <JEEB> well yea, the patch is pretty obvious [17:03:20 CEST] <JEEB> since I'm looking at the check [17:03:20 CEST] <JEEB> lol [17:04:05 CEST] <JEEB> but yea, it worked in the pkg-config check because both the include dir as well as the extra lil-related dir were in -I [17:04:12 CEST] <hanna> yeah but this way you just have to curl | git am && git push :p [17:04:12 CEST] <JEEB> and the other one as well worked because were there [17:04:35 CEST] <JEEB> true [17:05:05 CEST] Action: JEEB pokes durandal_1707 to verify that his system still works with that patch [17:05:14 CEST] <JEEB> if it works for him (it most likely does), then it can be pushed [17:05:28 CEST] <JEEB> or well, officially it needs to go through ML etc [17:05:28 CEST] <hanna> (plus I found the bug and required the change, shouldn't I be the one to attach my name to the fix so that people can complain? :p) [17:05:36 CEST] <JEEB> yes [17:05:52 CEST] <hanna> fuck mailing lists for one-word changes [17:05:58 CEST] <hanna> but I can send it if you really want to [17:06:00 CEST] <JEEB> I know, but that's the process [17:06:03 CEST] <JEEB> yes, I will send it right now [17:06:33 CEST] <hanna> I could also just type `git send` [17:06:47 CEST] <hanna> unless you already sent [17:06:56 CEST] <hanna> I didn't realize I already had git send configured for ffmpeg [17:07:04 CEST] <JEEB> nah, I just grabbed my laptop that has git send-email configured [17:07:05 CEST] <JEEB> lol [17:07:20 CEST] <JEEB> so if you can send it, pls do [17:07:26 CEST] <JEEB> then I will poke durandal_1707 do LGTM it [17:07:28 CEST] <JEEB> if it works for him [17:07:35 CEST] <JEEB> since he's the only other person with that library [17:07:42 CEST] <JEEB> (known) [17:07:49 CEST] <JEEB> since otherwise the breakage would have been noticed [17:09:53 CEST] <hanna> well it might be that gentoo is wrong in installing it directly to /usr/include/lilv-0 [17:10:01 CEST] <hanna> although that just seems to be the default behavior of the thing if you pass --prefix to the waf script [17:10:05 CEST] <hanna> I mean directly to /usr/include [17:11:14 CEST] <JEEB> CC'd paul [17:11:21 CEST] <JEEB> in my "looks good" reply [17:14:57 CEST] <hanna> FWIW, the only way that could possibly break if is there exists a platform that installs it to /usr/include/lilv-0/lilv-0/lilv/lilv.h [17:15:02 CEST] <hanna> but that seems too retarded for anything other than debian [17:15:20 CEST] <hanna> oh, and in that case, the configure check would work but the af_lv2.c would fail compiling [17:15:36 CEST] <hanna> really there's no possible case in which having the configure check mismatch the actual source code would either be needed or beneficial [17:15:44 CEST] <JEEB> yea [17:15:46 CEST] <JEEB> I 100% agree [17:16:08 CEST] <JEEB> for teh record, that 0x0.st link hasn't still opened for me btw [17:16:08 CEST] <JEEB> lol [17:16:16 CEST] <JEEB> so I never could even try or apply it [17:16:26 CEST] <JEEB> (although I could have done the change locally) [17:16:35 CEST] <hanna> curl https://0x0.st/sjFT.patch doesn't work for you? [17:16:51 CEST] <JEEB> it works now [17:16:57 CEST] <hanna> were you trying to open it in a browser? [17:17:07 CEST] <JEEB> and still did, which works generally OK [17:17:18 CEST] <JEEB> but yes, I do curl + git am generally [17:17:22 CEST] <JEEB> after checking the patch visually quickly [17:17:42 CEST] <JEEB> I just seem to have accessed 0x0.st exactly when something borked somewhere between here and the server [17:18:25 CEST] <hanna> I blame lachs0r [17:18:27 CEST] <hanna> (who isn't here, wtf) [17:54:14 CEST] <JEEB> alright, paul lgtm'd it [17:56:40 CEST] <JEEB> will quickly check that configure script didn't break and then push it in [17:56:46 CEST] <JEEB> I mean, it most likely didn't break [17:56:48 CEST] <JEEB> but you know [17:57:02 CEST] <JEEB> I want to be able to answer "did you even try running the shell script?!" [17:57:38 CEST] <hanna> I mean I built it using this patch locally already [17:57:42 CEST] <JEEB> ok, works [17:57:48 CEST] <JEEB> hanna: yea this is just a general workflow thing [17:57:50 CEST] <hanna> (which also confirms that it solves my issue) [17:58:03 CEST] <JEEB> I don't generally push things that I have not even had in my tree [17:58:07 CEST] <JEEB> and configured+built at least once [17:58:12 CEST] <JEEB> even if that feature is not enabled [17:58:29 CEST] <hanna> as if changing the contents of a string would break the configure script :p [17:58:41 CEST] <hanna> wait fuck, this is shell, everything's a string [17:58:57 CEST] <cone-890> ffmpeg 03Niklas Haas 07master:32234e03a792: configure: fix configure check for lilv-0 [17:59:01 CEST] <hanna> \o/ [17:59:02 CEST] <JEEB> there we go [17:59:13 CEST] <JEEB> that was also part of ffmpeg 4.0 as well, so maybe needs back-porting [18:00:09 CEST] <hanna> how many layers of bureaucratic BS does that need to go through? [18:00:21 CEST] <JEEB> someone saying "maybe" or "yea" [18:00:25 CEST] <JEEB> and then I just push it in [18:00:31 CEST] <JEEB> or someone else does [18:00:38 CEST] <jamrial> hanna: none, just making sure it works [18:00:41 CEST] <hanna> I remember trying to submit a trivial bug fix to gentoo and they insisted I provide like 10 different log files that had fuck all to do with the typo fix [18:00:46 CEST] <hanna> because their policy requires it [18:00:52 CEST] <hanna> at some point I just gave up [18:01:08 CEST] <JEEB> yes, if you are brave enough you just push. but I like to do the minimum [18:01:14 CEST] <JEEB> like actually running the shell script/build [18:01:20 CEST] <JEEB> for a patch that I am about to push [18:02:08 CEST] <jamrial> workflow is pretty lax. if it works, it's not spaghetti code and no one blocks it or is against, in general it's fine [18:05:09 CEST] <JEEB> which of course has its positives and negatives. generally I like to follow: 1) patch onto ML 2) at least someone else has taken a look at the patch, preferably the person who maintains that module 3) check that the patch hasn't broken anything obvious [18:05:59 CEST] <JEEB> I know that's not required, but it helps to have a distinct workflow :P I'm 100% OK with stuff like that documentation fixup which tmm1 did and just pushed, although someone could possibly argue that it's wrong because it didn't go through the ML [18:19:32 CEST] <cone-890> ffmpeg 03Niklas Haas 07release/4.0:93cee87b13fd: configure: fix configure check for lilv-0 [18:19:38 CEST] <JEEB> and there is a back-port [18:53:19 CEST] <KTSamy> foe me includes goes to lilv-o/lilv [18:53:38 CEST] <KTSamy> in wscript it's includedir = '${INCLUDEDIR}/lilv-%s/lilv' % LILV_MAJOR_VERSION [18:54:05 CEST] <KTSamy> I have indeed used --prefix to point a custom directory [18:54:10 CEST] <JEEB> yea, but the check was pkg-config based and the pc file should have the required -I [18:54:25 CEST] <KTSamy> Yes. It has [18:54:26 CEST] <JEEB> also the code didn't use the lilv-X prefix [18:54:44 CEST] <JEEB> the include in the .c file had only lilv/blah.h [18:54:46 CEST] <JEEB> :) [18:55:03 CEST] <KTSamy> I have tried ffmpeg master on mac [18:55:12 CEST] <KTSamy> everything went fine [18:55:27 CEST] <JEEB> yup, if it wouldn't have worked the code wouldn't have compiled in the first place [18:55:35 CEST] <JEEB> since the header check had a different path [18:55:59 CEST] <KTSamy> my pkg-config pc file has the required -I [18:57:12 CEST] <KTSamy> my HEAD is at cae004cabb [18:57:27 CEST] <KTSamy> that doesn't include the last fix for lilv [22:21:57 CEST] <AndroidDeveloper> Hello! Am I allowed to use binary file (static linking, compiled with --enable-static) in Android closed-source application (apk) and provide user an option to set its own path to any FFmpeg binary file he wants (to use it instead of mine)? [22:24:10 CEST] <JEEB> with LGPL I see that as long as you give the user the source code you used and the possibility to switch it "should" be OK. With GPL if it only works with those GPL components then you can't keep your thing only closed source since I'd consider your application be clearly requiring GPL software. [22:24:16 CEST] <JEEB> but IANAL [22:24:37 CEST] <JEEB> AndroidDeveloper: and you're just calling ffmpeg.c and not linking against the libraries? [00:00:00 CEST] --- Mon May 14 2018

1 0

ffmpeg.log.20180513
by burek 14 May '18

14 May '18

[00:01:16 CEST] <faLUCE> hello. Given myfile.mp4, how can I CUT video (while preserving audio) from 00:01:03 to 00:01:10 ? [00:31:47 CEST] <klaxa> faLUCE: use -ss and -t or -ss and -to ? [00:33:39 CEST] <faLUCE> klaxa: sorry, I wrote a wrong question. I want to DELETE video from 00:01:03 to 00:01:10 (without re-encoding) [00:34:07 CEST] <klaxa> use -ss and -t and concat? [00:35:41 CEST] <faLUCE> klaxa: I tried ffmpeg -i "concat:la-vestale-video-part1.mp4|la-vestale-video-part2.mp4" -c copy lavestalesolovideo.mp4 but the result is only the first part [00:36:47 CEST] <klaxa> hmm... can you try using .ts as intermediate instead of .mp4? [00:37:07 CEST] <faLUCE> ok, let's try [00:40:54 CEST] <c_14> you want to delete video while preserving audio? [00:40:57 CEST] <c_14> so you want it to be blank? [00:41:07 CEST] <c_14> just overlay with black? [00:44:24 CEST] <faLUCE> thanks klaxa, it worked with ts. c_14 I want to add blank video from 00:01:03 to 00:01:10 [00:44:31 CEST] <faLUCE> black video, sorry [00:45:04 CEST] <faLUCE> well, the problem is that the video, during this time, has some problem, so it looses sync with audio [00:45:16 CEST] <c_14> ah [00:45:21 CEST] <c_14> then klaxa's version is probably better [00:45:23 CEST] <faLUCE> so I don't know what to do exactly, I'm trying to delete this part [00:53:19 CEST] <faLUCE> what if I want to REPLACE audio from mymovie.flv with myaudio.mp3 ? [00:55:19 CEST] <c_14> all of it? [00:55:27 CEST] <faLUCE> c_14: yes [00:55:37 CEST] <faLUCE> both audio have same duration [00:55:42 CEST] <c_14> just have 2 inputs and use -map [00:56:14 CEST] <faLUCE> so, ffmpeg -i mymovie.flv -i myaudio.mp3 ..... output.flv ? [00:56:47 CEST] <c_14> yeah, but with -map 0:v and -map 1:a [01:05:21 CEST] <faLUCE> thanks c_14 [09:08:51 CEST] <th3_v0ice> Hi guys, I have been using ffmpeg c API for some time, but recently noticed that last frame is not written to the output. I tried sending the NULL packet to the av_interleaved_write_frame() but that doesnt flush the packet, even tho I have saved all of the frames as pictures and they are all accounted for. What could be the problem? Thanks! [09:11:40 CEST] <rindolf> th3_v0ice: hi [09:12:13 CEST] <rindolf> th3_v0ice: did it happen in previous ffmpeg versions? [09:13:01 CEST] <th3_v0ice> rindolf: I am currently using 3.4.2 version. My last resort is to use the 4.0 but that requires updating a lot of code. [09:13:31 CEST] <th3_v0ice> I am not sure if it was happening in the previous versions. I started with 3.4.2 [09:16:52 CEST] <rindolf> th3_v0ice: ah [09:16:52 CEST] <th3_v0ice> rindolf: It shows as that the packet was written. But decoding the output mp4 file into the YUV shows 1 frame less. [09:17:12 CEST] <rindolf> th3_v0ice: ok [09:33:12 CEST] <th3_v0ice> rindolf: Any hints as to what may be the problem? [09:33:26 CEST] <rindolf> th3_v0ice: no idea [09:34:13 CEST] <th3_v0ice> rindolf: Ok, thanks anyway :) [09:34:25 CEST] <rindolf> th3_v0ice: you're welcome [12:35:28 CEST] <spood> Allo [12:36:20 CEST] <spood> Hi [14:41:10 CEST] <faLUCE> Hello. I'm trying to replace the audio track in a audio+video file, with this command: " ffmpeg -i La_Vestale-704x400-832k.flv -i lavestaleuff.ac3 -vcodec copy -acodec copy -map 0:v -map 1:a la-vestale-sync.flv " -----> but get an error: http://paste.ubuntu.com/p/3kGk6CvWsd/ . What's wrong? [14:42:26 CEST] <klaxa> >Audio codec ac3 not compatible with flv [14:42:31 CEST] <klaxa> can't use ac3 in flv [14:42:54 CEST] <faLUCE> klaxa: which codec can I use? [14:43:02 CEST] <klaxa> mp3 i think [14:43:14 CEST] <c_14> probably also aac [14:43:27 CEST] <faLUCE> I tried with mp3 but got the same error [14:43:38 CEST] <klaxa> also only 44.1 khz iirc [14:43:52 CEST] <klaxa> flv is weird like that [14:44:31 CEST] <faLUCE> in fact the problem is in the sample rate [14:45:00 CEST] <klaxa> yeah [14:45:12 CEST] <klaxa> even says so >[flv @ 0x55f823606ea0] FLV does not support sample rate 48000, choose from (44100, 22050, 11025) [14:45:49 CEST] <JEEB> it supports misc sample rates with AAC [14:45:53 CEST] <JEEB> but not with other formats [14:46:02 CEST] <faLUCE> JEEB: so I can use AAC ? [14:46:19 CEST] <JEEB> yes, the latest FFmpeg should let you put in AAC at 48kHz just fine [14:46:23 CEST] <JEEB> into FLV [14:46:28 CEST] <faLUCE> let's try [14:46:31 CEST] <klaxa> oh? that's new [14:46:39 CEST] <JEEB> not really new, it's been in the spec for quite a while [14:46:51 CEST] <JEEB> for AAC they just say "write stereo, 44.1kHz" here for shits and giggles [14:47:06 CEST] <JEEB> and tell the implementation to actually parse the data from the AAC bit stream headers [14:47:20 CEST] <faLUCE> otherwise, how can I reasmple myfile.wav from 48kHz to 44Khz ? [14:47:28 CEST] <JEEB> you don't need to resample with AAC [14:47:31 CEST] <klaxa> ok that's new since the last time i did something with flv like 4 years or so ago [14:47:44 CEST] <faLUCE> JEEB: my ffmpeg version is of some months ago [14:47:58 CEST] <furq> 48k aac in flv has worked for ages [14:48:07 CEST] <faLUCE> ok [14:48:40 CEST] <JEEB> yea, actually I think it's been specified proper in FLV for quite longer than when FFmpeg improved the check [14:48:49 CEST] <JEEB> we just noticed at some point that the check was bullshit [14:48:52 CEST] <furq> i meant in ffmpeg but yeah [14:49:05 CEST] <JEEB> yea even in FFmpeg it was quite a few years ago IIRC [14:50:30 CEST] <furq> faLUCE: i take it you actually need to use flv [14:50:35 CEST] <furq> presumably for rtmp [14:51:54 CEST] <JEEB> and yea, it seems like this might have gotten fixed in flvenc back in 2008 [14:52:03 CEST] <JEEB> which is from before git [14:52:06 CEST] <furq> nice [14:52:26 CEST] <furq> i knew it was at least 2012 because i was using it pretty regularly then [14:53:19 CEST] <JEEB> but yes, everything else than MP3 and AAC seems to get the boot with 48kHz [14:53:36 CEST] <furq> it doesn't support any other worthwhile audio codecs anyway [14:53:45 CEST] <JEEB> yes [14:53:58 CEST] <JEEB> and adobe making no additions to it make it even sadder than companies have semi-standardized to it as ingest [14:54:25 CEST] <JEEB> well, I am not really 100% sure if smooth streaming is much better, but at least MS specified HEVC in it, har har har [14:54:29 CEST] <JEEB> and netflix VP9 [14:54:55 CEST] <JEEB> although it seems like there's interest for MPEG-TS in UDP and proper fragmented isobmff for ingest [14:55:04 CEST] <JEEB> latter through HTTP [14:55:12 CEST] <furq> yeah it's annoying flv doesn't support ac3 [14:55:13 CEST] <JEEB> like, long-going eternal POST kind of things [14:55:24 CEST] <furq> but i guess there's not even any procedure by which you'd get that added [14:55:34 CEST] <furq> other than "just start doing it and hope everyone else notices" [14:55:37 CEST] <furq> the apple technique [14:55:42 CEST] <JEEB> you could prod Adobe but they're most likely not interested [14:55:45 CEST] <furq> right [14:55:51 CEST] <JEEB> and so far we said nope at some random codec id being added for HEVC by the chinese [14:56:02 CEST] <JEEB> because seriously, if you want to still use FLV - go to adobe [14:56:07 CEST] <JEEB> and make them specify it [14:56:18 CEST] <JEEB> because otherwise in theory since it's just an integer ID [14:56:23 CEST] <JEEB> they could use that for something else [14:56:30 CEST] <JEEB> it's unlikely but more likely than with strings [14:57:28 CEST] <JEEB> also looking at the history of flvenc it seems like it briefly had a feature to mux whatever, but then that was very quickly reverted. and thank goodness for that [14:57:36 CEST] <JEEB> I don't even want to think about how that worked :P [15:52:56 CEST] <acresearch> people i am trying to understand how to record and export video for youtube. instead of just doing a recording and uploading, i want to understand what audio recording then compression parameters first (then when i understand it move on to video) i am not sure where to go so i thought i ask here and someone might advise me which channel to ask? or an online resource that can educate me [16:44:54 CEST] <klaxa> acresearch: https://trac.ffmpeg.org/wiki/Encode/AAC and https://trac.ffmpeg.org/wiki/Encode/H.264 may be good starting points [16:45:03 CEST] <klaxa> also read stuff they link to you don't understand [17:06:53 CEST] <acresearch> klaxa: thanks [17:20:32 CEST] <faLUCE> I don't know how to solve that. In myvideo.flv, at 00:10:03 , video track freezes for one second and from then, audio and video go out of sync. How can I correct the sync problem? [17:21:15 CEST] <faLUCE> should I use a video editor for that, or I can obtain that result with ffmpeg ? [18:49:53 CEST] <djk> Any hints on why an rtmp t facebook live would get " Input/output error" [18:50:24 CEST] <JEEB> -v verbose and the error usually comes before that. the end result is an IO error [18:53:39 CEST] <djk> RTMP_ReadPacket, failed to read RTMP packet header [18:53:59 CEST] <fooman2011> Hello. I'm tyring to debugging a problem and i'm stuck in the code. In the file hls.c there is a line: ret = s->io_open(s, pb, url, AVIO_FLAG_READ, &tmp); And I don't find what is this io_open function. Could you please help me to understand ? Maybe you're more familar with this code. [18:54:47 CEST] <fooman2011> it should be an http get request [18:59:26 CEST] <djk> I guess the static builds don't include support of -v? I get verbose info with a local compile of 2.8 but the 4.0 that I downloaded doesn't show any verbose. [19:00:15 CEST] <JEEB> uhh, that would require a very special way of doing stuff :P [19:00:23 CEST] <JEEB> the thing is, though, that -v requires a parameter [19:00:27 CEST] <akk> Hi -- I'm trying to make an animation from a series of images named yyyy-mm-dd.png, e.g. 2012-09-24.png [19:00:28 CEST] <JEEB> so -v PARAMETER [19:00:32 CEST] <JEEB> -v verbose for example [19:00:42 CEST] <akk> Is there any way to do that short of renaming them all to img0001.png, img0002.png etc.? [19:01:38 CEST] <JEEB> fooman2011: without looking at the internal code the s is probably an internal avformat context because the hls thing is a "meta" muxer, and io_open is a set function pointer for whatever is being called [19:01:46 CEST] <JEEB> or it is the AVIO context [19:01:50 CEST] <JEEB> one or the other [19:02:04 CEST] <JEEB> you should figure out what structure "s" is if you look upwards in the code of that function [19:06:00 CEST] <djk> right I have -v verbose but the static build doesn't show the verbose details. odd probably me [19:08:26 CEST] <JEEB> they could have been later moved to -v debug, or you have a different RTMP implementation going [19:08:29 CEST] <fooman2011> JEEB: thanks [19:08:31 CEST] <JEEB> (there's two available) [19:10:08 CEST] <djk> two rtmp? [19:10:45 CEST] <JEEB> the librtmp wrapper (older), and the internal rtmp implementation by wbs [19:10:49 CEST] <djk> frustrating thing is I had a process working about a year and yesterday the process stopped working [19:12:30 CEST] <djk> ok -v debug works now to figure out things [19:12:32 CEST] <djk> thank you [20:02:45 CEST] <fooman2011> Ok I think that there is a bug about cookies when you try to open a hls [20:03:07 CEST] <fooman2011> the cookies are not correctly transmitted for all http request [20:03:31 CEST] <fooman2011> I have identified one location where there are lost [20:03:40 CEST] <fooman2011> but it seems to have at least another [20:03:47 CEST] <fooman2011> any idea about this king of problem ? [20:05:30 CEST] <fooman2011> king => kind .. [21:41:58 CEST] <Asterisk> I have a weird issue with chaining filters together -- I'm getting different results doing two scale filters in sequence from what I get if I write to an intermediate file (losslessly) and run each filter in a separate ffmpeg command. [21:45:53 CEST] <Asterisk> The input is RGB at 320x200, and my goal was to first upscale to 1600x1200 with a nearest-neigbor scalar, then downscale to 960x720 using bilinear. [21:47:14 CEST] <Asterisk> See https://i.imgur.com/SIfpOXg.png -- the first column is from doing scale=1600:1200:sws_flags=neigbor, outputing with libx264rgb losslessly, then running scale=960:720:sws_flags=bilinear. [21:48:10 CEST] <Asterisk> The second column is from a single instance of "scale=1600:1200:sws_flags=neighbor,scale=960:720:sws_flags=bilinear" -- if you zoom in, you'll see that it's full of artifacts. [21:48:56 CEST] <Asterisk> The third column is just upscaling the source to 960x720 with bilinear without doing 1600x1200 first, so you can see why I want to do the two filters in sequence. [21:50:24 CEST] <Asterisk> The first column is the output I want, so why do I get artifacting when I do both scale filters in sequence? Is ffmpeg converting the pixel format differently in between the scale filters or something? [22:35:40 CEST] <faLUCE> I don't know how to solve that. In myvideo.flv, at 00:10:03 , video track freezes for one second and from then, audio and video go out of sync. How can I correct the sync problem? [22:35:42 CEST] <faLUCE> should I use a video editor for that, or I can obtain that result with ffmpeg ? [23:04:18 CEST] <kepstin> Asterisk: when you're doing the command with both filters, what's the pixel format of the final output? [23:04:56 CEST] <Asterisk> RGB [23:04:57 CEST] <kepstin> Asterisk: if your input is rgb and output is yuv420p or something, the problem might be that it's doing the conversion too early. [23:05:27 CEST] <Asterisk> I'm keeping everything in RGB and using libx264rgb for everything. [23:05:53 CEST] <Asterisk> It happens even with -pix_fmt rgb0 [23:06:44 CEST] <Asterisk> But the input source (from DOSBox) is a capture of a 16-color EGA game, and it's actually using an 8-bit palette. [23:07:28 CEST] <Asterisk> Still, the problem doesn't occur if I do the two scale filters sequentially in separate ffmpeg commands. [23:08:23 CEST] <kepstin> Asterisk: can you try running the command with both filters with "-v verbose" and pasting the output here? That verbosity will make it log the format conversions in the filter chain [23:08:48 CEST] <Asterisk> Sure, let me run it with verbose output. [23:09:14 CEST] <kepstin> Asterisk: if the input is paletted, adding something like a "format=rgb24," at the start of the filter chain might fix it. [23:10:35 CEST] <Asterisk> I'll try it with and without that using verbose output. [23:14:17 CEST] <Asterisk> Here's the original command output: https://pastebin.com/raw/ZKqzgbUn [23:14:44 CEST] <Asterisk> It looks like the RGB conversion *is* taking place in the middle of the filter chain. [23:15:00 CEST] <kepstin> yeah, it's running the bilinear scale while doing the pal8 to rgb24 conversion, i could see that messing up [23:15:11 CEST] <kepstin> my suggestion with adding a format to the filter chain should fix it [23:15:24 CEST] <Asterisk> Let me try specifying the format as you suggested. [23:16:22 CEST] <Asterisk> That did it. Thanks! [23:49:11 CEST] <kerio> can the palette be yuv instead of rgb? [23:51:58 CEST] <kepstin> i don't think ffmpeg supports any paletted yuv formats. [23:55:52 CEST] <kepstin> i'm not really sure it would be useful - the main benefit of yuv is that it makes compressing image planes separately more efficient [23:56:37 CEST] <kepstin> but with paletted images, you don't have separate image planes, and the palette is typically not compressed, so... might as well just store the rgb and save a conversion. [23:56:37 CEST] <JEEB> yea, and the RGB paletted things in FFmpeg seem to be quite far just an afterthought [23:57:36 CEST] <JEEB> basically I wouldn't care too much about the palettes in stuff like DVD/DVB/PGS subpictures [23:57:53 CEST] <JEEB> if you wanted raw YCbCr output I'd probably just give you 4:4:4 YCbCr instead of RGB [23:58:18 CEST] <JEEB> RGB out of those decoders isn't paletted currently anyways [23:58:42 CEST] <kerio> kepstin: i like having the luminance as a channel tho :< [00:00:00 CEST] --- Mon May 14 2018

1 0

ffmpeg-devel.log.20180512
by burek 13 May '18

13 May '18

[00:39:16 CEST] <tmm1> JEEB: have a link to your 'late pcr' sample? [00:47:40 CEST] <JEEB> pm'd a link since I hadn't cut it at all [01:00:43 CEST] <tmm1> ah ok i see, two teletext packets with wildly behind pts before the first pcr shows up [01:01:10 CEST] <JEEB> yes [01:01:20 CEST] <JEEB> because their timestamps are 5xxxxxx [01:01:24 CEST] <JEEB> while video is 8xxxxx [01:01:32 CEST] <JEEB> difference about ~8.5h [01:01:41 CEST] <JEEB> and then as soon as PCR comes they start getting adjusted [01:03:33 CEST] <tmm1> using -fix_teletext_pts, or is there some other generic pts adjustment too [01:03:56 CEST] <JEEB> I think it's generic because I don't think I used that option [01:04:21 CEST] <JEEB> also it gets funny when lavf reads in the timestamp after the video track's [01:04:40 CEST] <JEEB> it then decides there's a wrap-around and puts it like 20 hours in the future [01:06:04 CEST] <JEEB> the worst thing of course is that everyone seems to handle those with PCR, so nobody cares if the PTS is all over the place splattered on the walls :D so you can't really do much more than wait for the delicious PCR in one way or another [01:10:21 CEST] <cone-622> ffmpeg 03Michael Niedermayer 07master:d628caf54f57: avformat/mxfenc: Add Sample width/height/x offset/y offset, Display x offset and F2 offset [01:10:21 CEST] <cone-622> ffmpeg 03Michael Niedermayer 07master:10ca419dd8a3: avformat/mxfenc: Set color siting to 0 for D10-MXF [01:16:18 CEST] <JEEB> but for now, some sleep [02:59:25 CEST] Action: kierank agrees with atomnuker [02:59:30 CEST] <kierank> about twitter poll [02:59:41 CEST] <atomnuker> that was quick [02:59:54 CEST] <kierank> but it's not 2k [02:59:59 CEST] <kierank> it's 256 bytes [03:00:05 CEST] <kierank> so maybe not [03:00:44 CEST] <atomnuker> fragmentation then in case you have anther LUT which doesn't fit in L1 [03:01:16 CEST] <kierank> could well be that a synthetic benchmark doesn't match reality [03:02:55 CEST] <atomnuker> definitely won't [04:10:32 CEST] <philipl> BtbN, wm4: So, as expected, it's all fine. It's the same decoder and poll after a seek. So no worries. [11:07:44 CEST] <aleontiev> What is the meaning of bits_per_coded_sample for video streams? Is it the same as total amount of memory needed to store pixel in encoded stream? [11:26:29 CEST] <nevcairiel> there is no clear use for that property in encoded video [11:30:59 CEST] <aleontiev> OK, but for rawvideo? [12:16:47 CEST] <durandal_1707> atomnuker: you sure you will finish it this weekend? [12:45:12 CEST] <cone-648> ffmpeg 03Paul B Mahol 07master:9b6f8fb25df6: avfilter/vf_deblock: add timeline support [14:56:11 CEST] <atomnuker> durandal_1707: might take a bit longer, I'm reorganizing the tables and merging the init functions [14:56:37 CEST] <atomnuker> and wondering why the init function is templated and how that even works [15:05:59 CEST] <durandal_1707> atomnuker: so expect it arround next year this time? [15:44:40 CEST] <atomnuker> lol no [15:48:09 CEST] <durandal_1707> 5 months passed for atrac9 and still nothing, so anything is possible [15:49:28 CEST] <cone-648> ffmpeg 03Paul B Mahol 07master:1c2e5fc4546f: avfilter/vf_maskedmerge: add slice threading [16:10:28 CEST] <atomnuker> durandal_1707: I did take a look at that 2 weeks ago, seems to be a problem with demuxing [16:10:53 CEST] <atomnuker> also one track from the testset breaks band extension, just need to fix that [16:11:32 CEST] <atomnuker> I'll leave the demuxing problem in as a todo, can't figure it out [16:11:52 CEST] <atomnuker> it only happens on files from one game anyway [16:54:44 CEST] <durandal_1707> there appears someone uses owdenoise filter [17:02:36 CEST] <durandal_1707> some even compared owdenoise and hqdn3d with avisynth filters, and wrote like author of hqdn3d is Fabrice [17:07:15 CEST] <JEEB> and I guess he isn't? :) people have always various funny ideas of things [17:12:09 CEST] <atomnuker> the netflix guys used it to develop the film grain reconstruction av1 experiment [17:12:25 CEST] <atomnuker> told them to use nlmeans back in august, don't know if they did [18:15:03 CEST] <durandal_1707> ubitux: nlmeans=s=4:p=7:r=65 this are translated parameters used by KNLMeansCL for that gray sample i uploaded, yours implemenation have bad edges [18:16:37 CEST] <durandal_1707> and i can confirm that tnlmeans, another implementation (without need for OpenCL)- does not have this bug, it gives similar results as KNLMeansCL [18:18:12 CEST] <durandal_1707> are you gonna fix this, or you are working on subtitles? [18:44:44 CEST] <JEEB> michaelni: I wonder if you just lowered the possibility of having a lot of mp3 streams in mpeg-ts inputs with those patches 8) [18:45:42 CEST] <durandal_1707> is that bad or good? [18:46:35 CEST] <JEEB> I think that's good, mislabeling "unknown" as "mp3" isn't too great [18:47:29 CEST] <BtbN> ffmpeg doesn't have an OpenCL deinterlace filter (yet), does it? [18:48:12 CEST] <jamrial> i think not [18:48:24 CEST] <jamrial> isn't there a gsoc student doing opencl in some form? [18:48:24 CEST] <JEEB> nope [18:48:29 CEST] <JEEB> yea [18:48:38 CEST] <BtbN> I basically want to port one to CUDA [18:48:39 CEST] <JEEB> I think someone was supposed to be doing some sort of opencl? [18:48:58 CEST] <BtbN> And I'm bad at writing the actual code, so having something to just port would be nicer [18:49:21 CEST] <BtbN> I mean, getting a stupid simple bob deinterlacer would probably be possible, but who wants that [18:49:52 CEST] <BtbN> can't write a generic filter that runtime-loads cuda code sadly [18:51:04 CEST] <jamrial> well, we first need an opencl one that can run on any hardware :p [18:51:29 CEST] <BtbN> At least that wouldn't be an issue for CUDA [18:52:15 CEST] <durandal_1707> are .exe still detected as .mp3 ? [18:53:54 CEST] <michaelni> they should not be anymore, but i dont have many exe on my linux box [18:54:22 CEST] <durandal_1707> and elf? [18:58:32 CEST] <michaelni> the one i tried is no longer detected as mp3 [19:01:35 CEST] <durandal_1707> excellent! [19:07:29 CEST] <BtbN> I don't get why there is basically zero pre-existing code for OpenCL/CUDA deinterlacers. Everyone just using the in-GPU ones it seems [19:09:57 CEST] <BtbN> it doesn't help that the best algorithm, NEDI, also shares name with some neural network deinterlacing stuff [19:10:55 CEST] <BtbN> From how I understand it, nedi "deinterlacing" is just throwing away the even or odd fields, and then scaled the remaining ones up? [19:13:51 CEST] <JEEB> more or less yes, except you can also do it for both fields [19:13:58 CEST] <JEEB> thus you get full rate bobbing [19:14:37 CEST] <BtbN> what even is considered the state of the art deinterlacing algorithm right now? [19:14:43 CEST] <BtbN> except for that neutral network stuff [19:15:30 CEST] <JEEB> well you have two different problems anyways. pictures that are not really connected to each other, and pictures that are part of the same picture [19:17:09 CEST] <atomnuker> before neural networks it used to be motion estimated deinterlacers [19:17:19 CEST] <atomnuker> but I think neural networks do better [19:18:22 CEST] <JEEB> I mean, inter prediction can work with deinterlacing, but it's a hard problem [19:18:25 CEST] <JEEB> to make it look good [19:18:33 CEST] <JEEB> thus it is just simpler to throw good scaling at the problem [19:18:46 CEST] <BtbN> well, I can't find any documented algorithm for motion adaptive deinterlacing that could easily be implemented [19:18:55 CEST] <JEEB> I think there was an avisynth script called QTGMC [19:19:05 CEST] <JEEB> which picked up NNEDI3 and some mocomp stuff [19:19:18 CEST] <BtbN> but nnedi3 is the neural network thing? [19:19:19 CEST] <JEEB> used to be the top of the line stuff for deint in avisynht world [19:19:33 CEST] <JEEB> yes, it mixed the stuff up [19:19:40 CEST] <JEEB> doing mocomp probably on top of the upscaled images [19:19:46 CEST] <JEEB> never looked into its internals [19:19:51 CEST] <BtbN> I'm looking for something to implement in CUDA, to replace the inaccessible deinterlacer in cuvid [19:20:27 CEST] <JEEB> yes, and you were asking about "state of the art", and I gave thee the state of the art in Avisynth communities. of course for academical stuff I can point you towards prunedtree [19:30:24 CEST] <BtbN> I don't get this whole probing/mp3/txt security debate. If you have the ability to make ffmpeg open arbitrary system files, you have already a bit problem no matter what. No matter if we disable more and more demuxers/formats, something is going to open it, and it will have ways to attack it. [19:31:57 CEST] <j-b> Well, sure, but in the automatic/probing part, it should tell you "this is weak detection" [19:32:02 CEST] <JEEB> I think the "security" side is just additive. it was generally about "people throw txt or exe/elf files at lavf and except them to get two middle fingers raised" [19:49:38 CEST] <Compn> i love the txt decoder in ffmpeg :D [19:53:39 CEST] <durandal_1707> for mplayer devs thats normal [20:49:30 CEST] <cone-291> ffmpeg 03Aman Gupta 07master:6f50be876016: avformat/mpegtsenc: set AVFMT_NODIMENSIONS [20:49:30 CEST] <cone-291> ffmpeg 03Aman Gupta 07master:18074b309fb4: avformat/hlsenc: set AVFMT_NODIMENSIONS [20:50:55 CEST] <cone-291> ffmpeg 03Aman Gupta 07master:9152c1e49555: avformat/mpegts: parse sections with multiple tables [20:50:56 CEST] <cone-291> ffmpeg 03Aman Gupta 07master:7db022e67bab: avformat/mpegts: reindent after last change [21:03:49 CEST] <Mindless`> I have a small bug to report, but Trac won't let me sign up (captcha is broken) [21:03:49 CEST] <Mindless`> - man page says option is named "xsd_compliant" -- https://github.com/FFmpeg/FFmpeg/blob/1c2e5fc4546f2c80212add77015003de200f7… [21:03:49 CEST] <Mindless`> - actual option name is "xsd_strict" -- https://github.com/FFmpeg/FFmpeg/blob/1c2e5fc4546f2c80212add77015003de200f7… [21:10:10 CEST] <cone-291> ffmpeg 03Aman Gupta 07master:cae004cabb68: doc: fix incorrect reference to xsd_compliant option [21:10:11 CEST] <tmm1> Mindless`: thanks [21:10:23 CEST] <JEEB> :) [21:12:10 CEST] <Mindless`> no problem, thanks for fixing it [21:37:01 CEST] <BtbN> philipl, what format are OpenGL textures in when mapped to CUDA? 0BGR? [21:41:47 CEST] <durandal_1707> we use C99 in FFmpeg, so isnormal() is expected to always be available? [21:44:37 CEST] <jamrial> durandal_1707: we have wrappers for isinf() and isnan() in libavutil/libm.h, so probably not [21:45:16 CEST] <jamrial> then again, most of those were for old msvc, and i think we're not supporting versions older than 2013 (first one c99 compliant) anymore [21:45:43 CEST] <JEEB> yea, I think 2013 update 2 is needed [21:46:29 CEST] <atomnuker> seriously? [21:46:46 CEST] <atomnuker> right, then its time to accept for (int loops [21:47:07 CEST] <JEEB> yea, the msvc conversion thing possibly still works, but effectively we don't test nor care about it in general [22:20:18 CEST] <durandal_1707> ubitux: i fixed excessive edges artifacts and added option for less blurred denoising [23:08:07 CEST] <philipl> BtbN: I don't know. I've only done the write-target work where I create a texture with the right number of channels for YUV data. [23:08:35 CEST] <philipl> I assume that any GL format is representable. You get however many channels there are in the array and in CUDA they are just bytes. [23:09:49 CEST] <philipl> BtbN: I found a GL implementation of yadif [23:09:53 CEST] <philipl> I can dig it up again for you [23:10:12 CEST] <BtbN> A GL implementation? [23:10:25 CEST] <philipl> shader implementation, yes. [23:10:34 CEST] <BtbN> interesting. Yes, that should be portable [23:13:22 CEST] <philipl> While I'm digging that out, here is a simple GL one from gstreamer [23:13:24 CEST] <philipl> https://github.com/GStreamer/gst-plugins-base/blob/master/ext/gl/gstgldeint… [23:14:11 CEST] <philipl> and here is the yadif: https://git.sesse.net/?p=movit;a=tree [23:15:17 CEST] <philipl> https://git.sesse.net/?p=movit;a=blob;f=deinterlace_effect.frag;h=140f4205e… [23:15:35 CEST] <JEEB> huh, gl version of yadif [23:17:00 CEST] <BtbN> it's RGB instead of YUV, but that shoudln't be too different [23:18:15 CEST] <wm4> didn't we know about it and it was bad because GPL? [23:18:15 CEST] <durandal_1707> GPU cant do YUV [23:18:28 CEST] <philipl> wm4: we knew about it and it was useless for mpv because of GPL, yes. [23:18:39 CEST] <philipl> I assume BtbN is not bothered by that. [23:18:41 CEST] <BtbN> of course it can, the GPU doesn't care what numbers it crunches [23:18:46 CEST] <wm4> useless fo broader ffmpeg use too [23:18:56 CEST] <BtbN> it will be non-free in ffmpeg anyway [23:19:02 CEST] <philipl> Even better. [23:19:06 CEST] <philipl> GPL non-free :-) [23:19:22 CEST] <durandal_1707> why non-free? [23:19:25 CEST] <BtbN> because CUDA [23:19:57 CEST] <BtbN> I wonder what license you end up with if using https://forum.doom9.org/showthread.php?p=980375#post980375 as basis [23:20:15 CEST] <durandal_1707> please remove all non LGPL parts of ffmpeg and make new fork [23:21:40 CEST] <philipl> Only GPL+non-free builds will be allowed from now on. [23:47:58 CEST] <philipl> BtbN: double-non-free. [00:00:00 CEST] --- Sun May 13 2018

1 0

ffmpeg.log.20180512
by burek 13 May '18

13 May '18

[00:57:03 CEST] <wfbarksdale> random question, do hardware encoders ever have support for doing a YUV -> RGB conversion as part of the decoding process? [00:57:19 CEST] <wfbarksdale> erm, decoders i meant [00:57:55 CEST] <JEEB> yes, that's why f.ex. mpv's manual has tons of warnings about that [00:58:14 CEST] <JEEB> they might or might not get it correct, and their historical quality in chroma upscaling before the conversion could be either OK or less OK [00:58:30 CEST] <JEEB> which is why generally it is preferred if a hwdec interface gives you the original YCbCr [00:58:46 CEST] <JEEB> that also enables you to verify that the decoder correctly decodes things against reference files etc [00:58:50 CEST] <c_14> Isn't that the point of hardware decoders? that they return frames in gpu memory for "immediate" display? [00:59:00 CEST] <JEEB> they can be in GPU memory [00:59:02 CEST] <c_14> or is the download/upload not performance relevant? [00:59:06 CEST] <JEEB> but they don't have to be RGB [00:59:33 CEST] <JEEB> dxva2/d3d11va/vaapi all have interoperability with direct3d or opengl [01:00:20 CEST] <wfbarksdale> i see, also it from googling it looks like the encoders sometimes will handle the reverse RGB -> YUV for you also [01:00:29 CEST] <JEEB> yes [01:00:30 CEST] <wfbarksdale> could be something worth trying out for my app [01:00:52 CEST] <JEEB> by now most most likely use BT.709? or maybe not? [01:00:56 CEST] <JEEB> fun game of guessing [01:01:32 CEST] <wfbarksdale> seems like there is always a lot of probing that you have to do to get hardware support working [01:01:43 CEST] <wfbarksdale> bleh [01:03:01 CEST] <JEEB> hw decoding has surely gotten better at least on desktop APIs than it was before. but it's still a mess on a larger scale with APIs that let you get interoperability but then force you into RGB etc [01:03:35 CEST] <JEEB> I just wish everything standardized on VAAPI on linux. Windows is nice because MS just mandates DXVA2 and D3D11VA interfaces :P [01:17:26 CEST] <wfbarksdale> One more question: I have a processing pipeline pulling both video and audio streams from mp4 files. It is preferable to have the packets be read out in order of their pts, irrespective of which stream the packets are in. I have started work on Demuxer component which i imagined would read packets consecutively, buffering packets as needed when interleaved packets are read. But I was wondering is there a canonical way to achieve [01:17:26 CEST] <wfbarksdale> this with avformat? essentially having two separate file pointers advancing within the different streams? [01:18:09 CEST] <JEEB> not sure of lavf's exact logic but it should give you packets in a usable order [01:18:11 CEST] <wfbarksdale> (c++ API) [01:18:18 CEST] <JEEB> it's C, actually [01:18:21 CEST] <JEEB> but usable from C++ as well [01:18:28 CEST] <wfbarksdale> meant C :) [01:18:35 CEST] <wfbarksdale> using it from C++ [01:19:11 CEST] <JEEB> but yea, it has just one file pointer but it should be giving you the things A->B in a relatively sane order [01:19:23 CEST] <JEEB> anyways, sleep :P [01:19:43 CEST] <wfbarksdale> what I have seen is that I can read frames, but they are interleaved. So a client of the demuxer says, "I want the next Audio Packet", so the demuxer will read a packet, and if it a video packet, it will have to keep reading, buffering the video packets, until it gets to an audio packet [01:20:15 CEST] <wfbarksdale> demxuer = my c++ demuxer component, not avformat [01:20:55 CEST] <wfbarksdale> i need to buffer the video packets, because the video stream is also being consumed [01:21:13 CEST] <wfbarksdale> just wondered if this use case was accomadated int avformat and I could avoid having to write the logic myself [01:36:51 CEST] <klaxa> hmm, so i've found out that i need a bitstreamfilter for mp4 -> mkv with aac, when i compile remuxing.c from doc/examples it does that automatically [01:37:13 CEST] <klaxa> is it because my output is not seekable? :S [01:40:45 CEST] <klaxa> hmm even when writing to pipe it works properly [01:40:57 CEST] <c_14> maybe check that AVFMT_FLAG_AUTO_BSF is set? [01:42:48 CEST] <c_14> the mkv muxer has the automatic bitstream filter checking function since b287d7 (2015) so it should work [01:43:39 CEST] <klaxa> yeah i looked at those commits [01:43:49 CEST] <klaxa> (thanks for all these pointers again btw) [01:46:08 CEST] <ariyasu_> can someone help me dumping frames from hevc video [01:46:41 CEST] <ariyasu_> i use this command "ffmpeg.exe -ss 50 -i test.ts -r 1 out.bmp" to dump 1 frame 50 seconds into a video [01:47:02 CEST] <ariyasu_> it works great for everything except hevc where the frame is messed up [01:47:16 CEST] <ariyasu_> console output = https://pastebin.com/gE8w3hpg [01:47:26 CEST] <ariyasu_> example of a dumped frame = https://i.imgur.com/UcHwy0I.jpg [02:24:31 CEST] <ariyasu_> no one got any ideas? [02:25:27 CEST] <klaxa> can you play the file even? [02:26:25 CEST] <ariyasu_> yeah it plays fine [02:26:43 CEST] <ariyasu_> using mpc or vlc to dump a frame also works fine [02:26:55 CEST] <c_14> you probably want -frames:v 1 instead of -r 1 [02:27:02 CEST] <c_14> it looks like your keyframe is corrupt though [02:27:40 CEST] <c_14> maybe trie -ss 50 as an output option instead of an input option? [02:27:42 CEST] <c_14> *try [02:28:13 CEST] <ariyasu_> doing "-frames:v 1" produces the same result [02:28:39 CEST] <c_14> yeah, it should just get rid of the other error/warning [02:28:44 CEST] <c_14> but switching the seek type might fix it [02:30:25 CEST] <ariyasu_> moving -ss 50 to output, stalls ffmpeg [02:30:36 CEST] <c_14> yeah, it'll take a while [02:30:38 CEST] <c_14> but it should get there [02:30:45 CEST] <c_14> it's seeking after decoding instead of before now [02:30:59 CEST] <ariyasu_> frame= 0 fps=0.0 q=0.0 size=N/A time=00:00:00.00 bitrate=N/A speed= 0x [02:31:11 CEST] <ariyasu_> shows this constantly and i have to kill it with ctrl + c [02:31:20 CEST] <c_14> just wait for it [02:31:23 CEST] <ariyasu_> ok i will leave it going [02:31:36 CEST] <c_14> might take ~50 seconds or more depending on how fast your cpu can decode hevc [02:32:33 CEST] <ariyasu_> https://i.imgur.com/wqFhYCL.jpg [02:32:38 CEST] Action: ariyasu_ buys c_14 a beer [02:32:54 CEST] <ariyasu_> tyvm, i will move the value to 5 now instead of 50 [02:33:15 CEST] <ariyasu_> i like to dump 1 frame before encoding that i can examing to work out if i need to crop or not [02:33:36 CEST] <c_14> np, ffmpeg probably just messed up getting the last keyframe somehow [07:33:18 CEST] <jaggz> how would I flip a video horizontally then add it back to itself to make it horizontally seamless? [07:35:47 CEST] <jaggz> oh.. cool.. I just did it in blender by flipping a uv mapping [17:22:43 CEST] <ronald> hello [17:22:56 CEST] <ronald> do you guys do support here, i dont know how to use ffmpeg right [17:23:14 CEST] <JEEB> just ask and maybe someone replies [17:23:57 CEST] <ronald> i have a folder full of videos and i want ffmpeg to only convert the .webm ones into .mp4, i tried writing the code but it doesnt work [17:24:00 CEST] <ronald> for file in ("*videos/*.webm") do ffmpeg -i -threads 1.5 -crf 50 "%%a" -i "outputs\%%a.mp4" [17:24:06 CEST] <ronald> anyone know where the error is [17:24:13 CEST] <sfan5> you're missing a ; [17:24:27 CEST] <ronald> where [17:24:31 CEST] <JEEB> I recommend you look at the bash looping tutorial :) [17:24:37 CEST] <sfan5> well that doesn't look like bash... [17:24:43 CEST] <JEEB> http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-7.html [17:24:47 CEST] <JEEB> ah [17:24:48 CEST] <ronald> sfan5, where [17:24:49 CEST] <JEEB> then batch [17:25:32 CEST] <JEEB> https://ss64.com/nt/for.html [17:25:36 CEST] <sfan5> ronald: which os are you running? [17:25:36 CEST] <ronald> where is the ; missing [17:25:40 CEST] <JEEB> seems to be an OK documentation on the for looping [17:25:42 CEST] <ronald> w7 64 [17:25:46 CEST] <JEEB> sfan5: that's most likely windows so batch [17:25:59 CEST] <sfan5> then ignore my colon about semicolons [17:26:05 CEST] <sfan5> s/colon/comment/ [17:26:25 CEST] <JEEB> ronald: take a look at the examples in the page I linked [17:26:32 CEST] <JEEB> this is a general batch thing [17:27:08 CEST] <ronald> am i supposed to do it in multiple lines or only one [17:27:35 CEST] <JEEB> I think you can do multiple as well, but this is a general batch scripting question rather than an FFmpeg question [17:27:41 CEST] <JEEB> start by echoing the values in a loop first [17:27:50 CEST] <JEEB> then when that looks like working [17:27:55 CEST] <ronald> man i only know some python [17:27:56 CEST] <JEEB> then you stop echoing and start using FFmpeg [17:27:59 CEST] <ronald> no idea what batch even is [17:28:03 CEST] <JEEB> then use python? [17:28:07 CEST] <JEEB> you can install python3 on windows [17:28:21 CEST] <JEEB> batch is a very crappy scripting language from ages before [17:28:38 CEST] <ronald> i can just write a python script in the bat? [17:28:56 CEST] <JEEB> no, just write a python script that listdir()s and executes [17:29:17 CEST] <JEEB> and then run the script instead of the batch [17:31:04 CEST] <JEEB> but you can use either, just that if you are more used to python - use python [17:31:23 CEST] <JEEB> also means you can use the same thing outside of windows, if you should ever want to [18:53:04 CEST] <djk> anyone know a change with facebook live that would cause "RTMP_ReadPacket, failed to read RTMP packet header" [19:16:55 CEST] <djk> I had a stream working with ffmpeg but now it is erroring [20:33:13 CEST] <alone-x> hello, anyone know, why i can't use [20:33:20 CEST] <alone-x> -to 100:00:00 [20:33:22 CEST] <alone-x> ? [20:33:37 CEST] <alone-x> -to 99:00:00 - working. [20:33:47 CEST] <alone-x> my file more then 105:00:00 [20:33:52 CEST] <alone-x> ... [20:34:05 CEST] <BtbN> because the format only has two digits there [20:34:13 CEST] <alone-x> yes yes [20:34:22 CEST] <alone-x> i am guessing so [20:34:26 CEST] <alone-x> but, what i need to do? [20:34:44 CEST] <BtbN> I guess convert to seconds [20:35:15 CEST] <alone-x> thank yo [20:35:18 CEST] <alone-x> thank you [20:49:54 CEST] <Mindless`> Trac won't let me sign up -- https://i.imgur.com/lkzCgGd.png [20:50:41 CEST] <BtbN> recaptcha broke, not much to be done on your end. [20:53:03 CEST] <Mindless`> BtbN: could you submit a bug report for me? it's very simple [20:53:29 CEST] <BtbN> pretty sure there is one? [20:54:30 CEST] <Mindless`> no, I mean, I was signing up to submit a bug report, but it won't let me, so could you submit one for me? [21:00:04 CEST] <BtbN> not right now, but I'm sure someone can [21:02:18 CEST] <sfan5> you can put yuvj420p into H.264, right? [21:15:07 CEST] <furq> sfan5: you can but you're supposed to use yuv420p and -color_range jpeg nowadays [21:15:31 CEST] <sfan5> i meant format-wise, so that's a yes [21:15:57 CEST] <BtbN> there is no difference format wise [21:16:05 CEST] <BtbN> it's just how the colors are interpreted [21:16:23 CEST] <BtbN> putting it in there might not be the best idea though, as there is a good chance the decoding site will misinterpret them [21:16:24 CEST] <sfan5> maybe the spec mandates limited color range, who knows.. [21:16:59 CEST] <JEEB> AVC and HEVC just have flags [21:55:48 CEST] <The-Present> Hi, ffmpeg removed -timeout option? [21:56:12 CEST] <The-Present> for me it shows unrecognized option. I am trying to stream to rtmp server [21:56:13 CEST] <JEEB> I think some options moved to rw_timeout, although I don't think the old ones got removed yet? [21:56:22 CEST] <JEEB> it's a protocol-specific option though [21:56:25 CEST] <JEEB> I wonder if RTMP ever had it [21:56:58 CEST] <JEEB> wow [21:57:01 CEST] <The-Present> ok interesting about protocol-specific. I thought they are global options [21:57:09 CEST] <JEEB> yea, you wish :P [21:57:17 CEST] <JEEB> that's why we had different types of numbers for timeouts [21:57:22 CEST] <The-Present> any way to set some sort of timeout option for rtmp [21:57:23 CEST] <JEEB> some took in microseconds, others seconds [21:57:24 CEST] <JEEB> etc [21:57:47 CEST] <JEEB> there's actually still an option for rtmp protocol called "timeout", but it is actually a "listen timeout" [21:57:48 CEST] <The-Present> yep JEEB I agree with that :) ffmpeg is now very huge [21:58:02 CEST] <JEEB> `"timeout", "Maximum timeout (in seconds) to wait for incoming connections. -1 is infinite. Implies -rtmp_listen 1"` [21:58:16 CEST] <JEEB> but that's for listening for RTMP connections [21:58:18 CEST] <JEEB> not for sending [21:58:30 CEST] <The-Present> oh what a pitty :{ [21:59:06 CEST] <The-Present> so not for sending [21:59:07 CEST] <furq> The-Present: -rw_timeout should work apparently [21:59:18 CEST] <furq> https://ffmpeg.org/ffmpeg-protocols.html#Protocols [21:59:24 CEST] <furq> at least the docs claim it works for all protocols [21:59:25 CEST] <The-Present> furq, that can be used during sending [21:59:29 CEST] <JEEB> right, that might be on a different level in lavf [22:00:38 CEST] <JEEB> yes, libavformat/avio.c has rw_timeout [22:00:39 CEST] <JEEB> {"rw_timeout", "Timeout for IO operations (in microseconds)", offsetof(URLContext, rw_timeout), AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, INT64_MAX, AV_OPT_FLAG_ENCODING_PARAM | AV_OPT_FLAG_DECODING_PARAM } [22:00:47 CEST] <JEEB> which is both for input and output [22:01:41 CEST] <The-Present> ok that didn't work [22:01:57 CEST] <The-Present> or ok sorry my bad [22:04:39 CEST] <The-Present> ok i will try that. Thanks for the heads up JEEB and furq . very much appreciated :) [22:21:02 CEST] <flat20> I'm trying to pipe in PCM, which only produces audio output every now and then, to create a wav file in realtime, but I can't get it to work. ffmpeg always condenses the silent gaps in the final .wav file. [22:21:07 CEST] <flat20> I've tried: ffmpeg -re -y -f s16le -ar 48000 -ac 2 -i pipe:0 out.wav [22:21:28 CEST] <flat20> I've also tried using anullsrc for silence like this: ffmpeg -re -y -f lavfi -i anullsrc=channel_layout=stereo:sample_rate=48000 -f s16le -ar 48000 -ac 2 -i pipe:0 out.wav [22:22:31 CEST] <flat20> Even tried looping a silent .wav file, but it seems that if I no data is coming in from the pipe, ffmpeg just pauses until more data comes. [22:23:32 CEST] <djk> is there a way to specific a window instead of screen area for ffmpeg to stream. OBS lets you select a window name which good for avoiding private thing showing up on the stream [00:00:00 CEST] --- Sun May 13 2018

1 0

ffmpeg-devel.log.20180511
by burek 12 May '18

12 May '18

[00:06:44 CEST] <durandal_1707> wm4: look at ffplay it seeks within y4m just fine [00:08:51 CEST] <wm4> durandal_1707: doesn't here [00:10:20 CEST] <JEEB> durandal_1707: explain the issue step by step on either the user or devel channel and let's see if we can get your issue sorted [00:10:43 CEST] <JEEB> we are not espers and you didn't exactly share too much about your issue [00:13:21 CEST] <durandal_1707> JEEB: how when we contradicts each other from start [00:18:07 CEST] <JEEB> I'd say it's closer to "one does not understand the other" [00:18:40 CEST] <jkqxz> jamrial: Can I infer from your comments on 5 and 6 of the H.264 SEI set that you reviewed all of it? [00:18:47 CEST] <jkqxz> (Thank you for uploading the test file, btw.) [00:19:34 CEST] <rcombs> so apparently hwcontext_dxva2 leaks threads [00:21:39 CEST] <jamrial> jkqxz: no, but i did test them and as far as fate and a bunch of samples i tried it seemed ok [00:21:45 CEST] <jamrial> none had pan-scan rectangle sei, though [00:22:49 CEST] <jkqxz> I don't have any samples with it either, but the reference decoder does parse them and agreed with the ones I created. [00:39:41 CEST] <jamrial> sounds good then :p [00:40:53 CEST] <nevcairiel> rcombs: it doesnt open any, so how would that work? :) [00:41:07 CEST] <rcombs> it doesn't itself, but d3d9.dll does [00:44:50 CEST] <jkqxz> jamrial: Ok; thank you! [00:49:50 CEST] <rcombs> looks like the threads are created in IDirect3D9Ex_CreateDeviceEx [00:55:49 CEST] <cone-593> ffmpeg 03Mark Thompson 07master:4c9741a1dddf: cbs_h264: Fix handling of unknown SEI [00:55:50 CEST] <cone-593> ffmpeg 03Mark Thompson 07master:2b4121350092: h264_metadata: Remove redundant setting of SEI payload size [00:55:51 CEST] <cone-593> ffmpeg 03Mark Thompson 07master:9d375e114ac2: h264_metadata: Fix AUD writing [00:55:52 CEST] <cone-593> ffmpeg 03Mark Thompson 07master:d94dda742c8e: cbs_h264: Add support for pan-scan rectangle SEI messages [00:55:53 CEST] <cone-593> ffmpeg 03Mark Thompson 07master:ac687add84a1: cbs_h264: Add support for mastering display SEI messages [00:55:54 CEST] <cone-593> ffmpeg 03Mark Thompson 07master:f995aa82d858: fate/cbs: Add an SEI test [01:04:04 CEST] <rcombs> I dunno if anybody feels like debugging d3d9 code [01:04:12 CEST] <rcombs> I'm definitely out of my depth there [01:08:09 CEST] <nevcairiel> i've never noticed any excess threads [01:08:17 CEST] <nevcairiel> are you sure you dont leak the hwcontext somehow [01:17:27 CEST] <rcombs> I see one place where that could happen in an OOM case, but nowhere else [01:17:31 CEST] <rcombs> (fixed that though) [01:17:44 CEST] <rcombs> user's logs don't indicate that path was taken, either [01:17:56 CEST] <rcombs> could be something driver-specific [01:18:06 CEST] <nevcairiel> if its only one user, might be a driver bug indeed [01:18:26 CEST] <rcombs> i686 binary running on 64-bit windows in VMWare [01:18:45 CEST] <rcombs> no idea why anyone would ever want to run this app in a windows VM [01:18:50 CEST] <nevcairiel> hwaccel in a VM, he deserves all the pain he gets [01:19:11 CEST] <nevcairiel> those VM hwaccel virtualization drivers are super crappy [01:19:34 CEST] <rcombs> threads apparently created like this https://gist.github.com/ae5aec2badd1eb154dbaf7c3ad9589f7 [01:19:54 CEST] <rcombs> had to stare at disas of lavu to figure out what function it was [01:22:55 CEST] <rcombs> ¯\_(Ä)_/¯ I'll tell the user to poke the vmware people and in the interim that his use-case is insane [01:36:31 CEST] <philipl> rcombs: the vmware video driver doesn't implement hwaccel does it?? [01:36:49 CEST] <rcombs> dunno, and also dunno if it matters [01:37:04 CEST] <rcombs> I open a hwaccel to test whether or not it's available [01:37:38 CEST] <nevcairiel> virtualbox at least implements virtualized dxva, i imagine vmware might as well, but i havent used it in ages [01:38:17 CEST] <nevcairiel> but these modes are generally quite unusable regardless [01:38:49 CEST] <philipl> Having worked there - I can't imagine how they'd justify the engineering investment. Their paying customers certainly don't care about video playback. [01:41:02 CEST] <rcombs> meanwhile in extremely nice: https://gist.github.com/e58670a07b529578b6a1db3186a2514d [01:41:05 CEST] <nevcairiel> a quick google suggests that it does work [01:41:16 CEST] <nevcairiel> or well, is supposed to [01:41:46 CEST] <nevcairiel> well, at least with ESXi [01:43:26 CEST] <philipl> nevcairiel: with pass-through GPUs... [01:43:45 CEST] <nevcairiel> apparently also sharing hardware between multiple VMs [01:44:14 CEST] <nevcairiel> at least D3D9, which DXVA2 is based on [05:16:06 CEST] <Compn> i cant remember the cineform hd codec in mplayer [05:16:14 CEST] <Compn> there were two versions of it [05:16:22 CEST] <Compn> one worked and the other we all tried to forget about iirc [05:16:40 CEST] <Compn> which looks about the same in ffmpeg with that sample [05:18:02 CEST] <Compn> http://cineform.com/gopro-cineform-decoder [05:18:26 CEST] <Compn> oh i might be thinking of canopus [06:09:16 CEST] <jamrial_> jkqxz: re ticket 7200 above, https://pastebin.com/szcJw45K fixes it for me [06:09:25 CEST] <jamrial_> the file has a lot of NALUs type 0 (invalid, afaik) of size 1, with that byte being zero [09:17:31 CEST] <cone-752> ffmpeg 03Tobias Rapp 07master:66ba303c5369: fate: add more tests for hue video filter [10:44:29 CEST] <JEEB> tmm1: ahahahaha. I wonder if your PMT fixing bug actually just fixed my sample :D [10:44:54 CEST] <JEEB> I seem to get PCR quicker now [10:47:39 CEST] <JEEB> although I'll have to test with my usual way first to make sure... [10:49:32 CEST] <JEEB> ah, no :) shows me how I shouldn't be lazy and test things without making sure the way of doing it is the same [11:05:31 CEST] <JEEB> tmm1: so I guess for PID switches if we would want to support stuff like switching codecs we'd just need a flag "programs X,Y,Z got updated" with a list of pointers to matching AVPrograms? [11:05:44 CEST] <JEEB> because that way you don't need to iterate over the thing yourself [11:06:24 CEST] <JEEB> ffmpeg.c would need rework of course, haven't looked at how much [11:10:22 CEST] <JEEB> not sure where such side data would get attached though [11:10:26 CEST] <JEEB> stream? which stream? [11:10:30 CEST] <JEEB> packet? which packet? [11:11:13 CEST] <JEEB> if you could attach them to the avformat context then that would make it not matter which stream's packet is getting fed to you next, I guess? [11:11:25 CEST] Action: JEEB scratches his head [11:12:03 CEST] <JEEB> the stream merging thing will work as long as you are a) OK with losing the original PIDs b) having no support for codec switches [11:51:39 CEST] <jkqxz> Trac is down? I get 503. [11:53:22 CEST] <durandal_1707> not for me [11:56:26 CEST] <nevcairiel> seems to have come back just now [11:56:29 CEST] <jkqxz> Right, working again. Odd. [12:09:14 CEST] <JEEB> trac is a bit of weird bit of software [12:09:28 CEST] <JEEB> if I recall correctly on some implementation details [16:44:26 CEST] <philipl> BtbN: after your changes, GPU memory usage in mpv for a 4k/10bit video is reduced by 25% (comparing nvdec to cuvid) [16:44:37 CEST] <philipl> 1.2GB->0.9GB [16:45:21 CEST] <BtbN> didn't wm4 say mpv uses its own hw_frames_ctx, so the memory saving effect woudln't work? [17:11:19 CEST] <philipl> Not for nvdec. It just uses a device_ctx [17:26:05 CEST] <wm4> philipl: that sounds wrong [17:31:11 CEST] <wm4> generally it does what ffmpeg tells it though (but not sure which method is preferred) [17:34:40 CEST] <BtbN> for nvdec/cuvid, giving it just a hw_device_ctx is prefred I'd say [17:34:44 CEST] <BtbN> specially now [17:47:55 CEST] <durandal_1707> ubitux: patch_diff_sq in nlmeans can be negative [17:50:07 CEST] <ubitux> durandal_1707: huh, really? [17:50:13 CEST] <ubitux> did i introduce a regression? [17:53:12 CEST] <ubitux> are you sure it's not because it's >(1<<31)? [17:54:10 CEST] <wm4> BtbN: I think it actually prefers frames_ctx over device_ctx because it can cache the memory allocations [17:54:56 CEST] <BtbN> cache the memory allocations? [17:55:01 CEST] <wm4> since mpv keeps some frames in the video pipeline during seeks, not caching the frame pool could momentarily double GPU memory use [17:55:45 CEST] <BtbN> but the internal pool already caches the allocations [17:56:06 CEST] <BtbN> It allocates 14 or so "frames" at the beginning, and then never again under normal operation [18:01:53 CEST] <durandal_1707> ubitux: you are correct, still searching why results are soo blurry [18:05:51 CEST] <ubitux> try to switch to u64 [18:05:55 CEST] <ubitux> just in case it's due to an overflow [18:19:39 CEST] <durandal_1707> ubitux: right, i compiled with integer sanitizer: libavfilter/vf_nlmeans.c:401:50: runtime error: unsigned integer overflow: 2693 - 3291 cannot be represented in type 'unsigned int' [18:19:51 CEST] <durandal_1707> libavfilter/vf_nlmeans.c:401:54: runtime error: unsigned integer overflow: 4294782596 + 186942 cannot be represented in type 'unsigned int' [18:20:28 CEST] <durandal_1707> so it intermediate needs to be long [18:22:28 CEST] <ubitux> what resolution? [18:22:37 CEST] <durandal_1707> actually something goes into negative [18:23:12 CEST] <durandal_1707> ubitux: same gray sample with fishes i had uploaded [18:35:03 CEST] <philipl> wm4: For cuda it definitely just provides a device_ctx, and that's the right thing to be doing. [18:37:44 CEST] <durandal_1707> ubitux: it appears this one does not affect output, at least not for that sample [18:40:27 CEST] <wm4> philipl: and nvdec? [18:42:23 CEST] <philipl> I'm still looking at the code. :-) [18:42:30 CEST] <philipl> Can't argue about the lower memory footprint though. [18:42:51 CEST] <ubitux> durandal_1707: how can i reproduce the glitch? (what exact command) [18:43:58 CEST] <philipl> cuviddec only declares device_ctx support, so that's clear enough. nvdec declares both and I do see that mpv wants to use frames_ctx if it's possible. [18:45:22 CEST] <durandal_1707> ubitux: you need to compile with clang 6.0 [18:46:03 CEST] <ubitux> filter output is different between compilers? [18:46:35 CEST] <JEEB> he might be talking about the sanitizer? [18:46:55 CEST] <durandal_1707> ubitux: compile with -fsanitize=integer [18:47:01 CEST] <ubitux> i'm interested in the border glitch, not the sanitizer warning [18:47:02 CEST] <JEEB> yes, so that was it :) [18:47:42 CEST] <durandal_1707> ubitux: output appears to be same, with overflow or without [18:53:27 CEST] <philipl> wm4: OK. How does this sound for a story. [18:55:32 CEST] <philipl> mpv prefers frames_ctx, and it uses avcodec_get_hw_frames_parameters to set it up. That in turn uses the frame_params function provided by the hwaccel, which is specific to the decoder. The nvdec frame_params specify the dummy pool that BtbN added. [18:55:42 CEST] <philipl> So yes, it's using a pool, but it's using the pool that nvdec wants it to use. [18:55:49 CEST] <philipl> So you still get memory savings. [18:55:56 CEST] <durandal_1707> ubitux: are you ok with parameter that controls amount of denoising?, the 1.f weight of centered pixel [18:57:57 CEST] <ubitux> durandal_1707: yeah sure, just don't allow zero [18:58:50 CEST] <wm4> philipl: so what happens on a seek? [18:59:08 CEST] <wm4> normally the hw decoder will be recreated, but mpv makes sure it reuses the pool (in general for hwaccels) [18:59:30 CEST] <BtbN> I don't see why that wouldn't still work the exact same [19:00:06 CEST] <philipl> If you have a referenced AVFrame, it would continue to work because the AVFrame keeps the decoder alive. [19:00:17 CEST] <BtbN> that doesn't matter [19:00:31 CEST] <philipl> I didn't look in detail at seeks but I know seeks work, as I tried seeking. [19:01:55 CEST] <durandal_1707> ubitux: minimal would be 1.f [19:02:07 CEST] <ubitux> okay [19:02:20 CEST] <ubitux> is there an actual need for adjusting this? [19:07:21 CEST] <durandal_1707> for finer control, sigma is very crude currently [19:12:47 CEST] <wm4> philipl: so at some point during seek, there will be 2 decoders allocated, right [19:14:48 CEST] <philipl> That sounds likely. [19:15:14 CEST] <philipl> I can look this evening and see what the exact lifetimes are. [19:19:20 CEST] <wm4> assuming the decoders keep its internal frame pools alive that wouldn't be good [19:22:29 CEST] <philipl> wm4: presumably the frames keeping the decoder alive will be discarded soon after. even with interpolation they don't stick around that long. Or are you worried about a GPU memory allocation spike? [19:28:19 CEST] <wm4> yes, exactly [19:29:52 CEST] <philipl> I will investigate later. [19:31:00 CEST] <tmm1> JEEB: https://en.wikipedia.org/wiki/Program-specific_information documents the behavior i saw, "repeated until end of TS packet" [19:31:30 CEST] <tmm1> also says the 0xc0 table i'm seeing is a SCTE specific "Programme Information Message" [19:32:44 CEST] <JEEB> have you got a copy of the MPEG-TS spec btw? [19:32:54 CEST] <JEEB> just out of interest :) [19:33:46 CEST] <JEEB> but yes, the spec's part 2.4.4.8 shows how PMT contains arrays of things [19:34:00 CEST] <JEEB> I just never really got to trying to match that against your code because asdf other things [19:37:47 CEST] <tmm1> 2.4.4.8 only defines the structure of tid=0x2 [19:43:45 CEST] <tmm1> i'm sure it says somewhere in here that one ts packet can contain multiple tables but i'm not sure where [19:44:56 CEST] <JEEB> 2.4.4.8 clearly says that PMT can have multiple descriptors etc :) [19:45:03 CEST] <JEEB> or is it not about PMTs? [19:45:33 CEST] <JEEB> yea I think that's just a single entry with multiple PIDs linked to it [19:47:04 CEST] <tmm1> its confusing because PMT refers to the pid with the tables, and in there there's a "Program Map" table with table_id=2 [19:47:26 CEST] <tmm1> but the PMT pid can also contain other tables in the packets [20:05:13 CEST] <JEEB> tmm1: I guess it's an actual program association section? 2.4.4.3. since that defines 0x02 as program_map_section? [20:06:39 CEST] <JEEB> so it's actually a multi-part PAT [20:06:56 CEST] <JEEB> (the one that has program_map_section as 0x02 [20:11:11 CEST] <JEEB> (or they just decided to list all the alternatives for the tables under PA section) [20:12:55 CEST] <tmm1> well its not on the PAT pid [20:12:57 CEST] <tmm1> pretty confusing [20:13:33 CEST] <tmm1> 2.4.4.2 kind of alludes to it, "first section" and "at least one section" [20:14:08 CEST] <tmm1> its more clearly outlined in the dvb spec the wikipedia page links to [20:14:41 CEST] <JEEB> the sections are talking about PAT's things most likely, the 2-31 table_id assignment values table just somehow ends up being after the first table [20:15:10 CEST] <JEEB> or maybe not, I'm still trying to grasp what is a section and what is a table [20:15:13 CEST] <JEEB> (lol) [20:15:17 CEST] <tmm1> its not clear at all [20:15:23 CEST] <tmm1> they seem to use them interchangably [20:16:08 CEST] <JEEB> the only clear thing is that you're suppsoed to have a table_id (finally understood what tid was!) [20:16:22 CEST] <JEEB> and that we have various data under various table_ids [20:16:29 CEST] <JEEB> of which 0x00 is PAT [20:16:39 CEST] <JEEB> (and that's where the T in the PAT comes from I guess) [20:17:00 CEST] <JEEB> but then again, the name of the data structure is program_association_section [20:23:38 CEST] <JEEB> ok, 2.4.3.3 explains it more with the payload_unit_start_indicator thing. via context you know if a packet is going to be a PES packet or a section. and you can have multiple sections in some assembled data [20:26:16 CEST] <JEEB> and it's not surprising that the other data comes in a !PAT PID [20:26:53 CEST] <JEEB> "Only sections with this value of table_id (0x00 - PAT) are permitted within transport stream packets with PID value of 0x0000" [20:33:11 CEST] <JEEB> ok, so with non-PES PID packets you synchronize on payload_unit_start_indicator (2.4.3.2), with its value being 1 and then the pointer_field tells the offset from the start of the data in a given packet [20:36:23 CEST] <JEEB> trying to find a definite proof but as we see it's probably rather clear that if you can fit multiple sections in a single packet (or between multiple), the next one's table_id comes right after the previous ended? [20:36:48 CEST] <JEEB> and that's how non-PES PID packets work [21:10:21 CEST] <BtbN> philipl, wm4, if there wasn't a spike before, there can't be one now. [21:10:30 CEST] <BtbN> It's only allocating less memory, not more [21:14:22 CEST] <akravchenko188> jkqxz: I have sent couple of comments/questions. thanks [21:37:03 CEST] <tmm1> JEEB: yea that other doc explicitly states that [21:37:45 CEST] <tmm1> >There is never more than one pointer_field in a TS packet, as the start of any other section can be [21:37:48 CEST] <tmm1> identified by counting the length of the first and any subsequent sections, since no gaps between sections within a TS [21:38:39 CEST] <JEEB> yup [21:49:53 CEST] <philipl> BtbN: The question was how much memory is sunk into the decoder itself and the internal decoder surface pool. [21:50:06 CEST] <philipl> You'll have two of those around for a short period after a seek [21:50:10 CEST] <philipl> But I'll find out. [21:50:35 CEST] <BtbN> if you use the same hw_frames_ctx, no, you won't, ever [21:53:15 CEST] <philipl> BtbN: I mean the actual CUvideodecoder and its internal resource allocations [21:53:40 CEST] <BtbN> but those didn't change from before [21:54:11 CEST] <BtbN> or do you mean because now maybe two decoders might exist in parallel for a few frames? [21:54:40 CEST] <BtbN> that shouldn't really matter, as you'll have flushed it right before anyway [21:56:14 CEST] <philipl> I mean two might exist in parallel. [21:56:31 CEST] <philipl> If the memory overhead of that is minimal than it's not a problem, but that was what worried wm4 [22:13:34 CEST] <BtbN> well, it will be less of an overhead than the 14 extra frames before [22:13:55 CEST] <philipl> I would expect so [22:19:13 CEST] <wm4> why can't the decoder just be reused [22:20:27 CEST] <BtbN> seeking is not exactly intended by nvidia iirc [22:20:29 CEST] <philipl> It was because we couldn't find a way to actually flush it. [22:20:38 CEST] <philipl> yeah [22:20:45 CEST] <BtbN> if you flush it, it's just done for, not reuseable [22:21:43 CEST] <BtbN> how is that even done with nvdec hwaccel? [22:21:49 CEST] <BtbN> in cuvid it was an explicit implementation [22:22:30 CEST] <philipl> That's true actually. I'm not sure how it works out in nvdec :-) [22:22:55 CEST] <BtbN> actually, it's the nvidia parser that can't handle it [22:23:03 CEST] <BtbN> I don't see how the pure decoder would care [22:23:08 CEST] <philipl> ah. good point. [22:23:18 CEST] <philipl> That means we're not destroying the decoder on seek with nvdec. [22:23:26 CEST] <philipl> So there's no problem, right? [22:23:53 CEST] <BtbN> the nvdec decoder, without parser, is extremely simplistic [22:23:56 CEST] <BtbN> it consits of just 3 function calls [22:24:07 CEST] <BtbN> decode, map, unmap. If you ignore the create/destory calls [23:32:40 CEST] <durandal_1707> nobody commented on bm3d? I get noticeable better results than nlmeans [23:33:29 CEST] <JEEB> haven't needed denoising, unfortunately [23:44:07 CEST] <durandal_1707> nice thing with bm3d is that you can use other denoisers as first step instead of bm3d itself [23:54:41 CEST] <durandal_1707> JEEB: when will you switch to RustAV ? [23:57:03 CEST] <JEEB> haven't seen anything too interesting from there [00:00:00 CEST] --- Sat May 12 2018

1 0

ffmpeg.log.20180511
by burek 12 May '18

12 May '18

[00:03:34 CEST] Action: vlt wonders what phrase exactly caused JEEB to think of windows [00:04:28 CEST] <JEEB> those intel things IIRC had window on them as they were tablets [00:05:22 CEST] <vlt> JEEB: "-tune fastdecode" seems to work great so far. Without having measured yet: Does that increase the file size or affect the quality in any way? [00:05:39 CEST] <JEEB> it does disable features which lower compressibility, yes [00:05:51 CEST] <JEEB> stuff like CABAC and in-loop deblocking, if I recall correctly [00:06:31 CEST] <PureTryOut[m]> hey guys, ffmpeg segfaults for me when trying to use an file from sftp (ssh) as input. turning on verbose logging doesn't show any interesting errors or warnings... [00:06:53 CEST] <vlt> JEEB: I see, thanks. As I said before: In this situation I dont care for file size (as long as the tablet is able to read the data). [00:07:06 CEST] <vlt> (fast enough) [00:07:34 CEST] <JEEB> yea, it only starts becoming a problem when the speed of handling those bits is more than how long it would take to decompress the CABAC'd data [01:41:52 CEST] <SpeakerToMeat> Is there any way to use ff to convert a single image to a piece of video x seconds long with a fade in and fade out? [01:42:48 CEST] <JEEB> yes, but don't ask me for the filter chain [01:43:09 CEST] <SpeakerToMeat> ha filter chains are my biggest boogie man [01:46:02 CEST] <SpeakerToMeat> In IT we've had stuff like guie to regexp and gui to sql for a while, maybe I should try to do a gui to ff vf chain someday [01:51:06 CEST] <JEEB> SpeakerToMeat: I think someone tried that for the previewing. you could look at for example vapoursynth editor for an example of how such things were done for other things [01:51:18 CEST] <SpeakerToMeat> I always forget this, but what is the way to set an input image collection's native fps? seems not to be -r before .i [01:51:42 CEST] <JEEB> I think the image2 "demuxer" had its own framerate AVOption [01:51:55 CEST] <JEEB> there IIRC was a thing in ffmpeg.c that would let you list the AVOptions for a specific module [01:52:17 CEST] <SpeakerToMeat> Hmm I could swear it was a "simple" ffmpeg option [01:52:18 CEST] <c_14> ffmpeg -f image2 -framerate 1/duration -i image -vf fps=30,fade=in:d=1,fade=out:st=duration-1:d=1 [01:52:24 CEST] <c_14> something like that [01:52:45 CEST] <JEEB> framerate most definitely was an AVOption [01:52:52 CEST] <c_14> and it's `ffmpeg -h demuxer=image2' [01:52:56 CEST] <JEEB> ah, thank you [01:53:22 CEST] <JEEB> so that framerate goes before -i [01:53:26 CEST] <JEEB> as it's a demuxer option [01:53:31 CEST] <SpeakerToMeat> I could swear I didn't have to use image2 [01:53:41 CEST] <JEEB> most likely you didn't :P [01:53:48 CEST] <c_14> defaults to image2 for images, I like forcing it [01:54:06 CEST] <JEEB> I mean, I bet you could just ingest a single image and make a video filter output out of it [01:54:27 CEST] <c_14> probably [01:55:03 CEST] <SpeakerToMeat> ah iot was just -framerate I think [01:55:21 CEST] <SpeakerToMeat> hahahaha bingo [01:55:57 CEST] <SpeakerToMeat> ffmpeg -framerate 24 -i logo.tiff -t 4 -vf "fade=in:0:12,fade=out:83:12" dir/my_good_logo-%06d.dpx [01:56:03 CEST] <SpeakerToMeat> c_14: thank you [01:56:20 CEST] <JEEB> yes, framerate is an image2 AVOption [01:56:33 CEST] <JEEB> and that most likely as he said went for the image2 "meta" demuxer [01:56:39 CEST] <SpeakerToMeat> Yep [01:56:42 CEST] <SpeakerToMeat> So it's auto selected [01:56:58 CEST] <SpeakerToMeat> and its options are listed in the demuxer's help like c_14 said [01:57:15 CEST] <JEEB> but yea, what I mean is if you use any other demuxer those options will not necessarily be available [01:57:26 CEST] <JEEB> so they're not "ffmpeg.c options" or "global options" [01:57:36 CEST] <JEEB> global options are generally stuff that goes into AVCodecContext [01:57:45 CEST] <JEEB> like what -r sets, the poor bastard [01:59:02 CEST] <SpeakerToMeat> poor bastard [02:05:02 CEST] <Djfe> Hi, where should I report shareware that contains ffmpeg and mplayer without any mentioning of it? (nor license nor source code) [02:05:19 CEST] <c_14> open a ticket on trac [02:05:33 CEST] <Djfe> ok thx will do [02:09:25 CEST] <SpeakerToMeat> c_14: I've been out of the loop, is each project still fighting gpl violations, or is there a foundation doign this now? [02:09:58 CEST] <c_14> mostly project-by-project basis [02:10:08 CEST] <SpeakerToMeat> nod [02:10:18 CEST] <c_14> I think the FSF or Linux Foundation has an umbrella over a couple of projects [02:15:47 CEST] <iive> ffmpeg used to have a layer that handled most of the violations, he specialised in that. [02:15:47 CEST] <Djfe> but they can only represent the projects and not fight without their consent, right? [02:16:14 CEST] <iive> unfortunately this has halted with the fork [02:16:35 CEST] <Djfe> Done https://trac.ffmpeg.org/ticket/7197 [02:16:42 CEST] <c_14> Every person with a "reasonable" amount of code in ffmpeg is allowed to "deal with" (L)GPL violations [02:17:01 CEST] <c_14> as pertaining to the parts of code they authored [02:17:35 CEST] <iive> yes, but it also means that he represents only himself [02:17:48 CEST] <c_14> yeah [02:17:52 CEST] <iive> not the project. [02:18:35 CEST] <c_14> If you wanted to represent the project you'd probably need a vote from the active members [02:18:37 CEST] <iive> the layer had "authorization" from the most active developers for the most of the project. [02:18:53 CEST] <Djfe> good to know :) [02:19:12 CEST] <Djfe> lol https://i.imgur.com/0B3OC0C.png (I tried to attach their eula.pdf to the trac ticket) [02:21:45 CEST] <SpeakerToMeat> Post a ticket on tract about trac's captcha not working ;) [02:24:45 CEST] <Djfe> ok https://trac.ffmpeg.org/ticket/7198 [02:27:21 CEST] <SpeakerToMeat> :) [02:29:40 CEST] <klaxa> Djfe: in the User_Guide_win.pdf it at least acknowledges ffmpeg and farbice bellard :P (page 23) [02:29:58 CEST] <klaxa> is ffmpeg trademarked by him? [02:31:26 CEST] <klaxa> >FFmpeg is a trademark of Fabrice Bellard, the originator of the FFmpeg project. [02:32:15 CEST] <klaxa> but no gpl license in the pdf only their own [02:38:11 CEST] <Djfe> Can you link your pdf? [02:38:13 CEST] <Djfe> https://www.stellarinfo.com/de/installation-guide/video-repair/User_Guide_w… [02:38:30 CEST] <Djfe> this one is only 11 pages long (and in German, but at least for me that's my native language [02:38:45 CEST] <Djfe> (oh and it doesn't mention ffmpeg or mplayer at all) [02:39:18 CEST] <klaxa> https://www.stellarinfo.com/installation-guide/video-repair/User_Guide_win.… [02:40:21 CEST] <Djfe> ah I see (I only tried replacing de with en and not leaving it out) [02:40:40 CEST] <Djfe> Well they mention ffmpeg, but not mplayer and they don't mention the GPL at all. [02:40:54 CEST] <klaxa> yeah, also nothing in the EULA [02:41:12 CEST] <klaxa> at least it's concise only two pages [02:41:26 CEST] <klaxa> but it's an image in a pdf [02:41:33 CEST] <Djfe> "All rights of any kind in Stellar Phoenix Video Repair, which are not expressly granted in this license, are entirely and exclusively reserved to and by Stellar Information Technology Private Limited. You shall not rent, lease, modify, translate, reverse engineer, decompile, disassemble or create derivative works based on Stellar Phoenix Video Repair nor permit anyone else to do so." [02:41:41 CEST] <Djfe> "You shall not make access to Stellar Phoenix Video Repair available to others in connection with a service bureau, application service provider or similar business nor permit anyone else to do so." [02:42:10 CEST] <Djfe> @klaxa I know, but an image does nothing in this regard, it's clearly a violation [02:42:56 CEST] <Djfe> They aren't allowed to use ffmpeg and make money with it (unless maybe they actually send every owner of their software the source code of their software [02:43:06 CEST] <klaxa> yeah i was more complaining that you can't copy-paste from that file (without ocr) [02:43:21 CEST] <klaxa> yee pretty much [02:43:41 CEST] <klaxa> or something similar, i'm no lawyer [02:43:42 CEST] <Djfe> are you sure? I can copy text from the manual using pdf.js in FF [02:44:09 CEST] <klaxa> the manual yes, the EULA is 2 pages of images [02:50:26 CEST] <Djfe> weird, not for me (pdf.js and Adobe Reader can copy text from it just fine) [02:50:42 CEST] <Djfe> try this one: [02:50:42 CEST] <Djfe> https://drive.google.com/open?id=1A97EkHD_Z2Va20S2WFNY6tbxopTYHlrI [02:52:26 CEST] <klaxa> ah, i got EULA_eng.pdf obviously :D [02:52:35 CEST] <klaxa> https://www.stellarinfo.com/installation-uninstallation/eula_eng.pdf [02:52:38 CEST] <klaxa> looks quite different [02:52:43 CEST] <klaxa> with branding and whatnot [03:03:51 CEST] <Djfe> Anyways, taht's about it. I'm going to leave in 5mins. Bye! :) [14:48:24 CEST] <dragmore88> hi, anyone seen that -CRF Value and maxrate + vbv doesnt really uphold the limit set.. example, i set the limit to 15mbps.. i still get peaks up in 18mbps... (measuerd in bitrate viewer..) [14:52:54 CEST] <BtbN> either you use cr, or vbr/abr with vbv-maxrate [14:52:57 CEST] <BtbN> *crf [14:53:03 CEST] <BtbN> pretty sure crf will win if set [14:54:00 CEST] <BtbN> also, keep in mind that spikes up to the set bufsize can happen anytime, that's just how it works [16:01:34 CEST] <kepstin> crf in combination with vbv is supported with x264 [16:01:37 CEST] <kepstin> it should be working [16:01:54 CEST] <kepstin> you'll obviously still get peaks, depending on the bufsize you choose [16:02:16 CEST] <kepstin> (note that you are required to set bufsize, without it set, maxrate alone doesn't do anything) [16:04:16 CEST] <PureTryOut[m]> can anyone help me with my segfaulting issue? :/ [16:05:57 CEST] <Blacker47> panter [16:08:39 CEST] <PureTryOut[m]> panter? [16:13:42 CEST] <Blacker47> PureTryOut[m], was wrong window and i wonder why tab don't work. [16:15:07 CEST] <PureTryOut[m]> ah ok haha [16:15:26 CEST] <PureTryOut[m]> at least I'm glad to know my messages are arriving [16:16:18 CEST] <PureTryOut[m]> I thought they didn't, got no response at all for multiple days [16:17:41 CEST] <kepstin> PureTryOut[m]: well, there's not really anything anyone could say except maybe "that's too bad, it works for me". You might want to try getting a backtrace or trying a different ffmpeg build. [16:19:38 CEST] <kepstin> i didn't even know ffmpeg supported sftp protocol, tbh. [16:21:23 CEST] <^Neo> hello, can someone explain why there's an X in HLS after EXT-X-???? [16:21:39 CEST] <^Neo> I'm trying to translate the acronyms to generic names [16:21:54 CEST] <^Neo> EXTM3U = extended m3u playlist [16:21:59 CEST] <^Neo> EXTINF = extended information [16:22:05 CEST] <^Neo> EXT-X-??? = ???? [16:23:16 CEST] <Mavrik> extension I guess? :P [16:23:32 CEST] <kepstin> ^Neo: the X doesn't really mean anything, it's just a commonly used way of saying that something is a vendor-specific (non-standard) extension in protocol docs. [16:24:08 CEST] <kepstin> (of course, sometimes these get standardized later, including the x, so yea - it's basically meaningless) [16:25:17 CEST] <jkqxz> PureTryOut[m]: <https://trac.ffmpeg.org/ticket/6413>? [16:47:40 CEST] <dragmore88> so whats the point of "max-rate" if it will go past it all the way up to the bufsize threshold? or is it something obvious im missing? [16:47:57 CEST] <dragmore88> -crf 23 -maxrate 15M -bufsize 20M [16:48:28 CEST] <kepstin> dragmore88: maxrate tells the coded what the expected speed that the buffer will fill at is [16:48:28 CEST] <dragmore88> i see the bitrates on extreme peaks to go anywhere between 15 and 20 (just to confirm what u are saying.. [16:49:02 CEST] <kepstin> the video bitrate has nothing to do with the maxrate value [16:49:13 CEST] <dragmore88> ah [16:49:40 CEST] <kepstin> aside from that the codec might have to reduce bitrate if the buffer would underflow (because it's not refilling fast enough) [16:50:15 CEST] <dragmore88> i allways belived that Maxrate is the max threshold that x264 could let the bitrate peak to in a CRF world [16:50:34 CEST] <dragmore88> and bufsize was an absolute fixed buffer size in megabytes [16:51:48 CEST] <kepstin> you configure bufsize and maxrate to tell the codec "the player has X amount of buffer ram, and can read data off the disc or network at Y minimum speed" [16:52:10 CEST] <kepstin> and then the codec will make a video that'll stream smoothly with those parameters [16:53:08 CEST] <dragmore88> but if one set maxrate to 15mbps and the buffer to 15mbps, this is fact the upper max bitrate thresholds in practise right ? [16:53:27 CEST] <kepstin> and it will definitely make use of available buffer space to allow individual frames (esp keyframes) to peak at well over the maxrate if possible [16:54:19 CEST] <dragmore88> hmm [16:55:00 CEST] <dragmore88> i just did a test with a quite noisy prores source, 1 targe with CRF20 (free mode.. no limits) and CRF20 with maxrate = 10, bufsize = 10 [16:55:05 CEST] <kepstin> if the maxrate is 15 megabits per second and the buffer is 15 megabits, then the buffer takes 1s to refill. So the codec can take one second of video and make one frame (a keyframe) take 14mbits, and the other frames in that second (P or B frames) total 1mbit. [16:55:50 CEST] <dragmore88> the first target ended up with a 35mbps avg bitrate and the latter ended up with 9mbps, then i did a VMAF comparison with the 2 and the source.. and they were nearly identcal [16:56:03 CEST] <kepstin> so now you have to define how you measure "peak" bitrate [16:56:36 CEST] <kepstin> if you measure bitrate per-frame, then a single 14mbit frame at 30fps is 420mbit/s :/ [16:56:45 CEST] <dragmore88> heh [16:56:52 CEST] <kepstin> normally "peak" is averaged over some number of frames [16:57:09 CEST] <dragmore88> yea.. bitrate viewer uses frames, gop, enchaned gop mode etc.. [16:57:13 CEST] <kepstin> when using vbv controls, the only meaningful number to use is "the number of frames that are buffered" [16:57:31 CEST] <kepstin> so if you have 1 second of buffer, average bitrate over 1 second of frames to get the peak [16:58:13 CEST] <kepstin> and you'll find that... this ends up being basically what you set maxrate to [16:59:09 CEST] <dragmore88> agreed [17:00:23 CEST] <dragmore88> i find that CRF is quite alot better than fixed vbr on my testclips with an all over smaller byte footprint [17:00:31 CEST] <dragmore88> if one can accept the spikes [17:00:46 CEST] <dragmore88> vmaf scores confirms this [17:00:53 CEST] <kepstin> crf should be identical in overall quality to a 2-pass vbr encode with the same final bitrate. [17:00:54 CEST] <dragmore88> and my eyes ;) [17:01:10 CEST] <kepstin> (in x264, other codecs use different implementations) [17:02:06 CEST] <dragmore88> yes, but for most of us broadcasters a fixed CBR and now VBR is the old fashion way to do it.. [17:02:13 CEST] <kepstin> this is a quirk of the x264 two-pass encode implementation. it works by running an analysis pass, calculating a "constant rate factor" that's applied to the complexity of each frame, then does a second encode using that constant rate factor [17:02:21 CEST] <dragmore88> lots of wasted bits, and lost high quality areas lost.. [17:03:10 CEST] <dragmore88> does x264 use the crf values pr gop on the targed VBR? or just flat over the whole file ? [17:03:28 CEST] <kepstin> crf is constant over the whole encode in normal usage [17:03:44 CEST] <dragmore88> ok [17:04:01 CEST] <kepstin> (you can actually change it in the middle of an encode using the x264 api, but i dunno if ffmpeg's wrapper lets you do that) [17:04:25 CEST] <dragmore88> isnt this what netflix is doing on scene based encoding? [17:04:47 CEST] <dragmore88> chopping up the scenes, CRF first pass, lock it down with VBR for that scene [17:05:01 CEST] <dragmore88> or i might be wrong [17:05:09 CEST] <kepstin> netflix appears to be doing bitrate based encodes at a bunch of bitrates, then picking one that meets their quality level [17:05:22 CEST] <kepstin> crf is setting a quality level, and then getting whatever bitrate the encoder decides is good [17:05:41 CEST] <dragmore88> like VMAF sub 90 -> /DEV/NULL [17:05:44 CEST] <dragmore88> keep the one over [17:07:27 CEST] <kepstin> the point of crf is that it lets the encoder automaticall raise and lower the bitrate per scene based on complexity to maintain constant visual quality (according to the encoder's builtin psy metrics) [17:08:18 CEST] <dragmore88> japp [17:08:25 CEST] <kepstin> said builtin metrics are obviously less complex than vmaf, for speed reasons, but for most uses they're good enough [17:08:37 CEST] <dragmore88> i just want to limit it a bit on the top so it doesnt go totally haywire [17:09:02 CEST] <kepstin> yep, makes sense. That's actually what google does with their vp9 encoding for youtube [17:09:18 CEST] <dragmore88> i just 25 tests encodes on CRF20 and they averaged out on 4,4mbps and avg peak on 9mbps [17:09:35 CEST] <dragmore88> our formar static CBR level was 6,5mbps [17:09:37 CEST] <dragmore88> former* [17:09:59 CEST] <dragmore88> so we gain alot on quality and reduce the bitrate by like 40% [17:10:03 CEST] <dragmore88> on average [17:10:13 CEST] <kepstin> vp9 doesn't have something exactly like crf mode, but it does have a quality limit mode that lets you say "don't bother spending extra bits if the quality is at least X good", which can be used either standalone or in combination with bitrate controls [17:10:17 CEST] <dragmore88> just switching from a CBR to VBR world [17:12:09 CEST] <dragmore88> thx for the informative discussion kepstin ;) [17:18:23 CEST] <kepstin> probably the biggest thing about vod streaming that affects bitrate is what you set your gop size to [17:18:59 CEST] <kepstin> if you're using crf mode, increasing the gop size means it'll use a lot more, smaller, predicted frames and lower your average bitrate a lot [17:20:33 CEST] <kepstin> so e.g. going with 10s segments in your hls rather than 5s or something like that can be a big win. [17:21:49 CEST] <kepstin> (if you're doing segmented video, you might want to set the vbv bufsize to match the segment length, since you'd normally be expecting players to buffer ~1 segment ahead) [17:23:01 CEST] <BtbN> 3 segments actually [17:28:17 CEST] <dragmore88> we are using 2 sec GOP size today (dash) [17:28:28 CEST] <dragmore88> and im hardlocking IDR frames pr 2 sec [17:28:53 CEST] <dragmore88> but enabeling scenecut detection within the gop (iframe) [17:30:01 CEST] <kepstin> yeah, with that short of a gop, scene cut detection might not do much useful, since putting two i frames in the gop would probably hit the vbv limits, meaning one or both get reduced quality. [17:30:05 CEST] <dragmore88> how can one set the VBV bufsize to match the segment length? mb vs. seconds ;) [17:30:19 CEST] <kepstin> dragmore88: bitrate is in bits per second [17:30:27 CEST] <kepstin> therefore if you know seconds, you can calculate bits [17:30:39 CEST] <kepstin> (use the maxrate) [17:30:39 CEST] <dragmore88> in a crf world, i would know the bitrate [17:30:43 CEST] <dragmore88> k [17:30:59 CEST] <dragmore88> so 10mbps maxrate x 2 sec = 20mbps [17:31:11 CEST] <dragmore88> is the bufsize set in mbits or mbytes? [17:31:23 CEST] <dragmore88> 20mbit i meant [17:35:12 CEST] <kepstin> dragmore88: the suffixes 'M', 'K' in ffmpeg are in bits [17:35:50 CEST] <kepstin> the bufsize parameter takes a value in bits [20:21:32 CEST] <Cracki> silly question: does ffmpeg have a scene change detection such that it can poke a dumb, but p-frame-capable, codec to make an intra frame? [20:22:24 CEST] <Cracki> (i have qtrle, which is qt animation, which can do "p-frames", and I can use -g, but I'd rather it make intra frames only when needed) [20:27:04 CEST] <Cracki> (footage is screen capture of someone's static slides presentation, so no change mostly, and when change, it should be intra-coded) [20:28:53 CEST] <kepstin> nothing built-in, it would require code changes. [20:29:13 CEST] <Cracki> ic [20:29:17 CEST] <Cracki> thx [20:30:11 CEST] <kepstin> (the proper fix would probably be adding scene change detection to the codec itself) [20:31:02 CEST] <kepstin> if you were writing an application using ffmpeg libraries, you could do something like use a filter to detect scene changes (iirc there's one that sets frame metadata) and use that info to set the frame type when encoding. [20:32:24 CEST] <Cracki> don't even need a filter, I know exactly which frame needs intra, and all the rest are nulls [20:32:42 CEST] <Cracki> just never had the need to deal with ffmpeg api directly [20:33:21 CEST] <Cracki> say, using the API, I would be able to send null frames, eh? [20:33:26 CEST] <Cracki> (to the codec) [20:34:02 CEST] <Cracki> I think it's possible because cli ffmpeg transcode from one lossless p-capable codec (lagarith) to qtrle is really fast [20:55:16 CEST] <kepstin> Cracki: note that with the ffmpeg api, passing a NULL AVFrame is the indication that you've hit end of stream and want to start flushing encoder buffers. [20:55:34 CEST] <Cracki> ic. how to indicate a repeated frame? [20:56:02 CEST] <JEEB> pass the same frame again? [20:56:09 CEST] <kepstin> send another frame that references the same data [20:56:17 CEST] <Cracki> ah, references the same data [20:56:37 CEST] <kepstin> although I suspect few encoders bother optimizing by checking if the data pointers are the same [20:56:47 CEST] <JEEB> yes, they generally check the content [20:57:06 CEST] <Cracki> how do encoders typically handle that? can they detect that I sent the same frame twice, or would they have to figure out that there are no differences in the data on their own? [20:57:06 CEST] <JEEB> or... you do VFR [20:57:41 CEST] <Cracki> my output should be fixed frame rate... I can of course generate frames and PTSes [20:58:03 CEST] <JEEB> no, I mean if you want to make sure that no extraneous pictures get encoded, you do Variable Frame Rate [20:58:07 CEST] <kepstin> yeah, some people get this "null" frame idea because avi doesn't support vfr, but does let you pack null frames for skipped frames [20:58:22 CEST] <Cracki> ic [20:58:22 CEST] <JEEB> if you need to have a constant frame rate then you just feed frames over [20:58:37 CEST] <JEEB> modern encoders will figure out the content is the same if you're not set to all-intra [20:58:46 CEST] <JEEB> and yes, the AVI thing is actually VFR in a CFR container [20:58:57 CEST] <Cracki> qtrle would encode that as a frame that immediately ends, meaning use all the data from the previous frame (and nothing updated) [20:59:27 CEST] <JEEB> well yea, that depends on the encoder [20:59:43 CEST] <Cracki> I'd like to give the codec as much hinting as possible so it doesn't _have to_ touch the frame contents [20:59:43 CEST] <JEEB> any modern encoder worth its salt will attempt to figure out identical input [21:00:06 CEST] <Cracki> do avframes have "identity"? [21:00:09 CEST] <JEEB> Cracki: there's only two alternatives, you skip a timestamp and do VFR, or you just encode [21:00:14 CEST] <Cracki> hm [21:00:19 CEST] <JEEB> there's no flag for "this is a duplicate picture" [21:03:24 CEST] <Cracki> hmmm the "fast" transcode only happens from lagarith inside avi to qtrle inside whatever [21:03:52 CEST] <Cracki> and throws bunches of notices about repeated frames or somesuch. I guess ffmpeg does something smart in that case [21:03:56 CEST] <kepstin> it's possible the lagarith inside avi is actually pseudo-vfr and has null frames [21:04:07 CEST] <Cracki> it surely has null frames [21:04:28 CEST] <kepstin> which means that as long as you're passing it through as vfr inside ffmpeg, it should stay that way [21:04:31 CEST] <kepstin> i think [21:04:36 CEST] <Cracki> hmmm [21:04:42 CEST] <JEEB> yea, then it's VFR and for the mov muxer for some reason the default is CFR mode [21:04:50 CEST] <JEEB> the ffmpeg.c vsync mode that is [21:04:54 CEST] <JEEB> which is telling you it's duplicating things [21:05:00 CEST] <kepstin> obviously if you use -r output option or something to set cfr, it'll duplicate the frames [21:05:02 CEST] <JEEB> -vsync vfr or -vsync passthrough [21:05:14 CEST] <JEEB> kepstin: you don't even need to set -r or anything [21:05:20 CEST] <JEEB> just try doing VFR to movenc [21:05:23 CEST] <Cracki> I guess the transcode from (constant frame rate) qtrle to qtrle is slow because ffmpeg has to decode all frames and pass them over, because the "null" is on the bitstream level, not the container level [21:05:41 CEST] <JEEB> because movenc IIRC is for some reason marked as CFR container [21:05:45 CEST] <JEEB> uhh, muxer [21:06:23 CEST] <Cracki> I'd expect mp4 to be so restrictive. I can't even put qtrle into mp4, but mov... [21:06:30 CEST] <Cracki> (I know they share history) [21:06:36 CEST] <JEEB> no, it doesn't make sense for any of them to be honest [21:06:51 CEST] <JEEB> you can set a wild time base for each, and I think mov actually is even more restricted than mp4? [21:07:03 CEST] <Cracki> what makes sense, and what a standards body would think makes sense, are usually not the same [21:07:24 CEST] <JEEB> no, I'm telling you - there's zarro issues with VFR in ISOBMFF as long as you pick your time base right [21:07:38 CEST] <JEEB> I'll check where that CFR muxer flag comes from... [21:07:41 CEST] <JEEB> time for archeology [21:07:56 CEST] <JEEB> but you can override ffmpeg.c's behavior with -vsync vfr or -vsync passthrough [21:08:09 CEST] <Cracki> no no, I'm absolutely ok with cfr. the target application is adobe premiere and the version I'm on has shit to NO support for vfr [21:09:25 CEST] <JEEB> yeah, I was mostly commenting about the idea that the CFR limitation made any sense (there is no actual limitation in the muxer itself, if you set your time base you're rolling fine) [21:09:32 CEST] <Cracki> ic [21:09:38 CEST] <JEEB> and actually for video movenc.c generally just sets a >10k time base for you by default [21:09:47 CEST] <Cracki> yes, everything's got a PTS and DTS these days, eh [21:09:48 CEST] <JEEB> because back in ye olden days it didn't support edit lists [21:10:05 CEST] <JEEB> or some archeological findings like that [21:10:48 CEST] <Cracki> edit lists... I know they're part of mov/mp4 and some other formats but I have never seen a compelling purpose for them and I would strangle the ones who gave these formats the capability [21:11:26 CEST] <JEEB> edit lists are by default utilized for stuff like audio encoder delay and b-frame delay signaling [21:11:37 CEST] <Cracki> o.o [21:11:52 CEST] <JEEB> so you can say that "yes, there's some audio data in the beginning that you don't want to output" [21:12:04 CEST] <JEEB> because the encoder makes that, and the size depends on encoder mode etc [21:12:09 CEST] <JEEB> usually a single audio frame, I think? [21:12:12 CEST] <Cracki> or you can if you're so inclined, but there's no picture yet? [21:12:23 CEST] <JEEB> yes [21:12:32 CEST] <JEEB> although generally you don't want to decode encoder delay... [21:12:36 CEST] <JEEB> or well, you want to decode it [21:12:38 CEST] <JEEB> but not pass it on [21:12:42 CEST] <Cracki> aye [21:13:00 CEST] <JEEB> and I guess I should call it encoder initialization padding or something [21:13:06 CEST] <JEEB> it ends up being the encoder delay, yes [21:13:35 CEST] <JEEB> ah yes [21:13:38 CEST] <JEEB> the classic ffmpeg.c line [21:13:39 CEST] <JEEB> format_video_sync = (of->ctx->oformat->flags & AVFMT_VARIABLE_FPS) ? ((of->ctx->oformat->flags & AVFMT_NOTIMESTAMPS) ? VSYNC_PASSTHROUGH : VSYNC_VFR) : VSYNC_CFR; [21:14:03 CEST] <JEEB> so, AVFMT_VARIABLE_FPS is not set for movencäs muxers [21:14:03 CEST] <Cracki> why do you have no rule against masturbatory use of ternary operators? [21:14:05 CEST] <Tonnes> hi, can I post a possible issue? (or wait a bit) [21:14:29 CEST] <JEEB> Tonnes: just note it and also if you care you can post it on trac.ffmpeg.org [21:14:42 CEST] <Cracki> go ahead, I'm just chatting idly [21:15:29 CEST] <JEEB> but yea, that's why for any movenc.c muxer ffmpeg.c starts duplicating/dropping frames by itself by default [21:15:41 CEST] <Cracki> moven cäs, sounds like an offshoot of mövenpick [21:15:44 CEST] <JEEB> (it doesn't use the fps video filter, funny enough) [21:15:48 CEST] <JEEB> lol [21:15:57 CEST] <JEEB> that's what I get for missing a key location on a keyboard layout [21:16:01 CEST] <JEEB> ä is next to ' [21:16:08 CEST] <Cracki> and less than next to . [21:16:27 CEST] <Tonnes> i just stumbled on what may be a regression. when trying to fix a file as reported in mozilla's bug 1448762 using 2 builds from https://ffmpeg.zeranoe.com/builds/win32/shared/ I found that ffmpeg-20180102-41e51fb-win32-shared.zip worked, but ffmpeg-latest-win32-shared.zip did not, as the latter prevents is by the corrupt header [21:16:29 CEST] <Cracki> oh right that wasn't movenc.c [21:16:47 CEST] <Tonnes> s/prevents it [21:17:05 CEST] <Cracki> Tonnes, so your problem is some of zeranoe's zips are malformed? [21:17:15 CEST] <Cracki> or is that about the binaries inside? [21:17:30 CEST] <JEEB> this is a broken ISOBMFF file [21:17:33 CEST] <JEEB> https://bugzilla.mozilla.org/show_bug.cgi?id=1448762 [21:17:46 CEST] <Cracki> ah [21:17:56 CEST] <JEEB> " the sample table of this file is invalid. In particular the Sample To Chunk Box (ISO/IEC 14496-12:2015 8.7.4) contains rubbish data with the value of first_chunk always set to 1 for all samples." [21:18:19 CEST] <Tonnes> no, I think ffmpeg may work as it should (well, I never used it before today), it's just that "ffmpeg -i file.mp4 -codec copy file_fixed.mp4" halts because of the malformed header in the corrupt video [21:18:38 CEST] <Cracki> halt as in crash, or stops gracefully? [21:18:58 CEST] <Tonnes> will retry and post the error message if you want me to [21:19:31 CEST] <JEEB> and is this a change in behavior? although to be honest, if we have actually managed to properly derp at broken files this is *so* good [21:19:50 CEST] <JEEB> because usually FFmpeg is going the road to hell where we have more features to support broken files than valid ones [21:20:05 CEST] <Cracki> the last post on the bug says remuxing (-c copy) should work without problems and actually fix the problem, not crash or halt or anything [21:20:25 CEST] <JEEB> yes, but that could have been an old version [21:20:39 CEST] <JEEB> there's been some changes recently to the "mov" demuxer from both google and elsewhere [21:20:46 CEST] <Cracki> ic [21:21:33 CEST] <JEEB> I would probably write a box editor for mp4 to fix these sorts of things [21:22:44 CEST] <JEEB> and if you want, you can look into the byte offsets with L-SMASH's boxdumper or atomicparsley [21:22:46 CEST] <Tonnes> https://imgur.com/a/v2TkP7M [21:22:50 CEST] <JEEB> and use a hex editor [21:22:56 CEST] <Tonnes> I figured it could be intended behavior though [21:23:05 CEST] <Cracki> looks graceful enough [21:23:29 CEST] <JEEB> nice, it even tells you where things start to fall apart [21:23:45 CEST] <Tonnes> tried to help ouot som eforum user with broken videos in FF 59 and 60 so pointed to ffmpeg, then found this "issue" :) [21:24:19 CEST] <JEEB> let's see who you can "blame" for this improvement [21:25:02 CEST] <JEEB> ok, so it was asserting before [21:25:07 CEST] <JEEB> and the chromium people didn't like that [21:25:34 CEST] <JEEB> so now there's a commit that says "commit 9e67447a4ffacf28af8bace33faf3ea432ddc43e" [21:25:37 CEST] <JEEB> Author: Michael Niedermayer <michael(a)niedermayer.cc> Fri Mar 16 20:53:36 2018 [21:25:40 CEST] <JEEB> Committer: Michael Niedermayer <michael(a)niedermayer.cc> Tue Mar 20 23:59:40 2018 [21:25:43 CEST] <JEEB> avformat/mov: Check STSC and remove invalid entries [21:25:45 CEST] <JEEB> also I selected way more than I wanted [21:26:02 CEST] <JEEB> Fixes: crbug 822547, crbug 822666 and crbug 823009 [21:26:09 CEST] <JEEB> for references to chromium (?) bugs on this [21:26:19 CEST] <JEEB> it's their fuzzing infra [21:26:52 CEST] <Cracki> so he turned assertions into proper errors? sounds like a good thing [21:27:02 CEST] <JEEB> yes [21:27:10 CEST] <JEEB> those sanity checks aren't always the best, though :P [21:27:15 CEST] <JEEB> since they're not always clear cut [21:27:22 CEST] <JEEB> esp. the stuff like timestamp checks in movenc.c [21:28:10 CEST] <JEEB> Tonnes: if that file didn't assert before then it would have worked (maybe?) [21:29:17 CEST] <Tonnes> ? [21:29:49 CEST] <JEEB> as in, if you check out a version from before that hash, if it doesn't assert you might get something out of it [21:30:05 CEST] <Cracki> meaning: that change only made breakage obvious, it make it more strict [21:30:14 CEST] <Cracki> *didn't [21:30:42 CEST] <JEEB> oh it did add the sanity checks. and it doesn't exactly say which cases led to the asserts [21:30:46 CEST] <Tonnes> well, the same happens in fmpeg-4.0-win32-shared.zip [21:30:47 CEST] <Cracki> ic [21:30:55 CEST] <Cracki> 4.0 sounds fresh [21:30:57 CEST] <JEEB> ffmpeg-4.0 is from after that March commit [21:31:05 CEST] <JEEB> it was just branched a few weeks ago [21:31:06 CEST] <Tonnes> s/ when using [21:32:55 CEST] <Tonnes> ffmpeg-3.4.2-win32-shared.zip : no issue [21:33:11 CEST] <JEEB> yea then that breakage wasn't hitting the assert [21:34:11 CEST] <Tonnes> tbh I'd just be interested in whether or not this is expected behavior and moreover, if that's true, if there is an additional command line option to specify that would still enable FFmpeg to fix such a vid [21:34:52 CEST] <Tonnes> all in favaor of users and website ownere that may want to use ffmpeg in order to fix some vids rather than waiting for FF 61 [21:35:26 CEST] <JEEB> no option for that sanity check [21:35:35 CEST] <Tonnes> ..and grab the latest version automatically ;) [21:36:22 CEST] <Cracki> keep versions of everything [21:36:23 CEST] <BtbN> If ffmpeg can read that file and product proper audio and video from it, it shouldn't just fail imo [21:36:39 CEST] <Cracki> I love zeranoe for keeping tons of builds around. sigrok could learn from that :> [21:37:58 CEST] <JEEB> BtbN: as long as it doesn't insanely complicate things or enable completely invalid stuff to happen [21:38:20 CEST] <JEEB> Tonnes: if you want you can create a ticket on trac.ffmpeg.org to explain the issue and link the bugzilla issue etc [21:42:53 CEST] <Tonnes> only if you insist, otherwise I'd appreciate if you could do it for me (I'm a bit overloaded with other duties and it would require me to register somewhere) [21:43:12 CEST] <JEEB> oh you don't say I don't have too many hot things on the iron :P [21:43:33 CEST] <JEEB> I've got HDR output support in one player, multiple things Iwant to implement in FFmpeg's MPEG-TS demuxer [21:43:43 CEST] <JEEB> reviewing at least one dashenc.c patch set [21:43:50 CEST] <JEEB> reviewing some MPEG-TS demuxer patches [21:43:57 CEST] <Tonnes> :) [21:44:08 CEST] <JEEB> and now you know why the fuck I haven't watched series for seven fucking weeks [21:44:32 CEST] <JEEB> instead feeling sad and procrastinating on youtube bullshit if I'm too tired for open source on an evening [22:01:35 CEST] <Etrigan63> Hello. [22:02:36 CEST] <Etrigan63> Can anyone recommend a GUI front-end for ffmpeg on Linux? I am looking to take advantage of GPU acceleration that is not offered by Handbrake. [22:02:53 CEST] <BtbN> I can recommend not using one, ever [22:03:08 CEST] <BtbN> So far all of them I have seen were bad. Handbrake is the only somewhat decent one [22:03:17 CEST] <JEEB> and Handbrake is after all, an API client [22:03:44 CEST] <Etrigan63> So how can I enable GPU acceleration in Handbrake? [22:04:29 CEST] <kerio> i can recommend not using GPU acceleration for h264 :^) [22:05:00 CEST] <Etrigan63> Why not? [22:06:10 CEST] <durandal_1707> use vidcoder [22:06:53 CEST] <JEEB> handbrake IIRC had support for hwaccel, look into their documentation on how to use it [22:07:00 CEST] <JEEB> we do not make handbrake, handbrake just uses FFmpeg [22:07:03 CEST] <JEEB> (the libraries) [22:07:40 CEST] <BtbN> handbrake doesn't even use ffmpeg [22:07:57 CEST] <BtbN> it's libav-only from the looks of it, they are only, very slowly, thinking about switching to ffmpeg [22:08:00 CEST] <JEEB> yea I heard they were going to with the latest release? [22:08:01 CEST] <kerio> Etrigan63: libx264 is very very very good [22:08:12 CEST] <BtbN> the bug about it is open for 2 years now [22:12:05 CEST] <JEEB> oh well [22:12:59 CEST] <furq> Etrigan63: if you mean nvenc/quicksync then those are really only suitable for realtime [22:13:09 CEST] <furq> and handbrake implies this is for archival [22:13:34 CEST] <furq> if you just mean opencl in x264 then that's not really worth using, it hardly gives any speedup and it has a minor impact on quality [23:29:46 CEST] <zevarito> I am outputing m3u8 and looking for a way to introduce custom tags in the playlist, there is a way to do this inside the library? [23:30:36 CEST] <zevarito> Also I am having hard time to identify how to create the liveplaylist or a VOD programatically [00:00:00 CEST] --- Sat May 12 2018

1 0