Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

June 2017

1 participants
60 discussions

ffmpeg-devel.log.20170629
by burek 30 Jun '17

30 Jun '17

[00:51:20 CEST] <philipl> jkqxz: care to look at my last diff on the cuvid hwaccel stuff? [01:05:59 CEST] <cone-658> ffmpeg 03KongQun Yang 07master:45dbb40cd1b3: Update mp4 object type for VP9 [05:21:23 CEST] <LongChair> @jkqxz : you more likely need to rebuild mpp from here, i guess the image you got doesn't have a recent one https://github.com/rockchip-linux/mpp [05:22:31 CEST] <LongChair> jkqxz: by the way started the update work : https://github.com/LongChair/FFmpeg/commits/rockchip-new [05:51:59 CEST] <LongChair> jkqxz: your patch also seems to lack the deployment of hwcontext_drm.h (see one of the latest commits on my GH) [06:20:20 CEST] <LongChair> jkqxz, wm4: i was looking in using that format (with mpv & egl first). The only annoying thing from usage point of view is typical DRM_FORMAT_NV12 format which basically means i have 2 sets of offset/pitches (one for Y, one for UV), then i have one format and one fd for the whole thing. handling this in a generic way means that i have to browse planes and check if the DRMPlaneDescriptor.format changed to know if i need to switch textures. [06:20:20 CEST] <LongChair> in only one texture, where the vaapi format would result in 2 textures if i got it right. Ofc this is doable, just adds a bit of complexity in the code. But I guess that this is what you guys expected ? :) [06:45:02 CEST] <LongChair> just wondering if something like this wouldn't be easier to work with https://gist.github.com/LongChair/710d25ed60adce5b2ec146737226f0c9 [11:08:45 CEST] <jkqxz> LongChair: Doesn't that duplicate the file descriptor for Intel? (One of the things we were strongly trying to avoid.) [11:09:16 CEST] <jkqxz> Also it's missing the object sizes. [11:11:19 CEST] <jkqxz> That version on github doesn't have MPP_DEC_GET_FREE_PACKET_SLOT_COUNT either. Do you have a git hash for the version you are using? [14:09:06 CEST] <thardin> TIL about a new old format: windows metafile (wmf) [14:11:04 CEST] <RiCON> it's been used for something other than an exploit? [14:11:38 CEST] <thardin> it's used as output format of some vibration testing program [14:13:14 CEST] <thardin> swedish institute of space physics has an old P3 running XP that spits out such files (in addition to a rawer binary data form) [14:13:45 CEST] <thardin> I recall kostya ranting about formats like this. struct dumps of GDI calls [14:16:51 CEST] <thardin> like that screen capture program for win3.1 [14:57:20 CEST] <wm4> what is no_rasl_output_flag in hevcdec? [14:58:49 CEST] <wm4> anyway I'm trying to fix that someone seems to have codec the idea into hevcdec that mastering display data side data should be emited only on an irap, not every frame [14:58:52 CEST] <wm4> which is nonsense [15:01:13 CEST] <JEEB> huh [15:13:50 CEST] <wm4> urgh it has to do with frame threading [15:19:12 CEST] <nevcairiel> no_rasl_output_flag is in the spec [15:20:18 CEST] <nevcairiel> see NoRaslOutputFlag [15:20:39 CEST] <nevcairiel> its some condition for random access and frame output [15:20:59 CEST] <Th3On3> hi there... i am trying to build ffmpeg under windows, using msys2 and after i installed the packages needed to build, i go to ffmpeg rootpath i execute a default command: "./configure --arch=x86 --target-os=mingw32 --cross-prefix=i686-w64-mingw32- --pkg-config=pkg-config" and i get a "Unknown option: --target-os=mingw32". What am i doing wrong ????? [15:28:09 CEST] <BBB> whats wrong with that flag? [15:28:12 CEST] <BBB> I thought I fixed it? [15:28:32 CEST] <wm4> BBB: probably nothing [15:28:46 CEST] <wm4> also naively copying some sei stuff in hevc_update_thread_context appears to fix it [15:28:54 CEST] <wm4> but I have no idea how this is supposed to work [15:31:13 CEST] <wm4> does anyone have a hevc sample with a53 captions? [15:31:27 CEST] <wm4> also why the fuck are people using hevc with a53 captions? [15:40:14 CEST] <Th3On3> who can help me ? [15:40:23 CEST] <Th3On3> hi there... i am trying to build ffmpeg under windows, using msys2 and after i installed the packages needed to build, i go to ffmpeg rootpath i execute a default command: "./configure --arch=x86 --target-os=mingw32 --cross-prefix=i686-w64-mingw32- --pkg-config=pkg-config" and i get a "Unknown option: --target-os=mingw32". What am i doing wrong ????? [15:42:05 CEST] <J_Darnley> configure quite clearly says [15:42:34 CEST] <wm4> "What am i doing wrong ????? " <- everything, there us no user help in this channel [15:45:28 CEST] <wm4> is, even [15:45:37 CEST] <Th3On3> ok ty [15:45:48 CEST] <wm4> try #ffmpeg [15:46:53 CEST] <Th3On3> yes... i am trying [15:46:54 CEST] <Th3On3> ty [15:59:42 CEST] <cone-746> ffmpeg 03Paul B Mahol 07master:4d681269e096: avcodec/gdv: add decompression for 2 and 5 method [16:09:46 CEST] <TMM> durandal_170, sorry for causing those fuzzing errors on mve, I thought that bytestream2 would prevent most of those by itself, sorry. [16:11:27 CEST] <TMM> durandal_170, if you'd prefer I can go over those crashes myself in the future [16:12:20 CEST] <durandal_170> TMM: there is one open crash repot [16:12:30 CEST] <RiCON> BBB: 840b41b2a seems to have broken yuv444p10 decoding [16:12:54 CEST] <TMM> durandal_170, ok, I'll try to figure it out. I don't want to patch and run :) [16:15:17 CEST] <TMM> durandal_170, so, you're not supposed to rely on bytestream2 then to prevent overreads? You have to check before reading anyway? [16:15:22 CEST] <wm4> BBB, RiCON: and the sample was https://0x0.st/0rJ.mkv I think? [16:16:13 CEST] <RiCON> yeah, the SEI errors are probably to the stripping of x264 information [16:16:49 CEST] <nevcairiel> if you have a file that was encoded with old x264, then strip its SEI and then complain that it doesnt decode right ... then your file is just broken :) [16:17:14 CEST] <nevcairiel> because old x264 produced broken files [16:17:40 CEST] <BBB> I was going to say, was this file generated with old x264 but not signaled as such? [16:18:05 CEST] <durandal_170> TMM: crash is in overwrites [16:18:54 CEST] <TMM> durandal_170, I was looking at your other patches [16:19:18 CEST] <BBB> you could probably write a bitstream modifier (filter?) to parse the h264 stream and rewrite it using the fixed context? [16:19:21 CEST] <BBB> I wonder how hard that would be [16:19:36 CEST] <BBB> then you can manually insert it if the SEI is stripped [16:19:37 CEST] <nevcairiel> the commit suggests its in cabac, so possibly annoying [16:19:39 CEST] <durandal_170> TMM: those are not overreads, just invalid args passed to function [16:19:39 CEST] <BBB> and keeps h264dec clean [16:19:42 CEST] <BBB> but maybe not worth it [16:19:52 CEST] <BBB> well a bitstream filter can use cabac [16:19:56 CEST] <BBB> Im not saying this is easy [16:19:57 CEST] <BBB> :-p [16:20:05 CEST] <BBB> Im just saying it can be done [16:22:18 CEST] <RiCON> so vlc/mpc-hc/lavfilters happen to work because they use older commits and will be broken later? [16:23:48 CEST] <nevcairiel> yeah, h264dec was mostly written against libx264 streams, so some odd parts of the spec that were wrong in x264 were also wrong in h264dec, but standards compliance should obviously be preferred - and any "broken" streams should probably retain the SEI to identify them as such [16:27:20 CEST] <nevcairiel> one of the more annoying problems is however that if you try to start playback from the middle of such a file, the decoder might actually never see the SEI in the first place [16:30:14 CEST] <jamrial> nevcairiel: mkv and mp4 both should have the SEI in extradata. problem would i guess be raw streams, and maybe mpegts [16:30:30 CEST] <nevcairiel> mkv and mp4 dont specify SEI in h264 extradata [16:31:19 CEST] <nevcairiel> unless they amended the specs at some point [16:31:26 CEST] <nevcairiel> in which case h264dec probably doesnt read it [16:31:26 CEST] <jamrial> they do, hvcc extradata contains sei [16:31:40 CEST] <nevcairiel> wrong codec =p [16:31:54 CEST] <TMM> durandal_170, one of your changes broke the simcity movie playback [16:32:15 CEST] <durandal_170> TMM give sample [16:32:45 CEST] <TMM> durandal_170, https://trac.ffmpeg.org/ticket/4740 the one in this ticket [16:33:10 CEST] <TMM> durandal_170, there seem to be artifacts now that weren't there before, I'm reverting everything now to make sure I'm not hallucinating [16:33:52 CEST] <jamrial> nevcairiel: ah yeah, whoops :p [16:33:55 CEST] <durandal_170> TMM: please give sample name [16:35:03 CEST] <TMM> durandal_170, I don't understand what you want [16:36:16 CEST] <TMM> durandal_170, http://samples.mplayerhq.hu/game-formats/interplay-mve/MARIO1.MVE <-- that one shows the same problem in the beginning now [16:36:46 CEST] <TMM> durandal_170, if I revert all your changes it plays correctly [16:38:53 CEST] <TMM> durandal_170, is that the correct information? That sample url? Or do you need something else? [16:44:34 CEST] <cone-746> ffmpeg 03Paul B Mahol 07master:3821c004e260: avcodec/interplayvideo: fix regression causing artifacts [16:56:55 CEST] <TMM> durandal_170, looks good again, thanks :) [18:01:32 CEST] <cone-746> ffmpeg 03Clément BSsch 07master:2658e66cd1be: lavu/cpu: disable MMX warning on non x86 platforms [18:11:57 CEST] <tdjones> What is the best way to encode multiple short packets during a single call to encode_frame in an audio encoder if the total number of output samples is constant? [18:13:07 CEST] <atomnuker> tdjones: you can only output 1 packet per encode_frame [18:13:25 CEST] <nevcairiel> with the new api you can just not consume more input tho [18:14:57 CEST] <atomnuker> you could always do that (this is for the vorbis encoder, not for api users) [18:15:20 CEST] <tdjones> I should've clarified that, sorry nevcairiel. [18:16:46 CEST] <tdjones> If I'm understanding it correctly, each short window of samples must be in a separate ogg page, so each window must be a separate packet? [18:19:22 CEST] <atomnuker> right, so there's no way for the encoder to signal it doesn't need any input right now [18:20:02 CEST] <atomnuker> just mark it in your context that you'll be outputting a transient, you already have a lookahead so you know how long it'll last [18:20:27 CEST] <atomnuker> and you just output them 1 short window at a time, and you'll be supplied with a new avframe which you just reference in your queue [18:21:29 CEST] <atomnuker> throughput and waiting isn't a problem since one short window is always going to be more than or equal to the frame size so you won't see the API user starved of frames [18:21:44 CEST] <atomnuker> (or rather samples) [18:23:26 CEST] <nevcairiel> like i hinted to above, if you use the new API you can control when you receive new input - but of course that would mean that the encoder doesnt work for anyone using the old public API [18:24:13 CEST] <wm4> <nevcairiel> one of the more annoying problems is however that if you try to start playback from the middle of such a file, the decoder might actually never see the SEI in the first place <- this is indeed a problem [18:24:28 CEST] <atomnuker> nevcairiel: it is? how? [18:24:30 CEST] <wm4> already got a second report with a similar sample that works when decoding from the beginning, but not with seeking [18:25:44 CEST] <wm4> also can someone ack my hevc patch? [18:26:42 CEST] <BBB> ack [18:26:43 CEST] <BBB> :-p [18:26:48 CEST] <BBB> or you want it on ml? [18:27:12 CEST] <wm4> the latter (I'd also add a micro bump so the bug fix can be detected by API users) [18:27:26 CEST] <wm4> s/ack/review/ [19:42:22 CEST] <durandal_1707> what solution to pick for unaligned filtering? [19:43:11 CEST] <durandal_1707> clearly interlace filter thinks it will allways get aligned frame [19:55:42 CEST] <durandal_1707> michaelni: fine to push prores patch? [21:29:29 CEST] <J_Darnley> An odd question... Does the count argument given to avctx.execute2\? signal the maximum number of things that can be executed in parallel? [21:34:56 CEST] <atomnuker> wut? [21:35:11 CEST] <atomnuker> no, that's detemined by the thread count [21:35:43 CEST] <atomnuker> well, its the FFMIN(thread count, count) [21:36:11 CEST] <J_Darnley> Ah. That is what I think I wanted to know. [21:36:25 CEST] <atomnuker> you shouldn't care about how many threads there are, all your inputs and outputs should be independent [21:37:03 CEST] <J_Darnley> I don't I'm just trying to track what values go where [21:48:15 CEST] <kierank> J_Darnley: in vc-2 a thread can either be decoding the coeffs of a slice [21:48:18 CEST] <kierank> or doing the transform [21:48:29 CEST] <kierank> (ignore the fact you can thread planes) [21:48:43 CEST] <kierank> at the moment we decode all slices then do the transform single threaded [21:48:48 CEST] <kierank> (again ignore chroma planes) [22:05:19 CEST] <atomnuker> (actually the transform is per-plane threaded) [22:07:22 CEST] <kierank> atomnuker: that's what I said ;) [22:28:59 CEST] <J_Darnley> Who was the retard at Lenovo who thought it was a good idea to put the battery status light on the side of this shitty laptop? [22:30:54 CEST] <atomnuker> the same one that only looked that the windows battery status on the taskbar? [22:31:55 CEST] <atomnuker> nevcairiel: ping, how do you signal you don't want any input from an encoder (with the new api)? [22:33:52 CEST] <iive> J_Darnley: how else would you see the battery status when the laptop is closed?! [22:35:53 CEST] <J_Darnley> I think I need to configure a bigger flashier warning [22:44:37 CEST] <Compn> J_Darnley : probably you can hack the keyboard leds to indicate battery [22:44:49 CEST] <durandal_1707> atomnuker: have you managed to complete something? [22:45:42 CEST] <RiCON> J_Darnley: someone who liked macbooks doing the same [22:45:49 CEST] <LongChair> jkqxz: you want to use the "for_linux" mpp branch [22:45:55 CEST] <atomnuker> durandal_1707: not yet, I have a dayjob, you know? [22:46:55 CEST] <durandal_1707> atomnuker: quit it, come work for me! [22:54:44 CEST] <Compn> durandal_1707 : what are you paying ? [22:55:13 CEST] <durandal_1707> food only [22:58:39 CEST] <J_Darnley> Good it managed to restore from hibernate today [23:10:10 CEST] <durandal_1707> atomnuker: so how you plan to make bireader fast on both x86 and x64? [23:12:05 CEST] <atomnuker> dunno... since everything would use the same API I was thinking get_bits.h would just include get_bits_cached.h on 64 and get_bits_uncached on 32 bit systems [23:12:59 CEST] <atomnuker> or I could probably just ifdef a typedef on the storage type used for the cache to 32 bits [23:13:03 CEST] <durandal_1707> what would cached have? [23:13:38 CEST] <atomnuker> (in fact I think I'll do that first rather than leave the 2) [23:13:46 CEST] <atomnuker> the libav bitstream reader [23:15:32 CEST] <durandal_1707> i think better approach is just increasing cache with define in existing header [23:16:09 CEST] <atomnuker> the issue is the cache is not kept anywhere and looking at vlc decoding theirs does less operations to read [23:16:26 CEST] <atomnuker> extending the current reader to keep a cache also isn't easy [23:16:57 CEST] <iive> there used to be a bitstream reader that kept cache [23:16:57 CEST] <atomnuker> since some things like the cabac reader and some codecs do their own caching and updating [23:17:47 CEST] <durandal_1707> iive: how big cache? [23:18:42 CEST] <iive> 2x32bit iirc [23:19:18 CEST] <durandal_1707> probably didnt helped with get vlc2 [23:19:54 CEST] <wm4> I thought it helps to simply copy the bit reader state to the stack? [23:20:03 CEST] <wm4> since the compiler won't be plagued by possible aliasing anymore [23:21:23 CEST] <iive> what aliasing? [23:22:00 CEST] <wm4> pointers [23:22:48 CEST] <wm4> functions using the bitstream reader typically have the bitstream state as pointer argument [23:24:07 CEST] <iive> i still don't understand what aliasing you are talking about... [23:26:18 CEST] <kierank> rcombs: still in London? [23:27:28 CEST] <durandal_1707> kierank: i still want it [23:30:12 CEST] <kierank> durandal_1707: I will give it if I can upload [23:50:42 CEST] <kurosu> hi, regarding libav bitstream reader, I'm no longer able to publish what I've done [23:50:52 CEST] <kurosu> but you can somewhat contrive it to use native reg size [23:51:52 CEST] <kurosu> unfortunately, can break easily, as soon as you read more than 16 bits, so you need to do 8b/16b reloads instead of 32b-always for 64b archs [23:52:04 CEST] <kurosu> Then LONG_BITSTREAM_READER requires it to be dynamical [23:52:17 CEST] <kurosu> ie if LONG_BITSTREAM_READER, you can't use native reg size [23:53:15 CEST] <kurosu> or you spend a lot of time finding the one function call that does read more than 24b on occasion, and then you use bitstream_read_63 for instance [23:54:52 CEST] <kurosu> https://pastebin.com/HbtRpjA9 <- benchmarks to see on HSW-E/x86832 whether using 32b regs was effective: it is [23:55:24 CEST] <jamrial> hi kurosu [23:55:26 CEST] <jamrial> why is that? [23:55:42 CEST] <kurosu> ah, and some codecs like to do 32b reads (_xbits, exp-golomb), so one can try to reduce what it reads [23:55:48 CEST] <kurosu> why is that what ? [23:56:00 CEST] <jamrial> not being able to publish what you've done [23:56:43 CEST] <kurosu> because I had always done that pro bono, and it became difficult to manage that with $payjob [23:57:04 CEST] <kurosu> and also freetime greatly reduced [23:57:12 CEST] <jamrial> ah, i see :( [23:58:22 CEST] <kurosu> same, module extracting the joint table feature of huffyuvdec to use it in eg magicyuv or actually any huffman-based lossless decoder [23:59:16 CEST] <kurosu> libav bitstream reader + that is like >2x time speedup on those codecs [00:00:00 CEST] --- Fri Jun 30 2017

1 0

ffmpeg.log.20170629
by burek 30 Jun '17

30 Jun '17

[00:01:09 CEST] <JEEB> nicolas17: often that ends up being simpler than you'd think [00:03:13 CEST] <nicolas17> JEEB: I want to encode a bunch of JPEG images into mp4/x264 (or losslessly mux them into mkv so I can do the actual transcoding with ffmpeg later), but altering the PTS with custom logic [00:04:34 CEST] <nicolas17> and I don't have audio to deal with, so yeah, I'll give it a try [00:05:35 CEST] <Tatsh> lossy to lossy = bad [00:05:36 CEST] <Tatsh> :P [00:09:33 CEST] <nicolas17> Tatsh: hm? [00:10:55 CEST] <nicolas17> Tatsh: transcoding JPEG to x264 is bad? I'll post this 29GB video online then :P [00:11:22 CEST] <alphabitctiy> I'm trying to transcode a live RTSP stream and am seeing some A/V desync in the output. Anyone have any tips or flags I can try? Thank you! [00:32:45 CEST] <JodaZ> alphabitctiy, tried the async option? [00:35:07 CEST] <JodaZ> alphabitctiy, check the manual for that option, around it there are a few other things in the manual that might help [00:36:03 CEST] <alphabitctiy> JodaZ: Thanks! yes, we just tried aresample, which apparently is replacing async .. and it seems to be working great [01:03:32 CEST] <classsic> hi [01:03:57 CEST] <classsic> is correct ffmpeg generate greater bitrate than input when use "crf 0" ??? [01:04:48 CEST] <klaxa> usually yes [01:04:55 CEST] <klaxa> it's lossless [01:22:25 CEST] <classsic> ok, thanks. [01:35:16 CEST] <nicolas17> how do I read a sequence of images (as in -f image2) using the API? [01:35:34 CEST] <nicolas17> am I supposed to pass the wildcard as the url in avformat_open_input? [01:35:39 CEST] <nicolas17> also should I be asking in -devel? :) [01:35:42 CEST] <JEEB> no [01:35:45 CEST] <DHE> you can still treat it as ffmpeg handles it and let image2 do the heavy lifting. [01:35:46 CEST] <JEEB> -devel is for internals [01:41:29 CEST] <nicolas17> yeah looks like I need something fancier here :P avformat_open_input(ctx, "*.jpg", av_find_input_format("image2"), NULL) is not enough [02:39:58 CEST] <nicolas17> ughhhh I figured it out [02:40:26 CEST] <nicolas17> of course it fails, it would fail in ffmpeg too [02:40:34 CEST] <nicolas17> I'm passing -pattern_type glob to ffmpeg, I need to do the same in the API [02:42:59 CEST] <nicolas17> works now \o/ [02:44:52 CEST] <nicolas17> well, avformat_open_input doesn't throw an error [06:19:03 CEST] <Aprel> Does hevc_nvenc (hardware encoding with nVidia gfx) have configuration options? I'm trying different ffmpeg flags but the video file output is the same size. Is there a config setting for hevc_nvenc for "same quality"? [09:40:03 CEST] <albb> Hi all someone can help me with this error using ffmpeg? Unrecognized option 'x264opts'. Error splitting the argument list: Option not found [09:42:38 CEST] <bencoh> first ffmpeg -codecs | grep x264 to see whether your ffmpeg has support for libx264 [09:43:21 CEST] <albb> ffmpeg version N-86654-gd2ef9e6 Copyright (c) 2000-2017 the FFmpeg developers built with gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04.3) configuration: --disable-x86asm libavutil 55. 67.100 / 55. 67.100 libavcodec 57.100.102 / 57.100.102 libavformat 57. 75.100 / 57. 75.100 libavdevice 57. 7.100 / 57. 7.100 libavfilter 6. 94.100 / 6. 94.100 libswscale 4. 7.101 / 4. 7.101 libswresample 2. 8.100 [09:44:22 CEST] <albb> there is not libx264, but iif I go in the ffmpeg directory (in Home), there I see the x264 executable and others.. [09:45:26 CEST] <albb> I followed the step by step compiling guide of ffmpeg.org here https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu [09:52:47 CEST] <albb> This is the pastebin complete issue [09:52:48 CEST] <albb> https://pastebin.com/PXcakdHA [10:27:25 CEST] <termos> is there a way to artificially add delay to the output of FFmpeg? [10:27:46 CEST] <squ> operating system priorities [10:27:51 CEST] <squ> shell suspend [10:28:46 CEST] <termos> looking to do it only for certain outputs, hoping there would be some way to introduce the delay in the muxing step [10:29:47 CEST] <squ> I would wrap it in a perl script which parses the output to send suspend signal to running ffmpeg process [10:32:27 CEST] <albb> squ, can you help me with my issue? [10:33:10 CEST] <squ> haven't read it, too much text, sorry [10:33:36 CEST] <squ> could read a 255 character question if you make one [10:35:32 CEST] <memphisw> Hi, i want to use ffmpeg in my cpp program. And what i found in the Internet is all about using command line tool. where can i get tutor about how to use ffmpeg by lib? or is't recommended using command line tool ? [10:36:46 CEST] <albb> https://pastebin.com/pHJME3AG [10:37:08 CEST] <albb> squ, this is the problem, I have put all the commands on the bash and the relative output to see what is missing [10:37:46 CEST] <termos> memphisw: I would look at the examples in the doc folder, this is what I base most of my implementations on: https://github.com/FFmpeg/FFmpeg/tree/master/doc/examples [10:37:46 CEST] <memphisw> i search cmdutils.c, hoping to find out how ffmpeg command line tool using libs, but it's so compicated and needs alot of work to learn. [10:39:28 CEST] <dystopia_> albb [10:39:34 CEST] <dystopia_> 1 - load a scaler [10:40:03 CEST] <albb> dystopia what scaler? [10:40:06 CEST] <dystopia_> 2 - -x264-params is wrong, use "-c:v libx264 YOUR PARAMS HERE" [10:40:15 CEST] <dystopia_> any you want [10:40:17 CEST] <memphisw> termos: ok, i should take a look, i hope it wont take a long time. [10:40:17 CEST] <dystopia_> i use spline [10:40:35 CEST] <albb> I'm a newbie I have not understood [10:40:36 CEST] <squ> memphisw: http://www.videolan.org/developers/x264.html [10:40:36 CEST] <dystopia_> -sws_flags spline -s 704x396 [10:40:53 CEST] <albb> Should I use a different command? [10:41:37 CEST] <dystopia_> just remove -x264-params [10:42:08 CEST] <albb> ok and then? [10:42:13 CEST] <dystopia_> and change "-vf "scale=426:240" to "-sws_flags spline -s 426:240" [10:42:15 CEST] <dystopia_> and try again [10:42:26 CEST] <albb> Ok wait [10:43:26 CEST] <Ixantir> hey [10:44:12 CEST] <Ixantir> using ShareX it just grabbed this app, is there a video tutorial on how to set up sharex specifically for gifs? [10:44:37 CEST] <albb> [NULL @ 0xa3969c0] Unable to find a suitable output format for 'keyint=60:min-keyint=60:no-scenecut' keyint=60:min-keyint=60:no-scenecut: Invalid argument [10:45:16 CEST] <squ> dystopia_: why -vf scale to be replaced with sws ? [10:45:46 CEST] <squ> this is something new I didn't know about [10:46:10 CEST] <albb> ffmpeg -hide_banner -i Helicopter.mp4 -threads 0 -sws_flags spline -s 426:240 -c:v libx264 -preset slow -profile:v main -level 4 -g 60 -keyint_min 60 "keyint=60:min-keyint=60:no-scenecut" -b:v 300k -maxrate 300k -bufsize 600k -r:v 30 -an -y -f mp4 Helicopter_240p_300.mp4 [10:46:21 CEST] <albb> This is what I did, and that's the error [10:47:37 CEST] <dystopia_> no idea then albb :| [10:48:50 CEST] <squ> text in a string is treated as output file [10:49:17 CEST] <memphisw> squ: im not just play video, i want to edit some frame of it. maybe vlc is not what i want? [10:49:19 CEST] <Ixantir> urk and messed the ffmpeg path up [10:49:47 CEST] <squ> memphisw: what that link has to do with vlc [10:52:58 CEST] <memphisw> squ: oh i thought that is a vlc page, so i can use x264 to edit mp4? [10:53:18 CEST] <squ> how about reading [10:53:44 CEST] <memphisw> sorry i'm new in this field, lack lots of knownlage [10:53:53 CEST] <squ> you can start by reading [10:53:54 CEST] <Ixantir> pretty much the same [10:58:17 CEST] <Ixantir> all i'm seeing are flv and mkv notes [11:00:30 CEST] <Ixantir> so it wants to take mp4 rather than .gif [11:00:46 CEST] <Ixantir> and all the notes on gif from the wiki are about crashes rather than anything condusive [11:37:43 CEST] <jkqxz> zalaare: <https://github.com/01org/intel-vaapi-driver/pull/214> [12:16:21 CEST] <ciripi> morning guys [12:16:26 CEST] <ciripi> i need some help please [12:16:33 CEST] <ciripi> if anyone is available [12:17:20 CEST] <JEEB> you note your thing and then stay put [12:17:34 CEST] <JEEB> if you ever want to get helped [12:18:33 CEST] <ciripi> yes [12:18:52 CEST] <ciripi> i have multiple streams and i want to trancode them to facebook live [12:19:26 CEST] <ciripi> ffmpeg -re -i "http://domain/x/x/input.m3u8" -acodec libmp3lame -ar 44100 -b:a 128k -pix_fmt yuv420p -profile:v baseline -s 426x240 -bufsize 6000k -vb 400k -maxrate 1500k -deinterlace -vcodec libx264 -preset veryfast -g 30 -r 30 -f flv "rtmp://rtmp-api.facebook.com:80/rtmp/111111111111111?ds=1&a=XXXXXXXXXXXXXXXXX" [12:19:36 CEST] <ciripi> but with this command seems i can run only one instance [13:21:09 CEST] <chris_99> hey, has anyone seen an error like this before https://gist.github.com/anfractuosity/17aa7310665ea936cd817e6a328530f5 'av_interleaved_write_frame(): Broken pipe' [13:21:16 CEST] <chris_99> using 'ffmpeg version N-86575-g04aa09c Copyright (c) 2000-2017 the FFmpeg developers' [13:21:35 CEST] <chris_99> i can give my full command i used if that helps too [13:21:59 CEST] <squ> yes [13:22:12 CEST] <squ> I mean yes paste the command line [13:22:41 CEST] <chris_99> ok, if you refresh that gist you'll see it [13:22:42 CEST] <chris_99> cheers [13:23:10 CEST] <squ> -i /dev/zero [13:23:13 CEST] <squ> ? [13:23:42 CEST] <squ> making a null sound? [13:23:53 CEST] <chris_99> yeah [13:24:08 CEST] <chris_99> so the error only happens after a while, it streams fine for a while [13:24:20 CEST] <squ> -f is the file format, like mp4 [13:24:38 CEST] <squ> -f h264 -f flv [13:24:38 CEST] <chris_99> yeah it uses flv encapsulation [13:24:55 CEST] <chris_99> the first one is to specify the input format [13:24:56 CEST] <squ> is it ok to have two -f [13:25:01 CEST] <squ> I see [13:25:22 CEST] <chris_99> i can't tell if the issue is with ffmpeg atm [13:25:25 CEST] <chris_99> or with raspivid [13:25:29 CEST] <chris_99> it's hard for me to tell [13:25:59 CEST] <squ> let's try encoding just file without pipe [13:26:43 CEST] <chris_99> the thing is, the issue happens after a long while, like after hours, so it's hard to know why it happens, normally it's fine [13:27:19 CEST] <squ> right, I see it now: Broken pipek time=02:18:08.45 [13:29:05 CEST] <chris_99> if you refresh, i also added a message from the pi's videocore, but that is beyond me [13:33:01 CEST] <squ> googling EINVAL shows socket is closed? [13:35:03 CEST] <squ> is that all or something else above that einval? [13:38:51 CEST] <chris_99> hmm, squ, do you think that means the rtmp socket, it's confusing to me, which pipe is closed [13:39:21 CEST] <squ> first one [13:39:37 CEST] <chris_99> you mean the raspivid --> ffmpeg one? [13:39:44 CEST] <squ> that which gives einval [13:40:01 CEST] <squ> ffmpeg replies with broken pipe [13:40:35 CEST] <chris_99> could it not be ffmpeg ---> youtube though? because 'av_interleaved_write_frame(): Broken pipe' wouldn't that be sending frames to youtube normally [13:41:04 CEST] <squ> no its that one with EINVAL [13:41:20 CEST] <squ> it should also say why it errors [13:41:54 CEST] <squ> redirect error output to two different files [13:43:13 CEST] <chris_99> good point, afaik that's the only thing that was printed that i could see though, the main gist message. When it happens again, i'll see if i can hook gdb to raspivid maybe [13:43:32 CEST] <chris_99> thanks a lot for pointing me in the right direction [13:43:56 CEST] <squ> I googled that thing and found it should show something like no memory or no space https://www.raspberrypi.org/forums/viewtopic.php?t=142280&p=940743 [13:44:05 CEST] <squ> before einval [13:46:14 CEST] <chris_99> someones mentioned to me before about ensuring enough gpu ram, that was set to 256M which seems to be above what they recommend. i'll see if anyone else has this error with high gpu ram set [13:48:54 CEST] <squ> don't forget to reply what the problem was [13:49:17 CEST] <chris_99> mm will do [15:07:40 CEST] <_julian> hi [15:08:06 CEST] <_julian> if I confiure ffmpeg with --enable-mediacodec, will it automatically enable the mediacodec hwaccels? [15:37:33 CEST] <DHE> they will become available. you may still need to explicitly select the codecs on your ffmpeg commandline. there's a wiki article with more info on hwaccels [15:38:11 CEST] <DHE> oh that's the android API... [15:46:34 CEST] <Th3On3> who can help me on a problem building ffmpeg under windows ? on #ffmpeg-devel there is no help... :( [15:47:24 CEST] <Th3On3> hi there... i am trying to build ffmpeg under windows, using msys2 and after i installed the packages needed to build, i go to ffmpeg rootpath i execute a default command: "./configure --arch=x86 --target-os=mingw32 --cross-prefix=i686-w64-mingw32- --pkg-config=pkg-config" and i get a "Unknown option: --target-os=mingw32". What am i doing wrong ????? [16:03:16 CEST] <BtbN> Do you even need all that cross compile stuff? You're compiling natively after all. [16:03:36 CEST] <BtbN> Anyway, that commandline looks fine for a cross compile. Are you building latest master? [16:14:41 CEST] <Th3On3> BtbN: hey ty [16:15:01 CEST] <Th3On3> BtbN: i am buiding the version "inside" xbmc [16:15:13 CEST] <BtbN> hm? [16:15:50 CEST] <Th3On3> BtbN: the version builded and used by xbmc build scripts [16:16:04 CEST] <BtbN> Well, they somehow messed up the configure script then. Use an official one [16:16:12 CEST] <Th3On3> ok [16:16:34 CEST] <BtbN> also, if you're actually using xbmc, it must be terribly outdated [16:17:49 CEST] <Th3On3> BtbN: version 3.3.2 [16:19:19 CEST] <Th3On3> i think is the last stable [16:19:28 CEST] <BtbN> it is. But it can't really be xbmc then [16:20:08 CEST] <Th3On3> i think the problem is some package is not installed (msys2) or not working correctly... [16:21:17 CEST] <Th3On3> yes... i have the same problem with ffmpeg-3.3.2 officila... then its other packege that is not installed [16:21:25 CEST] <Th3On3> or not working [16:24:51 CEST] <BtbN> It's the configure script complaining about an unknown option which is clearly should know. Something is very wrong with your environment if this happens with an official tarball or git [16:28:02 CEST] <Th3On3> BtbN: yes... its my env... but i can not figure out [16:28:21 CEST] <BtbN> paste the entire invocation and output [16:28:26 CEST] <Th3On3> ok [16:29:14 CEST] <Th3On3> i will try to buil official ffmpeg on my env [16:29:20 CEST] <Th3On3> and paste the output [16:30:35 CEST] <BtbN> your exact commandline works perfectly fine for me, so if you have an official ffmpeg source tree, it can only be your build env [16:30:46 CEST] <BtbN> It looks more like a replaced/broken configure script to me though [16:33:31 CEST] <Th3On3> BtbN: My env variables: https://pastebin.com/qAyc9ZCu [16:33:48 CEST] <BtbN> No env variable can break configure in that way. [16:33:54 CEST] <Th3On3> BtbN: my installed packages: https://pastebin.com/0k9pLn7j [16:34:17 CEST] <Th3On3> BtbN: output: https://pastebin.com/aMvr8G1j [16:45:45 CEST] <The_8472> is it save to feed image2 muxer with packets populated from multiple png encoders? to do the encoding on different threads. [16:45:49 CEST] <The_8472> *safe [17:03:34 CEST] <chris_99> squ, i'm 80% certain i know what the problem is, i can get the same errors in vcdbg, by disconnecting the router from the Internet [17:04:16 CEST] <chris_99> (vcdbg is what prints the raspberry pi's videocore messages, which i showed before with the einval messages) [17:10:13 CEST] <ThugAim> Hey guys. Been doing XDCAM EX 35 conversions of some recordings for edit, is there a way to enable smart rendering for Adobe Premier Pro? [17:10:37 CEST] <ThugAim> or at least to find out the exact settings of the XDCAM preset adobe uses in MXF? [17:37:35 CEST] <spencer> Hi, I am trying to encode streaming video to jpegs. I was able to do this with ffmpeg cli via the -r '30000/1001' flag. I want to do this with libav* now. I have tried setting the mjpeg codec ctx time base to 30000/1001 but my output is always the same framerate. [17:38:59 CEST] <spencer> I'm having trouble forcing the output framerate. How does libav* handle the -r switch internally? [17:39:28 CEST] <kepstin> spencer: the ffmpeg command line tool implements -r by using libavfilter and adding an "fps" filter [17:39:35 CEST] <kepstin> as an output option [17:39:46 CEST] <kepstin> if you're talking aabout -r as an input option, um... [17:40:20 CEST] <kepstin> I think the ffmpeg cli tools just "manually" sets the timebase and pts on each frame, in that case? [17:40:30 CEST] <spencer> This is for output option [17:40:48 CEST] <spencer> I think you may have pointed me in the right direction - I will look at libavfilter source code! [17:41:12 CEST] <zalaare> jkqxz: PR looks to solve my issue for sure. too bad my testing showed VP9 still isn't worth .02 [18:23:04 CEST] <thebombzen> atomnuker: I just read this in the manpages: "This encoder is the default AAC encoder, natively implemented into FFmpeg. Its quality is on par or better than libfdk_aac at the default bitrate of 128kbps." [18:23:17 CEST] <thebombzen> Does this make avcodec's aac encoder the best aac encoder around now? [18:23:19 CEST] <furq> well he would say that wouldn't he [18:24:37 CEST] <thebombzen> also do we know how it stacks up against libopus? [18:25:06 CEST] <furq> we don't know any of these things until someone does a listening test [18:25:07 CEST] <atomnuker> everything is worse than libopus [18:25:18 CEST] <atomnuker> there, saved you a whole listening test [18:25:59 CEST] <furq> how do you know that you're not secretly, a genious, [18:38:18 CEST] <thebombzen> thanks, good to know lol [18:38:31 CEST] <thebombzen> although I'll change my scripts to use aac over fdk_aac [18:40:29 CEST] <atomnuker> nah, don't, make listening tests [18:40:38 CEST] <atomnuker> either encoder has a chance to screw up [18:40:55 CEST] <atomnuker> its just that one is an underdog so when it screws up its automatically the worst [18:42:16 CEST] <furq> atomnuker: does the builtin encoder do vbr [18:44:00 CEST] <atomnuker> yes [18:44:28 CEST] <furq> is it any good [18:44:34 CEST] <furq> and also what's the range for -q [18:45:59 CEST] <IRC-Source_90991> Hi.. i am using ffmpeg to transcode a hls stream and playing out from a blackmagic card.i found when there is a drop in the source ffmpeg does not produce any output. Is there any that ican out a color bar or a pattern when the source get droped [18:46:35 CEST] <atomnuker> furq: its alright, experiment but start with low values, e.g. 0.2 [18:47:10 CEST] <atomnuker> there is no range, the value gets multiplied by some constant and mapped to a constant rate control factor [18:47:29 CEST] <furq> fun [20:26:07 CEST] <Hfuy> Hello. [20:27:17 CEST] <Hfuy> I'm attempting to convert a file from an uncompressed V210 AVI to ProRes, thus: https://pastebin.com/73rGyam4 [20:27:32 CEST] <Hfuy> Problem: Blacks become grey in the output. Looks like a studio-vs-full swing level issue. [20:27:45 CEST] <Hfuy> Is there a commandline argument I can use to control the luma handling behaviour? [20:29:58 CEST] <kerio> something something -vf colorspace [20:30:21 CEST] <Hfuy> I've found -color_range but I'm not sure what the values mean. It calls one value "MPEG" and one value "JPEG" which doesn't seem to make much sense to me. [20:30:23 CEST] <c_14> try adding -color_range pc before -i [20:30:34 CEST] <c_14> jpeg is full range, mpeg is limited range [20:30:35 CEST] <Hfuy> Oh, OK, I'll try that. [20:30:53 CEST] <Hfuy> Yes I got the impression that JPEG meant full swing and MPEG meant studio swing but that's a very very odd naming convention. [20:31:11 CEST] <ChocolateArmpits> I would suggest to run a waveform monitor on the video to really check it [20:31:20 CEST] <Hfuy> Oh, I can see it quite clearly. [20:31:52 CEST] <Hfuy> I can understand calling full range "PC" [20:32:11 CEST] <ChocolateArmpits> the player you are using may also be treating both files differently [20:32:22 CEST] <Hfuy> Yes it's a difficult problem. [20:32:38 CEST] <ChocolateArmpits> not to mention graphics card settings also impact how color are rendered [20:33:01 CEST] <Hfuy> I'm going with what Quicktime shows me, as it's a ProRes file and that's what the other guy will be using. [20:34:54 CEST] <The_8472> \o/ finally got image2+png to use all cores. I was indeed holding it wrong [20:35:13 CEST] <c_14> The_8472: I've heard sacrificing goats helps [20:35:47 CEST] <nicolas17> The_8472: how did you do that? [20:35:51 CEST] <Hfuy> Grr. VLC is the mostest wrongest video player. [20:36:49 CEST] <The_8472> I was calling flush too often, writing avpacket in lockstep with each encoded frame instead of only writing the packets when the encoder indicated it did not need flushing [20:37:31 CEST] <nicolas17> oh are you encoding to png? [20:37:35 CEST] <The_8472> yeah [20:38:35 CEST] <The_8472> 2 minutes instead of 5. not bad. need to assign some more cores to the VM. [20:38:43 CEST] <ChocolateArmpits> Hfuy, try using mpv [20:39:32 CEST] <Hfuy> MPV? I'll look it up. [20:39:58 CEST] <Hfuy> In the meantime, I'm faced with a stark choice. Either get bigger disks, or stop using -qscale 9 and -profile 4 on 4K ProRes [20:42:06 CEST] <nicolas17> Hfuy: I'm copying my raw material to an external hard disk so I can give it to a friend for him to upload to the cloud from the office, because from my home connection it will take like 15 days [20:42:36 CEST] <nicolas17> is this what they call big data? :v [20:43:01 CEST] <The_8472> sneakernet [20:45:45 CEST] <Hfuy> yeah, sneakernet. [20:46:04 CEST] <Hfuy> I just uploaded 1.2Gb in basically the time it took since my last comment. [20:46:06 CEST] <Hfuy> So five minutes. [20:46:11 CEST] <Hfuy> GB, I guess. [20:46:16 CEST] <nicolas17> I have 260GB of JPEGs [20:46:23 CEST] <nicolas17> and 1.5Mbps upstream [20:47:44 CEST] <Hfuy> Oh, dear. [20:47:51 CEST] <Hfuy> Where do you live, the Tri-Podunk Area? [20:48:26 CEST] <nicolas17> Buenos Aires [20:48:35 CEST] <nicolas17> 12Mbps down, 1.5Mbps up [20:48:50 CEST] <Hfuy> Let's see what I get hgere [20:49:20 CEST] <nicolas17> there's 25/3 and 50/6 plans now, I should check the prices... [20:49:28 CEST] <Hfuy> 45 down, about 17 up [20:49:34 CEST] <Hfuy> and that's not good for here [20:49:48 CEST] <Hfuy> This is FTTC [20:57:48 CEST] <Hfuy> do I want a -color_range PC on the output side, too [20:58:20 CEST] <Hfuy> Sadly it complains [NULL @ 000000000036bf40] [Eval @ 000000000022e860] Undefined constant or missing '(' in 'PC' [20:59:44 CEST] <Hfuy> It's happy with -color_range 2, though [21:01:48 CEST] <Hfuy> Still got grey blacks in h.264 material, thus: https://pastebin.com/BUi513k4 [21:08:14 CEST] <The_8472> have you compared the embedded color metadata? mediainfo should be able to output them. ffinfo can show them too with some option, but imo mediainfo output is more readable [21:09:20 CEST] <Hfuy> The problem I have is that there's approximately a lot of ways to alter this behaviour, right up to graphics card settings. [21:10:01 CEST] <The_8472> well yeah, but the player should (hopefully) behave identically for your input and your output if the metadata is the same [21:10:22 CEST] <Hfuy> I'm not sure that all formats even have that metadata, or that all players read it. [21:10:38 CEST] <Hfuy> It's been a bugbear in computer video engineering for ages, and ffmpeg hasn't historically handled it that well [21:11:41 CEST] <The_8472> well, i've seen it preserved in .mkv at least. not sure about .mp4 [21:13:30 CEST] <Hfuy> It varies. [21:13:47 CEST] <nicolas17> what can't mkv do? :P [21:14:11 CEST] <The_8472> play on toasters [21:14:12 CEST] <Hfuy> As do people's browser and graphics card settings, monitor settings, player settings, shoe size and favourite food [21:14:17 CEST] <Hfuy> all of which seems to affect things [21:14:19 CEST] Action: Hfuy looks gloomy [21:14:29 CEST] <nicolas17> video is hard [21:15:28 CEST] <Hfuy> I'm a cameraman by trade. Tell me. [21:16:10 CEST] <nicolas17> okay so [21:16:14 CEST] <nicolas17> I'm checking formatCtx->streams[0]->codec->codec_type == AVMEDIA_TYPE_VIDEO [21:16:17 CEST] <The_8472> on windows mpc-hc+madvr bypasses most gfx card shenanigans when it can. and it has a nice debug overlay that shows you the input (from codec) and output (to textures) modes [21:16:28 CEST] <nicolas17> and I get a warning because 'codec' is deprecated; what should I use instead? [21:19:12 CEST] <Hfuy> The_8472: I can play 'em back right. The problem is ensuring clients can, and ensuring that I can prove that what I'm doing is correct if their results are not. [21:19:13 CEST] <Hfuy> It's a nightmare. [21:22:14 CEST] <furq> Hfuy: your build has zimg, you might want to do the pixel format conversion with that [21:22:31 CEST] <nicolas17> ok, I can replace stream->codec->codec_type with stream->codecpar->codec_type [21:22:50 CEST] <nicolas17> but this tutorial is also using stream->codec for other purposes [21:23:03 CEST] <Hfuy> what's a zimg and do they come in pink [21:23:18 CEST] <furq> get rid of color_range and pix_fmt and try -vf zscale=rin=full:r=limited,format=yuv420p [21:23:43 CEST] <furq> !filter zscale [21:23:43 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#zscale [21:25:13 CEST] <Hfuy> does this look like it has grey blacks to you guys : https://vimeo.com/223663605 [21:25:26 CEST] <Hfuy> You can tell as it's letterboxed. [21:28:07 CEST] <furq> the letterbox is #000 in my browser [21:28:37 CEST] <nicolas17> yeah, but in the video itself nothing ever gets that dark [21:29:57 CEST] <nicolas17> ok I think I figured it out, instead of doing avcodec_copy_context from stream->codec (which is deprecated), I should do avcodec_parameters_to_context from stream->codecpar, right? [21:31:05 CEST] <Hfuy> That's OK [21:31:09 CEST] <Hfuy> It's graded quite soft contrast [21:31:24 CEST] <nicolas17> Hfuy: I thought that was your problem [21:31:43 CEST] <Hfuy> The issue is things that should be "technical black" ending up grey (and the overall contrast being therefore reduced) [21:31:59 CEST] <Hfuy> I'm not expecting the "artistic" bit of it to have full tech black in it, much. [21:32:18 CEST] <nicolas17> but is there anything in the video with pure black? [21:32:23 CEST] <furq> the letterbox [21:32:34 CEST] <DHE> nicolas17: if the ->codec field is deprecated but available, it should still work but give compiler and run-tmie warnings. but yes, codecpar is the right way to do things now and you should not touch AVStream->codec anymore [21:32:53 CEST] <nicolas17> DHE: I'm looking at this ancient crap http://dranger.com/ffmpeg/tutorial01.html [21:34:56 CEST] <DHE> nicolas17: now your'e expected to keep the AVCodecContext as an object you manage and use codecpar to pass the essential information the AVStream needs [21:35:18 CEST] <nicolas17> atm I'm decoding [21:38:07 CEST] <acresearch> people, i have 3000 .png images that i want to fuse into a video (problem is how can i make them into a video that plays in iphone)? [21:38:50 CEST] <The_8472> acresearch, https://trac.ffmpeg.org/wiki/Slideshow [21:39:11 CEST] <The_8472> https://stackoverflow.com/questions/24961127/ffmpeg-create-video-from-images [21:39:23 CEST] <acresearch> The_8472: i tried this method, but for some reason the .mp4 video that i get does not play in ios [21:39:39 CEST] <nicolas17> what command did you use? [21:40:26 CEST] <nicolas17> DHE: looks like I have a good AVCodec now [21:40:33 CEST] <nicolas17> er AVCodecContext [21:42:39 CEST] <acresearch> The_8472: the second URL's commands do not work, nicolas17: i used this command: ffmpeg -r 25 -f image2 -i video%4d.png -qscale:v 1 video.mp4 [21:43:48 CEST] <nicolas17> yeah who knows what codec that's even using :P [21:44:12 CEST] <acresearch> nicolas17: oh [21:44:20 CEST] <acresearch> ios need MPEG-4 right? [21:44:44 CEST] <The_8472> and probably 4:2:0. it might be encoding as 4:4:4 [21:45:18 CEST] <nicolas17> it needs MPEG-4 part 10 (aka H.264, aka AVC), if you just say "video.mp4" it might use MPEG-4 part 2 video codec [21:45:42 CEST] <acresearch> nicolas17: so what command should i add? [21:45:57 CEST] <nicolas17> -codec:v libx264 [21:46:03 CEST] <nicolas17> let me check what profiles ios supports [21:46:15 CEST] <acresearch> ok [21:48:00 CEST] <user890104> acresearch: https://trac.ffmpeg.org/wiki/Encode/H.264#iOS [21:48:15 CEST] <nicolas17> there you go [21:48:45 CEST] <nicolas17> after avcodec_alloc_context3 and avcodec_open2 do I only need to avcodec_free_context? [21:48:53 CEST] <acresearch> nicolas17: so this is the final command? (ffmpeg -r 25 -f image2 -i video%4d.png -codec:v libx264 -profile:v baseline -level 3.0 -qscale:v 1 video.mp4) [21:49:17 CEST] <nicolas17> acresearch: yes, but try it, it might need quality tweaking [21:49:50 CEST] <acresearch> nicolas17: i get an error from ffmpeg: http://paste.ubuntu.com/24983702/ [21:50:10 CEST] <nicolas17> huh [21:50:18 CEST] <nicolas17> so you need to explicitly pass -pix_fmt yuv420p too [21:52:05 CEST] <acresearch> nicolas17: http://paste.ubuntu.com/24983715/ [21:54:01 CEST] <acresearch> nicolas17: i did the reccomended change from the error, but i got this now: http://paste.ubuntu.com/24983727/ [21:55:15 CEST] <nicolas17> "height not divisible by 2" seems self-explanatory [21:55:27 CEST] <acresearch> nicolas17: what hight should i use? [21:55:44 CEST] <nicolas17> an even number that fits your needs [21:55:46 CEST] <acresearch> nicolas17: and which part of the command does it control the height? [21:56:03 CEST] <nicolas17> -s 1060x768 should work, dunno if it will look good, that depends on your video [21:56:37 CEST] <acresearch> nicolas17: Unable to find a suitable output format for '1060x768' [22:03:08 CEST] <alexpigment> acresearch: that looks like there's an error in your command line somewhere [22:03:13 CEST] <alexpigment> what's your current command line? [22:03:38 CEST] <acresearch> alexpigment: ffmpeg -r 25 -f image2 -i video%4d.png -codec:v libx264 -s 1060x768 -profile:v baseline -level 3.0 -pix_fmt yuv420p -crf:v 1 video.mp4 [22:04:37 CEST] <alexpigment> interesting [22:04:55 CEST] <alexpigment> if you put -f mp4 after your png file, does it work [22:05:37 CEST] <acresearch> alexpigment: ffmpeg -r 25 -f mp4 -i video%4d.png -codec:v libx264 -s 1060x768 -profile:v baseline -level 3.0 -pix_fmt yuv420p -crf:v 1 video.mp4 [22:05:51 CEST] <alexpigment> no, after the png [22:06:06 CEST] <alexpigment> -i video%4d.png -f mp4 [22:06:13 CEST] <acresearch> alexpigment: i think i got it working with this command: ffmpeg -f image2 -i video%4d.png -r 30 -vcodec libx264 -pix_fmt yuv420p -acodec libvo_aacenc -ab 128k -s 1060x768 video.mp4 [22:06:33 CEST] <nicolas17> why are you setting acodec if you don't have an audio input stream? [22:07:09 CEST] <alexpigment> nicolas can re-take-over this thing; I just figured I'd help in his absence [22:07:18 CEST] <nicolas17> ok looks like all the avpicture_* functions are deprecated [22:07:22 CEST] <acresearch> nicolas17: i don't know i found this command in a forum, added your -s 1060x768 and it worked [22:07:28 CEST] <nicolas17> so this tutorial is increasingly useless [22:08:20 CEST] <acresearch> nicolas17: which one? the one you sent? [22:08:55 CEST] <nicolas17> acresearch: I'm fighting with my own problem with the ffmpeg API :P [22:09:15 CEST] <nicolas17> acresearch: ffmpeg -r 25 -f image2 -i video%4d.png -f mp4 -codec:v libx264 -s 1060x768 -profile:v baseline -level 3.0 -pix_fmt yuv420p -crf:v 1 video.mp4 [22:09:25 CEST] <acresearch> nicolas17: ffmpeg and the whole video codec business is SO complicated i try to avoid it as much as possible, [22:09:59 CEST] <alexpigment> generally speaking, the output format should be assumed based on the file extension (.mp4 in your case). not sure why it complained about not being able to find an output format [22:10:00 CEST] <acresearch> i save these complicated commands for future use so i don't get a headache when i repeat my work [22:10:16 CEST] <acresearch> alexpigment: i thought so too [22:10:17 CEST] <alexpigment> unless it's breaking the command after the resolution rather than at the output file name [22:10:22 CEST] <nicolas17> that should work, but the video will probably be very large, you should try a crf of 20 or so (lower is better quality but larger file), then tweak it according to the file size and quality you get [22:10:41 CEST] <alexpigment> oh wow. crf 1 ;) [22:11:10 CEST] <nicolas17> 0 is lossless video :P [22:11:25 CEST] <alexpigment> 1 is basically lossless [22:11:36 CEST] <alexpigment> for that matter, 10 is basically lossless [22:13:57 CEST] <kerio> why's 480p 16:9 852 pixels wide instead of 853 or 854 [22:14:49 CEST] <nicolas17> probably because 852 is divisible by 4, which is a requirement for some codecs [22:14:59 CEST] <kerio> oic [22:15:13 CEST] <kerio> hold on why can't those codecs just encode an extra column of black pixels or whatever [22:15:31 CEST] <nicolas17> feel free to pad your video with an extra column of black pixels before feeding it to the encoder ;) [22:32:22 CEST] <shincode> ok [22:32:25 CEST] <shincode> in between this [22:32:40 CEST] <shincode> if i spam { int error = av_read_frame(formatContext, &packet); if (error == AVERROR_EOF) [22:32:43 CEST] <shincode> all day in a loop [22:32:48 CEST] <shincode> do i really need to sleep or wait [22:33:01 CEST] <shincode> is not av_Read_Frame basically waiting on nic [22:33:07 CEST] <shincode> and my other threads can do shit [22:33:38 CEST] <shincode> i dont want to burn processing in this loop but if av_read_frame allows for not murdering the cpu then im ok [22:36:09 CEST] <kepstin> shincode: av_read_frame will be blocking if you're reading from a slow input device, yeah. the only reason you'd have to sleep or wait in there is if you're reading from e.g. a local file and want to output in realtime for streaming or something like that. [22:41:50 CEST] <shincode> im reading rtsp [22:42:03 CEST] <shincode> and it feels like i get more likely chance to corrupt frames if i sleep inbetween for 15ms [22:42:11 CEST] <shincode> i have a 1920x1080 stream of 30 fps [22:42:22 CEST] <shincode> and set buffer size option to 6500000 [22:42:37 CEST] <shincode> which is roughly size of one frame in rgb space. 24 bpp [22:53:57 CEST] <shincode> thanks. [22:54:02 CEST] <shincode> more study msut be done [00:00:00 CEST] --- Fri Jun 30 2017

1 0

ffmpeg-devel.log.20170628
by burek 29 Jun '17

29 Jun '17

[00:14:07 CEST] <michaelni> BBB, libavcodec/libavcodec.a(vp9dsp_init_16bpp.o): In function `ff_vp9dsp_init_16bpp_x86': mingw32/src/libavcodec/x86/vp9dsp_init_16bpp.c:144: undefined reference to `ff_vp9_ipred_dr_32x32_16_avx2' [00:14:25 CEST] <BBB> maybe forgot to mark it as 64bit only? [00:14:36 CEST] <BBB> like, put an #if ARCH_X86_64 around it in the init file [00:14:56 CEST] <michaelni> just this one or more ? [00:15:04 CEST] <michaelni> it seems this was the only not linking [00:15:50 CEST] <BBB> I think just this one [00:15:59 CEST] <michaelni> ok, will test and then push [00:16:01 CEST] <BBB> sorry, shouldve picked that up during review [00:16:02 CEST] <BBB> ty [00:22:07 CEST] <cone-161> ffmpeg 03Hendrik Leppkes 07master:15b00aea418b: hwcontext_d3d11va: use correct license header [00:25:17 CEST] <wm4> eh [00:25:58 CEST] <atomnuker> ubitux: there's some aarch64 asm I removed in 4fdacf4c which seems like it can be reused (the fft15 asm), can you give it a go [00:26:43 CEST] <atomnuker> tried but I don't understand what it tries to do [00:27:08 CEST] <atomnuker> and I saw some conditional stuff so I'm not sure how good it is [00:32:05 CEST] <cone-161> ffmpeg 03Michael Niedermayer 07master:516c213f089d: avcodec/x86/vp9dsp_init_16bpp: Fix linking to missing ff_vp9_ipred_dr_32x32_16_avx2() on 32bit [01:46:34 CEST] <cone-161> ffmpeg 03James Almer 07master:d2ef9e6e7f9e: x86/vf_blend: use ABS2 macro [08:24:52 CEST] <ubitux> atomnuker: i guess i should [08:24:55 CEST] <ubitux> atomnuker: speaking of this [08:24:57 CEST] <ubitux> https://trac.ffmpeg.org/ticket/3921 [08:25:02 CEST] <ubitux> did you see that ticket? [08:25:37 CEST] <ubitux> it's not that much used anymore though since most code was switched to fft [08:25:50 CEST] <ubitux> (but it was because of speed reason afaik) [11:13:56 CEST] <wm4> jkqxz: I think LongChair is confused about how to proceed now [11:14:07 CEST] <LongChair> i am :) [11:15:37 CEST] <LongChair> I understand that we need to make sure that the API would fit other API as well, problem is that i don't have a good overview of "other" APIs, so was somehow wishing jkqxz and wm4 could come up with the proper structs & API agreement, so that i can arrange that to my specific hwdec :) [11:16:28 CEST] <jkqxz> There were no replies to emails, unfortunately. [11:18:00 CEST] <wm4> I mean yes, you did post a patch for a DRM hwcontext proposal [11:19:27 CEST] <jkqxz> So, go ahead with that proposal? [11:36:24 CEST] <wm4> jkqxz: posted a small comment on the Libav one, but it's just my old boring obsession with the representation of the plane descriptions [11:49:48 CEST] <jkqxz> Does that actually work for all cases? The planes must be in the order they are in the sw_format. [11:50:21 CEST] <wm4> I mean then the contents would change, not the indexes [11:53:10 CEST] <jkqxz> I'm not quite sure what you mean by "the contents"? [11:53:41 CEST] <wm4> NV12 will always have the luma plane as first, and the chroma as second, right? [11:54:07 CEST] <JEEB> wm4: yes that's how it should be [11:54:11 CEST] <jkqxz> In libav*, yes, because that's how we define the pixfmt. [11:54:27 CEST] <nevcairiel> its not "we" that defined that format =p [11:54:28 CEST] <wm4> and the index fields would allow to shuffle this around, as far as the description goes [11:54:28 CEST] <jkqxz> But when the two planes are separate objects they aren't ordered in any sense. [11:55:32 CEST] <jkqxz> And there is no XYZ format (in that order) with three planes, where someone could have two objects XZ and Y? [11:55:54 CEST] <jkqxz> That would be insanity, but that doesn't mean it doesn't exist. [11:56:12 CEST] <nevcairiel> just because it exists doesnt mean we have to support it =p [11:56:19 CEST] <wm4> I guess I see what you mean [11:57:28 CEST] <wm4> (if someone invents a YUVA format that has interleaved YA and UV planes I might have to punch this someone) [11:57:30 CEST] <jkqxz> In fact, the pixfmt here doesn't enforce that data[0] < data[1] for NV12 anyway. (And line-interleaved YUV420P works too...) [11:58:35 CEST] <wm4> LongChair: do you think the current proposed representation is easy to work with? (you have to set it up from rockchip and then push it into both EGL and DRM APIs) [11:59:37 CEST] <LongChair> which one is the current one ? (sorry there has been several discussions, and i'm not sure whcih oen we are talking about) [12:00:01 CEST] <wm4> jkqxz's DRM patch on the ML [12:05:22 CEST] <LongChair> @wm4 : lemme check [12:05:59 CEST] <jkqxz> Enforce this constraint? planes[i].object_index < planes[i+1].object_index || (planes[i].object_index == planes[i+1].object_index && planes[i].offset < planes[i+1].offset) [12:06:13 CEST] <jkqxz> (Therefore, you must put the object descriptors in the right order.) [12:07:39 CEST] <wm4> not sure if I can fully parse it... but yes maybe [12:12:10 CEST] <LongChair> @wm4: i just checked ML don't see any answer from mark on my patch other than old ones. are we talking about another patch he submitted , :) [12:13:17 CEST] <jkqxz> <http://ffmpeg.org/pipermail/ffmpeg-devel/2017-June/212546.html> [12:13:19 CEST] <wm4> yes he submitted it as separate patch [12:15:20 CEST] <LongChair> ok reading [12:19:48 CEST] <LongChair> ok i think rk stuff would fit in there [12:21:05 CEST] <LongChair> I will grab this patch and start working with it [12:21:47 CEST] <LongChair> jkqxz: for some reason i didn't see it in my mail. Sorry for not replying to this before :) [12:23:16 CEST] <LongChair> wm4: i'll try to also make a generic drmprime-egl & drmprime-drm opengl-hwdec-interops for mpv . will need to review it when i'm done to make sure i'm not overlooking some "other" things :) [12:27:02 CEST] <jkqxz> The one in ffmpeg should be usable standalone with something like "ffmpeg -c:v h264_rkmpp -i in.264 -vf 'format=drm_prime,hwdownload,format=nv12' -c:v libx264 out.264" (though probably rather slow). [12:29:19 CEST] <cone-946> ffmpeg 03Clément BSsch 07master:e4a27e2f2dea: lavc/arm: fix lack of precision in ff_ps_stereo_interpolate_neon [12:29:20 CEST] <cone-946> ffmpeg 03Clément BSsch 07master:edd041e64c0b: checkasm: add AAC PS tests [12:29:21 CEST] <cone-946> ffmpeg 03Clément BSsch 07master:9bbb0fbd314c: lavc/aacpsdsp: fix a few spaces (cosmetics) [12:29:22 CEST] <cone-946> ffmpeg 03Clément BSsch 07master:ff0ecef624e9: lavc/aarch64: add a few SIMD functions for AAC PS [12:29:23 CEST] <cone-946> ffmpeg 03Clément BSsch 07master:b12a36170b13: lavc/aacpsdsp: use ptrdiff_t for stride in hybrid_analysis [13:05:42 CEST] <atomnuker> ubitux: actually might be a better idea to port the x86 asm over to aarch64, I'm pretty sure it'll be faster, but oh well, if you got the time [13:05:54 CEST] <atomnuker> that bug ticket doesn't seem valid to me though [13:06:30 CEST] <ubitux> why? [13:09:06 CEST] <atomnuker> it works around uncomfortable twiddles in the asm rather than to modify the twiddles themselves [13:09:39 CEST] <ubitux> no i mean, why the ticket seems invalid? [13:13:20 CEST] <atomnuker> I don't get what its complaining about, that we're only slightly slower than fftw3? [13:15:40 CEST] <ubitux> atomnuker: http://kojevnikov.com/static/images/fft-bench-results.png [13:15:46 CEST] <ubitux> there is no asm for our code [13:16:30 CEST] <LongChair1> jkqxz: i tried to gran the patch from mailing list and apply that locally on master, but doesn't seem to apply. could you gist me the patch please ? [13:16:35 CEST] <LongChair1> grab* [13:17:05 CEST] <atomnuker> ubitux: there isn't? holy shit [13:26:04 CEST] <durandal_1707> is there anything simdable in fft? [13:28:10 CEST] <durandal_1707> michaelni: fine to apply your utvideo patchset? [14:05:51 CEST] <jkqxz> LongChair1: Hmm, it collides with wm4's d3d11 changes. [14:08:29 CEST] <jkqxz> Rebased (but not tested): <http://ixia.jkqxz.net/~mrt/ffmpeg/drm/0001-lavu-Add-DRM-hwcontext.patch>. [14:10:20 CEST] <cone-946> ffmpeg 03Michael Niedermayer 07master:1835c5e7a4fd: avcodec/utvideodec: Move bitstream end check out of inner loop [14:10:21 CEST] <cone-946> ffmpeg 03Michael Niedermayer 07master:9c604b34d435: avcodec/utvideodec: hardcode vlc bits [14:10:22 CEST] <cone-946> ffmpeg 03Michael Niedermayer 07master:676a589c936b: avcodec/utvideodec: enable unchecked bitreader [14:10:23 CEST] <cone-946> ffmpeg 03Michael Niedermayer 07master:5eb4701b7d64: avcodec/utvideodec: bswap directly without memcpy [14:10:24 CEST] <cone-946> ffmpeg 03Michael Niedermayer 07master:850c6db97d1f: avcodec/utvideodec: Factor multiply out of inner loop [14:19:47 CEST] <kierank> http://obe.tv/about-us/obe-blog/item/45-optimising-and-modernising-ffmpeg-s… [14:20:50 CEST] <kierank> can someone add that to HN [14:20:55 CEST] <kierank> my account is on noslack [14:22:15 CEST] <ubitux> kierank: https://news.ycombinator.com/item?id=14653459 [14:22:26 CEST] <kierank> thanks! [14:23:18 CEST] <LongChair> jkqxz: thanks, will try it tonite :) [14:41:21 CEST] <cbsrobot> kierank: in your post, the last character in the link to http://www.inf.puc-rio.br/~roberto/lpeg/) should be removed [14:41:32 CEST] <kierank> thanks [14:56:45 CEST] <durandal_170> kierank: why do you not make more full timed ffmpeg devs? [14:57:22 CEST] <kierank> durandal_170: because we have non-ffmpeg stuff to do [14:57:28 CEST] <kierank> J_Darnley: https://www.reddit.com/r/programming/comments/6k07as/optimising_and_moderni… [14:57:32 CEST] <kierank> maybe you want to answer that [15:01:27 CEST] <wm4> lol is that really the first post [15:01:32 CEST] <J_Darnley> Oh many reasons but mostly because I thinkt they are shit. [15:01:32 CEST] <iive> Is that article written by J_Darnley ? I don't see name attached to it. [15:02:27 CEST] <kierank> wm4: it's very fashionable to use intrinsics [15:02:55 CEST] <J_Darnley> Top of my list of why I hate them: about 6 different functions for movd [15:03:45 CEST] <nevcairiel> the magic of intrinsics: you dont even need functions for that, you can just assign a variable to make it generate that! :D [15:05:13 CEST] <nevcairiel> the main reason against intrinsics is that you're still at the mercy of the compiler, and for many algorithms it really isnt even significantly easier to write either, since the worst you need are some loops [15:05:40 CEST] <durandal_170> divisions [15:06:02 CEST] <iive> well, intrinsics are not so bad, for as long as you have 1:1 transition of code to assembly. [15:07:04 CEST] <durandal_170> they are bad. period. [15:07:34 CEST] <wbs> I was surprised once to notice that clang/llvm actually is pretty good at intrinsics; there's an odd mpegvideo function that somebody from linaro ported to aarch64 by making an intrinsics version (pretty much based on the arm assembler); I tried making a 1:1 port of the arm assembly to aarch64 and compare that to the intrinsics; for gcc, the handwritten assembly was faster, but clang/llvm managed to [15:07:40 CEST] <wbs> make the intrinsics even faster than that [15:08:55 CEST] <nevcairiel> as long as you write only intrinsics and only use C as little as required for contorl flow etc, msvc also generates the expected assembly instructions directly, but if you start mixing more C in there, it gets weird fast [15:09:13 CEST] Action: durandal_170 gonna push prores patches [15:10:23 CEST] <J_Darnley> As far as I can tell, you suggest I just write "mm1 = pmaddwd(mm1, mm2)" and that is somehow better than assembly? [15:10:38 CEST] <ubitux> so i opened libavutil/cpu.c [15:10:40 CEST] <ubitux> and now i'm sad [15:11:19 CEST] <iive> well, every time somebody talks about intrinsics, in my memory i see the disassembly of intrinsic code compiled with non SIMD ops. just regular assembly.... [15:11:20 CEST] <kierank> why [15:12:05 CEST] <ubitux> almost duplicated options [15:13:12 CEST] <TMM> In my uses of intrinsics it usually works pretty well. You just have to be very careful about what you do with the special datatypes [15:13:34 CEST] <TMM> as soon as you do anything with the variables that's outside of the scope of the intrinsic you're using you're going to get a disaster [15:13:47 CEST] <TMM> ridiculous amount of copying,packing,unpacking etc [15:13:54 CEST] <J_Darnley> Perhaps one of you people can demonstate how I can use constants from memory? [15:31:21 CEST] <kierank> J_Darnley: are you going to reply [15:37:17 CEST] <J_Darnley> No. I don't have a reddit account for it is horrible censorious place [15:40:09 CEST] <iive> J_Darnley: you dare to oppose the hivemind?! ;) [15:41:40 CEST] <kierank> ok i will answer [15:54:17 CEST] <kierank> BBB: http://obe.tv/about-us/obe-blog/item/45-optimising-and-modernising-ffmpeg-s… [15:54:19 CEST] <kierank> james wrote that [15:54:24 CEST] <BBB> woohoo [15:54:27 CEST] <BBB> is it committed? [15:54:33 CEST] <BBB> please talk about this @ vdd [15:54:37 CEST] <BBB> its important that we talk about shit [15:54:46 CEST] <kierank> part 1 is just the conversion, part 2 and 3 will be the sse [16:06:09 CEST] <BBB> when will part 2 be written? [16:06:16 CEST] <BBB> or better: when will it be pushed? :-p [16:07:18 CEST] <kierank> dunno [16:07:20 CEST] <kierank> ask J_Darnley [16:14:14 CEST] <J_Darnley> Ha. I should probably get on that. I'm bored of this vc2 transform stuff. I wish to become bored of mpeg2 transform stuff again. [16:14:39 CEST] <BBB> hm...? [16:14:44 CEST] <BBB> whats so bad about the vc2 transform? [16:14:51 CEST] <BBB> isnt vc2 dirac-intra? [16:15:05 CEST] <kierank> J_Darnley: i thought all the mpeg2 stuff was fixed now? [16:15:08 CEST] <kierank> by you and ronald? [16:15:17 CEST] <BBB> yes but he needs to actually push it [16:15:18 CEST] <J_Darnley> It is. I just need to rebase and push, I think [16:15:22 CEST] <BBB> and thats scary [16:15:23 CEST] <kierank> J_Darnley: then do it! [16:15:27 CEST] <kierank> ah [16:15:37 CEST] <BBB> because when you push it, ffmpeg will suddenly be free of evil mmx code in your runtime [16:15:39 CEST] <BBB> just imagine that [16:15:48 CEST] <J_Darnley> pfft [16:15:52 CEST] <BBB> :-p [16:15:55 CEST] <J_Darnley> I bet it is still there somewhere [16:16:12 CEST] <BBB> I believe dequant/quant is still mmx, yes [16:21:29 CEST] <wm4> I wonder if we could remove the self-modifying mmx code from libswscale, that is somehow hacked into the common part with OS specific further hacks [16:21:43 CEST] <wm4> and which is only used for a non-default scaler that is known as broken [16:21:48 CEST] <wm4> (can't make that shit up) [16:22:16 CEST] <iive> i thought it is used for the default scaler and is the fastest one. [16:23:01 CEST] <BBB> the fast_bilinear one? [16:23:15 CEST] <BBB> I tried to remove or rewrite it once, and couldnt do it [16:23:17 CEST] <wm4> yes [16:23:18 CEST] <BBB> I wouldnt spend time on it [16:23:26 CEST] <BBB> not worth it [16:23:43 CEST] <iive> what do you mean by that you couldn't do it? [16:23:56 CEST] <iive> you couldn't write static version of similar speed? [16:52:43 CEST] <cone-946> ffmpeg 03Vittorio Giovara 07master:3426832ac307: hevc: Add support for alternative transfer characterics SEI [17:02:23 CEST] <cone-946> ffmpeg 03Paul B Mahol 07master:42f516b5d356: avcodec/interplayvideo: check that video_size is >0 [17:16:16 CEST] <cone-946> ffmpeg 03Paul B Mahol 07master:613ccdaaacaa: avcodec/interplayvideo: use int16_t instead of short [17:16:17 CEST] <cone-946> ffmpeg 03Paul B Mahol 07master:ed782bebf508: avcodec/interplayvideo: fix dead-lock [17:19:32 CEST] <cone-946> ffmpeg 03Paul B Mahol 07master:c1d1274bfc56: avcodec/interplayvideo: return void [17:20:08 CEST] <kierank> can anyone upvote this https://www.reddit.com/r/programming/comments/6k07as/optimising_and_moderni… [17:29:08 CEST] <wm4> didn't BBB have good explanations on why intrinsics are not the way to go for ffmpeg [17:33:25 CEST] <BBB> our documentation has some text about it [17:33:43 CEST] <BBB> I have played with intrinsics a few times and never found it quite ideal [17:33:57 CEST] <BBB> the performance is never quite what you can get manually [17:34:03 CEST] <BBB> its easier [17:34:15 CEST] <BBB> so the question is one between effort or performance [17:36:00 CEST] <atomnuker> not just effort or performance, one's likelier to give you alzheimer's later in life than the other [17:36:14 CEST] <Gramner> nasm preprocessor is much, much better than the c preprocessor is a pretty big deal. also if you want to use modern instruction sets it's usually a lot easier to upgrade the assembler than to upgrade the compiler [17:36:50 CEST] <BBB> preprocessor is a good reason for bigger, more complex functions, yes [17:37:07 CEST] <BBB> writing a 32x32 idct in intrinsics sounds hideous [17:37:43 CEST] <Gramner> also the compiler might not even support new instruction sets at all. msvc still doesn't support avx-512 iirc [17:37:58 CEST] <J_Darnley> That's not saying much [17:41:00 CEST] <atomnuker> J_Darnley: hey, you still use windows, don't insult the only compiler for your os [17:41:04 CEST] <cone-946> ffmpeg 03James Darnley 07master:8b19467d07d5: avcodec/x86: allow future 8-bit simple idct to have "DC only hack" [17:41:05 CEST] <cone-946> ffmpeg 03James Darnley 07master:d7246ea9f229: avcodec/x86: add an 8-bit simple IDCT function based on the x86-64 high depth functions [17:41:06 CEST] <cone-946> ffmpeg 03James Darnley 07master:0c2acccd4be4: avcodec/x86: use new x86-64 functions for -idct simple [17:41:17 CEST] <kierank> OMG [17:41:22 CEST] <J_Darnley> At long last [17:41:25 CEST] <Gramner> I also never understood why they insist on renaming every instruction in instrinsics. makes it harder to parse for no good reason [17:54:01 CEST] <gh0st__> Hm, libvpx seems to prefer intrinsics over manually writing assembly. [17:56:22 CEST] <nevcairiel> the only real reason for intrinsics is that its "easier", you dont need fancy build-system support, you can use C for control flow, etc [17:56:56 CEST] <BBB> so [17:57:18 CEST] <BBB> example number: libvpx sse2 idct32x32 is 3619.8 cycles (intrinsics), ours is 2563.6 cycles (assembly) [17:57:40 CEST] <BBB> they do exactly identical operations, except that libvpx doesnt zero the coefficients and the input is not pre-transposed [17:57:46 CEST] <nevcairiel> that doesnt really say that much, you would probably need to use the exact same code in both variants [17:58:00 CEST] <BBB> I plugged them both in our checkasm [17:58:43 CEST] <BBB> I cant find their avx2 version :-/ [17:59:14 CEST] <BBB> it looks like they dont have one [19:39:50 CEST] <cone-946> ffmpeg 03Paul B Mahol 07master:f0edab6e63ec: avcodec/interplayvideo: use correct context when checking for enough bytes [21:37:02 CEST] <durandal_170> atomnuker: report? [21:38:15 CEST] <atomnuker> buggered, easiest way would be to have 2 readers with the same api [21:41:55 CEST] <ubitux> you're looking at the bitstream reader? [21:42:58 CEST] <atomnuker> I looked at it last night [21:43:24 CEST] <atomnuker> got some work done on coverting the api [21:44:23 CEST] <durandal_170> just add flag cache 64 bit something [21:44:46 CEST] <durandal_170> like there is for unchecked bitreader [21:47:16 CEST] <atomnuker> I think replacing it is better [21:48:19 CEST] <iive> just write one that is faster on 32 bit and much faster on 64 [21:50:19 CEST] <atomnuker> iive: are you on a 32 bit system? [21:50:43 CEST] <iive> i have a cpu that can run 32 bit :D [21:51:53 CEST] <atomnuker> makes me wonder if there's a system which can't run in 32 bit mode [21:52:34 CEST] <BBB> most arm machines are 32bit [21:52:36 CEST] <J_Darnley> arm? powerpc? itanium? [21:53:42 CEST] <atomnuker> OH CRAP, I FORGOT [21:54:09 CEST] <BBB> J_Darnley: btw, WOOHOO! [21:54:11 CEST] <BBB> beer [21:54:24 CEST] <J_Darnley> Indeed [21:54:57 CEST] <J_Darnley> Though I wonder whether there is an x86 chip that somehow avoids needing <64 bit for booting [21:56:16 CEST] <BBB> I did not expect to ever get rid of some of that inline asm code [21:56:20 CEST] <BBB> very happy it went down [21:57:23 CEST] <J_Darnley> It certainly uncovered a lot of bugs elsewhere in the code. [22:18:17 CEST] <kwizart> what is the current situation if one enable fdk-aac with gpl and publicly redistribute such binary ? [22:18:30 CEST] <JEEB> the fdk-aac license isn't compatible with GPL [22:18:33 CEST] <JEEB> still nonfree [22:18:41 CEST] <JEEB> thus if you don't need HE-AAC then just use the internal encoder [22:18:52 CEST] <kwizart> is this something bad, but tolerated ? or will you ask the person to stop redistributing the binaries ? [22:18:53 CEST] <JEEB> it has been updated in late 2015-early 2016 [22:19:21 CEST] <JEEB> please don't distribute them, and people have scolded companies that have done it [22:20:40 CEST] <kwizart> okay, I don't plan, myslef, but there is a person doing so [22:21:01 CEST] <kwizart> and it's breaking ours users [22:21:40 CEST] <BtbN> doesn't --enable-gpl also allow fdk, without nonfree? [22:21:47 CEST] <JEEB> no [22:22:15 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=configure;h=282114d2688c3134… [22:22:15 CEST] <BtbN> JEEB, https://github.com/FFmpeg/FFmpeg/blob/master/configure#L3605 yes [22:22:55 CEST] <kwizart> well, one can build a lgpl binary that has fdk-aac enabled ? or I am wrong ? [22:23:03 CEST] <BtbN> yes, looks like it [22:24:05 CEST] <RiCON> same thing with openssl [22:24:21 CEST] <BtbN> It's questionable, pretty sure the fdk thing is lgpl incompatible as well [22:25:57 CEST] <JEEB> I think with LGPL the primary point moves to "are you compliant with fdk-aac's license?" [22:26:30 CEST] <BtbN> It's not a very restrictive license [22:26:46 CEST] <BtbN> just a bit weird, and thus making it incompatible [22:27:02 CEST] <kwizart> BtbN, my lawer say fdk-aac is lgpl period, but he's a little extremist. I would rather listen what you think "as ffmpeg projet" [22:28:13 CEST] <JEEB> it's similar in the vein that you have to give the sources to the library to binary recepient [22:28:29 CEST] <JEEB> but it has all sorts of funky things in there [22:30:20 CEST] <kwizart> about usage ? probably, but as soon as code copyrights apply this is lgpl. The others points 'license' as soon as you don't consider them as copyrights don't stand up [22:30:56 CEST] <kwizart> well, he made a rather quick analysis, so I wouldn't trust him either [22:31:20 CEST] <JEEB> anyways, I'm just happy the internal AAC encoder got improved [22:42:14 CEST] <kierank> kwizart: it's not [22:42:19 CEST] <kierank> it forces you to get a patent licence [22:42:26 CEST] <kierank> which is an additional requirement [22:55:12 CEST] <tmm1_> mateo`: have you looked into using getOutputImage() instead of getOutputBuffer() for mediacodec_wrap_sw_buffer() [22:58:20 CEST] <kwizart> kierank, yes this is my understanding also , and that we are in the good side not linking our ffmpeg built with fdk-aac [22:58:37 CEST] <tmm1_> n/m i misread the docs, reading from Image would be the same thing [22:58:45 CEST] <kwizart> thx for the answear, and sorry for bringing this topic here [22:59:02 CEST] <kwizart> FYI, the issue behind is way more complex: [23:00:14 CEST] <kwizart> The Fedora Councils want to allows others 3rd part repositories is the release media (not enabled by default) [23:01:23 CEST] <kwizart> one if it's repositories is hold by a person who produce incompatible package with our RPM Fusion project (rpmfusion.org) such as a ffmpeg built with fdk-aac [23:04:15 CEST] <wm4> I still wonder why we haven't removed fdk-aac [23:04:47 CEST] <BtbN> Because it's the best he-aac encoder. [23:05:20 CEST] <wm4> but why should it be in ffmpeg [23:05:34 CEST] <BtbN> why shouldn't it? [23:05:40 CEST] <wm4> if they don't want to make it (L)GPL compatible we should tell them to fuck off [23:06:02 CEST] <BtbN> I don't see the problem, there are plenty non-free libraries that can be used by ffmpeg [23:06:04 CEST] <nevcairiel> they dont care, they made the encoder for android, its the community that extracted the sources from the android sources and packaged it [23:06:12 CEST] <nevcairiel> because its high quality [23:06:29 CEST] <wm4> BtbN: only openssl and (weirdly) decklink [23:06:40 CEST] <BtbN> and various nvidia stuff [23:06:53 CEST] <wm4> that's not non-free [23:07:04 CEST] <BtbN> npp and scale_cuda is [23:07:14 CEST] <wm4> well they're not in the nonfree list anyway [23:07:20 CEST] <RiCON> they used to be [23:07:23 CEST] <nevcairiel> there is a separate list for hwaccel things [23:07:24 CEST] <BtbN> They are in the hwaccel_nonfree list [23:07:39 CEST] <RiCON> until BtbN (im)ported the headers [23:07:47 CEST] <BtbN> Not all of them [23:08:01 CEST] <BtbN> So there's parts left that still need the actual non-free parts [23:08:05 CEST] <wm4> so cuda has both free and nonfree support? [23:08:21 CEST] <BtbN> indeed [23:08:25 CEST] <RiCON> cuvid and nvenc are free, libnpp and cuda-based filters aren«t [23:08:31 CEST] <wm4> libnpp is also another thing where we should actually not enable nvidia's bullshit [23:08:49 CEST] <wm4> just tell people to buy intel if they really want to do hw transcoding [23:08:50 CEST] <BtbN> I actually think libnpp should be removed, now that there's scale_cuda [23:09:12 CEST] <BtbN> it's a mess anyway, most of the algorithms it advertises do nothing [23:09:18 CEST] <RiCON> npp is actually obsoleted by scale_cuda, but isn't scale_cuda also non-free? [23:09:24 CEST] <BtbN> it is [23:09:34 CEST] <BtbN> But at least it's not as messy [23:10:19 CEST] <RiCON> i remember libnpp needing cuda sdk installed to both compile and run [23:10:22 CEST] <RiCON> scale_cuda too? [23:10:33 CEST] <wm4> meanwhile I feel sorry for the libturing guy [23:10:45 CEST] <wm4> went through all of our bullshit to cosmetically perfectionalize his patch [23:11:06 CEST] <wm4> maybe I should just apply the patch [23:11:34 CEST] <atomnuker> yet they did not go through any bullshit to make an API [23:11:43 CEST] <atomnuker> they haven't got one still... [23:12:15 CEST] <iive> what is libturing? [23:12:29 CEST] <atomnuker> and its worse than x265 without any hope it'll be better [23:12:30 CEST] <nevcairiel> it has a similar api to how we use libx264 or libx265, it parses string commands, i dont see why everyoen makes such a fuzz about that [23:19:41 CEST] <iive> wm4: go ahead and commit it. [23:20:51 CEST] <BtbN> I still don't get the whole point of libturing in itself [23:21:10 CEST] <RiCON> another competitor to x265 [23:21:13 CEST] <RiCON> like kvazaar [23:23:50 CEST] <iive> x265 does need more competition. [23:25:14 CEST] <atomnuker> it won't improve [23:25:50 CEST] <iive> turing or x265 ? [23:26:01 CEST] <atomnuker> either, its not developed by neckbeards living in their parents basements [23:26:11 CEST] <j-b> +1 [23:26:32 CEST] <iive> how about kvazaar? [23:28:15 CEST] <atomnuker> it looked better on paper, though they used hm, the reference encoder as a reference [23:28:41 CEST] <jkqxz> The libturing people threw more stuff over the wall a month ago: <https://github.com/bbc/turingcodec/commit/09a838c9feeb43ac410391e300b8b53ff…>. Open development ftw! [23:31:07 CEST] <wm4> that looks like a code drop [23:32:00 CEST] <wm4> git merge --squash or something [23:32:18 CEST] <BtbN> Or some dev having no clue about git [23:32:24 CEST] <BtbN> and commiting once every half year [23:41:53 CEST] <cone-658> ffmpeg 03Michael Niedermayer 07master:bc6ab72bc7af: avcodec/vb: Check vertical GMC component before multiply [23:41:54 CEST] <cone-658> ffmpeg 03Michael Niedermayer 07master:c709f009dad2: avcodec/cfhd: Fix invalid left shift of negative value [23:49:01 CEST] <jkqxz> LongChair: Do I need a funny version of the Rockchip stuff? MPP_DEC_GET_FREE_PACKET_SLOT_COUNT doesn't exist in the one I have, nor does it appear to be present in the current git version. [23:50:46 CEST] <jkqxz> (And Google finds it only in your patch on the ffmpeg list...) [00:00:00 CEST] --- Thu Jun 29 2017

1 0

ffmpeg.log.20170628
by burek 29 Jun '17

29 Jun '17

[00:02:24 CEST] <kepstin> ultrav1olet: another thing to try is to use mkvmerge (from mkvtoolnix) to append tracks from one file to the other, rather than using ffmpeg to try to make a single video stream [00:03:11 CEST] <kepstin> something like mkvmerge -o combined.mkv part1.h265.mkv + part2.h265.mkv [00:03:17 CEST] <ultrav1olet> I'm already trying this option [00:03:20 CEST] <nicolas17> what should I use to do simple video transitions? [00:03:37 CEST] <ultrav1olet> nicolas17: non linear video editor [00:04:12 CEST] <kepstin> you can do simple-looking transitions with ffmpeg filters but actually writing the command lines? Not so simple :) [00:04:24 CEST] <ultrav1olet> kepstin: Warning: The track number 0 from the file 'part2.h265.mkv' can probably not be appended correctly to the track number 0 from the file 'part1.h265.mkv': The codec's private data does not match (lengths: 1825 and 1822). Please make sure that the resulting file plays correctly the whole time. The author of this program will probably not give support for playback issues with the resulting file. [00:04:47 CEST] <nicolas17> yeah I think the transitions I need are totally possible with ffmpeg video filters [00:05:05 CEST] <kepstin> ultrav1olet: well, then I guess that file will probably show the same issue :/ [00:05:34 CEST] <nicolas17> but getting video A to play normally for N seconds, then do the transition to video B, then play video B, and sync them at the point I want... that would need a messy filtergraph string [00:05:57 CEST] <nicolas17> oh I could use MLT, I have used it before, forgot about it... [00:06:00 CEST] <ultrav1olet> kepstin: no dice. the output is similarly broken. seems like you cannot merge two HEVC streams with different encoding parameters. This doesn't sound right. [00:06:31 CEST] <kepstin> ultrav1olet: well, the same's true of h264, it just seems like hevc is a little more touchy about it. [00:06:47 CEST] <JEEB> I have a feeling that mkvmerge might just be throwing away one set of parameter sets [00:06:56 CEST] <JEEB> and AVC concatenation and HEVC concatenation works the same way [00:07:04 CEST] <JEEB> make sure you have all parameter sets and start on a RAP [00:07:57 CEST] <ultrav1olet> first file encoding string: -vf fps=30 -an -c:v libx265 -preset veryslow -x265-params keyint=600:min-keyint=30:bframes=16:crf=20:no-sao=1 out.mkv [00:08:15 CEST] <ultrav1olet> second file encoding string: -vf fps=30 -an -c:v libx265 -preset veryslow -tune grain -x265-params keyint=600:min-keyint=30:bframes=16:crf=20 [00:08:55 CEST] <ultrav1olet> as soon as MPV/ffplay reaches the second file, the output turns to utter garbage [00:09:03 CEST] <JEEB> that means the parameter sets aren't there [00:09:12 CEST] <JEEB> parameter sets are what initialize the decoder [00:09:23 CEST] <JEEB> and if they're different enough that just doesn't work [00:09:26 CEST] <ultrav1olet> in that case merging these files is not even possible [00:09:34 CEST] <JEEB> ... [00:09:36 CEST] <JEEB> it is [00:09:37 CEST] <kepstin> which means that the ffmpeg concat demuxer isn't handling hevc in mkv correctly [00:09:38 CEST] <ultrav1olet> which totally sucks [00:10:14 CEST] <ultrav1olet> I've always thought that I frames are more or less independent [00:10:30 CEST] <JEEB> PARAMETER SETS DANG IT [00:10:31 CEST] <ultrav1olet> only P and B are dependant [00:11:06 CEST] <JEEB> now the perfect way of doing that would be to create an mp4 with two sets of sample description whatever it was called, which contain the parameter sets. and then map the samples to the correct one [00:11:07 CEST] <ultrav1olet> JEEB: should I file a bug report? [00:11:10 CEST] <JEEB> no [00:11:16 CEST] <JEEB> unless the thing is a bug in FFmpeg [00:11:25 CEST] <kepstin> JEEB: there are two mkv files containing hevc encoded by ffmpeg. they both play fine. After being concatenated by ffmpeg using the concat demuxer, the file does not play back [00:11:31 CEST] <ultrav1olet> mkvtoolnix produces the same result [00:11:54 CEST] <JEEB> kepstin: which means that both fuck the second parameter sets somewhere in the middle of it [00:12:08 CEST] <JEEB> which is probably why that warning happens, that if the parameter sets are different enough you will be fucked [00:12:23 CEST] <kepstin> looks like mkvtoolnix drops it, yeah, and I guess ffmpeg does too only silently. [00:12:33 CEST] <JEEB> also the concat shit in lavf is what it is [00:12:52 CEST] <JEEB> I've only used the lavfi concat because that IIRC decoded the things separately and thus not being affected by bullshit [00:13:22 CEST] <JEEB> (of course doesn't work when you want to concat already encoded streams so welp) [00:13:35 CEST] <ultrav1olet> JEEB: can I force ffmpeg to rebuild the output for each new I frame sequence without reencoding? [00:14:12 CEST] <kepstin> hmm. so would extracting the video tracks to elementary streams then concatenating those work, maybe? :/ [00:14:27 CEST] <nicolas17> would it work to "transcode" with -vcodec copy? [00:14:28 CEST] <JEEB> that would only work to a limit [00:14:38 CEST] <JEEB> as in what kepstin said [00:14:50 CEST] <ultrav1olet> nicolas17: how? [00:15:01 CEST] <JEEB> nicolas17: no [00:15:17 CEST] <JEEB> nicolas17: seemingly whatever they used for concat stripped the latter parameter sets [00:15:25 CEST] <JEEB> copying that shit doesn't help [00:15:38 CEST] <nicolas17> so you need actual transcoding? [00:15:47 CEST] <JEEB> no [00:15:55 CEST] <kepstin> nicolas17: wouldn't help, it's the concat prior to the transcode that's breaking it [00:16:09 CEST] <ultrav1olet> nope, never again - encoding with preset veryslow is very time demanding ;-) [00:16:21 CEST] <kepstin> I mean, you could use two separate inputs and the concat filter, do a full decode-renencode, but that defeats the point of this whole thing [00:16:48 CEST] <ultrav1olet> 0.8fps or so for 1080p source on my PC ;-) [00:16:55 CEST] <JEEB> that's fast enough [00:16:58 CEST] <nicolas17> I guess if you use the concat filter, just like with any filter, you don't get to use vcodec copy anymore? [00:17:11 CEST] <JEEB> nicolas17: no shit, sherlock [00:17:24 CEST] <ultrav1olet> My current concat is simple: ffmpeg -f concat -i list.txt -c copy out.mkv [00:17:26 CEST] <JEEB> anyways, what you most likely need is to make every RAP have the parameter sets [00:17:38 CEST] <JEEB> then you concatenate that [00:17:49 CEST] <ultrav1olet> that sounds like Chinese to my ears [00:18:10 CEST] <JEEB> that way no matter where you seek you should get the parameter sets matching the content first [00:18:18 CEST] <JEEB> and then the rest [00:18:31 CEST] <iive> JEEB: actually i was wondering if x264 could have a mode where it takes an extradata, uses it to configure itself and encode the input frame, [00:18:45 CEST] <iive> aka something that would help editing [00:19:11 CEST] <JEEB> the perfect way is still what I noted there up in the log regarding an mp4 with multiple pieces of initialization data and then mapping the parts of the file to the correct set [00:19:18 CEST] <JEEB> but I'm not sure how simple that is to write [00:19:35 CEST] <JEEB> for decoding I know libav added support for that, and FFmpeg might have merged it already [00:19:49 CEST] <JEEB> the less perfect alternative is to just copy the parameter sets all the way [00:19:52 CEST] <JEEB> to every RAP [00:20:01 CEST] <JEEB> as in, the matching ones [00:20:05 CEST] <iive> that -> multiple extradata mappings? [00:20:18 CEST] <JEEB> iive: yea, per-sample extradata stuff in mov/mp4 [00:20:25 CEST] <JEEB> I remember koda coding that up [00:20:41 CEST] <JEEB> but it's for decoding, so it doesn't help *creation* of such files :P [00:21:21 CEST] <iive> i'm sure somebody would write a program that concats a lot of different .mp4 into such rap [00:21:35 CEST] <nicolas17> what's a RAP? [00:21:43 CEST] <JEEB> Random Access Point/Picture [00:21:47 CEST] <kepstin> of course, in this example we have here, it's all in mkv files, not mp4... [00:22:07 CEST] <JEEB> matroska I think also supports it but I don't think much supports it :P [00:22:14 CEST] <JEEB> as in, multiple extradata blocks [00:22:30 CEST] <JEEB> thus as I noted, the simplest way is to somehow duplicate the parameter sets [00:22:37 CEST] <JEEB> so that they get applied to every RAP [00:22:46 CEST] <JEEB> dunno if mpegts muxer does it [00:22:58 CEST] <nicolas17> I used to know how to use MLT/melt [00:22:59 CEST] <nicolas17> :/ [00:23:00 CEST] <JEEB> then you concat that shit and hope for the best [00:23:22 CEST] <JEEB> if the concatenation didn't do anything extra "smart" [00:23:22 CEST] <kepstin> JEEB: that seems like the sort of thing that could be done in a bsf in ffmpeg, maybe? [00:23:48 CEST] <JEEB> then you should have the duplicated things still in your thing [00:23:57 CEST] <JEEB> and then it /should/ work, bar bugs in people's players [00:24:45 CEST] <JEEB> kepstin: I... guess? [00:27:20 CEST] <JEEB> anyways, both AVC and HEVC being hard to reconfigure or concat is just bollocks, stuff like broadcast changing the resolution is pretty much just that [00:27:26 CEST] <kepstin> but in the mean time, ultrav1olet, I guess you could try the good old "convert both files to mpegts, concatenate those, ???, profit" trick :/ [00:27:57 CEST] <JEEB> the problem is that the tools do tend to try and optimize, which then goes bonkers because you fed two different clips with different param sets [00:28:15 CEST] <JEEB> kepstin: yea and trying to make sure it duplicates the parameter sets at every RAP [00:28:22 CEST] <JEEB> otherwise seeks through the line can be "fun" [00:28:27 CEST] <ultrav1olet> I'd love to but as far as I remember mpegts doesn't support HEVC [00:28:39 CEST] <ultrav1olet> and it's only for AVC [00:28:40 CEST] <JEEB> then what are these broadcast samples I have on my hands? [00:28:47 CEST] <kepstin> ... hah, no. [00:28:55 CEST] <JEEB> or shall I link the DVB spec? [00:29:02 CEST] <ultrav1olet> I believe you ;-) [00:29:07 CEST] <ultrav1olet> how that can be done? [00:29:15 CEST] <kepstin> I would have expected mpegts to be basically the first 'container' to be able to hold hevc? [00:29:24 CEST] <furq> -i foo.mp4 -c copy -map 0 foo.ts [00:29:44 CEST] <furq> or mkv or whatever [00:29:46 CEST] <JEEB> let's see if the muxer or something else has an option to duplicate the parameter sets [00:30:08 CEST] <ultrav1olet> ffmpeg -i part1.h265.mkv -c copy -bsf h264_mp4toannexb output1.ts => Codec 'hevc' (174) is not supported by the bitstream filter 'h264_mp4toannexb'. Supported codecs are: h264 (28) [00:30:33 CEST] <kepstin> ultrav1olet: well, yeah, that's the h264 one, and you have h265...? [00:30:46 CEST] <JEEB> just try without manual bsfs :P [00:30:54 CEST] <JEEB> I /think/ that got automatized lately [00:30:55 CEST] <ultrav1olet> yep ;-) I've been talking about HEVC all along [00:31:09 CEST] <ArsenArsen> What homebrew formula do I need to get the development headers> [00:31:16 CEST] <ArsenArsen> ? not > >.> [00:31:36 CEST] <JEEB> ArsenArsen: ask whomever maintains the homebrew formula? [00:31:58 CEST] <JEEB> although to be honest you could just build a basic FFmpeg yourself with a custom prefix and utilize pkg-config to build against it :P [00:32:09 CEST] <ArsenArsen> I expected someone to know, but I don't have a Mac [00:32:24 CEST] <JEEB> yes, someone from /homebrew/ [00:32:59 CEST] <ultrav1olet> it worked!!! [00:33:00 CEST] <JEEB> how downstreams (be it a lunix distro or anything else) package is not really any of upstream's concern [00:33:36 CEST] <ArsenArsen> Good point. Thanks [00:34:01 CEST] <JEEB> also did you check that the thing didn't just install the stuff? [00:34:26 CEST] <JEEB> PKG_CONFIG_PATH=/path/to/install/prefix/lib/pkgconfig pkg-config --cflags libavcodec [00:34:29 CEST] <JEEB> for example [00:34:47 CEST] <JEEB> that path being where homebrew installed the thing [00:34:58 CEST] <JEEB> (and /lib/pkgconfig where the pc files get installed [00:35:39 CEST] <JEEB> if locate or find works on OS X, `locate libavcodec.pc` or `find / -iname 'libavcodec.pc'` should work [00:35:50 CEST] <JEEB> the find probably needs root :P [00:36:08 CEST] <nicolas17> use Spotlight! :P [00:36:47 CEST] <furq> find / ;_; [00:36:56 CEST] <furq> what is this, stackoverflow? [00:37:04 CEST] <JEEB> furq: well I have no fucking idea where homebrew installs its shit [00:37:15 CEST] <furq> it's either /usr/local or possibly /home [00:37:16 CEST] <JEEB> and I did note locate first [00:37:25 CEST] <ArsenArsen> Hmm. I'll look for it/ Thanks [00:37:26 CEST] <JEEB> if that works on mac [00:37:35 CEST] <furq> i assume it does but i doubt it's installed by default [00:37:40 CEST] <furq> and updatedb takes even longer than find / [00:37:49 CEST] <nicolas17> I think it's installed by default [00:37:56 CEST] <nicolas17> but there is no cronjob running updatedb regularly [00:38:40 CEST] <furq> https://github.com/Homebrew/homebrew-core/blob/master/Formula/ffmpeg.rb [00:39:01 CEST] <furq> the answer is "whatever your usual prefix is" [00:39:23 CEST] <furq> https://github.com/Homebrew/homebrew-core/blob/master/Formula/ffmpeg.rb#L10… [00:39:26 CEST] <furq> wow...ruby is so expressive [00:39:51 CEST] <nicolas17> lol [00:43:13 CEST] <JEEB> ultrav1olet: since I see you made a bug report, matroska and mp4 are formats where the usually the parameter sets are in a single place only and separated from the video stream. mpegts is one where there's no "separate" part. it's a "streaming" format (as in, optimized for reading A=>B) and with "just" the streams as-is. [00:43:45 CEST] <JEEB> when you are using the dump concat feature with matroska the thing opens the demuxer and reads the extradata off the first file and is happy. after that it proceeds to reading through the file. [00:43:51 CEST] <JEEB> and the second file [00:44:42 CEST] <JEEB> with mpegts there's no such stuff as it's just throwing data through [00:45:02 CEST] <JEEB> which is why it works even with the "stupid" mode that the concat thing does [00:45:50 CEST] <androclu`> nicolas17: just an update.. ever since i took the top off the computer and let it breath, it seems to not make seg-faults. funk-a-delic. [00:46:39 CEST] <androclu`> nicolas17: i think ffmpeg just stresses the cores. still don't know why it should happen *lately*, though, when it did not for the last year or so. [00:47:37 CEST] <androclu`> nicolas17: however, i think i am going A) to get a bigger fan for the box or set a massive room fan next to it, or B) figure out how to UN-overclock this board, or C) get a small 'fridge or freezer, and put my computer inside! [00:47:42 CEST] <JEEB> ultrav1olet: also I do really hope that x265 is giving you something that x264 isn't :P in my tests it really wasn't in any way clear cut that it would. [00:47:52 CEST] <JEEB> although I haven't tested recently [00:49:26 CEST] <ultrav1olet> JEEB: yep, I thought a bug report to remember and fix is pertinent in this situation ;-) [00:49:49 CEST] <ultrav1olet> this chat session might be easily forgotten and never taken care of ;-) [00:50:18 CEST] <ultrav1olet> one last question: how can I cut a file into two parts _exactly_? [00:50:43 CEST] <JEEB> I will raise a toast if anyone actually takes that use case up for grabs and implements it properly in the containers that need proper separation of parameter sets [00:50:50 CEST] <ultrav1olet> I've just discovered that I've spent literally 6 hours encoding while the second file misses at least 5 frames :( [00:51:15 CEST] <ultrav1olet> so -ss and -t options are not quite precise it seems [00:51:30 CEST] <JEEB> well -ss will only be as precise as the closest RAP [00:51:42 CEST] <JEEB> -t should be precise but you've got MPEG-TS now so all bets are off [00:52:03 CEST] <ultrav1olet> hm [00:52:25 CEST] <ultrav1olet> and how can I find that RAP position using -ss/-t? [00:52:54 CEST] <ultrav1olet> sounds like an impossible task unless I can operate with frames [00:52:57 CEST] <JEEB> well ffmpeg.c only lets you start the thing at a fucking RAP, that's what I fucking meant with what I said [00:53:13 CEST] <JEEB> so that's why your goddamn -ss is not exact, in addition to the fact thay you've now got MPEG-TS [00:53:31 CEST] <JEEB> which may or may not fuck your shit up because it's a format without an index [00:54:09 CEST] <JEEB> now, if you know the bytewise location of your RAP and parameter sets before it, you can just use dd with 188 byte chunks because that's what fucking MPEG-TS is [00:54:35 CEST] <JEEB> but of course you do not know that is so (Ž4@) [00:54:47 CEST] <ultrav1olet> :-) [00:55:48 CEST] <ultrav1olet> I'm now thinking of just reinserting a few forsaken frames ;-) sounds like an easier thing to do [01:02:44 CEST] <ultrav1olet> so how can I encode frames 8..29 from the source video? ;-) [01:03:33 CEST] <DHE> select filter? [01:03:34 CEST] <furq> -vf trim [01:03:40 CEST] <furq> !filter trim [01:03:40 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#trim [01:06:55 CEST] <ultrav1olet> ffmpeg -i part12.mp4 -vf trim=8:29 doesn't seem to work - ffmpeg exist momentarily [01:07:09 CEST] <ultrav1olet> video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:2kB muxing overhead: unknown [01:10:04 CEST] <furq> that's seconds, not frames [01:10:15 CEST] <furq> you want trim=start_frame=8:end_frame=29 [01:10:59 CEST] <furq> and probably also ,setpts=PTS-STARTPTS [01:12:09 CEST] <nicolas17> blargh [01:12:47 CEST] <nicolas17> I tried to use MLT to do the video transition I wanted but the composite transition doesn't do antialiasing >_< [01:13:38 CEST] <nicolas17> it moves the video by whole pixels only [01:15:37 CEST] <ultrav1olet> thanks everyone [01:50:31 CEST] <nicolas17> okay [01:50:43 CEST] <nicolas17> so the reason why I couldn't get these two timelapses in sync is that the interval isn't even consistent [01:50:49 CEST] <nicolas17> in theory it was 2fps [01:50:58 CEST] <nicolas17> but I see many seconds with only one picture, according to EXIF [01:51:33 CEST] <nicolas17> no idea if the framerate is even constant [01:51:45 CEST] <nicolas17> since I don't have sub-second timestamps /o\ [02:03:20 CEST] <nicolas17> and sure enough both cameras have different speeds [02:04:43 CEST] <JodaZ> yeh, video is such a shitshow, isn't it [02:05:16 CEST] <nicolas17> http://sprunge.us/GMQQ this is the EXIF timestamp of the photos [02:06:04 CEST] <nicolas17> any clever idea on how to estimate plausible milliseconds for them? [02:58:15 CEST] <FishPencil> Is there any better explanation of the hqdn3d settings? The docs are pretty basic https://ffmpeg.org/ffmpeg-filters.html#hqdn3d-1 [03:38:39 CEST] <FishPencil> Uhhh, how is it that -preset veryslow is larger than the same input sample with the same arguments except for -preset medium with x265? [03:39:31 CEST] <FishPencil> I thought -preset was a way to control how compressed it was (i.e. filesize) [03:44:08 CEST] <nicolas17> FishPencil: depends on your other options [03:44:25 CEST] <FishPencil> All other options are the same [03:44:36 CEST] <nicolas17> if you asked for a certain bitrate, veryslow will probably give you a result with a similar (maybe bigger!) file size but better quality [03:45:11 CEST] <FishPencil> Simply '-c:v libx265 -crf 22 -preset medium' vs '-c:v libx265 -crf 22 -preset veryslow' [03:45:36 CEST] <nicolas17> ah crf [03:45:39 CEST] <nicolas17> dunno then [03:46:33 CEST] <FishPencil> Seems quite odd. It took way longer, but ended up being bigger... [03:46:42 CEST] <FishPencil> Seems counter productive [03:47:08 CEST] <nicolas17> crf asks for constant "quality", so with same crf and slower preset it should have been smaller... [03:56:18 CEST] <FishPencil> Maybe the "veryslow" preset decided it actually needed more bits [04:11:11 CEST] <furq> FishPencil: that isn't what -preset means [04:11:27 CEST] <furq> the meaning of -crf changes depending on other encoding options [04:11:35 CEST] <furq> so you'll normally get roughly the same size for any preset [04:11:40 CEST] <furq> at least with x264, i assume x265 is the same [04:11:53 CEST] <FishPencil> furq: So what's actually happening here? [04:12:01 CEST] <furq> i said "normally" [04:12:08 CEST] <furq> crf isn't an exact science [04:12:21 CEST] <furq> it is perfectly normal for veryslow to come out bigger than medium [04:12:28 CEST] <furq> it'll look better [04:13:34 CEST] <FishPencil> furq: So it's probably just looking further ahead to see what can be done, and thus might find that the same bitrate for medium isn't enough? [04:14:43 CEST] <furq> not really [04:14:59 CEST] <furq> crf will try to pick the best quantiser for any given scene [04:15:11 CEST] <furq> if you use higher-quality settings it'll pick a lower quantiser (i.e. higher quality) [04:15:26 CEST] <furq> on the basis that it expects to compress better [04:15:51 CEST] <furq> that's my limited understanding of it anyway [04:15:57 CEST] <furq> i admit it is completely unintuitive [04:23:50 CEST] <FishPencil> -b:a is for all channels right? so for 5.1 (6 channel), I'd want 384k probably for 64k per channel? [04:27:18 CEST] <furq> yeah [04:27:34 CEST] <furq> you probably don't need that much for aac though [04:27:58 CEST] <FishPencil> Opus [04:28:06 CEST] <furq> yeah 256k should probably be fine [04:28:36 CEST] <furq> xiph recommend 128-256 for 5.1 [04:29:44 CEST] <FishPencil> Wow, 128 for 5.1? that must be some compression [04:30:36 CEST] <furq> bear in mind that that's vbr [04:30:44 CEST] <furq> and it's not abr so it might over/undershoot by a lot [04:31:50 CEST] <FishPencil> Curious if FFmpeg uses surround-sound bitrate allocation that Opus provides [04:32:01 CEST] <furq> it does if you use libopus [04:32:05 CEST] <FishPencil> furq: Is -b:a still the best way to call it? [04:32:15 CEST] <furq> that's the only way of using it afaik [04:32:29 CEST] <furq> opus is a bit weird in that regard [04:33:07 CEST] <furq> setting the bitrate to 128k will use settings that averaged out to 128kbps across their test corpus [04:33:15 CEST] <furq> it doesn't make any attempt to actually hit 128k [04:33:26 CEST] <furq> at least afaik [04:34:02 CEST] <furq> there are true abr and cbr modes but they're presumably intended for streaming [04:35:21 CEST] <FishPencil> furq: You said earlier that x265's -preset veryslow will be better quality at the same crf. Does that mean something like: -crf 22 -preset medium = -crf 24 -preset veryslow [04:35:34 CEST] <furq> "something like", yes [04:35:40 CEST] <furq> i would not try to put actual numbers on that [04:36:39 CEST] <FishPencil> In that case the file size would be smaller for -veryslow? [05:43:40 CEST] <kepstin> I actually kinda wish opus had a 'quality' setting like vorbis, so you didn't have to calculate it yourself based on the number of channels [05:44:23 CEST] <kepstin> didn't have to calculate the bitrate* [08:30:06 CEST] <cowai> Hello, does anybody have any experience with the prompeg fec documented here? https://www.ffmpeg.org/ffmpeg-all.html#prompeg [08:33:10 CEST] <cowai> I am trying to figure out if I can use that as input as well in ffmpeg [08:33:28 CEST] <cowai> I mean, can I decode FEC as well? [09:05:33 CEST] <nahsi> I need to make a clip from a 4h video consisting of evenly extracted parts of 50 frames. THe clip sould be around 6000 frames. Hope you can understand what I want. Can ffmpeg do that or I need to use bash magic? [09:11:02 CEST] <squ> split video by frames with ffmpeg [09:11:11 CEST] <squ> -t, -ss, -framerate [09:16:00 CEST] <nahsi> squ: I think it's now what I want. I need to extract 50 frames then skip some then extract more then skip etc so the total length would be around 6000 frames from every part of a video [09:16:57 CEST] <squ> yes [09:17:35 CEST] <nahsi> I though -framerate is for converting frame rate of a video? [09:17:51 CEST] <squ> tells how much frames in a second [10:06:00 CEST] <termos> when I'm done encoding and get an AVPacket out of avcodec_receive_packet it has duration set to 0 for video. This causes the HLS muxer to complain. Is there a reason it's set to 0 and not 1/framerate for example? [10:06:21 CEST] <termos> something I forgot to set in the AVCodecContext? [10:16:09 CEST] <DHE> interesting. what input format? [10:22:20 CEST] <termos> the input is FLV from rtmp, decoded h264 (still has duration set), then it's encoded with libx264 and no duration in the AVPackets after [10:22:50 CEST] <termos> my bad, still has duration after demuxing, no duration in the decoded AVFrame's [10:25:10 CEST] <termos> I guess I could set the duration manually before muxing to cur_pts-prev_pts scaled into the correct time_base or something [10:25:29 CEST] <termos> I'd like to avoid it if possible [10:53:20 CEST] <ArsenArsen> When I finish my encoding some frames are missing from the recording, I use the send receive API, and before writing the trailer I receive all packets that are left in the codec. What could cause this issue? [10:55:01 CEST] <ArsenArsen> There seems to be at max ~20 frames gone every time [11:00:25 CEST] <termos> are you flushing the encoder by passing a NULL frame to avcodec_send_frame? [11:01:57 CEST] <ArsenArsen> I am not.. Will try doing that now. [11:10:52 CEST] <ArsenArsen> That fixed it! Thanks [11:45:16 CEST] <termos> I ended up doing packet.duration = packet.pts - prev_pts; before every call to av_interleaved_write_frame and I see no issues with it. Does it look correct? [11:46:22 CEST] <termos> all HLS segments are the correct length at least [12:36:04 CEST] <darklink> hello. I have a wav file with 10 channels and a channel layout of Front left, front right, front center, LFE, back left, back right, side left, side right, top left and top right. [12:36:17 CEST] <darklink> Now I want to convert that file into something more usable [12:37:24 CEST] <darklink> like 7.1 or 11.1 [12:37:59 CEST] <darklink> What channel layout should I pass to ffmpeg? [12:39:14 CEST] <thebombzen> darklink: I believe ffmpeg supports notation like "-ac 7.1" [12:39:37 CEST] <darklink> but it can't guess the channel layout of the 10 channel input file [12:40:00 CEST] <thebombzen> idk then, I guess you might have to use a dedicated tool [12:40:09 CEST] <thebombzen> perhaps it can be done, but I don't know how [12:41:10 CEST] <darklink> can you split the channels of an arbitrary audio file into individual files? [12:41:27 CEST] <squ> yes, with -map [13:00:18 CEST] <hollunder> Hi there. I'm looking into a bug I encountered with obs and recording a stream to a mkv file. The resulting mkv file has 1000 fps and some other issues. [13:00:53 CEST] <hollunder> from what we could figure out at quackenet #obsproject it might be a ffmpeg issue. [13:01:22 CEST] <hollunder> Osiris there could get correct frame rates when he set avg_frame_rate but is worried about side effects [13:01:42 CEST] <hollunder> Is someone here familiar with this stuff? [14:14:45 CEST] <thebombzen> hollunder: OBS has had a broken mkv muxer for a long time [14:15:01 CEST] <thebombzen> they claim it's really ffmpeg's mkv muxer that is broken, but this isn't fully accurate [14:15:17 CEST] <thebombzen> I really think OBS just don't call libavformat correctly [14:22:22 CEST] <BtbN> I guess they don't properly let it finalize the output file? [14:28:30 CEST] <BtbN> They are doing VERY weird things with their muxing [14:28:44 CEST] <BtbN> they are calling an external binary which they made themselves, instead of muxing directly. [14:28:53 CEST] <BtbN> I guess so OBS can safely crash, without killing mp4 files?! [14:40:56 CEST] <thebombzen> BtbN: except it can't though [14:41:20 CEST] <thebombzen> otherwise I'd just remux to mp4. I don't know how it works. their mkv muxer is broken as above, the mp4 muxer is unsafe because it's not streamable by default [14:41:36 CEST] <thebombzen> I end up recordting to mpegts with OBS [14:41:38 CEST] <BtbN> mp4 is not streamable. You can't safely live-record to it [14:41:42 CEST] <BtbN> Just use flv [14:41:56 CEST] <thebombzen> I say "by default" because you can do moov hacks and whatnot [14:42:08 CEST] <thebombzen> but yea it has to be finalized or it'll be corrupt [14:42:10 CEST] <hollunder> can't someone tell them how to do it correctly? [14:42:20 CEST] <thebombzen> hollunder: if you do that, they'll say it's FFmpeg's problem [14:42:33 CEST] <thebombzen> I worked around it by recording to mpegts [14:42:59 CEST] <BtbN> The ffmpeg mkv muxer is clearly not broken. It works when used via ffmpeg.c or various other applications. [14:43:06 CEST] <hollunder> I don't know, Osiris didn't seem entirely unreasonable [14:43:21 CEST] <thebombzen> I've mentioned it in the past on #obsproject [14:43:31 CEST] <hollunder> IT worked for Osiris in obs when he set avg_frame_rate [14:43:31 CEST] <BtbN> So if it works everywhere, but in OBS, it's pretty clear on which side the issue/misuse is happening. [14:43:31 CEST] <thebombzen> and basically am told "we just use FFmpeg's muxer so it's their fault" [14:43:33 CEST] <thebombzen> which is stupid [14:44:01 CEST] <hollunder> he wasn't sure whether this had side effects [14:44:04 CEST] <BtbN> Also, their muxing code is so convoluted due to that seperate process it's really hard to pinpoint anything [14:48:23 CEST] <hollunder> I record two audio streams, so I can't just use flv. [14:48:46 CEST] <hollunder> It seems re-muxing the mkv to mp4 from obs works well enough. [14:49:05 CEST] <BtbN> you shouldn't use either format. [14:49:13 CEST] <BtbN> mp4 is risky to live-record, and mkv in obs seems to be broken [14:49:24 CEST] <BtbN> That leaves you with ts as the only possible format [14:51:07 CEST] <hollunder> thanks, I'll give that a shot [14:51:55 CEST] <thebombzen> well, it also has mov and flv, but mov has the exact same problem as mp4 [14:52:03 CEST] <thebombzen> and flv is deprecated and there's no reason to use it over mpegts [14:52:37 CEST] <hollunder> this looks like a quite horrible situation [14:52:47 CEST] <BtbN> flv is deprecated? [14:52:58 CEST] <BtbN> rtmp is still by far the most common distribution protocol, and that's flv over tcp [14:53:03 CEST] <BtbN> flv is not going anywhere [14:56:57 CEST] <zalaare> can someone tell me how to use vp9_vaapi /encode/ and the scaler. I prefer -scale=-2:480, however even the scale_vaapi=w=-2:h=480 is not working. If I add the scale i get "Failed to end picture encode issue: 18 (invalid parameter).", when I remove it, it encodes just ducky. [14:58:48 CEST] <zalaare> current command is `ffmpeg -i '/path/to/file' -vf 'format=nv12,scale=-2:480,hwupload -vaapi_device '/dev/dri/renderD128' -c:v vp9_vaapi -c:a copy -y '/path/to/newfile.mkv' [14:59:56 CEST] <c_14> I'd assume scale_vaapi doesn't support using -2 as a width [15:00:22 CEST] <shincodex> So. [15:00:26 CEST] <zalaare> c_14: it certainly did not in the past. I'm trying to use the swscale instead of it (see above). [15:00:51 CEST] <shincodex> if using rtsp then my priv_data is going to be a RTSPState [15:01:11 CEST] <c_14> zalaare: try scale,format,hwupload ? [15:01:12 CEST] <zalaare> to use the scale_vaapi as i understand it: -vf 'format=nv12,hwupload,vaapi_scale=w=840:h:480' [15:01:27 CEST] <shincodex> which uses udp or tcp which tries to cast the priv_data to a tcpcontext... This can never be true so the setsock options never goes off. [15:01:32 CEST] <zalaare> c_14 i'll try [15:01:44 CEST] <jkqxz> -2 should work, the code to calculate that is common. (Though that change was more recent than the addition of the filter itself.) [15:01:46 CEST] <shincodex> which is why in tcp they do url split for timeout [15:04:35 CEST] <jkqxz> Also, scale_vaapi can usually do the format conversion, so doing it on the CPU beforehand is unnecessary. If your input is yuv420p, you can just do 'hwupload,scale_vaapi=w=840:h=480:format=nv12'. [15:05:25 CEST] <zalaare> same result with scale before format [15:05:57 CEST] <zalaare> if scale_vaapi now supports -2 then i can do that. [15:06:57 CEST] <zalaare> same error [15:07:39 CEST] <jkqxz> Oh, I didn't see the first error you said. That is odd. Can you paste the whole output somewhere and link it? [15:08:27 CEST] <shincodex> oh.... [15:08:43 CEST] <shincodex> TCP.c does not implement a url_open2 which excepts avoptions [15:08:47 CEST] <shincodex> probably udp as well [15:10:36 CEST] <zalaare> https://www.pastiebin.com/5953aac353103 [15:14:37 CEST] <zalaare> if change 1 character it works :P vp9_vaapi -> vp8_vaapi [15:14:38 CEST] <zalaare> hehe [15:17:51 CEST] <jkqxz> Weird. I have no idea at all why that would be failing. [15:20:06 CEST] <jkqxz> The driver doesn't obviously have any relevant changes since that version. [15:20:07 CEST] <jkqxz> You could try doing the decode on the GPU as well, rather than having it on the CPU and uploaded? [15:20:24 CEST] <c_14> zalaare: try using -16 instead of -2? [15:21:13 CEST] <zalaare> jkqxz: decode works fine, but this is part of a script and I never know what the input will necessarily by. [15:21:14 CEST] <zalaare> be* [15:21:55 CEST] <zalaare> c_14 -16 works [15:21:57 CEST] <zalaare> why? [15:22:17 CEST] <zalaare> end up with slightly odd res [15:22:23 CEST] <zalaare> 848x480 [15:22:28 CEST] <zalaare> but it works [15:23:17 CEST] <zalaare> -8 works [15:23:51 CEST] <zalaare> -4 fails. good enough to work with :) Thanks! [15:25:37 CEST] <mcegledi> Hi there! [15:26:06 CEST] <jkqxz> The Intel VP9 encoder doesn't like some frame sizes? I haven't seen that before, but I don't think I ever tried weird sizes. I'll have to look into that. [15:28:37 CEST] <mcegledi> I have a installation description for a software that requires me to install the ubuntu ffmpeg package at my system. But that doesn't exist for my ubuntu 14.04. There are a lot of other *ffmpeg* packages for trusty, does anybody know which trusty packages have been replaced by "ffmpeg"? [15:31:46 CEST] <c_14> zalaare: some codecs only like things divisible by certain numbers [15:31:54 CEST] <c_14> most encoders should pad/scale to fit [15:32:00 CEST] <c_14> but vaapi_vp9 probably doesn't [15:32:36 CEST] <zalaare> stupid question, but is the -2,-4,-8,-16 basically the same as mod2, mod4, mod8, and mod16? [15:32:52 CEST] <DHE> yes, it forces a selection that is a multiple of those numbers [15:32:53 CEST] <c_14> no [15:32:56 CEST] <c_14> it's round to the nearest [15:33:06 CEST] <c_14> it forces it to be modn [15:33:10 CEST] <c_14> it's not actually a modn [15:33:30 CEST] <DHE> modulo arithmatic is technically different from the concept of "being a multiple of X" [15:33:58 CEST] <c_14> yes, it forces it to be modn == 0 [15:34:54 CEST] <zalaare> so similar, but not the same is what I think I am hearing/reading. [15:35:24 CEST] <jkqxz> It should work; seems likely to be a bug in the driver around thinking there should be alignment on input surfaces which need not have it. [15:35:31 CEST] <asdzxc> Hey everyone. I'm back with the same question as I had before: if I run the same command twice, why wouldn't the two outputs have the same checksum? [15:36:44 CEST] <celyr> if the same command is cat /dev/random that's actually expected [15:36:52 CEST] <jkqxz> Timestamps or similar in metadata? [15:37:04 CEST] <celyr> also xz on 2 different machines can have 2 different outputs [15:37:10 CEST] <celyr> you are giving 0 info [15:39:34 CEST] <c_14> asdzxc: ffmpeg includes timestamps in the metadata, use -fflags +bitexact [15:41:05 CEST] <asdzxc> Let me rebuild my command. One min [15:52:14 CEST] <asdzxc> https://pastebin.com/p93N3fjL [15:52:29 CEST] <asdzxc> It's a bit lengthy of a command, but it'll take an input @ timecode and create multiple outputs from it [15:52:44 CEST] <asdzxc> If I run that same command twice, my outputs have different checksums. [15:53:11 CEST] <c_14> how are you checking the checksums? [15:54:20 CEST] <asdzxc> Using a md5 checker built-in to FreeCommander [15:56:06 CEST] <c_14> yeah, first try adding -fflags +bitexact, then try using the hash/framehash muxers to compare instead [15:57:10 CEST] <asdzxc> Alright. Let me try that out. Thanks [16:05:33 CEST] <PsyDebug> hi all! how i can reload input stream, when eof? rtsp input is down every errors [16:07:58 CEST] <pgorley> hi, i'm looking at commit 66963d4b8d302611553e7928063c1cb2ff0efdff (avcodec: remove warning against using frame threading with hwaccels), which mentions a "libavcodec native software fallback mechanism". where can i get more details on such a mechanism (i don't mind looking through code)? [16:09:33 CEST] <thebombzen> BtbN: flv is deprecated in that you should not use it for anything other than rtmp [16:10:03 CEST] <thebombzen> unless you specifically need flv, there's not really any reason to use it instead of mpegts [16:11:26 CEST] <jkqxz> pgorley: It's there automatically. When you receive the get_format() callback it will always contain a software format (whether hardware formats are available or not), and if you pick it you will get the software decoder. [16:12:24 CEST] <asdzxc> c_14: The -fflags +bitexact didn't work. Do you see anything in my command that would cause the checksum to be different on different runs? With a simpler command, I'm able to confirm that the MD5s match, so I think there may be something with my command. [16:13:00 CEST] <pgorley> jkqxz: so if i'm using hardware decoding, and it fails during runtime, how do i fallback to software? is there a way to do this implemented in avcodec? [16:14:18 CEST] <c_14> asdzxc: not really, what does the framehash muxer say? [16:14:43 CEST] <asdzxc> I'm not sure how to use that. [16:15:20 CEST] <c_14> ffmpeg -i file -f framehash out.sha256 [16:15:29 CEST] <c_14> the hash is written to out.sha256 [16:16:21 CEST] <jkqxz> pgorley: What do you mena by "fails"? If the stream format changes to one which your hardware decoder does not support, then you can pick the software decoder instead. [16:17:20 CEST] <pgorley> jkqxz: i mean, once the hardware is decoding and for some reason screws up and starts spewing errors, is there a way to redo the get_format callback to choose a software format? [16:18:27 CEST] <jkqxz> If your hardware actually fails (like, you snap your graphics card in half mid-decode) then you it won't have any way to recover until the next get_format() callback, because that's the granularity of the selection. [16:18:56 CEST] <jkqxz> (Well, maybe that particular failure would be more serious, but hopefully you get the idea.) [16:20:45 CEST] <alexpigment> jkqxz: i'm interested to know what happens when you snap your GPU in half mid-decode. please report your findings ;) [16:22:02 CEST] <pgorley> jkqxz: haha, thanks for the help! [16:23:01 CEST] <pgorley> so i'd have to reinitialize the avcodecocntext to get the next call to get_format [16:23:05 CEST] <Asuran> hi, can -b:v use some automatic value like the bitrate of the source? [16:23:54 CEST] <alexpigment> Asuran: I assume a CRF value is out of the question? [16:24:02 CEST] <alexpigment> (if you're using x264) [16:25:50 CEST] <Asuran> alexpigment, actually i wanted to use crf [16:26:15 CEST] <Asuran> but now im unsure if i should not use some automatic -b:v and use vbr encoding? [16:26:20 CEST] <Asuran> codec libvpx-9 [16:26:27 CEST] <alexpigment> ah, gotcha [16:26:32 CEST] <Asuran> but im open to use x265 [16:27:03 CEST] <alexpigment> I think with libvpx, you can specify -crf but it actually maps to a -qp internally [16:27:09 CEST] <alexpigment> you still have to set the bitrate though [16:27:16 CEST] <alexpigment> -b:v effectively becomes the maxrate [16:27:26 CEST] <alexpigment> unless you set -b:v to 0, then it's unconstrained [16:27:42 CEST] <alexpigment> (I'm basing this off my experience with VP8, but I believe VP9 is the same [16:27:46 CEST] <furq> it is [16:28:02 CEST] <Asuran> ye in vp9 if you dont set it it autos to 256 or [16:28:12 CEST] <kepstin> asdzxc: You're using x264 multithreading - which is a *non-deterministic* encoder. You aren't guaranteed to get the same result each time. [16:28:16 CEST] <Asuran> so -b:v is like b:v auto? [16:28:17 CEST] <alexpigment> yeah, just set -crf [number] -b:v 0 [16:28:27 CEST] <Asuran> thanks! [16:28:40 CEST] <Asuran> to both of you [16:28:46 CEST] <alexpigment> np [16:29:01 CEST] <alexpigment> hope it works. i've done very little testing with vp9, but I *think* it's the same as how vp8 works [16:30:22 CEST] <kepstin> huh, I though cq mode with vp8 wasn't supported - you just had to set -b:v to some really high value and hope for the best. The unconstrained cq mode is new in vp9? [16:30:32 CEST] <furq> cq mode is in vp8 and vp9 [16:30:35 CEST] <furq> constant quality mode is new in vp9 [16:30:39 CEST] <kepstin> er, cq mode with unconstrained bitrate in vp8 wasn't supported* [16:30:45 CEST] <Asuran> furq, cq is crf? [16:30:47 CEST] <furq> you have to set -b:v 0 to enable it [16:30:51 CEST] <furq> cq is constrained quality [16:31:00 CEST] <furq> constant quality (VPX_Q) is presumably supposed to be crf [16:31:06 CEST] <alexpigment> kepstin: yeah, I didn't *know* it was supported years ago, so I set some really high bitrate as the max. and then I felt dumb when I found out -b:v 0 worked [16:31:37 CEST] <furq> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libvpxenc.c#L512-L5… [16:32:04 CEST] <Asuran> thanks again [16:32:12 CEST] <furq> http://www.webmproject.org/docs/webm-sdk/group__encoder.html#gaf50e74d91be4… [16:32:20 CEST] <kepstin> the libvpx constrained/constant quality modes are implemented in a completely different way from x264's "crf" mode tho, so don't be confused by the name and expect them to behave like x264 :/ [16:32:24 CEST] <furq> it was probably naive of me to expect them to explain what those modes actually are [16:34:24 CEST] <alexpigment> kepstin: yeah, as I said above, I think CRF just maps to qp (or cq or something) on the back end [16:34:45 CEST] <Asuran> which is youre fav codec for lossy archiving? [16:34:48 CEST] <furq> x264 [16:34:51 CEST] <alexpigment> x264 [16:34:53 CEST] <Asuran> i understand [16:34:53 CEST] <kepstin> Asuran: x264. [16:35:15 CEST] <furq> it will continue to be x264 at least until av1 comes out [16:35:17 CEST] <Asuran> so if i understand it right due encoding times? [16:35:19 CEST] <furq> and probably for a few years after that [16:35:27 CEST] <Asuran> av1 is the sucessor of vp9? [16:35:29 CEST] <furq> yes [16:35:34 CEST] <furq> vp9 and x265 aren't really that much better [16:35:47 CEST] <furq> certainly not enough to warrant how slow they are [16:35:57 CEST] <alexpigment> Asuran: it's just a fully featured encoder, and it's reasonably fast. it supports -crf and interlacing and has blu-ray compatibility. that's enough for me :) [16:36:17 CEST] <furq> and from what i hear the encoders are much less mature and more prone to weird quality issues that have been ironed out in x264 [16:36:47 CEST] <kepstin> the best part of x264 was when they added the "preset" system, which finally put an end to copying around encoder command lines you didn't understand, and made it easy to use. [16:36:52 CEST] <furq> and also obviously the h265 patent situation is a fucking nightmare [16:36:58 CEST] <furq> not that it matters that much for archival [16:37:06 CEST] <alexpigment> kepstin: agreed [16:37:31 CEST] <furq> and yeah i remember all the wizardry needed to create a decent-looking xvid rip [16:37:36 CEST] <furq> i'd rather not go back to that [16:37:45 CEST] <alexpigment> furq: what's nightmarish about it? I presume you just have to deal with MPEG-LA as usual [16:37:53 CEST] <furq> you wish [16:37:58 CEST] <furq> there are now four different patent pools [16:38:05 CEST] <furq> so you need to pay all of them [16:38:07 CEST] <kepstin> alexpigment: haha. Nope, that's the problem, it's not just the MPEG-LA [16:38:09 CEST] <alexpigment> really? [16:38:15 CEST] <alexpigment> well, consider this news to me ;) [16:38:21 CEST] <furq> mpeg-la, hevc advance, technicolour, and a new one whose name i forget now [16:38:27 CEST] <furq> we were making fun of their awful website a while back [16:38:41 CEST] <alexpigment> and you have to pay those four regardless of which features you use? [16:38:47 CEST] <furq> i've not looked into it that much [16:38:56 CEST] <furq> i just know i would run away from that shit like usain bolt [16:39:03 CEST] <alexpigment> haha [16:39:16 CEST] <alexpigment> well, I know that MPEG-LA has a minimum number of units before you actually have to pay [16:39:25 CEST] <alexpigment> hopefully the others are the same (not that I would bet on it) [16:39:26 CEST] <furq> velos media, that's the fourth one [16:41:08 CEST] <alexpigment> noted for the future; thanks [16:42:05 CEST] <furq> the fees have come down a lot though [16:42:21 CEST] <furq> hevc advance initially wanted $2.80 per device plus 0.5% of revenue from hevc content [16:42:36 CEST] <alexpigment> wow [16:43:24 CEST] <kepstin> hah, of course the velos media site serves up their videos... in h264/mp4 and vp9/webm. [16:43:28 CEST] <furq> lol yeah [16:43:37 CEST] <furq> i really like their "h264 vs hevc" comparison video [16:43:42 CEST] <furq> which is a webm [16:43:58 CEST] <furq> it's just the same video but one of them was scaled with nearest [16:44:05 CEST] <kepstin> some of the video tags even link to ogv files, but the one I checked returned a 403, so. [16:44:41 CEST] <DHE> I know some TV box manufacturers are starting to include VP9 player support... [16:44:52 CEST] <furq> but yeah unless you need to do a wide deployment of 4k Right Now then i would stay far away from hevc [16:45:18 CEST] <furq> or your name is apple and you're definitely not getting kickbacks at all from the patent pools for suddenly deciding to use it for everything [16:47:20 CEST] <furq> with that said, apparently some dvb-t2 stations are already using hevc [16:47:25 CEST] <furq> so it's probably in it for the long haul [17:19:17 CEST] <nahsi> OK, I'm back with the same question. I need to make a clip from a 4h long video, which will consist of short clips 50 frames of length evenly extracted. Hope that make sense. The total length of a clip should ba around 6000 frames. I need that to estimate optimal bitrate for encoding. [17:20:39 CEST] <DHE> so you want to break the input video into 50 chunks of roughly identical length? [17:21:01 CEST] <DHE> for later transcoding, I imagine on multiple systems [17:21:39 CEST] <nahsi> No-no, I want to make I single representative clip of ~6000 frames from a video [17:21:53 CEST] <nahsi> 50 frames from here 50 frames from there [17:23:45 CEST] <DHE> so some kind of supercut? :) [17:24:55 CEST] <nahsi> Yes you can all it like that. Just a bunch of random scenes to encode and see average bitrate [17:25:57 CEST] <nahsi> There is a script for aviSunth that does it but there is no abiSynth on linux [17:25:59 CEST] <nahsi> selectTotal1=framecount()/100 [17:26:00 CEST] <nahsi> selectTotal2=selectTotal1*2 [17:26:03 CEST] <nahsi> selectrangeevery(selectTotal2,50) [17:28:26 CEST] <dl2s4> there is vapoursynth on linux, also sometimes avxsynth can help too [17:30:38 CEST] <DHE> I'm thinking you might be able to do some trickery with select, setpts and funky math but I'd need to check the options available first. [17:31:11 CEST] <nahsi> Actually I think vapoursynth is what I need [17:31:15 CEST] <nahsi> I'll try it [17:31:18 CEST] <nahsi> Thanks [17:31:18 CEST] <kepstin> the main thing is that ffmpeg filters don't know the total no of frames or length of the video, so you'd have to precalculate it [17:31:30 CEST] <kepstin> but yeah, it could be done with ffmpeg other than that. [17:31:55 CEST] <nahsi> If I know the length then how I do that? [17:32:04 CEST] <nahsi> I can check it with ffprobe right? [17:32:10 CEST] <kepstin> yeah [17:32:30 CEST] <nahsi> So I have the length what's next [17:34:03 CEST] <kepstin> you'd use the 'select' filter, which takes a mathematical expression (has current frame no and current timestamp available) to pick which frames to include vs. exclude, then throw a setpts filter after it (probably something like 'setpts=N', depending on the stream timebase) to fix up the gaps in the timestamps. [17:34:29 CEST] <nahsi> OK I'll google it then [17:34:31 CEST] <nahsi> Thank you [17:35:56 CEST] <shincodex> typedef struct AVInputFormat { [17:36:03 CEST] <shincodex> shouldnt the read functor of this take options [17:36:57 CEST] <kepstin> probably something like select='between(mod(t\,600)\,0\,10),setpts=N' which would grab the first 10 seconds of video from each 10 minute segment - i.e. seconds 0-10,600-610,1200-1210, and so on [17:38:30 CEST] <kepstin> you could also use frame numbers rather than time, switch the variable t to be n instead [17:54:38 CEST] <shincodex> // Awful piece of @#$@#%@#%@$#%@#%@#%@#%@#%@#2355 extern "C" { // Go get the tcp global for control extern int TCPBufferSize; } [17:54:57 CEST] <shincodex> tcp.c [17:55:04 CEST] <shincodex> // a global controlling tcp recieve/send buffer size since options are not working because ffmpeg devs suck at design. int TCPBufferSize = -1; [17:55:14 CEST] <shincodex> static int tcp_open(URLContext *h, const char *uri, int flags) [17:55:19 CEST] <shincodex> if (TCPBufferSize > 0) { setsockopt(fd, SOL_SOCKET, SO_RCVBUF, &TCPBufferSize, sizeof(TCPBufferSize)); setsockopt(fd, SOL_SOCKET, SO_SNDBUF, &TCPBufferSize, sizeof(TCPBufferSize)); } [17:55:25 CEST] <shincodex> go patch the master with that [17:55:30 CEST] <shincodex> that awful fucking hack [18:08:52 CEST] <DHE> wut? [18:12:31 CEST] <Asuran> if i do 2pass encoding, can i tell ffmpeg to auto clean stuff up? [18:16:08 CEST] <BtbN> Just put an rm into the script you have anyway? [18:34:27 CEST] <albb> Hi there, can someone help me with a problem with x264 library? [18:42:06 CEST] <DHE> and he's already gone [18:47:42 CEST] <Asuran> BtbN, the file stay everytime same name? [18:48:12 CEST] <BtbN> I'd be surprised if it doesn't? The second process has to reliably find it. [18:57:21 CEST] <albb> Hi all someone can help me with this error using ffmpeg? [18:57:32 CEST] <albb> Unrecognized option 'x264opts'. Error splitting the argument list: Option not found [19:03:25 CEST] <BtbN> The option is called x264-params. [19:03:56 CEST] <ploprof> hello [19:04:07 CEST] <ploprof> I get this error [hevc_nvenc @ 0x563f46e7cd00] Failed to create nvenc instance: invalid version (15) [19:04:22 CEST] <kepstin> Asuran: the filename is derived from a prefix (which you can optionally specify) and a number to indicate which output stream. [19:04:22 CEST] <ploprof> I am on fedora 25 with up to date nvidia drivers and cuda [19:04:35 CEST] <ploprof> this was the command I used ffmpeg -i Grosse.Pointe.Blank.mkv -vcodec hevc_nvenc output.mkv [19:04:36 CEST] <albb> @BtbN the error is the same [19:04:57 CEST] <BtbN> You are not encoding with libx264 then. [19:05:12 CEST] <albb> how can I check it? [19:05:25 CEST] <BtbN> well, do you tell it to encode with libx264? [19:05:36 CEST] <albb> I have followed the Compiling guide of ffmpeg.org [19:06:02 CEST] <albb> Here https://trac.ffmpe [19:06:18 CEST] <albb> I have followed all the compile section.. [19:07:16 CEST] <BtbN> albb, that's not a compile time option though. [19:07:28 CEST] <BtbN> ploprof, what version of nvidia-drivers are you using? That are probably too old. [19:08:46 CEST] <ploprof> 375.66 [19:09:38 CEST] <albb> this is the pastebin [19:09:40 CEST] <albb> https://pastebin.com/giCNje2e [19:09:52 CEST] <BtbN> ploprof, the minimum driver version is 378.13 now [19:10:06 CEST] <ploprof> D a r n [19:11:46 CEST] <kepstin> albb: ok, what does the output of "ffmpeg -h encoder=libx264" say? [19:11:58 CEST] <BtbN> albb, what ffmpeg version is that? The commandline looks fine. [19:13:24 CEST] <albb> "ffmpeg -h encoder=libx264" lists some libavutil, libavcodec and says Codec 'libx264' is not recognized by FFmpeg [19:13:41 CEST] <albb> ffmpeg version N-86654-gd2ef9e6 [19:13:45 CEST] <kepstin> albb: alright, so your ffmpeg was not built with x264 enabled. [19:14:05 CEST] <albb> What should I do to enable? [19:14:30 CEST] <Asuran> recompile it [19:14:42 CEST] <Asuran> or get a version with it enabled [19:15:06 CEST] <kepstin> make sure you have the libx264 headers installed, and use "--enable-libx264" on the configure line. [19:16:17 CEST] <albb> where should I check for the libx264 headers? [19:17:39 CEST] <albb> I have the x264 application-executable in Home/ffmpeg_sources/x264-snapshot-20170627-2245 [19:18:23 CEST] <kepstin> did you build x264 yourself? or are you using e.g. distro-provided packages? [19:18:47 CEST] <kepstin> albb: honestly, unless you have a really good reason to build it yourself, you might want to consider just grabbing some prebuild ffmpeg binaries [19:19:44 CEST] <albb> I have followed https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu#RevertingChangesMadeby… [19:19:49 CEST] <albb> this guide [19:20:13 CEST] <Asuran> get the source pkg of this pkg [19:20:16 CEST] <Asuran> and add what he said [19:20:24 CEST] <albb> Before I have simply used git clone https://git.ffmpeg.org/ffmpeg.git ffmpeg [19:20:36 CEST] <kepstin> albb: so... are you actually running the ffmpeg binary that you built? [19:21:05 CEST] <kepstin> unless it's in your path, you'll need to specify the full path to the binary to run it [19:21:07 CEST] <albb> I hope, sorry but I am a newbie and I don't know how to check theese [19:21:52 CEST] <albb> I need a step by step :D [19:23:27 CEST] <kepstin> albb: honestly, if you're using ubuntu, it's probably easiest to just run version 16.10 or later and use the system ffmpeg, that should work for you well enough :/ [19:24:30 CEST] <albb> But I have a lo of programs in Ubuntu 14.04 [19:24:57 CEST] <albb> with an unpgrade OS i lose them , right? [19:26:18 CEST] <kepstin> well, you should do a backup obviously, but the ubuntu system upgrade from 14.04 to 16.04 is pretty reliable, and even 16.04 ships with a usable - if somewhat old (2.8) ffmpeg. [19:27:12 CEST] <albb> At the moment I can't do a backup :/ [19:28:32 CEST] <albb> <kepstin> can you help me tomorrow cause now I have to go? [19:28:40 CEST] <kepstin> any data you don't have backed up is obviously data you don't care about, so you should be good to just reformat and reinstall then ;) [19:29:19 CEST] <albb> Yes, I have backed up in cloud [19:29:42 CEST] <albb> Not all and I have not an external hard disk at the moment [19:30:28 CEST] <albb> I have some virtual machine, and a lot of programs :/ [19:30:45 CEST] <Asuran> arent those easy to backup? [19:30:51 CEST] <Asuran> i believe its just some vhd file? [19:31:35 CEST] <albb> University project [19:31:44 CEST] <Asuran> still same? [19:32:47 CEST] <albb> It's a long procedure even if it's easier later for ffmpeg use [19:33:55 CEST] <albb> but I have Eclipse, VirtualBox and so on that are time-expensive to re-install [19:38:45 CEST] <albb> Thank you for all advices.. tomorrow I'll try, and I hope to find you here [19:44:45 CEST] <alex88> Hello everyone, I'm trying to stream a webcam over the network, these are my ffserver config and ffmpeg command https://gist.github.com/alex88/1df3d37744726c9125f3a69dc7c850c8 the video is not very smooth, it lags and the fps seems very low, ffmpeg on the server command reports 22/24 fps and the same on the client (on the other machine) [19:46:18 CEST] <alex88> I don't know if it's a wifi problem (the machines are like 2 meters away and the router is at the same distance), is it because rtp transfers the video "as-is" without control on the timestamp or? (sorry for the idiot things I may.say :D ) [19:48:28 CEST] <kepstin> alex88: in general people aren't gonna be able to help you with ffserver stuff; what kind of use case are you thinking of? [19:49:08 CEST] <alex88> kepstin: it's a software which in some part, based on some sensors input has to start/stop recording from a webcam connected to another machine [19:49:46 CEST] <alex88> so on the machine with the webcam I run ffserver+ffmpeg and on the app server I just run ffmpeg to save the stream to file [19:50:19 CEST] <kepstin> alex88: anyways, some things to check: make sure you're not encoding the video twice (with some ffmpeg+ffserver configs that might happen), check cpu usage [19:50:21 CEST] <alex88> I've tried with https://github.com/mpromonet/v4l2rtspserver but the quality was very low and most of the time the stream wasn't working until I manually restart it [19:50:44 CEST] <kepstin> remember that many webcams don't actually have consistent framerate to start with, particularly in low light [19:51:31 CEST] <alex88> kepstin: cpu usage is mostly ffmpeg, ffserver usage seems very low, about the light, well, it's in a closed room where people work, not so dark, plus sometimes framerate is not that bad, it just drops for no reason randomly [19:52:25 CEST] <alex88> I've seen that setting video codec in ffmpeg but not in ffserver wasn't working, I don't remember what it wasn't working, but the format on the client was unexpected, so I had to set it into both [19:52:48 CEST] <kepstin> try using -tune zerolatency, make sure you have a reasonably small gop size so there's no long delay on startup, and don't use wifi because it adds random unpredictable delays. [19:54:29 CEST] <alex88> kepstin: dumb question, isn't there a way to make the client wait until it receives the correct frames instead of writing the last frame it received? [19:54:43 CEST] <alex88> -tun zerolatency where? server's ffmpeg or client ffmpeg? [19:54:56 CEST] <kepstin> alex88: that's an encoder option for x264 [19:55:29 CEST] <kepstin> alex88: and by default, the client should be waiting until it receives a keyframe before starting to write, but I dunno the details of how ffserver works for that sort of thing. [19:56:10 CEST] <alex88> well that's when to start the video (and it does, sometimes it's immediate, sometimes takes some seconds), I mean after starting writing the video, if framerate drops while streaming [19:57:25 CEST] <kepstin> you can probably do your use case fairly well without ffserver, btw; just have ffmpeg running on the server machine continuously sending udp/rtp to a port on the client, and then start/stop an ffmpeg on the client machine which listens to that udp/rtp stream. [19:57:33 CEST] <hiru> how do you capture multiple screenshots from a video sequence and combine them to make a single tall image? do you know when during a video there is a slow sequence that shows something from feet to the head? that's what I'm tring to do [19:58:12 CEST] <kepstin> hiru: I expect that most people do that by simply taking screenshots from the video, opening them in layers in e.g. the gimp or photoshop, and lining them up manually. [19:58:45 CEST] <kepstin> I haven't heard of any automated way to do it, although such might exist? (maybe something in opencv?) [19:58:54 CEST] <Asuran> hiru, if you want some kind of thumbnails look for imagemagick or google ffmpeg thumbnails [19:59:34 CEST] <hiru> not looking for a thumbnail, just wondering how it was done and if ffmpeg was the tool people is using [19:59:50 CEST] <Asuran> there you find explanation too how you get specific amount of screens between sec X and Y [20:01:42 CEST] <hiru> maybe ffmpeg is used to pipe the screenshots in some other tool [20:01:53 CEST] <kepstin> hiru: maybe look into software for image stack registration, like used for multi-exposure HDR stuff. Anyways, you're going to end up just turning the pan into a pile of images, then using some other tool or tools. [20:02:33 CEST] <hiru> ok thanks for the info. I'll try looking on google now that I know what to look for :) [20:02:42 CEST] <Asuran> hiru, why you dont do as i said? i googled it yesterday and find there an explantion for getting screens of sec X until Y [20:03:07 CEST] <kepstin> easy way? open the video in mpv, and use its framestep and screenshot feature to get the images. Slightly harder? you can use ffmpeg to turn a segment of the video into images per frame. [20:03:27 CEST] <hiru> uhm? Asuran actually taking screenshots from sec X to sec Y should be pretty easy. I was more interested in the combination part [20:03:44 CEST] <Asuran> combination of what? [20:04:03 CEST] <alex88> kepstin: thanks for the idea, I'll try that too, thank you! [20:04:09 CEST] <hiru> maybe I was unclear [20:04:34 CEST] <kepstin> Asuran: the video contains a pan over a static scene, and hiru wants to turn this into a single image of the entire scene. [20:04:53 CEST] <nicolas17> oh well have fun syncing it [20:05:00 CEST] <hiru> take the panoramic capture feature modern smartphones now have [20:05:12 CEST] <hiru> something like that [20:05:25 CEST] <hiru> you move and the phone combines the images in a long one at the end [20:06:28 CEST] <nicolas17> hugin is a GUI that combines several tools to do image stitching and panoramic photo stuff [20:07:53 CEST] <kepstin> ooh, I completely forgot about hugin. been a long time since I played with that :) [20:11:46 CEST] <hiru> maybe I found something useful http://www.kolor.com/wiki-en/action/view/Fun_:_Stitching_video_frames [20:29:32 CEST] <cryptodechange> hm crop=1920:698:0:191 produces a black line on top, crop=1920:698:0:192 produces a black line underneath [20:29:47 CEST] <cryptodechange> Though measuring the pixels, the source is definitely 698px in height [20:32:33 CEST] <kepstin> cryptodechange: hmm, the problem is probably that the image isn't lined up with the chroma subsampling [20:33:23 CEST] <kepstin> if you want to get the exact pixel offsets, you might have to convert to 4:4:4 sampling (e.g. yuv444p) before cropping (then convert back afterwards) [20:34:24 CEST] <kepstin> this is obviously a slightly lossy operation, since it requires reinterpolating the chroma [20:34:41 CEST] <kepstin> the other alternative would be to just take the middle 696px instead :/ [20:35:00 CEST] <cryptodechange> hm, well 2 pixels is no harm I suppose [20:35:28 CEST] <cryptodechange> media info states I'm using yuv420, haven't changed it [20:38:25 CEST] <lmat> I have an impulse response of a space and a dry recording. Can I convolve the two to create a "wet" recording in Audacity? [20:39:07 CEST] <lmat> Or command line or whatever? [20:41:33 CEST] <The_8472> does the png encoder support multithreading? [20:42:00 CEST] <durandal_170> yes it does [20:42:46 CEST] <The_8472> hrrm, then I must be holding it wrong. h.264 decoding for input uses multiple cores, but when i wire it together with a scaler, png encoder and image2 output it's using ~1core [20:43:56 CEST] <nicolas17> lol holding it wrong [20:45:51 CEST] <The_8472> kepstin> Asuran: the video contains a pan over a static scene, and hiru wants to turn this into a single image of the entire scene. <- oh heh, that's what i'm working on atm [20:46:23 CEST] <durandal_170> The_8472: filters are not frame thread encoding [20:46:48 CEST] <durandal_170> only directky encoding png is very fast iirc [20:48:01 CEST] <The_8472> is filter the right term? because i'm instantiating it as a codec [20:49:42 CEST] <The_8472> feed avframe into avpackage via avcodec, feed avpackage to avformatcontext [20:50:22 CEST] <roxlu> hey, does someone knows what example I can look at when I want to write a .mp4 file when I have raw h264 nals (in code). I've seen this one but that does a lot more: https://ffmpeg.org/doxygen/trunk/muxing-example_8c-source.html [20:59:04 CEST] <lmat> Forget it! I'll just read wikipedia and write it up myself! [21:00:02 CEST] <Vaska> Hello - I'm able to change ffplay's visualization when playing a local file but I can't figure out how to do it when playing a streaming url. [21:00:23 CEST] <Vaska> Is there an url equivilant to amovie? [21:03:25 CEST] <Vaska> I'd like to use something like this, but with an url instead of a local mp3 file --> ffplay -f lavfi "amovie=file.mp3,asplit[out0],showwaves[out1]" [21:06:48 CEST] <kepstin> Vaska: you should be able to use any url that works in ffplay in the amovie filter - the restriction is that : is a special character, so you'll have to escape it in the filter chain with \ [21:08:34 CEST] <kepstin> ... I'm not actually sure how to get that right [21:08:42 CEST] <kepstin> filtergraph escaping is kinda tricky [21:10:28 CEST] <Vaska> kepstin: I'm using a windows binary too which probably complicates things [21:11:13 CEST] <kepstin> ok, so on *linux*, you can do "ffplay -f lavfi 'amovie=filename=https\\\://www.example.com/audiofile.opus' [21:11:35 CEST] <kepstin> note that the filename= is required, and that single quotes are needed to get the escaping right [21:11:58 CEST] <kepstin> turning that into windows syntax is an exercise for the reader :/ [21:12:01 CEST] <Vaska> I get "Failed to avformat_open_input 'http'" when I try this --> ffplay.exe -f lavfi "amovie=http://wuwm.streamguys1.com/live.mp3,asplit[out0],showwaves[out1]" [21:12:31 CEST] <kepstin> Vaska: ^^ [21:12:44 CEST] <BtbN> kepstin, pretty sure you can just omit most quotes and escapes [21:13:06 CEST] <BtbN> Or just get bash [21:13:30 CEST] <Vaska> same thing when I add amovie=filename=http://wuwm.... [21:13:45 CEST] <kepstin> Vaska: needs more backslashes. [21:13:46 CEST] <BtbN> still need to escape the : for ffmpeg [21:14:30 CEST] <kepstin> specifically, ffplay has to get three backslashes in front of the : because it gets unescaped twice for some reason [21:15:01 CEST] <kepstin> if your shell interprets backslashes too, you may need more [21:15:28 CEST] <Vaska> it seems to be balking at http though -> Failed to avformat_open_input 'http' [21:16:10 CEST] <kepstin> Vaska: the character ':' is used to separate options in ffmpeg filters. So it reads up to the :, assigns the 'http' to the filename, then goes on and sets the next option with the rest of the string [21:16:16 CEST] <kepstin> which is why you need to escape the : [21:16:44 CEST] <Vaska> kepstin: ah, ok, trying some things, but a \ in front of the : doesn't seem to help [21:16:56 CEST] <Vaska> OH! [21:16:56 CEST] <kepstin> please go back and look at my example command again [21:17:02 CEST] <kepstin> and the rest of what i wrote [21:17:28 CEST] <Vaska> got it, thanks and sorry, had to use two backslashes, like this --> ffplay.exe -f lavfi "amovie=filename=http\\://wuwm.streamguys1.com/live.mp3,asplit[out0],showwav…" [21:17:59 CEST] <kepstin> huh, you're right, it does work with just 2 [21:18:14 CEST] Action: kepstin is confused by the fact that it also works with 3. [21:18:51 CEST] <Vaska> kepstin: thanks for the help though, wouldn't have figred it out without you [21:23:24 CEST] <Asuran> kepstin, im not sure but is there something which makes ffmpeg to take care oder audio synchron? i got some feeling its maybe a bit out of sync [21:23:32 CEST] <Asuran> i used libvp9 [21:23:40 CEST] <Asuran> and libopus [21:23:46 CEST] <Asuran> with -f webm [21:24:28 CEST] <kepstin> Asuran: unless you do anything strange, ffmpeg should preserve the synchronization as it was in your original file. [21:26:42 CEST] <nicolas17> how do I get filenames from a text file? [21:26:53 CEST] <nicolas17> I was using glob patterns with -f image2 before, but now I need a specific list of files [21:30:24 CEST] <kepstin> nicolas17: hmm, no way to do that with the image2 demuxer as far as I know. You might be able to use some external tool to concatenate the images then pipe them to ffmpeg (use the 'image2pipe' demuxer), depending on the image format used. [21:30:33 CEST] <kepstin> I think that works ok with png and jpeg. [21:30:46 CEST] <nicolas17> it's jpeg [21:38:15 CEST] <alexpigment> does anyone really know what the "Past duration too large" message is about? [21:39:16 CEST] <kepstin> I actually read the code a while back to figure it out. [21:40:06 CEST] <kepstin> it indicates that at the end of the filter chain, some frames have timestamps closer together than the indicated constant framerate would allow [21:40:13 CEST] <kepstin> I think the offending frames get dropped [21:41:02 CEST] <kepstin> the most common way to get it is probably to have something like a VFR mkv file where ffmpeg made a guess about the expected framerate, but was wrong or didn't look far enough ahead [21:41:21 CEST] <alexpigment> ah [21:41:33 CEST] <nicolas17> I'd love to turn all these pictures into a variable framerate video but I don't have subsecond timestamps D: [21:42:10 CEST] <alexpigment> i've never really understood the appeal of VFR [21:42:17 CEST] <alexpigment> especially for modern lossy codecs [21:42:22 CEST] <alexpigment> or modern lossless codecs, for that matter [21:42:26 CEST] <nicolas17> alexpigment: the pictures were taken with variable framerate to begin with [21:42:39 CEST] <alexpigment> oh gotcha [21:42:42 CEST] <nicolas17> because the camera's timer sucks, or it couldn't keep up to save them to the SD [21:42:50 CEST] <kepstin> it's mostly not useful, but sometimes when you're dealing with mixed telecined vs. interlaced vs. progressive content from old NTSC.. :/ [21:43:29 CEST] <nicolas17> it's *supposed* to be 2fps (0.5s) but the actual interval averages to 0.625s with quite some drift :/ [21:44:50 CEST] <kepstin> I *think* that using -vsync 0 or -vsync 2 should allow vfr output and get rid of the 'Past duration too large' message? But I haven't actually checked, and I don't remember if that's correct. [21:46:04 CEST] <kepstin> If the video was supposed to be CFR but there's just a lot of timestamp jitter, then just use '-vf fps=XXX' to fix it, of course. [21:46:47 CEST] <kepstin> If you're concatenating two videos with different framerates then... I need to resubmit the patch that fixes the concat video filter to mark the output as vfr ;) [21:48:38 CEST] <kepstin> (right now the concat filter sets the output fps to the fps of the first video input, so if the second is higher fps, then you'll get the 'Past duration too large' message a lot once the second video starts) [21:54:07 CEST] <nicolas17> "If the video was supposed to be CFR but there's just a lot of timestamp jitter, then just use '-vf fps=XXX' to fix it" [21:54:11 CEST] <nicolas17> kepstin: was that for me? [21:57:20 CEST] <nicolas17> frame I:9 Avg QP:21.07 size: 31610 [21:57:21 CEST] <nicolas17> frame P:510 Avg QP:23.44 size: 992 [21:57:22 CEST] <nicolas17> frame B:1500 Avg QP:26.49 size: 268 [21:57:25 CEST] <nicolas17> okay wow that partly explains why the video is so small [21:57:25 CEST] <kepstin> nicolas17: no, that's not really applicible to what you're doing. [21:57:30 CEST] <nicolas17> that's a big GOP [21:57:50 CEST] <kepstin> nicolas17: unless you specify, default gop on x264 is... 250, i think. [21:57:57 CEST] <nicolas17> hah [21:58:21 CEST] <nicolas17> keyint=250 [21:58:31 CEST] <kepstin> (although it has scene cut detection which can cause it to insert keyframes earlier) [21:59:04 CEST] <nicolas17> in MPEG2 it was like 15, right? [22:00:08 CEST] <The_8472> <alexpigment> i've never really understood the appeal of VFR <- it can still help lossy codecs to get a deeper reference buffer. i'm seeing some decent savings with vfr + duplicate frame decimation with the mpdecimate filter when encoding webms. [22:01:55 CEST] <The_8472> or when shoving TV content that switches rates into a single stream. i think mkv could also handle it some other way but multiple segments in a single mkv are arcane [22:02:53 CEST] <alexpigment> The_8472: I suppose that makes sense. In my heads I was just thinking about how no changes from frame to frame would result in very little extra data. And I guess I'm also thinking about how CFR video probably adheres to a stardard is more widely supported [22:03:18 CEST] <alexpigment> *head [22:03:49 CEST] <The_8472> yes, but whenever someone implements code that assumes CFR in popular software it's won't take long until someone opens a bug to complain :) [22:04:00 CEST] <alexpigment> true :) [22:04:29 CEST] <alexpigment> but knowing that there will be bugs in various software when using VFR is almost reason enough to not use it imho [22:04:45 CEST] <nicolas17> 640x480, crf 24 -> 173kbps <3 [22:05:06 CEST] <The_8472> alexpigment, yes, best to stop using any software with non-zero complexity if you want to avoid bugs [22:05:17 CEST] <nicolas17> heh :) [22:05:25 CEST] <alexpigment> haha [22:05:39 CEST] <alexpigment> I was really referring to VFR, but point taken :) [22:06:49 CEST] <JEEB> talking of low bit rates, I should do another floppy thing to have senpai notice me [22:07:20 CEST] <nicolas17> JEEB: ...now I kinda want to fit this timelapse into a floppy [22:07:41 CEST] <JEEB> do note that headers start taking space at some point [22:07:53 CEST] <JEEB> at which point you will have to start lowering frame rate [22:08:49 CEST] <JEEB> (this was a 22min lower-SD clip of a cartoon with something pre-opus for audio) [22:09:49 CEST] <nicolas17> this is only 5000 frames [22:12:52 CEST] <roxlu> When I want to write raw h264 (e.g. that I receive from a socket), into a .mp4 file do I need to setup the codec for the AVStream too? Also how should I create and init the stream? I'm looking at this muxing example: https://ffmpeg.org/doxygen/2.0/doc_2examples_2muxing_8c-example.html which sets up a video stream / codec which makes sense when encoding but I already have encoded data [22:26:50 CEST] <kepstin> roxlu: it might make sense to run the received h264 data through the "h264" demuxer, which will handle packetizing it, setting up timestamps, etc. [22:29:58 CEST] <roxlu> kepstin: yeah I was thinking about that, thanks [22:30:13 CEST] <roxlu> kepstin: I guess that's kinda the preferred solution from what I find online [22:36:39 CEST] <roxlu> kepstin: although I would think there is no need for a input context [22:40:50 CEST] <BtbN> you should not ever deal with raw h264 though [22:40:57 CEST] <BtbN> it's lacking important information. Like timestamps [22:41:31 CEST] <roxlu> BtbN: I think I have all the necessary information (decoder config, timestamps) [22:41:56 CEST] <BtbN> Where do you get timestamps from for your raw h264 input? [22:42:12 CEST] <roxlu> I don't get them from the h264, I have them in memory [22:42:34 CEST] <kepstin> where are you getting the frames from then, and why are they already h264? [22:42:44 CEST] <roxlu> webcam / hw-encoder [22:42:49 CEST] <alexpigment> Hey guys, I'm drawing a blank. What's the command line parameter to ignore video rotation metadata? [22:42:58 CEST] <BtbN> and it's not muxed into some format already? [22:43:08 CEST] <roxlu> No [22:43:15 CEST] <kepstin> roxlu: for a webcam, you should be using ffmpeg's device support for webcams, generally... [22:43:52 CEST] <kepstin> roxlu: and ffmpeg has hwaccel support for several types of hardware encoders. [22:44:04 CEST] <roxlu> kepstin: that's all fine, but I'm not looking for another way to deal with the data / input. I'm curious if ffmpeg is usable in this case [22:44:09 CEST] <kepstin> roxlu: you're not another person using an rpi & builtin cam, are you? [22:44:34 CEST] <roxlu> I undesrtand the points you're making, but I can't change that I only have raw h264 data [22:44:41 CEST] <roxlu> hehe no [22:45:40 CEST] <kepstin> roxlu: well, the way I'd recommend proceeding is rather than attempting to stuff some data you got somehow into ffmpeg, you should write an ffmpeg input device so that others can also use this hardware ;) [22:46:46 CEST] <kepstin> that's basically what you're going to end up writing in order to get this to work, really. [22:47:14 CEST] <BtbN> How is this not a normal ipcam anyway? What's so special about it? [22:47:25 CEST] <kepstin> maybe take a look at how the v4l2 driver handles webcams which return h264 frames as a reference. [22:47:35 CEST] <nicolas17> kepstin: hm I plan to do something with a rpi and builtin cam in the future, what's the problem with that? :) [22:48:04 CEST] <nicolas17> bad CPU for encoding? [22:48:13 CEST] <kepstin> nicolas17: most people who try something like that end up getting frustrated by bottlenecks due to underperforming hardware and issues with wifi performance [22:48:22 CEST] <nicolas17> oh ew wifi [22:49:31 CEST] <nicolas17> I want to take a timelapse, every 2 or 3 seconds, and I wonder if I should save individual JPEGs or if I should use some video codec to use less space... although I think I may run out of battery before running out of space [23:22:38 CEST] <kepstin> nicolas17: for that use case, an rpi would probably be fine, and using the hw encoder should in theory save a little battery power. Reducing amount of data written is a good idea because SD cards are mostly awful. [23:51:21 CEST] <nicolas17> looks like I'm exceeding the limits of the ffmpeg command line tool [23:51:47 CEST] <nicolas17> not really looking forward to writing my own C program with libav* though [00:00:00 CEST] --- Thu Jun 29 2017

1 0

ffmpeg-devel.log.20170627
by burek 28 Jun '17

28 Jun '17

[00:23:00 CEST] <durandal_1707> BtbN: use metadata filter to print it [00:24:09 CEST] <BtbN> the hack is working for now [00:24:30 CEST] <BtbN> but yeah, looks like it could also do that [00:51:48 CEST] <atomnuker> iive: updated https://pars.ee/temp/pvq_v2_benchmark.txt [00:53:12 CEST] <iive> Thank You [00:54:18 CEST] <durandal_1707> michaelni: prores_ks cant emulate prores_aw [00:55:31 CEST] <durandal_1707> you are asking bitrate which would give similar numerical results [00:55:50 CEST] <durandal_1707> thats nonsense [00:56:54 CEST] <durandal_1707> there are options to target bitrate per macroblock i think [00:57:00 CEST] <durandal_1707> use that [01:01:16 CEST] <michaelni> to compare quality one can check quality at the same bitrate or bitrate at the same quality or draw a distortion vs bitrate curve and compare these [01:02:01 CEST] <michaelni> you said its better i try to understand what you compared [01:02:11 CEST] <durandal_1707> bare eyes [01:02:48 CEST] <michaelni> did the files use similar bitrate ? [01:03:31 CEST] <durandal_1707> i could try to target it but why? [01:04:32 CEST] <durandal_1707> besides it supports only one pixel format [01:04:50 CEST] <durandal_1707> no point in keeping it [01:04:55 CEST] <michaelni> if a file with twice the size looks better it doesnt tell anything about which encoder is better quality [01:05:34 CEST] <michaelni> thats why i ask about bitrate so much, i would not really mind otherwise [01:06:47 CEST] <michaelni> iam not asking to keep 2 encoders but we should keep the better encoding algorithm, i do not knw which is better i dont remember the implementations exactly [01:07:52 CEST] <durandal_1707> michaelni: its obviously worse quality because it doesnt support higher profiles, besides i need to check which profile was used in fate [01:09:30 CEST] <durandal_1707> also this format is not used for compression [01:09:33 CEST] <nevcairiel> if both encoders lack ratecontrol to actually control the bitrate for a comparison, then with a format like prores the absolute quality should probably still matter [01:09:48 CEST] <michaelni> does either or both of the encoders do proper rate distortion decissions ? RD would beat non RD [01:12:10 CEST] <iive> atomnuker: may I request one more test run, all_float and presearch_rounding, at the same time. [01:12:37 CEST] <iive> you gave me a single number yesterday, it's bug i've made. [01:15:40 CEST] <atomnuker> so ALL_FLOAT_PRESEARCH cpuflag(sse42) && 1 and PRESEARCH_ROUNDING 01? [01:15:59 CEST] <atomnuker> that's already in the text file [01:16:09 CEST] <atomnuker> since presearch rounding is on as it was [01:16:20 CEST] <iive> rounding 00 [01:19:48 CEST] <atomnuker> iive: done [01:20:17 CEST] <iive> thank you [01:22:26 CEST] <iive> atomnuker: one more thing. [01:22:43 CEST] <iive> could you run a start/stop timer without anything between them [01:22:48 CEST] <iive> aka, no code. [01:22:55 CEST] <iive> once is enough. [01:23:04 CEST] <atomnuker> wouldn't it be more useful to run them with an empty function? [01:23:14 CEST] <atomnuker> calls still take time [01:24:15 CEST] <iive> no need [01:25:12 CEST] <iive> stop timer has an instruction fence, and it takes a lot of cycles to finish all codes at it. [01:25:37 CEST] <atomnuker> huh, didn't know that [01:25:39 CEST] <atomnuker> 264 decicycles in pvq_search, 8388340 runs, 268 skips [01:25:54 CEST] <iive> nice. similar to my cpu. [01:37:37 CEST] <kierank> rcombs: you can come visit us in Vauxhall if you want [01:38:17 CEST] <durandal_1707> watch out: they bite [01:38:57 CEST] <kierank> durandal_1707: i don't bite [01:39:29 CEST] <durandal_1707> i wasnt thinking .. [02:02:58 CEST] <jamrial> ubitux: can you test the coff patch on the ml with your freedos box? [02:03:49 CEST] <jamrial> nevcairiel: i have no idea what could be wrong with our code when you mix nasm and msvc, so just force yasm so the slots stop being red [02:07:18 CEST] <jamrial> nevcairiel: one thing worth testing is perhaps reverting 18f09524f7 since there's a ticket in trac complaining it generated unreadable .a files, but aside from that i don't know what could be wrong [03:13:12 CEST] <graphitemaster> when decoding audio with ffmpeg api, is there a way to request it at a different time scale, i.e slow it down or speed it up [03:14:02 CEST] <graphitemaster> right now I'm consuming it at the rate it suggests, which is fine, but our application has a global time scale, doing things this way leads to aliased or clipped audio naturally. [03:17:09 CEST] <Compn> there is an audio filter [03:17:34 CEST] <Compn> which api are you using graphitemaster ? [03:19:05 CEST] <graphitemaster> just av_read_frame and for audio avcodec_decode_audio4 with swr_convert to map it to the format and sample rate our application internally requires pretty much everything as [03:21:15 CEST] <graphitemaster> if there is a filter I can just tack onto the stream which does the magical time scale stuff [03:21:18 CEST] <graphitemaster> that'd be neat [03:21:27 CEST] <graphitemaster> not sure where to find the documentation for that though [03:21:32 CEST] <graphitemaster> or if such a thing exists [03:22:47 CEST] <graphitemaster> problem is I need to control the filter while decoding a stream, it needs to be immediate, I can't just open a stream with a filter, I need to control time scale pretty much at runtime at any time. [03:30:24 CEST] <graphitemaster> so it seems atempo is what I want [03:31:09 CEST] <graphitemaster> ah shucks, atempo is limited to 0.5 to 2 inclusive [03:31:13 CEST] <graphitemaster> that's no good :| [03:34:46 CEST] <graphitemaster> can stack atempo filters :| [03:34:53 CEST] <graphitemaster> but man that feels ugly [03:35:39 CEST] <graphitemaster> like, determining at runtime how many atempo filters I need and their coefficients would be basically impossible in the short amount of time I have anyways [10:02:18 CEST] <cone-209> ffmpeg 03Paul B Mahol 07master:4ed7c2bbc3d0: avcodec/utvideodec: add SIMD for restore_rgb_planes [10:28:29 CEST] <thebombzen> what is UT video even used for :O [10:41:39 CEST] <JEEB> thebombzen: it's an open source lossless video thingy that has modules for all.major video frameworks [10:42:04 CEST] <JEEB> thus it got popular for exporting your videos from editors etc [10:42:20 CEST] <thebombzen> Ah. Why not ffv1? isn't that now a standard? [10:42:40 CEST] <JEEB> it's becoming but there are no modules [10:43:06 CEST] <thebombzen> other than libavcodec ones I guess [10:43:09 CEST] <JEEB> also ut video is used to input lossless clips into those frameworks [10:43:33 CEST] <JEEB> basically ut has vfw/dshow/mf/QT [10:43:49 CEST] <thebombzen> hm, according to wikipedia it's also designed to be a more efficient alternative to huffyuv [10:44:01 CEST] <JEEB> so win/mac things can both read/write ut [10:44:04 CEST] <thebombzen> meaning it's probably a lot faster than ffv1 but less good for archiving due to ratio [10:44:31 CEST] <JEEB> yea compression wise ffv1 wins big time [10:45:09 CEST] <thebombzen> I wonder if utvideo is suitable for realtime encoding. Currently I use yuv444p libx264 with -qp 0 [10:45:12 CEST] <thebombzen> and preset superfast [10:57:51 CEST] <rcombs> kierank: poke me on twitter or something? I may have time to drop by today [11:17:25 CEST] <LongChair> jkqxz: hi :) touching base on the drm topic, hoping you had some time to think about it :) [12:07:51 CEST] <durandal_1707> wow foo86 rocks [12:15:40 CEST] <kierank> durandal_1707: LOL [12:15:57 CEST] <durandal_1707> whats funny? [12:16:42 CEST] <kierank> impressive piece of work [12:18:46 CEST] <nevcairiel> wasnt there some talk long ago that dolby might get angry about dolby e decoders [12:18:53 CEST] <kierank> yes they will [12:20:02 CEST] <durandal_1707> just point to vlc people, not us [12:27:24 CEST] <funman> 17:56 <@durandal_1707> only when kierank posts dolby-e decoder [12:27:48 CEST] <funman> too late i guess [12:32:01 CEST] Action: rcombs shrugs [12:32:02 CEST] <rcombs> fuck 'em [12:44:46 CEST] <thebombzen> I was thinking of writing a -vf colorlevelsdetect filter that autodetects the black point and white point to be fed for -vf colorlevels, similar to how -vf cropdetect is used for -vf crop [12:44:55 CEST] <thebombzen> is this something that would get added to libavfilter? [12:46:42 CEST] <thebombzen> or I mean if I write this and submit a patch for it to be added and document it, would there be any reason it's not added [12:51:46 CEST] <durandal_1707> thebombzen: basically you need report max and min value of pixel in video frame? [12:52:02 CEST] <durandal_1707> for example for y component? [12:52:40 CEST] <thebombzen> yea basically, and also scale it to the [0, 1] range because that's what colorlevels takes [12:53:07 CEST] <thebombzen> most likely I'd end up reporting both, but if you want it to end up like cropdetect, which spoon-feeds you the vf crop filter, I'd also have to do the scaling [12:58:15 CEST] <durandal_1707> thebombzen: doesnt cololevels already does that via negative number set for imin and imax? [12:58:35 CEST] <thebombzen> I don't know, does it? [12:59:56 CEST] <thebombzen> I don't actually know what negative input values for imin and imax do, seeing that setting imin to 0 and imax to 1 ends up doing nothing [13:18:25 CEST] <durandal_1707> thebombzen: set input max and min to -1 and watch output [13:23:40 CEST] <thebombzen> durandal_1707: that works, but it changes per-frame and doesn't print the info to stdout [13:24:28 CEST] <thebombzen> which means the filter's parameter change over the course of the input. it sounds like it would be nice for there to be a verbose=yes option or something to print the autodetected filter it's applying [13:24:40 CEST] <durandal_1707> if you need only numbers try signalstats filter [13:24:51 CEST] <thebombzen> hm, one sec, lemme read that [13:25:54 CEST] <durandal_1707> well it will not work for you because its not rgb filter... [13:26:44 CEST] <thebombzen> yea, according to the manpage, signalstats does not output rgb, and colorlevels only does rgb [13:27:35 CEST] <thebombzen> it might make sense to use the Y value if you want to just adjust the value without adjusting the color balance though [13:29:34 CEST] <JEEB> oh wow, dolby-e :D [13:29:38 CEST] <JEEB> foo86 da man [13:35:53 CEST] <funman> they really missed on calling it dolb-e [13:36:22 CEST] <JEEB> :D [13:36:59 CEST] <cone-209> ffmpeg 03Michael Niedermayer 07master:430d4f2bb52e: avcodec/ffv1enc: Allow less than 2 rows of slices for low vertical resolution [13:37:00 CEST] <cone-209> ffmpeg 03Andreas Håkon 07master:a29c7127297a: avformat: Fix Pro-MPEG non-square matrix [13:37:01 CEST] <cone-209> ffmpeg 03Michael Niedermayer 07master:0f8d3d8a462c: avcodec/ffv1enc: compute the max number of slices and limit by that [13:42:16 CEST] <kierank> is there any way i can remove this political bullshit footers from the mailing list [13:47:32 CEST] <Compn> where ? [13:47:38 CEST] <durandal_1707> kierank: what? [13:48:04 CEST] <J_Darnley> I would guess michaelni's most recent email [13:48:08 CEST] <kierank> not singling out michaelni because there are other people but i don't care about stupid politics [13:48:33 CEST] <Compn> oh, the automated signatures in peoples various mails [13:49:04 CEST] <durandal_1707> oh that one is very old... [13:50:26 CEST] <Compn> if you dont care about politics why are you caring abou... nevermind [14:03:46 CEST] <cone-209> ffmpeg 03Paul B Mahol 07master:bbaca6e86799: avcodec/proresenc_kostya: add 4444XQ profile [14:32:58 CEST] <thebombzen> this person links their log on a file upload site that has a shitty html interface that makes you pay or wait 5 seconds or some bs [14:57:22 CEST] <TMM> How is it determined whether enough reviews have taken place on a patch? I've received two reviews with some small fixes which I've processed but it appears that everything went silent again :) [14:57:27 CEST] <TMM> am I supposed to do something? [15:01:26 CEST] <BBB> did you send a new/updated patch? [15:01:35 CEST] <TMM> yes [15:02:06 CEST] <BBB> how long ago? [15:02:34 CEST] <TMM> Sunday [15:02:40 CEST] <durandal_1707> i gonna commit it, its game codecs after all [15:02:45 CEST] <BBB> ok [15:03:37 CEST] <TMM> If there are more fixes needed I'll happily make them :) [15:48:59 CEST] <wm4> " This fixes build failures on older mingw chains (before 2012)." [15:49:00 CEST] <wm4> nevcairiel: why [15:49:19 CEST] <cone-209> ffmpeg 03Hein-Pieter van Braam 07master:ba2c385006e3: Interplay MVE: Implement MVE SEND_BUFFER operation [15:49:20 CEST] <cone-209> ffmpeg 03Hein-Pieter van Braam 07master:8f87bfb4b7dd: Interplay MVE: Refactor IP packet format [15:49:21 CEST] <cone-209> ffmpeg 03Hein-Pieter van Braam 07master:19f6fd199e46: Interplay MVE: Implement frame format 0x06 [15:49:22 CEST] <cone-209> ffmpeg 03Hein-Pieter van Braam 07master:8f96da060a26: Interplay MVE: Implement frame format 0x10 [15:49:23 CEST] <cone-209> ffmpeg 03Hein-Pieter van Braam 07master:c4cbaec6e3af: Interplay MVE: Changelog entry for changes [15:49:24 CEST] <cone-209> ffmpeg 03Paul B Mahol 07master:feab761b73c3: avcodec/interplayvideo: properly check if there is enough bytes left [15:49:40 CEST] <wm4> also I assume it's fine to push merges without review [15:52:05 CEST] <iive> wm4: sure, but you have to fix them if somebody finds they cause regression. [15:52:44 CEST] <TMM> durandal_1707, Did you add those extra checks? [15:52:49 CEST] <TMM> durandal_1707, to interplayvideo? [15:53:16 CEST] <durandal_1707> yes [15:53:32 CEST] <TMM> durandal_1707, isn't that the exact same check that's on like 1292? [15:55:19 CEST] <durandal_1707> TMM: not exactly same, also it checks after doing pointer stuff [15:55:47 CEST] <durandal_1707> i guess that check is now obsolete [15:56:30 CEST] <TMM> bytestream2_init doesn't actually read anything though, right? [15:56:38 CEST] <TMM> that's why I collapsed all those checks at the end [15:56:59 CEST] <TMM> it'll setup all the pointers and bytestreams but it won't actually read anything until after that check [15:57:21 CEST] <durandal_1707> nope, but o dislike idea of incrrasing pointer and checking for overread later [15:57:42 CEST] <TMM> OK, I'll keep that in mind for next time [15:57:51 CEST] <TMM> the reason I did it like this was to ensure that no codepath could exist without that check [15:57:58 CEST] <durandal_1707> check doesnt take into account 14 bytes [15:58:17 CEST] <durandal_1707> of one of modes [15:59:24 CEST] <TMM> ah yeah, it only checks if the total size of the packet is big enough indeed, but the 14 bytes skipped get forgotten about [15:59:34 CEST] <TMM> that's not so great, thanks [16:03:48 CEST] <TMM> durandal_1707, I'll be wanting to merge more stuff from scummvm back into ffmpeg. If you have any other comments please let me know so I won't repeat the same mistakes for the future [16:05:16 CEST] <durandal_1707> TMM: just check for overreads and overwrites if you can [16:05:36 CEST] <durandal_1707> there is more stuff? [16:05:46 CEST] <TMM> yeah, older cocktel vision codec [16:05:51 CEST] <TMM> some bink features [16:05:53 CEST] <TMM> and sierra robot [16:06:21 CEST] <TMM> and I'm working on truemotion1's 'sprite' feature [16:28:28 CEST] <nevcairiel> wm4: what [16:29:16 CEST] <wm4> nevcairiel: I removed the check for disabling dxva with pre-2012 mingw builds [16:29:18 CEST] <wm4> is that ok? [16:29:34 CEST] <nevcairiel> why would you remove something that already exists [16:30:09 CEST] <wm4> because configure is a labyrinth and I don't need an additional wall to enable idiots (people on ancient mingws)? [16:32:12 CEST] <nevcairiel> adding header checks isnt that crazy, but it was like 3 years ago, who knows if anyone still runs those, however entirely failing builds is never nice when you could just disable shit [16:32:38 CEST] <wm4> well I'm not sure what to do with the check [16:33:32 CEST] <wm4> or how it used to work [16:49:12 CEST] <wm4> nevcairiel: want to test my d3d libav merge before I push it? [16:49:24 CEST] <wm4> also I didn't have a chance to test vp9 (not even compilation) [16:49:46 CEST] <wm4> I could probably steal a dxva header from somewhere for that to test compilation at least? [16:49:56 CEST] <iive> wm4: is that check somehow makes merges harder? [16:50:20 CEST] <wm4> iive: yes because Libav didn't have the check [16:51:39 CEST] <nevcairiel> latest mingw-w64 has vp9 at least [16:51:41 CEST] <nevcairiel> i got them to add it [16:52:17 CEST] <iive> is mingw now a distribution? [16:55:05 CEST] <nevcairiel> wm4: do you have a branch for testing? [16:56:40 CEST] <wm4> give me a second [16:57:58 CEST] <wm4> man I wish github had a "merge upstream" button or so [16:58:10 CEST] <wm4> nevcairiel: master branch https://github.com/wm4/ffmpeg/ [16:58:34 CEST] <nevcairiel> yeah its really annoying, w onder why github never tried to solve that problem [16:58:35 CEST] <iive> i thought they have push request or something similar [17:02:18 CEST] <nevcairiel> wm4: the changelog should probably refer to ffmpeg not avconv [17:03:42 CEST] <wm4> sure [17:03:46 CEST] <wm4> fuck the changelog anyway [17:04:08 CEST] <wm4> is just "ffmpeg" the right way to refer to CLI? [17:04:13 CEST] <nevcairiel> i guess [17:05:03 CEST] <wm4> force-pushed my branch to fix that [17:06:25 CEST] <nevcairiel> the dxva2 code sure is full of warnings [17:06:41 CEST] <wm4> example? most should have gone away [17:07:03 CEST] <wm4> but some will just remain if both dxva and d3d are enabled [17:07:11 CEST] <wm4> due to the messy way to making the code "generic" [17:07:14 CEST] <nevcairiel> plenty of those dxva2_internal.h:107:98: warning: pointer type mismatch in conditional expression [17:07:19 CEST] <wm4> yep, this [17:07:25 CEST] <nevcairiel> some const warnings [17:07:34 CEST] <nevcairiel> ibavcodec/dxva2.c:239:59: warning: passing argument 3 of 'dxva2_validate_output' discards 'const' qualifier from pointer target type [17:07:53 CEST] <wm4> huh [17:08:19 CEST] <wm4> that one is easily fixable, and probably should be [17:08:20 CEST] <nevcairiel> warning: "CONFIG_VP9_D3D11VA2_HWACCEL" is not defined, evaluates to 0 [17:08:23 CEST] <nevcairiel> configure missing something? [17:08:31 CEST] <wm4> that sounds worse [17:08:34 CEST] <nevcairiel> or allcodecs.c or whereever? [17:08:40 CEST] <wm4> shit [17:08:53 CEST] <wm4> yes that is missing [17:09:15 CEST] <nevcairiel> these context shit warnigns sure make it hard to find anything else [17:09:29 CEST] <wm4> indeed [17:09:35 CEST] <wm4> pushed a fixup commit [17:09:43 CEST] <wm4> blindly [17:11:23 CEST] <nevcairiel> meh noone ever fixed the problem that you cant run fate with hwaccel anymore [17:11:32 CEST] <nevcairiel> because it now decodes to nv12 and all hashes fail [17:11:44 CEST] <nevcairiel> previously the lack of filte re-config forced it to yuv420 =p [17:11:49 CEST] <JEEB> :D [17:11:53 CEST] <wm4> lol [17:12:11 CEST] <wm4> would be kind of nice if every fate test forced the output format, maybe [17:17:35 CEST] <nevcairiel> so is hwaccel supposed to crop now? [17:17:56 CEST] <nevcairiel> the test at least still fails [17:18:50 CEST] <wm4> only right/bottom borders [17:19:06 CEST] <wm4> the rest isn't hooked up anywhere, at least not with fate [17:19:50 CEST] <durandal_1707> my asm code made function 5x times faster but original utvideo decoder is still faster, how so? [17:20:35 CEST] <atomnuker> by how much? [17:20:51 CEST] <nevcairiel> maybe there is more things to accelerate [17:26:22 CEST] <wm4> nevcairiel: still testing my branch? [17:27:59 CEST] <nevcairiel> yeah had to reconfigure to test vp9 properly, another minute [17:28:24 CEST] <wm4> so I don't get any warnings for dxva2.c here, which is confusing [17:28:44 CEST] <wm4> I think I got at least the pointer type warnings in Libav [17:29:04 CEST] <nevcairiel> maybe for random reasons d3d11va is off for you? [17:29:51 CEST] <wm4> d3d11va, d3d11va2, dxva2 are all enabled [17:30:12 CEST] <wm4> they also worked when I tested them earlier this day [17:30:50 CEST] <nevcairiel> hrm now the build failed entirely [17:31:02 CEST] <nevcairiel> dxva2_vp9.c(354): error C2027: use of undefined type 'dxva2_picture_context' [17:31:08 CEST] <nevcairiel> let me clean to make sure nothing is wonky [17:31:37 CEST] <nevcairiel> ah no seems like an actual bug [17:31:46 CEST] <nevcairiel> d3d11va was just disabled before [17:32:05 CEST] <wm4> copy&paste error [17:32:21 CEST] <wm4> pushed another fixup for this [17:32:22 CEST] <nevcairiel> AV_CODEC_ID_H264 in there [17:32:26 CEST] <nevcairiel> for vp9 [17:32:28 CEST] <wm4> blerghhdl [17:32:28 CEST] <nevcairiel> :) [17:32:50 CEST] <wm4> ok, pushed another one [17:39:01 CEST] <nevcairiel> does d3d11va output to yuv420p for some reason or is it just not used? [17:39:21 CEST] <nevcairiel> either that or vp9 d3d11va just doesnt work [17:39:38 CEST] <wm4> no, it should output no nv12 [17:39:41 CEST] <wm4> *to [17:42:15 CEST] <nevcairiel> do all the get_format calls need the new d3d11 pix_fmt? [17:42:18 CEST] <nevcairiel> because vp9 didnt get it [17:42:32 CEST] <wm4> they do, and that explains it [17:42:56 CEST] <wm4> I'll add it [17:44:07 CEST] <nevcairiel> works with that added [17:44:10 CEST] <nevcairiel> should be good then [17:44:15 CEST] <wm4> pushed [17:44:54 CEST] <wm4> ok then I'll rebase it to put the fixes into their proper places [17:47:44 CEST] <wm4> pushed to my branch, want to take another look or should I push to the ffmpeg main repo? [17:49:17 CEST] <cone-209> ffmpeg 03James Almer 07master:4d62ee674699: x86inc: don't use read-only data sections on COFF targets [17:53:50 CEST] <wm4> nevcairiel: *prod* [17:55:06 CEST] <nevcairiel> i'll compile it again real quick, but i hope you didnt rebase wrong :) [17:55:33 CEST] <wm4> I hope not... seems like all fixes went into the big commit [18:01:53 CEST] <nevcairiel> wm4: should be good to go [18:06:26 CEST] <wm4> somehow pushing is stuck [18:06:39 CEST] <cone-209> ffmpeg 03wm4 07master:3303511f33dc: lavu: add new D3D11 pixfmt and hwcontext [18:06:40 CEST] <cone-209> ffmpeg 03wm4 07master:865360ba633b: lavc: set avctx->hwaccel before init [18:06:41 CEST] <cone-209> ffmpeg 03wm4 07master:ab28108a3611: dxva: preparations for new hwaccel API [18:06:42 CEST] <cone-209> ffmpeg 03wm4 07master:5659f7404731: dxva: move d3d11 locking/unlocking to functions [18:06:43 CEST] <cone-209> ffmpeg 03wm4 07master:70143a3954e1: dxva: add support for new dxva2 and d3d11 hwaccel APIs [18:06:44 CEST] <cone-209> ffmpeg 03Martin Storsjö 07master:3125a4a8a8fc: d3d11va: Link directly to dxgi.dll and d3d11.dll functions if LoadLibrary is unavailable [18:06:45 CEST] <cone-209> ffmpeg 03wm4 07master:e2afcc33e0bc: dxva: add declarative profile checks [18:06:46 CEST] <cone-209> ffmpeg 03wm4 07master:39f201a0ec79: dxva: fix some warnings [18:06:47 CEST] <cone-209> ffmpeg 03wm4 07master:1509d739a036: hwcontext_d3d11va: fix crash on frames_init failure [18:06:48 CEST] <cone-209> ffmpeg 03wm4 07master:6f5ff3269b12: hwcontext_d3d11va: allocate staging texture lazily [18:06:49 CEST] <cone-209> ffmpeg 03wm4 07master:8d7fdba7b867: dxva: support DXGI_FORMAT_420_OPAQUE decoding [18:06:50 CEST] <cone-209> ffmpeg 03wm4 07master:289d387330d8: hwcontext_d3d11va: add option to enable debug mode [18:06:51 CEST] <cone-209> ffmpeg 03wm4 07master:f0bcedaf37ed: dxva: verbose-log decoder GUID list [18:06:52 CEST] <cone-209> ffmpeg 03Anton Khirnov 07master:d14179e3d49e: hwframe: Allow hwaccel frame allocators to align surface sizes [18:06:55 CEST] <wm4> ah [18:07:55 CEST] <BtbN> Something is weird with the git server for a while. Feels like the push-hooks take forever [18:09:23 CEST] <jamrial> BtbN: yes, it's been like that since the server move [18:29:07 CEST] <durandal_1707> atomnuker: it used lot of cpu, for rgb, but i cannot test old utvideo any more so cant bench it [18:29:38 CEST] <durandal_1707> which is really weird because it worked before [18:30:48 CEST] <durandal_1707> nevcairiel: only obvious thing to simd was thing i did but it didnt improve overall performance a lot [18:31:19 CEST] <nevcairiel> Even pulling is slow from git [18:31:23 CEST] <durandal_1707> and i cannot get perf tools to work at all [18:31:50 CEST] <durandal_1707> dos attack again? [18:33:43 CEST] <jamrial> pulling is fine here [18:34:45 CEST] <durandal_1707> so anyone have perf setup already? [18:35:37 CEST] <ubitux> durandal_1707: what do you need? [18:36:40 CEST] <ubitux> btw, it's nice to have the functions in checkasm for benching [18:37:06 CEST] <durandal_1707> ubitux: get results of utvideo decoding performance for rgb24 format [18:37:20 CEST] <ubitux> can you provide command/sample? [18:37:37 CEST] <durandal_1707> encode with utvideo testsrc2 [18:37:45 CEST] <ubitux> what resolution? [18:37:52 CEST] <durandal_1707> hd1080 [18:41:44 CEST] <ubitux> 98.13% ffmpeg_g ffmpeg_g [.] decode_plane.constprop.6 [18:41:46 CEST] <ubitux> 1.19% ffmpeg_g ffmpeg_g [.] ff_restore_rgb_planes_sse2 [18:43:05 CEST] <ubitux> damnit perf still has this weird offset shift on the instruction time [18:43:37 CEST] <ubitux> http://ubitux.fr/pub/pics/2017-06-27-184312_280x227_scrot.png the 3 in red are obviously the 3 movdqa [18:44:23 CEST] <ubitux> durandal_1707: anyway, most of the code seems spent on the bitstream reader [18:45:40 CEST] <durandal_1707> yea, need to see if libav bitreader helps here [18:46:09 CEST] <ubitux> s/code/time/ [18:48:32 CEST] <jamrial_> durandal_1707: it might. afaik it helped huffyuv and other lossless decoders [18:49:48 CEST] <ubitux> yeah, it will likely help on x86_64 [18:51:52 CEST] <cone-209> ffmpeg 03James Almer 07master:fa50d9360ba3: x86/vf_blend: add sse and ssse3 extremity functions [18:51:53 CEST] <cone-209> ffmpeg 03James Almer 07master:0daa1cf07318: x86/vf_blend: optimize difference and negation functions [18:54:11 CEST] <jamrial> ubitux: speaking of speed, do you know why the aarch64 stereo interpolate functions are so slow? [18:54:23 CEST] <jamrial> the others you wrote got a decent speed up [18:55:03 CEST] <ubitux> i'm guessing it's hiting the memory bus bottleneck [19:10:02 CEST] <paras_2052> durandal_1707: hi, by metadata you mean the header of the fits image, right ? and i have to export it using the metadata AVDictionary in the AVFrame ? [19:10:37 CEST] <durandal_1707> paras_2052: yes [19:10:56 CEST] <paras_2052> durandal_1707: okay [19:24:19 CEST] <durandal_1707> ugh the avconv is 17% faster in decoding utvideo [19:24:51 CEST] <durandal_1707> 96 vs 116 fps [19:25:22 CEST] <JEEB> wow [19:25:33 CEST] <durandal_1707> atomnuker: have you looked at writing alternative bit reader? [19:26:21 CEST] <atomnuker> it can't be that slow [19:26:27 CEST] <kierank> durandal_1707: LOL [19:26:29 CEST] <kierank> drama [19:26:51 CEST] <durandal_1707> try it [19:27:06 CEST] <atomnuker> kierank: you hypocrite [19:27:32 CEST] <atomnuker> you create the drama by calling it drama in the first place and then you complain about there being drama! [19:27:46 CEST] <kierank> i was referring to previous drama [19:28:53 CEST] <durandal_1707> please no more drama surges [19:29:12 CEST] <kierank> ok [19:30:05 CEST] <atomnuker> durandal_1707: fine, I'll work on that tonight [19:30:31 CEST] <atomnuker> the residual reader for the dirac vlc codes I wrote ought to chew through everything [19:30:57 CEST] <durandal_1707> atomnuker: no need if you dont want :) [19:31:33 CEST] <atomnuker> its not about will its about pride now... 17% [19:32:39 CEST] <wm4> at this rate there will be more a few more forks before we can reunify with Libav [19:33:27 CEST] <atomnuker> >implying its even possible [19:35:29 CEST] <durandal_1707> yuv420p is even worse its 90 vs 120 or 25% [19:35:46 CEST] <durandal_1707> guess my simd helped lot [19:36:41 CEST] <durandal_1707> that or avconv is making numbers up [19:37:51 CEST] <durandal_1707> michaelni: improve bitreader and we can keep both prores encoders and decoders :) [19:38:33 CEST] <jamrial> durandal_1707: shouldn't be hard to just drop the bitstream reader header in our tree, cherry pick the utvideo bitstream reader port commit and see if that's what made it faster [19:39:18 CEST] <jamrial> no pls, just one of each [19:47:20 CEST] <wm4> we should write a new h264 decoder to encourage healthy competition [19:52:52 CEST] <durandal_1707> ffmpegs hevc is much faster than libavs [19:53:07 CEST] <ubitux> we have some missing simd though [19:53:13 CEST] <kierank> vp9 as well [19:53:53 CEST] <JEEB> ubitux: someone should just gcc -S that stuff and do the x264inc dance :D [19:54:28 CEST] <JEEB> HEVC is so far relatively low on my priority list so I haven't gotten to doing that [19:54:40 CEST] <JEEB> esp. since the intrinsics patches do still apply [19:54:48 CEST] <JEEB> which for local usage is "enough" [19:54:50 CEST] <ubitux> it's been years i hear about this "someone" guy that is going to save us all :( [19:54:58 CEST] <JEEB> yes :< [19:55:07 CEST] <JEEB> he is so busy we haven't seen him in years [20:05:03 CEST] <J_Darnley> Okay. I've got an big question regarding avcodec. [20:05:48 CEST] <J_Darnley> Does it already have the ability to encode a slice (part of a frame) without the whole frame being available? [20:06:02 CEST] <atomnuker> nope [20:06:25 CEST] <atomnuker> I thought you knew you had to take the encoder out of lavc [20:06:57 CEST] <durandal_1707> jamrial: stole libav bitstream and got 146 fps prev was 96 [20:07:28 CEST] <jamrial> haha [20:07:37 CEST] <durandal_1707> so its even faster than libav [20:07:54 CEST] <jamrial> yeah, the new bitstream is good with lossless video, at least on x86_64 [20:08:21 CEST] <jamrial> problem was with audio codecs, which was slower in some cases. i think ac3 and aac [20:08:54 CEST] <J_Darnley> atomnuker: I think I will have to [20:09:25 CEST] <J_Darnley> That might be slightly easier than trying to extend avcodec like that. [20:10:38 CEST] <kierank> J_Darnley: don't worry about the avcodec problems for now [20:10:41 CEST] <jamrial> durandal_1707: test x86_32 as well [20:10:54 CEST] <durandal_1707> jamrial: cant [20:11:17 CEST] <kierank> J_Darnley: being able to encode slice by slice (and not doing the transform on the entire image) is a big goal in itself [20:11:31 CEST] <J_Darnley> kierank: well as far as I can tell because sliced threading exists what you want already exists. [20:11:38 CEST] <durandal_1707> kierank: are you gonna use rust-av? [20:11:42 CEST] <kierank> J_Darnley: no, that's not quite [20:11:49 CEST] <kierank> J_Darnley: the transform is still run on the entire frame [20:11:53 CEST] <kierank> and then the slices are encoded iirc [20:12:00 CEST] Action: J_Darnley looks again [20:12:41 CEST] <kierank> J_Darnley: https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vc2enc.c;h=96e27… [20:12:47 CEST] <kierank> yeah the plane is transformed [20:13:04 CEST] <kierank> might also end up being faster doing the transform per-slice because the data is in cache [20:13:10 CEST] <J_Darnley> you are quite right there [20:14:58 CEST] <kierank> there are also various papers on vc-2 [20:16:29 CEST] <kierank> also https://github.com/bbc/vc2-reference [20:16:38 CEST] <kierank> https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&u… [20:16:45 CEST] <kierank> http://downloads.bbc.co.uk/rd/pubs/whp/whp-pdf-files/WHP238.pdf [20:16:48 CEST] <kierank> http://downloads.bbc.co.uk/rd/pubs/whp/whp-pdf-files/WHP159.pdf [20:16:50 CEST] <kierank> and those [20:17:21 CEST] <kierank> J_Darnley: try implementing haar on a slice, atomnuker will agree it's the simplest [20:17:24 CEST] <kierank> and easiest to get working [20:19:39 CEST] <kierank> J_Darnley: or you can perhaps try it on the decode [20:19:39 CEST] <kierank> https://github.com/atomnuker/ffmpeg_dirac_trimmed [20:19:51 CEST] <kierank> forget about the ffmpeg mainline decoder it has a ton of legacy stuff [20:20:53 CEST] <kierank> atomnuker: decoder is easier, right? [20:20:53 CEST] <tmatth> kierank: did you ever stream vc-2 over RTP or other? [20:20:59 CEST] <kierank> tmatth: no but that's the goal [20:21:20 CEST] <tmatth> kierank: nice, in upipe or some other repo? [20:21:37 CEST] <kierank> dunno tbh, none of the OSS frameworks are designed for super low latency [20:21:44 CEST] <kierank> so we might have to hack something in upipe [20:21:54 CEST] <kierank> by low latency I mean encoding slices before the frame has arrived [20:24:05 CEST] <atomnuker> not sure about the decoder, I think it'll take more work to start from the decoder [20:24:29 CEST] <kierank> atomnuker: are you sure not doing valid decoding slice by slice will be easier? [20:24:33 CEST] <atomnuker> for a starting point just do the transforms first on both the decoder and encoder on a per-slice basis [20:24:45 CEST] <kierank> well for a decoder you know you'll be right [20:25:08 CEST] <atomnuker> then rip both up and modify them to write the actual bitstreams on a per slice basis [20:25:12 CEST] <kierank> atomnuker: i never really understood how to handle the cases with large transforms and small slices but perhaps you may be able to help [20:27:25 CEST] <kierank> ah there are edge extension rules [21:00:11 CEST] <gh0st__> Does anyone have a machine with a cpu that has avx-512 instruction set to test avx-512 assembly code on it? [21:05:39 CEST] <Compn> a few devs have one iirc [21:05:52 CEST] <Compn> there might even be one setup for people to test on... [21:06:11 CEST] <Compn> i asked the intel guy to give us some chips to do tests and dev on hehe [21:06:15 CEST] <Compn> didnt get a reply tho [21:08:15 CEST] <BtbN> Isn't that pretty much limited to Xeon Phi right now? [21:09:01 CEST] <jamrial> no, skl-x is out [21:38:59 CEST] <Gramner> skl-x is released since yesterday, but motherboards in particular seems hard to come by [21:44:20 CEST] <Gramner> skl-x has avx-512{f, cd, bw, dq, vl} extensions, so everything you need for multimedia stuff [21:46:21 CEST] <gh0st__> Cool [22:09:21 CEST] <Compn> user talking about sample wav file with 32 channels [22:09:28 CEST] <Compn> can we up the max_channels limit ? [22:09:44 CEST] <Compn> michaelni ? [22:11:21 CEST] <cone-161> ffmpeg 03Ilia Valiakhmetov 07master:35a5d9715dd8: avcodec/vp9: add 64-bit ipred_dr_32x32_16 avx2 implementation [22:25:07 CEST] <michaelni> Compn, which limit where ? there are alot of MAX_CHANNELS and variants in the codebase [22:27:01 CEST] <Compn> hmm [22:27:48 CEST] <Compn> "Invalid sample rate or channel count!" [22:28:19 CEST] <Compn> weird, https://lists.ffmpeg.org/pipermail/ffmpeg-cvslog/2011-June/037929.html [22:28:37 CEST] <Compn> michaelni : i've asked for sample, maybe will be uploaded tomorrow [22:28:38 CEST] <nevcairiel> wav files cant really represent 32 channel properly, since its channel layout gives up at that point [22:29:27 CEST] <Compn> yeah i dont think its for playback , with channel layouts [22:29:35 CEST] <Compn> more for production music work [22:29:42 CEST] <Compn> or voice tracks [22:54:31 CEST] <durandal_1707> michaelni: ffmpeg with libav bitreader still beats your patchset, so new bitreader is still to go [22:56:41 CEST] <nevcairiel> the differences in the bitstream readers are extremely dependent on your compiler [23:08:04 CEST] <durandal_1707> nevcairiel: really? try it with your compilers [23:22:54 CEST] <cone-161> ffmpeg 03Michael Niedermayer 07master:2c874548d663: avcodec/hevcdec: do basic validity check on delta_chroma_weight and offset [23:22:55 CEST] <cone-161> ffmpeg 03Michael Niedermayer 07master:c578c9c229f0: libswresample/swresample: remove obsolete code [00:00:00 CEST] --- Wed Jun 28 2017

1 0

ffmpeg.log.20170627
by burek 28 Jun '17

28 Jun '17

[00:00:04 CEST] <hanna> JEEB: oh joy [00:00:04 CEST] <JEEB> https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2390-2-2017-PDF-E.pdf [00:00:19 CEST] <JEEB> "High dynamic range television for production and international programme exchange" [00:01:52 CEST] <hanna> https://0x0.st/UY2.png yeah herp [00:01:56 CEST] <hanna> this is exactly what I was talking about [00:02:02 CEST] <hanna> outdoor scenes in movies now hurt my eyes just like outdoor scenes in real life [00:02:55 CEST] <alexpigment> jeeb: "Of these, we will only address the first one here." , nice going on that Common Misconceptions section ;) [00:03:09 CEST] <JEEB> :D [00:03:18 CEST] <hanna> JEEB: honestly I'm liking what I'm reading in this report [00:03:22 CEST] <hanna> may even convince me not to do a blog article on HDR [00:03:24 CEST] <JEEB> anyways, I just happened to notice that spec [00:03:25 CEST] <hanna> and just link to that report instead [00:03:29 CEST] <JEEB> completely randomly [00:03:52 CEST] <JEEB> part 6 is all about HLG it seems [00:04:34 CEST] <alexpigment> hanna: if you have a blog that focuses on this sort of thing, feel free to PM me the link. I'm always interested in reading about video technology [00:04:44 CEST] <hanna> also good diagram of what tone mapping is about https://0x0.st/UY_.png [00:05:01 CEST] <hanna> alexpigment: not really, I just randomly post shit whenever I feel like it and not all of it has to do with video stuff [00:05:12 CEST] <alexpigment> ah [00:07:53 CEST] <hanna> https://0x0.st/UY9.png interesting [00:08:17 CEST] <hanna> reminds me of the tone mapping curve I came up with [00:09:06 CEST] <hanna> https://camo.githubusercontent.com/ac457c2ff89d541bf365aa1294ab4aad3be364ef… (green curve is the one we use in mpv now) [00:11:12 CEST] <komanda> iive: you don't put your local /etc/passwd in the video, you make an avi that when transcoded to mp4 will open the servers /etc/passwd and put that in the mp4 [00:12:12 CEST] <komanda> i need out server to support transcoding m3u8 to mp4 but want to disallow it from opening local filesystem files [00:12:58 CEST] <iive> komanda: i really hope you've read the .py file and you are sure that it does what you say it does. [00:15:08 CEST] <komanda> iive: i tried it in a sandboxed docker container and it does work, for any local file, not just /etc/passwd [00:15:27 CEST] <JEEB> yes but did you check it does what you think it does? [00:15:41 CEST] <komanda> iive: the container I made the exploit avi didn't even have the file that was in the output mp4 [00:15:56 CEST] <JEEB> as far as I can tell with http://git.videolan.org/?p=ffmpeg.git;a=commit;h=189ff4219644532bdfa7bab28d… the HLS decoder checks files for extension [00:16:06 CEST] <JEEB> local files that is [00:16:29 CEST] <BtbN> make sure you are actually testing with the latest ffmpeg [00:16:55 CEST] <JEEB> komanda: also you can build your FFmpeg without the file protocol altogether [00:17:06 CEST] <JEEB> and most likely other ways are there as well [00:23:05 CEST] <iive> JEEB: are m3u8 handled by hls code? [00:23:18 CEST] <JEEB> those that are actual HLS playlists, yes [00:24:19 CEST] <hanna> hmm [00:24:20 CEST] <iive> and if you give them raw text m3u8? [00:24:37 CEST] <JEEB> what? [00:24:44 CEST] <JEEB> HLS playlists /are/ raw text m3u8 [00:24:49 CEST] <JEEB> (Ž4@) [00:25:24 CEST] <hanna> no idea if I generated these images correctly but if it worked, then https://0x0.st/UYV.jpg is what mpv does out of the box (assume 1000 cd/m² display, tone map down to 1.0) and https://0x0.st/UYW.jpg is what I get when I plug the parameters of an SDR display into the HLG ootf (results in gamma 0.78, peak = 1.0) [00:25:27 CEST] <iive> i mean, if you give the list as local text file. [00:25:37 CEST] <hanna> keeping in mind both are tone-mapped to my display [00:25:54 CEST] <JEEB> iive: local HLS playback is something often done which is why I guess http://git.videolan.org/?p=ffmpeg.git;a=commit;h=189ff4219644532bdfa7bab28d… was done [00:26:25 CEST] <JEEB> since originally it just had `if (!av_strstart(proto_name, "http", NULL) && !av_strstart(proto_name, "file", NULL))` there [00:27:53 CEST] <hanna> here is mpv with hable tone mapping instead of mobius https://0x0.st/UY4.jpg [00:28:45 CEST] <iive> JEEB: so If I give ffmpeg a local file with extension .m3u8, it will parse it with the hls code, [00:29:16 CEST] <JEEB> well, yes [00:29:18 CEST] <hanna> and with clipping instead of tone mapping: https://0x0.st/UYJ.jpg [00:29:33 CEST] <hanna> hard to prefer the HLG OOTF here [00:29:45 CEST] <JEEB> iive: it probably has some checks with the probing so it at least looks like a HLS playlist though [00:29:48 CEST] <hanna> it makes all the colors more flat, while the contrast in the other tone mapping curves is more objectively closer to ground truth (clipping) [00:29:51 CEST] <JEEB> but that doesn't require much [00:30:03 CEST] <iive> i ask, because i remember m3u playlist been a thing in winamp, long before i've heard abuot hls [00:30:15 CEST] <iive> and winamp turned into video player too. [00:30:20 CEST] <JEEB> hanna: I like it how this recommendation mentions "hey, yo, we have the CL version of BT.2020 too - which fixes these certain issues you know!" [00:30:29 CEST] <hanna> mobius unfortunately warps the colors as it clips [00:30:31 CEST] <hanna> hmm [00:30:39 CEST] <hanna> this might be a good test sample to train a different tone mapping colorspace on [00:30:46 CEST] <hanna> actually [00:30:53 CEST] <hanna> maybe it's the =clip image that's distorting the colors [00:31:10 CEST] <JEEB> iive: well yes it came from audio playlists and then got used by apple for other means [00:31:25 CEST] <meriipu> if I use split on a video stream and map them to two outputs, how could I only encode audio once and copy it to the second destination? [00:31:44 CEST] <JEEB> meriipu: ffmpeg.c doesn't let you do that as far as I know [00:31:57 CEST] <JEEB> you have to write an API client yourself for that [00:32:13 CEST] <JEEB> which encodes once and then pushes those coded packets to multiple muxers [00:33:10 CEST] <meriipu> is real time audio encoding on (fairly) recent hardware to say mp3 fast enough that two streams hardly makes a difference over one? [00:33:27 CEST] <JEEB> yes [00:33:52 CEST] <JEEB> if you're not using something like a low-power ARM CPU you should be OK [00:34:00 CEST] <meriipu> I suppose I can live with the non-neat but simple way for now then. Thanks. [00:35:58 CEST] <hanna> this is =mobius before the XYZ patch: https://0x0.st/UYx.jpg [00:36:17 CEST] <hanna> and this is =clip before the XYZ patch: https://0x0.st/UY3.jpg [00:37:38 CEST] <hanna> skin color doesn't seem to be significantly affected [00:37:56 CEST] <hanna> but the color of all the reds changes, hmm [00:39:41 CEST] <hanna> anyway what this image tells me is that mpv tone mapping still needs to be improved by a *lot* [00:39:49 CEST] <hanna> but unfortunately, tone mapping in a way that doesn't distort colors is extremely tricky [00:40:02 CEST] <hanna> you can do the tone mapping on the luma channel instead of per-RGB but that result in a weird flatness to the image [00:40:08 CEST] <hanna> as colors also need to be desaturated [00:40:12 CEST] <hanna> in order to fit again [00:41:24 CEST] <durandal_1707> JEEB: you can encode once mux many with ffmpeg [00:41:32 CEST] <JEEB> oh [00:41:41 CEST] <hanna> what you could do is e.g. do tone mapping in LCh: 1. tone map lightness, 2. compute relative size of the chromaticity plane at that brightness, 3. tone map the saturation component according to this [00:41:43 CEST] <JEEB> without piping? [00:41:59 CEST] <hanna> but I can never figure out how to actually do clipping in LCh except by trial and error [00:42:31 CEST] <durandal_1707> JEEB: there is somewhere in muxers docs [00:42:39 CEST] <hanna> I think what we ought to do is move this into the 3DLUT and do it offline with high quality tone mapping algorithms [00:42:42 CEST] <JEEB> oh right, the tee muxer_ [00:42:46 CEST] <JEEB> that thing existed :P [00:48:01 CEST] <hanna> https://0x0.st/UYl.jpg this is what I get if I tone-map on the luma channel only [00:48:38 CEST] <hanna> actually I think I prefer that [00:48:41 CEST] <hanna> it's way closer to ground truth [00:48:46 CEST] <hanna> and basically just nukes specular detail completely [00:48:57 CEST] <hanna> I think the flatness I was complaining about was the fact that tone mapping this way removes specular highlights [00:49:00 CEST] <hanna> instead of distorting them [00:49:28 CEST] <hanna> so yeah let's do it this way [02:18:34 CEST] <hiihiii> can I tell ffmpeg to half the framerate using fps filter without actually describing any number? [02:19:03 CEST] <hiihiii> if the input is 60fps I don't want to say -vf "fps=30" [02:19:14 CEST] <nicolas17> what's a good lossless format to store my original data? currently I have a folder with tens of thousands of JPEG files and it's unmanageable [02:19:44 CEST] <nicolas17> it's too big, and since it's one file per frame I don't get filesystem readahead [02:20:27 CEST] <nicolas17> the latter could be solved by packing it into a single video file with MJPEG codec using -vcodec copy, but that will still be too big :p [02:20:50 CEST] <nicolas17> it's ~2MB/frame [02:23:59 CEST] <hiihiii> lossless means you'll still get a big output whatever codec you use [02:24:08 CEST] <nicolas17> sure [02:25:03 CEST] <hiihiii> try lib256 with -crf 0 [02:26:12 CEST] <nicolas17> I'd love to do this on some VPS with fast SSD storage, but it will take me 15 days to upload it :P [02:26:54 CEST] <hiihiii> if your frames are "generic" in nature and/or have a lot of similarities then maybe you'll get a good compression [02:27:40 CEST] <nicolas17> probably [02:27:44 CEST] <nicolas17> this was like a security camera [02:28:22 CEST] <nicolas17> (GoPro fixed to the ceiling doing timelapse) [02:28:57 CEST] <furq> you probably won't get any smaller than mjpeg [02:29:04 CEST] <furq> unless most frames are identical [02:29:51 CEST] <hiihiii> if it's a security camera then you'd probably be ok [02:29:55 CEST] <furq> flv1 and x264 lossless are probably your best choices [02:30:05 CEST] <furq> and most security cameras have a lot of sensor noise which will screw that up [02:30:28 CEST] <furq> not to mention the jpeg compression artifacts [02:30:41 CEST] <nicolas17> furq: it was a GoPro HERO (I think first gen), just saying it was fixed in the room in a similar way to a security camera [02:30:42 CEST] <furq> i guess try it with a short sample first [02:31:06 CEST] <furq> probably depends on the lighting then [02:31:29 CEST] <furq> either way try it with 1000 frames or so and see if you get passable results [02:31:55 CEST] <furq> either -c:v libx264 -qp 0 -preset veryslow or -c:v ffv1 [02:32:12 CEST] <hiihiii> why not libx265? [02:32:22 CEST] <nicolas17> I'm trying x264 with crf 0 now [02:32:28 CEST] <furq> shrug [02:32:31 CEST] <furq> i've never used x265 lossless [02:32:35 CEST] <nicolas17> it's eating my laptop CPU :D [02:32:36 CEST] <furq> i assume it'll be incredibly slow [02:32:36 CEST] <hiihiii> I understand the playback issues but still [02:32:52 CEST] <furq> and i have no idea if it's noticeably better than x264 [02:33:21 CEST] <furq> nicolas17: you can use a faster preset if x264 is too slow [02:33:25 CEST] <furq> obviously that'll compress worse [02:33:58 CEST] <hiihiii> well lossless x264 will probably be ok with his input. I'm guessing the entropy is good even with noise [02:34:27 CEST] <furq> if it's a gopro in good light then it should be fine [02:34:51 CEST] <furq> really bad grain/noise will destroy any chance of compressing it further [02:37:16 CEST] <hiihiii> btw is there a way to use fps filter such that it halfs the framerate without knowing the source's fps? [02:41:19 CEST] <nicolas17> 217M vid-copy-2s.mkv (-vcodec copy, ie. mjpeg) [02:41:21 CEST] <nicolas17> 222M vid-x264-crf0-2s.mkv [02:41:23 CEST] <nicolas17> 185M vid-ffv1-2s.mkv [02:41:59 CEST] <hiihiii> try x265 [02:43:35 CEST] <meriipu> I am not really sure how I can fit encoding of audio into this (so that it is encoded twice, once for each output) https://bpaste.net/show/8986832214d9 [02:46:31 CEST] <nicolas17> damn, x265 takes seconds per frame [02:47:54 CEST] <grublet> Yeah totally not worth it IMO [02:51:37 CEST] <nicolas17> 127M vid-x265-crf0-2s.mkv [02:51:51 CEST] <nicolas17> but the encode went at 0.4fps [02:53:46 CEST] <furq> try with x264 -preset veryslow [03:39:47 CEST] <eric__> Is there documentation somewhere about aevalsrc expressions? The fancy filtering example (https://trac.ffmpeg.org/wiki/FancyFilteringExamples#aevalsrc) is helpful, but I'm unfamiliar what language it is written in. Any help? [03:44:41 CEST] <furq> http://ffmpeg.org/ffmpeg-utils.html#Expression-Evaluation [03:44:53 CEST] <furq> https://ffmpeg.org/ffmpeg-filters.html#aevalsrc [03:45:52 CEST] <utack> didn't the last moscow university test determine x265 is better than x264, even when faster? [03:45:58 CEST] <eric__> @furq Thank you! [03:46:04 CEST] <furq> utack: link [03:46:21 CEST] <utack> this one http://compression.ru/video/codec_comparison/hevc_2016/ [03:46:21 CEST] <furq> last benchmark i saw was rbultje's benchmark which showed x265 was worse at the same speed as x264 veryslow [03:46:27 CEST] <furq> that's from late 2015 though [03:46:36 CEST] <utack> fig 33 [03:46:51 CEST] <furq> http://compression.ru/video/codec_comparison/hevc_2016/figures/videos.png [03:46:57 CEST] <furq> this looks like it'll be an easy article to follow [03:46:59 CEST] <utack> yeah unfortunately, but unlikely it got worse? [03:47:12 CEST] <utack> this one http://compression.ru/video/codec_comparison/hevc_2016/figures/graph3.png [03:48:18 CEST] <utack> now of course the measurement for quality...always debatable i know [03:48:25 CEST] <furq> Overall, the leaders in this comparison are Intel MSS HEVC and Kingsoft HEVC encoders! [03:48:28 CEST] <furq> uh [03:48:36 CEST] <furq> i take it these are commercial because i've never heard of them [03:48:52 CEST] <furq> also wtf are nj264 and nj265 [03:50:31 CEST] <furq> literally the only reference i can find to nj264 is this comparison [03:55:08 CEST] <Syl20> Hi, I'm trying to compile ffmpeg with --enable-decklink option, can someone help me please ? [04:08:58 CEST] <utack> furq seems to be some patched version https://mirror.tuna.tsinghua.edu.cn/solus/unstable/x/x264/ [04:16:35 CEST] <myke> what's the sanest way to use a gif for a stream? -loop doesn't work on gifs and converting the gif to a video and then looping it with -stream_loop doesn't quite work right either [04:17:17 CEST] <furq> -ignore_loop 0 -i foo.gif [04:19:36 CEST] <myke> holy cow i did not find that on stack overflow or anywhere, thanks [04:19:40 CEST] <myke> exactly what i wanted [04:30:04 CEST] <m1a0yu3> Hi, Does anyone know how to disable ffmpeg from grabbing local files in m3u8 format? [05:11:10 CEST] <Syl20> Hi, I'm trying to compile ffmpeg with --enable-decklink option, can someone help me please ? [06:21:46 CEST] <androclu`> furq, you out there? [06:26:06 CEST] <thebombzen> kerio: it's called colorlevels but I don't know how to do it automatically [06:29:42 CEST] <androclu`> i am getting errors from ffmpeg, ever since upgrading to debian 9 (stretch). [06:30:04 CEST] <androclu`> both from repo version and static. [06:30:19 CEST] <androclu`> so i went a 3rd route and compiled my own [06:30:22 CEST] <androclu`> that breaks too [06:30:32 CEST] <nicolas17> define "breaks" [06:30:55 CEST] <androclu`> this time i compiled with debugging symbols [06:30:56 CEST] <androclu`> the output is here https://bpaste.net/show/8c30dd176628 [06:31:30 CEST] <androclu`> i guess the debugging symbols give more info. without these, i was just getting seg-faults, and no info at all [06:31:53 CEST] <androclu`> while we speak, i am re-running same command, but inside gdb.. i suppose i should have something come up shortly [06:32:06 CEST] <nicolas17> you'd have to run it under gdb and get a backtrace [06:32:57 CEST] <androclu`> okay. that info at bottom not helpful, eh? [06:33:57 CEST] <nicolas17> "illegal instruction" does look somewhat suspicious; what CPU do you have? [06:35:25 CEST] <androclu`> 8-core Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz .. have /proc/cpu if u need it.. [06:36:33 CEST] <androclu`> possible i have a cpu going bad (one of the 8)? [06:36:49 CEST] <androclu`> (although i am not experiencing any other problems..) [06:37:08 CEST] <nicolas17> does it fail always at the same point? [06:38:12 CEST] <androclu`> well, i can't say i know because that output is the first one i captured that had any helpful info [06:38:31 CEST] <androclu`> is the "0x55fdf56319c0" the address it fails at? [06:38:54 CEST] <nicolas17> well if it once failed very shortly after you started the encoding, and another time it failed after several minutes of processing, then you know it's not deterministic :) [06:39:18 CEST] <androclu`> yes, well *that* much i can confirm. sometimes 2 minutes in.. sometimes 15.. etc [06:39:47 CEST] <nicolas17> hmmm then it does have a chance of being a hardware issue [06:39:56 CEST] <androclu`> grrrr... [06:40:10 CEST] <nicolas17> it's not certain, it absolutely could be something else [06:40:16 CEST] <androclu`> hrmm... [06:41:35 CEST] <androclu`> do you know of any linux (or other) utilities for checking hardware? [06:41:58 CEST] <nicolas17> linux distros usually put memtest86 in the boot menu [06:42:03 CEST] <nicolas17> that would check RAM [06:42:05 CEST] <androclu`> yes.. [06:42:08 CEST] <androclu`> and cores? [06:43:23 CEST] <androclu`> i see one out there called, 'cpuburn' [06:43:49 CEST] <nicolas17> I knew of that one, but I couldn't find it... [06:43:54 CEST] <nicolas17> I'm in debian testing, maybe they removed it [06:48:37 CEST] <goppo> hi [06:48:42 CEST] <goppo> is there a way to specify the output dir? [06:49:47 CEST] <goppo> my current command looks like ffmpeg -i rtsp://admin@192.168.1.104/user=admin_channel=1_stream=0.sdp -acodec aac -strict -2 -vcodec copy -f segment -segment_time 1800 -segment_format mpegts -strftime 1 "%Y-%m-%d_%H-%M.mpeg" [06:50:14 CEST] <nicolas17> uh, "path/to/dir/%Y-%m-%d_%H-%M.mpeg"? [06:50:45 CEST] <goppo> oh! [06:50:50 CEST] <goppo> lol [06:50:51 CEST] <goppo> thanks [06:54:11 CEST] <androclu`> nicolas17: yeah, same. but debian does have stress-ng and psensor [06:54:32 CEST] <androclu`> nicolas17: maybe cpuburn was only compiled for ubuntu :( [06:55:05 CEST] <nicolas17> looks like cpuburn is old [06:55:18 CEST] <nicolas17> and not optimized for modern CPUs [06:56:10 CEST] <androclu`> i'm fine with that :P .. stress-ng is working, and apparently there is also phoronix-test-suite [06:56:37 CEST] <androclu`> i suppose i shall have to play with them a bit to figure out how to stress each core separately [06:56:52 CEST] <androclu`> psensor, however, does say 0RPM for my cpu fan [06:58:22 CEST] <nicolas17> peek inside your computer and see if it's spinning or not :P [07:02:12 CEST] <androclu`> nicolas17: yeah, there are actually 2 big fans on either side of it -- both spinning [07:17:44 CEST] <Fenrirthviti> Hmm, anyone familiar with NVENC limitations? What's the max framerate it will encode at 1080p? [07:29:42 CEST] <androclu`> nicolas17: bingo [07:30:19 CEST] <nicolas17> CPU caught fire? [07:30:31 CEST] <androclu`> heheh.. [07:30:39 CEST] <androclu`> at this point, i almost sort of wish it would [07:31:02 CEST] <androclu`> oh, crap. this is my first time reading gdb output. i guess it actually finished! crud [07:31:13 CEST] <androclu`> "[Inferior 1 (process 810) exited normally]" [07:31:46 CEST] <nicolas17> bah [07:31:55 CEST] <androclu`> agreed [07:32:08 CEST] <androclu`> "when the mechanic is looking, the car works" [07:36:36 CEST] <androclu`> nicolas17: i have to call it a day. but i'll run it again overnight without gdb. the only thing i did differently (besides run it through gdb) was that i took the top off the case. maybe running just a tad cooler was what it needed (crossing fingers). [07:37:22 CEST] <androclu`> nicolas17: and the guy i bought this comp. from 2 years ago did say he overclocked the cpus. maybe there is just something a tad different in this new kernel for stretch that manages temps or cores a little differently? [07:38:01 CEST] <androclu`> nicolas17: anyway, thx for your ideas and support.. i'll find out in the morning if it barfed. [08:13:06 CEST] <Kirito> https://a.uguu.se/eg1r0OJrDXbx_dopus_2017-06-27_02-08-16.png two versions of the same clip encoded with the same settings at constant framerates. Only difference is one was exported from Adobe Premiere at 30fps with optical flow interpolation and one at 60fps with the same. Somehow the 60fps version apparently compresses better. That is.. weird o_O. [08:59:02 CEST] <kerio> thebombzen: ye colorlevels worked [08:59:06 CEST] <kerio> with manually specified limits [08:59:18 CEST] <kerio> which probably make sense, cuz otherwise the effect would be quite jarring [08:59:37 CEST] <thebombzen> yea, you have to do it manually. doing it frame-by-frame would be wrong (duh) but I was hoping it could autodetect it based on the first frame [08:59:43 CEST] <thebombzen> or an average of the first frame [08:59:49 CEST] <thebombzen> first few frames [09:00:31 CEST] <kerio> well no i mean i kinda want that i guess [09:00:34 CEST] <kerio> because of reasons [09:00:35 CEST] <thebombzen> also I think it's probably better to increase the precision to 16-bit before doing colorlevels, then you can deband and reduce to 10-bit before encoding [09:00:44 CEST] <kerio> this is 16 bit already [09:01:04 CEST] <thebombzen> alright good. Something you can do is dump the first frame and open it with an image editor like GIMP, and pick "autolevels" and see what values it comes up with [09:02:04 CEST] <kerio> does colorlevels adjust values linearly [09:02:09 CEST] <kerio> because this ain't really rgb [09:03:22 CEST] <thebombzen> well it's in float [09:03:36 CEST] <thebombzen> so the depth doesn't affect the input values [09:03:51 CEST] <thebombzen> but given that colorlevels affects rgb, I assume you'd have to convert it to rgb first to make it work well [09:03:58 CEST] <thebombzen> like zscale,format=gbrp16le [09:04:40 CEST] <kerio> no i mean that's fine i guess [09:05:07 CEST] <kerio> but are the values adjusted linearly between imin/imax and omin/omax? [09:05:14 CEST] <kerio> or does it use some other relation [09:05:36 CEST] <thebombzen> yea, it's linear as long as the gray point is 1.0 [09:05:39 CEST] <kerio> rgb is supposed to have output levels proportional to the square root of the actual value [09:06:00 CEST] <thebombzen> I believe it's quadratic if you set the gray point [09:06:16 CEST] <thebombzen> the gray point is the gamma. if you set it to 1 then it's linear. the color curves tell this to you [09:06:19 CEST] <kerio> but colorlevels doesn't have a gray point D: [09:06:51 CEST] <thebombzen> then it will be linear [09:06:52 CEST] <kerio> but yea [09:06:54 CEST] <kerio> coeff = (omax - omin) / (double)(imax - imin); [09:07:00 CEST] <kerio> dst[x + offset] = av_clip_uint8((src[x + offset] - imin) * coeff + omin); [09:07:16 CEST] <thebombzen> ah yep, it's linear [09:07:39 CEST] <thebombzen> I wish there was a filter like detectlevels [09:07:55 CEST] <thebombzen> -vf colorlevelsdetect that just works like cropdetect [09:08:09 CEST] <thebombzen> best used with -frames:v 1 [09:08:18 CEST] <kerio> i should probably use a real colorizer actually [09:08:23 CEST] <thebombzen> probably [09:08:28 CEST] <kerio> with output that's perceptually uniform [09:08:39 CEST] <kerio> but eh, pretty cool [09:13:44 CEST] <thebombzen> kerio: I do know about the square root thing but I was under the impression that modern imaging technology knew that [09:13:50 CEST] <thebombzen> like photoshop and GIMP both accounted for tha [09:33:33 CEST] <Gertm> Having trouble hardcoding subs. When doing it with files where the subs are SSA, it works fine, but not with srt subs. This is what I've tried: https://pastebin.com/JnMrpg3D [09:33:42 CEST] <Gertm> Does anyone have experience with that? [09:38:49 CEST] <thebombzen> Gertm: try ffmpeg -i input.mkv -vf subtitles=input.mkv output.mkv [09:39:08 CEST] <thebombzen> of course, set the encoding options, and you probably don't want to map the subtitle stream. [09:39:14 CEST] <Gertm> thebombzen: Did that, didn't work. [09:39:23 CEST] <thebombzen> what does "didn't work" mean [09:39:29 CEST] <Gertm> Yet with ass subs, it does work. [09:39:39 CEST] <Gertm> thebombzen: THe video output does not have the subs on it. [09:39:50 CEST] <Gertm> They have not been hardcoded onto the video. [09:39:54 CEST] <thebombzen> did you try -vf subtitles=subs.srt [09:39:59 CEST] <thebombzen> after extracting the subrip stream [09:40:23 CEST] <thebombzen> ffmpeg -i input.mkv -map s -c copy subtitles.srt [09:40:33 CEST] <thebombzen> ffmpeg -i input.mkv -vf subtitles=subtitles.srt [09:41:04 CEST] <Gertm> The pastebin entry has all the different commands I tried. [09:41:17 CEST] <Gertm> That one was one of them. [09:41:19 CEST] <thebombzen> well the pastebin entry has "-s" [09:41:22 CEST] <thebombzen> which is not an option [09:41:33 CEST] <thebombzen> so I assume you modified it and then I elected to ignore it [09:42:02 CEST] <Gertm> I will go over it again. [09:42:14 CEST] <thebombzen> why don't you try the command I suggested without using -ss and -t and then saying the one I suggested doesn't work [09:42:23 CEST] <thebombzen> when you didn't try it, you tried something approximately equal [09:42:48 CEST] <thebombzen> for the record, -ss can mess up the subtitles filter because it relies on the timestamp of the frames being sent to it [09:43:23 CEST] <thebombzen> if you use ffmeg -ss 1:00 -i input.mkv -vf subtitles then it'll put the subtitles at the beginning of the stream, they will be off by one minute, because the subtitles being passed to the subtitles filter start at a timestamp of 0 [09:43:31 CEST] <Gertm> Aha [09:43:41 CEST] <thebombzen> so keep that in mind [09:43:50 CEST] <Gertm> I'll try it on the full file without cutting. I was cutting it to speed up the encoding times. [09:44:02 CEST] <thebombzen> You can cut it, you just need to also offset the timestamp of the input [09:44:23 CEST] <thebombzen> something like ffmpeg -ss 2:00 -copyts -start_at_zero -i input.mkv [09:45:11 CEST] <thebombzen> if you do that, then the video frames passed to the filterchain will start at two minutes rather than 0. However, you will need to append setpts=PTS-STARTPTS to the filterchain so the final video has it start at zero and not two minutes [09:47:17 CEST] <Gertm> Ok, let me parse all that info and try again. [09:48:31 CEST] <Gertm> This is what I have now: ffmpeg -y -i input.mkv -c:v h264 -crf 18 -c:a copy -map 0:0 -map 0:1 -vf subtitles=subs.srt output.mkv [09:48:50 CEST] <Gertm> I extracted the srt files with mkvextract. [09:48:57 CEST] <Gertm> This didn't result in the subs being hardcoded. [09:50:09 CEST] <Gertm> I do get fontconfig errors, but it says it'll use the fallback. [09:50:48 CEST] <Gertm> Could it go wrong because ffmpeg can't find the correct font to use? [10:20:40 CEST] <thebombzen> Gertm: post the complete output [10:21:38 CEST] <Gertm> Hold on, I screwed up my fonts in general. Mixed up the symlink config from linux. [10:21:50 CEST] <Gertm> I think my windows fonts are screwed now, lemme fix this first. :) [10:21:59 CEST] <thebombzen> symlinks technically work on windows nowadays but lots of stuff hates them [10:22:20 CEST] <Gertm> Oh yeah, even windows itself. [10:30:14 CEST] <Gertm> thebombzen: https://pastebin.com/CjX3g56P Obviously something with my font config is screwed up. [10:32:24 CEST] <thebombzen> Hm [10:32:31 CEST] <thebombzen> what build of ffmpeg is this? [10:32:48 CEST] <thebombzen> cause the Zeranoe builds link in fontconfig, freetype, and fribidi [10:33:04 CEST] <Gertm> Hmm probably installed through chocolatey [10:33:20 CEST] <Gertm> I'll replace it with the zeranoe builds if that'll fix it. [10:33:48 CEST] <thebombzen> yea, let's see. the command you entered looks like it works, although I'd replace -c:v h264 with -c:v libx264 [10:34:00 CEST] <thebombzen> I think it's chosen that way by default but it's good to be unambiguous about which h.264 encoder you want [10:34:22 CEST] <thebombzen> otherwise it'll autoselect that one, or h264_qsv or something [10:36:27 CEST] <Gertm> Ok I'll change that now. [10:37:17 CEST] <Gertm> Ok the zeranoe build doesn't start, it's complaining about libsnappy. I downloaded the wrong thing probably. Lemme try again. [10:42:23 CEST] <Gertm> thebombzen: I was using the 3.3.1 build from zeranoe it seems. I switched to a working version of the nightlies (20170620) and now it works. The subs have been hardcoded. [10:42:26 CEST] <Gertm> Thanks for your help! [10:44:35 CEST] <thebombzen> you're welcome [10:44:45 CEST] <thebombzen> in this case it was just a font issue. figures. FOONNNNNTSS [10:45:11 CEST] <Gertm> Still, without you asking the right questions, I wouldn't have been able to solve it. [10:45:43 CEST] <dongs> how the hell do I trim stuff with ffmpeg BETWEEN two timestamps. a basic freaking feature --ss 00:10:00 -to 00:20:00 i expect resulting file to be 10 seconds, not 20 or 30 or wahtever teh shit it ended up being [10:45:56 CEST] <dongs> -to needs claculating minus offset, -t needs length calculation [10:46:04 CEST] <dongs> i just want to take 2 timestamps in media player and trim between them [10:52:01 CEST] <dongs> anyone?! [10:52:54 CEST] <thebombzen> dongs: it's 5 a.m. in US Eastern, be patient [10:53:02 CEST] <thebombzen> to answer your question, -to does not work the way you think it does [10:53:10 CEST] <thebombzen> or it doesn't work the way it seems like it should [10:53:16 CEST] <dongs> well, no kidding [10:53:36 CEST] <dongs> i dont want to do h:m:s calculations for -t or -to [10:53:37 CEST] <thebombzen> the reason being that -ss not only seeks to a particular time but it also shifts all the video timestamps to the left by that time, which makes sense [10:54:12 CEST] <thebombzen> so if you use -ss 10:00, it starts the video at 0, so if you use -ss 10:00 -to 20:00, it stops encoding at the 20:00 timestamp.... which is inconveniently 20 minutes after the start of the video [10:54:27 CEST] <dongs> correct. [10:54:39 CEST] <dongs> i know the problem and the cause, waht im trying to figure out is a solution for hte lazy (like me) [10:55:07 CEST] <dongs> also for some reason just muxing is pretty slow in general [10:55:16 CEST] <dongs> im working on a SSD, trimming a ~40gb hevc .ts file [10:55:20 CEST] <dongs> and its only doing like 40meg/sec [10:55:33 CEST] <dongs> surely it should be way faster than that just doing stream copy [10:55:34 CEST] <thebombzen> so there's two solutions I can think of [10:56:00 CEST] <thebombzen> one is to be disappointed and convert all your timestamps into seconds, and do the subtraction yourself [10:56:06 CEST] <thebombzen> you can do this with awk [10:56:49 CEST] <dongs> that... isnt gonna work :p [10:56:51 CEST] <dongs> next choice? [10:56:53 CEST] <thebombzen> why not? [10:57:17 CEST] <thebombzen> is there any particular reason you are intentionally avoiding it? [10:57:52 CEST] <dongs> -ss 00:04:11 -i trash.ts -to 02:27:33 [10:58:00 CEST] <dongs> because convertting this to seconds is super fucking annoying [10:58:06 CEST] <thebombzen> not if you're using a script [10:58:17 CEST] <dongs> surely theres gotta be a better way [10:58:20 CEST] <thebombzen> awk -F: '{ n = 1; for (i = NF; i > 0; i--) { out = $i * n + out; n = n * 60 } print out }' [10:58:24 CEST] <thebombzen> this for example does it [10:58:27 CEST] <dongs> yeah i dont have awk.exe [10:58:48 CEST] <thebombzen> ah, on windows. [10:59:00 CEST] <thebombzen> also, you should not really be seeking mpegts files [10:59:12 CEST] <thebombzen> mpegts seeking is not guaranteed to work. it might, but you should not expect it to [10:59:32 CEST] <thebombzen> but anyway, try this: [10:59:49 CEST] <thebombzen> ffmpeg -i trash.ts -c copy temp1.mkv [10:59:57 CEST] <thebombzen> just to get it out of mpegts [11:00:42 CEST] <dongs> 40 gigs at 30meg/sec jsut to change container type? [11:00:52 CEST] <dongs> the whole reason I'm chatting here is cuz im trying to avoid having to re-trim this thing again [11:00:55 CEST] <dongs> :) [11:01:22 CEST] <dongs> ts seeking works fine btw thats all i ever worked with [11:01:31 CEST] <thebombzen> Well mpegts is not easily seekable, unless you want to decode, but okay. [11:01:47 CEST] <dongs> what? you dont need to decode to seek in it [11:01:52 CEST] <dongs> there's PTS [11:01:59 CEST] <thebombzen> you do if you want to seek mpegts reliably [11:02:09 CEST] <thebombzen> because mpegts is not a seekable container by design [11:02:28 CEST] <thebombzen> however, you seem to have two conflicting issues here [11:02:39 CEST] <dongs> start trim worked just fine [11:02:42 CEST] <dongs> (and it alawys has) [11:02:56 CEST] <thebombzen> 1. You (for some reason) are very very resistant to just calculating the duration of the output in seconds [11:03:04 CEST] <dongs> its hard to do man [11:03:07 CEST] <thebombzen> No it's not [11:03:21 CEST] <thebombzen> 2. You are trying to avoid disk reads/writes [11:03:42 CEST] <thebombzen> unfortunately, what you want to do is hard [11:03:52 CEST] <thebombzen> to actually answer your question, you have two options [11:04:03 CEST] <thebombzen> 1. suck it up and push the calculator button [11:04:48 CEST] <thebombzen> 2. ffmpeg -ss start_timecode -copyts -start_at_zero -i input.ts -to end_timecode out.ts [11:05:08 CEST] <thebombzen> make sure you set the codec options as well [11:05:30 CEST] <thebombzen> however, out.ts will have a start timecode that is not zero [11:05:46 CEST] <thebombzen> which only works because it's mpegts, and some players might still reject it [11:06:06 CEST] <thebombzen> if you want it to not do that, you'll need to process the video afterward with a setpts filter [11:07:28 CEST] <thebombzen> alternatively, you can do ffmpeg -ss start_timecode -copyts -start_at_zero -i input.ts -vf 'trim=end=end_timecode,setpts=PTS-STARTPTS' codec_options out.ts [11:07:50 CEST] <thebombzen> dongs: ^ this here works, but takes more time to type than just using -t and subtracting [11:09:14 CEST] <nahsi> I need to generate a sample clip from a movie which will consist of random parts of it preferably not so random (ie some scenes with motion, some dark scenes, some scenes with low contrast etc) so I can then encode this clip with different settings and see a difference. How can I do that? I was not able to generate a search query for google sorry [11:10:20 CEST] <thebombzen> well if you're looking for particular scenes with certain properties, you probably have to find the time of them manually [11:11:27 CEST] <thebombzen> there is no filter to automatically generate a short representative set of scenes of a movie [11:11:32 CEST] <thebombzen> you just have to do that one by hand [11:13:03 CEST] <nahsi> thebombzen: thanks a lot [11:17:34 CEST] <dongs> thebombzen: end_timecop and pts-startpts are the start/end timestamps? [11:17:39 CEST] <dongs> err end_timecode lu [11:17:44 CEST] <thebombzen> in seconds yea [11:17:47 CEST] <dongs> .. ins econds [11:17:49 CEST] <thebombzen> or in time duration [11:17:50 CEST] <dongs> that doesnt solve anything at all [11:17:52 CEST] <dongs> oh [11:18:05 CEST] <thebombzen> I meant not actually in PTS units [11:18:08 CEST] <thebombzen> or in timebase units [11:18:11 CEST] <dongs> 00:04:11 -i trash.ts -to 02:27:33 [11:18:14 CEST] <dongs> are you saying i can use these [11:18:15 CEST] <dongs> and it will wokr? [11:18:29 CEST] <thebombzen> well if you're going from 4 minutes 11 seconds to 2 hours 27 minutes 33 seconds? yes [11:18:33 CEST] <dongs> yes [11:19:38 CEST] <dongs> what is PTS-STARTPTS is that atuallty 00:04:11 or some kinda keyword [11:19:52 CEST] <dongs> no looks like keyword [11:20:50 CEST] <dongs> Filtergraph ''trim=end=02:27:33,setpts=PTS-STARTPTS'' was defined for video output stream 0:0 but codec copy was selected. [11:20:54 CEST] <dongs> Filtering and streamcopy cannot be used together. [11:25:14 CEST] <thebombzen> you need to escape the \s [11:25:17 CEST] <thebombzen> er escape the :s [11:25:30 CEST] <dongs> whaT? [11:25:48 CEST] <thebombzen> the filtergraph uses : to separate arguments to a filter [11:26:00 CEST] <thebombzen> in this case end=02:27:33 is the argument [11:26:13 CEST] <thebombzen> otherwise end=02 will be passed as one argument, 27 will be passed as the second, and 33 will be the third [11:26:15 CEST] <thebombzen> you don't want that [11:26:30 CEST] <dongs> wtf [11:26:31 CEST] <thebombzen> also, you can't use codec copy with filters. You need to re-encode the video [11:26:39 CEST] <dongs> latest "static" zeranoa builds are asking for libsnappy or some other shit [11:26:44 CEST] <dongs> and i just deleted whatever old exes I had [11:26:46 CEST] <dongs> fuuuuu [11:26:53 CEST] <thebombzen> They shouldn't [11:26:55 CEST] <dongs> they are [11:27:05 CEST] <dongs> The program can't start because libvidstab.dll is missing from your computer. Try reinstalling the program to fix this problem. [11:27:13 CEST] <dongs> and libsnappy.dll [11:28:03 CEST] <dongs> well if i need to reencode this whole thing is useless, thats waht I dont wanna do [11:28:15 CEST] <thebombzen> that's not ordinary, so it's probably just a bug in the build [11:28:34 CEST] <dongs> I jsut realized, i downloaded some nightly bullshit [11:28:35 CEST] <thebombzen> well if you don't want to re-encode then you won't get accurate timestamps [11:28:38 CEST] <dongs> deleting it [11:28:46 CEST] <thebombzen> nightly is not "bullshit" [11:28:51 CEST] <thebombzen> it master is the most stable verion of FFmpeg [11:28:54 CEST] <dongs> of course it is, it doesnt even work :) [11:29:05 CEST] <thebombzen> that's not an issue with Zeranoe, not FFmpeg [11:29:15 CEST] <dongs> the 1st not isnt needed [11:29:37 CEST] <thebombzen> yes congrants you recognized the intent through my typo [11:29:46 CEST] <thebombzen> either way, you don't want to re-encode which means the timecodes won't be perfect [11:29:49 CEST] <thebombzen> are you okay with that? [11:30:04 CEST] <dongs> i dont want them perfect, regular -c copy trim works fine if only the fucking timestamps didnt need calculation [11:30:33 CEST] <thebombzen> dongs: you realize that if you had pulled up your calculator, you'd have solved this already, right? [11:30:38 CEST] <dongs> for sure [11:30:41 CEST] <dongs> but i want a permanent solution [11:30:50 CEST] <dongs> this is something i have to do enough times for it to get annoying [11:31:05 CEST] <dongs> and I always have ONLY start/end timestamps [11:31:10 CEST] <dongs> not duration or other bullshit. [11:31:31 CEST] <thebombzen> well you could write a script. but either way, try this: [11:31:32 CEST] <dongs> i suppose if there was a webshit i can type in 2 hms timestamps and get a hms duration that would work but even thats more work than just typing nubmers in [11:32:20 CEST] <thebombzen> ffmpeg -ss 4:11 -copyts -start_at_zero -i input.ts -to 02:27:33 -c copy -f mpegts - | ffmpeg -f mpegts -i - -c copy output.ts [11:32:52 CEST] <thebombzen> the purpose of the second ffmpeg is to sanitize the timestamps so the output file doesn't have timestampsstarting at 4:11 but rather at 0 [11:33:46 CEST] <thebombzen> keep in mind, it takes more time to type this command out than it does to pull up a calculator and do the arithmetic [11:33:53 CEST] <dongs> not to me [11:34:17 CEST] <dongs> i wonder if i can skip the second one. pts doesnt need to start at zero in mpegts, infact it rarely does in captures anyway [11:35:29 CEST] <dongs> stream copy speed decreased... [11:35:35 CEST] <dongs> with new build vs ~last year [11:35:59 CEST] <thebombzen> that's because you're running two ffmpeg processes that are also doing it [11:36:04 CEST] <thebombzen> also streamcopy speed is extremely fast [11:36:07 CEST] <dongs> no i skipped the second one [11:36:09 CEST] <thebombzen> that should not really be an issue [11:36:19 CEST] <dongs> thebombzen: then why is it only going at 30meg/sec [11:36:34 CEST] <thebombzen> didn't you just say that was your hard drive read speed [11:37:36 CEST] <dongs> http://bcas.tv/paste/results/rAUtwz32.html [11:37:37 CEST] <dongs> thats not what i said [11:39:14 CEST] <dongs> i can copy a file off same ssd to nas, while its trimming, and it will saturate gbit link (110meg/sec around). so its not the read OR the write speed [11:39:48 CEST] <dongs> neways tryimg to trim without 2nd ffmpeg, see what happens [11:42:33 CEST] <dongs> ok [11:42:35 CEST] <dongs> thebombzen: this works [11:43:02 CEST] <dongs> ffmpeg -ss 00:04:11 -copyts -start_at_zero -i fail.ts -to 02:27:33 -c copy trim.ts [11:46:16 CEST] <thebombzen> alright [11:46:30 CEST] <dongs> i dont mind that pts doesnt start at zero, like i said, it never does in ts anyway [12:10:30 CEST] <modestpharaoh> hi, Is there a way to update quicktime metadata (com.apple.quicktime.location.name & com.apple.quicktime.location.date) that specified here https://developer.apple.com/library/content/documentation/QuickTime/QTFF/Me… using ffmpeg [14:46:37 CEST] <meriipu> is there a sane limit to how high I should set thread_queue_size for audio? I have raised it to 4096 and still get warnings about considering raising it [15:11:57 CEST] <DHE> audio is probably fine to skyrocket. just make sure you're not actually CPU-bound in your encoding. [15:17:29 CEST] <atomnuker> meriipu: using alsa? its probably alsa. [15:25:27 CEST] <meriipu_> oh it actually ended up using 100% memory somehow completely locking compoop [15:30:57 CEST] <__deivid__> Hi. I think I talked to you before DHE, about my servers reaching ~75% cpu usage [15:31:51 CEST] <__deivid__> I have 4 servers with CPU E5-2640 v4 (20 cores, 40 threads) [15:32:44 CEST] <__deivid__> Running 9 ffmpeg instances, each with 4 threads for the video transcode and (I guess?) 1 for the audio transcode. My problem is that the cpu usage is like 75% [15:33:53 CEST] <BtbN> doesn't seem overly unexpected? [15:33:56 CEST] <iive> well, you might be hitting bottleneck somewhere else. like HDD read/write speed [15:34:22 CEST] <iive> or even getting short on RAM. [15:34:26 CEST] <__deivid__> I'm reading/writing to ram [15:34:31 CEST] <__deivid__> nah. I have 64gb [15:34:44 CEST] <__deivid__> and pci-e ssds [15:35:03 CEST] <__deivid__> (These are not my servers, a guy hired me to transcode, a fuckton of videos) [15:35:15 CEST] <__deivid__> http://i.imgur.com/zLpyc2I.png [15:36:01 CEST] <iive> well, each instance could easily eat 2-4GB, and if the files are few GB eatch... [15:37:00 CEST] <__deivid__> That's what the load looks like. Running 8,9 or 10 jobs shows the same load with average cpu usage (user) ~75% [15:38:09 CEST] <BtbN> Just overcommit a bit [15:38:24 CEST] <BtbN> ffmpeg/x264 will never fully use all its threads to 100% [15:39:28 CEST] <Threads> isnt it best to just have it set to 0 so it cant set the threads its self. [15:39:35 CEST] <Threads> cant = can [15:39:53 CEST] <__deivid__> Maybe, but then how many jobs should I run? [15:40:11 CEST] <BtbN> If you want one job to use all it can get and use, yes [15:40:11 CEST] <__deivid__> I have a central queue and all servers pick up jobs and start transcoding [15:40:20 CEST] <BtbN> but for multiple things in parallel, limiting might be a good idea [15:42:54 CEST] <__deivid__> `perf` shows 49% libavcodec, 30% libx264, 13% libswscale [15:44:22 CEST] <iive> does avcodec use automatically threading for decoding? [15:46:07 CEST] <__deivid__> My videoflags are -vf scale=-2:720 -profile:v high -level 4.0 -pix_fmt yuv420p -threads:v 4 [15:47:23 CEST] <iive> yes, but are these threads for the encoder or the decoder? [15:47:59 CEST] <iive> e.g. profile, level are encoder options [15:48:14 CEST] <kepstin> since you haven't specified any other options, I guess that means x264 is using the defaults, which iirc are -preset medium -crf 23. If you want it to use more cpu, you can try a slower preset :) [15:48:18 CEST] <DHE> BtbN: the "concern" is that, on my own similar system, 92% seems like a sort of total CPU limit. Adding more jobs (not disk bottlenecked) doesn't raise overall CPU usage any [15:48:39 CEST] <__deivid__> preset is 'veryfast' right now for some quality/speed testing [15:49:26 CEST] <kepstin> using faster presets, veryfast in particular, limits the amount of multithreading x264 can do. [15:49:29 CEST] <iive> if you are still doing testing, try decoding the files, to raw encoder and pipe the output to /dev/null [15:49:46 CEST] <iive> this should test your reading and decoding speed. [15:50:23 CEST] <__deivid__> I have to transcode like 14k hours so testing more stuff is always worth [15:50:33 CEST] <kepstin> you could also play around with cpu affinities, assigning each encoder some dedicated cores, might help if the issue is scheduling related. [15:50:54 CEST] <DHE> I tried it with preset 'slow' and 1080p output. no love [15:51:17 CEST] <DHE> <Threads> isnt it best to just have it set to 0 so it can set the threads its self. # you'd think so, but when you hit 40 threads (80 if you're dual socket) this becomes a bad idea. [15:52:23 CEST] <kepstin> also note that the same crf with different presets will give slightly different quality, so if you're checking quality you should use the preset you're actually going to be using. [15:52:36 CEST] <kepstin> the difference is usually fairly minor, tho. [16:15:09 CEST] <fin-ger> Hi, I'm currently trying to create a tiled video from 4 video files (with audio). The videos should be arranged in a grid (2x2). Additionally one audio file should be mixed into the output video. I want to adjust the volume of each audio stream separately. This is what I've got: https://dpaste.de/UXcR Currently ffmpeg hangs when rendering has nearly finished (a couple of seconds are missing in the output file). What is wrong with my filter? [16:24:39 CEST] <__deivid__> kepstin: I just set the affinity to all process to dedicated cores and it's the same [16:27:20 CEST] <__deivid__> kepstin: `perf` changed from 49% libavcodec, 30% libx264 to 40%, 40% [16:30:27 CEST] <kepstin> so when you look at the cpu usage in 'top', you are actually seeing some significant percentage idle ('id')? [16:31:16 CEST] <kepstin> and there's no/minimal time spend in io wait ('wa')? [16:33:22 CEST] <__deivid__> 45.0 user, 4.0 system, 15.9 nice, 34.0 idle, 0.5 wait [16:33:33 CEST] <__deivid__> yup [16:33:59 CEST] <__deivid__> idle in general is ~25 instead of 34 [16:34:16 CEST] <__deivid__> I have a 48hour average cpu usage on 75% [16:37:24 CEST] <meriipu> I have been searching around but I have not really found much of a solution to warnings of the sort [libfdk_aac @ 0x121fb60] Queue input is backward in time/on-monotonous DTS in output stream 0:1 it gets printed a lot of times for the first few seconds of my ffmpeg instantiation and then seems to stop [16:38:06 CEST] <meriipu> they might not be related but they were printed together a lot [16:53:20 CEST] <fin-ger> anybody? [17:08:43 CEST] <fin-ger> I think my issue is related to inputs of unequal length... But I don't know how to fix this. [17:09:41 CEST] <__deivid__> fin-ger: that's your problem. You can use -shortest I think so the output file will end when the first input ends [17:11:45 CEST] <tezogmix> On some devices that can't handle 59-60fps, I've been converting them to 1/2 of their fps (e.g. -r 30000/1001) and same resolution scale (mostly 1080p, 8000+ bitrate and using -crf 15, fast/veryfast preset). Is there a command I can add to compensate for some of the visually lost effects of the downgrade in fps? I've been looking at the "-tune film" [17:12:18 CEST] <tezogmix> The content is live/action. [17:12:46 CEST] <fin-ger> __deivid__: Hmm -shortest does not change anything [17:13:28 CEST] <__deivid__> it's an output option, are you using it correctly? [17:13:46 CEST] <__deivid__> I remember having the same issue a while back and I fixed it with -shortest [17:14:50 CEST] <fin-ger> __deivid__: I added it after the `-i` input parameters (my command line: https://dpaste.de/UXcR) [17:16:06 CEST] <__deivid__> try before $6 ? I think it should work anyway, maybe there's a weird interaction between filter-complex and shortest [17:16:31 CEST] <tezogmix> I'm not sure if there's a filter that could be used.... live/action example: animals moving around at the zoo [17:16:53 CEST] <__deivid__> https://ffmpeg.org/ffmpeg-filters.html#Examples-9 [17:16:55 CEST] <kepstin> tezogmix: converting to œfps basically means dropping every other frame, there's no way to retain smoothness of motion when doing that. [17:16:59 CEST] <__deivid__> check that example [17:17:53 CEST] <tezogmix> ah hey kepstin , that's the word I was looking for "smoothness" - yeah, it's quite noticeable with the 1/2fps... didn't know if there was something I could add to the command line to possibly make up for that. [17:17:59 CEST] <kepstin> tezogmix: there's some things you can do to e.g. blend the dropped frames into the kept frames, which can sometimes look like motion blur. [17:18:12 CEST] <kepstin> but in general, if you want smoothness, you need more frames per second. [17:18:20 CEST] <kepstin> that's it, really... [17:18:35 CEST] <__deivid__> fin-ger https://stackoverflow.com/questions/33330279/ffmpeg-selects-shortest-movie-… [17:19:09 CEST] <kepstin> tezogmix: if your devices support 1080i at 60 fields/s, you might consider doing an interlaced encode to tradeoff spatial resolution for temporal. [17:20:08 CEST] <tezogmix> cool kepstin , I'll have to try both of your suggestions, is it a string we can just add to the executed ffmpeg command? [17:20:39 CEST] <fin-ger> __deivid__: It is still hanging... [17:21:02 CEST] <tezogmix> I meant, independently to test and inserted before the output file name.... [17:21:08 CEST] <kepstin> tezogmix: only consider the interlaced option if you know your playback devices have reasonable support for deinterlacing (e.g. you're outputting to aTV or something) [17:21:43 CEST] <tezogmix> yes will need to check on the specifics on the latter kepstin - [17:23:05 CEST] <tezogmix> kepstin, googling real quick, is it "blend or tblend" ? [17:23:54 CEST] <tezogmix> https://www.ffmpeg.org/ffmpeg-filters.html#blend_002c-tblend [17:27:37 CEST] <fin-ger> __deivid__: This is what I got now: https://dpaste.de/BVv5 All inputs are ~16sec long. ffmpeg stops at ~time=00:00:15.87 The (so far) written output file is ~9 seconds long when played with vlc [17:28:35 CEST] <__deivid__> try adding shortest=1 to the overlay filters [17:28:38 CEST] <__deivid__> https://ffmpeg.org/ffmpeg-filters.html#overlay-1 [17:29:25 CEST] <kepstin> tezogmix: hmm, I don't actually know how to get ffmpeg to blend frames in the way I was thinking of. The 'framerate' filter won't do it with an simple multiple like œ. [17:31:00 CEST] <tezogmix> ah ok kepstin appreciate the remarks to simply be aware of... just in awe with how much is under the hood with possibilities in using ffmpeg... much respect to all who work on the project :) [17:31:01 CEST] <kepstin> you might be able to do with with tblend, try "-vf tblend=all_mode=average,fps=30000/1001" or so. The result will probably be very blurry [17:31:34 CEST] <fin-ger> __deivid__: Now it hangs with the messages: `[Parsed_overlay_18 @ 0xafe680] [framesync @ 0xb03428] Sync level 1` where this message appears for Parsed_overlay_16, Parsed_overlay_17 and Parsed_overlay_18 [17:32:15 CEST] <kepstin> (and the tblend idea won't handle scene cuts well, so it'll generally look pretty bad) [17:32:30 CEST] <__deivid__> fin-ger I don't know. Maybe someone else can help you. When I tried to do some weird stuff with ffmpeg eventually I gave up and used gstreamer [17:33:02 CEST] <fin-ger> __deivid__: Ok ^^ thank you for your help :) [17:34:44 CEST] <tezogmix> I see kepstin , it seems the effort may not be worth the implementation... most of the considerations were on older android OS tablets. [17:35:21 CEST] <kepstin> tezogmix: you'd probably be better off encoding a 720p60 rather than 1080p30 or 1080i60, to be honest. [17:35:24 CEST] <tezogmix> for now, all the earlier tips and suggestions you've all shared over the months with me have been working alright in those regards... [17:36:15 CEST] <tezogmix> 720p60 works well I know for a fact. [17:36:25 CEST] <tezogmix> Hmm, good point... [17:37:02 CEST] <kepstin> that said, if you want to try 1080i60 for some reason, adding "-vf interlace -flags ildct" should do it with the x264 encoder. Might be worthwhile to test it and see whether it looks better/worse than 720p60 on your target devices. [17:37:33 CEST] <kepstin> assuming the devices have ok deinterlacing, it'll probably look better on static or nearly static scenes, and worse on motion than 720p60 [17:38:28 CEST] <alexpigment> maybe i'm out of the loop, but I just sort of assumed that mobile chips didn't do any sort of deinterlacing (at least at the OS level) [17:38:41 CEST] <alexpigment> (again, I'm probably out of the loop) [17:38:46 CEST] <kepstin> if your target is mobile then yeah, skip the interlaced video. [17:39:14 CEST] <kepstin> if you're targetting something with tv playback it *might* be worth considering (but interlaced video is annoying to work with even then) [17:39:32 CEST] <tezogmix> so cool kepstin, thanks for the suggested options to try and test... with -vf interlase + vf scale function on the latter to 720p... [17:40:18 CEST] <tezogmix> is the -vf interlace a markedly time intensive process that I should be expecting? [17:40:22 CEST] <alexpigment> not to hijack, but I've always done both ilme and ildct flags. is there no reason to specify -flags ilme anymore? [17:41:13 CEST] <alexpigment> -vf interlace does slow the process down [17:41:17 CEST] <tezogmix> i'll have to check the tegra 3 nividia details alexpigment , i know it can play some 1080p60 but it really depends on the source [17:41:40 CEST] <alexpigment> tezogmix: i presume you mean 1080i60, right? [17:42:27 CEST] <kepstin> alexpigment: the x264 encoder driver checks the ildct flag (and only that flag) to determine whether to tell the x264 encoder to do interlaced encoding. [17:43:06 CEST] <alexpigment> but does the motion estimation benefit from ilme? [17:43:36 CEST] <DHE> doesn't matter. there's only one setting that matters and kepstin already explained that [17:44:02 CEST] <alexpigment> ok, well I guess I can stop specifying that from now on [17:44:14 CEST] <tezogmix> no alexpigment, i haven't ever looked into 1080i60 point... [17:44:23 CEST] <kepstin> alexpigment: the flag name is actually meaningless, it's just turned into "please do interlaced encoding however you feel like" to the x264 encoder. [17:44:41 CEST] <alexpigment> kepstin: ah, thanks for the clarification [17:44:49 CEST] <tezogmix> the tegra 3 nvidia definitely can't handle 2160/4k [17:45:00 CEST] <tezogmix> and so i've had to vf scale those [17:45:31 CEST] <kepstin> for mobile devices that aren't capable of decoding 1080p60, the screen is probably small enough that people wouldn't notice a 720p downscale anyways. [17:45:34 CEST] <tezogmix> i'm not sure of the newer android processors and gpu's... [17:46:06 CEST] Action: kepstin finds it ridiculous that his phone can take 4k video, but only has a 720p screen ;) [17:46:41 CEST] <alexpigment> kepstin: would you trade battery life for being able to view the full number of pixels on such a small device? [17:46:54 CEST] <tezogmix> hehe, yeah... the tablets from 7-10" do vary on how noticeable it could be... but all goes to how the source/bitrate is... [17:47:02 CEST] <alexpigment> kepstin: if i had to take a side here, i'd go with 720p screen every time [17:47:20 CEST] <tezogmix> why's that alexpigment ? [17:47:31 CEST] <alexpigment> tezogmix: i don't like charging things every day [17:47:38 CEST] <tezogmix> oh right, [17:48:06 CEST] <alexpigment> i surely couldn't see anything close to 4k at a normal distance from my phone [17:48:13 CEST] <kepstin> alexpigment: heh, yeah, even the 720p screen is still >300ppi on my 4.6" phone, which is plenty high enough. [17:48:25 CEST] <tezogmix> i was specifically about non-mobile (i.e. tablets with 7-10" screens) [17:48:56 CEST] <tezogmix> on mobile of 4-6", I can't tell a difference... [17:49:50 CEST] <tezogmix> unfortunately, there aren't too many higher end android specs on tablets nowadays and i don't think i'd ever spend more than $300-400 on one... [17:49:51 CEST] <alexpigment> yeah, i was really just responding to kepstin's (presumably not that serious) comment [17:50:09 CEST] <tezogmix> ah it's ok :) [17:50:30 CEST] <alexpigment> but i also don't get the point of tablets at all, so I'm going to just play the "old man" card [17:50:34 CEST] <kepstin> on a 7" device with a 1080p screen (the original nexus 7 only had 1280x800...) you'd probably only notice a 720p encode if the video contains a lot of text overlays, or if you had a magnifying glass [17:52:20 CEST] <kepstin> dropping the framerate to 30fps would certainly be more noticable than reducing the video resolution. [17:52:47 CEST] <alexpigment> kepstin: yes, 100%. which is why i hate streaming video compared to broadcast TV [17:53:03 CEST] <alexpigment> i'd like to highlight your comment in gold and show it to major companies [17:53:07 CEST] <tezogmix> ah yes... the nexus line was great, sad that they stopped... the nvidia shield k1 or something to that model was a notable successor.... not sure about the samsung lines but they're much more costly... my interest was for standalone/offline portable playback via USB-otg + external hdd's in a tablet form and there are a few good android media apps which do the job. [17:55:44 CEST] <tezogmix> what would you like to emphasize to those companies alexpigment ? [17:56:09 CEST] <alexpigment> tezogmix: that dropping the framerate to 30fps is very noticeable [17:56:27 CEST] <alexpigment> from a few feet away, you can't tell the difference between 1080p and 720p [17:56:47 CEST] <alexpigment> but you can notice the difference between 60p and 30p, or 60i and 30p from any distance [17:57:13 CEST] <tezogmix> yeah, plus the bitrates too I would imagine.... [17:57:19 CEST] <alexpigment> and yet most streaming video online, or even paid TV streaming services (DirecTV, Hulu, etc) just drop everything to 30p [17:57:30 CEST] <tezogmix> what does netflix do nowadays? [17:57:35 CEST] <tezogmix> and amazon [17:57:37 CEST] <alexpigment> the thing is, the bitrate requirements between 30p and 60p or 60i is not that big [17:57:57 CEST] <kepstin> tezogmix: most content on netflix/amazon is cinematic (or cinematically-styled), which usually means 24fps. [17:57:59 CEST] <tezogmix> I have amazon prime but rarely use their streaming.... [17:58:05 CEST] <alexpigment> netflix i think caps out at 30fps for 1080p conent i believe. at least on my apple tv [17:58:35 CEST] <alexpigment> but yeah, it's awful seeing something you *know* was recorded in 60i and watching it in 1080p24 [17:58:36 CEST] <tezogmix> i was thinking of picking up an android box (e.g. roku) [17:58:53 CEST] <tezogmix> for the netflix service... [17:59:09 CEST] <kepstin> they have some TV shows that were probably recorded (not "filmed") at 60i, and I'd expect they're mostly deinterlaced 30p for streaming :/ [17:59:10 CEST] <tezogmix> i can't stream on my main computer since i'm on vpn all the time [17:59:14 CEST] <kepstin> but I haven't checked [17:59:15 CEST] <alexpigment> tezogmix: if I knew for a fact that a modern Roku and *any* streaming service streamed in 1080p60, I would buy one today [17:59:19 CEST] <tezogmix> and netflix has blocked all that... [17:59:37 CEST] <alexpigment> kepstin: yes, I mean "filmed" in the loosest sense obviously :) [18:00:02 CEST] <tezogmix> i'm not sure alexpigment , i haven't checked the newer roku iterations , apparently there's 4k support but to what degree it is, don't know offhand. [18:00:04 CEST] <kepstin> yeah, most shows that are "filmed" are probably native 24fps. [18:00:30 CEST] <tezogmix> has anyone had any good experience with the netflix 4k/uhd content? [18:00:33 CEST] <alexpigment> yeah, I just don't watch many dramas or anything. most things I watch are definitely recorded in 60i [18:01:04 CEST] <alexpigment> tezogmix: i haven't tried it [18:01:59 CEST] <kepstin> I'm kinda sad that so much content is still recorded at 1080i60 rather than progressive, if only because of using older/cheaper equipment. [18:02:13 CEST] <alexpigment> kepstin: well i think you can blame atsc for that [18:02:18 CEST] <alexpigment> or broadcast standards in general [18:02:49 CEST] <alexpigment> it's easier to justify keeping old equipment when you know that it's going to be broadcast in the same format you're shooting in [18:03:13 CEST] <alexpigment> if the companies had to deinterlace everything though, they'd probably find the budget for upgrading :) [18:03:58 CEST] <alexpigment> but still, 1080i = 1080p for static parts of a frame [18:04:12 CEST] <alexpigment> i certainly can't tell the difference between the two from my couch [18:04:38 CEST] <alexpigment> (or probably from my monitor, for that matter) [18:13:12 CEST] <rsilvapt> Hi!, I'm using FFmpeg on Debian 8 to stream an online radio with a single image as a video to Facebook. However, after some hours of work, FFmpeg just stops working. Here is the command: ffmpeg -loop 1 -i live.jpg -i http://server.example.com -r 1 -acodec aac -strict experimental -b:a 128k -b:v 256k -minrate 128k -maxrate 512k -bufsize 768k -f flv -metadata:s:a:0 title="Here is the title" 'rtmp://rtmp-api.facebook.com:80/rtmp/xxxxxxxxxx [18:13:12 CEST] <rsilvapt> xxxxxxxxxxxxxxxxxxxxxxx' [18:14:31 CEST] <BtbN> define "a couple hours" [18:15:31 CEST] <rsilvapt> after ~ 24hours [18:15:55 CEST] <BtbN> probably some timestamp overflowing. But 24h seems a bit low for that. [18:16:01 CEST] <BtbN> Just restart it every 12h or so [18:16:30 CEST] <BtbN> also, if you still need experimental for aac, you are in bad need for an update. [18:18:33 CEST] <rsilvapt> ok... thank you. I'll do the update right now [19:16:00 CEST] <tezogmix> have a good rest of your day/evening all. [19:49:42 CEST] <alexpigment> I really wish NVENC and QSV had the ability to use a quality factor *and* a maxrate [19:50:07 CEST] <alexpigment> :( [19:51:16 CEST] <alexpigment> You really just have to choose to a) waste bits, b) have an unpredictable bitrate [19:54:50 CEST] <kepstin> well, if you're using a hardware encoder, you've already chosen to waste bits; I guess it's just whether you want to waste more :) [19:56:29 CEST] <kepstin> but yeah, that sort of quality factor + maxrate kind of thing would probably make their rate control more complicated & harder to implement (i.e. bigger) on silicon [19:59:19 CEST] <DHE> wish there was a good offload option for h264 or hevc. nvenc and qsv have the above problems. x264 opencl is minimal benefit at the risk of actually harming performance sometimes... [20:03:15 CEST] <kepstin> i don't even think any of the hw encoders actually support a constant quality mode at all, it's just static qp or something like that? [20:03:51 CEST] <BtbN> nvenc supposedly has it [20:03:59 CEST] <BtbN> but I don't understand it, and nvidia didn't bother to explain [20:04:39 CEST] <BtbN> nvenc has cqp and targetQuality [20:04:47 CEST] <BtbN> no idea when targerQuality has any meaning [20:08:15 CEST] <BtbN> also, rc_max_rate is universally passed to nvenc [20:08:17 CEST] <BtbN> in all rc modes [20:08:28 CEST] <BtbN> How much it cares about it is up to itself [20:08:37 CEST] <kittyfoots> qq -- is there a way of making ffprobe (with -show_frames) show video sample timestamps and stuff even though it isnt able to decode them (I have a ts segment that is missing sps/pps but I want to see what the video timestamps look like) [20:08:44 CEST] <BtbN> I'd assume you can do vbr with a maxrate and a targetQuality [20:10:46 CEST] <kittyfoots> oh i could use show_packets instead maybe [20:55:49 CEST] <alexpigment> kepstin: yeah, nvenc and qsv both have constant quality mode. the numbers don't correlate well to CRF, but they're there technically. -qp 24 works well for nvidia, ~19 or so is good for intel, but there is some occasionally macroblocking that i haven't figured out a way to dial out [20:56:05 CEST] <BtbN> nothing correlates well to crf [20:56:16 CEST] <BtbN> crf is x264 implementation specific, it's nothing standard [20:56:39 CEST] <kepstin> crf is just (or at least originally was) simply part of how x264 calculated complexity when doing 2-pass encodes. [20:57:28 CEST] <alexpigment> yeah, I'm just saying that the numbers don't really line up for a given level of quality, regardless of the efficiency that is inherent with CRF [20:57:33 CEST] <alexpigment> i realize they're not the same thing at all [20:57:50 CEST] <alexpigment> so i had to do a bunch of quality tests on my own to find good numbers [20:57:52 CEST] <BtbN> fell free to play around with target quality and maxrate in vbr mode [20:57:55 CEST] <user890104> hello, i am trying to use RTSP input buffering, but there's an error message saying that my build does not support pthreads (windows 7, zeranoe shared build), are there pthreads-enabled binaries available? [20:58:11 CEST] <BtbN> pthreads is a linux/unix api [20:58:16 CEST] <alexpigment> BtbN: I already have. I didn't find that the maxrate was respected at all [20:58:27 CEST] <BtbN> target quality, not constant quality [20:59:35 CEST] <user890104> BtbN: older builds seem to have it supported: https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=2&t=4837 [20:59:37 CEST] <alexpigment> -q:v? [21:00:05 CEST] <alexpigment> i've been using qp, but maybe that's a different thing altogether [21:00:35 CEST] <BtbN> ask nvidia what exactly it is [21:00:44 CEST] <BtbN> they sent a patch to set it, but I never figured out what it is and how it works [21:01:30 CEST] <alexpigment> on the phone with Jensen Huang right now... ;) [21:01:39 CEST] <furq> zeranoe builds used to have --disable-w32threads (i.e. pthreads) [21:01:48 CEST] <furq> i guess he changed it a while back though [21:02:31 CEST] <user890104> furq: yes, that's exactly the problem [21:02:45 CEST] <user890104> it broke buffered rtsp input [21:02:50 CEST] <furq> you'll probably have to build yourself [21:03:19 CEST] <user890104> is there an automated way to fetch all dependecies? [21:03:41 CEST] <user890104> or this is for #ffmpeg-devel? [21:03:42 CEST] <nicolas17> on Windows? have fun... [21:05:35 CEST] <user890104> well, mingw64 with pacman feels like Arch a bit, so if there's a linux script, it should work with minimal (or none) modifications [21:10:18 CEST] <BtbN> zeranoe jumps through quite some hoops to build all that stuff statically [21:10:33 CEST] <alexpigment> BtbN: yeah, it's really hard to test thing stuff sometimes because each encoder takes non-private parameters differently. for example, I just tried -cq with nvenc and wasn't getting expected results. as it turns out, when you don't set a bitrate, it assumes 2Mbps (at least in my case). it's pretty annoying when this stuff isn't hooked up. if I was a developer, I'd take some of my freetime and whip this thing into shape so that it works more like [21:10:33 CEST] <alexpigment> libx264 where possible [21:10:43 CEST] <alexpigment> *test things [21:11:13 CEST] <BtbN> if you set -cq with nvenc without further parameters, it will go into constqp mode and not care about any bitrates [21:12:18 CEST] <alexpigment> i was doing cq + maxrate + bufsize [21:12:35 CEST] <BtbN> set an rc mode explicitly if you are doing that kinda mixes [21:12:41 CEST] <BtbN> otherwise results can be unexpected [21:13:11 CEST] <alexpigment> well, cq by itself still is assuming 2mbps [21:13:33 CEST] <BtbN> constant quality does not assume anything like that [21:13:39 CEST] <alexpigment> cpb: bitrate max/min/avg: 0/0/2000000 buffer size: 4000000 vbv_delay: -1 [21:13:42 CEST] <BtbN> it outputs a constant quality, not caring about the bitrate [21:14:01 CEST] <BtbN> that's ffmpeg.c outputting some defaults. nvenc does not care [21:14:04 CEST] <alexpigment> BtbN: I don't know what to tell you. the proof is right there [21:14:43 CEST] <alexpigment> ok, so why does the same not apply for libx264? [21:14:53 CEST] <BtbN> The same what? [21:15:04 CEST] <BtbN> x264 in constant quality mode also does not care about bitrate [21:15:26 CEST] <alexpigment> I'm not sure what I'm saying that is confusing here [21:15:38 CEST] <BtbN> almost all of it right now. [21:15:56 CEST] <BtbN> if you put an encoder into pure constant quality mode, that's what you'll get. [21:16:05 CEST] <BtbN> no matter what is written in the in that case unused bitrate fields [21:16:09 CEST] <alexpigment> what is an equivalent pure constant quality mode for libx264? [21:16:16 CEST] <BtbN> the constant quality mode? [21:16:40 CEST] <kepstin> alexpigment: -crf mode is roughly constant perceptual quality, -qp is also a "constant quality" mode [21:16:40 CEST] <alexpigment> yes, i'm going to follow your directions, and then we'll see what libx264 does compared to nvenc [21:16:45 CEST] <furq> constant quality is crf [21:16:47 CEST] <kepstin> so there's two of them I guess [21:16:52 CEST] <furq> constqp is constant quantiser [21:17:04 CEST] <furq> which is sort of constant quality but not really [21:17:29 CEST] <alexpigment> ok, so crf and cq, when set alone, do not assume any bitrates [21:17:40 CEST] <alexpigment> the bitrates show as '0' in the command line [21:17:56 CEST] <alexpigment> nvenc, on the other hand, shows a bitrate of 2Mbps when setting a cq and nothing else [21:18:05 CEST] <BtbN> nvenc does not show anything [21:18:08 CEST] <furq> 20:14:01 ( BtbN) that's ffmpeg.c outputting some defaults. nvenc does not care [21:18:16 CEST] <nicolas17> sounds like a UI bug then [21:18:21 CEST] <furq> probably [21:18:34 CEST] <BtbN> ffmpeg.c has no clue about rc modes. It just outputs some pre defined fields [21:18:47 CEST] <alexpigment> nicolas17: it's not a UI thing. setting the bitrate to zero allows it to operate as expected [21:19:03 CEST] <BtbN> again: _WHAT_ bitrate? [21:19:08 CEST] <BtbN> There is like 5 diffrent ones you can set [21:19:15 CEST] <alexpigment> target [21:19:26 CEST] <alexpigment> "average" [21:19:38 CEST] <alexpigment> i'll repeat what I pasted above: "cpb: bitrate max/min/avg: 0/0/2000000 buffer size: 4000000 vbv_delay: -1" [21:20:06 CEST] <nicolas17> so if you set avg to 0 instead of 2M it "works as expected"? [21:20:12 CEST] <BtbN> That line has no meaning for nvenc at all. [21:20:17 CEST] <furq> what does "operate as expected" mean [21:20:20 CEST] <kepstin> alexpigment: all that says is that the encoder is setting some metadata fields to those values, it doesn't say anything about the actual video [21:20:23 CEST] <BtbN> so avctx->bit_rate? Or avctx->rc_max_rate? [21:20:52 CEST] <alexpigment> BtbN: -b:v is the parameter I'm talking about [21:21:43 CEST] <BtbN> that's ignored in -rc constqp mode [21:21:51 CEST] <alexpigment> OK, I'll try to explain this again, because I feel like this is not getting through at all [21:21:54 CEST] <kepstin> the ffmpeg code puts the avctx->bit_rate value into the cpb info regardless of whether the nvenc settings would use the bitrate value or not. [21:22:03 CEST] <kepstin> so that log message is irrelevant [21:22:22 CEST] <alexpigment> -c:v h264_nvenc -cq 10 produces a file with a target bitrate of 2Mbps [21:22:42 CEST] <alexpigment> -c:v h264_nvenc -cq 10 -b:v 0 produces a file without a target bitrate (and is much larger) [21:22:43 CEST] <BtbN> -cq is not constqp. -qp is [21:22:46 CEST] <BtbN> -cq is a whole other story [21:23:18 CEST] <BtbN> The one that I don't fully understand. It's basically a target quality for vbr mode. [21:23:20 CEST] <alexpigment> BtbN: the original message from me was "I just tried -cq with nvenc and wasn't getting expected results. as it turns out, when you don't set a bitrate, it assumes 2Mbps (at least in my case). it's pretty annoying when this stuff isn't hooked up" [21:23:40 CEST] <BtbN> I think 2mbps is the default libavcodec sets for -b:v [21:23:41 CEST] <alexpigment> I'm sorry you didn't catch those details, but I believe it was clear the first time [21:23:53 CEST] <alexpigment> BtbN: then why doesn't it apply to libx264? [21:24:03 CEST] <furq> x264 doesn't set a default bitrate [21:24:08 CEST] <furq> the default is -crf 23 [21:24:31 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/options_table.h#L42 [21:24:34 CEST] <BtbN> that's where it comes from [21:24:42 CEST] <BtbN> x264 default, if no parameter is given, is crf [21:24:48 CEST] <furq> yeah [21:24:58 CEST] <furq> it's usually a default bitrate for most codecs [21:25:01 CEST] <furq> which is generally far too low [21:25:14 CEST] <alexpigment> OK, so the problem here is that target bitrate mode is the default with NVENC [21:25:24 CEST] <alexpigment> and it uses the generic target bitrate from libavcodec [21:25:26 CEST] <BtbN> I don't see a problem here at all [21:25:39 CEST] <furq> the problem is that you misread cq as qp [21:25:42 CEST] <BtbN> If you use default parameters, you get defaults. They are not good quality, but they are default. [21:25:54 CEST] <alexpigment> BtbN: if you're trying to use these emerging technologies, it makes it hard to go from libx264 to nvenc without reading the source code [21:26:01 CEST] <furq> or maybe not [21:26:03 CEST] <BtbN> If you use -cq, it will be in vbr mode, which is default. And indeed care about the value of -b [21:26:17 CEST] <BtbN> nvenc and x264 are highly diffrent [21:26:28 CEST] <BtbN> there is already a lot of magic in place to make them similar. But they just aren't. [21:26:42 CEST] <BtbN> crf simply does not exist for nvenc, and it can't be emulated. [21:27:26 CEST] <alexpigment> well, i'm only trying cq right now because you mentioned that maxrates will work when used with target quality, and cq is noted as the target quality [21:27:46 CEST] <BtbN> They might. I have no idea what actually works. I never got consistent results with -cq [21:27:49 CEST] <alexpigment> i've been using -q:v , which doesn't work with maxrates [21:28:15 CEST] <BtbN> you mean -cq? [21:28:22 CEST] <BtbN> sorry, qp... [21:28:46 CEST] <alexpigment> yes, -qp (my bad) [21:28:55 CEST] <BtbN> I think -q is some weird thing ffmpeg.c maps to -global_qualiy, with some weird factor applied. [21:29:06 CEST] <BtbN> mpeg2 qscale stuff [21:29:17 CEST] <The_8472> I'm trying to achieve an equivalent to ffmpeg's out%d.png output format through libavcodec. I've gotten to the point where it writes some empty png files but it doesn't generate numbered file names. So I think I'm not configuring up the output format properly. Is the multi file png output actually treated as a video codec or do I have to deal with AVPicture? [21:29:37 CEST] <alexpigment> BtbN: one of the parameters mentions that global_quality is deprecated [21:29:54 CEST] <BtbN> yes, in favor of qp [21:29:58 CEST] <alexpigment> -q:v is mapped to global_quality. it says to use qp instead [21:30:00 CEST] <alexpigment> right [21:30:11 CEST] <furq> The_8472: out%d.png is the image2 muxer in libavformat [21:30:11 CEST] <alexpigment> i switched from global_quality to qp when that warning started appearing [21:30:36 CEST] <BtbN> global_quality was never intended for that purpose, I'm not sure why I used it in the first place [21:30:48 CEST] <alexpigment> global_quality worked fine, to be honest [21:31:10 CEST] <alexpigment> I believe it's 'global' because you're not setting the q for i, p, and b separately [21:31:20 CEST] <alexpigment> which you can do with other encoders [21:31:28 CEST] <BtbN> For cq you'd need something like -rc vbr_hq -cq 20 -b avg_bitrate -maxrate max_bitrate [21:31:56 CEST] <BtbN> you totally can set the i/p/b quants independently [21:32:20 CEST] <alexpigment> yeah, I haven't tested it with ffmpeg, just with other encoders [21:32:34 CEST] <alexpigment> I know there's an "init" for each, but I don't know if that's the same thing [21:32:38 CEST] <The_8472> furq, and it takes a video stream? [21:33:03 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/nvenc.c#L562 [21:33:15 CEST] <alexpigment> I'm also not looking forward to researching the results of setting I/P/B with separate q values. sounds daunting [21:33:22 CEST] <BtbN> the -qp initially sets all 3 of them. Then you can override the b and i ones if they are set [21:33:37 CEST] <kepstin> The_8472: it should take a series of AVPacket as produced by the png encoder. [21:34:04 CEST] <alexpigment> BtbN, well it's good to know that you can override just one [21:34:27 CEST] <alexpigment> I just don't know that I have the knowledge to know when a I/P/B is being starved [21:34:31 CEST] <BtbN> i_qfactor/i_qoffset and b_qfactor/b_qoffset are the parameters ffmpeg.c uses I think [21:34:52 CEST] <BtbN> Which are all set to non-zero by default [21:34:55 CEST] <alexpigment> ok, so those aren't private options [21:34:59 CEST] <BtbN> so if not specificey, they are not all the same [21:35:21 CEST] <The_8472> kepstin, thx. so I have to initialize a) the muxer b) the encoder c) some converter to adjust the pix format from the source, right? [21:36:20 CEST] <alexpigment> BtbN: is there an obvious way to tell when you need to adjust the quality of an I P or B frame separately from the others? [21:36:37 CEST] <kepstin> The_8472: more or less, yeah. Note that the 'some converter' is also provided by ffmpeg, in libswscale. [21:36:42 CEST] <BtbN> I don't think you ever really need to. [21:36:57 CEST] <alexpigment> Good to know [21:37:12 CEST] <BtbN> by default it favors I frames a bit [21:37:22 CEST] <BtbN> so you don't get too bad of a quality hit from them [21:37:32 CEST] <BtbN> and dis-favors B frames [21:37:48 CEST] <alexpigment> Btbn - yeah Staxrip defaults to I/P/B of 20/23/25 [21:38:30 CEST] <kepstin> the only time you're likely to notice an issue is when vbv controls cause i frames to become bitrate starved, and you get quality pulsing as the b-frames look better than i frames, but that's not really directly solvable with this mechanism [21:38:38 CEST] <alexpigment> Their implementation of NVENC seems very thorough in general [21:39:26 CEST] <alexpigment> kepstin: yeah, I've had to do that with MPEG-2 as I recall - good to have a refresher on what to do with the quality pulsing [21:41:01 CEST] <nicolas17> last time I wanted to do decent mpeg2 I used tmpgenc :/ [21:42:08 CEST] <nicolas17> maybe ffmpeg's rate control improved since then [21:42:30 CEST] <alexpigment> nicolas17: nope [21:42:33 CEST] <alexpigment> :( [21:42:59 CEST] <The_8472> kepstin, thx [21:43:08 CEST] <alexpigment> some source material is fine. but some source material makes it clearly obvious that mpeg2video is bested by pretty much any other encoder [21:45:06 CEST] <BtbN> mpeg2 is a diffrent story, as non-I frames don't recovery quality, but slowly degrade [21:45:22 CEST] <BtbN> so you want I frames to be super crisp [21:45:41 CEST] <BtbN> with h264 you can go without I frames forever [21:47:02 CEST] <alexpigment> BtbN: as long as seeking isn't important, yes :) [21:47:26 CEST] <alexpigment> usually if you're working with MPEG-2, you're doing something that requires more I frames for compatibility in my experience [21:49:01 CEST] <nicolas17> yeah I was making DVD-Video :P [21:50:50 CEST] <notdaniel> rebuilt our video platform in-house using ffmpeg+nvenc for encoding uploads and getting h264 output how we wanted has been a bit tricky without crf as we were used to [21:56:26 CEST] <alexpigment> notdaniel: yep, I'm dealing with that sort of stuff at the moment. it sucks :( I'm also doing Intel QSV as well, which is actually a lot worse than NVENC [21:56:43 CEST] <alexpigment> notdaniel: do you have any huge bitrate or file size limitations you have to work within? [21:56:56 CEST] <alexpigment> huge = major [21:59:50 CEST] <notdaniel> alexpigment, not explicitly, but we're a public video platform and users expect to be able to upload videos and play them back in decent quality without buffering much [22:00:09 CEST] <alexpigment> yeah, understandable [22:00:51 CEST] <alexpigment> I haven't tackled streaming-friendly stuff yet, but since BtbN let me know that -cq and -maxrate/bufsize will work together, it gives me hope [22:01:16 CEST] <BtbN> for streaming you want a cbr anyway [22:01:42 CEST] <alexpigment> BtbN: actually, that's why I like libx264's crf+maxrate mode [22:01:42 CEST] <notdaniel> yeah it's all being served up via DASH in the end [22:02:05 CEST] <alexpigment> but this is not HLS or Dash or anything - just basic HTML5 compatibility [22:02:05 CEST] <BtbN> no, you want strict cbr [22:02:07 CEST] <BtbN> not max-rate [22:02:12 CEST] <BtbN> you also don't want it to go lower [22:02:32 CEST] <notdaniel> we're using it 100% now on tens of thousands of videos and it seems to be okay, it was just a learning curve to understand their implementation of some of these flags and not behaving as originally expected [22:02:39 CEST] <alexpigment> BtbN: for my purposes, crf+maxrate is superior [22:02:56 CEST] <BtbN> So you are not using TCP? [22:03:17 CEST] <alexpigment> just a video that's being served up (not live) through a basic HTML5 player like videojs [22:03:37 CEST] <kepstin> notdaniel: if you're using nvenc just for speed, it probably makes sense to do a second encode with x264 later and replace the nvenc encode with it :/ [22:03:44 CEST] <kepstin> (unless it's live stuff) [22:04:17 CEST] <notdaniel> kepstin, weve gotten nvenc to look okay, and it wasnt for speed from a user standpoint so much as for rented cpu time [22:04:22 CEST] <BtbN> that's not what I'd call streaming. [22:04:36 CEST] <notdaniel> so making the x264 later defeats the purpose of less cpu time [22:05:07 CEST] <alexpigment> BtbN: I just meant web playback with bitrates that don't cause buffering [22:05:22 CEST] <BtbN> well, that depends on the users internet speed [22:05:30 CEST] <notdaniel> all bitrates cause buffering for the right client [22:05:41 CEST] <alexpigment> yes, but there are expected tolerances [22:05:52 CEST] <alexpigment> if you have a 1080p video, you don't want it to hit 30Mbps [22:05:54 CEST] <kepstin> notdaniel: huh, so you're limited more by expenses on cpu time than expenses on bandwidth? kind of odd, but ok. [22:06:01 CEST] <alexpigment> but 5-8Mbps is fine for most users [22:06:29 CEST] <alexpigment> but if your video is mostly stills, you don't want to waste storage on a constant bit rate [22:06:43 CEST] <BtbN> cbr is for streaming [22:06:45 CEST] <BtbN> not flat files [22:07:06 CEST] <notdaniel> that said, for x264 we set maxrate, crf, cq [22:07:20 CEST] <alexpigment> BtbN: i agree with your statement. apologies for using "streaming" in a misleading way [22:07:36 CEST] <notdaniel> in the end theyre fragmented with segments served up via dash [22:07:41 CEST] <BtbN> cbr for streaming is because TCP is bad with sudden bitrate bursts [22:07:44 CEST] <BtbN> so you don't want it to fall [22:07:55 CEST] <BtbN> if you have a flat file, you just download the whole thing as fast as you can anyway [22:08:14 CEST] <alexpigment> yes, i agree with this [22:08:41 CEST] <alexpigment> I used streaming in the "YouTube" sense earlier and I think that brought on some unnecessary confusion [22:08:45 CEST] <kepstin> with segmented video the players usually end up buffering far enough ahead anyways that tcp issues with varying rates have less effect. [22:08:57 CEST] <kepstin> well, sometimes. [22:09:18 CEST] <nicolas17> with segmented video you usually have multiple qualities [22:09:45 CEST] <notdaniel> oh, using dash/hls comes with its own new hilarious issues, but obviously in general it's a much better experience [22:09:46 CEST] <nicolas17> if the client decides it can't keep up, it picks a lower quality for the next segment it downloads [22:10:18 CEST] <kepstin> as an aside, whoever set up the current encoders at crunchyroll didn't align the segments for different qualities, so the video jumps back or skips forwards a bit whenever the player does a quality switch [22:10:22 CEST] <kepstin> yey :/ [22:10:25 CEST] <notdaniel> we're probably shortly removing the fallback to flat mp4s entirely [22:10:27 CEST] <nicolas17> kepstin: eww [22:10:46 CEST] <furq> good job animes is bad [22:11:08 CEST] <notdaniel> especially now that you can use the same fragmented media for both hls and dash, and that you dont need to segment the files [22:11:10 CEST] <kepstin> they used to get that right at least, seems like they broke it at some point :( [22:12:05 CEST] <nicolas17> notdaniel: "now"? what changed to allow reusing the segments? [22:12:09 CEST] <nicolas17> (I know almost nothing about dash) [22:12:28 CEST] <nicolas17> I mean why was it not possible before? [22:12:30 CEST] <notdaniel> nicolas17, hls changed to support it [22:12:36 CEST] <nicolas17> oh, huh [22:13:05 CEST] <notdaniel> dash and hls previously had very different requirements, both in terms of the format as well as how they were segmented [22:13:46 CEST] <notdaniel> both of those changed, so you can serve up one mp4, properly fragmented but not split, and serve up bitrange segments to both [22:13:54 CEST] <nicolas17> "Unlike, HLS, HDS and Smooth Streaming, DASH is codec-agnostic" ughh why are there so many options, I hadn't even heard of HDS [22:13:56 CEST] <notdaniel> you just generate 2 manifests [22:14:42 CEST] <notdaniel> in practice, dash is the way to go, with hls for people on specific older apple devices [22:14:51 CEST] <notdaniel> and again it doesnt matter anymore since they are using the same media [22:15:11 CEST] <nicolas17> does apple support dash natively now? [22:15:15 CEST] <notdaniel> you dont have to think about it or worry about it. smooth streaming and other solutions though, whatever [22:15:45 CEST] <nicolas17> or would you need your app (or website with HTML5 MSE) to handle DASH? [22:16:00 CEST] <notdaniel> no dash on ios period [22:16:30 CEST] <nicolas17> oh, no MSE on ios? :/ [22:17:00 CEST] <notdaniel> you just need MSE on the client (which is almost everyone) and the server needs to be able to serve a specific byterange of one file [22:18:42 CEST] <notdaniel> i very very rarely see the fallbacks kicking in. dash can come with its own optimization hilarity but it's mostly well-supported [22:35:09 CEST] <ultrav1olet> Hi, ffmpeg doesn't want to pass tune=film option to libx265 - in the log it says [libx265 @ 0xxxxxxxx] Unknown option: tune. [22:35:42 CEST] <ultrav1olet> -tune film is ever worse - an instant error: "Unrecognized option 'tune=grain' Error splitting the argument list: Option not found" [22:36:03 CEST] <ultrav1olet> Is this a known bug? Should I file a bug report? [22:39:18 CEST] <thebombzen> ultrav1olet: afaik "-tune film" is not an x265 option [22:39:34 CEST] <thebombzen> when I try to use that I get an error telling me this: Possible tunes: psnr ssim grain zerolatency fastdecode [22:41:47 CEST] <ultrav1olet> thebombzen: the documentation disagrees with you: http://x265.readthedocs.io/en/default/presets.html [22:42:06 CEST] <thebombzen> that's x265's binary [22:43:28 CEST] <thebombzen> ultrav1olet: try this, what do you get? x265 --help | grep -A1 -e --tune [22:43:46 CEST] <ultrav1olet> thebombzen: strings libx265.a | grep grain => grain/rc-grain/no-rc-grain [22:44:01 CEST] <thebombzen> no need to strings the static library [22:44:07 CEST] <thebombzen> try this: x265 --help | grep -A1 -e --tune [22:44:25 CEST] <ultrav1olet> I didn't build the binary - I only have two libraries installed [22:44:33 CEST] <thebombzen> ultrav1olet: also the docs do not disagree with me [22:44:36 CEST] <thebombzen> did you read them? [22:45:06 CEST] <ultrav1olet> it's called grain, not film - right [22:45:11 CEST] <ultrav1olet> but "tune" is there [22:45:27 CEST] <thebombzen> when did I say it wasn't [22:45:33 CEST] <thebombzen> http://0x0.st/UDV.png [22:46:02 CEST] <thebombzen> I said "-tune film" is not an option [22:46:13 CEST] <thebombzen> which it isn't [22:46:17 CEST] <ultrav1olet> I must be stupid today [22:46:26 CEST] <thebombzen> lol everyone has one of those days [22:46:29 CEST] <thebombzen> but yea try -tune grain [22:46:44 CEST] <thebombzen> it's the only psy tuning it appears that's useful. psnr and ssim are just for the objective tests. [22:47:35 CEST] <ultrav1olet> -c:v libx265 -preset veryslow -x265-params crf=18:no-sao=1:tune=grain 265.mkv results in "[libx265 @ 0xxxxxxxx] Unknown option: tune." [22:48:10 CEST] <thebombzen> btw, you can use -tune grain -crf 18 as x265 options [22:48:18 CEST] <thebombzen> er, as ffmpeg options [22:48:19 CEST] <ultrav1olet> also, the ".so" library doesn't contain "grain. So, something is not right with how libx265 gets built [22:48:43 CEST] <thebombzen> not necessarily, "strings" is not perfect [22:49:00 CEST] <thebombzen> try using -crf 18 -tune grain -x265-params no-sao=1 [22:49:15 CEST] <thebombzen> see if that does what you need it to [22:50:36 CEST] <ultrav1olet> it seems like you're insisting on running x265 directly while I cannot 'cause I prefer to use x265 as ffmpeg's library [22:51:22 CEST] <ultrav1olet> actually it worked [22:51:25 CEST] <ultrav1olet> OMG [22:51:34 CEST] <ultrav1olet> the order of arguments matter. FML [22:52:44 CEST] <ultrav1olet> this works: ffmpeg -i input.mp4 -c:a null -c:v libx265 -preset veryslow -tune grain -x265-params crf=18:no-sao=1 265.mkv [22:53:01 CEST] <ultrav1olet> this doesn't: ffmpeg -i input.mp4 -c:a null -c:v libx265 -preset veryslow -x265-params crf=18:no-sao=1 -tune grain 265.mkv [22:53:14 CEST] <nicolas17> o.o [22:53:30 CEST] <ultrav1olet> Is this an expected behaviour? ;-) [22:54:33 CEST] <thebombzen> and no I wasn't I meant don't put -tune grain inside x265-params [22:54:35 CEST] <thebombzen> but you figured it out :) [22:54:36 CEST] <nicolas17> maybe -tune sets crf or no-sao differently [22:54:54 CEST] <thebombzen> as for is this expected behavior? no. order option matters in ffmpeg for somethings but not others [22:55:11 CEST] <thebombzen> you should be able to interchange -x265-params crf=18:no-sao=1 with -tune grain [22:55:19 CEST] <thebombzen> that sounds like a bug to me [22:56:33 CEST] <ultrav1olet> -tune doesn't affect crf at all [22:57:08 CEST] <ultrav1olet> you always either set crf manually, or it's set to its default which is 28 or you use some bitrate control [22:57:10 CEST] <thebombzen> it doesn't and it shouldn't [22:57:26 CEST] <thebombzen> those options should be interchangeable, that sounds like a bug. [22:57:39 CEST] <thebombzen> also what is -c:a null? that doesn't work on my build. [22:57:46 CEST] <ultrav1olet> (dunno why 28 is default - it's faaaaaar from being transparent or even acceptable) [22:57:48 CEST] <thebombzen> what version are you using? [22:57:55 CEST] <thebombzen> of FFmpeg [22:58:04 CEST] <ultrav1olet> the one I compiled manually on Linux [22:58:13 CEST] <thebombzen> that doesn't actually answer my question [22:58:16 CEST] <ultrav1olet> 3.3.2 at the moment [22:58:26 CEST] <thebombzen> hm, how did you get -c:a null :O [22:58:28 CEST] <ultrav1olet> you need my compilation flags? [22:58:42 CEST] <ultrav1olet> I thought -c:a null equals to no audio [22:58:57 CEST] <ultrav1olet> in my case it works this way :-D [22:58:57 CEST] <thebombzen> no, it produces the "unknown encoder: null" error [22:59:03 CEST] <thebombzen> which you would know if you actually ran it [22:59:28 CEST] <ultrav1olet> I'm running it right now quite successfully [22:59:59 CEST] <ultrav1olet> and the output is quite correct - the only stream which is video [23:01:23 CEST] <thebombzen> now I'm confused, how did you do that? [23:02:42 CEST] <ultrav1olet> thebombzen: https://pastebin.com/karxm3Qq [23:04:30 CEST] <ultrav1olet> the right option is of course -an but it's kinda non-obvious [23:04:43 CEST] <kepstin> ah, your input file has no audio, so it doesn't try to initialize an audio encoder, so the "-c:a null" is ignored [23:05:11 CEST] <ultrav1olet> I'm indeed the idiot here [23:08:13 CEST] <ultrav1olet> -tune grain increases bitrate threefold. Wow. [23:10:35 CEST] <furq> yeah it'll do that [23:16:50 CEST] <asdzxc> Hey everyone. I had a quick question about md5 checksumming outputs of ffmpeg. [23:17:04 CEST] <asdzxc> I saw this ticket from 3 years ago: https://trac.ffmpeg.org/ticket/3524 [23:17:42 CEST] <asdzxc> I'm running the same ffmpeg command twice, but my 2 outputs are not the same md5. [23:18:16 CEST] <kepstin> asdzxc: as expected, not a bug. [23:18:54 CEST] <kepstin> asdzxc: there's some metadata and such in various containers that's either random or time sensitive each run; some codecs (e.g. x264 multithreaded) are non-deterministic. [23:20:27 CEST] <kepstin> there are options that cover some cases which can make things deterministic, but they're ether not recommended for general use (e.g. deterministic ogg stream ids can cause issues) or cause slowdowns (like doing single-threaded x264). [23:21:57 CEST] <kepstin> asdzxc: of course, with md5, you could probably just add some padding to the files then calculate a collision ;) [23:22:29 CEST] <kepstin> ... and I guess none of that was seen. [23:37:17 CEST] <ultrav1olet> how can I concatenate two mkv (the same video codec, the same resolution) files without reencoding so that video streams get rebuilt? [23:39:00 CEST] <ultrav1olet> right now the second part gets totally corrupted - I see some funny illumination/random noise/strange effects instead of the actual video [23:39:20 CEST] <kepstin> ultrav1olet: concat format should do it: https://www.ffmpeg.org/ffmpeg-formats.html#concat-1 [23:39:40 CEST] <kepstin> ultrav1olet: might be something in mkvtoolnix that could give you something useful, too [23:40:30 CEST] <ultrav1olet> I'm using concat indeed. It's just the output which is broken: millions of messages like [hevc @ 0xXXXXXXXXX] The cu_qp_delta -49 is outside the valid range [-26, 25] [23:41:03 CEST] <ultrav1olet> the first part of the video uses different H265 encoding parameters than the second one [23:41:12 CEST] <ultrav1olet> I'm not even sure that's allowed [23:41:18 CEST] <kepstin> ultrav1olet: that's odd... are you sure the codec parameters are compatible? e.g. don't mix 8 and 10 bit video [23:41:37 CEST] <ultrav1olet> However both parts are "x265 [info]: Main profile, Level-4 (Main tier)" [23:42:04 CEST] <ultrav1olet> absolutely - the same encoding string aside from tune=grain for the second part [23:42:44 CEST] <kepstin> I really don't know enough about hevc to say what's going on, then. [23:43:16 CEST] <kepstin> would be helpful to see the full ffmpeg output from the concat run [23:43:40 CEST] <kepstin> (and maybe the individual video encodes too, if you have that) [23:44:35 CEST] <ultrav1olet> kepstin: https://pastebin.com/j75r3qNN [23:46:22 CEST] <ultrav1olet> perhaps it's a bug in ffmpeg - I need to test some other decoder [23:51:20 CEST] <kepstin> ultrav1olet: it really looks like the files have mismatched bit depths, can you paste the output of "ffmpeg -i <filename>" from each? [23:54:08 CEST] <ultrav1olet> kepstin: https://pastebin.com/raw/yetfuZT7 [23:56:32 CEST] <ultrav1olet> maybe there's a way to use some raw intermediate container? [23:57:42 CEST] <kepstin> ultrav1olet: yeah, I'm at a bit of a loss there, then. either something going wrong with the dumuxing/parsing (I assume the files can be independently played back fine?) or there's some other not-obvious parameter or something that's incompatible [23:58:18 CEST] <ultrav1olet> yep, independently they can be played just fine [00:00:00 CEST] --- Wed Jun 28 2017

1 0

ffmpeg-devel.log.20170626
by burek 27 Jun '17

27 Jun '17

[00:00:57 CEST] <philipl> "working" is a probabilistic statement [00:05:30 CEST] <cone-547> ffmpeg 03Paul B Mahol 07master:315f51128a95: avcodec/prores_kostya: increase bits usage when alpha is used [00:05:30 CEST] <cone-547> ffmpeg 03Paul B Mahol 07master:4bd4fc56abf9: avcodec/proresenc_kostya: use frame metadata instead of avctx [01:07:29 CEST] <cone-547> ffmpeg 03Michael Niedermayer 07master:7d317d4706b4: avcodec/frame_thread_encoder: Fix AV_OPT_TYPE_STRING handling in priv_data [01:07:49 CEST] <michaelni> durandal_170, should be fixed [02:03:10 CEST] <iive> atomnuker: what asm did you use for the tests? [02:04:24 CEST] <atomnuker> nasm [02:04:40 CEST] <iive> version? [02:05:21 CEST] <atomnuker> 2.13 [02:05:30 CEST] <atomnuker> 2.13.01 [02:05:47 CEST] <iive> ok, i have the same nasm version. [02:12:40 CEST] <iive> atomnuker: btw, I do not have complete benchmarks from you. some defines were missing the the file. have you done them? [02:14:18 CEST] <iive> if you haven't, don't do them now, i'll be leaving in a moment [02:15:42 CEST] <atomnuker> no, not yet, what should I do? [02:15:46 CEST] <atomnuker> *what else [02:19:33 CEST] <iive> stall_write_forwarding, short_syy_update, [02:19:50 CEST] <iive> const_in_x64_reg_is_faster [02:20:06 CEST] <iive> and the blends... [02:30:28 CEST] <iive> see ya [03:19:40 CEST] <kierank> atomnuker: no it was fork drama at the time [03:19:44 CEST] <kierank> iirc [04:01:37 CEST] <atomnuker> ? [08:41:35 CEST] <rcombs> atomnuker: the prores stuff, presumably [09:14:00 CEST] <cone-442> ffmpeg 03Paul B Mahol 07master:915be7e13a0e: avcodec/proresenc_kostya: enable frame threading [09:56:00 CEST] <cone-442> ffmpeg 03Matthieu Bouron 07master:db5bf64b214d: lavc/x86: clear r2 higher bits in ff_sbr_sum_square [12:56:28 CEST] <TMM> good afternoon all! [13:07:50 CEST] <wm4> it's not good, it's too hot [13:14:15 CEST] <durandal_1707> michaelni: have you looked at #5405, its about ffv1? [13:30:03 CEST] <TMM> wm4, it finally cooled down here a bit, it was way too hot lately though [13:35:24 CEST] <kierank> J_Darnley: ask atomnuker here if you have questions please [15:27:48 CEST] <BBB> gh0st__: Ill probably push your patch sometime today [15:27:54 CEST] <BBB> gh0st__: unless people have review comments [15:28:10 CEST] <gh0st__> BBB:Sure [15:28:41 CEST] <BBB> next& threading? [15:29:03 CEST] <kierank> durandal_1707: holy crap you are [15:29:04 CEST] <kierank> ][';/./# [15:29:04 CEST] <kierank> ][=] [15:29:08 CEST] <kierank> shit [15:29:52 CEST] <durandal_1707> kierank: what? [15:30:13 CEST] <kierank> finally getting rid of prores dupes [15:30:38 CEST] <BBB> \o/ [15:30:40 CEST] <BBB> hurray [15:32:34 CEST] <gh0st__> BBB: Yes, I'll do one or two more avx2 versions of the directional intra predictions, by then I'll settle all my business with my university, and we can do tile threading. =) [15:32:45 CEST] <BBB> ok [15:35:42 CEST] <BBB> which one is next? I guess one of the hu/hd or vl/vr ones? [15:35:54 CEST] <BBB> hu/vl are probably easier since they only use one edge [15:36:08 CEST] <BBB> hd/vr are like ddr, they use both edges so a little more complicated [15:37:59 CEST] <gh0st__> Yeah, I'll do vl and vr they are pretty simple indeed. [15:38:50 CEST] <atomnuker> what about loopfilter avx2? [15:39:26 CEST] <gh0st__> atomnuker: I will do that too. [15:41:21 CEST] <atomnuker> BBB: do you know if youtube enable tile threaded decoding on any encodes they do? [15:41:37 CEST] <BBB> I believe it is, yes [15:41:56 CEST] <BBB> atomnuker: 10-bit will be done; 8-bit is in the planning but also very hard so cant guarantee well get to it [15:44:56 CEST] <atomnuker> odd, on a 4k video ripped from youtube I'm getting 1 row and 8 cols (s->s.h.tiling.tile_cols) [15:45:09 CEST] <atomnuker> on an 8k I'm getting 1 row and 16 cols [15:46:14 CEST] <nevcairiel> twice the width, twice the cols? :) [15:46:27 CEST] <atomnuker> yes, but 1 row? [15:51:48 CEST] <BBB> rows affect latency, not threading [15:52:03 CEST] <BBB> they have rows-mt also but apparently youtube isnt using it [15:52:16 CEST] <BBB> its a bitstream thing [15:52:22 CEST] <BBB> rows are different than cols in dependency handling [15:52:43 CEST] <BBB> so threading for cols is more independent than rows [15:55:33 CEST] <J_Darnley> atomnuker: So kierank has asked me to add sliced threading to the VC-2 encoder. Do you have any suggestions on where to start? [15:57:02 CEST] <atomnuker> J_Darnley: start with small 128x128 yuv444p samples, set -slice_width 128 and -slice_height 128 [16:01:45 CEST] <atomnuker> that way you can reorder stuff knowing quickly whether it works [16:01:53 CEST] <atomnuker> also -wavelet_depth 1 [16:02:12 CEST] <atomnuker> then add support for multiple wavelet levels [16:02:19 CEST] <atomnuker> then add support for more than 1 slice [16:03:06 CEST] <atomnuker> for now bodge the function which calculates slice sizes to output the worst case scenario [16:03:45 CEST] <J_Darnley> kierank said I should forget about rate control and just use const quant. [16:04:18 CEST] <J_Darnley> I guess bodging would have a similar effect [16:04:39 CEST] <atomnuker> if you have a constant quant you'll still need to calculate the worst case scenario [16:04:58 CEST] <atomnuker> (its one and the same, of course you need to fix the quantizer) [16:05:26 CEST] <atomnuker> and do keep in mind the worst case scenario in dirac is very very bad in terms of size [16:06:17 CEST] <atomnuker> and even the best scenario with a high quantizer will still give you a grey output and a large amount of bits spent encoding just gray [16:07:31 CEST] <cone-442> ffmpeg 03Michael Niedermayer 07master:449cdfa687f7: avcodec/ffv1: Increase the maximum number of slices to 1024 [16:07:32 CEST] <cone-442> ffmpeg 03Michael Niedermayer 07master:4147bb905346: avcodec/ffv1enc: Try to choose slice count so that slice packet sizes are within the supported size [16:07:33 CEST] <cone-442> ffmpeg 03Michael Niedermayer 07master:ea5366670e26: avcodec/jpeg2000dwt: Fix integer overflow in dwt_decode97_int() [16:07:34 CEST] <cone-442> ffmpeg 03Michael Niedermayer 07master:3c7025178064: avcodec/jpeg2000dwt: Fix integer overflows in sr_1d97_int() [16:31:04 CEST] <atomnuker> durandal_1707: which decoder do you plan on leaving? [16:32:00 CEST] <JEEB> ffmpeg Paul B Mahol master:915be7e13a0e: avcodec/proresenc_kostya: enable frame threading <- based on this the kostya one? [16:32:24 CEST] <JEEB> because I'd be surprised if he improved an encoder if he was going to drop it [16:32:27 CEST] <JEEB> &32 [16:32:38 CEST] <kierank> atomnuker: constant quant to experiment [16:32:48 CEST] <kierank> J_Darnley: no it's not slice threading [16:33:25 CEST] <atomnuker> JEEB: I said decoder, not encoder [16:33:38 CEST] <kierank> J_Darnley: it's slice-by-slice encoding [16:34:11 CEST] <BBB> durandal_1707: \o/ [16:35:40 CEST] <JEEB> atomnuker: ah right [16:35:47 CEST] <JEEB> didn't remember we had multiple *decoders* [16:36:04 CEST] <BBB> we should get rid of the gpl one [16:36:07 CEST] <BBB> this is so ridiculous [16:36:15 CEST] <BBB> arent they both the same anyway? [16:36:29 CEST] <BBB> (or maybe theyre now both lgpl; still, get rid of the one that is not in libav) [16:46:02 CEST] <JEEB> 734 [16:50:05 CEST] <durandal_1707> BBB: libav one is slightly slower [16:50:34 CEST] <BBB> then delete the other [16:50:42 CEST] <cone-442> ffmpeg 03Kyle Swanson 07master:c11ca6105e69: avcodec/g722enc: force mono channel layout [16:51:30 CEST] <durandal_1707> BBB: but the other one is less nice looking code [16:51:36 CEST] <BBB> are you plannign to address decoder duplication also? [16:51:49 CEST] <durandal_1707> will try [16:52:06 CEST] <BBB> \o/ [16:52:08 CEST] <BBB> hero [16:53:00 CEST] <atomnuker> durandal_1707: here performance > code quality, this isn't some hypercomplicated codec, its jpeg, you can always fix code if you don't like it [16:54:58 CEST] <kierank> it's an encoder [16:55:03 CEST] <kierank> surely the best quality is best [16:58:49 CEST] <atomnuker> DEcoder [16:59:04 CEST] <atomnuker> both decoders are lgpl [17:13:23 CEST] <durandal_1707> the elvis one was initially gpl for some reason [17:41:20 CEST] <BBB> hehe the sizeof_mismatch isnt doing its job in coverity [17:55:04 CEST] <ubitux> durandal_1707: feel free to update the "Collateral damage" section in doc/libav-merge.txt [17:55:13 CEST] <ubitux> (when you're done) [17:56:26 CEST] <durandal_1707> only when kierank posts dolby-e decoder [18:04:47 CEST] <durandal_1707> kierank: could you at least improve dolby-e description in wiki? [19:44:33 CEST] <cone-442> ffmpeg 03Paul B Mahol 07master:e9510dc03284: avfilter: remove usage of empty header [19:52:20 CEST] <JEEB> durandal_1707: cool stuff with utvideodec [19:52:29 CEST] <JEEB> funny how everyone forgot aboug planar RGB [19:52:50 CEST] <JEEB> even though, indeed, that is the native format [19:53:29 CEST] <BBB> did that exist when the native decoder was written? [19:53:41 CEST] <BBB> (planar rgb pix_fmt) [19:54:00 CEST] <JEEB> I don't exactly remember [19:54:10 CEST] <JEEB> I think it was circa 2011 or so [19:54:37 CEST] <JEEB> I then started poking around the encoder in 2012, and I even was a hard-headed SIMD "student" for you at one point :) [19:54:51 CEST] <BBB> oct 2011 [19:56:47 CEST] <BBB> aaaa [19:56:48 CEST] <BBB> and [19:56:53 CEST] <BBB> I added planar RGB (really!) [19:56:54 CEST] <BBB> in nov 2011 [19:56:55 CEST] <BBB> bd97b2e1ce713a4886d909f71b6f1f5403446f53 [19:57:07 CEST] <BBB> I dont even remember that [19:57:18 CEST] <JEEB> :D [19:57:20 CEST] <BBB> so yes, it wasnt around back then ;) [19:57:30 CEST] <JEEB> just like I don't remember adding high bit depth y4m into x264cli [19:57:47 CEST] <BBB> hbd y4m is a hack anyway :-p the original y4m software doesnt support it [19:57:53 CEST] <JEEB> true that [19:57:59 CEST] <JEEB> but it was simpler than adding NUT [19:58:13 CEST] <JEEB> and FFmpeg already supported it [19:58:17 CEST] <BBB> indeed [19:58:28 CEST] <BBB> wasnt that the point of y4m? to be an interop format between different tools? [19:58:38 CEST] <BBB> I thought it originated in mjpegtools but maybe Im way off [19:58:45 CEST] <JEEB> yea, it originated around there [19:59:52 CEST] <BBB> (I originate from mjpegtools also :-p) [20:00:05 CEST] <wm4> BBB is deprecated! [20:00:14 CEST] <BBB> its about time [20:00:35 CEST] <BBB> /shutdown -h now [20:04:44 CEST] <BBB> is anyone here attending VDD? [20:04:46 CEST] <BBB> err [20:04:47 CEST] <BBB> I mean [20:04:48 CEST] <BBB> demuxed [20:06:02 CEST] <Compn> what country is demuxed in ? [20:06:09 CEST] <BBB> us, san fransisco [20:06:29 CEST] <Compn> october 5th [20:07:03 CEST] <wm4> lol traveling to the US [20:07:18 CEST] <kierank> BBB: if my submission is accepted [20:08:07 CEST] <JEEB> wm4: no laptops and reset your phone before you go [20:08:15 CEST] <BBB> Im wondering if I should talk about stuff [20:08:38 CEST] <JEEB> wm4: actually this seems to be pretty solid advice https://mricon.com/i/travel-laptop-setup.html [20:08:47 CEST] <JEEB> even if not going to china [20:09:00 CEST] <Compn> bring usb drive? then just buy cheap netbook when you get to the states ? [20:09:15 CEST] <JEEB> Compn: or bring over a basic laptop with a pure install that isn't encrypted [20:09:21 CEST] <BBB> the easiest solution is to live in the US [20:09:22 CEST] <JEEB> just so you can boot it up and connect to wifi [20:09:26 CEST] <BBB> then you dont have to worry about bring stuff in [20:09:37 CEST] <JEEB> I would probably never fit into the US [20:09:46 CEST] <nevcairiel> BBB: as long as you never leave =p [20:09:49 CEST] <JEEB> I like government help and pay 40% taxes [20:10:02 CEST] <BBB> JEEB: depends on the state [20:10:29 CEST] <kierank> JEEB: yes but you don't have a space programme [20:10:33 CEST] <kierank> which is the best part of usa [20:10:45 CEST] <JEEB> yes, and I like the fact that the private enterprises are doing that now [20:10:48 CEST] <wm4> doesn't russia have a better one [20:10:49 CEST] <JEEB> I mean, not lockheed etc [20:10:53 CEST] <nevcairiel> at this state i dont even want to visit the US, never mind living there [20:11:25 CEST] <Compn> now would probably be a good time to visit [20:11:32 CEST] <Compn> as long as you arent muslim... [20:17:15 CEST] <BBB> kierank: what are you talking about again? [20:17:25 CEST] <kierank> Uncompressed video over IP [20:17:53 CEST] <kierank> and the simd & zero copy stuff around that [20:48:02 CEST] <kierank> JEEB: any idea who filler56789 is? [20:48:23 CEST] <JEEB> nope [20:49:12 CEST] <nevcairiel> i've seen the name around doom9 in places [20:59:05 CEST] <TD-Linux> nevcairiel, speaking of, do you know how I can get my posts on doom9 approved? [21:02:40 CEST] <JEEB> TD-Linux: huh, yours are still in mod queue? [21:08:50 CEST] <TD-Linux> JEEB, yes [21:09:24 CEST] <shincodex> "buffer_size", "Send/Receive buffer size (in bytes)", [21:09:31 CEST] <shincodex> but this only applies to udp [21:09:32 CEST] <shincodex> yet [21:09:39 CEST] <shincodex> the wording is lies [21:09:46 CEST] <shincodex> "buffer_size", "Underlying protocol send/receive buffer size", [21:09:56 CEST] <shincodex> the rtsp buffer_size does not control [21:10:12 CEST] <shincodex> "send_buffer_size", [21:10:13 CEST] <shincodex> for tcp [21:10:15 CEST] <shincodex> why? [21:21:22 CEST] <BBB> I dont know. do you want it to? [21:29:15 CEST] <shincodex> hmmm [21:29:34 CEST] <shincodex> better business bureau? [21:33:28 CEST] <kierank> lol [22:04:15 CEST] <BBB> still waiting for j_darnleys glorious push [22:04:17 CEST] <BBB> where is it? [22:05:58 CEST] <feliwir> hey, how do i synchronise two seperate files with libav for playback? E.g. i have a video file (vp6) and an audio file that is the audiostream for that video (mp3) [22:09:41 CEST] <shincodex> So [22:09:51 CEST] <shincodex> send_buffer_size or recv_buffer_size [22:09:58 CEST] <shincodex> are in options list but are ignored for tcp.c [22:10:05 CEST] <shincodex> does that sound right to you? [22:10:39 CEST] <shincodex> coming from RTSP [22:12:05 CEST] <BBB> feliwir: https://ffmpeg.org/faq.html#How-can-I-join-video-files_003f [22:12:17 CEST] <BBB> feliwir: and I think this probably belongs in #ffmpeg, not here [22:12:36 CEST] <BBB> shincodex: like I just said, not necessarily. if youd like it to be different, submit a patch? :) [22:12:57 CEST] <shincodex> Why is it like a giant guess with this whole framework [22:13:10 CEST] <shincodex> I really wish i was just using it wrong [22:13:31 CEST] <shincodex> sprintf(tempBuff, "%lld", tcpOptions.sendBufferSize); av_dict_set(&options, "send_buffer_size", tempBuff, 0); [22:13:35 CEST] <shincodex> int err = avformat_open_input(&formatContext, openPath.c_str(), inputFormat, &options); [22:13:38 CEST] <shincodex> its in there somewhere [22:17:38 CEST] <shincodex> oh... this really might be unfinished code [22:24:56 CEST] <feliwir> BBB, i want to do it in libav [22:24:56 CEST] <feliwir> not ffmpeg [22:25:21 CEST] <BBB> maybe ask in #libav-devel then or so? [22:26:01 CEST] <rcombs> I'm in London; anybody wanna hang out? [22:26:41 CEST] <rcombs> kierank? [22:26:57 CEST] <wm4> BBB: I think he means via the ffmpeg libraries and C API [22:27:08 CEST] <BBB> oh I see [22:27:15 CEST] <BBB> feliwir: you mean libavcodec/format etc.? [22:27:52 CEST] <kierank> rcombs: where in london [22:28:29 CEST] <kierank> If you are near the river I might end up seeing you anyhow [22:28:50 CEST] <rcombs> Holland Park Station [22:29:04 CEST] <rcombs> I'll be around until Friday [22:29:44 CEST] Action: kierank is running round the thames [22:30:14 CEST] <wm4> why are you in Britain anyway? [22:30:53 CEST] <kierank> Place to be [22:31:13 CEST] <rcombs> vacation [22:32:16 CEST] <wm4> strange choice [23:14:23 CEST] <atomnuker> iive: I'll do the tests in an hour or so, haven't forgotten [23:21:30 CEST] <iive> np [23:29:13 CEST] <BtbN> Why does the ocr filter have no way to dump out what it's recognizing? Getting out the frame metadata is hard. [23:29:24 CEST] <BtbN> I ended up just hacking file dumping into there [23:36:17 CEST] <rcombs> BtbN: because lavfi doesn't do subtitles yet [23:36:29 CEST] <BtbN> I don't want it as subtitle [23:36:36 CEST] <BtbN> I just want it as plain text [23:36:56 CEST] <BtbN> just log it for all I care, I can grep that out of the output [23:38:05 CEST] <BtbN> I just put something in that fopens a file, and writes every scanned line into a text file [23:38:21 CEST] <BtbN> it works surprisingly well [23:40:47 CEST] Action: wm4 can't wait for the trainwreck that will be subtitles [23:40:52 CEST] <wm4> it can barely do audio/video [23:41:35 CEST] <cone-442> ffmpeg 03Paul B Mahol 07master:3594788b713e: avcodec/utvideodec: decode to GBR(A)P [23:45:50 CEST] <BtbN> Well, I want it to parse a 140x60 image for a 2 or 3 digit number. It does that reliably. [00:00:00 CEST] --- Tue Jun 27 2017

1 0

ffmpeg.log.20170626
by burek 27 Jun '17

27 Jun '17

[00:38:52 CEST] <h0par> hi [00:39:15 CEST] <h0par> I'm getting error Bad audio codec 2 (Sorenson-H263). Accepted audio codecs: H264 [00:39:42 CEST] <h0par> command was ... -c:a aac [00:40:36 CEST] <furq> you might want to paste the full command there [00:40:37 CEST] <h0par> should I install/update anything or change parameters?? [00:41:11 CEST] <kerio> audio? :o [00:42:01 CEST] <h0par> https://pastebin.com/dZZqZqmX [00:42:31 CEST] <furq> add -c:v libx264 [00:42:58 CEST] <h0par> I don't have it [00:43:07 CEST] <h0par> should I recompile ffmpeg ? [00:44:19 CEST] <iive> flv1, h264 ... flash supported something else too... but i can't remember what. [00:44:22 CEST] <furq> probably [00:44:26 CEST] <furq> sorensen spark [00:44:38 CEST] <furq> and nellymoser audio iirc [00:45:00 CEST] <furq> i assume every modern streaming site will laugh in your face if you try to send those codecs though [00:45:13 CEST] <iive> isn't spark from the rang of animated gif? [00:45:15 CEST] <h0par> that's the case [00:45:21 CEST] <h0par> fb says it's bad [00:45:24 CEST] <h0par> (Sorenson-H263) [00:46:41 CEST] <furq> oh wait sorenson spark is flv1 isn't it [00:46:53 CEST] <furq> vp6 is the other one [00:47:14 CEST] <furq> but yeah that's still ffmpeg's default video codec in flv1 for some reason [00:47:29 CEST] <furq> s/flv1/flv/ [00:47:52 CEST] <furq> also idk how you even got a build of ffmpeg without libx264 [00:49:57 CEST] <iive> well, if you build it yourself, on windows... [00:50:24 CEST] <h0par> Invalid encoder type 'libx264' [00:50:39 CEST] <h0par> my bad, it was for audio, now it's fine [00:51:05 CEST] <h0par> what type of person I must be to compile it myself, on windows.. [00:51:57 CEST] <h0par> now it works, with `-c:a copy -c:v libx264` [00:52:00 CEST] <furq> kerio: just fyi i am still laughing at the idea of an italian radiohead fan [00:52:03 CEST] <h0par> thanks [02:47:59 CEST] <rk[ghost]> can i use ffmpeg to amplify an audio file? [02:51:16 CEST] <furq> !filter volume @rk[ghost] [02:51:16 CEST] <nfobot> rk[ghost]: http://ffmpeg.org/ffmpeg-filters.html#volume [03:43:51 CEST] <Wallboy> Hello, I'm trying to encode some low res content (between 320x240 and 640x480) using x264 and outputting at the same resolution. On a 4c/8t machine, I can only get ~30% CPU Usage. I'm wondering what the bottleneck is that I'm only getting this CPU usage? I've googled a bit and found out it could be because the decoder is not getting frames faster enough for the encoder? [03:45:03 CEST] <Wallboy> But if that's the case, what is the bottleneck at the decoder level then? It can't be CPU. I checked my SSD and noticed nothing over 5% usage there [03:47:29 CEST] <furq> you can benchmark the decoder with ffmpeg -i foo.mp4 -f null - [03:48:58 CEST] <Wallboy> 17500 fps [03:49:10 CEST] <Wallboy> my SD content was getting ~620 [03:50:39 CEST] <Wallboy> my command i'm using is ffmpeg -y -i input.mp4 -c:v libx264 -preset faster -crf 23 output.mp4 [03:51:08 CEST] <Wallboy> my real command is much longer with a lot of filters, but even this simple one I get the same 30% or so CPU usage [03:51:26 CEST] <furq> you're probably being bottlenecked by the filters then [03:51:43 CEST] <Wallboy> no no, i took the filters out to get that out of the equation [03:51:43 CEST] <furq> oh wait nvm i can't read [03:53:09 CEST] <Wallboy> i am using a year old or so custom build of ffmpeg... i'll try something more official to rule that out [03:55:43 CEST] <Wallboy> 1000 fps on the latest x64 static nightly build, cpu usage up to 40% now. But my custom build is x86, so that may be the difference... Either way it's still not loading the CPU [03:56:15 CEST] <furq> does the source have audio [03:57:01 CEST] <Wallboy> it does [03:57:08 CEST] <furq> are you using -c:a copy [03:57:22 CEST] <Wallboy> ffmpeg -y -i input.mp4 -c:v libx264 -preset faster -crf 23 output.mp4 [03:57:29 CEST] <furq> yeah that's encoding the audio [03:57:34 CEST] <furq> add -c:a copy [03:58:57 CEST] <Wallboy> your own to something sir, 2600 fps 75% usage now [03:58:59 CEST] <Wallboy> on* [04:00:20 CEST] <Wallboy> why would the default audio encoding be causing that then? [04:00:49 CEST] <furq> it's singlethreaded [04:00:50 CEST] <Wallboy> my actual command line filtergraph uses lib-rubberband, so I can't actually use -c:a copy [04:01:06 CEST] <Wallboy> any suggestions on a multithreaded audio codedc? [04:01:12 CEST] <furq> i don't think there is such a thing [04:01:40 CEST] <furq> there definitely isn't one in ffmpeg for aac [04:02:19 CEST] <furq> are you doing a constant speed change [04:02:26 CEST] <furq> you might be able to do that without reencoding [04:03:19 CEST] <Wallboy> [aconcat]rubberband=pitch=1.05[apitch] [04:03:29 CEST] <furq> is that pal to ntsc [04:03:40 CEST] <furq> if the source is h264 then you don't need to reencode [04:04:18 CEST] <furq> http://vpaste.net/nojjo [04:04:23 CEST] <Wallboy> no the video input is h264 encoded [04:04:38 CEST] <furq> yeah you can just remux the video stream with new timestamps [04:04:43 CEST] <furq> you do need to reencode the audio though [04:06:10 CEST] <furq> also i meant pal to film, not pal to ntsc [04:08:45 CEST] <Wallboy> if i ahve re-encode the audio anyway, wouldn't it be the same speed if I seperated them and muxed them back together after? [04:10:35 CEST] <furq> separated them? [04:10:59 CEST] <furq> this won't be any faster than reencoding if you're bottlenecked by the audio, but you won't lose any video quality [04:11:12 CEST] <furq> and you can run multiple jobs in parallel [04:11:13 CEST] <Wallboy> i'm trying to find a better audio codec [04:11:30 CEST] <furq> your only real choices are aac and libfdk_aac [04:11:41 CEST] <furq> and you probably don't have a build with fdk because it's not distributable [04:15:32 CEST] <Wallboy> how is that I can't even find threads talking about this issue with aac bottlenecking encoding speeds. You would think many would have ran into this issue... [04:17:26 CEST] <furq> most people aren't encoding video at 30x realtime [04:29:21 CEST] <Wallboy> libmp3lame encodes fast... until i throw in the rubberband filter, then it drops the speed again :/ [04:30:30 CEST] <furq> like i said, just run jobs in parallel [04:30:37 CEST] <furq> xargs will do it if you're on *nix [04:31:09 CEST] <Wallboy> windows [04:31:25 CEST] <atomnuker> if you need to speed up the aac encoder use -aac_coder fast [04:36:14 CEST] <Wallboy> when adding that I get: "Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height" [04:36:46 CEST] <Wallboy> and "Coders other than twoloop require -strict -2 and some may be removed in the future" [04:38:36 CEST] <Wallboy> added -strict -2 and it's encoding now... however we're down to 15% CPU usage :P [04:41:40 CEST] <Wallboy> trying some other audio codecs, and it's that rubberband filter that seems to be the bottleneck [04:42:40 CEST] <atomnuker> why are you using an ffmpeg version which is almost a year old? [04:42:51 CEST] <atomnuker> that option was changed in august last year [04:42:57 CEST] <Wallboy> because lib-rubberband was built with it [04:43:32 CEST] <Wallboy> none of the official builds have rubberband [04:43:44 CEST] <atomnuker> fair enough, not much has changed to the encoder since then [04:45:29 CEST] <Wallboy> i'm curious how the stand alone rubber band utility performs, going to try it [04:46:14 CEST] <Wallboy> uggh, but I'm concatenting other videos and audio streams in my main ffmpeg command line, and only using rubberband on the main video/audio... that complicates things [04:50:55 CEST] <Wallboy> bah, this rubberband standalone only accepts wav files [04:52:33 CEST] <androclu`> hey, all.. i'm using ffmpeg and since upgrading to debian stretch 9.0, i'm getting segmentation faults. [04:52:49 CEST] <Wallboy> kind of makes you wonder if that's why it's so slow, ffmpeg has to convert it to wav behind the scenes first? [04:53:01 CEST] <furq> it does have to do that but that's not what's slow [04:53:04 CEST] <androclu`> i've tried stable release, a static build from someone else, and my own compile. they're all seg-faulting, and i am dead in the water with 3 projects to get out the door [04:53:37 CEST] <androclu`> the segfault unfortunately gives me absolutely no information about what it didn't like. it just dumps. Any idea how I can pursue it? [04:53:57 CEST] <furq> gdb? [04:54:13 CEST] <furq> if the static build is segfaulting after an upgrade then i can only assume it's your libc [04:54:27 CEST] <furq> that's the only bit that would have changed [04:54:35 CEST] <androclu`> hmmm... [04:54:41 CEST] <furq> does ffmpeg from the repos work [04:54:50 CEST] <androclu`> no, it segfaults, too [04:54:53 CEST] <furq> fun [04:54:59 CEST] <furq> i never had any issues with ffmpeg on stretch [04:55:09 CEST] <androclu`> they all 'work' for a while, and i put it on a script and walk away, and a few minutes later it dies [04:55:14 CEST] <androclu`> hmm... [04:55:56 CEST] <androclu`> i was thinkikng maybe RAM problems, but nothing else is showing a problem [04:56:20 CEST] <androclu`> or maybe something wierd about an audio or video codec.. but then working on several different files results the same [04:56:40 CEST] <furq> i'd have thought you'd get actual lockups/reboots from hardware issues [04:56:53 CEST] <androclu`> i have to admit, after all these years using linux, i've no idea how to use the debugger (gdb) to debug something like this [04:56:57 CEST] <furq> but yeah iirc relaxed's static builds come with a debug binary [04:57:02 CEST] <androclu`> furq: exactly so [04:57:11 CEST] <furq> run that under gdb and type "bt" when it segfaults [04:58:47 CEST] <androclu`> furq: Thank you. Sorry, I'm lame tonight. I googled relaxed ffmpeg but don't see a repo or site ..(?) [04:59:00 CEST] <furq> https://www.johnvansickle.com/ffmpeg/ [04:59:28 CEST] <furq> nvm there's no debug binary [05:00:08 CEST] <furq> and debian has helpfully stopped making a ffmpeg-dbg package [05:03:45 CEST] <Wallboy> so it's absolutely that rubberband filter causing it. i just converted the audio to wav and extracted it and ran it through the standalone rubberband and i'm getting the exact same CPU usage [05:04:10 CEST] <furq> i take it -af atempo isn't high enough quality for you [05:04:39 CEST] <Wallboy> i have used that in the past before, i may have to try it again though, but rubberband definately did sound better [05:06:29 CEST] <Wallboy> i also had to go through a bunch of other filters to make the audio the same length [05:06:37 CEST] <Wallboy> apitch, atempo, and something else [05:07:05 CEST] <Wallboy> had to calculate the samplerate as well which can be variable... i just remember the whole thing being annoying to figure out and why i opted for rubberband [05:07:14 CEST] <Wallboy> variable per video i mean [05:08:18 CEST] <Wallboy> -af "aresample=45600,atempo=0.95,asetrate=48000" [05:08:26 CEST] <Wallboy> from an old ffmpeg command i used to use [05:08:37 CEST] <furq> you shouldn't need to resample for atempo [05:09:06 CEST] <furq> you do for asetrate [05:09:38 CEST] <androclu`> furq: since i was successful in making my own compile, do you happen to know off the top of your head what i would have to add on command-line / configure to add debug symbols? [05:09:49 CEST] <Wallboy> i wanted to change the pitch of the audio, while maintaining the same audio duration [05:09:55 CEST] <furq> iirc you should get an ffmpeg_debug binary by default when you build yourself [05:10:06 CEST] <furq> Wallboy: yeah that's asetrate [05:10:20 CEST] <furq> oh wait nvm [05:10:32 CEST] <furq> either way atempo by itself doesn't need resampling [05:13:06 CEST] <androclu`> furq: oh, there it is, duh: enable-debug=LEVEL [05:21:05 CEST] <Wallboy> trying to get atempo to work again. How do I maintain the same audio length while changing the pitch? [05:21:58 CEST] <Wallboy> i can't remember what i was doing when i did: -af "aresample=45600,atempo=0.95,asetrate=48000" [05:22:19 CEST] <Wallboy> i think i was changing the sample rate first, then changing the atempo to change pitch, and then using asetrate to get it back to the correct duration [05:23:10 CEST] <Wallboy> ya i must have since i got 45600 from 48000 * 5% [05:23:24 CEST] <Wallboy> is there a better way? [05:23:57 CEST] <Wallboy> why i chose those particular sample rates i don't know [05:38:57 CEST] <Wallboy> i might just have to accept that rubberband is a slow unoptimized pos and deal with it [05:42:15 CEST] <Wallboy> if it's going to bottleneck me, i might as well use a slower x264 preset as well... uggh whatever... thanks for all the help though [09:27:14 CEST] <Fyr> guys, can I burn subtitles without re-encoding? [09:27:58 CEST] <Fyr> I know that MP4 and MKV support streams and video player are able to play two streams at once. [09:28:55 CEST] <Fyr> I'm thinking that it's possible to create a stream, like PGS and make it work. [12:12:00 CEST] <Syl20> Hi [12:12:54 CEST] <Syl20> I'm trying to compile ffmpeg with --enable-decklink option, receive this error ERROR: DeckLinkAPI.h header not found [12:13:08 CEST] <Syl20> where to put this file ? [13:24:28 CEST] <elmarikon> cheers! I was wandering if there is a filter in ffmpeg to detect freeze/doubled frames. I read it would be possilble vie opencv (but also not how..:-), so maybe also with the ffmpeg-ocv filer. [13:24:52 CEST] <elmarikon> So I'm kind of lost here... any suggestions!? [13:40:03 CEST] <durandal_1707> elmarikon: yes see signalstats filter [13:49:58 CEST] <elmarikon> i will, thanx... [14:08:20 CEST] <elmarikon> durandal_1707: sorry but I don't get it... How would I use this filter to detect freeze/doubled frames? Do u have a hint for me, please!? [14:09:34 CEST] <durandal_1707> elmarikon: see frame metadata [14:10:03 CEST] <durandal_1707> see that udif,ydif etc are 0 [14:11:21 CEST] <elmarikon> durandal_1707: aaah, now i see it, thanx, I will give it a try. [14:21:11 CEST] <DHE> elmarikon: if the frames are absolutely identical, decimate may help. if they're not absolutely identical, it may still help but you have to give it thresholds [14:21:31 CEST] <DHE> or do you want to just detect? decimate will drop them [14:31:57 CEST] <elmarikon> DHE: I just have to detect them... It's for validation stuff... [14:34:37 CEST] <kerio> is there a filter to blow up the dynamic range of a frame [14:35:14 CEST] <kerio> like turn the minimum luma and turn it into 0, the maximum luma into 255 [14:35:21 CEST] <kerio> *take the minimum luma [14:43:39 CEST] <elmarikon> kerio: that should be possible, converting from one colorspace to another... [14:46:20 CEST] <meriipu> nvenc: https://developer.nvidia.com/nvidia-video-codec-sdk#NVENCFeatures seems to list Maxwell (GM206) as supporting hevc with yuv444p as the pixel format. My current card is a GTX 950, which to my understanding has that architecture. ffmpeg seems to indicate no support (for yuv444p), though? https://bpaste.net/show/3370cd36befb is there an inconsistency in information somewhere or am I misunderstanding? [14:49:51 CEST] <BtbN> increase the log level to get a more detailed error. [14:53:29 CEST] <meriipu> [hevc_nvenc @ 0x2677fe0] YUV444P not supported https://bpaste.net/show/d17bb6b1516a I suppose [14:55:03 CEST] <kerio> elmarikon: this is some gray16 that i want to blow up into gray8 [15:12:21 CEST] <meriipu> how would I list the supported pixel formats of a specific encoder (if that is even a thing that makes sense to do) ? [15:13:55 CEST] <Mavrik> I usually just look at the source :( [15:13:57 CEST] <bencoh> by iterating on .pix_fmts I'd say [15:14:04 CEST] <BtbN> meriipu, http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/nvenc.c;h=f79b9a5… [15:14:25 CEST] <BtbN> It's a hard capability check, the nvenc encoder just reports all potentially supported formats, and then errors at runtime. [15:14:50 CEST] <meriipu> BtbN: that makes sense. Thanks. [15:14:55 CEST] <BtbN> If you get that error message, the nvidia driver itself reports no support for YUV444 [15:16:16 CEST] <meriipu> oh wait really so it is the driver and not ffmpeg not having implemented it? [15:20:33 CEST] <BtbN> See the linked code. [15:20:34 CEST] <meriipu> Mavrik: I suppose these https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/nvenc.c#L39 and then it errors at runtime if it fails, as mentioned? [15:24:01 CEST] <meriipu> BtbN: I think I misunderstood what you meant by hard capability check and/or assumed too soon what the check did. I am not too strong in C [15:29:17 CEST] <kerio> why isn't the opus encoder called opossum [15:34:57 CEST] <atomnuker> you can call it celty if you'd like [15:35:07 CEST] <atomnuker> since it only does celt currently [15:35:52 CEST] <atomnuker> that's not a bad idea actually, might make a patch [15:42:45 CEST] <gmoryes> hello [15:43:53 CEST] <gmoryes> can anybody help [15:44:29 CEST] <gmoryes> if i do ffmpeg -i file.webm -codec copy -y file_clear1.webm [15:44:48 CEST] <gmoryes> and ffmpeg -i file.webm -codec copy -y file2.webm [15:45:17 CEST] <gmoryes> the md5(file_clear1.webm) != md5(file2.webm) [15:45:37 CEST] <BtbN> It contains the creation date and other stuff that changes per invocation. [15:46:16 CEST] <gmoryes> The differ in 16 bytes after first 332 bytes [15:46:31 CEST] <gmoryes> Where I can read what in these 16bytes? [15:46:55 CEST] <BtbN> With a hex editor of your choice I guess? [15:47:25 CEST] <gmoryes> yes, with hex editor, but I don't know what are these 16bytes mean [15:47:56 CEST] <gmoryes> where I can read for example, that first 4byte of 16 - creation date [15:48:10 CEST] <gmoryes> the next 4byte - something other info, and so on [15:48:16 CEST] <BtbN> You'll have to consult the matroska specification about that [15:49:34 CEST] <gmoryes> Okey, thanks! Is there any option to ffmpeg, so that it will not change these 16bytes after per invocation? [15:50:03 CEST] <BtbN> you can probably use one of the bitexact flags. But why? As long as the frames don't change, it seems pointless to insist on that. [15:51:06 CEST] <gmoryes> Because I want to md5(file1.webm) be equal to md5(file2.webm) [15:51:11 CEST] <BtbN> why? [15:51:28 CEST] <gmoryes> It is checking that the input file is same [15:51:29 CEST] <BtbN> If you want to verify the integrity of the video, there's framemd5 for that. [15:52:18 CEST] <gmoryes> The aim is not to encode input_file, if we encoded it later [15:52:41 CEST] <gmoryes> You say, that the framemd5 will help with this task? [15:52:59 CEST] <BtbN> It will hash the actual frames, not the file with random metadata [15:53:14 CEST] <gmoryes> oh, thanks very much [16:00:06 CEST] <meriipu> so say I have a filter graph, is there such a thing as the encoded video before and after the filter? Could I save the video to file before and after scaling, for instance, at little additional processing cost (save for the IO), or have I misunderstood something? -vf "hwupload_cuda,scale_npp=w=1440:h=-1:format=yuv444p:interp_algo=lanczos,hwdownload,format=yuv444p" [16:00:41 CEST] <meriipu> this is for h264_nvenc, by the way. [16:01:50 CEST] <BtbN> you'll probably need a complex filtergraph, that has a tee filter somewhere that sends to an additional output, and then have two encoders [16:02:46 CEST] <meriipu> so the graph does work on some unencoded object, only encoding it to something "outputable" at the end? [16:02:54 CEST] <BtbN> what? [16:03:14 CEST] <BtbN> filters obviously operate on raw frames [16:03:18 CEST] <BtbN> can't scale h264 [16:04:34 CEST] <meriipu> so there is quite some overhead in having to encode two files, then? [16:04:48 CEST] <BtbN> I don't follow [16:07:07 CEST] <Diego__> Just an easy question and (I suppose) fast answer. Why if I don't specify a -t option with a value > 0 when adding an "empty" input with color black FFMpeg keeps compiling forever? (e.g. ffmpeg -i video1.webm -i video2.webm -f lavfi -i color=s=640x480:color=black -i audio1.opus -i audio2.opus ...) [16:07:24 CEST] <BtbN> It'll keep going [16:08:08 CEST] <meriipu> so in one case there is duplicating the same output to two destinations, and in the other (the one mentioned above) outputting two versions, one to each destination. Is the additional computation required about twice as much in the second case, or could the scaled version somehow speed up its work by using results from the encoded pre-filter version ? [16:10:03 CEST] <BtbN> you'll obviously have to encode twice, if you want to diffrent encoded outputs [16:11:58 CEST] <meriipu> thanks [16:35:54 CEST] <meriipu> how are codec options like preset or pix_fmt set independently on split streams? following each -map "[vout]" ? [16:39:09 CEST] <BtbN> They affect the output they are in front of. [16:39:16 CEST] <furq> Diego__: color=black:d=10 [16:39:35 CEST] <furq> or use -shortest if you're overlaying something onto it [16:45:25 CEST] <meriipu> so I should use say -map [options] output1 -map [options] output2 rather than tee? https://bpaste.net/show/5fc73a0febc6 the outputs at least have different resolutions, though I am not sure how to specify encoding options with tee. [16:50:52 CEST] <BLZbubba> hello there, is there a simple cmd line way to identify the information of media files? I remember back in the "old days" the file utility would show resolution & codecs, but it seems useless these days [16:51:02 CEST] <furq> ffprobe [16:53:08 CEST] <BLZbubba> ok cool ty [16:56:56 CEST] <Diego__> furq: I've used -shortest option, without the d= option for the black screen, and still not working. Adding d=1 or -t 1 seems to do the same. I just want to add that black screen without duration, as if it were an image [16:57:20 CEST] <Diego__> to "fulfill" the video mosaic [17:01:14 CEST] <BLZbubba> furq: what does the letter r stand for in "tbr"? [17:01:18 CEST] <BLZbubba> tbn too [17:06:47 CEST] <meriipu> what does format -> stream #1:0 on line 7 mean? https://bpaste.net/show/127021f2b2a6 [17:33:54 CEST] <PsyDebug> Hi all! I need overlay video from some rtsp, but ffmpeg is down every some minutes https://pastebin.com/PEKszVbj What can i try? Thx! [18:05:51 CEST] <DHE> meriipu: you have 2 output files. #1:0 is output stream 0 (first stream) of output file 1 (second file) [18:06:22 CEST] <DHE> looks like you're taking video captured from a desktop and outputting a high quality version and low quality version at the same time [18:24:59 CEST] <meriipu> DHE: why is one line split:output1 -> and the other format -> Stream though? [18:26:21 CEST] <meriipu> I would have expected split:output1 and split:output2, I do not really understand what is meant by format [18:26:29 CEST] <kerio> furq: i fixed my hwdec porn problem :o [18:26:45 CEST] <kerio> by setting hwdec-codecs [18:26:50 CEST] <kerio> to something much more sensible [18:26:54 CEST] <kerio> specifically, h264,hevc [18:27:26 CEST] <furq> i have no memory of this problem but i'm glad that you can now honk one off again [18:27:32 CEST] <alexpigment> haha [18:33:01 CEST] <kerio> apparently the default for hwdec-codecs includes vc1, wmv3 and a bunch of other shit [18:33:10 CEST] <kerio> that has no place whatsoever in the appley world [18:33:12 CEST] <kerio> i think [18:41:42 CEST] <DHE> meriipu: it's going into some kind of filterchain. from the ffmpeg standpoint it's a stream that goes "somewhere" and a distinct stream that comes out "somewhere", hence distinct lines [18:57:25 CEST] <meriipu> DHE: so format is shorthand for something like split:output2 -> filter_chain_stuff [-> Stream #1:0 (h264_nvenc)] ? [19:03:45 CEST] <RandomCouch> JEEB: Hey! Just wanted to let you know I finally got ffmpeg working with Unity on android ! :D [19:03:54 CEST] <RandomCouch> all that research was helpful [19:03:57 CEST] <JEEB> ok [19:04:10 CEST] <RandomCouch> but now I'm having a small issue [19:04:19 CEST] <RandomCouch> I'm trying to concat 2 videos together, and it's working but it's taking a very long time [19:04:32 CEST] <JEEB> are you bit stream copying? [19:04:47 CEST] <RandomCouch> I'm using the method where you convert both vids to .ts first, using ffmpeg -i vid1.mp4 -qscale:v 1 intermediate1.ts [19:04:56 CEST] <RandomCouch> and then merge both intermediates and re-encode [19:05:11 CEST] <RandomCouch> using ffmpeg -f concat -i files.txt -c copy output [19:06:55 CEST] <RandomCouch> I've tried different methods too, like merging both intermediate videos into an intermediate_all.ts and then reencoding that to mp4 [19:07:01 CEST] <RandomCouch> but that took just as long [19:07:45 CEST] <RandomCouch> I also tried ffmpeg -i video1.mp4 -i video2.mp4 -c copy output.mp4 but that only gave me back the first video without concatenating [19:12:04 CEST] <furq> 18:04:47 ( RandomCouch) I'm using the method where you convert both vids to .ts first, using ffmpeg -i vid1.mp4 -qscale:v 1 intermediate1.ts [19:12:07 CEST] <furq> where did you get this command from [19:14:47 CEST] <RandomCouch> I was doing some googling and found it in a stackoverflow question [19:14:54 CEST] <RandomCouch> don't remember where exactly [19:15:56 CEST] <RandomCouch> but basically it goes like -i vid1.mp4 -qscale:v 1 intermediate1.ts then -i vid2.mp4 -qscale:v 1 intermediate2.ts then -i concat:intermediate1.ts|intermediate2.ts -qscale:v 2 intermediate_all.ts [19:19:21 CEST] <RandomCouch> the process of re-encoding the .ts file to .mp4 though, is what is taking so long [19:32:34 CEST] <alexpigment> Hey guys. I'm running into a crash that seems pretty weird to me. I've got a 1080p60 video that I'm using as the basis of a transcoding test bank. One of the tests was trying to create a 1440x1080 video that was interlaced, so I used "-vf crop=1440:1080,interlace=scan=tff" [19:32:38 CEST] <alexpigment> this causes a crash [19:32:54 CEST] <alexpigment> but I can crop or interlace by themselves without issue [19:33:27 CEST] <alexpigment> and I can subsequently interlace/crop the results of those individual encodes [19:33:50 CEST] <alexpigment> so effectively, I can do it in two separate passes without issue. if i try to do it at once, ffmpeg crashes [19:34:19 CEST] <alexpigment> Do any of you guys know of anything about 1080i that would explain this? [19:37:44 CEST] <alexpigment> Oh, and one other important detail: If I scale to 720x480 before interlacing, this doesn't cause a crash. (e.g. "-vf crop=1440:1080,scale=720:480,interlace=scan=tff") [19:38:32 CEST] <JEEB> you probably want to use gdb :) [19:39:14 CEST] <alexpigment> oh, compiling with debugging [19:39:21 CEST] <JEEB> it does that by default [19:39:22 CEST] <alexpigment> I'll try that out [19:39:39 CEST] <JEEB> it will then strip the ffmpeg binary as ffmpeg and I think the ffmpeg_g thing is the debug one? [19:39:43 CEST] <JEEB> check which is bigger [19:39:51 CEST] <alexpigment> ok, i've got that already built [19:39:53 CEST] <alexpigment> i'll just copy it over [19:40:08 CEST] <alexpigment> just gotta fire up this linux VM ;) [19:40:21 CEST] <JEEB> gdb ./ffmpeg_g and then I have to recall how to set the command line parameters in gdb again [19:40:47 CEST] <JEEB> ah right [19:40:48 CEST] <JEEB> http://www.unknownroad.com/rtfm/gdbtut/gdbuse.html#RUN [19:40:49 CEST] <alexpigment> well, if you remember, let me know. otherwise, i'll look it up in a minute after I get this file in place [19:40:50 CEST] <kepstin> my guess is that the way the crop filter works - it just adjusts the start pointer, line length, number of lines but doesn't actually change the size of the memory allocation - is causing the interlace filter to do something wrong. [19:40:52 CEST] <JEEB> run parameters [19:41:02 CEST] <alexpigment> awesome, thanks JEEB [19:41:32 CEST] <JEEB> and yea that tutorial was a nice thing when I had to remind myself the arcane ways of gdb debugging the last time [19:41:46 CEST] <alexpigment> kepstin: I suppose that makes sense. It didn't happen in a build I had from 2014. I assume it's a new bug, but I wanted to check to make sure I wasn't creating a file that was inherently out of spec [19:42:10 CEST] <JEEB> well a crash is never good [19:42:27 CEST] <kepstin> doing it in two passes or with the scale filter means that the frame's reloaded into a new buffer matching the size of the frame, rather than being only part in the middle of a larger frame. [19:42:29 CEST] <JEEB> and if you can then recreate it with something like the lavfi input so you don't even need a file to recreate it [19:42:31 CEST] <alexpigment> true, but my own priority on that crash would be less important if the resultant file wasn't realistic in the real world [19:42:40 CEST] <kepstin> so yeah, I'm guessing it's a bug in the interlace filter [19:42:47 CEST] <alexpigment> JEEB: true. i'll get on that in a second [19:45:03 CEST] <alexpigment> hmmm, i don't think i've tried to mess with lavfi in this way I guess. how do I set it's properties prior to the filtering? [19:45:17 CEST] <furq> 18:40:48 ( JEEB) http://www.unknownroad.com/rtfm/gdbtut/gdbuse.html#RUN [19:45:20 CEST] <alexpigment> like if i do smptebars as in the input, how do i make them 1080p60 [19:45:22 CEST] <furq> you can just do gdb --args ffmpeg -i foo bar [19:45:33 CEST] <furq> and then r [19:45:50 CEST] <alexpigment> furq: I was specifically trying to just simulate my crash without a real input first [19:46:30 CEST] <alexpigment> I've gotta copy this build from my VM which takes a while to load up, so I'm trying to do some other tests while I wait for that [19:48:22 CEST] <furq> -f lavfi -i testsrc=s=1920x1080:r=60 -vf ... [19:48:37 CEST] <alexpigment> great, thanks for that [20:41:59 CEST] <nicolas17> how can I know if the transcoding bottleneck is decoding or encoding? [20:43:13 CEST] <__jack__> you can decode to /dev/null and see [20:43:42 CEST] <nicolas17> huh, true [20:45:30 CEST] <nicolas17> looks like decoding goes at 18fps [20:46:59 CEST] <shincodex> "max_delay" what is its purpose [20:47:12 CEST] <shincodex> i try and it seems like nothing good comes from it [20:47:23 CEST] <shincodex> I thought it was good for buffer up incase corrupt packets [20:51:25 CEST] <nicolas17> does ffmpeg decode and encode in different threads? [20:53:01 CEST] <DHE> the encoders and decoders may support internal multi-threading for their operation, but ffmpeg itself is mostly single-threaded [20:54:22 CEST] <shincodex> h264 is threaded [20:54:32 CEST] <nicolas17> if I transcode from image2 (JPEG) to null muxer, it goes at 18fps [20:54:33 CEST] <shincodex> unless i think you turn that option off or on to tell it not to [20:54:47 CEST] <komanda> hey has anyone heard of some new security vulnerability with .avi files? [20:55:23 CEST] <nicolas17> if I transcode from image2 (JPEG) to libx264, it goes at 8fps but ffmpeg still uses only one core [20:55:23 CEST] <DHE> komanda: can you be more specific? like a link or CVE number? [20:56:00 CEST] <komanda> dont have a link to CVE, just a proof of concept link here: [20:56:03 CEST] <komanda> https://github.com/neex/ffmpeg-avi-m3u-xbin/blob/master/gen_xbin_avi.py [20:56:27 CEST] <komanda> basically it can access internal files and make a movie of the file contents [20:56:53 CEST] <komanda> https://github.com/neex/ffmpeg-avi-m3u-xbin [20:57:11 CEST] <nicolas17> ! [20:57:27 CEST] <DHE> so, they're taking an arbitrary file on disk and forcibly muxing it into an AVI file? [20:57:59 CEST] <BtbN> are they embedding an m3u8 into an avi? That's a thing? [20:59:04 CEST] <nicolas17> DHE: it seems transcoding a specially crafted .avi file may access arbitrary video files from the local filesystem [20:59:19 CEST] <nicolas17> and end up transcoding that instead [20:59:44 CEST] <BtbN> that's something that can happen if you open an untrusted m3u8 list [20:59:50 CEST] <BtbN> But avi? [21:01:39 CEST] <DHE> could you bypass the protocol whitelists by opening an m3u8 that actually came out of an AVI? [21:03:35 CEST] <nicolas17> this performance is weird... encoding 640x480 is not that much faster than encoding 2592x1944? :/ [21:07:46 CEST] <nicolas17> ah looks like at high res it uses 150% CPU rather than 100% [21:08:22 CEST] <nicolas17> anyway, seems I won't speed this up, I'll just run multiple transcoding tasks simultaneously, if I/O allows... [21:09:08 CEST] <shincodex> so [21:12:41 CEST] <nicolas17> I wish I could transcode this on a fast VPS instead of my laptop [21:12:55 CEST] <nicolas17> but uploading the source material will take longer, by several orders of magnitude :x [21:18:35 CEST] <komanda> would there be a way to build ffmpeg m3u8s cannot open local files? [21:20:41 CEST] <alexpigment> JEEB (or kepstin or furq): I just got back from lunch and ran my crashing command with gdb [21:21:04 CEST] <alexpigment> the result was "Thread 1 received signal SIGSEGV, Segmentation fault." [21:21:16 CEST] <furq> did you get a backtrace [21:21:20 CEST] <alexpigment> "0x0000002b in ?? ()" [21:21:24 CEST] <JEEB> "bt full" will give you a long backtrace [21:21:33 CEST] <furq> are you running ffmpeg_g [21:21:33 CEST] <JEEB> aww :< was that the stripped binary? [21:21:44 CEST] <furq> yeah ?? means no debug symbols [21:21:47 CEST] <alexpigment> ahh [21:21:54 CEST] <alexpigment> looks like this ffmpeg_g isn't going to cut it then [21:22:26 CEST] <alexpigment> I did get a message that it was reading the debug symbols though [21:22:30 CEST] <JEEB> oh [21:22:36 CEST] <JEEB> then check bt and bt full [21:22:40 CEST] <JEEB> bt is shorter, bt full is longer [21:23:00 CEST] <JEEB> pastebin 'em and we'll see if it's *any* use [21:23:19 CEST] <alexpigment> ok 1 sec [21:23:31 CEST] <furq> you might also want to get libc6-dbg or whatever your distro calls it [21:24:31 CEST] <alexpigment> (starting to feel that "in over my head because i'm not a developer" feeling :)) [21:24:48 CEST] <alexpigment> sorry, i have to rerun this because it's not letting me exit [21:24:54 CEST] <JEEB> ? [21:24:58 CEST] <furq> ^D to exit gdb [21:25:00 CEST] <JEEB> it should let you be in the gdb terminal [21:25:10 CEST] <alexpigment> it says to type <return> to continue or <return> to exit [21:25:19 CEST] <furq> i forget if there's a way to rerun after a segfault [21:25:19 CEST] <JEEB> write "bt" [21:25:20 CEST] <alexpigment> typing return (or <return>) does nothing [21:25:24 CEST] <furq> oh right [21:25:28 CEST] <JEEB> and then enter [21:25:31 CEST] <furq> yeah you can get a backtrace now [21:25:43 CEST] <alexpigment> jeeb, already did that. one sec [21:31:51 CEST] <alexpigment> https://pastebin.com/2tQjBFZZ [21:32:40 CEST] <JEEB> umm, sounds like you're using 32bit gdb with 64bit windows binaries? [21:33:07 CEST] <alexpigment> hmmm, i should be using 32-bit all the way, but I can rebuild and try again [21:33:22 CEST] <JEEB> or I'm misreading those messages [21:33:29 CEST] <JEEB> regarding libx265 [21:33:46 CEST] <JEEB> but yea, that has nada with regards to debug info [21:34:48 CEST] <alexpigment> yeah, I'm not sure what's up. oddly, it doesn't happen with a purely synthetic source (testsrc), but it happens with two very different real sources (one x264 1080p60 and one ProRes 1080p60) [21:35:03 CEST] <alexpigment> something about cropping to 1440x1080 and interlacing makes ffmpeg blow up [21:35:33 CEST] <alexpigment> I guess I'll just log it on trac and someone can get to it when they get to it [21:35:41 CEST] <JEEB> if it only happens with "actual" sources then you'll probably have to produce a sample that makes it happen [21:35:46 CEST] <JEEB> and yes, post it on trac with a command line [21:36:02 CEST] <alexpigment> Yeah, I'll include a sample [21:36:37 CEST] <nicolas17> how do I skip every other frame? [21:37:00 CEST] <RandomCouch> are certain video encoders faster in terms of re-encoding? [21:37:11 CEST] <RandomCouch> for example would it be faster to reencode to mpeg4 than h264 [21:38:03 CEST] <furq> nicolas17: -vf select="mod(n\,1)" [21:39:11 CEST] <nicolas17> I'm currently using -framerate 120 -i "*.jpg" -r 60 output.mp4 and that seems to work but it still reads and decodes every jpeg file, any way to avoid that? [21:39:39 CEST] <furq> delete every other file? [21:40:29 CEST] <nicolas17> yeah I may have to do that... the naming structure doesn't make that trivial, but... [21:40:42 CEST] <furq> or maybe -pattern_type glob -i "*[02468].jpg" [21:40:49 CEST] <nicolas17> hmm [21:41:30 CEST] <nicolas17> I think that would work :O [21:43:35 CEST] <nicolas17> ok, looks like it was slower than I thought [21:43:38 CEST] <nicolas17> it now says fps=4 [21:43:48 CEST] <nicolas17> so I think previously it was counting the dropped frames when saying fps=8 [21:43:53 CEST] <nicolas17> this will take forever to transcode [21:44:40 CEST] <nicolas17> but the [02468] trick means it won't murder my disk cache so much [21:54:14 CEST] <alexpigment> JEEB: ok, I logged that issue: https://trac.ffmpeg.org/ticket/6491 [21:54:32 CEST] <alexpigment> not expecting you to look into it, but I just wanted to follow up with you [21:57:52 CEST] <kepstin> it looks like it's an issue where the interlace filter is incorrectly using linesize instead of width in a couple of places [21:58:14 CEST] <kepstin> so if linesize > width, it might do some out-of-bounds writes on the dest frame [21:58:21 CEST] <BtbN> that shouldn't really matter, should it? [21:58:37 CEST] <kepstin> from a *really* fast review that might be wrong ;) [21:59:54 CEST] <alexpigment> kepstin: what exactly is linesize? [22:00:14 CEST] <feliwir> hey, how do i synchronise two seperate files with libav for playback? E.g. i have a video file (vp6) and an audio file that is the audiostream for that video (mp3) [22:00:36 CEST] <kepstin> "linesize" is the amount you have to add to a pointer in one of the data frames in order to get to the same column on the next line. [22:01:10 CEST] <alexpigment> i see. are linesize and width usually equal? [22:01:16 CEST] <BtbN> no [22:01:26 CEST] <BtbN> You want the linees to be aligned [22:01:31 CEST] <kepstin> hmm, I might be wrong about that, it looks like the interlace filter is just using av_image_copy_plane, it is passing the width (cols) correctly, so It *should* be working. [22:01:50 CEST] <kepstin> someone's gonna have to actually debug the issue :) [22:02:15 CEST] <nijoakim> Hey all! I am on Debian, trying to stream my desktop to a webm on localhost, (right now, just trying it out with an avi movie). It seems I can connect ffmpeg to ffserver, but when I try to access the stream URL in chromium, just a tiny player with a grayed out play button shows up. Any ideas on how to debug this? [22:02:39 CEST] <BtbN> you won't find a lot of help with ffsever, it's abandoned. [22:03:03 CEST] <kepstin> in particular, the way the crop filter works is that it leaves the actual buffer of image data the same, so the linesize is the same, but it adjusts the 'width' field so later stuff only reads part of the image data. [22:03:03 CEST] <alexpigment> k sounds good. well, it's not a huge deal for me - I already got the files I need by using two separate passes. I was intentionally trying to create every format I could think of for testing, but I imagine that most people aren't ever going to run into this [22:06:55 CEST] <nijoakim> BtbN: Aha, didn't know that. What do people used to stream on linux these days? [22:07:14 CEST] <BtbN> nginx-rtmp [22:07:28 CEST] <nijoakim> okay! Will check it out, thank you [22:07:29 CEST] <BtbN> Or just output to hls and put any normal http server in front. [22:07:44 CEST] <nicolas17> or using ffmpeg to send rtmp into someone else's streaming server like youtube :P [22:08:39 CEST] <furq> if you're streaming to localhost you can probably just use the hls muxer [22:09:06 CEST] <nijoakim> Okay... I didn't know what hls what until just now. What is the hls muxer? [22:09:19 CEST] <furq> https://en.wikipedia.org/wiki/HTTP_Live_Streaming [22:09:21 CEST] <kerio> HLS is a weird thing that apple et al. came up with [22:09:32 CEST] <nijoakim> Yeah, youtube will probably be my backup plan, but I will try to see if I can get this to work on localhost first. [22:09:49 CEST] <kerio> it's a specially-formatted m3u playlist that points to a bunch of .ts files [22:10:05 CEST] <nijoakim> Heh, okay! Yeah, sounds weird enough :) [22:10:07 CEST] <furq> if you need the server to run on a different machine than the encoder then use nginx-rtmp [22:10:07 CEST] <kerio> with directives to HLS-compliant players to keep reloading the playlist to add more and more elements [22:10:20 CEST] <kerio> it adds quite a bit of delay to the video [22:10:24 CEST] <nijoakim> Ah, I need that (server on differnt machine) [22:10:27 CEST] <kerio> but has the advantage of just being http [22:10:33 CEST] <nijoakim> So, I'll go with nginx-rtmp then [22:10:46 CEST] <furq> well yeah you'd normally use nginx-rtmp to create hls anyway [22:10:46 CEST] <nijoakim> Aha [22:10:52 CEST] <nijoakim> Ah, okay [22:10:53 CEST] <furq> since rtmp requires flash these days [22:10:55 CEST] <JEEB> kerio: first we had proper streaming protocols (rtsp) and then people decided they wanted to use standard caching infra for video [22:11:17 CEST] <nijoakim> Ah, so this will be to a flash stream? [22:11:18 CEST] <furq> and also that they didn't want to have to bother setting up their firewalls [22:11:23 CEST] <furq> rtmp is flash, yeah [22:11:27 CEST] <furq> but nginx-rtmp will remux to hls for you [22:11:30 CEST] <kerio> well, twitch.tv is at like 8 seconds of delay nowadays [22:11:32 CEST] <kerio> that's not bad at all [22:11:33 CEST] <furq> and create the playlist that you need etc [22:11:36 CEST] <nijoakim> Ahaa [22:11:54 CEST] <furq> it takes rtmp as ingest and outputs rtmp and optionally hls and mpeg-dash [22:11:59 CEST] <nijoakim> Okay! I will give it a try [22:12:16 CEST] <furq> but yeah i think just about everyone in here who has a streaming server is using nginx-rtmp [22:12:18 CEST] <kerio> and as a bonus, since it's all in nginx, you can tell nginx to also serve the hls files :o [22:12:22 CEST] <kerio> as http, that is [22:12:40 CEST] <nijoakim> And I convert my stream to rtmp with ffmpeg, did I understand that correctly? [22:12:51 CEST] <kerio> yes [22:13:01 CEST] <nijoakim> Great! Thanks [22:13:02 CEST] <kerio> well, somehow produce a stream [22:13:02 CEST] <furq> -c:v libx264 -c:a aac -f flv rtmp://localhost/app [22:13:06 CEST] <kerio> ye that [22:13:17 CEST] <nijoakim> oh, nice [22:13:19 CEST] <furq> on which note [22:13:27 CEST] <furq> dear devs, is there any chance of getting the default codecs for flv changed [22:13:40 CEST] <furq> i don't think anyone is using sorenson spark any more [22:13:53 CEST] <nicolas17> whatyearisit.jpg [22:14:15 CEST] <kerio> furq: and also add a default output format of flv if the output starts with "rtmp://" [22:31:18 CEST] <alexpigment> I'm trying to do a QSV encode, and I get the following warning: "[h264_qsv @ 0000000002b6f780] No device available for encoder (device type qsv f [22:31:18 CEST] <alexpigment> or codec h264_qsv)." [22:31:30 CEST] <alexpigment> but it still creates the video, seemingly with QSV [22:31:45 CEST] <BtbN> qsv has software fallback. [22:32:11 CEST] <alexpigment> interesting. it's a software implementation of the same encoder? [22:32:37 CEST] <BtbN> Well, it's obviously an encoder for the same codec. [22:33:13 CEST] <alexpigment> I guess I was asking for clarification that it wasn't a fallback to x264 (which this doesn't seem to be) [22:33:37 CEST] <utack> where would a problem with zscale be reported? is that a separate project, or ffmpeg bug? [22:33:50 CEST] <JEEB> zscale is a filter in FFmpeg, zimg is the library [22:34:12 CEST] <JEEB> so depends on which is the one that has the boog: zscale or zimg [22:34:21 CEST] <utack> nvm..it does not seem to be a bug https://github.com/sekrit-twc/zimg/issues/60 [22:34:29 CEST] <JEEB> k [22:34:36 CEST] <utack> HDR is definitely confusing if you are not working with it a lot [22:34:48 CEST] <JEEB> yes [22:34:49 CEST] <utack> the picture looks very different from what mpv makes of it [22:35:00 CEST] <JEEB> mpv recently switched its tone mapping algo [22:35:03 CEST] <JEEB> in the opengl renderer [22:35:15 CEST] <JEEB> if you want to discuss these things with haasn, he's on #mpv most of the time [22:35:19 CEST] <nicolas17> looks like input I/O is a significant bottleneck here, ugh [22:35:23 CEST] <utack> so tone mapping clip in my config should probably go? [22:35:23 CEST] <JEEB> he's the opengl renderer guy and who I have been feeding specs to [22:35:38 CEST] <utack> i will look into it, thanks [22:36:34 CEST] <JEEB> but yes, HDR is a lot of "fun" when all the screens can look different while technically being correct [22:36:50 CEST] <JEEB> because the tone mapping hasn't seen a standard yet, for example [22:37:37 CEST] <utack> is HDR as messy as it appears to the uneducated observer, or is it a smart design behind it? [22:37:52 CEST] <JEEB> there's a whole lot of mess in it, just like SDR [22:38:20 CEST] <JEEB> I prefer HLG to SMPTE ST.2084 tho, since that does remember that people tend to not have a specifically standardized-calibrated setup [22:38:53 CEST] <utack> for example i do not get the mastering display properties at all. why does that matter, just display the brightest pixel in the stream the brightest your local display can show? or is that too simple thinking? [22:39:15 CEST] <JEEB> it's to have a constant max/min over the whole clip I guess [22:39:26 CEST] <JEEB> they did add dynamic HDR metadata recently though :D [22:39:39 CEST] <JEEB> so you can adjust per-scene! :D [22:40:23 CEST] <utack> dear god, it sounds terrible [22:41:08 CEST] <JEEB> anyways, we've often had discussions on all the funky things and how the vocabulary is not always stable between specifications etc [22:42:01 CEST] <utack> someone is securing their job. "oh you totally can't implement that without me, only i know what hte latest spec really means" [22:42:21 CEST] <nicolas17> lol [22:42:34 CEST] <nicolas17> sounds like the spec is shit then [22:42:46 CEST] <utack> on the left is mpv "clip", on the right everything 709 after zscale https://i.imgur.com/4oymAXZ.png [22:42:53 CEST] <utack> on my non hdr display [22:43:19 CEST] <JEEB> yea, zscale doesn't do tone mapping IIRC. so if stuff goes above what's possible with SDR, you're out of luck [22:43:34 CEST] <utack> yeah [22:43:38 CEST] <JEEB> in a way, not doing tone mapping is not strictly incorrect [22:43:42 CEST] <JEEB> it just looks like shit [22:43:44 CEST] <JEEB> :D [22:44:39 CEST] <JEEB> anyways, if you have interest on HDR, #mpv and #mpv-devel are probably places you might want to lurk in [22:46:11 CEST] <utack> thanks! i primarily have interest in sane conversion with ffmpeg, but seems like that is not happening, due to the standards fault :D [22:48:20 CEST] <Mavrik> Btw, what's the dynamic log gamma thing? [22:48:35 CEST] <Mavrik> I've been seeing it around with "will support with firmware update" notes [22:49:26 CEST] <Mavrik> *hybrid [22:54:56 CEST] <JEEB> Mavrik: another transfer function, made together by NHK and BBC [22:55:22 CEST] <JEEB> SMPTE ST.2084 is the one made by Dolby ("PQ") [22:55:48 CEST] <JEEB> even if I didn't dislike dolby it seems like HLG is generally the saner spec [22:56:41 CEST] <Mavrik> Ahh. [23:02:05 CEST] <alexpigment> BtbN: for what it's worth, I tracked this issue with the QSV encoder giving a "No device available" message down to about June 14th. All builds tested (including the one I just compiled) exhibit that error on my machine [23:02:19 CEST] <alexpigment> I'm going to go ahead and log it on trac (unless this is a known issue here) [23:13:34 CEST] <BtbN> How does the ocr filter work? Is it supposed to write out the text somewhere? It seems to put it into some metadata. How do I get it? [23:24:17 CEST] <alphabitcity> Is it possible to have ffmpeg overlay a dynamic image? As in, an image rendered by software that's changing constantly .. Ideally force ffmpeg to keep re-fetching it? [23:28:36 CEST] <iive> afaik, you can overlay 2 videos if you want [23:32:01 CEST] <alphabitcity> iive: yea, good thinking. thank you [23:32:29 CEST] <alphabitcity> Does anyone know if the AMF functions here https://www.ffmpeg.org/doxygen/0.6/group__amffuncs.html are exposed in the ffmpeg CLI? [23:33:44 CEST] <hanna> JEEB: technically HLG tone-mapping is standardized [23:33:54 CEST] <hanna> but I don't know if that's only for HDR monitors or also for SDR monitors [23:34:04 CEST] <JEEB> ah [23:34:06 CEST] <hanna> actually let's try [23:35:08 CEST] <hanna> oh right I forgot I don't actually have a HLG test clip [23:35:22 CEST] <hanna> so I can't tell you what it looks like if I take the HLG curve and insert the SDR parameters [23:35:43 CEST] <hanna> but in theory, your display's peak white point is part of the HLG OOTF equation [23:36:05 CEST] <hanna> so if you set that to equal 1 (i.e. the same as the reference white, which is only true for an SDR display), it *should* work [23:36:12 CEST] <hanna> as in, have a defined result [23:39:49 CEST] <komanda> Hi, we got a report today of an ffmpeg vulnerability (https://pastebin.com/raw/vwdXuk9m) [23:40:23 CEST] <komanda> Does anyone know how to disable ffmpeg from grabbing local files in m3u8 format? [23:42:33 CEST] <JEEB> I thought there was a white list kind of thing already implemented? [23:43:21 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=189ff4219644532bdfa7bab28d… [23:43:33 CEST] <JEEB> and quite a bit of older stuff, too [23:44:23 CEST] <iive> komanda: is this a joke? [23:46:26 CEST] <iive> komanda: you run a program locally and give it the passwd file as argument, that program creates a video containing the content of the given file as image [23:46:35 CEST] <iive> and you upload the video to some site. [23:46:52 CEST] <iive> how is that different than uploading your passwd to the site directly? [23:52:39 CEST] <hanna> iive: no, no, clearly ffmpeg has a bug and should not allow you to choose your own files to upload, you should create a clip store and only allow using clips from this clip store [23:53:05 CEST] <hanna> JEEB: have I mentioned yet, a HLG test clip would really help [23:53:11 CEST] <hanna> surely some meme broadcasts have been done in HLG? [23:53:15 CEST] <hanna> given how much the BBC and NHK love it [23:53:26 CEST] <JEEB> I have one meme broadcast in HLG [23:53:42 CEST] <hanna> 22:37 <utack> is HDR as messy as it appears to the uneducated observer, or is it a smart design behind it? <- there's a smart design behing HLG [23:53:46 CEST] <hanna> PQ is a pile of shit [23:53:51 CEST] <hanna> that everybody likes because hurr SMPTE has money [23:54:25 CEST] <hanna> 22:38 <utack> for example i do not get the mastering display properties at all. why does that matter, just display the brightest pixel in the stream the brightest your local display can show? or is that too simple thinking? <- you get clipping artifacts if you just convert and clamp [23:54:40 CEST] <hanna> unless your device exactly corresponds to the specifications of the mastering device [23:54:42 CEST] <hanna> or you use HLG [23:54:44 CEST] <hanna> either one of the two, really [23:54:56 CEST] <hanna> HLG doesn't clip by design [23:55:13 CEST] <JEEB> hanna: didn't you have TravelXP_4K_HDR_HLG.ts ? [23:55:14 CEST] <hanna> at least not for HDR monitors [23:55:18 CEST] <hanna> JEEB: nope [23:55:21 CEST] <JEEB> welp [23:55:33 CEST] <hanna> tone mapping to SDR it would still be good to know the mastering display metadata, but for HLG it's not that important [23:55:40 CEST] <hanna> because the standard HLG peak is reasonably picked [23:55:54 CEST] <hanna> it's only important again for PQ because the PQ people went absolutely apeshit and decided to use 10,000 cd/m² as the peak [23:56:01 CEST] <utack> thanks for the information hanna [23:56:03 CEST] <hanna> which is completely unreasonable even in SMPTE bizzaro-land [23:56:29 CEST] <hanna> (the HLG reference peak is 1000 cd/m² which is much more sane) [23:56:56 CEST] <JEEB> hm? wasn't it much higher than 1000? [23:57:03 CEST] <hanna> nop [23:57:15 CEST] <hanna> the signal peak exactly 12.0 by definition, which is in scene-referred colors [23:57:23 CEST] <hanna> technically for the OOTF you plug in whatever your peak is [23:57:37 CEST] <hanna> but in the absence of this information, or when building a reference display, they've standardize peak=1000cd/m² gamma=1.2 [23:57:50 CEST] <hanna> so you could say the true dynamic range is about 10:1 [23:58:14 CEST] <hanna> at least this is how mpv considers it [23:58:21 CEST] <JEEB> right [23:58:23 CEST] <hanna> and a dynamic range of 10:1 is also what typical HDR clips seem to be using [23:59:19 CEST] <JEEB> oh wow, an ITU-R document that has a part called "common misconceptions on HDR" [23:59:41 CEST] <hanna> the one wtf thing about HLG is that there's no analytical solution to reverse the EOTF and therefore encode something *to* HLG such that it round-trips on a reference monitor [23:59:56 CEST] <hanna> but that's a consequence of making HLG backwards-compatible with SDR [00:00:00 CEST] --- Tue Jun 27 2017

1 0

ffmpeg-devel.log.20170625
by burek 26 Jun '17

26 Jun '17

[00:07:50 CEST] <iive> atomnuker: i think your clang compiler might produce slower code :P [00:09:11 CEST] <kierank> durandal_170: ?? [00:10:08 CEST] <kierank> Oh more review... [00:15:44 CEST] <atomnuker> iive: sure its crap but that not what I'm seeing [00:15:50 CEST] <atomnuker> its as fast as C [00:15:55 CEST] <atomnuker> *gcc [00:16:31 CEST] <JEEB> well with FFmpeg we're disabling vectoring optimizations etc anyways [00:18:38 CEST] <jamrial> iive: that patch is really hard to read... [00:18:41 CEST] <jamrial> so much disabled code [00:19:56 CEST] <iive> jamrial: sorry [00:22:19 CEST] <iive> jamrial: i've left too many alternative methods. As I want to get some benchmark results from them on different CPU's than mine. [00:24:48 CEST] <atomnuker> well, so far avx2 is as slow as sse2 on mine [00:24:58 CEST] <atomnuker> avx and sse42 are the same speed [00:25:17 CEST] <atomnuker> almost done with results though [00:25:30 CEST] <iive> atomnuker: be sure to run benchmarks few times [00:26:15 CEST] <atomnuker> 5 times enough? [00:26:22 CEST] <iive> yes [00:41:21 CEST] <atomnuker> iive: you've got issues [00:41:34 CEST] <iive> what? [00:41:35 CEST] <atomnuker> sometimes the sum doesn't match K [00:41:49 CEST] <atomnuker> 5 times in an hour long album [00:42:02 CEST] <iive> hum, with approx #1 ? [00:42:30 CEST] <atomnuker> iive: https://pars.ee/temp/pvq_v2_benchmark.txt [00:42:43 CEST] <atomnuker> I'll try disabling approximations [00:44:02 CEST] <iive> approx #2 should never have the issue, as it handles it specially [00:44:13 CEST] <iive> you do test the v2 patch, don't you? [00:44:15 CEST] <atomnuker> approx #0 fixes it [00:44:19 CEST] <atomnuker> yes, that's v2 [00:44:30 CEST] <atomnuker> I just forgot to do approx 2, wait for me to do it [00:45:13 CEST] <atomnuker> ok, approx 2 doesn't error, now lets see its speed [00:49:43 CEST] <atomnuker> iive: updated file with approx 2 [00:50:48 CEST] <atomnuker> I think you should drop everything except sse42, and drop every approximation except approx 0 [00:51:11 CEST] <atomnuker> (and assume blends are fast and horizontal stuff is slow) [00:51:34 CEST] <iive> approx 0 uses division [00:51:47 CEST] <iive> it is quite slow on older cpu's [00:52:04 CEST] <iive> aka, no approximation [00:52:16 CEST] <iive> I really hoped that the improved precision on #1 is enough. [00:53:26 CEST] <iive> btw, could you repeat the test of "all_float_presearch" ? [00:53:55 CEST] <iive> just to make sure you didn't left "presearch_rounding" at 0 [00:54:57 CEST] <atomnuker> iive: APPROX 0: 0.000000, APPROX 1: 2.866339, APPROX 2: 7.077843 [00:55:09 CEST] <atomnuker> total distortion over 1 minute [00:55:48 CEST] <atomnuker> iive: presearch rounding was _off_ [00:55:55 CEST] <atomnuker> I mean on [00:56:02 CEST] <atomnuker> I did it right and I'm not doing it again [00:57:17 CEST] <iive> ok. well... that's quite suprising since, this code avoids two cvt and replaces them with special "roundps" instruction [00:58:11 CEST] <atomnuker> iive: tested it again, there is _no_ difference, its still slow [00:58:27 CEST] <atomnuker> (and made very very sure presearch rounding is on) [00:59:30 CEST] <iive> maybe i've swapped the rounding parameters [00:59:46 CEST] <iive> would you test with presearch rounding set 0 and all_floats 1 [01:00:35 CEST] <atomnuker> iive: 1931 decicycles in pvq_search [01:00:42 CEST] <atomnuker> its still slower [01:01:03 CEST] <iive> yeh, i've made mistake. [01:01:03 CEST] <atomnuker> repeated twice, 1926 decicycles now, its slow [01:01:47 CEST] <iive> i kept the allfloat_presearch, because it allows avx1 with 256 regs... [01:02:33 CEST] <atomnuker> 256 bit regs don't help [01:02:50 CEST] <atomnuker> you can always add a patch to modify it later to add support for 256bit regs though [01:04:13 CEST] <iive> avx1 is more of a hack [01:04:40 CEST] <iive> that is, using float registers to hold integer values.... we don't need it. [01:05:10 CEST] <iive> i mean, also using float ops on registers that hold integers. [01:14:14 CEST] <cone-014> ffmpeg 03Michael Niedermayer 07master:63e7bfe78e6d: avcodec/hevc_ps: Fix max_dec_buffer check [01:14:15 CEST] <cone-014> ffmpeg 03Michael Niedermayer 07master:73ea2a028e12: avcodec/wavpack: Fix integer overflow in wv_unpack_stereo() [01:22:37 CEST] <iive> atomnuker: how do you get the "total distortion over 1 minute"? [01:24:33 CEST] <atomnuker> iive: really, the approximations are unacceptable [01:24:45 CEST] Action: kierank wonders when atomnuker will learn to put iive on ignore [01:25:05 CEST] <atomnuker> sacrificing accuracy for performance at stone age CPUs isn't a good tradeoff [01:25:33 CEST] <atomnuker> kierank: I never ignore anyone, ever [01:31:55 CEST] <iive> atomnuker: well, you are aware that neither opus, nor your improved C version are providing the optimal distortion. [01:45:43 CEST] <iive> atomnuker: I don't see benchmarks with stall_write_forwarding and short_syy_update [01:55:36 CEST] <atomnuker> iive: https://pars.ee/temp/pvq_bench_diff_accuracy.diff [01:56:01 CEST] <atomnuker> iive: nevertheless, you don't see libopus decreasing their accuracy because they can get more speed out of a pentium 2 [01:58:56 CEST] <atomnuker> since there's nothing to gain by reducing accuracy on anything more modern that 12 years AND its still faster than C on anything older than 12 years there's no point in approximations [02:02:24 CEST] <iive> actually they do use approximation #2 in their intrinsics code. [02:03:20 CEST] <iive> but I'm not sure how they handle the padding... i'll have to look. [02:04:54 CEST] <atomnuker> so I guess their code needlessly uses the approximation [02:05:48 CEST] <atomnuker> its not better, its worse [03:02:50 CEST] <iive> actually when you told me that approx #1 is not precise enough and still writes in the pad, i was thinking that maybe special crafted values for X and Y so that the computations are always off. [03:03:13 CEST] <iive> seems like opus intrinsic does use just that. [03:06:39 CEST] <jamrial> michaelni: 933aa91e31 broke fate-hevc-conformance-ENTP_C_Qualcomm_1 with THREADS=7 THREAD_TYPE=slice [03:07:28 CEST] <jamrial> the checksum changes between runs [03:17:22 CEST] <iive> i'll be going off. [03:17:25 CEST] <iive> n8 ppl [03:32:04 CEST] <kierank> wm4: was ffmpeg-security worth it in the end? [04:52:21 CEST] <cone-893> ffmpeg 03Michael Niedermayer 07master:89f8bff7983f: avcodec/hevcdec: Do not check the first ff_init_cabac_decoder() call in hls_decode_entry_wpp() for failure [12:37:31 CEST] <cone-121> ffmpeg 03Paul B Mahol 07master:f269a1e0b881: avfilter/vf_overlay: separate functions with main alpha [12:43:51 CEST] <wm4> <kierank> wm4: was ffmpeg-security worth it in the end? <- I "caught" a certain someone pushing a patch to git without going through review, and since something similar was posted to ffmpeg-security, that was probably the justification [12:44:24 CEST] <wm4> at least that's what I thought at the time [13:16:44 CEST] <cone-121> ffmpeg 03Paul B Mahol 07master:8a14374ab374: avfilter/vf_waveform: allow alpha output for >8 depth planar rgb inputs [16:46:42 CEST] <cone-461> ffmpeg 03Paul B Mahol 07master:22a03c29006e: avfilter/vf_blend: add extremity blend mode [17:44:30 CEST] <durandal_1707> atomnuker: are you near finishing noisereduce? [19:59:20 CEST] <atomnuker> durandal_1707: I promise to finish it soon [19:59:53 CEST] <atomnuker> so are you planning on dropping prores encoders other than prores_kostya? [20:00:24 CEST] <durandal_1707> yes [20:01:30 CEST] <durandal_1707> the other one is very minimal in features [20:02:35 CEST] <atomnuker> I know what happened [20:03:04 CEST] <atomnuker> "duuude im writing a prores encoder this new format by apple its gonna be huge it goes inside mp4 and quicktime opens it" [20:03:45 CEST] <atomnuker> "oh man finished writing intra frame support, this stuff was bscly jpeg, so easy, i bet inter is just like h264" [20:04:20 CEST] <atomnuker> "wait, there's no intra... screw this, im working on some game codecs next time" [21:08:46 CEST] <durandal_1707> michaelni: the encoders that try to use strings in options crash frame thread encoder [21:20:33 CEST] <michaelni> durandal_1707, do you have a testcase / command line to reproduce this ? [21:21:52 CEST] <durandal_1707> michaelni: see my old patch for prores_ks frame threading encoder [21:22:36 CEST] <durandal_1707> michaelni: basicall add non null string option to frame encoder like utvideoenc [21:23:00 CEST] <durandal_1707> and than encode with frame encoding [21:23:56 CEST] <durandal_1707> at eof it will crash [21:28:29 CEST] <durandal_1707> michaelni: have you reproduced it? [23:27:56 CEST] <philipl_> jkqxz: Thanks for the feedback. I've posted an updated patch set. [23:47:36 CEST] <iive> https://lists.debian.org/debian-devel/2017/06/msg00308.html small microcode bug in skylake & kabylake cpu's [23:58:46 CEST] <philipl> awesome [23:59:13 CEST] <nevcairiel> better dont read the list of erratas for any given processor, they are very long =p [00:00:00 CEST] --- Mon Jun 26 2017

1 0

ffmpeg.log.20170625
by burek 26 Jun '17

26 Jun '17

[00:06:04 CEST] <FurretUber> Hi, I am trying to capture the screen and the sound on Xubuntu 17.04, with the ffmpeg snapshot from three days ago. I am using VA-API to record video and it is working fine, but I am having troubles to record the sound. [00:07:18 CEST] <FurretUber> Initially I have tried with alsa, but then I could hear nothing while it was being recorded. Then I tried with pulse, but the result was horrible. Now I am using OpenAL, and this is by far the best [00:08:19 CEST] <FurretUber> However, when recording from a bluetooth device, the capture volume is being influenced by the bluetooth's device volume [00:08:29 CEST] <FurretUber> Which don't happen with the internal sound [00:09:10 CEST] <FurretUber> Here is the output of the command: https://pastebin.com/2xzEkdJz [00:22:54 CEST] <algun_> My -audiofile gets out of sync with video, how can I adjust only the video speed? [00:43:37 CEST] <ArsenArsen> After upgrading to 17.04 it works! Thanks! [01:32:34 CEST] <podman> hi there! anyone have any experience sandboxing ffmpeg? [01:33:11 CEST] <JEEB> make minimal builds regarding features you need, and only give it access to things it needs to have access to [01:33:42 CEST] <podman> for instance, if someone were to craft a malicious m3u8 manifest that attempted to access files... what would be a good way to deal with that (assuming hls support is still required) [01:33:54 CEST] <podman> JEEB: in more practical terms? [01:34:54 CEST] <JEEB> well first of all put it in its own kernel namespace, then additionally limit things with whatever security system you like, and only build FFmpeg with protocols, demuxers, decoders, encoders and muxers that you need [01:35:00 CEST] <JEEB> can't really say much more than that [01:38:40 CEST] <podman> and how would one go about that? the actual sandboxing? [01:52:36 CEST] <__deivid__> Hi! I'm transcoding THOUSANDS of videos (distributed across multiple computers) and ffmpeg is currently showing ~50% cpu usage and 40% 'nice' usage. Can this be because I'm reading/writing to NFS? [02:09:52 CEST] <c3-Win> __deivid__: The best way to know would be to copy a file locally and test with the same settings. [02:11:03 CEST] <c3-Win> And you can get even deeper into your testing by trying not only locally/locally but also locally/NFS and NFS/locally to see if it's reading or writing that's the slowest part... or both. [02:16:35 CEST] <__deivid__> c3-Win. I'll test it when this batch finishes [02:32:41 CEST] <DHE> multi-threading doesn't scale perfectly. coordination between threads is a thing. if you truly want 100.00% CPU usage, run your jobs in single-threaded mode and bound to a single CPU, with 2 jobs per CPU [02:40:06 CEST] <__deivid__> DHE: Yeah I have a few monster servers running multiple transcodings, tested with 1 to 8 threads and you do get diminishing returns. 4 was the sweet spot. [02:40:53 CEST] <__deivid__> But 4 threads gets me ~35fps downscaling 1080p to 720p when encoding x264 in (high profile, 4.0) [02:41:21 CEST] <__deivid__> I'm guessing the IO from nfs is killing it [02:42:03 CEST] <DHE> __deivid__: I've done similar on a dual socket E5-2698v4 (20 cores + hyperthreading). One job uses 800% of a possible 8,000% CPU availability. You'd think 10 instances would do it. But if I run 16 instances each slows a bit I see ~92% total utilization. Raising to 20 did nothing to total utilization [02:43:51 CEST] <DHE> each of the x264 threads are firing up, doing work, and going back to sleep. but on linux even if a job isn't actually running it still has a "home" CPU and moving it incurs a migration cost. as such tons of threads running and sleeping all the time just doesn't max out CPU [02:44:30 CEST] <DHE> or maybe linux isn't able to push a thread to an idle CPU when one is available quickly enough. I don't know the specifics. I just know you can't reach 100% usage like this. [02:44:37 CEST] <__deivid__> DHE: I have exactly the same cpu (and 4 servers) [02:45:06 CEST] <DHE> oh... and running that many ffmpeg instances isn't ideal either [02:45:23 CEST] <DHE> I thought you might have ryzen 7 or something [04:37:48 CEST] <aletorrado> [DirectShow] hey! is it possible to select the tv tuner channel when transcoding from a directshow tuner device? [05:14:14 CEST] <buu> So [05:14:22 CEST] <buu> I've got a chromecast(ultra?) in a vizio md55-0 [05:14:34 CEST] <buu> it will play x264 [05:14:36 CEST] <buu> but not 264 [05:14:38 CEST] <buu> *5 [05:15:10 CEST] <buu> Is this A) not really an ultra B) a problem with ffmpeg's x265 output C) something else [05:16:01 CEST] <buu> https://support.vizio.com/s/article/ka61a000000DWXDAA4/M55-D0-Model-Informa… [05:40:15 CEST] <buu> hm [05:40:22 CEST] <buu> How do I even tell which chromecast I have? [06:31:31 CEST] <buu> Also.. why doesn't -b:v set the bitrate? [06:31:56 CEST] <buu> Oh, maybe it is [06:34:55 CEST] <buu> I see this is a popular channel [06:35:40 CEST] <buu> Ok, how do I get more than 2.5fps encoding vp9? [07:00:01 CEST] <Threads> you get a better computer [07:12:12 CEST] <c3-Win> You use Google to search for better settings? [07:12:38 CEST] <c3-Win> You wait for someone to write a better implementation? [07:12:48 CEST] <c3-Win> You write one yourself? [07:52:51 CEST] <buu> Threads: if only that were possible =[ [07:54:37 CEST] <buu> Although since it is single threaded maybe an over clocked 7700k or something [08:52:20 CEST] <c3-Win> If I assemble an avfilter (the buffer+context+Sink+etc, etc) can i update the values in the the actual filter, or do I need to destroy everything and re-create it again? [10:04:28 CEST] <ArsenArsen> If anyone uses MXE, what do I need to compile in order to use libav* to Windows? I tried `make ffmpeg' in MXE and it compiled ffmpeg, but there is alot of undefined references afterwards when crosscompiling my project. https://hastebin.com/elaxubufig.swift [11:42:24 CEST] <superware> I'm using ffmpeg library to av_read_frame frames from a live h264 stream, when I'm dispaying each frame at it comes (without any synchronization) - the video is a little jittery, but since I must keep low-latency playback how can I still keep the rendering rate as close to the frames rate as possible? [11:46:13 CEST] <bencoh> respect pts when displaying pictures I'd say [12:01:30 CEST] <ArsenArsen> yeah you're probably not respecting it [12:07:40 CEST] <ArsenArsen> Hmm, while using the libs I don't seem to write out all the frames, a few are skipped on the end [12:09:02 CEST] <ArsenArsen> I use the new send/receive API, and before writing the trailer and closing the file output stream I receive all packets and scale their timestamps and write them, and frames are still missing. I am in a single thread environment so it's not race conditions [12:28:09 CEST] <superware> bencoh: according to my understanding pts is being used for synchronization of separate elementary streams, and not playback... [12:28:20 CEST] <ArsenArsen> presentation timestamp [12:33:20 CEST] <BtbN> of course they are used for playback [12:33:30 CEST] <BtbN> That's the whole point of timestamps [12:40:20 CEST] <superware> so it's not a good idea to get the frame rate and calculate a delay after each frame render? [12:41:06 CEST] <BtbN> why would you do that? You have the timestamps [12:41:57 CEST] <superware> which represent time in conjuction with the time_base? [12:45:57 CEST] <superware> BtbN: and how can I maintain low-latency playback? for exammple, should I always keep only the two latest frames in the render queue? [12:46:28 CEST] <BtbN> you always need some buffer [12:46:37 CEST] <BtbN> a few frames is probably enough [12:47:14 CEST] <BtbN> Can probably make it very small, and just present things the moment they come in, if enough time has passed [12:50:47 CEST] <superware> "if enough time has passed"? [12:51:36 CEST] <superware> I'm currently showing frames as they come, but then the video seems a bit jumpy since packets aren't arriving at FPS rate [12:51:51 CEST] <superware> the video isn't smooth, that is [12:53:27 CEST] <BtbN> well, that's what happens if you ignore their timestamps [12:53:47 CEST] <BtbN> don't present them before it's their time [12:53:59 CEST] <BtbN> that's the whole point of having presentation timestamps [12:58:58 CEST] <superware> something like: av_rescale_q(av_gettime_relative(), av_get_time_base_q(), _output_ctx->streams[stream_index]->time_base) ? [15:04:33 CEST] <aletorrado_> Any idea how to choose tv tuner channel using DirectShow? Thanks :) [15:11:15 CEST] <BtbN> I don't think TV tuners use DirectShow [15:11:22 CEST] <BtbN> There is a whole diffrent API for that stuff [15:11:27 CEST] <BtbN> Which ffmpeg does not support [15:21:28 CEST] <aletorrado_> Yes it uses directshow! It's listed as a dshow device in ffmpeg, but i cannot choose the channel [15:23:09 CEST] <aletorrado_> Capturing video&audio works fine though [16:04:58 CEST] <ChocolateArmpits> aletorrado_, you followed thet dshow tutorial page ? [16:06:05 CEST] <aletorrado_> ChocolateArmpits: yeap, it doesn't mention how to choose the channel [16:12:29 CEST] <c3-Win> I don't think changing the channel is a part of dshow. The Video output part (i.e. the card AV interface) is usually Dshow, but not the command list/structure. [17:00:00 CEST] <superware> BtbN: I'm still struggling with low-latency playback, I have a thread dequeuing frames as they come from avcodec_receive_frame, how should I calculate the delay between two dequeued frames? [17:00:51 CEST] <BtbN> check the timestamps, if enough time has passed, present the frame, if not, wait [17:03:17 CEST] <superware> for example, frame->pts increment by 3600, time_base is 1/90000 so each frame is 40 ms (25 fps), how should this be synced with the real time clock? [17:03:45 CEST] <BtbN> those are 40 real milliseconds [17:04:15 CEST] <superware> right, but I need a reference to the real time timestamp [17:04:23 CEST] <BtbN> real time stamp? [17:04:35 CEST] <BtbN> The time stamps are arbitrary, usually starting at 0 [17:04:39 CEST] <BtbN> not related to wall clock [17:06:34 CEST] <superware> but I must also measure real time, else how can I know how much time passed since last frame? [17:06:49 CEST] <BtbN> yes, use whatever precise API you have [17:07:34 CEST] <BtbN> just save the precise system time when playing the first frame, and the offset from it to the frame timestamps [17:07:45 CEST] <BtbN> then you can always calculate for every frame if it should have been presented already [17:09:08 CEST] <superware> but then if the first frame was late by 300 ms from the live stream, then latency will never be less than 300 ms [17:09:54 CEST] <BtbN> you can't have no latency at all [17:10:02 CEST] <superware> minimal [17:10:12 CEST] <BtbN> I'd say 300ms is very minimal [17:10:24 CEST] <JEEB> I don't remember how low some people doing medical equipment with libx264 got the latency [17:10:32 CEST] <JEEB> but it was IIRC pretty darn low [17:11:06 CEST] <BtbN> you need some buffer to get smooth playback, otherwise every tiny network jitter or CPU spike that slows encoding will be visible [17:12:38 CEST] <BtbN> can probably dynamically decrease that offset until you start getting frames too late, and then increase it a bit again, so that you still have wait times, but they are minimal [17:14:32 CEST] <superware> do you know of an existig example of such playback logic? [17:15:16 CEST] <ChocolateArmpits> I think x264+lan+mplayer had the latency of about 80-120ms in my case. [17:15:22 CEST] <JEEB> (very) low latency is such a specific requirement that you'd have to poke quite a bit to find some examples of that on the playback side [17:15:42 CEST] <superware> JEEB: I'm doing libav directly, I have my own queues ;) [17:15:44 CEST] <JEEB> some existing software can be configured for lower latency but the switches are often not known :P [17:17:33 CEST] <BtbN> Even Steam-Inhome has a noticable delay, and I'd assume that to be pretty tunes [17:17:36 CEST] <BtbN> *tuned [17:18:50 CEST] <furq> https://lists.debian.org/debian-devel/2017/06/msg00308.html [17:18:51 CEST] <furq> nice [17:45:29 CEST] <podman> I'm running into an interesting issue compiling FFMPEG on ubuntu 14.04 (yes i know it's old). It seems to be unable to find certain libraries, for example, I get the following error: 'libass not found using pkg-config', even thought libass-dev is installed using apt-get [17:45:56 CEST] <JEEB> check config.log [17:46:09 CEST] <JEEB> it could just be a case of not new enough version or so [17:47:42 CEST] <podman> JEEB: that would be interesting. I'm using a specific version of FFMPEG and a chef cookbook to install it. Worked without any issues in mid Feb but isn't working anymore. The only thing I can think of right now is that a newer version of chef is doing something weird? I'll see if I can find the config.log [17:49:06 CEST] <JEEB> dunno, in any case config.log's got the actual check and what happened [17:50:48 CEST] <podman> JEEB: ok, so it shows: "Package libass was not found in the pkg-config search path." [17:51:13 CEST] <JEEB> and the specific check is there, too [17:51:19 CEST] <JEEB> but yes, that pretty much says it all [17:51:31 CEST] <JEEB> pkg-config <something> didn't give a proper result [17:52:31 CEST] <podman> right, but if I run that check manually, it does exist [17:52:41 CEST] <podman> pkg-config --exists --print-errors libass [17:54:07 CEST] <JEEB> check what exactly it checks for [17:54:11 CEST] <JEEB> it should show up in config.log [17:54:43 CEST] <podman> that is exactly what is in config.log [17:54:58 CEST] <JEEB> ok [17:55:08 CEST] <JEEB> then when that ran pkg-config didn't get what you expected [17:55:48 CEST] <podman> maybe it's being run as a different user and for some reason that user doesn't have access to that library or the search path? [17:57:13 CEST] <podman> of for some reason PKG_CONFIG_PATH isn't set properly when it used to be? [18:14:20 CEST] <podman> JEEB: well, that's interesting. manually specifying PKG_CONFIG_PATH fixes it as far as I can tell. still waiting for it to finish. not sure why it wasn't able to find that [18:20:48 CEST] <podman> JEEB: well, that did it. ¯\_(Ä)_/¯ thanks for helping me solve that [18:59:15 CEST] <sfan5> ffmpeg can't read vapoursynth scripts directly can it? [19:01:57 CEST] <JEEB> nope, that's why you have vspipe [19:03:09 CEST] <sfan5> ;_; [19:10:50 CEST] <ChocolateArmpits> just use vapoursynth standalone [19:14:10 CEST] <JEEB> that's what vspipe is [19:14:23 CEST] <JEEB> basic vs client that passes video through [19:27:23 CEST] <sfan5> yeah i settled on vspipe with -y piped to ffmpeg -f yuv4mpegpipe -i - [20:32:32 CEST] <sfan5> is x265 supposed to look inferior to x264 at the same crf? [20:33:18 CEST] <BtbN> The crf values are arbitrary and implementation defined [20:33:38 CEST] <sfan5> what the ffmpeg wiki says is total bullshit then [20:33:42 CEST] <sfan5> but i remember someone mentioning that [20:33:43 CEST] <furq> in practice, no [20:34:01 CEST] <sfan5> (referencing the bullet points here https://trac.ffmpeg.org/wiki/Encode/H.265#ConstantRateFactorCRF) [20:34:06 CEST] <furq> the default x265 crf is 28, so i assume the same x265 crf setting maps to a higher quality than the same one in x264 [20:34:21 CEST] <furq> but yeah that's the most concrete comparison you'll get [20:34:31 CEST] <furq> they're just arbitrary numbers [20:34:36 CEST] <sfan5> x265 has more noticable blocking compared to x264 (both crf=21) [20:34:53 CEST] <sfan5> at least for the source material i have here rn [20:37:51 CEST] <JEEB> the CRF numbers are most likely completely different between the two encoders, just like they are somewhat different between settings and bit depths within x264 [20:38:38 CEST] <sfan5> fps=6.3 this reminds me of libvpx [20:38:54 CEST] <furq> at least it's using all your cores [20:38:58 CEST] <sfan5> true [20:39:04 CEST] <JEEB> and probably better rate control than libvpx [20:39:10 CEST] <JEEB> given that libvpx is completely bonkers [20:39:21 CEST] <sfan5> x265 [info]: Main profile [20:39:27 CEST] <furq> so what are the filesizes [20:39:28 CEST] <JEEB> I mean, libaom was going to put in *theora*'s rate control [20:39:30 CEST] <sfan5> wait shouldn't it default to High or some shit? [20:39:37 CEST] <JEEB> sfan5: HEVC has no high profile [20:39:40 CEST] <sfan5> oh [20:39:51 CEST] <furq> and also what presets are you using [20:39:53 CEST] <JEEB> it has main, main 10 and then various main X for 4:4:4 etc [20:39:59 CEST] <furq> i assume a good one if it's running at 6fps [20:40:10 CEST] <sfan5> -c:v libx265 -preset slower -crf 21 [20:40:20 CEST] <furq> what about x264 [20:40:51 CEST] <sfan5> same with s/265/264/ [20:41:25 CEST] <furq> shrug [20:41:28 CEST] <furq> x265 should compress better [20:41:42 CEST] <furq> obviously those settings won't even remotely target the same filesize though [20:41:53 CEST] <sfan5> it's true that the file is smaller but it also looks worse [20:42:11 CEST] <furq> lower the crf then [20:43:41 CEST] <furq> JEEB: people keep saying that as if we're supposed to remember how good theora's rate control was [20:43:50 CEST] <JEEB> it's shit [20:43:57 CEST] <furq> noted [20:44:05 CEST] <JEEB> the joke is that they were replacing it because it was less shit than libvpx's [20:44:13 CEST] <furq> i got that much [20:44:20 CEST] <furq> everyone knows how shit libvpx's is [20:44:43 CEST] <JEEB> no idea if they went through it, though. since AV1 wasn't finished I just haven't looked into it too much [20:47:57 CEST] <sfan5> i think what i'm hitting here is just an edge case of x265's deblock not being good for low-brightness areas [20:51:18 CEST] <kerio> what's the equivalent of opus for video? [20:51:26 CEST] <sfan5> since everything else looks fine [20:51:38 CEST] <sfan5> this alone however makes x265 unworthy of using for me [21:02:04 CEST] <JEEB> sfan5: I will note that since most HW decoders for HEVC handle 10bit that pretty much should be the standard for HEVC. of course that makes the encode even slower ^_^ [21:02:21 CEST] <JEEB> also all this reminds me that I should probably make another test of x265 [21:03:01 CEST] <sfan5> i guess that means i will not encode H.265 in the next 3 years [21:06:27 CEST] <JEEB> I only encode HEVC when absolutely needed [21:06:34 CEST] <JEEB> because any sane presets will go slooow [00:00:00 CEST] --- Mon Jun 26 2017

1 0