Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

January 2018

1 participants
62 discussions

ffmpeg-devel.log.20180130
by burek 31 Jan '18

31 Jan '18

[00:18:09 CET] <atomnuker> jkqxz: nope, "hwmap,detile_vulkan,hwdownload,format=bgr0" still makes the drm->vulkan mapping but the frame I get in the filter isn't a vulkan frame despite having in->format=vulkan [00:18:31 CET] <atomnuker> putting ,format=vulkan after it doesn't change anything [00:34:34 CET] <atomnuker> the fuck? [00:34:58 CET] <atomnuker> something's using buf[0] and overwriting where I put my avvkframe struct [00:55:45 CET] <jkqxz> atomnuker: What do you mean by looking inside buf[0]? That need not be the original buffer instance, it can be anything which holds the reference transitively. [00:57:27 CET] <atomnuker> I need to store some per-frame context so I put it in buf[0] thinking there'll not be any issues and once a buf's refcount reaches 0 it'll call my callback and get freed [00:58:27 CET] <atomnuker> thing is, in the map_to function buf[0] is NULL, so it gets set to a reference to my context, and that bufferref gets overwritten by some other when it gets to the second filter [00:58:39 CET] <jkqxz> What do you put in the data pointers? [00:58:46 CET] <atomnuker> nothing [00:58:52 CET] <jkqxz> Oh. [00:59:07 CET] <jkqxz> Your frame information, the VkImage and stuff, must be in the data pointers. [00:59:14 CET] <jkqxz> Look at every other hardware frame format. [00:59:23 CET] <atomnuker> huh, ok [00:59:59 CET] <atomnuker> I thought it was okay for them to be in the buf[0] parts because obviously a hwframe can't have a bufferref [01:01:05 CET] <jkqxz> The reference is only for the refcounting, what is actually in it need not be the original buffer as long as it holds a reference to the original buffer and its frames context (and transitively device). [01:01:55 CET] <jkqxz> E.g. the mapping functions put an HWMapDescriptor as the reference on the mapped frame, which contains a reference to the source frame. [01:03:33 CET] <atomnuker> ah, now it makes sense, thanks [01:39:41 CET] <atomnuker> jkqxz: so during normal frame creation (like in get_buffer) buf[0] is set to a reference to a hwcontext priv struct, which is normally set to data[0], but what happens when mapping from another frame type? [01:39:41 CET] <atomnuker> data[0] gets directly set to the frame type and buf[0] doesn't get set to anything is what hwcontext_vaapi does [01:39:42 CET] <atomnuker> what's meant to free data[0]? [01:39:42 CET] <atomnuker> line 1146, dst->data[0] = (uint8_t*)drm_desc; [01:39:42 CET] <atomnuker> well, actually I'm interested in the other case, "dst->data[3] = (uint8_t*)(uintptr_t)surface_id;" for drm->vaapi, but that doesn't allocate any memory for the data planes [01:39:42 CET] <atomnuker> obviously you can't make a reference to the data because like you said buf[0] is used for chaining mappings [01:46:29 CET] <atomnuker> I guess I'll make the unmapping function free that struct, maybe that's how it was made to be done [02:35:57 CET] <jamrial> wm4: i'll apply the mlp_parser patch that honors the PARSER_FLAG_COMPLETE_FRAMES flag, plus a patch to make the matroska demuxer not set it for mlp/theora, so that sample from the other day doesn't complain [02:37:25 CET] <jamrial> just a heads up since you didn't reply to my last email about it in that thread [03:12:52 CET] <cone-612> ffmpeg 03James Almer 07master:63b5d04e331c: avformat/matroskadec: force full frame parsing of MLP/TrueHD streams [03:12:53 CET] <cone-612> ffmpeg 03James Almer 07master:55ebf707d0ab: avcodec/mlp_parser: don't try to combine frames when full frames are provided [03:12:54 CET] <cone-612> ffmpeg 03James Almer 07master:ede6e7494f61: avcodec/mlp_parser: reindent after last commit [04:33:57 CET] <cone-612> ffmpeg 03James Almer 07master:0cc3d830d159: avcodec/Makefile: add missing opus.c dependency to opus encoder [04:43:39 CET] <wm4> jamrial: sure, don't know if other containers are affected though [05:29:07 CET] <cone-612> ffmpeg 03Gyan Doshi 07master:b99e77b9f7b9: avformat/mpegenc - fix typo in VBV warning [05:29:08 CET] <cone-612> ffmpeg 03Dale Curtis 07master:42323c3e3a60: avcodec/mpegaudio_parser: Skip APE tags when parsing mp3 packets. [09:00:00 CET] <dragmore88> hi, i tried this q on the main channel, but as this is a more deeper topic for devs, ill try here : hi. Anyone know if ffprobe or ffmpeg supports detecting/setting the EAC3 parameter : convsnroffst ? (its to enable the ability to downfilter eac3 to ac3 compliant systems) [11:42:53 CET] <thardin> former boss of MPEG lamenting the rise of open standards: http://blog.chiariglione.org/a-crisis-the-causes-and-a-solution/ [11:45:20 CET] <j-b> good job team [11:51:06 CET] <atomnuker> michaelni: could you finally remove the FCC countdown warning from ffmpeg.org? [11:58:18 CET] <RiCON> atomnuker: https://0x0.st/sNNf.txt [11:59:44 CET] <atomnuker> send it to the ml? if there just ping the patch [12:00:40 CET] <RiCON> ffmpeg-devel too? [12:01:25 CET] <atomnuker> yes [12:06:31 CET] <RiCON> sent [12:25:11 CET] <jdarnley> Curses. I've got a segfault what disappears in GDB [12:25:16 CET] <jdarnley> *that [12:29:44 CET] <atomnuker> valgrind it [12:41:19 CET] <kierank> or asan if it's thread related [13:33:00 CET] <durandal_1707> j-b: disfunctional team [13:43:49 CET] <wm4> Nablet Developer has a weird clock [13:45:06 CET] <wm4> (what kind of author name is that anyway, not that I'm someone to talk) [13:49:54 CET] <atomnuker> I wish instead of pushing for their library they'd submit a properly written demuxer [13:50:39 CET] <wm4> it's not a demuxer though [13:50:44 CET] <wm4> it's on the stream layer [13:51:10 CET] <wm4> I guess it's a byte transport protocol and it's for serving a normal container over it [13:52:56 CET] <atomnuker> meh, its not like they can do much for realtime streaming, it has to be udp and it has to be one-way only [13:53:25 CET] <kierank> huh, it's two way [13:53:35 CET] <kierank> they have just abstracted it as a "protocol" [13:53:56 CET] <atomnuker> well surely they don't have the time to ask the sender to resend a packet [13:54:06 CET] <kierank> they add buffering [13:54:09 CET] <kierank> in the receiver for that [13:54:40 CET] <atomnuker> do they do error correction? [13:54:48 CET] <kierank> no [13:54:59 CET] <kierank> just retransmit on some insane protocol they wrote [13:55:18 CET] <atomnuker> wtf, this is stupid [13:57:19 CET] <durandal_1707> atomnuker: 1 month passed and still no atrac9 decoder, you are very slow typing coder [13:58:33 CET] <atomnuker> on the other hand I have a fully working vulkan filtering infrastructure capable of importing dmabufs and a filter template to write whatever filter I wanna have [13:58:53 CET] <durandal_1707> but that is for gsoc [13:59:38 CET] <atomnuker> no, its up to the gsoc student to use what I've written to try to write MV search on the gpu, though I just know I'll have to do it myself [14:00:29 CET] <atomnuker> I'll post the vulkan patchset to the ML soon, then I'll get atrac9 finished [14:23:02 CET] <durandal_1707> iive: hi! why are you back? [14:23:37 CET] <iive> durandal_1707, what? [14:24:06 CET] <durandal_1707> i thought you left [14:25:15 CET] <iive> have you gone insane? [14:26:27 CET] <iive> or you are just trolling me. I don't find it funny. [15:33:58 CET] <jdarnley> atomnuker: in a 2-level wavelet transform without deinterleave the first dwt for the whole image would output "0 1 2 3" samples in a row... [15:34:18 CET] <jdarnley> but the second level should only touch the 0 and 2 samples [15:34:22 CET] <jdarnley> Is that right? [15:39:26 CET] <jdarnley> oh well all that code is wrong, that stride should increase as the SubBand gets smaller [16:17:01 CET] <cone-612> ffmpeg 03James Almer 07master:222d7055e2dd: avcodec/hevc_parser: use ff_hevc_decode_extradata() to parse extradata [17:25:18 CET] <cone-612> ffmpeg 03James Almer 07master:782e066e3e3d: avcodec/mediacodecdec: use ff_hevc_ps_uninit() [17:28:40 CET] <SortaCore> does NVENC still require screen plugged in and turned on? [20:41:40 CET] <SortaCore> hmm also does NVENC support crf [20:44:59 CET] <BtbN> no [20:45:07 CET] <BtbN> crf is an x264 thing [20:46:37 CET] <RiCON> (libvpx too) [20:46:55 CET] <SortaCore> qsv has ICQ with same range [20:48:14 CET] <BtbN> The meaning of crf varies greatly depending on which implementation adapted the name [20:48:26 CET] <BtbN> you can't pass the same number into the same implementation, and get the same result [20:50:26 CET] <SortaCore> hm, nvenc has adaptive quality thing [20:57:51 CET] <SortaCore> I see one place where the guy is recommending turn on adaptive quant, set constq mode as cq 1, and vbr it [20:58:06 CET] <SortaCore> and NVENC also has -qp and -cq parameters [21:04:35 CET] <BtbN> -cq is weird, and -qp has a whole different scale and meaning [21:12:25 CET] <SortaCore> interestin [21:13:09 CET] <SortaCore> tell me more [21:29:36 CET] <BBB> its difficult to explain if you dont understand some fundamentals about video compression [21:29:51 CET] <BBB> compression generally improves if not all frames use the same quantizer [21:29:58 CET] <BBB> but for testing, using the same quantizer can help greatly [21:30:02 CET] <BBB> -qp uses the same quantizer [21:30:08 CET] <BBB> -crf targets an average quantizer [21:30:28 CET] <BBB> so -crf will have a better overall quality, but -qp uses the same quantizer in the literal sense [21:30:37 CET] <BBB> -crf is for end users, -qp for developers, Id say [21:30:49 CET] <atomnuker> libvpx takes liberties with what it does with constant quantizers [21:46:32 CET] <SortaCore> yea, I know diff between crf and cq [21:46:40 CET] <SortaCore> -qp <int> E..V.... Constant quantization parameter rate control method (from -1 to 51) (default -1) [21:46:41 CET] <SortaCore> -cq <float> E..V.... Set target quality level (0 to 51, 0 means automatic) for constant quality mode in VBR rate control (from 0 to 51) (default 0) [21:46:51 CET] <SortaCore> just wondering what the difference between these is [21:46:53 CET] <BtbN> cq for nvenc never did anything for me. [21:47:04 CET] <BtbN> nvidia added it and sent a patch, and I never managed to make it do things [21:47:40 CET] <SortaCore> why does it say rate control "method" [21:57:35 CET] <mateo`> jamrial: thx for the mediacodec patch, and sorry for my lack of review/reply, i totally missed the patch on the ml [21:58:15 CET] <jamrial> mateo`: no prob [21:58:30 CET] <jamrial> and it was patch 4 in a set, so easy to miss [22:00:44 CET] <JEEB> yea, that was a nice one [22:18:51 CET] <kierank> michaelni: i appreciate you've been posting it for years but your mosad quotes are unnecessary [22:31:11 CET] <durandal_1707> kierank: also they are full of typos [22:34:42 CET] <SortaCore> that's just his way to avoid copyright strikes [22:48:47 CET] <cone-612> ffmpeg 03Michael Niedermayer 07master:4a75a75c62ef: avcodec/hevc_ps: Check log2_sao_offset_scale_* [22:48:48 CET] <cone-612> ffmpeg 03Michael Niedermayer 07master:2ff9f178519b: avcodec/indeo5: Do not leave frame_type set to an invalid value [22:48:49 CET] <cone-612> ffmpeg 03Michael Niedermayer 07master:fe1e6c06d034: avcodec/dirac_dwt: Fix several integer overflows [00:00:00 CET] --- Wed Jan 31 2018

1 0

ffmpeg.log.20180130
by burek 31 Jan '18

31 Jan '18

[00:07:21 CET] <kepstin> with the new multithreading, i wouldn't be surprised if vp9 is faster than vp8 in many cases. [04:01:06 CET] <mathcubes_> Yo can anyone help me? [04:01:23 CET] <mathcubes_> I need help with getting nvenc working with OBS [04:01:36 CET] <mathcubes_> I am using this [04:01:37 CET] <mathcubes_> https://gist.github.com/Brainiarc7/3f7695ac2a0905b05c5b [04:02:09 CET] <mathcubes_> But I am getting alot of makefile errors not existing [04:02:09 CET] <mathcubes_> paste.ubuntu.com/26486952 [04:02:26 CET] <nfobot> mathcubes_: Available functions: muxer demuxer encoder decoder filter source sink indev outdev protocol bsf [04:02:56 CET] <mathcubes_> @eveyone help [08:52:43 CET] <dragmore88> hi. Anyone know if ffprobe or ffmpeg supports detecting/setting the EAC3 parameter : convsnroffst ? (its to enable the ability to downfilter eac3 to ac3 compliant systems) [10:16:24 CET] <ArsenArsen> how do I read frames from x11grab/gdigrab/avfoundation inside C? [12:12:09 CET] <GianlucaF> Hi guys, can someone help me about guidelines to create a video from multiple scenes, where a scene is a combination of Image + N lines of Text? [12:13:33 CET] <GianlucaF> I think I need to create N intermediate videos ( one for each scene ) and then join each scene video with the next one ... or there is a more quick way to do this? [12:48:57 CET] <hanna> I was sent here from #mpv: apparently, the `loudnorm` filter doesn't pass through PTS or something - using it with -af inside mpv (with the new filter code) causes seeking to take forever and prints invalid audio PTS warnings [12:49:03 CET] <hanna> other filters like `dynaudnorm` don't have the same issue [12:49:33 CET] <hanna> any clues? [12:49:59 CET] <hanna> if you have mpv, just compile git master against ffmpeg git master and run `mpv --no-config -af loudnorm FILE.mp4` and seek around [12:53:41 CET] <JEEB> Kyle Swanson and durandal_1707 are the latest who have touched that filter [12:53:56 CET] <JEEB> looking at `gitk libavfilter/af_loudnorm.c` [12:58:42 CET] <durandal_1707> JEEB: its small patch thats needed to fix it [13:00:58 CET] <hanna> hmm using :print_format=summary it seems like the frame_type starts out as LINEAR but then switches to DYNAMIC after a seek [13:01:00 CET] <hanna> that seems... unexpected [13:01:56 CET] <hanna> interestingly enough even if :linear=false [13:04:47 CET] <hanna> Hmm, no, that's only printed on uninit [13:22:36 CET] <th3_v0ice> Why does this code needs to be there, x4->params.i_fps_num = avctx->time_base.den; [13:22:37 CET] <th3_v0ice> x4->params.i_fps_den = avctx->time_base.num * avctx->ticks_per_frame; [13:23:48 CET] <th3_v0ice> If I leave my timebase to be av_invq(framerate), my video has half of the fps, because of these two lines. Now I am sure there is a good reason why this is there and I am just wondering what is it? [13:25:47 CET] <solidus-fractal> hey all, i'm trying to build ffmpeg on windows 10 in order to link the libs and use them in a visual studio 2017 project and have no clue where to start [13:25:58 CET] <solidus-fractal> I've installed msys2 and followed a guild i found on the wiki [13:26:18 CET] <solidus-fractal> but configure --enable-shared has been stuck on one command with config.log not advancing for about 20 minutes [13:26:24 CET] <solidus-fractal> from mingw64.exe [13:27:05 CET] <solidus-fractal> i launched mingw64.exe from my msys2 install directory from a msvc 2017 development shell [13:27:22 CET] <solidus-fractal> and it appears to be compiling with gcc, the gthing its stuck on is.. [13:27:39 CET] <solidus-fractal> gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1 -D__printf__=__gnu_printf__ -D_WIN32_WINNT=0x0600 -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -std=c11 -fomit-frame-pointer -g -Wdeclaration-after-statement -Wall -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes -Wno-pointer-to-int-cast [13:27:39 CET] <solidus-fractal> -Wstrict-prototypes -Wempty-body -Wno-parentheses -Wno-switch -Wno-format-zero-length -Wno-pointer-sign -Wno-unused-const-variable -Wno-bool-operation -O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize -Werror=format-security -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=return-type -Werror=vla -Wformat -fdiagnostics-color=auto -Wmaybe-uninitialized -c -o /tmp/ffconf.sTbDf0bk/test.o [13:27:40 CET] <solidus-fractal> /tmp/ffconf.sTbDf0bk/test.c [13:27:52 CET] <solidus-fractal> :X, sorry, forgot to pastebin that [13:28:31 CET] <solidus-fractal> https://pastebin.com/gTcyfh93 [13:28:48 CET] <solidus-fractal> should i leave mingw64.exe running with the configure command up? i'm a bit lost [13:29:00 CET] <solidus-fractal> will this even generate .libs i can use to link into a visual studio 2017 project? [13:40:10 CET] <hanna> JEEB: durandal_1707: I think this patch fixes it https://0x0.st/sbQf.txt [13:42:01 CET] <hanna> it certainly works around the issues, though I'm not sure if that's the correct fix [13:44:42 CET] <esc-reality_> Could someone maybe take a look at this?: trac.ffmpeg.org/ticket/6949 [13:44:48 CET] <esc-reality_> Thanks in advance :$ [13:49:06 CET] <solidus-fractal> heyyy, it configured, is there anyway to build jus the libs with make :? [13:55:33 CET] <sfan5> if you configure with --disable-programs it will just build the libs [13:56:09 CET] <sfan5> configure always takes long on windows btw [13:56:47 CET] <solidus-fractal> so if i just want the 64bit libs to link into msvc 2017 x64... i want ./configure --enable-shared --disable-programs :? [13:56:57 CET] <solidus-fractal> and if i alreayd configured and reconfigure on top, will anything be foobar'd? [13:57:25 CET] <solidus-fractal> sorry, this is my first time trying to get anything in mingw to play nicely with vs 2017, i've been spoiled by a life of linux only targets [13:57:27 CET] <sfan5> 1) yes 2) no [13:58:13 CET] <sfan5> though mingw usually generates .dll.a, which i'm not sure if MSVC can handle [13:58:28 CET] <durandal_1707> hanna: AV_NOPTS_VALUE [13:58:41 CET] <solidus-fractal> i dont think it can, but theres mention on the wiki of a tool called lib.exe that comes with msvc [13:58:49 CET] <solidus-fractal> that can take lib.a's [13:59:50 CET] <solidus-fractal> if i can get to apoint iwth some .lib.a's and header files linked into my vs solution, i'll be hapily tackling how to use lib.a's :P [14:00:21 CET] <JEEB> dll.a is something htat MSVC can handle just fine [14:00:35 CET] <JEEB> you just have to specify the .a file instead of just name without suffix [14:00:46 CET] <JEEB> aka libthing.dll.a instead of libthing [14:00:53 CET] <solidus-fractal> between learning visual studio stuff, then cmake on windows, writing cmake stuff, and now trying to figure out msys2.. i'm suprised anythign gets done in a windows build environment [14:00:55 CET] <JEEB> because MSVC only searches for .lib [14:01:11 CET] <solidus-fractal> JEEB, thanks! [14:02:31 CET] <JEEB> solidus-fractal: also if you have the MSVC lib command in your PATH I think FFmpeg's build system should be able to utilize that one [14:03:37 CET] <JEEB> although I'm not sure now that I grep a bit more [14:04:12 CET] <JEEB> that said, .a files should work as long as you specify them with the extension(s) instead of just the name of the lib` [14:04:27 CET] <solidus-fractal> JEEB, do you know any other gotchas / tips for compiling .libs and .dll's to link to a msvc project? [14:04:55 CET] <solidus-fractal> would it pick up that lib.exe is there and use it instead if it was in my path or is that a param to configure [14:06:56 CET] <GianlucaF> Hi guys, can someone help me about guidelines to create a single video from multiple scenes, where a scene is a combination of one image ( or video ) + N lines of Text? [14:10:04 CET] <solidus-fractal> wait, lib.exe is a windows executable, that wont run inside mingw64 so how would it know hhow to use it :? [15:01:25 CET] <Fyr> guys, what are the options for matroska container to make it playable even when the file is incomplete, like mov_flags for MP4? [15:02:05 CET] <Fyr> when MP4 is incompletely downloaded, it can be played, but MKV can't. [15:02:39 CET] <Fyr> at least, with the default options.. [15:03:00 CET] <sfan5> in my experience it's the other way around [15:09:34 CET] <kepstin> mkv usually can be played but not seeked in that case [15:09:44 CET] <kepstin> (or slow seeking because no index) [15:10:11 CET] <kepstin> there's a few old versions of ffmpeg where mkv files couldn't be played as they were being written, but that's fixed now [15:11:05 CET] <Fyr> ok, seeked. [15:11:15 CET] <kepstin> anyways, there's two options: 1. use the -reserve-index-space <size> option, see the format docs for details [15:11:26 CET] <kepstin> or 2. use the 'mkclean' tool to fix the file after it's made [15:50:17 CET] <saml> -filter_complex framerate=fps=24001/1001 is this okay? [15:50:22 CET] <saml> using fraction as framerate [15:50:37 CET] <furq> sure [15:50:38 CET] <saml> i don't see much difference than specifying 23.9 [15:50:42 CET] <saml> nice [15:51:40 CET] <furq> the difference between 24000/1001 and 23.976 is about two frames an hour [15:51:58 CET] <furq> so it's not just an academic distinction [15:52:58 CET] <furq> 23.9 would be about 6800 frames an hour so definitely don't do that [15:53:30 CET] <saml> okay thanks [15:54:07 CET] <furq> also the framerate filter generally doesn't give good results [16:01:20 CET] <saml> yup that's what I noticed [16:01:33 CET] <saml> i assume it's because a lot of media is interlaced [16:06:32 CET] <alexp> saml: just to make sure you didn't typo in your original question, it's 24000/1001, not 24001/1001 [16:42:31 CET] <saml> alexpigment, thanks "avg_frame_rate": "24000/1001", [16:49:05 CET] <alexpigment> saml: cool. just wanted to point that out in case you were about to run a bunch of encodes with a fractionally incorrect rate :) [16:50:19 CET] <furq> saml: no it doesn't give results because it just does a linear blend [16:50:38 CET] <furq> normally you want fps or minterpolate (or telecine if you're going from 30 to 24) [16:51:00 CET] <furq> i put that in parens so that people wouldn't yell at me for recommending creating new telecined content in 2018 [16:51:38 CET] <alexpigment> furq: as long as ATSC and DVB still exist, many people will be telecining in 2018 [16:51:53 CET] <alexpigment> and in 2019 [16:51:56 CET] <alexpigment> and so on [16:52:43 CET] <kepstin> I mean, you can switch modes in ATSC, I think? but why bother when you could just statically set your encoder for 1080i and telecine stuff that doesn't match :/ [16:53:00 CET] <alexpigment> really? [16:53:01 CET] <JEEB> most broadcast specs let you code the video rather freely regarding that [16:53:05 CET] <alexpigment> i didn't think atsc had a 24fps mode [16:53:14 CET] <JEEB> yea, 24Hz I'm not sure [16:53:21 CET] <JEEB> but I've seen soft telecine at least [16:53:38 CET] <JEEB> as in, actual coded was not full rate, and then headers tell the decoders to add fields [16:53:42 CET] <alexpigment> just saying, most networks still telecine [16:53:47 CET] <JEEB> sure [17:01:48 CET] <wouter> hi -- what does ffmpeg do if I give it "-safe 0" when concatenating files with the concat demuxer? [17:02:08 CET] <wouter> I see that in the examples everywhere, but I can't find the right man page to see what -safe does and what the 0 means... [17:02:15 CET] <furq> it just disables the protocol whitelist iirc [17:02:22 CET] <furq> normally you'd need to prepend every entry with file:// [17:02:49 CET] <furq> !demuxer concat @wouter [17:02:49 CET] <nfobot> wouter: http://ffmpeg.org/ffmpeg-formats.html#concat-1 [17:02:53 CET] <furq> it's listed in there iirc [17:03:46 CET] <kepstin> wouter: it's basically a protection so that someone can't make a playlist you play off the internet which loads your local files or whatnot. [17:05:31 CET] <wouter> okay, thanks [17:09:03 CET] <JEEB> &34 [17:13:15 CET] <saml> furq, i don't understand between linear blend vs. minterpolate [17:13:18 CET] <saml> i'll study [17:13:41 CET] <durandal_1707> study hard [17:14:58 CET] <saml> okay i give up. let's go shopping [17:15:27 CET] <furq> all you really need to know is that minterpolate is much better but also really slow [17:17:23 CET] <saml> Convert the video to specified frame rate using motion interpolation. [17:17:35 CET] <saml> oh so I should use minterpolate instead of framerate filter [17:20:07 CET] <furq> it depends what you're doing [17:20:26 CET] <Diag> furq: can ffmpeg do minterpolate realtime [17:20:32 CET] <saml> i'm doing psnr :P [17:20:34 CET] <Diag> from a capture device [17:20:46 CET] <furq> Diag: i doubt it [17:21:01 CET] <Diag> how slow is it [17:21:12 CET] <furq> saml: if you're trying to compare two clips of different framerates then every method is going to give terrible results [17:23:13 CET] <saml> furq, yeah. so far best result is: ffprobe on main. and encode reference losslessly to match main's spec. and use that as ref [17:23:32 CET] <saml> but it's slow to create that lossless ref [17:23:47 CET] <saml> but it works! [17:24:18 CET] <saml> encoding 4k resolution clips is soooooooo slow [17:24:37 CET] <saml> i wonder if there's a way to launch multiple machines with multiple cores and somehow distribute encoding [17:24:58 CET] <saml> let's say i'm youtube. i'm rich [17:25:17 CET] <saml> there's a giant 4k resolution video being uploaded (or livestreamed) [17:25:40 CET] <saml> so i panic and give up [17:25:53 CET] <saml> my poor web server [17:27:53 CET] <saml> i think youtube uses mapreduce and bigdata in this scenario cause google [17:27:57 CET] <kepstin> i'm 90% sure youtube already does that. for streamable formats I think they start the encoding as you upload too. [17:28:43 CET] <alexpigment> well, youtube does it incrementally by resolution too [17:28:45 CET] <saml> if i split each frame into tiles and distributed workers encode each tile and combine later on, encoding quality would suffer, right? [17:28:51 CET] <saml> depending on tile size.. etc [17:28:52 CET] <alexpigment> so the 360p is first, 480p, 720p, then 1080p, etc [17:29:42 CET] <saml> i read twitch wrote their own so that video is decoded only once and do 360p, 480p... etc in parallel using already decoded stream [17:29:44 CET] <kepstin> saml: you'd have to re-encode again later to combine them, so that's just a waste of effort. The way you actually do it is split it up into chunks by time (so 10s or whatever), and encode each chunk separately. Then it's just concatenation to merge them. [17:30:30 CET] <furq> well the nice thing about youtube is you don't need to merge them [17:30:46 CET] <furq> or you wouldn't need to if it wasn't for apple and windows xp [17:31:29 CET] <saml> where you chunk would affect encoding quality right? if one chunk happens to have similar colors... etc [17:32:06 CET] <kepstin> saml: for segmented streaming, the video is already being chunked/split, so there's no difference. [17:33:34 CET] <kepstin> it's just the same as encoding video with a fixed gop size. [19:09:12 CET] <saml> yeah HLS will die i think [19:09:22 CET] <saml> what is gop? [19:09:42 CET] <saml> The Republican Party, commonly referred to as the GOP [19:09:58 CET] <saml> group of pictures [19:10:13 CET] <klaxa> why should hls die? [19:10:48 CET] <saml> cause Apple's players don't adhere to their published "spec" [19:11:12 CET] <saml> it won't die. [19:29:20 CET] <saml> so during encoding (for output), -r duplicates or drops frames to match specified fps. is it same as minterpolate? [19:31:19 CET] <saml> why would you convert framerate of video during encoding? [19:31:30 CET] <saml> some devices only support specific frame rate? web optimized? [19:31:55 CET] <c_14> no, it's the same as the fps filter [19:31:58 CET] <c_14> (because that's all it does) [19:34:57 CET] <alexpigment> saml: there are lots of reasons to convert framerate during encoding [19:35:01 CET] <alexpigment> device compatibility is one [19:35:27 CET] <alexpigment> also, format compatibility (e.g. blu-ray can't support 1080p60 officially) [19:36:05 CET] <alexpigment> the other reason would be to convert variable frame rate to constant frame rate [19:36:20 CET] <alexpigment> because of either player compatibility or some sort of standard [19:36:50 CET] <saml> ah i see. with -r 30 -acodec copy, there's audio sync issue. why? [19:37:03 CET] <saml> is it because timestamp(?) gets re-written? [19:37:25 CET] <alexpigment> hmmm, i'm not sure about that one [19:37:29 CET] <saml> like something says 1 minute mark is Nth frame but now it's Mth frame. but audio is the same [19:37:29 CET] <alexpigment> what is the source frame rate? [19:37:37 CET] <saml> 120fps [19:37:50 CET] <alexpigment> and the -r is *after* the input? [19:37:57 CET] <saml> yeah [19:38:09 CET] <alexpigment> just to be clear, the speed of the video isn't changing, right? [19:38:22 CET] <saml> i'm not sure how to teste [19:38:30 CET] <alexpigment> well, does it look 4x slower? [19:39:09 CET] <alexpigment> anyway, presumably you've also done -r 120 and confirmed that that problem doesn't happen there either, right? [19:39:25 CET] <saml> ah [19:39:31 CET] <alexpigment> if it happens with -r 120, then obviously the -r is not the culprit [19:40:25 CET] <saml> that's a good idea to find culprit. (i wasn't the doing the encoding. just was answering someone's question from different channel [19:40:36 CET] <alexpigment> ah [19:41:27 CET] <alexpigment> well, it's either a) the framerate is additionally being defined as 30 before the input, and therefore the speed is changing, or b) the simple act of encoding the video and copying the audio is causing the sync issue [19:41:36 CET] <alexpigment> my 2 cents, anyway [19:50:25 CET] <elmarikon> cheers everyone! [19:50:42 CET] <elmarikon> Hasanyone tried the new libvmaf-Filter in ffmpeg, yet? [19:51:13 CET] <elmarikon> I had huge problems compiling that thing, and now it won't run... [19:51:31 CET] <elmarikon> meaning ffmpeg works, but the filter doesn't. [19:53:30 CET] <elmarikon> this is all I get: https://pastebin.com/eBnV0AjE [19:53:47 CET] <elmarikon> can anyone suggest, what to do, plz!? [19:56:35 CET] <saml> Conversion failed! [19:56:47 CET] <saml> [Parsed_libvmaf_0 @ 00000000028635c0] libvmaf encountered an error, check log for details [19:56:51 CET] <furq> does the vmaf log say anything [19:56:53 CET] <saml> is there log for libvmaf? [19:57:20 CET] <saml> libvmaf=log_path=/tmp/yolo.log [19:57:58 CET] <saml> https://www.ffmpeg.org/ffmpeg-all.html#libvmaf wow libvmaf comes with psnr :) [19:58:06 CET] <saml> i've been dealing with psnr for too long [20:11:26 CET] <elmarikon> saml: there is no log... [20:11:56 CET] <elmarikon> i also tried to define the log-path. nothing... [20:40:52 CET] <saml> log_path bro [20:41:02 CET] <saml> full cli and example video would help [20:41:07 CET] <saml> so that i can study :P [20:41:27 CET] <geuis> hey folks, I'm trying to build ffmpeg from git head with librsvg enabled but getting the error "ERROR: librsvg-2.0 not found using pkg-config". Config paste is https://pastebin.com/p4YHJFLU [20:51:16 CET] <saml> geuis, pkg-config --cflags --libs librsvg does this work? [20:51:22 CET] <saml> not sure what's module name for librsvg [20:53:14 CET] <JEEB> geuis: see ffbuild/config.log [20:53:17 CET] <JEEB> for exact failure [20:53:38 CET] <atomnuker> hey someone's using the rsvg wrapper I wrote, awesome, didn't think anyone else would find it useful [20:58:13 CET] <geuis> This is the last chunk in the config before it fails [20:58:14 CET] <geuis> gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -I/usr/local/apps/ffmpeg/ffmpeg_build/include -std=c11 -fomit-frame-pointer -fPIC -pthread -pthread -I/usr/include/librsvg-2.0 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/u [20:59:28 CET] <geuis> Sorry that didn't paste. Included here https://pastebin.com/KD0Tq3dk [20:59:55 CET] <geuis> Basically this: /usr/bin/ld: cannot find -lselinux collect2: error: ld returned 1 exit status ERROR: librsvg-2.0 not found using pkg-config [21:03:03 CET] <geuis> @atomnuker if I can get librsvg to work, it potentially will solve a big feature problem for a video creation pipeline I'm building [21:03:24 CET] <geuis> it *was* building on Friday, but as of yesterday this error started [21:03:25 CET] <JEEB> geuis: somehow you're getting selinux's library required, which you don't have installed [21:03:46 CET] <geuis> that's weird. [21:04:04 CET] <JEEB> that comes out of some pkg-config check [21:04:10 CET] <JEEB> feel free to check which .pc file has it [21:04:44 CET] <saml> librsvg must be secure cause selinux [21:05:15 CET] <saml> dpkg -L librsvg2-dev | grep \.pc [21:05:44 CET] <saml> how much memory do I need for interpolate? [21:06:02 CET] <saml> Failed to inject frame into filter network: Cannot allocate memory [21:06:10 CET] <Diag> how much do you have [21:07:04 CET] <saml> https://gist.github.com/saml/5b4f4869558e0a2884014ec64c8e000e [21:07:13 CET] <saml> I have 16GB big data [21:09:36 CET] <geuis> @JEEB root@cbaea585c934:/# dpkg -L librsvg2-dev | grep \.pc [21:09:37 CET] <geuis> /usr/lib/x86_64-linux-gnu/pkgconfig/librsvg-2.0.pc [21:09:52 CET] <saml> pastebin the content of .pc? [21:11:39 CET] <geuis> https://pastebin.com/sWfzJhgj [21:12:24 CET] <saml> hrm that doesn't have selinux listed [21:12:44 CET] <atomnuker> what does pkg-config librsvg-2.0 --debug show? [21:14:17 CET] <geuis> checking [21:15:31 CET] <saml> which ubuntu version is this? [21:15:37 CET] <saml> i could try to do the same in docker [21:17:13 CET] <geuis> its debian:stretch [21:17:39 CET] <geuis> specifically, my base image is node:stretch https://hub.docker.com/_/node/ [21:18:53 CET] <saml> wow node.js [21:21:49 CET] <geuis> yeah super yummy. The other services calling ffmpeg are node based, so I'm building ffmpeg on the same base image and copying the cached binary over [21:23:41 CET] <geuis> @atomnuker https://pastebin.com/KkCef9Ua [21:23:58 CET] <saml> root@3c846e00654c:/# pkg-config --libs --cflags librsvg-2.0 |grep selinux [21:24:08 CET] <saml> returns nothing. so, I don't think it's a problem with librsvg-2.0 [21:24:30 CET] <geuis> on an aside, I also tried this with ubuntu:16.04 yesterday as the base docker image and had the same issue [21:25:40 CET] <saml> geuis, what is FFMPEG_VERSION? [21:25:48 CET] <geuis> 3.4.1 [21:26:02 CET] <geuis> its normally passed in as a build arg [21:26:37 CET] <JEEB> feel free to grep through ffbuild/config.log to see at what point selinux came up [21:26:49 CET] <geuis> I also cloned the git head for ffmpeg in the last hour and had the same thing happen [21:26:54 CET] <saml> PKG_CONFIG_PATH="${cwd}/ffmpeg_build/lib/pkgconfig" ./configure ... [21:26:57 CET] <saml> I think that's the problem [21:27:03 CET] <saml> why set PKG_CONFIG_PATH ? [21:27:07 CET] <JEEB> why not? [21:27:10 CET] <JEEB> it appends to the search path [21:27:16 CET] <JEEB> and he probably has some things he's built himself [21:27:28 CET] <saml> ah didnn't know it appends [21:27:33 CET] <JEEB> PKG_CONFIG_LIBDIR [21:27:35 CET] <JEEB> is the override one [21:27:46 CET] <JEEB> (which you use when cross-compiling f.ex.) [21:28:05 CET] <saml> PKG_CONFIG_PATH="${cwd}/ffmpeg_build/lib/pkgconfig" pkg-config --libs --cflags librsvg-2.0 [21:28:10 CET] <saml> hrm, that works... so i'm wrong [21:28:47 CET] <geuis> actually that's just there based on the compilation example given at https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu [21:29:23 CET] <JEEB> anyways, as I noted - grep around ffbuild/config.log [21:29:27 CET] <JEEB> see what exactly brought in selinux [21:29:41 CET] <geuis> with the exception of some extra vars like FFMPEG_VERSION, its basically the example instructions [21:29:53 CET] <JEEB> also as an unrelated recommendation `--disable-autodetect` is a nice thing [21:30:08 CET] <JEEB> it makes sure FFmpeg's configure doesn't try to do anything you don't ask it to [21:30:20 CET] <JEEB> (exceptions are still around, but in general) [21:30:22 CET] <geuis> selinux doesn't appear until the very end of the config.log [21:30:30 CET] <geuis> check_func_headers librsvg-2.0/librsvg/rsvg.h rsvg_handle_render_cairo -pthread -I/usr/include/librsvg-2.0 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -lrsvg-2 -lm -lgio-2.0 -lz -lresolv -lselinux -lgdk_pixbuf-2.0 -lm -lgmodule-2.0 -pthread -ldl -lpng16 -lm -lz -lm [21:31:06 CET] <JEEB> could be either cairo or glib [21:31:17 CET] <JEEB> although not sure at all [21:34:18 CET] <geuis> is this something that can be installed? `cannot find -lselinux` [21:34:31 CET] <JEEB> yes [21:34:38 CET] <JEEB> selinux development package would contain that library [21:34:51 CET] <JEEB> it comes out of somewhere not FFmpeg, that's for sure :D [21:35:03 CET] <JEEB> (since FFmpeg is only querying pkg-config for things) [21:36:01 CET] <geuis> MUCH SUCCESS! [21:36:28 CET] <geuis> root@b53c70ad9b33:/usr/local/apps/ffmpeg/ffmpeg_sources/ffmpeg-3.4.1# apt-get install libselinux1-dev [21:36:35 CET] <geuis> and ./configure worked [21:36:53 CET] <JEEB> yes because whatever told you it needed selinux didn't have selinux's library required packaging-wise :D [21:37:10 CET] <JEEB> although it still raises eyebrows for me [21:39:26 CET] <saml> while read -r x; do pkg-config --libs "$x" | grep selinux && echo "$x"; done < <(pkg-config --list-all |awk '{{print $1}}') [21:39:42 CET] <saml> nothing in pkg-config requires -lselinux [21:40:37 CET] <JEEB> a) use the PKG_CONFIG_PATH override you were using b) try --static in pkg-config parameters [21:41:08 CET] <JEEB> saml: well whatever it is FFmpeg isn't coming up with it by itself [21:43:35 CET] <saml> i blame node.js [21:43:54 CET] <klaxa> you can never go wrong with that [21:44:17 CET] <geuis> seconded [21:45:34 CET] <geuis> @JEEB --static is already in there ./configure \ --prefix="${cwd}/ffmpeg_build" \ --pkg-config-flags="--static" \ [21:45:59 CET] <JEEB> no, in your test [21:46:04 CET] <JEEB> since you tested with --static [21:48:48 CET] <geuis> oh you mean remove --static? [21:48:52 CET] <JEEB> no [21:49:00 CET] <JEEB> I mean in your pkg-config check-up for selinux [21:49:02 CET] <JEEB> :P [21:49:08 CET] <JEEB> ADD --static [21:49:23 CET] <JEEB> to pkg-config's flags for --libs "${x}" [21:49:54 CET] <geuis> this? pkg-config --cflags --libs --static librsvg [21:50:16 CET] <JEEB> --libs should be enough, but yes. that while loop you posted just some time ago here :P [21:50:32 CET] <geuis> sorry I don't do much of this kind of stuff =) [21:50:49 CET] <geuis> think that was saml [21:51:16 CET] <geuis> root@b53c70ad9b33:/usr/local/apps/ffmpeg/ffmpeg_sources/ffmpeg-3.4.1# pkg-config --cflags --libs --static librsvg Package librsvg was not found in the pkg-config search path. Perhaps you should add the directory containing `librsvg.pc' to the PKG_CONFIG_PATH environment variable No package 'librsvg' found [21:51:45 CET] <geuis> echo $PKG_CONFIG_PATH /usr/local/apps/ffmpeg/ffmpeg_build/lib/pkgconfig [21:52:16 CET] <JEEB> how did you just get it right like a few dozen lines upwards in the chat? [21:52:22 CET] <JEEB> and now suddenly get it wrong again? [21:52:53 CET] <JEEB> librsvg-2.0 is what you were posting earlier [21:53:36 CET] <geuis> not smart, that why [21:53:37 CET] <saml> grep -r selinux /usr/lib/x86_64-linux-gnu/pkgconfig/ [21:53:46 CET] <saml> /usr/lib/x86_64-linux-gnu/pkgconfig/gio-2.0.pc:Libs.private: -L/usr/lib/x86_64-linux-gnu -lz -lresolv -lselinux [21:53:53 CET] <saml> it's gio, it seems [21:54:11 CET] <JEEB> and then that gets grabbed by some library's privates [21:54:14 CET] <geuis> yeah --static provides some more details [21:54:14 CET] <saml> i guess gio is gnome io? [21:54:48 CET] <JEEB> geuis: basically --static means that pkg-config will try harder to find dependencies. for shared libraries it generally isn't needed, but if you have static ones it helps with those [21:55:07 CET] <JEEB> (mostly because the format for static libraries doesn't tell you if it depends on any shared ones) [21:55:37 CET] <geuis> gotcha [23:00:27 CET] <saml> wow bro psnr cray [23:01:11 CET] <saml> so, unless i know how video's framerate is generated (using -r or -filter framerate ...), I cannot calculate a good PSNR [23:02:19 CET] <alexpigment> saml: i don't want to keep asking you about this, but again, are you comparing two videos with different frame rates to get PSNR? [23:02:58 CET] <saml> sorry [23:03:04 CET] <saml> yup i am [23:03:10 CET] <alexpigment> stop doing that :) [23:03:21 CET] <saml> yup that's what i'm learning [23:03:35 CET] <saml> i had to try and convince myself. such foolish [23:03:36 CET] <alexpigment> frame rate and frame size need to be the exact same [23:03:48 CET] Action: saml googles frame size [23:03:52 CET] <alexpigment> resolution [23:03:58 CET] <alexpigment> e.g. 1920x1080 [23:04:09 CET] <alexpigment> also, scan type of course (progressive, interlaced) [23:04:16 CET] <alexpigment> most other things can vary [23:04:20 CET] <alexpigment> those elements can't [23:05:21 CET] <alexpigment> psnr is really only useful to measure the effects of encoding with a lower *bitrate* compared to a soure video [23:05:57 CET] <JEEB> PSNR is basically a calculation of how something is different from another :P [23:06:00 CET] <JEEB> for video that being frames [23:06:04 CET] <alexpigment> so i have my source - say that it's 100mbps - and I encode it to 2mbps, PSNR can give me a very basic description of how much quality i've lost in that process [23:06:29 CET] <alexpigment> but the numbers are really only useful in relation to other comparisons [23:07:22 CET] <alexpigment> for example, if i encode a 5mbps video from that 100mbps source, i'd ideally compare the psnr results of the 2mbps and 5mbps, so see at what bitrate i start dropping in quality significantly [23:07:42 CET] <JEEB> against the original of course [23:07:53 CET] <JEEB> so you have PSNR values against the original, and then you can plot them or whatever [23:08:01 CET] <alexpigment> JEEB: of course. i'm talking about how the psnr for one video doesn't mean anything really [23:08:22 CET] <alexpigment> it's good to compare the psnr results between two different videos (and the psnr is generated from comparing against the source) [23:08:43 CET] <JEEB> well I wouldn't say good, but when you know what exactly it is - it gives you a value [23:09:04 CET] <alexpigment> we're saying the exact same thing jeeb [23:09:16 CET] <JEEB> could very well be [23:09:41 CET] <alexpigment> point being: psnr is a generally meaningless number in a vacuum [23:31:12 CET] <saml> so, psnr is useful when everything is same but -vcodec [23:33:57 CET] <kepstin> nah, comparing psnr across different codecs isn't that useful [23:34:21 CET] <kepstin> it's kinda useful when everything is the same except bitrate, i guess? [23:44:08 CET] <DHE> PSNR implies that image quality can be expressed mathematically when codecs are usually tuned to the human eye [23:47:01 CET] <kepstin> yeah, and you can see that with the x264 tune options. The default is to use psy tunings, with reduce psnr; you can alternatively choose to optimize for psnr (or ssim) which reduces visual quality a bit. [23:47:58 CET] <kepstin> codecs tuned for psnr tend to make things look kind of smooth and blurry when they don't have enough bitrate [23:48:18 CET] <alexpigment> one of the reasons i hate bitrate-starved H.264 :) [23:48:38 CET] <alexpigment> sure, it doesn't get blocky, but it looks like entire sections have vaseline rubbed on them [23:48:43 CET] <kepstin> x264's defaults seem to try to preserve energy instead, so it'll leave blocking in textured areas rather than smooth them out. [23:48:59 CET] <kepstin> depends on other settings too tho [23:50:12 CET] <kepstin> if your source was really grainy tho, well, that'll never look good at low bitrate :) [23:50:28 CET] <alexpigment> very true [00:00:00 CET] --- Wed Jan 31 2018

