Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

April 2018

1 participants
60 discussions

ffmpeg-devel.log.20180429
by burek 30 Apr '18

30 Apr '18

[00:13:34 CEST] <durandal_1707> ubitux: fixed also TODO in fieldmatch [00:14:41 CEST] <durandal_1707> and learned new thing about lavfi and referencing supported pixel formats in query formats [00:16:28 CEST] <durandal_1707> also fixed leaks spotted [02:53:01 CEST] <kierank> atomnuker: do you think in vc2enc we could do some ratecontrol across a row of slices [03:14:42 CEST] <atomnuker> kierank: yeah, no point in doing something complicated if you've got a limit on the max cost per slice (bitrate/slice_nb) [03:15:00 CEST] <atomnuker> what you should do is just have a single lambda value and treat each slice as if its a new frame [03:15:37 CEST] <atomnuker> do some basic rdo, where you measure the distortion of the slice and its cost, mult them, mult that by the lambda [03:16:27 CEST] <atomnuker> since you approximately know how much distortion you'll gain/lose if you change the quant you can just make some basic per-qp weights [03:16:57 CEST] <atomnuker> so you can save time and do just 1 or 2 distortion/cost calculations per slice [03:17:50 CEST] <atomnuker> by just interpolating with the weights (and you'll probably need to work the energy of the slice in there somehow since the curves will change depending on the energy of the slice) [03:18:25 CEST] <kierank> hmmm ok [03:19:07 CEST] <kierank> when we get it all working I'll ask jdarnley to look at that or do it myself [03:19:20 CEST] <kierank> I'd like to do AQ across a row of slices [03:19:26 CEST] <kierank> because the whole fixed slice size thing is dumb [03:19:30 CEST] <atomnuker> well that pretty much does that [03:20:16 CEST] <atomnuker> since you can't get away with just a single qp per slice in vc2 unless you want hardware encoder-tier quality [03:21:06 CEST] <atomnuker> its not difficult, all the functions are there [03:21:35 CEST] <kierank> we are also putting a slice in an rtp packet so we need to modify the ratecontrol to be exact [03:21:37 CEST] <atomnuker> all you'll have to change (from the git master of the encoder) is make count_slice or whatever it was get you the slice energy while you're at it [03:21:38 CEST] <kierank> and never go over [03:21:58 CEST] <kierank> (like opus) [03:22:59 CEST] <atomnuker> yeah, if you calculate your weights on a few videos and make sure to compensate with the energy you'll likely never need to do more than 1-2 dist measurements per slice [03:23:27 CEST] <atomnuker> (to make sure you're fulfilling the specified rate and not going above) [03:24:17 CEST] <atomnuker> the hardest part will be using the lambda value at the start of the frame to calculate the slice padding/that weird multiplier [03:24:27 CEST] <atomnuker> because if its too big you'll waste a lot of bits [03:25:15 CEST] <atomnuker> but that can come later, you can stick with the default value of 2048 (I think, from memory it was usually hovering around that) [04:16:19 CEST] <cone-945> ffmpeg 03Jerome Borsboom 07master:19c3df0cd6dd: avcodec/vc1: fix mquant calculation [10:08:43 CEST] <cone-484> ffmpeg 03Paul B Mahol 07master:70d25b89db9b: avfilter/vf_overlay: use slice_end in alpha_composite() [13:05:16 CEST] <BtbN> I have been staring at this CUstream API for a while now, and I still don't understand it. [13:26:39 CEST] <cone-276> ffmpeg 03Paul B Mahol 07master:889d858491ac: avfilter: add amplify filter [13:53:28 CEST] <durandal_1707> ubitux: ppsrc option of fieldmatch is completly broken, it does not work with input from telecine filter [14:03:22 CEST] <ubitux> it's supposed to work with filter that do not affect the pts [14:03:38 CEST] <ubitux> like, does it work with a denoiser such a nlmeans? [14:04:05 CEST] <ubitux> iirc that's the purpose [14:04:24 CEST] <ubitux> pre-filtering the graphics to help the fieldmatch heuristics [14:05:25 CEST] <durandal_1707> ubitux: it is broken because it will call filter_frame when there is already frame, so it will just overwrite it, one of lavfi improvements broke it [14:05:45 CEST] <durandal_1707> guess will need transform to activate [14:06:20 CEST] <durandal_1707> ubitux: i test only with split, which should give same result [14:07:32 CEST] <durandal_1707> i now see how Nicolas is very incompetent for his position [14:07:53 CEST] <ubitux> i haven't tested the filter since its introduction [14:07:58 CEST] <ubitux> i'm not sure we even have a fate test& [14:08:15 CEST] <ubitux> if so, we should probably have at least 2 tests [14:10:38 CEST] <durandal_1707> ubitux: should it use framesync2 or not? definetely need converting to .activate [14:12:41 CEST] <ubitux> the expected usage is: "split=2[src][extra]; [extra]nlmeans[pp]; [src][pp] fieldmatch=ppsrc=true" [14:13:04 CEST] <ubitux> fieldmatch is supposed to use [pp] to analysis [14:13:13 CEST] <ubitux> and picking the corresponding from [src] [14:13:22 CEST] <ubitux> i don't know if framesync2 would help [14:13:58 CEST] <ubitux> (nlmeans or whatever filter that would help the heuristics) [14:14:12 CEST] <durandal_1707> ubitux: even simply do nothing does not work [14:14:13 CEST] <ubitux> (as long as it doesn't break the pts sync) [14:14:23 CEST] <durandal_1707> pts are unchanged [14:14:39 CEST] <durandal_1707> ubitux: i'm sure it worked before [14:14:47 CEST] <ubitux> maybe a regression was introduced in the past years [14:14:50 CEST] <ubitux> i never use that filter [14:14:51 CEST] <durandal_1707> yes [14:21:23 CEST] <wm4> ubitux: can you ok my HLS patch? (it's somewhat related to your avoption deprecation thing) [14:23:54 CEST] <ubitux> maybe dashdec and rtsp should actually be updated as well [14:32:42 CEST] <wm4> thanks [14:33:18 CEST] <wm4> now if only dashdec weren't just most of hls copy&pasted or something [14:33:32 CEST] <JEEB> yea, they could just share a lot of base logic [14:33:41 CEST] <wm4> with some weird differences [14:34:12 CEST] <JEEB> and same for hlsenc and dashenc, they could also just share a lot of stuff [14:34:13 CEST] <nevcairiel> they even share a lot now because dashenc can also create a hls playlist on the side [14:34:32 CEST] <JEEB> yea, but they don't share all of the non-string creation stuff [14:34:39 CEST] <wm4> dashenc!=dashdec [14:34:40 CEST] <JEEB> but they do share some stuff, yes [14:34:57 CEST] <wm4> oh you changed topic, nvm [14:34:57 CEST] <nevcairiel> obviously encoder != decoder, your point? :p [14:35:09 CEST] <JEEB> the decoder was being discussed [14:35:12 CEST] <JEEB> and IIRC that shares less [14:35:14 CEST] <JEEB> or they [14:35:29 CEST] <nevcairiel> those people interested in the encoders are not really interested in making nice and clean things [14:35:34 CEST] <nevcairiel> much corporate in there [14:35:41 CEST] <wm4> it seems like dashdec started out with a copy of hls that was then heavily modifed [14:35:41 CEST] <JEEB> yup [14:36:06 CEST] <nevcairiel> probably, dashdec was one of those big monsters noone dared to really review anyway [14:36:27 CEST] <JEEB> yea [14:37:20 CEST] <wm4> well many reviewed it a bit, but I think they could pick out only minor things, not criticize the architecture [14:37:41 CEST] <wm4> can't exactly say "please rewrite it in a way that as much logic as possible is shared with hls" [14:37:50 CEST] <nevcairiel> why not [14:42:43 CEST] <wm4> because it'd require being a dick [14:43:11 CEST] <wm4> not that much of a problem in ffmpeg, but still [14:44:19 CEST] <nevcairiel> if devs want to a void that, they ask about architectural feedback before writing thousands of lines of code [14:44:36 CEST] <JEEB> true [15:04:09 CEST] <cone-276> ffmpeg 03Paul B Mahol 07master:a5b2d85f18b3: avfilter/vf_fieldmatch: switch to activate [15:04:10 CEST] <cone-276> ffmpeg 03Paul B Mahol 07master:ad164237047d: avfilter/vf_fieldmatch: add support for >8 bit depth in ppsrc [15:18:51 CEST] <JEEB> holy crap [15:19:04 CEST] <JEEB> just noticed this one guy implemented an ARIB subtitle decoder in lavc [15:19:16 CEST] <JEEB> now I don't know if I should rework that one, or use libaribb24 [15:19:21 CEST] <JEEB> https://github.com/0p1pp1/FFmpeg/commit/7757871426c285c913a27771c11e9c0e5c8… [15:20:18 CEST] <durandal_1707> JEEB: that is old one, couple days passed [15:21:07 CEST] <JEEB> yes, I know I had looked at that repo before but I hadn't noticed this :D [15:21:14 CEST] <atomnuker> JEEB: looks fine, tables aren't huge [15:21:53 CEST] <JEEB> I think he started using some forked libass features to show it [15:21:59 CEST] <JEEB> but having this internal is pretty cool [15:22:21 CEST] <JEEB> also this repo taught to me that iconv seems to have the ARIB-B24 coding as well? [15:22:29 CEST] <JEEB> iconv_open("UTF-8", "ARIB-STD-B24"); [15:22:33 CEST] <JEEB> which is good if true [15:24:15 CEST] <wm4> not here btw. [15:24:17 CEST] <wm4> iconv -l [15:24:28 CEST] <JEEB> yes I was kind of afraid it was this guy's fork [15:24:32 CEST] <wm4> it has shitjizz (aka SHIFT_JIS) but no arib [15:24:32 CEST] <JEEB> since he has a gconv module for it [15:24:44 CEST] <JEEB> yea, shift-jis and iso2022jp families with euc-jp are there [15:26:35 CEST] <JEEB> but yea, this 0p1pp1 dude seems to have poked all the things [15:26:42 CEST] <JEEB> iconv, FFmpeg, libass, mpv [15:27:12 CEST] <wm4> he probably wouldn't mind if someone took it and cleaned it up [15:27:25 CEST] <JEEB> yea [17:40:03 CEST] <JEEB> wm4: seems like one .jp guy already posted both European and ARIB text codings to gconv in 2015 https://sourceware.org/ml/libc-help/2015-03/msg00006.html [17:40:20 CEST] <JEEB> not sure if it ever went into the repo [17:41:10 CEST] <JEEB> wonder what happened to those patches as they contain both DVB and ARIB [17:42:27 CEST] <JEEB> https://sourceware.org/ml/libc-help/2015-03/msg00027.html [17:42:32 CEST] <JEEB> > they are domain-specific so GTFO [17:42:35 CEST] <JEEB> asdf [17:43:12 CEST] <JEEB> https://sourceware.org/ml/libc-help/2015-03/msg00016.html [17:44:31 CEST] <durandal_1707> where is GTFO written? [17:45:03 CEST] <JEEB> paraphrasing [17:45:37 CEST] <JEEB> but basically "thanks, they look largely straight forward. unfortunately, i think most likely we're going to pass on them. it's nothing personal ... we most likely won't accept any more gconv modules unless it's computing related (as vague as that sounds) and makes a strong case as being relevant." [17:46:05 CEST] <JEEB> "a quick scan of our current modules shows they're all focused on encodings that were used historically (IBM/DOS/Windows/etc...) or active today (UTF8/etc...). encodings used in broadcast tv don't really fall into these buckets." [17:46:25 CEST] <durandal_1707> shame [17:47:00 CEST] <wm4> seems arbitrary [17:47:09 CEST] <JEEB> like [17:47:22 CEST] <JEEB> is every goddamn project supposed to have their own thing embedded? [17:49:06 CEST] <wm4> anyway it wouldn't help ffmpeg anyway [17:49:15 CEST] <wm4> it can't rely on the system iconv having this [17:50:06 CEST] <JEEB> then the alternatives are to use patched iconv, or using aribb24 for ARIB and ?!? for DVB [17:50:18 CEST] <JEEB> or NIH'ing the code from another project and having the N'th copy of a similar text conversion code [17:52:29 CEST] <wm4> maybe making a small lib? [17:52:51 CEST] <JEEB> for ARIB aribb24 seems to be that [17:52:57 CEST] <JEEB> DVB I just have no idea [18:00:35 CEST] <durandal_1707> kierank: shouldn't because alpha can be 16 bit in ProRes, we do 16bit instead of 12? [18:01:10 CEST] <kierank> I guess [18:04:17 CEST] <wm4> jamrial: is it ok if I push my VS wrapper? [18:04:22 CEST] <cone-644> ffmpeg 03Michael Niedermayer 07master:da038c07f02d: avcodec/wavpack: Fix integer overflow in wv_unpack_stereo() [18:04:22 CEST] <cone-644> ffmpeg 03Michael Niedermayer 07master:6e95d80e6fae: avcodec/wavpack: Fix integer overflow in DEC_MED() / INC_MED() [18:04:34 CEST] <durandal_1707> wm4: not ok [18:05:45 CEST] <wm4> durandal_1707: why? [18:08:14 CEST] <durandal_1707> we should remove avisynth support, vapoursynth support is not needed [18:22:48 CEST] <durandal_1707> so i can not pass struct to x86 asm? [18:23:20 CEST] <wm4> durandal_1707: are you blocking my patch? [18:26:40 CEST] <atomnuker> JEEB: its not that much code and it'll mathematically always be valid tbh [18:27:05 CEST] <JEEB> yea, as long as someone goes through the validation [18:27:07 CEST] <atomnuker> its not really nih, someone else wrote it too :) [18:27:24 CEST] <jamrial> durandal_1707: you can, see fft [18:27:43 CEST] <JEEB> I'm not sure if I have the patience to make sure all entries match their pretty pictures at the end of the ARIB PDF :D [18:28:00 CEST] <JEEB> I just have to trust and see that most of the code makes sense [18:28:04 CEST] <JEEB> maybe add a few tests [18:29:08 CEST] <jamrial> wm4: i have no opinion on vapoursynth other than i'd prefer if you could do like avisynth and export as rawvideo instead [18:29:50 CEST] <jamrial> lets try to not increase the amount of modules depending on sizeof(avframe) [18:30:16 CEST] <wm4> I can send a patch to fix that for all modules afterwards [18:30:24 CEST] <wm4> my idea is to store a AVFrame* instead [18:30:31 CEST] <wm4> (why isn't that done currently anyway) [18:30:38 CEST] <durandal_1707> wm4: no, is this sponsored work? [18:30:45 CEST] <wm4> durandal_1707: no [18:30:59 CEST] <wm4> durandal_1707: I'm just trying to fight avisynth [18:31:07 CEST] <durandal_1707> lol [18:31:09 CEST] <jamrial> wm4: any such change couldn't be done until we bump major again anyway [18:31:29 CEST] <wm4> jamrial: depending on what we think about we might have to add a new codec ID [18:32:26 CEST] <wm4> or the avpriv_get_avframe_size() idea [18:33:21 CEST] <jamrial> is it too hard to assemble rawvideo pakets with the methods vapoursynth provides? [18:33:23 CEST] <durandal_1707> jamrial: even for "struct weighted_avg wa[HUGE_NUMBER]" ? [18:33:58 CEST] <wm4> jamrial: vapoursynth only provides an AVFrame-like object [18:34:29 CEST] <wm4> though I'm copying the video anyway, because otherwise I'd probably have to attach python to the refcount thing (lol) [18:34:39 CEST] <wm4> or well I'd have to refcount the core [18:34:42 CEST] <durandal_1707> ubitux: i gonna write nlmeans SIMD [18:34:45 CEST] <wm4> might actually do that later [18:34:52 CEST] <ubitux> durandal_1707: i'm actually doing it right now [18:35:03 CEST] <ubitux> for aarch64 though [18:35:10 CEST] <ubitux> but the infrastructure + tests is there [18:36:21 CEST] <durandal_1707> ubitux: i write for x64 [18:36:38 CEST] <ubitux> are you going to blind it [18:36:39 CEST] <ubitux> ? [18:36:58 CEST] <ubitux> i'll poke you when the branch is ready for adding simd [18:37:34 CEST] <durandal_1707> ubitux: you have additional changes? [18:37:53 CEST] <ubitux> yeah sure, the callback system + checkasm test [18:38:17 CEST] <ubitux> tests are a bit tricky so i need to start writing stuff to make sure they work [18:42:15 CEST] <durandal_1707> well code that does doubles doesn need checkasm, only last averaging needs doubles [18:44:14 CEST] <ubitux> what doubles? [18:44:25 CEST] <ubitux> the simd i'm writing is for the integral part [18:44:50 CEST] <ubitux> compute_safe_ssd_integral_image(_c) [18:48:23 CEST] <durandal_1707> ubitux: final averaging [18:49:30 CEST] <ubitux> ah, okay [18:49:38 CEST] <ubitux> well we shouldn't have too much conflict then [18:50:41 CEST] <ubitux> i went with a NLMeansDSPContext dsp at the end of NLMeansContext [18:50:51 CEST] <durandal_1707> ubitux: well, i want to write other one too, for x64 [18:50:56 CEST] <ubitux> addition of a libavfilter/vf_nlmeans.h, usual stuff [18:51:04 CEST] <ubitux> sure [18:51:12 CEST] <ubitux> i don't plan to write any x86 simd [18:51:25 CEST] <ubitux> but if we can do the infrastructure work once that would be best [18:51:36 CEST] <durandal_1707> just post patch when you write infrastructure [18:51:37 CEST] <ubitux> i'll give you the branch with that done in a moment [18:51:59 CEST] <ubitux> yup, it's written but i did that months ago i need to check what's the status of it (if it does even work/compile) [18:52:06 CEST] <ubitux> give me 30 min - 1h [18:53:18 CEST] <durandal_1707> wm4: have you read post on d9, your patch was mentioned there, and it have bug [18:54:15 CEST] <durandal_1707> probably python environment variable is needed because thats what i need for vspipe and mpv's vs filter [18:59:40 CEST] <wm4> I don't read d9 [19:04:35 CEST] <durandal_1707> https://forum.doom9.org/showthread.php?t=175341 [19:07:27 CEST] <wm4> that doesn't seem to be related to anything, just someone fighting windows [19:09:34 CEST] <jamrial> there's a version using rawvideo posted there as well [19:09:42 CEST] <jamrial> from April 3rd [19:10:10 CEST] <jamrial> doing the same as the avisynth wrapper, nice [19:18:23 CEST] <jamrial> Gramner: ^ ticket 7177 looks like a x264 bug [19:40:27 CEST] <cone-644> ffmpeg 03Paul B Mahol 07master:c0f2abcc8d2a: avfilter/vf_mix: make setting weights more user friendly [19:40:28 CEST] <cone-644> ffmpeg 03Paul B Mahol 07master:02470814b595: doc/filters: add tmix examples [19:45:44 CEST] <ubitux> /home/ux/ffbuild/aarch64/src/libavcodec/v4l2_m2m.c:72: undefined reference to `sem_init' [19:45:48 CEST] <ubitux> is this known? [19:47:45 CEST] <jamrial> sounds like pthreads was not properly detected? [19:48:03 CEST] <jamrial> or that v4l2_m2m is missing the relevant dep in configure [19:48:48 CEST] <ubitux> yeah i disabled pthread on purpose [19:49:02 CEST] <ubitux> i guess that's the reason [19:50:38 CEST] <jamrial> ubitux: maybe https://pastebin.com/czWavj0C ? [19:51:25 CEST] <jamrial> guess checking for sem_timedwait is enough since that's only enabled if pthreads is enabled [19:54:37 CEST] <jamrial> so maybe https://pastebin.com/rEjms3vY [19:57:07 CEST] <ubitux> durandal_1707: WIP @ https://github.com/ubitux/FFmpeg/tree/nlmeans-dsp [19:57:11 CEST] <ubitux> jamrial: i'll test in a second [19:57:30 CEST] <jamrial> sure, no hurry [20:01:13 CEST] <ubitux> jamrial: seems to fix compilation with --disable-pthreads here [20:01:15 CEST] <ubitux> thanks [20:02:19 CEST] <jamrial> no prob [20:06:27 CEST] <cone-644> ffmpeg 03James Almer 07master:cae6f806a636: configure: add missing pthreads dependency to v4l2_m2m [20:33:10 CEST] <JEEB> wm4: someone actually seems to have tested your thing https://forum.doom9.org/showthread.php?p=1840663#post1840663 [20:33:15 CEST] <JEEB> (vapoursynth) [20:33:56 CEST] <wm4> fuck that person [20:34:03 CEST] <wm4> "it doesn't work" [20:34:29 CEST] <JEEB> yes, not exactly a good report [20:34:54 CEST] <wm4> also something about windows builds [21:10:57 CEST] <wm4> jamrial: what's your beef with wrapped avframe? [21:11:23 CEST] <durandal_1707> wrapped avframe is faster? [21:11:48 CEST] <wm4> it can be made faster and it doesn't have these alignment issues [21:12:01 CEST] <jamrial> it's ugly, that "trusted" pkt stuff is kinda sketchy, it uses sizeof(avframe) [21:12:34 CEST] <jamrial> i'm not blocking your patch, just would prefer if you can do like avisynth and just export normal rawvideo packets [21:13:19 CEST] <atomnuker> it would have been nice to have an api which could make lavf and lavd output avframes but that could go wrong [21:13:50 CEST] <wm4> there's already such an API and it sucks [21:13:59 CEST] <wm4> I prefer the wrapped_avframe hack [21:14:07 CEST] <durandal_1707> ubitux: why aarch64 specifically? [21:14:25 CEST] <atomnuker> wm4: there is? which one [21:14:34 CEST] <wm4> oh wait, the uncoded stuff is for muxing only [21:14:36 CEST] <wm4> no demuxing [21:14:54 CEST] <wm4> but I guess you could argue demuxing could be added [21:20:35 CEST] <kierank> We should have a unified type for frame and packet [21:20:43 CEST] <kierank> Would solve a lot of issues [21:20:56 CEST] <wm4> just make AVFrame carry packet data [21:21:17 CEST] <wm4> you can bet someone will suggest this [21:33:04 CEST] <ubitux> durandal_1707: because that's the easiest one [21:38:19 CEST] <durandal_1707> ubitux: you actually have way to test? [21:45:14 CEST] <jamrial> there are some commercial aarch64 boards, but last time i remember them being mentioned they kinda sucked for dev work [21:45:22 CEST] <jamrial> crappy/old kernels or some such [21:46:56 CEST] <atomnuker> the c2 is alright _when it works_, the latter being a question of distros [21:48:04 CEST] <atomnuker> the pi3 with arch (aarch64) also works fine, though its a few times slower than the c2 [21:48:37 CEST] <atomnuker> (the plus being you won't get ripped off with customs fees, at least for now, because the c2 is korean made) [21:55:33 CEST] <Gramner> jamrial: nope, it's not [21:55:43 CEST] <Gramner> an x264 issue that is [21:57:05 CEST] <jamrial> but shouldn't x264 gracefully reject weird input like the kind sent with that vf_scale combination instead of hard crashing with an assert? [21:57:13 CEST] <Gramner> I guess x264 could fail more gracefully in case of invalid output instead of failing some random assert though [21:57:23 CEST] <jamrial> yeah [21:59:41 CEST] <Gramner> would probably have to do it in the plane copying functions to not affect performance, which would require modifying asm for at least 4 archs though, so somewhat of an effort required [21:59:59 CEST] <Gramner> e.g. checking that all input pixels are in a valid range [22:01:25 CEST] <wm4> I can't forgive C2 its video API [22:02:15 CEST] <ubitux> durandal_1707: yeah i have a few aarch64 boards [22:02:42 CEST] <ubitux> i'm using qemu for testing initially though, i use real boards when benchmarking [22:04:00 CEST] <durandal_1707> ubitux: strange, i wrote asm that does nothing and speed does not changes, i expect perf gain by doing nothing [22:04:40 CEST] <ubitux> maybe it's already zomg fast? [22:06:39 CEST] <durandal_1707> ubitux: maybe algo does not like searching zeroes? [22:09:07 CEST] <atomnuker> wm4: the c2 has a video api? first I've heard [22:09:52 CEST] <wm4> atomnuker: yes, in /sys/ [22:10:24 CEST] <atomnuker> next you'll tell me it has hardware encoders and decoders using relatively standard APIs for embedded systems like v4l [22:10:49 CEST] <durandal_1707> ubitux: actually i had bigger numbers with averaging, so that one might be better for perf gain [22:11:08 CEST] <wm4> atomnuker: apparently you're not understanding the horror of it [22:13:11 CEST] <atomnuker> probably not, I don't remember what it was like before I used a standard kernel without binary blobs [22:17:06 CEST] <wm4> you control video decoding and display by writing into special files in /sys/ [22:17:49 CEST] <wm4> there's also an open source library (provided by the firmware vendors) that controls it, but it's pre-beginner level shit C that does almost nothing anyway [22:17:53 CEST] <nevcairiel> thats hardly an API, thats more like a CLI interface :P [22:18:00 CEST] <wm4> other than opening special files and then leaking FDs [22:18:17 CEST] <wm4> nevcairiel: kind of, but it's the kernel interface [22:26:08 CEST] <kierank> michaelni: did you even read the spec when you wrote the patches [22:29:57 CEST] <michaelni> kierank, yes [22:30:06 CEST] <kierank> you reorder a lot of things [22:31:02 CEST] <kierank> you break encoders which want to send custom quant matrix afaik [22:31:38 CEST] <michaelni> none of the samples breaks, and one of them uses custom matrixes [22:32:04 CEST] <kierank> michaelni: you break encoders which want to send them in a particular way [22:32:17 CEST] <kierank> you make assumptions based on samples instead of the spec [22:32:55 CEST] <kierank> it seems there are conformance samples [22:34:03 CEST] <michaelni> kierank, if you have more sampels, please provide them. I dont see where my changes break the spec but the code before certainly doesnt follow the spec [22:34:15 CEST] <kierank> it follows the spec exactly [22:34:32 CEST] <kierank> you have made assumptions about particular ordering [22:36:06 CEST] <kierank> table 6.2.2 [22:37:39 CEST] <kierank> michaelni: http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_IEC_14496-4_20… [22:37:42 CEST] <kierank> I only just found these now [22:38:13 CEST] <michaelni> ehm, the code before had many assumtations on ordering that are removed by the patches [22:38:25 CEST] <kierank> exactly the spec says they must be ordered like htat [22:38:48 CEST] <kierank> you allow studiovisualobject to be anywhere in the bitstream now [22:40:16 CEST] <michaelni> the code before didnt implement the specs ordering at all [22:40:33 CEST] <kierank> ???? [22:40:35 CEST] <kierank> it did exactly [22:40:58 CEST] <michaelni> for example theres a loop in that user/ext data thing on the spec but not in the code [22:42:14 CEST] <michaelni> thanks for the link btw, ill make sure anything that works isnt broken by any changes i make [22:42:41 CEST] <kierank> michaelni: ok, sure but that's an unrelated patch [22:42:56 CEST] <kierank> nothing to do with allowing studiovisualobject anywhere in the bitstream [22:43:57 CEST] <kierank> michaelni: ???? [22:44:12 CEST] <kierank> it's not about samples breaking with your changes, it's about following the spec [22:45:54 CEST] <michaelni> the way the mpeg4 decoder is written is that the header is parsed in a loop, its messy if parts of it bypass the loop, also the ordering is really not enforced before, lots of stuff where and are parsed at random places or parsed twice if thats how they are stored [22:46:31 CEST] <kierank> sunk cost fallacy [22:47:22 CEST] <durandal_1707> what instruction to use to move 32bit unsigned from memory to stack variable? [22:48:03 CEST] <nevcairiel> durandal_1707: "mov"? :) [22:48:45 CEST] <nevcairiel> although you cannot do memory->memory, need to go into a register once [22:49:14 CEST] <durandal_1707> mov accd, [dstq-dst_linesized*4-4] [22:49:47 CEST] <durandal_1707> impossible combination of address sizes, invalid effective address [22:50:06 CEST] <nevcairiel> that might also be too much math [22:50:18 CEST] <kierank> durandal_1707: movd I think [22:50:42 CEST] <nevcairiel> and as said, you cannot do mem->mem moves, so if accd is on the stack, you need a register in between first [22:51:24 CEST] <wm4> movd as in the string instruction? seems overkill [22:52:07 CEST] <nevcairiel> he probably thinks about the simd movd [22:52:20 CEST] <nevcairiel> but that also only works if one of those is a simd reg [22:52:25 CEST] <kierank> ah [22:52:54 CEST] <nevcairiel> for GPR stuff, mov is the right choice, but it has certain limitations - like no mem->mem [22:53:03 CEST] <nevcairiel> so no heap->stack [22:55:37 CEST] <jamrial> durandal_1707: lea, not mov [22:56:33 CEST] <durandal_1707> mov doesnt like negative number [22:57:50 CEST] <jamrial> use lea instead of mov and the above should work [22:58:03 CEST] <nevcairiel> except it wont actually load the data :p [22:58:31 CEST] <durandal_1707> i get invalid effective address [22:58:44 CEST] <durandal_1707> so it can go only forward? [22:58:54 CEST] <durandal_1707> this is not rust :) [22:58:55 CEST] <jamrial> you may need to use dst_linesizeq, but yeah, what nevcairiel said is true in any case [22:59:27 CEST] <durandal_1707> i tried that one already [22:59:53 CEST] <durandal_1707> and acc is defined with call arguments [23:00:22 CEST] <durandal_1707> so it can be both, but probably is on stack [23:02:25 CEST] <nevcairiel> you can subtract constants, not sure you can subtract registers [23:02:28 CEST] <nevcairiel> maybe only add [23:04:15 CEST] <kierank> might work as adding twos complement number [23:04:35 CEST] <kierank> oh it's the register [23:04:40 CEST] <kierank> yeah don't think you an do that [23:04:45 CEST] <kierank> neg the linesize [23:27:48 CEST] <Gramner> x86 addressing is [base+index*(1,2,4,8)+offset] where offset is a constant. any one of them can be omitted [23:28:29 CEST] <Gramner> offset can be negative, but not registers [23:29:57 CEST] <Gramner> and always use native sizes (e.g. q suffix) in addressing operands even if using 32-bit is technically allowed [23:30:25 CEST] <Gramner> even when using lea with a 32-bit destination register (shorter opcode in most cases) [23:30:56 CEST] <atomnuker> you can neg either register though, preferably at the start of the function (its how you can save a register by not needing a counter if you count backwards) [23:43:06 CEST] <durandal_1707> i forgot what to use to unpack bytes into words [23:44:03 CEST] <Gramner> punpck(l/h)bw? [23:44:21 CEST] <Gramner> http://www.felixcloutier.com/x86/ [00:00:00 CEST] --- Mon Apr 30 2018

1 0

ffmpeg.log.20180429
by burek 30 Apr '18

30 Apr '18

