Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

August 2018

1 participants
60 discussions

ffmpeg-devel.log.20180825
by burek 26 Aug '18

26 Aug '18

[13:37:50 CEST] <durandal_1707> how should i name my blog site? [13:46:34 CEST] <thardin> I see kostay updated his blag [13:46:39 CEST] <thardin> kostya* [13:46:55 CEST] <thardin> https://codecs.multimedia.cx/2018/08/nihav-some-progress-to-report/ tl;dr rust still not as fast as c [13:47:35 CEST] <nevcairiel> all that safety doesnt come for free, shocker =p [13:49:47 CEST] <thardin> heh [13:54:34 CEST] <durandal_1707> huh, x262 still wants yasm [13:54:57 CEST] <JEEB> I don't think that branch was updated [13:55:04 CEST] <durandal_1707> since ages [13:55:12 CEST] <JEEB> yup [14:05:24 CEST] <durandal_1707> still uses old APIs [14:23:50 CEST] <durandal_1707> also really broken, mpeg mode causes SEGV here [14:26:48 CEST] <durandal_1707> disabling asm make it not crash [15:57:03 CEST] <kierank> durandal_1707: what command [15:57:39 CEST] <kierank> Shouldn't segfault afaik [16:01:12 CEST] <durandal_1707> kierank: ./x262 --mpeg -o out.264 ~/Videos/derf/akiyo_cif.y4m [16:01:41 CEST] <kierank> Yes that produces mpeg4 [16:01:46 CEST] <kierank> I want to produce mpeg2 [16:02:18 CEST] <kierank> iirc we had to make some breaking changes to h264 encoding [16:03:39 CEST] <durandal_1707> well, it is mpeg2(disabled asm): Stream #0:0: Video: mpeg2video (Main), yuv420p(tv, progressive), 352x288 [SAR 1:1 DAR 11:9], 29.97 fps, 29.97 tbr, 1200k tbn, 59.94 tbc [16:05:46 CEST] <kierank> Ok weird [16:10:39 CEST] <cone-283> ffmpeg 03Jun Zhao 07master:00286673d97c: doc/examples/hw_decode: re-licensed to MIT-license. [16:10:40 CEST] <cone-283> ffmpeg 03Jun Zhao 07master:5f090727adda: doc/examples/vaapi_encode: re-licensed to MIT-license. [16:10:41 CEST] <cone-283> ffmpeg 03Jun Zhao 07master:d6915d0d4510: doc/examples/vaapi_transcode: re-licensed to MIT-license. [17:08:00 CEST] <durandal_1707> finally configure fix [17:09:29 CEST] <JEEB> oh, avih posted his thing [17:11:50 CEST] <JEEB> but yea, if things still work for everyone then I must say that's a nice speed-up [17:12:36 CEST] <kierank> what is point of weird indentation rukes [17:26:58 CEST] <jamrial> "(...)commit XXX changed it to keep the first. This commit restores the original order due to *TBD*." [17:27:03 CEST] <jamrial> from one of those patches :p [17:27:53 CEST] <JEEB> yes, the e-mail notes that if the order matters there's a patch to get the pre-patchset order [17:28:03 CEST] <JEEB> and if it is not required then that patch doesn't have to be applied [17:28:19 CEST] <JEEB> pre-emptive posting [17:46:29 CEST] <kierank> michaelni: how can I submit a fate test [17:47:47 CEST] <kierank> michaelni: also are you going to commit your patch [17:56:51 CEST] <jamrial> kierank: if you mean a sample, just upload it somewhere, link it here, and i'll add it to the samples suite [17:57:35 CEST] <kierank> jamrial: thanks, I'm not fully sure how to add an mpeg4 fate test anyway [17:59:12 CEST] <jamrial> what is it meant to test? decoding bitexactness, frame/stream props? [17:59:30 CEST] <jamrial> look at other tests and basically just copy paste what they do [17:59:37 CEST] <kierank> mpeg4 only has vsynth I think [18:03:39 CEST] <kierank> jamrial: https://0x0.st/syD9.mkv --> can you call it mpeg4_sstp_dpcm.m4v [18:12:03 CEST] <jamrial> kierank: done [18:26:06 CEST] <michaelni> kierank, which patch do you want me to commit ? [18:26:27 CEST] <kierank> The one with the padding checks [18:26:32 CEST] <kierank> I think it's needed [18:30:45 CEST] <durandal_1707> that patch iirc just silences red text [18:31:11 CEST] <michaelni> kierank, will commit, thx for reminder [18:31:36 CEST] <cone-283> ffmpeg 03Timo Rothenpieler 07master:0c71c6d66f9a: avcodec/utils: document allocation requirement of extradata [18:31:43 CEST] <kierank> durandal_1707: dunno I don't want to try and understand that crazy code [18:37:44 CEST] <durandal_1707> i RE yet another screen capture codec, and whole algo is again in my head [18:43:09 CEST] <atomnuker> speaking of that, doesn't zlib do RLE anyway? [18:43:34 CEST] <durandal_1707> atomnuker: tell them [18:45:27 CEST] <kierank> durandal_1707: maybe you're right michaelni code is useless [18:49:33 CEST] <michaelni> without correct slice end detection error concealment will not function completely and there would be artifacts from the concealment code thinking that there is an error. If it does work without the patch then thats probably due to the EC code not being run [18:50:29 CEST] <kierank> durandal_1707: yes you are right patch is useless [18:50:43 CEST] <kierank> error concealment doesn't work in 10-bit mode anyway [18:50:46 CEST] <kierank> it's disabled for studio [18:51:01 CEST] <cone-283> ffmpeg 03Michael Niedermayer 07master:168d8d56bfb0: avcodec/mpeg4videodec: Fix slice end detection in mpeg4_decode_studio_mb() [18:54:35 CEST] <durandal_1707> bitpacked decoder is misplaced in libavcodec/alldecoders.c [18:57:31 CEST] <michaelni> it would make sense in principle to extend the EC code to support all variants the decoder supports [18:58:42 CEST] <kierank> that would require a 10-bit aware mpegvideoc [18:58:47 CEST] <kierank> which is a huge piece of work [19:03:16 CEST] <michaelni> the 10bit EC code could skip over the complex mpegvideo involving part and just do a simple memcpy from the previous frame where damage is found [19:03:41 CEST] <michaelni> i mean copy on a macroblock base not copy of the whole frame [19:06:11 CEST] <kierank> I wonder if i've been blocked by videolan git again [19:07:11 CEST] <kierank> ER needs a complete redesign [19:08:41 CEST] <kierank> durandal_1707: can you push my patch [19:08:45 CEST] <kierank> I think I am blocked again [19:09:02 CEST] <durandal_1707> im busy writing decoder [19:09:27 CEST] <durandal_1707> after i finish it [19:11:28 CEST] <kierank> ok [19:38:59 CEST] <cone-283> ffmpeg 03Rostislav Pehlivanov 07master:2e23cfbb4246: allcodecs: reorder ff_bitpacked_decoder [19:39:03 CEST] <atomnuker> durandal_1707: thanks for telling me, fixed [21:42:57 CEST] <JEEB> oh the 0p1pp1 guy rebased his stuff on top of 4.0.x [21:51:28 CEST] <cone-283> ffmpeg 03Michael Niedermayer 07master:acba153a1487: avcodec/snowdec: Fix integer overflow with motion vector residual [21:51:29 CEST] <cone-283> ffmpeg 03Michael Niedermayer 07master:1cbac9ce20d3: avcodec/vb: Check for end of bytestream before reading blocktype [21:51:30 CEST] <cone-283> ffmpeg 03Michael Niedermayer 07master:c9222b972d6c: avcodec/hq_hqa: Check remaining input bits in hqa_decode_mb() [21:51:31 CEST] <cone-283> ffmpeg 03Michael Niedermayer 07master:323095a6db67: avformat/mpegts: add missing null pointer checks in ff_parse_mpeg2_descriptor() [22:10:02 CEST] <cone-283> ffmpeg 03Kieran Kunhya 07master:844ff494696e: mpeg4video: Add Studio DPCM support [22:23:42 CEST] <durandal_1707> JEEB: who? [22:26:43 CEST] <JEEB> the guy who added DVB protocol and some other broadcast stuff [22:27:13 CEST] <JEEB> too bad his ISDB caption stuff requires the linuxtv custom iconv [22:27:31 CEST] <JEEB> the DVB and ISDB/ARIB caption text encodings didn't get merged upstream because they were not "major enough" [22:27:47 CEST] <JEEB> https://github.com/0p1pp1/FFmpeg/commits/isdb-4.0 [22:28:01 CEST] <JEEB> and then libaribb24 seemed to have issues with the license? [22:28:27 CEST] <JEEB> I wonder if that was ever fixed or is the best alternative to make libbroadcasttext or something to decode/encode DVB and ARIB text codings :P [22:28:38 CEST] <JEEB> since those iconv patches were clearly under LGPL or so [22:29:16 CEST] <durandal_1707> please review my mt prores decoder patch asap [22:30:35 CEST] <durandal_1707> and i still have no idea how to name blog [22:30:57 CEST] <JEEB> I don't see such a patch and I'm not sure if I'd even grasp it depending on the complexity [22:30:57 CEST] <atomnuker> JEEB: just implement in in lavu, I don't see an issue [22:31:27 CEST] <JEEB> atomnuker: yea that's another thing I thought of, but I wondered if people would go "ewwww broadcast text coding stuff in lavu" [22:31:29 CEST] <atomnuker> durandal_1707: name it - "The trials and tribulations of a XXX" [22:32:15 CEST] <atomnuker> JEEB: would it be possible to implement it in the demuxer instead? if its not going to be used elsewhere might as well [22:32:32 CEST] <durandal_1707> https://patchwork.ffmpeg.org/patch/10056/ [22:32:54 CEST] <JEEB> atomnuker: sure, the code could be pretty much everywhere. but the user would be both the demuxer as well as the subtitle decoder [22:33:10 CEST] <atomnuker> ah, right [22:33:11 CEST] <durandal_1707> atomnuker: trials? WTF [22:33:13 CEST] <JEEB> since ARIB captions as well as the broadcast metadata effectively utilize the ARIB caption text coding [22:33:23 CEST] <JEEB> they have a flag for UTF-8 but I've not seen that utilized in real life [22:33:26 CEST] <JEEB> seems like a theoretical flag [22:37:54 CEST] <atomnuker> JEEB: if you implement it as a .h file in lavc you can use it in both lavc and lavf [22:38:09 CEST] <atomnuker> its how some opus things are needed in mpegts.c [22:39:43 CEST] <JEEB> I will poke the aribb24 folk first because I'd really rather not start reimplementing it based on iconv stuff - although that way you'd also gain DVB text coding since the same guy implemented both the ARIB thing and the DVB one [22:40:47 CEST] <durandal_1707> >>>> https://patchwork.ffmpeg.org/patch/10056/ <<<< [22:43:30 CEST] <durandal_1707> blog name: Bink it! [23:02:08 CEST] <durandal_1707> bye [00:00:00 CEST] --- Sun Aug 26 2018

1 0

ffmpeg.log.20180825
by burek 26 Aug '18

26 Aug '18

[03:10:55 CEST] <Cracki> FishPencil, ask it [03:11:19 CEST] <Cracki> perhaps I'll direct you to a more fitting channel [04:14:06 CEST] <furq> is showwavespic on a 90 minute audio file supposed to use all my ram [04:14:10 CEST] <furq> because it does [04:16:52 CEST] <Cracki> I'm browsing https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/avf_showwaves.c [04:19:00 CEST] <Cracki> possibly it caches all samples relevant to the frame... [04:19:11 CEST] <Cracki> seems it was made for realtime display, so short windows [04:19:12 CEST] <furq> yeah that sounds like lavfi [14:42:05 CEST] <MrScoumoune> Hi how can i reencode a video for 720p, actualy i have try this but didn't work ffmpeg -i myvid.mp4(or other) -s hd720 -c:v libx264 -preset superfast -strict -2 myvid.mp4 [14:42:26 CEST] <MrScoumoune> i have multi format and other scale [14:52:56 CEST] <MrScoumoune> any have idea ? [15:04:08 CEST] <MrScoumoune> ffmpeg -i myvid.mp4(or other) -crf 18 -c:v libx264 -preset superfast -strict -2 myvid.mp4 [16:10:02 CEST] <_cfr> Hello, I'm trying to convert the audio track of .ts (mpegts) segments without changing their container (or video). I use -copyts -muxdelay 0 -max_delay 0 but at the ends of *some* segments, I can hear a weird cracking noise. Does anyone have any idea what can cause that or how to fix it? Thank you! [16:50:41 CEST] <pi--> On linux `apt install ffmpeg` gives 3.2.12-1~deb9u1, on OSX I have 4.0.1. [16:50:56 CEST] <pi--> Is there any particular reason? [16:51:08 CEST] <pi--> How to get the latest on Linux? [16:53:45 CEST] <JEEB> I mean, with debian/ubuntu you get the latest that was around a few months before the release of a distro [16:53:59 CEST] <JEEB> unless you're on the rolling version if they have one [16:54:10 CEST] <JEEB> for newer stuff you have to build yourself [16:54:15 CEST] <JEEB> also macos has no official packages [16:54:29 CEST] <JEEB> so that's just some rolling stuff made by whomever is maintaining homebrew [16:55:24 CEST] <DHE> that's what distros with fixed releases do. they have the version at the moment of the release (or more like slightly behind) and then pulling in fixes [16:55:44 CEST] <DHE> the idea is that scripts you write won't break from patching (even automatic patching) because of a version change [17:22:38 CEST] <st-gourichon-fid> Hello. I'm trying to figure out the importance of a "Non-monotonous DTS in output stream " when copying streams. [17:23:01 CEST] <st-gourichon-fid> I see in https://github.com/FFmpeg/FFmpeg/blob/b955a33314d4707f3c90c75d7c319d2020ec1… that it's in write_packet. [17:23:44 CEST] <st-gourichon-fid> pi--, have you read https://trac.ffmpeg.org/wiki/CompilationGuide#Linux ? [17:25:53 CEST] <st-gourichon-fid> I guess the "non-monotonous DTS" only affects a decoder, and perhaps even most modern decoder in PCs don't actually care? [17:26:54 CEST] <JEEB> it means whatever you're feeding has borked timestamps and the muxer might output garbage [17:27:13 CEST] <JEEB> and yes, unfortunately various stuff can read broken stuff [17:30:05 CEST] <st-gourichon-fid> Stream comes from an IP camera and appears to decode well. I guess it's those class of bugs that never get fixed because in most cases it doesn't cause too much damage? [17:36:25 CEST] <pi--> This is a weird problem. [17:36:55 CEST] <pi--> `ffmpeg -i $SRC_AUDIO -i $SRC_VIDEO -acodec aac -cutoff 22000 -vcodec copy -map 0:a:0 -map 1:v:0 -shortest -ab 384k $DST` [17:38:09 CEST] <pi--> In the ffmpeg output, [17:38:12 CEST] <pi--> Metadata: [17:38:12 CEST] <pi--> handler_name : VideoHandler [17:38:12 CEST] <pi--> File '/var/tmp/cue_embedder/2018-08-25--15-28-16--322216/merged.mp4' already exists. Overwrite ? [y/N] Not overwriting - exiting [17:38:47 CEST] <pi--> Now $DST a.k.a. '/var/tmp/cue_embedder/2018-08-25--15-28-16--322216/merged.mp4' doesn't exist before the call! [17:38:58 CEST] <pi--> Is this syntax somehow creating it twice? [17:39:11 CEST] <pi--> And maybe only doing it on old ffmpeg [18:34:21 CEST] <MrScoumoune> any know is it possible to convert is hd 720p ? i cant [18:54:10 CEST] <BtbN> What? [18:57:42 CEST] <DHE> you want to downscale a video to 720p? [19:44:14 CEST] <st-gourichon-fid> Do I understand right that DTS was introduced in older times (80s ?) where a decoder was dedicated hardware with tight constraints, thus the DTS field was important to tell it when to allocate resources to decoding, while current software play actually care about timestamps? [19:44:42 CEST] <st-gourichon-fid> Hm let's fix it [19:44:55 CEST] <st-gourichon-fid> Do I understand right that DTS was introduced in older times (80s ?) where a decoder was dedicated hardware with tight constraints, thus the DTS field was important to tell it when to allocate resources to decoding, while current software players actually don't care about timestamps, only presentation time stamp is important? [19:47:10 CEST] <kepstin> at the very least, modern decoders don't really care about dts as long as the frames are provided in dts order [20:07:51 CEST] <MrScoumoune> YEA [20:07:55 CEST] <MrScoumoune> i have try many cmd [20:07:58 CEST] <MrScoumoune> dont work [20:08:01 CEST] <MrScoumoune> properly [20:08:07 CEST] <MrScoumoune> ith scale kepping [20:08:35 CEST] <MrScoumoune> ffmpeg -i vid-2-R.mp4 -preset slow -codec:a aac -b:a 128k -map_metadata -1 -map 0 -codec:v libx264 -pix_fmt yuv420p -b:v 2500k -minrate 1500k -maxrate 4000k -bufsize 5000k -vf scale=-1:720 intro-720p.mp4 [20:08:38 CEST] <MrScoumoune> ffmpeg -i vid-2-R.mp4 -preset slow -codec:a libfdk_aac -b:a 128k -codec:v libx264 -pix_fmt yuv420p -b:v 2500k -minrate 1500k -maxrate 4000k -bufsize 5000k -vf scale=-1:720 intro-720p.mp4 [20:08:40 CEST] <MrScoumoune> and OTHER [20:09:01 CEST] <MrScoumoune> that work for 1 vids on 100. [21:09:54 CEST] <st-gourichon-fid> Complete message from FFmpeg about DTS suggests that it fixes DTS on-the-fly. This is a capture from IP camera. And indeed, playing the resulting capture file no longer show this message. [21:10:28 CEST] <st-gourichon-fid> If file appears to play okay, without artifact or out-of-order frames, I guess we can consider that the stream is fixed. What else can happen? [21:10:50 CEST] <st-gourichon-fid> "file" = the output of the FFmpeg instance that captured RTP and wrote a container file. [21:11:01 CEST] <JEEB> it 100% depends on the muxing code and if it does the right thing [21:11:05 CEST] <JEEB> (For your broken input) [21:11:17 CEST] <JEEB> and it might even depend on the muxer that gets fed with those broken timestamps [21:14:03 CEST] <st-gourichon-fid> Well, RTP feeds a broken feed to FFmpeg which says "Non-monotonous DTS in output stream 0:0; previous: 13712, current: 8932; changing to 13713. This may result in incorrect timestamps in the output file.". [21:14:16 CEST] <JEEB> yes [21:14:17 CEST] <st-gourichon-fid> Is it safe to add flag -fflags +igndts? [21:14:24 CEST] <JEEB> why would you even [21:14:41 CEST] <JEEB> just keep it in your mind that the input DTS goes bonkers [21:14:55 CEST] <st-gourichon-fid> Okay. I expect no actual trouble. [21:15:06 CEST] <JEEB> so you either fix it or know that with your exact set of paramaters it might be currently working out OK [21:15:36 CEST] <JEEB> (or there's a bug in the DTS reading code of FFmpeg, but I would be less surprised by the stream just being bonkers) [21:15:44 CEST] <JEEB> *of FFmpeg's RTP protocol thing [21:16:41 CEST] <st-gourichon-fid> Video will be reencoded later for playing to network clients. If the reencoder happens to be okay with the broken input stream, the output stream should be okay regarding DTS issue, right? I understood that PTS are important, and these don't cause issue in those streams. [21:17:04 CEST] <JEEB> I can't promise you anything really [21:17:13 CEST] <JEEB> if the +1 DTS is OK then things are OK, if it isn't then derp [21:17:23 CEST] <st-gourichon-fid> Okay, thanks. :-) [21:17:38 CEST] <st-gourichon-fid> I don't expect promises, rather things like "beware of case X and Y, there lie dragons". [21:19:33 CEST] <JEEB> also I hope you've checked if you actually get a PTS from the RTP stream itself [21:30:03 CEST] <st-gourichon-fid> I can check that. [21:30:42 CEST] <st-gourichon-fid> I have not checked in the stream itself, but I have observed some jitter in messages shown by FFmpeg during capture, so I guess this jitter comes from the PTS. [21:54:05 CEST] <st-gourichon-fid> Hmm, wireshark cannot tell. RTP timestamp is neither DTS nor PTS. These are buried in stream payload. [21:54:33 CEST] <JEEB> yea [21:54:47 CEST] <JEEB> I just took a look at rtpdec.c and it just calls per-format parsers [21:54:52 CEST] <JEEB> sounds like a "fun format" [21:57:24 CEST] <feedbackmonitor> Hey, I am working on a video recorded by my camera in h264 with MOV as a container. The majority of footage is at 60 fps but some was accidentally done at 24 fps so wanted to re-encode the 24 to match the project. Someone here suggested ffv1, but that output is just too large for my machine to handle. Is there a middle ground to better match the original footage sizes? [22:05:02 CEST] <atomnuker> rtp has a clock, and that's about all the procotol has, for dts you need more signalling provided by the payload [22:05:39 CEST] <st-gourichon-fid> Perhaps my DTS issue is just FFmpeg doing funny things from the RTP timestamps? From glance at wireshark capture, the RTP timestamp is monotonic. [23:11:22 CEST] <st-gourichon-fid> Strange behavior. [23:11:45 CEST] <st-gourichon-fid> A stream that plays fine with VLC and mplayer. [23:12:00 CEST] <st-gourichon-fid> ffplay plays it fine, too, but just does not stop at end. [23:12:17 CEST] <JEEB> if it's UDP the default for that is that there's no timeout [23:12:41 CEST] <st-gourichon-fid> Sorry, I mean playing the file after capture was completed. [23:12:56 CEST] <st-gourichon-fid> The file has a finite length but ffplay does not end after it played all file. [23:13:15 CEST] <st-gourichon-fid> For example, a 20 second file shows counter continuing: [23:13:17 CEST] <st-gourichon-fid> 63.07 A-V: -0.004 fd= 1 aq= 0KB vq= 0KB sq= 0B f=4/4 [23:13:34 CEST] <JEEB> file protocol last I knew should work unless you've enabled the follow stuff with a timeout of X seconds [23:14:22 CEST] <st-gourichon-fid> ffplay file://complete_path_ has same behaviour. [23:14:40 CEST] <st-gourichon-fid> "follow stuff" -> can't find info on the net. [23:15:56 CEST] <JEEB> well if you're not setting AVOptions for that it's not on by defualt :P [23:16:29 CEST] <JEEB> libavformat/file.c: { "follow", "Follow a file as it is being written", offsetof(FileContext, follow), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, [23:16:32 CEST] <JEEB> 1, AV_OPT_FLAG_DECODING_PARAM }, [23:17:33 CEST] <st-gourichon-fid> I don't want to follow (like unix tail command). [23:17:41 CEST] <JEEB> well as I said [23:17:44 CEST] <JEEB> it's not on by default :P [23:17:53 CEST] <st-gourichon-fid> Just observed that playing a random ogg file has same behavior: ffplay does not exit at end. [23:18:03 CEST] <JEEB> so it is very weird if a file doesn't EOF properly [23:18:23 CEST] <JEEB> I haven't seen the behavior in even very recent FFmpeg revisions with MPEG-TS input from a file, for example [23:18:31 CEST] <st-gourichon-fid> On Ubuntu 18.04 AMD64, version 7:3.4.4-0ubuntu0.18.0 [23:19:07 CEST] <JEEB> sorry, no idea. no reason for me to go back to anything that old [23:19:15 CEST] <st-gourichon-fid> Sorry :-) [23:19:16 CEST] <JEEB> although I've used versions from sept last year just fine too :P [23:19:34 CEST] <JEEB> the big zero != EOF change is from after 3.4, too [23:19:49 CEST] <JEEB> unless Ubuntu did like Arch and for some reason back-ported that change which then broke plenty of API clients [23:34:23 CEST] <st-gourichon-fid> Okay, let's assume that it's just my current FFmpeg binaries that smoke too much. [23:34:29 CEST] Action: st-gourichon-fid builds FFmpeg from git master [23:36:03 CEST] <JEEB> yeh, you can run the ffmpeg.c from the build dir just fine for decoding testing [23:36:10 CEST] <JEEB> `./ffmpeg -version` etc [23:36:27 CEST] <st-gourichon-fid> Yes [23:37:40 CEST] <st-gourichon-fid> Actually, I have made a script that automatically calls configure with arguments for automatic out-of-source build tree and install tree. Very easy. [23:37:44 CEST] <st-gourichon-fid> to use [23:38:44 CEST] <st-gourichon-fid> Same result. [23:39:13 CEST] <JEEB> would be interesting to see a sample of such, because I haven't seen file AVIO not sending the EOF signal [23:39:19 CEST] <JEEB> be it on windows or *nix [23:39:56 CEST] <JEEB> unless the file's duration is over 9000 and the player/decoder is trying to get to that point [23:40:06 CEST] <JEEB> can't do much more with just guessing, though :P [23:41:59 CEST] <st-gourichon-fid> Actually, any file I throw at ffplay does not end. [23:42:00 CEST] <st-gourichon-fid> E.g. [23:42:01 CEST] <st-gourichon-fid> wget -S https://upload.wikimedia.org/wikipedia/commons/7/79/Example_of_flats_in_mus… [23:44:52 CEST] <st-gourichon-fid> Will go to sleep. All this is on my dev machine. We might meet again if this causes trouble on the machine that will run ffmpeg for production. [23:46:32 CEST] <st-gourichon-fid> Thank you for all your feedback. :-) [00:00:00 CEST] --- Sun Aug 26 2018