1 0

ffmpeg-devel.log.20180129
by burek 30 Jan '18

30 Jan '18

[00:31:17 CET] <kierank> michaelni: is there any easy way to turn off er just for 10-bit [00:40:30 CET] <michaelni> yes [00:42:22 CET] <michaelni> see er_supported or ff_er_frame_end() its also turned off for other unsupported cases [03:43:57 CET] <raytiley_> sending patches w/ git to an email list is new to me... I just messed up and sent a new patch instead of replying to the original thread. What should I do if anything? [03:47:42 CET] <cone-873> ffmpeg 03Brendan McGrath 07master:4e3e8980b58f: dashdec: Fix segfault on decoding segment timeline [03:52:42 CET] <wm4> raytiley_: that's not so bad... to reply, you can use --in-reply-to [03:52:55 CET] <wm4> or just send them as attachments [03:53:28 CET] <wm4> also my mail client shows your mail as a reply [03:54:12 CET] <raytiley_> hmm.. I did that.. but showed up as a new thread in inbox. oh well... [03:54:40 CET] <raytiley_> thanks [03:54:41 CET] <Compn> its fine if new thread [03:54:46 CET] <Compn> welcome to contributing [03:55:34 CET] <wm4> I don't think we have an overlay strict policy on whether updated patches should be posted as reply or new thread anyway [03:57:15 CET] <raytiley_> cool, I'll keep that in mind for the future. The email list and git patches still stress me out a bit. [04:12:03 CET] <cone-873> ffmpeg 03Michael Niedermayer 07master:05f4703a168a: avcodec/mpeg4videodec: Check mb_num also against 0 [04:12:04 CET] <cone-873> ffmpeg 03Michael Niedermayer 07master:4a94ff4ccd4f: avcodec/get_bits: Document the return code of get_vlc2() [04:12:05 CET] <cone-873> ffmpeg 03Michael Niedermayer 07master:d4967c04e040: avcodec/mpeg4videodec: Avoid possibly aliasing violating casts [14:42:30 CET] <jdarnley> atomnuker: if you're not busy I need to ask you a some questions about vc2 encoder. [14:42:41 CET] <jdarnley> Which places does the order of transform coefficients matter? [14:43:00 CET] <jdarnley> I am trying to remove the deinterleave [14:43:49 CET] <jdarnley> I think I have teken care of encode_subband, count_hq_slice, and the haar transform. [14:44:02 CET] <jdarnley> But I still can't get identical output. [14:44:06 CET] <atomnuker> dunno what you mean, you can remove deinterleave and the only thing you should do is make the quantization functions pick the same coeffs as if there was deinterleave [14:44:52 CET] <jdarnley> Yeah, skip over values [15:04:25 CET] <Chloe> raytiley_: don't worry about fucking up sending stuff to the ML. It's clunky as shit and we've all done it [15:04:25 CET] <kierank> jdarnley: what was the problem with getting fragments into master? [15:04:49 CET] <kierank> jdarnley: for the encoder [15:05:00 CET] <jdarnley> I couldn't decode the output correctly with my crap little program. [15:06:00 CET] <jdarnley> So I think there is a bug since I think it did work correctly with our hacked branch [15:06:33 CET] <jdarnley> *a bug in what I added to the encoder for the master branch [17:43:09 CET] <kierank> jdarnley: but our hacked branch didn't touch encoder [17:43:19 CET] <kierank> or the hacks to do low latency you mean? [17:44:24 CET] <jdarnley> Yes, I do think my crap program could decode the output of our low-latency encoder branch [18:11:57 CET] <rindolf> hi all! make check fails here - http://paste.debian.net/1007843/ [18:13:38 CET] <chance83> what room for avfilter development? [18:16:26 CET] <Chloe> rindolf: distclean, reconfigure, and make [18:18:00 CET] <rindolf> Chloe: ok [18:24:47 CET] <rindolf> Chloe: done [18:25:12 CET] <rindolf> Chloe: now run make check again? [18:26:00 CET] <Chloe> yes [18:26:51 CET] <rindolf> Chloe: same problem [18:27:27 CET] <Chloe> make fate-api-threadmessage V=1 [18:28:44 CET] <rindolf> Chloe: http://paste.debian.net/1007847/ [18:29:26 CET] <Chloe> ldd ./tests/api/api-threadmessage-test [18:29:53 CET] <jkqxz> I think you built with --enable-shared. The test suite doesn't work normally in that case. [18:29:57 CET] <Chloe> are you explicitly asking it to produce shared libraries [18:30:13 CET] <rindolf> jkqxz: i did [18:30:22 CET] <Chloe> jkqxz: this sounds like a bug? [18:30:24 CET] <jkqxz> If you install it should work, as should setting LD_LIBRARY_PATH to point at the build directory containing the shared libraries. [18:30:55 CET] <Chloe> I guess a patch which sets LD_LIBRARY_PATH temporarily when testing with shared libraries would be welcxome [18:31:20 CET] <jkqxz> Chloe: I guess? Testing static builds is generally much saner. [18:31:49 CET] <Chloe> jkqxz: sure testing static builds is better, but you can hardly call not testing shared builds sane. [18:33:04 CET] <jkqxz> The only difference is the linking, which isn't really something the test suite is intending to test. [18:34:57 CET] <rindolf> you can refuse to run check on a shared build w a helpful msg [18:35:19 CET] <jkqxz> It works, you just have to install first. [18:36:12 CET] <jkqxz> So that the shared libraries it picks are the right ones. (The problem is more insidious when you already have older libraries with the same version installed, though.) [18:37:07 CET] <rindolf> jkqxz: i installed and it still fails [18:37:24 CET] <jkqxz> But yes, something to clean that up so it's harder to do the wrong thing would be welcome. [18:40:02 CET] <durandal_1707> chance83: this one [18:47:12 CET] <rindolf> jkqxz: ok [19:13:07 CET] <chance83> durandal_1707, if I made a change to some of the filters like adding a process_command to get some of the internal coefficients (example: integrated loudness from ebur128), what is the likelihood that patch would be accepted? [19:13:32 CET] <chance83> right now these patches just av_log on filter uninit [19:13:39 CET] <chance83> s/patches/filters [19:20:18 CET] <durandal_1707> chance83: dunno, ask ebur128 maintainer, ubitux [23:01:10 CET] <chance83> why doesnt a redirect on cout/cerr rdbuf work for av_log messages? [23:04:59 CET] <BtbN> Why would ffmpeg care about some C++ thing? [23:11:06 CET] <chance83> BtbN, duh... thank you [23:11:08 CET] <chance83> =) [00:00:00 CET] --- Tue Jan 30 2018

1 0

ffmpeg.log.20180129
by burek 30 Jan '18

30 Jan '18

