Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

January 2016

1 participants
62 discussions

ffmpeg-devel.log.20160125
by burek 26 Jan '16

26 Jan '16

[00:01:41 CET] <Cornelius^> hi guys, whats the story on vp9 hardware accellerated encoding? [00:02:03 CET] <nevcairiel> there is no story [00:09:39 CET] <atomnuker> speed of our native flac encoder + multi dimensional quantization - 0.000283x [00:09:56 CET] <atomnuker> it would take longer than a year to encode 5 minutes according to my math [00:10:05 CET] <atomnuker> actually 2 years [00:10:18 CET] <nevcairiel> why does this mode even exist :D [00:10:57 CET] <nevcairiel> our PCs are not ready for alien technology yet [00:11:20 CET] <wm4> some sort of audiophile mode [00:20:11 CET] <cone-336> ffmpeg 03Michael Niedermayer 07master:cde57eee98d2: avformat/hls: Check that filename is not "" in probe before checking its extension [00:29:41 CET] <JEEB> lol [00:31:22 CET] <cone-336> ffmpeg 03James Almer 07master:1d8f9b7d1ad2: avcodec/webp: fix decoder dependencies [00:43:51 CET] <atomnuker> speed=6.53e-05x [00:44:13 CET] <atomnuker> I didn't even know it was possible to have the speedometer output this format [00:44:22 CET] <nevcairiel> haha [00:47:12 CET] <J_Darnley> durandal_170, atomnuker: I need to get my 32-bit flac lpc assembly committed. That will help (somewhat) after a fairly recent bugfix. [00:49:10 CET] <atomnuker> yeah, that would allow for more LPC passes [00:49:32 CET] <atomnuker> but not under x86_64, right? [00:49:38 CET] <durandal_170> I need to figure frame encoder for audio [00:50:16 CET] <durandal_170> Multithreaded* [00:50:17 CET] <J_Darnley> No I mean for 32 bit coeffs not arch [00:50:48 CET] <J_Darnley> A 32*32=64 bit multiply then [02:42:02 CET] <BBB> nevcairiel: what a silly question [02:42:36 CET] <BBB> nevcairiel: try vpxenc passes=2 best cpu-used=0 4kinputvideo.y4m codec=vp9 -o output.webm [02:42:49 CET] <BBB> nevcairiel: why does that mode exist? nobody knows [02:43:13 CET] <Timothy_Gu> that's video. there's an excuse to be slow [02:43:18 CET] <BBB> x265 isnt any better with preset=veryslow [02:43:39 CET] <BBB> with x265, preset=veryslow passes=2, I believe pass 1 and pass2 are equally slow [03:00:12 CET] Action: jamrial wants the new dca decoder committed already [03:00:22 CET] <jamrial> i already wrote some easy simd for it :p [03:00:52 CET] <jamrial> pity as is it broke decoding of that one file michaelni pointed out [07:30:18 CET] <ac_slater> with a libavcodec encoder, what's the significance of AVCodec.pix_fmts? Does some auto conversion happen? [08:00:06 CET] <ac_slater> I see this when I attempt to put rawvideo yuyv422 into my encoder [08:00:09 CET] <ac_slater> [auto-inserted scaler 0 @ 0x15ee6d0] w:640 h:480 fmt:yuyv422 sar:0/1 -> w:640 h:480 fmt:yuv420p sar:0/1 flags:0x4 [08:01:02 CET] <ac_slater> the result mostly green (always), which tells makes me thing a conversion didn't happen [08:01:04 CET] <ac_slater> clues? [08:12:18 CET] <ac_slater> which tells me a conversion didn't happen* [10:32:35 CET] <Warblefly_> Gentlemen, thank you for fixing "master:cde57eee98d2: avformat/hls: Check that filename is not "" in probe before checking its extension" -- just about to test [11:12:26 CET] <cone-569> ffmpeg 03Mats Peterson 07master:fe7639b1c8be: avcodec/rawdec: initialize palette for mono [11:12:26 CET] <cone-569> ffmpeg 03Mats Peterson 07master:82325dbec144: lavc/rawdec: Use 16-byte line alignment for 1, 2, 4 and 8 bpp [11:12:26 CET] <cone-569> ffmpeg 03Michael Niedermayer 07master:46f67f4a34ca: avcodec/rawdec: Check height and packet size [13:52:40 CET] <durandal_1707> michaelni: I added audio support to frame_thread_encoder, but somehow other threading code from decoder kicks in and segv [14:49:08 CET] <durandal_1707> michaelni: ping [14:52:30 CET] <atomnuker> so supposing I have a decoder which needs to output an interlaced picture (so I have 2 frames coming in but a single frame coming out) [14:52:45 CET] <Daemon404> atomnuker, youre screwed [14:52:53 CET] <Daemon404> i already tried that for libx265 support [14:53:00 CET] <Daemon404> (hevc interlaced is 2 output packets) [14:53:16 CET] <wm4> wait, 2 packets in, 1 frame out should be fine [14:53:19 CET] <wm4> since this is decoding [14:53:36 CET] <atomnuker> can't I somehow save the contents of an AVFrame and continue with it? [14:53:36 CET] <Daemon404> oh i misread [14:53:49 CET] <Daemon404> atomnuker, in the private context [14:54:04 CET] <Daemon404> unless you mean entirely copyless [14:54:13 CET] <atomnuker> do I need to just save the pointer or use some copy function? [14:54:42 CET] <Daemon404> im nto sure of the rules for the buffer returned from get buffer [14:54:44 CET] <wm4> make a ref [14:54:47 CET] <wm4> with av_frame_ref [14:54:57 CET] <atomnuker> would be nice if I could just continue with the same AVFrame I've saved and just signal that that AVFrame is the one I want to output [14:55:16 CET] <Daemon404> i think wm4 is right here [14:56:59 CET] <atomnuker> so for the first field I set an AVFrame in my context as a ref [14:57:15 CET] <atomnuker> but what do I do for the second field? [14:57:39 CET] <atomnuker> copy whatever I need from my ref to the new AVFrame? [14:57:49 CET] <Daemon404> dont request a new buffer at all [14:57:57 CET] <Daemon404> i assume [14:58:01 CET] <Daemon404> and return the other [14:58:08 CET] <Daemon404> and properly unref? [14:58:11 CET] <Daemon404> (im noty 100% myself) [14:58:15 CET] <wm4> I guess you could also somehow decode into the same AVFrame by playing with the strides? [14:58:23 CET] <wm4> dunno [14:59:34 CET] <Daemon404> what stops you from decoding into the same avframe? [15:00:28 CET] <atomnuker> nothing except I don't know how to output the avframe I have instead of the one I get in the second field [15:00:48 CET] <Daemon404> there's a function to use the same buffer i think [15:00:57 CET] <Daemon404> elenril would know best [15:08:05 CET] <durandal_1707> michaelni: and indeed encode context is same as decoder one [15:18:59 CET] <michaelni> durandal_1707, encoder and decoder should have seperate contexts [15:19:31 CET] <michaelni> but maybe i misunderstand [15:20:36 CET] <nevcairiel> atomnuker: you can just do what you propose, just decode into one avframe and when its done output it [15:20:54 CET] <durandal_1707> michaelni: clearly, they are shared, I printed pointers [15:21:26 CET] <michaelni> atomnuker, yes, as nevcairiel says, first field in, no output, 2nd field in output a frame [15:22:14 CET] <atomnuker> okay, but I still have to move the stuff from my ref/buffer to the new frame [15:22:21 CET] <atomnuker> though the overhead would be minimal probably [15:22:24 CET] <michaelni> durandal_1707, a AVCodecContext is either a encoder or a decoder not both [15:22:37 CET] <nevcairiel> atomnuker: its just copying a pointer around, many decoders do that [15:22:50 CET] <nevcairiel> its not like you are copying the frame contents [15:23:41 CET] <atomnuker> so first field, put stuff in the avframe, make a ref at the end, *got_frame = 0 [15:23:58 CET] <atomnuker> and the second field I just call av_frame_move_ref() to move the stuff to the new avframe [15:24:01 CET] <nevcairiel> create your own avframe to put stuff into, dont put it into the one you get [15:24:15 CET] <nevcairiel> only on the second field move_ref your internal avframe over the one decode() is called with [15:25:22 CET] <Daemon404> sounds right [15:26:33 CET] <durandal_1707> michaelni: try patch I just posted [15:54:11 CET] <durandal_1707> michaelni: also frame mt encoder seems to be called for encoders that do not have cap flag [15:56:19 CET] <Daemon404> i think it may be done for intra-only codecs automatically? [15:56:22 CET] <Daemon404> (maybe) [15:57:18 CET] <michaelni> IIRC, yes [16:06:12 CET] <wm4> BtbN: I'm fighting with vdpau preemption again... god I hope libav wins this API war [16:09:11 CET] <nevcairiel> you mean libva? [16:09:25 CET] <nevcairiel> this preemption business sounds like a badly thought out design [16:10:02 CET] <wm4> err, yes, libva [16:10:05 CET] <wm4> (interesting typo) [16:10:19 CET] <wm4> well it seems to be modeled after D3D preemption [16:10:19 CET] <BtbN> you mean handling of the display device getting taken away at runtime? [16:10:22 CET] <wm4> aka "lost devices" [16:10:26 CET] <wm4> yes [16:10:39 CET] <BtbN> How does libva handle that? [16:10:44 CET] <wm4> and the new vdpau hwaccel API is also being a fucking pain in the ass about this [16:10:48 CET] <nevcairiel> interestingly i never had to deal with that from a decoder side, since the video renderers all take care of that [16:10:52 CET] <wm4> BtbN: it simply doesn't have the concept [16:10:59 CET] <BtbN> So it would just explode? [16:11:09 CET] <wm4> I don't know? [16:11:17 CET] <wm4> does vaapi decoding explode if you change VTs? [16:11:20 CET] <wm4> because vdpau does [16:11:24 CET] <BtbN> Never tried that [16:11:45 CET] <BtbN> But as the libva intel driver communicated directly with the in-kernel drm driver, I wouldn't think so. [16:12:02 CET] <BtbN> If nvidia were to implement a VAAPI driver, things might be different [16:13:44 CET] <jkqxz> Yeah, libva doesn't really care about the display at all. It runs fine headless, connecting to the DRM device directly. [16:14:16 CET] <wm4> well vdpau doesn't handle display in my case either [16:14:26 CET] <nevcairiel> easy enough for intel to get away with, they dont have th chance of multiple gpus being available in their igpu setups =p [16:14:31 CET] <BtbN> Doesn't VDPAU require an active X display? [16:14:33 CET] <jkqxz> (This is helpful when you are trying to develop things and get random GPU hangs because the driver sucks.) [16:14:54 CET] <wm4> BtbN: yes [16:15:02 CET] <BtbN> You can easily kill the CPU entirely when doing stuff with VAAPI [16:15:14 CET] <BtbN> Forcing you to remove power from the device for a while for it to recover [16:15:25 CET] <nevcairiel> that bad huh [16:15:41 CET] <BtbN> Happend a few times while implementing the HEVC stuff [16:16:04 CET] <BtbN> Wrong parameters? The CPU is out of this for today. [16:16:05 CET] <jkqxz> I've never had it go that far. I had to use a headless machine because it messed with X, but it did always recover. [16:16:46 CET] <nevcairiel> intels windows drivers also like to crash on such things, but in that case usually only the application, not at kernel level, or even hardware =p [16:17:06 CET] <jkqxz> That was all HEVC too (encode). H.264 seemed much more solid, but then it is significantly older. [16:17:52 CET] <BtbN> encoding with libva is ridiculously convoluted. [16:18:14 CET] <BtbN> It just feels like the developers were trying to do the least possible amount of work. [16:18:49 CET] <BtbN> We need all those bitstream parameters passed via some structs? Ok, fine, let's not use them to generate the NAL bitstream and instead require the api user to generate it! [16:20:20 CET] <fritsch> lol sounds like vaapi [16:20:25 CET] <fritsch> ah it's about vaapi [16:20:37 CET] <jkqxz> How could we generate that ourselves? The user might want to use one of the other parameters which we randomly missed out of the structs! [16:21:03 CET] <BtbN> They could still offer to pass the NAL the same way one has to do right now. [16:21:16 CET] <BtbN> But instead of erroring out, generate it internaly if it's not given... [16:34:51 CET] <durandal_1707> michaelni: it is evil, anyway have you tried patch? [16:41:09 CET] <kierank> BBB: is there a way of getting gcc to treat the variable as a constant? [16:41:23 CET] <kierank> will it work with const int and a hardcoded branch in the wrapper? [16:41:46 CET] <BBB> a hardcoded branch works [16:42:01 CET] <BBB> if (var == 10) { clip(10); } else clip(12); [16:42:01 CET] <BBB> or so [16:42:16 CET] <BBB> if thats not easily possible, dont use clip_uint8p2 [16:42:22 CET] <BBB> its only speed advantage is on arm anyway [16:42:28 CET] <BBB> because you can hardcode the exponent [16:42:32 CET] <BBB> without it needing a reg [16:42:33 CET] <kierank> I want to keep the wrappers in place [16:42:35 CET] <kierank> and avoid macros [16:42:47 CET] <BBB> do whatever you think is best [16:44:23 CET] <ubitux> kierank: i'm explaining this in the post of sent you already [16:44:44 CET] <ubitux> s/of/i/ [16:45:59 CET] <kierank> ubitux: where is this? [16:46:49 CET] <ubitux> http://blog.pkh.me/p/20-templating-in-c.html [16:46:59 CET] <kierank> ah no i dont want to use macros for that :( [16:47:11 CET] <ubitux> the macro overhead is low [16:47:17 CET] <kierank> they look ugly [16:47:21 CET] <ubitux> look at "Mixing full functions mechanism and macro" [16:47:48 CET] <ubitux> or the section just before with no macro [16:48:24 CET] <cone-102> ffmpeg 03Michael Niedermayer 07master:ed0c550564a8: avcodec/utils: run ff_frame_thread_encoder_init() only for encoders [16:48:32 CET] <wm4> rewrite in C++ [16:48:37 CET] <kierank> I'm just going to clip normally [16:48:56 CET] <kierank> I don't care much for the c anyway [16:50:57 CET] <michaelni> durandal_1707, yes, it segfaults, i fixed one bug but there likely are more [16:51:16 CET] <kierank> BBB: also is adding GBRAP12 pixel format hard? [16:53:06 CET] <jamrial> BBB:, kierank: maybe the arm optimized versions of clip_unit* could use av_builtin_constant_p? [16:54:22 CET] <jamrial> or yeah, just use generic av_clip. on x86 it should use cmov anyway [16:54:35 CET] <michaelni> durandal_1707, actually it seems your patch is nearly working now after that single bugfix [16:54:45 CET] <michaelni> iam getting "sample/frame number mismatch in adjacent frames" [16:55:04 CET] <michaelni> and it likely still would try to use threading with all non video encoders [16:55:14 CET] <BBB> kierank: no [16:55:56 CET] <BBB> jamrial: probably, but there may be compilers not supporting that [16:56:05 CET] <BBB> jamrial: not sure :) [16:56:46 CET] <BBB> and do we hae agreement on how hwaccel+mt should work now? Ill get to coding then sometime soon [16:58:04 CET] <wm4> BBB: if you could somehow lock out concurrency completely in this scenario, that would be ideal [16:58:18 CET] <BBB> I think thats the goal [16:58:40 CET] <jamrial> are there arm compilers we support that are not gcc or clang? av_builtin_constant_p seems to check for __GNUC__ [16:58:43 CET] <BBB> i.e. if hwaccel is enabled and active, just lock the child and parent codec context together in their respective calls to decide_frame [16:58:45 CET] <fritsch> what's the benefit of hwaccel and mt if I may ask? [16:58:51 CET] <BBB> fritsch: none [16:58:53 CET] <fritsch> i see really none [16:59:05 CET] <BBB> fritsch: but we want hwaccel fallback to software to use mt [16:59:11 CET] <fritsch> wait [16:59:14 CET] <fritsch> we have something in kodi [16:59:18 CET] <BBB> fritsch: so we cannot just disable it by setting avcodeccontext.n_threads to 1 [16:59:27 CET] <fritsch> ah! to make it easier [16:59:33 CET] <fritsch> to not have to recreate everything [16:59:41 CET] <BBB> well, more for end user transparency [16:59:58 CET] <BBB> you should be able to enable mt and hwaccel and have us figure out whats good for you [17:00:00 CET] <fritsch> yeah - we reimplemented this scenario in kodi ~6 months ago [17:00:07 CET] <fritsch> some patches were send and merged by rainer hochecker [17:00:11 CET] <fritsch> our player head dev [17:00:30 CET] <fritsch> for the fallback that is [17:00:42 CET] <BBB> its hard to know when the fallback is enabled [17:00:45 CET] <fritsch> did not need "many" ffmpeg changes, something with VC1 was an issue [17:00:46 CET] <BBB> it can switch within the stream [17:00:53 CET] <BBB> (adaptive) [17:01:03 CET] <fritsch> okay - I trust you guys there [17:01:11 CET] <BBB> its good that you did it, dont get me wrong [17:01:12 CET] <fritsch> but please don't win MT by locking everything out ... [17:01:19 CET] <fritsch> that won't help in performance and is just ugly [17:01:35 CET] <BBB> dont worry, if theres anything Im good at, its performanc [17:01:40 CET] <fritsch> BBB: i did not take any offense, happy that it gets easier in the future [17:01:49 CET] <fritsch> to fallback [17:01:53 CET] <fritsch> hehe, I know - I read your blog [17:02:12 CET] <BBB> \o/ [17:02:30 CET] <fritsch> you do ffmpeg for living? or work at a university in the topics? [17:02:41 CET] <fritsch> (sorry for offtopic) [17:03:49 CET] <BBB> I do & video technology, I guess, for a living [17:03:55 CET] <BBB> so ffmpeg is part of it [17:04:00 CET] <BBB> but I do other things also [17:04:14 CET] <BBB> Ill talk on my blog when its ready to be talked about ;) [17:04:59 CET] <fritsch> thx for that - looking forward to read it [17:05:07 CET] <fritsch> and adjusting our fallbacks of course [17:05:23 CET] <fritsch> though - we will do when it is released as a stable [17:05:56 CET] <fritsch> BBB: btw. we have some patches in kodi's ffmpeg since a very, very long time - who could we ask to check if they were needed and useful or just too specific and only useful for us? [17:07:19 CET] <fritsch> https://github.com/xbmc/FFmpeg/commits/release/2.8-xbmc <- just 11 while the second could be interesting for nevcairiel [17:07:29 CET] <fritsch> as we had some AMD windows bailouts without that [17:08:06 CET] <BBB> lemmesee [17:08:17 CET] <BBB> from e00 onwards? [17:08:44 CET] <fritsch> exactly, including [17:09:29 CET] <Daemon404> none of these have any explanation as to why they are dine [17:09:34 CET] <Daemon404> just "do x" or "fix X" [17:09:52 CET] <fritsch> as said, historical since many years [17:10:06 CET] <fritsch> that's why I also did not just want to send them to the ML [17:11:00 CET] <fritsch> https://github.com/xbmc/FFmpeg/commit/4f9b154ad5b55e50d866a3907a20164d21a2b… <- what about this one? [17:12:00 CET] <BBB> I think about half of them seem sensible [17:12:08 CET] <BBB> I also feel some of them are outdated and may not be necessary anymore [17:12:19 CET] <BBB> it always helps to have files to reproduce, esp. for things like memleaks [17:12:26 CET] <BBB> (4f9) [17:12:28 CET] <fritsch> jep, exactly [17:12:38 CET] <fritsch> the devs that did them are long gone [17:12:48 CET] <fritsch> so - that's my issue [17:12:48 CET] <fritsch> hehe [17:13:30 CET] <BBB> it suggests that at some point, a code path existed where read_packet bails out without freeing allocated packets [17:13:43 CET] <BBB> we can trace the code and see if that was the case years ago and if its still the case now [17:13:46 CET] <BBB> thats not super-hard [17:14:01 CET] <cone-102> ffmpeg 03Paul B Mahol 07master:06f65fd026a1: avcodec/dcaenc: return correct number of bytes in output packet [17:14:02 CET] <cone-102> ffmpeg 03Paul B Mahol 07master:5dc37a5d8abd: avcodec/dcaenc: do not change user requested bitrate [17:14:09 CET] <BBB> and if not, it can go (I suspect this was fixed since then, but its good to check anyway) [17:14:18 CET] <BBB> if not, we fix a real bug! :) [17:14:23 CET] <fritsch> hehe [17:14:30 CET] <BBB> (obv by fixing it instead of keeping state) [17:14:43 CET] <BBB> because right now you probably still get the memleak if you exit the loop and close the demuxer after [17:14:45 CET] <BBB> which isnt quite right [17:20:21 CET] <durandal_1707> michaelni: the pts are wrong, but same doesn't happen with video frame mt [17:27:30 CET] <nevcairiel> fritsch: i havent had any reports about amd for a long time, i have some work arounds of my own in the user code however, not in avcodec [17:27:50 CET] <fritsch> nevcairiel: oki [17:28:23 CET] <fritsch> just wanted to point out, kodi does not have some "secret black magic code" somewhere - we just don't know how / if to send them upstream, cause for most we don't have samples anymore - nor trac references [17:28:46 CET] <fritsch> we could: just drop them and see what happens, though [17:28:47 CET] <fritsch> hehe [17:29:25 CET] <wm4> cargo cult patches are the best patches [17:29:29 CET] <fritsch> hehe [17:29:38 CET] <atomnuker> If I set *got_frame = 0 I get "Unable to parse option value "0x0" as image size" [17:31:07 CET] <BBB> old patches like these are the best [17:31:12 CET] <BBB> it fixed some issue 5 years ago" [17:31:21 CET] <BBB> and nobody knows what to do [17:31:44 CET] <BBB> ohwell, every project has these issues, its a luxury to be >5 years old I guess [17:42:25 CET] <durandal_1707> michaelni: how are encoded frames - packets handled? first one wins? [17:46:30 CET] <michaelni> not sure i understand but order should be maintained, the actual encoding could occur in any order (as it doesnt matter for intra only encoders) [17:48:47 CET] <BBB> assuming it uses frame-mt, it autoamtiaclly waits the next to finish (so if frame N finished last, it pthread_cond_waits on N+1) [17:49:06 CET] <BBB> and that automatically means order is maintained [17:49:45 CET] <BBB> the threads themselves are responsible for handling inter-frame dependencies, so N+2 could finish earlier for intra-only, but the frame will never be handed back to frame-mt layer until N+1 is picked up first [17:49:58 CET] <durandal_1707> michaelni: flac is busted as it have counter inside code, wavpack produces bitexact audio but pts are wrong [17:50:45 CET] <BBB> durandal_1707: update_thread_context to sync counters between threads [17:51:52 CET] <durandal_1707> BBB: we are talking about audio encoders [17:52:11 CET] <BBB> they work the same [17:59:24 CET] <atomnuker> here's a horror story for you: the Dirac decoder's way of handling references [17:59:57 CET] <atomnuker> the format was extended to insane levels back when it was actively developed just to try to make it competitive [18:00:05 CET] <atomnuker> so naturally it has B-frames [18:00:14 CET] <durandal_1707> BBB: frame_thread_encoder is different [18:00:39 CET] <BBB> durandal_1707: I dont think you want to use frame_thread_encoder, theres clearly an inter dependency [18:00:41 CET] <BBB> (the counter) [18:00:52 CET] <BBB> :-p [18:02:37 CET] <durandal_1707> It works with alac [18:03:25 CET] <durandal_1707> BBB: no code use pthread stuff for frame encoding [18:03:41 CET] <BBB> I wasnt suggesting that [18:03:47 CET] <BBB> nevermind [18:04:11 CET] <durandal_1707> I guess the counter could be derived from pts [18:05:36 CET] <BBB> oh I see frame_thread_encoder is not mt derived [18:06:27 CET] <BBB> so & nobody will like me for saying this [18:06:30 CET] <BBB> and youre just gonna flame me [18:06:41 CET] <BBB> but you should look at how frame-mt (decoder) uses update_thread_context [18:06:49 CET] <BBB> and use that callback for frame_thread_encoder.c also [18:06:52 CET] <BBB> it solves your problem [18:08:41 CET] <jermy> I need to get some information which is embedded in a SEI message. I assume the only place to sensibly copy data out is in libavcodec/h264? [18:13:25 CET] <kierank> jermy: there are a number of examples already there [18:13:26 CET] <kierank> yes [18:13:28 CET] <kierank> as side data [18:16:37 CET] <jermy> This is largely the use of AVFrameSideData? [18:17:36 CET] <kierank> yes [18:17:45 CET] <kierank> but the way it's handled is a bit nontrivial [18:18:42 CET] <Daemon404> ^ this quote should be at the top of every libav* API doc [18:18:43 CET] Action: Daemon404 runs [18:27:29 CET] <Daemon404> the suspense is killing me [18:28:50 CET] <jermy> ...profit? [18:35:50 CET] <BtbN> "I am having issues converting an mp3 to an mp4 with a single watermark image and then converting that mp4 into mpeg ts for streaming." yes, I'd kind of call that an issue oO [18:36:19 CET] <durandal_1707> BBB: proper flac mt needs syncing between workers [18:37:15 CET] <durandal_1707> michaelni: ^ [18:40:37 CET] <ubitux> nevcairiel: when is the next merge scheduled? [18:41:23 CET] <ubitux> (there are ~80 commits) [18:42:40 CET] <Daemon404> i can help if need be... [18:50:39 CET] <michaelni> durandal_1707, some form of sync would need to be added, calling update and waiting for that like BBB suggested, or maybe its enough to just give each encoder a frame number for this case or something else [18:51:20 CET] <durandal_1707> nah, flac keeps crap in stream info [18:51:37 CET] <durandal_1707> Of all frames encoded [19:07:05 CET] <cone-102> ffmpeg 03James Almer 07master:209f50e16b5e: avcodec/synth_filter: split off remaining code from dcadec files [19:21:13 CET] <BBB> durandal_1707: thats update_thread_context, I just said that [19:21:31 CET] <BBB> oh michaelni already said that [19:29:37 CET] <durandal_1707> I don't get how to sync those workers [19:30:12 CET] <nevcairiel> it would need quite a bunch of infrastructure [19:30:36 CET] <nevcairiel> and depending on how the encoders work, might not actually work in frame threading [19:31:03 CET] <nevcairiel> ie. if you only Žknow all the parameters after you are done encoding the entire packet, then there is nothing to gain [19:32:38 CET] <durandal_1707> nah, flac just need to pick between values of all workers after they finish work [19:33:03 CET] <durandal_1707> and its just metadata [19:33:22 CET] <durandal_1707> flac format needs it [19:33:54 CET] <BBB> durandal_1707: frame-mt uses ff_thread_finish_setup as initiation point of synchronization between workers [19:34:39 CET] <durandal_1707> But frame-mt is only used for decoding [19:35:28 CET] <durandal_1707> if it was actually used for frame encoding I would use it [19:37:26 CET] <durandal_1707> I don't think that infrastructure works for encoding [19:39:31 CET] <durandal_1707> It's funny because alac may now be faster than flac [19:41:30 CET] <BBB> Im not saying you use it [19:41:34 CET] <BBB> Im saying you use something like it [19:42:00 CET] <BBB> it could even use the same function ptr in AVCodec [19:42:01 CET] <Venti^> is AV_CODEC_FLAG_INTERLACED_DCT the correct flag to watch for to see if interlaced field coding should be used instead of progressive? [19:47:56 CET] <cone-102> ffmpeg 03Mats Peterson 07master:191ec55c9fc1: lavc/rawdec: Use 16-byte line alignment for AV_PIX_FMT_MONOWHITE [19:47:57 CET] <cone-102> ffmpeg 03Vittorio Gambaletta (VittGam) 07master:8b02af1e6fbb: avformat/mpegtsenc: Fix multi program so that it supports adding the same stream to multiple programs. [19:53:36 CET] <roxlu> Hey! Does someone knows the tool "DVBAnalyzer" ? I'm using ift for a project and I'm getting an log message like "PTS_PCR problem (PTS is -0.90ms in the past!)" I'm trying to understand the meaning of that message. I would say that this may be caused by a PTS value which is behind the PCR; though when I log the PCR / PTS values from my MpegTS stream they are all nicely monotonically increasing. [20:29:48 CET] <wm4> nevcairiel: does "delaying" frames really help that much? [20:29:53 CET] <nevcairiel> yes [20:30:50 CET] <wm4> but only with nvidia? [20:30:51 CET] <nevcairiel> at least on nvidia, on intel its so-so, i forgot what amd did [20:30:58 CET] <wm4> ok [20:31:05 CET] <wm4> maybe I should do this in my own code [20:31:16 CET] <nevcairiel> its not like its a complex feature [20:31:32 CET] <nevcairiel> i just have a static AVFrame array with 2 members and a variable that I modulo around to index into it [20:31:46 CET] <nevcairiel> (not static as in global, mind you) [20:37:19 CET] <durandal_1707> why is dvaudio decoder in lavf? [20:38:55 CET] <nevcairiel> because dv is all sorts of crazy [20:38:58 CET] <nevcairiel> a container in a container [20:40:52 CET] <Compn> dvaudio in mov and avi... [20:42:04 CET] <Compn> not sure specifically which dvaudio files need the lavf demuxer, but we probably have such samples. [20:43:27 CET] <Compn> should we keep track of such things in some kind of document somewhere ? [20:43:38 CET] <Compn> like a reason for foobar.c to exist ? [20:44:37 CET] <nevcairiel> I thought avi specifically had dv support as well [20:47:30 CET] <Compn> well [20:47:58 CET] <Compn> it looks like , from that ffmpeg output, that pinnacle didnt write the audio two cc (it says 'none') so i'm guessing thats causing some problem too [20:49:01 CET] <Compn> oh lol [20:49:09 CET] <Compn> old ffmpeg output, ignore m [20:49:26 CET] <nevcairiel> did write a twocc though, 0x0216 [20:49:29 CET] Action: nevcairiel looks it up [20:49:44 CET] <Compn> thats ulead dv acm yes [20:49:56 CET] <Compn> it should work in mplayer :P [20:50:03 CET] <nevcairiel> anyway thats the original file, no idea about the new one [20:51:26 CET] <Compn> hmmm [20:51:32 CET] <Compn> https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket1564/Test_DV_Audio.avi [20:51:34 CET] <cone-102> ffmpeg 03Andreas Cadhalpun 07master:b46aae093634: build: use a link instead of changing current directory when compiling [21:08:36 CET] <durandal_1707> Compn: where is the ulead decoder in mplayer? [21:26:58 CET] <Compn> durandal_1707 : binary codec [21:27:06 CET] <Compn> you mean where is the dll file ? [21:28:04 CET] <Compn> http://samples.ffmpeg.org/drivers32/newcodecpack/DVACM.acm [21:28:18 CET] <durandal_1707> vlc have decoder but its gpl [21:28:52 CET] <Compn> right there is "libdv" [21:29:01 CET] <durandal_1707> I think guy that wrote it is no longer alive [21:29:19 CET] <Compn> forever gpl. :p [21:45:22 CET] <durandal_1707> Compn: miracle, it is relicensed to lgpl [21:48:27 CET] <wm4> so fast? [21:59:02 CET] <durandal_1707> I was looking initial version [21:59:50 CET] <durandal_1707> vlc likes to not give decoders to us, so I will steal from them [22:02:25 CET] <wm4> don't let j-b know [22:15:04 CET] <j-b> durandal_1707: what VLC decoder is GPL? [22:32:56 CET] <durandal_1707> j-b: it was, ulead dv audio [22:34:15 CET] <nevcairiel> that code looks like it was ripped out of the dv demuxer on a cursory look [22:34:25 CET] <Compn> what is dvaudio decoder? just libdv ? [22:34:32 CET] <j-b> durandal_1707: this is LGPL since a long time. [22:34:43 CET] <nevcairiel> Compn: dvaudio is just jumbled up pcm, no reason to use a library [22:34:44 CET] <durandal_1707> ubitux: when you gonna comment streamselect [22:34:52 CET] <j-b> durandal_1707: and it's tless than 120 LoC [22:35:00 CET] <Compn> nevcairiel : i mean "dvaudio" in libavcodec is listed twice.. [22:35:08 CET] <cone-102> ffmpeg 03Marton Balint 07master:fe4a2cbd4d22: lavc/libzvbi-teletextdec: use the built-in transparent color for transparent background [22:35:10 CET] <cone-102> ffmpeg 03Marton Balint 07master:92f2a9dbc501: lavc/libzvbi-teletextdec: remove cmax variable [22:35:11 CET] <cone-102> ffmpeg 03Marton Balint 07master:73e4565dff92: lavc/libzvbi-teletextdec: add support for setting background opacity [23:09:42 CET] <ubitux> durandal_1707: oh damn i'm sorry i forgot [23:09:46 CET] <ubitux> give me an hour [23:10:46 CET] <durandal_1707> no hurry [23:44:05 CET] <ubitux> durandal_1707: segfault if !map [23:44:37 CET] <ubitux> assert if map is empty [23:46:56 CET] <durandal_1707> default could be set to something [23:48:46 CET] <ubitux> so i'm trying stuff like ./ffmpeg_g -re -f lavfi -i testsrc2 -ss 30 -re -f lavfi -i testsrc -lavfi "[0][1] streamselect=2:map=1" -f xv - and using 'c' to enter stuff like "all -1 map 0" and it seems to work fine [23:49:00 CET] <ubitux> i would love some examples in the documentation though [23:50:01 CET] <ubitux> if i use: [23:50:03 CET] <ubitux> ./ffmpeg_g -re -f lavfi -i testsrc2 -ss 30 -re -f lavfi -i testsrc=s=hd720 -lavfi "[0][1] streamselect=2:map=1" -f xv - [23:50:09 CET] <ubitux> i get glitchy outputs [23:50:12 CET] <ubitux> (mismatching dimensions) [23:51:56 CET] <ubitux> if you set an invalid map value, the filter is in a freezed state apparently [23:52:45 CET] <ubitux> so 5 things, sigsegv if !map, abort if empty map, examples in documentation, glitches if mismatching resolution, and broken state with invalid map commands [23:52:59 CET] <ubitux> do you want me to post these on the ml? [23:53:05 CET] <ubitux> durandal_1707 ^ [23:58:44 CET] <durandal_1707> ubitux: itsnot glitchy, using lavf to test this is wrong [23:59:03 CET] <ubitux> ah, ok [00:00:00 CET] --- Tue Jan 26 2016

