Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

May 2018

1 participants
62 discussions

ffmpeg-devel.log.20180505
by burek 06 May '18

06 May '18

[00:02:09 CEST] <BtbN> also, are there no a53 cc samples on samples.ffmpeg.org? [00:07:45 CEST] <jkqxz> BtbN: <http://ixia.jkqxz.net/~mrt/ffmpeg/sei-test.h264> [00:07:45 CEST] <jkqxz> (I just happened to be contriving a ridiculous SEI test to add to FATE. The captions should name the numbers in the video.) [00:09:04 CEST] <BtbN> ok, so it seems like a53 in nvenc works [00:09:13 CEST] <BtbN> at least transcoding this gives me a file with a subtitle track in vlc [00:10:06 CEST] <jkqxz> Is it right? [00:10:15 CEST] <BtbN> In what sense right? [00:10:32 CEST] <nevcairiel> CCs often arent a "track" as such, but i have no clue how vlc works [00:10:43 CEST] <jkqxz> Well, are the captions in the right order. [00:11:45 CEST] <BtbN> I can't see them for that sample at all, probably because VLC is bad and renders them black on black? [00:12:06 CEST] <BtbN> They are there, according to ffprobe though [00:13:43 CEST] <BtbN> found some other sample on track, and it's just fine there [00:16:10 CEST] <cone-914> ffmpeg 03Timo Rothenpieler 07master:7d4e1f7cfb66: avcodec/nvenc: make hw_frames_ctx fully optional [00:16:11 CEST] <cone-914> ffmpeg 03Miroslav SlugeH 07master:952421cd20ac: avcodec/nvenc: support dynamic aspect ratio change [00:16:12 CEST] <cone-914> ffmpeg 03pkviet 07master:155375123c1f: avcodec/nvenc: support dynamic bitrate changes [00:16:13 CEST] <cone-914> ffmpeg 03Roman Arzumanyan 07master:5a88e8c36581: avcodec/nvenc: add A53CC support [00:16:14 CEST] <cone-914> ffmpeg 03Timo Rothenpieler 07master:fdbb4b9a7866: avcodec/nvenc: move reconfig_encoder call inside of push/pop ctx [00:18:58 CEST] <jkqxz> If anyone would like to suggest any other SEI things (or other metadata) to add to that file I would add them. [00:28:39 CEST] <jamrial> jkqxz: that files gives an "Assertion n == subs" error with trace_headers [00:29:14 CEST] <jkqxz> Yes, I'm fixing that. [00:29:33 CEST] <jamrial> ok [00:29:35 CEST] <jkqxz> The "other" SEI support doesn't really work properly. [00:30:18 CEST] <jkqxz> (It doesn't write the correct size either.) [00:38:04 CEST] <cone-914> ffmpeg 03Paul B Mahol 07master:c2fd69ba6239: avfilter/vf_colorbalance: add 16bit depth support [00:54:02 CEST] <tmm1> rcombs: this is super hacky but fixes decoding https://github.com/tmm1/FFmpeg/commit/44b1612000 [00:54:17 CEST] <tmm1> i can't figure out why some frames are missing hw_frames_ctx.. its not getting copied somewhere [00:54:23 CEST] <tmm1> maybe wm4 has some idea [01:43:33 CEST] <rcombs> tmm1: well what code path would call alloc_frame but not end_frame? [01:47:28 CEST] <rcombs> maybe the `!avpkt->size` case in hevc_decode_frame()? [02:18:25 CEST] <tmm1> nope that would only be on EOF [02:18:49 CEST] <tmm1> its something weird inside the hevc dec, maybe this HEVC_FRAME_FLAG_BUMPING business [02:18:54 CEST] <tmm1> causing frames to be reused [03:03:40 CEST] <tmm1> the decoder copies and moves frames all over the place, so i can't make any sense of what's going on [03:25:27 CEST] <cone-914> ffmpeg 03Aman Gupta 07master:84e03db9a334: avcodec/videotoolbox: improve logging of decoder errors [03:25:28 CEST] <cone-914> ffmpeg 03Aman Gupta 07master:bcff983dc340: avcodec/videotoolbox: fix kVTCouldNotFindVideoDecoderErr trying to decode HEVC on iOS [03:38:03 CEST] <Compn> hanna : i didnt see any good mails in queue , only spam [03:38:16 CEST] <Compn> so either lou or someone else approved them, or they didnt come [04:51:32 CEST] <hanna> maybe my registering to the ML automatically approved it [04:51:38 CEST] <hanna> (retroactively) [05:45:22 CEST] <philipl> BtbN: Not a real problem but the define you're using in nv-codec-headers to detect 64bit windows is ffmpeg specific. [05:45:25 CEST] <philipl> https://github.com/jb-alvarado/media-autobuild_suite/pull/832 [05:45:34 CEST] <philipl> Presumably there's a windows define you can check instead. [05:45:53 CEST] <philipl> In practice mpv doesn't care as it doesn't try to load any nvenc symbols. [12:27:11 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:4cd4aa08a689: avfilter/vf_convolution: use already available dstride [12:27:12 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:db8777cef092: avfilter/vf_colorbalance: add planar rgb support [12:52:31 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:0ef7a4519745: avfilter/vf_colorbalance: add slice threading [15:49:06 CEST] <BtbN> philipl, fixed, just missed that one [16:08:58 CEST] <ubitux> i'm going to repeat myself but the aarch64 simd asm is really damn nice [16:09:20 CEST] <ubitux> almost done with the nlmeans simd [16:09:45 CEST] <ubitux> not sure it will make much of a difference, but it will at least act as a reference for x86 [16:09:54 CEST] <JEEB> nice [16:10:21 CEST] <JEEB> I've got rpi3 running in aarch64 mode but I seem to have one of those that dies after ~3 days of running [16:11:25 CEST] <durandal_1707> ubitux: i looked at that already, and it doesnt help much for cif resolutions [16:30:41 CEST] <ubitux> durandal_1707: yeah but you don't need nlmeans for cif resolutions [16:30:57 CEST] <ubitux> and even if you do, you don't need simd since it's already small & fast :p [16:40:45 CEST] <durandal_1707> ubitux: it is not realtime even for cif [16:45:10 CEST] <atomnuker> JEEB: I put archlinux aarch64 on mine, 100 days of uptime [16:45:31 CEST] <atomnuker> and it did reset and had compiler errors and ram errors all the time with raspbian [16:46:09 CEST] <atomnuker> ubitux: yeah but no x86 addressing [16:46:56 CEST] <BtbN> interesting. Twitch plays their HLS stuff with sub 1 second delay now [16:47:09 CEST] <BtbN> Their playlists have the next two segments in a #EXT-X-TWITCH-PREFETCH: thing [16:47:27 CEST] <BtbN> as in, the next two that don't even exist yet [16:49:41 CEST] <wm4> can libavformat play this [16:51:28 CEST] <BtbN> it will just ignore the EXT- elements and play it like normal HLS with more delay [16:52:07 CEST] <BtbN> But a live stream with less than a second delay, over a CDN and Server-Side remuxing and even transcoding if enabled... [16:52:13 CEST] <BtbN> That's pretty impressive, even without HLS. [16:53:14 CEST] <BtbN> It's Chrome-Only for some reason [16:53:38 CEST] <wm4> yeah sometimes stupid things are impressive [16:53:57 CEST] <atomnuker> is that what peloverde is up to nowadays [16:54:08 CEST] <cone-295> ffmpeg 03Michael Niedermayer 07master:15a2e35e9e74: avcodec/flac_parser: Fix infinite loop [16:54:16 CEST] <JEEB> BtbN: I think they just generate the initial PMT/PAT first, then keep the chunked thing waiting [16:54:21 CEST] <JEEB> something like that [16:54:29 CEST] <JEEB> atomnuker: I hear this is just a hardware thing [16:54:38 CEST] <JEEB> some rpi3s seemingly die after ~3 days [16:55:27 CEST] <BtbN> JEEB, can confirm. When I used an rpi3 for something semi-important, I had to cronjob-reboot it every night, otherwise it would die after random times [16:56:12 CEST] <wm4> reboot? so it's a software problem? [16:56:45 CEST] <JEEB> well reboot probably reset some hw [17:02:50 CEST] <atomnuker> JEEB: don't know, mine got fixed after I reinstalled [17:03:05 CEST] <JEEB> oh well [17:03:22 CEST] <JEEB> I wish I cared more about it; right now I am lazy enough that it's still powered on dead [17:07:24 CEST] <atomnuker> same issue and situation as one of my odroid c2s [17:08:23 CEST] <atomnuker> rock solid for months until you run something even remotely intensive like cloning the kernel git, then you need to physically unplug and plug it again [17:08:38 CEST] <BtbN> I eventuelly replaced the RPi with a NUC. No issues anymore since. [17:09:12 CEST] <hanna> ^ [17:09:49 CEST] <JEEB> yea [17:09:59 CEST] <JEEB> I would never put the rpi for anything serious [17:10:07 CEST] <JEEB> for me it was mostly about "how far do I get in aarch64 mode" [17:10:15 CEST] <JEEB> the answer to which was "surprisingly far" [17:10:18 CEST] <Compn> rpi people are fun, they come into #mplayer because there is no rpi support or forum or distro [17:10:35 CEST] <JEEB> because I got as far as opengl with the open source driver [17:10:41 CEST] <JEEB> with the 4.16.x kernel [17:10:44 CEST] <JEEB> and mesa, I guess? [17:39:32 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:d1e18724187d: avfilter/vf_colorchannelmixer: add slice threading [17:39:33 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:2017b4b1c25b: avfilter/vf_colorbalance: fix off by one overflow [17:39:34 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:931e2c4541e0: avfilter/vf_colorchannelmixer: refactor code [17:39:35 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:0f4ca420bca4: avfilter/vf_colorchannelmixer: add planar rgb support [18:04:15 CEST] <BtbN> https://cgit.freedesktop.org/gstreamer/gst-libav/commit/?id=15a17f3f8d22820… interesting. It really should just work? [18:06:57 CEST] <wm4> yes [18:07:25 CEST] <wm4> maybe they're using the API incorrectly, like always expecting yuv420p or so? [18:07:27 CEST] <wm4> who knows [18:07:38 CEST] <philipl> Maybe because it wasn't written by a libav dev... [18:08:03 CEST] <BtbN> Or they didn't even test it, and just disabled it like every hwenc [18:08:15 CEST] <JEEB> yea, that is more likely [18:08:20 CEST] <JEEB> "just disable things just in case" [18:08:22 CEST] <philipl> But the yuv420p wouldn't surprise me. When I did that firefox experiment with it, I had to mess around with a bunch of stuff to get nv12 working [18:09:21 CEST] <philipl> BtbN: there's also a native nvdec gst plugin. Bare minimum functionality though. [18:10:28 CEST] <philipl> but it has GL interop [18:10:49 CEST] <ubitux> ssd_integral_image_c: 360618.5 [18:10:51 CEST] <ubitux> ssd_integral_image_neon: 212887.2 [18:10:54 CEST] <ubitux> not crazy but still good [18:10:58 CEST] <BtbN> latest gst-plugins-libav does not build with ffmpeg-4 anyway [18:11:43 CEST] <wm4> why not [18:11:58 CEST] <BtbN> Using a bunch of deprecated defines that got removed [18:12:08 CEST] <BtbN> ones without AV_ prefix [18:12:17 CEST] <wm4> wow they only had a decade to fix this [18:12:26 CEST] <BtbN> And a lot of other stuff [18:12:38 CEST] <durandal_1707> atomnuker: see ml, there is crash in dcaenc [18:13:36 CEST] <ubitux> https://github.com/ubitux/FFmpeg/blob/nlmeans-dsp/libavfilter/aarch64/vf_nl… [18:13:45 CEST] <ubitux> suggestions for acc_sum_store welcome [18:14:01 CEST] <ubitux> i could probably make use of random other registers to help with pairing [18:14:16 CEST] <durandal_1707> i think C code is very slow, there are better implementations [18:14:49 CEST] <durandal_1707> or defaults are simply too strong... [18:15:18 CEST] <ubitux> i made a faster C version [18:15:42 CEST] <ubitux> but simd is still much faster [18:16:14 CEST] <ubitux> https://github.com/ubitux/FFmpeg/blob/nlmeans-dsp/libavfilter/aarch64/vf_nl… [18:16:23 CEST] <ubitux> this one is relatively faster than current naive C [18:16:43 CEST] <ubitux> (unrolled but mainly a different algorithm, typically what i do in simd) [18:16:54 CEST] <ubitux> (except 16 instead of 8) [18:17:24 CEST] <durandal_1707> how much faster? [18:20:18 CEST] <ubitux> 49317.0 old c, 46343.0 new c, 28219.5 neon [18:20:38 CEST] <ubitux> (sorry not the same magnitude as previously, i forgot what settings i was testing) [18:22:15 CEST] <jamrial> BtbN: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/gst… Arch gst-libav maintainer just said "fuck it, no system libraries" [18:22:31 CEST] <jamrial> probably because it wasn't fixed by gst-libav itself [18:23:40 CEST] <ubitux> durandal_1707: found back previous settings: 360552.5 old c, 340711.0 new c, 213613.2 neon [18:26:04 CEST] <durandal_1707> ubitux: well, i got several milliions cycles in antother part of code [18:26:34 CEST] <ubitux> yeah that's not surprising [18:26:55 CEST] <ubitux> it's not meant for real time [18:42:43 CEST] <durandal_1707> ubitux: others nlmeans filters are realtime, even purce C versions [18:53:52 CEST] <durandal_1707> what about colorize filter, this one would colorize gray images, with set hue, saturation, lightness? [19:27:55 CEST] <ubitux> durandal_1707: are you saying the ffmpeg nlmeans is much slower than other implementations? [19:28:16 CEST] <ubitux> (can you provide numbers?) [19:28:47 CEST] <atomnuker> durandal_1707: -devel? I don't see it [19:29:27 CEST] <durandal_1707> atomnuker: -user [19:29:41 CEST] <durandal_1707> ubitux: the old handbrake filter [19:32:42 CEST] <ubitux> with+without its asm disabled and comparable settings? [19:34:33 CEST] <durandal_1707> i tried it long ago, and was pretty fast [19:35:36 CEST] <ubitux> the settings have a large influence on the speed [19:36:08 CEST] <ubitux> changing the research window and patch size can be night & day [19:36:46 CEST] <ubitux> i've followed the ipol suggestions, they may not be the most appropriate settings [20:13:34 CEST] <durandal_1707> ubitux: https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=4883 it is 5x times slower [20:14:03 CEST] <ubitux> interesting [20:14:18 CEST] <ubitux> any idea how i can test handbrake? [20:14:30 CEST] <ubitux> i mean, bench [20:17:15 CEST] <durandal_1707> you could build ffmpeg with this one: https://github.com/farindk/ffmpeg/blob/master/libavfilter/vf_nlmeans.c [20:20:10 CEST] <ubitux> ffmpeg from 2014? yeah nah, i'll pass [20:20:26 CEST] <ubitux> anyway, i'll just work on making it faster [20:21:14 CEST] <ubitux> maybe i'm doing something stupid but i can't see how it could be significantly slower with comparable settings [20:21:25 CEST] <ubitux> maybe the threading i did wasn't smart, dunno [20:23:14 CEST] <ubitux> i'll make the unsafe version faster [20:23:27 CEST] <ubitux> the integral in simd will help also [20:24:00 CEST] <ubitux> then 65% of the time seems spent in nlmeans_slice [20:26:43 CEST] <durandal_1707> ubitux: also the noise is not removed as good as other filter [20:27:28 CEST] <durandal_1707> with same settings, range, and patch size, and different strength [20:33:03 CEST] <ubitux> ah? maybe there is a bug? [20:35:43 CEST] <durandal_1707> ubitux: i have downloaded orig pngs [20:37:49 CEST] <jamrial> jkqxz: ping [20:43:02 CEST] <cone-295> ffmpeg 03Rostislav Pehlivanov 07master:a1c6fc773f94: mpegvideo: remove support for libxvid's RC system [20:43:03 CEST] <cone-295> ffmpeg 03Rostislav Pehlivanov 07master:c1b282dc74d8: dcaenc: fix segfault when attempting to encode with invalid samplerate [20:48:45 CEST] <JEEB> what's the way to add pkg-config checks for check_lib things? [20:48:56 CEST] <JEEB> because it seems like require_pkg_config does die? [20:49:35 CEST] <JEEB> because I'm getting kind of tired of having to add extra-cflags/ldflags for my (say) mingw-w64 prefix just because the zlib pc file isn't being utilized [20:49:55 CEST] <JEEB> (yes, zlib comes with a seemingly working pc file, for the horror) [20:52:00 CEST] <JEEB> I guess I'll just try and see how it goes [20:52:58 CEST] <jamrial> JEEB: check_pkg_config [20:53:44 CEST] <JEEB> wonder how I missed that [20:53:52 CEST] <ubitux> durandal_1707: https://paste.ee/p/f4oaU [20:53:57 CEST] <JEEB> oh, and I had just copy-pasted it from the fdk-aac check [20:53:58 CEST] <JEEB> lal [20:53:59 CEST] <ubitux> stupid shit like this seems to improve performance for me [20:54:53 CEST] <ubitux> i'll make a few other speedups and send a patchset maybe tomorrow [20:55:00 CEST] <durandal_1707> ubitux: yes, but by how much? compilers are dumb [20:55:36 CEST] <durandal_1707> actually i can not reproduce quality stuff, because he uploaded jpgs [20:55:44 CEST] <ubitux> it went from about 62% to 59.9% time spent in that function [21:00:56 CEST] <ubitux> i' [21:01:05 CEST] <ubitux> i'm curious how x86 simd will help here [21:01:23 CEST] <ubitux> pretty sure it will be more efficient than on these shitty board [21:01:41 CEST] <ubitux> where it's probable the memory bus is saturated [21:04:02 CEST] <jamrial> atomnuker: you forgot to add the deprecated avoption flag as i told you [21:04:58 CEST] <durandal_1707> ubitux: the other nlmeans filter is about 30% faster than yours, with just C, looks like slice threading doesnt help much [21:06:13 CEST] <ubitux> with same settings? [21:06:20 CEST] <durandal_1707> yes [21:06:27 CEST] <ubitux> is it processing the same pixel format as input? [21:06:32 CEST] <durandal_1707> yes [21:06:48 CEST] <ubitux> well, if you can figure out why& [21:07:02 CEST] <durandal_1707> try nlmeans=threads=X and you will see no big gain [21:07:14 CEST] <ubitux> ok [21:09:01 CEST] <ubitux> speed=0.612x vs speed=0.451x here with threads=1 vs threads=8 [21:09:14 CEST] <ubitux> (./ffmpeg -lavfi testsrc2=d=5,nlmeans=threads=X -f null -) [21:09:19 CEST] <ubitux> not the best comparison [21:09:26 CEST] <ubitux> but it seems to help a little [21:09:53 CEST] <ubitux> (i inverted the results, threads=8 is the fastest ofc) [21:10:32 CEST] <JEEB> yayifications, got my mingw-w64 build to work without manual cflags/ldflags [21:10:43 CEST] <JEEB> first of course forgot the ; [21:10:49 CEST] <JEEB> and got my shell derping at myself [21:12:54 CEST] <JEEB> aand sent [21:13:36 CEST] <nevcairiel> why did you need special cflags before [21:14:12 CEST] <JEEB> if your cross-prefix is not your sysroot [21:14:27 CEST] <JEEB> if you f.ex. use the distro toolchain [21:14:49 CEST] <JEEB> so I have the toolchain and CRT etc under /usr/something_or_another [21:14:54 CEST] <nevcairiel> oh stupid cross-compilation [21:15:04 CEST] <JEEB> and then I have my own stuff including zlib under /home/jeeb/blah [21:15:14 CEST] <JEEB> because I don't want to mix that stuff up, of course [21:16:47 CEST] <JEEB> I hope that stupid cross-compilation didn't mean my way of keeping my own things and sysroot separate is dumb? [21:17:01 CEST] <nevcairiel> no just that i find cross-compilation dumb :p [21:17:02 CEST] <JEEB> because I just like to have those two separate [21:17:05 CEST] <cone-295> ffmpeg 03Rostislav Pehlivanov 07master:d05c3b9ceeb9: mpegvideo: add deprecated flags to the rc_strategy option [21:17:08 CEST] <JEEB> heh [21:17:10 CEST] <atomnuker> jamrial: sorry, I forgot [21:21:47 CEST] <JEEB> nevcairiel: let's just say I disliked the waiting times before, and I dislike them even more now [21:22:10 CEST] <wm4> does mingw use dash? [21:22:16 CEST] <JEEB> you can use it [21:22:19 CEST] <JEEB> msys comes with it [21:22:23 CEST] <JEEB> or mingw, whichever it was [21:22:35 CEST] <nevcairiel> it helps the time, but doesnt eliminate the huge waits from the mess that is configure [21:22:37 CEST] <JEEB> msys is the environment, mingw has native tools [21:23:02 CEST] <wm4> lately someone mentioned that dash helps a lot even on linux [21:23:05 CEST] <JEEB> yea, that's why I just do cross from my fedora VM these days [21:23:07 CEST] <wm4> (over bash) [21:23:24 CEST] <JEEB> leads to "oh, my configure is done already? yay" [21:23:30 CEST] <JEEB> instead of "let me go grab my coffee mug" [21:24:57 CEST] <jamrial> i have been manually adding shit to config.h/mak lately to avoid having to run configure for 15 min just to add one define for a new filter [21:25:42 CEST] <jamrial> wish windows 10 would get its shit together and go back to pre CU build process spawn performance [21:26:09 CEST] <JEEB> I think at that point you might have luck just using WSL and a zipballed MSVC in wine if you were using MSVC [21:26:10 CEST] <jamrial> maybe this April release that came out last tuesday is the one... [21:26:16 CEST] <JEEB> I haven't tried yet [21:26:22 CEST] Action: JEEB did install it on Monday [21:27:39 CEST] <jamrial> i'm waiting for a stable/whql driver from amd before i install it (they had a beta ready the same day this win10 update came out, but i always skip those) [21:27:51 CEST] <JEEB> ah [21:34:29 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:ac86011b1fa7: avfilter/af_amerge: port to activate API [21:34:30 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:20a3c4f606e7: avfilter: forward status back in some filters that missed it [21:53:42 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:aef93c6aa572: avutil: add gray14 pixel format [21:53:43 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:b9dd058f7a9d: swscale: add gray14 support [21:53:44 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:41ebbae9dd65: avfilter/vf_extractplanes: add support for extracting planes with 14 depth [21:53:45 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:72b29c02f4ba: avfilter/drawutils: support gray14 [22:04:06 CEST] <durandal_1707> shit, all code convoluted, managed to break fate again [22:06:02 CEST] <JEEB> congratulations. sounds like we need something like oracle if you don't have space/cpu time to run FATE yourself [22:06:13 CEST] <JEEB> so you can push your WIP branch there [22:07:12 CEST] <atomnuker> fate runs as quick as configure here [22:07:42 CEST] <atomnuker> well, maybe 3x slowr, still not much, just a few minutes [22:07:45 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:a26367493c13: fate: update pad pixfmt test [22:28:25 CEST] <jamrial> nevcairiel: do you know if access() is available in msvc? [22:31:42 CEST] <jamrial> mmh, we seem to check for access() in configure [23:25:16 CEST] <JEEB> michaelni: for you the numbers you add up for those checks might be obvious, but I'd recommend adding the actual ideas behind them as a comment or so [23:40:36 CEST] <michaelni> JEEB, ok, will fix that [23:40:51 CEST] <JEEB> cheers [23:45:53 CEST] <wm4> in general it seems better to put a comment instead of a log message [00:00:00 CEST] --- Sun May 6 2018

1 0

ffmpeg.log.20180505
by burek 06 May '18

06 May '18