[02:54:55 CET] <kennedy101> I have a scaling question. https://pastebin.com/BBz9rU1b [03:11:08 CET] <furq> you would do the thing you put in parens [03:11:39 CET] <furq> unless you're asking how that works with deinterlacing in which case get rid of -deinterlace and -vf yadif=1,scale=-2:720 [03:11:57 CET] <furq> i don't even know what -deinterlace is mapped to these days [03:38:04 CET] <kennedy101> furq - yes sir, need to append the part in parens. testing it on a short 1080x1920 now. [03:40:37 CET] <kennedy101> looks like cropdetect might be an option too for 480x720 LD transport streams. [04:05:35 CET] <moszeusz> hello! I am trying to use rubberband from librubberband library to pitch scale my audio file; it is described in https://ffmpeg.org/ffmpeg-filters.html#rubberband but ffmpeg ver. 3.4.1 doesn't find it [04:06:22 CET] <moszeusz> what should I do to use it or is there another way to pitch scale my file? [04:07:46 CET] <moszeusz> I'm sorry if I'm not precise enough but I'm new here and in using ffmpeg [08:53:18 CET] <yusa> Hello there, i am currently testing to stream a mp4 file from an embedded linux device to a nginx streaming server which runs on my development pc. Testing on my development pc i was fine with the command: "ffmpeg -re -i music.mp4 -c:v libx264 -f flv rtmp://192.168.10.35/live". But on the embedded linux platform unfortunately i only get about 3 fps at max. Any ideas to increase performance? I would consider transmitting less compressed [08:53:28 CET] <yusa> Bandwidth should not be limiting factor. [08:54:23 CET] <yusa> I am trying to watch the stream with the vlc player afterwards, so it should a compatible format. Any ideas? [08:55:58 CET] <furq> what cpu does this embedded device have [08:57:30 CET] <yusa> the platform is a Xilinx Zynq-7020 with a ARM ® Cortex"-A9 processor CPU [08:59:39 CET] <furq> yeah you're probably not going to have much luck transcoding video on that [08:59:56 CET] <furq> if the source is an mp4 then it's probably already h264 and aac [09:00:02 CET] <furq> in which case you can just use -c copy -f flv [09:00:48 CET] <yusa> Aha, i see. [09:01:59 CET] <yusa> Okay, as this is only for test purpose i maybe skip that step. Maybe you remember, i actually use case is to stream raw data images. [09:02:10 CET] <yusa> my* [09:02:16 CET] <furq> in that case you can try -c:v libx264 -preset ultrafast [09:02:33 CET] <furq> downscaling the images will also help a lot if that's acceptable [09:02:48 CET] <furq> ideally you'd do that before it gets to ffmpeg but otherwise -vf scale=123:456 [09:04:44 CET] <yusa> yes, sounds plausible [09:06:07 CET] <yusa> cat *.raw | ffmpeg -s 1280x960 -pix_fmt gray -f rawvideo -i - -c:v libx264 -f flv rtmp://192.168.10.35/live [09:07:45 CET] <yusa> So this command is also pretty weak in performance on my embedded platform. What could increase efficiency? [09:08:22 CET] <yusa> Ahh, "-c:v libx264 -preset ultrafast" this? [09:10:02 CET] <furq> yeah [09:10:13 CET] <yusa> Okay cool, i will give it a try [09:12:40 CET] <yusa> Unable to find a suitable output format for 'rtmp://192.168.10.35/live' rtmp://192.168.10.35/live: Invalid argument [09:12:56 CET] <furq> you still need -f flv [09:15:11 CET] <yusa> so i only added -preset ultrafast, what does it? [09:17:42 CET] <yusa> I am at 10 fps now. [09:28:28 CET] <yusa> For me it seems, that ffmpeg still has to encode something. Some outputs: "using cpu capabilities: ARMv6 NEONprofile High 4:4:4 Predictive, level 3.2, 4:4:4 8-bit 264 - core 148 r2748 97eaef2 - H.264/MPEG-4 AVC codec [09:28:45 CET] <JEEB> > ARMv6 [09:28:47 CET] <JEEB> my condolences [09:28:57 CET] <JEEB> also 4:4:4 encoding on a low-power device :/ [09:28:58 CET] <pmjdebruijn> yusa: the ffmpeg binary you're using is built for a previous generation of ARM [09:29:14 CET] <JEEB> I'm pretty sure NEON is runtime checked? [09:29:30 CET] <JEEB> yusa: is this an ARMv6 device? [09:29:39 CET] <pmjdebruijn> I though it's ARMv7 (A9)? [09:29:54 CET] <yusa> yes, should be Cortex-A9 [09:30:02 CET] <yusa> it is defenitely [09:30:10 CET] <yusa> so i got wrong ffmpeg version? [09:30:29 CET] <pmjdebruijn> well, at least libx264 [09:30:33 CET] <pmjdebruijn> the question is how much it'll matter [09:30:42 CET] <JEEB> there is some NEON code in x264 [09:30:44 CET] <JEEB> so it will matter [09:30:44 CET] <yusa> JEEB: what can i do about 4:4:4 encoding ? [09:30:46 CET] <pmjdebruijn> considering it seems it's using NEON [09:30:53 CET] <JEEB> oh, it says NEON [09:30:53 CET] <JEEB> derp [09:30:55 CET] <JEEB> ok [09:30:57 CET] <JEEB> sorry then [09:31:02 CET] <JEEB> E_NOT_ENOUGH_COFFEE [09:35:19 CET] <yusa> Okay. cat /proc/cpuinfo says: "ARMv7 Processor rev 0 (v7l)" and ffmpeg says using cpu capabilities: ARMv6 NEON. I installed ffmpeg through package manager, do you have to build it on my own? What impact does it have anyways? [09:35:47 CET] <yusa> *do I have to... [09:36:06 CET] <JEEB> well if it says NEON it's at least using NEON instructions [09:36:12 CET] <pmjdebruijn> https://www.johnvansickle.com/ffmpeg/ you might want to try that [09:36:13 CET] <JEEB> but 4:4:4 encoding will be slow in any case [09:36:24 CET] <pmjdebruijn> presumably the armhf [09:36:40 CET] <yusa> how to change it to a more performant encoding than 4:4:4 ? [09:36:51 CET] <JEEB> (sw encoding with ARM will be slow in any case, so you will only be able to do low resolution stuff) [09:37:15 CET] <JEEB> yusa: by making sure your input is not 4:4:4? the problem is that you cannot use software filtering for that because that will just slow you down *more* [09:37:51 CET] <pmjdebruijn> yusa: those binaries are static, just download and try them [09:37:56 CET] <furq> his input is gray8 iirc [09:38:33 CET] <furq> so it probably doesn't make much difference either way [09:39:17 CET] <yusa> Okay, i actually dont know what 4:4:4 means -.- so ye how could my "gray" format be something like 4:4:4 encoded? :'D [09:39:41 CET] <pmjdebruijn> it's chroma subsampling [09:39:44 CET] <furq> https://en.wikipedia.org/wiki/Chroma_subsampling#Types_of_sampling_and_subs… [09:39:46 CET] <pmjdebruijn> but you don't have chroma [09:39:54 CET] <furq> your input is gray8 so you don't have chroma so it won't make a difference [09:40:05 CET] <furq> you might as well add -pix_fmt yuv420p anyway [09:47:16 CET] <Daglimioux> I have a command that creates a 3 video and 1 "black screen" in a mosaic (2x2). 2 videos has a duration of 00:01:33 and the third one has a duration of 00:01:32. The video with duration of 00:01:32 has some frames missing from 00:00:24 to 00:00:26. When I do the compilation, the video is played as expected, but at 00:00:26, all videos are freezed while the audio continues being played. Any suggestion why is this behaviour happenin [09:47:30 CET] <Daglimioux> Here is the command: ffmpeg -i video1.webm -i video2.webm -f lavfi -i color=s=640x360:color=black:d=1 -i video3.webm -i audio1.opus -i audio2.opus -i audio3.opus -filter_complex "amix=inputs=3:dropout_transition=0; [0:v] scale=640x360, setdar=0 [r1c1]; [1:v] scale=640x360, setdar=0 [r1c2]; [3:v] scale=640x360, setdar=0 [r2c2]; [r1c1][r1c2] hstack=2 [r1]; [2][r2c2] hstack=2 [r2]; [r1][r2] vstack=2" -c:a libfdk_aac -b:a 96k -c:v lib [09:47:31 CET] <Daglimioux> -f mp4 -preset ultrafast -y output.mp4 [10:07:06 CET] <durandal_1707> Daglimioux: probably pts is jumping high [10:08:40 CET] <Daglimioux> durandal_1707: what does it mean? [10:11:46 CET] <durandal_1707> Daglimioux: presentation timestamps have big jumps, either use setpts filter to reset pts or fix video so it doesnt have pts jumps [10:13:09 CET] <Daglimioux> durandal_1707: I cannot fix the video, as it is a recording from another software. I will try the "setpts" option [10:17:12 CET] <cutechaos> Hello everyone, I have one doubt, Does FFmpeg support srt protocol as input (https://github.com/Haivision/srt)? [10:17:25 CET] <Daglimioux> durandal_1707: I've tried adding "setpts=PTS-STARTPTS" to each video, but now I get freezed at 00:00:26 seconds and cannot get further. With my command, atleast I could listen the rest of the audio inputs, but now VLC stops playing at 00:00:26 even with a duration of 00:01:33 [10:24:13 CET] <Daglimioux> durandal_1707: I've tried: "setpts=PTS". Same results :( In fact, when I play the "corrupted" video in VLC, sometimes VLC crashes at that timestamp [10:24:32 CET] <Daglimioux> I mean, the video itself, not the compilation [10:26:35 CET] <durandal_1707> Daglimioux: you need to completely rewrite pts, not just make it start from 0 [10:27:22 CET] <Daglimioux> Oh! okay, I'm dumb, sorry. Is there a doc about it, so I can learn how to do that? [10:30:11 CET] <yusa> Okay i tried the given binaries. There is no visible change to me. Still telling me he is using ARMv6 NEON capabilities. A tried to add -pix_fmt yuv420p at the output side, but changed to the bad. I would like to try "-f rawvideo" at output side, but i guess that will not work with my nginx and vlc solution... [10:36:18 CET] <durandal_1707> Daglimioux: its in examples of documentation [10:42:16 CET] <pmjdebruijn> yusa: you meant the link I pasted? keep in mind you need to start those binaries with ./ffmpeg right? [10:42:40 CET] <yusa> yes, i did [10:42:52 CET] <yusa> downloaded armhf version [10:42:53 CET] <pmjdebruijn> oh I thought those were ARMv7 built :( [10:43:08 CET] <pmjdebruijn> my bad [10:43:23 CET] <pmjdebruijn> still it's a good source of newer ffmpeg outside of your regular distro :D [10:55:51 CET] <furq> yusa: -pix_fmt gray -i - -pix_fmt yuv420p [10:55:55 CET] <furq> in case that wasn't clear [10:57:21 CET] <furq> but yeah it sounds like your only real option is to pipe in lower resolution images [11:27:12 CET] <yusa> Maybe other option is to forward my raw data using netcat to my dev pc and utilizing ffmpeg only at the dev pc for stream generation. [11:28:31 CET] <yusa> pmjdebruijn: ok, thanks anyways! [11:30:14 CET] <yusa> From ffmpeg can i directly pipe into mplayer? [11:33:53 CET] <furq> yes although you should probably be using mpv now [11:34:00 CET] <furq> -f rawvideo - | mpv - [11:34:31 CET] <furq> also you don't need netcat, just cat *.raw | ssh devpc ffmpeg -i - ... [11:35:50 CET] <durandal_1707> Daglimioux: ffmpeg have documentation at www.ffmpeg.org [11:36:04 CET] <yusa> yes, cool, that (mplayer pipe) works! Uff, whats wrong about mplayer? :D [11:37:21 CET] <yusa> cat *.raw | ssh devpc ffmpeg -i - ... (cool, is that performant? ) [11:38:22 CET] <furq> mplayer hasn't been developed for a while [11:38:34 CET] <furq> mpv is a fork that a lot of the devs jumped ship to [11:38:41 CET] <yusa> kk [11:38:51 CET] <yusa> i dont mind using mpv ;-) [11:39:02 CET] <furq> ssh probably isn't as performant as nc but i'm sure it'll be plenty fast enough [11:39:09 CET] <furq> you could probably force no cipher if you really want [11:39:52 CET] <yusa> ok, ill give a try [11:42:29 CET] <Daglimioux> durandal_1707: Thank you. I've been looking at it, but I still don't know how to properly use it (or which options should I use) to "rebuild" timestamp. Btw, I've been reading a post that it is almost "impossible" to do that and a re-encoding should work. I've tried to re-encode the videos with problems and the compilation completes succesfully, but re-encoding because of bad frames is not a true solution for my problem, as it wil [11:43:00 CET] <Daglimioux> multiple videos, then do the compilation. If video recordings are about 30 mins length, it will take almost 15-25 mins, which is not our goal [11:46:05 CET] <kazuma_> anyone having issues with zeranoe builds? [11:46:06 CET] <kazuma_> https://i.imgur.com/qSAUlqQ.png [11:46:18 CET] <kazuma_> this is like my 10th crash in a week :( [11:46:32 CET] <kazuma_> before that it never crashed in years of using his builds [11:52:52 CET] <Guest46325> Hello everyone I have question about ffmpeg when it make hardsub. my native language is farsi. i have subtite which in a line have mixed english and farsi word. when i make hardsub. subtitle have issue. in line have mixed english and farsi word direction is wrong. for example this screenshot is correct line in libreoffice writer and secend screenshot is output ffmpeg with wrong direction [11:52:57 CET] <Guest46325> http://uupload.ir/files/mo0q_correct-direction.jpg [11:53:10 CET] <Guest46325> http://uupload.ir/files/lx30_wrong-direction.jpg [11:53:42 CET] <Guest46325> is issue related to ffmpeg or my subtitle have issue? [11:56:44 CET] <relaxed> Guest46325: could be, which ffmpeg version are you using? [11:58:08 CET] <Guest46325> ffmpeg version 3.4.1 [11:58:55 CET] <furq> i doubt that's an ffmpeg bug, it's probably fribidi [11:59:25 CET] <JEEB> harfbuzz and fribidi are the two related components IIRC [11:59:44 CET] <JEEB> make sure both are built into your FFmpeg's subtitle rendering [11:59:49 CET] <Guest46325> does ffmpeg use fribidi for farsi language? [12:00:01 CET] <JEEB> depends on which renderer [12:00:10 CET] <JEEB> I think libass can use fribidi and harfbuzz with freetype2 [12:00:17 CET] <JEEB> *but* I also know it's far from perfect [12:00:25 CET] <furq> yeah idk if you need to build ffmpeg with fribidi, it should be fine as long as libass is [12:00:31 CET] <furq> but i guess it couldn't hurt [12:01:29 CET] <Guest46325> well what am i doing? [12:02:56 CET] <yusa> "cat *.raw | ssh -p 4422 yusa(a)192.168.10.35 ffmpeg -s 1280x960 -pix_fmt gray -f rawvideo -i - -c:v libx264 /home/yusa/out.mp4" principially works, but again, not at sufficient frame rates, 9 fps i am getting. I will check my bandwidth and file operation capabilities and come back or did i messed something up with the command? But mh, im guessing sending data over ssh is too costly... :( [12:04:53 CET] <Daglimioux> durandal_1707: Tbh this is making me going crazy. I cannot make it work :( [12:06:25 CET] <Daglimioux> durandal_1707: And as I mentioned earlier, re-encoding doesn't sound a "good" solution. If I have 9 recordings and my system has to re-encode all 9 streams into the same ones to fix frame errors and then do the compilation... It will take years to create the output video :( [12:07:28 CET] <relaxed> Guest46325: you could try https://www.johnvansickle.com/ffmpeg/ [12:08:45 CET] <durandal_1707> Daglimioux: you are reencoding anyway when stacking videos [12:09:33 CET] <Guest46325> relaxed: do you means I compile ffmpeg from source? [12:09:38 CET] <Daglimioux> durandal_1707: yes, but when I reencode with my example, is just one line of code reencoding webm - mp4. The solution I've found is going 1 by 1 reencoding webm to webm, then use the new ones to reencode again webm to mp4 [12:10:47 CET] <Daglimioux> with that, I can fix my webm file errors, but I cannot do it in one line and I have to reencode into the same codec to "fix problems", then reencode again. Sounds really awful [12:11:41 CET] <relaxed> Guest46325: no, if you run linux those are binaries with everything included [12:12:20 CET] <Guest46325> ok i got this i will try with new ffmpeg [12:14:05 CET] <relaxed> be sure and use the new binary, /path/to/new/ffmpeg -i ... [12:15:10 CET] <yusa> "time cat *.raw > test; time sync;" on my embedded linux platfrom gives me "real 0m11.209s" and "real0m9.063s". Seems to be the bottleneck here. 135 images / 11 sec = 12fps ... So, i know how to adjust my test setup. Thanks for great help anyways @furq. Really appreciate it! [12:20:45 CET] <Guest46325> i hardsub with new ffmpeg output still have issue on direction mix line [12:38:02 CET] <furq> relaxed: those binaries don't have fribidi do they [12:47:13 CET] <Daglimioux> durandal_1707: Okay. Thanks for all the information you provided. After talking with the recording service creator (janus), he says that when you have missing information from RTCPeers, the generated video file might have errors in dts/pts, bad RTP timestamps, etc. and he recommends to re-encode the resulting webm videos to fix some of those errors. It's weird that FFMpeg can't do that when a compilation with filter-complex is mad [12:48:08 CET] <Daglimioux> but it works when videos are re-encoded then compiled with filter-complex. Btw, I've found how to speed up vp8 re-encoding and it works like a charm. I suppose that I have to do that for all my recordings, but well. Thanks again for all the information and keep up the good work :) [13:01:12 CET] <th3_v0ice> Hello all. Can somebody please tell me how to properly set timebase for x264 encoder? I tried different combinations that use ticks_per_frame, inverted fps, 1/90000, but nothing seems to be working properly. I get the video as output which is correct in duration but its simply not at the bitrate that I specify using the crf. Changing the timebase gives different values for bitrate. Thanks. [13:02:46 CET] <BtbN> timebase and bitrate are entirely unrelated. [13:03:15 CET] <BtbN> of course, if you massively lower the fps, you technically get a super low bitrate. As two frames might play for a minute [13:05:13 CET] <th3_v0ice> But doesnt the timebase affect the fps? [13:07:37 CET] <BtbN> There is no fps. Only timestamps to a given timebase [13:08:05 CET] <yusa> Hey there, just wanted to share my success :) Achieved streaming mp4 video over ssh to PC and utilizing ffmpeg there to pipe through named pipe to mpv. Works like a charme! [13:08:08 CET] <yusa> Dev PC: [13:08:13 CET] <yusa> mkfifo fifo.mp [13:08:17 CET] <yusa> mpv fifo.mp4 [13:08:25 CET] <yusa> Embedded Linux Platform: [13:08:40 CET] <yusa> cat music.mp4 | ssh julian(a)192.168.10.35 "ffmpeg -i - -c:v libx264 -f flv pipe:1 > /home/julian/fifo.mp4" [13:09:25 CET] <yusa> *mkfifo fifo.mp4 [13:09:43 CET] <th3_v0ice> BtbN: Ok, then I am not properly setting the timebase. How to set one? Can You describe some steps? [13:10:01 CET] <BtbN> if you need to manually worry about the timebase you are most likely doing something wrong [13:10:26 CET] <BtbN> yusa, sorry to disappoint, but you are streaming flv in a pipe ending in .mp4, not mp4. [13:10:35 CET] <BtbN> mp4 cannot be streamed. [13:10:42 CET] <th3_v0ice> BtbN: But in the examples they are setting the timebase to be inverse of fps. right? [13:11:24 CET] <yusa> Okay, thanks for pointing out, maybe i should use other name for the named pipe, fifo.flv e.g. right? [13:11:43 CET] <th3_v0ice> BtbN: Also if I try to not specify it to the encoder my run fails. [13:12:20 CET] <BtbN> you need a valid timebase, yes. inverse of the fps is the most simple case. [13:12:31 CET] <BtbN> that makes in increment of 1 be the time of one frame [13:13:14 CET] <th3_v0ice> So if You include ticks_per_frame in the equasion, everything should be fine? [13:16:51 CET] <th3_v0ice> BtbN: Lets try a different approach. Should I, or should I not, set the timebase while transcoding? [13:16:52 CET] <BtbN> your timebase needs to have space for multiple ticks per frame [13:17:05 CET] <BtbN> Are you using ffmpeg.c? [13:17:36 CET] <BtbN> so if you have 30 fps, for two ticks per frame your timebase needs to be a multiple of 1/60 [13:17:43 CET] <th3_v0ice> I created my own class with the transcoding.c as a template, but I can look at the ffmpeg.c if You wont to point me to some specific code. [13:18:02 CET] <BtbN> Some containers also have fixed timebases [13:18:04 CET] <th3_v0ice> *want. [13:18:22 CET] <BtbN> but generally video encoders do not care about fps/timebase. They just pass through timestamps. [13:18:27 CET] <th3_v0ice> I am only using mp4 container. [13:20:59 CET] <Swervz> Hi how would I transcode a variable framerate video to constant framerate video with ffmpeg? Google results just have people saying to not record in VFR which is not helpful if you have existing videos [13:21:54 CET] <JEEB> there are filters to convert to a specific frame rate, the basic filters just duplicate or cut off frames to match the request frame rate [13:22:07 CET] <JEEB> additionally there's a slooow filter that does motion compensation if you want to go fancy [13:22:25 CET] <JEEB> and of course if you can encode VFR as VFR, that's the least bad alternative [13:22:39 CET] <th3_v0ice> BtbN: fps=50/2 timebase=1/50 does this seem right? [13:22:53 CET] <BtbN> for 25 fps, probably [13:22:53 CET] <Swervz> I just want to import it into adobe premiere but their broken software just chokes on VFR videos [13:23:20 CET] <furq> Swervz: just -vf fps=25 to do it naively [13:23:27 CET] <th3_v0ice> Yes, fps is 25, but why does my encoder when I set crf to 0, only achieves 122kbps ? [13:23:35 CET] <furq> i guess the higher the rate, the less bad it'll look [13:23:43 CET] <BtbN> th3_v0ice, because it doesn't need more? [13:23:52 CET] <Swervz> It's a ~60 fps clip [13:24:05 CET] <th3_v0ice> BtbN, what if I want it to achieve more? [13:24:11 CET] <BtbN> why would you? [13:24:28 CET] <BtbN> x264 does not waste bandwidth if it can achive losslessness with that little, it will [13:24:29 CET] <Swervz> Is there a way to specify cutting frames or duplicating frames? [13:24:43 CET] <furq> it'll do both [13:24:51 CET] <furq> whatever it needs to hit the target rate [13:25:16 CET] <Swervz> Is there a way to just drop frames and like round down the FPS to a constant number [13:25:58 CET] <furq> that's pretty much what fps will do if you set the target rate lower [13:26:06 CET] <Swervz> hmm okay thankyou [13:26:16 CET] <Swervz> yeah videos with duplicates always look more jarring than ones with dropped frames [13:26:18 CET] <Swervz> at least to me [13:26:31 CET] <th3_v0ice> BtbN, Hmm, but if the input clip is at 1.2mbps, and I specify crf 0, how can it not loose something when it encodes at 122kbps, because the sequence looks to be worse in qualiy. [13:26:40 CET] <furq> if you prevented it from duping frames then the output wouldn't be cfr if you have a 100ms discontinuity [13:26:47 CET] <furq> so that's obviously not something you'd usually do [13:27:02 CET] <furq> and if you don't have any long gaps then it won't dup anyway [13:27:16 CET] <Swervz> hmm what about the other filter that does the motion compensation? [13:27:19 CET] <BtbN> th3_v0ice, you did not properly set it to crf 0 then. [13:27:21 CET] <furq> minterpolate [13:27:26 CET] <furq> i've not used that and as JEEB said it's very slow [13:27:40 CET] <furq> and also all filters like that are prone to creating artifacts [13:28:08 CET] <furq> if the source is cfr and it has >1-frame gaps then it'll playback as if it had duped frames anyway [13:28:15 CET] <furq> so i wouldn't worry too much about that [13:28:35 CET] <furq> i would just try fps=60 and see if it looks jerky [13:28:56 CET] <furq> if it doesn't then there's not much point messing with minterpolate [13:29:20 CET] <Swervz> okay thankyou I guess Ill try just doing that first and then use minpolate if it looks werid [13:30:07 CET] <th3_v0ice> BtbN, I need to investigate a little bit more and will get back to You. Thanks for the help! [13:30:28 CET] <Swervz> its werid how google never found me this page https://ffmpeg.org/ffmpeg-filters.html when searching earlier [13:30:42 CET] <Swervz> I only found it because I searched for minterpolate [13:31:09 CET] <furq> yusa: you shouldn't need a fifo for that, just -f flv - | mpv - [13:33:16 CET] <yusa> Ok, but then i would be needed to initiate the command from the dev pc as i am not able to open windows (for mpv) through the ssh command form the embedded device i think [13:34:00 CET] <furq> oh right [13:34:53 CET] <furq> iirc you can do something like ssh embedded "cat /path/to/*.raw" | ffmpeg ... [13:35:21 CET] <yusa> yeah, than i would have a one liner :D [13:44:59 CET] <Swervz> Is there a way to output something that does not require much encoding? if I do ffmpeg -i "input.mp4" -vf fps=60 "output.mp4" it transcodes at 2x speed which is gonna take a really long time [13:45:34 CET] <Swervz> anything that works in adobe premiere would be fine [13:45:36 CET] <yusa> furq: thanks again, yes that just worked! Thanks again for simplifying my command ! :) [13:45:42 CET] <furq> if you just want to test what it looks like then output rawvideo or ffvhuff or something [13:45:45 CET] <sfan5> -preset ultrafast [13:45:52 CET] <furq> if it has to be compatible with premiere then yeah i guess preset ultrafast [13:45:53 CET] <sfan5> alternatively save it in a lossless video format [13:46:16 CET] <sfan5> adobe probably supports apple ProRes or something similar [13:46:20 CET] <Swervz> yeah lossless would be fine Its just so I can edit it in premiere then export [13:46:54 CET] <furq> i guess maybe ut video then? [13:47:05 CET] <furq> if you're on windows then there's a dshow component you can install that should make premiere load it [13:47:07 CET] <sfan5> https://helpx.adobe.com/de/premiere-pro/using/supported-file-formats.html prores works according to this [13:47:14 CET] <sfan5> so add -c:v prores [13:47:16 CET] <furq> is prores quick to encode [13:47:19 CET] <sfan5> not sure [13:47:43 CET] <furq> https://www.videohelp.com/software/Ut-Video-Codec-Suite [13:47:44 CET] <pmjdebruijn> Swervz: ffmpeg -c:v libx264 -tune:v fastdecode -intra out.mp4 [13:47:51 CET] <furq> uh [13:47:53 CET] <furq> no [13:48:22 CET] <Swervz> Yeah I'm on windows 10 sorry I should have specified [13:48:23 CET] <pmjdebruijn> Swervz: that'll get you good scrubbing compatibity, if you want it as a proxy codec [13:48:32 CET] <pmjdebruijn> but the video quality will suffer :) [13:48:38 CET] <furq> Swervz: install the thing i just linked and use -c:v utvideo [13:48:40 CET] <sfan5> I get 96 fps for 720p with prores here, so no it's not fast [13:48:42 CET] <pmjdebruijn> otherwise you might want to take a look at dnxhd [13:48:43 CET] <furq> if you have the disk space for it obviously [13:48:52 CET] <furq> you won't get any quicker than that [13:49:12 CET] <furq> premiere should be able to open it but you might need to use avi [13:49:22 CET] <Swervz> ok thankyou all for helping really appreciate it that codec looks good [13:51:07 CET] <Swervz> So after installing that codec I'm just transcoding it to a lossless format using avi as a container and the UT codec? [13:51:12 CET] <furq> right [13:51:30 CET] <Swervz> ah awesome [13:51:30 CET] <furq> you only need to install it so premiere can decode it [13:51:51 CET] <furq> that's the best lossless codec it supports afaik [13:52:13 CET] <Swervz> ah ok I get it now yeah [13:52:15 CET] <furq> certainly if you just want something quick [13:52:38 CET] <Swervz> I was confused at first because I remember using fraps a long time ago to do rawcap and then converting to avi but I guess that used a lossy codec [13:53:19 CET] <Swervz> unrelated to the current thing of course just an anecdote [13:53:24 CET] <furq> mkv supports ut video but idk if premiere supports mkv [13:53:36 CET] <furq> it shouldn't make any difference if this is just a temp file anyway [13:53:37 CET] <Swervz> nah it doesnt [14:02:04 CET] <yusa> I can see ffmpeg is a very powerful. Lets see where the limits are! Is ffmpeg cabable [14:02:18 CET] <yusa> of producing overlays? [14:03:13 CET] <yusa> e.g. i want add some colored points, rectangles, circles and lines to the images [14:04:55 CET] <furq> !filter drawbox @yusa [14:04:56 CET] <nfobot> yusa: http://ffmpeg.org/ffmpeg-filters.html#drawbox [14:05:07 CET] <yusa> maybe i can transmit these information through vector image format like MVG [14:05:22 CET] <yusa> Ahaa, okay, thanks for the link, let me have a look [14:05:25 CET] <furq> no circles though [14:05:39 CET] <Swervz> furq, does this look right to you? ffmpeg -i "input.mp4" -c:v utvideo -vf fps=60 "output.avi".mp4 [14:05:42 CET] <furq> there's also the overlay filter if you want to prerender an image and overlay it [14:05:47 CET] <Swervz> um [14:05:49 CET] <furq> lol [14:05:52 CET] <Swervz> ignore that mp4 [14:05:54 CET] <furq> other than that yeah [14:06:44 CET] <Swervz> apparently there is utvideo and libutvideo [14:07:13 CET] <furq> either should be fine [14:07:27 CET] <furq> idk which one is faster [14:07:51 CET] <Swervz> Non-monotonous DTS in output stream 0:1 I guess because I did not specify audio codec? [14:08:08 CET] <furq> just add -an to drop the audio [14:08:23 CET] <Swervz> But I want audio [14:08:30 CET] <Swervz> -codec:a pcm_s16le [14:08:36 CET] <furq> i guess that works [14:08:44 CET] <ArsenArsen> anyone got a code example to record x11grab into a file? (inside C/C++ [14:10:17 CET] <Swervz> I still only get 155FPS with that, beginning to think there is something wrong with my pc [14:12:13 CET] <Swervz> Looks like HDD bottleneck https://i.imgur.com/emUDzCB.png [14:12:51 CET] <Swervz> I guess its time to buy more SSDS [14:15:28 CET] <yusa> Is this a static overlay? Can I produce a frame accurant overlay (each frame its own overlay) ? [14:15:55 CET] <pmjdebruijn> you can overlay a video onto another video [14:16:20 CET] <Swervz> a different overlay for each frame sounds crazily complex [14:16:56 CET] <Swervz> I wouldn't even want to do that in a NLE lol [14:16:58 CET] <yusa> yes, but i do object recognition and want to mark found objects in each frame [14:18:03 CET] <Swervz> Oh that's a bit beyond me. Sounds fun though [14:19:20 CET] <Swervz> You making the next skynet or something? [14:19:26 CET] <yusa> maybe overlaying a video could be useful, mhh. [14:19:36 CET] <yusa> ;D [14:20:47 CET] <yusa> I was implementing hardware accelerator for the FPGA Zynq platfrom for real-time object detection. Now i am on my way setting up a nice demonstrator ;-) [14:23:42 CET] <Swervz> Is this the sort of thing you want to do? https://superuser.com/questions/1172260/ffmpeg-overlaying-images-sent-throu… [14:27:34 CET] <yusa> Swervz: Yes, something like that. But ideally it should be frame accurate, maybe i will have to do it by my own or with libSDL maybe beforehand. [14:55:17 CET] <yusa> mh, libSDL will not work without creating windows, damn. Need to create my overlays in a smart way :P [16:31:23 CET] <Tweak> Goody day everyone. Is anyone familiar with the API? Trying to do a crossfade, but a bit lost on how the initialize and use filters [16:40:54 CET] <azarus> Would it make sense to convert my 720p h264 library to h265? [16:41:36 CET] <Swervz> hey my command fails with "[h264_nvenc @ 00000000027e1020] EncodePicture failed!: unsupported param (12)" anyone know why? ffmpeg -i "input.mp4" -c:v h264_nvenc -profile high444p -pixel_format yuv444p -preset default -c:a copy "output.mp4" [16:41:48 CET] <teratorn> azarus: considering storage price/MB over time... probably not [16:41:56 CET] <lyncher> when encoding from a raw source (SDI/declink) does ffmpeg retains timecodes that can be available in SDI? [16:42:04 CET] <Swervz> azarus, I assume its already lossy compressed [16:42:09 CET] <azarus> Swervz: yes [16:42:13 CET] <Swervz> transcoding it will probably just make it look worse [16:42:20 CET] <Swervz> for minimal gain in other aspects [16:42:34 CET] <azarus> I'm not exactly struggling for space either :/ [16:42:46 CET] <teratorn> azarus: are you going to do it again when the next whiz-bang codec comes along? [16:43:33 CET] <azarus> teratorn: relevant? https://xkcd.com/1683/ [16:43:36 CET] <alexpigment> azarus: i think you've answered your own question with a resounding "no" :) [16:44:06 CET] <azarus> Hrm. But I might recode the audio! :P [16:44:11 CET] <alexpigment> why? [16:44:30 CET] <teratorn> azarus: cute [16:45:01 CET] <azarus> Kinda want everything uniformely opus, but I suppose it's not really practical [16:45:17 CET] <alexpigment> there's no benefit to doing all that imho [16:45:38 CET] <azarus> Just keep it as it is? [16:45:41 CET] <furq> on the plus side, that will at least run faster than 0.1x like x265 would [16:45:46 CET] <furq> on the minus side, literally everything else about it [16:46:11 CET] <azarus> What I find funny is that some movies (of the same length) take up several GBs while others take only like 700MB [16:46:32 CET] <furq> well yeah some people are bad at encoding movies [16:46:46 CET] <furq> most people, in fact [16:46:55 CET] <Swervz> but its a lossy format [16:46:59 CET] <Swervz> why would you want to transcode [16:47:18 CET] <furq> yeah you'd generally better have a good reason for transcoding lossy to lossy [16:47:25 CET] <Swervz> there are zero benefits I can think of unless you have some archaic device [16:47:36 CET] <azarus> Smaller filesizes? [16:48:03 CET] <azarus> (but then again, storage is cheap) [16:48:04 CET] <furq> especially given what you have is probably a bdrip or a dvdrip which is already a lossy transcode [16:48:16 CET] <Swervz> I think it just comes down to if you care about quality over quantitiy [16:48:35 CET] <azarus> I don't care that much about quality tbh, my eyes aren't that great [16:48:44 CET] <Swervz> you should get glasses [16:48:47 CET] <azarus> (or rather, some blockiness doesn't bother me) [16:49:00 CET] <kepstin> I mean, if you e.g. want a copy that fits on your phone or something, then transcode to a copy for your phone. But a copy, don't delete the source ;) [16:49:13 CET] <Swervz> most phones can handle h.264 just fine though [16:49:18 CET] <Swervz> and have ample storage these days [16:50:43 CET] <azarus> Oh well. Still leaves me wondering why some files are huge and some tiny without looking that different quality-wise [16:51:06 CET] <furq> the smaller one was probably denoised to hell [16:51:40 CET] <furq> if that's 720p then i would also expect it to have a lot of ringing [16:52:06 CET] <Swervz> I'm not sure what to tell you if you can't see the difference [16:52:43 CET] <azarus> I'm not a pixel-peeper, if that helps [16:53:08 CET] <Swervz> I can see the difference like 20 feet away from my tv [16:53:09 CET] <kepstin> keep in mind also that the *content* of the video highly influences what filesize/bitrate you need to hit a particular quality level [16:53:26 CET] <Diag> >pixel peeper [16:53:29 CET] <Swervz> Maybe you don't know what to look for at that point sometimes its best to not know.. Because like with screen tearing you will forever be cursed to notice it after someone shows you what it is [16:53:29 CET] <kepstin> so you can't really compare two different movies [16:53:30 CET] <azarus> kepstin: yup; movies with lots of stills take up far less space, right? [16:53:54 CET] <Diag> Swervs that's why you go with freesync [16:54:17 CET] <Swervz> or gsync, I have a nvidia gpu [16:54:23 CET] <Diag> Gross [16:54:33 CET] <Swervz> I'd buy amd if they had more powerful gpus [16:54:36 CET] <azarus> Swervz: I do have a FreeSync GPU and monitor; and I do notice a slight difference [16:54:42 CET] <Diag> It's major [16:54:58 CET] <Diag> You can't get a shit monitor, get one that can go 35-144 [16:55:07 CET] <azarus> (but I only have a 75Hz monitor) [16:55:15 CET] <Diag> There's your problem [16:55:23 CET] <kepstin> does it actually help with video tho? (i.e. will freesync allow adapting to exact video framerates?) [16:55:30 CET] <Diag> Freesync is the best thing to happen to monitors [16:55:30 CET] <azarus> I don't ever play any FPSs nowadays [16:55:50 CET] <azarus> Neither anything that benefits a lot from it [16:55:50 CET] <Diag> kepstin it will if it's in your monitors range [16:56:10 CET] <kepstin> Diag: alright, do any players support this? (and I assume if so, it's only in fullscreen) [16:56:20 CET] <furq> i should hope it's only in fullscreen [16:56:21 CET] <Diag> Should be anything that uses direct x [16:56:37 CET] <kepstin> huh. might work with mpv then [16:56:59 CET] <Diag> I can try when I get home [16:57:06 CET] <Diag> I haven't done video yet [16:57:07 CET] <kepstin> I'm running a 4k monitor with no freesync, and using linux, so I guess I'll never know ;) [16:57:38 CET] <Diag> After you go freesync you don't go back [16:58:02 CET] <Diag> No tearing. Ever [16:58:14 CET] <Diag> Ultra smooth low latency shit [16:58:42 CET] <kepstin> well, i'm running in wayland, so I don't get tearing. The benefit would just be in the lower latency/reduced judder. [16:58:58 CET] <Diag> Lol [16:59:09 CET] <Diag> It legit makes 40fps in games very playable [16:59:21 CET] <Swervz> I've been thinking of buying an amd gpu for a while but they're just not powerful enough. I already have an overclocked titan xp and Im at the limits of the thing almost already [16:59:34 CET] <Swervz> would be nice to not have to deal with nvidias shit [16:59:41 CET] <Diag> I have a Vega64 under a water block [16:59:48 CET] <azarus> I got a R9 Fury, it does everything and anything I want from it [16:59:58 CET] <Diag> Dead quiet and hauls ass [17:00:10 CET] <Diag> And it's been getting faster and faster with every driver release [17:00:12 CET] <azarus> (but my "want" is probably different from yours) [17:00:22 CET] <Diag> It's consistently ahead of the 1080 now [17:00:27 CET] <Diag> Reaching at the ti [17:00:40 CET] <Diag> There's like 2 games where it stomps the ti [17:00:45 CET] <Swervz> anyone know why I'm getting [h264_nvenc @ 00000000027e1020] EncodePicture failed!: unsupported param (12) with ffmpeg -i "input.mp4" -c:v h264_nvenc -profile high444p -pixel_format yuv444p -preset default -c:a copy "output.mp4" [17:00:47 CET] Action: kepstin has an rx560 and plays games in 1080p on his 4k monitor, so yeah. [17:00:52 CET] <Swervz> Feels like I'm doing something wrong [17:00:53 CET] <Diag> Gross wtf [17:01:04 CET] <Diag> Nvenc [17:01:07 CET] <Diag> There's your problem [17:01:11 CET] <Swervz> what do you feel is wrong with nvenc? [17:01:18 CET] <Diag> It's made by nvidia [17:01:20 CET] <Diag> :v [17:01:21 CET] <kepstin> Swervz: what gpu is that, a 1080? [17:01:25 CET] <Swervz> Titan xp [17:01:42 CET] <kepstin> Swervz: which gpu core/generation is that? [17:01:50 CET] <Swervz> pascal [17:02:04 CET] <kepstin> hmm, should be able to do 4:4:4 then. [17:02:18 CET] <Swervz> it can [17:02:54 CET] <Swervz> Here are the capabilities reported https://i.imgur.com/i3EEPu6.png [17:03:07 CET] <Diag> Nvidia probably broke it in the current driver release [17:03:47 CET] <kepstin> Swervz: can you pastebin the *complete* output? I probably can't help you with it, but maybe someone else will see something. [17:03:59 CET] <Swervz> Sure [17:06:14 CET] <Swervz> Diag, They didn't. It works in every other program. Fanboism is not healthy for competition between companies. I buy and use the products that best suit my use case and I suggest that is what everyone else does budget permitting. Being loyal to a company is pointless because all they really care about is getting your money and keeping their shareholders happy regardless of if its Nvidia or AMD. [17:06:52 CET] <sfan5> >Fanboyism is not healthy for competition between companies [17:07:04 CET] <sfan5> NVIDIA having less marketshare would result in much better competition though [17:08:11 CET] <Swervz> NVIDIA will lose market share as amd products improve just like how intel lost marketshare after ryzen release [17:08:32 CET] <Swervz> kepstin, https://pastebin.com/PW3HKsa2 there you go [17:09:35 CET] <Diag> Amd products are great, albeit slower graphics performance, software is Faaaaaaar Superior, as with business practices as well [17:10:32 CET] <Diag> In fact [17:10:35 CET] <Swervz> What issue do you have with nvidias business practices? I've not been following that. [17:10:43 CET] <Diag> Nvidia has the majority of the fanboys [17:10:55 CET] <Diag> Can you give me like 10 minutes I'm driving to my shop [17:11:53 CET] <Diag> In the meantime [17:12:02 CET] <Diag> Gameworks and mantle [17:12:54 CET] <Swervz> Was mantle not succeeded by vulkan? [17:13:30 CET] <kepstin> Swervz: did you mean to convert that from yuv420p to yuv444p? given the options you have, it looks like it's sending yuv420p video to an encoder set up for yuv444p [17:14:14 CET] <Swervz> Kepstin, I did not realise it was trying to convert it, yeah source is 420 [17:14:27 CET] <kepstin> well, i think the problem is that it's *not* trying to convert it [17:14:48 CET] <kepstin> does it work if you just drop the -pixel_format option and let the encoder use the automatic value? [17:14:51 CET] <Swervz> I guess it would be best to use 444 considering its already undergone one round of chroma subsampling [17:15:10 CET] <Swervz> no I still get the same error if I drop that [17:15:21 CET] <kepstin> the best is to leave it as-is at yuv420p [17:15:33 CET] <sfan5> ffmpeg -i "input.mp4" -c:v h264_nvenc -profile high444p -vf format=yuv444p -preset default -c:a copy -y "output.mp4" works here [17:17:07 CET] <Swervz> hmm that worked but I get a lot of warnings like "Past duration 0.659645 too large" could be because the input is variable frame rate? [17:17:17 CET] <Swervz> encoding at 2715FPS though [17:17:39 CET] <Swervz> vs ~650 on cpu with the verfast preset [17:18:08 CET] <kepstin> Swervz: that error can happen if vfr was misdetected as cfr. Try adding the '-vsync 0' option. [17:18:20 CET] <kepstin> or -vsync 2 [17:18:54 CET] <Swervz> does it matter what order the options are in? [17:18:59 CET] <Swervz> as long as they're after the input [17:19:22 CET] <kepstin> only if you specify the same option twice - then the later one overrides the first [17:20:04 CET] <Swervz> looks like -vsync 0 did the trick, 2 just gives the same warnings [17:21:22 CET] <Swervz> Can I do -vf fps=60 now to output a constant framerate? [17:27:37 CET] <Swervz> ffmpeg -h encoder=h264_nvenc did not list an arg for it but I know it can be specified [17:28:58 CET] <sfan5> input fps is not something the user should set [17:29:09 CET] <sfan5> but you can put the vf there to convert to 60 fps [17:30:22 CET] <Swervz> yeah that's what I wanted to do [17:31:21 CET] <Swervz> this whole thing was just to convert a video to constant framerate so adobe premiere can handle it, I tried converting to different formats including lossless avi with cpu but its just too slow [17:39:33 CET] <kepstin> yeah, the fps video filter should work fine (or, equivalently, the -r output option) [17:41:06 CET] <Swervz> kepstin, Any idea why I'm getting these warnings now? https://pastebin.com/QJMMLvTX [17:41:30 CET] <kepstin> Swervz: don't use the -vysnc option if you're using the fps filter [17:41:38 CET] <Swervz> ah okay [17:41:47 CET] <kepstin> Swervz: also, you're using -vf twice - the second overrides the first [17:42:10 CET] <kepstin> Swervz: to run two filters, you make a single filter chain with both, e.g. "-vf fps=60,format=yuv444p" [17:42:41 CET] <Swervz> ah I think I tried that before, but without the comma and thats why it failed [17:43:15 CET] <kepstin> the , in a filter chain means "take all the outputs from the previous filter and hook them to the inputs of the next filter" [17:43:48 CET] <Swervz> ah okay thankyou [17:43:57 CET] <Swervz> I thought a space was enough to seperate them at first [17:44:42 CET] <Swervz> It works perfectly now! Just have to set my desired bitrate [17:45:25 CET] <Swervz> -rc cbr=50000 [17:45:51 CET] <kepstin> if you're making a temporary file for input to some other tool, you probably want to encode to quality rather than constant bitrate. I dunno if nvenc has a constant quality mode? or even just constant qp? [17:47:40 CET] <Swervz> Yeah this is what it reports back when I do ffmpeg -h encoder=h264_nvenc https://pastebin.com/7BQiV3Hx [17:47:52 CET] <Swervz> Although I assumed a really high CBR would have lost less visual quality [17:47:56 CET] <Swervz> Something like 100Mbps [17:48:02 CET] <furq> doesn't nvenc have a lossless mode [17:48:09 CET] <Swervz> It does iirc [17:48:28 CET] <Swervz> I don't remember how to use it though [17:55:46 CET] <Swervz> furq, oh Its the lossless preset lol, I was looking in bitrate for it [17:56:43 CET] <kepstin> I'd read that output you just pasted and see "oh hey, there's an option -preset lossless" ;) [17:57:13 CET] <Swervz> sometimes I'm just really bad at reading things when there is a ton of text on screen [17:58:18 CET] <Swervz> I thought my gpu was at its limits but it seems my HDD is the bottleneck again haha [17:58:52 CET] <kepstin> with lossless? yeah. [17:59:04 CET] <Swervz> I think I'm either gonna have to buy more ssds or ram and make a ramdisk [17:59:46 CET] <Swervz> I've been needing more ram anyway for a while so maybe nows the time to buy [18:00:32 CET] <sfan5> now is definitely not the time to buy RAM if you've followed the price [18:01:04 CET] <Swervz> Yeah its crazy [18:01:19 CET] <Swervz> I think I paid just under $100 for 16GB ddr4 3200mhz back in 2016 [18:01:50 CET] <Swervz> although I'm being limited by ram almost daily now for other tasks like virtualization so I may just cave and buy some [18:04:00 CET] <Swervz> Here's the final command for anyone who wants it ffmpeg -i "input.mp4" -c:v h264_nvenc -profile high444p -vf fps=60,format=yuv444p -preset lossless -c:a copy -y "output.mp4" [18:51:01 CET] <Guest3479> who can please help me here? https://video.stackexchange.com/questions/23304/ffserver-filemaxsize-what-d… , please son't say that ffserver is not recommended , I know it but I ust this help [18:54:34 CET] <Swervz> Guest3479, It's to set the max size of the feed file in bytes. [18:54:40 CET] <Swervz> you can do 0 for no limit [20:49:04 CET] <dradakovic> What would some common values of -muxrate be, if my parameters for streaming digital radio are -maxrate 256k -minrate 192k -bufsize 256k [21:05:19 CET] <kepstin> dradakovic: you're using mpeg-ts for this? [21:06:16 CET] Action: kepstin isn't really sure that any audio codecs respect maxrate/bufsize either. [21:06:23 CET] <kepstin> i could be wrong about that, tho [21:07:46 CET] <dradakovic> Yes correct. Allow me to post my pastebin [21:08:52 CET] <dradakovic> https://pastebin.com/zksPDDZb [21:09:32 CET] <dradakovic> After lets say 2 hours, the digital radio starts skipping. I was hoping muxrate would somehow solve it [21:09:36 CET] <Diag> uh [21:09:39 CET] <Diag> it aint in english [21:09:49 CET] <dradakovic> Oh yeah those are just comments [21:09:56 CET] <dradakovic> ignore that [21:10:28 CET] <dradakovic> I could remove them for clearer readability [21:11:06 CET] <Diag> what language is that [21:13:16 CET] <dradakovic> Slovenian [21:13:18 CET] <dradakovic> https://pastebin.com/mei9bFZm [21:13:25 CET] <dradakovic> Should be clearer now [21:14:15 CET] <Diag> waaaaaaaaaait a minute, are you running pirate radio [21:14:24 CET] <dradakovic> No, we are an ISP [21:14:29 CET] <Diag> oh what lol [21:14:29 CET] <dradakovic> we have the contract [21:14:51 CET] <dradakovic> It is that we are disabling the analog radio and we are sending their stream as digital [21:14:58 CET] <dradakovic> instead [21:14:58 CET] <kepstin> dradakovic: what is the source? A realtime capture [21:15:02 CET] <dradakovic> Yes [21:15:04 CET] <kepstin> dradakovic: if so, remove the -re [21:15:11 CET] <kepstin> the -re option might be causing the desync [21:15:38 CET] <dradakovic> If i do that, my radio starts to instantly skip. [21:15:47 CET] <dradakovic> At least -re keeps it fine for a while. [21:15:51 CET] <sfan5> hmm that's an interesting way of doing inline comments in bash [21:15:56 CET] <dradakovic> Some radios sooner some later [21:15:58 CET] <sfan5> i've never seen that [21:16:15 CET] <kepstin> The -re option is for use if you have a non-realtime source (e.g. a local file) that you want to stream out in realtime - it makes ffmpeg sleep while reading the file. [21:17:51 CET] <kepstin> if your source is actually realtime, the extra sleeps can cause desync or missing input [21:18:29 CET] <dradakovic> Ok i understand that but if i dont use -re option, the radio is played too fast. As in too many udp packets get sent to the pint that it causes buffer overflow [21:18:52 CET] <kepstin> it should eventually settle down to match the input speed [21:19:17 CET] <kepstin> ffmpeg cli tool isn't really designed for realtime streaming, so :/ [21:19:31 CET] <dradakovic> Ahh :( [21:20:01 CET] <dradakovic> Allow me to show you the graph that we monitor while we broadcast [21:20:04 CET] <dradakovic> give me a min [21:20:05 CET] <kepstin> sounds like your issue is that you want the output packets to be paced, and ffmpeg is outputting them in bursts then gaps? [21:22:52 CET] <sfan5> dradakovic: have you looked into the bitrate option of udp:// ? http://ffmpeg.org/ffmpeg-protocols.html#udp [21:23:14 CET] <sfan5> setting bitrate=256k&burst_bits=256k sounds like it would do exactly what you need [21:23:46 CET] <dradakovic> Hmmm, ok thank you for this. I shall try it right away. Let me just show you my graph with and without the -re option. [21:23:50 CET] <dradakovic> Very cool [21:24:43 CET] <dradakovic> https://imgur.com/a/TESDC [21:25:02 CET] <dradakovic> on the left you see with -re option. THen i stopped the radio and tried it without -re [21:25:10 CET] <dradakovic> Going for bitrate now that sfan5 suggested [21:28:53 CET] <dradakovic> Alright, i added the bitrate as you suggested sfan5. I will also be keeping the -re option because it seems like i have to have it. [21:29:07 CET] <dradakovic> It will take hours before i can confirm this worked [21:29:16 CET] <dradakovic> thank you sfan5 and keepstin so far [21:29:20 CET] <sfan5> if packet rate is limited by udp:// you won't need -re [21:29:43 CET] <sfan5> slightly unrelated, but don't your digital radios support mp3? [21:29:57 CET] <dradakovic> it does. I can convert it to libmp3lame [21:30:06 CET] <dradakovic> It works the same though [21:30:12 CET] <sfan5> the stream you're reading is mp3 already so -c copy would work [21:30:27 CET] <sfan5> asking because mp2 generally results in lower quality [21:30:33 CET] <dradakovic> Ohh no no, that wouldn't work as i said, we are ISP. So this has to be streamed to a cable network [21:30:47 CET] <dradakovic> pretty much cable tv [21:31:05 CET] <sfan5> ah, okay [21:31:21 CET] <kepstin> if the bitrate option works, please do not use -re, the -re option will cause other problems [21:31:22 CET] <dradakovic> Gotta be mp2 or mp4 but mp2 is preferable [21:31:47 CET] <kepstin> in particular, the -re option can cause missing input or buffer problems in input on realtime sources [21:32:27 CET] <dradakovic> You are right. It causes the missing input. [21:36:13 CET] <dodo> who can please help me here? https://video.stackexchange.com/questions/23304/ffserver-filemaxsize-what-d… , please son't say that ffserver is not recommended , I know it but I umst this help [21:36:30 CET] <dodo> Swervz: why do I have temp file to store the stream? [21:36:52 CET] <JEEB> Guest94413: ok. then I will just tell you that nobody here mos likely knows anything about ffserver :D [21:41:13 CET] <derbie_> I know nothing of video/audio compression and streaming. Any good resources for beginners? [21:41:39 CET] <Guest94413> JEEB: witch server can stream over http with ffmpeg ? [21:41:43 CET] <klaxa> wikipedia is a good start most of the time [21:45:24 CET] <derbie_> I'm thinking of making something to: take X sources of videos (youtube, vimeo, MIT, khanacademy, etc.) and serve as one seamless video stream [21:45:59 CET] <derbie_> with the option of specifying different segments and order [21:46:12 CET] <kepstin> derbie_: well, you certainly picked a hard problem to start with. [21:46:26 CET] <derbie_> it should solve some really nasty problem though [21:46:37 CET] <derbie_> drum roll.... [21:46:39 CET] <derbie_> lost time [21:47:06 CET] <derbie_> i want to cut out useless information from lecture videos [21:48:18 CET] <derbie_> kepstin, please elaborate on why it is difficult [21:48:26 CET] <kepstin> honestly, you're gonna spend more time figuring out segment in/out times and setting up the edits than you would just seeking through it in your player :) [21:48:45 CET] <derbie_> kepstin, but you do it once for thousands or more [21:49:08 CET] <Swervz> Is that not what chapters are for [21:49:17 CET] <derbie_> chapters? [21:51:44 CET] <Swervz> https://video.stackexchange.com/questions/18970/how-to-add-chapters-section… [21:53:26 CET] <kepstin> derbie_: if you're doing manual editing anyways, you might want to just get a graphical nle program. This sort of thing can be done with ffmpeg, but it's all kind of a pain to set up commands and scripts. [21:54:17 CET] <Swervz> Imagine if there was a NLE that let you select clips on the timeline and only mux them into the video instead of encoding them [21:54:25 CET] <Swervz> assuming its the same codec [21:54:36 CET] <derbie_> i think the user should aim to mark which content is irrelevant (taking from a few millis to seconds) and cut that out [21:55:02 CET] <derbie_> the mixing of videos is just a step further than what I'm thinking to do [21:56:31 CET] <derbie_> was imagining some kind of mass contribution and version control to make continous and the most comprehensive content about a certain topic [21:57:20 CET] <derbie_> then again i've never edited a video... [22:00:51 CET] <derbie_> maybe voice recognition + transcripts could make it easier to edit stuff out [22:01:38 CET] <kepstin> I assume you've already figured out the hard problems of business model (who's paying?) and copyright status, so I'm not gonna discuss those at all. [22:02:26 CET] <derbie_> open and free [22:02:51 CET] <kepstin> but for something of the scope you're talking about, i'd basically suggest just hiring a few engineers who already know about video to build the system :/ It's very big for a one-person project. [22:03:28 CET] <derbie_> i know some java [22:06:32 CET] <derbie_> at least you said it's possible [22:07:00 CET] <kepstin> well, the hardest part is complying with the appropriate copyright laws and figuring out how to afford it [22:07:05 CET] <kepstin> building it is only the hard part ;) [22:07:58 CET] <kepstin> but if all you really want is to have one person take a few videos on a topic and combine them together into a shorter edited video and repost on youtube or something, the easy way is to just buy a copy of sony vegas or something. [22:08:18 CET] <kepstin> the slightly harder way is to manually note down times and run a bunch of ffmpeg commands to build the final video [22:08:42 CET] <derbie_> ^ [22:10:00 CET] <ssdsd> what is the dffrence between -re before -i or -c:v copy ??? [22:11:40 CET] <derbie_> The following could be cut down to "this example is called regression problem" https://youtu.be/UzxYlbK2c7E?t=39m12s to 39:23 don't know the amount would be saved but i feel it would be from 10s to 3s [22:13:18 CET] <derbie_> Now i'm all excited [22:17:35 CET] <kepstin> ssdsd: '-re' before '-i' tells ffmpeg to slow down reading the file by sleeping so that it doesn't go faster than realtime. [22:17:53 CET] <kepstin> ssdsd: '-re' somewhere else in the command... does nothing, i'm suprised it's not an error [22:18:36 CET] <ssdsd> kepstin: but -re is re-encode the stream/video? [22:18:46 CET] <kepstin> ssdsd: no. [22:19:14 CET] <ssdsd> kepstin: how copy can be faster fps than the original video? [22:19:33 CET] <kepstin> ssdsd: ffmpeg re-encodes the video by default, unless you explicitly tell it to copy [22:20:14 CET] <ssdsd> kepstin: unless copy or -re , yes? [22:20:30 CET] <kepstin> no, '-re' doesn't have anything to do with this. [22:22:31 CET] <kepstin> The only thing the '-re' option does is slow down ffmpeg. [22:22:35 CET] <ssdsd> kepstin: I not get you , before I ask you if I put -re the ffmpeg re-encode the video and you tell me , no [22:23:00 CET] <kepstin> ssdsd: the "-re" option does not mean "re-encode". It does not make ffmpeg re-encode the video. [22:23:12 CET] <kepstin> ssdsd: ffmpeg will re-encode the video unless you use -c copy. [22:24:15 CET] <ssdsd> so if I dont want that my video re-encode and I dont want to read the video faster than original video fps I need to put ffmpeg -re -c:v copy -i myVideo.avi ..... [22:24:33 CET] <bindi> rtl_fm -g15 -f 98.0M -M wbfm -E deemp | ffmpeg -f s16le -ac 1 -i pipe:0 -acodec libmp3lame -ab 128k -f rtp rtp://192.168.1.123:1234 [22:25:01 CET] <bindi> trying to play rtp://192.168.1.123:1234 on another PC (.123 is the IP of the machine i'm running ffmpeg on), vlc to be specific, yields an error [22:25:13 CET] <kepstin> ssdsd: Why would you do that? It will just make ffmpeg take a long time to run. [22:25:31 CET] <kepstin> ssdsd: Are you streaming video? [22:25:40 CET] <ssdsd> yes i am [22:25:50 CET] <ssdsd> kepstin: copy or -re , what takes lot of time ? [22:25:59 CET] <bindi> https://hastebin.com/nejebusaji.tex here's the debug log from vlc [22:26:29 CET] <kepstin> ssdsd: You didn't explain your original question very well. [22:27:08 CET] <kepstin> ssdsd: If you have a local file on the hard drive, and you're streaming the output, then you should use the "-re" option (before "-i") to make the video play back in realtime [22:27:42 CET] <kepstin> ssdsd: You can also use -c copy so that the video doesn't get re-encoded. THis means the command will use less CPU, and the quality will not change. [22:27:56 CET] <ssdsd> kepstin: greate! [22:28:55 CET] <ssdsd> kepstin: witch format is better to save mjpeg stream to file on my disk , that takes less cpu and save on quality? avi? [22:30:38 CET] <kepstin> ssdsd: if you have lots of hard drive space, use "-c copy" and save to whatever container you like, mkv or avi should work. [22:31:09 CET] <ssdsd> kepstin: have you ever stream video? [22:31:57 CET] <ssdsd> kepstin: why I must use -re when I takes video from my disk and not when I takes video from live stream? why ffmpeg read video from my disk with larger fps ? [22:32:27 CET] <kepstin> ssdsd: because your hard drive is fast, so ffmpeg can read the file really fast. [22:32:56 CET] <kepstin> ssdsd: when you read from a live stream, the video can only be read by ffmpeg as fast as the live stream sends it out. [22:34:15 CET] <ssdsd> kepstin: can I takes the video file on my disk that I want to stream it and upload to my ram, that will be faster ? on ubuntu ? [22:35:54 CET] <kepstin> ssdsd: if you're using -re, there's no point... [22:36:13 CET] <ssdsd> kepstin: last quastion please , do you ever use ffserver? [22:36:27 CET] <kepstin> ssdsd: nope. [22:36:40 CET] <ssdsd> kepstin: do you ever stream video? [22:36:57 CET] <Swervz> That guy in here earlier who was using IRC and driving and said he would be back in 10 minutes never came back... [22:37:05 CET] <kepstin> i work on software that includes streaming video features, yeah [22:37:24 CET] <ssdsd> kepstin: witch server do you use to stream video? [22:37:33 CET] <ssdsd> and witch protocols is support ? [22:37:59 CET] <kepstin> for non-realtime stuff i just encode mp4 files and put it on http server. [22:38:28 CET] <kepstin> my realtime stuff is all legacy flash (rtmp) using a customized red5 server, although we're also starting to do some webrtc with kurento iirc. [22:39:16 CET] <ssdsd> kepstin: "for non-realtime stuff i just encode mp4 files and put it on http server." stream it via mjpeg protocols? [22:39:20 CET] <kepstin> for most people, i'd probably recommend nginx-rtmp nowadays for live stuff. (it can do hls, dash i think) [22:39:38 CET] <kepstin> ssdsd: no, just http. No mjpeg anywhere. [22:39:48 CET] <kepstin> h264+aac in mp4 file [22:41:51 CET] <kepstin> mjpeg is a terrible streaming format, since it doesn't compress very well. [22:48:11 CET] <Swervz> Is there anything like the NGU sharp doubling in madVR for ffmpeg? [22:48:39 CET] <Swervz> It can make some videos look so much better [22:50:10 CET] <Swervz> Mainly intro videos from old PS1 and PS2 games, the upscaling helps immensely [22:50:55 CET] <kepstin> Swervz: probably not. I think most madVR stuff is gpu shaders? So someone would have to port it to C for ffmpeg, and it'll be a lot slower [22:51:06 CET] <kepstin> (or run it in opencl or something, i dunno) [22:51:35 CET] <Swervz> I was thinking of something you can run offline and have it put out an upscaled video [22:52:38 CET] <Swervz> The best way I can think of right now is playing it in MPC-HC and then recording it with OBS, the quality loss from re recording it is much lower than the gains you get from the shaders [22:53:59 CET] <Swervz> I guess you'd be transcoding it anyway with FFMPEG [23:18:20 CET] <ovidiu> hello [23:18:38 CET] <ovidiu> I would like to concatenate multiple jpeg files into a video [23:18:48 CET] <ovidiu> and I used this example [23:18:49 CET] <ovidiu> http://hamelot.io/visualization/using-ffmpeg-to-convert-a-set-of-images-int… [23:19:45 CET] <ovidiu> in my case the command is: ffmpeg -r 16 -f image2 -s 640x480 -i /home/frames/0/%s-video.jpg -vcodec libx264 -crf 25 -pix_fmt yuv420p /home/videos/tl_camera-0.ogv [23:19:56 CET] <ovidiu> but i've got an error [23:20:06 CET] <klaxa> i don't think ogv can mux h264 [23:20:09 CET] <klaxa> or can it? [23:20:14 CET] <klaxa> replace ogv by mkv or mp4 [23:20:18 CET] <ovidiu> : /home/frames/0/%s-video.jpg: Is a directory [23:20:40 CET] <klaxa> what are your files called? [23:20:43 CET] <ovidiu> but.. i intended to specify *-video.jpg [23:21:18 CET] <ovidiu> the following regexp pattern applies: /CAM([0-9]+)__([0-9]{2})_([0-9]{2})_([0-9]{4})_([0-9]{2})_([0-9]{2})_([0-9]{2})-video.jpg/ [23:22:05 CET] <ovidiu> do I have to use %0{n}d instead of ([0-9]{n}) ? [23:22:18 CET] <klaxa> *something something glob* alternatively: cat /home/frames/0/*-video.jpg | ffmpeg -f image2pipe -r 16 -s 640x480 -i - -c:v libx264 -crf 25 -pix_fmt yuv420p /home/videos/output.mkv [23:25:20 CET] <ovidiu> cat ? [23:25:37 CET] <ovidiu> will ffmpeg know to get pictures from stdin? [23:27:29 CET] <DHE> well you give it a hint by telling it the type is image2pipe [23:29:08 CET] <klaxa> i think -s 640x480 is also either at the wrong place or unneeded [23:29:28 CET] <mkdir_> Hi [23:29:52 CET] <mkdir_> any good places to get .wav files of english words? [23:31:54 CET] <ovidiu> @DHE thanks a lot [23:32:00 CET] <ovidiu> it works fine [23:32:17 CET] <ovidiu> what codec can I use to generate ogv and webm? [23:40:15 CET] <klaxa> for webm you can use vp8 [23:40:32 CET] <ovidiu> libvpx ? [23:41:13 CET] <ovidiu> is libtheora available also in ffmpeg? [23:41:52 CET] <klaxa> yes [23:42:01 CET] <klaxa> i think that'sthe only codec availble for ogv? [23:42:10 CET] <klaxa> no idea tbh [23:42:33 CET] <klaxa> also yes, libvpx-vp8 is the encoder (according to ffmpeg -codecs anyways) [23:46:39 CET] <TD-Linux> by default ffmpeg will write vp9 into webm (which I recommend) [23:47:05 CET] <klaxa> ok [23:47:14 CET] <klaxa> is the encoder "fast" now? [23:48:28 CET] <sfan5> libvpx is still terribly slow [23:52:06 CET] <TD-Linux> I would generally recommend choosing a faster encoder speed over vp8, unless you're in a big hurry. [23:53:03 CET] <utack> at least row-mt should work now, thanks to the new libvpx 1.7 from a few days ago [00:00:00 CET] --- Tue Jan 30 2018