1 0

ffmpeg.log.20160125
by burek 26 Jan '16

26 Jan '16

[01:11:15 CET] <Snaggle> Using ffmpeg-git to make a movie from a series of tiffs. The command and ffmpeg output is at http://pastebin.com/yeLiCQBY But when I try to play the local file in Firefox, I get an error that the video is corrupt and unplayable. [01:12:11 CET] <J_Darnley> What do I want to bet on? [01:13:25 CET] <J_Darnley> So many reasons. yuv444? vp9? no audio stream? [01:13:31 CET] <furq> vp9 and no audio should be fine [01:13:44 CET] <furq> i'm pretty sure yuv444p isn't supported by browsers [01:14:02 CET] <furq> Snaggle: -pix_fmt yuv420p [01:14:45 CET] <J_Darnley> Well, the browser in this case isn't as rubbish as it could be. [01:14:45 CET] <furq> http://stackoverflow.com/a/21510586/1516484 [01:14:47 CET] <furq> nice answer J_Darnley [01:15:24 CET] <furq> that's not even the worst answer on the page [01:15:42 CET] <J_Darnley> A GUI? What kind of pleb do you think I am? [01:16:13 CET] <furq> the kind of pleb who doesn't want to run three separate tools to demux a pgc? [01:17:19 CET] <furq> handbrake is actually quite good now provided you have a relatively clean source [01:20:05 CET] <Snaggle> thank you. pix_fmt did it. [01:50:36 CET] <andrey_utkin> any idea how to cope with NOPTS from mkv files? Want to concat a couple of _streamed_ ones (mkv saved to seekable files works fine). Simple testcase: https://gist.github.com/andrey-utkin/d24f2fa744bd18a2067a Output: https://gist.github.com/andrey-utkin/f9b72c0ae711716500c8 [02:29:12 CET] <andrey_utkin> http://trac.ffmpeg.org/ticket/5186 help is appreciated [02:44:08 CET] <J_Darnley> Is catting mkv supposed to work? [02:59:22 CET] <andrey_utkin> J_Darnley: why not? [02:59:50 CET] <andrey_utkin> J_Darnley: or you mean cat(1)? [03:01:13 CET] <J_Darnley> Yeah, isn't that what concat does? [03:06:49 CET] <furq> you're thinking of the concat protocol [03:07:04 CET] <furq> -f concat is the concat demuxer [03:08:46 CET] <J_Darnley> oh my bad [04:48:14 CET] <Chagall> so i have an audio file with mono and 5.1ch audio [04:48:30 CET] <Chagall> i encode it with opus but every time mediainfo says it is 6 channels [04:48:40 CET] <Chagall> regardless of which one i select, and the ID seems right [04:51:05 CET] <Chagall> nevermind, seems a container issue [05:20:18 CET] <tldr`> http://news.softpedia.com/news/zero-day-ffmpeg-vulnerability-lets-anyone-st… [05:20:21 CET] <tldr`> has this been fixed? [05:20:54 CET] <furq> did you read to the end of the article [06:35:17 CET] <tldr`> now i did [07:39:57 CET] <jleclanche> I'm trying to concat 4 mp4 files together so I followed the wiki and used -f concat, but it says Requested output format 'concat' is not a suitable output format. any idea why? [07:45:21 CET] <chungy> You need to use -f concat with input, not output. [08:01:48 CET] <jleclanche> chungy: oh of course [08:01:57 CET] <jleclanche> I keep forgetting how argument ordering works in ffmpeg [08:02:33 CET] <jleclanche> hmm, Invalid data found when processing input [08:29:52 CET] <jleclanche> Aight well I tried several of the concat ways but all of them result in a corrupt file :( `ffmpeg -f concat -i list -c copy output.mp4` gives me something fine for the first chunk, but then completely corrupt for the last 3 (spams "aac: Number of bands (49) exceeds limit (40)." when testing it with mpv and crashes) [08:46:23 CET] <durandal_1707> you can't use copy if input params change [09:04:33 CET] <jleclanche> durandal_1707: input params don't change, that I know of [09:04:41 CET] <jleclanche> chungy: what do you want pastebinned? [09:06:51 CET] <chungy> The command you're using and the output [09:15:40 CET] <jleclanche> chungy: results of ffmpeg -f concat -i list -c copy output.mp4: http://sprunge.us/YTeR [09:17:05 CET] <chungy> that looks like a successful run... [09:18:01 CET] <jleclanche> chungy: mpv output playing the file: http://sprunge.us/dhPd [11:45:20 CET] <andrey_utkin> Please recommend some multimedia container format which supports h264 & flac, is streamable, and is not matroska (because i have this bug with matroska http://trac.ffmpeg.org/ticket/5186) [11:47:40 CET] <JEEB> I can't recommend it for anything else than ffmpeg-to-ffmpeg but there's NUT [11:47:53 CET] <JEEB> it's usually used for raw video and audio piping [11:48:03 CET] <JEEB> for compressed formats it's usually not used [11:48:15 CET] <JEEB> but it can do them [11:52:19 CET] <explodes> When FFMpeg decodes my video track as scrambled images, what is a common mistake I may be making? [11:52:35 CET] <explodes> The audio track is also very high-pitched. [11:53:09 CET] <explodes> In some videos I get a line of output saying something about how mis-alignment may cause slowdown [11:53:11 CET] <andrey_utkin> JEEB: yes this is for ffmpeg-to-ffmpeg, thanks, will try [11:53:28 CET] <andrey_utkin> any ideas what's that matroska bug and how to overcome? [11:53:44 CET] <BtbN> andrey_utkin, just stream-copy the mkvs to a new mkv before concating them, should work fine after that. [11:54:34 CET] <andrey_utkin> BtbN: i want to avoid transition files for max performance and for simplicity [11:55:03 CET] <BtbN> Well, that doesn't seem to work too well. [11:55:30 CET] <andrey_utkin> yep but i'm sure it is supposed to work well somehow [11:55:39 CET] <andrey_utkin> that way [11:55:44 CET] <BtbN> It's supposed to work well with non-broken files [11:57:33 CET] <andrey_utkin> well, then ffmpeg produces broken matroska files when in streaming mode [11:59:33 CET] <BtbN> It does that for quite a few files if it's unable to write the "lead-out", which is the case if you write to stdout, because it can't seek in the output file. [11:59:56 CET] <BtbN> Just stream-copying to a local mkv file should fix that. [12:01:00 CET] <andrey_utkin> in my usecase, it'll be doing it all the time, so "quite a few files" is wrong thing to say [12:27:36 CET] <andrey_utkin> Thanks JEEB, nut seems to do what I ultimately want, but with some weirdness in logs: https://gist.github.com/andrey-utkin/5c61d91acbd8a32acef1 (script: https://gist.github.com/andrey-utkin/d1d204884d49b8f1a9c3) [12:27:58 CET] <andrey_utkin> see "invalid dropping" [12:37:27 CET] <explodes> video doesn't get scrambled when I change the output size.. interesting indeed [12:58:34 CET] <andrey_utkin> created a ticket for nut concat warnings issue http://trac.ffmpeg.org/ticket/5189 [13:00:08 CET] <explodes> Sorry for keeping on asking dumb random questions, but I'm not very smart with ffmpeg or c for that matter. I'm trying to build ffmpeg for android, and I get some compiler errors. I get a lot of errors say "version.h" isn't found [13:00:19 CET] <explodes> I'm building 2.7.2 [13:00:48 CET] <andrey_utkin> explodes: how do you build it? [13:01:06 CET] <andrey_utkin> and what output it gives you? [13:01:18 CET] <explodes> let me show you, give me a sec [13:01:32 CET] <andrey_utkin> whare full input and output via pastebin [13:01:36 CET] <andrey_utkin> share [13:02:15 CET] <explodes_> build output: http://pastebin.com/LwPbBW3W [13:02:50 CET] <explodes_> build script: http://pastebin.com/KdYxjcqS [13:04:01 CET] <andrey_utkin> where from is the ffmpeg sources tree? [13:04:12 CET] <andrey_utkin> is it tarball of release downloaded, or a git checkout? [13:04:46 CET] <explodes> tarball [13:04:54 CET] <andrey_utkin> from where? [13:05:23 CET] <explodes> from here: https://www.ffmpeg.org/download.html [13:06:49 CET] <andrey_utkin> i have just downloaded http://ffmpeg.org/releases/ffmpeg-2.8.5.tar.bz2 , extracted it, and I see there are version.h in all lib subdirs. [13:07:06 CET] <andrey_utkin> i guess 2.7.2 tarball should have them, too [13:07:37 CET] <andrey_utkin> so try again [13:07:53 CET] <andrey_utkin> BTW why not the latest release? [13:07:58 CET] <explodes> weird, dunno why they disappeared [13:08:20 CET] <explodes> no real reason, just haven't upgraded and done all of the testing. I'm going to try with 2.8.5 now, though. [13:08:42 CET] <explodes> that tarball was downloaded last september [13:11:33 CET] <explodes> dunno how that happened, maybe something happened in git somewhere, but 2.8.5 is building fine so far [13:29:05 CET] <explodes> yep. there was .gitignore that ignored, explicitly, add version.h files. [13:29:32 CET] <andrey_utkin> explodes: if you use git, just make ffmpeg a submodule [13:32:46 CET] <explodes> will do. [13:33:13 CET] <explodes> but first, now that my ffmpeg is built, it's back to debugging SIGSEGV's and very high-pitched audio streams [14:18:56 CET] <t4nk183> Hey, would anyone be able to help me with my encoding settings? I am trying to create two pass encoding settings but can't seem to get it to run correctly. The individual lines work but not as a two pass setup using Windows Form C#. My arguments - http://pastebin.com/vbYEaRCR. Any help at all would be great thanks! [14:19:50 CET] <DHE> and what errors are you getting? [14:20:58 CET] <t4nk183> I tried && to join the passes together but I am given invalid arguments [14:24:58 CET] <DHE> that's a unix shell-ism. does windows do that [14:25:44 CET] <J_Darnley> cmd supports it too [14:26:22 CET] <J_Darnley> t4nk183: who says "invalid arguments"? ffmpeg or c#? [14:26:45 CET] <t4nk183> ffmpeg [14:26:48 CET] <DHE> (this is why you should paste everything, not just your commandline) [14:32:52 CET] <J_Darnley> Are you going to give us the whole log? [14:35:04 CET] <t4nk183> Yes sorry it's on a separate machine. I'll grab it now. [14:35:35 CET] <dorp> Could I screen-capture a playing video stream of 100fps, with gdigrab? Is there an internal limit to the captured framerate? I would like to learn and read further about the nature of 'gdigrab', is there a recommended resource other than the brief usage within the docs? [14:36:14 CET] <J_Darnley> The source code? It is the ultimate reference. [14:36:36 CET] <J_Darnley> I don't see why there would be an arbitrary limit though. [14:36:43 CET] <waressearcher2> dorp: https://trac.ffmpeg.org/wiki/Capture/Desktop [14:37:46 CET] <dorp> waressearcher2: Thanks, but these are merely usage examples with brief commentary [14:38:18 CET] <t4nk183> The entire log: http://pastebin.com/C4D6Nc7N [14:38:53 CET] <J_Darnley> You can't use && to chain commands without going through the shell [14:38:54 CET] <DHE> dorp: 100 is a bit extreme. you may experience a lot of deviation and drift because encoding real-time at 100fps might be too much for your system. [14:39:35 CET] <DHE> yeah, && is a shell thing. along with running it in a shell you'd have to specify "ffmpeg" at the start again since it's a second command to be run [14:40:16 CET] <dorp> DHE: How about high framerate, with a small resolution? 100fps with 100x100 [14:40:52 CET] <t4nk183> Ok and is there a windows equivalent? [14:41:08 CET] <J_Darnley> Change how you run ffmpeg [14:41:26 CET] <J_Darnley> Either spawn/fork ffmpeg twice [14:41:30 CET] <DHE> dorp: that's a bit more reasonable, as long as it's a 100x100 capture window and not something silly like 1920x1080 being downsampled to 100x100 [14:41:36 CET] <J_Darnley> Or use a function which uses the shell [14:41:45 CET] <dorp> DHE: When I use such a framerate, the command line indicates: 'dups'... clearly these dups are not related to the source, because even if the source is static, it wouldn't indicate any dups at lower framerates. So wouldn't that suggest that there is another limitation somewhere? [14:42:15 CET] <J_Darnley> If you want to use && then you need the C# equivalent of system() [14:43:47 CET] <jkqxz> dorp: Are you sure the output that you are capturing from is actually rendering at 100Hz? If it's only rendering at 60Hz then half of your frames are disappearing before they get rendered, so you can't capture them. [14:45:05 CET] <dorp> jkqxz: But how would that explain the 'dups' as indication to capture-rate. Given a static/blank screen, 10fps, there are no dups. Same blank screen, 50fps, there are dups [14:45:34 CET] <J_Darnley> dups doesn't tell you anything about the content [14:45:50 CET] <jkqxz> Because the capture driver knows that the frame hasn't been rerendered since the last time it ran, so there is definitely a dup. [14:48:36 CET] <t4nk183> What do you mean by the C# equivalent of system()? [14:48:36 CET] <dorp> jkqxz: Let me try to expand on what I've attempted, I've taken a video stream with motion/camera-panning, cropped it to a small resolution, and played it at 100fps rate, which ran very smoothly and clearly [14:50:00 CET] <dorp> jkqxz: When I try to screen-capture said playing video stream, while adjusting the x/y and the video_size appropriately, there are lots and lots of dups, and the export doesn't represent the motion of the played video stream [14:50:34 CET] <DHE> t4nk183: in C there is a function called system() that calls out to run the command you specify [14:51:16 CET] <DHE> the idea being you'd run system("ffmpeg -i input.mp4 ... .... output.mp4"); and the easiest way to do it in C would be to run system() twice. must be something similar for C# ? [14:51:58 CET] <dorp> jkqxz: So I'm trying to understand where's the limitation? [14:54:02 CET] <dorp> Playing the same sample, at 23.976fps, 1920x1080 ... would result with a much better capture-export, so I came to the conclusion that the limitation is specific to the high framerate capturing? [14:54:44 CET] <jkqxz> dorp: You've also set the framerate argument to gdigrab? (Along with offset_x, offset_y and video_size.) [14:55:07 CET] <dorp> jkqxz: Yes, ./ffmpeg -f gdigrab -framerate 100 ... [15:04:59 CET] <jkqxz> Looking at the source (libavdevice/gdigrab.c), it looks like it always blindly copies, so the problem is probably somewhere else. [15:05:45 CET] <jkqxz> Given that it could be timing, have you tried with -vsync 0? [15:07:04 CET] <dorp> jkqxz: I've tried all the -vsync options within the docs, -1, 0, 1, 2 [15:07:40 CET] <dorp> The nature of the exports were very much different, most notably the elimination of all the duplicated frames [15:09:07 CET] <dorp> But the captured motion of the 23.976fps 1080p sample, is still much better than the captured motion of the 100fps 100x100 sample [15:09:31 CET] <dorp> So I just wanted to know what's the consideration/limitation behind that [15:14:33 CET] <jkqxz> I don't know. Probably somewhere in the interaction between rendering and capture, but that's going to be a Windows thing rather than ffmpeg. The screen you're capturing really is a 100Hz output with a 100Hz monitor here, right? [15:16:19 CET] <dorp> jkqxz: I don't know if the screen matches the exact properties, all I know is that by playing the source, and playing the export, there's a big gap [15:16:46 CET] <dorp> jkqxz: (I'm pretty much a beginner that would like to understand the concepts behind screen capturing) [15:19:54 CET] <jkqxz> The rendering will likely run at whatever the framerate of the output is (hence the output and monitor being important), and that gets pasted into a framebuffer somewhere. The capture just reads out of that framebuffer at it's own specified rate, with that rate not synchronised to the input. [15:21:06 CET] <jkqxz> As such, nasty things can happen if those rates don't quite match, because the capture can easily read the same frame twice or miss a frame. [15:22:58 CET] <jkqxz> It also changes the duration of frames. Suppose you have a 1/3Hz output and a 1/2Hz capture (somewhat similar to your case). Frames are output at times 0, 3, 6, 9 ..., and are captured at times 0, 2, 4, 6, .... [15:24:13 CET] <dorp> But isn't that the purpose of duplicating frames? For adjusting the timing? [15:24:21 CET] <jkqxz> Then the even frames (at 0, 6, ...) will appear twice in the capture, but the odd frames (3, 9, ...) will only appear once. Since it then plays back at uniform rate, the captured video will look very stuttery despite the output not being. [15:27:14 CET] <jkqxz> The duplication doesn't help, because it still doesn't know the original clock that the output was running on before it captured. It's just making sure that the output is uniform from its point of view, but it doesn't have enough information to help here. [15:28:06 CET] <dorp> I assume that all the issues that you mention, are not specific to ffmpeg or gdigrab, right? [15:29:05 CET] <dorp> Do you think that 'hardware' capture devices are likely to handle such issues better? Or it's likely to be more of the same? [15:29:26 CET] <jkqxz> Correct. Something cleverer than gdigrab might be able to fix it up by knowing the output clock. [15:30:33 CET] <jkqxz> A hardware device will do better, because the capture there is purely derived from the output clock (it will just capture frames as they are given to it). [15:32:19 CET] <jkqxz> Can you try modifying the capture framerate until you don't get stuttery video? If it looks smooth at 60, then that's what your output is and therefore where your problem lies. [15:34:18 CET] <dorp> jkqxz: I was under the assumption that there is no 'precise' number, because the display rate/interval is not required to be precise, and it could lag/shift? [15:40:17 CET] <jkqxz> Not very much. Clock error there is on the order to tens of ppm. (So at worst 1 frame off after 100000, so a drop/dup at most every ~15 minutes at 100Hz.) [15:40:42 CET] <jkqxz> Differences in software latencies on a loaded system are much larger. [15:41:34 CET] <dorp> I see. So it definitely worth trying a range of framerates [15:42:01 CET] <jkqxz> Maybe that should be 10000 -> ~2 minutes. Still, sufficiently low to not be very significant. [15:44:59 CET] <dorp> BTW, is there a better sample to evaluate motion-stutter, than camera-panning? [15:46:33 CET] <jkqxz> Make a 1000-frame video out of images of the numbers 1..1000? [15:47:58 CET] <dorp> That would be interesting [15:57:54 CET] <jkqxz> for i in $(seq -f "%03g" 0 999) ; do convert -size 100x100 xc:white -pointsize 48 -fill black -draw "text 10,64 '$i'" test-$i.png ; done [15:58:05 CET] <jkqxz> ffmpeg -framerate 100 -i 'test-%03d.png' -c:v libx264 -r 100 -pix_fmt yuv420p numbers.mp4 [15:58:24 CET] <jkqxz> ffmpeg ftw :) [16:14:27 CET] <dorp> jkqxz: Thanks a lot, I'll bbs and share the result [16:17:43 CET] <dorp_> jkqxz: Thanks a lot, I'll bbs and share the result [17:36:30 CET] <dorp_> jkqxz: Hmmm... I've used the sequence of frames for creating a 25fps stream, I played it, and captured it with -framerate 25 .. and within ~15 frames, I have 2 dups, and 2 missing frames (without -vsync) [17:36:51 CET] <andrey_utkin> JEEB: (sorry to disturb you) the same issue happens with nut when I specify x264: https://gist.github.com/andrey-utkin/633090e183e82b3ae5a4 , script: https://gist.github.com/andrey-utkin/1900b6098e09806dc1e0 [17:37:15 CET] <dorp_> It seems reasonable? Maybe there's something wrong with my setup? [17:49:54 CET] <jkqxz> dorp_: The real framerate might not be divisible by 25, then? I'm still expecting you can find a framerate (30 or 60?) that will play perfectly. [18:11:37 CET] <andrey_utkin> anybody knows why h264 stream has NOPTS in first packet? matroska, nut etc. fail the purpose of this script: https://gist.github.com/andrey-utkin/208b18869e68cc83cc4d and only MPEG TS works: https://gist.github.com/andrey-utkin/208b18869e68cc83cc4d [18:11:49 CET] <wvuu> hello [18:12:00 CET] <wvuu> how to run ffplay with multiple threads? [18:12:25 CET] <wvuu> this option keeps mutatin, worse than flu bacteria. [18:20:49 CET] <digidog> ok after long research and with the help of some of you here I cam to the conclusion the qtgmc 50p via vapoursynth will be my best option for deinterlacing old DV PAL material for integration into uptodate cut. but I am totally lost of how to start scripting this. does anyone has examples around or links for script and how to fire them? is it like with shell scripts and ffmpeg, like a script injection in t [18:20:55 CET] <digidog> he command ? [18:21:35 CET] <ChocolateArmpits> digidog: hey digi, have you tried any scripts yet, did you come up with a base vpy script ? [18:21:50 CET] <digidog> ChocolateArmpits: hey! :) [18:22:42 CET] <ChocolateArmpits> I have written a batch script that writes a vpy script that performs quite a few actions, like connecting videos, adding subtitles, masking etc [18:22:54 CET] <ChocolateArmpits> so I can help you with the process [18:23:20 CET] <digidog> ChocolateArmpits: well honestly, ... I maybe was a litle bit fast with asking *hides* I used to work with avisynth back in the days a liltte but I honestly are a littel bit lost in the wild. I think I should rather take a nap, read some more and should test out some examples before asking :) [18:23:49 CET] <digidog> ChocolateArmpits: oh thats interesting o.O [18:23:51 CET] <ChocolateArmpits> digidog: ok but did you get vapoursynth running, did you test a script with your video ? [18:24:06 CET] <ChocolateArmpits> even simple i/o [18:25:10 CET] <digidog> ChocolateArmpits: errm, yes I did, 2 days ago ... but dont ask me ... I was 24 hour awake this day -.O ... let me check and come back 30 min later ? I dont want to waste your time while being unprepared :/ [18:25:27 CET] <digidog> ChocolateArmpits++ [18:25:28 CET] <ChocolateArmpits> You should get the Vapoursynth Editor https://bitbucket.org/mystery_keeper/vapoursynth-editor/overview [18:25:32 CET] <digidog> thanks a million for chiming in! [18:25:42 CET] <ChocolateArmpits> it has a scripting window and you can test and preview frames [18:25:49 CET] <digidog> ChocolateArmpits: ah good to know! [18:25:53 CET] Action: digidog grabs the link [18:26:02 CET] <ChocolateArmpits> http://forum.doom9.org/showthread.php?p=1689404#post1689404 here's how to build it, I think [18:26:15 CET] <ChocolateArmpits> it makes scripting easier [18:29:38 CET] <digidog> ChocolateArmpits: this is awesome start! thank you! [18:30:11 CET] <digidog> ChocolateArmpits: I will try to get in and come back later if I need a side kick :) [18:30:27 CET] <digidog> ChocolateArmpits++ [18:33:40 CET] <digidog> didn't I wanted to provide an additional Debian build instruction for vapoursynth ? *scratcheshead* I found asnippet here in the folder ... jesus, I must have been really tired this night ... [18:37:25 CET] Action: digidog filters chatlog, what I have talked to and with who the days ... [18:48:35 CET] <digidog> ah yes found it ... I have talked with Myrsloik about it :) [18:49:44 CET] <durandal_1707> off topic is off topic [18:53:37 CET] <digidog> Myrsloik: should I provide this Debian install info in markdown or what would be the best format ? [18:54:06 CET] <durandal_1707> qtgmc uses eedi for deinterlacing IIRC [20:58:13 CET] <Tzimmo> c_14: J_Darnley: I created ticket #5196 with a small sample. I can upload a larger (large!) sample if needed. [21:03:04 CET] <furq> durandal_1707: http://avisynth.nl/index.php/QTGMC#Interpolation [21:07:07 CET] <durandal_1707> furq: I ported nnedi3 to lavfi [21:08:02 CET] <J_Darnley> Not we just need mvtools and an easy to have filters call other filters! [21:09:00 CET] <J_Darnley> I cannot type worth a damn today [21:16:58 CET] <furq> well a better deinterlace filter would be much appreciated [21:17:07 CET] <furq> for starters it would mean that i'd never have to use avisynth again [21:45:12 CET] <YamakasY> mhh nice, cannot convert my flv to mp4 [21:45:32 CET] <YamakasY> [mp4 @ 0x32553a0] Could not find tag for codec nellymoser in stream #1, codec not currently supported in container [21:47:15 CET] <dystopia> what does -y before -i actually do? [21:51:13 CET] <kepstin> dystopia: the position of the '-y' doesn't actually matter, I think [21:51:54 CET] <kepstin> YamakasY: pretty obvious message there; your video is in the nellymoser codec, and you can't store that in mp4. you'll have to reencode the video (e.g. to h264) [21:54:53 CET] <J_Darnley> Yes, some options are global. [21:55:09 CET] <J_Darnley> Like -y, -n, and -loglevel [21:56:09 CET] <YamakasY> kepstin: I did and what a damn bad quality I get back :( [21:56:47 CET] <YamakasY> sound is great, video is artifacted [21:57:06 CET] <kepstin> YamakasY: then you might need to set some encoding options, like -crf to set a quality level (the default is sort of medium-low, try around 16) [21:57:25 CET] <YamakasY> kepstin: yeah ok, but this is the way ? [21:57:39 CET] <YamakasY> everyone wants to see his pr0n in good quality! :P [22:10:46 CET] <YamakasY> kepstin: heh now is the quality ok but does the sound not lineup [23:38:17 CET] <dorp_> I've been trying to screen-capture a playing video which consists of frames of 1,2,3,4,5... each frame is a digit, at the rate of 25fps. I've been trying to capture it at various rates from 25 and up to 50... and it seems that no matter what, in the scope of 4 seconds, 1 to 4 frames will be missing. Using -vsync would affect the timing and duplicate frames, but frames will still be missing [23:39:19 CET] <dorp_> Is it to be expected that within 100 frames, 1-4 frames to be missing via screen capture? Or I'm likely to be doing or having something wrong? [23:40:54 CET] <c_14> capture at your screen's refresh rate [23:42:22 CET] <kepstin> well, depending on the capture driver in use, you might not be able to hit the requested input fps. [23:45:33 CET] <kepstin> one common mistake is to use the '-r' input option rather than '-framerate' - but I think most capture drivers default to around 30fps which should be enough [23:45:53 CET] <kepstin> that said, when I was testing gdigrab on windows 7, I was lucky to get 12fps on my laptop :) [23:47:41 CET] <dorp_> c_14: My refresh rate seems to be 60hz, which means to try -f gdigrab -framerate 60 ...? should I expect to see 100% of the frames, and if not- what is to be expected? [23:48:50 CET] <c_14> Assuming your capture device can actually capture at that framerate, I think so yes. [23:49:02 CET] <c_14> And you can encode all the frames realtime [23:49:04 CET] <kepstin> dorp_: with gdigrab, it's probably too slow to capture the framerate you're requesting, depending on the windows version you're using. You should also check the video encoder - you need to use something fast enough [23:50:59 CET] <kepstin> dorp_: when you run the ffmpeg command, the status line should say the fps that it's actually encoding at. [23:51:23 CET] <dorp_> kepstin: I don't have any drops, my test resolution is only 100x100, and I use Windows 10 with gdigrab, basically: ffmpeg -f gdigrab -framerate 25 -video_size 100x100 -i desktop (with x264 -qp 0 ultrafast), my test machine is offline, I'm not sure how much the whole console output would be helpful [23:53:08 CET] <kepstin> well, next time you run it, check the status line to see the real fps that the encode is running at [23:53:20 CET] <kepstin> and check the cpu and disk usage to try to figure out the bottleneck [23:54:02 CET] <kepstin> if neither cpu or disk is overloaded and it's not managing 25fps, it might just be limitations of the api the capture driver is using. [23:55:35 CET] <dorp_> kepstin: fps= shows 60-61, no disk/cpu bottleneck, ~6% cpu for ffmpeg ... the resolution is trivial: 100x100 [23:56:01 CET] <dorp_> drop=0, but there are a lot of dups [23:56:22 CET] <kepstin> you shouldn't be getting dup frames unless you did something wrong in the command line [23:56:29 CET] <kepstin> please pastebin your complete command line [23:57:36 CET] <dorp_> kepstin: I've copied it by hand: http://codepad.org/wepSt13e [23:58:35 CET] <kepstin> ok, that's really weird. you shouldn't be getting any 'dup' frames with that command line as far as I understand the ffmpeg sync code. [23:58:49 CET] <dorp_> If I use a lower -framerate, then I wouldn't be having lots of dups, and maybe none at all [00:00:00 CET] --- Tue Jan 26 2016