[01:08:17 CEST] <amaurea> I'm using the command ffmpeg -f concat -safe 0 -t 10 -i "$ifile" -vf setpts=1/4*PTS,vidstabtransform=smoothing=60,unsharp=5:5:0.8:3:3:0.4 -r 30 -an -y "$ofile" to concatenate stabilize and speed up a video. It is quite high resolution (2704x1520), but even so the speed I'm getting is surprisingly slow, at 0.7 fps. So I wonder if I'm doing something wrong. In particular, I wonder if the dropping of frames needed to speed up the video by 4 times, as this command [01:09:41 CEST] <amaurea> Since the starting point is a 60 fps video, and the output is a 4x fast forward 30 fps video, that means that in the end only one frame in 8 will be used in the output. Hence the point at which the frame dropping happens should matter a lot for the speed [01:10:25 CEST] <amaurea> The ffmpeg version is 3.4.2 on linux [01:14:12 CEST] <furq> amaurea: -r 30 will just append -vf fps to the end of the filterchain [01:14:55 CEST] <amaurea> I assume that the actual video encoding happens after the whole filterchain? [01:14:57 CEST] <furq> yes [01:15:08 CEST] <amaurea> So I would still only be encoding 1/8 of the original frames, then [01:15:10 CEST] <furq> i guess you might want to put it before vidstabtransform but idk if that'll make any difference [01:15:14 CEST] <klaxa> but filtering all of them [01:15:18 CEST] <amaurea> The redundant part is the stabilization of frames that would be dropped [01:15:36 CEST] <amaurea> Would the select filter be better, then? [01:16:11 CEST] <furq> select,setpts might be faster [01:16:22 CEST] <amaurea> thanks, I will try that [01:16:34 CEST] <furq> x264 with default settings shouldn't be that slow at ~1440p [01:16:39 CEST] <furq> so i guess vidstab is bottlenecking it [01:17:00 CEST] <amaurea> (otherwise my video would take half a week to encode [01:17:25 CEST] <furq> i guess lowering the smoothing value might help as well [01:17:32 CEST] <furq> i've never really used vidstab so that's just a guess [01:17:44 CEST] <amaurea> Maybe it's a bit high. The video is quite shaky, though.. [01:17:49 CEST] <amaurea> I'll experiment a bit [01:18:16 CEST] <furq> i take it $ofile ends in either mkv or mp4 [01:18:26 CEST] <furq> otherwise it might be defaulting to some worse codec [01:19:00 CEST] <amaurea> Yes, it's mp4 since mkv is poorly supported by browsers etc. [01:19:24 CEST] <furq> you can maybe try -preset superfast [01:19:35 CEST] <amaurea> Is that a lot faster than fast? [01:19:43 CEST] <furq> the default is medium [01:20:04 CEST] <furq> but yeah if vidstab is the bottleneck then ffmpeg won't be using close to 100% cpu [01:20:05 CEST] <amaurea> I tried fast, and it didn't make any noticable difference. Which makes me think that the encoding isn't the bottleneck [01:20:17 CEST] <furq> if it's not then changing the x264 preset won't make any difference [01:20:28 CEST] <furq> if it's not using close to 100% cpu, that is [01:21:09 CEST] <furq> it's probably also worth testing without unsharp, although that's probably not the issue [01:21:14 CEST] <furq> but it's good to rule it out [01:21:30 CEST] <amaurea> Ok, I'll keep you updated on the result [01:25:26 CEST] <kepstin> furq: amaurea: the -r output option actually *doesn't* put the fps filter on, it behaves slightly differently [01:25:40 CEST] <kepstin> (i normally recommend using the fps filter instead, it has better rounding behaviour imo) [01:25:47 CEST] <furq> oh yeah this came up recently didn't it [01:25:54 CEST] <furq> either way it won't take affect until after the rest of the filterchain [01:25:58 CEST] <furq> effect [01:26:24 CEST] <kepstin> yeah, the -r option takes effect when muxing the encoded video into the container, iirc [01:26:35 CEST] <kepstin> and the fps filter takes effect wherever you put it :) [01:27:04 CEST] <kepstin> er, no, -r has to be before the encoder [01:27:11 CEST] <furq> right [01:27:15 CEST] <kepstin> between the filter chain and encoder, not sure exactly where [01:36:48 CEST] <amaurea> 1.7 fps with select and without unsharp [01:37:00 CEST] <amaurea> I'll try a simpler plain reencode test, with no filters [01:55:40 CEST] <amaurea> Encoding 10 s of video with default settings takes 107 s. 10 s of input video with select=mod(n\,8) and setpts=1/8*PTS takes 25 s, as does setpts=1/4*PTS with -r 30. So encoding only 1/8 of the frames is not 8 times faster, only 4 [01:56:19 CEST] <furq> well those are encoding the sane number of frames because of -r 30 [01:56:23 CEST] <furq> same [01:56:55 CEST] <amaurea> you mean the 1/8 and 1/4 examples, right? [01:57:01 CEST] <amaurea> Those were supposed to be the same [01:57:17 CEST] <amaurea> I expected both of them to be 8x faster than the plain encode, since the original video is 60 fps [01:58:01 CEST] <kepstin> I wouldn't expect a linear speedup, because video decoding becomes a larger portion of time used as you decrease the number of frames encoded. [01:58:13 CEST] <furq> if you're going from 60 to 30 then i'd only expect that to be about twice as fast [01:58:31 CEST] <furq> but it's probably duplicating some frames which would account for the rest of the speedup [01:59:00 CEST] <amaurea> furq: I'm going from 60 to 30, but it's 30 after dividing the PTS by 4, so effectively it's like going from 60 to 7.5 [01:59:08 CEST] <kepstin> using a setpts=1/4*PTS and setting an output framerate <= input should only drop frames. [01:59:26 CEST] <amaurea> kepstin: so all the frames are decoded, even those that will be dropped? [01:59:28 CEST] <kepstin> (it'll shorten the run time of the video) [01:59:28 CEST] <furq> oh yeah you're speeding it up [01:59:32 CEST] <kepstin> amaurea: yes [02:00:18 CEST] <kepstin> amaurea: there's some tricks that can be done to e.g. only decode keyframes, but that depends on the video having a keyframe interval suitable for what you want to do. [02:00:29 CEST] <amaurea> Encoding 10 s with hwaccel and superfast took just 19 s [02:00:39 CEST] <amaurea> without any frame dropping etc. [02:00:49 CEST] <amaurea> kepstin: that makes ense [02:02:07 CEST] <amaurea> superfast without hwaccel: 25 s [02:12:57 CEST] <amaurea> 10 s with hwaccel, superfast, motion estimation and motion compensation: 150 s. So clearly the motion stuff totally dominates [02:20:24 CEST] <amaurea> I think the main conclusion here is that the resolution is too high. I get more tolerable results with rescaling to 1280:720 [02:42:58 CEST] <nohop> Hey guys. I'm using an ffmpeg to stream to ffserver using: /usr/bin/ffmpeg -v 2 -r 2 -s 640x480 -f video4linux2 -i /dev/video0 http://localhost:8090/webcam.ffm [02:43:27 CEST] <nohop> The framerate, however, is much higher than 2 (around 4-5 or so). Am I missing something? [02:55:48 CEST] <kepstin> nohop: first of all, ffserver isn't supported any longer, so we can't help you with any problems specific to that [02:56:30 CEST] <kepstin> nohop: you should not use the -r option with live inputs - please either use the -framerate option to request the input use a different framerate (if supported), or use the -r *output* option or -vf fps filter instead. [02:58:56 CEST] <nohop> ffserver is no longer supported?! That makes me a little sad. It has been with us for so many years! :) [02:59:40 CEST] <klaxa> i'm working on a replacement through google summer of code, so maybe after the summer there is something usable that replaces the old ffserver [03:00:35 CEST] <nohop> And, ah... So it's probably the 'if supported' part. I thought maybe ffmpeg would 'resample'.. In my case I'd actually be fine throwing away frames to the point where I average ~2fps. That's a little hacky though, so I'd understand if there's no option for that :) [03:00:49 CEST] <nohop> klaxa: Nice! [03:02:48 CEST] <kepstin> nohop: if you want ffmpeg to drop/duplicate frames to get exact 2fps output, the fps filter is the way to go. [03:07:49 CEST] <nohop> As in -vf "fps=2" ? [03:12:47 CEST] <kepstin> yeah [03:14:43 CEST] <nohop> Doesn't seem to change anything... [03:15:23 CEST] <nohop> It's also not that big a deal, just wanted to reduce a tiny bit of CPU load on this old little intel atom n270 board :) [03:20:28 CEST] <kepstin> heh. at least you don't need to apply spectre/meltdown fixes on that :) [03:22:26 CEST] <nohop> On the other hand, compiling shit on it gives you cancer. So I guess there's pros and cons :) [03:24:57 CEST] <nohop> I haven't really followed much of that whole debacle. Are there now patches/hacks/workarounds in the mainstream kernel to 'protect' against it at all? [03:26:04 CEST] <nate> there have been patches since before it was even announced (though it was patches to the linux kernel which lead to people figuring out the vulnerability which then lead to the early announcement) [03:26:25 CEST] <nate> (for meltdown anyways, spectre's been getting rolled out a bit more carefully) [03:26:47 CEST] <kepstin> the kernel has a pretty decent set of patches to protect itself now, but it requires microcode updates (only available on recent cpus) to fully apply. Some userspace apps that run/interpret untrusted remote code - like browsers - needed some work as well. [03:27:15 CEST] <nohop> model name : Intel(R) Xeon(R) CPU W3520 @ 2.67GHz [03:27:24 CEST] <nohop> Probably shit-out-of-luck with this old beast huh :) [03:27:30 CEST] <nohop> (Not that I care, really) [03:28:35 CEST] <kepstin> looks like the W3520 is one generation older than the oldest they have updates for [03:29:03 CEST] <kepstin> looking at the intel guidance, they might still have something for it later, not sure [03:29:41 CEST] <nate> nohop: Intel released patch/microcode stuff for every CPU made since I believe the P2 era [03:30:03 CEST] <nate> or whatever was the earliest vuln ones [03:30:05 CEST] <nate> Was that P4? [03:30:33 CEST] <kepstin> microcode updates have only been released for second generation "core" series chips and later from intel [03:30:49 CEST] <kepstin> and some first generation core series, and a few later atom chips [03:31:13 CEST] <kepstin> vulnerable chips are anything with speculative execution, which iirc is pentium pro and later excluding some early atom chips. [03:31:17 CEST] <nohop> Ah. Oh well. [03:32:17 CEST] <nohop> Yeah, I watched some talks on the vuln. It's actually a pretty exciting one, I thought :) [03:34:52 CEST] <nate> kepstin: That's variant 2 isn't it? They claim they "can't" microcode fix variant 2 on older stuff, but variant 1 I thought they were doing a mix of microcode+software patches going back ages [03:35:03 CEST] <nate> https://downloadcenter.intel.com/download/27591 <-- this one specifically, which looks like it goes back at least to the P2 Xeons [03:35:15 CEST] <nate> Or sorry, original pentiums actually [03:37:09 CEST] <kepstin> yeah, variant 1 can be mitigated purely in software (which on older systems reduces performance quite a bit - newer processors have features that reduce the overhead) [03:40:13 CEST] <kepstin> variant 2 iirc can be mostly mitigated in software (retpoline), but there's some weird cases with preemption or something that can break it so microcode fixes are usually used in combination. [03:40:32 CEST] <kepstin> er, i'm getting 1 and 3 mixed up [03:40:44 CEST] <kepstin> anyways, this isn't really the place to talk about it, so I'm gonna shut up now :) [03:49:30 CEST] <Kadigan> Hey. When I split a file but do -c:v copy -c:a copy, I'm not guaranteed to have the segment start on an i-frame, am I? [03:50:37 CEST] <kepstin> Kadigan: using the segment muxer? ffmpeg will by default adjust the segment lengths so they start on keyframes [03:51:14 CEST] <Kadigan> I'm trying to understand ordered chapters, so I took a TV series I have and split off the intro sequence and the episodes (2 for now) [03:51:34 CEST] <Kadigan> and it seems it's working, but... when the next segment starts, I have blank video until something happens... [03:51:58 CEST] <Kadigan> I'm not sure what that "something" is. When I play the "cut off" file back directly, the same happens. [03:52:05 CEST] <Kadigan> When I seek or something, it shows video. [03:52:30 CEST] <furq> how did you split it [03:52:55 CEST] <furq> if you used -ss and the file has audio then you'll probably end up with a video delay [03:53:12 CEST] <Kadigan> I did. How should I do this? [03:53:40 CEST] <furq> i'm not really aware of an elegant way other than finding the correct timestamp of the nearest iframe [03:54:26 CEST] <Kadigan> I need to cut on that spot. So what, I need to use a NLE? [03:54:33 CEST] <Kadigan> an* [03:56:52 CEST] <furq> ffprobe -show_frames -show_entries frame=pict_type,best_effort_timestamp_time test2.mkv | grep -B1 pict_type=I [03:57:01 CEST] <furq> that should give you the timestamps of every idr frame [03:57:35 CEST] <furq> hopefully you're not on windows [04:04:39 CEST] <Kadigan> ... I am. :) [04:04:55 CEST] <Kadigan> I realized I could cut via Premiere Pro and just recode the whole thing, [04:05:11 CEST] <Kadigan> but then I also realized that the audio doesn't end cleanly and would pose problems down the line. [04:05:43 CEST] <Kadigan> So I'm forgetting this idea. I <did> get ordered chapters working, though, before I ran into all sorts of trouble, so <that> part of the activity went just fine... :D [04:06:03 CEST] <Kadigan> Also helped me understand ordered chapters, which is nice. [04:06:06 CEST] <Kadigan> Thanks, anyway. :) [10:30:48 CEST] <acresearch> hello people, i have a video .mp4 at 150MB i want to reduce its size to 5MB but keep it at .mp4 encoding i understand i would lose quality but how can i setup the command? any help? [10:30:56 CEST] <acresearch> no audio in the video [10:42:27 CEST] <Mavrik> acresearch, how long is the video? In minutes / seconds? [10:43:02 CEST] <acresearch> Mavrik: 1:20 [10:45:34 CEST] <Mavrik> So you need to reduce bitrate of the video to about 500kbps [10:45:59 CEST] <acresearch> Mavrik: sure as long as i get low memory [10:46:20 CEST] <Mavrik> (500 kbit/s * 80 s) / 8 = ~5MB [10:46:49 CEST] <Mavrik> so something like ffmpeg -i <your video>.mp4 -codec:v libx264 -b:v 500k -preset slow output.mp4 should do the trick [10:48:22 CEST] <Mavrik> acresearch, what's the resolution of your video? [10:48:38 CEST] <acresearch> 4k [10:48:45 CEST] <Mavrik> ah, I'd suggest reducing that [10:48:55 CEST] <Mavrik> Or you'll get a blurry blotch :P [10:49:21 CEST] <Mavrik> add "-vf scale=-2:480" to that commandline :) [10:55:26 CEST] <acresearch> Mavrik: thanks [12:17:24 CEST] <kerio> hm, would a 4k video viewed as 480p look worse than a video scaled to 480p before encoding, given the same bitrate? [12:21:51 CEST] <sfan5> definitely not [12:22:32 CEST] <sfan5> though.. by "same bitrate" you mean encoding 4k video at the bitrate you would use for 480p? [12:22:43 CEST] <kerio> yep, see the backscroll [12:23:26 CEST] <iive> yes it would definitely look worse. [12:35:53 CEST] <Mavrik> Yes, it'll look like a shapeless blob :P [12:36:15 CEST] <Mavrik> You can't record 3840x2160 worth of pixels at 30fps into 500.000 bits per second :P [12:54:10 CEST] <iive> let's say that you use format that has 4x4 dct blocks. one such block would be like 1 pixel in the SD image. [12:54:56 CEST] <iive> so you will effectively use only DC part of the encoding. If the format has loopfilter, it might smooth the edges of the blocks. [12:55:44 CEST] <iive> still, you'd have to spend some bits in order to fix the errors caused by the artifacts and you don't have any extra bits to spare. [14:14:12 CEST] <voltagex> Out of interest, is x265 encoding likely to get much faster in the coming years, other than through CPU improvements? [14:16:12 CEST] <JEEB> that is up to the x265 development team, which currently is 99% developers from MultiCoreWare [14:17:20 CEST] <iive> i don't think they have that as a major goal... [14:17:47 CEST] <iive> but that's just my own speculation. [14:18:38 CEST] <voltagex> Is 1.8fps using veryslow on a 6 core Intel normal? 1080p transcode [14:18:47 CEST] <JEEB> that sounds like fast [14:18:56 CEST] <JEEB> with x264 in 2006 I was having 0.6fps [14:19:03 CEST] <JEEB> with slow settings [14:20:13 CEST] <voltagex> That's good perspective, thanks [14:20:53 CEST] <JEEB> granted it seems like veryslow is still on the faster side with x265, they noted that they would be adding another preset between veryslow and placebo later [14:21:12 CEST] <JEEB> because the jump is pretty big right now in performance with veryslow to placebo [14:22:09 CEST] <voltagex> As in placebo is much slower? [14:22:17 CEST] <JEEB> yea [14:22:23 CEST] <voltagex> Sigh [14:22:25 CEST] <JEEB> before all the presets very geared a bit slower [14:22:36 CEST] <JEEB> so the change between veryslow and placebo wasn't that big [14:22:37 CEST] <JEEB> now it is [14:22:43 CEST] <JEEB> so they will be adding a middle point I guess [14:23:10 CEST] <voltagex> Question is now, do I build a dedicated Threadripper encoding box, or spend the same amount of money on AWS [14:23:48 CEST] <JEEB> depends on your needs completely. on the longer run, do you think your needs for encoding will stay the same? [14:23:59 CEST] <JEEB> because IIRC AWS and similar things make you pay quite a bit for the CPU time [14:24:11 CEST] <JEEB> if you are using it constantly [14:24:24 CEST] <voltagex> By splitting the file among 20 AWS boxes I was able to encode at about realtime for ~$1/hour [14:24:28 CEST] <JEEB> if you have very limited needs on-demand [14:24:33 CEST] <JEEB> then AWS etc makes sense [14:24:40 CEST] <voltagex> Bandwidth costs killed me [14:24:50 CEST] <JEEB> as in, you don't need to have the things running all the time [14:24:59 CEST] <JEEB> then not having a dedicated box might be useful [14:25:01 CEST] <voltagex> Yeah, I don't [14:25:21 CEST] <JEEB> try to also check other places like google's thing etc [14:25:32 CEST] <JEEB> to see the best price/perf on other people's hardware [14:25:39 CEST] <voltagex> I'm looking at packet.net's threadripper boxes too [14:25:40 CEST] <JEEB> for your use case [14:25:58 CEST] <voltagex> I also need to get my x265 settings right [14:27:52 CEST] <voltagex> Hm, speed is one of thier project goals - http://x265.org/ [14:33:04 CEST] <JEEB> well yea, realtime is already possible [14:33:13 CEST] <JEEB> you just need to use one of the faster presets [14:33:34 CEST] <arnold> knock knock [14:46:31 CEST] <kerio> who's there [14:54:31 CEST] <kerio> voltagex: check out hetzner, if you're in europe [14:54:36 CEST] <kerio> cheap iron [15:22:09 CEST] <arnold> do you guys have example mux AAC and h264 to mp4 file [15:30:05 CEST] <BtbN> pretty much any commandline from the h264/aac encoding wiki page [19:12:17 CEST] <Madsfoto> G'day. I have a syntax issue, the command ffmpeg -i Org.mov -vf tmix=frames=128 -c:v libx264 orgx264.mp4 only creates a tmix of 3 frames (the default). It's not -vf tmix:frames=128 OR -vf tmix=frames:128 . What am I doing wrong? [19:14:13 CEST] <durandal_1707> Madsfoto: you need add weights: "1 1 1 .... 1 1 1" 128 numbers :) [19:15:18 CEST] <durandal_1707> perhaps, it would be good idea, to use last item to fill all the rest? [19:15:53 CEST] <Madsfoto> last item to fill the rest? [19:16:30 CEST] <durandal_1707> yes, do you need such feature? so you do not need to type 128 times '1 ' [19:16:50 CEST] <Madsfoto> To be honest I assumed it would do that automatically [19:17:41 CEST] <Madsfoto> the syntax would be written how? -vf tmix=frames=20=weights="1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1" [19:18:05 CEST] <Madsfoto> .. as an example (I don't want to spam 128 1's in here) [19:18:27 CEST] <Madsfoto> so, yes, I would very much like such a feature [19:18:32 CEST] <durandal_1707> ok [19:22:08 CEST] <Madsfoto> The correct syntax (for logging reasons) is: ffmpeg -i Org.mov -vf tmix=frames=20:weights="1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1" -c:v libx264 orgx264.mp4 [19:25:09 CEST] <Madsfoto> Although, @durandal_1707 can I request it's written in the docs too, as an example? I think that's easier than coding the thing [19:27:05 CEST] <durandal_1707> ok [19:30:30 CEST] <ariyasu> what are weights? [19:31:59 CEST] <Madsfoto> "Specify weight of each input video frame. Each weight is separated by space." I assume how much it's blended (so if you care most about the 3rd frame, you weight it more => giving it higher priority) [19:43:46 CEST] <Madsfoto> Thank you very much. Now the waiting for the website/github to catch up begins :) [20:38:04 CEST] <icy_hot> Hi guys, will really appreciate if anyone experienced with advanced ffmpeg settings can help me out. I know my way around but IŽll be at the summerhome for the next month or so, and I want to get out the *best* possible quality of ffmpeg with x264 coded for a 512 kbps connection to stream my live TV and movies on the limited connection. HereŽs what I got so far but I think you can do much better: https://pastebin.com/63GnMc6b [20:53:55 CEST] <klaxa> icy_hot: looks pretty sane to me, maybe see if slower presets are still acceptably fast [20:54:19 CEST] <klaxa> that should increase the quality at the same bitrate at the expense of computation time [20:55:58 CEST] <icy_hot> It does not help very much, medium seems to be the sweet spot, veryfast also is very good with almost unnoticeable disruption and considerably faster, but I've seen some way better results at 500 kbps [21:29:40 CEST] <romano> Can someone explain to me how the select filter works when used with overlay filter? [21:29:50 CEST] <romano> With the enable [21:29:53 CEST] <dragmore88> good evening! So im trying to extract 6 mono channels from a prores file and encode a valid AC3 5.1 track.. but i have issues.. Anyone care to take a look? https://pastebin.com/HBZFb7uB [21:41:00 CEST] <durandal_1707> dragmore88: you cant just copy paste random command, you need to understand stuff [21:41:27 CEST] <durandal_1707> dragmore88: you will need to use join or amerge filter to merge all mono channels into 5.1 [21:41:40 CEST] <JEEB> I even linked him the audio filtering article the other day [21:41:58 CEST] <durandal_1707> pan filter is not useful in this situation [21:42:31 CEST] <JEEB> and I mentioned there was even an example where there were 6 inputs and 5.1 output was needed lol [21:42:34 CEST] <JEEB> :P [21:43:24 CEST] <JEEB> https://trac.ffmpeg.org/wiki/AudioChannelManipulation [21:43:33 CEST] <JEEB> specifically https://trac.ffmpeg.org/wiki/AudioChannelManipulation#a6mono5.1 [21:54:24 CEST] <romano> Can someone explain to me how the select=between filter works when used with overlay filter? [21:57:47 CEST] <durandal_1707> romano: like any other case, what you want to do? [22:10:17 CEST] <cryptopsy> what does this asm error mean when compiling ffmpeg-4.0 ? https://clbin.com/I9S2B [22:11:31 CEST] <JEEB> cryptopsy: do you enable PIC? [22:11:34 CEST] <dragmore88> JEEB, as i said before.. the example doesnt cover my problem.. i have all in 1 source file, not 6 random wave files.. im just asking for help, and ive read the docs several times [22:12:18 CEST] <durandal_1707> dragmore88: then use [2:a][3:a].., join=6 ... [22:12:19 CEST] <JEEB> cryptopsy: seems like you do. various parts of hand-written SIMD use more registers than x86 has [22:12:33 CEST] <JEEB> (when PIC is enabled) [22:12:38 CEST] <cryptopsy> JEEB: what's pic? [22:12:42 CEST] <durandal_1707> JEEB: failure is in inline libpostproc asm [22:13:01 CEST] <durandal_1707> written eons before [22:13:12 CEST] <JEEB> cryptopsy: position independent code [22:13:34 CEST] <JEEB> cryptopsy: in other words one or more registers are being used to keep offsets if I recall correctly [22:13:36 CEST] <cryptopsy> JEEB: just CFLAGS="-march=native" [22:13:47 CEST] <cryptopsy> no flto no pipe no O3 [22:14:02 CEST] <JEEB> if you look at your build lines you clearly have PIC there [22:14:02 CEST] <cryptopsy> -j3 MAKEOPTS [22:14:11 CEST] <JEEB> -DPIC and -fPIC [22:14:25 CEST] <cryptopsy> so -fno-PIC should save it? [22:14:44 CEST] <JEEB> it would enable the SIMD to be built, if not then I was wrong :P [22:14:55 CEST] <JEEB> this is a 32bit x86 specific issue [22:15:10 CEST] <dragmore88> durandal_1707,is 2:a the 3rd source track or the 3rd target track ? [22:15:25 CEST] <JEEB> 3rd input file [22:15:26 CEST] <JEEB> audio track [22:15:30 CEST] <cryptopsy> is that -fno-PIC or -fno-pic ? [22:15:55 CEST] <JEEB> cryptopsy: I have no idea how gentoo calls it since it seems like it's overriding whatever FFmpeg's build system is doing [22:16:05 CEST] <JEEB> since you don't have --enable-pic in your configure [22:16:05 CEST] <cryptopsy> its a gcc option [22:16:16 CEST] <cryptopsy> the compiler is gcc .. [22:16:32 CEST] <JEEB> yes, but it is your gentoo build system setting that flag somehow, so have fun disabling it somehow [22:16:50 CEST] <JEEB> because there's a flag in FFmpeg's configure which is called --enable-pic, which does this. but that is nowhere to be seen [22:16:50 CEST] <dragmore88> something like this : ffmpeg -loglevel verbose -i "BBC_Short_HDR.mov" -filter_complex "[2:a][3:a][4:a][5:a][6:a][7:a]amerge=inputs=6[aout]" -map "[aout]" -acodec ac3 -ac 6 -ar 48000 -ab 448k test.ac3 ? [22:17:00 CEST] <JEEB> that's a single input file [22:17:12 CEST] <JEEB> in that case you want 0:a:N [22:17:13 CEST] <dragmore88> correct, as it has allways been [22:17:18 CEST] <dragmore88> k [22:17:34 CEST] <JEEB> 0th (1st) input file, audio Nth (N+1st) audio stream [22:17:47 CEST] <JEEB> (add one , after audio [22:18:08 CEST] <dragmore88> ffmpeg -loglevel verbose -i "BBC_Short_HDR.mov" -filter_complex "[0:a:2][0:a:3][0:a:4][0:a:5][0:a:6][0:a:7]amerge=inputs=6[aout]" -map "[aout]" -acodec ac3 -ac 6 -ar 48000 -ab 448k test.ac [22:18:23 CEST] <furq> you presumably want 0:a:0 through 0:a:5 [22:18:30 CEST] <dragmore88> (its the 3rd track counting from 0 since the first 2 are stereos [22:18:33 CEST] <furq> oh [22:18:33 CEST] <JEEB> he had two stereo tracks IIRC [22:18:37 CEST] <furq> yeah 2 to 7 is correct then [22:18:37 CEST] <JEEB> yea [22:18:43 CEST] <JEEB> looks good [22:18:50 CEST] <dragmore88> aaait [22:19:31 CEST] <dragmore88> [Parsed_amerge_0 @ 000001ea74bc5f40] No channel layout for input 1 [22:19:32 CEST] <dragmore88> [Parsed_amerge_0 @ 000001ea74bc5f40] Input channel layouts overlap: output layout will be determined by the number of distinct input channels [22:19:37 CEST] <dragmore88> ignore? [22:19:44 CEST] <furq> yeah you don't care about the input channel layout [22:21:14 CEST] <dragmore88> thx [22:21:18 CEST] <dragmore88> looks like its working [23:52:08 CEST] <leewdch> when I play an swf file it plays really fast for the first 5 seconds with desync audio that plays normally for the whole length of the video. what is happening? [23:52:39 CEST] <leewdch> I tried decompressing it first but same result [23:56:41 CEST] <tdr> you sure it was encoded right? [23:57:01 CEST] <leewdch> it plays correctly in the browser [23:57:11 CEST] <leewdch> it is also an old swf I found on internet [00:00:00 CEST] --- Mon Apr 30 2018

1 0

ffmpeg-devel.log.20180428
by burek 29 Apr '18

29 Apr '18

[00:41:38 CEST] <cone-184> ffmpeg 03Mark Thompson 07master:92a0a6bea9dc: hwcontext_vaapi: Fix compilation with libva versions < 1.4.0 [00:45:25 CEST] <cone-184> ffmpeg 03Mark Thompson 07release/4.0:44cb6474770e: hwcontext_vaapi: Fix compilation with libva versions < 1.4.0 [01:30:21 CEST] <atomnuker> nevcairiel: do the mysterious hls errors still get reported? [01:30:50 CEST] <atomnuker> a bunch of streaming websites have had issues for more than a week, so it might be just a coincidence [01:32:56 CEST] <atomnuker> smashcast for instance is hilarious, almost all requests 504, 404 or just time out [01:34:42 CEST] <klaxa> aren't they going bust soon anyway? [01:35:02 CEST] <wm4> what's this about [01:35:30 CEST] <klaxa> hitbox rebrand smashcast [01:35:45 CEST] <klaxa> twitch clone afaict [01:37:20 CEST] <klaxa> but with shitty websocket chat instead of irc like twitch [01:37:31 CEST] <klaxa> fucking webshits ruining everything [01:38:04 CEST] <atomnuker> no, just going through "corporate restructuring" and firing a bunch of people, though that's not a good sign [01:38:16 CEST] <klaxa> ah [01:38:41 CEST] <wm4> always cute when they don't actually have a way to make money [01:39:42 CEST] <atomnuker> 5-6 years ago there was own3dtv which for a time was almost an equal to twitch in size [01:40:12 CEST] <atomnuker> shame they didn't improve their awful pos player and failed purely because of it [01:41:57 CEST] <atomnuker> literaly all a streaming website had to do back then was to use html5 video to become a dominant platform [01:42:25 CEST] <atomnuker> but that didn't happen until somewhat recently for twitch [02:38:40 CEST] <kierank> michaelni: why not clip the rgb values [02:57:07 CEST] <cone-184> ffmpeg 03Mark Thompson 07n4.1-dev:HEAD: hwcontext_vaapi: Fix compilation with libva versions < 1.4.0 [04:00:01 CEST] <Chloe> BtbN: I think youre missing an obvious reason for cracks, games cost a lot [10:55:33 CEST] <durandal_1707> can i get review for my overlay slice threading patch? [10:56:19 CEST] <kierank> durandal_1707: we should remove non bitexact hpel crap, no? [10:57:15 CEST] <durandal_1707> what's gain of having non-bitexact at first place? [10:57:55 CEST] <kierank> durandal_1707: early 2000s thinking of people like michaelni of course [10:57:56 CEST] <kierank> as always [10:58:07 CEST] <kierank> cf thread on postproc [10:58:30 CEST] <durandal_1707> ? [10:58:54 CEST] <kierank> It's "faster" if you don't care about exact quality [10:59:07 CEST] <durandal_1707> how much faster? [10:59:16 CEST] <kierank> dunno [11:28:41 CEST] <cone-135> ffmpeg 03Paul B Mahol 07master:4f484edaa7ca: avfilter/vf_convolution: make rdiv set to 0 more useful [11:37:15 CEST] <durandal_1707> kierank: you no longer use overlay filter? [11:37:36 CEST] <kierank> I do but I have hardcoded ffmpeg version because everything breaks [11:37:50 CEST] <durandal_1707> what breaks? [11:38:09 CEST] <kierank> api [11:40:30 CEST] <durandal_1707> so you will not benefit from faster overlay filter in lavfi? [11:42:13 CEST] <kierank> https://github.com/FFmpeg/FFmpeg/commit/6442e4ab3cab573e6f86bfa6db096afd8ed… [11:42:17 CEST] <kierank> this is what broke api for me [11:42:25 CEST] <kierank> and why i am never touching lavfi in my code ever again [11:43:54 CEST] <nevcairiel> that commit seems pretty innocent, if you passed integer font sizes before it should still handle them like that after i would think [11:44:11 CEST] <kierank> iirc it doesn't work [11:44:26 CEST] <kierank> I had all the wrong font sizes [11:52:20 CEST] <durandal_1707> kierank: you are bad, bad, bad [13:11:53 CEST] <atomnuker> kierank: still not using systemd? [14:01:02 CEST] <loki_> good morning everyone [14:02:00 CEST] <loki_> so i have just gotten audio for this really obscure game codec working, however now when i add the audio stream and render an avi, the video is spep up by about 2x. any idea what might be the reason? it is clearly the audio, when i disable it again then video is normal speed [14:05:39 CEST] <wm4> wrong sample rate? [14:06:27 CEST] <loki_> thought of that. however audio is sounding normal and has the correct length. so the whole avi is set to 55 seconds, but the audio plays the full 100 seconds [14:07:08 CEST] <loki_> normally video should be 100 seconds too, but now plays faster and finishes at 55 [14:07:38 CEST] <loki_> mpc-hc says it is 24 fps, but plays visibly faster than 24 [14:07:43 CEST] <durandal_1707> wrong format? [14:10:04 CEST] <loki_> raw output to 22050 hz s16le 2ch sounds correct. the same i did in the code, not sure about avpriv_set_pts_info tho. currently i use this: avpriv_set_pts_info(ast, 33, 1, 22050); [14:10:12 CEST] <wm4> messed up timebases? [14:10:18 CEST] <atomnuker> or timestamps [14:10:39 CEST] <wm4> because avpriv_set_pts_info(ast, ...) is a complicated way to set st->time_base [14:13:18 CEST] <loki_> would it be better to set time_base directly? [14:13:32 CEST] <wm4> no [14:13:48 CEST] <wm4> I just mean you should check whether it's consistent with your pts values [14:18:28 CEST] <cone-135> ffmpeg 03Paul B Mahol 07master:5c6a3604f059: avcodec: remove duplicate prores decoder [14:18:29 CEST] <cone-135> ffmpeg 03Paul B Mahol 07master:99d24499c231: avcodec/proresdec2: make long name more descriptive [14:18:30 CEST] <cone-135> ffmpeg 03Paul B Mahol 07master:81d78fe13bc1: avcodec/proresdec2: add missing frame color metadata [14:18:31 CEST] <cone-135> ffmpeg 03Paul B Mahol 07master:c116ba375ea4: doc/libav-merge: remove resolved item [14:23:16 CEST] <durandal_1707> pp7 filter confirmed very blurry and too strong on d9 [14:48:17 CEST] <loki_> thanks for the info, it is definitely related to avpriv_set_pts_info, i just checked again [15:32:57 CEST] <durandal_1707> will apply overlay slice patch soon, as looks nobody gonna review it anytime soon [15:34:14 CEST] <wm4> so does anyone know if libavcodec/rawdec.c can accept arbitrary pixfmts? [15:34:42 CEST] <wm4> I mean it almost looks like it does [15:35:01 CEST] <wm4> (but only with minimal alignment) [15:35:31 CEST] <Chloe> durandal_1707: I would have loved to review it, but I'm honestly not experienced enough to review much on the ML [15:36:07 CEST] <durandal_1707> wm4: does raw supports colorspace, color_trc, color_primaries, color_range ? [15:37:14 CEST] <wm4> durandal_1707: I think it'll just pass them through from codecpar [15:37:25 CEST] <wm4> on that note I'm really glad we did this codecpar merge [15:37:36 CEST] <wm4> it's so much more defined what gets passed through and what not [15:38:46 CEST] <JEEB> yup [16:05:26 CEST] <durandal_1707> why slice threading init in lavfi cost so much? [16:19:45 CEST] <JEEB> hmm, did adding a new thing add a #define for it in config.h? [16:20:38 CEST] <JEEB> seems like yes [16:20:51 CEST] <JEEB> CONFIG_XXXX 1 [16:21:12 CEST] <wm4> durandal_1707: ? [16:25:07 CEST] <durandal_1707> wm4: i benchmarked filter with threads=1 and threads=4 and it gave only 10% gain [16:33:36 CEST] <wm4> how is that related to "init" [16:40:32 CEST] <JEEB> how did I in configure add a dependinng dependency to a demuxer? just yer usual string append with an if? [16:41:13 CEST] <JEEB> oh, the listing definition is before any of the functions [16:41:43 CEST] <JEEB> or is the _suggest [16:41:49 CEST] <JEEB> thing for possible deps? [16:43:19 CEST] <atomnuker> <name>_demuxer_deps="<component>" [16:43:36 CEST] <JEEB> yeah, but if it is dependant on libXXXX being enabled? [16:43:45 CEST] <JEEB> and I've ifdef'd it in the demuxer [16:44:07 CEST] <atomnuker> you don't need to ifdef it if its depending on it [16:44:33 CEST] <JEEB> yes, but the demuxer doesn't *require* it, it's just niced to get X,Y,Z if you do have it [16:44:39 CEST] <JEEB> ok, _suggest seems to be it [16:44:48 CEST] <atomnuker> no, that's not it [16:44:57 CEST] <atomnuker> say its optional if it is [16:45:12 CEST] <atomnuker> to make it optional add the ifdef flag to HAVE_ flags [16:45:36 CEST] <JEEB> ok, so there's an xxxx_demuxer_optional? [16:45:50 CEST] <atomnuker> and check it using enabled <component> && require <stuff to check> <component> [16:46:10 CEST] <JEEB> I already have the demuxer building without the library enabled, so the ifdefs are there correct [16:46:18 CEST] <atomnuker> no, itis called EXTERNAL_LIBRARY_LIST [16:46:22 CEST] <atomnuker> and HAVE_LIST [16:46:27 CEST] <atomnuker> you need to add it to both [16:46:54 CEST] <JEEB> EXTERNAL_LIBRARY_LIST I already of course have [16:47:12 CEST] <JEEB> and `enabled libaribb24 && require_pkg_config libaribb24 aribb24 "aribb24/aribb24.h" arib_instance_new` [16:47:15 CEST] <JEEB> is already there [16:47:20 CEST] <JEEB> so it gets the correct flags from pkg-config [16:47:38 CEST] <JEEB> and I have CONFIG_LIBARIBB24 in mpegts.c [16:47:42 CEST] <JEEB> ifs [16:48:08 CEST] <JEEB> so now all I need to libavformat get the aribb24 flags if libaribb24 is enabled + mpegts demuxer is enabled [16:48:18 CEST] <JEEB> and _suggests seems to do that? [16:48:50 CEST] <JEEB> I will be moving some of this functionality to a separate file, but currently it's all in mpegts.c so no separate file [16:49:56 CEST] Action: JEEB re-tests without aribb24 enabled [16:50:59 CEST] <JEEB> and yes, as soon as you add a single file into the library that has a specific dependency on a thing [16:51:05 CEST] <JEEB> the whole library gets those link flags [16:51:12 CEST] <JEEB> and it's suddenly much simpler :) [16:55:49 CEST] <JEEB> ok, _suggest seems to not make it require it if library isn't enabled it seems [16:55:52 CEST] <JEEB> which is gut [16:56:07 CEST] <JEEB> and it adds it as a dep to an existing thing if it is enabled [16:57:20 CEST] <JEEB> atomnuker: just for the context, this is how it came to look like now :) https://github.com/jeeb/ffmpeg/commit/5c225ac6917d483ce7a33f1c32366a33a3304… [16:57:35 CEST] <JEEB> also I need to add requirement for v3 [16:59:05 CEST] <atomnuker> is it that hard to decode sjis to utf8? [16:59:13 CEST] <JEEB> it's not SJIS [16:59:14 CEST] <JEEB> that's the joke [16:59:31 CEST] <JEEB> it's a special JIS coding defined at hte end of STD-B.24 or B.32 [16:59:40 CEST] <jamrial> JEEB: whatever_demuxer_deps="libaribb24" [16:59:47 CEST] <JEEB> jamrial: that's a requirement, right? [16:59:52 CEST] <JEEB> but I've ifdef'd it [16:59:52 CEST] <jamrial> yes [17:00:00 CEST] <JEEB> or well if'd [17:00:07 CEST] <JEEB> for the if'ing _suggest seemed to work [17:00:08 CEST] <jamrial> this is in configure, doesnt' matter what you did in the tree [17:00:13 CEST] <JEEB> yea [17:00:16 CEST] <jamrial> c files, i mean [17:00:23 CEST] <JEEB> see the commit I just linked, that seems to work [17:00:33 CEST] <JEEB> with both enabled and disabled for the lib [17:00:37 CEST] <jamrial> a demuxer that needs a external library must depend on said library being present to be enabled at all [17:00:48 CEST] <JEEB> it's an optional feature [17:00:51 CEST] <jamrial> oh, this is for mpegts [17:00:53 CEST] <JEEB> yes [17:01:05 CEST] <JEEB> it's my first part of integrating ARIB B.24 [17:01:05 CEST] <jamrial> yeah, _deps would make it required [17:01:10 CEST] <jamrial> i thought this was for a new demuxer [17:01:16 CEST] <atomnuker> JEEB: still, how hard would that be? [17:01:26 CEST] <JEEB> atomnuker: it's a fuckbig map [17:01:33 CEST] <JEEB> let's not duplicate it in avutil, shall we? [17:01:35 CEST] <jamrial> so yeah, _suggest is ok [17:02:46 CEST] <JEEB> but yea, this simple character conversion is just the first thing, after that I'll try adding demuxing and decoding of the captions [17:02:52 CEST] <JEEB> with the aribb24 library [17:03:38 CEST] <JEEB> and added libaribb24 to EXTERNAL_LIBRARY_VERSION3_LIST [17:03:45 CEST] <JEEB> since its license is LGPLv3 [17:04:13 CEST] <JEEB> although I guess since he already once relicensed from GPL to LGPL I'm not sure if he wouldn't be OK with LGPLv2+ [17:04:26 CEST] <JEEB> might poke him about that later [17:04:53 CEST] <j-b> you cannot. [17:05:01 CEST] <j-b> the relicensing is already very dodgy [17:05:13 CEST] <j-b> JEEB: you should consider this lib to be GPLv3, for the moment. [17:05:17 CEST] <JEEB> oh? [17:05:27 CEST] <JEEB> so there are old contributors [17:05:33 CEST] <JEEB> which he didn't consult with [17:05:45 CEST] <j-b> JEEB: it's a bit more complex than that. [17:07:10 CEST] <JEEB> ok, it seems like he just copied some things from VLC ad verbatim in 2014, possibly including the license file? [17:07:17 CEST] <j-b> indeed. [17:08:11 CEST] <JEEB> huh, the character code decoder at least was LGPLv2+ from the beginning it seems o_O [17:08:18 CEST] <JEEB> what on earth happened there [17:09:41 CEST] <j-b> JEEB: told you. [17:09:47 CEST] <j-b> JEEB: it's being discussed, btw [17:11:35 CEST] <JEEB> and the files copied from VLC seemed to be LGPLv2+ too by their headers [17:11:53 CEST] <JEEB> at least the amount of contributors can be counted on the fingers of one hand it seems [17:29:10 CEST] <Compn> oh no we lost the cone [17:34:51 CEST] <rcombs> JEEB: couldn't you just take any existing EUC decoder and swap out the char tables [17:36:39 CEST] <rcombs> e.g. https://github.com/bminor/glibc/blob/09533208febe923479261a27b7691abef297d6… [17:50:07 CEST] <Chloe> Compn: ? [17:50:09 CEST] <wm4> av_iconv [17:50:37 CEST] <Chloe> wm4: also add zip to lavf then you dont have to use libarchive with its encoding issues in mpv [17:51:43 CEST] <wm4> and instead have that in lavf [17:51:54 CEST] <wm4> I don't really agree that something like libarchive should be in lavf though [17:52:06 CEST] <wm4> it wouldn't integrate well and would cause all kinds of problems [17:52:28 CEST] <wm4> otherwise I'd be glad to leave yet another stinky feature to ffmpeg [17:54:59 CEST] <j-b> So, the HTTP server supports gzip compression? :D [18:01:11 CEST] <wm4> don't know [18:11:05 CEST] <cone-889> ffmpeg 03Mark Wachsler 07master:9d7535496356: fftools/ffmpeg: Add system time and real time to benchmarking. [18:11:05 CEST] <cone-889> ffmpeg 03Rahul Chaudhry 07master:e84212b78e00: swresample/arm: rename labels to fix xcode build error [18:11:05 CEST] <cone-889> ffmpeg 03André Camargo 07master:1322b00060d3: fftools/ffmpeg: change fps progress log message to show two decimal digits [18:25:36 CEST] <JEEB> rcombs: I dunno, this was just the first step in integrating that thing that will also do ARIB STD-B.24 captions [18:25:48 CEST] <JEEB> so just charset conversion seemed like the simplest thing to do [18:25:52 CEST] <JEEB> as the first step [18:35:06 CEST] <kierank> atomnuker: ubuntu 18.04 will force us [18:48:02 CEST] <atomnuker> oh, you skipped 16.04 [18:56:27 CEST] <kierank> atomnuker: yeah, systemd :) [18:56:43 CEST] <cone-889> ffmpeg 03Paul B Mahol 07master:d54014d1573e: avfilter/vf_overlay: add slice threading [19:00:52 CEST] <JEEB> kierank: as someone making services I felt like sysv < upstart < systemd. of course the problem was that debian-based distros for some reason kept around init files for all of the darn init systems so in the worst case you got a random one utilized [19:01:05 CEST] <JEEB> but I guess if you don't need to change, don't :) [19:02:47 CEST] <kierank> Got no choice, have to change for 18 [19:03:42 CEST] <JEEB> well yea [19:17:14 CEST] <durandal_1707> wm4: vapoursynth wrapper does not support alpha? [19:17:41 CEST] <wm4> durandal_1707: VS handles alpha as separate node, so it's kind of awkard... but we could [19:18:33 CEST] <durandal_1707> bad joke [19:24:27 CEST] <cone-889> ffmpeg 03Gyan Doshi 07master:96d7cbedbefd: doc/ffmpeg - update benchmark option readout details [19:55:39 CEST] <durandal_1707> ubitux: why fieldmatch doesn't use same defaults as vapoursynth VFM ? [19:56:25 CEST] <ubitux> maybe the defaults changed in vs [19:56:35 CEST] <ubitux> i don't remember changing them [19:56:59 CEST] <ubitux> but it was a long time ago [20:57:06 CEST] <durandal_1707> ubitux: you have hardcoded stuff for subsamplings, so it only works with yuv420p case [21:00:52 CEST] <durandal_1707> for y0/y1 using [21:05:21 CEST] <atomnuker> michaelni: you should probably remove https://github.com/FFmpeg/gas-preprocessor [21:05:49 CEST] <atomnuker> it hasn't been needed to build with simd support on arm for ages now [21:08:18 CEST] <JEEB> it was made for clang IIRC [21:08:32 CEST] <JEEB> and clang compatibility was only fixed to be good enough very recently [21:08:48 CEST] <JEEB> and wbs's fixes that make clang work without it went in just a few weeks ago [21:09:07 CEST] <atomnuker> it was needed for gcc too, wasn't it? [21:09:42 CEST] <JEEB> I never heard of that [21:09:51 CEST] <JEEB> I only heard of it in conjunction with clang [21:10:06 CEST] <atomnuker> no, I'm pretty sure it was needed for gcc 2 years ago as well [21:10:28 CEST] <atomnuker> well, its in 4.0 anyway so its technically no longer needed to build the latest release [21:12:14 CEST] <wbs> it's needed with clang < 5.0, super-old xcode toolchains that use standalone apple binutils 'as', and also for windows/arm with msvc tools [21:12:28 CEST] <JEEB> yup [21:12:53 CEST] <JEEB> and wasn't that <= 5.0? [21:13:07 CEST] <JEEB> since IIRC the check for clang only broke with the latest NDK clang [21:13:14 CEST] <JEEB> which I think should have been 6.0 development? [21:13:26 CEST] Action: JEEB goes check [21:13:41 CEST] <wbs> NDK r17 beta uses clang from october 2017 (despite the version number saying it's 6.0.1) [21:13:46 CEST] <wbs> october 2017 + patches [21:14:05 CEST] <wm4> so their version numbers lie or what? [21:14:28 CEST] <wbs> NDK r16 used clang from maybe march/april 2017; the altmacro stuff was merged in may 2017, and 5.0 branched in july 2017 [21:14:42 CEST] <JEEB> ok [21:14:44 CEST] <wbs> wm4: well 6.0.0 would have been accurate at least, dunno what things they've backported [21:15:06 CEST] <wbs> since clang trunk claimed to be 6.0.0 from after when 5.0.0 was branched [21:16:59 CEST] <wbs> but with modern tools (latest ndk, latest xcode), the only place where gas-preprocessor is necessary is for arm/arm64 with msvc tools (where it reformats the asm completely for use with armasm.exe) [21:17:34 CEST] <JEEB> so it's no longer needed for R16? [21:17:53 CEST] <wm4> does windows on arm still exist [21:18:01 CEST] <JEEB> yes [21:18:06 CEST] <wbs> JEEB: no, I meant latest == R17 [21:18:07 CEST] <JEEB> they're actually pushing out new devices [21:18:11 CEST] <JEEB> wbs: but that's still beta? [21:18:16 CEST] <wbs> JEEB: well yes [21:18:27 CEST] <JEEB> I'd rather call it the next version at this point of time [21:18:30 CEST] <JEEB> but details, details [21:18:31 CEST] <JEEB> ;) [21:18:37 CEST] <wbs> yes, my point was, "modern tools" [21:19:03 CEST] <wbs> wm4: windows phone is dead, but they're pushing it for windows desktop and server [21:19:16 CEST] <wbs> wm4: (arm64 then also, not only arm) [21:19:37 CEST] <JEEB> the work wbs did was exactly related to the desktop Windows on aarch64 [21:19:47 CEST] <JEEB> if I recall correctly :) [21:19:51 CEST] <wbs> yes [21:20:35 CEST] <wbs> (and using clang and llvm tools with mingw, which is like 90% of the effort; the aarch64 parts is pretty much good enough at the moment) [21:22:48 CEST] <wm4> why is MS pushing this? the only advantage I can see is that they can lock "secureboot" on those devices [21:23:41 CEST] <wbs> wm4: keeping all doors open? or maybe it's mostly qualcomm (and arm64 server chips manufacturers) pushing, and microsoft not denying it? [21:24:58 CEST] <JEEB> esp. if they already had the kernel etc done [21:25:04 CEST] <JEEB> and a lot of stuff cross-compilable [21:27:39 CEST] <Compn> Chloe : the cone bot timed out :P [21:29:01 CEST] <wm4> why is CE being cranky with me again [21:29:02 CEST] <wm4> what the fuck [21:29:10 CEST] <durandal_1707> what you expect? [21:29:27 CEST] <wm4> probably better if I just filter his email address and ignore anything that comes from him [21:29:51 CEST] <wm4> would that be against the dev policies or anything [21:30:11 CEST] <Compn> no [21:30:13 CEST] <Compn> do that [21:30:19 CEST] <Compn> thats fine [21:30:27 CEST] <atomnuker> no, don't [21:30:28 CEST] <wm4> ok [21:30:32 CEST] <wm4> now what [21:30:42 CEST] <atomnuker> don't do anything you wouldn't want done on yourself [21:30:51 CEST] <atomnuker> just ignore him unless you get replied to [21:31:02 CEST] <wm4> well he replied to my patch [21:32:47 CEST] <atomnuker> well don't do anything, its not like he asked you, he just told you an issue he saw once had a proposed fix which was the same as in your patch and didn't help, its irrelevant [22:35:51 CEST] <durandal_1707> ubitux: do i must sent every patch for fieldmatch to ML for review? [22:51:35 CEST] <ubitux> no it's ok if you're confident with your patches [22:56:48 CEST] <durandal_1707> well, i only have one that changes yuv444p fate test, because of hardcoded subsamplings for yuv420p [23:15:43 CEST] <cone-673> ffmpeg 03Paul B Mahol 07master:29fd44adf128: avfilter/vf_fieldmatch: use correct subsamplings for y0a, y1a and startx [00:00:00 CEST] --- Sun Apr 29 2018