1 0

ffmpeg-devel.log.20180128
by burek 29 Jan '18

29 Jan '18

[00:00:00 CET] <CoreX> :/ [00:30:25 CET] <kierank> durandal_1707: what os and compiler? [02:02:12 CET] <kierank> is there a guide to building ffmpeg with tsan [03:07:17 CET] <kierank> michaelni: are you aware mpeg4video is full of tsan errors [03:14:39 CET] <michaelni> are they real errors (outside tsan) ? its a while since i looked at tsan and i had the feeling long ago that it was alot of not really bugs but maybe i was mistaken [03:14:54 CET] <kierank> according to durandal_1707 with my patch yes [03:15:00 CET] <kierank> but i can't reproduce to tsan is all i got [03:15:02 CET] <kierank> carl also saw errors [03:17:19 CET] <durandal_1707> kierank: ubuntu, gcc [03:17:46 CET] <kierank> i can see lots of errors now but no crash [03:17:50 CET] <kierank> on ubuntu 16.04 [03:17:54 CET] <kierank> lots of tsan errors [03:21:30 CET] <kierank> some seem related to 10-bit dct [03:21:43 CET] <kierank> but some happen with normal mpeg4 [03:23:20 CET] <durandal_1707> its trigered with error resilence for some reason [03:24:15 CET] <kierank> probably ER doesn't understand 10-bit [03:24:37 CET] <durandal_1707> doesnt happen always when starting ffplay, mpv [03:25:42 CET] <durandal_1707> it should happen always or never... [03:26:03 CET] <kierank> probably because s->block32 is an array [03:26:09 CET] <kierank> whereas it perhaps expects a pointer [03:26:48 CET] <durandal_1707> kierank: try corrupting bitstream with bsf to trigger er [03:26:57 CET] <kierank> I can see the error in tsan [03:27:02 CET] <wm4> (is there such a bsf) [03:27:30 CET] <durandal_1707> yes, there is [03:30:18 CET] <durandal_1707> noise bitstream filter [03:30:52 CET] <wm4> (is that useful over a fuzzer?) [08:33:16 CET] <vrd> Hello! Vishal here, I wanted to take up the super resolution task , if no one's already doing it.If somebody has already done it,please let me know! Thanks. [11:29:30 CET] <kaushik_> hi can anyone help me with the "Add a filter which performs a convolution of two images." qualifying task. [11:29:54 CET] <kaushik_> Where should I start to gain some background knowledge? [12:35:10 CET] <BtbN> philipl, is it only me, or shouldn't the code that unmaps the input resource also unregister it? Unregister is currently only called when re-assigning an unmapped registered_frame [13:14:22 CET] <cone-706> ffmpeg 03Timo Rothenpieler 07master:bbe1b21022e4: avcodec/nvenc: refcount input frame mappings [13:14:22 CET] <cone-706> ffmpeg 03Timo Rothenpieler 07master:32bc4e77f61a: avcodec/nvenc: unregister input resource when unmapping [13:14:22 CET] <cone-706> ffmpeg 03Timo Rothenpieler 07master:48e52e4edd12: avcodec/nvenc: add some more error case checks [13:14:22 CET] <cone-706> ffmpeg 03Timo Rothenpieler 07master:932037c6bb6b: avcodec/nvenc: also clear data pointer after unregistering a resource [13:38:54 CET] <cone-706> ffmpeg 03Timo Rothenpieler 07release/3.4:fbb27e291183: avcodec/nvenc: refcount input frame mappings [13:38:55 CET] <cone-706> ffmpeg 03Timo Rothenpieler 07release/3.4:a7c60c5b7bc5: avcodec/nvenc: unregister input resource when unmapping [13:38:56 CET] <cone-706> ffmpeg 03Timo Rothenpieler 07release/3.4:d36714f72702: avcodec/nvenc: add some more error case checks [13:38:57 CET] <cone-706> ffmpeg 03Timo Rothenpieler 07release/3.4:93c8720b914e: avcodec/nvenc: also clear data pointer after unregistering a resource [14:00:40 CET] <kierank> durandal_1707: ping [14:01:36 CET] <durandal_1707> kierank: pong [14:01:46 CET] <kierank> durandal_1707: can you test new patch please [14:01:54 CET] <kierank> it's on ml [14:02:07 CET] <kierank> dunno about segfault but it should fix thread problems [14:07:18 CET] <durandal_1707> kierank: its worse, now also ffmpeg segv [14:07:35 CET] <kierank> huh, works for me [14:09:39 CET] <cone-706> ffmpeg 03Timo Rothenpieler 07release/3.3:802ebfae3b5b: avcodec/nvenc: refcount input frame mappings [14:09:40 CET] <cone-706> ffmpeg 03Timo Rothenpieler 07release/3.3:4bb40c32ee09: avcodec/nvenc: unregister input resource when unmapping [14:09:41 CET] <cone-706> ffmpeg 03Timo Rothenpieler 07release/3.3:d68d537f0a78: avcodec/nvenc: add some more error case checks [14:09:42 CET] <cone-706> ffmpeg 03Timo Rothenpieler 07release/3.3:dfd2f4ee265e: avcodec/nvenc: also clear data pointer after unregistering a resource [14:09:43 CET] <cone-706> ffmpeg 03Timo Rothenpieler 07release/3.3:09419de21620: configure: add support for libnpp* from cuda sdk 9 [14:10:10 CET] <durandal_1707> kierank: im on 64bit [14:11:20 CET] <durandal_1707> perhaps you need to resend idct patch [14:15:05 CET] <kierank> durandal_1707: so am I but in vm [14:15:37 CET] <kierank> durandal_1707: can you send bt? [14:17:56 CET] <durandal_1707> kierank: http://pastebin.com/gB2Gru3e [14:18:29 CET] <kierank> durandal_1707: which file? [14:19:20 CET] <durandal_1707> sr lite [14:45:00 CET] <kierank> durandal_1707: weird, so recompiling without tsan shows the issue [14:52:13 CET] <kierank> ah fixed [15:11:41 CET] <kierank> durandal_1707: thanks [15:13:38 CET] <cone-706> ffmpeg 03Michael Niedermayer 07master:3f621455d62e: avfilter/vf_transpose: Fix regression with packed pixel formats [15:13:39 CET] <cone-706> ffmpeg 03Michael Niedermayer 07master:293f24b42c5d: fate: test the transpose filter more fully [15:43:28 CET] <durandal_1707> kierank: where is patch? [15:43:41 CET] <kierank> trying to fix cutting segfault first [15:43:52 CET] <durandal_1707> ok [15:44:55 CET] <kierank> it's all unchecked bitstream reads [15:45:16 CET] <kierank> i can turn it off but ricers won't like that [16:26:13 CET] <philipl> BtbN: So, I don't know about nvenc, but with nvdec interop, you keep the frame registered as long as you care about it, but you only map it to get a pointer and then immediately unmap it. [16:26:54 CET] <philipl> Looks like you fixed whatever the problem was :-) [18:00:31 CET] <kierank> michaelni: so can you explain all this padding heuristics stuff? [18:01:21 CET] <kierank> why does decode_mb need to return < 0? [18:02:03 CET] <kierank> the crash is actually in your av_log message [18:08:26 CET] <durandal_1707> kierank: er still trigers random crash with ffplay/mpv [18:10:08 CET] <kierank> durandal_1707: same backtrace? [18:10:58 CET] <kierank> michaelni: imo the bug is in existing mpeg4video code [18:12:03 CET] <kierank> you do show_bits(&s->gb, 24) without checking you can read 24 bits [18:12:04 CET] <michaelni> decode_mb needs to return errors in case of errors / end otherwise it would continue and corrupt the next slice, waste cpu, potentially crash with overread [18:12:22 CET] <michaelni> kierank, how can i reprodeuce with existing code ? [18:13:12 CET] <durandal_1707> kierank: yes, same bt [18:13:16 CET] <kierank> the problem is I return SLICE_OK [18:13:25 CET] <kierank> but perhaps I need to return SLICE_END? [18:13:33 CET] <kierank> who knows what these things mean? [18:14:41 CET] <kierank> durandal_1707: but works in ffmpeg? [18:14:47 CET] <kierank> imo this is all existing tsan bugs [18:15:35 CET] <durandal_1707> yes, ffmpeg doesnt trigger er, it appears [18:17:48 CET] <kierank> michaelni: you know at some point someone is going to send a field coded sample [18:18:03 CET] <kierank> and then I will have to unwind the hacks upon hacks in the mpeg4video/h263 codebase [18:20:30 CET] <kierank> the segfault happens because I return SLICE_OK and so i fall through all the s->padding_bug_score categories [18:20:33 CET] <kierank> whatever those hacks do [18:20:58 CET] <michaelni> mpeg2 already supports field coded pictures with the mpegvideo framework. [18:22:11 CET] <kierank> can you explain to me the difference between SLICE_OK and SLICE_END [18:22:20 CET] <kierank> and why one falls through and one doesnt? [18:25:28 CET] <durandal_1707> are there alternative mpeg4 decoders? [18:26:23 CET] <michaelni> its long ago but IIRC SLICE_END means the slice end has been found, SLICE_OK means all fine and there is more data in this slice [18:28:53 CET] <michaelni> looking at the code it looks like it reads the startcode of the next slice not just checks if its there. [18:29:54 CET] <kierank> michaelni: what does? [18:31:22 CET] <michaelni> maybe i misunderstood next_start_code_studio() [18:32:27 CET] <kierank> that's exactly how it says to do it in the spec (because studio allows all sorts of what I guess are predecessors to SEIs) [18:36:22 CET] <kierank> durandal_1707: can you provide tsan for ffplay or mpv please [18:36:38 CET] <michaelni> theres also a check_marker in mpeg4_decode_studio_block() that doesnt have its return code checked [18:37:29 CET] <michaelni> also group is used as array index before being checked <ß [18:37:37 CET] <michaelni> <0 [18:37:59 CET] <kierank> michaelni: fixed that one locally [18:38:21 CET] <kierank> actually fixed in latest patchset [18:38:27 CET] <kierank> check_marker isn't checked anywhere in the code [18:38:37 CET] <kierank> but I can't do dpcm (yet) so I bail out anyway [18:39:32 CET] <michaelni> the markers check_marker checks are bits in long runs of potential zeros, not checking them can get the code probably deeper over the end [18:41:06 CET] <kierank> i'd still bail out nonetheless [18:41:18 CET] <kierank> the problem is as i said you read 24 bits without checking you have 24 bits available [18:41:54 CET] <kierank> and that may have worked in the past because of all this padding heuristics [18:42:58 CET] <michaelni> AV_INPUT_BUFFER_PADDING_SIZE requires 64 bytes over the end, thats 512 bits, for the 24 bits read to be too far and over that the code would have to be quite a bit over it before already [18:44:46 CET] <michaelni> mpeg4 shouldnt need any tricks at all to not overread, mpeg4 doesnt allow start code emulation in the bitstream so a valid bitstream cannot contain long runs of 0. the padding is all 0 so it cannot be a valid bitstream and checkibg the stream for validity should catch this before the end [18:47:13 CET] <kierank> https://0x0.st/sbZn.mxf [18:47:33 CET] <kierank> that's the same, it's a cut version of one of the samples [18:47:35 CET] <kierank> sample* [18:49:05 CET] <kierank> michaelni: is there an assumption in the code that a slice is horizontal? [18:49:17 CET] <kierank> one row of MBs perhaps [18:49:26 CET] <michaelni> not for mpeg4 [18:52:02 CET] <kierank> this is something to do with ff_h263_resync perhaps [18:52:36 CET] <kierank> seems i read some uninitialised stack memory [18:56:31 CET] <Gusar_> Delf: there's a --hwdec=crystalhd in mpv, so theoretically it works... but can you actually buy the thing anywhere anymore? [18:56:34 CET] <Gusar_> oops [18:58:39 CET] <kierank> michaelni: what is the purpose of ff_h263_resync [18:58:48 CET] <kierank> to get to the beginning of a slice? [19:00:15 CET] <kierank> studio doesn't have resync markers like normal mpeg4 [19:18:08 CET] <kierank> durandal_1707: possibly fixed your issue, but the segfaults i dunno, mpeg4video/h263 code is impossible to understand [19:25:56 CET] <cone-116> ffmpeg 03Marton Balint 07master:5bf774a4a448: avfilter/vf_framerate: unify luma and chroma blending [19:25:56 CET] <cone-116> ffmpeg 03Marton Balint 07master:1b6ffe9aca1b: avfilter/vf_framerate: factorize blend functions and unify filter_slice [19:25:56 CET] <cone-116> ffmpeg 03Marton Balint 07master:2cbe6bac0337: avfilter/vf_framerate: change blend factor precision [19:25:56 CET] <cone-116> ffmpeg 03Marton Balint 07master:4d95c6d5d7d8: avfilter/vf_framerate: add SIMD functions for frame blending [19:35:59 CET] <michaelni> ff_h263_resync() finds the next slice (video packet header / gob header) [19:53:07 CET] <kierank> durandal_1707: can you test new patch that i just posted [19:56:20 CET] <durandal_1707> will do [19:57:30 CET] <kierank> durandal_1707: thanks, i am starting to give up being able to fixing the fuzz crashes [19:59:19 CET] <durandal_1707> why? [19:59:40 CET] <kierank> mpeg4video/ER code is impenetrable [20:00:24 CET] <atomnuker> can't you just disble ER? [20:01:43 CET] <kierank> dunno, it's quite tied into mpeg4video/mpegvideo [20:08:20 CET] <durandal_1707> kierank: issue is fixed \Ë/ [20:08:54 CET] <kierank> !!! [20:23:01 CET] <cone-116> ffmpeg 03Martin Vignali 07master:3a230ce5fa10: avfilter/x86/vf_blend : avfilter/x86/vf_blend : add AVX2 version for each func except divide [20:25:00 CET] <cone-116> ffmpeg 03Martin Vignali 07master:8f9c38b19629: avcodec/utvideoenc : add SIMD (avx) for sub_left_prediction [20:25:01 CET] <cone-116> ffmpeg 03Martin Vignali 07master:78b982d3b9f1: checkasm : add test for losslessvideoencdsp for diff bytes and sub_left_pred [20:29:31 CET] <kierank> michaelni: so I understand correctly, should error_resilience report MV errors on an intra video? [20:31:43 CET] <kierank> some kind of "special" MVs for error resilience? [21:06:48 CET] <michaelni> possibly it does print a non zero mv error number. Shouldnt really matter. [21:11:28 CET] <jamrial> jkqxz: can you reproduce the above ticket? [21:11:51 CET] <jamrial> also, wonder if the amd guys even look at trac for amf issues [21:12:25 CET] <jamrial> assuming it's amf and not d3d11 in general [21:17:05 CET] <kierank> michaelni: it changes the idct codepaths which are not 10-bit [21:17:24 CET] <kierank> it tries to do mc [21:26:29 CET] <jkqxz> jamrial: I don't have D3D11 input to AMF working at all. [21:26:56 CET] <jamrial> it doesn't work for you? what system? [21:27:26 CET] <jkqxz> Windows 7. No Windows 10 system I can put a graphics card in. [21:27:44 CET] <jamrial> ah, yeah, d3d11va is win8 minimum i think [21:28:10 CET] <jkqxz> D3D11VA does work fine, it's just AMF says no when trying to give it the D3D11 frames. [21:28:42 CET] <jamrial> can you try nvenc or some other encoder that accepts d3d11 frames? [21:29:01 CET] <jamrial> to know if the issue is amf, or d3d11 hwaccel with d3d11 format output [21:30:25 CET] <jkqxz> Can't try Nvidia. libmfx does kindof work with D3D11 input, but the array texture problems are still there (though that should be fixed soon). [21:30:48 CET] <jkqxz> OpenCL input to AMF did work for me, but apparently that's doing a secret download/upload so probably isn't representative. [21:35:03 CET] <BtbN> I remember the AMD guy mentioning d3d11 only working on Win8.1+ due to new APIs [21:38:02 CET] <jkqxz> Yeah, I didn't mind that in review once it was clear that was the problem. It does mean I didn't test that part at all, though. [21:47:59 CET] <jkqxz> jamrial: Presumably it doesn't happen if you "... -hwaccel d3d11 -hwaccel_output_format d3d11 -i ... -vf 'hwdownload,format=nv12' ..."? [21:48:21 CET] <jkqxz> I think you should probably just email the AMD guy. [21:57:37 CET] <jamrial> jkqxz: doesn't happen. same good output as doing -hwaccel d3d11 -hwaccel_output_format nv12 [22:15:33 CET] <michaelni> kierank, "mc" (rather copyying from last frame) makes sense for ER even with intra only. The last frame may be the best source of picture content available [22:56:53 CET] <BtbN> is -hwaccel cuda really a thing? oO [22:56:56 CET] <BtbN> Never heard of that. [23:04:17 CET] <kierank> michaelni: why does it involve calling dct outside out of the mb_intra branch [23:07:18 CET] <jkqxz> BtbN: It's a slightly silly consequence of the names coming from the hwcontext devices there. (The "nvdec" name only works because of <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=fftools/ffmpeg_opt.c;h=92199…>.) [23:07:34 CET] <michaelni> maybe block_last_index is set >= 0, that would make the code belive there are non zero coeffs that need idct [23:18:49 CET] <wm4> jkqxz: haha I have the same thing in mpv [23:19:26 CET] <wm4> that's the only name fudging left though, so not sure if anything needs to be done about it [23:19:36 CET] <BtbN> wasn't the -hwaccel thing a hardcoded list in ffmpeg.c? [23:26:40 CET] <cone-116> ffmpeg 03Marton Balint 07master:dc5d1515681b: avformat/hlsenc: use av_bprintf without buffer limit in replace_int_data_in_filename [23:26:41 CET] <cone-116> ffmpeg 03Marton Balint 07master:ea3672b7d67c: avformat: add url field to AVFormatContext [23:26:42 CET] <cone-116> ffmpeg 03Marton Balint 07master:25a2d269bdd9: fftools, tools, examples: migrate to AVFormatContext->url [23:26:43 CET] <cone-116> ffmpeg 03Marton Balint 07master:4bb04098204a: avdevice: migrate to AVFormatContext->url [23:26:44 CET] <cone-116> ffmpeg 03Marton Balint 07master:45ec2e44be91: avformat/hls: migrate to AVFormatContext->url [23:26:45 CET] <cone-116> ffmpeg 03Marton Balint 07master:18ac64235939: avformat: migrate to AVFormatContext->url [23:26:46 CET] <cone-116> ffmpeg 03Marton Balint 07master:fa8308d3d4f2: avformat: deprecate AVFormatContext filename field [23:29:46 CET] <wm4> BtbN: I think that's completely removed now [23:29:51 CET] <wm4> (and in mpv too) [00:00:00 CET] --- Mon Jan 29 2018

1 0

ffmpeg.log.20180128
by burek 29 Jan '18

29 Jan '18