1 0

ffmpeg-devel.log.20160124
by burek 25 Jan '16

25 Jan '16

[00:00:20 CET] <nevcairiel> i'm not only talking about the msvc thing, but the original patch that broke it as well [00:00:30 CET] <nevcairiel> just get rid of it, let him rework in peace, or maybe just forget [00:02:07 CET] <nevcairiel> i should stop caring and just maintain my own fork, revert all the shit from andreas [00:02:24 CET] <BBB> thats barely any better [00:02:39 CET] <BBB> but broken/controversial stuff is pushed too fast nowadays, not just by him [00:02:50 CET] <BBB> In The Old Days, Everything Was Better [00:05:22 CET] <wm4> BBB: by who else, ganesh? [00:05:32 CET] <wm4> I say take push rights from those two [00:06:12 CET] <BtbN> Time to move to Github and do PR-Only. With automatic sanity checks and forced reviews before anything can be merged. [00:06:36 CET] <BBB> yeah, I asked ganesh to revert a patch that he committed with me as reviewer/approver, except I never reviewed it, and I certainly did not approve of it [00:06:39 CET] <BBB> he refused [00:08:44 CET] <nevcairiel> everyone that sends 3 patches gets push access these days [00:11:40 CET] <jamrial> BBB: you should have told ganesh that his "nack" meant jackshit since the patch was never approved and he even went and said you reviewed it [00:11:43 CET] <jamrial> followed by a revert [00:14:22 CET] <iive> ganesh again? [00:14:31 CET] <jamrial> no, this was a week or so ago [00:15:08 CET] <durandal_1707> even if patch improves code? [00:15:53 CET] <BtbN> If someone pushes something and claims that I approved/reviewed it in the commit, and I clearly didn't, I'd just push a revert, no matter what the patch is. [00:16:58 CET] <jamrial> basic netiquette, which ganesh seems to lack [00:17:12 CET] <BBB> jamrial: I hate to get into bitchfights, I guess... [00:18:13 CET] <nevcairiel> BBB: its annoying if you try to be nice and follow the rules, while the others dont, isnt it [00:19:15 CET] <BBB> annoying, or maybe just frustrating [00:19:26 CET] <jamrial> if he does anything like that again he should have his push access revoked [00:20:05 CET] <iive> i'm starting to think that you all are talking about 2 or 3 different things here... [00:21:11 CET] <jamrial> iive: no, this is about ganesh. the earlier stuff was about andreas [00:23:57 CET] <iive> jamrial: so.. ganesh have pushed a patch, without waiting for review, approved by himself and this patch breaks stuff? [00:24:31 CET] <iive> or worse, he says it is approved by somebody who haven't approved it for real. [00:25:24 CET] <BBB> that, yes [00:28:56 CET] <durandal_1707> the push acess should be given for contributing big stuff [00:30:29 CET] <jamrial> iive: he pushed a patch that never made it to the ml in the first place [00:30:35 CET] <jamrial> he sent something, was told it was ok if he made a simple change before pushing, then he instead did a full rewrite and pushed something completely different saying it was reviewed [00:30:48 CET] <durandal_1707> Not oneliners [00:30:53 CET] <jamrial> then, when the person that "reviewed" it asked for it to be reverted, he said "no" [00:31:46 CET] <iive> oh.. what a mess. [00:37:52 CET] <iive> what patch is that? [00:44:22 CET] <jamrial> isfinite fallback [03:17:33 CET] <nevcairiel> plot twist: the msvc "fix" patch doesn't actually work, my fate boxes are still broken [07:14:54 CET] <andrewrk> nevcairiel, please give a spoiler alert before saying something like that [07:15:00 CET] <andrewrk> some of us having seen that movie yet [12:34:01 CET] <durandal_1707> filter_design still mentions obsolete stuff [13:01:39 CET] <BtbN> This msvc patch discussion is getting stupid... [13:03:35 CET] <wm4> it's just because andreas is being stubborn and impatient [13:04:03 CET] <BtbN> "You're very quick to suggest a revert here" Dude, you pushed it after _5 minutes_ [13:05:37 CET] <nevcairiel> Feel free to tell him on the ML [13:13:48 CET] <Daemon404> so uh [13:13:57 CET] <Daemon404> isnt this *why* one restricts push access [13:14:06 CET] <Daemon404> to stop this sorts of stupid things [13:14:13 CET] <Daemon404> revert wars / hack pushes [13:15:16 CET] <nevcairiel> Don't tell us, tell whoever gives push access out these days [13:15:33 CET] <wm4> nevcairiel: michaelni does [13:20:03 CET] <durandal_1707> clearly that power should be given to comitte [13:24:13 CET] <Daemon404> " [13:24:15 CET] <Daemon404> Thus I object to reverting this before the regression caused by 31741ae is fixed." [13:24:18 CET] Action: Daemon404 sighs [13:25:24 CET] <wm4> that's a load of bullshit [13:25:46 CET] <Daemon404> of course it is [13:25:54 CET] <Daemon404> it's like policing a high school [13:25:58 CET] <nevcairiel> that guy should be thrown out of the project for such BS [13:26:20 CET] <nevcairiel> breaking git master and objecting to fixing it until his pet peeve is fixed? [13:26:21 CET] <nevcairiel> seriously? [13:27:16 CET] <Daemon404> [21:53] <@Daemon404> you must be new to debianland [13:28:39 CET] <JEEB> lol [13:34:39 CET] <nevcairiel> also, everyone feel free to call him out on his BS on the ML, otherwise he'll come back with arguments like how noone objects [13:34:58 CET] <wm4> and now for something completely different [13:35:05 CET] <wm4> can we even have vaapi in libavutil? [13:35:09 CET] <wm4> or will we regret this later [13:35:14 CET] <nevcairiel> probably regret [13:35:21 CET] <nevcairiel> why cant avfilter devepn on avcodec anyway [13:35:25 CET] <nevcairiel> it does for some other filters already [13:36:03 CET] <Daemon404> nevcairiel, i just dont have the energy to argue with people on the ML today [13:36:22 CET] <Daemon404> especially the sort who have boundless energy to defend their positiosn to the death [13:37:30 CET] <wm4> Daemon404: maybe time to use the power of voting? [13:37:40 CET] <nevcairiel> so we have a fix in a month? [13:37:50 CET] <wm4> lol [13:40:47 CET] <jkqxz> The only reason that vaapi code is against avutil was because of the dependency. Other than the hardware context setup, I don't really think it should be a public API at all. [13:42:07 CET] <atomnuker> so why are the videolan guys so persistent about hwaccel + frame threading? don't they know it breaks stuff [13:42:23 CET] <wm4> atomnuker: courmisch is, AFAIK [13:42:47 CET] <nevcairiel> he is just insistent that he knows his solution cant possibly be faulty [13:42:48 CET] <wm4> and whether it breaks stuff or not seems to be a complex question [13:42:50 CET] <nevcairiel> thats just how he is [13:43:31 CET] <Daemon404> reply sent [13:44:30 CET] <Daemon404> atomnuker, it works for them because they have extensive locking, apparently? [13:44:34 CET] <Daemon404> i dont know enough to take either side [13:44:47 CET] <nevcairiel> for their d3d11 hwaccels its even worse [13:44:59 CET] <nevcairiel> they added a mutex into the avcodec code for this locking purposes [13:45:00 CET] <Daemon404> but i think it's BS for andreas to demand a revert here instead of pursing both projects [13:45:48 CET] <wm4> maybe arguing with us is easier [13:45:59 CET] <wm4> path of least resistance [13:46:36 CET] <Daemon404> i said as much [13:46:37 CET] <durandal_1707> just revert it, if he revert that fork of [13:46:46 CET] <Daemon404> revert wars get people nowhere [13:47:15 CET] <Daemon404> might be eaisest to round everybody involved up with a shotgun for cleansing^Wdiscussions [13:47:53 CET] <durandal_1707> michaelni: why are you giving commit rights to random people [13:48:30 CET] Action: Daemon404 already regrets involvement today, should have played games and hada pint instead [13:48:36 CET] <mateo`> if master is broken and a fix is not likely to be expected soon enough, just revert until a proper patch is sent (that's my opinion). [13:48:47 CET] <Daemon404> thats everyone's opinion (except his) [13:49:08 CET] <mateo`> and that's not some kind of war, just a generic rule that should apply to everyone [13:49:26 CET] <nevcairiel> his opinion is to leverage it to get his other controversial topics done [13:49:37 CET] <nevcairiel> which is just childish BS and doesnt belong into our project [13:49:56 CET] <nevcairiel> if they work like that in debian, fine, but if this becomes standard here I rather move on [13:50:34 CET] <Daemon404> actually... [13:50:41 CET] Action: Daemon404 lunch pint & [13:50:44 CET] <durandal_1707> well if michaelni disappears who to contact for commit rights policy? [13:51:12 CET] <nevcairiel> some others have root access, i forget [13:51:32 CET] <durandal_1707> Compn? [13:51:49 CET] <durandal_1707> j-b? [13:52:17 CET] <wm4> durandal_1707: andreas is not just random, it's reasonable to have given him commit access at this point IMO [13:52:35 CET] <wm4> but with behavior like this, we should think about removing it again [13:52:36 CET] <nevcairiel> its also reasonable to expect him to behave mature [13:53:16 CET] <durandal_1707> no, rule should be write at least one decoder from scratch [13:53:32 CET] <Daemon404> wm4, vlc, in the past, have locked all parties invokved out of direct pushes for some amount of time [13:53:33 CET] <nevcairiel> can I invent my own format first? [13:53:48 CET] <nevcairiel> and then write a decoder for it? [13:54:00 CET] <Daemon404> nevcairiel, you forgot to 'standardize' it at SMPTE [13:54:04 CET] <JEEB> lol [13:54:06 CET] <nevcairiel> thats a given [13:54:18 CET] <j-b> durandal_1707: we have commit rights control. [13:54:20 CET] <durandal_1707> if anime people use it [13:54:35 CET] <j-b> durandal_1707: but we're moving to code.videolan.org (aka gitlab) to make all those issues easier to deal with. [13:55:19 CET] <durandal_1707> gitlab? So serious? [13:55:28 CET] <j-b> durandal_1707: yes. Why? [13:56:57 CET] <durandal_1707> its company [13:57:59 CET] <j-b> durandal_1707: it's open source. fully. [13:58:09 CET] <wm4> (unlike github) [13:58:22 CET] <Daemon404> i dont think you would want to see github's source code [13:58:43 CET] <JEEB> it's unicorn blargs [13:59:59 CET] <j-b> Daemon404: I would, tbh. [14:00:07 CET] <j-b> btw, hi from London :) [14:00:16 CET] <Daemon404> oh hi [14:00:29 CET] <Daemon404> some meeting? [14:00:49 CET] <j-b> some transits :) [14:00:55 CET] <Daemon404> ah right [14:00:58 CET] <j-b> leaving again for the land of freedom [14:01:03 CET] <Daemon404> i saw this on social media this morning [14:01:09 CET] <Daemon404> headed to land of weed [14:01:58 CET] <Daemon404> as for github: their codebase is supposedly terrifying and unchangeable, baed on my feature requests with tehe github enterprise team (and testimaony from githubbers) [14:33:38 CET] <cone-336> ffmpeg 03Paul B Mahol 07master:547d41207804: avfilter: update some comments [14:41:21 CET] <cone-336> ffmpeg 03Clément BSsch 07master:17d41220d81d: lavfi/pthread: fix perameters/parameters typo [14:47:16 CET] <Compn> durandal_1707 : i dont have git admin rights. that falls to the git admins. [14:47:58 CET] <Compn> which i dont know exactly who is git admin, but i think vlc git admins are the same [14:51:07 CET] <durandal_1707> michaelni: do you know anything on how avoid oom scenario with fps filter and vfr content? [14:56:16 CET] <BtbN> wm4, isn't that cache the whole idea of that copy function? It's supposed to fit into the CPU cache, which makes the entire copy process faster. [14:56:42 CET] <BtbN> I'll try to turn it into yasm, and do some benchmarks [14:57:12 CET] <wm4> BtbN: nevcairiel did experiments on it and found the cache isn't needed, or something [14:58:04 CET] <nevcairiel> the whole point of the copy function is using the special copy instruction [15:00:44 CET] <BtbN> That function also looks like it expects the source and destination to be 64 bit aligned [15:00:56 CET] <BtbN> 64 byte [15:10:35 CET] <nevcairiel> its designed for gpu copying, where this is usually a given [15:18:08 CET] <ubitux> wm4: so a readorder that keeps incrementing even after flushing is really what you need? [15:18:33 CET] <ubitux> that is same event at the same time could show up later with a different readorder [15:19:06 CET] <ubitux> (which is also the case with a reset to zero now that i think about it) [15:19:17 CET] <wm4> ubitux: yeah, basically I want to disable ReadOrder's functionality (I'm preventing duplicates manually by checking the packet's pos field) [15:19:30 CET] <ubitux> alright, i'll adjust the patchset to allow this then [15:19:33 CET] <ubitux> anything else? [15:19:46 CET] <wm4> I don't think so [15:19:50 CET] <ubitux> ok, thx [15:20:34 CET] <durandal_170> does anybody know when filter's filter_frame will be called [15:21:34 CET] <durandal_170> when another filter calls request_frame? [15:31:44 CET] <durandal_170> looks like nobody knows, so I will do the work [15:36:49 CET] <Daemon404> durandal_170, you probably know lavfi better than almost everyone [15:43:52 CET] <durandal_170> looks like presence of another audio stream triggers filter_frame [15:44:26 CET] <durandal_170> video alone works great [16:30:46 CET] <cone-336> ffmpeg 03Timothy Gu 07master:af54a36fc42d: avdevice: Mark decklink_common.h as unconditional SKIPHEADER [16:30:47 CET] <cone-336> ffmpeg 03Timothy Gu 07master:bd4d19208123: common.mak: Use CCFLAGS for assembly generation as well [16:33:22 CET] <cone-336> ffmpeg 03Timothy Gu 07master:61fb70c3866b: decklink: Header cleanup [16:47:49 CET] <kierank> going to push this libquvi thing soon [16:47:56 CET] <nevcairiel> noone complained? [16:49:39 CET] <kierank> nope [16:49:45 CET] <RiCON> everyone's using ytdl [16:51:50 CET] <Daemon404> ^ [16:52:21 CET] <nevcairiel> usually there is at least one crazy person that complains about removals [16:53:13 CET] <cone-336> ffmpeg 03Michael Niedermayer 07master:3130556c0eb0: avformat: Document urls a bit [16:53:14 CET] <cone-336> ffmpeg 03Michael Niedermayer 07master:a7305c780b54: Print the whitelists if entities are not found on them [17:02:38 CET] <kierank> hmm why can't I push [17:02:51 CET] <kierank> I always forget which url I am meant to use for pushing [17:03:02 CET] <nevcairiel> the ssh url [17:09:16 CET] <cone-336> ffmpeg 03Kieran Kunhya 07master:2d40a09b6e73: avformat: Remove support for libquvi [17:10:47 CET] <kierank> ok what other crap needs to go? [17:11:59 CET] <kierank> atomnuker: can I get rid of libvo-aacenc [17:20:12 CET] <wm4> redundant prores encoders maybe? [17:20:18 CET] <atomnuker> kierank: not sure, I've checked out its popularity in debian and arch [17:20:19 CET] <atomnuker> https://qa.debian.org/popcon.php?package=vo-aacenc [17:20:20 CET] <wm4> also, old vdpau hwaccel [17:20:36 CET] <durandal_1707> Carl will complain, so just send mail for voting [17:20:37 CET] <wm4> atomnuker: isn't it just installed as part of the ffmpeg build [17:20:46 CET] <philipl> wm4: did I not push that change? [17:20:53 CET] <kierank> atomnuker: I mean is our encoder better and a superset of libvo-aacenc now? [17:20:58 CET] <atomnuker> wm4: no, debian's ffmpeg isn't compiled with neither fdk_aac or libvo-aac [17:21:05 CET] <wm4> philipl: when? [17:21:11 CET] <atomnuker> kierank: yes, it is [17:21:25 CET] <kierank> then there is no reason for libvo-aacenc to exist [17:21:34 CET] <wm4> kierank: +1 [17:21:36 CET] <atomnuker> yeah, for ffmpeg there is none [17:21:46 CET] <philipl> wm4: clearly not [17:21:52 CET] <atomnuker> but still kinda curious what pulls libvo-aacenc in debian [17:22:00 CET] <JEEB> kitchen sink [17:22:02 CET] <wm4> philipl: I mean, my ffmpeg checkout is a week old already [17:22:05 CET] <kierank> wm4: anything non-contentious? [17:22:10 CET] <atomnuker> kierank: anyway, +1 for removing libvo-aacenc [17:22:17 CET] <philipl> wm4: no I didn't. I did it for mplayer :-P [17:22:30 CET] <wm4> philipl: so mplayer can't use the old hwaccel anymore? [17:22:36 CET] <philipl> wm4: right. [17:22:39 CET] <wm4> lol. [17:22:42 CET] <JEEB> at this point as far as I can see vo-aacenc has no place in FFmpeg [17:22:53 CET] <wm4> so there's literally no reason to keep the old vdpau hwaccel [17:23:02 CET] <philipl> wm4: carl admitted to me that I'd removed his biggest argument in favour of keeping it [17:23:33 CET] <JEEB> it was useful for a very brief moment of time when faac "became" nonfree and fdk-aac still wasn't there. although it still wasn't much better than lavc's own encoder [17:23:41 CET] <JEEB> + it only supported stereo [17:27:24 CET] <RiCON> also, aacplus [17:27:42 CET] <RiCON> any reason to use it instead of fdk? [17:33:48 CET] <kierank> wm4: ok, what else need scrapping? [17:34:46 CET] <wm4> I don't keep a list... asf comes to mind, but that one is very controversial [17:35:13 CET] <wm4> do we really need libschroedinger support? [17:36:06 CET] <kierank> libxavs is crap [17:37:32 CET] <durandal_1707> yes, remove [17:38:36 CET] <kierank> hmm why did the ffmpeg github not update [17:39:16 CET] <kierank> libnut... [17:42:30 CET] <wm4> is libopenjpeg still controversial? [17:42:35 CET] <kierank> if I need to decode alpha channel, how do I make sure it looks ok? [17:43:02 CET] <atomnuker> kierank: we still have 2 prores decoders and 2 prores encoders (didn't we have 3 encoders?) [17:43:21 CET] <kierank> lol yeah [17:43:42 CET] <wm4> hm, crystalhd support [17:43:58 CET] <wm4> didn't someone here implement that originally, maybe BtbN? [17:44:07 CET] <BtbN> hm? [17:44:12 CET] <wm4> atomnuker: DEVIL. prores Apple ProRes (iCodec Pro) (decoders: prores prores_lgpl ) (encoders: prores prores_aw prores_ks ) [17:44:30 CET] <wm4> BtbN: crystalhd [17:44:35 CET] <BtbN> Never heard of that [17:44:50 CET] <wm4> oh right, it was philipl [17:44:52 CET] <durandal_1707> Just remove [17:44:52 CET] <wm4> sorry [17:45:41 CET] <wm4> libgsm? [17:46:17 CET] <cone-336> ffmpeg 03Ronald S. Bultje 07master:9cf81e573c70: lavfi: recognize GBR9-14P as RGB in ff_fill_rgba_map(). [17:52:14 CET] <atomnuker> wm4: the prores_aw and prores encoders both use the same file with the same init/encode_frame/close functions [17:52:50 CET] <wm4> atomnuker: oh [17:53:07 CET] <cone-336> ffmpeg 03Paul B Mahol 07master:3b9f41a9c681: avfilter/vf_zoompan: rewrite so it doesn't cache all output frames [17:53:37 CET] <atomnuker> wm4: can't find anything that would change the output, so I think it's just a duplicated (for compatibility?) entry [18:08:17 CET] <durandal_1707> encoders have different features [18:08:57 CET] <durandal_1707> decoders should do same, thus one should be removed [18:11:06 CET] <durandal_1707> libgsm decoders should probably be removed [18:11:49 CET] <nevcairiel> its funny how the one prores decoder is called prores_lgpl, but the other one is also lgpl [18:11:50 CET] <nevcairiel> i r confused [18:18:04 CET] <BBB> the origin is different [18:18:12 CET] <BBB> the lgpl one was always lgpl, the other one was originally gpl [18:19:14 CET] <BBB> it was written by bcoudurier together with maxim, the lgpl one was written by maxim himself alone [18:19:19 CET] <BBB> or something like that [18:19:54 CET] <BBB> then something something and before you know it you have two decoders, of which one is gpl so youtube cant steal it [18:19:59 CET] <nevcairiel> someone should figure out which is better and just drop the other [18:20:04 CET] <BBB> and then the lgpl one gets optimized so its better [18:20:13 CET] <BBB> and then he relicenses so people dont kick his decoder out [18:20:21 CET] <BBB> again something something [18:20:48 CET] <nevcairiel> currently the default seems to be the one not called lgpl [18:20:54 CET] <nevcairiel> so just drop the other one [18:21:01 CET] <BBB> I believe I wrote simd for the maxim (lgpl) one [18:21:10 CET] <BBB> first make sure its not slower [18:23:54 CET] <BtbN> nevcairiel, do you happen to still have that non-buffer copy function somewhere? It might be nice to have it in avutil, since that vaapi stuff that's about to land could make good use of it. [18:24:48 CET] <nevcairiel> BtbN: the existing vdpau and dxva2 stuff could also use it, but we consider those things more of developer tools than user features =p [18:25:25 CET] <BtbN> There's no harm in making it public api though, who knows who finds it usefull [18:25:26 CET] <wm4> well there are people who are interested in full hw transcoding pipelines, like rcombs [18:25:37 CET] Action: Daemon404 is still not exactly sold on 650+ lines of vaapicrap in avutil [18:26:01 CET] <wm4> so why can't we have a libavvaapiutil [18:28:32 CET] <nevcairiel> i only have it in intrinsics, so someone would have to properly yasm it, but the basics are pretty simple: read 64-byte (ie. one cache line) using 4x movntdqa, write them out using 4x movntdq (no a), the 4x unroll is important due to the way movntdqa's internal cache works [18:29:03 CET] <nevcairiel> (note: sse4) [18:30:46 CET] <nevcairiel> either enforce a 64-byte stride on the buffers in the documentation, or add trailing code to copy more fine-grained remainders [18:31:02 CET] <jamrial> saste started a patch for this some time ago [18:31:09 CET] <jamrial> but the problem was in the glue [18:31:09 CET] <nevcairiel> his approach was way too generic [18:31:18 CET] <nevcairiel> dealing with unaligned memory and whatnot [18:31:26 CET] <nevcairiel> just make it a strict definition of what it expects as input [18:31:39 CET] <jkqxz> The vaapi filter thing isn't exactly vital. It helps improve performance when you're using it with ffmpeg, but everything it does can be done in software instead there. Other things using libav* would hopefully know what they're doing enough that they could implement whatever fragments of it they needed themselves. If dropped, the bits currently in libavutil could go in libavcodec instead. [18:32:01 CET] <nevcairiel> I still think that avfilter filter should just depend on avcodec [18:32:04 CET] <nevcairiel> other filters do [18:32:06 CET] <nevcairiel> so why not this one [18:32:27 CET] <jkqxz> That's allowed? [18:32:34 CET] <BtbN> i wonder how to do it the other way around, there seems to be no store-equivalent for movntdqa [18:32:36 CET] <nevcairiel> optionally, yes [18:32:50 CET] <wm4> jkqxz: essentially anything is allowed as long as there are no cycles [18:32:57 CET] <nevcairiel> BtbN: dont think there is a upload instruction, just use normal moves [18:33:13 CET] <BtbN> so basicaly, a normal memcpy would be fine for that direction? [18:33:27 CET] <nevcairiel> if said memcpy is simd'ed [18:33:32 CET] <nevcairiel> which any sane OS probably should do [18:33:50 CET] <jkqxz> Normal memcpy() is indeed pretty much fine for the other direction, in the vaapi case. [18:34:50 CET] <jkqxz> (To the Intel weird memory. There might be other sorts of weird memory which want a different approach.) [18:35:34 CET] <nevcairiel> in any case, yes avfilter can depend on avcodec, many filters already do, see configure 6070-6096 [18:35:46 CET] <nevcairiel> i would probably feel a bit better to have vaapi code in avcodec [18:38:03 CET] <jkqxz> Likewise. I will make that change. [18:40:04 CET] <wm4> anyway this is pretty orthogonal to which API should be public and which not [18:43:16 CET] <jkqxz> I was wanting the hardware context stuff (+ locking) to be public, and everything else not, at least initially. The other parts are mainly avoiding internal duplication - they could be convenient to offer to users, but are not in any way vital to operation. [18:44:23 CET] <wm4> yeah [18:44:24 CET] <cone-336> ffmpeg 03Timothy Gu 07master:fe71fde24685: configure: Maintain alphabetical order of components [18:45:30 CET] <cone-336> ffmpeg 03Timothy Gu 07master:794b015035a5: Changelog: Add entry on libquvi being removed [18:45:30 CET] <jkqxz> But the cross-library dependency is getting in the way of that. [18:48:57 CET] <BtbN> I wonder if another shared library, which is entirely non-public, would make sense [18:49:40 CET] <wm4> libavpriv [18:50:03 CET] <jamrial> pls no [18:50:16 CET] Action: Daemon404 weeps [18:51:11 CET] <Timothy_Gu> RiCON: patch to remove aacplus sent [18:52:06 CET] <Timothy_Gu> also is there any reason to use FAAC nowadays? [18:52:18 CET] <jamrial> or vo-aac [18:52:31 CET] <jamrial> every guide i found says it sucks [18:52:44 CET] <BtbN> With the current state of the native aac encoder, there isn't realy any reason to use anything else [18:53:02 CET] <nevcairiel> testing purposes [18:53:12 CET] <Timothy_Gu> kierank: I'm running a cron job that updates the GitHub mirror every hour [18:53:35 CET] <jamrial> fdk should be enough for both external decoder and encoder [18:53:56 CET] <Daemon404> yes id rather keep both [18:54:07 CET] <Daemon404> fyi we use fdk for weird aac streams the internal decoder cant handle [18:54:19 CET] <Daemon404> (both = fdk enc/dec) [18:54:35 CET] <Timothy_Gu> let's remove faac after aacplus then :) [18:54:48 CET] <nevcairiel> which would that be Daemon404 [18:54:55 CET] <Daemon404> i need to double check [18:55:04 CET] <jamrial> the only thing i couldn't play with ffaac was some latm in ts stream, which fdk handled right [19:02:50 CET] <kierank> Timothy_Gu: ah right thought it was automatic [19:03:12 CET] <kierank> Oooh can we get rid of faac too? [19:03:22 CET] <wm4> it's strange how github has no way to auto-update forks [19:03:26 CET] <wm4> so most forks are outdated [19:03:36 CET] <nevcairiel> yeah i've always wondered that [19:03:40 CET] <wm4> hundreds and thousands of outdated forks [19:05:17 CET] <Timothy_Gu> wm4: https://github.com/FFmpeg/FFmpeg/pull/115 [19:05:58 CET] <Daemon404> lol [19:07:27 CET] <wm4> lol [19:27:01 CET] <kierank> any less ugly way to do [19:27:03 CET] <kierank> output[(2*i+0)*out_stride] = clip ? av_clip_uintp2(output[(2*i+0)*out_stride], clip) : output[(2*i+0)*out_stride]; [19:27:34 CET] <kierank> ? [19:27:55 CET] <kierank> I don't want to macro this [19:28:11 CET] <BtbN> Just a normal if, that does nothing if !clip? [19:28:42 CET] <kierank> oh yeah lo [19:28:43 CET] <kierank> l [19:52:23 CET] <wm4> michaelni: somehow your recent hls changes must have broken hls playback in mpv (while it works in ffplay) [19:52:44 CET] <wm4> do I need to do something special? [19:53:56 CET] <wm4> oh, it's probably because I don't give libavformat the filename/URL [19:54:06 CET] <wm4> because libavformat tends to do stupid stuff when I do that [19:55:07 CET] <wm4> michaelni: so does this count as regression Y/N [19:56:55 CET] <nevcairiel> didnt it say that without any filename it would still accept it [20:00:02 CET] <wm4> ah if I pass NULL instead of "" as filename it works, lol [20:00:42 CET] <wm4> but I once changed it from NULL to "" to fix a crash [20:00:58 CET] <wm4> in rtp_probe within libavformat, apparently [20:01:47 CET] <wm4> indeed, it still accesses the filename unconditionally, and will crash if it's NULL [20:01:52 CET] <wm4> bipolar libavformat [20:04:17 CET] <wm4> I don't really think that this new HLS check increases security anyway... [20:09:09 CET] <michaelni> i can revert the filename extension check if people feel its not usefull? otherwise ill fix the "" case [20:10:03 CET] <wm4> well, I'm not sure what other API users who expect HLS to work use [20:10:33 CET] <wm4> what exactly does the extension check prevent? [20:10:44 CET] <nevcairiel> i just pass the filename, since i let avformat open the file directly [20:10:51 CET] <nevcairiel> do you pass the m3u8 using custom io? [20:10:57 CET] <wm4> yes [20:13:42 CET] <durandal_170> Daemon404: Nicolas tells me libavfilter is not designed to return multiple frames from .filter_frame [20:15:34 CET] <Daemon404> i did tell you it was a fundemental problem with lavfi [20:15:38 CET] <Daemon404> (or so i was told) [20:18:04 CET] <michaelni> wm4, the idea was to prevent users from getting the hls demuxer when clicking on files that look like other formats like mkv as hls does remote connections and stuff which is potentially unexpected [20:19:12 CET] <michaelni> durandal_170, returning multiple frames from filter_frame should work but isnt optimal as the frames might pile up and overload available memory [20:19:29 CET] <Daemon404> michaelni, that is the exact problem he was addressing [20:19:54 CET] <durandal_170> michaelni, BBB: so what is buggy in flac encoder? [20:20:06 CET] <BBB> I responded to your email [20:20:10 CET] <BBB> read it [20:20:20 CET] <michaelni> the solution for frame pileup should be to return each frame in response to request_frame [20:20:38 CET] <durandal_170> I have, but dunno what to fix [20:21:30 CET] <durandal_170> *flac [20:21:50 CET] <BBB> make the return value of encode_frame (count_*) and count_header byte-aligned [20:21:53 CET] <BBB> I bet you that will fix it [20:22:05 CET] <BBB> otherwise, more generally, figure out which part of count_* and write_* differs in size [20:22:14 CET] <BBB> I think its the byte-alignment missing in count [20:22:18 CET] <BBB> but it may be something else [20:22:24 CET] <BBB> goodluck, Im watching toy story with my kids [20:31:07 CET] <cone-336> ffmpeg 03Paul B Mahol 07master:8a343443796a: avfilter/vf_zoompan: unbreak filtering with video input [20:31:08 CET] <cone-336> ffmpeg 03Paul B Mahol 07master:f42eae96b22d: avfilter/vf_zoompan: fix pts handling [20:41:57 CET] <BtbN> michaelni, so a potential filter that potentialy produces multiple output frames per input frame is a problem? [20:43:08 CET] <nevcairiel> wonder how long I have to come up with cases where andreas patch doesnt work before we can revert it [20:48:11 CET] <nevcairiel> BtbN: deint filters like yadif and w3fdif do that, so its probabvly a different thing they are talking about [20:49:25 CET] <BtbN> I don't get why it's not reverted yet. What's there to argue about? Current master is broken, no fix available. The only benefit of it beeing broken is questionable bit-perfect out-of-tree builds, which won't hurt anyone of they get in a bit later. [20:49:47 CET] <durandal_170> filter that return huge number of frames [20:49:48 CET] <BtbN> If he finaly fixes it, there is no problem pushing it again, after propper review. [20:50:57 CET] <Gramner> indeed, the proper way to handle accidental breakage like this with no simple/obvious fix should be to revert it and resubmit once you're confident that it's fixed [20:51:57 CET] <michaelni> BtbN, IIUC/IIRC anderas patch also fixed out of tree builds with gdb (that is it didnt find the source files) that is if i dont misremember [20:54:57 CET] <nevcairiel> i never heard of such a problem before, so either noone does out of tree builds, or its something how debian builds their things [20:58:34 CET] <nevcairiel> in any case, please express the opinion that we should just revert and try again without a broken live tree on the ML, if I do that again it won't do any good anyway [21:13:09 CET] <BBB> what is currently still broken? [21:13:21 CET] <nevcairiel> now andreas answer is to simply not allow this use-case [21:13:29 CET] <nevcairiel> i'm done arguing with such arguments [21:20:33 CET] <iive> what is out of tree builds? ones where the .o .a .so files are created in other directory than the source? [21:21:52 CET] <nevcairiel> Yes [21:30:22 CET] <Daemon404> i think thats about 6 people who said revert now [21:30:28 CET] <Daemon404> this is somewhat ridiculous. [21:32:13 CET] <atomnuker> durandal_170: in the latest patch you sent, that *2 is to account for the custom sample rate at the end of the frame header, right? [21:32:37 CET] <atomnuker> but the spec says that can be either 8 or 16 bits, so shouldn't that be conditional [21:32:47 CET] <durandal_170> yes, it takes 16 bits [21:33:13 CET] <durandal_170> the other is 0 [21:34:12 CET] <atomnuker> ah, yeah, I see [21:43:21 CET] <cone-336> ffmpeg 03Timothy Gu 07master:ce36cb08ed46: Revert "decklink: Header cleanup" [21:56:12 CET] <cone-336> ffmpeg 03Paul B Mahol 07master:3e7d6849120d: avcodec/flacenc: fix calculation of bits required in case of custom sample rate [22:00:43 CET] <atomnuker> I remember asking how good our FLAC encoder is compared to libflac [22:01:05 CET] <nevcairiel> Didn't you also say that it's better [22:01:19 CET] <atomnuker> yes, just did comparisons, at the highest compression level we beat it by 20 bytes (for a 35 megabyte file) [22:01:37 CET] <atomnuker> but we take 12 seconds on my machine and libflac takes 3.89 seconds :/ [22:01:49 CET] <nevcairiel> Heh [22:02:04 CET] <jamrial> worth 20 bytes! [22:02:26 CET] <nevcairiel> Libflac got a bunch of simd over recent versiona [22:02:30 CET] <nevcairiel> versions [22:02:34 CET] <atomnuker> you can also enable multi_dim_quant which apparently does something crazy and should compress it with alien technology [22:02:43 CET] <nevcairiel> Hehe [22:02:59 CET] <atomnuker> but that would literaly take longer than a day to compress the same file [22:06:14 CET] <nevcairiel> Really this slow? [22:07:01 CET] <Daemon404> i was never able to make flac beat wavpack in compression, even with its (no joke) --super-secret-totally-impractical-compression-level [22:07:34 CET] <atomnuker> you and your wavpack [22:07:57 CET] <jamrial> i think the best compression i've seen was monkey's audio [22:08:04 CET] <jamrial> but it was also pretty slow [22:08:08 CET] <Daemon404> lossless audio is a crapshoot [22:08:28 CET] <atomnuker> wavpack would be better and more accepted if it didn't have the semi-lossless mode IMO [22:08:45 CET] <jamrial> our flac decoder is mighty fast compared to every other lossless decoder we have [22:08:46 CET] <Daemon404> i agree it should have been removed / not existed [22:08:56 CET] <Daemon404> jamrial, it has to be [22:08:59 CET] <Daemon404> the flac format is terrible [22:09:00 CET] Action: Daemon404 runs [22:09:36 CET] <Daemon404> although thats parsing, i suppos.e [22:11:27 CET] <atomnuker> as in, ogg-in-flac or just plain flac? [22:11:36 CET] <atomnuker> *flac-in-ogg [22:12:48 CET] <Daemon404> i can only speak for plain flac, but i think flac in ogg also needs some nutty parsing [22:17:31 CET] <durandal_170> Libflac uses mt for encoding? [22:19:41 CET] <atomnuker> maybe in the future if I'm bored I'd write a modern lossless audio format, with vector quantization, entropy encoding, something obscure and alien to encode the quantization errors and whatever else impractical-for-embedded-systems technology I could think of [22:20:21 CET] <atomnuker> an FFA1 to FFV1 [22:20:57 CET] <durandal_170> Thats sonic [22:21:11 CET] <atomnuker> that S stands for Simple [22:21:29 CET] <nevcairiel> Potential gains would seem to be small in the grand scheme of things, wouldn't they. Over existing codecs anyway [22:21:38 CET] <atomnuker> and that I stands for 'I make bigger files than the input' [22:22:06 CET] <durandal_170> why is sonic encoder still in codebase? [22:22:13 CET] <atomnuker> nevcairiel: probably, but it'd be fun and you'd know that you're getting the best compression level there is [22:22:58 CET] <durandal_170> somebody please send patch to remove Sonic [22:23:09 CET] <nevcairiel> Andreas arguments are getting more flimsy by the minute [22:23:25 CET] <atomnuker> durandal_170: what's wrong with sonic? [22:25:18 CET] <durandal_170> crapware, abandonware, pissing code [22:25:38 CET] <durandal_170> nobody touch it [22:25:54 CET] <durandal_170> and its still useless [22:26:35 CET] <durandal_170> does libav have native vorbis encoder? [22:35:57 CET] <rcombs> I should resend my patches to use a system cert bundle by default [22:36:06 CET] <rcombs> and verify TLS by default [22:36:15 CET] <rcombs> now that OS X and Windows have native TLS code [22:37:10 CET] <JEEB> nice [22:37:43 CET] <nevcairiel> I would just turn it off again [22:37:58 CET] <nevcairiel> There is no sufficient feedback mechanism for API users [22:38:09 CET] <nevcairiel> Log messages are not useful [22:38:19 CET] <JEEB> right [22:39:53 CET] <durandal_170> michaelni: sonicls is not bitexact [22:44:13 CET] <durandal_170> probably because of last small frame [22:44:34 CET] <durandal_170> size not stored anywhere [22:49:31 CET] <durandal_170> buy what margin is libflac encoder faster then our? [22:49:40 CET] <durandal_170> *by [22:51:06 CET] <atomnuker> durandal_170: 3.34 times faster [22:52:09 CET] <atomnuker> but they are nearly identical when I reduce the compression level by 2 [22:52:48 CET] <atomnuker> probably something to do with the amount of LPC passes it does [22:53:02 CET] <durandal_170> well, for fast mode out doesn't have mt [22:53:43 CET] <durandal_170> decoder does use multiple threads [23:08:37 CET] <Timothy_Gu> RiCON: you here? [23:10:04 CET] <RiCON> Timothy_Gu: yes [23:59:09 CET] <Timothy_Gu> ubitux: seems like eglibc doesn't have pthread_setname_np either [23:59:30 CET] <nevcairiel> sounds like a configure check will be needed [23:59:45 CET] <Timothy_Gu> should we revert this commit :p [00:00:00 CET] --- Mon Jan 25 2016