1 0

ffmpeg.log.20180428
by burek 29 Apr '18

29 Apr '18

[00:11:40 CEST] <rindolf> furq: ping [00:21:22 CEST] <rindolf> Lite: <rindolf> furq: see http://www.shlomifish.org/Files/files/text/f.txt ==> do you know how to fix it? [00:24:00 CEST] <Lite> Unfortunely not. I am facing such not so much crutucal 'errors' connected with DTS but never in real faced that output file was incrorrect/wrong [00:24:36 CEST] <Lite> I have a question too [00:24:57 CEST] <Lite> to these guys who knows my issue I provided yesterday in detail [00:25:13 CEST] <Lite> with HTTPS URLs [00:25:45 CEST] <Lite> I just deleted all cryptography software but that's not affected [00:25:47 CEST] <Lite> but [00:26:47 CEST] <Lite> there switched on totally all possible to switch on, you know, Windows 10 OS components [00:26:59 CEST] <Lite> They included OpenSSL [00:27:49 CEST] <Lite> Could it be faced some, you know incompatibility between latest Nightly builds and OpenSSL? [00:28:15 CEST] <Lite> Which was not before released version 02.11.2017? [00:28:20 CEST] <Lite> ??? [00:36:18 CEST] <kepstin> you're talking about openssh? [00:36:23 CEST] <kepstin> completely unrelated [00:36:29 CEST] <Lite> Ye, ye [00:36:43 CEST] <Lite> should be ssh [00:36:44 CEST] <kepstin> (the version of openssh shipped in the windows components doesn't use openssl, it uses windows builtin crypto) [00:36:55 CEST] <Lite> wait no [00:36:56 CEST] <Lite> SSL [00:36:59 CEST] <Lite> OpenSSL [00:37:43 CEST] <Lite> Or SSH :D [00:37:46 CEST] <Lite> dunno [00:37:49 CEST] <Lite> :'C [00:38:30 CEST] <Lite> But SSL installed at my PC too definately [00:51:30 CEST] <rindolf> good night, all [00:54:25 CEST] <Guma> I am looking for advise and direction for my hobby project. I have application that I am reading images from IP camera. I have few of them to experiment and they provide different formats. Some are in raw format. What I would like to do is write service in C++ that I can connect with web browser and see image stream from remote camera. Since such cameras might be accessed over 4G LTE, speeds might very. Is anyone here who has done this can explain some [00:54:25 CEST] <Guma> general directions where to start? Maybe some sample code? [00:55:25 CEST] <Mavrik> Hmm, for starters, you probably don't need to write the service yourself at all. Would you consider a more script oriented approach? :) [00:57:25 CEST] <Guma> Mavrik I might. What scripting are you talking about? But I would prefer C++ since it is my language of choice [00:57:49 CEST] <Mavrik> Guma, basically for your use-case you probably don't have to write code at all [00:58:04 CEST] <Mavrik> You can just use ffmpeg directly to transcode streams and pass them on to something like nginx-rtmp-module [00:58:21 CEST] <Mavrik> Which acts as a streaming server for web and then use video.js or something to show it in the browser [00:58:46 CEST] <Mavrik> If you know nothing about how digital video is structured you'll have a pretty hard time with ffmpeg APIs [00:59:07 CEST] <Guma> Mavrik So I have already C++ library that is reading frames from camera (USB or IP) so how could I feed such frame directly to ffmpeg? [00:59:35 CEST] <Guma> Mavrik I do not might learning API. I got time :) [00:59:46 CEST] <Lite> Is there anybody who uses Fiddler? [01:00:08 CEST] <Guma> I just want to know where to start to be as much as efficient with my learning time [01:01:02 CEST] <Mavrik> Guma, ad [01:01:04 CEST] <Mavrik> *ah [01:01:06 CEST] <Guma> I see there is ffserver. This sounds something like I would like to do [01:01:13 CEST] <Mavrik> Guma, yeah, you'd have to look at libav API [01:01:18 CEST] <Mavrik> ffserver is dead, don't touch that :P [01:01:21 CEST] <Guma> I am doing some processing in OpenCV first then publish [01:01:42 CEST] <Mavrik> basically you'll have to use libavcodec to encode frames into a video stream [01:01:48 CEST] <Mavrik> and then libavformat to mux it into a container [01:01:58 CEST] <Mavrik> then send it to nginx-rtmp-module or equivalent streaming server [01:02:10 CEST] <Mavrik> (ffmpeg / libavformat knows how to do that for you) [01:02:31 CEST] <Mavrik> I'd try first setting up a pipeline with plain ffmpeg and static file so you get the web part working [01:02:37 CEST] <Mavrik> And then start writing C++ :) [01:02:39 CEST] <Lite> Just strange...after I installed Cryptographic software and setted ip how it should working in 2017 (I used also Fiddler before and didn't see such request), it starts to show some csp/ocsp requests [01:02:51 CEST] <Mavrik> Guma, there's an example folder in ffmpeg source :) [01:03:01 CEST] <Guma> Mavrik do you know of any decent sample tutorial code so I can start go over and read API docs? [01:03:15 CEST] <Guma> You just did beat me with answer [01:03:21 CEST] <Lite> user agent there in request headers shows as 'Microsoft-CryptoAPI/10.0' [01:03:28 CEST] <Mavrik> Sadly the documentation isn't that stellar [01:03:46 CEST] <Guma> Ok I will go download the source and look there. [01:03:49 CEST] <Mavrik> Guma, this helped me a lot as well: https://www.ffmpeg.org/doxygen/3.4/index.html [01:03:58 CEST] <Lite> It still continue. Even after uninstalling all cryptographic software from machine [01:03:59 CEST] <Guma> So if I have any question is this best channel to ask? [01:04:13 CEST] <Mavrik> It's as good as it gets I think :P [01:04:52 CEST] <Lite> Could this sh*t 'Microsoft-CryptoAPI/10.0' affect my issue????! Untill I won't switch it off? [01:05:08 CEST] <Lite> kepstin? [01:05:11 CEST] <Guma> Sweet. Thank you. Will start there [01:08:41 CEST] <Guma> Mavrik I was wondering if I build all libs from source at some point for specific hardware is there any speed gain? I am on Ubuntu 16.04. Is the latest packages good or there is a benefit to use latest and build from source. [01:09:15 CEST] <Mavrik> Hmm, the bigger concern is that 16.04 probably has stone age ffmpeg in repos [01:09:35 CEST] <Mavrik> Performance won't differ much because pretty much all hot codepaths are handtuned ASM for popular codecs [01:09:41 CEST] <Mavrik> Which is loaded according to CPU capabilities [01:09:53 CEST] <Guma> Ok so building from source will be first step [01:09:55 CEST] <Mavrik> So you'd only be optimizing most of the code that doesn't really do any CPU work :P [01:10:05 CEST] <Mavrik> But yeah, I'd suggest you build from source [01:10:18 CEST] <Mavrik> And while developing link against ffmpeg with debug symbols enabled and optimizations disabled [01:10:23 CEST] <Mavrik> So you can use gdb to step through ffmpeg code as well [01:10:25 CEST] <Guma> I was thinking like enabling SSE4 or anything else specific to my hardware. [01:10:58 CEST] <Guma> I might worry about this later but I am just asking for future. [01:11:00 CEST] <Mavrik> As I said, the places where that helps already have AVX etc. code written [01:11:07 CEST] <Mavrik> And will use it if they detect you have a CPU capable of that. [01:11:12 CEST] <Mavrik> Other places aren't doing anything CPU intensive :) [01:12:43 CEST] <Guma> ok. Thank you for you help and time. Talk soon [04:09:44 CEST] <oerg866> Problem: -f concat with multiple VOB files with MPEG2 + PCM audio streams, with -c copy into a new VOB or MPG files, audio is unplayable. MPC-HC detects it as "MPEG audio 11025 hz" instead of PCM. [04:10:45 CEST] <oerg866> https://i.snag.gy/G8kmn3.jpg https://i.snag.gy/hXJ6OR.jpg [04:11:54 CEST] <oerg866> command: ffmpeg -f concat -safe 0 -i list.txt -codec copy output.mpg (or vob) [04:22:01 CEST] <oerg866> " [04:22:01 CEST] <oerg866> At this time, ffmpeg does not write the header for LPCM streams in MPEG-1/2 when streamcopying." [04:22:05 CEST] <oerg866> is this a bug???? [10:29:18 CEST] <rindolf> hi all [10:41:00 CEST] <rindolf> furq: hi! See http://www.shlomifish.org/Files/files/text/f.txt [10:48:10 CEST] <rindolf> Hi all! I have an issue with overlaying audio and video - see https://github.com/shlomif/pysolfc-black-hole-solver--screencast and http://www.shlomifish.org/Files/files/text/f.txt [11:22:27 CEST] <ChocolateArmpits> rindolf, have you tried another version? [11:23:13 CEST] <rindolf> ChocolateArmpits: what for? [11:23:21 CEST] <ChocolateArmpits> so see if that works [11:24:07 CEST] <rindolf> ChocolateArmpits: no [11:24:31 CEST] <rindolf> ChocolateArmpits: ok, let me build 3.x.y [11:39:29 CEST] <helmo_> hello there, sorry for probably newbie question, is it normal to get THIS.. "WARNING: Building with deprecated library libavresample" and if not how to solve it? am i missing something? [11:40:13 CEST] <helmo_> its appeared now when trying v 4.0 [11:41:01 CEST] <helmo_> and obviously fails the build any hintt? [11:41:03 CEST] <durandal_1707> helmo_: do not build it and do not use it [11:42:48 CEST] <helmo_> @durandal_1707 ??? [11:50:02 CEST] <rindolf> ChocolateArmpits: same problem with 3.4.2 [11:51:09 CEST] <ChocolateArmpits> rindolf, have you tried omiting parameters like -shortest or the timestamp filter ? [11:51:13 CEST] <helmo_> 3.4.2 for me builds just fine its only v 4 which seem have this issue [11:51:59 CEST] <rindolf> ChocolateArmpits: which timestamp filter? [11:52:11 CEST] <ChocolateArmpits> asetpts=PTS-STARTPTS [11:52:58 CEST] <ChocolateArmpits> I don't see why you would need to create timestamps like this [11:53:04 CEST] <durandal_1707> helmo_: post your full configure line [11:55:31 CEST] <helmo_> @durandal_1707 https://pastebin.com/fi9MtKdn [11:55:32 CEST] <rindolf> ChocolateArmpits: https://github.com/shlomif/pysolfc-black-hole-solver--screencast/blob/maste… - this is with ffmpeg 3.4.2 [11:57:20 CEST] <ChocolateArmpits> rindolf, and this fails too right ? [11:57:40 CEST] <rindolf> ChocolateArmpits: i get a zero length file [12:04:07 CEST] <ChocolateArmpits> rindolf, well best I can suggest is to rewrap each file separately to see if there's an offender [12:04:25 CEST] <ChocolateArmpits> or remove shortest and set the target length for the audio input directly [12:04:55 CEST] <ChocolateArmpits> via the duration input option -t [12:04:58 CEST] <rindolf> ChocolateArmpits: wo -shortest i only get thhe first frame of the video [12:05:18 CEST] <rindolf> with the full audio [12:05:47 CEST] <ChocolateArmpits> try rewrapping that one separately [12:06:30 CEST] <rindolf> ChocolateArmpits: what is rewrapping? [12:06:42 CEST] <ChocolateArmpits> remuxing lol [12:07:01 CEST] <rindolf> ChocolateArmpits: what? [12:07:17 CEST] <ChocolateArmpits> pick the ogv file and do a -c copy just with it [12:07:38 CEST] <ChocolateArmpits> see if it plays back afterwards [12:10:27 CEST] <rindolf> ChocolateArmpits: it has no video [12:11:30 CEST] <durandal_1707> helmo_: remove this line: --enable-avresample [12:11:37 CEST] <rindolf> ChocolateArmpits: can you test it yourself? See https://github.com/shlomif/pysolfc-black-hole-solver--screencast [12:12:39 CEST] <ChocolateArmpits> rindolf, ok I'll take a look [12:12:43 CEST] <helmo_> @durandal_1707 thx will try [12:12:49 CEST] <rindolf> ChocolateArmpits: thanks [12:17:42 CEST] <ChocolateArmpits> rindolf, the timestamps for the ogv file are all over the place [12:18:50 CEST] <ChocolateArmpits> in the stream audio they go backwards somehow, the video stream has them start at some ridiculous value then suddenly jump to normal [12:19:31 CEST] <ChocolateArmpits> I think you'll have to transcode the video [12:19:42 CEST] <ChocolateArmpits> to set timestamps properly [12:21:47 CEST] <helmo_> @durandal_1707 nope even omitting --enable-avresample it fails [12:22:09 CEST] <helmo_> @durandal_1707 thanks anyway [12:22:22 CEST] <rindolf> ChocolateArmpits: ah [12:24:22 CEST] <oerg866> Question: Is there a way to make -shortest consider only audio and video? I'm also copying a subtitle stream and since that only displays something at the start of the file the resulting output is as long as that subtitle XD [12:26:17 CEST] <durandal_1707> helmo_: that add --disable-avresample [12:26:33 CEST] <durandal_1707> and it warnings are not errors [12:26:55 CEST] <ChocolateArmpits> rindolf, you can check timestamps using this: ffprobe -select_streams a -show_packets -print_format json=c=1 file.ogv [12:27:06 CEST] <ChocolateArmpits> where select_streams will select the stream type [12:27:35 CEST] <durandal_1707> helmo_: pastebin ffbuild/config.log [12:27:47 CEST] <rindolf> ChocolateArmpits: hi [12:28:29 CEST] <rindolf> ChocolateArmpits: this is the original file - i want to extract a duration from it - http://www.shlomifish.org/Files/files/video/out.ogv [12:29:42 CEST] <rindolf> ChocolateArmpits: i tried "ffmpeg -ss 2.0 -to 1:27 -i out.ogv -c copy out2.ogv " but it yielded the bad file [12:29:57 CEST] <ChocolateArmpits> rindolf, you need to transcode the file for it to work [12:30:04 CEST] <ChocolateArmpits> as I said before [12:31:32 CEST] <helmo_> @durandal_1707 rebuilding... i'll post the log as soon its done [12:32:11 CEST] <helmo_> trashed the other before reading.. :( [12:33:27 CEST] <ChocolateArmpits> rindolf, ffmpeg can't fix timestamps without reencoding the file [12:34:24 CEST] <rindolf> ChocolateArmpits: ah [12:35:24 CEST] <rindolf> ChocolateArmpits: wouldn't that be lossy? [12:36:40 CEST] <ChocolateArmpits> well of course it is, but the video content is static, don't think it's going to hurt by any margin [12:37:10 CEST] <helmo_> @durandal_1707 log too long for non pro user, hope you dont mind i made a zip here sorry for the hassle... https://workupload.com/file/rHyQ6gw [12:37:29 CEST] <helmo_> anyway didnt work either [12:37:30 CEST] <rindolf> ChocolateArmpits: wo -c copy, the result was bad [12:37:37 CEST] <ChocolateArmpits> rindolf, I already told you why [12:38:06 CEST] <rindolf> ChocolateArmpits: without -c copy, the result was bad [12:38:23 CEST] <ChocolateArmpits> how bad ? [12:38:35 CEST] <rindolf> ChocolateArmpits: very low quality [12:38:46 CEST] <ChocolateArmpits> rindolf, so set the bitrate [12:38:52 CEST] <rindolf> ChocolateArmpits: ok [12:39:11 CEST] <ChocolateArmpits> your current video has 1mbps listed, you can try specifying the same [12:42:42 CEST] <durandal_1707> helmo_: make clean && make distclean ?? [12:43:25 CEST] <helmo_> @durandal_1707 same [12:46:34 CEST] <durandal_1707> helmo_: why --as=yasm ? [12:49:15 CEST] <helmo_> @durandal_1707 always used as since v3 in osx it wouldn't work without it [12:50:20 CEST] <helmo_> @durandal_1707 was some issue with xcode [12:50:36 CEST] <durandal_1707> --as=clang should be [12:51:03 CEST] <durandal_1707> looks like your build environment is broken [12:52:03 CEST] <helmo_> @durandal_1707 curious thing is 3.4.2 still builds.. [13:20:36 CEST] <rindolf> durandal_1707: hi, how can I trim the duration of this file while preserving quality? http://www.shlomifish.org/Files/files/video/out.ogv [13:22:40 CEST] <rindolf> durandal_1707: i tried ffmpeg -ss 2.0 -to 27.0 -i out.ogv -b:v 1M -bufsize 1M -crf 18 -preset veryfast out5.ogv --- there is a loss of quality [13:24:47 CEST] <rindolf> anyone? [13:26:42 CEST] <durandal_1707> nobody sane uses ogv [13:36:32 CEST] <rindolf> durandal_1707: ok, that is what http://recordmydesktop.sourceforge.net/about.php gave me [13:49:03 CEST] <rindolf> durandal_1707: apparently there is http://www.maartenbaert.be/simplescreenrecorder/ which gives an .mkv file - is that better? [13:52:30 CEST] <rindolf> anyone? [13:52:43 CEST] <durandal_1707> dunno, never tried, just know that ogv support is flaky in ffmpeg [13:52:54 CEST] <rindolf> durandal_1707: ah [14:12:17 CEST] <rindolf> durandal_1707: yay! Working now with .mkv - thanks [14:13:11 CEST] <JEEB> -39 [14:36:32 CEST] <rindolf> durandal_1707: here is the final result - http://www.shlomifish.org/Files/files/video/pysolfc-bhs-with-audio.mkv [14:37:39 CEST] <durandal_1707> this channel is logged, so do not post important stuff [14:38:41 CEST] <rindolf> durandal_1707: yes, i know [14:38:57 CEST] <rindolf> durandal_1707: it is public [15:20:02 CEST] <rindolf> yay! it is now live at https://www.youtube.com/watch?v=t_cuDHj5V2k&feature=youtu.be [16:56:45 CEST] <oerg866> hi I have an mpeg2 stream that changes aspect ratio in the middle for some reason from 4:3 to 16:9, can I fix the file to.... not do that? I tried DVDpatcher to fix the headers but that doesn't work [17:14:29 CEST] <Mavrik> oerg866: that's probably because SAR changes [17:14:35 CEST] <Mavrik> It's standard in broadcast TV [17:14:46 CEST] <Mavrik> I guess you could use a setsar= filter to lock the video to a single SAR [17:14:55 CEST] <oerg866> wouldn't that require me to re-encode [17:15:04 CEST] <JEEB> if the content is actually of a specific SAR [17:15:12 CEST] <JEEB> you could rewrite the stream SAR with the bitstream filter [17:15:21 CEST] <JEEB> there's one recently added for MPEG-2 headers [17:15:28 CEST] <JEEB> *MPEG-2 Video [17:15:28 CEST] <Mavrik> oerg866: by MPEG2 i'm assuming you have a MPEG-2TS file captured from a broadcast TV? :) [17:15:41 CEST] <oerg866> not TS, it was in VOB format [17:15:45 CEST] <Mavrik> because TS signals those changes as a packet in the stream so I guess it's possible to drop it [17:15:49 CEST] <oerg866> just to make things clear, this is how it starts: https://i.snag.gy/356Dps.jpg [17:16:16 CEST] <oerg866> and then it goes to this for no reason: https://i.snag.gy/NASewi.jpg [17:16:17 CEST] <Mavrik> Yeah, VOB is structurally not far away from TS. [17:16:30 CEST] <JEEB> it's PS [17:16:39 CEST] <JEEB> program stream VS transport stream [17:17:01 CEST] <JEEB> oerg866: if you are sure the content is actually of one aspect ratio [17:17:06 CEST] <JEEB> cbs_mpeg2 is probably what you want [17:17:11 CEST] <oerg866> yes, it is all 4:3 [17:17:20 CEST] <oerg866> the video is from 1984 and remained unchanged,it's just the stream that's messed up [17:17:57 CEST] <JEEB> too bad I don't remember if or how you can do the header modification with ffmpeg.c [17:18:32 CEST] <oerg866> i have tried a couple patcher programs now that supposedly fix this but no luck so far [17:18:59 CEST] <JEEB> the bit stream filter is seemingly there now in FFmpeg's libraries but I've just never used it :P [17:19:04 CEST] <JEEB> (through the command line) [17:19:20 CEST] <oerg866> interestingly, if I use mpgpatcher to force 1:1 aspect ratio [17:19:36 CEST] <oerg866> then it is played as 1:1 throughout by both windows 10's media player and MPC-HC [17:19:47 CEST] <oerg866> but if i patch it back to 4:3 it switches to 16:9 in the middle as usual [17:19:52 CEST] <oerg866> ?!?!?! [17:21:01 CEST] <oerg866> ah actually, windows' thingy gets confused, drops frames and changes aspect ratio to 16:9 and then 1:1 again shortly after [17:21:11 CEST] <oerg866> this is getting very fishy I think the file might just be unlucky :P [17:21:50 CEST] <oerg866> I can reduce the file to the offending parts and upload somewhere if someone more knowledgeable wants to try his luck :-) [17:23:31 CEST] <oerg866> https://drive.google.com/open?id=1dV_OZTWAENVV56ZdrNWg0RgZX4DzoZy1 [17:23:52 CEST] <oerg866> I'm out of ideas now :-) [17:26:55 CEST] <Mavrik> Hmm, you're probably just confusing the video player with non-standard AR [17:27:06 CEST] <Mavrik> And most likely mpegpatcher isn't doing anything hence why you're still seeing the switch :P [17:27:17 CEST] <Mavrik> It should scan the stream and throw away all the AR change packets [17:28:03 CEST] <oerg866> mpegpatcher is just patching sequence headers [17:28:15 CEST] <oerg866> if theres a program to ditch the packets let me know :S [17:29:19 CEST] <oerg866> interestingly if I remux into mkv the switch doesn't happen [17:29:29 CEST] <oerg866> but if i mux the mkv back to mpg or vob it happens again [17:29:31 CEST] <oerg866> so weird [17:29:55 CEST] <oerg866> according to mpegpatcher all headers now say 4:3 but if theres some packets inbetween i dunno [17:36:07 CEST] <oerg866> I would just try and find another recording of this but this is the only PAL/25fps version of this clip I could find, all dvd releases are 480i :( [17:45:07 CEST] <Mavrik> Yes, that's because mkv doesn't support AR switching. [17:45:37 CEST] <Mavrik> (Which kinda surprises me.= [18:26:26 CEST] <JEEB> Mavrik: I think it has more to do with "do you trust container vs contained format" [18:26:46 CEST] <JEEB> and while matroska in theory supports multiple extradata blocks, those aren't used [18:27:06 CEST] <JEEB> and usually when you mux into matroska extradata/init data packets get dropped [18:27:13 CEST] <JEEB> I mean, in-band [18:27:20 CEST] <JEEB> so you lose the update even if it was there [18:32:25 CEST] <Mavrik> mhm [18:32:44 CEST] <JEEB> of course some muxers will not filter those out [18:32:45 CEST] <Mavrik> I'm surprised because I managed to mux some of H.264 into FLV and the AR change code stayed [18:32:57 CEST] <JEEB> yea, FLV does in-band [18:33:02 CEST] <JEEB> as far as I know [18:33:08 CEST] <Mavrik> And it's surprising in a way that I'd expect MKV to keep those packets as well. [18:33:19 CEST] <Mavrik> Although the whole 4:3 / 16:9 switch is now kinda obsolete. [18:33:20 CEST] <JEEB> or at least I don't know of muxers that aproactively "clear" those init packets out [18:33:34 CEST] <JEEB> with matroska or mp4 I wouldn't be surprised [18:33:43 CEST] <JEEB> if various muxers were "helpful" [18:33:51 CEST] <JEEB> and removed "duplicated" init packets [18:35:12 CEST] <Mavrik> Yeah, especially since MP4 has all of that info in the header. [22:30:32 CEST] <v1v1> Simple command ( cat /home/ec2-user/FILES/*.jpg* | /home/ec2-user/ffmpeg/ffmpeg -f image2pipe -i /dev/stdin /home/ec2-user/OUT.MP4 ) failing with warning ( [image2pipe @ 0x4f45bc0] Could not find codec parameters for stream 0 (Video: none, none): unknown codec Consider increasing the value for the 'analyzeduration' and 'probesize' options ) and error ( Output file #0 does not contain any stream ). Any recommendations? [22:31:00 CEST] <v1v1> Full output pasted at: https://pastebin.com/2tChqvvq [22:34:14 CEST] <furq> why not just use -pattern_type glob -i *.jpg [22:45:50 CEST] <v1v1> furq: thanks, giving that approach a try [00:00:00 CEST] --- Sun Apr 29 2018

1 0

ffmpeg-devel.log.20180427
by burek 28 Apr '18

28 Apr '18