[00:52:34 CET] <jasom> Is it possible to resize picture (DVD) subtitles? I'm resizing the video and I'd rather not burn them in or convert to text, but I'll do that if I have to. [00:55:11 CET] <JEEB> I'm not sure if rescaling or just leaving them as-is and hoping the players do things so that it matches is better [00:55:37 CET] <JEEB> in theory you can get the output of the DVB/DVD/blu-ray subpictures as a video track and scale it [00:55:49 CET] <JEEB> and then for DVB and DVD I think we have an encoder? [00:55:56 CET] <JEEB> so in theory you could re-code it [00:56:17 CET] <JEEB> but in practice I would probably just remux and see how players reflect the difference in size between canvas and video [00:56:27 CET] <JEEB> ugh, *canvas and subpicture [00:59:06 CET] <jasom> JEEB: vlc seems to scale, mpv does not [03:14:22 CET] <dradakovic> Any clue why my FFMPEG timestamp is faster than it should be? Seconds are going too fast if i check the time played [03:15:53 CET] <dradakovic> I can see in log file that i get cur_dts is invalid (this is harmless if it occurs once at the start per stream) [03:15:53 CET] <dradakovic> . [04:05:26 CET] <DHE> I request op assistance in the channel for the obvious problem [04:46:00 CET] <CoreX> petecouture fix your shit [05:55:47 CET] <FishPencil> Does -threads 1 disable filter slice threading [05:58:33 CET] <furq> FishPencil: -filter_threads [06:09:31 CET] <Dalboz989> hi - i am seeing something odd when I use stream_loop - anyone around want to take a stab at it? [06:17:16 CET] <Dalboz989> so video is like 10 seconds long but when i add stream_loop to the same command it is takes over 3 minutes.. https://pastebin.com/PetKKzT1 [06:29:04 CET] <kazuma_> why not just cat the video stream over and over if you are not encoding [06:30:22 CET] <Dalboz989> hrm.. do you mean like cat out.mp4 out.mp4 out.mp4 | ffmpeg -y -an -i - -c copy junk.mp4 ???? [06:33:21 CET] <furq> presumably not because that's not a thing [06:33:54 CET] <furq> there are a bunch of different ways to do this though [06:34:36 CET] <Dalboz989> ultimately i want infinite loop but was just testing with 3 [06:34:53 CET] <furq> oh nvm you want to stream copy [06:35:05 CET] <furq> if you want an infinite loop then you're pretty much stuck with stream_loop [06:36:16 CET] <Dalboz989> well if i could loop say 10 times that would probably work - any suggestion how i can do 10 times? or a suggestion on what is up with stream_loop ? [06:36:37 CET] <furq> https://trac.ffmpeg.org/ticket/6121#comment:5 [06:36:39 CET] <furq> try that i guess [06:40:20 CET] <Dalboz989> so change output from mp4 to mkv and you think it will work? [06:40:28 CET] <Dalboz989> or rather the input file [07:04:25 CET] <Dalboz989> so i converted the mp4 to mkv and tried the same thing but no difference [09:55:32 CET] <killown> hey there :) I am trying to set watermark with this code https://bpaste.net/show/be8facee8c95 in manjaro updated works but in ubuntu 16.04 it gives error and the out.mp4 is empity [09:55:38 CET] <killown> can anyone help me? [09:58:57 CET] <killown> I just updated for newest ffmpeg and worked [10:01:25 CET] <killown> is there someway to add watermark only in the first 2 minutes of the video? [10:14:03 CET] <killown> overlay=enable='lte(t,30)' doesnt work [libvorbis @ 0x55e7d725fc00] 39 frames left in the queue on closing [10:18:58 CET] <durandal_1707> 2 minutes have 120 seconds [10:42:47 CET] <killown> ok [10:43:03 CET] <killown> can you help me create a watermark with text transparency? [12:51:50 CET] <wasperen> hi all [12:52:07 CET] <wasperen> hopefully someone here can help me... [12:52:27 CET] <wasperen> I am building ffmpeg with support for zvbi_teletext [12:52:54 CET] <wasperen> I am building version 3.4.1 with the --enable7libzvbi flag [12:53:36 CET] <wasperen> it compiles ok but the dvb_teletext decoder / encoder is not included in the list of codecs... [12:55:12 CET] <wasperen> I have trawled the internet but to no avail... [12:55:29 CET] <hojuruku> ffmpeg h264_vaapi assumes vaapi can do high profile. AMD Polaris GPU's don't do b-frames so we need to be able to tweak / patch ffmpeg to use base profile etc [12:56:18 CET] <hojuruku> i think openmax at least works a little better, i'll do some tests now [12:56:33 CET] <JEEB> wasperen: 1) does it pop up in your configure output? 2) are you sure you are testing with the thing that you actually built? [12:57:01 CET] <hojuruku> i mean gst-openmax. ffmpeg openmax stable doesn't support libomxil-bellago yet right? [12:59:38 CET] <JEEB> hojuruku: no need to patch the vaapi h264 encoder to set the profile (although I'm not sure if it does more than just the flag in the headers) - see the AVOptions defined for the encoder [12:59:44 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vaapi_encode_h264… [13:05:58 CET] <jkqxz> hojuruku: There is no "yet" wrt OpenMAX. The specification is too loose to be useful generally, so the ffmpeg wrapper supports only implementations which conform to the Android requirements (those imposed by libstagefright and related stuff, as available on ~all mobile devices). The Mesa stuff is an ad-hoc implementation without those constraints, so it doesn't work. [13:08:09 CET] <hojuruku> openmax was merged first into mesa for amd gallium. i wonder if it does a better job than vaapi. i remember being able to play back the gst created hardware encoded videos, but the ffmpeg ones are unplayable. [13:08:59 CET] <wasperen> JEEB, well this is the thing. It sort of does... [13:09:14 CET] <wasperen> running config again and will copy the output here [13:09:18 CET] <wasperen> (relevant parts) [13:10:37 CET] <wasperen> under "external libraries" it shows libzvbi [13:10:51 CET] <JEEB> ok, that means the thing is enabled and should be built [13:11:04 CET] <JEEB> so now the main thing is to check that you actually tested it to be available [13:11:09 CET] <JEEB> (with the thing you built) [13:11:34 CET] <JEEB> also one simple way to check is to just ffprobe FILE or ffmpeg -i FILE and see if the teletext track is actually noted as teletext [13:11:47 CET] <JEEB> but it should also be in the list [13:11:52 CET] <wasperen> under enables decoders it shows libzvbi_teletext [13:11:58 CET] <JEEB> yes [13:12:02 CET] <JEEB> that much I understood [13:12:13 CET] <wasperen> I have it installed under ~/local/ffmpeg/bin [13:12:25 CET] <wasperen> I'll run the probe [13:13:06 CET] <wasperen> output: Stream #0:2[0x1424](eng,eng): Subtitle: dvb_teletext ([6][0][0][0] / 0x0006) [13:13:17 CET] <wasperen> but also: Unsupported codec with id 94215 for input stream 2 [13:13:24 CET] <wasperen> ok... [13:13:56 CET] <hojuruku> yeah i need to turn of cbac as well for baseline compatibility - but when i run ffmpeg -h encoder=h264_vaapi it says -coder <int> E..V.... Entropy coder type (from 0 to 1) (default cabac) [13:13:56 CET] <hojuruku> cavlc E..V.... [13:13:56 CET] <hojuruku> cabac E..V.... [13:13:56 CET] <hojuruku> vlc E..V.... [13:13:56 CET] <hojuruku> ac E..V.... [13:13:57 CET] <hojuruku> Syntax is no good - choice of zero and one. What is zero and one? [13:14:19 CET] <JEEB> just use the names [13:14:28 CET] <wasperen> and ffmpeg -codecs (the right one!) shows: ..S... dvb_teletext DVB teletext [13:14:34 CET] <hojuruku> i tried that - it gets angry it want a zero or a one. [13:14:41 CET] <JEEB> wasperen: ok, then it is there :P [13:15:09 CET] <wasperen> but... should it now show DES... dvb_teletext? [13:15:34 CET] <JEEB> I know for sure there is no encoder in libavcodec for teletext [13:15:47 CET] <wasperen> what do you mean with "use the names"? [13:15:57 CET] <wasperen> Ok -- but a decoder should be there... [13:16:26 CET] <wasperen> so should it not read ".DS... dvb_teletext"? [13:17:00 CET] <JEEB> hojuruku: it definitely has the named options in the code so either there's a bug or you're doing something wrong [13:17:13 CET] <JEEB> just look at the h264 vaapi encoder code I noted [13:18:00 CET] <JEEB> wasperen: do you have "libzvbi_teletextdec" noted anywhere? [13:20:07 CET] <wasperen> JEEB -- I have "installed" it under ~/local/ffmpeg -- but maybe it still uses the system-provided libavcodecs? [13:20:14 CET] <hojuruku> JEEB: indeed you were right, i needed -coder:v not -coder. [13:20:32 CET] <JEEB> hojuruku: it probably was trying to apply that option to something else then [13:20:37 CET] <wasperen> I have only added a --prefix to the configure [13:20:40 CET] <JEEB> you can have that with the "profile" option as well [13:21:04 CET] <JEEB> wasperen: then it should be static, and not shared. also make sure you cleared your build directory between builds [13:21:41 CET] <JEEB> hojuruku: for example both AAC and AVC encoders usually have the "profile" option and of course the values don't match so you have to specify which encoder you'd be setting the value to [13:23:33 CET] <wasperen> JEEB -- I'll run make clean and build again [13:24:08 CET] <JEEB> that's why i usually build in separate roots [13:24:15 CET] <JEEB> I can just nuke them from the orbit [13:24:21 CET] <JEEB> and recreate the directory and call configure/make from there :P [13:24:47 CET] <hojuruku> jeeb adding "-profile:v baseline -level 3.0" gave [h264_vaapi @ 0x55f7f37bb4e0] [Eval @ 0x7ffc35116d50] Undefined constant or missing '(' in 'baseline' [h264_vaapi @ 0x55f7f37bb4e0] Unable to parse option value "baseline" [13:24:58 CET] <wasperen> It has been a while since I did the good-old configure/make cycle :) [13:25:27 CET] <JEEB> hojuruku: are the quotes on your command line actually like that? [13:25:46 CET] <JEEB> (I usually use backticks or nothing to denote a command line or a part of it) [13:25:56 CET] <wasperen> I'll move the system-provided libavcodec out of the way and see if it uses the newly built ine [13:26:16 CET] <JEEB> unless you used enable-shared the libavcodec should be just fine :P [13:26:17 CET] <hojuruku> nope just to show you the text i added. [13:26:20 CET] <JEEB> since it's always statically linked [13:27:09 CET] <furq> hojuruku: iirc for vaapi you need to use -profile:v 578 [13:27:25 CET] <JEEB> wat [13:27:58 CET] <JEEB> then what are these good for? http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vaapi_encode_h264… [13:28:14 CET] <hojuruku> furq: omg you did it... Stream #0:0(eng): Video: h264 (h264_vaapi) (Constrained Baseline) (H264 / 0x34363248) - ppl complaining about it all over the place online ;) [13:28:25 CET] <furq> oh i guess constrained_baseline will work as well then [13:28:40 CET] <furq> that's dumb considering x264 just uses -profile baseline [13:28:57 CET] <JEEB> technically constrained baseline is more correct, but yes - everyone keeps calling it "baseline" [13:29:01 CET] <furq> yeah [13:29:17 CET] <hojuruku> i'm going to find the ppl complaining ;) [13:29:22 CET] <furq> consistency is more important than technical correctness [13:29:36 CET] <hojuruku> how do you calculate that number furq? [13:29:43 CET] <JEEB> hojuruku: you don't need the number [13:29:46 CET] <JEEB> just look at the link I posted [13:29:51 CET] <furq> https://www.ffmpeg.org/doxygen/trunk/avcodec_8h_source.html#l02866 [13:30:04 CET] <JEEB> there just is no "baseline" defined for vaapi h264 encoder [13:30:15 CET] <JEEB> the list is "constrained_baseline", "main", "high" [13:30:19 CET] <furq> right [13:30:24 CET] <JEEB> which is why "baseline" was not found [13:30:57 CET] <JEEB> anyways, if someoen cares they could add "baseline" as an additional alternative setting the profile to constrained baseline to match libx264 [13:32:20 CET] <furq> https://github.com/FFmpeg/FFmpeg/commit/c490fc9536dcea7fdf1245a340bf0755336… [13:32:23 CET] <furq> i was only two months out of date then [13:32:37 CET] <DHE> x264 only offers a single profile with "baseline" in its name though... [13:32:46 CET] <JEEB> DHE: yeh [13:32:51 CET] <furq> yeah, which is constrained baseline [13:32:55 CET] <JEEB> and that's constrained baseline [13:32:58 CET] <hojuruku> so it would work with -profile:v constrained_baseline [13:33:01 CET] <JEEB> yes [13:33:04 CET] <furq> yeah [13:33:22 CET] <furq> if your ffmpeg is new enough [13:33:28 CET] <DHE> but then there would be no typical/correct "baseline" profile to go with it. [13:33:39 CET] <furq> well neither of those encoders have an actual baseline profile [13:33:48 CET] <furq> and cbp is still technically baseline [13:34:19 CET] <hojuruku> i can't see how you worked out 578 yet in the source [13:34:54 CET] <JEEB> DHE: so yes, technically "baseline" was always a misnomer which was left to be because a) nobody actually used the actual baseline as it was not a subset of main (and thus high) b) constrained baseline is a subset of baseline [13:35:07 CET] <furq> hojuruku: http://codepad.org/Ce65vRBn [13:35:11 CET] <DHE> (a) was going to be my next question. [13:35:11 CET] <JEEB> but yea, we would have to have some sort of consistency [13:35:25 CET] <JEEB> which seems to be hard because different people work on different encoders :P [13:36:23 CET] <furq> does anything actually use the non-constrained baseline features [13:36:49 CET] <furq> it's just transmission robustness stuff isn't it [13:37:10 CET] <JEEB> maybe in the beginning by academic stuff, and possibly some video conferencing stuff? [13:37:20 CET] <furq> likewise with extended profile which i don't think i've ever seen [13:37:22 CET] <JEEB> nothing too general since none of the main implementations implement those features [13:37:37 CET] <JEEB> as in, none of the closed ones either [13:37:47 CET] <furq> yeah i figured maybe some commercial stuff used it [13:38:30 CET] <JEEB> yea, what I was hinting at was some really expensive telco system by cisco or something would possibly use it... for a while, until they found it not too useful :) [13:38:42 CET] <JEEB> after all, I think scalable video coding is also used by some IP telco solutions [13:38:44 CET] <furq> makes sense [13:39:12 CET] <furq> it doesn't sound like there's too much risk of ffmpeg adding support for an encoder where there's a meaningful distinction [13:39:57 CET] <hojuruku> https://en.wikipedia.org/wiki/Context-adaptive_variable-length_coding is that supported in constrained baseline like it is in baseline? [13:40:06 CET] <furq> yes [13:40:19 CET] <JEEB> hojuruku: AVC only has CAVLC and CABAC for coding of symbols [13:40:27 CET] <JEEB> and baseline/constrained baseline don't have CABAC [13:40:42 CET] <JEEB> so you kind of can't remove CAVLC can you :D [13:41:12 CET] <JEEB> or more specifically, something else than CAVLC gets added to be available as a tool /after/ baseline profiles [13:41:26 CET] <hojuruku> so ac and vlc are not supported in constrained baseline only cavlc :P ok [13:41:58 CET] <JEEB> more like they don't exist in H.264/AVC [13:42:11 CET] <JEEB> H.264/AVC only has CAVLC and CABAC [13:42:18 CET] <JEEB> H.265/HEVC only has CABAC [13:42:46 CET] <hojuruku> what'a ac and vlc's full names / and what codes support them? [13:43:07 CET] <hojuruku> ah they are different stages in the pipeline [13:43:53 CET] <JEEB> well all of them are something to compress the final data losslessly [13:44:06 CET] <JEEB> which is why in theory you can take a H.264 stream coded with CAVLC and re-compress it with CABAC [13:45:57 CET] <wasperen> JEEB -- so, moving the system-provided libavcodec.so out of the way breaks the newly built ffmpeg [13:46:16 CET] <wasperen> So it does use the systems one rather than the newly created one [13:46:39 CET] <wasperen> how do you create a new build-root? [13:47:12 CET] <wasperen> or make the linking to libavcodec to the new one rather than the system one? [13:47:33 CET] <hojuruku> what's the maximum bitrate of h264 level in the average 1080p / 720p home television - e.g. a tcl. I'm trying to find out what mine is capable of, what audio codecs it support. It can play mp3 files but not in a matroska for audio. Seems to like DTS audio. [13:47:35 CET] <wasperen> (I'm sure this is basic stuff, sorry for asking stupid questions :)) [13:47:42 CET] <JEEB> wasperen: this works for me just fine :P http://up-cat.net/p/426d9769 [13:47:57 CET] <JEEB> hojuruku: most recent enough hw decoders take level 4.1 [13:49:10 CET] <hojuruku> yeah it slows down at 60fps 1080p ;) [13:49:41 CET] <JEEB> well blu-ray for example goes up to 720p60/1.001 [13:49:56 CET] <JEEB> so some things having issues with 1080p60/1.001 isn't exactly surprising [13:50:28 CET] <JEEB> my default for hwdec support is high/level 4.1. if the decoder doesn't take that, then main/level 4.1 and finally main/level 3.0 [13:50:45 CET] <JEEB> the last one was what the PSP from 2004 supported :P [13:51:36 CET] <hojuruku> constrained_baseline & -level:v 4.1 is valid? [13:52:19 CET] <JEEB> why not? [13:53:30 CET] <hojuruku> great. Now the only other problem is subtitles in the source are not making it through with -scodec copy. The source material plays without sound and subtitles but the destination does not, and it only takes one of the two subtitle channels [13:54:22 CET] <JEEB> if you want all subtitles to be passed with the ffmpeg.c command line tool, you'd have to start mapping streams manually [13:54:51 CET] <JEEB> (as soon as you add one mapping the whole app switches to manual stream selection) [13:55:40 CET] <JEEB> so what you probably want is -map 0:v (maps all video streams from 0th input) -map 0:a:0 (-maps first audio track from 0th input) -map 0:s (maps all subtitle streams from 0th input) [13:56:28 CET] <hojuruku> furq: so it's not possible to use a numeric code for baseline with the amd polaris 21 vce - i have to use "constrained baseline" [13:57:38 CET] <JEEB> you will get a message that non-constrained baseline is not supported by the encoder from the encoder itself [13:57:41 CET] <JEEB> :P [13:58:15 CET] <JEEB> people have just gotten used to calling constrained baseline "baseline" because so few things actually utilize the baseline profile [13:59:15 CET] <JEEB> in case of libx264 it was called just "baseline", and the person who added the options to the VAAPI H.264 encoder decided to be technically correct [13:59:57 CET] <JEEB> of course nobody stops one from adding "baseline" as another value there that maps to the constrained baseline profile [14:00:34 CET] <JEEB> oh wait [14:00:36 CET] <JEEB> haha [14:00:42 CET] <JEEB> the darn code doesn't error there [14:00:50 CET] <JEEB> it just warns you about baseline not being supported [14:00:57 CET] <JEEB> and then sets profile to constrained [14:00:58 CET] <JEEB> :D [14:03:20 CET] <specing> Any idea how to make -ss work with stuff to encode passed on /dev/stdin? [14:03:24 CET] <specing> "/dev/stdin: could not seek to position 89393.261" [14:03:58 CET] <specing> if this is in frames, then it is much different to -ss 00:08:11 [14:04:47 CET] <JEEB> no [14:05:02 CET] <JEEB> it is just trying to seek in the input and since your input is a non-seekable stream it tells you it can't seek [14:05:05 CET] <JEEB> which isn't surprising [14:05:26 CET] <JEEB> -ss isn't "skip this much input", it's "try seeking in this input to this point" [14:05:54 CET] <specing> How do I tell it to skip instead of seek? [14:07:04 CET] <JEEB> no idea :) [14:07:08 CET] <specing> >_> [14:07:40 CET] <JEEB> I mean, with the API it's simple (you keep reading until you get to where you wanted to be), but with ffmpeg.c NFI :) [14:08:13 CET] <specing> ah I think I get it [14:08:19 CET] <specing> "When used as an output option (before an output url), decodes but discards input until the timestamps reach position." [14:08:25 CET] <specing> lets see [14:08:40 CET] <JEEB> right, that at least on some level sounds like it :) [14:09:06 CET] <JEEB> also that seems to decode, too. but I guess you're OK with that? [14:09:50 CET] <specing> better than nothing ;) [14:10:05 CET] <specing> actually I'm using -stream copy, so its more or less a noop [14:10:22 CET] <specing> "-codec copy" [14:10:55 CET] <JEEB> umm [14:11:08 CET] <JEEB> yea, that skips decoding altogether. so not sure how that will work with the -ss that is supposed to decode [14:11:47 CET] <specing> *shrug* [14:17:24 CET] <sine0> I have a dozen podcasts where the best bit starts 45 minutes in, they are in mp3 format, how can i trim to tha part and save [14:18:04 CET] <sine0> -ss [14:18:05 CET] <JEEB> if you have the file around you can just use -ss before the input [14:22:03 CET] <sine0> yay [14:22:06 CET] <sine0> :) [14:23:48 CET] <specing> JEEB: that works, but the seek position is wrong, both at start and at end >_> [14:23:58 CET] <specing> most annoying [14:24:13 CET] <JEEB> rip [14:24:32 CET] <JEEB> which container is it, btw? [14:24:35 CET] <wasperen> JEEB -- thanks for your support! I made it work [14:24:43 CET] <JEEB> wasperen: great :) [14:24:59 CET] <wasperen> (stupid but I flagged the configure --enable-linked) [14:25:13 CET] <wasperen> thanks again [14:25:16 CET] <wasperen> you rock [14:25:28 CET] <JEEB> yea that's why I was trying to stress "are you sure you're testing what you built" [14:25:49 CET] <JEEB> and testing with a static build is probably the simplest way to do that [14:25:53 CET] <JEEB> you can always enable shared later [14:26:27 CET] <wasperen> I'm more a java / scala man -- moving the system-provided lib out of the way and seeing it breaking convinced me [14:28:02 CET] <specing> huh? [14:29:40 CET] <BtbN> So you moved system libs around, and stuff broke, and that's why Java is better? oO [14:30:48 CET] <JEEB> no [14:31:12 CET] <JEEB> he just didn't think too much of the enable-linked too much [14:31:15 CET] <JEEB> :P [14:33:20 CET] <wasperen> exactly -- [14:33:54 CET] <hojuruku> i only get 93fps with rx560's vce (4.14 - i'll try out amdgpu.dc=1 and 4.15 very shortly) doing a h254 transcode from 1080p to 1366x768. [14:33:56 CET] <wasperen> (you don't know how many hours I have spent fixing java classpath issues!) [14:34:36 CET] <BtbN> 93 fps for decoding and encoding hevc sounds decent to me [14:34:52 CET] <BtbN> is this via vaapi? [14:35:07 CET] <specing> wasperen: you don't have those problems if you aren't using java ;p [14:35:26 CET] <JEEB> everything has its own kinks :P [14:35:41 CET] <specing> I have spent a lot of hours getting a working Ada compiler onto Gentoo [14:35:51 CET] <hojuruku> https://github.com/Xaymar/obs-studio_amf-encoder-plugin/wiki/Hardware-VCE3.4 that's what it get's in windows. 111fps - oh that's right for quality - plus the other 20fps is the vaapi resize filter [14:40:59 CET] <hojuruku> vdpau/vaapi supports high quality scaling/resizing on playback in mpv. What's the default in ffmpeg. In mpv it's --vo-vaapi-scaling=<algorithm> fast hq default nla [14:46:35 CET] <hojuruku> BtbN: it's h264 [15:06:47 CET] <hojuruku> intel uses NV12 for the vaapi hardware surfaces, i wonder what amd uses.... [15:07:24 CET] <BtbN> pretty much every hardware uses NV12 [15:07:33 CET] <BtbN> most even in a tiled variant [15:09:14 CET] <hojuruku> that's the internal format, but the hardware (not software conversion) can decode to other formats right? (-hwaccel-output_format) like yuv20p for doing a software encode. Now how do I verify x264 is using the opencl?.... [15:10:04 CET] <hojuruku> amd has got a chip for encode (uvd 3.4 external) and encode (vce on die). I doubt it would get faster if I used the onboard graphics to decode. [15:10:32 CET] <hojuruku> A few years ago intel quick sync video didn't support haswell refresh for h264 encode, but windows did. Have they made it catch up yet? [15:12:56 CET] <BtbN> at least cuvid can output _only_ NV12 and variants of it. [15:13:09 CET] <BtbN> nvenc accepts other formats for convenience, but internally converts them to NV12 [15:17:03 CET] <hojuruku> "BEWARE: if you use the installer script the custom libva would override your system one, you might not want that. " Ah if I get quicksync installed I'll have to only enable it via ld_library_path [15:17:22 CET] <BtbN> you should forget qsv for Linux even exists. [15:17:42 CET] <JEEB> yea [15:17:47 CET] <JEEB> qsv on linux is a major PITA [15:19:31 CET] <hojuruku> https://blogs.gentoo.org/lu_zero/2016/10/31/intel-mediasdk-mini-walkthrough/ [15:19:52 CET] <hojuruku> kernel patches for 4.14 for media sdk.. i wonder [15:20:48 CET] <BtbN> Just give up on it. There is absolutely no reason to waste time on it. [15:20:58 CET] <BtbN> QSV should only be used on Windows, and even there it's a pain. [15:21:17 CET] <hojuruku> yeah i know i used it with handbrake on windows, it was a PITA too. [15:21:44 CET] <hojuruku> but amd rx560 no b frames is a pain me thinks. Will youtube accept a live stream without b-frames? [15:22:02 CET] <BtbN> live streams usually do not have b frames [15:22:08 CET] <BtbN> to avoid reorder-delay [15:22:23 CET] <hojuruku> i'm a gentoo guy, i can make custom ebuilds and put all the quicksync stuff in a custom path - at least userspace. I just hope amd can still use the dri after they have patched the crap out of it [15:22:45 CET] <BtbN> Why tho? [15:22:52 CET] <BtbN> There is zero reason to deal with QSV on Linux. [15:23:15 CET] <hojuruku> it's that bad? [15:23:24 CET] <BtbN> It needs Kernel patches... [15:23:30 CET] <BtbN> And patches to various system libs [15:23:32 CET] <hojuruku> what's the fps at 1080p with H264 encode on intel qsv? [15:23:32 CET] <BtbN> so why bother? [15:23:43 CET] <hojuruku> it only patches the kernel and libva right? [15:23:48 CET] <BtbN> and libdrm [15:24:00 CET] <hojuruku> ouch libdrm, well i already have a custom gentoo build.... [15:24:07 CET] <BtbN> libva encoding just works out of the box [15:24:10 CET] <hojuruku> libdrm git doesn't need to be patched? [15:24:13 CET] <BtbN> so why the hell deal with qsv? [15:25:40 CET] <hojuruku> i had trouble using vaapi on haswell with filters before some bug i can try dig it up [15:27:03 CET] <hojuruku> https://gab.ai/ozzieslovepedos/posts/7802589 ah yes dug it up https://trac.ffmpeg.org/ticket/5532 [15:27:44 CET] <hojuruku> it got fixed i guess. [15:30:34 CET] <hojuruku> https://software.intel.com/en-us/forums/intel-media-sdk/topic/595283 intel saying qsv is faster [15:32:35 CET] <BtbN> it uses the exact same hardware [15:32:41 CET] <hojuruku> yeah i'll stick with just plain vaapi unless i need more performance for my workload for now. [15:32:43 CET] <BtbN> and qsv is just a wrapper on top of libva [15:32:55 CET] <BtbN> so claiming it to be faster makes no sense [15:33:13 CET] <hojuruku> they say the driver patches improve performance [15:33:46 CET] <BtbN> And why won't they just merge them then? [15:33:50 CET] <hojuruku> anyway haswell has no h265 encode so there is no point. i think they have 265 hardware decoding on windows but not linux nevermind moving on. [15:33:59 CET] <hojuruku> yeah i dropped it.... ;) [15:34:13 CET] <JEEB> they have a sw module that is used through the same API on windows I think [15:34:20 CET] <JEEB> since haswell is old enough to not have silicon [15:34:23 CET] <JEEB> as in, a specific chip [15:34:51 CET] <hojuruku> "intel clear video" core on haswell doesn't have the necessary asic to do h265... i got mixed up, i thought there was the h265 hardware encode light at the end of the tunnel. How is AMD going along moving that functionality to linux. [15:35:34 CET] <BtbN> it's exposed via vaapi iirc [15:35:53 CET] <BtbN> But AMDs video encoder is terrible sadly [15:52:06 CET] <hojuruku> humm the hardware tcl tv rejected the video. I'm going to try again with level 3.1 constrained baseline. Maybe it's looking at the level settings in the video header. I don't watch my little pony but i'll leave a usb stick in the tv with it for my daughter [15:52:21 CET] <hojuruku> ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -i rep-mylittleponythemovie.2017.1080p.bluray.x264.mkv -vf 'scale_vaapi=w=1280:h=720' -map 0:0 -map 0:1 -map 0:2 -map 0:3 -c:v h264_vaapi -b:v 4500k -qp 18 -bf 0 -profile:v 578 -quality:v 0 -level:v 3.1 -coder:v cavlc -c:a ac3 -ab 224k -ar 48000 -ac 2 -codec:s copy -sub_charenc UTF-8 -metadata:s:s:0 language=eng -metadata:s:s:1 language=eng [15:52:22 CET] <hojuruku> /run/media/lmc/4409-8CCC/mylittlepony.mkv [15:52:52 CET] <JEEB> do you know it takes in matroska at all btw? [15:53:21 CET] <hojuruku> yeah it plays 1080 in another sample i got from mkv. the original video doesn't like the audo [15:53:37 CET] <yusa> Hello all! [15:53:45 CET] <JEEB> also lol at still using the integer for the profile :P [15:53:50 CET] <JEEB> way to make it unreadable [15:53:58 CET] <JEEB> anyways, if you know that the video track works [15:54:06 CET] <JEEB> just transcode the audio to AAC, that's the most common thing to work [15:54:11 CET] <hojuruku> the tcl cheap tv with a usb port can't do DTS, but it does AC3. It can't do mp3 in mkv/mp4 streams either. [15:54:35 CET] <hojuruku> haha it wont fit on the 4 gb usb key i'm throwing away then ;) [15:54:42 CET] <JEEB> right [15:54:56 CET] <hojuruku> JEEB: it rejects constrained_baseline [15:55:05 CET] <JEEB> old version or something? [15:55:12 CET] <hojuruku> and the interger is in the vaapi howto on your website .. oh sorry the evil libav website [15:55:31 CET] <JEEB> stop the evil/whatever BS, thank you [15:55:54 CET] <JEEB> but yea, originally the vaapi encoder didn't have the string-based options [15:56:03 CET] <JEEB> they were added in late last year I think [15:56:35 CET] <hojuruku> https://trac.ffmpeg.org/wiki/Hardware/VAAPI sorry i stand corrected you have 578 on your VAAPI page not libav [15:57:01 CET] <hojuruku> exactly what do i type -profile:v WHAT?? because constrained_baseline is rejected. [15:57:29 CET] <JEEB> well the wiki pages are community maintained [15:57:45 CET] <JEEB> hojuruku: as I asked, what is your FFmpeg version? [15:58:22 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=c490fc9536dcea7fdf1245a340… [15:58:27 CET] <JEEB> this is what added the named options [15:59:03 CET] <JEEB> before then the integer was correct since nobody had added string-wise AVOptions [15:59:25 CET] <hojuruku> gentoo is pretty recent, i wont try git because it breaks too much. 3.4.1-r1 [15:59:41 CET] <JEEB> yea, that probably is after the cut for the 3.4 series [16:01:25 CET] <hojuruku> do some hardware players (old one - think 4 year old tcl tv) demand cabac or high profile input? [16:03:17 CET] <JEEB> their software might be doing weird stuff but usually when people cheap out the hw limit is upwards, not downwards :P [16:04:14 CET] <JEEB> because to make a main profile decoder you need to support features in constrained baseline, and to make a high profile decoder you need to support features in main profile, as they are subsets of each other [16:04:15 CET] <hojuruku> i wonder if someone has made a swuite of test videos to probe the capabilities of your tv :) [16:04:44 CET] <hojuruku> constrained baseline only supports levels up to 3.2 right? [16:04:58 CET] <JEEB> I'd have to open the specification for that [16:05:00 CET] <hojuruku> officially that is. if you want hardware players to accept it [16:05:20 CET] <JEEB> because different profiles had slightly different limitations on the levels [16:05:56 CET] <yusa> Hello I am quite new to ffmpeg at all, but maybe you can kickstart me a little bit! I am actually from the area of object recognition, but for my demonstrator i will need to convert raw images. I am handling with 8-bit gray scale raw images that currently live in allocated memory in my C-tool. I could imagine piping these images from there to the ffmpeg tool. (Like in this example i found: #cat png/*png | ffmpeg -f image2pipe -c:v png - [16:06:21 CET] <hojuruku> maybe you might need a level 3.0 or 3.1 or 3.2 along with the constrianed profile to make the hardware player accept the b-frame content. maybe ffmpeg for some reason is choosing a higher level by default. ffmpeg always tries to choose the lowest compatible right? [16:06:32 CET] <JEEB> uhh [16:06:36 CET] <yusa> The format is specified here by "-c:v png". How to specify my raw images? (x and y resolution, 8-bit gray scale) [16:06:47 CET] <JEEB> hojuruku: a whole buttload of stuff depends exactly on the encoder you're using [16:06:59 CET] <JEEB> so saying generic statements on FFmpeg isn't going to help [16:07:10 CET] <hojuruku> yeah i'll have to read the source for h264_enc [16:07:16 CET] <hojuruku> i mean vaapi_h264enc [16:07:20 CET] <JEEB> also for b-frames you need main profile or higher [16:07:28 CET] <JEEB> since CABAC and b-frames are only included there [16:08:37 CET] <hojuruku> i'm talking the other way, with no b-frames and no cabac - you'll need to limit the max level you will put in the stream header right? i wonder if constrained baseline use in hardware plays only works to a certian level that's lower than the player's max capabilities. (e.g. 3.1 / 3.2) [16:10:09 CET] <JEEB> hojuruku: for your reference the limits between levels are common between baseline, constrained baseline, main and extended profiles [16:10:22 CET] <JEEB> A.3.1 in the AVC/H.264 specification [16:10:24 CET] <JEEB> there's also a nice table [16:10:40 CET] <JEEB> so it's just the high *** profiles that have a separate sets of limits [16:10:51 CET] <hojuruku> ah so with constrained baseline you are not allowed to go above level 3.1 [16:10:54 CET] <JEEB> and the table has 4+ just fine for baseline|main|extended [16:11:03 CET] <JEEB> no, A.3.1. is the part of the goddamn specification [16:12:09 CET] <yusa> Any ideas? :P [16:12:45 CET] <JEEB> and baseline/constrained baseline does have specific limits on the MbRectSize for levels 1-3.0, but defines anything higher just fine as "just follow the general requirements for the profile" [16:13:03 CET] <JEEB> so I don't know where this "constrained baseline only supports up to 3.2" thing comes from :P [16:13:24 CET] <hojuruku> ah i'm trying to find why this hardware player is rejecting it but the pc is playing it fine [16:13:42 CET] <JEEB> personally I would just make short clips with minimal stuff first :P [16:13:47 CET] <hojuruku> divide and conquer, i'll take 10 mins of the raw video without transcoding and change the audio to see if that fixes it. [16:13:54 CET] <hojuruku> .. then confirm my audio is ok so i can focus on the video. [16:14:58 CET] <JEEB> first an mp4 file with just AVC video, and AAC audio only, and setting -movflags faststart. first by copying, then re-encode [16:15:22 CET] <JEEB> because something like -c:a aac -ac 2 -b:a 192k should be good enough for basic AAC [16:15:45 CET] <JEEB> (you could probably lower the bit rate quite a bit, but it generally takes a small part of it all) [16:15:50 CET] <JEEB> then you start playing around with other variables [16:16:01 CET] <JEEB> after you make sure that the basics of video and audio work :P [16:16:11 CET] <JEEB> after you verify mp4, you can also test mkv [16:16:12 CET] <JEEB> etc etc [16:16:30 CET] <hojuruku> yeah i'm using ac3 because i first tried big buck bunny samples on the hardware player. mp4 with mp3 audio at 720p failed, but mp4 with ac3 448k 720p surround sound palyed fine [16:16:41 CET] <hojuruku> so i know mp3 isn't supported by the hardware player at least in video streams. [16:16:54 CET] <JEEB> that's usually an issue with people not implementing old mpeg audio parsing from mp4 [16:16:59 CET] <JEEB> rather than a "doesn't support mp3" issue [16:17:12 CET] <JEEB> which is why I note AAC as the first thing I test with mp4 [16:17:26 CET] <JEEB> since that stuff, esp. with the movflags faststart flag, tends to more or less work [16:17:36 CET] <hojuruku> oh so i should test again with mkv. [16:17:52 CET] <JEEB> yea if you have an exact combo that works with mp4 [16:17:57 CET] <JEEB> you should -c copy that into mkv [16:18:01 CET] <JEEB> and see how that works [16:18:11 CET] <hojuruku> it's there a equivalent flag for mkv to have the fast start? [16:18:17 CET] <JEEB> it doesn't need it per se [16:18:22 CET] <JEEB> so there isn't [16:18:38 CET] <hojuruku> yeah, mp4 can not define the length of the video etc at the beginning for streaming, but mkv not so. [16:22:21 CET] <hojuruku> that's an idea, maybe mkv container is assumed to be main or high profile by the hardware player, but mp4 support not. [16:22:32 CET] <JEEB> lol no [16:22:43 CET] <JEEB> generally just issues with specific audio/video formats or containers altogether [16:23:00 CET] <JEEB> although to be completely honest I have no idea what the AMD encoder spouts out at all [16:23:04 CET] <JEEB> also you added subtitle tracks etc [16:23:12 CET] <JEEB> there's plenty of stuff that could make the TV go "nope" [16:23:29 CET] <JEEB> which is why you start with the most plain of plainest for most ekta plastik boxes [16:23:30 CET] <hojuruku> the subtitle tracks work in the original video so remove them. got it. [16:23:42 CET] <JEEB> eh [16:23:50 CET] <JEEB> I'm just saying limit your darn testing surface [16:23:51 CET] <hojuruku> but the srt subtitles work in the sample from the original source (only the dts audio fails) [16:24:23 CET] <JEEB> as in make a short sample, encode just video and audio in mp4 with faststart [16:24:27 CET] <JEEB> test that [16:24:33 CET] <JEEB> if works, add more stuff step by step [16:24:34 CET] <JEEB> :P [16:24:48 CET] <JEEB> I don't think this is a hard thing to grasp [16:25:28 CET] <hojuruku> but what i started with was mkv 1080p, dts, srt and it worked minus the audio. That's why i'm confused now. [16:26:22 CET] <JEEB> well it could just be the video encoder being derp, of course. but still. minimize the testing surface. output a short sample with just the video and the audio into mp4, test that [16:26:36 CET] <JEEB> then test -c:v libx264 -profile main -level 4.1 or something like that [16:26:43 CET] <JEEB> or even baseline [16:27:04 CET] <JEEB> (which is constrained baseline) [16:27:19 CET] <JEEB> I'm pretty sure all of those would work on your device, but at least libx264 should give you relatively known results [16:27:29 CET] <hojuruku> libx264 high aac 192 made by handbrake failed on the audio ;) [16:27:36 CET] <hojuruku> but the video worked fine. [16:27:47 CET] <JEEB> I don't know what exactly handbrake did there [16:28:01 CET] <hojuruku> the hardware player generally carries on if the audio is broken but borks if the video is screwed. [16:28:09 CET] <JEEB> anyways, that sort of thing failing with AAC would be rather funny [16:28:14 CET] <hojuruku> i can see what handbrake did with mediainfo [16:28:55 CET] <hojuruku> maybe it only does aac up to 128k [16:29:02 CET] <JEEB> no, instead just darn test things quickly with ffmpeg.c since that's what you're currently utilizing (Ž4@) [16:29:07 CET] <JEEB> rather darn arbitrary limit that [16:29:16 CET] <JEEB> I mean, you can keep on darn guessing as much as you want [16:29:22 CET] <furq> yeah i'm not sure there is anything that has that kind of limit [16:29:46 CET] <JEEB> anyways, have fun - I'm going out to get fresh air and see who I will vote for [16:29:58 CET] <hojuruku> testing with mp4 now... [16:31:04 CET] <JEEB> just darn test with `ffmpeg -i INPUT -t 120 -c:v libx264 -profile baseline -level 4.1 -c:a aac -ac 2 -b:a 192k -sn -movflags faststart test1.mp4` [16:31:09 CET] <JEEB> then give that a fly [16:31:16 CET] <JEEB> that's the very basic of basics [16:31:23 CET] <JEEB> if you need to re-encode [16:31:29 CET] <JEEB> if you don't then it's all simpler [16:31:35 CET] <furq> JEEB: nils torvalds of course [16:32:01 CET] <JEEB> then if you need stuff like subtitles you switch to mkv next [16:32:15 CET] <JEEB> then if that works you switch to your beloved black box VAAPI encoder [16:32:26 CET] <JEEB> if that breaks you know it's not baseline nor the level which you guessed around [16:32:33 CET] <JEEB> it's just whatever the VAAPI encoder is doing [16:32:42 CET] <JEEB> but ye, I'm outta here [16:42:23 CET] <hojuruku> it rejected the mp4 with whatever vaapi was making completly with aac, but scrambled the screen with the mkv with 128 aac which was interesting. [16:42:34 CET] <hojuruku> i'll begin testing using software encoders now. [16:42:42 CET] <hojuruku> i thought if it played on my pc it was good... it's not good. [16:43:46 CET] <furq> yusa: -s 123x456 -c:v rawvideo [16:44:08 CET] <furq> you might need to set -pixel_format before -i as well [16:44:39 CET] <yusa> I was trying: ffmpeg -f image2 -r 30 -s 1280x720 -pix_fmt rgb24 -vcodec rawvideo -i raw/*.raw raw.mp4 [16:44:59 CET] <yusa> for these test images in folder raw/ [16:45:09 CET] <yusa> [NULL @ 0x11010c0] Unable to find a suitable output format for 'raw/image002.raw' raw/image002.raw: Invalid argument [16:45:58 CET] <klaxa> doesn't this image """raw""" format contain tons of metadata? [16:46:11 CET] <furq> oh if you mean .raw then that's different [16:46:16 CET] <furq> i thought you meant piping raw frames into ffmpeg [16:46:41 CET] <yusa> ah, with raw i mean only the pixel data nothing else [16:46:58 CET] <yusa> thats what my .raw files contain, sorry if i am messing up with file types [16:47:24 CET] <furq> yeah that's rawvideo then [16:48:19 CET] <furq> probably something like cat *.raw | ffmpeg -s 123x456 -pix_fmt rgb24 -f rawvideo -i - out.mp4 [16:49:28 CET] <yusa> awesome almost worked [16:51:30 CET] <yusa> How can i print all available pixel formats i can apply to -pix_fmt? [16:53:36 CET] <furq> ffmpeg -pix_fmts [16:54:32 CET] <yusa> okay for my 8-bit gray scale images, i will need gray i guess [16:54:39 CET] <yusa> thank you very much [17:00:21 CET] <yusa> Another question: Is it somehow possible output not in a file but as a RTP/RTSP or RTMP stream ? [17:02:12 CET] <hojuruku> haha -x264-params opencl makes it go slower i think. well 1.33fps vs 1.2 [17:32:37 CET] <furq> yusa: if you have an rtmp server to send it to, sure [17:32:51 CET] <furq> -c:v libx264 -f flv rtmp://1.2.3.4/live [17:36:52 CET] <yusa> furq: That is really cool! I am beginning to enjoy working with ffmpeg, sounds pretty straight forward. Yes i have already tried nginx media streaming server, this should work. But i also came accross ffserver, could be the most efficient solution. I am seeking for efficiency as I am working on an embedded linux platform... [17:37:12 CET] <furq> don't use ffserver [17:37:27 CET] <furq> nginx-rtmp is a much better choice [17:37:41 CET] <furq> not least because ffserver is deprecated now and will be gone in the next release [17:38:13 CET] <yusa> Aah, thanks for the insides! [17:39:06 CET] <JEEB> hojuruku: the Proof of Concept opencl stuff only applies to lookahead, and yes - it can very much be slower [17:39:13 CET] <JEEB> that is why people don't generally use the opencl stuff in x264 [17:39:21 CET] <JEEB> it can be easily built in, but (Ž4@) [17:39:45 CET] <JEEB> it's a proof of concept, after all [17:39:48 CET] <JEEB> http://git.videolan.org/?p=x264.git;a=commit;h=f49a1b2ef6d95d8f0f186df0fc3b… [17:40:04 CET] <JEEB> so if you want to go faster, you use presets [17:40:17 CET] <JEEB> -preset veryfast should with any modern CPU be rather quick, for example [17:41:12 CET] <DHE> I've seen opencl give performance boosts from -20% to +20% and I'm not sure what the difference maker is [17:41:48 CET] <furq> i've read that it may give slightly worse quality [17:42:03 CET] <furq> so it doesn't seem worth it at all considering how unpredictable the perf is [17:42:26 CET] <JEEB> yeh [17:42:33 CET] <JEEB> it's a proof of concept that "we can do stuff with opencl" [17:42:37 CET] <JEEB> not to mention this was early opencl [17:42:53 CET] <JEEB> there's plenty of hacks there because of its age and thus opencl 1.x lacking stuff [17:43:00 CET] <furq> use your gpu for filtering [17:43:03 CET] <furq> it's quite good at that [17:43:06 CET] <JEEB> yup [17:43:07 CET] <furq> Yagiza: pls stop [17:43:25 CET] <JEEB> unsurprisingly graphics hardware is actually good at graphics stuff [17:44:41 CET] <JEEB> granted if you can thread your calculations really heavily [17:44:45 CET] <JEEB> GPGPU can work [17:45:07 CET] <JEEB> unfortunately video encoding with any resemblance of compression efficiency will not let you do that [17:45:31 CET] <JEEB> ATi back in the day made their own video format that enabled really high threading and it was fast - but it was also not something that would compress well [17:45:37 CET] <furq> semblance [17:45:47 CET] <JEEB> right [17:45:57 CET] <furq> resemblance to or semblance of [17:46:09 CET] <JEEB> anyways, the end result was that everyone and their dog just started making ASICs for the video formats [17:46:14 CET] <JEEB> (for both decoding and encoding) [17:47:23 CET] <hojuruku> been testing that hardware player using libx264 ... interesting it plays aac 192 in mp4 but not mkv [17:47:43 CET] <furq> "interesting" is one way to describe hardware players [18:05:10 CET] <hojuruku> interesting, mpv loves what the vaapi encoder makes but gstreamer isn't having any constrained baseline. [18:07:32 CET] <hojuruku> Stream #0:2(eng): Data: bin_data (text / 0x74786574) Metadata: handler_name : SubtitleHandler Unsupported codec with id 100359 for input stream 2 - funny i thought i disabled subtitles. ffprobe found that [18:07:48 CET] <hojuruku> yep i encoded with -sn [18:09:13 CET] <hojuruku> and there we go again it got added [18:09:55 CET] <ritsuka> it's the chapters track [18:13:33 CET] <hojuruku> i encoded with -map 0:0 -map 0:1 (audo / video only) as well as -sn and it keeps coming up with ffprobe [18:13:52 CET] <JEEB> yes, because of how chapters can get put into mp4 [18:14:07 CET] <JEEB> or well, explicitly they're all out of spec because the working group decided they wouldn't specify chapters [18:14:15 CET] <JEEB> so you've got either the CHAP way or the other way [18:14:25 CET] <JEEB> and they can pop up in ffprobe like that, although I haven't seen them in general [18:14:33 CET] <JEEB> (although I very rarely transcode stuff with chapters) [18:20:09 CET] <hojuruku> so i've done some more testing, that was a misnomer. the hardware player can not handle aac audio in mkv container. [18:20:51 CET] <hojuruku> i need to make libx264 do constrained baseline now... i think i can't handle that either [18:22:07 CET] <hojuruku> libx264 doesn't support constrained baseline :P maybe it takes the interger format [18:23:21 CET] <hojuruku> nope, why can't vaapi_h264 support baseline??? [18:23:30 CET] <furq> -profile baseline with x264 is actually constrained baseline [18:23:41 CET] <hojuruku> [libx264 @ 0x560125dedca0] Error setting profile 578. [18:24:54 CET] <hojuruku> this is interesting... fmpeg -i rep-mylittleponythemovie.2017.1080p.bluray.x264.mkv -t 120 -ss 600 -c:v libx264 -coder 0 -profile:v baseline -level 3.1 -c:a aac -ac 2 -b:a 128k -sn -movflags +faststart /run/media/lmc/4409-8CCC/test10.mp4 works... [18:25:30 CET] <hojuruku> but... ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -ss 120 -t 120 -i rep-mylittleponythemovie.2017.1080p.bluray.x264.mkv -map 0:0 -map 0:1 -c:v h264_vaapi -b:v 4000k -qp 20 -bf 0 -profile:v 578 -movflags +faststart -quality:v 0 -level:v 3.1 -coder:v cavlc -c:a aac -ab 128k -ar 48000 -ac 2 vaapitest3.mp4 - doesn't. I need to investigate how the mp4 data is corrupt somehow [18:26:38 CET] <hojuruku> bflags... i wonder. [18:27:34 CET] <hojuruku> maybe there is a bug here. i've set up vaapi to encode with the same paramaters exactly, and i'm going to investigate with gstreamer rejects it but mpv accepts it. [18:33:44 CET] <hojuruku> libx264: Stream #0:0(eng): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuv420p, 1920x808 [SAR 1:1 DAR 240:101], 2957 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 47.95 tbc (default) vaapi Stream #0:0(eng): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuv420p, 1920x808, 3913 kb/s, SAR 1:1 DAR 240:101, 23.98 fps, 23.98 tbr, 24k tbn, 48k tbc (default) [18:36:45 CET] <hojuruku> yep totem gstreamer isn't playing the vaapi created file with the same presets. something is going on here. [18:37:56 CET] <hojuruku> mpv with -hwdec no -vo x11 has no problems. therefore gstreamer's playbin hates the mp4 stream created by vaapi with all the same parameters. [18:39:24 CET] <yusa> Hi again! I've tried now: "ffmpeg -i music.mp4 -c:v libx264 -f flv rtmp://localhost/live". This streams to nginx server. With vlc i am opening "rtmp://localhost/live" and it seems to work. But then video stops, because ffmpeg has finished work as it as converted all data and sent it to the server. So my question is, how to control the output framerate so that the replay rate matches the output rate? [18:40:06 CET] <furq> yusa: -re before -i [18:41:01 CET] <yusa> cool, now operating constantly at 24 fps, awesome! [18:43:09 CET] <yusa> i see, "Mainly used to simulate a grab device. or live input stream" [18:43:11 CET] <yusa> thanks a lot again [18:46:15 CET] <hojuruku> qtdemux qtdemux.c:9713:qtdemux_parse_trak:<qtdemux0> Track shorter than 20% (2881879/24000 vs. 5834998/1000) of the stream found, assuming preview image or something; skipping track [18:47:02 CET] <hojuruku> that's the problem gstreamer has with the vaapi encoded mp4 [18:48:40 CET] <hojuruku> yet vaapi encoded matroska has no errors at all with the same command line except for the container format. this is getting weird. is it a bug? [18:49:27 CET] <hojuruku> i think i'll go to git once i've finished my update and leave the preserved libraries alone ;) [18:58:11 CET] <hojuruku> Note: 4 Generation Intel Core and earlier processors are not supported by Intel Media Server Studio 2017. I knew qsc was shit [18:58:20 CET] <hojuruku> https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/q… [18:59:33 CET] <hojuruku> Prerequisites A machine with QSV hardware, Haswell, Skylake or better. https://blogs.gentoo.org/lu_zero/2016/10/31/intel-mediasdk-mini-walkthrough/ [19:01:34 CET] <kevinn> Does anyone have any experience using libp2p to pack planar buffers? [19:01:51 CET] <kevinn> I am having a bit of trouble [19:02:02 CET] <hojuruku> https://software.intel.com/media-sdk haaha they dropped all desktop support - only for embedded linux now [19:04:06 CET] <hojuruku> https://software.intel.com/en-us/intel-media-server-studio/details yep haswell support dropped. [19:10:03 CET] <hojuruku> hehe, vaapi encoded mp4's that bork gstreamer crash the hardware player too, but are rejected there in matroska streams. vaaapi plays fine on gstreamer in matroska containers. i can't make sense of this. [19:11:25 CET] <hojuruku> sorry i mean the mkv's that play fine on gstreamer crash the hardware player. the mp4's are rejected outright by the hadware player are also rejected on the gstreamer qtmux plugin. [19:11:57 CET] <hojuruku> mpv can't find anything wrong with the hardware encoded content. [19:12:39 CET] <JEEB> if you're using software decoding then that goes through FFmpeg's decoding and that gives a whole lot of stuff leeway even if it's not perfect [19:12:49 CET] <JEEB> have you tried hwdec with mpv? [19:13:09 CET] <JEEB> (that also goes through FFmpeg usually but the ASICs tend to be more finicky) [19:13:10 CET] <hojuruku> hwdec with mpv and software dec with mpv handles whatever vaapi throws at it [19:15:17 CET] <hojuruku> what ffmpeg tool looks at the streams and qa's the files? ffprobe? [20:02:28 CET] <ddubya> if a filter chain outputs lower framerate than input, what could be the problem. My inputs are 30fps and smooth but output is 25 and choppy [20:03:19 CET] <JEEB> unless you do some fancy stuff changing the frame rate without making the clip longer/shorter means you're just taking pictures out [20:03:43 CET] <JEEB> so yes, totally not surprising if a simple 25'ification of 30Hz content gets choppy :P [20:04:07 CET] <ddubya> well the choppy is no surprise, but the frame rate change is [20:04:25 CET] <JEEB> it's your filter chain... [20:04:47 CET] <JEEB> you can look at what exactly it contains and look at why you're getting what you're getting [20:06:32 CET] <ddubya> hmm all I have is "color" and "overlay" [20:06:37 CET] <ddubya> maybe "color" has fps setting [20:06:44 CET] <DHE> what's the framerate of the other overlay signal? [20:06:55 CET] <DHE> is it 1 input, or 2? [20:07:14 CET] <ddubya> they're both 30fps [20:07:21 CET] <ddubya> it says on the opening input log [20:07:43 CET] <DHE> yeah, color defaults to a 25fps virtual output [20:46:36 CET] <trewq> folks, wanted to see if you had any thoughts on this question: https://stackoverflow.com/questions/48490516/ffmpeg-concatenated-file-does-… [20:54:29 CET] <specing> one does not simply concatenate video files [20:56:29 CET] <durandal_1707> meme [20:59:40 CET] <specing> hi durandal_1707 [20:59:49 CET] <specing> I was not aware the elders were available [21:00:10 CET] <specing> speaking of glueing video files together, is there an official or a good unofficial howto? [21:00:59 CET] <specing> i.e. how to continue after ffmpeg got killed.... there was something saying that one has to glue before the last reference frame, but -ss and -to only accept time and not frames... [21:01:22 CET] <Kuukunen-> ffmpeg used to concat files like you do, but then it took a fork to the knee [21:01:43 CET] <durandal_1707> howto: avoid it at all cost [21:02:11 CET] <specing> :( [21:02:33 CET] <durandal_1707> for concat of frames at any position use concat filter [21:04:00 CET] <ddubya> how would I figure out the scrolling speed rate of the showspectrum filter in samples/second ? [21:05:29 CET] <ddubya> I think I mean pixels/second [21:07:08 CET] <durandal_1707> ddubya: each frame gives new pixel width [21:09:00 CET] <ddubya> how many samples in the frame? I guess its the width of the FFT ? [21:09:57 CET] <durandal_1707> width of fft is given by height of video [21:14:33 CET] <durandal_1707> so for 512 height its approx 44 frames per second for 44100 rate [21:18:15 CET] <ddubya> got it! thanks! [21:54:13 CET] <hihi> I know that I can save stream to file without decode and encode the stream , ffmpeg-i http://.... -v:c copy test.avi how can I do that when I stream file with ffserver(I know that not recommended) [21:54:36 CET] <hihi> when I stream static file I see that ffmpeg decode and encode it , [21:56:18 CET] <BtbN> you realize ffserver is dead? It was recently removed from ffmpeg. Don't use it. [21:57:24 CET] <analogical> does anyone happen to know how do decompress wavpack on linux? [21:57:45 CET] <hihi> BtbN>: I don't find another server that works with ffmpeg that can stream with lot of protocols [21:57:49 CET] <sfan5> ffmpeg can do that ;) [21:57:53 CET] <hihi> BtbN: do you know ? [21:58:03 CET] <BtbN> most people use nginx-rtmp [21:58:37 CET] <hihi> BtbN: I not see that nginx-rtmp can stream over rtsp and over mjpeg (http) [21:59:08 CET] <BtbN> It can send out rtmp, hls and dash [21:59:14 CET] <BtbN> which is pretty much all that's commonly used nowdays [21:59:34 CET] <hihi> BtbN: i not get you freind [21:59:59 CET] <hihi> i looking for server that can easily works with ffmpeg and can stream with lot of protocols that ffserver can [22:00:36 CET] <BtbN> Why do you want a server for lots of protocols? That's not how this works. You get a server for one specific protocol. [22:00:36 CET] <hihi> 1) mjpeg 2) rtsp udp 3)rtsp tcp 4) rtsp ovet http 5) rtsp multi cast , I not see that nginx-rtmp can do that [22:01:04 CET] <hihi> that why I love ffserver , that can stream with lot of protocols [22:01:27 CET] <BtbN> It's also a big hack and unmaintaned for the better part of a decade [22:02:59 CET] <hihi> BtbN: I know that , but I not find another server that can stream over lot of protocols [22:03:18 CET] <BtbN> And why do you need a lot of different protocols? That's not a normal usecase. [22:04:01 CET] <hihi> I have many client and each 1 want another protocols [22:04:16 CET] <hihi> do you know ffserver and can you help me wit hthat problem? [22:04:32 CET] <BtbN> I never used it. And nobody seems to have in a long time. [22:04:39 CET] <BtbN> You're on your own if you insist on using it. [22:05:01 CET] <klaxa> i looked at it in 2015 and was supposed to remove all the internal http usage by the pubilc api [22:05:10 CET] <klaxa> but holy shit [22:05:48 CET] <analogical> does anyone happen to know how do decompress wavpack on linux?? [22:06:18 CET] <JEEB> did you miss FFmpeg having a decoder? [22:06:36 CET] <JEEB> not sure if the reference code can be compiled for *nix, probably can :P [22:06:38 CET] <hihi> JEEB are you talking to me? [22:07:55 CET] <tdr> analogical /usr/bin/wvunpack ? [22:11:20 CET] <analogical> tdr, doesn't exist on my Linux Mint system [23:34:22 CET] <Jaxx_> hi, I dont like to be the one asking "when" question but is there any aproximate eta for ffmpeg binary for windows with VPX 1.7.0? thanks [23:35:00 CET] <JEEB> there are no official binaries [23:35:06 CET] <BtbN> we don't do binaries [23:35:13 CET] <JEEB> some people do windows binarie, so you'd have to ask them [23:37:14 CET] <Jaxx_> ah so ask zeranoe directly? [23:37:29 CET] <JEEB> that would be one guy [23:38:08 CET] <Jaxx_> kk thank you [00:00:00 CET] --- Mon Jan 29 2018