1 0

ffmpeg.log.20160124
by burek 25 Jan '16

25 Jan '16

[00:09:59 CET] <Exon> Could someone help me with the command to stream a certain audio output to an icecast server? Thanks! [00:16:22 CET] <Fjorgynn> no [00:16:32 CET] <Fjorgynn> but I am going to bed soon [00:16:32 CET] <Exon> :X [00:17:57 CET] <edman007> Exon, just ask away [00:18:14 CET] <Exon> <Exon> Could someone help me with the command to stream a certain audio output to an icecast server? Thanks! [00:18:32 CET] <Exon> i know the icecast:// parameters [00:19:27 CET] <Exon> But I keep getting "Unable to find a suitable output format" [00:19:40 CET] <Exon> I once had a .bat file where the correct command was but I can't find it anymore [00:19:44 CET] <Exon> and I havent used FFMPEG in ages [00:19:50 CET] <pzich> what format should it be? [00:19:57 CET] <Exon> mp3 is fine [00:27:14 CET] Action: J_Darnley wonders whether Exon has tried -f mp3 [00:28:06 CET] <Exon> Ah the actualy error is Output file #0 does not contain any stream [00:28:18 CET] <Exon> The other arrow fixed itself after I appended .mp3 to the mountpoint [01:26:08 CET] <J_Darnley> Exon: so you still have a problem? [01:26:20 CET] <J_Darnley> if so put the full log on pastebin [01:41:42 CET] <Exon> It's just Output file #0 does not contain any stream J_Darnley [01:50:57 CET] <furq> pastebin the full command [02:25:25 CET] <Logicgate> J_Darnley, I want to keep a video under a certain output size [02:25:31 CET] <Logicgate> Do I absolutely need to do a 2 pass? [02:26:28 CET] <Logicgate> For instance, I want a 720p video to be maximum 4mb in output [02:26:33 CET] <Logicgate> h264 [02:26:41 CET] <J_Darnley> 2 pass would be much better than trying ABR [02:26:44 CET] <Logicgate> The video is a maximum of 6.8 seconds [02:29:07 CET] <Logicgate> this is my current command: ffmpeg -i <input> -c:a aac -ac 2 -t 6.8 -c:v libx264 -movflags +faststart -crf 20 -vf "scale=w=if(gte(dar\,1)\,720\,720*dar):h=if(lte(dar\,1)\,720\,720/dar):flags=lanczos,format=yuv420p,pad=720:720:(720-iw*min(720/iw\,720/ih))/2:(720-ih*min(720/iw\,720/ih))/2:black" <out.mp4> [02:29:21 CET] <furq> i guess you could try with bufsize and maxrate [02:29:32 CET] <furq> and b:v instead of crf obviously [02:29:45 CET] <furq> i'd expect better results with 2-pass though [02:30:03 CET] <J_Darnley> If you only expect to cap a few files out of many you could consider using "slow first pass" and then only doing the second for files which need to be smaller. [02:30:03 CET] <J_Darnley> But that means the first pass takes as long as the second. [02:30:04 CET] <Logicgate> how does one keep the best quality possible doing two pass [02:30:20 CET] <Logicgate> J_Darnley, I'm fine with that [02:30:21 CET] <furq> https://trac.ffmpeg.org/wiki/Encode/H.264#twopass [02:31:01 CET] <J_Darnley> Keeping "best quality" means using all the available bits when doing 2 pass [02:32:39 CET] <Logicgate> okay so what would my command look like for 2 pass with a set size? [02:32:50 CET] <Logicgate> I have to calculate bitrate right [02:32:54 CET] <J_Darnley> Yes [02:33:12 CET] <Logicgate> so does b:v set a max bitrate or its a fixed bitrate [02:33:19 CET] <furq> it's the average bitrate [02:33:43 CET] <J_Darnley> In this case for x264 the average [02:33:44 CET] <Logicgate> So how does one calculate theoretical bitrate [02:34:07 CET] <J_Darnley> simply put: video bitrate = size / length - audio bitrate [02:34:49 CET] <J_Darnley> or: (size - audio size) / length [02:34:55 CET] <Logicgate> 128k for audio per second = 870.4k [02:35:03 CET] <Logicgate> Or those are kilobits [02:35:09 CET] <furq> those are indeed kilobits [02:35:16 CET] <J_Darnley> ffmpeg uses bits for bitrate [02:35:25 CET] <furq> it's 108KB [02:35:43 CET] <furq> actually why did i even work that out [02:36:13 CET] <furq> https://www.google.co.uk/search?q=4%20megabytes%20%2F%206.8%20seconds%20in%… [02:36:30 CET] <furq> so you have 4577kbps for video [02:36:40 CET] <furq> also i love google. it's great [02:37:40 CET] <Logicgate> no kidding [02:37:44 CET] <Logicgate> Okay, so that's my max [02:38:01 CET] <Logicgate> So i need to substract 128kilobits per second for audio [02:38:06 CET] <furq> one of these days i'll have to do a basic unit conversion without internet access and i'll die [02:38:09 CET] <furq> but today is not that day [02:38:21 CET] <furq> Logicgate: i just did that for you [02:38:24 CET] <Logicgate> 3834.6 kilobits [02:38:28 CET] <furq> ...what [02:38:38 CET] <Logicgate> furq, you gave me total kilobits [02:38:44 CET] <furq> 4705 - 128 is not 3834 [02:38:52 CET] <Logicgate> 128kilobits per second no? [02:38:57 CET] <furq> yes [02:39:00 CET] <Logicgate> exactly [02:39:03 CET] <furq> ...no [02:39:12 CET] <Logicgate> so 6.8 * 128 = 870.4kilobits ? [02:39:48 CET] <furq> you do not have to multiply kilobits by anything to get kilobits [02:40:01 CET] <Logicgate> I thought it was kbps (kilobits per second) [02:40:02 CET] <Logicgate> NO?! [02:40:41 CET] <furq> i don't know how to explain this more clearly [02:40:43 CET] <Logicgate> You guys said to substract audio bitrate to get video bitrate, I'm doing it as a total [02:40:45 CET] <Logicgate> both ways works [02:40:53 CET] <J_Darnley> When you said "maximum 4mb" is that four megabytes? [02:40:55 CET] <furq> oh. [02:41:06 CET] <Logicgate> J_Darnley, yes [02:41:09 CET] <furq> 4705 is not the total number of kilobits [02:41:13 CET] <furq> that's the bitrate [02:41:17 CET] <Logicgate> furq, my point exactly [02:41:20 CET] <furq> dfndsds [02:41:29 CET] <Logicgate> SO in order to calculate the video bitrate, I need to substract total audio bitrate [02:41:47 CET] <Logicgate> total bitrate - total audio bitrate = total allowed video bitrate [02:42:12 CET] <Logicgate> total allowed video bitrate / 6.8 = 564.04kbpd [02:42:18 CET] <Logicgate> kbps* [02:42:44 CET] <Logicgate> so my b:v should be 564k, or to be on the safe side 555k [02:43:55 CET] <J_Darnley> no [02:44:07 CET] <Logicgate> Okay, then I'm completely lost. [02:44:18 CET] <furq> 01:36:13 ( furq) https://www.google.co.uk/search?q=4%20megabytes%20%2F%206.8%20seconds%20in%… [02:44:21 CET] <furq> 01:36:30 ( furq) so you have 4577kbps for video [02:44:24 CET] <furq> that is the answer [02:44:57 CET] <furq> notice that the google answer is in kilobits per second, not kilobits [02:45:08 CET] <Logicgate> okay, I get it [02:45:18 CET] <Logicgate> so 4mb * 8192 / 6.8 [02:45:41 CET] <J_Darnley> close enough [02:46:00 CET] <Logicgate> 4818.82 - 128k = 4690 max bitrate [02:46:08 CET] <furq> 8000, not 8192 [02:46:11 CET] <furq> although it pains me to say it [02:46:18 CET] <Logicgate> On the ffmpeg docs it says 8192 [02:46:25 CET] <Logicgate> http://puu.sh/mHfkE/92f114f9c9.png [02:46:30 CET] <furq> i'm pretty sure ffmpeg uses kilobits, not kibibits [02:46:31 CET] <Logicgate> Docs are wrong then [02:46:43 CET] <furq> probably [02:46:55 CET] <J_Darnley> (4*1048576*8)/6.8 [02:47:01 CET] <Logicgate> which preset should I use? [02:47:14 CET] <furq> whichever preset you want [02:47:16 CET] <Logicgate> and can I do the scaling in the second pass? [02:47:21 CET] <J_Darnley> As slow as you can tolerate except for placebo [02:47:38 CET] <J_Darnley> Logicgate: you must provice the encoder with the same video [02:47:50 CET] <Logicgate> I see [02:47:54 CET] <Logicgate> So then I need to do 3 passes [02:48:04 CET] <furq> huh [02:48:07 CET] <J_Darnley> what? [02:48:17 CET] <Logicgate> It just makes for one long command [02:48:20 CET] <Logicgate> is what I'm saying [02:48:31 CET] <Logicgate> if I do 3 passes with the scaling algorithm [02:48:49 CET] <J_Darnley> Why would you do the scale seprately? [02:49:06 CET] <Logicgate> Because I'm stupid, clearly. [02:49:47 CET] <Logicgate> How does it do the two passes, does it store the data of the first pass that goes to /dev/null? [02:49:56 CET] <furq> yeah it writes out a log file which is used by the second pass [02:50:08 CET] <J_Darnley> ffmpeg -i INPUT -vf FILTERS [OUTPUT OPTIONS] -pass 1 OUTPUT ; ffmpeg -i INPUT -vf FILTERS [OUTPUT OPTIONS] -pass 2 OUTPUT [02:50:25 CET] <furq> Logicgate: you might also want to check the additional information section of that wiki page [02:50:40 CET] <furq> specifically the cbr and crf with maximum bitrate sections [02:51:31 CET] <Logicgate> you can do crf with maxrate [02:51:39 CET] <Logicgate> Then what's the point of two pass then [02:51:47 CET] <Logicgate> bufsize is total size? [02:51:49 CET] <furq> 2-pass ought to be higher quality [02:52:01 CET] <furq> "-bufsize is the "rate control buffer" so it will enforce your requested "average" (4000k in this case) across each 1835k worth of video." [02:52:12 CET] <J_Darnley> VBV max rate is not for maximum file size! [02:52:32 CET] <furq> i was just typing that i've never used anything but -crf on its own so idk how effective this is [02:52:54 CET] <J_Darnley> VBV is for streaming or hardware limits like bluray [02:53:11 CET] <Logicgate> These videos are for mobile streaming [02:53:29 CET] <Logicgate> So I need to figured out how much is being buffered basically or does that matter. [02:53:50 CET] <J_Darnley> Then I would expect you to be using them if you are *streaming* [02:54:29 CET] <Logicgate> Jesus, I don't know what to do now [02:54:35 CET] <Logicgate> I think I'm going overkill [02:54:50 CET] <Logicgate> Should I do CRF + Maxrate or 2 pass [02:54:55 CET] <furq> wouldn't -maxrate 4700k -bufsize 4000k give acceptable results [02:55:00 CET] <furq> considering the video is only 4mb [02:56:04 CET] <furq> or am i just being a distraction here [02:56:17 CET] <J_Darnley> I don't know [02:56:35 CET] <J_Darnley> I haven't kept up with the nonsense of streaming [02:56:39 CET] <furq> i guess try crf + maxrate, if it gives crap results then do 2-pass [02:56:51 CET] <Logicgate> Lol J_Darnley [02:56:54 CET] <furq> crf + maxrate will be faster and less complicated but it might not give the desired results [02:57:03 CET] <Logicgate> furq, I like your style [02:57:11 CET] <Logicgate> going to give it a shot [02:57:17 CET] <Logicgate> it's just 720p, not blu-ray 4k [02:59:59 CET] <J_Darnley> I would have expected that last ~8 years to have settled all this but I guess streaming people keep thieir knowledge to themselves. [03:00:42 CET] <furq> actually bufsize is in kbps isn't it [03:00:50 CET] <furq> i think i got it confused with rtbufsize [03:00:54 CET] <J_Darnley> ? [03:00:59 CET] <Logicgate> lol [03:01:00 CET] <J_Darnley> its s aize not a rate [03:01:07 CET] <furq> kbit, rather [03:01:10 CET] <J_Darnley> its a size not a rate [03:01:11 CET] <furq> i thought it was in KB for some reason [03:01:43 CET] <J_Darnley> No I don't think it was bytes [03:01:50 CET] <furq> yeah i checked and it is kbit [03:01:59 CET] <furq> rtbufsize is in bytes i think [03:02:17 CET] <furq> also s/kbit/bits since you need to specify a suffix [03:02:33 CET] <Logicgate> furq, that's what I thought to actually [03:03:22 CET] <furq> i was thinking of -bufsize 32000k in that case [03:03:36 CET] <furq> but that doesn't seem like a thing which is right [03:03:50 CET] <furq> check out that expert technical analysis there [03:07:09 CET] <Logicgate> furq, it worked [03:07:22 CET] <Logicgate> furq, you can't do that though [03:07:30 CET] <Logicgate> Because video buffers are never that big [03:07:38 CET] <Logicgate> They're much smaller chunks (I think) [03:58:13 CET] <Guest49336> greetings - seeking assistance debugging ffmpeg build - ldd indicates libavdevice.o.57 but only *.o.56 in /usr/local/lib [04:03:51 CET] <Guest49336> ./ffmpeg: error while loading shared libraries: libavdevice.so.57: cannot open shared object file: No such file or directory [07:32:35 CET] <Guest49336> too bad nobody was able to help. maybe next time. [07:32:46 CET] <Guest49336> <crickets> [09:54:00 CET] <SeanM_> Hi, can someone here please hellp point me in the right direction why this command doesnt work --> ffmpeg -i INPUTFILE.mpg -i logo.png -filter_complex "[0:v][1:v] overlay=10:10:enable='between(t,4,12)'" -scale=1728:970,crop=1280:720:224:6 -sws_flags lanczos -codec:v libx264 -crf 18 -preset ultrafast -movflags faststart -pix_fmt yuv420p -c:a copy OUTPUTFILE.mp4 (it is supposed to crop and overlay a png file watermark that [09:54:00 CET] <SeanM_> only displays from 4s-12s of the video, yet it doesn't work. i am new to ffmpeg and spent 10+ hours on this. puzzled) [09:56:11 CET] <waressearcher2> SeanM_: hallo und herzlich willkommen [09:59:07 CET] <c_14> SeanM_: that's broken [09:59:12 CET] <c_14> there is no -scale option [09:59:24 CET] <c_14> I'm assuming you wanted that and the crop as part of the filterchain [09:59:36 CET] <c_14> the filterchain is comma separated [09:59:51 CET] <SeanM_> Yes I want to first crop it like that and then apply the watermark over it, but it doesnt seems to work together [09:59:56 CET] <c_14> move the double quote behind the :6, drop the space and replace the '-' with a comma [10:00:14 CET] <c_14> Move the sws_flags as an option to the scale filter (it should work as is, but just in case) [10:00:25 CET] <c_14> Do you want to crop first or overlay first? [10:00:31 CET] <SeanM_> crop first [10:00:36 CET] <c_14> And do you want to crop then scale or scale then crop [10:01:14 CET] <SeanM_> scale and then crop, and then apply the watermark overlay [10:02:14 CET] <c_14> -filter_complex "[0:v]scale=1728:970,crop=1280:720:224:6[iv];[iv][1:v]overlay=10:10:enable='between(t,4,12)'[v]" -map '[v]' [10:02:59 CET] <c_14> Might need to escape the commas in the between(), not sure [10:06:02 CET] <SeanM_> Wow thats very helpful c_14, it nearly worked, it's just that it doesnt seem to have audio now =/ i probably did the command wrong [10:06:46 CET] <SeanM_> ffmpeg -i INPUTFILE.mpg -i logo.png -filter_complex "[0:v]scale=1728:970,crop=1280:720:224:6[iv];[iv][1:v]overlay=10:10:enable='between(t,4,12)'[v]" -map '[v]' -sws_flags lanczos -codec:v libx264 -crf 18 -preset ultrafast -movflags faststart -pix_fmt yuv420p -c:a copy OUTPUTFILE.mp4 [10:06:46 CET] <SeanM_> it plays and has the overlay but no audio, not sure if i did your fix wrong [10:06:57 CET] <c_14> add -map 0:a [10:08:33 CET] <SeanM_> Awesome, that did exactly what i wanted perfectly, thank you so much c_14 [11:26:52 CET] <Farika> Hi [11:31:06 CET] <Farika> Someone has it succeded to use xvba on catalyst for video acceleration? [12:56:10 CET] <Tzimmo> I have a bluray .m2ts file with multiple audio tracks and subtitles. I'd like to get only one video, one audio and one subtitle track and just copy them over, keeping the original container etc is fine. When I try to do [12:56:29 CET] <Tzimmo> ffmpeg -i source.m2ts -vcodec copy -acodec copy -scodec copy output.m2ts [12:56:33 CET] <c_14> Do you care which you want to keep? [12:56:48 CET] <Tzimmo> it breaks the output file so that it can no longer to be played: [12:56:58 CET] <Tzimmo> ffmpeg -i output.m2ts [12:57:07 CET] <Tzimmo> Stream #0:0[0x100]: Data: bin_data ([6][0][0][0] / 0x0006) [12:57:14 CET] <Tzimmo> #0:1[0x101]: Audio: ac3 ([129][0][0][0] / 0x0081) [12:57:22 CET] <Tzimmo> Stream #0:2[0x102]: Data: bin_data ([6][0][0][0] / 0x0006) [12:57:31 CET] <J_Darnley> I would suggest you put the full log on pastebin [12:57:37 CET] <c_14> Can you upload the complete command and full console output for your command -- ^yes [12:57:41 CET] <Tzimmo> I can use -map to select which tracks I want, but the problem is to get any playable output at all in m2ts format. [12:57:55 CET] <Tzimmo> ok, a second [12:58:45 CET] <J_Darnley> c_14makes a good point, the whole command too please [13:04:01 CET] <Tzimmo> http://pastebin.com/694vvSQ3 [13:04:52 CET] <J_Darnley> FYI you could shorten those sizes to 1G [13:05:55 CET] <Tzimmo> My TV has a poor selection of subtitle tracks, it generates just 20 "unnamed" subtitles and it is very laborous to figure out which one of them is the right one for me (finnish) so I try to rip away all the other subtitles so that there is only 1 subtitle available any more to make it usable [13:06:26 CET] <Tzimmo> (sony tv, pick subtitle #15, scroll at the end of the list, right arrow to highlight "OK" and then you're done.) [13:06:37 CET] <c_14> You might need to add the analyzeduration and the probesize to the second command [13:06:47 CET] <Tzimmo> Repeat that 20-30 times as you don't know which is the correct subtitle for this specific file and you're lost. [13:07:00 CET] <Tzimmo> c_14: ah... [13:07:39 CET] <Tzimmo> c_14: still at least about the same output [13:07:54 CET] <Tzimmo> bin_data ... and it cannot be played unlike the original that still plays [13:08:56 CET] <c_14> try putting the analyzeduration and probesize before the -i in the first command [13:09:17 CET] Action: J_Darnley missed that [13:09:17 CET] <Tzimmo> And if I convert it to mkv, the TV no longer is able to show any subtitles at all as pgs is not supported in mkv but only ass :( [13:10:08 CET] <Tzimmo> c_14: ah, ok, even though I think I saw at least some difference in adding them after -i, because otherwise it didn't find any subtitle tracks (of course) [13:11:42 CET] <Tzimmo> Still just bin_data, now I had those analyzeduration and probesize options as the first options with 1G argument in both commands [13:12:50 CET] <J_Darnley> Does ffmpeg stop printing those warnings if you increase those sizes more in first command [13:12:52 CET] <Tzimmo> Another option could be to be able to convert those pgs subtitles to ass (or dvb subtitles) that might work in mkv but I guess at least conversion to ass requires OCR? [13:12:59 CET] <J_Darnley> Yes [13:13:01 CET] <Tzimmo> even more than 1G? like 100G? [13:13:07 CET] <J_Darnley> No [13:13:12 CET] <J_Darnley> like 2 or 4 maybe [13:13:18 CET] <Tzimmo> I'll try. [13:13:50 CET] <J_Darnley> Converting bitmap subs to text subs will require OCR, something ffmpeg cannot do. [13:13:59 CET] <c_14> it can actually [13:14:01 CET] <c_14> just not very well [13:14:21 CET] <J_Darnley> When did that happen? [13:14:27 CET] <c_14> (you have to build with tesseract support, and it afaik it doesn't generate subtitle output) [13:14:34 CET] <Tzimmo> Hmm, true, with 4G I get only some DTS discontinuity warnings... [13:14:36 CET] <c_14> A few months ago iirc [13:14:40 CET] <J_Darnley> ah [13:14:59 CET] <J_Darnley> Anyway, your TV may not support text subtitles [13:15:06 CET] <J_Darnley> You would have to consult the manual. [13:15:09 CET] <Tzimmo> Also I couldn't convert pgs to dvb_subtitle for some reason... or maybe it was a limitation in matroska format that dvb_subtitle is not allowed? [13:15:19 CET] <Tzimmo> dvb_subtitle is also bitmap-based [13:15:31 CET] <c_14> the ocr filter was added in september [13:15:33 CET] <Tzimmo> TV supports srt and ass in mkv [13:15:46 CET] <Tzimmo> and dvb/dvd in SD video (mpeg2ts) [13:16:23 CET] <Tzimmo> and pgs but only in mpeg2ts, not in mkv (yes, I guess you can code like that) :) [13:17:04 CET] <Tzimmo> And also a separate srt/sub/whatever next to the file if it is avi/mkv/mpegps at least. [13:17:21 CET] <Tzimmo> But I'll see what 4G sizes do... a sec [13:18:26 CET] <Tzimmo> ...still bin_data :( [13:18:35 CET] <J_Darnley> :( [13:19:11 CET] <Tzimmo> If I was encoding my own bluray m2ts file, what would be the appropriate format (-f) for it? [13:19:17 CET] <J_Darnley> I wonder whether ffmpeg supports muxing the vc1 and pgs streams correctly [13:19:19 CET] <c_14> If you can cut a small sample of the video using dd, you might want to open a bugreport on trac with that as a sample [13:19:42 CET] <Tzimmo> I can... what is a proper size for "small"? [13:19:55 CET] <c_14> as small as you can make it and still reproduce the problem with it [13:19:57 CET] <Tzimmo> (I of course check that it still reproduces the issue) [13:20:02 CET] <c_14> I think attaching to trac limits to 2mib or so [13:20:02 CET] <Tzimmo> ok [13:20:22 CET] <J_Darnley> There's an ftp server you can put bigger things on [13:20:28 CET] <Tzimmo> The subtitle won't be there in the beginning of the file but this is not just about subtitles, also the video gets broken- [13:20:41 CET] <Tzimmo> Unless I cut in the middle of the file [13:20:49 CET] <c_14> This is m2ts you can just cut anywhere [13:21:14 CET] <J_Darnley> There's a bit of a limit with video though. [13:21:24 CET] <Tzimmo> Yes, but 2 megs of bluray movies doesn't last long enough to catch a video, audio and subtitle, maybe... or maybe if I can find the right spot. [13:21:46 CET] <JEEB> if you are aiming at creating a fully compliant MPEG-TS mux for blu-ray, I don't think the mpegts muxer is applicable for that [13:21:50 CET] <Tzimmo> Yes, I should find a keyframe and a start of the subtitle close to each other. [13:22:02 CET] <c_14> It can be larger than 2mib, you'll just have to upload to the ftp server then [13:22:15 CET] <c_14> JEEB: he's just trying to get the output recognized (ie not bin_data) [13:22:17 CET] <Tzimmo> Ok, I'll check what I can do. Btw, I noticed Im [13:22:25 CET] <J_Darnley> JEEB: at the moment we are just trying to get ffmpeg to see vc1 and pgs in its own output [13:22:30 CET] <Tzimmo> using 2.84 version and there is 2.85 available. Any worth trying 2.85 first? [13:22:30 CET] <JEEB> ah [13:22:46 CET] <J_Darnley> Tzimmo: use the git head [13:22:50 CET] <JEEB> you should in general be using not releases but master unless FATE is red everywhere [13:23:19 CET] <Tzimmo> J_Darnley: ok [13:39:23 CET] <micechal> I'm trying to encode a ogg vorbis file without any metadata at all, but ffmpeg keeps adding the "encoder" field no matter what I try. yesterday, when encoding some PCM WAVs, "-fflags +bitexact -map_metadata -1" was enough [13:39:52 CET] <micechal> but with the OGGs it doesn't seem to work that well [13:41:12 CET] <c_14> try adding -flags +bitexact [13:42:10 CET] <micechal> no difference :( [13:47:03 CET] <c_14> Hmm, that's what my logs tell me should work. Maybe something changed. [13:48:59 CET] <micechal> "-map_metadata -1 -c:a libvorbis -flags +bitexact -fflags +bitexact" this is what I tried [13:49:11 CET] <Chagall> I think encoding is failing because of the subtitle filter - I'm escaping single quote marks to mark the input file (with whitespace in the path), but if I have single quote marks in the input file name (from which I get the subtitles) then it fails. can I wrap the input path around double quotes instead or somehow mark the single quotes inside the input as being part of the filename? [13:49:38 CET] <c_14> you can use double quotes or escape the single quotes with a '\' [13:50:09 CET] <Chagall> "-i D:/Encodes/my file 'name'.mkv -ss 00:00:00.000 -t 00:07:17.400 -c:v:0.0 libvpx -pass 1 -b:v 3917K -quality good -cpu-used 0 -vf subtitles=\\'D\\:/Encodes/my file \\'name\\'.mkv\\':si=0 -an -sn -sws_flags lanczos -f webm D:\\Encodes\\temp\\null" [13:50:38 CET] <Chagall> i'll try double quotes then [13:54:05 CET] <Chagall> doesn't seem to work either [14:03:34 CET] <Tzimmo> J_Darnley: with git head I actually get video stream looking a lot better [14:03:44 CET] <Tzimmo> Stream #0:0[0x100]: Video: vc1 (Advanced) (VC-1 / 0x312D4356), yuv420p(bt709), 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn, 47.95 tbc [14:03:52 CET] <Tzimmo> the subtitle is still bin_data [14:04:05 CET] <Tzimmo> but let's see if this now at least is playable [14:05:21 CET] <Tzimmo> yes, video and audio plays fine, subtitle isn't recognized [14:09:42 CET] <Tzimmo> If I try with -scodec dvb_subtitle to try to convery the subtitles I get [14:09:52 CET] <Tzimmo> Stream #0:13 -> #0:2 (hdmv_pgs_subtitle (pgssub) -> dvb_subtitle (dvbsub)) [14:09:54 CET] <Tzimmo> ... [14:09:59 CET] <Tzimmo> frame= 1855 fps=600 q=-1.0 size= 160661kB time=00:01:17.28 bitrate=17029.5kbitsSubtitle encoding failed [14:10:02 CET] <Tzimmo> Conversion failed! [14:10:26 CET] <Tzimmo> I can provide a full output if you think this should work...? [14:16:13 CET] <c_14> I don't think ffmpeg can convert between video subtitle formats well/at all. [14:16:47 CET] <durandal_1707> it can [14:17:00 CET] <c_14> never seemed to work when I tried [14:17:29 CET] <c_14> Are there restrictions on which codecs it can convert to certain other codecs? [14:17:46 CET] <durandal_1707> probably [14:18:20 CET] <durandal_1707> but its bug and should be reported [14:28:40 CET] <iive> i'm sure it cannot convert from bitmap to text based subtitles [14:29:07 CET] <iive> howeve both pgs and dvb are bitmap subtitles. [14:31:40 CET] <Chagall> i tried a bunch of different things but still not working [14:31:56 CET] <Chagall> just need to support any file name in the sub filter input [14:32:17 CET] <Chagall> single quotes alone don't work because i surround the input file name in single quotes, but can't figure out how to make the alternatives work [14:32:30 CET] <Chagall> or escape the inner single quote properly [14:34:03 CET] <c_14> you probably need either more or less '\' [14:35:17 CET] <Chagall> i tried adding an extra layer but it didn't work either [14:35:56 CET] <Chagall> and i tried removing some and then all of them and that still didn't work [14:36:15 CET] <Tzimmo> Yes I've converted from dvb subtitles to dvd subtitles etc, bitmap-to-bitmap and it has mostly been working at least somewhat. [14:36:21 CET] <Chagall> just need a clear pattern for this [14:36:26 CET] <c_14> have you tried using -filter_script [14:37:14 CET] <hassonofer> How do I retransmit RTSP stream using ffmpeg ? [14:37:41 CET] <Tzimmo> Chagall: At least in the example you gave above, you have the whole command line inside double quotes. You should only put filenames (with spaces and ':s) in double quotes, not the whole command line...? [14:38:13 CET] <Chagall> they're not actually there [14:38:29 CET] <Chagall> the same settings work when i have no subtitles enabled [14:38:41 CET] <Tzimmo> Ok [14:38:50 CET] <Chagall> that's debug output i copy-pasted [15:09:31 CET] <hassonofer> How do I retransmit RTSP stream using ffmpeg ? I'm keep getting "Could not write header for output file #0 (incorrect codec parameters ?): Connection refused" error [15:10:16 CET] <hassonofer> The command I use is: "ffmpeg -i "rtsp://USER:PASS@DOMAIN.dvrlists.com:8554/streaming/channels/601" -f rtsp rtsp://127.0.0.1:8888/live" [16:14:09 CET] <t0by> Hi. Stupid question - I would like to *add* (render) some grain. Is there a way to do so with ffmpeg or do I need to use a GUI editor? [16:15:20 CET] <c_14> The noise filter? [16:21:06 CET] <t0by> c_14, the thing is that I would like to specify an average size for the "grains", if you get what I mean, to make it look actually grainy and not noisy [16:21:20 CET] <t0by> which obviously would be >1px [16:23:39 CET] <Chagall> in filter_complex [0:s:0], first 0 is first input and second is first sub stream in the input? [16:23:56 CET] <Chagall> so if i did 0:s:1 i would get the 2nd subtitle stream? [16:24:02 CET] <c_14> t0by: don't think there's a filter for that [16:24:13 CET] <c_14> Chagall: yes [16:24:26 CET] <t0by> c_14, any sort of magic that can be done to approximate that? [16:24:27 CET] <Chagall> thanks [16:25:11 CET] <c_14> t0by: if you can get a video with alpha of the grain you want you might be able to overlay it [16:26:08 CET] <t0by> c_14, I thought of that approach, but... that would require me to render 2 hours of pure noise at 1080p on my disk [16:26:14 CET] <t0by> which I'm not exactly looking forward to [16:26:27 CET] <c_14> overlay or blend [16:26:43 CET] <c_14> If you don't mind the noise repeating after n minutes, it doesn't have to be full-length [16:27:13 CET] <c_14> And if whatever's rendering the noise can output to stdout (or even just to a named fifo) you can use that as input for ffmpeg so you don't have to save it to disk [16:29:09 CET] <t0by> c_14, is there a simple way of chaining the noise filter with scale and blur to get that instead of an external tool? [16:29:13 CET] <t0by> sorry for the newbie question [16:29:20 CET] <t0by> but I've never had to do complex filter chains like this [16:30:35 CET] <c_14> probably [16:31:40 CET] <t0by> c_14, sorry, so how do I combine the two chains? [16:31:49 CET] <t0by> (this chain I'll make up somehow and my source)? [16:32:17 CET] <Kak> good morning, how can I record my desktop and my voice at the same time with ffmpeg? [16:34:44 CET] <c_14> Kak: https://trac.ffmpeg.org/wiki/Capture/Desktop https://trac.ffmpeg.org/wiki/Capture/ALSA [16:36:36 CET] <c_14> t0by: just testing it out here first [16:36:46 CET] <t0by> c_14, thank you *so* much [16:40:12 CET] <Kak> thank you very much [16:44:53 CET] <Chagall> -filter_complex "[0:v:0][0:s:0]overlay[vid]" fails for me [16:46:52 CET] <Chagall> "Filter overlay has a unconnected output" [16:47:02 CET] <c_14> did you map [vid] ? [16:48:35 CET] <Chagall> oh my bad [16:48:38 CET] <Chagall> was missing [16:49:30 CET] <c_14> t0by: ffmpeg -f lavfi -i color=black@0.8:s=640x360 -i movie -filter_complex '[0:v]noise=alls=40:allf=t,scale=1920x1080,smartblur[iv];[iv][1:v]blend=all_mode=hardlight[v]' -map '[v]' -t 2 out.mkv <- something like this maybe [16:49:35 CET] <c_14> the blend mode isn't great currently [16:49:46 CET] <c_14> And you might want to adjust how much you scale by and the noise settings etc [16:50:17 CET] <c_14> I tired getting overlay to work, but it's either not reading the opacity or one of the other filters is throwing it away [16:50:36 CET] <t0by> c_14, i might be in love with you [16:50:38 CET] <t0by> just one thing [16:50:44 CET] <t0by> where do I put my input file in all that? [16:50:49 CET] <gener1c> he's a guy [16:50:55 CET] <t0by> so what [16:50:57 CET] <c_14> where I wrote movie [16:51:04 CET] <t0by> d'oh [16:51:05 CET] <gener1c> ffmpeg -i input_file [16:51:17 CET] <c_14> t0by: using white instead of black seems to work better [16:51:50 CET] <t0by> thank you so so so so much [16:53:10 CET] <gener1c> i cant find the fifo bug anywhere [16:53:16 CET] <gener1c> is there fifo support already? [16:53:28 CET] <c_14> hmm? fifo for what? [16:53:34 CET] <gener1c> fifo files [16:53:45 CET] <gener1c> for multiple pipes to the same encoding process [16:53:53 CET] <gener1c> in different time periouds [16:54:09 CET] <c_14> should work [16:54:18 CET] <t0by> hum [16:54:22 CET] <t0by> not working? [16:54:34 CET] <gener1c> well i didnt try yet [16:54:36 CET] <c_14> t0by: error or you don't see anything? [16:54:49 CET] <t0by> i get circa 1 second of pure noise [16:54:55 CET] <t0by> let me try again [16:55:08 CET] <c_14> The -t 2 limits the output to 2 seconds (for testing purposes) [16:55:26 CET] <t0by> d'oh [16:55:27 CET] <c_14> you might have to change the blend mode to something better (I just picked one at random) [16:55:36 CET] <t0by> but i mean, I get *pure* white [16:55:41 CET] <t0by> er, noise [16:55:43 CET] <t0by> er, noise-on-white [16:56:03 CET] <c_14> you can also control the strength of the noise in each of the chroma values as well as the seed, and control blending per chroma value as well [16:56:52 CET] <c_14> Aha [16:56:57 CET] <c_14> found what I was looking for [16:57:03 CET] <gener1c> after the first pipe ffmpeg stops [16:57:05 CET] <c_14> The blend filter has an all_opacity option [16:57:11 CET] <c_14> Set that to 0.2 or something [16:57:12 CET] <gener1c> it makes sense because it sees and eof [16:57:16 CET] <gener1c> how to i make it stay up? [16:57:27 CET] <gener1c> an* [16:57:34 CET] <c_14> gener1c: it won't. As soon as it sees EOF it stops [16:57:45 CET] <c_14> t0by: like so blend=all_opacity=0.2 [16:57:46 CET] <gener1c> but its a fifo pipe [16:57:54 CET] <gener1c> i need to >> several files into it [16:57:56 CET] <gener1c> :| [16:58:05 CET] <c_14> Are you trying to concatenate? [16:58:12 CET] <gener1c> i know -concat [16:58:24 CET] <gener1c> i am trying to live encode random blobs [16:58:27 CET] <gener1c> that come as files [16:58:35 CET] <c_14> What format? [16:58:41 CET] <gener1c> humz [16:58:53 CET] <c_14> Because that won't work with most formats (it'll work for mpegts) [16:59:02 CET] <gener1c> mpeg2 i think [16:59:10 CET] <gener1c> file outputs mpeg transport stream [16:59:28 CET] <gener1c> then yeah [17:01:07 CET] <gener1c> so i get transport stream blobs ... how can i make this work without closing on me because of the eof? [17:01:08 CET] <c_14> You might have better luck writing a small program and then just piping from that program via stdout to ffmpeg [17:02:16 CET] <gener1c> how will i go about it? use libav? [17:03:23 CET] <gener1c> or just open ffmpeg with popen? [17:03:29 CET] <c_14> gener1c: just write a small script in your favorite scripting language that reads from the fifo (or whatever) and then pipes that out via stdout to ffmpeg -i foo bar [17:03:43 CET] <c_14> something like that, ye [17:03:57 CET] <t0by> c_14, thank you so much [17:10:45 CET] <gener1c> well that was easy enough [17:11:06 CET] <gener1c> i was scared ffmpeg wont like the chunk sizes or something but it ate it like a pro, it just works [17:11:54 CET] <gener1c> now i need to make this thing stable and pretty [17:27:42 CET] <Chagall> well... overlaying subs kinda worked, only it makes the image look like complete garbage [17:28:21 CET] <Chagall> http://i.imgur.com/SaARwNq.png at 3k kbps [17:29:28 CET] <Chagall> no issue when i disable subs, all i did was -filter_complex [0:v:0][0:s:0]overlay[vid] -map [vid] [17:29:34 CET] <Chagall> not sure if it'S because i did it on the first pass [17:29:39 CET] <Chagall> or some other issue [17:33:36 CET] <c_14> are you encoding 2-pass? [17:33:40 CET] <Chagall> yes [17:33:48 CET] <c_14> only apply filters on the second pass [17:33:52 CET] <Chagall> ok [17:33:54 CET] <c_14> although [17:33:56 CET] <c_14> or was it both [17:34:09 CET] <Chagall> yeah both [17:34:12 CET] <c_14> both should be fine [17:34:18 CET] <Chagall> yeah it works when i use regular filters [17:34:21 CET] <c_14> Is your bitrate 3000k or 3k? [17:34:38 CET] <c_14> because 3k is really low [17:37:10 CET] <Chagall> same thing on 2nd pass only [17:41:02 CET] <Chagall> it works on actual dvd subtitle but not on vobsub it seems [17:43:46 CET] <Chagall> chaining filters like crop=something,scale=something doesn't work in filter_complex? [17:44:07 CET] <c_14> it does [17:46:03 CET] <Chagall> oh, cannot use normal filter and complex filter for the same stream [18:02:22 CET] <Chagall> so yeah now i can handle raw dvd subs, but what can i do about vobsub [18:02:30 CET] <Chagall> it turns it into garbage [18:58:13 CET] <debianuser> Hello. How can I disable ODML when writing .avi file with ffmpeg? I'm encoding a 1.5GB video for a hardware player, and it stops playing after ~1GB. But if I remux the file with `mencoder -noodml ...` the player plays it all fine. [18:59:08 CET] <debianuser> (I currently have that player here, so I can test any options you know) [19:03:34 CET] <c_14> debianuser: I don't think there's an option for that. (I just checked the code and all the calls to the odml writing functions aren't conditional) [19:06:07 CET] <debianuser> c_14: Maybe there's a way to increase the boundary to create ODML index if the file is >1.9GB instead of 1GB? [19:10:42 CET] <c_14> You'd have to recompile, but sure. [19:10:57 CET] <c_14> change AVI_MAX_RIFF_SIZE in libavformat/avi.h [19:18:36 CET] <debianuser> Hm, I think I can do that... but not now. Maybe later, if I get this issue happens again. This time I'll just remux those two files with mencoder -noodml. [19:18:57 CET] <debianuser> c_14: Thanks a lot for your help! [19:19:22 CET] Action: debianuser saves a note to increase AVI_MAX_RIFF_SIZE when building ffmpeg next time... [20:43:26 CET] <dorp> If one uses ffmpeg for screen capturing a playing video, should the exported video match (precisely) the framerate of the playing video, or it might as well exceed it? [20:45:02 CET] <DHE> ffmpeg captures at the framerate you specify, but scheduling may cause it to drift a little bit. you may get duplicate and dropped frames [20:45:13 CET] <DHE> and then there's stuff like videos running at 29.97fps when you record at 30 [20:47:50 CET] <dorp> DHE: So as I take it that there's no special significance to the precise framerate? [20:48:47 CET] <DHE> I haven't tried recording video playback with ffmpeg. usually I just download the video itself and save it. much easier, faster and reliable [20:49:02 CET] <DHE> mostly I've recorded things like games, instructional demonstrations, etc [20:49:15 CET] <DHE> where a little bit of framerate jitter is more tolerable [20:49:45 CET] <dorp> I see, thanks [20:50:51 CET] <DHE> all I can suggest is trying it and see if you're happy with the results [21:01:24 CET] <Chagall> to use fast seeking (-ss before -i) with text subtitles is the only way to extract the subtitle and change the timestamps externally before feeding it back to the filter or is there a better solution? [21:27:58 CET] <Farika> hi [21:28:19 CET] <Farika> xvba works with ffmpeg ? [21:42:48 CET] <Warblefly> Not that I can find on http://www.ffmpeg.org/ffmpeg-all.html. It was talked about three years ago. https://trac.ffmpeg.org/search?q=xvba [21:44:01 CET] <BtbN> xvba still exists? [22:28:55 CET] <Farika> BtbN : yes when you use catalyst :) [22:29:16 CET] <BtbN> The only player which supported that was kodi, and i think they dropped it. [22:29:25 CET] <BtbN> Or does something else still support it? [22:29:42 CET] <Farika> ah :( and i have a bug with opensource driver and i can use only catalyst [22:29:44 CET] <Farika> suckz :( [22:30:47 CET] <Farika> so , no video acceleration with proprietary drivers [22:31:03 CET] <Farika> vainfo: Driver version: AMD MMD 1.0 [22:32:08 CET] <Farika> don't work with vlc [22:32:29 CET] <JEEB> xvba was the worst of all the lunix hw decoding APIs [22:32:46 CET] <JEEB> pretty sure it wasn't even full hw decoding, but rather you had to do parts of the job yourself [22:32:55 CET] <JEEB> which is why pretty much nothing supports it [22:32:56 CET] <Farika> yeah... and catalyst is bad too but no choice [22:32:58 CET] <Farika> https://bugs.freedesktop.org/show_bug.cgi?id=93826 [22:33:10 CET] <Farika> my 290X and my screen don't work with opensource driver [22:33:21 CET] <JEEB> my condolences then [22:33:34 CET] <Farika> tks :p [22:33:35 CET] <JEEB> also I thought AMD did VA-API :P [22:33:41 CET] <JEEB> at least with those newer pieces [22:34:00 CET] <JEEB> xvba was a thing for like early middle 2000s or so [22:34:14 CET] <Farika> hum [22:34:29 CET] <Farika> my vainfo output is ok [22:34:39 CET] <Farika> but vlc wont work with [22:35:08 CET] <JEEB> try building mpv withe va-api from the mpv-build repository [22:35:19 CET] <JEEB> (or installing from packages if you have new enough) [22:35:29 CET] <Farika> i've post a topic on vlc forum... but a dev say the error is between libavcodec and vdpau [22:35:30 CET] <Farika> https://forum.videolan.org/viewtopic.php?f=13&t=130325&p=436402#p436402 [22:35:46 CET] <JEEB> vdpau is not va-api [22:36:48 CET] <JEEB> anyways, my recommendation would be with trying out the latest mpv with va-api and the opengl renderer, I guess [22:38:54 CET] <Farika> heuu [22:39:01 CET] <Farika> i don't know what i've but i think its ok [22:39:06 CET] <Farika> [00007f75a4c0bf58] avcodec decoder: Using AMD MMD 1.0 for hardware decoding. [22:39:11 CET] <Farika> *what i've done [22:40:38 CET] <Farika> :) thanks [22:40:49 CET] <Farika> wish u good night [00:00:00 CET] --- Mon Jan 25 2016