[00:00:44 CEST] <michaelni> JEEB, is it known why it segfaults ? [00:00:56 CEST] <JEEB> yes, the post I did links to a fix to the segfault [00:01:04 CEST] <JEEB> but apparently those output files don't work in browsers either [00:01:13 CEST] <JEEB> according to that akamai person in his first attempt at getting that patch through [00:03:38 CEST] <jamrial> who wrote support for webm in dashenc to begin with? [00:04:50 CEST] <JEEB> Peter Grosse and it seems to have gotten merged from Libav. [00:05:02 CEST] <JEEB> 7295b7373862ee54903b33d6ef3335531dfa93ad [00:05:20 CEST] <JEEB> 1b8ef01f04ab2210a26b59d3a1a62daed52ce88a being the merge commit by rcombs [00:05:43 CEST] <JEEB> granted, the segfault fix is also by rodger, so he did indeed fix it and send the patch to the ML [00:06:24 CEST] <JEEB> although let me check git blame specifically on that part of code [00:09:09 CEST] <cone-026> ffmpeg 03Paul B Mahol 07master:6a955750d670: avfilter/vf_maskedclamp: add slice threading [00:09:19 CEST] <JEEB> the reason for the segfault I've also explained in my first comment to the first attempt of the akamai person to have that patch go upstream https://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228433.html [00:09:32 CEST] <JEEB> (when I still didn't know he had commented on rodger's initial fix) [00:34:49 CEST] <Chloe> JEEB: they should be waiting at least 3 days [00:35:10 CEST] <JEEB> Chloe: I think the biggest thing is that I commented on his first attempt [00:35:23 CEST] <JEEB> thus he knew that I had shown interest towards the patch [00:35:32 CEST] <michaelni> JEEB, i see the crash now [00:35:55 CEST] <Chloe> JEEB: oh then he pushed before you reviewed the second part. [00:35:55 CEST] <michaelni> also happens with vp8 [00:36:03 CEST] <JEEB> yes, it happens with everything [00:36:07 CEST] <JEEB> I linked the explanation for it [00:36:15 CEST] <JEEB> https://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228433.html [00:36:38 CEST] <JEEB> basically because it was calling write_header before init() was called [00:36:54 CEST] <JEEB> the rcombs patch I linked in https://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/229058.html [00:36:57 CEST] <JEEB> would fix the crash [00:37:27 CEST] <JEEB> but according to the akamai person even fixing the crash didn't make that webm file work in browsers so I have no idea if the output is valid or not after that [00:37:44 CEST] <michaelni> I think we should give Jeyapal a chance to comment, as he activly works on dashenc and i didnt activly follow it. [00:38:16 CEST] <michaelni> but the segfault needs to be fixed [00:38:30 CEST] <JEEB> sure, I'm just saying that we might as well remove the broken thing if we're OK with rugging these things under the rug [00:38:56 CEST] <JEEB> because that way the segfault doesn't exist any more instead of currently still being there [00:39:43 CEST] <JEEB> because if a feature possibly never worked then removing it technically doesn't constitute a removal, I think? [00:39:52 CEST] <wm4> I'd rather have ffmpeg crash than people distributing broken encodes [00:40:16 CEST] <JEEB> I agree [00:40:31 CEST] <JEEB> but if the feature probably never worked and could be removed [00:41:16 CEST] <JEEB> that way you get rid of the crash and the end result is cleaner [00:41:53 CEST] <JEEB> just for the record, I'm just really pissed that this got committed - esp. with the commit message it has [00:42:08 CEST] <JEEB> when you note that you set the "default" for something it means you have alternatives [00:42:27 CEST] <JEEB> in this case it's not about alternatives, the thing's just moved away from a crashing thing [00:44:46 CEST] <JEEB> and since I'm the only one seemingly having a problem with this, I will be probably seen as the bad guy who doesn't even post any patches [00:46:16 CEST] <michaelni> JEEB, its not just you, i also see the apparent bad commit message but i did not closely follow the dashenc changes so i dont want to jump to quick conclusion as theres too much i dont know about this [00:47:31 CEST] <JEEB> I only happened to know about the problem because I helped a facebook person to locally fixup the thing, and most likely that person then contacted this person to "fix" the issue [00:47:58 CEST] <Chloe> JEEB: doesn't really matter if you dont submit tons of patches, you are knowledge and your opinion is useful [00:48:16 CEST] <JEEB> but anyways, I will just shut up and go to sleep. not the best of evenings. not because I care about dashenc. but because this seems like against how this thing should work [00:48:47 CEST] <JEEB> (to be honest if it was just about dashenc and not about commit/pushing etiquette I would just be non-caring) [00:49:09 CEST] <JEEB> (unless someone wanted help around me and I happened to poke into it while helping someone) [00:49:21 CEST] <JEEB> anyways, | [01:06:06 CEST] <cone-026> ffmpeg 03James Almer 07master:dff1fb27aaf0: avcodec/cbs: create reference counted fragments in ff_cbs_read_extradata() [01:06:07 CEST] <cone-026> ffmpeg 03James Almer 07master:05c0f620bf14: avcodec/cbs_mpeg2: use existing buffer reference when splitting fragments [01:13:01 CEST] <Chloe> so what else can we deprecate/remove? [01:16:31 CEST] <cone-026> ffmpeg 03Aukasz Krzciuk 07master:48330500efd6: avformat/mpegts: set AV_DISPOSITION_DESCRIPTIONS for OIPF cases [01:16:57 CEST] <jkqxz> Chloe: FF_QP2LAMBDA. [01:17:03 CEST] <Chloe> jamrial: what does postproc give over normal filters? [01:17:21 CEST] <jamrial> i don't know, why do you ask me? [01:18:35 CEST] <Chloe> jamrial: you seemed to be supporting merging over just removing it entirely, was just wondering why [01:21:01 CEST] <jamrial> because keeping the filter in a simpler form is better than just removing it [01:22:33 CEST] <wm4> libpostproc was simply an ancient filter framework [01:23:29 CEST] <Chloe> Why shouldn't the libpostproc filters just be moved to lavfi? (and I think there are a few equivalents already) [01:24:19 CEST] <iive> that's actually good idea [01:25:01 CEST] <wm4> lol all this effort for something that barely matters and at most is used by some old mplayer fans [01:26:26 CEST] <jamrial> i'm fine moving the postproc code inside the pp filter and killing the library, or just moving the library out of the main repository [01:26:37 CEST] <jamrial> but you're not going to have much luck removing both altogether [01:26:38 CEST] <wm4> all while ffmpeg still can't correctly convert hdr video etc., unless you know the magic switches [01:26:51 CEST] <wm4> Libav moved it to a separate repo [01:26:55 CEST] <wm4> ffmpeg didn't care [01:27:28 CEST] <jamrial> no, the other way around. libav didn't care about the library, since the maintainer wasn't in that project [01:27:41 CEST] <nevcairiel> libpostproc was moved to a separate repo, but for some reason it was never removed from the main tree [01:27:55 CEST] <nevcairiel> so more like "copied" [01:28:04 CEST] <jamrial> is it even kept up to date? [01:28:18 CEST] <nevcairiel> no, because people forgot that it even exists [01:28:25 CEST] <wm4> does libpostproc change? [01:28:42 CEST] <jamrial> if it is, then just send a patch to use said out of tree version. if it isn't, then also make it up to date [01:28:44 CEST] <wm4> nevcairiel: what do you mean [01:29:40 CEST] <wm4> I don't see it here https://git.libav.org/?p=libav.git;a=tree [01:30:08 CEST] <nevcairiel> libav dropped it entirely [01:30:16 CEST] <nevcairiel> http://git.videolan.org/?p=libpostproc.git;a=summary [01:30:25 CEST] <nevcairiel> hasnt really been updated much since the initial copy [01:30:34 CEST] <jamrial> 2012, wtf [01:31:15 CEST] <jamrial> so just tidy that repo up, make ffmpeg configure look for it, and remove it from the main repo [01:31:32 CEST] <wm4> basically yes [01:31:47 CEST] <wm4> I think D404 actually intended that ffmpeg uses it too [01:31:57 CEST] <nevcairiel> probably bikesheeding ensued [01:38:58 CEST] <atomnuker> better start from scratch rather than that repo [01:39:36 CEST] <atomnuker> the filter's probably going to bitrot to hell so might as well deprecate that one too [01:39:59 CEST] <iive> then go and start from scratch. [01:40:34 CEST] <iive> i see this bitrot used a lot as excuse for removing things, that doesn't seem to rot. [01:41:10 CEST] <iive> i just want to have good postprocessing filter, that can make old crappy videos less ugly [01:41:22 CEST] <iive> and not consume a whole core. [01:41:54 CEST] <wm4> what we need is a new libswscale [01:42:46 CEST] <wm4> what kind of core gets maxed out by 320p video [01:43:12 CEST] <nevcairiel> if i'm processing a video with ffmpeg, i would hope it always maxes my core, the more the merrier =p [01:44:16 CEST] <wm4> I'm assuming realtime playback [01:44:50 CEST] <iive> well, spp does excellent work of making blocky videos nice and smooth. it only does fdct and idct once for each pixel. [01:45:25 CEST] <wm4> you mean nice and blurry [01:46:53 CEST] <jamrial> spp doesn't seem to use libpostproc, though [01:46:54 CEST] <iive> well, if you like it extra smooth :P [01:47:18 CEST] <iive> jamrial, that's the point. if there is no pp, then i should use spp. [02:00:37 CEST] <Chloe> klaxa: do you have a list of the features you would like to implement for ffserver? [02:00:49 CEST] <klaxa> ah right, i was making that list [02:01:18 CEST] <klaxa> https://gist.github.com/klaxa/a170a1c963463141a392cf53da20ae89 [02:01:27 CEST] <klaxa> what i have right now [02:02:12 CEST] <klaxa> i've looked a bit at hlsenc.c and it looks like it can only work on files on disk? [02:02:37 CEST] <klaxa> i've been trying to keep everything in memory for now [02:07:04 CEST] <klaxa> hmm maybe i should read the code instead of doxygen :D [02:07:53 CEST] <Chloe> klaxa: since you're not doing nginx, I'm sort-of interested in doing RTSP for that module I linked you. (or at least looking at it since you said you had no idea) [02:09:21 CEST] <klaxa> okay, well i started to read about how to write nginx modules and stuff, also i think if i make it properly implementation independent it should also be possible to put all that in nginx modules [02:09:39 CEST] <klaxa> that sentence didn't end the way i thought it would when i started to write it [02:10:07 CEST] <klaxa> anyway, sounds good i guess? [02:13:03 CEST] <klaxa> well i wasn't sure because nginx does http and rt(s)p uses udp so... [02:13:19 CEST] <Chloe> klaxa: I'm unsure of how your ffserver will actually look, but I'm excited to see :) Also will you use a standardised config format like YAML or something? [02:13:21 CEST] <klaxa> or i am under some misconceptions here [02:13:40 CEST] <klaxa> i've actually been pondering that as well [02:13:48 CEST] <klaxa> i like yaml [02:14:23 CEST] <wm4> yaml sucks [02:14:25 CEST] <Chloe> klaxa: I'm not sure either if nginx only supports http, I meant that I wanted to look into it but yeah [02:14:28 CEST] <klaxa> i'm not sure how other peop-- [02:14:40 CEST] <klaxa> yea didn't think that would just fly with no problems :P [02:14:40 CEST] <wm4> it's too complicated [02:14:55 CEST] <wm4> it's like they thought of all syntaxes you could possibly want [02:14:58 CEST] <Chloe> wm4: well I didnt necessarily mean YAML, just was suggesting not inventing yet-another config format [02:15:06 CEST] <wm4> heh [02:15:20 CEST] <klaxa> well the few times i touch yaml files it's usually simple ones [02:15:27 CEST] <klaxa> although now i remember some others [02:15:29 CEST] <klaxa> hmmm... [02:16:12 CEST] <klaxa> the old ffserver was xml right? i don't really feel like going down that road [02:16:22 CEST] <wm4> plain .ini is probably fine for 99% of all things [02:16:26 CEST] <Chloe> I was just about to suggest xml for a joke [02:16:38 CEST] <wm4> not sure what ffserver did [02:16:49 CEST] <Chloe> wm4: it probably had an internal xml lib [02:16:53 CEST] <klaxa> yeah a flat ini config should be fine [02:17:01 CEST] <wm4> I'd probably go with json, with some extensions to make it less painful [02:17:12 CEST] <wm4> (in practice probably a subset of yaml...) [02:17:26 CEST] <Chloe> there are some really nice json libs too [02:17:29 CEST] <wm4> but then I tend to overengineer such things [02:17:42 CEST] <wm4> Chloe: a json parser is maybe 300 LOC in C [02:17:55 CEST] <wm4> well, mpv's is, though it cheats a bit [02:18:14 CEST] <wm4> but in conclusion json is really easy to process compared to xml [02:18:15 CEST] <nevcairiel> as a human, i find reading/writing yaml easier then json [02:18:15 CEST] <Chloe> wm4: less than a mailto uri parser apparently [02:18:29 CEST] <wm4> nevcairiel: opposite for me [02:18:37 CEST] <Chloe> wm4 isn't human. [02:18:46 CEST] <nevcairiel> yaml has no braces everywhere, just some indentation [02:18:50 CEST] <wm4> with yml I alwaas have to wonder wtf something really does.. in json it's just clear [02:19:03 CEST] <klaxa> i agree that braces make it clearer :/ [02:19:11 CEST] <Chloe> honestly, my only experience of yaml is like [02:19:14 CEST] <Chloe> travis configs [02:19:17 CEST] <klaxa> i like python indentation, but in yaml i mostly don't get it [02:19:20 CEST] <Chloe> and damn, they're pretty bad [02:20:05 CEST] <wm4> the main things I hate about json as config formats are: 1. outer { } (around the whole thing), 2. having the quote keys in "" [02:20:28 CEST] <wm4> but you could drop the outer {}, and make "" for keys optional [02:20:35 CEST] <klaxa> well the config should really be just defining a few parameters per stream [02:20:38 CEST] <wm4> then it's almost ini [02:20:48 CEST] <klaxa> input, output format(s) and maybe max clients [02:20:57 CEST] <klaxa> maybe some other options, but should all be global per stream [02:21:01 CEST] <wm4> .ini without sections, then [02:21:39 CEST] <atomnuker> klaxa: use lua. eof. [02:21:39 CEST] <nevcairiel> thats why I hate json [02:21:49 CEST] <nevcairiel> it just looks terrible with quoted keys and the outer {} [02:21:54 CEST] <klaxa> i switched FROM awesome because of lua [02:22:02 CEST] <atomnuker> lua is awesome [02:22:08 CEST] <atomnuker> for config files [02:22:14 CEST] <Chloe> mmh. I really like that json quotes its keys [02:22:20 CEST] <atomnuker> want a standard human readable config file? gotcha [02:22:28 CEST] <atomnuker> want to do some scripting in there? yep, you can [02:22:34 CEST] <nevcairiel> using a Lua interpreter just to get config files seems extremely overkill =p [02:22:51 CEST] <atomnuker> want to define some misc functions to override some edge cases? yep [02:23:11 CEST] <Chloe> nevcairiel: if we have fflua then we can also make lavfi's filtergraphs lua [02:23:35 CEST] <nevcairiel> if you have Lua already anyway and the stuff can interact with some things of your project, fine, but if you introduce it just for the config format then all your added benefits do not actually work [02:24:28 CEST] <wm4> mpv uses a lot of lua scripting, but even it doesn't use lua for config files [02:24:42 CEST] <atomnuker> because of historical reasons [02:25:02 CEST] <Chloe> Honestly though [02:25:03 CEST] <atomnuker> lua is infinitely more readible than both json or yaml or anything [02:25:15 CEST] <wm4> not sure I agree [02:25:18 CEST] <Chloe> How else can filtergraphs be easier to use [02:25:54 CEST] <atomnuker> ":" as a set operator is a blunder of a choice and json shouldn't have gone for it [02:26:48 CEST] <wm4> lavfi filter graphs would benefit from lua or json or whatever [02:27:25 CEST] <Chloe> wm4: I really think filtergraphs should be scriptable [02:27:39 CEST] <wm4> yeah [02:27:42 CEST] <Chloe> They sortof are now but not really [02:27:45 CEST] <Chloe> They try to be [02:27:56 CEST] <Chloe> Which is an indication that they should be [02:28:02 CEST] <wm4> well some options use this gross eval thing [02:28:09 CEST] <wm4> or actually all [02:28:17 CEST] <wm4> but some take a string argument and eval it [02:28:26 CEST] <wm4> or, uh, not sure [02:29:05 CEST] <wm4> hm right [02:29:06 CEST] <atomnuker> having scriptable filtergraphs would solve like 99% of the issues lavfi users have requested [02:29:19 CEST] <wm4> the filter parser doesn't use eval expressions [02:29:25 CEST] <nevcairiel> the eval thing is kinda useful for things like scaling percentages and whatnot [02:29:31 CEST] <wm4> but many filters use string options for number arguments, and eval those [02:29:49 CEST] <wm4> e.g. vf_scale uses strings for w/h, so that it can eval them to allow filter users to do clever things [02:29:50 CEST] <atomnuker> "I wanna have a logo! Which like moves! Like every 4 frames, but not on the 5th! Oh and I want it only in between frames 5 and 39!" [02:29:51 CEST] <nevcairiel> i wouldnt really call that "scripting" [02:30:15 CEST] <nevcairiel> atomnuker: you can probably even do that already =p [02:30:38 CEST] <atomnuker> yes, using the API, but try telling that to people who don't believe such exists [02:30:49 CEST] <nevcairiel> nah even from CLI [02:31:01 CEST] <nevcairiel> the syntax is crazy but you can do all sorts of weird things with it [02:31:18 CEST] <Chloe> nevcairiel: yes thats the issue lol [02:31:32 CEST] <Chloe> You can do a lot of things but the syntax gets batshit insane [02:31:55 CEST] <wm4> nevcairiel: it usually ends with really really long filter graph strings for achieving rather simple things [02:32:04 CEST] <Chloe> Scripting would simplify it massively [02:32:16 CEST] <wm4> with scripting you could use functions [02:32:21 CEST] <rcombs> atomnuker: I mean, JSON got it from JS, but what would you suggest? [02:32:38 CEST] <wm4> e.g. make a letterbox() function instead of direct vf_scale invocation with dozens of characters as arguments [02:32:50 CEST] <Chloe> As for what scripting is viable, only lua or JavaScript probably? [02:32:56 CEST] <wm4> json syntax could be extended to allow = for : [02:33:03 CEST] <wm4> it's unambiguous [02:33:05 CEST] <nevcairiel> never javascript [02:33:15 CEST] <nevcairiel> its interpreters are huge and clunky [02:33:24 CEST] <nevcairiel> also the language itself is terrible [02:33:24 CEST] <rcombs> are we inventing vapoursynth but in lavfi [02:33:24 CEST] <wm4> mujs is tiny [02:33:36 CEST] <Chloe> Mujs is pretty alright [02:33:36 CEST] <atomnuker> nobody ships it, also js sucks as a language [02:33:58 CEST] <wm4> fun fact: BrainStorming, BikeShedding, and BullShit all have the same initials [02:34:14 CEST] <Chloe> Most people know js [02:34:21 CEST] <nevcairiel> BS only ever means one thing tho :p [02:34:21 CEST] <atomnuker> its only popular because someone went "OH A MOVING MENU! IN A BROWSER" 25 years ago [02:34:22 CEST] <klaxa> so? [02:35:36 CEST] <rcombs> JS is much less bad than it used to be [02:35:41 CEST] <Chloe> rcombs: thats the dream (not really, just to make filtergraphs usable) [02:35:53 CEST] <rcombs> these days the problem with JS is everything written in it [02:36:03 CEST] <nevcairiel> the language itself is still terrible [02:36:09 CEST] <rcombs> it's like PHP except better-documented [02:36:11 CEST] <wm4> nevcairiel: +1 [02:36:16 CEST] <nevcairiel> its auto-type conversion rules still give me headaches [02:36:22 CEST] <rcombs> I did say "less bad" and not "good" [02:36:25 CEST] <wm4> also fuck this [02:36:34 CEST] <wm4> as in, the special keyword "this" and its semantics [02:36:50 CEST] <rcombs> oh yeah JS this is nonsense [02:36:53 CEST] <Chloe> What other options are there? [02:36:58 CEST] <atomnuker> lua. [02:37:00 CEST] <Chloe> Other than lua and js [02:37:07 CEST] <atomnuker> lua 5.3 [02:37:14 CEST] <atomnuker> its a different language [02:37:23 CEST] <rcombs> on one hand, JS has loose-typing nonsense [02:37:29 CEST] <nevcairiel> can go classic and use python like vsynth =p [02:37:30 CEST] <rcombs> on the other hand, lua has 1-indexed arrays [02:37:53 CEST] <Chloe> If people dont like js then theres pretty much only lua [02:37:58 CEST] <wm4> mruby [02:38:14 CEST] <rcombs> I mean there's moonscript but that's a lua dialect basically [02:38:15 CEST] <wm4> python (not really) [02:38:18 CEST] <rcombs> embedded perl [02:38:26 CEST] <wm4> tcl [02:38:35 CEST] <rcombs> in case you want to be no more readable than current filtergraphs [02:38:36 CEST] <Chloe> nevcairiel: You complained about js being big then suggested python... [02:38:50 CEST] <rcombs> I believe that was in jest [02:38:54 CEST] <atomnuker> rcombs: you can still do array[0] in lua, its 1 indexed in some situations if you want it to be [02:38:59 CEST] <nevcairiel> python is probably present on every system already anyway! [02:39:06 CEST] <atomnuker> you can't embed python [02:39:14 CEST] <rcombs> oh yes you can [02:39:21 CEST] <rcombs> hi I maintain a product that does it [02:39:23 CEST] <atomnuker> you can only have "from ffmpeg import libavcodec" [02:39:24 CEST] <rcombs> (we're trying to stop) [02:39:26 CEST] <Chloe> nevcairiel: coinflip which version though [02:39:31 CEST] <nevcairiel> arrays are basically 1 indexed, if you access array[0] you go into the hash [02:39:36 CEST] <rcombs> we call into python code from C++ [02:39:38 CEST] <wm4> in lua [0] would use a hash entry instead of the array optimization [02:39:39 CEST] <rcombs> we regret it [02:39:43 CEST] <wm4> Lua actually sucks too [02:39:54 CEST] <atomnuker> not as much as python or js [02:39:55 CEST] <wm4> but it has small footprint and relatively ok embedding [02:40:11 CEST] <Chloe> atomnuker: js sucks less than python [02:40:22 CEST] <rcombs> how about just expose an API to modify filtergraphs and let people write clients for it in whatever language they like [02:40:32 CEST] <nevcairiel> you mean, lavfi? [02:40:33 CEST] <atomnuker> you still need bindings [02:40:36 CEST] <rcombs> run on unix sockets or whatever [02:40:41 CEST] <klaxa> does that help cli users though? [02:40:44 CEST] <atomnuker> Chloe: yeah, it does [02:40:47 CEST] <wm4> mpv actually parses filter graphs itself, just uzsing the same syntax lol [02:41:08 CEST] <Chloe> rcombs: xml rpc [02:41:10 CEST] <atomnuker> python is godawful and is run by a bunch of paganic cultists [02:41:32 CEST] <atomnuker> *intradimensional paganic cultists [02:41:48 CEST] <rcombs> plus they maintain two similar languages at once so they must be super-masochistic [02:42:04 CEST] <nevcairiel> 2.x still kicking eh? [02:42:12 CEST] <atomnuker> read that as "masonic" at first though I guess they're masons too probably [02:42:43 CEST] <wm4> what I dislike most about lavfi is how static it is and its format negotiation [02:43:08 CEST] <Chloe> Could be dynamic with scripting [02:43:18 CEST] <wm4> not really [02:43:18 CEST] <rcombs> like how ffmpeg.c can't into new streams [02:43:25 CEST] <atomnuker> well not to the extent that you can change essential frame properties like size [02:43:28 CEST] <wm4> Chloe: as an API user [02:43:39 CEST] <wm4> Chloe: even when not using its graph parser [02:43:46 CEST] <atomnuker> you can use process_command to send filters arbitrary commands but afaik you can't really change the format nor the frame size [02:43:55 CEST] <Chloe> wm4: ssshh im trying to argue for scripting here [02:44:00 CEST] <wm4> Chloe: e.g. mpv's fiilter/f_lavfi.c shoulöd be almost empty, but it's not [02:44:20 CEST] <atomnuker> not without reiniting the graph [02:44:26 CEST] <Chloe> Anyway, I mean it seems like people arent strongly against changes to filtergraphs [02:44:48 CEST] <Chloe> Maybe something for on-the-fly changes could be implemented alongside [02:44:56 CEST] <rcombs> did I mention my evil plan to turn ffmpeg.c into a library and expose a bunch of hooks [02:45:16 CEST] <wm4> atomnuker: and commands don't even have a convention that'd effectively mean you can implement changing certain options in a generic way (from the view of an API user) [02:45:19 CEST] <nevcairiel> did we yell at you the last time you did? [02:45:50 CEST] <rcombs> well I brought it up in darkhold and nobody yelled [02:45:58 CEST] <rcombs> somebody went "oh yeah google does that for youtube apparently" [02:46:12 CEST] <Chloe> rcombs: just make it hook into random shared objects [02:46:18 CEST] <rcombs> wm4 went "how about write something new that's not bad" and I'm like "that sounds like a lot of work" [02:46:34 CEST] <wm4> that was me yelling [02:46:49 CEST] <wm4> ffmpeg.c is some sort of caricature at this point [02:46:52 CEST] <rcombs> well it was lowercase so [02:47:11 CEST] <wm4> and not really appropriate as a library anyway [02:47:13 CEST] <Chloe> Should have put rewrite ffmpeg*.c on gsoc tbh [02:47:27 CEST] <Chloe> Maybe thats what we truly need instead [02:47:40 CEST] <rcombs> basically I need ffmpeg.c's functionality on iOS but I can't fork() there [02:48:11 CEST] <rcombs> and I can't justify rewriting the whole thing for work and also I don't want to [02:48:15 CEST] <Chloe> Instead of generic incremental library refractors, I should just rewrite ffmpeg*.c [02:48:19 CEST] <wm4> complain to apple (trollol) [02:48:54 CEST] <wm4> well then make patches to move all the shit to structs, and do your evil ffmpeg.c library thing as a small private patch after that is done [02:49:48 CEST] <Chloe> rcombs: hire me to do it. Am very experienced with more than 2 weeks of irc experience [02:50:24 CEST] <Chloe> Damn. I should have said more than 2 weeks of bikeshedding experience [02:56:20 CEST] <Chloe> michaelni: removal/moval of postproc was discussed on irc a while ago and i only recently got round to doing a patch (it was also then discussed again today) [03:01:03 CEST] <klaxa> man that really bugged JEEB, eh [03:01:31 CEST] <klaxa> i totally get it though [08:53:55 CEST] <JEEB> klaxa: yup, it really bugged me. [10:39:33 CEST] <ldts> I have extended doc/examples/decode_video.c to add some trivial DRM/KMS display support in order to validate the current work in progress for ffmpeg v4l2 DRM (lrusak)...I have pushed this to my github because I dont know if there is any interest in having it in the ffmpeg tree....still I'll ask: does anyone think there might be any value in preparing it to be merged? code it is here: [10:39:33 CEST] <ldts> https://github.com/BayLibre/ffmpeg-drm/blob/master/main.c [10:41:17 CEST] <ldts> LongChair: ^^ [10:48:31 CEST] <LongChair> ldts: good to see we're progressing there :) [10:49:26 CEST] <ldts> yeah, sorry about the lag [11:34:02 CEST] <LongChair> ldts: i guess what lrusak wants is to get it adjusted for the jobs API right ? [11:34:23 CEST] <LongChair> seems a lot of SoC vendors are going that route nowadays [11:34:48 CEST] <ldts> sorry what do you mean? [11:37:38 CEST] <wm4> can someone explain what the stateless v4l decoding api is [11:44:45 CEST] <cone-055> ffmpeg 03Paul B Mahol 07master:9faec78b1429: avfilter/vf_mix: add slice threading [11:44:46 CEST] <cone-055> ffmpeg 03Paul B Mahol 07master:e0e75f93b97a: avfilter/vf_maskedclamp: silence warning [12:08:17 CEST] <ldts> wm4: I'll try to find out...I dont know [12:09:18 CEST] <wm4> it sort of sounds like desktop hwaccel APIs (which are very nice and don't call all these random problems), but hard to find real information [12:10:18 CEST] <ldts> yes I found a RFC for linux-rockchip that call them "Frame API" based decoders (ie non-stream API) [12:10:54 CEST] <wm4> s/call/cause/ [12:11:20 CEST] <ldts> I guess you have seem it as well https://www.mail-archive.com/linux-media@vger.kernel.org/msg104163.html [12:14:12 CEST] <wm4> possibly [12:14:39 CEST] <wm4> I wonder if this went anywhere [12:31:38 CEST] <cone-055> ffmpeg 03Paul B Mahol 07master:2d7ba3a96f50: avfilter/vf_premultiply: add slice threading [13:00:48 CEST] <durandal_1707> who needs threading to overlay filter? [13:01:31 CEST] <kierank> durandal_1707: did you fix prores [13:03:22 CEST] <durandal_1707> kierank: locally, but only pure C version [13:04:13 CEST] <durandal_1707> asm one needs asm of 12 bit idct, nobody have written [13:04:47 CEST] <durandal_1707> asm needed because asm path needs transposed permutations [13:04:55 CEST] <durandal_1707> and pure C doesnt [13:07:25 CEST] <wm4> <durandal_1707> who needs threading to overlay filter? <- sounds pretty useful at least [14:21:50 CEST] <ubitux> can't we just move libpostproc in a pp directory in lavfi with ff_ functions the pp filter would use? [14:22:38 CEST] <ubitux> actually, it's like 3 .c, we may not even need a directory for it [14:23:28 CEST] <ubitux> (that is, assuming the problem with libpostproc is its exposition) [14:29:04 CEST] <durandal_1707> ubitux: problem of libpostproc is: it is dead code [14:29:22 CEST] <ubitux> well, there is a pp filter [14:30:00 CEST] <durandal_1707> yes, but that is irrelevant, better move libpp code into pp filter [14:30:07 CEST] <durandal_1707> it is several lines [14:30:19 CEST] <ubitux> yeah ok, well i'm fine with that [14:30:49 CEST] <BtbN> Why is libpostproc its own lib? [14:30:57 CEST] <nevcairiel> historical reasons [14:31:01 CEST] <durandal_1707> old glorious days [14:35:09 CEST] <wm4> rather the question is why is libpostproc in the main repo? [14:35:13 CEST] <wm4> it's an embarrassment [14:37:30 CEST] <wm4> it's a whole different lib for some filters that were written decades ago [14:38:06 CEST] <wm4> try to explain it to someone uninitiated, "it's here for historical reasons, you should prefer the more powerful and advanced filters in libavfilter" is your best bet [14:38:35 CEST] <wm4> it would be a bit different if they were just another set of filters in lavfi [14:39:25 CEST] <wm4> also I wonder why libpostproc is supposedly "required" for some things (I've seen that claim from at least 2 people, but it was never explained) [14:44:31 CEST] <wm4> wow vlc uses libpostproc [14:44:33 CEST] Action: wm4 dies [14:44:46 CEST] <j-b> The module is still there [14:44:48 CEST] <j-b> and available [14:44:56 CEST] <j-b> Some people use it. [14:45:01 CEST] <wm4> the only time I've seen mpv users use vf_pp was out of ignorance, or in one case because they wanted a fast bob deint filter [14:45:19 CEST] <nevcairiel> does vlc also still uses liba52? in some areas it always seemed quite a bit slow on the uptick [14:45:49 CEST] <j-b> vlc did use liba52 for a very good reason, that was explained many times over, and it's no longer the case [14:46:00 CEST] <j-b> wm4: our users are not always smart [14:46:02 CEST] <wm4> what reason [14:46:20 CEST] <wm4> neither are mine [14:46:42 CEST] <j-b> an architecture issue with a52/dts being not "decoders" in VLC, but "filters" for SPDIF reasons. [14:46:54 CEST] <j-b> and noone cared enough to fix. [14:47:00 CEST] <j-b> until 2 years ago, IIRC [14:47:14 CEST] <wm4> ah [14:47:18 CEST] <j-b> However, moving from libdca was more problematic, in terms of regression. [14:48:09 CEST] <j-b> wm4: I hate postproc with a force too, but I remember some arguments of it being more advancedly integrated with the mpeg4 decoder than usual filters [14:48:15 CEST] <j-b> (or something like that) [14:48:34 CEST] <j-b> How much of that is BS, I don't remember [14:48:50 CEST] <wm4> it's the only filter that uses the exported QP table [14:48:58 CEST] <j-b> yeah [14:50:02 CEST] <nevcairiel> the need for processing 320x240px blocky videos also reduces every day [14:50:24 CEST] <wm4> in any case still not a reason why it'd be a separate lib [14:51:06 CEST] <j-b> true. [14:51:15 CEST] <nevcairiel> i dont really care, i just dont build it and its so entirely separate that it not once impacted anything i wanted to change [14:51:23 CEST] <j-b> and maybe there are more clever algo/filters to remove blocks that don't need a QP table [14:51:36 CEST] <j-b> durandal_1707: ^^ that's what I meant. [14:52:28 CEST] <nevcairiel> knowing the MB layout and possibly the compression factors of those MBs can be beneficial, on the other hand its also nice to be able to do that without this information, as someone may recompress the blocky video and the info is lost [14:54:27 CEST] <durandal_1707> j-b: see recently added deblock filter, it is very simple and competes with h264 deblock filter from avs/vs [14:54:27 CEST] <Chloe> j-b: I wonder how the new deblock filter stacks up against all the pp deblock filters [14:54:39 CEST] <j-b> Chloe: exactly my point, I believe [14:54:53 CEST] <j-b> I hate postproc, because some users are stooopid [14:55:15 CEST] <j-b> durandal_1707: really cool then. [14:55:34 CEST] <Chloe> j-b: well if we can just say 'use vf_deblock instead', but for all the filters in pp then I dont see why we cant just remove them [14:55:46 CEST] <Chloe> then they'd essentially just be duplicate (and worse) filters [14:56:02 CEST] <j-b> Chloe: I'm totally fine with saying to my users to change the filter. [15:01:38 CEST] <Chloe> auto-levels could be added to eq somehow maybe, we have hqdn3d instead of the temporal noise filter [15:02:04 CEST] <Chloe> Though I dont do much with filtering so idk about the quality of these filters [15:02:38 CEST] <durandal_1707> atadenoise is temporal only denoiser [15:03:02 CEST] <durandal_1707> nlmeans is now spatial only, need SIMD to be faster [15:03:39 CEST] <Chloe> durandal_1707: are there any filters in pp which do not have 'equivalents'? [15:03:56 CEST] <wm4> alternative filters will always behave slightly difference and thus will not be accepted as "replacements" [15:04:24 CEST] <j-b> Chloe: durandal_1707: tbh, I need a filter to remove some blocking for all codecs. And if vf_deblock does 80% of the job, it's good enough for me. [15:04:39 CEST] <j-b> Chloe: durandal_1707: and I can sponsor more work around that, if someone can do the work. [15:05:07 CEST] <Chloe> around removing postproc or vf_deblock? cause i'm fairly sure that deblock does what you want already [15:05:14 CEST] <Chloe> ngl it looks pretty good [15:05:52 CEST] <durandal_1707> there is deringing filter [15:06:10 CEST] <durandal_1707> in pp [15:06:19 CEST] <durandal_1707> /libpostproc [15:06:57 CEST] <Chloe> durandal_1707: is that the only one then? [15:07:43 CEST] <durandal_1707> there are various strange deinit filters [15:09:07 CEST] <Chloe> wm4: mmh. Maybe, but even so, having equivalents would be good (or at least stating which lavfi filters are equivalents). [15:09:30 CEST] <Chloe> wm4: 'cause they're sure not getting removed if there is no alternative whatsoever [15:10:09 CEST] <durandal_1707> the temporal filter options looks to not be used at all, need to test... [15:12:37 CEST] <durandal_1707> -vf pp=tn give silly artifacts [17:00:33 CEST] <durandal_1707> which else filters needs slice threading? [17:26:30 CEST] <cone-441> ffmpeg 03Paul B Mahol 07master:309fce63d8c8: avfilter/vf_shuffleplanes: add support for timeline [18:25:38 CEST] <kierank> jdarnley: maybe worth looking at that hpeldsp patch [18:27:10 CEST] <atomnuker> Gramner too, if he's there [18:27:27 CEST] <atomnuker> *if he can [18:28:56 CEST] <wm4> how do I make configure to check for two .pc files [18:29:00 CEST] <wm4> fucking shell shit [18:30:13 CEST] <wm4> and configure lying about shit [18:30:35 CEST] <wm4> (incorrect error messages) [18:33:33 CEST] <jamrial> you mean check_pkg_config() ? [18:34:23 CEST] <jamrial> or require_pkg_config() if you need configure to die on failure [18:36:47 CEST] <wm4> second [18:37:03 CEST] <wm4> I guess it probably works now [19:18:53 CEST] <cone-441> ffmpeg 03Paul B Mahol 07master:b473e76876d9: avfilter/vf_mix: use correct linesizes [22:25:13 CEST] <RiCON> wm4: group within ""? [22:25:32 CEST] <wm4> somehow that didn't work [22:55:59 CEST] <durandal_1707> so only way to unpack packed binary is to run it? [22:56:43 CEST] <atomnuker> packed binary? [22:56:58 CEST] <atomnuker> usually there's a bunch of unpacked code to unpack it [22:58:37 CEST] <durandal_1707> they appears to run it inside some kind of controlled environment [23:12:25 CEST] Action: durandal_1707 attempts to run avisyth under linux to RE filter [23:13:57 CEST] <atomnuker> madman [23:14:22 CEST] <atomnuker> avisynth supports binary filters? lol [23:15:35 CEST] <BtbN> A lot of modern games come not as native code, but to some weird VM code and ship a VM that jit-compiles it on the fly [23:15:53 CEST] <BtbN> with a lot of randomization in that VM, and all that kind of bullshit, just for the sake of copy protection [23:16:02 CEST] <BtbN> It still gets cracked within a week [23:16:31 CEST] <nevcairiel> there have been some of those VMs that went uncracked for months [23:16:52 CEST] <BtbN> That was before they even introduced the VMs, just Anti-Tamper [23:17:03 CEST] <BtbN> The added VM layer was done in an attempt to slow them back down. Didn't work. [23:17:38 CEST] <nevcairiel> and everyone knows none are infinitely safe, they are just trying to delay it long enough to get the launch weeks over without cracked versions turning up [23:18:00 CEST] <BtbN> Yeah, but now it's usually just a matter of days again. [23:19:03 CEST] <kierank> durandal_1707: run program in vm, dump memory [23:19:12 CEST] <BtbN> I don't get the appeal of cracked games. You are behind on patches, no online features, massive risk of malware. The only reason a lot of people get it is to play test the game(and then "forget" to buy it). [23:19:32 CEST] <BtbN> I guess the most effective thing game publishers could do is offer good old demos again [23:36:04 CEST] <klaxa> and release it without drm like gog [00:00:00 CEST] --- Sat Apr 28 2018

1 0

ffmpeg.log.20180427
by burek 28 Apr '18

28 Apr '18

