Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

August 2018

1 participants
60 discussions

ffmpeg-devel.log.20180830
by burek 31 Aug '18

31 Aug '18

[06:44:04 CEST] <gagandeepsingh> finally quiz in university over, going to update the patches [10:01:57 CEST] <cone-385> ffmpeg 03Raphael Graf 07master:a3c6b7ff5903: frei0r: handle string params [11:48:34 CEST] <durandal_1707> anybody compared av1 with xvc? [12:05:25 CEST] <cone-385> ffmpeg 03Paul B Mahol 07master:ca079b095499: avcodec/get_bits: add cached bitstream reader [12:05:26 CEST] <cone-385> ffmpeg 03Paul B Mahol 07master:042fc12344d6: doc/libav-merge: bitstream reader is now merged [12:05:27 CEST] <cone-385> ffmpeg 03Paul B Mahol 07master:562f00ed0720: avcodec/utvideodec: use cached bitstream reader everywhere except on x86_32 [13:20:52 CEST] <durandal_1707> -300 scpr version 3, now at ~2111, need to be less than 1000 [13:34:46 CEST] <TekniQue> I was looking at this ticket, and I tried out the patch someone submitted, that almost worked, needed one little change to really work properly https://trac.ffmpeg.org/ticket/5419 [13:36:14 CEST] <TekniQue> I'm wondering by what route it's best for me to get patches accepted and merged into the main branch [13:44:42 CEST] <durandal_1707> TekniQue: http://ffmpeg.org/developer.html#Submitting-patches-1 [15:24:21 CEST] <kierank> January: maybe worth having discussion here [16:14:50 CEST] <durandal_1707> nothing worth here, feel free to leave [17:41:31 CEST] <cone-786> ffmpeg 03Michael Niedermayer 07master:6b1b5af0240b: avfilter/vf_frei0r: Remove duplicate }, fix build [22:05:24 CEST] <j-b> What's the use of using wolfSSL? [22:06:19 CEST] <BtbN> The hell is WolfSSL? [22:08:01 CEST] <atomnuker> pull [22:08:23 CEST] <atomnuker> erm switched focus halfway through [22:11:34 CEST] <durandal_1707> j-b: what's use of vlc supporting cineform but not sheervideo? [22:11:48 CEST] <j-b> durandal_1707: no idea. [22:12:03 CEST] <j-b> durandal_1707: people ask me for cineform all the time. Almost never sheervideo. [22:15:33 CEST] <durandal_1707> Compn: still waiting for your changes to mplayer repo [22:21:27 CEST] <durandal_1707> jamrial: can you please explain what i should do? I failed to understand your message. [22:22:18 CEST] <jamrial> look at how UNCHECKED_BITSTREAM_READER is defined and checked in get_bits.h, then do the same for the new define [22:23:21 CEST] <durandal_1707> what about using: #if ARCH_X86_32 #define ... [22:29:10 CEST] <jamrial> durandal_1707: https://pastebin.com/vHWdi9Nz [22:34:59 CEST] <kurosu> so, do people in here think OPEN_READER & friend should eventually go (like in libav) or there is a *functional* difference [22:36:16 CEST] <kurosu> from a quick glance, I'd say this is mostly better for the unchecked case, and having some heavily used struct members as variables, which I imagine helps compilers use registers [22:38:07 CEST] <kurosu> because the opposite would be to then port durandal_1707's cached part to this macro API [22:43:12 CEST] <durandal_1707> kurosu: someone needs to make benchmarks, lot of that belongs to microoptimization [22:44:06 CEST] <BBB> holy crap that email does not render correctly in gmail [22:44:16 CEST] <BBB> its like word vomit all over my screen, what happened [22:44:26 CEST] <BBB> (the wolfssl one) [22:44:30 CEST] <BBB> does anyone else have that issue also? [22:44:48 CEST] <kurosu> durandal_1707, yeah, but that would be ignoring why there is a benefit and how it could be reused [22:46:29 CEST] <durandal_1707> BBB: mailing list archive attachment is fine [22:48:27 CEST] <durandal_1707> jamrial: that patch have some issues, i fixed it and will push it under your authorship [22:58:58 CEST] <cone-733> ffmpeg 03James Almer 07master:9305bdc68f09: avcodec/get_bits: actually make cached reader correctly disabled [23:11:32 CEST] <thardin> https://www.gamasutra.com/blogs/TrevorDiem/20171018/301247/The_Full_Throttl… http://gamasutra.com/blogs/TrevorDiem/20180829/321112/The_Full_Throttle_Rem… interesting considering the smush support in ffmpeg [00:00:00 CEST] --- Fri Aug 31 2018

1 0

ffmpeg.log.20180830
by burek 31 Aug '18

31 Aug '18