1 0

ffmpeg-devel.log.20160123
by burek 24 Jan '16

24 Jan '16

[00:19:42 CET] <cone-711> ffmpeg 03Michael Niedermayer 07master:9a8034b8bc1d: doc/demuxers: Document enable_drefs and use_absolute_path [00:19:43 CET] <cone-711> ffmpeg 03Michael Niedermayer 07master:8e32d014322e: avformat/concat: Check protocol prefix [00:19:44 CET] <cone-711> ffmpeg 03Michael Niedermayer 07master:15cc98a0f38a: avformat/libquvi: Set default demuxer and protocol limitations [00:22:56 CET] <kierank> libquvi [00:23:01 CET] <kierank> ... [00:26:37 CET] <atomnuker> I can't even remember when its development stopped [00:27:06 CET] <rcombs> mpv replaced it with youtube-dl [00:27:09 CET] <rcombs> things are better now [00:27:50 CET] <kierank> I'm sending a patch to remove that [00:28:19 CET] <wm4> the developer of libquvi simply disappeared (it's a bit scary) [00:28:50 CET] <J_Darnley> The web streaming cabal whacked him! [00:36:40 CET] <BBB> he probably got hired by some big company [00:59:37 CET] <Plorkyeran> didn't he go insane and try to relicense to agpl first or something? [01:27:39 CET] <J_Darnley> What happened with alldevices and msvc fate clients? [01:32:03 CET] <nevcairiel> hm who knows [01:32:58 CET] <nevcairiel> probably the makefile patch from andreas [01:35:32 CET] <BBB> jya: poke [01:35:49 CET] <BBB> probably off for the weekend... [01:35:50 CET] <BBB> hmm... [01:47:08 CET] <kierank> hopefully I'll get some support for this piece of crap getting removed [01:48:38 CET] <atomnuker> with that description? [01:49:28 CET] <kierank> well lets see if certain people (tm) can behave like adults [01:50:50 CET] <atomnuker> with that description? even I'm not sure what to say [01:51:07 CET] <kierank> it's a removal what do you want me to say [01:51:19 CET] <atomnuker> see the libstagefright message [01:51:45 CET] <kierank> it's notably so easy to add crap to ffmpeg [01:51:47 CET] <kierank> but so hard to remove crap [01:53:03 CET] <atomnuker> less than 5 minutes to write a proper commit message is hard? [01:53:40 CET] <atomnuker> it doesn't even have to be completely true just as long as it's somewhat not-false [01:54:37 CET] <kierank> ah yes let's discuss silly things instead of the actual content [01:54:49 CET] <kierank> classic ffmpeg diversionary tactic [01:54:59 CET] <kierank> what colour is your bikeshed [01:57:25 CET] <atomnuker> okay, someone opens up the commit log and sees "libquvi removed" with the commit message "$subj" [01:58:17 CET] <atomnuker> and before that is a nicely explained bugfix [01:59:18 CET] <atomnuker> what are they going to think? [01:59:51 CET] <atomnuker> one thing they'd do is they'd read the author's name and do some associations [02:00:28 CET] <jamrial> atomnuker: "libquvi is a dead project and hasn't worked on its supported sites for months" [02:00:43 CET] <jamrial> that should be enough as a commit message [02:00:50 CET] <atomnuker> another thing is they'd just do what you do - just assume the project's developers are so lazy they couldn't even write up a proper commit message [02:01:07 CET] <atomnuker> there, see, a nice coherent, to the point sentence [02:04:17 CET] <kierank> atomnuker: your idol carl does exactly this [02:08:03 CET] <jamrial> can we not start a flamewar out of something as stupid as a commit message? [02:08:47 CET] <TD-Linux> the bikeshed should be ON FIRE [02:10:10 CET] <atomnuker> I blame the "FFmpeg is shit" meme [02:12:59 CET] <atomnuker> making it worse "because why should I, it's shit" and then continuing to complain is what gets me [02:18:45 CET] <kierank> yes but you fuel the bigger problems by splitting hairs [02:19:04 CET] <kierank> because it adds noise to whole development process and trying to get stuff done [02:19:16 CET] <kierank> jamrial did exactly what was necessary [02:19:18 CET] <kierank> it will be fixed [02:19:18 CET] <kierank> that's iot [02:19:37 CET] Action: J_Darnley shouldn't be enjoying this [02:19:54 CET] <BBB> so uhm, if all msvc builds are broken [02:19:57 CET] <BBB> maybe revert that patch? [02:20:45 CET] <nevcairiel> probably only out of tree builds, but thats the only thing fate tests [02:21:02 CET] <jamrial> we could give Andreas some time to see if he can fix it [02:23:18 CET] <kierank> Any idea what could be causing these weird RGB halos? [02:23:23 CET] <kierank> https://usercontent.irccloud-cdn.com/file/fDNvLZ0m/ [02:23:35 CET] <kierank> right is what appears to be a sane looking yuv422p file [02:23:39 CET] <kierank> left is the rgb version [02:23:44 CET] <J_Darnley> Weird Al looking extra weird! [02:24:06 CET] Action: J_Darnley needs to stop shit posting [02:27:31 CET] <jya> BBB: yes? [02:32:16 CET] <atomnuker> kierank: looks like an overflow [02:32:54 CET] <kierank> yes ofc [02:33:03 CET] <TD-Linux> a busted resampling filter? [02:33:55 CET] <TD-Linux> though luma looks broken too [02:36:40 CET] <kierank> atomnuker: no top posting =p [02:36:53 CET] <kierank> it's low bitrate [02:36:59 CET] <kierank> so luma might need to look like that I dunno [02:42:27 CET] <cone-711> ffmpeg 03Michael Niedermayer 07master:f502583663eb: avcodec/mpeg4videoenc: Use 64bit for time variables [02:49:54 CET] <TD-Linux> kierank, oh that's before and after compression too? [02:50:00 CET] <kierank> no [02:50:02 CET] <kierank> the same source [02:50:08 CET] <kierank> one with yuv decoding which works [02:50:11 CET] <kierank> other is rgb which doesn't [03:08:06 CET] <BBB> jya: sent email instead :) [04:11:47 CET] <kierank> do we have a 12-bit gbrp [04:23:24 CET] <jamrial> looks like we do [04:23:40 CET] <jamrial> at least in pixfmt.h [04:23:54 CET] <jamrial> avutil [04:24:01 CET] <jamrial> no idea about swscale [04:24:35 CET] <jamrial> a quick grep says yes [04:29:23 CET] <kierank> ooh that makes it look quite good [04:29:53 CET] <kierank> https://usercontent.irccloud-cdn.com/file/f0s8GpmM/ [04:29:55 CET] <kierank> wtf that weird border is I have no idea [04:38:35 CET] <kierank> looks like I have to add a GBRAP12 [04:40:35 CET] <jamrial> ^looks like that ticket has a hint to solve Andreas' problem :p [04:44:59 CET] <kierank> ffplay shows different artefacts to other players [10:28:23 CET] <wm4> nevcairiel: you said there's a hack that somehow serializes hwaccel access on mt to a degree? [10:54:29 CET] <wm4> also, can someone send a patch to remote the old vdpau decoder? [10:54:47 CET] <durandal_1707> but carl [12:02:17 CET] <nevcairiel> wm4: it does that today yes, by only allowing one thread to execute at a time, but that only serializes inside avcodec, as soon as avcodec_decode_video returns the next thread runs, so while its internally serizalized, its still in parallel to whatever your user code does, which is where the problems come from [12:20:51 CET] <nevcairiel> so now he runs out of arguments and just threatens to push it anyway? [12:23:10 CET] <wm4> would the compromise be allowing MT only for some codecs? (vaapi or vdpau, whatever he uses and which he judged as probabilistically working) [12:24:46 CET] <wbs> do I understand it correctly that it theoretically can work for dxva as well, if the caller does some complicated locking (as vlc apparently does)? [12:24:50 CET] <nevcairiel> that doesnt really solve the underlying issues and still requires someone to refactor the vp9 hwaccel since we have a vaapi for that [12:24:57 CET] <nevcairiel> wbs: yes [12:25:18 CET] <nevcairiel> but its really kinda complex so not something anyone should be doing [12:25:24 CET] <wbs> well vlc apparently wants to [12:25:28 CET] <wbs> why not let them, then? [12:25:45 CET] <wbs> something like a "I really know what I'm doing" flag or so [12:25:46 CET] <nevcairiel> because it requires us to make sure it keeps working [12:26:24 CET] <wbs> sure [12:26:34 CET] <wbs> just wanted to check that, so I know what to think of all the discussion, I won't be taking part [12:27:50 CET] <wm4> nevcairiel: so can dxva really not read back while the surface is in use as reference picture? [12:28:08 CET] <nevcairiel> its the other way around, it cannot use it as a reference if its locked for readback [12:28:13 CET] <nevcairiel> but only on some drivers, not all [12:29:42 CET] <wm4> how inconvenient, could lead to random corruption when taking screenshots and using direct rendering (at least the way I'd implement it) [12:57:13 CET] <nevcairiel> i only ever lock them on the same thread as the decoding runs to avoid that, if i use direct rendering they get passed to the video renderer as-is which processes them into rgb before any such thing as screenshotting [12:59:40 CET] <wm4> maybe this could be solved by copying the surface to another surface? although that might not be wanted during normal decoding, as it might make it slower [13:00:15 CET] <nevcairiel> you could probably avoid this particular problem by doing that, yes [13:00:47 CET] <wm4> but it would be slower? (I'm thinking that this copy could also take care of copying it to system ram, so maybe it would not matter?) [13:01:11 CET] <wm4> or you could leave the second surface locked, and use its memory directly (again assuming it's in system ram) [13:01:30 CET] <nevcairiel> would probably end up slower, depends how much free memory bandwidth your gpu has [13:02:37 CET] <nevcairiel> cant say I have ever done this, so.. [13:03:05 CET] <davnik> Hello, I am trying to remove the watermark from a video using the --delogo option [13:03:16 CET] <davnik> http://snag.gy/B5BUv.jpg [13:03:27 CET] <davnik> Could anyone please give me the proper coordinates to use here? [13:03:57 CET] <wm4> davnik: wrong channel [13:04:34 CET] <davnik> wm4, I posted on #ffmpeg no response ;-) [13:06:17 CET] <wm4> then wait there [13:06:29 CET] <wm4> this is a development channel [13:09:53 CET] <BBB> kierank: yes, we support up to 14bpp in swscale (was needed for >8bpp h264 support in fate) [13:10:18 CET] <BBB> kierank: since fate tests by md5 and the endianness needed to be standardized for fate to test >8pp stuff [13:10:34 CET] <kierank> BBB: it looks funny though in ffplay [13:10:48 CET] <kierank> In other viewers it looks better [13:11:09 CET] <BBB> its possible some conversions are a little questionable [13:11:10 CET] <kierank> I blame swscale [13:11:17 CET] <BBB> thats reasonable [13:11:25 CET] <kierank> Only RGB looks weird [13:11:42 CET] <BBB> I believe the >8bpp support in swscale uses intermediates that scale up to 14bpp to fit the complete inside width internally [13:11:49 CET] <BBB> I forgot how it works exactly [13:11:54 CET] <BBB> so 14bpp may overflow [13:11:57 CET] <BBB> sometimes [13:19:07 CET] <wm4> what looks weird? [13:19:37 CET] <JEEB> depending on the format, you might be able to use the zscale filter instead of swscale [13:19:53 CET] <JEEB> which uses the zimg scaler/colorspace conversion library [13:21:39 CET] <durandal_1707> shame swscale is not rewriten and added float pixel format [13:24:55 CET] <kierank> I don't actually need to scale - I just need to add a comment saying don't use ffplay to debug this decoder [13:25:23 CET] <nevcairiel> figuring out why its broken would still be useful though [13:26:05 CET] <ubitux> ffplay = sdl broken yuv, no? [13:26:50 CET] <wm4> also forces libswscale [13:32:49 CET] <Daemon404> output to rgb via vf_zscale? [13:32:50 CET] Action: Daemon404 runs [13:35:58 CET] <cone-684> ffmpeg 03Hendrik Leppkes 07master:406f30072e4e: dxva2_h264: fix reference field marking in long slice struct [13:37:18 CET] <wm4> nevcairiel: so, how about that dxva hevc10 support? [13:54:49 CET] <nevcairiel> I thought again about just skipping any flag or such to enable it, since that just feels ugly, but I already see someone yelling at me for breaking vlc again =p [13:55:48 CET] <wm4> lol [13:56:05 CET] <wm4> vlc seem to have pretty advanced dxva support [13:56:10 CET] <wm4> for supporting windows store I guess [13:56:13 CET] <nevcairiel> not really [13:56:24 CET] <nevcairiel> its profile checks are adequate at best [13:57:19 CET] <nevcairiel> although it would probably not break from enabling hevc10 since it seems to check for that specifically [13:58:44 CET] <wm4> ah I see, they still have their old d3d9 code around [13:59:31 CET] <nevcairiel> interestingly, microsoft updated the vp9 dxva spec to allow profile 2 decoding as well (420 10-bit) [13:59:42 CET] <wm4> (actually no idea how that vlc code works now...) [14:01:03 CET] <wm4> anyway... either we potentially "break" API users, or we add a new private option [14:01:09 CET] <wm4> we just have to make a choice [14:02:14 CET] <nevcairiel> private options on the "host" codec seem like a rather terrible choice [14:02:29 CET] <nevcairiel> personally I would add a flag to the dxva_context, but alas it doesnt have an allocation function, sooo... [14:02:50 CET] <nevcairiel> should probably add that for the next bump [14:06:56 CET] <wm4> also an option: add a new function, that sets an internal flag somewhere [14:07:12 CET] <wm4> meh I'd just "break" it [14:07:40 CET] <wm4> if the hevc standard would add new 8 bit profiles they'd also break, so what [14:09:08 CET] <nevcairiel> speaking about profiles, for some reason our hevc decoder doesnt list any of the new profiles [14:09:11 CET] <nevcairiel> i should add those [14:09:47 CET] <wm4> which new profiles? [14:10:20 CET] <nevcairiel> version 2 [14:10:24 CET] <nevcairiel> https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Version_2_profil… [14:10:46 CET] <wm4> urgh multiview [14:11:38 CET] <Compn> is that 3d or angles ? [14:11:59 CET] <wm4> "The Screen-Extended Main profile allows for a bit depth of 8-bits per sample with support for 4:0:0 and 4:2:0 chroma sampling." [14:12:11 CET] <wm4> this one sounds like a new yuv420p profile [14:13:04 CET] <nevcairiel> ah profiles in hevc are all kinds of confusing [14:13:19 CET] <nevcairiel> the version 2 profiles set profile = 4 and indicate their features in extra bits [14:13:59 CET] <nevcairiel> and there is profile = 5 for "high througput" profiles, ie 444 16 intra [14:14:28 CET] <BBB> kierank: can you give me a file and a ffplay commandline to reproduce? [14:14:39 CET] <BBB> kierank: I can assist in fixing the bug regardless of whether you care [14:14:55 CET] <kierank> have to get the cfhd decoder in first [14:14:57 CET] <kierank> and working [14:19:02 CET] <BBB> ok [14:19:04 CET] <BBB> let me know [14:28:42 CET] <kierank> very likely the cause [14:28:43 CET] <kierank> [auto-inserted scaler 0 @ 0x7fac980024c0] w:640 h:608 fmt:gbrp12le sar:0/1 -> w:640 h:608 fmt:yuv420p sar:0/1 flags:0x4 [14:29:12 CET] <wm4> mpv can render this format directly with vo_opengl (but don't ask me if it's correct) [14:29:14 CET] <nevcairiel> the new sdl2 ffplay should be able to make saner choices [14:29:24 CET] <nevcairiel> at least render to rgb32 instead of yuv420 [14:30:06 CET] <kierank> I tried implementing gbr12 in a yuv viewer but it looks different [14:30:11 CET] <kierank> so I wonder if that conversion is getting botched [14:30:16 CET] <kierank> and the material isn't gbr [14:30:35 CET] <wm4> did you make sure the upper bits are zero? [14:31:27 CET] <kierank> no [14:31:30 CET] <kierank> might have to [14:31:50 CET] <kierank> the difference is much better in the yuv viewer but the planes are in the wrong order [14:31:56 CET] <kierank> not sure what permutation gives you the right picture [14:48:30 CET] <kierank> one of the viewers is wrong and I have no idea why [14:49:24 CET] Action: kierank tries imagej [14:53:45 CET] <kierank> starting to think it's a hardware issue [14:57:45 CET] <kierank> only one that looks right in the viewer is GRB [14:58:01 CET] <kierank> but then i flip the planes in the decoder to GBR and the viewer isn't happy [14:58:04 CET] <kierank> ffplay looks ok though [17:46:05 CET] <durandal_170> vapoursynth filters never check malloc return value [17:49:22 CET] <wm4> aren't most of them written in C++ [17:53:12 CET] <Daemon404> wm4, no [17:53:16 CET] <Daemon404> most i see are c [17:53:19 CET] <Daemon404> durandal_170, which ones? [17:53:26 CET] <Daemon404> if theyre ported from avisynth, i am not surprise.d [17:53:36 CET] <wm4> ah, lol [17:54:52 CET] <durandal_170> vs_aligned_malloc [17:57:45 CET] <Daemon404> durandal_170, i dont follow [17:57:50 CET] <Daemon404> it's just a malloc wrapper [17:57:55 CET] <Daemon404> its up to teh caller to check [17:58:40 CET] <durandal_170> yes, and nnedi3 never check it [17:58:50 CET] <Daemon404> nnedi3 is a port from avisynth [17:58:50 CET] <Daemon404> so [17:58:53 CET] <Daemon404> [16:53] <@Daemon404> if theyre ported from avisynth, i am not surprise.d [17:58:58 CET] <Daemon404> avisynth code is horrible [18:00:02 CET] <durandal_170> Looking how fast I can port random filter, fast and ugly way [18:28:24 CET] <vincentdumont> Hello everyone! I am seeking to help the open source ffmpeg community. I would be glad to contribute to this wonderful project so feel free to visit my website (www.vincentdumont.com) in order to have more information about me. Thank you in advance! [18:33:32 CET] <kierank> What are you interested in doing? [18:39:52 CET] <vincentdumont> I can work on C or C++ level [18:40:50 CET] <vincentdumont> But I would also be interested in web development [18:41:04 CET] <cone-684> ffmpeg 03Michael Niedermayer 07master:7fc944df1583: fate/ffmpeg: Fix colorkey test failure without samples [18:41:05 CET] <cone-684> ffmpeg 03Michael Niedermayer 07master:d8637853795e: avfilter/vf_convolution: Use av_clip_uint8() [18:43:28 CET] <Daemon404> vincentdumont, you should pick a thing to work on or figure out which bits you'd enjoy working on. (when in doubt, there is the bug tracker, i suppose.) [18:45:22 CET] <Compn> we need a list of stuff to work on :P [18:45:33 CET] <Compn> we keep getting volunteers [18:45:45 CET] <Daemon404> the wiki / small tasks lists is probably sorta kinda maybe useful [18:45:47 CET] <Compn> j-b : how does videolan organize new contributors ? [18:45:58 CET] <Compn> Daemon404 : you guys hate on those wiki pages all the time ! :P [18:46:06 CET] <Daemon404> Compn, thats not on our wiki [18:46:09 CET] <Daemon404> it's multimediawiki [18:46:13 CET] <Daemon404> i hate on our wiki ;) [18:46:58 CET] <Daemon404> ... last updated may 2014 [18:47:02 CET] <Daemon404> mayeb not as useful. [18:47:05 CET] <vincentdumont> Okay I am going to search for a good list of bugs then, thank you for your time! [18:47:40 CET] <Compn> Daemon404 : unfortunately i think everyone kind of abandoned multimediawiki [18:47:51 CET] <Compn> scorched earth... [18:49:28 CET] <kierank> you could also try fuzzing a simple codec [18:49:32 CET] <kierank> that's a nice way to understand things [18:49:39 CET] <Daemon404> do we have a guide for that [18:49:43 CET] <Daemon404> i was sure we did. [18:50:36 CET] <kierank> libav does [18:52:57 CET] <fritsch> libav also enables frame threading .... [18:52:59 CET] <fritsch> not an argument :-) [20:23:48 CET] <jkqxz> wm4: The codec/profile problem isn't sensibly fixable. We want FATE to work, and some of those streams declare unhelpful profiles (most obviously H.264 extended) but work anyway with a technically-incompatible profile (there, H.264 main). Hence I kept the dubious fallback, though I removed the default promotion. [20:26:32 CET] <wm4> jkqxz: then there should be an option to override it, and the FATE tests should add it (also, since when do we test hwaccel with FATE?) [20:27:09 CET] <nevcairiel> not automatically, but you can run it manually [20:27:11 CET] <nevcairiel> its kinda helpful [20:28:07 CET] <J_Darnley> durandal_170: doesn't nnedi need some or other training data? [20:28:55 CET] <wm4> nevcairiel: does this mean the other hwaccels don't check profiles properly? [20:28:57 CET] <durandal_170> J_Darnley: yes, you give it as arg to filter [20:29:04 CET] <J_Darnley> ah [20:30:20 CET] <Daemon404> that makes it pretty useless [20:30:24 CET] <Daemon404> if you have to supply your own [20:30:31 CET] <Daemon404> needi's selling point is its specific trauining data [20:30:34 CET] <Daemon404> nnedi* [20:30:46 CET] <Daemon404> no otehr set will ever be use.d [20:30:49 CET] <Daemon404> (loltypos) [20:31:27 CET] <nevcairiel> wm4: like how, hwaccels dont check profiles, heck the majority of them dont even want to know what the profile is, the hwaccels just give it the data they ask for, its the user apps responsiblity to chekc [20:32:29 CET] <durandal_170> Daemon404: distributing data with ffmpeg is pointless [20:32:30 CET] Action: J_Darnley wonders if someone will complain about not checking the return of fclose. [20:32:45 CET] <Daemon404> durandal_170, its point is to make it actually usable [20:32:53 CET] <Daemon404> id say thats a pretty big point. [20:32:54 CET] <wm4> nevcairiel: yes but in this case ffmpeg.c is the app? [20:33:08 CET] <durandal_170> > /dev/null [20:33:10 CET] <nevcairiel> ffmpeg_dxva2.c checks the profile for h264 at least [20:33:27 CET] <wm4> Daemon404: the problem with it is that the data is so huge [20:33:34 CET] <J_Darnley> Tut tut! Using "long" in this day and age. [20:34:03 CET] <Daemon404> wm4, yes but then you end up with users wondering a) why the hell it does nothing or b) confused as hell c) askign where to even get the data [20:34:04 CET] <wm4> although mpv's nnedi support uses a subset, so it's only 158KB [20:34:11 CET] <wm4> (still that's a hard increase in binary size) [20:34:14 CET] <durandal_170> it is fast and fury port [20:34:48 CET] <J_Darnley> And that was a fast review. [20:35:18 CET] <Daemon404> this is just yet another inherent problem of the "giant monolithic filyter library" approach [20:35:29 CET] <wm4> Daemon404: definitely [20:35:30 CET] <Daemon404> cant increase size with useful things! my precious mb! [20:35:31 CET] <jkqxz> Heh, extent of profile checking in ffmpeg_dxva2.c: "if (s->codec_id == AV_CODEC_ID_H264 && (s->profile & ~FF_PROFILE_H264_CONSTRAINED) > FF_PROFILE_H264_HIGH) { fail; }". Am I a naughty person if I copy that? [20:35:48 CET] <wm4> but, ffmpeg and defining APIs that don't need ABI changes a month after... [20:36:04 CET] <Timothy_Gu> jkqxz: are the incorrect results observable for libva's reference decoder as well? [20:36:14 CET] <wm4> jkqxz: I guess there's no problem with that if it works [20:36:31 CET] <Daemon404> wm4, ... i just went to google my lavfi email [20:36:34 CET] <Daemon404> its 4 years old now [20:36:36 CET] <Daemon404> hot damn. [20:36:42 CET] <wm4> heh [20:36:51 CET] <wm4> I remember that mail [20:37:23 CET] <nevcairiel> jkqxz: technically you would probably want to blacklist baseline as well, but you know the deal with baseline, so [20:38:47 CET] <Timothy_Gu> jkqxz: also we usually type a space after `if`, `while`, and other keywords [20:38:53 CET] <jkqxz> Timothy_Gu: Don't know. I thought of trying that, but it needs some set of otherwise-useless code written to test. I was rather hoping for a hint around what is interesting about cvfc1_sony_c and others. [20:38:56 CET] <durandal_170> Daemon404: enjoying yourself? [20:38:59 CET] <Daemon404> ...? [20:39:34 CET] <durandal_170> googleing own mails? [20:40:06 CET] <Daemon404> sure why not. all the poitns from 4 years ago are still relevant to lavfi today. [20:40:28 CET] <Daemon404> although now i would add a few more to the list. [20:40:29 CET] <durandal_170> they are not [20:40:30 CET] <Timothy_Gu> jkqxz: ah. Cool then [20:40:37 CET] <Daemon404> durandal_170, i can only disagree, [20:40:45 CET] <wm4> jkqxz: anyway, I'll try to review tomorrow [20:40:51 CET] <jkqxz> Timothy_Gu: Then you are all crazy people. (Habits of a lifetime. I can fix it with sed if you care strongly.) [20:41:43 CET] <durandal_170> Daemon404: what would you add? [20:42:11 CET] <Daemon404> durandal_170, the first that comes to mind is the way it pushes/pulls frames [20:42:16 CET] <Daemon404> e.g. going fro ma very very low fps to a higher one [20:42:18 CET] <Daemon404> buffers a LOT [20:42:20 CET] <Daemon404> and uses a lot of memory [20:42:24 CET] <Daemon404> causes OOM kills sometimes [20:42:36 CET] <Daemon404> so point: buffering problems. [20:44:17 CET] <wm4> wasn't there a lot done on frame scheduling [20:44:28 CET] <durandal_170> Daemon404: huh, what buffers? Specific filter? [20:44:41 CET] <Daemon404> wm4, we still regularily get OOM kills in prod [20:44:48 CET] <Daemon404> durandal_170, vf_fps [20:46:01 CET] <durandal_170> hmm, it just clones or drops frames, it shouldn't allocs so much memory [20:46:25 CET] <Timothy_Gu> jkqxz: lol you can do whatever you feel like. I (nor most of us) have strong opinions on it anyway [20:46:45 CET] <Daemon404> durandal_170, i think it has something to do with the way it's used in ffmpeg.c, but i am not sure [20:47:29 CET] <Daemon404> [output stream 0:0 @ 0x7f9c68d00900] 1000000 buffers queued in output stream 0:0, something may be wrong. [20:47:33 CET] <Daemon404> this kind of stuff is always in the logs [20:47:52 CET] <durandal_170> Daemon404: what fps args you used? [20:48:46 CET] <Daemon404> i dont have any on my at this very moment... [20:48:53 CET] <Daemon404> but it generally happens when you have stuff like [20:48:59 CET] <Daemon404> 10 seconds of 25 fps content with some intro [20:49:04 CET] <Daemon404> then 1-2 hours of a single, static frame after [20:49:12 CET] <Daemon404> VFR, of course. [20:49:21 CET] <Daemon404> so that last 1-2 frames is some incredibly low fps. [20:49:55 CET] <Daemon404> durandal_170, i assume you missed my response [20:50:22 CET] <durandal_1707> I lost you at stuff like [20:50:38 CET] <Daemon404> [19:48] <@Daemon404> 10 seconds of 25 fps content with some intro [20:50:38 CET] <Daemon404> [19:49] <@Daemon404> then 1-2 hours of a single, static frame after [20:50:39 CET] <Daemon404> [19:49] <@Daemon404> VFR, of course. [20:50:39 CET] <Daemon404> [19:49] <@Daemon404> so that last 1-2 frames is some incredibly low fps. [20:51:00 CET] <Daemon404> it's unfortunately common for seminars and talks [20:54:22 CET] <Daemon404> pfff [20:54:42 CET] <JEEB> cool connection [20:54:44 CET] <durandal_1707> so fps filter should make it cfr [20:54:55 CET] <Daemon404> yes [20:55:12 CET] <Daemon404> but then it has to duplicate that final static frame a bazillion times [20:56:27 CET] <durandal_1707> but it keeps buffering it but never allowing buffersink to pick it [20:56:55 CET] <Daemon404> i am not familiar enough with the internals of lavfi to say if thats correct or not [20:57:04 CET] <Daemon404> i just know the end result is an OOM kill [20:58:11 CET] <durandal_1707> something similar happens with zoompan [21:13:00 CET] <jamrial> looks like the out-of-tree patch also broke hardcoded tables builds [21:13:50 CET] <cone-684> ffmpeg 03Michael Niedermayer 07master:0be4377333d8: fate/cabac: replace uninitialized bytes by random bytes [21:24:01 CET] <BBB> so is that patch being reverted? [21:30:48 CET] <jamrial> Andreas fixed checkasm, but msvc is still broken. so yeah, it should be reverted until a solution is found [21:42:05 CET] <jamrial> meant to say checkheaders [21:50:11 CET] <cone-684> ffmpeg 03Andreas Cadhalpun 07master:f503022ce56a: build: fix make checkheaders in out-of-tree builds [21:52:43 CET] <BBB> especially because it sounds, from the discussion so far, that the whole point of the patch (making in/out tree bitexact) is fundamentally not possible with msvc [21:53:24 CET] <BBB> so at least well need a conditional pre-patch makefile codepath for msvc, and that probably means a full revert for simplicity purposes [22:21:18 CET] <J_Darnley> Is using MSVC through Cygwin supported? [22:21:27 CET] <J_Darnley> If so that patch would fail. [22:21:40 CET] <J_Darnley> Cygwin's pwd doesn't have -W [22:22:38 CET] <J_Darnley> Maybe I should put that in an email. [22:22:54 CET] <Daemon404> J_Darnley, neither does freebsd's/ [22:23:06 CET] <Daemon404> http://pubs.opengroup.org/onlinepubs/009696899/utilities/pwd.html [22:23:09 CET] <Daemon404> neither does POSIX. [22:23:10 CET] <J_Darnley> Can you use MSVC there? [22:23:24 CET] <J_Darnley> I assume its a feature of msys [22:23:24 CET] <Daemon404> i dont know, i have no context :D [22:25:34 CET] <cone-684> ffmpeg 03Charlie Arnold 07master:22ee0a576faf: build: fix msvc build [22:26:53 CET] <Daemon404> .... it was pushed anyway? [22:26:57 CET] <Daemon404> holy crap that is a hack [22:27:37 CET] <BtbN> Welp, that means it's broken for me now. [22:27:50 CET] <BtbN> msvc via cygwin is how I usualy build [22:27:54 CET] <Daemon404> a few people do [22:27:57 CET] <J_Darnley> Ah. [22:28:20 CET] <drv> pwd -W is a msys-only thing [22:28:31 CET] <drv> we could pile on more hacks by detecting cygwin and using cygpath, but that seems like a bad plan [22:28:43 CET] <J_Darnley> heh [22:29:22 CET] <J_Darnley> BtbN: you should check just incase I didn't understand the logic correctly [22:29:27 CET] <Daemon404> its incredinly wrong to make environment decisions based on TARGET toolcgain [22:29:30 CET] <Daemon404> on so many levels [22:30:25 CET] <drv> it's not even too far-fetched to imagine MSVC cross compile via wine [22:30:37 CET] <drv> (with a native linux shell) [22:31:10 CET] <BBB> did we just pile 3 levels of hacks on top of something that is nice-to-have at best? [22:31:15 CET] <BBB> please someone take charge of this :( [22:31:16 CET] <Daemon404> drv, all of libav's fate instances do that [22:31:18 CET] <Daemon404> BBB, yes [22:31:31 CET] <Daemon404> i think having the 'feature' at all si not worth it. [22:32:12 CET] <BtbN> What about $(pwd -W 2>/dev/null || cygpath -w -a . 2>/dev/null || pwd) [22:32:17 CET] <BtbN> when we're making ugly hacks anyway [22:32:32 CET] <BBB> wine cl.exe [22:32:41 CET] <BBB> lets just revrt that patch? [22:32:45 CET] <BBB> all of them, that is [22:32:57 CET] <BtbN> What exactly are they even trying to fix? [22:33:07 CET] <BBB> my boss at hedge fund used to say hacky hack hack when we did stpid stuff like that [22:33:13 CET] <BBB> so Id like to introduce that here [22:33:15 CET] <BBB> hacky hack hack [22:33:18 CET] <J_Darnley> The new patches: building on msys [22:33:39 CET] <J_Darnley> The first problem patch: bitexact building out of tree [22:33:56 CET] <BBB> I know [22:34:10 CET] <J_Darnley> (that was bot BtbN) [22:34:15 CET] <J_Darnley> *for [22:34:57 CET] <BBB> oh sorry [22:34:59 CET] <J_Darnley> Oh another new patch was for check-headers [22:35:12 CET] <J_Darnley> *fixing check-headers [22:35:37 CET] <Daemon404> and i replied to teh wrong mail [22:35:47 CET] <Daemon404> i didnt notice my MUA didnt select it [22:35:50 CET] Action: Daemon404 A+ stuent [22:35:53 CET] <Daemon404> student, even. [22:37:40 CET] <drv> oh yeah, the OS/2 guy showed up in this other thread, totally forgot about that [22:52:09 CET] <BBB> Im starting to feel that the arguments that come out of andreas are identical to these coming out of ganesh, and they dont make me happy [22:52:24 CET] <BBB> theyre just about arguing, having the last word and not about moving a situation forward to an actual solution [22:53:51 CET] <Daemon404> you must be new to debianland [22:54:16 CET] <jamrial> andreas is the debian guy, right? i can see now why he's insisting on the mt vlc issue [22:54:54 CET] <Daemon404> yes he is [22:55:17 CET] <Daemon404> most of his stuff seems to me like "what is the least amount of effort i can put into makign my packages happy" [22:55:29 CET] <jamrial> why isn't he poking the vlc side of things instead? [22:55:33 CET] <BtbN> it seems strange to me that videolan/vlc refuses to fix something that is known to be broken, and instead so this weird stuff that's happening right now [22:55:42 CET] <jamrial> isn't every other libavcodec based player working fine after this mt change? [22:55:49 CET] Action: Daemon404 has 10 foot pole about vlc/hwaccel [22:56:11 CET] <Daemon404> jamrial, path of least resistance to making packages happy. [22:56:11 CET] <BtbN> No other (major?) player uses frame threading with hwaccell i'd guess [22:57:05 CET] <BtbN> But I don't get why they don't just fix that. What's so hard about that? Or is it realy about the fallback to sw decode, which would also just use one thread then? [22:57:43 CET] Action: Daemon404 keeps his 10-foot pole out [23:00:37 CET] <durandal_1707> Daemon404: have more to add from list? [23:01:22 CET] <Daemon404> durandal_1707, ill think on it. [23:10:12 CET] <wm4> I wonder why this andreas guy doesn't just go argue with courmisch [23:10:19 CET] <wm4> I'm sure they'd have a lot of fun together [23:10:40 CET] <Daemon404> i already answered that [23:50:22 CET] <nevcairiel> ... why do patches get pushed after 5 minutes [23:50:27 CET] <nevcairiel> this msvc thing is broken as fuck [23:52:15 CET] <wm4> were they OK'ed? [23:52:22 CET] <nevcairiel> not by anyone but himself [23:52:31 CET] <nevcairiel> and even then it should be left on the ML for a period of time [23:52:43 CET] <wm4> that's not ok then [23:54:56 CET] <nevcairiel> we should just push a revert of everything of this crap [23:58:09 CET] <ubitux> send a patch, wm4 ack it, and 5min later you push it [23:58:35 CET] <ubitux> introducing the pair revert wars [23:59:42 CET] <BtbN> This should never have been pushed in the first place, so reverting it sounds like the apropriate thing to do. [23:59:52 CET] <BtbN> There were numerous concerns about it [00:00:00 CET] --- Sun Jan 24 2016