1 0

ffmpeg-devel.log.20180824
by burek 25 Aug '18

25 Aug '18

[00:17:11 CEST] <atomnuker> bofh_: ping [05:02:58 CEST] <rcombs> anybody have the key for this 256-bit-encrypted ML post http://ffmpeg.org/pipermail/ffmpeg-devel/2018-August/233610.html [06:46:43 CEST] <cone-900> ffmpeg 03Gyan Doshi 07master:d0b48a960448: avdevice/decklink_enc: print preroll and buffer size [09:44:52 CEST] <JEEB> 741 [10:10:12 CEST] <kurosu___> durandal_1707: in your ut videodec patch, maybe define the macro to HAVE_FAST_64BITS [10:11:17 CEST] <kurosu___> I don't remember the impact of an the cached reader optimized for 32b, [10:12:16 CEST] <kurosu___> all the more since on utvideodec, it was on top of the dual vlc tables ported from huffyuvdec [10:15:28 CEST] <kurosu___> Regarding ffv2, I find the naming confusing: I wouldn't expect a lossy, spatial-transform based encoder, when the original ffv1 was like a lossless png on steroid [10:16:10 CEST] <kurosu___> And the very first ffv2 was trying to increase throughput by using multisymbol codewords iirc [10:16:59 CEST] <durandal_1707> kurosu___: when is fast_64 enabled? [10:17:49 CEST] <kurosu___> x86_64, but the issue is when a 32b arch actually splits 64b ops in 32b ones [10:18:54 CEST] <kurosu___> I don't know if arm64/v8/whatever it's called is both faster with the cached version and really uses 64b ops there [10:18:57 CEST] <durandal_1707> Carl tried patch with other popular arches and only x86_32 is worse [10:19:16 CEST] <kurosu___> libav probably did some test on arm64 [10:19:18 CEST] <kurosu___> Ok [10:19:52 CEST] <kurosu___> Anyway, this can be handled on a case by case, as the cached reader needs to be selectively enabled [10:21:14 CEST] <kurosu___> You could then maybe use !ARCH_X86_32 but that looks hackish [10:21:41 CEST] <kurosu___> (I mean, more than fast 64b, which is kind of a rationale by itself) [10:25:26 CEST] <kurosu___> Anyway I could put on some kind of pastebin some results for different things (optimized libav reader for 32b, dual vlc for various lossless decoders) [10:26:01 CEST] <kurosu___> Probably 2yo codebase not having the latest security fixes (like invalid vlcs etc) [10:36:54 CEST] <durandal_1707> libav doesn't use unchecked bit reader, so that should be looked into [10:40:04 CEST] <durandal_1707> what about this qp_table thing, - its deprecated and there is no alternative? [10:55:55 CEST] <kurosu___> Regarding bitstream reader, anyway, I recommend you read https://fgiesen.wordpress.com/2018/02/19/reading-bits-in-far-too-many-ways-… and followings [10:56:16 CEST] <kurosu___> You may recognize some of the 'tricks' in ffmpeg [10:59:26 CEST] <j-b> kierank: do you have DPCM samples? [10:59:46 CEST] <durandal_1707> kurosu___: using 25 (why 25 and not 23) bit reader is one of tricks? [10:59:58 CEST] <kierank> j-b: kind of [11:00:13 CEST] <nevcairiel> because 7 bits is the remaining room for one spill over byte [11:03:13 CEST] <kierank> j-b: there is one mxf sample that apparently has dpcm blocks but I can't see them. Then there is reference samples which I can decode one frame now but the rest doesn't decode because of impossible to understand moeg4video code [11:06:35 CEST] <durandal_1707> mpeg4video P frames code is trivial - piece of cake [11:10:43 CEST] <kierank> durandal_1707: for 10-bit? [11:10:59 CEST] <kierank> all the slice padding stuff doesn't work [11:11:04 CEST] <kierank> it just drops frames [11:11:10 CEST] <kierank> all sorts of insane mpegvideo.c magic in there [11:15:16 CEST] <durandal_1707> kierank: you already wrote some basic 10bit P parsing? [11:15:24 CEST] <kierank> no [11:15:34 CEST] <kierank> I am not working on theoretical code [11:16:10 CEST] <durandal_1707> wait, that DPCM stuidio files are I always? [11:16:23 CEST] <kierank> dunno, never looked at pframes [11:16:33 CEST] <kierank> I don't think they exist in reality [11:16:59 CEST] <durandal_1707> so samples you have are all I? [11:18:37 CEST] <kierank> real samples [11:18:38 CEST] <kierank> yes [11:19:40 CEST] <durandal_1707> kierank: link to files? [11:19:56 CEST] <kierank> https://trac.ffmpeg.org/ticket/4447 [11:21:07 CEST] <durandal_1707> kierank: those 3 files, I have already i think, where is calendar sample? [11:21:10 CEST] <kierank> also reference samples https://mpeg.chiariglione.org/standards/mpeg-4/conformance-testing [11:21:16 CEST] <kierank> can't remember which one [11:22:13 CEST] <BtbN> I'm really surprised carl didn't immediately close that one. [11:35:31 CEST] <durandal_1707> kierank: cant find it there [11:36:00 CEST] <kierank> standards.iso.org\ittf\PubliclyAvailableStandards\ISO_IEC_14496-4_2004_Conformance_Testing\video_conformance\studio [11:36:04 CEST] <kierank> there [11:36:09 CEST] <kierank> I think calendar one is 11 [11:53:39 CEST] <durandal_1707> 11, calendar ones decodes all frames just fine here [11:54:24 CEST] <kierank> durandal_1707: without patch? [11:54:41 CEST] <durandal_1707> kierank: with your patch obviously [11:54:49 CEST] <kierank> ffmpeg drops lots of frames for me [11:54:53 CEST] <kierank> it's a piece of crap [11:54:57 CEST] <kierank> so I dunno [11:54:59 CEST] <kierank> don't care [11:55:10 CEST] <kierank> not gonna spend time fixing mpeg4video monstrosiy [11:55:39 CEST] <durandal_1707> kierank: ffmpeg demuxes 6 frames only, is there more frames actually? [11:57:04 CEST] <kierank> proably [11:57:06 CEST] <kierank> I dunno [12:06:37 CEST] <BtbN> This guy... [12:09:21 CEST] <durandal_1707> BtbN: give him free support [12:09:36 CEST] <BtbN> I even told him what was wrong with his code. [12:10:28 CEST] <BtbN> hm, our trac is kinda in need of an update [12:11:56 CEST] <BradleyS> s/trac/honeypot/ [12:28:06 CEST] <durandal_1707> kierank: do you have specs for studio? [12:28:52 CEST] <durandal_1707> some files have P frames, but they came later and even first I frame somehow fails to decode for 6 sample [12:30:36 CEST] <durandal_1707> ^6th file [12:40:48 CEST] <kierank> durandal_1707: sent [12:59:39 CEST] <durandal_1707> kierank: vcon-stp6L1.bits first frame is fully DCT and it decodes noise [13:00:56 CEST] <cone-720> ffmpeg 03Carl Eugen Hoyos 07master:c2be3826200c: lavf/Makefile: Fix standalone compilation of the matroska and webm muxers. [13:01:29 CEST] <JEEB> ah, I was thinking of sending that patch (if that adds av1.o to the deps) [13:01:41 CEST] <JEEB> but great if someone was quicker [13:04:57 CEST] <kierank> durandal_1707: dunno, might use some features not seen before [13:13:04 CEST] <durandal_1707> kierank: macroblock_type vlc stuff is missing [13:36:12 CEST] <kierank> durandal_1707: really [13:37:23 CEST] <durandal_1707> for intra, one needs to check if remaining bit is 1 [13:48:46 CEST] <durandal_1707> if video height is not multiple of 16, how is it handled for DCT decoders? do i need to align height to 16? [13:49:38 CEST] <kierank> durandal_1707: so if it's not 1 then what do I do? [13:50:30 CEST] <durandal_1707> invalid for intra [13:51:28 CEST] <kierank> does that fix sample 6? [14:07:51 CEST] <durandal_1707> kierank: nope [16:49:17 CEST] <durandal_1707> i just RE another screen capture codec gem, it took me litteraly 15 minutes, and all algo is in my head [16:50:59 CEST] <atomnuker> hail to you, champion [16:52:11 CEST] <durandal_1707> zlib + rle on planar rgb vertically flipped [17:59:50 CEST] <MoSal> In libavcodec/utils.c line 2133 [18:00:05 CEST] <MoSal> av_freep(&codec->extradata); [18:00:44 CEST] <MoSal> what if codec->extradata is NULL? [18:00:55 CEST] <BtbN> nothing to free then? [18:01:23 CEST] <BtbN> freeing a NULL pointer is perfectly valid [18:04:47 CEST] <MoSal> BtbN: the NULL being codec->extradata not &codec->extradata, right? [18:05:02 CEST] <BtbN> &codec->extradata cannot be NULL. [18:05:31 CEST] <BtbN> The only problem would be if codec was [18:06:05 CEST] <JEEB> as long as the lavc helpers were used for the codec [18:07:49 CEST] <MoSal> BtbN: I traced the crash I mentioned here https://ffmpeg.org/pipermail/ffmpeg-devel/2018-August/233584.html to this [18:08:21 CEST] <JEEB> how does Firefox make that thing? [18:09:07 CEST] <MoSal> JEEB: don't know. [18:09:13 CEST] <MoSal> #0 0x0000000000406599 in () [18:09:15 CEST] <MoSal> #1 0x00007fc5b0dcdc76 in avcodec_parameters_to_context (codec=codec@entry=0x7fc5b226c800, par=0x7fc5b22997c0) [18:09:17 CEST] <MoSal> at libavcodec/utils.c:2133 [18:09:19 CEST] <MoSal> #2 0x00007fc5b095ceda in ff_decode_bsfs_init (avctx=avctx@entry=0x7fc5b226c800) at libavcodec/decode.c:284 [18:09:21 CEST] <MoSal> avci = 0x7fc5b224f100 [18:09:23 CEST] <MoSal> s = 0x7fc5b224f138 [18:09:25 CEST] <MoSal> bsfs_str = 0x7fc5b110d364 "" [18:09:25 CEST] <JEEB> (use a pastebin) [18:09:27 CEST] <MoSal> ret = <optimized out> [18:09:29 CEST] <MoSal> #3 0x00007fc5b0dcccf1 in avcodec_open2 (avctx=0x7fc5b226c800, codec=0x7fc5b1416880 <ff_aac_decoder>, options=0x0) [18:09:31 CEST] <MoSal> at libavcodec/utils.c:731 [18:09:31 CEST] <JEEB> or 0x0.st [18:09:33 CEST] <MoSal> ret = 0 [18:09:35 CEST] <MoSal> tmp = 0x0 [18:09:37 CEST] <MoSal> pixdesc = <optimized out>yTY [18:10:02 CEST] <MoSal> JEEB: figured it's short enough. won't do it again. [18:10:14 CEST] <nevcairiel> anything more then 3 lines isnt short :) [18:10:26 CEST] <JEEB> also that's a mess to read on my terminal IRC client [18:10:46 CEST] <BtbN> Line 2133 in utils.c in what commit? [18:11:07 CEST] <BtbN> That av_freep line is absolutely fine. [18:11:07 CEST] <MoSal> BtbN: c2be382620 [18:11:39 CEST] <nevcairiel> unless they manually allocate it with another allocation function [18:11:44 CEST] <nevcairiel> which would probably be bad API use [18:12:35 CEST] <JEEB> yea [18:12:41 CEST] <JEEB> that's what I meant. [18:12:51 CEST] <JEEB> or if nullptr gets through somewhere from the API client [18:17:43 CEST] <BtbN> The backtrace showing nothing is also very suspicious. It should jump into av_freep at the very least [18:17:54 CEST] <BtbN> Or is that just a macro? [18:22:48 CEST] <cone-094> ffmpeg 03James Almer 07master:3d2cf50ebbe2: avcodec/libopusenc: support encoding packets of sizes bigger than 60ms [18:22:49 CEST] <cone-094> ffmpeg 03James Almer 07master:7890181d7e76: avformat/movenc: support Opus packets with more than 60ms of audio when writing the Sample Group Description [18:22:50 CEST] <cone-094> ffmpeg 03James Almer 07master:701aca55fd11: avformat/flvdec: don't propagate empty extradata [18:23:55 CEST] <JEEB> can someone run FATE on https://patchwork.ffmpeg.org/patch/9836/ before I push it just in case? I don't have the full FATE set around [18:24:07 CEST] <JEEB> I should have changed all of the tests relevant to ismv/movenc [18:28:23 CEST] <jamrial> JEEB: sure [18:29:01 CEST] <JEEB> cheers [18:36:57 CEST] <atomnuker> durandal_1707: had some comments about the prosumer decoder [19:26:58 CEST] <MoSal> https://hg.mozilla.org/mozilla-central/file/tip/dom/media/platforms/ffmpeg/… [19:27:53 CEST] <MoSal> mExtraData is a ref-counted vector-like type. [19:28:23 CEST] <BtbN> So they clearly are putting something into that pointer that's not supposed to be there. [19:29:26 CEST] <MoSal> BtbN: Is it made clear that libavcodec own than data? [19:30:22 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/avcodec.h;h=31e50… [19:30:25 CEST] <BtbN> that depends [19:30:51 CEST] <BtbN> For decoding, which this clearly is, ffmpeg freeing it is a bug. [19:31:44 CEST] <MoSal> BtbN: this is indeed AAC decoding context. [19:35:51 CEST] <BtbN> I think I see what's going on. It's a copy & paste error. [19:36:08 CEST] <BtbN> All lines around line 2133 reference par->extradata [19:37:02 CEST] <BtbN> hm, no, that's not it [19:37:11 CEST] <BtbN> it overwrite the codec one [19:37:15 CEST] <BtbN> so it does right in freeing it [19:41:21 CEST] <MoSal> So, should I send a reply to the mailing list, or open an issue, or you got it from here? [19:42:30 CEST] <nevcairiel> i dont think its the only place where its assumed that extradata is allocated from av_malloc [19:42:51 CEST] <nevcairiel> for API safety firefox should change its code [19:43:20 CEST] <BtbN> https://bpaste.net/show/c7c10cc6e79e this should be the right approach [19:43:32 CEST] <nevcairiel> doubtful [19:43:34 CEST] <BtbN> as the doc clearly states that ffmpeg never touches it for decoders [19:43:36 CEST] <nevcairiel> bsfs dont run in front of encoders [19:44:01 CEST] <BtbN> But avcodec_parameters_to_context does? [19:44:31 CEST] <nevcairiel> if you call that function, it will modify the avctx [19:44:35 CEST] <nevcairiel> no matter what you do [19:44:56 CEST] <nevcairiel> thats its express purpose [19:45:14 CEST] <BtbN> Yes, but it's only documented to touch the extradata for encoders [19:45:18 CEST] <nevcairiel> no its not [19:45:30 CEST] <nevcairiel> that function is entirely independent of what the avctx contains [19:45:44 CEST] <BtbN> "- decoding: Set/allocated/freed by user." [19:45:45 CEST] <nevcairiel> it copies the entire continents of codecpar to avctx [19:45:51 CEST] <nevcairiel> contents* [19:45:57 CEST] <nevcairiel> no exceptions [19:46:16 CEST] <BtbN> Well, but it can't reasonably copy something it has no knowledge about how it was allocated [19:46:47 CEST] <nevcairiel> if you c hange that function as proposed, half of avcodec/ffmpeg will cease to function [19:46:55 CEST] <nevcairiel> and plenty user apps as well [19:47:15 CEST] <BtbN> hm, so only putting the free behind that is? [19:47:24 CEST] <BtbN> Is there a way to test if a pointer was allocated by us? [19:47:56 CEST] <BtbN> The immediate fix would be to not have extradata in codecpar [19:47:59 CEST] <nevcairiel> should just document that extradata should be allocated with av_malloc like many other fields in various structs [19:48:11 CEST] <nevcairiel> and where would that be then? [19:48:13 CEST] <nevcairiel> thats no fix [19:48:16 CEST] <nevcairiel> its a mandatory field [19:48:21 CEST] <nevcairiel> it needs to be there [19:49:26 CEST] <BtbN> Well, that mozilla code is setting it right on the context [19:49:50 CEST] <BtbN> Which is why it explodes in the first place, because it's about to be overwritten with whatever was set in codecpar [19:53:37 CEST] <BtbN> But yeah, the only safe and version-compatible way to fix this is Mozilla allocating the memory with av_malloc [19:53:40 CEST] <nevcairiel> the only future-proof solution is to j ust documented the requirement, because in reality it has practically been required in a wide number of cases already [19:55:44 CEST] <jamrial> JEEB: fate passes [19:56:05 CEST] <jamrial> sorry for the delay, i forgot i left it running [19:57:01 CEST] <JEEB> no problemos [19:57:17 CEST] <JEEB> I will push it then because it fixes an issue we've had with this thing for ages with regards to f.ex. B-frames [19:57:46 CEST] <JEEB> since it has no concept of edit lists + implementations always add the initial CTS offset to the fragment timestamp [19:58:01 CEST] <durandal_1707> atomnuker: i will not use for (int ...) hack [19:58:05 CEST] <JEEB> so you got delicious double b-frame A/V sync delay [20:02:21 CEST] <cone-094> ffmpeg 03Jan Ekström 07master:1931761f18cd: avformat/movenc: implicitly enable negative CTS offsets for ismv [20:02:30 CEST] <JEEB> there [20:02:44 CEST] <atomnuker> durandal_1707: not a hack, its valid c and saves lines [20:02:56 CEST] <atomnuker> and looks better [20:04:19 CEST] <durandal_1707> atomnuker: its a hack [20:06:55 CEST] <kierank> durandal_1707: what is [20:07:02 CEST] <kierank> I shall be the judge jury and executioner [20:07:37 CEST] <kierank> oh [20:07:39 CEST] <kierank> that's not a hack [20:07:40 CEST] <kierank> it's nie [20:07:43 CEST] <kierank> nice [20:07:48 CEST] <kierank> it keeps i in the right scope [20:25:20 CEST] <baptiste> JEEB, how is ctts version 1 support nowadays ? [20:26:34 CEST] <JEEB> baptiste: pretty much everything supports them since DASH IF etc recommend their usage [20:26:44 CEST] <JEEB> because everyone seems to hate edit lists [20:27:02 CEST] <JEEB> so if you can have CTS == DTS for initial sample, everyone seems to love that [20:27:29 CEST] <JEEB> in other words, anything that does web streaming with MPEG-DASH/fmp4 HLS better support it [20:28:51 CEST] <baptiste> yeah edit lists are not the best [20:29:08 CEST] <baptiste> but negative ctts, make pts < dns which is an abberation [20:29:45 CEST] <JEEB> yea, it's esp. fun when something takes in your negative cts offsets and muxes them straight into mpeg-ts [20:29:50 CEST] <JEEB> like apple seemingly did [20:30:00 CEST] <JEEB> https://kuroko.fushizen.eu/screenshots/apple_mpegts/nice_timestamps_there.p… [20:30:12 CEST] <JEEB> I complained to a vendor and they linked me this Apple HLS sample [20:30:36 CEST] <JEEB> "apple is doing this too so it's OK to do DTS > PTS in MPEG-TS [20:31:27 CEST] <JEEB> at which point I kind of wanted to laugh and cry, and decided that I'll get back to them later [20:31:28 CEST] <baptiste> humm that's weird [20:31:57 CEST] <baptiste> that's in clear violations of the specs [20:32:01 CEST] <JEEB> yes, yes it is [20:32:14 CEST] <JEEB> but it seems like various vendors that take in ISOBMFF with negative cts offsets (and recommend it, even) do this [20:32:27 CEST] <JEEB> when they re-multiplex to HLS [20:32:47 CEST] <baptiste> that's an oversight not supporting ctts version 1 and not offsetting dts/pts [20:32:52 CEST] <baptiste> and/or [20:33:01 CEST] <baptiste> Im sure apple can fix that [20:33:07 CEST] <baptiste> if asked nicely [20:33:22 CEST] <JEEB> basically people saw apple fucking it up around iOS 5 [20:33:27 CEST] <JEEB> in their samples [20:33:34 CEST] <JEEB> and decided that this was a-OK and kosher [20:34:31 CEST] <JEEB> but yea, lesson of the story is that you can't use the CTS/DTS values as-is from negative cts offset stuff [20:34:37 CEST] <baptiste> qq, do you remember where DASH-IF recommends ctts version 1 ? I might point to it in the future :) [20:34:42 CEST] <JEEB> sec [20:36:44 CEST] <JEEB> wbs also wrote it in the docs so it clearly was in there [20:37:21 CEST] <MoSal> https://bugzilla.mozilla.org/show_bug.cgi?id=1486080 [20:38:27 CEST] <JEEB> baptiste: at least 6.2.5.2 mentions > This requires the use of negative composition offsets [20:39:04 CEST] <JEEB> > It is strongly recommended that the presentation time offset at the start of each period coincide with the first frame of a segment [20:39:29 CEST] <JEEB> although I remember it being mentioned elsewhere as well [20:40:03 CEST] <baptiste> nice [20:44:38 CEST] <JEEB> MoSal: you can still own it and the user is allocating it, even if you have to utilize the lavc functionality to allocate it [20:48:31 CEST] <MoSal> JEEB: I will add a comment. Is this accurate: [20:48:33 CEST] <MoSal> To clarify, the user is still responsible for the data. But allocation/deallocation must be done using av_* functions. [21:23:58 CEST] <cone-094> ffmpeg 03Paul B Mahol 07master:aba720dce236: avcodec: add Brooktree ProSumer Video decoder [21:30:54 CEST] <atomnuker> durandal_1707: you put too many spaces on line 152 of prosumer.c, also you left a bunch of unsigned stuff, no shame in making a commit to fix that, it happens [21:40:33 CEST] <cone-094> ffmpeg 03Paul B Mahol 07master:4d87cd2882c0: avcodec/prosumer: fix some minor issues [22:09:08 CEST] <kurosu> durandal_1707, https://pastebin.com/JwXF4RaN [22:09:24 CEST] <kurosu> first column = codec, first row = implementation [22:09:34 CEST] <kurosu> m = master (of the time I did the test) [22:09:41 CEST] <kurosu> g = libav bitstream reader [22:10:07 CEST] <kurosu> f = g + 32bits cache and reader adaptation [22:10:44 CEST] <kurosu> prores needed more fixes at the time because of a function bent on reading 32 bits, which required more adaptation [22:12:00 CEST] <kurosu> got magicyuv down to ~3.3s using ffvhuff dual vlc tables [22:13:42 CEST] <durandal_1707> you can now fork [22:14:30 CEST] <durandal_1707> why dual vlc tables gives so big gain? [22:16:08 CEST] <kurosu> lots of small codewords, so you spend lots of time iterating bitstream reading [22:16:30 CEST] <kurosu> using dual tables, you can output 2 symbols at a time (or more...) [22:17:02 CEST] <kurosu> of course, if your source is very noisy and the shortest vlcs are very large, that doesn't work [22:17:55 CEST] <kurosu> also work in utvideo [22:18:15 CEST] <atomnuker> what does reader adaptation mean? [22:20:12 CEST] <kurosu> cache being 32bits, you need to refill it slightly differently [22:20:56 CEST] <kurosu> and there's benefit in having intermediate reader sizes if you know the max size of your codewords [22:21:08 CEST] <durandal_1707> so for x32 it is 32 and for x64 remain 64 bits? [22:21:16 CEST] <kurosu> with 64b cache and arithmetics, this is almost free [22:21:23 CEST] <kurosu> yeah [22:21:56 CEST] <kurosu> the issue of the cache reader with x32 is that it requires 64b arithmetics, which is split by the compiler in several 32b operations [22:22:11 CEST] <nevcairiel> one of the problems with the libav reader was that they also changed the API and re-defined it so that the short read could read more then a 32-bit cache driven API could really provide [22:22:13 CEST] <kurosu> and when you are already under reg pressure such as on x86_32... [22:22:25 CEST] <nevcairiel> but pauls version just changed the internals, so that was avoided [22:23:19 CEST] <kurosu> I don't remember if I was ricing or not concerning those 32b adaptations [22:23:46 CEST] <kurosu> I'm pretty sure some golomb reading function was not working with 32b cache [22:25:10 CEST] <kurosu> for prores, I moved to VLCs, but then atomnuker moved such code to byte-based reading in vc2 iirc [22:25:29 CEST] <kurosu> never tried to adapt this to prores, which iirc also use EG codes [22:26:51 CEST] <atomnuker> right, for dirac golomb reading you couldn't use the standard VLC reader so I nih'd a lut-based one [22:26:52 CEST] <kurosu> sad thing is that even 1GB of data takes only a few seconds to decode on 1 thread, once the data is in memory [22:27:57 CEST] <kurosu> (well it's good, but that means you are very sensitive to measure error and at some point this is the HD that limits decoding speed) [22:27:59 CEST] <atomnuker> the reason why you couldn't was because there are far too many codes, and they may be arbitrarily long, 64 bits+ [22:28:21 CEST] <kurosu> I think in prores the cases are far less frequent [22:28:33 CEST] <kurosu> iirc max of 29b [22:28:48 CEST] <kurosu> not guaranteed, but never encountered anything else [22:29:48 CEST] <kurosu> dct => max 12b coeffs (or 14?), and the golomb orders are fixed, so the theorical limit is probably close, but I never computed it [22:29:56 CEST] <kurosu> or I did, but I'm not sure [22:30:54 CEST] <kurosu> yeah, prores ac coeffs only need in 6 VLCs for the useful orders [22:31:26 CEST] <kurosu> probably some are indeed unusable, but those are very rare, so switching between VLC and current code is still a win [22:34:21 CEST] <atomnuker> nevcairiel: short read? [22:34:37 CEST] <kurosu> nevcairiel, yeah, I was more interested in proof of concept [22:34:42 CEST] <kurosu> atomnuker, <25 bits iirc [22:34:56 CEST] <nevcairiel> well thats not a problem this time around anyway [22:35:01 CEST] <nevcairiel> since we kept our API [22:35:24 CEST] <kurosu> (or 27) [22:35:46 CEST] <nevcairiel> its <= 25 right now iirc, and the libav version extended it to full 32 [22:36:15 CEST] <nevcairiel> but since we didnt go with that, only a historical comment [22:36:25 CEST] <kurosu> I think current solution is nice, as you can enable it on a case-by-case basis, which can include !ARCH_X86_32 [22:36:44 CEST] <kurosu> current=durandal_1707's [22:37:06 CEST] <nevcairiel> we always lobbyed for keeping the current ABI and just changing the internals, potentially macro controlled [22:37:11 CEST] <nevcairiel> but they didnt like that for reasons [22:37:14 CEST] <nevcairiel> API* [22:37:45 CEST] <atomnuker> I'd rather switch over fully to using the cached reader with the changes needed to make it fast on 32bits [22:38:45 CEST] <kurosu> I may have my share of bad communication on this topic, but I really felt down when I saw the topic change into "us vs them" [22:39:44 CEST] <kurosu> (or at least some people seemed to have behaved as if this was their perception of the discussion) [22:41:07 CEST] <atomnuker> I don't mind gradually enabling it on a case by case basis though, since it would be a lot of work to verify all codecs work [22:42:53 CEST] <durandal_1707> some codecs, like ffvhuff cant use it because it use pesky macros of old reader [22:43:45 CEST] <kurosu> yeah, I had extracted and converted its dual vlc table reading as a module for use by other codecs for that very reason [22:44:47 CEST] <durandal_1707> may I ask, how much do you ask for your troubles? [22:46:44 CEST] <kurosu> I did it knowing I couldn't publish them [22:47:14 CEST] <kurosu> trying to fix that, but that may take time or even never done [22:47:57 CEST] <kurosu> so here, I'm not selling anything, just discussing on a topic I personally like [22:48:31 CEST] <durandal_1707> you should sell, people sell even much less useful stuff [22:55:17 CEST] <atomnuker> but the most useful stuff they give away for free [22:56:15 CEST] <durandal_1707> like boring company flamethrowers [00:00:00 CEST] --- Sat Aug 25 2018