1 0

ffmpeg-devel.log.20180127
by burek 28 Jan '18

28 Jan '18

[00:44:10 CET] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vN1xJ [00:44:10 CET] <KGB> 13FFV1/06master 149df20bf 15Dave Rice: bump to version 01... [01:12:13 CET] <wm4> rcombs: I sent a patch that partially reverts a commit by you, can you review? [01:12:21 CET] <rcombs> sure [01:13:18 CET] <rcombs> wm4: yeah that's fine [01:13:40 CET] <rcombs> the point was to try to be more friendly to existing API users, so if it's not having that effect reverting's fine [01:15:21 CET] <atomnuker> jkqxz: I see you can map vaapi frames to drm frames, what use is that? can you output vaapi frames directly to VTs this way? [01:16:48 CET] <wm4> not just via DRM but also EGL and others [01:17:10 CET] <wm4> since the DRM hwcontext is just unix FDs + metadata [01:22:36 CET] <jkqxz> atomnuker: <http://ixia.jkqxz.net/~mrt/kms_va_nv12.c> [01:25:26 CET] <atomnuker> this does vaapi->drm by itself, I was wondering why there was a vaapi->drm in lavu [01:25:32 CET] <atomnuker> can you use it? [01:26:36 CET] <jkqxz> Oh, right. It's the same thing. [01:27:28 CET] <jkqxz> I was planning to use it as an intermediate for other stuff (like OpenCL), but it still isn't in a released libva. [01:29:23 CET] <jkqxz> So it's currently there but unused. You can see it working in ffmpeg with hwmap, but not very usefully. [01:30:23 CET] <atomnuker> could be useful for VAAPI->DRM->Vulkan [01:30:35 CET] <atomnuker> because there's no way to directly import from vaapi as far as I can see [01:30:55 CET] <jkqxz> Yeah, I'd like to do DRM intermediates using it, but OpenCL was there before it could be used. [01:31:41 CET] <wm4> jkqxz: what's the to be released libva thing? [01:32:18 CET] <jkqxz> vaExportSurfaceHandle() is in libva 2.1, but it's not yet released. [01:32:42 CET] <jkqxz> Hmm, I should chase the AMD people in Mesa over that again. [01:33:32 CET] <wm4> oh right [01:33:45 CET] <wm4> I'm waiting for that too [01:33:48 CET] <wm4> vdpau must die [01:39:43 CET] <jkqxz> Huh, they've posted H.265 encode with VAAPI - <https://lists.freedesktop.org/archives/mesa-dev/2018-January/183471.html>. [01:40:17 CET] <jkqxz> Raven Ridge only though (the newest APU chips, which aren't in many places yet). [03:30:08 CET] <wm4> old but nice: https://de.slideshare.net/SamsungOSG/ffmpeg-a-retrospective [03:30:27 CET] <wm4> gems like this https://image.slidesharecdn.com/2015102801sosconslidesffmpeg-151104161552-l… [03:36:30 CET] <kierank> wm4: not untrue [03:41:42 CET] <youngluoyang> how to use docker build ffmpeg develop environment? [04:18:41 CET] <cone-625> ffmpeg 03wm4 07master:637dfa39421c: hls: do not allow fallback to generic seeking [04:18:41 CET] <cone-625> ffmpeg 03wm4 07master:6194d7e56454: avformat, hls: add a flag to signal unavailability of seeking [04:18:41 CET] <cone-625> ffmpeg 03wm4 07master:23ffeb91fe46: hls: don't print a certain warning if playlist loading is aborted [04:31:21 CET] <cone-625> ffmpeg 03Michael Niedermayer 07master:c6939f65a116: avfilter/vf_transpose: Fix used plane count. [04:31:22 CET] <cone-625> ffmpeg 03Michael Niedermayer 07master:1bfc1aa00495: avcodec/mjpegdec: Fix integer overflow in DC dequantization [04:31:23 CET] <cone-625> ffmpeg 03Michael Niedermayer 07master:a026a3efaeb9: avcodec/hevc_cabac: Check prefix so as to avoid invalid shifts in coeff_abs_level_remaining_decode() [12:54:18 CET] <KGB> [13FFV1] 15michaelni tagged 06draft-ietf-cellar-01 at 06master: 02https://git.io/vNMEW [13:49:53 CET] <dijkstrazeppelin> Hi guys, I was investigating the MPEG-4 ALS decoder aka "alsdec.c" for the qualification task. Could someone please tell me how a modified alsdec.c can be tested ? Is there some command that 'runs' ffplay and uses my modified alsdec.c file?Thanks a ton in advance !:) [13:58:15 CET] <DHE> umm.. recompile and produce new binaries to test it? [13:59:03 CET] <dijkstrazeppelin> Thanks! I'm sorry I'm such a noob :( [15:50:46 CET] <atomnuker> jkqxz: for some reason doing hwmap,hwdownload makes lavfi correctly call map_to but then gives the original unmapped frames to hwdownload [15:50:48 CET] <atomnuker> ./ffmpeg_g -init_hw_device "vulkan=sl:0,extensions=VK_EXT_debug_report" -device /dev/dri/card0 -crtc_id 0 -f kmsgrab -i /dev/zero -filter_hw_device sl -vf hwmap,hwdownload,format=bgra -f null - [15:51:30 CET] <atomnuker> so hwdownload gets frames with drm_prime as pixfmt [17:08:14 CET] <BtbN> philipl, can you take a look at the mapping-refcounting-nvenc patch? I'm pretty confident it's ok, but a second pair of eyes would be good. [17:19:58 CET] <BtbN> I'd also like to backport this to at least 3.4 and 3.3. It fixes crashes in a few strange edge cases I wasn't able to reproduce myself. [17:29:42 CET] <jkqxz> atomnuker: Did it choose the right pixfmt on the output of hwmap? [17:30:19 CET] <jkqxz> (The lavfi format setup runs before you can map anything, so it can easily mess up.) [17:51:15 CET] <atomnuker> you mean the right drm -> vulkan format mapping? [17:51:29 CET] <atomnuker> or the hwdownload format? [18:05:58 CET] <jkqxz> I mean what lavfi chooses as the format on the link between hwmap and hwdownload. [18:08:24 CET] <kierank> michaelni: [18:08:24 CET] <kierank> > + s->mb_x = mb_num % s->mb_width; [18:08:24 CET] <kierank> > + s->mb_y = mb_num / s->mb_width; [18:08:24 CET] <kierank> missing validity checks [18:08:33 CET] <kierank> it's the same in the normal mpeg4 video code [18:08:37 CET] <kierank> what do you want me to validate them as? [18:08:44 CET] <kierank> nonzero? [18:09:28 CET] <kierank> same with [18:09:28 CET] <kierank> > + Mpeg4DecContext *ctx = (Mpeg4DecContext *)s; [18:09:34 CET] <kierank> that's exactly the same as the existing code [18:10:37 CET] <kierank> also get_vlc2 isn't documented as returning any errors? [18:10:54 CET] <atomnuker> jkqxz: would that be the output sw_format? [18:11:02 CET] <atomnuker> (after mapping?) [18:20:01 CET] <jkqxz> No. AVFilterLink.format on the link between hwmap and hwdownload, is that AV_PIX_FMT_VULKAN_WHATEVER? If not, it can't possibly work. And I don't think your command has given lavfi the opportunity to choose that. [18:22:52 CET] <atomnuker> yeah, link->format is dri_prime in filter_frame [18:23:15 CET] <atomnuker> the same command works with vaapi though, if you replace vulkan->vaapi and add a proper /dev/dri node [18:24:49 CET] <jkqxz> Luck? Dunno. Put format=vulkan_whatever between the two filters and try again, I think. [18:25:44 CET] <jkqxz> (Are there going to be multiple vulkan formats, or is the VkImage the only sensible thing to expose?) [18:26:44 CET] <atomnuker> vkimage is the only sensible thing [18:29:39 CET] <atomnuker> hm, seems to work now, though the avframe I'm getting is junk [18:29:49 CET] <atomnuker> the avbufferref seems to be all 0's [18:29:57 CET] <atomnuker> (that's where I store my context) [18:32:12 CET] <atomnuker> wait, no, whatever's in the bufferref is definitely not an avvkframe [19:28:19 CET] <michaelni> kierank, i meant that mb_num must be less than the number of mbs. theres a check for this in the existing code "mb_num>=s->mb_num", zero if its disallowed can be checked too. ill double check and if needed fix the existing code [19:28:34 CET] <kierank> ok that's what i did [19:37:13 CET] <atomnuker> grr vulkan, why do you support all these obscure packings and yet no bgr0 [19:37:50 CET] <atomnuker> I get that you can use BGRA and swizzle the alpha to null but its less nice [20:05:11 CET] <durandal_1707> lol, so vulkan thing doesnt work at all? awesome work! [20:10:00 CET] <atomnuker> durandal_1707: no, it does, its quite fast too [20:10:24 CET] <atomnuker> I have a working DRM->Vulkan interop [20:10:56 CET] <kierank> durandal_1707: can you review my patch [20:11:37 CET] <atomnuker> and since everywhere in lavfi in vulkan we work in linear images the drm tiles images can be converted to linear (de-tiled) via a filter which just blits 'em [20:12:24 CET] <atomnuker> once I write that filter you'll finally be able to losslessly download kms frames rather than going through vaapi [20:12:34 CET] <durandal_1707> kierank: no, im michaelni lieutenant [20:12:41 CET] <kierank> durandal_1707: ok, np [20:12:47 CET] <kierank> I defer to the dear leader [20:13:19 CET] <durandal_1707> @/ [20:16:08 CET] <durandal_1707> atomnuker: what? does it support float formats? [20:18:54 CET] <durandal_1707> kierank: where is simple idct patch? when you last time sent it? [20:19:03 CET] <kierank> durandal_1707: december 27 [20:19:06 CET] <kierank> i think [20:19:50 CET] <atomnuker> durandal_1707: sure, though it works on non-planar floats though so I'll need to write a few lines to (de) interleave them during mapping/uploading [20:20:31 CET] <atomnuker> lavu only has planar GBR float formats [20:21:55 CET] <atomnuker> I could add non-planar float support if there's anything to generate them (zlib?) [20:24:05 CET] <durandal_1707> atomnuker: zlib works only with planar , libp2p on other hand works with packed [20:24:34 CET] <JEEB> p2p is the packed<->planar conversion thing :P [20:24:49 CET] <JEEB> did it support NV12? [20:24:57 CET] <JEEB> (or other half-packed things) [20:25:44 CET] <durandal_1707> kierank: michaelni said that you hadnt renamed functions to have clear whats what in bitdepth [20:25:56 CET] <kierank> I did [20:26:08 CET] <durandal_1707> for 12 bit too? [20:26:18 CET] <atomnuker> hmm, actually what I could do is to flag the image as YUV444 multiplanar and then allocate 3 planes for 1 image and bind them all to it [20:26:24 CET] <kierank> durandal_1707: yes [20:26:42 CET] <atomnuker> the sw_format's going to be GRAPF so filters will know its not YUV but float RGB in each plane [20:27:27 CET] <atomnuker> durandal_1707: why do you need float pixfmt support? [20:32:43 CET] <durandal_1707> atomnuker: out of gamut values for hdr? [20:34:26 CET] <durandal_1707> kierank: one of test stuff is not updated, ff_simple_idct_16_12 [20:35:20 CET] <kierank> fixed that already [20:38:43 CET] <durandal_1707> JEEB: https://github.com/sekrit-twc/libp2p/blob/master/p2p_api.cpp [20:41:08 CET] <JEEB> yea, I noticed the V210 case too already [20:44:34 CET] <atomnuker> jkqxz: is there a filter which refs the frames context rather than creating a new one? [20:48:43 CET] <durandal_1707> kierank: where are studio samples? [20:49:02 CET] <kierank> On trac [20:49:36 CET] <kierank> Only 3, one uses dpcm so only plays for a bit [20:49:43 CET] <kierank> But I will fix later [20:50:59 CET] <jkqxz> atomnuker: deinterlace_qsv. [20:53:20 CET] <durandal_1707> kierank: i get segv plaaying sr lite incomplete download [20:53:58 CET] <kierank> Send backtrace [20:54:27 CET] <kierank> Probably because mpeg4video uses unchecked bitstream reader [20:56:28 CET] <durandal_1707> yes [20:56:59 CET] <durandal_1707> ff mpeg4 decode studio slice header [20:57:18 CET] <durandal_1707> mpeg4video.c:560 [20:57:35 CET] <durandal_1707> *dec [21:08:49 CET] <philipl> BtbN: looking [21:10:22 CET] <durandal_1707> kierank: it also randomly crashes when playing with mpv or ffplay, inside add_dct at libavcodec/mpegvideo.c:1877 [21:10:35 CET] <JEEB> can you try valgrind'ing it? [21:12:50 CET] <durandal_17> (gdb) bt [21:12:50 CET] <durandal_17> #0 0x0000000000000000 in ?? () [21:12:50 CET] <durandal_17> #1 0x00007ff4dcbbf6ae in add_dct (s=0x5596e2055240, i=0, line_size=<optimized out>, block=<optimized out>, dest=<optimized out>) at libavcodec/mpegvideo.c:1877 [21:12:53 CET] <durandal_17> #2 mpv_reconstruct_mb_internal (lowres_flag=0, is_mpeg12=0, s=<optimized out>, block=<optimized out>) at libavcodec/mpegvideo.c:2092 [21:12:56 CET] <durandal_17> #3 ff_mpv_reconstruct_mb (s=<optimized out>, block=<optimized out>) at libavcodec/mpegvideo.c:2214 [21:12:59 CET] <durandal_17> #4 0x00007ff4dc868988 in guess_mv (s=<optimized out>) at libavcodec/error_resilience.c:453 [21:13:02 CET] <durandal_17> #5 ff_er_frame_end (s=<optimized out>) at libavcodec/error_resilience.c:1231 [21:13:05 CET] <durandal_17> #6 0x00007ff4dc8d0283 in ff_h263_decode_frame (avctx=<optimized out>, data=<optimized out>, got_frame=<optimized out>, avpkt=<optimized out>) at libavcodec/h263dec.c:670 [21:13:08 CET] <durandal_17> #7 0x00007ff4dcc4e612 in frame_worker_thread (arg=<optimized out>) at libavcodec/pthread_frame.c:201 [21:13:11 CET] <durandal_17> #8 0x00007ff4d84e46da in start_thread (arg=0x7ff4b68df700) at pthread_create.c:456 [21:13:27 CET] <durandal_17> #9 0x00007ff4d821ed7f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 [21:14:21 CET] <durandal_1707> JEEB: with valgrind it doesnt crash [21:14:44 CET] <JEEB> :< [21:15:10 CET] <durandal_1707> randomly crashes at begining ^ [21:15:59 CET] <durandal_1707> guess frame threading triggers it [21:17:44 CET] <philipl> BtbN: reviewed. Looks fine [22:43:48 CET] <kierank> durandal_1707: damn, gonna be hard to fix that threading problem [23:36:31 CET] <RiCON> heh [00:00:00 CET] --- Sun Jan 28 2018

1 0

ffmpeg.log.20180127
by burek 28 Jan '18

28 Jan '18