1 0

ffmpeg.log.20160123
by burek 24 Jan '16

24 Jan '16

[00:57:07 CET] <SeanM_> is there an easy automated/newbie proof way to install ffmpeg on osx? [00:58:43 CET] <genii> ...perhaps https://www.ffmpeg.org/download.html#build-mac ? [01:00:31 CET] <J_Darnley> or perhaps an osx link from http://trac.ffmpeg.org/wiki/CompilationGuide if you want to compile yourself [01:01:04 CET] <SeanM_> Thanks guys [07:46:36 CET] <probalaa> I run the command given on this page: https://trac.ffmpeg.org/wiki/StreamingGuide AND the terminal says: Unknown input format: 'dshow' [07:46:53 CET] <probalaa> $ ffmpeg -y -loglevel warning -f dshow -i video="screen-capture-recorder" -vf crop=690:388:136:0 -r 30 -s 962x388 -threads 2 -vcodec libx264 -vpre baseline -vpre my_ffpreset -f flv rtmp:///live/myStream.sdp [07:52:53 CET] <rektimus> https://trac.ffmpeg.org/wiki/DirectShow [07:53:13 CET] <rektimus> does screen capture recorder show in ur device list output [08:00:57 CET] <rektimus> or [08:01:00 CET] <rektimus> are you on windows? [09:01:28 CET] <digidog> rektimus: hi. ffmplay seesm not to have STDIN support. do you have any idea how to setup the part of a shell script playing audio thru ffmplay, which tries to bind keys for skipping or forward/rewind, etc ? [09:03:03 CET] <digidog> rektimus: maybe a work around via trap? [09:03:21 CET] <c_14> digidog: I don't think ffplay reads stdin [09:03:32 CET] <digidog> c_14: thats what I think too [09:04:06 CET] <digidog> c_14: any idea how to get around this. at least for some minimum control [09:04:34 CET] <digidog> c_14: at least for break up a play or skip if multiple files are in queue [09:05:11 CET] <digidog> trap 'trap - INT; kill -INT "$$"' INT ... hm ... [09:14:57 CET] <c_14> You could try using an actual scriptable player such as mpv [09:17:13 CET] <digidog> c_14: hm, yeah but I was hoping to be able to stay low level and tight to ffmpeg. BUt maybe you are right [09:17:32 CET] <Degot> Hi, All. Is there a tutorial on how to start ffserver as service on Ubuntu 14.04.x? [09:17:50 CET] <c_14> digidog: otherwise you'd have to patch ffplay to accept input on stdin [09:18:33 CET] Action: digidog hides and facepalms [09:18:40 CET] <digidog> :) [09:22:35 CET] <digidog> c_14: sadly this options only work if ffplay has been started directly and with display http://ffmpeg.org/ffplay-all.html#While-playing [09:24:17 CET] <digidog> does anyone know if I can route ffplay thru alsa under linux ? [09:25:24 CET] <c_14> -sinks alsa probably [09:26:03 CET] <c_14> hmm, that just lists them [09:28:16 CET] <digidog> c_14: yep [09:32:44 CET] <c_14> Don't think there's an option. [09:33:08 CET] <digidog> c_14: :$ yeah, tried to find sth, with no luck [09:33:35 CET] <digidog> c_14: but hey, thanks a million for chiming in and trying to help [09:33:38 CET] <digidog> c_14++ [09:33:57 CET] <digidog> LOL [09:33:58 CET] <c_15> np [09:38:46 CET] <digidog> c_14: maybe we better switch to mplayer (mpv is too much fo rthis appraoch) and use ffplay as a fall back. [09:54:23 CET] <digidog> c_14: https://github.com/diqidoq/playa [12:45:00 CET] <davnik> Hello, I am trying to remove the watermark from a video using the --delogo option [12:45:25 CET] <davnik> http://snag.gy/B5BUv.jpg [12:45:40 CET] <davnik> Could anyone please give me the proper coordinates to use here? [13:24:47 CET] <jkqxz> davnik: You mean the "made with ..." thing? That's too big to plausibly remove. You can blur it over but there won't be enough information to recreate anything sensible underneath. [13:33:01 CET] <chungy> you could probably try to recreate the background and overlay it... but I'm assuming that banner appears in other scenes too that aren't identical [13:42:42 CET] <rektimus> if photoshop can do it [13:50:38 CET] <chungy> it's not really a matter of software, but artistic skill and how much effort will be involved [14:19:52 CET] <micechal> is it possible to *completely* drop any metadata when encoding pcm s16le? [14:20:36 CET] <micechal> so far I tried "-map_metadata -1" but that still leaves some stuff [14:20:46 CET] <micechal> like encoder information [14:21:03 CET] <c_14> try adding -fflags +bitexact [14:21:11 CET] <c_14> You can get rid of the encoder info as well, but I can't remember how. [14:22:54 CET] <micechal> I'll try some googling [14:23:00 CET] <micechal> well, that seems to have dropped the "ISFT" thingy, but yeah, the encoder info is still here [14:23:03 CET] <micechal> I'll try some googling [15:46:58 CET] <Chagall> is there a way to tell programmatically whether there exists a pass log file corresponding to a certain input file? [15:49:37 CET] <Chagall> or any other way to tell after the process exits whether it was encoding with pass 1 or not [15:50:12 CET] <Chagall> in the log file situation i would know where the log file is located, but i don't know if it is parsable and how to do it [15:52:44 CET] <dystopia_> look in media info [15:53:04 CET] <dystopia_> undner encoding settings it will say rc=2pass [16:02:00 CET] <Chagall> i mean between the first and second pass [16:02:13 CET] <Chagall> need to check whether the process that ended was the one that did the first or the second pass [16:03:05 CET] <Chagall> i guess i could check that the files exist but i'd rather be sure [16:24:47 CET] <gattler> Hi all, can I convert only the audio part of a video? e.g I have a with a 5.1 dts audio but I want it to have 5.1 ac3 with a certain bitrate [16:25:03 CET] <gattler> can I do that without touching the video? [16:27:21 CET] <jkqxz> -c:v copy [16:28:40 CET] <gattler> do I have to worry about the audio channels? or will ffmepg ensure that e.g. front-left stays front-left? [16:29:25 CET] <c_14> yes [16:29:32 CET] <c_14> you don't have to worry [16:30:28 CET] <gattler> ffmpeg -i input.mkv -vcodec copy -acodec ac3 -ab 192k output.mkv [16:30:30 CET] <gattler> like this? [16:30:55 CET] <c_14> sure [16:31:10 CET] <c_14> 192k is rather low for ac3 though [16:31:25 CET] <gattler> ah ok, what do you suggest? [16:32:03 CET] <Mavrik> well 192k is what you do for stereo mp3 [16:32:07 CET] <Mavrik> not 6 channel audio :) [16:32:29 CET] <c_14> 5.1 AC3 afaik is usually between 400 and 500k [16:32:32 CET] <Mavrik> It's usually 448 or so for 5.1 [16:32:56 CET] <gattler> good to know, thanks [16:33:02 CET] <gattler> Decoder (codec id 94210) not found for input stream #0.3 [16:33:15 CET] <gattler> this is what i get, i guess I need some extra packages [16:33:37 CET] <gattler> can I lookup what "codec id 94210" means? [16:33:41 CET] <c_14> try adding -c copy before -c:a ac3 [16:33:49 CET] <c_14> and maybe -copy_unknown [16:33:56 CET] <c_14> Though I'm not sure why it's trying to decode that. [16:34:13 CET] <gattler> kk [16:39:07 CET] <gattler> c_14: http://pastebin.com/J9gNNb3X [16:39:16 CET] <jkqxz> 94210 = 0x17002 is a text subtitle stream <https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/avcodec.h#L507>. [16:39:27 CET] <c_14> ah [16:39:28 CET] <jkqxz> (So just copy it, as suggested.) [16:39:56 CET] <c_14> gattler: that's an ancient binary from libav, not FFmpeg. try again with a static build [16:39:58 CET] <c_14> http://johnvansickle.com/ffmpeg/ [16:40:02 CET] <gattler> c_14: [16:40:15 CET] <gattler> yeah, I'm on ubuntu 12.04 :P [16:43:54 CET] <gattler> ok, It seems wo work with the static ffmpeg build [16:43:57 CET] <gattler> thanks alot guys [16:44:54 CET] <gattler> Is it normal that it takes alot of time? I was hoping just converting the audio will only take a few minutes [16:45:23 CET] <c_14> it shouldn't take that long. It does have to read and write the whole file so it might depend on your IO though [16:53:13 CET] <gattler> It worked ;) thanks alow again guys [16:53:24 CET] <gattler> *alot.. [17:29:28 CET] <redsPL^GxG> heya [17:29:45 CET] <redsPL^GxG> i've got a compro videomate u900 [17:29:50 CET] <redsPL^GxG> i want to use it on linux [17:30:10 CET] <redsPL^GxG> but i dont know where to start.. dmesg sees that high speed usb device is connected.. [17:30:17 CET] <redsPL^GxG> lsusb says "Compro" [17:30:30 CET] <J_Darnley> What is it? A webcam? [17:31:08 CET] <redsPL^GxG> nope [17:31:17 CET] <redsPL^GxG> that is a analog tv [17:31:18 CET] <redsPL^GxG> tuner [17:31:28 CET] <J_Darnley> Ah [17:31:30 CET] <redsPL^GxG> +composite video input [17:31:36 CET] <redsPL^GxG> and i wanna use that composite video [17:31:55 CET] <J_Darnley> Then I think you need to read about video4linux [17:32:29 CET] <J_Darnley> (I probably would have said that anyway) [18:28:46 CET] <vincentdumont> Hello everyone! I am seeking to help the open source ffmpeg community. I would be glad to contribute to this wonderful project so feel free to visit my website (www.vincentdumont.com) in order to have more information about me. Thank you in advance! [22:22:37 CET] <popara> hello it's possible in the -f segment output format, to specify the segments to be always incremental? [22:22:54 CET] <popara> because i give also the wrap argument and the number is changing back to an old one again [22:24:27 CET] <J_Darnley> How should that work then? [22:24:30 CET] <J_Darnley> An error? [22:25:18 CET] <popara> not an error, nothing. It works fine, just the segment number is not incremental [22:26:57 CET] <furq> what else would you expect wrap to do [22:41:59 CET] <popara> yes for example in the HLS container there is an option to delete old segments [22:42:03 CET] <popara> and keep the number incremental [22:43:00 CET] <J_Darnley> Doesn't sound like "wrap" to me but like "delete old" [22:46:26 CET] <edman007> Hi, how do I set the pixel format with the scale filter? [22:46:31 CET] <furq> weird [22:46:41 CET] <furq> hls has delete_segments but segment doesn't appear to have any equivalent [22:46:53 CET] <furq> i guess you should file a feature request [22:46:56 CET] <edman007> when I use it I get [swscaler @ 0x1e2fe00] deprecated pixel format used, make sure you did set range correctly [Parsed_vidstabtransform_0 @ 0x1e2f500] pixel-format error: bpp 1<>2 chroma_subsampl: w: 1<>1 h: 0<>0 [Parsed_vidstabtransform_0 @ 0x1e2f500] Failed to configure input pad on Parsed_vidstabtransform_0 [22:46:59 CET] <J_Darnley> patches welcome! [22:47:04 CET] <furq> or that [22:47:16 CET] <edman007> and the docs just say you have to give it an integer...where do I get the meanings of the integers? [22:50:43 CET] <J_Darnley> Isn't it the format option? [22:51:00 CET] <furq> edman007: https://github.com/georgmartius/vid.stab/issues/13 [22:52:21 CET] <J_Darnley> oh no, you stick the format filter in afterwards [22:55:07 CET] <edman007> furq, hrm, I can get it to work, but it breaks with the scale filter [22:56:01 CET] <J_Darnley> edman007: can you put the full log on pastebin? [23:02:55 CET] <edman007> http://pastebin.com/FjMg2MpG [23:03:01 CET] <edman007> if I take the scale out of the filter it works [23:04:55 CET] <furq> use pix_fmt yuv444p as an output option [23:13:32 CET] <edman007> ffmpeg -y -pix_fmt yuv444p -framerate 30 -i F%04d-L0-normal.jpg -frames 5 -c:v libx264 -r 30 -vf vidstabtransform=input=transforms.trf:crop=keep:tripod=1:optzoom=0:smoothing=0:zoomspeed=5:debug=0:interpol=no,scale=w=0.75*iw:h=0.75*ih,crop=w=3840:h=2160:y=0 -pix_fmt yuv444p stacked.mp4 [23:13:38 CET] <edman007> like that? because it doesn't work... [23:17:38 CET] <edman007> I think I can get away without video stabilization for now anyways...so I'm probably fine...but it should still work.. [23:21:05 CET] <J_Darnley> Oh shit! I forogt it was an external lib [23:21:43 CET] <J_Darnley> Screw it. I'm not going to debug this anymore for now. [23:25:33 CET] <furq> try removing pix_fmt as an input option [23:26:07 CET] <furq> and/or use -vf format=yuv444p instead of pix_fmt [23:26:43 CET] <furq> presumably before any of the other filters [00:00:00 CET] --- Sun Jan 24 2016