1 0

ffmpeg.log.20180824
by burek 25 Aug '18

25 Aug '18

[00:14:01 CEST] <feedbackmonitor> furq, So uhh, how big do you think this file is going to be. ffmpeg is still transcoding and the file is currently at 9.7 gb and the original size is 4.3 [00:48:04 CEST] <Cracki> qp 0 is for "lossless"? [00:48:15 CEST] <Cracki> expect an insane bitrate [00:48:20 CEST] <Cracki> what bitrate does it tell you atm? [00:48:57 CEST] <Cracki> why do you even transcode that stuff? it's h264 at 50 Mbit/s already [00:49:11 CEST] <Cracki> and I see no video filters... whyyyy [00:50:28 CEST] <Cracki> if your video editing program can't use mixed frame rates, CHUCK it in the trash bin [00:52:35 CEST] <feedbackmonitor> Cracki, Hey there [00:52:46 CEST] <feedbackmonitor> Cracki, Apparently it can, am not sure how [00:53:09 CEST] <feedbackmonitor> Cracki, I was just trying to make it easier, the whole work flow thingy [00:53:13 CEST] <Cracki> do not edit videos with blender. that's insane. [00:53:21 CEST] <Cracki> at least look at kdenlive [00:53:25 CEST] <feedbackmonitor> Cracki, I am insane in the membrane. [00:53:35 CEST] <feedbackmonitor> Cracki, Actually, it is not a bad editor [00:53:42 CEST] <Cracki> enough highlighting thx [00:54:22 CEST] <feedbackmonitor> highlighting? What is that? [00:55:22 CEST] <feedbackmonitor> Cracki, There are editors who work in TV studios who use Blender as a video editor and they have pythn scripts (which they share) to make workflow easier [00:55:36 CEST] <Cracki> "tv studios" [00:55:39 CEST] <feedbackmonitor> Plus there are some good tutorials [00:55:47 CEST] <feedbackmonitor> Cracki, hehehe [00:55:54 CEST] <Cracki> pls stop highlighting [00:56:09 CEST] <Cracki> and figure out how you can mix frame rates [00:56:17 CEST] <feedbackmonitor> Cracki, You need to explain, I am new to this channel [00:56:25 CEST] <Cracki> stop using my nickname [00:56:35 CEST] <feedbackmonitor> Cracki, I am not sure what you mean by highlighting [00:56:47 CEST] <feedbackmonitor> oh, why is that bad? [00:57:13 CEST] <Cracki> "highlighting" is one of the most common features on irc [00:57:37 CEST] <feedbackmonitor> Well, I mean no harm. [00:57:38 CEST] <Cracki> and when you repeatedly use my name, I repeatedly get audio alarm [00:58:02 CEST] <Cracki> there is no need for that [00:58:20 CEST] <feedbackmonitor> Cracki, My system has no such thing. I will make a note for your Nick [00:58:23 CEST] <feedbackmonitor> sorry [00:58:26 CEST] <feedbackmonitor> unintentional [00:58:31 CEST] <feedbackmonitor> whew [00:59:16 CEST] <Cracki> mentioning people's names is like tugging their pants leg [01:00:08 CEST] <feedbackmonitor> this is the first channel I encountered this in my years of usage of IRC, but that is okay. I aim to comply where applicable. [01:01:32 CEST] <Cracki> I think I remember you from some channel... [01:01:49 CEST] <feedbackmonitor> ? [01:01:56 CEST] <feedbackmonitor> What OS do you use? [01:02:34 CEST] <feedbackmonitor> I spend time in Blender, Blender VSE and assorted GNU?Linux distributions [01:03:01 CEST] <feedbackmonitor> Perhaps an opensource program like GIMP? Inkscape? Cinelerra? [01:03:42 CEST] <feedbackmonitor> Ardour? I am on there a lot [04:05:03 CEST] <FishPencil> If I have two images, is it possible to create a resulting image from only the identical pixels between them with FFmpeg? [04:12:45 CEST] <furq> FishPencil: -filter_complex blend=all_mode=xor [04:13:14 CEST] <furq> actually nvm that does the exact opposite [04:20:26 CEST] <furq> if you just want to see what the differences are then blend=all_mode=grainextract [04:20:35 CEST] <furq> but that doesn't pass through the original colours [04:33:45 CEST] <FishPencil> I want to see what the similarities are [09:33:09 CEST] <zyme> dumb re-encoding/transcoding with ffmpeg and target codec x264, whats the cli-syntax needed for lossless video output compared to source? [09:35:07 CEST] <zyme> I was told x264 has a lossless recording mode (Probably pairs well in a mkv with flac hehe) - so I'm assuming ffmpeg can do that - since it does just about everything anyway.. [09:35:26 CEST] <zyme> ilove11ven: hi [09:37:10 CEST] <ritsuka> lossless h.264 will take a lot more space than your input, if your input is already compressed [09:37:36 CEST] <zyme> I only need it temporarily for streaming purposes.. [09:38:00 CEST] <zyme> so as long as 1gbit is enough bandwidth.. [09:38:33 CEST] <ritsuka> http://trac.ffmpeg.org/wiki/Encode/H.264 [09:41:59 CEST] <zyme> I'm hoping that using a ssd for storing, and maybe cuda or one of the other hardware assists will be able to make it in a reasonable amount of time, perhaps even in evenly length chunks and streamed in succession so it starts quick, but I found the command to auto-do-that in the tmp files from videostream lol =) [10:01:52 CEST] <furq> zyme: streaming to what [10:09:30 CEST] <zyme> A ChromeCast Ultra, using a gbit via usb 2 wired Ethernet -- source PC on same switch (Airport Extreme [specs in case I need to id the rev: gbit router w/802.11n dual band, 60mhz wide channels for wifi @450mbit]) -- I just need to know what output format(s) it supports so I can see which ones I can use on the chromecast, unless it has the ability to use google cast naively like VLC can [except subs are broke]. [10:11:21 CEST] <furq> the chromecast won't be able to decode lossless h264 [10:11:49 CEST] <furq> lossless is always hi444pp and pretty much only software decoders can handle that [10:15:09 CEST] <furq> if you have an nvidia card then probably just use nvenc -preset slow -cq 10 [10:15:16 CEST] <furq> or some similarly low number for -cq [10:25:35 CEST] <zyme> It suppoerts Profiles up to level 5.1, hi Main and Main10. [10:26:52 CEST] <zyme> https://developers.google.com/cast/docs/media [10:31:07 CEST] <furq> yeah that doesn't include hi444p [10:31:16 CEST] <furq> also that's for hevc [10:31:48 CEST] <zyme> I did a general google search about hi444 and chromecast, seems it does support it [10:31:52 CEST] <furq> with that said, if this supports h264, hevc and vp9, why do you need to transcode [10:31:56 CEST] <zyme> though my TV probably doesn't [10:32:56 CEST] <furq> what your tv supports is irrelevant because the chromecast decodes it [10:33:04 CEST] <furq> but the chromecast definitely doesn't support hi444pp [10:34:13 CEST] <JEEB> not even nvidia itself decodes lossless (even though you can encode lossless even with 4:4:4 with it) :D [10:35:20 CEST] <zyme> It supports HDR and 4k res, I won't me using any HDR or above 1080p media.. [10:35:51 CEST] <JEEB> those have nothing to do with lossless coding [10:35:59 CEST] <furq> also it doesn't support hdr or 4k with h264 [10:36:03 CEST] <furq> that's just for hevc [10:36:13 CEST] <JEEB> a hw decoder with AVC supports most likely up to high profile, level 4.1 [10:36:15 CEST] <furq> but yeah, like i said, why do you need to transcode [10:36:29 CEST] <JEEB> a hw decoder with HEVC most likely supports up to main 10 profile, level 5 or something [10:36:31 CEST] <furq> JEEB: the page he just linked says high:4.1, so yeah [10:36:33 CEST] <furq> @ [10:36:43 CEST] <zyme> Inserting image based subs primarily [10:37:20 CEST] <zyme> but also I'm trying to reduce multiple transcoding degradation [10:37:51 CEST] <furq> just throw a lot of rate at it [10:39:55 CEST] <furq> JEEB: does lossless hevc require some fancy profile [10:40:30 CEST] <furq> apparently pascal nvenc does lossless but i'm guessing it requires main444 or something that'll make it not work here [10:42:03 CEST] <JEEB> I would expect the same they do with AVC [10:42:06 CEST] <JEEB> you can do lossless encoding [10:42:08 CEST] <JEEB> but not decoding [10:45:21 CEST] <zyme> I think google cast requires yuv420p [10:45:50 CEST] <zyme> if I'm starting to understand whatcolor modes are correctly that is.. [10:47:32 CEST] <JEEB> 4:2:0 yes, but the main thing is to also not use profiles/features not supported [10:47:39 CEST] <zyme> is there a way to make only the color mode lossy? [10:47:55 CEST] <JEEB> (lossless AVC is always high 4:4:4 whatever profile, even if 4:2:0) [10:48:05 CEST] <JEEB> zyme: you cannot do lossless coding with hw decoders. QED [10:48:14 CEST] <JEEB> be it lossless 4:2:0 or lossless 4:4:4 [10:48:16 CEST] <JEEB> or 4:2:2 [10:48:26 CEST] <JEEB> it's just not supported even if in theory they could support it [10:48:42 CEST] <JEEB> use a low enough CRF/quantizer [10:52:21 CEST] <zyme> Then can I set a the max bitrate to something like 100MB/s with a variable output bitrate so it uses less if possible, like say on frames that are just 100% black for example (I imagine that ex. compresses well) [10:52:43 CEST] <JEEB> what I noted should do for you [10:53:13 CEST] <JEEB> x264 has CRF, and I think those pesky hw encoders have quantizer settings [10:57:29 CEST] <zyme> eh, I guess, I just hate CRF, most of the time I'd be okay with 10x the output size as long as the quality was better - but CRF has to combine the speed and quality with the same cli-argument [10:57:49 CEST] <JEEB> no [10:57:54 CEST] <JEEB> CRF is only quality [10:58:02 CEST] <JEEB> it's a variable quantizer depending on the complexity and some others [10:58:07 CEST] <JEEB> it has zero % to do with *speed* [10:58:56 CEST] <zyme> "(CRF) is the default quality (and rate control) setting for the x264 and x265 encoders. You can set the values between 0 and 51, where lower values would result in better quality, at the expense of higher file sizes. Higher values mean more compression, but at some point you will notice the quality degradation." [10:59:25 CEST] <JEEB> yes, nothing does it say anything about speed [10:59:31 CEST] <JEEB> it is rate control [10:59:40 CEST] <JEEB> it's like quantizer, except dynamic [10:59:50 CEST] <furq> zyme: do you have an nvidia card in the pc you're streaming from [10:59:51 CEST] <zyme> rate means speed in rl english lol [11:00:03 CEST] <JEEB> rate of bits [11:00:09 CEST] <JEEB> so amount/speed of bits per second [11:00:14 CEST] <JEEB> as opposed to rate of the encoder [11:00:26 CEST] <JEEB> bit rate | rate of bits [11:00:33 CEST] <JEEB> so rate control :P [11:01:02 CEST] <zyme> and an upscaled unfiltered output needs to read faster if the rate is higher.. [11:01:28 CEST] <JEEB> you've lost me [11:01:43 CEST] <JEEB> yes, *any* rate control if it uses more bits will cause more bits to be written [11:01:54 CEST] <JEEB> and thus the decoder has to be able to read more bits when decoding [11:02:10 CEST] <JEEB> that's unreltaed 100% ot the actual rate control mode used [11:02:42 CEST] <furq> lower crf values will be marginally slower [11:02:51 CEST] <JEEB> that's unrelated to *CRF* [11:02:51 CEST] <furq> but it's very little compared to changing preset [11:02:55 CEST] <furq> true [11:03:03 CEST] <JEEB> since you're writing more bits it takes longer [11:03:05 CEST] <zyme> I wish the amount of quality output wasn't controlled by the same setting as bitrate, ie the reverse of higher quality compresson, think less compression same quality.. [11:03:14 CEST] <furq> zyme: it isn't [11:03:33 CEST] <JEEB> ok, so what was meant is [11:03:41 CEST] <JEEB> CRF higher => encoder tries to compress more [11:03:46 CEST] <furq> also as i said you shouldn't use x264 for this if you can avoid it [11:03:47 CEST] <JEEB> CRF lower => encoder tries to compress less [11:04:05 CEST] <JEEB> and that leads to smaller/bigger file sizes [11:04:19 CEST] <JEEB> it only controls quality within specific parameters [11:04:31 CEST] <furq> "compress more" in the sense that it will discard more information [11:04:44 CEST] <JEEB> yes, it will use higher quantizers [11:04:50 CEST] <furq> not that it will try harder to keep information, which is the thing that takes time [11:04:54 CEST] <JEEB> yes [11:04:59 CEST] <JEEB> that is controlled by presets [11:05:02 CEST] <furq> right [11:05:14 CEST] <JEEB> the algorithms in the back are controlled by presets, and then the quantizer range is controlled by rate control [11:06:54 CEST] <zyme> the point has always been: I want to compress less for my output. what setting can I change to make two transcodes of a video file that should be identical in quality but largely different in size? [11:07:59 CEST] <JEEB> you just set your preset to be much faster [11:08:12 CEST] <JEEB> although technically CRF values are not the same across presets [11:08:22 CEST] <JEEB> because what the encoder "sees" depends on the presets [11:08:31 CEST] <JEEB> and thus the algorithms of rate control work on different stuff [11:08:40 CEST] <JEEB> so in theory to hit the same quality you have to tweak both :P [11:08:53 CEST] <JEEB> but veerry simplified you just tweak the preset until you're fast enough [11:09:05 CEST] <JEEB> and then you tweak your CRF value for your required quality level [11:09:54 CEST] <zyme> so if CRF is 51 (highest - am I right?) and the preset is changed then the outputs should be visibly identical? [11:10:13 CEST] <furq> if the crf is 1 [11:10:42 CEST] <JEEB> zyme: technically since what CRF "sees" is different between presets you cannot expect the CRF value's results to be the same, but generally speaking they should be *similar* [11:10:49 CEST] <zyme> and superfast or veryfast, etc are the different preset speeds? [11:10:52 CEST] <furq> yes [11:11:02 CEST] <furq> also yeah they won't be identical but you will not be able to spot the difference [11:11:11 CEST] <furq> honestly you won't be able to see any difference at crf 15 [11:11:22 CEST] <furq> but since this is streaming over a lan then you might as well go nuts [11:11:48 CEST] <JEEB> basically I always drive the point home because people tend send out question marks as they go slower and slower in presets and around slow-placebo you actually get *larger* files from the same CRF [11:11:54 CEST] <JEEB> because the encoder is seeing more and more stuff [11:11:57 CEST] <zyme> so we're at about 98 or <99% the same? [11:12:47 CEST] <JEEB> "depends" is the 100% correct answer [11:13:06 CEST] <JEEB> but generally speaking you are in the very similar ballpark [11:13:12 CEST] <JEEB> but it's generally just simpler if you first tweak the speed [11:13:14 CEST] <JEEB> and then your CRF [11:13:19 CEST] <JEEB> then you have it all set up :P [11:13:48 CEST] <zyme> if I'm using the fastest setting should I just use HEVC, or will it still take a very long time even on the fastest setting? [11:15:50 CEST] <JEEB> I have no idea hwich encoder you're taling about anyways [11:16:15 CEST] <zyme> originally I was talking about x264 [11:16:25 CEST] <JEEB> (and I have no idea of the speed or quality of x265's fastest presets) [11:16:31 CEST] <JEEB> x264 is much more of a known quantity [11:16:52 CEST] <zyme> but that was before I found out that 265 supported lossless as well, which I'd been told before it didn'y [11:17:04 CEST] <JEEB> oh it did support, but your clients don't [11:17:17 CEST] <JEEB> so even if you did lossless encode it doesn't help much if your client can't habla espanol [11:18:29 CEST] <zyme> other than the color mode I thought it would? was the impression I was getting.. [11:19:39 CEST] <zyme> it supports HDR, Level 5.1, Main10, 4k res, hevc decoding, etc..etc.. (I'm a little confused as to what the level #'s are though lol) [11:19:44 CEST] <kerio> is lossless h264/h265 supported by anything other than ffmpeg? [11:20:28 CEST] <kerio> cuz sure as shit quicktime doesn't support it [11:22:23 CEST] <zyme> "Constant Rate Factor. Determines output quality. 0 is lossless, 23 is default, and 51(8-bit x264) or 63(10-bit x264) is worst possible. Increasing the CRF value +6 is roughly half the bitrate while -6 is roughly twice the bitrate." [11:22:43 CEST] <zyme> from some page called ffmpeg tricks [11:27:03 CEST] <JEEB> zyme: profiles = features, levels = memory requirement from the decoder [11:27:27 CEST] <kerio> a hardware decoder will support certain combinations of profiles and levels [11:27:55 CEST] <JEEB> so levels control resolution and how many references (and bit rate in theory) [11:28:00 CEST] <kerio> ffmpeg don't care, ffmpeg don't give a fuck [11:28:13 CEST] <JEEB> and profiles control features [11:29:20 CEST] <JEEB> for example in AVC the features basically go up: constrained baseline < main < high < { all of those "high xxx" profiles, up to high 4:4:4 whatever it was } [11:29:50 CEST] <JEEB> with HEVC it's main < main 10 < { all of those "main XXX" profiles } [11:36:52 CEST] <zyme> how does main 10 compare to levels, as its always listed in place of a levels number in mediainfo? [11:38:49 CEST] <JEEB> levels are compltely separate, levels are in both AVC and HEVC [11:39:07 CEST] <JEEB> they're orthogonal [11:39:09 CEST] <zyme> if I use a lower level then with crf at 1 for example, then that should also speed up the encoding and be similar quality no? [11:39:35 CEST] <zyme> or at least with 0 for lossless is should be different bitrates same output [11:41:21 CEST] <zyme> https://usercontent.irccloud-cdn.com/file/2BbjncZr/Color%20doesn't%20matter%20for%20lossless%20output.png [11:42:37 CEST] <zyme> So I can make a lossless transcode after-all, it doesn't matter that my Chromecast doesn't support hi444 [11:43:08 CEST] <JEEB> I thought I mentioned this already if you read back through what I've noted [11:43:15 CEST] <JEEB> but lossless coding is limited to that profile as a feature [11:43:24 CEST] <JEEB> so ALL LOSSLESS SHIT WILL BE High 4:4:4 blah profile [11:43:40 CEST] <JEEB> and as I've noted UMPTEEN TIMES ALREADY lossless is not supported on hw decoders [11:43:42 CEST] <JEEB> for eff's sake [11:44:40 CEST] <durandal_1707> but can I play 8k with PotPlayer ? [13:58:17 CEST] <Cracki> wat does that mean [14:08:22 CEST] <durandal_1707> Cracki: what? [14:14:42 CEST] <occivink> hey, maybe a silly question but how does licensing work when using distribution versions. Let's say I create an executable that I dynamically linked against an LGPL-compliant build of ffmpeg. Then, I distribute a package containing the executable but not the LGPL-ffmpeg, instead it specifies to use the system version (which happened to be built with --enable-gpl). Is my executable now GPL? If yes, do I need [14:14:44 CEST] <occivink> to package my own LGPL-ffmpeg to stay compliant? [14:18:02 CEST] <JEEB> IANAL, but if you expect and cannot work without GPL features there might be some reason to think you are basing on a GPL configuration. But if you don't, and you don't distribute FFmpeg itself then you're basing on LGPL FFmpeg [14:28:06 CEST] <occivink> uh okay, and if it's just some optional feature? e.g. h264 encoding is possible, and it might use libx264 if present [14:28:52 CEST] <JEEB> as long as the binary does not expect to have libx264 there I'd say it's OK [14:30:13 CEST] <JEEB> hmm, I wonder if you can give a format name to -encoders or something [14:32:05 CEST] <occivink> avcodec_find_encoder only takes a codec id at least, not a specific encoder name [14:32:35 CEST] <occivink> but this seems like a "loophole" to me, at least in the spirit of the gpl [14:36:11 CEST] <JEEB> there's another API to request specific encoders [14:36:29 CEST] <JEEB> avcodec_find_encoder_by_name [14:37:35 CEST] <occivink> right [14:37:39 CEST] <zyme> My laptop kept BSOD'ing every time I opened chrome... This has happened a few times the past week, ever since I enabled Intels HD4400 iGPU to work with my nvidia card thinking gpu offloading would be split between the gpus... [14:38:15 CEST] <kepstin> zyme: that sounds like a windows driver bug completely unrelated to ffmpeg... [14:38:36 CEST] <zyme> I think Chrome defaults to the intel, possibly because theres more feature support compared to my NVS Fermi [14:39:21 CEST] <zyme> it is unrelated, except that I had 2 or 3 sentences I was about to hit enter on, now I've forgotten [14:42:46 CEST] <zyme> something about testing things to see what happens when using something in a way not intended is the best form of discovery, its just to bad all non-system code can't be executed like a vbs file with "On Error Resume next" -> although for video formats spoofing the details can usually make a non-compatible video play will little or no corruption... [14:44:25 CEST] <zyme> Every time my chromecast2 hit something the hardware decoder crashed on I had to restart the player, the cc2-ultra just pauses, I resend resume/play and it contines on [14:48:06 CEST] Action: zyme notices the statementon ffmpeg's page that NVENC combined with CUVID == 100% GPU encoding, I wonder if you have two Nvidia GPU's, and only one has NVENC support - does it still offload work to the sli partner? [14:51:07 CEST] <kepstin> if you have two different gpus, they're not in sli. Compute stuff doesn't use sli anyways, and the hardware encoder/decoder is completely separate per card. [14:51:15 CEST] <zyme> And what others can combine? Will Cuda and Quick Sync? [14:51:39 CEST] <kepstin> so you have to explicitly use a particular card for something, and you want to avoid transferring video between cards because that means a slow copy through memory or pci [14:52:40 CEST] <kepstin> ffmpeg can do something silly like decode video using nvdec, download to system ram, then encode to quicksync if you manually set up the appropriate downloads/uploads in filters. [14:52:41 CEST] <zyme> if the software supports it, they do use the PCI-E to distribute the load though, NVENC is a hardware decoder so it would do its thing alone [14:52:49 CEST] <kepstin> but there's no good reason to do so [14:54:12 CEST] <kepstin> (well, maybe there's reason to do so if you have an nvidia card like the gt 1030 with no nvenc, but its hardware decoder can do something quicksync can't decode, but that's a bit of an edge case) [14:54:16 CEST] <zyme> I have an Ivy Bridge on my laptop and my desktop is a 4-core unlocked Sandy Bridge.. Quick sync probably wont help nearly as much as the latest revs [14:55:11 CEST] <BtbN> kepstin, ffmpeg on Windows can do nvdec decode to quicksync encode without even downloading to ram in theory [14:56:21 CEST] <BtbN> As nvdec can output d3d surfaces, and qsv can take them. Not sure how well that works in practice though, as they will clearly be on different GPUs [14:56:36 CEST] <kepstin> how is that even possible? nvdec decodes to gpu ram, and the intel igpu can't access nvidia gpu ram [14:56:52 CEST] <BtbN> It can [14:56:56 CEST] <kepstin> if it *does* work, then direct3d is doing the copy behind your back [14:57:13 CEST] <zyme> That reminds me of the two Nice Quadro cards I use to have, which I ubtained for free - and retailed for over 2k USD each, it was a few years back and I ended up selling them off on ebay for $500 each after their value dropped. [14:57:24 CEST] <BtbN> Nvidias unified gpu memory makes it possible, as it blends in the VRAM into the normal address space [14:57:30 CEST] <zyme> I salvaged them from the trash at work [14:57:51 CEST] <BtbN> So at least in theory, the Intel GPU could read it straight from the nvidia VRAM [14:58:32 CEST] <DHE> it's faster and maybe more convenient on a busy system to let the GPU do most of the work onboard, but you can steal the frames out of the GPU no problem [14:58:35 CEST] <zyme> Integrated gpu's use system ram, DMA.. [14:58:37 CEST] <kepstin> BtbN: either way it's still doing a copy out over the pcie bus [14:58:40 CEST] <BtbN> If this is some Laptop with Optimus, you have to keep in mind that they very often entirely remove the video de/encoding unit from the nvidia GPU [14:59:51 CEST] <kepstin> hmm, the optimus stuff is weird, isn't it, where the nvidia card does something like render into the system ram used by the igpu as a framebuffer? [15:00:08 CEST] <BtbN> Yes, in the optimal setup that's used on Windows, that's how it works. [15:00:31 CEST] <zyme> as long as you disable protected memory/process isolation you should be able to specify the memory address, create a pointer, and use OpenCL or something to make the processes initiated by the card.. [15:01:05 CEST] <zyme> drivers work at above user level so the API might allow for it cleanly [15:02:39 CEST] <zyme> btw, I think the outdated PCI-E bus on my laptop would kill most the potential speed of upgrading its gpu (but its awesome that my laptop has a removable gpu lol) [15:05:39 CEST] <zyme> my desktop, the Ivy Bridge is What I'd likely upgrade.. and it runs 4*3.4Ghz x86_64 so.. The new GPU would take 90% of the web browser load anyway so you probably wouldn't notice the impact.. [15:06:59 CEST] <kepstin> web browser load is still mostly cpu outside of certain animation/rendering steps, video decoding (in some configs), and webgl. [15:08:14 CEST] <BtbN> Specially on Linux, Webbrowsers don't use video decoding hwaccel [15:09:34 CEST] <kepstin> last i checked, firefox doesn't even fully enable gpu compositing on linux yet [15:09:47 CEST] <kepstin> (this is partly why webgl is so slow in firefox on linux...) [15:10:22 CEST] <atomnuker> firefox with gpu compositing is actually even slower on 4k displays [15:10:35 CEST] <atomnuker> because every time a pixel changes it uploads the entire window to the gpu [15:10:55 CEST] <atomnuker> software compositing does partial updates so it only uploads what has actually changed [15:11:31 CEST] <zyme> OpenCL 1.2 is supposedly fully C++ compatible, how well it performs depends on the program.. [15:11:57 CEST] <zyme> and how much code has been modified to use it instead of the cpu [15:12:11 CEST] <zyme> and balancing the two if needed.. [15:12:43 CEST] <kepstin> stuff like opencl is interesting, yeah. if you get it wrong it'll slow the program down due to extra synchronization/setup required when switching between cpu and gpu :/ [15:31:54 CEST] <kerio> i wonder if opencl and the like would work better with shared memory between cpu and gpu [15:32:55 CEST] <atomnuker> actually yes, with vulkan there's an improvement if you need the data to remain on the gpu [15:33:26 CEST] <atomnuker> since with a normal upload operation you copy it on the gpu linearly and then you do a gpu memcpy to tile the image to a format gpus are good with [15:34:01 CEST] <atomnuker> you can cut the second part with a shared memory interface, but doing operations on linear images is slower, especially if you have quite a lot to do [15:34:48 CEST] <atomnuker> so it'll only give benefit for small filterchains (e.g. upload, color correct, download) or for display purposes (upload, convert to rgb to a separate image, display) [15:45:24 CEST] <kerio> hm, why do you need to tile the image? [15:45:28 CEST] <kerio> can't you do that beforehand? [15:57:26 CEST] <zyme> [off-topic] other then transcoding the only bottleneck that's bothersome on my desktop is a 250mb proprietary database with encryption and no odbc's or api, in plain text export its only 120mb but I don't know why its so slow, it uses very little cpu so I'm thinking a little bit HDD IOP's, maybe a whole lot of memory bandwidth? [ddr3 dual channel 1333 mobo-limited 1800-capable].. [16:02:35 CEST] <zyme> I have a MS-SQL licence from work that cost about 10k new that I could've used via my old technet licence if it only supported sql servers.. the company that made this uses open source everything obscured within mostly encrypted zip files..even in the temp folder. *sigh* [16:11:31 CEST] <zyme> [another offtopic comment] I bet that SQL server is still running mostly untouched since I left, the previous one went untouched for several years, 1 or 2 went by without hiring someone to admin - combined with different client ver. used on every users PC.. it was a flight plan app so: it ended up the cause of a mid-air collision. [16:13:01 CEST] <zyme> (Every IT guy loves it when the bosses come around and say "here's $22,000 - fix our server please" =) [16:19:50 CEST] <_Mike_C_> Hello again, sorry for the repeat question. Can anyone point me to an example that programatically creates and uses the h264_nvenc or hevc_nvenc encoders? I am running into access violations, I assume due to missing some extra steps needed in their instantiation. [16:21:01 CEST] <_Mike_C_> Access violations in the avcodec_send_frame() call [16:21:19 CEST] <zyme> _Mike_C_: there were no make errors? and did you compile w/static library's? [16:21:36 CEST] <zyme> btw is it linux/win/mac/etc? [16:21:41 CEST] <_Mike_C_> I'm using the distributed DLLs from the ffmpeg site, I'm on windows [16:21:57 CEST] <_Mike_C_> Both the encoders work fine when used from the command line [16:22:13 CEST] <zyme> Windows 10? version 1803? [16:22:46 CEST] <zyme> if its 1803 they added a bunch of new memory protective security settings in the security manager [16:23:40 CEST] <_Mike_C_> I'm not sure what exact windows it is, it is windows 10 though. [16:23:57 CEST] <zyme> and the av protects access to many file locations unless its explicitly added, but that shound give you a notice from the sec mgr if that happens [16:24:05 CEST] <_Mike_C_> The encoders work fine from the command line ffmpeg, so I assume its not something related to that, wouldn't that be correct? [16:24:15 CEST] <zyme> press windows key and r [16:24:37 CEST] <zyme> a run box should open, type winver [16:24:46 CEST] <_Mike_C_> 1709 [16:25:41 CEST] <zyme> that's the previous update rolled out - which means it should be less troublesome [16:25:42 CEST] <_Mike_C_> It's definitely some setting I'm either not setting or setting incorrectly. [16:26:23 CEST] <_Mike_C_> I'm looking at the vdpau example and there are a lot of extra steps to use that hardware encoder, is there a similar example for the nvenc hardware encoders? [16:26:45 CEST] <zyme> I've never used the shared dll version - did/do they need to be registered in windows with regsvr32.exe? [16:27:32 CEST] <_Mike_C_> No, other software encoders work fine. This is specifically the hardware encoders. [16:28:08 CEST] <zyme> I'm not a ffmpeg expert like most those in here, but I spent 9 years in IT so I have a general knowledge.. [16:28:33 CEST] <zyme> I assume you needed to download a sdk from nvidia and #include it for your compile? [16:29:07 CEST] <_Mike_C_> No they worked out of the box, tested with the command line version of ffmpeg [16:30:38 CEST] <zyme> Oh.. your using a gui/some soft of syntax builder? [16:31:28 CEST] <_Mike_C_> You can use ffmpeg from the command line and call the .exe or you can make a program that calls the api. I'm running into issues due to missing steps when calling the api directly [16:34:49 CEST] <atomnuker> kerio: nope, each GPU has a different way of tiling which is opaque to users, only linear tiling is universally understood [16:37:41 CEST] <haasn> an extension to make the tiling requirements public would be cool [16:37:53 CEST] <haasn> useful for people who could then precalculate their data in the right tiling [16:38:16 CEST] <zyme> I wonder how that would have worked with 3dfx's rampage had it been released. it supposedly used some new method that natively tiled rendering without rendering the part of the image unseen from overdraw, [16:38:18 CEST] <haasn> and it being an extension means you wouldn't have to implement it if you do exotic or usage-dependent tiling in some way that isn't compatible with the specification [16:38:31 CEST] <haasn> I mean "tiling" is an overloaded term [16:38:44 CEST] <haasn> these days GPUs use tiled textures, tiled rasterizers, tiled binning, and none of these are "tiled rendering" [16:39:22 CEST] <zyme> funny how nvidia infringed on all off their patents - then bought them to gain licencing rights and threw out most of their tech the first chance they got.. [16:41:37 CEST] <zyme> They had pushed back a court trial date for more than 2 years - and were only a month away from it when they went bankrupt.. I'd boycott them except they hired most of 3dfx's employees so I figure its still supporting the same people minus the ceo that mismanaged them into the ground at the end.. [16:43:11 CEST] <zyme> _Mike_C_: they work out of the box when in the same dir as the .exe - what about if it isn't, or did you already test that? [16:43:38 CEST] <atomnuker> haasn: tru dat, would allow you to map drm textures directly and download them without mapping to something else [16:43:49 CEST] <zyme> if the .exe is in a path variable contained dir it's likely the same result as being in the same folder [16:44:24 CEST] <atomnuker> libdrm's does document what each tiling is meant to look like in memory but a lot of them are just defined as vendor specific and undocumented [16:45:49 CEST] <zyme> this the same memory that uses advanced randomized placement as a barrier against buffer overflow attack attempts? lol. [16:47:32 CEST] <zyme> https://usercontent.irccloud-cdn.com/file/WLbUkpgw/High%20Entropy%20ASLR.png [16:47:48 CEST] <_Mike_C_> I'm using the same DLLs, yes. They're in my system path. [16:50:04 CEST] <zyme> doesn't a api call not access the code via the file system method? the .exe cli would work wherever it was located but since it's designed to work when in the same folder.. [16:50:36 CEST] <haasn> zyme: ASLR just randomizes the base offset for the executablle [16:50:41 CEST] <zyme> I would try and run regsvr32 on each of them just to see if that works or gives an error [16:51:03 CEST] <haasn> and I wonder how that "Force randomization of images not compiled with /DYNAMICBASE" works [16:51:04 CEST] <zyme> generally if it needed it it will work, if it doesn't it'll error.. [16:51:07 CEST] <haasn> seems like it would immediately segfault [16:52:12 CEST] <zyme> the last option in that list is "Terminate a process when heap corruption is detected" [16:52:30 CEST] <haasn> how nice of them to provide the option to *not* do that [16:52:34 CEST] <zyme> turn that off and maybe it'll run while leaking memory lol [16:52:49 CEST] <haasn> leaking memory and executing arbitrary code [16:52:57 CEST] <haasn> but heap corruption != segfault [16:52:59 CEST] <zyme> good stuff [16:53:14 CEST] <haasn> heap corruption just means your malloc state is inconsistent [16:53:34 CEST] <haasn> like a double free [16:53:38 CEST] <zyme> I've never coded using a memory manager/garbage cleanup mechanism like with .net code [16:57:23 CEST] <zyme> The most automation I'm familar with is using string variables instead of char -- but I imagine complex enough software needs to be more dynamic with memory allocation.. how does ASLR work by adding somethin akin to pointers at each fragmentation point, chunk sizes like file system clusters or packet mtu's? [16:58:43 CEST] <zyme> malloc inconsistent with what? [16:59:14 CEST] <zyme> unexpected early termination? [16:59:34 CEST] <haasn> ASLR works with position independent code, by doing indirect address lookups / offsets instead of hard-coding them [17:00:07 CEST] <haasn> inconsistent with its internal assumptions, like representing anything valid or sane [17:00:28 CEST] <haasn> e.g. imagine something as simple as a counter tracking the number of allocated objects [17:00:29 CEST] <zyme> like pointers that are not statically assigned, I follow so far.. [17:00:46 CEST] <haasn> on a double free() that pointer will be erroneously decremented and eventually hit negative numbers [17:00:54 CEST] <haasn> s/pointer/counter/ [17:01:17 CEST] <haasn> >In 2017, an attack named "ASLRCache" was demonstrated which could defeat ASLR in a web browser using JavaScript.[41] [17:01:20 CEST] <haasn> classic [18:01:37 CEST] <zyme> if only misuse and security wasn't a concern, imagine how much faster everything would be without logical software layers, isolated exec data with software gateways, hardware based virtual environments on top of software ones and software levels working with user-based levels working with kernel based levels etc. everything being monitored by av scanners and malware scanners etc.. soon AI adaptive security vs AI based malware [18:01:59 CEST] <haasn> misuse? security??? [18:02:13 CEST] <haasn> my main concern is buggy software tearing everything down. [18:02:22 CEST] <haasn> imagine getting a BSOD every 3 seconds [18:02:30 CEST] <haasn> this is what life would be like if we didn't have umpteegn security layers [18:02:37 CEST] <haasn> s/teegn/teen/ [18:03:07 CEST] <haasn> but yeah AV software is a scam industry [18:05:14 CEST] <Hello71> you heard it here first, ffmpeg developers admit their software is a scam [18:05:27 CEST] <haasn> lol [18:07:35 CEST] <zyme> true - but with frequent validation testing and the right programmed logic it'll only slow down to course correct when some bad code starts breaking things. instead now we have hardware based av+anti-malware + hardware drm to trying to use rl hardware to isolate itself from software.. btw I'm reminded of a couple months ago reading that the latest malware is ram-stored 100% so no av software scans can find it.. [18:31:19 CEST] <jokke> hi [18:33:26 CEST] <jokke> i'm trying to figure out what's the easiest way to get the codec (such as "x264") for a stream of data coming over the network without having to use command line tools [18:34:38 CEST] <jokke> my scenario: someone sends a file over http, i want to check if it's in an allowed format, if not i want to stop reading the request body and respond with a 400 error code [18:36:55 CEST] <DHE> well ffmpeg does include API options, so you could buffer in RAM and try letting libavformat guess the type. however the HTTP spec officially requires you to read the whole body before you send the error message and some formats are not streaming-friendly or only conditionally so [18:39:50 CEST] <jokke> DHE: are you sure baout that? [18:39:52 CEST] <jokke> *about [18:40:05 CEST] <jokke> i recently read that it's not required to read the whole body [18:40:52 CEST] <jokke> https://tools.ietf.org/html/rfc7540#section-8.1 [18:42:18 CEST] <DHE> well this is HTTP v2 [18:42:29 CEST] <jokke> ah [18:42:31 CEST] <jokke> dang [18:42:35 CEST] <jokke> true [18:42:46 CEST] <DHE> and I've had issues in the past when using the apache LimitRequestBody directive in the past. might be an implementation detail but it sucked for me [18:42:56 CEST] <jokke> i see [18:43:01 CEST] <jokke> damn that sucks [18:43:15 CEST] <jokke> waiting for a multi gigabyte upload to finish [18:43:37 CEST] <jokke> just to tell "nah, i won't take that" [18:44:22 CEST] Action: DHE is pleased with his 10gigabit servers [18:44:39 CEST] <jokke> heh, but your client's won't be happy [18:44:44 CEST] <jokke> *clients [18:45:14 CEST] <jokke> waiting for the upload to finish for an hour only to see an error. That sure makes everybodys day [18:45:48 CEST] <jokke> DHE: are you sure this also applies for Transfer-Encoding: chunked? [18:46:09 CEST] <Foaly> uploading from a browser? [18:46:11 CEST] <jokke> yeah [18:46:40 CEST] <Foaly> there is definitley a way to partially upload a file, because i have seen websites that do that [18:47:01 CEST] <Foaly> but i don't know anything about web development [18:47:06 CEST] <Foaly> probably javascipt magic [18:47:16 CEST] <jokke> hmm [18:47:39 CEST] <DHE> also resumable uploads, etc [18:48:44 CEST] <DHE> or something where you upload in 1 megabyte increments or something, giving your application the chance to look at an incomplete file and veto the next 1meg chunk or such [18:48:49 CEST] <jokke> yeah [19:01:47 CEST] <Cracki> definitely javascript magic. js gets a handle to the local file, can seek and read it any way it wants, sends stuff to the server, which can handle the data any way it needs to. [19:02:08 CEST] <Cracki> you can chunk it, or POST/PUT/... ranges, anything goes [19:02:32 CEST] <Cracki> "chunked" is inside the http layer, so transparent to whoever uses it [19:04:13 CEST] <JEEB> yeh [19:04:50 CEST] <jokke> https://lists.w3.org/Archives/Public/ietf-http-wg/2004JanMar/0044.html [19:12:53 CEST] <zyme> nice protocal function, I would've gone straight to ethereal/wireshark + a special filter [21:56:29 CEST] <Mista_D> Any method for FFPLAY to render HDR 4K as "intended" please? [21:58:07 CEST] <JEEB> use a proper player that has tone mapping [22:01:21 CEST] <remlap> mpv [22:01:23 CEST] <Mista_D> VLC? [22:01:29 CEST] <remlap> nope [22:02:52 CEST] <Mista_D> remap: thanks, it worked [23:02:51 CEST] <haasn> VLC 3 [23:07:09 CEST] <FishPencil> Not sure if this is ontopic here, but I have a computer vision question and IDK where to ask it [00:00:00 CEST] --- Sat Aug 25 2018