[01:06:32 CEST] <amaurea> Let's say I have a large set of [from,to] frame ranges I want to remove from a video. Is ffmpeg the right tool for doing this? I think I could construct somethign convoluted using the select filter, but I think that would mess up the PTS, making the whole thing very complicated [01:14:31 CEST] <furq> amaurea: use trim/atrim and setpts/asetpts [01:16:48 CEST] <furq> https://video.stackexchange.com/a/10401 [01:16:51 CEST] <furq> something like that [01:17:18 CEST] <furq> you can use trim=start_frame=123:end_frame=456 although idk how well that works with atrim [01:17:41 CEST] <amaurea> furq: Can I specify the filter chain in a file? I fear that I would hit the maximum argument length limit [01:17:50 CEST] <furq> -filter_complex_script iirc [01:17:59 CEST] Action: amaurea reads about that [01:18:55 CEST] <furq> oh i guess atrim doesn't have start_frame/end_frame [01:18:57 CEST] <furq> that makes sense [01:19:18 CEST] <TheRock> I have a mp3 with an image. I wonder which decoder/demuxer/parser is required to display mp3s with an attached image (png,jpg,bmp,gif?). i used ffprobe and it shows me encoder Lavf. Is ./configure --enable-decoder=lavf enough to display images? [01:19:19 CEST] <furq> if you have an audio stream then you'll need to use the actual PTS values rather than the frame number [01:19:50 CEST] <amaurea> furq: hm... I do have an audio stream. This seems pretty daunting [01:21:18 CEST] <furq> ffprobe -show_frames will show you the pts values for every frame (and also a million other lines, so pipe it to head/less or something) [01:21:39 CEST] <furq> so if it's cfr you should be able to figure out what you need to multiply the frame number by [01:22:50 CEST] <furq> you could also just use timestamps if that's easier [01:23:35 CEST] <amaurea> Yes, I don't have to use frame numbers [01:28:28 CEST] <amaurea> furq: Is a construction like [0:v]trim=a:b,setpts...[v0];[0:v]trim=c:d,...[v1];[0:v]trim=e:f,...[v2],..., efficient for large numbers of such trims? I'll give it a try, but I fear that this will involve N passes over all the frames [01:33:26 CEST] <furq> it should only take one pass [01:33:40 CEST] <furq> using -ss and -t a million times would decode the file a million times [01:34:23 CEST] Action: amaurea writes an awk script to generate the filter chain script [01:58:53 CEST] <amaurea> I'm getting decent speeds for 10 segments each of length 100 s and 100 segments each of length 10 seconds (around 100-150 fps), but for 1000 segments each of length 1 second I get only 1.4 fps, and for 10000 segments each of length 0.1 seconds I'm still waiting for the first frame, and it's using 29 GB of virtual memory. [01:59:48 CEST] <amaurea> Looks like it might be easier to write my own ffmpeg filter for doing this [02:00:42 CEST] <furq> you could maybe do it with select and just manually generate PTS values with setpts [02:01:04 CEST] <furq> that would just be one filter invocation but with a colossal expression to evaluate [02:02:15 CEST] <amaurea> That would probably be much faster, yes. Still not as fast as a dedicated filter, though. And this is a pretty self-contained, useful operation, so I think a filter is pretty appropriate [02:02:24 CEST] <amaurea> (and I'm surprised one doesn't already exist) [02:02:54 CEST] <amaurea> I'll check how easy it is to write a filter. If it's not too hard I might go tha tway [02:03:11 CEST] <amaurea> (still waiting for the first frame, by the way :) ) [02:03:15 CEST] <furq> select=whatever,setpts=N/(FRAME_RATE/TB) [02:03:19 CEST] <furq> something like that [02:03:26 CEST] <furq> FRAME_RATE*TB rather [02:03:57 CEST] <furq> splitting the output 10,000 times is probably having some unfortunate effect [02:04:12 CEST] <furq> or 1,000 rather [02:04:21 CEST] <furq> oh no wait it was 10,000 [02:04:23 CEST] <amaurea> the last one was 10000 times [02:11:07 CEST] <amaurea> which operators are allowed in select? Can I use between()|between()|..., or do I have to do or(between(),or(between(),or(...))))? [02:11:19 CEST] Action: amaurea tries | first [02:11:23 CEST] <furq> you can use between()+between()+between()... [02:13:16 CEST] <amaurea> ah, of course [02:13:55 CEST] <amaurea> and video and audio must be selected separately, right? [02:14:00 CEST] <furq> yeah [02:33:26 CEST] <amaurea> select=between(t\,0\,1);aselect=between(t\,0\,1);setpts=N/FRAME_RATE/TB;asetpts=N/SAMPLE_RATE/TB <-- I thought this would work, but it complains about not being able to find a matching stream: Cannot find a matching stream for unlabeled input pad 0 on filter Parsed_setpts_2 [02:41:04 CEST] <amaurea> setting explicit labels gets rid of this error, but instead results in ffmpeg continuing to encode nothing after 1 second has been output: [0:v]select=between(t\,0\,1)[v1];[0:a]aselect=between(t\,0\,1)[a1];[v1]setpts=N/FRAME_RATE/TB;[a1]asetpts=N/SAMPLE_RATE/TB[out] [02:41:20 CEST] <amaurea> I guess I don't understand filter chains well enough [02:42:54 CEST] <amaurea> ok, the being stuck part was just ffmpeg not knowing that it doesn't need to decode the rest of of the stream [02:44:11 CEST] <amaurea> The select approach gives good speed even with 10k segments [02:45:05 CEST] <TheRock> encoder : Lavf - what kind of decoder is this? [03:08:08 CEST] <kepstin> TheRock: that tells you nothing about the codec used - Lavf is short for 'libavformat' (a library that's a part of ffmpeg), so all that line means is that the file was muxed using ffmpeg libraries. [03:09:09 CEST] <TheRock> i see, does png required zlib enabled? [03:53:25 CEST] <kepstin> TheRock: yes [10:57:05 CEST] <Franciman> Hi, is it possible that when converting from one video codec to another, params like fps change? [15:07:32 CEST] <kepstin> Franciman: unless you add some filters or other options, ffmpeg will normally preserve the relative timings of individual frames as close as possible. For more help, please provide a command line and console output. [15:11:33 CEST] <Franciman> thanks [17:13:29 CEST] <giaco> hello [17:15:12 CEST] <giaco> I'm playing with multiple rtp streams. I have the sender working correctly and I have copied the sdp file, but when I do on the listener ffplay -protocol_whitelist file,udp,rtp -i mysdp.sdp it returns bind failed: Address already in use, Invalid data found when processing input. [17:15:56 CEST] <giaco> netcat -peanut confirm that there's nothing listening on the ports [17:18:16 CEST] <c_14> what's your sdp file look like? [17:22:29 CEST] <giaco> c_14: solved. I've found out that the two maps cannot be on sequential ports. Moving 4444+4445 to 4444+5555 worked [17:23:04 CEST] <giaco> But now I have video but no audio. Or, at least, I have a spike of sound on the first second and then silence [17:29:30 CEST] <c_14> yeah, port+1 is used for rtcp [17:30:55 CEST] <giaco> I've just changed mp3lame with aac and edited to sdp file to get only the audio stream, but I still have a spike of sound and then silence. where's the error? [17:56:27 CEST] <kyan> Hi! I just wanted to let you know that ffmpeg 3.4.1, as used by VLC, seems to not work with this file (I guess the file is invalid or something). Windows 10's FLAC decoder and the Clementine music player in GNU/Linux both work with it. It would be nice if ffmpeg did too! https://archive.org/download/McScuse_me__Beats/1.%20McScuse%20me,%20BEATS.f… [17:57:31 CEST] <JEEB> make an issue on trac.ffmpeg.org [17:57:41 CEST] <JEEB> probably the best visibility you could get :P [17:58:01 CEST] <JEEB> also I'm not that sure VLC is using FFmpeg for it? I'm not wholly sure. so please try with ffmpeg.c from FFmpeg first [17:58:11 CEST] <JEEB> (and preferably with current master, not the release branch) [17:59:57 CEST] <kyan> Thanks! [18:03:06 CEST] <kyan> Compiling... [18:09:32 CEST] <Blacker47> kyan, even flac (with --test or --analyze) can't use the file. [18:20:07 CEST] <durandal_1707> kyan: file seems invalid, it have broken image tag [18:22:23 CEST] <kyan> It would be nice to be able to play it though, since some players do work with it... [18:27:31 CEST] <kyan> The flac command can decode it with the -F option, at least. [18:39:31 CEST] <Blacker47> kyan, it is allways a bad idea to try play corrupted files. the file needs to be reuploaded. maybe you can reencode it using -F... [18:44:30 CEST] <giaco> hello. I need help to setup my rtp stream. I got it working but audio and video seems not compatible. If I start video+audio I see video but just a spark of audio, if I start just audio on the server it plays correctly (ffmpeg). I am not succeeding in finding what's wrong [18:47:50 CEST] <kyan> Blacker47: I guess, I just assume that there might be more files with that problem, though, since it was encoded using "reference libFLAC 1.2.1 20070917" according to metaflac. [18:49:08 CEST] <Blacker47> kyan, i have no idea if some old version has have bugs or incompabilities or just failed or damaged encoding. i think some flac people could know more. [18:49:23 CEST] <kyan> mm. thanks :) [18:58:17 CEST] <giaco> please [19:03:27 CEST] <giaco> could you please point me to the right manual page to learn how to make a proper stream combining two input and creating two synchronized rtp streams? [19:27:00 CEST] <vidal> Hi I am not a regular user of ffmpeg but I am relying on it for some crucial activities... Is it really sure that ffserver will be discontinued?? It is a terrible problem for me I have no alternative 😥 [19:29:45 CEST] <JEEB> vidal: well effectively it was not maintained and generally it seemed like there are better alternatives for various use cases. what was yours? [20:20:32 CEST] <vidal_> I am acquiring conferences during events then stream them live. [20:23:25 CEST] <vidal_> At the moment I am trying to use a raspberry pi as a cheap acquisition system to watch children or elders. It was so easy to have a chain : raspi(raspivid + nc) encoder (nc+ffmpeg -> ffm) server (ffserver multiple views including smartphones with app like vlc) [20:23:53 CEST] <JEEB> yea, the general use cases I'm not that interested of, but the technical use cases [20:24:06 CEST] <JEEB> for example, input/output protocols etc [20:24:37 CEST] <JEEB> I've seen https://github.com/sergey-dryabzhinsky/nginx-rtmp-module/ poked around quite a bit for web browsers and mobiles [20:24:44 CEST] <JEEB> which you can feed into with ffmpeg.c [20:25:06 CEST] <JEEB> (it generates RTMP|HLS|DASH from RTMP ingest) [20:30:38 CEST] <vidal_> Thanks for the link. i will have to work a little bit because I have never used rtmp 😶 because things were so simple in http. I am using nginx I will check. thanks again [20:31:17 CEST] <JEEB> rtmp as a thing sucks as adobe will not extend the container utilized within it [20:31:28 CEST] <JEEB> but for various use cases it (currently) works [20:31:37 CEST] <JEEB> and people are working on other formats for ingest [20:31:44 CEST] <vidal_> Anyway now ffmpeg refuses to go for anything else than a file , <i think I will have to have a look in the code. [20:32:07 CEST] <JEEB> well, with current master I've had various things work daily, such as UDP [20:32:15 CEST] <JEEB> so most definitely not just files [20:32:40 CEST] <JEEB> (also it's generally a good thing to distinguish between ffmpeg.c and FFmpeg itself) [20:32:45 CEST] <vidal_> OK I'll have also to investigate.... [20:33:03 CEST] <JEEB> ffmpeg.c is the command line application with a bunch of semi-random logic, and then you have the libraries of which FFmpeg consists [20:33:29 CEST] <JEEB> ffmpeg.c is basically an API client for those libraries, doing a whole lot of stuff but also having some quirks and limitations [20:33:38 CEST] <giaco> could you please help me. I need to understand why my stream audio is not working. [20:34:31 CEST] <vidal_> I was not aware of that [20:35:44 CEST] <vidal_> My plan at first was to try to compile 3.4.2 or do the checkout that is recommended but years ago for another software I suffered many problems while trying to use it against developper's trend and will... [20:38:02 CEST] <JEEB> also for HLS you in theory don't even need to have nginx-rtmp built in [20:38:25 CEST] <JEEB> since you can just PUT/POST the files from ffmpeg.c [20:38:39 CEST] <JEEB> and then just make your normal nginx be OK with receiving stuff from a specific ingest address [20:38:48 CEST] <JEEB> and then share those uploaded things through another end point [20:39:08 CEST] <TheRock> Question: when building ffmpeg with --enable-zlib on Windows with MingW. In which pathes does the configure look? I'm getting always the error zlib not found. [20:39:29 CEST] <JEEB> I think it lacks pkg-config check so it checks the default search paths only [20:39:51 CEST] <JEEB> if it had a pkg-config check you could set PKG_CONFIG_PATH or PKG_CONFIG_LIBDIR to your prefix's /lib [20:40:08 CEST] <JEEB> currently you have to manually augment your --extra-cflags and extra-ldflags [20:40:11 CEST] <JEEB> with the search path [20:40:43 CEST] <JEEB> I've been meaning to post a patch but I've always been unsure how you add a check for a library like zlib, which by default is autoenabled unless you add disable-autodetect [20:40:56 CEST] <TheRock> I already put zlib.h in /mingw/include /usr/include etc., but the config tests fails with zilb.h not found. [20:41:00 CEST] <TheRock> Can you tell me how to specify the path manually? [20:41:33 CEST] <JEEB> --extra-cflags="-I/your/prefix/include" --extra-ldflags="-L/your/prefix/lib" [20:41:37 CEST] <JEEB> which I hate doing [20:41:39 CEST] <JEEB> for the record [20:41:58 CEST] <JEEB> because zlib actually contains a pc file when you install it [20:43:26 CEST] <TheRock> Ty, gonna give it a try [20:43:46 CEST] <JEEB> actually, let's see if I can hack up the pkg-config check and post it on the ML [20:45:15 CEST] <TheRock> running confgiure now. [20:45:23 CEST] <TheRock> just curious about i looked the error previously, it also checks for bzlib.h, it's not shipped with zlib? [20:45:32 CEST] <JEEB> that's a separate check [20:45:35 CEST] <JEEB> it's for bzlib [20:45:40 CEST] <JEEB> which really isn't seemingly used for much at all [20:45:51 CEST] <JEEB> I at least don't care about it in my own builds [20:46:00 CEST] <JEEB> you can ctrl+F bzlib in the configure script [20:46:13 CEST] <JEEB> to see which modules even have a dependency on it (probably partial anyways) [20:46:54 CEST] <JEEB> ok, literally only matroska demuxer suggests bzlib [20:47:07 CEST] <JEEB> and that's just to support compressed headers in that compression format [20:47:21 CEST] <JEEB> which, thankfully, are not really popular at all [20:50:24 CEST] <TheRock> afaik, i had matroska enabled and played .mkvs without zlib before? [20:50:34 CEST] <JEEB> yes [20:50:51 CEST] <JEEB> most matroska files lack compressed headers, and those that had them most likely weren't bzip [20:52:23 CEST] <TheRock> zlib is now found [20:52:29 CEST] <TheRock> but it hangs on bzlib.h [20:52:30 CEST] <TheRock> https://nopaste.xyz/?998b3b1ad8df862b#rXzxk9LJ/pbzFvw9TBFwdc2hjhkI5wsGKkR7D… [20:52:34 CEST] <TheRock> so i can delete bzlib.h? [20:52:38 CEST] <TheRock> from the check? [20:53:12 CEST] <JEEB> uhh, that sounds really weird [20:53:27 CEST] <JEEB> the zlib test does not check for bzip2 [20:54:09 CEST] <TheRock> i just need that bitch for png ;( [20:54:25 CEST] <TheRock> any idea how to continue now? [20:55:11 CEST] <JEEB> well you're clearly failing at not something zlib [20:55:23 CEST] <JEEB> so you have poked the configure script or something? [20:55:28 CEST] <TheRock> nothing at all [20:55:41 CEST] <JEEB> I mean, I am building with zlib and without bzlib2 [20:55:47 CEST] <JEEB> and it WorksForMe [20:55:54 CEST] <TheRock> but matroska is enabled? [20:55:58 CEST] <JEEB> yes, of course [20:56:55 CEST] <JEEB> let me check the bzip check [20:56:57 CEST] <TheRock> Hm Hm hMh [20:57:32 CEST] <JEEB> but yes, it seems like I've got an initial version of the zlib check done [20:57:37 CEST] <JEEB> let's see if it works [20:58:32 CEST] <vidal_> Thanks @JEEB I'll try to investigate your idea on nginx fed by ffmpeg.c I'll let some traces if I succeed. [20:59:59 CEST] <TheRock> matroska_demuxer_suggest='bzlib lzo zlib' [21:01:03 CEST] <JEEB> TheRock: yes, that's the only place where bzlib is utilized [21:01:07 CEST] <JEEB> and it is not a requirement [21:01:19 CEST] <TheRock> Gonna remove matroska now to test [21:01:19 CEST] <JEEB> unless specifically "enabling" it means you want all features, which is kind of retarded [21:01:48 CEST] <JEEB> wonder if you can then disable-bzlib [21:01:54 CEST] <JEEB> if that is the case [21:01:54 CEST] <TheRock> but why is it "required" on my OS? i haven't altered any config files [21:02:04 CEST] <TheRock> --disable-bzlib didn't work [21:02:07 CEST] <JEEB> ok [21:02:25 CEST] <JEEB> TheRock: it isn't for your OS. I bet if you stop disabling everything it will nicely build the limited matroska demuxer [21:02:33 CEST] <JEEB> since _suggest is exactly that [21:02:47 CEST] <JEEB> it might be some dumb logic of "if you specifically enable it, you want ALL THE THINGS" [21:03:07 CEST] <JEEB> also classic thing, of course I get shell syntax incorrect [21:03:08 CEST] <TheRock> yeah matroska builds just fine, but once zlib is enabled it gets greedy and wants bzlib as well ;( [21:03:10 CEST] Action: JEEB sighs [21:03:25 CEST] <JEEB> TheRock: it really shouldn't. either the script is weird or something else is weird [21:03:47 CEST] <JEEB> oh right, I forgot a ; [21:03:56 CEST] <TheRock> I just removed matroska [21:04:03 CEST] <TheRock> *still wants bzlib* [21:04:41 CEST] <TheRock> using ffmpeg 3.4.2, without any modifications [21:04:45 CEST] <JEEB> unless you have disable-autodetect it will try to find it, but that shouldn't be a failure [21:05:01 CEST] <JEEB> so something wonky is going on *somewhere* [21:05:27 CEST] <JEEB> yay [21:05:32 CEST] <JEEB> got my zlib pkg-config check done [21:06:34 CEST] <JEEB> https://github.com/jeeb/ffmpeg/commit/351fbff9339ab631913f0de1e125b489c3201… [21:06:37 CEST] <JEEB> if you want to give it a whirl [21:07:09 CEST] <JEEB> also now I am reminded that I should probably change wording [21:07:21 CEST] <JEEB> s/me/one/ [21:09:25 CEST] <JEEB> heh, just checked what the only thing was that utilized lzma [21:09:28 CEST] <JEEB> the TIFF thing [21:09:48 CEST] <Boobuigi> I use lavfi -show_entries with ffprobe to detect scene changes and fades. It works great, but I would like to see some kind of progress indication. The best I've found is -v debug, but that produces waaaaay too much output. Can anyone help? [21:16:11 CEST] <JEEB> Boobuigi: I don't think you get that from ffprobe [21:16:19 CEST] <JEEB> would probably be worth it to make your own API client for that [21:16:48 CEST] <Boobuigi> Thanks for checking. [21:17:51 CEST] <Boobuigi> I suppose I'll try piping -v debug output through some kind of formatter. [21:18:31 CEST] <JEEB> (I didn't check anything, I just don't think that's a thing to expect from ffprobe) [21:19:16 CEST] <Boobuigi> Well, you checked your brain. That's good enough for thanks. [21:20:09 CEST] <JEEB> but yea, since ffprobe is so limited I'd really probably just do a proper thing that would only do what you need (whatever lavfi filter chain you need and the output of which), which would export you the state properly [21:28:29 CEST] <Boobuigi> Using ffmpeg and not ffprobe? [21:29:57 CEST] <JEEB> not sure what you'd get out of that if you mean ffmpeg.c instead of ffprobe.c? [21:30:04 CEST] <JEEB> (or do you mean the APIs?) [21:31:29 CEST] <TheRock> JEEB: i just added bzlib as well [21:31:31 CEST] <TheRock> https://nopaste.xyz/?7d692817cfea47a9#D4pBJuljRY0hJ8SQy4J6O4AUWOWQnJTyVkz7x… [21:31:42 CEST] <TheRock> Is that fail eventually due to the compile errors? [21:31:48 CEST] <TheRock> I use MSVC 2013 [21:32:07 CEST] <TheRock> Even with bzlib, it fails [21:33:02 CEST] <TheRock> not even sure if the errors are related to zlib [21:33:05 CEST] <JEEB> uhh, yea [21:33:08 CEST] <JEEB> that seems rather unrelated [21:33:16 CEST] <JEEB> at least looking at that test.c [21:33:29 CEST] <JEEB> which is just static inline int foo(int a) { return a; } [21:33:54 CEST] <JEEB> seems like it's rather failing at trying to utilize inline [21:34:01 CEST] <JEEB> since it wants ( after inline [21:34:11 CEST] <JEEB> I thought there was something special for MSVC for that, maybe? [21:34:26 CEST] <TheRock> I'm not quite sure if the test is for zlib/bzlib [21:34:32 CEST] <JEEB> it definitely isn't [21:34:34 CEST] <TheRock> that are just the last lines before zlib not found [21:34:39 CEST] <TheRock> so, i guess i can ignore it [21:34:44 CEST] <TheRock> but still weird it doesn't work [21:35:07 CEST] <JEEB> at this point I would nuke your build dir and start from a clean one, although the configure script isn't affected by previous runs [21:35:22 CEST] <JEEB> are you sure you are telling teh configure script that you're under MSVC? [21:35:52 CEST] <TheRock> yes toolset=msvc, built previously without png support [21:35:59 CEST] <TheRock> since i want png=zlib/bzlib [21:36:01 CEST] <TheRock> problems start [21:36:35 CEST] <TheRock> No more *zlib.h* *bzlib.h* errors anymore, from the config I wouldn't know why it fails [21:37:12 CEST] <JEEB> well zlib at least has special flag conversion for it [21:37:34 CEST] <JEEB> bzlip doesn't, but that still doesn't explain why on earth it would be wanting bzlip if you're not enabling it :P [21:39:04 CEST] <TheRock> i will nuke the directroy now [21:39:24 CEST] <JEEB> also which shell are you using? bash or dash? [21:39:41 CEST] <JEEB> (dash is just quite a bit faster on native windows) [21:40:09 CEST] <TheRock> bash [21:40:17 CEST] <TheRock> invoked through msys.bat [21:40:49 CEST] <JEEB> next time to save time you might want to try out running dash ../configure --blah [21:40:57 CEST] <JEEB> since dash is quite a bit simpler and quicker [21:41:03 CEST] <JEEB> and on windows that makes an actual difference [21:41:34 CEST] <TheRock> Hmhm, yeah but it just builds fine [21:41:38 CEST] <TheRock> without zlib stuff [21:41:57 CEST] <JEEB> ../configure --disable-autodetect --enable-zlib [21:42:04 CEST] <JEEB> try that and let's see where we get [21:48:21 CEST] <TheRock> running now [21:50:57 CEST] <TheRock> failed ;_( [21:51:49 CEST] <TheRock> using a new dir now [21:57:48 CEST] <TheRock> JEEB: https://nopaste.xyz/?e3de09a3a955adb8#c7Nzg9tQEaWgrcbZZLaFO6Mt+w7NIOXz7uBTe… [21:57:53 CEST] <TheRock> here is the new output from a new dir [21:58:12 CEST] <TheRock> It's quite hard to tell, if the errors are from bzip/zlib at begin? [21:58:26 CEST] <TheRock> it appears there is a redefinition of time_t which causes a fail [21:58:35 CEST] <JEEB> can you pastebin the whole thing? [21:59:39 CEST] <TheRock> Here is the entire log [21:59:40 CEST] <TheRock> https://nopaste.xyz/?d6d62df6fbc01f23#h6mq8r6jv52tcqgX00E0+yBYjZTLEo/jx1tGs… [22:00:07 CEST] <TheRock> search for "zlib.h" to get to the compile output [22:00:52 CEST] <TheRock> to me it looks like there is a header error in the zlib compliation [22:00:58 CEST] <TheRock> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\INCLUDE\crtdefs.h(580) : see declaration of 'time_t' [22:01:04 CEST] <TheRock> but not sure, if thats from the zlib test [22:01:12 CEST] <JEEB> also just for the record during our initial discussion I did not note that you were building with MSVC [22:01:27 CEST] <TheRock> oh, ok [22:01:41 CEST] <JEEB> so you are clearly now including stuff from the mingw setup you have [22:01:44 CEST] <JEEB> which doesn't mix well [22:01:46 CEST] <JEEB> with the MSVC stuff [22:01:57 CEST] <JEEB> so just put your zlib built with MSVC *somewhere* [22:02:03 CEST] <TheRock> yeah, looks like. I placed the zlib stuff in /mingw/include /mingw/lib [22:02:05 CEST] <JEEB> and add extra_*flags [22:02:13 CEST] <TheRock> and added that dir [22:02:14 CEST] <JEEB> yea, don't mix mingw-w64 and MSVC [22:02:16 CEST] <TheRock> so thats probably the problem [22:02:20 CEST] <JEEB> yes, quite likely [22:02:34 CEST] <JEEB> because /mingw-get/include/process.h sounds like a mingw-w64 process.h [22:03:08 CEST] <TheRock> hopefully it works now =) [22:03:13 CEST] <TheRock> gonna move it to /home/zlib [00:00:00 CEST] --- Sun May 6 2018

1 0

ffmpeg-devel.log.20180504
by burek 05 May '18

05 May '18

[00:12:26 CEST] <cone-506> ffmpeg 03Haihao Xiang 07master:314994051b3d: vaapi_encode_h264: Take VAAPIEncodeH264Context::sei_needed as an ORed value [02:21:46 CEST] <cone-506> ffmpeg 03Michael Niedermayer 07master:dc7a8f731084: avcodec/h263dec: Document padding_bug_score heuristic used for wrong stuffing [10:08:55 CEST] <cone-914> ffmpeg 03Rodger Combs 07release/4.0:b32f86596953: lavf/dashenc: don't call flush_init_segment before avformat_write_header [11:22:11 CEST] <JEEB> ugh, sorry for the top-post on the mailing list. I felt like I had to reply ASAP and was on my phone [12:14:44 CEST] <durandal_1707> ubitux: if you not gonna review lut3d and edgedetect patches, i gonna apply them soon [12:14:58 CEST] <ubitux> i'll do that later today if you can wait [12:16:41 CEST] <JEEB> ugh [12:19:04 CEST] <JEEB> what's with the Steven Liu guy? can't he see the mismatching types, and the lack of timestamp discontinuity handling, and the possible issues with nonzero DTS.. [12:19:23 CEST] <JEEB> instead of addressing them, why just go with "it's all gonna be alright" [12:19:52 CEST] <JEEB> (not all things have to be things that need to be fixed, but at least goddamn looked into - which most likely he didn't) [12:19:57 CEST] <kierank> JEEB: he's a maintainer lol [12:20:54 CEST] <wm4> ah ffmpeg's development "model" [12:20:58 CEST] <JEEB> michaelni: if he goes on pushing that thing, please do some action as that patch clearly is not gone through the process [12:21:32 CEST] <JEEB> I don't give a flying crap if this is called the status quo with the development model by some people, it is clearly not done yet [12:25:08 CEST] <wm4> well, the current highly vague rules only lead to conflict and discontent, until they (hopefully) either lead to clarifications and improvements, or destroy the project as deserved [12:28:09 CEST] <JEEB> that I don't disagree with, and writing rules generally is hard [12:28:37 CEST] <JEEB> or at least it seems like coming up with any sort of attainable ones is [12:28:41 CEST] <JEEB> and/or upkeeping them [12:28:51 CEST] <JEEB> but I really don't care about that bigger problem at the moment :P [12:28:59 CEST] <JEEB> my concern is primarily what I saw right now [12:34:12 CEST] <wm4> writing/defining rules actually isn't that important, it's more important to establish how things should work, and to enforce it [12:34:22 CEST] <JEEB> yes [12:34:28 CEST] <JEEB> that's what I was *trying* to say [12:34:29 CEST] <wm4> currently this is not working and we have flamewars every week [12:35:11 CEST] <wm4> not like I'm a project management expert, but it seems pretty obvious that the current situation is really bad [12:57:24 CEST] <michaelni> JEEB, what is the issue with the patch ? about discontinuities, muxers generally should not have discontinuous input timestamps [12:59:55 CEST] <JEEB> dts is int64_t, not "unsigned int" [13:00:17 CEST] <JEEB> just read the initial comments and if any of them are not relevant then they are not relevant. also f.ex. movenc.c takes in discontinuities just fine?! [13:00:29 CEST] <JEEB> also I am not sure if I talked about discontinuities [13:00:33 CEST] <JEEB> just having a nonzero start time [13:00:50 CEST] <JEEB> but that's less important than handling the FLV int32_t timestamp roll-over [13:01:07 CEST] <JEEB> as in, if we just make sure that we do the roll-over correctly I'm OK with that [13:03:37 CEST] <JEEB> also my original commetns were written under the assumption of unsigned 32bit since that's what I assumed with "unsigned int", but in reality we need to do roll-over over int32_t [13:06:59 CEST] <michaelni> JEEB, i think you should post that to the ML [13:08:07 CEST] <michaelni> i think theres maybe some misunderstanding between people [13:10:27 CEST] <JEEB> I don't have the mail client open right now, and I have other things to attend to right now [13:10:31 CEST] <JEEB> unfortunately [13:11:21 CEST] <michaelni> JEEB, btw about int32_t, the >>24 & 0x7f is what flvenc does currently, i understand that this neverf sets the sign bit even for negative int64. Which may be wrong and maybe should be changed but iam not sure this belongs in this patch [13:14:04 CEST] <JEEB> nah, the timestamps seem to start at zero so that's probably done understandably [13:15:13 CEST] <JEEB> although to be 100% correct someone would have to check how adobe's implementation does timestamp roll-overs [13:15:25 CEST] <JEEB> is it just over zero, or from negative [13:15:40 CEST] <JEEB> (most likely it will just roll over in positive values) [13:16:06 CEST] <JEEB> so effectively we're rolling over an unsigned 31 bit integer :P [13:30:12 CEST] <michaelni> JEEB, ive looked a bit more at this now, isnt the "0 ts might be wrong if start is not 0" issue unrelated to this patch ? Its writing 0 currently, it still does after the patch. only the midstream headers change which feels correct [13:31:02 CEST] <michaelni> i agree that 0 might be bad if starttime is far from 0 but the patch doesnt introduce or change this issue [14:24:53 CEST] <durandal_1707> Compn: why are you raising your opinions on ml? [14:26:24 CEST] <wm4> to make it worse [14:36:07 CEST] <cone-914> ffmpeg 03wm4 07master:022d4a2114d2: avformat/matroskaenc: do not write timebase as framerate [14:36:08 CEST] <cone-914> ffmpeg 03wm4 07master:1d642ebfdb31: avformat/hls: don't propagate deprecated "user-agent" AVOption [14:43:56 CEST] <cone-914> ffmpeg 03Paul B Mahol 07master:4bad76b6e9e4: avfilter/vf_amplify: add more options for finer filtering [14:50:53 CEST] <Compn> durandal_1707 : because that is where discussion goes [14:56:50 CEST] <Compn> .mkv : Used for Video files, as well those containing audio (movies) or video only [14:56:50 CEST] <Compn> .mka : Used for audio only files, can contain any supported audio compresion format, such as MP2, MP3, Vorbis, AAC, AC3, DTS, or PCM [14:56:50 CEST] <Compn> .mk3d : For files with stereoscopic (3D) video [14:56:50 CEST] <Compn> .mks :Used for Subtitles that an 'elementary' matroska stream [14:57:08 CEST] <Compn> cmon, someone should tell the mkv people to get rid of this .mks .mk3d shit we've never heard of or seen [14:57:22 CEST] <nevcairiel> just because you have not seen those doesnt mean they exist [14:57:27 CEST] <nevcairiel> get off your soapbox already [14:57:34 CEST] <nevcairiel> dont exist* [14:58:13 CEST] <durandal_1707> Compn should kill mplayer already [15:41:29 CEST] <ubitux> should i switch to non-simd op to do f(ABCD) = {A,A+B,A+B+C,A+B+C+D}? [15:42:59 CEST] <ubitux> maybe with a bunch of add and ext with 0000 i could do sth [15:43:02 CEST] <jdarnley> If you have oodles of spare regs you could do it [15:44:27 CEST] <jdarnley> vector registers I mean [15:44:38 CEST] <ubitux> yeah aarch64 has a shit ton of them [15:45:18 CEST] <nevcairiel> 3 adds and 3 shifts could do it, not sure how efficient that is [15:45:28 CEST] <jdarnley> Oh, I was picturing x86 instructions to do it [15:46:33 CEST] <jdarnley> And I guess it depends whetehr ABCD are in vector regs already. [15:46:47 CEST] <jdarnley> *whether [16:08:51 CEST] <Chloe> JEEB: you have further comments for flvenc: Fix sequence header update timestamps? [16:09:43 CEST] <nevcairiel> why does everyone feel like rushing that patch, its been on the ML for 21 hours only and the original author didnt even have time to respond to any comments yet [16:10:57 CEST] <Chloe> nevcairiel: well i wanted to ask for more time on behalf of JEEB [16:11:53 CEST] <Chloe> I guess it doesnt matter if there are more comments, just ask for more time anyway [16:12:37 CEST] <JEEB> Chloe: I am currently drinking a beer after a not-so-perfect work week. to be honest, I don't even use rtmpenc, but I saw clear possible issues there (like passing int64_t through "unsigned int", and not being sure how the FLV timestamp wrap-over is going to be handled) [16:14:26 CEST] <Chloe> JEEB: ya we gucci. Im not able to do much cause I also feel like shit but it shouldnt get pushed until you give some more comments at least hopefully [16:19:55 CEST] <durandal_1707> Chloe: why you feel like that? [16:22:08 CEST] <Chloe> durandal_1707: its not ffmpeg related. [16:34:31 CEST] <cone-914> ffmpeg 03Sergey Lavrushkin 07master:9479955c6265: Adds SRCNN filter. [17:57:00 CEST] <cone-914> ffmpeg 03wm4 07master:7074a7ccd9a4: avformat: add vapoursynth wrapper [18:15:43 CEST] <durandal_1707> have nothing left to do, help me! [18:18:35 CEST] <wm4> fix y4m seeking [18:19:01 CEST] <jamrial> even more sizeof(AVFrame) :( [18:20:12 CEST] <jamrial> you really couldn't tidy up the rawvideo implementation posted in doom9 and push that instead? [18:20:38 CEST] <wm4> as if ABI mattered [18:21:06 CEST] <jamrial> it does, we already released 4.0 with the new soname [18:21:08 CEST] <wm4> as far as I can see it only sets a random unused number anyway [18:22:28 CEST] <wm4> also you didn't comment on this when kmsgrad added it [18:22:44 CEST] <durandal_1707> wm4: y4m seeking works fine here [18:34:17 CEST] <JEEB> durandal_1707: do you want to check out that one case I've not had time to debug? [18:42:39 CEST] <durandal_1707> JEEB: the midstream parameters change? i thought that is unsupported [18:44:02 CEST] <JEEB> well at least the audio things work :P [18:44:19 CEST] <JEEB> if input stream switches between 5.1 and stereo [18:44:26 CEST] <JEEB> and my output is stereo, it works a'OK [18:44:35 CEST] <JEEB> I think what didn't work is something different [18:44:42 CEST] <JEEB> but that's not as relevant [18:45:13 CEST] <JEEB> in this case it's to find out what happens when the audio changes and why it originally caused the end-of-stream trigger for subtitle overlay [18:45:29 CEST] <JEEB> I made a fix for it, but it seems to have some imperfections regarding performance [18:45:40 CEST] <JEEB> mostly because I probably didn't dive deep enough [18:46:03 CEST] <JEEB> I can share a sample and a replication command line if you are interested [18:46:53 CEST] <durandal_1707> JEEB: share it [18:47:11 CEST] <JEEB> roger [18:48:20 CEST] <JEEB> replication filter chain https://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/227511.html [18:48:23 CEST] <JEEB> then the sample... [18:49:08 CEST] <JEEB> durandal_1707: https://kuroko.fushizen.eu/samples/2018-03-26-subtitles_disappear_after_ad_… [18:49:42 CEST] <JEEB> if you want to see the full glory, revert http://git.videolan.org/?p=ffmpeg.git;a=commit;h=e760c12aeef608aa8b41666468… [18:50:10 CEST] <JEEB> there still seems to be something wrong, though, possibly buffering or something. you don't notice it with file->file, but live stuff seems affected [18:51:41 CEST] <wm4> 90% of ffmpeg development effort is arguing about bullshit [18:52:25 CEST] <JEEB> durandal_1707: the diff I used to debug it https://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/227630.html [19:15:33 CEST] <JEEB> durandal_1707: anyways do note if you figure anything out [19:15:56 CEST] <JEEB> and that's why I mentioned if only the relevant parts should be re-init'd in a filter chain [19:16:00 CEST] <JEEB> instead of the whole thing [20:05:29 CEST] <JEEB> who's reviewing the mailing list queue? [20:05:37 CEST] <JEEB> hanna's got a mail in the queue it seems [20:17:12 CEST] <durandal_1707> Compn ^ [20:40:14 CEST] <ubitux> durandal_1707: do you have the edgedetect patchset in a branch? [20:40:20 CEST] <ubitux> i'd like to give a try [20:40:58 CEST] <durandal_1707> ubitux: cant you use patches on ml? [20:41:07 CEST] <ubitux> i can [20:41:19 CEST] <ubitux> it's just simpler if i run a git fetch [20:43:47 CEST] <durandal_1707> ubitux: see canny branch [20:44:10 CEST] <ubitux> thanks [20:55:23 CEST] <cone-914> ffmpeg 03Aman Gupta 07master:fe0a6bcbda0f: avcodec/mediacodec_wrapper: add helper to fetch SDK_INT [20:55:24 CEST] <cone-914> ffmpeg 03Aman Gupta 07master:f6681feda641: avcodec/mediacodecdec: restructure mediacodec_receive_frame [20:55:25 CEST] <cone-914> ffmpeg 03Aman Gupta 07master:a75bb5496ac6: avcodec/mediacodecdec: wait on first frame after input buffers are full [20:55:26 CEST] <cone-914> ffmpeg 03Aman Gupta 07master:9b563f6584b5: avcodec/mediacodecdec: add workaround for buggy amlogic mpeg2 decoder [20:55:54 CEST] <JEEB> has anyone received parser buffer reallocation failures from libavcodec/parser.c? [20:56:03 CEST] <JEEB> from MPEG-TS input [20:57:15 CEST] <JEEB> Haven't been able to capture samples of where it has happened, but if the data's not broken that'll be fun :) [20:58:25 CEST] <tmm1> haven't seen that [20:59:20 CEST] <JEEB> I'll probably set up a source-dumping setup next week since I've had it happen on the same source stream a few times now [21:05:17 CEST] <jamrial> JEEB: sounds like oom? the only way to get that kind of error in parse.c seems to be that [21:05:27 CEST] <jamrial> it should also print the amount of memory it tried to allocate [21:29:45 CEST] <cone-914> ffmpeg 03Paul B Mahol 07master:901dc11bb67e: avfilter/vf_lut3d: add planar rgb support [21:34:14 CEST] <cone-914> ffmpeg 03Paul B Mahol 07master:aba39cc1f18f: avfilter/vf_convolution: add column/vertical mode [21:39:42 CEST] <tmm1> rcombs: did you see this hevc decoding regression after the videotoolbox_postproc_frame patch [21:40:42 CEST] <rcombs> yeah, haven't had a chance to look at it yet [21:41:28 CEST] <tmm1> trying to poke at it but i dont' understand this postproc stuff yet [21:41:38 CEST] <tmm1> weird it doesn't trigger on all samples either [21:41:44 CEST] <tmm1> here's a shorter one that does it: https://s3.amazonaws.com/tmm1/videotoolbox/germany-hevc-zdf.ts [21:50:01 CEST] <JEEB> thanks to whomever who passed through hanna's e-mail :) [21:58:38 CEST] <cone-914> ffmpeg 03Paul B Mahol 07master:d122c8b1028b: avfilter/vf_edgedetect: add canny mode [21:58:39 CEST] <cone-914> ffmpeg 03Paul B Mahol 07master:0bcc66571aab: avfilter/vf_edgedetect: add planes option [21:58:40 CEST] <cone-914> ffmpeg 03Paul B Mahol 07master:20c83be27a3e: avfilter/vf_edgedetect: add more formats support to canny mode [22:04:47 CEST] <rcombs> tmm1: €ó¿ì§§§§ [22:06:53 CEST] <durandal_1707> JEEB: only slowdown i get is spam: Changing frame properties on the fly is not supported by all filters. [22:09:10 CEST] <JEEB> yea, I don't think with my fix the thing is actually slowing down - but rather it might have to do with buffering or something. it seems to drop out with pushing live output into an HTTP end point [22:09:23 CEST] <JEEB> without my fix it seems to work fine [22:10:59 CEST] <JEEB> my next step would have been to start adding logging towards where AVFrames are received from the filter chain [22:14:55 CEST] <durandal_1707> JEEB: so what is an issue? this happens only over network and not with files? [22:15:33 CEST] <JEEB> I would like you to clear your mind, revert my fix and check how you would go about debugging the original issue [22:15:45 CEST] <JEEB> because I'm pretty sure I just didn't dig deep enough :P [22:15:52 CEST] <JEEB> also it should be relevant in file input as well [22:16:08 CEST] <durandal_1707> but i see nothing wrong, fps=103 [22:16:10 CEST] <JEEB> whatever the issue is, it should be visible with any in/output protocol [22:17:27 CEST] <JEEB> ok, and going by clear things that seem to go wrong there, if you are encoding the audio you should notice that there's a "audio PTS went backwards" warning [22:17:37 CEST] <JEEB> that's not because of input [22:17:50 CEST] <JEEB> it seems like the audio filter chain outputs the input PTS as-is after the re-init [22:18:17 CEST] <JEEB> forgetting that you had an offset because input frame size != output frame size (most visible with AAC) [22:18:27 CEST] <JEEB> since AC3 is 15xx samples per frame [22:18:36 CEST] <JEEB> and AAC is (generally) 1024 [22:19:41 CEST] <JEEB> but that happens pre/post my fix so that isn't seemingly breaking anything - just either seemingly incorrect lavfi API usage, or incorrect handling of things in lavfi (one or the other, not sure if the lavfi docs specify this) [22:24:05 CEST] <durandal_1707> JEEB: with aresample, I get strange error: Error while add the frame to buffer source(Invalid argument). [22:24:18 CEST] <JEEB> yea [22:24:28 CEST] <JEEB> those come before-after my patch I think? [22:24:36 CEST] <JEEB> and yes, as I noted in the mailing list entry I mentioned [22:24:43 CEST] <JEEB> you need the audio to get the bug to happen [22:24:48 CEST] <JEEB> no audio - no filter chain reset [22:26:03 CEST] <JEEB> https://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/227511.html [22:26:05 CEST] <JEEB> for the record [22:26:21 CEST] <JEEB> and my debugging codes https://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/227630.html [22:30:55 CEST] <tmm1> rcombs: looks like some AVFrame are being returned with hw_frames_ctx==NULL [22:31:02 CEST] <rcombs> sounds bad [22:59:07 CEST] <tmm1> rcombs: lol wtf, hw_frames_ctx is def being set but by the time postproc is called its randomly back to NULL sometimes [23:01:55 CEST] <durandal_1707> lol, overlay in vs is so slooow [23:07:49 CEST] <rcombs> tmm1: watchpoint! [23:08:09 CEST] <rcombs> tmm1: that or it's getting set for one field but not the other [23:10:10 CEST] <BBB> does anyone want to push the libvmaf patch for me? [23:14:04 CEST] <jamrial> i was going to ask which one, but well [23:23:55 CEST] <cone-914> ffmpeg 03Paul B Mahol 07master:244d4ba0da00: avfilter/vf_lut3d: fix typo [23:25:41 CEST] <durandal_1707> BBB: which patch? [23:26:25 CEST] <BBB> https://patchwork.ffmpeg.org/patch/8699/ [23:31:29 CEST] <cone-914> ffmpeg 03Kevin Wheatley 07master:51775bc1cdef: avfilter/vf_libvmaf: the libvmaf filter tried to join on an invalid thread id [23:32:24 CEST] <durandal_1707> FUUUUUUUUUUUUUUUUUUUUUUU, i wanted to apply it [23:33:37 CEST] <jamrial> haha [23:35:57 CEST] <BBB> ty <3 [23:57:59 CEST] <BtbN> the ffmpeg cli does not support changing bitrate mid stream via commands, does it? [00:00:00 CEST] --- Sat May 5 2018

1 0

ffmpeg.log.20180504
by burek 05 May '18

05 May '18

[00:43:37 CEST] <poutine> Is there a way of dumping all encountered PIDs in a mpegts file? [05:52:39 CEST] <servmeme> c [10:28:19 CEST] <termos> When doing HTTP PUT with FFmpeg with HLS segments/playlists, the HTTP connection is terminated right after the body is sent, FFmpeg is not waiting for a response like 200 for example. Is there a way to make it wait for such a response? [11:36:54 CEST] <Tzimmo> I'd like to cut out commercials (via command line, preferably) from MPEG-TS HD video streams. For SD, I use Project-X to sync A/V and then cutting is easy, but because it doesn't support HD, it cannot be used for HD videos. Could I use ffmpeg to do the same, a) with I-frame accuracy, b) with frame accuracy so that it could encode only those frames leading in/out to the next I-frame (using about the same bit [11:37:00 CEST] <Tzimmo> rates as the original) but mostly keep the original video as-is, except resyncing audio with video (in DVB-T(2) transmission the audio is transmitted about a second before video (or was it after, but anyway) [11:38:32 CEST] <ariyasu> yes [11:38:53 CEST] <ariyasu> but you would be much better with a gui tool designed to do the job such as tsdoctor or videoredo [11:39:19 CEST] <sfan5> a) yes b) you can piece such a thing together with ffmpeg, but there's no simple "built in" way to do it [11:39:24 CEST] <Tzimmo> Ah, the OS is Linux as well [11:39:49 CEST] <ariyasu> https://pastebin.com/RNTpCV8b [11:40:09 CEST] <ariyasu> i build this windows script a few years ago to do what you specified [11:40:18 CEST] <Tzimmo> I'd like to have a script to redo that operation if needed, so once I have the cutpoints, I could just run the script. [11:40:20 CEST] <ariyasu> it's messy but you can get an idea how to do it, and bort it ot bash [11:40:32 CEST] <ariyasu> port even [11:41:50 CEST] <Tzimmo> Does it sync audio with video? Or just keep then out of sync as the original ts file has? i.e., if I don't cut anything, would the resulting file be identical to the source? [11:43:06 CEST] <ariyasu> the sync relative to video will be kept [11:43:45 CEST] <ariyasu> all it is doing is marking start and end points then using -c copy to write that to a new file, then when you have cut all the segments it cats it back together [11:43:47 CEST] <Tzimmo> I'll try it out but I think I have tried this before and failed with it because of, at least, A-V sync issues... [11:43:50 CEST] <ariyasu> like i say it's messy but it works [11:44:40 CEST] <Tzimmo> So basically I could just use dd if=input.ts of=output.ts bs=188 skip=MMM count=NNN to do the same? [11:45:42 CEST] <Tzimmo> Well, I'll give it a try and let you know what I find [12:35:13 CEST] <bon> hello :) i am trying to check metadata from a multicast video source. ffprobe udp://@x.x.x.x:yyyy works [12:35:35 CEST] <bon> howerver when i set format to xls or json the metadata is not there (service_name specifically) [12:35:41 CEST] <bon> what's my error there? :) [12:37:26 CEST] <JEEB> try adding -show_X [12:37:34 CEST] <JEEB> it should be in the streams *or* programs [12:37:38 CEST] <JEEB> -show_streams -show_programs [12:55:18 CEST] <bon> JEEB: thx, it is present in show_programs data [15:36:02 CEST] <zerodefect> When building FFmpeg from source, I usually use something like 'checkinstall' to create the .deb package (Ubuntu). I notice that when I perform a 'make install', it also installs the header files. Is there a way to configure such that the install step only installs executables/shared libs without the other files which are not required for deployment? [15:37:00 CEST] <BtbN> no [15:37:35 CEST] <zerodefect> Ok. Thanks. Out of interest. Is that the way most projects work? [15:37:46 CEST] <JEEB> yes [15:37:54 CEST] <JEEB> only distributions usually separate debug and non-debug [15:38:00 CEST] <JEEB> (if they do) [15:38:38 CEST] <zerodefect> Understood. [15:41:07 CEST] <furq> zerodefect: there's make install-progs [15:41:47 CEST] <zerodefect> @furq: Sounds promising. Let me investigate? [16:53:12 CEST] <da1n1us> hello... can anyone explain how ffmpeg hls_flags 'periodic_rekey' works? [16:54:03 CEST] <da1n1us> https://pastebin.com/VGb3LiGd [17:03:34 CEST] <dubrsl> Hi. I'm trying to use new future in 4.0 - var_stream_map in hls muxer for generate multibitrate HLS stream. Use first example from documentation. And if I add different profiles (-profile:v:0 baseline and -profile:v:1 main) the variants 62000 bps and 800000 bps, segment 1525445599, are not aligned (first frame PTS not equal 362040000 != 362160000) [17:03:34 CEST] <dubrsl> Is it bug? [17:26:23 CEST] <JEEB> that sounds like b-frame delay if debug_ts gives you same timestamps for throwing into muxer [18:03:49 CEST] <Marti__> hi, i am trying to install handbrake and I get: ERROR: opus not found. It seems that ffmpeg does not find my opus installation, which I have in a non-standard folder. I found no way to tell the handbrake config that my opus installation is somewhere else yet. [18:33:29 CEST] <JEEB> Marti__: PKG_CONFIG_PATH=/path/to/libopus/lib/pkgconfig [18:33:49 CEST] <JEEB> that actually *adds* to the pkg-config search PATH [19:30:19 CEST] <dubrsl> JEEB: How can I check timestamps that throwing into muxer? [19:31:57 CEST] <JEEB> -debug_ts [19:32:11 CEST] <JEEB> that will show you a lot of timestamps within ffmpeg.c [19:32:16 CEST] <JEEB> input and output side [19:58:47 CEST] <Marti__> <JEEB>: thanks for the help, still got the same error. I think the problem is that when handbrake installs contributing libraries it uses a different environment. PKG_CONFIG_PATH of ffmpeg is ouput and it does not contain the path to opus [20:04:03 CEST] <Marti__> btw, tried installing ffmpeg independent of handbrake and it worked [20:21:18 CEST] <ritsuka> Marti__: handbrake doesn't use ffmpeg, it should compile its own libav and use it [20:25:46 CEST] <JEEB> I think it depends on the version? [20:26:01 CEST] <JEEB> anyways, he's seemingly using Handbrake's build scripts and those are irrelevant to either FFmpeg or Libav anyways [20:26:04 CEST] <JEEB> (Ž4@) [20:26:40 CEST] <ritsuka> yup, it should compile its own static version automatically [20:27:10 CEST] <ritsuka> JEEB: it should switch to ffmpeg soon, but no one is working on the switch right now [22:18:12 CEST] <TheRock> i just need decoding. To reduce the size i used: --disable-everything. What's required to support all formarts/codecs? --enable-dexmuxers --enable-decoders --enable-parsers is required, right? [22:20:34 CEST] <JEEB> I hope you have tested your app with a non-limited build first? [22:20:44 CEST] <JEEB> also do you need protocols? (file is one!) [22:22:42 CEST] <TheRock> yeah, i used to specify a lot of codecs manually [22:22:52 CEST] <TheRock> but turned out rare files can't be heard or played [22:23:00 CEST] <TheRock> now, i'm building with $ ./configure --disable-everything --extra-version=QtAV --disable-debug --enabl [22:23:00 CEST] <TheRock> e-static --disable-shared --enable-runtime-cpudetect --toolchain=msvc --extra-l [22:23:00 CEST] <TheRock> dexeflags='-SUBSYSTEM:CONSOLE,5.01' --enable-avresample --enable-decoders --ena [22:23:00 CEST] <TheRock> ble-demuxers --enable-parsers --disable-programs --enable-protocol=file [22:23:31 CEST] <TheRock> that should give just a decoding ffmpeg, right? [23:03:57 CEST] <TheRock> which codec is required when an mp3 has an image? [23:04:41 CEST] <TheRock> i can play all mp3s, but some have an image and throw an error (decoding failed), but it still plays. [23:04:50 CEST] <TheRock> so what would i need to add to ./configure [00:00:00 CEST] --- Sat May 5 2018