[01:50:30 CEST] <fling> Ke: does it work? [01:50:49 CEST] <fling> Ke: you should not worry about mem2mem as long as it is v4l device [01:51:33 CEST] <fling> Ke: because v4l devices use inputs/outputs and controls available via v4l [01:52:03 CEST] <fling> Ke: you use input and output with ffmpeg and switch controls with v4l2-ctl [01:52:28 CEST] <fling> Or is there any trickery involved? Tell me more about what you have there. [04:28:28 CEST] <breakslowbot> Hello [04:30:52 CEST] <breakslowbot> ffmpeg.nightly don't have support for .NETframework v4.5.2 wich one I should use? [04:31:35 CEST] <yagiza> Hello! [04:31:47 CEST] <pi--> So, I have a repeatable test illustrating strange behaviour. A video formed by concatenating two other videos glitches in VLC. [04:32:04 CEST] <breakslowbot> hello yagiza [04:32:23 CEST] <breakslowbot> I am new here [04:32:40 CEST] <pi--> https://paste.pound-python.org/show/9g22Vq4VVWYM77Yfh5AH/ [04:32:57 CEST] <pi--> Might this be of any interest as a bug? [04:32:58 CEST] <yagiza> breakslowbot [04:34:26 CEST] <yagiza> When I switched to custom I/O for RTP encoding, I have an error -5 (I/O error) on avformat_write_header(). [04:34:43 CEST] <breakslowbot> can someone help me setting up ffmpeg on C#? [04:34:47 CEST] <yagiza> My costom I/O procedures never invoked. [04:35:32 CEST] <yagiza> Is it possible to use RTP encoding with custom I/O procedures? [04:46:40 CEST] <poutine> pi--, I don't think you're encoding using the same parameters for the 2nd video as the 1st one had [04:46:50 CEST] <poutine> you'll likely need to use the concat filter and transcoding rather than transmuxing [08:07:03 CEST] <Ke> fling: sorry did not try yet [12:03:17 CEST] <AnrDaemon> Can somebody please tell me, what's wrong with this filter? https://pastebin.com/YF6KGtkP [12:10:16 CEST] <BtbN> Error when evaluating the expression '(540-h*min(720/w,540/h))/2' [12:22:29 CEST] <AnrDaemon> WHICH error? [12:22:46 CEST] <AnrDaemon> I don't see anything particularly wrong with it. [12:24:43 CEST] <durandal_1707> AnrDaemon: have you copy pasted that command from somewhere? [12:24:52 CEST] <AnrDaemon> Nop. [12:25:45 CEST] <AnrDaemon> I'm puzzled by the fact it complains about the last block only. [12:26:48 CEST] <AnrDaemon> Ok, documentation says it only supports iw/ih. Let me try. [12:29:36 CEST] <AnrDaemon> https://pastebin.com/YF6KGtkP [12:29:51 CEST] <AnrDaemon> IDK what's going on. Honestly. :( [12:36:08 CEST] <durandal_1707> AnrDaemon: you get negative width for pad argument [12:36:38 CEST] <AnrDaemon> Why? [12:38:03 CEST] <AnrDaemon> According to https://ffmpeg.org/ffmpeg-filters.html#toc-Options-1, if one of the w:h is negative, it claculates it based on the other component, preserving image scale rouded to the abs(negative) [12:38:53 CEST] <AnrDaemon> https://ffmpeg.org/ffmpeg-filters.html#Options-1 [12:41:33 CEST] <durandal_1707> AnrDaemon: then x/y are too big [12:42:13 CEST] <AnrDaemon> O.o [12:42:30 CEST] <AnrDaemon> The streams layout is attached. I don't see anything particularly wrong with it. [12:46:30 CEST] <durandal_1707> [Parsed_pad_2 @ 0665fac0] Input area -120:0:840:540 not within the padded area 0:0:720:540 or zero-sized [12:46:48 CEST] <AnrDaemon> I see it, but don't understand& or may be I do. [12:46:58 CEST] <AnrDaemon> Lemme try one thing. [12:51:17 CEST] <AnrDaemon> https://pastebin.com/YF6KGtkP :WALL: [12:51:29 CEST] <AnrDaemon> Forcing SAR/DAR makes no diff. [13:09:48 CEST] <AnrDaemon> I'm about to give up and calculate everything my hands. :( [13:15:58 CEST] <AnrDaemon> scale=w=720:h=540:force_original_aspect_ratio=decrease [13:31:31 CEST] <ariyasu> -profile:v high422 -pix_fmt yuv420p [13:31:35 CEST] <ariyasu> this is wrong for a start [13:32:03 CEST] <ariyasu> you cant use both 4:2:2 and 4:2:0 [13:32:10 CEST] <AnrDaemon> ariyasu: I'm open for suggestions. [13:32:48 CEST] <AnrDaemon> I admit, parts of it is copied from various "make html5 ready video" tutorials. [13:35:52 CEST] <ariyasu> forgetting your command for a min [13:35:58 CEST] <ariyasu> what are you actually trying to do [13:38:17 CEST] <AnrDaemon> I'm trying to automate video processing before uploading to the website. [13:39:30 CEST] <AnrDaemon> The content is educational, so SUPER HIGHT QUALITY 1080p is rather useless. [13:40:28 CEST] <AnrDaemon> And in process, I'm testing it on my <khm> collection. [13:40:35 CEST] <Nacht> Why the 4:3 output ? [13:40:44 CEST] <AnrDaemon> Just for test. [13:40:52 CEST] <AnrDaemon> It could be anything, really. [13:40:58 CEST] <Nacht> What exactly do you hope the pad to do ? [13:41:23 CEST] <AnrDaemon> Solved it already, kind of. Will have to check on non-sar=1 video first though. [13:41:41 CEST] <Nacht> Cause, judging from the string. If you input an 1920x1080, it will get scaled to 960x540 and it will exceed the size of the pad [13:42:20 CEST] <AnrDaemon> Not with scale=w=720:h=540:force_original_aspect_ratio=decrease [13:46:47 CEST] Action: AnrDaemon finally found the right documentation parts. *blush* [15:12:45 CEST] <AnrDaemon> Thanks everybody for being my rubber ducky for today. [15:27:24 CEST] <AnrDaemon> Hm, may be a stupid question, but& can I save two video streams in one file? I.e. both M4V and VPX ? [15:35:01 CEST] <Ke> AnrDaemon: you mean concatenated or parallel? [15:35:08 CEST] <AnrDaemon> Parallel. [15:35:22 CEST] <Ke> I would assume mkv can do this [15:35:37 CEST] <Ke> I would recommend looking at mkvmerge tool [15:35:41 CEST] <Ke> in mkvtoolnix [15:45:04 CEST] <AnrDaemon> Thanks. [15:52:58 CEST] <DHE> AnrDaemon: there's also a "tee" output muxer to save simultaneously. useful for both streaming and saving to disk. [15:53:06 CEST] <AnrDaemon> Is it safe to exclude video strem from first pass encoding? [15:53:15 CEST] <DHE> ..? [15:53:24 CEST] <AnrDaemon> Err, audio stream :D [15:53:32 CEST] <AnrDaemon> Sorry, thinking too many things at once. [15:54:14 CEST] <Ke> hmm do you actually mean streaming, mkvmerge might not do that [15:54:25 CEST] <AnrDaemon> Nop. [15:54:52 CEST] <DHE> sure, though usually the savings isn't very much. slowest codec I've used recently still encodes at 20x realtime. so that saves 3 CPU minutes for an hourlong video [15:55:18 CEST] <AnrDaemon> I can imagine that. Was just wondering :) [15:55:50 CEST] <AnrDaemon> M4V firstpass was noticable faster than VPX one, and I've seen it only encoding video stream. [16:20:25 CEST] <AnrDaemon> Any way to specify some global defaults? I'm tired of adding -hide_banner -nostdin -nostats to every command. [16:28:45 CEST] <AnrDaemon> -map 0:v -map -0:a?" [16:28:50 CEST] <AnrDaemon> Works. :) [16:44:55 CEST] <colegatron> Hi all. I have found ffmpeg and I am wondering if it is possible to capture audio/video (two different browser tabs, but can also be two different browsers, ff and chrome, if it helps), without mixing audios. [16:44:58 CEST] <colegatron> is that possible? [16:45:29 CEST] <colegatron> I am using ubuntu, so pulseaudio server [16:48:51 CEST] <colegatron> just to clarify; the requirement is capture each browser tab in a different mpeg/flv/whatever [16:53:19 CEST] <Lokie> hello, I am trying to join pictures into a video and I want to specify the framerate [16:53:45 CEST] <Lokie> I am using "ffmpeg -y -pattern_type glob -i '*.JPG' -c:v copy -r 15 output.mp4" but it seems ignored [16:53:45 CEST] <kepstin> Lokie: use the `-framerate X` input option (goes before the -i) [16:54:37 CEST] <Lokie> it's ignored [16:54:51 CEST] <Lokie> ffprobe shows fps 25 [16:54:59 CEST] <DHE> ffmpeg -y -framerate 30 -pattern_type glob -i '*.JPG' ... [16:55:04 CEST] <DHE> order matters in ffmpeg. a lot [16:55:42 CEST] <Lokie> there we go, thank you! [16:55:57 CEST] <DHE> note that's what kepstin said as well [16:56:01 CEST] <Lokie> is -framerate different to -r cause I did try -r before -pattern and it didn't work [16:56:28 CEST] <c_14> yes [16:56:29 CEST] <DHE> -framerate is an option to the image demuxer since it fakes a movie from still images. -r is an ffmpeg option for rate conversion [16:56:46 CEST] <Lokie> aha so that was the problem [16:56:49 CEST] <Lokie> thank you all [17:09:55 CEST] <AnrDaemon> Lokie: Before -i [17:22:52 CEST] <fpiraneo> Hi all. Ive a question about encoding a video with ffmpeg 4.0.2; Ive two different builds of ffmpeg: The first under the latest freebsd and the second under osx; in both cases I use the x265 codec; in the freebsd version all video are encoded with pixel format yuv420p12le; in the osx version all video are encoded with pixel format yuv420p; same pixel format are video encoded with ubuntu 18.04 build. [17:23:22 CEST] <fpiraneo> Now: the -pix_fmt parameter seems to doesnt have effect. [17:23:46 CEST] <fpiraneo> Any idea about is welcome; follows the command I use for encoding: [17:24:16 CEST] <fpiraneo> ffmpeg -y -i INPUT -t 00:00:05 -c:v libx265 -pix_fmt:v yuv420p -preset medium -s hd720 -crf 23 -c:a copy -strict -2 -f matroska OUTPUT [17:25:12 CEST] <BtbN> why -strict -2? [17:25:33 CEST] <fpiraneo> Let me check some notes... [17:25:49 CEST] <BtbN> it should be doing nothing [17:26:18 CEST] <BtbN> but the command seems ok otherwise, so that freebsd build must be messed up [17:26:48 CEST] <fpiraneo> Well& I cannot find any note about but I remember that without the -strict -2 ffmpeg gave me some error while rescaling. [17:27:23 CEST] <fpiraneo> Consider that on freebsd I use the official ports. Nothing more, nothing less... [17:27:58 CEST] <fpiraneo> But, when I try to change the pixformat on osx, ffmpeg always encode with yuv420p. [17:29:04 CEST] <fpiraneo> Some other notes: On VLC both pixformat plays fine! Ive issues when playing on my OSMC media player, based on raspberrypi 3 [17:29:19 CEST] <fpiraneo> So I began to dig to see whats happening. [17:30:52 CEST] <kepstin> fpiraneo: x265 can be built in various different ways, you can either get a single bit depth build or multi bit depth [17:31:03 CEST] <kepstin> it might be that on one of your systems you have an 8-bit-only x265 build [17:32:04 CEST] <fpiraneo> kepstin: How can I check how x265 is built? Using ffmpeg commands I mean... [17:32:28 CEST] <kepstin> "ffmpeg -h encoder=libx265" will print out the supported pixel formats [17:32:54 CEST] <fpiraneo> Ok Ill do it now& and Ill post the result& just a sec. [17:33:51 CEST] <fpiraneo> on osx: Supported pixel formats: yuv420p yuv422p yuv444p gbrp gray [17:34:30 CEST] <kepstin> ok, so on osx you have an 8-bit only x265 build (there's no 10le or 12le formats) [17:34:38 CEST] <fpiraneo> Supported pixel formats: yuv420p yuv422p yuv444p gbrp yuv420p10le yuv422p10le yuv444p10le gbrp10le yuv420p12le yuv422p12le yuv444p12le gbrp12le gray gray10le gray12le [17:34:45 CEST] <fpiraneo> The latter on freebsd. [17:34:59 CEST] <kepstin> and on freebsd you have a multi-bit-depth x265, supports 8, 10, and 12bit video [17:35:15 CEST] <fpiraneo> It should be ok to encode in yuv420p BUT it seems that the -pix_fmt is not taken into account& [17:35:33 CEST] <fpiraneo> With ffprobe I still get a yuv420p12le [17:35:41 CEST] <kepstin> using -pix_fmt yuv420p (in the correct location in the command line) should cause the freebsd system to encode with yuv420p [17:35:58 CEST] <kepstin> note the *in the correct location in the command line*, that's important ;) [17:36:01 CEST] <fpiraneo> Good point!! The right position. [17:36:15 CEST] <fpiraneo> I post again the command I use: [17:36:30 CEST] <fpiraneo> ffmpeg -y -i INPUT -t 00:00:05 -c:v libx265 -pix_fmt:v yuv420p -preset medium -s hd720 -crf 23 -c:a copy -strict -2 -f matroska OUTPUT [17:36:38 CEST] <fpiraneo> This make sense for you? [17:37:01 CEST] <kepstin> hmm, that should be correct. Note that the :v on pix_fmt is redundant, it only applies to video anyways. [17:37:17 CEST] <kepstin> please pastebin the complete output of ffmpeg on freebsd [17:37:29 CEST] <fpiraneo> Ok give me a sec! [17:39:21 CEST] <fpiraneo> Lot of printout is coming& sorry for that. [17:39:28 CEST] <fpiraneo> ffmpeg version 4.0.2 Copyright (c) 2000-2018 the FFmpeg developers [17:39:32 CEST] <fpiraneo> built with FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0) [17:39:33 CEST] <fpiraneo> configuration: --prefix=/usr/local --mandir=/usr/local/man --datadir=/usr/local/share/ffmpeg --pkgconfigdir=/usr/local/libdata/pkgconfig --enable-shared --enable-pic --enable-gpl --enable-postproc --enable-avfilter --enable-avresample --enable-pthreads --cc=cc --disable-alsa --disable-libopencore-amrnb --disable-libopencore-amrwb --disable-libass --enable-libbs2b --disable-libcaca --disable-libcdio --disable-libcelt --disable-chromaprint --enable-libco [17:39:35 CEST] <fpiraneo> --disable-libdc1394 --disable-debug --enable-htmlpages --enable-libdrm --enable-libfdk-aac --disable-libflite --enable-fontconfig --enable-libfreetype --enable-frei0r --disable-libfribidi --disable-libgme --disable-libgsm --enable-iconv --disable-libilbc --disable-libjack --enable-libkvazaar --disable-ladspa --enable-libmp3lame --enable-libbluray --disable-librsvg --disable-libxml2 --disable-lv2 --enable-mmx --disable-libmodplug --disable-libmysofa [17:39:35 CEST] <DHE> do NOT do that [17:39:36 CEST] <fpiraneo> --disable-openal --disable-opencl --enable-libopencv --disable-opengl --enable-libopenh264 --disable-libopenjpeg --enable-optimizations --enable-libopus --enable-libpulse --enable-runtime-cpudetect --disable-librubberband --disable-sdl2 --disable-libsmbclient --disable-libsnappy --disable-sndio --disable-libsoxr --disable-libspeex --enable-sse --disable-libssh --disable-libtesseract --enable-libtheora --disable-libtwolame --enable-libv4l2 --enable-vaapi [17:39:36 CEST] <DHE> oh shit... [17:39:38 CEST] <fpiraneo> --enable-vdpau --disable-libvidstab --enable-libvorbis --disable-libvo-amrwbenc --enable-libvpx --disable-libwavpack --disable-libwebp --enable-libx264 --enable-libx265 --disable-libxcb --enable-libxvid --disable-outdev=xv --disable-libzimg --disable-libzmq --disable-libzvbi --disable-gcrypt --enable-gmp --disable-librtmp --enable-gnutls --disable-openssl --enable-version3 --enable-nonfree --disable-libaom --disable-libsrt [17:39:39 CEST] <fpiraneo> libavutil 56. 14.100 / 56. 14.100 [17:39:41 CEST] <fpiraneo> libavcodec 58. 18.100 / 58. 18.100 [17:39:42 CEST] <fpiraneo> libavformat 58. 12.100 / 58. 12.100 [17:39:44 CEST] <fpiraneo> libavdevice 58. 3.100 / 58. 3.100 [17:39:45 CEST] <fpiraneo> libavfilter 7. 16.100 / 7. 16.100 [17:39:47 CEST] <fpiraneo> libavresample 4. 0. 0 / 4. 0. 0 [17:39:48 CEST] <fpiraneo> libswscale 5. 1.100 / 5. 1.100 [17:39:50 CEST] <fpiraneo> libswresample 3. 1.100 / 3. 1.100 [17:39:51 CEST] <fpiraneo> libpostproc 55. 1.100 / 55. 1.100 [17:39:53 CEST] <fpiraneo> Input #0, matroska,webm, from '1_org/13x01 - Decolliamo.mkv': [17:39:54 CEST] <fpiraneo> Metadata: [17:39:56 CEST] <fpiraneo> encoder : libebml v1.3.3 + libmatroska v1.4.4 [17:39:57 CEST] <fpiraneo> creation_time : 2017-10-15T05:06:38.000000Z [17:39:59 CEST] <fpiraneo> Duration: 00:41:32.84, start: 0.000000, bitrate: 6102 kb/s [17:40:00 CEST] <fpiraneo> Stream #0:0(eng): Video: h264 (High), yuv420p(progressive), 1920x1080, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 1k tbn, 47.95 tbc (default) (forced) [17:40:02 CEST] <fpiraneo> Metadata: [17:40:03 CEST] <fpiraneo> BPS : 5332031 [17:40:05 CEST] <fpiraneo> BPS-eng : 5332031 [17:40:06 CEST] <fpiraneo> DURATION : 00:41:32.840000000 [17:40:08 CEST] <fpiraneo> DURATION-eng : 00:41:32.840000000 [17:40:09 CEST] <fpiraneo> NUMBER_OF_FRAMES: 62321 [17:40:11 CEST] <fpiraneo> NUMBER_OF_FRAMES-eng: 62321 [17:40:12 CEST] <fpiraneo> NUMBER_OF_BYTES : 1661487790 [17:40:14 CEST] <fpiraneo> NUMBER_OF_BYTES-eng: 1661487790 [17:40:15 CEST] <fpiraneo> _STATISTICS_WRITING_APP: mkvmerge v8.5.2 ('Crosses') 64bit [17:40:17 CEST] <fpiraneo> _STATISTICS_WRITING_APP-eng: mkvmerge v8.5.2 ('Crosses') 64bit [17:40:18 CEST] <fpiraneo> _STATISTICS_WRITING_DATE_UTC: 2017-10-15 05:06:38 [17:40:20 CEST] <fpiraneo> _STATISTICS_WRITING_DATE_UTC-eng: 2017-10-15 05:06:38 [17:40:28 CEST] <durandal_1707> lol [17:40:34 CEST] <DHE> hahaha [17:40:39 CEST] <DHE> Sigyn: thx [17:47:41 CEST] <AnrDaemon> What can I do about [vc1 @ 05acef80] Error in WVC1 interlaced frame [17:47:41 CEST] <AnrDaemon> Error while decoding stream #0:1: Invalid data found when processing input [17:49:06 CEST] <AnrDaemon> I highly doubt it is actually interlaced. [17:49:16 CEST] <kepstin> I did say "pastebin" :/ [17:49:34 CEST] <kepstin> should have use the !pb macro i guess. [17:49:58 CEST] <DHE> yes you did [17:50:06 CEST] <AnrDaemon> Oh. "Scantype: mixed" [17:50:06 CEST] <DHE> seems like nobody listens [17:50:50 CEST] <AnrDaemon> Lies. I did. [18:04:32 CEST] <fpiraneo> Hi all, Im sorry but I did a big mistake publishing all the output line from my console. [18:04:38 CEST] <fpiraneo> Now, Im back. [18:05:08 CEST] <AnrDaemon> fpiraneo: Was it so friggin hard to read the channel join notice before posting? [18:05:48 CEST] <fpiraneo> I was discussing about a freebsd build of ffmpeg that seems not to take account of -pix_fmt parameter. [18:06:24 CEST] <fpiraneo> AnrDaemon: Sorry for that but it seems the only way to provide a full and complete answer to a question& [18:06:58 CEST] <AnrDaemon> Somebody kick him again to refresh the join message& please. [18:07:15 CEST] <fpiraneo> So& rolling back: I use this command under freebsd: [18:07:32 CEST] <fpiraneo> ffmpeg -y -i INPUT -t 00:00:05 -c:v libx265 -pix_fmt:v yuv420p -preset medium -s hd720 -crf 23 -c:a copy -strict -2 -f matroska OUTPUT [18:08:08 CEST] <fpiraneo> And the video is still encoded with yuv420p12le pixel format& [18:10:19 CEST] <BtbN> From how I understand libx265, the lib can only do either 8, 10 or 12 bit encoding, depending on how it was compiled. [18:10:30 CEST] <BtbN> So if freebsd decided to build a 12 bit one... [18:10:58 CEST] <fpiraneo> And I got this: https://pastebin.com/QuD1Rqa5 [18:11:19 CEST] <fpiraneo> (Sorry again but I didnt knew pastebin&) [18:11:42 CEST] <furq> build x265 from ports [18:11:48 CEST] <furq> there's a make config option to enable 10 and 12-bit [18:12:00 CEST] <fpiraneo> No& this is the interesting point: [18:12:01 CEST] <fpiraneo> Supported pixel formats: yuv420p yuv422p yuv444p gbrp yuv420p10le yuv422p10le yuv444p10le gbrp10le yuv420p12le yuv422p12le yuv444p12le gbrp12le gray gray10le gray12le [18:12:14 CEST] <BtbN> Yes, it supports taking them [18:12:17 CEST] <BtbN> but will output 12 bit [18:12:23 CEST] <fpiraneo> How freebsd reports to me with ffmpeg -h encoder=libx265 [18:12:31 CEST] <fpiraneo> And I used the port version of x265 [18:12:42 CEST] <BtbN> They built a 12 bit only version then [18:13:50 CEST] <fpiraneo> BtbN: Are you sure? Its seems that the build support also the 8 bit! (look ad yuv420p as first one) [18:14:16 CEST] <BtbN> Well, then there clearly is no problem. [18:14:25 CEST] <AnrDaemon> fpiraneo: Not all pixel formats supported by all codecs. [18:14:48 CEST] <furq> that list is from the help for x265 [18:14:50 CEST] <AnrDaemon> fpiraneo: And unfortunately, there's no way to get this information directly from ffmpeg :/ [18:14:56 CEST] <furq> ...yes there is [18:15:00 CEST] <furq> you run the command he said [18:15:01 CEST] <AnrDaemon> Share please. [18:15:03 CEST] <fpiraneo> AnrDaemon: This is the output of the command asking the pixel format support for the codec! [18:15:10 CEST] <AnrDaemon> I've been hit by the same issue. [18:15:12 CEST] <furq> 17:12:23 ( fpiraneo) How freebsd reports to me with ffmpeg -h encoder=libx265 [18:15:15 CEST] <fpiraneo> I make another pastebin: jiust a sec [18:15:22 CEST] <BtbN> it lists the supported input formats. What the codec then does with it is up to its internals. [18:15:28 CEST] <BtbN> If that involved converting to 12 bit, so it will do. [18:15:53 CEST] <fpiraneo> https://pastebin.com/Hdzhty6H [18:16:46 CEST] <fpiraneo> BtbN: So the listed format are valid *INPUT* formats, not outputs? [18:16:55 CEST] <AnrDaemon> furq: Exactly. It happily chws the input, but complaints when you try to set output. [18:16:58 CEST] <BtbN> Video Encoders do not have output pixel formats. [18:17:02 CEST] <BtbN> They output packets [18:17:43 CEST] <fpiraneo> Ok. So can you please suggest me how to deal with this issue? [18:18:05 CEST] <BtbN> Get a libx265.so that supports what you want. [18:18:08 CEST] <fpiraneo> I need to recompile or modify the port of the codec? [18:19:15 CEST] <fpiraneo> I suppose I have to ask to x265 room to get more infos& ;-) [18:21:19 CEST] <fpiraneo> Ok gentleman, thank you for your help! [18:21:28 CEST] <fpiraneo> And sorry again for the huge past& ;-) [18:21:39 CEST] <fpiraneo> *paste [18:41:46 CEST] <Zgrokl> hey is there a way to limit ffmpeg to core 1 and 2 and ffmpeg process 2 to core 3 and 4 [18:42:07 CEST] <Zgrokl> i try with taskset -c 0,1 ffmpeg, seem to work but not really good [18:43:11 CEST] <BtbN> taskset is how you do it on Linux. [18:57:12 CEST] <DHE> taskset is the standard tool, yes. it may not cover 100% of CPU usage as other related kernel activities like interrupts and drivers may use other CPUs [19:17:49 CEST] <Zgrokl> DHE is there a way to get 100% ? like set a nice ? [19:19:08 CEST] <Zgrokl> and you think it's better to make taskset -c 0,1 ffmpeg -threads 0 (or threads 2 ?) [19:19:33 CEST] <BtbN> The thread count auto-detecting will not take notice of the taskset I think [19:19:40 CEST] <BtbN> so you'll need to set it to something sensible manually [19:50:20 CEST] <ChocolateArmpits> When generating sub-second segments in HLS, ffmpeg seems to always make EXT-X-TARGETDURATION equal 0 which fails with most javascript players. Is this a bug or is it supposed to be rounded that way ? [19:52:44 CEST] <JEEB> ChocolateArmpits: not sure about zero specifically but IIRC it is indeed rounded towards smaller int [19:52:54 CEST] <JEEB> let me try and get you the reference from when I tried to post a patch for it [19:53:20 CEST] <JEEB> https://patchwork.ffmpeg.org/patch/8130/ [19:55:46 CEST] <JEEB> of course if the duration is closer to 1 than 0 then technically it should be 1 and not 0 [19:56:05 CEST] <ChocolateArmpits> in relation to the midpoint that is ? [19:56:43 CEST] <JEEB> well, in float seconds that is [19:58:01 CEST] <DHE> The target duration must be an integer, and each segment must be <= its duration. So rounding up is okay and a minimum of 1 would also be fine. [19:58:13 CEST] <ChocolateArmpits> well now it's 0 [19:58:28 CEST] <JEEB> DHE: https://tools.ietf.org/html/rfc8216#page-22 [19:58:40 CEST] <ChocolateArmpits> yeah I'm looking at it [19:58:41 CEST] <DHE> I'm looking at it right now [19:59:45 CEST] <JEEB> but yea, I tried to add ceil to that and got herped a derp back with a bug + the spec [20:00:19 CEST] <ChocolateArmpits> ceiling would make justifiable sense when segment length is less than 1, no? [20:00:26 CEST] <DHE> I have a TV box vendor who mishandled the field and used it for seekbar timing information. due to the rounding sometimes "now" was past the duration of the video. [20:10:17 CEST] <_Mike_C_> Hello again, I asked a question yesterday about the nvenc encoder not returning pkt's. I've made debug versions of the dll's and gone as deep as I can into the ffmpeg code (it skips a lot of functions). It appears like my problem involves the NvencContext in the output_ready() function inside of nvenc.c [20:11:47 CEST] <_Mike_C_> the flush parameter is false, and it gets down to the bottom of the function before returning false [20:12:02 CEST] <_Mike_C_> nb_ready appears to be 16, nb_pending appears to be 0 [20:12:51 CEST] <_Mike_C_> which can only mean that the ctx->async_depth is really high for some reason? I was not able to create my own NvencContext or see what is going on inside it. [20:15:35 CEST] <_Mike_C_> Could someone offer some advice on where to go from here/how to further diagnose/ fix the problem? [20:29:35 CEST] <_Mike_C_> Or maybe someone could explain to me what NvencContext->async_depth is? [20:31:07 CEST] <BtbN> It's where the async_depth avoption gets written to. [21:14:37 CEST] <_Mike_C_> Sorry I got DCed after I asked a question. If anyone answered me, could you please copy the text again. [21:26:03 CEST] <Fenrirthviti> _Mike_C_: [13:31:08] <BtbN> It's where the async_depth avoption gets written to. [21:28:36 CEST] <_Mike_C_> BtbN, is that something I have to write? Or something internal. I don't see it as an option when I look at the h264_nvenc option list [21:28:44 CEST] <_Mike_C_> Fenrirthviti, thank you [21:28:50 CEST] <BtbN> If you are unhappy with the default [21:28:58 CEST] <BtbN> but it's generally fine and you don't need to care about it. [21:29:48 CEST] <_Mike_C_> Can you think of why my output_ready function is returning false then? From the best I can tell, nb_ready is 16, nb_pending is 0 and the second check in line 1941 is returning false [21:30:11 CEST] <_Mike_C_> aka nb_ready + nb_pending >= ctx->async_depth seems to be returning false [21:31:23 CEST] <BtbN> It just means you haven't fed enough input yet [21:31:43 CEST] <_Mike_C_> Unfortunately it never returns true [21:32:00 CEST] <_Mike_C_> despite me continually feeding the encoding context frames [21:32:59 CEST] <BtbN> You are doing something wrong then. [21:33:38 CEST] <_Mike_C_> Could you direct me in a better way to troubleshoot this? [21:33:53 CEST] <_Mike_C_> Everything works just fine with software encoders [21:36:33 CEST] <_Mike_C_> prior to this returning false and no pkt being returned from the avcodec_recieve_packet, I recieve a 0 return value from avcodec_send_frame [21:37:12 CEST] <_Mike_C_> which, I have assumed, means it successfully completed sending a frame to the encoder [21:39:12 CEST] <BtbN> That's what it means, yes. [21:39:47 CEST] <BtbN> There are multiple ways to go at this [21:40:06 CEST] <BtbN> feed frame, loop over receive packet until EAGAIN, feed frame, and so on [21:40:20 CEST] <BtbN> Or feed frames until EAGAIN, then drain the packages, and start over [21:40:21 CEST] <BtbN> both works [21:40:28 CEST] <_Mike_C_> I am using the first method [21:41:11 CEST] <_Mike_C_> I'm sorry to keep bugging you, its just frustrating because I don't have the ability/documentation to troubleshoot this myself. [21:41:40 CEST] <_Mike_C_> I've followed the examples and everything works perfectly as it should, but there must be something extra that I haven't done thats needed with the H264_nvenc encoder [21:42:05 CEST] <BtbN> There really isn't. ffmpeg.c accesses all of them in the same generic way, and it just works there. [21:42:23 CEST] <_Mike_C_> Is there something platform specific that could be breaking it because I am on windows? [21:42:31 CEST] <BtbN> no [21:42:38 CEST] <BtbN> if there was, it would error on init [21:45:17 CEST] <_Mike_C_> How else can I troubleshoot the fact that no matter how long I run it for, the output_ready function returns false? [21:46:10 CEST] <_Mike_C_> The avcodec_send_frame function is even returning EAGAIN, signifying the input buffer is full [21:46:11 CEST] <BtbN> No idea, but I'd assume you do not properly send frames, cause if you send frames constantly without reading anything, you would eventually get an EAGAIN on send [21:46:19 CEST] <_Mike_C_> I do [21:47:00 CEST] <_Mike_C_> I let it run for a bit and it starts returning EAGAIN, but the out_ready is still returning EAGAIN as well [21:47:15 CEST] <BtbN> On what path? [21:47:19 CEST] <_Mike_C_> er it returns false, which in turn returns EAGAIN [21:47:50 CEST] <_Mike_C_> What do you mean "path"? [21:48:26 CEST] <BtbN> From what path in that function does it return 0 [21:49:19 CEST] <BtbN> Where do your frames come from? Do they have proper, non AV_NOPTS_VALUE, pts set on them? [21:50:10 CEST] <_Mike_C_> I cannot dive into that code (the debugger skips past a lot of stuff) but I see both av_fifo_size functions execute and I know that the parameter flush is false, so I am assuming its the final reutrn statement that returns 0, aka line 1941 [21:50:46 CEST] <BtbN> The only idea I'd have is that you never set a proper pts on your input frames, so the re-ordering logic is waiting on something to work with [21:50:47 CEST] <_Mike_C_> Yes the frames have proper pts values [21:51:01 CEST] <BtbN> If all else fails, put debug-prints in there [21:51:03 CEST] <_Mike_C_> Do they have to have numbers starting from 0 before fed to the encoder? [21:51:25 CEST] <_Mike_C_> I'm currently using pts values returned from the decoder [21:51:30 CEST] <BtbN> As long as they aren't NOPTS_VALUE you're good. [21:51:47 CEST] <BtbN> You can also temporarily set avctx->max_b_frames = 0 to rule out that branch. [21:52:15 CEST] <_Mike_C_> I have done that, its set to 0 [21:53:53 CEST] <BtbN> And you say nb_ready is 16, and pending 0? [21:54:42 CEST] <_Mike_C_> yes [21:54:52 CEST] <BtbN> How can you even see that if you can't step into the function? [21:55:41 CEST] <_Mike_C_> actually, maybe its not. It takes me inside of the av_fifo_size function and I just did the math myself, but maybe the [21:56:18 CEST] <_Mike_C_> on the first run of the function the return value is 16 [21:56:28 CEST] <_Mike_C_> one the second run, its 0 [21:56:46 CEST] <BtbN> That can be really anything [21:56:46 CEST] <_Mike_C_> Maybe the divide by sizeof(NvencSurface*) is messing up the variable number [21:56:59 CEST] <BtbN> No, it returns the actual size [21:58:41 CEST] <BtbN> 16 is also super low. A single surface is larger than that. [21:59:18 CEST] <BtbN> I'll just assume your debugger is doing nonsense [21:59:48 CEST] <_Mike_C_> Im using the visual studio debugger [21:59:56 CEST] <_Mike_C_> when it steps me into the av_fifo_size function [22:00:13 CEST] <_Mike_C_> the first time, f->wndx is 16 and f->rndx is 0 [22:00:29 CEST] <_Mike_C_> the second time its 16 and 16 [22:00:40 CEST] <BtbN> No idea what that is [22:01:19 CEST] <_Mike_C_> they're some pointers in the AFifoBuffer : ( [22:01:34 CEST] <BtbN> I never looked at that code, the buffers just work [22:02:09 CEST] <BtbN> Anyway, with what you are telling, the only actual answer I can give you is "You are doing something wrong" [22:03:22 CEST] <_Mike_C_> Unfortunately I don't know how to figure out what that is, I've followed the examples and have a working product with software encoders. Its something about using this hardware encoder (possibly on windows) and ive tracked down the fail location the best I can. [22:03:59 CEST] <_Mike_C_> That last return statement in output_ready returns false even with the input buffer returning EAGAIN [22:09:12 CEST] <_Mike_C_> I suppose I'll take your advice and put in debug print statements, recompile and recheck the values I'm getting. Hopefully I can come back to you with better information [22:46:21 CEST] <Pistos> I am rendering a video using kdenlive. It has a slider in the render dialogue which I am *guessing* refers to options sent to ffmpeg: "Encoder speed", which, when you hover over it, says "Codec speed parameters: preset=ultrafast" So, assuming this really does pass this to ffmpeg, my question is: Is this tradeoff encoding time vs. file size? Or something else? Will changing the preset affect quality, or [22:46:23 CEST] <Pistos> just file size? Reference: https://trac.ffmpeg.org/wiki/Encode/H.264 [22:48:38 CEST] <BtbN> That depends on the other settings. [22:52:29 CEST] <kepstin> Pistos: that sets an option specific the the libx264 encoder (and I guess libx265 uses a similar option too) [22:53:13 CEST] <kepstin> Pistos: assuming other options are set the same, changing the speed option mostly affects encoding time vs file size, but can also make some minor quality changes. [23:05:30 CEST] <BtbN> If it's set to a fixed bitrate, changing the preset will affect the quality a whole lot [23:06:05 CEST] <kepstin> ah, yeah, i sometimes forget that people use modes other than crf ;) [23:17:37 CEST] <pi-> poutine: Thanks! That was it! [23:30:18 CEST] <Pistos> Okay, thanks for the info, guys. [23:31:28 CEST] <Pistos> Well, the kdenlive interface seems to have this output in a textfield, which presumbly is trying to tell me some of the command line params being passed to the underlying ffmpeg, melt, etc.: properties=x264-medium f=mp4 vcodec=libx264 acodec=aac g=120 crf=%quality ab=%audiobitrate+'k' [23:31:45 CEST] <Pistos> In the dialogue box, I have the %quality (I assume) set to 24, and audio 192 [23:32:35 CEST] <Pistos> I've played with %quality at 15 and 45 for a short fragment of my video, and the video quality is noticeable when it's as high as 45 for crf, but difference between audio 64 and audio 192 is inaudible to my ears (for this particular source recording). [23:33:34 CEST] <Pistos> So, assuming I'm relatively okay with larger file sizes, choosing ultrafast as a preset should be okay? [23:35:12 CEST] <BtbN> veryfast is usually the fastest not completely shit option [23:36:31 CEST] <Pistos> BtbN: Thank you. [23:36:50 CEST] <Pistos> I'm rendering a clip now with various settings, putting them to the eye- and ear-test. [23:42:13 CEST] <Pistos> I can't tell the difference with my eyes or ears: Given exiftool reporting Avg Bitrate of 2.91 Mbps (smaller file) vs. 9.69 Mbps (larger file), which is supposedly better quality? [23:42:50 CEST] <Pistos> Render time was a difference of double (half). [23:49:09 CEST] <iive> you might want to enable psnr and ssim statistics, they can give you some objective numbers. [23:57:10 CEST] <kepstin> Pistos: in general, you want to pick the slowest preset that is "fast enough" for your application, then choose a crf value that provides the quality level you want. [23:59:49 CEST] <Pistos> I have a 17.5 minute video which, with this machine, settings, effects, etc., takes 2 hours to render. I'm just getting impatient :) , and am looking for ways to speed up render time without noticeably sacrificing quality. [00:00:00 CEST] --- Fri Aug 31 2018

1 0

ffmpeg-devel.log.20180829
by burek 30 Aug '18

30 Aug '18

[00:34:11 CEST] <kurosu> re configure script, it runs in 1m20s now, so ~3.2x faster [00:34:22 CEST] <kurosu> (Win7 x64) [06:02:22 CEST] <atomnuker> decoders can attach arbitrary private avbuffers to frames, right? [10:37:51 CEST] <cone-102> ffmpeg 03Jacek Jendrzej 07master:3cff2311ab9d: avformat/dashdec: Fix calc_cur_seg_no if availability_start_time not [10:37:51 CEST] <cone-102> ffmpeg 03Colin NG 07master:b205635fbc08: avformat/dashdec: Add a re-entrance check point after an interrupt operation [14:24:29 CEST] <durandal_1707> another -200 lines diff reduced with scpr 3rd version [15:24:50 CEST] <atomnuker> how much + was it when you started? [16:25:27 CEST] <durandal_1707> atomnuker: too much, >3000 [16:55:17 CEST] <durandal_1707> atomnuker: you gonna RE binka? [17:32:52 CEST] <atomnuker> durandal_1707: not if you do it first [17:53:47 CEST] <durandal_1707> snowman plugin successfully decompiles that binka function [18:17:55 CEST] <atomnuker> couldn't find a recent cracked version of ida, russians have 6.5 uncracked for linux only [18:49:07 CEST] <kierank> atomnuker: surely mozilla can get you that [18:55:20 CEST] <atomnuker> of course not, its for personal use, and its too expensive for anyone anyway [20:19:05 CEST] <durandal_1707> kierank: use wine, 6.8 works very good, 7.0 is crap [20:19:27 CEST] <durandal_1707> atomnuker: ^ [20:20:04 CEST] <kurosu> durandal_1707, none of the fate magicyuv samples are >8 bits ? [20:21:06 CEST] <durandal_1707> kurosu: yes, only 8bit [20:23:14 CEST] <kurosu> so does your encoder [20:23:35 CEST] <durandal_1707> kurosu: why you need 10bit? [20:24:03 CEST] <kurosu> would have been nice to test the roundtrip, e.g. vsynth tests [20:24:31 CEST] <kurosu> durandal_1707, I like running fate to see if a change breaks some stuff [20:24:35 CEST] <durandal_1707> there is also 12bit, and unsupported 14bit [20:24:53 CEST] <kurosu> yeah, I can see that from the code [20:25:43 CEST] <durandal_1707> kurosu: do you need >8bit samples or you gonna extend encoder? [20:26:19 CEST] <kurosu> encoder is too much work [20:26:36 CEST] <kurosu> A 10bit sample for a start would have been nice [20:27:18 CEST] <kurosu> It would be nice if trac tickets had a feature to declare samples as free to redistribute (eg fate) [20:28:44 CEST] <durandal_1707> kurosu: what kind of input source for 10bit? [20:29:34 CEST] <kurosu> durandal_1707, err... I just want to check whether the decoder produces the same output after a change [20:30:32 CEST] <durandal_1707> so i can use: ffmpeg -f lavfi -i yuvtestsrc as source? [20:31:55 CEST] <kurosu> I suspect, yes [20:32:15 CEST] <kurosu> the vsynth tests are kind of similar, except legacy [20:32:49 CEST] <kurosu> I don't remember the invoking chain, but I remember adding vsynth3 to catch corner cases with weird or small dimensions [20:34:03 CEST] <durandal_1707> vsynth3 is for cases when there is encoder [20:37:03 CEST] <kurosu> yes, I thought we were discussing the roundtrip fate thing [20:42:34 CEST] <durandal_1707> kurosu: http://0x0.st/stSl.avi ? [20:44:20 CEST] <kurosu> ok so you fed that to a 10bit capable encoder [20:44:43 CEST] <kurosu> ok, I recognize the yuvtestsrc pattern, and thus the intent of your question [20:49:38 CEST] <durandal_1707> that is magicyuv 10bit 422 [20:50:06 CEST] <kurosu> yeah, I saw that from the pixfmt [20:51:06 CEST] <kurosu> anyway, I picked the wrong branch to rebase, so I can't check everything I wanted [20:51:32 CEST] <kurosu> https://pastebin.com/H6Lwpuic <- various bitstream reading commits to magicyuv decoder [20:51:38 CEST] <kurosu> master = current ffmpeg master [20:51:46 CEST] <kurosu> prepa: just before the actual changes [20:52:10 CEST] <kurosu> lav: libav bitstream reader (their API, this is very old code) [20:52:26 CEST] <kurosu> dual: code from huffyuvdec [20:52:56 CEST] <kurosu> funny that the x86_32 (2nd column) is faster than x86_64 (3rd) at the start [20:53:06 CEST] <kurosu> (gcc 7.3) [20:53:24 CEST] <kurosu> can't test in particular the x86_32 tweaks [20:53:58 CEST] <kurosu> and well, I intended to see about the >8 bits paths, but using the wrong branch broke my motivation for further tests [20:57:09 CEST] <kurosu> anyway, summary of all this: you should commit your cached bitstream reader [20:57:22 CEST] <kurosu> that is too good for continuing passing on it for another year [20:57:28 CEST] <kurosu> even if few people care [21:00:41 CEST] <durandal_1707> michaelni: do you have comments for bitstream patchset? [21:43:38 CEST] <michaelni> durandal_1707, ive looked very briefly at the 3 cached bitstream reader patches when yu posted a few days ago. and didnt spot anything beyond what others have mentioned, quite possibly of course that i missed something [21:50:02 CEST] <atomnuker> durandal_1707: what's wrong with 7.0? [22:03:24 CEST] <durandal_1707> atomnuker: debuger crashes under wine, and your changes are not fully reflected in decompiler output [23:15:53 CEST] <cone-066> ffmpeg 03Paul B Mahol 07master:d71dfc087bce: avcodec/scpr: error out if run length is <= 0 [00:00:00 CEST] --- Thu Aug 30 2018

1 0

ffmpeg.log.20180829
by burek 30 Aug '18

30 Aug '18

[00:01:13 CEST] <jkqxz> At which point x11grab may well just be easier, since the whole point of kmsgrab is to keep stuff on the GPU side and only use resources there because you want to use the CPU for something else. [00:02:47 CEST] <hojuruku> Ah so I need to get prime up and running I guess. Reverse prime on the intel monitor because xrandr is making my pull my head out and xinerama is hell too these days. [00:03:06 CEST] <hojuruku> POLARIS10 here. RX560 [00:03:34 CEST] <jkqxz> To avoid the high-bandwidth transfer maybe you could encode on the AMD, then decode that stream on the Intel and reencode with your working setup? (Quite possibly that's worse overall, would need testing.) [00:03:36 CEST] <hojuruku> but x11grab chews up 15% of the CPU - KMSGRAB only does 2% [00:04:35 CEST] <hojuruku> interesting concept with the encode -> decode -> encode option. i wonder if the intel could cope though it's only a haswell refresh. [00:05:15 CEST] <hojuruku> i'd rather amd just fix their vaapi driver. I think it worked a little better with their gstreamer omx driver. [00:12:47 CEST] <kainengran> Hi! I'm a bit new to compiling stuff, so sorry if it may seem too lame. I'm trying to compile ffmpeg with openh264. I get an error that it isn't found by pkg=config (I've checked that it's the latest version). I've compiled libopenh264 from the source code at openh264.org and the files are sitting in /usr/local/lib. Made sure the $PKG_CONFIG_PATH has this directory. Here's the ffbuild/config.log: [00:12:53 CEST] <kainengran> http://termbin.com/70ac What am I doing wrong here? [00:20:07 CEST] <jkqxz> Does "PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/ pkg-config --exists --print-errors openh264" find it? [00:26:39 CEST] <kainengran> yes [00:28:02 CEST] <jkqxz> Is PKG_CONFIG_PATH definitely being passed to configure? [00:30:22 CEST] <kainengran> How to be sure? [00:30:49 CEST] <jkqxz> Put it on the command line: "PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/ .../configure ..." [00:34:41 CEST] <kainengran> That was it. Thanks from Mr. Noob :) [01:22:40 CEST] <hojuruku> baah i get 70 mins or so from youtube before it panic's and dumps me. [01:23:28 CEST] <hojuruku> It's it's new resolution changing based on the stream feature, it thinks my screen resolution is 65536x65536 and wants me to have 27MBIT streaming capacity or it gets pissed off and hangs up on me. [01:25:25 CEST] <hojuruku> https://i.imgur.com/M9Coy8H.png [01:26:13 CEST] <hojuruku> I need to do battle with xrandr to get the second monitor up, or run off the intel framebuffer and use PRIME for gaming which would be interesting (not that I game much) [01:27:02 CEST] <hojuruku> I used to have some success with obs vaapi patch but that's probably before this youtube upgrade. I'll go check that out. [01:28:51 CEST] <hojuruku> av_interleaved_write_frame(): End of fileB time=00:38:44.13 bitrate=2604.6kbits/s speed= 1x [01:28:51 CEST] <hojuruku> [flv @ 0x55cff0488f40] Failed to update header with correct duration.604.4kbits/s speed= 1x [01:28:51 CEST] <hojuruku> [flv @ 0x55cff0488f40] Failed to update header with correct filesize. [01:28:51 CEST] <hojuruku> Error writing trailer of rtmp://a.rtmp.youtube.com/live2/.... [02:37:41 CEST] <XorSwap> is there a way to make a video with a looping gif and an audio file so that the gif repeats for the length of the audio? [04:00:31 CEST] <pi--> I'm trying to freeze the last frame of a video. [04:00:41 CEST] <pi--> For some reason is taking an incredible amount of time. [04:00:44 CEST] <pi--> https://paste.pound-python.org/show/c5JfErb2vnTSm84XLSiG/ [04:01:06 CEST] <pi--> It takes 1min+ to process a 20 MB video [04:02:00 CEST] <pi--> Why does it need to take so long? [06:50:59 CEST] <kepstin> pi--: that is (by necessity since you're modifying the video content) re-encoding the video. Video encoding takes time. There are options you can use to change the speed/compression/quality tradeoffs. [13:47:02 CEST] <Nacht> Is there a difference between '-itsoffset 3' and 'setpts=PTS-STARTPTS+3/TB' ? [14:26:37 CEST] <fling> Is there something new about mixing multiple live input sources together? [14:27:10 CEST] <fling> It was not working few years back when I tried to mux live feeds from multiple uvc and alsa devices into a single file. [14:29:37 CEST] <fling> BtbN: genkernel respects properties and mounts everything properly. [14:29:40 CEST] <fling> But not /usr :D [15:04:47 CEST] <kepstin> Nacht: -itsoffset applies to all streams in a file, the filter only applies to selected streams (you need to separately do video, audio, and you can't do subtitles at all) [15:54:18 CEST] <Nacht> kepstin: Ah, I thought it only applied to the video stream. cheers [16:52:40 CEST] <learningc> Can ffmpeg do real time encoding on small arm processor, say a quad core A7? [16:53:47 CEST] <JEEB> depends on its power, you can try benchmarking libx264 and openh264 with very fast settings [16:54:02 CEST] <Foaly> just try it, i guess [16:54:19 CEST] <JEEB> I think there's also some HW encoding support as well, but not sure how well it works and if it works with ffmpeg.c at all [16:54:32 CEST] <JEEB> also for decoding you probably want to do hwdec if you're planning on decoding anything [16:55:57 CEST] <learningc> Does it take more processing power to do encoding or decoding? [16:56:58 CEST] <Foaly> encoding [16:58:16 CEST] <JEEB> to be honest, you can encode something in a really simple manner and if you have AVC or HEVC decoding that's most likely going to be more processing power intensive [16:58:25 CEST] <JEEB> so the real response is "it depends" [16:59:09 CEST] <learningc> I see. [17:01:02 CEST] <learningc> So what are my options for least power intensive encoding I can use? [17:01:19 CEST] <DHE> if there is hardware encoding available, use it [17:01:24 CEST] <JEEB> what is your use case? [17:04:22 CEST] <fling> learningc: I always use '-c copy' on slower systems but it depends. [17:06:54 CEST] <ChocolateArmpits> you can also pick lighter encoding standards, for instance mjpeg [17:07:05 CEST] <ChocolateArmpits> of course at the expense of bandwith [17:10:18 CEST] <learningc> There is only mjpeg encoder on the soc, will that work? [17:10:54 CEST] <learningc> But I'm not sure there is a driver available [17:11:06 CEST] <learningc> So I might resort to software encoding [17:11:12 CEST] <fling> learningc: what is the input video? [17:11:23 CEST] <learningc> Webcam [17:11:32 CEST] <learningc> or usb camera [17:11:35 CEST] <fling> learningc: just capture mjpeg from the cam and use -c copy then [17:12:04 CEST] <learningc> I did not get, -c copy is for what? [17:12:17 CEST] <fling> learningc: with mjpeg you will get the best resolution from your cam (unless it is one of two cams capable of h264 output via uvc) [17:13:19 CEST] <learningc> fling, do you mean ffmpeg will do the mjpeg encoding or? [17:13:23 CEST] <fling> learningc: ffmpeg -f v4l2 -input_format mjpeg -framerate 15 -video_size 1280x1024 -i /dev/video0 /path/to/file.nut [17:13:48 CEST] <fling> learningc: no, it will just copy the stream without any encoding. It will mux input to the output without consuming your cpu [17:14:04 CEST] <fling> whoops forgot to add -c copy :D [17:14:33 CEST] <learningc> ffmpeg -f v4l2 -input_format mjpeg -framerate 15 -video_size 1280x1024 -i /dev/video0 /path/to/file.nut -c copy ? [17:14:59 CEST] <fling> ffmpeg -f v4l2 -input_format mjpeg -framerate 15 -video_size 1280x1024 -i /dev/video0 -c copy /path/to/file.nut [17:15:06 CEST] <fling> learningc: any audio input? pulse? [17:15:31 CEST] <learningc> no audio needed for my application [17:16:10 CEST] <fling> learningc: what is the camera model? [17:17:21 CEST] <learningc> It's a custom camera made in korea. Not sure which brand. I just got it as sample [17:18:30 CEST] <fling> learningc: use this `v4l2-ctl --list-formats-ext` to list the supported formats. [17:18:40 CEST] <learningc> For the command line you gave me, is the camera itself doing mjpeg encoding? [17:19:20 CEST] <fling> learningc: run `v4l2-ctl --list-formats-ext` and see [17:19:50 CEST] <fling> choose MJPG pixel format over YUYV [17:19:58 CEST] <learningc> Ok, in case I don't see mjpeg listed, will the above command works? (I don't have the camera with me right now) [17:20:03 CEST] <fling> to get higher resolution and fps! [17:20:48 CEST] <learningc> YUYV is an encoding format? [17:20:49 CEST] <fling> learningc: you could just drop `-input_format mjpeg` then or specify whichever is supported [17:21:02 CEST] <fling> is a raw pixel format [17:21:08 CEST] <fling> MJPG is the compressed one [17:21:20 CEST] <fling> then you specify proper values for fps and resolution [17:21:26 CEST] <learningc> I can record in raw pixel format? [17:22:04 CEST] <fling> notice if you will use `-c copy` with YUYV pixel format you will get a raw video with very high bitrate [17:22:15 CEST] <fling> Sure you can but prepare your storage :D [17:22:43 CEST] <learningc> I see. And if I don't use -c copy? What will the command do? [17:23:02 CEST] <fling> learningc: it will reencode so some codec depending on the file extension you choose for the output [17:24:29 CEST] <learningc> I see [17:24:51 CEST] <fling> learningc: I used nut in the example because it is not getting file corrupted on the muxing interrupts. With mkv format file will bork when there will not be storage space left [17:24:52 CEST] <learningc> If I specify .nut, what will the format be? [17:24:59 CEST] <learningc> I see [17:25:16 CEST] <fling> if you specify .nut then the format will be .nut obviously [17:25:51 CEST] <fling> not sure if .nut works for raw video but you could always switch to .mp4 or whatever. test it and see! [17:26:06 CEST] <fling> anyway .nut works best for mjpeg [17:26:41 CEST] <fling> learningc: don't you have any camera? You could test now with another one, I'm leaving soon. [17:26:44 CEST] <learningc> Ok. Thanks. I will try when I get my hand on the camera. But I can test with my integrated webcam for now [17:27:21 CEST] <learningc> fling, ok, no problem. Thanks again. very helpful info to me as a beginner in ffmpeg [17:27:24 CEST] <fling> show me the output of `v4l2-ctl --list-formats-ext` [17:27:34 CEST] <learningc> Will do. [17:29:46 CEST] <fling> learningc: and `ffmpeg -f v4l2 -list_formats all -i /dev/video0` [17:30:30 CEST] <learningc> Ok. Apparently I don't have v4l2-ctl installed. I will install first [17:31:17 CEST] <fling> learningc: what about the second command? [17:32:21 CEST] <learningc> Trying to install ffmpeg now [17:32:28 CEST] <fling> haha [17:32:41 CEST] <fling> Which distro? [17:32:50 CEST] <learningc> Ubuntu 16.04 [17:33:41 CEST] <learningc> I don't want to hold you. I will let you know v4l2-ctl output when you are back [17:34:24 CEST] <fling> learningc: `apt install v4l-utils ffmpeg` [17:35:04 CEST] <learningc> Ok. Thanks. [17:37:06 CEST] <fling> I have 15 minutes :D [17:38:14 CEST] <Ke> now that we are on this topic, is there some library for using v4l mem2mem [17:39:19 CEST] <fling> Ke: not sure but v4l2loopback is here and you could read from one device with ffmpeg copy input to output and write to another [17:39:50 CEST] <fling> Ke: both of them could be loopbacks or any of them could be real v4l devices [17:40:22 CEST] <Ke> fling: can I do rescale with it [17:40:52 CEST] <fling> Ke: sure, you could recode to raw video changing the resolution [17:41:24 CEST] <Ke> mem2mem does not have decode, at least this one [17:41:30 CEST] <Ke> just scale and copy [17:41:43 CEST] <Ke> but thanks, I'll have a look [17:41:59 CEST] <learningc> About ffmpeg itself, is it also a C api for codec, or just a command line application for Linux? [17:42:19 CEST] <Ke> learningc: there are C apis [17:42:27 CEST] <Ke> libavcodec for example [17:42:37 CEST] <Ke> but quite a few other libs as well [17:43:06 CEST] <Ke> like the livswscale that is causing me problems =o) [17:43:14 CEST] <Ke> libswscale [17:44:28 CEST] <fling> Ke: ffmpeg -input_format mjpeg -framerate 15 -video_size 1280x1024 -i /dev/video0 -s 800x600 -r 10 -vcodec rawvideo -pix_fmt yuv420p -f v4l2 /dev/video1 [17:45:09 CEST] <fling> Ke: this will capture mjpeg from video0 scale it to 800x600, chance fps to 10 and reencode to raw and send to video1 which is imaginary loopback [17:45:36 CEST] <fling> Ke: then you could pretend video1 is a real v4l device :D [17:45:58 CEST] <fling> Ke: you could apply any filters or do whatever you do with the video not only scaling it is possible [17:45:59 CEST] <Ke> but I have real v4l device, and I need it's computing power [17:46:11 CEST] <fling> Ke: umm what? [17:46:11 CEST] <learningc> How is ffmpeg different from gstreamer? It seems like gstreamer can do what ffmpeg does [17:46:17 CEST] <fling> Ke: what are you trying to do? [17:46:31 CEST] <Ke> fling: rescale at a reasonable speed [17:46:40 CEST] <fling> learningc: it is failing to build on my box and the plugins are broken [17:46:51 CEST] <fling> Ke: define rescale [17:47:11 CEST] <learningc> fling, which kind of box do you have? [17:47:23 CEST] <fling> learningc: libreboot x200 [17:47:29 CEST] <Ke> convert from yuv420p 1080p somwthing to 2400x1600 rgb888 [17:47:38 CEST] <Ke> eg. [17:48:12 CEST] <Ke> I have v4l device that can do this [17:48:18 CEST] <fling> Ke: input is v4l device with no 2400x1600 rgb888 capability right? [17:48:30 CEST] <Ke> input is a file [17:48:31 CEST] <fling> What is the output? [17:48:39 CEST] <Ke> output is a buffer in memory [17:49:03 CEST] <Ke> mostly KMS buffer I imagine [17:49:39 CEST] <fling> Ke: either input or output should be a v4l device or you have another question [17:49:45 CEST] <Ke> then libavcodec translates the file into yuv420p buffers [17:50:24 CEST] <Ke> as I understand, mem2mem is a device type that operates between buffers [17:50:35 CEST] <Ke> input on one side output on other [17:50:45 CEST] <fling> so no v4l? [17:50:51 CEST] <Ke> I actually care about both sides [17:50:58 CEST] <Ke> it's v4l [17:51:10 CEST] <Ke> just like hw decoders [17:51:19 CEST] <Ke> or some hw decoders [17:51:56 CEST] <Ke> it's a device, but you don't send the data rather you receive it in another buffer [17:51:59 CEST] <Ke> or something [17:52:06 CEST] <fling> Ke: Will this send the video to the device? -> ffmpeg -i /some/file -vcodec rawvideo -pix_fmt yuv420p /dev/video0 [17:52:30 CEST] <Ke> I guess, you probably know that thing better [17:52:39 CEST] <Ke> I have no idea, how those work [17:53:22 CEST] <Ke> but I have no idea how it could work with just input defined, it also needs an output somehow [17:53:23 CEST] <fling> Ke: then you do this -> ffmpeg -input_format rgb888 -video_size 2400x1600 /dev/video0 -c whatever /your/actual/output.file [17:53:40 CEST] <fling> Ke: am I right? you let the v4l device to rescale ^ [17:54:04 CEST] <Ke> fling: perhaps, I'll study your suggestion a bit [17:54:04 CEST] <fling> Ke: 1. you use file input and video0 as the output [17:54:17 CEST] <fling> Ke: magic happens in v4l [17:54:33 CEST] <fling> Ke: 2. you use video0 as input to get the rescaled video and write it to your actual output [17:55:10 CEST] <fling> Ke: gtg [17:55:19 CEST] <Ke> sure, thanks [17:55:34 CEST] <fling> cya later [17:55:42 CEST] <fling> learningc bye [17:55:54 CEST] <fling> whoops they are not here [17:56:06 CEST] <fling> Ke: tell learningc when he comes I'm away now for few hours [17:56:16 CEST] <Ke> yup [18:14:59 CEST] <learningc> fling, http://termbin.com/bgq5 [18:16:45 CEST] <Ke> (18:56:06) < fling> Ke: tell learningc when he comes I'm away now for few hours [18:17:24 CEST] <learningc> Ok thanks [18:22:05 CEST] <learningc> How can I play back the file with ffmpeg? [18:30:07 CEST] <learningc> ok got it, with ffplay [18:34:32 CEST] <_Mike_C_> Hello, does anyone have any experience with using the nvenc hardware encoders, programatically on windows? [18:36:01 CEST] <_Mike_C_> I'm having an issue attempting to use the h264_nvenc encoder, I followed the example in code that created the VAAPI encoder (but with h264_nvenc) and everything "seems" to work fine, but when I finally get packets out of the encoder, there is no buffer assigned (its NULL) [18:36:37 CEST] <BtbN> You can treat nvenc like any software encoder if you don't have hwframe inputs. [18:40:50 CEST] <_Mike_C_> I had to use hwframe inputs, it would throw errors if I didn't set up that whole thing [18:41:21 CEST] <_Mike_C_> I am able to send HW frames to it successfully, but for some reason when it sends back a pkt, theres nothing in it [18:41:51 CEST] <BtbN> You definitely do not have to do that for nvenc [18:41:59 CEST] <BtbN> it happily takes software frames and does all hw setup internally. [18:43:00 CEST] <_Mike_C_> That's interesting, do you know of another reason that it would throw an access violation when I try to send a sw frame to it? [18:43:20 CEST] <BtbN> "throw an access violation"? You mean, it crashes? [18:45:04 CEST] <_Mike_C_> I'm writing the program in C++, debugging in visual studio. When I try to send a software frame to a h264_nvenc context [18:45:09 CEST] <_Mike_C_> It throws an exception [18:45:18 CEST] <_Mike_C_> "Access violation reading location xxxxx" [18:45:30 CEST] <BtbN> You did something wrong then. That's just a crash. [18:46:24 CEST] <_Mike_C_> Could you please help me figure out what I did wrong? The program works just fine when using a software encoder. [18:46:51 CEST] <_Mike_C_> But when I swap it to the nvenc, it throws the exception, are there other steps I have to do with the nvenc encoder? [18:52:35 CEST] <BtbN> No, it behaves virtually the same as libx264 for that [18:52:51 CEST] <BtbN> Just look at the backtrace and see what's crashing [18:55:04 CEST] <_Mike_C_> I'm not sure what you mean by that [18:56:28 CEST] <_Mike_C_> its an exception thrown from inside the avcodec-58.dll, what does "backtrace" mean [19:10:16 CEST] <ChocolateArmpits> stacktrace [19:13:58 CEST] <_Mike_C_> is there somewhere I can get debug ffmpeg dlls? Or would I have to compile them myself [19:14:55 CEST] <JEEB> if the stuff you got doesn't have debug symbols, then you need to build it yourself, yes [19:15:29 CEST] <_Mike_C_> Well, I'm using the distro dll's so they do not have debug symbols in them [19:15:46 CEST] <JEEB> > distro > windows [19:15:48 CEST] <JEEB> ? [19:15:54 CEST] <_Mike_C_> Yes [19:15:58 CEST] <JEEB> as far as I know MS doesn't distro FFmpeg [19:16:24 CEST] <JEEB> or you mean you're running something under WSL? [19:16:31 CEST] <JEEB> and then what you mean as dll is actual so files? [19:16:36 CEST] <JEEB> *actually [19:16:46 CEST] <JEEB> although I'd be surprised if nvenc would work in that case [19:17:24 CEST] <_Mike_C_> I'm confused with what you're saying. Maybe I used the wrong terminology [19:17:48 CEST] <_Mike_C_> I'm using the Windows build of ffmpeg (from the ffmpeg site) for windows, shared linking [19:17:50 CEST] <JEEB> distro = distribution , "using the distribution's DLLs" [19:18:00 CEST] <JEEB> usually used for stuff packaged by the OS vendor [19:18:08 CEST] <JEEB> _Mike_C_: the windows binaries are not from FFmpeg itself [19:18:17 CEST] <JEEB> someone just linked a 3rd party's windows builds there [19:18:26 CEST] <JEEB> FFmpeg itself only distributes source code [19:18:46 CEST] <JEEB> so you might want to ask whomever you got the binaries from for debug symbols [19:18:52 CEST] <JEEB> if those are not available, build yourself [19:20:21 CEST] <_Mike_C_> I'm literally following the links from the ffmpeg website, https://ffmpeg.zeranoe.com/builds/# [19:20:42 CEST] <_Mike_C_> is there no better way to debug this than to compile debug dll [19:20:48 CEST] <_Mike_C_> myself and use those instead? [19:28:58 CEST] <raytiley> Having trouble wrapping my head around tee and map and was hoping someone could give me a nudge in the right direction. [19:30:05 CEST] <raytiley> I have ffmpeg.exe -i captions.vtt -i video.mpg ... out.m3u8 working nowto create an hls stream. Can I use tee / map to dumb the same encoded data into an mp4 as well? [19:36:49 CEST] <ChocolateArmpits> raytiley, absolutely [19:37:31 CEST] <ChocolateArmpits> raytiley, there's an article about it https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs#Teepseudo-muxer [19:40:35 CEST] <raytiley> yup [19:41:09 CEST] <raytiley> so I tried this: -f tee -map 0:s -map 1:v 1:a "test.m3u8|test.mp4" [19:41:26 CEST] <raytiley> but I get an error about not selecting an encoder [19:41:40 CEST] <raytiley> https://www.irccloud.com/pastebin/KYNUuQ0I/output.txt [19:41:49 CEST] <ChocolateArmpits> >" -map 1:v 1:a" [19:41:55 CEST] <ChocolateArmpits> is that syntax legal [19:42:20 CEST] <_Mike_C_> Is there somewhere I can find documentation on specific encoders inside ffmpeg, like the h264_nvenc encoder? [19:43:18 CEST] <ChocolateArmpits> _Mike_C_, did you try ffmpeg -help encoder=h264_nvenc ? [19:43:30 CEST] <raytiley> copy paste error [19:43:37 CEST] <raytiley> -map 0:s -map 1:v -map 1:a [19:44:29 CEST] <_Mike_C_> I meant something more along the lines of, how to use them [19:45:01 CEST] <ChocolateArmpits> raytiley, did you specify video encoder and an audio encoder? [19:45:14 CEST] <_Mike_C_> Because BtbN says that it can use software frames, but how would I know that? The only example that covers hardware acceleration shows VAAPI and using hardware frames [19:45:46 CEST] <BtbN> Because it accepts software pix_fmts as input [19:47:05 CEST] <_Mike_C_> Ok, well clearly there are other parameters that are specific to the encoder that need to be taken care of because if I just plug and play with it, I get access violations. So I'm asking if there is somewhere I can go to read more about specific steps that need to be performed. [19:48:18 CEST] <raytiley> @ChocolateArmpits I beleive [19:48:24 CEST] <raytiley> full command is: ffmpeg.exe -y -i D:\test\captions.vtt -i D:\\content\\13127-1-vod-test-with-captions.mpg -vf scale=w=640:h=360:force_original_aspect_ratio=decrease -c:a aac -ar 48000 -c:v h264 -profile:v main -crf 20 -sc_threshold 0 -g 48 -keyint_min 48 -hls_time 4 -hls_playlist_type vod -b:v 800k -maxrate 856k -bufsize 1200k -b:a 96k -hls_segment_filename D:\\vod\\13127-vod-test-with-captions-v15/360p_%03d.ts -f tee -map [19:48:24 CEST] <raytiley> 0:s -map 1:v -map 1:a "test.m3u8|test.mp4" [19:51:32 CEST] <ChocolateArmpits> raytiley, is "h264" really an encoder? [19:52:00 CEST] <ChocolateArmpits> ok it's an alias for libx264 [19:52:02 CEST] <raytiley> yeah [19:52:24 CEST] <raytiley> so without the tee / map stuff and a single m3u8 output the command works fine [19:53:58 CEST] <ChocolateArmpits> I think this one "-hls_segment_filename" needs to go inside of the output descriptor for that particular ouput [19:54:36 CEST] <ChocolateArmpits> but I think the issue is with the caption file [19:54:42 CEST] <ChocolateArmpits> the error specifically pertains to it [19:54:56 CEST] <ChocolateArmpits> you haven't specified an encoder for it [19:55:11 CEST] <ChocolateArmpits> and aren't -c copying it [19:59:42 CEST] <raytiley> cool, I'll keep digging [20:31:51 CEST] <_Mike_C_> BtbN, can you tell me if there a special steps I have to take when setting up the encoder context for h264_nvenc [20:32:06 CEST] <BtbN> If you treat it as a software encoder, no [20:32:27 CEST] <BtbN> Just don't set any CUDA stuff [20:38:40 CEST] <qxt> I am making a manifest for some DASH adaptive video. I am getting this warning "[webm_dash_manifest @ 0x56523e975460] Could not find codec parameters for stream 0 (Video: vp9, none(progressive), 1280x720): unspecified pixel format [20:38:40 CEST] <qxt> Consider increasing the value for the 'analyzeduration' and 'probesize' options" [20:39:11 CEST] <qxt> ok so I have a unspecified pixel format. What can I do about it?= [21:01:31 CEST] <_Mike_C_> BtbN, do you know how to diagnose a "Resource temporarily unavailable error?" I got it to not throw exceptions on receive packet... but it never gives me packet back now. [21:01:56 CEST] <BtbN> Look at the backtrace and see when it happens [21:02:12 CEST] <BtbN> Does nvenc work when you use the ffmpeg cli? [21:02:20 CEST] <_Mike_C_> yes [21:05:27 CEST] <pi--> ffmpeg -loop 1 -framerate 1 -i LAST_FRAME.png -r 1 -t "$FREEZE_S" -pix_fmt yuv420p LAST_FRAME.mp4 [21:06:14 CEST] <pi--> ^ if I set FREEZE_S to 10, VLC correctly reports a 10 second video https://www.dropbox.com/s/yfu9g86iofdyt7n/Screenshot%202018-08-29%2020.06.0… [21:06:36 CEST] <pi--> But if I play it, VLC only plays it for six seconds. [21:07:38 CEST] <pi--> Can anyone tell me what's going wrong? [21:10:03 CEST] <poutine> pi--, https://trac.videolan.org/vlc/ticket/214 Any reason you wouldn't want to make output a more reasonable frame rate? [21:10:32 CEST] <poutine> I guess that says it's fixed, but I knew it used to have trouble with very low fps [21:10:37 CEST] <poutine> not sure which version you're using [21:11:21 CEST] <pi--> poutine: I'm trying to freeze the last frame of a video for 30s. [21:11:42 CEST] <pi--> I have one technique but it takes 60s+ to encode. [21:11:49 CEST] <pi--> So I'm trying out this technique instead. [21:12:12 CEST] <pi--> First I capture the last Frame. Then I create a video of the appropriate length. [21:12:27 CEST] <pi--> Then I concatenate the 2 videos [21:14:44 CEST] <pi--> It doesn't matter what I set the framerate to [21:14:52 CEST] <pi--> I still only get six seconds. [21:17:43 CEST] <pi--> Setting FREEZE_S=30, I get 26s. [21:17:53 CEST] <pi--> So it appears to be 4s short(!) [21:18:46 CEST] <pi--> 60 -> 56 [21:18:49 CEST] <pi--> so yes, 4s! [21:19:34 CEST] <pi--> So I can fix it by applying a fudge factor. but MEH. [21:20:24 CEST] <poutine> When you do a frame rate -r that matches the other video, (what frame rate did you put there) and how many frames are in the output video? What is ffprobe reporting duration as? [21:25:11 CEST] <pi--> ffprobe reports the correct duration [21:26:13 CEST] <pi--> I've been doing `ffmpeg -loop 1 -framerate 30 -i LAST_FRAME.png -r 1 -t 60 -pix_fmt yuv420p LAST_FRAME.mp4` -- but looking at the documentation I see that `-r` and `-framerate` appear to be the same. [21:26:30 CEST] <poutine> -r 1 [21:26:35 CEST] <pi--> Maybe this is a malformed instruction to ffmpeg. [21:27:42 CEST] <pi--> ah `-r 30` fixes. Thanks! [21:29:29 CEST] <pi--> `-r 5` still seems to shave a couple of seconds off [21:29:39 CEST] <poutine> how are you concatenating these videos? [21:29:53 CEST] <pi--> I haven't got that far yet. [21:30:18 CEST] <pi--> `ffmpeg -f concat -i "$SRC" -i LAST_FRAME.mp4 -c copy "$DST"` [21:30:26 CEST] <poutine> if you're using ffmpeg -f concatenate it should be the same frame rate, unless you have reason to be messing with the frame rate there it's best to work with normalized values here in my experience [21:30:29 CEST] <pi--> ^ that's my plan. [21:30:39 CEST] <poutine> I don't see why you need 5 fps or 1 fps [21:31:31 CEST] <poutine> If it's the last frame you're freezing I think there might be a simpler way as well [21:31:44 CEST] <pi--> True. My previous approach was taking a huge amount of processing time, so I was thinking maybe lowering the frame rate of the frozen portion might work. [21:32:07 CEST] <pi--> `ffmpeg -y -i "$SRC" -vf trim=0:$BLACK_S,geq=0:128:128 -af atrim=0:1,volume=0 -video_track_timescale 600 black.mp4` [21:32:26 CEST] <pi--> ^ this was my first approach, but as mentioned the processing time was crazy. [21:34:35 CEST] <poutine> pi--, what are you doing with the video in plain terms, are you freezing the last frame for 10 seconds? [21:34:50 CEST] <pi--> yes! [21:34:53 CEST] <pi--> for k seconds [21:38:06 CEST] <poutine> https://superuser.com/questions/1250900/freeze-last-frame-of-a-video-with-f… [21:38:14 CEST] <poutine> check that super hacky way, I think there has to be a different way [21:46:24 CEST] <pi--> https://paste.pound-python.org/show/64YYm7zQ9u7Yxzy3a0Vc/ [21:46:33 CEST] <pi--> ^ I don't understand the error here [22:26:47 CEST] <pi--> Okay, I'm really close to having something working [22:26:57 CEST] <pi--> It even worked once! [22:27:04 CEST] <superlinux> hello. I want to merge two videos side by side. but I want the second video to start showing from a point in time of the first. how can I achieve that? [22:27:07 CEST] <pi--> But I cannot replicate. [22:27:10 CEST] <pi--> https://paste.pound-python.org/show/91GrAYFsmsYZarUP8D27/ [22:27:19 CEST] <pi--> It is the final concatenation that is giving trouble. [22:27:26 CEST] <pi--> The screen goes duck-blue. [22:27:45 CEST] <pi--> Rather than freezing on the correct final frame. [22:40:00 CEST] <poutine> superlinux, Can you explain what you mean "showing from a point in the time of the first", do you really mean "the videos should start at different times"? [22:40:27 CEST] <DHE> I assume he wants to synchronize them at some point in time which is not frame 0 [22:42:01 CEST] <pi--> I am falling at the final hurdle. I just can't get my videos to concatenate. [22:42:02 CEST] <superlinux> I want them next to each other. however, the one of them will start showing after lets say 15 min from the start of the 1st one. it's just i have done two facebook lives [22:43:35 CEST] <superlinux> two live broadcasts from two different phones. [22:44:03 CEST] <superlinux> there is a camera I started it like 15 minutes later. [22:45:48 CEST] <poutine> just seeking the input should accomplish that, would it not? [22:48:27 CEST] <poutine> ffmpeg -ss 00:15:00 -i <video you want to start 15 minutes in on> -i <some other one> w/ hstack filter for side by side [22:48:44 CEST] <superlinux> ok thanks [00:00:00 CEST] --- Thu Aug 30 2018

1 0

ffmpeg-devel.log.20180828
by burek 29 Aug '18

29 Aug '18

[00:18:17 CEST] <cone-704> ffmpeg 03Rostislav Pehlivanov 07master:6213cf73945d: atrac9dec: relax gradient value requirements [00:18:18 CEST] <cone-704> ffmpeg 03Rostislav Pehlivanov 07master:ea82ff81e4ae: atrac9dec: implement LFE channel decoding [00:18:36 CEST] <atomnuker> now all files from thealexbarney's crazy testset decode correctly! [00:24:41 CEST] <JEEB> nice [05:18:32 CEST] <atomnuker> holy shit [05:19:09 CEST] <atomnuker> on the vita version of va11 hall-a some tracks have been converted to .ogg with ffmpeg [05:19:15 CEST] <atomnuker> as in ffmpeg.c [05:19:27 CEST] <atomnuker> from the official released soundtrack [05:19:51 CEST] <atomnuker> how do I know this? they forgot to disable the theora video stream ffmpeg will create by default for .ogg files [05:30:29 CEST] <TD-Linux> lul. let me check the pc version. what does it take to fix that wonderful ffmpeg.c behavior [05:49:02 CEST] <cone-889> ffmpeg 03Rostislav Pehlivanov 07master:964819fefdd1: atrac9dec: clean up code slightly [05:49:12 CEST] <atomnuker> disable theora as the default video codec for .ogg [06:01:34 CEST] <TD-Linux> can ffmpeg.c discern between .ogv and .ogg? [06:03:34 CEST] <atomnuker> yeah, I think so, it knows the difference between .mka and .mkv [06:41:57 CEST] <cone-889> ffmpeg 03Gyan Doshi 07master:26dc76324564: ffmpeg: add correct field for raw pts in -progress report [12:29:20 CEST] <durandal_1707> http://nico-lab.net/vmaf_score_using_deinterlace-denoise_filters/ [12:32:01 CEST] <thardin> moon language [12:35:35 CEST] <kierank> iiuc vmaf sucks on sports [12:35:37 CEST] <kierank> with grass [12:35:47 CEST] <kierank> but netflix doesn't do sports so their test corpus doesn't notice [12:50:38 CEST] <LigH> Hi. [12:50:50 CEST] <durandal_1707> hi [12:51:16 CEST] <LigH> Is there a common naming convention between a library to be linked into ffmpeg and the related pkg-config file (*.pc)? [12:53:14 CEST] <LigH> Specifically, is it necessary to have a lin/pkgconfig/liblensfun.pc to link lib/liblensfun.a ? [12:53:25 CEST] <LigH> *lib/ [12:56:27 CEST] <LigH> The building of lensfun generates lib/pkgconfig/lensfun.pc (without "lib") instead. That seems to be part of an issue. [12:56:46 CEST] <jkqxz> It depends on the convention for that library. In the case of lensfun it looks like the pkg-config component is called "lensfun". [12:59:13 CEST] <LigH> wiiaboo (author of the media-autobuild_suite) believes that ffmpeg expects a liblensfun.pc instead: [12:59:16 CEST] <LigH> https://github.com/jb-alvarado/media-autobuild_suite/issues/899#issuecommen… [12:59:51 CEST] <jkqxz> That's checked at <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=configure;h=3cf9412947b332d4…> - the second argument to the (require|check)_pkg_config call is the name of the pkg-config component (the first argument is the ffmpeg config name). [13:00:40 CEST] <jkqxz> RiCON: ^ [13:03:03 CEST] <LigH> Well, maybe there is a different reason why pkg-config cannot find a component which has been built and installed moments ago. I do not know the suite inwards, I'm only using it (and meddling with it a little, sometimes). [13:03:17 CEST] <LigH> I don't know shell script syntax, only guessing. [13:03:28 CEST] <LigH> Trial and error. [13:04:37 CEST] <LigH> And unfortunately, support for the suite starts decreasing. [13:16:11 CEST] <LigH> The error message is: "ERROR: lensfun not found using pkg-config"; so somehow I believe the problem is not the name, but a missing registration during its installation after building? [13:18:41 CEST] <nevcairiel> all the files would of course also have to be put into the correct place so that pkg-config can find it [13:19:34 CEST] <nevcairiel> there is no "registration" outside of having a lensfun.pc somewhere that pkg-config is going to check for it [13:31:07 CEST] <BBB> jkqxz: did you see the pleas yesterday for you to please please attend VDD? [13:31:24 CEST] <LigH> So maybe pkg-config doesn't know to look in that directory... [13:31:32 CEST] <BBB> kierank: does it? that would be interesting to bring up on their bug tracker [13:32:30 CEST] <kierank> BBB: ateme gave a presentation saying it does [13:32:37 CEST] <kierank> and I would take ateme's word for it [13:32:48 CEST] <BBB> interesting [13:32:49 CEST] <kierank> https://www.theiabm.org/wp-content/uploads/2018/05/Ateme-OTT-event.pdf [13:32:54 CEST] <kierank> unfortunately many marketing slides [13:34:01 CEST] <LigH> (Rémoulade is spoiled) [13:34:08 CEST] <BBB> that might actually be related to an AQ-related weighting issue I brought up with them earlier [13:34:14 CEST] <BBB> looks like it, at least [13:34:31 CEST] <BBB> you can see that the audience on top in the left picture has more details than on the right [13:35:18 CEST] <BBB> and the weighting (suspected) bug is that I dont think the weighting of different parts of a frame are different [13:35:30 CEST] <BBB> for different frames in a sequence, the weighting *is* different [13:35:45 CEST] <BBB> so I think they shouldve done that intra-frame also [13:36:01 CEST] <BBB> (this is supposedly very difficult to do, and Im not smart enough to be able to do it myself :-( ) [13:36:08 CEST] <jkqxz> BBB: I did; I'm afraid I won't make it this year. [13:37:03 CEST] <BBB> sorry to hear :( [13:43:44 CEST] <durandal_1707> give me something easy to do! [14:36:29 CEST] <LigH> Regarding lensfun, I found a linker error, I believe. May I show you the tail of ffbuild/config.log? [14:37:50 CEST] <durandal_1707> yes, use pastebin or similar [14:39:14 CEST] <LigH> https://pastebin.com/CBe4jc2i [14:39:32 CEST] <LigH> undefined reference to `_imp__g_utf8_skip' [14:42:18 CEST] <jamrial> that seems to be from glib2 [14:42:30 CEST] <LigH> Complete archive of MABS logs = https://0x0.st/stTc.zip [14:42:32 CEST] <nevcairiel> the usual reason for such problems is that the libraries .pc file is incomplete [14:43:46 CEST] <nevcairiel> if it needs glib, then the .pc file needs to indicate that [14:43:50 CEST] <jamrial> what do you get from running " pkg-config --libs lensfun" vs "pkg-config --libs --static lensfun"? [14:43:51 CEST] <nevcairiel> otherwise how is ffmpeg to know [14:45:28 CEST] <LigH> https://pastebin.com/iabRDHcn [14:46:28 CEST] <jamrial> well, there you go. you have a static build of lensfun, so simply run configure with --pkg-config-flags=--static [14:46:53 CEST] <nevcairiel> the config.log shows it actually tried to link with glib [14:46:55 CEST] <nevcairiel> it just didnt work [14:47:43 CEST] <LigH> Could it be a required-version conflict? MSYS2 packages had them sometimes. [14:47:53 CEST] <nevcairiel> probably because its windows and the symbol is not named _imp__g_utf8_skip, but just _g_utf8_skip [14:48:26 CEST] <Yagiza> Is this a better place to discuss RTP? [14:49:51 CEST] <nevcairiel> https://github.com/Alexpux/MINGW-packages/issues/988 seems vaguely related [14:50:02 CEST] <Yagiza> How can I specify sdp_flags=custom_io option to make it work? [14:50:04 CEST] <nevcairiel> static linking everything is usually a nightmare of manual fixings [14:51:33 CEST] <Yagiza> Also, I wonder, which file contains code for SDP demuxing? sdp.c or rtsp.c? [14:52:24 CEST] <LigH> nevcairiel, it mentions a flag -DGLIB_STATIC_COMPILATION ... I will share that issue, thank you. [14:52:45 CEST] <nevcairiel> you probably need that when building lensfun, not when building ffmpeg, fwiw [14:54:02 CEST] <LigH> Yes. I will test that. [14:54:09 CEST] <LigH> It looks like a CMake flag. [14:54:28 CEST] <nevcairiel> its a compiler flag for gcc [14:54:31 CEST] <nevcairiel> to define that macro [14:55:25 CEST] <LigH> Hmm, then I need to discover how to patch the suite. And possibly only for the case that ffmpeg will be built statically. [15:25:25 CEST] <BBB> do I use GRAY16 for 10-bit 4:0:0? [15:25:29 CEST] <BBB> as AvPixelFormat [15:26:50 CEST] <j-b> 10bit 4:0:0? [15:26:54 CEST] <j-b> what? [15:28:22 CEST] <BBB> all modern video codecs have it; dont ask me why [15:28:33 CEST] <j-b> why? [15:28:34 CEST] <j-b> :D [15:30:48 CEST] <thardin> medical stuff? [15:33:07 CEST] <durandal_1707> BBB: no, there is 10 bit gray [15:43:15 CEST] <BBB> ah ok cool [16:18:50 CEST] <LigH> There is support for chroma subsampling i400, I do remember that x265 supports Y4M with e.g. "mono10" as color space marker... but not sure what ffmpeg expects in which options. [16:19:36 CEST] <LigH> 400p10 seems not to exist. [16:19:48 CEST] <nevcairiel> those formats are called gray [16:20:05 CEST] <nevcairiel> there is no chroma subsampling, chroma is just non-existant [16:22:16 CEST] <LigH> Yes, gray10 exists. [16:22:44 CEST] <LigH> For -pix_fmt [16:23:54 CEST] <LigH> Bye. [17:15:00 CEST] <atomnuker> BBB: haha, av1 doesn't [17:15:14 CEST] <BBB> huh what? [17:15:23 CEST] <atomnuker> you can partially thank luc and CFL for av1 lacking 4:1:1 support [17:16:15 CEST] <BBB> Ive never heard of 4:1:1 [17:16:20 CEST] <BBB> you mean 4:4:0? [17:17:00 CEST] <atomnuker> I thought it was 4:1:1, it was vertical subsampling without horizontal subsampling, for cheapo DVs [17:17:30 CEST] <atomnuker> er, the opposite of 422 [17:17:45 CEST] <BBB> vp9 called that 440 [17:17:56 CEST] <BBB> and yes Im glad it was deleted, dumbest thing ever [17:19:07 CEST] <nevcairiel> 411 and 440 are different, not many people probably know exactly how that syntax works, but with the help of the wikipedia article i can usually decipher it =p [17:19:50 CEST] <durandal_1707> 411 have horizontal subsampling only [17:20:14 CEST] <atomnuker> if we had cut 422 derf might have been almost happy with the codec but there's no way we could, lack of interlacing and lack of limited range rgb was the best we could do to make it seem like a codec for the future [17:21:36 CEST] <nevcairiel> the 4 is basically constant, the first digit is the number of chroma samples in the first row of samples, the second number is the number of chroma samples in the second row. so 411 has one sample in the first row, and one sample in the second row, ie. 1/4th horizontal, full vertical [17:21:48 CEST] <nevcairiel> while 440 has full horizontal, and half vertical [17:22:12 CEST] <nevcairiel> (always refering a 4x2 grid of pixel) [17:22:35 CEST] <durandal_1707> wrong [17:22:37 CEST] <BBB> 422 is totally b0rk3d is you ask me [17:22:41 CEST] <BBB> (422 in av1) [17:23:10 CEST] <nevcairiel> whats with 422 always being special [17:23:24 CEST] <nevcairiel> for some reason in h264 422 was also so different, while 444 then again was similar to 420 [17:23:27 CEST] <durandal_1707> for 411 see y41pdec and prosumer.c in lavc [17:24:24 CEST] <BBB> honestly, in av1, I dont know [17:24:41 CEST] <BBB> it appears they wanted to use consistet BLOCK_SIZE ratios for all subsamplings [17:24:59 CEST] <BBB> and since uneven hor vs. ver subsampling means different blocksize ratios, it means some partitionings are disallowed in av1 422 [17:25:10 CEST] <BBB> the rules for it are weird, if you ask me [17:25:52 CEST] <BBB> e.g. 1:4 is allowed in 444/420, but 1:2 *and* 1:4 are disallowed in 422 because 1:4 turns into 1:8 and 1:2 something something ?????? [17:26:13 CEST] <nevcairiel> i guess that makes some sense [17:26:15 CEST] <BBB> either 1:2 disallowing had to do with 128x128 special rules, or with a bug in the 4x8 blocks [17:26:26 CEST] <BBB> but its still crazy to not allow it at all, no reason for it IMO [17:31:14 CEST] <kierank> some hardware bullshit iirc [17:34:56 CEST] <BBB> ... [17:35:46 CEST] <BBB> I have a feeling that many quetionable design decisions - not just in av1, but really everywhere - are often attributed to some crazy hw bullshit without anyone really understanding what was actually going on; and thats a problem [17:36:13 CEST] <nevcairiel> well some hardware guy probably does [17:36:17 CEST] <nevcairiel> but we're all software guys [17:36:50 CEST] <BBB> so hw supports 422? [17:37:47 CEST] <nevcairiel> not sure speaking in present tense about av1 hardware is going to be accurate [17:37:50 CEST] <atomnuker> yes, some should in the future, the pro profile provides support for it [17:38:22 CEST] <nevcairiel> pro-hardware also supports 422 h264, because thats used for broadcast streams, but of course consumer never did [17:41:14 CEST] <atomnuker> I'm not sure if the hardware companies are to blame, they were mostly civilized [17:41:56 CEST] <atomnuker> ...when they bothered to finally evaluate a coding tool's impact, most of the time they were a bit lazy [18:27:47 CEST] <kurosu> atomnuker, is 422 always 10 bits? [18:28:09 CEST] <kurosu> conversely, can 422 be 8 bits [18:29:31 CEST] <atomnuker> absolutely [18:30:07 CEST] <atomnuker> though if you ask some people the only true pro 422 is 10 bits [18:30:16 CEST] <kurosu> exactly [18:30:23 CEST] Action: kurosu asking for a friend [20:03:14 CEST] <BBB> for a friend :D [20:03:49 CEST] <BBB> kurosu: all these things are planar, just like h264/hevc, so bitdepth vs. chroma subsampling are completely unrelated [20:10:13 CEST] <atomnuker> unless someone brings v210 or bitpacked into the mix in which subsampling and depth are very related [20:15:53 CEST] <kurosu> people like having profile mandating stuff [20:16:14 CEST] <kurosu> profiles [20:16:46 CEST] <kurosu> though I'm really unsure the selling point of av1 matters to the pro users [20:16:55 CEST] <kurosu> (point or points) [20:17:10 CEST] <kurosu> s/the/such [20:18:13 CEST] <atomnuker> you need pro profile to decode 422 anyway which already includes support for 10 and 12 bits [20:18:59 CEST] <atomnuker> I don't remember what levels include each though, the levels were a mess and I'm glad I've forgotten what happened [20:20:54 CEST] <BradleyS> durandal_1707: what's your method for benchmarking prores? [20:21:13 CEST] <BradleyS> i was going to dump to a fast disk but to mem discard would probably be better [20:21:33 CEST] <nevcairiel> just do -f null - [20:22:02 CEST] <BradleyS> ah, perfect [20:31:42 CEST] <durandal_1707> reduced scpr version 3 line count by -200, still many remaining for rewrite [20:47:48 CEST] <BradleyS> Stream #0:0(und): Video: wrapped_avframe, yuv422p10le, 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc (default) [20:47:48 CEST] <BradleyS> frame=18000 fps=658 q=-0.0 Lsize=N/A time=00:10:00.60 bitrate=N/A speed=21.9x [20:47:55 CEST] <BradleyS> multithreaded from ramdisk [20:48:29 CEST] <BradleyS> xeon w3680 on macos [20:48:40 CEST] <durandal_1707> and now with -thread_type slice? [20:48:41 CEST] <BradleyS> (well, vice versa) [20:49:54 CEST] <BradleyS> i should have averaged multiple, it's more like 665 [20:49:59 CEST] <BradleyS> sliced, 669 [20:50:27 CEST] <BradleyS> that said, this is pre-haswell and 1333 mhz ddr3 [20:51:11 CEST] <BradleyS> newer arch probably performs better with frame threading, we've seen similar differences between pre-haswell and say skylake with handbrake's nlmeans denoiser and frame threads [20:51:42 CEST] <BradleyS> it's possible i'm memory bound, basically [20:53:51 CEST] <BradleyS> speed test shows ramdisk 2550/1300 MB/s read/write [20:54:50 CEST] <durandal_1707> BradleyS: how much RAM? [20:55:33 CEST] <BradleyS> 24 GB, about 10 free (i made sure to free up as much as possible) [20:56:11 CEST] <BradleyS> going to try smaller and larger frame sizes [20:56:23 CEST] <durandal_1707> BradleyS: -thread_type is input option [20:57:41 CEST] <BradleyS> oof, that's probably it too, give me a moment [21:07:28 CEST] <BradleyS> ffmpeg -thread_type slice -i /Volumes/ramdisk/720p.mov -f null - [21:07:28 CEST] <BradleyS> Stream #0:0(und): Video: wrapped_avframe, yuv422p10le, 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc (default) [21:07:28 CEST] <BradleyS> frame=18000 fps=497 q=-0.0 Lsize=N/A time=00:10:00.60 bitrate=N/A speed=16.6x [21:07:28 CEST] <BradleyS> video:9422kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown [21:08:01 CEST] <BradleyS> so that is a nice speedup after all [21:08:13 CEST] <atomnuker> durandal_1707: btw I have some .binka files, wanna take a look at them? [21:08:22 CEST] <BradleyS> about 33% [21:09:06 CEST] <durandal_1707> atomnuker: looked at their decoder/encoder, probably imdct based [21:10:20 CEST] <durandal_1707> i think i removed/lost dlls [21:10:55 CEST] <BradleyS> 480p 1075/1224 fps [21:11:17 CEST] <BradleyS> 720p 497/665 fps [21:13:47 CEST] <BradleyS> will take awhile for my 1080p and 2160p to render, will report back in a bit [21:22:08 CEST] <durandal_1707> atomnuker: i still have them. binkawin.asi and few binka samples [21:22:26 CEST] <durandal_1707> only 54k [21:22:44 CEST] <durandal_1707> should be straightforward to RE even for noobs [21:30:56 CEST] <durandal_1707> actually there is one small problem [21:31:51 CEST] <durandal_1707> ida reports call analysis failed for main function responsible for stream decompression [21:32:25 CEST] <durandal_1707> and i haven't looked much after that [21:33:46 CEST] <jamrial> atomnuker: ^ [21:43:39 CEST] <BradleyS> 1080p 261/339 [21:49:41 CEST] <jamrial> atomnuker: libfdk-aac also sets the correct 5.0/5.1 layouts, yet the resulting file doesn't end up with ffprobe saying channel_layout=unknown [21:50:53 CEST] <atomnuker> they don't implement PCEs, so the decoder's probably doing something [21:51:46 CEST] <BradleyS> 2160p 75/93 fps [21:52:09 CEST] <BradleyS> durandal_1707: is there somewhere you would like me to post the results? [21:54:58 CEST] <nevcairiel> if ffmpeg itself cannot recognize the layout of those PCE files, then you should consider that a bug no matter what [21:55:04 CEST] <nevcairiel> perhaps in the decoder, but there is definitely a bug [21:55:36 CEST] <atomnuker> I know, I'm looking into it [21:57:42 CEST] <durandal_1707> BradleyS: on twitter? [22:09:46 CEST] <BBB> jamrial: should I stop asking? & [22:10:13 CEST] <durandal_1707> jamrial: just accept invitation [22:10:21 CEST] <BradleyS> durandal_1707: whether you were serious or not, here it is https://twitter.com/bradleysepos/status/1034533519530315776 [22:10:22 CEST] <BradleyS> thanks [22:10:42 CEST] <jamrial> BBB: yes, it would help a lot in making up my mind if i'm not badgered about it all the time [22:11:18 CEST] Action: BBB will shut up [22:11:38 CEST] <nevcairiel> Big Bad Badger? [22:11:40 CEST] <nevcairiel> it all makes sense [22:15:07 CEST] <durandal_1707> for me BBB always stand for Big Buck Bunny [22:15:30 CEST] <nevcairiel> absolutely, but he insists he came before [22:16:35 CEST] <jamrial> i met him before i ever watched that short, so the other way around for me [22:26:58 CEST] <atomnuker> for me BBB means Bromley-By-Bow [22:27:50 CEST] <BradleyS> https://www.google.com/search?q=htda+bbb [22:27:52 CEST] <atomnuker> which is 2 stops away from Mile End where you can transfer for the central line to evade the constant delays on the District/H&C line just before Aldgate [22:28:54 CEST] <durandal_1707> atomnuker: you just wrote what? [22:31:20 CEST] <atomnuker> yes, each ride on the underground is traumatic enough to remember if you go to heathrow [22:32:09 CEST] <atomnuker> "I can cheat the system and go to the central line, and take the picadilly line or the heathrow express!" goes through the minds of most travellers crossing the city from the east to heathrow [22:33:28 CEST] <atomnuker> but no, turns out time wise its actually better to suffer going through all the stops on the district line (20ish) and transfer for the picadilly line on gloucester road [22:36:38 CEST] <atomnuker> the elizabeth line might speed things up a lot and maybe even make the hyperexpensive heathrow express redundant but that opens in december, according to schedule [22:39:51 CEST] <atomnuker> I should be in madrid by then if things go well enough, ~15 minutes on the tube from the center to the airport, it takes me 2h 30m here [22:40:42 CEST] Action: BradleyS wishes he had rapid underground/rail transport [22:41:48 CEST] <BradleyS> this is as far as my state has gone with it https://en.wikipedia.org/wiki/Ohio_Hub [22:41:55 CEST] <BradleyS> no current funding, all but dead [22:42:23 CEST] <BradleyS> the longer we wait the more crowded roads become, it's literally 3-4x worse than it was 10 years ago where i live now [22:44:03 CEST] <BradleyS> with distracted driving (texting) it's pretty nightmarish, narrowly avoid accidents every single drive [22:45:13 CEST] <robUx4> michaelni: can you hear us in the meeting ? [22:47:25 CEST] <durandal_1707> ? [22:54:05 CEST] <atomnuker> turns out that our aac decoder instantly gives up if AAC_CHANNEL_SIDE is present in the layout map parsed from PCEs [22:54:27 CEST] <atomnuker> peloverde: do you have the time to look at it? [23:02:43 CEST] <peloverde> I'm too busy right now, sorry. [23:03:16 CEST] <atomnuker> k, I think we're signalling PCEs badly too [00:00:00 CEST] --- Wed Aug 29 2018

1 0

ffmpeg.log.20180828
by burek 29 Aug '18

29 Aug '18

[00:01:27 CEST] <LigH> Well, maybe I found the position. [00:02:37 CEST] <LigH> I just need someone understanding shell scripts to confirm [00:02:49 CEST] <LigH> Or blindly test and hope [00:22:08 CEST] <LigH> OK, I got lensfun built in media-autobuild suite. Waiting for ffmpeg to link it too... [00:22:13 CEST] <LigH> Bye for now. [00:31:58 CEST] <pi-> ffmpeg seems to be refusing to process certain MP3 files [00:32:16 CEST] <pi-> I'm getting "[mp3 @ 0x55eb48657e40] Format mp3 detected only with low score of 1, misdetection possible!" [00:32:24 CEST] <pi-> Then "[mp3 @ 0x55eb48657e40] Failed to read frame size: Could not seek to 1327." [00:32:38 CEST] <pi-> Is there any sensible next step? [00:32:48 CEST] <pi-> Or have I reached a dead-end? [00:33:01 CEST] <DHE> you sure the file isn't corrupted? [00:36:00 CEST] <LigH> May it have a large ID3 tag (e.g. with lyrics or cover)? [00:38:30 CEST] <LigH> My test failed in ffmpeg's configure step: "lensfun not found using pkg-config" [00:38:41 CEST] <LigH> I'm out. [00:38:45 CEST] <LigH> GN8 [04:05:44 CEST] <hojuruku> I'm not having much luck with ffmpeg kmsgrab on amdgpu gcn 1.4 https://pastebin.com/pxjZVa6q [04:07:20 CEST] <hojuruku> [pid 28577] ioctl(5, DRM_IOCTL_AMDGPU_GEM_CREATE or DRM_IOCTL_VIA_ALLOCMEM, 0x7ffe6e9d1ac0) = 0 [pid 28577] ioctl(5, _IOC(_IOC_READ|_IOC_WRITE, 0x64, 0x48, 0x28), 0x7ffe6e9d1b00) = 0 [pid 28577] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x15c} --- system call trace [05:16:53 CEST] <hojuruku> https://superuser.com/questions/908280/what-is-the-correct-way-to-fix-keyfr… ok I got it working.... [05:17:08 CEST] <hojuruku> now to set the keyint with vaapi - what options does it support? [06:04:41 CEST] <hojuruku> "Please check the video resolution. The current resolution is (65535x65535), which is not optimal." says youtube but ffmpeg reports 1080p [06:57:57 CEST] <hojuruku> yeah can't get around that youtube glitch. How to I KMS grab on the amd - hwdownload - then upload to the intel for encoding? [06:59:29 CEST] <hojuruku> DRI_PRIME=1 ffmpeg -threads 4 -framerate 15 -device /dev/dri/card1 -thread_queue_size 1024 -f kmsgrab -i - -f lavfi -i anullsrc=channel_layout=stereo:r=44100 -ar 44100 -init_hw_device vaapi=amd:/dev/dri/renderD129 -filter_hw_device amd -filter:v hwmap,hwupload,format=nv12 -init_hw_device vaapi=intel:/dev/dri/renderD128 -filter_hw_device intel -filter:v hwdownload,format=nv12 -c:v h264_vaapi -g 30 -bf 0 -profile:v constrained_baseline -level:v 4 [06:59:29 CEST] <hojuruku> -coder:v cavlc -qp 23 -codec:a aac -b:a 128k -f flv rtmp://a.rtmp.youtube.com/live2/ [07:09:43 CEST] <hojuruku> ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel_output_format vaapi -framerate 30 -device /dev/dri/card1 -f x11grab -i :0.0 -f lavfi -i anullsrc=channel_layout=stereo:r=48000 -threads 4 -vf 'format=nv12,hwupload' -g 60 -c:v h264_vaapi -qp 24 -bf 0 -coder:v cavlc -profile:v constrained_baseline -level 4.1 -acodec aac -ar 48000 -b:a 128k -f flv rtmp://a.rtmp.youtube.com/live2/ [07:10:00 CEST] <hojuruku> that's what's "works" with youtube but the screen can't start because the screen dimensions are wrong [07:10:33 CEST] <hojuruku> "Please check the video resolution. The current resolution is (65535x65535), which is not optimal." [07:10:49 CEST] <hojuruku> (in VBR mode) [07:12:01 CEST] <hojuruku> DRI_PRIME=1 LIBVA_DRIVER_NAME=intel ffmpeg -threads 4 -framerate 15 -device /dev/dri/card1 -thread_queue_size 1024 -f kmsgrab -i - -f lavfi -i anullsrc=channel_layout=stereo:r=44100 -ar 44100 -init_hw_device intel=v:/dev/dri/renderD128 -filter_hw_device v -filter:v hwmap,scale_vaapi=format=nv12 -video_size 1920x1080 -c:v h264_vaapi -g 30 -bf 0 -profile:v constrained_baseline -level:v 4.1 -coder:v cavlc -qp 23 -codec:a aac -b:a 128k -aspect 16: [07:12:01 CEST] <hojuruku> flv rtmp://a.rtmp.youtube.com/live2/ [07:12:17 CEST] <hojuruku> sorry that's the "working" line as sending data to youtube [07:12:50 CEST] <hojuruku> (with -hw_device intel (should be amd on both of them) you get the idea... [11:02:27 CEST] <Yagiza> Are there any news about RTP/SDP implementation/usage? [11:06:33 CEST] <Mavrik> What do you mean news? :) [11:06:37 CEST] <Mavrik> It works? [11:09:40 CEST] <Yagiza> I have some questions and noone could help me a few weeks ago when I asked here. [11:10:23 CEST] <Yagiza> So, maybe RTP profi appeared? [11:11:22 CEST] <Yagiza> The question was about sdp_flags=custom_io option. [11:14:36 CEST] <Yagiza> When I specify this option for format with avformat_open_input() via dictionary, it accepts the option, but nothing happens. [11:15:32 CEST] <Yagiza> It still listens the port specified in SDP instead of listening the I/O used to provide SDP. [11:16:52 CEST] <Yagiza> But when I specify the option for ffplay.exe, it do not play. So it seems the option works with ffplay.exe. [11:17:22 CEST] <Yagiza> So, I'm looking for any working example of using the option. [11:18:17 CEST] <Yagiza> Of any example of specifying RTCP port when using SDP demuxer. [11:43:18 CEST] <Mavrik> I'd look at sdp demuxer and see if it's not hardcoded [11:43:21 CEST] <Mavrik> (source that is) [11:51:12 CEST] <Yagiza> Mavrik, I just wonder if SDP demuxer is in srtp.c/h or sdp.c/h. [11:51:31 CEST] <Mavrik> Last time I worked with it, it was in sdp.c [11:51:53 CEST] <Yagiza> Mavrik, it seems sdp.c/h contains SDP muxer only. And SDP demuxer is in rtsp.c/h. But I'm not sure. [11:53:19 CEST] <Yagiza> Mavrik, I didn't find any SDP parser code in sdp.c. Only SDP builder. [11:53:46 CEST] <Yagiza> Mavrik, but I see SDP parsing in rtsp.c. [11:56:40 CEST] <Yagiza> Mavrik, is #ffmpeg-devel a better place to discuss such things? [12:47:29 CEST] <barhom> Hello, trying apples mediastreamvalidator on some HLS created with ffmpeg. Scaling using "-2:240" [12:47:46 CEST] <barhom> Video is getting scaled to 300x240 (reported in vlc), but mediastreamvalidator is still saying, [12:47:55 CEST] <barhom> Error: Playlist video resolution doesn't match parsed video resolution [12:47:55 CEST] <barhom> --> Detail: Playlist: 300 x 240, Video: 426 x 240 [12:48:03 CEST] <barhom> Does this have anything to do with setsar or similar? [13:37:19 CEST] <barhom> anything to do with setsar? [15:08:45 CEST] <Yagiza> For options like this: [15:08:56 CEST] <Yagiza> -err_detect <flags> .D.VA... set error detection flags (default 0) [15:08:56 CEST] <Yagiza> crccheck .D.VA... verify embedded CRCs [15:08:56 CEST] <Yagiza> bitstream .D.VA... detect bitstream specification deviations [15:08:56 CEST] <Yagiza> buffer .D.VA... detect improper bitstream length [15:08:56 CEST] <Yagiza> explode .D.VA... abort decoding on minor error detection [15:08:56 CEST] <Yagiza> ignore_err .D.VA... ignore errors [15:08:56 CEST] <Yagiza> careful .D.VA... consider things that violate the spec, are fast to check and have not been seen in the wild as errors [15:08:57 CEST] <Yagiza> compliant .D.VA... consider all spec non compliancies as errors [15:08:57 CEST] <Yagiza> aggressive [15:10:21 CEST] Action: DHE abandons the flooding ship [15:10:23 CEST] <Yagiza> Is it possible to specify more than one option, or they are mutually exclusive? [15:10:53 CEST] <durandal_1707> Yagiza: use + for flags options [15:11:08 CEST] <Yagiza> durandal_1707, thanx [15:11:19 CEST] <durandal_1707> -err_detect buffer+explode [15:15:50 CEST] <Yagiza> durandal_1707, when specifying options with AVDictionary, the same rule applied? [15:33:40 CEST] <durandal_1707> Yagiza: for every option for type <flags> [15:37:03 CEST] <Yagiza> durandal_1707, thanx [15:38:46 CEST] <Yagiza> durandal_1707, and what about AV_OPT_TYPE_CONST? [15:48:05 CEST] <durandal_1707> Yagiza: it is for using in C [15:54:06 CEST] <Yagiza> durandal_1707, that's what I need [15:54:45 CEST] <Yagiza> durandal_1707, I have this option: [15:55:21 CEST] <Yagiza> static const AVOption sdp_options[] = { [15:55:21 CEST] <Yagiza> RTSP_FLAG_OPTS("sdp_flags", "SDP flags"), [15:55:21 CEST] <Yagiza> { "custom_io", "use custom I/O", 0, AV_OPT_TYPE_CONST, {.i64 = RTSP_FLAG_CUSTOM_IO}, 0, 0, DEC, "rtsp_flags" }, [15:55:21 CEST] <Yagiza> ... [15:55:21 CEST] <Yagiza> }; [15:55:46 CEST] <Yagiza> durandal_1707, I try to set it with av_dict_set() [15:57:23 CEST] <Yagiza> durandal_1707, then pass it to demuxer as "options" parameter of avformat_open_input(). [15:58:21 CEST] <Yagiza> durandal_1707, I specify "sdp_flags" as option name, and "custom_io" as string value. [15:58:43 CEST] <Yagiza> durandal_1707, but it seems the option is ignored. [15:59:24 CEST] <Yagiza> durandal_1707, but when I pass it to ffplay.exe as -sdp_flags custom_io, it works! [15:59:53 CEST] <Yagiza> durandal_1707, so, I try to figure out, what's wrong with my code? [16:02:07 CEST] <durandal_1707> show me the code [16:09:02 CEST] <Yagiza> durandal_1707, one moment, please. I need to check something. [16:42:37 CEST] <Yagiza> durandal_1707, where can I paste my code? [16:43:24 CEST] <tdr> Yagiza, https://paste.pound-python.org [16:44:56 CEST] <Yagiza> tdr, thanx [16:45:26 CEST] <Yagiza> durandal_1707, oh! I found a bug in my code. It seems to be working right now. [16:45:44 CEST] <Yagiza> durandal_1707, but I need to write more code to check it. [17:02:18 CEST] <mixfix41> arg on arm trying to play ffplay in full screen mode, but it doesn't play very well compared to firefox on the same machine. but there was a change in xorg.conf and some libraries added to get firefox playing that way [17:09:11 CEST] <durandal_1707> mixfix41: use mpv [17:26:43 CEST] <DHE> mixfix41: ffplay is more of a demo application or to do some filter testing. it's not intended as a fully featured consistent video player [17:30:23 CEST] <salatfreak> Hey ho! I'd like to cut out a segment of a long h264 video but only reencode the stream before the first keyframe and after the last keyframe in the time range and copy the rest in between. What's the best way to go about that? [17:38:04 CEST] <mixfix41> good to know [17:46:19 CEST] <salatfreak> When using '-ss' and '-t' to cut out a segment from a video with the '-c copy' option, can I specify that I want the nearest keyframes *before* the start time and *after* the end time selected? [17:46:45 CEST] <DHE> ending usually doesn't need to be on a keyframe [17:59:17 CEST] <salatfreak> DHE: Then I'd only need to worry about the first keyframe to be before the specified start time. Is there a solution for that? [17:59:44 CEST] <DHE> if you're looking to cut the video into keyframe segments, I suggest looking at the "segment" muxer [18:07:32 CEST] <salatfreak> DHE: My goal is to cut out a segment at exact times without reencoding more than necessary. [18:10:01 CEST] <hojuruku> RI_PRIME=1 LIBVA_DRIVER_NAME=radeonsi ffmpeg -threads 8 -framerate 24 -device /dev/dri/card1 -thread_queue_size 1024 -f kmsgrab -i - -f lavfi -i anullsrc=channel_layout=stereo:r=44100 -ar 44100 -init_hw_device vaapi=amd:/dev/dri/renderD129 -filter_hw_device amd -filter:v hwmap,scale_vaapi=format=nv12 -video_size 1920x1080 -c:v h264_vaapi -max_delay 500000 -g 48 -keyint_min 48 -force_key_frames "expr:gte(t,n_forced*3)" -bf 0 -profile:v [18:10:01 CEST] <hojuruku> constrained_baseline -level:v 4.1 -coder:v cavlc -sei timing -b:v 3M -maxrate 3M -codec:a aac -b:a 128k -f flv rtmp://a.rtmp.youtube.com/live2/ [18:11:07 CEST] <hojuruku> That's working but youtube is not letting the stream start go live because AMD is reporting the wrong screen size 65536x65536 to youtube - but work find wint intel. Is there some way to copy from amd's kmsgrab video memory to the intel's memory to use as the encoder until the fix the bug [18:12:00 CEST] <hojuruku> also the timing information in the stream is wrong usually. mkvmerge manages to fix it up to work around this issue: https://bugs.freedesktop.org/show_bug.cgi?id=105277 why I didn't up date my ticket with the success is a long story I wont go into , but the amd driver puts out broken streams. [18:12:44 CEST] <jkqxz> The AMD VAAPI implementation does not support out-of-band extradata. Can you send TS or something where inband extradata is generally supported? [18:14:42 CEST] <jkqxz> The copy from video memory should work automatically if you supply a different filter_hw_device to hwmap, assuming there isn't any funny tiling. (IIRC from my testing in X AMD capture mapping to Intel worked, but Intel capture mapping to AMD doesn't because of tiling. May be different with other things running, though.) [18:15:26 CEST] <hojuruku> yeah I don't mind using the intel for encoding. How do you tell / disable sei so amd stops sending the wrong screen size etc to youtube. [18:15:43 CEST] <hojuruku> "Please check the video resolution. The current resolution is (65535x65535), which is not optimal." that's the error i would get in live dashboard from youtube [18:16:06 CEST] <jkqxz> I assume youtube is trying to read the nonexistent extradata and making something up to tell you. [18:19:39 CEST] <hojuruku> jkqxz: i think we talked before regarding with ffmpeg making corrupted mp4 files - it wasn't just no moov atom it had timing issues, however mkmerge could fix the timing issues running the video through. [18:20:31 CEST] <hojuruku> i set -sei to identification only - hoping that works better, but somehow the stream is reporting the wrong size, the radeon vaapi needs lots of work [18:21:12 CEST] <hojuruku> any help telling me how to hwmap from one device to another (is that possible? - letting the intel hwmap the amd's ram?) - or hwdownload one gpu -> hwupload to the intel. [19:04:14 CEST] <jkqxz> hojuruku: In your command above, you can make the second device the Intel (presumably /dev/dri/renderD128). [19:04:35 CEST] <jkqxz> The SEI stuff doesn't work at all in the AMD driver, it's completely ignored. [19:05:28 CEST] <hojuruku> ah ok, so the amd driver is hardcoded to out put a fake screen resolution and broken timestamp data that freaks out some players (like gstreamer and hardware decoding TVs) [19:06:37 CEST] <jkqxz> No, it just gives you nothing at all as extradata. You only get the stream with inband parameter sets. [19:06:41 CEST] <hojuruku> jkqxz: I've tried for 30 mins to try and modify that above to take the kmsgrab from the andgpu card1 - and hwmap it to the intel decoder, or if all else fails hwdownload -> hwupload. The docs talk about having two vaapi's working on different streams - but not talking to eachother. [19:08:20 CEST] <jkqxz> What goes wrong with 'ffmpeg ... -f kmsgrab -device /dev/dri/card0 -i - ... -init_hw_device vaapi=intel:/dev/dri/renderD128 -filter_hw_device intel -filter:v hwmap,scale_vaapi=format=nv12 ...'? [21:56:50 CEST] <leandro_> hello [21:57:13 CEST] <leandro_> how can i set referer, origin and cookie by ffmpeg ? [22:53:22 CEST] <hojuruku> jkqxz: sorry about before I missed your reply I got hit by a kernel panic (not swap enabled since ssd died, but zswap enabled in kernel boot arguments - BOOM when OOM) [23:16:23 CEST] <jkqxz> hojuruku: "17:08 < jkqxz> What goes wrong with 'ffmpeg ... -f kmsgrab -device /dev/dri/card0 -i - ... -init_hw_device vaapi=intel:/dev/dri/renderD128 -filter_hw_device intel -filter:v hwmap,scale_vaapi=format=nv12 ...'?" [23:19:00 CEST] <hojuruku> Failed to create surface from DRM object: 18 (invalid parameter). [23:19:08 CEST] <hojuruku> i could debug it. [23:21:40 CEST] <hojuruku> needs to capture amd screen > to intel vaapi surface and encode. i think we have to take it out of the amd memory by vaapi via hwdownload, then init a new vaapi the intel and hwupload it. just changing the vaapi driver and dri/render to intel didn't work. [23:22:12 CEST] <jkqxz> That case should be the usual DRM PRIME sharing between devices setup. [23:22:28 CEST] <jkqxz> Though yeah, certainly you can do download/upload if you prefer. [23:23:17 CEST] <hojuruku> not using DRI prime, but you are right that might be what i need to enable sharing, xinerama is no good. but I don't want to use reverse prime, I rather just have to seperate cards the old fashioned way and using xinerama, but xrandr is giving me no joy either. right now only got the one screen working. [23:54:57 CEST] <jkqxz> Hmm, right. What I was remembering working was export of video surfaces from AMD, which can indeed be imported directly to Intel from PRIME fds. [23:56:10 CEST] <jkqxz> It looks like however the scanout surfaces get set up means that isn't the case for them, though, so it's probably not going to work directly. [23:57:25 CEST] <jkqxz> (From testing with Polaris + Coffee Lake recording a bare framebuffer console, but could well be different with other setups.) [00:00:00 CEST] --- Wed Aug 29 2018

1 0

ffmpeg-devel.log.20180827
by burek 28 Aug '18

28 Aug '18

[00:02:47 CEST] <rcombs> dolby vision is just HDR10+ with more Brand" [00:03:36 CEST] <JEEB> wasn't HDR10+ samsung's edition? [00:03:42 CEST] <JEEB> while dolby vision was the other thing [00:03:48 CEST] <JEEB> https://kuroko.fushizen.eu/screenshots/smpte/st2094_apps1_4.png [00:03:54 CEST] <JEEB> app 1 was dolby (dolby vision) [00:04:00 CEST] <JEEB> app 4 was samsung (hdr10+) [00:04:16 CEST] <nevcairiel> dolby vision is more then that [00:04:24 CEST] <nevcairiel> they hide a whole stack of tech behind that name [00:04:25 CEST] <JEEB> they had N different profiles for it [00:04:39 CEST] <JEEB> https://www.dolby.com/us/en/technologies/dolby-vision/dolby-vision-profiles… [00:05:01 CEST] <nevcairiel> they also have some hacks to transport that over lower hdmi versions by encoding it into the image data [00:05:43 CEST] <nevcairiel> noone is going to mind a few pixels with metadata in them right ? :D [00:05:48 CEST] <JEEB> :D [00:07:04 CEST] <nevcairiel> in hevc they also have this dual layer concept where you h ave the hdr info as a secondary layer you need to decode using a proprietary dolby NAL prefix [00:07:19 CEST] <nevcairiel> its not just a different expression of smpte st 2094 metadata [00:07:19 CEST] <JEEB> yup [00:07:30 CEST] <JEEB> the profiles go over those things [00:07:44 CEST] <JEEB> base layer and enhancement layer [00:26:16 CEST] <rcombs> yeah but most dolby vision is decodeable as HDR10+ [00:26:36 CEST] <rcombs> or so they told me [00:26:54 CEST] <rcombs> there are a bunch of profiles but the most commonly-used ones are compatible [00:27:20 CEST] <rcombs> in-band signaling sure is on-brand for them, though [00:43:41 CEST] <TD-Linux> certainly the dual later hevc wouldn't be [00:46:33 CEST] <JEEB> yea, dual layer avc/hevc was custom [00:46:53 CEST] <JEEB> I've got some MPEG-TS sample of dolby vision but I've been :efff: to look into how that's coded [00:47:04 CEST] <JEEB> it didn't seem to be PQ/BT.2020 at least [10:38:50 CEST] <jya> hi.. I'm investigating a bug reported to us (https://bugzilla.mozilla.org/show_bug.cgi?id=1486080) Now why we it now be required to allocate memory in a particular way (and worse have it automatically freed) when the doc has clearly stated for years that it was up to the user to allocate and free? [10:43:59 CEST] <nevcairiel> its just how it has always worked, you just never hit one of those cases before, now you do [10:54:06 CEST] <jya> nevcairiel: the doc should be amended then [10:56:17 CEST] <cone-220> ffmpeg 03Zhong Li 07master:d91370e0f12a: lavc/encode: fix frame_number double-counted [14:11:50 CEST] <durandal_1707> atomnuker: you cant review new 2 decoders for some reason? [15:08:58 CEST] <nevcairiel> hrm who broke checkasm once again [15:11:14 CEST] <durandal_1707> it works here [16:36:35 CEST] <cone-426> ffmpeg 03Avi Halachmi (:avih) 07master:58b81ac621ae: configure: speed up flatten_extralibs_wrapper() [16:36:35 CEST] <cone-426> ffmpeg 03Avi Halachmi (:avih) 07master:923586a58f37: configure: speed up print_enabled_components() [16:36:35 CEST] <cone-426> ffmpeg 03Avi Halachmi (:avih) 07master:45499e557c80: configure: speed up check_deps() [16:36:45 CEST] <jamrial> configure is no longer a pain to run [16:37:11 CEST] <JEEB> \o/ [16:37:21 CEST] <iive> under windows too? [16:37:28 CEST] <JEEB> yes, the time is now really cut [16:37:36 CEST] <JEEB> there were some msys2 numbers in the ML messages [16:37:39 CEST] <iive> nice [16:37:44 CEST] <JEEB> aka closer to a minute than 10 [16:37:45 CEST] <JEEB> lol [16:38:26 CEST] <jamrial> iive: real 3m30.198s [16:38:31 CEST] <jamrial> On win10 [16:38:40 CEST] <jamrial> it was 16 min before [16:38:49 CEST] <jamrial> or worse [16:41:43 CEST] <JEEB> yup [16:41:49 CEST] <JEEB> I completely stopped building on windows because of it :D [16:49:49 CEST] <atomnuker> durandal_1707: yeah, I'll review them tonight [16:50:10 CEST] <atomnuker> one thing which stood out: frame->key_frame = rle_uncompress(.... [16:50:28 CEST] <atomnuker> you run an unpack all over again to get a flag [16:51:10 CEST] <atomnuker> oh nvm, you write to the bytestream when you do that which writes to frame->data [16:56:12 CEST] <BtbN> I'm kinda expecting this to break on some occasions [16:56:21 CEST] <BtbN> But it's a good starting point [17:06:00 CEST] <BtbN> dash ./configure --disable-doc 28,89s user 36,35s system 63% cpu 1:42,42 total [17:06:11 CEST] <BtbN> That's on cygwin [17:26:29 CEST] <kierank> not bad at all [20:05:16 CEST] <kurosu> nice, configure taking 1m30s [20:05:37 CEST] <atomnuker> on windows? [20:05:43 CEST] <kurosu> yes, win7 x64 [20:06:00 CEST] <atomnuker> nice, didn't it take like 15 minutes before? [20:06:11 CEST] <kurosu> I think this is Win10 [20:06:28 CEST] <kurosu> I can't remember the last time measured [20:06:41 CEST] <kurosu> probably in my logs when the python script was being discussed [20:07:10 CEST] <kurosu> bah, local history doesn't go that far [20:07:22 CEST] <nevcairiel> it was about 15-20 minutes on windows before, so thats nice [20:07:26 CEST] <JEEB> atomnuker: yea it was 10-15min until then :D [20:07:34 CEST] <JEEB> so that change was very nice speed-wise [20:10:07 CEST] <kurosu> 4m15 [20:12:00 CEST] <kurosu> eh, except I was clocked much higher [20:12:10 CEST] <kurosu> s/I/CPU [20:19:40 CEST] <cone-704> ffmpeg 03Mark Thompson 07master:2fd962efbaf4: vaapi_encode_h264: Move options and common structures into context [20:19:40 CEST] <cone-704> ffmpeg 03Mark Thompson 07master:46d1313fcd31: vaapi_encode_h265: Move options and common structures into context [20:19:40 CEST] <cone-704> ffmpeg 03Mark Thompson 07master:2c3ad16d3e6e: vaapi_encode_mjpeg: Move common structure into context [20:19:40 CEST] <cone-704> ffmpeg 03Mark Thompson 07master:537d6aa30ebc: vaapi_encode_mpeg2: Move common structure into context [20:19:40 CEST] <cone-704> ffmpeg 03Mark Thompson 07master:58d3ac31c8a4: vaapi_encode_vp8: Move options and common structures into context [20:19:41 CEST] <cone-704> ffmpeg 03Mark Thompson 07master:1616106f1168: vaapi_encode_vp9: Move options and common structures into context [20:19:41 CEST] <cone-704> ffmpeg 03Mark Thompson 07master:c5b4ad247b9d: vaapi_encode: Remove common priv_data and options fields [20:19:42 CEST] <cone-704> ffmpeg 03Mark Thompson 07master:38ec5b4aa473: vaapi_encode: Factorise out adding global parameters [20:29:53 CEST] <jamrial> jkqxz: if you don't get reviews for the remaining vaapi stuff (not a lot of active devs using it maybe?) then just push them [20:30:00 CEST] <jamrial> most of those patches are months old by now [20:33:54 CEST] <atomnuker> yeah, I did take a look at the patch which ported vaapi to the new decode api and it looked okay [20:34:24 CEST] <BBB> jamrial: did you consider attending vdd this year? please please please [20:34:39 CEST] <BBB> (Im finally in the correct timezone again, allowing me to badger you to no end) [20:35:12 CEST] <atomnuker> durandal_1707: you too ^^, there's still time, the register link does allow you to get sponsored still [20:35:13 CEST] <j-b> +1 [20:35:27 CEST] <j-b> jamrial: jkqxz: durandal_1707: plz plz plz, come :) [20:35:56 CEST] <atomnuker> but don't open the webpage, they've stuck a picture of me, I'm hideous :) [20:36:27 CEST] <BBB> just say the picture is old [20:37:13 CEST] <BBB> and yes, others should come also, come on guys, its fun [20:37:19 CEST] <j-b> atomnuker: please send me another one [20:37:20 CEST] <j-b> BBB: same [20:37:38 CEST] <BBB> that presumes I can find a picture of me that is not ugly [20:37:54 CEST] <BBB> its ok, Ill live with the old one and just use its oldness as an excuse [20:39:32 CEST] <durandal_1707> atomnuker: zlib checks if there is enough buffer size, and in that case it will error out as it should [20:39:35 CEST] <JEEB> yes, I'd love to see durandal_1707 and share words <3 [20:40:49 CEST] <JEEB> mostly thanks :D [20:40:55 CEST] <durandal_1707> j-b said there are guards, i cant go [20:41:01 CEST] <JEEB> there's no need [20:41:09 CEST] <JEEB> it's nerds and everyone's under the CoC [20:41:24 CEST] <JEEB> /geeks/whatever [20:41:29 CEST] <kurosu> I believe vdd helps people see through the mail/irc persona, and generally improves relationships afterwards [20:41:37 CEST] <JEEB> yes [20:42:01 CEST] <kurosu> considering how prolific and essential jamrial and durandal_1707 have become, it seems really a miss they don't come [20:42:01 CEST] <atomnuker> durandal_1707: should be fine then [20:42:24 CEST] <durandal_1707> i already stated my position regarding vdd location [20:42:45 CEST] <pasouza> atomnuker: could you please give you opinion on the patch (https://patchwork.ffmpeg.org/patch/10037/) when you have time [20:43:20 CEST] <atomnuker> durandal_1707: dude, its the only technical conference in europe [20:43:24 CEST] <kurosu> durandal_1707, you never travel? Don't you want to meet some people? not everyday ones, but maybe people like kostya? [20:50:03 CEST] <j-b> even Kostya came to VDD [20:50:07 CEST] <j-b> and Jason! [20:50:31 CEST] <j-b> and security is to help you, not annoy you. [20:52:13 CEST] <atomnuker> jason has been to a vdd? wasn't the first one in ireland only a few years ago? [20:52:35 CEST] <j-b> yes, he even went to the Louvre [20:52:38 CEST] <j-b> with Lydia [20:52:50 CEST] <j-b> I think it was the year before ireland [20:54:17 CEST] <JEEB> yea I think he was around 2010/2011 [20:54:27 CEST] <atomnuker> what about pengvado? [20:54:44 CEST] <JEEB> that ninja :D [20:56:15 CEST] <atomnuker> I've scanned all the chatlogs I have, never seen him utter a single word :/ [20:56:57 CEST] <JEEB> Freenode/#x264dev.log:33 [20:57:24 CEST] <atomnuker> ah, well, that's one channel I'm not in [20:59:13 CEST] <durandal_1707> kurosu: i generally avoid people [21:00:34 CEST] <atomnuker> good choice in case there are self-checkout machines, but those won't be supermarket clerks you're meeting, but other experts on video coding [21:05:20 CEST] <durandal_1707> av_image_fill_black is useless [21:05:33 CEST] <JEEB> orly? [21:05:36 CEST] <durandal_1707> why it uses ptrdiff for linesize? [21:05:36 CEST] <JEEB> I thought it was a nice helper [21:05:57 CEST] <durandal_1707> libavcodec/wcmv.c:67:42: warning: incompatible pointer types passing 'int [8]' to parameter of type 'const ptrdiff_t *' (aka 'const long *') [-Wincompatible-pointer-types] [21:06:05 CEST] <kurosu> durandal_1707, why should it not ? [21:06:25 CEST] <kurosu> I think because of win64, ptrdiff_t is now favored for pointer offsets [21:06:44 CEST] <kurosu> (high 32bits of 64 regs not being cleared/... by Win64 ABI) [21:06:44 CEST] <durandal_1707> but frame linesize is int[8] [21:06:52 CEST] <kurosu> ah, ok, yes [21:06:55 CEST] <kurosu> legacy code [21:07:20 CEST] <kurosu> at some point, I would expect frame linesize to also become ptrdiff_t [21:07:30 CEST] <atomnuker> I don't think we can change the type of a variable without deprecating it and making a new one [21:07:40 CEST] <atomnuker> thankfully frame->stride is still up for grabs [21:16:05 CEST] <gnafu> If someone wanted to sponsor me and pay for the travel, I'd love to go to VDD as Resident Fanboi or something ;-D. [21:16:53 CEST] <atomnuker> if we do deprecate frame->linesize pretty much 100% of our code + 100% of api users will have to change their code too, so when we bump major eventually it'll be an apocalypse [21:20:34 CEST] <durandal_1707> gnafu: post few patches to ffmpeg/videolan/libav and you will be sponsored [21:22:46 CEST] <gnafu> durandal_1707: Maybe someday :-). Anyway, I don't have a passport and probably couldn't get one in time even if I could go :-P. [21:23:21 CEST] <durandal_1707> you live in north korea? [21:23:56 CEST] <gnafu> durandal_1707: No, but close. USA. I've never traveled internationally, so I never needed a passport. I suppose I might be able to get one in a month, but I've always had the impression it can take a while. [21:24:12 CEST] <gnafu> I really should get one just so I can be ready for something like that. [21:57:41 CEST] <BradleyS> https://travel.state.gov/content/travel/en/passports/apply-renew-passport/h… [21:58:11 CEST] <BradleyS> gnafu: ^ [22:01:09 CEST] <gnafu> BradleyS: Thanks :-). [22:01:15 CEST] <BradleyS> ;) [22:01:54 CEST] <j45> I just did that a couple of weeks ago. Took 1 week from the day I sent in the application [22:02:31 CEST] <BradleyS> E_NOTHREAT [22:07:58 CEST] <cone-704> ffmpeg 03Paul B Mahol 07master:f7d749e95b93: avcodec: add MatchWare Screen Capture Codec [22:07:59 CEST] <cone-704> ffmpeg 03Paul B Mahol 07master:ad2ac1e7dd90: avcodec: add WinCAM Motion Video decoder [22:11:10 CEST] <atomnuker> bofh_: ping [23:36:07 CEST] <cone-704> ffmpeg 03Shiyou Yin 07master:e13e52fd0de6: configure: [loongson] revert no-expensive-optimizations [00:00:00 CEST] --- Tue Aug 28 2018

1 0

ffmpeg.log.20180827
by burek 28 Aug '18

28 Aug '18

[10:43:23 CEST] <gaara4896> Hi, I was planning to write a steganography algorithm which require to modify some intermediate step of h264 to makes it works. Is ffmpeg suitable tools for the job? [10:49:33 CEST] <furq> gaara4896: there's no builtin h264 encoder so probably not [10:50:09 CEST] <furq> other than linking it with a modified x264 or openh264 [10:50:11 CEST] <JEEB> there's a bit stream filter for modifying H.264 bit streams [10:50:21 CEST] <JEEB> so that can be utilized to making random changes [10:50:39 CEST] <furq> yeah if you just want to pack data into the bitstream [10:50:47 CEST] <furq> but i assume you want to actually modify the image somehow [10:51:29 CEST] <furq> bye [11:15:29 CEST] <haasn> the H264 bitstream should be roughly perceptually equal, right? [11:15:47 CEST] <haasn> or, well, an ideal codec's bitstream would be [11:15:53 CEST] <haasn> I wonder how far from this ideal real codecs are [11:16:08 CEST] <haasn> i.e. does modifying a random bit in the bitstream have a consistent visual effect [11:16:39 CEST] <haasn> I mean if you modify the DC offset you're going to have more of a visible effect than modifying some high frequency component [11:16:54 CEST] <haasn> but how does this interact with quantization? [11:17:09 CEST] <haasn> the bits that play a greater role should have more bits allocated to them, no? [11:17:11 CEST] <haasn> in an ideal quantizer [12:50:08 CEST] <Franciman> Hi [12:50:22 CEST] <Franciman> How can I create a video stream with ffmpeg? [12:50:40 CEST] <Franciman> Instead of writing the video to a file, I'd like to create a stream [13:19:13 CEST] <BtbN> What kind of stream? Stream to an rtmp server? [13:21:22 CEST] <Franciman> yes [13:21:28 CEST] <Franciman> sorry I forgot to mention [21:20:09 CEST] <yagiza> It seems there is no way to specify RTCP port when using SDP demuxer. [21:21:22 CEST] <yagiza> And there is no way to play RTP with non-static payload type without using SDP demuxer. [21:22:52 CEST] <yagiza> So, in most cases there is no way to specify an RTCP port to send packets when playing RTP media. [22:33:06 CEST] <pi-> https://paste.pound-python.org/show/3sUzuJGRTko8j9gqQEd4/ <-- can anyone suggest what might be going wrong here? [23:33:19 CEST] <LigH> Hi. [23:35:18 CEST] <LigH> Can anyone help me with building issues related to pkgconfig files (*.pc)? [23:35:48 CEST] <DHE> can you be more specific? [23:38:24 CEST] <LigH> There is the "media autobuild-suite" which helps building ffmpeg in a regularly updated MSYS2 environment and with regularly updated sources of the ffmpeg project and related libraries. [23:38:29 CEST] <LunaLovegood> Can I mix two audio channels into one (stereo -> mono) but give "priority" to one channel? Like that the left channel gets attenuated by 12 or so dB whenever there is some activity on the right channel (voice) ? [23:38:40 CEST] <LigH> Recently, there was a preparation for liblensfun, but it was not finished. [23:39:36 CEST] <LigH> I wanted to test it, I enabled the library to be included, it was downloaded, compiled ... and then there was a problem with the installation. [23:40:04 CEST] <LigH> I found that instead of pkgconfig/liblensfun.pc, there is instead a file pkgconfig/lensfun.pc which was nor expected. [23:40:47 CEST] <LigH> Now I wonder where the reason for this difference may be, if I shall "blame" the authors of lensfun for not sticking to any guidelines I do not even know about... [23:41:33 CEST] <LigH> A pity that the author of the media-autobuild suite does not help in this case. [23:41:43 CEST] <LigH> He said he has no time, no interest, etc. [23:42:04 CEST] <LigH> So I'm trying to find anyone else with enough insight. [23:43:29 CEST] <LunaLovegood> Oh, I think I can just boost the volume on the more important channel then use dynaudnorm before mixing. [23:43:34 CEST] <LunaLovegood> right. sorrt. [23:43:36 CEST] <LunaLovegood> *sorry [23:46:18 CEST] <LigH> LunaLovegood: Sounds like a good idea to me. [23:47:00 CEST] <LigH> But be careful with volumes, avoid clipping. [23:47:42 CEST] <LigH> Often you want a dynamic compression (possibly with limiting), a loudness instead of a volume change. [23:53:46 CEST] <LigH> DHE: Is that a topic for the devel channel? [23:54:49 CEST] <JEEB> no [23:54:55 CEST] <JEEB> it doesn't even have anything to do with FFmpeg [23:55:11 CEST] <JEEB> also as far as I can tell people call their pkg-config .pc files however they want [23:56:19 CEST] <JEEB> it's just that the name is generally to be static [23:56:31 CEST] <JEEB> and defined by upstream unless upstream is stupid [23:56:43 CEST] <JEEB> example http://up-cat.net/p/dd56369a [23:59:03 CEST] <LigH> Means, someone would have to adapt the suite to this specific name. And I doubt I would be the one... [00:00:00 CEST] --- Tue Aug 28 2018

1 0

ffmpeg-devel.log.20180826
by burek 27 Aug '18

27 Aug '18

[01:22:16 CEST] <jamrial> tmm1: would be neat if you could test the configure patches to see if they don't break detection/deps of apple framework stuff [02:49:44 CEST] <bofh_> atomnuker: so if you keep around 2 different copies of fft5 you can do the rest via reindexing (also, seriously, hardcode the twiddles *into* the fft5 part of that code instead of regenerating them at runtime, it's like 4 values). I don't know if you can do better, I'm trying to get a general result right now on feasibility of forward/inverse FFTs via just reindexing. [02:49:59 CEST] <bofh_> (also sorry for the delay, I've been at a superconductivity conference in Beijing for the past few days) [02:53:29 CEST] <atomnuker> wish I was there [02:54:58 CEST] <atomnuker> yeah, the 5-point fft is small enough to template, I assume all you need to do is change the sign [02:55:36 CEST] <atomnuker> can you tell me what changes to make or submit a diff maybe? [12:34:31 CEST] <cone-765> ffmpeg 03Nicolas George 07master:962c9313af31: lavfi/avf_concat: switch to activate. [16:48:49 CEST] <durandal_1707> Compn: you have commit rights for mplayer, so commit fixed imm4 patch [18:05:58 CEST] <cone-306> ffmpeg 03Paul B Mahol 07master:c84a57d1a218: avcodec/mscc: fix several bugs [18:08:38 CEST] <cone-306> ffmpeg 03Paul B Mahol 07master:3aacb0d196d1: avcodec/proresdec2: add frame threading support [18:09:19 CEST] <BradleyS> ^ ooo [18:09:40 CEST] <BradleyS> is there a ML thread or other information with benchmarks? [18:10:19 CEST] <durandal_1707> BradleyS: why you ask? [18:10:39 CEST] <BradleyS> because i use prores a lot and run it through handbrake a lot [18:11:16 CEST] <durandal_1707> then test latest ffmpeg master and report your findings [18:11:33 CEST] <BradleyS> of course :) [18:15:54 CEST] Action: BradleyS wonders whether durandal_1707 is the author [18:16:15 CEST] <BradleyS> i haven't put together everyone's name/handle combination quite yet [18:18:02 CEST] <kierank> he is author of thread patch yes [18:18:29 CEST] <BradleyS> cool o/ [18:18:48 CEST] <BradleyS> adding it to my long todo list, will do some testing here [18:22:16 CEST] <BradleyS> when i asked about benchmarks i of course assumed the patch was a bit more involved, heh [18:23:52 CEST] <durandal_1707> it depends how many CPUs one have [18:27:33 CEST] <durandal_1707> here on my CPU, with 4 cores, i get speed increased from 693 fps (slice mt) to 721 fps (frame mt) for static hd720 video [18:29:24 CEST] <BradleyS> i can test 720/1080 on my 6 core westmere, and probably 4k when new camera stuffs arrive soonish (or using test media) [19:52:48 CEST] <durandal_1707> Dav1d is written in Rust [19:53:14 CEST] <JEEB> funky [19:54:09 CEST] <atomnuker> pretty sure it isn't [19:54:22 CEST] <JEEB> that's what I would have expected [19:54:41 CEST] <JEEB> that said I also don't know what durandal_1707 based that sentence on [19:55:51 CEST] <durandal_1707> it is decoder for rav1e [19:58:16 CEST] <kurosu> Speak of the devil [20:51:22 CEST] <durandal_1707> BBB: is Dav1d going to be sold like that vp9 encoder? [20:52:10 CEST] <atomnuker> no, it'll be released as a bsd 2 clause code [20:52:25 CEST] <BBB> BBB is short for beelzebub, which is actually one of the fallen angels, yes :-p [20:52:29 CEST] <BBB> so I guess I am a devil [20:53:11 CEST] <BBB> Im not in charge of license details, ask, j-b [20:53:27 CEST] <durandal_1707> thanks [20:58:06 CEST] <durandal_1707> ubitux: is lut1d patch fine, should i use LUT3DContext instead? [21:02:02 CEST] <kierank> durandal_1707: how do I make fate test [21:02:08 CEST] <kierank> for mpeg4video [21:02:33 CEST] <JEEB> I think the latest thing is the md5sum based stuff? [21:02:53 CEST] <kierank> mpeg4 is framecrc [21:03:00 CEST] <JEEB> yea because it's older [21:03:05 CEST] <JEEB> (than the md5 stuff) [21:03:38 CEST] <JEEB> also an alternative is to make the test a separate C app [21:03:41 CEST] <JEEB> like with movenc [21:03:47 CEST] <kierank> I don't need that afaik [21:03:49 CEST] <kierank> it's one frame [21:04:06 CEST] <JEEB> yeh, framemd5 or something sounds good enough then. [21:04:44 CEST] <JEEB> for something like a single frame test it might even be nice if we had per-plane and possibly even per-line hashes or something [21:04:50 CEST] <JEEB> but I don't think we have that :) [21:06:52 CEST] <durandal_1707> per pixel component sha1024 hashes are not enough? [21:07:23 CEST] <JEEB> heh [21:10:07 CEST] <kierank> atomnuker: ping [21:10:32 CEST] <durandal_1707> someone please reply to MWSC and WCMV decoders patches with just LGTM, so I can push them and move on with *SECRET* [21:13:59 CEST] <kierank> https://obe.tv/clang/scan-build-2018-08-26-195358-16089-1/index.html [21:14:09 CEST] <kierank> most are junk but some are real [21:19:06 CEST] <atomnuker> yeah, that's true, I'll fix some in my code [21:19:31 CEST] <kierank> atomnuker: do you have any comment on the vc2enc one? [21:19:42 CEST] <kierank> is it actually real [21:19:58 CEST] <JEEB> yea, scan-build has a lot of misdetections, but it's a nice OSS analyzer [21:20:05 CEST] <JEEB> which reminds me, clang 7 is at rc2 [21:24:57 CEST] <atomnuker> kierank: actually both the one in opusenc and vc2enc are bogus [21:25:12 CEST] <atomnuker> in vc2enc if (quant_buf[1] == quant) { is never going to be true for the first slice [21:25:18 CEST] <atomnuker> as quant_buf[1] = -1 [21:25:30 CEST] <atomnuker> and quant is clipped like av_clip(quant + signed_step, 0, s->q_ceil-1); [21:25:33 CEST] <kierank> you can add an assert I think [21:25:38 CEST] <kierank> and it will go away [21:58:01 CEST] <atomnuker> "Twitch is building a VP9 live-encoding solution that can deliver broadcast-level video quality with 25+% bitrate savings" [21:58:07 CEST] <atomnuker> yah, another encoder [21:58:17 CEST] <atomnuker> "Based on our feasibility study, FPGA is the only available solution in the market right now" [21:58:23 CEST] <atomnuker> nevermind [21:58:30 CEST] <kierank> hahahaha [21:58:31 CEST] <kierank> they are idiots [21:58:35 CEST] <kierank> going to cost them soo much [21:58:36 CEST] <JEEB> ah, oppan FPGA style [21:58:51 CEST] <atomnuker> https://www.meetup.com/SF-Video-Technology/events/wlnthpyxlbnc/ [21:59:15 CEST] <kierank> it cannot be cost effective for them to do this [21:59:32 CEST] <atomnuker> "Yueshi will explain the thought process of selecting VP9 as Twitch's next-gen video codec format" <- couldn't they wait a bit for av1? [21:59:55 CEST] <jamrial> atomnuker: no hardware until like 2020 [22:00:13 CEST] <JEEB> yea, the decoders for VP9 have been on the market since 2016 at the very least [22:00:14 CEST] <jamrial> nvidia is about to release their new cards, obviously without av1 [22:00:18 CEST] <JEEB> (my 2016 TV has support for it) [22:00:27 CEST] <JEEB> and nvidia encoders, yea [22:00:38 CEST] <atomnuker> can't they implement a partial cuda decoder like they've done before? [22:00:48 CEST] <JEEB> although did they have VPx encoders in their cards yet? [22:00:55 CEST] <JEEB> I only saw AVC and HEVC generally [22:00:57 CEST] <jamrial> so you'd have to wait until the following gen [22:00:57 CEST] <kierank> jamrial: why do they need hardware [22:01:03 CEST] <kierank> tvs can be upgraded [22:01:04 CEST] <kierank> browsers can [22:01:08 CEST] <kierank> even phones [22:01:22 CEST] <kierank> atomnuker: probably nobody is using the AWS fpgas so they are getting them for free [22:01:32 CEST] <JEEB> :D [22:01:50 CEST] <jamrial> kierank: hardware decoders. you can't add transistors to a phone or set top box already in the market [22:02:01 CEST] <JEEB> reminds me of another live streaming service advertising some hardware encoding solution they picked [22:02:04 CEST] <jamrial> software decoder sure. just update libavcodec in your browser [22:02:05 CEST] <kierank> phones are very powerful these days [22:02:24 CEST] <kierank> probably the saved rf bandwidth will save more power than the cpu cost [22:02:44 CEST] <kierank> twitch is unrelated to set top boxes [22:02:50 CEST] <JEEB> true [22:02:55 CEST] <JEEB> it's mostly mobile and browsers [22:02:59 CEST] <kierank> and smart tvs [22:03:13 CEST] <JEEB> and on those VP9 is already [22:06:55 CEST] <durandal_1707> multimedia is no longer relevant [22:07:09 CEST] <JEEB> right. we can then all go home [22:08:08 CEST] <durandal_1707> i hate object based languages and javascript [22:08:51 CEST] <kierank> durandal_1707: no job at google for you then [22:08:55 CEST] <kierank> it's c++ minimum there [22:11:54 CEST] <durandal_1707> kierank: i got contacted by them again, (not counting cases prior to joining FFmpeg) [22:12:49 CEST] <JEEB> golang, javascript, C++ seem to be the usual cases at GOOG [22:53:47 CEST] <durandal_1707> what os is OS/2 ? [22:56:02 CEST] <JEEB> OS/2 is Ossi, from the 1990s. Koreans still seem to be maintaining it [22:56:10 CEST] <JEEB> which is why it was surprising that the guy who tested it was !Korean [22:56:19 CEST] <JEEB> because all of the OS/2 patches for VLC and FFmpeg seemed to come from Korea [23:02:00 CEST] <Shiz> there's a commercial OS/2 distri again these days [23:02:03 CEST] <Shiz> it's crazy [23:10:16 CEST] <durandal_1707> looks like nobody here cares for Dolby Atmos and Dolby Vision? [23:12:02 CEST] <nevcairiel> some of my users care and occasionally annoy me [23:26:44 CEST] <TD-Linux> someone make a bsf that make the dolby atmos light go on but otherwise does nothing [23:27:12 CEST] <JEEB> :D [23:27:24 CEST] <JEEB> yea the atmos light seems to be the only thing people care about [23:30:01 CEST] <nevcairiel> i had to do some work on bitstreaming to fit the higher bitrate truehd streams into there properly, but that was about all [00:00:00 CEST] --- Mon Aug 27 2018

1 0

ffmpeg.log.20180826
by burek 27 Aug '18

27 Aug '18

[06:13:53 CEST] <craftxbox> how do i get android_camera functionality? [10:35:49 CEST] <paul_uk> hi all. I'm hoping someone can help. I'm trying to simulate a distributed encoding setup. where a video file gets uploaded, split into N segments. Then each worker gets a segment, transcodes it into various formats and then sends it elsewhere to be put back together. [10:37:46 CEST] <paul_uk> The problem I am having, is that I can split, transcode and stitch back the video. But whenever I play back the file, when I get to a join. I notice there is a slight millisecond delay, like the video jumps from 1 segment to the next. So if I have a 60 minute video with 10 segments. Every new segment there is a jump. [10:37:57 CEST] <paul_uk> Here is my ffmpeg cli: https://pastebin.com/raw/vnZ9xTk2 [10:38:15 CEST] <paul_uk> If anyone can let me know what I'm doing wrong, I'd appreciate it. I'm also very new to video encoding as well. [10:38:46 CEST] <_cfr> paul_uk: try -copyts [10:39:44 CEST] <paul_uk> _cfr: thanks for taking a look. where do I apply -copyts ? [10:39:58 CEST] <paul_uk> in the initial split? [11:19:06 CEST] <paul_uk> So I did ffmpeg -i test.mp4 -vcodec mpeg4 -f segment -segment_time 600 -c copy -map 0 -copyts test_%03d.mp4 when doing the split. I still hear that slight pause when viewing the video. I'm using ffmpeg 4.0.2. I see lots of "Non-monotonous DTS in output stream 0:0; previous: 7303168, current: 7303168; changing to 7303169. This may result in incorrect timestamps in the output file." When I split the file. I have [11:19:06 CEST] <paul_uk> done a lot of searching on google and all the answers say that it's fixed. Is this the cause of the issue? [11:51:25 CEST] <th3_v0ice> paul_uk: While joining try to set -reset_timestamps 1 after -i and join the video. Maybe it will resolve the issue. [11:52:04 CEST] <paul_uk> th3_voice: thanks I will try that [11:52:20 CEST] <furq> are you sure you want to use mpeg4 [11:55:15 CEST] <paul_uk> I am brand new to all this. I'm using a mp4 source file. So I don't know what's best to use :) [11:55:43 CEST] <furq> just omit -vcodec entirely and it'll use the default [11:55:50 CEST] <furq> which is normally x264, which is much better [11:56:00 CEST] <paul_uk> ok thanks [11:56:11 CEST] <furq> idk if that'll fix the issue but if nothing else the video will look much better [13:31:37 CEST] <paul_uk> So I have gotten to the bottom of the slight delay in sound. If I use -codec:a copy then I have no problems. I dont even need to use -fflags +genpts -reset_timestamps 1 when rejoining the segments. However once I use libfdk_aac or aac. I get that noticable delay. Any ideas on how to resolve this? Thanks [13:32:40 CEST] <paul_uk> the command with no issues is: ffmpeg -i test_000.mp4 -codec:v libx264 -codec:a copy -threads 6 -f mp4 changed_0.mp4 [16:31:51 CEST] <sircmpwn> if I'm using -f concat and -vf drawtext[...] can I draw the filename concat is currently processing with drawtext? [16:32:45 CEST] <JEEB> the filter most certainly has no idea of the input lavf stuff [16:32:49 CEST] <DHE> sounds like you might want to do something with the concat filter instead [16:33:18 CEST] <DHE> a series of "movie=...,drawtext=...[video1]; ... ; [video1][video2]... concat=... [output]" filters [16:33:26 CEST] <sircmpwn> hmm [16:33:35 CEST] <sircmpwn> that's an interesting thought [16:33:41 CEST] <sircmpwn> thanks [16:33:43 CEST] <DHE> it's gonna be a bit more complicated than that but that'll get the ball rolling [16:34:03 CEST] <DHE> unless you want to buld a timeline and have drawtext change texts at exactly the cut points [16:34:32 CEST] <sircmpwn> I think what I want to do is live with not having the filename shown on the video [16:36:40 CEST] <DHE> that is super-effective as well... :/ [16:42:16 CEST] <paul_uk> This seriously bites. No matter what I try. When I split a file into segments, change the codec and put it back together again. I get a slight pause on the sound where the join is. I read on SO that -reset_timestamps 1 only works with .ts. So I changed to that. Made no difference. This is a known probably because on github when other devs attempt to use distributed encoding. They all complain about this issue [16:42:16 CEST] <paul_uk> too. Any other ideas anyone? [16:43:29 CEST] <paul_uk> Oh and the join process doesn't matter. i tried MP4Box as well and it had the same issue. So it's down to the transcoding of the individual segments. [16:43:30 CEST] <DHE> have you tried options like -copyts ? [16:43:56 CEST] <paul_uk> DHE: This is my segment command: ffmpeg -i test.mp4 -f segment -segment_time 150 -c copy -map 0 -copyts -muxdelay 0 -reset_timestamps 1 test_%03d.ts [16:44:18 CEST] <paul_uk> my transcode command is: ffmpeg -i "$i" -codec:v libx264 -codec:a aac -threads 6 "t_${name}.mp4" [16:44:56 CEST] <DHE> and copyts on the transcode command as well? [16:45:13 CEST] <paul_uk> no. let me give that a try now [16:45:15 CEST] <DHE> also keep using .ts files? [16:45:36 CEST] <DHE> you can probably just "cat *.ts | ffmpeg -i - -c copy -movflags faststart output.mp4" to merge it [16:45:54 CEST] <paul_uk> My intention is to use the files for a VOD service. What's best practice? Combine to mp4 or keep as ts? [16:46:56 CEST] <DHE> depends on the player. mp4 has more universal support but you'll need the -movflags faststart parameter to make it streaming-friendly [16:47:40 CEST] <paul_uk> understood thanks [16:47:57 CEST] <DHE> I'm making this up as I go based on what I know, so... take that for what it is... [16:48:56 CEST] <paul_uk> it's ok. it's really my first foray into ffmpeg. i really just want to get a working prototype on the process and then when that's down, built out the infrastructure to handle encoding at scale. which ironically is the easy part for me. [16:49:46 CEST] <DHE> you've really gone into the deep end for a first project... [16:58:39 CEST] <paul_uk> DHE: unfortunately i still have gaps. Here's the CLI that I'm using. https://pastebin.com/raw/sXPaX4Lu The issue is that when I use -codec:a copy then I have no issues at all. So why the issue when I define an audio codec? I don't understand. [17:02:04 CEST] <DHE> two thoughts occur. the first is that reset_timestamps doesn't sound like a good idea here. the second is that AAC encodes in fixed increments of 1024 samples so there may be an issue with cutting on any non-1024 multiple depending on the properties of the source [17:02:52 CEST] <JEEB> also if the segments are encoded separately with audio then you will have initial delay which depending on how things process it might not be invisible for you :P [17:03:07 CEST] <JEEB> the "encoder delay" [17:03:20 CEST] <DHE> it might be worth encoding the audio entirely separately and merging it in later [17:03:47 CEST] <JEEB> you're not usually speed-limited with audio :P [17:03:58 CEST] <JEEB> which is why you'd want to split video [17:04:07 CEST] <DHE> as an aside, I'm curious about the specifics of your VOD platform and your transcoder capacity. if you're doing an initial conversion of 10,000 items but you don't have well over 10,000 machines doing the work, is this really helping? [17:04:28 CEST] <DHE> kind of a "premature optimization" thing [17:06:41 CEST] Action: DHE is actually preparing for something similar so this is on my mind. [17:07:29 CEST] <paul_uk> Trust me. I'll be at the place where a million items are present and 10k machines are doing the work. I dont have issues getting users for the platform. [17:08:18 CEST] <paul_uk> My reach when it comes to marketing. I could have an email land in 5m inboxes tomorrow if I chose to and no, that's not spamming. All done via influencers :) [17:10:09 CEST] <paul_uk> But back to the original issue. I assume I'll have to split the video and audio into different files and then split each into their own segments. Transcode each distinct group and then rejoin each type and finally combine the two files again into one? [17:10:20 CEST] <DHE> but that's still 100 jobs per machine, not 100 machines per job... [17:11:29 CEST] <paul_uk> Ultimately, it's really about getting the process down. Once I'm happy with it, then I tackle any challenges that come up. I know full well, you can be prepared as possible and then a wrench comes in that you didn't prepare for. [17:48:18 CEST] <Ke> in SwsFunc ff_yuv2rgb_get_func_ptr(SwsContext *c) in libscscale there seems to be special cases for accelerating x86 and ppc, though aarch64 dir seems to have some code implementation [17:48:53 CEST] <Ke> is seems to me I could just copy x86 line and replace the function names with aarch64 function names [17:53:33 CEST] <Ke> I guess I'll just compile and see what happens [18:34:56 CEST] <JEEB> Ke: if there's any aarch64 stuff there the function pointers should be set there during runtime [18:35:11 CEST] <JEEB> that's how the SIMD optimizations work in FFmpeg in general [18:35:28 CEST] <JEEB> also that's an internal function that should be internal to that library as far as I can tell [18:35:41 CEST] <Ke> yes it is [18:36:25 CEST] <JEEB> yeh, there's ff_sws_init_swscale_aarch64 [18:36:35 CEST] <JEEB> which checks if the thing has NEON [18:36:48 CEST] <JEEB> and if it has, and depending on some parameters it sets the function pointer [18:37:17 CEST] <JEEB> and then swscale.c in libswscale/ calls that aarch64 func [18:37:21 CEST] <JEEB> probably under #ifdef AARCH64 [18:37:22 CEST] <JEEB> or something [18:37:37 CEST] <JEEB> yes, ff_getSwsFunc [18:37:49 CEST] <JEEB> if (ARCH_AARCH64) [18:37:58 CEST] <JEEB> so I don't think you need to modify anything to get that stuff used? [18:40:41 CEST] <JEEB> or did I misunderstand something? :D [18:48:35 CEST] <Ke> hmm, apparently I missed the function name, though color space transform stuff is at least partially there in aarch64 as well [18:49:44 CEST] <JEEB> I think all the function pointers should be set during init or so, so if there's aarch64 optimizations they should already be in use [18:56:23 CEST] <Ke> I guess the color conversion is somehow integrated into scaling? [18:56:45 CEST] <Ke> otherwise this naming scheme is very confusing [19:03:04 CEST] <JEEB> yea, swscale does both with sws_scale [19:04:36 CEST] <Ke> in this case ff_sws_init_swscale_aarch64 is triggered for aarch64 code [19:04:57 CEST] <Ke> which does not have the aarch64 code [19:14:27 CEST] <paul_uk> I think I have finally fixed my issue. I need to do a bit more testing because I have loads of tabs open with ffmpeg commands everywhere lol. But I now have a joined sample where there are no gaps. [19:14:44 CEST] <paul_uk> From an SO answer: DCT-based audio codecs like MP3, AAC rely on neighbouring audio frames for decoding. At the start of the stream, there's a priming frame which serves that purpose. It has a negative timestamp, so during concat, its TS clashes with the final packets of the preceding file and it gets dropped by concat. PCM is self-contained for decoding, so doesn't suffer from this. [19:15:09 CEST] <paul_uk> goes a bit over my head, but makes sense. When I use flac for the audio codec. Works just fine. [19:15:27 CEST] <JEEB> paul_uk: I'm pretty sure I mentioned priming samples/encoder delay :P [19:15:40 CEST] <JEEB> also FLAC also has it but I bet the decoder just hard-codes what libflac does [19:15:47 CEST] <JEEB> or I would bet FLAC also has it [19:15:53 CEST] <JEEB> if it doesn't, sure [19:16:43 CEST] <paul_uk> Yes. But I'm day zero here and this is my first time doing anything video or audio related. Have a lot to learn. So I'm feeling around as I experiment. Still more than appreciative for the advice everyone has given so far. [19:58:42 CEST] <DHE> paul_uk: distributing the video encoding but doing the audio encoding at once on the spot is probably still worth it overall. my PC can do 20x realtime encoding to AAC per CPU core [20:27:23 CEST] <qxt> I am streaming video and udp works just fine ie ffmpeg -i state.mp4 -f mpegts "udp://127.0.0.1:1234" but when I try tcp like ffmpeg -i state.mp4 -f mpegts "tcp://127.0.0.1:1234" I get a "Connection refused" [20:28:01 CEST] <qxt> any clue what that is about. I am using Debian 9 GNU/Linux with ffmpeg from the repo [20:28:17 CEST] <qxt> Debian stable that is [20:29:24 CEST] <qxt> Everything is local and there are no iptables/firewalls in the way [20:30:10 CEST] <JEEB> pretty sure it doesn't listen but attempts to push to that :P [20:30:35 CEST] <JEEB> udp is kind of special because it has the concept of just pushing stuff into the ether [20:32:07 CEST] <qxt> JEEB, yeah I am listing with ffplay on ffplay tcp://127.0.0.1:1234 [20:34:15 CEST] <qxt> JEEB, udp works fine. Have even listened on 127.0.0.1:1234 transcoded and dumped the output on port 60006 [20:35:14 CEST] <qxt> what I am wondering is if there was something that should have been compiled into ffmpeg that is missing.... [20:36:13 CEST] <JEEB> nope, you're just either doing something else than you think you're doing or there's a boog somewhere [20:36:36 CEST] <JEEB> I would bet on the first part but you'll have to figure it out yourself. I haven't poked at the tcp protocol at all in lavf :P [20:39:46 CEST] <qxt> What would be the most universal way of steaming audio and video any browser will just work with? x246 and aac ? [20:41:03 CEST] <qxt> When I say work with I mean as in html5 and nothing else installed. [20:44:44 CEST] <qxt> If somebody has a recent version of ffmpeg and they try ffmpeg -i someVideo.mp4 -f mpegts "tcp://127.0.0.1:1234" and see if it spontaneously crashes like the Debian version in stable. [21:00:53 CEST] <paul_uk> qxt: I'm finished for today. but im running ubuntu and i compiled 4.2.0. i can give it a try tomorrow if you like. [21:02:04 CEST] <qxt> paul_uk, thx [21:04:11 CEST] <paul_uk> I want to do the same as you. stream video with any browser. but i thought hls was the best way. I'm trying to emulate wistia in this respect: https://wistia.com/support/getting-started/export-settings [21:05:14 CEST] <qxt> JEEB, how many years have you been hanging out here? IIRC you helped me out with something back in 2010-ish with some guy called pastryeater [21:06:43 CEST] <JEEB> probably ever since circa some time after 2008 [21:06:51 CEST] <JEEB> since I first entered around #x264 in 2008 [21:06:55 CEST] <qxt> dang... [21:07:10 CEST] <qxt> that guy pastyeater still hang out here? [21:07:31 CEST] <JEEB> no idea [23:21:22 CEST] <qxt> is the "strict experimental" still needed? This is from 2012 -acodec aac -strict experimental -ar 44100 -ac 2 -b:a 96k [23:21:43 CEST] <Cracki> aac isn't experimental anymore [23:21:59 CEST] <qxt> thx [23:28:21 CEST] <qxt> hacked this together. Seems to work ok. Anybody see anything wrong with it? Going to use this to transcode and stream video. [23:28:23 CEST] <qxt> ffmpeg -i state.mp4 -f rtsp -rtsp_transport tcp -c:a aac -ar 44100 -ac 2 -b:a 96k -c:v libx264 -crf 23 -maxrate 1M -bufsize 2M rtsp://localhost:8888/live.sdp [23:47:02 CEST] <analogical> when a movie on a Blu-ray ís spread out on several .m2ts files how do I create one single .mkv file from all those files? [23:47:34 CEST] <JEEB> either use libbluray if your FFmpeg has that, or concatenate the m2ts files one after another with cat or so [23:47:37 CEST] <Cracki> possibly "concat" input protocol [23:47:59 CEST] <Cracki> cat is a waste of space if ffmpeg can ingest the files concatenated [23:47:59 CEST] <JEEB> libbluray can basically read the playlists that blu-rays have [23:48:16 CEST] <JEEB> Cracki: cat as in `cat 1 2 3 | ffmpeg -i input` [23:48:21 CEST] <JEEB> not outputting into a file first [23:48:37 CEST] <JEEB> argh, not -i input , -i - [23:48:43 CEST] <JEEB> since "-" is stdin or stdout [23:49:13 CEST] <furq> analogical: mkvmerge can read mpls playlists [23:49:25 CEST] <Cracki> I had bad experiences with piping stuff around. ffmpeg sometimes needs to seek and stdin doesn't do that [23:49:36 CEST] <Cracki> look at the "concat" input protocol [23:49:36 CEST] <JEEB> with mpeg-ts you shouldn't have that [23:49:50 CEST] <Cracki> https://trac.ffmpeg.org/wiki/Concatenate [23:49:55 CEST] <JEEB> but to be honest the libbluray input protocol would be my recommendation [23:49:57 CEST] <JEEB> or what furq noted [23:50:02 CEST] <Cracki> ffmpeg -i "concat:input1.ts|input2.ts|input3.ts" -c copy output.ts [23:50:05 CEST] <JEEB> because both can read the playlists and provide the input [23:50:13 CEST] <JEEB> also the playlist files contain the language info etc [23:50:15 CEST] <furq> if you're just remuxing then mkvmerge is your best bet because it'll keep chapters etc [23:50:19 CEST] <Cracki> ^ [23:50:58 CEST] <JEEB> yea, I think libbluray input protocol in FFmpeg does the same, so it's up to what one prefers [23:51:37 CEST] <furq> neat [00:00:00 CEST] --- Mon Aug 27 2018

1 0