1 0

ffmpeg-devel.log.20180823
by burek 24 Aug '18

24 Aug '18

[00:23:32 CEST] <durandal_1707> did anyone received last patch from me? [00:24:05 CEST] <durandal_1707> ah it appeared [05:33:01 CEST] <TimothyGu> It takes so much work to roll FFmpeg in Chromium, the instructions are almost funny to read [05:33:02 CEST] <TimothyGu> https://docs.google.com/document/d/14bqZ9NISsyEO3948wehhJ7wc9deTIz-yHUhF1MQ… [05:35:19 CEST] <TimothyGu> "It's much less stressful to do the roll earlier. If youre familiar with the process and get lucky (nothing breaks), you can finish the FFmpeg roll within a day." [06:56:09 CEST] <kierank> atomnuker: they don't need to buffer frames to do that [06:56:19 CEST] <kierank> just lines [06:58:43 CEST] <Compn> dur : [06:58:46 CEST] <Compn> where he go [07:10:36 CEST] <Compn> does someone still run a server box for devs to test things ? [07:10:46 CEST] Action: Compn needs to build mplayer somewhere.... [11:40:39 CEST] <durandal_1707> ubitux: this site: http://www.arri.com/camera/alexa/tools/lut_generator/lut_generator/ can generate various 3d luts, some are unsupported by lut3d filter [11:46:09 CEST] <ubitux> yeah i just picked the most common formats i was sent by people [11:46:16 CEST] <ubitux> it's incomplete [11:46:36 CEST] <ubitux> it's a mess of random text files [11:46:53 CEST] <ubitux> (reminds you sth, doesn't it..) [11:47:14 CEST] <ubitux> the only sane lut3d format is haldclut [11:47:20 CEST] <ubitux> which is binary/an image [11:47:26 CEST] <ubitux> ppl should just use that [11:48:09 CEST] <JEEB> didn't you first poke at subtitles? [11:48:24 CEST] <JEEB> which is one of the "random stuff in text" things [11:48:24 CEST] <JEEB> :D [12:04:06 CEST] <ubitux> JEEB: yeah that's what i was refering to :( [13:18:33 CEST] <cone-207> ffmpeg 03Jun Zhao 07master:c9ed7f002492: lavc/encode: remove redundant av_init_packet after av_packet_unref. [15:22:50 CEST] <durandal_1707> ubitux: why you didn't do tricubic interpolation in lut3d? [15:30:48 CEST] <ubitux> too slow i suppose, i looked at the most common interpolation for lut3d [16:01:31 CEST] <cone-207> ffmpeg 03Michael Niedermayer 07master:4251a44e7d9e: configure: do not add fsanitize cflags with ossfuzz if coverage is tested [16:01:32 CEST] <cone-207> ffmpeg 03Dale Curtis 07master:e7080d1fe29b: avformat/mov: Correct opus-in-mp4 pre-skip to be uint16_t versus int16_t. [16:01:33 CEST] <cone-207> ffmpeg 03hwren 07master:b8da7ba5ac99: lavc/extract_extradata_bsf.c: add AVS2 [16:46:27 CEST] <durandal_1707> Who is Dav1d ? [17:18:43 CEST] <Gramner> dav1d is dav1d [17:22:07 CEST] <j-b> Gramner: :D [17:31:07 CEST] <durandal_1707> dav1d is j-b super secret then, he do not want to share it with anyone except himself [17:31:31 CEST] <j-b> durandal_1707: just wait a couple of weeks and come to VDD [17:32:00 CEST] <durandal_1707> only when VDD come to me [17:35:36 CEST] <j-b> Where are you? [17:35:45 CEST] <durandal_1707> dav1d = b1veb [17:35:46 CEST] <atomnuker> you still have 2 days left to register [17:36:47 CEST] <durandal_1707> am against registering [17:37:20 CEST] <j-b> necause? [17:38:07 CEST] <durandal_1707> i'm not gonna share my personal info [17:38:15 CEST] <j-b> personal info? [17:38:15 CEST] <JEEB> the most you are sharing is your name [17:38:25 CEST] <JEEB> and that's kind of required wrt venues [17:38:36 CEST] <j-b> You don't even need to share your name, if you really need that. [17:38:55 CEST] <j-b> I can work-around it for one person. [17:39:37 CEST] <atomnuker> you can always say you're elvis presley too [17:40:35 CEST] <JEEB> durandal_1707: in any case, whatever negative thoughts you have about VDD, try to put them aside. People I've met at VDD have been nice unrelated to any internet personas [17:41:10 CEST] <durandal_1707> i'm awaiting VDD to come to me, because I can not move out [17:41:54 CEST] <gnafu> atomnuker: {:-] [17:41:56 CEST] <atomnuker> its a 2 hour flight from where you are, that's nothing, I've been on a 14 hour flight a day after I did an 8 hour flight [17:42:33 CEST] <durandal_1707> atomnuker: some super secret agency is looking for me [17:44:24 CEST] <atomnuker> disguise yourself, a long brown coat, a fedora and glasses with a nose and a mustache [17:45:04 CEST] <durandal_1707> you just described me!! [17:46:22 CEST] <BradleyS> i totally read that "long brown cat" [17:46:38 CEST] <atomnuker> ah, well, its easy then, put on a shiny white suit, pomade on your hair, then you'll pass for elvis presley [17:47:21 CEST] <atomnuker> agents won't be looking for you because they don't look for dead people, conspiracy theorists will however, but they're friendly, only take pictures for underground newspapers [17:47:31 CEST] <durandal_1707> ok, that one is resolved, but I'm scared about flying [17:48:47 CEST] <atomnuker> you've never flown before? issue solved, you get to fly twice and see what its like! [17:50:10 CEST] <durandal_1707> no, i can not go there without parachute [17:52:00 CEST] <atomnuker> there are parachutes, they're in the cargo hold, I've seen it in action movies [17:52:41 CEST] <Gramner> just pull a D. B. Cooper [17:56:31 CEST] <atomnuker> he never gets on a plane in either series though [17:57:00 CEST] <atomnuker> oh or do you mean teleportation through electrical sockets? [17:57:18 CEST] <Gramner> https://en.wikipedia.org/wiki/D._B._Cooper [17:58:26 CEST] <atomnuker> I thought you meant Dale Cooper, whose middle initial is also B. [17:59:23 CEST] <durandal_1707> will I sleep alone in room? Paris is veeeeerrry big [18:03:09 CEST] <atomnuker> usually yes, with someone from videolan, unless you request someone specific [18:04:01 CEST] <atomnuker> inner paris isn't that big, and you won't be going outside that unless you want to go to disneyland on friday [18:05:34 CEST] <durandal_1707> will there be live stream? [18:06:44 CEST] <Gramner> the community event is a visit paris competition, not disneyland, according to the videolan vdd page [18:13:26 CEST] <atomnuker> oic, I don't go to them as I always have to work my slides [18:14:16 CEST] <atomnuker> durandal_1707: don't count on it, don't count on the videos being uploaded for around 8 months either [18:14:26 CEST] <durandal_1707> atomnuker: you are little lazy, work on slides days before and then socialize a litle [18:15:10 CEST] <atomnuker> no way, all pros do their slides from scratch the night before [18:15:25 CEST] <durandal_1707> atomnuker: what kind of unprofesionalism is that? amateurs, give me live stream! [18:16:53 CEST] <durandal_1707> i will go to NTTW X when it being held in Slovenia or Italy or somewhere even closer, they have live streaming too [18:17:01 CEST] <atomnuker> its not a big marketing event, its a technical unconference [18:17:05 CEST] <Gramner> the pro way is to create the next slide while presenting the current slide [18:17:30 CEST] <durandal_1707> that is called the improvisations [19:25:53 CEST] <JEEB> btw, what's a nice thing to snapshot memory usage from a running process? [19:26:32 CEST] <JEEB> if I have a long-running process and I'd like to take snapshots of its memory usage every hour or so [19:27:02 CEST] <JEEB> because I think there's a memory leak somewhere, but if the process exits it might be all released properly [19:27:09 CEST] <kurosu_> cat /proc/$PID/stats or something ? [19:27:25 CEST] <JEEB> I think that doesn't show whereabouts the memory usage is [19:27:39 CEST] <JEEB> I think someone at some point noted gprof [19:27:50 CEST] <kurosu_> *status [19:27:51 CEST] <JEEB> but I think that might be a full all-the-way dumping [19:28:08 CEST] <JEEB> instead of "let's see where memory is used at time points X,Y,Z" [19:28:11 CEST] <kurosu_> how you mean like profiling inside of the process ? [19:28:20 CEST] <kurosu_> *oh [19:28:35 CEST] <JEEB> yea, I'd like to figure out where lavf/lavc/lavfi is buffering more and more stuff with time [19:28:44 CEST] <kurosu_> I think I used valgrind's massif, but that's valgrind, and I forgot how since then [19:29:09 CEST] <JEEB> ok, I'll have to see if I can get valgrind be fast enough [19:29:41 CEST] <JEEB> unless I dump gigabytes worth of the source [19:30:00 CEST] <JEEB> but that'd be rather long to keep it rolling for enough time [19:30:06 CEST] <JEEB> s/long/large/ [19:30:16 CEST] <JEEB> so being able to run it fast enough with the realtime input sounds like a better idea :D [19:30:27 CEST] <JEEB> since it seems to constantly replicate [19:30:40 CEST] <JEEB> and it's specific to certain inputs [19:30:48 CEST] <JEEB> not all of them lead to such memory usage gains [19:30:58 CEST] <kurosu_> Or you move the av_ alloc functions to macros that log big enough ones using __line__ and stuff [19:31:24 CEST] <kurosu_> though you don't know when that gets deallocated [19:31:32 CEST] <atomnuker> ^^that's a good idea [19:32:09 CEST] <atomnuker> you can keep track of frees by having a global array store the pointers, and making sure to have a global lock too [19:32:13 CEST] <kurosu_> maybe alloc eg a bigger area to store interesting info there [19:32:32 CEST] <kurosu_> at the start of the area, like old unaligned allocs were doing [19:35:01 CEST] <kurosu_> I remember using massif because of a C++ app that didn't get its dangling references, local copies and such [19:35:37 CEST] <kurosu_> like "how let's put that image in that container" - ah I just duplicated it [19:43:13 CEST] <JEEB> I'll have to try massif [22:22:45 CEST] <rcombs> hmmmmm [22:23:04 CEST] <rcombs> I think if an error occurs during an avio_read, but there's some data buffered, that data will get returned rather than the error code, right? [22:23:14 CEST] <rcombs> potentially resulting in a short read [22:23:26 CEST] <rcombs> mpegts.c seems to assume that all short reads mean EOF [22:23:28 CEST] <rcombs> who's wrong [22:25:00 CEST] <JEEB> hmm [22:26:08 CEST] <rcombs> (got a log + pcap indicating a read timeout in a chunked HTTP stream was treated as an EOF and resulted in ffmpeg.c exiting with status code 0) [22:34:09 CEST] <durandal_1707> michaelni: let's ban Compn he is ignoring me [22:35:55 CEST] <Compn> i posted patch durandal_1707 [22:35:58 CEST] <Compn> to -dev-eng [22:36:01 CEST] <Compn> what out fmt is it [22:36:49 CEST] <durandal_1707> Compn: same as for y41p [22:36:59 CEST] <Compn> out Y41P ? [22:37:17 CEST] <durandal_1707> Compn: oh, noo, its yuv420p [22:37:21 CEST] <Compn> lol [22:37:37 CEST] <Compn> k [22:37:38 CEST] <durandal_1707> i thinked about BT20 [22:37:55 CEST] <Compn> durandal_1707 : why imm4 not imm5 and imm6 at same time? :) [22:37:59 CEST] <durandal_1707> IMM4 is yuv420p [22:38:11 CEST] <Compn> working on imm5 / imm6 ? [22:38:17 CEST] <durandal_1707> no [22:38:33 CEST] <Compn> binary decoder still needed. [22:39:26 CEST] <Compn> durandal_1707 : write guide for reverse engineering codecs? [22:39:46 CEST] <cone-785> ffmpeg 03James Almer 07master:35c84ae834de: Revert "avcodec/opus_parser: Handle complete frames flag." [22:40:48 CEST] <durandal_1707> Compn: guide? more like book of 3k pages [22:42:34 CEST] <Compn> yes write it [22:43:38 CEST] <durandal_1707> once mplayer lose all users [22:45:36 CEST] <durandal_1707> also there are no imm6 samples iirc [23:28:08 CEST] <durandal_1707> who gave Carl so many different computers? [23:31:24 CEST] <atomnuker> the results are good so its alright [23:31:52 CEST] <atomnuker> I'd rather have the new reader used everywhere, but I'd be happy with it being x86_64 only [23:32:11 CEST] <atomnuker> I think the cache size is adjustable, not sure if that would help 32 bits [23:36:55 CEST] <durandal_1707> atomnuker: what you use to measure ffv2 visual performance? [23:37:59 CEST] <j-b> ffv2! [23:40:58 CEST] <rcombs> alright sent a patch (and also a couple others for HEVC bsf stuff) [23:43:17 CEST] <atomnuker> durandal_1707: erm illustrations and pictures of birds over sky/water, because artifacts around sharp edges are easy to see [00:00:00 CEST] --- Fri Aug 24 2018

