April 2019 - Ffmpeg-devel-irc

ffmpeg-devel.log.20190429
by burek 30 Apr '19

30 Apr '19

[00:02:48 CEST] <JEEB> j-b: unfortunately GPLv2+ is the most quoted limiting license that touches upon these things when people end up talking about OSS and closed source stuff. and yes, too bad it's worded in an awkward way. [00:02:55 CEST] <JEEB> so it's unsurprising that people bring it up [00:03:10 CEST] <JEEB> (also it's the most limiting license you can configure FFmpeg under) [00:03:29 CEST] <j-b> exactly, so, as it is the most limiting, it would make sense to use this definition, as it is for exclusion [00:04:32 CEST] <JEEB> yes [00:25:29 CEST] <nevcairiel> We should make it a general policy to officially discuss a vote before actually asking the vote itself, because often its just badly worded and as such results in discussion and influences the actual votes cast [00:27:21 CEST] <jkqxz> ... or the absence of actual votes cast, for that matter. [00:49:25 CEST] <cone-166> ffmpeg 03James Almer 07master:67f9d3f461f6: avcodec/cbs_av1: add missing value range constrains to timecode Metadata OBU [01:33:52 CEST] <cone-166> ffmpeg 03James Almer 07master:16c50abb5016: avcodec/cbs_h2645: add macros to read and write fields with no custom range of values [01:33:53 CEST] <cone-166> ffmpeg 03James Almer 07master:45048ece81d3: avcodec/cbs_h2645: use the fixed() macro for forbidden_zero_bit [11:12:53 CEST] <cone-829> ffmpeg 03Matthias Troffaes 07master:90b21ae5b5f8: avfilter/af_astats: fix msvc compile error [11:49:03 CEST] <durandal_1707> why atomnuker left? [15:22:23 CEST] <cone-704> ffmpeg 03Paul B Mahol 07master:ce774e30ffe3: avfilter/avf_showspectrum: add log scale for frequency plot [15:22:23 CEST] <cone-704> ffmpeg 03Paul B Mahol 07master:a66324cd52f5: avfilter/avf_ahistogram: properly name pads [15:22:23 CEST] <cone-704> ffmpeg 03Paul B Mahol 07master:77aacdb03683: avfilter/avf_ahistogram: switch to activate [15:22:23 CEST] <cone-704> ffmpeg 03Paul B Mahol 07master:21b1f08ea2ec: avfilter/avf_avectorscope: switch to activate [15:22:23 CEST] <cone-704> ffmpeg 03Paul B Mahol 07master:21d1bb00c4d1: avfilter/af_sofalizer: switch to activate [15:22:23 CEST] <cone-704> ffmpeg 03Paul B Mahol 07master:a89ec33fd591: avfilter/af_rubberband: check if rbs is valid [15:22:23 CEST] <cone-704> ffmpeg 03Paul B Mahol 07master:a40bcb5c93b5: avfilter/af_rubberband: switch to activate [15:22:24 CEST] <cone-704> ffmpeg 03Paul B Mahol 07master:d7fead80ad99: avfilter/af_dynaudnorm: switch to activate [16:25:32 CEST] <durandal_1707> ubitux: there are ways for biqauds in ebur128 to be created with arbitrary sample rates [16:27:09 CEST] <ubitux> that sounds good [16:27:13 CEST] <ubitux> i was wondering about it [16:49:04 CEST] <durandal_1707> ubitux: see small patch for silly bug in ebur128 on ML [16:50:41 CEST] <ubitux> i don't see anything [16:54:04 CEST] <durandal_1707> i sent it, perhaps it need to process it longer? [16:55:57 CEST] <ubitux> just got it [16:56:04 CEST] <ubitux> wow... [16:56:45 CEST] <nevcairiel> who uses anything beyond the first 16 channel anyway [16:57:13 CEST] <ubitux> libavutil/channel_layout.h:#define AV_CH_LOW_FREQUENCY_2 0x0000000800000000ULL [16:57:21 CEST] <ubitux> well... for this one :p [16:59:15 CEST] <ubitux> top back center too [16:59:18 CEST] <ubitux> and a few others, meh [16:59:32 CEST] <nevcairiel> not actually channels common to find in audio, is all I'm saying :) [16:59:41 CEST] <ubitux> :) [20:23:21 CEST] <durandal_1707> ubitux: lut3d is supposed to work with float pixel format, same as exr decoder [20:25:08 CEST] <durandal_1707> because alowed range is out 0, 1 - which exr->rgb clips [20:25:34 CEST] <durandal_1707> and exr decoder is big HACK MESS with internal code to do transforms [20:26:50 CEST] <logicWEB> hello :-) I submitted a patch, and it was the first time I'd done it and I made a hash of it (my e-mail client wrapped lines, so the patch was corrupt). someone asked me to re-post it a different way, so I replied with an attachment, and it's just been sitting there for a while now [20:27:03 CEST] <logicWEB> is there a thing I should be doing to draw attention? should my re-post have been as a new root post instead of a reply?? [20:27:19 CEST] <cone-945> ffmpeg 03Paul B Mahol 07master:31990046ac68: avfilter/f_ebur128: use correct type for chl [20:27:35 CEST] <cehoyos> Please add a little information about which patch you are talking about;-) [20:39:26 CEST] <cone-945> ffmpeg 03Martin Vobruba 07master:093a504414ef: avfilter/avf_showwaves: Add draw mode also to showwavespic filter [20:48:41 CEST] <durandal_1707> logicWEB: link to patch? name of patch? [21:13:06 CEST] <cone-945> ffmpeg 03Paul B Mahol 07master:12a284fa6356: avfilter/af_rubberband: make use of initial input timestamp [22:02:50 CEST] <logicWEB> durandal_1707: it's in a thread titled "[PATCH] libavfilter/f_select: response file support" on the mailing list [22:11:54 CEST] <durandal_1707> logicWEB: ping it on ML [22:12:44 CEST] <logicWEB> just send a follow-up message to the same thread? or start a new thread? [22:16:18 CEST] <durandal_1707> logicWEB: reply to same thread [22:18:15 CEST] <logicWEB> will do, thanks :-) [22:27:11 CEST] <cone-945> ffmpeg 03Paul B Mahol 07master:e6c7d838ea90: avfilter/af_adeclick: switch to activate [23:33:55 CEST] <cone-945> ffmpeg 03Paul B Mahol 07master:ac551c54b138: avfilter/vf_normalize: add timeline support [00:00:00 CEST] --- Tue Apr 30 2019

1 0

ffmpeg.log.20190429
by burek 30 Apr '19

30 Apr '19

[01:51:13 CEST] <TikityTik> is there a difference to putting the video filter before specifying the video codec and codec settings vs after?? [01:51:24 CEST] <TikityTik> and does 2 pass actually help crf encoding with libvpx? [01:53:40 CEST] <JEEB> the major differences are between input and output related parameters, their order within those two don't really matter other than if you define something twice :P [01:54:07 CEST] <TikityTik> so there's no difference in what i said? [01:54:15 CEST] <JEEB> ffmpeg INPUT_OPTIONS_FOR_INPUT -i INPUT OUTPUT_OPTIONS_FOR_OUTPUT OUTPUT [01:55:02 CEST] <JEEB> basically you can have multiple inputs and outputs and the order of the options matter in the sense if they're before or after inputs and f.ex. before which input or output they come [01:55:12 CEST] <JEEB> but if you have the most common case, then you have one input and one output [01:55:31 CEST] <JEEB> and thus it only matters that options you meant for output are after input and before output [01:55:38 CEST] <JEEB> and what you meant for input are before input [01:56:15 CEST] <JEEB> the order within those parts only matter on the level of "if you define option X more than once, most likely the last definition will stand" [01:57:41 CEST] <TikityTik> thanks, and what about 2pass for libvpx crf? [01:59:53 CEST] <furq> TikityTik: yes it does actually help because -crf isn't really crf for vpx [02:00:28 CEST] <furq> although mostly because vpx's rate control is just generally bad [02:00:38 CEST] <furq> a lot of features are only enabled on the second pass [02:01:31 CEST] <TikityTik> also how do i know what bufsize to use? i don't know when to have 1 MB bufsize of 4 MB bufsize [02:01:50 CEST] <furq> what makes you think you need to set bufsize [02:02:00 CEST] <DHE> vbv demands it, but he doens't understand the rules [02:02:01 CEST] <TikityTik> crf doesn't work without bufsize i believe [02:02:10 CEST] <DHE> no [02:02:21 CEST] <TikityTik> oh? [02:02:40 CEST] <DHE> are you specifying both a bitrate and crf setting? [02:03:11 CEST] <TikityTik> DHE: now i'm only doing either CBR or CRF only [02:03:20 CEST] <TikityTik> not both since i learned that it's crap lol [02:03:42 CEST] <furq> yeah you need to set -b:v 0 [02:03:49 CEST] <furq> or -b:v max-bitrate [02:04:15 CEST] <TikityTik> so if i want to use only crf i need -b:v 0? [02:04:18 CEST] <furq> yes [02:04:24 CEST] <furq> unless something changed recently [02:04:27 CEST] <TikityTik> how do i figure this out on my own without IRC? lol [02:04:36 CEST] <furq> no comment [02:04:50 CEST] <DHE> you get true constant-quality mode, but the codec can do whatever it wants in terms of bitrate [02:04:56 CEST] <furq> this is particular to libvpx, other encoders have less dumb default settings [02:05:02 CEST] <TikityTik> heh [02:05:44 CEST] <furq> also i can't find an authoritative source for 2-pass cq being better that's newer than about 2011 [02:05:45 CEST] <TikityTik> i don't need bufsize if i do CBR i assume? [02:05:54 CEST] <TikityTik> only cbr and not crf [02:05:55 CEST] <furq> so maybe that's not true any more but it probably is [02:06:24 CEST] <DHE> actually you do. CBR is just a variant of VBR where minbitrate, bitrate and maxbitrate are the same number [02:06:26 CEST] <furq> TikityTik: -b:v isn't cbr, it's abr [02:06:55 CEST] <TikityTik> ok so i guess i can skip -b:v and use minrate = maxrate? [02:07:12 CEST] <furq> set b:v to the same value as minrate and maxrate [02:07:20 CEST] <DHE> usually b and maxrate are good enough [02:07:21 CEST] <TikityTik> ughh, redundant typing [02:07:32 CEST] <furq> i don't actually know if you need all three but it can't hurt [02:07:36 CEST] <TikityTik> so would i need bufsize for that? [02:07:40 CEST] <DHE> yes [02:07:46 CEST] <TikityTik> i see... [02:07:49 CEST] <furq> really? [02:08:02 CEST] <DHE> I'm an x264 guy, but I'm assuming the rules are about the same, no? [02:08:04 CEST] <furq> i don't see why bufsize would make a difference if minrate is enforced [02:08:28 CEST] <furq> actually nvm yes i do [02:08:45 CEST] <furq> trac doesn't mention bufsize in the cbr section anyway [02:09:15 CEST] <furq> i'm going to stop thinking about libvpx now because it's hurting my brain [02:09:19 CEST] <TikityTik> when when do i need to remake pass 1? if i only change input options? [02:09:27 CEST] <TikityTik> or if i change output options? [02:10:25 CEST] <DHE> again, I'm an x264 guy. you can usually get away with setting changes on pass 2 that don't affect the frame type decisions (I, P, B) [02:12:30 CEST] <TikityTik> wow my bitrate sure jumped up with crf mode and setting -b:v 0 [02:20:44 CEST] <TikityTik> thanks everyone for the info btw [02:25:23 CEST] <another> TikityTik: https://trac.ffmpeg.org/wiki/Encode/VP9 [02:25:33 CEST] <TikityTik> i have to specifically use vp8 [02:25:40 CEST] <another> TikityTik: https://trac.ffmpeg.org/wiki/Encode/VP8 [02:28:10 CEST] <TikityTik> so why do you need -b:v 0 for true crf mode? what is happening without it? [02:30:50 CEST] <another> constrained quality i presume [02:32:00 CEST] <TikityTik> what do you mean? [02:32:59 CEST] <another> see the VP9 article [02:33:24 CEST] <another> i think most of that applies to VP8 as well [02:34:49 CEST] <furq> TikityTik: -crf and -b:v together will clamp it to that maximum bitrate [02:35:08 CEST] <furq> and the default bitrate setting for libvpx is 200kbps [02:35:15 CEST] <TikityTik> interesting [02:35:23 CEST] <furq> it's some legacy ffmpeg thing afaik [02:38:01 CEST] <another> isn't that the default bitrate for all video? [02:47:22 CEST] <TikityTik> what's a good way of comparing crf encodings to see which one turned out better? [02:47:36 CEST] <TikityTik> i'm trying to watch it side by side but it's too hard to tell [02:57:07 CEST] <TikityTik> ah whatever [02:58:44 CEST] <TikityTik> also is it true that -quality best makes the quality worse for libvpx vp8? [03:33:29 CEST] <TikityTik> hahah i guess i ask too many questions [04:31:56 CEST] <buhman> how do I get good quality encoding with h264_vaapi or hevc_vaapi? I tried both intel/radeon cards, and I see very clearly square patches on the output [04:32:32 CEST] <buhman> I was reading https://trac.ffmpeg.org/wiki/Hardware/VAAPI but a few options I tried from there had no effect (like changing bitrate/profile/..) [04:47:53 CEST] <TikityTik> just a noob here but i thought using graphic drivers for encoding is worse than using the cpu? [04:47:59 CEST] <TikityTik> that it's mainly for livestreaming [04:50:26 CEST] <TikityTik> buhman: is thise for a video file or a stream? [04:51:42 CEST] <buhman> TikityTik: when you have live input, the encoder needs to be able to keep up with the input framerate [04:52:21 CEST] <buhman> it doesn't matter so much if the output is a file or "stream" api [04:55:42 CEST] <TikityTik> buhman: https://video.stackexchange.com/questions/14656/why-processor-is-better-for… [05:01:58 CEST] <buhman> I don't think any of this is relevant to my question [05:07:49 CEST] <TikityTik> ah, sorry then [07:45:29 CEST] <acresearch> people, i have 2 videos that i want to fuse into 1 video, how? [09:56:21 CEST] <xqo> hello, does anyone understand the WEBM/Matroska format? I'm trying to extract ogg vorbis audio from webms, what kind of element has the actual audio data? frames? blocks? segments? [09:57:56 CEST] <xqo> The docs are a little hard to read, but I _think_ Segments hold actual file data, and contains all the frames, and that anything outside Segments is metadata. Can someone confirm? [09:57:59 CEST] <JEEB> looking at a matroska file with mkvinfo with specific flags lets you see the structure. simpleblocks etc usually contain the stuff, although muxers can utilize different muxing techniques [10:01:32 CEST] <xqo> @jeeb ok! do you also understand how the simpleblocks are arranged? What is confusing is how the docs reference seek-time very often. Do you simply find the first and last simpleblock, and join them all in the order they are in the file, or are they arranged arbitrarily? [10:03:11 CEST] <xqo> first simpleblock referenced by a track* [10:06:59 CEST] <acresearch> people, i have 2 videos that i want to fuse into 1 video, how? [12:13:09 CEST] <hedgehog90> I have a 24fps CFR lossless HuffYUV video and i want to convert it to h264, but it always changes the framerate mode to Variable. I've tried specifying the framerate with -r on both input and output, but it doesn't work. Any ideas? [12:13:36 CEST] <hedgehog90> (by it I mean ffmpeg always changes the framerate mode to Variable) [12:16:19 CEST] <hedgehog90> ffmpeg -i input.mkv -r 24 -c:a aac -b:a 384k -vf "scale,format=pix_fmts=gbrp,zscale=m=709:dither=random,format=pix_fmts=yuv420p" -c:v libx264 -preset veryfast -profile:v high -level 4.1 -crf 6 -threads 0 -r 24 output.mkv [12:18:58 CEST] <durandal_1707> use fps filter and not -r 24 [12:21:48 CEST] <Hypnotoad90_> any known common reason why av_read_frame and/or avcodec_decode_audio4 might start spitting out a bunch of frames that are only one sample long? [12:23:25 CEST] <durandal_1707> Hypnotoad90_: hmm? needs more info, could be anyting [12:25:46 CEST] <Hypnotoad90_> unfortunaly don't have access to the machine it occured to at the moment, but it happened on a pcm 2 channel audio stream, after several dozen frames it suddenly started producing frames with unusual sizes after initially being consistently 1024 samples long, for instance dozens of frames only 1 sample long in a row, followed later by a large frame tens of thousands of samples long [12:26:38 CEST] <durandal_1707> still not enough info [12:30:05 CEST] <Hypnotoad90_> of course, im checking if there are currently known or frequent issues that could cause that, that i could check against [12:30:15 CEST] <Hypnotoad90_> im not asking specifically what's causing it in my case right now [12:35:01 CEST] <hedgehog90> Regarding my framerate issue - I;ve just realised if I remux the supposedly constant frame rate mkv in question using mktoolnix, it says the framerate is 24.203fps and it sets the mode to variable [12:35:09 CEST] <hedgehog90> What's going on? [12:36:26 CEST] <JEEB> you can take a look at the timestamps in mkvinfo etc [12:36:40 CEST] <JEEB> also matroska cannot handle all frame rates exactly [12:37:05 CEST] <JEEB> I wouldn't be surprised if your input file isn't really possibly CFR either [13:11:45 CEST] <hedgehog90> JEEB, I just checked and the interval between frames is 42,42,41 repeated until the final frame, which is correct [13:12:30 CEST] <hedgehog90> Not sure how the avg frame rate 24.102 is being calculated from that... [13:13:23 CEST] <hedgehog90> So how do I tell ffmpeg to brute force the frame rate to 24fps? And will it cause issues with my audio sync? I tried the fps filter but no luck? [13:15:56 CEST] <BtbN> Via the fps filter. [13:16:13 CEST] <BtbN> Audio should stay in sync, the fps filter will only drop or duplicate frames. [13:16:55 CEST] <hedgehog90> Hmm... [13:17:46 CEST] <hedgehog90> I just checked the frame interval from an output (the result of an ffmpeg conversion) and the first few frame intervals are: 65 41 42 19 64 [13:17:59 CEST] <hedgehog90> and then 42, 42, 41 for the rest of the video [13:18:25 CEST] <hedgehog90> I don't want any frame dropping [13:18:58 CEST] <hedgehog90> I just want to take my supposedly 24fps and prevent ffmpeg from messing with the frame intervals [13:19:06 CEST] <hedgehog90> as it appears to be doing [13:19:11 CEST] <BtbN> It doesn't. FFmpeg passes through timestamps. [13:19:59 CEST] <hedgehog90> and yet my source timestamps appear to be perfectly 24fps [13:22:09 CEST] <hedgehog90> any ideas what's going on here? [13:22:31 CEST] <hedgehog90> Maybe I could upload a snippet of the source file and someone could take a look. [13:30:00 CEST] <hedgehog90> ok, bizarrely this is all being caused by the aduio - I tried the same command with -an (remove audio) instead of converting the original pcm to aac, and now the framerate is a constant 24fps [13:30:36 CEST] <hedgehog90> So how do I get true 24fp avc with aac audio? This is maddening. [13:41:38 CEST] <hedgehog90> Another thing - if I don't specify -r 24 for my input, then ffmpeg takes a look at my 42,42,41 interval source file, and just outputs it with all intervals of 41 (24.417 fps) [13:42:11 CEST] <hedgehog90> I do not get this... please help. [13:46:12 CEST] <durandal_1707> hedgehog90: your input is not CFR [13:46:41 CEST] <hedgehog90> Right, it should be 41.6666 interval every frame, right? [13:47:34 CEST] <hedgehog90> Unfortunately this is the output from the video editing software and I've explicitly set it to export at 24fps. This is what I get. [13:48:58 CEST] <durandal_1707> leave input as is, and use fps filter to make output CFR [13:49:31 CEST] <durandal_1707> for 24 fps output it will drop some frames [13:49:57 CEST] <hedgehog90> I really don't want any dropped frames [13:50:07 CEST] <BtbN> You'll need to fix your input then [13:50:14 CEST] <hedgehog90> It's lossless video btw [13:52:44 CEST] <durandal_1707> cant you make it 25 FPS? [13:52:52 CEST] <hedgehog90> No [13:53:15 CEST] <hedgehog90> I could losslessly export each individual frame and reconvert back to video losslessly at 24fps... but surely there's a way of doing this in one command and simply [13:55:46 CEST] <hedgehog90> If I upload a snippet of the source video will someone please take a look? [14:04:36 CEST] <durandal_1707> hedgehog90: does vfrdet filter report something useful for your input? [14:05:47 CEST] <hedgehog90> VFR:0.663900 (160/81) min: 41 max: 42) [14:06:32 CEST] <hedgehog90> I've check other 24fps mkv files I have, and they all have the same interval pattern as my source. The source appears to be fine. [14:07:53 CEST] <hedgehog90> If I enter -r 24 before the input, and dont convert the audio to aac, then I retain the same frame intervals and it appears to be genuinely 24fps [14:08:03 CEST] <durandal_1707> you could change pts to not follow this strange pattern, but i dunno how this should look like... [14:09:22 CEST] <hedgehog90> By specifying the framerate before the input, i think it's working, but as soon as i try to add aac audio it goes to variable framerate and the first bunch of frames have unusual intervals [14:14:13 CEST] <hedgehog90> does this odd behaviour ring a bell with anyone? [14:14:34 CEST] <hedgehog90> why is my audio encoding changing the video's frame rate? [14:14:48 CEST] <durandal_1707> tried -vsync 0 to input and output? [14:15:18 CEST] <durandal_1707> they may have weird muxing interval... [14:16:35 CEST] <hedgehog90> made no difference, variable frame rate again [14:18:32 CEST] <hedgehog90> it's only the first 5 frames that go 'variable' (ie, not 42,42,41), but this is enough to make my video not processable by some sites [14:19:11 CEST] <hedgehog90> with aac encoding my first 5 frames have the intervals 65 41 42 19 64 [14:26:23 CEST] <durandal_1707> hedgehog90: if you trim that bad frames, do you get valid output? [14:29:25 CEST] <hedgehog90> exactly the same frame rate intervals if I trim the beginning [14:29:40 CEST] <hedgehog90> this appears to be a problem with aac now. [14:30:30 CEST] <durandal_1707> you could try other aac encoder... [14:31:01 CEST] <hedgehog90> like? [14:33:28 CEST] <hedgehog90> definitely something up with my ffmpeg aac encoder. I've just tried uploading some short clips with aac encoding to a particular video processing site and they all get rejected. I remove the audio and they are accepted. [14:37:36 CEST] <durandal_1707> it is muxing A+V issue [14:38:48 CEST] <hedgehog90> could you elaborate? [14:55:54 CEST] <hedgehog90> Using an mp4 container now, haven't changed anything else, framerate appears to be constant... [15:03:39 CEST] <JEEB> hedgehog90: mp4 can actually hold a lot of frame rates exactly, unlike matroska [15:04:23 CEST] <JEEB> think of matroska being only able to specify the times for each audio/video frame on the level of 1/X where X is something divisible by 10 [15:05:29 CEST] <JEEB> but that is usually considered "constant enough rate" if the container cannot hold it 100% exactly [15:05:34 CEST] <JEEB> same thing with the broadcast MPEG-TS [15:05:43 CEST] <JEEB> which has a hard-coded time base of 1/90000 [15:05:50 CEST] <JEEB> and FLV, which is hard-coded to 1/1000 [15:53:15 CEST] <Tazmain> Hi all, I have a wireshark trace with RTP, so I can extract the RTP but it was encoded using OPUS, how do I play it or convert to wav. I am really stuck here `ffmpeg -c:a libopus -i file.raw -vn sa.ogg` or `ffmpeg -c:a libopus -i file.raw -c copy out.opus` <- I tried this , I get an empty output file [15:53:49 CEST] <saml> Tazmain, you want to convert to .wav file (audio)? [15:54:02 CEST] <Tazmain> or play it :( [15:54:18 CEST] <Tazmain> either convert or play. Not having any luck [15:55:14 CEST] <saml> mv file.raw file.ogg; ffmpeg -i file.ogg file.wav [15:55:26 CEST] <saml> i don't know exact -f {format} parameter [15:55:51 CEST] <Tazmain> saml, but the file is raw binary [15:55:59 CEST] <saml> ffmpeg -f {format-for-opus} -i file.raw -vn -c:a pcm_s32le file.wav [15:56:14 CEST] <Tazmain> that is why there is that ` -c:a libopus` [15:56:14 CEST] <saml> ffmpeg detects type based on extension [15:56:21 CEST] <Tazmain> oh? [15:56:35 CEST] <saml> or, you'll have to specify -f format exactly [15:56:43 CEST] <acresearch> people, i have 2 videos that i want to fuse into 1 video, how? [15:57:24 CEST] <saml> Tazmain, can you upload the file.raw somewhere? [15:57:28 CEST] <Tazmain> I can [15:58:01 CEST] <Tazmain> saml, here you go https://send.firefox.com/download/fe076e66b48e76cc/#RdwKzgQA04_xoD5f3BpYzg [15:58:07 CEST] <saml> acresearch, maybe use -f concat [15:58:20 CEST] <saml> https://www.ffmpeg.org/ffmpeg-all.html#concat-1 [15:58:45 CEST] <acresearch> saml: ffmpeg -f concat file1.avi file2.avi ? [15:59:51 CEST] <saml> https://trac.ffmpeg.org/wiki/Concatenate [16:00:18 CEST] <saml> Tazmain, hrm i thought it was just a proper opus container. So, I'm wrong. I don't know how to read the file properly [16:00:28 CEST] <Tazmain> makes two of us [16:00:35 CEST] <Tazmain> it comes from RTP [16:00:41 CEST] <Tazmain> wireshark pcap file [16:00:45 CEST] <Tazmain> the RTP stream is opus [16:02:14 CEST] <saml> yeah it's out of my league [16:07:08 CEST] <Tazmain> saml, looks like pjsip might be able to, it uses ffmpeg [16:08:11 CEST] <Tazmain> if I can get it to compile that is [16:10:50 CEST] <saml> Tazmain, it's a raw tcp dump in the middle of stream? [16:11:07 CEST] <Tazmain> its UDP (RTP) and it's the full conversation [17:22:31 CEST] <Yamakaja> Hey, i'm a bit lost here - i can't really find any documentation on the mpeg2video codec 0.o [17:23:07 CEST] <Mavrik> What kind of documentation do you need? :) [17:23:18 CEST] <Yamakaja> I'd like to know what the -g flag does [17:23:30 CEST] <DHE> group-of-pictures, or interval between keyframes [17:23:46 CEST] <Yamakaja> Which unit? [17:23:49 CEST] <DHE> frames [17:24:04 CEST] <Yamakaja> Lol, it's set to 1 here [17:24:55 CEST] <Mavrik> Nice [17:25:03 CEST] <Mavrik> Efficient stream :) [17:25:09 CEST] <DHE> that'll skyrocket the bitrate (or tank the quality) [17:25:26 CEST] <Yamakaja> Alright, another question: I'm currently looking for the best format to stream over the network with the latency reduced as much as possible over a possibly lossy connection (udp) at semi-reasonable bitrates ~10-20mbps max [17:25:29 CEST] <DHE> for mpeg2 I believe 15-18 is the sort of optimal value [17:25:59 CEST] <DHE> the quasi-standard is mpegts in CBR mode. the catch is getting the parameters right for it [17:26:30 CEST] <Mavrik> yp [17:27:34 CEST] <Yamakaja> Lol, halved my bitrate by setting the value to 18 [17:27:47 CEST] <DHE> I do this quite a bit, but I also have custom patches to libavformat/udp.c [17:27:57 CEST] <Mavrik> Custom patches for? [17:28:09 CEST] <DHE> the UDP transmission driver in ffmpeg [17:28:20 CEST] <Yamakaja> To decrease latency? [17:28:40 CEST] <DHE> yeah. I enable realtime scheduling, and use file capabilities to let ffmpeg use it (plus other things) [17:30:03 CEST] <JEEB> yea I think that required root on some level? [17:30:17 CEST] <JEEB> to get the cap [17:30:33 CEST] <DHE> yes and no. you can get exactly the cap necessary (cap_sys_nice) without making the process setuid root, or giving other caps [17:30:46 CEST] <DHE> setcap cap_sys_admin+ep /usr/local/bin/ffmpeg [17:31:03 CEST] <DHE> setcap cap_net_bind_service,cap_sys_admin+ep /usr/local/bin/ffmpeg # for also being able to bind to low port numbers. needed for my multicast setup. :( [17:31:34 CEST] <JEEB> yea I'm happy that low port #s haven't been used in my case yet :) [17:31:55 CEST] <DHE> yeah I don't have that luxury. :( [17:32:03 CEST] <Yamakaja> Any hints as to how i should be configuring mpegts? [17:32:23 CEST] <DHE> Yamakaja: Select a bitrate that is suitable and will never be exceeded. Let's say 17 megabits for the sake of this example. [17:32:27 CEST] <JEEB> what is the use case? usually you set a muxrtae [17:32:42 CEST] <JEEB> bitrate is then avoption for udp [17:32:46 CEST] <DHE> ffmpeg -i <input> <encodingopts> -muxrate 17M -bitrate 17M -pkt_size 1316 -f mpegts udp://239.0.0.1:5000 [17:33:29 CEST] <DHE> if you select too low a speed, you'll get PCR errors from ffmpeg [17:34:26 CEST] <DHE> I have a patch to my udp driver that does realtime scheduling on the transmission thread. without it you will definitely want to set -burst_bits 50000 or higher [17:34:44 CEST] <DHE> even with realtime scheduling I find I need 10000 or more [17:34:51 CEST] <Mavrik> Does ffmpeg still cause a huge amount of pcr jitter if you do muxrate? [17:35:03 CEST] <Mavrik> Last I check the code was rather funny and not quite correct [17:35:07 CEST] <DHE> actually forcing CBR mode basically fixes PCR issues [17:35:27 CEST] <Mavrik> CBR on MPEG-2? [17:35:35 CEST] <Mavrik> I was only using it for H.264 [17:35:36 CEST] <Yamakaja> I'm a bit confused as to how parameters are assigned to the different "targets" - everything before (since the "target" before that) a "-i", "-c" and "-f" will be applied? [17:35:51 CEST] <DHE> no, CBR on the mpegts muxer affects its PCR generating behaviour [17:37:21 CEST] <Yamakaja> I still have pretty much exactly one second of latency in my stream (I'm playing it with vlc with caching set to 50ms) [17:37:31 CEST] <Yamakaja> Any ideas as to what i could be doing wrong? [18:21:37 CEST] <DHE> fwiw https://github.com/DeHackEd/FFmpeg/commits/local this is my local patch set. I plan to offer one or two for ffmpeg merging, but most not [18:59:22 CEST] <rjp421> on linux, can i screen grab a 320x240 area around the cursor? also, can i scale the output to 320x240 keeping aspect ratio of the source (which is not always the same)? current command 'ffmpeg -f x11grab -r 8 -s 1600x900 -i :0.0+0,0 -vcodec rawvideo -pix_fmt yuv420p -threads 0 -f v4l2 /dev/video2' [19:01:20 CEST] <DHE> display aspect ratio is preserved by skewing the sample aspect ratio unless overridden manually when resizing video [19:20:18 CEST] <TikityTik> is there a way to quickly get an estimate for what crf values for libvpx will get you under a filesize? I thought of adjusting cpu-used and quality but the filesize is way too different i think [19:24:01 CEST] <TikityTik> also how do you get timestamps with minutes like 8:30 to work with the bottom solution for this? https://trac.ffmpeg.org/ticket/2067 [19:24:14 CEST] <TikityTik> is there a better work around? [19:29:52 CEST] <cehoyos> If you want a filesize, why don't you pass a bitrate? [19:30:31 CEST] <TikityTik> because i want to maximize quality and constrained bitrate kind of ruins that [19:31:42 CEST] <cehoyos> Your question above sounds to me as if you have exactly this constraint. If you don't have it, you should choose the quality you want. [19:34:41 CEST] <TikityTik> cehoyos: how would i constrain it properly in libvpx vp8? [19:36:06 CEST] <furq> in theory you want 2-pass abr (-b:v and nothing else) [19:36:17 CEST] <furq> idk how well that works in practice with vpx though [19:36:19 CEST] <cehoyos> Do you mean that libvpx-vp8 does not support abr? [19:36:28 CEST] <cehoyos> (I haven't played with it for some time.) [19:37:23 CEST] <cehoyos> I certainly hope that 2-pass abr works perfectly with libvpx (if not, it would say a lot about the encoder's quality), the question is if one-pass abr works to some degree... [19:37:37 CEST] <TikityTik> I found i had better quality just playing around with pure crf alone [19:37:39 CEST] <furq> there's not much more to be said about the quality of libvpx [19:37:46 CEST] <furq> particularly its rate control [19:37:54 CEST] <TikityTik> better results i mean [19:39:27 CEST] <cehoyos> Ok, I tested 2-pass, it reached two bitrates that I tested to ~0.5% (which is good afair) [19:39:56 CEST] <furq> iirc it has issues with undershooting [19:40:11 CEST] <cehoyos> One-pass also works fine here. [19:40:21 CEST] <TikityTik> so 2 pass is pointless? [19:40:51 CEST] <TikityTik> cehoyos: can you show me what command you used for your test? [19:40:57 CEST] <cehoyos> No, it overshot [19:41:11 CEST] <cehoyos> ffmpeg -i input -pass n -b:v xxx -y out.mkv [19:41:35 CEST] <cehoyos> 2-pass is definitely not pointless, it just takes longer [19:42:00 CEST] <TikityTik> hmm, i assumed crf would be vastly superior to abr [19:42:02 CEST] <furq> iirc some encoder features are only enabled on second pass [19:42:06 CEST] <furq> so it's especially not pointless for vpx [19:42:28 CEST] <furq> with something like x264 the first pass pretty much just works out the right crf value for the second pass [19:42:33 CEST] <TikityTik> because i assume abr would use a lot of bitrate for still scenes and not enough bitrate for fast moving scenes [19:42:35 CEST] <cehoyos> Especially the feature of "encoding" is only enabled on second pass;-) [19:42:38 CEST] <TikityTik> if someone can correct me [19:42:49 CEST] <furq> TikityTik: that's what one-pass abr will do [19:43:00 CEST] <cehoyos> No, this is exactly what it does not (contrary to constant quality) [19:43:02 CEST] <TikityTik> interesting [19:43:23 CEST] <furq> the whole point of two-pass is that it will analyse the whole video and figure out where it can allocate more rate and still hit the target rate [19:43:54 CEST] <TikityTik> so to avoid overshooting and undershooting i'm guessing just specifying -b:v for 2-pass won't cut it? you need min and max rate specified too? [19:44:03 CEST] <cehoyos> Even for one-pass abr, it shouldn't do it (and it didn't in my tests, it undershoots for the credits) [19:44:43 CEST] <furq> it'll make worse decisions though [19:48:34 CEST] <cehoyos> Yes, there is no free lunch;-) [19:49:16 CEST] <kepstin> yeah, the goal of abr (without any other limits) is that the average over the whole video hits a certain target. [19:50:31 CEST] <furq> https://github.com/deterenkelt/Nadeshiko/wiki/Pitfalls-in-VP9 [19:50:39 CEST] <furq> i don't know how accurate this is but it's reinforcing my decision to just stick with x264 [19:51:52 CEST] <kepstin> i kinda wish xpv8 had become a thing [19:53:15 CEST] <furq> whatever happened to x262 [19:54:09 CEST] <kepstin> i think it ... technically works? but is basically dead in terms of development [19:54:24 CEST] <furq> did it ever get good enough to be worth using [19:54:53 CEST] <kepstin> no idea [20:04:23 CEST] <TikityTik> thanks for the help guys [20:15:37 CEST] <kepstin> that pitfalls doc is out of date in one respect, you can use -row-mt in recent libvpx versions and the multithreading is less terrible. [20:19:13 CEST] <kepstin> everything else tho... it's an encoder developed by google for google use cases :/ [20:23:16 CEST] <cehoyos> I expect them to accept patches just as we do... [21:38:25 CEST] <rjp421> on linux, can i screen grab a 320x240 area around the cursor? also, can i scale the output to 320x240 keeping aspect ratio of the source (which is not always the same)? current command 'ffmpeg -f x11grab -r 8 -s 1600x900 -i :0.0+0,0 -vcodec rawvideo -pix_fmt yuv420p -threads 0 -f v4l2 /dev/video2' [21:54:10 CEST] <Ke> sal [21:54:26 CEST] <Ke> nvm [21:56:12 CEST] <rnderr> \o/ [21:59:00 CEST] Last message repeated 1 time(s). [21:59:26 CEST] <relaxed> rjp421: try, ffmpeg -video_size 320x240 -framerate 8 -follow_mouse centered -show_region 1 -f x11grab -i :0.0 ... [22:00:11 CEST] <relaxed> the output will be 320x240 [22:04:40 CEST] <TikityTik> how do i make sure libvpx abr undershoots my target filesize without resorting to limiting maxrate? [22:05:04 CEST] <TikityTik> i'm getting like 100 kB off mark but even when i calculate a bitrate by taking away a 100 kB, it still overshoots [22:05:19 CEST] <TikityTik> not sure if it's abr or vbr when i just specify -b:v [22:05:37 CEST] <TikityTik> and i'm using 2 pass abr [22:12:19 CEST] <rjp421> relaxed, cool thanks [22:14:26 CEST] <rjp421> it works! [23:14:25 CEST] <TikityTik> anyone know how to avoid overshooting by 100 kB? [23:14:30 CEST] <TikityTik> for my question? [23:21:21 CEST] <another> I'm curious: What is your usecase that you need such accurate rate control? [23:22:04 CEST] <TikityTik> file limits could be 8 MB, or such, and I wanted to push out the max quality for the file size limit [00:00:00 CEST] --- Tue Apr 30 2019

1 0

ffmpeg-devel.log.20190428
by burek 29 Apr '19

29 Apr '19

[10:24:41 CEST] <thardin> hmmm [10:24:53 CEST] <thardin> is there a particular reason why av_clip_uint8_c() assumes 32-bit int? [10:34:55 CEST] <durandal_1707> speed [10:36:29 CEST] <thardin> it just seems it's supposed to do sign extension into the lowest 8 bits. but that won't work right for say 0x80000000 on 64-bit systems [10:36:47 CEST] <thardin> would return 1 instead of 255 [10:39:35 CEST] <thardin> and presumably shifting by 31 takes the same time as shifting by 63 [10:53:19 CEST] <thardin> derp, it's only long that is 64-bit on 64-bit [10:53:38 CEST] <thardin> in gcc at least [10:59:09 CEST] <cone-189> ffmpeg 03Paul B Mahol 07master:d5b2458f4695: avfilter/vf_lut3d: fix range domain processing for .cube format [10:59:09 CEST] <cone-189> ffmpeg 03Paul B Mahol 07master:5840a7f8a6d7: avfilter/vf_lut3d: increase MAX_LEVEL [11:06:59 CEST] <nevcairiel> this is true, int is 32-bit everywhere, long is best avoided since it changes on different archs [11:07:57 CEST] <nevcairiel> (and also doesnt change consistently, on windows long is always 32-bit, even on 64-bit systems, on linux it is 64-bit on 64-bit systems, etc - in short, avoid long :D) [11:10:54 CEST] <cone-189> ffmpeg 03Paul B Mahol 07master:ea80af659c60: avcodec/scpr: avoid using uninitialized value [14:20:22 CEST] <cehoyos> nevcairiel: Iiuc, toolchain=msvc defaults to "hardened" because GS is default for cc.exe, shouldn't we change this to "GS-" as default and "GS" for hardened? [14:23:24 CEST] <nevcairiel> we should prefer default flags as much as possible imho [14:23:33 CEST] <nevcairiel> if the compiler thinks this should be on by default, we shouldnt turn it off [14:23:54 CEST] <cehoyos> The option exists... [14:24:07 CEST] <cehoyos> And imo, this breaks performance comparisons [14:24:34 CEST] <cehoyos> We default to "not hardened", no= [14:24:36 CEST] <cehoyos> ? [14:25:13 CEST] <JEEB> do we? I thought gcc/clang also harden by default (if we're talking about stuff like spectre etc mitigation) and we don't override that? unless we're talking about some other hardening. [14:25:17 CEST] <nevcairiel> on gcc you have to explicitly enable it, and it potentially does much more then simple buffer security cookies [14:25:26 CEST] <JEEB> ah, ok. so gcc doesn't :) [14:25:36 CEST] <nevcairiel> it probably does some thing by default as well [14:25:45 CEST] <nevcairiel> but it certainly has some additional hardening o ptions [14:25:56 CEST] <JEEB> yea, you have various additional generic hardening options [14:26:04 CEST] <cehoyos> Are there other hardening / non-hardening options for msvc except GS? [14:26:04 CEST] <JEEB> which are unrelated to the CPU issues [14:26:37 CEST] <cehoyos> gcc defaults to no security features, no? [14:29:01 CEST] <nevcairiel> which gcc features are enabled by default can also vary depending on how it was build [14:29:10 CEST] <nevcairiel> ie. it can change in different distributions [14:29:53 CEST] <nevcairiel> In any case I'm of the opinion that we shouldn't disable default security features unless specifically asked to [14:31:02 CEST] <nevcairiel> msvc performance comparisons are "unfair" anyway because the inline asm syntax we use is incompatible [14:32:23 CEST] <nevcairiel> and there is definitely more hardening options for msvc, spectre stuff for example, but also some additional options that I don't exactly know how to fully use [14:33:14 CEST] <JEEB> yea, I'm generally of the opinion that not overriding defaults is probably a good idea. you then need to keep tabs on when things change in different ways. just like in theory we should be keeping an eye on that autovectorization thing we disable in some compilers [14:47:18 CEST] <cehoyos> I am not sure there are spectre options: Aren't there spectre-compilers? [14:47:38 CEST] <BtbN> There is a whole different msvc runtime you can target for spectre hardening. [14:47:43 CEST] <nevcairiel> its /Qspectre for cl.exe [14:47:54 CEST] <cehoyos> And how does the user ask FFmpeg to compile without hardening with msvc? I thought that is exactly what "./configure --toolchain=msvc" would do. [14:48:06 CEST] <nevcairiel> the hardened library is basically the default library compiled with t hat option [14:48:16 CEST] <cehoyos> So we should add "Qspectre" for hardening [14:49:01 CEST] <cehoyos> JEEB: I am not sure you understand: FFmpeg defaults to non-hardening, but the user cannot disable hardening for msvc. [14:49:24 CEST] <nevcairiel> this isnt really "hardening" as it is in gcc [14:49:32 CEST] <nevcairiel> its a very cheap protection against buffer overflows [14:49:39 CEST] <nevcairiel> hardening in gcc is typically far more expensive options [14:50:09 CEST] <JEEB> I remember giving cl.exe parameters with env vars (because I remember having issues with extra-cflags/ldflags back in the day) [14:50:10 CEST] <cehoyos> The description sounds similar to gcc stack protection [14:50:41 CEST] <JEEB> so if you need to add "GS-" somewhere, wouldn't that make it possible? [14:50:48 CEST] <JEEB> although I don't remember the exact env vars [14:51:16 CEST] <nevcairiel> you can always build with extra-cflags if you so desire [14:51:28 CEST] <nevcairiel> re spectre: we dont add the gcc options for spectre either [14:52:15 CEST] <nevcairiel> these things are very specialized and should probably be entirely controlled by the user - thats what extra cflags is for [14:52:15 CEST] <JEEB> yea, not sure why I had problems with extra-*flags back in the day. been a while since I last touched cl.exe building [14:52:36 CEST] <JEEB> I think it was mostly LIBS or so for me [14:52:43 CEST] <cehoyos> JEEB: We tell our users not to mess with compiler options (they break compilation with Gentoo) [14:53:09 CEST] <cehoyos> As user you cannot control them because of how configure works. [14:55:24 CEST] <JEEB> I don't think this is as black/white as that to be honest. there are legitimate cases where you might have to override some compiler/linker flags. as a generic user thing, yes. "don't mess with the options unless you know you have to" [14:55:47 CEST] <nevcairiel> if you use gentoo and dont understand compiler flags, you are doing it wrong anyway [22:08:47 CEST] <cone-166> ffmpeg 03Marton Balint 07master:a5136426a732: avformat/mxfdec: rework mxf_essence_container_end [22:08:47 CEST] <cone-166> ffmpeg 03Marton Balint 07master:5b6960f955a8: avformat/mxfdec: guess wrapping of tracks by other tracks with the same body sid [22:08:47 CEST] <cone-166> ffmpeg 03Marton Balint 07master:fc15e8306f84: avformat/mxfdec: take into account run-in in find_partition_by_offset [22:08:47 CEST] <cone-166> ffmpeg 03Marton Balint 07master:3dee6c09970d: avformat/mxfdec: fix and enhance RIP KLV length checks [22:34:23 CEST] <durandal_1707> we should vote first should we vote at all [23:13:43 CEST] <kierank> durandal_1707: so many people who have not done anything for years [23:17:28 CEST] <durandal_1707> kierank: i doubt they will cast a vote [23:42:50 CEST] <ubitux> still no decision taken on forward declaration and merging all the libs? [23:43:02 CEST] <ubitux> damn, why did i go away for? :( [23:45:21 CEST] <durandal_1707> ubitux: what happened? [23:47:08 CEST] <jamrial> ubitux: there was a vote for that? :S [23:48:25 CEST] <ubitux> durandal_1707: nothing it seems :( [23:48:37 CEST] <ubitux> jamrial: i dunno, maybe it could have happened [23:48:46 CEST] <j-b> merging all the libs? why? [23:49:04 CEST] <ubitux> j-b: ease code sharing and inter-lib dependencies [23:49:22 CEST] <ubitux> the question was raised quite a few times [23:49:51 CEST] <j-b> I find this idea a bit weird, every time this is raised, tbh. [23:50:42 CEST] <j-b> I would prefer more splitting, tbh :) [23:53:28 CEST] <ubitux> as a user, sure, but as a developer, it makes progress much more complex [23:54:08 CEST] <ubitux> that said, i'd rather push on the forward declaration thing currently [23:54:34 CEST] <ubitux> 'been working on a codebase where this is allowed for a while now, and i must admit it often makes the code so much better... [23:54:56 CEST] <j-b> I agree on the fwd declarations [23:55:28 CEST] <j-b> as for the splitting, not really, because I'm afraid it will allow more "dirty hacks" [23:55:40 CEST] <j-b> especially with libavfilter and libavdevice. [23:56:02 CEST] <j-b> Why does Marton focus on GPLv3 while most of FFmpeg is LGPLv2.1 or later? [23:57:18 CEST] <BtbN> I feel like we need a vote on how the Project wants to interpret the license first of all... [23:57:20 CEST] <jkqxz> Can we please not use any sort of GPL definition anyway? People don't generally agree what it means, so there will just be more argument later. [23:57:55 CEST] <j-b> jkqxz: I agree on that. [23:58:05 CEST] <j-b> The GPL is too verbose and not preceise enough [23:58:55 CEST] <jkqxz> It's not relevant to this question. The GPL definition can affect people distributing binaries, but it's orthogonal to the current question of what should be included in the source code. [00:00:00 CEST] --- Mon Apr 29 2019

1 0

ffmpeg.log.20190428
by burek 29 Apr '19

29 Apr '19

[00:51:09 CEST] <snap1> everybody: did you know that intel system does not support high-density ram: where AMD system does [01:27:22 CEST] <irwiss> anyone knows if api users can somehow get to the MiscFlags in hwcontext_d3d11va.c without a recompile? I'd like to set shared flag so i can try accessing the texture array from another context, but can't figure out where to grab the knob to tune it or if it's just hardcoded to have no flags https://ffmpeg.org/doxygen/4.1/hwcontext__d3d11va_8c_sourc [01:27:22 CEST] <irwiss> e.html#l00256 [01:29:20 CEST] <irwiss> welp, botched the link, the flags are set around line 256, i'm wondering if i can somehow change the pointer to d3d11va_frames_init at the bottom to point at my function that'll set the flag [04:53:36 CEST] <Humanoid> Why doesn't my ffmpeg show the language of the streams? When I use "ffprobe -show_entries stream_tags" I get nothing. [05:01:04 CEST] <Humanoid> It happens when I ffprobe a bluray disc. [05:44:38 CEST] <snap1> if OLED monitor were same price as LCD monitor, is it better to get OLED monitor? [09:43:19 CEST] <Jolein> the mb_size default is 16 but what gives better quality lowering or increasing the value and if so by how much is still obtainable ? [09:43:29 CEST] <Jolein> for minterpolation [09:58:58 CEST] <durandal_1707> Jolein: depends on many factors [09:59:35 CEST] <Jolein> durandal_1707 i am just testing out all the settings available but dont realy understand the mb_size value [09:59:41 CEST] <Jolein> like what does it do [10:00:48 CEST] <durandal_1707> Jolein: it is macroblock size in pixels [10:01:02 CEST] <Jolein> would lower be better or higher ? [10:01:22 CEST] <Jolein> or is it not realy important? [10:03:08 CEST] <durandal_1707> how do i know, i dunno with what video you are playing with [10:03:30 CEST] <Jolein> what do you mean ? [10:06:19 CEST] <durandal_1707> Jolein: it depends on input video [10:07:04 CEST] <Jolein> input video is a 1080p mkv file h.264 [10:08:18 CEST] <durandal_1707> i mean actual PIXELS [10:10:35 CEST] <Jolein> i apreciate you are tying to help but i dont realy understand what you are asking here [10:10:44 CEST] <durandal_1707> bigger block size make filtering faster for very high resolution [10:10:52 CEST] <der_richter> snap1 depends, for a 'short' time it will definitely be better in output quality, till you get burn ins [10:11:28 CEST] <snap1> ok [10:11:33 CEST] <durandal_1707> Jolein: when you describe all pixels you see in your video, than i can help you... [10:12:42 CEST] <Jolein> well the first pixel is black [10:12:44 CEST] <der_richter> snap1 static content is an OLED killer, and as a computer monitor it would need to show a lot of it [10:13:13 CEST] <Jolein> the second pixel is #e97b9e [10:13:34 CEST] <Jolein> the third pixel is #e97b90 [10:13:50 CEST] <durandal_1707> lol [10:14:00 CEST] <Jolein> :p [10:14:10 CEST] <Jolein> you want the total pixels per frame ? [10:15:07 CEST] <durandal_1707> no, you can not explain it in words [10:15:15 CEST] <Jolein> you want the video ? [10:16:05 CEST] <durandal_1707> only if it is anime [10:17:11 CEST] <Jolein> well its not anime [10:17:19 CEST] <Jolein> its a 9s test clip [10:17:29 CEST] <Jolein> you can download it straight if you want to [10:19:44 CEST] <Jolein> well if you have an ftp client [11:38:52 CEST] <MatthewAllan93> Hey is there anyway in FFMPEG to set the language of the chapters in the output file from the input file? [15:36:20 CEST] <XLS202> Hey, I have problems using FFMPEG as a restreamer for Twitch. Every time OBS looses a few frames the connection to twitch crashes.. not completly but unwachtable. [15:38:03 CEST] <BtbN> You'll need to explain your setup more. You are using nginx I assume? [15:40:50 CEST] <XLS202> Not exactly, i will paste my commands in a pastebin. [15:42:56 CEST] <XLS202> https://pastebin.com/7p1V74xb [15:43:15 CEST] <XLS202> I could als provide the log snippet then the problem appears. [15:43:55 CEST] <BtbN> Use nginx, not the rtmp "server" in ffmpeg. [15:45:30 CEST] <XLS202> And this would help with such problems? [15:49:26 CEST] <XLS202> And should i use the rtmp Module from sergey-dryabzhinsky or from arut? [15:49:38 CEST] <XLS202> Or do you mean something else [15:50:03 CEST] <BtbN> There is only one rtmp module for nginx, most distributions even packaged it by now. [15:52:03 CEST] <XLS202> Okay thank you for your help :) I will look into it. [16:15:41 CEST] <MatthewAllan93> Hey is there anyway in FFMPEG to set the language of the chapters in the output file from the input file? [16:58:04 CEST] <GuiToris> hey, I have a little problem. I exported my video into pngs but with alpha channel and I created a video with ffmpeg -i %d.png output.mp4 but because of the alpha channels fade in and out aren't visible. What can I do? [16:58:13 CEST] <GuiToris> do I have to reexport the video without alpha? [17:21:55 CEST] <cehoyos> GuiToris: Please use pastebin to show us your command line including complete, uncut console output [17:26:50 CEST] <MatthewAllan93> Just wondered because I was converting a file that had chapters in it, the language prefix in mediainfo didn't display properly but the chapters were there. [17:28:05 CEST] <cehoyos> Feel free to post the FFmpeg command line you used together with the complete, uncut console output. [17:41:07 CEST] <GuiToris> cehoyos, that was the entire command [17:41:18 CEST] <GuiToris> I didn't use any filters [17:41:34 CEST] <GuiToris> ffmpeg -i filename_%3d.png output.mp4 [17:41:51 CEST] <pink_mist> GuiToris: you're forgetting the console output. all of it. [17:42:00 CEST] <pink_mist> please don't paste it in the channel though. [17:42:02 CEST] <pink_mist> use a paste site [17:42:06 CEST] <GuiToris> get it [17:46:28 CEST] <GuiToris> cehoyos, pink_mist https://bpaste.net/show/2657aae62888 [17:47:26 CEST] <GuiToris> I created a fade in but it's not visible here [17:47:38 CEST] <GuiToris> the png files are transparent there [17:48:16 CEST] <GuiToris> it's weird because the first image is completely transparent, yet I see the full image here in the video [17:51:00 CEST] <cehoyos> That's because h264 does not support transparency (and newer FFplay plays a trick on you, implying that there is some "fading" where there is none). [17:51:21 CEST] <cehoyos> You have to overlay your video over some background of your choice, for example the "color" filter (that defaults to black) [17:53:34 CEST] <GuiToris> can you tell me the actual code of that filter? [17:53:50 CEST] <GuiToris> I've never used one, and I wouldn't like to mess this up [18:01:35 CEST] <de-facto> GuiToris, i am new to ffmpeg, but i think its possible to use chromakey or lumakey (e.g. lumakey=16:4:4 for everything black) to set transparency then use overlay=x=<coord>:y=<coord> to put that on a background video [18:03:39 CEST] <cehoyos> ffmpeg -i input -vf color[c],[c][0:0]overlay out.mov [18:05:35 CEST] <cehoyos> ffmpeg -i FULL_%4d.png -t 3 -vf color=s=hd1080[c],[c][0:0]overlay out.mov [18:06:06 CEST] <cehoyos> As said, the color filter defaults to black, but you can choose any background color [18:11:05 CEST] <GuiToris> cehoyos, what's the difference between color[c] and color=s=hd1080[c] [18:16:55 CEST] <GuiToris> cehoyos, the second one works well [18:16:56 CEST] <cehoyos> color defaults to 320x240 but I think you want 1920x1080 [18:17:21 CEST] <GuiToris> yes, that's what I wanted thank you so much [18:17:41 CEST] <GuiToris> the first one was really small indeed [20:28:02 CEST] <hedgehog90> Hi, I've got a RGBA PNG sequence (a 3D animation, 24fps, 9 minutes long) and I want to convert it to h264 (YUV colorspace) so I can upload it to youtube and other video hosting sites. I've done this before many times, but always experience a certain amount of color banding, especially with glowing lights in a dark environment. I've tried sws_dither, the dither filter and the deband filter, I've tried all sorts, but nothing seems to work that well, [20:28:02 CEST] <hedgehog90> considering I want to preserve the quality of my animation as best as possible (~40mbps). Any guidance on this would be much appreciated! [20:31:42 CEST] <JEEB> hedgehog90: try encoding losslessly first and seeing if the issue is in the colorspace conversions or not [20:31:53 CEST] <JEEB> or if it's the lossy compression if that's what you're doing [20:32:04 CEST] <JEEB> note: youtube does support lossless ingest just fine [20:32:07 CEST] <furq> try 4:4:4 and 4:2:0 as well [20:32:14 CEST] <hedgehog90> It's lossless RGB encoded HuffYUV [20:32:15 CEST] <JEEB> (although of course youtube will derp it up) [20:33:12 CEST] <hedgehog90> I'm well aware JEEB, but there are other sites with less derpifying video processing settings. [20:33:20 CEST] <JEEB> yup [20:33:24 CEST] <JEEB> thank goodness for that :P [20:33:26 CEST] <hedgehog90> and i want to get it looking perfect as possible [20:33:44 CEST] <JEEB> anyways, just noting that you should attempt to limit to one or so scene which you know has your issue [20:33:51 CEST] <JEEB> and then test encoding losslessly [20:33:58 CEST] <hedgehog90> Fortunately it's the beginning scene [20:34:08 CEST] <JEEB> to see if it's the encoding, or the actual colorspace conversion [20:34:22 CEST] <JEEB> with libx264 you can just set -q:v 0 for lossless [20:34:27 CEST] <hedgehog90> and yes, encoding with h264 crf 0 produces banding [20:34:30 CEST] <JEEB> ok [20:35:17 CEST] <JEEB> I would then compare it to zscale's conversion, which should probably be something like -vf "scale,format=bgrb,zscale,format=yuv420p" [20:35:24 CEST] <JEEB> I /think/ that works, but I didn't just test it [20:35:33 CEST] <JEEB> also it requires you to have FFmpeg built with the zimg library [20:35:36 CEST] <JEEB> https://github.com/sekrit-twc/zimg [20:35:46 CEST] <hedgehog90> I'll give that a go [20:36:01 CEST] <JEEB> not sure if the initial scale is needed [20:36:10 CEST] <JEEB> the format should have auto-insertion there if needed [20:36:34 CEST] <hedgehog90> Is there a build with zimg that you could provide? [20:36:36 CEST] <JEEB> also I think format needed pix_fmts parameter [20:36:42 CEST] <JEEB> nope [20:36:54 CEST] <JEEB> depending on the OS there might be some people doing it [20:36:59 CEST] <JEEB> f.ex. I think on windows zeranoe does it? [20:37:07 CEST] <hedgehog90> windows64 bit [20:37:31 CEST] <JEEB> note that I do not endorse his builds, but they are some of which people seem to be using [20:37:40 CEST] <JEEB> https://ffmpeg.zeranoe.com/builds/readme/win64/static/ffmpeg-20190427-80193… [20:37:43 CEST] <JEEB> and it seems to have zimg there [20:37:51 CEST] <hedgehog90> thanks [20:38:40 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#format-1 [20:38:46 CEST] <JEEB> so yes, the format filter takes in pix_fmts [20:39:01 CEST] <JEEB> thus it's format=pix_fmts=THING [20:39:05 CEST] <hedgehog90> -pix_fmt yuv420p ? [20:39:05 CEST] <JEEB> and not just format=THING [20:39:19 CEST] <JEEB> hedgehog90: that's probably inserting something similar at the end [20:39:24 CEST] <JEEB> but I like to have it in the filter chain [20:39:50 CEST] <hedgehog90> sorry, could you provide it in full commandline terms? [20:39:53 CEST] <JEEB> -vf "scale,format=pix_fmts=bgrb,zscale,format=pix_fmts=yuv420p" [20:39:56 CEST] <JEEB> so something like this? [20:40:02 CEST] <JEEB> not sure if the initial scale is needed [20:40:07 CEST] <hedgehog90> ok, trying it now [20:40:28 CEST] <JEEB> also zscale might need you to say that "hey, I want BT.709 output" [20:41:23 CEST] <hedgehog90> oh - another thing, my lossless video is 24fps according to mediainfo (as it should be) but when I try converting it with ffmpeg or handbrake, I need to specify the framerate because it assumes something wacky like 24.407 [20:41:36 CEST] <JEEB> it shouldn't change the rate [20:41:43 CEST] <JEEB> you can test this with ffprobe or so [20:41:48 CEST] <JEEB> unless you add some filters [20:41:48 CEST] <hedgehog90> Well, right. It's bizarre. [20:42:19 CEST] <JEEB> anyways, FFmpeg itself doesn't really work with frame rates in general [20:42:30 CEST] <JEEB> exceptions are just containers that only have a frame rate field like AVI :P [20:42:41 CEST] <hedgehog90> Could I maybe send you the first few seconds so you can have a look? I think my video editor has produced something that confuses converters somehow [20:42:41 CEST] <JEEB> although even with that FFmpeg just calculates the DTS/PTS [20:43:30 CEST] <JEEB> if the thing happens with just that someone could take a look probably [20:43:44 CEST] <JEEB> at late evening in Sunday my care levels are getting lower by the minute to be honest 8) [20:43:48 CEST] <JEEB> *on a Sunday [20:45:33 CEST] <hedgehog90> the file's very big so I've uploaded just the first second: https://drive.google.com/file/d/1nfaqQQlL028oT0N2ruXmcC3T8Q90rf7K/view?usp=… [20:45:58 CEST] <hedgehog90> It comes out as 24.42fps with ffmpeg and other converters [20:46:16 CEST] <hedgehog90> but mediainfo says 24fps (which it is) [20:47:52 CEST] <hedgehog90> "Invalid pixel format 'bgrb'" [20:47:59 CEST] <JEEB> bgrp [20:48:07 CEST] <JEEB> pretty sure I got that right... [20:48:08 CEST] <hedgehog90> ah ok [20:48:32 CEST] <hedgehog90> Invalid pixel format 'bgrp' :) [20:48:52 CEST] <JEEB> o_O [20:49:18 CEST] <JEEB> gbrp I guess [20:49:24 CEST] <JEEB> got it slightly wrong [20:49:45 CEST] <hedgehog90> code 3074: no path between colorspaces [20:49:45 CEST] <hedgehog90> Error while filtering: Generic error in an external library [20:49:58 CEST] <JEEB> ok, so it needs the output definition [20:50:05 CEST] <JEEB> zscale is fussy because it doesn't want to guess :) [20:50:41 CEST] <hedgehog90> scale=1920:1080? [20:51:03 CEST] <JEEB> nah [20:51:11 CEST] <JEEB> zscale=m=709 [20:51:20 CEST] <JEEB> just add the matrix there, if I recall it correctly [20:51:29 CEST] <JEEB> either matrix or primaries :) [20:51:42 CEST] <hedgehog90> ok it's going! :) [20:52:02 CEST] <JEEB> a lot of systems just expect that if your input/output is HD, you want BT.709 [20:52:07 CEST] <JEEB> and if it's SD you want BT.601 [20:52:22 CEST] <JEEB> zimg is like "no, you *tell* me what you want" [20:53:55 CEST] <hedgehog90> hmm, honestly can't tell the slightest difference between the 2 :) [20:55:01 CEST] <hedgehog90> actually no, I see a small improvement tbf [20:56:51 CEST] <hedgehog90> I spoke too soon, comparing the 2 this is quite a bit better. [20:56:59 CEST] <hedgehog90> Many thanks :) [20:57:41 CEST] <hedgehog90> just to make sure, this isn't going to make it any less compatible than if i converted it with more vanilla settings / through handbrake? [20:57:48 CEST] <JEEB> no [20:58:01 CEST] <hedgehog90> because some sites kick up a stink if you dont comply to their standards [20:58:08 CEST] <JEEB> you've just switched the component which is handling the conversion from RGB to YCbCr [20:58:21 CEST] <JEEB> there's also dithering etc options [20:58:27 CEST] <JEEB> trying to figure out which is the default :) [20:59:10 CEST] <JEEB> ah, none [20:59:15 CEST] <JEEB> which is "round to nearest" [20:59:32 CEST] <hedgehog90> how would I add dithering then? [21:00:10 CEST] <JEEB> ":dither=VALUE" at the end of the zscale (filter options are separated with a :) [21:00:13 CEST] <JEEB> VALUE being one of [21:00:21 CEST] <JEEB> none,ordered,random,error_diffusion [21:01:52 CEST] <hedgehog90> which of those would you recommend?? [21:02:07 CEST] <JEEB> I have no idea to be honest :D [21:02:20 CEST] <hedgehog90> ok, I'll try them out :) [21:37:04 CEST] <mr_alpaca> if i want to crop a video losslessly, in the command, should "-c:v libx264 -preset veryslow -crf 0 -c:a copy" come before or after the "-filter:v [21:37:04 CEST] <mr_alpaca> "crop=1080:608:0:350"" part? [21:43:50 CEST] <furq> it makes no difference [21:43:54 CEST] <furq> filtering is always done before encoding [21:44:43 CEST] <mr_alpaca> i see [00:00:00 CEST] --- Mon Apr 29 2019

1 0

ffmpeg-devel.log.20190427
by burek 28 Apr '19

28 Apr '19

[00:03:03 CEST] <cone-150> ffmpeg 03Paul B Mahol 07master:bf15dcc5c8d8: avfilter/vf_stack: use time_base from framesync [00:06:59 CEST] <Lynne> durandal_1707: have you tested your chained opus patch with this stream? [00:07:01 CEST] <Lynne> http://listen.42fm.ru:8000/stealkill-opus [00:08:04 CEST] <Lynne> I also have a patch to fix chained opus decoding which works with both the test sample and that stream, just haven't cleaned it up to send it [00:10:33 CEST] <Lynne> I also made it check page CRCs to reduce errors, and because of how bad my other CRC patches were taken on the mailing list I didn't know whether to remove it or not [00:11:55 CEST] <durandal_1707> well CRC checking is not improving decoding much :) [00:13:04 CEST] <durandal_1707> Lynne: my patch produces same number of samples as opusdec tool but with some small artifacts, i dunno what is source of that one [00:14:11 CEST] <jamrial> durandal_1707: did you try decoding with libopus instead of the internal decoder? [00:15:53 CEST] <Lynne> the demuxer sets the preskip so it doesn't matter which one is used [00:16:20 CEST] <durandal_1707> jamrial: nope [00:16:56 CEST] <Lynne> durandal_1707: the source is a recent icecast version, that russian radio station is the only chained opus stream I've found [00:17:41 CEST] <Lynne> it was hard to get both it and the sample file to decode properly, I asked on #opus which one was incorrect but I wasn't told [00:24:04 CEST] <cone-150> ffmpeg 03Paul B Mahol 07master:c2f305ca17e3: avfilter: add audio soft clip filter [00:41:06 CEST] <durandal_1707> Lynne: what you use to play that stream? [00:57:11 CEST] <Lynne> durandal_1707: normal ffmpeg opus decoder, with my patch [00:57:53 CEST] <durandal_1707> Lynne: i mean ffplay/vlc/mpv ? [00:58:33 CEST] <Lynne> Oh, wget to a file, wait until there's a switch, then ffmpeg [01:17:54 CEST] <durandal_1707> Lynne: send your work/patch without unrelated stuff to ML [01:40:17 CEST] <cone-150> ffmpeg 03Lynne 07master:4b7166c9d57d: x86/opusdsp: replace loads with shuffles [09:50:11 CEST] <cone-138> ffmpeg 03Jun Zhao 07master:d6489ddb7a6c: lavf/hls: Remove HLSContext.strict_std_compliance field [12:48:10 CEST] <cone-138> ffmpeg 03Timo Rothenpieler 07master:23ed147e8fc2: avcodec/nvenc: only unregister input resources when absolutely needed [12:48:11 CEST] <cone-138> ffmpeg 03Timo Rothenpieler 07master:2e254bb89747: avcodec/nvenc: fix indentation [12:59:48 CEST] <cone-138> ffmpeg 03Paul B Mahol 07master:6347146e3d3d: avformat/subtitles: ignore extra '\r' at line endings [12:59:49 CEST] <cone-138> ffmpeg 03Paul B Mahol 07master:163bb087f81d: avformat/microdvddec: skip empty lines [13:26:50 CEST] <cehoyos> michaelni: The pgm regression has real-life effect afaict. [13:36:42 CEST] <michaelni> cehoyos, what pgm regression ? [13:43:40 CEST] <durandal_1707> michaelni: was it seriously coded in such a way that PGM is reparsed from start after each combine frame? [13:52:53 CEST] <cehoyos> michaelni:I sent an email to -devel after a pgm regression was reported on -user [13:53:35 CEST] <cehoyos> (I already wonder if you will be patient enough to test the actual slowdown...) [14:09:16 CEST] <michaelni> yes, thats messed up [14:13:51 CEST] <durandal_1707> michaelni: i have fix [14:14:49 CEST] <michaelni> i have too but didnt test yet [14:16:45 CEST] <durandal_1707> https://pastebin.com/JtRywy9C [14:39:08 CEST] <atomnuker1> durandal_1707: I've combined your patch and my patch - https://paste.ubuntu.com/p/jXnhYkC7vf/ [14:50:20 CEST] <durandal_1707> atomnuker1: is that some kind of joke? [14:51:19 CEST] <durandal_1707> atomnuker1: ah this is another thing, please state it when saying something [15:01:00 CEST] <durandal_1707> atomnuker1: there is still invalid argument erro on song switch [15:17:50 CEST] <durandal_1707> atomnuker1: also why we can not get full metadata update on song switch? [15:19:28 CEST] <durandal_1707> also for chained ogg, it would be best if each new component uses pts of last one, so seeking from one song to another one works - currently seeking works only in current song [15:23:32 CEST] <durandal_1707> atomnuker1: with your patch ffplay can _not_ seek in chained ogg+opus [15:33:33 CEST] <durandal_1707> Lynne: can you please show yours patch? [21:08:39 CEST] <durandal_1707> ubitux: so how to proceed regarding lut3d's LUT size? [21:12:07 CEST] <jamrial> durandal_1707: can you look at my scpr3 patch? [21:12:24 CEST] <durandal_1707> jamrial: i consider such changes very trivial [21:13:25 CEST] <jamrial> they are, but when it's not my code i usually prefer to not push without a review [21:14:31 CEST] <durandal_1707> is there player that can seek without issues in chained ogg? [21:15:39 CEST] <jamrial> foobar2000 i think can [21:15:55 CEST] <cone-252> ffmpeg 03James Almer 07master:938cb783d40a: avcodec/scpr3: add missing check for decode_value3() return value [21:34:06 CEST] <ubitux> durandal_1707: you can go for it if you think it's fine [21:35:27 CEST] <durandal_1707> i doubt that embeded users do 3D LUT [21:37:29 CEST] <ubitux> don't tell me what to do with my boards ;) [21:38:17 CEST] <durandal_1707> video of what size VGA or QCIF? [21:39:41 CEST] <durandal_1707> also i think doing indexes manually would give same code as it is currently? [22:25:29 CEST] <ubitux> i don't plan to use it, it was half of a joke [22:25:45 CEST] <ubitux> i believe gcc will do better offseting than us [22:25:50 CEST] <ubitux> but feel free to check [22:41:02 CEST] <cone-252> ffmpeg 03Michael Niedermayer 07master:9fc1031ac2e8: avcodec/pnm_parser: Remember the size of the image and do not reparse the header [22:41:03 CEST] <cone-252> ffmpeg 03Michael Niedermayer 07master:801939588999: avcodec/pnm_parser: Remember the length already scanned for ascii images [00:00:00 CEST] --- Sun Apr 28 2019

1 0

ffmpeg.log.20190427
by burek 28 Apr '19

28 Apr '19

[00:01:23 CEST] <de-facto> its the -t "${DURATION}" argument, -t 120 works, -t 30 kills OOM [00:01:59 CEST] <de-facto> what does -t mean? [00:02:28 CEST] <durandal_1707> man ffmpeg [00:19:21 CEST] <de-facto> ok i found the cause of the memory peak, but it does not make any sense to me: -t 30 gets killed (regardless of d=30 or d=120, -t 120 works: https://dpaste.de/5XDs [00:20:20 CEST] <de-facto> it seems like ffmpeg can't write moov atom for 30s video without more than 16 GB of memory. I have seen it working on 64GB machines today... [00:21:13 CEST] <durandal_1707> try another container to be sure [00:22:05 CEST] <furq> de-facto: the moov atom thing is just because ffmpeg is crashing [00:22:17 CEST] <furq> it doesn't write that until it's done muxing [00:22:37 CEST] <furq> or not crashing, getting oom killed [00:39:34 CEST] <de-facto> my internet service provider is causing problems, bad luck day... cant surf too much over mobile :/ [00:41:14 CEST] <de-facto> any idea why 120 seconds is fine but 30 seconds gets OOM killed? [00:42:29 CEST] <durandal_1707> de-facto: 120 seconds is enough to get back frames [00:42:39 CEST] <de-facto> they behave the same until ~28.5s encoding, i guess then the finalizing for the 30s video begins and it requests too much memory for some reason (in contrast 120 seconds it would not do that even at the end of 120s) [00:43:09 CEST] <durandal_1707> PTS-(3*DURATION) [00:43:20 CEST] <durandal_1707> 0-(3*30) [00:43:27 CEST] <durandal_1707> =-90 [00:43:53 CEST] <de-facto> PTS-(3*${DURATION})/(4*TB) [00:44:40 CEST] <de-facto> so it should be 3/4*30=22.5 [00:45:57 CEST] <de-facto> but yeah i have to tweak that anyhow, just wanted to find out the reason before [00:46:45 CEST] <furq> some filter's buffer is going nuts [00:46:49 CEST] <furq> i couldn't tell you for sure which one or why [00:47:01 CEST] <furq> probably one of the overlays [00:47:17 CEST] <furq> if it was loop/setpts then i'd expect increasing the pts offset would make the problem worse [00:47:49 CEST] <furq> i guess maybe try using pad and xstack instead of overlay [00:53:08 CEST] <durandal_1707> furq: xstack does not need pad [00:54:40 CEST] <furq> the videos are all the same size and he's putting one in each corner with gaps [00:54:52 CEST] <furq> so either i'm reading the filter docs wrong or he needs to pad them [00:57:29 CEST] <durandal_1707> furq: no padding is needed for xstack if colorspace is rgb [00:57:35 CEST] <de-facto> its like a "cross" around the background (1600x1200) center: four VGA videos rotated (0, 90, 180, 270 degree) [01:02:09 CEST] <de-facto> i cant surf right now, my internet is broken :/ [01:09:57 CEST] <de-facto> loop=1 makes it kinda work with 30s, there is still a little memory peak at the end but its much better [01:43:37 CEST] <snap1> i just learned something today: did you know intel system does not support high-density ram: where AMD system does [01:44:54 CEST] <BtbN> Are you talking Registered vs. Non-Registered? [01:45:05 CEST] <BtbN> Never heard the term high density before. [01:47:08 CEST] <snap1> non registered [01:47:50 CEST] <BtbN> Single vs. Dual Rank then? [01:48:24 CEST] <snap1> no [02:15:49 CEST] <de-facto> ok cropping and scaling was easy, ffmpeg is awesome :) [02:17:34 CEST] <de-facto> is there a filter to mathematically transform/project videos with complex functions? just was thinking: the glass pyramid reflection is not perfect since viewed from an edge always allows two paths of sight on the object [02:19:07 CEST] <de-facto> maybe a cone (or rotational symmetric body) would be better, yet it would require to distort the video in a complex way on the monitor to compensate the effect of a curved reflection [02:20:11 CEST] <de-facto> probably a task suitable for mathematica et al [02:20:46 CEST] <DHE> the list of filters is here: https://ffmpeg.org/ffmpeg-filters.html [02:21:55 CEST] <snap1> everybody: did you know that intel system does not support high-density ram: where AMD system does [02:22:17 CEST] <DHE> you mean 8-channel memory from AMD vs intel's 6? [02:22:24 CEST] <de-facto> whats high density ram? do you have a link? [02:23:24 CEST] <snap1> DHE no [02:23:37 CEST] <snap1> do you have a RAM in front of you [02:23:43 CEST] <snap1> then ican explain better [02:24:01 CEST] <snap1> find a ram and look at it in front of you [02:24:51 CEST] <snap1> then ican explain better [02:26:39 CEST] <de-facto> you mean the storage per chip on a dimm? [02:27:00 CEST] <DHE> or number of chips (ie. vertically tall memory sticks) [02:30:48 CEST] <snap1> de-facto yes [02:31:03 CEST] <snap1> sometimes you see 4 chips per side or 8 chips [02:31:56 CEST] <DHE> 9 if you have ECC. :) [02:32:56 CEST] <snap1> ecc rams have 9 chips? didn't know that [02:33:03 CEST] <de-facto> interessting, i thought thats what JEDEC conformity is meant for, no clue if there are different levels of standard conformity though [02:33:39 CEST] <de-facto> ECC = 72bit (e.g. 9 chips) vs non-ECC = 64bit (e.g. 8 chips) per rank [02:34:09 CEST] <snap1> is it possible to have more than 9 chips per side? [02:34:09 CEST] <de-facto> or something like that [02:34:20 CEST] <snap1> so 20 chips total ? [02:35:48 CEST] <de-facto> no clue, i guess its a sum of powers of two or such [02:36:26 CEST] <de-facto> maybe the guys in #hardware know more? [02:56:23 CEST] <koz_> I keep getting this error message when trying to recode some videos: Error initializing output stream 0:1 -- Error while opening encoder for output stream #0:1 - maybe incorrect parameters such as bit_rate, rate, width or height [02:56:58 CEST] <koz_> I have no idea what I have to tell it. According to mediainfo, the original audio has 6 channels with layout C L R Ls Rs LFE. [02:59:27 CEST] <furq> koz_: pastebin the command line and output [03:01:39 CEST] <koz_> furq: http://paste.debian.net/1080145/ [03:06:49 CEST] <furq> https://trac.ffmpeg.org/ticket/5718 [03:07:05 CEST] <furq> looks like there's a workaround at least [03:07:35 CEST] <koz_> furq: Yup, that seems to work. Thanks! [03:21:25 CEST] <de-facto> How can i match pure black only? chromakey=black:0.01:0.0 also takes some dark gray, but i want to match ONLY pure (binary) black. Is there a filter without similarity? [03:34:30 CEST] <de-facto> nice it seems lumakey=16:0:0 comes pretty close to that [04:18:39 CEST] <de-facto> According to the raspberrypi.org guys the VideoCore iV in all Pis is the same. ... "The chip was originally designed for 1080P30 encode and decode with VideoCore running at 250MHz. In reality the Pi is almost universally able to overclock the VideoCore blocks to 400MHz, to the extent that that is done automatically on "complex" H264 streams. [04:18:39 CEST] <de-facto> Decode is dependent on the exact bitstream. It will manage almost all 1080P60 streams, but it does depend on the bitrates involved. You have no come back should you find a stream that it can't play that exceeds 1080P30." ... [04:18:59 CEST] <de-facto> does that mean H264 High(a)4.1? [04:20:07 CEST] <DHE> most likely [04:20:52 CEST] <de-facto> H264 1080p30 is 4.1-ish right? [04:21:40 CEST] <DHE> it's a bit more complicated than that, but most likely [04:23:32 CEST] <de-facto> they dont really provide detailed info (at least i couldnt find it). if they claim guarenteed H264 high@1080p30 i understand high(a)4.1-ish and if they say probably most high@1080p60 i read high(a)4.2-ish at least as estimate [04:24:51 CEST] <DHE> officially there are additional restrictions like number of reference frames according to the spec, but I don't see that being a major issue. [04:28:10 CEST] <de-facto> i will just try to encode 1600x1200@60fps on H264 high(a)4.1 with ~2.7Mbit and see if that plays back on Raspi 2 when I have access again on monday [04:32:51 CEST] <furq> de-facto: you can clamp reference frames to the maximum allowed for 4.1 with -level 41 [04:34:00 CEST] <DHE> are you encoding or decoding? [04:34:01 CEST] <de-facto> oh i was using -profile:v high -level:v 4.1 , is that wrong syntax? [04:34:05 CEST] <de-facto> decoding [04:34:26 CEST] <de-facto> with openelec [04:34:49 CEST] <DHE> that's right for encoding. whatever options you give it will be adjusted to meet the constraints of the profile/level [04:36:36 CEST] <furq> i think 1600*1200 @ 60fps needs 4.2 [04:37:06 CEST] <furq> setting -level can only clamp refs [04:39:13 CEST] <de-facto> ok then i try -level:v 4.2 and see if that plays back [04:39:44 CEST] <furq> you usually don't need to set -level, it picks the right one automatically [04:40:43 CEST] <de-facto> thats really efficient, the source.webm is 11.5MB (VGA), the target.mp4 is 10MB :) [04:41:30 CEST] <de-facto> oh I didnt know that, so only -profile:v high is sufficient already then? [04:41:38 CEST] <furq> you don't need that either [04:44:29 CEST] <de-facto> interessting, indeed it gives me the exact same size in bytes :) [04:44:55 CEST] <de-facto> without either profile nor level as you said [04:46:21 CEST] <furq> 1152x864 should be level 4.1 at 60fps [04:46:26 CEST] <furq> i think that's as high as you can go [04:46:46 CEST] <furq> apparently the pi might work with 4.2 if it's overclocked, but 1600x1200 is way over the max data rate for 4.1 [04:46:55 CEST] <furq> so i'd probably have a backup prepared [04:47:23 CEST] <furq> alternatively you could drop to 30fps but i'm guessing that's not going to work [04:49:52 CEST] <de-facto> well if it would not work I could try to drop to 30fps indeed, 60fps was just chosen before for some reason i am not aware of, i guess to match the refresh rate or such [04:50:15 CEST] <furq> if it's a physical effect then it's probably just to look smoother [04:50:58 CEST] <de-facto> yeah i guess something like that [04:51:32 CEST] <de-facto> the video they had before was around 20 Mbps and it wasnt really smooth [04:52:27 CEST] <de-facto> but that also could have been for other reasons, i guess they didnt really think too much about it [04:59:56 CEST] <de-facto> I am going with this now and see if it plays back, it stays below 5GB on encode with a small memory peak at the end, lumakey and scaling made it much slower, but cropping compensated a bit: https://dpaste.de/6Jdt [05:03:24 CEST] <de-facto> cool thing is overlay would allow for lumakey so i could scale them together much closer without dealing with overlappings [13:59:28 CEST] <kubast2> hey, how can I capture a pulse audio application output and make it an input device? [14:01:04 CEST] <kubast2> Rn I'm recording my microphone, putting a filter on it for kicks, and output it to pulseaudio, does pulseaudio allow me to create a dummy input device? [14:13:45 CEST] <kubast2> okay [14:13:47 CEST] <kubast2> I done it [14:14:26 CEST] <kubast2> I found someone who needed an output device for voice chat and a game [14:14:30 CEST] <kubast2> to be seperate for obs [14:14:36 CEST] <kubast2> allowing me to what I wanted [22:46:02 CEST] <Jolein> hi [22:47:12 CEST] <Jolein> is there a way to use these 2 things (-vf scale=1280:720 and -filter:v "minterpolate='mi....) at the same time ? [22:47:48 CEST] <durandal_1707> yes [22:48:12 CEST] <Jolein> it gives a strange error with me [22:48:23 CEST] <durandal_1707> because you use it wrong [22:48:33 CEST] <Jolein> well obviously xD [22:48:38 CEST] <Jolein> else it would be working :p [22:48:59 CEST] <Jolein> trying to find the error back [22:49:21 CEST] <durandal_1707> http://ffmpeg.org/ffmpeg-filters.html#Filtering-Introduction [22:50:43 CEST] <Jolein> so it would be just (-vf scale=1280:720,filter:v "minter...) ? [22:51:05 CEST] <durandal_1707> no [22:51:50 CEST] <durandal_1707> -vf is same as -filter:v [22:52:39 CEST] <Jolein> -vf scale=1280:720,minter..? [22:52:49 CEST] <durandal_1707> yes [22:52:55 CEST] <Jolein> ah [22:53:03 CEST] <Jolein> easy info that i couldnt find for some reason >.> [22:53:12 CEST] <Jolein> ty :D [23:08:46 CEST] <nitrxgen> <3 ffmpeg [23:28:07 CEST] <Jolein> would anyone be willing to help me get open_cl to work ? [23:48:22 CEST] <__Shepherd> furq: you've posted this setpts=PTS-22.5/TB mid-week [23:48:40 CEST] <__Shepherd> that offsets the input -22.5s seconds back [23:49:25 CEST] <__Shepherd> can you offer an explanation on how that works [00:00:00 CEST] --- Sun Apr 28 2019

1 0

ffmpeg-devel.log.20190426
by burek 27 Apr '19

27 Apr '19

[03:14:10 CEST] <cone-973> ffmpeg 03Ruiling Song 07master:0fc464631aaf: lavfi/opencl: add more opencl helper macro [12:15:19 CEST] <cone-105> ffmpeg 03Paul B Mahol 07master:1e01f66822a0: avfilter/af_astats: count number of NaNs/Infs/denormals for floating-point audio too [12:51:05 CEST] <durandal_1707> ubitux: ping [12:55:22 CEST] <iive> atomnuker1, which metro game are you playing? the first or the latest (exodus)? [12:56:07 CEST] <nevcairiel> he did say 2033, thats the first one [12:59:27 CEST] <durandal_1707> iive: what are you playing now? some trolish game? [13:01:09 CEST] <ubitux> durandal_1707: pong [13:01:19 CEST] <ubitux> durandal_1707: i will check the lut3d patch(es) tonight [13:03:52 CEST] <durandal_1707> ok [13:08:22 CEST] <iive> durandal_1707, your constant trolling is annoying. grow up. [13:08:35 CEST] <durandal_1707> ubitux: there is also subtitle patch [16:44:44 CEST] <mkver> Is FFmpeg (the project) actually requiring the range of int to be the typical 32bit range? [16:45:20 CEST] <JEEB> no idea if we support something like DJGPP with 16bit ints [16:45:29 CEST] <mkver> I'm asking because ff_log2_c in libavutil/intmath.h would fail if the unsigned int were 64bit. [16:45:40 CEST] <JEEB> I would bet there's a lot of stuff that would fail with 16bit ints [16:45:45 CEST] <JEEB> mkver: oh, *bigger* :D [16:45:52 CEST] <JEEB> sounds like kool stuff [16:46:35 CEST] <mkver> I'm actually interested in bigger ints. Lots of things would fail with 16bit ints -- lots of constants would overflow etc. [16:46:40 CEST] <jamrial> no, even djgpp has 32 bits ints [16:46:45 CEST] <JEEB> ok [16:46:54 CEST] <JEEB> kind of expected since almost everything expects that nowadays [16:48:30 CEST] <mkver> If 32int are expected and implicitly assumed, then shouldn't this be explicitly mentioned somewhere (probably in the list of C language features here: https://www.ffmpeg.org/developer.html#C-language-features)? [16:48:30 CEST] <nevcairiel> basically, we dont support anything where int is not 32-bit, what would even have that? [16:49:47 CEST] <philipl> wikipedia says "HAL Computer Systems port of Solaris to the SPARC64" [16:50:30 CEST] <mkver> I don't know. I think some of the Cray supercomputers have 64bit ints (everything except char is 64bit on that plattform if I remember correctly). But I am just asking because I saw this implicit assumption on ff_log2_c. [16:52:44 CEST] <mkver> My actual concern is because of a bug in the Matroska muxer. [16:54:02 CEST] <mkver> If you reserve a certain size for cues in the front and said size happens to be 1 byte more than the needed size, then the cues will be written normally and afterwards there will be an attempt to fill in the hole with an EBML void element. [16:54:03 CEST] <jamrial> if the function takes an int, then it's assumed to be for 32 bits ints. in some cases, a version for 64 bit integers is also available, usually using a prefix like 64 or ll, and int64_t as argument [16:54:27 CEST] <mkver> Ok, so int is only supposed to be 32bit. [16:54:36 CEST] <jamrial> sorry, suffix [16:54:38 CEST] <jamrial> and yes [16:55:19 CEST] <mkver> Of course, a one byte hole can't be filled by a void element and one runs into an assert (that the hole to be filled has to be at least two bytes long). [16:56:18 CEST] <mkver> There are two ways to solve this problem: The first is: Error out on this edge case. The second is: If this is so, then write the cues length field on one byte more than necessary. [16:57:11 CEST] <nevcairiel> wouldnt that excess byte still cause validation troubles [16:57:44 CEST] <mkver> No. It is completely spec-compliant to write the length of an EBML element with more bytes than necessary. [16:58:00 CEST] <JEEB> sounds like mp4 [16:58:05 CEST] <JEEB> where you could have just extra stuff at the end [16:58:09 CEST] <nevcairiel> how does a reader know the content ended when there is still stuffing at the end [16:58:19 CEST] <JEEB> or wait I don't remember [16:58:23 CEST] <JEEB> disregard muh comment [16:59:21 CEST] <mkver> No, I don't put the stuffing at the end. An EBML element goes like this: EBML ID, EBML length followed by the payload (whose length is given by the EBML length field except in the unknown-length case). [16:59:33 CEST] <mkver> It is legal to write the EBML length field on more bytes than needed. [16:59:47 CEST] <nevcairiel> oh, you just want to make the length inefficient [17:00:06 CEST] <mkver> I only want to make the length in this very edge case inefficient. [17:00:50 CEST] <nevcairiel> well that would work if the content is already being written to a dynbuf anyway [17:01:00 CEST] <mkver> The current Matroska muxer writes the lengths of lots of elements (like clusters) on the maximum amount of bytes (namely eight). I have a patchset on the mailing list to change this. [17:01:23 CEST] <mkver> Exactly! We already write the cues to a dynbuf. [17:01:41 CEST] <mkver> So it is possible to adapt the length of the length field as needed. [17:02:00 CEST] <nevcairiel> unless its already maxed out, but that would be a lot of cues and not realistic [17:02:31 CEST] <mkver> If int is 32bit, it is not only not realistic, but impossible. [17:02:53 CEST] <nevcairiel> oh right its equipped for writing 64-bit sizes [17:03:55 CEST] <mkver> That's of course the reason for my question: Do I need an #ifdef for big ints? [17:04:03 CEST] <nevcairiel> no [17:04:17 CEST] <mkver> Good. Then I'll remove it again. [17:04:33 CEST] <nevcairiel> you can put an assert if you want to be sure this never happens in case something changes in 10 years or so [17:05:07 CEST] <mkver> Yes, that's what I thought, too. [17:33:22 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07master:f857753f56f8: avcodec/gdv: Check input palette size before rescale() [20:47:12 CEST] <durandal_1707> how to mark sidedata used and not longer needed for packet? [20:48:39 CEST] <jamrial> remove it? [20:49:29 CEST] <durandal_1707> how? [20:50:33 CEST] <durandal_1707> removing all side data is bad idea [20:50:45 CEST] <JEEB> I think you could unlink specific side data? [20:50:52 CEST] <JEEB> not that I've tried to do it myself [00:00:00 CEST] --- Sat Apr 27 2019

1 0

ffmpeg.log.20190426
by burek 27 Apr '19

27 Apr '19

[00:00:46 CEST] <de-facto> can I set the source background (black) as transparent somehow ? [00:09:36 CEST] <de-facto> btw furq, your version works as well like this: http://vpaste.net/nX4GM [00:10:29 CEST] <Numline1> furq hi :) I just wanted to let you know, I played with your Go code a bit. I don't think it's working for me, the splitter doesn't split the y4m a single time. I'm going to debug it on my own of course, I was just wondering if you could show me the ffmpeg command or file or somethign you used to test it [00:10:34 CEST] <Numline1> I don't want to bother you with this too much [00:15:14 CEST] <furq> Numline1: ffmpeg -i foo.mp4 -f mjpeg - | ./foo [00:17:39 CEST] <furq> i feel like you've got mjpeg and y4m mixed up here [00:18:06 CEST] <Numline1> furq well that might be possible, I'm using this for output - -pix_fmt yuv420p -f yuv4mpegpipe [00:18:16 CEST] <Numline1> the outfile is y4m, so I guess that's something different? [00:18:19 CEST] <furq> yeah [00:18:26 CEST] <Numline1> heh, that explains a lot [00:18:34 CEST] <furq> the point was that you're uploading these images to some web service as jpeg anyway [00:18:40 CEST] <Numline1> yes sir [00:18:45 CEST] <furq> so you might as well have ffmpeg convert it to mjpeg [00:18:49 CEST] <furq> which is just a bunch of concatenated jpegs [00:19:18 CEST] <Numline1> absolutely. I just had no idea it existed tbh, I was using an advice I got yesterday from fellow friends in here [00:19:24 CEST] <Numline1> furq I'll try that, thank you [00:20:06 CEST] <Numline1> furq btw just out of curiosity, does y4m have any sort of similar delimiters like mjpeg or is it just a newline that's not reliable anyway? [00:20:51 CEST] <furq> y4m is file header, newline, frame header, newline, known-size frame data that can contain newlines, newline [00:21:27 CEST] <furq> so you can read everything other than the frame data line-by-line [00:21:37 CEST] <furq> also https://clbin.com/uJFry [00:21:44 CEST] <furq> it won't make any difference but i figured i should fix that bug [00:23:48 CEST] <Numline1> furq hah thanks :) same but a bit fancier [00:23:56 CEST] <Numline1> furq can I buy you a coffee for your help? [00:26:47 CEST] <de-facto> furq do you know if i can set the black background color of the source video sprites transparent prior to putting them on the canvas? [02:43:39 CEST] <irwiss> are there muxers/codecs/others which may be changing the format mid-stream? e.g. can i get a 320x240 YUV420P frame from a specific AVStream, and then the stream will resize into some other size or pixel format without a restart? or with audio are there scenarios where audio format changes without restarting the stream? i'm trying to figure out what [02:43:39 CEST] <irwiss> kind of stuff i need to handle w.r.t. buffer allocations [09:33:45 CEST] <dilm_> hi, i'm searching where i can find if my camera is compatible with ffmpeg to have a device in /dev/video* [09:34:27 CEST] <dilm_> Bus 001 Device 043: ID 04e8:138b Samsung Electronics Co., Ltd [09:34:36 CEST] <dilm_> WB250F [15:32:31 CEST] <mozzarella> guys help [22:07:00 CEST] <de-facto> why does crop filter require over 16 GB of memory for 320x320 video? [22:16:18 CEST] <durandal_1707> de-facto: post full command line [22:17:01 CEST] <de-facto> its not the crop filter, but after some time ffmpeg just tries to allocate memory like crazy and gets killed [22:18:29 CEST] <durandal_1707> de-facto: post full command line [22:22:07 CEST] <de-facto> durandal_1707, https://dpaste.de/gzEb [22:23:01 CEST] <de-facto> encodes a while with ~4.5 GB RAM then stops and allocates until it gets killed at ~16GB [22:23:56 CEST] <de-facto> i know it works on linux/windows with more memory (e.g. 64 GB) [22:26:42 CEST] <durandal_1707> de-facto: if it caches lots of frames than it will need more RAM, setpts could do that [22:27:43 CEST] <durandal_1707> so try without setpts filter and does it still need so many RAM? [22:31:30 CEST] <de-facto> durandal_1707, it reduces a lot of ram (1.2 GB), but at the end there still is a BIG peak, yet slightly below 16 GB for now [22:31:59 CEST] <de-facto> thats crazy, why would it need such enormous amounts of ram just to finish writing the file out to disk? [22:33:17 CEST] <durandal_1707> you could also use xstack instead of overlay [22:38:15 CEST] <de-facto> would that reduce the memory peak? [22:38:22 CEST] <durandal_1707> de-facto: look at graphmonitor filter, it can show number of cached frames in filter links [22:38:52 CEST] <durandal_1707> de-facto: if you just tile videos into grid, its also much faster [22:39:10 CEST] <de-facto> i need specific positions, not just a grid [22:40:14 CEST] <durandal_1707> de-facto: does not look like from graph, you just put videos into 2x2 tile [22:40:26 CEST] <durandal_1707> xstack can do that [22:41:20 CEST] <de-facto> its a "cross" of videos from the center with each video rotated by an additional 90 degree [22:43:44 CEST] <de-facto> from the docs it seems that xstack is meant for tight grids (e.g. by rows/cols by source w/h) [22:44:58 CEST] <durandal_1707> de-facto: not really, it allows any combination, even overlap, overlay filter is for transparency masking [22:48:36 CEST] <de-facto> hmm then i dont understand the documentation of xstack [22:49:06 CEST] <BtbN> I also don't see any sign of rotation in there, or cropping. [22:49:24 CEST] <furq> BtbN: transpose [22:49:36 CEST] <BtbN> ah [22:50:18 CEST] <de-facto> i removed the cropping i tried as a test, that is not the cause [22:50:51 CEST] <durandal_1707> bunch of overlays and setpst timeline changing needs RAM [22:50:56 CEST] <de-facto> it seems it encodes stable at constant memory and just before it finishes there is a crazy memory peak [22:51:17 CEST] <durandal_1707> to prove this, just attach graphmonitor at end and watch its output [22:51:39 CEST] <BtbN> The progress indicator also doesn't mean much when messing around with setpts [22:51:45 CEST] <BtbN> "the end" could be just it starting [22:51:58 CEST] <durandal_1707> yea [22:52:04 CEST] <de-facto> i just looked at the system monitor, but yeah maybe i need to use graph monitor [22:52:16 CEST] <durandal_1707> graphmonitor is filter [22:52:40 CEST] <durandal_1707> it shows issues with filtergraphs [22:52:47 CEST] <BtbN> I don't understand those setpts lines. Are they supposed to queue the 4 videos one after the other? [22:53:30 CEST] <furq> it's supposed to offset each one by 7.5 seconds [22:54:35 CEST] <durandal_1707> that will cause big cache of frames, which needs RAM [22:54:56 CEST] <de-facto> maybe my version 3.4.4-0ubuntu0.18.04.1 is too old? [22:55:12 CEST] <furq> they're small-ish frames and the source video is only 30 seconds long [22:55:18 CEST] <furq> so i wouldn't have thought it'd be that bad [22:55:29 CEST] <furq> but yeah graphmonitor will tell you for sure [22:55:43 CEST] <de-facto> im just not sure how to use that [22:55:44 CEST] <furq> de-facto: https://www.johnvansickle.com/ffmpeg/ [22:56:01 CEST] <furq> graphmonitor is new in 4.1 [22:58:55 CEST] <de-facto> yup i thought that already [22:59:22 CEST] <de-facto> weird thing is it encodes happily until 28 seconds in the video, then stalls and just allocates memory until its killed [22:59:52 CEST] <de-facto> same with the 4.1.3 static build [23:02:33 CEST] <furq> is it actually writing anything to the file [23:03:56 CEST] <de-facto> yes i think a little bit, but its unplayable [23:08:22 CEST] <de-facto> maybe its level and profile? [23:13:09 CEST] <durandal_1707> nope, that is tipical for mp4 [23:15:03 CEST] <de-facto> i think its something with the DURATION=30 and -t "${DURATION}" [23:17:27 CEST] <de-facto> i dont understand it, have to experiment for a while [23:23:37 CEST] <de-facto> what does this line mean? -i "color=r=60:c=black:s=1600x1200:d=120" [23:26:47 CEST] <kepstin> de-facto: ` -f lavfi -i "<some stuff>" ` means "run the filters listed in <some stuff> and use their output as an input to ffmpeg" [23:27:40 CEST] <de-facto> ok its a black 1600x1200 60 fps video i guess [23:27:53 CEST] <kepstin> de-facto: so in this case, the "color" filter just generates a blank video to use as an input to composite the other stuff over [23:29:35 CEST] <de-facto> kepstin, ok but i dont understand "color=r=60" and also not "d=120" [23:30:56 CEST] <kepstin> de-facto: https://www.ffmpeg.org/ffmpeg-filters.html#Filtergraph-description [23:31:35 CEST] <kepstin> de-facto: basically, you have a filter name, then an equals sign, then a list of options for the filter separated with : [23:32:40 CEST] <durandal_1707> http://ffmpeg.org/ffmpeg-filters.html#allrgb_002c-allyuv_002c-color_002c-ha… [23:33:31 CEST] <de-facto> yeah i am already trying to read that [23:36:18 CEST] <de-facto> so its the color source with color=... with the options separated by : e.g. r=60:c=black:s=1600x1200:d=120 trying to find documentation of those specifically d=120 i guess its duration? [00:00:00 CEST] --- Sat Apr 27 2019

1 0

ffmpeg-devel.log.20190425
by burek 26 Apr '19

26 Apr '19

[00:29:58 CEST] <cone-887> ffmpeg 03Carl Eugen Hoyos 07master:1ae5a6445724: lavfi/frei0r: Fix a union member type and remove an unneeded cast. [01:15:16 CEST] <CounterPillow> rofl 2.8.15 [14:52:49 CEST] <cone-142> ffmpeg 03Michael Niedermayer 07master:b91786360f48: avcodec/zmbv: optimize motion compensation with memcpy() [14:52:49 CEST] <cone-142> ffmpeg 03Nikolas Bowe 07master:dd9907847c0d: avcodec/bintext: Add error message when resolution is too small for font. [14:52:49 CEST] <cone-142> ffmpeg 03Michael Niedermayer 07master:8ea211ab79d6: avcodec/aacdec_fixed: Fix undefined shift in noise_scale() [14:52:49 CEST] <cone-142> ffmpeg 03Michael Niedermayer 07master:af77adc02e4a: avcodec/qtrle: Check how much of the chunk is available before decoding [14:52:49 CEST] <cone-142> ffmpeg 03Michael Niedermayer 07master:06ef186fa1b7: avcodec/jpeg2000: Check stepsize before using it [14:52:50 CEST] <cone-142> ffmpeg 03Michael Niedermayer 07master:6381b6f6a973: avcodec/jpeg2000dec: Replace the step_x/y assert by a check in the CPRL case as with the PCRL case [14:52:50 CEST] <cone-142> ffmpeg 03Michael Niedermayer 07master:e627113329da: avcodec/jpeg2000dec: Check PLT data somewhat [14:59:37 CEST] <durandal_1707> ubitux: see more lut3d patches on ML [15:02:09 CEST] <durandal_1707> for 2nd patch look here for .cube file: https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=13&t=6896 [15:24:59 CEST] <mkver> The description of avio_seek's return value is "new position or AVERROR." Does this mean that if avio_seek doesn't return an error, the returned position can be different from the desired position? [16:40:02 CEST] <nevcairiel> no that should not happen, but in case you use anything but SEEK_SET it'll return the absolute file position, i nstead of just throwing your offset back at you [17:17:31 CEST] <mkver> @Nev: Thanks. [18:51:30 CEST] <durandal_1707> michaelni: your last patch, as explained on ML is buggy [19:20:41 CEST] <cone-293> ffmpeg 03Michael Niedermayer 07master:2be0bd12b71c: avcodec/jpeg2000dec: Fix return type of get_plt() [19:36:41 CEST] <Lynne> Could someone review or push my patches? I have 5 on the ML and 2 more I'm working on [00:00:00 CEST] --- Fri Apr 26 2019

1 0

ffmpeg.log.20190425
by burek 26 Apr '19

26 Apr '19

[00:01:33 CEST] <another> no idea what premiere supports, but from the table on wikipedia it seems that not a lot of encoders support high444pred [00:02:13 CEST] <GuiToris> well actually I checked the reencoded file and it's High 4:4:4 Predictive(a)L4.2 , CABAC / 4 Ref Frames [00:03:04 CEST] <GuiToris> and it works perfectly [00:03:30 CEST] <GuiToris> should I really reencode all the clips? [00:04:28 CEST] <another> you reencoded with ffmpeg -i lossless.mp4 new.mp4 ? [00:04:42 CEST] <another> and it's high444pred? [00:04:54 CEST] <GuiToris> yes [00:05:05 CEST] <GuiToris> I didn't use a single option [00:06:56 CEST] <another> o.O [00:07:28 CEST] <GuiToris> I'll post the full output [00:08:17 CEST] <GuiToris> https://bpaste.net/raw/12e6eb65d596 [00:14:37 CEST] <another> without options libx264 should default to crf 23 [00:16:50 CEST] <GuiToris> hurray, I have internet connection again [00:16:59 CEST] <GuiToris> another, did you get my links? [00:17:08 CEST] <GuiToris> I'm not sure if I could send them [00:17:20 CEST] <GuiToris> my internet just disconnected [00:18:16 CEST] <GuiToris> they are both High 4:4:4 Predictive [00:18:25 CEST] <GuiToris> I don't know what's wrong with Premiere [00:19:06 CEST] <GuiToris> and what options should I use in case I have to reencode all the clips? [00:19:28 CEST] <another> maybe try to limit the level? [00:20:05 CEST] <another> but that's just a wild stab in the dark [00:21:30 CEST] <GuiToris> another, -c:v libx264 -preset veryslow -crf 0 -level:v 4.2 [00:21:37 CEST] <GuiToris> is this what you meant? [00:23:10 CEST] <another> yep [00:23:34 CEST] <GuiToris> I'll give it a shot, thank you another [00:24:36 CEST] <GuiToris> I'm leaving now because my connection is really poor and it's disconnecting all the time [00:24:42 CEST] <GuiToris> see you later! [00:25:19 CEST] <another> laters [03:49:08 CEST] <Numline1> So I just got home from Endgame [03:49:13 CEST] <Numline1> I'm not gonna spoil anything [03:49:27 CEST] <Numline1> but it might be the best movie in like 20 years [03:52:46 CEST] <Numline1> Also I meant to post this elsewhere and I'm an idiot lol [10:39:10 CEST] <irwiss> hey i've a video that appears like so https://i.imgur.com/rtaO1Ou.png (planar YUV420) even though other videos seem to decode fine, on the other hand vlc can play that stream so it's not completely broken and most likely i'm doing something wrong, it looks a lot like banding but i'm not sure, did i mess up an alignment/stride or is it some other is [10:39:10 CEST] <irwiss> sue? i'm baffled why it repeats 5 times; the width of the video is 320px, the green part on second line is garbage in memory (i think) so did i mess up the alignment by 64 bytes or so.? [12:49:58 CEST] <irwiss> yep that's what it was and by about that much, didn't realize the strides could be up ~20% of a frame's size [13:27:59 CEST] <Numline1> irwiss I'm about to do some yuv420 magic and I feel your pain [13:28:11 CEST] <Numline1> I have nothing constructive to help you with [13:58:03 CEST] <irwiss> Numline1: it seems i would stumble into same issue with simplest rgb interleaved raster, i didn't realize how large those strides can be, also directx memory views also have their own stride, fun stuff [13:59:31 CEST] <Numline1> irwiss that sounds rough, I'm glad I'm not doing exactly the same. Tl;dr I'm trying to convert y4m into series of images in memory, it took me a while to even figure out how to spit it correctly [13:59:59 CEST] <Numline1> the y4m header kept messing with me, but I eventually found the correct yuv 2 rgb formula. I'm trying to implement it now, I hope I don't get that noise you got [14:00:13 CEST] <JEEB> "correct YCbCr to RGB formula" [14:00:16 CEST] <JEEB> oh you youngling [14:00:24 CEST] <JEEB> to think there is a single formula that is correct 8) [14:00:57 CEST] <Numline1> JEEB well I really hope this one'll work. It's something I found deeply in Golang core :) [14:01:06 CEST] <Numline1> this folk right here - https://golang.org/src/image/color/ycbcr.go [14:01:25 CEST] <JEEB> ok [14:01:45 CEST] <JEEB> doesn't mention BT.709 vs BT.601 or BT.2020 [14:01:57 CEST] <Numline1> who's that [14:02:05 CEST] <Numline1> sounds like terminator models [14:02:21 CEST] <JEEB> also doesn't mention full/limited range YCbCr [14:02:43 CEST] <JEEB> since most YCbCr that comes out of video is limited as in, the full range is 16-235/240 [14:02:47 CEST] <JEEB> instead of 0-255 [14:02:58 CEST] <JEEB> JPEG YCbCr by default is "full range" which is 0-255 [14:03:05 CEST] <Mavrik> Is scaling from 16-235 -> 0-255 linear? :) [14:03:26 CEST] <Numline1> does that depend on pixel format? [14:03:31 CEST] <JEEB> no [14:03:39 CEST] <JEEB> it's a separate piece of metadata [14:03:43 CEST] <JEEB> full range vs limited range [14:03:53 CEST] <JEEB> for video you can expect limited range [14:04:03 CEST] <Numline1> well fuck me sideways [14:04:05 CEST] <Numline1> I hope this works [14:04:15 CEST] <Numline1> JEEB you've planted the seed of uncertainty [14:04:20 CEST] <JEEB> mwahahaha [14:04:30 CEST] <JEEB> anyways, that code with a quick look looks like it took values from JFIF [14:04:40 CEST] <JEEB> so it's highly likely that it's meant for JPEG like stuff [14:04:56 CEST] <Numline1> I mean it's image library, so I'd think so [14:05:14 CEST] <Numline1> fuck I still need to figure out a reasonable way to parse the y4m header [14:05:16 CEST] <JEEB> Numline1: I would just utilize something like zimg to get YCbCr into RGB [14:05:29 CEST] <JEEB> or even output RGB out of FFmpeg first of all :P [14:05:42 CEST] <JEEB> unless you need the raw data that the decoder is pushing out [14:06:09 CEST] <Numline1> JEEB can I though? I'm basically outputting multiple images into a pipe, so guys from this channel recommended y4m [14:06:12 CEST] <irwiss> anyone knows what determines the output formats of say a dx11 hw decoder? i've been staring at https://ffmpeg.org/doxygen/4.1/hwcontext__d3d11va_8c_source.html#l00082 and nearby lines 142/143 trying to figure out what's going on there, e.g. is there a way to get nicer texture layout (non-planar) than nv12 or are hw decoders are hardwired/coded into [14:06:12 CEST] <irwiss> those formats? or a writeup on how various sw_format_* stuff interacts with hw_format* stuff? [14:06:20 CEST] <Numline1> I doubt I can output multiple images into rgb format [14:06:23 CEST] <Numline1> in a single run [14:06:47 CEST] <JEEB> Numline1: if y4m output takes in rgb pix_fmts I don't see any reason why not [14:06:52 CEST] <JEEB> it's just an identifier after all [14:07:23 CEST] <JEEB> irwiss: hw decoder interfaces pretty much give you NV12 or P010 nowadays [14:07:39 CEST] <JEEB> (or other P01X for >10bit) [14:08:12 CEST] <Numline1> JEEB _ ERROR: yuv4mpeg can only handle yuv444p, yuv422p, yuv420p, yuv411p and gray8 pixel formats [14:08:18 CEST] <JEEB> ok [14:08:25 CEST] <Numline1> so that's probably a nope :) [14:08:46 CEST] <Numline1> JEEB I mean, unless there's a better format to output my frames... I was thinkign GIF maybe? [14:08:46 CEST] <JEEB> technically nothing stops you from outputting it, but I guess that's 100% valid because then other tools wouldn't be able to read it [14:08:49 CEST] <JEEB> although [14:09:12 CEST] <JEEB> Numline1: umm [14:09:18 CEST] <JEEB> current yuv4mpegenc has quite a bit more [14:09:21 CEST] <JEEB> of pix_fmts supported [14:09:28 CEST] <irwiss> ah, guess i'll have to trigger a shader or something then, couldnt figure out if it's hardwired or nobody bothered to support non-planar ones :) thanks [14:09:39 CEST] <JEEB> although no full rgb ones [14:09:57 CEST] <Numline1> oh, it also says And using 'strict -1' also yuv444p9, yuv422p9, yuv420p9, yuv444p10, yuv422p10, yuv420p10, yuv444p12, yuv422p12, yuv420p12, yuv444p14, yuv422p14, yuv420p14, yuv444p16, yuv422p16, yuv420p16, gray9, gray10, gray12 and gray16 pixel formats. Use -pix_fmt to select one. [14:10:01 CEST] <Numline1> I haven't noticed that [14:10:06 CEST] <Numline1> it's 4.1.1 [14:10:08 CEST] <Numline1> btw [14:10:28 CEST] <JEEB> ok, so it checks that in init() while I was reading write_header probably :) [14:10:41 CEST] <JEEB> also I hate those numeric strict values :P [14:10:49 CEST] <JEEB> they have textual names goddamnit xD [14:11:04 CEST] <Numline1> JEEB I mean, to be fair, I don't mind the conversion to RGB, even though it adds a bit of complexity :) I just need to figure out the "how" [14:11:09 CEST] <Numline1> most examples only do that in matlab [14:11:17 CEST] <JEEB> zimg [14:11:26 CEST] <Mavrik> swscale? /hides [14:11:26 CEST] <JEEB> that's my goto thing for CPU based conversions and scaling [14:11:34 CEST] <Numline1> yeah I was also trying to avoid C bindings in Go [14:11:52 CEST] <JEEB> uh-huh [14:12:05 CEST] <Numline1> plus, this shouldn't really be hard to implement. All I need are 3 values from y4m header and then slice the remainder of the file [14:12:33 CEST] <JEEB> anyways, swscale (generally) and zimg do these things correctly, while all the random matlab etc answers probably not :P [14:12:33 CEST] <Numline1> what I'm trying to figure out right now is how to strip away the header and then start slicing [14:12:46 CEST] <JEEB> also at this point it sounds like you might as well have written a short API client [14:12:48 CEST] <Numline1> matlab actually seems to have some video libs as well, for whatever reason [14:12:51 CEST] <JEEB> that outputs the raw decoded images [14:12:59 CEST] <JEEB> in a amanner that you want to parse [14:13:06 CEST] <JEEB> if you really really wanted to keep the C separate from golang [14:13:07 CEST] <JEEB> :P [14:13:26 CEST] <Numline1> this poor thing is a bit monolithic :) [14:13:37 CEST] <Numline1> It needs to do the ffmpeg part internally, since it's deployed to Google App Engine and more instances = more money [14:13:55 CEST] <Numline1> I also shouldn't write files [14:14:11 CEST] <JEEB> I haven't mentioned either so I don't knwo why you mention it [14:14:16 CEST] <Numline1> Basically I fell into this rabbit hole of "I'm trying to do this properly" instead of actually finishing 2 days ago with something that actualyl works [14:14:43 CEST] <JEEB> well right now you'rei nstead of knowingly picking correctly working components trynig to cobble something together yourself :P [14:14:57 CEST] <JEEB> I might be sounding a bit bad, but that's how it looks right now [14:14:58 CEST] <Numline1> JEEB yeah, I know, I added that as a lovely bonus to explain why I can't just let ffmpeg output bunch of jpeg files [14:15:06 CEST] <JEEB> eh [14:15:11 CEST] <JEEB> why do you bring jpeg here [14:15:14 CEST] <JEEB> I didn't mention it [14:15:31 CEST] <JEEB> so far your problem is according to chat a) decode videos b) output timestamp+raw RGB c) do *something* with it [14:15:38 CEST] <Numline1> JEEB I know, I'm trying to say letting ffmpeg output a bunch of jpeg files into a folder and then loading them would essentially be the same :) [14:16:00 CEST] <Numline1> the input is an mp4 or whatever file, yuv is something I willingly created on output in stdout [14:16:28 CEST] <Numline1> I'll end up creating jpeg files anyway, so our image recognition system can deal with it later [14:16:42 CEST] <Numline1> I just wanted to do all that in memory during runtime of my program [14:16:49 CEST] <Numline1> /rant [14:16:59 CEST] <JEEB> yes, I just see it as an extra complication what you're noting about not wanting to do X,Y,Z [14:17:08 CEST] <JEEB> like using lavc + zimg to get the RGB planes [14:17:18 CEST] <JEEB> either via sub-process that's custom built or otherwise [14:17:18 CEST] <JEEB> :P [14:17:26 CEST] <JEEB> anyways, have fun [14:18:38 CEST] <Tazmain> HI all, I am trying to convert a RTP stream that was saved as raw (it was opus) to wav,. and I keep getting invalid pixel format https://bpaste.net/show/0dc18782d7aa [14:18:40 CEST] <Numline1> JEEB well, thanks :) My issue with that is it add extra dependencies like imagemagic and stuff [14:19:05 CEST] <Tazmain> does the -dn flag not work ? [14:19:09 CEST] <Numline1> I would use that for something more complex, after all, I used ffmpeg instead of splitting videos manually, zimg just doesn't seem necessary at this time [14:19:35 CEST] <JEEB> uhh [14:19:40 CEST] <JEEB> where did imagemagick come in from? :D [14:19:49 CEST] <JEEB> https://github.com/sekrit-twc/zimg [14:19:50 CEST] <JEEB> is zimg [14:19:59 CEST] <JEEB> does scaling and colorspace conversions correctly [14:20:06 CEST] <JEEB> and is usable through FFmpeg's libavfilter [14:20:07 CEST] <JEEB> :P [14:20:11 CEST] <JEEB> (through the zscale filter) [14:20:19 CEST] <JEEB> while the swscale library is usable through the scale filter [14:20:19 CEST] <another> Tazmain: is the raw data opus? [14:20:25 CEST] <Tazmain> another, yes [14:20:37 CEST] <another> then put the -c:a libopus before the input [14:20:39 CEST] <Tazmain> `ffmpeg -i Saved\ RTP\ Audio.raw -vn -c:a libopus sa.ogg` is my command [14:20:45 CEST] <Tazmain> before the input ? [14:21:06 CEST] <TikityTik> can anyone explain bufsize to me? [14:21:06 CEST] <another> ffmpeg -c:a libopus -i $input -c copy out.opus [14:21:19 CEST] <Tazmain> -c copy ? [14:21:22 CEST] <Tazmain> is that -c:a ? [14:21:29 CEST] <Tazmain> oh nvm [14:22:16 CEST] <Tazmain> still getting errors on that https://bpaste.net/show/ef8fd36fc876 [14:26:14 CEST] <another> looks like it not just raw opus frmaes [14:26:18 CEST] <another> *frames [14:27:03 CEST] <TikityTik> Tazmain: what are you trying to do, what is your command line? [14:27:11 CEST] <Tazmain> well I tried saving as Unsyncronized forward stream, stream syncrhonized audio [14:27:13 CEST] <Tazmain> next is file [14:28:28 CEST] <Tazmain> TikityTik, `ffmpeg -c:a libopus -i file.raw -vn sa.ogg` or `ffmpeg -c:a libopus -i file.raw -c copy out.opus` both fail . So I have a wireshark trace of a SIP call using opus RTP. I want to get the audio from the RTP [14:28:52 CEST] <Tazmain> now no guide online matches the current wireshark option, and there is very little on working with opus [14:29:01 CEST] <Tazmain> so I am basically stuck and at the point of giving up [14:29:03 CEST] <TikityTik> Tazmain: why aren't you using ffmpeg -i file.raw -vn -c:a libopus sa.ogg? [14:29:46 CEST] <Tazmain> Output file #0 does not contain any stream [14:29:49 CEST] <another> Tazmain: where did you get this "raw" file? [14:29:52 CEST] <Tazmain> for that command [14:30:07 CEST] <Tazmain> another, saving from wireshark rtp anaylsis, I mentioned above [14:30:35 CEST] <TikityTik> Tazmain: can you upload the file? [14:30:40 CEST] <Tazmain> TikityTik, sure [14:31:19 CEST] <Tazmain> TikityTik, https://send.firefox.com/download/7407997eec598148/#uC6T8ytZk6q1vTqYD9-iTQ [14:31:34 CEST] <Tazmain> there are 4 raw files, as I tried different option in wireshark to save as [14:33:05 CEST] <another> hmm.. just a wild stab in the dark: ffmpeg -f rtp -c:a libopus -i $input -c copy out.opus [14:35:12 CEST] <Tazmain> wait , if that can take rtp then I need to dump the rtp [14:36:30 CEST] <Tazmain> still all fails [14:36:31 CEST] <Tazmain> sigh [14:39:39 CEST] <TikityTik> Tazmain: what encoding was the RTP stream using? [14:42:04 CEST] <Tazmain> opus [14:42:17 CEST] <Tazmain> even shows that in wireshark [14:45:28 CEST] <Numline1> I wonder, why does the YCbCrToRGB func in Go accept 3 int8 parameters [14:45:38 CEST] <Numline1> Shouldn't that be like a ton of bytes instead? [14:49:30 CEST] <Mavrik> Hopefully it's not operating on per-pixel basis :D [14:49:33 CEST] <Mavrik> Or it'll be slow as heck [14:50:16 CEST] <JEEB> it probably does [14:53:14 CEST] <Numline1> Tazmain I honestly think it does lol [14:54:33 CEST] <furq> Numline1: sounds like it's expecting you to have packed yuv444 [14:55:29 CEST] <Numline1> furq it's this thing here, I'm currently trying to check the math whether it's something that could work - https://golang.org/src/image/color/ycbcr.go [14:55:53 CEST] <Numline1> although looking at the namespace under "color" it may be something different [14:56:30 CEST] <Numline1> it says it's used to convert Y'CbCr triple and RGB triple, among some other stuff [14:57:34 CEST] <furq> annoyingly it would be easier to just do the rgb conversion in ffmpeg, but y4m doesn't support rgb [14:58:33 CEST] <JEEB> furq: I'd just patch it locally if I needed RGB over some simple container [14:58:35 CEST] <Numline1> Yeah. However it seems I might be able to just read the frame from y4m file and then pass it to something in Go's image package [14:58:45 CEST] <Numline1> this one is sadly a bit low level. I need to do some googling [14:58:56 CEST] <JEEB> I mean, you just add a new identifier for RGB and let it pass the check [14:59:11 CEST] <furq> JEEB: it's weird that hasn't been done already considering there are already noncompliant pixel formats with -strict -1 [14:59:17 CEST] <JEEB> yea [14:59:17 CEST] <furq> i guess it would conflict with the name though [14:59:21 CEST] <JEEB> I Was going to mention that :P [15:02:01 CEST] <Numline1> Okay I think I can create an Image struct in Go with Model called "YCbCrModel" [15:02:06 CEST] <Numline1> from the frame I read [15:02:11 CEST] <Numline1> and then convert it to Jpeg [15:02:18 CEST] <Numline1> holy shit, if this works... [15:02:54 CEST] <JEEB> always compare your output against something known "OK" stuff [15:03:11 CEST] <JEEB> like f.ex. mpv with the gpu renderer, opengl/d3d11 output [15:03:24 CEST] <JEEB> or if you have a simple way of using zimg with vapoursynth or so [15:03:42 CEST] <Tazmain> Numline1, heh ? [15:04:40 CEST] <Numline1> Tazmain basically I thought I'd have to read pixel by pixel and convert into RGB [15:04:46 CEST] <Numline1> I may be able to load an entire frame [15:05:00 CEST] <Numline1> and hope Go actually has its ways to convert it into jpeg [15:05:03 CEST] <furq> jpeg is yuv though so i don't see how that helps [15:05:08 CEST] <furq> also it's lossy which isn't great [15:05:20 CEST] <furq> unless you're planning to then convert it into png [15:05:20 CEST] <Numline1> furq the end file needs to be uploaded online and then processed [15:05:36 CEST] <Numline1> I mean I'm okay with png as well, anything more "standard" [15:05:49 CEST] <Numline1> it just needs to have some fancy headers so iimage recognition can work with it [15:43:53 CEST] <TikityTik> can anyone explain bufsize to me? and why setting it too low ruins the quality? [15:44:16 CEST] <TikityTik> and why is there no option for bufsize to be set by seconds instead? [15:53:57 CEST] <DHE> keyframes require a large amount of data compared to other frames. the in VBV mode the maximum size of any frame will be bitrate/framerate + whatever is available in the buffer [15:54:18 CEST] <DHE> if the buffer is too small, a keyframe will look bad when forced to be about the same size as other inter/between frames [16:09:50 CEST] <TikityTik> DHE: keyframes are in bufsize? [16:11:50 CEST] <TikityTik> i don't really understand the structure of a video [16:12:04 CEST] <Numline1> So folks :) I had some progress with my Y4M file :) [16:12:11 CEST] <Numline1> The header is : YUV4MPEG2 W1280 H720 F30:1 Ip A1:1 C420mpeg2 XYSCSS=420MPEG2 [16:12:19 CEST] <Numline1> As far as I can tell, there are two frames in the video [16:12:36 CEST] <Numline1> the amount of bytes read for one frame should be 1382400 [16:12:47 CEST] <Numline1> However, the file size, without the header, seems to be 1382400 * 4 [16:12:55 CEST] <Numline1> before the EOF has been reached [16:13:03 CEST] <Numline1> Any thoughts on why that might be? [16:17:40 CEST] <DHE> TikityTik: a keyframe is basically an entirely self-contained picture. inter frames are based on previous frame(s) so they size requirements are much lower [16:18:26 CEST] <TikityTik> DHE: so what's the min keyframe size? [16:18:49 CEST] <TikityTik> are the multiple keyframes per a second? [16:18:53 CEST] <TikityTik> are there* [16:19:08 CEST] <DHE> there isn't really a minimum. assuming h264, there's a quality parameter which goes from 0 (lossless) to 51 (unreadable smudge) [16:19:55 CEST] <TikityTik> how do i determinte then what's the smallest bufsize i can do? [16:19:59 CEST] <TikityTik> determine* [16:20:26 CEST] <DHE> you can do 0. you just get a horrible image to go with it. [16:20:30 CEST] <faLUCE> TikityTik: why do you want to determine it? [16:21:01 CEST] <TikityTik> smaller bufsize means more changing bitrate right? so it would be better for constant quality encoding no? [16:26:35 CEST] <DHE> the average remains constant. bigger buffers allow for more variance in the short term to deal with times that need it [16:32:16 CEST] <TikityTik> i don't understand [16:32:31 CEST] <TikityTik> wouldn't the crf be calculated by the bufsize? [16:32:54 CEST] <TikityTik> the bitrate needed for the quality [16:33:31 CEST] <TikityTik> which means that smaller buffers give more variance? [16:35:03 CEST] <bigpod> Hello my question is how to compile ffmpeg on ubuntu so it can utilise nvenc and can be used by OBS i followed the guide and on the side and before hand got nv-codec-headers but obs doesnt detect it [16:36:20 CEST] <BtbN> You'll need to re-compile the system packages, or build a custom deb of them [16:36:33 CEST] <DHE> "ffmpeg -h encoder=nvenc" should produce information about what options it supports, if ffmpeg was built correctly [16:36:36 CEST] <BtbN> Or build a static version and build OBS forcing it to use those [16:36:47 CEST] <DHE> also you need the binary nvidia driver from nvidia themselves for this to work [16:36:57 CEST] <BtbN> manually "make install"ing a version of FFmpeg into your system is a recipe for disaster. [16:38:48 CEST] <bigpod> and how to do those sort of stuff [16:39:35 CEST] <BtbN> Use the apt/dpkg magic to get the exact sources of your system packages, build them with the exact same parameters, except you also enable ffnvcodec, and then install those debs you end up with [16:39:36 CEST] <bigpod> so it would work [16:39:42 CEST] <BtbN> and repeat on every update [16:40:57 CEST] <bigpod> i just need ffmpeg with nvenc which actualy works but OBS doesnt detect it(becuase its installed at user level as far as i understand) [16:44:48 CEST] <bigpod> so i dont need every piece of software to use nvenc its just a recording and transcode machine [16:45:01 CEST] <BtbN> obs does not use the ffmpeg cli tool [16:45:19 CEST] <BtbN> It needs the libraries it uses to support it [16:45:23 CEST] <bigpod> what it uses [16:46:43 CEST] <bigpod> because what i get on OBS side of things is i need to compile FFMPEG in such a way that it installed at system level and not user level [16:47:21 CEST] <BtbN> Which is exactly what I just explained... [16:47:34 CEST] <BtbN> That or a local build of OBS with static ffmpeg with ffnvcodec support [16:48:37 CEST] <bigpod> and how to do that [16:48:49 CEST] <BtbN> <BtbN> Use the apt/dpkg magic to get the exact sources of your system packages, build them with the exact same parameters, except you also enable ffnvcodec, and then install those debs you end up with [16:49:18 CEST] <BtbN> There is no copy&paste tutorial for that stuff [16:53:03 CEST] <bigpod> and how to do that [16:57:29 CEST] <TikityTik> DHE: don't smaller buffers in common sense mean more variance? I don't understand [16:59:58 CEST] <DHE> each frame is allotted up to bitrate/framerate + remaining_buffer_size bytes. if the buffer is small, the second term approaches 0 and you get an actual consistent bitrate [17:00:12 CEST] <DHE> (if the frame uses less than bitrate/framerate bytes, the excess goes into the buffer if capacity permits) [17:03:31 CEST] <TikityTik> so how do i know what bufsize to use if i want to do constant quality? [17:03:49 CEST] <TikityTik> for libvpx for example [17:07:47 CEST] <kepstin> if you want constant quality, then you shouldn't be using a buffer limit at all [17:08:13 CEST] <kepstin> the purpose of the buffer stuff is to limit the bitrate usage, causing quality to be reduced in complex scenes that would otherwise use too much bitrate [17:08:19 CEST] <TikityTik> i notice for libvpx that if i want to use cbr mixed with crf then you need bufsize [17:09:08 CEST] <TikityTik> thanks for letting me know though, i didn't notice crf actually works without bufsize [17:09:10 CEST] <DHE> constant quality and constant bitrate are mutually at odds. this is more constant quality with constrained bitrate [17:09:18 CEST] <kepstin> with libvpx, usind crf in combination with a bitrate causes the crf to be used as a maximum quality value (i.e. it will constrain the max quality) [17:09:47 CEST] <kepstin> so if there's a simple scene such that if it used the full bitrate, the quality will be over the specified crf value, then it'll limit it and use less bitrate [17:10:32 CEST] <TikityTik> ah so it's not maintain crf and use the bitrate as a max? [17:11:13 CEST] <kepstin> nope, it's the other way around [17:11:23 CEST] <TikityTik> is it not possible to do it in libvpx? [17:11:27 CEST] <kepstin> (with libvpx) [17:11:33 CEST] <kepstin> note that x264 works very differently [17:13:08 CEST] <TikityTik> is it not possible to maintain crf and have constrained bitrate with libvpx? [17:15:39 CEST] <kepstin> if you set a crf value such that the with most content the crf limit would be below the specified bitrate limit, then that's effictively what you'll get [17:24:08 CEST] <TikityTik> i see [17:24:11 CEST] <TikityTik> thanks [17:25:12 CEST] <kepstin> in other words - if you set the quality low enough that it wouldn't use all the available bitrate, then the bitrate limits won't have an effect. [17:48:56 CEST] <Numline1> Guys, I'm getting very close with my YUV handling :) [17:49:27 CEST] <Numline1> kepstin I think we spoke yesterday about how y4m output works. You've mentioned that the frame size is width x height x 1.5 for yuv420 [17:49:42 CEST] <Numline1> However I've noticed there's a "FRAME \n" thingie before each frame [17:49:50 CEST] <furq> Numline1: if you need to convert to jpeg anyway then you might as well just have ffmpeg output mjpeg [17:50:27 CEST] <Numline1> furq I'm actually considering it at this point. I managed to split the Y4M into separate frames, however I can't seem to open them [17:50:36 CEST] <Numline1> My header was 61 bytes [17:50:47 CEST] <furq> mjpeg is more or less just a bunch of concatenated jpegs [17:50:54 CEST] <furq> so just read from 0xFFD8 to 0xFFD9 [17:50:55 CEST] <Numline1> When I removed the FRAME \N part, I eliminated another 12 bytes (for two frames) [17:51:00 CEST] <furq> inclusive [17:51:17 CEST] <Numline1> furq what are those characters anyway? [17:51:25 CEST] <furq> jpeg SOI and EOI markers [17:51:33 CEST] <Numline1> ohh [17:52:14 CEST] <Numline1> Well my hex editor can't see them for some reason, 0 results [17:53:38 CEST] <Numline1> furq would you mind if I sent you a frame (yuv) to see whether it's correctly split? [17:53:53 CEST] <Numline1> I don't want to waste your time if you're busy [17:55:20 CEST] <furq> if you just save it as .yuv then mpv should be able to display it [17:55:53 CEST] <Numline1> furq both ffmpeg and mpv say [ffmpeg] IMGUTILS: Picture size 0x0 is invalid [17:56:04 CEST] <Numline1> I assume I saved an incorrect portion of the frame [17:56:22 CEST] <furq> no you just need to give ffmpeg the video size [17:56:24 CEST] <Numline1> the y4m file is playable okay [17:56:31 CEST] <furq> -video_size 123x456 -i foo.yuv [17:57:59 CEST] <Numline1> furq https://numshare.s3-eu-west-2.amazonaws.com/Screen-Shot-2019-04-25-17-57-55… [17:58:10 CEST] <Numline1> the ffmpeg part worked, but I still suspect it's broken :( [17:58:33 CEST] <Numline1> furq just to be sure - the "FRAME \n" part should be omitted from the final yuv when doing y4m to yuv? [17:59:36 CEST] <Numline1> Again, I did the math and basically width * height * 1.5 = <some_number>. The some_number + size of the header + amount_of_frames * 6 === file size [18:00:39 CEST] <Numline1> 6 is bytesize of FRAME\n [18:01:51 CEST] <furq> the actual frame data excludes the headers, yeah [18:01:56 CEST] <furq> https://clbin.com/ZyTNU [18:01:58 CEST] <furq> but also just use this [18:04:13 CEST] <furq> it's probably buggy but piping 8K mjpeg from ffmpeg worked [18:04:27 CEST] <Numline1> furq thank you very much for that (especially since it's in Go) [18:04:33 CEST] <Numline1> furq did you write that or find that? [18:04:41 CEST] <furq> i wrote it [18:04:59 CEST] <furq> it was a good excuse to actually use a bufio.Scanner [18:05:29 CEST] <Numline1> furq that's very cool from you. What do you think was wrong here? https://privatebin.net/?052cc1e5a8d2e804#/PDcbmE9TZPZR2a4fYz6X5WalmkbjRIi11… [18:05:38 CEST] <Numline1> We took very different aproaches I think [18:06:00 CEST] <Numline1> Scanner gave me some headaches lol :) I had to figure out when the file pointer was moving and when not :) [18:07:41 CEST] <Numline1> I was thinking about using scanner split functions, I was just thinking about newlines (someone in here advised I shouldn't use it as frame delimiter, since there can be the same character somewhere in the frame) [18:14:07 CEST] <furq> yeah there's no need for a scanner there really [18:14:38 CEST] <furq> i can't see anything obviously wrong with that code but i'd have to actually test it and see what it's doing [18:16:07 CEST] <Numline1> furq don't bother with that, I like your solution better tbh. I'm just trying to figure out how you came up with 1<<20 and 1<<22 [18:16:13 CEST] <Numline1> is that just random size? [18:16:15 CEST] <furq> yeah [18:16:17 CEST] <furq> 1MB and 4MB [18:16:34 CEST] <Numline1> furq neat. Could I possibly use that width x height * 1.5 formula for that? [18:16:52 CEST] <furq> the second argument to Buffer has to be larger or else it won't ever reallocate the buffer if it runs out of space [18:17:00 CEST] <Numline1> instead of 1<<20 and the same for the second one, but times the amount of frames [18:17:04 CEST] <furq> and uh [18:17:21 CEST] <furq> it's mjpeg so the frames are already compressed [18:17:46 CEST] <Numline1> damn, really? I always thought it's raw uncompressed data [18:17:52 CEST] <Numline1> that explains some problems [18:18:05 CEST] <Hello71> have you heard of "jpeg" [18:21:41 CEST] <Numline1> fair enough [18:27:26 CEST] <kubast2> Hey, how can I overlay transparently more than 2 videos? [18:28:57 CEST] <kubast2> or [18:29:10 CEST] <cfoch> Hello [18:29:40 CEST] <cfoch> I am reversing an audio file with this command: ffmpeg -y -i "$input_file" -af silenceremove=1:0:$ratio "$input_file" [18:29:54 CEST] <cfoch> but I note that for some reason the result file has less duration than the original one [18:29:58 CEST] <cfoch> any idea why? [18:30:15 CEST] <furq> did you also notice that it's not reversed [18:30:27 CEST] <cfoch> sorry [18:30:30 CEST] <cfoch> the wrong command [18:30:38 CEST] <cfoch> ffmpeg -y -i "$input_file" -af "areverse" "$input_file" [18:30:41 CEST] <cfoch> this is the command I use [18:31:11 CEST] <furq> don't use the same output filename as input filename [18:31:31 CEST] <kubast2> yep [18:31:40 CEST] <furq> ffmpeg -i in out && mv out in [18:32:00 CEST] <cfoch> I see [18:33:53 CEST] <durandal_1707> cfoch: ffmpeg version is? [18:34:27 CEST] <cfoch> ffmpeg version 4.0.3 Copyright (c) 2000-2018 the FFmpeg developers [18:34:44 CEST] <cfoch> in the new version using the same output file as the input file is allowed? [18:35:38 CEST] <durandal_1707> nope [18:36:23 CEST] <durandal_1707> anyway use latest ffmpeg version [19:47:36 CEST] <ChocolateArmpits> Using drawgrid, is it possible to have the lines be spaced non linearly? It seems the width or the height parameter simply takes the resultant expression value and uses that to plot lines at exact distances so I have to use mulitple filters to get what I want [19:48:26 CEST] <durandal_1707> nope, and why you need something different? [19:49:04 CEST] <ChocolateArmpits> What do you mean different? I don't want evenly spaced lines that's all [19:49:27 CEST] <durandal_1707> use geq filter [19:51:52 CEST] <pzich> wow, geq sounds pretty awesome [19:52:05 CEST] <ChocolateArmpits> okay that seems more like it [19:52:22 CEST] <ChocolateArmpits> hopefully it's not slow, seems to have slice threading [19:55:44 CEST] <ChocolateArmpits> I'm actually plotting volume bars for vertically displayed showvolume output of 16 channel audio input. The default volume measurement provided by showvolume is quite bad so not using it [19:56:22 CEST] <ChocolateArmpits> drawtext lists volume level at each predefined bar position [19:59:18 CEST] <durandal_1707> ChocolateArmpits: how can that be true? What is missing in that filter? [19:59:52 CEST] <ChocolateArmpits> durandal_1707, showvolume? [20:00:22 CEST] <durandal_1707> yes [20:00:59 CEST] <ChocolateArmpits> Well if the orientation is set to vertical then the volume indication is also drawn vertically, which makes it hard to read [20:01:52 CEST] <durandal_1707> anything else? [20:02:56 CEST] <ChocolateArmpits> The volume number updates with the frequency of the framerate, but even at 8 fps the updates are too often, but lowering it makes the volume bar update too sluggishly [20:03:25 CEST] <ChocolateArmpits> And the size of the volume indication is somewhat small and hard to read at higher sizes [20:03:32 CEST] <ChocolateArmpits> dimensions* [20:04:03 CEST] <ChocolateArmpits> So overall I plan to have it disabled especially because a few horiztaonl lines indicating volume level across 16 channels is just easier to view [20:05:14 CEST] <ChocolateArmpits> I mean I already have it working with 8 drawgrid filters, but I want a lighter filter command, so as you suggest, geq may help [20:34:48 CEST] <de-facto> Hey guys, I want to combine four "sprite" videos (a spinning object) along the four edges of a black canvas (combined output video). Each "sprite" needs rotation e.g. 0 deg, 90 deg, 180 deg and 270 deg [20:35:38 CEST] <de-facto> Is something like this scriptable with ffmpeg? the source "sprites" will be VP8 webm from either chrome or firefox [20:36:13 CEST] <__Shepherd> are the sprite vids still [20:36:19 CEST] <pink_mist> I know it's doable with ffmpeg, yes ... I haven't the faintest clues how [20:36:50 CEST] <__Shepherd> oh never mind [20:36:55 CEST] <de-facto> the sprites are rotations from a 3D object rendered with threejs (full rotations along axes) [20:37:25 CEST] <de-facto> maybe -filter_complex something? [20:37:31 CEST] <__Shepherd> let me get this straight [20:37:34 CEST] <pink_mist> yeah, probably [20:38:29 CEST] <__Shepherd> your sprite vids display rotation objects or the vid itself is yet to be made rotating [20:39:49 CEST] <de-facto> I have a 3D model (glb) which is rendered in the browser with threejs. This animation shows it rotating around specific axes and i capture this with ccapture.js to a webm VP8 video as "sprite". It shows the object rotating. [20:42:43 CEST] <de-facto> now i want to put this "sprite" four times along the edges of a big black canvas. Each "sprite" video rotated by 90 degrees: one normal orientation, second rotated 90 deg, third upside down and forth rotated 270 deg [20:43:02 CEST] <de-facto> video (2d) rotation that is [20:44:16 CEST] <__Shepherd> hang there a sec [20:47:51 CEST] <de-facto> correction its not upside down its all rotations 0, 90, 180, 270 deg, [20:49:03 CEST] <de-facto> it is going to be a "fake" hologram displayed by a monitor and its reflection is shown by a glas pyramid below. preferably it would need to show the four sprites at different timecodes [20:50:37 CEST] <de-facto> e.g. first from start, second 1/4 playtime, third 1/2 playtime, fourth 3/4 playtime to show correct "object" rotations [20:53:57 CEST] <de-facto> also the "sprites" would need to be looped for this i guess (until first sprite got one complete playtime) [20:57:13 CEST] <de-facto> output from the big black "canvas" should be a mp4 playable buy raspberry pi (e.g. 1600x1200 or such) [21:08:51 CEST] <__Shepherd> what's the size of your canvas? [21:09:02 CEST] <__Shepherd> and fps? [21:09:31 CEST] <__Shepherd> and duration? [21:10:30 CEST] <__Shepherd> guessing you want your duration to be a multiple of your sprite vid duration so it can loop w/ no problem [21:37:05 CEST] <de-facto> __Shepherd, first capture "sprite" is a 30s WebM in VGA (640x480) in VP8 codec 60fps, the canvas size is 1600x1200 in 60fps [21:39:00 CEST] <de-facto> " Stream #0:0: Video: vp8, yuv420p(progressive), 640x480, SAR 1:1 DAR 4:3, 60 fps, 60 tbr, 1k tbn, 1k tbc (default)" [21:40:41 CEST] <de-facto> i hope this fits in the video canvas, but i can adjust the sprite size prior to creating it (html canvas) [21:42:17 CEST] <__Shepherd> 640 x2 is 1280 but your canvas is only 1200 [21:42:57 CEST] <__Shepherd> some of your sprite video will be outside [21:44:07 CEST] <__Shepherd> *only 1200 in height [21:45:29 CEST] <de-facto> the sprite will be with its bottom edge along each outer edge of the big canvas (maybe with a margin, have to adjust the reflection probably), so its 480x2 = 960 < 1200 and 480x2 = 960 < 1600 [21:46:35 CEST] <__Shepherd> but your sprite vid is 640x480 [21:47:14 CEST] <de-facto> if it helps, this is my first capture of the sprite: https://uploadfiles.io/foi1hf1r [21:47:22 CEST] <__Shepherd> nah it will fit [21:49:35 CEST] <de-facto> yeah 640 is the width along each outer edge of the canvas, only the sprite height is perpendicular to this edges [21:49:39 CEST] <de-facto> *these [21:59:01 CEST] <__Shepherd> Uploaded file: https://uploads.kiwiirc.com/files/8ec67d8f3efdf889ff7dc74bef960fc9/rotation… [21:59:21 CEST] <__Shepherd> is that the effect you need de-facto [22:03:17 CEST] <de-facto> yeah kinda, but all four at once [22:04:01 CEST] <__Shepherd> all four to be visible at the same time? [22:06:38 CEST] <de-facto> yes with some seek offsets, like 0s, 1/4 playtime, 1/2 playtime, 3/4 playtime like this: https://s16.directupload.net/images/190425/xfrmtxcg.png [22:11:24 CEST] <__Shepherd> you want the bottom video1 to appear starting from 0s to 7.5s, then the video2 from 7.5s to 15s, video3 from 15s to 22.5s, finally video4 from 22.5s to 30s then have that looped [22:11:45 CEST] <__Shepherd> I'm not really sure I understand what you want to achieve [22:14:12 CEST] <Classsic> hi [22:14:28 CEST] <Classsic> somebody know how fix this "Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly" [22:14:55 CEST] <__Shepherd> de-facto or maybe you just want them to rotate in fast succussion with a predetermined interval between all of them [22:15:01 CEST] <JEEB> means that the AVPackets passed in the framework don't have timestamps [22:15:08 CEST] <de-facto> i want the target video to make a full loop (30s). It will be displayed on a 1600x1200 monitor with a raspi: its reflection will be on a glass pyramid (4 triangles), so the object appears as rotating in the middle of the glass pyramid: each sprite would have to loop for 30 seconds but start with offsets: 0s, 7.5s, 15s, 22.5s and loop for full 30 s [22:16:32 CEST] <__Shepherd> got it [22:17:24 CEST] <de-facto> e.g. sprite0 from 0->30s, sprite1 7.5s->7.5s (loop), sprite2 15s->15s (loop), sprite3 22.5s->22.5s (loop) [22:17:44 CEST] <de-facto> a bit difficult to explain, but its for correct object rotation angles for each reflection [22:17:50 CEST] <Classsic> ok, how I can fixit this? this is rtsp ----> rtp [22:18:00 CEST] <__Shepherd> that's actually much simpler [22:24:42 CEST] <de-facto> i probably would have to adjust it on the glass pyramid itself when it is working (e.g. symmetric distances from the center), but thats fine tuning... [22:25:47 CEST] <de-facto> either using a sprite aspect=1 or maybe even with black=transparent or such, but thats first order corrections [22:29:54 CEST] <de-facto> e.g. "project" the glass pyramid ground plane on the monitor (which is above facing downwards) and have the objects centers each one quater distance from the projection edges or such [22:46:42 CEST] <__Shepherd> Uploaded file: https://uploads.kiwiirc.com/files/fc01a195ee9597ccf2c35e25cf39eb95/rotation… [22:51:34 CEST] <de-facto> that looks almost perfect, how did you do this? [22:57:26 CEST] <__Shepherd> Uploaded file: https://uploads.kiwiirc.com/files/40c92e4515ad0cda5e7a6e238efee62c/ffmpegcm… [22:59:12 CEST] <de-facto> whoa thats a lot of advanced ffmpeg fu :) [23:00:03 CEST] <de-facto> need some time to understand this, but it looks really well :)) [23:01:14 CEST] <furq> the pi supports high(a)4.1 [23:01:32 CEST] <furq> so probably just get rid of profile and level [23:03:01 CEST] <furq> de-facto: http://vpaste.net/Z42lO [23:03:05 CEST] <furq> it's a lot easier to understand with line breaks [23:03:36 CEST] <de-facto> right now its a raspi2 with openelec i think [23:03:47 CEST] <furq> every pi has the same hwdec chip iirc [23:04:01 CEST] <furq> but if not then even the worst one does high(a)4.1 [23:04:30 CEST] <furq> it's been a long time since devices could only do baseline [23:05:01 CEST] <furq> also you probably want to remove -preset ultrafast if that wasn't obvious [23:05:24 CEST] <another> btw: is it possible to just set a max profile level for x264? [23:05:29 CEST] <de-facto> yeah mainly its the geometric and time layout that i could not do myself (ffmpeg noob here) [23:05:35 CEST] <furq> another: sort of [23:05:46 CEST] <furq> actually wait. no [23:05:54 CEST] <furq> it's only sort of possible to set the level at all [23:07:28 CEST] <de-facto> this is really a really cool script, thanks a lot __Shepherd [23:08:58 CEST] <__Shepherd> sorry I left the room my computer got sluggish. tell me if that works [23:09:26 CEST] <de-facto> it looks extremely well, im gonna need some time to understand [23:10:04 CEST] <__Shepherd> I hope someone can optimize on that cuz the loop filter sucks so much ram damn [23:10:12 CEST] <__Shepherd> so did it work for you? [23:11:20 CEST] <de-facto> kinda, have to adjust the positions and understand what it does [23:14:42 CEST] <de-facto> coordinates start in lower left corner? [23:15:07 CEST] <furq> __Shepherd: http://vpaste.net/BgihG [23:15:10 CEST] <furq> something like that (untested) [23:16:10 CEST] <furq> de-facto: top left [23:16:26 CEST] <de-facto> ok [23:17:52 CEST] <furq> https://ffmpeg.org/ffmpeg-filters.html#overlay-1 [23:19:18 CEST] <__Shepherd> I'm sorry [23:19:41 CEST] <__Shepherd> I let the X Y coordinates of my test run [23:21:50 CEST] <de-facto> its extremely helpful and even fun to use ffmpeg like this :) [23:22:38 CEST] <__Shepherd> Uploaded file: https://uploads.kiwiirc.com/files/954d0b7cf8ebe997742b3b0d917ab8e0/ffmpegcm… [23:23:41 CEST] <de-facto> coordinates work well adjusted: http://vpaste.net/E3zBj [23:24:31 CEST] <furq> de-facto: get rid of -preset ultrafast as well [23:25:25 CEST] <__Shepherd> yeah change whatever setting you like depending on your liking [23:29:22 CEST] <de-facto> this is awesome guys thanks a lot :)) [23:30:10 CEST] <__Shepherd> loop=3:1800:0 I have no explanation why I set loop's size to 1800 [23:30:31 CEST] <__Shepherd> but that's what worked [23:30:49 CEST] <de-facto> 30s*60fps=1800 frames maybe? [23:31:32 CEST] <__Shepherd> yes that's how I've calculated it [23:31:55 CEST] <__Shepherd> but I don't have a complete understanding of why it worked [23:32:32 CEST] <__Shepherd> other values just ruin the loop [23:34:43 CEST] <__Shepherd> there's a max limit in this option so you can't loop anything seamlessly [23:37:31 CEST] <__Shepherd> this is most likely the filter option that will cause you trouble when scripting to the raspberry [23:38:55 CEST] <__Shepherd> but since you are in control of making the overlay inputs I guess you could work something out [23:40:10 CEST] <de-facto> yeah i would have to feed it to the raspi tomorrow (I dont have it here right now) and adjust to the glass pyramid [23:41:05 CEST] <de-facto> but this is much better with ffmpeg, the other guys messed around with adobe premiere for this [23:51:02 CEST] <durandal_1707> de-facto: learn about hflip/vflip [23:52:53 CEST] <de-facto> i also need 90° rotations though [23:57:18 CEST] <durandal_1707> yes, but twice transpose is hflip/vflip [23:59:01 CEST] <de-facto> yes, orientation seems to be quite well like this: http://vpaste.net/8iW06 [00:00:00 CEST] --- Fri Apr 26 2019

1 0