[02:08:09 CET] <islanti> is there a command line solution to convert an aax file to multiple mp4s for each chapter? [02:29:30 CET] <M6HZ> c_14, Sequel of: "Jan 19 20:42:36 <M6HZ> c_14, I will use: curl -L '[URL]' | tee >(ffplay -) > "$(date --rfc-3339=seconds -u | sed 's/ /_/g')"_-_radio-record.mp3" [02:29:30 CET] <M6HZ> The problem happend again, but the recorded file is playable without any problem. [02:31:36 CET] <M6HZ> c_14, I will try to reproduce this result a second time to confirm the issue. [02:37:05 CET] <mainomenon> i am kind of stupid with computers. how do i add the libx265 encoder to my build of ffmpeg on macOS ? [02:43:08 CET] <kazuma_> you could just download a pre built binary mainomenon [02:43:49 CET] <kazuma_> https://ffmpeg.zeranoe.com/builds/ has mac builds for example [02:50:25 CET] <mainomenon> thank you [02:50:37 CET] <mainomenon> i got mine from homebrew and theirs doesn't have it [02:52:38 CET] <furq> mainomenon: brew install --with-x265 [02:52:41 CET] <furq> (apparently) [02:53:06 CET] <mainomenon> ah [02:53:14 CET] <mainomenon> why dont they include something like that by default? [03:08:11 CET] <youngluoyang> JOIN [03:08:16 CET] <youngluoyang> HELP [03:09:15 CET] <youngluoyang> how to use docker build ffmpeg develop environment? [10:55:47 CET] <kikobyte> BtbN, also, I guess, this initialization in ffmpeg_cuvid.c https://github.com/FFmpeg/FFmpeg/blob/master/fftools/ffmpeg_cuvid.c#L58 should be same as https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_scale_npp.c#L178, because when the context allocated in ffmpeg_cuvid.c gets into the h264_nvenc encoder, for certain resolutions it cannot be accepted by the nvidia api [10:56:22 CET] <kikobyte> Alignment and stuff [10:57:21 CET] <kikobyte> Preferably, surely, there should have been an allocator negotiation across the pipeline, where every component could have imposed its requirements on the buffer, but since it's not actually there, at least some guaranteed alignment could have been added [11:52:42 CET] <specing> Hi [11:52:55 CET] <BtbN> kikobyte, the CUDA hwframes context takes care of propper linesize-alignment itself. [11:52:57 CET] <specing> Is it possible to continue ffmpeg after it got killed? [11:53:18 CET] <specing> as in continue the last running job [11:53:41 CET] <BtbN> what scale_npp does is actually wrong. It will lead to frames with wrong dimensions which is then later has to correct [11:54:16 CET] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/hwcontext_cuda.c;h… [11:55:11 CET] <BtbN> so far I have not encountered a resolution that nvenc refused. [13:00:18 CET] <specing> I've heard that it is possible to "resume" by stiching two files together before the last keyframe in the first file [13:00:25 CET] <specing> how to do so? [13:01:59 CET] <specing> I don't know what/where the last keyframe is and -ss and -to only take time, not frames [16:52:46 CET] <onodera> Hi, will ffmpeg ever be fixed to work with libressl? [16:53:07 CET] <c_14> already has been? [16:53:08 CET] <onodera> I've seen a patch last year and I thought i'd wait till it gets merged but even master is still not building with libressl unpatched [16:53:20 CET] <c_14> was the patch not applied [16:53:22 CET] <c_14> ? [16:53:36 CET] <onodera> I tried building a few days ago [16:53:57 CET] <onodera> let me pull in master and rebuild to verify [16:57:28 CET] <c_14> There's definitely --enable-libtls [16:59:16 CET] <onodera> nope still fails, I'm talking about this patch: https://github.com/gentoo/libressl/blob/master/media-video/ffmpeg/files/ffm… [16:59:34 CET] <sfan5> that's just a workaround to make --enable-openssl compile on libressl [16:59:40 CET] <c_14> yeah [16:59:43 CET] <c_14> there's actual libtls support now [16:59:51 CET] <sfan5> but if you have libressl installed, it makes much more sense to use the "native" TLS library it provides [16:59:54 CET] <sfan5> ...which is libtls [16:59:54 CET] <onodera> hmm let me look into this [17:07:28 CET] <BtbN> You will need latest master [17:07:34 CET] <BtbN> stable branches will most likely not get it [17:46:54 CET] <tyng> ffbox0-bg.ffmpeg.org at 79.124.17.100 is unresponsive [17:49:14 CET] <JEEB> is it used for anything? [17:49:40 CET] <JEEB> since the web site works and I would guess the git is on videolan territory [17:49:48 CET] <JEEB> yup http://git.videolan.org/?p=ffmpeg.git;a=summary [17:49:54 CET] <c_14> ml maybe? [17:50:54 CET] <tyng> both ffmpeg.org and git.ffmpeg.org resolves to this server [17:51:44 CET] <c_14> it's responsive for me [17:57:32 CET] <tyng> c_14 try getting this file https://ffmpeg.org/releases/ffmpeg-3.4.1.tar.xz [17:57:56 CET] <JEEB> tyng: that's why I generally do not utilize the git.ffmpeg.org name for the git repo [17:58:19 CET] <JEEB> it's on videolan infrastructure behind it so I just point towards that [17:58:28 CET] <JEEB> and as I noted git.videolan.org seems to be OK [17:59:52 CET] <tyng> does the videolan server mirror releases too? [18:00:02 CET] <tyng> then maybe set it as the default in the download page [18:01:04 CET] <JEEB> seems like the git instance has disabled tarballs for tags [18:01:24 CET] <JEEB> but that release tarball downloads just fine for me? [18:09:22 CET] <tyng> i am getting ~2s ping ~80% packet loss and tls/http timeouts from several endpoints [18:11:00 CET] <tyng> but it seems to be fine now [18:37:33 CET] <sine0> hello folks, pardon the offtopic, but I dont know what tool I should use to do the job, this seems like one of these linux cli jobbies. I have thousands of images and I want to do a batch resize on them. what tool should I use [18:37:56 CET] <TaZeR> ffmpeg is so badass [18:38:53 CET] <JEEB> sine0: you can either use imagemagick's convert or ffmpeg [18:39:13 CET] <JEEB> see whichever fits you more [18:39:32 CET] <ddubya> has anyone coded a script or tool to track the history of every api in FFmpeg. Namely, when it was introduced, and any changes to the function signature [18:39:49 CET] <ddubya> oh, and when it was removed of course [18:40:38 CET] <sine0> JEEB: sweet. [18:40:57 CET] <JEEB> ddubya: there's an APIchanges document under doc [18:41:10 CET] <JEEB> not perfect but recent changes I think seem to have been added there [18:42:41 CET] <ddubya> Thanks, that could be useful. But I need to go waaay back. For some reason the project is stuck on FFmpeg 2.2 [18:42:48 CET] <ddubya> but still needs to work on 3.5 [18:43:14 CET] <ddubya> I guess some combination of git bisect and grep is in order [18:44:14 CET] <ddubya> apichanges seems to go back far enough but nothing about the apis I'm looking to validate [18:44:27 CET] <ddubya> avcodec_get_name and av_get_default_channel_layout [20:04:06 CET] <ddubya> it log --follow -p libavcodec/avcodec.h | grep avcodec_get_name [20:04:13 CET] <ddubya> git log --follow -p libavcodec/avcodec.h | grep avcodec_get_name [20:04:18 CET] <ddubya> ^^ [20:04:36 CET] <ddubya> for some reason that doesn't show when CodecID -> AVCodecID [20:26:19 CET] <kevinn> Does anyone know how to have avcodec_receive_frame() output in packed RGB? [20:27:31 CET] <JEEB> the output format depends on the decoder, and you will have to utilize avfilter to convert it to packed if it happens to planar (or anything else that you know can handle the conversion) [20:28:21 CET] <kevinn> Any help would be greatly appreciated! [20:28:42 CET] <JEEB> I replied to you right after you quit [20:28:47 CET] <JEEB> "the output format depends on the decoder, and you will have to utilize avfilter to convert it to packed if it happens to planar (or anything else that you know can handle the conversion)" [20:30:26 CET] <kevinn> if I do something like c->pix_fmt = AV_PIX_FMT_0RGB32; before avcodec_open2() will that output in packed RGB [20:30:43 CET] <JEEB> no [20:31:24 CET] <kevinn> okay I must be missing something then, how can I configure my decoder if not through avcodec_open2? [20:31:30 CET] <JEEB> decoding is just decoding so you get what is there in the data (for example RGB from H.264 ends up being planar as it's coded in separate planes [20:31:57 CET] <kevinn> ahh, so x264 will always be planar? [20:32:19 CET] <JEEB> decoders do not convert formats for you [20:32:30 CET] <JEEB> they give you something and then you deal with that as you require [20:32:44 CET] <kevinn> Is there anyway I can tell x264 to not use planar? [20:32:48 CET] <JEEB> no? [20:33:12 CET] <JEEB> seriously, just add the filter that converts to packed RGB? [20:33:28 CET] <JEEB> there's an example for avfilter under docs [20:33:36 CET] <JEEB> doc/examples, if I recall correctly :P [20:33:54 CET] <JEEB> avfilter is not perfect but you should get it going since you only want to convert to packed RGB [20:34:30 CET] <JEEB> another way is to utilize libp2p which is a thing that specializes on packing/unpacking (https://github.com/sekrit-twc/libp2p) [20:34:33 CET] <kevinn> well there lies the problem. avfiler code is actually pretty bad. I wrote my own conversion algorithm from planar to packed but it takes about 20 miliseconds every render cycle to run. Which is about 10 more miliseconds then I have [20:34:42 CET] <ddubya> JEEB, is swscale no good now? [20:34:52 CET] <JEEB> ddubya: avfilter uses swscale for various things, yes [20:35:06 CET] <ddubya> oic i always used it directly [20:35:24 CET] <JEEB> if it works for you like that, that's fine as well. for a newcomer "just feeding AVFrames" is simpler though [20:35:35 CET] <JEEB> which is the main point of avfilter for me [20:35:44 CET] <JEEB> it takes in AVFrames and outputs them [20:35:59 CET] <kevinn> Should I just put the planar to packed algorithm into threads or something to increase the speed? [20:36:51 CET] <ddubya> kevinn, probably not, your video decode is going to dominate most likely, that's where using multhtreaded codec will help [20:36:52 CET] <JEEB> depends. do check out libp2p as well since it's a thing specialized in (un)packing. of course I think it mostly has optimizations for x86 so if you're running on ARM that's a whole separate pain [20:37:12 CET] <JEEB> and of course one thing is to do the RGB related stuff on a GPU [20:37:19 CET] <JEEB> if the upload to VRAM is fast enough [20:38:03 CET] <ddubya> JEEB, If I use hw codec like cuvid is it simple to keep the frame in hardware and pass it to cuda for example [20:38:30 CET] <kevinn> ddubya: hmm, okay, so your suggestion is to use a multithreaded codec to increase the speed of my decode? [20:38:33 CET] <JEEB> yes, with most hw decoding APIs you have ways to keep the image in VRAM, and then you can use something like libplacebo or anything else [20:38:46 CET] <JEEB> well H.264 is already multithreaded decoding-wise :P [20:38:51 CET] <kevinn> does avcodec support multiple threads? [20:38:54 CET] <JEEB> yes [20:39:09 CET] <JEEB> as long as you have some threading primitives (posix threads or windows threads) [20:39:09 CET] <kevinn> I thought x264 is just encoding? [20:39:19 CET] <JEEB> x264 is an encoder [20:39:23 CET] <JEEB> H.264 is the format [20:39:28 CET] <kevinn> okay and can I configure that ussing avcodec_open2? [20:39:46 CET] <JEEB> yes you can control threads [20:40:30 CET] <JEEB> https://www.ffmpeg.org/doxygen/trunk/structAVCodecContext.html#aa852b6227d0… [20:40:46 CET] <JEEB> although as far as I remember lavc should kind of auto-decide on amount of threads [20:41:19 CET] <kevinn> hmm, okay I'll set thread_count and I'll see if it helps at all. [20:41:36 CET] <JEEB> you might want to look at its value after you initialize the decoder already [20:41:40 CET] <JEEB> if it's already set to something [20:41:55 CET] <kevinn> okay I will, thank you again for the help [20:42:10 CET] <kevinn> Don't know if you remember me from a few months ago ;) [20:42:18 CET] <JEEB> I have a very bad memory on things [20:42:25 CET] <JEEB> which might be a good thing [20:42:56 CET] <kevinn> ya, you started cursing at me last time c: [20:47:01 CET] <kevinn> JEEB: so I checked the value it was before and it was set to 1 [20:47:06 CET] <kevinn> and I set it to 4 [20:47:29 CET] <kevinn> it didn't get any faster but instead introduced what I can only describe as latency [20:47:33 CET] <kevinn> same effect with 2 [20:47:57 CET] <JEEB> yes, you will get latency with frame threads, d'uh [20:48:20 CET] <JEEB> you can use sliced threads if your encode has slices and the decoder supports them (H.264 does), which is not as fast but doesn't have latency [20:49:16 CET] <kevinn> okay, I'll try sliced threads, I've seen examples online. Do I have any other options on cutting down on decode time? [20:49:34 CET] <JEEB> not correct ones [20:49:47 CET] <JEEB> also as I said, in FPS frame threads are faster [20:49:58 CET] <JEEB> sliced threads will give you LESS fps [20:50:07 CET] <ddubya> kevinn, only if you have a hardware decoder (I didn't see your original post) [20:50:09 CET] <JEEB> (also as I said, the videos have to be encoded WITH SLICES) [20:50:25 CET] <JEEB> otherwise there's one slice per image [20:50:31 CET] <JEEB> and of course that doesn't thread [20:51:39 CET] <kevinn> ddubya: I unfortunately do not have a hardware decoder... am I really stuck with this 20 milisecond number? [20:52:01 CET] <kevinn> JEEB: oh okay then I definitely don't want to slice threads then [20:52:17 CET] <ddubya> kevinn, if you can't control the input files then nope [20:52:17 CET] <kevinn> is 20 miliseconds fairly standard for decode time? [20:52:31 CET] <kevinn> control input files? [20:52:34 CET] <kevinn> what do you mean? [20:52:42 CET] <JEEB> no idea, never had to compare on my machines because my stuff was always fast enough :P [20:52:47 CET] <ddubya> reformat them, reencode or whatever [20:53:02 CET] <JEEB> well, one exception being HEVC decoding on the CPU [20:53:09 CET] <JEEB> which is just not optimized because nobody cares enough [20:53:25 CET] <kevinn> ddubya: you mean there are things I can do to x264 to make it quicker to decode? [20:53:34 CET] <ddubya> sure [20:53:42 CET] <kevinn> like what!! [20:53:57 CET] <ddubya> lower the bitrate & resolution are the main things [20:54:01 CET] <ddubya> and frame rate [20:54:20 CET] <JEEB> it really depends on which is being slower for you: CABAC decoding or having more bits for the same original data [20:54:37 CET] <JEEB> tune fastdecode in x264 makes the encoder disable more CPU intensive features [20:54:56 CET] <JEEB> (but on the other hand if the bit rate goes waay up then suddenly your CAVLC decoding is the bottleneck) [20:55:26 CET] <kevinn> JEEB: will fastdecode conflict heavily with zerolatency? [20:55:41 CET] <kevinn> which is what I have set now [20:55:47 CET] <JEEB> no? [20:56:07 CET] <JEEB> also do note that zerolatency is for latency, not speed. just so you aren't misunderstanding things [20:56:08 CET] <kevinn> okay let me try that and see what happens [20:57:11 CET] <ddubya> kevinn, what speedup do you get by removing the yuv->rgb conversion.? And what is the frame used for (display? analysis ?) [20:57:35 CET] <JEEB> it seems like his content is RGB anyways [20:57:41 CET] <kevinn> JEEB: yes I know. so if I do this "zerolatency+fastdecode" it'll use both right? [20:57:50 CET] <ddubya> the point is, you might achieve your goals with YUV format, for example computer vision only needs grayscale normally [20:57:52 CET] <kevinn> ddubya: not sure, let me test that [20:57:56 CET] <JEEB> kevinn: I don't remember exactly :P [20:58:19 CET] <JEEB> kevinn: you don't have YCbCr to RGB conversion at least during decoding if your H.264 is already RGB :P [21:00:00 CET] <ddubya> another example, if you are using OpenGL it is possible to make a shader for the YUV -> RGB conversion [21:01:05 CET] <JEEB> if he doesn't have an issue with encoding RGB I don't think he will get less problems on the receiving ends by switching to YCbCr :P [21:01:39 CET] <JEEB> but yes, all sorts of stuff can be moved to GPU (p2p conversion or whatever) as long as it makes sense in the larger context [21:01:55 CET] <JEEB> how much upload and download requires in time f.ex. [21:02:13 CET] <JEEB> so if he was doing more filtering on the GPU, that would make sense [21:02:24 CET] <JEEB> just pushing it there and back doesn't often make sense [21:03:05 CET] <JEEB> of course depending on your needs having less data to decode might make sense with YCbCr :P [21:03:05 CET] <ddubya> yeah, not worth the trip to GPU for that operation [21:03:13 CET] <kevinn> JEEB: okay the fastdecode tune didn't have an effect at all [21:03:23 CET] <JEEB> too bad [21:03:23 CET] <ddubya> unless doing more work there [21:03:25 CET] <kevinn> ddubya: let me run that test you suggested now [21:03:38 CET] <JEEB> kevinn: did you make sure it disabled CABAC and instead used CAVLC? [21:03:44 CET] <JEEB> as in, the option actually got utilized [21:04:24 CET] <kevinn> JEEB: well I didn't touch those settings when configuring x264 so I assume it did right? [21:04:43 CET] <JEEB> that's one of the options tune fastdecode is supposed to modify [21:04:49 CET] <JEEB> you should see it in libx264's logging [21:04:55 CET] <JEEB> either cavlc or cabac [21:05:05 CET] <JEEB> also `strings your_encode |grep x264` [21:05:23 CET] <kevinn> okay let me confirm that... [21:05:24 CET] <JEEB> it writes out a custom SEI message with the parameters and x264 version at the beginning of the stream [21:05:31 CET] <JEEB> it's either cabac=0/1 or something else [21:05:55 CET] <JEEB> tune fastdecode is what I used when I still cared about the 1st gen Xbox :P [21:05:59 CET] <JEEB> to get SD H.264 to play [21:06:09 CET] <JEEB> (but then I got tired of re-encoding pretty darn quickly) [21:08:35 CET] <kevinn> ddubya: as for your point when I comment out the planar to packed conversion it's taking about 5 miliseconds to decode. Which is pretty darn fast. so 15 miliseconds is spent converting [21:08:52 CET] <JEEB> is this on x86 or ARM or what, btw? [21:08:54 CET] <kevinn> which leads me to believe the problem is still in the planar to packed conversion [21:09:19 CET] <kevinn> right now it is on x86, but I do intend on running on ARM eventually [21:09:21 CET] <JEEB> yea, H.264 decoding is pretty optimized :P [21:09:39 CET] <JEEB> (at least on x86, and some on ARM - although ARM in general is much slower and mostly kept up by hw decoding chips) [21:09:55 CET] <JEEB> kevinn: for x86 you might want to give libp2p a try which I linked [21:10:10 CET] <JEEB> it specializes in packed<->planar optimized conversions if I recall correctly [21:10:17 CET] <JEEB> it's by the zimg dude [21:11:01 CET] <kevinn> okay I will try that [21:11:18 CET] <kevinn> for reference here is my planar to packed algorithm [21:11:19 CET] <kevinn> https://pastebin.com/ik9HzHfF [21:11:43 CET] <kevinn> does it look like libp2p would be better [21:12:08 CET] <JEEB> quite possible [21:13:03 CET] <kevinn> oh p2p looks really easy to implement, let me give this a try [21:13:35 CET] <JEEB> yea, it's a simple thing you're meant to put into your code base according to the guy [21:13:57 CET] <JEEB> of course if that's not fast enough then you will have to start looking at what makes sense in your use case [21:14:17 CET] <ddubya> so the h.264 is actually encoded in rgb? interesting [21:14:30 CET] <JEEB> yes, it is actually encoded in BGR I think [21:14:32 CET] <kevinn> ya I am slightly worried about what I am to do if it isn't fast enough [21:14:33 CET] <JEEB> but yes, it's RGB [21:14:43 CET] <ddubya> that's a bit unusual, any reason for that? [21:14:53 CET] <JEEB> probably screen capture or something [21:14:59 CET] <ddubya> hmm [21:15:13 CET] <kevinn> JEEB is right, it is for essentially remote desktop [21:18:00 CET] <JEEB> kevinn: btw what's the final destination of the decoded picture? [21:18:34 CET] <kevinn> It's the machine watching the screen of the other machine, is that what you mean? [21:18:49 CET] <JEEB> well, stuff like "it will get rendered on screen" etc [21:18:53 CET] <JEEB> the use case, basically [21:18:54 CET] <ddubya> yeah but what GUI library or image format [21:19:33 CET] <kevinn> oh yes, well it is slightly unusual but I am rendering directly to /dev/fb0 [21:19:55 CET] <JEEB> well I've already seen opengl-on-drm so that's not even perverse [21:20:23 CET] <JEEB> (mpv got all sorts of opengl back-ends added) [21:20:42 CET] <JEEB> just wondered if you could just move the RGB data as-is planarly into the GPU and just render it there [21:21:19 CET] <kevinn> no unfortunately that won't work :( [21:21:53 CET] <JEEB> well then you have a problem [21:22:22 CET] <kevinn> you don't think p2p will help? [21:22:30 CET] <JEEB> no, just if that fails [21:22:46 CET] <JEEB> although there are some ways you can still get your head further into the chaos [21:22:48 CET] <kevinn> ahh, well I am praying that it will work [21:23:05 CET] <kevinn> how so? [21:24:12 CET] <JEEB> like writing special SIMD for all architectures, or praying that decoding of H.264 can be made so that it outputs into a single buffer instead of separate ones, or you switch to 4:2:0 YCbCr and pray that the dumb fbdev you're pushing stuff into supports planar 4:2:0 YCbCr [21:24:25 CET] <JEEB> all of those three are possibilities [21:25:25 CET] <kevinn> okay let me finish up libp2p first before I think about those ;) [21:30:34 CET] <kevinn> JEEB: hey a few questions on libp2p [21:31:06 CET] <kevinn> so in p2p_api.h there this line: typedef void (*p2p_pack_func)(const void * const src[4], void *dst, unsigned left, unsigned right); [21:31:31 CET] <kevinn> does the const void * const src[4] mean that it can only pack 4 bytes at a time? [21:31:40 CET] <kevinn> as in I'd have to do each individually? [21:31:53 CET] <GyrosGeier> four void pointers [21:32:07 CET] <JEEB> it means it wants four pointers [21:32:08 CET] <kevinn> jesus [21:32:13 CET] <kevinn> of course [21:32:27 CET] <JEEB> (since generally planar formats have up to four planes) [21:32:48 CET] <kevinn> and what does unsigned left and right mean? [21:32:52 CET] <kevinn> what does it want? [21:33:16 CET] Action: GyrosGeier suspects that these are different planes than what we do on Amiga [21:35:48 CET] <kevinn> JEEB: what is left and right? [21:36:02 CET] <kevinn> do you know? [21:37:07 CET] <ddubya> kevinn, I'm just farting around here, but maybe this function is better that what you had: https://pastebin.com/qK9kHFr3 [21:37:21 CET] <ddubya> *totally untested and not compiled* [21:38:13 CET] <kevinn> ddubya: what does __restrict do! I've never seen it before [21:38:34 CET] <JEEB> kevinn: not sure but the tests seem to be calling the latter with stuff https://github.com/sekrit-twc/libp2p/blob/master/main.c#L21 [21:38:46 CET] <JEEB> I can ask the author [21:39:26 CET] <DHE> https://en.wikipedia.org/wiki/Restrict This seems related? [21:39:28 CET] <kevinn> JEEB: I will just use 0, 2 like the author does. thanks again [21:39:38 CET] <ddubya> kevinn, it tells compiler that pointer types with the same type can't point to the same memory [21:40:17 CET] <JEEB> he uses 0, 2 for rgbx_be but then rgb24_le|be has 0, 1 [21:40:34 CET] <kevinn> it's an optimization thing, okay I see, let me try that too, thank you again for all the help ddubya [21:43:34 CET] <JEEB> < Arwen> JEEB, left/right offset [22:07:01 CET] <stsbqm> Hi! [22:10:21 CET] <stsbqm> -c:a flac -sample_fmt s24 :: Invalid sample format 's24' [22:10:24 CET] <stsbqm> -c:a flac -sample_fmt s32 :: [flac @ 0x55b061c63e60] encoding as 24 bits-per-sample [22:10:31 CET] <stsbqm> Is there an explanation for this? [22:13:03 CET] <JEEB> stsbqm: there is no separate sample format for 24bit, instead 24bit is internally handled as 32bit with the coded_bits (I think) set 24 [22:13:24 CET] <DHE> I think it's related to the fact that the compiler doesn't have a good data type for 24 bits [22:13:27 CET] <JEEB> so it means in the framework "this is a 32bit sample, but actually utilized in it are 24bit" [22:15:05 CET] <stsbqm> That's confusing. But okay, ty. [22:15:31 CET] <JEEB> DHE: that in theory could have been handled with a separate 24bit sample format which would have been in many ways exactly the same as 32bit [22:16:53 CET] <DHE> I guess.. that's what 9-bit and 10bit h264 use for example (with 16 bit data types) [22:48:32 CET] <BtbN> Can ffmpeg "decode" a Dolby Pro Logic (II) signal? [22:51:19 CET] <JEEB> depends on what you mean, but there was a filter mentioning that if I recall correctly [22:58:45 CET] <BtbN> You can produce it, aresample has support for it. [22:58:50 CET] <BtbN> But I can't find anything to consume it [23:02:21 CET] <durandal_1707> surround filter [23:03:41 CET] <BtbN> That can take Pro Logic? [23:04:00 CET] <BtbN> The documentation is a bit barren then [23:23:35 CET] <mkdir_> Yo 2chainz [23:23:40 CET] <mkdir_> what's up woodward [23:24:02 CET] <mkdir_> Idk spectograms [23:24:07 CET] <mkdir_> I gotta learn spectogram [23:24:10 CET] <mkdir_> How I do dat? [23:25:50 CET] <mkdir_> Sharkigator [23:25:52 CET] <mkdir_> sup [23:29:40 CET] <mkdir_> mete, hi [00:00:00 CET] --- Sun Jan 28 2018

1 0

ffmpeg-devel.log.20180126
by burek 27 Jan '18

27 Jan '18

