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

ffmpeg-devel.log.20190424
by burek 25 Apr '19

25 Apr '19

[00:01:20 CEST] <durandal_1707> cehoyos: why? [00:02:19 CEST] <cone-633> ffmpeg 03Takayuki 'January June' Suwa 07master:f9a061a31c3d: avdevice/alsa: fix indefinite stop on closing PCM capture [00:03:08 CEST] <cehoyos> Why I was asking for aac? Or why I closed the ticket where it is claimed that either Dolby or DTS are "not normal" (don't remember which)? [00:03:40 CEST] <cehoyos> There is already a ticket for the stupid resampling for dts -> ac3 [00:03:49 CEST] <cehoyos> (a "new team" regression) [00:03:57 CEST] <cehoyos> sorry, a paid new team regression [00:04:29 CEST] <durandal_1707> frei0r [00:04:34 CEST] <cehoyos> ;-) [00:04:48 CEST] <cehoyos> The patch that fixes the warning is wrong afaict, I sent a new patch. [00:05:04 CEST] <cehoyos> But I could not really test so maybe I miss a lot... [00:06:28 CEST] <cehoyos> Please review [00:06:47 CEST] <durandal_1707> fetch frei0r and test it? [00:08:13 CEST] <cehoyos> I did and I can reproduce the original issue (before the patch last year) and the warning but frei0r crashes here elsewhere, but since my patch should not change the actual argument to frei0r, I don't think that really matters. [00:08:30 CEST] <cehoyos> The warning fix was just wrong imo. [00:09:04 CEST] <durandal_1707> where it crashes? [00:10:04 CEST] <cehoyos> Sorry, I removed the binary: An assertion failure in frei0r [00:11:21 CEST] <cehoyos> Did you look at my patch? [00:12:22 CEST] <durandal_1707> no, its not in mail as txt but attached as binary [00:12:58 CEST] <durandal_1707> tomorrow,now sleep time [00:13:05 CEST] <cehoyos> Good night! [00:20:02 CEST] <durandal_1707> patch looks fine, will test tomorrow [00:22:58 CEST] <cehoyos> Please do, thank you [01:41:49 CEST] <cone-633> ffmpeg 03Cyber Sinh 07master:499b46fd0a89: compat/windows/makedef: Allow building shared libs with MSVC under WSL [01:43:37 CEST] <cone-633> ffmpeg 03Carl Eugen Hoyos 07master:d0ca749adbf2: tests/fate-run: New variable hostexecsuf for local fate tools. [17:08:10 CEST] <cone-882> ffmpeg 03Michael Niedermayer 07master:caa9b4ff89c0: avcodec/agm: Check that there is available input in read_code() [17:08:10 CEST] <cone-882> ffmpeg 03Michael Niedermayer 07master:fee666104519: avcodec/dsicinvideo: check the amount decoded by cin_decode_huffman() [17:08:10 CEST] <cone-882> ffmpeg 03Michael Niedermayer 07master:9570322a2d8c: avcodec/dxtory: Check slice_size against minimum in dxtory_decode_v2() [17:08:10 CEST] <cone-882> ffmpeg 03Michael Niedermayer 07master:ed188f6dcdf0: avformat/aadec: Check for scanf() failure [17:08:10 CEST] <cone-882> ffmpeg 03Michael Niedermayer 07master:18a567c369d7: avformat/mov: Skip stsd adjustment without chunks [17:08:10 CEST] <cone-882> ffmpeg 03Michael Niedermayer 07master:6f0e9a863466: avutil/avstring: Fix bug and undefined behavior in av_strncasecmp() [17:08:10 CEST] <cone-882> ffmpeg 03Michael Niedermayer 07master:8b10f09fd537: avcodec/arbc: Skip unchanged frames [17:08:11 CEST] <cone-882> ffmpeg 03Michael Niedermayer 07master:7c2ee8d43d95: avcodec/arbc: Try to correct keyframe/frame type [17:10:45 CEST] <philipl> BtbN: so the nvenc thing? should we just make the change and document the assumption? [17:16:27 CEST] <jamrial> jkqxz: there's a bunch of cbs patches from andreas and some by me, if you can look whenever you have time [18:08:07 CEST] <BtbN> philipl, I looked into reverting the relevant patch, but it needs more indepth changes to do things properly. [18:08:30 CEST] <BtbN> And I haven't found time to do so yet. [18:10:33 CEST] <philipl> Bok [18:12:01 CEST] <BtbN> There are two patches which basically need reverted again, so there is only a global list of mappings, and not one per frame [18:14:55 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=bbe1b21022e4872bc64066… see commit message as to why it can't just be reverted. [18:18:03 CEST] <BtbN> ok, it's not as complicated. Unfortunately, I can't test if it works, cause I'm not seeing any performance regression at all. [18:21:58 CEST] <philipl> I assume these guys will let us know :-) [18:27:08 CEST] <BtbN> Did you see the patch about the nvidia h264 parser getting interlaced flags wrong? [18:49:26 CEST] <philipl> BtbN: I totally believe it. [18:49:52 CEST] <BtbN> It's easily reproducible (dude that sent the patch prepared half a dozen docker containers for some reason) [18:50:03 CEST] <BtbN> Run these in order to see! [18:50:17 CEST] <BtbN> And before that do these 12 commands to make using GPUs in Docker possible in the first place [18:50:27 CEST] <philipl> I did not think hard, but doesn't this mean that mixed interlacing streams will have problems because we are making a stream level decision? [18:50:55 CEST] <BtbN> I don't think so, cause the sequence callback will be re-called for those I believe. [18:51:50 CEST] <BtbN> Which is also why I moved the location where it's set from the original patch to the display callback [18:52:13 CEST] <BtbN> to make sure an intermediate re-call of the sequence callback does not make it use the new flag on old frames still in the queue [18:55:45 CEST] <BtbN> Where would you even document special behaviour of an encoder that only an API user would care about? [18:56:46 CEST] <BtbN> nvenc does not have an entry in encoders.texi. Maybe it should? [19:03:08 CEST] <JEEB> yea [19:03:30 CEST] <BtbN> philipl, I'm tempted to just #ifdef out the part that unregisters the frames. That way someone who really relies on the behavour can easily build a version that does so. [19:05:09 CEST] <BtbN> Could also turn it into a normal option, but it seems a bit arcane to expose that way. [19:05:24 CEST] <BtbN> Is there a way to make options hidden? [19:06:59 CEST] <BtbN> doesn't seem like it [19:07:47 CEST] <philipl> BtbN: we discussed making it an option when it first came up. I'd be ok with it. Others might not be. [19:08:19 CEST] <philipl> It's only relevant for a very customised application usage pattern. Documenting it as such seems to be fine. [19:20:43 CEST] <BtbN> philipl, https://github.com/BtbN/FFmpeg/commit/5f77951908677d1f9a0f27bb19ebaa6cb5679… [19:22:11 CEST] <nevcairiel> why not have fully compatible method be default, and the performance edge-case require special compilation? [19:24:55 CEST] <nevcairiel> potential leaks are worse then slowdown in extreme special cases [19:32:02 CEST] <philipl> because there's no way to directly use ffmpeg that requires the compatible path [19:32:15 CEST] <philipl> You need a custom pool allocator [19:32:23 CEST] <nevcairiel> people use APIs as well you know [19:32:38 CEST] <nevcairiel> and such an option is pretty well hidden [19:32:55 CEST] <philipl> Of course, but the edge case, in practice, the non-performant one. [19:32:58 CEST] <philipl> that's what I mean. [19:33:59 CEST] <philipl> When I say directly use, I mean you must provide a custom allocator that doesn't re-use a fixed pool to need the aggressive unregistration. [19:34:07 CEST] <philipl> You can't combine off-the-shelf parts to create that situation. [19:35:12 CEST] <nevcairiel> you would be surprised how many people just grab zeranoe windows builds to use the .dlls because they cant build their own [19:35:28 CEST] <nevcairiel> and even if you do compile yourself, finding and knowing about that option is still quite a step [19:36:49 CEST] <philipl> Oh, I thought it was a runtime option. [19:36:57 CEST] <philipl> I'm seeing now it's not [19:37:58 CEST] <nevcairiel> it could be i suppose, but even then the option thats not error prone in some situations is usually favorable over performance optimizations [19:38:21 CEST] <nevcairiel> ideally you would be able to detect this from the pool or something [19:47:04 CEST] <BtbN> nevcairiel, it's not a leak though [19:47:15 CEST] <BtbN> The resources are eventually unregistered [19:47:31 CEST] <BtbN> Just not immediately, but at the end of the session, of if the buffer is full [19:48:05 CEST] <nevcairiel> so what actually happens if i use new buffers for every frame? [19:48:49 CEST] <BtbN> The undefined situation happens when you free the CUdevptr that nvenc still has registered [19:49:21 CEST] <BtbN> as long as you just keep feeding in an endless stream of new handles it will eventually run out of buffer space to store them, free one, and register there. [19:49:34 CEST] <nevcairiel> obviously i would relesae those frames [19:49:43 CEST] <BtbN> What happens then is up to the nvidia driver. [19:50:02 CEST] <BtbN> If it implicitly unregisters them, and doesn't complain when trying to do so again, all will be fine [19:51:10 CEST] <BtbN> But in what situation would you not keep re-using the same set of input surfaces over and over again? [19:52:10 CEST] <BtbN> Keep in mind that the behaviour I'm restoring right now was the default in nvenc for the longest time, and nobody ever had issues. [19:54:36 CEST] <BtbN> I'm just gonna try doing that, it's an easy test [19:59:37 CEST] <BtbN> nevcairiel, how do I free whatever d3d11va gives to nvenc in frame->data[0]? [19:59:42 CEST] <nevcairiel> this only affects cuda input, not software or d3d? [19:59:56 CEST] <BtbN> Software input does not care, d3d11va is equally affected [20:01:50 CEST] <nevcairiel> ID3D11Texture2D_Release(frame->data[0]) i think [20:02:06 CEST] <BtbN> yeah, looking at the hwcontext stuff for it, seems like that's it [20:02:45 CEST] <nevcairiel> not sure if it needs a cast [20:02:46 CEST] <nevcairiel> maybe [20:02:47 CEST] <BtbN> I have just thrown that in right after registering a frame, and then try to unregister it again right away [20:02:51 CEST] <BtbN> ID3D11Texture2D_Release((ID3D11Texture2D *)frame->data[0]); [20:03:14 CEST] <nevcairiel> the way d3d11 frames are allocated its even less l ikely to get that problem tho [20:03:52 CEST] <BtbN> If the unregister succeeds (or throws a well defined error like "not registered"), there is no need for the special flag in the first place [20:04:02 CEST] <BtbN> cause that can be handled and safely ignored [20:07:20 CEST] <nevcairiel> thinking about it, d3d11 is a bad test, since there is only one ref-counted texture object with X layers, so it'll never actually be free'ed [20:09:52 CEST] <BtbN> Yeah, d3d11 has those sub layers [20:27:31 CEST] <BtbN> it works just fine if I free the thing. Unregisters without errors [20:27:35 CEST] <BtbN> for d3d11 [20:27:38 CEST] <BtbN> testing CUDA now [20:28:42 CEST] <BtbN> Yeah, works just fine as well. [20:41:17 CEST] <philipl> BtbN: so you can unregister after free in practice? [20:41:36 CEST] <BtbN> it does not throw an error at least [20:41:50 CEST] <philipl> heh. Ship it. [20:47:11 CEST] <BtbN> I guess it would explode if you were to actually re-use it [20:58:06 CEST] <philipl> BtbN: I don't get the first_round thing [20:59:30 CEST] <BtbN> It avoid unregistering frames if there are still slots without a registered frame int hem [20:59:34 CEST] <BtbN> *in them [21:00:02 CEST] <BtbN> Cause right now, if it's looking for an unmapped spot, it'll just unregister whatever is in there [21:00:28 CEST] <BtbN> And not prefer fully empty ones [21:01:08 CEST] <philipl> ah, ok. [21:05:04 CEST] <BtbN> though in reality, it'll never reach that function again after a short while, because all input surfaces will be registeres already [21:10:54 CEST] <philipl> sure. [22:57:25 CEST] <cone-887> ffmpeg 03Paul B Mahol 07master:e1cfb01b054b: avfilter/af_surround: fix typo [22:57:25 CEST] <cone-887> ffmpeg 03Paul B Mahol 07master:e1e0f94dc956: avfilter/af_surround: add angle option [22:57:25 CEST] <cone-887> ffmpeg 03Paul B Mahol 07master:2d16b83824c1: avfilter/af_surround: check for invalid magnitude and phase difference [22:57:25 CEST] <cone-887> ffmpeg 03Paul B Mahol 07master:604421630bd5: avfilter/af_surround: improve rear channels separation [23:36:41 CEST] <cone-887> ffmpeg 03James Almer 07master:53cc3338f7b2: avcodec/h264_ps: fix storage size for offset_for_ref_frame [23:36:42 CEST] <cone-887> ffmpeg 03James Almer 07master:a42e761b9623: avcodec/h264_ps: use get_se_golomb_long() to parse some sps fields [00:00:00 CEST] --- Thu Apr 25 2019

1 0

ffmpeg.log.20190424
by burek 25 Apr '19

25 Apr '19

[00:01:29 CEST] <BtbN> mkv is just fine [00:08:36 CEST] <dablitz> can anyone continue to help me [00:08:50 CEST] <cehoyos> Yes [00:09:00 CEST] <dablitz> cehoyos: [00:09:18 CEST] <cehoyos> No, sorry, I don't know much about rtp (if that is the question) [00:09:29 CEST] <dablitz> yes that is the question [00:11:33 CEST] <Atlenohen> calamari: OBS broadcaster specifically uses MKV for failsafe when abrupt shutdown or crash, I was benchmarking, ran out of RAM, it crashed, the video was fine [00:11:47 CEST] <cehoyos> He has left [00:11:52 CEST] <Atlenohen> Oh [00:12:18 CEST] <cehoyos> But using broken mkv as "failsafe" is of course also not a useful answer;-) [00:12:29 CEST] <cehoyos> Do you still have your configure line? It looked a little broken to me... [00:12:36 CEST] <Atlenohen> Atleast in comparison to MP4 [00:13:22 CEST] <Atlenohen> You mean my ffmpeg compiling saga? [00:13:37 CEST] <cehoyos> Iirc, you used both --disable-all and --disable-everything [00:13:59 CEST] <cehoyos> everything is a debug options that you should not use and it is always a subset of all [00:14:13 CEST] <cehoyos> You should not use "--disable-everything"! [00:14:14 CEST] <cehoyos> You should not use "--disable-everything" [00:14:39 CEST] <Atlenohen> Oh I did sort it out tho fully, however, I'll check that right now [00:14:40 CEST] <cehoyos> Don't remember the other issues atm, saw them in the log [00:14:59 CEST] <cehoyos> But if you run "./ffmpeg", I can have another look [00:16:10 CEST] <cehoyos> I meant: If you post your configure line again, I can have a look [00:16:38 CEST] <Atlenohen> FFmpeg was building fine, the two other issues were that I had to modify x264.header for ffmpeg to know it's getting a static x264 lib instead of dynamic, the X264_API_IMPORTS stuff [00:17:06 CEST] <Atlenohen> and I had to simply include bcrypt.lib in the additional libraries of the project settings linker in VS2017, presto [00:17:09 CEST] <elmofan> can any deshaker for ffmpeg also correct rotational shake? or is it all translation? [00:17:34 CEST] <Atlenohen> Sure [00:17:58 CEST] <cehoyos> Of course, I believed we resolved bcrypt originally ("in a minute" iirc), you just added some additional options, some of them are wrong afair, one of them was "--disable-everyhing" [00:18:05 CEST] <Atlenohen> not sorry, to ceyehos: sure I can, moment, [00:18:34 CEST] <Atlenohen> I did fiddle in depth with the options too, but I don't remember [00:19:07 CEST] <Atlenohen> cehoyos: # ./configure.txt --toolchain=msvc --arch=x86_64 --target-os=win64 --extra-cflags=-I./dependency/x264/include --extra-cflags=-MT --extra-cflags=-GS- --extra-ldflags='-LIBPATH:./dependency/x264/lib' --prefix=./CAKE --disable-all --disable-everything --disable-network --disable-debug --enable-static --enable-avformat --enable-avcodec --enable-swscale --enable-swresample --enable-gpl --enable-protocol=file --enable-muxer='matros [00:19:07 CEST] <Atlenohen> ka,mpegts,mxf,webm,rawvideo,frame*' --enable-libx264 --enable-encoder='mpeg4,libx264*,bmp,ffv*,rawvideo' [00:19:25 CEST] <cehoyos> Are you using msys or wsl? [00:19:29 CEST] <Atlenohen> msys2 [00:20:04 CEST] <Atlenohen> it's more like msys2+mingw64, properly. [00:20:07 CEST] <cehoyos> Remove arch (it does not do what you think it does, if it had an effect, it would break compilation) and target [00:20:45 CEST] <cehoyos> Remove --disable-everything (it is a subset of all, and a subset that you are not interested in) [00:21:14 CEST] <cehoyos> Remove --disable-static (it has been the default since forever, much more than a decade) [00:21:21 CEST] <cehoyos> Remove --enable-static (it has been the default since forever, much more than a decade) [00:21:23 CEST] <cehoyos> (sorry) [00:21:41 CEST] <Atlenohen> You sure, I did went into the configure and hard edited some stuff that were annoying me, but it's working now, althought, who knows maybe theres some unforseen consequences when encoding [00:22:00 CEST] <cehoyos> Remove --disable-network as it is a subset of --disable-all [00:22:08 CEST] <Atlenohen> Ah if it's a subset then probably not necessary [00:22:16 CEST] <cehoyos> Yes, I am sure that --enable-static is the default since forever and that forever is >10 years [00:24:05 CEST] <Atlenohen> I see that there's multiple things leading to x86 like i[3-6]86*|i86pc|BePC|x86pc|x86_64|x86_32|amd64) [00:24:05 CEST] <Atlenohen> arch="x86" - so I left it be as it probably didn't break anything [00:24:32 CEST] <cehoyos> Again: arch breaks compilation [00:24:53 CEST] <cehoyos> target is useless because it is set by toolchain=msvc [00:25:16 CEST] <Atlenohen> how does it break it? [00:26:03 CEST] <cehoyos> If your compiler actually is configured for "x86_64", arch does nothing, if your compiler happens to be configured for another target, arch breaks (or maybe: can break) compilation [00:26:06 CEST] <cehoyos> Please remove it [00:26:11 CEST] <cehoyos> to be on the safe side. [00:28:27 CEST] <cehoyos> Did you benchmark "-GS-"? I ask because I believe we should make it the default (but only if it has an effect). [00:29:07 CEST] <Atlenohen> Not, I've not done that specifically, since I did more side stuff in the VS project [00:29:32 CEST] <Atlenohen> However MSVC has win32 not win64 as the target_os_default [00:29:56 CEST] <Atlenohen> and there is no arch [00:30:35 CEST] <cehoyos> There is no difference between "win32" and "win64" [00:30:49 CEST] <cehoyos> There is no arch because the option can break compilation, you should not use it [00:30:49 CEST] <Atlenohen> yeah it's one of those duds again [00:30:59 CEST] <cehoyos> (Unless you cross-compile which you are not) [00:31:32 CEST] <cehoyos> If you have not benchmarked it, why do you use it? [00:31:52 CEST] <Atlenohen> most of this stuff was in the original configure statement [00:32:16 CEST] <cehoyos> Do you know what -GS- does? [00:32:33 CEST] <Atlenohen> which is several years old, or so, when I wasn't around [00:32:43 CEST] <Atlenohen> I figured out all the options yes [00:32:51 CEST] <cehoyos> So what does it? [00:33:41 CEST] <Atlenohen> I had to, It was quite a run, I worked 16 hours strait for 3 days lol, finally found I suppose to be using -LIBPATH: not -L [00:33:57 CEST] <Atlenohen> Disables buffer security [00:34:28 CEST] <cehoyos> That took me more than a minute arguably (in the meantime I also compiled for Windows but decided to use wsl, not msys), but fortunately not days;-) [00:34:43 CEST] <cehoyos> to find out about LIBPATH [00:35:07 CEST] <cehoyos> But I decided to install into /lib/x86-64/whatever to avoid this issue;-) [00:36:11 CEST] <Classsic> hi [00:36:35 CEST] <Classsic> somebody know how add buffer on rtp output? [00:38:59 CEST] <Atlenohen> the linker is looking at 5 places in my case by default, without LDFLAGS, unfortunately I figured that out too late, some lib folders in MS NET, SDK and VC paths on the system, but the two easy ones were that it looked in msys64/mingw64/lib/x264.lib and ffmpeg's root github folder all that time, facepalm [00:40:15 CEST] <Atlenohen> it does not look into ffmpeg-repo/lib/x86-64/ AFAIK [00:46:42 CEST] <Atlenohen> would be a good idea updating configure for using LIBPATH: for windows, it's only using it one odd case in PKCONFIG but even that by just [00:47:27 CEST] <Atlenohen> And there's a lot of other stuff in those 3 days, that was quite a summary I made there [01:45:36 CEST] <Atlenohen> later [02:10:55 CEST] <LunaLovegood> The docs about AVCodecContext::time_base say to use 1/framerate, but wouldn't 1/90000 make more sense for MPEG stuff? [07:08:36 CEST] <elmofan> how can i auto-censor faces [13:49:01 CEST] <Numline1> Hey guys. So, what does -ss stand for? [13:49:08 CEST] <Numline1> I know it's for seeking, but what's the other s [13:49:15 CEST] <Numline1> seek start? [14:01:20 CEST] <DHE> it may just be different than -s because it's already used for scaling the image size. eg: -s 1920x1080 [14:14:04 CEST] <Numline1> DHE tl;dr ffmpeg devs are nazis [14:18:30 CEST] <Numline1> anyway, jokes aside - I was kind wondering, with all the protocols supported by ffmpeg [14:18:53 CEST] <Numline1> I kinda need to process a file from Google Storage without downloading it locally [14:19:08 CEST] <Numline1> Since my app running in app engine can't really access local storage anyway [14:19:15 CEST] <Numline1> what protocol could be used for this? [14:19:24 CEST] <Numline1> it seems async could be the one? [14:22:44 CEST] <DHE> you can always write your own or shoehorn a pipeline that the ffmpeg CLI makes awkward or impossible. [14:26:42 CEST] <Mavrik> Just read via HTTP? :) [14:27:04 CEST] <DHE> Maybe. If you need to do something more complicated, see doc/examples/avio_reading.c to write your own IO handler for ffmpeg [14:27:37 CEST] <Numline1> DHE Well, I suck at C so that's a nope :) [14:27:44 CEST] <Numline1> Mavrik will it be a streamed input though? [14:28:15 CEST] <Numline1> I'm actually going to try it right now, but I do a lot of seeking and stuff, so I'd prefer the file doesn't get downloaded in its entire for no reason [15:00:18 CEST] <elmofan> did you know the talmud is pure evil? [16:08:02 CEST] <PixelHir> Hi, I need a bit of help [16:08:14 CEST] <PixelHir> How can you convert mp3 to mp4? without image etc, sound only [16:08:26 CEST] <PixelHir> Facebook's voice messages are stored in mp4 for some reason [16:08:34 CEST] <PixelHir> and i need to convert but i don't know how [16:12:56 CEST] <pink_mist> ffmpeg -i in.mp3 -a:c copy out.mp4? [16:13:15 CEST] <DHE> that's -c:a [16:13:40 CEST] <pink_mist> ah [16:33:59 CEST] <Numline1> Folks, one more question - is it possible to pipe out from ffmpeg when creating multiple output files/images? [16:34:32 CEST] <Numline1> I'm doing this at the end of my command - thumb%04d.jpg [16:34:43 CEST] <Numline1> And I'm trying to process the result programatically if possible [16:37:28 CEST] <Numline1> ffmpeg -ss 1 -i https://example.com/test.mp4 -t 200 -vf scale=1280:-1,thumbnail=50 -vsync 0 thumb%04d.jpg [16:37:32 CEST] <Numline1> would be the entire command :) [16:37:34 CEST] <kepstin> Numline1: you can with some image formats (using either image2pipe or mjpeg for example), but note that ffmpeg will simply write one frame then the next, so you have to parse the images yourself afterwards. [16:38:05 CEST] <kepstin> (you might consider a raw image format rather than e.g. jpg if you're passing it to another program - then the images are all fixed sizes and you don't have to decode it again) [16:38:22 CEST] <pomaranc> Numline1: aren't you from slovakia by any chance? [16:38:56 CEST] <Numline1> kepstin yeah that's what I was wondering how that behaves. One output is easy to handle, multiple outputs to stdout are a mystery to me :) [16:39:00 CEST] <Numline1> pomaranc o/ [16:39:34 CEST] <kepstin> Numline1: it's not multiple outputs, it's just one output, a stream of bytes containing one image then the next. [16:39:48 CEST] <Numline1> kepstin will it send EOF though? [16:39:55 CEST] <Numline1> if so, I can easily handle that I think [16:39:56 CEST] <kepstin> Numline1: only after the last frame [16:40:26 CEST] <Numline1> kepstin that's a problem :D [16:40:55 CEST] <kepstin> that's why I recommend using a raw image format - since each frame is the same number of bytes (calculated from frame size), you just read N bytes, treat as a frame, repeat. [16:43:24 CEST] <Numline1> kepstin well, that might work, if it's not prone to errors. What I'm actually doing is I'm processing a video in Go, trying to get multiple outputs. Since the app is going to run in app engine, I'm avoiding file writes. I can get a Reader from the stdout and pass that directly to Google Storage library [16:43:56 CEST] <Numline1> but let's pretend it's language agnostic - doesn't ffmpeg output also some verbose crap to stdout? [16:44:06 CEST] <kepstin> no, stderr (and you can turn that off) [16:46:24 CEST] <Numline1> I mean, I'm getting stuff like [16:46:25 CEST] <Numline1> ffmpeg version 4.1.1 Copyright (c) 2000-2019 the FFmpeg developers [16:46:25 CEST] <Numline1> built with Apple LLVM version 10.0.0 (clang-1000.11.45.5) [16:46:36 CEST] <Numline1> judging by the exit code, it might be stdout, but I'm not arguing with you [16:47:07 CEST] <another> that is going to stderr [16:47:14 CEST] <Numline1> oh :) good to know [16:47:36 CEST] <Numline1> kepstin another okay guys, anyway, I'm going to fiddle with it a bit more, thanks for the tips on handling the outputs :) much appreciated [17:11:41 CEST] <Numline1> kepstin so um :) I was trying your advice about raw data - ffmpeg -ss 1 -i https://something.com/something.mp4 -t 200 -vf scale=1280:-1,thumbnail=50 -vsync 0 -f data - | cat - [17:11:47 CEST] <Numline1> Output file #0 does not contain any stream [17:11:59 CEST] <Numline1> The error kinda makes sense, but I'm not sure why the output needs to contain a stream [17:12:50 CEST] <furq> Numline1: you want -f rawvideo [17:13:09 CEST] <Numline1> oh shoot, yea, I just found that furq [17:13:10 CEST] <furq> although you probably actually want something like -f yuv4mpegpipe [17:13:10 CEST] <kepstin> Numline1: the "data" format isn't what you want here. Try something like "-pix_fmt bgr0 -f rawvideo" (change the -pix_fmt option to taste) [17:13:19 CEST] <Numline1> I thought that doesnt make sense since the output is actually images :) [17:13:27 CEST] <furq> video is actually images [17:13:40 CEST] <Numline1> touche [17:14:00 CEST] <furq> if go has an mjpeg demuxer/decoder then that's probably the easiest answer [17:14:38 CEST] <furq> or a y4m demuxer [17:15:06 CEST] <Numline1> well I found an encoder (images > video) [17:15:16 CEST] <Numline1> I wonder if it has the reverse :) [17:15:26 CEST] <furq> the problem with rawvideo is you need to hardcode the dimensions, pixel format etc in your receiving application [17:15:29 CEST] <Numline1> I liked the idea kepstin had, to use rawvideo and just somehow separate the bytes [17:15:43 CEST] <furq> y4m is pretty much the same thing except with a header that contains all that [17:15:51 CEST] <furq> you could probably write a demuxer in five minutes [17:16:02 CEST] <furq> https://wiki.multimedia.cx/index.php/YUV4MPEG2 [17:16:29 CEST] <Numline1> Okay, I'll try y4m and output that stuff into a file to see the format. I can probably easily decode that into images by just reading the file via buffer [17:16:35 CEST] <Numline1> furq kepstin thanks again fellas [17:16:40 CEST] <kepstin> with raw video, as long as you know the frame size and pixel format in advance, reading a frame is just "read width * height * bytes per pixel bytes into a buffer" [17:16:45 CEST] <kepstin> and repeat :/ [17:16:54 CEST] <furq> yeah which is fine if that's always the same [17:17:09 CEST] <furq> if it's not and you're using yuv images anyway (which you are if it's always jpeg) then y4m will ultimately be less hassle [17:17:39 CEST] <Numline1> Yeah, that would be ez to implement, I just don't trust that rawvideo solution. It's probably just a matter of time before something somewhere breaks and suddenly there's a frame that's incorrect and it screws all further images [17:17:43 CEST] <kepstin> y4m (or even something like nut) lets ffmpeg pass the information about width, height, pixel format, etc. to you in the container. [17:18:12 CEST] <Numline1> tbh I honestly wish I could just output the files somewhere and get JSON from ffmpeg on output to see where they are [17:18:26 CEST] <furq> there is an image2pipe muxer but i don't think anyone's ever used it [17:18:30 CEST] <kepstin> there's more moving parts involved encoding video, stuffing it into a container, demuxing it, and decoding it again... tbh i'd normally expect that to be more fragile :) [17:18:30 CEST] <furq> only the demuxer is documented anywhere [17:18:31 CEST] <Numline1> or just somehow loop the ffmpeg in some weird way and get single image for each loop [17:19:04 CEST] <Numline1> furq yeah but image2pipe (if it does what the name sounds like) probably only does one image :) [17:19:23 CEST] <furq> well the demuxer is used like cat *.jpg | ffmpeg -f image2pipe -i - ... [17:19:29 CEST] <furq> so i assume the muxer works the same way [17:19:29 CEST] <kepstin> no, image2pipe puts multiple images into a pipe [17:19:46 CEST] <furq> it's worth trying just to see what it actually outputs [17:19:48 CEST] <Numline1> kepstin yeah, but you still have to process and split them eventually :) [17:19:53 CEST] <kepstin> but i'm pretty sure it has the issue that it doesn't indicate frame boundaries in any way, you're required to parse the image somehow to find them [17:20:02 CEST] <furq> yeah i'm not sure about that either [17:20:34 CEST] <Numline1> yeah, the yuv thingie seems to be more viable in the end [17:21:10 CEST] <kepstin> but yeah, I use the piped raw video quite a bit in production, one app I have is actually a python script that renders frames with pycairo and then sends them to ffmpeg over a pipe to be encoded. [17:21:54 CEST] <Numline1> kepstin I'll save that as a fallback if YUV4MPEG2 fails for some reason, I already have metadata from ffprobe anyway [17:25:06 CEST] <Numline1> ERROR: yuv4mpeg can only handle yuv444p, yuv422p, yuv420p, yuv411p and gray8 pixel formats. 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. [17:25:08 CEST] <Numline1> yikes [17:25:10 CEST] <Numline1> which one do I want [17:25:21 CEST] <furq> don't set -pix_fmt at all [17:25:55 CEST] <Numline1> furq that's when I got the error :P [17:26:26 CEST] <Numline1> ffmpeg -ss 1 -i https://blah.com/mp4 -t 200 -vf scale=1280:-1,thumbnail=50 -vsync 0 -f yuv4mpegpipe - | cat > test.txt [17:26:52 CEST] <furq> what pixel format is the input video [17:28:23 CEST] <Numline1> ooff. It can be pretty much anything in the actual app. When it comes to this specific one, I'm not sure, how can I find out? [17:28:38 CEST] <Numline1> I ran ffprobe on it, I just dont see it there [17:29:35 CEST] <furq> Stream #0:0: Video: h264 (High), yuv420p(progressive), 1920x1080, 30 fps, 30 tbr, 1k tbn, 60 tbc (default) [17:29:41 CEST] <furq> it should say there [17:29:59 CEST] <furq> like 99% of videos you'll ever encounter are yuv420p so i figured y4m was a safe bet [17:30:18 CEST] <Numline1> furq oh :) Stream #0:1(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 2161 kb/s, 30 fps, 30 tbr, 30k tbn, 60 tbc (default) [17:30:40 CEST] <Numline1> I ran a ffmpeg command from stackoverflow which should determine that, it said: yuv420p [17:30:44 CEST] <another> furq: except mjpeg [17:31:03 CEST] <furq> mjpeg is always one of the supported y4m pixel formats [17:31:54 CEST] <another> Stream #0:0: Video: mjpeg (MJPG / 0x47504A4D), yuvj422p(pc, bt470bg/unknown/unknown), 1280x720, 18252 kb/s, 23.98 fps, 23.98 tbr, 23.98 tbn, 23.98 tbc [17:32:08 CEST] <furq> yuvj422p isn't a real pixel format [17:32:20 CEST] <furq> although idk how the y4m muxer deals with that [17:32:21 CEST] <another> it's not? [17:32:33 CEST] <furq> no it's just yuv422p with the full range flag [17:32:41 CEST] <Numline1> well I add -pix_fmt yuv420p and it works (?) [17:32:43 CEST] <furq> using the yuvj pixel formats has been deprecated for ages [17:32:47 CEST] <Numline1> It started spitting out output at least [17:33:06 CEST] <Numline1> however I can't verify it makes sense (the output), it's bunch of jibberish at this point [17:33:53 CEST] <another> furq: does this full range flag mean anything? [17:34:12 CEST] <furq> it means full colour range (0-255) instead of limited range (16-235) [17:34:31 CEST] <furq> limited range is a tv thing which is why jpeg doesn't use it [17:34:48 CEST] <Numline1> Well, I've piped the output to a file, the header says YUV4MPEG2 W1280 H720 F30:1 Ip A1:1 C420mpeg2 XYSCSS=420MPEG2 [17:34:48 CEST] <Numline1> FRAME [17:34:59 CEST] <Numline1> I guess that's it and it worked :) Now I just need to decode it in Go [17:35:27 CEST] <Numline1> The first result in Google is to use ffmpeg, lol [17:35:58 CEST] <furq> ok i checked and yuvj444p to y4m works fine [17:36:01 CEST] <furq> so that's nice to know [17:36:12 CEST] <furq> i have no idea why it would want you to set pix_fmt with a yuv source though [17:36:37 CEST] <Numline1> No idea man, but since it's the default one anyway... [17:36:55 CEST] <Numline1> Thanks again though, hopefully I'll be able to go from here [17:37:01 CEST] <Numline1> literally, since I'm using Go [17:37:08 CEST] <Numline1> *awkward silence* [18:00:05 CEST] <irwiss> not seeing this mentioned anywhere so could be a silly question, but given a naive read_frame/send_packet/receive_frame decoding loop, can frames come out of decoder out-of-order when using udp transport(or may be tcp too?) [18:01:35 CEST] <Mavrik> You'll get broken frames first [18:01:46 CEST] <Mavrik> Although it's not very likely :) [18:01:56 CEST] <Mavrik> Basically the decoder needs packets in order since frames depend on each other [18:02:17 CEST] <Mavrik> But most protocols that use UDP have some kind of timestamp counter so you can reorder packets back :) [18:02:20 CEST] <irwiss> ah so if i need to reorder it has to happen before decoder gets them [18:02:34 CEST] <Numline1> kepstin sorry, one more thing if you don't mind. You've mentioned it's basically width * height * bytes per pixel. How do I figure how many bytes there are per pixel? [18:02:48 CEST] <furq> Numline1: the pixel format [18:03:12 CEST] <furq> 4:2:0 is 12 bits per pixel, 4:2:2 is 16, 4:4:4 is 24 etc [18:03:19 CEST] <kepstin> Numline1: for this application, you'd request ffmpeg convert to a specific pixel format with a known bits/bytes per pixel [18:03:37 CEST] <furq> well y4m signals that so you could just handle it in your code [18:03:42 CEST] <irwiss> Mavrik: thanks i think this clears up my confusion [18:03:44 CEST] <Numline1> Oh I already did that, yuv420p [18:03:47 CEST] <Numline1> I'm a dummy :) Thanks! [18:03:51 CEST] <Mavrik> There's a helper function somewhere [18:03:58 CEST] <Mavrik> That gives you number of bytes per plane for pixel format [18:04:00 CEST] <pink_mist> furq: but those are bits, not bytes ... and 12 bits is hard to fit along a byte boundary :P [18:04:12 CEST] <furq> fortunately 4:2:0 is always mod2 [18:05:00 CEST] <Mavrik> Yeah, but YUV420P will be planar [18:05:08 CEST] <Mavrik> So you'll have a plane that's width*height [18:05:10 CEST] <Mavrik> and two planes that are half [18:05:18 CEST] Action: Numline1 is confused [18:05:41 CEST] <Numline1> "two planes that are half" [18:05:49 CEST] <Numline1> ChanServ: NSA wants to know your location [18:06:16 CEST] <furq> Numline1: if you're just handing the frame off to something else, it's not something you need to care about [18:07:10 CEST] <Numline1> furq oh, I'm actually trying to split that YUV4MPEG2 input into separate frames [18:07:19 CEST] <Mavrik> That's fine then [18:07:24 CEST] <Mavrik> I mean, everything will be in AVFrame struct [18:07:27 CEST] <Mavrik> And you don't need to care [18:07:29 CEST] <Mavrik> :) [18:07:41 CEST] <Numline1> oh is it in a separate struct? I didn't see that in the binary blob [18:07:44 CEST] <Numline1> I've seen the header [18:07:51 CEST] <Numline1> I thought I had to do the math myself [18:07:54 CEST] <furq> Mavrik: this is ffmpeg.c's y4m output being read into something else [18:08:19 CEST] <Numline1> oh, yeah, that's true. AVFrame is a ffmpeg struct [18:08:25 CEST] <Numline1> I just have the raw output [18:09:24 CEST] <Numline1> basically just to sum up, all I need is to split the output (input in my app) into a bunch of images. Since it's 12 bits, I'm not entirely sure I'll be able to find the amount of bytes per frame [18:09:37 CEST] <furq> Numline1: like i said, a 4:2:0 frame is always mod2 [18:09:38 CEST] <Numline1> this is all new to me, so the answer might be obvious though [18:09:45 CEST] <furq> so it'll always be some multiple of 48 bits [18:10:39 CEST] <Numline1> thinking emoji [18:10:51 CEST] <furq> which is to say width * height * 1.5 will always be an integer [18:11:03 CEST] <Mavrik> Numline1: YUV420 frames are funny because as opposed to more usual RGB images, they have one channel that's full sized (Y) and two channels that are half sized (UV) [18:11:17 CEST] <Mavrik> so the size of each frame is width * height * 1.5 :) [18:11:31 CEST] <kepstin> actually quarter size - U and V are both 1/2 height and 1/2 width [18:11:36 CEST] <furq> half sized in both dimensions yeah [18:11:54 CEST] <Numline1> y u do this frames [18:12:21 CEST] <Numline1> Mavrik I understand what you're saying, I just can't imagine how that's actually looking in the end (the frame) [18:12:25 CEST] <Numline1> isn't it stretched? [18:12:33 CEST] <furq> the U and V planes are chroma [18:12:45 CEST] <furq> so you have full-size luma and then the chroma planes are resized to match on playback [18:12:56 CEST] <furq> like i said, 99% of video uses 4:2:0 [18:13:00 CEST] <kepstin> Y is encoder full resolution, U and V are quarter resolution because they encode information the eye is less sensitive to [18:13:09 CEST] <furq> so you've seen it a million times and never noticed [18:13:55 CEST] <Numline1> that's interesting and a bit funky :) [18:14:03 CEST] <furq> unless you've seen youtube videos of screen captures or coloured text overlays and wondered why they look so bad [18:14:04 CEST] <JEEB> yes, all players and things convert YCbCr to RGB [18:14:05 CEST] <Numline1> I always thought it's just a series of x y images [18:14:22 CEST] <JEEB> yes, it's three "images" per image [18:14:27 CEST] <JEEB> Y is teh "grayscale" image [18:14:33 CEST] <JEEB> then Cb ir Chroma-blue [18:14:36 CEST] <JEEB> and Cr is chroma-red [18:14:49 CEST] <JEEB> and the chroma planes are "one sample for each 2x2 block" [18:14:51 CEST] <JEEB> that is 4:2:0 [18:15:02 CEST] <JEEB> full resolution chroma and luma is 4:4:4 [18:15:16 CEST] <Numline1> ahhh [18:15:23 CEST] <Numline1> well, I know two things [18:15:25 CEST] <JEEB> so when a player plays video, it receives 4:2:0 YCbCr from decoder, then scales the chroma to full resolution [18:15:31 CEST] <Numline1> 1) It's more complicated than I thought [18:15:34 CEST] <JEEB> and then converts to RGB [18:15:35 CEST] <Numline1> 2) Jesus christ why [18:15:36 CEST] <JEEB> so it can be shown [18:15:51 CEST] <kepstin> Numline1: why? because video is huge and this lets it be smaller [18:15:54 CEST] <JEEB> there's a lot of details in this too [18:16:07 CEST] <furq> the historical motivation is that the luma plane in YUV is the same thing that black-and-white tv transmissions used [18:16:12 CEST] <JEEB> like, the chroma samples aren't actually in the middle of that 2x2 block [18:16:15 CEST] <Mavrik> Numline1: if you want pictures: https://en.wikipedia.org/wiki/Chroma_subsampling#Sampling_systems_and_ratios :) [18:16:20 CEST] <furq> so YUV itself is for backward compatibility, and then the small chroma planes are to save bandwidth [18:16:24 CEST] <JEEB> the MPEG-2 Video and H.264 default is "top left" if I recall correctly [18:16:40 CEST] <JEEB> so when you pull the chroma to full resolution, you will have to scale correctly [18:16:41 CEST] <Numline1> Mavrik thank you, that makes it more clear :) [18:16:42 CEST] <JEEB> \o/ [18:16:56 CEST] <furq> and yes of course we're still using a format designed for backward compatibility with the 1950s [18:16:59 CEST] <furq> why wouldn't we be [18:17:03 CEST] <Mavrik> And https://stackoverflow.com/questions/27822017/planar-yuv420-data-layout :) [18:17:06 CEST] <Numline1> wow, I never knew this stuff is so complex [18:17:26 CEST] <Numline1> btw I've noticed the output I generated actually has one frame per line [18:17:37 CEST] <Numline1> If I'm reading that correctly [18:18:05 CEST] <Numline1> which is a lie because I'm not, there's 3 frames on 2 lines. I thought I found a shortcut [18:18:30 CEST] <Numline1> It seems to be delimited by something like "¬¬¬¬¬FRAME" [18:18:36 CEST] <furq> the frame always ends with a newline [18:18:49 CEST] <furq> but there could obviously be an 0x0A in the actual frame data [18:19:03 CEST] <kepstin> the newline byte is valid in the data, yeah, so you can't rely on it as a delimiter [18:19:03 CEST] <Numline1> who's that? [18:19:11 CEST] <furq> 0x0A is \n [18:19:17 CEST] <Numline1> oh, gotcha [18:19:17 CEST] <kepstin> don't use a text parser for binary data :) [18:19:27 CEST] <JEEB> thankfully the pixel format should tell you the frame sizes :P [18:19:33 CEST] <furq> yeah it's easy to calculate the dimensions [18:19:37 CEST] <Numline1> Hah, I just wanted to see the header before I do any decoding :) [18:19:53 CEST] <furq> you really don't need to care about how the data is packed, you just need to know the bits per pixel and dimensions [18:20:05 CEST] <Numline1> It's just a bit weird. I should have at least <amount_of_frames> newlines [18:20:06 CEST] <Numline1> or more [18:20:09 CEST] <Numline1> I have one less, which is weird [18:20:54 CEST] <Numline1> basically ffmpeg said it parsed 3 thumbnails, the file has 4 lines (header, "FRAMES" and then two actual lines). But I guess it's just Sublime being funky, I'll try to actually parse it in code :) [18:21:31 CEST] <JEEB> I recommend hex editors :P [18:21:36 CEST] <JEEB> hxd on windows [18:21:40 CEST] <JEEB> and I think I use bless on linux [18:21:47 CEST] Action: Numline1 uses macOS [18:21:50 CEST] <Numline1> :P [18:21:55 CEST] <JEEB> then whatever is sane for that [18:22:05 CEST] <JEEB> text editor usually isn't nice for this sort of stuff :P [18:23:05 CEST] <Numline1> yeah, poor VisualStudio Code is just displaying empty space :P [18:23:11 CEST] <Numline1> I'll try to find something [18:23:35 CEST] <JEEB> https://github.com/ridiculousfish/HexFiend [18:23:37 CEST] <JEEB> something like this? [18:24:44 CEST] <Numline1> yeah I found something similar :) Basically looks like this - https://numshare.s3-eu-west-2.amazonaws.com/Screen-Shot-2019-04-24-18-24-25… [18:25:01 CEST] <Numline1> you guys can possibly reconstruct part of my first frame now #securityleak [18:49:40 CEST] <Numline1> btw I've just noticed, ppm might be used as well :) Is that better/worse in some way? [18:53:11 CEST] <Numline1> although it probably just saved the latest image, so that's irrelevant :) [19:09:47 CEST] <emsjessec> why does ffmpeg get stuck sometimes and I have to ctrl+c it? [19:09:57 CEST] <emsjessec> ffmpeg -y -nostdin -i (input file) -filter:a loudnorm (output file) 2>&1 [19:10:17 CEST] <emsjessec> it's running from PHP's exec function and there's no input being sent to STDIN [19:12:41 CEST] <durandal_1707> emsjessec: is it using CPU? [19:15:47 CEST] <ChocolateArmpits> emsjessec, where did you get the binary [19:16:48 CEST] <ChocolateArmpits> Also for loudnorm you may want to downsample to 48kHz because it always outputs an upsampled stream [19:17:22 CEST] <ChocolateArmpits> It does that to increase measurement accuracy [19:39:55 CEST] <emsjessec> ok [20:27:33 CEST] <DHE> is there documentation about what mpegtsraw does differently from the regular mpegts demuxer? [21:16:18 CEST] <zerodefect> When using the C-API and setting up the x264 encoder, is it possible to somehow log the low-level settings (x264_params) after the encoder is configured? [21:19:48 CEST] <kepstin> zerodefect: the x264 encoder itself already logs (as a text log message) its internal settings when it starts up [21:20:08 CEST] <kepstin> other than that, the answer is "anything is possible if you code it" :/ [21:20:31 CEST] <JEEB> after you have applied the AVOptions they get eaten from the list [21:20:53 CEST] <JEEB> so log them before you apply them to libx264's AVCodecContext [21:21:01 CEST] <JEEB> if you want to log them [21:21:16 CEST] <JEEB> and then you'll have to log all of the AVCodecContext parameters you are interested in [21:24:19 CEST] <zerodefect> Ok. Nothing elegant. The reason I ask is that I'm trying to set a CBR stream but the bitrate is fluctating to above 4.2 MBit/s and the HW IRD receving is very unhappy about the video bitrate. I've set NAL=HRD/vbv-bufsize, but I clearly need to tweak something else. I was wanting to drill down into x264_params a bit more :/ [21:25:37 CEST] <JEEB> make sure it's complaining about the video stream [21:25:44 CEST] <JEEB> also you need to set both maxrate and bufsize [21:26:20 CEST] <JEEB> nal-hrd has to be set to either vbr or cbr for getting the HRD headers written into the video stream regarding the buffering parameters [21:26:52 CEST] <JEEB> often when people have things receiving complaining it's more often about the muxer/transmission [21:27:00 CEST] <JEEB> rather than actual video encoding rates [21:27:48 CEST] <JEEB> make sure you're using muxrate with MPEG-TS if you're using that, and if my development VM would boot at least once a day proper I would be able to tell you the bit rate option for the UDP protocol :P [21:28:05 CEST] <zerodefect> Ok. What is a sensible vbv-bufsize? Bitrate / fps? [21:28:19 CEST] <JEEB> that 100% depends on your requirements [21:28:43 CEST] <zerodefect> Do you know if this is outlined in any of the DVB docs? [21:29:02 CEST] <JEEB> I think DVB specs only talk about the MPEG-TS level mux [21:29:13 CEST] <JEEB> but feel free to check, I haven't checked too hard :P [21:29:28 CEST] <JEEB> most encoders out there don't let you tweak this stuff too much if I understand it correctly [21:29:51 CEST] <JEEB> usually it's (maxrate * seconds of initial buffer) [21:29:53 CEST] <JEEB> kidn of thing [21:29:54 CEST] <zerodefect> Yes, that is what I've seen thus far. It feels a bit more like an art to find the best settings to keep this HW encoders happy. [21:32:33 CEST] <Mavrik> There's of course also an option in x264 to stuff the stream with null packets :) [23:47:03 CEST] <GuiToris> hey, I have a problem. I created some lossless video files with ffmpeg and imported them into Premiere and they look like this : http://ix.io/1H7N [23:47:33 CEST] <GuiToris> -c:v libx264 -preset veryslow -crf 0 [23:47:39 CEST] <GuiToris> that's what I used [23:48:28 CEST] <GuiToris> if I reencode the video with ffmpeg -i lossless.mp4 new.mp4 this color artifact disappears [23:48:34 CEST] <GuiToris> what should I do? [23:48:37 CEST] <furq> that link doesn't work [23:48:54 CEST] <GuiToris> furq, weird it works here :S [23:49:03 CEST] <GuiToris> can't you download it with wget? [23:49:23 CEST] <GuiToris> wget 'http://ix.io/1H7N' [23:50:29 CEST] <GuiToris> it also works here but you'll lose the extension (it's jpg) [23:50:38 CEST] <GuiToris> could you open it? [23:51:48 CEST] <another> not sure if premiere support the lossless profile [23:52:37 CEST] <GuiToris> I could edit and play back them but they are all ugly [23:52:44 CEST] <GuiToris> isn't it just a color profile or something? [23:53:21 CEST] <GuiToris> I would keep the good quality but right now even ffmpeg -i lossless lossy is way much better [23:55:01 CEST] <GuiToris> isn't premiere the leading video editing software? that would be a shame if it didn't support lossless files [23:57:10 CEST] <GuiToris> My format profile is 'High 4:4:4 Predictive(a)L5.1' [23:57:31 CEST] <GuiToris> CABAC / 16 Ref Frames [00:00:00 CEST] --- Thu Apr 25 2019

1 0

ffmpeg-devel.log.20190423
by burek 24 Apr '19

24 Apr '19

[02:37:47 CEST] <cone-924> ffmpeg 03Jun Zhao 07master:a0877648472a: examples/avio_reading: Use avio_context_free() to free AVIOContext [07:30:52 CEST] <rcombs> the file produced by fate-lavf-mkv produces warnings in matroskadec and I'm not entirely sure it demuxes correctly [07:32:22 CEST] <rcombs> mkvalidator doesn't complain about anything relevant, so I think this is probably demux-side [07:32:47 CEST] <rcombs> seems like it overreads the last cluster [08:24:00 CEST] <rcombs> oh, I guess this is probably a regression in 18a851aca766ff8c7199c9e0c37d8fa642e41920 [08:25:18 CEST] <rcombs> &nope [08:25:52 CEST] <rcombs> regressed in 9326117bf63b04a466d9e787224e56ba8cdbb215, I guess? [08:25:57 CEST] <rcombs> seems to happen at EOF in most files [12:51:07 CEST] <cone-318> ffmpeg 03Sergey Svechnikov 07master:703583dbb1f3: avcodec/cuviddec: improve progressive frame detection [12:59:27 CEST] <cone-318> ffmpeg 03Sergey Svechnikov 07release/4.1:7c2dd1f969c9: avcodec/cuviddec: improve progressive frame detection [13:04:50 CEST] <cone-318> ffmpeg 03Sergey Svechnikov 07release/4.0:fc630d7b437b: avcodec/cuviddec: improve progressive frame detection [13:41:36 CEST] <cone-318> ffmpeg 03Paul B Mahol 07master:ccc07ebe4527: avfilter/af_surround: add 6.1/6.0 upmix from stereo [13:41:37 CEST] <cone-318> ffmpeg 03Paul B Mahol 07master:7a128ac2bca2: avfilter/af_surround: expose window size to user [13:41:38 CEST] <cone-318> ffmpeg 03Paul B Mahol 07master:ce15c3a4c8d6: avfilter/af_surround: switch to activate [18:12:46 CEST] <cone-834> ffmpeg 03Paul B Mahol 07master:4a69b18242dc: avfilter/af_surround: export more channel's in/out gains [22:44:11 CEST] <cone-633> ffmpeg 03Dan Sanders 07master:22c820f50904: libavformat/mov: limit nb_frames_for_fps to INT_MAX [22:58:06 CEST] <cehoyos> Has anybody ever used frei0r? [00:00:00 CEST] --- Wed Apr 24 2019

1 0

ffmpeg.log.20190423
by burek 24 Apr '19

24 Apr '19

[04:18:08 CEST] <TheBest_F-22> Does anyone know where to get the Latest FFmpeg "Stable" (4.1.3) for Windows (pre-built)? [04:19:15 CEST] <TheBest_F-22> Zeranoe tends to no longer keep up-to-date with "Stable", for some Reason... [04:25:49 CEST] <TheBest_F-22> Anyone knows if Kyle/Zeranoe simply gave up on Building "Stable" Releases? [04:25:52 CEST] <TheBest_F-22> (even though there are so few of them...) [05:14:32 CEST] Action: TheBest_F-22 wonders if there's anyone listening... [05:23:37 CEST] <elmofan> TheBest_F-22: those who read your question do not know the answer, or are witholding it from you. [05:23:44 CEST] <elmofan> Perhaps you need to offer incentives. [05:23:57 CEST] <elmofan> but i doubt that would help [05:27:22 CEST] <TheBest_F-22> elmofan: Thanks. I'm actually wondering if it's because Kyle/Zeranoe is the only one still bothering to do a Proper "trustworthy" Windows Build of FFmpeg from Source (as feature complete as possible on this Platform)... [05:28:02 CEST] <elmofan> does he have an email addr? [05:30:46 CEST] <TheBest_F-22> Maybe He (Zeranoe) doesn't think that the Changes from 4.1.1 to 4.1.3 are "Worth it"(?)... (Or He just has an Automated Process for Git "Nightlies" that isn't capable of Processing "Releases"/"Stable"s... Who knows...) [05:31:09 CEST] <TheBest_F-22> He has a Forum, a Contact Page, and a Twitter account... [05:31:29 CEST] <elmofan> i expect he knows better why he does or doesn't do things than I do [05:31:40 CEST] <TheBest_F-22> Last time I gave him this thread -> twitter.com/TheBestF22/status/1098260668191510528 [05:32:02 CEST] <TheBest_F-22> He apparently hear it and it appeared a couple of days later. [05:32:47 CEST] <TheBest_F-22> I just was hoping for him to get back to what he did before: He was almost always only half a week behind a Stable Release... [05:33:14 CEST] <TheBest_F-22> (but normally, just a single day, I think...) [05:37:11 CEST] <TheBest_F-22> I just read through "https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/4154f8967820ca734a77ce91bb590…" and there seems to be a lot of useful "Fixes"... [05:38:05 CEST] <TheBest_F-22> it's weird that Termux for Android (on arm64) got the Stable update before Windows... [05:39:04 CEST] <TheBest_F-22> (BTW: Zeranoe seems to be the only Windows Build Listed on the Official "http://ffmpeg.org/download.html#build-windows" Page... [05:49:33 CEST] <TheBest_F-22> Maybe it has to do with what's written on the right side of said Official Download site... (in the "Get the Sources" Section" [05:52:13 CEST] <TheBest_F-22> Sometimes, it seems that FFmpeg developers themselves recommend the Latest Git Commit Snapshot over the "Stable" one that, hopefully, should be more Reliable and with less possible Security Vulnerabilities... [05:56:01 CEST] <TheBest_F-22> Even Zeranoe's Own Website has "hover text" on the "Version" selection that Defaults and suggests the Latest "Git Version" over the "Stable" one... [05:58:04 CEST] <TheBest_F-22> I'd Like to see all those Fixes (and Security Patches) on Windows too... (though I doubt that I would encounter an exploit coming from Videos on Legal Streaming Sites, the Source of most of My FFmpeg use cases...) [06:00:24 CEST] <TheBest_F-22> I just Noticed I've been at this for far too long... Gotta go get some Dinner and some Sleep too... --> 5 a.m. here in Lisbon, Portugal... [06:00:36 CEST] <TheBest_F-22> C Ya L8r then!. ;P [06:04:46 CEST] <TheBest_F-22> if someone sees Zeranoe around Here, Kindly ask Him to Build a "Stable" (4.1.3) Release of FFmpeg... [06:05:32 CEST] <TheBest_F-22> K thx Bai. (for now) [07:48:31 CEST] <gour> ll [07:50:01 CEST] <gour> morning [07:51:00 CEST] <gour> our non-profit organization is recorring video from our public programs/lectures and here is the ffmpeg -i output: https://pastebin.com/vR5Sv2U6 [07:53:01 CEST] <gour> i need some recommendation how (to what) convert such recordings to make them smaller for more convenient upload to the server's public download area, but not to sacrifice quality too much? now ~1hr15min is ~1.7G [08:28:54 CEST] <elmofan> gour: will the users want to view them in browser? [08:29:53 CEST] <gour> elmofan: i belive that downloading them is preferred option, although we make a version for online viewing as well [08:30:05 CEST] <gour> *we can make... [08:30:43 CEST] <elmofan> i tend to prefer h264, but browsers don't generally seem to support it [08:30:52 CEST] <elmofan> so that is one consideration [08:31:07 CEST] <elmofan> i am no expert in encoding though, so I can not advise [08:31:07 CEST] <furq> all browsers support h264 [08:31:24 CEST] <elmofan> is it the container then? no .mp4? [08:31:40 CEST] <furq> h264/aac in mp4 is the most widely supported thing there is [08:32:03 CEST] <furq> gour: 1.7G for 75 minutes of 720p is already pretty small [08:32:44 CEST] <elmofan> thank you for the correction furq [08:33:01 CEST] <gour> furq: so, not much can be saved space-wise? [08:33:17 CEST] <furq> probably not without downscaling or something like that [08:33:25 CEST] <furq> it depends on the content though [08:34:09 CEST] <gour> it's kind of "classical" presentation with light usage of flip-chart [11:54:51 CEST] <seni> how does one read from an input audio stream? im getting an "invalid start code [..] pipe::invalid data found when proc input".the input format is mulaw in wav. im reading like `ffmpeg -y -loglevel error -acodec:a pcm_mulaw -f wav -i` [14:37:50 CEST] <Ariyasu> i have a h264 video that plays back fine and a e-ac3 audio file that also plays back fine [14:38:10 CEST] <Ariyasu> when i mux the two together, the output becomes very stuttery/jerky/choppy [14:38:26 CEST] <Ariyasu> any ideas why ? or how i can prevent/fix it [14:45:40 CEST] <elmofan> what are you using for playback Ariyasu [14:45:53 CEST] <elmofan> try with -ao null [14:48:10 CEST] <Ariyasu> mpc but it doesn't matter what media player i use [14:48:17 CEST] <Ariyasu> i will give -ao null a try [14:50:32 CEST] <Ariyasu> "Unrecognized option 'ao'." [14:51:22 CEST] <elmofan> well it's a long shot anyway [14:51:28 CEST] <lemourin> Is it possible to distinguish mp4 from mov using ffmpeg? Other than just looking at the extension. [14:51:47 CEST] <Ariyasu> what was -ao null supposed to do? [14:52:09 CEST] <elmofan> selects a null sink for your audio output [14:52:36 CEST] <elmofan> to eliminate possibility of your player+system having audio driver issues [14:52:46 CEST] <elmofan> that might get triggered by unusual files [15:10:00 CEST] <Ariyasu> elmofan i see this error in output everytime i try to mux [15:10:03 CEST] <Ariyasu> "[eac3 @ 0000000002c4e040] Estimating duration from bitrate, this may be inaccurate" [15:10:18 CEST] <Ariyasu> you think this is the cause of the choppy playback? [15:10:36 CEST] <elmofan> this is beyond my knowledge [15:13:02 CEST] <ritsuka> lemourin: you can check the major_brand with ffprobe [15:19:59 CEST] <lemourin> ritsuka: this won't work most of the time because i have mov files which don't have this metadata field set [15:20:29 CEST] <lemourin> MediaInfo manages to differentiate those files somehow though [15:20:36 CEST] <ritsuka> uh, major_brand is a required part of mov/mp4 [15:20:55 CEST] <lemourin> oh [16:27:24 CEST] <Ariyasu> [matroska,webm @ 00000000005895c0] Element at 0x2687a58 ending at 0x268b7b6 exceeds containing master element ending at 0x2687a52 [16:27:30 CEST] <Ariyasu> what does this mean? [17:15:59 CEST] <Adcock> I need help to reverse a video and the reversed portition at the end of actual video. [17:16:07 CEST] <Adcock> Can this be done? [17:16:40 CEST] <Adcock> I need help to reverse a video and then add reversed portition at the end of actual video. [17:49:46 CEST] <Adcock> I figured it out guys. [17:49:48 CEST] <Adcock> :D [19:55:56 CEST] <dablitz> good afternoon channel I want to rtp stream audio and also recieve rtp audio at the same time. is there a command with ffmpeg where I can ffmepg and ffplay off 2 seperate ports simulataniously [20:03:06 CEST] <dablitz> I am thinking, and please correct me --> ffmpeg -re -f alsa -i hw,1:0 -acodec mulaw -f rtp rtp://xxx.xxx.xxx.xxx:1234 | ffplay rtp://xxx.xxx.xxx.xxx:4321 [20:12:00 CEST] <dablitz> I have to run out a get some batteries, i will be back in 30 minutes [21:25:49 CEST] <dablitz> can anyone help [21:49:17 CEST] <ChocolateArmpits> dablitz, yeah go ahead [21:55:27 CEST] <DHE> he's doing rtp shenanigans [21:57:39 CEST] <another> why don't you just start two processes separately? [22:19:25 CEST] <dablitz> ChocolateArmpits: good afternoon channel I want to rtp stream audio and also recieve rtp audio at the same time. is there a command with ffmpeg where I can ffmepg and ffplay off 2 seperate ports simulataniously [22:19:50 CEST] <dablitz> ChocolateArmpits: I am thinking, and please correct me --> ffmpeg -re -f alsa -i hw,1:0 -acodec mulaw -f rtp rtp://xxx.xxx.xxx.xxx:1234 | ffplay rtp://xxx.xxx.xxx.xxx:4321 [22:20:17 CEST] <ChocolateArmpits> wew you don't want to use a pipe for that [22:20:29 CEST] <dablitz> this is for my ham network and I don't know how [22:22:34 CEST] <dablitz> I have 6 radio repeaters, and my home pc. I want to be able to key up my radio at home and rtp audio direct to all my repeaters at once [22:22:37 CEST] <ChocolateArmpits> While it's possible to have both a sender and receiver in the same process via output mapping it would probably be much better launch two separate processes as another suggests [22:22:53 CEST] <dablitz> ok [22:23:03 CEST] <dablitz> is my ffmpeg string correct [22:23:08 CEST] <ChocolateArmpits> It's not [22:23:20 CEST] <dablitz> can i get a correction [22:25:07 CEST] <ChocolateArmpits> Provided your output destination is correct [22:25:09 CEST] <ChocolateArmpits> Maybe this: ffmpeg -re -f alsa -i hw,1:0 -i rtp://xxx.xxx.xxx.xxx:4321 -map 0 -acodec mulaw -f rtp rtp://xxx.xxx.xxx.xxx:1234 -map 1 -codec copy -f nut - | ffplay -sync ext -probesize 32 -f nut - [22:25:25 CEST] <ChocolateArmpits> But because I don't know bash I can't suggest to how to start two processes at once :/ [22:25:57 CEST] <ChocolateArmpits> That sample should work but it's not an ideal case [22:27:29 CEST] <dablitz> the reason for the ffplay is when my repeaters receive RF they will stream that to my home pc, hence the two [22:29:46 CEST] <dablitz> so I need to send to each repeater and receive back from the repeater, I dont mind having 6 different instances of this running I just need to know the config is correct [22:35:46 CEST] <pzich> ChocolateArmpits: are you proposing using something like a fifo instead of a pipe? Or a different approach entirely? [22:38:24 CEST] <ChocolateArmpits> dablitz, by sending to the repeater do you mean sending anything or what you expect to get back? [22:39:50 CEST] <dablitz> ChocolateArmpits: my radio is connected to my mic input on my computer, so when I key my mic it streams to the raspberry pi at the repeater, and when the repeater recieves RF from another radio it streams back to my pc and out soundcard into my radio and I hear it [22:45:40 CEST] <ChocolateArmpits> dablitz, by radio you mean using it as a loudspeaker? [22:45:58 CEST] <ChocolateArmpits> I'm trying to figure it one by one [22:47:26 CEST] <dablitz> yes kindof. the radio on my desk will play as a loud speaker what it recieves, but will also tx via vox (inside the radio) on a simplex channel to my portable radio that I carry around town with me [22:48:08 CEST] <dablitz> i just need to have the stream of unencrypted audio go back and forth [23:10:39 CEST] <ChocolateArmpits> dablitz, do you want only one mic to engage all the repeaters? [23:11:24 CEST] <dablitz> the raspberry pi on each repeater only has 1 mic [23:12:49 CEST] <dablitz> all pi's are on a vpn and I was multicasting [23:12:55 CEST] <dablitz> on the vpn [23:13:30 CEST] <dablitz> that way I can use internal ip's and not have to worry about remotes having static public ip's [23:39:38 CEST] <calamari> The AVI container has a multitude of drawbacks, but one nice thing is that if you only copy some of it, you can still have a playable file, which isn't the case with MKV for example. Does anyone know of other containers that can tolerate truncated containers? [23:40:10 CEST] <cehoyos> All do iirc [23:40:50 CEST] <calamari> cehoyos: not true.. MKV doesn't work if you don't have the end [23:40:58 CEST] <cehoyos> That's news to me. [23:41:31 CEST] <cehoyos> (With mov and friends, the part that can be at the end of the file but can as well be at the beginning is needed - if it is at the end, you cannot cut the file) [23:41:48 CEST] <calamari> cehoyos: try ripping a blu-ray with MakeMKV. It's writing a mkv all along, but you can't play it until it finishes up [23:42:14 CEST] <furq> that sounds like a makemkv problem [23:42:16 CEST] <cehoyos> So your questions was actually: Which applications apart from MakeMKV write files so that they cannot be played while written? [23:42:33 CEST] <calamari> LOL! [23:42:43 CEST] <furq> anyway mpegts is the canonical unbreakable container format [23:42:58 CEST] <cehoyos> You mean like mpeg-ps? [23:43:14 CEST] <cehoyos> And without pat/pmt? [23:43:16 CEST] <calamari> furq: I'll give it a try, thanks [23:46:42 CEST] <calamari> I believe the problematic part of mp4 and mkv is called the MOOV atom, which has to be updated for the file not to be corrupted [23:46:50 CEST] <furq> of mp4, sure [23:46:56 CEST] <furq> there's no such thing in mkv [23:48:22 CEST] <BtbN> There is, but it doesn't break the file to uselessness if it's missing. It's just not seekable. [23:48:34 CEST] <cehoyos> as said, the moov atom can be at the start of the file, if it is at the start of the file, you can cut it and (still) play it. [23:48:34 CEST] <furq> i meant it's not called a moov atom [23:49:02 CEST] <calamari> BtbN: are there any containers besides AVI that don't have a moov atom or anything like it? [23:49:10 CEST] <furq> mpegts [23:49:10 CEST] <BtbN> mpegts [23:49:11 CEST] <cehoyos> All except mov? [23:49:12 CEST] <BtbN> flv [23:49:24 CEST] <furq> flv as well but that's much more restrictive in terms of codecs [23:49:30 CEST] <BtbN> mkv in streamable mode [23:49:32 CEST] <furq> basically any container designed for streaming [23:49:42 CEST] <calamari> alrighty, thanks! sounds like mpeg-ts is the answer [23:49:47 CEST] <furq> bear in mind mpegts has no seek index [23:49:53 CEST] <BtbN> mpeg-ts is pretty heavy in terms of overhead as well [23:49:56 CEST] <BtbN> I'd just go for mkv [23:50:00 CEST] <BtbN> for pretty much everything [23:50:10 CEST] <calamari> mkv doesn't work, it's broken if you don't have the entire file [23:50:15 CEST] <furq> yeah idk what makemkv is doing but ffmpeg's mkv output will work if it's truncated [23:50:15 CEST] <cehoyos> No [23:50:17 CEST] <BtbN> Unless you want it to play in a Browser, then you have the choice between mp4 and mp4 [23:50:42 CEST] <cehoyos> Your application is "broken" because it does not write mkv in the normal way where it can be played before being finished. [23:50:53 CEST] <cehoyos> In any case, you can certainly cut your finished mkv file and it is still playable. [23:51:03 CEST] <calamari> cehoyos: in this case I'm not using makemkv, I was just offering that as an example [23:51:16 CEST] <furq> what player are you using [23:51:19 CEST] <furq> maybe that's broken [23:52:52 CEST] <calamari> furq: well with the partial mkvs, I tried vlc, mpv, a browser, an old mplayer.. it seemed universally broken [23:53:09 CEST] <furq> weird [23:53:27 CEST] <calamari> I realize mkv and mplayer are probably not really a different test [23:53:43 CEST] <calamari> err mpv * [23:54:02 CEST] <calamari> anyhow thanks everyone, I'll try it with mpeg-ts [23:54:05 CEST] <cehoyos> They all work fine with cut mkv files [23:54:41 CEST] <cehoyos> None of them can play invalid mkv file which is likely what your application produces if you don't allow it to run until the end. [23:58:12 CEST] <calamari> can you seek in a partial mpeg-ts? [23:58:27 CEST] <calamari> (you can in avi) [23:58:41 CEST] <calamari> I can try it and see :) [23:58:46 CEST] <BtbN> mpeg-ts is not seekable [23:59:34 CEST] <calamari> bummer. maybe AVI is the only answer then [00:00:00 CEST] --- Wed Apr 24 2019

1 0

ffmpeg-devel.log.20190422
by burek 23 Apr '19

23 Apr '19

[00:51:17 CEST] <cone-203> ffmpeg 03Michael Niedermayer 07master:f17e8e90bb1f: avcodec/ccaption_dec: Add a blank like at the end to avoid rollup reading from outside [00:51:17 CEST] <cone-203> ffmpeg 03Michael Niedermayer 07master:158efc045c71: avcodec/agm: Do not crash on invalid codes [00:51:17 CEST] <cone-203> ffmpeg 03Michael Niedermayer 07master:7ee7bb92e603: avcodec/agm: Check for too many too short codes in make_new_tree() [00:51:17 CEST] <cone-203> ffmpeg 03Michael Niedermayer 07master:df9ef925f97d: avcodec/agm: remove ;; [07:07:04 CEST] <cone-379> ffmpeg 03Steven Liu 07master:613ca7b100ac: avformat/dashdec: add ProgramInformation parser [08:08:46 CEST] <cone-379> ffmpeg 03Karthick J 07master:eeca67e0232c: avformat/dashenc: Fix a bug with writing "final" manifest [12:04:12 CEST] <durandal_1707> michaelni: did we requested slots for GSoC? [12:10:33 CEST] <michaelni> durandal_1707, just checked, yes, min/max slot request has been entered already [12:37:40 CEST] <durandal_1707> atomnuker: come on, push some patches finally! [14:45:03 CEST] <atomnuker> durandal_1707: don't have any, I'm busy [14:48:56 CEST] <durandal_1707> atomnuker: with what? [14:54:01 CEST] <atomnuker> metro 2033 [15:01:35 CEST] <durandal_1707> not again [15:10:43 CEST] <atomnuker> hey, it beats thinking about how every place in the universe is fucked up and I have to pick my poison [15:12:23 CEST] <durandal_1707> atomnuker: nooooooo [15:15:23 CEST] <BBB> atomnuker: don't you want to write new codecs anymore? [15:35:57 CEST] <atomnuker> BBB: I do, its very fun to experiment, but right now I can't seem to get motivated [15:36:32 CEST] <BBB> but you don't want to play games all day for the rest of your life, right? [15:36:36 CEST] <BBB> what are you looking for? [15:37:00 CEST] <BBB> more money? more purpose? social connection? life companion? sth. else? [15:37:12 CEST] <BBB> or just to be left alone? [16:45:09 CEST] <thebombzen> I'm looking into writing a fate test for the patch I submitted a few weeks ago, at Michael N's recommendation. problem is... I'm not entirely familiar with how to write a fate test or the standards thereof. [16:45:14 CEST] <thebombzen> I read fate.html but it mostly says how to run fate tests, not how to write fate tests [16:45:39 CEST] <thebombzen> is there any documentation on this or developer policy [16:47:25 CEST] <JEEB> seems to be pretty scattered. for example the doc/developer.texi talks aoubt adding new files to fate-suite but not related to the details of fate [16:47:39 CEST] <JEEB> anyways, the core is that the tests are in Makefiles under tests/fate/* [16:48:09 CEST] <JEEB> your patch was regarding the ffmpeg.c cli so most likely a test file that tests ffmpeg.c would be the default spot to add it to [16:48:46 CEST] <thebombzen> should I just emulate what other fate tests do? [16:48:52 CEST] <JEEB> something like tests/fate/ffmpeg.mak is probably the place? [16:49:31 CEST] <JEEB> you can look at some FATE sample that is good enough for your input, and then see if one of the framemd5/crc/etc muxers is good enough for your purpose [16:49:37 CEST] <JEEB> since it gives you DTS/PTS and some other stuff [16:50:29 CEST] <thebombzen> alright [16:50:35 CEST] <JEEB> there are various raw H.264 etc samples in the FATE test suite thankfully [17:46:38 CEST] <cone-583> ffmpeg 03Jun Zhao 07master:8d3630c5402f: lavf/oggparsevorbis: Fix change the case of metadata keys issue [18:03:00 CEST] <cone-583> ffmpeg 03Gyan Doshi 07master:6829c3cbe480: avformat/mpegenc - reject unsupported audio streams [22:29:19 CEST] <cone-133> ffmpeg 03Paul B Mahol 07master:c6c94303d447: avfilter/af_surround: avoid divisions with very small numbers [22:29:19 CEST] <cone-133> ffmpeg 03Paul B Mahol 07master:dbb35abf2897: avfilter/af_surround: add lfe_mode option [22:29:19 CEST] <cone-133> ffmpeg 03Paul B Mahol 07master:26fd40b568b8: avfilter/af_surround: make channel spread from stereo image user configurable [00:00:00 CEST] --- Tue Apr 23 2019

1 0

ffmpeg.log.20190422
by burek 23 Apr '19

23 Apr '19

[00:32:07 CEST] <kepstin> M6HZ: no, it would make it harder to use, because making a single complex filter chain which handles multiple streams is more work than doing separate simple "audio" and "video" chains that are applied to all of the relevant streams automatically. [00:36:39 CEST] <M6HZ> kepstin: Hum, fair enough. It's just that there are at least four ways to apply filters with ffmpeg, -vf, -af, -complex_filer, -lavfi, all of these having their limitations. Trying to unify them into something more intuitive could be a nice idea. [00:37:03 CEST] <kepstin> you only listed 3 ways, since -filter_complex and -lavfi are the same thing :) [00:37:19 CEST] <kepstin> (there's also options that load filter chain descriptions from files) [00:37:26 CEST] <M6HZ> Well, yes, I've read that earlier, but there are two different options. [00:37:27 CEST] <kepstin> and the lavfi input device [00:38:14 CEST] <M6HZ> "there's also options that load filter chain descriptions from files" What is that. Can you give me an example? [00:41:06 CEST] <kepstin> -filter_script is the same thing as -filter (which is the long form of the -af and -vf options), except it reads the filter chain description from a file rather than from the command line. [00:41:15 CEST] <kepstin> same for -filter_complex_script vs. -filter_complex [00:41:43 CEST] <M6HZ> ok [00:43:00 CEST] <furq> what limitations does filter_complex have that vf/af don't [00:48:15 CEST] <M6HZ> kepstin: And you see there is another source of confusion "-lavfi" and "lavfi input virtual device", I had always conflated both. [00:48:33 CEST] <M6HZ> furq: kepstin gave at least one of them earlier. [00:49:20 CEST] <M6HZ> kepstin: It is also the case for the term "codec" in the man page, being either related to an encoder name or to a bitstream format name. [00:49:24 CEST] <kepstin> hmm? I don't recall saying anything of the sort. [00:49:44 CEST] <M6HZ> "[18:32] <kepstin> M6HZ: no, it would make it harder to use, because making a single complex filter chain which handles multiple streams is more work than doing separate simple "audio" and "video" chains that are applied to all of the relevant streams automatically." [00:49:56 CEST] <kepstin> i said that -af/-vf are often easier to use, but that's not really a "limitation" [00:50:21 CEST] <M6HZ> Alright the word is maybe too strong. [07:40:52 CEST] <koz_> I'm using (successfully) ffmpeg with Intel's VA-API HEVC encoder. If I wanna do a lot of files (say, 12), does it make sense for me to use something like GNU Parallel to execute ffmpeg in parallel on each one, or will that not really help? [07:41:14 CEST] <koz_> I assume it won't, because I have only one DRI device, and I guess that all that parallel-hammering won't play very nicely with it. [07:52:58 CEST] <TikityTik> koz_: there's a -threads option and a -cpu option [07:53:17 CEST] <koz_> TikityTik: I understand that. I'm asking more about processing multiple files, not one file faster. [07:53:41 CEST] <koz_> Because I'm not sure that I can hardware encode 12 things in parallel, even though my CPU has 12 hyperthreads. [07:54:05 CEST] <koz_> I've done some tests, the results are inconclusive, and I'd like to hear from someone who can give me a definitive answer on whether that's a) even possible and b) worthwhile. [07:54:18 CEST] <koz_> I can give the exact ffmpeg invocations I'm feeding to GNU parallel if that'd help. [07:57:05 CEST] <furq> i don't think it'll make any difference [07:57:28 CEST] <koz_> furq: So what you're saying is 'don't bother using GNU parallel,just process the files in sequence'? [07:57:32 CEST] <furq> yeah [07:57:49 CEST] <koz_> furq: Could you explain your reasoning for that? Not disagreeing, but just curious why. [07:57:59 CEST] <koz_> Is it because the hardware can only encode one file at a time anyway? [08:00:23 CEST] <furq> each encode will slow down pretty much in line with however many streams you're running [08:00:31 CEST] <koz_> Ah, I see. [08:00:33 CEST] <furq> plus i assume you lose some more in overhead [08:00:40 CEST] <koz_> Yeah, I'm _definitely_ noticing that. [08:00:43 CEST] <furq> although you'd gain a tiny bit from running the decoder closer to capacity [08:01:09 CEST] <koz_> On just FPS alone, 1 proc = 60fps, 2 procs = 48fps, but 4 already kick me to like, 27. [08:02:26 CEST] <furq> that sounds better than i thought [08:02:56 CEST] <furq> unless you mean 27fps in total [08:06:57 CEST] <koz_> This is per ffmpeg process. [08:14:01 CEST] <koz_> furq: So I guess either I do it entirely serially, or at most 2 processes at a time? [09:29:23 CEST] <vishnuyr> Hi [09:29:57 CEST] <vishnuyr> I need help with encoding of DVCPro HD to XDCAM HD 422. [09:30:21 CEST] <vishnuyr> has anyone tried it? [09:37:25 CEST] <KaitoDaumoto> idk [09:37:25 CEST] <KaitoDaumoto> :( [10:47:21 CEST] <Hypnotoad90_> hey, is it possible to request a specific frame size AVCodecContext? [10:48:33 CEST] <Hypnotoad90_> or from the codec [10:48:37 CEST] <Hypnotoad90_> by frame size i mean a specific nb_samples [10:50:09 CEST] <Hypnotoad90_> alternatively, is it possible to have swr_convert write to your sample buffers with a sample offset, rather than having it write from the beginning of the buffer? [13:01:51 CEST] <Hypnotoad90> not sure how to phrase that question properly [13:46:04 CEST] <Hypnotoad90> or am i only supposed to be writing to new buffers each frame? [13:49:45 CEST] <JEEB> Hypnotoad90: you're talking about audio, so I know the libavfilter interfaces which behind the scenes utilize swresample has a function to request XYZ samples [13:49:53 CEST] <JEEB> not sure if swresample itself has that [13:50:08 CEST] <Hypnotoad90> hmm cool [13:50:48 CEST] <Hypnotoad90> if i just want to decode and resample an audio stream, libavfilter is a suitable thing to use? [13:51:26 CEST] <JEEB> yes, it basically wraps around swresample so it's less nitty gritty and more "feed me AVFrames and you get AVFrames back" [13:51:42 CEST] <JEEB> although I thought swresample also has an AVFrame based API, but I'm now having trouble noticing it :P [13:51:55 CEST] <Hypnotoad90> sounds great, and i can use it without it actually 'filtering' the audio? [13:52:14 CEST] <JEEB> well you define the filter chain [13:52:18 CEST] <JEEB> that can just be "aresample" [13:52:27 CEST] <JEEB> input -> aresample -> output [13:52:38 CEST] <Hypnotoad90> aresample is like swrseample? [13:52:47 CEST] <JEEB> it's the filter that wraps swresample, yes [13:52:58 CEST] <Hypnotoad90> awesome, i'll def look into that in a bit [13:53:06 CEST] <Hypnotoad90> is there some good example code showing its usage? [13:53:25 CEST] <JEEB> doc/examples has an example of using the "just give it a string" interface [13:53:44 CEST] <JEEB> which builds a filter chain from a string you pass libavfilter [13:54:20 CEST] <Hypnotoad90> oh btw forgot to mention, i'm forced to use a specific version of ffmpeg, i think it might be 2.4.1 or something, if that matters [13:54:28 CEST] <JEEB> yes it does [13:54:39 CEST] <JEEB> you're very unfortunate in various ways :P [13:54:44 CEST] <Hypnotoad90> yup :( [13:55:30 CEST] <JEEB> that's old enough for many things to have changed or gotten fixed since [13:55:53 CEST] <JEEB> ok, and I found the AVFrame based API in swresample for the record. it's indeed documented in swresample.h as I remembered :P [13:59:08 CEST] <Hypnotoad90> ah i see there's swr_convert_frame [13:59:48 CEST] <JEEB> and swr_config_frame for reconfiguration in case of changes [14:00:03 CEST] <Hypnotoad90> JEEB, actually can i explain my overall situation: [14:00:10 CEST] <Hypnotoad90> basically im dealing with an old code base [14:00:25 CEST] <Hypnotoad90> the old code base will call a function with a char* buffer [14:00:34 CEST] <Hypnotoad90> of a given size [14:00:46 CEST] <Hypnotoad90> basically this codebase has its own 'frame' concept distinct from ffmpeg's [14:00:53 CEST] <Hypnotoad90> so the char it sends is the buffer size for the whole frame [14:01:20 CEST] <Hypnotoad90> and i basically need to get audio out of ffmpeg and pack it into this data [14:02:23 CEST] <Hypnotoad90> now if i could get codec ffmpeg uses to have the same frame size as this function requests, that would be perfect, as it would all match up and i could just use swr_convert to write to the frame directly [14:02:38 CEST] <Hypnotoad90> write to the char* [14:02:51 CEST] <Hypnotoad90> i dunno if any of that made sense [14:03:04 CEST] <JEEB> given that FFmpeg itself has alignment requirements I'm not sure if you can just feed the buffer as-is to FFmpeg's APIs [14:03:18 CEST] <JEEB> but you can indeed with various APIs request XYZ samples [14:03:37 CEST] <JEEB> including that AVFrame API and probably the non-AVFrame one too :P [14:03:47 CEST] <Hypnotoad90> well this codebase has functions to prepare the sample format etc.. [14:04:12 CEST] <JEEB> so then all you need to do is transfer those samples from f.ex. the received AVFrame to your buffer [14:04:21 CEST] <JEEB> which should in general be one or multiple memcpys [14:04:24 CEST] <Hypnotoad90> but anyway, suppose i wanted to request an arbitrary number of samples from an arbitrary sample offset, would that be possible? [14:04:38 CEST] <JEEB> why do you need the offset? [14:04:44 CEST] <JEEB> you want to skip samples? [14:04:54 CEST] <Hypnotoad90> well so the codebase will request a frame as well [14:04:57 CEST] <JEEB> or do you mean "don't start at the beginning of the output buffer"? [14:05:01 CEST] <Hypnotoad90> so it might call the function and ask for audio at frame 30 [14:05:15 CEST] <Hypnotoad90> and say frame 30 is 5000 samples in [14:05:23 CEST] <Hypnotoad90> so i need to get data from the audio stream 5000 samples in [14:05:36 CEST] <Hypnotoad90> and lets say the frame size its requesting is 1000 [14:05:49 CEST] <Hypnotoad90> so i need to get 1000 samples of audio data beginning at sample 5000 from the stream, if that makes sense [14:06:30 CEST] <Hypnotoad90> i know i can use av_seek_frame or something like that to find the frame that contains the sample number [14:06:54 CEST] <JEEB> that's a container level seek to a position [14:07:02 CEST] <JEEB> time-wise position [14:07:05 CEST] <JEEB> not in samples [14:07:08 CEST] <Hypnotoad90> right [14:07:18 CEST] <Hypnotoad90> but i believe it was possible to calculate the right time position from samples [14:07:23 CEST] <JEEB> (you can also seek in bytes) [14:07:25 CEST] <Hypnotoad90> using AV_TIME_BASE or something [14:07:33 CEST] <Hypnotoad90> oh that might be easier [14:07:35 CEST] <JEEB> yes, if your definition is number of samples in the input format [14:07:54 CEST] <JEEB> as opposed to number of samples after whatever conversion you need to do with resampling [14:07:57 CEST] <JEEB> :P [14:08:23 CEST] <Hypnotoad90> anyway getting precisely the right frame is secondary atm, the main thing is being able to read an arbitrary number of samples [14:09:15 CEST] <JEEB> well at least the AVFrame API for swresample and the libavfilter stuff lets you basically request X amount of samples [14:09:30 CEST] <JEEB> as swr_convert_frame f.ex. notes [14:09:36 CEST] <Hypnotoad90> theres the decoder i need to deal with too [14:09:46 CEST] <JEEB> well yes, but decoder will just churn AVFrames for you [14:10:00 CEST] <JEEB> what you are interested in is that you get the output in XYZ sample chunks [14:10:09 CEST] <JEEB> which is what these APIs will give you [14:10:16 CEST] <Hypnotoad90> not sure what you mean by XYZ exactly [14:10:28 CEST] <JEEB> some arbitrary number of samples [14:10:43 CEST] <JEEB> see the sentence starting with "The output AVFrame can be NULL or have fewer allocated samples than required." [14:10:46 CEST] <JEEB> in swresample.h [14:11:01 CEST] <Hypnotoad90> right, but the decoder still forces a specific nb_samples size it seems [14:11:08 CEST] <JEEB> of course it does [14:11:16 CEST] <JEEB> it just outputs decoded AVFrames as-is [14:12:05 CEST] <JEEB> and read that explanation to the start of which I pointed please, that will probably clear some doubts on your side :P [14:12:33 CEST] <Hypnotoad90> which explanation sorry? [14:12:48 CEST] <JEEB> fourth line before the "and read that explanation..." [14:12:56 CEST] <JEEB> referencing to swresample.h [14:14:35 CEST] <Hypnotoad90> okay so [14:16:04 CEST] <Hypnotoad90> so i can see that could be used if my frame is smaller than the one the codec produces, but lets say my frame is the size of 3 frames the codec churns out, i guess i want swr to read to the same frame 3 times with those 3 input frames? [14:16:06 CEST] <Hypnotoad90> if possible? [14:16:09 CEST] <Hypnotoad90> write to* [14:17:31 CEST] <Hypnotoad90> or otherwise i need to just write 3 frames and pack them all into the char* somehow [14:17:54 CEST] <JEEB> I would think that at least some API will just outright tell you that the internal buffer doesn't yet have enough data [14:17:59 CEST] <JEEB> if you request a larger frame size [14:18:33 CEST] <JEEB> although I have not touched swresample and most of my experience has been writing relatively simple stuff with libavfilter in the audio department [14:19:38 CEST] <Hypnotoad90> okay so i think it sounds like i'll have multiple frames to deal with and i need to write them all into a single char* buffer, im not sure how id do that [14:19:54 CEST] <JEEB> ? I don't think that's what I said [14:20:09 CEST] <Hypnotoad90> i cant see what else i could do reading the doc [14:20:26 CEST] <JEEB> I would rather have f.ex. avfilter handle the buffering (or swresample if it indeed tells you that if you try to request more samples from it than it has in buffer) [14:21:17 CEST] <JEEB> you can relatively easily test what the thing tells you if you request more samples than you have fed it :P [14:21:45 CEST] <JEEB> and if that's not possible, you can always copy the buffer and offset the pointer to your output buffer :P [14:21:46 CEST] <Hypnotoad90> but i'll already know in advance if im requesting more samples than available, not entirely sure why its useful if swresample tells me or not [14:21:58 CEST] <JEEB> because tehn you can just keep feeding more data in? [14:22:09 CEST] <Hypnotoad90> right, as in additional frames? [14:22:11 CEST] <JEEB> it should then buffer internally until it has a full frame's amount of stuff [14:22:20 CEST] <Hypnotoad90> thats why im saying i'd end up with multiple frames [14:22:28 CEST] <JEEB> on the input side? [14:22:29 CEST] <JEEB> yes [14:22:32 CEST] <JEEB> on the output side? why [14:22:39 CEST] <Hypnotoad90> are you saying i can write multiple times to the same frame? [14:22:44 CEST] <JEEB> no? [14:23:06 CEST] <Hypnotoad90> so how am i supposed to use multiple input frames for one output frame? [14:23:08 CEST] <JEEB> I'm saying taht you request XYZ samples out of the resampler it should hopefully either tell you it has no such amount of samples yet, or it will be dumb and give what it has [14:23:47 CEST] <JEEB> Hypnotoad90: it references an internal buffer so you can easily test which the swresample lib does if you ask for more than it's got :P [14:23:55 CEST] <JEEB> since it does have internal buffering as per the doc [14:24:03 CEST] <Hypnotoad90> i get that, but i dont know what im supposed to do with that info [14:24:16 CEST] <JEEB> "I ate your input frame, feed more" [14:24:19 CEST] <JEEB> is what that means [14:24:29 CEST] <JEEB> *feed more if you want output [14:24:41 CEST] <Hypnotoad90> oh so you mean it wont write to the output frame right away until enough input has been added? [14:24:58 CEST] <JEEB> yes, that is what I'm hoping for since it has the same thing for asking for less samples than it has in buffer [14:25:03 CEST] <Hypnotoad90> like the "gotframe" thing from the decoder? [14:25:04 CEST] <JEEB> which is why I said "just try it out" [14:25:16 CEST] <JEEB> Hypnotoad90: oh boy, those old APIs [14:25:21 CEST] <JEEB> nowadays we have separate feed/receive [14:25:23 CEST] <JEEB> functions :P [14:25:31 CEST] <JEEB> which both report "cannot do that yet" [14:25:42 CEST] <JEEB> if the internal state isn't ready for your request yet [14:25:43 CEST] <JEEB> :P [14:25:54 CEST] <Hypnotoad90> swr_convet_frame, doc says: Returns [14:25:54 CEST] <Hypnotoad90> 0 on success, AVERROR on failure or nonmatching configuration. [14:26:25 CEST] <Hypnotoad90> doesnt look like it returns info about needing more data [14:26:26 CEST] <JEEB> yup, so it will probably return an AVERROR [14:26:29 CEST] <Hypnotoad90> oh? [14:26:35 CEST] <Hypnotoad90> hmm [14:26:36 CEST] <JEEB> or I would guess so [14:26:41 CEST] <JEEB> test it and it'll be quick [14:26:43 CEST] <JEEB> then we'll know :P [14:26:53 CEST] <Hypnotoad90> i'll test in a bit [14:26:55 CEST] <JEEB> just like it returns AVERROR_{OUTPUT,INPUT}_CHANGED [14:27:01 CEST] <JEEB> if the input or output config changed [14:27:02 CEST] <JEEB> :P [14:27:12 CEST] <JEEB> (and thus a reconfig is needed) [14:27:56 CEST] <Hypnotoad90> alternatively, in case this doesn't work out, before i was writing directly to the buffer with: av_samples_alloc((uint8_t**) &buffer, NULL, numchans, MAX_AUDIO_FRAME_SIZE, sample_fmt, 0); [14:28:39 CEST] <Hypnotoad90> is there someway i can offset the buffer pointer so it fills say the end half of the buffer [14:28:58 CEST] <Hypnotoad90> i couldnt quite figure it out how to do it properly, i was constantly getting bad access errors [14:29:03 CEST] <Hypnotoad90> if it's even possible [17:46:39 CEST] <Hypnotoad90> alright lets give this a shot [17:57:07 CEST] <Hypnotoad90> noooo [17:57:19 CEST] <Hypnotoad90> JEEB, looks like swr_convert_frame isn't available in my version of ffmpeg :( [18:36:43 CEST] <JEEB> Hypnotoad90: too bad [18:36:59 CEST] <JEEB> although I think you could request for XYZ samples in teh buffer based API too? [18:44:54 CEST] <Hypnotoad90> JEEB, right but how? [18:46:15 CEST] <Hypnotoad90> oh i pasted the wrong function before [18:47:11 CEST] <Hypnotoad90> i do the conversion atm with: swr_convert(swr, (uint8_t**)&buffer, frame->nb_samples, (const uint8_t**)frame->data, frame->nb_samples); [18:47:54 CEST] <Hypnotoad90> id like at least for now to be able to call that swr_convert function multiple times on the same buffer, i.e. writing several frames to one buffer, im assuming i can do that by offsetting the pointer to buffer somehow but not sure how [00:00:00 CEST] --- Tue Apr 23 2019

1 0

ffmpeg-devel.log.20190421
by burek 22 Apr '19

22 Apr '19

[06:38:53 CEST] <cone-736> ffmpeg 03Gyan Doshi 07master:6e0488cac431: doc/codecs: mention error returned for flag AV_CODEC_FLAG_DROPCHANGED [15:22:06 CEST] <cone-098> ffmpeg 03Jun Zhao 07master:b272d5b9b6e1: lavfi/frei0r: Fixes the compilation warnings [19:45:37 CEST] <cone-006> ffmpeg 03Paul B Mahol 07master:833ae5f4bfdc: avcodec/dvdec: add frame threads [21:14:31 CEST] <cone-006> ffmpeg 03Paul B Mahol 07master:dafcdeb25823: lavfi/avf_showwaves: fix extra gaps at end of waveform [00:00:00 CEST] --- Mon Apr 22 2019

1 0

ffmpeg.log.20190421
by burek 22 Apr '19

22 Apr '19

[00:10:02 CEST] <TikityTik> i'm surprised the subtitles filter still doesn't work off streams [00:13:43 CEST] <JEEB> subtitles are the one part of libavcodec that doesn't return AVFrames [00:13:48 CEST] <JEEB> and libavfilter only takes in AVFrames [00:14:13 CEST] <JEEB> so to get a similar result like what the sub2video thingamajig does in ffmpeg.c, you would have to re-implement what the subtitle filter does in tehre [00:14:23 CEST] <JEEB> as in, call libass or so on the subtitle lines [00:15:07 CEST] <JEEB> but yea, an old technical piece of debt is why a filter cannot take in subtitles :) [00:16:36 CEST] <JEEB> the ffmpeg.c sub2video thing already does generation of overlay images from picture based AVSubtitles, so one would just have to write handling of text AVSubtitles there that more or less duplicates what the subtitle filter does :) [00:26:06 CEST] <FreeBDSM> could someone help me? [00:27:21 CEST] <klaxa> from the paste it looks like your file is simply corrupted [00:28:55 CEST] <FreeBDSM> klaxa: it is not [00:29:09 CEST] <klaxa> can you play it back with something? [00:29:14 CEST] <FreeBDSM> no [00:29:32 CEST] <klaxa> then how do you know it is not corrupted? [00:29:38 CEST] <FreeBDSM> you may try it yourself, the file may be obtained via `youtube-dl -f 397 "https://www.youtube.com/watch?v=o6xQDChpUR0"` [00:29:56 CEST] <FreeBDSM> I doubt google would upload corrupted audio [00:30:43 CEST] <klaxa> maybe update your ffmpeg [00:30:46 CEST] <klaxa> works for me: https://gist.github.com/klaxa/6a59b49272d33b927af33d087a0bbdc7 [00:30:55 CEST] <JEEB> ah [00:30:56 CEST] <JEEB> av01 [00:30:57 CEST] <JEEB> yes [00:31:17 CEST] <JEEB> that needs FFmpeg to be built with an AV1 decoder (libaom or libdav1d) [00:31:37 CEST] <JEEB> libdav1d is faster by now so that is recommended [00:31:46 CEST] <FreeBDSM> aw, crap [00:31:52 CEST] <FreeBDSM> so it's not in ubuntu's repos yet [00:32:05 CEST] <JEEB> the format was stabilized in summer 2018 [00:32:06 CEST] <FreeBDSM> 3.4.4 version here [00:32:12 CEST] <JEEB> so very unlikely to be in any LTS currently [00:32:35 CEST] <FreeBDSM> got it, thanks [00:32:50 CEST] <JEEB> and then of course you need the mapping for AV1 in mp4, which is probably in a newer version as well, as that was finished after the format was finished I think [00:32:55 CEST] <JEEB> around sept, 2018? [00:35:15 CEST] <JEEB> so yea, you're dealing with rather fresh stuff :) [00:36:24 CEST] <FreeBDSM> well, basically, I don't have problems with ffmpeg, I do have problems with youtube-dl downloading non-supported stuff :( [00:36:31 CEST] <FreeBDSM> (by default) [00:37:51 CEST] <JEEB> well, youtube-dl doesn't know how old your other software is, and I'm not sure if it should be trying to :) [00:38:11 CEST] <JEEB> you can just disable AV1 in the youtube-dl config or get newer copies of FFmpeg (or build it yourself) [00:38:24 CEST] <JEEB> of course it will not fix AV1 decoding in other apps like vlc or mpv [00:38:43 CEST] <FreeBDSM> JEEB: looks like only AV1 audio is not supported [00:39:11 CEST] <furq> av1 audio is just opus [00:39:11 CEST] <JEEB> I think that was a bug with youtube-dl if it's old enough? AV1 has no audio [00:39:24 CEST] <JEEB> AV1 is a video format [00:39:24 CEST] <FreeBDSM> oh [00:39:42 CEST] <furq> also youtube-dl doesn't default to av1 here [00:39:44 CEST] <JEEB> I think old enough youtube-dl will guess that av1 in mp4 must be audio :P [00:41:01 CEST] <FreeBDSM> hold on, so https://gist.github.com/klaxa/6a59b49272d33b927af33d087a0bbdc7 is a video? [00:41:19 CEST] <furq> Stream #0:0(und): Video: av1 (Main) (av01 / 0x31307661), yuv420p(tv), 600x480, 0 kb/s, 25 fps, 25 tbr, 12800 tbn, 12800 tbc (default) [00:41:24 CEST] <FreeBDSM> riiight, fps [00:41:24 CEST] <klaxa> yes [00:41:29 CEST] <FreeBDSM> audio with fps, lol [00:41:31 CEST] <furq> well also "Video:" [00:41:36 CEST] <JEEB> yes, it is av1 video [00:42:10 CEST] <FreeBDSM> `youtube-dl -F "https://www.youtube.com/watch?v=o6xQDChpUR0" | pastebinit` > http://paste.ubuntu.com/p/KcvFXDvjG7/ [00:42:27 CEST] <JEEB> yup, too old youtube-dl [00:42:29 CEST] <JEEB> what I just said :P [00:42:37 CEST] <JEEB> I think I commented on youtube-dl's bug tracker about this [00:42:49 CEST] <JEEB> it was basically going "I don't know what this codec id is and it's mp4" [00:42:54 CEST] <JEEB> thus "This must be audio" [00:43:26 CEST] <FreeBDSM> but fps... [00:43:30 CEST] <furq> https://clbin.com/PbJlr [00:43:41 CEST] <JEEB> yes, they then fixed it [00:43:50 CEST] <JEEB> like furq's output shows [00:44:10 CEST] <FreeBDSM> I see [00:44:14 CEST] <FreeBDSM> thanks for the info [00:44:38 CEST] <FreeBDSM> I hope they downport this version to LTS Ubuntu [00:44:54 CEST] <furq> just uninstall it from apt and install it with pip [00:45:11 CEST] <JEEB> probably not unless you bug them about it :P and even then they might go "we do not new versions, only bug fixes" :P [00:45:24 CEST] <FreeBDSM> furq: no, this is a path to hell [00:45:26 CEST] <furq> i do that on debian testing because it's always outdated otherwise [00:45:26 CEST] <JEEB> also for reference the bug https://github.com/ytdl-org/youtube-dl/issues/17506#issuecomment-419710634 [00:45:33 CEST] <FreeBDSM> learned the hard way that pip breaks system [00:45:44 CEST] <JEEB> I actually like how fedora updates youtube-dl regularly [00:46:00 CEST] <JEEB> which makes sense since it's so much up to the systems it interfaces with [00:46:03 CEST] <JEEB> which can change [00:46:12 CEST] <furq> debian updates it pretty regularly but i've still needed newer versions a lot [00:46:16 CEST] <furq> also on freebsd [00:46:33 CEST] <JEEB> FreeBDSM: you can use a virtualenv if you want to keep it out of your main python root [00:46:37 CEST] <JEEB> so it's all in your home dir [00:46:39 CEST] <FreeBDSM> also, updating just youtube-dl wouldn't help [00:47:05 CEST] <JEEB> well right now it only picks av01 becuase it thinks it's the highest bit rate audio :P [00:47:07 CEST] <FreeBDSM> I still have old ffmpeg [00:47:09 CEST] <JEEB> as soon as you fix that [00:47:11 CEST] <furq> ^ [00:47:15 CEST] <FreeBDSM> oh, right [00:47:15 CEST] <furq> like i said it doesn't default to av1 here [00:47:25 CEST] <furq> on youtube-dl from this month [00:47:43 CEST] <JEEB> also the ffmpeg/ffprobe you showed actually had libaom built in [00:47:52 CEST] <JEEB> so whatever that was it could decode it [00:48:03 CEST] <furq> probably just no mapping for av1 in mp4 then [00:48:36 CEST] <JEEB> if that was true it wouldn't probe :P [00:48:45 CEST] <furq> it didn't [00:48:47 CEST] <furq> that was his problem [00:48:51 CEST] <JEEB> oh wait, that was klaxa's pastebin [00:48:54 CEST] <furq> yeah [00:49:01 CEST] <JEEB> ok, never mind then :) [00:49:05 CEST] <JEEB> anyways, night'o [00:50:36 CEST] <FreeBDSM> well, I've installed youtube-dl into a virtualenv [00:50:58 CEST] <FreeBDSM> but `which youtube-dl` shows that it still uses the one in /usr/bin/ [00:51:35 CEST] <FreeBDSM> ah, venvs don't seem to replace stuff in PATH [00:51:48 CEST] <FreeBDSM> wait, no, it did [00:52:28 CEST] <FreeBDSM> ah... zsh issue [00:52:44 CEST] <FreeBDSM> one needs to 'rehash' after activating a virtualenv [00:57:58 CEST] <FreeBDSM> well, that doesn't help if I used `-f 'bestvideo,bestaudio'` [01:00:38 CEST] <FreeBDSM> it throws ERROR: WARNING: unable to obtain file audio codec with ffprobe [01:00:46 CEST] <FreeBDSM> but there's no audio in that file [01:03:54 CEST] <FreeBDSM> nvm, looks like there's a difference between bestvideo,bestaudio vs bestvideo+bestaudio [01:05:57 CEST] <FreeBDSM> oh my, youtube-dl is a total crap [01:12:24 CEST] <FreeBDSM> turns out -x in user config breaks --merge-output-format 'mkv': it merges stuff but then deletes video + video+audio files, leaving only audio [01:28:40 CEST] <XLS202> Hey, I use ffmpeg as a recording and restreaming software for twitch. First i stream to an instance that records it and sends it to a second instance. And for example if I chance the scence in OBS or sometimes if a start a program the Stream crashes on twitch with the twitch error #2000. In the sametime the line "Sending bytes read report" is missing in the log from ffmpeg (https://pastebin.com/VdgVNUFT) has anyone an idea after what i [06:15:25 CEST] <pk08> hi [06:16:32 CEST] <pk08> i am trying to output TS stream in UDP multicast using complex_filter (used filters: show_volume, scale, overlay, nullsrc, setpts, etc) [06:17:06 CEST] <pk08> but when i try to pull ts from buffersink i only gets I frames for few seconds only [06:17:36 CEST] <pk08> after that i am getting `avcodec_receive_packet failed while encoding packet for output! Error: -541478725[End of file]` [06:17:57 CEST] <pk08> even if i push frames in filtersrc [06:18:15 CEST] <pk08> can anyone please tell me what can be the problem? [06:18:30 CEST] <pk08> why am I getting only I-Frames? [06:18:41 CEST] <pk08> and getting error after few sec? [06:19:05 CEST] <pk08> and thank you faLUSE for you help [06:19:37 CEST] <pk08> i have fixed PTS issue which we were discussed last time [10:06:13 CEST] <Filarius> for pet project I need settings for ffmpeg to make video as like it was re-encoded by youtube. Making some hobby research on video what target youtube, but I have slow internet to use youtube directly [10:06:55 CEST] <Filarius> even do not know how to google this right [14:43:01 CEST] <XLS202> Hey, I use ffmpeg as a recording and restreaming software for twitch. First i stream to an instance that records it and sends it to a second instance. And for example if I chance the scence in OBS or sometimes if a start a program the Stream crashes on twitch with the twitch error #2000. In the sametime the line "Sending bytes read report" is missing in the log from ffmpeg (https://pastebin.com/VdgVNUFT) has anyone an idea after what i [16:13:40 CEST] <M6HZ> Hi, I'm trying to understand how the links between filters are made one of the examples of the category "Filtergraph syntax" in the man page. [16:13:54 CEST] <M6HZ> This is the example: "nullsrc, split[L1], [L2]overlay, nullsink" [16:14:43 CEST] <M6HZ> My question is, are both of the outputs of "split" linked to "overlay" or just one of them? [16:42:00 CEST] <DHE> split produces 2 outputs. one is named L1, the other is being passed along to overlay which is also taking a second input named L2 [16:42:36 CEST] <DHE> with a comma, the two filters have a direct attachment. whereas with a semicolon; all inputs and outputs are explicit for the filters [16:59:25 CEST] <M6HZ> DHE: Thanks, alright. I would like to know, are both outputs of "split" connected to both inputs of "overlay"? [17:03:56 CEST] <DHE> no [17:04:23 CEST] <M6HZ> DHE: Ok, that's what I thought. [17:05:03 CEST] <DHE> I'm assuming the example you pasted is incomplete since there's no L2 output but it's used as an input [17:09:25 CEST] <M6HZ> DHE: So, if I understand correctly, the "split"'s output L1 goes the unlabelled input of "overlay", and the unlabelled "split"'s output goes to "nullsink"? [17:12:06 CEST] <DHE> well I was going to link you to https://ffmpeg.org/ffmpeg-filters.html#Filtergraph-description but I suspect you're already there now based on your example [17:12:36 CEST] <kepstin> no. the unlabelled output of split goes to the unlabelled input of overlay. There's no connection between split and nullsink [17:13:14 CEST] <M6HZ> DHE: Yes, I had written where It came from ;) [17:13:17 CEST] <kepstin> where L1 and L2 come from and go... isn't shown in the part of the filter chain you've pasted [17:14:07 CEST] <DHE> here's the same filtergraph in no-commas syntax: nullsrc[u1]; [u1]split[L1][u2]; [L2][u2]overlay[u3]; [u3]nullsink [17:14:33 CEST] <DHE> where u1, u2, and u3 are unlabeled connections formed by using the commas, [17:15:13 CEST] <M6HZ> kepstin: You're saying that "There's no connection between split and nullsink", but it is written that :If an output pad is not labelled, it is linked by default to the first unlabelled input pad of the next filter in the filterchain.". [17:15:38 CEST] <kepstin> M6HZ: nullsink isn't the next filter in the filterchain after split [17:15:48 CEST] <kepstin> M6HZ: overlay is the next filter [17:16:27 CEST] <M6HZ> sure. but if there is no available input in the next filter, isn't it going to search an input with the next filter? [17:16:32 CEST] <kepstin> M6HZ: no [17:16:41 CEST] <M6HZ> Alright. [17:16:46 CEST] <DHE> overlay takes 2 inputs. thats its job. [17:16:54 CEST] <kepstin> the `,` operator connects the filter before it to the filter after it. that's it. [17:16:58 CEST] <DHE> one is implied by the comma, one is explicitly specified with a label. [17:17:02 CEST] <DHE> (not in that order though) [17:18:16 CEST] <kepstin> if you need to do something other than connect all the outputs of one filter to all the inputs of the next filter, then you have to use labels to specify the connections to use. [17:20:15 CEST] <M6HZ> kepstin: but then, in this example, where is going the output L1? [17:20:36 CEST] <kepstin> M6HZ: your example is incomplete and doesn't say what L1 is connected to [17:21:00 CEST] <M6HZ> kepstin: True, but it is from the man page. [17:21:07 CEST] <M6HZ> I was confused [17:21:18 CEST] <chinknot> do I need any special option to trim flac files? the generated output loses duration metadata entirely if I use "-acodec=flac" and keeps the original input duration if I use "-acodec=copy" [17:22:02 CEST] <kepstin> M6HZ: ah. that example simply doesn't say. that example is not a complete filter chain, it's just demonstrating how a particular connection works. [17:22:55 CEST] <kepstin> M6HZ: just assume that L1 goes somewhere else, and L2 comes from somewhere else. [17:23:06 CEST] <M6HZ> kepstin: alright thank you :) [17:24:13 CEST] <kepstin> note that you are allowed to have labelled outputs in a filter chain that don't connect to anything. You can then put a `-map [L1]` or so in your ffmpeg command line, and that filter chain output will be stored as a stream in the output file. [17:26:06 CEST] <M6HZ> kepstin: ok, good to know. [17:28:31 CEST] <furq> chinknot: loses duration metadata? [17:28:41 CEST] <chinknot> yeah [17:29:09 CEST] <chinknot> if I inspect it with mediainfo there's no duration, if I try to use ffprobe same result [17:29:23 CEST] <furq> that sounds broken [17:29:31 CEST] <M6HZ> kepstin: I had understood things differently by reading : "A filtergraph is considered valid if all the filter input and output pads of all the filterchains are connected." [17:29:41 CEST] <furq> pastebin the command line and output [17:29:53 CEST] <chinknot> indeed. I tried inspecting the flac file with a flac frontend but there's no error in the file [17:30:01 CEST] <kepstin> M6HZ: it can be connected to something outside of the filterchain [17:30:23 CEST] <M6HZ> ok [17:32:02 CEST] <chinknot> for instance, the command was something as simple as ffmpeg -i input.flac -ss 10 -to 20 -acodec flac output.flac [17:33:29 CEST] <furq> yeah that works fine here [17:33:57 CEST] <chinknot> I downloaded a flac sample from internet and the same command works ok trimming and generating a new file with correct duration [17:37:36 CEST] <chinknot> something I noticed when comparing different flac files is the stream size. on the working flac the stream size is 100%, on the other flac is 98% [17:37:42 CEST] <chinknot> does that mean anything? [17:39:54 CEST] <TikityTik> chinknot: flac files do compression [17:40:15 CEST] <TikityTik> chinknot: they only compress if there's no audio [17:40:36 CEST] <TikityTik> unlike wav that wastes space to represent the no audio part [17:41:21 CEST] <TikityTik> which could possibly explain the different file size [17:51:36 CEST] <chinknot> I just tried re encoding it with a modern libflac but same issue. it isn't exported correctly [18:04:46 CEST] <chinknot> it's the -ss and -to part failing the conversion. it happens if I re encode in another format entirely as well. just tried libvorbis [20:11:50 CEST] <chinknot> I'm the guy who was having troubles with flac files before. I tried downloading previous ffmpeg builds and trying something more stable (not the nightly branch, the distributor builds) and I found out ffmpeg 3.4.2 is the latest version that works for me [20:12:37 CEST] <chinknot> no errors and the output files correctly displays a duration [22:15:18 CEST] <Kingslayer> howdy [22:30:24 CEST] <pomaranc> Kingslayer: oathbreaker! [22:31:09 CEST] <Kingslayer> hey is it possible to set the size in number of samples an audio frame will be that's returned by avcodec_decode_audio4 or similar? [22:43:56 CEST] <Kingslayer> also anyone know why i might get "bad access" error when calling av_samples_get_buffer_size? [22:44:15 CEST] <Kingslayer> sorry nvm it wasnt that [22:59:55 CEST] <M6HZ> Does someone have a clue about the meaning of this sentence present in the man page "The -lavfi option is equivalent to -filter_complex." ? [23:00:13 CEST] <JEEB> they are synonyms [23:00:19 CEST] <JEEB> as in, the point internally to the same thing [23:00:26 CEST] <JEEB> *they [23:00:47 CEST] <M6HZ> Alright [23:02:11 CEST] <M6HZ> I was also wondering, is there a good reason to have both -vf and -filter_complex since the second one is able to do the work of the first? [23:06:29 CEST] <furq> -vf and -af are useful shorthands [23:07:12 CEST] <JEEB> also vf and af build separate filter chains (which are less powerful) [23:08:07 CEST] <M6HZ> What do you mean by "separate filter chains" ? [23:08:55 CEST] <JEEB> you will have two separate filter chains, as it says on the tin [23:09:00 CEST] <JEEB> -filter_complex is a single filter chain [23:09:37 CEST] <JEEB> in many cases it doesn't matter but I've had reconfiguration of audio happen to affect video due to the whole filter chain getting re-configured [23:10:13 CEST] <M6HZ> Oh you mean when both -vf and -af are used simultaneously? [23:10:44 CEST] <JEEB> each creates a single filter chain, yes. so if you are using both you are getting two separate filter chains: one for video and one for audio [23:10:52 CEST] <M6HZ> Ok [23:11:49 CEST] <M6HZ> Why not to replace both by a new command -fc (because it's short) ? [23:27:06 CEST] <M6HZ> Wouldn't it make the whole program easier to use? [23:32:33 CEST] <Kingslayer> brb [00:00:00 CEST] --- Mon Apr 22 2019

1 0

ffmpeg-devel.log.20190420
by burek 21 Apr '19

21 Apr '19

[00:14:25 CEST] <cone-932> ffmpeg 03Carl Eugen Hoyos 07master:48860df34df6: configure: Add .exe suffix to toolchain calls. [00:17:57 CEST] <cehoyos> Any comments about -Wno-gnu-variable-sized-type-not-at-end? http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241729.html [00:19:07 CEST] <cehoyos> What are win32 arm/arm64 devices? Compilation works fine but I wonder what to do with the binaries... [00:20:16 CEST] <nevcairiel> technically you can run Windows 10 IoT on a variety of ARM devices, including a Pi3 [00:20:40 CEST] <cone-932> ffmpeg 03Carl Eugen Hoyos 07master:93209902ede3: lavfi/fspp: Simplify a macro. [00:20:47 CEST] <nevcairiel> not sure if any are officially sold yet [00:21:11 CEST] <cehoyos> I see. [00:21:20 CEST] <cehoyos> Did you look again into the aac vs2019 issue? [00:21:42 CEST] <nevcairiel> not yet, probably not before next week [00:22:45 CEST] <cehoyos> In-tree compilation works now without changes, I will look into mslink next week to see if I can fix out-of-tree builds. [00:22:56 CEST] <cehoyos> mklink [00:25:55 CEST] <cehoyos> Matebook E 2019 is apparently a real-life arm Windows device [00:27:00 CEST] <nevcairiel> wbs has been doing a lot of work with windows on arm if there is any problems [00:28:47 CEST] <cehoyos> I had to realize that gas-preprocessor is needed, then it worked fine [00:29:12 CEST] <cehoyos> I know now how to test future arm64 patches for compilation issues. [01:28:17 CEST] <cone-932> ffmpeg 03Jun Zhao 07master:d93e44332f1b: lavf: bump version/add APIchanges entry when cleanup applehttp [05:21:06 CEST] <hanetzer> question. should I be using https://github.com/FFmpeg/FFmpeg.git or git://source.ffmpeg.org/ffmpeg.git ? [05:34:32 CEST] <kierank> the latter [05:34:35 CEST] <kierank> the former is a mirror [05:34:38 CEST] <kierank> it may not be up to date [05:34:47 CEST] <kierank> likely it will be but i have seen it be delayed before [06:46:19 CEST] <hanetzer> kierank: gotcha. looking into the possibility of porting ffmpeg to meson as 'exercise' and it may be useful to you guys as well :) [07:16:38 CEST] <cone-553> ffmpeg 03Gyan Doshi 07master:3153a6502a28: avcodec: add AV_CODEC_FLAG_DROPCHANGED to flags [07:19:09 CEST] <cone-553> ffmpeg 03Gyan Doshi 07master:3a07aec82741: doc/APIchanges: update for 3153a6502a [08:21:15 CEST] <nevcairiel> hanetzer: someone already did that once [08:21:27 CEST] <hanetzer> orly. [08:21:37 CEST] <nevcairiel> i forgot where its at [11:06:18 CEST] <durandal_1707> ubitux: i did .csp for lut3d/lut1d on ML [11:16:20 CEST] <ubitux> looks fine at first glance, i'll send an official answer soon [11:16:53 CEST] <ubitux> can you give me some context on where it comes from and why the sudden interest in it? [11:20:15 CEST] <durandal_1707> ubitux: i work for secret agency and they work with bunch of cineSpace LUTs, on serios side I just found it exists [11:20:53 CEST] <ubitux> ok :) [11:24:25 CEST] <J_Darnley> hanetzer: look in the ML archives if you want to see when it was last discussed [11:24:46 CEST] <J_Darnley> June and July 2018 http://ffmpeg.org/pipermail/ffmpeg-devel/2018-June/thread.html http://ffmpeg.org/pipermail/ffmpeg-devel/2018-July/thread.html [11:28:53 CEST] <BtbN> don't use git:// urls, ever. They are unsafe. [11:29:30 CEST] <BtbN> I also don't think a switch of build-systems would be possible to get accepted. [11:29:44 CEST] <BtbN> Unless you somehow manage to make it 100% regression free, which seems impossible. [11:29:45 CEST] <hanetzer> BtbN: yeah. I was more pointing at the domain/etc; I believe some portion of the documentation mentions the git:// url [11:33:52 CEST] <hanetzer> BtbN: elaborate the regression free bit? [11:34:13 CEST] <BtbN> Someone on the ML will find an edge case the new build system breaks, and veto it on that basis. [11:34:48 CEST] <hanetzer> gotcha. so until its 1:1 feature parity that's a no until it is [11:35:04 CEST] <BtbN> Even then I'd suspect people will give it a hard time [11:35:19 CEST] <BtbN> Cause, the bunch of script we have right now do work surprisingly fine [11:36:32 CEST] <J_Darnley> I too think it is unlikely to get accepted wih anything less then full feature parity [11:36:41 CEST] <J_Darnley> *than [11:36:53 CEST] <BtbN> I also still don't feel like meson is mature enough [11:37:13 CEST] <BtbN> Every time I use it I end up in a situation where I have to manually install a sometimes project-specific version of it [11:37:54 CEST] <hanetzer> expected. I did the mesonbuild port for mate-desktop and there is currently some grumbling about ninja uninstall 'erroring' because it tries to remove icon files twice, but honestly irl make install and the equivalent to the root filesystem is rather uncommon [11:39:25 CEST] <J_Darnley> I think meson looks like one of the configure & make relacements with promise [11:40:03 CEST] <BtbN> But why does ffmpeg configure need replaced? [11:40:27 CEST] <hanetzer> BtbN: do me a favor; got a clone? assume you do. time ./configure [11:41:04 CEST] <J_Darnley> I don't really think it does, especially not since some genius fixed the massive slow-down that crept in. [11:42:16 CEST] <J_Darnley> But as I'd like to say to people who say "why don't you write it in X?": please go ahead and do that [11:42:46 CEST] <hanetzer> J_Darnley: found the stuff you were talking about; https://gitlab.freedesktop.org/gstreamer/meson-ports/ffmpeg << gonna give this a go [11:44:12 CEST] <nevcairiel> configure time complaints are such an overrated problem, especially since the big slowdown from recent years has been fixed [11:44:26 CEST] <nevcairiel> so it takes 30 second to configure, big deal [11:44:51 CEST] <JEEB> yea, I stopped building on windows when it was 10min, but since that has dropped dramatically [11:46:07 CEST] <J_Darnley> Ah look at that repo. Good to see gaps being papered over with python scripts. [11:46:37 CEST] <nevcairiel> that sort of defeats the purpose doesnt it [11:46:37 CEST] <hanetzer> nevcairiel: that's fair. but then again, the fact that 'some genius' had to fix that issue and not just 'some dude' kinda sucks :) [11:47:32 CEST] <hanetzer> J_Darnley: directory of python scripts? curious, I am :) [11:47:53 CEST] <hanetzer> theoretically said gaps could be included into meson proper if needed. [11:47:54 CEST] <J_Darnley> The root directory! [11:48:04 CEST] <nevcairiel> there is at least 7 python scripts that fix up a lacking build system [11:48:39 CEST] <BtbN> And then we end up with the same situation other projects have. A build system that only works with a very specific and/or super bleeding edge meson version [11:48:40 CEST] <J_Darnley> And "some dude" won't know how to profile a shell script, let alone python. [11:50:16 CEST] <hanetzer> J_Darnley: ah, that's a place I personally wouldn't put my extra glue so was looking in ./tools :P [11:50:29 CEST] <nevcairiel> if anything it should've gone into ffbuild [11:50:42 CEST] <J_Darnley> Sure, a new build system will have some gaps but why would you chose python, aka the worst language [11:51:01 CEST] <hanetzer> that too, but ffbuild is the ./configure guts right? thought they may want to avoid mixing it up :) [11:51:06 CEST] <durandal_1707> ubitux: the cineSpace luts supports XxYxZ luts (instead of just YxYxY) is such thing easily added to lut3d? [11:51:11 CEST] <nevcairiel> they choose meson, meson is in python, so one might assume python is already installed [11:51:23 CEST] <nevcairiel> ... unless you're on windows and use meson.exe which has python baked in =p [11:51:39 CEST] <J_Darnley> Yeah but I don't have to see any python code with meson (unlike scons) [11:51:56 CEST] <BtbN> Python is probably the best choice for build systems right now [11:52:00 CEST] <hanetzer> nevcairiel: yep. a simple port I'm working on (icon theme, only one source file for the theme engine but its mostly install_data and install_subdir ca [11:52:03 CEST] <hanetzer> lls) [11:52:08 CEST] <BtbN> it's relatively fast and powerful, super portable and widely available [11:52:13 CEST] <nevcairiel> i rather like how i can build eg. dav1d with meson without needing msys at all [11:52:39 CEST] <nevcairiel> or python for that matter [11:52:51 CEST] <hanetzer> the current Makefile solutions I've seen in icon themes are terrible lol, so I'm writing that bit for index.theme generation in python because I know meson users will have python :) [11:52:55 CEST] <nevcairiel> but its a far simpler project then ffmpeg [11:53:17 CEST] <J_Darnley> I'd probably like meson when its "finished" [11:53:26 CEST] <hanetzer> J_Darnley: or at least a 1.x release eh? [11:53:50 CEST] <BtbN> It would also be entirely possible to just clone what configure does, but writing it in Python instead. Would be a serious performance boost, and if done right, provide the exact same features. [11:54:16 CEST] <nevcairiel> but outside of possibly performance enhancements, also doesnt offer anything else [11:54:29 CEST] <nevcairiel> one point of using something like meson is to claim that in the long run its simpler to maintain [11:54:46 CEST] <nevcairiel> because you dont have to work on the plumbing all the time [11:54:49 CEST] <hanetzer> aight guys, later. $dayjob [11:54:55 CEST] <hanetzer> J_Darnley: thanks for the links [11:55:00 CEST] <J_Darnley> no problem [11:55:15 CEST] <BtbN> My experience with build systems is that you have to work on plumbing a lot, because the build systems break thing all the time. [11:55:18 CEST] <J_Darnley> or you're welcome [11:55:40 CEST] <BtbN> That primarily a problem of all the fancy new "better" build systems though [11:55:50 CEST] <BtbN> autotools and cmake always are rock stable in that regard [11:59:13 CEST] <nevcairiel> writing autotools files is even more arcane magic then writing custom shell scripts tho [11:59:43 CEST] <BtbN> Yep, autotools is horrible to work with. [11:59:43 CEST] <J_Darnley> Except for when a dev puts checks in the wrong order letting it detect signed c99 stdint but not unsigned stdint [11:59:53 CEST] <BtbN> But stuff written 20 years ago pretty much still works unchanged [12:07:22 CEST] <cone-429> ffmpeg 03Paul B Mahol 07master:fee7c15d8754: avfilter/af_surround: allow user to change overlap and win_func [12:30:31 CEST] <hanetzer> I don't much mind autotools were it not for the m4sh syntax and long ./bootstrap-alike and ./configure times :) [13:38:46 CEST] <cone-429> ffmpeg 03Gyan Doshi 07master:bf4245e9521b: doc/filters: list values for af_surround window function [14:15:14 CEST] <cone-429> ffmpeg 03Paul B Mahol 07master:b9d25b1a6ef0: avfilter/vf_lut3d: add cineSpace 1D lut parsing [14:15:15 CEST] <cone-429> ffmpeg 03Paul B Mahol 07master:e20ad3bd59cc: avfilter/vf_lut3d: add cineSpace 3D lut support [14:23:36 CEST] <cone-429> ffmpeg 03Paul B Mahol 07master:782ae68a117f: avfilter: add lagfun filter [17:46:19 CEST] <cone-100> ffmpeg 03Jarek Samic 07master:1c46ab4815f8: lavfi: add colorkey_opencl filter [23:56:43 CEST] <cone-146> ffmpeg 03Lou Logan 07master:d8245cff167f: doc/mailing-list-faq: auto unsubscribe due to DMARC [00:00:00 CEST] --- Sun Apr 21 2019

1 0

ffmpeg.log.20190420
by burek 21 Apr '19

21 Apr '19

[02:18:30 CEST] <ncouloute> Since I cant get the concat muxer to output a cfr for mp4. I'm looking into using the concat filter, but is there any way to find out where the files start and end after they have been concatenated? [02:23:12 CEST] <TheAMM> ffprobe the files before doing the encode, add the durations [02:23:43 CEST] <TheAMM> file 1 starts at 0, file 2 starts at file_1_duration [02:24:10 CEST] <TheAMM> probably + one frame [02:27:56 CEST] <ncouloute> problem is I'm changing the framerate of the files as well. [02:30:08 CEST] <JEEB> I'd probably just stick the video/audio streams together separately and then apply the stream copy frame rate patch so -r XX would work [03:28:32 CEST] <ncouloute> Not sure I understand what all that means.I think you mean combine the video stream together as one file and combine the audio together as one file and then custom build ffmpeg with a patch located somewhere.. Currently using zeranoe build. Where would I find this patch? Cant be too hard [03:55:31 CEST] <friendofafriend> ls [03:55:37 CEST] <friendofafriend> Excuse me. [04:10:33 CEST] <obscure> can ffmpeg trim bits out of a 250 mb webm video [07:43:21 CEST] <__raven__> processing images to video clips sometimes leads to an endless loop caused by "invalid data found..." due to negative duration. how to exit that? [23:43:32 CEST] <FreeBDSM> hello [23:44:57 CEST] <FreeBDSM> it looks like I'm having problems with ffmpeg being unable to play a file: `ffprobe -show_streams 'file:that_file.mp4'` results into `Unsupported codec with id 32797 for input stream 0` [23:46:50 CEST] <TikityTik> can you reference subtitle streams? -filter_complex "[0:v]subtitles=[0:s]" [23:51:53 CEST] <furq> TikityTik: -i foo.mkv -vf subtitles=foo.mkv [23:52:08 CEST] <TikityTik> furq: sometimes the filenames are too long [23:52:20 CEST] <TikityTik> which is why i was wondering if i could do it through those stream identifies [23:52:51 CEST] <furq> yeah you can't use labels like that [23:56:09 CEST] <FreeBDSM> tech is crap :( [23:56:16 CEST] <FreeBDSM> nothing just works [23:57:04 CEST] <TikityTik> lol [23:58:35 CEST] <TikityTik> ah got it working [23:58:48 CEST] <TikityTik> err nevermind [00:00:00 CEST] --- Sun Apr 21 2019

1 0

ffmpeg-devel.log.20190419
by burek 20 Apr '19

20 Apr '19

[00:00:23 CEST] <JEEB> probably [00:00:28 CEST] <mkver> One of those "via ffmpeg-devel" commits is mine (namely 18a851aca766ff8c7199c9e0c37d8fa642e41920). [00:00:43 CEST] <mkver> Then it is time to change the email provider. [00:01:57 CEST] <JEEB> yea, basically your name should be correct because the mailing list only rewrites the e-mail (and the "via xxx"), so at least that part should be OK [00:02:19 CEST] <JEEB> of course it still was a mistake on part of whomever pushed. but most likely nobody expected the patches to come out like that [00:02:35 CEST] <JEEB> then patchwork doing the name attribution incorrectly is another thing :D [00:03:02 CEST] <JEEB> not sure if it actually also rewrites the patches if you try to get the patches from it [00:03:14 CEST] <JEEB> if yes, then that's bad. I've sometimes used patchwork to curl | git am patches [00:03:39 CEST] <mkver> Which (free) provider doesn't implement DMARC? [00:22:58 CEST] <cone-741> ffmpeg 03Steven Liu 07master:608d5fd8b616: add tests/ref/fate/hls-segment-size for the fate test [00:22:59 CEST] <cone-741> ffmpeg 03Steven Liu 07master:55619f30122e: rename hls_segment_filename in fate-hls-segment-size for fate [01:15:07 CEST] <mkver> I have just found out that googlemail.com had a different DMARC policy than gmail.com. I thought googlemail was just an alias for gmail; apparently it's not so easy. [01:15:38 CEST] <mkver> It's v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:mailauth-reports@google.com for googlemail vs. v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com for gmail. [01:16:02 CEST] <mkver> Hopefully using @gmail will fix the problems in the future. [01:17:32 CEST] <cone-741> ffmpeg 03Carl Eugen Hoyos 07master:96fc0cbfde24: tests: Add EXESUF to program calls. [01:27:53 CEST] <BtbN> It affects it for a lot more servers than just googlemail.com [01:28:04 CEST] <BtbN> google.com protonmail are the first ones that come up [01:29:59 CEST] <cehoyos> I succeeded building and testing qsv on Windows but I wonder how this is supposed to work without the patch I just sent... [01:32:18 CEST] <BtbN> You mean the EXECSUF for fate? [01:32:46 CEST] <BtbN> That's a WSL specialty. Everywhere else you can just omit the .exe suffix and it'll run. [01:33:29 CEST] <BtbN> oh, no, the mfx one, nvm [01:34:01 CEST] <cehoyos> The mfx one, yes [01:34:15 CEST] <BtbN> I remember that weird -llibmfx being there very intentionally for some horrid weird closed source version of the Media SDK [01:34:21 CEST] <cehoyos> Although I also wonder why nobody ever used wsl for fate, I find it very useful [01:34:44 CEST] <BtbN> Every other case is supposed to be covered by pkg_config [01:34:45 CEST] <cehoyos> So there is another version of the same library that is called liblibmfx.a or similar? [01:35:15 CEST] <BtbN> Pretty much, yes [01:35:26 CEST] <cehoyos> Cool, where can I find it? [01:35:40 CEST] <BtbN> Need to register with Intel and dig in their closed source media SDKs [01:35:54 CEST] <cehoyos> I'll ask them to comment [01:36:16 CEST] <BtbN> It's the issue of lib???.so -> ???.lib on Windows. But someone didn't pay attention and named the .lib lib???.lib [01:36:20 CEST] <BtbN> so that's where that comes from [01:40:40 CEST] <BtbN> See comment of 164e2773261451ef33c4616296ec5bebecff42af [01:48:21 CEST] <cehoyos> BtbN: Thank you. I wonder how I am going to fix this for the "normal" case... [01:50:23 CEST] <BtbN> Every other case should have a proper pkg-config file, you you probably just need to adjust your PKG_CONFIG_PATH? [01:54:05 CEST] <cehoyos> I still need to see a toolchain for win32 that supports pkg-config by default [01:54:44 CEST] <cehoyos> I don't like it, I use it if available but forcing users to install it when it is not needed still seems absurd to me. [01:55:33 CEST] <cehoyos> Especially for a library like mfx that has exactly one constant dependency. [04:29:46 CEST] <BBB> kierank: don't you ever sleep? :D [04:29:54 CEST] <kierank> BBB: i'm in the usa [04:30:01 CEST] <BBB> yay [04:30:08 CEST] <BBB> east or west coast? [04:30:12 CEST] <kierank> BBB: not really, it's hard to eat well in florida [04:30:21 CEST] <BBB> ah [04:30:21 CEST] <kierank> I saw my first vegetable for a week [04:30:44 CEST] <kierank> was a joy to see broccoli on a plate [04:30:46 CEST] <BBB> why wouldn't they say "we're adding chromecast support to prime video app" instead of "we're bringing prime video app to chromecast" [04:31:13 CEST] <BBB> is my english so sub-standard? [04:31:26 CEST] <kierank> BBB: chromecast doesn't have apps per-se [04:31:41 CEST] <kierank> but yeah [04:31:42 CEST] <kierank> oh [04:31:42 CEST] <BBB> exactly, so I have no idea what it means [04:31:43 CEST] <kierank> hmm [04:31:58 CEST] <kierank> I read it as you can cast to chromecast from the app [04:32:18 CEST] <BBB> I want to read it that way, but it very specifically does not say that [04:32:26 CEST] <BBB> that's why I said, it seems written by a marketing dude [04:32:31 CEST] <kierank> I don't see what it can mean otherwise [04:32:48 CEST] <kierank> but yeah maybe marking to make amazon sound more "dominant" [04:33:07 CEST] <BBB> I could interpret it as "our prime video app player in your browser will allow casting to chromecast" [04:33:20 CEST] <BBB> which would be incredibly underwhelming [04:33:32 CEST] <kierank> I would be happy with that [04:33:33 CEST] <BBB> but technically consistent with the message in the press release [04:33:35 CEST] <kierank> that's better than nothing [04:33:48 CEST] <BBB> we write all this software so we can get better than nothing [04:34:05 CEST] <BBB> yeah, I know I still need dvd players, but hey, at least the dvd was encoded with x264 [04:34:23 CEST] <kierank> x264 blu-ray still (!) is a big deal [04:34:46 CEST] <BBB> it's a big deal for blu-ray, but blu-ray still sucks [04:34:56 CEST] <kierank> it's better quality than netflix [04:35:00 CEST] <kierank> or all streaming [04:35:10 CEST] <BBB> yes that's sadly true [04:35:11 CEST] <kierank> and can't be revoked [04:35:40 CEST] <BBB> I hope you're right and android app will support casting :) [04:36:09 CEST] <BBB> we'll see "in the coming months" [04:36:14 CEST] Action: BBB gonna sleep now [04:36:19 CEST] <BBB> g'nite [11:34:32 CEST] <durandal_1707> Nicolas George is full of shit, he thinks he is smartest asshole on planet, and have opinion about anything [11:43:57 CEST] <j-b> durandal_1707: this is not a correct way to speak about anyone [11:55:03 CEST] <ubitux> you just have to say "he's french", that's enough [13:18:08 CEST] <BradleyS> it is better to upsample, do all processing, and then downsample, than to up/downsample for each audio filter [13:19:35 CEST] <BradleyS> most quality audio plugins do both, if sample rate <= 48kHz, upsample+process+downsample, if > 48kHz only process [13:20:18 CEST] <durandal_1707> yes, it is faster. Note this is different than resampling - which is basically interpolation [13:20:21 CEST] <BradleyS> with multiple filters it makes sense to manually upsample and downsample before and after to limit the amount of sample rate changes [13:21:21 CEST] <BradleyS> yes [13:21:32 CEST] <BradleyS> just saying, paul is correct in this case [13:22:08 CEST] <BradleyS> not sure what others' objections are about but it seems they might be applying video thinking to audio [13:23:27 CEST] <BradleyS> patches look fine to me [13:25:36 CEST] <BradleyS> it's not much different that processing 8-bit pixels in 32-bit, for instance [13:25:47 CEST] <BradleyS> it's not about negotiation at all [13:41:26 CEST] <cone-962> ffmpeg 03Gyan Doshi 07master:3bef1dab6e88: avutil/colorspace: add macros for RGB->YUV BT.709 [13:57:23 CEST] <cone-962> ffmpeg 03Carl Eugen Hoyos 07master:dd06f022b074: lavf/utils: Allow url credentials to contain a slash. [13:59:10 CEST] <cone-962> ffmpeg 03Paul B Mahol 07master:78c8a765369d: avcodec/get_bits: unbreak get_bits_le() with cached reader [14:02:24 CEST] <cone-962> ffmpeg 03Carl Eugen Hoyos 07master:53064e134ca6: lavc/alac: Make a variable unsigned. [14:08:05 CEST] <cone-962> ffmpeg 03Carl Eugen Hoyos 07master:32215b21407e: lavf/vc1dec: Reduce probe score for streams with invalid frames. [14:09:13 CEST] Action: BradleyS gives durandal_1707 a cookie [14:20:59 CEST] <cone-962> ffmpeg 03Carl Eugen Hoyos 07master:a24a1523e8d7: lavu/hwcontext_d3d: Cast src pointers calling av_image_copy*(). [16:13:41 CEST] <cehoyos> nevcairiel: Is the new patch (with hostexesuf) ok? Tested with mingw64 and cl.exe from wsl. [16:14:46 CEST] <nevcairiel> looks ok on first glance [16:19:04 CEST] <cehoyos> nevcairiel: Thank you, I sent one more that I believe should be non-controversial, do you agree? [16:19:57 CEST] <nevcairiel> probably also need the .exe in the cl_major_ver= line [16:20:05 CEST] <cehoyos> The remaining issue is that out-of-tree builds need mklink run after configure, I wonder why configure overwrites a "src" symlink [16:20:31 CEST] <cehoyos> fate fails for me with cl.exe 64bit, works with 32bit, but both work for you, right? [16:21:01 CEST] <cehoyos> indeed [16:21:13 CEST] <nevcairiel> there is a bug in fate that i sent a patch for that makes one test fail [16:21:17 CEST] <nevcairiel> i should push that [16:21:34 CEST] <nevcairiel> although its probably fine if you run on wsl anyway [16:22:19 CEST] <cehoyos> Is that related to png or to mov/aac-fixed/rotate? [16:22:24 CEST] <nevcairiel> apng [16:22:42 CEST] <cehoyos> The problem I see is with the rotate-test that also tests aac wich outputs one different frame [16:22:55 CEST] <cehoyos> I don't have zlib yet... [16:23:19 CEST] <cehoyos> one different audio frame [16:24:15 CEST] <cehoyos> Is it possible that I use a newer cl.exe than you? [16:24:40 CEST] <nevcairiel> if you got vs2019, then i havent setup new stations for that yet [16:24:46 CEST] <nevcairiel> if its 2017, i run the latest of that [16:25:08 CEST] <cehoyos> I use vc2019 [16:25:11 CEST] <nevcairiel> 2019 only came out two weeks ago or so [16:25:21 CEST] <cehoyos> Installed tonight... [16:25:36 CEST] <cehoyos> Is it possible to uninstall the (huge) ide? [16:25:59 CEST] <cone-962> ffmpeg 03Hendrik Leppkes 07master:a87774636b87: tests: don't include TARGET_PATH in the sample path needlessly [16:26:11 CEST] <cehoyos> I chose "selected components" and only the compiler but it also installs the ide [16:26:23 CEST] <nevcairiel> presumably its supposed to, but i dont know how to do it exactly [16:26:32 CEST] <cehoyos> ok [16:26:41 CEST] <JEEB> yea not sure the IDE is separately installable/uninstallable. mozilla and friends used to have scripts to archive just the compiler/SDK though [16:27:19 CEST] <cehoyos> Does building from a separate directory work with msys? [16:27:43 CEST] <nevcairiel> it also works with msvc, my fate boxes all do it [16:27:43 CEST] <cehoyos> I mean out-of-tree builds [16:27:50 CEST] <JEEB> yea, out of tree should work [16:27:58 CEST] <cehoyos> you mean it works with msys and msvc, no? [16:28:06 CEST] <nevcairiel> but the detection to not do a symlink my fail on wsl [16:28:10 CEST] <nevcairiel> may* [16:28:11 CEST] <JEEB> ah [16:28:17 CEST] <cehoyos> as opposed to wsl and msvc [16:28:34 CEST] <JEEB> well, at least it should be relatively easy to check if the result seems sane? [16:28:37 CEST] <nevcairiel> indeed [16:28:42 CEST] <cehoyos> I need a symlink: The full paths are completely incompatible [16:28:54 CEST] <cehoyos> Windows "mklink" makes symlinks that work fine in wsl [16:29:30 CEST] <cehoyos> wsl does not understand "C:\" [16:29:40 CEST] <nevcairiel> this is true [16:30:12 CEST] <cehoyos> But everything works fine if I run configure and then make a symlink with mklink [16:30:28 CEST] <cehoyos> I just believe that if such a symlink exists, configure should not delete it [16:32:11 CEST] <nevcairiel> i actually have vs2019 installed here locally for testing, lets see what happens in fate [16:35:08 CEST] <cehoyos> Please! [16:35:29 CEST] <nevcairiel> didnt really get around to testing it much yet the last two weeks [16:35:40 CEST] <cehoyos> fate-filter-meta-4560-rotate0 [16:35:48 CEST] <cehoyos> is the test that fails with 64bit here [16:40:20 CEST] <nevcairiel> i get that too [16:48:04 CEST] <nevcairiel> only one audio frame being different is a bit weird, if it were to miscompile one would expect more then one error like that, and its not even floating point to generate inaccuracies there. but then, the aac fixed point decoder is rather hacky in various places, so who knows [17:35:39 CEST] <cone-962> ffmpeg 03Andreas Hakon 07master:e750dc9de61b: libavformat: improve logs with cur_dts [18:06:56 CEST] <cehoyos> nevcairiel: Thank you for the confirmation, I had similar thoughts... [18:25:55 CEST] <cone-962> ffmpeg 03Dan Sanders 07master:fac761dae927: avformat/apetag: tag values are unsigned [19:50:45 CEST] <JEEB> +This protocol provides most functionalities of the UDP protocol RTMFP : [19:50:45 CEST] <JEEB> +unicast, direct p2p and multicast (via NetGroup). [19:50:53 CEST] <JEEB> is this the zombie of RTMP going around? [19:51:11 CEST] <JEEB> or I guess this is something new with a name resembling Adobe's still-walking zombie protocol [20:33:46 CEST] <mkver> Can someone please confirm that my mails sent via gmail (the two sent today) are actually working properly and are not munged with "via ffmpeg-devel"? [20:34:04 CEST] <JEEB> mkver: which thread? [20:34:21 CEST] <mkver> E.g. this email: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242818.html [20:34:39 CEST] <JEEB> yea, that is how it was received [20:35:08 CEST] <JEEB> think the via things get munged at a point before writing them onto the pipermail [20:35:30 CEST] <JEEB> or maybe not [20:35:36 CEST] <mkver> Good. Then I can now resend the munged patches. [20:35:57 CEST] <JEEB> just trying to figure out if there were any munged mails from your name on the pipermail [20:36:47 CEST] <JEEB> and yes, that mail you linked in my mail client shows up without the via ... [20:36:50 CEST] <JEEB> thing [20:36:53 CEST] <mkver> All mails on the mailing list archive are ok; but apparently those sent to other subscribers of the list were not. [20:37:16 CEST] <mkver> And patchwork is affected, too. [20:38:00 CEST] <JEEB> yeh, my (gmail) interface shows it as coming from your e-mail [20:39:34 CEST] <mkver> Good. Thanks for the confirmation. [21:10:19 CEST] <cone-962> ffmpeg 03Michael Niedermayer 07master:837820f385af: avcodec/diracdec: Use 64bit in intermediate of global motion vector field generation [21:10:20 CEST] <cone-962> ffmpeg 03Michael Niedermayer 07master:110dce963315: avcodec/ivi: Move buffer/block end check to caller of ivi_dc_transform() [21:10:21 CEST] <cone-962> ffmpeg 03Michael Niedermayer 07master:bcf9d2a17242: avcodec/wmv2dec: Check that the P frame secondary header fit in the input [21:10:22 CEST] <cone-962> ffmpeg 03Michael Niedermayer 07master:3ed360ea5cba: avcodec/pictordec: avoid pointers in picmemset() [21:10:23 CEST] <cone-962> ffmpeg 03Michael Niedermayer 07master:838710bd6c5f: avcodec/pictordec: Only recalculate d when y changes in picmemset() [22:14:45 CEST] <durandal_1707> cehoyos: you are back! [22:21:02 CEST] <cehoyos> Correct [00:00:00 CEST] --- Sat Apr 20 2019

1 0

ffmpeg.log.20190419
by burek 20 Apr '19

20 Apr '19

[01:32:55 CEST] <t-mullen> My raw video input has frames of variable size. How would I change the input size dynamically? Are video filters relevant here? [01:35:10 CEST] <cehoyos> That cannot work, where do the frames come from? [01:36:33 CEST] <t-mullen> They're dumped from an RTCVideoSink. Should I just scale the frames before passing them as input? [01:37:18 CEST] <cehoyos> I don't see how any application (not necessarily ffmpeg) is supposed to know where one frame ends and the next begins if they are not all the same size. [01:37:45 CEST] <t-mullen> I don't expect it to know, I wanted to know if there was a way to specify frame size alongside the frame. [01:38:01 CEST] <cehoyos> If it is one frame, you have no problem [02:41:23 CEST] <DHE> he's gone, but the raw swscale interface is probably the best bet. if resolutions are in a fixed set of possibilities, keep the contexts around I guess... [14:41:53 CEST] <shibboleth> some application using ffmpeg for streaming expects rtsp over udp [14:42:15 CEST] <shibboleth> is there any envvar that will use rtsp over tcp by default? [14:43:54 CEST] <JEEB> no, you just set the AVOption [14:44:34 CEST] <JEEB> rtsp_transport is one of udp, tcp, udp_multicast, http [14:44:40 CEST] <JEEB> default is udp [14:45:09 CEST] <JEEB> you set that to TCP and you get rtsp over tcp [14:45:16 CEST] <shibboleth> yeah, but the application doesn't let me specify rtsp transport [14:45:40 CEST] <JEEB> that is then a problem in the application rather than in the framework [14:45:47 CEST] <shibboleth> sure [14:47:02 CEST] <JEEB> if it's an open source application you can patch it of course. if it's not, then you will have to get the source code they used for FFmpeg (since by LGPL rules they have to give you it to be able to replace it) [14:47:17 CEST] <JEEB> and replace the copy used by the application :P [14:47:52 CEST] <JEEB> of course in any case I would recommend making a bug report to the application's vendor [16:56:04 CEST] <logicWEB> just thought I'd throw this out there, I spent the last few days developing this: https://gist.github.com/logiclrd/287140934c12bed1fd4be75e8624c118 [16:56:11 CEST] <logicWEB> I wanted film grain that wasn't just straight HD pixels [16:56:25 CEST] <logicWEB> I'm now running an encode and we'll see what it looks like but my previews looked hopeful :-) [17:00:39 CEST] <logicWEB> the one thing I'm unsure about is aq-strength -- someone on a forum said high aq-strength is great for preserving grain, he said to use 1.8 or 1.9, but -tune grain uses aq-strength 0.5, where the default is 1.0? [17:00:53 CEST] <durandal_1707> logicWEB: you should avoid use of geq at all costs, it is _bad_ [17:02:04 CEST] <durandal_1707> geq=lum='255-lum(X,Y)':cb=128:cr=128 this can be done much faster with lut filter [17:02:56 CEST] <logicWEB> bad as in slow or bad as in doesn't actually do what you were expecting? [17:03:05 CEST] <durandal_1707> geq=red_expr=random(1)*256:green_expr=random(1)*256:blue_expr=random(1)*256 --- this one you could use real noise like /dev/random [17:03:12 CEST] <durandal_1707> it is very slow [17:03:49 CEST] <logicWEB> I'm running on Windows so I don't have /dev/random :-P [17:07:02 CEST] <durandal_1707> logicWEB: you do not like noise filter grain? [17:07:57 CEST] <logicWEB> is `noise=alls=100:allf=t+u` equivalent to that `geq` thing? [17:08:29 CEST] <logicWEB> I just changed my command line to that and it is, as expected, much faster that 3 per-pixel general expressions at twice the video resolution :-P [17:09:08 CEST] <logicWEB> okay I just tested with ffplay, it's not the same [17:09:13 CEST] <logicWEB> even with alls=100 the noise is very dark [17:12:41 CEST] <durandal_1707> that is because you are supposed to use it directly on video [17:15:25 CEST] <furq> logicWEB: also just use c0s and omit hue [17:18:43 CEST] <durandal_1707> ffmpeg -f lavfi -i color=gray:s=vga,noise=alls=100:allf=t,hue=s=0,deflate=threshold0=15,dilation=threshold0=10,eq=contrast=3,scale=320x240 [17:18:47 CEST] <JEEB> squirrel: /25 [17:18:51 CEST] <JEEB> asdf [17:19:15 CEST] <durandal_1707> use that if you really need big noise patches [17:23:26 CEST] <logicWEB> also looks like my `geq=lum='256-lum(X,Y)'` can be done with `negate` instead more quickly [17:24:03 CEST] <durandal_1707> negate is actually lut filter :-) [17:36:29 CEST] <logicWEB> just did some tests, I can't actually tell the difference between aq-strength 0.5 and aq-strength 1.9, maybe because the CRF is so high? I guess I'll just go with what -tune grain recommends? [17:37:11 CEST] <furq> it's doubtful you'll notice the difference between any x264 settings at crf 12 [17:37:31 CEST] <furq> you could probably run ultrafast and not notice [17:37:47 CEST] <logicWEB> except I'd notice the filesize :-P [17:38:20 CEST] <furq> you'd be surprised [17:39:04 CEST] <logicWEB> oh yeah? I mean, I compared veryfast with veryslow and got a file that was twice the size... [17:39:54 CEST] <logicWEB> also I was reading about it in a little bit of depth a week or two back and read that while the _intent_ is for the speeds to have virtually no effect on the quality in CRF mode, _in practice_ veryslow turns some features on that _in some rare cases_ will find better solutions for things and actually look better [17:40:09 CEST] <logicWEB> if there's even a tiny effect I'm willing to pay an extra day of CPU time :-P [17:53:15 CEST] <scottchiefbaker> What is the current status of the native AAC encoder? [17:53:29 CEST] <JEEB> it's pretty usable for LC-AAC [17:53:29 CEST] <scottchiefbaker> Is it still sub-par quality compared to the fdk one? [17:54:17 CEST] <JEEB> there are some specific use cases where it seems to handle some things worse but in general I would have no issues utilizing it given that the binaries can be re-distributed with GPL stuff like x264/5 enabled [17:54:39 CEST] <scottchiefbaker> JEEB: Ok good. [17:54:40 CEST] <scottchiefbaker> https://trac.ffmpeg.org/wiki/Encode/AAC#NativeFFmpegAACEncoder [17:54:57 CEST] <scottchiefbaker> Do you know anything about the VBR stuff? Is the VBR still a work-in-progress? [17:55:03 CEST] <scottchiefbaker> or should I just stick to CBR [17:55:20 CEST] <scottchiefbaker> "This VBR is experimental and likely to get even worse results than the CBR." [17:55:34 CEST] <JEEB> not sure when that line was written or by whom - and I haven't checked myself [17:55:56 CEST] <JEEB> so can't say anything one way or another [17:56:11 CEST] <JEEB> (esp. since I generally just set a bit rate like 96-192k) [17:56:27 CEST] <scottchiefbaker> a range? or a specific bitrate? [17:57:07 CEST] <JEEB> specific [17:57:13 CEST] <JEEB> something from that area [17:57:39 CEST] <JEEB> for local usage I usually go 192k since I don't generally re-encode unless I absolutely have to, and if I have to for local usage I have no real need to skimp on bits [20:50:52 CEST] <irwiss> i've been looking at https://ffmpeg.org/doxygen/4.1/hw__decode_8c_source.html and it seems to grab the hw device type from the cli args, ffmpeg returns all of cuda, dxva2, qsv, d3d11va "available" on this laptop but afaik intel integrated gpus can't use cuda? trying to open it seems to fail at av_hwdevice_ctx_create, so my question is; what's the s [20:50:52 CEST] <irwiss> trategy for detecting the correct type to open, a list sorted by priority and just trying until success or fallback to software? [20:53:01 CEST] <irwiss> also qsv seems to fail as well though it looks like it should work, is my hardware not compatible (Iris 540) or do i need the Intel Media SDK which https://trac.ffmpeg.org/wiki/Hardware/QuickSync warns not to install unless you need it, but i guess that folds into the question; how do i figure out which hw type out of the ones ffmpeg lists to open [20:53:46 CEST] <JEEB> you as an API or otherwise user should know what you should attempt on a specific piece of hardware. what is available is just what's available in the build of FFmpeg you have around [20:54:10 CEST] <JEEB> for decoding in Windows you generally want to use either dxva2 or d3d11va in any case [20:54:11 CEST] <irwiss> ah so "available" is just compile time "flags" [20:54:22 CEST] <JEEB> yes, they're available in the build [20:54:34 CEST] <JEEB> so when you attempt them the framework will attempt to utilize them [20:54:53 CEST] <JEEB> and then fail in case where you don't have the required stuff [20:55:19 CEST] <JEEB> but yea, on windows it's pretty simple since pretty much everything puts their hardware decoding into the windows APIs [20:55:27 CEST] <JEEB> thus dxva2 or d3d11va [20:57:04 CEST] <irwiss> i suppose if on windows i should try d3d11 then dxva2(which seems to be dx9) then fall back to software, can i just try opening them one by one until i succeed? or do i need to destroy the format/codec context [20:57:48 CEST] <JEEB> avformat context is separate anyways so no real need to close that [20:58:04 CEST] <JEEB> just keep the AVPackets around to feed the same stuff into the decoder [20:59:03 CEST] <JEEB> also I think your hw decoding context creation generally fails way before you start feeding it AVPackets I think? [20:59:20 CEST] <JEEB> (into the AVCodecContext [20:59:35 CEST] <irwiss> it looks like i'm not feeding packets yet by the time this fails, yep i was just wondering if trying to open hw context changes some internal ffmpeg state on those structures [21:00:10 CEST] <irwiss> guess i'll try and find out, hopefully it crashes before someone reports it doesn't work on their machine, thanks for the help! [21:00:11 CEST] <JEEB> avformat instance should be quite separate from the avcodec instance(s) you initiate [21:00:38 CEST] <JEEB> yea, unfortunately some hardware decoders have been less fun to deal with - but that could happen even without any mistake on your side :) [21:00:50 CEST] <JEEB> feed some funky bit stream to the hw decoder and receive bacon in the sense of BSoD [21:01:13 CEST] <JEEB> thankfully lately such drivers or hw decoders on PCs are starting to become more rare [21:01:17 CEST] <irwiss> yeah i'll try restarting just the codecs first, the startup sequence seems to be blazing fast [21:01:35 CEST] <irwiss> and fingers crossed no driver bugs with bsods :D [21:03:37 CEST] <JEEB> in mpv I think after X amount of failures with hwdec we fall back and create a swdec instance [21:04:20 CEST] <JEEB> also I've found that hwdecs are much more likely to bail out with a broken/unsupported bit stream [21:04:37 CEST] <JEEB> the FFmpeg swdec is trying quite hard :) [21:07:22 CEST] <JEEB> also the biggest difference between d3d11va and dxva2 seem to be indeed the newer/older back-end on the D3D side. which also means that with dxva2 you can get native D3D9 GPU surfaces, and with d3d11va you can get native GPU D3D11 surfaces [21:17:10 CEST] <irwiss> yeah my follow up task is trying to figure out if i can somehow supply my own d3d11 surface into the decoder, even with hw decoding but then juggling the buffers through system ram appears to be too slow for 4k videos on this laptop though vlc and mpv run the video just fine and so it looks like the roundtrip through system ram kills performance, s [21:17:10 CEST] <irwiss> earching the intertubes provides very little info on the subject but ffmpeg apis in the docs look promising [21:28:54 CEST] <__raven__> hi [21:30:08 CEST] <__raven__> processing images to video clips sometimes leads to an endless loop caused by "invalid data found..." due to negative duration. how to exit that? [00:00:00 CEST] --- Sat Apr 20 2019

1 0

ffmpeg-devel.log.20190418
by burek 19 Apr '19

19 Apr '19

[09:41:24 CEST] <cone-591> ffmpeg 03Sam John 07master:88325f4b34dd: Updated documentation for libaom encoder options. [13:41:18 CEST] <cone-915> ffmpeg 03Carl Eugen Hoyos 07master:09f8b21deb16: doc/encoders: Fix libvpx option name arnr-maxframes. [14:45:43 CEST] <cehoyos> Hi! vaapi works fine here, can anybody explain to me what I have to do to use qsv? I did install libmfx, what else is needed? Where do I get the necessary shared library? [14:47:00 CEST] <BtbN> iirc you need a special kernel and the Intel Media SDK for Linux from their Developer Resources [14:47:15 CEST] <BtbN> There isn't really any reason to use QSV on Linux [14:47:27 CEST] <cehoyos> So on Linux qsv never works without a patched kernel? So I don't want to use it, correct? [14:47:48 CEST] <BtbN> libva just works and offers almost the exact same features [14:47:59 CEST] <cehoyos> On Windows, qsv is the only hardware acceleration (with Intel) for encoding, right? [14:48:04 CEST] <BtbN> yes [14:48:12 CEST] <BtbN> Well, and d3d11va for decoding [14:48:22 CEST] <cehoyos> (And dxva2) [14:48:30 CEST] <BtbN> Same thing but kinda dead [14:48:35 CEST] <cehoyos> And do I need anything apart from libmfx on Windows? [14:48:43 CEST] <cehoyos> It worked when I tested it yesterday. [14:48:53 CEST] <cehoyos> Patching the kernel maybe? [14:48:56 CEST] <BtbN> Everything comes with the driver. If you use libmfx_dispatch, that's all you need. [14:49:05 CEST] <cehoyos> Ok, will test, thank you! [14:51:08 CEST] <BtbN> https://github.com/Intel-Media-SDK/MediaSDK also seems to be an official open source dispatcher library for both OS [14:52:54 CEST] <cehoyos> But several docs suggest to use libmfx [14:53:27 CEST] <cehoyos> Once you find out that the CMake.txt file is just a trap, it is not difficult to install (at least on Linux, I wonder how to autobuild on Windows) [14:58:21 CEST] <nevcairiel> i dont think the k ernel patches are needed anylonger on recent drivers [14:59:32 CEST] <BtbN> You crosscompile it from Linux or use MinGW I guess [14:59:59 CEST] <cehoyos> I use the subsystem now, works really great imo. [15:00:08 CEST] <nevcairiel> the official mediasdk from intel has a visual studio solution, you can also use that if you are not into mingw [15:00:13 CEST] <cehoyos> nevcairiel: So what is needed? [15:00:22 CEST] <cehoyos> On Linux, I mean. [15:00:37 CEST] <cehoyos> I don't have installed VS yet on this system [15:00:45 CEST] <cehoyos> Want to avoid it a little longer;-) [15:04:44 CEST] <nevcairiel> apparently qsv on linux is still as undocumented as ever [15:04:56 CEST] <nevcairiel> maybe jkqxz has some hints [15:05:39 CEST] <nevcairiel> a more portable encoding solution on linux is using vaapi [15:14:30 CEST] <JEEB> ya [15:14:43 CEST] <JEEB> thankfully intel added support for it as well, instead of trying to keep to qsv only [15:14:50 CEST] <JEEB> windows is the thing where you get sad [15:15:34 CEST] <BtbN> QSV works just fine on Windows though, as it comes with the driver you install anyway [15:15:43 CEST] <JEEB> yup [15:15:45 CEST] <BtbN> So the thin dispatcher is all you need [15:19:05 CEST] <cehoyos> Ok, will test [15:19:24 CEST] <cehoyos> Since there are many qsv reports that nobody ever tested, I would have liked to also install it on Linux though. [15:21:06 CEST] <BtbN> That chain of github stuff is what you need to figure out then [15:21:15 CEST] <cehoyos> I am building it right now. [15:21:24 CEST] <cehoyos> I wonder how to install: Won't it overwrite libmfx [15:21:26 CEST] <cehoyos> ? [15:21:41 CEST] <BtbN> I'd just install it somewhere in your homedir [15:21:50 CEST] <BtbN> never even giving it the change to install anything as root [15:24:11 CEST] <cehoyos> Ok, it loads the library now. [15:24:30 CEST] <cehoyos> It seems to be implemented so smart that it only works with additional parameters;-) [15:24:48 CEST] <wbs> nevcairiel: re patchwork, you're right with how it associates usernames; it stores a email->realname mapping, with the first sender name for each email address that it has gotten. and then, as you guessed, rewrites patches with a realname based on only the email address in the mail [15:31:38 CEST] <nevcairiel> yeah it seemed logical to do that [15:31:48 CEST] <nevcairiel> multiple people dont usually share mail addresses [15:32:08 CEST] <BtbN> So if you Typo your name the first time you send a patch, you're stuck with it forever? [15:32:57 CEST] <nevcairiel> presumably it updates the name [15:33:05 CEST] <nevcairiel> but there is still only one global record for every mail address [15:33:54 CEST] <nevcairiel> ultimately that rewrite script should really learn to insert From: lines into the pathc c ontent itself to fix it [15:34:18 CEST] <nevcairiel> .. and my spacebar is going crazy again [21:10:09 CEST] <wbs> BtbN: true. if you typo your name in the first patch, you need to ask the patchwork admin to reset it for you [22:04:25 CEST] <cone-741> ffmpeg 03Lou Logan 07master:d7e8e62797d8: doc/mailing-list-faq: add DMARC munging [23:37:04 CEST] <mkver> I just found out that I am affected by the mailing list name mangling. [23:37:45 CEST] <mkver> In fact, I am the author of the majority of the commits by "Oliver Collyer via ffmpeg-devel" on patchwork (https://patchwork.ffmpeg.org/project/ffmpeg/list/?submitter=776) [23:38:35 CEST] <mkver> But googlemail is just another name for gmail and plenty of people use gmail without issue. Does anyone have a clue why I could be different? [23:42:38 CEST] <durandal_1707> dunno, if pushed patch was wrongly attributed raise it on mailing list [23:49:57 CEST] <JEEB> we right now seem to have four mistakenly committed patches in the repo find'able with `git log |grep "via ffmpeg-devel"` [23:50:29 CEST] <durandal_1707> only four? what about Elvis ones? [23:50:42 CEST] <JEEB> this is specific to the "via ffmpeg-devel" stuff :P [23:56:30 CEST] <JEEB> mkver: it seems like those who committed ffmpeg-devel(a)ffmpeg.org e-mail addressed people at least downloaded the patches from the mailing list, and not patchwork. since the author name seems to be correct [23:57:03 CEST] <JEEB> so while patchwork doing not-so-nice things is bad, it doesn't seem to have been affected wrong name being put onto commits in the repo [23:59:13 CEST] <JEEB> or at least that's how it looks because there's no Oliver Collyer there, and just one occurence of each name [23:59:42 CEST] <mkver> Is the reason that e.g. Jamrial is not affected that he commits his stuff himself? [00:00:00 CEST] --- Fri Apr 19 2019

1 0

ffmpeg.log.20190418
by burek 19 Apr '19

19 Apr '19

[00:01:21 CEST] <nickster> ffserver command not found? Every solution I find just states to install ffmpeg but I already have that installed. [00:02:01 CEST] <another> ffserver has long been deprecated and recently dropped [00:03:40 CEST] <nickster> is it still possible to output to a website like with ffserver? [00:15:17 CEST] <another> output to a website? what do you mean by that [00:20:37 CEST] <nickster> ffserver gave one the option to throw up an http host or something, by the looks of it, and ffmpeg can stream right to it. [00:20:49 CEST] <nickster> It seems I am just going to have to work with udp/rtmp [00:21:34 CEST] <kepstin> for modern setups you normally want to serve up e.g. hls or dash for live streaming, and ffmpeg can output that directly to a directory, and any webserver works [00:21:55 CEST] <kepstin> or you can use something like the nginx-rtmp module, that's pretty popular [00:23:50 CEST] <another> or something like icecast [00:36:29 CEST] <friendofafriend> Yeah, icecast works great with MPEG-TS. [02:33:13 CEST] <analogical> I [02:34:51 CEST] <analogical> I've noticed something strange. Using ffpmpeg to download a files is much faster on Windows 10 and on Linux than it is on Windows 7 using the same computer. [02:35:26 CEST] <analogical> there shouldn't be any difference should there? [02:36:44 CEST] <another> hmm.. maybe the overhead of process spawning on windows? [02:37:47 CEST] <another> but that should apply to w10 too [06:09:35 CEST] <logicWEB> huh, curious. "... [a]; color=c=black:s=whatever:d=whatever [b]; [1][a] alphamerge [c]; [b][c] overlay" is almost twice as fast as just "... [a]; [1][a] blend=c0_mode=multiply" [07:09:05 CEST] <Mrjoker> what is better ? 720p or 1080i [07:21:16 CEST] <Buster> if deinterlacing is enabled then 1080i is better [07:23:18 CEST] <Mrjoker> buster can you even see the video if "deinterlacing" is not "enabled"? [07:25:16 CEST] <Buster> if there are a lot of dynamic scenes, it will look bad [08:27:33 CEST] <another> aaand he's back [09:16:45 CEST] <aleek> sup guys! ABR live streaming here! So I am able to generate a mp4 segment file with one frame - h264 key frame. I'd like to covert it to png/jpg/bmp - without ffmpeg. Code should be in c/c++. Any ideas? [09:17:07 CEST] <aleek> I have trouble finding any valuable information on the Internet ;( [09:21:20 CEST] <aleek> As I understand now, I have to dig into mp4's mdat segment, and treat it as h264 block [14:00:25 CEST] <kepstin> aleek: in order to turn that frame into a png/jpg/whatever, you're going to need an h264 decoder [14:01:02 CEST] <kepstin> aleek: probably the easiest h264 encoder to get is the one built in to ffmpeg... so why not just use ffmpeg? [14:02:15 CEST] <another> ffmpeg has no builtin avc encoder. it uses libx264 [14:03:03 CEST] <kepstin> er, typo. i meant decoder [14:03:04 CEST] <another> oh wait. i think you meant DEcoder [14:28:27 CEST] <aleek> so I can use x264 lib in this case [16:12:52 CEST] <Hello71> no. [16:13:04 CEST] <Hello71> well you can but it won't really help [16:14:37 CEST] <kepstin> aleek: x264 is an encoder only, it's not a decoder [18:49:54 CEST] <logicWEB> MrJoker: there's a trade-off to be made between the different options. 720p video will always "play nicely", with the caveat that you only have 720 scans of video. this is actually pretty good, really, but if you're frequently watching 1080p or 2160p content on a very large screen, your eye might be attuned enough to notice a slighty fuzziness about 720p video [18:50:04 CEST] <logicWEB> MrJoker: but... 1080i has some challenges in being played back well. an interlaced format presenting X frames per second is actually really 2X frames per second, but you're only getting half of each frame. so, with 30fps 1080i, you'll get a new picture 30 times per second, but each picture has (e.g.) all the even scans from one frame and the odd scans from another frame that comes after [18:50:20 CEST] <logicWEB> MrJoker: if you just play it like that, you'll see "combing" during motion, which, I mean, it's totally _possible_ to just put up with it and still enjoy the content, but it can be really annoying [18:50:31 CEST] <logicWEB> MrJoker: the other way to play 1080i content is to use a "deinterlacer", which splits that combined frame apart into the "parts of" the two original frames it was made up from. since each of these is only _half_ the original frame (even scans vs. odd scans), they aren't called "frames" per se, but "fields" of the combined frame in the 1080i source [18:50:59 CEST] <logicWEB> MrJoker: these split-out fields will then typically be played by using a heuristic to "guess" the pixels from the scans that aren't part of the field. so, basically, you're taking 540 scans and "guessing" the other 540 in between. the result is a frame with 1080 scans to put on your screen, but it doesn't actually have 1080 rows of detail. it's essentially 540 rows of detail [18:51:13 CEST] <logicWEB> MrJoker: so, you can think of 720p 30fps as just that, 720p 30fps, but 1080i 30fps as really more like 540p 60fps [18:51:35 CEST] <logicWEB> MrJoker: in my personal opinion, just going with 720p is a better experience than the artefacts that result from deinterlacing 1080i video [18:51:57 CEST] <logicWEB> MrJoker: but... this loss of resolution only happens vertically, so from left to right, a 720p video has 1280 pixels, while a 1080i video has 1920 pixels, so even though the 1080i video may be less sharp vertically, it can still be more sharp horizontally [18:52:16 CEST] <logicWEB> MrJoker: if you're trying to make a decision, I recommend trying it both ways and making a value judgment based on your own personal experience [18:53:59 CEST] <logicWEB> one thing I've seen is naively-encoded interlaced video where the frame is treated as progressive, and _that_ makes a mess because the combing is generally far too high frequency to fit into the bitrate constraints -- the result is that the fields interfere with each other, so even after they're split out by the deinterlacer, each one can suffer from a "ghost" of the other frame [18:54:21 CEST] <logicWEB> I don't have firsthand experience, but I'm pretty sure with proper settings, the encoder doesn't try to naively encode the alternating scans this way, and the issue _can_ be avoided [19:07:28 CEST] <irwiss> is it normal to get sporadic AVFrames where values for pts look like -9223372036854775808 1 90000 ? (pts first, the other 2 are time based num/denominator) do i just throw away such frames or i can somehow estimate pts in another way? [19:07:45 CEST] <irwiss> time base* [19:10:06 CEST] <JEEB> is it the NOPTS value? [19:10:26 CEST] <JEEB> AV_NOPTS_VALUE [19:12:58 CEST] <ChocolateArmpits> logicWEB, I find that with proper deinterlacing 1080i to be markedly better than 720p50/60. When having to key greenscreen footage the higher resolution really goes a mile. It's only really with poor deinterlacing that issues crop up. I personally advocate for QTGMC when quality is concerned. [19:15:15 CEST] <DHE> I've seen some mpegts streams where some packets have no timing data at all... [19:15:32 CEST] <JEEB> yes [19:15:45 CEST] <JEEB> for teletext f.ex. PTS is optional IIRC [19:16:04 CEST] <JEEB> so then all you can do is put it somewhere around pcr [19:21:02 CEST] <irwiss> NOPTS_VALUE seems to be 0x8000000000000000 which i guess is -1 signed? that weird -922.... number is sitting inside the frame->pts, and as far as i can see the stream does have pts usually, but some frames come with mangled one :( [19:25:30 CEST] <irwiss> yep looks to be no pts value for one specific frame [19:26:36 CEST] <DHE> JEEB: I've seen one feed where this is happening in the h264 video stream... :/ [19:27:09 CEST] <DHE> 0x8000000000000000 is the smallest possible integer. -1 has representation 0xFFFFFFFFFFFFFFFF [19:29:39 CEST] <irwiss> oh right, largest positive, but well the pts value on some frames appears to have the no_pts constant, while previous frame and the next appears to be fine, and time base is also preserved, guess i need to throw away the pts on frames like these if they come in a stream that normally provides pts [21:12:50 CEST] <kepstin> irwiss: consider using av_frame_get_best_effort_timestamp() which might give you something a bit more usable [21:13:55 CEST] <kepstin> er, let me double check that function name, i had some really old ffmpeg docs open [21:15:45 CEST] <irwiss> i think i used that before, but upgraded to 4.1 recently it claimed to be obsolete, unless i still need it [21:16:03 CEST] <kepstin> ah, just read the best_effort_timestamp directly from the frame struct now [21:45:25 CEST] <logicWEB> ChocolateArmpits: mm, yeah I guess it really make a big difference what you're using it for. but, it is really important that it be done right in the first place. here's a concrete example of it being done _really not right_: [21:45:27 CEST] <logicWEB> https://imgur.com/a/wGezjnG [21:46:01 CEST] <logicWEB> the first image comes off of the DVD of Pink Floyd's The Wall, that's exactly how the frame is on the DVD (except resized from 720x480 to 853x480 for aspect ratio) [21:46:24 CEST] <logicWEB> but the DVD is encoded as though it is progressive, and it just can't accurately represent the stark contrast from one scan to the next as it flips between the fields [21:46:46 CEST] <logicWEB> the second and third images are reconstructions of the fields (just using bicubic interpolation after extracting the relevant scans) [21:47:23 CEST] <ChocolateArmpits> I'd expect such a source to be telecined albeit with a field shift [21:51:21 CEST] <ChocolateArmpits> But while that's more common with improperly prepared DVD material, I don't really think high definition suffers from such mistakes simply because of more format options in terms of delivery. In my case having control over the video format makes for no problems in further interlace processing [00:00:00 CEST] --- Fri Apr 19 2019

1 0

ffmpeg-devel.log.20190417
by burek 18 Apr '19

18 Apr '19

[00:14:19 CEST] <cehoyos> durandal_1707: I want to but this is true for a long time... [00:25:50 CEST] <cone-514> ffmpeg 03James Almer 07master:cfe220332a8f: avcodec/cbs_av1: add support for Scalability Metadata [01:48:09 CEST] <cone-514> ffmpeg 03James Almer 07master:5006dcdf9af1: avcodec/cbs: add helper functions and macros to read and write signed values [01:48:10 CEST] <cone-514> ffmpeg 03James Almer 07master:3dc6adf326c8: avcodec/cbs_h2645: add helper macros for signed values [01:48:11 CEST] <cone-514> ffmpeg 03James Almer 07master:9bf520d04d61: avcodec/cbs_h264: fix storage type for time_offset in Pic Timing SEI [01:48:12 CEST] <cone-514> ffmpeg 03James Almer 07master:137c0fcad151: avcodec/cbs_h265: fix storage type for time_offset_value in Time Code SEI [01:48:13 CEST] <cone-514> ffmpeg 03James Almer 07master:e2f766e13f03: avcodec/cbs_av1: use the new signed value read/write functions [09:08:08 CEST] <seastar> hello, when I configure ffmpeg with --enable-libopenh264 parameter on windows using either msys2 or mysys, I get the following error: ERROR: openh264 not found using pkg-config [09:08:23 CEST] <seastar> how can I configure ffmpeg with --enable-libopenh264 parameter on msys2? [09:10:31 CEST] <rcombs> jkqxz: think you can get someone to take a look at this? https://github.com/intel/libva/pull/266 [09:15:52 CEST] <mkver> @seastar: You can take a look at the "media autobuild suite" https://github.com/jb-alvarado/media-autobuild_suite (in paticular build/media-suite_compile.sh) to see how they do it there. [09:18:07 CEST] <seastar> is the only solution media autobuild suite? [09:19:42 CEST] <mkver> Of course not. It's just a suggestion. [09:22:07 CEST] <seastar> I consider to use that solution but I am curious about any other solution [10:11:59 CEST] <cone-972> ffmpeg 03Steven Liu 07master:2a50f1d9e414: tests/fate: add fate-hls-segment-size for hls_segment_size test [16:39:14 CEST] <cone-580> ffmpeg 03Paul B Mahol 07master:a0559fcd81f4: avfilter/af_sidechaincompress: implement mode option [20:12:14 CEST] <mkver> @jkqxz: In ff_cbs_alloc_unit_content the opaque pointer for the free function is set equal to the CodedBitstreamContext. But in the actual free functions the (unused) opaque pointer is called "unit" (which would also make more sense to me). [23:43:12 CEST] <cone-858> ffmpeg 03Paul B Mahol 07master:8a3ed5a31364: avfilter/af_agate: implement mode option [00:00:00 CEST] --- Thu Apr 18 2019

1 0

ffmpeg.log.20190417
by burek 18 Apr '19

18 Apr '19

[00:25:35 CEST] <cehoyos> jamie_1: Combining --enable-shared with --static most likely makes no sense, what are you trying to do? [01:12:11 CEST] <TheSashmo> @kepstin I was thinking about that, but had no clue where to start..... any direction? google is coming up short on that search... LOLOL [03:30:14 CEST] <xyz111> Hi Guys, I wanted to validate this idea with people more knowledgeable than me: I want to create a little video editor on linux, which piggybacks on ffmpeg. Basically, the front end would be a shell issuing commands to ffmpeg. I want the software to be able to cut videos, fade videos, extract audio etc etc. Most importantly, I want to be able to see the composited results in realtime. Would all this be viable, or am I oversimplifying the proble [03:32:54 CEST] <klaxa> i think most open-source non-linear video editors already use ffmpeg for that [03:33:02 CEST] <klaxa> those that don't probably use gstreamer [03:35:59 CEST] <klaxa> i don't think you can offload real-time compositing very well through the cli though [03:46:03 CEST] <xyz111> thanks klaxa, what is usually used for realtime compositing? [03:48:03 CEST] <klaxa> hmm, not sure, opengl? i might be way off, but as i understand it, a non-linear video editor would just use ffmpeg for decoding/demuxing and encoding/muxing, so you'd have to write your timeline which holds all the frames yourself [03:48:13 CEST] <klaxa> that would then be displayed with whatever GUI framework you are using [03:50:45 CEST] <klaxa> it may be a good idea to look at other software that does similar things? kdenlive and pitivi come to mind [03:51:58 CEST] <klaxa> https://en.wikipedia.org/wiki/List_of_video_editing_software#Free_and_open-… might also be a good point to start looking? [04:18:09 CEST] <klaxa> it feels like after watching wataten my life is now complete and i can die in peace [04:34:05 CEST] <klaxa> oh shit, wrong channel [04:54:33 CEST] <xyz111> thanks again klaxa - I will investigate further! [05:05:07 CEST] <nickster> dealing with a.... weird issue here [05:05:15 CEST] <nickster> https://youtu.be/kiRLVcEaw74 [05:05:33 CEST] <nickster> using x11grab and trying to use that as a webcam with v4l2loopback [05:06:17 CEST] <nickster> > ffmpeg -f alsa -i pulse -f x11grab -r 15 -s 1280x720 -i :0.0+0,0 -f v4l2 /dev/video0 [05:06:38 CEST] <nickster> only thing i could get to recognize the video is obs [05:06:52 CEST] <nickster> it records to file fine so im thinking this may be an v4l2 issue [08:48:40 CEST] <ossifrage> Does ffmpeg support a simple ycrcb file format (like pnm) that has embedded image dimension data? [08:52:44 CEST] <JEEB> ossifrage: y4m and NUT are usually utilized for raw video without or with timestamps [08:52:52 CEST] <JEEB> y4m is a relatively simple, constant frame rate thing [08:54:48 CEST] <ossifrage> JEEB, that would work, thanks [08:58:35 CEST] <ossifrage> JEEB I never managed to get my DTS timestamps to work right when trying to generate fmp4, ended up punting and switching to rtsp until I can come back and look at it [09:05:28 CEST] <seastar> hello, when I configure ffmpeg with --enable-libopenh264 parameter on windows using either msys2 or mysys, I get the following error: ERROR: openh264 not found using pkg-config [09:06:07 CEST] <seastar> how can I configure ffmpeg with --enable-libopenh264 parameter on msys2? [09:06:28 CEST] <seastar> could anybody please help me? [09:27:11 CEST] <JEEB> seastar: look at ffbuild/config.log ; it should show you what failed in the configure check [09:38:54 CEST] <seastar> gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1 -D__printf__=__gnu_printf__ -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -std=c11 -fomit-frame-pointer -ID:/msys64/mingw64/include -LD:/msys64/mingw64/lib -c -o /tmp/ffconf.mFXThrca/test.o /tmp/ffconf.mFXThrca/test.c [09:38:54 CEST] <seastar> D:/msys64/tmp/ffconf.mFXThrca/test.c:1:10: fatal error: wels/codec_api.h: No such file or directory [09:38:54 CEST] <seastar> #include <wels/codec_api.h> [09:38:54 CEST] <seastar> ^~~~~~~~~~~~~~~~~~ [09:38:54 CEST] <seastar> compilation terminated. [09:38:56 CEST] <seastar> ERROR: openh264 not found using pkg-config [09:40:46 CEST] <seastar> JEEB: config.log file contains error lines above [09:42:36 CEST] <JEEB> either you're lacking a header, the pkg-config pc file doesn't contain the correct location (or you haven't defined a sysroot) or openh264 changed their API [09:45:28 CEST] <seastar> I copied the pc file to another location so that pkg-config command can show location of the library, but I still get the same message [09:46:22 CEST] <seastar> should I define sysroot on msys2? how can I verify it? [09:48:23 CEST] <JEEB> changing the location of the pc file does not change the result [09:48:58 CEST] <JEEB> if you defined a custom --prefix when building openh264 that should have added the needed -I/-L [09:49:01 CEST] <JEEB> into the pc file [09:49:02 CEST] <JEEB> OR [09:49:14 CEST] <JEEB> if you are utilizing a reusable sysroot [09:49:22 CEST] <JEEB> then you will have to tell pkg-config about it [09:49:23 CEST] <JEEB> :P [09:49:37 CEST] <JEEB> which is PKG_CONFIG_SYSROOT_DIR as an env var [09:49:44 CEST] <JEEB> if I recall correctly [09:56:01 CEST] <seastar> openh264 doesn't have configure file, and I didn't change prefix line of its makefile. [09:56:21 CEST] <seastar> PKG_CONFIG_SYSROOT_DIR variable is undefined [09:58:06 CEST] <seastar> I also tried to change prefix line, and to use -L and -I parameters to configure ffmpeg, but the result hasn't changed [09:59:24 CEST] <seastar> I mean I built openh264 with another prefix to provide with it to ffmpeg using -I and -L parameters [09:59:39 CEST] <seastar> but nothing has changed. I got the same error [10:06:48 CEST] <logicWEB> I'm trying to encode video with film grain in it. I know the source video is pristine, because it's the output of a timeline in kdenlive. kdenlive does its video rendering using the MLT framework, which, as I understand it, ultimately wraps ffmpeg and the related encoding libraries at its core. so, I have this video to which I am _adding film grain_ using a kdenlive filter, and I'm trying to produce an output file -- at any cost -- t [10:07:40 CEST] <logicWEB> based on tweaking after reading various forum posts, I am currently using settings: preset=veryslow g=120 crf=1 tune=film aq-strength=1.8 [10:08:52 CEST] <logicWEB> this is _pretty good_, but it's not perfect -- the film grain does sort of a global shift about every 5-7 frames, and otherwise is kept the same frame-to-frame with a little bit of flickering [10:09:22 CEST] <logicWEB> does anyone have any advice on how to tweak the settings in order to actually preserve the unique grain in every frame? framerate is ntsc-film in case that matters [10:09:55 CEST] <logicWEB> I was wondering whether it might be an option to disable P and B frames entirely? [10:13:11 CEST] <logicWEB> complicating matters is that I'm not sure if my video encoder options are being passed through to the underlying encoder by MLT -- I tried "keyint=1 weightp=0 weightb=0 bframes=0 scenecut=0 no-open-gop=1" and it didn't seem to make a difference [10:13:32 CEST] <logicWEB> (that is the syntax MLT uses for other options) [10:15:28 CEST] <redliondj> hi there does any1 know why am I getting the following error ? [10:15:32 CEST] <redliondj> Error while decoding stream #1:0: Invalid data found when processing input [10:16:18 CEST] <logicWEB> okay another complicating factor is that the Grain filter in kdenlive might not actually be producing unique grain per frame, I just jacked up the grain amount so I could see it easily and stepped through the early video frame by frame and it doesn't appear to be updating every frame, so that certainly doesn't help! :-/ [10:18:01 CEST] <logicWEB> so maybe the video encoding is doing exactly what I want and the source isn't what I expect, guess I need to go sort this out with the kdenlive folks first :-P [10:21:55 CEST] <redliondj> https://pastebin.com/PsR5KcZ9 [10:22:14 CEST] <redliondj> I am tring to add a turkish subtitle [10:22:38 CEST] <redliondj> I tried to change my locale settings bw exporting LC_ALL and LANG [14:59:08 CEST] <Zgrokl> I currently save a stream from dvb and sometime the sound got desync with video with the error : Non-monotonous DTS in output stream 0:0; [14:59:24 CEST] <Zgrokl> since it's random it means that it source that is fucked up or not ? [15:09:10 CEST] <JEEB> Zgrokl: use something like multicat to dump the input and then inspect problematic points with DVB Inspector or so. [15:09:39 CEST] <JEEB> multicat has examples in its repo on how to set up a window of X hours or whatever for dumping [17:37:09 CEST] <redliondj> hi I am tring to add a turkish subtitle but I get following issue [17:37:11 CEST] <redliondj> https://pastebin.com/PsR5KcZ9 [17:47:40 CEST] <nickster> oh hey i got a legit ffmpeg question now [17:47:47 CEST] <nickster> fixed the weird v4l2 issue though [17:48:03 CEST] <furq> redliondj: did you try using -sub_charenc [17:48:12 CEST] <nickster> anyway, what about recording input from certain applications as a "virtual" microphone? [17:48:26 CEST] <nickster> i know how to record certain applications [17:48:54 CEST] <furq> that's more of an alsa/pulse question [17:48:58 CEST] <nickster> but i cant find out how to make a virtual microphone with it [17:49:14 CEST] <nickster> https://trac.ffmpeg.org/wiki/Capture/ALSA [17:49:42 CEST] <nickster> i can get the alsa / pulse stuff but just as there is a /dev/video0 is there a /dev/audio0 or smth? [17:49:45 CEST] <nickster> or am i just naive [17:50:01 CEST] <kepstin> with alsa, you can set up an aloop device and have your application output audio to that rather than to speakers (or maybe both, if you set up your alsa config appropriately) [17:50:14 CEST] <kepstin> with pulseaudio, easiest is to capture from the output monitor device [17:50:30 CEST] <kepstin> (that's not a single application, rather it's all the audio being output by your computer) [17:50:38 CEST] <nickster> ye I looked into that but the issue is because this machine is a virtual machine and I haven't gotten any virtualized audio devices to work. [17:50:54 CEST] <kepstin> aloop should work for that use case [17:51:08 CEST] <nickster> It can record audio to file no problem, but I can't configure a loopback with any tested configuration so far. [17:51:26 CEST] <furq> there's a pulseaudio loopback module that should do what you want [17:52:12 CEST] <kepstin> on a virtual machine with no sound card, pulseaudio should start with a dummy device by default, and you can just record off the monitor of that [17:54:13 CEST] <furq> 16:49:42 ( nickster) i can get the alsa / pulse stuff but just as there is a /dev/video0 is there a /dev/audio0 or smth? [17:54:17 CEST] <furq> there was back in the oss days [17:54:24 CEST] <furq> i guess this is still a thing on freebsd [17:54:46 CEST] <furq> there are alsa compat modules that reinstate /dev/dsp etc but i don't think they'll help you much [17:57:00 CEST] <nickster> my goal is to get hangouts to recognize the loopback [17:57:10 CEST] <nickster> its not behaving thoough. [18:00:06 CEST] <nickster> most all things im finding say to edit the recording device and enable loopback [18:00:24 CEST] <nickster> but that isnt an option for me [18:00:31 CEST] <nickster> i may ask alsa/pulse [18:00:34 CEST] <nickster> thanks for the help though [18:14:11 CEST] <redliondj> furq I looked in the documentation but could not find any ifno on the option [18:14:58 CEST] <redliondj> I remember ahving seen something like this when using special filters that "hardburns" the sub [18:19:44 CEST] <furq> redliondj: -sub_charenc ISO8859-9 -i foo.srt [18:19:49 CEST] <furq> or whatever the subtitle encoding is [18:22:38 CEST] <redliondj> ok furq [18:25:29 CEST] <redliondj> thx that seems to have done the trick [20:16:48 CEST] <friendofafriend> ls -l [20:17:00 CEST] <friendofafriend> Oh no. Is the trac.ffmpeg.org site down? [20:17:40 CEST] <ChocolateArmpits> doesn't work for me as well [20:18:33 CEST] <friendofafriend> I never realized how totally helpless I am without it. [20:19:02 CEST] <zeromind> just slow for me, takes ~1min to load per page [20:19:27 CEST] <ChocolateArmpits> friendofafriend, try web.archive.org for cached pages [20:19:58 CEST] <friendofafriend> Yeah, no results. https://web.archive.org/web/*/http://trac.ffmpeg.org/wiki/Encode/H.264 [20:21:20 CEST] <ChocolateArmpits> try https :) [20:21:26 CEST] <ChocolateArmpits> Or http://archive.fo/epBXJ [20:21:55 CEST] <ChocolateArmpits> through web archive should provide links to other pages as well [20:22:07 CEST] <friendofafriend> Oh sorry, I thought it was just HTTPS-Everywhere giving me that address. http works great. Thank you so much. [20:22:44 CEST] <friendofafriend> Is there an archive of trac somewhere? I'm referencing it enough that I should probably have it offline. [20:22:55 CEST] <furq> it's back up now [20:23:12 CEST] <furq> it was actually timing out for a minute there [20:23:36 CEST] <friendofafriend> I don't know, I'm still heckuva long load times. [20:24:08 CEST] <furq> maybe not then [20:36:59 CEST] <friendofafriend> Maybe we could pass around a mirror of trac in a torrent. [20:39:17 CEST] <furq> i'm sure it's backed up [20:42:17 CEST] <friendofafriend> I just don't want to mirror it without permission. I know that's not very nice. :) [22:28:00 CEST] <budRich> hello, something is acting up when im trying to make a screenrecording, when my mic is turned on.. never had problems with this before. error code: [22:28:24 CEST] <budRich> ALSA lib pcm_dsnoop.c:638:(snd_pcm_dsnoop_open) unable to open slave [22:28:39 CEST] <budRich> [alsa @ 0x5582d7ad1c00] cannot open audio device default (Device or resource busy) [22:29:22 CEST] <budRich> command used to start recroding: ffmpeg -y -f x11grab -s 1600x900 -i :0.0+0,0 -f alsa -i default -c:v libx264 -preset ultrafast -crf 0 -acodec mp3 [22:29:56 CEST] <budRich> works when i disable the microphone in pavucontrol.. [22:30:32 CEST] <budRich> it's like the mic is already being used.. can i see what's using it somehow? [22:30:47 CEST] <another> try using pulse instead of alsa [22:31:17 CEST] <budRich> another: just replace -f alsa with -f pulse? [22:33:23 CEST] <budRich> another, thanks that worked, but still strange, i have been using the same command for years never any issues, i get the feeling, something is not right with my where my microphone.. [23:56:46 CEST] <friendofafriend> Hello. I've got this MPEG-TS stream from a live source, works great but over time there's more and more delay. Is there a way to reduce the amount of delay clients experience after watching for a long time? [00:00:00 CEST] --- Thu Apr 18 2019

1 0

ffmpeg-devel.log.20190416
by burek 17 Apr '19

17 Apr '19

[00:44:14 CEST] <cone-842> ffmpeg 03Carl Eugen Hoyos 07master:c3aa4844f393: lavfi/fspp: Remove two unused macros. [02:03:05 CEST] <cehoyos> JEEB: Please push if the patch is ok. [02:52:23 CEST] <cone-842> ffmpeg 03fumoboy007 07master:036b4b0f8593: avcodec/videotoolbox: add support for 10bit pixel format [05:25:08 CEST] <unlord> I'm sure you all saw https://www.reddit.com/r/AV1/comments/bdmk6h/32bit_ffmpeg_and_libaom_curren… [08:37:19 CEST] <JEEB> unlord: interesting if only 32bit is borked and not from libaom's side. funny enough when I used avisynth more getting the extra speed from 64bit encoding was worth it so I would utilize avs2pipe and friends to get the video data into a 64bit encoder process :) [11:40:16 CEST] <nevcairiel> I really don't see how that could be our crash [11:40:39 CEST] <nevcairiel> It reads like all of those people use some pre-built third-party binary [11:40:52 CEST] <cehoyos> which crash? [11:40:58 CEST] <nevcairiel> so presumably what really changed is the libaom version [11:41:12 CEST] <nevcairiel> https://www.reddit.com/r/AV1/comments/bdmk6h/32bit_ffmpeg_and_libaom_curren… https://trac.ffmpeg.org/ticket/7844 [11:41:33 CEST] <cehoyos> You could build locally and test... [11:42:01 CEST] <nevcairiel> I could, but that would go against my prime directive of being lazy! [11:42:51 CEST] <nevcairiel> mostly because i dont have libaom handy anyway [11:46:58 CEST] <cehoyos> There is no repo? [11:47:00 CEST] <cehoyos> ;-) [12:06:23 CEST] <nevcairiel> crashes in some simd function in libaom, so unless they changed their padding or alignment requirements without a major bump and didn't tell anyone, its likely their bug [12:15:20 CEST] <JEEB> nevcairiel: it's probably zeraenoe's binaries [12:16:17 CEST] <nevcairiel> crashes in my build as well [12:17:27 CEST] <JEEB> yea, that's how you were able to get the SIMD function [12:17:54 CEST] <nevcairiel> i just dont see how any change in ffmpeg might've caused this to start [12:18:04 CEST] <nevcairiel> especially between 4.1.0 and 4.1.1 as is claimed [12:18:04 CEST] <JEEB> yea [12:19:41 CEST] Action: JEEB just started getting angry comments about FFmpeg sucking with regards to SVT-AV1 and AOM crashes too, for some reason [12:19:48 CEST] <JEEB> I guess AV1 is popular today? :P [12:20:10 CEST] <JEEB> and getting more information from these people isn't exactly the simplest of things always [12:20:30 CEST] <nevcairiel> of course [12:20:37 CEST] <nevcairiel> oh well back to writing this config parser [12:20:48 CEST] <nevcairiel> i'm still wondering if i should bother to l earn some parser generator or just do it manually [12:27:45 CEST] <j-b> config parser? [12:29:15 CEST] <nevcairiel> basically an advanced ini file [12:29:45 CEST] <cone-857> ffmpeg 03Karthick J 07master:bcde9ec02056: avformat/dashenc: Disable streaming for webm output [12:30:37 CEST] <nevcairiel> meh i'll just do it manually, it only has like 5 syntax elements [12:59:13 CEST] <cehoyos> How do I build 32-bit libaom? [12:59:45 CEST] <cehoyos> JEEB: Is there a reason you did not push 2/2? [13:05:06 CEST] <JEEB> cehoyos: still needs a bump I think [13:05:15 CEST] <JEEB> and I was going to talk with the author [13:07:41 CEST] <cehoyos> A bump? [13:07:41 CEST] <JEEB> also it was late and I hadn't looked as much into the second patch :P [13:07:47 CEST] <JEEB> cehoyos: it adds a new av_* function [13:07:56 CEST] <cehoyos> Of course. [13:07:57 CEST] <JEEB> as far as I can see [13:07:59 CEST] <JEEB> :/ [13:08:05 CEST] <cehoyos> (In that case, I mean) [13:08:09 CEST] <JEEB> yea [13:08:30 CEST] <cehoyos> To answer my question: cmake -DCMAKE_CXX_FLAGS=-m32 -DCMAKE_C_FLAGS=-m32 ../aom [13:08:46 CEST] <JEEB> yes, with multiarch that should work :) [13:09:02 CEST] <JEEB> otherwise you have to either define a lot of stuff or a full cross-file [13:09:18 CEST] Action: JEEB kind of dislikes build systems with cross-files because mostly you just need --cross-prefix or something like it [13:09:37 CEST] <JEEB> of course if you need to override more stuff a separate file does start making sense [13:09:49 CEST] <nevcairiel> yeah the cross-file concept is weird, rather stick to cross-prefix, thats how most stuff works anyway [13:10:01 CEST] <cehoyos> I do not consider compiling x86_32 Linux on x86_64 Linux cross-compiling. [13:10:14 CEST] <JEEB> well yes, esp. with multiarch [13:10:32 CEST] <JEEB> I think my comments were more towards general cross-compilation with cmake/meson [13:10:45 CEST] <cehoyos> I still hope I can avoid this. [13:10:52 CEST] <cehoyos> (I won't test on Windows) [14:02:13 CEST] <cehoyos> Has anybody ever installed libmfx? [14:02:33 CEST] <cehoyos> FFmpeg and the github source disagree about the header location: I just wonder why this was never reported... [14:03:59 CEST] <BtbN> You are supposed to use mfx_dispatch [14:04:11 CEST] <cehoyos> And have you tried it? [14:04:19 CEST] <BtbN> On Windows on Cygwin, yes. Worked fine. [14:04:39 CEST] <cehoyos> Where did it install the header files? [14:04:50 CEST] <BtbN> No idea anymore [14:05:19 CEST] <cehoyos> The reason I ask is that the header files cannot be found by FFmpeg where the installer puts them. [14:05:30 CEST] <BtbN> Looking at the Makefile.am, they'd end up in /usr/include/mfx/*.h [14:05:54 CEST] <cehoyos> They ended up in /usr/include here [14:05:57 CEST] <cehoyos> (No mfx) [14:06:18 CEST] <BtbN> When you installed https://github.com/lu-zero/mfx_dispatch via autotools? [14:06:30 CEST] <cehoyos> via autotools? [14:06:38 CEST] <cehoyos> How do I install via autotools? [14:06:42 CEST] <cehoyos> Aaaaaaaaaaa [14:06:47 CEST] <BtbN> Yeah, it also supported cmake, which I didn't test [14:07:03 CEST] <cehoyos> The cmake is just for deception, well it hit me;-)) [14:07:20 CEST] <cehoyos> But that's really smart, I couldn't guess! [14:07:37 CEST] <nevcairiel> the cmake is vastly out of date [14:08:43 CEST] <nevcairiel> Personally on Windows I use the official intel variant though, since they fixed a bunch of stuff related to their new driver versions and finding the runtime libraries [14:09:00 CEST] <cehoyos> As said, this is a smart deception, not something that can be immediately understood [14:09:23 CEST] <BtbN> cmake and autotools supposedly both work (and haven't been touched in years) [14:09:37 CEST] <cehoyos> I don't think that is true [14:09:49 CEST] <nevcairiel> cmake doesnt work properly [14:10:11 CEST] <nevcairiel> at least the .pc.cmake is wrong in some ways [14:10:44 CEST] <nevcairiel> i had to deal with that only weeks ago [14:10:52 CEST] <nevcairiel> when i tried to figure out why the new drivers didnt work anymore [14:10:58 CEST] <nevcairiel> and ended up building with t he official one instead [14:11:31 CEST] <nevcairiel> i tried to copy its cmake thing to the official one so i could build it with gcc, so i noticed it needed some work =p [14:15:01 CEST] <cehoyos> Why is mfx not auto-detected? [14:22:10 CEST] <cone-857> ffmpeg 03Carl Eugen Hoyos 07master:1e8475b507ee: lavc/libaomenc: Mark a potentially unused variable as av_unused. [14:29:39 CEST] <cone-857> ffmpeg 03Carl Eugen Hoyos 07master:5ba769214f91: lavu/hwcontext_qsv: Mark a pointer as const. [14:32:10 CEST] <thardin> libmxf or libMXF ? [14:32:19 CEST] <nevcairiel> the intel one [14:32:25 CEST] <nevcairiel> mfx [14:36:04 CEST] <thardin> oh joy, another library called exactly "libmxf" [14:36:14 CEST] <JEEB> yea [14:36:15 CEST] <JEEB> :/ [14:36:19 CEST] <JEEB> unfortunate [14:37:00 CEST] <nevcairiel> mfx [14:37:04 CEST] Last message repeated 1 time(s). [14:37:04 CEST] <nevcairiel> :P [14:37:30 CEST] <nevcairiel> its a different order! [14:37:37 CEST] <nevcairiel> its not like its new though [14:37:43 CEST] <JEEB> ah right :D [14:37:43 CEST] <nevcairiel> it probably exists for 8 years by now [14:37:48 CEST] <JEEB> also yes, the library is old [14:37:52 CEST] <thardin> aha [14:37:57 CEST] <thardin> lol [14:38:02 CEST] <JEEB> (it shows that I deffo didn't get enough sleep) [14:38:22 CEST] <nevcairiel> i never get enough sleep, you get used to i t [14:38:26 CEST] <cehoyos> nevcairiel: gcc claims here that strftime() does not understand %s on mingw either [14:38:35 CEST] <nevcairiel> this is true [14:38:39 CEST] <cehoyos> hlsenc.c:1693 [14:38:40 CEST] <nevcairiel> because thats not gccs doing [14:38:51 CEST] <nevcairiel> gcc on mings compiles against the MS crt [14:38:54 CEST] <nevcairiel> mingw* [14:39:10 CEST] <cehoyos> Then why do we use %z on mingw? [14:39:29 CEST] <cehoyos> Didn't you block my patch changing this? Or do I misremember? [14:39:32 CEST] <nevcairiel> mingw likes to override some functions with its own variants [14:39:43 CEST] <nevcairiel> for better gcc-style compat [14:39:50 CEST] <nevcairiel> but not strftime afaik [14:40:25 CEST] <cehoyos> So what is the solution? [14:40:49 CEST] <nevcairiel> configure should really test this instead of some runtime test being performed [14:41:02 CEST] <nevcairiel> i recommended that to the author at the ti me, but apparently that never came as a follow up [14:41:16 CEST] <cehoyos> How can configure test this? [14:41:27 CEST] <nevcairiel> make a binary, execut it, see what happens [14:41:34 CEST] <cehoyos> When cross-compiling? [14:41:38 CEST] <cehoyos> As I do atm [14:42:38 CEST] <nevcairiel> we could also just adjust that guard there to account for mingw [14:42:42 CEST] <nevcairiel> or generally all windows in that case [14:43:06 CEST] <cehoyos> What is our preferred check for Windows in c files? [14:43:46 CEST] <nevcairiel> #ifdef _WIN32 typically, but you can't use that inline like the existing check [14:57:14 CEST] <cehoyos> How does "CYGWIN" relate here? Can CYGWIN target MSVCRT? [14:57:32 CEST] <BtbN> no, Cygwin is Linux for most things ffmpeg cares about [14:58:08 CEST] <BtbN> _WIN32 is also not defined on Cygwin [15:09:06 CEST] <cehoyos> nevcairiel: How do you know where libaom crashed when encoding on win32? [15:09:24 CEST] <cehoyos> I can reproduce the crash with wine but I don't get very useful debug information... [15:10:08 CEST] <nevcairiel> i just ran it through gdb and it showed that [15:11:25 CEST] <cehoyos> Found gdb in the packager... [20:56:49 CEST] <faLUCE> JEEB and others: (about patching when a patch includes also a modification to a file which is frequently changed, like configure) before format-patch, should I rebase my-dev-branch against local master or against origin/master ? [20:57:42 CEST] <nevcairiel> against the central master of course, thats what the patch has to apply against [20:59:12 CEST] <JEEB> faLUCE: the end result is what nevcairiel says. the branch you rebase against can be local or remote branch, but main thing is that you're rebasing against current central master :P [20:59:48 CEST] <faLUCE> nevcairiel JEEB: ok, then should I call: "git format-patch -o patches origin/master..HEAD" or is the last token unnecessary given that I already rebased? [21:32:24 CEST] <mkver> AVPacket's duration field says that a duration of 0 means "unknown". But how does one distinguish the case of an unknown duration (which probably means "show until the next subtitle (of this stream) is to be displayed) from a zero duration subtitle (like a comment that is not to be displayed at all)? [21:36:04 CEST] <JEEB> usually you decode the subtitle and then you get an AVSubtitle [21:36:35 CEST] <JEEB> which has its own fields [21:37:36 CEST] <mkver> I am more interested in the case of (de)muxing. [21:38:02 CEST] <JEEB> then you're usually at the behest of your input container [21:38:19 CEST] <JEEB> for example MPEG-TS just has zero [21:38:27 CEST] <JEEB> for pkt_duration [21:38:52 CEST] <mkver> But how should the demuxer set the duration field for a subtitle with an explicit duration of zero (as opposed to an unknown length duration)? [21:39:22 CEST] <nevcairiel> Also Set it to zero, not like you have options [21:39:42 CEST] <mkver> If the demuxer can't signal this, the information is lost and whatever works with this data will not be able to handle it properly. [21:40:16 CEST] <mkver> Duration is signed, so one could signal it by using a negative value or so. [21:40:20 CEST] <durandal_1707> cehoyos: you gonna add new codecs to mplayer svn code? [21:42:03 CEST] <JEEB> mkver: yea it's unfortunate - for AVSubtitles I noticed -1/UINT32_MAX is what got utilized [21:42:27 CEST] <nevcairiel> Is there really an actual semantic difference between unknown and no duration from a demuxer perspective? The decoder will figure out if there is a subtitle to show forever, or some other content [21:44:06 CEST] <nevcairiel> Ultimately both mean "I have no duration' [21:45:13 CEST] <mkver> Duration zero can also mean "I should not be shown at all." This way one could add comments. [21:46:17 CEST] <JEEB> yea, that's really format specific [21:46:21 CEST] <JEEB> unfortunately [21:46:54 CEST] <JEEB> if you then decode that and it actually has a subtitle that is supposed to be shown or not then that should be signaled in the decoded AVSubtitle [21:47:15 CEST] <JEEB> what formats are you specifically talking about btw, for reference? [21:48:34 CEST] <nevcairiel> The decoder will know that [21:48:40 CEST] <mkver> Matroska. It can distinguish between duration zero (for comments) and unknown duration. [21:48:40 CEST] <nevcairiel> Does the container have to? [21:50:17 CEST] <mkver> How should the decoder be able to find out when a subtitle is not to be shown? [21:50:40 CEST] <mkver> If said information is only stored at the container level and can't be forwarded? [21:50:45 CEST] <nevcairiel> The codec would have a way to signal comments of course [21:51:01 CEST] <JEEB> like ASS, which most likely are what have comment lines [21:51:10 CEST] <JEEB> the actual line contents contain a comment [21:51:36 CEST] <JEEB> also I'm trying to check what the matroska spec exactly says just out of interest [21:51:36 CEST] <nevcairiel> Trying to rely on duration 0 not being shown instead of shown until next seems very specific and likely to break in 90% of all software [21:51:52 CEST] <mkver> Really? What way do e.g. srt subtitles (S_TEXT/UTF8 in Matroska) have for this? [21:52:35 CEST] <nevcairiel> I don't really get the point of this feature. It's not like you have video frames that get silently skipped for no reason [21:52:49 CEST] <nevcairiel> On a demuxer controlled level no less [21:52:55 CEST] <mkver> Ok, then there is also the invisible flag in the (Simple)Block header, but this can't be exported either. [21:53:51 CEST] <JEEB> SRT IIRC has had all sorts of stuff put into it, I wouldn't be surprised if there's some ways of putting a comment into a line [21:53:54 CEST] <JEEB> but yes [21:53:57 CEST] <nevcairiel> Matroska likes to invent nonsensical features tbh [21:53:58 CEST] <JEEB> SRT is a format with an exact start and end time [21:54:07 CEST] <mkver> For videos, this feature (whether through duration zero or no the invisible flag) could be used for frame-accurate cutting, similar to edit lists for mov/mp4. [21:54:23 CEST] <JEEB> we already have virtual time lines, though? [21:54:29 CEST] <JEEB> in matroska [21:54:37 CEST] <JEEB> as part of chapters [21:55:11 CEST] <mkver> And if said start and end time coincide, it will be indistinguishable from a subtitle packet without a duration at all. [21:56:06 CEST] <nevcairiel> btw AV_PKT_FLAG_DISCARD exists for frames that should not be shown, but decoded [21:56:14 CEST] <nevcairiel> but good luck hoping that anyone implements that properly [21:57:25 CEST] <JEEB> mkver: anyways yea - currently the "unknown" duration thing is a mess [21:58:13 CEST] <JEEB> if you really need to hold that info on the demuxer/muxer level and can't decode [21:58:22 CEST] <JEEB> since a lot of stuff is thus format-specific :P [22:01:26 CEST] <mkver> @nev: You are right. That info can be exported. Thanks. Sorry for the noise. [22:01:29 CEST] <JEEB> and if we want to differentiate unknown (say, -1) and zero. we'd have to change quite a few [22:01:52 CEST] <nevcairiel> yeah something like that is unlikely to get changed without reaaaaally good reasons [22:01:58 CEST] <JEEB> or actually I'm not sure how many demuxers use -1 and which use 0 already [22:02:02 CEST] <nevcairiel> since its very hard to deprecate and inform callers [22:02:05 CEST] <JEEB> the default value is probably 0 [22:07:11 CEST] <JEEB> we do have some -1s although I'm not sure for how long those stay like that [22:07:21 CEST] <JEEB> git grep is not perfect [22:07:48 CEST] <nevcairiel> AVPacket->duration of -1 is technically invalid [22:09:02 CEST] <JEEB> looked with `git grep -E "duration\s*=\s*" -- libavformat/` [22:09:16 CEST] <JEEB> which isn't perfect but it has some seeming AVPacket sets [22:09:26 CEST] <mkver> @JEEB: If by "we" you mean FFmpeg, then I have to say that Matroska ordered chapters (the virtual timelines) are not really supported (just like the file linking stuff). The current code basically ensures that only the first edition will be used. [22:09:52 CEST] <nevcairiel> the subtitle queue stuff uses -1 as a special marker that means "set me to the start time of the next subtitle" [22:09:55 CEST] <nevcairiel> it should never reach the caller [22:10:25 CEST] <JEEB> mkver: yes I know, there was a lot of hurf and durf about it back in the day, and nowadays I think we kind of have a consensus'ish about making it metadata/side data [22:10:42 CEST] <JEEB> mkver: which is how seemingly ISOBMFF edit lists should have been implemented like [22:11:01 CEST] <nevcairiel> the edit list stuff constantly causes issues [22:11:06 CEST] <JEEB> yes [22:11:15 CEST] <JEEB> quite a few API users just disable the "advanced" edit list code [22:11:16 CEST] <JEEB> :) [22:11:24 CEST] <nevcairiel> indeed i do that myself [22:11:35 CEST] <mkver> In LAV? [22:11:40 CEST] <nevcairiel> i also was one to push for that option even being present [22:11:47 CEST] <JEEB> mkver: aye [22:12:00 CEST] <JEEB> mpv also disables it because it does things on the wrong layer [22:12:06 CEST] <JEEB> (it's a presentation layer thing) [22:12:51 CEST] <nevcairiel> technically the same applies to mkv [22:13:12 CEST] <JEEB> yes [22:13:15 CEST] <nevcairiel> but mkv is far more limited by implementation, and most files and tools around that were build against how haali made it work on a demuxer level, so it sort of works out [22:13:22 CEST] <JEEB> yup [22:14:51 CEST] <nevcairiel> for mp4 .. i dont remember ever getting a real request for such files anyway [22:18:02 CEST] <mkver> So all the edit lists that you encounter are of the type that just shift the pts of the first packet to zero? [22:18:41 CEST] <nevcairiel> something like that yea [22:18:45 CEST] <JEEB> that's 99% of it all. then there's both borked samples (clearly not meant to be what the edit list says), and some which might be output from a video editor... as a project file [22:18:58 CEST] <JEEB> because MOV files were also supposedly utilized as at least partial project files [22:23:26 CEST] <JEEB> anyways, exported to the presentation layer (API client), and then that layer can handle it in ways it requires/knows [22:23:59 CEST] <JEEB> I'm just happy that it's pretty rare we get people actually having issues with the on-by-default advanced edit list stuff [22:24:41 CEST] <JEEB> every now and then, like once in a few months or so on the user channel I have to explain people how to disable it [22:25:31 CEST] <mkver> @Nev: If there is no next subtitle packet and the duration is still -1, what does it get set to? [22:26:29 CEST] <JEEB> which layer? [22:26:37 CEST] <JEEB> or what was the context? :) [22:27:14 CEST] <mkver> "<nevcairiel> the subtitle queue stuff uses -1 as a special marker that means "set me to the start time of the next subtitle"" [22:45:29 CEST] <nevcairiel> would have to read the code, so you can do that too :D [22:46:30 CEST] <mkver> Ok. [00:00:00 CEST] --- Wed Apr 17 2019

1 0

ffmpeg.log.20190416
by burek 17 Apr '19

17 Apr '19

[00:25:27 CEST] <phinxy> I'd like to know if any of the libav* libraries uses libmp3lame. Maybe that's what you are trying to say. [00:26:33 CEST] <c_14> No, the problem is that the ffmpeg you built is being linked at runtime to your system's libav* libraries which aren't linked against lame [00:27:04 CEST] <c_14> So you either need to link the binary statically, or make sure they're linked at runtime to the libraries you built and not the system ones [00:58:52 CEST] <jamie_1> hey im trying to compile ffmpeg with nvidia and the script im using is https://pastebin.com/raw/AKvCRuHf but i keep getting ERROR: nvenc requested, but not all dependencies are satisfied: ffnvcodec [00:59:04 CEST] <jamie_1> anyone know what im missing? [00:59:38 CEST] <cehoyos> You have to install https://git.videolan.org/?p=ffmpeg/nv-codec-headers.git;a=summary [01:00:18 CEST] <jamie_1> im going and getting the nv headers and setting up the the nvcodec includes but it doesnt seem to recognise the nvcodec [01:01:28 CEST] <jamie_1> roughly lines 70-80 [01:01:44 CEST] <jamie_1> sorry roughly lines 60-70 [01:02:12 CEST] <cehoyos> Did you see the link that I posted? [01:02:18 CEST] <jamie_1> function InstallNvcoedIncluedERROR: nvenc requested, but not all dependencies are satisfied: ffnvcodec [01:02:27 CEST] <jamie_1> sorry [01:02:47 CEST] <jamie_1> didnt mean to send that again... scrolled in my terminal and bumped enter [01:04:24 CEST] <jamie_1> cehoyos: ill aim at that git instead and see how it goes [01:07:11 CEST] <Atlenohen> kepstin: gop size of 0 didn't made a difference with x264 [01:08:05 CEST] <Atlenohen> Ofcourse with other codecs such as FFV1 it's all fine, and by the way FFV1 is being described as an intra-frame codec, doesn't that mean that setting GOP anything higher than 0 for FFV1 doesn't make any sense? [01:08:43 CEST] <cehoyos> FFV1 allows setting gop-size but ths usually makes no difference for the output file, it may make a difference in the future [01:09:09 CEST] <jamie_1> any suggestions on how to point that scrip to use that source? i know how to do it from the videolan github but not sure how to do it from that git [01:09:11 CEST] <cehoyos> It is very hard to believe that setting a gop size to different values makes no difference with x264... [01:09:40 CEST] <Atlenohen> cehoyos: the x264 case was a context from 1 to 0 [01:09:55 CEST] <Atlenohen> probably is a difference, i meant practically no difference [01:10:40 CEST] <Atlenohen> The video quality gets horrible after a few seconds and progressively turns more murky even starting to look like weird corruption, even tho the bitrate is like 10K [01:10:40 CEST] <jamie_1> nvm... got it [01:11:45 CEST] <jamie_1> i will win against this ffmpeg compile XD [01:15:13 CEST] <jamie_1> even pointed and using that as the compile header for ffmpeg it still fails [01:17:55 CEST] <cehoyos> Yes, gop size 0 and 1 (both very unusual values) have the same effect with x264 [01:19:04 CEST] <cehoyos> jamie_1: "still fails" is not a very useful description of your issue. Please understand that scripts (and FFmpeg) are generally not supported. Install the nvheaders, run configure with current FFmpeg git head and tell us if nvenc gets enabled. [01:19:57 CEST] <jamie_1> oaky, ill go back and start there [01:27:18 CEST] <another> cehoyos: setting the gop for FFV1 absolutely makes a difference [01:28:16 CEST] <another> a larger gop compresses better [01:40:00 CEST] <cehoyos> another: I heard that but I never found an input sample that allowed me to reproduce. [01:41:39 CEST] <another> really? i'm pretty sure i have [01:45:06 CEST] <another> just did a quick encode of the sintel trailer in 480p [01:46:19 CEST] <another> with default GOP of 12: 84137977 bytes [01:46:32 CEST] <another> GOP 1: 85146234 bytes [01:49:05 CEST] <cehoyos> Good to know, thank you! [01:52:09 CEST] <another> there's also a wiki page which explicitly mentions GOP: https://trac.ffmpeg.org/wiki/Encode/FFV1 [02:01:28 CEST] <jamie_1> cehoyos: do i need to enable it in the config for nvcodec or will it do it based on that it's installed already [02:03:21 CEST] <cehoyos> It should be auto-detected. [02:03:47 CEST] <cehoyos> --disable-nvdec disable Nvidia video decoding acceleration (via hwaccel) [autodetect] [02:03:54 CEST] <cehoyos> Similar for nvenc [02:04:13 CEST] <jamie_1> okay [02:04:43 CEST] <jamie_1> running now :D [02:05:23 CEST] <jamie_1> thanks for the help btw cehoyos [02:05:31 CEST] <cehoyos> Was the detection successful? [02:05:58 CEST] <jamie_1> well see [02:06:02 CEST] <jamie_1> im compiling now [02:06:14 CEST] <cehoyos> You don't have to compile, didn't I write that above? [02:06:24 CEST] <jamie_1> i might have missed it... sorry [02:06:28 CEST] <cehoyos> run configure with current FFmpeg git head and tell us if nvenc gets enabled [02:07:04 CEST] <cehoyos> grep CONFIG_NVDEC config.h [02:07:20 CEST] <cehoyos> grep CONFIG_NVENC config.h [02:07:45 CEST] <cehoyos> ? [02:09:05 CEST] <jamie_1> cehoyos: i was reading the console output and it is there [02:09:07 CEST] <jamie_1> :D [02:09:10 CEST] <jamie_1> thanks! [02:09:34 CEST] <jamie_1> i also added/made all the extra packages, any i could make from source resonable i did [02:09:40 CEST] <jamie_1> and it looks like all of them are there [02:32:39 CEST] <jamie_1> so the only issue im having now is when i go to reference ffmpeg for compile i get recompile with -fPIC how would i do that with ffmpeg? [02:38:47 CEST] <furq> jamie_1: you build all the external libs you're trying to link to with fPIC [02:39:45 CEST] <jamie_1> ooff... so i have to go back to the beginning [02:40:48 CEST] <jamie_1> furq: is it possible to pass the --enable-static in the build config and do it that way? [02:41:32 CEST] <furq> maybe [02:42:00 CEST] <jamie_1> ehh, ill give it a go and find ouyt [02:42:17 CEST] <furq> if you actually want a fully static build then that should work [02:42:32 CEST] <furq> it'll be a lot quicker to find that out anyway [02:42:50 CEST] <jamie_1> furq: obs doesnt like the shared libraries [02:43:57 CEST] <jamie_1> furq: ill let you know [02:55:44 CEST] <jamie_1> furq: no good :( [02:56:04 CEST] <jamie_1> any ideas how to overcome the relocation R_X86_64_PC32 against symbol `ff_pw_9' can not be used when making a shared object; recompile with -fPIC without having to recompile EVERYTHING [02:56:19 CEST] <jamie_1> like the deps i have [02:56:31 CEST] <jamie_1> i dont mind compiling ffmpeg again... but all the deps would take a good minute [05:24:43 CEST] <unlord> I'm sure you all saw https://www.reddit.com/r/AV1/comments/bdmk6h/32bit_ffmpeg_and_libaom_curren… [05:35:22 CEST] <furq> i don't think that many people are really concerned about whether av1 and avisynth work properly together [05:35:49 CEST] <furq> Well there are plenty of filters that don't work with Vapoursynth. Like QTGMC, [05:35:53 CEST] <furq> this guy's done his homework [07:34:09 CEST] <Atlenohen> Hmm, weird, on windows libavutil/avconfig.h and libavutil/ffversion.h are not CRFL but LF ... this intended or just forgoten to be converted ? [07:37:16 CEST] <Atlenohen> Not sure if it's Git on windows or MSYS2 or the make build process responsible for this, these are include headers that are part of the finished build (make install) but maybe .h just get copied as is, not sure yet, [08:02:16 CEST] <Atlenohen> Wait so what's on the ffmpeg's repo in previous releases aren't the stable ones, only the tarball links on the front page are regarded stable? [08:03:08 CEST] <Atlenohen> For example 4.1.3-3 state which is like 2 weeks old from the release of 4.1.3, is not considered stable ? [08:04:35 CEST] <furq> huh [08:07:41 CEST] <Atlenohen> I cloned from 4.1, not from master, built and got the full version as 4.1.3-3-abcabcabc [08:09:14 CEST] <Atlenohen> A stable 4.1.3 was released on 4th April, today is 16 april and 4.1 branch has received more commits, is 4.1.3-3 right now considered stable or not? [08:09:54 CEST] <Atlenohen> My guess is not, by pure logic, but I'm just double checking [08:15:52 CEST] <furq> the 4.1 branch isn't stable, no [08:15:56 CEST] <furq> there's a tag for 4.1.3 [08:16:57 CEST] <furq> old branches don't get any new features but they are still actively worked on for bugfixes [08:18:41 CEST] <Atlenohen> Oh tags, right. Well in this case the difference shouldn't be that big to bother, but just to be sure, thanks. [08:29:23 CEST] <Atlenohen> Thanks guys for all the help, pretty much done with this chore, I'll probably be more personally interested in getting to know FFmpeg deeper later on when I'll be doing some of my own projects/ideas for myself that I've been having in the past, glad I got this job which finally got me over the hardest part that I kept delaying. [13:49:19 CEST] <Zucca> Hi. I have a looooooong video. I'd like to convert it to a time-lapse video. The video has 30fps frame rate, and I'd like to only take every 30th frame (essentially convert it to 1fps video) and then speed it up to 60fps so that one second is one minute in video. [13:49:35 CEST] <Zucca> Can this archieved losslessly? [13:51:01 CEST] <Zucca> When I think of it: drop 29 of 30 frames, then speed up by x60. That should not need any re-enconding. Right? [13:52:10 CEST] <Zucca> Also I don't have any audio to consider. [13:57:15 CEST] <cehoyos> Zucca: Please provide "ffmpeg -i" console ouput for your video. [13:57:20 CEST] <cehoyos> In most cases, this cannot be done. [13:57:37 CEST] <cehoyos> In most cases, what you ask for cannot be done. [13:58:08 CEST] <DHE> making a video of only keyframes might be doable, but it will at best constrain the speedup and/or output framerate. and the video bitrate will be rather high [13:58:51 CEST] <Zucca> It's ffv1 encoded. [13:58:54 CEST] <Zucca> Stream #0:0: Video: ffv1 (FFV1 / 0x31564646), yuv422p(progressive), 640x480, 30 fps, 30 tbr, 1k tbn, 1k tbc (default) [14:00:15 CEST] <Zucca> To to be able to do this I'd need to choose kayframing and codec propely or capture 1fps to begin with? [14:01:07 CEST] <DHE> a bit of both. there's -skip_frames nokey but that'll just produce a stuttering video [14:01:45 CEST] <cehoyos> Where is the problem? Simply re-encode to ffv1 (you cannot do codec copy for your usecase) [14:01:45 CEST] <Zucca> But since I have it as ffv1 already I can just re-encode it as ffv1 and lose onlt the dropped frames. [14:02:07 CEST] <DHE> yeah, being ffv1 at least you're not losing image quality here [14:02:47 CEST] <Zucca> cehoyos: I thought to get some speedups by doing stream copy. ;) But I'll go with re-encoding since it's the easiest way. [14:03:01 CEST] <DHE> so... ffmpeg -skip_frames nokey -r 3600 -i input.mkv -c ffv1 -r 30 output.mkv [14:03:10 CEST] <cehoyos> It is the only way because there is no raw ffv1 that you can feed into image2 [14:03:14 CEST] <DHE> I think... never tried this before [14:03:24 CEST] <cehoyos> This is not related to skip_frames [14:03:41 CEST] <DHE> but it would speed up the decoding step, hopefully providing at least some speedup [14:03:46 CEST] <DHE> assuming your GOP setting is sane-ish [14:04:35 CEST] <DHE> it may make the output video less consistent though [14:04:46 CEST] <Zucca> I have only used -c:v ffv1 when creating the video. [14:05:00 CEST] <furq> does -skip_frame nokey speed up ffv1 noticeably [14:05:19 CEST] <Zucca> I could test it... [14:05:41 CEST] <DHE> it's described as "skip decoding for the selected frames", so if you're dropping 90%+ of all frames, it sounds worthwhile [14:06:19 CEST] <cehoyos> Can we please agree that this is not the use-case for skip_frame? [14:06:35 CEST] <furq> it's not that uncommon of a use for skip_frame really [14:06:38 CEST] <furq> it is a hack though [14:07:05 CEST] <DHE> there's definite unknowns that prevent us from being sure it's a good idea [14:07:19 CEST] <Zucca> Sure it is. The only reason I like it a bit is the speedup... But I think I'll avoid it. [14:07:28 CEST] <furq> what is even the default gop size for ffv1 [14:08:37 CEST] <furq> apparently 12 [14:10:59 CEST] <King_DuckZ> hi, I have an AVCodecContext c on which I set c->profile = 1 and c->profile = 4, but that doesn't seem to have any effect on the output file [14:11:05 CEST] <King_DuckZ> codec is prores_ks [14:11:30 CEST] <King_DuckZ> how can I achieve the same effect that -profile:v X on the command line would have? [14:13:50 CEST] <cehoyos> It is supposed to work with prores_aw [14:14:16 CEST] <King_DuckZ> ah, so is it just not supported by prores_ks? [14:15:21 CEST] <cehoyos> Not in the way you tested it. [14:17:41 CEST] <King_DuckZ> ffprobe -show_streams is still reporting profile=unknown tho, even if I use prores_aw [14:18:03 CEST] <King_DuckZ> but I mean, if it can be made to work with prores_ks, then how do I do it? [14:18:26 CEST] <durandal_1707> via AVOptions [14:20:00 CEST] <DHE> AVDictionary *dict = NULL; av_dict_set(&dict, "profile", "auto", 0); avcodec_open2(avc_ctx, codec, &dict); [14:20:23 CEST] <DHE> (yes, AVDictionary** is intentional) [14:20:51 CEST] <King_DuckZ> DHE: ah I think I understand that, thanks [14:21:07 CEST] <King_DuckZ> so should I just leave c->profile to just 0 all the time? [14:21:57 CEST] <DHE> setting c->profile manually requires knowing the numerical codes for the profiles and they're not exported in a user header file. I would use the dictionary method [14:24:15 CEST] <DHE> (a very large number of options can be set this way - both codec-specific and otherwise) [14:25:02 CEST] <King_DuckZ> ah, I thought it was the constants from FF_PROFILE_* macros [14:25:15 CEST] <King_DuckZ> damn ok, I'll delete that and use the dictionary approach [14:26:38 CEST] <DHE> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/proresenc_kostya.c#… Oh? That's kinda interesting, because the source includes these duplicates. [14:26:55 CEST] <DHE> and those are what the AVDictionary code will expand them out to... [14:27:31 CEST] <DHE> at least they seem to be in the same order and all that [14:27:50 CEST] <King_DuckZ> T_T [14:27:54 CEST] <DHE> ikr [14:42:37 CEST] <Zucca> Since I still need to re-encode my video to get the time-lapse... I could set "keyframerate" to a very low value to save space. Right? [14:43:14 CEST] <Zucca> I ment for the video when I'm doing the initial capturing. [14:46:47 CEST] <furq> Zucca: a lower gop size will use more space [14:46:55 CEST] <furq> also it doesn't make a huge amount of difference with ffv1 [14:47:06 CEST] <Zucca> Hm. [14:47:10 CEST] <Zucca> Ok. [14:47:22 CEST] <furq> it obviously depends a lot on the content so you might as well try it on a short chunk [14:47:32 CEST] <furq> but i wouldn't expect more than a few percent [14:47:33 CEST] <Zucca> furq: [14:47:39 CEST] <Zucca> Well it's static mostly. [14:47:53 CEST] <Zucca> Timelapse from my yard. [14:48:12 CEST] <furq> you might want to use something like x264 lossless then [14:48:16 CEST] <furq> since that actually does inter compression [14:48:48 CEST] <Zucca> I've been trying out with vp9. But eventually went with ffv1. [14:49:28 CEST] <furq> i would definitely use x264 over vp9 for this [14:49:42 CEST] <Zucca> Why's so? [14:49:53 CEST] <furq> speed, mostly [14:50:12 CEST] <furq> also i know x264's lossless mode is fairly widely used whereas i don't think vp9's is [14:50:22 CEST] <furq> or libvpx's is rather [14:50:55 CEST] <furq> ffv1 is pretty nice but if you have a mostly static image then x264 should compress a lot better [14:51:27 CEST] <Zucca> Yeah. With vp9 I need to drop then capturing frame rate a bit. Although I might do it anyway. Since I'm doing timelapse I really don't need 30fps input. [14:52:22 CEST] <Zucca> 30fps is there because if somathing interesting happens I could extract it from the "master" and still get 30fps. [14:52:57 CEST] <Zucca> Oh well... I'll test out different options and see what suits the best. [14:53:25 CEST] <furq> if you don't get a decent size reduction with x264 then just stick with ffv1 [14:54:11 CEST] <Zucca> Yeah. ffv1 is suprisingly light with this task. Although the resolution isn't high. :P [15:00:15 CEST] <nicoulaj> could anyone tell me if HEVC hardware encoding is possible on Linux + AMD ? looks like AMF does not support Linux, and VAAPI/MESA only supports H264 if I'm reading the wiki correctly ? [15:50:06 CEST] <faLUCE> hello, are there cases in which AVFrame->pkt_duration of a demuxed packet is wrong? [15:51:25 CEST] <faLUCE> (pts are right, and evaluating the duration with pts - prev_pts gives ~3000, which is 33,3ms (30fps) if rescaled according to the demuxer time_base) [15:51:34 CEST] <faLUCE> but pkt_duration gives 6000 [15:52:10 CEST] <JEEB> generally that means that the value in the container might be incorrect (otherwise a bug) [15:53:07 CEST] <faLUCE> JEEB: ok, thanks. I wondered if there could be other reasons [15:54:55 CEST] <JEEB> I'm not sure if lavf tries to guesstimate you a value if the demuxer doesn't give you one. but I would think it wouldn't [15:56:11 CEST] <faLUCE> do you mean "if the muxer doesn't give you one" ? [15:56:26 CEST] <JEEB> if the muxer itself doesn't set the field [15:56:32 CEST] <faLUCE> ok [15:56:40 CEST] <JEEB> I recall MPEG-TS not setting pkt_duration so I would guess not :P [16:04:17 CEST] <kepstin> nicoulaj: vaapi can to hevc, needs fairly recent mesa i think. On nvidia cards with the binary driver, nvenc can do hevc [16:04:38 CEST] <Numline1> Hey folks, I suck at ffmpeg. Can someone please help me with this command, so it extracts an image about every 5 seconds? ffmpeg -i AMBA0273.MOV -vf thumbnail=100 -frames:v 1 thumb%04d.jpg [16:04:50 CEST] Action: kepstin has done some test hevc encodes w/vaapi on his rx 560 and they worked fine, better than the h264 encoder in fact :/ [16:04:59 CEST] <cehoyos> Why did you choose 100? Why vframes 1? [16:05:32 CEST] <Numline1> cehoyos I wasn't sure how to combine that. 100 was supposed to be every x frames, vframes was in the original command and I wasn't sure what to do with it [16:05:58 CEST] <kepstin> Numline1: "-vframes 1" means "output a single frame then exit" [16:06:06 CEST] <Numline1> oh [16:06:17 CEST] <Numline1> well okay, I removed it :) Now it seems to create a thumbnail every 100 frames [16:06:37 CEST] <Numline1> I'm trying to find a way to extract a reasonable amount of images for each video [16:06:57 CEST] <Numline1> I'm not exactly sure how to scale it properly [16:10:53 CEST] <cehoyos> Only you know the input video, only you can decide what is "reasonable" [16:12:02 CEST] <Numline1> Yeah I was thinking - 10 "thumbnails" for first 10 seconds, then 1 thumbnail every 5 seconds [16:12:13 CEST] <Numline1> although I'm not sure if that's even possible in a single command [16:12:23 CEST] <Numline1> I assume I'd have to set -ss for the second part [16:12:43 CEST] <Numline1> cehoyos btw, just to verify - the thumbnail filter thingie - does it take 100 frames and looks for the best one? [16:14:10 CEST] <cehoyos> https://ffmpeg.org/ffmpeg-filters.html#thumbnail [16:14:16 CEST] <cehoyos> It picks one of 100 [16:17:15 CEST] <Numline1> okay, thanks [16:17:19 CEST] <Numline1> one more thing I'm wondering about [16:17:20 CEST] <Numline1> ffmpeg -ss 00:00:10 -i AMBA0273.MOV -t 1 -vf thumbnail thumb%04d.jpg [16:17:35 CEST] <Numline1> This creates 30 thumbnails, probably one for each frame. Why;s that? [16:21:30 CEST] <furq> you need to set the output framerate to match [16:22:45 CEST] <Numline1> oh, I removed the =100 [16:22:48 CEST] <Numline1> I'm a dumbass [16:22:48 CEST] <Numline1> thanks [16:23:47 CEST] <furq> it defaults to 100 anyway [16:24:05 CEST] <Numline1> oh. Then I'm not sure I follow [16:25:05 CEST] <furq> the thumbnail filter doesn't actually change the output framerate so it just outputs a bunch of duplicate frames [16:25:16 CEST] <furq> you want something like -vf thumbnail,fps=30/100 [16:25:38 CEST] <kepstin> I think "-vsync 0" would work here as well [16:26:01 CEST] <cehoyos> Yes, and it is recommended [16:26:07 CEST] <furq> oh yeah that's a less dumb way of doing it [16:27:49 CEST] <Numline1> I'll go with the less dumb way then :) Thanks folks [16:28:11 CEST] <Numline1> ffmpeg -ss 00:00:10 -i AMBA0273.MOV -t 10 -vf thumbnail=50 -vsync 0 thumb%04d.jpg is the final version, seems to be fine [17:05:59 CEST] <superware> can an AVPacket contain more than a single video frame? [17:14:32 CEST] <kepstin> superware: i think with most video codecs that'll hold, although there might be some cases where a parser of some sort has to be run before that's true [17:14:53 CEST] <kepstin> (and I'm not sure how things like vp9's alternate reference frame, which is decoded but not displayed, is handled) [17:15:28 CEST] <kepstin> in general, when decoding video, you cannot assume that if you pass one packet to the decoder, that it'll give you one frame back [18:01:57 CEST] <King_DuckZ> DHE: I fixed my program, I get different file sizes now depending on which profile I set [18:02:26 CEST] <King_DuckZ> but if I run ffprobe -show_streams myfile.mov the profile field shown there is always set to unknown, is that normal? [18:13:17 CEST] <Cracki> cheers. I can't be assed to deal with understanding and using the library, but I'd like to generate a video from specified bitmaps at specified times, and pipe that to ffmpeg for compression. I remember there was a binary format for just such purposes... anyone remember it? haven't found it yet in the docs [18:14:09 CEST] <Cracki> my source material is quite sparse, maybe a few hundred different pictures over an hour. ATM I'm piping in raw bitmaps at a fixed frame rate, which is very very wasteful. [18:14:33 CEST] <King_DuckZ> yeah I did something like that myself, it's called y4m [18:15:33 CEST] <King_DuckZ> Cracki: https://wiki.multimedia.cx/index.php?title=YUV4MPEG2 this was my source of wisdom, plus some gotchas that are not clear from there and I found out by reading the code from some other project on the internet [18:16:17 CEST] <Cracki> I would prefer a variable frame rate, i.e. just PTS [18:16:38 CEST] <Cracki> I already have a solution for fixed frame rate [18:19:03 CEST] <King_DuckZ> https://alarmpi.no-ip.org/kamokan/fo?cpp this is my code for the header, you'll have to work out the details for yourself [18:19:15 CEST] Action: King_DuckZ shrugs [18:19:29 CEST] <King_DuckZ> that's the y4m specs [18:20:33 CEST] <Cracki> uh no thanks, I think I'm not making myself clear [18:20:42 CEST] <Cracki> I do NOT want fixed frame rate [18:21:36 CEST] <King_DuckZ> yeah, and what I said is that's what the y4m specs look like, wheter it supports that or not my fault [18:22:13 CEST] <Cracki> I never mentioned y4m, I am just looking for a better solution than I have [18:22:21 CEST] <Cracki> if that isn't a solution, fine? [18:22:26 CEST] <King_DuckZ> maybe you want to dig if there's anything else than y4m then [18:22:35 CEST] <Cracki> we're in #ffmpeg, right? [18:22:48 CEST] <King_DuckZ> yes? [18:23:47 CEST] <Cracki> ah, there it is https://ffmpeg.org/nut.html [19:01:10 CEST] <yug_blop> Hi, is there a device like gdigrab for macos that allows you to specify a window title to record? [19:12:20 CEST] <coolhp48> Whould anyone know when I might find some documentation or an example of resampling using the AVSAMPLE API ? [19:13:03 CEST] <JEEB> doc/examples [19:13:27 CEST] <JEEB> that has swresample example, although I think it doesn't utilize the AVFrame-based API [19:14:33 CEST] <coolhp48> Hi Jeeb. You are correct. That's the example I was reading but it doesnt use AVFrame-based API calls. [19:16:13 CEST] <coolhp48> I think I might have found something in the group_lavr documentation (detailed description section). Its still sample based and not frame based but it seems simpler than the resample example from the doc folder. [19:26:31 CEST] <tablerice> trying to convert .R3D footage into anything else (prores MOV, h264 mp4) but I'm getting an error "Invalid data found when processing input". How can I find more info about the error? [19:30:08 CEST] <JEEB> tablerice: just `ffprobe -v verbose -i "FILE"` and pastebin that. then link here. might just be that the file is in a format that's not supported by FFmpeg (yet) [19:33:35 CEST] <tablerice> https://pastebin.com/kf4q1G4W [19:33:57 CEST] <JEEB> that's an older version of FFmpeg, but yea - exactly what I thought :) [19:34:12 CEST] <JEEB> FFmpeg couldn't figure out what that is [19:34:14 CEST] <tablerice> I saw something while researching, ffpmeg only supports a certain version of red footage? [19:34:23 CEST] <tablerice> version 3 i think? [19:34:25 CEST] <JEEB> it supports exactly what was reverse engineered ;) [19:34:35 CEST] <tablerice> Ha ha no worries [19:34:37 CEST] <JEEB> it's not like R3D publishes what they create [19:34:53 CEST] <tablerice> Nah, they're proprietary to the max [19:36:41 CEST] <JEEB> check if there's any similar ticket on trac.ffmpeg.org. if there isn't and you have some samples you can share, feel free to upload some short sample that you can share somewhere sane (like f.ex. 0x0.st with curl - curl -F'file=@FILE' https://0x0.st ) and make an issue [19:36:48 CEST] <JEEB> (or well, feature request to be exact) [19:37:11 CEST] <JEEB> https://wiki.videolan.org/Bounties [19:37:20 CEST] <JEEB> videolan bounty page doesn't seem to have one for modern R3D [19:37:48 CEST] <JEEB> it has contact info if you or your employer might be interested in sponsoring a bounty [19:39:28 CEST] <tablerice> Sounds good. Thanks for the help JEEB! [19:57:44 CEST] <tablerice> Okay so apparently the team at RED has some linux users because I just came across this little gem for anyone else trying to convert R3d footage on linux while keeping all the raw goodness: https://www.red.com/downloads/options?itemInternalId=16146&version=1 [21:30:22 CEST] <TheSashmo> has anyone at all ever seen a player that can support mpeg2 in browser other than vlc plugin? [22:16:05 CEST] <ChocolateArmpits> TheSashmo, windows media player embed supports it [22:16:17 CEST] <ChocolateArmpits> but of course only on internet exploder [22:18:23 CEST] <ChocolateArmpits> quicktime browser plugin should also support it [22:18:34 CEST] <TheSashmo> ChocolateArmpits: oh snap! never thought of that [22:32:17 CEST] <TheSashmo> ChocolateArmpits: but chrome and firefox are my go to browsers obv.... [22:32:35 CEST] <ChocolateArmpits> What's so bad about VLC then? [22:32:50 CEST] <ChocolateArmpits> Maybe there are some proprietary solutions for this, but I really can't name any more [22:40:10 CEST] <ChocolateArmpits> I can only guess what you're doing, but usually for large collections of videos that need to be previewed in the browser a compatible format version is transcoded [22:53:56 CEST] <alexozer> ffmpeg seems to output the entire video starting at "-ss" instead of ending at "-to": [22:53:58 CEST] <alexozer> ffmpeg -ss 929.363 -noaccurate_seek -i practice1.mp4 -to 939.681 -c copy -y part-1-practice1.mp4 [22:54:11 CEST] <alexozer> so in this case, the video should only be 10 seconds long but it's much longer than that [22:54:37 CEST] <c_14> either use -t and a duration or add -copyts [22:55:11 CEST] <kepstin> TheSashmo: you could always compile ffmpeg to wasm and run a decoder in the browser that way [22:56:54 CEST] <kepstin> alexozer: when you use -ss before the -i, ffmpeg cli runs some timestamp cleanup code that changes the timestamps to start at 0 [22:57:18 CEST] <kepstin> alexozer: so that command will grab 939.681s of video starting at 929.363 seconds in [22:57:51 CEST] <alexozer> kepstin: ah interesting. Would providing -i before -ss work in this case as well then? [22:58:16 CEST] <kepstin> alexozer: that would work, but it would be a *lot* slower, since -ss after -i has to decode the entire video up to the start point [22:59:09 CEST] <alexozer> kepstin: interesting thank you! [22:59:41 CEST] <kepstin> alexozer: there's some options to change the timestamp behaviour in ffmpeg, depending on what exactly you want to do [22:59:59 CEST] <kepstin> (note that you generally do want the encoded output to have timestamps starting at 0) [23:01:35 CEST] <kepstin> for example, the "-copyts" option disables the input timestamp processing, and the result will be 10 seconds of video - but the timestamps in the output will start at 939.681s [23:03:39 CEST] <alexozer> so to get the optimal seek performance as well as zero-based timestamps for the output videos, I could provide the duration to -to in my command, correct? [23:04:14 CEST] <kepstin> alexozer: the duration in the -to or -t option would work, yeah (with 0-based timestamps, both options have the same behaviour) [23:04:34 CEST] <kepstin> alexozer: note that you can also use -to as an input option (before -i), and you might want to see how that compares as well [23:07:53 CEST] <alexozer> kepstin: using -to before -i seems most reasonable I think [23:09:25 CEST] <jamie_1> so i am working on compiling ffmpeg from scratch and i have done it fine before, but i nuked my dir since i made a few whoopsies i was having a hard time fixing, so im working on a 100% fresh install folling the ffmpeg compile instructions and i keep running into https://pastebin.com/S0EM508X [23:10:39 CEST] <kepstin> jamie_1: please share your configure line, linux distro and arch, and more of the build log [23:10:49 CEST] <jamie_1> okay one sec [23:13:43 CEST] <irwiss> good time of day, i'm trying to figure out how to convert numeric pixel format into the short string identifier, looking at https://ffmpeg.org/doxygen/4.0/pixfmt_8h_source.html there seems to be an #ifdef block in the middle , do these numbers then float around as compiler defines are set or are they constants? [23:14:10 CEST] <kepstin> jamie_1: I'm guessing a bit, but it looks like you're trying to build the ffmpeg libraries (libavcodec.so, etc.) but have it set to statically link in the C library, which isn't gonna work [23:17:14 CEST] <kepstin> irwiss: the way to get the name from the number is to call https://ffmpeg.org/doxygen/4.0/pixdesc_8h.html#afe0c3e8aef5173de28bbdaea429… which returns the descriptor structure, and that has a name string in it. [23:18:36 CEST] <kepstin> irwiss: if the numbers change, the soversion of the ffmpeg libs will be changed as well, so you'd have to rebuild to link to the new lib [23:18:40 CEST] <irwiss> that seems to be what i'm looking for, google for some reason referred to https://ffmpeg.org/doxygen/4.0/group__lavc__misc__pixfmt.html which hasn't got that method listed, thanks! [23:18:54 CEST] <jamie_1> kepstin: how would have it not statically link the c libraies [23:19:10 CEST] <kepstin> jamie_1: please share your configure line, linux distro and arch, and more of the build log [23:19:17 CEST] <jamie_1> kepstin: im still working on it [23:19:32 CEST] <kepstin> jamie_1: you probably have something on the configure line which is incorrect [23:19:35 CEST] <jamie_1> i had to do a make clean and make to get the output again so i could link it [23:19:51 CEST] <jamie_1> https://pastebin.com/pS5v47jy is my config line [23:20:03 CEST] <jamie_1> im still working on getting a build log [23:20:35 CEST] <jamie_1> thats gonna be a few minutes though [23:21:29 CEST] <kepstin> jamie_1: hmm. that actually looks correct for the use of pkg-config; i'm guessing that some of the libraries you're trying to link into ffmpeg weren't built with -fPIC [23:22:10 CEST] <jamie_1> kepstin: if you give me just a sec, i should be able to find out [23:22:33 CEST] <jamie_1> its libaom but i honestly dont have a darn clue how to work with that one [23:22:41 CEST] <kepstin> to build a library like libx264 statically, but in such a way that it can be linked into a shared library, often requires special prep [23:23:26 CEST] <jamie_1> im trying to build one for obs that includes latest nvenc and nvida sdk [23:23:27 CEST] <kepstin> (do you actually need the libavcodec.so, etc. libraries? or only the ffmpeg cli tool?) [23:24:04 CEST] <jamie_1> im building for obs compile from scratch so it depends on libav for encoding in x264 [23:24:17 CEST] <jamie_1> at least from what i understand [23:24:20 CEST] <kepstin> tbh, it would be easiest if you just remove the --pkg-config-flags="--static" and link to the various libraries dynamically [23:24:27 CEST] <furq> jamie_1: if it helps you're not going to be needing libaom for obs [23:24:30 CEST] <jamie_1> obs doesnt allow you to [23:24:36 CEST] <furq> unless you want to capture your screen at 0.01fps [23:24:43 CEST] <jamie_1> yeah no.... [23:24:56 CEST] <jamie_1> that would be pretty funny though [23:25:00 CEST] <jamie_1> do that for a day [23:25:33 CEST] <kepstin> it would certainly be a low bitrate livestream ;) [23:25:57 CEST] <jamie_1> what would be the best way to dissable libaom? [23:26:05 CEST] <furq> remove --enable-libaom from configure [23:26:10 CEST] <jamie_1> im not sure exactly what it does to start with but it was listed as part of the standard ffmpeg [23:26:30 CEST] <jamie_1> was hoenstly one of the few parts i didnt at least know what they do [23:26:37 CEST] <furq> libaom encodes av1 [23:26:50 CEST] <kepstin> specifically, libaom encodes av1 very slowly [23:26:53 CEST] <jamie_1> yeah... not planning on doing that any time soon [23:27:15 CEST] <jamie_1> i have no use for av1 personnaly [23:27:24 CEST] <furq> not many people do yet [23:27:51 CEST] <jamie_1> would be cool to look into, still working on understand x264 and x265 better before that XD [23:28:04 CEST] <jamie_1> *working on understanding [23:28:38 CEST] <jamie_1> so im assuming the best course of action would be to remove libaom from my user libs? [23:32:58 CEST] <jamie_1> just removed libaom from my config and removed it from my bin [23:33:10 CEST] <jamie_1> didnt know if it would catch it in the autoconfigure so i wanted to make sure it didnt [23:33:39 CEST] <jamie_1> thanks for the help kepstin snf furq [23:33:46 CEST] <jamie_1> not sure where the snf came from [23:41:01 CEST] <jamie_1> screwed up fdk-aac too :/ had to change that to --enable-shared [00:00:00 CEST] --- Wed Apr 17 2019

1 0

ffmpeg-devel.log.20190415
by burek 16 Apr '19

16 Apr '19

[00:05:15 CEST] <jamrial> anyway, patch sent [09:26:49 CEST] <cone-690> ffmpeg 03Steven Liu 07master:f502bd5432c9: lavf/rtsp.c: Fix stimeout option not applied on http tunnel [11:02:28 CEST] <superware> how can I detect (from AVFormatContext/AVStream) that the opened media is a file OR a real-time stream? [11:03:45 CEST] <funman> try seeking? [11:05:41 CEST] <superware> can't RTSP seek? [11:06:43 CEST] <funman> I guess it might [11:06:58 CEST] <JEEB> there's no flag for "live stream" in lavf as far as I know [13:44:39 CEST] <cone-690> ffmpeg 03Steven Liu 07master:bbae8d08f592: Revert "lavf/rtsp.c: Fix stimeout option not applied on http tunnel" [13:44:40 CEST] <cone-690> ffmpeg 03Signed-off-by: Jun Li 07master:1ae8a1073ba8: lavf/rtsp.c: Fix stimeout option not applied on http tunnel [13:45:15 CEST] <nevcairiel> someone needs to stop sucking =p [13:47:12 CEST] <cone-690> ffmpeg 03Steven Liu 07master:7f78a1b1caea: Revert "lavf/rtsp.c: Fix stimeout option not applied on http tunnel" [13:47:13 CEST] <cone-690> ffmpeg 03Jun Li 07master:32148b5ac96b: lavf/rtsp.c: Fix stimeout option not applied on http tunnel [13:47:18 CEST] <durandal_1707> why this guy have commit access? [13:47:42 CEST] <JEEB> o_O [13:47:59 CEST] <JEEB> that's quite... unfortunate [14:04:33 CEST] <BtbN> What even is that? Revert and immediate re-apply of the same commit, from a different author? [14:05:09 CEST] <ubitux> Author: Signed-off-by: ... [14:05:11 CEST] <ubitux> lol [14:05:22 CEST] <ubitux> wonky [14:06:59 CEST] <BtbN> It changes not a single line of code? What? Why? [14:07:33 CEST] <ubitux> it's applying 3x the "same" commit, and revert it twice [14:07:40 CEST] <ubitux> i think the patch is applied [14:09:38 CEST] <BtbN> It's Revert + Apply same patch again, twice [15:38:34 CEST] <cone-690> ffmpeg 03Jun Zhao 07master:abfeba97241e: lavf/hls: Cleanup the applehttp [21:04:11 CEST] <faLUCE> Hello. I would like to send a patch containing a new API usage example, which I think is very useful for libavcodec users. Unfortunately, adding a new example requires one new file (new_example.c), and requires to modify configure, Makefile and Makefile.example. I can create a patch with all 4 files, but if one of them change meanwhile, I have to create a new patch. I was told that a patch often has to be pinged a [21:04:13 CEST] <faLUCE> lot before it is considered/accepted, so what can I do in order to create this patch in an easy way? [21:05:39 CEST] <JEEB> if you have the commits in a branch locally then you just rebase against master. if there are actual merge conflicts git will tell you [21:05:47 CEST] <JEEB> then you just commit and finish rebase [21:06:16 CEST] <JEEB> the examples directory though isn't as much touched so not sure how likely it is that it will hit a conflict? [21:06:39 CEST] <faLUCE> JEEB: but the patch touches configure [21:07:05 CEST] <JEEB> ok, then it's more likely [21:07:19 CEST] <JEEB> but if there's no merge conflict it will just get done automagically [21:07:33 CEST] <JEEB> at the worse part you just fix a (most likely minor) merge conflict [21:07:36 CEST] <faLUCE> with rebase? [21:07:39 CEST] <JEEB> yes [21:07:51 CEST] <JEEB> you have your own xxx_example branch locally [21:07:53 CEST] <faLUCE> I see, then I have to understand how rebase works [21:07:54 CEST] <JEEB> you update your local master [21:08:19 CEST] <JEEB> faLUCE: I didn't say that there is no merge conflicts if someone changed something right next to your place and git can't figure it out by itself [21:08:29 CEST] <JEEB> in that case it will ask you which parts to keep :P [21:08:39 CEST] <JEEB> still, should be relatively quick [21:08:48 CEST] <JEEB> commit and tell rebase to --continue, done [21:09:15 CEST] <faLUCE> ok, so, I pull in local master, then I rebase my_branch (with the new example) against LOCAL master [21:09:26 CEST] <JEEB> well local or remote [21:09:29 CEST] <JEEB> either is fine [21:09:36 CEST] <JEEB> usually you just have a copy of master around locally too :P [21:09:48 CEST] <faLUCE> yes [21:09:49 CEST] <JEEB> and at least I generally update local master when I fetch [21:10:16 CEST] <faLUCE> but why is it needed a local personal branch for rebasing? [21:10:24 CEST] <faLUCE> (because I rebase all the branch?) [21:10:42 CEST] <faLUCE> (instead of specifying the files?) [21:11:11 CEST] <JEEB> well I would rather keep master clean, no? [21:11:22 CEST] <JEEB> and you are handling a patch set and thus a branch makes sense IMHO [21:11:28 CEST] <faLUCE> of course [21:11:30 CEST] <JEEB> yup [21:11:46 CEST] <JEEB> that way you can work in git, and then export patches with git format-patch when needed [21:12:07 CEST] <faLUCE> but when addind to stage the modified files, do I have to git add file1 file2 etc. each time? [21:13:08 CEST] <JEEB> in which sense? if you have a merge conflict in a single file then that's all you add? [21:13:30 CEST] <faLUCE> sorry, the question was meaningless [21:13:42 CEST] <JEEB> also I think there's a shortcut to add all currently changed but unstaged files [21:14:03 CEST] <JEEB> but the more you use something like that the more likely you are to "oh, I didn't mean to add that one to *this* commit" [21:14:06 CEST] <JEEB> :) [21:14:35 CEST] <faLUCE> yes, I'll use git add ... [21:15:06 CEST] <TheAMM> git add -u [21:15:29 CEST] <JEEB> and that I will guess is the shortcut [21:15:36 CEST] <JEEB> "unstaged", I guess? [21:15:57 CEST] <TheAMM> probably, I think it as "update" [21:16:05 CEST] <TheAMM> Adds all changes from tracked files [21:16:20 CEST] <JEEB> yea, changed but unstaged [21:16:22 CEST] <JEEB> :) [21:16:33 CEST] <JEEB> if you open up gitk or so you'll see how it calls those things [21:16:36 CEST] <JEEB> (or git status, even) [21:17:13 CEST] <TheAMM> git add -u && git commit -m "wip" && git push prod [21:17:24 CEST] <TheAMM> lifehack [21:17:56 CEST] <TheAMM> (I have some history of abusing git as a file transport on personal projects) [23:21:22 CEST] <cone-842> ffmpeg 03Marton Balint 07master:e036b8dcf46d: avdevice/decklink_dec: set configs before listing formats [23:21:23 CEST] <cone-842> ffmpeg 03Marton Balint 07master:f3e22e320142: avdevice/decklink_common: properly check DoesSupportVideoMode result when trying VANC flag [23:21:24 CEST] <cone-842> ffmpeg 03Marton Balint 07master:63c2c83f6eb4: avdevice/decklink_common: add support for DeckLink SDK 11 [23:36:26 CEST] <faLUCE> JEEB and others: I don't get a point. The devel documentation says: "When you submit your patch, please use git format-patch OR git send-email. We cannot read other diffs :-). " But from what I read, git format-patch doesn't send any email" .... is it a typo error, and "OR" should be replaced with "AND" ? [23:37:24 CEST] <nevcairiel> git send-email will do everything in one step [23:37:39 CEST] <nevcairiel> but you can also manually attach the patch as an attachment, for that use git format-patch [23:38:27 CEST] <faLUCE> I see (then the webpage should be updated with a more clear description, IMHO) [23:38:36 CEST] <JEEB> well, format-patch makes something you can attach and send. send-email does format-patch + send e-mail. so technically it could say "and send the patches as attachment" to the format-patch part, but the person writing the text probably thought the sending part was obvious [23:38:55 CEST] <faLUCE> ok, got it [00:00:00 CEST] --- Tue Apr 16 2019

1 0

ffmpeg.log.20190415
by burek 16 Apr '19

16 Apr '19

[00:09:00 CEST] <DHE> ffmpeg's libs are static, but what other 3rd party libs (eg: x264) end up used remain in their original form and are pulled in as needed during compiling of real aps [00:15:26 CEST] <Atlenohen> Yeah I also had to modify the x264 header so that it doesn't use X264_API _dllImport thingy, and then rebuild ffmpeg [00:16:23 CEST] <Atlenohen> DHE: Cehoyos and others forgot this when they talked about BCrypt.lib with me, they kept telling me ffmpeg did not compile it [00:16:45 CEST] <Atlenohen> That apparently ffmpeg did not had a message about it it supposed to (about missing bcrypt.lib [00:27:00 CEST] <ncouloute> Concat Demuxer - 11.253-59.940 variable fps + frames shifting. [00:27:01 CEST] <ncouloute> Concat Protocol - 59.920-59.940 varible fps + no frame shifting [00:27:01 CEST] <ncouloute> . Concat Filter - 59.940 constant fps + frames shifting [00:27:01 CEST] <ncouloute> . My guess is since concat Protocol method first involves going from mp4 to ts then concat then remix back to mp4. [00:27:02 CEST] <ncouloute> Concat just doesnt work very well for h264 mp4s. [00:27:04 CEST] <ncouloute> Strangely enough h264_nvenc/h264_qsv encoded files dont have the frame shifting. [00:41:29 CEST] <cehoyos> That FFmpeg did not compile what? [01:49:35 CEST] <Atlenohen> cehoyos: Well, I got other people telling me bcrypt.lib wasn't suppose to be compiled with ffmpeg anyway as it's a standard practice that static libraries don't pack other libraries, unless specifically instructed. [01:50:48 CEST] <Atlenohen> I remember you thought that ffmpeg had to "compile" it and that there was a no error/warning about it being "missing". [01:55:19 CEST] <chinknot> I tried using a file with square brackets in its path with ffprobe but the terminal returns "No such file or directory". Is it possible this is a ffprobe related issue? I tried opening an issue on git-for-windows github but using the same path with other commands work without problems [01:57:44 CEST] <Ariyasu> encase the path in " [01:57:50 CEST] <Ariyasu> "path to input" [01:58:04 CEST] <chinknot> I tried that but same result [01:58:09 CEST] <Ariyasu> or caret the [] like ^[ and ^] [01:58:17 CEST] <chinknot> I'll try ^ [01:58:38 CEST] <chinknot> anyway sorry if I didn't mention it but I launched it via git-for-windows [01:59:45 CEST] <chinknot> ^ and \ didn't work [01:59:55 CEST] <chinknot> also replacing ' with " didn't help [02:20:40 CEST] <cehoyos> Atlenohen: You definitely don't "compile" bcrypt with FFmpeg, you need it to link the final executable, since you only build static libraries, you never need it. But FFmpeg's pkg-config file tells you that bcrypt is a dependency of libavutil. [02:21:30 CEST] <cehoyos> None of this is secret in any way and none of this is difficult in any way. You just manage to always mix your issue reports with some unrelated and wrong opinions (possibly of others) making helping you more difficult than necessary. [02:22:33 CEST] <Atlenohen> I didn't say it's secret, I obviously had no idea PKGCONFIG reports that ... if that's the standard place fine, but I'd have it in the terminal at the end of the build [02:24:51 CEST] <Atlenohen> You certainly didn't explain this back then, I was then looking what's making ffmpeg not get bcrypt, in the process I found other bugs and also figured out the whole thing I either would need to anyway so I lost no time and I'm actually glad now I went as deep as I did, I'm not blaming you, just asking if you have meant something else, or misunderstood the situation at the time. [02:26:31 CEST] <HickHoward> https://www.v-nova.com/tryPERSEUS/ [02:26:38 CEST] <HickHoward> perseus is going real live this time around [02:26:45 CEST] <Atlenohen> Because that day we concluded "it doesn't have an error for bcrypt, patch welcome", there were 3 other guys looking into bcrypt is needed, none of them mentioned it's not suppose to pack bcrypt.lib inside FFmpeg's libs. [02:33:17 CEST] <cehoyos> You reported a link error with your application yesterday and as I told you yesterday, it took me (who had never heard of this library) a minute to find out what you were missing. This simply isn't FFmpeg-related, the fact that the library doesn't show up in a list of external libraries that you most likely would have missed anyway is a bug but not one that ranks high on any list. [03:03:49 CEST] <Kaedenn> Are there Python bindings for libffmpeg or libavconv? [04:06:11 CEST] <Atlenohen> Cehoyos: sure that's right, I just wanted to clear out we both understand the same, I see now brcrypt.lib reported in the EXTRALIBS-avutil variable inside config.mak, not sure how do you guys feel about printing extralibs that at the end of thhe configuration process but it be kinda handy, for future new people dealing with it for example. [08:34:26 CEST] <pranayvshah> Is there a way to explicitly set the shaper when using the subtitles filter? I know there is for the ass filter. FFmpeg v4.1.3 sets ass->shaping to 0 with my subtitles filter command; if I use ass and set shaper to complex everything works [08:35:07 CEST] <pranayvshah> Even if there isn't a way, what can I do to have a value of 1 for ass->shaping [11:02:56 CEST] <superware> how can I detect (from AVFormatContext/AVStream) that the opened media is a file OR a real-time stream? [11:04:03 CEST] <while> I find vlc is having trouble playing a udp stream from ffmpeg, but it can be played with ffplay, is there a way to stream udp that vlc can read? [11:04:22 CEST] <while> (both audio and video) [11:05:20 CEST] <superware> while: output to "udp://ip:port?pkt_size=1316", and then try VLC [11:06:11 CEST] <JEEB> superware: I think lavf didn't have a flag for that [11:06:32 CEST] <JEEB> the previous mpv maintainer was pretty heavily herping a derp about that [11:07:02 CEST] <Mavrik> superware: that would be a property of AVIOContext more [11:07:04 CEST] <Mavrik> so something like [11:07:23 CEST] <JEEB> seeking was already mentioned but something rtsp might have support for seeking [11:07:26 CEST] <Mavrik> avformatcontext->pb->seekable == 0 [11:07:37 CEST] <JEEB> and yes, usually a protocol thing [11:07:45 CEST] <JEEB> although then you have the stuff on top of HTTP etc [11:12:50 CEST] <superware> while: output to "udp://ip:port?pkt_size=1316", I have a MediaInput raising PacketReady events, and a MediaPlayer receiving each packet, decoding the video stream and delaying (current_pkt_pts - last_pkt_pts), all that in a single thread. then I have a render thread being signaled for each delayed frame... [11:13:15 CEST] <superware> Problem is the video isn't smooth at all, so I guess the pts sync is wrong.. [11:13:41 CEST] <superware> (forget the "output to" :) [11:13:50 CEST] <while> I am trying your suggestion of output [11:14:04 CEST] <while> $ ffmpeg -re -i output.ogg -vcodec mpeg4 -f mpegts 'udp://127.0.0.1:10000?pkt_size=1316' [11:14:21 CEST] <while> is how I am currently issuing the command [11:14:41 CEST] <JEEB> you probably want to do multicast into localhost [11:14:50 CEST] <JEEB> that way multiple things can connect to it methinks [11:15:01 CEST] <superware> I was asking about detecting a real-time streams because I thought frames sync should be different for file vs. stream [11:15:30 CEST] <JEEB> yes, you may attempt low latency sync (aka ignoring some sync) with live streams [11:15:57 CEST] <JEEB> so that you show video f.ex. as fast as possible [11:16:03 CEST] <JEEB> as you receive the images from the decoder [11:17:33 CEST] <superware> from my experience you must do some syncing since incoming packets can be received at different times [11:18:37 CEST] <superware> only with syncing video will be smooth, otherwise they simply jitter, am I wrong? [11:20:00 CEST] <Mavrik> What's syncing in this case? [11:20:08 CEST] <Mavrik> You'll need to obey PTS for playback [11:20:28 CEST] <superware> that's what I mean [11:23:59 CEST] <while> so far adding the pkt_size option doesn't seem to have fixed it for VLC, but it still works in ffplay [11:23:59 CEST] <superware> what's the most simple syncing method? [11:24:30 CEST] <superware> while: I experienced VLC-udp issues, for me it worked [11:27:54 CEST] <while> I notice in Wireshark, is seems the udp packets are coming right before icmp port unreachable messages [11:28:24 CEST] <superware> while VLC is opening stream? [11:28:44 CEST] <while> here is vlc's log if it helps: https://wieldfield.com/downloads/20190415_ISO8601_vlclog.txt [11:28:56 CEST] <while> I have the VLC window open, and it still has the orange bouncing bar [11:29:29 CEST] <superware> try udp://@:10000 [11:29:56 CEST] <while> superware: yes it works! [11:33:01 CEST] <while> thank you [11:34:42 CEST] <superware> while: update your blog posts regarding ffmpeg/udp/vlc :) [11:35:12 CEST] <superware> it doesn't work without the "?pkt_size=1316", right? [11:35:21 CEST] <while> I haven't tried it without that yet [11:35:53 CEST] <while> I read that suggestion 2 other places, although trying with or without, both didn't work at the time [11:36:44 CEST] <while> to answer your question though, it is working without the "?pkt_size=1316" [11:37:21 CEST] <superware> Mavrik: after avcodec_receive_frame on the input thread, how should I calculate the delay in order to sync frames? [11:42:18 CEST] <superware> until now, what USED to work for me was no sycning on input thread (since I only played realtime streams) and syncing the frames from queue on a render thread. but now since I want to play files, I MUST sync on the input thread or else it will read frames at the speed of light [11:59:53 CEST] <superware> can someone please help me with how to sync frames (video-only)? [12:00:31 CEST] <superware> how much should I delay before rendering current frame? [12:02:05 CEST] <BtbN> Until the pts of the frame you want to present is reached [12:14:15 CEST] <superware> and when is that for the first frame? [12:18:52 CEST] <pk08> hello again [12:18:52 CEST] <pk08> i am developing an application which scales (scale filter) muliple input streams and overlay on single nullsrc filter using complex filter [12:18:52 CEST] <pk08> now i have problems in dts in output stream (outputing in h264(libx264) codec), Error: Application provided invalid, non monotonically increasing dts to muxer in stream [12:18:52 CEST] <pk08> and it only outputs I frames, no B or P frames. Log: [libx264 @ 0xea9b40] frame= 0 QP=11.24 NAL=3 Slice:I Poc:0 I:8160 P:0 SKIP:0 size=4038 byte [12:18:54 CEST] <pk08> can anyone please tell me how to fix these? [12:20:30 CEST] <pk08> output stream config: https://pastebin.com/e9QpvHhb [12:33:33 CEST] <pk08> rescaling packet: https://pastebin.com/QmR3MuCv [13:14:34 CEST] <superware> BtbN? [13:30:50 CEST] <pranayvshah> How/from where is this config_input function in vf_subtitles.c called please? https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_subtitles.c#L141 [13:35:36 CEST] <superware> How should I calculate delay between video frames in order to sync them for playback? [13:40:46 CEST] <superware> (with the master clock) [13:41:49 CEST] <BtbN> Like I said, based on the pts, presentation timestamps. [13:41:55 CEST] <BtbN> If you substract them, you get your delay. [13:46:21 CEST] <superware> but for real-time streams, frames can only be on-time OR late, so the delay isn't only based on pts subtraction, am I wrong? [13:47:11 CEST] <superware> when you open a file, you always get frames before their presentation time [13:55:13 CEST] <t3st3r> btw... does anyone knows if ffmpeg + VP9 supports "constrained quality" (CQ) mode in 2-pass mode and is it works with ffmpeg? Man/faqs/search results weren't conclusive. [13:55:56 CEST] <t3st3r> That is - what happens with ffmpeg + livbpx if I both specify -crf and non-zero bitrate? [13:56:10 CEST] <t3st3r> while doing 2 pass [13:56:55 CEST] <JEEB> that's up to libvpx [13:58:06 CEST] <JEEB> and the results differ between VP8 and VP9 most likely [13:58:13 CEST] <JEEB> since google changed the behavior of various options in libvpx [13:59:00 CEST] <pranayvshah> Hey JEEB, would you know how is this function called ? https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_subtitles.c#L141 [13:59:40 CEST] <t3st3r> This question about VP9 and how this particular combo + ffmpeg could/would perform. [14:00:31 CEST] <JEEB> t3st3r: ok, then you should first request info from folk who know libvpx better. you could guesstimate how it works from the libvpx vp9 wrapper but after all the final decision making is up to libvpx [14:00:34 CEST] <t3st3r> I've got idea I overall like CRF/CQ idea but I also like 2-pass. However I don't want "potentially unrestricted" bitrate. [14:01:24 CEST] <t3st3r> hmm any ideas of better channel to ask this question? [14:01:37 CEST] <t3st3r> do libvpx haves channel in freenode? [14:24:05 CEST] <Atlenohen> Hey guys, these are all the warnings I get in my FFmpeg build, there's no problem, just checking if anyone thinks anything's worth taking a look at https://pastebin.com/6v9d2FWN [14:28:43 CEST] <JEEB> t3st3r: I think at one point there was a #vp8 channel at least, also check the webm project's site [14:39:52 CEST] <t3st3r> JEEB> it really here, let's see if someone here got idea, thanks. [14:43:07 CEST] <kuznetsss> Hello, I am writing C++ application using FFmpeg libraries. [14:43:09 CEST] <kuznetsss> Here is part my code: https://pastebin.com/UEeEvZwq [14:43:11 CEST] <kuznetsss> I don't understand which function should initialize flags in AVOutputFormat which is inside AVFormatContext (format_context->oformat->flags)? [14:52:51 CEST] <t3st3r> interesting, google's developer pages actually recommend doing what I described and at 1st glance it does more or less what could be expected. [14:53:22 CEST] <Atlenohen> cehoyos: pkgconfig for ffmpeg isn't autogenerated so I couldn't have found out about bcrypt.lib that way, and in many places there doesn't appear to be windows compatible arguments, it uses /L almost everwhere instead of /LIBPATH: [14:57:48 CEST] <t3st3r> Also ... I've got rather odd problem. I did realtime vp9 encode and managed to box it into some strange (bugged?) bitrate allocation. [14:58:19 CEST] <t3st3r> At the end of day I've got some videos which look virtually perfect except some few frames that are AWFUL. [14:58:27 CEST] <JEEB> libvpx's rate control is known to be funky [14:58:29 CEST] <JEEB> have fun :) [14:58:32 CEST] <t3st3r> (likely very low quantizer) [14:59:03 CEST] <t3st3r> So the real quation is: are there way to programmatically detect such frames and chop 'em out under software control? [14:59:14 CEST] <t3st3r> and could ffmpeg do that? :D [15:00:04 CEST] <JEEB> nothing is impossible but do you really want to be working around libvpx's rate control in FFmpeg's wrapper or in your own API client :P [15:01:03 CEST] <t3st3r> No, I don't want to work it around :). Seems thx to google dev pages and #vp8 I got idea I know how to make it more or less behave. [15:01:48 CEST] <t3st3r> But I did few captures where I boxed rate-control decision pretty badly - and it elected to make perfect sequence at expence of few totally borkz0r3d frames :D [15:02:27 CEST] <t3st3r> I'm 100% fine with just throwing these away (as they cause very unpleasant "oscillation" but I'm not sure how to detect 'em software way. [15:02:38 CEST] <t3st3r> (and if ffmpeg can do it) [15:02:53 CEST] <JEEB> theoretically everything is possible with enough code, the question is whether it's worth the while [15:03:18 CEST] <JEEB> also if your results are due to boxing the rate control too much then maybe that should be tweaked instead :P [15:03:32 CEST] <JEEB> or if there's a global "don't use quantizer higher/lower than X" option in libvpx [15:03:35 CEST] <JEEB> :P [15:03:43 CEST] <t3st3r> Hmm good answer. I've hoped it could be done by just ffmpeg commands. Say some filter "if ...quantizer is bogusly high ... drop it" [15:04:17 CEST] <t3st3r> I've ofc tweaked it - but I have some captures I don't stand chance to recapture :D [15:04:47 CEST] <JEEB> also the problem is if some other picture used that as reference [15:04:52 CEST] <JEEB> that's now completely broken [15:04:55 CEST] <t3st3r> at which point I've both sorted out bitrate control but also 2nd part is fixing what I already had. [15:05:16 CEST] <JEEB> also I'm not sure if dropping random packets is OK in VP9; I don't remember if the coding engine's state is dependant on the pictures in the GOP [15:05:27 CEST] <JEEB> you should ask the libvpx/VP9 folk regarding that to begin with :P [15:05:36 CEST] <t3st3r> <JEEB> also the problem is if some other picture used that as reference <- not seems so. Somehow it did full-frames with very low Q [15:05:55 CEST] <JEEB> otherwise even if you take a bad picture out, you might just cause regressions until the end of GO [15:05:58 CEST] <JEEB> *GOP [15:06:16 CEST] <t3st3r> er I mean it used very high q, so frame is grossly overcompressed and looks like tetris. But all frames around are fine. [15:06:30 CEST] <t3st3r> (so bitrate control did really strange way of controlling bitrate) [15:07:19 CEST] <t3st3r> so most obvious idea would be just drop these few offending frames and re-encode rest using more sane parameters :) [15:08:32 CEST] <t3st3r> I've failed to find major damage on other frames - seems to be localized to certain frames - just them alone. I'd be damned, never seen such way to control bitrate in my whole life. [15:09:45 CEST] <t3st3r> technically idea to notice you've exceeded allowed bitrate and grossly overcompress few frames is valid, but result looks ... strange. [15:15:47 CEST] <t3st3r> I would surely use more sane bitrate control next time. Yet fixing few movies is an issue. Can ffmpeg filters see quantizers? -vf select is almost what I need. Except I can't readily formulate drop criterion. [19:58:14 CEST] <Atlenohen> Hi [19:58:30 CEST] <Atlenohen> Does x264 even support GOP = 1 ? [19:59:02 CEST] <Atlenohen> I get High Intra(a)L4.2 [19:59:29 CEST] <Atlenohen> But the quality quicly boggles down to sometihng like worse than old nokia phone quality [19:59:57 CEST] <Atlenohen> bitrate at 3000 kbps at around 1200x900 [20:01:18 CEST] <furq> just because it's intra-only doesn't mean it'll look good [20:01:33 CEST] <furq> you still need to set appropriate quality settings [20:03:54 CEST] <Atlenohen> Any other way to improve seeking then without having this quality destroying effect? [20:04:22 CEST] <furq> use a higher bitrate [20:05:02 CEST] <Atlenohen> Oh, okay, just checking if such a low GOP may be breaking some things, compat, stability ? [20:05:17 CEST] <Atlenohen> maybe i could use 2,4 later on but we'll see [20:05:30 CEST] <furq> i assume it has lower compatibility if it's using one of the intra profiles [20:05:37 CEST] <furq> it obviously has a very negative effect on compressibility [20:06:18 CEST] <furq> i assume you're doing this to feed into an NLE or something [20:08:44 CEST] <Atlenohen> No rush tho I can play with it and see what I like, oh and I just played them with MVP this time, didn't test with other players yet [20:13:48 CEST] <Atlenohen> It feels a bit better but the longer video plays the worse it gets [20:50:59 CEST] <kepstin> Atlenohen: most of the efficiency of codecs like h264 comes from its ability to use predicted frames (P,B frames). if you turn that off by setting -g 1 then either your video will be *much* lower quality at the same bitrate, or it'll be *much* larger [20:51:24 CEST] <kepstin> the gradual quality loss in 1-pass encode mode with bitrate set is just the bitrate controls taking a while to adapt to the situation. [20:51:47 CEST] <kepstin> (if you did a 2-pass encode, the video would be consistently low quality) [20:53:58 CEST] <kepstin> rather than setting gop size to 1, you'll normally want to compromise between seekability and file size. The default gop size for x264 is very large - lowering it down to ~1 second (e.g. -g 30 in a 30fps video) might be worth trying. [21:27:49 CEST] <Atlenohen> kepstin: thanks for the explanation, I'll have to figure out the basics yes, aren't intra frames full ones or I have mistaken them? [21:28:31 CEST] <kepstin> intra frames refers to frames that can be decoded on their own, without referring to data from other previously decoded frames. [21:28:37 CEST] <Atlenohen> kepstin: efficiency in compression, efficency in encoding, that's different then, if it's just compression, then it just be a size thing, not a quality one but I goess it's a bit more complicated [21:29:39 CEST] <kepstin> when referring to "efficiency" of a video codec, that almost always refers to "the bitrate required to achieve a certain quality level" [21:31:06 CEST] <kepstin> note that x264 has an encoding mode (using the "crf" parameter) where you can (approximately) set a quality level you want, and let the encoder choose the bitrate required to achieve that. [21:31:33 CEST] <kepstin> in many use cases, that's preferred over setting a bitrate [21:32:03 CEST] <Atlenohen> Oh, this is an older implementation that uses fixed bitrate, not crf, I do actually know a thing about video transcoding since I did a lot of archiving in the past but I have to refresh some memory [21:32:49 CEST] <Atlenohen> So I'm modifying the implementation, the ffmpeg api has probably changed since this was initially designed [21:34:46 CEST] <Atlenohen> Oh 0 is for intra only, interesting. [21:40:22 CEST] <cahoots> hi, do i need to pay royalties or anything if using ffmpeg's h.264 encoder? [21:42:13 CEST] <kepstin> cahoots: ffmpeg doesn't include an h264 encoder, it normally uses the implementation from the x264 library [21:42:38 CEST] <kepstin> cahoots: nobody here can give you a definitive answer on whether you need to pay patent royalties. [21:45:23 CEST] <JEEB> cahoots: for software licensing the open source licenses under which we have modules (LGPL and/or GPL) are rather simple. if you're talking about patent licensing then unfortunately you will not find an answer in here [21:48:43 CEST] <DHE> I would suggest googling "MPEG LA" and contacting your legal council [22:23:30 CEST] <cahoots> kk thanks [23:17:48 CEST] <phinxy> I can not get mp3 encoding recognized. There is a /usr/lib/libmp3lame.so and I've configured with --extra-cflags='-I/usr/include --enable-libmp3lame'. Could the reason ffmpeg does not find the lame encode have something to do with the error "WARNING: Libarary configuration mismatch"? avutil, avcodec, avformat does not have the extra --enable-libmp3lame flag (WHY NOT?). [23:20:24 CEST] <kepstin> phinxy: you should not need to set extra-cflags - you need to ensure your distribution's devel package for the lame library (which includes headers and pkg-config file) is installed [23:20:48 CEST] <kepstin> phinxy: what command are you running that gives this library configuration mismatch error? [23:22:07 CEST] <BtbN> --enable-libmp3lame inside of extra-cflags is also not going to do any good [23:22:46 CEST] <phinxy> BtbN: Right -- It's not in the cflags [23:22:58 CEST] <kepstin> phinxy: in your paste it was in the cflags [23:24:10 CEST] <kepstin> (if you copy-paste text, please copy-paste it rather than retyping where possible to avoid typos, since that can really affect the meaning of the command) [23:24:15 CEST] <phinxy> Let me get you the corrent ./configure flags I have used: https://termbin.com/q652e [23:25:17 CEST] <kepstin> right, that looks fine. what does the output of ./configure with those options look like? [23:25:42 CEST] <kepstin> although note that you shouldn't ever have to specify -I/usr/include [23:26:15 CEST] <kepstin> because the include paths are loaded from pkg-config and set automatically [23:27:15 CEST] <kepstin> if that doesn't work, it usually means that you need to install the -dev or -devel package from your distro (e.g. on ubuntu "apt-get install libmp3lame-dev" [23:28:15 CEST] <kepstin> also note that after re-running configure with changed options, it's sometimes a good idea to "make clean" and do a fresh build (even tho that'll be pretty slow on a little arm box like that...) [23:29:40 CEST] <kepstin> also, raspberry pis make terrible media processing platforms, when people come around with problems with them, the best advice is often "get a faster computer" :( [23:30:46 CEST] <phinxy> Perhaps the installation of libmp3lame was not correctly done. I might have put the headers in the wrong place or something [23:34:06 CEST] <phinxy> I recall having difficulty compiling libmp3lame so I fetched the .so and the single header file from a ftp server. [23:34:47 CEST] <kepstin> doesn't the distro you're running have it packaged? [23:35:39 CEST] <phinxy> I just checked ftp.slackware.org.uk/slackwarearm-14.2 , cant find it [23:36:07 CEST] <phinxy> hmm my package manager have it. [23:36:14 CEST] <phinxy> why have I not installed it from there? [23:37:25 CEST] <phinxy> I might have wanted to compile it "for fun" with my own configuration options. I'll try get it from the package manager without overwriting the previous, customized version. [23:39:10 CEST] <c_14> phinxy: what's the actual error you're getting [23:43:21 CEST] <phinxy> c_14: https://termbin.com/hrlc https://termbin.com/rtwi [23:44:34 CEST] <c_14> looks like you built a shared ffmpeg binary and it's linking against your system builds at runtime [23:44:57 CEST] <c_14> either rebuild static (--disable-shared) or use LD_RUNTIME_PATH to set the correct lib path [23:50:37 CEST] <phinxy> output of ./configure says "static yes" and libmp3lame is listed under External libraries. https://termbin.com/rjvg [23:51:49 CEST] <c_14> I'm not entirely sure what the preference is when both are enabled, you can always check by running `ldd' on the ffmpeg binary and checking if it links the libav* libraries [23:51:56 CEST] <c_14> s/links/lists/ [00:00:00 CEST] --- Tue Apr 16 2019

1 0

ffmpeg-devel.log.20190414
by burek 15 Apr '19

15 Apr '19

[00:04:37 CEST] <cehoyos> michaelni: Patch sent [01:08:04 CEST] <cone-831> ffmpeg 03Michael Niedermayer 07master:0ad0533e914a: avcodec/truemotion2: Fix integer overflow in tm2_decode_blocks() [01:37:59 CEST] <cehoyos> michaelni: So is the patch ok or do I misunderstand? [01:43:59 CEST] <michaelni> cehoyos, i think if you want to maintain the unused C64/FIX64 code working without changing it then uint16 instead of int16 is needed or some other change [01:45:07 CEST] <michaelni> C64() does not work with a negative signed argument as it is implemented ATM [01:46:12 CEST] <cehoyos> I didn't change C64() or did I? [01:47:45 CEST] <cehoyos> And FIX64 is unused [12:49:06 CEST] <faLUCE> Hello. When patching makefiles, how can I re-indent? I was told to avoid TABs [12:56:07 CEST] <thilo> IIRC Makefiles are an exception to the no-tabs rule for their syntax [12:58:12 CEST] <faLUCE> thilo: yes, in factI read "The TAB character is forbidden outside of Makefiles as is any form of trailing whitespace. Commits containing either will be rejected by the git repository." [12:59:12 CEST] <atomnuker> use spaces. [12:59:14 CEST] <faLUCE> thilo: but carl suggested yesterday to avoid re-indentation of makefiles [12:59:22 CEST] <atomnuker> yes, use spaces. [12:59:26 CEST] <faLUCE> atomnuker: ok thanks [13:13:34 CEST] <faLUCE> when a patch includes ffmpeg/dir1/file1 and ffmpeg/dir2/file2, which is the command for making one patch that includes both the modified files? [13:13:51 CEST] <faLUCE> (on the master) [13:17:43 CEST] <JEEB> git add dir1/file1 dir2/file2 [13:17:50 CEST] <faLUCE> thnx [13:17:51 CEST] <JEEB> git commit [13:18:18 CEST] <JEEB> then mkdir -p patches/ && git format-patch -o patches REMOTE/master..HEAD [13:18:24 CEST] <JEEB> REMOTE is usually by default origin [13:18:58 CEST] <JEEB> and generally it probably is worth it to make your own work-in-progress branch that your local master isn't with your own changes [13:20:41 CEST] <faLUCE> JEEB: wait, too many things :-) . 1) [13:18] <JEEB> then mkdir -p patches/ && git format-patch -o patches REMOTE/master..HEAD <--- what exactly does this command? [13:22:27 CEST] <JEEB> faLUCE: the && runs the other one if the first one succeeds. so you make a directory called "patches", and then the -o parameter in format-patch outputs there [13:23:01 CEST] <JEEB> and the REMOTE/master..HEAD part takes the hash of REMOTE/master and outputs patches for all commits that are locally in your tree until HEAD [13:23:06 CEST] <JEEB> HEAD being the current working tree tip [13:24:05 CEST] <JEEB> you can take a look at what `git show HEAD` outputs as an example [13:27:35 CEST] <faLUCE> JEEB: OK, but given that I would not use git-send-email, where the email info, description of the patch etc. well be put? [13:27:44 CEST] <JEEB> format-patch outputs that [13:28:20 CEST] <JEEB> git diff outputs a simple patch without authorship/commit message etc [13:28:34 CEST] <JEEB> git format-patch outputs proper `git am`'able commits [13:48:31 CEST] <faLUCE> ok JEEB, thnks, I have to learn more about that [14:19:05 CEST] <JEEB> does anyone remember if VP9 kept state over RAPs? [14:19:19 CEST] <JEEB> so if you just try to cut a VP9 stream over RAPs that you could get corruption [14:19:32 CEST] <JEEB> or more specifically, starting with a RAP in the middle of the stream [14:39:21 CEST] <jkqxz> A key frame in VP9 clears all state. [14:39:41 CEST] <JEEB> ok, so cutting and then stitching on a RAP should be OK then [14:40:06 CEST] <JEEB> I don't remember which format I was talking about where this was not true and the coder state was dependant on previous frames [14:40:16 CEST] <JEEB> on of the VPx or AV1 [14:40:34 CEST] <jkqxz> Nothing would stop you marking a non-key intra-only frame as a RAP in VP9, but I don't think anyone does that. [14:41:05 CEST] <BBB> av1 has invisible keyframes [14:41:10 CEST] <BBB> which don't clear state until they become visible [14:41:15 CEST] <BBB> as a show-existing-frame reference [14:41:20 CEST] <BBB> and then hevc also of course [14:41:22 CEST] <JEEB> yea, I was mostly considering correctly mapped pictures [14:41:54 CEST] <JEEB> ok, then I wonder why I remember there being a thing about not being able to cut some formats [14:42:09 CEST] <JEEB> thanks [14:43:47 CEST] <jkqxz> H.26[45] both allow non-decodable leading pictures before a non-IDR RAP (and H.265 explicitly marks them with a different NAL unit type). [14:43:59 CEST] <JEEB> yup [14:47:46 CEST] <atomnuker> BBB: so an encoder could in theory fill all invisible frame slots and then never show them even after a keyframe? [14:49:12 CEST] <atomnuker> I seem to remember that was because of some closed gop thing, but having a broken file hog decoder memory isn't cool [14:49:44 CEST] <BBB> yes [14:49:46 CEST] <jkqxz> Showing a key frame clears all frame slots at the point it is shown. [14:49:47 CEST] <BBB> it's a delayed clear-state [14:50:07 CEST] <BBB> you can do all sort of weird stuff with this [14:50:15 CEST] <BBB> but mostly it's both dumb and innocent [14:50:23 CEST] <BBB> so it's ok I guess [14:50:29 CEST] <BBB> it's not like you can break your hardware or something [14:53:14 CEST] <atomnuker> well, filling all ref frame slots is difficult to do in av1 in the first place, so yeah, not much danger [14:55:20 CEST] <atomnuker> the sequence and naming was something completely illogical, and I'm too lazy to dig up the 2 crazy flowcharts google made to further confuse everyone [14:55:46 CEST] <durandal_1707> atomnuker: what's up? [14:55:47 CEST] <JEEB> anyone wants to look at a supposed sample of 22.2ch LATM AAC? [14:56:46 CEST] <atomnuker> durandal_1707: trying to fully complete gta san andreas [14:56:59 CEST] <JEEB> that's a fun one [14:57:17 CEST] <JEEB> not 100% sure it's valid since the provider isn't sure of the crypto but it does get as far as noting that multiple programs are not yet supported [14:59:18 CEST] <durandal_1707> atomnuker: stop wasting time on stupid games [15:20:49 CEST] <cone-372> ffmpeg 03Steven Liu 07master:b18c8688dd4f: avformat/hlsenc: flush packets before update split message [18:10:57 CEST] <philipl> JEEB, haasn: So this crap is harder than it looks. If I rename the ta_* functions from xtalloc, it will compile. I couldn't do a full static mpv build because many of the dependencies don't have static versions in Ubuntu. So I tried just linking a static libplacebo. [18:12:02 CEST] <philipl> That actually linked after the renames, but blows up at runtime because there are symbol conflicts with spriv_shader.c which exists in both code bases. Strangely it doesn't fail at link time. [18:12:13 CEST] <philipl> but it ends up calling the mpv version which then fails - no surprises. [18:12:26 CEST] <JEEB> probably wrong channel but ouch :/ [18:12:38 CEST] <philipl> whoops. [18:12:43 CEST] <philipl> I will repeat in the right channel. [20:55:31 CEST] <cone-285> ffmpeg 03James Almer 07master:62074b8f85e0: avcodec/cbs_av1: add a function to strip trailing zeroes from a buffer size [20:55:32 CEST] <cone-285> ffmpeg 03James Almer 07master:1f260d7285c8: avcodec/cbs_av1: add support for Padding OBUs [21:22:58 CEST] <thardin> so I'm staring at mxf_read_sync() and it seem it'll behave incorrectly for any UL which contains 0x06 in places beyond index 0 [21:25:37 CEST] <thardin> baptiste: do we have any sample that uses say mxf_crypto_source_container_ul[] ? [21:27:04 CEST] <baptiste> Im afraid not :( [21:27:43 CEST] <thardin> mxf_sony_mpeg4_extradata as well [21:28:01 CEST] <thardin> ah but that has a fate sample. hmmm [21:28:49 CEST] <thardin> I *really* don't like that sync thing being used for anything besides run-in [21:33:40 CEST] <thardin> I see it works because both of those are local tags [22:57:42 CEST] <thardin> hum hum.. who in here had knowledge about protools again? [23:13:53 CEST] <jamrial> jkqxz: adding support for Scalability Metadata obu to cbs_av1 should be trivial, but it will probably increase the struct size considerably [23:13:58 CEST] <jamrial> do you think it's worth doing? [23:14:58 CEST] <jkqxz> Have you found anything which uses it? [23:15:18 CEST] <jamrial> no, that's why i'm not sure it's worth implementing it :p [23:15:38 CEST] <jamrial> although something has to be first, right? :p [23:16:10 CEST] <jkqxz> Yeah, that was my position too. [23:16:36 CEST] <jamrial> the couple samples i saw using more than one spatial/temporal layers didn't have it [23:17:23 CEST] <jkqxz> If you want to do it then go ahead, but I'm happy to wait and see if anyone ever uses it. [23:17:49 CEST] <jamrial> i wouldn't mind if it wasn't so big. the struct will be like 8kb alone [23:19:06 CEST] <jkqxz> How big is the current largest thing in the OBU union? [23:20:45 CEST] <jkqxz> If all the stuff in frame header is already bigger than that then it doesn't make a difference. [23:23:55 CEST] <jamrial> let me check [23:24:25 CEST] <jamrial> biggest is frame, 1k [23:28:58 CEST] <cone-285> ffmpeg 03Marton Balint 07master:f9840cd2b501: avformat/mxfdec: use operational_pattern_ul instead of operational_pattern for metadata [23:48:01 CEST] <jamrial> jkqxz: my bad, with the new struct it will be ~3k, no 8k [23:48:08 CEST] <jamrial> considerably bigger than frame still, but not that bad [00:00:00 CEST] --- Mon Apr 15 2019

1 0

ffmpeg.log.20190414
by burek 15 Apr '19

15 Apr '19

[00:02:12 CEST] <cehoyos> JEEB: For dst, this is not a question of the "information", our decoder provides the audio with this sample rate (which is different from the one in the white paper or advertising), it cannot be changed. The same is true for some SBR files. [00:04:08 CEST] <JEEB> yes [00:04:16 CEST] <JEEB> I was mostly just responding to the question asked [00:04:38 CEST] <JEEB> regarding a decoder showing the wrong rate after probe() was done [00:05:00 CEST] <JEEB> dst is of course its own bundle of fun :) [00:05:00 CEST] <cehoyos> I finally realize there is a usecase for mediainfo ;-) [00:05:15 CEST] <cehoyos> (Or a fundamental problem about ffprobe) [00:15:28 CEST] <garyserj> I have two mp4 files, I made examples files, each one second. One uploads to youtube, one does not. If I look at the profile of each on mediainfo, I see that the bad one has encoding settings and writing library, and the good one does not. I am able to import the bad one into movie maker, and save it, and it becomes good, and has no encoding settings or writing library listed by mediainfo. [00:15:28 CEST] <garyserj> I'd like to do that with ffmpeg though. How can I do that? this is the profile of the bad mp4 https://pastebin.com/raw/XD5YnaLg and this is the profile of the good mp4 https://pastebin.com/raw/b5xqFLxy [00:16:43 CEST] <JEEB> garyserj: neither of those flags most likely has anything to dow ith whether youtube takes it in or not [00:16:53 CEST] <JEEB> otherwise everyone would have to run a patched libx264 [00:17:24 CEST] <cehoyos> garyserj: Instead please provide the command line that you used to produce the "bad" file together with the complete, uncut console output. [00:19:10 CEST] <garyserj> cehoyos: ok that will take a while.. i'll reply when done! [00:25:40 CEST] <Atlenohen> standby ... will report findings soon [00:33:21 CEST] <garyserj> thanks for waiting. here is the output of mp4 that won't upload to youtube https://pastebin.com/raw/9ap6bMfe [00:33:51 CEST] <JEEB> > 1348290000.00 tbn [00:34:07 CEST] <JEEB> this sounds like something that might cause issues down the line if it gets written into the output container [00:35:47 CEST] <garyserj> a)what does it mean b)movie maker was able to import the file and save it and the saved file uploaded to youtube. How might I 'fix' it witih ffmpeg like movie maker did? [00:36:27 CEST] <JEEB> well if it decoded and re-encoded your thing it most likely limited the time base, while somehow ffmpeg.c ended up with a humongous time base there [00:36:55 CEST] <JEEB> given that the input time base is 90k it sounds funky at the very least [00:37:43 CEST] <garyserj> so is there a flag in ffmpeg to limit the timebase or is this a bug in ffmpeg that has no flag to fix? [00:37:50 CEST] <garyserj> (or both) [00:39:16 CEST] <JEEB> I would first check a newer version of FFmpeg [00:39:21 CEST] <JEEB> since you're on 3.4 [00:39:32 CEST] <JEEB> you can find current master builds from zeranoe's for example [00:40:38 CEST] <garyserj> another odd thing is I reckon the phone i recorded the 3gp on has been oriented the correct way, yet some videos come out needinig a vflip and some needing a -vf "transpose=1" (clockwise 90 degree turn), and most don't need any turn or flip [00:40:44 CEST] <garyserj> this one didn't need any turn or flip [00:41:31 CEST] <JEEB> mobile camera stuff is fun :P [00:41:52 CEST] <garyserj> I can understand the case of vflip 'cos maybe it's possible i oriented my rectangular phone the wrong way. but 90 degrees is very strange 'cos don't place my camera on one of its small edges [00:42:04 CEST] <garyserj> 'cos don't = 'cos I don't [00:42:16 CEST] <JEEB> yea but the software might still think you're in some other mode [00:42:21 CEST] <JEEB> fun for the whole family [00:42:36 CEST] <JEEB> of course, I'm just guesstimating without knowing more about it [00:43:48 CEST] <JEEB> also the weird time base is probably due to the content being of non-constant rate (mobile phones generally tend to record "as fast as possible with a cap". so you might be hitting that cap (say, 30Hz) or something lower than that [00:43:59 CEST] <JEEB> although I'm just guesstimating without knowing the details [00:44:33 CEST] <garyserj> zeranoe has 'builds' i'm just downloading one it's about 60MB! [00:45:20 CEST] <cehoyos> I suspect the input file is vfr, I suggest you force an output frame rate with "-r 30000/1001" [00:45:31 CEST] <cehoyos> This will force a sane time base [00:45:56 CEST] <JEEB> yes, that is what I was alluding to with the long and winding explanation about mobile phone cameras recording at a non-static rate :) [00:46:07 CEST] <JEEB> "as fast as possible, with a cap" basically [00:46:07 CEST] <cehoyos> Yes, I hadn't read so far, sorry [00:46:29 CEST] <JEEB> although it's still weird so it would be interesting to know if current master handles it any better [00:46:46 CEST] <JEEB> and considering the input has 90k time base for the stream, it's kind of weird how it goes worse from that [00:46:47 CEST] <cehoyos> But thank you for proving that "complete, uncut console output missing" is still the key to such issues;-) [00:46:59 CEST] <JEEB> often it is :) [00:47:05 CEST] <JEEB> sometimes you end up needing a bit more [00:47:21 CEST] <cehoyos> I don't really expect it to work better but a test won't hurt. [00:47:32 CEST] <cehoyos> garyserj: Feel free to provide the input sample [00:47:35 CEST] <JEEB> yea, I don't think the code around there changed too much [00:47:47 CEST] <JEEB> but since there are binaries available, the test shouldn't take too long :) [00:47:57 CEST] <cehoyos> True! [00:48:19 CEST] <JEEB> also funny enough there should be a time base option both in ffmpeg.c as well as in movenc.c [00:48:28 CEST] <JEEB> so in theory one could set it to the input time base (90k) [00:48:31 CEST] <JEEB> to get a similar result [00:49:27 CEST] <cehoyos> Maybe "-r 24000/1001": Check if many frames are dropped with this value [00:49:47 CEST] <cehoyos> I think the correct solution is to force a sane frame rate [00:50:39 CEST] <JEEB> I would think a similar time base should most likely work (since 90k is used in mpeg-ts and youtube has to be taking in content straight from these devices). but yes, either vf fps=30000/1001 or -r 30000/1001 should make sure the output is of constant rate :) [00:51:05 CEST] <JEEB> (the options in ffmpeg.c are -time_base and -enc_time_base btw) [00:51:46 CEST] <JEEB> movenc.c has video_track_timescale AVOption [00:51:51 CEST] <JEEB> just for the record :) [00:52:27 CEST] <garyserj> https://pastebin.com/raw/7dTEv0by [00:52:50 CEST] <JEEB> garyserj: thanks. so yea, the logic that leads to that value is still there :) [00:53:32 CEST] <JEEB> if you are re-encoding you might attempt what cehoyos noted regarding setting output rate of 30000/1001 [00:53:39 CEST] <JEEB> which is seemingly the cap in your sample [00:54:11 CEST] <JEEB> or then if you don't want to do that, you can attempt setting the time bases for that output stream. setting the frame rate is simpler [00:54:32 CEST] <JEEB> and if you could share the sample, that could be lovely [00:54:32 CEST] <garyserj> okay, i'm an ignoramous with ffmpeg, what'd be the flag for that? And what might movie maker be using if not ffmpeg? [00:54:50 CEST] <JEEB> no idea, and it might be forcing the rate by default [00:54:58 CEST] <JEEB> since usually video editors don't output variable frame rate [00:55:03 CEST] <JEEB> (even if the input is) [00:55:39 CEST] <garyserj> so i guess i'd need the flag for setting a set frame rate [00:56:03 CEST] <garyserj> is that a 'no dea' for the second question only? [00:56:11 CEST] <garyserj> (sorry, my 'i' key is rubbish) [00:56:22 CEST] <garyserj> dea=idea [00:56:40 CEST] <JEEB> the no idea is regarding whether the thing you're talking about is also using FFmpeg in some capacity [00:56:58 CEST] <garyserj> i'd assume not [00:57:08 CEST] <garyserj> but i'm wondering what alternatives there are that software uses [00:57:11 CEST] <cehoyos> Didn't I already provide the missing "flags"? [00:57:24 CEST] <garyserj> ah ok [00:57:27 CEST] <JEEB> and setting a video frame rate can be done in two ways. either -r "30000/1001" or -vf "fps=fps=30000/1001" [00:57:42 CEST] <cehoyos> Actually not [00:57:53 CEST] <garyserj> cehoyos: yeah -r 30000/1001 [00:57:56 CEST] <JEEB> you did note the rate setting twice :) [00:57:58 CEST] <cehoyos> The second variant won't tell you if it wasn't necessary to choose such a high value [00:58:34 CEST] <cehoyos> Look at "dups", if it increases constantly, choose a lower number [00:58:39 CEST] <garyserj> okay i will try that [00:58:45 CEST] <JEEB> also the 90k time base seems to be a common thing with android [00:58:50 CEST] <JEEB> my sample from last year has that too [00:58:57 CEST] <cehoyos> If it only duplicates for the first second(s) and then stays (nearly) constant, the value is ok [01:00:55 CEST] <garyserj> https://pastebin.com/raw/zrzkSJnA [01:01:24 CEST] <JEEB> my sample ends up with "only" 22500 AVStream time_base :) [01:01:33 CEST] <garyserj> ah the file example is only one second long. But the problem exists for a three second file too or for larger [01:01:55 CEST] <cehoyos> Remove "-t 1" [01:02:07 CEST] <garyserj> how many seconds do you need? [01:02:16 CEST] <cehoyos> Yes but with the one second sample you don't know a useful value for -r. [01:02:27 CEST] <cehoyos> As many as your input has [01:02:53 CEST] <cehoyos> You can use "-f null -" instead of "-vcodec libx264 outputfilename.mp4" [01:02:57 CEST] <garyserj> okay! i'll just remove the -ss and -t completely. this will take longer. [01:03:00 CEST] <cehoyos> To speed up the process [01:03:03 CEST] <cehoyos> If you need [01:03:44 CEST] <garyserj> and isntead of -acodec i guess? [01:03:58 CEST] <garyserj> so no vcodec no acodec no output filename but -f null - [01:04:56 CEST] <garyserj> and i guess i keep the -r "30000/1001" [01:04:57 CEST] <cehoyos> "ffmpeg -i input -acodec copy -r 30000/1001 -f null -" [01:05:08 CEST] <garyserj> ffmpeg -i Apr__8_2019_WLC_C_3.3gp -f null - -r "30000/1001" [01:05:13 CEST] <cehoyos> No [01:05:41 CEST] <cehoyos> ffmpeg -i Apr__8_2019_WLC_C_3.3gp -acodec copy -r 30000/1001 -f null - [01:05:55 CEST] <JEEB> yea, the remux-only -r patch I think is still on the ML [01:06:56 CEST] <cehoyos> It wouldn't help [01:06:57 CEST] <garyserj> I am getting a lot of lines like [null @ 00000000004b8fc0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 6443 >= 6443 and each time the number increases I will show the full output on pastebin link [01:07:28 CEST] <JEEB> cehoyos: yea it would just break the A/V sync of VFR input :) [01:08:46 CEST] <garyserj> https://pastebin.com/raw/EnxTqCJv [01:09:14 CEST] <cehoyos> Sorry, the command was wrong;-( [01:09:33 CEST] <cehoyos> Should have been: ffmpeg -vsync cfr -i Apr__8_2019_WLC_C_3.3gp -acodec copy -r 30000/1001 -f null - [01:09:42 CEST] <cehoyos> But don't worry, we can calculate the issue... [01:09:57 CEST] <garyserj> ok, running now, thanks [01:10:43 CEST] <cehoyos> 30000/1001 is correct [01:10:46 CEST] <garyserj> https://pastebin.com/raw/GgECKThL [01:11:17 CEST] <cehoyos> The device just needed to "warm up", it could then keep the high framerate [01:12:00 CEST] <cehoyos> I wonder if it is a bug that ffmpeg is trying to produce vfr output with "-r"... [01:12:13 CEST] <cehoyos> May be a regression [01:12:15 CEST] <JEEB> quite possible [01:12:22 CEST] <cehoyos> Sounds like one to me [01:13:06 CEST] <garyserj> heh, sounds like a star trek conversation ;-) [01:15:01 CEST] <garyserj> good stuff. hmm , I can't see an 'issues' section on the ffmpeg github page [01:15:10 CEST] <garyserj> I see bug reports link n topic, i'll check there [01:16:45 CEST] <cehoyos> Why are you interested in that topic if I may ask? [01:17:20 CEST] <cehoyos> To quote myself: Feel free to provide a sample... [01:17:27 CEST] <garyserj> well, if there's a bug in ffmpeg then I want to help resolve it [01:17:36 CEST] <cehoyos> Feel free to provide a sample [01:17:41 CEST] <garyserj> also sometimeis something is said that I don't understand now but understand later [01:17:55 CEST] <JEEB> the android mp4 samples I have seem to max out in more pleasant time bases :) [01:18:04 CEST] <JEEB> so definitely something interesting in that one [01:19:35 CEST] <garyserj> The other 3gp files I had did upload, but is it possible they had the same issue? [01:19:57 CEST] <garyserj> like the other 3gp files i had did convert to an mp4 that uploaded, but is it possible they had the same issue? [01:20:23 CEST] <garyserj> i'd rather make a new video, 'cos that one did have some peoples' faces in t [01:20:47 CEST] <garyserj> the first second didn't have anybodys' faces but seconds beyond that did [01:21:00 CEST] <cehoyos> The first second is enough [01:21:44 CEST] <Atlenohen> ... Takes a bit long to make it really nice and clear ... [01:21:58 CEST] <garyserj> ffmpeg -i -ss 0 -t 1 Apr__8_2019_WLC_C_3.3gp -acodec copy -vcodec copy sample.3gp <-- that ok? [01:22:03 CEST] <cehoyos> NO!!! [01:22:03 CEST] <garyserj> ah mean [01:22:10 CEST] <garyserj> ffmpeg -iApr__8_2019_WLC_C_3.3gp -acodec copy -vcodec copy -ss 0 -t 1 sample.3gp [01:22:15 CEST] <garyserj> with space after -i [01:22:24 CEST] <cehoyos> Either provide an input file not created with FFmpeg (!), or feel free not to provide a sample file [01:22:32 CEST] <faLUCE> cehoyos: instead of making re-indentation on the makefiles, how should they formatted? by adding spaces? [01:22:42 CEST] <cehoyos> Don't change it [01:23:10 CEST] <faLUCE> cehoyos: and what if they appear badly formatted? [01:23:21 CEST] <cehoyos> Then send a second patch that fixes the indentation. [01:24:15 CEST] <faLUCE> uhmmm but why the indentation can't be changed in the first patch? [01:24:16 CEST] <garyserj> okay so let's say i don't proviide a sample. Shall I just provide this line and its output ffmpeg -vsync cfr -i Apr__8_2019_WLC_C_3.3gp -acodec copy -r 30000/1001 -f null - [01:24:37 CEST] <garyserj> What commands with output, should I provide? [01:25:20 CEST] <garyserj> is this chat log sufficient? [01:27:01 CEST] <garyserj> here http://ffmpeg.org/bugreports.html they say if the sample file is too large, cut it down e.g. dd if=sample-file of=small-sample-file bs=1024 count=10000 [01:27:07 CEST] <garyserj> I can cut it down to 1 second with a line like that [01:31:12 CEST] <cehoyos> Please do that, than test the sample (this is very important!), then provide it [01:33:12 CEST] <cehoyos> If you decide to open a ticket (as I tried to imply, it may be better to just provide a sample), please do not share a chat log there, please do not open a ticket if you cannot provide a sample file, please test your sample file before uploading it and please don't forget to provide the command line you tested together with the complete, uncut console output, only current FFmpeg git head is supported [01:34:07 CEST] <garyserj> ok, thanks [01:36:47 CEST] <cehoyos> will you provide the sample now? If not, I will see the link in 24 hours [01:37:12 CEST] <garyserj> yeah i'll provide a sample now, just running the dd command, thanks [01:37:24 CEST] <garyserj> just fixing my path so i can run the dd command. i have some path issues! [01:41:43 CEST] <garyserj> I just made a 1MB sample with dd, dd if=Apr__8_2019_WLC_C_3.3gp of=sample.3gp bs=1024 count=1000 And even VLC won't play it [01:42:43 CEST] <cehoyos> You have to use tools/qt_faststart before using dd [01:43:02 CEST] <garyserj> i've used dd before, but not that, i'll look into that [01:43:45 CEST] <cehoyos> Just post your link here, I will see it a day later. [01:43:50 CEST] <cehoyos> Good night [01:43:52 CEST] <garyserj> okay, thanks [01:43:57 CEST] <garyserj> i'll make a 100KB sample [01:43:59 CEST] <garyserj> that's about 1 second [01:44:14 CEST] <garyserj> without the qt.. i'll be here this week too [01:44:24 CEST] <garyserj> gnight [01:44:30 CEST] <garyserj> and will post here [01:45:33 CEST] <garyserj> http://ge.tt/5JDvaYv2 [01:45:50 CEST] <garyserj> 102,400 sample1.3gp [01:49:00 CEST] <cehoyos> How did you test the sample you uploaded? [01:51:52 CEST] <garyserj> I haven't managed to test it yet 'cos I don't know the faststart command. And i'm not even sure how i'd test it for the timebase issue other than perhaps trying to run those commands on it and look for tb. but that's where I am at the moment. [01:52:09 CEST] <garyserj> sorry, should've tested it but can't yet. but i wanted to make sure you had something! [01:52:34 CEST] <garyserj> if i knew right now how to test it then i would [01:52:43 CEST] <cehoyos> Please do not provide a sample that you didn't test and please do not open a ticket without a sample! [01:52:53 CEST] <garyserj> okay. i haven't opened any ticket [01:53:03 CEST] <cehoyos> (And how is all this related to faststart??) [01:53:27 CEST] <garyserj> just that you mentioned to do qt_faststart before using dd. [01:53:33 CEST] <garyserj> but i don't know the command to do that [01:54:08 CEST] <cehoyos> tools/qt_faststart is a tool that you have to use before dd so that dd will not damage your file, faststart is an option for the mov (and mp4) muxer [02:01:47 CEST] <garyserj> can anybody advise how I can use tools/qt_faststart ? [02:05:23 CEST] <garyserj> ah i see it's fairly simple https://manpages.debian.org/stretch/ffmpeg/qt-faststart.1.en.html i just gotta get the program [02:07:43 CEST] <Atlenohen> Actually , build log proven to be useful [02:07:49 CEST] <Atlenohen> it just takes a good peek at it [02:09:59 CEST] <garyserj> I see it was integrated into ffmpeg [02:18:39 CEST] <garyserj> ffmpeg -i Apr__8_2019_WLC_C_3.3gp -codec copy -movflags +faststart largefixed.3gp Thus fixing it with faststart. I tried dd if=largefixed.3gp of=sample2.3gp bs=1024 count=1000 It plays. [02:18:47 CEST] <garyserj> here is the sample http://ge.tt/9CRTdYv2 [02:18:59 CEST] <garyserj> 1,024,000 sample2.3gp [02:48:13 CEST] <Atlenohen> btw, I found YOUTUBE to be broken with MP4 faststart, or ffmpeg aint doing it right (but it is confirmed with ffprobe), so I had to use MKV for YOUTUBE [02:51:34 CEST] <garyserj> Interestingly, when I made a sample file so dd, followed by faststart (I used the ffmpeg one), then I used the -vsync cfr line with -r ... that was given, so I Had a sample 3gp. Then I did the command I Had done to convert to mp4, the mp4 not only played fine and not only gave no tbn issue, but also, uploaded fine to youtube. [02:53:04 CEST] <garyserj> I mean.. When did dd followed by faststart(I used the ffmpeg one), then i used the -vsync cfr line with -r ... that was given, (But making a file rather than using -f null -). Then it played fine, gave no tbn issue , and most importantly, it uploaded fine to youtube. [03:18:54 CEST] <HickHoward> is Dolby AC-4 worth implementing into ffmpeg? [03:34:42 CEST] <garyserj> btw, I am not sure how I would verify the sample, but it played, and it failed to upload to youtube, so in that sense it's a good sample. [04:17:04 CEST] <furq> HickHoward: someone will implement it when they have something they want to decode with it [04:17:10 CEST] <furq> which is probably why nobody has done it yet [04:21:35 CEST] <HickHoward> well this is gonna suck [04:22:03 CEST] <HickHoward> but i don't mind waiting for that moment [07:29:17 CEST] <Atlenohen> solved it [07:29:20 CEST] <Atlenohen> report tomorrow, sleep [09:01:05 CEST] <dongs> JEEB: i have it, but i donno if decrypting it was correct. you're welcoem to the sample stream tho.https://mega.nz/#!cQsw3IAZ!VN8d_QSJDH0iu4isLqtfmX5yuy9Yjl6PGeJkMtegDzY [10:29:24 CEST] <Silicium> hi there [10:30:53 CEST] <Silicium> i dump images from a video using image2 but i want to change the output frame integer value by 20. how can i achieve that? [13:53:38 CEST] <howaboutsynergy> Can ffmpeg cut out multiple parts from an audio file with one command? eg. removing multiple ads [13:54:53 CEST] <howaboutsynergy> rather than using multiple ffmpeg invocations for each part to be removed using -ss and -to [13:54:54 CEST] <pink_mist> I would be extremely surprised if it couldn't [13:55:09 CEST] <howaboutsynergy> ok, can you tell me how? pink_mist [13:55:20 CEST] <pink_mist> no, if I knew how, I would have already done so [13:55:27 CEST] <howaboutsynergy> oh, right [13:55:30 CEST] <JEEB> you can probably do it with a filter but not with -ss / -t [13:55:32 CEST] <pink_mist> I'd check the ffmpeg-filters man pages [13:55:42 CEST] <howaboutsynergy> ok, let's check [13:55:43 CEST] <JEEB> which also means that you will have to re-encode [13:56:04 CEST] <howaboutsynergy> ohhh [13:56:05 CEST] <pink_mist> oh, well that's a bummer [13:56:24 CEST] <howaboutsynergy> yeah, I'd rather use multiple ffmpeg invocations than reencode [13:56:28 CEST] <pink_mist> unless you've got a lossless stream [13:56:44 CEST] <howaboutsynergy> nah, it's lossy [13:57:09 CEST] <howaboutsynergy> I don't need precision though, so -c copy would od [13:57:10 CEST] <howaboutsynergy> do* [13:57:38 CEST] <howaboutsynergy> ok then, thanks for the help, I'll stick to -ss and -to and multiple ffmpeg runs. [13:57:58 CEST] <howaboutsynergy> Oh, one more thing, this yields a bunch of parts, how would I merge them? [13:58:34 CEST] <howaboutsynergy> without reencoding [13:58:52 CEST] <howaboutsynergy> looks like $ ffmpeg -f concat -i mylist.txt -c copy output [13:58:59 CEST] <howaboutsynergy> yes? [13:59:42 CEST] <howaboutsynergy> I'll try [14:00:08 CEST] <pink_mist> yeah, trying it and seeing is a great way to check if something works =) [14:01:38 CEST] <howaboutsynergy> :D [14:02:01 CEST] <howaboutsynergy> just wanted to make sure there wasn't a better or more idiomatic way first ;) [14:02:42 CEST] <JEEB> you could make an app that indexes things and then processes them in one pass nicely [14:02:47 CEST] <JEEB> but ffmpeg.c currently will not do that for you :) [14:02:58 CEST] <JEEB> after all, ffmpeg.c cannot do everything you could do with the library [14:03:48 CEST] <howaboutsynergy> interesting that -ss can be used on output: "When used as an output option (before an output url), decodes but discards input until the timestamps reach position.)" I wonder if this means I don't get garbled first frames in vlc [14:04:20 CEST] <JEEB> but that only works with re-encoding [14:04:41 CEST] <howaboutsynergy> so, you mean, not with copy? [14:04:45 CEST] <JEEB> yes [14:04:48 CEST] <howaboutsynergy> got it [14:04:49 CEST] <JEEB> because you can't decode [14:05:03 CEST] <howaboutsynergy> right [14:05:15 CEST] <JEEB> with -c copy ffmpeg.c will use lavf seeking to guesstimate where the last random access point was [14:05:18 CEST] <JEEB> and copies from there [14:05:19 CEST] <howaboutsynergy> so with copy, I'm always suck with those evil video frames(when video) [14:05:34 CEST] <howaboutsynergy> stuck* [14:05:37 CEST] <JEEB> you shouldn't get garbled unless your input is marked incorrectly [14:05:54 CEST] <howaboutsynergy> what do you mean by that? [14:05:55 CEST] <JEEB> as ffmpeg.c and lavf should only seek to random access points [14:06:08 CEST] <JEEB> you shouldn't get a stream starting at a non-RAP [14:06:46 CEST] <howaboutsynergy> sounds like I shouldn't get garbled first frames ? [14:06:52 CEST] <howaboutsynergy> with copy, ever [14:07:07 CEST] <howaboutsynergy> but man ffmpeg looking at -ss kinda makes sense that I do [14:07:08 CEST] <JEEB> I wouldn't say ever since some files are mis-marked [14:07:23 CEST] <JEEB> but generally you shouldn't be getting them [14:07:28 CEST] <JEEB> unless the stream is broken [14:07:47 CEST] <howaboutsynergy> I only tested on youtube videos, downloaded with youtube-dl [14:08:15 CEST] <howaboutsynergy> I don't remember ever not getting any bad ones [14:08:31 CEST] <JEEB> I'm trying to remember if VP9 had something special that made cutting more problematic [14:10:26 CEST] <howaboutsynergy> however, vlc kinda skips a bit of the beginning on any video/audio, compared to mplayer, so I don't know [14:13:13 CEST] <JEEB> howaboutsynergy: what sort of inputs are you dealing with btw? youtube can feed you a lot of different stuff [14:17:20 CEST] <howaboutsynergy> ah, I'm not using any youtube inputs anymore, I'm currently looking at audio mp3s from grc the Security Now shows, Stream #0:0: Audio: mp3, 44100 Hz, mono, fltp, 64 kb/s ; So I don't remember what codecs the youtube vids were using [14:18:05 CEST] <howaboutsynergy> I took a look at one vid: Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv, bt709), 1920x1080, SAR 1:1 DAR 16:9, 29.97 fps, 29.97 tbr, 1k tbn, 1k tbc (default) [14:18:14 CEST] <JEEB> ok, so vp9 [14:18:19 CEST] <howaboutsynergy> Stream #0:1: Audio: aac (LC), 44100 Hz, stereo, fltp (default) [14:18:26 CEST] <JEEB> I don't remember if there was some thing in VP9 that made cutting it harder [14:18:40 CEST] <JEEB> like, that the coder state was not reset at RAPs [14:18:51 CEST] <howaboutsynergy> no idea [14:19:38 CEST] <JEEB> asked #elsewhere if someone would remember [14:19:48 CEST] <JEEB> because I remember having discussions on something that slightly resembles this [14:20:50 CEST] <howaboutsynergy> ok I actually found a cut vid which, in the beginning of the vid, garbles with vlc but not at all with mplayer [14:21:07 CEST] <howaboutsynergy> so, I tend to believe that maybe's a vlc issue [14:21:15 CEST] <JEEB> possible [14:21:26 CEST] <howaboutsynergy> like: [h264 @ 0x7f0d490943c0] co located POCs unavailable [14:21:26 CEST] <JEEB> but I still recall some things about these things so I'll see if someone responds [14:21:29 CEST] <JEEB> oh [14:21:30 CEST] <JEEB> that is H.264 :D [14:21:30 CEST] <howaboutsynergy> [00007f0d49052f70] avcodec decoder error: more than 81 frames of late video -> dropping frame (computer too slow ?) [14:21:50 CEST] <howaboutsynergy> oh yeah it's another vid, Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 1280x720 [SAR 1:1 DAR 16:9], 1116 kb/s, 30 fps, 30 tbr, 90k tbn, 60 tbc (default) [14:22:01 CEST] <JEEB> H.264 should be cut'able on RAPs [14:22:02 CEST] <howaboutsynergy> Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 125 kb/s (default) [14:22:27 CEST] <howaboutsynergy> and I used -accurate_seek -acodec copy -aq 1 -vcodec copy [14:22:36 CEST] <JEEB> umm [14:22:43 CEST] <howaboutsynergy> the "-aq 1" is useless there right? I dno why I had it [14:22:45 CEST] <JEEB> not sure -aq 1 or -accurate_seek do anything [14:22:55 CEST] <JEEB> or latter might do something, and I wonder if it does anything good [14:23:21 CEST] <howaboutsynergy> yeah, accurrate seek is default anyway, but yeah both must be leftovers for when I didn't use copy at all! [14:23:56 CEST] <howaboutsynergy> "seeking is accurate when transcoding" [14:24:08 CEST] <JEEB> ok, seems like the value is only utilized in ffmpeg_filter.c [14:24:10 CEST] <howaboutsynergy> "which may be useful e.g. when copying some streams and transcoding the others." [14:24:22 CEST] <howaboutsynergy> so, it's useless with copy? [14:24:26 CEST] <JEEB> yes [14:24:33 CEST] <JEEB> since you can only be more "accurate" in that sense if you are decoding [14:24:45 CEST] <JEEB> howaboutsynergy: btw was your input container MPEG-TS in that case? [14:24:51 CEST] <JEEB> since I see the 90k tbn [14:25:26 CEST] <howaboutsynergy> -ss " When used as an input option (before "-i"), seeks in this input file to position. Note that in most formats it is not possible to seek exactly, so ffmpeg will seek to the closest seek point before position. When transcoding and -accurate_seek is enabled (the [14:25:26 CEST] <howaboutsynergy> default), this extra segment between the seek point and position will be decoded and discarded. When doing stream copy or when -noaccurate_seek is used, it will be preserved." [14:25:43 CEST] <JEEB> yes [14:26:44 CEST] <howaboutsynergy> yeah makes sense what you said. I don't know what the input container was when youtube-dl got it, but before cutting it was the same ".mp4" [14:27:29 CEST] <JEEB> ok [14:27:44 CEST] <howaboutsynergy> or can I run something on it that tell you more info about the container? [14:27:50 CEST] <howaboutsynergy> tells* [14:28:01 CEST] <JEEB> `ffprobe -v verbose -i FILE` gives you a general overlook [14:28:05 CEST] <JEEB> like the format etc [14:28:22 CEST] <JEEB> so for mp4 you get mp4, and then the streams etc [14:29:58 CEST] <JEEB> there are then special tools to look at the details if you need to get those [14:30:10 CEST] <howaboutsynergy> ffprobe is what I used but without the -v verbose [14:30:32 CEST] <JEEB> yea, you mostly posted the part that says something about the streams within [14:30:37 CEST] <howaboutsynergy> ok, so since vlc is the only one garbling, i guess I can rest assured it wasn't ffmpeg [14:30:50 CEST] <howaboutsynergy> Input #0, mov,mp4,m4a,3gp,3g2,mj2 [14:30:57 CEST] <JEEB> you can test decoding with something like `ffmpeg -v verbose -i FILE -f null -` [14:31:02 CEST] <howaboutsynergy> compatible_brands: isomiso2avc1mp41 [14:31:09 CEST] <JEEB> yea, so it's mp4-like [14:31:13 CEST] <JEEB> probably mp4 [14:31:28 CEST] <JEEB> which should have a global index (Generally) and proper fields for RAPs [14:31:49 CEST] <howaboutsynergy> the extension is .mp4 [14:32:06 CEST] <howaboutsynergy> encoder : Lavf58.26.101 [14:32:11 CEST] <howaboutsynergy> cool [14:32:27 CEST] <JEEB> then for various formats there's actual inspectors [14:32:39 CEST] <howaboutsynergy> I tried VLC media player 4.0.0-dev Otto Chriek (revision 4.0.0-dev-7321-gdb9131787a) [14:32:39 CEST] <JEEB> but in this case I don't think you need those :) [14:32:42 CEST] <kubast2_> Does tune makes any difference when doing lossless x264 like use -crf 0/ -qp 0 -qpmin 0 -qpmax 0 ? [14:33:00 CEST] <kubast2_> As in [14:33:05 CEST] <JEEB> kubast2_: I don't think you need to set min/max :P [14:33:09 CEST] <kubast2_> Is it possible for the output material to be different [14:33:09 CEST] <JEEB> with libx264 at least [14:33:18 CEST] <JEEB> you just set -q:v or whatever to zero [14:33:25 CEST] <JEEB> (crf zero works for 8bit) [14:33:48 CEST] <JEEB> kubast2_: I don't think anything set in tunes generally affects lossless mode too much [14:35:47 CEST] <kubast2_> I guess I can always convert the files to rawvideo and check if there's a difference [14:35:59 CEST] <JEEB> there shouldn't be :) [14:36:10 CEST] <JEEB> lossless if enabled is always lossless [14:36:38 CEST] <JEEB> at most tune fastdecode or zerolatency affect compression efficiency [14:42:29 CEST] <JEEB> howaboutsynergy: VP9 seems apparently to reset coder state on RAPs so as long as they're correctly marked it should JustWork [14:43:57 CEST] <howaboutsynergy> what's a RAP? relative access point? [14:44:09 CEST] <JEEB> random access point [14:44:22 CEST] <JEEB> because a "keyframe" talks only about a single frame [14:44:23 CEST] <howaboutsynergy> oh right, (pretending to know what that's about xD) [14:44:34 CEST] <JEEB> it does not make a promise about being able to decode what comes after [14:44:58 CEST] <JEEB> while RAP always means that what comes after in presentation order should be decode'able as well [14:47:24 CEST] <dongs> JEEB: dongs [14:48:05 CEST] <JEEB> exactly [14:48:28 CEST] <JEEB> thanks for the sample, although I couldn't parse it as LATM I think [14:49:34 CEST] <dongs> i handle 22ch shit same way as < 22ch, which is just prepend length header or wahtever [14:49:37 CEST] <dongs> and dump [14:49:40 CEST] <dongs> i donno if thats wrong or not [14:50:31 CEST] <JEEB> yea, as bit stream it should be the same so no special handling there methinks [14:50:39 CEST] <dongs> hdr[0] = 0x56; hdr[1] = 0xE0 | ((pInfo->Length >> 8) & 0xF); hdr[2] = pInfo->Length & 0xFF; [14:52:25 CEST] <furq> kubast2_: use the hash muxer if you want to compare two decoded files [14:52:50 CEST] <furq> ffmpeg -v error -i foo.mp4 -i bar.mp4 -map 0 -f hash - -map 1 -f hash - [14:53:07 CEST] <dongs> JEEB: unless it was split across separate PIDs and i didnt notice [14:53:14 CEST] <dongs> anyway, the dump there is raw dump + latm header. [14:53:21 CEST] <dongs> whats beyond it is either trash or ?? i donno. [14:53:27 CEST] <dongs> since not 100% sure of crypto either. [14:53:33 CEST] <JEEB> aye [14:53:40 CEST] <dongs> unfortunately 8K is crypto even during sleep time [14:53:45 CEST] <dongs> unlike 4K [14:53:47 CEST] <dongs> whcih is in teh clear [14:53:59 CEST] <dongs> so i don't have a baseline [14:54:27 CEST] <JEEB> yea I just noticed it mentioned something about multiple programs so the insane people might have decided to do sub-streams in LATM [14:54:36 CEST] <dongs> im back in japan so i'll be poking with this again as soon asi get my desk from exploded state [14:59:14 CEST] <JEEB> I'll probably poke a bit more on the MMTP part after I get over some other stuff I'd like to move forwards [14:59:23 CEST] <JEEB> since I think I've got TLV more or less OK [15:00:10 CEST] <howaboutsynergy> looks like -nostdin is pretty much what I always want to specify on every ffmpeg command [15:02:46 CEST] <kubast2_> furq they all have different hashes [15:03:15 CEST] <kubast2_> I did both converssion to rawvideo with the same pix format and using the hash mux [15:03:34 CEST] <kubast2_> tune modifies lossless video then? [15:03:40 CEST] <furq> by decoded i meant the decoded contents [15:03:45 CEST] <furq> you can use it on the encoded files [15:04:07 CEST] <kubast2_> Yeah I used the muxer on encoded frame/file [15:04:14 CEST] <kubast2_> Well gonna check one more thing tbh [15:04:22 CEST] <furq> are you enabling the vbv [15:04:32 CEST] <furq> x264 output is nondeterministic if you use multithreading and enable vbv [15:04:32 CEST] <kubast2_> vbv? [15:04:36 CEST] <furq> maxrate/bufsize [15:04:43 CEST] <furq> probably not if it's lossless [15:04:55 CEST] <kubast2_> I used none options for maxrate and bufsize [15:05:04 CEST] <kubast2_> And if ffmpeg uses multithreading by default [15:05:16 CEST] <kubast2_> Then yes I did use it and didn't add -threads 1 [15:05:17 CEST] <furq> well libx264 does by default [15:05:26 CEST] <furq> but one or the other is fine [15:05:29 CEST] <furq> it's just if both are enabled [15:06:27 CEST] <furq> also i guess you want -map 0:v and -map 1:v if the files have audio [15:06:50 CEST] <kubast2_> Ah I'm an idiot [15:10:04 CEST] <kubast2_> The hashes are still different, but yeah I forgot to use -crf 0 :^) [15:10:46 CEST] <kubast2_> And now I put -crf 0 in a wrong place :^) I will just open bash history file and fix it there [15:10:58 CEST] <kubast2_> And redo it as one command [15:15:44 CEST] <kubast2_> Yep [15:15:46 CEST] <kubast2_> Same hash [15:29:58 CEST] <howaboutsynergy> What do they mean here by timestamps being copied? " Note that if you specify -ss before -i only, the timestamps will be reset to zero, so -t and -to have not the same effect. If you want to keep the original timestamps, add the -copytsoption. " from https://trac.ffmpeg.org/wiki/Seeking#Cuttingsmallsections [15:30:56 CEST] <howaboutsynergy> and is that 'not' a type for 'now' ? in "so -t and -to have not the same effect" [15:31:10 CEST] <howaboutsynergy> typo* [15:33:22 CEST] <howaboutsynergy> oh i understand it now that I read the 3 explained examples which follow [15:39:03 CEST] <howaboutsynergy> I recompiled vlc, same garblage at the beginning and boy vlc changed, now I've 2 windows: one for video and one for playlist+menu. [16:19:51 CEST] <Atlenohen> JEEB,Cehoyos,furq: I had to go and document things from the get go to figure this out, infact this picture is the draft of what will be a new guide, I should have analyzed the build log earlier it turned out to be very helpful [16:20:15 CEST] <Atlenohen> https://i.imgur.com/U89cCmO.png [16:21:27 CEST] <Atlenohen> The configure file would need some updates, but this is just bare to get it working, there's a lot of stuff that's "unknown option" which I can summarize later, will probably put it all on a bug ticket [16:23:00 CEST] <Atlenohen> As for BCrypt, after I finished the graphic, I went and tried if it's the version issue, with Win10 SDK, I basically made a copy of the LIBs and INCLUDEs of Win10SDK's older version and make them to be fakes, renamed to a folder of the new version, so it took the old files, but it didn't help [16:24:19 CEST] <Atlenohen> Finally, it only struck me then at the end of that, well, why the hell don't I try forcing the bcrypt.lib and bcyrpt.h into the final program, who cares if ffmpeg doesn't compile it, I'll just put it there, that worked and sovled the whole issue. [18:15:00 CEST] <HickHoward> uhhh [18:15:00 CEST] <HickHoward> so [18:15:43 CEST] <HickHoward> has anyone ever ripped a netflix video with ffmpeg before? [18:16:52 CEST] <durandal_1707> that is illegal [18:17:15 CEST] <HickHoward> oof [18:29:03 CEST] <aboxer> I am converting h264 to h265 with this command: ffmpeg -i IN.ts -c:v libx265 -preset ultrafast -x265-params lossless=0 OUTPUT.ts [18:29:22 CEST] <aboxer> I would also like to convert ATSC closed captions [18:29:28 CEST] <aboxer> what am I missing ? [18:30:14 CEST] <JEEB> quickly looked at the libx265.c wrapper here [18:30:19 CEST] <JEEB> and I don't see it touching the side data [18:31:11 CEST] <aboxer> o o [18:31:16 CEST] <aboxer> thanks, JEEB [18:31:16 CEST] <JEEB> I mean, touching the side data that contains the captions [18:31:20 CEST] <aboxer> yes [18:31:55 CEST] <aboxer> plan B is to find an h265 sample with SEI closed captions [18:36:16 CEST] <aboxer> JEEB: is there an issue open for CC conversion for h265 ? [18:39:53 CEST] <aboxer> I found a sample file, btw: https://streams.videolan.org/streams/ts/CC/hevc_cc.ts [18:54:48 CEST] <lrusak> I'm only getting about 90fps when transcoding with vaapi, is that normal? [18:55:03 CEST] <lrusak> ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -i input.mkv -c:v hevc_vaapi output.mkv [18:55:17 CEST] <JEEB> could be normal, depends heavily on what the hardware can provide [18:55:35 CEST] <JEEB> it's more than real time for a lot of stuff so I would expect that to be what's expected [18:55:51 CEST] <JEEB> (because 60Hz is usually most you get with broadcast/streaming) [18:58:14 CEST] <lrusak> Ok, it's a kaby lake i7, and the content is 23.976 [19:15:29 CEST] <jkqxz> lrusak: The default compression level in some drivers trades a lot of speed for a marginal quality gain in the encode. Try "-compression_level 100" (some large number, it'll tell you what he upper bound is). [19:25:02 CEST] <lrusak> [hevc_vaapi @ 0x564f25964200] Invalid compression level: valid range is 0-7, using 7. [19:25:25 CEST] <lrusak> I don't seem much difference though when using different vaues [20:11:19 CEST] <ncouloute> When I use the concat demuxer to combine several cfr mp4s I'm getting a variable framerate file back. Is there any way to get it to output cfr without reencoding? [20:16:14 CEST] <Ariyasu> is the frame rate the same in each file? [20:16:40 CEST] <Ariyasu> if you concat somthing thats 25fps and somthing thats 50fps, while both have cfr the output will be vfr [20:17:24 CEST] <Ariyasu> and if it's the case that your source files have differing framerates, you would have to encode to get them all to match and you probably dont want to be doing that [20:17:38 CEST] <Ariyasu> changing framerate is noramlly a bad idea [20:30:46 CEST] <ncouloute> yes each file has the same constant framerate of 60000/1001 In fact I encode them with ffmpeg at first.. then concat after [20:31:45 CEST] <JEEB> ncouloute: you should check the timestamp diffs with either ffprobe or l-smash's boxdumper [21:07:09 CEST] <ncouloute> How would I go about that. Starting at second frame the pkt_pts and pkt_dts is off. Too much info going on with ffprobe. Going to give boxdumper a shot less output [21:07:13 CEST] <ncouloute> I tried using the concat protocol and that seems to generate a file that is only slightly variable. Although that is 3 ffmpeg statments. one to mux each file to ts and then stitch the files together then remux to mp4. Another approach would be to concat during the initial encode might work be better that way. [21:46:15 CEST] <Atlenohen> Is there some kind of an explanation to the configure file [21:46:28 CEST] <Atlenohen> it's like totally undocumented of what's what [21:48:15 CEST] <Atlenohen> these tests that are being done ff.conf_9djdsnj87c.test are they even needed for building? [21:49:09 CEST] <Atlenohen> so many repeating tests in the config.log, testing what? [21:49:52 CEST] <Atlenohen> I know it generates the things and checks for valid paths but, how roughly how much is strictly necessary ? [22:34:09 CEST] <Atlenohen> install command also copies shared text files [22:34:26 CEST] <Atlenohen> but in makefile it only speifies libs and headers [23:26:54 CEST] <Atlenohen> I have received word from other people that static libs aren't going to pack other libs like bcrypt.lib anyway so it's not ffmpeg fault [23:27:33 CEST] <Atlenohen> Not sure if it's that true, however, ffmpeg's build log could be designed to output a list of dependencies that may be needed later on [00:00:00 CEST] --- Mon Apr 15 2019

1 0

ffmpeg-devel.log.20190413
by burek 14 Apr '19

14 Apr '19

[00:05:00 CEST] <mkver> Hello all. I have a question regarding inactive maintainers: What happens with patches to components whose maintainers are inactive? [00:08:37 CEST] <BBB> someone else will eventually review them [00:09:43 CEST] <mkver> Ok, then I'll simply ping the patchset. Thanks. [08:10:25 CEST] <mkver> If an error happened during writing a packet during muxing, is the user then actually allowed to simply try to mux another packet or is he supposed to end muxing altogether and write the trailer? I presume the former, but I am not sure. [08:14:10 CEST] <mkver> I'm asking because of the webm_chunk muxer. This muxer uses a Matroska/Webm muxer internally and if an error happens during writing the packet, the whole Matroska/Webm mux context gets freed. In this case a use-after-free (and also double free) also happens during writing the trailer. And depending upon the answer to my question, a use-after-free would also happen when one writes another packet after an error occurred during a [08:14:10 CEST] <mkver> packet. [08:15:05 CEST] <mkver> during writing a packet. [10:47:23 CEST] <nevcairiel> even if a call is technically wrong, it should not result in a use-after-free, so checks are needed regardless [12:57:44 CEST] <atomnuker> "The string codecs="av01.0.01M.08" in this case would represent AV1 Main Profile, level 2.1, Main tier, 8-bit content with 4:2:0 chroma subsampling, ITU-R BT.709 color primaries, transfer characteristics, matrix coefficients, and studio swing representation." [12:58:14 CEST] <atomnuker> why the cryptic codec name? that data is available elsewhere [12:59:08 CEST] <atomnuker> not like hardware decoders care about colorspace or range [13:02:10 CEST] <nevcairiel> the last part isnt even signaled in t he string, those are the defaults [13:02:20 CEST] <nevcairiel> but it can be [13:02:35 CEST] <nevcairiel> it may want to know if something is hdr vs not or such [13:09:08 CEST] <atomnuker> av01.0.05M.08, so youtube signal it [13:45:04 CEST] <nevcairiel> a full string would be something like "av01.0.04M.10.0.112.09.16.09.0" .. yours all end after the bitdepth, so no color info [13:51:06 CEST] <atomnuker> oic, still very verbose [15:03:53 CEST] <cehoyos> jkqxz: There is a GSoC proposal for an OpenCL Deshake Filte, you are listed as a possible mentor on trac - are you (still) interested? [15:05:38 CEST] <BtbN> Anyone happen to know if my Visual Studio 2017 Enterprise License will activate 2019? [15:06:03 CEST] <BtbN> I highly suspect it won't, but the Installer is offering me the update. [15:10:04 CEST] <BtbN> btw. regarding opencl filters. I guess we are no longer integrating them with the existing native filters? [15:10:18 CEST] <BtbN> Cause that OpenCL version of the colorkey filter had me wondering. [15:10:42 CEST] <JEEB> BtbN: my first guess would be not to activate although I don't think I've noticed details being written about that anywhere [15:10:54 CEST] Action: JEEB has mostly moved onto the free SDKs after leaving university [15:11:21 CEST] <BtbN> I'm still at a university, and will be for quite a while, since I work there. [15:11:44 CEST] <BtbN> But Microsoft rebranded MSDNAA/Dreamspark/Imagine/... once again, and has so far not supplied anyone with info on how to get access. [15:12:10 CEST] <JEEB> oh, they changed that again [15:13:04 CEST] <BtbN> "Azure Dev Tools for Education" is what it's called now [15:13:47 CEST] <BtbN> "Microsoft has so far failed to provide us with information on how to gain access." [15:13:55 CEST] <BtbN> That's my Unis statement about it [15:14:21 CEST] <BtbN> They're a bit pissed, because they did not fail to send the next bill [16:39:56 CEST] <durandal_1707> https://github.com/losnoco/vgmstream/issues/395 [16:55:27 CEST] <HickHoward> "i'm da badass here" [16:57:36 CEST] <durandal_1707> look at https://github.com/losnoco/vgmstream/issues/394 for explanations [17:01:57 CEST] <HickHoward> huh... [17:02:22 CEST] <HickHoward> guy's a possible terrorist by this point [17:47:05 CEST] <durandal_1707> why hevc-two-first-slice is still failing? [17:52:54 CEST] <jamrial> because whoever runs those fate clients hasn't synced the sample [17:53:30 CEST] <durandal_1707> who is responsible for it? [17:54:19 CEST] <jamrial> "mik" [17:54:46 CEST] <jamrial> i worry more about how no slot seems to have run in two days [17:55:22 CEST] <jamrial> michaelni: is there something wrong with fate? it's been two days since the last submitted result [17:56:42 CEST] <durandal_1707> ffmpeg got to big for fate [17:56:49 CEST] <jamrial> oh, nevermind, it's just that no commits were made since then [17:57:17 CEST] <jamrial> fate just discards new results if it's for the same commit as the last one [17:58:07 CEST] <durandal_1707> even if it becomes green? [17:58:37 CEST] <jamrial> no idea [18:02:14 CEST] <cehoyos> Did anybody ever look at "warning: implicit conversion from 'int' to 'int16_t' (aka 'short') changes value from 44130 to -21406" when compiling fspp with clang? [18:02:49 CEST] <durandal_1707> i ignore darkmagic filters [18:03:19 CEST] <cehoyos> I thought you wrote it;-) [18:04:15 CEST] <JEEB> could be valid depending on the values passed [18:04:51 CEST] <JEEB> or technically: is valid, but whether it affects things depends on the values passed [18:09:09 CEST] <durandal_1707> trac is unresponsive again [18:15:28 CEST] <cone-188> ffmpeg 03Paul B Mahol 07master:16f7c1f2911c: avcodec: add LSCR decoder [18:18:41 CEST] <JEEB> meanwhile brr, I really need to create that sample for that one sub2video FATE test that I wanted to add :V [18:18:52 CEST] <JEEB> that one sub2video bugfix has been sitting on the ML for a while [18:19:02 CEST] <JEEB> (use case that michael noticed) [18:19:31 CEST] <michaelni> jamrial, one of my fate client VMs died, one has a clock thats a day off, iam checking the others dunno if thats the issue [18:20:47 CEST] <jamrial> michaelni: no, it isn't. i noticed after asking you that there have been no new commits since then [18:23:42 CEST] <jkqxz> cehoyos: Yes, I've been talking to that student. [18:24:03 CEST] <cehoyos> michaelni: Does this clang warning have any real-life effect: "warning: implicit conversion from 'int' to 'int16_t' (aka 'short') changes value from 44130 to -21406" [18:24:08 CEST] <cehoyos> This is when compiling fspp [18:24:23 CEST] <cehoyos> jkqxz: Please accept the mentor invitation by Google. [18:25:40 CEST] <jkqxz> Hmm. I'm trying to log in with my account from last year, but it says I don't have one. Do I need to sign up again? [18:25:59 CEST] <cehoyos> Did you not receive an invitation? [18:26:31 CEST] <jkqxz> Where? [18:26:45 CEST] <cehoyos> sw(a)jkqxz.net [18:27:49 CEST] <cehoyos> Or to say it differently: Where do you want it? [18:28:05 CEST] <jkqxz> Ah, I do have an email. [18:28:11 CEST] <cehoyos> ;-) [18:28:32 CEST] <cehoyos> Do you know how to setup Linux so that you don't have to login locally to enable remote vaapi? [18:28:43 CEST] <cehoyos> remote: via ssh [18:29:35 CEST] <jkqxz> Use a render node? [18:30:17 CEST] <cehoyos> Sorry? [18:30:17 CEST] <jkqxz> Does it fail because you have X forwarding enabled and it tried to connect via X? [18:30:46 CEST] <cehoyos> It doesn't fail after I logged in on the system where I want to test vaapi [18:30:50 CEST] <cehoyos> Even via ssh [18:31:11 CEST] <jkqxz> Huh. What is the error? [18:31:42 CEST] <cehoyos> The error was: No VA display found for device: /dev/dri/renderD128. [18:33:01 CEST] <jkqxz> Can you strace it to find out what fails? That's a pretty generic top-level error because you don't get much feedback from libva. [18:37:09 CEST] <cone-188> ffmpeg 03Paul B Mahol 07master:a208c277f811: avcodec/imm4: flush prev_frame after seeking [18:40:34 CEST] <cehoyos> openat(AT_FDCWD, "/dev/dri/renderD128", O_RDWR) = -1 EACCES (Permission denied) [18:41:46 CEST] <nevcairiel> there may be a group your user needs to be in to access that [18:42:15 CEST] <jkqxz> Most distributions make that accessible to a group called "video". Is the user you are running as in that group when you run it? [18:43:18 CEST] <cehoyos> I see the same error after adding my user to that group [18:43:50 CEST] <cehoyos> Works after logoff-login [18:44:09 CEST] <cehoyos> I wonder why it worked locally and via ssh if I was logged in locally [18:44:21 CEST] <JEEB> something could have made the file more accessible [18:44:29 CEST] <JEEB> I just checked the rights on my fedora while logged in [18:44:32 CEST] <JEEB> http://up-cat.net/p/d5e059e7 [18:44:48 CEST] <JEEB> which seems to be rather free for the render end point? [18:44:52 CEST] <cehoyos> Anyway jamrial: Neither vaapi nor nv decode the sample(s) bit-exact, only old FFmpeg did [18:45:25 CEST] <cehoyos> The third gop of the second sample is still different with your patch. [18:47:26 CEST] <jkqxz> It's possible to have different sets of groups when logged in by different methods. When running as the user, try "id". [18:48:32 CEST] <cehoyos> Thank you! [18:49:21 CEST] <cehoyos> Feel free to click "Want to mentor" for the deshake project. [18:50:31 CEST] <jkqxz> Looking at it now. [19:04:31 CEST] <michaelni> cehoyos, the cast looks correct [19:05:39 CEST] <JEEB> that warning says implicit, so there is no explicit cast there [19:05:48 CEST] <JEEB> unless clang is missing it [19:06:09 CEST] <michaelni> theres a explicit cast in the line and a implicit one [19:06:18 CEST] <JEEB> ah [00:00:00 CEST] --- Sun Apr 14 2019

1 0

ffmpeg.log.20190413
by burek 14 Apr '19

14 Apr '19

[01:10:01 CEST] <friendofafriend> Actually communicating with the MPEG LA sounds terrifying. [01:27:35 CEST] <freemint> Hello i try to findout whether my Intel i5 8250 running fedora 29 performs harware accelartion for video. [01:28:25 CEST] <freemint> I tried figure that out by ffmpeg -i file -map 0:v:0 -c:v libx264 -f null - vs ffmpeg -i file -map 0:v:0 -c:v mpeg2_vaapi -f null - [01:29:38 CEST] <freemint> When i call anything goal codec ending in _vaapi i always get the error: [01:29:39 CEST] <freemint> Impossible to convert between the formats supported by the filter 'Parsed_null_0' and the filter 'auto_scaler_0' [01:29:39 CEST] <freemint> Error reinitializing filters! [01:29:41 CEST] <freemint> Failed to inject frame into filter network: Function not implemented [01:38:55 CEST] <friendofafriend> freemint: You're talking about QuickSync? [01:39:49 CEST] <freemint> i think the technology i want to use is called libva or vaapi or vdpau [01:40:12 CEST] <friendofafriend> And you're trying to hardware accelerate encoding on your Intel CPU, yes? [01:40:27 CEST] <freemint> Encoding and decoding, yes [01:41:17 CEST] <friendofafriend> You'll find some excellent information about it, here. https://trac.ffmpeg.org/wiki/Hardware/QuickSync [01:42:55 CEST] <freemint> Is it the same as quicksync? [01:43:30 CEST] <friendofafriend> That's the term for hardware accelerated video encoding/decoding with Intel CPUs. [01:43:38 CEST] <freemint> my intel is gen8 [01:45:06 CEST] <friendofafriend> Right, so the wiki recommends you use intel-vaapi-driver from the linked repo. [01:46:28 CEST] <friendofafriend> There's a lot of example commands in the wiki, also. You'll want to make sure the ffmpeg you have supports "qsv", in the first place. [04:46:38 CEST] <Tu13es> hi folks, i have a mp4 whose audio/video goes out of sync part way through. is there a way I can adjust the video stream partway through? [04:48:09 CEST] <Tu13es> i used -itoffset to fix some initial sync issues but it goes out of sync again later in the video [15:07:02 CEST] <Atlenohen> Is it possible to disable audio of the mpegts muxer ? LATM and ADTS are added as muxers [15:07:41 CEST] <Atlenohen> Not a big deal tho [15:08:10 CEST] <cehoyos> They are a requirement [15:08:18 CEST] <cehoyos> Actually a dependency [15:08:38 CEST] <Atlenohen> Oh allright [15:09:47 CEST] <JEEB> probably in order to minimize the amount of ifdefs in code [15:11:36 CEST] <cehoyos> No, in this case the dependency was added because users protested that the mpegts muxer didn't work [15:12:18 CEST] <JEEB> :) [15:12:23 CEST] <Atlenohen> hmm, ffmpeg's configure treats .LIB files as "shared libs" and .a as static for MSVC and WIN64, while lib.exe according to everyone I talked never worked with .a files, whether shared or static [15:13:14 CEST] <JEEB> Atlenohen: yea I think in msvc nomenclature .lib is generally utilized for both the stubs as well as static libs I think [15:14:37 CEST] <Atlenohen> So my MSYS2 MINGW MSVC build attempt with x264 is stuck with these invalid .a files, they look like they're COFF (!<arch>) format but their size is too small IMO, I have more muxers/encoders and it's 3 times the size of the older library which has only 1 muxer and 1 encoder [15:15:20 CEST] <Atlenohen> So I get errors in VS2017,LNK2019 unresolved external symbol BCryptOpenAlgorithmProvider referenced in function av_get_random_seed avutil.lib(random_seed.o) [15:16:44 CEST] <BtbN> .lib and .a are virtually the same [15:16:56 CEST] <cehoyos> The error you quote is definitely not related to x264 [15:16:57 CEST] <Atlenohen> 3 times less size, the old lib is 10 MB and I have 3 MB [15:17:02 CEST] <BtbN> it's impossible to tell, other than by guessing based on file size. [15:17:29 CEST] <BtbN> Cause an import-.lib is technically also just a static lib, but only containing trampolines [15:17:44 CEST] <cehoyos> It sounds more as if you forgot to tell which native Windows libraries libavutil needs [15:17:55 CEST] <BtbN> 3MB is still way too large for it to be just an import-lib [15:18:32 CEST] <cehoyos> 3MB sounds correct for x264 [15:19:08 CEST] <Atlenohen> cehoyos: I had same kind of errors pointing to avcodec.lib(libx264.o) previously, someone else told me that static libs dependencies may not be packing themselfs like russian dolls and that the 3rd C++ project needs all the includes so I added them, the x264 errors turned into warnings and new errors pointing to ffmpeg stuff shown up [15:19:35 CEST] <cehoyos> I saw some of the nonsense you were told yesterday;-) [15:19:48 CEST] <cehoyos> Atm, I only see an error message that you quoted and that is not related to x264 [15:20:02 CEST] <Atlenohen> cehoyos: these are the x264 warnings now LNK4217 locally defined symbol x264_levels imported in function X264_init avcodec.lib(libx264.o) [15:20:46 CEST] <JEEB> I don't think static libs have dependencies noted in them so you need to link all of the stuff (usually noted by pkg-config implementations), and preferably in the right order for your linekr [15:20:50 CEST] <JEEB> *linker [15:20:53 CEST] <Atlenohen> cehoyos: cause I was around 5 other channels all day long, so it's a bit spread around, I was on #msys on OFTC alot, on ##linux, on ##c++-general, etc [15:21:20 CEST] <Atlenohen> BtbN cause I want full static libs, not DLL import libs [15:21:39 CEST] <BtbN> You'll need to make sure all your dependencies are static libs then [15:21:42 CEST] <cehoyos> I don't think the Windows C library is available as a static library, is it? [15:21:49 CEST] <BtbN> It is [15:22:05 CEST] <cehoyos> And also all other Windows system libraries? [15:22:06 CEST] <BtbN> You don't want that though, cause it comes with Windows anyway, and is huge [15:22:08 CEST] <cehoyos> I didn't know that. [15:22:21 CEST] <BtbN> Like, 30MB or so [15:22:37 CEST] <BtbN> And it's part of Windows in every still supported release [15:22:38 CEST] <cehoyos> I mean I didn't know that all Windows system libraries exist as static libraries. [15:22:53 CEST] <JEEB> I didn't know if all of them did? [15:22:59 CEST] <Atlenohen> X264 building is a lot different, look a lot different output, and lib.exe command is clearly shown at the end and a .lib is made, but I have independently confirmed that AR (archive tool) is indeed lib.exe so the problem may be somewhere else [15:23:28 CEST] <JEEB> msvcrtXXX was a thing that definitely had static versions though [15:23:30 CEST] <cehoyos> As long as you don't tell us your problem, it is unlikely that we will be able to help you;-) [15:23:41 CEST] <Atlenohen> BtbN: Yes I built x264 as static, there's no other dependencies that I'm aware of. [15:24:07 CEST] <cehoyos> x264 can have several dependencies but this was not the issue of the error message you quoted above. [15:25:37 CEST] <Atlenohen> cehoyos: I wish I knew what the problem was. Simply put the .a files (which I renamed to .lib) that got generated all day yesterday in those conditions weren't valid for the C++ project which always used and is using static ffmpeg libs [15:26:15 CEST] <Atlenohen> I did further config adjustments, added more params, will try again now, and I'll paste all the config's [15:26:23 CEST] <cehoyos> They weren't valid? You mean you created libraries incompatible with the toolchain you want to use? [15:26:45 CEST] <cehoyos> Instead of pasting the config's you should maybe tell us the error you get. [15:27:07 CEST] <Atlenohen> x264 build and ffmpeg build were all successful, it was a struggle to just get to some result. [15:27:27 CEST] <Atlenohen> There's no error in x264 or ffmpeg builds in MSYS2 MINGW shell [15:27:32 CEST] <cehoyos> (Given that static compilation is the default, this is a little surprising) [15:27:34 CEST] <BtbN> You cannot use gcc built .a files in msvc builds. They will be targetting a different libc [15:29:10 CEST] <Atlenohen> BtbN: this is what I was trying to figure out yesterday evening with someone on a C++ channel, but we confirmed MSYS2 MINGW64 shell is indeed using lib.exe from MSVC because I got an error if it didn't find it, i also forced option --ar=lib too [15:29:40 CEST] <Atlenohen> So it's not using ar.exe in MSYS2/MINGW64, even tho ffmpeg's output prints "AR libavcodec.a" [15:30:05 CEST] <JEEB> AR is just "whatever is set to be your 'ar' equivalent" [15:30:11 CEST] <JEEB> I think the more specific output is with make V=1 [15:30:19 CEST] <JEEB> which outputs the actual commands if you wish to see those [15:30:34 CEST] <cehoyos> To answer the question that you have not yet asked: You need the additional import library Bcrypt.lib for libavutil in your project. [15:31:14 CEST] <Atlenohen> x264 build log printed lib.exe and the full command referencing all .o files, I'm sure probably that's what it's done under the hood in ffmpeg case, the messaging may just be different, although for a novice user that's sometimes very confusing but I managed to figure things out [15:32:50 CEST] <Atlenohen> cehoyos: Oh well, if it's that easy ... I never knew about it's existence so I couldn't have been able to ask it, I might have figured it out by searching the error, but hours later probably. [15:33:22 CEST] <cehoyos> I didn't know about its existence either but it took me a minute to find out. [15:33:25 CEST] <Atlenohen> cehoyos: this is something the ffmpeg's build log should have warned about, (or maybe i should have enabled warn failure) [15:34:22 CEST] <cehoyos> Please provide the output of: make libavutil/libavutil.pc && cat libavutil/libavutil.pc [15:34:40 CEST] <Atlenohen> JEEB: V=1, oh the messaging configuration, thanks [15:35:07 CEST] <Atlenohen> cehoyos: after the build? I cleaned it so I'll have to rebuild, moment [15:35:20 CEST] <cehoyos> No, you don't have to rebuild [15:35:22 CEST] <Atlenohen> or wait, maybe it's still in the output folder [15:35:33 CEST] <JEEB> his command specifically re-builds the pc file [15:35:35 CEST] <JEEB> :) [15:35:38 CEST] <JEEB> (only) [15:35:50 CEST] <JEEB> (or makes sure it exists if you have some build outputs still there) [15:36:06 CEST] <Atlenohen> Ofocurse, I'm totally new to this. [15:36:39 CEST] <BtbN> lib and ar are just archiv creating tools for virtually the same format [15:37:05 CEST] <BtbN> It's the object files inside that matter [15:37:21 CEST] <cehoyos> I am curious about something else: What is your original issue? After all, the default builds are static. [15:38:21 CEST] <Atlenohen> cehoyos: https://pastebin.com/5pAE8xcL [15:39:31 CEST] <cehoyos> So, if I count correctly there are three ways to immediately tell you that bcrypt.lib is a needed library (I was just interested in this one because I was curious if pkg-config really works, I doubted it). Where id you look? [15:39:56 CEST] <Atlenohen> BtbN: I worked with delayloaded DLLs and their .libs, while there is similarities they look a lot different in text editor and they're much smaller, only a few 100 KBs at most, I am thinking maybe FFMPEG has improved in years so much there's less code needed for the stuff I'm using [15:40:01 CEST] <cehoyos> The easiest would be "rm ffmpeg_g && make V=1 ffmpeg_g" [15:40:08 CEST] <Atlenohen> unrelated project* [15:40:15 CEST] <cehoyos> after building FFmpeg [15:40:59 CEST] <cehoyos> This is extremely unlikely: The FFmpeg libraries grow each year. [15:41:25 CEST] <Atlenohen> cehoyos: after ffmpeg built, there was no any indication of anything wrong, so I just spent 3 hours figuring out why .a, and all that was a long story, I then just put .a renamed to .lib manually and see what happens, and here we are [15:41:53 CEST] <cehoyos> Why do you believe that anything went wrong? [15:41:55 CEST] <Atlenohen> The log was long, I didn't check all warnings, but if it's a needed lib it probably should have been an error, no big deal, it may be a bug [15:42:28 CEST] <cehoyos> Why would there be a bug? [15:42:39 CEST] <Atlenohen> cehoyos: Such thing should show an error by default, not my me having to explicitly use some verbose output mode. Error happened when it didn't find x264.lib so why not bcrypt.lib [15:42:49 CEST] <cehoyos> What should show an error by default? [15:43:24 CEST] <cehoyos> You showed us an error when compiling your project and - as said - it was immediately clear what was missing. Then you asked if FFmpeg didn't know about the dependency, and yes, it knew. [15:43:37 CEST] <cehoyos> (I forgot that configure also told you about the dependency, that makes four times) [15:44:10 CEST] <Atlenohen> If ffmpeg needs it for building then ffmpeg. So you're trying to say it's some dependency which is needed but not at build time, so VS2017 project would need it? [15:44:17 CEST] <cehoyos> * what was missing although I don't compile on Windows and I had never heard about this library before. [15:44:58 CEST] <cehoyos> It is needed at build time which is why FFmpeg's build system first told you about it, wrote it down for you and used it when linking ffmpeg (the application). [15:46:24 CEST] <Atlenohen> Look I just woke up in the morning after doing that for 14 hours straight yesterday, Bcrypt error happened late yesterday and I called it quits, so I haven't had the chance to search, I did assume and didn't check if it's something else so I didn't rush to search what it means [15:47:22 CEST] <Atlenohen> I'm going to repeat build now, and I'll pay attention at the log [15:50:11 CEST] <cehoyos> (I didn't suggest to pay more attention to the log, just that it is not difficult to find out about additional dependencies and that afaics, there is no bug.) You still haven't answered my question what your original issue is: What is wrong with the Zeranoe builds? [15:50:55 CEST] <Atlenohen> I haven't saw that question before - zeranoe does not provide static libs, those are shared libs [15:51:40 CEST] <Atlenohen> the .lib files are just refs to the .DLLs, they're not the same, but they kinda look the same since the extension is the same .lib [15:52:14 CEST] <Atlenohen> MS uses same extension for both, it's nothing new, it's just one more stupid thing MS does. [15:53:10 CEST] <Atlenohen> Plus, I need a custom build with only a few components, not the full blown ffmpeg. [15:54:09 CEST] <Atlenohen> And I generally am interested in learning how to build my self, ffmpeg happened to be the first one for me. [15:54:54 CEST] <cehoyos> I see. [15:55:54 CEST] <Atlenohen> And, you know it kinda looked as if I couldn't search this one little error, as I explained, circumstances, .. I'm exhausted! [15:56:19 CEST] <Atlenohen> As if I didn't turn over the whole internet yesterday ;) [15:56:57 CEST] <BtbN> Atlenohen, yes, DLLs work because they can link in their own libc. When static linking the whole application and all libs and their libs have to aggree on the same libc. [15:57:39 CEST] <BtbN> The .lib for loading DLLs and true static .lib files don't only look the same, they are the same. [15:58:01 CEST] <BtbN> The .lib to load a dll just has a GetProcAddress based shim function for every function in the dll [16:00:53 CEST] <Atlenohen> BtbN: We had a big discussion on the .a and .lib differences yesterday, I went in ##linux at one point and called for real linux people to tell me the first 8 bytes of a .a file they had, and the result was some had ELF and some had !<arch> format (COFF) which is the format used by LIB.EXE while linux utils can do both but they usually don't name .lib they name it .a so you have another confusion on linux cause not .a files may be [16:00:53 CEST] <Atlenohen> the same format, that's one thing [16:01:23 CEST] <BtbN> both .a and .lib files are just ar archives with object files in them [16:01:44 CEST] <BtbN> That's not the issue at all [16:02:05 CEST] <BtbN> It's what built that code inside and what libraries and runtime it expects to have access to [16:02:49 CEST] <Atlenohen> Second thing is, the !<arch> files thhe ones are static are several times larger than the ones that are only references, all it takes is taking a look at zeranoe's build, avcodec.lib is 128 kilobytes large, tell me how can that be a static library ? [16:02:50 CEST] <BtbN> If you build libx264 with msvc and ffmpeg with mingw64, or vice versa, that will explode because one expects Microsoft CRT, and the other the gcc libc [16:03:08 CEST] <BtbN> Zeranoe does not offer static libraries [16:03:13 CEST] <BtbN> For license reasons [16:03:29 CEST] <BtbN> There are static fftools and shared libraries [16:03:35 CEST] <BtbN> no static libraries [16:04:21 CEST] <Atlenohen> But he offers .libs which look like static libs but they aren't so the argument is when you said all .libs are the same which just doesn't make sense. [16:04:43 CEST] <BtbN> All libs are, in their essence, static libraries. [16:04:56 CEST] <BtbN> But some of them are just empty shim ones that load a .dll and forward to it. [16:05:28 CEST] <BtbN> That's a Windows specific btw., on Linux you can link directly against .so files, so there is no need for import .libs [16:06:06 CEST] <BtbN> Only real way to tell on Windows is to either decompile the .lib and look what it does. Or it's plain obvious by its size. [16:06:19 CEST] <Atlenohen> Sure if you want to treat such a significant practical difference as a small technical details than that's your opinion, to me that's a major difference, and while you may be right about the technical aspect of the files themsefls, in practice, it's a night and day difference. [16:06:28 CEST] <BtbN> gcc/mingw on Windows has adopted the .dll.a vs. .a scheme to differentiate the two [16:08:26 CEST] <Atlenohen> At least that. But I do agree with the .lib exention, althought only for "independent static libs" for "reference libraries" i'd use something like ".rlib" or ".dlib" [16:08:47 CEST] <BtbN> That will confuse the hell out of the linker and build system though [16:09:00 CEST] <BtbN> Cause for them, there is zero difference between a shim .lib and actual static lib .lib [16:09:06 CEST] <BtbN> They work and behave the same [16:09:27 CEST] <BtbN> And Windows likes its file extensions [16:09:37 CEST] <Atlenohen> I do however find .a extension kinda like linux usually does, put some random name on it, weird, you know the trend of naming software after some random anime/manga name, which makes zero relevance/sense. [16:09:48 CEST] <BtbN> ? [16:10:06 CEST] <BtbN> It's called .a because it's an ar archive. [16:13:00 CEST] <Atlenohen> Well, yeah I did eventually heard that. Oh and I didn't mean that with linux, at least I feel it's a recent trend, I think I saw an utility called "Candy" or something. [16:13:52 CEST] <Atlenohen> Nevermind, I don't remember it was several months ago, but it doesn't help with making things less confusing. [16:24:39 CEST] <Atlenohen> cehoyos: There is no mention of bcrypt.lib in the default output log (without V=1) [16:26:52 CEST] <Atlenohen> https://pastebin.com/HHTDU8wd [16:34:18 CEST] <cehoyos> Atlenohen: Missing configure output [16:34:47 CEST] <Atlenohen> Yeah I was about ot [16:36:47 CEST] <Atlenohen> cehoyos: Configuration https://pastebin.com/7WktAgFC [16:38:13 CEST] <cehoyos> Indeed, bcrypt is not mentioned, feel free to send a patch. [16:38:21 CEST] <cehoyos> Note that your configure line has multiple issues... [16:39:04 CEST] <Atlenohen> pkg config probably since I pasted it later on from a forum, but it didn't made a diff apparently [16:47:05 CEST] <cehoyos> Try: $ ./configure --toolchain=msvc --disable-all --enable-avformat --enable-avcodec --enable-gpl --enable-protocol=file --enable-muxer=webm,matroska,mpegts,rawvideo,mxf,frame* --enable-libx264 --enable-encoder=mpeg4,libx264*,bmp,ffv*,rawvideo [16:47:45 CEST] <Atlenohen> Will do [16:48:53 CEST] <Atlenohen> Althought I was thinking, maybe bcrypt is needed by framecrc/hash/md5 that looks related, those aren't that that super necessary (but it comes useful for debug), so I could do another test later without those [16:49:29 CEST] <cehoyos> You cannot disable it [16:49:50 CEST] <cehoyos> Sorry, you can, but you have to remove a header from your toolchain [16:50:14 CEST] <cehoyos> (Or patch the FFmpeg source code) [16:50:56 CEST] <furq> it's required for the matroska muxer [16:51:06 CEST] <cehoyos> ./configure --disable-autodetect --toolchain=msvc --disable-all --enable-avformat --enable-avcodec --enable-gpl --enable-protocol=file --enable-muxer=webm,matroska,mpegts,rawvideo,mxf,frame* --enable-libx264 --enable-encoder=mpeg4,libx264*,bmp,ffv*,rawvideo [16:51:21 CEST] <cehoyos> Is more similar to what you did (disable-autodetect) [16:51:30 CEST] <cehoyos> I don't know if it has an effect on bcrypt [16:52:07 CEST] <furq> bcrypt is used for av_get_random_seed on windows [16:52:10 CEST] <cehoyos> furq: I don't see a requirement for bcrypt or do I misundersatnd? [16:52:32 CEST] <furq> which is called a couple of times in matroskaenc [16:52:51 CEST] <furq> apparently the mxf muxer needs it as well [16:53:00 CEST] <cehoyos> Yes, but the function doesn't need it. [16:54:48 CEST] <Atlenohen> Building the first command - maybe the old libs were larger because they were build with debug (as I have the original configure command, or it looks like it, good thing it gets copied over to the .lib) [16:55:17 CEST] <Atlenohen> Debug is enabled here now, so it looks like it's the default. [16:56:45 CEST] <Atlenohen> Debug Symbols* - didn't made a difference to the size of he .a libs [16:56:48 CEST] <furq> i guess it's not required then but that's what's pulling it in [16:59:40 CEST] <furq> you can probably just use --disable-bcrypt if it's causing issues [17:01:26 CEST] <Atlenohen> No wait [17:01:52 CEST] <Atlenohen> cehoyos: I was looking at the old --prefix, it picked /usr/local in MSYS2 [17:02:59 CEST] <Atlenohen> the libraries appear to be of the expected size, slightly larger, 11 MB for libavcodec ... but is this due to debug symbols, idk, it's still at least positive indication. [17:03:16 CEST] <Atlenohen> the old was 9.x MB [17:05:32 CEST] <Atlenohen> What about cflags, loks like defining -I and -L wasn't necessary, but I hope the autodetect used -GS- for disabling Buffer Security [17:15:52 CEST] <furq> 15:59:40 ( furq) you can probably just use --disable-bcrypt if it's causing issues [17:15:55 CEST] <furq> ok apparently you can't do this [17:15:59 CEST] <furq> that's slightly annoying [17:18:21 CEST] <Atlenohen> I'm building C++ Solution right now with the first build [17:21:19 CEST] <Atlenohen> Looks like Swscale is required by the C++ solution, I'll have to rebuild ffmpeg [17:35:33 CEST] <Atlenohen> Yeah bcrypt again [17:36:49 CEST] <Atlenohen> yeah, debug symbols make a big diff in lib size [17:39:10 CEST] <cehoyos> ./configure --disable-autodetect --toolchain=msvc --disable-all --enable-avformat --enable-avcodec --enable-swscale --enable-gpl --enable-protocol=file --enable-muxer=webm,matroska,mpegts,rawvideo,mxf,frame* --enable-libx264 --enable-encoder=mpeg4,libx264*,bmp,ffv*,rawvideo [17:42:25 CEST] <Atlenohen> I would need to do multiple into the PKG config then [17:45:55 CEST] <Atlenohen> Sure, I found that environmental vars are set up, but they don't point directly to /um/x64 where bcrypt.lib is apparently, still checking [17:47:39 CEST] <Atlenohen> ah spoke too soon, it does [17:51:51 CEST] <Atlenohen> but can't check it if accessible in shell [17:52:03 CEST] <Atlenohen> tried cat bcrypt.lib but won't work. [18:05:13 CEST] <Atlenohen> I probably have to make universal pkgconfig and add another pkgconfig entry, not directly to just x264 [19:03:29 CEST] <Atlenohen> cehoyos: If I turn autodetect off wouldn't then some options which are enabled by default be turned on? Like pthreads? [19:12:51 CEST] <cehoyos> Atlenohen: (What you write - "wouldn't turning autodetect off turn autodetection on?" - makes little sense imo), either pthreads or win32threads is the default, I forgot which: Use either --disable-pthreads or --enable-w32threads if you don't like the default, no need to use both [19:14:07 CEST] <Atlenohen> Well since there's much less, i'd leave autodetect on, probably it's good to do it simple first, then define it more specifically later on [19:16:28 CEST] <cehoyos> No, I can see from your configure line that you do not want autodetection [19:16:56 CEST] <cehoyos> (I always recommend to leave it on and I regularly fight for more auto-detection but judging from your configure line it is not what you want) [19:17:21 CEST] <Atlenohen> But I'm not using mine anymore, i'm using your now [19:17:28 CEST] <cehoyos> Note that my recommendation - contrary to what you have used so far - is to do it simple first [19:18:22 CEST] <cehoyos> My suggestion from 16:51 was to turn auto-detect off [19:18:22 CEST] <Atlenohen> Well, it still works the same, right now I'm trying to combine PKGCONFIG for both x264 and Bcrypt [19:18:49 CEST] <cehoyos> But I am not sure what the default threads type for msvc is [19:19:16 CEST] <cehoyos> I don't think there is PKGCONFIG for Bcrypt... [19:19:31 CEST] <cehoyos> And you don't need it for x264 as it also works without [19:19:38 CEST] <cehoyos> (Some libraries absolutely need it) [19:19:55 CEST] <Atlenohen> I moved the pkgconfig for x264 and made it for Bcrypt in a central location inside msys64/usr/local/.../pkgconfig but it has trouble locating x264 [19:20:07 CEST] <Atlenohen> so I kinda have to fiddle with it [19:20:39 CEST] <Atlenohen> Because I can't link to just x264, I need included more than one dependency then [19:21:30 CEST] <cehoyos> Instead of fiddling supply --extra-cflags=-i/path/to/x264/include --extra-ldflags=-L/path/to/x264/library [19:21:48 CEST] <Atlenohen> Sure ... but what about bcrypt [19:21:58 CEST] <cehoyos> I have x264 on the same "level" as FFmpeg, so here it is: --extra-cflags=-I../x264 --extra-ldflags=-L../x264 [19:21:59 CEST] <Atlenohen> I never got cflags working anyway [19:22:08 CEST] <cehoyos> capital I... [19:23:08 CEST] <cehoyos> It's not difficult: clone x264, cd into x264, build it, cd .., clone FFmpeg, cd into FFmpeg, configure with --enable-gpl --enable-libx264 --extra-cflags=-I../x264 --extra-ldflags=-L../x264 [19:23:08 CEST] <Atlenohen> well I did i just left it as --extra-cflags=-I until you removed it which means it wasn't necessary at all as PKGCONFIG worked [19:23:33 CEST] <cehoyos> It should have returned an error imo because -I needs a parameter... [19:23:36 CEST] <cehoyos> awk [19:23:55 CEST] <Atlenohen> But it did work make, and I did put it in C++ and it was the same result, BCRYPT issue [19:24:53 CEST] <Atlenohen> I have x264 as separate gitrepo, I guess move the whole thing into ffmpeg then, along with bcrypt [19:25:24 CEST] <Atlenohen> Bcrypt is accessible, no idea why it doesn't take it, as if a config is missing, because it is part of INCLUDE environment that MS Dev Cmd makes [19:25:46 CEST] <Atlenohen> So I wanted to try to force bcrypt inclusion by making a pkconfig for it [19:29:39 CEST] <Atlenohen> The .a thing's pretty much done, i found LIBSUF whihc defines it, i'll force change it to .lib in the configure it self, done! :D [19:29:56 CEST] <Atlenohen> in the configure file it self* [19:43:10 CEST] <Atlenohen> cehoyos: well can you confirm the extact values, no dots, one dot, two dot -Ipath ? [19:43:28 CEST] <Atlenohen> actual folder like include, libs, or root one like x264 ? [20:05:09 CEST] <Atlenohen> cehoyos: nothing works with flags [20:05:42 CEST] <Atlenohen> that's why I came to pkconfig, I put all combinations, .. dots, one dot, no dots, no slash, while I had the x264 in ffmpeg and in usr/local [20:06:06 CEST] <Atlenohen> msys64/usr/local that is, now I typed out the full path, still nothing, it's broken or what [20:06:34 CEST] <Atlenohen> # ./configure --toolchain=msvc --extra-cflags=-I/c/msys64/usr/local/dependency/x264/include --extra-ldflags=-L/c/msys64/usr/local/dependency/x264/lib [20:10:45 CEST] <Atlenohen> if it given me the path where is it searching [20:11:14 CEST] <Soni> can ffmpeg hwdecode with my GPU and hwencode with my CPU? [20:14:38 CEST] <ncouloute> yes it can [20:18:25 CEST] <garyserj> What commands would help convert an mp4 with this profile https://pastebin.com/raw/XD5YnaLg into an mp4 with this profile https://pastebin.com/raw/b5xqFLxy ? [20:28:51 CEST] <ncouloute> Soni you can specify the decoder before the input (-i) for example for nvidia. (-hwaccel cuvid -c:v h264_cuvid -i "Path\to\ConvertMe.mp4") [20:29:54 CEST] <ncouloute> garyserj - unlikely someone will give you the exact flags. It isn't that hard to figure it out. Documentation for that kind of stuff is pretty good. [20:31:15 CEST] <Soni> what about intel and amd (mesa)? [20:34:37 CEST] <ncouloute> -hwaccel qsv -c:v h264_qsv -i "Path\to\ConvertMe.mp4" for intel. I'm not sure there is a AMD specifi decoder yet. I know there is an encoder. At least not in the zeranoe i use. There are a few generic hw decoders that arent brand specific [20:37:07 CEST] <Atlenohen> cehoyos: That does it had to put an end to this, deep monitoring: I can see that CL.exe is accessing bcrypt.h in the configuration process, which surely means it's also possible in the making process, and link.exe is accessing crypt.lib in the default directory, it first tries to find it in the ffmpeg repo root directory, tries a few other MS directories and then finds it in the existing default location [20:38:23 CEST] <Atlenohen> I think I have the latest or at least almost latest Win10 SDK ... what if the bcrypt is TOO HIGH version ???? [20:38:39 CEST] <Atlenohen> C:\Program Files (x86)\Windows Kits\10\Lib\10.0.17134.0\um\x64\bcrypt.lib [20:48:22 CEST] <garyserj> ncouloute: both are x264 and both are AAC so i've no idea [20:49:33 CEST] <garyserj> the main difference is one of them have "writing library" and "encoding settings" and the other doesn't [20:49:59 CEST] <garyserj> but i've no idea how to convert one that does into one that doesn't [20:53:24 CEST] <Atlenohen> Cehoyos: okay we got the full picture now, cflags actually works, it forwards the -I/path parameter to CL.exe, CL.exe finds x264.h successfully [20:54:48 CEST] <Atlenohen> Cehoyos: link.exe receives nothing from --extra-ldflags and this is probably what I was hinting at previously, there is no "-L" option I found on the MS documentation sites I checked 2 days ago (i'll do again as soon as I finish writing this) [20:55:06 CEST] <Atlenohen> It must be a legacy option that was deprecated and removed, replaced [20:56:01 CEST] <Atlenohen> so link.exe (not the MSYS2 link.exe, i disabled that, this is actual MSVC link.exe) first looks into the ROOT FFMPEG directory where were configuring, it doesn't find it. [20:56:49 CEST] <Atlenohen> Link.exe then tries C/msys64/mingw64/lib/ directory, doesn't find it, then it tries the FFMPEG root again [20:58:02 CEST] <Atlenohen> It then tries 3 other Windows Kits "lib" directories (which are part of $INCLUDE and other env variables), doesn't find it there obviously, then tried FFMPEG root again, and that's it, nothing found so we get an error in MSYS2 MINGW64 Shell [20:59:41 CEST] <Atlenohen> The workaround is obviously to try to move it there where it's looking at, or using the PKCONFIG which worked previously, but PKCONFIG's also hit and miss, I'll debug it as well to get an idea [20:59:55 CEST] <Atlenohen> PKGCONFIG* [21:01:11 CEST] <Atlenohen> https://docs.microsoft.com/en-us/cpp/build/reference/libpath-additional-lib… let's try this [21:03:44 CEST] <Atlenohen> didn't work, maybe the whole --extra-ldflags is broken the way it's scripted, i'll see... I'm pretty much developing ffmpeg at this point lol [21:03:57 CEST] <Atlenohen> debugging it at least [21:04:38 CEST] <Atlenohen> I have no choice but to go to the bottom of it, and well, probably would be great if I can contribute back too. [21:40:02 CEST] <ncouloute> garyserj - In the case of encoding settings and writing library. That is telling you that the original file was made with x264 using those specific flags. You care more about the resulting file info as you are trying to emulate that [21:56:36 CEST] <_bt> hello, i have some 1080p60 h264 video which i want to timelapse. i'm using 'ffmpeg -i 2019_0412_202119_001.MP4 -vf framestep=30,setpts=N/60/TB,fps=60 -an out.mp4' to create the timelapse. it works well, but the output file is the same length as the input file, only with the last frame displayed for the remainder of the video. where am i going wrong? [22:11:57 CEST] <_bt> cracked it: ./ffmpeg -discard nokey -i 2019_0412_202119_001.MP4 -vf "setpts=0.0120*PTS" -an out3.mp4 [22:12:00 CEST] <_bt> see ya [22:12:26 CEST] <poutine> I feel like that guy has been asking the same question for months now [22:15:07 CEST] <HickHoward> uhhh [22:15:16 CEST] <HickHoward> how as ATRAC3 reverse-engineerred in the first place? [22:17:35 CEST] <JEEB> by finding a decoder and looking what it did inside [22:17:51 CEST] <JEEB> nowadays you can get rather fancy decompilers etc in open source [22:17:56 CEST] <JEEB> like NSA's ghidra being the latest [22:19:07 CEST] <JEEB> sometimes of course you might also find something documenting the format [22:19:10 CEST] <JEEB> often this is not the case [22:19:42 CEST] <JEEB> and then you have people documenting their findings [22:19:46 CEST] <JEEB> f.ex. https://wiki.multimedia.cx/index.php/ATRAC3plus [22:21:45 CEST] <faLUCE> JEEB: yesterday I got an answer from MPEG LA [22:22:41 CEST] <HickHoward> he [22:22:45 CEST] <HickHoward> *heh [22:25:05 CEST] <durandal_1707> faLUCE: and? [22:25:35 CEST] <faLUCE> durandal_1707: they told me that "Based on your explanation below, I understand that you will not be offering end products with AVC functionality for Sale. Rather, you will simply publish source code. Therefore, your understanding is correct that you would not benefit from coverage under our AVC License in that case." [22:27:23 CEST] <faLUCE> what could it mean? does it mean that the license is not required? [22:28:34 CEST] <faLUCE> it seems to confirm what the old threads pasted by JEEB said [22:29:14 CEST] <faLUCE> (given that source code is not an end product) [22:32:05 CEST] <faLUCE> yes, it confirms that [22:33:46 CEST] <faLUCE> then MPEG-LA seems to be perfectly compatible with FOSS non commercial stuff [22:50:17 CEST] <iive> faLUCE, the last statement doesn't seem correct [22:50:32 CEST] <faLUCE> iive: why? [22:51:33 CEST] <iive> they told you that simply publishing the source code is OK. that has always been the case. [22:51:49 CEST] <iive> distributing working program for free is separate issue [22:51:56 CEST] <faLUCE> iive: yes, you are right [22:52:03 CEST] <iive> so is distributing working program for money. [22:53:06 CEST] <iive> that's why cisco basic avc codec exists... [22:53:26 CEST] <faLUCE> iive: anyway, the important thing is that MPEG LA is absolutely not against non commercial open source [22:53:33 CEST] <faLUCE> this is very good [22:54:31 CEST] <faLUCE> I think it's ethical [22:59:09 CEST] <cehoyos> Atlenohen: It's unlikely that we would accept a change to how --extra-ldflags work, it is working for many people for a very long time. [22:59:14 CEST] <cehoyos> Please explain what is not working for you [23:00:39 CEST] <cehoyos> " then MPEG-LA seems to be perfectly compatible with FOSS non commercial stuff" [23:00:43 CEST] <cehoyos> No, this is not correct [23:00:51 CEST] <cehoyos> And please do not repeat this again and again [23:01:18 CEST] <cehoyos> "anyway, the important thing is that MPEG LA is absolutely not against non commercial open source" [23:01:27 CEST] <cehoyos> This is of course also not true, on the contrary [23:01:42 CEST] <faLUCE> cehoyos: why? [23:08:22 CEST] <cehoyos> The MPEG-LA tries (actively) to oppress the freedoms that open source implies: They do not allow re-distribution. [23:09:01 CEST] <cehoyos> The re-distribution that free software implies of course includes binary distribution, it is not limited to source distribution. [23:09:32 CEST] <cehoyos> Note that I clearly remember a C interpreter, I wonder what happens if MPEG-LA remembers it;-) [23:10:44 CEST] <faLUCE> cehoyos: I did not even know that a C interpreter does exist! [23:11:03 CEST] <faLUCE> cehoyos: but would it have performance issues...? [23:13:42 CEST] <cehoyos> Yes =-) [23:13:59 CEST] <JEEB> cehoyos: I would guess the intent of the distributor is what will end up meaning something in the courts :) f.ex. "just distributing code" in python or JS and expect that to be OK in their eyes (in case you get on one of these patent licensing things' radar) [23:14:23 CEST] <JEEB> but yes, all this patent licensing is a mess :P [23:14:35 CEST] <JEEB> full of "let's make things not clear to not make promises" [23:14:53 CEST] <faLUCE> JEEB: but a native python x265 encoder would never exist... [23:15:32 CEST] <JEEB> why not? just like fabrice made a JS decoder (not sure if he used emscripten with HM or the lavc thing) [23:16:07 CEST] <faLUCE> JEEB: I mean _encoders_ .... because it would not take full advantage of the current technology [23:16:33 CEST] <cehoyos> My point is just that this isn't patent-law-exchange, and it would be great if we could agree that we cannot know what exactly the MPEG-LA thinks. I still don't know faLUCE's use case... [23:16:42 CEST] <JEEB> very true [23:16:47 CEST] <JEEB> we are all very much not lawyers [23:16:58 CEST] <JEEB> (and even if we are, we don't want to give out law advice) [23:16:59 CEST] <cehoyos> I usually read irc-log and this goes on for far too long;-) [23:17:09 CEST] <cehoyos> Correct! [23:17:43 CEST] <faLUCE> I was interested in understanding all the sides of open source digital-audio video [23:18:02 CEST] <faLUCE> because I see that it's a mess! [23:18:43 CEST] <faLUCE> anyway, I'm thinking seriously to switch to theora [23:19:11 CEST] <faLUCE> from what I read, its current quality is comparable to h264 [23:19:21 CEST] <JEEB> o_O [23:19:32 CEST] <faLUCE> not true? [23:20:40 CEST] <JEEB> I would be very surprised :D libvpx and friends came out (plus then daala/libaom/rav1e etc). so the theora encoder's issues such as rate control I think never got resolved. [23:20:59 CEST] <JEEB> I remember derf talking about the rate control fixes a few years ago at VDD [23:21:32 CEST] <HickHoward> is it just me or am i the only one who thinks that Ogg Opus is not a good audio codec? [23:21:34 CEST] <JEEB> basically, while theora encoding could be improved, the effort went into more modern formats [23:21:38 CEST] <faLUCE> JEEB: which kind of issue? it's not possible to change bitrate on fily? [23:22:10 CEST] <faLUCE> or is it a more general problem? [23:22:21 CEST] <JEEB> I wish I remembered the details [23:23:11 CEST] <cehoyos> Why do you believe that it is a mess? And is there a specific reason why you want to "understand" all sides? [23:23:35 CEST] <JEEB> ooh, https://git.xiph.org/?p=theora.git;a=commit;h=eac29ae2f9c748cb4a0a3fc381002… [23:23:42 CEST] <JEEB> so the mentioned issue might have gotten fixed :) [23:23:52 CEST] <cehoyos> But the technology is not up-to-date [23:24:10 CEST] <JEEB> yea [23:24:14 CEST] <cehoyos> The idea that libtheora's is equal to x264 makes not much sense to me. [23:24:18 CEST] <JEEB> theora was vp3++ [23:24:19 CEST] <faLUCE> cehoyos: because before three months ago I did not knew anything detailed about patent question [23:24:22 CEST] <faLUCE> s [23:24:33 CEST] <JEEB> patents don't really relate to open source as such [23:24:42 CEST] <JEEB> it's in a way relevant to all software, and yes - it's a mess [23:25:08 CEST] <cehoyos> I am not 100% convinced that you know many details now and I wonder why you want to know them. [23:25:43 CEST] <faLUCE> cehoyos: because I would like to work more and more with open source video stuff [23:26:33 CEST] <damdai> cehoyos why are you keep closing my bug report for no reason [23:26:38 CEST] <faLUCE> [23:25] <cehoyos> I am not 100% convinced that you know many details <-- in fact it's a mess [23:27:23 CEST] <JEEB> dongs: no problemos. not sure if it was much more than maybe a ping regarding a possibility of getting a sample of the 22.2ch AAC to see how it's bolted together [23:27:26 CEST] <Atlenohen> cehoyos: none of the combinations of -cflags and ldflags have worked that I tried, would you be able to provide an exact working example ? [23:30:24 CEST] <cehoyos> I provided one (the one I use) at 19:23 but if pkg-config works for you, please use it! [23:31:02 CEST] <cehoyos> faLUCE: We all work (more and more) with open source video stuff and we try not to think about patents - what is the reason that you want to think of them? [23:31:17 CEST] <cehoyos> damdai: Would you like to tell me which ticket you talk about? [23:31:51 CEST] <Atlenohen> cehoyos: whether or not PKGCONFIG works, if flags don't work it's a bug of some kind [23:31:57 CEST] <damdai> cehoyos http://trac.ffmpeg.org/ticket/7824 [23:32:19 CEST] <Atlenohen> PKGCONFIG needs to support more than one library, not only x264 [23:32:25 CEST] <Atlenohen> If it can't do that it's useless [23:32:32 CEST] <cehoyos> Again: They work fine, if they don't work for you, I am happy to help you find out why but if pkg-config works for you (it doesn't work for me on many operating systems), that may save us both time. [23:33:25 CEST] <JEEB> I think it's worthwhile checking the differnce between the make V=1 output between the two ways [23:33:40 CEST] <Atlenohen> cehoyos: Yes PKGCONFIG hasn't been working when I tried to combine it with other than x264 [23:33:40 CEST] <cehoyos> damdai: Ticket 7824 has not similarities to a valid ticket, I really don't know why you are surprised that I closed it. [23:33:49 CEST] <faLUCE> cehoyos: because I wanted to be sure that publishing source code is OK. it would be much better to publish also binaries, but from what I see, it's a mess (and it depends also on the laws country where you are). Then, in my next projects I wonder which codec could I use without all this mess [23:33:51 CEST] <damdai> cehoyos bug still exist [23:34:20 CEST] <Atlenohen> JEEB: This is only the ./configure process, it can't get past that yet (I know it works one way, but that was is not really practical) [23:34:21 CEST] <faLUCE> so I thought about theora, based on what I read on wikipedia, but now you are telling me that is not comparable to h264 [23:34:48 CEST] <cehoyos> damdai: No, there is no bug. FFmpeg's implementation of dst uses 352800Hz, if you are unhappy about it, don't use it. [23:35:07 CEST] <cehoyos> If you don't believe me: It is trivial to replace this value but this will break compilation;-( [23:35:20 CEST] <JEEB> Atlenohen: ok, the configure script outputs its stuff in ffbuild/config.log [23:35:33 CEST] <JEEB> so you should be able to compare whatever is your failing and succeeding configuration [23:35:42 CEST] <damdai> cehoyos but it shouldn't show as 352800Hz [23:35:51 CEST] <damdai> how is that not a bug [23:35:52 CEST] <cehoyos> faLUCE: What do you mean with sure? There are more than one thousand contributors in FFmpeg, what problem could you have that they do not have? [23:36:01 CEST] <Atlenohen> JEEB: That has not been helpful most of the time I checked it, but I'll do it again, it only says "x264.h" not found and that's it [23:36:10 CEST] <cehoyos> damdai: Again, this is how it is implemented, this is not a bug as long as the output sounds correct. [23:36:30 CEST] <damdai> cehoyos well i am just doing ffprobe [23:36:33 CEST] <JEEB> Atlenohen: it should have the check (code) and the actual commands utilized for checking in there [23:36:59 CEST] <cehoyos> Atlenohen: In case your issue is that bcrypt has nothing to do with pkg-config than you can neither fix this in pkg-config nor with --extra-flags: Both are not related to bcrypt. [23:37:17 CEST] <faLUCE> cehoyos: "There are more than one thousand contributors in FFmpeg, what problem could you have that they do not have?" <--- this is true... but what could happen if tomorrow MPEG LA changes their rules? [23:37:18 CEST] <damdai> cehoyos so if a 22khz mp3 file show as 44khz mp3 file on ffprobe, you are saying that is not a bug then? [23:37:37 CEST] <cehoyos> damdai: As said: If you are not happy about our dst implementation, just use another one;-) [23:37:42 CEST] <Atlenohen> LDFLAGS=' -L/c/msys64/usr/local/dependency/x264/lib' [23:37:46 CEST] <damdai> cehoyos answer my question [23:37:47 CEST] <damdai> cehoyos so if a 22khz mp3 file show as 44khz mp3 file on ffprobe, you are saying that is not a bug then? [23:37:57 CEST] <JEEB> damdai: if the decoded output is correct, then it is "only" an issue with the output of the information provided at the probe [23:38:09 CEST] <JEEB> if the actual *decode* is incorrect, that's a separate case [23:38:20 CEST] <cehoyos> That would likely be a bug because our mp3 implementation requires that the output has the frequency that you want to hear. [23:38:40 CEST] <cehoyos> I suspect it would be possible to change the mp3 decoder so that it shows another frequency and still works. [23:38:50 CEST] <cehoyos> (Note that this is exactly what happens for some aac files) [23:39:19 CEST] <Atlenohen> JEEB: does that mean it's trying to pass linux-paths to a windows utility? cl -nologo -I/c/msys64/usr/local/dependency/x264/include -c -Fo./ffconf.xwinK8u6/test.o ./ffconf.xwinK8u6/test.c [23:39:20 CEST] <damdai> i expect 22khz mp3 file show to show as 22khz mp3 file in ffprobe [23:39:26 CEST] <cehoyos> faLUCE: Then - sad as it is for us and maybe for you - you should not contribute to FFmpeg. [23:40:00 CEST] <faLUCE> cehoyos: in addition, I was about fsf complaining MPEG-LA... so my thought was.. should I continue to use MPEG stuff or do I have to switch to theora and opus. I tried opus in the last two months and I was very satisfied [23:40:14 CEST] <cehoyos> damdai: That is correct for the current mp3 decoder implementation, it could (theoretically) change in the future, as said for some aac files this is exactly what happens. [23:40:26 CEST] <JEEB> Atlenohen: yes. although do remember that msys(2) has funky utilities to convert stuff in flight [23:40:28 CEST] <cehoyos> you were about or it was about? [23:41:16 CEST] <cehoyos> Now you are saying "use": Do you want to use FFmpeg or do you want to contribute to FFmpeg? I believe these are two differect things (I very, very rarely use FFmpeg) [23:41:36 CEST] <faLUCE> cehoyos: I would like to contribute too. [23:41:55 CEST] <cehoyos> Then please do, man power (time) is the only limiting factor;-) [23:42:18 CEST] <faLUCE> cehoyos: I did in the past! And in this channel I try to help newbies [00:00:00 CEST] --- Sun Apr 14 2019

1 0

ffmpeg-devel.log.20190412
by burek 13 Apr '19

13 Apr '19

[01:32:20 CEST] <atomnuker> how many people are going to write ec code simd for dav1d before I get the clue giving it to someone else was a bad idea? [01:33:26 CEST] <atomnuker> and the last 2 attempts are going the wrong way about it by assuming a specific cdf size [01:34:18 CEST] <nevcairiel> optimizing the most common cases seperately is the essence of making stuff fast =p [01:34:31 CEST] <jamrial> you should join #dav1d and mention it there [01:35:18 CEST] <atomnuker> not when there's no need for it, my code was at least generic and overwrote/read as it saw fit as it padded all CDFs and just needed a loop for when they were big [01:36:21 CEST] <atomnuker> actually I don't think they got big enough to need a loop at all, IIRC they fit in a single 256bit reg [01:37:57 CEST] <atomnuker> oh well, I'll rewrite it when we port the codebase to lavc, no way I'm giving my code away to big corps under MIT [01:39:32 CEST] <atomnuker> well, I do if they pay [01:40:02 CEST] <BBB> <3 [01:40:39 CEST] <BBB> atomnuker: in the end it's about speed [01:40:56 CEST] <BBB> your (our? I wrote part of that also) code didn't speed it up half as much as this code appears to do [01:41:14 CEST] <atomnuker> it was unfinished IIRC [01:41:28 CEST] <BBB> another issue, yes :) [01:42:17 CEST] <atomnuker> I'll admit for small CDF sizes it didn't speed things up, it turns out avx2 is kinda too heavy [01:43:17 CEST] <atomnuker> I think that was what I had to finish, specialcase 128bit simd for small CDFs [01:45:07 CEST] <atomnuker> hmm, maybe even have separate functions for avx2/sse (macro'd in at runtime based on cdf size) since you don't want another branch [10:02:25 CEST] <kurosu> it makes sense to optimize aggressively the most costly case, and then more generically the other ones [16:58:30 CEST] <BtbN> Ghidras decompiler has very weird ways to express things. "state_byte = (uint)CONCAT11(1,(char)uVar2);" This is "movzx eax,al; or ah,1", so essentially (uVar2 & 0xFF) | 0x100. [16:59:26 CEST] <BtbN> There is zero results about CONCAT11 in its docs for all I can tell [17:03:23 CEST] <BtbN> This code I'm analysing is also doing highly weird things. It has an elaborate function to get the next byte from a buffer, which returns data[pos] | (pos & ~0xff). But every instance of it using that function immediately applies & 0xFF to the result. Like... what are you doing there? [17:15:02 CEST] <ubitux> the use of these CONCAT thing is often due to bad type set on the variables/arguments [17:15:13 CEST] <ubitux> (or the use of SIMD) [17:15:33 CEST] <ubitux> check again the type you set [17:19:13 CEST] <BtbN> The types look proper to me [17:19:24 CEST] <BtbN> Looks like a compiler optimization to me [17:20:20 CEST] <BtbN> Which optimized EAX=(EAX & 0xFF) | 0x100 to MOVZX EAX,AL; OR AH,1 [18:29:50 CEST] <philipl> BtbN: what do you think of Yogender's reply? [18:30:39 CEST] <BtbN> I have no idea. Requiring that the input pointers stay "alive" for the whole runtime of the encoder is not _that_ unreasonable. [18:35:03 CEST] <philipl> It seems like you'd have to go out of your way to write your custom pipeline where that's hard to achieve. [00:00:00 CEST] --- Sat Apr 13 2019

1 0

ffmpeg.log.20190412
by burek 13 Apr '19

13 Apr '19

[00:01:02 CEST] <faLUCE> JEEB: it's strange that this discussion is of about 10 years ago... [00:01:08 CEST] <faLUCE> what happened meanwhile? [00:01:18 CEST] <JEEB> (Ž4@) [00:04:32 CEST] <faLUCE> JEEB: note that: [00:04:33 CEST] <faLUCE> https://www.openh264.org/faq.html [00:04:54 CEST] <faLUCE> " In order for Cisco to be responsible for the MPEG LA licensing royalties for the module, Cisco must provide the packaging and distribution of this code in a binary module format (think of it like a plug-in, but not using the same APIs as existing plugins), in addition to several other constraints" [00:05:08 CEST] <JEEB> yes, cisco distributes binaries that f.ex. firefox then downloads [00:05:21 CEST] <JEEB> this way cisco is distributing the binaries [00:05:25 CEST] <faLUCE> JEEB: it confirmes what the quoting of ryan said [00:05:58 CEST] <JEEB> it's the more or less common understanding of what *MPEG-LA* wants [00:07:19 CEST] <faLUCE> JEEB: so, openh264 source code doesn't pay MPEG-LA ? [00:07:43 CEST] <JEEB> what [00:08:39 CEST] <faLUCE> JEEB: yes, look at that. The binary has another license than the source code [00:08:43 CEST] <faLUCE> "Additionally, this binary is licensed under Ciscos AVC/H.264 Patent Portfolio License from MPEG LA, at no cost to you, provided that the requirements and conditions shown below in the AVC/H.264 Patent Portfolio sections are met. " [00:08:53 CEST] <JEEB> that is not a software license [00:08:56 CEST] <faLUCE> while the source code is BSD [00:08:59 CEST] <JEEB> that is a patent license [00:09:02 CEST] <JEEB> separate things [00:09:22 CEST] <faLUCE> ok, but I mean: the patent license is applied only to the binary [00:09:28 CEST] <faLUCE> not to the source code [00:09:41 CEST] <faLUCE> even if the source code has patented algos [00:10:19 CEST] <JEEB> that is the common understanding of how it goes with MPEG-LA, yes. do note that unless cisco has this in writing from mpeg-la, mpeg-la could choose to change its mind [00:10:34 CEST] <JEEB> of course probably, maybe that is unlikely to happen [00:10:38 CEST] <JEEB> but welcome to legalese [00:10:58 CEST] <JEEB> although cisco already pays the maximum license amount [00:11:01 CEST] <faLUCE> JEEB: ok, but this license clarifies all [00:11:05 CEST] <JEEB> so for cisco it wouldn't matter at all :P [00:12:15 CEST] <faLUCE> FOSS source code doesn't require license from MPEG LA, while binary requires patent license [00:12:31 CEST] <faLUCE> they WROTE that, so.... [00:12:37 CEST] <JEEB> cisco did, yes [00:12:51 CEST] <JEEB> I'm not saying this is not the common understanding [00:12:53 CEST] <JEEB> just details :P [00:13:19 CEST] <faLUCE> JEEB: but note this is an important doc, because your thread is old and without explicit quotes [00:13:30 CEST] <faLUCE> instead, this is a sort of legal doc by cisco [00:13:31 CEST] <JEEB> is this an explicit quote? [00:13:40 CEST] <faLUCE> yes, it's the cisco license [00:13:45 CEST] <faLUCE> https://www.openh264.org/BINARY_LICENSE.txt [00:14:25 CEST] <JEEB> yup, that's just cisco's understanding [00:14:39 CEST] <JEEB> most likely they talked with MPEG-LA and it will hold :P [00:14:48 CEST] <faLUCE> ok, but it something more "official" [00:14:53 CEST] <faLUCE> than the old thread [00:15:00 CEST] <faLUCE> (it is) [00:15:27 CEST] <faLUCE> JEEB: otherwise even CISCO would be in violation! [00:15:42 CEST] <JEEB> of course, but they already pay the max :D [00:15:55 CEST] <JEEB> that's why they are distributing it [00:16:00 CEST] <JEEB> because it doesn't cost anything to them [00:16:03 CEST] <JEEB> and it's good PR [00:16:44 CEST] <JEEB> faLUCE: also was there a spot where it notes that the source code is not applicable? either in the txt or the site. [00:16:51 CEST] <JEEB> we both know that's most likely what MPEG-LA thinks [00:16:56 CEST] <JEEB> but yunno :P welcome to legal stuff [00:16:59 CEST] <JEEB> it's all vague [00:17:19 CEST] <faLUCE> JEEB: yes, there is that spot: [00:17:21 CEST] <faLUCE> https://www.openh264.org/faq.html [00:17:47 CEST] <faLUCE> "In order for Cisco to be responsible for the MPEG LA licensing royalties for the module, Cisco must provide the packaging and distribution of this code in a binary module format (think of it like a plug-in, but not using the same APIs as existing plugins), in addition to several other constraints. This gives the community the best of all worlds - a team can choose to use the source code, in which case the team is [00:17:48 CEST] <faLUCE> responsible for paying all applicable license fees, or the team can use the binary module distributed by Cisco, in which case Cisco will cover the MPEG LA licensing fees." [00:18:18 CEST] <faLUCE> ----> this means that the first one who makes binaries, has to pay MPEG-LA [00:18:25 CEST] <JEEB> no [00:18:26 CEST] <JEEB> not make [00:18:27 CEST] <JEEB> distribute [00:18:30 CEST] <faLUCE> yes [00:18:32 CEST] <faLUCE> distribute [00:18:45 CEST] <JEEB> I could make the binary to a company, and the company would distribute it [00:19:15 CEST] <JEEB> according to the common understanding the company would thus be the end-user distributor [00:20:15 CEST] <JEEB> faLUCE: also do note how that quote does not specifically say that the source code is not relevant to the MPEG-LA licensing. it's the common understanding, but it is /not/ mentioned there. [00:20:23 CEST] <JEEB> not trying to be an asshole, just noting it :P [00:22:01 CEST] <faLUCE> JEEB: it says: "a team can choose to use the source code, in which case the team is responsible for paying all applicable license fees" [00:22:16 CEST] <faLUCE> which means that "source code itself is not subject to fees" [00:22:45 CEST] <damdai> anybody know what it means by "fragmented" and "cbcs" ? http://download.opencontent.netflix.com/?prefix=AV1/Chimera/ [00:24:29 CEST] <JEEB> faLUCE: no it does not. it just says that if you don't use cisco's binary it is of course not licensed [00:24:47 CEST] <JEEB> you can /read/ it like you do [00:24:58 CEST] <JEEB> it doesn't /say/ it [00:25:29 CEST] <faLUCE> JEEB: I'm talking about the non-binary case [00:25:36 CEST] <faLUCE> for an user too [00:25:59 CEST] <faLUCE> so, an user that uses cisco's code for making another non-binary library [00:27:16 CEST] <JEEB> faLUCE: but see how it specifically say what you read out of it :P it does /not/ say "source code itself is not subject to fees". it /only/ says "if you choose to use the source code, you are responsible for handling any applicable license fees" [00:27:33 CEST] <faLUCE> JEEB: ok, but it can be deduced [00:27:46 CEST] <JEEB> no it cannot be. it is the common understanding though. [00:27:53 CEST] <JEEB> that mpeg-la does not care about source [00:28:05 CEST] <JEEB> anyways, good night :) [00:28:12 CEST] <faLUCE> good night :-) [00:29:40 CEST] <kevinnn> does anyone know why some routers block UDP traffic and others don't? Specifically for rtsp streams [00:31:05 CEST] <faLUCE> kevinnn: by closing ports [00:31:06 CEST] <faLUCE> ;-) [00:31:54 CEST] <kevinnn> faLUCE: how do I get my routers not to do that? it is affecting my performance [00:31:55 CEST] <kevinnn> also... [00:32:01 CEST] <kevinnn> apple's facetime [00:32:06 CEST] <kevinnn> that goes over rtp [00:32:10 CEST] <kevinnn> which is UDP [00:32:18 CEST] <kevinnn> but it doesn't seem to be blocked [00:32:37 CEST] <faLUCE> kevin, be more precise [00:32:40 CEST] <kevinnn> or do they also revert to TCP when UDP is blocked [00:32:48 CEST] <faLUCE> yes, it can be [00:32:58 CEST] <faLUCE> kevinnn: you should a test with netcat [00:33:05 CEST] <kevinnn> but the other thing is I tested with netcat [00:33:08 CEST] <kevinnn> yes exactly [00:33:20 CEST] <faLUCE> and what netcat said? [00:33:21 CEST] <kevinnn> and it seems like UDP traffic gets through just fine [00:33:32 CEST] <kevinnn> but for some reason rtsp still defaults to tcp [00:33:35 CEST] <kevinnn> as opposed to UDP [00:33:41 CEST] <kevinnn> it is very confusing [00:33:55 CEST] <faLUCE> kevinnn: it works in this way [00:34:13 CEST] <faLUCE> the RECEIVER asks to the STREAMER a rtsp description [00:34:38 CEST] <faLUCE> then the receiver allocates resources based to this description [00:34:50 CEST] <faLUCE> then the streamer sends stuff over UDP [00:35:24 CEST] <faLUCE> RTSP is TCP, while RTP is UDP [00:35:54 CEST] <faLUCE> now, given that your player doesn't allow you to allocate a netcat receiver [00:36:02 CEST] <faLUCE> use a SNIFFER [00:36:04 CEST] <faLUCE> ok? [00:36:29 CEST] <kevinnn> faLUCE: okay use a sniffer to determine if rtp is being passed via UDP or tcp? [00:36:52 CEST] <faLUCE> yes [00:37:07 CEST] <kevinnn> because on some routers (like mine) vlc produces this error when connecting to an rtsp stream: no data received in 10s. Switching to TCP [00:37:17 CEST] <kevinnn> okay, let me download and install a sniffer [00:38:10 CEST] <faLUCE> [00:37] <kevinnn> because on some routers (like mine) vlc produces this error when connecting to an rtsp stream: no data received in 10s. Switching to TCP <--- then you should already know if it's TCP or UDP [00:38:29 CEST] <kevinnn> right... but I don't want it to be [00:38:37 CEST] <kevinnn> I want it to be UDP [00:38:50 CEST] <kevinnn> and it is my router so I should be able to configure it like so [00:39:03 CEST] <kevinnn> but there don't appear to be any settings that allow me to adjust that [00:39:42 CEST] <faLUCE> kevinnn: this is another problem [00:40:10 CEST] <kevinnn> faLUCE: I know... but for my specific use case TCP adds too much latency [00:40:17 CEST] <kevinnn> the stream must be in UDP [00:40:46 CEST] <faLUCE> kevinnn: first check if it's TCP instead of UDP [00:41:04 CEST] <kevinnn> okay, I will check with wireshark, give me a sec [00:41:25 CEST] <faLUCE> kevinnn: also note that TCP doesn't introduce significant latency [00:41:33 CEST] <faLUCE> you can drop frames [00:41:57 CEST] <kevinnn> for bi-directional streaming, every millisecond of latency counts [00:42:28 CEST] <faLUCE> kevinnn: not if they have the same latency [00:43:15 CEST] <kevinnn> TCP always higher latency than UDP does doesn't it? [00:43:31 CEST] <kevinnn> I mean it physically feels slower when i use tcp vs udp [00:43:55 CEST] <faLUCE> yes, but it doesn't mean that it's higher in a significant way for you [01:48:01 CEST] <garyserj> I have this video that won't upload to youtube. I used ffmpeg to cut 1 second of it so I have a very small example file. That gives the same error from youtube The video is available here http://ge.tt/1wtKlWv2 and is 98KB in size. The story is I had a bunch of .3gp videos on my phone, I converted them to mp4. For some inexplicable reason a few 90 degrees rotated or needed a vertical flip, [01:48:01 CEST] <garyserj> which I did with -vf "transpose=1" or -vf "transpose=vflip". One of the videos (I don't know if it's one that needed rotating or flipping), but it's not uploading. mediainfo shows https://pastebin.com/raw/YXdiTxeu e.g. mp4(AVC,AAC) so I am not sure the problem or how can change it so it uploads. [02:38:23 CEST] <fella> garyserj: nothing that strikes my eye, but see for yourself: https://support.google.com/youtube/answer/1722171 [02:38:39 CEST] <fella> what's the err you get? [03:08:25 CEST] <garyserj> fella: "The video has failed to process. Please make sure you are uploading a supported file type." [03:37:49 CEST] <garyserj> fella: just tried importing to movie maker and saving, and it worked, and I made a cut of the working one. http://ge.tt/1jovrWv2 i'm interested if i can use ffmpeg to turn the bad one into the good one? [08:44:23 CEST] <fella> garyserj: could you post the 'mediainfo' of the working one as well? [12:12:16 CEST] <aleek> hello! [12:14:07 CEST] <aleek> we are trying to transcode live stream of regular tv. We have mpeg2ts subtitles Elementary Stream, but usually it is empty, because there is no subtitles at the moment. I cannot start ffmpeg, until it finds at least one subtitle frame. Can we somehow overcome that? [12:19:00 CEST] <JEEB> not sure the probe function would do that [12:37:53 CEST] <DHE> failure to detect the input codec causing fail? [12:38:34 CEST] <xerpi> Hi, I'm trying to use ffmpeg (libavcodec to do video decoding specifically) on bare-metal, without any OS beneath [12:38:56 CEST] <xerpi> I can provide my own implementations of simple libc functions such as memcpy, strlen, etc [12:39:45 CEST] <xerpi> But I see that for example file_open.c of libavutil, which uses open() and the like, is unconditionally compiled [13:43:26 CEST] <dongs> JEEB: im sorry, im gulag'd in korea/taiwan so i probably missed your message. i saw a highlight here. but it scrolled off my screen [14:42:09 CEST] <Numline1> Hey folks. I'm looking to implement this one thing in Go and I wonder if I could use ffmpeg for that. I need to process a video and extract one frame for each second of the video. This frame should be as stable as possible, meaning no blurry mid-frames and stuff. Would this be possible? Thanks! [14:43:05 CEST] <BtbN> That depends on the material. If the source material uses tons of motion blur, you're gonna get motion blur. [14:45:29 CEST] <BtbN> Extracting frames will not mix multiple together unless you explicitly use a filter for that. [14:48:19 CEST] <Atlenohen> furq: Looks like it's the other way around /GS checks for buffer security, not disables it https://docs.microsoft.com/en-us/cpp/build/reference/compiler-options-liste… [14:49:05 CEST] <Atlenohen> unless, the minus after it [14:49:44 CEST] <Atlenohen> it was typed -GS- so I guess - at the end would mean to disable, I was wondering what does it mean I guess I figured it out [14:52:28 CEST] <Numline1> BtbN yeah I was either hoping I could find the most "perfect" frame or mix multiple ones. Are there any resources on this online? [14:55:23 CEST] <BtbN> mixing multiples ones will only make matters worse [14:55:45 CEST] <BtbN> But generally, just set the fps to 1, and you will get, well, one frame per second. [14:56:14 CEST] <Numline1> BtbN Fair enough. I found this - https://www.bugcodemaster.com/article/extract-images-frame-frame-video-file… which seems to be what I need. I was just hoping there's a filter that could look for stable frames [14:59:29 CEST] <furq> Numline1: check the thumbnail filter [14:59:38 CEST] <furq> https://ffmpeg.org/ffmpeg-filters.html#thumbnail [15:00:49 CEST] <Numline1> furq that'll probably do. Thanks! Are there any details on how that filter works? [15:00:59 CEST] <Numline1> by that I mean what are the methods it uses under the hood [15:01:43 CEST] <furq> https://notbrainsurgery.livejournal.com/29773.html [15:01:46 CEST] <furq> apparently it's derived from this [15:02:18 CEST] <Numline1> thank you :) [15:02:27 CEST] <Numline1> also, what I like is that there's a filter named "ass" [15:02:37 CEST] <Numline1> I'm going to use that even though I might not need it [15:08:12 CEST] <iive> well, there is also file format .ass [15:08:37 CEST] <iive> that this filter renders [15:10:05 CEST] <Numline1> one could say it consumes ass [15:55:15 CEST] <killown> hi there [15:55:22 CEST] <killown> ffmpeg -y -ss 00:00:10.0 -i *BuUOl7HKM8U.mkv -strict -2 -c copy -t 00:00:13.0 ../videos/video.mp6 [15:55:25 CEST] <killown> mp4 [15:55:37 CEST] <killown> why ffmpeg is cuting random times? [15:56:14 CEST] <killown> I want to cut 3 seconds from starting from second 10 [15:57:13 CEST] <ritsuka> you can't cut at a random point if the video format uses P and B frames [15:57:23 CEST] <DHE> you must cut starting on a keyframe [16:08:52 CEST] <killown> how is that? [16:08:57 CEST] <killown> starting on a keyframe? [16:09:12 CEST] <killown> cannot cut from 10 seconds? [16:09:22 CEST] <furq> only if there's a keyframe at that timestamp [16:09:27 CEST] <HickHoward> okay, so i did... this [16:09:27 CEST] <HickHoward> ffmpeg.exe -i "H:\Tourist Trophy (Japan)\tt_vol\openingW.m2v" -vf "il=1:1:1,setfield=tff,separatefields" -vcodec rawvideo -pix_fmt bgr24 openingW.avi [16:09:30 CEST] <furq> otherwise it'll seek to the (closest/next) one [16:09:39 CEST] <HickHoward> now the final .avi video is looking all jittery every 2 frames [16:10:09 CEST] <HickHoward> this is especially noticeable on parts of the video in which only a static image is displayed for like 5 seconds [16:12:10 CEST] <killown> furq how do I check that? [16:12:48 CEST] <furq> well there almost certainly isn't one there [16:12:52 CEST] <furq> so you probably just want to reencode the video [16:13:26 CEST] <furq> HickHoward: what's that even supposed to do [16:13:49 CEST] <killown> furq could you help me reencode the vide to have this keyframe? [16:14:02 CEST] <furq> killown: i don't mean reencode the entire video [16:14:23 CEST] <furq> you can't cut at arbitrary points and use -c copy [16:14:31 CEST] <furq> because the output video has to start on a keyframe [16:14:31 CEST] <DHE> move your -ss to after the input file, and change -c to an actual codec. plus codec options suitable to your needs [16:14:40 CEST] <furq> if you cut and reencode then it'll work fine [16:19:42 CEST] <HickHoward> furq: not do this shit to me -> https://diff.pics/2vcOo4y6Z3ve/1 [16:31:05 CEST] <killown> ffmpeg -y -i *BuUOl7HKM8U.mkv -acodec aac -strict experimental -ss 0:00:10 -t 0:00:13 ../videos/A... [16:31:08 CEST] <killown> still not working [16:35:03 CEST] <quakenet> INVITED: Hello I invite you to a great chat service >< IRC quakenet ORG <<< #philosophy #DALnet , #NASA , #Freenode , #LOVE [16:45:52 CEST] <zalaare> https://pastebin.com/raw/Gg8wUS8x Can someone point out where the "other" filters exist that ffmpeg is complaining about here? I only thought I was using 1 video and 1 audio. [17:16:02 CEST] <Atlenohen> hey guys, VS2017 MSVC doesn't list any linker/compiler arguments for -L from --extra-ldflags=-L../build/lib [17:17:04 CEST] <Atlenohen> I see where was -IInclude like if "Include" is an environmental variable would it for both included headers and libs then? [17:47:06 CEST] <Atlenohen> pretty much the only thing left is ERROR: libx264 not found [17:54:53 CEST] <Atlenohen> Ah it may just be a bash/VC env variable problem, i'll ask on ##linux [17:56:37 CEST] <DHE> pkg-config? maybe you need to set PKG_CONFIG_PATH=/usr/local/lib/pkg-config if you used configure defaults on x264 when building from source [17:56:48 CEST] <DHE> dunno how that works on VC... [17:58:27 CEST] <Atlenohen> Well, it's a MINGW64 shell created from a VS2017 Developer Command prompt which sets environmental variables for that windows (without having to set them up in windows) [17:59:07 CEST] <Atlenohen> I had manually created added more paths and it didn't work, looks like it ignores system ones, that or I need to reboot the machine for it to confirm [17:59:48 CEST] <Atlenohen> I'll first reboot and then all I think I need to figure out is how to input new env into bash [18:00:08 CEST] <Atlenohen> oh I don't have PKG at all, i'll add if it's needed, brb [18:06:01 CEST] <Atlenohen> back [18:06:40 CEST] <Atlenohen> Looks like the windows env won't work echo %comspec% or $comspec won't wokr [18:07:11 CEST] <Atlenohen> well it does work now [18:07:28 CEST] <Atlenohen> I guess it works for non %windowspercent% variables [18:07:59 CEST] <Atlenohen> but that's base MINGW64, now I'll test the VC initialized one, [18:14:09 CEST] <Atlenohen> Oh so if I specify pkconfig then I don't need to specify include and libs [18:18:23 CEST] <Atlenohen> DHE: does this pkg_config_path need to be set under ./configure ? [18:24:06 CEST] <furq> it's an environment variable [18:31:25 CEST] <Atlenohen> Oh I need to use that to actually enter it, okay --pkgconfigdir [18:38:18 CEST] <Atlenohen> furq: still won't work: https://pastebin.com/7fWqUKC3 [18:38:42 CEST] <furq> i've never used msvc so i can't help you [18:39:28 CEST] <DHE> well x264.pc isn't a dir [18:39:46 CEST] <DHE> normally I do "export PKG_CONFIG_PATH=/usr/local/lib/pkg-config" before running configure [18:40:10 CEST] <furq> afaik you should still be able to link gcc dlls to an msvc host as long as you don't link any C++ libs to ffmpeg [18:40:16 CEST] <furq> so it'll probably be easier to do that [18:41:28 CEST] <DHE> it's not recommended, but if you specify enough options that compiling a test x264 application succeeds (eg: --extra-cflags=-I/path/to/x264 --extra-ldflags=-L/path/to/x264 substitute for what VC needs) it should work. [18:42:06 CEST] <furq> if you're only linking one library then specifying paths manually will be simpler [18:42:51 CEST] <furq> you also probably want to use relative paths [18:43:16 CEST] <furq> i never quite figured out at what point msys bash transforms msys paths to actual windows ones but i do know it's pretty fragile [18:43:34 CEST] <furq> so it's best to just use relative paths and avoid that entirely [19:05:14 CEST] <Atlenohen> furq: oh oops, DHE: I'm not sure anymore what pkg-config were talking about, I was linking to the x264 one, not the one in the msys2 install directory [19:05:58 CEST] <syadnom> I'm pulling my hair out trying to get ffmpeg to encode mpeg dash at all, with a goal of multiple streams. can anyone point me to a comprehensive guide or look at what I've got right now that isn't working? [19:11:08 CEST] <Atlenohen> DHE:okay but all the talk is about the env variable, what do you put into the --pkgconfigdir then ? [19:13:28 CEST] <Atlenohen> for relative paths that means I make a copy of the x264/built folder over to the ffmpeg repo, make sense, okay [19:13:50 CEST] <Atlenohen> indeed the whole linux paths inside windows is confusing [19:17:33 CEST] <Atlenohen> DHE: then --extra-ldflags -L is not a MSVC option then, there is no -L anywhere in the C complier options, linker [19:21:10 CEST] <Atlenohen> okay it didn't work, i'm out of ideas, I'll be back later after a big break [19:21:39 CEST] <Atlenohen> this was the final command I tried: CC=cl ./configure --toolchain=msvc --arch=x86_64 --pkgconfigdir=./x264/built/lib/pkgconfig --extra-cflags='-I./x264/built/include -O2 -MT -GS-' --extra-ldflags=-L./x264/built/lib --prefix=./BUILT/x64 [19:25:44 CEST] <Atlenohen> petty issues with licenses making this process 100x the hassle it could be [19:26:04 CEST] <Atlenohen> it could have just been boundled with ffmpeg [19:26:10 CEST] <Atlenohen> meh [19:48:21 CEST] <cptnhmr42> How can I keep audio and video timestamps / idr alligned when transmuxing and transcoding from rtmp to mpeg-dash / hls? [19:59:10 CEST] <cptnhmr42> If no one answers questions in here, should I ask my question on the mailing list? [19:59:47 CEST] <Atlenohen> Okay the thing actually worked [20:01:27 CEST] <Atlenohen> DHE: I used your suggestion to define PGK_CONFIG_PATH, and then I ommited any text from the -I and -L options, and it worked, but it is set for x86 instead of x64, I have installed both YASM and NASM in , I did not enable yasm in ffmpeg config, not sure if that has anything to do with x64 vs x86 [20:02:32 CEST] <Atlenohen> https://pastebin.com/ZTyWR59m [20:07:01 CEST] <Atlenohen> oh, yasm stuff seems deprecated [20:20:42 CEST] <Atlenohen> so wait, it is x86_64, it just gets reported as x86 [20:20:45 CEST] <Atlenohen> i[3-6]86*|i86pc|BePC|x86pc|x86_64|x86_32|amd64) [20:20:45 CEST] <Atlenohen> arch="x86" [21:10:42 CEST] <lindylex> I am trying to concat video using this script https://pastebin.com/jjpkY7w5 I am not sure why it is turning my 4 and 2 minute in length videos in 4 second videos. [21:10:58 CEST] <garyserj> What is this command for libx264? fmpeg -i input.mkv -c:v libx265 -b:v 4000k -an -x265-params no-info=1 output.hevc [21:11:35 CEST] <garyserj> I tried ffmpeg -i c_bad.mp4 -vcodec libx264 -libx264-params no-info=1 -acodec copy d.mp4 and I got "Unrecognized option 'libx264-params'." [21:12:55 CEST] <garyserj> ah, maybe x264-params [21:13:36 CEST] <garyserj> it isn't removing all encodnig settings though. how would I do that? [21:13:43 CEST] <lindylex> garysej: are you trying to use something like this? -codec:v libx264 [21:14:07 CEST] <garyserj> I think -codec:v is the same as -vcodec copy so that's ok [21:15:46 CEST] <Atlenohen> lindylex: because the scrip has trim, you don't need any trim if you want to combine full videos [21:16:13 CEST] <lindylex> Ok thanks that was new to me. Trimming videos this way. [21:16:23 CEST] <garyserj> if you look here https://pastebin.com/raw/ZJHhHGnD c_good.mp4 has no encoding settings and no writing library listed, whereas c_bad.mp4 has writing library listed, and encoding settings e.g. "cabac=1 / ref=3 / deblock=1:0:0 " I want to convert c_bad.mp4 to have no writing library and no encoding settings listed [21:16:25 CEST] <Atlenohen> concat works differnt on different OS I believe, in windows I usually got it working with a list file, a text file that has the input filenames [21:17:51 CEST] <Atlenohen> lindylex: that trim is probably used for a large batch, if you only have one or two videos to trim, you can do that manually with -ss and -to options, like -ss 00:00:10 (start at 10 seconds) and -to 00:00:30 (end at 30) [21:17:54 CEST] <lindylex> Atlnohen I use to use a text file with a list. I no longer. [21:18:12 CEST] <lindylex> That is the way I use to do it. -ss and -to [21:18:14 CEST] <Atlenohen> As you wish if it works better for you [21:18:50 CEST] <lindylex> I was just sharing. And thanks for your input. Trimming the way it is done in the script is new to me. [21:19:26 CEST] <Atlenohen> You may need to customize the script to make trimming the way you need, if necessary, I never used that so I can't tell much from the first look. [21:20:05 CEST] <garyserj> ah -to is useful, i've been using -t [21:20:41 CEST] <lindylex> -to is my favorite. Before that I used -t and I had to do to many calculations. [21:20:49 CEST] <garyserj> heh, i wrote a program to do the calculations! [21:21:04 CEST] <lindylex> What language? [21:21:07 CEST] <Atlenohen> garyserj: the bad.mp4 may be corrupt so it may not show details, if you want to ommit details you may need to HEX edit the file, that's the only way I know right now, I don't know if encoders/muxers have the option to customize or omit the info [21:21:35 CEST] <lindylex> I wrote a wrapper for special effects python calling ffmpeg [21:22:40 CEST] <garyserj> lindylex: ruby [21:23:01 CEST] <garyserj> How can I check if an mp4 is corrupt? [21:23:16 CEST] <garyserj> and how can I fix it if it is corrupt? [21:23:36 CEST] <garyserj> atlen: the bad one iis the one with the details [21:23:56 CEST] <garyserj> Both play, but the bad one won't upload to youtube and the good one will [21:24:29 CEST] <lindylex> Atlenohen : https://github.com/MotionDesignStudio/commandlinemediahelper [21:24:48 CEST] <lindylex> sorry I meant garyserj : https://github.com/MotionDesignStudio/commandlinemediahelper [21:24:56 CEST] <garyserj> thanks ,i'll check that [21:25:00 CEST] <garyserj> bbiab like 3h but will check for any replies when I get back [21:25:13 CEST] <lindylex> Send me yours please. [21:25:39 CEST] <Atlenohen> furq, DHE: I managed to do something, but it produced .a files not .lib, they're much smaller than they suppose to be IMO as I have a lot more encoders/muxers enabled than the 5 year old versions have [21:29:12 CEST] <garyserj> lindylex : I haven't used it in ages and there seems to be a little bug but anyhow https://pastebin.com/raw/B0fTcJLt you just entered the start and end time and it told you the -ss and -t [21:29:25 CEST] <lindylex> Atlenohen I am having issues removing the trim and getting this ffmpeg command to run. [21:29:46 CEST] <garyserj> lindylex: nothing special, like a 5min program! [21:30:02 CEST] <lindylex> Thanks nice work. [21:30:10 CEST] <garyserj> heh, gotta go though, bbaib 3h [21:30:32 CEST] <garyserj> slight bug on gets.chomp but the calculation s fnie [21:30:56 CEST] <garyserj> not seen that bug before but it says bug on line 18. should be quick to fix but i gtg. [23:07:13 CEST] <lindylex> I am trying to remove the trim and the audio removal from the ffmpeg command without success. I tried sever variations with no success. https://pastebin.com/Psn7cp0H [23:23:00 CEST] <Ariyasu> maybe try concat the source files [23:23:11 CEST] <Ariyasu> so your working with less inputs [23:23:23 CEST] <Ariyasu> might make it easier to work out where things are goign wrong [23:24:18 CEST] <lindylex> The source files need to have the transition between them. This is why I can not concat before applying the filter. [23:56:12 CEST] <faLUCE> Hello all. JEEB: I just got a confirmation from MPEG LA :-) [00:00:00 CEST] --- Sat Apr 13 2019

1 0

ffmpeg-devel.log.20190411
by burek 12 Apr '19

12 Apr '19

[00:14:47 CEST] <cone-246> ffmpeg 03Michael Niedermayer 07master:7f3d39b21f89: avcodec/pnm_parser: Support concatenated ASCII images [00:14:47 CEST] <cone-246> ffmpeg 03Michael Niedermayer 07master:1d43d72b181a: avcodec/pnm_parser: Factor next initialization out [00:14:47 CEST] <cone-246> ffmpeg 03Michael Niedermayer 07master:3fe37033b982: avcodec/pnm_parser: Factor out next/index compensation [08:09:12 CEST] <cone-788> ffmpeg 03Lauri Kasanen 07master:ce92ee4b4f3e: swscale/ppc: VSX-optimize non-full-chroma yuv2rgb_2 [11:59:50 CEST] <cone-788> ffmpeg 03Paul B Mahol 07master:0f2835597484: avcodec/agm: add support for higher compression [11:59:51 CEST] <cone-788> ffmpeg 03Paul B Mahol 07master:7be8f7ac8143: avcodec/agm: add support for non-dct coding [11:59:52 CEST] <cone-788> ffmpeg 03Paul B Mahol 07master:d0f24df648f4: avcodec: add ADPCM AGM decoder [13:44:05 CEST] <durandal_1707> michaelni: what type of NALs are those? : https://github.com/richardpl/FFmpeg/blob/imm5/libavcodec/h264dec.c#L956 [13:45:19 CEST] <nevcairiel> 0x67 in the 5th spot is SPS, 0x68 is PPS [13:45:32 CEST] <JEEB> if it's H.264 the spec should have a nice list [13:45:35 CEST] <JEEB> for NAL unit types [13:47:54 CEST] <nevcairiel> note that the type is only 0x1f of that byte, so its 7 and 8, ie. sps and pps [14:02:46 CEST] <durandal_1707> and what they contain? [14:03:18 CEST] <nevcairiel> information to decode the video! [14:03:18 CEST] <nevcairiel> :) [14:03:30 CEST] <durandal_1707> like? [14:04:05 CEST] <nevcairiel> read the syntax spec yourself =p [14:04:50 CEST] <nevcairiel> profile, width/height/bitdepth, all that stuff, various flags [14:26:00 CEST] <pranayvshah> Is this the right place to hire an ffmpeg dev from? [14:26:17 CEST] <JEEB> this has developers at least :P [14:26:39 CEST] <JEEB> the ffmpeg-devel mailing list is another venue since I don't think we have a specific list for offers [14:28:17 CEST] <pranayvshah> Alright, will post there too. I went through drawtext filter's .c code and libfribidi seems to be the only shaper supported. Who would be the right dev to add support for harfbuzz and are they available for contracting work? [14:31:33 CEST] <BradleyS> i believe libass uses harfbuzz if enabled, and ffmpeg can use libass if enabled [14:31:50 CEST] <BradleyS> this is how we use harfbuzz in handbrake, for example [14:32:34 CEST] <pranayvshah> But that's just the ass/subtitles filter, drawtext wouldn't use libass right? [14:33:11 CEST] <BradleyS> indeed, subtitles only but might be helpful reference [14:34:24 CEST] <BradleyS> see also http://ffmpeg.org/consulting.html [14:34:48 CEST] <BradleyS> and do email the ffmpeg-devel mailing list [14:35:11 CEST] <pranayvshah> Agreed, and will email to the dev list. Thank you :) [14:44:15 CEST] <durandal_1707> aren't there ass filter? [14:45:19 CEST] <JEEB> yup, for cases where a static ASS file can be generated it should be good enough [14:45:43 CEST] <JEEB> since it effectively just tells libass to parse an ASS file [19:47:54 CEST] <cone-562> ffmpeg 03Michael Niedermayer 07master:3308e3da045e: avcodec/agm: Check frame dimensions [20:47:47 CEST] <cone-562> ffmpeg 03James Almer 07master:80e9f50f82a7: avcodec: add an AV1 frame split bitstream filter [21:05:12 CEST] <cone-562> ffmpeg 03James Almer 07master:c5a825dc7536: configure: fix av1_frame_split bsf dependencies [21:47:41 CEST] <cone-562> ffmpeg 03Marton Balint 07master:6ed7df5b20e4: avformat/mxfdec: export operational pattern UL as file metadata [21:47:42 CEST] <cone-562> ffmpeg 03Marton Balint 07master:3e10223385b8: avformat/file: add seekable option to disallow seeking [00:00:00 CEST] --- Fri Apr 12 2019

1 0

ffmpeg.log.20190411
by burek 12 Apr '19

12 Apr '19

[00:00:24 CEST] <phisch> kepstin: that could explain it, but default behavior should be that background tasks don't receive the sigint afaik [00:00:34 CEST] <phisch> don't know why this should be different for me [00:01:34 CEST] <kepstin> but that would explain the behaviour - if ffmpeg receives *two* SIGINT, the first starts a clean exit, but the second aborts that and exits immediately [00:02:11 CEST] <phisch> yeah, but i don't know how i could check/prevent this [00:03:05 CEST] <phisch> i think this is very ffmpeg related [00:05:28 CEST] <kepstin> I explained ffmpeg's behaviour ^^ [00:06:31 CEST] <phisch> do you know if there is a way to disable this behavior then? :P [00:07:12 CEST] <phisch> or could you run the script, hit ctrl+c and tell me your output? just to make sure that this is not some messed up stuff related to my system [00:07:14 CEST] <kepstin> I'm really not familiar enough with how the process group stuff in the shell works to give a suggestion :/ [00:07:26 CEST] <kepstin> this is the expected behaviour with your script, i think. [00:11:06 CEST] <phisch> no, i expect that when my script receives a sigint (either by `kill -INT [PID]` or `ctrl+c`) the sigint trap handles gracefully killing background processes [00:23:20 CEST] <kepstin> hmm. i really dislike working with signal handling. I can't even get that working when just running 'sleep' instead of ffmpeg :/ [00:25:53 CEST] <kepstin> phisch: you might have better results if you remove the 'wait $FFMPEG_PID' from the signal handler [00:26:48 CEST] <phisch> i need to wait until it's completely done though [00:27:05 CEST] <kepstin> don't wait in the signal handler :/ [00:27:46 CEST] <phisch> i have to, since i want to run the script via a shortcut and kill it with another one [00:28:22 CEST] <kepstin> not sure what you mean. you shouldn't need to wait in the signal handler, you're already waiting at the end of the script [00:32:21 CEST] <phisch> you hit a shortcut, select a screen area with slop, it records that screen area with ffmpeg, once the process is killed via another shortcut the trap sends a sigint to ffmpeg and then waits until the process has fully exited, then takes the video and makes a gif out of it [00:33:16 CEST] <kepstin> ah, the issue is that the signal handler interrupts the wait at the bottom of the script and it doesn't get resumed :/ [00:33:40 CEST] <phisch> yes, thats why i need the wait in the signal handler [00:34:28 CEST] <phisch> and everything works for my use-case, but i'd really like to also be able to use this from a terminal directly and having it work with hitting ctrl+c [00:34:42 CEST] <phisch> but as we have seen the ctrl+c somehow sends 2 sigints to ffmpeg [00:34:55 CEST] <phisch> because ffmpeg does some magic or whatever [00:39:01 CEST] <kepstin> just to confirm, you want to run some other commands in the same script after ffmpeg exits? [00:41:48 CEST] <kepstin> probably the easiest solution is to run the ffmpeg command under nohup (like `nohup ffmpeg <args> &`), that'll make all the signals work the way you expect. Note that nohup by default sends the command output to a file named nohup.out. [00:42:27 CEST] <kepstin> (bit of a big hammer for this, since you probably would want ffmpeg to be killed if you close the terminal, but it'll work) [00:44:46 CEST] <phisch> yeah, detaching with nohup seems like something worth trying [00:45:21 CEST] <phisch> and yes, i want to run more commands, my example is just a stripped down version to illustrate the problem without unnecessary stuff [00:47:01 CEST] Action: kepstin has confirmed that it works - if you still want the command output in the terminal, `nohup ffmpeg ... | cat &` is a hilarious way of doing it. [00:47:35 CEST] <kepstin> i assume there must be a way to do this without nohup, but..? :/ [00:48:02 CEST] <phisch> yeah, without would be perfect [01:49:30 CEST] <kevinnn> does anyone know if vlc streams rtsp using UDP by default? [01:49:43 CEST] <kevinnn> and if it does how can I set it to use TCP? [03:10:12 CEST] <memelover> I'm attempting to transcode some FLACs to ALAC. The specific command I'm using is "ffmpeg -i song.flac -acodec alac -map 0:0 song.m4a. This seems to preserve most of the tags, but not all. For example, the "total tracks" tag does not appear in the m4a.Is there some gotcha that I'm missing? [03:11:52 CEST] <memelover> It also appears to gut the replaygain data. [03:17:21 CEST] <klaxa> there is a -map_metadata flag, maybe look into that? [03:18:10 CEST] <klaxa> https://ffmpeg.org/ffmpeg.html#Advanced-options [03:21:40 CEST] <memelover> Hmm. It says that if not included, it defaults to including all metadata. [03:24:53 CEST] <klaxa> -map 0:0 excludes everything but track 0 from file 0 though [03:25:05 CEST] <klaxa> not sure if that also excludes metadata, but maybe? [03:25:15 CEST] <klaxa> but if you tried and it didn't help, guess not [03:33:18 CEST] <memelover> Well, my reason for doing that is that track 1 sometimes contains an mjpeg album cover, which ffmpeg really doesn't like. It cannot seem to process it at all, so my plan is to add it back in after transcoding. [03:34:27 CEST] <memelover> And it looks like the replaygain data isn't actually metadata, but information inside the audio track. Even -fflags keepside doesn't seem to help with that. [03:41:03 CEST] <phisch> kepstin: wait, how did you get nohup to work? [06:25:59 CEST] <damdai> anybody know what it means by "fragmented" and "cbcs" ? http://download.opencontent.netflix.com/?prefix=AV1/Chimera/ [07:29:16 CEST] <damdai> what is wrong with ffmpeg devs? [07:29:29 CEST] <damdai> they closed my bug report for no reaosn [07:32:13 CEST] <damdai> dongs you there? [08:39:15 CEST] <pkunk> Does "-use_wallclock_as_timestamps 1" work with mpegts streams? [08:40:44 CEST] <pkunk> I sometimes get "non-monotonous" packet errors on output. So tried this option, but with this I instead get "DTS discontinuity in stream 1" errors as the mpegts packets sometimes come in out of order over http [08:42:03 CEST] <pkunk> Or is there any other way to "fix" the timestamps on mpegts streams so I can avoid the dreaded "non-monotonic" errors on av_interleaved_write_frame() [10:04:33 CEST] <JEEB> pkunk: if it's wrap-around that's standard in MPEG-TS in theory libavformat has wrap-around handling but that only seems to work once. ffmpeg.c then attempts to do it again in a separate piece of logic. [10:05:15 CEST] <JEEB> for that specific option what it does is it overrides the timestamp in libavformat's utils [10:05:28 CEST] <JEEB> in other words if you have b-frames etc it will just bork [10:05:31 CEST] <JEEB> pkt->dts = pkt->pts = av_rescale_q(av_gettime(), AV_TIME_BASE_Q, st->time_base); [10:06:18 CEST] <JEEB> so yes the option will "work" for MPEG-TS input, but I think of this as something that an API client would handle rather than the framework (I like the way upipe has three timestamps) [10:06:43 CEST] <JEEB> (in upipe each packet has three timestamps: original coded, coded+wrap-arounds etc handled, receipt time) [10:07:41 CEST] <JEEB> that way the API client can still know the original timestamps but attempt to normalize the stream in case the input timestamps are actually broken [11:50:12 CEST] <pkunk> JEEB: Thanks JEEB . I'm using the console ffmpeg right now, modified to do parallel open of all input streams [11:51:57 CEST] <pkunk> Excuse the additional nickname, Will have a look at what "upipe" is . First time I've heard of it [11:57:44 CEST] <cartman412> Hi there! I've been making a gif maker using ffmpeg and I noticed that for some reason, when I try to add padding the final output quality seems to lower drastically. Here are the commands I use (no padding/padding): https://pastebin.com/3rrAJ0df / https://pastebin.com/uYg8PZuq and a screenshot of the resulting gifs (no padding/padding): https://pasteboard.co/I9CCPmr.png / https://pasteboard.co/I9CD8xK.png [11:58:20 CEST] <cartman412> Also note how the padding color seems to leak into the actual video on the left side [11:58:28 CEST] <cartman412> Any ideas of what I might be doing wrong? [11:58:49 CEST] <JEEB> pkunk: it's a more broadcast-oriented multimedia framework that has modules for decoding through FFmpeg etc [11:58:55 CEST] <JEEB> it has some nice ideas [11:59:11 CEST] <furq> cartman412: you probably want to pad before calling paletteuse [11:59:56 CEST] <cartman412> that was what I was thinking, thanks for confirming it :) I'll try this now! [12:08:08 CEST] <cartman412> furq your suggestion fixed the quality and pad color leaking into the actual image, but now the padding color seems to be affected instead [12:08:41 CEST] <furq> yeah it sounds like the problem is that the pad color isn't in the generated palette [12:08:41 CEST] <cartman412> https://pasteboard.co/I9CJAB7.png [12:08:59 CEST] <cartman412> so I should add padding when generating the palette as well? [12:09:05 CEST] <furq> that should work [12:09:22 CEST] <cartman412> awesome, thanks for the quick answers :) [12:16:48 CEST] <cartman412> furq: it worked! https://pasteboard.co/I9CMJz4.png thank you so much! :) [13:19:01 CEST] <Atlenohen> Any idea what this does in ffmpeg's config? --extra-cflags='-MT -IWindowsInclude -GS-' [13:19:18 CEST] <Atlenohen> Build config [13:22:24 CEST] <furq> they're just extra arguments to your c preprocessor/compiler [13:22:26 CEST] <pink_mist> sets flags for the C compiler [13:22:31 CEST] <pink_mist> yeah, or preprocessor [13:22:58 CEST] <pink_mist> what exactly they do to your C preprocessor or compiler, you'd haveto read its documentation or ask on its support forums [13:24:40 CEST] <furq> if this is msvc then -MT uses the static runtime library and -GS disables buffer security checking [13:24:57 CEST] <furq> i assume -I is the same as gcc (sets a header include directory) [13:39:20 CEST] <King_DuckZ> hi, anyone knows what the -profile:v 3 option would be set in code? I'm using the library directly [15:05:22 CEST] <th3_v0ice> Why would avformat_find_stream_info() fail for a same file that FFmpeg reads properly? Both are from the same version 4.0. [15:34:56 CEST] <pranayvshah> How can I get ass->shaping to hold a value of 1 that is "shaping complex" in here https://github.com/FFmpeg/FFmpeg/blob/release/4.1/libavfilter/vf_subtitles.… [15:35:57 CEST] <JEEB> pranayvshah: set the shaping option to the value "complex" [15:36:27 CEST] <pranayvshah> That option works for the ass filter. I need it to work for the subtitles filter [15:36:28 CEST] <JEEB> oh, that is specific to the ass filter [15:36:30 CEST] <JEEB> right [15:36:43 CEST] <JEEB> just noticed the name of the struct that defines the option :) [15:37:00 CEST] <pranayvshah> Yeah :P [15:37:24 CEST] <JEEB> wonder why it was added as ass-only [15:37:59 CEST] <pranayvshah> I nevertheless tried the same option on the subtitles filter, did not work :D [15:39:28 CEST] <JEEB> ok, sounds like you could try moving the option from ass_options to COMMON_OPTIONS [15:40:04 CEST] <JEEB> if it really works as an option for the other filter that you're utilizing [15:40:05 CEST] <JEEB> :) [15:40:58 CEST] <JEEB> which would effectively make ass_options into COMMON_OPTIONS and then nullptr [15:41:09 CEST] <pranayvshah> As a workaround, I simply set removed the ass->shaping argument and replaced it with 1. That's a lot simpler for me since I know libass is compiled with harfbuzz [15:41:36 CEST] <JEEB> if the option works then we might want to move it into the common options [15:41:48 CEST] <JEEB> if you think that's a useful change and it isn't specific to the ass filter [15:42:42 CEST] <pranayvshah> This does work for me - ass_set_shaper(ass->renderer, 1); [15:43:06 CEST] <JEEB> ok, might post a patch on the mailing list moving the option into the common one [15:43:09 CEST] <JEEB> *common list [15:43:16 CEST] <pranayvshah> I was hoping to not have to use my own compiled version [15:53:57 CEST] <bencoh> 41 [16:08:09 CEST] <Atlenohen> Does this still hold true? http://www.ffmpeg-archive.org/ffvhuff-codec-improvement-td4661530.html FFV1 doesn't operate on per-frame level? And the force intra-frame only is not a 100% workaround? [16:11:29 CEST] <furq> what does "operate on per-frame level" mean [16:12:27 CEST] <DHE> and this is talking mostly about pixel formats [16:12:47 CEST] <DHE> oh, this bit about precise and fast seeking I assume... [16:35:33 CEST] <Atlenohen> Yeah, [16:36:18 CEST] <furq> what makes you think setting the gop size isn't a workaround [16:36:39 CEST] <Atlenohen> I was about to mention that, if the GOP size has anything to do wiht it [16:37:09 CEST] <Atlenohen> I guess good then [16:37:29 CEST] <furq> i mean i don't know that it is [16:37:33 CEST] <furq> i just didn't see that in the thread [16:37:51 CEST] <furq> it ought to work fine with a gop size of 1 [17:03:36 CEST] <HickHoward> uhhhhhhh [20:50:11 CEST] <HickHoward> uhh [20:50:57 CEST] <HickHoward> how can i encode a mpeg2 video file with a custom intra quantizer matrix? [20:52:57 CEST] <HickHoward> wait a second [20:53:00 CEST] <HickHoward> nevermind [21:17:05 CEST] <HickHoward> anyways i'm having a bit of a problem with this filter [21:17:06 CEST] <HickHoward> file:///H:/ffmpeg/doc/ffmpeg-filters.html#toc-il [21:17:32 CEST] <HickHoward> so, with ffmpeg's current version i'm supposed to just use "-vf 'il'" or something? [21:18:46 CEST] <HickHoward> i say this because i tried other options 'il' has in offer like chroma_mode and interleave but none of them work [21:18:48 CEST] <HickHoward> like this [21:18:57 CEST] <HickHoward> "-vf "il=chroma_mode=interleave"" [21:21:12 CEST] <durandal_1707> pastebin full command and ffmpeg output [21:21:24 CEST] <HickHoward> wait [21:21:33 CEST] <HickHoward> ffmpeg.exe -i "H:\Tourist Trophy (Japan)\tt_vol\openingW.m2v" -vf 'il=chroma_mode:interleave' openingW.avi [21:21:35 CEST] <HickHoward> no [21:21:38 CEST] <HickHoward> sorry [21:21:47 CEST] <HickHoward> you meant pastebin [21:22:06 CEST] <HickHoward> https://pastebin.com/TaQKq8VD [21:23:09 CEST] <durandal_1707> HickHoward: il=chroma_mode=interleave [21:23:45 CEST] <HickHoward> pastebin edited [21:23:48 CEST] <HickHoward> doesn't work for me either [21:24:29 CEST] <durandal_1707> HickHoward: you forgot to paste and ffmpeg output of command [21:25:02 CEST] <HickHoward> just the ffmpeg output of command [21:25:11 CEST] <HickHoward> okay [21:26:02 CEST] <HickHoward> pastebin updated [21:29:25 CEST] <durandal_1707> HickHoward: ffmpeg.exe -i "H:\Tourist Trophy (Japan)\tt_vol\openingW.m2v" -vf "il=chroma_mode:interleave" openingW.avi [21:30:28 CEST] <HickHoward> done [21:30:31 CEST] <HickHoward> pastebin updated [21:36:50 CEST] <durandal_1707> HickHoward: Sorry, use: ffmpeg.exe -i "H:\Tourist Trophy (Japan)\tt_vol\openingW.m2v" -vf "il=chroma_mode=interleave" openingW.avi [21:37:55 CEST] <HickHoward> okay, *now* it works [21:39:53 CEST] <HickHoward> well, i feel like i haven't communicated my idea with this yet [21:40:00 CEST] <HickHoward> so, the source file looks like this [21:40:01 CEST] <HickHoward> https://i.boring.host/WS8WD5U.png [21:40:21 CEST] <HickHoward> what you're seeing here is *two* frames being combined into one [21:40:33 CEST] <HickHoward> and the frame rate is halved [21:40:36 CEST] <HickHoward> because of this [21:41:08 CEST] <HickHoward> (as in, the original frame rate of this source file is 29.98 fps) [21:41:16 CEST] <HickHoward> *29.97 fps [21:42:31 CEST] <durandal_1707> use weave/doubleweave [21:42:38 CEST] <HickHoward> okay [21:44:40 CEST] <HickHoward> tested it, all that ever did was double the horizontal screen size of the output file [21:44:55 CEST] <HickHoward> *all that ever did => all that weave/doubleweave [21:49:10 CEST] <durandal_1707> HickHoward: il=1:1:1 [21:49:25 CEST] <HickHoward> hold on [21:49:27 CEST] <durandal_1707> HickHoward: il=1:1:1,separatefields [21:49:42 CEST] <HickHoward> okay, testing now [21:54:26 CEST] <HickHoward> tested, now the frame organization is wrong as all hell(first frame is bottom, second frame is top, and so on until the end of video) so i had to put setfield=tff before separatefields [21:57:45 CEST] <durandal_1707> HickHoward: so it works? if not upload first 20 frames somewhere [21:57:54 CEST] <HickHoward> yes [22:16:15 CEST] <HickHoward> okay, now i've done this [22:16:17 CEST] <HickHoward> ffmpeg.exe -i "H:\Tourist Trophy (Japan)\tt_vol\openingW.m2v" -vf "il=1:1:1,setfield=tff,separatefields" -vcodec rawvideo -pix_fmt bgr24 openingW.avi [22:16:36 CEST] <HickHoward> and now i want the output video to remain its input resolution(640x448) [22:19:06 CEST] <cptnhmr42> Does anyone know if there are any patches out there for dealing with AV sync issues when converting RTMP to HLS / MPEG-DASH? [23:08:34 CEST] <faLUCE> Hello. If a GPL non-commercial library uses ffmpeg/x264, does it have to contact/pay something to MPEG LA ? [23:09:46 CEST] <faLUCE> it seems that MPEG LA's license doesn't talk about FOSS projects, and requires a fee only for big commercial ones [23:11:42 CEST] <JEEB> software licensing is unrelated to patent licensing due to distributing binaries [23:12:30 CEST] <faLUCE> JEEB: and what does this cause? [23:13:24 CEST] <JEEB> that whether something is open source or not doesn't matter. you look if <patent licensing for thing X> is applicable to you (maybe consult a lawyer if you care enough) regardless [23:14:25 CEST] <JEEB> I don't know your laws and whether such licensing is applicable in your country to begin with [23:14:51 CEST] <faLUCE> JEEB: for example, in France? [23:15:07 CEST] <JEEB> VideoLAN seems to be on the stance of middle fingering [23:15:15 CEST] <JEEB> given that they are not paying for VLC distribution [23:16:02 CEST] <faLUCE> JEEB: but what if a library doesn't provide binaries? [23:16:13 CEST] <JEEB> then at least with MPEG-LA you have no problems [23:16:17 CEST] <JEEB> they license binary distribution [23:16:32 CEST] <JEEB> at least according to a quote from donald graft on doom9 ages ago [23:16:51 CEST] <JEEB> if you start caring about patent licensing of course, then there's way more than just MPEG-LA :P [23:17:46 CEST] <JEEB> it's a messy thing if you really want to start looking into it [23:18:03 CEST] <faLUCE> JEEB: yes, I tried to understand but it's too messy [23:18:19 CEST] <faLUCE> after reading several posts I did not get any conclusion [23:18:22 CEST] <JEEB> well, the MPEG-LA rules in general are pretty simple [23:18:25 CEST] <JEEB> for H.264 at least [23:18:55 CEST] <faLUCE> which are them? [23:19:00 CEST] <JEEB> https://www.mpegla.com/wp-content/uploads/avcweb.pdf [23:19:08 CEST] <JEEB> this is the brief overview [23:19:43 CEST] <JEEB> for example for encoders you pay nothing if you distribute 0-100k binaries :P [23:20:04 CEST] <faLUCE> JEEB: where is the word "binary" in that doc? [23:20:29 CEST] <JEEB> "Products sold to end users" is basically binary distribution to end user [23:20:46 CEST] <faLUCE> JEEB: in this case thekeyword is "sold", not "binary" [23:21:05 CEST] <JEEB> yes, but you can sell it for $0. it's made for businesses that generally don't set the price at $0 :P [23:21:11 CEST] <JEEB> of course [23:21:17 CEST] <JEEB> nothign stops you from *asking* MPEG-LA [23:22:17 CEST] <faLUCE> JEEB: but why a library is not a "product" ? [23:22:25 CEST] <JEEB> ? [23:22:36 CEST] <JEEB> I don't think whether it's a library or not matters [23:23:18 CEST] <faLUCE> so, it's not clear if open source code is not a "product sold to end user" [23:23:25 CEST] <faLUCE> (encoder) [23:23:31 CEST] <JEEB> I will have to find the quote [23:23:39 CEST] <JEEB> but MPEG-LA has said that they don't care about *source* [23:23:40 CEST] <durandal_1707> faLUCE: you need to pay for any non-foss codec usage as user to my address [23:24:26 CEST] <faLUCE> durandal_1707: yes, in fact I understood that MPEG LA wants to be payed for non FOSS [23:24:37 CEST] <faLUCE> durandal_1707: but where is it specified in their license? [23:24:47 CEST] <faLUCE> it doesn't talk about foss or non foss [23:25:16 CEST] <JEEB> https://forum.doom9.org/showthread.php?t=156599 [23:25:34 CEST] <JEEB> yea, MPEG-LA does not care if the distributed software (binaries) is OSS or not [23:26:32 CEST] <durandal_1707> OSS is irrelevant to them, they count only implementations [23:27:06 CEST] <JEEB> well, as I noted (this is not legal advice) they don't really care about open source (by non-corps) [23:27:13 CEST] <JEEB> or well, it would be stupid to go after them [23:27:43 CEST] <faLUCE> [23:27] <JEEB> well, as I noted (this is not legal advice) they don't really care about open source (by non-corps) <--- this is true, but tehy could, if they want [23:28:08 CEST] <JEEB> yes [23:28:16 CEST] <JEEB> if they would want to enforce it they 100% could attempt to [23:28:25 CEST] <JEEB> whether such patent licensing is valid in your country is the key [23:28:29 CEST] <JEEB> > Ryan has just clarified that indeed source code is not a "product" in the required sense. He clarified that anybody creating a product using FFMPEG source code is a supplier, so anyone compiling and supplying the binary library would be subject to licensing. [23:28:42 CEST] <JEEB> this is the quoting from MPEG-LA [23:29:40 CEST] <faLUCE> JEEB: so, if a library wraps ffmpeg, there are not binaries or "products" [23:29:56 CEST] <JEEB> faLUCE: until someone produces a binary and distributes it to users, yup [23:30:05 CEST] <JEEB> source code only is something that MPEG-LA does not care about [23:30:41 CEST] <JEEB> or at least this was the case in 2010 [23:31:01 CEST] <faLUCE> JEEB: in case MPEG LA cares about source code, it would stop/break projects like vlc,ffmpeg, mplayer and tons of other stuff downloaded by million of users [23:31:20 CEST] <faLUCE> this would be absurd [23:31:25 CEST] <durandal_1707> really? [23:32:13 CEST] <faLUCE> durandal_1707: so this is the reason for which they don't do anything [23:32:30 CEST] <faLUCE> ? [23:34:01 CEST] <durandal_1707> sometimes they ask authors to remove source code implementing certain codecs [23:34:22 CEST] <faLUCE> durandal_1707: which codecs for example? [23:34:59 CEST] <durandal_1707> any random one =p [23:36:06 CEST] <faLUCE> durandal_1707: but they asked that to ffmpeg too? [23:36:42 CEST] <durandal_1707> yea [23:37:03 CEST] <faLUCE> and did ffmpeg remove the code? [23:37:45 CEST] <durandal_1707> nope [23:38:06 CEST] <faLUCE> durandal_1707: and they (MPEG LA) did not do anything else? [23:38:43 CEST] <durandal_1707> uhg, i dunno about MPEG LA, I was talking about other companies [23:39:29 CEST] <faLUCE> durandal_1707: so there's a fight between companies and ffmpeg [23:40:33 CEST] <durandal_1707> more like fight with authors of certain REd code [23:41:06 CEST] <HickHoward> gotta protect my codecs! [23:41:23 CEST] <faLUCE> durandal_1707: but do they have really power to begin a legal action against ffmpeg ? [23:42:01 CEST] <durandal_1707> dunno, anything can change [23:43:31 CEST] <faLUCE> then it's a very obscure situation :-( [23:44:36 CEST] <faLUCE> JEEB: from what "ryan" of the linked discussion say, that companies could not do anything [23:46:32 CEST] <faLUCE> let's ask to x264 channel too... [23:47:08 CEST] <durandal_1707> x264 is encoder, while i mainly talked about decoders [23:47:36 CEST] <faLUCE> durandal_1707: what's the difference, in terms of legal stuff? [23:48:50 CEST] <durandal_1707> dunno, for important legal stuff ask lawyers [23:49:50 CEST] <durandal_1707> short story: if you make money on ffmpeg, they will come after you... [23:50:01 CEST] <faLUCE> durandal_1707: this is not my case [23:50:11 CEST] <faLUCE> and I understood that [23:51:11 CEST] <faLUCE> durandal_1707: but I wondered if is there anything in their licens/docs that assures that if you DON'T provide binaries and DON'T make money , you won't have probles [23:51:16 CEST] <faLUCE> problems [23:51:32 CEST] <JEEB> of course not, why would they write that :D [23:52:05 CEST] <JEEB> but at least the binary distribution is a requirement for *MPEG-LA* [23:52:12 CEST] <faLUCE> JEEB: for completeness [23:52:16 CEST] <JEEB> so it doesn't matter for MPEG-LA if you're OSS or not [23:52:27 CEST] <JEEB> if you don't distribute binaries you're not distributing to end users [23:52:34 CEST] <JEEB> that's an early exit :P [23:52:46 CEST] <JEEB> (not legal advice but that's how a lot of people read it) [23:53:05 CEST] <faLUCE> JEEB: it seems more a "common thought" that the reality [23:53:35 CEST] <JEEB> faLUCE: for you, not for MPEG-LA or any other licensor. for the licensor it is much better if there are cases where someone is unsure, and thus they are more likely to license [23:53:46 CEST] <JEEB> for possible licensees it is of course worse [23:53:47 CEST] <JEEB> :P [23:54:09 CEST] <JEEB> thus it becomes a legal thing and the only ones that can advise you on that are lawyers [23:55:21 CEST] <JEEB> or if you want MPEG-LA's opinion, ask them [23:55:32 CEST] <faLUCE> but in the case they want to require license from one of these GPL non-commercial products, they would have to do that for all of them [23:56:04 CEST] <JEEB> dunno, I don't know if there are such requirements in laws [23:56:14 CEST] <JEEB> I Am Not A Lawyer (IANAL) [23:56:43 CEST] <faLUCE> JEEB: anyway, "Ryan has just clarified that indeed source code is not a "product" in the required sense. He clarified that anybody creating a product using FFMPEG source code is a supplier, so anyone compiling and supplying the binary library would be subject to licensing." <-- it doesn't quote ryan's words [23:56:50 CEST] <JEEB> true [23:57:00 CEST] <JEEB> he did leave ryan's contact though [23:57:09 CEST] <JEEB> feel free to request a new quotable thing [23:57:23 CEST] <JEEB> if you want MPEG-LA's opinion on things [00:00:00 CEST] --- Fri Apr 12 2019

1 0

ffmpeg-devel.log.20190410
by burek 11 Apr '19

11 Apr '19

[01:05:29 CEST] <jamrial> jkqxz: i disagree, sps parsing can and should be added to libavformat [01:05:39 CEST] <jamrial> we did it for hevc, and av1 [01:05:58 CEST] <jamrial> making that function avpriv can be a pita in the long run [01:06:21 CEST] <nevcairiel> also his current code is super wrong, semantically [01:06:39 CEST] <nevcairiel> he passes some random pointer as AVCodecContext [01:06:57 CEST] <nevcairiel> if the code ever tries to access it, nevermind a ssuming it may have a H264Context in its priv_data, there is no c oming back from that [01:07:00 CEST] <jamrial> it's for logging purposes. the AVClass is always first [01:07:07 CEST] <jamrial> but yes, it's ugly [01:07:08 CEST] <nevcairiel> but the API does not document it like that [01:07:10 CEST] <nevcairiel> hence, wrong [01:07:23 CEST] <nevcairiel> its an AVCodecContext argument, it needs to get one, a real one [01:08:23 CEST] <jkqxz> So limited copy of H.264 header parsing? I guess it doesn't actually need that much of it. [01:08:49 CEST] <jamrial> yeah, only until the beginning of vui_parameters [01:09:23 CEST] <cone-114> ffmpeg 03Lynne 07master:4d2f62150dba: aarch64/opusdsp: implement NEON accelerated postfilter and deemphasis [01:11:46 CEST] <jkqxz> I wonder whether it could include cbs_h264_syntax_template.c. [01:12:00 CEST] <jkqxz> Hmm, probably a bit too horrible. [01:12:36 CEST] <jkqxz> A file include might be better than a complete reimplementation, still. [01:25:08 CEST] <jamrial> jkqxz: i suggested to basically copy what you did in cbs_h264, since it's the simplest, most straightforward sps parsing function in the codebase [01:25:53 CEST] <jamrial> compared to h264_ps, which does a lot more than just read bits, it should be trivial to copy into libavformat [01:32:34 CEST] <jkqxz> The fatal case would be when the next version of this format decides it needs to know the value of some field that is currently discarded (something HRD, say). Then you're entirely screwed with this avpriv approach. [01:39:15 CEST] <jkqxz> Also the code does already write to some random memory through that forged AVCodecContext pointer: <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/h264_ps.c;h=17bfa…>. [01:57:26 CEST] <tmm1> is it possible to define and register an AVInputFormat at runtime? [01:58:44 CEST] <jamrial> no [02:00:26 CEST] <tmm1> thanks [02:26:20 CEST] <jamrial> i could use other people's opinion on that thread [10:37:27 CEST] <cone-522> ffmpeg 03joepadmiraal 07master:951561b64ee6: libavformat/dashenc : Prevent writing manifest files multiple times [12:42:14 CEST] <cone-522> ffmpeg 03Don C. Bigler 07master:2be7c388db67: avdevice/opengl_enc: fix build error using msvc compiler [14:36:46 CEST] <thardin> oof, that mxf avg_frame_rate ticket [14:37:47 CEST] <thardin> I went over S336m and it turns out ULs are not allowed to contain bytes 0x80-0xFF [14:38:28 CEST] <thardin> so the probe function can be improved somewhat [14:52:59 CEST] <thardin> ah no, that's only for the first 8 bytes of the UL [16:06:49 CEST] <thardin> getting a bit annoyed at all these hacks that don't have corresponding files in FATE [16:13:41 CEST] <kurosu> thardin: I think michaelni and cehoyos also run ffmpeg against ticket files. Dunno how and how much though, but that's why they sometimes come back with issues [16:20:01 CEST] <thardin> i see [16:22:07 CEST] <thardin> still, should be in fate [16:36:23 CEST] <rcabrera> Pasting this here as I wrote it on the wrong channel. [16:36:42 CEST] <rcabrera> I am parsing this args with avfilter_graph and creating a filter graph, however even I get the frames from the buffersink the filter doesn't seem to be applied. [16:36:42 CEST] <rcabrera> https://pastebin.com/LATvky15 [16:36:42 CEST] <rcabrera> Any idea of why this could be happening? [16:36:42 CEST] <rcabrera> The image should be flipped but instead I see the frame as if no filters were applied [16:42:55 CEST] <kurosu> thardin: I did that for some of the tickets that I fixed [16:43:27 CEST] <kurosu> and some people/parties expressed interest in adding as many of these files as possible [16:43:43 CEST] <kurosu> though size of the fate suite was mentioned [16:47:01 CEST] <kurosu> and fate-suite grew by 20MB since I last sync'ed it \o/ [16:54:56 CEST] <durandal_1707> sent 319 bytes received 572,663 bytes 163,709.14 bytes/sec [16:54:58 CEST] <durandal_1707> total size is 1,158,179,157 speedup is 2,021.32 [17:02:10 CEST] <thardin> kurosu: the problem is that it's hard to write patches to certain things (like probing) if such samples can't be tested by all [17:25:37 CEST] <durandal_1707> trac is 503 [17:30:48 CEST] <BtbN> %256 and &255 is equivalent, right? Or am I confusing myself? [17:31:34 CEST] <JEEB> & 0xFF basically selects the least significant byte's value [17:31:53 CEST] <JEEB> the hex-version at least makes it easier to see for me than just a 255 [17:31:54 CEST] <durandal_1707> negative is differents i think [17:32:08 CEST] <BtbN> Only caring about unsigned ints [17:33:12 CEST] <JEEB> so basically you will be getting the value between 0x00-0xFF from the least-significant byte. so I would *guess* for unsigned ints they're equivalent with % 256 [17:37:00 CEST] <BtbN> Yeah, I'm just gonna roll with the assumption. Compiler will optimize it anyway I guess [17:39:51 CEST] <durandal_1707> do not use % [17:47:47 CEST] <ubitux> BtbN: not if it's signed [17:48:50 CEST] <ubitux> using % on x86 generates 5 more instructions here (gcc -O2) on signed int [17:49:07 CEST] <BtbN> Yes, on signed ints it's clearly different [17:49:34 CEST] <nevcairiel> & on signed probably also doesnt make much sense [17:49:56 CEST] <nevcairiel> except for cases where one tries to be very smart = p [17:50:01 CEST] <BtbN> it ignores the signedness pretty much [17:50:34 CEST] <ubitux> there are many places where we use signed instead of unsigned but rely on it to be positive [17:50:56 CEST] <ubitux> it sometimes happen that you want to detect -1 only and not the whole negative space [17:51:37 CEST] <nevcairiel> sure, but in reality you are not really dealing with a signed number [17:51:49 CEST] <nevcairiel> i mostly meant & on negative n umbers is weird [19:01:58 CEST] <durandal_1707> anybody here can read japanese? i need some bitmap translated [19:02:10 CEST] <JEEB> sure [19:03:45 CEST] <durandal_1707> https://0x0.st/zZk0.png [19:04:23 CEST] <JEEB> this selection cannot be done with the free version [19:06:06 CEST] <durandal_1707> aha, thanks, the other version of similar software is limited differently but somehow buggy [19:06:21 CEST] <JEEB> np [00:00:00 CEST] --- Thu Apr 11 2019

1 0

ffmpeg.log.20190410
by burek 11 Apr '19

11 Apr '19

[01:03:03 CEST] <Atlenohen> hi trying to compile ffmpeg on linux mint (latest) any tips that aren't on the compilation guide [01:04:21 CEST] <Atlenohen> I'm usually on windows but I can do live linux boot and I was wondering if it's going to be less than a few hours so I don't need to leave, I don't have a good place or conditions to intall linux for some time due to HDD/Data maintenance/archiving taking place [03:39:38 CEST] <HickHoward> uhh [03:44:19 CEST] <HickHoward> so [03:45:07 CEST] <HickHoward> i have a mpeg2 video file whose frame consists of both the top and bottom feeds for whatever reason [03:45:08 CEST] <HickHoward> https://i.imgur.com/fOKgS3s.png [03:45:09 CEST] <HickHoward> like this [03:45:43 CEST] <HickHoward> *feeds => fields of a frame [03:45:53 CEST] <HickHoward> okay to elaborate [03:46:21 CEST] <HickHoward> in this image you are seeing two frames being merged together into both the top and the bottom fields each [03:46:44 CEST] <HickHoward> and i want to handle both fields of a frame so the final video can have this "interlaced" look [03:47:02 CEST] <HickHoward> but the thing is how can i actually do that *without* having to convert one format into another? [03:56:21 CEST] <iive> HickHoward, check `man ffmpeg-filters` 'il Deinterleave or interleave fields." [03:58:12 CEST] <iive> he didn't see it. [04:43:39 CEST] <CarlFK> this works: ffplay tcp://localhost:11000 - anyone know how to make melt use ffmpeg do play that? [04:43:51 CEST] <CarlFK> docs lead me here: https://www.mltframework.org/plugins/ProducerAvformat/#rtsp_transport [04:47:24 CEST] <CarlFK> I'm guessing something like melt -producer avformat:rtsp_transport tcp=tcp://localhost:11000 [04:51:51 CEST] <Atlenohen> hello [04:52:27 CEST] <Atlenohen> Is it better compiling on windows if the target platform is windows ? I need to compile some libs, not actualy final compiled exe [04:53:02 CEST] <Atlenohen> the libs then get put in another project and compilation later [04:58:30 CEST] <CarlFK> Atlenohen: it shouldn't matter. the complier you run needs to run on the OS it was build for. [04:59:17 CEST] <CarlFK> as long as you get all the input files where it wants them, it should produce a legit output [04:59:42 CEST] <CarlFK> getting all the files - that may be cumbersome [05:05:12 CEST] <Atlenohen> CarlFK: first time attempting this http://mingw-w64.org/doku.php/download [05:05:29 CEST] <Atlenohen> the multiple platforms is already confusing [05:05:51 CEST] <Atlenohen> MinGW for windows .... then why are all other platforms doing on the main DL page [05:06:25 CEST] <furq> because it builds binaries for windows [05:06:38 CEST] <furq> it'll run more or less anywhere gcc does [05:09:05 CEST] <Atlenohen> oh [05:09:32 CEST] <Atlenohen> I thought it's about "where the environment can be setup" as opposed to what the target compilation result is [05:09:39 CEST] <Atlenohen> so it's the other way around? [05:09:52 CEST] <Atlenohen> unless is labeled "cross compiler"? [05:22:41 CEST] <Atlenohen> meh i'll just poke something and see if it works [05:26:48 CEST] <Atlenohen> great trac.ffmpeg.org appears to be down or what [05:30:06 CEST] <Atlenohen> okay i got the all-in-one installer from surceforge as I have no idea what to download [05:30:37 CEST] <Atlenohen> funny URLs the project is w64, then it's "targeting 32bit" and then the "64bit version" again mingw-w64/files/Toolchains targetting Win32/Personal Builds/mingw-builds/installer/mingw-w64-install.exe [05:41:30 CEST] <Atlenohen> SEH or SJLJ ? [05:57:02 CEST] <damdai> does ffmpeg support making 320x240 video to 640x480 video ? [05:57:39 CEST] <CarlFK> damdai: yes [05:57:58 CEST] <damdai> carlfk okay, how is that possible though [05:58:32 CEST] <damdai> that means extra 320x240 pixels comes from nothing [05:58:41 CEST] <damdai> that means extra 320x240 pixels must appear from nothing [06:00:06 CEST] <CarlFK> what are the names of your input and output files? [06:04:01 CEST] <CarlFK> ffmpeg -i in.mpg -s 640x480 out.mpg [06:05:14 CEST] <Atlenohen> there is no MSYS in MINGW installation [06:05:26 CEST] <Atlenohen> ffmpeg docs are seriously outdated, links don't work [06:05:43 CEST] <Atlenohen> eh [06:06:10 CEST] <Atlenohen> I'm done bothering with this for today ... which'll trun into this week, this month :p [06:21:57 CEST] <bray90820> is there a way to concatenate VOB files with ffmpeg? [06:22:22 CEST] <damdai> what do you mean by "concatenate [06:23:49 CEST] <bray90820> Combine 4 VOB files into one [06:25:02 CEST] <damdai> yes ffmepg supports that [06:48:05 CEST] <bray90820> damdai: what code would I use? [06:48:18 CEST] <damdai> you mean command? [06:48:43 CEST] <bray90820> Yes my bad [06:49:29 CEST] <damdai> ffmpeg -y f concat -i list.txt -map 0:v -map 0:a:2 -map 1:v -map 1:a:2 -map 2:v -map 2:a:2 -map 3:v -map 3:a:2 -map 4:v -map 4:a:2 -c copy -f mpegts joined.mpeg [06:50:16 CEST] <bray90820> That would do a passthrough of the video and audio right? [06:51:10 CEST] <damdai> actually use this: [06:51:12 CEST] <damdai> ffmpeg -i input1.mp4 -c copy -bsf:v h264_mp4toannexb -f mpegts intermediate1.ts [06:51:12 CEST] <damdai> ffmpeg -i input2.mp4 -c copy -bsf:v h264_mp4toannexb -f mpegts intermediate2.ts [06:51:12 CEST] <damdai> ffmpeg -i "concat:intermediate1.ts|intermediate2.ts" -c copy -bsf:a aac_adtstoasc output.mp4 [06:51:22 CEST] <damdai> but instead of .mp4 use .vob [06:53:14 CEST] <bray90820> Assuming those three should be on one line right? [06:53:25 CEST] <damdai> actually try this first: ffmpeg -i "concat:input1.ts|input2.ts|input3.ts" -c copy output.ts [06:53:33 CEST] <damdai> but instead of .ts use .vob [06:54:10 CEST] <damdai> let me know if that worked [06:56:06 CEST] <bray90820> It seems to be working [06:56:22 CEST] <bray90820> I'll let you know in a minute tho [06:56:22 CEST] <damdai> check the output.vob to make sure [06:56:34 CEST] <damdai> play the output.vob to make sure [06:57:01 CEST] <damdai> there is a chance it can create corrupted/unplayable file [06:57:19 CEST] <bray90820> I get a lot of these errors idk if it's a problem tho [06:57:19 CEST] <bray90820> [svcd @ 0x7ff517828000] buffer underflow st=0 bufi=79900 size=81218 [06:57:38 CEST] <damdai> i am not familar with that error message [06:58:23 CEST] <damdai> are you able to play individual .vob files fine? [06:58:24 CEST] <bray90820> Ok [06:58:40 CEST] <bray90820> Well the Vob file seems to play correctly [06:59:01 CEST] <damdai> you mean output.vob ? [06:59:05 CEST] <bray90820> Yes [06:59:13 CEST] <damdai> make sure video/audio sync match [06:59:38 CEST] <damdai> sometimes it can create non sync [07:00:26 CEST] <bray90820> Yes it's in sync [07:01:52 CEST] <damdai> if you joined 2 5:00 min video playback at 4:57-5:05 to check it joined smoothly [07:03:07 CEST] <bray90820> Yes it's good [07:04:52 CEST] <bray90820> Is that all I need to check [07:05:08 CEST] <damdai> i guess [07:06:56 CEST] <bray90820> Woot [07:06:59 CEST] <bray90820> Thanks for the help [10:21:56 CEST] <jya> is there a way with a h264/mp4 video that contains no colorspace information in the SPS NAL (colour_description_present_flag is false), to rework it quickly to say it's BT601 ? [10:23:14 CEST] <furq> jya: https://www.ffmpeg.org/ffmpeg-bitstream-filters.html#h264_005fmetadata [10:23:57 CEST] <jya> furq: do you know how you call this ? [10:28:10 CEST] <furq> -i foo.mkv -bsf:v h264_metadata=colour_primaries=6:transfer_characteristics=6:matrix_coefficients=6 -map 0 -c copy bar.mkv [10:29:49 CEST] <jya> awesome thank you [10:30:03 CEST] <furq> 6 is smpte170m which is correct for ntsc iirc [10:30:10 CEST] <furq> i think you'd want 5 (bt470bg) for pal [10:30:19 CEST] <jya> smpte170m is what I want [10:30:38 CEST] <jya> we don't differentiate bt470bg from smpte170m anyway [11:16:53 CEST] <JsbBpk> Hello ! [11:17:22 CEST] <JsbBpk> I am facing a problem with http version and ffplay. Even though http version is 1.1, connection header is still "close" not "keep-alive" [11:19:18 CEST] <JsbBpk> ffplay version N-93544-g0a347ff422 Copyright (c) 2003-2019 the FFmpeg developers built with gcc 8.2.1 (GCC) 20190212 [11:22:18 CEST] <JsbBpk> It looks like this bug : https://trac.ffmpeg.org/ticket/5845 (fixed 3 years ago) [11:51:24 CEST] <DHE> based on the code it looks like there is an onus on the user to explicitly set the header themselves and ffmpeg should roll with it [13:39:36 CEST] <Atlenohen> Anyone around, trying to put another go at building ffmpeg on windows, for windows [13:39:48 CEST] <Atlenohen> don't need any other target platforms just win64 [13:40:20 CEST] <BtbN> The easiest way to build for Windows is to install Linux, or use WSL, and cross compile it. [13:53:53 CEST] <Mavrik> Won't WSL give you linux binaries? [13:54:21 CEST] <Mavrik> As opposed to just installing Mingw-64? [13:58:48 CEST] <furq> you can install mingw in wsl [13:58:59 CEST] <BtbN> Well, I said cross compile for a reason [13:59:41 CEST] <furq> i should really get a wsl toolchain set up [14:00:02 CEST] <BtbN> I'm waiting for the 1903 update to land so I can finally replace Cygwin with WSL [14:00:05 CEST] <furq> the only distro i know of with mingw packages or ports is arch and for some awful reason they decided to move mingw into the aur [14:00:27 CEST] <furq> hell yeah i want to compile gcc myself [14:00:28 CEST] <BtbN> Hm? Ubuntu and Debian both have mingw64 packaged just fine [14:00:39 CEST] <furq> i mean libraries packaged for mingw [14:01:05 CEST] <BtbN> You can use mxe if you need something more complex [14:01:45 CEST] <furq> arch has mingw pkgbuilds for pretty much all the ffmpeg deps i want [14:01:53 CEST] <furq> so i mistakenly thought that would make it easier [14:01:58 CEST] <furq> but i forgot that it also involves using arch [14:03:57 CEST] <Mavrik> What does using WSL give you though? [14:04:02 CEST] <BtbN> Ubuntu [14:04:17 CEST] <BtbN> But people have ported pretty much all common distros to it [14:04:25 CEST] <furq> something theoretically less likely to kill itself than msys2 is [14:05:39 CEST] <BtbN> 1903 WSL will finally allow access to WSL files from regular applications [14:06:05 CEST] <furq> i couldn't help but notice that configure is still a lot slower than it is in a vm [14:06:11 CEST] <furq> so i guess the fork emulation still isn't up to par [14:06:22 CEST] <furq> it is way faster than msys/cygwin fork though [14:06:23 CEST] <BtbN> There is no fork emulation [14:06:38 CEST] <BtbN> Windows implemented fork in their kernel long ago, both Cygwin and WSL use that now [14:06:43 CEST] <BtbN> MSYS does not however [14:07:25 CEST] <BtbN> configure on Windows is primarily slow because of I/O [14:13:19 CEST] <Atlenohen> Well I don't have a HDD spare to installa linux to, I wanted to do it on Mint but it's not looking like a fast thing I could do on the live boot [14:13:49 CEST] <Atlenohen> I'm also in the middle of HDD/Data archial/sorting/maintennace, [14:13:57 CEST] <BtbN> Just use WSL then [14:14:12 CEST] <Atlenohen> Perhaps running linux in virtualbox or so? [14:15:52 CEST] <BtbN> If you just want to compile, there is no reason to deal with that. WSL does that just fine. [14:28:13 CEST] <JsbBpk> Hello again ! Thank you for your reply about http headers. It worked [14:32:37 CEST] <JsbBpk> However, http_version option seems not working in version available on your website [14:33:09 CEST] <JsbBpk> ffplay version N-93544-g0a347ff422 Copyright (c) 2003-2019 the FFmpeg developers built with gcc 8.2.1 (GCC) 20190212 [14:33:59 CEST] <JsbBpk> For instance : ffplay.exe -http_version "1.0" Error : Error setting option http_version to value 1.0 [14:34:12 CEST] <JsbBpk> same without quotes [14:38:56 CEST] <DHE> I don't host ffmpeg builds, that's for sure... [14:40:29 CEST] <JsbBpk> I just tested the behavior with keep-alive header. ffplay keeps closing the socket [14:44:20 CEST] <Hackerpcs> on hydrogenaud.io wiki it says that aoTuV vorbis is the recommended encoder of vorbis, does libvorbis include its improvements? I'm mostly interested in Q 7-8 [14:46:09 CEST] <furq> didn't all the aotuv stuff get merged back into mainline eventually [14:46:29 CEST] <furq> also you should be using opus instead of vorbis if your device supports it [14:47:08 CEST] <Hackerpcs> opus cuts off high frequencies [14:47:29 CEST] <JEEB> so do all audio encoders that are lossy [14:47:40 CEST] <JEEB> it might be configurable depending on the encoder [14:47:41 CEST] <Hackerpcs> Don't know so that's why I ask about libvorbis [14:48:00 CEST] <Hackerpcs> fdk aac (thanks furq) on VBR 5 doesn't, vorbis too on Q 8 [14:48:13 CEST] <furq> lame v0 doesn't either [14:48:17 CEST] <Hackerpcs> it does [14:48:23 CEST] <Hackerpcs> ~20k [14:48:25 CEST] <JEEB> that's surprising, I'd have thought it still does cut around 21-22kHz [14:48:26 CEST] <furq> it hasn't for quite a while [14:48:38 CEST] <furq> with that said 20khz is fine [14:50:16 CEST] <furq> https://0x0.st/slrd.png [14:50:18 CEST] <furq> that's 3.100 v0 [14:50:26 CEST] <furq> weirdly 320 still cuts off at 20khz [14:50:53 CEST] <furq> no idea what the rationale for that is but it's cbr mp3 in 2019 so who cares [14:51:14 CEST] <Atlenohen> btbn: but since the compilation guides are outdated what does that help me unless someone is guiding me through the process it'll take me forever, but oh wll [14:51:28 CEST] <Hackerpcs> true I was wrong, V0 doesn't cut [14:52:16 CEST] <Atlenohen> so WSL is different thatn using virtualbox [14:52:35 CEST] <Atlenohen> I'd figure VM is a less intrusive thing than setting up WSL env [14:52:50 CEST] <Atlenohen> Don't want to mess my Win10 up where I have other env setup [14:53:06 CEST] <Hackerpcs> which platform Atlenohen? on Win10 https://github.com/jb-alvarado/media-autobuild_suite works nicely, compiled this morning [14:53:56 CEST] <Hackerpcs> Win10 LTSC 64 here [14:57:08 CEST] <furq> Hackerpcs: anyway, i don't think the libvorbis api changed recently, so you could presumably just build ffmpeg with an aotuv libvorbis [14:57:21 CEST] <furq> i would still just use opus though [14:58:33 CEST] <furq> also i was technically right about the changes being merged back into mainline except it was in 2004 [14:58:42 CEST] <furq> so only about 10 years out [15:06:34 CEST] <Atlenohen> Hackerpcs: LTSB, not LTSC yet [15:06:58 CEST] <Hackerpcs> it doesn't matter as you don't use WSL with the above [15:07:07 CEST] <Hackerpcs> I don't have WSL at all, I use cygwin [15:07:17 CEST] <Atlenohen> Yeah, good then [15:08:53 CEST] <Atlenohen> By the way I'm not sure if this is called compiling or not, but I have to make libraries as it was before, i still have the old "compiled" ones [15:09:36 CEST] <Atlenohen> they're just .lib files as in avcodec.lib and the file starts with the term !<arch> [15:10:33 CEST] <BtbN> How is installing a full VM environmentr with kernel mode drivers and everything less intruse than installing Ubuntu from the Windows store which then runs pretty much natively? oO [15:11:35 CEST] <BtbN> and compiling ffmpeg boils down to running configure with the options you desire, and then make [15:12:33 CEST] <Atlenohen> btbn: oh sorry, the offices still use LTSB from 2016 and Windows Store is not allowed, I'm not sure if WSL goes that far back, among many other things, long story but it's company policy [15:13:14 CEST] <BtbN> you want the latest version for WSL [15:13:20 CEST] <BtbN> it gets steadily improved [15:14:47 CEST] <Hackerpcs> https://superuser.com/a/1369767 "Windows 10 LTSB 2016 is build 14393, and you need at least build 16215 to run WSL" [15:15:29 CEST] <BtbN> didn't they end support for 1709 recently? A build from 2016 doesn't seem like the best idea. [15:15:30 CEST] <Hackerpcs> LTSC is 17763 [15:15:51 CEST] <Hackerpcs> LTSB is 10 year supported like LTSC [15:16:09 CEST] <Hackerpcs> it's Win10 enterprise [15:17:01 CEST] <Hackerpcs> Atlenohen: do you need to pay to upgrade to LTSC from LTSB or it's free? [15:17:42 CEST] <Hackerpcs> basically LTSx is similar to windows 7 [15:17:51 CEST] <Hackerpcs> in support manner [15:22:05 CEST] <Atlenohen> Not sure about that stuff I wasn't setting any of the OS stuff up around here currently. [15:23:27 CEST] <Atlenohen> What's confusing is there's so many terms and it's like a sea of version,subversion,editions,packs,combinations,platforms, msys, msys64,msys2, msys+gcc, mingw+msys, mingw+msys1+msys2 ... just oh [15:23:55 CEST] <Hackerpcs> why do you want to compile and don't grab a zanoe build? [15:24:35 CEST] <Atlenohen> One of the guides said I have to go into msys inside mingw, I install mingw and there is no msys inside it, then double msys1 and msys2 ... [15:25:49 CEST] <Atlenohen> hackerpcs: that's because zeranoe does not provide proper .lib files, he provides only placeholders for delayed DLL loading, not for integration in another project for final compilation later. [15:26:05 CEST] <Hackerpcs> oh ok [15:26:46 CEST] <Atlenohen> And, we don't need full blown FFMPEG, can disable most stuff and only need a few codecs/formats [15:27:09 CEST] <BtbN> He builds with gcc [15:27:13 CEST] <BtbN> There are no .lib files [15:28:03 CEST] <BtbN> but looking at his build... there are .def, .lib and .dll.a files in there. So he added compatiblity for everything one can thing of. [15:29:07 CEST] <BtbN> Of course those are for shared linking the .dll. He intentionally does not provide static libs, because you cannot use those anyway in most cases due to GPL [15:29:22 CEST] <Atlenohen> Yes, they are in the -dev package, to be used with compatible .dlls [15:30:21 CEST] <Atlenohen> Oh so it's a license thing? [15:30:50 CEST] <BtbN> You can only statically link GPL libs into projects with a GPL compatible free license [15:31:01 CEST] <BtbN> If he'd offer static libs, most people would abuse them [15:33:26 CEST] <Atlenohen> Oh, I see, well then I would recommend the proper change to the master project to change it over to DLLs, however I don't believe this was released earlier, it supposed to be an internal helper utility. [15:33:47 CEST] <Atlenohen> Would that be a problem either way? [15:35:17 CEST] <furq> honestly cross-compiling is easy if you don't need any external libraries [15:35:23 CEST] <furq> the guides on the wiki are massively overengineered for that [15:36:41 CEST] <furq> nowadays with debian/ubuntu you can just install mingw-w64 and then ./configure --cross-prefix=x86_64-w64-mingw32- --target-os=mingw32 [15:42:34 CEST] <Hackerpcs> https://images2.imgbox.com/56/2d/kA8des51_o.png -- flac vs opus vs vorbis vs fdk aac vs lame, roughly same sizes. fdkaac seems the best and I can't hear any audible difference in any of them (AKG K240, Realtek mobo soundcard, no amp) [15:43:38 CEST] <furq> you won't hear any difference at 256kbps [15:44:01 CEST] <Hackerpcs> does opus have any alt setting that may not cut off? [15:44:14 CEST] <furq> there's -cutoff but i think it clamps at 20khz [15:44:29 CEST] <Hackerpcs> ah true, forgot the cutoff [15:44:39 CEST] <Hackerpcs> yes there is a hard limit at 20k [15:45:13 CEST] <Hackerpcs> no scrap that, that's fdkaac [15:45:59 CEST] <Hackerpcs> no that's correct actually "Cutoff frequency must be exactly one of: 4000, 6000, 8000, 12000 or 20000.", it just doesn't fail like fdkaac [15:49:25 CEST] <Hackerpcs> but there's no difference with -cutoff 20000, it defaults to that "Invalid frequency cutoff: 24000. Using default maximum bandwidth." [15:50:18 CEST] <Hackerpcs> sorry for the spam :P [15:52:16 CEST] <Atlenohen> Okay, I checked with mgmt, the utility was released as free, for fixing in some cases, can update it with proper GPL and include source so it shouldn't be a problem [15:53:43 CEST] <Atlenohen> Hackerpcs: I'll give this script a shot, I might want to know how to build ffmpeg for me personally for anything that may come up in future anyway, but does the script support static libraries out of the box or would I need to modify the install script? [15:54:04 CEST] <Atlenohen> It's asking me how would I want to build FFMPEG, non-free, GLPv3, etc [15:54:15 CEST] <Atlenohen> Or I can set all those things later? [15:55:06 CEST] <Hackerpcs> you set the settings to customize what you want to have available. I compiled to use the fdkaac which isn't available as a binary because of licensing [15:55:35 CEST] <Hackerpcs> unless you want something specific like that, for personal use zeranoe builds are fine [16:00:30 CEST] <Atlenohen> Hackerpcs: I said, zeranoe doesn't do static libraries, I did some calls and it's possible to go this route as this is a small free utility for internal and some customer maintenance use which can be updated with proper GPL/source, I wouldn't want to mess with changing the master project to do DLLs since I don't manage the whole thing, besides I decided it's a good opportunity to learn how to build things manually for me personally [16:00:30 CEST] <Atlenohen> as a bonus, might come hand in future elesewhere. [16:01:30 CEST] <Hackerpcs> I was talking about personal use in your last message, I don't know about the project situation/needs [16:02:45 CEST] <Atlenohen> Hackerpcs: You are misunderstanding, I am not personally using this right now, I was talking about the personal experience of setting up a build environment and building from source, the experience I would get from this it may help me in future unrelated cases. [16:03:28 CEST] <Atlenohen> So I prefer this over DLLs right now, I just explained one of the reasons. [16:04:21 CEST] <Atlenohen> So I'm assuming in order to build static-library I probably need to turn some knobs and switches within the build environment, or maybe they are automatically generated by default? [16:05:00 CEST] <Hackerpcs> It's pretty noob-proof (like me), you just select static and it builds ffmpeg.exe, ffprobe, etc and that's all you need. I just moved the three exes to my C:\tools\bin folder plus h264 and it works. During the script you select what you want and it's done automatically, you don't mess with msys2 environment [16:05:02 CEST] <BtbN> Building static libs is the default. [16:05:28 CEST] <Atlenohen> BtbN: Thanks. [16:06:16 CEST] <Atlenohen> BtbN: Well, https://github.com/jb-alvarado/media-autobuild_suite it could be different here but, only one way to find out is just try it :) [16:06:33 CEST] <BtbN> that's something very third party and not supported here [16:08:29 CEST] <Atlenohen> Yeah, that's why I'm asking hackerpcs: who linkes to this, to confirm whether that thing is setup to build most of the things or only .exe ? [16:11:22 CEST] <Hackerpcs> Atlenohen: https://pastebin.com/dq4u2ddq [16:12:23 CEST] <rcabrera> Hello, I am parsing this args with avfilter_graph and creating a filter graph, however even I get the frames from the buffersink the filter doesn't seem to be applied. [16:12:49 CEST] <rcabrera> https://pastebin.com/LATvky15 [16:13:19 CEST] <rcabrera> Any idea of why this could be happening? [16:14:09 CEST] <rcabrera> The image should be flipped but instead I see the frame as if no filters were applied [16:14:44 CEST] <Hackerpcs> the whole local folder, plus my build options https://pastebin.com/V2KHk6Jb [16:50:54 CEST] <Improvotter> Is it possible to tell ffmpeg to use an intermediary file and copy it to its destination once the task is done without doing `ffmpeg ... && mv in out`? [16:52:26 CEST] <DHE> pretty sure the answer is No [16:52:45 CEST] <Improvotter> DHE: alright, I asked just in case. Thank you. [18:07:47 CEST] <zerodefect> I have a simplish code example (https://pastebin.com/BZzqGZtB) which uses the C-API in libswscale to convert a set of buffers from 720p @ YUV420P to 720p @ YUV422P. When I use the electric fence library (libefence.so) with LD_PRELOAD, a segfault is reported. I'm allocating/sizing the buffers myself. Now when I use an AVFrame and allocate a buffer using the corresponding API, it does not [18:07:47 CEST] <zerodefect> crash. [18:29:58 CEST] <zerodefect> http://ffmpeg.org/doxygen/trunk/frame_8c_source.html#l00211 - I think I've figured out my problem. It appears that the height must be padded to 32 lines (if not evently divisble by 32). [18:36:56 CEST] <kepstin> zerodefect: yeah, some of the code in ffmpeg overreads past the ends of the frame, so that special handling isn't required for boundary conditions when using vector instructions. (libswscale in particular requires this, iirc) I thought that there were some notes about this in some of the headers. [18:39:40 CEST] <DHE> the AVFrame method involves calling av_frame_get_buffer which specifically asks for a padding value [18:40:50 CEST] <kepstin> yeah, the get_video_buffer function in that link^ is what av_frame_get_buffer ends up calling. It uses a default padding of 32 if you didn't pass a padding (used 0) [18:42:08 CEST] <kepstin> looks like you can call the av_cpu_max_align() function instead of hardcoding a value if you prefer [19:06:21 CEST] <Atlenohen> hey guys does this line still hold true? [19:06:22 CEST] <Atlenohen> Then run the mingw32_shell.bat or mingw64_shell.bat command in the MSYS2 installation home. Be careful not to run the MSYS2 Shell as this will result in FFmpeg's configure saying building an MSYS binary is not recommended and exiting. [19:26:30 CEST] <zerodefect> Thanks @DHE and @kepstin :) [20:36:30 CEST] <mauz555> hello multimedia gurus [20:37:24 CEST] <mauz555> I'm trying to stream audio microphone speech to an local nginx rtmp server and consume on another lan-connected computer [20:37:35 CEST] <mauz555> like this `ffmpeg -re -f avfoundation -ac 1 -i ":0" -acodec pcm_s16le -ab 16k -ac 1 -f flv -rtmp_app speech -rtmp_playpath test rtmp://127.0.0.1:1935/` [20:38:16 CEST] <mauz555> I can't hear anything on the consumer side (VLC or rtmpdump) [21:07:18 CEST] <Atlenohen> From the what I figured this gcc thing has a load of ports/forks whatever, the FFMPEG guide says "i could install gcc in msys and skip above (pacman) steps" as one user puts it's "it's quite clear" to him, that's rich, I think i have a word for it, excuse me, a clusterfuck of namings https://superuser.com/questions/996332/what-is-the-difference-between-the-d… [21:07:44 CEST] <Atlenohen> So if gcc isn't made for windows, why would one install "gcc" [21:08:17 CEST] <Atlenohen> and msys is like gcc port anyway or what? .. sorry cygwin fork [21:08:46 CEST] <Atlenohen> so why would I need a cygwin fork(which is a gcc port again) if I then install the base gcc inside msys2 [21:20:51 CEST] <Atlenohen> there's no usr/local/bin in the msys64 root directory or in mingw64 [21:21:07 CEST] <Atlenohen> okay maybe it gets created later, i'll put it in just bin [22:50:29 CEST] <cptnhmr42> Hi! I'm using ffmpeg to convert an rtmp stream to an mpeg dash stream (using the -f dash flag). I want to keep the source audio and video and add an additional encoded video stream. The issue I'm having is that audio drifts over time. Here is the command I'm running https://pastebin.com/7krDpGsv [22:52:11 CEST] <cptnhmr42> How can I keep all 3 streams in sync? [23:45:19 CEST] <phisch> i have a short bash script that runs ffmpeg to record a part of the screen, when hitting ctrl+c (sigint) a trap catches it, sends a sigint to the ffmpeg background process and continues with other stuff. this works when i run the script in one terminal, and send the sigint to the script from another terminal. but when hitting ctrl+c, ffmpeg just in [23:45:19 CEST] <phisch> stantly dies horribly [23:45:27 CEST] <phisch> this is the script: https://pastebin.com/HjsrpxsB [23:46:54 CEST] <phisch> it feels like when i hit ctrl+c ffmpeg somehow receives 2 sigints, the one that i send it, and a ghost one, but i am wondering where the ghost one comes from [23:47:02 CEST] <phisch> (if this is the case at all) [23:53:17 CEST] <kepstin> phisch: your interactive shell might be sending the signal to the entire process group rather than just the foreground task. [00:00:00 CEST] --- Thu Apr 11 2019

1 0

ffmpeg-devel.log.20190409
by burek 10 Apr '19

10 Apr '19

[03:18:24 CEST] <cone-053> ffmpeg 03Jun Zhao 07master:0a347ff42223: lavf/matroskaenc: Fix memory leak after write trailer [04:03:34 CEST] <jamrial> half the fate clients haven't yet synced the new sample, so it all looks very yellow [13:19:03 CEST] <nevcairiel> its been three days and some fate clients still lack a sample? [13:19:12 CEST] <nevcairiel> are they using a different sample source or some other nonsense? [15:30:25 CEST] <cone-424> ffmpeg 03Carl Eugen Hoyos 07master:d6a8392224c0: lavf/movenc: Pass correct pointer to av_log(). [15:50:08 CEST] <cone-424> ffmpeg 03Tristan Matthews 07master:1ec777dcdd03: avformat/matroskaenc: fix leak on error [17:12:54 CEST] <cone-424> ffmpeg 03Jeremy Dorfman 07release/4.1:420fe39aff3d: avformat/av1: Initialize padding in ff_isom_write_av1c [17:12:55 CEST] <cone-424> ffmpeg 03Tristan Matthews 07release/4.1:cf7a5c655c04: avformat/matroskaenc: fix leak on error [18:50:14 CEST] <philipl> BtbN: well, that was a generally unhelpful response re nvenc. [18:51:14 CEST] <BtbN> What they propose is not really sensible possible in the context of ffmpeg [18:51:25 CEST] <BtbN> It is if you embed nvenc into an application [18:57:10 CEST] <philipl> Worst case you add some flag to indicate you're using it with a fixed frame pool and don't need to unregister every time? [19:12:41 CEST] <nevcairiel> that seems like a rather hacky option [19:13:21 CEST] <philipl> It is. Maybe it can be detected? I have not thought hard about it. [19:13:23 CEST] <nevcairiel> before doing anything I would definitly try to get nvidia to comment on it [19:13:36 CEST] <philipl> the nvidia guys said don't unregister until you free the frame. [19:13:39 CEST] <philipl> which we can't really do. [19:15:21 CEST] <nevcairiel> does this problem apply to cuda input, software input, or both? [19:16:54 CEST] <philipl> The 'problem' is that unregistering after unmap (when the buffer is actually going to be reused) causes a throughput bottleneck in nvenc. That applies to every scenario, although it's only detectly in extreme parallel encoding situations. [19:17:07 CEST] <philipl> s/detectly/detectable/ [19:17:32 CEST] <philipl> The guy in the ticket has three big quadroos and wants to do 60 parallel encodes on one system for whatever reason. [19:17:55 CEST] <nevcairiel> 60 encodes doesnt seem like it would run any faster then 2x 30 encodes in series [19:18:17 CEST] <philipl> Depending on the exact pipeline setup, there may be a fixed buffer pool being reused all the time, in which case delayed unregistration is fine. [19:18:34 CEST] <philipl> Or there may be buffers getting deallocated and newly allocated each time, in which case it is not fine. [19:18:44 CEST] <philipl> I'm not sure which pipelines are which. [19:18:54 CEST] <philipl> nevcairiel: and yes, one would asssume that is so if full utilisation occurs. [19:21:44 CEST] <nevcairiel> even the big quadro cards dont have more encoding resources. some get a second nvenc engine, and thats it, afaik? [19:22:35 CEST] <philipl> They may have an additional engine, but nvidia also lifts the artifical limit on the number of parallel encodes on a single engine. [19:22:50 CEST] <nevcairiel> you can lift that with mild driver hacking on c onsumer cards too [19:23:10 CEST] <philipl> I don't know how silly this guy's scenario is (but I have suspicions), but it is true that the official nvidia recommendation is not to unregister all the time. It's relatively expensive and they don't consider that a bug. [19:23:37 CEST] <nevcairiel> our architecture doesnt really allow anything else and still feeling "clean" tho [19:24:08 CEST] <nevcairiel> I wonder what happens if you dont unregister and then dont use a fixed pool [19:24:35 CEST] <philipl> Presumably some sort of resource leak that eventually leads to errors the next time you try to register. [19:25:16 CEST] <nevcairiel> thats the only place we unregister, isn't it? so the pool is never unregistered, and presumably if you make enough pools or something, it might also result in that? [19:25:57 CEST] <nevcairiel> or maybe nvenc cleans it up when the session is closed [19:27:18 CEST] <philipl> I would hope so. Presumably someone could use a custom pool implementation that actually did full allocations and deallocations (rather than maintaining a pool) and that would create the pathological scenario? [19:27:22 CEST] <nevcairiel> tying that to the frames lifetime would be ideal, but alas we can't exactly have encoders messing with the incoming avframe [19:28:08 CEST] <philipl> I asked BtbN if we could register a deallocation hook, but that requires keeping the nvenc alive - unless we convince ourselves that closing the session cleans things up and then we just need a weak reference. [19:28:13 CEST] <philipl> Still messy, but not crazy. [19:28:52 CEST] <philipl> We sort of do this on the decoder side where frames are owned by the encoder and returned via a custom pool. The frames hold a decoder ref. [19:29:14 CEST] <philipl> but in that case the decoder is the actual allocator. [19:29:27 CEST] <philipl> s/encoder/decoder/ [19:30:46 CEST] <BtbN> That's done via a custom deallocator in the buffer pool [19:30:54 CEST] <BtbN> nvenc can't do that, since it's not allocating the frames [19:31:22 CEST] <philipl> We'd need to add a new buffer pool mechanism for generic deallocation callbacks. [19:32:15 CEST] <BtbN> Which would actually need to be attached to the internal buffer pool, not to the frame [19:32:20 CEST] <BtbN> since the frame _does_ get freed eventually [19:32:24 CEST] <BtbN> the underlying buffer does not [19:33:50 CEST] <philipl> Yes. [19:41:52 CEST] <siperman> hello [19:42:19 CEST] <siperman> someone can help applying a patch to solve an issue to ffmpeg [19:42:20 CEST] <siperman> ? [19:45:06 CEST] <Kwiboo> philipl: I added get+release callbacks for buffer pool in https://github.com/Kwiboo/FFmpeg/commit/42e3ab0b889a736fcbbdb50086b1a645844… when I was looking for a resource leak in my v4l2 request api hwaccel + kodi, not sure if something like that is what you had in mind with mechanism for generic deallocation callbacks [19:46:36 CEST] <philipl> Kwiboo: it's not quite that. We would need to attach a callback from a frame consumer (the nvenc encoder) that would fire when the buffer was eventually deallocated (and not when the frame is freed) [19:46:46 CEST] <philipl> So it's not something you set up at bool init time. [19:46:55 CEST] <philipl> s/bool/pool/ [19:49:50 CEST] <Kwiboo> philipl: I see, a little bit more complex scenario [20:00:45 CEST] <siperman> hello [20:02:46 CEST] <siperman> i have a problem with Inconsistent UDP output packet size [20:02:53 CEST] <siperman> can someone help me [20:02:54 CEST] <siperman> ? [23:17:45 CEST] <cone-114> ffmpeg 03Jarek Samic 07master:1c50d61a5a68: libavutil/hwcontext_opencl: Fix channel order in format support check [00:00:00 CEST] --- Wed Apr 10 2019

1 0

ffmpeg.log.20190409
by burek 10 Apr '19

10 Apr '19

[00:12:43 CEST] <faLUCE> DHE: it seems that if I force a keyframe, while encoding, the global quality decrease and remains with that lower quality [00:13:20 CEST] <DHE> keyframes are large. forcing them will negatively impact quality. [00:13:38 CEST] <faLUCE> DHE: ok, but why that quality remains bad forever? [00:13:57 CEST] <DHE> you don't get stuck using keyframes the whole way from then on are you? [00:16:52 CEST] <faLUCE> DHE: you are right again [00:17:07 CEST] <faLUCE> so, How can I unset AV_PICTURE_TYPE_I ? [00:17:43 CEST] <faLUCE> (on pict_type) [00:18:07 CEST] <faLUCE> AV_PICTURE_TYPE_NONE ? [00:18:24 CEST] <DHE> yeah [00:18:25 CEST] <JEEB> yes, anything that is not I/P/B goes to default [00:18:35 CEST] <JEEB> which is X264_TYPE_AUTO [00:20:26 CEST] <DHE> it's worth noting there's a special setting for x264 that makes I frames into IDR frames, which may be what you want [00:21:15 CEST] <faLUCE> what a asshole I was ;-). x264 was soo good that I even did note that all were keyframes... [00:21:22 CEST] <faLUCE> I did not note [00:23:07 CEST] <DHE> called it [02:52:30 CEST] <Ariyasu> maybe offtopic question [02:52:48 CEST] <Ariyasu> if my display is set to 2160p and im playing a 1080p video [02:53:19 CEST] <Ariyasu> what is handling the upscaling to 2160p? the media player? the display itself? the os? [02:55:01 CEST] <tlacatlc6> that'd be the media player [03:40:05 CEST] <dongs> uh, depends completely on what is playing, and waht mode etc. [03:42:45 CEST] <Hello71> if you have dpi scaling on your media player that's a shit media player [03:43:20 CEST] <Ariyasu> i use mpc-hd with lav and playing back a m2ts from bluray [03:43:30 CEST] <Ariyasu> i was just curious what was handling the scaling [03:43:35 CEST] <klaxa> the most sane way would be some scaling filter in the player [03:43:39 CEST] <Ariyasu> mpc-hc* [03:43:43 CEST] <klaxa> and that's what probably all do [03:44:01 CEST] <klaxa> you can make the OS scale it by reducing the screen resolution [03:44:18 CEST] <klaxa> the display should only output what it is fed [03:44:52 CEST] <klaxa> having the scaling done in the player adds the advantage that you can choose how to scale [03:45:29 CEST] <klaxa> also probably less syscalls if you had to call the OS to scale [03:51:37 CEST] <dongs> yeah but like, if youre in fullscreen exclusive mode it could be your gpu or your monitor [03:52:00 CEST] <dongs> Hello71: dpi has nothing to do with this [03:52:06 CEST] <klaxa> wouldn't that scale on OS level then? [03:52:19 CEST] <dongs> thats what im saying, theres not enough information in the question to ansewr [03:52:42 CEST] <klaxa> i think there is enough information [03:52:44 CEST] <dongs> "i play back 1080p video on 2160p screen, what is doing the scaling"? answer: could be anything depending on how its done [03:52:59 CEST] <dongs> klaxa, what if its not even fullscreen [03:53:02 CEST] <dongs> then there's no scaling. [03:53:03 CEST] <klaxa> ><Ariyasu> i use mpc-h[c] with lav and playing back a m2ts from bluray [03:53:22 CEST] <klaxa> ><Ariyasu> what is handling the upscaling to 2160p? the media player? the display itself? the os? [03:53:34 CEST] <dongs> decoder will output 1080p, eihter renderer or gpu or monitor will be scaling [03:53:45 CEST] <dongs> depending on screen mode [03:53:46 CEST] <klaxa> should probably be a setting in the player [03:56:32 CEST] <Hello71> the question specifically says "set to 2160p" [03:57:57 CEST] <dongs> the real answer is nobody gives a shit cuz you wont notice the difference anyway. [03:58:00 CEST] <dongs> :) [03:59:01 CEST] <klaxa> blasphemy! [12:08:18 CEST] <sadasaulna> Hi. Is the warning "[mp3float @ 0x7f7ff7b03800] Could not update timestamps for skipped samples." something I should worry about? [12:36:57 CEST] <DHE> it probably means the file is damaged. mp3 is recoverable with some glitchy sound where the damage is... [13:45:19 CEST] <ozette> Does anyone know if MPEG-4 Part 2 can be decoded by browsers? I got a .mp4 here, which won't play in chrome nor firefox. It was "converted" from a .mpeg, I don't know how exactly, but supposedly 4videosoft's 'video converter' was used [13:45:39 CEST] <ozette> Chrome says: Resource interpreted as Document but transferred with MIME type video/mp4 [13:46:03 CEST] <ozette> Firefox says a whole lot and then: No MP4 audio () or video () tracks [13:46:49 CEST] <furq> no it can't [13:46:53 CEST] <ozette> MediaInfo shows 'Video' in Tree view and under that: Format: MPEG-4 Visual [13:46:58 CEST] <ozette> oh [13:47:31 CEST] <furq> mpeg-4 part 2 is like divx/xvid etc [13:47:46 CEST] <furq> browsers will generally only decode h.264 (mpeg-4 part 10 if you want to be technical) [13:47:52 CEST] <furq> at least in mp4 [13:47:59 CEST] <ozette> Yea I noticed [13:48:17 CEST] <ozette> I'm not familiar with divx or vidx codecs [13:49:32 CEST] <ozette> Thanks :) [17:43:26 CEST] <pkeroulas_> I'd like to convey closed captions in flv/rtmp stream. It is suggested to use AMF messages and more precisely "onCaptionInfo" event to do that. Is there any support/example/doc in ffmpeg for that use case? [17:47:15 CEST] <pkeroulas_> apparently, the flv decoder can handle such messsages but not the encoder [18:26:26 CEST] <zerodefect> When scaling YUV420p with sws_scale() (using C-API), do I have to make any explicit considerations for chroma subsampling when setting up the scaler? I'm getting a crash, but I can't quite put my finger on the problem. [18:31:57 CEST] <DHE> the input data fields need to be arrays of pointers. maybe you're providing the wrong frame fields? [18:35:19 CEST] <zerodefect> Well, what's interesting is my logic works for YUV422P but not YUV420P. In my height calculations, I'm not taking chroma subsampling into consideration, but I think that is ok. The problem is definitely my side, but just trying to corner it. [18:50:23 CEST] <DHE> I just call sws_scale(scaler, (const uint8_t* const*)source_frame->data, source_frame->linesize, 0, input_h, frame->data, frame->linesize); // source source_frame is the input, and frame is the output. I'm going 420p to 420p but it's been fine for me... [18:55:04 CEST] <Mavrik> linesize array is the prime suspect there [19:28:05 CEST] <dablitz> start : ---> ffmpeg -f alsa -i hw:1,0 -acodec libopus -ar 8000 -sdp_file sdp -f rtp rtp://192.168.100.21:52000 [19:28:05 CEST] <dablitz> <dablitz> and when i play : ---> ffplay -nodisp rtp://192.168.100.20:52000 [19:28:05 CEST] <dablitz> <dablitz> it should allow the audio to stream from one computer to the next. I do get cli showing stings are happening on the sending side...but nothing on the recieving side [19:28:05 CEST] <dablitz> * alex`` (~alex(a)aputeaux-651-1-292-49.w86-249.abo.wanadoo.fr) has joined [19:28:05 CEST] <dablitz> <dablitz> ffplay just sits : nan : 0.000 fd= 0 aq= 0KB vq= 0KB f=0/0 [19:39:29 CEST] <siperman> hello [19:40:15 CEST] <siperman> i need some help with ffmpeg running on ubuntu [19:40:28 CEST] <siperman> i am using it to make an udp stream [19:41:18 CEST] <siperman> i have a problem with the packet creation, and i read on the wiki that i need to apply a patch [19:41:25 CEST] <siperman> i downloaded the patch [19:41:36 CEST] <siperman> but i dont know how to apply it [19:43:42 CEST] <DHE> for mpegts? [19:44:42 CEST] <siperman> yes [19:45:49 CEST] <siperman> i have a problem when i use the pkt_size=1316, the files are not constant sized, is well known problem and auser create a patch, but i dont know how to apply it [19:47:32 CEST] <DHE> I see... I've not actually had that as a problem though. nothing's complained about the packet sizes [19:49:29 CEST] <siperman> did you need to apply a patch in the past? [19:50:47 CEST] <DHE> I see small packets from time to time. but there's been nothing on the network complaining about it so I've just ignored it as a non-issue [19:50:54 CEST] <DHE> curious what you have that's causing you grief [19:53:26 CEST] <siperman> the problem is because i am trying to send the feed to an equipment that i am thinking is the decoder from hell [19:53:40 CEST] <siperman> but the decoder doesent see the udp packets [19:54:14 CEST] <DHE> multicast? [19:54:33 CEST] <siperman> the brand and the model os the decoder is Ateme Kyrion DR5000 [19:54:48 CEST] <siperman> no, i am sending as an unicast [19:55:02 CEST] <siperman> i am sending the packags directly to the decoder [21:21:52 CEST] <zerodefect> @DHE / @Mavrik - Silly mistake with my YUV420p scaling problem - the height of the frame was not a multiple of 2 so the scaler was reading off the end of the buffer :( [21:23:51 CEST] <pranayvshah> Can anyone please help me with an issue regarding burning Indic subtitles into a video. Works perfectly fine with Handbrake GUI and CLI and also when the subtitles are added as a stream instead of burning them into the video. [23:36:16 CEST] <Hackerpcs> reading about AAC encoding https://trac.ffmpeg.org/wiki/Encode/AAC , it says about using a higher cutoff "keeping in mind that a higher limit may audibly reduce the overall quality." why is that? [23:42:49 CEST] <furq> because you're encoding more data at the same bitrate [23:46:26 CEST] <Hackerpcs> what could possibly be a good combination of the highest available cutoff and bitrate for fdk acc to achieve transparency? [23:46:37 CEST] <Hackerpcs> highest is 20k [23:46:41 CEST] <furq> if you just want no cutoff then use -vbr 5 [23:48:00 CEST] <Hackerpcs> that works, it goes over 20k too [23:50:07 CEST] <Hackerpcs> thanks! [00:00:00 CEST] --- Wed Apr 10 2019

1 0

ffmpeg-devel.log.20190408
by burek 09 Apr '19

09 Apr '19

[01:40:49 CEST] <lrusak_> anyone know why this happens?: [01:40:50 CEST] <lrusak_> Assertion *(const AVClass **)avctx->priv_data == codec->priv_class failed at libavcodec/utils.c:998 [01:41:58 CEST] <lrusak_> ah, similar fix here, http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=b942845beedc369cf0684e… [01:42:42 CEST] <nevcairiel> yeah if you use options, the struct needs to include AVClass [03:55:38 CEST] <x420> where did trac go [03:55:50 CEST] <x420> seems down for me [03:59:47 CEST] <jamrial> works here [04:00:44 CEST] <jamrial> although kinda slow [04:04:07 CEST] <x420> can ping it but times out on 80 and 443 for me idk [04:04:10 CEST] <x420> oh well [16:26:25 CEST] <cone-476> ffmpeg 03Jeremy Dorfman via ffmpeg-devel 07master:bb5efd1727ee: avformat/av1: Initialize padding in ff_isom_write_av1c [16:29:21 CEST] <durandal_1707> jamrial: now you, previously michaelni, same error [16:31:16 CEST] <jamrial> ugh [16:32:08 CEST] <jamrial> yeah, my fault, i don't run any script to catch these. i just didn't pay enough attention [16:32:43 CEST] <jamrial> it's annoying how google emails get mangled like this [19:02:12 CEST] <j-b> Can we not do that, again? [19:04:02 CEST] <JEEB> gitlab when (ŽûÉû@) (only half-jokingly) [19:13:38 CEST] <thardin> gitmab is ok [20:34:49 CEST] <durandal_1707> gitmob [20:43:58 CEST] <durandal_1707> who gonna RE blackmagic and prores RAW? [20:46:25 CEST] <gnafu> Is that like a flash mob? [20:46:42 CEST] <gnafu> A bunch of people committing several tiny typo fixes all at once. [20:46:50 CEST] <gnafu> Or code formatting changes. [21:19:55 CEST] <philipl> BtbN: so this ticket #7674. The guy who reopened it pinged me on devtalk too. It seems on the surface that cleaning up after yourself and avoiding a resource leak leads to a big performance penalty. [21:20:13 CEST] <philipl> I think we should throw it to an nvidia person to deal with. [21:21:28 CEST] <BtbN> Yeah, removing the deregistering is incorrect and only works because the hwframes_ctx keeps reusing the same frames over and over again [21:21:40 CEST] <BtbN> Which cannot be safely assumed in nvenc [21:22:16 CEST] <BtbN> His usecase is such an edge case that I have a hard time caring. Only breaks when using at least 50 encode sessions... [21:49:53 CEST] <nevcairiel> I imagine there is a certain overhead of resource management, and the special case of re-using the same stuff all the time avoids that [21:50:03 CEST] <nevcairiel> why it suddenly kills performance is a bit odd, but who knows [21:59:05 CEST] <BtbN> re-registering the same frame over and over again certainly does not feel right [21:59:23 CEST] <BtbN> So that deregister got to be there. If it causes a serious performance impact, that's on the driver. [22:00:20 CEST] <philipl> Could we, in theory, have some sort of hook that get registered with the hwframes_ctx so that we unregister when the frame gets deallocated? [22:01:06 CEST] <philipl> Of course, better if nvidia fixes driver, but register/unregister is slow for many of their resource types. [22:01:09 CEST] <philipl> Seems a tradition. [22:02:19 CEST] <BtbN> In theory, yes. In practice, that would require some hackery to keep nvenc alive until the frame is freed [22:02:29 CEST] <BtbN> which sounds dangerous and deadlocky to me [22:03:11 CEST] <BtbN> Would need to work in a very similar fashion as it does in nvdec, except that nvenc does not produce the frames and thus can't set a custom deallocator [22:40:48 CEST] <durandal_1707> oh no! black belt training in RE sold out: https://nullcon.net/website/goa-2019/training/black-belt-in-reverse-enginee… [22:42:00 CEST] <nevcairiel> it also happened a month ago a lready [22:43:06 CEST] <BtbN> Talking about RE, i'm currently trying to reverse engineer some "encryption" algorithm arcade cabs use. I have the decompiled code Ghidra generated for the decrypt function, but holly hell they put some effort into making this obtuse. [22:44:32 CEST] <nevcairiel> in my experience decompiled code hardly looks straight forward from the get go =p [22:44:45 CEST] <BtbN> It does a surprisingly good job [22:45:02 CEST] <BtbN> Since it uses no external functions and just shuffles around on a block of memory [22:45:19 CEST] <durandal_1707> just reproduce decompiled function, you can even compile it with minor changes if it is not referencing extra stuff [22:45:52 CEST] <BtbN> It's 6 layers deep of memory shuffling functions though [22:46:23 CEST] <BtbN> I guess I could just straight up copy the decompiled C code, and it'd work. [22:46:46 CEST] <durandal_1707> well, it may not work always,... [22:47:54 CEST] <JEEB> BtbN: they just open sourced the decompiler C++ module I think [22:47:56 CEST] <JEEB> @ ghidra [22:48:18 CEST] <BtbN> nice, but I doubt that'd help me. At least immediately. [22:48:26 CEST] <BtbN> In the long run it'll probably greatly improve its quality. [22:48:43 CEST] <durandal_1707> you can also use retdec [22:48:45 CEST] <BtbN> I'm still a bit confused about their intention with releasing Ghidra, but I take it [22:49:11 CEST] <JEEB> BtbN: it's a PR thing mostly [22:49:16 CEST] <JEEB> but yes [22:49:38 CEST] <JEEB> it doesn't seem to be a generally OK thing [22:49:48 CEST] <JEEB> so yes, taking it :) [22:50:30 CEST] <BtbN> Maybe someone higher up at the NSA got seriously upset about Hexrays [22:50:46 CEST] <BtbN> Cause they are right now actively harming their business quite a bit [22:51:12 CEST] <JEEB> yup [22:51:50 CEST] <JEEB> granted, this seems to fit their defensive role. by releasing this they bring good reverse engineering tools into the hands of many whom the NSA is supposed to defend [22:52:24 CEST] <JEEB> (and yes, IDA Pro / Hex-rays loses some market share or at least doesn't get utilized in the manner it has been so far as much) [22:52:43 CEST] <BtbN> They probably primarily will get pirated a lot less [22:52:48 CEST] <JEEB> yea [22:52:53 CEST] <durandal_1707> lol, it loses nothing [00:00:00 CEST] --- Tue Apr 9 2019

1 0

ffmpeg.log.20190408
by burek 09 Apr '19

09 Apr '19

[00:01:16 CEST] <JEEB> coolhp48: it uses swresample, but it might be utilizing the non-AVFrame API [00:01:45 CEST] <JEEB> just make sure you check the headers for AVFrame utilizing functions [00:01:55 CEST] <coolhp48> Ok. I'll dig into the AVFrame API. Thanks again. [02:17:13 CEST] <KombuchaKip> How robust are FLAC files to data corruption? I'm doing some testing. I flipped a bit half way in the file and ffmpeg doesn't detect any bad frames. If I corrupt more data, eventually it emits a warning about bad frames. Doesn't FLAC headers contain a checksum? [02:19:48 CEST] <KombuchaKip> If I pass it through flac(1) via -wst it confirms data corruption. [02:23:35 CEST] <TheAMM> https://xiph.org/flac/features.html They do [02:23:40 CEST] <TheAMM> and https://github.com/FFmpeg/FFmpeg/blob/a0ac49e38ee1d1011c394d7be67d0f08b2281… [02:24:11 CEST] <TheAMM> but also https://github.com/FFmpeg/FFmpeg/blob/a0ac49e38ee1d1011c394d7be67d0f08b2281… [02:24:45 CEST] <TheAMM> ' [02:32:15 CEST] <KombuchaKip> TheAMM: Ok, so basically I need to specify AV_EF_CRCCHECK or AV_EF_COMPLIANT to something. [02:32:28 CEST] Action: KombuchaKip tries to find where. [03:21:55 CEST] <KombuchaKip> TheAMM: I've tried setting m_DecoderContext->err_recognition = AV_EF_EXPLODE & AV_EF_CRCCHECK after opening the codec, but before decoding any data. It still doesn't seem to detect the corrupt bit in the FLAC file. [04:58:35 CEST] <lindylex> How do I fix these errors when compiling ffmpeg with gltransition https://pastebin.com/9WLAm901 [07:19:29 CEST] <rjp421> ffmpeg is shown on screen during the movie Glass when Samuel L Jackson is hacking a computer [07:41:21 CEST] <circuitbone> cracking the movie to complete the mission. [07:42:53 CEST] <circuitbone> rjp421: Had a giggle at mr robot screens ? [07:42:54 CEST] <circuitbone> https://www.youtube.com/watch?v=SZQz9tkEHIg [11:32:39 CEST] <dablitz> good morning channel. [11:33:48 CEST] <dablitz> start : ---> ffmpeg -f alsa -i hw:1,0 -acodec libopus -ar 8000 -sdp_file sdp -f rtp rtp://192.168.100.21:52000 [11:34:38 CEST] <dablitz> and when i play : ---> ffplay -nodisp rtp://192.168.100.20:52000 [11:35:41 CEST] <dablitz> it should allow the audio to stream from one computer to the next. I do get cli showing stings are happening on the sending side...but nothing on the recieving side [11:44:15 CEST] <dablitz> ffplay just sits : nan : 0.000 fd= 0 aq= 0KB vq= 0KB f=0/0 [17:42:10 CEST] <pkeroulas_> Hello, I'd like to transcode rtp raw streams to mpegts (h264 + acc + cc53). Audio and video are fine. Closed caption (EIA 608) can be decoded to output file, as scc or text but it doesn't appear in the output stream. https://pastebin.com/UvCU08uS [17:43:11 CEST] <pkeroulas_> any idea someone, please? [17:43:17 CEST] <DHE> that uses a distinct subtitle stream for the closed captions? [17:46:47 CEST] <pkeroulas_> DHE, ideally yes, but it could also be inserted in SEI metadata of h264, but I know how to verify that. Vlc doesn't detect any cc/subtitles [17:47:46 CEST] <DHE> if the subtitles are present as SEI data in the input, most h264 encoders have an option -a53cc to just copy them as SEI data to the destination [17:49:03 CEST] <pkeroulas_> The input is not h264. It 3 "raw" rtp streams. [17:50:59 CEST] <DHE> oops, missed the pastebin link [17:53:19 CEST] <pkeroulas_> by the way, how to check if SEI data contains subtitles? [17:54:21 CEST] <DHE> Stream #0:0: Video: bitpacked (UYVY / 0x59565955), yuv422p10le(top first), 1920x1080, 90k tbr, 90k tbn, 90k tbc # this line would indicate h264, and there would be a "Closed Captions" clause listed [18:03:16 CEST] <pkeroulas_> DEH, not sure I understand. What the input video decoder, bitpacked, which is not aware of subtitles, has to do with h264 SEI? [18:06:32 CEST] <pkeroulas_> But my real question is: why does ffmpeg shows a distinct output stream ("Stream #0:1: Subtitle: text") but mediainfo and ffplay don't recognize that track? [18:10:58 CEST] <JEEB> pkeroulas_: if your input has the captions as a separate stream ffmpeg.c will show them as such. if they are in a video track the command line applications have limited support because they're not dynamic [18:12:14 CEST] <JEEB> (any ffmpeg api using application can utilize those packets though as they're properly presented as side data within the framework [18:16:21 CEST] <aboxer__> does FFMpeg process AFD data in mpeg user data ? [18:16:30 CEST] <aboxer__> parse it [18:23:00 CEST] <pkeroulas_> JEEB, understood. Could you please take a look at this ? https://pastebin.com/UvCU08uS Everything looks good in ffmpeg, but ffplay and mediainfo fail at detecting the subtitle track. [18:33:18 CEST] <DHE> the ffmpeg cli does very little with side data, which is what SEI-based closed captions are carried by [20:26:40 CEST] <egrouse> Hey all. I am using a complex filter map to concatenate x amount of videos together and stream to rtmp. the first video plays fine - 30fps, 1x speed; however later files seem to get exponentially faster almost. The 2nd one is currently on 35fps at 1.17fps and keeps getting faster [20:27:51 CEST] <egrouse> which eventually results after a few hours in huge video skips and dropping of 100s of frames at a time i guess as its trying to catch up with itself [20:28:01 CEST] <egrouse> in fact, it seems to be related to VBV underflow messaging - when i get that message the speed/fps seems to go up [20:28:49 CEST] <egrouse> bit of a vague question i'm sure but any suggestions or ideas how i could possibly counteract this!? [20:33:28 CEST] <egrouse> https://pastebin.com/T3rFW9LQ is the current command [20:48:40 CEST] <DHE> you have two [scaled] labels.. so there's that [20:49:29 CEST] <egrouse> so there is [20:49:46 CEST] <DHE> I don't think that's the cause of the problem, but it's the first error I found [22:40:21 CEST] <pkeroulas_> I have a situation where closed caption can be written to a srt file or in a mp4 container. But to insert this cc in a distinct mpeg ts stream (not embedded in video)? [22:41:54 CEST] <another> not sure ts supports subtitles [22:42:05 CEST] <JEEB> it does [22:42:06 CEST] <pkeroulas_> I tryed different codecs: srt, text, dvb, ass, no success. Mediainfo seems to detect an empty track [22:42:36 CEST] <JEEB> pkeroulas_: not sure if you can put closed captions into a separate stream in mpeg-ts [22:42:43 CEST] <JEEB> usually dvb teletext is what's being utilized [22:42:51 CEST] <JEEB> or dvb subtitles (which are images) [22:43:19 CEST] <pkeroulas_> and text-to-bitmaps is complicated, right? [22:43:44 CEST] <JEEB> I wouldn't say complicated, but not sure how easily you can do it with the command line app [22:43:45 CEST] <another> nvm, it does [22:44:15 CEST] <JEEB> I don't think we have a libzvbi encoder module (if it supports *encoding* dvb teletext) [22:44:21 CEST] <JEEB> but in theory that way you could stick text into mpeg-ts :P [22:44:29 CEST] <JEEB> in a way that receivers like [22:45:00 CEST] <JEEB> but since your input is US style closed captions more often you stick those closed caption packets to video tracks [22:45:10 CEST] <JEEB> not sure how easily or if at all the command line app supports that [22:45:40 CEST] <JEEB> which is going to become a theme I think. since the API gives you possibilities to do a lot of stuff, but you can guess how many things are properly implemented in ffmpeg.c and friends because it has its limitations :P [22:49:30 CEST] <pkeroulas_> "./configure --help [...] --enable-libzvbi enable teletext support via libzvbi [no]" [22:49:58 CEST] <JEEB> yea but I think that was decoder only [22:50:14 CEST] <JEEB> yes [22:50:15 CEST] <JEEB> libavcodec/libzvbi-teletextdec.c [22:50:20 CEST] <JEEB> > teletextDEC [22:50:52 CEST] <JEEB> you would have to add a module yourself and propose it to be added to FFmpeg if you want to create teletext subtitles :) [22:52:43 CEST] <pkeroulas_> interesting [22:54:06 CEST] <pkeroulas_> what about inserting the CC in video frames? It doesn't work either in my case. -a53cc doesn't seem to help. [22:55:18 CEST] <JEEB> pkeroulas_: you can do that with the API just fine. the command line tools work with this when the input is in the incoming video packets (because the tools don't have to do anything in that case) [22:55:30 CEST] <JEEB> also they get passed by default in most encoders by now [22:56:03 CEST] <JEEB> so in case of the input having the captions in a separate track, you would have to make the command line application take the packets from that stream and stick them together with decoded video frames being pushed into the encoder [22:56:13 CEST] <JEEB> which it currently does not do [23:02:53 CEST] <pkeroulas_> yes, JEEB I have been trying to stick the cc track to the video track, using the command line. Developing a new app on top of API sounds more complicated to me than adding libzvbi :) [23:03:09 CEST] <pkeroulas_> thanks for your help [23:43:51 CEST] <faLUCE> Hello. Which could be the best way to force an h264 keyframe with lavc? InputLibAVFrame->pict_type = AV_PICTURE_TYPE_I before send_frame() ? [23:44:53 CEST] <DHE> basically yes [23:59:05 CEST] <faLUCE> thanks DHE [00:00:00 CEST] --- Tue Apr 9 2019

1 0

ffmpeg-devel.log.20190407
by burek 08 Apr '19

08 Apr '19

[02:01:17 CEST] <cone-429> ffmpeg 03Carl Eugen Hoyos 07master:d234ed76330a: lavf/Makefile: Fix kux demuxer standalone compilation. [04:27:35 CEST] <cone-429> ffmpeg 03Jun Zhao 07master:7c1875143db4: doc/examples/metadata: fix the example can't dump FLV metadata [08:20:57 CEST] <cone-973> ffmpeg 03Lauri Kasanen 07master:50e672bc5437: swscale/ppc: VSX-optimize non-full-chroma yuv2rgb_1 [08:20:58 CEST] <cone-973> ffmpeg 03Lauri Kasanen 07master:3256e949be7b: swscale/ppc: VSX-optimize yuv2rgb_full_2 [08:20:59 CEST] <cone-973> ffmpeg 03Lauri Kasanen 07master:8607e29fa3d4: swscale/ppc: VSX-optimize yuv2rgb_full_X [11:22:31 CEST] <superware> AVPacket holds pts/dts, where can I find the corresponding time_base relating to the entire packet? [11:23:53 CEST] <nevcairiel> depends where you got the packet from [11:24:48 CEST] <nevcairiel> when demuxing, its time_base in the corresponding AVStream [11:25:08 CEST] <nevcairiel> when encoding its the time_base of the encoding context [11:25:20 CEST] <nevcairiel> thats probably all major sources of AVPackets [11:26:28 CEST] <superware> I'm demuxing using av_read_frame, there are multiple streams inside an AVPacket [11:26:43 CEST] <nevcairiel> no, every packet always corresponds to one stream [11:26:53 CEST] <superware> hmm [11:27:15 CEST] <nevcairiel> identified by stream_index [13:04:53 CEST] <superware> nevcairiel: is there a way to have ffmpeg return the next frame (av_read_frame) from a file at playback speed? [13:05:16 CEST] <nevcairiel> no [13:11:47 CEST] <superware> I'll really appreciate any help: I have an app which has a MediaInput class that has a thread spitting out packets, and a MediaPlayer class which has a thread filling a queue of frames (avcodec_receive_frame) and another thread which dequeue and handles synchronization and rendering, this works well for network streams, but not for files since MediaInput has no synchronization. is this a valid use case? [13:12:34 CEST] <nevcairiel> typically you would synchronize on rendering, ensuring that audio a nd video are rendered at the appropriate times, and with limited queue space it would limit everything else automatically [13:13:15 CEST] <superware> so you basically say the MediaPlayer queue is redundant [13:13:56 CEST] <superware> ? [14:02:34 CEST] <superware> nevcairiel: thanks [16:06:59 CEST] <cone-083> ffmpeg 03Nikolas Bowe via ffmpeg-devel 07master:4c8e3725d9ff: avfilter/af_asetnsamples: fix sample queuing. [16:30:20 CEST] <j-b> Oh, come on [16:30:25 CEST] <j-b> "Nikolas Bowe via ffmpeg-devel [16:30:30 CEST] <j-b> How is that a name? [16:30:42 CEST] <nevcairiel> thats just email being terrible [16:30:57 CEST] <nevcairiel> and the commiter being lazy or forgetting to fix it [16:30:58 CEST] <j-b> yet, it stays forever in the git history [17:07:43 CEST] <durandal_1707> force push it [17:07:50 CEST] <JEEB> we already have a few of those :P [17:07:59 CEST] <JEEB> just means that whomever is pushing should double-check author/e-mail [17:30:51 CEST] <michaelni> or automate it with a script that works better than mine, which failed to catch this one as it was just looking for a name which this one had [17:35:01 CEST] <JEEB> michaelni: yea. I guess checking for "via ffmpeg-devel" or something would have caught this [17:35:27 CEST] <JEEB> also checking for the e-mail [17:35:38 CEST] <JEEB> XXX via ffmpeg-devel <ffmpeg-devel(a)ffmpeg.org> [17:35:40 CEST] <JEEB> seems to be the pattern [17:35:50 CEST] <jamrial> looking for @ffmpeg.org email as author seems easier [17:36:20 CEST] <JEEB> yea [17:53:50 CEST] <BtbN> How does it determine the commiter Name/Email? Just the user.name and user.email of the one who ran git commit? [17:53:54 CEST] <BtbN> Or push, rather? [17:55:16 CEST] <JEEB> git commit, yea [17:55:56 CEST] <JEEB> git push just pushes those info nodes onto a remote server [18:12:25 CEST] <durandal_1707> vel0city: do not forget to finalize proposal, without it you can not work at all... [18:32:27 CEST] <durandal_1707> michaelni: now when i have both codes, symbols and bit-lengths how can i dechipher this algo? [18:34:43 CEST] <michaelni> look for patterns [19:15:17 CEST] <durandal_1707> michaelni: what patterns? anything specific? [19:22:32 CEST] <durandal_1707> what a waste, libreoffice dec2bin is limited to -512-512 [21:11:30 CEST] <durandal_1707> michaelni: ugh asetnsamples change is wrong [21:12:00 CEST] <durandal_1707> warning is issued here [21:16:52 CEST] <BradleyS> $(.+) via (.+)^ [21:17:23 CEST] <cone-851> ffmpeg 03Paul B Mahol 07master:3a2adeedaff3: avformat/riffdec: pass correct pointer to av_log [21:17:23 CEST] <cone-851> ffmpeg 03Paul B Mahol 07master:ecdaa4b4fa52: avfilter/af_asetnsamples: use correct function [21:17:40 CEST] <BradleyS> ^$ obviously [22:05:52 CEST] <durandal_1707> apparently mpc-be guys ripped my dhav code [22:08:52 CEST] <jamrial> for what purpose? [22:10:13 CEST] <durandal_1707> for demuxing in dvrsplitter [00:00:00 CEST] --- Mon Apr 8 2019

1 0

ffmpeg.log.20190407
by burek 08 Apr '19

08 Apr '19

[11:13:51 CEST] <superware> AVPacket holds pts/dts, where can I find the corresponding time_base relating to the entire packet? [13:56:22 CEST] <DHE> in the avformatcontext->streams[pkt- [13:57:09 CEST] <DHE> in avformatcontext->streams[pkt->stream_index]->time_base iirc [18:36:30 CEST] <jokoon> hello [18:38:20 CEST] <jokoon> so scale="320:-1" requires -vf before it [18:39:37 CEST] <another> was that a question? [18:46:40 CEST] <jokoon> yes [18:46:47 CEST] <jokoon> I guess it's a yes but nevermind [18:46:48 CEST] <jokoon> Invalid pixel aspect ratio 5121/5120, limit is 255/255 reducing [18:47:31 CEST] <jokoon> I realized what I wanted was scale="-1:320" [18:47:58 CEST] <jokoon> converting from 264 to mp4 [18:48:09 CEST] <jokoon> I know it's wrong but Im doing it anyway [18:48:56 CEST] <JEEB> also generally I would recommend -2 instead of -1 [18:49:19 CEST] <JEEB> since if you're converting to 4:2:0 etc you need the resulting value to be divisible by two [18:49:47 CEST] <JEEB> since in 4:2:0 the chroma layers are stored in a single value for a 2x2 block [18:49:51 CEST] <jokoon> mh ok thanks for the heads up [18:50:34 CEST] <JEEB> and yes, that "scale=blah" thing is a filter chain [18:50:52 CEST] <JEEB> so you either put it into a vf (video filter chain), or if you want more fancy things there's also the complex filter chain stuff [18:51:00 CEST] <jokoon> any doc for that precise -2 ? [18:51:05 CEST] <jokoon> ok [18:51:29 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#scale-1 [18:51:47 CEST] <jokoon> thanks [18:51:47 CEST] <JEEB> > If one and only one of the values is -n with n >= 1, the scale filter will use a value that maintains the aspect ratio of the input image, calculated from the other specified dimension. After that it will, however, make sure that the calculated dimension is divisible by n and adjust the value if necessary. [18:52:42 CEST] <jokoon> mmmh [18:52:52 CEST] <jokoon> what if the input is not divisible by 2? [18:53:12 CEST] <jokoon> should I use a n that is a multiple of the input? [18:53:18 CEST] <JEEB> the input doesn't really matter [18:53:26 CEST] <JEEB> this is just a calculation based on the input values [18:53:43 CEST] <jokoon> I don't understand, why -2 instead of -1 then? [18:53:55 CEST] <JEEB> that controls the output divisibility [18:54:24 CEST] <jokoon> but anything is divisible by 1 [18:54:43 CEST] <JEEB> ok, so most video out there and most likely what you are pushing out is 4:2:0 [18:54:58 CEST] <JEEB> 4:2:0 is a way in YCbCr where the "black and white" (luma) has full resolution [18:55:09 CEST] <JEEB> but then the color information is stored for a single value for a 2x2 block [18:55:29 CEST] <JEEB> you cannot store images with the height/width not being divisible by two in 4:2:0 [18:55:43 CEST] <jokoon> ok [18:55:46 CEST] <JEEB> if you set -1 you are not making sure your calculation output is divisible by two [18:55:56 CEST] <JEEB> -2 is meant to help with that part [18:56:16 CEST] <JEEB> because after the scaling your exact output value might be not divisible by two [18:56:17 CEST] <JEEB> :P [18:57:38 CEST] <jokoon> I thought that rule only applied for 264, not for mpeg [18:57:52 CEST] <JEEB> it applies to anything coding in 4:2:0 [18:57:54 CEST] <JEEB> it's not the format [18:58:01 CEST] <JEEB> like the video compression format [18:58:13 CEST] <JEEB> H.264 for example supports everything from 4:0:0 to 4:4:4 [18:58:27 CEST] <JEEB> the first being "no color information at all" to "color information is full resolution" [18:58:47 CEST] <JEEB> the reason why everyone uses 4:2:0 for video is because that's what everything most often supports :P [18:59:13 CEST] <TheAMM> (where's my 4:1:1) [18:59:40 CEST] <TheAMM> Or wait, does H.264 handle that too? [19:02:02 CEST] <jokoon> scale="320:-2" will be a height of 320 right? [19:02:13 CEST] <jokoon> no a width [19:02:17 CEST] <DHE> width:height [19:02:30 CEST] <jokoon> yes [19:02:49 CEST] <DHE> 4:1:1 isn't listed as supported by libx264... 4:2:0 is the most common, being what hardware decoders are usually limited to and what broadcasts like TV and Youtube run [19:03:10 CEST] <jokoon> what's better about 4:1:1 or 4:4:4 ? [19:03:52 CEST] <DHE> 4:4:4 has full colour data for all pixels. any other (lower) number has adjacent pixels share at least some chroma data with each other [19:04:22 CEST] <jokoon> so higher color restitution [19:05:56 CEST] <jokoon> mmmmh so will I save space with 4:1:1? [19:06:12 CEST] <TheAMM> Please don't use 4:1:1 [19:06:16 CEST] <TheAMM> Forget my joke [19:06:17 CEST] <DHE> since x264 doesn't support it, yes since it will produce a 0 byte file [19:06:24 CEST] <DHE> :) [19:06:29 CEST] <jokoon> is there a way to save space when converting from 264 to mpeg4? [19:06:44 CEST] <DHE> wait, what? why are you going from mpeg4 part-10 to part-2 ? [19:06:57 CEST] <jokoon> Im converting to mpeg4 so I guess it doesn't matter? [19:07:13 CEST] <jokoon> a device cant read 264 [19:07:19 CEST] <jokoon> it's a old nokia phone [19:07:20 CEST] <DHE> what ffmpeg calls "mpeg4" is the video codec once known as divx back in like 2001 [19:07:31 CEST] <DHE> oh, my condolences. [19:11:59 CEST] <JEEB> DHE: mpeg-4 part 2, which was the "original" MPEG-4 video codec in that set of specs. nobody probably thought back then that we'd have multiple :) [19:12:14 CEST] <JEEB> you had pt1 for containers/system stuff [19:12:17 CEST] <JEEB> pt2 for video [19:12:22 CEST] <JEEB> pt3 for audio I think? [19:12:53 CEST] <DHE> JEEB: my company has an IPTV product. whenever I hear "MPEG4" I had to mentally substitute "H264" [19:13:18 CEST] <JEEB> yea, by now that makes sense :) [19:13:26 CEST] <JEEB> since mpeg-4 part 2 more or less simmerred off [19:13:50 CEST] <JEEB> or well, it's unfortunate but makes sense xD [19:13:54 CEST] <DHE> and I'm largely okay with it, but then these little incidents happen with [really] old hardware or users getting confused [19:49:13 CEST] <shibboleth> i've got a security camera which will only provide video over rtsp (h264) and only provide audio over http (pcm_ulaw). how can i run a background, respawning process to provide a muxed rtsp stream for a third party DVR? [20:12:47 CEST] <dablitz> getaddrinfo(fc6f, 19): Name or service not known [20:12:47 CEST] <dablitz> rtp://fc6f:19fc:d0ef:fdc0:f356:bf23:3bd4:854d:52000: Input/output error <--- can I get some help. using ---> ffmpeg -f alsa -i hw:1,0 -acodec pcm_mulaw -f rtp rtp://fc6f:19fc:d0ef:fdc0:f356:bf23:3bd4:854d:52000 [20:23:33 CEST] <another> dablitz: try putting the ipv6 addr in brackets [ ] [20:24:02 CEST] <dablitz> another thankyou I will try that [20:24:31 CEST] <dablitz> that worked thanks [20:46:57 CEST] <dablitz> ffmpeg -re -f alsa -i hw:1,0 -acodec pcm_mulaw -f rtp rtp://[fca4:b047:503e:3bfb:413c:5726:3a69:e82a]:52000 <--- this starts what it is suppose to start doing, but the other end ---> ffplay rtp://[fc6f:19fc:d0ef:fdc0:f356:bf23:3bd4:854d]:52000 produces this error ---> [rtp @ 0x7fe020000b80] Unable to receive RTP payload type 97 without an SDP file describing it [20:47:21 CEST] <dablitz> Input #0, rtp, from 'rtp://[fc6f:19fc:d0ef:fdc0:f356:bf23:3bd4:854d]:52000': [20:47:46 CEST] <dablitz> Duration: N/A, bitrate: N/A [20:48:10 CEST] <dablitz> Failed to open file 'rtp://[fc6f:19fc:d0ef:fdc0:f356:bf23:3bd4:854d]:52000' or configure filtergraph [21:05:37 CEST] <pranayvshah> Can someone please please help me with this issue - https://github.com/harfbuzz/harfbuzz/issues/1654 [21:07:23 CEST] <another> dablitz: look into rtsp [21:09:12 CEST] <dablitz> another, this is something I am very new at. all I want to do is stream simple audio via ffmpeg point to point. would happen to have a good document on rtsp? [21:10:10 CEST] <another> 'fraid not [21:10:44 CEST] <another> i'm not an expert on this either [21:10:44 CEST] <dablitz> ok i will continue to google [21:12:32 CEST] <pranayvshah> I tried with Handbrake GUI and the output (the hindi subtitles) were rendered correctly. Tried the same with HandbrakeCli, that worked too. Adding the subs as a stream works fine too when I view the video through VLC media player [21:30:54 CEST] <pranayvshah> Can someone please please help me with this issue - https://github.com/harfbuzz/harfbuzz/issues/1654 . I tried with Handbrake GUI and the output (the hindi subtitles) were rendered correctly. Tried the same with HandbrakeCli, that worked too. Adding the subs as a stream works fine too when I view the video through VLC media player [21:51:00 CEST] Last message repeated 1 time(s). [21:55:30 CEST] <pink_mist> please don't repeat yourself this much [21:55:40 CEST] <pink_mist> at least wait a couple of hours between asking [21:56:43 CEST] <pranayvshah> Sorry about it, I am new to IRC chat and I was not sure my message was even being broadcast [21:58:27 CEST] <Ariyasu> set utf-8 [21:59:10 CEST] <pranayvshah> My file is UTF-8 encoded and ffmpeg subtitles documentation says that is the default anyway. [22:00:10 CEST] <Ariyasu> -sub_charenc UTF-8 [22:00:16 CEST] <Ariyasu> ok [22:00:38 CEST] <Ariyasu> i remember mkvmerge never set it and always used system default which screwed up a ton of sub files rendering for years [22:01:13 CEST] <pink_mist> it wouldn't screw up like his screenshots show though. [22:02:32 CEST] <pranayvshah> Just tried with the charenc set to UTF-8, did not make a difference [22:03:02 CEST] <Ariyasu> so Glyph 0x74 not found in your font [22:03:13 CEST] <Ariyasu> i take it thats the character that gets messed up? [22:04:26 CEST] <pranayvshah> No, that's not the character which is getting messed up [22:08:47 CEST] <pink_mist> Ariyasu: it's just a little line on top of the characters that gets put in the wrong place (or at least that's what it looks like to me who can't tell front from back of any of those characters) [22:21:25 CEST] <pranayvshah> Hey sorry, is the difference clearer with this picture - https://res.cloudinary.com/qblm/image/upload/v1554668448/Annotation_2019-04… [23:19:27 CEST] <f3ndot> Curious: is there a timeline for the 4.2 release? where can such information be obtained? [23:23:36 CEST] <JEEB> I don't think there is [23:23:57 CEST] <JEEB> releases are cut every N months, at semi-random spots [23:43:34 CEST] <coolhp48> Hi JEEB. Thank you for your help yesterday. You did point me in the right direction. Those AAC frames I was trying to decode were indeed RAW AAC without the ADTS headers. I ended up just reconstructing an ADTS header and adding that to every frame I received before passing it to the AV_CODEC_ID_AAC decoder. [23:43:50 CEST] <coolhp48> It works like a charm. [23:46:07 CEST] <JEEB> nice [23:51:03 CEST] <coolhp48> Now I'm stuck with another issue and I have no idea of where to get started with this : In the framework I'm working off of, I'm given a uint8_t* pointer called "sampleBuffer". This is actually an array of pointers, one per channel. Each channel has a pointer to an uint8_t that is supposed to be where I should write the RAW PCM. But the AV_CODEC_ID_AAC decoder gives me float32s instead of uint8s and I have no [23:51:04 CEST] <coolhp48> idea of how to overcome that. [23:51:28 CEST] <coolhp48> This is very poorly explained... probably because I myself arent sure of what I'm dealing with here. [23:52:58 CEST] <coolhp48> Is it possible to convert 32bit float PCM to 8bit unsigned int PCM on the fly ? [23:53:20 CEST] <JEEB> yes [23:53:37 CEST] <JEEB> either via swresample with the AVFrame API, or through libavfilter audio filtering which utilizes swresample in the background [23:53:53 CEST] <JEEB> which in both cases means that you feed the resampler the AVFrame you get from decoder [23:54:03 CEST] <JEEB> and you get another AVFrame back [23:54:30 CEST] <coolhp48> Aha ! That sounds promising. I'm going to look into it right away. Thanks JEEB ! [23:54:48 CEST] <JEEB> :) [23:55:34 CEST] <coolhp48> Is examples/resampling_audio.c what I should be looking at as a roadmap ? [00:00:00 CEST] --- Mon Apr 8 2019

1 0

ffmpeg-devel.log.20190406
by burek 07 Apr '19

07 Apr '19

[15:23:31 CEST] <cone-059> ffmpeg 03Octavio Alvarez 07master:f4f40cbb578a: lavd/x11grab: fix vertical repositioning [15:55:47 CEST] <cone-059> ffmpeg 03Swaraj Hota 07master:208ae228fa12: lavf/flvdec: added support for KUX container [20:31:42 CEST] <durandal_1707> michaelni: i got working code, take a look: https://github.com/richardpl/FFmpeg/tree/agm [20:32:13 CEST] <durandal_1707> doesn't look like typical huffman coding to me, isn't it? [20:32:33 CEST] <JEEB> &34 [20:32:53 CEST] <durandal_1707> JEEB: did you played with bink2? [20:33:08 CEST] <JEEB> didn't have time yet, sorry :) [21:07:43 CEST] <durandal_1707> michaelni: more specifically, it appears it encodes cases for longer (2 bytes) symbols iiuc [21:19:30 CEST] <durandal_1707> or that is just 2 sequential symbols ... [21:20:30 CEST] <pridkett> why is FFMPEG listed in GSOC? are you people looking for more ffmpeg devs ? [21:21:23 CEST] <durandal_1707> why it shouldn't be listed? [21:22:21 CEST] <pridkett> i thought there are enough ffmpeg devs [21:22:33 CEST] <durandal_1707> lol [21:41:20 CEST] <durandal_1707> michaelni: extracting codes from table, and using only codes for 1 byte symbols, sucessfully decodes first frame! [21:41:56 CEST] <durandal_1707> now i just need to figure out how codes are generated, the code is unreadable currently [00:00:00 CEST] --- Sun Apr 7 2019

1 0

ffmpeg.log.20190406
by burek 07 Apr '19

07 Apr '19

[02:57:40 CEST] <CCFL_Man> ffmpeg0 in freebsd has ffserver0 [05:05:04 CEST] <tombert> Howdy, I'm trying to do an HLS stream using this following command: ffmpeg -y -i /dev/video0 -vcodec h264_omx -f hls -hls_time 30 -hls_segment_filename "fileSequence%Y%03d.ts" prog_index.m3u8 [05:05:27 CEST] <tombert> I want to put the year in the filename, but the file will have the literal %Y in the name [05:05:36 CEST] <tombert> how do I go about making the filename have a timestamp [05:07:09 CEST] <fella> $(date +%Y) [05:12:05 CEST] <tombert> What if I want the filenames to update automatically? [05:14:09 CEST] <tombert> if I do the $(date) thing, won't that only load the date initially [05:14:09 CEST] <tombert> ? [05:14:47 CEST] <furq> tombert: -strftime -hls_segment_filename fileSequence%Y%%03d.ts [05:15:45 CEST] <furq> oh i guess you need -hls_flags second_level_segment_index as well [05:16:29 CEST] <furq> https://www.ffmpeg.org/ffmpeg-formats.html#Options-5 [05:20:12 CEST] <texasmynsted> it seems I need remux a video h264 but the timestamps/timecodes are invalid or incomplete [05:25:30 CEST] <tombert> furq: that worked, thank you! [05:25:44 CEST] <tombert> my home security system is complete! [06:15:38 CEST] <lindylex> What is the last thing I should see when I build ffmpeg from source? I see this at the end "STRIP ffprobe" [06:23:24 CEST] <furq> if you don't see an error then congratulations, you won [06:24:32 CEST] <lindylex> I saw lots of these "fftools/ffprobe.c:2920:13: warning: codec is deprecated [-Wdeprecated-declarations]" [06:24:42 CEST] <ricekrispie> warnings aren't errors [06:24:45 CEST] <ricekrispie> you're fine [06:24:46 CEST] <furq> ^ [06:25:25 CEST] <lindylex> This is a line in the ./config [06:25:27 CEST] <lindylex> PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure \ [06:25:37 CEST] <ricekrispie> ok [06:25:44 CEST] <lindylex> I guess this installs to my home directory? [06:25:56 CEST] <furq> no [06:26:07 CEST] <lindylex> Where? [06:26:11 CEST] <furq> --prefix [06:26:19 CEST] <furq> but if you didn't run make install then it hasn't installed anywhere yet [06:26:38 CEST] <lindylex> Ok now I get it. I did not do that. [06:26:50 CEST] <ricekrispie> most open source projects just have the resulting binary in the same directory that you started the build in [06:26:52 CEST] <ricekrispie> try ./ffmpeg [06:27:03 CEST] <furq> it's in ffbuild/ now afaik [06:27:12 CEST] <ricekrispie> o [06:27:19 CEST] <ricekrispie> I haven't built ffmpeg in a long time [06:27:23 CEST] <ricekrispie> carry on [06:27:57 CEST] <lindylex> Ok this is awesome the binary is there and this is what I wanted. I do not want to make install it. [06:28:19 CEST] <furq> did you build with --enable-static [06:28:30 CEST] <lindylex> The binary is in the ./ffmpeg [06:29:17 CEST] <lindylex> This is what my full configure was https://pastebin.com/bFPCW7DL [06:29:42 CEST] <pridkett> what is the command to use AV1 video codec with ffmpeg? [06:29:45 CEST] <lindylex> furg : i did not. [06:30:00 CEST] <lindylex> Let me try adding this. [06:31:17 CEST] <lindylex> Sorry here it is https://pastebin.com/bFPCW7DL [06:31:38 CEST] <furq> if you don't want to install it then you'll want --enable-static [06:32:14 CEST] <lindylex> Like this https://pastebin.com/CGaruRKh [06:35:45 CEST] <lindylex> I am really trying to build ffmpeg-gl-transition and have encountered so many errors. [06:54:41 CEST] <pridkett> where can i get binary for ffmpeg 4.1.3 ? [06:56:31 CEST] <lindylex> pridett you can build it http://ffmpeg.org/download.html#build-linux [06:56:38 CEST] <lindylex> What OS is this for? [06:56:51 CEST] <pridkett> win64 [06:57:08 CEST] <lindylex> Ok I do not know how to do that for Windows. [06:58:32 CEST] <lindylex> pridkett : try thi https://ffmpeg.zeranoe.com/builds/ [06:58:46 CEST] <pridkett> i don't see 4.1.3 [12:34:59 CEST] <^Neo> I'm trying to use two BMD Quad 2's in a single machine with FFmpeg and the cards get enumerated with the same name... is this correct? [12:35:53 CEST] <^Neo> i.e. `DeckLink Quad (1)` through `DeckLink Quad (8)` and then `DeckLink Quad (1)` through `DeckLink Quad (8)` [12:36:21 CEST] <JEEB> I think we're just reading them how the system is providing them [12:36:30 CEST] <JEEB> is this dshow or which module? [12:36:50 CEST] <^Neo> uhhh on linux, so the decklink module [12:37:15 CEST] <^Neo> I was going to start digging into decklink_dec.cpp [12:37:34 CEST] <^Neo> I saw that going from 3.x to 4.x the enumeration code had changed [12:37:35 CEST] <JEEB> then quite likely how the decklink lib is exporting them [12:37:46 CEST] <^Neo> yeah, I figured... [13:38:46 CEST] <^Neo> @JEEB, so new to 4.x is the `-sources` option which gives some sort of colon delimited triplet that can be used to uniquely select ports on separate cards [13:38:57 CEST] <^Neo> so that works for me :+1: [13:39:28 CEST] <^Neo> I think 3.x FFmpeg only gave the name which would duplicate and had no notion, but I haven't tested that out [13:39:42 CEST] <JEEB> coolio [16:15:04 CEST] <gamelaster> Hi everyone, I have command which joining 1000 png frames with transparent bg into webm. Problem is that, after the rendering is complete, my webm contains default removed background (which isn't in frames), how is this possible and how to fix it? Thanks [16:27:59 CEST] <pink_mist> I don't believe webm supports alpha channel (a.k.a. transparency) [16:28:06 CEST] <pink_mist> I could be wrong, but that's my belief [16:28:25 CEST] <JEEB> vpX series of formats kind of support it, but it's a special snowflake [16:29:07 CEST] <JEEB> so the decoding might not work correctly with FFmpeg's internal decoder [16:29:18 CEST] <JEEB> you might want to check how something utilizing libvpx's decoding fares [16:29:28 CEST] <JEEB> also check that you are passing to the encoder something with the alpha channel intact [16:29:34 CEST] <JEEB> yuvaBLAH [16:29:39 CEST] <JEEB> instead of yuvBLAH [16:29:46 CEST] <JEEB> the a noting that it has alpha [16:52:32 CEST] <gamelaster> ffmpeg -framerate 12 -f image2 -i frame%04d.png -c:v libvpx-vp9 -vf format=rgba -pix_fmt yuva420p output.webm [16:53:13 CEST] <gamelaster> I'm using this, it works for few frames, but after that, it using "hidden" pixels, and I see my frames, but with old background, what is really crazy [17:04:29 CEST] <gamelaster> the images have "dirty transparency" problem, but I have no idea how to fix it [18:17:32 CEST] <nitrxgen> gamelaster, seems like something i wouldnt let ffmpeg try to fix, no way to batch edit the images first? [18:21:31 CEST] <nitrxgen> i think webm does support transparency, seems to be demonstrated here > http://www.sciencelifeny.com/transparency/transparency.html# [18:23:19 CEST] <nitrxgen> but actually it looks like that's done with video masking [18:58:30 CEST] <JEEB> nitrxgen: VPx formats since ancient times (at least VP6 series) have had transparency but it has kind of been a separate "video" within the video stream, so it was kind of outside the "normal" video decoding [18:58:45 CEST] <JEEB> which is why FFmpeg doesn't support it with at least some of the VPx formats [18:59:04 CEST] <JEEB> if you encode and decode with libvpx then you most likely can get it with VP8/9 [18:59:32 CEST] <JEEB> and I think the libvpx encoder/decoder wrappers might even support it if you pass YUVA into the encoder [19:00:41 CEST] <nitrxgen> that doc i linked to seemed to instruct you to double the height of the created video and use the bottom half for the mask, the rest seems to be done with js [19:01:47 CEST] <nitrxgen> as far as in depth video container/stream format stuff goes it's beyond me, not gonna lie lol [19:03:16 CEST] <JEEB> yea, that's just a hack :P [19:03:28 CEST] <nitrxgen> oh of course [19:03:32 CEST] <JEEB> the VPx formats actually have alpha layer [19:03:39 CEST] <JEEB> but it's not part of the primary image coding [19:03:43 CEST] <JEEB> which is why it's easy to "skip" it [19:03:51 CEST] <JEEB> (like I think FFmpeg does with VP8/9 decoding) [19:03:57 CEST] <JEEB> with the internal decoder, that is [19:04:03 CEST] <JEEB> I think the ye olde VP6 decoder has support for it [19:22:05 CEST] <pridkett> what do you people think about AV1 ? it's claiming it can produce same quality as half size of x264 [19:30:00 CEST] Last message repeated 1 time(s). [19:30:29 CEST] <durandal_1707> it is best [19:30:55 CEST] <pridkett> durandal_1707 then why aren't people using? [19:31:07 CEST] <pridkett> it [19:35:53 CEST] <durandal_1707> pridkett: are you troll? [19:36:01 CEST] <pridkett> durandal_1707 huh? [19:36:18 CEST] <pridkett> did i something that wasn't true? [19:36:23 CEST] <pridkett> did i say something that wasn't true? [19:36:31 CEST] <durandal_1707> you are trolling [19:36:41 CEST] <pridkett> because i asked about av1 ? [19:37:42 CEST] <durandal_1707> no [19:39:10 CEST] <pridkett> i don't understand then [19:50:54 CEST] <another> durandal_1707: imho pridkett is either trolling or ... i don't know [19:51:07 CEST] <pridkett> another because i asked about av1 ? [19:53:01 CEST] <another> no, because of the nature and structure of your questions [19:53:45 CEST] <pridkett> another, lol okay, what words should i have used to asked the exact same question then? [19:55:46 CEST] <another> *sigh* read my sentence again [19:57:09 CEST] <durandal_1707> av1 is going to be used soonTM [22:43:14 CEST] <wallace_mu> hi all, how do I scale image with filter_complex, i have this command but it's complaining scale2ref not found [22:43:17 CEST] <wallace_mu> ffmpeg -i inputfile [22:43:18 CEST] <wallace_mu> -i ../1/logo.png [22:43:18 CEST] <wallace_mu> -i ../1/xin.png [22:43:19 CEST] <wallace_mu> -i ../1/comment.png [22:43:21 CEST] <wallace_mu> -filter_complex [22:43:23 CEST] <wallace_mu> "[0][1]overlay=main_w/2-overlay_w/2-10:main_h-overlay_h-10:scale2ref=(W/H)*ih/8:ih/8[v1]; [22:43:25 CEST] <wallace_mu> [v1][2]overlay=main_w-overlay_w/2-10:main_h-overlay_h-10[v2]; [22:43:27 CEST] <wallace_mu> [v2][3]overlay=main_w/2-overlay_w-10:main_h-overlay_h-10 [22:49:25 CEST] <DHE> scale2ref is its own filter [22:49:33 CEST] <DHE> ffmpeg -h filter=scale2ref [22:50:21 CEST] <DHE> wallace_mu: see also https://ffmpeg.org/ffmpeg-filters.html [22:53:24 CEST] <wallace_mu> anyway i can combine these together? [22:53:26 CEST] <wallace_mu> DHE: [22:55:43 CEST] <wallace_mu> DHE: so looks like, for image it only has coreimage filter [22:56:11 CEST] <wallace_mu> still don't figure out how it apply to my command [00:00:00 CEST] --- Sun Apr 7 2019

1 0

ffmpeg-devel.log.20190405
by burek 06 Apr '19

06 Apr '19

[00:06:24 CEST] <BtbN> it's not a script that's meant to be executed though [00:08:43 CEST] <BtbN> oh wait, that one is [00:09:14 CEST] <BtbN> weird, how is that working at all? [00:11:36 CEST] <nevcairiel> iirc it'll just execute in the default shell if no bang is present [00:57:21 CEST] <BtbN> but yeah, should probably have one [11:57:10 CEST] <j-b> 'morning [11:58:05 CEST] <durandal_1707> good day [12:02:04 CEST] <j-b> durandal_1707: what's up, man? [12:03:23 CEST] <kurosu> he's in a huff, man [12:03:41 CEST] <kurosu> can't get his head around some vlc [12:06:17 CEST] <durandal_1707> yea, i'm going learn cryptography skills, man [13:14:46 CEST] <cone-185> ffmpeg 03Andreas Rheinhardt via ffmpeg-devel 07master:18a851aca766: avformat/matroskadec: Improve length check [13:14:46 CEST] <cone-185> ffmpeg 03Michael Niedermayer 07master:2169a3f262be: avcodec/agm: Fix integer overflow with w/h [15:19:53 CEST] <durandal_1707> michaelni: can one generate codes by simply doing something similar like deflate does for canonical codes, it simply shifts left by one position for higher bit lengths? [15:22:19 CEST] <durandal_1707> in one case, there is code of 7 bits, and 9 codes of length 6 (min len is 6, max len is 11) [15:23:41 CEST] <durandal_1707> some 7 length codes are 2a for 0 and a for 5 [15:24:15 CEST] <cone-185> ffmpeg 03Derek Buitenhuis 07master:772c73e61f5d: FATE: Add test for HEVC files that claim to have two first slices [15:24:43 CEST] <durandal_1707> because code of 5 is a and there is 9 codes of lenght 6, i think it uses somethinkg like breath first traversal [15:25:13 CEST] <durandal_1707> does my reasoning make sense? [15:34:53 CEST] <J_Darnley> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfa… [15:35:02 CEST] <J_Darnley> What utter lies from systemd. [15:35:10 CEST] <J_Darnley> "predictable" my arse [16:17:47 CEST] <kierank> J_Darnley: oh yes, fuck that so hard [16:18:10 CEST] <JEEB> something that sounds OK in paper, but lol. [16:18:15 CEST] <JEEB> (bases on the MAC address) [16:19:33 CEST] <J_Darnley> I doubt they ever tried the claim "Stable interface names even when hardware is added or removed" [16:20:15 CEST] <JEEB> well unless they derped it up it should be based on the hw mac address, which in all theory should be unique [16:20:33 CEST] <JEEB> but I've never looked into the details and things have so far JustWorked [16:20:34 CEST] <nevcairiel> i thought it was on the bus location [16:20:39 CEST] <JEEB> oh [16:20:44 CEST] <JEEB> could be [16:20:54 CEST] <JEEB> as I said, I just have a vague idea of that thing [16:21:22 CEST] <nevcairiel> its rather irritating if you say "predictable", but then design it on factors that you don't really know [16:21:30 CEST] <nevcairiel> sure its predicatble, by the software, and thats it [16:21:33 CEST] <JEEB> yes [16:26:49 CEST] <jkqxz> The bus location sounds like a good idea, but unfortunately with PCIe the bus can get renumbered on pretty much any change. [16:27:08 CEST] <jkqxz> Start with enp3s0, change something unrelated (not necessarily physical, could be BIOS setting), now it's enp4s0 and systemd refuses to let your system start because it can't bring up the network on enp3s0 and you need to init=/bin/sh to recover. [16:52:16 CEST] <durandal_1707> why I do not get any comments? [17:08:59 CEST] <durandal_1707> you are not smart enough to reply? [17:09:01 CEST] <jamrial> durandal_1707: my guess is that no one that knows the answer read it [17:44:03 CEST] <JEEB> why do people come up with new extensions for mp4 [17:44:05 CEST] <JEEB> cmfv, cmfa, cmft [17:44:05 CEST] <JEEB> for "CMAF" mp4 [17:44:53 CEST] <gnafu> Big fans of country music? [17:45:10 CEST] <JEEB> :D [18:36:52 CEST] <michaelni> durandal_1707, building or updating a huffman code/tree can be done in _many_ ways, i cannot guess which one your codec (which i do not even know which codec that is) is using [18:45:16 CEST] <durandal_1707> michaelni: tell some ways of building/updating tree you have in mind? [18:45:39 CEST] <durandal_1707> not counting already known stuff available in lavc [18:52:06 CEST] <michaelni> one can have a static tree change the order of the codes or remove and then insert a entry in the tree, something similar to how splay trees work maybe, one could keep track of statistics and when they chnage beyond a threshold recalculate the tree by any method. Knowing nothing about the codec its unlikely i will guess better than you. [18:54:58 CEST] <durandal_1707> michaelni: code lengths are new in every new frame, i assume that from this one can generate single binary tree that just have codes different in each branch, or there can be more than one huffman tree for same set of bit lengths? [18:56:07 CEST] <michaelni> for one set of length you can make MANY valid codes [18:56:17 CEST] <durandal_1707> yes i know that [18:57:09 CEST] <durandal_1707> in each branch you can flip bit you will give to left or right child [18:58:08 CEST] <durandal_1707> codec is agm, (missing features/code) [19:00:20 CEST] <michaelni> there are more valid codes than just from fliping bits on nodes, you can change the structure too and end with the same lengths in many cases [19:01:16 CEST] <michaelni> consider 16 codes of length 4 bits there are more permutations of 16 elements to 16 4bit codes than what one would get from just fliping bits at nodes [19:03:55 CEST] <durandal_1707> what you mean by structure? the different look of tree? [19:06:51 CEST] <michaelni> For example A and B could be leafs on a node and C and D could be leafs on another node. 3 bits to flip here but a totally different valid tree with identical lengths could have A and C leafs on a node and B and D leaves on a node which then connect together again with 3 bits on nodes to flip [19:09:44 CEST] <durandal_1707> could i derive same algo if i gather all codes? [19:11:17 CEST] <michaelni> maybe, probably, ... i assume its not intentionally obfuscated with hard crypto ... [22:24:51 CEST] <durandal_1707> michaelni: can you grasp what this function does: https://pastebin.com/MsVtRzMq -- i'm lost around 63rd line [22:26:34 CEST] <durandal_1707> basically code uses previously unset arrays [22:27:05 CEST] <durandal_1707> perhaps from look you or someone else can dechipher it [22:39:08 CEST] <michaelni> durandal_1707, access through aiStack7316 might actually go to aiStack6288 and aiStack7316 could be part of aiStack39056, that would make it a nicer size of 8192, but iam just guessing, that might eliminate one unset array [00:00:00 CEST] --- Sat Apr 6 2019

1 0

ffmpeg.log.20190405
by burek 06 Apr '19

06 Apr '19

[01:26:27 CEST] <PhantomSc> Does anyone have an example of how to use '-hls_segment_size'? [02:18:56 CEST] <unlord> how do I find out what version of libaom is in ffmpeg N-93083-g8522d219c [02:22:50 CEST] <unlord> I'm sure the answer is in a file somewhere in here: https://gitlab.com/UbikBSD/Codecs/FFMpeg/tree/8522d219c [02:36:00 CEST] <unlord> how about just printing the one linked in [02:36:13 CEST] <unlord> ffmpeg -encoders shows libaom-av1 [02:44:30 CEST] <kepstin> unlord: might not be an easy way to know without asking the person who built the ffmpeg binary you're using, unless it prints it in a log when encoding something (some encoders do, i haven't checked libaom) or maybe just looking for the version string in the compiled binary :/ [02:45:09 CEST] <kepstin> libaom is an external library, so there's no correlation between the ffmpeg version and the libaom version [02:51:58 CEST] <unlord> kepstin: I downloaded the static Windows build ffmpeg-20190205-8522d21-win64-static.zip and got it by running some video through it: [libaom-av1 @ 0000000000388640] 1.0.0-1297-g52ea88fd1 [02:53:05 CEST] <unlord> Gotta go back and verify these results https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=130284 after this announcement https://twitter.com/janozer/status/1113930266983190529 [02:53:32 CEST] <kepstin> unlord: that looks like a zeranoe build - here's the readme: https://ffmpeg.zeranoe.com/builds/readme/win64/static/ffmpeg-20190205-8522d… [02:54:13 CEST] <unlord> kepstin: libaom is not listed there [02:54:27 CEST] <kepstin> it is, it's just called 'aom' [02:54:37 CEST] <kepstin> shows the same git hash as you saw in the log [02:54:46 CEST] <unlord> wooops, you are right [02:55:09 CEST] <unlord> No idea if Jan Ozer was using this build, but without asking him who knows [02:55:46 CEST] <unlord> Note that the MSU results just came out and came to a very different conclusion on page 17: http://www.compression.ru/video/codec_comparison/hevc_2018/pdf/MSU_HEVC_AV1… [02:56:22 CEST] <unlord> but he wasn't really trying to do the same comparison, so it just sloppy reporting [03:02:09 CEST] <kepstin> every time i see these comparisons, i'm impressed by how close the quality of x264 is to the newer codecs while it's still /way/ faster to encode. [03:03:36 CEST] <furq> unlord: the aom version in the msu report is from january 30th [03:04:44 CEST] <furq> https://aomedia.googlesource.com/aom/+/625cded0550bb79efd10d98a9809a7ccd72a… [03:04:50 CEST] <kepstin> huh, the msu report didn't run av1 in a bitrate target mode, they used cq? [03:05:09 CEST] <kepstin> is 2-pass mode just not finished, or did they not feel like waiting? :) [03:05:12 CEST] <unlord> 625cded0 = Date: Tue Jan 29 19:50:20 2019 -0800 [03:05:22 CEST] <unlord> but yeah, that is just the authored date [03:05:27 CEST] <furq> yeah close enough [03:05:37 CEST] <furq> also idk how much i trust those msu reports if they're only using ssim [03:05:49 CEST] <furq> maybe they do some better analysis in the paid version [03:07:06 CEST] <unlord> furq: when you scroll that blurred PDF, my reader gets jank. Just sayin.... [03:07:17 CEST] <furq> i was going to ask what sz264/sz265 is but the link in the codecs list is just a mailto: [03:07:28 CEST] <furq> not really sure why they would include this but ok [03:09:04 CEST] <kepstin> presumably someone paid them to? [03:09:20 CEST] <kepstin> kinda amazing how closely sz264 tracks to x264 on some of the graphs... [03:09:29 CEST] <furq> yeah until you get to encoding time [03:12:15 CEST] <kepstin> so it's x264 being run in placebo mode, maybe with some asm optimizations removed? :) [03:25:56 CEST] <DHE> AV1 at 1 megabit can encode 1080p @ 25fps at very watchable image quality... [03:27:05 CEST] <DHE> (I did a test video a while ago... many months) [05:26:48 CEST] <Kuukunen> 4 [07:49:28 CEST] <lindylex> I am try to compile ffmpeg with gltransition and I keep getting the following error. https://pastebin.com/JW1Nsehf [13:34:27 CEST] <CCFL_Man> hello, what can one use in place of ffserver? the modern freebsd ports don't have it [13:35:07 CEST] <CCFL_Man> can mkvserver_mk2 provide the same stream that could be compatible with other players? [14:12:31 CEST] <DHE> people say good things about nginx-rtmp [14:13:05 CEST] <DHE> if HTTP-based streaming is acceptable, HLS or Dash with just any old static content HTTP server (apache, nginx plain, etc) can work at the cost of high delay live streaming [15:05:32 CEST] <faLUCE> hello all [15:10:45 CEST] <Freneticks> Hey Is it possible to have 2 input stream and change if input 1 is down to >> -c copy test.ts [15:19:30 CEST] <DHE> ffmpeg doesn't do that dynamically. some manual control can be done with the streamselect filter, but ffmpeg in general doesn't handle outages like that either [15:27:13 CEST] <saml_> you can set up proxy and do failover in the proxy [15:29:07 CEST] <Freneticks> what kind of proxy are you thinking about saml_ [15:29:14 CEST] <Freneticks> or maybe with dns [15:29:55 CEST] <saml_> ah is it generating livestream? [15:30:02 CEST] <Freneticks> yes [15:30:24 CEST] <saml_> and you have two source streams? what protocol those source streams use? HTTP? [15:30:34 CEST] <saml_> i'm not familiar with livestream [15:30:45 CEST] <Freneticks> http yes [15:31:17 CEST] <saml_> i think nginx and haproxy can do failover. If one http upstream is down, use another [15:32:11 CEST] <Freneticks> nice idea will check that [15:32:30 CEST] <saml_> but i don't know how well failover at loadbalancer would work with livestream. it could introduce glitches during failover [16:08:56 CEST] <pink_mist> Freneticks: I was recently informed of http://upipe.org/blog/ which I was told was what one should use rather than (or possibly in front of) ffmpeg for that kind of thing ... I've never used it myself though, so I can't really say whether or not it'll actually work [16:09:29 CEST] <JEEB> it's a framework more geared for live streaming, esp. in broadcast environments. it uses FFmpeg for decoding etc, of course [16:09:45 CEST] <JEEB> it does not have standard modules for web streaming etc, of course [16:09:55 CEST] <JEEB> but it's something I've been meaning to look into for a while [16:10:28 CEST] <pink_mist> yeah, JEEB was the one who informed me :P (though I think he was informing someone else at the time; I was just listening on the side :P) [16:12:14 CEST] <friendofafriend> I was feeding images and audio through a FIFO at ffmpeg to make slideshows. It works sort of OK, but all the sync problems you'd imagine. [16:14:47 CEST] <Freneticks> JEEB: It's a low level lib, why not go on gstreamer and built something good ? [16:15:16 CEST] <JEEB> that's another framework, and also already has logic like switching between alternative inputs? [16:15:22 CEST] <JEEB> also it seems to have alright inputs for stuff like MPEG-TS [16:15:28 CEST] <JEEB> and I like the concept of three timestamps [16:15:32 CEST] <JEEB> you have the original coded timestamp [16:15:40 CEST] <JEEB> you have the adjusted coded timestamp [16:15:44 CEST] <JEEB> and you have the receipt time [16:15:57 CEST] <JEEB> different applications can utilize these things for different things [16:18:39 CEST] <Freneticks> unfortunately i don't know anything about gstreamer, never took the time learn, but seems powerfull, and have the pipe concept too [16:18:55 CEST] <JEEB> all the frameworks have some sort of "pipeline" going [16:19:07 CEST] <JEEB> FFmpeg, upipe, gstreamer [16:20:51 CEST] <Freneticks> Also gstreamer have python bindings which can save me to learn C ^^ [16:45:13 CEST] <while> is rfc3533 the rfc implemented by ffmpeg when encoding OGG files? [16:55:42 CEST] <JEEB> no idea [16:56:15 CEST] <JEEB> it has an ogg muxer which seems apparently capable of writing ogg files readable by other applications [17:00:06 CEST] <kepstin> i'm pretty sure ffmpeg's ogg muxer was written before rfc3533 was published [17:00:46 CEST] <kepstin> but on the other hand, rfc3533 is supposed to be a document of the ogg container as it existed [17:05:23 CEST] <kepstin> ogg itself is of course pretty simple, the tricky stuff is mostly in the individual codec mappings. [17:07:19 CEST] <JEEB> yea [17:33:27 CEST] <Hello71> even though mans hates it [17:41:32 CEST] <dongs> dongs [17:44:19 CEST] <JEEB> perkele [18:43:24 CEST] <CCFL_Man> DHE: i just need low latency http streaming, same thing as what ffserver provided [18:58:35 CEST] <TAFB> How do I get microsecond in my filename with strftime? supposed to be %f I think but I always get "Could not get segment filename with strftime" if I use %f [19:16:56 CEST] <TAFB> "there is no way to get the current time with a higher precision than seconds in POSIX on which FFmpeg depends." [19:16:58 CEST] <TAFB> oh damn :( [19:24:40 CEST] <TAFB> if I can't use microsecongs, how about what frame I'm at in the -i file? [19:29:31 CEST] <TAFB> or how can I use a random number in the filename? [19:29:39 CEST] <TAFB> (windows) [20:21:42 CEST] <while> TAFB: you could probably find a proprietary solution (for creating random numbers) if nothing else works [20:38:00 CEST] <coolhp48> Hello all. I was wondering if this is the appropriate channel to ask a question about libavcodec/libavformat ? [20:38:19 CEST] <JEEB> it is [20:38:39 CEST] <JEEB> this channel for API usage of FFmpeg's libraries, and then the -devel channel is for actual development within the FFmpeg libraries [20:42:03 CEST] <coolhp48> Wonderful. I am in the middle of a puzzle I cant seem to figure out how to solve : I'm trying to decode raw AAC audio frames directly. The data I receive doesnt give me access to the packet itself. I just receive a variable with some context (like the number of channels and number of samples) [20:42:16 CEST] <coolhp48> And a buffer containing a raw AAC frame. [20:43:45 CEST] <coolhp48> In theory the right function to decode it would be either aac_decode_frame_int or aac_decode_frame but I cant access those if I just include libavcodec.h [20:44:07 CEST] <Mavrik> You shouldn't call those directly [20:44:17 CEST] <coolhp48> I've tried "reconstructing" an AVPacket from the buffer but to no avail... [20:44:34 CEST] <coolhp48> I'm at a bit of a loss as to what to try next. [20:44:43 CEST] <Mavrik> see https://ffmpeg.org/doxygen/trunk/decode__audio_8c_source.html [20:45:25 CEST] <coolhp48> Hi Mavrik. Thanks for the link. I've actually used that example as a roadmap for everything I've tried. [20:46:02 CEST] <coolhp48> But the issue with that example is that it expects the contents of the buffer to be a full ADTS/AAC Packet, not just a frame. [20:46:03 CEST] <JEEB> if you don't know if your data is properly separated per packet [20:46:09 CEST] <JEEB> oh [20:46:12 CEST] <JEEB> it's not ADTS? [20:46:24 CEST] <JEEB> or the thing that's in MP4? [20:46:43 CEST] <coolhp48> It should be. But what I'm receiving is really a raw audio frame. Not a full packet. [20:47:22 CEST] <coolhp48> I know its a proper frame because the headers are correct (ie : the first 3 bits indicate either TYPE_CPE, or TYPE_LFE or other) [20:47:35 CEST] <coolhp48> So its really a frame I'm trying to decode, not a packet. [20:50:18 CEST] <coolhp48> Here's an example of the buffer I'm being served : https://pastebin.com/iyqPU5E4 [20:57:11 CEST] <coolhp48> In theory, would this work ? Create an AVFrame, put that raw frame data I'm receiving in ->data[0], then create an AVPacket and somehow store that frame in that new packet, then follow the same logic as decode_audio.c does to finally get the decoded audio buffer ? [21:05:27 CEST] <JEEB> AVFrames are for raw audio/video/etc [21:05:32 CEST] <JEEB> AVPackets are something to feed into a decoder [21:05:43 CEST] <JEEB> or received from an encoder [21:05:49 CEST] <coolhp48> Ok. [21:06:13 CEST] <coolhp48> So assuming I have a byte array that contains an encoded AAC frame... how would I go about decoding it ? [21:06:18 CEST] <JEEB> so you would have to make an AVPacket out of your data in a format that lavc's decoder can take it in [21:06:55 CEST] <JEEB> coolhp48: you make a new AVPacket with the buffer allocated with FFmpeg helpers (to make sure you have needed alignment and additional buffer) [21:07:07 CEST] <JEEB> then make sure your frame is packaged in a way that the AAC decoder can eat [21:08:45 CEST] <coolhp48> Aye... with you so far :-) That's what I've been trying to do... Let me cleanup my code a bit and try again. [21:10:15 CEST] <JEEB> ok, so it expects when you init the decoder that you have the sample rate there [21:10:38 CEST] <coolhp48> Yup, I have that. [21:11:17 CEST] <JEEB> also channel count as far as I can see [21:11:41 CEST] <coolhp48> Just to give you a bit more context, I'm trying to decode an Apple Airplay 2 stream... while the contents of the frames are the same (proper AAC frames) the packets are in a completely different format. [21:11:43 CEST] <JEEB> I'm just looking at what the aac_decode_init() function seems to require to be set [21:11:45 CEST] <coolhp48> Thus my issue. [21:12:17 CEST] <coolhp48> (We're talking AAC stream here, not one using Apple's Lossless codec) [21:14:43 CEST] <JEEB> coolhp48: also if you have means to make it into ADTS or so, sticking the raw aac reader in front of the decoding might let you get the parsing for free, too [21:14:51 CEST] <JEEB> and thus make the whole shebang simpler [21:15:36 CEST] <coolhp48> Ah... that might be a good option... is there an example of how to call up the raw aac reader ? [21:16:20 CEST] <JEEB> there should be an example of how to utilize your own AVIO callback implementation with libavformat [21:16:38 CEST] <JEEB> then you just set the format to be "aac" in the AVFormatContext creation [21:17:01 CEST] <JEEB> yea, doc/examples/avio_reading.c [21:17:15 CEST] <JEEB> seems to be a "libavformat AVIOContext API example." [21:17:27 CEST] <JEEB> in other words, instead of reading from a file or protocol [21:17:39 CEST] <JEEB> you would be providing the functions which libavformat calls when it wants to read or write or seek [21:17:47 CEST] <JEEB> of course in your case you just implement read [21:18:12 CEST] <coolhp48> Looks very promising :-) ... I'm going to read up on it and see what I can figure out. [21:18:48 CEST] <JEEB> you just have to make sure you can make ADTS AAC from whatever you're given [21:25:47 CEST] <coolhp48> Ah... down the rabbit hole I went and low and behold, it looks like what I have are actually LATM ? Trying to understand what that is. [21:28:12 CEST] <JEEB> coolhp48: ok, then you should be able to feed that into the loas reader [21:28:26 CEST] <JEEB> as opposed to the "aac" one which ADTS [21:29:08 CEST] <coolhp48> Trying to adapt the decode example with that in mind.... brb [21:31:08 CEST] <coolhp48> There seems to be a code for that directly (CODEC_ID_AAC_LATM) [21:32:41 CEST] <JEEB> yes, of course you can try your chances and try making an AVPacket out of your data and feeding that into the AAC decoder with that codec id [21:33:03 CEST] <JEEB> if that doesn't seem to work, then you'll have to try the "demuxer" level thing with your own AVIO callbacks [21:33:18 CEST] <JEEB> which will then call the parser on the stream and all that fancy stuff [21:33:45 CEST] <coolhp48> Thanks a lot JEEB.... I'm going to keep going down this avenue and see where it leads. [21:38:07 CEST] <texasmynsted> I have videos recorded using OBS to h264 using "Apple VT H264 Hardware Encoder" with aac audio in mkv container. [21:38:55 CEST] <texasmynsted> They can not be seeked. They play but only from start to finish, no seeking of any kind. I tried copy to mp4, but the same issue exists. [21:39:04 CEST] <texasmynsted> How can I fix this? [21:39:54 CEST] <BtbN> Just remuxing to any other container will fix that. The encoder is entirely irrelevant for that. Unless it did some insanity like not adding I frames at all. [21:40:21 CEST] <texasmynsted> I added bframes [21:40:26 CEST] <texasmynsted> during encoding [21:40:53 CEST] <texasmynsted> so copy from mkv to mp4, should have fixed it? [21:41:51 CEST] <JEEB> yes, if it has random access points correctly marked [21:42:05 CEST] <BtbN> bframes don't matter either [21:42:09 CEST] <JEEB> you might try to extract into a raw .264 file first [21:42:19 CEST] <BtbN> that'll mess up sync with the audio [21:42:28 CEST] <JEEB> if it's VFR, yes [21:42:35 CEST] <BtbN> Even if not [21:42:49 CEST] <JEEB> and I was going to note L-SMASH's mxuer because the frame rate setting patch is not in yet [21:42:51 CEST] <BtbN> Audio and Video might be offset a bit [21:42:56 CEST] <JEEB> well yes [21:43:55 CEST] <BtbN> I'd first make sure if that thing has more than one I frame [21:44:18 CEST] <texasmynsted> how? [21:46:16 CEST] <JEEB> ffprobe's show_packets might not show anything else than what the container is informing it of. thus, probably ffprobe's show_frames + grep for the keyframe flag [21:46:23 CEST] <JEEB> I think it was also in AVFrames? [21:46:28 CEST] <JEEB> don't remember [21:49:43 CEST] <coolhp48> I'm now hitting a strange problem : When I call "codec = avcodec_find_decoder(AV_CODEC_ID_AAC); [21:49:43 CEST] <coolhp48> " , it always return 0x00... any ideas ? [21:49:56 CEST] <JEEB> how old FFmpeg? [21:50:04 CEST] <JEEB> also you need specifically the LATM one [21:50:16 CEST] <JEEB> AV_CODEC_ID_AAC_LATM [21:51:08 CEST] <coolhp48> Yup, that's what I tried too. My FFMpeg is 3.2.12 [21:51:23 CEST] <JEEB> ok, then you need to call av_register_all [21:51:29 CEST] <JEEB> as one of your first things :P [21:51:43 CEST] <JEEB> that was made unnecessary half a year or so ago [21:51:45 CEST] <JEEB> I think? [21:51:54 CEST] <texasmynsted> I guess -count_frames [21:52:14 CEST] <coolhp48> Doh ! ... thank you ! [21:52:25 CEST] <JEEB> texasmynsted: -of json -show_frames |grep keyframe ... I think? [21:52:26 CEST] <texasmynsted> but it will probe for the entire time of the video (I am guessing). Video is 1 hour [21:52:37 CEST] <JEEB> it will decode the whole shebang as fast as it can :P [21:52:48 CEST] <texasmynsted> ok [21:53:08 CEST] <texasmynsted> I will just let it work in the backgroun [21:53:13 CEST] <JEEB> alternatively, extract the H.264 stream and use show_packets [21:53:15 CEST] <JEEB> which is much faster [21:53:24 CEST] <JEEB> because that way it will have to parse the stream [21:53:26 CEST] <JEEB> :) [21:53:50 CEST] <JEEB> as opposed to "this is in a sane container, and I can trust it to have set the flags right") [21:54:00 CEST] <texasmynsted> ok what if it does not have frames or whatever [21:54:06 CEST] <texasmynsted> Can I somehow add them? [21:54:48 CEST] <JEEB> not without re-encoding [21:55:17 CEST] <texasmynsted> Okay, how would I re-encode? [21:55:52 CEST] <texasmynsted> like rather than copy, I am guessing I would somehow let it transcode back to the same codec? [21:56:09 CEST] <JEEB> just check the stream first :P [21:56:17 CEST] <JEEB> since it makes no sense to re-encode if you can just properly remux [22:01:21 CEST] <texasmynsted> okay [22:06:39 CEST] <texasmynsted> many key_frame [22:07:10 CEST] <JEEB> alright [22:07:15 CEST] <JEEB> so it's just a bugged mux \o/ [22:08:23 CEST] <texasmynsted> https://gist.github.com/mmynsted/f976a399080d635fb011ca354d74454d [22:09:05 CEST] <texasmynsted> they are all 1 or 0 [22:09:09 CEST] <texasmynsted> whatever that means [22:10:12 CEST] <JEEB> so yea, you should try to extract the video track, extract the timestamps (they're called "timecodes" with mkvextract or so) for the video track, and then use the separate video track and the timecodes together with the audio from the other matroska file with mkvmerge(gui) or so [22:10:16 CEST] <texasmynsted> so is this correct to re-mux? ffmpeg -i 2019-04-05_13-04-27.mkv -codec copy 2019-04-05_13-04-27.mp4 [22:10:24 CEST] <JEEB> yes, but if your input file's flags are bonkers [22:10:34 CEST] <JEEB> then it will copy the flags incorrectly [22:10:54 CEST] <JEEB> that's why I noted how to do it the "long way" [22:12:58 CEST] <texasmynsted> So then: 1. extract video h264, 2. extract audio aac, 3. extract timecodes, 4. use something called mkvmerge to combine/remux them? [22:14:09 CEST] <JEEB> no need to extract audio [22:15:31 CEST] <JEEB> 1. so extract the video (can be done in ffmpeg) 2. extract the video timecodes (really: timestamps! matroska has brought up a generation of people who go to work in media and get confused about these two). 4) in mkvmerge(gui) stick in a) the audio track from the original mkv (disable video), b) the video from the raw .264 file (with timecodes) [22:15:53 CEST] <JEEB> so you can read the audio as-is, but the video you want to once pull out [22:16:59 CEST] <coolhp48> Question : When I call av_parser_parse2 with my codec set to AV_CODEC_ID_AAC_LATM , which function in actually being called to parse the LATM packet ? Is it latm_parse() from [22:17:00 CEST] <coolhp48> libavcodec [22:17:00 CEST] <coolhp48> latm_parser.c ? [22:18:00 CEST] <texasmynsted> okay thank you. I will try this. I also need to figure out why OBS would do this, to prevent this for future videos. [22:18:22 CEST] <texasmynsted> I do now want to have to do this over and over, each day. Hehe [22:21:50 CEST] <JEEB> coolhp48: if you have an AVPacket you have already "parsed" it [22:22:17 CEST] <JEEB> not sure how you got parsing in there, but not like I've used that API [22:22:40 CEST] <JEEB> if you were getting "standard" LATM AAC packets I would have thought you would have just attempted to feed them to the decoder [22:22:45 CEST] <JEEB> and see how it explodes or not [22:28:33 CEST] <Retal> Guys, what command shows all available ffmpeg filters? Like ffmpeg -h...... [22:29:15 CEST] <durandal_1707> ffmpeg -filters [22:29:47 CEST] <Retal> durandal_1707: thx! [22:34:23 CEST] <JEEB> (45 [00:00:00 CEST] --- Sat Apr 6 2019

1 0

ffmpeg-devel.log.20190404
by burek 05 Apr '19

05 Apr '19

[00:10:24 CEST] <nevcairiel> jamrial: i figured out why fate doesnt work on my windows boxes anylonger. Some of the helper routines that are now being used by more tests don't like windows-style absolute path syntax, and therefor screw everything up [00:11:13 CEST] <jamrial> nevcairiel: might have to change the test to not use transcode() then [00:11:20 CEST] <jamrial> i'll look at it later [00:11:21 CEST] <nevcairiel> its actually surprising this didnt blow up much sooner, but apparently TARGET_PATH wasn't used much [00:11:49 CEST] <nevcairiel> actually m aybe this can be fixed easier [00:12:12 CEST] <nevcairiel> transcode() wants to prepend TARGET_PATH and checks if its already there [00:12:16 CEST] <nevcairiel> but that check f ails on windows [00:12:25 CEST] <nevcairiel> so.. why not change the actual test to not have it there? [00:12:38 CEST] <nevcairiel> it'll just get added and not blow up [00:12:40 CEST] <nevcairiel> let me test [00:13:02 CEST] <nevcairiel> yup that works [00:15:20 CEST] <nevcairiel> i'll send to the ML [00:15:23 CEST] <jamrial> nice, thanks [00:17:15 CEST] <jamrial> i worry about the transcode() tests adding TARGET_SAMPLES then [00:18:09 CEST] <nevcairiel> its probably not just transcode [00:18:25 CEST] <nevcairiel> a lot of functions have that appending logic [00:18:33 CEST] <nevcairiel> but samples are not typically in TARGET_PATH [00:18:40 CEST] <nevcairiel> since thats the output directory [00:18:51 CEST] <nevcairiel> this one was special since it was generated by another test [00:20:11 CEST] <nevcairiel> TARGET_SAMPLES works because I have that setup with a relative path :D [00:20:31 CEST] <nevcairiel> iirc i did that because absolute-path on windows for that was entirely broken :) [00:20:57 CEST] <jamrial> yeah, i have to do the same [00:21:22 CEST] <nevcairiel> i forget why i didnt u se mingw-style path with /c/ instead of c:/ [00:21:28 CEST] <nevcairiel> but probably msvc stuff didnt liket hat [11:32:59 CEST] <cone-127> ffmpeg 03Michael Niedermayer 07master:8e3b01e20ebd: avcodec/agm: More completely check size before using it [12:41:50 CEST] <durandal_1707> michaelni: do you know way to get different(non-canonical) prefix codes from set of bit-lenghts? [13:12:34 CEST] <michaelni> iam not sure i understand the question, you can build a VERY large number of prefix codes from a list of lengths [13:19:56 CEST] <durandal_1707> michaelni: yes, but i know how for certain values code actually looks like [13:31:20 CEST] <michaelni> durandal_1707, i dont have a good solution i think. if its few codes a text editor or pencil and paper could be used to build the whole list of prefixes with a lot of guessing. once the patterm is obvious the rest could be done with code. I assume theres no simple table in the binary of these codes? [13:31:54 CEST] <michaelni> also of course you coukd hack the encoder (if available) to spit all codes out in sequence or feed special input to achieve the same [13:33:47 CEST] <michaelni> the decoder with some instrumentation decoding random things might also be useable to extract the codes but maybe iam misunderstanding the problem [13:35:58 CEST] <durandal_1707> i have codec that recreate huffman tree from set of 256 bit-lenghts [13:36:49 CEST] <michaelni> try if it matches any of our length -> prefix implementations [13:38:20 CEST] <durandal_1707> already did [13:46:04 CEST] <michaelni> ff_huff_build_tree() with custom HuffCmp might help, if you know how things in the tree are supposed to be ordered [13:51:30 CEST] <durandal_1707> isn't that for frequencies only? [13:53:22 CEST] <michaelni> you can use something like freq = 1<<len [13:54:36 CEST] <michaelni> rather freq = 1<<(max - len) [14:06:22 CEST] <durandal_1707> michaelni: does not work [14:32:30 CEST] <j-b> 'lo [14:33:35 CEST] <durandal_1707> alright [14:42:31 CEST] <kurosu> durandal_1707: I don't think you have another option than RE how the codewords are created [14:54:02 CEST] <kurosu> if it's not that dynamical, maybe you could dump the output and store them in a data file as codebooks [14:54:26 CEST] <kurosu> (though atypical for huffman codes) [15:09:44 CEST] <durandal_1707> it is dynamical [16:11:03 CEST] <JEEB> it seems like the C++ module in ghidra got open sauce'd? [22:57:12 CEST] <carton> Hello! Could you please add "#!/bin/sh" to ffbuild/libversion.sh. It doesn't work with busybox. Thank you. [00:00:00 CEST] --- Fri Apr 5 2019

1 0

ffmpeg.log.20190404
by burek 05 Apr '19

05 Apr '19

[05:51:00 CEST] <cardz> Are there any tools out there to compare two videos, or to rate and score a video's quality on any number of factors [05:51:25 CEST] <cardz> The goal being to conclude that one video is "better" than another, and how much better. [05:55:24 CEST] <furq> cardz: https://ffmpeg.org/ffmpeg-filters.html#libvmaf [06:00:46 CEST] <cardz> furq: thanks. Do you know if this netflix lib is also ported to Windows? [13:41:55 CEST] <lemourin> Is it expected behavior that the result of conversion from rgb24 to yuv420p is platform dependent? [13:49:03 CEST] <JEEB> yes, there's some SIMD in there most likely [13:49:20 CEST] <JEEB> and SSE2 etc might give different results to plain C [13:54:01 CEST] <lemourin> JEEB: is there a way to make it platform independent? by e.g. disabling optimizations? [13:59:29 CEST] <JEEB> the tests utilize a bitexact flag [14:00:51 CEST] <JEEB> -sws_flags bitexact seems to be one [14:01:18 CEST] <lemourin> thanks, i'll try this out [14:29:30 CEST] <thebombzen> did kmsgrab ever get fixed on nVidia? [14:44:04 CEST] <ahmadjamalmughal> Hi. Is anyone here applying for GSoC? [14:50:13 CEST] <JEEB> ahmadjamalmughal: some people have popped up on the -devel channel, but I'm not sure how many mentors are on IRC [16:49:43 CEST] <zPhantomGG> hi [16:51:33 CEST] <zPhantomGG> Can someone answer me if this is a bug? http://phantsc.rf.gd/AAA/Bbb.html exactly in the second 7 [16:53:03 CEST] <zPhantomGG> using: 'ffmpeg.exe -i in.mp4 -vcodec copy -acodec aac -hls_list_size 0 -hls_segment_size 17000000 -f hls out.m3u8' [16:55:56 CEST] <zPhantomGG> someone? [16:58:10 CEST] <pink_mist> wait for people with knowledge in the area to respond [16:58:17 CEST] <pink_mist> (that does not include me) [17:00:24 CEST] <faLUCE> zPhantomGG: why do you see it as a bug? [17:00:37 CEST] <faLUCE> is your mp4 different? [17:05:03 CEST] <zPhantomGG> a video crash occurs. [17:05:26 CEST] <zPhantomGG> when going from segment0.ts to segment1.ts [17:06:15 CEST] <zPhantomGG> in the link I sent you can see clearly [17:07:25 CEST] <zPhantomGG> I'm trying to get m3u8 with bytesranges, and each segment with a maximum size [17:07:33 CEST] <zPhantomGG> not a size exactly, but approximate [17:07:55 CEST] <zPhantomGG> so I use: -hls_segment_size [17:09:32 CEST] <w1kl4s> it does? [17:10:26 CEST] <faLUCE> zPhantomGG: with which criterium did you set hls_segment_size to 17000000 ? [17:11:15 CEST] <zPhantomGG> for each segment to have an approximate size [17:11:44 CEST] <zPhantomGG> ~17MB [17:11:45 CEST] <faLUCE> zPhantomGG: ok, but why did you choose the value 17000000 ? [17:11:57 CEST] <faLUCE> did you try with another value? [17:11:59 CEST] <zPhantomGG> https://github.com/FFmpeg/FFmpeg/blob/9461e4bc694b8d95d4224226b9781f8166d96… [17:12:13 CEST] <zPhantomGG> yes [17:12:36 CEST] <faLUCE> also with very different values? [17:12:36 CEST] <zPhantomGG> this video in the link that I sent, was with a lower value [17:12:53 CEST] <faLUCE> for example: 1 Mb [17:13:00 CEST] <faLUCE> or even less [17:13:40 CEST] <zPhantomGG> even different values, this always happens in the video, when it goes from one segment to the other [17:15:55 CEST] <faLUCE> zPhantomGG: I would suggest you to re-encode with the same codec, but not with a copy [17:16:13 CEST] <faLUCE> and then mux again with the same segment val and see what happens [17:22:04 CEST] <zPhantomGG> Like this ? -vcodec libx264 -acodec aac -hls_list_size 0 -hls_segment_size 1000000 -f hls [17:23:04 CEST] <faLUCE> yes [17:23:19 CEST] <zPhantomGG> the same thing happens [17:24:18 CEST] <faLUCE> zPhantomGG: try to mute the audio codec [17:24:26 CEST] <faLUCE> -acodec none [17:24:31 CEST] <zPhantomGG> ok [17:24:59 CEST] <zPhantomGG> Unknown encoder 'none' [17:25:10 CEST] <faLUCE> -an or something like that [17:28:06 CEST] <zPhantomGG> -vcodec libx264 -an -hls_list_size 0 -hls_segment_size 1000000 -f hls [17:28:25 CEST] <zPhantomGG> The same thing happens, the video hangs [17:29:15 CEST] <faLUCE> and you don't hear the audio, right? [17:29:49 CEST] <zPhantomGG> no audio, I can see the video hang [17:29:55 CEST] <faLUCE> ok, wait [17:34:09 CEST] <faLUCE> zPhantomGG: [hls @ 0x5602e0a4b380] Cannot use rename on non file protocol, this may lead to races and temporary partial files [17:35:54 CEST] <zPhantomGG> I did not understand.. [17:38:11 CEST] <DHE> the traditional method of writing your new files to a .tmp file and then rename() it to the proper name for an atomic content update doesn't work if you're doing, say, direct HTTP PUT uploads [17:41:25 CEST] <zPhantomGG> I am not uploading via HTTP PUT ... [17:48:19 CEST] <faLUCE> zPhantomGG: https://docs.peer5.com/guides/production-ready-hls-vod/ [18:00:26 CEST] <zPhantomGG> I already saw this tutorial [18:00:29 CEST] <zPhantomGG> I'm looking to make an m3u8 file that has byte range [18:00:56 CEST] <zPhantomGG> without using '-hls_flags single_file' [18:01:43 CEST] <zPhantomGG> but I also want to set an approximate size for each segment [18:06:17 CEST] <zPhantomGG> it's probably some problem with '-hls_segment_size' [18:06:18 CEST] <zPhantomGG> alguém tem uma ideia alternativa? [18:06:24 CEST] <zPhantomGG> Does anyone have an alternative idea? [18:11:18 CEST] <kevinnn> does anyone know how to properly handle a 60fps h264 network stream that has sliced NAL units? Previously I would just render after each NAL unit was received with libav but not that they are sliced there are actually much more than 60 NAL units coming in per second on a 60fps stream [18:48:29 CEST] <poisond> hi :) I'm having problems with nvenc since a recent update: https://pastebin.ubuntu.com/p/S4mMKgKQT3/ ... is this a known problem? Any workaround? [18:50:39 CEST] <JEEB> that really says nothing :D [18:51:36 CEST] <JEEB> initialized successfully and then unloaded [18:55:02 CEST] <poisond> JEEB: sorry, here's with an actual file https://pastebin.ubuntu.com/p/dnZSmYp2px/ [18:55:28 CEST] <JEEB> [hevc_nvenc @ 0x55f55b535500] OpenEncodeSessionEx failed: out of memory (10) [18:55:36 CEST] <JEEB> so you're trying to do 5 encodes [18:55:42 CEST] <JEEB> due to teh cover art in there :P [18:56:16 CEST] <JEEB> I think nvidia tells you to eff off if it's like over 2 or 4 [18:56:20 CEST] <JEEB> in the driver [18:56:28 CEST] <JEEB> unless you patch the driver to remove that limit [18:57:36 CEST] <netkam2> can I record a command line only with ffmpeg [19:00:57 CEST] <poisond> JEEB: ok, never encountered this before O_o so nvenc doesn't like multiple video stream? [19:01:08 CEST] <poisond> JEEB: or is it the format it's complaining about? [19:02:34 CEST] <poisond> I can transcode with -map 0:v:0 [19:02:50 CEST] <JEEB> poisond: it's the amount of encodes being done at a time :P [19:03:02 CEST] <JEEB> the driver has a hard-coded limit for normal customer cards [19:04:12 CEST] <poisond> JEEB: OK, thanks, that solved my problem! (still confuses me since I tend to do parallel transcodes using nvenc) [19:04:57 CEST] <JEEB> you can do multiple, but in this case you were doing 5 [19:05:16 CEST] <JEEB> which I think is more than nvidia lets you do at once [19:06:23 CEST] <JEEB> https://developer.nvidia.com/video-encode-decode-gpu-support-matrix [19:06:30 CEST] <JEEB> poisond: ^ see this [19:07:01 CEST] <JEEB> so for GTX 1080 it's one chip and 2 instances per chip [19:07:20 CEST] <JEEB> and then max concurrent sessions is 2 [19:07:31 CEST] <JEEB> that's of course a 100% driver limitation :P [19:07:50 CEST] <JEEB> nvidia wants you to pay more moneys for a quadro if you want more encodes at once [19:08:23 CEST] <poisond> oh, only need to shelf out a few thousand bucks to do 3 parallel, that's quite generous of them to allow 2 on consumer cards then xD [19:16:31 CEST] <nicolas17> can I make ffmpeg only decode intra frames? I'm speeding up a video like 60x and decoding the input is the bottleneck, it seems to be decoding every frame and then dropping most of them [19:18:12 CEST] <JEEB> nicolas17: with the API you could do that, not sure if you can drop with the command line app [19:22:42 CEST] <nicolas17> ok I think I can download the input file to my 4-core PC faster than I can transcode on my 1-shared-core VPS :/ [19:27:55 CEST] <kevinnn> I am getting this warning while using ffmpeg [19:27:56 CEST] <kevinnn> chroma_format_idc 10 is not implemented [19:28:11 CEST] <kevinnn> is it necessary to update ffmpeg in this case? [19:29:22 CEST] <kevinnn> google literally returns this for a search on the internet [19:29:30 CEST] <kevinnn> "No results found for "chroma_format_idc 10 is not implemented"." [19:31:26 CEST] <kevinnn> which means I am the first human to have this issue? [19:31:40 CEST] <nicolas17> what version of ffmpeg? [19:31:46 CEST] <JEEB> is that HEVC or AVC? [19:32:23 CEST] <kevinnn> JEEB: AVC [19:32:38 CEST] <kevinnn> nicolas17: whatever the latest version debian stretch offers [19:32:49 CEST] <kevinnn> I am using the libraries not ffmpeg directly [19:33:12 CEST] <JEEB> should quickly check if it's logging it as bits [19:33:16 CEST] <JEEB> or as a value [19:33:20 CEST] <JEEB> like, is 10 3 [19:33:22 CEST] <JEEB> or is it 10 [19:33:30 CEST] <JEEB> because 3 makes sense [19:33:33 CEST] <JEEB> 10 less so [19:34:00 CEST] <kevinnn> it shows 10 [19:34:08 CEST] <kevinnn> I am not even sure what that means to be honest [19:34:48 CEST] <JEEB> ok, so it's really 10 [19:34:59 CEST] <JEEB> just looked at the place where it logs where it requests a sample [19:35:09 CEST] <JEEB> if it's more than 3 it logs that out [19:35:21 CEST] <JEEB> let's see if that value makes any sense according to the specification :) [19:36:28 CEST] <kevinnn> JEEB: hmm, okay but what exactly does it mean? [19:36:39 CEST] <JEEB> "chroma_format_idc shall be in the range of 0 to 3, inclusive." [19:36:43 CEST] <JEEB> according to the specification [19:36:53 CEST] <JEEB> "chroma_format_idc specifies the chroma sampling relative to the luma sampling as specified in clause 6.2." [19:36:54 CEST] <nicolas17> so your input file is corrupted or otherwise not conforming [19:37:08 CEST] <nicolas17> i guess [19:37:26 CEST] <kevinnn> oh okay, weird, why is my input file like that? It plays just fine on other decoders [19:37:38 CEST] <kevinnn> well specifically openmax IL [19:37:50 CEST] <JEEB> hw decoders anyways expect chroma_format_idc 1 [19:37:58 CEST] <JEEB> (or no value which is same as 1) [19:38:10 CEST] <kevinnn> this is a software decoder [19:38:11 CEST] <JEEB> which is 4:2:0 video [19:38:22 CEST] <JEEB> kevinnn: anyways I guess quickest way to check is to get a sample [19:38:35 CEST] <JEEB> but the initial guesstimate is that the stream is in some way corrupted [19:38:40 CEST] <kevinnn> okay let me see... [19:39:37 CEST] <nicolas17> ok no, looks like my slow VPS will finish encoding before my slow home internet finishes downloading input -.- [19:48:42 CEST] <kevinnn> JEEB: https://www.mediafire.com/file/kthp42ahfzouy0h/output/file [19:48:49 CEST] <kevinnn> this is that first packet [19:48:57 CEST] <kevinnn> does it look corrupt? [19:49:20 CEST] <JEEB> annex b? [19:49:26 CEST] <kevinnn> yes [20:02:15 CEST] <kevinnn> JEEB: is it super corrupt? [20:03:35 CEST] <JEEB> kevinnn: I'm trying to get some food etc [20:04:01 CEST] <kevinnn> JEEB: okay sorry, didn't mean to bother you [20:41:00 CEST] <kevinnn> can anyone else take a look at my first frame? [23:30:32 CEST] <TheSashmo> anyone know if there is a way to apply biss code to a file after its been recorded? I have the ecnrypted file and the biss key [00:00:00 CEST] --- Fri Apr 5 2019

1 0

ffmpeg-devel.log.20190403
by burek 04 Apr '19

04 Apr '19

[00:11:36 CEST] <jamrial> jkqxz: regarding my review, something like https://pastebin.com/HmCgZ1mm (on top of your set) [00:36:27 CEST] <durandal_1707> kurosu: codes are static - and there are many combinations for same set of bitlengths [00:55:07 CEST] <cone-185> ffmpeg 03James Almer 07master:0e1ea034d8fc: avcodec/libaomenc: fix range of values for enable-intrabc option [04:18:25 CEST] <cone-385> ffmpeg 03Jun Zhao 07master:ecb4398d71c9: lavf/hashenc: Correct the hash/MD5 muxer class name [07:34:53 CEST] <cone-698> ffmpeg 03Gyan Doshi 07master:b131a07e4bf9: fate: unbreak fate with custom binary names [11:01:41 CEST] <pridkett> what is cehoyos 's irc name [11:02:05 CEST] <JEEB> exactly that, but he is on IRC very rarely [11:02:21 CEST] <pridkett> cehoyos closed my ticket for no reason [11:02:33 CEST] <JEEB> comms with him is mostly through e-mail (ML or private) [11:02:40 CEST] <JEEB> or the issue tracker, yes [11:02:56 CEST] <pridkett> jeeb is jeeb also your trac nasme? [11:02:59 CEST] <durandal_1707> do not spamm trac with useless bug reports [11:03:04 CEST] <JEEB> pridkett: yes? [11:03:26 CEST] <pridkett> durandal_1707 why would you say it's useless [11:03:43 CEST] <JEEB> he doesn't even know what you're talking about:P and neither do I [12:21:16 CEST] <cone-698> ffmpeg 03Gyan Doshi 07master:8161ac290283: lavf/movenc: fix tmcd writing for non-MP4/MOV modes [16:50:19 CEST] <durandal_1707> can i traverse(preorder/inorder/postorder) binary tree represented with array? [17:00:31 CEST] <cone-325> ffmpeg 03Zhong Li 07master:6f9d7c556d5f: lavc/qsvenc: no need to include h264.h for jpeg encoder [17:00:32 CEST] <cone-325> ffmpeg 03Zhong Li 07master:c745bedd18af: lavc/qsvenc: enable hevc coding options configuration [17:00:33 CEST] <cone-325> ffmpeg 03Zhong Li 07master:1125277bc64e: lavc/qsvenc: enable hevc gpb option [18:48:30 CEST] <thardin> oh joy av1 patent trolls are coming out of the woods [18:53:04 CEST] <BBB> samsung is not a troll? [18:53:18 CEST] <BBB> (I know, you mean sisvel :-p) [18:54:30 CEST] <nevcairiel> i'm sure every sufficiently large company has done some patent trolling in their time [19:02:17 CEST] <durandal_1707> can i traverse(preorder/inorder/postorder) binary tree represented with array? [23:14:55 CEST] <cone-424> ffmpeg 03James Almer 07master:ee16d14b0a29: avcodec/av1_metadata: add an option to remove Padding OBUs [23:15:40 CEST] <durandal_1707> why i get same output for different binary tree traversals? [00:00:00 CEST] --- Thu Apr 4 2019

1 0

ffmpeg.log.20190403
by burek 04 Apr '19

04 Apr '19

[00:00:31 CEST] <bugre> faLUCE: i would like to stop ffprobe after a certain amount of time (or frames if that helps). I'm trying to automate some checkings on GOP, bitrate on our livestreams. [00:08:47 CEST] <fella> -read_intervals [00:10:09 CEST] <pridkett> let's say if i have IP 24.111.111.100 and let's say my neighbor who use same ISP as me has IP 24.111.111.105 : if somebody DDOS my ip 24.111.111.100 , obviously i would go offline, but would my neighbor go offline as well? [00:29:38 CEST] <friendofafriend> pridkett: I think you're in the wrong channel, maybe ##networking instead? [00:29:48 CEST] <pridkett> okay [01:19:11 CEST] <bugre> fella: Thank you, you're the man!! '-read_intervals' worked. [01:19:28 CEST] <bugre> I would never have found this one alone. [04:56:33 CEST] <nitrxgen> just a message of appreciation for ffmpeg, idk how i would ever manipulate videos as easily as this [06:37:42 CEST] <while> hi [06:42:08 CEST] <while> is rfc3533 the rfc implemented by ffmpeg when encoding OGG files? [08:26:32 CEST] <pridkett> what is the command to put just the audio test.ac3 to .mp4 container file? [08:27:13 CEST] <pridkett> what is the command to put just the audio "test.ac3" to "test.mp4" container file? [08:43:43 CEST] <JEEB> pridkett: ffmpeg -i test.ac3 -c copy test.mp4 [08:43:57 CEST] <pridkett> thanks [08:45:40 CEST] <pridkett> wow that caused ffmpeg to crash [08:45:57 CEST] <pridkett> never seen that befnore [09:23:17 CEST] <pridkett> i get this error " add '-strict -2' if you want to use it" but if i add it i get this error "Unable to find a suitable output format for 'strict -2' [09:23:17 CEST] <pridkett> strict -2: Invalid argument" [11:07:07 CEST] <azy> how can i overlay an mp3 to an mp4 at a specific time? [11:07:48 CEST] <tanja77> hi. I got many surveillance videos (about animals im my garden). does anyone know of a software that could "inspect" all these MANY videos and look on differences so that I could "catch" the animal automatically instead of watching all videos? [11:08:05 CEST] <tanja77> (I am actually watching them via avidemux with more speed, but its a pain anyway) [11:08:43 CEST] <pridkett> azy what does the mp4 file have [11:09:10 CEST] <azy> video+audio [11:09:17 CEST] <pridkett> azy which codec [11:09:35 CEST] <pridkett> tanja77 what is your obsession with animals on your surveillnace video [11:10:13 CEST] <azy> ive no idea [11:10:19 CEST] <pridkett> ffprobe it then [11:10:44 CEST] <azy> http://paste.debian.net/hidden/6e705203/ [11:11:44 CEST] <pridkett> does mp3 and mp4 have matching timeline? [11:11:49 CEST] <pridkett> does mp3 and aac have matching timeline? [11:13:19 CEST] <tanja77> pridkett, no obsession. its because the animals leaves its "rests" on our balkony and we want to know what kind of animals it is [11:13:38 CEST] <pridkett> rests? [11:13:45 CEST] <tanja77> for example we would have to treat a dormouse different like a mouse or so, right? [11:14:04 CEST] <tanja77> had to google this translation: [11:14:05 CEST] <tanja77> feces [11:14:08 CEST] <tanja77> :-) [11:14:11 CEST] <pridkett> i see [11:14:32 CEST] <pridkett> azy: Dude\ Asks\ Girl\ To\ The\ Prom\ But\ Showed\ Up\ To\ The\ Wrong\ House\!-video.mp4 that's a weird file name [11:14:49 CEST] <azy> no @ matching timeline [11:14:54 CEST] <azy> http://worldstarhiphop.com/videos/video.php?v=wshh8k7r15F4hBKA88lv [11:14:57 CEST] <azy> its hilarious [11:14:59 CEST] <pridkett> why do you have such a weird file name [11:15:01 CEST] <tanja77> so in the first place its just about knowing who the offender is ;-) [11:15:45 CEST] <pridkett> azy it's not even funny [11:15:47 CEST] <pridkett> i just watched [11:16:06 CEST] <pridkett> azy so what mp3 file you want to overlay? [11:20:35 CEST] <azy> http://paste.debian.net/hidden/76eda90b/ [11:20:50 CEST] <pridkett> tanja77 sorry not sure how ffmpeg can detect animals [11:21:05 CEST] <azy> needs to detect motion [11:21:19 CEST] <azy> https://motion-project.github.io/ [11:21:41 CEST] <pridkett> there are face recognition [11:21:43 CEST] <azy> any surveillance software should do it [11:21:58 CEST] <pridkett> azy and what is the link you got the Curb\ Your\ Enthusiasm\ Theme-Ag1o3koTLWM.webm [11:22:30 CEST] <azy> https://www.youtube.com/watch?v=Ag1o3koTLWM [11:22:45 CEST] <azy> i could get a different format with youtube-dl if needed [11:22:58 CEST] <pridkett> azy webm is fine [11:23:02 CEST] <pridkett> ffmpeg handles it [11:23:21 CEST] <pridkett> azy are you trying to edit the video and upload to youtube? [11:23:29 CEST] <azy> ye [11:23:39 CEST] <pridkett> azy what is your youtube name [11:24:47 CEST] <azy> https://www.youtube.com/user/0xstev3/videos [11:25:59 CEST] <pridkett> 308 subscribers NOT bad for having only crappy videos [11:27:13 CEST] <pridkett> azy at what time/point does Curb\ Your\ Enthusiasm\ Theme-Ag1o3koTLWM.webm wants to join in [11:29:35 CEST] <azy> 0:07 [11:31:04 CEST] <pridkett> extract the audio file from mp4 [11:31:41 CEST] <pridkett> ffmpeg -i input1.webm -i input2.aac -filter_complex amerge -ac 2 -c:a libmp3lame -q:a 4 output.mp3 [11:33:31 CEST] <pridkett> azy why are you hiding your version [11:34:40 CEST] <azy> so i dont get haked [11:34:49 CEST] <azy> whats the second -i meant to represent? [11:37:05 CEST] <tanja77> pridkett, yes, I did not think of ffmpeg could do this LOL.. but I thought in an ffmpeg channel there could be perhaps persons that know other software or so [11:37:19 CEST] <pridkett> tanja77 fair enough [11:38:21 CEST] <pridkett> azy 99% people in freenode reveals version info [11:38:36 CEST] <pridkett> that doesn't mean 99% people are getting hacked [11:39:04 CEST] <azy> i was expecting something like: ffmpeg -i video.mp4 -i audio.webm -uwotm8 3:40 [11:39:51 CEST] <relaxed> tanja77: I think zoneminder would work (uses ffmpeg on the backend) [11:40:56 CEST] <tanja77> just downloading zoneminder... [11:41:08 CEST] <relaxed> for monitoring, not going over your past video [11:41:16 CEST] <tanja77> ah, I see [11:44:45 CEST] <relaxed> tanja77: maybe this? https://www.home-assistant.io/components/binary_sensor.ffmpeg_motion/ [11:45:41 CEST] <tanja77> this looks cook, I am gonna check this [11:45:57 CEST] <tanja77> ps: you guys see: I AM in the right channel ;-) thanks & kisses [11:47:43 CEST] <pridkett> hi i am doing a survey: what gender/age do you think the person on this youtube video is based on their voice: https://www.youtube.com/watch?v=hMynODL4GtQ [11:51:42 CEST] <azy> 14 [11:51:59 CEST] <pridkett> azy thanks and gender? [11:52:23 CEST] <azy> male [11:52:34 CEST] <azy> plus "ron fetter" [11:53:36 CEST] <pridkett> is Ron, a guy only name? [12:34:49 CEST] <JEEB> pk08: please stop privately messaging me [12:35:25 CEST] <pk08> ok, i dont see anything related to ttl in doc/example [12:35:27 CEST] <JEEB> there's an AVOption for ttl in the UDP protocol, set that through av_dict_set to your avformatcontext (or IO one, don't remember) [12:35:30 CEST] <JEEB> of course not [12:35:44 CEST] <JEEB> they are just examples on how to *set* *options* [12:36:11 CEST] <JEEB> when you set the options you will get back a list of options that were not applied [12:36:18 CEST] <JEEB> that way you can figure out if your options got applied or not [12:53:57 CEST] <pk08> thanks JEEB [14:19:27 CEST] <miyalys> Hi! I'm trying to record audio out and video simultaneously, via ffmpeg and an alsa loopback device. this command runs, but strangely the audio is only heard for maybe half a second (sounding like it should for that duration) and then it disappears? [14:19:49 CEST] <miyalys> The command: ffmpeg -f x11grab -framerate 25 -video_size 1920x1080 -i :0.0 -f alsa -i "plug:\"dsnoop:Loopback,1\"" screencast.mkv [14:21:22 CEST] <miyalys> Not sure if the solution is alsa or ffmpeg related, but recording just the audio separately, also with ffmpeg, it plays back just fine. [15:06:27 CEST] <blueman24> Hello, i trying to compile ffmpeg like this "PKG_CONFIG_PATH=/usr/local/src/ffmpeg/lib/pkgconfig ./configure --prefix=/opt/ffmpeg --extra-cflags=-I/opt/ffmpeg/include --extra-ldflags=-L/opt/ffmpeg/lib --pkg-config-flags=--static --bindir=/opt/ffmpeg/bin --enable-openssl --enable-gpl --enable-nonfree --enable-libfreetype --enable-libtheora --enable-libvpx --enable-libx264 --enable-libx265" [15:06:35 CEST] <blueman24> i got error "ERROR: freetype2 not found" [15:06:49 CEST] <blueman24> any thoughts? [15:09:03 CEST] <pink_mist> try installing freetype2 [15:09:09 CEST] <pink_mist> and its development headers [15:09:43 CEST] <blueman24> yum search freetype2 does not exist [15:10:03 CEST] <blueman24> I installed freetype-devel [15:10:57 CEST] <pink_mist> well, as long as the version of that is >=2, it should be fine [15:13:15 CEST] <blueman24> my version is: 2.8 [15:19:46 CEST] <miyalys> update on my issue: Switching to a native codec solved my problem of desyncing: ffmpeg -f alsa -i "plug:\"dsnoop:Loopback,1\"" -f x11grab -r 24 -s 1920x1080 -i :0.0 -acodec aac -vcodec mpeg4 -preset medium -qscale:v 5 rec.mkv [18:42:05 CEST] <retal> faLUCE, hi. Couple days ago you sent me message, sorry I didn't answer . Was very busy [19:54:36 CEST] <King_DuckZ> hi, in my program I want to generate output that is readable by ffmpeg's pipe input, from a full black frame for example I generate this https://alarmpi.no-ip.org/kamokan/fk?colourless (cut to 20 lines) [19:55:29 CEST] <King_DuckZ> then I run ffmpeg -i frame.y4m -r 1/1 deleme.bmp, but the resulting bmp image is not black not a uniform colour [19:57:19 CEST] <King_DuckZ> deleme.bmp --> https://alarmpi.no-ip.org/kamokan/fl?colourless (cut to 30 lines) [20:02:33 CEST] <King_DuckZ> ah fck it's interleaved, damn how did I not realize sooner [20:02:51 CEST] <King_DuckZ> sorry, I see how to fix it now [21:18:11 CEST] <faLUCE> hey retal ;-) [22:49:22 CEST] <mekeor> hello. how to convert a video to MP4 (H.264) with 8 bit depth? i tried `ffmpeg -i input.mxf -c:v libx264 -preset superfast -x264opts bit_depth=8 -c:a copy -map 0 output.mp4` because i didn't see a direct way to set the bit depth but this x264-option doesn't exist [22:50:04 CEST] <JEEB> for the basic way there's just -pix_fmt yuv420p [22:50:23 CEST] <JEEB> but since you're dealing with MXF you probably want a high quality conversion [22:50:33 CEST] <JEEB> I recommend building FFmpeg with zimg to get the zscale filter [22:50:51 CEST] <JEEB> then you can do -vf "zscale=m=709,format=pix_fmts=yuv420p" [22:51:07 CEST] <JEEB> the parameter to zscale might be unnecessary in your case [22:51:12 CEST] <mekeor> how could i find out that yuv420p has 8 bit depth if you wouldn't tell me? [22:51:50 CEST] <JEEB> I think in the API it has that property, and then you get a long list through -pix_fmts in ffmpeg.c [22:52:19 CEST] <JEEB> http://up-cat.net/p/db50f53b [22:52:21 CEST] <JEEB> a bit of it [22:52:41 CEST] <BtbN> Well, it's an 8 bit pixel format by itself [22:52:49 CEST] <BtbN> 10 or 12 bit ones are named accordingly [22:53:09 CEST] <JEEB> and yes, usually if not mentioned otherwise, it's 8bit per channel by default [22:53:41 CEST] <mekeor> cool, thank you! [22:53:44 CEST] <mekeor> so, specifying yuv420p should be enough but the zscale option would help keep high quality, right? [22:54:02 CEST] <mekeor> thank you ver much for your quick help :) [22:54:27 CEST] <JEEB> not sure how much difference in pure bit depth reduction there is [22:54:48 CEST] <BtbN> I'd say hardly any. [22:54:56 CEST] <JEEB> mostly dithering I guess? [22:55:07 CEST] <JEEB> which is minor [22:55:22 CEST] <BtbN> Don't you dither when going from 8 to 10 or 12, not the other way? [22:55:35 CEST] <BtbN> hm, no, nvm [22:55:41 CEST] <JEEB> no, dithering is usually done to get a better result from less bits [22:56:47 CEST] <mekeor> hmm. it seems like i'm missing some codecs... http://sprunge.us/ClPCJr [22:58:08 CEST] <mekeor> oh, seems like that error is due to the audio stuff [22:58:11 CEST] <JEEB> yes [22:58:18 CEST] <mekeor> hmm. i was trying to keep all audio-tracks [22:58:29 CEST] <JEEB> raw audio is possible in mp4 but not sure how much was implemented [22:58:35 CEST] <JEEB> that's a really fringe thing [22:59:52 CEST] <mekeor> raw audio? [23:00:02 CEST] <JEEB> yes, the audio is raw pcm [23:00:08 CEST] <JEEB> as opposed to being compressed [23:00:40 CEST] <mekeor> and you can only have multiple tracks of audio if it's raw pcm? [23:00:46 CEST] <JEEB> no? [23:01:01 CEST] <mekeor> sorry, i didn't understand you then :D [23:01:05 CEST] <JEEB> I'm saying the version of FFmpeg you have at least can't figure out which identifier to put into mp4 to put raw audio into it :P [23:01:13 CEST] <JEEB> thus the "codec not currently supported in container" [23:02:46 CEST] <mekeor> hmm, so might there be a solution without compiling ffmpeg on my own? [23:03:14 CEST] <JEEB> you can use an audio format that FFmpeg can write into mp4 [23:03:29 CEST] <JEEB> or switch from mp4 to another container [23:04:35 CEST] <mekeor> ah, okay, specifying aac works [23:05:16 CEST] <mekeor> but in the input-file there is a "Data: none" stream and thus ffmpeg complains that the codec "none" is not supported [23:05:47 CEST] <JEEB> yes, it's vanc data. [23:06:02 CEST] <JEEB> which is exported with a data_type but there's no codec id for it :P [23:06:16 CEST] <mekeor> so i need to map it, right? [23:06:21 CEST] <JEEB> no [23:06:29 CEST] <JEEB> most likely you don't get anything useful out of it with ffmpeg.c [23:06:37 CEST] <JEEB> whatever SMPTE 436M VANC is :P [23:07:23 CEST] <mekeor> so i need to tell ffmpeg to ignore that stream? [23:07:28 CEST] <JEEB> yes [23:07:41 CEST] <JEEB> seems like support was added to be able to copy those streams from MXF to MXF [23:07:47 CEST] <JEEB> but nothing at all otherwise :P [23:08:14 CEST] <mekeor> ah okay :D [23:08:25 CEST] <mekeor> i hope i won't miss those data [23:08:30 CEST] <JEEB> http://mogurenko.com/2015/10/30/closed-captions-and-mxf/ [23:08:39 CEST] <JEEB> seemingly closed captions [23:10:48 CEST] <mekeor> okay, cool, i specified `-map 0:v -map 0:a`& let's see =) [23:12:11 CEST] <JEEB> I guess if you actually read the caption data from the MXF packets you could export it as a captions track since FFmpeg has a decoder for it [23:12:23 CEST] <JEEB> but then you'd have to add re-packaging code on the other side (writing MXF) [23:12:37 CEST] <JEEB> which currently just happens to work because nothing is done to the data xD [23:19:56 CEST] <mekeor> actually i could also use `-map 0` for MXF-to-MTS conversion [23:20:13 CEST] <JEEB> not sure what it did with the data track for the record :P [23:20:26 CEST] <JEEB> since most likely it did *nothing* to the packets, which are valid in MXF [23:20:31 CEST] <JEEB> but not necessarily in MPEG-TS [23:20:50 CEST] <JEEB> and most likely MPEG-TS lets you send out arbitrary data as Data streams [23:20:51 CEST] <JEEB> :P [23:21:03 CEST] <JEEB> as in, the FFmpeg writer [23:40:13 CEST] <mekeor> thank you very much, JEEB and BtbN :) [23:40:27 CEST] <mekeor> i got done what i was aiming to do :) [00:00:00 CEST] --- Thu Apr 4 2019

1 0

ffmpeg-devel.log.20190402
by burek 03 Apr '19

03 Apr '19

[00:14:00 CEST] <BtbN> Fenrirthviti, try turning on aud, I vaguely remember that being important for the cbr padding [00:14:27 CEST] <Fenrirthviti> Hm, ok, I'll check in to that [00:14:37 CEST] <BtbN> There was a commit fixing the padding, ages ago [00:14:40 CEST] <BtbN> but I can't find it [00:15:15 CEST] <Fenrirthviti> I found a param in their headers for uhh [00:15:40 CEST] <Fenrirthviti> outputPictureTimingSEI, which is required for CBR to work properly if I read it right? [00:15:56 CEST] <Fenrirthviti> we also have outputAUD set to 1 [00:16:05 CEST] <BtbN> yes, the TimingSEI definitely is required [00:16:16 CEST] <BtbN> for whatever reason, that's what they bound the padding to [00:16:29 CEST] <Fenrirthviti> yeah digging through this has been super fun. [00:16:50 CEST] <BtbN> outputBufferingPeriodSEI and outputPictureTimingSEI need to be set for it to work, yeah [00:16:53 CEST] <BtbN> and they are [00:17:36 CEST] <nevcairiel> so that explains why those got turned on without me explicitly asking for them [00:17:46 CEST] <Fenrirthviti> I see that we're setting that, but not outputAUD actually [00:18:04 CEST] <BtbN> I don't think outputAUD was one of the magical padding settings [00:18:23 CEST] <Fenrirthviti> ah, ok. [00:18:25 CEST] <nevcairiel> i can see the buffering/timing SEIs being related to m ake a proper CBR stream [00:18:29 CEST] <nevcairiel> AUD is just unrelated [00:18:58 CEST] <Fenrirthviti> Just frustrating that nvidia is telling us that there are "too many uses cases where CBR not being CBR is useful" [00:19:13 CEST] <nevcairiel> well there are [00:19:23 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/commit/3a9df7dfec89fadfee9e814e6adb2706908… [00:19:57 CEST] <Fenrirthviti> alright, I wonder if there's some kind of logic mixup here then https://github.com/obsproject/obs-studio/blob/5d83e1aec42c39f524b1c8681ea6d… [00:20:13 CEST] <BtbN> I do still wonder why this jim-nvenc thing ever became a thing in the first place [00:20:22 CEST] <BtbN> I don't see the advantage of duplicating it into OBS [00:20:35 CEST] <Fenrirthviti> on-GPU encode is why [00:20:36 CEST] <BtbN> It was added to implement d3d11 surface input, which ffmpeg can also do. [00:20:45 CEST] <Fenrirthviti> not sure past that [00:20:47 CEST] <BtbN> nevcairiel, added that ages ago [00:21:15 CEST] <Fenrirthviti> This issue is still present in the version of ffmpeg we ship, fwiw (the bitrate padding issue) [00:21:26 CEST] <nevcairiel> i found that while googling for some nvenc information, and i also wondered why it was seperate [00:21:31 CEST] <Fenrirthviti> It's actually more pronounced in the ffmpeg nvenc than ours [00:21:36 CEST] <nevcairiel> but i also know how such projects are [00:21:43 CEST] <nevcairiel> trying to improve upstream is effort, better clone i t [00:21:48 CEST] <BtbN> So the only reason OBS duplicated mass amounts of code is because Jim didn't know nvenc in FFmpeg can take d3d11 surfaces [00:22:15 CEST] <Fenrirthviti> Could be, yeah. You'd have to ask him. [00:22:55 CEST] <BtbN> anyway, ffmpeg does set the relevant flags, anything beyond that is out of our control [00:23:08 CEST] <nevcairiel> the CBR flags have also been set since like 2016 [00:23:11 CEST] <Fenrirthviti> yeah, I'm reasonably sure this is a nvidia problem as this point [00:23:16 CEST] <nevcairiel> if OBS ffmpeg is older then that, you are in trouble anyway [00:23:27 CEST] <Fenrirthviti> I have a post from you in 2014 saying that nvidia doesn't do padding as well, heh [00:23:47 CEST] <nevcairiel> All I know is that I did a bunch of test encodes last week, and the bitrate came out perfect [00:23:53 CEST] <BtbN> That was before someone at OBS found those magic two parameters that did enable padding [00:23:56 CEST] <Fenrirthviti> It's not, no, we're on some commit in 4 I can't recall off the top of my head [00:24:00 CEST] <BtbN> they were not documented to do so at that point in time [00:24:03 CEST] <nevcairiel> but it was mostly live action movies or tv show content, so no still images or animations, so shrug [00:24:27 CEST] <Fenrirthviti> yeah, it's really only noticeable with static images or very simple animations [00:24:34 CEST] <Fenrirthviti> but easily replicable [00:24:57 CEST] <Fenrirthviti> I appreciate the insight, I don't think it's a bug, I'm just trying to factfind so I can have the most informed conversation with them about it [00:25:14 CEST] <jkqxz> jamrial: What AV1 patches should I be looking at? [00:26:38 CEST] <jkqxz> jamrial: I also hacked in a way to do the parser change you suggested, but it's pretty horrible. I'll send it in a bit and you can see what you think. [00:27:49 CEST] <jamrial> jkqxz: the set i pinged during the weekend, starting with "add support for Padding OBUs" [00:28:30 CEST] <jamrial> also "fix range of allowed values for obu_type" which is not in that set [06:12:19 CEST] <cone-359> ffmpeg 03Steven Liu 07master:326cec3771f9: avformat/hls: make different warning message between open url and parse playlist [07:53:01 CEST] <cone-359> ffmpeg 03Karthick J 07master:3d0894990d17: avformat/movenc: Fix skip_trailer when global_sidx is enabled [07:53:02 CEST] <cone-359> ffmpeg 03Karthick J 07master:6aeaac3e1c40: avformat/dashenc: Add support for Global SIDX [15:57:41 CEST] <sasshka> hey people, ffmpeg fails to compile on power pc [15:57:45 CEST] <sasshka> it seems to fail only on LE [15:58:26 CEST] <JEEB> not many of us have access to those systems; do you know which the cross-compiler is that's required and which distros have it? [15:58:51 CEST] <sasshka> JEEB: I compiled on rhel [15:59:10 CEST] <sasshka> libswscale/ppc/swscale_vsx.c: In function yuv2rgb_full_1_vsx_template: [15:59:13 CEST] <sasshka> libswscale/ppc/swscale_vsx.c:527:9: error: invalid parameter combination for AltiVec intrinsic vy32_l = vec_mul(vy32_l, y_coeff); ^ [15:59:16 CEST] <sasshka> I can fix that [15:59:33 CEST] <JEEB> fedora seems to have something [15:59:34 CEST] <JEEB> ======================================================== Name & Summary Matched: ppc64le ======================================================== [15:59:37 CEST] <JEEB> gcc-ppc64le-linux-gnu.x86_64 : Cross-build binary utilities for ppc64le-linux-gnu [15:59:40 CEST] <JEEB> gcc-c++-ppc64le-linux-gnu.x86_64 : Cross-build binary utilities for ppc64le-linux-gnu [15:59:43 CEST] <JEEB> binutils-ppc64le-linux-gnu.x86_64 : Cross-build binary utilities for ppc64le-linux-gnu [16:00:00 CEST] <JEEB> sasshka: I think some Finn (?) recently changed that stuff, you should ping him [16:00:23 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=search;s=Lauri+Kasanen;st=author [16:00:38 CEST] <JEEB> at least that seems related [16:00:45 CEST] <sasshka> I see [16:00:59 CEST] <sasshka> I could just report it to bugzilla or I could fix that [16:01:06 CEST] <JEEB> so if you send out a patch you should CC that guy [16:01:06 CEST] <sasshka> let me know what you prefer [16:01:23 CEST] <JEEB> since he seems to be maintaining the VSX stuff [16:08:07 CEST] <sasshka> JEEB: I'll write to him [16:13:40 CEST] <durandal_1707> given set of 256 huffman code lengths - I want to write code which would generate all possible codes - how can i do that? [16:37:52 CEST] <cone-815> ffmpeg 03James Almer 07master:b74e13711ff6: avcodec/opus: make redundancy_buf 32 byte aligned [17:16:43 CEST] <j-b> heya [17:26:01 CEST] <sasshka> j-b: hello [17:26:09 CEST] <sasshka> j-b: any news about next VDD? [17:47:48 CEST] <cone-815> ffmpeg 03Matthew Fearnley 07master:5dcc63c1d2d9: libavcodec/zmbv: use PTRDIFF_SPECIFIER for `src - c->decomp_buf`. [17:47:49 CEST] <cone-815> ffmpeg 03Matthew Fearnley 07master:1046e880884b: libavcodec/zmbv: change 24-bit decoder channel order, from RGB24 to BGR24 [17:47:50 CEST] <cone-815> ffmpeg 03Matthew Fearnley 07master:b97a7dd03185: libavcodec/zmbvenc: add support for 24-bit encoding, using pix_fmt BGR24. [21:21:51 CEST] <durandal_1707> given set of 256 huffman code lengths - I want to write code which would generate all possible codes - how can i do that? [21:24:18 CEST] <durandal_1707> michaelni: know ^ answer? [21:28:13 CEST] <atomnuker> are you sure those are huffman codes you want? [21:28:25 CEST] <atomnuker> and not a golomb variant? [21:29:15 CEST] <durandal_1707> huffman, it is called in binary that way [21:29:52 CEST] <durandal_1707> binary have debug symbols [21:30:27 CEST] <atomnuker> you should really extract the codes themselves too, since all combinations of bits for 256 bit-long codes would be a universe-ending amount of data [21:32:49 CEST] <durandal_1707> bit lenghts are fixed, also i know first 8 bytes how it should look like when decoded [21:34:11 CEST] <durandal_1707> atomnuker: it is not 256! it is some special number that depends on highest coded bit length [21:34:42 CEST] <cone-185> ffmpeg 03James Almer 07master:461303f94ab6: avcodec/cbs_av1: fix parsing spatial_id [21:34:45 CEST] <atomnuker> you still need to know the input bits to make an output map, or at least how to create them [21:35:15 CEST] <durandal_1707> i know bit lenghts, that is enough info to create tree [21:35:50 CEST] <durandal_1707> canonical one does not work (inverted bits or not) [22:13:33 CEST] <kurosu> durandal_1707: do you have any idea if/when the tree building starts diverging from an optimal tree? or is the problem really that it is not canonical? because the remapping should be handled by sparse vlc init stuff (can't remember name) iirc [22:15:27 CEST] <atomnuker> the vlc system still needs input bit arrays, it can only do purely sequential (1,2,3) in non-sparse mode or any 16-bit int in sparse mode [22:17:45 CEST] <kurosu> sounds like a suboptimal tree is built - isn't magicyuv using one such or so? they trade off compression efficiency for decoding speed [23:05:10 CEST] <cone-185> ffmpeg 03James Almer 07release/4.1:ec82b3ecbbff: avcodec/cbs_av1: fix parsing spatial_id [00:00:00 CEST] --- Wed Apr 3 2019

1 0

ffmpeg.log.20190402
by burek 03 Apr '19

03 Apr '19

[00:08:51 CEST] <dipole> Hi! I'm trying to record 3 seconds of webcam with audio, but the following command just hangs after encoding the resulting video. If I interrupt it, I get my 3 second video [00:08:53 CEST] <dipole> ffmpeg -y -f alsa -ac 2 -i default -f video4linux2 -s vga -i /dev/video0 -c:v libx264 -t 3 /tmp/tmp19y9jqar.mp4 [00:09:10 CEST] <dipole> Any ideas how can I make this command not hang after it generated result? [00:11:26 CEST] <dipole> well, the problem is in this arguments: -f alsa -ac 2 -t 3 -i default [00:11:32 CEST] <dipole> if I remove it, the script works seamlessly [00:19:48 CEST] <dipole> what is pb? :) [00:21:24 CEST] <another> hmm.. seems to be broken. anyway, post your command output to some pastebin site [00:23:06 CEST] <dipole> ahh, https://pastebin.com/90Tk3GdX sure! [00:23:45 CEST] <dipole> (accidentally sent two commandline outputs, double Ctrl-C stops hanging ffmpeg [00:24:20 CEST] <dipole> also, while it hangs, it maxes the CPU [00:26:11 CEST] <another> hmm.. your alsa device looks wrong. have you looked at https://trac.ffmpeg.org/wiki/Capture/ALSA ? [00:27:31 CEST] <dipole> I have pulseaudio btw [00:28:51 CEST] <another> then maybe you should use -f pulse [00:30:04 CEST] <dipole> you are my hero!!! [00:31:17 CEST] <another> :) [03:16:43 CEST] <bray90820> The premium Tv service that was canceled was that the stuff that was on the OTA Tuners [08:53:31 CEST] <pk08> hi [08:53:49 CEST] <pk08> i want to output stream to udp multicast [08:54:19 CEST] <pk08> so by default what is the ttl of that multicast and how can i change in c program? [09:03:53 CEST] <JEEB> see the AVOptions of the UDP protocol [09:07:49 CEST] <pk08> thanks JEEB [09:08:09 CEST] <pk08> will this type of url work? url syntax: udp://host:port[?option=val...] [09:08:33 CEST] <JEEB> just use AVOptions [09:08:40 CEST] <pk08> ok, thank you [09:08:41 CEST] <JEEB> see the examples using av_dict [09:08:49 CEST] <JEEB> you set a key and a value :P [09:09:21 CEST] <JEEB> the UDP protocol does abuse URL options, but I don't recommend them unless required [09:12:31 CEST] <pk08> i will use av_dict option [09:13:11 CEST] <pk08> and i have to pass that option to avformat_init_output or avformat_write_header? [09:17:16 CEST] <JEEB> there's some examples under doc/examples [09:21:08 CEST] <pk08> thank you JEEB [13:27:24 CEST] <ehsanv> hi guys. i have a problem! i want to overlay my webcam on top of my desktop(making a screencapture with my video on it) and it works with ffmpeg. the problem is, i want to transparent it, and flip the camera verticaly, but when i use this code, it not works at all! [13:27:29 CEST] <ehsanv> ffmpeg -f dshow -i video="USB2.0 HD UVC WebCam":audio="Microphone (Realtek High Definition Audio)" -f gdigrab -i desktop -filter_complex "[0]geq='p(X,Y)'[a];[1][a]overlay=10:main_h-overlay_h-10" output.mp4 [13:29:01 CEST] <ehsanv> the [a] output is not show anything! but when use [0] instead of [a] on overlay input it works! [13:30:31 CEST] <ehsanv> P.S: sorry for posting command line here, pastebin is filtered for me, i'm from a sanctioned country, IRAN! [13:33:26 CEST] <durandal_1707> geq is extremly slow, why you use it at all? [13:34:26 CEST] <ehsanv> i'm newbie, any alternatives to suggest?! [13:34:38 CEST] <durandal_1707> vflip/hflip [13:34:47 CEST] <ehsanv> and for transparency? [13:35:02 CEST] <durandal_1707> what about it? [13:35:22 CEST] <thebombzen> overlay is fine if you're actually using it to overlay, which is what it appears you're doing [13:35:25 CEST] <ehsanv> i want to make whole picture semi transparent [13:35:48 CEST] <ehsanv> thanks durandal_1707 [13:35:59 CEST] <thebombzen> oh that, you want to set the alpha value to 0.5 [13:36:12 CEST] <ehsanv> yep [13:37:19 CEST] <thebombzen> try something like alphamerge. like: color=gray[alpha]; [input][alpha] alphamerge [output] [13:40:17 CEST] <ehsanv> thanks thebombzen, [13:40:25 CEST] <ehsanv> this command worked! [13:40:25 CEST] <ehsanv> ffmpeg -thread_queue_size 16 -f dshow -i video="USB2.0 HD UVC WebCam":audio="Microphone (Realtek High Definition Audio)" -f gdigrab -i desktop -filter_complex "color=gray:640x480[alpha];[0]hflip[a];[a][alpha]alphamerge[ao];[1][ao]overlay=10:main_h-overlay_h-10" output.mp4 [13:42:42 CEST] <ehsanv> i get the point! geq not worked because as durandal_1707 said, its slow and my webcam is a video stream and maybe the geq result isn't fast enough to sync with other inputs, so thats the problem. thank you both [14:37:25 CEST] <kubast2> Any of you know which audio codecs and containers does twitch.tv support? [14:39:43 CEST] <TheAMM> Isn't that better asked from Twitch? [14:40:05 CEST] <BtbN> h264 and aac [14:40:13 CEST] <BtbN> You stream to them via rtmp. That's it. [14:42:36 CEST] <kubast2> flv, h264 and aac [14:43:15 CEST] <BtbN> They will remux it though. The player never gets flv, it's all mpeg-ts [15:50:34 CEST] <MyStartx> Hello [15:53:25 CEST] <MyStartx> Guys how can i record just a terminal session in linux with ffmpeg? what input should i have in command line? thank you [15:53:57 CEST] <BtbN> script [15:58:08 CEST] <DHE> I assume he wants an x11grab that's single-window aware... [15:58:29 CEST] <MyStartx> yes..but i dont want all screen [15:58:44 CEST] <MyStartx> just onecterminal session [15:58:48 CEST] <pink_mist> that's what DHE meant by "single-window aware" [15:59:27 CEST] <DHE> ffmpeg -x $TOPLEFT_X -y $TOPLEFT_Y -s ${WIDTH}x${HEIGHT} -framerate 30 -f x11grab -i :0.0 [...] [15:59:40 CEST] <BtbN> I think the best you can do is query the region beforehand, so it won't track the window when you move it around [15:59:50 CEST] <DHE> realistically I would run a private X11 window (Xvnc is great for this) and record the whole screen anyway [16:00:20 CEST] <DHE> this would protect you against pop-ups, etc. [16:00:32 CEST] <BtbN> Don't you usually use Xephyr or something for thaT? [16:01:08 CEST] <DHE> umm.. not me. I thought xephyr was for hotseating [16:01:21 CEST] <BtbN> Xephyr is modern Xnest [16:01:29 CEST] <BtbN> Literally an X-Server in an X-Window [16:01:32 CEST] <DHE> oh... Xnest could work [16:01:37 CEST] <BtbN> Xnest is old and slow [16:01:39 CEST] <BtbN> use Xephyr [16:02:39 CEST] <DHE> that makes sense... [16:04:08 CEST] <mozzarella> please help me [16:04:11 CEST] <MyStartx> thank you guys [16:13:31 CEST] <Hello71> or just use script [19:54:41 CEST] <TheWild> hello [19:56:53 CEST] <TheWild> well, never mind. Tried concatenating two files losslessly, but just now I found out they use different codecs :/ [19:57:00 CEST] <Matttttt> Can anyone help me with an error, "dimensions not set" when trying to copy an HLS stream? [19:57:09 CEST] <Matttttt> https://pastebin.com/kNfMhfRq [21:31:07 CEST] <dawgly> Hello, does anyone know where I could learn the differences between huffyuv and v210 and which is better for capturing video using v4l2? [22:16:57 CEST] <rlot> Hi everyone. I'm streaming combined audio + video stream to youtube rtmp livestream. Is it possible to switch the input stream without killing the ffmpeg process? [22:17:25 CEST] <rlot> Do I need to use libav manually to achieve it? [22:18:45 CEST] <BtbN> No, ffmpeg can't do that. [22:18:56 CEST] <BtbN> You probably want to use OBS for dynamic live streams. [22:19:47 CEST] <rlot> Can't really use OBS because its supposed to be streamed from vps [22:19:54 CEST] <rlot> so no gpu [22:20:22 CEST] <BtbN> Probably have to roll your own software then, I'm not aware of anything headless that does that kind of stuff [22:21:46 CEST] <rlot> Hmm [22:22:34 CEST] <rlot> Or can I concat multiple of these streams before starting the transmission and use -stream_loop -1? [22:39:41 CEST] <bugre> Hi, i'm searching for a 'duration' limiter on `ffprobe`, to limit the probing of the stream to a specific time. Something similar as '-t' on the ffmpeg input, that limits the amount of time that is read from the input. I've searched the man and internet, but wasn't able to find an equivalent for ffprobe, but i'm probably looking at it from the wrong perspective. Would appreciate some itp/help if someone knows it. [22:40:51 CEST] <furq> bugre: analyzeduration/probesize [22:40:54 CEST] <faLUCE> bugre: did you try probesize? [22:41:06 CEST] <furq> although those are set by default unless you do something like -count_frames that requires decoding the whole stream [22:43:08 CEST] <bugre> thanks @furq and @faLUCE. I've not tried those options. Right now i've a script around the ffprobe that kills the command when desired time is reached. (it's something like: `fprobe -show_entries frame -select_streams V -print_format xml...`) [22:43:26 CEST] <bugre> I'll look into analyzeduration/probesize. [22:58:06 CEST] <bugre> @furq and @faLUCE, apparently the analyzeduration/probesize only affect the amount used to get the 'stream identified' and don't make the stream read operation stop, in my case, where i'm checking information on the frames itself. I've also tried the fpsprobesize, but not the expected result neither. [23:10:11 CEST] <faLUCE> bugre: do you want to stop ffprobe after getting these infos? [00:00:00 CEST] --- Wed Apr 3 2019

1 0

ffmpeg-devel.log.20190401
by burek 02 Apr '19

02 Apr '19

[00:25:55 CEST] <cone-843> ffmpeg 03Lynne 07master:0cea3ca8943b: opusdsp: create and move deemphasis and postfiltering from opus_celt [00:25:56 CEST] <cone-843> ffmpeg 03Lynne 07master:605e3303109e: x86/opusdsp: implement FMA3 accelerated postfilter and deemphasis [01:02:12 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/4.1:cb4768e7f20b: avcodec/truemotion2: Fix integer overflow in tm2_null_res_block() [01:02:13 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/4.1:ad0f4a7d10f9: avformat/mov: Fix potential integer overflow in entry check in mov_read_trun() [01:02:14 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/4.1:65f94b732a27: avcodec/mpegpicture: Check size of edge_emu_buffer [01:02:15 CEST] <cone-843> ffmpeg 03Carl Eugen Hoyos 07release/4.1:daca529112d8: lavc/bmp: Avoid a heap buffer overwrite for 1bpp input. [01:02:16 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/4.1:f1ecebcdb72b: avcodec/hevcdec: Avoid only partly skiping duplicate first slices [01:02:17 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/4.1:1d720b37f0f3: Update for 4.1.3 [01:17:03 CEST] <cone-843> ffmpeg 03James Almer 07master:27c94c57dc84: avformat/movenc: free eac3 private data only when closing the stream [01:22:39 CEST] <jamrial> michaelni: can i backport the above commit to the 4.1 branch, or are you in the middle of testing/tagging? [01:36:00 CEST] <michaelni> jamrial, feel free to back port, i intend to do the release after sleeping [01:36:09 CEST] <jamrial> ok, thanks [01:37:18 CEST] <cone-843> ffmpeg 03James Almer 07release/4.1:58cd70201edc: avformat/movenc: free eac3 private data only when closing the stream [02:21:01 CEST] <taliho> Hello, I'm running FATE regression tests, but have an error "Test api-seek failed. Look at tests/data/fate/api-seek.err for details." [02:22:03 CEST] <taliho> The error message in the file is "Can't open file". Do I have download any test files separately, or is there a ./configure option I missed? [02:23:11 CEST] <jamrial> taliho: make fate-rsync will download the required samples to the folder you defined during configure with the --samples= option [02:23:55 CEST] <jamrial> if you didn't use that option during configure, then just run make fate-rsync and make fate with the SAMPLES= option, set to the same folder [02:27:37 CEST] <taliho> thanks jamrial [10:32:24 CEST] <cone-536> ffmpeg 03Michael Niedermayer 07master:3a0ec1511e70: avcodec/rscc: Check that the to be uncompressed input is large enough [10:39:27 CEST] <cone-536> ffmpeg 03Gyan Doshi 07master:7f9a81b11056: doc/general: make column key note more verbose [11:41:13 CEST] <thardin> is anyone else getting NAB spam? [11:42:39 CEST] <JEEB> the one about getting user lists or something? yea [11:43:03 CEST] <thardin> I guess they farm the mailing list then [11:43:21 CEST] <kierank> thardin: yes a lot [11:43:24 CEST] <thardin> I got some IBC spam too, but I've been suspecting that's because it's linked to my old work email or something [11:43:45 CEST] <kierank> they farm MLs and ring me asking to speak to jdarnley_obs [11:43:51 CEST] <kierank> even though he has nothing to do with expos [11:44:11 CEST] <J_Darnley> :) my condolences [11:44:24 CEST] <thardin> heh [11:45:48 CEST] <thardin> on an unrelated note, does anyone in here have experience with aaf export in protools? [11:53:07 CEST] <BradleyS> thardin: maybe [11:53:27 CEST] <BradleyS> what's the issue [11:54:06 CEST] <thardin> it seems mute automation doesn't get exported, and I'm wondering if there's any case where it would [11:54:30 CEST] <thardin> while volume does get exported [11:54:40 CEST] <BradleyS> hmm, not sure about that [11:55:19 CEST] <BradleyS> noise gate instead? [11:55:36 CEST] <BradleyS> are volume envelopes exported? [11:56:34 CEST] <BradleyS> also, if you're not aware, this is very very useful software (no affiliation): https://www.aatranslator.com.au [11:56:56 CEST] <thardin> yeah, volume is exported [11:57:04 CEST] <thardin> like the control point stuff [11:58:01 CEST] <thardin> kAAFParameterDef_Amplitude [11:59:02 CEST] <thardin> bookmarking aatranslator, thanks for the tip [11:59:40 CEST] <BradleyS> looks like the mute automation is a known gray area [11:59:51 CEST] <BradleyS> if a track is fully muted it's omitted [12:00:21 CEST] <BradleyS> otherwise mute points can still be missing, advice is to use clip gain / volume envelopes instead [12:00:38 CEST] <thardin> yeah that's what I've gathered so far [12:00:43 CEST] <BradleyS> sucks [12:00:58 CEST] <thardin> could protools be scripted to convert mute automation to volume? [12:01:24 CEST] <BradleyS> good question, sadly i never used mute automation much [12:33:16 CEST] <cone-536> ffmpeg 03Michael Niedermayer 07release/4.1:6c75df556f8c: avcodec/rscc: Check that the to be uncompressed input is large enough [12:33:17 CEST] <cone-536> ffmpeg 03Michael Niedermayer 07release/4.1:4154f8967820: Changelog: update [13:24:31 CEST] <cone-536> ffmpeg 03Linjie Fu 07master:a8355eed3699: lavc/qsvenc: expose low_power as a common option for QSV encoder [13:24:32 CEST] <cone-536> ffmpeg 03Zhong Li 07master:d071a1117daf: lavc/qsvenc: get vps extradata from MSDK [13:59:39 CEST] <cone-536> ffmpeg 03Zhong Li 07n4.1.3:HEAD: lavc/qsvenc: get vps extradata from MSDK [14:28:34 CEST] <BBB> so are the matrox people just going to resubmit their patch in a new thread until we forget to say it's closed source software, and then quickly apply it and now it can't be removed anymore [14:29:02 CEST] <thardin> probably [14:29:56 CEST] <thardin> they didn't seem too receptive to the idea that they are, in fact, a hardware company [14:59:55 CEST] <kierank> thardin: the same with all of them [15:00:02 CEST] <kierank> software is just this annoying burden for them [15:01:08 CEST] <thardin> there's win-win potential there, if there were only willing to see it [15:02:18 CEST] <thardin> RE: maybe having a vote, that heliosvoting requires being used by either google or facebook [16:56:12 CEST] <cone-536> ffmpeg 03Lynne 07master:b43b8d337db0: x86/opusdsp: fix WIN64 return value [17:05:32 CEST] <thebombzen> I sent a patch to the mailing list last october, it had issues, and I resent the fixed version a few days later and didn't get a response. I resent the patch in January and also didn't get a response. should I send it again? I don't really want to spam [17:05:43 CEST] <thebombzen> this is the patch, FWIW: https://0x0.st/zXg0.patch [17:05:49 CEST] <JEEB> you should ping it [17:06:09 CEST] <JEEB> it's the ffmpeg.c frame rate for remux thing, right? [17:06:48 CEST] <thebombzen> yes [17:06:53 CEST] <thebombzen> so resend it again? [17:06:55 CEST] <JEEB> no [17:07:03 CEST] <JEEB> just reply to the thread with a ping [17:07:11 CEST] <thebombzen> wdym "a ping" [17:07:34 CEST] <thebombzen> unless you just mean "bump it" [17:07:56 CEST] <JEEB> literally that. "ping? requesting reviews because I feel like being able to set a frame rate when remuxing is worthwhile" [17:13:32 CEST] <thebombzen> done [19:59:18 CEST] <cone-536> ffmpeg 03Gyan Doshi 07master:8eca42e6320e: lavf/mov: skip extradata check in esds for MPEG-1/2 audio [20:04:17 CEST] <Fenrirthviti> Hey guys, does anyone know offhand of FFmpeg implements their own bitrate padding for NVENC CBR modes? [20:04:28 CEST] <Fenrirthviti> offhand if, that is. [20:05:41 CEST] <JEEB> I'd say no. the encoder should do any padding if it feels like it needs such :P [20:06:19 CEST] <Fenrirthviti> Trying to diagnose what's going on. Noticing some odd bitrate fluctuations with CBR where low/no-motion video the bitrate tanks. [20:06:54 CEST] <Fenrirthviti> I'm being told that this is expected by NVIDIA, but that seems... wrong for a CBR mode. [20:07:21 CEST] <Fenrirthviti> Was curious if anyone had run in to that before. [20:08:31 CEST] <Fenrirthviti> Found a post from BtbN back in 2014 that seems to corroborate that they don't use any kind of bitrate padding. Seems odd to call it CBR in that instance. Frustrating :\ [20:10:08 CEST] <nevcairiel> are you sure you a re setting cbr mode properly? In my recent tests, the bitrate is always spot on, in such a way that i can only achieve with padding in x264 etc [20:10:50 CEST] <Fenrirthviti> Yes, quite certain. It doesn't happen in situations with medium/high motion. [20:11:11 CEST] <Fenrirthviti> If you encode, say, a still image or extremely simple animation with very little motion [20:11:46 CEST] <Fenrirthviti> Bitrate will fall close to 0 [20:12:55 CEST] <Fenrirthviti> Context here is latest OBS Studio, with the nvenc update we did. Happens in FFmpeg as well with default options. [20:13:28 CEST] <Fenrirthviti> Just factfinding to see if I can get more details on what's going on. [20:55:28 CEST] <BtbN> nvenc does automatically insert padding in CBR mode [21:23:55 CEST] <Fenrirthviti> Hm, their engineers are saying they don't. [21:24:10 CEST] <Fenrirthviti> I'll check again. [00:00:00 CEST] --- Tue Apr 2 2019

1 0

ffmpeg.log.20190401
by burek 02 Apr '19

02 Apr '19

[01:41:15 CEST] <tomf> just stopped by to thank you for making FFMPEG! its amazing! :) [01:44:05 CEST] <hanetzer> yep, sure is :D [01:44:21 CEST] <hanetzer> I ran into an ipcamera which runs ffmpeg as a webassembly library/something [01:44:26 CEST] Action: hanetzer is not hip to webdev stuff [02:25:14 CEST] <Atlenohen> Hello [02:26:03 CEST] <Atlenohen> I'm trying to extract N frames per second for the enitire video, but the old commands don't work anymore, r 1 only ouptput 1 frame and can't do the rest [02:27:23 CEST] <Atlenohen> Use '-frames:v 1' for a single image, or '-update' option, or use a pattern such as %03d within the filename. [02:27:23 CEST] <Atlenohen> av_interleaved_write_frame(): Invalid argument [02:32:27 CEST] <faLUCE> Atlenohen: paste the command [02:35:27 CEST] <Atlenohen> faLUCE: I'm pretty sure it's quite old, ffmpeg -loglevel verbose -i "Temp3.mp4" -r 1 %03d.bmp [02:38:55 CEST] <Atlenohen> Could not get frame filename number 2 from pattern 'd.bmp'. [02:41:29 CEST] <faLUCE> Atlenohen: which version are you using? [02:41:47 CEST] <Atlenohen> not more than a few weeks old [02:42:43 CEST] <Atlenohen> ffmpeg version N-93276-g3b23eb283a Copyright (c) 2000-2019 the FFmpeg developers [02:42:43 CEST] <Atlenohen> built with gcc 8.2.1 (GCC) 20190212 [02:42:53 CEST] <Atlenohen> win64, zeranoe [02:43:09 CEST] <faLUCE> Atlenohen: it works for me [02:43:36 CEST] <faLUCE> Atlenohen: what if you use %03d.jpg ? [02:45:00 CEST] <faLUCE> Atlenohen: wait [02:45:04 CEST] <Atlenohen> nope [02:45:06 CEST] <faLUCE> I got you error [02:45:15 CEST] <Atlenohen> video is 30000/1001 fps [02:45:17 CEST] <faLUCE> you have to use ZERO, not "o" [02:45:30 CEST] <Atlenohen> it is a zero [02:45:30 CEST] <faLUCE> %03d.bmp [02:46:02 CEST] <faLUCE> and what if you add quotes? [02:46:23 CEST] <Atlenohen> Yes I tried many combinations nonthing worked [02:46:31 CEST] <faLUCE> "%03d.bmp" [02:47:14 CEST] <faLUCE> but how do you invoke ffmpeg? [02:47:35 CEST] <faLUCE> it's clearly a problem in the token %03d.bmp [02:47:48 CEST] <faLUCE> your env sends bad stuff to ffmpeg [02:48:02 CEST] <faLUCE> what do you use for invoking ffmpeg? [02:48:08 CEST] <faLUCE> a script or a terminal? [02:49:29 CEST] <Atlenohen> batch file [02:49:39 CEST] <Atlenohen> oh right, i should try tpying in cmd manually [02:49:44 CEST] <faLUCE> Atlenohen: then this is the problem [02:50:04 CEST] <Atlenohen> most tokens do work in batches tho [02:50:13 CEST] <faLUCE> surely you won't have manually [02:50:14 CEST] <Atlenohen> but sometimes they don't, yeah it happened before [02:51:02 CEST] <faLUCE> surely you won't have that problem if you invoke ffmpeg manually [02:51:54 CEST] <Atlenohen> oh yeah, i have ffmpeg in environmental variable, so ffmpeg.exe isn't in the same path the video file is [02:53:08 CEST] <Atlenohen> yeah it works now [02:53:23 CEST] <faLUCE> good [10:32:07 CEST] <thesero_> Hi. I am using ffmpeg 4.1.1 with frei0r plugins 1.6.1. Under Ubuntu 18.04 all goes right. When crosscompiling for Windows, using mingw-w64 7.3 posix, I have noticed that all plugins written in C work, while those writen in C++ don't. I tracked town the problem to vf_frei0r.c where dlopen in called with the path/name of the plugin dll, but the returned handle is null. Any idea why? [10:34:07 CEST] <thesero_> Configuration: ./configure --arch=x86_64 --target-os=mingw32 --cross-prefix=x86_64-w64-mingw32- --disable-doc --enable-nonfree --enable-gpl --enable-version3 --enable-static --disable-shared --enable-frei0r --extra-cflags='-I../frei0r/include -I/usr/local/include' --extra-ldflags="-static -static-libstdc++ -static-libgcc -Wl,-Bstatic /usr/local/lib/libdl.a" --extra-libs='-lstdc++ /usr/local/lib/libdl.a' [11:48:19 CEST] <BlackDalek> hi. Is it possible to use ffmpeg to add a timecode overlay onto en existing video file? [13:15:51 CEST] <tommy``> there is some gui for ffmpeg to do fast things for lazy people? i want 25fps-y an mkv removing audio [13:24:06 CEST] <HickHoward> are you in a hurry? [13:24:19 CEST] <tommy``> no lazy [13:54:48 CEST] <w1kl4s> tommy`` you can just write a script for that [13:55:05 CEST] <w1kl4s> pretty sure it will be easier for you in the future [13:55:15 CEST] <tommy``> w1kl4s you mean .bat? [13:55:42 CEST] <w1kl4s> yeah for wangblows that would be the shell script extension [13:56:18 CEST] <tommy``> wangblows? [13:56:28 CEST] <w1kl4s> winshit [13:56:46 CEST] <tommy``> mmh [13:56:54 CEST] <tommy``> could you show me some examples? [13:57:31 CEST] <w1kl4s> i have no idea how bat scripts work, i don't use windows [13:57:35 CEST] <w1kl4s> google it [13:57:39 CEST] <w1kl4s> shouldn't be hard [16:03:02 CEST] <thesero_> Hi. I am using ffmpeg 4.1.1 with frei0r plugins 1.6.1. Under Ubuntu 18.04 all goes right. When crosscompiling for Windows, using mingw-w64 7.3 posix, I have noticed that all plugins written in C work, while those writen in C++ don't. I tracked town the problem to vf_frei0r.c where dlopen in called with the path/name of the plugin dll, but the returned handle is null. Any idea why? [16:03:55 CEST] <bencoh> is everything crosscompiled with the same toolchain? [16:04:11 CEST] <thesero_> yes [16:05:07 CEST] <thesero_> someone tried today compiing on windows and send me the dlls. same issue [16:06:27 CEST] <thesero_> build config is: ./configure --arch=x86_64 --target-os=mingw32 --cross-prefix=x86_64-w64-mingw32- --disable-doc --enable-nonfree --enable-gpl --enable-version3 --enable-static --disable-shared --enable-frei0r --extra-cflags='-I../frei0r/include -I/usr/local/include' --extra-ldflags='-static -static-libstdc++ -static-libgcc' --extra-libs='-lstdc++ /usr/local/lib/libdl.a' [16:08:34 CEST] <BtbN> Using your systems libdl.a, which is in /usr/local even, seems wrong for cross compiling to Windows. [16:11:03 CEST] <thesero_> sorry that is in fact link to libdll.dll.a [16:11:23 CEST] <BtbN> And what and why is that? [16:11:51 CEST] <thesero_> because in ffmpeg configure ldl is required for building with --enable-frei0r [16:12:27 CEST] <thesero_> for manipulating dynamic library [16:12:40 CEST] <thesero_> dlopen/dlclose etc [16:13:17 CEST] <thesero_> basically the vf_frei0r in ffmpeg takes the plugin name as argument and then loads it's library dynamically [16:13:45 CEST] <thesero_> and it works [16:13:47 CEST] <JEEB> are the frei0r windows plugins built with MSVC or mingw-w64? [16:13:58 CEST] <JEEB> the C++ ones specifically since you mentioned they don't work [16:14:00 CEST] <thesero_> all mingw-w64 [16:14:11 CEST] <JEEB> ok, so in theory the C++ ABI should work [16:14:18 CEST] <JEEB> no idea what the ldl.a wrapper is though, unfortunately [16:14:20 CEST] <thesero_> well yes [16:14:29 CEST] <JEEB> if it comes from mingw-w64 or where [16:14:46 CEST] <BtbN> ffmpeg has its own little wrapper to offer the dlopen() API on Windows [16:14:58 CEST] <BtbN> using a library for that seems highly wrong and is probably what's breaking things. [16:15:18 CEST] <thesero_> oh, did not know... thhe complation was crashing without libdl [16:15:50 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=compat/w32dlfcn.h;h=c83bdc93… [16:16:47 CEST] <thesero_> oh, but then how would this resolve in config? "frei0r_filter_deps="frei0r libdl"" [16:17:06 CEST] <BtbN> That's wrong, it should use the ldl variable [16:17:19 CEST] <BtbN> And the code in that filter is also wrong, it directly includes dlfcn [16:17:37 CEST] <thesero_> well I saw this [16:17:39 CEST] <JEEB> tl;dr the filter was not reviewed enough [16:17:49 CEST] <JEEB> (nobody cared enough) [16:17:53 CEST] <thesero_> ok, however first time I included dlfcn directly [16:18:03 CEST] <JEEB> which is not surprising, frei0r is pretty minor [16:18:09 CEST] <JEEB> (not that it's a reason of course) [16:18:09 CEST] <BtbN> And it seems to have a hardcoded list of paths, which are all Linux-Only, where it searches for the library. [16:18:13 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/vf_frei0r.c;h=c7… [16:18:20 CEST] <thesero_> I know [16:18:24 CEST] <thesero_> saw the code [16:18:31 CEST] <thesero_> but got over that [16:18:46 CEST] <thesero_> except for C++ dll stuff [16:19:08 CEST] <BtbN> C++ DLL stuff? [16:19:28 CEST] <thesero_> I mean dlls coming from C++ classes [16:19:35 CEST] <thesero_> that would not load in ffmpeg [16:19:49 CEST] <thesero_> I mean in vvf_frei0r [16:19:51 CEST] <BtbN> The DLL has to offer a defined API, which is a C API. Doesn't matter if it's written in C++ or C [16:20:10 CEST] <thesero_> it is, and also exported [16:20:22 CEST] <BtbN> That's all there has to be [16:20:34 CEST] <BtbN> it's a dll, there is no reason to also make ffmpeg link anything extra [16:23:42 CEST] <thesero_> I have added some logs in the filter's code (vf_frei0r.c) and it seems that the handle to these kinds of dll is null after calling dlopen. [16:24:11 CEST] <thesero_> *handle_ptr = dlopen(path, RTLD_NOW|RTLD_LOCAL); [16:25:06 CEST] <thesero_> but I shall try with the ffmpeg's dl api [16:25:13 CEST] <thesero_> and see if it works [16:52:56 CEST] <tommy``> there is some ffmpeg plugin for adobe audition 3.0? [17:10:49 CEST] <zumba_ad_> I'm on mac and I installed ffmpeg using brew. I'd like to try stabilizing a video. When I ran it, I got this error message `[AVFilterGraph @ 0x7fabee18d580] No such filter: 'vidstabdetect'` [17:11:18 CEST] <JEEB> yours was built without that filter then [17:27:05 CEST] <zumba_ad_> Yup, I was hoping if someone here knows how to add that filter using brew. I can install ffmpeg from source but was hoping if it can be done quickly with brew [17:30:15 CEST] <zumba_ad_> https://gist.github.com/maxogden/43219d6dcb9006042849 [17:30:18 CEST] <zumba_ad_> uninstall now [17:34:19 CEST] <zumba_ad_> didn't work, parameter passed was invalid [17:51:03 CEST] <zumba_ad_> I can't use brew since `brew info ffmpeg` showed it does not have library anymore. I'll be installing from source. Any link that I should follow? I remember using a configure script and it had something to do with gpl or something [17:51:16 CEST] <zumba_ad_> it's been a while and I couldn't remember exactly what it was [17:52:49 CEST] <zumba_ad_> found it - `--enable-nonfree && \` [18:16:56 CEST] <faLUCE> hello retal ;-) [00:00:00 CEST] --- Tue Apr 2 2019

1 0

ffmpeg-devel.log.20190331
by burek 01 Apr '19

01 Apr '19

[10:50:28 CEST] <cone-584> ffmpeg 03Paul B Mahol 07master:4e8cbbf70e7a: avcodec: add Amuse Graphics decoder [11:41:56 CEST] <cone-584> ffmpeg 03Lauri Kasanen 07master:a6a31ca3d9af: swscale/ppc: VSX-optimize yuv2422_1 [11:41:57 CEST] <cone-584> ffmpeg 03Lauri Kasanen 07master:9a2db4dc61d0: swscale/ppc: VSX-optimize yuv2422_2 [11:41:58 CEST] <cone-584> ffmpeg 03Lauri Kasanen 07master:7adce3e64c6e: swscale/ppc: VSX-optimize yuv2422_X [12:13:54 CEST] <cone-584> ffmpeg 03Jun Zhao 07master:24dac56e1d8c: lavf/flvdec: add AMF date type support [12:13:55 CEST] <cone-584> ffmpeg 03Jun Zhao 07master:e995e2395b8f: lavf/flvdec: Cosmetics: Fix indentation for flv_read_packet [17:14:24 CEST] <thardin> I see kostya is working on a decoder for discworld noir's video format [17:15:15 CEST] <thardin> a game that's very tricky to get to run stably [18:43:11 CEST] <cone-392> ffmpeg 03Nick Renieris 07master:93748a2efa66: avcodec/tiff: Multi-page support [20:27:08 CEST] <durandal_1707> av1 is full of patents [20:27:29 CEST] <JEEB> everything is full of patents [20:28:56 CEST] <durandal_1707> except rawvideo [20:29:15 CEST] <JEEB> your colorspace is patented [20:29:21 CEST] <JEEB> so rawvideo is also patented [20:29:42 CEST] <durandal_1707> time to cry [20:57:59 CEST] <HickHoward> >av1 is full of patents [20:58:01 CEST] <HickHoward> :thinking: [23:26:48 CEST] <cone-843> ffmpeg 03Jun Li 07master:4f5e660e6954: avformat/doc, http, icecast, rtsp: Add option to disable send-expect-100 [23:26:48 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07master:468ae6a734b2: avcodec/proresdec2: decode picture header before frame allocation [23:26:48 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07master:c163e62db53d: avcodec/ivi: Factor ref_mb check out [23:26:48 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07master:111e9b0929ab: avcodec/ivi: fix indention for previous commit [23:26:48 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07master:4bf9561d63f3: avcodec/ivi: Mark band parameter as const [23:26:49 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07master:4eec0082599a: avcodec/ivi: Reduce dereferencing structs in inner loop of ivi_process_empty_tile() [23:48:49 CEST] <cone-843> ffmpeg 03Lynne 07master:4a2c65162029: x86/opus_dsp: rename to celt_pvq [23:48:50 CEST] <cone-843> ffmpeg 03Lynne 07master:5468c1d07516: celt_pvq_init: only build when CONFIG_OPUS_ENCODER is enabled [00:00:00 CEST] --- Mon Apr 1 2019

1 0

ffmpeg.log.20190331
by burek 01 Apr '19

01 Apr '19

[11:55:08 CEST] <clarkk> Are there any less cumbersome ways to specify time periods for filters? For example: [11:55:11 CEST] <clarkk> ffmpeg -i input.mp4 -af "volume=enable='between(t,56*60+12,56*60+14)':volume=0,volume=enable='between(t,56*60+20,56*60+22)':volume=0,volume=enable='between(t,56*60+24,56*60+27)':volume=0,volume=enable='between(t,56*60+30,56*60+37)':volume=0" -c:v copy output.mp4 [11:55:45 CEST] <clarkk> so, are there any alternatives to 56*60+12 etc? [22:10:05 CEST] <friendofafriend> Howdy. i'm using the h264_omx encoder on a Raspberry Pi to create an h264 stream. I'm piping the output of that into another instance of ffmpeg to create an MPEG-TS stream. The resulting stream plays very well, but I get "Invalid UE golomb code" error sometimes. Is there a flag I should try in ffmpeg to fix it? [22:51:00 CEST] <Ulrar> Hi, I have a line I use to convert to x265 which works okay : ffmpeg -i "${_file}" -vcodec hevc -preset medium -acodec aac new.mkv. The problem is that it only keeps one of the subtitles track, so I tried adding "-map 0:s? -c:s copy" to get them all but with that, if there are subtitle tracks, it ignores video and audio [22:51:19 CEST] <Ulrar> What would be the correct way to change my original line to also copy all subtitles tracks ? [22:51:26 CEST] <DHE> -map 0 # will fetch everything [22:54:08 CEST] <Ulrar> DHE: Excluding the non-converted audio and video tracks ? [22:54:44 CEST] <Ulrar> The goal here is to get all the subtitles, and still convert the video to x265 [22:55:44 CEST] <another> no. it just selects everything for conversion/copy [22:56:08 CEST] <Ulrar> I thought so, not what I'm looking for then [22:56:19 CEST] <DHE> I think you might want -c:s copy for thoroughness [22:56:19 CEST] <another> see also: https://ffmpeg.org/ffmpeg-all.html#Stream-selection [22:56:24 CEST] <DHE> wait, what am I missing then? [22:57:28 CEST] <Ulrar> DHE: I want to copy all subtitles as is, but convert the video to x265, not copy it [22:57:45 CEST] <Ulrar> Which is what my original line did, convert the video [22:57:48 CEST] <another> -map 0 -c:s copy -c:a aac -c:v hevc [22:58:12 CEST] <another> Ulrar: i think you misunderstood something [22:58:20 CEST] <Ulrar> ffmpeg -i "${_file}" -map 0 -c:s copy -c:a aac -c:v hevc -preset medium out.mkv [22:58:24 CEST] <Ulrar> Is that correct ? [22:58:32 CEST] <DHE> yes, that'll get you started [22:58:41 CEST] <Ulrar> Perfect, thanks [00:00:00 CEST] --- Mon Apr 1 2019

1 0