1 0

ffmpeg-devel.log.20180503
by burek 04 May '18

04 May '18

[00:00:02 CEST] <cone-555> ffmpeg 03Paul B Mahol 07master:6d7c63588c81: avfilter/vf_overlay: add x86 SIMD [00:14:15 CEST] <cone-555> ffmpeg 03Paul B Mahol 07master:ab1114a0f5b3: avfilter/vf_convolution: rewrite so it doesn't use temp buffers [03:07:35 CEST] <kierank> ma [03:07:40 CEST] <kierank> bleh [03:11:35 CEST] <BBB> kierank: thank you for that link [03:11:41 CEST] <BBB> I can now live a happy, worry-free life [03:11:46 CEST] <kierank> BBB: ? [03:12:02 CEST] <kierank> the one with all the random guessing? [03:12:04 CEST] <BBB> I know that no matter what I do, all code I write in my life will not be the worst ever written [03:12:19 CEST] <BBB> even if I were a blind monkey typing drunk, it would be better than that [03:13:00 CEST] <kierank> trying to do anything with the mpeg4/h263 codebase is very difficult [03:25:04 CEST] <kierank> BBB: https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/h263dec.c;h=eae2… [03:25:06 CEST] <kierank> also that [03:27:26 CEST] <jamrial> it may be ugly, but it's probably parf of what made ffmpeg support all kinds of fucked up divx/xvid video back when those were everywhere [03:28:00 CEST] <kierank> sure, but could be documented [03:28:08 CEST] <kierank> e.g what file does it fix and why [03:31:58 CEST] <Compn> well it helps that divx was a hacked msmpeg4 asf codec [03:32:08 CEST] <Compn> and then b-frames were never meant to be put in .avi [03:32:32 CEST] <Compn> and then everyone including skal made his/her own mpeg4 codec :P [03:33:06 CEST] <Compn> so of course we supported playing back all of those codecs [03:52:20 CEST] <rcombs> xvid claims a patent on the packed b-frame technique [03:52:38 CEST] <rcombs> which is dumb because it has little technical value [03:52:48 CEST] <rcombs> if I'd invented that I sure wouldn't be publicly claiming credit for it [04:12:05 CEST] <BBB> oops ;)? [04:34:51 CEST] <Compn> i saw the oops :D [08:06:07 CEST] <cone-271> ffmpeg 03Rodger Combs 07master:6f119dc32176: lavf/dashenc: don't call flush_init_segment before avformat_write_header [08:06:07 CEST] <cone-271> ffmpeg 03Jan Ekström 07master:48684d26057a: lavf/dashenc: require experimental mode to be enabled for WebM [08:06:07 CEST] <cone-271> ffmpeg 03Jan Ekström 07master:bad42e9b4092: lavf/dashenc: pass standards compliance value to the internal context [09:26:04 CEST] <cone-271> ffmpeg 03Paul B Mahol 07master:0f0d468fbcf1: avfilter/vf_overlay: exclude nv12/nv21 formats from x86 asm check [10:06:42 CEST] <vishnu_nk> Hi Can anyone tell me of there is a way to change the program id of a TS file using ffmpeg? [10:13:42 CEST] <funman> [11:00:48 CEST] <BtbN> hm, nvidia sending in an entire a53 parser for cuviddec. That stuff is one of the primary reasons the nvdec hwaccel exists [11:06:21 CEST] <JEEB> lol [11:06:34 CEST] <JEEB> yea, that sounds like awful duplication of functionality [11:22:38 CEST] <durandal_1707> wm4: i gonna push improved y4m patch, if you do not mind [11:24:18 CEST] <JEEB> oh hey, we got a person who had actually utilized WebM with dashenc [11:24:25 CEST] <JEEB> so it might have not been crashing in 3.4 [11:24:39 CEST] <JEEB> I'm asking him if it gives him usable files with current master [11:24:51 CEST] <JEEB> if it does, then 48684d26057a can be reverted [11:34:06 CEST] <cone-271> ffmpeg 03Paul B Mahol 07master:3a96534ed9dd: avfilter/vf_convolution: add horizontal/row mode [11:34:07 CEST] <cone-271> ffmpeg 03Paul B Mahol 07master:c8c2fb097777: avfilter/vf_convolution: unbreak roberts filter [12:58:52 CEST] <cone-271> ffmpeg 03Paul B Mahol 07master:943f7902e6f7: avfilter/vf_neighbor: add >8 depth suppport [13:58:50 CEST] <moreentropy> hi. [13:59:15 CEST] <JEEB> ohai [13:59:24 CEST] <moreentropy> about the DASH bug: I just compiled & deployed ffmpeg master, at least my DASH/WebM/OPUS audio-only streams are working again [13:59:58 CEST] <moreentropy> Player: https://www.eldoradio.de/broadcast/player/ [14:00:01 CEST] <moreentropy> Manifest: http://sender.eldoradio.de/chunks/dash/eldoradio.mpd [14:01:26 CEST] <JEEB> if you get time, please test with some sort of small video stream with vp9/8 (vp9 was forcibly made non-webm by the akamai person some time ago because webm mode crashed) [14:01:42 CEST] <JEEB> like, you can just make a small video source based on the audio [14:01:49 CEST] <JEEB> durandal_1707 knows all about those filters [14:02:15 CEST] <JEEB> (also site:ffmpeg ffmpeg-all.html) [14:02:19 CEST] <JEEB> *site:ffmpeg.org [14:02:31 CEST] <moreentropy> ok, I can try that later today, that streaming server is not my day job ;) [14:02:50 CEST] <JEEB> that's OK, I have my $dayjob as well [14:05:47 CEST] <durandal_1707> there is no way to debug why vs plugin does not load? [14:28:50 CEST] <Compn> haha [14:28:54 CEST] <Compn> -c copy is the best :D [14:32:56 CEST] <cone-271> ffmpeg 03Paul B Mahol 07master:5abcf45d752d: avformat/yuv4mpegdec: simplify math [14:45:33 CEST] <durandal_1707> ubitux: the edgedetect filter, even links canny, but it is more toy filter [14:45:51 CEST] <durandal_1707> it supports only gray for some reason, the other mode is just toy [14:46:36 CEST] <ubitux> yeah well, edge detect concept in itself isn't really useful [14:46:45 CEST] <ubitux> as a building block for other filters it might make sense though [14:53:11 CEST] <durandal_1707> ubitux: yes, but edgedetect filter is really toy, you can not build useful mask with default mode [14:53:21 CEST] <ubitux> maybe [14:53:23 CEST] <ubitux> what's your point? [14:53:38 CEST] <durandal_1707> it should operate on all planes for start [14:53:43 CEST] <durandal_1707> not just gray [15:06:50 CEST] <durandal_1707> ubitux: i already wrote one patch for this [15:07:06 CEST] <ubitux> i don't plan to work on edgedetect so yeah, sure, feel free to contrib [15:07:29 CEST] <durandal_1707> also add planes option and more pixel format support [17:35:00 CEST] <wm4> BtbN: maybe we should just remove the old cuda decoder wrapper [17:35:43 CEST] <cone-271> ffmpeg 03Michael Niedermayer 07master:e03bf251d878: avcodec/mpeg4videodec: Move decode_studiovisualobject() parsing in the branch for visual object parsing [17:35:44 CEST] <cone-271> ffmpeg 03Michael Niedermayer 07master:177133a0f4b4: avcodec/mpeg4videodec: Split decode_studio_vol_header() out of decode_studiovisualobject() [18:12:57 CEST] <BtbN> wm4, it still has features that would be lacking if it's missing [18:13:09 CEST] <wm4> too bad for nvidia? [18:13:11 CEST] <BtbN> and it's also still faster than the nvdec one for decoding to software frames [18:13:14 CEST] <BtbN> by quite a bit [18:13:25 CEST] <wm4> at least they'll have an incentive to add support [18:13:35 CEST] <wm4> instead of using our project as code dump (and we maintain it then) [18:13:41 CEST] <BtbN> it's primarily deinterlacing [18:14:04 CEST] <BtbN> And the nvdec one needs some work to get rid of the useless extra copy it does when doing swdecode [18:45:31 CEST] <BtbN> Can there be more than one AV_FRAME_DATA_A53_CC? [18:45:58 CEST] <JEEB> I think someone made a commit that enabled that [18:46:13 CEST] <JEEB> with a function that gets the next side data of a specific type [18:47:25 CEST] <BtbN> Cause right now, the nvidia patch iterates over all side data, and uses the last one it finds [18:47:36 CEST] <BtbN> and I'm tempted to just add a break; so it uses the first, and probably only one [18:48:28 CEST] <BtbN> also, I wonder why they iterate over it manually. Isn't that what av_frame_get_side_data is for? [18:48:48 CEST] <BtbN> yes, it very much is. [18:51:02 CEST] <atomnuker> I think there's only one of a side data type allowed per frame [18:53:38 CEST] <JEEB> yes, currently I think explicitly or implicitly we limit it to one [18:54:07 CEST] <JEEB> and I seem to have lost the github URL to the fork that did the multiple thing [18:54:32 CEST] <BtbN> https://bpaste.net/show/e6e4b1df6e8e this should be reasonable though? Or am I missing something? [18:59:49 CEST] <atomnuker> yeah, looks fine [19:35:25 CEST] <kurosu> ubitux, (slowpoke) your simd stuff looks like lossless video left prediction, which is on 8b; still worth looking at? [19:38:52 CEST] <ubitux> kurosu: are you refering to my f(ABCD,BCDE)={A+B A+B+C A+B+C+D A+B+C+D+E} question? [19:49:25 CEST] <jamrial> [15:30:11 CEST] <BBB> I believe jamrial wrote the vp9 bsf [19:49:33 CEST] <jamrial> no, i didn't. elenril did [19:50:13 CEST] <jamrial> wm4 then enabled it for the decoder, in place of the parser [19:50:19 CEST] <jamrial> but in any case, the issue (if any) seems to be in either decode.c or pthread_frame.c [19:50:40 CEST] <wm4> uh we just did what Libav did [19:50:50 CEST] <wm4> (when they fixed the issue we fixed years ago in a different way) [19:50:55 CEST] <jamrial> the vp9 superframe split bsf is the only one that outputs more than one packet per input packet [19:51:26 CEST] <jamrial> something in the generic code doesn't play nice with that [19:51:27 CEST] <wm4> anyway I suspect there's something fishy going on but I haven't taken a close lok [19:51:30 CEST] <wm4> *look [19:51:57 CEST] <jamrial> every other decoder uses the null bsf (basically, nothing) and that's one packet in, one packet out [19:54:58 CEST] <wm4> sure [19:56:32 CEST] <atomnuker> wm4: you wanted to deprecate parsers in favor of bsfs, right? [19:56:47 CEST] <wm4> maybe [19:57:00 CEST] <wm4> the BSF API would have to get extended a bit [19:57:17 CEST] <wm4> but in theory it's what we want: N packets in, M packets out [20:03:02 CEST] <BBB> why? [20:03:14 CEST] <BBB> whats the advantage (in a push mechanism) between 1:M and N:M? [20:03:31 CEST] <JEEB> -34 [20:04:03 CEST] <wm4> BBB: parsers often reassemble packets, so we definitely need it for data flow [20:04:11 CEST] <wm4> some input packets are just random byte ranges [20:04:45 CEST] <BBB> and a bytes_consumed + sub-packeting mechanism isnt sufficient for that? [20:04:47 CEST] <wm4> parsers are for retrieving codec information, but also for assembling proper packets in some cases [20:04:51 CEST] <jamrial> then make parsers stop splitting packets, and leave that task fr bsfs [20:04:59 CEST] <wm4> BBB: that'd also be possible [20:05:12 CEST] <wm4> BBB: then the input would be an AVBufferRef [20:05:17 CEST] <BBB> yes [20:05:20 CEST] <wm4> but then some parsers need input timestamps [20:05:31 CEST] <wm4> (the parser API passes them separately) [20:05:36 CEST] <wm4> so why not just use AVPacket [20:06:05 CEST] <wm4> also other metadata like side data, packet duration, or packet positions [20:06:19 CEST] <wm4> many parsers just pass through packets while "analyzing" them in the first place [20:10:37 CEST] <durandal_1707> ubitux: i sent patch for lut3d too [20:15:06 CEST] <wm4> gawd pages of code that are a single macro [20:35:20 CEST] <durandal_1707> wm4: you use 80x25 ? [20:56:02 CEST] <durandal_1707> becuase there is barely half page of macros [21:58:57 CEST] <cone-506> ffmpeg 03Paul B Mahol 07master:f43fd68f2807: avfilter/drawutils: add support for full range [00:00:00 CEST] --- Fri May 4 2018