1 0

ffmpeg-devel.log.20160122
by burek 23 Jan '16

23 Jan '16

[00:32:51 CET] <cone-469> ffmpeg 03Andreas Cadhalpun 07master:064963bd2702: build: make out-of-tree builds bit-identical to in-tree builds [00:41:32 CET] <Timothy_Gu> I really wish I could use some of the modern services for web development for FATE. The current file-based not-even-a-database is a pain to manipulate in large numbers [04:39:01 CET] <cone-047> ffmpeg 03Neil Birkbeck 07master:17399f6a9f00: Add missing conversions from side data enum to name [04:39:01 CET] <cone-047> ffmpeg 03John Cox 07master:48f80831bad8: cabac: Ensure 2-byte cabac loads are on 2-byte boundry [04:39:01 CET] <cone-047> ffmpeg 03John Cox 07master:5115d8326e8e: cabac_functions: Count zeros with ctz if it is fast [04:39:01 CET] <cone-047> ffmpeg 03John Cox 07master:74105fc9a3c4: cabac_functions: Allow more functions to be overridden [10:57:18 CET] <durandal_1707> I have idea how to do conditional filter [11:24:39 CET] <cone-711> ffmpeg 03Paul B Mahol 07master:b18467a9433c: avfilter/avf_showwaves: add logarithmic amplitude scaler [12:08:42 CET] <cone-711> ffmpeg 03Paul B Mahol 07master:1c02af307a67: avfilter: add convolution filter [13:12:21 CET] <durandal_1707> please comment streamselect patch [13:14:19 CET] <ubitux> sorry, i will [13:14:47 CET] <ubitux> as usual i'm in a rush on many things, which will calm down pretty soon [13:20:01 CET] <cone-711> ffmpeg 03Michael Niedermayer 07master:70ece6ccd0c3: fate: add 1 and 15BPP rawvideo in avi tests [13:26:46 CET] <Franciman> Hi [13:26:57 CET] <Franciman> What's the difference between avcodec_decode_audio3 and avcodec_decode_audio4 ? [13:28:25 CET] <jermy> The number? [13:29:01 CET] <nevcairiel> 3 is deprecated, 4 is the replacement with a new interface [13:29:09 CET] <Franciman> I see [13:29:18 CET] <jermy> But seriously, it's largely that the former required passing in a pre-allocated buffer of the right size, and the latter returns a AVPacket instead [13:29:56 CET] <jermy> (What size should the buffer have been? A very good question) [13:30:05 CET] <Franciman> I see, ok thank you [14:02:46 CET] <nevcairiel> A year later, still dealing with fallout from "refactoring" [14:06:11 CET] <nevcairiel> I should setup some sort of unit tests to make FATE verify that the struct content of hwaccels doesnt change randomly [14:07:23 CET] <wm4> which refactoring? [14:08:15 CET] <nevcairiel> in this case, this commit http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=a12d3188cbec15e22070e1… [14:09:11 CET] <wm4> oh [14:09:34 CET] <nevcairiel> (its not the first dxva regression this particular patch series caused, but this one took ages to surface, apparenly) [14:10:59 CET] <Franciman> thanks for your help, bye [14:24:34 CET] <jkqxz> wm4: I've updated the VAAPI encode patch to use refcounting on AVFrames/AVBuffers throughout. Thank you for your thoughts on that; the libavutil parts in particular are much more sensible now. [14:25:19 CET] <jkqxz> Unfortunately I seem to have broken something low-level in H.265 encode in the process (segfaults deep in the Intel driver, yay). Hopefully I will be able to fix that and post a new version tomorrow. [14:26:00 CET] <wm4> ok [14:35:50 CET] <BtbN> One could argue that the intel driver is what is broken here. [14:46:50 CET] <jkqxz> The Intel driver is very fun. Oh, you stupidly set some option to a value we don't support? Have a GPU hang. Hopefully the kernel will notice within a few seconds and reset everything. [15:04:44 CET] <cone-711> ffmpeg 03Ganesh Ajjanagadde 07master:89189b1010de: lavc/wma: add av_warn_unused_result to ff_wma_init [15:04:45 CET] <cone-711> ffmpeg 03Ganesh Ajjanagadde 07master:9254e6176c1a: lavc/atrac3plusdsp: change pow(2,x) to exp2f(x) [15:04:46 CET] <cone-711> ffmpeg 03Ganesh Ajjanagadde 07master:cea529dd7f0d: lavc/opus_celt: replace pow(2,x) by exp2f(x) [15:04:47 CET] <cone-711> ffmpeg 03Ganesh Ajjanagadde 07master:1fb5ae44c43d: lavc/wmadec: replace pow by faster functions [15:15:11 CET] <esdwdftty> Make decoding vp9, HEVC on OpenCl CPU + GPU offers a good trade-off http://www.arm.com/zh/files/event/B-2.2014_ARM_Multimedia_Seminar_Ittiam.pdf [15:31:51 CET] <esdwdftty> <rektimus> vp9 @ 200kbps doesnt seem bad [15:31:53 CET] <esdwdftty> <rektimus> for a 340p video [15:32:33 CET] <esdwdftty> i know, i only have on gpu, h264, vc1, mpg2, mpg4. the pdf talks about "Mali" gpu (tablets, smartphones) I showed the idea on the example of Mali: CPU + GPU / Open CL [15:42:23 CET] <cone-711> ffmpeg 03Perette Barella 07master:84110f4f7760: libavformat/tcp.c : add send_buffer_size and recv_buffer_size options [15:59:34 CET] <wm4> durandal_1707: I'm fairly sure libavfilter doesn't support dynamic reconfiguration [15:59:38 CET] <wm4> even if vf_scale pretends to [16:00:08 CET] <wm4> the buffersink filter for one doesn't update its parameters when a change happens [16:00:28 CET] <wm4> and I bet buffersrc (or most other filters) don't support it either [16:02:19 CET] <durandal_1707> w/h change is supported [16:02:57 CET] <wm4> not really [16:04:03 CET] <wm4> or why does buffersink not adjust the input pad parameters? [16:04:16 CET] <durandal_1707> call avfilter_config_links [16:05:55 CET] <wm4> who? [16:07:04 CET] <wm4> bufferink's inputs[0]->w isn't update when I change the width in vf_scale before it [16:08:50 CET] <durandal_1707> vf_scale doesn't call that function [16:09:29 CET] <durandal_1707> but it probably should [16:09:58 CET] <wm4> ??? [16:10:13 CET] <wm4> and such a garbage patch was applied? that's baffling [16:10:29 CET] <wm4> hurrr let's add dynamic reconfiguration without taking any of the design into account? [16:10:31 CET] <durandal_1707> what patch? [16:10:49 CET] <wm4> the one which added size changes to vf_scale by commands [16:11:12 CET] <durandal_1707> ah, you mean when input change [16:13:28 CET] <durandal_1707> some filters are going to be reset, others are intra only so it doesn't matter for them [16:20:07 CET] <durandal_1707> wm4: about design you can ask elenril [16:20:56 CET] <wm4> the buffersink's filter link is not updated, and it returns a frame of the wrong configuration - this is a bug [16:21:26 CET] <wm4> and it seems to be a rather fundamental bug, rather than some oversight in buffersink [16:22:50 CET] <durandal_1707> you mean link w/h is not updated or also AVframe is not? [16:23:05 CET] <wm4> they don't match [16:24:45 CET] <durandal_1707> hmm, let me try something... [16:46:19 CET] <cone-711> ffmpeg 03Michael Niedermayer 07master:ee3eac59df10: fate: Add a small number of rawvideo in mov tests [17:07:16 CET] <Daemon404> almost have it build with clang-cl... [17:11:05 CET] <durandal_1707> wm4: not all links are updated with avfilter_config_links [17:13:04 CET] <durandal_1707> michaelni: crash if input size changes with bunch of video encoders still apply [17:13:37 CET] <wm4> the situation with encoders is similar [17:13:52 CET] <wm4> normally encoders are configured with a width and height before sending the first frame, right? [17:14:07 CET] <wm4> so you just trigger undefined behavior by sending a frame with different configuration [17:24:46 CET] <nevcairiel> Daemon404: i didnt bother yet, its still too limited todaa [17:24:48 CET] <nevcairiel> today* [17:26:58 CET] <wm4> is clang-cl the windows thing? [17:27:38 CET] <nevcairiel> technically its called clang/c2, but i assume thats what he meant [17:28:28 CET] <Daemon404> limited? [17:28:46 CET] <nevcairiel> didnt you read the long list of limitations [17:29:03 CET] <Daemon404> most of that is either: a) debug info b) C++ related [17:29:10 CET] <Daemon404> i dont recall a ton else [17:29:50 CET] <nevcairiel> although there was a new release just two days ago, maybe they fixed a bunch [17:30:13 CET] <michaelni> durandal_1707, how to reproduce that crash ? but most encoders dont support that currently [17:30:53 CET] <nevcairiel> Daemon404: no inline asm yet either =p [17:31:45 CET] <Daemon404> eh? [17:31:50 CET] <Daemon404> i am building with inline asm right now. [17:32:06 CET] <Daemon404> unless it secretly ignores it [17:32:14 CET] <Daemon404> this is SVN trunk [17:33:05 CET] <Daemon404> granted i patched configure and mem.h [17:34:58 CET] <nevcairiel> Daemon404: it said no inline asm in their announcement as a known limitation right now, either it was fixed, or your configure just disables it [17:35:12 CET] <nevcairiel> configure has a check that tries to use it and d isables it if it fails, fwiw [17:35:23 CET] <durandal_1707> michaelni: see patch I just posted [17:35:46 CET] <Daemon404> i checkec config.h [17:35:47 CET] <Daemon404> its enabled [17:37:40 CET] <Daemon404> ah damn... [17:37:41 CET] <Daemon404> libavcodec.a(lpc.o) : error LNK2019: unresolved external symbol pd_1 referenced in function lpc_apply_welch_window_sse2 [17:37:44 CET] <Daemon404> libavcodec.a(lpc.o) : error LNK2019: unresolved external symbol pd_2 referenced in function lpc_apply_welch_window_sse2 [17:37:49 CET] <Daemon404> it looks like it fails at the asm constanta. [17:56:25 CET] <cone-711> ffmpeg 03Paul B Mahol 07master:8a5d4a51fff7: avfilter/vf_convolution: add timeline support [18:15:11 CET] <cone-711> ffmpeg 03Rostislav Pehlivanov 07master:ce855bf43bcb: diracdec: fix full range videos [18:16:27 CET] <atomnuker> well, this opens up a nice niche use case for the encoder: near lossless desktop recording with a 1:5 compression ratio [18:42:20 CET] <Daemon404> nevcairiel, i got inline asm to build. [21:44:42 CET] <cone-711> ffmpeg 03Paul B Mahol 07master:805563c814bf: avfilter/af_ladspa: accepts ' ' as command separator too [22:15:20 CET] <durandal_1707> why there is no API to check number of available frames in sink? [00:00:00 CET] --- Sat Jan 23 2016

1 0

ffmpeg.log.20160122
by burek 23 Jan '16

23 Jan '16

[01:05:44 CET] <rizuk> VLC can pick up the stream from ffmpeg, then redistribute it, acting as a server. Since FFmpeg is at times more efficient than VLC at doing the raw encoding..Can someone tell me how this is done i have ffmpeg stream running over UDP how do i get VLC to stream it to clients [01:06:08 CET] <rizuk> redistribute it over http how? [01:06:28 CET] <Mavrik> Uh. [01:06:36 CET] <Mavrik> Why not use something more stable than VLC as a streaming server? [01:06:51 CET] <Mavrik> There's bunch of streaming servers that can injest ffmpeg output. [01:07:13 CET] <rizuk> because vlc is not as stable and ffmpeg uses less cpu imo [01:07:51 CET] <rizuk> which streaming servers are they [01:07:55 CET] <J_Darnley> I wonder what magic encoder it uses then. [01:08:39 CET] <rizuk> tell me this same settings i use in vlc yet vlc uses more cpu? [01:08:52 CET] <rizuk> FFmpeg same settings as vlc 20 percent less cpu usage [01:11:07 CET] <J_Darnley> I read that backwards. Now I doubly wonder what magic FFmpeg has. [01:11:46 CET] <furq> is it time for me to mention nginx-rtmp again [01:12:18 CET] <rizuk> shame nginx is not http what im after [01:12:46 CET] <furq> why would you stream over http unless you wanted a bad stream [01:12:53 CET] <furq> unless you mean hls in which case nginx-rtmp can do that [01:13:16 CET] <J_Darnley> <furq> why would you stream [01:13:18 CET] <J_Darnley> FTFY [01:14:38 CET] <furq> but how else am i going to monetise myself pretending to react to video games which aren't really that bad [01:18:28 CET] <rizuk> ffserver can do HTTP MPEG-TS output right [01:18:43 CET] <rizuk> only for linux will have to get a vps for it. [01:19:01 CET] <furq> please don't spend any money so that you can use ffserver [01:19:25 CET] <rizuk> it will benefit me not you [01:21:13 CET] <furq> i very much doubt that [02:51:03 CET] <Logicgate> Okay [02:51:11 CET] <Logicgate> So i need someone to help me with the calculations for ffmpeg [02:51:14 CET] <Logicgate> For aspect ratio [02:51:30 CET] <Logicgate> All videos need to end in 720x720 (1:1 ratio) [02:51:47 CET] <Logicgate> And I get videos from all shapes and sizes [02:51:51 CET] <Logicgate> So i need to calculate the padding [02:51:59 CET] <Logicgate> However, I'm not able to figure out what the calculations are. [02:54:30 CET] Action: J_Darnley prays you don't get any anamorphic video [02:57:21 CET] <J_Darnley> pad=w=max(720,in_w),h=max(720,in_h),x=(720-in_w)/2,y=(720-in_h)/2 [02:57:39 CET] <J_Darnley> (plus escaping hell) [03:01:25 CET] <Logicgate> J_Darnley that'll work for *ALL* container sizes? [03:02:15 CET] <J_Darnley> if you scale to fit in 720x720 first, yes (which is what I was writing until you interrupted) [03:02:52 CET] <Logicgate> Lol [03:03:25 CET] <J_Darnley> scale=w=if(gte(1,dar),720,720*dar),h=if(lte(1,dar),720,720*(1/dar)) [03:03:30 CET] <J_Darnley> (I think) [03:03:38 CET] <J_Darnley> (plus escaping hell) [03:04:03 CET] Action: J_Darnley pulls up his terminal [03:04:46 CET] <furq> those commas should be colons [03:05:02 CET] <J_Darnley> oh shit, yes [03:05:03 CET] <furq> the ones outside of brackets, that is [03:05:34 CET] <J_Darnley> and the ones inside need escaping! [03:05:57 CET] <Logicgate> I'll paypal you money if you get me the right formula to pad which ever way it needs to and scale whichever way it needs to [03:06:01 CET] <Logicgate> :) [03:06:29 CET] <J_Darnley> Paypal can get cancer and burn in the fires of hell! [03:06:32 CET] <furq> will you paypal me money if i copy and paste the things J_Darnley just said [03:06:51 CET] <Logicgate> furq, if you pm me and help me. Yes. [03:07:00 CET] <Logicgate> that's if J_Darnley gives up[ [03:07:14 CET] <furq> no i'm pretty sure he just gave you the answer [03:07:17 CET] <J_Darnley> ah! errors! [03:07:20 CET] <furq> or maybe not [03:07:52 CET] <Logicgate> so do I need to fill in the blanks? [03:08:08 CET] <Logicgate> or this is all good to go [03:09:45 CET] <Logicgate> invalid size if(gte(.. [03:10:10 CET] <J_Darnley> where's a link to the fucking syntax when you need one? [03:14:19 CET] Action: J_Darnley wonders if the numerical comarisons support floats [03:17:19 CET] <J_Darnley> WTF is going on here? [03:20:51 CET] Action: J_Darnley facepalms [03:22:55 CET] <Logicgate> I GOT IT J_Darnley [03:23:09 CET] <Logicgate> "scale=iw*min(720/iw\,720/ih):ih*min(720/iw\,720/ih):flags=lanczos,format=yuv420p,pad=720:720:(720-iw*min(720/iw\,720/ih))/2:(720-ih*min(720/iw\,720/ih))/2:black" [03:23:52 CET] Action: J_Darnley points out that that doesn't support anamorphic [03:24:03 CET] <Logicgate> difine anamorphic :( [03:24:13 CET] <J_Darnley> scale=w=if(gte(dar\,1)\,720\,720*dar):h=if(lte(dar\,1)\,720\,720*(1/dar)) [03:24:50 CET] <J_Darnley> 16:9 DVD video has a frame size 720x480 [03:25:01 CET] <J_Darnley> its pixels are not square [03:25:13 CET] <J_Darnley> it must be stretched for correct playback [03:25:46 CET] <Logicgate> Okay so use your scale command? [03:25:49 CET] <Logicgate> w=if(gte(dar\,1)\,720\,720*dar):h=if(lte(dar\,1)\,720\,720*(1/dar)) [03:25:54 CET] <Logicgate> That'll work on everything? [03:26:01 CET] <J_Darnley> I believe so [03:26:22 CET] Action: Logicgate is going to run some tests meow.. [03:26:45 CET] <furq> Logicgate: if you ignore the dar then input videos which don't use a 1:1 dar will end up at the wrong aspect ratio [03:26:59 CET] <furq> or 1:1 par rather [03:27:07 CET] <Logicgate> dar? [03:27:13 CET] <furq> display aspect ratio [03:27:31 CET] <J_Darnley> What blanks? [03:27:39 CET] <J_Darnley> nevermind [03:27:55 CET] <Logicgate> furq, okay so I'm not sure what I'm supposed to do then [03:28:08 CET] <J_Darnley> My scale corrects for that [03:28:15 CET] <furq> ^ [03:28:22 CET] <Logicgate> Awesome [03:29:28 CET] <J_Darnley> If you do want to give money I would say send it to FFmpeg http://ffmpeg.org/donations.html [03:29:44 CET] <furq> J_Darnley: if it makes you feel any better, i've been using megui all day [03:29:52 CET] <furq> so at least you've not had the biggest video-related headache today [03:30:26 CET] <J_Darnley> If anyone was wondering what my problem was: gte(1,dar) vs. gte(dar,1) [03:30:47 CET] <furq> has there ever been a worse example of gui design than megui [03:31:13 CET] <J_Darnley> Every driver utility? [03:31:30 CET] <J_Darnley> Audio drivers in particular [03:31:52 CET] <J_Darnley> Windows 8 and 10? [03:32:10 CET] Action: J_Darnley goes to add his hardwork to the docs. [03:33:24 CET] <furq> http://gadgets.boingboing.net/gimages/razergp6.jpg [03:33:27 CET] <furq> i would rather use that than megui [03:33:47 CET] <furq> although i am at least glad that megui hasn't included any bank gothic [03:33:52 CET] <furq> the worst font in the world [03:34:08 CET] <J_Darnley> Mouse utils! How could I forget those? [03:34:26 CET] <Logicgate> J_Darnley, that will also work for 1:1 ratio video right [03:34:28 CET] <furq> how could you forget razer in any discussion about ugly computer shit [03:34:38 CET] <J_Darnley> :) [03:34:43 CET] <J_Darnley> Logicgate: let me test [03:35:10 CET] <J_Darnley> yes [03:35:34 CET] <J_Darnley> if dar is 1 then the constant 720x720 is used [03:35:51 CET] <Logicgate> the output needs to be 720x720 always [03:36:31 CET] <J_Darnley> and it should be with the right padding [03:36:44 CET] <Logicgate> yes padding seems to be working fine right meow [03:37:37 CET] Action: TD-Linux votes for UIs that literally give people cancer https://en.wikipedia.org/wiki/Therac-25 [03:38:20 CET] <furq> that still sounds better than megui [03:40:11 CET] <Logicgate> J_Darnley, thanks a lot for the help [03:40:15 CET] <Logicgate> I will be donating to FFMpeg [03:40:30 CET] Action: Logicgate bows down to the greatness of J_Darnley and furq [03:41:24 CET] <furq> mostly me though [03:42:51 CET] <J_Darnley> ha ha. why did I do 720*(1/dar) when that's the same as 720/dar? [03:43:05 CET] <Logicgate> lol [03:43:09 CET] <J_Darnley> (too much use of a calculator with rational numbers [03:46:15 CET] <Logicgate> J_Darnley, so I should switch that [03:46:17 CET] <Logicgate> to make it prettier [03:46:32 CET] <J_Darnley> If you like [04:45:57 CET] <saranshsrivastav> Hello [04:46:45 CET] <saranshsrivastav> I am building a precompiled ffmpeg binary for android [04:47:02 CET] <saranshsrivastav> But it is giving an error of PIE failure [04:47:31 CET] <saranshsrivastav> Error: only position independent executables are supported [04:47:46 CET] <saranshsrivastav> Anybody has a knowledge about it? [04:47:54 CET] <saranshsrivastav> Arch=arm [05:36:16 CET] <SeanM_> Hi [08:39:05 CET] <esdwdftty> AMD CPUX2 3394Hz have commands: SSE 4.1, 4.2, SSE 4A. GPU no have decode vp9, H264 yes. [08:39:05 CET] <esdwdftty> Uses the vp9 decoder for these commands? If not then maybe they will give some performance gains on the CPU? [08:44:39 CET] <esdwdftty> vp9 decoder ffmpeg [08:51:56 CET] <TD-Linux> esdwdftty, ffmpeg's vp9 decoder already uses those instructions automatically. [08:53:16 CET] <esdwdftty> ok [08:58:34 CET] <esdwdftty> To decode vp9 need a new GPU architecture or it can implement on the new version of the GPU driver? [09:01:03 CET] <esdwdftty> 4k HEVC, CPU 2-5 fps [09:03:54 CET] <esdwdftty> vp9 1080p60 56-70% cpu, 4k HEVC, CPU 2-5 fps 98-100% cpu, me not need 4k [09:05:09 CET] <esdwdftty> vp9 1080p60 an average of 60% [09:12:21 CET] <esdwdftty> H264 1080p60 48-70% cpu average of 60% [09:14:56 CET] <explodes_> I'm using ffmpeg through the JNI, I cannot figure out why ffmpeg is requesting to seek ~48 bytes away from the end of the file [09:15:29 CET] <explodes_> correction: 32498 bytes from the end of the file [09:22:23 CET] <explodes_> I also get a request to seek 1 byte away from the end of the file: SEEK_END offset=-1 [09:23:00 CET] <explodes_> Not sure if SEEK_END is a variable actually used in the FFMpeg circle but it is a value defined for the jni callback to seek to relative offset from the end of the file [09:26:59 CET] <esdwdftty> 4k HEVC 25 frames, CPU 2-5 fps 98-100% cpu [09:32:50 CET] <otopolsky_> hi, can someone tell me what could possibly mean when avcodec_encode_audio2 returned -22 Invalid argument? [10:18:59 CET] <zylthinking> I am writing 2 streams using ffmpeg to mp4, the stream comes from network. So it is possible that I have lots of stream 1 while stream 2 nothing. My question is can I write the stream 1 even the stream 1s pts is larger than stream 2 pts [10:20:02 CET] <zylthinking> e.g. I have stream 1s pts 10000000, while, stream 2s pts 10, then can I write stream 1 to 10000000 before I write stream 2? [10:20:44 CET] <zylthinking> stream 1 and stream 2 need sync with pts when playing [10:21:49 CET] <zylthinking> e.g. I have stream 1s pts 10000000, while, stream 2s pts 10, then can I write stream 1 to 10000000 before I write stream 2 with pts 11? [10:23:29 CET] <zylthinking> or I have to wait stream 2 before I write stream 1 with pts > 10? [10:26:57 CET] <Mavrik> First of all, your streams should really have the same timebase. [10:27:15 CET] <Mavrik> Second of all, while PTS may differ between streams, a too large of a drift will make the file unplayable on most players. [10:27:29 CET] <Mavrik> (Where a lot of players will choke even on a 1 sec difference) [10:30:52 CET] <termos> Is it possible to create an mp4 file that I can read while writing to? I get these moov atom issues since it's written in the end [10:31:19 CET] <zylthinking> the streams have same timebase [10:37:04 CET] <zylthinking> Mavrik, which the PTS may differ between streams means? I have the streams with pts of everything OK, only that I may write lots of video frames before writing any audio frame, then when I have any audio packet to write, there is a big gap between the audio pts with the last writen video pts [10:53:43 CET] <Mavrik> termos, segmented I guess, but if you have that use-case MP4 is not a container to use. [10:54:00 CET] <Mavrik> zylthinking, yes, that will break a lot of players. [10:54:07 CET] <Mavrik> A/V should be as interleaved as possible. [10:54:30 CET] <zylthinking> : Mavrik thanks [10:54:33 CET] <Mavrik> Since players won't load whole MP4 file to memory just to find matching audio packet to go with video it's trying to play. [10:54:56 CET] <Mavrik> They usually buffer a short amount (depending on implementation) and will break hard if the matching packets for streams aren't found. [10:55:01 CET] <Mavrik> Or will just play without audio or video. [11:10:54 CET] <zylthinking> another question, can mp4 contain more than one video stream? [12:05:52 CET] <jcalonso> Hello, Im using ffmpeg and ffserver to stream video coming from a dvr, it works fine for some seconds but then the video freeze and sometimes it able to continue if I stop and play again (vlc), sometimes i neec to stop ffmpef y start over again, any ideas? [12:06:23 CET] <jcalonso> i can paste the full command if that helps [12:07:51 CET] <waressearcher2> jcalonso: hallo und herzlich willkommen [13:27:01 CET] <spaam> waressearcher2: nemen tack så mycket! [15:08:32 CET] <esdwdftty> Make decoding vp9, HEVC on OpenCl CPU + GPU offers a good trade-off http://www.arm.com/zh/files/event/B-2.2014_ARM_Multimedia_Seminar_Ittiam.pdf [15:18:03 CET] <rektimus> vp9 @ 200kbps doesnt seem bad [15:18:05 CET] <rektimus> for a 340p video [15:25:10 CET] <esdwdftty> i know, i only have on gpu, h264, vc1, mpg2, mpg4. the pdf talks about "Mali" gpu (tablets, smartphones) I showed the idea on the example of Mali: CPU + GPU / [15:25:11 CET] <esdwdftty> Open CL [20:45:43 CET] <explodes_> Is it current during stream load to have ffmpeg read the end of the video file? (mp4, if that makes a difference) [20:47:12 CET] <c_14> yes [20:47:17 CET] <c_14> that's where the moov atom (usually) is [20:48:47 CET] <BtbN> you can't stream mp4, if that's what you're asking. [20:51:02 CET] <kepstin> explodes_: if you're pre-encoding file for http streaming, you can use the "-movflags faststart" ffmpeg option or qt-faststart tool to move the moov to the start of the file, which should speed up loading over http. [20:51:33 CET] <explodes_> I'm using c api to decode a local file [20:52:19 CET] <explodes_> but c_14 gave me the expected answer. do I need to reset my stream's position to 0 or will the seek callback function be provided with the absolute position? [20:52:26 CET] <explodes_> (after load) [20:56:16 CET] <explodes_> one of my video files comes out scrambled. all of them crash after about 1 second (it seems that the 'loaded' 262Kb are the only ones properly rendered, then I get a crash during the next read callback) [20:56:33 CET] <kepstin> explodes_: the callback should be passed an argument for that, I think? if you get SEEK_SET it's an absolute position, SEEK_CUR is relative? [20:57:08 CET] <explodes_> yea, i am getting those: AVSEEK or SEEK_SET or SEEK_END too [20:57:21 CET] <explodes_> with reasonable offsets as well. [20:57:35 CET] <explodes_> I'm not sure why my code crashes: the stack trace is messy [21:36:35 CET] <explodes_> This is the stack trace: http://pastebin.com/5DGDfhmn [21:46:07 CET] <jkqxz> ReadFunc is the native callback attached to lavf, which tries to call back to your Java code but somehow the place it's calling back to is invalid? [21:50:20 CET] <jkqxz> If that worked for a few calls and then stopped, maybe you've lost all references to the object containing the callback and it's been garbage collected? [23:05:34 CET] <skywalker> Hello [23:06:05 CET] <skywalker> I am building a precompiled executable of ffmpeg for an android project [23:09:08 CET] <skywalker> And i want to build with x264 vcodec [23:09:32 CET] <skywalker> In arm architecture [23:10:05 CET] <skywalker> The problem is : vcodec x264 is building for x86 architecture [23:11:05 CET] <skywalker> Does anyone know how to build ffmpeg precompiled executable with x264 codec for ARM architecture? [23:11:21 CET] <Logicgate> skywalker, this might help: http://forum.synology.com/enu/viewtopic.php?t=64609 [23:12:13 CET] <J_Darnley> > --disable-asm [23:12:22 CET] <J_Darnley> Are these ARM people retarded? [23:12:37 CET] <J_Darnley> (yes, they're trying to use x264 on AMR) [23:14:09 CET] <Logicgate> lol [23:14:22 CET] <Logicgate> J_Darnley, seems as if the channel is flooded with people trying to accomplish the samething [23:14:27 CET] <Logicgate> should make an off channel #ffmpeg-arm [23:15:01 CET] <skywalker> @Logicgate, bdw i solved yesterday's problem of PIE [23:15:55 CET] <skywalker> By configuring cflag with -fPIE and ldflag with -pie [23:16:00 CET] Action: J_Darnley is going to get kicked again at this rate [23:17:16 CET] <furq> it's ok i'm sure you'll find some other place to talk shit [23:18:17 CET] <Logicgate> J_Darnley, I like your style though. That's how I operate my company [23:18:25 CET] <Logicgate> People with hurt feelings get fired [23:19:04 CET] <skywalker> Lol [23:19:28 CET] <Logicgate> I got no time for feelings lol [23:27:05 CET] <skywalker> The link looks promising. But i want to build it for licence version 2.1. I hope that won't be a problem [23:27:18 CET] <skywalker> I will try that in the morning. I wasn't expecting such a quick reply, lol [00:00:00 CET] --- Sat Jan 23 2016