[00:01:18 CET] <jkqxz> Ok, thank you. [00:02:24 CET] <cone-091> ffmpeg 03Mark Thompson 07master:74cf4a75f74e: ffmpeg: Ignore SIGPIPE [00:15:32 CET] <wm4> on that note, I'm not actually interested in the drama, and if my reply to michaelni was too harsh/unfriendly, I apologize [00:16:44 CET] <cone-091> ffmpeg 03Jun Zhao 07master:658ac0672f46: lavfi/procamp_vaapi: fix the green video issue if without arguments. [00:16:45 CET] <cone-091> ffmpeg 03Jun Zhao 07master:4e6e1e5350b7: lavfi/misc_vaapi: use default value setting if without arguments. [00:26:15 CET] <wm4> huh I didn't realize we have a hls protocol [00:26:27 CET] <wm4> though it says you should use the hls demuxer instead [00:26:51 CET] <nevcairiel> yeah its old [00:27:00 CET] <wm4> it's only 300 lines, wonderfully simple [00:27:11 CET] <wm4> the demuxer is 2300 lines [00:27:45 CET] <jamrial> hls demuxer got a lot of development recently. half of those ~2300 lines are probably less than a year old [00:28:54 CET] <nevcairiel> its simple because it barely supports any of it [00:31:56 CET] <wm4> sure [00:32:43 CET] <nevcairiel> thats probably because hls was still relatively simple back in the days [00:32:53 CET] <nevcairiel> it got expanded with dumb features over the years [00:33:04 CET] <nevcairiel> what was wrong with mpegts segments, noo, had to force fMP4 into that [00:33:30 CET] <nevcairiel> fMP4 is only the most hackish streaming format ever invented [00:33:34 CET] <wm4> Libav's hls.c (basically didn't get any of the recent changes) is only 860 lines [00:33:45 CET] <wm4> hey still better than dash [00:33:59 CET] <nevcairiel> dash is xml, thats just always worse [00:34:00 CET] <wm4> which is a comical xml nightmare [00:40:28 CET] <klaxa> wow, i didn't know hls got mp4 now [00:40:49 CET] <klaxa> i've only hacked hls stuff when i didn't even know what it was, like 2014 or so [00:40:51 CET] <wm4> jkqxz: wow you got the worst possible reply from nicolas [01:02:22 CET] <nevcairiel> i'm pretty sure he referred to "lurks" instead of the nickname, but who knows at this point, not like thats an offending term in any way [01:04:30 CET] <wm4> eh [01:05:15 CET] <nevcairiel> there is even a wikipedia article to explain it =P [01:05:17 CET] <wm4> anyway trying to figure out what exactly CE is offended by is increasingly a guessing game [01:06:56 CET] <Chloe> did the irc meeting which occured a while ago help anything? [01:06:59 CET] <Chloe> we could try do that again [01:07:38 CET] <jamrial> no, and no [01:07:50 CET] <nevcairiel> those things barely ever help anything [01:08:29 CET] <wm4> CE also just mailed me this: Bist Du wirklich so bescheuert? [01:08:29 CET] <wm4> Die Mailing list admins glauben, Du bist krank und man kann [01:08:29 CET] <wm4> nichts dagegen tun. Ich glaube das eigentlich nicht, aber nach [01:08:29 CET] <wm4> diesem Email frage ich mich, ob sie recht haben? [01:08:54 CET] <wm4> that's pretty funny [01:08:55 CET] <jamrial> i could use a translation :p [01:09:06 CET] <nevcairiel> its basically a bunch of insults [01:09:22 CET] <wm4> it also says the mailing list admins think I'm "sick" [01:09:30 CET] <wm4> as in sick in the head [01:11:04 CET] <jamrial> ml admins, as in llogan and Compn? [01:11:31 CET] <wm4> probably [01:11:42 CET] <jamrial> also, google translate handled that really well [01:11:52 CET] <TimothyGu> lol more CE bs [01:11:58 CET] <TimothyGu> when is this going to end [01:12:57 CET] <wm4> it was sort of funny but I think it's going a bit too far now [01:13:47 CET] <JEEB> yes, multiple people have been rather insulting at each other, but it's no reason to level-up it [01:14:18 CET] <JEEB> (or well, not insulting but what's the right word...) [01:14:26 CET] <klaxa> flaming? [01:14:35 CET] <JEEB> just generally WORD [01:19:10 CET] <TimothyGu> read the archives. same old same old [01:20:04 CET] <JEEB> yes, it's unfortunately not new [01:31:27 CET] <JEEB> wm4: btw are you sure it was http that had timeout? [01:31:39 CET] <JEEB> http.c didn't have a timeout AVOption (couldn't find string) [01:31:47 CET] <JEEB> is it on the tcp protocol level? [01:32:10 CET] <JEEB> ah, yes [01:32:13 CET] <JEEB> there it is :) [01:33:44 CET] <wm4> yes, I think strictly speaking it's tcp, and it's passed down the protocol chain [01:34:28 CET] <JEEB> yea, I just wanted to link the specifics for some reason into my reply :P [01:34:38 CET] <JEEB> (I should really be sleeping) [01:34:52 CET] <wm4> uh I should verify whether it really works [01:37:41 CET] <JEEB> ok, udp is also microseconds with timeout [01:38:47 CET] <wm4> ok looked how it actually works, and it's due to explicitly passing the options AVDictionary down the protocol chain [01:39:12 CET] <wm4> and for subsequent connections (like when seeking) it even keeps a copy of the original options dict, so that the options stick [01:41:25 CET] <JEEB> yup [01:46:10 CET] Action: JEEB posts [01:48:45 CET] <kierank> JEEB: as if a thread on a nonrealtime os can do microsecond precision timings [01:49:40 CET] <JEEB> kierank: that wasn't the point, the point was that changing the name of an option brings it in line with another protocol's option [01:49:44 CET] <kierank> i know [01:50:33 CET] <JEEB> so we have RTSP/UDP/TCP at least with a similar socket-based "timeout" option that takes in microseconds [01:50:52 CET] <JEEB> whether or not microseconds are correct for this... (Ž4@) [01:51:17 CET] <JEEB> but this change was just regarding renaming of options, where the type just happened to even match between multiple protocols after it [01:54:02 CET] <JEEB> of course, if the change of option types (which seemed to be the primary concern for most people who commented) is deemed critical enough, then that can be done as well, although I'm not sure if it should be stuck together with the initial option renaming. [01:57:27 CET] <wm4> yeah I don't think finer than microseconds is needed [01:57:49 CET] <JEEB> if there's a fancier type than just INT [01:57:55 CET] <JEEB> (which all timeouts currently are) [01:57:56 CET] <wm4> if you need timeouts smaller than a microsecond you're probably doing some hardcore realtime stuff, and certainly not in libavformat [01:58:19 CET] <JEEB> they can be switched together at some point as a general timeout clean-up [01:59:58 CET] <wm4> also these timeouts are usually used for rather coarse user settings (or just to prevent scripts from getting stuck), so even a resolution as low as 100ms would be fine [02:00:09 CET] <JEEB> yes [02:00:15 CET] <wm4> not the mention that libavformat's polling reduces the resolution anyway [02:00:36 CET] <JEEB> but personally I'm not going to touch that side of it, since that's a whole separate bikeshed [02:01:54 CET] <wm4> ah yeah, the poll() call is always done with a fixed 100ms timeout [02:02:12 CET] <wm4> so the timeout option effectively has a resolution of 100ms [02:02:32 CET] <rcombs> I do think it being in microseconds when everything else is (possibly decimal) seconds is weird [02:04:10 CET] <rcombs> AV_OPT_TYPE_DURATION [02:04:25 CET] <JEEB> yes, that part I actually most agreed with [02:04:36 CET] <JEEB> that the types (option ones) could be normalized [02:05:07 CET] <wm4> feel free to Change Everything for that but I won't [02:05:11 CET] <rcombs> not sure how to do that without immediately breaking compat, though [02:05:19 CET] <rcombs> I mean, you could use a different name [02:05:22 CET] <JEEB> oh yea, bw compat will go derp [02:05:28 CET] <JEEB> unless you want a new option [02:05:31 CET] <wm4> I only wanted to get rid of the stupid rtsp special case [02:05:34 CET] <rcombs> but there isn't really a better name available than "timeout" [02:05:34 CET] <JEEB> yes [02:06:28 CET] <JEEB> the rename is a step to the right direction and the next step can be taken if we are still in the mood of breaking AVOption bw compat [02:06:52 CET] <JEEB> (but it's a separate larger piece of work that requires git grepping for all time-related AVOptions to bring them all in line) [02:07:11 CET] <JEEB> (or just even starting with timeouts) [02:08:28 CET] <rcombs> just sucks for anyone currently using them in a script [02:08:46 CET] <JEEB> yes [02:08:59 CET] <rcombs> I guess for timeouts you could cheat and assume any absurdly large value was meant to be microseconds, and warn about it and divide [02:09:30 CET] <JEEB> also I loved one of the options being in milliseconds, just to be different from both seconds and microseconds [02:09:41 CET] <rcombs> lol [02:09:44 CET] <JEEB> of which microseconds was utilized for the normal socket timeout [02:09:51 CET] <rcombs> AV_OPT_TYPE_DURATION is AV_TIME_BASE, right? [02:09:59 CET] <JEEB> I think so [02:10:11 CET] <JEEB> or was it a rational thing? [02:11:01 CET] <rcombs> nah it's microseconds [02:11:07 CET] <JEEB> yea [02:11:11 CET] <JEEB> just checked some of my older code [02:11:15 CET] <wm4> the best idea I came up with was interpreting "timeout" as the actual timeout (and in ms) if "listen_timeout" is also set [02:11:22 CET] <kierank> wm4: I reckon you can do +- 500us at best on a standard machine [02:11:25 CET] <wm4> but, too much effort [02:11:29 CET] <JEEB> which (ab)used av_parse_time() [02:12:14 CET] <rcombs> so yeah, you could change them all to AV_OPT_TYPE_DURATION, then check if the value is e10000*AV_TIME_BASE, for instance [02:12:23 CET] <rcombs> and warn and divide by 1000000 [02:13:18 CET] <JEEB> anyways, sleep taimu [02:13:54 CET] <wm4> that seems like a bad idea [02:14:35 CET] <wm4> wait what is AV_TIME_BASE at all [02:14:51 CET] <wm4> hm microseconds [02:15:07 CET] <rcombs> yeah, so there'd be no change to existing code that actually _uses_ the value [02:15:25 CET] <wm4> so why the comparison you mentioned? [02:15:46 CET] <wm4> oh, TYPE_DURATION would still assume seconds for normal input numbers [02:15:49 CET] <rcombs> currently to specify e.g. 5 seconds, you pass 5000000 [02:15:51 CET] <rcombs> yeah [02:16:02 CET] <rcombs> so this would let you pass 5 [02:16:22 CET] <rcombs> 5 would produce 5000000, and 5000000 would produce 5000000000000 [02:16:24 CET] <wm4> I still don't think this would be a good idea for a compat hack [02:16:44 CET] <rcombs> I'm not _super_ sold on it but as compat hacks go it's relatively clean [02:17:05 CET] <rcombs> since the range of reasonable timeouts is way smaller than the 6 orders of magnitude of difference here [02:17:19 CET] <wm4> couldn't it just default to microseconds if there's no unit given [02:17:19 CET] <rcombs> so you could very confidently tell when a value was intended for the old thing [02:17:26 CET] <wm4> then it'd be perfectly compatible [02:17:37 CET] <rcombs> does TYPE_DURATION even do units? [02:17:53 CET] Action: rcombs checks [02:17:54 CET] <wm4> (not that I'd see any reason to change this... if ffmpeg CLI usage is too inconvenient, the CLI can do the translation) [02:18:14 CET] <rcombs> it does not [02:18:34 CET] <wm4> anyway this is still nothing but bikeshed since the rtsp option not only has a different unit, but completely different and incompatible semantics [02:19:02 CET] <rcombs> API usage would stay the same unless you were passing a string already [02:20:34 CET] <wm4> protocols use AVDictionary to pass in options, which are always strings [02:21:08 CET] <rcombs> I mean if you were using, say, av_opt_set_int [02:22:29 CET] <wm4> AFAIK you can't even use that with protocols [03:12:00 CET] <Compn> wat [03:34:02 CET] <rcombs> has http://fatebeta.ffmpeg.org/report/aarch64-linux-qemu-ubuntu-gcc-4.8/2018012… been broken since 0a24d7ca831b85db18593e5f18d765adb40e5cd9 [03:35:32 CET] <rcombs> it's complaining about "fcmeq v7.4S, v3.4S, #0.0" [03:35:54 CET] <rcombs> I don't know nearly enough arm to tell what any of that means [03:44:03 CET] <jamrial> rcombs: poke matthieu [03:44:17 CET] <rcombs> does he IRC [03:44:24 CET] <jamrial> i don't know [03:47:38 CET] <jamrial> rcombs: maybe https://sourceware.org/ml/binutils/2014-02/msg00148.html [03:48:15 CET] <rcombs> hmm, so maybe I need a new assembler on this CI [03:48:18 CET] <rcombs> and so does fate [03:49:00 CET] <jamrial> how old is binutils? [03:49:23 CET] <jamrial> try to change that to #0.0 to #0, see if it helps [03:52:37 CET] <rcombs> 2.24 [03:52:51 CET] <rcombs> it's an android toolchain [03:52:56 CET] <cone-078> ffmpeg 03Karthick Jeyapal 07master:0df9d0f4cbcb: avformat/dashenc: Fix a resource leak when http persistent in enabled [03:52:56 CET] <cone-078> ffmpeg 03Karthick Jeyapal 07master:18e2ac032e9d: avformat/dashenc: Signal http end of chunk(http_shutdown) explicitly [03:52:57 CET] <rcombs> (>android) [03:53:00 CET] <rcombs> I'll try it [03:57:36 CET] <jamrial> guess that fix was never backported to 2.24 as mentioned in that patch, and it's only in >= 2.25 [04:44:34 CET] <jamrial> rcombs: cool, can you send a patch? [04:45:15 CET] <rcombs> jamrial: sent [09:42:17 CET] <cone-380> ffmpeg 03Rodger Combs 07master:77237504757b: lavc/aarch64/sbrdsp_neon: fix build on old binutils [14:01:21 CET] <thardin> can ffmpeg do palette + dither these days? [14:15:05 CET] <sfan5> like this? http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html [14:20:04 CET] <thardin> yes found something similar [17:22:34 CET] <atomnuker> durandal_1707: https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2018?action=diff&versi… [17:33:06 CET] <cone-380> ffmpeg 03Rodger Combs 07release/3.4:ad85d9af13db: lavc/aarch64/sbrdsp_neon: fix build on old binutils [18:11:54 CET] <tmatth> atomnuker: would it make sense to add PLC to one or both of ffmpeg's libopus decoder or native opus decoder? [18:16:25 CET] <atomnuker> its not straightforward [18:16:57 CET] <atomnuker> packet loss implies total packet loss and not just a corrupted packet, right? [18:17:42 CET] <atomnuker> I think the simplest and non-hacky way to do this would be to use lavfi [18:19:04 CET] <atomnuker> with a filter which is forced to run in real time and checks the pts on every input packet and if it drifts more than the max frame size would apply plc [18:19:38 CET] <durandal_170> atomnuker: yes!, i am qualified as student for gsoc [18:19:40 CET] <atomnuker> though I think this should belong in the user, unless durandal_1707 has any ideas how to [18:24:52 CET] <durandal_170> write simd for lut3d filter [18:25:28 CET] <tmatth> atomnuker: total packet loss yeah [18:26:09 CET] <kierank> atomnuker: unless you use a special protocol packets are either there are not [18:27:22 CET] <atomnuker> yeah, and no packets -> no frames [18:29:19 CET] <kierank> well if you buffer and lose a single packet you can hide [18:33:43 CET] <tmatth> IIRC opus_demo buffers by one packet to demonstrate PLC as well as FEC [19:33:02 CET] <KGB> [13FFV1] 15michaelni closed pull request #89: Replace color space wording by more adapted transformation wording (06master...06transformations) 02https://git.io/vNvVm [20:12:32 CET] <BtbN> Are those unversioned files like "libavfilter/opencl/overlay.c" auto-generated? [00:00:00 CET] --- Sat Jan 27 2018

1 0

ffmpeg.log.20180126
by burek 27 Jan '18

27 Jan '18

[00:11:29 CET] <zerodefect> So I see there is a 'av_buffersrc_parameters_set(..)' method. Does what it says on the tin. [00:11:33 CET] <zerodefect> :) [00:12:08 CET] <zerodefect> It's times like this where I wish I was more familiar with the API [00:13:35 CET] <zerodefect> JEEB: It look like I'm at that point where you once were. [02:45:23 CET] <lindylex> I am having trouble slicing this video. This is the info about the video : https://pastebin.com/sR5xrAMU This is my command : ffmpeg -i l3.mov -vcodec copy -acodec copy -ss 00:00:05.000 -t 00:00:11.000 l4.mov This is the file : http://mo-de.net/d/l3.mov [02:47:06 CET] <lindylex> I meant this is my command : ffmpeg -i l3.mov -vcodec copy -acodec copy -ss 00:00:05.000 -to 00:00:11.000 l4.mov [02:49:14 CET] <fella> with *codec copy you can only cut at full frame boundaries - if that's your question [02:50:33 CET] <lindylex> I am sking why does it not cut at the seconds I want it to. I think it is the video file. It works for other video files. [02:52:01 CET] <fella> you have full frames/images ( also called I-Frames ) and other frames which are derived from those full frames [02:52:19 CET] <fella> the occur only every 10sec or so [02:52:38 CET] <fella> and with -vcodec copy you can only cut at those bondaries [02:52:48 CET] <fella> they occur [02:53:41 CET] <lindylex> How do I fix this? [02:54:36 CET] <fella> change '-vcodec copy' to '-vcodec libx264 -preset fastest' and '-acodec copy' to '-an' [02:54:45 CET] <fella> ^^ for testing - to see if it works [02:56:48 CET] <lindylex> This ffmpeg -i l3.mov -ss 00:00:05.000 -to 00:00:11.000 -vcodec libx264 -preset fastest -an l4.mov Gives me this error : Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [02:57:25 CET] <lindylex> I changed it to this ffmpeg -i l3.mov -ss 00:00:05.000 -to 00:00:11.000 -vcodec libx264 -preset ultrafast -an l4.mov [02:57:34 CET] <lindylex> One sec let me test. [02:58:08 CET] <fella> -t EN:DT:IM.e, not -to ! [02:59:26 CET] <lindylex> -to works better because I do not have to do any calculations. [02:59:32 CET] <lindylex> Thanks it worked. [02:59:56 CET] <fella> kk [03:10:56 CET] <jasom> I'm trying to IVTC some video; -vf pullup seems to drop 2x as many frames as expected (it reliably produces ~12000/1001 FPS output on telecined video) [03:26:07 CET] <jasom> ah, nevermind my test video was already deinterlaced; on actual TC content it seems to work. [03:32:08 CET] <kazuma_> had 3 crashes today with zeranoe's nightly build [03:32:25 CET] <kazuma_> before that, i don't think i've ever had an ffmpeg crash [03:57:24 CET] <mkdir_> Hello [03:59:18 CET] <mkdir_> stevenliu, a question? [04:01:37 CET] <stevenliu> [04:01:49 CET] <stevenliu> What's happen? [04:02:43 CET] <mkdir_> I'm trying to convert my ogg to .wav, but I am getting a strange threshold cutoff [04:02:50 CET] <mkdir_> viewing the spectogram it becomes apparent [04:06:29 CET] <stevenliu> how can is reproduce it? [04:06:38 CET] <stevenliu> how can i reproduce it? [04:08:17 CET] <mkdir_> ffmpeg -i myOgg.ogg myOgg.wav [04:08:34 CET] <stevenliu> I don't have ogg file :( [04:08:39 CET] <mkdir_> I have a python script to plot the wav as a spectogram [04:08:51 CET] <mkdir_> http://shtooka.net/search.php?str=cat&lang= [04:08:52 CET] <mkdir_> acat [04:08:57 CET] <mkdir_> a cat [04:09:44 CET] <stevenliu> Can you give me a wget link? [04:10:08 CET] <mkdir_> what is a wget link? [04:10:50 CET] <mkdir_> ooh [04:10:51 CET] <mkdir_> one moment [04:10:54 CET] <mkdir_> I will do that [04:10:56 CET] <mkdir_> my guy [04:11:57 CET] <mkdir_> http://packs.shtooka.net/eng-balm-judith/ogg/eng-a35d9c64.ogg [04:46:52 CET] <mkdir_> stevenliu, still there buddy? [04:47:12 CET] <stevenliu> I Cannot reproduce it [04:48:06 CET] <stevenliu> http://bbs.chinaffmpeg.com/out.wav [04:48:09 CET] <stevenliu> try this please [04:48:31 CET] <stevenliu> ffmpeg -i eng-a35d9c64.ogg out.wav [04:48:38 CET] <stevenliu> ffmpeg version N-89672-g41e51fbcd9 Copyright (c) 2000-2018 the FFmpeg developers [04:51:19 CET] <mkdir_> out.wav has the cutoff [04:53:15 CET] <mkdir_> Maybe I should try vorbis... [04:53:33 CET] <mkdir_> you may need my script to see the cutoff [04:53:38 CET] <mkdir_> are you looking at the spectogram? [07:36:00 CET] <himawari> I am splitting video files using the ffmpeg stream segmenter. [07:36:01 CET] <himawari> Some of the segments won't play. When I use ffprobe on the offending video files, I noticed the start time is after the duration. Could the incorrect start time be the cause of the problem? [07:36:46 CET] <himawari> my segmenting command: ffmpeg -i movie.mp4 -an -map 0 -segment_time 8 -f segment out.mp4 [07:38:47 CET] <himawari> actually out_%03d.mp4 [07:39:01 CET] <himawari> there seem to be no warnings or errors when splitting [07:40:41 CET] <Johnjay> any idea how much louder I can make this mp3 file? [07:40:54 CET] <Johnjay> i'm at 5x volume. not sure what typical pc speakers can tolerate [07:41:19 CET] <Diag> ...? [07:41:29 CET] <Diag> its not the speakers [07:42:02 CET] <Diag> pcm is only 16 bit usually so you literally get +-32768 [07:42:08 CET] <Diag> you cant go above that [07:42:10 CET] <himawari> Audio files have a limit to how loud they can get. Anything past that limit will just clip [07:42:19 CET] <Johnjay> ok. but i don't want to damage the speakers on my pc when i play it back [07:42:23 CET] <Johnjay> ok [07:42:29 CET] <Diag> you cant....... [07:42:34 CET] <himawari> If you want to make it sound louder you can use a limiter to boost the volume while keeping it from clipping [07:42:56 CET] <Johnjay> i'm just using the volume filter on ffmpeg right now [07:43:15 CET] <Johnjay> how would I use a limiter in ffmpeg? [07:44:14 CET] <Diag> Johnjay: himawari is only partially right with a limiter, dynamic range is shit in audio nowadays anyways [07:44:20 CET] <Diag> youll likely not gain much from a limiter [07:45:29 CET] <Johnjay> well i know very little about audio engineering anyway [07:45:36 CET] <Johnjay> so half of the ffmpeg filters are greek to me [07:45:38 CET] <himawari> Johnjay: check this out https://superuser.com/questions/323119/how-can-i-normalize-audio-using-ffmp… [07:45:38 CET] <Diag> ok well basically [07:45:54 CET] <Johnjay> thanks mr. sunflower san [07:45:58 CET] <Diag> a limiter will just try to keep the amplitude the same [07:46:10 CET] <Diag> So itwont duck and it wont clip [07:51:33 CET] <furq> !filter volumedetect @Johnjay [07:51:33 CET] <nfobot> Johnjay: http://ffmpeg.org/ffmpeg-filters.html#volumedetect [07:51:50 CET] <furq> run that and then amplify it by max_volume [08:02:02 CET] <himawari> I figured out the answer to my own question! Adding the option '-reset_timestamps 1' fixed it [08:03:12 CET] <Johnjay> oh nice [08:03:13 CET] <Johnjay> thanks [08:15:14 CET] <m712> hi, is there a way I can shift the subtitles of a video when using the subtitles filter? I'm trying to cut a segment from a video file with the subtitles burned. ffmpeg -ss 00:16:05.00 -to 00:16:45.00 -i my_vid.mkv -vf subtitles=my_vid.mkv -c:v libx264 -b:v 600K -c:a libmp3lame -b:a 128K out.mp4 [08:15:49 CET] <m712> this starts the subtitles from the beginning instead of from the segment i want [08:45:22 CET] <FishPencil> Does x265/x264 CRF mean constant quality on an external scale, or is it related to the input stream? Basically, is there any CRF value (other than 0), that would result in no visual quality loss after 1000s of reencodes? [08:59:57 CET] <kerio> i doubt there's an idempotent h264 encoder out there [09:04:41 CET] <FishPencil> So they're all just relative quality from the source [09:11:47 CET] <kerio> both crf and qp try to achieve constant quality, using two different metrics [09:12:17 CET] <kerio> keyword being try [09:14:48 CET] <FishPencil> I guess a broader question would be: if I want to retain a video with minimal to no quality loss (but don't want to use FFV1), what crf value for x265 is good? I need to filter the video, so I can't just copy it [09:16:08 CET] <FishPencil> What would be considered "safe", like -crf 18 was for x264 I believe [10:33:43 CET] <dradakovic> I have a quetion regarding the -re option. I am converting live online radios into mpegts. In order for radios to work fine i specificall have to have the -re option, else they are choppy. [10:34:13 CET] <dradakovic> Is there a better alternative to -re as some radios still get choppy after few hours and i need to reconnect to them again [10:34:34 CET] <dradakovic> my pastebin for 1 radio https://pastebin.com/L3CjYSf1 [10:34:50 CET] <dradakovic> When i reconnect to the radio, the choppiness is gone [10:36:43 CET] <dradakovic> I have about 30 radios and this thing happens on lets say 5 or 6 of the radios [10:37:16 CET] <dradakovic> If i remove the -re option, the choppiness is present on all the radios as it causes the packets to flow too fast to my device [10:39:25 CET] <dradakovic> Maybe this will be a better pastebin https://pastebin.com/XbU3Ve8c [11:00:52 CET] <dradakovic> Or better question, how do i make sure that radio outputs always at the 1x speed? [11:01:46 CET] <JEEB> you can limit the udp and mpegts outputs, read upon the documentation with regards to their options [11:02:14 CET] <JEEB> and yes, -re is a hack although usually it fails the other way (you get a timestamp jump to 8h in the future and your ffmpeg.c is going to be sitting there :P) [11:05:48 CET] <dradakovic> Would you have any recommendation options on what to try? I have been playing with various options for months now and this code is the best i could come up with [11:07:25 CET] <dradakovic> I mean it seems like i need -re. But it also looks like it stops working for specific radios after some time and they act like there would be no -re present. [11:16:52 CET] <dradakovic> Or what would be the first thing you would change, for udp packets not to cause overflow? [11:41:17 CET] <XoXFaby> why/how does rendering 100mb of frames into a 11mb video file end up using 1.5gb of RAM? [11:42:11 CET] <pmjdebruijn> presumably a bunch of frames need to be in memory uncompressed ? [11:42:15 CET] Action: pmjdebruijn is just guessing [11:58:27 CET] <DHE> I'm guessing libx264. look-ahead buffers a lot of frames and 1920x1080 in decompressed format is pretty big [12:08:20 CET] <fdsfds> when I save rtsp strem to 264 file i get error malloc of size ... failed, why? [12:08:33 CET] <fdsfds> ffmpeg -i rtsp://...... test.264 [12:11:48 CET] <DHE> if the source is already h264, you should use -c copy [12:20:33 CET] <fdsfds> DHE: even my source is mjpeg i got this error [12:42:12 CET] <steinchen> hi all [12:42:43 CET] <steinchen> i want to build a very simple streaming sollution to view all videos in a specific folder.. but i have no idea where to start [12:43:00 CET] <steinchen> server is running lamp and ffserver etc [12:55:30 CET] <BtbN> ffserver is dead, don't use it. [13:08:07 CET] <fdsfds> BtbN: witch server is rocommmended that working with ffpmpeg? [13:08:31 CET] <fdsfds> and can stream via most of protocols?(mjpeg/rtsp(tcp ond udp) [13:31:14 CET] <DHE> fdsfds: nginx-rtmp is what we're recommending users consider [13:51:22 CET] <fdsfds> DHE: nginx-rtmp working with ffmpeg? can i do ffmpeg -i (some input) and send it directli to nginx-rtmp ? like i did with ffserver? [13:51:37 CET] <furq> yes [13:51:57 CET] <fdsfds> with with protocols is supported ? [13:52:08 CET] <fdsfds> mjpeg/rtsp(tcp ond udp) [13:52:25 CET] <DHE> I don't think it cares about the codec [13:53:18 CET] <fdsfds> that now codec , that streaming protocols [13:53:28 CET] <fdsfds> that not * [13:55:02 CET] <DHE> mjpeg is a codec [13:55:52 CET] <fdsfds> it codec+ streaming protocol [13:58:44 CET] <fdsfds> i not see that nginx-rtmp can streaming with rtsp udp and rtsp tcp , too bad, ffserver cand do it ... [14:14:44 CET] <XoXFaby> DHE: any suggestion for helping not use as much RAM> [14:15:08 CET] <XoXFaby> I need to render 30 to 250, depending on how long I want my clips to be, rendered on a raspberry pi [14:29:13 CET] <steinchen> mmh isit possible what im planning? to stream all videos from a specific folder? and also if new files are added or removed.. [15:05:05 CET] <buzzing> Hey everyone. I would like to merge several video files with the same codec into one. But I would like x seconds of black between them and a y frames/seconds long audio fade at the beginning and end of each video. How do I do this with ffmpeg? :-) [16:10:28 CET] <kepstin> buzzing: by writing fairly long and complicated filter chains. You'll probably want a script that'll generate temp files with the fade-in/out applied, then generate some segments of silent/black video, then concatenate everything together. [16:11:32 CET] <kepstin> note that there'll be some scripting involved in particular to do the audio fade-out, since none of the filter support anything like "y seconds before the end of the video" - so you have to pre-calculate the timing. [16:36:57 CET] <buzzing> Thanks kepstin. I'll look into it :-) [16:40:59 CET] <Daglimioux> Hey there. I'm doing a compilation with this command: ffmpeg -i video1.webm -i video2.webm -f lavfi -i color=s=640x360:color=black:d=1 -i video3.webm -i audio1.opus -i audio2.opus -i audio2.opus -filter_complex "amix=inputs=3:dropout_transition=0; [0:v] scale=640x360, setdar=0 [r1c1]; [1:v] scale=640x360, setdar=0 [r1c2]; [3:v] scale=640x360, setdar=0 [r2c2]; [r1c1][r1c2] hstack=2 [r1]; [2][r2c2] hstack=2 [r2]; [r1][r2] vstack=2" [16:41:01 CET] <Daglimioux> libx264 -b:v 300k -crf 20 -threads 2 -f mp4 -preset ultrafast -y output.mp4 [16:42:42 CET] <Daglimioux> but my problem is that one of those videos (video2.webm) is missing a "frame" at 00:00:26 and produces an output that freezes all videos at second 26. Is there a way to fix that? [16:48:34 CET] <kepstin> hmm. the framesync code in hstack/vstack should allow it to keep showing frames from other videos. [16:48:43 CET] <kepstin> that's really odd. [16:49:49 CET] <ddubya> is avcodecdescriptor_get the replacement for CodecContext->codec_name ? [16:50:58 CET] <ddubya> or is avcodec_get_name better [16:52:38 CET] <storrgie> I've got a decklink device in linux that I'm trying to record video/audio from... the example in the ffmpeg documentation has `-format_code Hi50`... is there a way to list out format_code so I can see what options I'd like to use? [16:56:07 CET] <Daglimioux> kepstin: Yes, that's really odd. The other frames from other videos, even from the same video, are not showing up. The first video duration is 00:01:33, while the others are 00:01:32 and I get an output file of 00:01:33, but at second 00:00:26, where the frames are missing in video2, all videos are freezed [16:56:39 CET] <Daglimioux> kepstin: I have the latest version of ffmpeg (I updated it last monday) [17:00:13 CET] <storrgie> actually I was able to get a list of format_code.. however I'm getting `Unrecognized option 'format_code'.` now... and my ffmpeg does have `--enable-decklink` in its configuration [17:13:03 CET] <kepstin> storrgie: that's an input option, so it should be placed before the -i for the decklink input [17:13:16 CET] <kepstin> I think [17:14:53 CET] <storrgie> I'm wondering if I've compiled ffmpeg properly [17:15:11 CET] <storrgie> there is a cryptic note in the documentation about decklink: "To enable this input device, you need the Blackmagic DeckLink SDK and you need to configure with the appropriate --extra-cflags and --extra-ldflags" [17:15:21 CET] <ddubya> is it necessary to hard-code what codecs are compatibel with what containers or is therey a way to query it [17:15:26 CET] <storrgie> I'm not sure what I should have --extra-cflags and --extra-ldflags set to [17:15:59 CET] <kepstin> ddubya: there is not a working query right now (there's an api for it, but it's not wired up in most containers, so it just returns "maybe" for almost every codec) [17:16:14 CET] <ddubya> ok [17:16:26 CET] <kepstin> ddubya: on the other hand, if you try to mux a particular codec into a container, it'll either work or produce an error [17:16:40 CET] <kepstin> so... try, and if it doesn't work then it's not compatible :) [17:16:50 CET] <ddubya> sure, but I don't want to present a UI with options that don't work [17:17:21 CET] <kepstin> sure, but you also don't want to present a ui that won't let you do something that does work because it was added more recently than the ui was built. [17:17:29 CET] <kepstin> depends on how advanced your users are i guess [17:17:34 CET] <ddubya> yeah its a tradeoff [17:18:09 CET] <ddubya> given this app has a lot of users I'll take the former and save myself some bug reports [17:18:41 CET] <storrgie> kepstin, even though I have `--enable-decklink` in my configuration... it appears ffmpeg doesn't recognize that critical option of `format_code`: https://gist.githubusercontent.com/storrgie/92b43fbaf8a69fe0b338ab4c608ae63… [17:19:28 CET] <kepstin> storrgie: what does the output of "ffmpeg -h demuxer=decklink" look like? [17:21:54 CET] <storrgie> kepstin, https://gist.githubusercontent.com/storrgie/de82baeae1e61369469edc42eebbf06… [17:22:32 CET] <storrgie> kepstin, I was going off the discussion here: http://www.ffmpeg-archive.org/DeckLink-cannot-enable-video-input-td4679883.… and the documentation in ffpmeg where both say you need to have format_code specified [17:23:09 CET] <kepstin> storrgie: well, that decklink demuxer simply does not that a format_code option, so hmm. [17:23:35 CET] <ddubya> anyone know if the old and new codec_cap flags after rename have the same values? [17:24:22 CET] <storrgie> kepstin, when trying to record from the interface I just get [decklink @ 0x11b7a00] Cannot enable video input, DeckLink Duo (1): Input/output error [17:30:09 CET] <kepstin> storrgie: I think your problem is that your ffmpeg is just too old [17:30:20 CET] <kepstin> storrgie: that's the 2.8 from ubuntu, you should get something newer [17:30:54 CET] <kepstin> if you compiled & installed a new ffmpeg, you need to make sure it's in your PATH so you actually run it& [17:41:39 CET] <Johnjay> is there a way to compare decibels of sound [17:41:50 CET] <Johnjay> with the -4 and -10db levels that ffmpeg reports in an mp3 file? [17:42:06 CET] <Johnjay> this wiki article is saying 40db is the volume of a whisper [17:44:52 CET] <kepstin> Johnjay: not sure what values you're talking about ffmpeg report. Is this replaygain stuff? [17:45:05 CET] <Johnjay> volumedetect filter [17:45:17 CET] <Johnjay> it reports mean and max db level with max PCM volume as a reference [17:45:21 CET] <furq> Johnjay: https://en.wikipedia.org/wiki/DBFS [17:45:22 CET] <kepstin> ok, volumedetect just returns volumes in dbFS, yeah [17:45:43 CET] <kepstin> so all that says is "this file is 4dB quieter than the max that can be represented in digital audio" [17:46:12 CET] <kepstin> it doesn't have any direct mapping to a reference, since the output level depends on the volume you have set on your sound system [17:46:38 CET] <Johnjay> weird it says that -6dbFS is 50% of max volume but 10^(-6/10) is .25 [17:46:41 CET] <Johnjay> not .5 [17:47:12 CET] <Johnjay> wouldn't -3dbFS be 50%? [17:48:15 CET] <kepstin> a change of ±6dB is a change in signal levels (voltage) of about ±50% [17:49:53 CET] <furq> it's 20 * log10(value, max) [17:50:17 CET] <Johnjay> wikipedia is saying you're taking the square root [17:50:23 CET] <Johnjay> and distinguishes power ratio from amplitude ratio [17:51:06 CET] <kepstin> Johnjay: note that we're talking about a change of 6 db, so you have to use a +6 in the power, and that it's a 20 rather than 10, yeah [17:51:12 CET] <furq> value / max rather [17:51:32 CET] <Johnjay> wiki is saying it's "useful" consider the square of the field strength... ok then [17:51:42 CET] <kepstin> 10^(6/20) = 1.99, so an increase of 6dB multiplies signal values by 1.99 (approximately doubles them) [17:51:51 CET] <therage3> it's interesting how doing these things properly requires knowledge of electrical/electronics engineering [17:51:55 CET] <kepstin> for -6dB, you divide by 1.99 [17:52:15 CET] Action: kepstin rounded poorly, but you get the idea [17:52:27 CET] <furq> but yeah since you were asking earlier about damaging speakers if you amplify too much [17:52:34 CET] <furq> if you overamplify you'll just clip to 0dB [17:52:59 CET] <kepstin> well, a pcm signal clipped at full scale can actually be louder than 0dBFS :/ [17:55:11 CET] <kepstin> but as for damaging speakers, you have to look at (analogue?) power meters tracking voltages going to the speakers and see if they're in specs, I guess? Maybe you can work back through your amp and dac settings to figure out what digital signal level corresponds to what output voltage. [17:55:45 CET] <Johnjay> right [17:55:56 CET] <Johnjay> but now i'm trying to figure out how to get a sound sample to be a whisper, i.e. 40db [17:56:10 CET] <furq> turn your volume down [17:56:15 CET] <Johnjay> lol ok [17:56:15 CET] <kepstin> simple - play any sound sample, and adjust the volume on the amp until it's a whisper [17:56:20 CET] <furq> ^5 [17:57:38 CET] <kepstin> Johnjay: this is a calibration thing. you need to find out what digital signal level corresponds to what dB output from your system. [17:57:47 CET] <kepstin> and once you have that, then you just use relative numbers. [17:58:55 CET] <kepstin> (and this obviously also depends on listener's distance to the speakers, too) [18:00:51 CET] <furq> dB is a relative scale, and dBFS and dB SPL aren't relative to the same thing [18:01:55 CET] <furq> dBFS can tell you whether something will sound like a whisper relative to some other sound in the same file, but not absolutely [18:02:02 CET] <furq> and obviously it still depends on your output level [18:03:12 CET] <kepstin> keep in mind that many SPL meters can use a human-peception weighted scale (humans have different response at different frequencies), and you might have to do similar compensation in the digital side, e.g. by using the ebu r128 LUFS values rather than dBFS. [18:34:00 CET] <andrew-shulgin> Hello! Is there a function to get timestr from timeval (av_parse_time vice-versa)? [18:34:29 CET] <Johnjay> how do i overlay two mp3 files together? [18:35:07 CET] <durandal_170> Johnjay: amix filter? [18:35:48 CET] <Johnjay> right [18:36:10 CET] <Johnjay> that should work [18:36:13 CET] <Johnjay> i'm trying to remix this track of jungle sounds and don't know what i'm doing [18:37:38 CET] <Johnjay> specifically i want to mix in some sounds, but then normalize the audio so it's increasing and then decreasing [18:37:42 CET] <Johnjay> kind of like a bell curve [18:37:46 CET] <Johnjay> right now i'm using afade=in and afade=out [18:38:23 CET] <Johnjay> the doc says afade accepts parameters like exponential and sine [19:02:58 CET] <kikobyte> BtbN, I was investigating a segmentation fault happening during the nvenc h264 encoding (remember, the one which segfaulted on nvEncUnmapInputResource). What I found is, a particular surface gets actually unmapped twice. Long story short, I decided to check here https://github.com/FFmpeg/FFmpeg/blob/release/3.3/libavcodec/nvenc.c#L1452 if the incoming frame is already mapped (that's what caused double unmap) [19:03:48 CET] <kikobyte> BtbN, What happened is, the input picture was duplicated because of the default -vsync 1 behavior [19:07:30 CET] <BtbN> But only in combination with re-negoatiation I guess? [19:07:34 CET] <BtbN> And does it still happen on master? [19:08:35 CET] <kikobyte> BtbN, haven't checked on master, but I don't think I saw any protection from this case there as well [19:09:12 CET] <kikobyte> Re-negotiation here, seems doesn't really matter, but because of changing resolution, the next frame comes with a little delay in PTS, which makes the vsync logic to duplicate the previous frame [19:09:46 CET] <kikobyte> Since the encoder on the far end of the whole pipeline (not even in this process) cannot reinitialize instantly [19:10:37 CET] <kikobyte> Basically, it would be good to put a check in nvenc_register_frame for the frame being actually in the internal encoder queues at the moment [19:10:43 CET] <BtbN> I wonder if this should be plain not supported, or somehow make nvenc aware of the same frame being input twice [19:10:58 CET] <BtbN> well, doing such a check would be a huge effort for every single frame [19:11:10 CET] <kikobyte> At least a diagnostic message would be good [19:11:31 CET] <BtbN> If you figure it out to give a message, you might as well handle it... [19:11:59 CET] <kepstin> this case would be two refcounted frames sharing data, right? [19:12:03 CET] <kikobyte> BtbN, if (ctx->registered_frames[i].mapped) __builtin_trap(); is what gave me the clue [19:12:03 CET] <BtbN> But just noticing that you are getting the same frame twice is not straight forward [19:12:26 CET] <kikobyte> Just a O(1) lookup per frame [19:12:37 CET] <BtbN> The registered_frame is internal to nvenc [19:12:51 CET] <BtbN> if you get a new frame from external, you have to iterate and compare with all others [19:13:04 CET] <kikobyte> kepstin, in this case nvenc_register_frames overwrites the existing surface [19:13:44 CET] <kikobyte> registered_frames[...].mapped only gets changed when the frame is either registered or pushed while processing the output surface [19:13:48 CET] <kepstin> wouldn't a simple fix be to just have the encoder call av_frame_make_writable() on every frame it gets so that none share memory? [19:14:00 CET] <BtbN> you cannot make writeable a hardware frame. [19:14:13 CET] <kepstin> oh, hardware frames, right :/ [19:14:21 CET] <kikobyte> I'm referring to the NvencSurface structure [19:14:33 CET] <BtbN> That's internal to nvenc [19:14:38 CET] <BtbN> and assigned for every input frame [19:14:49 CET] <kikobyte> It's a fixed-size array defined in nvenc.c [19:14:50 CET] <BtbN> so if the same frame is input twice, it also ends up with two internal handles [19:15:08 CET] <BtbN> so? [19:15:09 CET] <kikobyte> used for mapping incoming frames (register + map) for gpu-only pipeline [19:15:19 CET] <BtbN> yes, exactly [19:15:25 CET] <BtbN> one mapping is made for every frame it gets [19:15:38 CET] <BtbN> so if it gets the same frame twice, it will be mapped twice, and eventually explode [19:16:08 CET] <BtbN> So it would need logic to detect frames referencing the same data. And then ref-counting logic on the mappings [19:16:15 CET] <BtbN> Which is a bit much for a simple fix [19:16:32 CET] <kikobyte> yeah, but when a new frame arrives, the nvenc_register_frame function goes through the fixed-size array of existing mappings and has the logic of quickly picking the previously registered instance if the cuda pointer matches [19:17:05 CET] <BtbN> And what do you do then? You'll still end up unmapping it twice. [19:17:20 CET] <kikobyte> essentially what I'm saying is, in the very same structure which keeps the cuda pointer, there's an indication of whether this mapping is currently active (read: not pushed out of the encoder) [19:17:59 CET] <BtbN> It's an array of mappings, so you cannot just add another for the frame with same data [19:18:13 CET] <kikobyte> nothing to add... [19:18:24 CET] <kikobyte> just check .mapping [19:18:45 CET] <kikobyte> if (ctx->registered_frames[i].ptr == (CUdeviceptr)frame->data[0]) { return i; } [19:18:51 CET] <BtbN> You will eventually unmap it [19:18:54 CET] <BtbN> and it will explode then [19:18:57 CET] <BtbN> not on originally mapping it [19:19:05 CET] <kikobyte> if (ctx->registered_frames[i].ptr == (CUdeviceptr)frame->data[0]) { assert(!ctx->registered_frames[i].mapped) return i; } [19:19:07 CET] <kepstin> you'd have to refcount it then? [19:19:15 CET] <BtbN> you'd have to come up with a full refcounting, yes [19:20:11 CET] <kikobyte> guys, that's weird. You have a structure, which remembers which frames are already registered, and it also remembers whether they're mapped. [19:20:25 CET] <BtbN> It crashes on _unmap_ [19:20:31 CET] <kikobyte> You use that structure to check if the incoming buffer needs registering through nvenc or you can re-use that reg resource [19:20:39 CET] <BtbN> And there is no way for it to know if the frame is in the queue again at that point [19:20:44 CET] <kikobyte> why not check if you already mapped it? because that's exactly "gates of mordor" [19:20:59 CET] <kikobyte> the frame is in the queue is then and only then if .mapped is 1 [19:21:10 CET] <BtbN> It already does that. Which is why it explodes when it tries to use and unmap it a second time [19:21:24 CET] <kikobyte> it crashes, and you can prevent that crash [19:21:39 CET] <kikobyte> by rejecting even to accept that frame [19:22:04 CET] <BtbN> you don't seem to follow. It needs to actually count how often the frame comes in, and if it can already unmap it, or needs to wait [19:22:14 CET] <BtbN> so mapped would have to be a counter instead of just a flag [19:23:07 CET] <kepstin> basically - when it gets to the unmap step, how is it supposed to know whether or not there's another later frame that's using the same mapping? [19:23:23 CET] <kikobyte> what I'm proposing is to detect and gracefuly exit once that kind of situation happens [19:23:36 CET] <kikobyte> you cannot refcount that mapping because, afaik, the requirements for the nvenc api are that you cannot even write to the buffer which you have mapped [19:23:42 CET] <BtbN> that wouldn't really be an improvement. It will still fail the entire encode. [19:23:56 CET] <BtbN> you're not writing to the frame [19:24:15 CET] <kikobyte> I thought that a diagnostic message is better than a random crash [19:24:16 CET] <BtbN> it's just used twice [19:25:25 CET] <kikobyte> supposedly, if you've got the frame you mapped (and haven't unmapped yet) again, it might mean that it's potentially modified. I can be wrong here, if the previous element in the pipeline doesn't re-use the buffer based on the refcount [19:25:38 CET] <kikobyte> so won't argue here [19:26:08 CET] <BtbN> If you modify a frame that you gave to an encoder you're violating API [19:26:18 CET] <kikobyte> exactly what i'm saying [19:26:27 CET] <BtbN> So that's not a case that needs to be worried about. [19:26:28 CET] <kikobyte> in this particular case, the frame isn't being modified, just being re-sent [19:26:54 CET] <BtbN> I'm not even sure if that kind of usage is valid [19:27:12 CET] <BtbN> But pretty much nothing evet actually modifies a frame [19:27:16 CET] <kikobyte> good to know [19:27:29 CET] <BtbN> You only modify a frame if the refcount is 1 [19:27:57 CET] <kikobyte> anyways, I just felt obliged to share my findings. To put it short - sending the same frame twice in a rapid succession (as with -vsync 1 frame duplication) spuriously crashes encoder [19:40:40 CET] <BtbN> I wonder if this also happens if you put a fps filter in the chain to double the framerate [19:40:58 CET] <kikobyte> BtbN, my assumption - yes [19:41:23 CET] <BtbN> depends on how the filter duplicates frames [19:41:27 CET] <BtbN> It might be doing a full copy [19:41:30 CET] <kikobyte> Sorry man, I'm heading home [19:42:46 CET] <BtbN> nope, high fps works just fine [20:23:59 CET] <bbert> I have some files that were muxed with a custom application built with libav. I would like to remux them using ffmpeg. The original container is matroska, with dnxhd video and pcm_s24le audio. The issue is that the custom application doesn't seem to properly handle setting the frame rate, or perhaps timestamps. I *can* verify that all video frames and audio samples are present, but the duration of the file is not properly detected by ffmpeg. If I [20:23:59 CET] <bbert> force the proper frame rate (using -r on the input), video is remuxed perfectly, and everything lines up with my separately recorded audio, which was recorded with AD converters locked to the same master clock as the video devices. However, the remuxed file ends prematurely and the remaining frames are not included in the output file. Playing the source file in ffplay has a similar result, where the final frames which are beyond the calculated [20:24:00 CET] <bbert> duration are omitted. However, when playing the source file in VLC, those frames are played. Is there a way to make ffmpeg include those files? I can't really take the time to try many different methods. These are quite large files (~1TB) and remuxing takes around an hour. [20:25:41 CET] <bbert> ^ should read "Is there a way to make ffmpeg include those *frames*?" [20:33:55 CET] <kepstin> bbert: ffmpeg should be including all of the frames. It's possible that the *audio* is too short - if the audio is shorter than the video, most players will stop playback when the audio track ends. [20:34:32 CET] <kepstin> or.. does this video file have no audio track? is it video only? [20:36:57 CET] <bbert> kepstin: The mismatch in framerate vs audio rate (proper 48k) does, in fact, cause the audio to end earlier than the video when the video is not forced to the proper frame rate. However, the behavior persists when using -an [20:38:05 CET] <kepstin> bbert: it would be helpful to see a pastebin of the ffmpeg command you're running and its complete output. [20:39:13 CET] <bbert> ffmpeg -r 30000/1001 -i input.mkv -c:a copy -c:v copy output.mxf [20:39:30 CET] <bbert> Or the same w/ -an and no -c:a [20:40:00 CET] Action: bbert reads more... "complete output...." [20:41:16 CET] <bbert> how about the complete output, but for only the first few seconds of remuxing? The full run will take a long time, and produce copious output.... [20:44:01 CET] <ddubya> avcodec_get_name segfaults.... could it be because the codec isn't open? All it is passed is a codec id [20:44:34 CET] <ddubya> this is what I'm using as replacement for avcodeccontext->codec_name [20:45:34 CET] <saml> til color space [20:46:03 CET] <saml> how does -filter_complex format=pix_fmts=rgb24 work given yuv420p? would it lose color? [20:46:24 CET] <saml> or yuv420p (12bpp) to rgb24 (24bpp) is lossless? [20:46:31 CET] <bbert> kepstin: Here's a paste from one of the smaller files I've been using for testing. https://pastebin.com/uLVrzjJx [20:53:40 CET] <ddubya> is AVCodec->name going to be deprecated as AVCodecContext->codec_name has been? [21:00:22 CET] <kepstin> bbert: hmm. kinda odd. nothing obvious there except that those dts errors will probably cause some issues later. It looks like you exited that early with ctrl-c? [21:02:55 CET] <bbert> kepstin: yes, ctrl-c. running the full file would have taken ~20 min [21:07:12 CET] <ddubya> hmm I don't see where anyone is calling av_register_alll ... doh [21:08:14 CET] <bbert> kepstin: interesting... doing the same, but to .mov does not result in the same dts problems... I'm going to do a full remux to .mov and see what happens... [21:15:02 CET] <wandering_segfau> Hello, is there a way to force ffmpeg to copy a private data PID in a transport stream? -copy_unknown doesn't seem to do anything. [21:19:31 CET] <ddubya> anyone know why avcodec_get_name always segfaults, tested on version 2.2.9 and git master same [21:22:26 CET] <ddubya> nvm I'm an idiot [21:22:26 CET] <BtbN> because you never called register_all? [21:22:46 CET] <ddubya> its a blasted function pointer due to this dynamic loader they've got [22:14:01 CET] <ddubya> I'm upgraded to ffmpeg 3.5 (git master) and avcodec_open2 always returns -22. Any idea what to look for? [22:14:16 CET] <ddubya> doesn't seem to matter what the codec is [22:14:24 CET] <JEEB> did you register_all() before? [22:14:34 CET] <ddubya> yes [22:14:54 CET] <ddubya> they're audio codecs with s16 sample format [22:15:03 CET] <ddubya> works fine with v57 [22:17:01 CET] <ddubya> here's the codec setup, https://goo.gl/euT4iL [22:17:13 CET] <ddubya> maybe something stands out as off [22:28:45 CET] <BtbN> Did you ever alloc the context? [22:32:27 CET] <ddubya> it was set to point to the stream->codec after allocating the stream [22:34:27 CET] <ddubya> then filled with various parameters, then avcodec_open2 [22:35:08 CET] <ddubya> something here is now illegal since v57 and I've got no idea [22:41:43 CET] <alexpigment> ddubya: https://stackoverflow.com/questions/26205017/ffmpeg-avcodec-open2-returns-2… [22:41:47 CET] <alexpigment> is it possible that's related? [22:44:43 CET] <ddubya> maybe [22:44:54 CET] <ddubya> not setting channel_layout at all here, but setting channels [22:45:04 CET] <ddubya> channels is always 1 or 2 [22:46:26 CET] <alexpigment> gotcha [22:46:34 CET] <alexpigment> just figured i'd throw that out in there in case it helped [22:46:45 CET] <alexpigment> i have no idea about the actual problem, but that came up in a google search [22:46:49 CET] <ddubya> thanks, I can use all the help I can get [22:46:57 CET] <BtbN> Look at the log output [22:46:57 CET] <ddubya> would a debug build of ffmpeg help you think [22:47:05 CET] <BtbN> it will most likely tell you what it dislikes [22:47:41 CET] <ddubya> ok, I don't see any logging at the moment, maybe they disabled it [22:54:47 CET] <ddubya> "aac unsupported channel layout". I'm a PLEB. Thanks for the logging suggestion [22:57:43 CET] <lazorshade> Is there a way to cut out multiple short clips from a longer video in one go? Something like "ffmpeg -i inputfile.mp4 -ss 5:05 t 10 -ss 6:30 -t 10 out.mp4". I know I could go one by one but seeking through the files takes a long time if the timestamp is at the 1h mark. [22:58:16 CET] <BtbN> put -ss before -i [22:59:05 CET] <lazorshade> But then the video doesn't cut as exactly as when I put it after -i. [22:59:06 CET] <alexpigment> BtbN: isn't that going to be inaccurate though? [22:59:10 CET] <alexpigment> yeah [22:59:43 CET] <alexpigment> it's fairly accurate for me, but I always encode with a gop the same as the frame rate [22:59:54 CET] <alexpigment> and i realize most people don't do that [23:00:15 CET] <BtbN> gop as same as frame rate is pretty bad quality wise [23:00:39 CET] <alexpigment> you're assuming too much about my bitrate/crf [23:01:04 CET] <alexpigment> hard drives are cheap. cheap enough to not take shortcuts when encoding [23:01:34 CET] <BtbN> sounds more like you are looking for a proper lossless intermediate format [23:01:48 CET] <alexpigment> me? [23:02:07 CET] <lazorshade> Yeah, I mean it's not super inaccurate, but usually there's about 0.5 to 1 second of a frozen frame in the clip while the audio is already playing when i put -ss before -i. [23:02:24 CET] <lazorshade> And I'm trying to avoid that. [23:03:20 CET] <alexpigment> lazorshade: one of the suggestions here mentions using the trim filter: https://superuser.com/questions/681885/how-can-i-remove-multiple-segments-f… [23:03:28 CET] <ChocolateArmpits> lazorshade, you can check for the closest keyframe using ffprobe and then cut on the related timestamp [23:03:49 CET] <alexpigment> i'm not sure if that is much quicker than doing each one individually, but it's worth a try [23:04:16 CET] <lazorshade> alexpigment, ChocolateArmpits: Thank you, I'll look into that! [23:04:50 CET] <ChocolateArmpits> it would probably be smart to script it, because there's quite some data to parse manually each time [23:05:52 CET] <lazorshade> Yeah, I'd be working with a list of timestamps that I'll run through a script anyway, so that should work. Thanks. [23:07:30 CET] <BtbN> lazorshade, if you're re-encoding anyway, you might as well just transcode it to utvideo or something, and then cut that quick [23:08:52 CET] <alexpigment> the one downside to that method is that you then have to really actively think about and deal with situations where you'd run out of hard drive space [23:09:11 CET] <alexpigment> (if the source video resolution and length is highly variable) [23:09:41 CET] <lazorshade> I'm not familiar with utvideo, does it make seeking through the video faster? [23:10:11 CET] <lazorshade> Disk space isn't really an issue, the source files are deleted once the short clips are cut out. [23:14:43 CET] <alexpigment> lazorshade: it should make it faster I would think. you'd have to run through some tests to see if it's overall faster, since you're adding another encode and decode step to the process [23:15:38 CET] <lazorshade> Okay, thank you. [23:18:17 CET] <islanti> hmm i need to convert an aax file to multiple mp4s for each chapter [23:20:52 CET] <islanti> is there a command line solution to do that? [23:22:50 CET] <alexpigment> islanti: https://github.com/r15ch13/audible-converter ? [23:27:36 CET] <islanti> looks like that keeps chapters intact in the mp4 file, but i need seperate mp4 files for each chapter [23:29:14 CET] <saml> what is output format for .mp4 if I were to output to - ? [23:29:20 CET] <saml> -f mp4 - won't work [23:29:22 CET] <islanti> hmm unless my ipod gen7 supports chapter markes, then i'm ok with that. i will have to check.. [23:29:32 CET] <islanti> *markers [23:34:03 CET] <saml> looks like mp4 is special and needs to write full size in the header and can't be streamed to - [23:34:32 CET] <saml> it's just so weird -filter_complex psnr gives very different number if i'm comparing .mp4 and .avi [23:35:55 CET] <alexpigment> saml: same exact codec? [00:00:00 CET] --- Sat Jan 27 2018

1 0