1 0

ffmpeg.log.20180823
by burek 24 Aug '18

24 Aug '18

[00:27:12 CEST] <BenMcLean> Hi there folks. I am trying to do a bit of work with my brand new Blu Ray box set of The Hobbit 3D Extended Trilogy [00:27:46 CEST] <BenMcLean> and was wondering if I might be able to get some technical advice from people who know alot about media conversion [00:28:06 CEST] <Cracki> use bittorrent [00:28:37 CEST] <BenMcLean> Here's what I'm trying to do: I want to get the 3D version of the Hobbit movies into a format that I can watch on my Samsung Gear VR headset in 3D with the director's commentary [00:28:55 CEST] <BenMcLean> Torrents 1. don't have extended in 3D and 2. don't have commentary [00:28:59 CEST] <kepstin> I don't think the ffmpeg h264 decoder can even handle mvc video? [00:30:07 CEST] <BenMcLean> The normal process people are following to convert 3D blu ray to VR ready files is to use MakeMKV and then BD3D2MK3D [00:30:37 CEST] <BenMcLean> and I could be wrong but I believe BD3D2MKV3D is ffmpeg-based [00:31:22 CEST] <BenMcLean> Here's my problem: That method works when MakeMKV spits out one MKV file with two video streams, but in the case of the Hobbit movie I'm working with, it is making two separate MKV files, one for each eye [00:31:53 CEST] <kepstin> ffmpeg has filters that can combine those two separate files into common formats like alternating frame or side-by-side, etc. [00:32:22 CEST] <BenMcLean> kepstin that's what I'm thinking might be the right path to pursue this project, rather than going through BD3D2MKV3D [00:32:57 CEST] <BenMcLean> But another oddity is that the 3D version of the movie is split up on to two separate discs, and the 3D version doesn't have commentary, only the 2D version does [00:33:21 CEST] <BenMcLean> So my thought is that I should be able to splice the commentary from the 2D version into the 3D files I make somehow [00:33:50 CEST] <BenMcLean> but then one final weird thing is that the second disc made THREE MKV files, not two. That's really weird! [00:45:39 CEST] <BenMcLean> I can't seem to find good settings recommendations for Gear VR or Daydream videos anywhere online. Sites always want to talk about 360 videos, not 3D videos [00:53:15 CEST] <BenMcLean> This command gives an error: [00:53:17 CEST] <BenMcLean> ffmpeg -i left.mkv -vf "[in] pad=2*iw:ih [left]; movie=right.mkv [right];[left][right] overlay=main_w/2:0 [out]" -i commentary.mkv -map 0:v -map 0:a -map 0:s -map 1:a:2 -t 30 output.mkv [00:53:47 CEST] <BenMcLean> The error is: Option vf (set video filters) cannot be applied to input url The_Hobbit_An_Unexpected_Journey_Extended_t00.mkv -- you are trying to apply an input option to an output file or vice versa. Move this option before the file it belongs to [00:54:05 CEST] <BenMcLean> er, that t00 one is what I called "commentary.mkv" [00:58:38 CEST] <c_14> filters go after _all_ input files, and before the output file you want to apply it to [01:01:05 CEST] <BenMcLean> oh i see [01:02:03 CEST] <BenMcLean> i told ffmpeg 30 seconds but it seems to keep on going and going at 29.99 seconds for some reason when encoding [01:03:37 CEST] <ariyasu> -t will never be exact [01:03:43 CEST] <ariyasu> it works to the nearest i-frame [01:04:12 CEST] <ariyasu> also i find it better to use -t before the input instead of the output [01:04:36 CEST] <c_14> that's a mess if you have multiple inputs though [01:04:47 CEST] <BenMcLean> What does "sps_id 1 out of range" mean? [01:04:58 CEST] <ariyasu> true [01:09:23 CEST] <BenMcLean> I found this but it's not very instructive https://www.ffmpeg.org/doxygen/3.2/structPPS.html [01:13:18 CEST] <BenMcLean> yeah no, it just keeps encoding and encoding and never stops [01:14:41 CEST] <BenMcLean> If I say 5 seconds, it just goes to 4.99 seconds and then never stops encoding without the time advancing [01:14:53 CEST] <BenMcLean> here's the command I used: [01:14:54 CEST] <BenMcLean> ffmpeg -i The_Hobbit_An_Unexpected_Journey_Extended_Edition_Part_1_t02.mkv -i The_Hobbit_An_Unexpected_Journey_Extended_t00.mkv -vf "[in] pad=2*iw:ih [left]; movie=The_Hobbit_An_Unexpected_Journey_Extended_Edition_Part_1_t03.mkv [right];[left][right] overlay=main_w/2:0 [out]" -map 0:v -map 0:a -map 0:s -map 1:a:2 -c:v h264 -c:a copy -c:s copy -t 5 output.mkv [01:20:35 CEST] <BenMcLean> Yeah, i come back 10 minutes later and it's still going, still at 4.99 seconds for a 5 second clip. [01:25:44 CEST] <BenMcLean> maybe i should be doing this in stages instead, like pull out the commentary, stick it in a container first [02:05:57 CEST] <BenMcLean> If ffmpeg gets stuck in an infinite loop isn't that a problem!? [03:11:12 CEST] <Guddu> I have a audio and video in MXF format. I want to join those two into a MOV file without any loss. Could this be done using ffmpeg [03:12:25 CEST] <DHE> one input file or two? [03:12:50 CEST] <Guddu> DHE, Thanks for your response. Those are 2 separate files. [03:13:02 CEST] <DHE> ffmpeg -i file1 -i file2 -c copy ouput.mov [03:13:41 CEST] <Guddu> DHE, -c copy is to specify that the output format is mov? [03:13:48 CEST] <furq> -c copy is to specify not to reencode [03:13:50 CEST] <DHE> codec: copy [03:14:02 CEST] <DHE> (which isn't really a codec) [03:14:13 CEST] <furq> also if it's mxf then there's a good chance it has every audio channel as a separate stream [03:14:18 CEST] <furq> in which case you'll need to mix them together [03:14:37 CEST] <DHE> if that's the case then it will require transcoding to merge them... [03:14:55 CEST] <JTa> o/ all.. [03:15:08 CEST] <furq> unless it's pcm [03:15:09 CEST] <Guddu> furq, Yes. That mxf file has 1 Audio Stream with 6 channels. [03:15:23 CEST] <Guddu> Its PCM [03:15:24 CEST] <furq> if that's how ffprobe describes it then great [03:15:30 CEST] <JTa> hey, if there are any socal peeps here please pm me. I got a question for you. I'm the guy who organizes most of the blender user meetings here in socal [03:15:44 CEST] <Guddu> furq, I saw that in mediainfo tool. [03:16:29 CEST] <Guddu> I am generating this mov file to subsequently be able to load it into my Blu Ray creator program. I am using Leawo for that. [03:17:17 CEST] <JTa> BTW, I am also working on my addon again in blender that exposes the complete command line parameters to blender's VSE to use ffmpeg externally like most of us do, lol... [03:17:36 CEST] <JTa> but if you are socal like me please PM me real quick, I have a question for you... [03:29:10 CEST] <Guddu> DHE, furq So that command is ok? ffmpeg -i file1 -i file2 -c copy ouput.mov [03:29:25 CEST] <Guddu> Also can i convert it to 1920*1080? Currently it is 2048*858 [03:32:09 CEST] <DHE> well then you're transcoding. and video transcoding tends to be pretty hard on the CPU [03:32:16 CEST] <DHE> also worth noting that there's an aspect ratio change there [03:32:49 CEST] <mitigate> klaxa, I finally looked up nginx - you told me in feb it would do what ffserver could do- but i find afaict you cant use html5 + webm as you could with ffserver - you need special video players on the client [03:33:06 CEST] <Guddu> DHE I have the server available for whole night. So CPU usage is not an issue. Its all for me today. [03:33:22 CEST] <Guddu> Is this command ok? ffmpeg -i file1 -i file2 -s1920*1080 -c copy ouput.mov [03:33:41 CEST] <DHE> -s and -c copy are not compatible. you can't resize without transcoding [03:33:51 CEST] <mitigate> and you need special modules on nginx. double fail. afaict it will not be possible to get the functionality with the new apis (which are also designed to be an ever moving target) [03:44:55 CEST] <furq> mitigate: you can do webm livestreaming with icecast to some degree [03:44:59 CEST] <furq> i couldn't vouch for how well it works [03:46:40 CEST] <Guddu> DHE, I will skip the -s for now and let the Blu Ray program handle it. But if i generate using this command then will the Handbrake took recognize the generated MOV file? [03:46:52 CEST] <Guddu> ffmpeg -i file1 -i file2 -c copy ouput.mov [03:51:17 CEST] <mitigate> but the simplicity that is ffmpeg is gone - because these third parties invest and donate to ffmpeg to destroy it\ [03:52:05 CEST] <mitigate> the developer that removed ffserver isnt fit to be a programmer or write new apis if he couldnt provide the functionality [03:52:56 CEST] <mitigate> "i cant maintain it" gtfo programming! [03:54:24 CEST] <atomnuker> you do realize there's a better ffserver that was written for the gsoc? [03:54:39 CEST] <mitigate> no i only saw the proposal [03:55:01 CEST] <mitigate> i'll check again later.. [03:55:03 CEST] <atomnuker> well its there and it works quite well, better yet it uses fully standard things [03:55:49 CEST] <atomnuker> (also I pushed and commited to remove ffserver, sorry, had to, was hoding us back) [03:56:16 CEST] <mitigate> i'm sorry - but i still have a tough time wrapping my head around it [03:56:23 CEST] <mitigate> and i'm not terribly invested in it [03:57:22 CEST] <furq> i'm honestly amazed anyone ever got anything running with ffserver [03:57:51 CEST] <furq> but i'm pretty sure that for years it had been in a state of doing the minimum possible to move it off deprecated apis [03:58:01 CEST] <furq> and not actually fixing the fact that it never worked well [04:01:37 CEST] <mitigate> ah klaxa wrote it! [04:02:25 CEST] <mitigate> it needs lua and microhttpd - lua stops the show on this box [04:06:31 CEST] <mitigate> but i'll fix that and try it and maybe report again later... [04:08:06 CEST] <furq> are you on one of those rpm distros [04:08:41 CEST] <mitigate> no, roll my own... [04:10:30 CEST] <Guddu> DHE, I generate the output with -c copy but the resulting mov does not loads in Handbrake. [04:10:38 CEST] <Guddu> Should I try another codec? [04:16:52 CEST] <feedbackmonitor> Hi, can ffmpeg be used to re-encode footage recorded at 24 fps to output to 60 fps? [04:17:13 CEST] <furq> sure [04:17:34 CEST] <furq> do you want to duplicate frames, blend frames, or use motion interpolation [04:17:40 CEST] <feedbackmonitor> furq, Here is my footage ingredients: http://pastebin.centos.org/1587131/ [04:17:57 CEST] <feedbackmonitor> furq, Whatever looks nicest [04:18:08 CEST] <furq> motion interpolation will look nicest but it's slow [04:18:13 CEST] <feedbackmonitor> Audio I can tack on after the fact [04:18:30 CEST] <feedbackmonitor> furq, I don't care about slow, I care about looking great [04:18:42 CEST] <furq> https://ffmpeg.org/ffmpeg-filters.html#minterpolate [04:18:44 CEST] <furq> that's what you want then [04:18:59 CEST] <furq> just -vf minterpolate=60 should give decent results [04:19:02 CEST] <furq> you can probably tune it more [04:19:24 CEST] <feedbackmonitor> can you please provide a code example (but I will read it as I am making a lot of errors that need to be rectified) [04:19:36 CEST] <feedbackmonitor> furq, ahh [04:20:27 CEST] <feedbackmonitor> furq, Thanks [04:20:45 CEST] <feedbackmonitor> I need to read the ffmpeg manual, wil it have that information you mentioned? [08:14:43 CEST] <NoEgo> I've got some DVD's I ripped to MKV, and they have a container speed of 29.976 and a stream speed of 23.976. I've been using '-vf fieldmatch,yadif=deint=interlaced,decimate' to IVTC based on some advice I found online. The resulting file is 23.976 fps, but the file duration has changed (06:44 > 05:23) and the audio is obviously way out of sync. Am I mistaken in thinking these files are telecined? Is there a surefire test? I am now [08:14:43 CEST] <NoEgo> using the 'idet' filter to check and am getting very low TFF (13) and BFF (26) numbers. I was previously using the Hybrid GUI to test for interlacing/telecine and encoding, Hybrid reports these files as telecine but it also now encoding everything at 20FPS regardless of the settings so I am not sure if I can trust that anymore. [09:04:11 CEST] <furq_> NoEgo: you should just be able to framestep through the file and see if it's telecined [09:04:27 CEST] <furq_> obviously in a player that doesn't automatically deinterlace [09:05:02 CEST] <furq> two frames out of every five will be interlaced [09:19:48 CEST] <ldlework> furq: are -pix_fmt and -vcodec coupled? [09:20:03 CEST] <ldlework> like are only certain pix_fmt's compatible with certain vcodecs? [09:21:24 CEST] <furq> yeah [09:21:31 CEST] <furq> -h encoder=foo will list the available pixel formats [09:21:37 CEST] <ldlework> neat [09:23:08 CEST] <ldlework> i suppose they are all meaningless to me anyway [09:23:17 CEST] <JEEB> which /41 [09:40:02 CEST] <NoEgo> furq: Stepping through manually these look progressive. Does that generally mean I would be safe to just encode these with "-r 24000/1001"? Thanks for the help. [09:40:44 CEST] <furq> are you getting regular duplicate frames [09:42:17 CEST] <NoEgo> Yeah, it seems 2:2 in the file I am currently testing [09:42:47 CEST] <NoEgo> every frame repeats twice [09:43:07 CEST] <furq> that doesn't sound right [09:43:16 CEST] <furq> are you sure your player isn't deinterlacing [09:43:33 CEST] <NoEgo> I am using SMplayer with deinterlacing set to none [09:44:09 CEST] <NoEgo> wait [09:44:17 CEST] <NoEgo> Now I am not seeing any repeating [09:44:29 CEST] <NoEgo> That may have just been a very slow scene, my apologies [09:44:50 CEST] <furq> is this a film or a tv show [09:45:27 CEST] <NoEgo> Animated film short. It's a Tom and Jerry DVD [09:45:53 CEST] <furq> i was sort of hoping you wouldn't say animation [09:46:11 CEST] <furq> since that tends to be a pain [09:46:32 CEST] <NoEgo> lol, yeah. [09:46:40 CEST] <furq> if you're not getting any dup frames and not seeing any interlacing then i would just encode it 30p [09:47:10 CEST] <furq> that'd be weird though given i'm pretty sure that source should be telecined [09:47:15 CEST] <NoEgo> I am thinking this is definitely soft-telecined [09:47:42 CEST] <NoEgo> I can force it at 24000/1001 and everything seems to shake out ok [09:48:26 CEST] <furq> oh right i always forget soft telecine exists [09:48:38 CEST] <furq> i assume there's some good way to deal with that but i couldn't tell you what it is [09:50:12 CEST] <NoEgo> Yeah, all the other tricks I've found so far have come with their own headaches. Thanks for the help [10:12:40 CEST] <linux8659> Hi ,I m wondering if there is a way to pass a ffmpeg command to automatically merge all the files in the pwd ?? [10:13:00 CEST] Last message repeated 1 time(s). [10:13:05 CEST] <linux8659> the command I use I need to rename all the names first for convenience : ffmpeg -i "concat:1.mp3|2.mp3|3.mp3|4.mp3|5.mp3|6.mp3|7.mp3|8.mp3|9.mp3|10.mp3" -c copy out.mp3 [10:13:13 CEST] <linux8659> sorry.. thanks [10:31:49 CEST] <linux8659> I got the aswer on #bash : ffmpeg -i "concat:$(files=(*.mp3); printf %s "$files"; printf '|%s' "${files[@]:1}")" -c copy out.mp3 [10:34:42 CEST] <furq> that's probably not going to work well [10:35:04 CEST] <furq> that more or less does the same thing as cat *.mp3 > out.mp3 [10:36:18 CEST] <furq> you probably want something like `for f in *.mp3; do printf "file %q\n" "$f"; done | ffmpeg -f concat -protocol_whitelist file,pipe -safe 0 -i - -c copy out.mp3` [10:40:18 CEST] <linux8659> furq ok they both work for me ,you say yours is better [10:41:25 CEST] <furq> like i said, the concat protocol is more or less just cat [10:41:40 CEST] <furq> so it'll leave a bunch of file headers, id3 tags etc in the middle of the stream [10:41:44 CEST] <furq> which will cause issues in some players [10:42:24 CEST] <linux8659> THANKS I ll use it then ,this trick will save me SO MUCH time ,even if understand almost nothing of the command!!! [10:42:39 CEST] <furq> https://trac.ffmpeg.org/wiki/Concatenate#demuxer [10:42:54 CEST] <furq> it's more or less just that, except it pipes the concat list in [10:45:01 CEST] <linux8659> furq THANKS [11:16:33 CEST] <th3_v0ice> Is it possible to remove the audio stream delay while opening the AVCodecContext for encoding? I tried setting the initial_padding to zero, but this doesnt seem to affect anything. [11:16:54 CEST] <th3_v0ice> Timestamps are shifted by -initial_padding and I want to avoid this. [11:57:25 CEST] <ldlework> furq: what did I break? this only records greyness now, [11:57:44 CEST] <ldlework> ffcast % ffmpeg -f x11grab -i :0.0 -video_size %s -framerate 60 -vcodec libx264 -pix_fmt yuv420p -b:v 2000 -minrate 500k -maxrate 2500k ~/www/caps//045623082018.mp4 [11:58:20 CEST] <ldlework> this was working so good before gar [13:12:42 CEST] <relaxed> ldlework: -video_size and -framerate go before the input [13:14:30 CEST] <ldlework> relaxed do you ever use slop? [13:22:53 CEST] <ldlework> nm [14:13:09 CEST] <Kam_> Hello, I'm (cross) compiling FFmpeg with --disable-everything, but added a few things. one of my configurations fails building on the current git master revision (it works with a revision from beginning of August) (maybe by --enable-muxer=webm ?) and it might be caused by commits regarding av1 on 17th August. here is the error message: https://pastebin.com/HEcsE7tZ can someone look into this, please? I do [14:13:09 CEST] <Kam_> not have av1 enabled on my configuration and do not intent to have it. [14:18:13 CEST] <DHE> Kam_: --disable-everything is not usually recommended as it disables a number of core features as well. maybe you just want "--disable-muxers --enable-muxers=avi,pcm*,mpegts,h26*,mov,matroska" or such? [14:19:45 CEST] <Kam_> DHE, my configuration is fine, I guess this is a regression. the linker tries to reference 'ff_isom_write_av1c', 'ff_av1_filter_obus_buf' etc. which look like being part of AV1 [14:20:21 CEST] <DHE> yes, a quick source check says that you need the mov muxer enabled as well [14:20:34 CEST] <Kam_> but I do not want to have AV1 [14:20:51 CEST] <Kam_> what do I need the mov muxer for? [14:21:05 CEST] <DHE> it's the quickest solution to pull in the needed code [14:21:41 CEST] <Kam_> I have a even more minimalistic configuration, that one builds. [14:21:42 CEST] <DHE> even if you don't use av1 as an encoder, the matroska muxer still handles av1 as a codec to be written to. helper functions for it are missing [14:22:06 CEST] <JEEB> but it still shouldn't fail at compilation if the configuration is valid [14:22:33 CEST] <JEEB> so that is a boog I would guess in that sense [14:22:48 CEST] <Kam_> this configuration builds with git master from beginning of August. [14:23:07 CEST] <JEEB> basically either have that symbol available even without enabling some things, or proper ifdefs are needed in matroskaenc [14:23:08 CEST] <DHE> sounds like Kam_ wants to be able to compile codec-specific handling straight out of muxers as well [14:23:21 CEST] <JEEB> we already do that in various cases methinks [14:23:29 CEST] <JEEB> or we have the stuff that's 100% needed always available [14:23:37 CEST] <JEEB> it's a mishap due to an aV1- specific parser file [14:23:44 CEST] <DHE> https://github.com/ffmpeg/ffmpeg/commit/de1b44c2 offending commit [14:25:13 CEST] <JEEB> I'm at $dayjob but might look into it after I get home [14:25:55 CEST] <JEEB> I would guess that we still want av1 parsing so we can put AV1 into matroska even if AV1 itself isn't enabled [14:25:59 CEST] <DHE> there's that, but I would also just suggest a git revert for this specific user's issue [14:26:33 CEST] <JEEB> most likely movenc already depends on this parser, but not matroskaenc [14:27:33 CEST] <ldlework> Has anyone played around with PyAV? I'm trying to do basic screen recording but I am pretty lost. [14:27:49 CEST] <JEEB> yup, `OBJS-$(CONFIG_MOV_MUXER) += movenc.o av1.o avc.o hevc.o vpcc.o` [14:27:55 CEST] <JEEB> so MOV_MUXER has av1.o [14:28:15 CEST] <DHE> that's the right fix as is... [14:28:30 CEST] <JEEB> yes, but matrosak muxer probably misses it [14:28:34 CEST] <JEEB> while using the exports [14:28:42 CEST] <JEEB> s/exports/symbols/ [14:28:54 CEST] <DHE> yes, it's an error in the commit which should have added the Makefile deps [14:28:59 CEST] <JEEB> yes [14:29:15 CEST] <JEEB> anyways, $dayjob [14:29:17 CEST] <DHE> but the question being asked here is, for a "minimal" config, should it be possible to ./configure that patch right out? [14:29:25 CEST] <DHE> as you said, #ifdef the AV1 stuff away [14:29:35 CEST] <JEEB> no [14:29:43 CEST] <JEEB> we already have AVC/HEVC parsers in there are deps [14:29:46 CEST] <JEEB> and VPx [14:29:57 CEST] <JEEB> in some cases if there's a dependency on a decoder or so [14:30:00 CEST] <JEEB> that'd make sense [14:30:06 CEST] <JEEB> for just the parser, nope [14:30:53 CEST] <Kam_> a compontent always comes in a "complete" fashion? [14:31:16 CEST] <DHE> matroska support means support for all codecs matroska can handle [14:31:17 CEST] <Kam_> so, webm muxer is always able to handle AV1? [14:31:31 CEST] <JEEB> in general, there IIRC are some exceptions [14:31:36 CEST] <Kam_> yeah, I see. then this makes sense to me. [14:31:59 CEST] <JEEB> ok, libavformat generally seems to not have it [14:32:09 CEST] <JEEB> looking at git grep "#ifdef" -- libavformat/ [14:32:26 CEST] <JEEB> there's some OS specific checks but not feature checks [14:33:25 CEST] <JEEB> and ok, it is better than I thought in libavcodec as well :D [14:33:48 CEST] <JEEB> so yes, if you enable some feature then it should get fully enabled [14:34:07 CEST] <Kam_> could I -- in theory -- encode AV1 with a different program and feed it to FFmpeg to mux it in matroska? [14:34:33 CEST] <Kam_> .. without FFmpeg having a AV1 encoder [14:35:24 CEST] <JEEB> yes [14:36:01 CEST] <JEEB> with the API that is, the command line app would also need the required inptu modules enabled [14:36:04 CEST] <JEEB> like the IVF demuxer [14:36:37 CEST] <JEEB> so you'd receive encoded data and put that buffer into AVPacket [14:36:55 CEST] <JEEB> then feed that AVPacket to an instance of matroskaenc [14:39:33 CEST] <Kam_> good, then it sounds like the dependency is missing in Makefile, and not to #ifdef it [14:39:55 CEST] <JEEB> yup [14:40:08 CEST] <termos> Setting -rtmp_flashver from ffmpeg command line works great, but it is not set when I do av_opt_set(format, "rtmp_flashver", "FMLE test version", 0); Am I doing something wrong here? [14:54:48 CEST] <Kam_> is WebM also able to contain an AV1 stream? [14:56:48 CEST] <termos> Figured out I have to set the AVDictionary to avio_open2 function when I open the RTMP stream [14:58:10 CEST] <Kam_> or is there even a difference between WebM muxer and Matroska? (there is no WebM demuxer, I have to use the Matroska demuxer for webm) [14:58:17 CEST] <DHE> Kam_: you might also copy pre-encoded AV1 from one .mkv to another, etc. [15:01:51 CEST] <th3_v0ice> Can anyone help with audio stream delay? Any info is more then welcome. [15:01:59 CEST] <Kam_> DHE: I'm pulling in the WebM muxer in my configuration, not Matroska. If AV1 is not part of WebM, then #ifdef'ing it down might also be an idea additionally. [15:03:33 CEST] <JEEB> Kam_: it'll be in both webm profile and matroska profile in the end [15:03:49 CEST] <JEEB> after all, webm is just a subset of matroska, a profile by GOOG [15:12:59 CEST] <zerodefect> Using the C-API, is there a way to get the frame type from the x264 encoder in AVPacket (once encoded). I've seen there is a way to get if a keyframe but that doesn't differentiate between say B/P frames. [15:13:29 CEST] <Kam_> I added 'av1.o' to OBJS-$(CONFIG_MATROSKA_MUXER) and OBJS-$(CONFIG_WEBM_MUXER) in libavformat/Makefile and it works -- thanks! :) [15:28:58 CEST] <DHE> zerodefect: keyframes are indicated as such. otherwise you will have to guess that P-frames have pts==dts and B-frames do not [15:29:10 CEST] <DHE> even so that's not quite 100% but it's most of the way there [15:30:08 CEST] <zerodefect> Oh ok. Thanks for tip. Can I ask when that won't hold true? Seems easier than parsing NAL units :) [15:38:33 CEST] <DHE> a keyframe and an I-Frame are not necessarily the same thing with H264. I and IDR have different semantics [15:41:25 CEST] <termos> I've seen this way of getting frame types, is it not correct for H264? https://github.com/FFmpeg/FFmpeg/blob/master/fftools/ffmpeg.c#L741-L744 [15:41:29 CEST] <zerodefect> Ok thanks. I'll do some research - I need to understand more. You've given me a lot to go on. [15:42:54 CEST] <zerodefect> Thanks @termos, nifty. I'll try that out. [16:27:00 CEST] <certaindestiny> Hi All, We have a blackmagic decklink card installed in this server and are able to transcode video, So far so good, however we would like to check the bitrate for the video every couple of seconds so we can generate graphs etc of the video being sent [16:27:06 CEST] <certaindestiny> I tried this with ffprobe -f decklink -i <input> but it is not working [16:27:24 CEST] <certaindestiny> input/output error [16:28:46 CEST] <certaindestiny> Anybody any idea how to achieve this [16:36:27 CEST] <Nacht> certaindestiny: Might be worth looking at this examepl [16:36:29 CEST] <Nacht> https://github.com/zeroepoch/plotbitrate [16:44:45 CEST] <certaindestiny> Nacht, Thanks for the response, We however do not control the way the stream gets started as this is done by third party software. We are simply looking to query the decklink card for its current bitrate [16:46:55 CEST] <kepstin> i thought the decklink cards just gave you raw video, did they add hardware encoders to them? [16:49:32 CEST] <kepstin> if you want to find the bitrate of the encoded video, you'd probably want to analyze the stream being output by the third party software... [16:52:32 CEST] <JEEB> pretty sure the avdevices don't take in non-raw [16:52:44 CEST] <JEEB> so if it's input via decklink avdevice then it's raw [17:55:48 CEST] <leif> If avstream_duration() returns -9223372036854775808, does that mean something special to ffmpeg? [17:56:07 CEST] <leif> (Like, I don't know how a stream can have a negative duration per se.) [17:56:50 CEST] <leif> OHHH....that's the AV_NOPTS_VALUE...facepalm. [17:57:01 CEST] <leif> I wonder why a file would have that though... [18:05:29 CEST] <JEEB> leif: there are various formats where the duration is not known before hand [20:02:48 CEST] <dscastro> hello, i'm wondering why i'm losing quality when getting a rtsp feed from a security camera. [20:05:01 CEST] <dscastro> this is the command i ended up: [20:05:04 CEST] <dscastro> ffmpeg -rtsp_transport http -i 'rtsp://${RTSPURL}' \ [20:05:04 CEST] <dscastro> -map 0 -r 20 -g 40 -bufsize 512K -maxrate 2M -crf 15 -vf scale=1920:1080 -vf scale=1280:720 \ [20:05:04 CEST] <dscastro> -f segment -segment_time 10 -segment_format mp4 -strftime 1 "capture-%03d-%Y-%m-%d_%H-%M-%S.mp4" [20:11:54 CEST] <ChocolateArmpits> dscastro, why have you specified -vf scale two times ? [20:15:24 CEST] <dscastro> ChocolateArmpits: could be lack of understand but as far as i could se, ffmpeg is smart enough to detect the best scale within a INPUT, isn't it? [20:15:32 CEST] <dscastro> *see [20:15:55 CEST] <ChocolateArmpits> Other than that, your bufsize and maxrate may be inadequate for the crf you picked. The crf you picked would by itself generate higher bitrate video, but due to ratecontrol constraints it probably never gets utilized fully [20:16:40 CEST] <ChocolateArmpits> dscastro, you're supposed to specify -vf only once and then have a chain of filters that process input frames [20:17:52 CEST] <dscastro> ChocolateArmpits: you think this is the root of the poor quality? [20:18:09 CEST] <ChocolateArmpits> What's the output resolution? [20:19:11 CEST] <dscastro> ChocolateArmpits: this is a standard 1Mpx camera, so i assume this will be 1280x720 [20:19:34 CEST] <ChocolateArmpits> dscastro, can you post your console output? [20:22:26 CEST] <ChocolateArmpits> The console output should have input parameters listed like resolution [20:22:55 CEST] <dscastro> ChocolateArmpits: https://paste.fedoraproject.org/paste/ScVoxuakuE3eFEeCsVnNXA [20:24:08 CEST] <ChocolateArmpits> dscastro, the input resolution is only 352x288. Are you sure you have configured the camera correctly or have picked the right stream? [20:25:27 CEST] <dscastro> ChocolateArmpits: ohh.. you are right [20:25:45 CEST] <dscastro> i haven't payed attention on it. [20:25:53 CEST] <dscastro> let me see [20:29:35 CEST] <dscastro> ChocolateArmpits: you were right, i picked up the wrong stream url [20:30:31 CEST] <dscastro> ChocolateArmpits: would you mind pointing me to the right direction about buffer_size, maxrate , crf and etc? [20:31:33 CEST] <dscastro> i have a early beta to get rtsp streams and put it on a s3 bucket to storage and even a "near real" stream [20:38:18 CEST] <ChocolateArmpits> dscastro, you can read this https://slhck.info/video/2017/03/01/rate-control.html [20:47:16 CEST] <dscastro> ChocolateArmpits: tks ! [20:48:26 CEST] <ChocolateArmpits> np [22:05:38 CEST] <feedbackmonitor> Hello, I had some video footage at 24 fps which was 4.3 gb and then output it to 60 fps, but that file is 315.4 mb . The command I used was ffmpeg -i P1170226.MOV -c:v libx264 -preset veryslow -crf 24 -r 60 -profile:v high -level 4.1 -tune film -acodec copy output60fps.MOV [22:05:38 CEST] <feedbackmonitor> My concern is quality of the output. [22:06:52 CEST] <feedbackmonitor> Because that will be used for a 'master project' where it is set at 60 fps for the majority of the footage [22:07:26 CEST] <BtbN> Why would you convert 24 fps to 60? There's nothing to gain by doing that. [22:07:43 CEST] <furq> well your source was 50mbit 1080p so the output isn't going to be that high [22:07:48 CEST] <furq> you probably still want to set crf though [22:08:19 CEST] <feedbackmonitor> BtbN, In the video editor I have, when I input the 24 fps into the 60 fps project, the audio /video is out of sync, so there is that [22:08:51 CEST] <BtbN> If you want this only for editing, you can probably use some lossless intermediate codec [22:09:31 CEST] <feedbackmonitor> My project is recorded in h264, what do you advise? [22:09:45 CEST] <furq> what video editor are you using [22:09:49 CEST] <feedbackmonitor> Blender [22:10:19 CEST] <furq> blender supports ffv1, so try that [22:10:56 CEST] <furq> actually it doesn't say if it supports lossless h264 but if it supports ffv1, it's probably using ffh264 to decode [22:11:04 CEST] <furq> so if you're making a file with a ton of dup frames, try that first [22:11:17 CEST] <furq> add -qp 0 to the command you have now [22:11:44 CEST] <furq> also bear in mind both of those will be way bigger than 50mbit [22:12:19 CEST] <feedbackmonitor> furq, Where do I add the -qp 0? [22:12:28 CEST] <furq> as an output option [22:12:38 CEST] <furq> get rid of -crf 24 and put -qp 0 there [22:13:26 CEST] <feedbackmonitor> furq, I can still output to mov format? [22:13:35 CEST] <furq> yes with lossless h264 [22:13:45 CEST] <furq> you'd need mkv or nut for ffv1 [22:13:55 CEST] <furq> blender supports mkv so that's fine [22:14:34 CEST] <BtbN> mov isn't exactly a good format for that stuff anyway [22:15:24 CEST] <feedbackmonitor> BtbN, That is what my camera records at [22:15:36 CEST] <BtbN> so? [22:15:43 CEST] <feedbackmonitor> BtbN, Nothing I can do until I buy a new camera [22:15:54 CEST] <BtbN> And you need to output to mov again because? [22:16:15 CEST] <feedbackmonitor> BtbN, This is not final output, it is just to have working files [22:16:32 CEST] <feedbackmonitor> BtbN, for the master project and then I can do final output to something else [22:16:40 CEST] <BtbN> And why do you use mov for that? [22:17:07 CEST] <feedbackmonitor> BtbN, Because that is what my camera records at, unless you think I should mix formats in the video project? [22:17:24 CEST] <furq> it makes no difference what the files you import into blender are [22:18:20 CEST] <feedbackmonitor> furq, http://pastebin.centos.org/1601886/ [22:18:45 CEST] <furq> get rid of -profile, -level and -tune [22:19:37 CEST] <feedbackmonitor> furq, thanks [23:17:43 CEST] <_Mike_C_> Hello, could anyone point me to an example that would show me how to programatically set up the h264_nvenc and hvec_nvenc? [00:00:00 CEST] --- Fri Aug 24 2018

1 0

ffmpeg-devel.log.20180822
by burek 23 Aug '18

23 Aug '18

[00:17:43 CEST] <JEEB> asdf [00:18:13 CEST] <JEEB> apparently we have a performance thing with tls_schannel around the same time the EOF != 0 thing happened [00:18:23 CEST] <JEEB> but I can't see anything glaringly obvious [00:18:26 CEST] <Compn> http://www.otakuusamagazine.com/66-pounds-hentai-confiscated-comiket-goer-s… [00:18:29 CEST] <JEEB> and it's not like TLS doesn't work [00:18:51 CEST] <JEEB> and we're not getting bug reports on this because the most utilized ffmpeg.c builds (zeranoe's) utilize gnutls [00:18:56 CEST] <JEEB> which seemingly seem to work better [00:19:06 CEST] <JEEB> *which seemingly seems to work better [00:19:47 CEST] <JEEB> people mostly seem to notice the issues with HLS playback with schannel, gnutls seems to work quite a bit better [00:20:24 CEST] <JEEB> I tried to look at tls_read but as I noted I couldn't figure out anything glaringly obvious [00:20:52 CEST] <nevcairiel> try with -http_persistent 0 [00:21:57 CEST] <JEEB> with a quick look that's faster [00:22:27 CEST] <nevcairiel> for some reason that mode seems to mess up with schannel [00:22:29 CEST] <nevcairiel> no clue why [00:27:32 CEST] <JEEB> the issue @ mpv had someone make retry_transfer_wrapper return not only with < 0 but with <= 0 as well, which supposedly for some improved performance. personally I don't see it [00:27:36 CEST] <JEEB> https://github.com/mpv-player/mpv/issues/5286#issuecomment-354140558 [00:28:23 CEST] <nevcairiel> that was probably before schannel was fixed for EOF returns [00:28:36 CEST] <JEEB> quite possible [00:28:58 CEST] <JEEB> since you're not supposed to return zero from that function with such protocols anyways [00:29:23 CEST] <JEEB> (you get a warning) [00:47:29 CEST] <cone-578> ffmpeg 03Jacob Trimble 07master:7e0df5910ec0: avcodec/opus_parser: Handle complete frames flag. [03:49:55 CEST] <atomnuker> bofh_: ping [03:53:29 CEST] <bofh_> atomnuker: pong [03:54:33 CEST] <atomnuker> do you think its possible to change transform direction by changing the pre/post reindexing? [03:55:01 CEST] <atomnuker> our ptwo fft does it that way, but don't know if its possible to do in mdct15 as well [03:55:40 CEST] <atomnuker> currently we conjugate the imaginary values of the exptabs [03:57:33 CEST] <atomnuker> *the values of the exptabs [04:01:09 CEST] <bofh_> atomnuker: hrm. not sure. the fact that you can do it that way for split-radix 2/4 Cooley-Tukey seems more luck than anything (it's not possible to do it that way for regular radix-2 DIT Cooley-Tukey IIRC), but I'll think about it / ch3c3ck 3ckeck gh3 the literature over lucnch [04:01:16 CEST] <bofh_> lunch* [04:02:28 CEST] <bofh_> conjugating exptab values is the canonical way to do it & works for any order FFT btw. [04:04:49 CEST] <atomnuker> ktnx, I'd really rather not store huge tables in our fft context which only differ by their sign [04:05:40 CEST] <atomnuker> it doesn't help that the complex values we'd be storing will change size depending on whether float/double or int fft is used [04:05:49 CEST] <bofh_> they're runtime-generated tho so they'd live in RAM/stack [04:06:21 CEST] <bofh_> also doubles for audio fft is massive overkill imho. [04:06:30 CEST] <atomnuker> yes, currently for the non power of two fft, for the ptwo fft they're generated on init once unless config_small is disabled [04:07:10 CEST] <atomnuker> it won't just be used for audio though, durandal_1707 was requesting it for a filter [04:08:28 CEST] <bofh_> using doubles in af_* is still overkill for all but very few cases, but that's a discussion for another time. [04:08:44 CEST] <bofh_> and ahh. [04:09:55 CEST] <bofh_> well I'll try seeing if doing it via reindexing alone is possible & poke you this evening. [04:10:58 CEST] <bofh_> well, early afternoon for you if I'm remembering your timezone correctly. [04:17:35 CEST] <atomnuker> ping me whenever, it hardly matters when I'm not aligned to what people use here [09:41:19 CEST] <durandal_1707> Compn: are you ignoring me? [09:43:35 CEST] <cone-030> ffmpeg 03Zhong Li 07master:900487043b6e: lavc/qsvenc: add quality status to side_data [10:57:42 CEST] Action: JEEB makes a trac issue for the H.264 decoding barf [10:58:26 CEST] <durandal_1707> Carl will close it for sure if he can not reproduce it [10:58:39 CEST] <JEEB> don't worrty [10:58:52 CEST] <JEEB> the sample reproduces on all versions of FFmpeg I've had on hand :P [11:07:21 CEST] <JEEB> ^ durandal_1707 , pretty sure even you can repro this :D [11:21:03 CEST] <kierank> JEEB: I want to create a "super-fate" for things like this [11:36:27 CEST] <jdarnley> > Not a regression afaict, the following works fine [11:36:33 CEST] <jdarnley> > -skip_initial_bytes 2000000 [11:37:13 CEST] <cone-030> ffmpeg 03Martin Vignali 07master:3af1c4ea7d18: swscale : treat float input data as uint 16bpc [11:37:14 CEST] <cone-030> ffmpeg 03Martin Vignali 07master:bdd67546482b: swscale/swscale : small cosmetic [11:37:15 CEST] <cone-030> ffmpeg 03Martin Vignali 07master:9e64ee3936b1: avcodec/psd : add support for gray float [11:37:36 CEST] <kierank> jdarnley: wow you're not joking either [11:39:11 CEST] <jdarnley> I guess that gives someone an idea of what it should look like after they fix the bug. [11:40:15 CEST] <durandal_1707> TIL emblaze .EA files uses gsm codec [11:49:35 CEST] <JEEB> jdarnley: yup. I did note in the initial description that it would work if you started decoding after the glitch/whatever [12:10:19 CEST] <durandal_1707> which decoder is this: https://pastebin.com/QnsewCt6 [12:14:31 CEST] <BradleyS> System.out.println("Timebomb :" + TimeBomb()); [12:14:31 CEST] <BradleyS> System.out.println("Emblaze Video : This copy has EXPIRED"); [12:14:58 CEST] Last message repeated 1 time(s). [12:14:58 CEST] <BradleyS> if (TimeBomb()) [12:14:59 CEST] <BradleyS> heh [12:16:19 CEST] <BradleyS> probably this: https://www.zdnet.com/article/emblaze-video-fizzles-out/ [12:17:45 CEST] <jdarnley> > ecommends Netscape Navigator 4.0 [12:17:51 CEST] <jdarnley> Then I looked at the date [12:20:07 CEST] <BradleyS> i like how the article subhead claims it's plugin-less video technology when it requires and ships it's own java applet [12:20:42 CEST] <BradleyS> i guess it's technically a runtime and maybe not specifically using netscape's plugin api but yeah... far from native [12:42:07 CEST] <durandal_1707> what decoder should i do next? i'm out of ideas [12:43:30 CEST] <JEEB> did you already get bored of bink2? [12:45:18 CEST] <durandal_1707> i got very frustrated, i couldn't get bitstream parsing of old variant working, and because of multithreading any debugging is futile [12:50:39 CEST] <kierank> durandal_1707: can you not run in vm and set cpus to 1 [12:53:09 CEST] <durandal_1707> kierank: wouldn't kernel scheduler switch threads anyway? [12:53:28 CEST] <kierank> durandal_1707: depends, they may have a thing to check cpus and spawn threads accordingly [13:07:47 CEST] <cone-030> ffmpeg 03Jun Zhao 07master:c4608d225faf: lavf/hlsenc: fix mixed declarations and code warning. [13:07:48 CEST] <cone-030> ffmpeg 03Jun Zhao 07master:e2921578c09e: lavc/libkvazaar: fix incompatible pointer type. [13:15:45 CEST] <cone-030> ffmpeg 03Steven Liu 07master:9e61141905b5: avformat/hls: support decryption AES128 fmp4 m3u8 list [14:11:21 CEST] <pasouza> Hi, I'd like to call anyone interested in the use of swscale in the SR filter to follow the ml discussion (http://ffmpeg.org/pipermail/ffmpeg-devel/2018-August/233233.html) [14:11:36 CEST] <pasouza> and argue for or against it before we make any final decision [14:15:58 CEST] <azaki> Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.32), passed through in regex; marked by <-- HERE in m/^\s+@([[:alnum:]][[:alnum:]\-]*)({ <-- HERE })?\s*/ at /usr/share/texinfo/Texinfo/Parser.pm line 5481. [14:16:06 CEST] <azaki> was building ffmpeg-git in arch, and got this warning [14:16:33 CEST] <azaki> i'm guessing it's known by now? =o [14:17:08 CEST] <azaki> seems to be during the configure stage [14:22:58 CEST] <nevcairiel> isnt that error from your local TexInfo package [14:23:07 CEST] <nevcairiel> or warning for that matter [17:11:23 CEST] <cone-955> ffmpeg 03Baptiste Coudurier 07master:130de9142edd: avformat/mxfenc: automatically update descriptors klv size [18:02:28 CEST] <durandal_1707> michaelni: if you find time, do you gonna review prosumer decoder? [18:13:43 CEST] <durandal_1707> libavformat/tls_openssl.c:105:46: warning: comparison of function 'openssl_lock' equal to a null pointer is always false [-Wtautological-pointer-compare] [18:13:46 CEST] <durandal_1707> if (CRYPTO_get_locking_callback() == openssl_lock) { [18:13:48 CEST] <durandal_1707> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~ [18:13:51 CEST] <durandal_1707> libavformat/tls_openssl.c:105:46: note: prefix with the address-of operator to silence this warning [18:13:54 CEST] <durandal_1707> if (CRYPTO_get_locking_callback() == openssl_lock) { [19:00:33 CEST] <cone-955> ffmpeg 03Jacob Trimble 07master:eb350ab738e7: avformat/mov: Allow saio/saiz in clear content. [19:00:34 CEST] <cone-955> ffmpeg 03Fredrik Hubinette 07master:5ecd580953bb: avformat/utils: avoid undefined integer overflow behavior in update_stream_timings() [19:01:46 CEST] <cone-955> ffmpeg 03Zhao Zhili 07master:70d2bab80b38: lavc/hevc_ps: fix crop info for monochrome [19:14:42 CEST] <thardin> hrm, mxfdec timestamp issue [20:41:55 CEST] <rcombs> durandal_1707: CRYPTO_get_locking_callback() was changed to a macro returning NULL in 1.1.0; you can make that compile-time-conditional on the version if you like [22:16:55 CEST] <durandal_1707> Compn: are you awake? [23:17:16 CEST] <jdarnley> Is it just me or does this monitor look better now I connected it on DVI rather than HDMI? [23:25:15 CEST] <kierank> jdarnley: ? [23:29:37 CEST] <wbs> jdarnley: some monitors display colors differently depending on HDMI and DVI connection, yes. HDMI connections usually run YCbCr while DVI connections run RGB, even though both could handle both. and monitors usually treat YCbCr differently even though it technically shouldn't matter [23:37:36 CEST] <atomnuker> and even then some want limited range rgb even though they can handle full range just fine [23:39:02 CEST] <atomnuker> TVs are hell and you shouldn't rely on them having anywhere near accurate colors nor that the image won't be filtered and noised/denoised [23:39:59 CEST] <jkqxz> ... / overscanned / delayed by up to a second / etc. [23:40:33 CEST] <jdarnley> This is a desktop PC display and now you mention TV range... that would fit. [23:40:55 CEST] <jdarnley> It seems to be quite a bit brighter, and whiter, with the idential one next to it. [23:41:01 CEST] <atomnuker> jkqxz: you've seen a TV which delays so long? damn, I thought 300ms I saw once was bad [23:41:28 CEST] <jdarnley> It was never a perfect match but this is now brighter, sharper [23:41:40 CEST] <jdarnley> with better black too, maybe [23:42:06 CEST] <jdarnley> I've been missing out! [23:42:48 CEST] <jdarnley> Maybe I should clarify that this is an HDMI-DVI cable. [23:42:56 CEST] <jdarnley> I think I'll buy two more [23:43:34 CEST] <jkqxz> I've seen over 500ms. (It fucks epically with echo cancellation when you have microphones in the room as well.) [23:43:58 CEST] <jkqxz> Generally TVs have some sort of "game mode" or similar function which you should always use, because it turns off the stupidest delay parts. [23:45:22 CEST] <atomnuker> sadly they turn the backlight down for some reason on game mode, and some still do filtering even then, though nothing fancy [23:46:03 CEST] <jkqxz> The cable shouldn't make any difference, because the wires are identical (excepting the lack of CEC in DVI). That doesn't rule out either end deciding to treat the different connectors differently, though. [23:46:11 CEST] <atomnuker> I wonder how they store potentially 100mb of data and some even do temporal interpolation, isn't memory quite expensive [23:46:41 CEST] <jdarnley> One chip buffing just a little, then another, then another? [23:46:43 CEST] <jkqxz> They need a few GB of memory to run their shitty android UIs anyway. [23:46:58 CEST] <jkqxz> (Or webos, of course.) [23:48:46 CEST] <atomnuker> right, that's probably why, they buffer and rely on android to display, maybe [00:00:00 CEST] --- Thu Aug 23 2018

1 0

ffmpeg.log.20180822
by burek 23 Aug '18

23 Aug '18

[02:53:11 CEST] <ldlework> How do I check if I have VP9 support [02:57:04 CEST] <Hello71> ffmpeg -codecs [03:36:38 CEST] <leif> Does anyone have any idea why ffmpeg would set the time base to 1/1000000 with the following filter graph: [03:36:41 CEST] <leif> https://gist.github.com/LeifAndersen/8cb1294a4e96d4c8bdd0e4805e96d11d [03:39:43 CEST] <leif> (I also tried using "time_base=1/1000" as part of the buffersink filter, but ffmpeg still seems to change it back to 1/1000000 [04:33:58 CEST] <leif> (Also, for what its worth, I'm getting the time base with av_buffersink_get_time_bae() ) [04:35:04 CEST] <atomnuker> some containers have specific hardcoded timebases [04:39:46 CEST] <leif> atomnuker: That would make sense. Although the container I'm using is mp4 with h264 as the codec. [04:40:08 CEST] <leif> Leading to the error: timebase 1/1000000 not supported by MPEG 4 standard, the maximum admitted value for the timebase denominator is 65535 [04:51:48 CEST] <furq> leif: fyi you don't need to use explicit labels if the output of one filter and the input of the next filter are the same [04:52:16 CEST] <furq> e.g. [audio16]afifo[audio17];[audio17]afifo[audio18] is the same as [audio16]afifo,afifo[audio18] [04:52:26 CEST] <furq> (i'm not going to ask what that actually does) [05:05:34 CEST] <leif> furq: lol, ya. The graph was actually programatically built, and that's just how it gets rendered to text. [05:06:12 CEST] <leif> atomnuker: I guess put another way, as far as I can tell, the filter graph doesn't really deal with containers (as I understand it), so how would it know what container requirements are? [05:07:16 CEST] <atomnuker> the muxer itself can adjust the timestamps to whatever timebase it needs, though usually you're required to give the correct one [05:18:18 CEST] <ldlework> I'm just getting started with ffmpeg. Why would the following have a bunch of color corruption in the recording? [05:18:20 CEST] <ldlework> ffcast % /nix/store/9rckxnnabglaf4p2fad97hp3nknhwkgg-ffmpeg-4.0-bin/bin/ffmpeg -f x11grab -framerate 10 -video_size %s -i %D+%c -vcodec libvpx-vp9 -acodec libvorbis -show_region 1 ~/media/captures/3c651290.webm [05:18:49 CEST] <ldlework> like the colors are all wrong in the video [05:20:05 CEST] <ldlework> white is pink, black is green [05:21:43 CEST] <ldlework> hmm seems to only be when I use libvpx-vp9 [05:21:51 CEST] <ldlework> if i just use libvpx it works ok [05:22:08 CEST] <ldlework> quality is really bad though [05:22:46 CEST] <furq> vp9 supports rgb, so if i had to guess i'd say your player doesn't support rgb in vp9 properly [05:22:50 CEST] <leif> atomnuker: Makes sense. I'll look into that, thanks again. [05:23:24 CEST] <furq> ldlework: add -pix_fmt yuv444p [05:23:48 CEST] <furq> all desktop browsers that support vp9 support 4:4:4, idk about mobile [05:25:41 CEST] <ldlework> furq: do you have any recommendations for recording terminals in perfect clarity but not silly inefficient? [05:25:52 CEST] <ldlework> i have a LOT of artifacts in my video [05:26:07 CEST] <ldlework> especially as text moves and stuff [05:26:42 CEST] <ldlework> furq: look at this lol https://i.imgur.com/9WW6laO.png [05:28:41 CEST] <ldlework> furq: ah when i went back to vp9 with your setting it improved a lot [05:28:48 CEST] <ldlework> not perfect but big improvment [05:29:42 CEST] <ldlework> https://i.imgur.com/Zxb3ut6.png [05:33:00 CEST] <furq> the default bitrate for vp9 is 200kbps [05:33:05 CEST] <furq> so you probably want to bump that [05:33:40 CEST] <ldlework> constant quality did the trick [05:33:56 CEST] <ldlework> furq: I added -crf 30 -b:v 0 [05:34:15 CEST] <ldlework> I guess that is going to make my files really big though [05:34:38 CEST] <furq> shouldn't be too bad [05:34:55 CEST] <furq> i mean my actual recommendation for recording terminals would be to use something like asciinema [05:35:13 CEST] <furq> or an equivalent thing that isn't -as-a-service [05:35:16 CEST] <ldlework> well it isn't just terminals [05:35:42 CEST] <ldlework> emacs gui mode, terminals, dmenu and so on [05:35:51 CEST] <ldlework> mostly text on flat backgrounds is what I meant to say [05:36:08 CEST] <ldlework> where sometimes the text scrolls or the whole scene changes instantly, etc [05:36:11 CEST] <furq> do you need browser support [05:36:22 CEST] <ldlework> I want to display the webm in browsers yeah [05:36:30 CEST] <furq> you're more or less stuck with vp9 then [05:36:31 CEST] <ldlework> but most videos should be short [05:36:36 CEST] <ldlework> ok [05:36:45 CEST] <furq> h264 would be the only alternative and most browsers don't support 4:4:4 h264 [05:36:55 CEST] <ldlework> furq: what would be the best youtube stuff if I was going to make an actual video recording with voice and stuff [05:37:04 CEST] <ldlework> same content, but full screen, longer, etc [05:37:13 CEST] <furq> it doesn't make much difference really [05:37:17 CEST] <furq> youtube will recompress everything [05:37:21 CEST] <ldlework> heh ok [05:37:53 CEST] <ldlework> furq: thanks a lot [05:38:18 CEST] <furq> if you're going to host it somewhere that recompresses it then you can try using ffv1 or something [05:38:37 CEST] <furq> it'll obviously be much bigger [05:58:26 CEST] <ldlework> furq: i set my -framerate 60 but it doesn't seem like 60 [05:58:33 CEST] <ldlework> when recording typing it see it in spurts [05:58:40 CEST] <ldlework> when smooth scrolling a browser it just jumps around [06:01:18 CEST] <ldlework> when recording it says fps=3.5 [06:09:02 CEST] <leif> atomnuker: So it looks like the sink's output codec is 'mpeg4, with a pixel format of yuv420p [08:27:52 CEST] <furq> ldlework: libvpx is principally famous for being incredibly slow [08:28:03 CEST] <furq> which is part of why i suggested using something lossless to capture [08:35:55 CEST] <ldlework> furq: i switched over to mp4 [08:36:05 CEST] <ldlework> when i term ffpmeg it is done encoding right away [08:36:07 CEST] <ldlework> which is nice [08:36:09 CEST] <ldlework> :P [08:43:47 CEST] <furq> ok but bear in mind 4:4:4 h264 doesn't have widespread browser support [08:43:54 CEST] <furq> firefox on windows definitely doesn't support it and never will [08:44:08 CEST] <furq> and probably on osx as well if anyone actually uses that [08:44:17 CEST] <furq> also anything chromium-based on windows (other than chrome) [08:44:33 CEST] <furq> if 4:2:0 looks ok to you then great, but for screen capturing it's probably going to look awful [08:44:45 CEST] <ldlework> i don't even know what you're saying at me :( [08:44:51 CEST] <furq> -pix_fmt yuv444p [08:44:55 CEST] <ldlework> ahhh [08:45:09 CEST] <ldlework> furq, I'm open to recommendations definitely [08:46:12 CEST] <furq> actually firefox doesn't support it anywhere for "consistency" with the fact they can't support it on windows [08:46:15 CEST] <furq> which is dumb but oh well [08:46:43 CEST] <ldlework> furq: I am mostly interested in two ways of recording one subject. Linux terminals and emacs and stuf, for embedding quick looping snippets in tutorial pages, and to youtube for longer formats. [08:46:58 CEST] <ldlework> It seems like there is a lot to learn [08:47:30 CEST] <furq> my recommendations would be: try -pix_fmt yuv420p and see if it looks ok; try messing with the libvpx speed settings (-cpu-used, -row-mt etc); encode to lossless rgb with ffv1 and then encode with libvpx later [08:47:35 CEST] <furq> in order of how annoying they'll be [08:47:45 CEST] <furq> bearing in mind youtube will make everything yuv420p anyway [08:48:39 CEST] <furq> you could also maybe try upscaling the input 2x, which should mitigate how bad yuv420p looks [10:21:33 CEST] <botik101> hello, can someone please explain to me why we need to use setpts when using beten? [10:22:30 CEST] <botik101> here ios an example https://pastebin.com/V26HZWzU [10:23:46 CEST] <botik101> why do i need to set the timestamps to be continuous using setpts=N/FRAME_RATE/TB [10:29:29 CEST] <botik101> can someone please tell me why this ffmpeg between command would not give me a video? I am running it now, and the poutput file is not playable. [10:29:43 CEST] <botik101> https://pastebin.com/V26HZWzU [10:41:44 CEST] <botik101> i need help with between statement for ffmpeg. [10:58:35 CEST] <botik101> can someone please tell me why this statement would not grab video? ffmpeg -t 200 -i video.mp4 -an -vf "select='between(t,166,12)+between(t,184,7)',setpts=N/FRAME_RATE/TB" out.mp4 [11:14:09 CEST] <furq> botik101: the first value in between has to be lower [11:18:30 CEST] <botik101> it is not? [11:19:10 CEST] <botik101> furq: t,166,12 means start from 166 second of the video for 12 seconds [11:19:29 CEST] <furq> yeah you'd need to do t,166,178 [11:22:01 CEST] <botik101> god dammit [11:22:04 CEST] <botik101> you are freaking right [11:22:16 CEST] <botik101> for some reason i thought it was t, start time, length [11:24:10 CEST] <furq> http://ffmpeg.org/ffmpeg-utils.html#Expression-Evaluation [11:24:42 CEST] <botik101> furq: ok, it is still copying only the audio track [11:28:51 CEST] <botik101> I took yoru advice and fixed between as this: ffmpeg -t 200 -i video.mp4 -vf "select='between(t,166,178) +between(t,184,191)', setpts=N/FRAME_RATE/TB" out.mp4 [11:29:19 CEST] <botik101> it is still only copying autiotrack... ffmpeg reports that it only wrote audio and no video [11:30:48 CEST] <botik101> I checked the input video - it is 2 hours of soccer game - I can see it... [11:38:56 CEST] <botik101> furq: I figured ut a problem (partially). if you specify only select for video and do not say -an, you actually get the whole file, only video will be present where it is inside between. The rest will only be sound...bizzare [11:43:23 CEST] <Mavrik> Why bizarre? [11:43:46 CEST] <Mavrik> If you leave a 2 hr audio track inside and only include 10 minutes of video in the middle, what else did you expect to happen? :P [11:45:31 CEST] <botik101> mavrik - - I thought that by using select filter, it would only copy the information when select filter would be true [11:45:54 CEST] <Mavrik> Yes, and it does. [11:46:04 CEST] <Mavrik> But it's a filter that only runs on the video :) [11:46:10 CEST] <Mavrik> (-vf = video filter) [11:46:13 CEST] <Mavrik> So audio track gets untouched. [11:46:16 CEST] <botik101> Mavrik: now it makes sense [11:46:17 CEST] <Mavrik> or any other streams [11:46:26 CEST] <Mavrik> *is untuched [11:46:44 CEST] <botik101> mavrik , I am more troubled by setpts = .... I cant figure out why it is necessary [11:47:05 CEST] <Mavrik> No idea, it retimestamps the frames [11:47:11 CEST] <Mavrik> Probably horribly breaking audio sync >P [11:47:19 CEST] <botik101> Mavrik: I understand that we need to copy the timestamps but why N/FRAME_RATE/TB and not N/TB or START_PCT [11:48:13 CEST] <Mavrik> No idea really :/ [11:48:37 CEST] <Mavrik> I'm guessing it also makes sure you have a constant framerate video [11:49:03 CEST] <Mavrik> Which on iOS makes sense due to camera recording a variable framerate video [11:49:13 CEST] <Mavrik> But it still probably makes it a bit judderz [11:49:17 CEST] <Mavrik> *juddery [12:56:34 CEST] <salatfreak> I'm trying to split a h264 video without reencoding it, so that I can concatenate the parts again without any stuttering. When using 'ffmpeg -t 2 -i video.mp4 -c copy start.mp4' and 'ffmpeg -ss 2 -i video.mp4 -c copy end.mp4' to split it and 'echo -e "file 'start.mp4'\nfile 'end.mp4'" | ffmpeg -safe 0 -protocol_whitelist file,crypto,pipe -f concat -i - -c copy concat.mp4' it does stutter unfortunately. How can I fix this? [13:11:56 CEST] <kepstin> salatfreak: when copying video without re-encoding, you can only cut starting on a keyframe. [13:12:16 CEST] <kepstin> salatfreak: if you want to cut at arbitrary times exactly, you have to reencode. [13:21:47 CEST] <salatfreak> kepstin: I'm fine with ffmpeg cutting at keyframes as long as the concatenated videos don't stutter. How can I make it do that? [13:22:54 CEST] <kepstin> if you don't want the concatenated videos to stutter, you have to find out in advance where the keyframes are, so you can sut on the exact correct times. Getting the end time right is important [13:23:26 CEST] <kepstin> but you might want to use the "segment" muxer instead for this case [13:23:37 CEST] <kepstin> it's designed to split files on keyframes [14:08:03 CEST] <salatfreak> kepstin: Yay! 'ffmpeg -i video.mp4 -f segment -segment_times 2 -c copy segment_%02d.mp4' does the job :) [17:50:16 CEST] <Triskel> hello ! [17:50:55 CEST] <Triskel> what is simpliest than obs to rtmp/streaming the desktop ? [17:51:43 CEST] <BtbN> what? [17:52:51 CEST] <ChocolateArmpits> there's probably none [18:34:06 CEST] <ariyasu> Triskel, https://trac.ffmpeg.org/wiki/Capture/Desktop [18:37:32 CEST] <kepstin> note that, particularly on windows, obs has a much better-performing screen capture than ffmpeg. [18:39:14 CEST] <atomnuker> and on linux ffmpeg has something that obs can't compare with anywhere - kmsgrab [19:15:30 CEST] <tmatth> atomnuker: whoa didn't know kmsgrab was a thing [19:15:33 CEST] <tmatth> neat [20:15:13 CEST] <kubast2> So I took a look at googles crf recommends for low res I am guessing the "37" for 240p is like there for lulz or they tested it on a 4k/1080p monitor without making it decentlly big inch/centimeters wise [20:15:29 CEST] <kubast2> like it makes me bleed my eyes [20:16:02 CEST] <kepstin> doesn't really matter what you set the quality to, 240p will make your eyes bleed unless it's no bigger than around 3-4" :/ [20:16:22 CEST] <kubast2> sure but like at 20 crf it looks pretty good for a 240p video [20:16:38 CEST] <kubast2> both a like 1:1 and 2:1 and 1080p fill it doesn't bleed artifacts at all times [20:16:39 CEST] <kubast2> at least [20:16:40 CEST] <furq> by google do you mean a google result or do you mean their recommendations for youtube [20:16:50 CEST] <kubast2> good VOD recomended settings [20:16:56 CEST] <kubast2> as in google [20:16:58 CEST] <furq> idk why i asked because they're both terrible [20:16:58 CEST] <kepstin> They made those recommendations based on youtube, iirc, where the 240p is only sent to people playing video on potatoes over 3g [20:17:27 CEST] <kepstin> so it was more important for it to be small instead of good looking [20:17:30 CEST] <kubast2> Yeah and on phones it would look a bit better I guess [20:17:41 CEST] <kubast2> even upscalled to 1080p I guess(?) [20:17:45 CEST] <DHE> also note that google transcodes everything, so within reason it's best to provide google high quality sources [20:18:21 CEST] <kepstin> but yeah, you'll basically never see the 240p stream on youtube unless you're in extremely bad network conditions [20:18:38 CEST] <leif> I asked a similar question last night (local time), but I'm having a similar problem so I'll try again (also thanks to atomnuker for the help last night.). Anyway: [20:18:43 CEST] <kepstin> if you have more bandwidth, they'd send you a bigger video size. [20:18:54 CEST] <kubast2> yeah I am figuring out what resolution and what crf can I get away with to transcode for my phone and fit as much videos as possible tbh [20:19:03 CEST] <BtbN> they send you 240p if you tab away but leave the video running [20:19:21 CEST] <leif> I have a filtergraph, and when I run avfilter_graph_config() on it, it sets the time base to 1/1000000 [20:19:25 CEST] <kepstin> ah, true, that works since they can switch the video/audio separately. [20:19:52 CEST] <kepstin> leif: what filters are in the filtergraph? filters can change the timebase. [20:19:53 CEST] <leif> But this is a problem because the output codec is mpeg4. So does anyone know why avfilter_graph_config() would change the output to an invalid time-base? [20:20:08 CEST] <kepstin> that's perfectly valid, that's AV_TB. [20:20:22 CEST] <leif> kepstin: https://gist.github.com/LeifAndersen/8cb1294a4e96d4c8bdd0e4805e96d11d [20:20:26 CEST] <kepstin> you probably just need to rescale timestamps when muxing to the container [20:20:35 CEST] <kubast2> BtbN, yeah 240p is the highest audio quality res on youtube afaik ,they don't increase the quality over it [20:20:48 CEST] <kubast2> as in they set 160kbps opus [20:20:50 CEST] <kepstin> youtube can independently switch audio and video quality [20:20:51 CEST] <kubast2> for 240p [20:20:54 CEST] <kubast2> oh [20:21:04 CEST] <leif> kepstin: I get this error: timebase 1/1000000 not supported by MPEG 4 standard, the maximum admitted value for the timebase denominator is 65535 [20:21:10 CEST] <leif> (When I begin to write.) [20:21:22 CEST] <DHE> leif: sounds like you forget to set the time_base parameter to the `buffer` filtergraph input [20:21:24 CEST] <kubast2> I didn't knew about that; 144p is locked to lower audio qualities though(?) at least as of right now ,that's how I suspected the site works [20:22:01 CEST] <DHE> snprintf(args, sizeof(args), "video_size=%dx%d:pix_fmt=%d:time_base=%d/%d:pixel_aspect=1/1",width, height, pixfmt, avfctx->streams[i]->time_base.num, avfctx->streams[i]->time_base.den); // what I'm using [20:22:04 CEST] <kepstin> leif: weird, when you set up the output format context with your requested timebase, it should have changed to to an acceptable value I thought. [20:22:17 CEST] <kepstin> or maybe it only does that when scaling up, not down [20:22:27 CEST] <DHE> see also: https://ffmpeg.org/ffmpeg-filters.html#buffer [20:22:38 CEST] <leif> DHE: The buffer arguments are: video_size=1920x1080:pix_fmt=0:time_base=1/1000 [20:22:49 CEST] <kepstin> leif: anyways, I think the concat filter always outputs with AV_TB, you could try just throwing an fps filter after it. [20:23:14 CEST] <leif> kepstin: AH, okay. That may be it, I'll give it a shot! Thanks. [20:23:47 CEST] <kepstin> but I forget exactly how that interacts with the filter stuff :/ [20:24:10 CEST] <kepstin> (it's weird, and that's one of the sources of those 'past duration too large' messages you sometimes see with ffmpeg) [20:24:17 CEST] <leif> kepstin: OMG, that seems to work. [20:24:32 CEST] <leif> thank you so much. [20:24:49 CEST] <kepstin> I have a half-written patch hanging around that makes concat preserve the timebase if all inputs match :/ [20:24:55 CEST] <kepstin> maybe i should finish that [20:25:14 CEST] <kepstin> (current concat filter is broken if a later input has a higher fps than an earlier input, btw) [22:11:39 CEST] <leif> kepstin: Hmm...thanks for the heads up. [22:12:08 CEST] <leif> Anyway, I'm programmatically generating the filtergraph (which is why there was the redundant fifos), so its not a big deal to just change it back. :) [22:12:15 CEST] <leif> Anyway, thanks again. [00:00:00 CEST] --- Thu Aug 23 2018

1 0

ffmpeg-devel.log.20180821
by burek 22 Aug '18

22 Aug '18

[09:45:44 CEST] <cone-881> ffmpeg 03Steven Liu 07master:dcef44f13625: avfilter/buffersrc.h: fix typo of the comment [12:11:32 CEST] <durandal11707> i'm seeking AC-4 files [12:12:53 CEST] <JEEB> the DASH-IF sample set IIRC has some AC-4 samples [12:15:35 CEST] <durandal11707> JEEB: where is that? [12:17:19 CEST] <cone-881> ffmpeg 03Paul B Mahol 07master:42a99b76de98: avcodec: add IMM4 decoder [12:17:20 CEST] <cone-881> ffmpeg 03Paul B Mahol 07master:a39fdc97b73f: doc/general: add some missed codecs [12:17:21 CEST] <cone-881> ffmpeg 03Paul B Mahol 07master:6972dae5a494: avformat/avidec: fix demuxing of all keyframes of sample 200707170736151.avi [12:19:09 CEST] <JEEB> durandal11707: http://testassets.dashif.org/ [12:19:28 CEST] <JEEB> http://testassets.dashif.org/#feature/details/586fb3879ae9045678eab593 [12:19:36 CEST] <JEEB> that's the AC-4 test vectors [12:20:06 CEST] <JEEB> (if that link doesn't work, that's Features->List->Dolby Audio AC-4 [12:20:34 CEST] <JEEB> as far as I know, that's the only samples of AC-4 I've seen [12:23:17 CEST] <durandal11707> cool, thank you [12:25:20 CEST] <j-b> IMM5, IMM6 and IMM3 exist too? [12:27:55 CEST] <durandal11707> j-b: i doubt IMM3 exist, for IMM5 we have one sample, for IMM6 there are no samples [14:46:47 CEST] <j-b> Did someone do something cool about audio, this year? [14:54:03 CEST] <kurosu_> Xiph did some CNN-based denoising ? /o\ [15:02:20 CEST] <kierank> durandal11707: really [15:02:26 CEST] <kierank> you want to implent dolby ac4 [15:02:27 CEST] <kierank> eugh [15:15:25 CEST] <cone-881> ffmpeg 03Timo Rothenpieler 07master:dc2d56a66b8a: avcodec/nvenc: add option to turn off a53 closed caption embedding [16:08:00 CEST] <durandal11707> ffmpeg -i http://streaming.dolby.com/ftproot/mitXperts/ts/ts_multi_codec.ts -f null - [16:08:08 CEST] <durandal11707> ^ this errors out [17:14:04 CEST] <cone-881> ffmpeg 03Paul B Mahol 07master:24b24e14d647: avcodec/codec_desc: mark Duck TrueMotion 2.0 Real Time as intra only [17:21:39 CEST] <atomnuker> wasn't ac-4 just a container? [17:22:21 CEST] <atomnuker> maybe I'm misremembering, I do remember something about them nih-ing an opus-like codec [17:22:50 CEST] <durandal11707> anybody have ac-4 decoder? [17:31:21 CEST] <nevcairiel> ac4 is their object based codec isn't it [17:31:48 CEST] <kierank> Yes [17:32:01 CEST] <kierank> FFmpeg isn't going to understand objects [17:48:22 CEST] <atomnuker> all it would have to do is provide side data about the objects, decoders can output a different amount of channels per-frame [17:49:17 CEST] <atomnuker> though if each object is its own stream and isn't synced with the rest, welp, not much that can be done [18:53:52 CEST] <durandal11707> need to make FFmpeg brand [19:00:05 CEST] <thardin> ffmpeg.org doesn't have nearly enough js or background videos [19:01:04 CEST] <j-b> background video of 250MB! [19:02:03 CEST] <gnafu> Encoded using Bink! [19:03:12 CEST] <TD-Linux> atomnuker, ac4 is a codec, besides object-based I think they much improved the quality over ac3 [19:03:33 CEST] <atomnuker> at least you can download it quickly, what if you have, say, 33 megabyte webpage, with 8mb of css, ~16 mb of js, which take 30 seconds (!) to load fully? [19:03:50 CEST] <atomnuker> now you can experience this hell by upgrading gmail! [19:04:26 CEST] <atomnuker> I'm serious, its 33 megabytes, and that's with a blank background, and it does take 30 seconds to fully initialize [19:15:14 CEST] <durandal11707> why you think FFmpeg brand immediately means js and videos? [19:18:32 CEST] <gnafu> durandal11707: 'Cause that's what "2!.$).' is all about. [19:25:47 CEST] <durandal11707> nope [19:34:47 CEST] <gnafu> durandal11707: I know, I'm just making light (as I'm sure others are). I agree a good brand language can be beneficial. [19:36:45 CEST] <gnafu> But given ffmpeg's age and ubiquity, does it need an updated brand to achieve anything useful? [19:45:59 CEST] <gnafu> If someone wanted to work on that, though, why not? If I was talented in that area, I could see wanting to contribute my talents to a project I love. [19:47:11 CEST] <gnafu> durandal11707: Do you have ideas, or know someone with that kind of interest? I'm no designer, but I'd be happy to provide feedback :-). [19:51:46 CEST] <durandal11707> gnafu: congratulations, i'm your manager, get to work! [19:53:19 CEST] <gnafu> durandal11707: :-D [20:58:29 CEST] <atomnuker> freenode finally did something [21:08:55 CEST] <cone-881> ffmpeg 03Baptiste Coudurier 07master:b8351ea0c335: avformat/audiointerleave: pad last audio frame [21:14:59 CEST] <durandal11707> atomnuker: what? [21:15:39 CEST] <cone-881> ffmpeg 03Baptiste Coudurier 07master:955a989341a5: avformat/mxfenc: fix muxing when audio tracks are longer than video track [21:17:45 CEST] <durandal11707> ubitux: should 1d cube lut format be supported by lut3d filter? or i should do lut1d filter? [21:20:59 CEST] <durandal11707> Compn: please add ffmpeg imm4 codec to mplayer [21:26:17 CEST] <ubitux> durandal11707: it doesn't make much sense in lut3d i think [21:26:46 CEST] <ubitux> the logic is going to be completely different [21:27:08 CEST] <ubitux> and typically the options of the filter such as interpolation won't apply [21:27:29 CEST] <ubitux> now maybe in the source file it could make sense, if you want to share the option parsing [21:27:44 CEST] <ubitux> but up to you, i don't have a strong opinion on that [21:28:04 CEST] <ubitux> (option parsing -> lut file parsing) [21:28:48 CEST] <ubitux> or we could move the lut3d file parsing into a decoder or something, to access the lut themselves as image buffer [21:29:03 CEST] <ubitux> and use video stream as input for lut3d lut1d .. [21:29:06 CEST] <ubitux> gtg [21:29:08 CEST] Action: ubitux & [21:43:37 CEST] <kierank> TD-Linux: well they had 25 years to do it [21:46:40 CEST] <TD-Linux> kierank, sadly there aren't any useful samples or comparisons to see how much better it is. I only have rumors [21:57:12 CEST] <kierank> TD-Linux: it's not a codec there to improve compression imo [21:57:19 CEST] <kierank> it's their to add as much ipr as possible [21:57:22 CEST] <kierank> into tvs [21:57:30 CEST] <JEEB> yup [21:57:54 CEST] <JEEB> if it is better at something that is just the R&D people actually caring about what they're doing, I guess? [21:58:21 CEST] <TD-Linux> kierank, right, it's regulatory-capture-the-codec [21:58:24 CEST] <kierank> probably comparable with opus [21:59:40 CEST] <TD-Linux> they claim transparency at 96kbps with stereo which would put it in line with opus [22:27:05 CEST] <j-b> 'morning [22:37:25 CEST] <atomnuker> j-b: its 21:37, or do you have an even more messed up sleep cycle than me? [22:37:34 CEST] <j-b> it's always morning on IRC [22:37:43 CEST] <j-b> and I have a messed up sleep cycle, those days [23:17:09 CEST] <JEEB> &32 [00:00:00 CEST] --- Wed Aug 22 2018

1 0

ffmpeg.log.20180821
by burek 22 Aug '18

22 Aug '18

[00:13:18 CEST] <hackpoetic> I am messing around with the chromakey filter and I have my settings working in ffplay, but when I write to a video with settings I read preserve transparency ("-c:v png out.mov") it's back to being blue! [00:13:50 CEST] <hackpoetic> ffmpeg -i ~/Downloads/Black\ Cat\ isolated\ on\ blue\ screen-AeYp3S0v0N8.mp4 -vf "chromakey=0x0000ff:0.4:0.1" -c:v png out.mov [00:14:11 CEST] <hackpoetic> ffplay ~/Downloads/Black\ Cat\ isolated\ on\ blue\ screen-AeYp3S0v0N8.mp4 -vf "chromakey=0x0000ff:0.4:0.1" [00:15:01 CEST] <BtbN> Can you even put png into mov? [00:15:13 CEST] <BtbN> You will need to overlay the now transparent image on top of something. [00:16:18 CEST] <hackpoetic> oh, figured mplayer would show it as black and not the original color. [00:16:23 CEST] <hackpoetic> I'll try overlaying [00:16:45 CEST] <hackpoetic> Ha, I should have try with ffplay [00:22:14 CEST] <hackpoetic> hmm... overlaying doesn't seem to work. The blue is right back [00:22:23 CEST] <hackpoetic> Do you have suggested output encoding options? [00:23:10 CEST] <BtbN> The encoding options don't really matter if you are overlaying it on top of a black or whatever kind of background [00:24:16 CEST] <hackpoetic> I'm not. I'm doing the overlraying live in other software [00:24:22 CEST] <hackpoetic> so I need to retain the alpha channel [00:25:35 CEST] <BtbN> Video doesn't really support alpha [00:25:52 CEST] <BtbN> VP9 has some hack to support it, and one of the various prores encoders in ffmpeg supports it as well [00:43:50 CEST] <Cracki> qtrle does alpha. it's a lossless codec, of course. [00:49:24 CEST] <hackpoetic> I keep typing aplay instead of ffplay and breaking my ears [00:51:22 CEST] <hackpoetic> I'm having so many problems with this I'm wondering if I should just build chroma keying into my app and not have that a pre-processing step [00:53:21 CEST] <hackpoetic> Now I just need to lookup how to implement chroma keying. More reason for me to rewrite my app to use libffmpeg [00:53:51 CEST] <BtbN> There's no libffmpeg though [00:54:11 CEST] <hackpoetic> What the heck am I thinking of [00:54:24 CEST] <BtbN> libavfilter probably, for chromakey [00:55:38 CEST] <hackpoetic> I see mention of a libffmpeg online that's for handling AV stuff... What are they referring to? [00:56:35 CEST] <hackpoetic> http://ffmpeg.org/doxygen/trunk/ [00:56:47 CEST] <hackpoetic> Oh I see, I just called it the wrong thing [00:56:51 CEST] <rjeli> >i keep typing aplay instead of ffplay [00:56:53 CEST] <rjeli> l m a o [00:57:27 CEST] <hackpoetic> ;-) [00:57:38 CEST] <hackpoetic> It's the worst [00:58:48 CEST] <hackpoetic> How would I find out finding where the chromakey source lives for libavfilter? [00:59:01 CEST] <hackpoetic> Found it [00:59:01 CEST] <hackpoetic> https://www.ffmpeg.org/doxygen/3.0/vf__chromakey_8c_source.html [00:59:10 CEST] <BtbN> you're looking at ancient docs [00:59:16 CEST] <mixfix41> hmm firefox youtube video runs better than ffplay for me now with some additional libraries, libEGL libgles libdrm exynos libmali, going to need to optimize this to get full screen o nthis laptop [00:59:38 CEST] <hackpoetic> Damn google [01:00:25 CEST] <hackpoetic> Okay, I'll poke at this later [01:00:29 CEST] <hackpoetic> Thank you all for the help! [02:17:24 CEST] <ahoo> good day fine sirs! [02:17:33 CEST] <ahoo> what is your preferred nopaste thing? [02:25:38 CEST] <DHE> one that works without javascript and preferably no ads [02:26:00 CEST] <DHE> often your distro's support site may have one and you can use that [02:28:27 CEST] <Cracki> github gists are an option [02:42:51 CEST] <DHE> a bit overkill, and require a github account, but quite viable [02:56:40 CEST] <ahoo> https://www.irccloud.com/pastebin/nznU3jDP/ [02:56:52 CEST] <mijofa_> ix.io is good [02:57:19 CEST] <ahoo> recording works fine but there are errors all the time [02:57:24 CEST] <ahoo> see snippet [02:58:31 CEST] <DHE> https://www.irccloud.com/pastebin/raw/nznU3jDP because I said no javascript. :) [02:59:02 CEST] <ahoo> oh, sorry. i confused that. [02:59:36 CEST] <ahoo> my camera can only supply 33FPS - is that something i have to tell ffmpeg? [03:00:26 CEST] <ahoo> never mind, just saw that i do. [03:03:51 CEST] <ahoo> any idea what could be wrong? [03:04:30 CEST] <DHE> if the output video is fine, I wouldn't worry about it... [03:09:04 CEST] <ahoo> alright [03:09:05 CEST] <ahoo> thanks [03:09:28 CEST] <DHE> sounds like some kind of format error on the input, but a known error easily dealt with... [03:28:23 CEST] <Hello71> why is it 33 anyways [03:31:36 CEST] <ahoo> idk [03:52:12 CEST] <opticron> hi, I've been provided a file as a sample for how one I create should be produced and I want the A/V codec setup to match exactly. is there an easy way to do that without spending a few days trying to get options right? I've already tried a concat filter with a sample of the original, but the wrong codecs are chosen regardless of the order specified [03:59:56 CEST] <Cracki> a file is not a proper specification of codec parameters [04:00:00 CEST] <Cracki> ask what they want [04:22:47 CEST] <Hello71> that's not even specific to media [04:32:12 CEST] <opticron> yeah, the video file wasn't encoded by the person that handed it to me, they don't have that information :/ [04:32:28 CEST] <opticron> I guess I'll just have to get it close [04:32:37 CEST] <Hello71> here's this csv, please export in this format [05:40:42 CEST] <teganburns> Building ffmpeg for Android with libopenh264 has proven to be quite a challenge. Does anyone here have and recommended resources? The ones listed on the site seem pretty dated. Thanks [06:04:03 CEST] <leif> What is the best way to display an image for, say, 5 seconds, with the filter_complex flag? [06:04:08 CEST] <leif> (If that's possible) [06:04:34 CEST] <leif> Right now about all I've got is to generate 5 seconds of black with the `color` filter, and overlay the image on top of it. But that seems silly to me. [06:07:03 CEST] <leif> (Also using the trim filter understandably has no effect.) [06:25:30 CEST] <teganburns> leif: https://video.stackexchange.com/questions/12105/add-an-image-overlay-in-fro… [06:31:33 CEST] <leif> teganburns Interesting. I guess overlay really is the way to do it, thanks. [06:49:21 CEST] <furq> leif: is this a transparent image [06:50:03 CEST] <furq> if you just want to use an image as a bumper then use the loop filter and concat [10:28:40 CEST] <ahoo> how to make ffmpeg creating more keyframes when recording? [10:28:57 CEST] <ahoo> per default it's like every 1 minute or so [10:29:10 CEST] <ahoo> i'd like to have it every 1 or 2 seconds [10:29:23 CEST] <ahoo> oh, and aac or mp3? [10:29:36 CEST] <Mavrik> -g sets GOP size [10:29:46 CEST] <Mavrik> and aac or mp3 depends on your target format and target players. [10:31:48 CEST] <furq> i don't know of any codec that defaults to a gop size of one minute [10:31:53 CEST] <furq> unless you're capturing at 4 fps [10:32:33 CEST] <Nacht> Yeah that's a GOP of 1500 ~ 1800 [10:34:28 CEST] <ahoo> Mavrik: yeah but which of the two is the better choice? in terms of modernity, effectiveness, maintainedness [10:34:39 CEST] <furq> aac [10:35:42 CEST] <ahoo> thx [11:16:50 CEST] <Nacht> Anyone know any formats/codecs who support alpha ? I got a MOV with QTRLE but it's a tad big [11:19:33 CEST] <X-Kent> Hello, I have an HLS stream that has some misconfiguration that I cannot figure out. It seems that video is somehow getting it frames dropped while audio is OK. Is there any tool I can use to check what is it ? [11:23:48 CEST] <Nacht> Apple themselves have a HLS validator. But it only works on Macs [11:36:20 CEST] <durandal_1707> Nacht: utvideo? magicyuv? [11:36:47 CEST] <Nacht> durandal_1707: Cheers, I' [11:36:49 CEST] <Nacht> ve [11:37:03 CEST] <Nacht> I've tried with VP9 but I dont seem to keep the alpha [11:37:45 CEST] <furq> Nacht: the ffmpeg vp9 decoder doesn't support alpha [11:37:56 CEST] <furq> you'd have to force using libvpx to decode [11:38:58 CEST] <furq> if you want it to be lossless then i guess ffv1 is your best option [11:39:42 CEST] <Nacht> furq: It doesn't have to be lossless. I just need it to not be 800mb at the moment. [11:40:19 CEST] <Nacht> What I had was "-c:v libvpx -pix_fmt yuva420p -auto-alt-ref 0" [11:40:40 CEST] <furq> that should work iirc [11:41:08 CEST] <furq> but if you want to process it again with ffmpeg then you need -c:v libvpx -i ... [11:41:11 CEST] <Nacht> Yeah that's the weird thing. But once I use that video and overlay it on top of another, i dont get the alpha [11:41:13 CEST] <furq> or libvpx-vp9 [11:41:22 CEST] <Nacht> Ah [11:41:29 CEST] <Nacht> That might be it then [11:41:41 CEST] <furq> transparency in webm is a weird hack, it stores a separate alpha plane [11:42:48 CEST] <furq> or a separate alpha stream, rather [11:43:27 CEST] <ritsuka> prores 4444 supports alpha, but it still takes a lot of space, and I don't know if ffmpeg supports it [11:45:03 CEST] <Nacht> The decoder trick worked, thanks furq [11:45:04 CEST] <furq> you'd be better off just using ffv1 at that point [11:45:17 CEST] <furq> it'll be better than qtrle but probably still pretty big [14:06:28 CEST] <X-Kent> Nacht, it may be that the problem is not in the HLS itself but in the segments. Some players handle the stream well, others lose some frames, some just get stuck completely. HLS playlist itself looks legit in it's structure. [14:07:29 CEST] <X-Kent> tried ffplay with debug options, don't see anything other than that it complains about CRLF at the end of headers. [14:20:07 CEST] <Nacht> X-Kent: You would need to inspect the TS files then. [14:24:49 CEST] <Nacht> X-Kent: I'm quite fond of this tool to check the TS files: http://www.pjdaniel.org.uk/mpeg/ [14:25:05 CEST] <Nacht> But it requires some knowledge regarding TS to know when something isn't valid [14:25:12 CEST] <X-Kent> Nacht, ow, will check it out [14:27:34 CEST] <X-Kent> crashes on linux under wine, will try it on my windows box [14:28:44 CEST] <JEEB> for MPEG-TS I generally recommend DVBInspector [14:28:53 CEST] <JEEB> it's java but seems pretty gut for stuff like checking PTS/DTS/PCR etc [14:29:44 CEST] <JEEB> for examle it let me see how nicely Apple was muxing MPEG-TS https://kuroko.fushizen.eu/screenshots/apple_mpegts/nice_timestamps_there.p… [14:34:00 CEST] <Nacht> True, DVBinspector is quite nice as well. Nice visual representation of the PTS/DTS as well [14:42:34 CEST] <JEEB> also generally if you're generating the HLS MPEG-TS yourself I recommend sticking at least two segments together and checking them like that [14:42:48 CEST] <JEEB> that should also show if anything doesn't nicely flow from one segment to another [15:17:11 CEST] <termos> av_opt_set(format->priv_data, "hls_flags", "program_date_time", 0); is it incorrect for me to set it like this? It does not work at least, wonder what the proper way to set it is [18:43:56 CEST] <Mista_D> Why not extracting thumbnail at 0 seconds? ./ffmpeg -i file.ts -vf fps=0.1:near=0 images/%04d.jpg [18:44:44 CEST] <Mista_D> Why not extracting thumbnail at 0 seconds? ./ffmpeg -i file.ts -vf fps=0.1:round=0 images/%04d.jpg [18:44:59 CEST] <Mista_D> fixed the fps round... [19:09:49 CEST] <kepstin> Mista_D: I believe you want to use round=inf to achieve that. [19:56:24 CEST] Action: CoreX slaps tomaw around a bit with a large trout [19:56:56 CEST] <tomaw> CoreX: hey, you got some warning :p [19:57:57 CEST] <CoreX> surely you would rather give the advice via a global announce [20:01:07 CEST] <tomaw> I might, when I've decided how many things I'm restarting :) [22:12:26 CEST] <leif> Is there any way to set the time base with the ffmpeg filter graph? [22:13:49 CEST] <ChocolateArmpits> leif, there's settb/asettb filter pair [22:14:33 CEST] <ChocolateArmpits> but there's also -enc_time_base parameter for encoder [22:15:19 CEST] <leif> ChocolateArmpits: Ah cool, thanks. [22:15:41 CEST] <leif> (Also its for a programatic use, so using the filtergraph is much easier for this use case.) [22:15:43 CEST] <leif> Anyway, thanks. [22:16:16 CEST] <ChocolateArmpits> np [22:16:17 CEST] <furq> dedicated muxers can do it without reencoding, if you happen to need that [22:42:46 CEST] <dlb76> dlb76 #ffmpeg Cannot change nickname while banned on channel [22:42:46 CEST] <dlb76> why you do this [22:42:51 CEST] <dlb76> very uncomfortable [22:51:40 CEST] <BtbN> Just register. [22:52:15 CEST] <BtbN> The alternative is a bunch of spambots. [22:55:53 CEST] <dlb76> i always identify [22:56:19 CEST] <dlb76> https://pastebin.com/38mr3Uxq [22:59:53 CEST] <furq> dlb76: auth with sasl instead [23:00:08 CEST] <furq> i was going to say "it's less hassle" but i didn't want it to rhyme [23:01:32 CEST] <dlb76> will see about it [00:00:00 CEST] --- Wed Aug 22 2018

1 0