1 0

ffmpeg.log.20180503
by burek 04 May '18

04 May '18

[00:59:30 CEST] <LiedFrice> Does anyone know if ffplay supports full 360 video playback yet? So that one could preview how well sources are being stitched together and such; without having to upload to a service to preview first [01:00:57 CEST] <JEEB> ffplay is a PoC (Proof of Concept). do not expect it to be a proper player. do note that most likely if you make your manual filter chain you'll be able to play it if libavfilter supports 360 mappings [01:05:55 CEST] <LiedFrice> I figured as much, I still prefer it to most media players still haha. I'm not certain if libavfilters supports it yet. But if so there's hope I suppose :D [01:06:29 CEST] <LiedFrice> I love ffplay for its ability to accept piped data versus other media players, too [01:08:14 CEST] <furq> mpv does that fine [01:10:23 CEST] <LiedFrice> Didn't know mpv could, thx [01:14:15 CEST] <LiedFrice> I doubt this is what I want but I found this interesting. https://github.com/facebook/transform360/blob/master/README.md [01:14:22 CEST] <LiedFrice> Thanks Facebook [01:17:44 CEST] <poutine> Is there a way using ffmpeg/ffprobe to get PCR frequency out of a file at rest? [01:18:35 CEST] <poutine> .ts file [01:18:38 CEST] <poutine> oops [01:19:51 CEST] <poutine> we have some automated system complaining about PCR frequency in our mpegts video stream, and I've looked at tstools (both the project with the GUI windows graphing thing, and a loose collection of utilities found on github), and while I do get data out of it, it's not as simple as "PCR packet every 100ms" [01:28:53 CEST] <Soni> how do I turn /dev/urandom into brown noise? [01:29:21 CEST] <Soni> cat /dev/urandom | ffmpeg [???] [01:59:15 CEST] <Soni> and then someone gives me this: `mpv --lavfi-complex='anoisesrc=c=brown [l] ; anoisesrc=c=brown [r] ; [l] [r] amerge [ao]' null://` [01:59:25 CEST] <Soni> I have no idea what I'm looking at [02:06:47 CEST] <TheAMM> It creates two sources of brown noise, merges them into a stereo track and opens a null input (since the audio is generated, and not read from a file) [03:55:29 CEST] <garoto> this is a lazy question and i'm sorry, but what are my options for quality control (bitrate wise) when using "h264_nvenc"? [03:57:09 CEST] <garoto> (lost my cmd .history file with ~2yrs worth of cli stuff) [09:37:49 CEST] <greves> Hello, (hopefully) quick question, I am using the following command which works fine to convert a 1080p video to 720p, but it doesn't work for 480p: [09:38:03 CEST] <greves> ffmpeg -i teaser_raw.mp4 -vf scale=-1:720 -c:v libx264 -crf 24 -preset veryslow -c:a copy teaser_720p_24.mp4 [09:38:23 CEST] <greves> Changing scale to -1:480, I get the following error: [libx264 @ 0x2c9fec0] width not divisible by 2 (853x480) [09:38:27 CEST] <greves> Should I manually set the width? [09:39:59 CEST] <jkqxz> Use "-2:480" instead. [09:40:06 CEST] <greves> What does -2 do? [09:41:25 CEST] <jkqxz> Ensures that the output is divisible by 2. [09:42:01 CEST] <greves> Ah great, thank you :) [09:54:14 CEST] <vishnu_nk> Is there any way to change the program id of a TS stream using ffmpeg? [09:54:21 CEST] <vishnu_nk> Can anyone help with this? [10:14:21 CEST] <durandal_1707> not possible [11:10:40 CEST] <moreentropy> hi [11:10:57 CEST] <moreentropy> i'm wondering a bit about 48684d26057ad830f522fc94d073a26067b49e6f [11:11:38 CEST] <moreentropy> i've been using WebM in DASH with 3.4 for a few months now, the commit states that it "has not ever been working" [11:12:12 CEST] <JEEB> well at least it was crashing until now [11:12:23 CEST] <JEEB> it could have been broken post-3.4 [11:12:32 CEST] <JEEB> but it was definitely segfaulting and nobody seemed to have used it [11:12:44 CEST] <moreentropy> yes, it crashes in 4.0 only [11:12:46 CEST] <JEEB> and since nobody had reported the breakage for months [11:13:24 CEST] <JEEB> if you -strict experimental does it work for you in a browser etc as well as before? [11:13:35 CEST] <JEEB> also heh, I guess that akamai dude didn't back-port the fix to 4.0 [11:13:45 CEST] <moreentropy> ok, well I've been (experimentally) using it w/ 3.x for a few months [11:13:57 CEST] <JEEB> according to the original author from Libav it was tested at some point [11:14:07 CEST] <moreentropy> doesn't work in a browser right now because it instantly crashes in 4.0 [11:14:30 CEST] <JEEB> well, the crash is already fixed and the crash fix could be back-ported rather easily into the 4.0 branch [11:14:47 CEST] <JEEB> please try with master and help us verify it. I tried with dash.js I think [11:15:04 CEST] <JEEB> and IIRC I didn't get it working, although that could've been due to some other reasons [11:15:16 CEST] <moreentropy> the other commit bad42e9b40920f079b27e5bd4103d9293046b2ed is great, I wanted to submit a similar patch, with ctx->strict_std_compliance = s->strict_std_compliance [11:15:26 CEST] <moreentropy> I'll do that! [11:16:06 CEST] <JEEB> I will probably add a new thing that lets you pick the format [11:16:11 CEST] <moreentropy> I'm also experimenting with flac in dash/mp4, works fine but has an issue with the dash manifest (will submit a but for it) [11:16:14 CEST] <JEEB> since right now you can't get WebM with VP9 for example [11:16:31 CEST] <JEEB> since the akamai dude "changed the default" [11:16:39 CEST] <JEEB> at which I yelled a bit on the internet [11:16:46 CEST] <JEEB> because defaults mean there are alternatives [11:16:52 CEST] <JEEB> while in this case it just switched the container [11:23:09 CEST] <JEEB> moreentropy: feel free to join the -devel channel and share your results there [11:23:39 CEST] <JEEB> as you get them, that is [11:25:43 CEST] <moreentropy> JEEB: will do, thanks. building right now.. [11:27:27 CEST] <JEEB> I guess "working" would be chromium and firefox at the very least [11:27:36 CEST] <JEEB> so if the WebM output works on those, we can consider it OK [11:28:00 CEST] <JEEB> (you might have to revert the VP9 change to get WebM for it) [11:34:20 CEST] <moreentropy> I'm using audio only for DASH streams at a radio station, so didn't try / not affected by VP9 in WebM problems [11:34:51 CEST] <JEEB> ah [11:35:04 CEST] <JEEB> well, still - we found a user \o/ [11:35:05 CEST] <moreentropy> tested with chrome desktop and mobile, firefox, edge [11:35:11 CEST] <moreentropy> works in all three [11:35:51 CEST] <JEEB> ok, can you test with vp9 and vp8 video? I think vp9 now should write the profile string in the manifest so the manifest side should work in chromium and firefox [11:35:55 CEST] <JEEB> (and probably edge) [11:35:59 CEST] <moreentropy> haha. yeah i'm experimenting a lot with chunked streaming, our default live streams to the browser are progressive download / icecast right now and i want to change that [11:36:00 CEST] <JEEB> but if they support WebM at all [11:36:27 CEST] <moreentropy> yes, can try that later today [11:36:33 CEST] <JEEB> yea, to be honest I prefer long connections for streaming but browsers can't do that without extra complexity [11:36:51 CEST] <JEEB> which is why web people mumble about websockets etc [11:38:13 CEST] <moreentropy> we had a lot of trouble with antivirus that tried to intercept, download and scan the streams before giving data to the browser [11:38:24 CEST] <moreentropy> switching to HTTPS made that go away [11:38:34 CEST] <JEEB> lol [11:40:10 CEST] <moreentropy> DASH seems really solid, streams start instantly, the client can decide how close to the live edge it will go (afaik). tried listening to a DASH/WebM/OPUS stream with three qualities during a 40 minute commute to work w/ mediaelemend.js on chrome on android [11:40:40 CEST] <moreentropy> the stream switched qualities multiple times and i had a short data outage, live stream continued a the live edge when data came back [11:41:55 CEST] <moreentropy> but I have to resample (async=1) the alsa input, else the stream will slowly drift over days and will not start instantly in the browser because timestamps don't match (???) [11:43:47 CEST] <moreentropy> with flac in dash/mp4 the manifest says codecs="fLaC" which the browser doesn't accept, I filtered fLaC -> flac in Nginx, now it works flawlessly. will open a trac for it [11:49:15 CEST] <JEEB> ok, also try poking the webm mode for it (I don't think it's set to get WebM by default) [11:56:10 CEST] <moreentropy> yeah afaik flac/mp4 is defined somehow while flac/webm is not (??), but I really don't know the details. [11:57:04 CEST] <moreentropy> basically this works with ffmpeg https://www.bbc.co.uk/rd/blog/2017-04-radio-3-high-quality-flac-dash [11:57:40 CEST] <moreentropy> experimental live stream w/ ffmpeg: https://www.eldoradio.de/broadcast/flac/ [12:22:54 CEST] <JEEB> moreentropy: flac/webm is just matroska. same as opus [12:23:09 CEST] <JEEB> so in theory it should be even more defined than ISOBMFF ;) [13:33:47 CEST] <dsi> Hi everyone, I am having some trouble getting the dev packages for FFMPEG libraries such as libavcodec on a Debian 9 (Stretch). When I use aptitude or apt-get, I get an "unmet dependencies" error [13:34:39 CEST] <dsi> For example, for libavcodec-dev, I get "libswresample-dev : Depends: libswresample2 (= 7:3.2.9-1~deb9u1) but 7:3.2.10-1~deb9u1 is installed" .... I have all the runtime libraries [13:37:05 CEST] <Blacker47> dsi, is more a debian-related question. also it should depend on the .10-1.. version like here (tested). so you may need to update your sources first (e.g. apt-get update) or check if you have right sources enabled. [13:42:09 CEST] <dsi> blacker47: Thanks, I will try that out. [15:53:09 CEST] <arinov> guys [15:53:14 CEST] <arinov> ffmpeg -framerate 30 -f x11grab -i 0 test.flv [15:53:17 CEST] <arinov> does not work [15:53:24 CEST] <arinov> [x11grab @ 0x55cf3ca087c0] Cannot open display 0, error 5. [15:53:27 CEST] <arinov> 0: Input/output error [15:53:33 CEST] <arinov> i have 3 displays here [15:53:44 CEST] <arinov> trying to record from one of them [15:53:59 CEST] <atomnuker> use kmsgrab if you can, its faster [15:54:24 CEST] <atomnuker> you need either vaapi support or opencl [15:54:38 CEST] <arinov> nknown input format: 'kmsgrab' [15:54:47 CEST] <arinov> i am on fedora 27 [15:54:54 CEST] <arinov> ffmpeg from rpmfusion [15:55:38 CEST] <JEEB> x11grab probably won't work with wayland :) [15:55:48 CEST] <JEEB> and for kmsgrab you then need to build yer own FFmpeg [15:55:58 CEST] Action: JEEB actually likes Fedora because standard repositories come without FFmpeg et al [15:57:01 CEST] <arinov> i am sure i am on X (configured GDM) [15:57:39 CEST] <debianuser> arinov: `-i :0` maybe? [15:57:46 CEST] <arinov> WaylandEnable=false in gdm custom.conf [15:58:00 CEST] <debianuser> arinov: echo $DISPLAY [15:58:18 CEST] <arinov> debianuser: works [15:58:20 CEST] <arinov> :1 [15:58:21 CEST] <arinov> thanks [15:58:46 CEST] <arinov> lol [15:58:58 CEST] <arinov> it writes the left screen (part of it) [15:59:19 CEST] <arinov> it seems i have on big screen here in gnome [16:01:08 CEST] <JEEB> arinov: the Xorg GNOME shell is an option in the graphical interface of gdm anyways, so in theory you don't need to poke at config files [16:13:15 CEST] <arinov> $ ffmpeg -video_size 1920x1080 -framerate 30 -f x11grab -i :1+1080,0 test.flv [16:13:17 CEST] <arinov> perfect [16:14:19 CEST] <arinov> left & right screens are in vertical orientation, central in horizontal [16:14:36 CEST] <arinov> making screencast from central with this options [16:38:29 CEST] <easy_ref123> can't find a description of the -b flag in the manpage [16:38:33 CEST] <easy_ref123> somebody? [16:39:17 CEST] <crypttab> easy_ref123: it's the bitrate in kbits/s [16:40:52 CEST] <TheAMM> Bits, not kbits [16:42:27 CEST] <TheAMM> It's also technically unique per-encoder, not a global option, but pretty much all encoders have a -b option to set a bitrate in bits/s [16:44:19 CEST] <crypttab> TheAMM: true, thanks [16:45:20 CEST] <furq> easy_ref123: https://www.ffmpeg.org/ffmpeg-codecs.html#Codec-Options [16:58:41 CEST] <JEEB> TheAMM: there are options in the AVCodecContext, and those are global [16:58:50 CEST] <JEEB> the bit rate thing is in AVCodecContext [16:58:58 CEST] <JEEB> so it 100% bases on if the encoder reads it or not [16:59:04 CEST] <JEEB> instead of "is it there or not" [16:59:30 CEST] Action: TheAMM shrugs [16:59:41 CEST] <TheAMM> I can't find -b on the general options manpage [16:59:47 CEST] <TheAMM> Only on codecs [17:00:37 CEST] <DrLuke> Hello, where can I read how the pixel data in AVFrame is structured? I'm asking because I'm converting to RGB24 and I am wondering if it gives me the data in 3 seperate arrays for each channel or just one [17:02:33 CEST] <atomnuker> no, RGB24 is interleaved packed RGB, so everything is in AVFrame->data[0] [17:05:24 CEST] <DrLuke> atomnuker: so it's [R G B R G B ...] ? [17:05:45 CEST] <DrLuke> That's actually exactly what I need :D [17:06:39 CEST] <DrLuke> Thank you :) [17:10:10 CEST] <atomnuker> each pixfmt has a comment describing its layout in libavutil/pixfmt.h [17:10:26 CEST] <atomnuker> planar ones have their samples spread out in each data[] plane of the avframe [17:12:30 CEST] <DrLuke> Nice, thanks again :) [17:13:36 CEST] <DrLuke> Oh nice, there's a format containing a vdpau surface [17:44:29 CEST] <atbd> hi, is it possible to read an input video/audio from stdin with avformat_open_input? [17:50:42 CEST] <klaxa> yes [17:50:43 CEST] <klaxa> one sec [17:51:31 CEST] <klaxa> use "pipe:0" as filename [17:52:03 CEST] <klaxa> so: avformat_open_input(&fmt_ctx, "pipe:0", NULL, NULL); [17:58:44 CEST] <atbd> thanks a lot ! [18:15:06 CEST] <GIFGuy> Hey there! So I'm trying to losslessly convert 2 GIFs but unsure what command do I use? [18:15:22 CEST] <GIFGuy> They're both in the same folder, if that matters [18:31:17 CEST] <wfbarksdale> I am writing a demuxer, and I am observing the interleaving of audio / video packets. ignorning b frames, I was wondering, is it pretty much always the case that you have some video packets beginning with a pts of x, then some audio frames beginning with a pts < x? [18:31:46 CEST] <wfbarksdale> Is this a convention or a spec for the mp4 container [18:35:55 CEST] <ritsuka> it depends, I think some muxers put audio before video, if the audio track comes before the video track [18:39:03 CEST] <zerodefect> The other thing that can have an affect is the internal delay within the various encoders. [18:57:38 CEST] <GIFGuy> Hey there! So I'm trying to losslessly convert 2 GIFs but unsure what command do I use? [18:57:41 CEST] <GIFGuy> They're both in the same folder, if that matters [19:02:59 CEST] <oerg866> GIFGuy: what are you trying to convert them to? [19:09:28 CEST] <GIFGuy> oerg866: Nah I wanna keep em as GIFs as they are [19:09:39 CEST] <GIFGuy> Like not convert,more like combine [19:09:52 CEST] <GIFGuy> Like combine them into one file [19:10:13 CEST] <oerg866> https://trac.ffmpeg.org/wiki/Concatenate [19:14:07 CEST] <GifGuy2> oerg866: I looked at that page but I don't understnad [19:14:12 CEST] <GifGuy2> It's kinda confusing [19:16:39 CEST] <oerg866> Gifguy2: make a file in that folder called list.txt [19:16:43 CEST] <oerg866> write this to it: [19:16:54 CEST] <oerg866> file 'C:\whatever\file1.gif' [19:16:55 CEST] <oerg866> file 'C:\whatever\file2.gif' [19:16:59 CEST] <oerg866> save it [19:17:04 CEST] <GifGuy2> done [19:17:14 CEST] <oerg866> ffmpeg -f concat -safe 0 -i list.txt -c copy output.gif [19:17:20 CEST] <GifGuy2> Thanks! [19:20:11 CEST] <GifGuy2> oerg866: Gives me an error [19:20:33 CEST] <GifGuy2> Assertion video_par->format == AV_PIX_FMT_PAL8 failed at src/libavformat/gif.c:130 [21:46:45 CEST] <oerg866> <GifGuy2> Assertion video_par->format == AV_PIX_FMT_PAL8 failed at src/libavformat/gif.c:130 <-- that's probably something a dev should look at [21:49:14 CEST] <durandal_1707> oerg866: how to reproduce that? [21:51:16 CEST] <oerg866> the guy asked how to join two gif files [21:51:18 CEST] <oerg866> i said concat demuxer [21:51:20 CEST] <oerg866> <oerg866> ffmpeg -f concat -safe 0 -i list.txt -c copy output.gif [21:52:37 CEST] <durandal_1707> nope, use concat filter [21:55:50 CEST] <oerg866> but concat filter re-encodes, no? [21:55:53 CEST] <oerg866> he asked how to join [21:55:56 CEST] <oerg866> losslesslz [21:56:00 CEST] <oerg866> *losslessly [21:57:25 CEST] <durandal_1707> oerg866: thing is muxer supports only basic single image gifs [22:02:59 CEST] <oerg866> ahhhh [22:03:01 CEST] <oerg866> okay that makes sense tehn [22:06:35 CEST] <oerg866> hmm but now that i think about it [22:06:41 CEST] <oerg866> gif to gif encoding should always be lossless [22:06:48 CEST] <oerg866> since gifs have fixed limitations [22:07:10 CEST] <oerg866> if you decimate 256 colors to 256 colors idally it should yield the same 256 colors ^^ [22:07:56 CEST] <durandal_1707> yes [00:00:00 CEST] --- Fri May 4 2018

1 0

ffmpeg-devel.log.20180502
by burek 03 May '18

03 May '18