1 0

ffmpeg-devel.log.20160121
by burek 22 Jan '16

22 Jan '16

[00:09:38 CET] <TD-Linux> ffmpeg doesn't detect a tty to enable color? [00:10:44 CET] <drv> script probably uses a pty [00:12:31 CET] <J_Darnley> ffmpeg does check stderr [00:12:58 CET] <J_Darnley> (see libavutil/log.c:125) [00:57:52 CET] <cone-880> ffmpeg 03Michael Niedermayer 07master:a53fbda9dc92: avcodec/mpeg12enc: Move high resolution thread check to before initializing threads [02:59:11 CET] <cone-880> ffmpeg 03Michael Niedermayer 07master:19e456d48c90: avcodec/wmaenc: Check ff_wma_init() for failure [02:59:12 CET] <cone-880> ffmpeg 03Michael Niedermayer 07master:41e07390e04c: avformat/avformat: Replace some references to filenames by urls [03:37:21 CET] <cone-880> ffmpeg 03Carl Eugen Hoyos 07master:7158ce778f82: lavf/nut: Add forgotten fourccs for YUV4xxP9. [03:40:30 CET] <cone-880> ffmpeg 03Carl Eugen Hoyos 07master:4f9314ed5835: lavf/riff: Support reading vlc's rawvideo fourccs. [04:49:54 CET] <cone-880> ffmpeg 03James Almer 07master:8bbb9723508b: configure: add missing library deps for showcqt_filter [08:01:24 CET] <cone-890> ffmpeg 03Claudio Freire 07master:adc7d2a4ce8f: AAC encoder: check for NaNs/inf in TNS gain [10:53:32 CET] <durandal_1707> can I get feedback for showwaves patch? [13:19:27 CET] <cone-469> ffmpeg 03Michael Niedermayer 07master:56c182c4d716: avformat/nutenc: implement deinit() [13:38:23 CET] <BBB> michaelni: ffmpeg -i fate-date/sgi/lena_rgb48.sgi -i fate-data/sgi/lena_rgb48.sgi -lavfi '[0:v]format=gbrp16le[out1];[1:v]format=gbrp16le[out2];[out1][out2]psnr' -f null -nostats - gives me: Impossible to convert between the formats supported by the filter 'graph 0 input from stream 0:0' and the filter 'auto-inserted scaler 0' [13:38:26 CET] <BBB> michaelni: why? [13:40:59 CET] <wm4> missing swscale support? [13:41:56 CET] <BBB> configuration: --enable-gpl --samples=fate-data --enable-libvpx --enable-libx264 [13:42:01 CET] <BBB> doesnt look like it [13:46:07 CET] <wm4> I mean, conversion to gbrp16 is probably not supported by swscale [13:46:26 CET] <wm4> [AV_PIX_FMT_GBRP16LE] = { 1, 0 }, [13:46:28 CET] <wm4> yeah [13:47:59 CET] <michaelni> yes, thats likely the reason [13:50:05 CET] <kierank> why is the order of those GBR? [13:50:20 CET] <kierank> cineform uses that too [13:51:19 CET] <michaelni> btw my fate clients are all down (incompetent electricans in the house) ill start them again once they are gone [13:51:19 CET] <wm4> (good question) [13:52:45 CET] <BBB> wm4: ah, I see, ok [13:52:57 CET] <BBB> kierank: its for h264 and related formats [13:53:37 CET] <BBB> kierank: rgb colorspace is coded in planar gbr order [13:53:55 CET] <BBB> kierank: so this way the decoder needs no special case channel order handling for rgb [13:54:29 CET] <wm4> but why does h264 do this? [13:54:35 CET] <kierank> subsampling [13:54:47 CET] <kierank> makes no sense for no subsampled formats like cineform though [13:55:28 CET] <wm4> I don't think we allow subsampled rgb output either [14:07:24 CET] <BBB> what do you mean why does it do this? [14:07:31 CET] <BBB> it decodes planar data into plane 0, 1 and 2 [14:07:39 CET] <BBB> plane 1 is y/g, 1=cb/b, 2=cr/r [14:07:45 CET] <BBB> it does what the bitstream dictates [14:07:47 CET] <BBB> brb [14:08:54 CET] <wm4> yeah, but cr still doesn't have much to do with r [14:31:55 CET] <cone-469> ffmpeg 03Paul B Mahol 07master:fa04ec728da3: avfilter: add afftfilter [14:38:44 CET] <nevcairiel> does the order of the components really matter? planar rgb is uncommon enough as it is, its not like another planar rgb format is more popular or anything :D [14:48:10 CET] <cone-469> ffmpeg 03Paul B Mahol 07master:73c938dd9f3b: doc/filters: fix afftfilt example [14:53:47 CET] <J_Darnley> I thought it was gbr because g made the most sense to put into the luma plane and retain the most quality. [14:54:32 CET] <J_Darnley> Make me wonder though. How far back does it go? Was h264 the first? [15:08:19 CET] <kierank> nevcairiel: it matters because my way of figuring out the component order of cineform is just to change the ordering until it looks right [15:17:45 CET] <JEEB> was aresample=async=1 still a special case? [15:18:38 CET] <durandal_1707> what for? [15:20:30 CET] <JEEB> I just remember it being useful with broken or otherwise non-monotonically rising tiemstamps [15:22:16 CET] <JEEB> I think it was the one that didn't limit the amount of emptiness that it should pad [15:24:31 CET] <jkqxz> G as "first" component of RGB has been around forever - consider component video and sync-on-green. Not sure when that got transposed into video formats in-memory, but it totally makes sense than G ends up first there (use identical hardware setup for YPbCr and GBR planes). [15:48:41 CET] <cone-469> ffmpeg 03Rostislav Pehlivanov 07master:8248b51e0b94: diracdec: add support for 12 bit videos [16:04:56 CET] <cone-469> ffmpeg 03Michael Niedermayer 07master:b65efbc0f419: avcodec/mpegvideo_enc: Check for integer overflow in ff_mpv_reallocate_putbitbuffer() [16:07:46 CET] <durandal_1707> come on, try and comment patches [16:16:31 CET] <BBB> which one& streamselect? [16:18:04 CET] <durandal_1707> showwaves [16:21:15 CET] <cone-469> ffmpeg 03Rostislav Pehlivanov 07master:a849ebb54e18: dirac_parser: Improve parsing and silence pointless warnings [16:24:28 CET] <BBB> durandal_1707: the colors one? thats pretty minor, lgtm [16:25:55 CET] <cone-469> ffmpeg 03Ronald S. Bultje 07master:8c9103c4aff4: checkasm: add videodsp emulated_edge_mc test. [16:26:04 CET] <durandal_1707> no, you are supposed to try it and tell how much it is awesome [16:27:08 CET] <durandal_1707> it major thing like color tv [16:28:44 CET] <BBB> how do I test it? [16:28:54 CET] <BBB> ffmpeg -i file.mp3 -lavfi showwaves -f null - ? [16:29:45 CET] <BBB> ffplay file.mp3 -vf showwaves also doesnt work [16:31:03 CET] <durandal_1707> ffmpeg and pipe [16:31:15 CET] <cone-469> ffmpeg 03Rostislav Pehlivanov 07master:7d8891593c28: dirac_parser: add exceptions for Dirac inter parse codes [16:32:20 CET] <BBB> pipe what? [16:33:37 CET] <BBB> I dont even see a video stream in the ffmpeg output [16:34:12 CET] <atomnuker> I usually use "ffmpeg -i file.mp3 -filter_complex <FILTER> -strict -2 -f yuv4mpegpipe - | mpv -" [16:35:05 CET] <BBB> Output file #0 does not contain any stream [16:35:21 CET] <BBB> ah, -vf vs -lavfi [16:35:23 CET] <BBB> so complicated [16:35:24 CET] <wm4> hm I should get back to implementing "complex" filter support in mpv [16:36:04 CET] <BBB> how do I get this to work in ffplay? [16:36:11 CET] <BBB> I mean, video without audio is kind of & researchy [16:36:44 CET] <wm4> ffplay apparently doesn't have "complex" filter support either [16:37:22 CET] <BBB> right [16:37:28 CET] <BBB> Im doing the worst I can think of here [16:37:42 CET] <BBB> -f nut [16:37:53 CET] <BBB> with -c:v rawvideo -c:a pcm_s16le [16:37:58 CET] <BBB> and then pipe into ffplay [16:37:59 CET] <BBB> that works [16:38:09 CET] <BBB> I suppose ffm would work also [16:38:21 CET] <BBB> yeah ffm is fine also [16:38:30 CET] <BBB> so now I have to test the patch? [16:41:07 CET] <durandal_1707> yes [16:41:26 CET] <BBB> it doesnt work [16:41:32 CET] <BBB> if I say colors=orange, I get something whiteish [16:41:38 CET] <BBB> if I do the default, its brown [16:41:54 CET] <BBB> blue gives me very light blue [16:42:06 CET] <BBB> red gives me pink [16:44:23 CET] <durandal_1707> BBB: how many channels have audio? [16:45:03 CET] <BBB> 2? [16:47:08 CET] <durandal_1707> BBB: put two colors: pinkŠcyan [16:48:48 CET] <BBB> ah, ok, now it makes sense [16:49:06 CET] <BBB> (it also helps to select a audio file where left/right are not identical copies or nearly-so) [16:49:19 CET] Action: BBB pats durandal_1707 on the back - good job dude! [16:50:55 CET] <BBB> so, whos gonna hook this up in ffplay so ffplay -vis showwaves file.mp3 does this? [16:51:19 CET] <durandal_1707> Original code used only gray and changed brightness if multiple channels where [16:51:29 CET] <durandal_1707> present [16:51:29 CET] <BBB> (as opposed to ffmpeg -i file.mp3 -lavfi showwaves -f nut - | ffplay -) [16:51:54 CET] <BBB> or -f ffm, or whatever [16:52:19 CET] <BBB> and then -c:v rawvideo -c:a pcm_s16le or whatever because by default itll compress to mp2/mpegvideo, I AM NOT KIDDING YOU [16:52:49 CET] <durandal_1707> BBB: well adding visualization should be easy, ffplay already have some code but general filter complex is harder [16:55:32 CET] <jamrial> atomnuker: mind if i also replace av_clip with av_clip_uintp2 for the 12bit function you just added as part of the 10bit patch you reviewed? [16:57:40 CET] <atomnuker> jamrial: sure, go ahead, sorry you had to rebase [16:58:20 CET] <BBB> durandal_1707: patch still fine btw [17:19:33 CET] <cone-469> ffmpeg 03James Almer 07master:033e7dbd31c5: avcodec/diracdsp: use av_clip_uintp2 [17:27:31 CET] <ubitux> jamrial: you can do better templating for these [17:28:00 CET] <ubitux> http://blog.pkh.me/p/20-templating-in-c.html "Mixing full functions mechanism and macros" [17:29:10 CET] <ubitux> it should still be considered constant [17:31:13 CET] <jamrial> well, i used the same kind of template as other dsp functions in this file [17:31:55 CET] <ubitux> ok :) [17:35:36 CET] <[1]merlink> Is there any possibility to set decklink output cards to interlaced? [17:49:54 CET] <cone-469> ffmpeg 03Rostislav Pehlivanov 07master:053900ca4c72: dirac: add more parse codes from the specifications [17:49:55 CET] <cone-469> ffmpeg 03Rostislav Pehlivanov 07master:5776344a7bc9: diracdec: fix original Dirac Low Delay profile [17:59:28 CET] <atomnuker> I have a Dirac Low Delay sample here, would be nice to get that into the samples repo to add a test [18:00:44 CET] <atomnuker> who did I need to talk to/send email to do that? [18:05:09 CET] <BBB> atomnuker: if all else fails, ask michael :-p [19:27:47 CET] <cone-469> ffmpeg 03Michael Niedermayer 07master:1dd11160eafb: fate: Add test for colorkey [19:59:14 CET] <jamrial> nice, new dca patchset [20:18:58 CET] <Gramner> BBB: are you ok with the updated "x86inc: Preserve arguments when allocating stack space" patch? [20:20:23 CET] <BBB> yes [20:20:29 CET] <BBB> ty [20:40:16 CET] <Gramner> great, I'll push it later today then [20:47:41 CET] <durandal_1707> michaelni: why colorkey test have audio? [20:49:07 CET] <cone-469> ffmpeg 03Paul B Mahol 07master:6ed3a10f644b: avfilter/avf_showwaves: color support [20:49:43 CET] <michaelni> does it cause a problem ? i didnt think about it but its more "real world" with audio [20:51:30 CET] <cone-469> ffmpeg 03James Almer 07master:a2e1b6646079: x86/intmath: disable sse av_clip functions when using ICC [20:59:01 CET] <durandal_1707> michaelni: nope, its just strange [21:03:36 CET] <michaelni> i think we should maybe have more real world tests [23:36:15 CET] <cone-469> ffmpeg 03Henrik Gramner 07master:6cbd0fdf2859: x86inc: Be more verbose in assertion failures [23:36:16 CET] <cone-469> ffmpeg 03Henrik Gramner 07master:b1496008ee17: x86inc: Improve FMA instruction handling [23:36:17 CET] <cone-469> ffmpeg 03Henrik Gramner 07master:dfe771dc5a09: x86inc: Preserve arguments when allocating stack space [23:36:18 CET] <cone-469> ffmpeg 03Henrik Gramner 07master:2d60b18cf082: x86inc: Use more consistent indentation [23:36:19 CET] <cone-469> ffmpeg 03Henrik Gramner 07master:87b587d4fe91: x86inc: Simplify AUTO_REP_RET [23:36:20 CET] <cone-469> ffmpeg 03Henrik Gramner 07master:d3662777e070: x86inc: Avoid creating unnecessary local labels [23:36:21 CET] <cone-469> ffmpeg 03Geza Lore 07master:d39c229e54d6: x86inc: Add debug symbols indicating sizes of compiled functions [23:58:31 CET] <cone-469> ffmpeg 03Michael Niedermayer 07master:509c9e74e548: avcodec/mjpegdec: Check for end for both bytes in unescaping [00:00:00 CET] --- Fri Jan 22 2016

1 0

ffmpeg.log.20160121
by burek 22 Jan '16

22 Jan '16

[02:52:21 CET] <k_sze[work]> Just me or `-f rawvideo -y /dev/null` as output is faster than `-f null -y /dev/null`? [02:52:56 CET] <rektimus> -sn strips subs right? [02:53:32 CET] <rektimus> does rawvideo create a buffer? [03:01:08 CET] <rektimus> sweet didnt even need to strip subs [03:26:52 CET] <DHE> k_sze[work]: -f null is fast if you add "-c copy" [10:21:23 CET] <Maz0m> Hello, I'm trying to encode a file to webm VP9 / OGG. I'm using the ffmpeg--78077-g5989 binary from evermeet (El Capitan 10.11.3) but it only uses one core. Here is the command I used : http://pastebin.com/raw/eHzQXDzz Where am I suppose to enter the -threads option ? before -input ? or after ? I tried both, it doesn't change anything. [10:22:04 CET] <c_14> before the output file [10:22:11 CET] <c_14> the way you have it right now should fail outright [10:22:45 CET] <c_14> And I think for vp9 threading you need to set at least -tile-columns [10:24:18 CET] <Maz0m> Alright, I'll try that [10:25:54 CET] <AreaScout> hi all, is the 'decoder_ctx->flags2 |= CODEC_FLAG2_FAST' flag still used or not ? [10:26:27 CET] <AreaScout> or better say, does it change something or is it useless ? [10:26:41 CET] <Maz0m> c_14 well, same thing, it still use one core only [10:33:42 CET] <c_14> Hmm, no idea. [10:35:06 CET] <Maz0m> No prob, could you tell me if the command is correct though ? http://pastebin.com/raw/dFa0YUfW thanks [10:45:06 CET] <c_14> looks fine, except for maybe the qmin and qmax [11:12:00 CET] <jkqxz> Tiles in VP9 are at least 256 pixels wide, so there is at most 2x gain to be had with that resolution (the number you give is log2(number of tile columns), anyway). There is also -frame-parallel to try if you want. [16:25:43 CET] <mrAZ> Hello, changing aspect in one file - does it exist? Is that normal that somebody is asking me to produce that? [16:27:31 CET] <DHE> aspect ratio? it can be done, but it might require a transcode to do it depending on the file formats involved, etc [16:29:58 CET] <mrAZ> DHE: are you sure? one file with switching aspect several times from 16:9 tp 4:3 and back? [16:33:04 CET] <jkqxz> Is it the resolution of the stream changing, or just the shape of the pixels? [16:34:48 CET] <jkqxz> WRT it being normal, it's a common thing on broadcast video channels as they switch between different content. [16:40:56 CET] <DHE> I don't know that you can do that so easily. may need to concatenate several files together or just stretch/skew them to a common encoder resolution (ie: letterbox/pillar the videos) [16:42:41 CET] <YamakasY> hi guys, when I do a -vcodec copy -acodec copy are the copy ones temp file names or not ? [16:43:19 CET] <J_Darnley> What? [16:43:59 CET] <J_Darnley> "copy" is a special case for choosing what "encoder" is used. [16:44:07 CET] <YamakasY> I need to convert from flv to mp4 so the params above are best it seems, but is copy temp filename between the codev conversion ? [16:44:12 CET] <YamakasY> ahj ok [16:44:19 CET] <mrAZ> DHE: i tried to make two files with different aspect and cat them together. If it is transport stream with mpeg2video. it works. thanks. [16:44:37 CET] <YamakasY> J_Darnley: but that is best for quality it seems ? [16:44:51 CET] <J_Darnley> It is a copy [16:44:55 CET] <J_Darnley> copy [16:46:48 CET] <YamakasY> J_Darnley: best for quality ? it's a repackage I think ? [16:47:36 CET] <furq> it remuxes the existing streams into a new container [16:47:46 CET] <furq> also you can use -c copy instead of specifying both [16:50:27 CET] <YamakasY> okay both are default -c copy ? [16:51:01 CET] <J_Darnley> No. That is not what he said. [16:51:23 CET] <YamakasY> J_Darnley: no but that is what I make out of it ? [16:51:48 CET] <J_Darnley> Is that a question? [16:51:56 CET] <YamakasY> yes [16:52:07 CET] Action: J_Darnley doesn't think it looks like one. [16:52:14 CET] <J_Darnley> No the default is not "copy" [16:52:18 CET] <YamakasY> I mean... questionable statement :) [16:52:54 CET] <J_Darnley> The default depends on what output format you use and what encoders are available. [16:53:08 CET] <J_Darnley> If you want to copy then use "copy" [16:53:11 CET] <YamakasY> I can install what I want I just want best quality left [16:53:18 CET] <J_Darnley> If you want to copy then use "copy" [16:53:34 CET] Last message repeated 1 time(s). [16:53:34 CET] <YamakasY> ok [16:53:38 CET] <YamakasY> merci [16:54:34 CET] <merlink> Anybody worked with decklink output of FFMPEG? [20:03:51 CET] <Logicgate> hey guys, is there a way to automatically calculate side to side padding? [20:04:02 CET] <Logicgate> I'm having problems coming up with the formula [20:05:27 CET] <Logicgate> example, I want to encode a 568x320 video into a 480x480 container [20:05:35 CET] <Logicgate> and pad the sides [20:05:53 CET] <Logicgate> Do I *have* to pass the side to side padding parameters? Or can ffmpeg do it automatically [20:09:25 CET] <J_Darnley> Yes and yes. [20:09:34 CET] <J_Darnley> Use an expression. [20:09:51 CET] <J_Darnley> They are ugly as hell but they'll work. [20:10:12 CET] <Logicgate> What I thought, :( [20:22:02 CET] <t4nk470> Hey, I was just wondering if there is a way to flatten all audio tracks in the input file into just one in the output file? [20:22:20 CET] <t4nk470> Without knowing how many audio tracks there are in the input file [20:28:36 CET] <saranshsrivastav> ##limechat [20:28:59 CET] <J_Darnley> yes? [20:29:15 CET] <saranshsrivastav> Hello, I am developing a static library for android using ffmpeg [20:29:26 CET] <saranshsrivastav> and i am facing an PIE error [20:29:43 CET] <saranshsrivastav> I think it is due to Lollipop version of android [20:29:50 CET] <saranshsrivastav> but i couldnt get any leads [20:29:52 CET] <J_Darnley> What? If you need more pies go and make or buy some. [20:30:10 CET] <saranshsrivastav> Lol [20:31:52 CET] <saranshsrivastav> PIE - Position independent executables [20:31:57 CET] <J_Darnley> wikipedia suggests you might mean "position independant executable" [20:32:06 CET] <J_Darnley> /snap [20:32:18 CET] <J_Darnley> Is that on x86? [20:32:27 CET] <saranshsrivastav> no it is on ARM [20:33:23 CET] <saranshsrivastav> The following is the error: error: only position independent executables (PIE) are supported. [20:34:13 CET] <J_Darnley> Wait for somone who knows or cares about arm to come along. [20:34:27 CET] <saranshsrivastav> surely, thanks anyways :) [20:39:46 CET] <Logicgate> saranshsrivastav, since ffmpeg is open source, you're lucky. [20:39:59 CET] <Logicgate> You'll need to modify the source code to make it a PIE executable [20:40:04 CET] <Logicgate> That's going to be a ton of work [20:40:16 CET] <Logicgate> And then need to recompile [20:40:29 CET] <saranshsrivastav> I was hoping that I will have to add some flags to make it PIE compatible [20:40:36 CET] <Logicgate> http://stackoverflow.com/questions/13061086/building-ffmpeg-library-for-ios… [20:40:45 CET] <Logicgate> here something that might help [20:41:20 CET] <saranshsrivastav> checking.. [20:41:37 CET] <Logicgate> That's for iOS, but it's still related to ARM architecture [20:41:42 CET] <Logicgate> Which should work for your issue [20:45:32 CET] <saranshsrivastav> I think the problem is not in the ARM architecture but because of android lollipop [20:46:45 CET] <saranshsrivastav> I have already '--enable-pic' [20:49:20 CET] <Logicgate> saranshsrivastav, you need to make it a PIE executable [20:49:21 CET] <saranshsrivastav> This is the closest answer I have got till now for my problem : http://stackoverflow.com/questions/30498776/position-independent-executable… [20:49:28 CET] <Logicgate> Which is what is described on the SO post [20:49:31 CET] <jkqxz> Has it told you what files you build are not position-independent? You could try adding '--disable-asm' and if that fixes it (though that probably isn't a good idea to use, it hopefully helps in fixing the problem). [20:50:42 CET] <saranshsrivastav> The log cannot tell me the exact files because I am using a precompiled binary of ffmpeg for android [20:50:52 CET] <Logicgate> saranshsrivastav, lol [20:51:00 CET] <Logicgate> Like I said, you'll need to recompile yourself. [20:51:12 CET] <Logicgate> So you know exactly what goes into your package [20:51:19 CET] <Logicgate> Don't expect precompiled bins to work for you [20:51:49 CET] <saranshsrivastav> I am not sure about all the flags [20:52:04 CET] <Logicgate> Well, do your research [20:52:05 CET] <Logicgate> Ask here [20:52:09 CET] <Logicgate> ask on stack overflow [20:55:42 CET] <jkqxz> If we assume that the precompiled library you have can work (definitely not a given, but assume), then the problem is likely that something on your side is not compiled with -fpic or not linked with -fpie. Are you sure that /every single other file/ compiled has those flags set? [20:58:31 CET] <saran> I'm not sure...i pass as an argument cflag = -fpic & -fpie along with ./configure when i build the executable [21:01:32 CET] <saran> Which i suppose sets the executable as pie enabled [21:02:04 CET] <saran> Right? [00:00:00 CET] --- Fri Jan 22 2016

1 0