[00:00:13 CEST] <GrayShade> This started, so you can report it to the developer [00:00:30 CEST] <GrayShade> Though I'm not sure he keeps that many versions [00:00:40 CEST] <Lite> Could it affect the issue with FFmpeg? [00:01:36 CEST] <Lite> The problem is I can not tell when exactly it worked perfect and when exactly stopped [00:01:50 CEST] <GrayShade> It shouldn't, but you can install it on the other computer to check [00:02:11 CEST] <Lite> But yeah at that period of time I installed Charles. And it still is in system [00:02:34 CEST] <Lite> LOL, nice joke, Gray [00:03:44 CEST] <Lite> If it's not I can't see any more reasons why something wrong could happened with TLS [00:04:18 CEST] <Lite> I remember I edited manually via Windows registry values of default TTL [00:04:24 CEST] <GrayShade> Well, it wasn't a joke, actually [00:04:40 CEST] <Lite> not sure if TTL and TLS connected somehow [00:05:53 CEST] <Lite> OK, checking provided URLs will come back with results in ~5 mins [00:07:24 CEST] <GrayShade> Assuming you didn't decrease it, I'd say it's fine, but if you change registry settings and install a TLS proxy, then ffmpeg stops working.. Yeah. [00:08:06 CEST] <Lite> TLS proxy? [00:08:30 CEST] <Lite> no no I changed only TTL :O [00:10:04 CEST] <GrayShade> Charles [00:11:42 CEST] <Lite> Well, rolled back last nightly version and tested http URL [00:12:08 CEST] <Lite> Sir Gray, your theory confirming... HTTP is working [00:12:47 CEST] <Lite> And....yep! HTTPS stucks [00:13:08 CEST] <GrayShade> HTTPS would still need to fail to confirm it, and there are a couple of TLS versions, so it might work [00:13:12 CEST] <GrayShade> Or yeah [00:13:17 CEST] <Lite> Sir Gray, your theory about HTTP and HTTPS totally confirmed [00:14:36 CEST] <Lite> But what's the difference in 3.4.2 over nightly build with this TLS (HTTPS)??!! [00:14:45 CEST] <GrayShade> You could try to remove Charles, but the registry changes would remain [00:14:49 CEST] <Lite> Why 3.4.2 working? [00:14:56 CEST] <GrayShade> No idea, I'm not the one to ask [00:15:03 CEST] <Lite> :D [00:15:16 CEST] <JEEB> have you actually looked into the traffic to see any differences? [00:15:21 CEST] <Lite> Ok, deleting Charles [00:15:22 CEST] <JEEB> 3.4 is quite old by now [00:15:28 CEST] <Lite> Will come back soon [00:15:44 CEST] <JEEB> and there's been a lot of changes in various things since 3.4 branch was created [00:16:08 CEST] <JEEB> a lot of good stuff but also possibly bugs. the only way to debug is to actually dump the network traffic and see WTF is going on [00:16:32 CEST] <GrayShade> They'd need to add a certificate to decrypt the session and that might be hard with gnutls [00:17:06 CEST] <JEEB> I'm not sure if libavformat's http by default validates the certificate [00:17:08 CEST] <JEEB> let me check [00:18:00 CEST] <GrayShade> And when you already have TLS errors, doing MITM sounds like the last thing you'd want :-D [00:18:08 CEST] <Lite> >> They'd need to add a certificate to decrypt the session and that might be hard with gnutls - so that could be a decision to exclude users like me faces such issue from devs side in this case? [00:18:10 CEST] <Lite> :D [00:18:15 CEST] <Lite> souns nice [00:18:20 CEST] <Lite> sounds* [00:18:37 CEST] <GrayShade> "They" would be you [00:19:03 CEST] <JEEB> {"tls_verify", "Verify the peer certificate", offsetof(pstruct, options_field . verify), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, .flags = TLS_OPTFL }, \ [00:19:10 CEST] <JEEB> ok, so the default is zero [00:19:15 CEST] <JEEB> so MITM should work [00:19:17 CEST] <JEEB> :P [00:20:01 CEST] <GrayShade> Sounds like a fun project. I off to sleep, so maybe I'll find out in the morning [00:20:12 CEST] <GrayShade> I'm* [00:20:43 CEST] <JEEB> Lite: btw *how* recent is your "nightly"? [00:20:50 CEST] <JEEB> what git hash? [00:21:00 CEST] <JEEB> it's the gXXXX you get when you do ffmpeg -version [00:21:29 CEST] <GrayShade> There was a screenshot above [00:21:51 CEST] <Lite> https://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-20180426-8ea8be5-win6… this one [00:22:42 CEST] <JEEB> ok, so if it uses the windows internal TLS thing [00:22:45 CEST] <JEEB> called schannel [00:22:53 CEST] <JEEB> then it should have all the improvements that was getting [00:23:13 CEST] <GrayShade> The error seems to be from gnutls [00:23:22 CEST] <JEEB> ok, so it uses gnutls on windows... interesting) [00:23:26 CEST] <JEEB> there's no reason to do that [00:23:31 CEST] <JEEB> windows has a TLS implementation out of the box [00:23:38 CEST] <JEEB> and we implement that [00:24:12 CEST] <JEEB> also it could be that the "zero is not EOF" change could still be giving fruit, just with gnutls now [00:24:30 CEST] <GrayShade> schannel has its fair share of issues. There was a recent thing with tls 1.2 and worried 7 iirc [00:24:44 CEST] <GrayShade> Windows 7 :-/ [00:25:35 CEST] <JEEB> you might have to enable newer ciphers in registry or something like that because for some reason MS disabled them by default. or we have to enable them explicitly in the schannel code [00:25:46 CEST] <JEEB> anyways, news for me regarding the issues :P [00:26:11 CEST] <JEEB> the TLS 1.2 stuff that is [00:27:02 CEST] <GrayShade> Yeah, there were a lot of people having issues with GitHub in the community of a language I'm following. It seemed that the docs were a bit contradictory on whether the registry change is needed [00:27:23 CEST] <GrayShade> Does ffmpeg support xp? [00:28:11 CEST] <klaxa> not anymore [00:28:32 CEST] <Lite> ok [00:28:38 CEST] <Lite> deleted Charles... [00:28:45 CEST] <GrayShade> That's a plus for schannel, I suppose [00:28:53 CEST] <klaxa> >Dropped support for building for Windows XP. The minimum supported Windows version is Windows Vista. [00:28:59 CEST] <Lite> will check it out in couple mins [00:29:15 CEST] <JEEB> considering that XP lost support in april 2014 [00:29:25 CEST] <JEEB> if you are still using it outside of a VM [00:29:37 CEST] <JEEB> or something else that is not on a network [00:29:38 CEST] <klaxa> but they patched for wannacry :P [00:30:29 CEST] <Lite> F*ck thats not affected... maybe needs reboot for more clearance [00:30:40 CEST] <GrayShade> It must be on a network if you care about tls working :-D [00:31:22 CEST] <JEEB> that's kind of what I was already pointing towards. those people are fscked [00:31:31 CEST] <GrayShade> Well, what jeeb said. Use that wireshark to see what's up [00:31:35 CEST] <Lite> A few days ago I reinstalled Fiddler [00:32:30 CEST] <Lite> so it affected the issue it should be fixed. Since I also checked for deleting all of it's certs [00:32:40 CEST] <Lite> if* [00:33:02 CEST] <Lite> So the issue not affected by Fiddler definately [00:33:55 CEST] <Lite> because Fiddler installed at System a long time ago and FFmpeg nightly worked perfect [00:34:38 CEST] <JEEB> if you have access to multiple nightlies of different age, you could start going through them forwards from the last known working one :P [00:34:48 CEST] <Lite> Moreover, on another device Fiddler installed too [00:36:02 CEST] <Lite> Actually I don't believe that's 'update to more actual version' issue [00:36:37 CEST] <Lite> SInce I faced an issue someday on same version that worked perfect before. [00:38:43 CEST] <Lite> Yeee Mr. Gray and kepstin are really PRO. To find out a reason just from screenshot (https://Drive.Google.Com/uc?id=1h6CyKvQ25ztx9FNo7YBqH-vUyHm4bEt-) shows for me almost nothing :D [00:43:38 CEST] <Lite> :'C [00:44:01 CEST] <Lite> @D-ion A5@LQ7=>? [00:44:12 CEST] <Lite> 8;09=? [00:44:26 CEST] <Lite> 4>@>20 [00:45:54 CEST] <Lite> I'm sorry it was russian language :| [00:46:39 CEST] <Anonrate> To compile ffmpeg with lzma, you need to install the lzma sdk from 7-zip, ya? [00:49:48 CEST] <furq> no [00:50:20 CEST] <furq> you want liblzma from xz-utils [00:50:54 CEST] <Anonrate> I want to compile from source though. So that would be from kobolabs? [00:51:02 CEST] <furq> still no [00:51:57 CEST] <Anonrate> Tukaani? [00:53:08 CEST] <furq> yes [00:53:15 CEST] <Lite> found a path affected to schannel setting in Windows 10 registry... [00:53:27 CEST] <Lite> But nothing intersting there [00:53:47 CEST] <Lite> Even no any empty folder fro any TLS [00:54:16 CEST] <Lite> :'( [00:54:47 CEST] <Anonrate> Thank you. [00:56:51 CEST] <D-ion> Lite: Da. Tovarisch. [01:13:28 CEST] <kepstin> Lite: i was mistaken about th eschannel stuff, both builds should be gnutls [01:14:07 CEST] <kepstin> Lite: at least according to the readme zeranoe provides [01:15:21 CEST] <Lite> I see [01:16:33 CEST] <Lite> But it was confirmed that 3.4.2 works how nightly should; ATM nightly works at "i" parameter with HTTP URLs and not working with HTTPS [01:17:01 CEST] <Lite> isn't that a good reason to tell I should fix something with TLS? [02:17:51 CEST] <Nanashi> When creating a gif from transparent frames how do I keep the first frame's transparency instead of having black background? [02:40:10 CEST] <Nanashi> nvm got it, used latest version but slightly different commands, gonna recheck old commands [02:44:06 CEST] <Nanashi> exactly same result, no issues [02:56:42 CEST] <Nanashi> but what's the flag to tell it to replace frame instead of combine [03:09:17 CEST] <Nanashi> since with transparent frames it's stacking on top of each other... [03:10:40 CEST] <klaxa> would help to know what you are already doing [03:10:48 CEST] <klaxa> as in, what command you are running [03:11:15 CEST] <klaxa> not sure if i can help, but if someone else can they can help better and faster [03:14:11 CEST] <Nanashi> the basic, ffmpeg -i input%d.png -vf palettegen palette.png then ffmpeg -i input%d.png -i palette.png -lavfi paletteuse output.gif [03:17:26 CEST] <klaxa> maybe your input images need to have their alpha removed? [03:18:42 CEST] <Nanashi> the point is to have a transparent gif [03:19:24 CEST] <klaxa> ah [03:19:55 CEST] <klaxa> oh you don't want it stacking right you said, hmm have you tried -gifflags -transdiff ? [03:20:21 CEST] <klaxa> not sure if it works that way exactly, but if it is on by default - should disable it [03:30:54 CEST] <Nanashi> strangely not doing anything [03:50:37 CEST] <Nanashi> wow my workaround solution is to output each frame, essentially just applying the palette, then assemble the gif in gimp... extra work tho [03:51:17 CEST] <klaxa> hmm i would have probably done the same :/ [03:51:23 CEST] <klaxa> might be worth a ticket [03:51:34 CEST] <furq> it's cool that gifflags doesn't appear anywhere in the docs [03:51:58 CEST] <furq> also yeah if you're going to just write out every frame then just use gifsicle to assemble it [03:52:01 CEST] <Nanashi> Is there a flag to create unoptimized gif? [03:52:09 CEST] <furq> i don't know, it's not documented [03:52:39 CEST] <klaxa> hmm i got it from ffmpeg -help encoder=gif [03:53:15 CEST] <furq> yeah it shows up in -h full but that's it [03:53:19 CEST] <furq> it's not in man ffmpeg-all or on the site [03:53:54 CEST] <furq> i vaguely remember there being some unresolved issue in the gif encoder but i forget what it was now [03:54:06 CEST] <furq> but yeah just use gifsicle [05:13:01 CEST] <hotbobby> by what method does -ac 2 downmix 5.1 to stereo audio [05:20:21 CEST] <hotbobby> also, there is not any kind of -loglevel that lets me ignore errors but also see stream statistics like fps and bitrate [05:23:00 CEST] <furq> -v error -stats [05:24:58 CEST] <hotbobby> it still shows nonfatal errors [05:29:15 CEST] <Nanashi> fuckit, I notice ffmpeg is adding red to palette when there is no red in images [06:11:35 CEST] <tdr> pick a better color pallet or encoding codec [06:20:08 CEST] <hotbobby> is there any way to show stats but not errors? [06:20:19 CEST] <furq> -v quiet [06:21:04 CEST] <hotbobby> -v quiet -stats works. i didnt think of combining them [06:21:05 CEST] <hotbobby> thanks [09:26:21 CEST] <styler2go> Good Morning. I'm trying to make a small script which records my security camera. Now i am stuck on even the simplest step. Problem is it says: "Nothing was written into output file 0 (log.mp4), because at least one of its streams received no packets." What could cause this? [09:27:08 CEST] <styler2go> full output: https://p.styler2go.de/3306680 [09:48:03 CEST] <Diag> styler2go: are your streams receiving packets? [09:49:59 CEST] <styler2go> well i can watch the stream in vlc player if that counts? [10:24:07 CEST] <styler2go> I don't really get any video output, any ideas? https://p.styler2go.de/6864679 [10:25:33 CEST] <sfan5> >Consider increasing the value for the 'analyzeduration' and 'probesize' options [10:25:36 CEST] <sfan5> have you tried? [10:25:54 CEST] <sfan5> also why yuva420p instead of yuv420p? [10:28:08 CEST] <styler2go> sfan5, i just tried, no changes [10:28:55 CEST] <sfan5> try -probesize 50M -analyzeduration 100M [10:30:39 CEST] <styler2go> Still the same problem sadly [12:18:29 CEST] <oerg866> hello again [12:19:09 CEST] <oerg866> I'm trying to mux some vob files with high quality wav files into a new file, ffmpeg doesn't support lossless or uncompressed audio for TS so I tried muxing to a VOB file instead [12:19:20 CEST] <oerg866> I get a lot of these: [svcd @ 00000000001ce400] packet too large, ignoring buffer limits to mux it [12:19:20 CEST] <oerg866> [svcd @ 00000000001ce400] buffer underflow st=1 bufi=2608 size=2728 [12:19:28 CEST] <oerg866> the resulkting file plays fine in MPC-HC [12:19:37 CEST] <oerg866> but is it always safe to ignore these warnings? [12:19:41 CEST] <oerg866> they're red and look scary ;-) [13:10:07 CEST] <Lite> Hello! [13:10:27 CEST] <Lite> Still couldn't fix TLS/HTTPS issue at my PC.... [13:13:33 CEST] <Lite> ATM, deleted Charles, created 'Clent' and 'Server' paths at each of also created 'TLS 1.0', 'TLS 1.1' 'TLS 1.2', 'SSL 2.0', 'SSL 3.0' Paths here at Windows Registry ><?LNB5@\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL Path which was totally empty before [13:17:09 CEST] <Lite> everywhere at 'Client' and 'Server' paths created 'DWORD' parameters called 'DisableServerExtendedMasterSecret' with value=0 and 'Enabled' with value=1 [13:17:30 CEST] <Lite> Like it said here https://Docs.Microsoft.Com/En-US/windows-server/identity/ad-fs/operations/m… [13:18:22 CEST] <Lite> Also did it with RC4 at totally empty before path '><?LNB5@\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\Ciphers' [13:19:18 CEST] <Lite> restarted my PC, saw how it applies some updates (maybe meaning settings changes I made), [13:19:36 CEST] <Lite> But even after all of it nothing successfull [13:19:45 CEST] <Lite> :'C [13:20:39 CEST] <Lite> Any ideas? What else could be edited to fix this TLS/HTTPS issue? [13:21:15 CEST] <Lite> :'C [13:31:03 CEST] <styler2go> Hey there, i am still trying to save a stream to a file but it doesn't seem to save anything.. Any ideas? https://p.styler2go.de/9368806 [13:37:07 CEST] <kepstin> Lite: the ffmpeg builds you have use gnutls not schannel, so changing schannel stuff should change nothing. [13:38:09 CEST] <kepstin> styler2go: I'm not that familiar with rtsp, but it looks like the issue is that it's not receiving an IDR frame in the video before it times out. maybe there's a timeout you can adjust. [13:41:19 CEST] <styler2go> kepstin, didn't seem to work with increased timeouts [13:42:18 CEST] <Lite> @Kepstin, so what's this issue 'stucking, crashing at HTTPS requests with -i parameter' or 'impossibility to produce HTTPS requests with -i parameter' about??!! :O [13:43:18 CEST] <Lite> Is there any way to find out and fix a reason? [13:46:58 CEST] <kepstin> Lite: need to debug the issue. maybe look at the network traffic in wireshark to see if there's a difference between the versions, or try on a few more different windows systems to see if it's only the one computer. [13:49:00 CEST] <Lite> I already confirmed it is only one computer [13:50:22 CEST] <Lite> Where everything was workinmg perfect before someday when some unknown event or user's action became a reason of this unsolved for now issue [13:52:15 CEST] <Lite> Only one detail I could add to this IS that issue started at Windows 10 1703 Build. Was hoping for upgrading to current 1709 build will fix the issue... But it did not [13:52:42 CEST] <Lite> How can I debug the issue? [13:53:12 CEST] <Lite> Could you provide me step-by-step please? [13:59:58 CEST] <Lite> And also what, in your mention, could be found in Wireshark as soon as at HTTPS requests FFmpeg just stucks and crashes? [14:00:13 CEST] <Lite> It is not proceeding these URLs [14:00:31 CEST] <Lite> even if URL not existing/availiable [14:00:53 CEST] <Lite> It is just NOT proceeding it at all [14:01:08 CEST] <Lite> As I showed it at screenshot [14:02:21 CEST] <Lite> difference between the versions? LOL sure there is. 3.4.2 version works and proceeds HTTPS URLs successfully [14:25:17 CEST] <Lite> OMG [14:25:19 CEST] <Lite> Ah [14:25:20 CEST] <Lite> Ok [14:25:38 CEST] <Lite> I lied you a little bit, dear colleagues.... [14:25:47 CEST] <Lite> Mr. kepstin [14:26:33 CEST] <Lite> As I told I faced an issue in ~november or december 2017 - jan. 2018 [14:27:01 CEST] <Lite> Now exchanged current latest nightle build to different nightly build [14:27:20 CEST] <Lite> https://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-20171030-05beee4-win6… this one works perfect [14:29:09 CEST] <kepstin> october 2017, eh. that's not really all that much newer than 3.4, really. It might be helpful to try a few inbetween builds to figure out when it stopped working [14:32:06 CEST] <Lite> This one already not working https://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-20171128-86cead5-win6… [14:36:03 CEST] <kepstin> hmm. https://git.videolan.org/?p=ffmpeg.git;a=commit;h=eb061ad6fd0e3cea7cf7cfbff… was merged between those two builds, i wonder if it had some fallout on windows. [14:36:45 CEST] <Lite> YES! [14:36:48 CEST] <Lite> FOUND IT! [14:36:59 CEST] <Lite> Well.... Not so good news for me... [14:37:10 CEST] <kepstin> that is not necessarily the problem, it's just a guess [14:37:35 CEST] <kepstin> you'd want to narrow it down more and maybe even try a custom build with that reverted to see if it's really the problem. [14:43:40 CEST] <Lite> Last Nightly build (version) which is working well on my issued [for latest-for-now Nightly build (version) of FFmpeg working] machine is N-88428-g88c7aa13dd [released (published) 31.10.2017] [URL: HTTPS://FFmpeg.Zeranoe.Com/builds/win64/static/ffmpeg-20171031-88c7aa1-win6…] Nightly build (version) N-88514-gd5995c531d which has been released 02.11.2017 already stopped working as well. [URL: HTTPS://FFmpeg.Zeranoe.Com/builds/ [14:43:51 CEST] <Lite> oops [14:44:01 CEST] <Lite> Last Nightly build (version) which is working well on my issued [for latest-for-now Nightly build (version) of FFmpeg working] machine is N-88428-g88c7aa13dd [released (published) 31.10.2017] [14:44:11 CEST] <Lite> [URL: https://FFmpeg.Zeranoe.Com/builds/win64/static/ffmpeg-20171031-88c7aa1-win6…] [14:44:18 CEST] <Lite> Nightly build (version) N-88514-gd5995c531d which has been released 02.11.2017 already stopped working as well. [14:44:27 CEST] <Lite> [URL: https://FFmpeg.Zeranoe.Com/builds/win64/static/ffmpeg-20171102-d5995c5-win6…] [14:44:34 CEST] <Lite> That's it :'C [14:45:11 CEST] <Lite> What has been changed there?? [14:46:03 CEST] <Lite> Anyway. It's a good reason to provide an issue directly to Developers [14:46:31 CEST] <Lite> Because in it's issued machine it has been installed and staying for now a lot of Cryptography software for work [14:46:51 CEST] <Lite> Which is not installed at all on second machine [14:48:33 CEST] <Lite> As I understand, any of this software can be affected bad for builds of FFmpeg which are published since 02.11.2017 up to current time [14:49:48 CEST] <Lite> kepstin? Any ideas? [14:49:53 CEST] <Lite> :'C [14:51:22 CEST] <kepstin> I've stepped away from my computer, have some things to do. Later. [14:51:48 CEST] <Lite> Ah. I'm just going away too... [14:52:27 CEST] <Lite> Please note my email address to contact me: DEgorkin22(a)GMail.Com. Will wait for your reply, sir... [14:53:04 CEST] <Lite> Also, going to come back here over~ 5 hours [15:04:30 CEST] <Lite> For comfortable navigating for changes: [15:05:25 CEST] <Lite> ReadMe for version N-88428-g88c7aa13dd [released (published) 31.10.2017]: https://FFmpeg.Zeranoe.Com/builds/readme/win64/static/ffmpeg-20171031-88c7a… [15:06:56 CEST] <Lite> ReadMe for version N-88514-gd5995c531d [released (published) 02.11.2017]: https://FFmpeg.Zeranoe.Com/builds/readme/win64/static/ffmpeg-20171102-d5995… [15:12:00 CEST] <Lite> :'C [15:28:17 CEST] <Lite> What I definately believe is that any tsable or even beta version of FFmpeg after 3.4.2 shoudn't be released/published since we found an issue which should be definately fixed. [15:28:54 CEST] <Lite> Or without a release about incompatible software wich could affect the issue [15:28:56 CEST] <JEEB> 4.0 was released ages ago :P [15:29:04 CEST] <JEEB> as in more than a week ago [15:30:35 CEST] <Lite> @ JEB, 1) as soon as I faced(ing) an issue at Nigtly build released since 02.11.2017, will I face an issue at 4.0? [15:30:44 CEST] <JEEB> fuck if I know [15:30:51 CEST] <JEEB> also those builds are not official and are using gnutls? [15:30:56 CEST] <Lite> 2) Why isn't it published here https://ffmpeg.zeranoe.com/builds/ then? [15:31:01 CEST] <JEEB> ask zeranoe? [15:31:06 CEST] <JEEB> there are no official binaries of FFmpeg [15:31:19 CEST] <JEEB> but try with a build that uses SChannel on Windows [15:31:20 CEST] <JEEB> for TLS [15:31:48 CEST] <Lite> :C [15:31:52 CEST] <JEEB> most people who build for windows use schannel because that's the system TLS library [15:32:00 CEST] <JEEB> also if you have a clear issue that you can replicate [15:32:03 CEST] <JEEB> post it on trac [15:32:10 CEST] <JEEB> since at this point you've spammed a lot already [15:32:11 CEST] <JEEB> :) [15:32:14 CEST] <Lite> But we found already that's not GnuTLS or TLS issue [15:32:15 CEST] <JEEB> better put it in one place [15:32:17 CEST] <JEEB> ok [15:32:22 CEST] <JEEB> then post all that in an issue on trac [15:32:25 CEST] <JEEB> trac.ffmpeg.org [15:32:31 CEST] <Lite> LOL [15:32:46 CEST] <Lite> Thats why Im here and not there at trac [15:32:52 CEST] <JEEB> or do you expect any developer to just read your fucking long log here? [15:32:53 CEST] <Lite> can't register there [15:33:03 CEST] <Lite> spam filter and not working captcha [15:33:25 CEST] <JEEB> well I don't know, someone is maintaining that thing. but putting all this stuff here is not going to make it easier for people to test your issue [15:33:35 CEST] <JEEB> or get your issue fixed [15:33:36 CEST] <JEEB> :P [15:33:46 CEST] <JEEB> because f.ex. I just look at this wall of text [15:34:00 CEST] <JEEB> and you have no idea where to start or where the actually meaningful parts end [15:34:01 CEST] <JEEB> :P [15:34:45 CEST] <Lite> :'C [15:38:36 CEST] <Lite> Hoping for sir's @kepstin help... [15:38:57 CEST] <Lite> He knows for now about my issue almost everything [15:39:25 CEST] <kepstin> well, i'm not a core ffmpeg dev, i'm not a windows dev, i'm just a person on irc trying to help you narrow down your issue so you can report it properly [15:40:51 CEST] <Lite> And we found out it :D [15:41:51 CEST] <Lite> Next task is to try to found out a real reason depends on what changed between those 2 builds -> which one software could be affect provided in details issue. [15:42:09 CEST] <Lite> Is it possible here ? :D [15:42:50 CEST] <Lite> Fiddler is excluded. It installed on both machines [15:43:33 CEST] <Lite> Wireshark?... dunno, don't believe it. You recommended me to use it to check details [15:43:54 CEST] <Lite> So, some of cryptographic softwarte. [15:45:48 CEST] <Lite> Just wanna use actual version of FFmpeg :C [15:45:51 CEST] <Lite> :'C [15:46:23 CEST] <Lite> Still hoping you will provide me something more specific [15:46:45 CEST] <Lite> Or tell me which one logs/diags should I make and provide [16:22:53 CEST] <lightbulb6> how can i access frame metadata in a ffmpeg expression? [16:24:20 CEST] <lightbulb6> for example, the aphasemeter filter sets the value of lavfi.aphasemeter.phase frame metadata key; how can i use that value in another filter further down the filterchain, for example the zoompan filter's "zoom" parameter? [16:26:55 CEST] <durandal_1707> lightbulb6: you can not, zoompan filter does not accepts filter metadata [16:27:15 CEST] <durandal_1707> but you can with other filters, like drawtext [16:28:04 CEST] <lightbulb6> hmm, so the metadata cannot be retireved with some expression trickery? i'm thinking https://ffmpeg.org/ffmpeg-utils.html#Expression-Evaluation [16:28:33 CEST] <lightbulb6> i thought i could st() the value using the ametadata filter first, then ld() it in the zoompan expression [16:29:10 CEST] <lightbulb6> but it looks like the variables set with st() don't persist between different expressions [16:30:26 CEST] <lightbulb6> or maybe sendcmd/asendcmd could be used in some way? [16:59:14 CEST] <durandal_1707> lightbulb6: why you need to set zoompan parameters from aphasemeter? [17:23:58 CEST] <Lite> any news for me :D [17:23:59 CEST] <Lite> ?? [17:28:18 CEST] <benguitar> Hello, what is the best way to add "eta" functionality to ffmpeg on macOS? [17:28:53 CEST] <durandal_1707> there is no way [17:30:29 CEST] <benguitar> It appears that assumption is incorrect, as others have seem to have added that functionality. https://prupert.wordpress.com/2010/05/11/finally-a-bash-progress-indicator-… [18:08:57 CEST] <BtbN> Not everything ffmpeg does has a given duration/number of frames [18:09:04 CEST] <BtbN> so a generic progress indicator is impossible [18:09:29 CEST] <BtbN> If you know the length of your input, you can already just look at the processed duration yourself [18:30:41 CEST] <Lite> I created MS-info diagnostic file. Which includes list of software installed on my PC and services [18:30:52 CEST] <Lite> But it's russian language [18:30:55 CEST] <Lite> :'C [18:31:22 CEST] <Lite> Should I provide it with my issue to trac? [18:32:02 CEST] <Lite> Mr. Kepstin, do you have any news for me? [19:00:09 CEST] <AJ_> \list [19:02:05 CEST] <AJ_> anyone familiar with ffprobe? [19:03:04 CEST] <AJ_> i am using it to check the health of mpeg-DASH streams [19:03:42 CEST] <AJ_> but the bitrate seems inaccurate [19:03:45 CEST] <lightbulb6> durandal_1707: zoompan was just an arbitrary example, i'd like to create some nice visual effects to accompany the music, i noticed the output of aphasemeter corresponds to the overall volume of music at any given frame, with that data i could make the video into something more entertaining to watch than a barebones album cover, etc. [19:05:09 CEST] <utack> vmaf has been nothing but a big segfault for me. is that expected? [19:08:30 CEST] <Lite> Help me please somebody: how can I set up this IRC chat via Trillian (look at screenshot: https://Drive.Google.Com/uc?id=1VxbpOsTjxMp8OBgNRpmSRZEvIYYMnE8E) What exactly should I type in each of these 3 fields? [19:08:33 CEST] <AJ_> anyone familiar with ffprobe? [19:10:29 CEST] <AJ_> Does anyone know if FFPROBE does work with DASH? I have done multiple tests, but the reported bitrate is off [19:15:50 CEST] <lightbulb6> AJ_: the actual bitrate may be different than the value specified in the manifest [19:34:18 CEST] <AJ_> Does anyone know if FFPROBE does work with DASH? I have done multiple tests, but the reported bitrate is off [19:43:22 CEST] <utack> turns out aptx has no bitrate setting...just patents. what a stupid codec [19:48:29 CEST] <Lite> Mr. Kepstin, you here? [19:48:45 CEST] <kepstin> Lite: I am not your personal support agent. [19:48:55 CEST] <Lite> I'm sorry. [19:49:00 CEST] <Lite> I understand [19:49:09 CEST] <Lite> :'C [19:49:40 CEST] <kepstin> I've helped you out as much as I can, your next task is to file a bug report with as much as you know about the problem and how to reproduce it. [20:49:30 CEST] <AJ_> Does anyone know if FFPROBE does work with DASH? I have done multiple tests, but the reported bitrate is off [21:21:29 CEST] <SpeakerToMeat> Can quicktime files have plain xml inside? [21:23:56 CEST] <oblio> halo, having some issues concatenating webm/avc/opus uploaded from chrome into mp4/aac, anyone have any experience or pointers with that? [21:25:52 CEST] <SpeakerToMeat> I explain, somebody wants help with non playing "undeleted" video files. I suspect simply sectors of the file where overwriten after deletion, or it was non contiguous and somehow a contiguous block was recovered. the file has the moov at the start so mediainfo and ffprobe show its data, but nothing plays it. simply editing the file in an editor to check it "looks ok" (a.k.a. human giberish) I find in th [21:25:54 CEST] <SpeakerToMeat> emidle a short but complete xml, but the xml contents are congruent with camera metadata so I wonder if it's a sign of corruption, or if .mov is capable of having textual metadata inside in the form of human readable xml. [21:27:52 CEST] <SpeakerToMeat> Well actually itr's a .mp4... almost the same thing but there might be an important distinction [21:28:02 CEST] <SpeakerToMeat> it does have a moov at the header though [23:05:26 CEST] <greentea> Can we ask question about AAC encoding such as the transcode_aac.c example not working for me and i am trying to get audio encoding to work for at the least the example [23:08:19 CEST] <rindolf> hi all! how can i get this cli to work in ffmpeg 4.0? << ffmpeg -i "audiodump.wav" -i pysolfc-bhs.ogv -map 0:0 -map 1:1 -shortest -c:a libvorbis -q:a 7 -c:v copy pysolfc-bhs-with-audio.ogv >> ? [23:08:44 CEST] <furq> rindolf: you probably want -map 1:v [23:08:44 CEST] <greentea> i just got a mp3 file as the input and trying to save the output such as "transcode_aac.exe filename.mp3 filename.mp4" and i am getting that it cannot open the file (i double checked the paths), anyone let me know [23:08:55 CEST] <furq> and you probably also want that to come before -map 0:0 [23:09:05 CEST] <furq> unless ogv typically orders streams backwards [23:09:13 CEST] <rindolf> furq: ah [23:18:32 CEST] <rindolf> furq: ffmpeg -i "006 - David Amber - Gnarly _feat. Devyn Rush_.ogg" -i pysolfc-bhs.ogv -map 1:v -map 0:a -shortest -c:a libvorbis -q:a 7 -c:v copy pysolfc-bhs-with-audio.ogv ==> with this i get a zero-length file [23:18:56 CEST] <rindolf> also tried w -map 0:0 and before [23:19:22 CEST] <furq> pastebin the full command and output [23:19:39 CEST] <rindolf> furq: ok. [23:22:12 CEST] <rindolf> furq: see http://www.shlomifish.org/Files/files/text/f.txt [23:24:23 CEST] <rindolf> furq: thanks for your help [23:24:49 CEST] <furq> that doesn't look fun [23:25:00 CEST] <furq> try adding -af asetpts=PTS-STARTPTS [23:26:40 CEST] <rindolf> furq: doesnt help [23:26:53 CEST] <rindolf> furq: same result [23:32:26 CEST] <Lite> hello :D [23:33:17 CEST] <rindolf> Lite: hi [23:33:50 CEST] <Lite> Tell me please, which one parameter should I try to use to add some cpesific supported ...how it called ...protocol? which is not included at whitelist by default [23:34:01 CEST] <Lite> That whitelist where included 'http,https,tls,rtp,tcp,udp,crypto,httpproxy' [23:34:16 CEST] <Lite> I remember I did it somehow [23:34:26 CEST] <Lite> forgot how exactly :C [23:34:44 CEST] <rindolf> Lite: do you mean at ./configure? [23:35:25 CEST] <rindolf> furq: any idea? [23:36:09 CEST] <Lite> I mean... [23:36:26 CEST] <Lite> For example by default I'm using string: FFMPEG -i "<Input_file>" -c copy -crf 0 -preset placebo C:\<Output_file_path>.MP4 [23:37:12 CEST] <Lite> But I wish also to set specific parameter to access it's proceeding with what not included at whitelist [23:37:47 CEST] <Lite> 'file' for example [23:38:41 CEST] <Lite> So I'm adding to this string something like that: 'FFMPEG -<???> file -i "<Input_file>" -c copy -crf 0 -preset placebo C:\<Output_file_path>.MP4' [23:39:16 CEST] <Lite> how correctly should I exchange '<???>' which one parameter is it? [23:44:22 CEST] <rindolf> furq: any idea? [23:47:05 CEST] <Lite> looks like almost found that! Here you go: https://blog.yo1.dog/fix-for-ffmpeg-protocol-not-on-whitelist-error-for-url… that's what I told about https://blog.yo1.dog/fix-for-ffmpeg-protocol-not-on-whitelist-error-for-url… [23:47:20 CEST] <Lite> Ah sorry for duplicating URLs [23:50:08 CEST] <Lite> yes, that's definately it. '-protocol_whitelist' [23:52:28 CEST] <rindolf> Lite: thanks for letting us know [23:53:43 CEST] <Lite> NP :D [23:58:19 CEST] <rindolf> anyone? [00:00:00 CEST] --- Sat Apr 28 2018

1 0

ffmpeg-devel.log.20180426
by burek 27 Apr '18

27 Apr '18

[00:02:30 CEST] <kierank> atomnuker: what a surprise [01:14:30 CEST] <Chloe> klaxa: didnt get around to emailing about ffserver today but expect one tomorrow or the day after. (Also who is your mentor?) [01:14:47 CEST] <klaxa> atomnuker [01:15:24 CEST] <klaxa> alright thanks for taking the time, i'm currently reading through old mailing list archives to find out how debated this project really was :/ [01:15:46 CEST] <klaxa> and it must even go back further than 2015, it was already a qualification task for outreachy 2014 [01:17:47 CEST] <klaxa> and gsoc 2014 [01:17:53 CEST] <klaxa> even though ffmpeg was not accepted that year [01:31:51 CEST] <klaxa> gaaaah [01:32:10 CEST] <klaxa> in 2014 the gsoc page was on wiki.multimedia.cx for some time [01:32:27 CEST] <klaxa> apparently during that the project was added and later merged back into trac [01:32:34 CEST] <klaxa> with the history of who added it gone [01:32:54 CEST] <klaxa> aaah no there is history on the wiki, duh [01:34:00 CEST] <klaxa> it was nicolas [01:39:35 CEST] <klaxa> but i can't find any discussion of it in the archives at least not at the time it was relevant (early 2014, early 2015) [01:41:13 CEST] <klaxa> maybe i didn't look hard enough [01:49:51 CEST] <klaxa> i just had the idea of maybe using an optional external http library? like, if available and desired use libwhatever and otherwise use the built-in http server? [01:53:39 CEST] <atomnuker> meh, that'd be worse [01:54:01 CEST] <klaxa> how so? [01:56:12 CEST] <atomnuker> ifdeffery, hacks, hidden incompatibilities, no tnx [01:57:05 CEST] <klaxa> hmmm ok [07:12:47 CEST] <cone-026> ffmpeg 03guikunzhi 07master:8ea8be595166: fix memory leak of parsing dash MPD [10:19:52 CEST] <cone-026> ffmpeg 03Steven Liu 07master:798ae8794e84: avformat/dashdec: fix compling warning "filename is deprecated" [10:22:02 CEST] <JEEB> has anyone seen perf impact post-framesync2 for overlay filter? [10:22:52 CEST] <JEEB> I will probably try to do some profiling one of these days to verify that's it [10:27:47 CEST] <durandal_1707> JEEB: what? for vf_overlay.c ? [10:54:05 CEST] <cone-026> ffmpeg 03Karthick Jeyapal 07master:5b6cc3a73acb: avformat/vpcc: Calculate VP9 level from Luma's Sample rate and Picture size [10:54:06 CEST] <cone-026> ffmpeg 03Karthick Jeyapal 07master:060e74e2a970: avformat/dashenc: Set VP9 codec string with profile, level and bitdepth [10:54:07 CEST] <cone-026> ffmpeg 03Karthick Jeyapal 07master:4c27a6fbfde1: avformat/dashenc: Set mp4 as the default format for VP9 [10:55:30 CEST] <Chloe> tmm1: you asked about zvbii think it is needlessly complex [11:36:59 CEST] <nevcairiel> kierank: durandal_1707: re prores, apparently the 4444 profile is just always 12-bit, while the 422 profiles are 10-bit, if that helps at all [11:39:38 CEST] <Compn> i wonder how many prores people are using ffmpeg now [11:39:56 CEST] <Compn> i didnt realize it was such a big codec [11:40:46 CEST] <BtbN> I used prores once because it was the only codec that supports an alpha channel that fits into mp4 [11:41:16 CEST] <BtbN> It created a ridiculously big 200MB file for a few seconds long clip, but it worked [11:41:36 CEST] <Compn> https://support.apple.com/en-us/HT200321 [11:41:46 CEST] <Compn> Unauthorized codec implementations [11:41:46 CEST] <Compn> In some instances, unauthorized codec implementations have been used in third-party software and hardware products. Using any unauthorized implementation (such as the FFmpeg and derivative implementations) might lead to decoding errors, performance degradation, incompatibility, and instability. If you're using or considering the purchase of a product that encodes or decodes ProRes but isn't on the list below, please contact us at ProRes(a)apple.com. [11:41:47 CEST] <Compn> ehehe [11:42:02 CEST] <Compn> apple nailed us [11:42:16 CEST] <BtbN> ffmpeg has like 10 different prores encoders as well [11:42:18 CEST] <nevcairiel> they are just annoyed that they cant charge license fees [11:42:29 CEST] <BtbN> it's rather confusing. Only some of them support alpha [11:43:05 CEST] <nevcairiel> there is only two, and one of them supports 4444, one doesnt [11:43:08 CEST] <Compn> BtbN : good point, do any of the various encoders have docs that explain which one supports alpha? if not we should improve the docs [11:43:26 CEST] <BtbN> No idea, I just looked at the source right away [11:43:36 CEST] <Compn> ehe [11:43:53 CEST] <nevcairiel> one of them hasnt been touched since 2015 more or less [11:43:57 CEST] <nevcairiel> it should probably just be dropped [11:44:11 CEST] <Chloe> Why has it not been dropped [11:44:25 CEST] <nevcairiel> usual reasons [11:44:26 CEST] <BtbN> Because nobody cared enough to send a patch [11:45:06 CEST] <Compn> send patch and then we get complaints after its removed :D [11:45:10 CEST] <nevcairiel> paul send a patch, but the usual bike-sheeding ensued [11:46:31 CEST] <Compn> also, at the time, it was difficult to see which one would succeed [11:46:35 CEST] <Compn> and which one would be abandoned [11:46:50 CEST] <Chloe> I will rebase his patch and enact anti-bikeshedding order #3732, if durandal_1707 doesnt want to it himself [11:46:54 CEST] <Compn> and also no one cared to compare them, and they had different features (although that was sync'd long ago iirc) [11:47:12 CEST] <nevcairiel> the _ks variant has more features these days [11:47:19 CEST] <Compn> Chloe : that would be useful, as you are new to bikeshedding and may handle it differently [11:48:38 CEST] <Compn> Chloe : also it maybe good idea to alias the prores name you remove to the other one. e.g. for old scripts that use -prores_anatoly or whatever , have it automatically use the encoder still in [11:49:07 CEST] <nevcairiel> anatoly was the old default, its unlikely anyone accessed it directly [11:49:24 CEST] <Compn> those apple users are weird :P [11:49:34 CEST] <Compn> also the archivists [11:49:46 CEST] <Compn> but they will already be angry we removed it :P [11:49:46 CEST] <Chloe> Compn: Id hardly say Im new to bikeshedding... but yes, compatibility should be kept as much as required [11:50:10 CEST] <Chloe> Clearly they should just use ffv1 [11:50:11 CEST] <Compn> Chloe : you are experienced with ffmpeg bikeshedding already? :) [11:50:36 CEST] <Chloe> Compn: I did sdl2 and the new iter api [11:50:52 CEST] <Compn> oh what fun :) [11:51:34 CEST] <Chloe> I didnt manage to get the opengl output device to be dropped though [11:51:44 CEST] <Chloe> Maybe Ill also resend a patch for that [11:53:45 CEST] <durandal_1707> no, please no [11:53:49 CEST] <durandal_1707> lavd needs new api [11:54:39 CEST] <Compn> i like idea of opengl output [11:54:52 CEST] <Compn> ffmpeg can finally absorb mplayer :) [11:55:15 CEST] <Compn> now just need binary codec loader.... [11:55:54 CEST] <Chloe> Compn: why does it need to be in the libraries [11:56:06 CEST] <Compn> why what need to be where ? [11:56:13 CEST] <Chloe> Why does libavdevice need a renderer [11:56:23 CEST] <Chloe> (Hint: it doesnt) [11:56:42 CEST] <Compn> i didnt say it had to be in libraries [11:57:04 CEST] <Chloe> Compn: well it is currently in the library [11:57:16 CEST] <Chloe> And thats the issue [11:57:25 CEST] <Compn> i dont mind if you change it :) [11:57:58 CEST] <Chloe> durandal_1707: yes. I really want to do it, but I dont have hardware to test the major devices in lavd [12:01:41 CEST] <Chloe> durandal_1707: also why you against removing lavd components if you want a new api? The less components there are the easier it is [12:08:34 CEST] <Compn> interesting looks like a lot of articles of people using ffmpeg to convert 4k stuff to 1080 :D [12:10:25 CEST] <Chloe> Compn: which filter they suggesting? [12:12:06 CEST] <Compn> averaging area in one article [12:12:09 CEST] <Compn> lets see the other [12:12:36 CEST] <Compn> oh im not getting proper google results these pages might be outdated [12:13:37 CEST] <Compn> other article uses a frontend with different names for filters [13:23:00 CEST] <Chloe> 'I was wondering if there is any chance to move development to github?' [13:32:43 CEST] <durandal_1707> Chloe: how would you move fate tests? [13:35:00 CEST] <durandal_1707> gonna remove another prores decoder NOW! you can not stop me! [13:35:53 CEST] <durandal_1707> i wrote 12bit prores support, but than i found out that we have 2 decoders, so i need to add this support for both of them? [13:36:47 CEST] <durandal_1707> also there is no asm for 12 bit simple idct, i wrote asm for 12bit prores, but it was not bitexact as it used 10 bit idct [13:37:30 CEST] <durandal_1707> and i can not really do only C version as asm one have different idct permutation [13:43:42 CEST] <wm4> durandal_1707: post some numbers and the decision is clear [13:44:47 CEST] <wm4> klaxa: in the end I'd say do what you feel like doing [13:45:16 CEST] <wm4> that'll probably lead to the best outcome anyway [13:45:50 CEST] <wm4> or at least I think that's how it should go [13:46:06 CEST] <cone-026> ffmpeg 03Carl Eugen Hoyos 07master:3914a76db687: lavf/rtmpcrypt: Add a cast to silence an unavoidable warning. [13:46:10 CEST] <wm4> if you want to extend/improve the native http server, go ahead; if you found a nice external lib you'd like to use, go ahead [13:48:44 CEST] <Chloe> klaxa: yeah, in the end wm4 is right but I would recommend at least looking at the nginx module i linked (maybe you could just extend that) [13:49:01 CEST] <durandal_1707> wm4: this is about decoder - they give same results with same speed [13:49:34 CEST] <wm4> wait so we have multiple prores encoders and decoders or what [13:49:49 CEST] <nevcairiel> two of both [13:49:52 CEST] <wm4> DEVIL. prores Apple ProRes (iCodec Pro) (decoders: prores prores_lgpl ) (encoders: prores prores_aw prores_ks ) [13:49:58 CEST] <wm4> 2 decoders 3 encoders [13:50:04 CEST] <wm4> heh [13:50:05 CEST] <nevcairiel> two of t hose encoders are the same one [13:50:10 CEST] <wm4> ah [13:50:16 CEST] <nevcairiel> prores is prores_aw [13:50:57 CEST] <wm4> I guess decoders are easier to compare [13:51:27 CEST] <wm4> durandal_1707: how is one of them better? [13:53:30 CEST] <durandal_1707> decoders give same output, just one code is prettier than other [13:53:55 CEST] <wm4> seems like a good reason [13:54:10 CEST] <durandal_1707> and prores_lgpl had more features until carl copy pasted code to aw decoder [13:54:23 CEST] <nevcairiel> are they the same license now? same speed? [13:54:58 CEST] <durandal_1707> see git history, it is one huge mess of renaming and relicensing [14:01:33 CEST] <durandal_1707> for speed i need to check again [14:06:27 CEST] <Chloe> durandal_1707: youd just move the repo, the fate tests would still have to be somewhere else, but its not really practical anyway [15:42:42 CEST] <jamrial> wow, the mailman version used for ffmpeg-devel not only fucks up pgp signed email by Thunderbird+enigmail, but also by Apple Mail [15:43:03 CEST] <BtbN> Never had an issue with that [15:43:16 CEST] <jamrial> the only mulitpart mails i see that don't get runied by mailman scrambling it are from mutt [15:43:53 CEST] <jamrial> BtbN: look at the github thread, jdarnley's and Daniel Oberhoff's mails [15:44:34 CEST] <jamrial> then look at Nicolas' [15:44:37 CEST] <jamrial> or any email by michaelni [15:45:22 CEST] <jdarnley> Time I finally went to mutt? [15:46:12 CEST] <jamrial> mailman doesn't play nice with some specific kind of mulitpart emails at the time of adding the list signature attachment [15:46:33 CEST] <jamrial> and it scrambles the original email contents, making the pgp signature invalid [15:47:33 CEST] <jamrial> who manages the server running mailman? maybe this was addressed in a more recent version... [15:47:42 CEST] <BtbN> jamrial, I don't see any issues? [15:47:54 CEST] <BtbN> Or difference between their mails [15:48:11 CEST] <jamrial> BtbN: do the pgp signatures in those emails show up as valid for you? [15:48:20 CEST] <BtbN> They all tell me "Parts of this message are signed" [15:48:24 CEST] <BtbN> and then highlights which parts [15:48:41 CEST] <wm4> heh the mkvtoolnix gitlab link isn't loading for many people [15:49:05 CEST] <j-b> gitlab is mostly down today or very very slow [15:49:13 CEST] <jamrial> BtbN: using thunderbird? is that message in a yellowish bar? [15:49:31 CEST] <BtbN> jamrial, Blueish-Bar now, since I imported the keys [15:49:37 CEST] <BtbN> but yes, Thunderbird with Enigmail [15:50:57 CEST] <jamrial> BtbN: for jdarnley and Daniel's email, i get a yellowish bar saying "Parts of this message are signed", then when i click on security info, i see "BAD signature from [...]" [15:50:58 CEST] <BtbN> there is only one mail of them that has an invalid signature, the 14:41 CEST one [15:51:13 CEST] <BtbN> (last one from Danial in the github thread) [15:51:17 CEST] <BtbN> the other ones verify successfully [15:51:26 CEST] <jamrial> Nicolas and michaelni emails are blueish, and it says "Good signature" [15:51:37 CEST] <wm4> j-b: apparently it's really hard to setup gitlab, and it will be slow as shit [15:51:55 CEST] <wm4> I wonder how videolan is coping [15:52:38 CEST] <BtbN> jamrial, it only seems to break some mails [15:52:45 CEST] <BtbN> and I'm tempted to blame thunderbird? [15:53:28 CEST] <BtbN> Like, the original mail from Danial is fine [15:53:29 CEST] <jamrial> as in, enigmail parsing them wrong rather than mailman ruining them before delivery? [15:53:35 CEST] <BtbN> yes [15:54:00 CEST] <BtbN> Or something, somewhere, strips whitespaces or converts charset [15:54:06 CEST] <jamrial> so far, every email created by enigmail and passed through mailman doesn't validate for me, and now this one from Apple Mail [15:54:14 CEST] <jamrial> mutt email is always ok [15:54:23 CEST] <BtbN> then most of his mails are unsiged, the original from him in github is fine [15:54:26 CEST] <BtbN> his last in github is broken [15:55:04 CEST] <cone-026> ffmpeg 03Derek Buitenhuis 07master:28503c5aea5f: mov: Properly abide by the track's media duration [15:57:18 CEST] <jamrial> BtbN: guess the only way to confirm this is someone using mutt or some other client confirming they also get bad signature on those mails [15:57:50 CEST] <BtbN> It also broke my reply to the C++ nvcodec [15:57:53 CEST] <BtbN> which was just one word [15:58:11 CEST] <BtbN> unsurprisingly, the one I sent is fine [15:58:19 CEST] <BtbN> so lets compare the two raw mails [16:02:29 CEST] <BtbN> jamrial, this is confusing. I saves the raw mail that's broken, and the "ffmpeg-devel mailing list" footer isn't even in there [16:03:16 CEST] <jamrial> BtbN: it should be at the end, in base64 [16:03:31 CEST] <BtbN> oh, indeed [16:03:34 CEST] <BtbN> why is it base64 [16:09:05 CEST] <ubitux> i'll apply the AV_OPT_FLAG_DEPRECATED and its associated http patch tonight [16:09:20 CEST] <ubitux> along with thread message queue function [16:09:43 CEST] <ubitux> tonight = ETA ~ h-4 [16:10:55 CEST] <BtbN> jamrial, it's definitely mailman breaking it. Intact signed part: https://bpaste.net/show/1d477460f7cc What mailman makes of it: https://bpaste.net/show/69df0894253b [16:11:09 CEST] <BtbN> I'm not 100% sure which parts are signed, but all of them are changed [16:12:08 CEST] <BtbN> There's also a suspicious line in the headers: X-Content-Filtered-By: Mailman/MimeDel 2.1.20 [16:14:00 CEST] <jamrial> yeah, it doesn't play nice with too many parts, and seems to remove one of the boundaries when it rebuilds the mail to add its own attachment [16:14:59 CEST] <jamrial> enigmail could admitedly create simpler signed emails, much like mutt, but mailman definitely shouldn't break anything like this [16:47:50 CEST] <wm4> we should have an avcodec_set_parameters_from_avframe() function [16:48:05 CEST] <durandal_1707> patch welcome [16:50:04 CEST] <cone-026> ffmpeg 03Paul B Mahol 07master:161e006cc02e: avfilter: add tmix filter [16:50:05 CEST] <cone-026> ffmpeg 03Paul B Mahol 07master:a5172dcab67f: avfilter/vf_mix: add scale option [16:50:06 CEST] <cone-026> ffmpeg 03Paul B Mahol 07master:330215830ef9: avfilter/vf_mix: clip output pixel values [17:18:13 CEST] <cone-026> ffmpeg 03Jerome Borsboom 07master:02e4970bc9d3: avcodec/vc1: fix out of bounds access of overlap filter [17:35:58 CEST] <BtbN> hm, I'm not sure about adding more and more stuff to the ffnvcodec headers which are not needed by ffmpeg [17:36:28 CEST] <atomnuker> its fine if they're optional [17:36:36 CEST] <BtbN> I'm more concerned license-wise [17:36:52 CEST] <atomnuker> why? [17:37:00 CEST] <atomnuker> its lgpl, isn't it? [17:37:11 CEST] <BtbN> Yes, ours is, because it's a re-implementation [17:37:25 CEST] <BtbN> If the patch author just straight up copied that from the nvidia headers, which have a restrictive proprietary license, that's a problem. [17:38:13 CEST] <wm4> mpv uses those headers too [19:45:52 CEST] <cone-026> ffmpeg 03Clément BSsch 07master:71fa82bed62f: lavu/threadmessage: add av_thread_message_queue_nb_elems() [19:53:20 CEST] <cone-026> ffmpeg 03Clément BSsch 07master:5be0410cb31c: lavu/opt: add AV_OPT_FLAG_DEPRECATED [19:53:21 CEST] <cone-026> ffmpeg 03Clément BSsch 07master:2e341eb15bf8: lavf/http: use AV_OPT_FLAG_DEPRECATED for user-agent option [20:08:24 CEST] <peloverde> Is new avcC side data supposed to make it to the h264 parser? It seems to be getting lost on me. [20:08:57 CEST] <JEEB> avcC side data?! o_O [20:09:09 CEST] <peloverde> yes like in flv [20:09:09 CEST] <JEEB> I thought that was in extradata, not side data [20:09:31 CEST] <JEEB> funky [20:09:33 CEST] <peloverde> You are right [20:09:35 CEST] <peloverde> it is AV_PKT_DATA_NEW_EXTRADATA [20:09:51 CEST] <JEEB> that is funky [20:10:03 CEST] <jamrial> that depends [20:10:03 CEST] <JEEB> so we do extradata updates with side data now? [20:10:10 CEST] <jamrial> of course [20:11:52 CEST] <peloverde> from what I can tell it makes it to the decoder, but not the parser, so the parser screams and screams and screams [20:12:00 CEST] <jamrial> parsers don't handle packets, just raw data, so new extradata sent through packet side data will not be seen by it [20:12:42 CEST] <wm4> just replace parsers by BSFs already [20:59:08 CEST] <atomnuker> so now I understand why kmsgrab mapping to vulkan works on one of my machines with an nvidia proprietary drivers and optimus [20:59:31 CEST] <atomnuker> the nvidia card draws into the intel card since the intel card is connected to the display [20:59:42 CEST] <atomnuker> so the intel card has access to the screen [21:00:10 CEST] <atomnuker> and the reason why I don't see tiling is because the buffer on the intel is linear [21:00:49 CEST] <atomnuker> and if I run something with wayland I see tiling because I presume the compositor picks an optimal texture format which is tiled [21:02:12 CEST] <atomnuker> makes sense because both gpus have their own tiling so the only way to interop them is by transferring the buffer linearly [21:41:55 CEST] <klaxa> mmhh i'm really favoring being http server/implementation independent [22:31:20 CEST] <durandal_1707> static const int elem_offset[sizeof(num_bins_in_se)] <---- this one should be uint8_t [22:34:54 CEST] <cone-026> ffmpeg 03Paul B Mahol 07master:356a33b20aec: avfilter/vf_atadenoise: do not abort if user specified invalid size [22:37:06 CEST] <JEEB> oh, so akamai dudes had push rights? [22:37:20 CEST] <JEEB> I was going to comment on one of their patches and the guy pushed it after ~2 days [22:37:37 CEST] <JEEB> the darn commit message doesn't even tell you the asdf truth [22:37:42 CEST] <durandal_1707> JEEB: which patch? [22:37:49 CEST] <JEEB> [PATCH v2 3/3] avformat/dashenc: Set mp4 as the default format for VP9 [22:37:59 CEST] <JEEB> I mean, I'm not sure what 1,2 did [22:38:19 CEST] <JEEB> but unless they did some magic it's not the default format but they just quietly moved it out of the webm list [22:38:29 CEST] <JEEB> (because webm is broken) [22:38:48 CEST] <JEEB> do note that I agree with the idea of making the default VP9 [22:38:55 CEST] <JEEB> since browsers seem to be able to play that [22:40:13 CEST] <durandal_1707> this all shady, for commit rights, it is enough to request to be maintainer for some part of ffmpeg code [22:40:32 CEST] <atomnuker> JEEB: just revert it and ask [22:41:04 CEST] <JEEB> I don't use dashenc.c and I'm most definitely not going to start a revert war. I will possibly write a response on the ML [22:41:25 CEST] <JEEB> I only knew webm mode was broken because I heard it from a facebook person [22:41:31 CEST] <atomnuker> there's no such thing as revert wars nowadays, especially with these people [22:41:32 CEST] <JEEB> and I debugged it one lonely night [22:41:48 CEST] <JEEB> but yea, I will take a look at it in context [22:41:57 CEST] <JEEB> if the 1,2 out of 3 did something nice [22:55:35 CEST] <BtbN> VP9 in browsers is horrible though, no hwaccel [22:56:50 CEST] <kierank> durandal_1707: of course, you just ask and get commit [22:57:04 CEST] <kierank> you also ask and get to host ffmpeg.org and trac [23:06:00 CEST] <j-b> /lastlog durandal_1707 [23:06:03 CEST] <j-b> :) [23:06:07 CEST] <j-b> hello guys [23:06:22 CEST] <j-b> BtbN: why don't they accelerate it? Do you know? [23:06:53 CEST] <BtbN> Lack of wide spread HW support I guess [23:07:05 CEST] <j-b> I thought recent nvidia/Intel chips had it. [23:07:08 CEST] <BtbN> iirc hwaccel in Browsers on Linux is also disabled entirely [23:07:14 CEST] <BtbN> because of the API chaos [23:07:25 CEST] <BtbN> And questionable stability [23:07:35 CEST] <j-b> yeah [23:07:42 CEST] <j-b> annoying for webgl [23:08:17 CEST] <BtbN> WebGL works fine [23:08:20 CEST] <BtbN> it's just video hwaccel [23:08:46 CEST] <BtbN> Seems like Chrome in Windows does accelerate VP8 and 9 now [23:08:51 CEST] <BtbN> Firefox just hasn't implemented it it seems [23:09:16 CEST] <atomnuker> I don't think firefox really cares about the API chaos aspect of it [23:09:37 CEST] <atomnuker> because afaik they only care about windows mainly [23:09:48 CEST] <atomnuker> so they just need dxva there and that's it [23:11:18 CEST] <atomnuker> as for linux, if it somewhat works, its good enough (opengl compositing accerelation is still disabled unless you force it) [23:12:37 CEST] <atomnuker> and even if there was decoding accerelation it still has to go back to system ram and through a few copies before finally being composited and displayed [23:13:20 CEST] <atomnuker> *at least* they stopped damaging the entire window a few versions ago on every frame and just damage what they need to [23:13:35 CEST] <BtbN> Yeah, Firefox on Linux is in a very sorry state, I switched to Chrome because of that. And even there it's pretty bad. [23:13:53 CEST] <atomnuker> not chromium? [23:14:05 CEST] <BtbN> I'm not going to build that on every update, takes hours. [23:14:06 CEST] <wm4> firefefox is in a sorry state anywhere [23:14:15 CEST] <BtbN> It's fine on Windows [23:14:15 CEST] <wm4> *firefox [23:14:19 CEST] <wm4> nope [23:14:34 CEST] <wm4> also some of the sorry is portable [23:15:00 CEST] <wm4> btw. does anyone know how to add custom search prefixes? [23:15:11 CEST] <wm4> without running 3rd party code [23:15:14 CEST] <atomnuker> BtbN: are you on gentoo? [23:15:17 CEST] <BtbN> yes. [23:15:24 CEST] <BtbN> Edit your search engine, and write the Prefix there? [23:15:31 CEST] <BtbN> I'm 99% sure that's a core feature and just there. [23:15:31 CEST] <atomnuker> wasn't there a sort of a binary repo for gentoo [23:15:39 CEST] <BtbN> Chrome is binary [23:15:42 CEST] <BtbN> Chromium you build yourself. [23:15:50 CEST] <wm4> BtbN: where [23:15:52 CEST] <BtbN> And since it's practically the same code [23:15:58 CEST] <BtbN> wm4, in the search engine editor [23:16:15 CEST] <wm4> where, I only see a list where I can delete entries, nothing else [23:16:26 CEST] <atomnuker> I'd rather take a day to build it if I had no other option than install literal google spyware [23:16:28 CEST] <BtbN> about:preferences#search [23:17:16 CEST] <BtbN> Yeah, the Keyword field is just right there, and you can freely edit it. [23:18:32 CEST] <wm4> BtbN: yeah, I can only delete things there [23:18:45 CEST] <BtbN> works fine for me [23:18:55 CEST] <wm4> there's also a link "Add more search engines..." that leads to some WTF garbage that probably makes people accidentally install spyware [23:18:57 CEST] <BtbN> double click the Keyword, edit it [23:19:21 CEST] <wm4> yeah, changing the keyword works, but adding a new entry? [23:19:30 CEST] <wm4> this makes me wonder wtf mozilla is fucking doing [23:19:53 CEST] <BtbN> you are aware that you can right click basically any input field on any website, and click "Add keyword for this Search", and it will appear there? [23:19:54 CEST] <wm4> it's just a bad chrome clone now anyway [23:20:05 CEST] <wm4> BtbN: doesn't work for wikipedia [23:20:32 CEST] <BtbN> Just tested it. Works [23:21:45 CEST] <wm4> it just adds a bookmark [23:21:50 CEST] <wm4> I don't want a fucking bookmark [23:22:07 CEST] <BtbN> And the bookmark has a keyword, and when you prefix something in the URL bar with that keyword, it will use that bookmark for the search [23:22:12 CEST] <BtbN> which seems to be exactly what you want? [23:22:30 CEST] <wm4> I'd probably edit the config files directly, but it's all either hundreds of KBs XML gibberish, or sqlite [23:22:44 CEST] <BtbN> No idea what you're on about, it works just fine for me. [23:22:45 CEST] <wm4> well that didn't work either [23:22:50 CEST] <wm4> I only had a bookmark [23:23:00 CEST] <BtbN> Yes, it _is_ a bookmark. With a keyword for the searchbar [23:23:29 CEST] <wm4> actually now it worked [23:23:35 CEST] <wm4> but after removing the bookmark it's gone again [23:23:49 CEST] <BtbN> well, that's not overly surprising, since the keyword is set on the bookmark [23:23:59 CEST] <wm4> it also doesn't show up in the preferences (even while the bookmark is added) [23:24:08 CEST] <wm4> and the other searches don't have any bookmarks anywhere [23:24:20 CEST] <BtbN> The other searches that show up there are Browser-Extensions [23:24:25 CEST] <BtbN> the default one are hidden default ones [23:24:42 CEST] <wm4> that seems fucking stupid [23:24:42 CEST] <BtbN> custom stuff is only done via bookmark [23:25:37 CEST] <wm4> also I wonder when firefox will stop leaking memory [23:26:01 CEST] <j-b> never [23:26:06 CEST] <atomnuker> hasn't leaked for me in a while? [23:36:32 CEST] <JEEB> there, herped a derp at akamai [23:51:24 CEST] <JEEB> michaelni: shall we just remove the webm mode from dashenc.c in the branches where it segfaults (it might just segfault in all branches where the feature lies currently) [23:51:38 CEST] <JEEB> since we didn't get any reports about it seemingly, and people are not interested in fixing it [23:52:19 CEST] <JEEB> it can be quickly tested with any VP9 input, `ffmpeg -i INPUT -c copy -b:v 2M out.mpd` (since it doesn't read maxrate) [23:55:19 CEST] <JEEB> related thread: https://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/229058.html [23:56:37 CEST] <JEEB> and while I do not care about dashenc.c too much, it's still infuriating when people don't just seem to do the Right Thing [23:58:48 CEST] <JEEB> also jamrial ^ [00:00:00 CEST] --- Fri Apr 27 2018

1 0

ffmpeg.log.20180426
by burek 27 Apr '18

27 Apr '18

[01:01:35 CEST] <giaco> hello [01:02:01 CEST] <giaco> ffmpeg -f v4l2 -i /dev/video0 -> ioctl(VIDIOC_QUERYCAP): Inappropriate ioctl for device [01:36:13 CEST] <oliverdain> hey - I have some C code that is encoding a video. It works fine on OSX. I re-compiled it for Linux and changed the encoder from ffmpeg native to libx264. It still "works" but now the first few frames of video are grey. I compared the ffprobe -show_frames -pretty output between what Linux and OSX generate and the only difference is the sizes of those initial frames. They're *tiny* on the Linux version: 12 bytes instead of 100+k [01:36:21 CEST] <oliverdain> Why ideas what could be causing that? [01:50:59 CEST] <kepstin> oliverdain: the x264 encoder doesn't generate an output frame for each input frame - it has a delay [01:52:12 CEST] <kepstin> i suppose what you're describing might happen if you aren't handling this correctly, and try to mux null frames into the output [01:54:38 CEST] <oliverdain> kepstin: we have the normal loop were we call avcodec_receive_packet and then bail if we get EAGAIN. If we don't get EAGAIN (or other error code) we call av_interleaved_write_frame. Isn't that the right sequence [01:55:22 CEST] <kepstin> hmm, that should be correct then. [01:55:31 CEST] <oliverdain> so if x264 isn't ready to generate an output avcodec_receive_packet should return EAGAIN and that's OK. Then at some later point we'd go through our loop multiple times and those frames would be output, right? [01:55:39 CEST] <kepstin> yeah. [01:56:01 CEST] <kepstin> so, hmm. i guess the place to look into would be the input to the encoder, then. [02:29:45 CEST] <Pandela> Hey guys. I was curious if anyone has gotten local lv2 plugins to work with the new option to load lv2 plugins? [02:30:13 CEST] <Pandela> Or are http:// urls the only suppoeted option? [02:33:13 CEST] <Pandela> If I try to specify a file to use I just get invalid uri [02:52:18 CEST] <Pandela> I noticed that if I do "ffmpeg -i input.wav -af lv2=plugin=http:\\\\://lv2plug.in/plugins/eg-amp output.wav" It works. [02:52:58 CEST] <Pandela> Its calling an lv2 in my usr/local/lib/lv2/ folder [02:54:02 CEST] <Pandela> I know that because i have no internet and I edited the file to see if it changed the lv2 plugin in ffmpeg. So you would think one would be able to call a local lv2 plugin no? [02:54:04 CEST] <furq> maybe file:// [02:54:11 CEST] <furq> or however much escaping that needs [02:59:24 CEST] <Pandela> @furq no luck with that either :c I tried using the .so and .ttl files [03:26:21 CEST] <Pandela> I'll have to just keep trying and checking back if there's a solution [04:53:57 CEST] <hotbobby> what would be the most obvious way to have ffmpeg recognize the input file's video stream is x264 and then make it just -c:v copy instead of transcode [04:54:16 CEST] <furq> ffprobe [04:55:05 CEST] <hotbobby> oh wow. thank you. i did not know this tool existed [04:55:25 CEST] <furq> i'll save you the effort of figuring it out [04:55:29 CEST] <hotbobby> scripting my desired behavior is straightforward now, i have to see that it works on streams but im sure it does [04:56:05 CEST] <furq> [ $(ffprobe -v error -select_streams v:0 -show_entries stream=codec_name -f default=nk=1:nw=1 "foo") = "h264" ] [04:56:21 CEST] <hotbobby> wow! [04:56:53 CEST] <hotbobby> so the part before the equals will either return h264 or not? [04:56:58 CEST] <furq> right [04:57:05 CEST] <hotbobby> excellent, thank you very much [04:59:06 CEST] <hotbobby> it doesnt like the -f part [04:59:51 CEST] <furq> sorry, -of [04:59:52 CEST] <hotbobby> taking that out gives me a few more lines but i can just test for the line "codec_name=h264". still works [04:59:55 CEST] <hotbobby> ooo let me try that [05:00:12 CEST] <hotbobby> amazing! [15:12:49 CEST] <AppleTor> weird, got this message from ffmpeg on ubuntu "https protocol not found, recompile FFmpeg with openssl, gnutls or securetransport enabled." [15:12:55 CEST] <AppleTor> never happen on my mac [15:16:09 CEST] <JEEB> you just don't have a lunix TLS implementation enabled [15:16:27 CEST] <JEEB> macs and windows have their own things, which might get enabled by default? [15:16:41 CEST] <JEEB> and since they're system things you don't need to install devleopment packages for them separately :P [15:17:56 CEST] <AppleTor> will running brew install ffmpeg --with-openssl --with-gnutls going to solved the problem? [15:19:46 CEST] <AppleTor> ah it works now [15:22:50 CEST] <atomnuker> you don't need both openssl and gnutls [15:22:56 CEST] <atomnuker> just one, preferably gnutls [15:23:37 CEST] <JEEB> didn't macs have their own TLS library? and wasn't your problem with *ubuntu* , not macs? [15:23:46 CEST] <JEEB> lul [15:25:04 CEST] <dragmore88> hi, trying to encode a UHD clip and ffmpeg is barfing: ./ffmpeg-10bit -loglevel verbose -i "BBC_Short_HDR.mov" -strict -1 -vf scale=out_color_matrix=bt2020nc:out_h_chr_pos=0:out_v_chr_pos=0,format=yuv420p10 -an -r 25 -f yuv4mpegpipe - | "x265.exe" --y4m - --output-depth 10 --input-res 3840x2160 --fps 25 --preset medium --b-adapt 2 --ref 4 --no-open-gop --keyint 50 --rc-lookahead=50 --profile main10 --level-idc 5.1 --no-high-tier --sa [15:25:04 CEST] <dragmore88> t2020 --transfer smpte-st-2084 --colormatrix bt2020nc --b-pyramid --bframes 4 --hrd --vbv-bufsize 35000 --crf18 --vbv-maxrate 80000 --slow-firstpass --aud --chromaloc 2 --max-cll "1000,400" --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,0.0050)" --repeat-headers -vn -filter_complex "[0:7][0:8]amerge=inputs=2[aout]" -map "[aout]" -c:a libfaac -q:a 330 -y BBC_HDR [15:25:04 CEST] <dragmore88> _HRD.ts -loglevel debug [15:25:17 CEST] <dragmore88> av_interleaved_write_frame(): Broken pipe [15:25:21 CEST] <dragmore88> Error writing trailer of pipe:: Broken pipe [15:25:25 CEST] <dragmore88> [swscaler @ 0x87db740] YUV color matrix differs for YUV->YUV, using intermediate RGB to convert [15:25:25 CEST] <dragmore88> [yuv4mpegpipe @ 0x670f440] Warning: generating non standard YUV stream. Mjpegtools will not work. [15:26:00 CEST] <dragmore88> anyone know what can be wrong ? [15:27:01 CEST] <AppleTor> atomnuker I have already installed both ð [15:29:06 CEST] <AppleTor> JEEB it's running just fine on my mac, the problem was on my ubuntu machine [15:29:19 CEST] <JEEB> yes [15:29:25 CEST] <AppleTor> using it along with youtube-dl [15:29:28 CEST] <JEEB> exactly that's why you asking about your homebrew config was weird [15:29:47 CEST] <JEEB> since seemingly your *mac* thing was working JustFine [15:29:51 CEST] <JEEB> so why ask about that? [15:30:09 CEST] <AppleTor> i have homebrew installed on my ubuntu too [15:30:20 CEST] <JEEB> ugh [15:30:34 CEST] Action: JEEB erases that line from his memory with brain bleach [15:30:48 CEST] <AppleTor> ð [15:32:16 CEST] <AppleTor> ah onemore thing. why ffmpeg with https proxy on ubuntu decoding the chunk link one by one, like literally one by one. [15:32:48 CEST] <AppleTor> while on my mac it's just downloading smoothly. am i missing something? [15:36:13 CEST] <AppleTor> MAC:https://pastebin.com/CVuTyMZT Ubuntu: https://pastebin.com/cAbmZ5z7 [15:45:31 CEST] <kepstin> dragmore88: the lines you posted are just warnings, they wouldn't have stopped the ffmpeg command from working. Please pastebin the *complete* output. [15:50:23 CEST] <dragmore88> kepstin,https://pastebin.com/GguejQ6j [15:51:26 CEST] <kepstin> dragmore88: "-bash: x265.exe: command not found" [15:52:52 CEST] <kepstin> there's your problem. ffmpeg exits early because the other end of the pipe it's writing to is disconnected, because the x265 process couldn't be started. [15:56:33 CEST] <dragmore88> kepstin, ure right! i didnt see that one... its on a linux box.. and my syntax was done on a windoze pc... i just changed it to ./x265 but doest want to use it.. [15:56:57 CEST] <kepstin> assuming you have x265 installed and in the path, it's just "x265" [15:57:13 CEST] <dragmore88> its there.. both in the same directory and in the global path [15:57:16 CEST] <kepstin> but why are you running external libx265 anyways? ffmpeg can use the x265 encoder as a library [15:57:34 CEST] <kepstin> external x265 cli tool* [15:58:11 CEST] <dragmore88> well.. it was an old syntax from a time half a year ago when one had to use it for hdr [15:58:18 CEST] <dragmore88> i need to convert it for libx265 now [16:01:42 CEST] Last message repeated 1 time(s). [16:01:42 CEST] <dragmore88> kepstin, can u see any wrongdoings in this one then : https://pastebin.com/2B1mKaQU [16:01:49 CEST] <dragmore88> im getting only audio..?? ;) [16:02:06 CEST] <sfan5> you have -vn [16:02:20 CEST] <sfan5> and you'd need to -map the video output too [16:02:38 CEST] <dragmore88> https://pastebin.com/8EDeDxvy [16:02:44 CEST] <dragmore88> ah [16:03:15 CEST] <dragmore88> whats the problem with -vn ? [16:03:52 CEST] <sfan5> -vn disables video [16:03:56 CEST] <dragmore88> oh [16:03:58 CEST] <dragmore88> right [16:04:53 CEST] <dragmore88> removed that one.. still getting the same problem.. i need to map the video.. never done that before [16:07:55 CEST] <dragmore88> https://pastebin.com/5ePhUKgy [16:10:26 CEST] <dragmore88> ./ffmpeg-10bit -loglevel verbose -i "BBC_Short_HDR.mov" -map 0:0 -map 0:1 -pix_fmt yuv422p10le -codec:v libx265 -x265-params "colorprim=bt2020:transfer=smpte-st-2084:colormatrix=bt2020nc:master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,10):max-cll=0,0:rc-lookahead=50:keyint=100:min-keyint=50:hrd=1:vbv_maxrate=75000:vbv_bufsize=33000" -crf 18 -force_key_frames "expr:e [16:10:26 CEST] <dragmore88> q(mod(n,50),0)" -filter_complex "[0:7][0:8]amerge=inputs=2[aout]" -map "[aout]" -c:a aac -q:a 330 -y test1.ts [16:10:41 CEST] <dragmore88> added a map.. seems to work now [16:18:52 CEST] <dragmore88> how can i force the ouput as 4:2:0 10bit and 1 stereo aac track.. i got 2 stereo tracks and 422 output.. ? [16:21:10 CEST] <sfan5> -pixfmt yuv420p10le [16:21:24 CEST] <sfan5> for audio just remove the filter_complex construct you got there(?) [16:22:19 CEST] <dragmore88> problem is that for the audio, the source is a prores with a ton of channels.. i need to pick channel 7 and 8, merge em together as a stereo track [16:23:06 CEST] <dragmore88> 9 PCM tracks [16:23:10 CEST] <dragmore88> mono [16:24:17 CEST] <dragmore88> both output audio tracks are stereo [16:24:22 CEST] <dragmore88> different bitrates.. [16:25:37 CEST] <AppleTor> can't you use map to select which audio you want to use? [16:26:05 CEST] <AppleTor> i'm not so sure either, never did it before [16:26:54 CEST] <kepstin> with the -map stuff you have, there should only be a single stereo track output [16:27:33 CEST] <kepstin> if you use any -map options, ffmpeg will include a single output track for each -map option present [16:41:52 CEST] <AppleTor> why ffmpeg with https proxy on ubuntu decoding the chunk link one by one, like literally one by one. [16:41:52 CEST] <AppleTor> while on my mac it's just downloading smoothly. am i missing something? [16:41:53 CEST] <AppleTor> OUTPUT= MAC: https://pastebin.com/CVuTyMZT Ubuntu: https://pastebin.com/cAbmZ5z7 [16:44:13 CEST] <sfan5> wildly different ffmpeg version [16:45:03 CEST] <AppleTor> oh right, just noticed that [16:45:17 CEST] <AppleTor> but wait, the one on my mac is older right? [16:46:34 CEST] <sfan5> 2.8.1 is older than 4.0 yes [16:47:14 CEST] <AppleTor> so, should i downgrade the one on my ubuntu machine? [16:48:08 CEST] <sfan5> why do you even care about which things ffmpeg logs or doesn't [16:48:45 CEST] <AppleTor> wait, it's just loggin? [16:48:50 CEST] <sfan5> (the older version is still doing the exact same thing, but doesn't log each chunk) [16:49:17 CEST] <AppleTor> then why i'm seeing spike at my network traffic [16:49:23 CEST] <AppleTor> like it's downloading one chunk [16:49:48 CEST] <AppleTor> then stop, then starting to download another chunk and so on [16:49:54 CEST] <AppleTor> while on my mac, it's stable [16:50:19 CEST] <sfan5> ¯\_(Ä)_/¯ [19:25:51 CEST] <DanneDunder> Hey, I'm trying to decode some audio from a videofile, but when I send packet/receive frame I get two EAGAIN's and then a 'Resource temporarily unavailable' , does anyone know what could be wrong? [19:26:55 CEST] <DanneDunder> EAGAINS from avcodec_receive_frame and 'temp unavailable' from the avcodec_send_packet that is [19:28:17 CEST] <DanneDunder> It could be that I used the video decoder in receive .__: [19:29:55 CEST] <atomnuker> multiple EAGAINS are normal, just means you need to send it more packets [19:35:19 CEST] <DanneDunder> I had the audio_ctx in the send_packet and video_ctx in the receive [19:48:13 CEST] <dragmore88> anyone know why using this syntax: -map 0:a:0 -c:a aac -b:a 256k -y test1.ts i still get the 2 first audiotracks from a prores files? (i want the first one ) [19:48:31 CEST] <TheWild> hello [19:48:56 CEST] <ChocolateArmpits> dragmore88, audio tracks or audio channels? [19:48:57 CEST] <JEEB> dragmore88: that has only one map so it's somewhere else. or you are meaning audio channels and not streams [19:49:08 CEST] <dragmore88> yea.. i found another map that was redundant [19:49:20 CEST] <TheWild> surprised just realized today my DVB receiver/recorder records the audio and video... along with teletext streams :O [19:49:45 CEST] <dragmore88> prores file with 9 pcm "channels" wheres the 2 first are stereo and the last 7 are moni [19:49:47 CEST] <dragmore88> mono [19:50:07 CEST] <TheWild> I tried ffplay, but the video is overlayed with insanely-switching teletext pages. How to command ffmpeg to not display teletext? [19:50:35 CEST] <dragmore88> JEEB, know of any good guides to encode 5.1 AC3 from 6 mono channels in prores? [19:50:47 CEST] <dragmore88> cherrypicking, id and mapping ? [19:51:24 CEST] <JEEB> if it was 6 channels it wouldn't be a problem [19:51:27 CEST] <JEEB> you mean 6 mono streams [19:51:46 CEST] <JEEB> in which case you have to map them, and then use an audio filter to make 5.1 out of them [19:52:34 CEST] <TheWild> okay, disabling subtitles (-sn option) helped [19:53:00 CEST] <JEEB> dragmore88: see https://trac.ffmpeg.org/wiki/AudioChannelManipulation [19:53:21 CEST] <JEEB> it even has a 6xmono to 5.1 example [19:53:40 CEST] <dragmore88> JEEB,https://pastebin.com/uw3wCUS4 [19:53:53 CEST] <JEEB> yes, that's N streams [19:54:00 CEST] <JEEB> all mono except for the last [19:54:14 CEST] <JEEB> oh, and 0:1 and 0:2 are stereo as well :P [19:54:16 CEST] <dragmore88> first 2 are stereo [19:54:24 CEST] <dragmore88> thats what im using now for the aac target [19:54:31 CEST] <dragmore88> but i wanna create a 5.1 EAC3 track too [19:54:39 CEST] <JEEB> just see the example [19:54:45 CEST] <JEEB> I literally just linked you the trac wiki page [19:54:49 CEST] <dragmore88> i have no idea how the mapping is.. but the example is for external wave files [19:54:57 CEST] <dragmore88> i need to cherry pick from the prores file [19:55:07 CEST] <JEEB> it's the same thing. you map and then you set up the audio filter [19:55:28 CEST] <dragmore88> so -map 0:a:2 -> left etc.. ? [19:55:28 CEST] <JEEB> or I think you might not even need map [19:55:48 CEST] <JEEB> in filter_complex you can tell it to just use the mapping values with [] around them [19:55:56 CEST] <JEEB> [0:a:2]blah [19:55:58 CEST] <JEEB> for example [19:56:05 CEST] <dragmore88> ah, thx [19:56:08 CEST] <dragmore88> ill try later [19:56:58 CEST] <kepstin> then at the end of the filter, add a named pad like [out51] or something, then you can use 2 -map options: "-map 0:a:0 -map [out51]" to select both the stereo track and the filtered combined track. [19:57:02 CEST] <kepstin> if that's what you want to do [20:05:16 CEST] <TheWild> ffplay. How to display current frame number? [20:05:34 CEST] <JEEB> pretty sure you can't [20:05:43 CEST] <JEEB> unless you never seek :) [20:05:55 CEST] <TheWild> drawtext ... text=%{n} does that, but everytime I seek... yeah, JEEB [20:06:03 CEST] <TheWild> everytime I seek, the count is restarted [20:06:18 CEST] <TheWild> s**t, and I want to cut something at precise frames [20:06:19 CEST] <JEEB> yes, because exactly as I noted on #mpv [20:06:23 CEST] <JEEB> oh [20:06:25 CEST] <JEEB> you just want preview? [20:06:32 CEST] <JEEB> use vapoursynth editor and ffms2 [20:06:33 CEST] <JEEB> :P [20:06:38 CEST] <JEEB> that indexes your input [20:06:44 CEST] <JEEB> and you get frame-exactness [20:07:02 CEST] <JEEB> also vapoursynth scripts can of course be fed into an encoder then [20:07:58 CEST] <JEEB> frame-exact things generally require indexing, and while you can make that *with* FFmpeg (ffms2 does this), FFmpeg's APIs in general are all about A->B [20:08:36 CEST] <JEEB> basically ffms2 uses FFmpeg's APIs to once go through the whole input and generates an index on things. then it uses that for seeking etc [20:09:37 CEST] <TheWild> the video needs a TOC somewhat, since one frames require more data, other less. [20:10:03 CEST] <TheWild> and it's about seeking [20:10:33 CEST] <JEEB> but yea, vapoursynth editor + ffms2 as an input module for that [20:10:37 CEST] <JEEB> should give you what you want [20:11:17 CEST] <TheWild> so when I want to go to frame 152, it finds in the TOC which says "keyframe no is 146 and it's at offset 0x199CE4", or something like that [20:11:32 CEST] <JEEB> yes [20:11:36 CEST] <JEEB> ffms2 does that basically [20:11:56 CEST] <TheWild> okay, let's try vapoursynth + ffms2 then [20:11:59 CEST] <TheWild> thanks JEEB [20:13:20 CEST] <kepstin> yeah, the seek index included in files is normally a map from a timestamp to the location of a packet in the file for that timestamp, there's generally no record of frame numbers in the seek index [20:13:37 CEST] <kepstin> so you need to build an external index if you want that info. [20:14:13 CEST] <JEEB> well, the sample number is the thing you usually need, and then you have random access point flags in modern containers [20:14:29 CEST] <JEEB> but then the problem is that FFmpeg is not made to give that info to the API user [20:14:43 CEST] <JEEB> the API user just cares about A->B and seeking to a timestamp [20:14:56 CEST] <JEEB> or, well, that's the use cases [20:14:58 CEST] <JEEB> :) [20:15:03 CEST] <JEEB> (FFmpeg was designed for) [20:15:13 CEST] <kepstin> ffmpeg's time based seeking is (in most indexed formats) accurate enough to select a particular frame by timestamp/pts, if you know the timestamp somehow [20:15:34 CEST] <TheWild> I thought it's: I want to go to 42.5 second * 24 fps = frame no 1020 [20:15:34 CEST] <JEEB> and then it flies way out somewhere with stuff like MPEG-TS :) [20:15:48 CEST] <JEEB> quite often it's not 24 but 24000/1001 [20:15:56 CEST] <JEEB> but yes, if you have a constant frame [20:16:11 CEST] <JEEB> you do it generally in that way [20:16:13 CEST] <TheWild> but hmmm... as I seen one video changing it's resolution "at runtime" then frame rate might not be constant as well [20:16:40 CEST] <kepstin> pretty much all webcam and cell phone captured video is variable rate, for example (they run slower in lower light conditions, normally) [20:17:01 CEST] <kepstin> some newer phones might do better i suppose [20:17:27 CEST] <JEEB> and then there's the granularity of timestamps [20:17:40 CEST] <kepstin> mkv is fun, because it's normally used with a fixed 1ms timebase, so frame times are rounded rather than exact [20:17:41 CEST] <JEEB> some containers let you express the timestamps exactly [20:17:49 CEST] <JEEB> but then others don't [20:17:57 CEST] <JEEB> kepstin: actually you can bump that up, 1ms is just the default [20:18:06 CEST] <JEEB> so instead of 1000 you can have 10000 [20:18:18 CEST] <JEEB> (you can't have fractions though) [20:18:30 CEST] <kepstin> i've never seen any tools use something other than 1000, but yeah, I knew it supported changing to a different power of 10 [20:18:51 CEST] <JEEB> mkvtoolnix lets you pick it I think, but default is what you guess it is [20:19:44 CEST] <kepstin> i think the pts is a fixed length field? so increasing the timebase reduces the max video length [20:25:44 CEST] <JEEB> kepstin: that's true with almost any container :) [20:25:50 CEST] <JEEB> but I think the field's a 64bit int anyways [20:26:25 CEST] <kepstin> hmm, i thought it was 32, but when I tried looking it up, well, the mkv spec doesn't clearly say [20:26:33 CEST] <kepstin> maybe I'm just reading it wrong [20:27:56 CEST] <JEEB> it'd be surprising if any modern container was limited to 32bit, but of course that's possible [20:28:27 CEST] <JEEB> also the time base is in nanoseconds [20:28:35 CEST] <JEEB> so what you think of 1/1000 is actually 1000000 [20:30:19 CEST] <JEEB> ok, so you have cluster's timestamp, and then each cluster's packet has a relative timestamp to the cluster [20:32:01 CEST] <JEEB> kepstin: and yes the data size field is used to note how big the value is [20:32:59 CEST] <JEEB> and the spec even says at the beginning that both types of integers can be any size from 1 to 8 octets [20:33:02 CEST] <JEEB> https://matroska.org/technical/specs/index.html [20:35:10 CEST] <kepstin> hmm, yeah, the cluster stuff just says the timestamp is an 'unsigned integer', i guess that means it's a variable length encoding? [20:36:17 CEST] <JEEB> yes [20:36:20 CEST] <JEEB> that's what I was noting :) [20:36:38 CEST] <JEEB> ctrl+F "The known basic types are" [20:36:46 CEST] <JEEB> that lists unsigned integer as the second thing [20:36:55 CEST] <kepstin> the problem is that all of these matroska specs are defined assuming you know ebml [20:37:04 CEST] <kepstin> rather than just telling you what the binary format is like [20:37:12 CEST] <JEEB> yea [20:38:32 CEST] <kepstin> (has anything other than matroska ever even used ebml?) [20:58:02 CEST] <oliverdain> I'm trying to set crf and a preset in C code. I've tried av_dict_set(&opts, "preset", "medium", 0) with av_dict_set_int(&opts, "crf", 5, 0) before calling avcodec_open2 but that doesn't change anything - that is changing the values of those options doesn't change the resulting file at all [20:58:23 CEST] <oliverdain> I also tried av_opt_set on my context's priv_data both before and after the call to avcodec_open2 and that also has no effect. [20:58:35 CEST] <oliverdain> How is one supposed to set these options? [21:13:59 CEST] <oliverdain> So I checked what's in my AVDictionary after the call to avcodec_open2 and sure enough, preset and crf are in there as unrecognized options. But all the examples I see and the docs seem to indicate I can use them. [21:33:33 CEST] <oliverdain> I am soooooo confused. I see several official examples from ffmpeg project using preset but when I pass it to avcodec_open2 in the AVDictionary parameter it comes back as an unrecognized option. I'm not really doing anything unusual. Any help would be greatly appreciated. [21:33:51 CEST] <furq> oliverdain: you're using x264, right [21:34:22 CEST] <oliverdain> yes. I even have an assert(encoder->id == AV_CODEC_ID_H264) [21:34:35 CEST] <JEEB> no, that just makes sure you are getting H.264 [21:34:43 CEST] <JEEB> better get the encoder by name [21:34:45 CEST] <JEEB> if you want x264 [21:34:48 CEST] <JEEB> *libx264 [21:34:58 CEST] <oliverdain> and encoder is the AVCodec that I pass to avcodec_alloc_context3 [21:35:01 CEST] <JEEB> and yes, there are other H.264 encoder wrappers [21:35:05 CEST] <JEEB> in FFmpeg [21:35:20 CEST] <JEEB> that may or may not be enabled in your build [21:35:31 CEST] <oliverdain> JEEB: ahhh -- maybe that's it. We are, in fact, using libx264 on Linux but the native encoder on OSX. These tests were on OSX. [21:35:58 CEST] <furq> yeah videotoolbox probably doesn't have those options [21:36:00 CEST] <oliverdain> I didn't realize preset and crf are libx264 specific. the docs implied they were general H.264 options [21:36:24 CEST] <oliverdain> I see. thanks! [21:38:01 CEST] <oliverdain> will check encoder->name and set options accordingly. [21:54:24 CEST] <oliverdain> hmmm... It seems that videotoolbox doesn't have the equivalent of preset and crf. It doesn't seem to have many options at all. [21:54:24 CEST] <dreamon_> using to create jpgs out of a movie. ffmpeg -i file.mpg -r 1/1 $filename%03d.jpg [21:54:50 CEST] <dreamon_> my question. the quality is low. what can I do to make it better? [21:55:03 CEST] <dreamon_> movie plays good quality [21:58:47 CEST] <dreamon_> ah.. png pics are much better its a jpg thing [21:59:28 CEST] <JEEB> use the quantizer setting [21:59:39 CEST] <JEEB> to set how much it tries to compress the JPEG imag [21:59:47 CEST] <shfil> hi, I'm trying to replace deprecated codec with codecpar, but actually it (after second of play) crashes. It is code: https://github.com/rwengine/openrw/pull/420/commits/aae8f7adc5a49fd5c73e6c1… [22:01:01 CEST] <JEEB> shfil: I think I have done something similar with a quick look and it worked well except for my own fuck-ups by not handling memory management correctly [22:01:18 CEST] <JEEB> are you using the old or new decode api? [22:01:24 CEST] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [22:01:36 CEST] <JEEB> also using a debugger to get a backtrace is a Good Idea [22:01:45 CEST] <shfil> new [22:02:09 CEST] <JEEB> (--disable-stripping is btw the command to make the build system not strip things) [22:02:35 CEST] <dreamon_> JEEB, whats the right option for this? [22:02:48 CEST] <JEEB> in ffmpeg.c it's -q:v NUMBER [22:02:54 CEST] <JEEB> where NUMBER is a value you can play with [22:03:10 CEST] <shfil> asan says it crashes at line of reading from frame "int16_t sample = reinterpret_cast<int16_t *>(frame->data[channel])[i];" [22:05:02 CEST] <shfil> reading loop: https://github.com/ShFil119/openrw/blob/aae8f7adc5a49fd5c73e6c18411551d9c45… [22:05:34 CEST] <dreamon_> JEEB, Thank you, works great [22:19:44 CEST] <shfil> yeah, I've found guilty: "codecContext->request_sample_fmt = av_get_alt_sample_fmt(codecContext->sample_fmt, 0);" [22:20:06 CEST] <shfil> not sure why it causes crashing [22:20:41 CEST] <JEEB> http://www.ffmpeg.org/doxygen/trunk/group__lavu__sampfmts.html#ga8e66c3f813… [22:21:24 CEST] <shfil> ah, I get it, thanks. ;) [22:21:35 CEST] <JEEB> note: a useful thing to have in search bookmarks is `site:ffmpeg.org doxygen trunk KEYWORD` [22:21:54 CEST] <JEEB> trunk being current master, which is the latest state of how things are all going into Mars [22:22:04 CEST] <JEEB> and thus the documentation is most likely in the best shape there [22:25:18 CEST] <Lite> Hello! :D [22:25:36 CEST] <Lite> I [22:26:22 CEST] <Lite> I faced an issue here and need support... Could somebody help me here? [22:29:23 CEST] <Lite> Hello GrayShade [22:31:15 CEST] <Lite> Anybody? [22:31:57 CEST] <durandal_1707> do not ask to ask! [22:32:51 CEST] <Lite> I'm sorry, @durandal_1707. Just here first time. [22:33:21 CEST] <durandal_1707> Lite: so finnaly say what is your issue? [22:34:49 CEST] <Lite> Well, I faced an issue with my FFmpeg. At my Windows 10 Pro (64 bit). Immediately. I mean before some critical unknown event which became a reason of an issue, it worked fine there. [22:36:46 CEST] <Lite> 'What's exactly going on?' you will ask me - I will ansswer: it's pretty simple. It stucks and crashes during couple maybe a little bit more minutes after starting any task with "i" parameter [22:37:16 CEST] <Lite> At the same time, it's working fine other options. [22:38:34 CEST] <Lite> What I tried to do to solve this is deleting FFmpeg folder totally and reunpack actual version of FFmpeg nightly build. [22:38:47 CEST] <Lite> Nothing helps [22:40:50 CEST] <Lite> Today I started task with "i" parameter nad added also "-v 9 -loglevel 99" parameters. Multiplie times. And once it showed that: "Error in the pull function." Before that everything is fine. [22:41:25 CEST] <durandal_1707> give full uncut ffmpeg output and pastebin it and send link here [22:41:54 CEST] <Lite> can I do it via GoogleDrive? [22:42:42 CEST] <Lite> uncut you mean logfile with these "-v 9 -loglevel 99" parameters? or what exactly? [22:42:50 CEST] <durandal_1707> yes, even images if you do not know otherwise [22:43:09 CEST] <Lite> Ah ok great. fine. [22:43:13 CEST] <durandal_1707> Lite: output of ffmpeg command in terminal [22:43:36 CEST] <durandal_1707> with command itself [22:43:59 CEST] <Lite> ye ye [22:44:02 CEST] <Lite> I see [22:44:13 CEST] <Lite> I will come back in couple mins [23:00:05 CEST] <Lite> Well, sir @durandal_1707, here you go: HTTPS://Drive.Google.Com:443/uc?id=1h6CyKvQ25ztx9FNo7YBqH-vUyHm4bEt- [23:00:25 CEST] <Lite> Hope that screenshot is exactly what you requested [23:03:23 CEST] <Lite> Here at my PC installed, if we talking about codecs, - except K-Lite Codec Pack Mega - XViD codec and DivX Pro Pack [23:04:16 CEST] <sfan5> protip: you don't need codecs packs in 2018 [23:04:18 CEST] <Lite> What I know about that this issue is my OS issue. Not input URL I'm trying to download issue. [23:04:35 CEST] <Lite> @protip :O [23:04:44 CEST] <kepstin> hmm, a tls error. probably something going wrong with the schannel stuff. [23:04:59 CEST] <Lite> channel? [23:05:25 CEST] <Lite> HTTPS://Drive.Google.Com:443/uc?id=1h6CyKvQ25ztx9FNo7YBqH-vUyHm4bEt- you found that here is TLS error?? [23:05:27 CEST] <kepstin> this ffmpeg should work fine with local sources, but something is going wrong with trying to read from https [23:06:11 CEST] <Lite> wait a sec... [23:06:13 CEST] <Lite> TLS.. [23:07:45 CEST] <kepstin> (as a side note, why are you transcoding the stream to lossless h264 rather than just saving it to disk with -c:v copy?) [23:08:17 CEST] <kepstin> the output file would be huge, and with -preset placebo it might be too slow for realtime streaming, too [23:08:45 CEST] <furq> that command is using -c copy [23:09:04 CEST] <Lite> ah, it's just copied string from notes. It is anyway savings as c:v without additional parameters [23:09:06 CEST] <kepstin> ... oh, so it is [23:09:14 CEST] <furq> with that said i don't know why you wouldn't just download the file [23:09:19 CEST] <kepstin> missed that. the extra parameters there are just being ignored. [23:09:26 CEST] <furq> oh nvm it's an m3u8 [23:10:25 CEST] <kepstin> Lite: which ffmpeg build is this? zeranoe? [23:11:07 CEST] <furq> anyway yeah this isn't the full output [23:11:10 CEST] <Lite> @kepstin, downloaded it today. But it's working fine on another Windows 10 device. [23:11:13 CEST] <furq> pastebin the output file that -report generated [23:11:24 CEST] <Lite> And should work same way on mine [23:12:30 CEST] <Lite> Maybe you could advise me which Windows parameters should I check and where? [23:13:08 CEST] <Lite> Maybe some service switched off as soon as should be swithed on or so... [23:14:03 CEST] <Lite> I also tried to give admins right to FFmpeg.exe. Not sure that helped too. [23:14:54 CEST] <kepstin> Lite: it could be something like missing tls certificates, or something akamai has done on their end. can't really tell without more debugging. [23:15:53 CEST] <Lite> If the issue doesn't depends on version of FFmpeg (I could totally delete this and install any other - it will be same) , so that's some Windows OS issue [23:17:08 CEST] <Lite> Are you sure codecs not the reason of the issue? [23:17:52 CEST] <Lite> Because when I'm updating K-Lite. It requests me it doesn't like some DivX and XViD codecs... [23:18:14 CEST] <kepstin> Lite: nothing to do with system codecs. ffmpeg does not use system codecs [23:18:33 CEST] <postmodern> hello, i'm trying to run two video inputs through hstack and then stereo3d, however i'm noticing after 10 minutes one of the video inputs becomes de-synced with the other. I've verified that this is not an issue with the inputs, as I can ffplay them both and not observe any de-sync over time. How would I get started debugging this problem? [23:18:40 CEST] <kepstin> Lite: maybe give ffmpeg 3.4.2 a try. it uses gnutls rather than schannel, so it might behave differently. https://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-3.4.2-win64-static.zip [23:19:35 CEST] <Lite> OK I will try it as an experiment. Will come back in couple mins [23:21:19 CEST] <Lite> Actually this situation looks almost like an issue when you staring some process (.Exe) and it stucks at Tasks manager with 0% of usage... Maybe because of antivirus software or so... [23:21:30 CEST] <Lite> Have no antivirus software for now [23:21:42 CEST] <Lite> And already for along time [23:23:00 CEST] <rjp421> can i turn a 5sec mp4 into a loop 5min long? [23:23:15 CEST] <furq> sure [23:24:30 CEST] <furq> for i in {1..60}; do printf "file %q\n" foo.mp4; done | ffmpeg -f concat -protocol_whitelist file,pipe -safe 0 -i - -c copy bar.mp4 [23:25:04 CEST] <rjp421> ty [23:27:02 CEST] <rjp421> worked, neat [23:29:10 CEST] <GrayShade> Lite: can you paste that command line here? [23:29:31 CEST] <Lite> cmd? [23:29:40 CEST] <Lite> what do you mean? [23:29:56 CEST] <Lite> is PowerShell so much bad? [23:30:09 CEST] <GrayShade> no, the command you're running, with the URL and all that [23:30:24 CEST] <GrayShade> I just wanted to try it, though I'm not on Windows and I don't have the same ffmpeg version as you [23:32:18 CEST] <Lite> No-no. That will be useless. Told before already: downloaded it today. But it's working fine on another Windows 10 device. [23:36:38 CEST] <Lite> Wow [23:36:59 CEST] <Lite> 3.4.2 works perfect [23:37:39 CEST] <Lite> BUT I always used before faced that issue nightly builds [23:38:46 CEST] <GrayShade> where did you get the other version from? [23:38:47 CEST] <Lite> And continue using (totally successfully on another device), same OS [23:39:00 CEST] <Lite> from here lol [23:39:07 CEST] <GrayShade> the one that doesn't work [23:39:29 CEST] <Lite> kepstin messaged [23:39:42 CEST] <GrayShade> not 3.4.2, the one you tried and didn't work [23:40:06 CEST] <Lite> ah [23:40:07 CEST] <Lite> se [23:40:09 CEST] <Lite> sec [23:40:21 CEST] <GrayShade> kepstin: do you know if gnutls is linked statically or not? [23:40:25 CEST] <kepstin> GrayShade: i suspect it was just a zeranoe nightly? [23:40:45 CEST] <kepstin> GrayShade: in static builds, it would be linked statically. [23:41:15 CEST] <GrayShade> um. do you know if Windows ffmpeg builds are usually statically linked? [23:41:25 CEST] <Lite> https://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-20180426-8ea8be5-win6… [23:41:32 CEST] <Lite> from here [23:43:27 CEST] <kepstin> GrayShade: most people get their windows builds from zeranoe, and the default download link there is the static build [23:43:50 CEST] <kepstin> well, I say "most", but i don't know if that's actually true. Certainly many people do :) [23:43:53 CEST] <Lite> Moreover, when these nitghtly build worked on that machine fine (before some critical unknown event which became a reason of an issue - as I already told), I downloaded all versions I mean static, shared and dev [23:44:30 CEST] <Lite> And unpcaked them at FFMPEG folder step by step: static-shared-dev, exchanging files [23:44:47 CEST] <kepstin> anyways, at some point fairly recently, it looks like zeranoe's builds switched from using statically linked gnutls to using windows built-in schannel support [23:45:06 CEST] <kepstin> which in at least this one case appears to be problematic? [23:45:30 CEST] <Lite> Still interested in finding and fixing a reason why they stopped working at this machine. Maybe I did anything wrong. Dunno. But need to fix that [23:45:30 CEST] <kepstin> it would be nice to see if someone else could reproduce this problem on a different system, I suppose. [23:45:33 CEST] <GrayShade> but.. "error in the pull function" seems to be a gnutls error message [23:45:52 CEST] <GrayShade> kepstin: I was wondering if it wasn't loading a random gnutls from PATH [23:46:01 CEST] <kepstin> oh, i'm wrong [23:46:07 CEST] <kepstin> looked in the wrong place at the readme [23:46:11 CEST] <kepstin> it is still using gnutls [23:46:22 CEST] <GrayShade> (which might explain it working on another computer) [23:46:26 CEST] <Lite> So, stable 3.4.2 works - nightly stopped working with only "i" parameter [23:46:41 CEST] <Lite> What is it talking about? [23:46:49 CEST] <kepstin> the statically linked builds won't ever use gnutls from somewhere else on the system [23:46:52 CEST] <kepstin> so that's not the problem [23:46:56 CEST] <Lite> Is it helps to find real reason? [23:47:06 CEST] <kepstin> i wonder if the gnutls version used in the builds changed [23:47:22 CEST] <GrayShade> yeah, that's why I asked how it's usually linked [23:47:53 CEST] <kepstin> hmm, no, latest nightly and 3.4.2 zeranoe readmes both list gnutls 3.5.18 [23:49:06 CEST] <GrayShade> oh, and shared builds still have static gnutls [23:49:35 CEST] <GrayShade> welp, no idea (: [23:49:58 CEST] <Lite> Wait, let's back to TLS. Who suggested it's TLS issue and why? [23:50:44 CEST] <GrayShade> Lite: the error comes from the TLS client used by ffmpeg to connect to https URLs [23:50:57 CEST] <Lite> As I understand if it was any codecs issue it wasn't going to work (going to fail with all other parameters - not only "i") [23:51:07 CEST] <Lite> So codecs issue excluded [23:51:09 CEST] <GrayShade> TLS is the S in HTTPS [23:51:23 CEST] <GrayShade> it would work with local files or HTTP [23:51:57 CEST] <Lite> Can you find me some m3u working URL without HTTP to test it? [23:51:59 CEST] <Lite> :D [23:52:01 CEST] <Lite> please [23:53:45 CEST] <Lite> Ah, I will come back in couple mins. need to check something [23:54:39 CEST] <GrayShade> http://hcmaslov.d-real.sci-nnov.ru/public/mp3/Queen/ [23:54:42 CEST] <GrayShade> pick one from there [23:55:12 CEST] <GrayShade> and one from here https://www.mfiles.co.uk/mp3-files.htm [23:58:19 CEST] <Lite> I remember my last nightly build worked without issues in november-december 2017 last time [23:58:37 CEST] <Lite> ans in ~december it stopped working [23:59:44 CEST] <Lite> I see I installed Charles 4.3b2 25.12.2017 [23:59:51 CEST] <GrayShade> Well, it might be worth testing the older nightlies to see where exactly thks [23:59:58 CEST] <Lite> Charles is something like Wireshark and Fiddler [00:00:00 CEST] --- Fri Apr 27 2018

1 0

ffmpeg-devel.log.20180425
by burek 26 Apr '18

26 Apr '18

[02:34:47 CEST] <Chloe> tmm1: JEEB says you did a teletext thing [02:42:22 CEST] <Mina> Hi, I've been accepted into GSoC to work on a project idea I've proposed which was the color constancy filter. I'm ready to start with my plan but thought to come and ask if there's anything I should know or share before starting. [02:49:03 CEST] <tmm1> Chloe: yea, for subtitles [02:49:17 CEST] <tmm1> its not great but mostly works [02:49:37 CEST] <tmm1> i can submit if interested [02:52:43 CEST] <klaxa> Mina: hey, yeah i don't think there is much to do right now, lurking the channel and reading what other people have to say is a good and interesting passtime at least [02:54:53 CEST] <tmm1> Chloe: https://github.com/tmm1/ffmpeg/commit/telx-subs [02:55:19 CEST] <Mina> klaxa: I will be delighted to chat and get to know new people. Nevertheless, the topic I am working on is not a new topic for me so I am ready to start implementing. [02:55:50 CEST] <klaxa> heh, well gotta hold off on that for now i think [02:57:27 CEST] <Mina> Guess I'll just implement some basic filters as showcases. Anyway, what project are you working on. I think I saw your name on GSoC. [02:58:54 CEST] <Mina> Just received the mail, ffserver then? [02:59:01 CEST] <klaxa> yeah [02:59:26 CEST] <Mina> Would you like to tell me more about it? [02:59:59 CEST] <klaxa> well, i basically wanted to do something like this since 2012, back then i already kinda knew it must be possible [03:00:06 CEST] <klaxa> to stream matroska with subtitles i mean [03:00:10 CEST] <klaxa> that was my original goal [03:00:38 CEST] <klaxa> started to experiment with some python stuff, didn't work out, tried to learn libav*, phew went pretty much over my head [03:01:08 CEST] <klaxa> in gsoc 2015 i wrote (the much debated) http server in lavf [03:01:27 CEST] <klaxa> then i started using it for my own project to finally do what i wanted to do since 2012, stream matroska with subs [03:02:03 CEST] <klaxa> now it's becoming the replacement for ffserver which was recently dropped [03:03:21 CEST] <klaxa> in gsoc 2015 i tried to replace some of the http usage of the old ffserver with the new api [03:03:37 CEST] <klaxa> but wow, that was much harder and much more than i thought [03:04:41 CEST] <Mina> Trying to catch up xD [03:05:53 CEST] <Mina> First, that sounds really interesting that you've been tackling this for these years. [03:06:00 CEST] <Mina> But why is it that hard? [03:06:13 CEST] <Mina> And debated. [03:07:10 CEST] <klaxa> it's debated because people disagree about whether libavformat should even have an http server [03:07:31 CEST] <atomnuker> tmm1: doesn't look horrible, would be useful too [03:07:46 CEST] <atomnuker> because libzvbi has never worked for me [03:07:51 CEST] <klaxa> when i applied for that in 2015 i didn't know how divided people were on it [03:08:12 CEST] <atomnuker> (on the few mpegts streams I had and tested it with) [03:08:45 CEST] <atomnuker> decoding it to ass is hardcore [03:08:59 CEST] <klaxa> well it took some time to learn how video files and libav* work and i only worked on it whenever i felt like it, became more with time [03:09:37 CEST] <klaxa> and it is actually not too hard if you look under the hood, just took some time figuring out how to do it properly [03:10:00 CEST] <klaxa> that makes me even more puzzled as to why there is not a single software that allows you to live stream matroska [03:10:03 CEST] <klaxa> i have not seen one [03:10:07 CEST] <klaxa> in all these years [03:10:11 CEST] <Mina> Okay, so I think you found a better way to do it -which you are going to implement this year-? [03:11:00 CEST] <klaxa> well i wish to find out in the next few days or so? that's why i wrote to the ML, getting more expert opinions before making uninformed decisions [03:11:20 CEST] <Mina> Alternatives are? [03:11:47 CEST] <klaxa> libmicrohttpd was suggested and writing an nginx module [03:11:50 CEST] <tmm1> atomnuker: i'm only decoding subtitle pages which come in as mostly text [03:13:18 CEST] <klaxa> a somewhat middle way might really be writing the server code as a library and making writing an nginx module trivial [03:13:31 CEST] <Mina> Wished I could help but actually I don't have a clear idea. [03:14:20 CEST] <klaxa> np, neither have i at the time :) [03:14:36 CEST] <Mina> What's special with matroska? [03:15:05 CEST] <klaxa> it supports more things than mp4 [03:15:10 CEST] <klaxa> for example styled subtitles [03:15:15 CEST] <klaxa> or reading partial files [03:16:52 CEST] <klaxa> you could have a live stream with multiple language subtitles in the same stream! [03:17:00 CEST] <klaxa> no need to download some other file or something [03:18:24 CEST] <atomnuker> tmm1: that's okay, most of teletext is text [03:18:31 CEST] <Mina> Looks cool. [03:25:23 CEST] <Mina> I guess I will leave now and come back later. Bye [03:26:46 CEST] <klaxa> that was quick :P [03:27:25 CEST] <Mina> hah xD I run in C [08:15:36 CEST] <dagb> seeing how aptx got merged to ffmpeg.... how about LDAC? git clone https://android.googlesource.com/platform/external/libldac apache license. [09:03:24 CEST] <rcombs> what do people use aptx in ffmpeg for anyway [09:03:49 CEST] <rcombs> like, not saying LDAC necessarily shouldn't be added, just wondering what you'd use it for [09:09:16 CEST] <dagb> rcombs: I agree it is an odd thing to add to ffmpeg. But stuff like bluez-alsa can link to ffmpeg, in order to de-/encode these formats. [09:09:40 CEST] <rcombs> ahhhhhh [09:09:55 CEST] <rcombs> welp patchwelcome then I'd imagine [09:10:23 CEST] <dagb> having standalone codec libraries would remove the dependency on both pulseaudio and ffmpeg, which would make for a very slim and capable bluetooth audio support in linux. [09:19:09 CEST] <Chloe> tmm1: what's missing from it? [09:29:04 CEST] <Chloe> tmm1: it looks ok, better than zvbi at least [11:50:49 CEST] <ubitux> durandal_1707: for what options? the strength? or the patch sizes? [11:52:35 CEST] <durandal_1707> both, but mostly strength [11:58:58 CEST] <ubitux> i don't think it's a problem but i need to check the patch itself [12:00:57 CEST] <durandal_1707> ubitux: i have sample that give different output with fieldmatch,decimate and vapoursynth one, and its decimate filter that is causing it [12:39:30 CEST] <cone-621> ffmpeg 03Paul B Mahol 07master:0b360cae1cb7: make swresample optional for ffmpeg [13:07:27 CEST] <ubitux> durandal_1707: iirc the decimate picking logic is slightly different due to design differences [13:07:49 CEST] <ubitux> is it behaving badly? [13:08:05 CEST] <ubitux> also note the filter probably needs some adjustments since when they were introduced [13:08:17 CEST] <ubitux> i haven't tracked the changes upstream [13:08:23 CEST] <durandal_1707> it appears, it drops different frames [13:08:39 CEST] <ubitux> but are they duplicated frames? [13:08:43 CEST] <durandal_1707> nope [13:08:58 CEST] <ubitux> that's unfortunate then, patch welcome [13:08:58 CEST] <durandal_1707> it is some strange sample i have [13:09:22 CEST] <durandal_1707> the VDecimate also drops non dupe frames... [13:15:15 CEST] <ubitux> there is a drop ratio [13:15:25 CEST] <ubitux> so the filter actually has to drop something [13:15:30 CEST] <durandal_1707> yes [13:15:43 CEST] <ubitux> if there is no duplicate it will pick close one [13:15:52 CEST] <durandal_1707> agree [13:16:11 CEST] <durandal_1707> maybe sample is invalid.. [14:09:52 CEST] <cone-621> ffmpeg 03Paul B Mahol 07master:a12899ad9b4d: avfiler/vf_mix: fix crash with >8 bit depth [15:32:43 CEST] <durandal_1707> ubitux: why nlmeans does not work with rgb formats? [15:34:15 CEST] <ubitux> no particular reason i suppose [15:36:57 CEST] <durandal_1707> actually it have gbrp already [16:08:44 CEST] <jamrial> atomnuker: can you answer Thomas' question about mbedTLS so we can get that moving? [16:10:25 CEST] <jamrial> otherwise i'll tell him to push it since there are seemingly no other objections [16:28:21 CEST] <durandal_1707> it is comming to libav, just wait for merge [16:39:07 CEST] <durandal_1707> who is writing av1 decoder for lavc? [17:05:36 CEST] <atomnuker> durandal_1707: ...me [17:07:51 CEST] <atomnuker> and BBB if he manages to negociate with j-b once the codec is complete [17:10:37 CEST] <atomnuker> I really wish I knew when the bitstream freeze will happen [17:10:59 CEST] <atomnuker> I know that the spec will be finalized 100 days or so after that happens [17:11:25 CEST] <atomnuker> since it'll take the company doing the spec verification that long to make synthetic bitstreams and a decoder completely from the spec [17:11:53 CEST] <atomnuker> I was hoping the bitstream would be frozen yesterday but no, ext_tile had to have some changes [17:12:52 CEST] <atomnuker> which were apparently in conflict with what the experiment was adopted with (no bitstream changes, but now they want to add some signalling) [17:35:11 CEST] <jamrial> durandal_1707: no, it's proper to apply it the way it was made for ffmpeg by its author [18:08:32 CEST] <jamrial> durandal_1707: http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-disableswresam… [18:23:34 CEST] <tmm1> Chloe: whats wrong with zvbi? (i've never used it) [18:25:52 CEST] <durandal_1707> jamrial: looks like aresample filter is dependency of bunch of tests [18:26:15 CEST] <atomnuker> jamrial: replied [18:34:22 CEST] <cone-621> ffmpeg 03Paul B Mahol 07master:b2570afde362: avformat/yuv4mpegdec: fix seeking backwards [18:49:06 CEST] <durandal_1707> jamrial: that fate box is strange, it use avresample instead [18:49:38 CEST] <jamrial> durandal_1707: avresample is always enabled in builds made by tests/fate.sh [18:51:10 CEST] <jamrial> just to make sure it builds, afaik [18:51:39 CEST] <jamrial> since ffmpeg uses swr only, avr is not really used at all even if enabled (unless you invoke the relevant audio filter, which no test does) [18:52:39 CEST] <jamrial> in any case, disabling swr evidently makes ffmpeg cli a lot less useful. same as disabling sws as seen in http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-disableswscale [18:56:15 CEST] <durandal_1707> jamrial: is this new box or we had this box run disabling swresample, which was enabled later anyway? [18:56:47 CEST] <jamrial> durandal_1707: it's old, you can see the run history [18:57:38 CEST] <jamrial> before your patch removing swr dependency to ffmpeg, a build without swr would just run 321 or so non-ffmpeg based tests [18:59:19 CEST] <durandal_1707> so i need to add 424 aresample checks to those tests :) [19:04:17 CEST] <durandal_1707> 424 more commits to my stats? :) [19:05:38 CEST] <atomnuker> or just have 1 fixing tests/fate.sh [19:33:17 CEST] <jamrial> durandal_1707: adding aresample as a dep to the relevant tests would be a solution, yeah, but probably end up looking way too ugly [19:34:02 CEST] <durandal_1707> jamrial: i dont get it, lavf-sox is used by that box but if swresample is disabled, how it managed to convert s16 to s32? [19:35:13 CEST] <durandal_1707> it would not run any tests because ffmpeg would not exist.... [19:35:18 CEST] <jamrial> it didn't. fate-lavf-sox failed with a "'aresample' filter not present, cannot convert audio formats." error [19:35:49 CEST] <durandal_1707> previously i mean.. [19:36:11 CEST] <jamrial> previously, lavf-sox wasn't run [19:36:19 CEST] <jamrial> no ffmpeg cli based test did [19:36:34 CEST] <jamrial> because ffmpeg was disabled [19:37:06 CEST] <durandal_1707> well, tests should be run if it they do not need aresample [19:42:42 CEST] <jamrial> if you can find a non ugly way to add aresample as dep for these 424 tests, then that'd be great :p [19:54:34 CEST] <cone-621> ffmpeg 03Aman Gupta 07master:6a7a84b2d11e: avcodec/mediacodecdec: clarify delay_flush specific code [19:54:35 CEST] <cone-621> ffmpeg 03Aman Gupta 07master:7a4639b1eba3: avcodec/mediacodecdec: use AV_TIME_BASE_Q [19:54:36 CEST] <cone-621> ffmpeg 03Aman Gupta 07master:d8e92a89edd8: avcodec/mediacodecdec: refactor pts handling [19:58:31 CEST] <durandal_1707> jamrial: what means non ugly? [19:59:11 CEST] <nevcairiel> preferably without changing 424 places [19:59:23 CEST] <jamrial> adding aresample to most of these would require to do things like changing a lot of DEMDEC macro usage to ALLYES [19:59:59 CEST] <jamrial> although i see now there's a FILTERDEMDEC macro, so maybe not /that/ ugly [20:00:07 CEST] <jamrial> but yeah, what nevcairiel said still applies [20:01:15 CEST] <durandal_1707> i disagree, all 424 places should be changed [21:00:38 CEST] <atomnuker> well, if they were changed now they'd have to be changed again in less than 2 years once avresample is gone [21:03:01 CEST] <jamrial> this has nothing to do with avresample [21:04:00 CEST] <jamrial> swresample disabled -> aresample_filter disabled -> plenty of tests that need resampling fail [21:04:01 CEST] <jamrial> just that [21:18:40 CEST] <atomnuker> oh, right, yeah [21:18:53 CEST] <atomnuker> makes sense all of them to depend on aresample [21:19:16 CEST] <atomnuker> even if it means changing it in 424 places, IMO the tests shouldn't rely on default behaviour [21:35:58 CEST] <kierank> durandal_1707: to answer your prores12 bit question, afaik the idct just truncates values to 10-bit [21:36:08 CEST] <kierank> the spec might explain how to actually signal 12-bit output [21:49:16 CEST] <kierank> it might reduce precision of coefficients, can't remember prores idct was a bit odd [21:50:27 CEST] <durandal_1707> kierank: only 16bit alpha is scaled to 10bit [21:50:33 CEST] <cone-621> ffmpeg 03James Almer 07master:bd90a2ec04d7: avcodec/mpeg4_unpack_bframes: cache input packets directly [21:50:34 CEST] <cone-621> ffmpeg 03James Almer 07master:0161d91db01a: avcodec/cbs_mpeg2: use memcpy when assembling fragments [21:50:58 CEST] <kierank> durandal_1707: ? [21:51:04 CEST] <kierank> there isn't a 12-bit pixel format [21:53:30 CEST] <kierank> in prores at least no mention [21:53:55 CEST] <durandal_1707> mention of what? [21:54:41 CEST] <durandal_1707> also how I can check that extra 2 bits are really correct and not just noise? [21:54:57 CEST] <kierank> The IDCT follows the conventions [21:54:57 CEST] <kierank> of IEEE Std 1180-1990, specifically the expectation that the DCT coefficients have the [21:54:57 CEST] <kierank> range of 12-bit signed integers while the reconstructed values have the range of 9-bit signed [21:54:57 CEST] <kierank> integers. [21:56:15 CEST] <kierank> seems like you don't know [21:57:30 CEST] <kierank> there's a reference decoder [21:58:03 CEST] <durandal_1707> on windows? it can export to 16bit formats? [22:04:12 CEST] <kierank> durandal_1707: so what you should do is make everything 12-bit [22:04:15 CEST] <kierank> imo [22:12:25 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:5e5c9f1804bf: avcodec/vc1: re-implement and expand VC-1 overlap smoothing [22:12:26 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:20de893b3bb4: avcodec/vc1: change to using v->block instead of s->block for P frames [22:12:27 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:ded52f6e36c5: avcodec/vc1: re-implement and expand VC-1 loop filtering [22:12:28 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:c5f74b1e232c: avcodec/vc1: store additional bitstream elements during MB decoding [22:12:29 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:79f8074cc405: avcodec/vc1: store color-difference reference field type [22:12:30 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:dd1e717f5b79: avcodec/vc1: correct ff_vc1_mbmode_intfrp [22:12:31 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:b43f1c522572: avcodec/vc1: correct ff_vc1_dqscale [22:12:32 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:362ce2db4bbc: avcodec/vc1: implement interlaced out-of-bounds reference pixel replication [22:12:33 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:e60e14ef929f: avcodec/vc1: re-implement vc1_put_signed_blocks_clamped [22:12:34 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:cc5deeb74a34: avcodec/vc1: add overlap smooting and loop filter for frame/field-interlace [22:12:35 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:7a70879624a0: avcodec/vc1: remove unused overlap smooting and loop filter [22:12:36 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:a1dc0bdaf494: avcodec/vc1: correct mspel for field-interlace B frames [22:12:37 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:797c1536a46e: avcodec/vc1: correct AC inverse quantization scaling [22:12:38 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:9ae2845b1c0a: avcodec/vc1: correct forgotten v->blocks_off [22:12:39 CEST] <cone-621> ffmpeg 03Jerome Borsboom 07master:144ce364cd2d: avcodec/vc1: more corrections for AC inverse quantization scaling [22:31:50 CEST] <nevcairiel> yay for vc1? [22:32:00 CEST] <nevcairiel> now if someone would also make it properly fast, i could drop the MS decoder :p [22:36:30 CEST] <durandal_1707> the bitstream decoding is very connected with pure frame reconstruction, so it will need heavy refactoring [22:37:08 CEST] <durandal_1707> to support possible? threaded slice decoding [22:39:08 CEST] <TD-Linux> you only need those to be separate if the final state of bitstream decoding affects future frames / slices (as in vp9) [23:12:56 CEST] <cone-621> ffmpeg 03Michael Niedermayer 07master:0bd0401336df: avcodec/elsdec: Fix memleaks [23:12:57 CEST] <cone-621> ffmpeg 03Michael Niedermayer 07master:7562567f41aa: avcodec/h2645_parse: Replace RNXYA by RNXY in ff_h2645_extract_rbsp() [23:12:58 CEST] <cone-621> ffmpeg 03Michael Niedermayer 07master:de841fbea765: avcodec/h263dec: Check slice_ret in mspeg4 slice loop [23:12:59 CEST] <cone-621> ffmpeg 03Michael Niedermayer 07master:1c97035e3b16: avcodec/error_resilience: Fix integer overflow in filter181() [23:43:24 CEST] <nevcairiel> the gcc status report mails are always rather disconcerning [23:43:34 CEST] <nevcairiel> oh hi we reached < 100 important regressions, we can totally release now [23:43:57 CEST] <nevcairiel> 93 important regressions is still a lot of regressions folks! [23:46:54 CEST] <wm4> just declare it UB by the applications after some standards lawyering [23:52:30 CEST] <atomnuker> that radio canada rfc4175 guy doesn't seem to test his patches at all [23:52:47 CEST] <atomnuker> that last version he submitted leaked every frame [23:53:32 CEST] <atomnuker> and for the version before that he unref'd the just allocated frame and then ref'd the existing top+bottom one [23:54:20 CEST] <jamrial> atomnuker: non important regressions are many times ICEs or wrong assembly when trying to compile invalid code, just to give you an example [23:54:55 CEST] <nevcairiel> i think you got confuzzled there [23:55:14 CEST] <nevcairiel> and i'm not even talking about the "non-important" ones, there is like 200 more of those [23:55:34 CEST] <jamrial> oh, <100 important [23:55:38 CEST] <jamrial> yeah, that does sound kinda bad [23:55:50 CEST] <nevcairiel> its about normal for their status reports tho [23:56:13 CEST] <nevcairiel> gcc 7.3 had 186 still open [23:56:28 CEST] <nevcairiel> a number that actually grew from 7.2 [23:56:33 CEST] <nevcairiel> more got reported then fixed [23:56:56 CEST] <nevcairiel> so who knows how to properly classify that [23:57:08 CEST] <atomnuker> jamrial: did you mean to ping nevcairiel? [23:57:19 CEST] <nevcairiel> it just sounds very odd if they call those "important" and then have such high numbers [23:57:26 CEST] <jamrial> atomnuker: yeah, sorry [23:57:27 CEST] <nevcairiel> the "critical" ones they try to keep at zero at least [23:58:10 CEST] <jamrial> critical ones are "linux kernel and chromium don't compile" :p [00:00:00 CEST] --- Thu Apr 26 2018