[00:00:02 CEST] <atomnuker> Gramner: ah, forgot the offset was barely one byte [00:00:03 CEST] <exastiken_> instead it comes from 2 sources [00:00:50 CEST] <Gramner> there's two offset types: 1 byte and 4 bytes. obviously you want the majority to use 1 byte [00:01:20 CEST] <exastiken_> can someone explain how do_encode's function run is so small but motion_estimate ends up so big? [00:01:30 CEST] <Gramner> which works really well in evex compressed displacements since almost all offsets are a multiple of the load/store size [00:03:10 CEST] <jamrial> TD-Linux: the most used display resolution being 1366x768 and the massive intel lead on gpu kinda hints this survey was done mostly on net/notebook :p [00:03:21 CEST] <nevcairiel> TD-Linux: i think a browser survey is probably far more impacted by laptops then a gaming centric survey, but yeah [00:04:04 CEST] <atomnuker> Gramner: so above 256 you need to have your offset aligned to nearest multiple of 4? [00:04:10 CEST] <nevcairiel> (the Browsers by Architecture graph looks funny) [00:04:13 CEST] <jamrial> and the gpu model graph tells you what instruction sets are available, because most of those gpus are intel igp [00:04:36 CEST] <Gramner> atomnuker: no, the 4-byte offset uses bytes. so anything within +-2GiB [00:05:11 CEST] <Gramner> onkly the one-bte offset has to be a multiple (which is true in the majority of cases, so saves space on average) [00:06:48 CEST] <Gramner> e.g. mova zmm0, [src+256] would be encoded as imm8 0x04 [00:08:58 CEST] <Gramner> so for 64-byte memory args you can have +-8 KiB offsets encoded in one byte as long as it's a multiple of 64 [00:09:31 CEST] <atomnuker> how is the type signalled? [00:10:24 CEST] <nevcairiel> its the size of the register, zmm is 64 byte [00:11:15 CEST] <Gramner> not strictly register size. e.g. vpbroadcastd will use multiples of 4 [00:11:28 CEST] <Gramner> it's basically the "memory access size" [00:43:10 CEST] <cone-597> ffmpeg 03Mark Thompson 07master:d7786b66bdd4: cbs: Fragment/unit data is always reference counted [00:43:10 CEST] <cone-597> ffmpeg 03Mark Thompson 07master:315cc8c0988d: cbs_h2645: Simplify representation of fixed values [00:57:15 CEST] <exastiken_> How do I compile ffmpeg with debugging options visible to callgrind? [00:58:33 CEST] <BtbN> Use the _g executable. [01:00:36 CEST] <jamrial> by default it compiles with -g, but if you need a specific debug level (-g3 or -ggdb) use --enable-debug=$level [01:12:07 CEST] <exastiken_> BtbN: I tried it with _g but it's telling me that No debug information is present, recompile source and redo the profile run. The function is located is located in this ELF object: 'ffmpeg_g' [01:13:15 CEST] <exastiken_> jamrial: I'm already using --enable-debug=3 [01:13:48 CEST] <exastiken_> my full configure is [01:13:50 CEST] <exastiken_> ./configure \ --prefix="$HOME/ffmpeg_build" \ --pkg-config-flags="--static" \ --extra-cflags="-I$HOME/ffmpeg_build/include -g" \ --extra-ldflags="-L$HOME/ffmpeg_build/lib" \ --extra-libs="-lpthread -lm" \ --bindir="$HOME/bin" \ --enable-debug=3 \ --extra-cflags="-gstabs+ -g" \ --enable-gpl \ --valgrind=valgrind \ --disable-optimizations \ --disable-stripping \ --enable-extra-warnings \ --enable-li [01:14:18 CEST] <exastiken_> --enable-libfreetype \ --enable-libmp3lame \ --enable-libopus \ --enable-libtheora \ --enable-libvorbis \ --enable-libvpx \ --enable-libx264 \ --enable-libx265 \ --enable-nonfree [01:22:27 CEST] <iive> don't paste huge things in irc, use pastebin site [01:22:55 CEST] <iive> and compilation related question are more on topic in #ffmpeg. [01:23:24 CEST] <nevcairiel> you seemed to be itnerested in analyzing x265 earlier anyway, you should probably analyze x265 directly and n ot through ffmpeg then [01:59:22 CEST] <Gramner> apparently github were storing passwords in plaintext in log files that got exposed, nice [02:07:21 CEST] <jamrial> user account passwords? [02:07:43 CEST] <Gramner> yes [02:07:52 CEST] <Gramner> they sent me an email about it [02:08:48 CEST] <klaxa> why would they have them in the first place? [02:08:57 CEST] <Gramner> "[...] a recently introduced bug exposed a small number of users passwords [...]" [02:09:04 CEST] <nevcairiel> only affects those that changed them recently, otherwise they wouldnt have gone into logs [02:09:50 CEST] <klaxa> ah hmm i guess when you enter them in the site, they hash them when they receive it [02:10:22 CEST] <nevcairiel> and the logs only possibly got "exposed" to their own employees, and even there are probably strict limits who can view them [02:10:26 CEST] <atomnuker> btw here's the latest isobmff av1 spec if anyone's interested or has any comments [02:10:27 CEST] <atomnuker> https://aomediacodec.github.io/av1-isobmff/ [02:10:32 CEST] <nevcairiel> still not nice, but better then other things that happened [02:10:40 CEST] <klaxa> yeah [02:11:43 CEST] <atomnuker> jamrial / jkqxz ^^ [02:32:53 CEST] <cone-597> ffmpeg 03Mark Thompson 07master:300ef253141f: cbs: Add support for array subscripts in trace output [02:32:54 CEST] <cone-597> ffmpeg 03Mark Thompson 07master:b5df289eb771: lavc: Add coded bitstream read/write support for VP9 [02:32:55 CEST] <cone-597> ffmpeg 03Mark Thompson 07master:308b989e0cf1: lavc: Add VP9 metadata bitstream filter [02:32:56 CEST] <cone-597> ffmpeg 03Mark Thompson 07master:ddd3a209dc5a: lavc/cbs: Add tests for VP9 [02:32:57 CEST] <cone-597> ffmpeg 03Mark Thompson 07master:e07b1913fc67: fate/cbs: Always overwrite output in cbs fate tests [02:40:16 CEST] <wm4> wow the internal mpeg encoder could use libxvid's rate control? [02:42:30 CEST] <atomnuker> yeah [02:44:47 CEST] <wm4> that's so fucked up [02:54:07 CEST] <atomnuker> indeed, it was only working for 2pass [05:11:59 CEST] <wm4> jamrial: aprtopos vp9, seems like there might be a problem with BSF dataflow in avcodec: https://github.com/FFMS/ffms2/pull/323#discussion_r185303842 [05:12:05 CEST] <wm4> *apropos [05:13:26 CEST] <wm4> haven't looked closer at it, so I'm not sure if it's really a bug [05:14:51 CEST] <jamrial> i don't see bsf usage in that repro program [05:15:21 CEST] <jamrial> unless this is related to the superframe split bsf autoinserted by the decoder? [05:16:43 CEST] <wm4> it is [05:16:47 CEST] <wm4> because this uses vp9 [05:17:02 CEST] <wm4> I wonder if it's just a file with broken muxing [05:17:20 CEST] <wm4> but if enabling frame threading changes it... [05:19:57 CEST] <jamrial> this bsf was written by elenril, but he's kinda awol... [05:21:28 CEST] <jamrial> maybe ask BBB to look at it. he understands the vp9 bitstream better [05:37:25 CEST] <TD-Linux> I think the API requires you to loop until you get no more frames out [05:37:59 CEST] <wm4> if the file is correctly muxed that shouldn't happen [05:38:34 CEST] <wm4> the thing with ffms2 is that it tries to create a perfect packet->frame index [05:40:55 CEST] <TD-Linux> yeah I guess the ffmpeg docs say you don't have to pull all frames out [05:40:56 CEST] <TD-Linux> >For example, you can call avcodec_send_packet() repeatedly without calling avcodec_receive_frame(). [05:41:08 CEST] <TD-Linux> so it's a bug (unless he's getting EAGAIN from avcodec_send_packet) [05:42:45 CEST] <wm4> yeah if there's still a frame to output, and avcodec_send_packet is called, it should return EAGAIN [08:17:24 CEST] <ubitux> i have 2 4x32-bit regs such that v0=ABCD and v1=BCDE, and i want v2={A+B A+B+C A+B+C+D A+B+C+D+E} [08:17:34 CEST] <ubitux> is there an usual pattern to deal with this? [09:10:33 CEST] <cone-762> ffmpeg 03Tobias Rapp 07master:a150b2e3a099: fftools/ffmpeg: properly initialize output stream field order [09:47:22 CEST] <durandal_1707> if we would add support for all color properties negotiation, how it should be done? [12:03:46 CEST] <Chloe> lol. I thought I was bad for replying to a thread which was from 2017 then durandal_1707 replies to one from 2016 :d [12:05:00 CEST] <Chloe> durandal_1707: will you push '[PATCH] avcodec: remove duplicate prores decoder'? [12:08:06 CEST] <durandal_1707> Chloe: i pushed that ages ago [12:09:00 CEST] <Chloe> durandal_1707: ah, missed it. I'm not currently tracking master and you didnt say it was pushed on the ML [12:25:38 CEST] <jdarnley> Oh wow. ffmpeg did get rtp-vc2 added by someone. [12:26:10 CEST] <jdarnley> How do I make ffplay play an rtp stream? [12:35:56 CEST] <durandal_1707> can i get review for overlay simd patch? [12:36:14 CEST] <funman> jdarnley: i think you need an sdp [12:36:48 CEST] <funman> then should be ffplay foo.sdp iirc [12:38:35 CEST] <jdarnley> lol it guessed it as some sort of ausio [12:38:38 CEST] <jdarnley> *audio [12:47:28 CEST] <jdarnley> Oh whoops. That is only for encoding. [12:47:29 CEST] <jdarnley> FUCK! [12:48:03 CEST] <jdarnley> wait, I see a "dec" file [12:48:43 CEST] <jdarnley> Oh yes, that was the encoder commit. [13:10:50 CEST] <jdarnley> This sdp thing is garbage. Do I really have to read a couple of RFCs to create one? [13:11:31 CEST] <nevcairiel> if you dont know how, then you need to read something that tells you how to do it, does that seem so unusual? :p [13:12:34 CEST] <jdarnley> Reading 1 sure but this one references several others including a "changes from" section. [13:13:11 CEST] <jdarnley> Why can't I just use ffmpeg's or ffplay [13:13:18 CEST] <jdarnley> 's usual options for this? [13:13:34 CEST] <nevcairiel> you can also just specify a rtp url for opening [13:13:44 CEST] <nevcairiel> but without sdp its usually a bit unreliable, in my experience [13:19:22 CEST] <jdarnley> Now I would need to understand what "nettype" and "addrtype" are if basic ipv4 wasn't shown. [13:24:26 CEST] <jdarnley> Fucking whitelist shit! [13:24:55 CEST] <JEEB> oh right, ffplay has a weird list of "live" protocols :D [13:25:00 CEST] <JEEB> I felt that was weird as heck [13:27:41 CEST] <jdarnley> "Invalid return value 0 for stream protocol" [13:27:50 CEST] <jdarnley> such a useful message [13:28:46 CEST] <JEEB> ah yes, the EOF != zero [13:28:46 CEST] <JEEB> thing [13:28:55 CEST] Action: JEEB pats jdarnley [13:42:09 CEST] <jdarnley> > "seascape" (upside-down landscape) [13:42:10 CEST] <jdarnley> heh [13:45:09 CEST] <atomnuker> durandal_1707: probably a structure instead of a single array of color ranges [13:45:23 CEST] <atomnuker> actually an array of structs [13:45:47 CEST] <atomnuker> each defining a single acceptable input [13:46:18 CEST] <atomnuker> so it would contain pixfmt, colorspace, color range, transfer functions [13:46:55 CEST] <atomnuker> and each of those would need to get negotiated separately [13:47:24 CEST] <atomnuker> I'm not sure if that's really the correct solution though [13:47:54 CEST] <atomnuker> because most codecs don't care at all about anything but pixfmt [13:49:04 CEST] <atomnuker> it'll be the most correct solution for filters though [13:51:42 CEST] <durandal_1707> current state is just broken [13:52:19 CEST] <JEEB> it's so broken that most likely when we fix it it will just break some use cases that people *thought* were working :D [13:52:28 CEST] <JEEB> (but weren't in reality) [13:53:10 CEST] <nevcairiel> the current state isnt quite broken, just ignorant of such things [13:53:26 CEST] <JEEB> yes, you could put it like that :) [13:53:42 CEST] <nevcairiel> and personally, i would say thats how its best, because all the combinations go into infinite complexity [13:54:05 CEST] <nevcairiel> but of course users are generally morons and would never bother to make sure colors are correct on their own, and instead yell at us :p [13:54:20 CEST] <durandal_1707> so you want to keep J? [13:56:44 CEST] <nevcairiel> no, i would just remove them without replacement and let users figure it out themselves [13:58:35 CEST] <nevcairiel> for range negotiation might be straight forward, sure, but if you go to the other properties like colorspace, then negotiation and conversion becomes a nightmare, and personalyl I would never want my colorspace to be auto-converted [14:00:35 CEST] <nevcairiel> because speifically compressing colorspace is a lossy operation [14:00:40 CEST] <nevcairiel> specifically* [14:04:19 CEST] <JEEB> yup [14:04:33 CEST] <JEEB> requiring user to be more explicit is good the more correctly you start doing stuff [14:07:24 CEST] <durandal_1707> that's what i'm trying to do, remove J [14:07:54 CEST] <durandal_1707> if there are no more comments for overlay simd i gonna apply it! [14:35:09 CEST] <durandal_1707> wm4: have you tried that y4m thing? [15:25:39 CEST] <BBB> atomnuker: the problem of that approach might be that we get chain-conversions with each filter [15:26:18 CEST] <BBB> atomnuker: imagine that your in/out is bt2020 10bit (full-range), and the first filter supports 8bit rgb and the second only bt709 limited-range yuv 8bit [15:26:34 CEST] <BBB> atomnuker: and I havent talked about transfer functions or primaries yet [15:27:12 CEST] <BBB> I think the most important thing (since thats how most filters will work) is to make it default and VERY easy for filters to say I dont care and just proxy my input frame fields to the output) [15:27:23 CEST] <BBB> e.g. if input is bt709, then output is bt709 etc. [15:27:48 CEST] <BBB> I think if we do that for all fields, well fix 90% of the use cases already [15:28:05 CEST] <BBB> second thing is to make sure all filters support 10bit, which is admittedly orthogonal to this, but still [15:28:28 CEST] <atomnuker> yeah, that'd be alright, most filters don't care about primaries or color ranges [15:28:37 CEST] <atomnuker> just about pixfmts [15:28:41 CEST] <BBB> for the few cases where the filter does care about what type of stuff is in the frame, or where in/out is different (e.g. converting bt2020 av1 to vp8), auto-insertion of converion would be nice, yes [15:29:00 CEST] <atomnuker> btw there seems to be a bug with the vp9 bsf [15:29:02 CEST] <atomnuker> https://github.com/FFMS/ffms2/pull/323#discussion_r185303842 [15:29:09 CEST] <BBB> and then we need to think of how that auto-inserted conversion filter is implemented, because vittorio is right that swscale is a piece of crap [15:30:10 CEST] <Chloe> imagine that your in/out is bt2020 10bit (full-range), and the first filter supports 8bit rgb and the second only bt709 limited-range yuv 8bit this sounds fun, i can imagine people would also want to know if they were losing quality by not all filters supporting their input [15:30:11 CEST] <BBB> I believe jamrial wrote the vp9 bsf [15:30:14 CEST] <BBB> I just wrote the decoder [15:30:23 CEST] <BBB> Chloe: right [15:30:33 CEST] <nevcairiel> atomnuker: there is no issue, someone just didnt read the api docs on how to handle the api [15:30:35 CEST] <BBB> Chloe: at the very least auto-inserted filters should be very clearly logged [15:31:16 CEST] <BBB> Chloe: the worst thing that could happpen is that stuff like that silently works and people start saying crap like ffmpeg quality is actually kind of shitty lately :(" [15:34:41 CEST] <atomnuker> well it would be easy to make the filters not care currently, because that's what they do, except for yuvj [15:37:34 CEST] <durandal_1707> f* i will committ all my patches! [15:38:05 CEST] <JEEB> you are clearly frustrated. sit down and let's talk about what is disturbing your peace of mind? [16:04:25 CEST] <durandal_1707> jamrial: have new comments for overlay patch? [16:08:32 CEST] <jamrial> durandal_1707: the "da" parameter seems pointless as you either don't use it or overwrite it [16:12:08 CEST] <durandal_1707> jamrial: it is for future functions [16:12:27 CEST] <durandal_1707> when main have alpha [16:12:43 CEST] <jamrial> ok [16:14:52 CEST] <jamrial> i don't see anything obviously wrong, so make sure there's a fate test for this and it should be good [16:16:19 CEST] <durandal_1707> jamrial: there are already tests for overlay filter [16:17:02 CEST] <JEEB> and it passes? zer gut [16:19:04 CEST] <durandal_1707> as reviewer you must apply, build, install and test it too [16:20:06 CEST] <BBB> durandal_1707: do you appreciate vittorios comment? I think its good to not just reject it but at least think about what he says a little [16:24:11 CEST] <durandal_1707> BBB: i appreciate everyones comments, i write all such comments in my diary [16:25:15 CEST] <Chloe> Doesnt this patchset highlight the bigger issue here: the state of swscale [16:32:00 CEST] <atomnuker> no, it doesn't [16:32:12 CEST] <atomnuker> this is just negotiation [16:32:19 CEST] <atomnuker> and removal of YUVJ formats [16:37:29 CEST] <atomnuker> but feel free to think it underlines the shortcomings of big bad swscale because someone told you so and because of your misconceptions [16:44:44 CEST] <BBB> swscale demonstrates that video format conversion has gotten a lot more complex over the years [16:44:50 CEST] <BBB> it used to just be pixel layout and scaling [16:44:54 CEST] <BBB> then full vs. limited range [16:44:56 CEST] <JEEB> yup [16:45:07 CEST] <BBB> and now its also primaries, colorspace (bt709/2020/etc.), transfer function [16:45:07 CEST] <JEEB> then colorspaces within the same colorspace families [16:45:15 CEST] <BBB> in the future well adjust it dynamically for viewing conditions [16:45:37 CEST] <BBB> I guess swscale handles bitdepth somewhat, although I find the dithering deplorable [16:45:41 CEST] <BBB> but thats just me [16:45:52 CEST] <BBB> and people dont like when I say deplorable so maybe I shouldn't [16:50:52 CEST] <atomnuker> would you rather it shifts without dithering? [16:51:03 CEST] <atomnuker> there are more than one dithering methods available too [16:54:06 CEST] <BBB> I would not rather have it shift without dithering [16:54:16 CEST] <BBB> I would, however, like to have an option to use floyd-steinberg dithering [16:54:49 CEST] <JEEB> for various stuff I would just point one towards zimg [16:54:52 CEST] <JEEB> and the zscale filter [16:55:06 CEST] <BBB> yes, I believe vittorio is a fan of that also [16:55:19 CEST] <nevcairiel> I just wish zscale had some ARM assembly [16:55:22 CEST] <JEEB> it's one of those cases "holy crap the eternal IRC troll actually made something quite useful" [16:55:24 CEST] <nevcairiel> but i'm too dumb to write that [16:55:25 CEST] <JEEB> *cases of [16:55:33 CEST] <BBB> Im kind of sad, I was hoping that the colorspace filter would be a good stop-gap fix for that, but unfortunately it just didnt do enough quickly enough [16:56:21 CEST] <BBB> but Ill admit that zimg does more than colorspace, and it doesnt do it poorly, so thats kind of great [16:56:51 CEST] <BBB> (my sarcasm there is just me being northern-dutch, not me being negative about zimg or anything) [16:57:43 CEST] <atomnuker> JEEB: would you not? [16:57:56 CEST] <atomnuker> _stop_ flogging that thing here or on #ffmpeg [16:58:01 CEST] <JEEB> eh? [16:58:15 CEST] <JEEB> it seems to be doing a better job than swscale [16:58:15 CEST] <atomnuker> you always mention it whenever someone asks about conversions [16:58:25 CEST] <JEEB> if I'm incorrect then sure [16:58:38 CEST] <nevcairiel> its definitely much better then anything we have [16:58:40 CEST] <atomnuker> define better [16:58:51 CEST] <BBB> atomnuker: what do you want us to do? recommend swscale? [16:58:53 CEST] <atomnuker> I understand if its for some complicated niche conversion [16:58:55 CEST] <BBB> or fix swscale? [16:59:05 CEST] <BBB> or something else? [16:59:15 CEST] <JEEB> yes, for just plain scaling it might be OK, not sure if swscale does linear gamma [16:59:23 CEST] <nevcairiel> it does not [16:59:35 CEST] <atomnuker> stop flogging it unless its necessary, like a conversion which swscale isn't fast at or is plain wrong at [16:59:41 CEST] <JEEB> sure [16:59:55 CEST] <JEEB> but we were specifically talking about colormatrix/transfer function/resolution [17:00:03 CEST] <JEEB> and while you could have 2 filters do some of that [17:00:09 CEST] <JEEB> BBB's and swscale [17:00:13 CEST] <JEEB> (when used together) [17:00:24 CEST] <JEEB> w/34 [17:00:46 CEST] <JEEB> also isn't "flogging" basically hitting someone in the back with a whip or something? [17:01:27 CEST] <JEEB> anyways, colorspaces|transfer matrices etc. were *specifically* mentioned [17:01:40 CEST] <JEEB> so I don't get it why you're so mad [17:02:01 CEST] <JEEB> and yes, I use swscale myself at times because nobody cares if some things are 100% correct with gamma-correct scaling and shit [17:02:37 CEST] <JEEB> but as soon as we start caring about that as being 'the baseline' then we only have zimg and libplacebo (whenever that gets ready) [17:02:43 CEST] <JEEB> that do these things correctly [17:13:07 CEST] <atomnuker> you offer zimg to people who don't have a need for it and won't solve their problem [17:13:16 CEST] <atomnuker> and whenever the topic arises you can't help but mention it [17:15:12 CEST] <JEEB> when was it in cases where it will not do what they need? [17:20:44 CEST] <atomnuker> a time or two on #ffmpeg [17:21:07 CEST] <JEEB> right. in a case where they didn't need scaling or colorspace conversion? [17:21:34 CEST] <atomnuker> yes [17:21:40 CEST] <JEEB> ok [17:21:46 CEST] <JEEB> then that was incorrect of course [17:21:54 CEST] <JEEB> but it's quite surprising I would recommend it in that case [17:22:02 CEST] <JEEB> but sure, I'm not perfect and probably an asshole too [17:23:54 CEST] <JEEB> but I find this thing pretty derpy that you start herping a derp at me when specifically these technicalities of how colorimetry has become more complex was the goddamn theme [17:24:13 CEST] <wm4> durandal_1707: you never sent me a sample file, and the one I made seemed ok [17:50:17 CEST] <durandal_1707> wm4: you sure it is hd1080 and long enough? [17:50:20 CEST] <BBB> JEEB: colorspace; colormatrix is the older (8bit only) filter from baptiste [17:50:48 CEST] <JEEB> yea, I remember there were two but always get them wrong :P [17:51:02 CEST] <wm4> durandal_1707: I can't do anything with this statement and I won't try to guess what the heck you mean either [17:54:31 CEST] <durandal_1707> wm4: this one: https://media.xiph.org/video/derf/y4m/sunflower_1080p25.y4m , with 500 frames, backstepping from end show hourglass [17:54:53 CEST] <durandal_1707> just any hd1080 y4m with 500 frames will do [17:55:18 CEST] <durandal_1707> you need to have , pressed all the time [17:55:34 CEST] <wm4> are you sure you got the right player, mpv doesn't render hourglass cursors [17:55:45 CEST] <wm4> To reduce wasted bandwidth from poorly-behaved scrapers and web [17:55:45 CEST] <wm4> crawlers, please verify below that you intend to download a very [17:55:45 CEST] <wm4> large file. [17:55:50 CEST] <wm4> is what I get with wget [17:56:36 CEST] <durandal_1707> wm4: ffmpeg -f lavfi -i testsrc2=size=hd1080 -vframes=500 out.y4m [17:56:59 CEST] <wm4> Unrecognized option 'vframes=500'. [17:57:00 CEST] <wm4> Error splitting the argument list: Option not found [17:57:40 CEST] <BBB> JEEB: its ok, close enough [17:57:51 CEST] <BBB> wm4: -vframes <space> 500 [17:58:16 CEST] <BBB> remember, ffmpeg has its own NIH getopt_long implementation that has many more features and is much more consistent [17:58:17 CEST] <durandal_1707> see, i mixed mpv synthax with ffmpeg one [17:58:43 CEST] <JEEB> mpv doesn't do singular dashes [17:58:48 CEST] <JEEB> as far as I know :P [18:21:59 CEST] <wm4> durandal_1707: seemingly, seeking will sporadically not work (from mpv's perspective the demuxer seek is broken) [18:22:47 CEST] <wm4> durandal_1707: so libavformat will somehow seek to the start instead, and the backstepping will decode _all_ frames until the target [18:29:15 CEST] <durandal_1707> wm4: and with my patch it is instant [18:34:47 CEST] <wm4> that just means the current code is even more broken [18:35:04 CEST] <wm4> but your new code is not entirely correct [18:38:00 CEST] <durandal_1707> wm4: i just need to add FFMAX(pts, 0) [18:59:43 CEST] <atomnuker> why are there 2 sets of arnr options for libvpx... [19:00:07 CEST] <atomnuker> -arnr-maxframes, -arnr-strength, -arnr-type [19:00:18 CEST] <atomnuker> -arnr_max_frames, -arnr_strength, -arnr_type [19:02:27 CEST] <jamrial> "legacy" and "common" options. same reason quality and deadline are the same option, or cpu-used and speed [19:03:03 CEST] <jamrial> things just piled up around the time vp9 encoding was added [19:08:08 CEST] <atomnuker> has it been long enough to remove them? [19:11:08 CEST] <jamrial> they are not deprecated, though [19:11:59 CEST] <atomnuker> the common ones were added 5 years ago [19:12:33 CEST] <atomnuker> well why weren't they deprecated? could people not decide which ones they wanted? [19:12:59 CEST] <atomnuker> even weirder is that the common ones have the "-" sign but the older ones as well as most vpx options have an underscore [19:13:50 CEST] <atomnuker> actually the opposite, the common ones blend in better [19:30:35 CEST] <JEEB> https://lwn.net/Articles/753284/ [19:30:37 CEST] <JEEB> gcc 8.1 out [19:31:29 CEST] <wm4> old [19:31:40 CEST] <JEEB> sure :) just noticed it on LWN [19:32:11 CEST] <wm4> gawd there's already c++-2a [19:32:14 CEST] <wm4> (why "a") [19:33:18 CEST] <nevcairiel> it was 1z and the overflow from z is a [19:33:44 CEST] <nevcairiel> 0x, 1z, 2a [19:33:55 CEST] <nevcairiel> hm wonder what happened to y [19:34:30 CEST] <nevcairiel> oh it existed [19:34:42 CEST] <nevcairiel> 0x became 11, 1y became 14, 1z is becoming 17 [19:34:45 CEST] <nevcairiel> 2a probably 21? [19:35:02 CEST] <nevcairiel> maybe 20 [19:35:06 CEST] <nevcairiel> who knows when they finish it [19:37:02 CEST] <jamrial> 1z is 17, not becoming [19:37:21 CEST] <nevcairiel> is that fully and finally ratified yet [19:37:26 CEST] <jamrial> it's finished, but the supposed juicy parts were postponed for 2x [19:37:52 CEST] <nevcairiel> since 11 they havent really messed with the core much anymore anyway, just piling features on [19:39:05 CEST] <nevcairiel> gcc 8.1 only claims experimental support for c++17, must be a mess to get it in fully, they are usually faster then that [19:39:53 CEST] <jamrial> yeah [19:40:41 CEST] <wm4> does 2a finally add concepts? [19:40:43 CEST] Action: wm4 lols [19:41:02 CEST] <nevcairiel> its in the draft for it yes [19:42:00 CEST] <jamrial> gcc 5 came out in 2014 and was already c++14 feature complete, for example [19:42:38 CEST] <jamrial> actually no, early 2015, but still [19:42:55 CEST] <wm4> I wonder if they'll fix the completely broken C99 designated initializers [19:46:01 CEST] <BBB> whats broken about it? [19:47:00 CEST] <wm4> compiler enforces the same order as declaration, and array syntax doesn't work [20:04:13 CEST] <rcombs> string literals as template parameters are interesting, and there's a proposal to add std::fmt [20:04:34 CEST] <rcombs> which would be based on fmtlib, and do type-safe (sn)printf [20:05:10 CEST] <rcombs> possibly including compile-time format-string parsing [20:05:34 CEST] <nevcairiel> some C compilers already do that to throw warnings at you [20:07:31 CEST] <rcombs> nevcairiel: yeah but then the libc parses it again at runtime [20:07:53 CEST] <nevcairiel> i guess if it can store it to kenized during compilation or so that might be neat [20:07:54 CEST] <rcombs> (twice for asprintf) [20:07:58 CEST] <nevcairiel> tokenized* [20:08:09 CEST] <rcombs> yeah [20:08:18 CEST] <rcombs> there's a proposal for compile-time code that emits runtime code [20:08:42 CEST] <rcombs> with the compile-time code having really extensive introspection/reflection capability [20:08:51 CEST] <rcombs> like, "iterate class members" and such [20:09:02 CEST] <wm4> D did that years ago and it was a shitball [20:10:13 CEST] <rcombs> so compile-time format strings would move the parser loop to compile-time and emit e.g. "print N characters, then format an int, then print N more characters, then format a float", etc, as C++ code [20:12:09 CEST] <rcombs> the nice thing about fmtlib over printf as-is is that it supports arbitrary C++ types; you can define a formatter function or any given type (and if you don't it'll use the ostream<< one) [20:12:16 CEST] <rcombs> so you can spit out string, path, etc [20:13:26 CEST] <rcombs> I still hate std::filesystem::path for trying to force MS's bullshit on me [20:13:40 CEST] <wm4> could be sort of done with C if anyone cared [20:14:07 CEST] <rcombs> path::path(string) converts from [process codepage] to UTF-16; path::string() converts from UTF-16 to [process codepage] [20:14:36 CEST] <rcombs> at least with boost::filesystem::path I can set an override to make it use UTF-8 instead of [process codepage] [20:14:56 CEST] <rcombs> "but rcombs, that adds global state" yeah fuckwit what do you think the process codepage is [20:15:06 CEST] <wm4> also I don't get why paths would need special formatting [20:15:22 CEST] <rcombs> wm4: they don't, it's just another type that isn't char* [20:15:37 CEST] <rcombs> the formatter for it just takes the string [20:15:52 CEST] <rcombs> (the path class is just a wrapper around std::string [or std::wstring if your platform sucks]) [20:16:49 CEST] <wm4> oh, so C++ solving C++ made problems [20:17:25 CEST] <rcombs> eh, it's a useful wrapper [20:17:40 CEST] <wm4> totally [20:17:55 CEST] <wm4> I mean I know what code you're talking about, so I don't have to believe you [20:17:56 CEST] <rcombs> stuff like operator/ to join adding a separator, functions to extract the filename, stem, etc [20:26:26 CEST] <wm4> you could just use, you know, functions for that [20:37:21 CEST] <atomnuker> wm4: read what I write next time [20:37:39 CEST] <TD-Linux> rcombs, most c compilers can special case printf and emit calls to special minimize versions that don't do full parsing [20:37:59 CEST] <rcombs> huh, really? [20:38:12 CEST] <rcombs> like, for non-trivial cases? [20:38:48 CEST] <wm4> atomnuker: how did I offend you now [20:39:13 CEST] <nevcairiel> nevermind him, he is just extra obnoxious today [20:39:26 CEST] <TD-Linux> I'm not sure exactly, I know printf("%s", x) gets reduced and I've seen more specific ones show up in disassembly [20:40:13 CEST] <rcombs> yeah I know about that one [20:40:28 CEST] <wm4> oh, so me mentioning HDMI was offensive because it's already covered by "broadcasting junk" [20:40:30 CEST] <wm4> well whatever [20:40:34 CEST] <TD-Linux> it's a builtin function so in theory it can do anything [20:40:58 CEST] <rcombs> yeah, though usually it ends up just being a bog-standard variadic function call [20:43:50 CEST] <TD-Linux> rcombs, huh it looks like latest gcc actually has a full "printf compiler" and emits custom code for each printf call https://github.com/gcc-mirror/gcc/blob/master/gcc/gimple-ssa-sprintf.c [20:43:58 CEST] <rcombs> oh huh [20:45:04 CEST] <rcombs> that looks like it's just used for warnings and constants, though? [20:45:39 CEST] <atomnuker> nevcairiel: I'm frustrated such an idea could even be proposed by someone in our circles [20:53:13 CEST] <TD-Linux> rcombs, yeah you're right. the actual folding happens here. I assumed it being in gimple would mean a full compiler, but it's just a bunch of special cases. https://github.com/gcc-mirror/gcc/blob/master/gcc/gimple-fold.c#L3108 [20:55:09 CEST] <rcombs> yeah, that's still just the "no %" and "just %s" special cases [20:55:26 CEST] <rcombs> which is nice but not especially broad [23:17:13 CEST] <atomnuker> michaelni: could you please okay that libxvid_rc patch? [23:17:20 CEST] <atomnuker> you're listed as maintainer [23:19:30 CEST] <durandal_1707> he is busy finding case where that code is useful [23:20:19 CEST] <atomnuker> or maybe he's formulating a new branch of psychology to try to understand carl's objection to the commit message [23:20:43 CEST] <atomnuker> like myself, because I don't understand what he's complaining about [23:20:54 CEST] <atomnuker> sentence by sentence, each statement is the truth [23:22:23 CEST] <jamrial> he probably doesn't like the commit message is too agressive, saying only misled people used that feature and such [23:26:20 CEST] <j-b> I kind of agree on the commit message. However, the commit in itself is fine. [23:26:49 CEST] <BBB> I find the commit message aggressive, but so is his opposition to it [23:27:03 CEST] <BBB> both could display some more manners and common sense :-/ [23:27:29 CEST] <j-b> well, it's also very easy to say "Commit OK, please reformulate commit message" and end the discussion [23:27:52 CEST] <BBB> +1 [23:36:19 CEST] <durandal_1707> Gramner: i will add you to copyright as you did it too [23:36:48 CEST] <Gramner> ok, sure [23:51:34 CEST] <jkqxz> I feel like I must have missed something here. How is one meant to distinguish between the H.265 profiles with the same profile_idc and constraint flags? E.g. "Screen-Extended High Throughput 4:4:4 10" and "Screen-Extended 4:4:4 10". [23:52:13 CEST] <JEEB> wasn't there also a tier flag? [23:52:16 CEST] <JEEB> or something [23:53:11 CEST] <jkqxz> I don't think the tier flag makes a difference? [23:53:36 CEST] <jamrial> wasn't there a huge compat table or some such? [23:53:38 CEST] <jkqxz> It looks like it only modifies the level constraints (after you know the profile). [23:53:59 CEST] <JEEB> ah [23:58:24 CEST] <jkqxz> There are a few other differences like the high throughput profiles allowing 4:2:2 and combining of tiles with entropy-coding-sync, but those are optional so can't be used to distinguish them. [23:59:52 CEST] <jkqxz> jamrial: The relevant rows of the huge table (table A.5 is the relevant part of it) are identical for the two profiles. [23:59:59 CEST] <jamrial> i see [00:00:00 CEST] --- Thu May 3 2018

1 0

ffmpeg.log.20180502
by burek 03 May '18

03 May '18

[04:07:16 CEST] <oerg866> bug: ffmpeg 4.0 messes up -vf setdar on mpeg2video [04:07:31 CEST] <oerg866> the resulting file has an aspect ratio set to 2.2:1 [04:08:29 CEST] <oerg866> with setdar=4:3 i mean [04:24:33 CEST] <oerg866> oh, the num:den syntax was thrown out [04:34:02 CEST] <furq> that hasn't changed afaik [04:34:14 CEST] <furq> you always needed to escape the : or else it'd be parsed as an option separator [04:34:21 CEST] <furq> you can just use 4/3 anyway [05:52:30 CEST] <oerg866> furq: yes it has, 3.x had no problem with setdar=4:3 just like that [05:52:40 CEST] <oerg866> but now that I know what to do I'll just adapt my scripts to the new way [05:53:51 CEST] <furq> shrug [05:53:57 CEST] <furq> the manual for 3.4 says : needs to be escaped [05:54:30 CEST] <oerg866> well...what can I tell ya? :D [05:54:37 CEST] <oerg866> works/ed for me :p [05:54:49 CEST] <oerg866> only thing that happened was a warning: [05:54:49 CEST] <oerg866> [Parsed_setdar_5 @ 0000000004c078e0] num:den syntax is deprecated, please use num/den or named options instead [05:55:21 CEST] <oerg866> even used two of them in the same command line to check something (setsar=16:15,setdar=4:3) [05:56:28 CEST] <furq> the manual still says the same thing [05:56:36 CEST] <furq> i wonder if it used to be specialcased and they got rid of it [05:56:45 CEST] <furq> if it had a deprecation warning before then that's probably it [06:12:29 CEST] <oerg866> yeah probably [07:07:57 CEST] <oerg866> furq: what's slightly off-putting is that it doesn't warn you or give an error message if you use the : now [07:08:19 CEST] <oerg866> I needlessly spent like an hour banging my head and registering on the bug-tracker and such :P [08:35:38 CEST] <rakhanreturns> Hello All! I just tried to ./configure ffmpeg from Git and it failed. Where should I paste my log? [08:37:01 CEST] <rakhanreturns> Sorry, dumb question; just saw the message. [08:40:10 CEST] <rakhanreturns> Running Ubuntu 18.04: https://pastebin.com/fH9Fx1D4 [08:52:30 CEST] <oerg866> NICE [08:52:43 CEST] <oerg866> i've spent like a week messing with this but it seems [08:52:54 CEST] <oerg866> i finally managed to mux a 6h44m vob file [08:53:05 CEST] <oerg866> with pcm audio and vobsub sub titles [08:53:20 CEST] <oerg866> out of 129 individual music videos [08:54:41 CEST] <furq> rakhanreturns: install nasm [09:01:08 CEST] <rakhanreturns> furq: Duh. Thanks; that fixed it. [09:06:07 CEST] <oerg866> okay maybe not [09:06:09 CEST] <oerg866> Error writing trailer of C:\output\output.vob: No space left on device [09:06:16 CEST] <oerg866> damn and blast these small SSDs [09:06:20 CEST] <oerg866> oopsie :D [09:28:05 CEST] <oerg866> oh, now I know why [09:28:09 CEST] <oerg866> it just loops over and over [09:28:25 CEST] <oerg866> what the actual fudge [09:33:05 CEST] <oerg866> it's always something else :-) [09:33:26 CEST] <oerg866> ffmpeg -y -f concat -safe 0 -i list.txt -map 0:v -map 0:s -vcodec copy -scodec copy C:\output\temp_video.vob [09:33:46 CEST] <oerg866> this command results in an endless loop, the vob just keeps growing and growing (currently 17 hours ... ) [09:35:45 CEST] <furq> what's in list.txt [09:36:15 CEST] <oerg866> i'll show you if you promise not to sue ;-) [09:36:21 CEST] <furq> i'll try my best [09:36:30 CEST] <oerg866> https://pastebin.com/4gsaAAwy [09:37:08 CEST] <furq> shrug [09:37:57 CEST] <oerg866> I checked the output vob it's actuallycompletely seekable, perfect a/v sync its just looping the same 8 or so hours over and over :D [09:38:03 CEST] <furq> weird [09:38:09 CEST] <oerg866> time for a ticket? [09:38:10 CEST] <furq> all i know is i want to play gta vice city now [09:38:14 CEST] <oerg866> HAHA [09:38:16 CEST] <oerg866> yes! [09:39:27 CEST] <furq> also yeah for a bug report it'll need to be reproducible without external files [09:40:04 CEST] <furq> or it won't need to be but that would help a lot [09:40:05 CEST] <durandal_1707> it will be closed because you use unsafe [09:40:20 CEST] <oerg866> durandal_1707: what does that have to do with anything [09:40:59 CEST] <oerg866> Let's see if I can reduce this to something easily reproducable [09:41:12 CEST] <furq> what's temp_video.vob [09:41:26 CEST] <furq> is that maybe a previous output file [09:41:55 CEST] <oerg866> it existed before yeah [09:41:57 CEST] <furq> oh right yeah it is [09:42:02 CEST] <furq> that's in your concat list [09:42:08 CEST] <oerg866> oh my god [09:42:29 CEST] Last message repeated 1 time(s). [09:42:29 CEST] <oerg866> stupidity like mine shouldn't be allowed [09:43:08 CEST] <oerg866> FINGERS CROSSED [09:43:45 CEST] <furq> that is actually sort of fascinating that that works [09:44:27 CEST] <furq> that's probably actually a viable way of looping something infinitely [09:46:25 CEST] <oerg866> yeah [09:46:34 CEST] <oerg866> not just that it works but that the file remains valid [09:46:49 CEST] <oerg866> because I assume it just kept writing new headers in the middle of the file [09:47:06 CEST] <oerg866> (ok, that's valid with MPEG2 I suppose but it still got the seeking right) [09:47:40 CEST] <oerg866> I think this probably wouldn't work with containers like mp4 very well [11:46:55 CEST] <Accord> hey, I have some png frames which act as an alpha mask, I'd like to alphamerge these frames with another video [11:47:36 CEST] <Accord> do I have to make a video from the png frames first? if so is there a container / codec that will losslessly pack the pngs? [11:47:45 CEST] <Accord> tried qtrle but it's too lossy [12:00:03 CEST] <furq> no [12:00:27 CEST] <furq> just -i foo.mkv -i foo_%03d.png -lavfi alphamerge [12:10:00 CEST] <gloomy> hi :) [12:10:13 CEST] <gloomy> Is there a way to add libraries to ffmpeg /after/ compilation? [12:10:28 CEST] <gloomy> I realised I don't have libx265 installed [12:10:45 CEST] <gloomy> recompiling everything is quite lengthy iirc [12:14:48 CEST] <sfan5> nope [12:15:15 CEST] <sfan5> the only thing you could do is pipe the output from ffmpeg to x265 being called externally [12:19:53 CEST] <Accord> furq: thanks [12:20:04 CEST] <Accord> but I'm having problems simply applying one png as an alpha mask [12:20:13 CEST] <Accord> this is my command : ffmpeg -y -i /home/claudiu/Videos/bbb_small_360.mp4 -filter_complex "movie=frames/0000.png:loop=0, alphaextract [alpha]; [0:v][alpha] alphamerge" -c:v libx264 out.mp4 [12:21:00 CEST] <Accord> my mask is a png with 0,0,0,0 as background and 0, 0, 0, 255 (black) ellipse in the middle [12:21:24 CEST] <Accord> but the input video isn't changed at all [13:33:42 CEST] <gloomy> Hellp [13:33:42 CEST] <gloomy> hello * [13:40:42 CEST] <gloomy> Sorry, my connection went down [13:40:44 CEST] <gloomy> I was saying: [13:40:47 CEST] <gloomy> I am trying to pack a hevc stream in a container [13:40:52 CEST] <gloomy> here is what I get: [13:41:08 CEST] <gloomy> https://pastebin.com/Mdj9WZJX [13:41:14 CEST] <gloomy> Any idea what the issue might be? [13:41:24 CEST] <gloomy> I'm pretty sure the stream is valid [13:56:03 CEST] <BtbN> Is raw .265 even valid? [13:58:40 CEST] <gloomy> What do you mean? [13:59:21 CEST] <furq> yeah there's a format for it [13:59:34 CEST] <BtbN> That file in particular appears to be broken then [13:59:41 CEST] <BtbN> Or just not HEVC [14:00:18 CEST] <gloomy> I looked at it with hevcbrowser and everything seems fine... [18:47:21 CEST] <lemontea> Hello Ffmpeg, I have an issue with directshow and audio. There is a 1.5 second delay on capturing the microphone, (through static executable and the API). How to get around this or am I doing something wrong? CLI: ffmpeg -f dshow -i audio="CABLE Output (VB-Audio Virtual Cable)" stuff.mp3 [18:50:49 CEST] <durandal_1707> lemontea: what if you do not use mp3 ? [18:55:52 CEST] <ChocolateArmpits> lemontea, there seems to be added latency for microphone capture as explained here http://trac.ffmpeg.org/wiki/DirectShow#BufferingLatency [18:56:08 CEST] <ChocolateArmpits> lemontea, additionally you can tweak input delay using -itsoffset parameter [18:59:38 CEST] <alexpigment> maybe i'm missing something, but how do you know if you have a delay if you're writing out to an mp3 file? [19:00:04 CEST] <alexpigment> perhaps he's just summarizing a larger command that gives a better context for where the delay is perceived [19:00:50 CEST] <ChocolateArmpits> well if the command is stopped at a point when he stops speaking, I guess the buffered data that still contains some speech samples might be dropped, no? [19:01:06 CEST] <alexpigment> ah, i guess that makes sense [19:01:13 CEST] <alexpigment> in which case, the itsoffset thing is probably unrelated [19:02:06 CEST] <alexpigment> maybe worth putting the buffer size down to ~50ms as indicated in that article [20:36:02 CEST] <oerg866> furq: my endeavours did actually end up in a ticket :-) https://trac.ffmpeg.org/ticket/7183#ticket [21:56:33 CEST] <gwohl> When I run `ffprobe -show_frames -select_streams v:0` on a matroska file containing a single FFV1 video stream, the `coded_picture_number` of each frame is returned as `0`. On matroska files containing an H.264 video stream, though, the `coded_picture_number` of each frame will correctly increment. Is there another way to get a `coded_picture_number` of a FFV1 frame? [23:19:06 CEST] <lemontea> ChocolateArmpits Thanks. I think that is the idea. And i timed it so, when I start it, it will make a sound, actually, I can hear my mouse click if that helps. I measure it through Audacity [00:00:00 CEST] --- Thu May 3 2018

1 0

ffmpeg-devel.log.20180501
by burek 02 May '18

02 May '18

[00:08:18 CEST] <durandal_1707> i will remove 4 arguments, and let it filter only mmsize multiple of stuff and return consumed bytes, because writing normal asm is pain [00:11:09 CEST] <kierank> just make the function work on mod 8 or 16 data and finish the rest in c [00:11:41 CEST] <Gramner> writing scalar asm tends to not be very useful compared to compiler-generated code in general [01:31:33 CEST] <cone-189> ffmpeg 03James Almer 07master:65d36473c930: avcodec/cbs_mpeg2: create a reference to the existing buffer when decomposing slice units [01:31:34 CEST] <cone-189> ffmpeg 03James Almer 07master:0807a7716009: avcodec/cbs_h2645: create a reference to the existing buffer when decomposing slice units [01:32:46 CEST] <jkqxz> jamrial: I did some more AV1, but the minor changes everywhere are quite annoying. [01:32:54 CEST] <jkqxz> It doesn't really invite doing much more until it's actually frozen (so I don't have to read through all of the syntax tables carefully yet again). [01:33:07 CEST] <JEEB> yea :/ [01:35:05 CEST] <jamrial> i don't think there have been any changes to the header obus in a while, but yeah, better wait until the thing is officially frozen [01:36:03 CEST] <jkqxz> The uncompressed header was totally rearranged since ~three weeks ago. [01:37:13 CEST] <jamrial> yeah, they added this reduced still image stuff and turned it upside down, heh [01:38:09 CEST] <wm4> didn't they say it's frozen a month ago? lol [01:38:29 CEST] <jamrial> that was a pr move [02:07:11 CEST] <BBB> https://aomedia.googlesource.com/aom/+/98ec4594116b20e98c785f6e15dd463b7225… [02:07:13 CEST] <BBB> that was 4 days ago [02:07:16 CEST] <BBB> so no, its not frozen [02:07:37 CEST] <BBB> I believe that most changes now are about fix bug, not add feature" [02:21:23 CEST] <jamrial> BBB: and https://aomedia.googlesource.com/aom/+/598d11fdceedaf362033cc24323d60211754… was today, so yeah [04:35:08 CEST] <rcombs> jkqxz: the folks at NAB seemed to be under the impression that it was frozen, but I think what they internally mean is that silicon design work is theoretically unblocked [11:03:53 CEST] <nevcairiel> rcombs: so their silly marketing stunt with their fake announcement apparently worked on the NAB people, huh [13:17:54 CEST] <cone-851> ffmpeg 03Paul B Mahol 07master:273edb2fe45a: avfilter/vf_neighbor: rewrite without using temp memory [15:10:15 CEST] <cone-851> ffmpeg 03Paul B Mahol 07master:ddf844d17c40: avfilter/vf_neighbor: simplify code little [15:10:16 CEST] <cone-851> ffmpeg 03Paul B Mahol 07master:5bfc433a6ed9: avfilter/vf_neighbor: add slice threading [16:05:13 CEST] <cone-851> ffmpeg 03Paul B Mahol 07master:2308a3c7e37d: avfilter/af_biquads: change clipping detection from global to channel [16:05:14 CEST] <cone-851> ffmpeg 03Paul B Mahol 07master:d176497cec95: avfilter/af_biquads: add slice threading [16:26:53 CEST] <durandal_1707> JEEB: somebody claims overlay is slower with framesync2 ? [16:28:36 CEST] <JEEB> it seems to have been my sub2video fix after all quite likely, something regarding buffering or something that makes realtime use cases start failing after N amount of time. so without my fix you lose overlay because of End-of-Stream at filter chain reinit, and with my fix there is something wrong somewhere - I haven't debugged what exactly yet [16:28:58 CEST] <JEEB> I think I am just going to call this "I'm going to slap whomever came up with using the same filter chain for video and audio" [16:29:19 CEST] <JEEB> if you want a sample and replication command I can give that if you want to look into it [16:57:23 CEST] <Danil_Iaschenko> Hi everybody! My name is Danil Iashchenko, I'm GSoC student and I will be working on project "OpenCL support for libavfilter". (https://summerofcode.withgoogle.com/projects/#4925416792391680) My mentor is Mark Thompson. [17:05:47 CEST] <durandal_1707> wm4: somehow mpv thinks pts are broken, and is trying to fix it, that's way backstepping is so slow [17:31:52 CEST] <jkqxz> Danil_Iaschenko: Welcome! [17:36:19 CEST] <jkqxz> Danil_Iaschenko: If you have any general questions about ffmpeg development then here is a good place to ask them, and some people have useful knowledge of hardware or libavfilter (though not necessarily OpenCL). [17:39:25 CEST] <jkqxz> (Though as you can see there isn't much excitement going on right now - traffic is quite variable, and it's fine to lurk all the time.) [17:58:36 CEST] <jamrial> jkqxz: labour/worker day :p [17:59:00 CEST] <nevcairiel> except in murica, they for some reason have that in fall [18:01:34 CEST] <jkqxz> Ohright, yeah. The holiday for it in this country is defined as the first Monday in May, so it's actually next week. [18:01:59 CEST] <nevcairiel> first of may for us [18:03:07 CEST] <atomnuker> jkqxz: that's a bank holiday [18:04:15 CEST] <atomnuker> nothing to glorify the low-middle class workers [18:06:57 CEST] <jkqxz> Well, May Day was a thing before socialism was invented. [18:08:05 CEST] <nevcairiel> those two concepts kind of combined around here [18:11:52 CEST] <durandal_1707> who have expertize in IVTC and deinterlacing? [18:14:57 CEST] <atomnuker> JEEB maybe? [18:15:08 CEST] <jkqxz> As long as the peasants stay down they can have as many maypoles and as much morris dancing as they like, I guess. [18:17:30 CEST] <atomnuker> and as long as these pagans don't do that in front of churches [19:30:51 CEST] <kierank> durandal_1707: me [19:30:54 CEST] <kierank> what do you want [19:31:17 CEST] <JEEB> oh, so you found something wonky with it too? [19:33:41 CEST] <atomnuker> you can't use detelecine in mpv as it complains the framerate is variable (its uninitialized, 0/1 or something) [19:33:55 CEST] <atomnuker> you can use the fieldmatch filter [19:34:02 CEST] <durandal_1707> detelcine is carl's pet [19:34:38 CEST] <atomnuker> its useless, and then there's the dejitter filter which is meant to fix the output of detelecine [19:35:10 CEST] <durandal_1707> dejudder [19:35:33 CEST] <atomnuker> I say remove detelecine and that, move fieldmatch to detelecine and make detelecine optionally decimate the output [19:35:50 CEST] <atomnuker> the decimate filter has the same error if used in mpv too btw [19:37:32 CEST] <durandal_1707> atomnuker: use them inside -vf "lavfi=[]" [21:19:00 CEST] <durandal_1707> cat i get explicit approval for overlay patch? [21:22:00 CEST] <BBB> atomnuker: \o/ [21:23:48 CEST] <durandal_1707> but, but we are old code museum, not code removal please! [21:33:19 CEST] <Gramner> need more mmx code for everything [21:34:08 CEST] <Gramner> think about all those people who want to decode 4K AV1 on their pentium pros [21:35:50 CEST] <atomnuker> what happened with musl libc btw? do they still do floating point math inside malloc() and don't bother with the FPU state? [21:36:24 CEST] <Gramner> iirc they changed that [21:37:36 CEST] <jamrial> atomnuker: add the deprecated opt flag while at it [21:37:47 CEST] <iive> musl should be using lookup table now. [21:38:36 CEST] <durandal_1707> hello, please explicitly approve my overlay patch! [21:39:17 CEST] <Gramner> durandal_1707: now you're just making me want to nitpick it! [21:40:01 CEST] <cone-785> ffmpeg 03Matt Oliver 07release/4.0:29328d96b90f: ffplay: Fix realloc_texture when input texture is NULL. [21:40:01 CEST] <cone-785> ffmpeg 03Marton Balint 07release/4.0:da6c519f6e53: avformat/qtpalette: parse color table according to the QuickTime file format specs [21:40:01 CEST] <cone-785> ffmpeg 03Marton Balint 07release/4.0:70a01aa4901a: avcodec/anm: fix palette alpha [21:40:01 CEST] <cone-785> ffmpeg 03Marton Balint 07release/4.0:0a22e31fbbba: avcodec/hnm4video: fix palette alpha [21:40:01 CEST] <cone-785> ffmpeg 03Marton Balint 07release/4.0:d89eea345586: avdevice/decklink_dec: unref packets on avpacket_queue_put error [21:40:40 CEST] <durandal_1707> nooooooo! [21:41:56 CEST] <durandal_1707> because you are all evil, i sent you more spam to your mailboxes! [21:42:28 CEST] <atomnuker> jamrial: oh, right, forgot about it, added locally as replied on the ml [21:47:06 CEST] <durandal_1707> atomnuker: i posted spam because you complained multiple times, now I expect explicit approvals [21:53:28 CEST] <durandal_1707> jamrial: i not gonna add x86_32 support for overlay asm, there are others that can do it [21:54:00 CEST] <jamrial> it's a one line change for two functions, and a two line change for the last function [21:55:12 CEST] <jamrial> don't be lazy. it's not like the others i adapted that required ifdeffery [21:58:31 CEST] <durandal_1707> i'm not gonna do it, its hard, and i can not test it, dont be lazy and write it instead [21:58:53 CEST] <JEEB> I mean, someone already ran FATE for you, right? [21:59:30 CEST] <JEEB> or are you expecting someone to rage at you and eff you off and send a patch? [22:00:51 CEST] <atomnuker> durandal_1707: you just need to recompile with a different flag to test it (unless you're from the future and they've dropped 32 bit in x86 cpus) [22:01:20 CEST] <durandal_1707> i'm from future [22:04:57 CEST] <atomnuker> have they dropped 16-bit mode too? [22:08:40 CEST] <atomnuker> durandal_1707: oh wow, you reposted the patchset, thanks [22:08:54 CEST] <atomnuker> that's with the 2 bugs fixed from last time, right? [22:12:16 CEST] <durandal_1707> i do not know, was long ago [22:13:47 CEST] <Gramner> 16-bit x86 with memory segmentation is the one true µarch. it will be in your cpu forever eating transistors [22:13:53 CEST] <atomnuker> I think so, the ffplay limited range only patch addressed IIRC one of them [22:14:25 CEST] <Gramner> along with x87 [22:14:37 CEST] <atomnuker> nah, AMD will drop it soon, probably [22:14:46 CEST] <atomnuker> (as in, not flag it, they'll drop it later) [22:15:02 CEST] <atomnuker> like what happened with FMA4 [22:15:31 CEST] <Gramner> yeah, AMD actually drops stuff unlike intel which still support undocumented instructions from the 8086 days [22:16:04 CEST] <atomnuker> lol, really? which ones [22:16:27 CEST] <Gramner> it's just too bad that they didn't bring the axe to a lot more stuff when they created amd64 [22:19:07 CEST] <jamrial> amd drops xop, which has useful instructions, but keeps shipping cpus with sse4a, which nothing and nobody uses [22:19:28 CEST] <Gramner> xop was good but never got traction because intel refused to support it [22:20:54 CEST] <Gramner> atomnuker: 0xD6 is one undocomented instruction for example [22:21:07 CEST] <Gramner> equivalent to sbb al, al except it doesn't set flags [22:21:16 CEST] <Gramner> which is obviously incredibly useful /s [22:21:25 CEST] <Gramner> and totally warrants a one-byte opcode [22:23:16 CEST] <jamrial> intel adopted amd64 and nothing else from amd because legacy code must run no matter what, so ia64 was a no go [22:23:19 CEST] <jamrial> it's no wonder then why they keep instructions like that one in place [22:23:34 CEST] <Gramner> so much useless garbage occuping one-byte opcodes, so any new instructions become insanely long [22:25:15 CEST] <Gramner> had amd been smart they would've axed all the crap from 64-bit mode when they created amd64 while still supporting it in 32-bit mode. so new stuff could be made 64-bit only with reasonable opcodes. e.g. you could have had avx being 64-bit exclusive with really short opcodes for example [22:25:27 CEST] <Gramner> which would improve performance because instruction decoding sucks [22:26:08 CEST] <Gramner> some avx-512 instructions are like 12 bytes long, it's insane [22:28:52 CEST] <durandal_1707> jamrial: i prefer to explicitly state no stack is used [22:31:33 CEST] <jamrial> ok [22:34:45 CEST] <iive> Gramner, amd didn't invent avx [22:35:04 CEST] <Gramner> no, but they invented amd64 (hence the name) [22:35:35 CEST] <Gramner> and they would reasonable have assumed that at some poin in the future you'd want to add more instructions [22:35:47 CEST] <iive> my point is, intel still could have made something that doesn't use 4-5 byte prefixes for each instruction. [22:35:50 CEST] <durandal_1707> jamrial: how to use al straight from the memory? [22:36:05 CEST] <nevcairiel> iive: not really though, there is only so many values in a byte [22:36:33 CEST] <Gramner> how? prefixes are required to not cause collisions with existing instructions so not using them would break stuff [22:37:36 CEST] <jamrial> durandal_1707: almp [22:37:45 CEST] <nevcairiel> the way they do the vex prefix is already extremely hacky because there just wasnt any bytes left [22:37:46 CEST] <iive> well, not that it is a good solution, but it is a solution. you can use a switchable mode [22:38:22 CEST] <iive> so you can say, all these mmx codes are actually avx. and use the prefix only to invert the mode. [22:38:34 CEST] <iive> i think there is already something similar for 32 vs 16 bit. [22:41:59 CEST] <iive> i have explained before my idea how to make extensible SIMD, so the mode could actually be setting the register size [22:42:22 CEST] <iive> the benefit, you won't need new opcodes for avx-1024 [22:43:07 CEST] <nevcairiel> Even if that might work, you are limited to exactly the same instructions you always had, no changing [22:43:14 CEST] <nevcairiel> thats not extensible, thats just variable-size [22:46:08 CEST] <Gramner> I'm guessing changing the meaning of opcodes back and forth on the fly probably introduces a lot of issues with µop caching, interrupts, etc. [22:46:55 CEST] <Gramner> and you would have to change it a lot since calling external library functions might expect things to be in the "old state" and break otherwise [22:47:08 CEST] <iive> not really [22:48:15 CEST] <iive> let's say that we have a register names mmsize, you set the size of register in it and the instructions work with that size, avx style. [22:49:39 CEST] <Gramner> now every instruction have an additional register dependency which is problematic [22:49:46 CEST] <iive> that is, if you set mmsize=32, you can use 2 size16 uOPs that execute in parallel. like the amd does. [22:50:14 CEST] <iive> that register only affects uOP generation. [22:52:01 CEST] <iive> you can make it so that modification of that register clears all uOP cache. it's huge penalty that we can affort [22:52:27 CEST] <iive> because we can use a prefix to change it for single operation, [22:53:27 CEST] <iive> still better than mixing sse/avx code. [22:53:47 CEST] <nevcairiel> that could still end up terrible, if you interleave functions one being sse and one avx, you not only would have to write these functions, but also know the full context of how they are called to avoid crazy expensive switches [22:55:10 CEST] <iive> that's the beauty of it. you don't need to write sse/avx functions anymore [22:55:24 CEST] <iive> you write the function once and you can use it with any register size [22:55:37 CEST] <iive> even insanely huge ones. [22:56:26 CEST] <nevcairiel> register still c hange size and you load different amounts of data, sometimes alignment or block size concerns dont let you use the full size, so you use a smaller one [22:56:40 CEST] <nevcairiel> makes no sense to use avx512 on 128-bit data [22:57:17 CEST] <Gramner> variable-sized vector registers is not a new idea, it just turns out that a lot of real-world code is too complex to just work with arbitrary sized registers. an ymm implementation can differ drastically from a xmm one, not just "do half as many loop iterations" [22:58:00 CEST] <atomnuker> yeah, I agree, besides it would probably not be as fast as hardcoding the size to instructions [23:00:26 CEST] <iive> atomnuker, but that's the problem. instruction with big sizes use long redundant prefixes [23:03:21 CEST] <atomnuker> they wouldn't have to if the ISA was cleaned up a bit [23:04:10 CEST] <iive> even if it was [23:04:22 CEST] <iive> it would just mean more pefixes could be used. [23:10:36 CEST] <iive> let's say we remove half of the x86 instruction. how would you use the freed codes? map them all to avx512? [23:13:47 CEST] <iive> Gramner, avx literally executes 2 sse registers. A variable length SIMD would actually need an effective system for collapsing the registers. [23:14:01 CEST] <atomnuker> nah, I'd just use them to make all instructions fit in 2 bytes [23:14:46 CEST] <iive> atomnuker, no problem doing this now. You just need 1 free byte for a prefix, and then use a number to pick the set. [23:15:02 CEST] <iive> but this is not what intel have done, they've been piling prefix after prefix... [23:15:30 CEST] <nevcairiel> because no more bytes are free [23:15:47 CEST] <iive> there are few that are not used yet. [23:15:51 CEST] <Gramner> being able to make most simd instructions 1-2 bytes shorter would help, both for decoding performance and power efficiency as well as code cache utilization [23:16:25 CEST] <nevcairiel> they even only found a half-byte for the vex prefix, it encodes a normal instruction in an invalid way, which the cpu then recognizes [23:19:09 CEST] <atomnuker> and to think intel was pursuing the mobile market with this ISA [23:19:38 CEST] <iive> there are 2 bytes that are currently noop prefixes. 0x2e and 0x3e [23:19:45 CEST] <iive> use them. [23:21:01 CEST] <Gramner> that would break legacy code that uses them as branch prediction prefixes [23:21:20 CEST] <Gramner> and they are adamant to preserve compatibility [23:21:51 CEST] <iive> that's not problem, they can sill be noops when used before branch jump [23:23:22 CEST] <Gramner> then it's longer than one byte when used as a prefix since you'd have to make sure to not collide with valid following bytes [23:24:14 CEST] <iive> not really, [23:25:57 CEST] <iive> but even if it was 2 bytes. you can have 200 different sets using them. [23:29:33 CEST] <rcombs> pull an ARM and have an instruction to switch into a smaller encoding [23:30:14 CEST] <iive> that's what i proposed initially [23:30:16 CEST] <durandal_1707> huh, why m32 binaries are slower than m64 ones? [23:31:21 CEST] <rcombs> save a tiny amount on memory bandwidth for pointers, and better code size due to lack of prefixes? [23:31:59 CEST] <iive> i have even better idea. put more arm cores in the cpu [23:32:02 CEST] <rcombs> (which you might lose in spills but hey depends on your workload) [23:32:13 CEST] <rcombs> iive: and also take out all the x86 ones? [23:32:28 CEST] <atomnuker> durandal_1707: less registers [23:32:35 CEST] <iive> rcombs, you can leave one. for the XT games :P [23:33:56 CEST] <Gramner> also worse calling conventions, e.g. 32-bit x86 passes everything on the stack whereas x86-64 uses registers in most cases [23:34:55 CEST] <nevcairiel> why is it that they never wanted to use registers back then [23:35:11 CEST] <iive> nevcairiel, not enough registers [23:35:28 CEST] <Gramner> probably easier to debug when you can read the process memory and see what arguments were passed [23:35:44 CEST] <nevcairiel> i reckon most of the time you may push something onto the stack before a call and then just pop it out right in the function [23:36:49 CEST] <nevcairiel> the fastcall calling conventions did exist which used 2 registers, but i ts probably rarely used [23:37:42 CEST] <Gramner> doesn't fastcall also have the weird thing where the callee must clean up the stack space allocated by the caller? [23:38:03 CEST] <rcombs> oh I read what durandal_1707 said backwards [23:38:34 CEST] <rcombs> durandal_1707: it's also because there's some asm that's only available on x86_64 because nobody wants to deal with spills when hand-optimizing [23:39:15 CEST] <TD-Linux> also just simpler to implement, these calling conventions were made in the 80s [23:39:16 CEST] <nevcairiel> fastcall is like pascal call or stdcall yeah, callee clean-up [23:41:37 CEST] <Gramner> it's starting to become time to let 32-bit x86 though [23:41:44 CEST] <Gramner> die* [23:41:54 CEST] <Gramner> deprecate it and move on [23:42:27 CEST] <durandal_1707> lies, we still have 3D Now asm and libpostproc [23:43:26 CEST] <rcombs> microsoft's apparently got a new windows variant that fits a 64-bit install on 16GB poop tablets [23:43:39 CEST] <nevcairiel> yeah they stripped it down quite a bit [23:43:40 CEST] <JEEB> hah [23:43:47 CEST] <rcombs> I'm wondering when they'll ship a variant that drops 32-bit compat to save space [23:43:48 CEST] <JEEB> so that means my whiskey might get 64bit [23:43:51 CEST] <JEEB> not that I want one [23:44:04 CEST] <durandal_1707> 16GB? I want max 4GB [23:44:17 CEST] <rcombs> inb4 never because they never gave people any incentive to move to it for non-performance-critical apps [23:44:17 CEST] <JEEB> I had stopped using it before because I had forgotten to back up the drivers for it [23:44:27 CEST] <JEEB> yea [23:44:29 CEST] <JEEB> quite likely [23:44:41 CEST] <rcombs> and having a 32-bit build has always been crucial since they never stopped shipping 32-bit kernels [23:44:57 CEST] <Gramner> make 64-bit a hard requirement on x86, flag every xmm simd function as avx and rm -rf all remaining mmx and sse code. then enjoy the complaints [23:44:59 CEST] <rcombs> meanwhile apple's dropping 32-bit userspace compat in the next macOS [23:45:34 CEST] <rcombs> eh sse's useful enough [23:45:36 CEST] <nevcairiel> apple is not concerned about compatiblity in the slighest [23:45:43 CEST] <rcombs> not everything benefits from avx [23:45:51 CEST] <nevcairiel> they dont care about devs or users in that regard [23:46:20 CEST] <Gramner> code maintainance benefits from not having to have an sse2, an ssse3, and an avx implementation of a bunch of code [23:46:31 CEST] <rcombs> ¯\_(Ä)_/¯ I'll take it [23:46:34 CEST] <Gramner> although yes, that is a bit extreme I guess [23:46:50 CEST] <rcombs> Gramner: I mean not everything needs an avx imp at all [23:46:51 CEST] <nevcairiel> wonder if people might actually wise up to their nonsense if they actually drop x86 entirely and go ARM on desktop or some shit, and suddenly nothing works anymore (or very slowly with translation) [23:47:55 CEST] <Gramner> rcombs: indeed, but it makes everything simpler to have a higher baseline. just flag it avx and forget about if it's ssse3 or sse4.1 [23:48:07 CEST] <rcombs> ¯\_(Ä)_/¯ I guess [23:48:55 CEST] <rcombs> wonder how many of my users would actually regress if I made avx a requirement for all simd [23:49:20 CEST] <Gramner> it's been around since 2011 [23:49:23 CEST] <rcombs> I remember a few people complained when I shipped something that used AVX and checked the AVX-present cpuid flag but not the AVX-OS-supported [23:49:25 CEST] <nevcairiel> i had people complain when i forced sse2 [23:49:27 CEST] <nevcairiel> so yeah [23:49:44 CEST] <rcombs> (which then proceeded to crash) [23:49:49 CEST] <nevcairiel> (2 years ago or so, but i dont expect those weirdos to have changed) [23:49:50 CEST] <jamrial> i know some people really like their sandy bridges and stick to them, but i don't think such thing happens with nehalem or older [23:50:05 CEST] <nevcairiel> sandy at least has avx [23:50:09 CEST] <Gramner> sandy bridge was a super solid µarch [23:50:15 CEST] <jamrial> i know [23:50:17 CEST] <Gramner> still works fine in modern games and whatnot [23:50:45 CEST] <nevcairiel> most people sticking to something much older is either something crazy like Athlon XP or something, or maybe Core2 arch stuff [23:50:51 CEST] <jamrial> so avx minimum would piss off <=nehalem and <= phenom users [23:51:48 CEST] <jamrial> i think phenom 6 core was popular even during the piledriver days [23:52:53 CEST] <atomnuker> I do wish all ISAs had x86 addressing, that would make them suck less [23:52:54 CEST] <nevcairiel> the good ol amd fake cores, where you got 2 with the performance of one :) [23:53:14 CEST] <Gramner> https://store.steampowered.com/hwsurvey/ (which is probably one of the better up-to-date surveys) says ~90% avx support [23:53:31 CEST] <atomnuker> except maybe with more bits for shifts of the second register and the offset could also be a register, that would rock [23:53:47 CEST] <atomnuker> then all your loads would pretty much just be one instruction [23:54:10 CEST] <nevcairiel> I'm just happy we finally managed to roll out 64-bit at work last year, although with people running external third-party plugins and stuff we would never dream to cancel the 32-bit version anytime soon [23:54:32 CEST] <Gramner> evex compressed displacement for constant offsets is also great, should be a thing everywhere [23:54:50 CEST] <rcombs> I'm still mad at MS for ever shipping 32-bit win10 [23:54:50 CEST] <Gramner> e.g. it encodes imm8 as a multiple of the element size, not absolute bytes [23:55:47 CEST] <atomnuker> dunno about that, I'd prefer bytes [23:56:02 CEST] <jamrial> Oculus Rift - 0.20% [23:56:03 CEST] <jamrial> lol vr [23:56:03 CEST] <Gramner> bytes are still supported, just uses 4 bytes instead of one [23:56:42 CEST] <Gramner> just makes more efficient use of the 1-byte offset encoding [23:57:37 CEST] <Gramner> otherwise with zmm registers you'd only have -2, -1, and +1 * mmsize fit in an imm8 [23:58:33 CEST] <exastiken_> Hello! I have been using callgrind with ffmpeg encoding of a YUV to mp4 [23:58:48 CEST] <durandal_1707> and? [23:59:27 CEST] <TD-Linux> the steam survey is biased towards better PCs as well. compare it to the firefox version https://hardware.metrics.mozilla.com/ [23:59:32 CEST] <exastiken_> And I noticed that x265::MotionEstimate::motionEstimate [23:59:43 CEST] <exastiken_> is used heavily during encoding [23:59:48 CEST] <exastiken_> but not by do_encode [23:59:53 CEST] <TD-Linux> (unfortunately the firefox one doesn't collect instruction set data) [00:00:00 CEST] --- Wed May 2 2018

1 0

ffmpeg.log.20180501
by burek 02 May '18

02 May '18

[00:00:09 CEST] <JEEB> is this with latest FFmpeg? [00:00:22 CEST] <JEEB> and what version of libvpx? [00:00:42 CEST] <JEEB> and you get to that error with [00:00:43 CEST] <JEEB> if (ctx->crf < enccfg.rc_min_quantizer || ctx->crf > enccfg.rc_max_quantizer) [00:00:59 CEST] <ovi> true it makes no sens .. [min-max] should be [50-5000] not [5000-50] [00:01:18 CEST] <JEEB> so if your CRF is smaller than minimal quantizer OR CRF is larger than maximum quantizer [00:01:46 CEST] <jkqxz> Have you somehow set qmin to 5000? [00:02:15 CEST] <ovi> i compiled ffmpeg-4.0 from sources [00:02:36 CEST] <ovi> libvpx 1.7.0 [00:02:44 CEST] <jkqxz> Because I can't see any other way to get a crazy value there. [00:02:56 CEST] <JEEB> can you post your full command line with full terminal output in a pastebin-like? [00:02:59 CEST] <JEEB> and link it here [01:18:28 CEST] <oerg866> alright here's the bug [01:18:30 CEST] <oerg866> command line: [01:18:33 CEST] <oerg866> ffmpeg -i a.vob -i a.wav -vcodec copy -an -shortest C:\output\tmp.vob [01:18:42 CEST] <oerg866> er whooops [01:18:44 CEST] <oerg866> wrong command [01:18:50 CEST] <oerg866> ffmpeg -i a.vob -i a.wav -vcodec copy -acodec pcm_s16be -ar 48000 -shortest tmp.vob [01:19:03 CEST] <oerg866> audio duration=213.172122 [01:19:09 CEST] <oerg866> video duration=213.040000 [01:22:16 CEST] <oerg866> I might be mistaken but I'm pretty sure they're supposed to be the same after muxinbg [01:51:04 CEST] <Nkekev> hello [01:51:47 CEST] <Nkekev> I have a little question if someone can help me with my output? [01:53:12 CEST] <Nkekev> I want to encode some video to have the closest format as another one i have to be compatible with a game [01:53:32 CEST] <Nkekev> So thats i get with ffmpeg -i on my source video [01:53:54 CEST] <Nkekev> https://pastebin.com/zFYgndYd [01:54:07 CEST] <Nkekev> what settings should i use to get the same ? [02:36:35 CEST] <Nkekev> zz [02:45:01 CEST] <Exagone313> Hi, I'm trying to compile git version of ffmpeg with --enable-libaom and git version of aom installed, and I get "ERROR: aom >= 0.1.0 not found using pkg-config", although `pkg-config --modversion aom` returns 0.1.0 [02:48:01 CEST] <Nkekev> chat is dead [02:48:39 CEST] <Exagone313> hmm weird /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../lib/libaom.so: undefined reference to `pthread_once' [02:48:46 CEST] <Exagone313> in config.log [02:49:30 CEST] <Exagone313> -pthread is missing [03:14:07 CEST] <Exagone313> ok, it's a bug from aom, -lpthread is not correctly used in their pkg-build file [03:14:18 CEST] <Exagone313> pkg-config* [04:09:51 CEST] <darkdrgn2k> hi all [04:10:11 CEST] <darkdrgn2k> i keep betting "value too large for defined data type" when i try to process a ATSC DVB stream and it exits [04:10:17 CEST] <darkdrgn2k> i alreayd did the cat test and that seem to work [07:37:44 CEST] <oerg866> What's the recommended way to convert NTSC 29.97 progressive to PAL 25 interlaced? [07:49:18 CEST] <kepstin> oerg866: the correct way is to not do it at all, since you often don't have to with modern tvs :/ [07:49:38 CEST] <oerg866> yeah but the end result kinda needs to be in PAL interlaced format for some hobby purposes ;) [07:50:30 CEST] <kepstin> there's no good options. you can drop frames or fields and get judder, blend stuff, do motion-compensated framerate conversion with varying results, :/ [07:52:12 CEST] <oerg866> i found a "decent" way to cvonvert ntsc interlaced to pal interlaced [07:52:24 CEST] <oerg866> ffmpeg -i gf.vob -vf yadif=1,scale=720x576,setdar=4:3,minterpolate='fps=50:mi_mode=blend',tinterlace=5 -vcodec mpeg2video -acodec pcm_s16be -b:v 15000k -flags +ilme+ildct TEST.mpeg [07:52:38 CEST] <oerg866> it's not perfect but good enough for my purposes [07:52:51 CEST] <oerg866> the material is going to be recorded to VHS so the quality difference matters very little :P [07:52:58 CEST] <furq> that seems way overcomplicated [07:53:13 CEST] <oerg866> well I'd love to hear a less complicated way [07:53:19 CEST] <furq> i'm pretty sure you could just use -vf scale=720:576:interl=1,fps=25 [07:53:22 CEST] Action: kepstin notes that 720x576 isn't 4:3 dar, although it's close. [07:53:38 CEST] <furq> you might need to setsar as well, i don't really know [07:53:40 CEST] <kepstin> furq: that'll give you some pretty nasty judder, i'd think. [07:53:45 CEST] <oerg866> no, setdar is good enough [07:53:55 CEST] <oerg866> furq that will not work [07:54:01 CEST] <oerg866> it will scale to 720x576 with all interlace artifacts [07:54:23 CEST] <kepstin> oerg866: that does an interlaced scale (scale each field separately) [07:54:35 CEST] <oerg866> does it? [07:54:36 CEST] <oerg866> let me try [07:54:52 CEST] <furq> yeah scale=interl is interlacing-aware [07:55:18 CEST] <furq> that'll basically just drop every sixth frame so it's still going to be a bit juddery [07:55:19 CEST] <kepstin> but yeah, setsar and setdar conflict with eachother; using one after the other means the second will overwrite the results of the first. [07:55:39 CEST] <furq> but it should be ok-looking and way faster than using minterpolate [07:55:41 CEST] <oerg866> it does look quite jerky [07:55:56 CEST] <oerg866> minterpolate is not slow at all when using blend mode [07:55:59 CEST] <oerg866> which I'm using [07:56:02 CEST] <kepstin> setsar calculates a new dar from the provided sar and the frame size [07:56:06 CEST] <oerg866> but yeah your methid is way too jerky for my taste [07:56:09 CEST] <kepstin> setdar calculates a new sar from the provided sar and the frame size [07:56:17 CEST] <kepstin> setdar calculates a new sar from the provided dar and the frame size* [07:56:40 CEST] <oerg866> it makes my content display at the aspect ratio I want [07:57:20 CEST] <oerg866> I've done VHS digitzation with intent to upload to youtube at 720p50 by converting it to 720x720 and giving it setdar=4:3 [07:57:32 CEST] <furq> fwiw you can use yadif on field-based content [07:57:32 CEST] <oerg866> gives you more quality per bitrate [07:57:39 CEST] <furq> so that method should still work on 29.97p [07:57:43 CEST] <furq> er, frame-based [07:57:51 CEST] <furq> idk if it'll give good results [07:58:03 CEST] <furq> i can't immediately think of anything else that isn't even hackier [07:58:44 CEST] <kepstin> old analog video standards are weird, for pal 4:3 content you probably want setsar=16/15 [07:59:06 CEST] <kepstin> the 720-sample per line video include stuff past the edges of the picture on either side [07:59:42 CEST] <kepstin> that said, depending how you're outputting this for the tape recording, it's probably not that important. [08:00:45 CEST] <kepstin> hmm, i'm not even sure I got the right value there. I don't touch pal stuff much :) [08:00:49 CEST] <furq> yeah [08:00:59 CEST] <furq> it's 16:15 for 720*576 and 12:11 for 704*576 [08:01:07 CEST] <furq> for fullscreen obviously [08:01:09 CEST] <kepstin> 12:11 looks right, yeah [08:03:01 CEST] <oerg866> this is seriously messing with my head and I haven't slept yet [08:03:07 CEST] <oerg866> i'll mess with this later, thanks for the pointers [08:09:27 CEST] <furq> i'm sort of wondering how studios dealt with this now [08:10:00 CEST] <furq> at least ntsc to pal interlaced, which definitely happened a lot [08:10:03 CEST] <kepstin> tv studios or movie studios? :) [08:10:06 CEST] <furq> tv studios [08:10:09 CEST] <furq> i know how movie studios did it [08:10:49 CEST] <kepstin> a lot of the pal->ntsc conversions I've seen have nasty blended fields and can't be cleanly deinterlaced. [08:11:09 CEST] <kepstin> (you get some ghosting on the intermediate frames) [08:11:27 CEST] <furq> actually i guess most of the american sitcoms i'm thinking of were shot on film [08:11:52 CEST] <furq> there probably wasn't actually that much that was shot on video that made it over here [08:11:59 CEST] <furq> certainly not much i'd have been watching [08:13:26 CEST] <kepstin> I should try to find some recent north american releases of some bbc shows or something, check how they did that. [08:14:03 CEST] <furq> well not too recent or it'll be progressive [08:15:03 CEST] <kepstin> hm, still could be interesting to see how they handled the 25p to 24p (or 30p?) conversion. But I might have to go look for some dvds instead to find interlaced stuff :) [08:16:19 CEST] <furq> i think i actually have a bootleg region 1 dvd of a bbc show shot on video somewhere [08:16:22 CEST] <furq> i should dig that out [08:16:38 CEST] <furq> bootleg as in a copy of an official release [09:06:35 CEST] <oerg866> furq / kepstin well the thing is [09:06:55 CEST] <oerg866> a lot of music videos of stuff that wasn't really popular in europe [09:07:04 CEST] <oerg866> or american bands to begin with [09:07:23 CEST] <oerg866> you know you can watch VH1 classic which is an USA NTSC station here in Germany's major cable networks in PAL [09:07:25 CEST] <oerg866> i just wonder how they do it [09:07:43 CEST] <oerg866> i also have some recordings of 80s music shows from german television [09:07:48 CEST] <oerg866> that showed some american videos [09:07:53 CEST] <oerg866> even back then the technology was there! but how??? [09:25:28 CEST] <furq> oerg866: i did find a bunch of avisynth scripts that supposedly do this [09:25:42 CEST] <furq> there's at least one on the wiki and a bunch in forums [09:25:48 CEST] <furq> you could probably port those to lavfi pretty easily [09:27:17 CEST] <furq> they're pretty much doing deinterlace, resize, change fps, separate fields, select first and fourth field of every four, weave [09:27:30 CEST] <furq> but using convertfps which interpolates frames together [09:30:37 CEST] <AlecTaylor> hi [09:31:08 CEST] <AlecTaylor> Speeding up a video using ffmpeg, but the result has no audio track, how to fix? - `ffmpeg -i myvideo.mov -vf "setpts=0.78*PTS" -an /tmp/speedy.mov` [09:31:57 CEST] Action: AlecTaylor notes video is h264 and audio is 2channel aac [09:32:49 CEST] <furq> AlecTaylor: -an removes the audio track [09:33:44 CEST] <furq> also you probably want to add -af "atempo=1/0.78" [09:33:48 CEST] <furq> otherwise the audio will be out of sync [09:37:04 CEST] <AlecTaylor> Perfect, thanks furq [09:38:53 CEST] <durandal_1707> furq: all those filter are already in lavfi [09:38:59 CEST] <furq> yeah, i said that [09:39:10 CEST] <furq> i meant he could port the script, not the filters [09:40:04 CEST] <oerg866> interestingly enough [09:40:40 CEST] <oerg866> furq: adobe premiere's way of doing things looks a bit like how I saw it on the old TV recordings of NTSC material on PAL channels [09:40:45 CEST] <oerg866> it looks quite nice actually [09:41:24 CEST] <oerg866> it's probably doing it in some industry standard way [09:42:27 CEST] <oerg866> now if only the process of doing that on adobe premiere was scriptable :-) [09:42:32 CEST] <durandal_1707> oerg866: what you want to do? I missed previous log [09:42:41 CEST] <furq> durandal_1707: ntsc interlaced to pal interlaced [09:43:09 CEST] <oerg866> I've got some NTSC 720x480 29.97 interlaced music videos i'd like to convert to PAL 720x576 25.00 interlaced [09:43:10 CEST] <furq> or uh [09:43:14 CEST] <furq> ntsc progressive wasn't it [09:43:22 CEST] <oerg866> that was a specific subset of my question [09:43:26 CEST] <furq> fair enough [09:43:33 CEST] <oerg866> some of the videos are progressive to begin with and thus fairly straightforward [09:43:34 CEST] <furq> i don't suppose it makes too much difference [09:43:49 CEST] <oerg866> since the framerate is higher it makes sense to interpolate to 50 and then interlace it [09:44:00 CEST] <oerg866> gets a higher perceived framerate I suppose [09:44:01 CEST] <furq> if it's not telecined then it's probably equally awkward either way [09:44:16 CEST] <oerg866> Well the problem with telecined is the following [09:44:25 CEST] <oerg866> yes most material is shot on film in 23.976 or whatever [09:44:38 CEST] <oerg866> but the cuts and fades are NOT cleanly done on original frames [09:44:51 CEST] <oerg866> like you'd have fades that are inbetween two "film frames" [09:44:54 CEST] <oerg866> or cuts [09:45:07 CEST] <oerg866> so you'd have one frame of NASTY interlace artifacts in your inverse telecined videos [09:45:17 CEST] <furq> yeah that's just a general ivtc issue though [09:45:28 CEST] <oerg866> still nasty to look at [09:45:30 CEST] <furq> sure [09:45:36 CEST] <oerg866> and the next issue is for PAL playback you'd usually just speed the ~24 to 25 [09:45:54 CEST] <oerg866> since this is music the pitch change is rather annoying and noticable and I don't like pitch correctors, they sound so mechanical [09:46:11 CEST] <oerg866> (and the speed being off knowing how the song sounds like in the original still annoys me) [09:46:25 CEST] <furq> i take it this isn't telecined anyway [09:46:36 CEST] <oerg866> a lot of it actually is [09:46:42 CEST] <oerg866> but as I said, the cuts :-/ [09:46:52 CEST] <furq> true [09:47:04 CEST] <furq> there is some ridiculous pulldown method for film to pal that avoids the speedup [09:47:15 CEST] <furq> but if your issue is with the ivtc bit then that doesn't help [09:47:15 CEST] <oerg866> yeah the euro pulldown [09:47:20 CEST] <oerg866> 12 progressive, 13 interlaced frames [09:47:21 CEST] <oerg866> :D [09:48:01 CEST] <furq> good old 2:2:2:2:2:2:2:2:2:2:2:3 pulldown [09:48:09 CEST] <oerg866> XD [09:48:41 CEST] <oerg866> i dunno did the guy who invented that just think "oh I know, I'm going to fuck with peoples' heads real hard 8)" [09:49:06 CEST] <furq> it's specifically to avoid the pitch change i think [09:49:13 CEST] <furq> there's no other good reason for it [09:49:41 CEST] <oerg866> yeah I know the motive makes good sense [09:50:11 CEST] <oerg866> but it didnt hold up too well since most film -> PAL stuff is just sped up to 25 :P [09:51:05 CEST] <oerg866> OH yeah another issue with inverse telecine [09:51:09 CEST] <oerg866> with mpeg2 stuff [09:51:29 CEST] <oerg866> you're going to see interlace artifacts where the compression artifacts were in the individual fields :-D [09:52:07 CEST] <furq> i think it's fairly common to use a proper deinterlacer in an ivtc pipeline nowadays [09:53:01 CEST] <oerg866> probably [09:53:19 CEST] <furq> i've definitely seen people using qtgmc after decimating [09:53:26 CEST] <furq> but that's not going to be quick [09:53:35 CEST] <oerg866> I really want to see what qtgmc looks like [09:53:44 CEST] <oerg866> unfortunately I lack the will power to get into avisynth [09:53:53 CEST] <furq> you can use it with vapoursynth these days [09:54:02 CEST] <oerg866> I have no idea what that is :-( [09:54:13 CEST] <furq> it's cross-platform avisynth with multithreading that isn't fucked [09:54:27 CEST] <furq> it's not really much easier to set up or script though [09:54:34 CEST] <furq> especially on windows [09:54:45 CEST] <oerg866> I don't know man, I was pretty content with yadif so far [09:54:56 CEST] <oerg866> I'd love to use it in my VHS digitzation projects if it's actually a noticable improvement [09:55:08 CEST] <furq> well if you're using it after decimating then you'd be using it in progressive mode [09:55:23 CEST] <oerg866> yeah no I meant like in general [09:55:29 CEST] <furq> which just tries to clean up interlacing artifacts in progressive video [09:55:36 CEST] <furq> it's an absolute godsend lol [09:55:46 CEST] <oerg866> aaaaah now that makes more sense to my head [09:55:50 CEST] <oerg866> yeah that's probably a good idea actually [09:56:02 CEST] <oerg866> jeez why didn't I think of that before ._. [09:56:11 CEST] <furq> there's not really any other filter i know of that does that [09:56:24 CEST] <furq> that's pretty much the only thing i use vs for [09:56:38 CEST] <furq> also yeah qtgmc is slower than shit [09:56:52 CEST] <oerg866> I've got about 50 VHS tapes full of music shows from 1984 until 1989... I need to figure out a nice pipeline for that [09:57:09 CEST] <oerg866> digitizing those [09:58:04 CEST] <oerg866> most definitely gonna have to use avisynth or that replacement you just mentioned for that [09:58:11 CEST] <oerg866> need to fix chroma shifts etc [09:58:24 CEST] <furq> i would definitely use vs over avs if you're planning on looking at qtgmc [09:58:42 CEST] <furq> i tried avisynthmt and it just kept crashing on me like 5+ hours into an encode [09:58:53 CEST] <oerg866> yeah i've heard it was an absolute hackjob [09:59:04 CEST] <furq> vs is a little bit slower but it's been totally stable for me [09:59:11 CEST] <furq> and most good stuff is ported [09:59:58 CEST] <furq> it still has the same fundamental problem as avs though, which is that package management is "trawl through doom9 forums" [10:00:48 CEST] <oerg866> :D [10:00:48 CEST] <durandal_1707> furq: what's so special about qtgmc? [10:01:05 CEST] <furq> the progressive mode is the most special thing [10:01:17 CEST] <furq> as an actual deinterlacer it's just good quality [10:01:23 CEST] <oerg866> ahhhhhhh I remember now why I gave up on the digitization last time [10:01:26 CEST] <oerg866> https://i.snag.gy/a2gLIE.jpg [10:01:31 CEST] <oerg866> I couldn'T figure out how to denoise this episode [10:01:39 CEST] <oerg866> which was recorded off a different station off antenna [10:01:39 CEST] <furq> but it does a really good job of repairing interlacing artifacts in progressive frames [10:01:49 CEST] <furq> which i have a lot of because bbc dvds are terribly produced [10:01:58 CEST] <oerg866> all denoisers work horizontally and vertically, but analog video is line based . . . [10:03:19 CEST] <furq> but yeah i'm not going to pretend i know what qtgmc does that lavfi nnedi doesn't [10:03:33 CEST] <furq> i just know it looks better than yadif/bwdif on sd mpeg2 [10:03:36 CEST] <furq> and i have a lot of that [10:04:27 CEST] <oerg866> would you say it looks better than yadif if the source material hasnt been lossily compressed? [10:04:35 CEST] <oerg866> i.e. capture card -> lagarith -> deinterlacer [10:04:39 CEST] <furq> probably not [10:04:56 CEST] <furq> i don't really know how fields are stored on vhs [10:05:14 CEST] <oerg866> well pretty much the same as on any other interlaced source [10:05:18 CEST] <furq> if you get bleeding between fields then maybe [10:05:22 CEST] <oerg866> bottom field first, PAL timing [10:05:34 CEST] <oerg866> nah, the fields are stored cleanly after one another [10:05:46 CEST] <furq> yeah it probably won't make much difference then [10:06:00 CEST] <furq> nnedi is a better upscaler than whatever yadif uses, but it's not going to be a big enough difference to be worth how slow it is [10:06:59 CEST] <durandal_1707> nnedi is for anime fans [10:07:10 CEST] <oerg866> that's quite specific :D [10:07:47 CEST] <furq> https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_nnedi.c#L3 [10:07:48 CEST] <furq> wait a minute... [10:11:28 CEST] <oerg866> hm? [10:11:34 CEST] <durandal_1707> you need motion compesated/adaptive bob filter [10:26:49 CEST] <oerg866> ugh this whole chain disgusts me [10:26:58 CEST] <oerg866> >British band, PAL material [10:27:09 CEST] <oerg866> >only DVD releases are NTSC [10:27:23 CEST] <oerg866> >i convert it back to PAL for my own purposes [10:27:30 CEST] <oerg866> the world has gone crazy! [13:11:46 CEST] <GamleGaz> Hey, do I need to decode audio before resampling it, or can svresample handle encoded audio? [13:59:41 CEST] <Freneticks> I trying to -c copy a stream and my writing speed is 0.1x any idea where it came from, slow network ? [14:16:03 CEST] <kerio> oerg866: the worst part is that you're converting to PAL for some reason [15:37:55 CEST] <Zgrokl> hi any help on my stream copy problem ? [15:55:03 CEST] <relaxed> Zgrokl: what is the problem? [15:55:25 CEST] <Zgrokl> i ffmpeg -i (youtube-dl -g url) -c copy stream.ts [15:55:36 CEST] <Zgrokl> but writespeed is 0.123 relaxed [15:56:13 CEST] <Zgrokl> I just want to copy with normal speed without reencoding [16:21:47 CEST] <relaxed> pastebin.com ffmpeg's output [16:42:17 CEST] <romano2k_> hi there! i'm trying to convert a burst of images into a x264 video, but somehow i get a very high bitrate, i don't understand why [16:42:34 CEST] <romano2k_> ffmpeg -framerate 10 -start_number 0 -pattern_type glob -i '*.jpg' -filter:v "scale=3840:2880,crop=3840:2160,format=yuv420p" -codec:v libx264 -crf 20 output.mp4 [16:42:39 CEST] <romano2k_> any idea what's wrong? [16:44:30 CEST] <romano2k_> here is the result: https://pastebin.com/ycCifjSf [16:48:57 CEST] <nille02> Hello everyone, i got a small problem with ffmpeg while configure. [16:48:58 CEST] <nille02> ERROR: x265 not found using pkg-config [16:49:19 CEST] <nille02> it is there and this is the config.log https://www.dropbox.com/s/5z1te12vtlqoghz/config.log?dl=0 [16:52:42 CEST] <c_14> are you cross compiling? [16:56:05 CEST] <nille02> yes [16:56:05 CEST] <c_14> nille02: what version of x265 is that? [16:56:21 CEST] <c_14> git head? [16:56:25 CEST] <nille02> git head [16:57:23 CEST] <nille02> hg head [16:57:26 CEST] <c_14> well, mercurial but w/e [16:58:04 CEST] <c_14> Your x265.h lists bool bEnableavx512 but the current hg source has int bEnableavx512 [16:58:07 CEST] <nille02> and about compiling i use a mysy2 enviroment [16:58:15 CEST] <c_14> and I can't find a version in which it's bool [16:58:41 CEST] <c_14> wait [16:58:57 CEST] <c_14> ok, looks like it was the latest commit [16:59:13 CEST] <c_14> anyways, they're using bool without including stdbool.h [16:59:17 CEST] <c_14> so it's a bug on their end [16:59:25 CEST] <c_14> use an older x265 version [16:59:39 CEST] <nille02> ok i try it. thank you [17:02:51 CEST] <c_14> It works for the x265 internal stuff because that's C++ but when you include the file in C bool isn't a recognized type without stdbool.h [17:33:12 CEST] <nille02> c_14 thank you, its build again. i switched to the default branch [17:47:57 CEST] <Nethe> Hi :) I'm facing problems when creating multicast with multiple streams from one source (live source). The issue is that the encoding is slower than realtime. That is big issue for me as I'm processing live feed. The exact command and it's output you can find here: https://pastebin.blesmrt.net/p4bw0pmqm/vpacnu [17:54:30 CEST] <oerg866> <kerio> oerg866: the worst part is that you're converting to PAL for some reason [17:54:37 CEST] <oerg866> I live in a PAL region :) [17:54:40 CEST] <kerio> it's 2018 [17:55:11 CEST] <oerg866> oh really, einstein [18:57:49 CEST] <wallnut> hello! I want to re-encode a video from h264 to h265 but the colors in the result are always washed out, the blacks are almost grays. ffprobe says this about the source: "Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc), 1920x1080, 5456 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)", is this a problem with color range (since it's yuv*J*420p)? what could I try in order to keep the color quality? thanks. [19:01:12 CEST] <JEEB> wallnut: yea it sounds like something in the chain is forgetting about the PC flag [19:01:20 CEST] <JEEB> (see the (pc) after the pix_fmt) [19:05:21 CEST] <wallnut> yes, the output gets a "tv" instead of "pc" there, any pointer on what to try? [19:07:35 CEST] <durandal_1707> wallnut: are you doing filtering by any chance? [19:10:01 CEST] <wallnut> no, i'm just doing this: ffmpeg -i "input.mp4" -c:v libx265 -c:a copy "output.mp4" [19:10:48 CEST] <wallnut> ffmpeg warns "deprecated pixel format used, make sure you did set range correctly" and then the output is "Video: hevc (Main) (hev1 / 0x31766568), yuv420p(tv, progressive), 1920x1080, 1358 kb/s, 25 fps, 25 tbr, 12800 tbn, 25 tbc (default)" [19:11:17 CEST] <wallnut> i tried fiddling with -color_range and -pix_fmt but nothing seemed to change (for the better or for the worse) [19:14:00 CEST] <JEEB> wonder if that thing is plugged anywhere in the x265 wrapper [19:14:37 CEST] <wallnut> i also tried -x265-params range=full, is that what you're talking about? [19:15:11 CEST] <JEEB> if libx265 takes it like that, then that should pass things into libx265 as-is [19:15:31 CEST] <JEEB> x265-params just passes key=value pairs to libx265 itself [19:16:40 CEST] <jkqxz> You could fix it up after the encode by adding -bsf:v hevc_metadata=video_full_range_flag=1 [19:17:14 CEST] <JEEB> ok, seems like libx265 wrapper has nothing related to range [19:17:36 CEST] <durandal_1707> that is bad [19:18:07 CEST] <durandal_1707> does it support different ranges at all? [19:18:53 CEST] <JEEB> I think libx265 itself does, the wrapper only takes in non-J pix_fmts and has no "range" string in it [19:19:26 CEST] <durandal_1707> ugh, that means that it will be probably converted to limited range [19:19:44 CEST] <JEEB> yes, which thankfully now is borked so mos tlikely the only thing changing is the pix_fmt and range flag :D [19:19:56 CEST] <JEEB> which is why the content doesn't look right [19:21:00 CEST] <durandal_1707> code is stupid, yuvj formats when converted to yuv are converted to limited [19:21:30 CEST] <durandal_1707> i wanted to fix this crap, but michaelni did not helped at all [19:21:37 CEST] <atomnuker> you fixed it damn it! [19:21:52 CEST] <atomnuker> you just didn't resend your patchset and left it rotting [19:25:15 CEST] <wallnut> jkqxz: i just tried that, no difference, did i do it right? just add -bsf:v ... with the other params [19:27:35 CEST] <jkqxz> At the end, yeah. It won't work if some other conversion is happening in the middle, though, and it sounds like that's the case. [19:29:03 CEST] <wallnut> aw :( [19:29:34 CEST] <jkqxz> (It's just marking the metadata on the stream to say it's full range, if something else has messed that up then it doesn't help.) [19:29:55 CEST] <JEEB> yea, you use it with -c copy after the encode [19:30:00 CEST] <JEEB> not during the encode [19:31:02 CEST] <wallnut> yup, i tried that too [19:31:33 CEST] <wallnut> is there anything i can do to help fix it? [19:32:07 CEST] <JEEB> I would double-check the libx265 API key=value for full (pc) range [19:32:13 CEST] <JEEB> and then just use x265-params [19:32:54 CEST] <jkqxz> Seems like it should be 'range=full'. [19:33:05 CEST] <jkqxz> From the source. Dunno if that actually works. [19:33:55 CEST] <JEEB> and then ffprobe -v verbose FILE'ing the generated file probably would then show it if the flag got applied [19:34:00 CEST] <wallnut> i've seen mentions of it working: https://stackoverflow.com/a/47901085 [19:34:12 CEST] <wallnut> okay, let me try [19:42:58 CEST] <wallnut> 'range=full' seems to be at least doing something: ffprobe of the output changes from "yuv420p(tv, progressive)" to "yuvj420p(pc, progressive)" [19:43:13 CEST] <JEEB> yup [19:43:17 CEST] <JEEB> so it is flagging the output stream [19:43:26 CEST] <JEEB> now you just need to use a player that handles full range correctly [19:43:28 CEST] <JEEB> most do not [19:43:31 CEST] <JEEB> unfortunately [19:43:39 CEST] <JEEB> try out mpv for example [19:44:09 CEST] <wallnut> hmm, would ffplay be ok? [19:44:35 CEST] <JEEB> not sure :D [19:44:41 CEST] <JEEB> it's a proof of concept thing [19:48:14 CEST] <wallnut> okay, i tried with mpv, colors still washed out in output [19:48:31 CEST] <JEEB> :< hopefully that was with the opengl-based rendering [19:48:43 CEST] <JEEB> but yea, that means something is playing with the values too [19:48:46 CEST] <wallnut> well, i don't know if it's relevant but i'm on windows [19:48:50 CEST] <JEEB> is the input RGB or...? [19:49:34 CEST] <wallnut> i... don't really know, it's a video from a camera that somebody sometime converted with ffmpeg probably [19:50:29 CEST] <JEEB> what does ffprobe -v verbose say about the input? [19:51:26 CEST] <wallnut> Video: h264 (High), 1 reference frame (avc1 / 0x31637661), yuvj420p(pc, left), 1920x1080 (1920x1088), 5456 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default) [19:51:48 CEST] <JEEB> ok, so no additional colorimetry info [19:52:20 CEST] <wallnut> i can cut a couple of seconds and share the file if you want, it has no copyright or anything [19:57:53 CEST] <wallnut> i was using 4.0, i just tried with a build from a couple days ago, same result [20:06:18 CEST] <wallnut> should i open a bug? [20:44:13 CEST] <durandal_1707> wallnut: if you can [21:00:31 CEST] <wallnut> sure, i will [21:08:09 CEST] <oerg866> is there a way in ffprobe to only output a certain information [21:08:12 CEST] <oerg866> i.e. stream duration? [21:12:54 CEST] <JEEB> I would recommend using the json output and using -show_streams or so [21:13:05 CEST] <JEEB> that way you can parse things relatively easily [21:13:09 CEST] <kepstin> oerg866: yes, see the -show_entries option [21:13:14 CEST] <JEEB> with any modern language [21:13:19 CEST] <JEEB> and yes, short_entries limiting works too [21:14:06 CEST] <oerg866> i don't intend to do fancy processing; I just want the video length so i can make the audio that exact length [21:14:20 CEST] <oerg866> because -shortest is buggy and just doesn't do what it says ._. [21:15:38 CEST] <kerio> -of csv=p=0 [21:16:56 CEST] <wallnut> um, if i encode directly to h265 without any special parameters, mpv *does* show correctly the colors [21:17:11 CEST] <wallnut> does this mean it's a player problem and not ffmpeg's? [21:18:17 CEST] <durandal_1707> no, post full uncut ffmpeg command [21:18:59 CEST] <oerg866> dayum kerio you're a saint [21:19:00 CEST] <oerg866> thanks [21:19:13 CEST] <wallnut> ffmpeg -i input.mp4 -c:v libx265 -an output.mp4 [21:19:28 CEST] <durandal_1707> command that does not work? [21:21:09 CEST] <wallnut> ffmpeg -i input.mp4 -c:v libx265 -x265-params range=full -an output.mp4 [21:23:59 CEST] <wallnut> first command shows washed out colors in vlc and mpc-hc (both windows) but correct in mpv [21:24:13 CEST] <wallnut> although input.mp4 has correct colors in vlc and mpc-hc [21:24:56 CEST] <wallnut> i was creating the bug and wanted to write about what i tried, but now i'm a little confused :P [21:25:15 CEST] <durandal_1707> wallnut: vlc and others support only limited range [21:25:37 CEST] <durandal_1707> so convert range with scale filter, from full to limited [21:26:15 CEST] <wallnut> i don't have enough knowledge to refute that information, but if vlc and others show full range correctly with source video, doesn't that mean they support it? [21:30:20 CEST] <wallnut> from my limited user perspective if a video has full range in h264 and i encode it to h265 without any other changes, it still should be full range, shouldn't it? [21:30:27 CEST] <wallnut> i'm probably wrong but i don't understand why [21:31:07 CEST] <JEEB> if all things go right, it should go through (or if there's a range conversion, it should be done correctly) [21:31:22 CEST] <JEEB> at this point I've no idea and I didn't nor do I currently have the time to test your issue out [21:32:04 CEST] <JEEB> before in the history the swscale library didn't have range correctly so your full range stuff was likely to lose its marking but still stay the same [21:32:13 CEST] <JEEB> oh, and this is expecting that the video encoder is OK [21:53:41 CEST] <wallnut> i think durandal_1707 's advice about the scale filter did the trick [21:54:11 CEST] <wallnut> for this command `ffmpeg -i input.mp4 -an -c:v libx265 -vf "scale=in_range=X:out_range=Y" output.mp4` i got these results [21:54:17 CEST] <wallnut> X=full, Y=full => colors OK X=full, Y=limited => colors washed out X=limited, Y=full => colors OK X=limited, Y=limited => colors OK [21:55:27 CEST] <wallnut> "OK" output files are binary identical [21:58:12 CEST] <oerg866> hey by the way, ffmpeg still says 2017 :D [21:58:15 CEST] <oerg866> in the copyright :D [21:59:17 CEST] <durandal_1707> oerg866: you are using old binary [21:59:30 CEST] <durandal_1707> here it says 2018 [22:01:36 CEST] <oerg866> oh whoops, my %path% was pointing to a folder that had an old version in it [22:01:40 CEST] <oerg866> my bad :d [22:21:29 CEST] <alexpigment> hey guys. i was encoding some videos to blu-ray and i came across a 720p30 video (i hate people who convert 720p60 to 720p30 by the way) [22:21:55 CEST] <alexpigment> tried to use the x264 param "pulldown=double" but ffmpeg doesn't think it's a valid one [22:22:04 CEST] <alexpigment> does anyone know if this was deprecated? [22:22:56 CEST] <alexpigment> i suppose i could just encode to 720p60 and call it a day, but the pulldown method should shorten the encode time considerably [22:22:59 CEST] <JEEB> I would almost recommend scanning x264's code base quickly for it [22:23:46 CEST] <JEEB> < durandal_1707> i'm not gonna do it, its hard, and i can not test [22:23:49 CEST] <JEEB> asdf [22:23:52 CEST] <JEEB> copypasta fail [22:23:58 CEST] <JEEB> static const char * const pulldown_names[] = { "none", "22", "32", "64", "double", "triple", "euro", 0 }; [22:24:06 CEST] <JEEB> so yes, x264.c has it [22:24:49 CEST] <JEEB> and that is for OPT_PULLDOWN which has its string option as { "pulldown", required_argument, NULL, OPT_PULLDOWN } [22:25:15 CEST] <alexpigment> so in theory :pulldown=double: in a string of other args should work, right? [22:26:16 CEST] <JEEB> ah, it might be that the string is limited to cli [22:26:24 CEST] <JEEB> not 100% sure though [22:26:32 CEST] <JEEB> never tried to actually set that thing :P [22:26:57 CEST] <JEEB> but it should be rather simple to encode a few frames and see [22:27:35 CEST] <alexpigment> oh weird, i figured it out [22:27:36 CEST] <JEEB> although it probably will need cfr mode as well on the encoder side [22:27:59 CEST] <alexpigment> so i was using some older scripts that had "x264opts" [22:28:14 CEST] <alexpigment> i've really never come across a reason to need x264-params [22:28:16 CEST] <alexpigment> until just now [22:28:20 CEST] <alexpigment> changing it to that fixed it [22:28:48 CEST] <alexpigment> seems like a bug, but probably one that no one cares to fix since it's considered legacy syntax at this point [22:29:15 CEST] <JEEB> x264-params uses a newer way of reading key=value pairs which doesn't support hacks like not having the value at all [22:29:25 CEST] <JEEB> while x264opts has an old homebrew parsing thing [22:29:50 CEST] <alexpigment> yeah, maybe i need to make sure everything also has a value while i'm at it [22:30:08 CEST] <JEEB> I tried to remove x264opts at one point, but then basically got told that people wanted to be able to set booleans without a value [22:30:20 CEST] <JEEB> I don't remember the exact discussion, it was a while ago [22:30:42 CEST] <alexpigment> oh yeah, i've got a handful of options in here wih no values (force-cfr, open-gop, no-scenecut) [22:31:05 CEST] <alexpigment> i guess it's just safe to put =1 on all of them? [22:31:10 CEST] <JEEB> yes [22:31:26 CEST] <JEEB> also fun if those got set because then someone actually implemented that hack :P [22:33:19 CEST] <alexpigment> i mean it seems weird to get rid of the hack [22:33:37 CEST] <alexpigment> like it's an efficient way to write a command [22:33:50 CEST] <JEEB> a completely different person wrote a general key-value thing for the whole of FFmpeg [22:33:57 CEST] <JEEB> or well, Libav maybe since it originates there probably [22:34:12 CEST] <JEEB> but that person did not think of that as a requirement [22:34:12 CEST] <alexpigment> anyway, i just noticed that my encoding didn't fail, but it does say it can't understand pulldown double. it's just a warning now with params, vs a failure with opts [22:34:23 CEST] <alexpigment> maybe i need to update ffmpeg [22:34:39 CEST] <JEEB> then new features just got written with the built-in dictionary parser [22:35:12 CEST] <JEEB> if that "doesn't understand" comes from libx264 itself then it's just an incorrect thing [22:35:15 CEST] <JEEB> lessee [22:35:55 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/libx264.c;h=12379… [22:36:10 CEST] <JEEB> so if you get that warning, then x264 told FFmpeg that it no habla espanol [22:38:34 CEST] <alexpigment> yeah that's the one [22:38:46 CEST] <alexpigment> so basically pulldown=double is broken [22:39:55 CEST] <alexpigment> i wonder if 22 is the same as pulldown [22:40:10 CEST] <alexpigment> er, the same as double [22:41:02 CEST] <JEEB> ah, fun [22:41:11 CEST] <JEEB> all of the API options are defined in common/base.c [22:41:12 CEST] <JEEB> http://git.videolan.org/?p=x264.git;a=blob;f=common/base.c;h=a07d9c6b84d24a… [22:41:46 CEST] <alexpigment> none of the other pulldown options work either [22:42:00 CEST] <JEEB> so like it seemed with reading x264.c, it actually only works if you set the values to the struct [22:42:48 CEST] <alexpigment> that last statement was above my understanding [22:43:12 CEST] <JEEB> as in, currently it needs actual code plumbing specifically for those values [22:43:26 CEST] <JEEB> or adding pulldown as an API option [22:43:30 CEST] <JEEB> in x264 [22:44:09 CEST] <alexpigment> ah [22:44:35 CEST] <alexpigment> so there's no way to work around it as far as you can see, right? [22:44:54 CEST] <alexpigment> if so, i'll just go ahead and change fps to 60000/1001 [22:46:45 CEST] <JEEB> yea, it currently doesn't have an option in libx264.c on FFmpeg's side, and the string-based things don't have the logic there is in x264.c [22:46:50 CEST] <JEEB> http://git.videolan.org/?p=x264.git;a=blob;f=x264.c;h=7688b60d733bec00a9ef8… [22:47:01 CEST] <JEEB> that's what the cli does [22:49:44 CEST] <alexpigment> well, i'm over here just doing 60 for now [22:49:49 CEST] <alexpigment> thanks for looking into that and confirming [22:50:17 CEST] <alexpigment> ffmpeg is saying "Over 1000 frames duplicated", and i'm like "good, keep doing that" [22:52:43 CEST] <JEEB> do it in the fps filter and it will not do that I think? :D [23:13:14 CEST] <leewdch> can I make a video out of two frames making them 4 seconds long each? [23:41:18 CEST] <kepstin> leewdch: a lot of container formats can't handle representing the duration of the last frame [23:41:29 CEST] <kepstin> leewdch: that said, it should be ok if you have 8 seconds of audio [23:42:27 CEST] <leewdch> how can that help me? [23:43:07 CEST] <kepstin> a video player will hold the last frame in the video until the audio finishes, typically [23:43:45 CEST] <kepstin> so if you have a video track with a frame at t=0, a frame at t=4, and an audio track that's 8s long, the playback will show the first frame for 4s, and the second frame for 4s. [23:46:47 CEST] <leewdch> cant I just make a 8 seconds long silent audio and pipe it? [23:47:10 CEST] <kepstin> ffmpeg can generate silent audio in a filter, no need for external processes [00:00:00 CEST] --- Wed May 2 2018

1 0