1 0

ffmpeg.log.20180425
by burek 26 Apr '18

26 Apr '18

[00:18:37 CEST] <c_14> can't you use avcodec_descriptor_get_by_name or something? [00:18:57 CEST] <c_14> ar avcodec_descriptor_get [00:19:24 CEST] <c_14> Those'll return the descriptor without having to open the codec [00:22:56 CEST] <c_14> oliverdain: ^ [00:30:32 CEST] <oliverdain> avcodec_descriptor_get: yup, had just found that and got it working. Thanks c_14!! [01:52:04 CEST] <frecklealex> Hey folks. Question: I have a 16Mbps bitrate mp4 file which I input into ffmpeg with `ffmpeg -i start.mp4 finish.mp4` and it seems like the final bitrate is somewhere around 800Kbps. What is ffmpeg's default behavior? Does it figure out an optimal bitrate for me, ending up with that final number? [01:53:57 CEST] <frecklealex> I couldn't find the default behavior in the docs, so asking here now. [01:55:20 CEST] <klaxa> it picks some "sane" defaults [01:55:21 CEST] <atomnuker> no, you need to set the bitrate and all settings yourself, this is just the defaults [01:55:30 CEST] <furq> the default behaviour with mp4 is x264 at crf 23 [01:56:02 CEST] <furq> which i'd probably describe as "generally fine" [01:56:03 CEST] <furq> but not really good [02:04:06 CEST] <frecklealex> "not really good" in terms of final quality, or what specifically? I'm unfortunately not super familiar with this space, so might be asking something really obvious. [02:05:48 CEST] <klaxa> just run ffmpeg -i start.mp4 -t 10 finish.mp4 and see for yourself [02:05:54 CEST] <klaxa> that'll encode the first 10 seconds [02:06:24 CEST] <klaxa> if you want to use a short segment from somewhere else use: ffmpeg -i start.mp4 -ss 1:20 -t 10 finish.mp4 [02:06:40 CEST] <klaxa> that'll use 10 seconds at ~1 minute and 20 seconds [02:06:59 CEST] <klaxa> and yes, in terms of final quality [02:07:26 CEST] <klaxa> if you look for it you will most likely be able to see that some parts of the encode show artifacts (parts that look "wrong") [02:07:50 CEST] <klaxa> if you increase the quality they will start to become less visible [02:08:36 CEST] <klaxa> increasing the quality means decreasing the crf value, so: ffmpeg -i start.mp4 -crf 20 finish.mp4 would be better than the default quality [02:18:08 CEST] <frecklealex> Gotcha, thanks for explaining. Our videos are mostly static frames being show on the screen for 5-10 seconds, very little movement with exception for fade in and out, so I've perceived no reduction in quality. [02:19:39 CEST] <frecklealex> Basically a powerpoint that ended up in an mp4 [02:19:43 CEST] <klaxa> yeah those are pretty "easy" to code, iirc x264 even has a tune setting for still frames [02:20:02 CEST] <klaxa> my uni made me doe something similar... [02:20:17 CEST] <klaxa> audio + slides as jpeg with timecodes in custom .ogg [02:20:35 CEST] <klaxa> converted that to mkv x264 with chapters [02:23:12 CEST] <frecklealex> Heh sounds clever. I've realized that our "slideshows" were starting off as these giant 300MB files because of folks setting the bitrate as high as they could [02:23:25 CEST] <frecklealex> Even Cloudinary was saying "Yeah.. I'm not accepting files that large" [02:24:50 CEST] <klaxa> well they had to ship their own java player for playback [02:25:00 CEST] <klaxa> and i don't like java poisoning my computers [02:25:10 CEST] <klaxa> they made the spec open, but their lib closed [02:28:32 CEST] <klaxa> not really the way to go as a university imo, but whatever [02:28:43 CEST] <klaxa> i think they moved to something "html5-compatible" now [02:28:54 CEST] <klaxa> gotta support those iphones [02:40:03 CEST] <furq> frecklealex: you probably want to check out -tune stillimage and maybe lower the framerate [02:40:24 CEST] <furq> but preset and crf are the two most important x264 settings [02:41:00 CEST] <furq> it's generally worth spending some time tooling around with those and seeing what kind of results you get [02:42:24 CEST] <frecklealex> furq: thanks for that, will check it out [05:24:08 CEST] <stephen> What up folks [05:24:39 CEST] <stephen> Anyone around who remembers my data in a video convo a few days back? [05:55:54 CEST] <bubbaFFMPEG> I think im having palette problems. Im trying to make animated gif from mp4, Ive tried many ways, and failed. I get Error initializing filter 'fps' with args '1', googling hasnt resolve the issue. [05:57:07 CEST] <furq> bubbaFFMPEG: pastebin the full command [05:59:35 CEST] <bubbaFFMPEG> This is a the most recent attempt. [05:59:36 CEST] <bubbaFFMPEG> https://pastebin.com/VH0u9fwx [06:03:21 CEST] <bubbaFFMPEG> I was able to make a gif, but it looked horrible, so I looked into making it look reasonable, and I guess that means making a palette first. I cant seem to do that part. [06:03:48 CEST] <bubbaFFMPEG> like discribed here: https://superuser.com/questions/556029/how-do-i-convert-a-video-to-gif-usin… [06:07:37 CEST] <bubbaFFMPEG> Here was my first attempt to follow those instructions, I changed some values, removed the time stuff. [06:07:40 CEST] <bubbaFFMPEG> https://pastebin.com/3rQFQ0aa [06:07:47 CEST] <furq> palettegen creates an output stream, so palette.png in that command should be the output file [06:07:55 CEST] <furq> and then you'd do a second pass with the video and the palette and -vf paletteuse [06:08:13 CEST] <furq> but you can do it in one command like this: http://vpaste.net/o8QPH [06:08:28 CEST] <furq> also you should really be using ffmpeg, not avconv [06:10:00 CEST] <bubbaFFMPEG> Unrecognized option 'lavfi'. [06:10:30 CEST] <bubbaFFMPEG> Yeah, I hate avconv, and ive tried to apt-get install ffmpeg, but it refuses [06:10:56 CEST] <furq> if you're on an old debian/ubuntu then just use https://www.johnvansickle.com/ffmpeg/ [06:11:19 CEST] <furq> -lavfi is an alias for -filter_complex so use that for now [06:11:43 CEST] <furq> also i assume this is a short enough video for it all to be buffered [06:11:48 CEST] <furq> but if not then you'd need to do it in two passes [06:11:51 CEST] <bubbaFFMPEG> I think Im going to be upgrading to the new LTE or whatever ubuntu is coming out this month, but for now I can put up with avconv. [06:12:17 CEST] <bubbaFFMPEG> Yeah, its short, its like 30 seconds [06:12:52 CEST] <furq> well yeah if it throws buffer queue overflow errors then pretty much just run the example commands for palettegen and paletteuse [06:13:45 CEST] <bubbaFFMPEG> what are the example commands? how do I use those? [06:14:12 CEST] <furq> !filter palettegen @bubbaFFMPEG [06:14:12 CEST] <nfobot> bubbaFFMPEG: http://ffmpeg.org/ffmpeg-filters.html#palettegen-1 [06:14:15 CEST] <furq> !filter paletteuse @bubbaFFMPEG [06:14:15 CEST] <nfobot> bubbaFFMPEG: http://ffmpeg.org/ffmpeg-filters.html#paletteuse [06:18:59 CEST] <bubbaFFMPEG> I tried the palettegen example and it failed. [06:19:01 CEST] <bubbaFFMPEG> https://pastebin.com/Zc9t7Bhx [06:19:16 CEST] <furq> oh wow [06:19:27 CEST] <furq> yeah i guess that's just down to having an ancient libav [06:19:34 CEST] <furq> just use those ffmpeg static builds i linked [06:20:11 CEST] <bubbaFFMPEG> Ugh, well, I better back up data, so I can make disk space while im at it :( [06:20:59 CEST] <furq> it's only about 20MB [06:23:16 CEST] <bubbaFFMPEG> I just treid a website called ezgif, and it did a nice job, and it used ffmpeg and imagemagik, just like i am. [06:32:45 CEST] <bubbaFFMPEG> I downloaded and uncompressed the static 32bit build, but I cant figure out how to install, there doesnt seem to a an install script [06:32:58 CEST] <furq> just put everything in bin/ in /usr/local/bin/ [06:33:05 CEST] <furq> or ~/bin if you prefer [06:34:23 CEST] <furq> actually i guess there's no bin/ in the archive, so just put ffmpeg in /usr/local/bin [06:35:18 CEST] <bubbaFFMPEG> Doh, I treid to uncompress it, but i ran out of disk space. its a 126mb download. [06:42:03 CEST] <bubbaFFMPEG> It looks like i had a lot of duplicate video on my primary disk, so I deleted a whole bunch of files. I sure hope they were all duplicates! [06:54:36 CEST] <bubbaFFMPEG> furq [Parsed_palettegen_2 @ 0xc58b880] [06:56:39 CEST] <bubbaFFMPEG> furq: it seems to have make a palette, im grinding out a gif to see if its working good. [06:58:19 CEST] <bubbaFFMPEG> furq: Yep, its working nicely. I think it was the palatte issue hanging me up. [06:59:41 CEST] <bubbaFFMPEG> furq: Thank you, I think I can move on to making gifs now. [09:24:04 CEST] <GrayShade> hi. do -preset and -crf interact? that is, can I use e.g. -preset ultrafast to pick a crf, then use a slower one to get a smaller file? [09:26:27 CEST] <TheAMM> Yes. [09:26:49 CEST] <TheAMM> Or wait, what, use -preset to pick a crf? [09:27:18 CEST] <TheAMM> "-crf 20 -preset ultrafast" will create a bigger file than "-crf 20 -preset veryslow" [09:29:10 CEST] <furq> no [09:29:12 CEST] <GrayShade> TheAMM: does -crf 20 -preset ultrafast look the same as -crf 20 -preset veryslow, disregarding the file size? [09:29:16 CEST] <furq> no [09:29:35 CEST] <GrayShade> oh [09:29:53 CEST] <furq> ultrafast might produce a smaller file than veryslow at the same crf [09:30:30 CEST] <furq> you really need to test with the exact same settings [09:30:37 CEST] <GrayShade> I see, okay [09:30:39 CEST] <furq> and tuning etc [09:30:41 CEST] <GrayShade> thanks [09:30:56 CEST] <TheAMM> ? [09:31:19 CEST] <JEEB> CRF value is 100% dependant on the settings [09:31:26 CEST] <TheAMM> I've seen the -presets being about the speed and compression [09:31:28 CEST] <JEEB> what CRF can "see" [09:31:29 CEST] <JEEB> yes [09:31:46 CEST] <JEEB> they also make the algorithms internally which are also relevant to CRF differ [09:31:58 CEST] <JEEB> so the same CRF value does not produce the same quality for different presets [09:32:08 CEST] <GrayShade> I have some crappy phone video I want to make smaller than 16 mbps. I guess I'll have to play with the settings for a bit [09:32:17 CEST] <JEEB> for example if you go from slow to veryslow or placebo in x264 it's highly likely that the file size for the same CRF will go *up* [09:32:22 CEST] <JEEB> because the algorithms "see" more things [09:32:34 CEST] <JEEB> and thus the result is different [09:32:55 CEST] <JEEB> so you a) pick the preset b) iterate over ~2500 frames or something to find the highest CRF value that still looks good [09:32:57 CEST] <TheAMM> Fuzz in terms on the h264 encoding guide [09:33:00 CEST] <furq> crf is supposed to be constant quality regardless of source, not regardless of other settings [09:33:15 CEST] <TheAMM> Not compression as in data packs better, but lossy compression as in more detailed data is packed [09:33:39 CEST] <GrayShade> and woah, the noise magically goes away [09:33:47 CEST] <JEEB> furq: lol I got scolded hard by pengvado when I called CRF "constant quality" [09:33:50 CEST] <JEEB> since it's not [09:33:53 CEST] <JEEB> it's the closest we have to such [09:34:03 CEST] <furq> yeah i was careful to add "supposed to be" [09:34:03 CEST] <JEEB> but it's "just" constant rate factor [09:34:28 CEST] <JEEB> and when you iterate over CRF values, generally start somewhere high where you have at least chance of seeing artifacts :P [09:34:32 CEST] <JEEB> like 23 [09:34:35 CEST] <JEEB> (which is the default CRF value) [09:34:51 CEST] <furq> obviously if the source is five minutes of confetti raining down over the sea, it's maybe not going to hold up [09:37:35 CEST] <fella> furq: < furq> ultrafast might produce a smaller file than veryslow at the same crf -- I can hardly imagine in what cases that might happen? [09:37:56 CEST] <furq> maybe superfast rather than ultrafast, since ultrafast is so much different [09:38:21 CEST] <furq> i rarely go lower than slow, but i've definitely had slow encodes turn out noticeably smaller than veryslow [09:47:55 CEST] <alone-y> furq, may i ask? [09:48:20 CEST] <alone-y> thank you for filter-complex idea. it's working perfect for avoiding bat file limit 8192 [09:54:25 CEST] <mlok> hey anybody know a similar command to -q:a 1 ? [09:54:30 CEST] <mlok> *flag [09:54:39 CEST] <mlok> or another way to tune this setting more [10:13:46 CEST] <alone-y> can i do if rgb(x,y)<>255 then z=z+1? [11:18:22 CEST] <faLUCE> Hello. I'm trying to make a video from single image + mp3. I tried: ffmpeg -loop 1 -r 1 -i de-bellis.jpg -i leonardo-leo-dixit-dominus.mp3 -acodec copy -vcodec libx264 leonardo-leo-dixit-dominus.mp4 but it goes into an endless loop. what's wrong ? [11:19:46 CEST] <durandal_1707> faLUCE: add -shortest [11:22:13 CEST] <faLUCE> durandal_1707: at which point? [11:23:03 CEST] <durandal_1707> faLUCE: where output options are [11:23:37 CEST] <faLUCE> thnks durandal_1707 [12:47:12 CEST] <shfil> hi, I want use "avio_context_free" but on our CI (ubuntu, fedora, MSVC) I get "error: 'avio_context_free' was not declared in this scope". On macOS and Arch it works. Do you know what can be suspect? [12:47:32 CEST] <shfil> for example: https://travis-ci.org/rwengine/openrw/builds/370138895 [12:48:01 CEST] <shfil> it is pull: https://github.com/rwengine/openrw/pull/420/files [13:48:06 CEST] <shfil> it looks like I should rewrite FindFFmpeg.cmake [14:00:48 CEST] <hay> hi all... when I am trying to do ffprobe -v debug -i udp://239.0.1.135:3135 for an UDP multicast stream, ffmpeg (and ffprobe) stops at "[udp @ 0x2f7c3e0] end receive buffer size reported is 131072"... it doesnt hang, but I can see with tcpdump that stream is arriving... but I am unable to use that input in ffmpeg... what am I doing wrong? thanks [14:02:03 CEST] <JEEB> if it's source-specific add ?sources=SOURCE_IP [14:02:11 CEST] <JEEB> also always use -timeout with UDP [14:02:20 CEST] <JEEB> -timeout 5000000 for 5 seconds IIRC [14:02:25 CEST] <JEEB> (before -i) [14:02:30 CEST] <JEEB> also ffprobe doesn't need -i [14:03:05 CEST] <JEEB> it's just ffprobe -v verbose -timeout 5000000 -sources SOURCE_IP udp://XXXX:PORT [14:03:07 CEST] <JEEB> that should work [14:03:19 CEST] <JEEB> it should die after five seconds if there's no data (according to ffprobe) [14:17:13 CEST] <hay> JEEB, thanks... I will try it in a few minutes when I'm back at the computer :) [14:18:25 CEST] <hay> should I use IP address as SOURCE_IP and not the MC address right? [14:23:06 CEST] <hay> with -sources and timeout added it just finishes immediately... output: https://pastebin.com/45yMdhKp [14:25:52 CEST] <JEEB> hay: SOURCE_IP is the multicast source [14:26:09 CEST] <JEEB> in the udp:// you put the MULTICAST address and port [14:30:07 CEST] <hay> thanks, it works :) [17:42:46 CEST] <Li> is it possible to extract audio based on h:mm:ss time interval for -ss and -to? [17:43:04 CEST] <Li> any example would be highly appreciated [17:55:54 CEST] <Li> good [18:41:36 CEST] <marcus_> Hi, I'm using ffmpeg to extract frames and combine using tile. Is it possible to optimize this command and make it faster? ffmpeg -i https://localhost:5001/original.mp4 -vf select='not(mod(n\,62))',yadif,scale=480:270:force_original_aspect_ratio=increase,crop=480:270,tile=1x50 -q:v 5 -nostats -loglevel 0 -frames:v 1 scrub.jpg [18:54:46 CEST] <ChocolateArmpits> marcus_, tile is a pretty hefty filter [18:54:49 CEST] <ChocolateArmpits> it seems [18:55:02 CEST] <ChocolateArmpits> try benching it with the bench filter to see how much it takes up processing time [18:58:51 CEST] <marcus_> ChocolateArmpits: I'm far from an expert on ffmpeg. Can you give me an example on what you mean? [18:59:06 CEST] <marcus_> ChocolateArmpits: Is it possible to tile with some other filter maybe? [18:59:36 CEST] <ChocolateArmpits> marcus_, overlay, but you'll have to multiply the video stream 50 times for that. Can't be in any way more efficient [19:00:15 CEST] <ChocolateArmpits> not to mention it won't lay out the frames correctly, so there'll have to be even more select filters [19:00:41 CEST] <ChocolateArmpits> bench filter is used to test processing time taken for a single frame [19:01:06 CEST] <ChocolateArmpits> place bench=start at the position you want to start checking performance from and bench=stop where you want the performance checking to end [19:01:33 CEST] <ChocolateArmpits> place these in the filtergraph that is, will print time processing information [19:02:11 CEST] <ChocolateArmpits> tile is also not threaded leading to potentially even slower performance [19:03:11 CEST] <durandal_1707> tile just does memcpy [19:05:46 CEST] <ChocolateArmpits> replacing yadif for pp=lb will speed it up, but that's not where the real performance issue is [19:07:52 CEST] <ChocolateArmpits> dropping color should speed up tile I think, if you're not concerned with only having a black and white image [19:09:25 CEST] <marcus_> I need color for this feature so that is not an option [19:09:35 CEST] <ChocolateArmpits> scale filter flag set to area or neighbor should speed up the operation too, in exchange for decreased quality (mostly with neighbor) [19:11:00 CEST] <ChocolateArmpits> marcus_, so what's the actual speed ? is it impossible to run concurrently if multiple videos need to be processed [19:11:01 CEST] <marcus_> How would you approach this problem to make it fast and effective on even very large movies? Is seek an option? [19:11:11 CEST] <durandal_1707> the biggest source of cycles is before select filter, you decode bunch of frames which you then discard [19:12:55 CEST] <marcus_> I have an mp4 movie 228MB that takes about 25 seconds to create a 50 frame tile [19:13:40 CEST] <marcus_> Running on aws with the source on s3 using accelerated endpoint [19:17:08 CEST] <ChocolateArmpits> you could try grabbing only keyframes using concat file with inpoint-outpoint for the number of frames needed, but you'd have to determine their position first using ffprobe [19:19:34 CEST] <ChocolateArmpits> so it's more or less counting time offsets for whatever number of frames based on file duration you need, then searching those time offsets backwards and forwards for any keyframes and grabbing the times. Add file start time to each exact keyframe offset and input it to a concat file, outpoint having the timestmap of the next frame after the keyframe [19:20:08 CEST] <ChocolateArmpits> this sounds, but not sure if it'll work out completely smooth [19:20:13 CEST] <ChocolateArmpits> this sounds possible to do* [19:20:29 CEST] <marcus_> Ok, I see [19:20:49 CEST] <furq> maybe -skip_frame nokey [19:21:10 CEST] <furq> although you'd need to do ffprobe -skip_frame nokey -count_frames to get an accurate keyframe count [19:21:23 CEST] <furq> and doing that plus your ffmpeg command might end up taking more time than it does now [19:22:20 CEST] <ChocolateArmpits> hmmm an example in the tile filter does suggest using -skip_frame nokey [19:22:49 CEST] <ChocolateArmpits> https://ffmpeg.org/ffmpeg-filters.html#Examples-101 [19:24:17 CEST] <ChocolateArmpits> the only problem if the gop duration isn't fixed, it won't be possible to do frame selection the way they are done in the initial command, you'll have to pick using timestamps [19:25:41 CEST] <ChocolateArmpits> and it'll still have to decode all keyframes, though that's less work than intially planned [19:25:53 CEST] <ChocolateArmpits> I would probably explore this option first, before doing concat file [19:27:39 CEST] <marcus_> Ok, I will give -skip_frame a try [19:27:42 CEST] <marcus_> Today I do "-select_streams", "v:0", "-show_entries", "stream=nb_frames" [19:27:58 CEST] <marcus_> to select the number of frames using ffprobe [19:28:18 CEST] <marcus_> Will this give me the wrong number of frames? [19:28:22 CEST] <furq> you can try just adding -skip_frame nokey to that, but i suspect you'll need -count_frames as well [19:28:28 CEST] <furq> i did last time i tried this [19:29:35 CEST] <ChocolateArmpits> for ffprobe you may want to use read_intervals, you can then input time where the file should be read, it's pretty much seeking so no need to collect frames before or between the times you are interested [19:29:56 CEST] <ChocolateArmpits> you can also list lots of time in succession [19:30:16 CEST] <ChocolateArmpits> so no need to rerun ffprobe for each potential offset of interest [19:43:40 CEST] <marcus_> Adding -skip_frame nokey to my command results in just one frame and the others 49 is blank? [19:54:24 CEST] <mlok> .win 3 [20:06:41 CEST] <marcus_> With -skip_frame nokey it seems to run faster but I get a lot of blank frames [20:07:12 CEST] <ChocolateArmpits> marcus_, did you try with -vsync 0 as suggested? [20:11:57 CEST] <marcus_> ChocolateArmpits: yes, but the result is the same [22:21:16 CEST] <GamleGaz> should srcSliceY and srcSliceH be the width and height of the frame when converting yuv420p->RGB24 using sws_scale? [23:16:09 CEST] <b0bby__> hello [23:17:20 CEST] <b0bby__> with the ffmpeg command how do you get ffmpeg to output a new line rather than a cartridge return when outputting file progress [23:17:23 CEST] <b0bby__> ? [23:31:21 CEST] <b0bby__> hello? [23:32:07 CEST] <kepstin> b0bby__: the main stats output is hardcoded to do \r, so you'd have to edit the source and recompile to change that [23:32:35 CEST] <kepstin> b0bby__: why do you want to change it? maybe there's some other things to try. [23:33:22 CEST] <b0bby__> kepstin: is there a way to output only the current frame ffmpeg is on [23:33:34 CEST] <b0bby__> kepstin: Like no other output [23:33:49 CEST] <kepstin> b0bby__: what do you want to use this output for? [23:34:15 CEST] <b0bby__> kepstin: Keep track of how complete ffmpeg is [23:34:52 CEST] <kepstin> as a person? just watch the output on the terminal, that should work fine with \r... [23:35:29 CEST] <kepstin> it will just keep updating the same line on the terminal (assuming it's wide enough that you don't get wordwrapping) [23:35:30 CEST] <b0bby__> kepstin: I'm not watching it. A program is. I'm redirecting output to a log [23:35:40 CEST] <tdr> pipe the output through a text filter? (sed /awk ... ) [23:36:00 CEST] <tdr> or tr [23:36:00 CEST] <b0bby__> tdr: How [23:36:11 CEST] <kepstin> b0bby__: ok, so if you're doing this programmatically, you shouldn't be using that output - instead, you probably want to use -vstats and -vstats_file to a pipe or file, and read that [23:36:12 CEST] <b0bby__> ? [23:36:21 CEST] <tdr> b0bby__, are you on linux or iwndows or ? [23:36:27 CEST] <b0bby__> tdr: linux [23:36:56 CEST] <kepstin> b0bby__: the vstats output is a defined program-readable format, separated with \n [23:38:18 CEST] <b0bby__> kepstin: what happens if it is only half complete [23:38:26 CEST] <kepstin> not sure what you mean [23:38:46 CEST] <kepstin> ffmpeg doesn't know what percentage complete it is [23:39:06 CEST] <b0bby__> kepstin: but it does no what frame it is one and the time stamp of that frame [23:39:12 CEST] <b0bby__> *know [23:39:31 CEST] <kepstin> yes, but it doesn't know how long the video will be when it's done [23:39:46 CEST] <b0bby__> kepstin: I don't care about the time [23:39:53 CEST] <b0bby__> kepstin: just the percent [23:40:13 CEST] <kepstin> but unless you know how long the video will be when it's done, you can't know how far through the video you are [23:40:23 CEST] <kepstin> so there's no way to calculate a percent [23:40:51 CEST] <kepstin> If you (as the person running ffmpeg) know how long the output is, you can calculate the percent yourself from the current time [23:41:15 CEST] <b0bby__> 1. Find the length of the original video 2. Monitor ffmpeg for output on current frame. 3. current/original length 4. profit [23:42:57 CEST] <kepstin> that works as long as the output video will be the same length as the input video, yep. [23:44:12 CEST] <furq> i already have an awk script that does that somewhere [23:44:16 CEST] <b0bby__> kepstin: So when trancoding(which is what I'm doing) ffmpeg is going to add extra time to the file because it feels like it? [23:44:39 CEST] <kepstin> not unless you use filters that change the video length [23:44:39 CEST] <b0bby__> furq: please can I get that awk script [23:44:57 CEST] <furq> http://vpaste.net/iraOS [23:47:06 CEST] <furq> i don't really recommend using this for the reasons that have already been said [23:47:13 CEST] <furq> but it does basically work [23:48:28 CEST] <furq> bye [23:50:28 CEST] <kerio> IRA OS huh [23:51:00 CEST] <furq> your tone is antagonistic and you're making me very angry [23:51:12 CEST] <kerio> tiocfaidh ár lá [00:00:00 CEST] --- Thu Apr 26 2018

1 0