Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

March 2017

1 participants
62 discussions

ffmpeg-devel.log.20170330
by burek 31 Mar '17

31 Mar '17

[00:00:08 CEST] <mateo`> av_buffersink_get_format :) [00:00:50 CEST] <jkqxz> Yep! [00:06:02 CEST] <cone-796> ffmpeg 03Mark Thompson 07master:e3fb74f7f9a8: lavfi: Always propagate hw_frames_ctx through links [00:06:03 CEST] <cone-796> ffmpeg 03Matthieu Bouron 07master:b5e1ec566069: Merge commit 'e3fb74f7f9a8f1895381355f40c92cac3c1023d9' [00:07:01 CEST] <mateo`> jkqxz: thanks for your help [00:08:09 CEST] <mateo`> hwmap is not too far away :), anyway i'll probably continue the merges tomorrow if ubitux does not [00:36:23 CEST] <PaoloP> git send-email -1 --to=ffmpeg-devel(a)ffmpeg.org --in-reply-to= .... how can I obtain the string of the message to which I have to reply ? for example, in replay to this msg: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209324.html [00:38:39 CEST] <JEEB> PaoloP: look at the link that you get when you right-click the e-mail address of clement [00:38:40 CEST] <jkqxz> Look at the mailto link at the top (see the In-Reply-To argument). [00:41:00 CEST] <PaoloP> t [00:42:28 CEST] <PaoloP> thnks jkqxz JEEB: I obtain In-Reply-To=%3C20170329074335.GD14584%40golem.pkh.me%3E" <---but I see weird characters as well [00:42:59 CEST] <PaoloP> %3E, %40.... [00:46:14 CEST] <PaoloP> solved, nm, used the ascii chart [00:46:16 CEST] <RiCON> that's url encoding [00:46:19 CEST] <JEEB> ^ [00:47:00 CEST] <RiCON> %3C = <, %40 = @ and %3E = >, i'd guess [00:47:08 CEST] <PaoloP> RiCON: yes, thnks [00:47:24 CEST] <JEEB> you can use python or so to decode it easily [00:48:22 CEST] <JEEB> https://docs.python.org/3/library/urllib.parse.html [01:02:31 CEST] <PaoloP> JEEB: nm, it only gives me the three chars that RiCON listed [01:06:26 CEST] <J_Darnley> I wonder whether git or email clients would thread properly if you gave the URL-encoded string on the command line. [01:07:14 CEST] <RiCON> thunderbird can probably take the whole mailto: [01:07:32 CEST] <RiCON> not sure on git [01:42:23 CEST] <cone-796> ffmpeg 03Carl Eugen Hoyos 07release/3.2:582c3d514a7b: lavf/flacdec: Return maximum score if the streaminfo header is valid. [02:20:53 CEST] <cone-796> ffmpeg 03James Almer 07master:c14b3ea93c4f: ffprobe: fix printing packet side data information [02:28:43 CEST] <michaelni> jamrial, btw ive succeeded to install gcc 5.2.0 on solaris and fate passes except fate-source (some non posix tool i suspect)) [02:31:20 CEST] <michaelni> btw i see on the x86-32 solaris fate client "can't create libavcodec/x86/hpeldsp_vp3_init.o: Disc quota exceeded" [02:31:40 CEST] <michaelni> could be unrelated though [02:42:36 CEST] <jamrial> michaelni: no idea then, maybe some difference in their environments [02:43:09 CEST] <jamrial> oddly enough their four slots (x86_32, x86_64, sparc, sparc64) fail the same way [02:43:33 CEST] <michaelni> yes, its a bit odd [02:44:01 CEST] <michaelni> also no valgrind on solaris it seems at least no package in the main repo with that name or i am silly [02:45:31 CEST] <michaelni> wtf doesnt even patch work on solaris [03:12:52 CEST] <cone-796> ffmpeg 03Michael Niedermayer 07master:5f019909c0e2: avfilter: Add AV_OPT_FLAG_FILTERING_PARAM where it is missing [03:12:53 CEST] <cone-796> ffmpeg 03Michael Niedermayer 07master:ad7aff035517: tests/fate/source-check: Use git grep in place of grep [03:17:06 CEST] <thebombzen> what repo is docs/nut4cc.txt in? [03:17:16 CEST] <thebombzen> it's not in ffmpeg.git [03:19:20 CEST] <michaelni> thebombzen, svn://svn.mplayerhq.hu/nut [03:19:37 CEST] <thebombzen> time to learn svn again lol [03:20:18 CEST] <michaelni> thebombzen, https://git.ffmpeg.org/gitweb/nut.git [03:20:42 CEST] <thebombzen> oh okay, thanks [03:22:44 CEST] <thebombzen> now, it says the spec is frozen [03:22:52 CEST] <thebombzen> does that not count adding extra 4ccs? [03:27:16 CEST] <michaelni> any change not breaking existing files could be considered [03:35:55 CEST] <thebombzen> michaelni: alright, I sent the patch [09:34:52 CEST] <cone-056> ffmpeg 03Martin Storsjö 07master:2e55e26b40e2: vp9: Flip the order of arguments in MC functions [09:34:52 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:4503d678cb04: Merge commit '2e55e26b40e269816bba54da7d0e03955731b8fe' [09:40:35 CEST] <ubitux> wbs: how much in sync are {libav,ffmpeg}/libavcodec/arm/vp9mc_neon.S? [09:41:02 CEST] <ubitux> based on libav/master it looks like there are differences, are they justified or one is missing a few changes from the others? [09:41:37 CEST] <wbs> ubitux: they are supposed to be identical, mostly. on the libav side, some things were fixed in later commits - all the commit hashes should have been mentioned in the commits on the ffmpeg side [09:41:51 CEST] <wbs> ubitux: the latest libav version should be identical (as far as possible) to the ffmpeg version [09:42:08 CEST] <ubitux> there are a few differences [09:42:16 CEST] <wbs> ubitux: for itxfm and lpf, there's really no other changes than ffmpeg having 10/12 bit support, and the license header. for mc there's a tiny detail [09:43:02 CEST] <ubitux> http://b.pkh.me/ffavmcvp9neon.html [09:43:13 CEST] <wbs> in libav, ff_vp9_subpel_filters is int8_t and lacks the first (offset 0) filter coefficients [09:43:17 CEST] <ubitux> ah sorry not up-to-date this one [09:43:28 CEST] <wbs> in ffmpeg, they're int16_t and have got the first row present [09:43:49 CEST] <ubitux> (now it is) [09:44:00 CEST] <ubitux> wbs: ah, ok :) [09:44:02 CEST] <wbs> so the offsets and shifts for loading the filter coefficients are different, and on the libav side, there's a vmovl to widen to 16 bit [09:44:58 CEST] <ubitux> alright, perfect then [09:45:00 CEST] <ubitux> thanks [09:45:19 CEST] <wbs> yup, those differences are to be expected. if you look at ff_vp9_subpel_filters in libavcodec/vp9dsp.c in the two projects you'll see the difference [09:45:51 CEST] <wbs> for itxfm and lpf there shouldn't be any difference except for license headers, and 10/12 bit [09:46:24 CEST] <cone-056> ffmpeg 03Martin Storsjö 07master:ffbd1d2b0002: arm: vp9: Add NEON optimizations of VP9 MC functions [09:46:25 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:d4bb093ad35a: Merge commit 'ffbd1d2b0002576ef0d976a41ff959c635373fdc' [09:46:36 CEST] <wbs> especially as long as the commit hash is mentioned in one of my cherrypicks, you should be able to no-op the merge [09:50:16 CEST] <ubitux> yep i didn't notice you took care of referencing the hash :) [09:50:37 CEST] <wbs> that commit message is .. rather large, yeah :P [09:56:45 CEST] <cone-056> ffmpeg 03Martin Storsjö 07master:1a469a5e423b: options_table: Remove a now unnecessary include of config.h [09:56:46 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:a48c0c41c4de: Merge commit '1a469a5e423bdad779b8534247dea8cc86169b88' [09:57:27 CEST] Action: ubitux can't test windows ce/phone/rt/.. [10:00:29 CEST] <mateo`> come on, put some effort, it's the next step after freedos :D [10:01:00 CEST] <wbs> TBH, I've never actually run tests for the wince or symbian builds, only tested building [10:01:22 CEST] <wbs> I did actually use builds for wince at some point many years ago though, so at least some codecs did work in the build back then [10:02:55 CEST] <cone-056> ffmpeg 03Diego Biurrun 07master:ee59f0540875: intrax8: Have function signature match across declaration and definition [10:02:56 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:b76dd6a67832: Merge commit 'ee59f0540875ab42496af2aacddd942757707683' [10:04:35 CEST] <cone-056> ffmpeg 03Diego Biurrun 07master:13fcdfb97603: svq3: Drop unused function dctcoef_get() [10:04:35 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:a5745897e4c5: Merge commit '13fcdfb976038f63b9f753e2ebcc8e04d7c7abc2' [10:06:26 CEST] <cone-056> ffmpeg 03Mark Thompson 07master:67c65e461cb0: vf_hwupload_cuda: Fix build error [10:06:27 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:4f96c11ed743: Merge commit '67c65e461cb073d61ffbc78845d4a3d8f14bf481' [10:07:45 CEST] <ubitux> "warning C4028" are these MSVCC stuff? [10:08:47 CEST] <ubitux> (the number looks close to the warnings id disabled in the configure) [10:09:33 CEST] <nevcairiel> yes [10:10:10 CEST] <nevcairiel> "The type of the formal parameter does not agree with the corresponding parameter in the declaration. The type in the original declaration is used." [10:11:11 CEST] <cone-056> ffmpeg 03Diego Biurrun 07master:99ddeddc7fc9: ituh263dec: Have function signature match across declaration and definition [10:11:12 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:c223784ea7f3: Merge commit '99ddeddc7fc996c0c1e842112928490e78542bd5' [10:15:24 CEST] <cone-056> ffmpeg 03Diego Biurrun 07master:c778eb15b89d: pixblockdsp: Have function pointer prototype match implementation [10:15:25 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:7b8901571504: Merge commit 'c778eb15b89d875cb246b18f65b3b4321cb1e7d6' [10:17:45 CEST] <ubitux> these commits are weird [10:19:35 CEST] <ubitux> because they do not touch the declared prototypes for asm& [10:19:37 CEST] <ubitux> but anyway. [10:20:28 CEST] <cone-056> ffmpeg 03Diego Biurrun 07master:6354957a9502: dnxhdenc: Have function pointer prototype match implementation [10:20:29 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:77248d121812: Merge commit '6354957a95022864746180525680cca872ab0e0a' [10:27:32 CEST] <mateo`> wm4: hello, regarding the port of the examples to the new api, can you confirm it is ok to assume that the first call to send_packet will *always* succeed (unless an error happens or the codec is flushed), then I can loop on receive_frame until EAGAIN and then goes back to reading the next packet and continue (still assuming send_packet won't return EAGAIN because receive_frame previously returned [10:27:34 CEST] <mateo`> EAGAIN) ? [10:28:22 CEST] <cone-056> ffmpeg 03Diego Biurrun 07master:99434f4df81b: float_dsp: Have implementation match function pointer prototype [10:28:23 CEST] <cone-056> ffmpeg 03Diego Biurrun 07master:67351924fa91: Drop unreachable break and return statements [10:28:24 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:f291a9a1adab: Merge commit '99434f4df81b6801b2b535d5b9143305595784f6' [10:28:25 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:03f5e80bdbbf: Merge commit '67351924fa91dea4339109100a4c0689f006581f' [10:29:32 CEST] <ubitux> jkqxz: we're at the hwmap commit [10:29:39 CEST] <ubitux> do you want to merge it? [10:32:22 CEST] <mateo`> wm4: it seems to be the case, but I've been traumatized by the MediaCodec api that does not provide such guarantees [10:32:54 CEST] <ubitux> jkqxz: looks like it applies mostly cleanly so i'll probably apply blindly [10:36:34 CEST] <ubitux> how can i test that hwmap filter? [10:36:57 CEST] <ubitux> there is no doc/test :( [10:39:01 CEST] <cone-056> ffmpeg 03Mark Thompson 07master:d06aa24ba583: hwcontext: Hardware frame mapping [10:39:02 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:4cda23f1f146: Merge commit 'd06aa24ba583ad08025da9e1b29afcd8218ff9b0' [10:49:34 CEST] <wm4> mateo`: yes, ffmpeg.c relies on it [10:49:50 CEST] <mateo`> wm4: ok, thanks [10:53:11 CEST] <cone-056> ffmpeg 03Mark Thompson 07master:124e26971e69: lavfi: Hardware map filter [10:53:12 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:6234fd2fa012: Merge commit '124e26971e69bb25f38c6c7cb3fa20c77cf10966' [10:56:57 CEST] <cone-056> ffmpeg 03Mark Thompson 07master:8ad9f9d675ea: hwcontext_vaapi: Frame mapping support [10:56:58 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:71c22fb7aec9: Merge commit '8ad9f9d675eab139aa2208722009eeed981460dd' [10:57:36 CEST] <cone-056> ffmpeg 03Martin Storsjö 07master:392caa65df3e: arm: vp9mc: Insert a literal pool at the middle of the file [10:57:36 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:aa7976fd1550: Merge commit '392caa65df3efa8b2d48a80f08a6af4892c61c08' [11:03:37 CEST] <cone-056> ffmpeg 03Martin Storsjö 07master:d1ef1b9eaa45: configure: Silence lld-link when getting the version number [11:03:38 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:8524b0162f01: Merge commit 'd1ef1b9eaa45043ea5df5a004fb37243e05da61d' [11:05:49 CEST] <cone-056> ffmpeg 03Diego Biurrun 07master:3cba09e5228c: x86: Drop stray semicolons after function definitions [11:05:50 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:80f91c8d5a6f: Merge commit '3cba09e5228c889d63814dc43bc68f15c9dbac77' [11:08:46 CEST] <cone-056> ffmpeg 03Derek Buitenhuis 07master:db0b3dccb384: libx265: Add option to force IDR frames [11:08:47 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:03f22c288aff: Merge commit 'db0b3dccb3842de134721e8d5c275f56d384340d' [11:11:35 CEST] <cone-056> ffmpeg 03Hendrik Leppkes 07master:fabfbfe57100: dxva2: fix surface selection when compiled with both d3d11va and dxva2 [11:11:36 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:46998d037f8b: Merge commit 'fabfbfe5710050812147f93a351a53fdda56ff8c' [11:12:34 CEST] <ubitux> i need someone to merge the next commits [11:12:43 CEST] <ubitux> nevcairiel: can you do those? dxva2 etc [11:14:13 CEST] <nevcairiel> they should just apply as-is i would think [11:14:21 CEST] <nevcairiel> but i can otherwise do them a bit later [11:16:20 CEST] <ubitux> no the files are different [11:16:37 CEST] <ubitux> well, actually, it applies cleanly [11:17:01 CEST] <ubitux> but files are quite different [11:17:14 CEST] <ubitux> the second one clashes [11:17:34 CEST] <ubitux> i'm not confident in blindly merging this [11:17:42 CEST] <nevcairiel> we're probably in some odd state where we backported half their things [11:18:24 CEST] <ubitux> (ETA: 682) [11:30:54 CEST] <nevcairiel> wm4: threaded hwaccel decoding of vp9 is still broken for me, wasnt this supposed to work now [11:32:12 CEST] <BtbN> threaded hwaccel decoding sounds weird to begin with [11:32:28 CEST] <BtbN> Do the hwaccel APIs support that? [11:32:38 CEST] <BtbN> Or does it just automatically limit itself to one thread? [11:32:42 CEST] <wm4> nevcairiel: I think so [11:32:53 CEST] <wm4> BtbN: yes [11:33:17 CEST] <nevcairiel> I get a lot of "Operation not permitted" spam and 90% of the frames have the same hash (using framemd5) [11:33:28 CEST] <nevcairiel> threads 1 and it works [11:39:22 CEST] <cone-056> ffmpeg 03Anton Khirnov 07master:910973765417: hwcontext_dxva2: frame mapping support [11:39:23 CEST] <cone-056> ffmpeg 03Anton Khirnov 07master:10065d9324c2: hwcontext_dxva2: add support for the P8 format [11:39:24 CEST] <cone-056> ffmpeg 03Hendrik Leppkes 07master:9ca5d2de5d14: Merge commit '910973765417f06a4a9ccbd006e4df74c32ecb01' [11:39:25 CEST] <cone-056> ffmpeg 03Hendrik Leppkes 07master:14764b93e282: Merge commit '10065d9324c2e35ce7040b6a2b9ebf6079bcbf42' [11:39:38 CEST] <nevcairiel> ubitux: done [11:48:09 CEST] <wm4> nevcairiel: how to reproduce? does it work with h264? [11:55:24 CEST] <nevcairiel> h264 seems fine [11:56:31 CEST] <ubitux> nevcairiel: thx :) [11:56:46 CEST] <nevcairiel> I tested with this clip https://files.1f0.de/encodes/tos3k-vp9-b5000.webm and an ordinary ffmpeg -hwaccel dxva2 -i <> -f framemd5 - [11:57:31 CEST] <ubitux> if you want to do the qsv ones too btw... [11:57:42 CEST] <ubitux> i can't test them either [12:09:03 CEST] <nevcairiel> i dont have an intel gpu really setup either [12:09:46 CEST] <BtbN> I'd guess my Laptop has that. But no idea how to utilize it. [12:10:22 CEST] <BtbN> Those libmfx wrappers are confusing [12:25:12 CEST] <wm4> durandal_1707: don't you like to add fringe formats? OSX icns files are apparently not supported by ffmpeg [12:25:24 CEST] <wm4> it's Apple's .ico I guess [12:25:37 CEST] <wm4> appears to contain PNGs [12:25:56 CEST] <durandal_1707> awesome [12:26:12 CEST] <durandal_1707> format of fotmats [12:26:40 CEST] <PaoloP> wm4, ubitux and others: I made the changes you told me to the API usage snippet. It should be ok: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209385.html . Hope you can accept it so I can add other examples [13:26:26 CEST] <cone-056> ffmpeg 03Leo Izen 07master:744916908167: avformat/nut: Add HEVC and Opus support [13:51:28 CEST] <ubitux> BBB: are you going to add AVCOL_PRI_JEDEC_P22 to colorspace? [13:51:45 CEST] <BBB> probably? although adding crazy new stuff is more kodas thing [13:52:36 CEST] <BBB> did we merge a patch changing the hevcpred interface? [13:52:40 CEST] <BBB> (re: that mips patch) [13:52:56 CEST] <ubitux> yeah i may have broke it [13:53:06 CEST] <ubitux> i need to check [13:53:08 CEST] <ubitux> PaoloP: you're missing the build of the example through the build system (needs update in configure and doc/Makefile) [13:53:22 CEST] <ubitux> PaoloP: you should rebase on upstream, some changes in the examples recently went it [13:53:31 CEST] <ubitux> also update the .gitignore of the examples [13:53:43 CEST] <ubitux> replace ++x with x++, you're not doing c++ [13:53:59 CEST] <ubitux> you should wrap a little the long lines too [13:54:47 CEST] <BBB> I think theyre including the wrong header [13:54:49 CEST] <BBB> ohwell [14:00:35 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:b22c4d822b33: doc/codecs: add jedec-p22 [14:06:07 CEST] <ubitux> BBB: btw i think your initial patch fixing the checkheader was more correct [14:06:25 CEST] <ubitux> i assumed you were supposed to skip the header, but if you have vda, you shouldn't [14:06:25 CEST] <BBB> I didnt push anything yet did I? [14:06:43 CEST] <BBB> ubitux: I dont know the intention, I wish the vda people would respond ;) [14:07:05 CEST] <BBB> (Sebastian Zwickert) [14:11:09 CEST] <BBB> I thought he was on IRC at some point [14:11:14 CEST] <BBB> does anyone remember his nickname? [14:32:02 CEST] <wm4> atomnuker: didn't you say you had remarks about the new bitstream API to Libav? they say they aren't aware of any [14:32:50 CEST] <wm4> <atomnuker> BBB: they ignored my small tiny request as well [14:34:07 CEST] <BBB> I asked for a bunch of things [14:34:18 CEST] <BBB> its always easiest to say youre not aware of it, because then you can just commit it [14:34:39 CEST] <BBB> ;) [14:34:42 CEST] <wbs> BBB: trolling aside, this last comment also is just dismissive [14:34:43 CEST] <wbs> fwiw [14:34:54 CEST] <BBB> wbs: it is, but Im getting kind of tired [14:35:01 CEST] <wbs> BBB: sure [14:35:06 CEST] <BBB> wbs: Ive tried for a while to be helpful towards bringing the projects together [14:35:13 CEST] <BBB> Im tired of it [14:35:18 CEST] <wbs> sure [14:35:35 CEST] <BBB> so yes, Ive gotten dismissive. I hope someone else can still do it, its the right thing to do - but it wont be me [14:35:50 CEST] <j-b> I know most of you don't care, but everyone here could make a lot of money, instead of fighting... [14:35:59 CEST] Action: BBB hugs j-b [14:36:08 CEST] <wbs> BBB: I just try to keep the dismissing factual instead of emotional :P [14:36:10 CEST] <j-b> and, by a lot, I mean a lot. [14:36:18 CEST] <ubitux> what if we already make a lot of money? :s [14:36:27 CEST] <BBB> wbs: I did ask for things, thats not emotional [14:36:28 CEST] <j-b> well, I know your boss, and you don't. [14:36:51 CEST] <j-b> BBB: do you have the list of things somewhere? [14:37:16 CEST] <wm4> <DonDiego> ronald had some comments in the beginning, then he disappeared [14:37:25 CEST] <wbs> BBB: yes, that's true. what wm4 said before was people actually searching to find which particular request that was ignored in his case [14:37:34 CEST] <wbs> BBB: (for atomnuker's request) [14:37:56 CEST] <BBB> I dont know what atomnukers request was& lets wait for him to respond [14:38:11 CEST] <wbs> BBB: exactly. then don't pretend that "they know it, they just ignored it on purpose" [14:38:30 CEST] <BBB> ok [14:39:00 CEST] <wm4> <DonDiego> i don't remember any changes he requested that were not implemented (do not remember != do not exist) [14:39:30 CEST] <wm4> so from my perspective it looks like at _worst_ stuff was forgotten/overlooked (with no ill intent) [14:44:10 CEST] <mateo`> wm4: the filtering_{audio,video} examples do not take care of flushing the decoders (as well as the filter graph), is the patch still ok for you ? [14:44:31 CEST] <mateo`> and we should add the flushing code in a separate commit [14:44:43 CEST] <wm4> mateo`: yeah... that's bad for an example, so that should be done (or at least a warning against it) [14:46:51 CEST] <mateo`> are you ok if we do that in a separate patch ? [14:47:11 CEST] <wm4> yes [14:47:27 CEST] <wm4> absolutely... just because it updates the API use, it doesn't need to make the example perfect [14:48:04 CEST] <atomnuker> BBB: I asked luca if all functions may be clearly labeled whether they read or write [14:48:09 CEST] <atomnuker> most were, but some were not [14:48:43 CEST] <wm4> so was it like that before, or he honored your request, but incompletely? [14:48:56 CEST] <atomnuker> no, it was like that before [14:49:25 CEST] <atomnuker> also the function names are too long [14:49:46 CEST] <atomnuker> bitstream is 9 chars [14:50:06 CEST] <ubitux> should use "bs" [14:50:10 CEST] <BtbN> building with mingw sureis slow [14:50:14 CEST] <atomnuker> or better yet "get_bits" [14:50:26 CEST] <ubitux> BS is better [14:50:33 CEST] <j-b> BtbN: and WSL [14:50:36 CEST] <wm4> atomnuker: they don't hear/read that [14:51:10 CEST] <BtbN> j-b, hm? I'm comparing to cygwin gcc. And it takes several magnitudes longer. [14:51:11 CEST] <nevcairiel> configure with mingw is slow, the build after that is fine [14:51:26 CEST] <BBB> I agree that bitstream_*() is stupidly long [14:51:33 CEST] <mateo`> ubitux: i like bs :D [14:51:36 CEST] <ubitux> ;) [14:51:54 CEST] <BtbN> nevcairiel, what I mean is, mingw gcc is even slower than cygwin gcc. [14:51:59 CEST] <ubitux> no one wants to merge the qsv commits? [14:52:03 CEST] <ubitux> should i blind them? [14:52:18 CEST] <BtbN> I should be able to at least test them soon [14:52:22 CEST] <BtbN> once this build finishes [14:52:32 CEST] <nevcairiel> if you target building for windows, isnt that basically the same compiler then [14:52:40 CEST] <nevcairiel> cygwin uses mingw afterall to make windows binaries [14:52:48 CEST] <BtbN> targeting mingw from cygwin is a cross-compile for configure. [14:54:05 CEST] <j-b> BtbN: WSL is fast, for me. [14:54:12 CEST] <BtbN> What even is WSL? [14:54:26 CEST] <j-b> Windows Subsystem for Linux [14:54:31 CEST] <j-b> aka Linux on Windows. [14:54:38 CEST] <wm4> you'd have to cross-compile in that [14:54:46 CEST] <BtbN> oh, that. Doesn't integrate the same way Cygwin does. [14:54:55 CEST] <BtbN> You can't access the Host-OS from it. [14:55:03 CEST] <nevcairiel> define "access" [14:55:07 CEST] <nevcairiel> you can access the file system [14:55:12 CEST] <nevcairiel> and its kinda the same OS [14:55:17 CEST] <j-b> and you can call both Linux and Win32 exe [14:55:17 CEST] <nevcairiel> its not like its a VM [14:55:25 CEST] <nevcairiel> calling win32 exe is new though [14:55:31 CEST] <nevcairiel> j-b must be on insider builds [14:55:38 CEST] <j-b> nevcairiel: RS2 is RTM. [14:55:47 CEST] <j-b> release is in 12 days. [14:55:53 CEST] <j-b> not really insider, tbh. [14:55:55 CEST] <nevcairiel> RTM perhaps, but until it releases the build will still change a bit [14:56:06 CEST] <j-b> I doubt it. [14:56:13 CEST] <nevcairiel> they have never released a RTM as-is [14:56:19 CEST] <BtbN> Can I build a WSL-ffmpeg and call it from normal windows processes? [14:56:21 CEST] <j-b> the nightly builds have moved to RS3 already [14:56:21 CEST] <nevcairiel> always a couple update rollups on top [14:56:23 CEST] <j-b> BtbN: yes. [14:56:47 CEST] <BtbN> So you can actually call ELF binaries from Windows now? [14:56:51 CEST] <j-b> BtbN: either by calling gcc.exe or by cross-compiling with mingw-w64 [14:57:00 CEST] <j-b> BtbN: inside the bash shell, yes. [14:57:08 CEST] <nevcairiel> not exactly, you can run bash.exe which can then execute ELF binaries [14:57:14 CEST] <j-b> a Windows.exe cannot call an ELF binary. [14:57:16 CEST] <BtbN> hm, that's still not too useful then [14:57:21 CEST] <nevcairiel> why not [14:57:27 CEST] <nevcairiel> just script everything inside the bash.exe [14:57:31 CEST] <wm4> lol MS [14:57:32 CEST] <nevcairiel> it can call both ELF and win32 [14:57:33 CEST] <BtbN> Because it's not transparent for normal applications [14:57:38 CEST] <j-b> normal applications? [14:57:47 CEST] <j-b> just build a ffmpeg.exe in the bash [14:57:48 CEST] <nevcairiel> its a developer tool either way [14:57:55 CEST] <nevcairiel> not something for applications to use [14:57:58 CEST] <j-b> once built, it's a normal application [14:58:13 CEST] <wm4> nevcairiel: hwaccel threading with dxva2 works for me [14:58:16 CEST] <BtbN> I'm using cygwin was my system shell. Not as a build tool [14:58:20 CEST] <nevcairiel> wm4: with my sample on vp9? [14:58:26 CEST] <wm4> framemd5 output is the same for threads=1 and =32 [14:58:35 CEST] <wm4> I tried some random vp9 sample [14:59:04 CEST] <PaoloP> ubitux: ok. I'm going to make the changes you said. [14:59:20 CEST] <j-b> BtbN: so what? WSL can call normal applications and ELF ones [14:59:28 CEST] <wm4> PaoloP: I think your code would still profit from moving some things to functions [14:59:36 CEST] <wm4> PaoloP: also dropping the custom I/O [14:59:52 CEST] <BtbN> j-b, but I have also a lot of applications calling into cygwin binaries which [14:59:56 CEST] <wm4> PaoloP: also not sure why you use the resampler [15:00:14 CEST] <BtbN> +wouldn't work if they weren't normal .exe files they can blindly execute [15:00:21 CEST] <wm4> nevcairiel: did you probably try before the async_mutex fix [15:00:22 CEST] <j-b> cygwin binaries? what is that? [15:00:28 CEST] <nevcairiel> wm4: todays git master [15:00:28 CEST] <j-b> it's either win32 or not. [15:00:36 CEST] <BtbN> binaries linked against cygwin.dll [15:00:38 CEST] <nevcairiel> when i was merging the dxva changes above [15:00:57 CEST] <BtbN> built with cygwin gcc [15:00:59 CEST] <wm4> nevcairiel: I tried with current git master [15:01:10 CEST] <wm4> b22c4d822b3315449ebb975a691f36933c14a00b [15:01:28 CEST] <nevcairiel> can you try my clip? it shouldnt be in any way special, i encoded it with vpx a couple years ago myself [15:01:31 CEST] <wm4> (uh what exactly is the P8 format needed for?) [15:01:38 CEST] <wm4> nevcairiel: I think I didn't get a link... [15:01:47 CEST] <nevcairiel> https://files.1f0.de/encodes/tos3k-vp9-b5000.webm [15:01:58 CEST] <nevcairiel> i linked it earlier, but hey =p [15:02:08 CEST] <nevcairiel> ffmpeg -hwaccel dxva2 -i <> -f framemd5 - [15:02:11 CEST] <nevcairiel> just fails [15:02:13 CEST] <wm4> oh indeed, I just didn't see it [15:02:15 CEST] <nevcairiel> adding -threads 1 works [15:02:40 CEST] <nevcairiel> working with a 1080 GTX, not like that should matter [15:02:58 CEST] <nevcairiel> vp9 8-bit is present in all the 1000 series [15:03:07 CEST] <wm4> I only have Intel here... wait does this shit even support vp9 [15:03:23 CEST] <nevcairiel> depends how new it is [15:03:25 CEST] <PaoloP> wm4: about the resampler, I'm using it because frames are read from a raw file, so they are necessarily not planar, and the format required by the aac encoder is planar. [15:03:27 CEST] <wm4> no it doesn't [15:03:31 CEST] <wm4> nevcairiel: well that explains it [15:03:47 CEST] <wm4> PaoloP: so why read it from a file, instead of generating it? [15:03:49 CEST] <nevcairiel> i can try to look into it later, might be a bug in the vp9 code [15:04:00 CEST] <nevcairiel> i know this sample worked once upon a time [15:04:05 CEST] <nevcairiel> so i can bisect, i guess [15:04:05 CEST] <wm4> just to be sure I'll retry the test with h264 [15:04:18 CEST] <nevcairiel> (its my fallback vp9 generic test) [15:04:56 CEST] <nevcairiel> maybe the recent vp9 cahnges did break it instead of the threading things [15:05:06 CEST] <BtbN> Which sample are you trying? I might be able to test it with qsv [15:05:22 CEST] <PaoloP> wm4: because it's much better for the user, so they can adapt the code to a custom source of frames, and it's very useful if the source is a live one (I have a program which grabs frames from a microphone with alsa, and the snippet can be used for encoding that frames) [15:05:46 CEST] <nevcairiel> it requires an actual hwaccel to test [15:05:50 CEST] <nevcairiel> so frame threading is used [15:05:52 CEST] <nevcairiel> qsv doesnt do that [15:06:13 CEST] <BtbN> Doesn't qsv integrate with the normal h264 hwaccel? [15:06:22 CEST] <wm4> no [15:06:49 CEST] <wm4> although you can feed the qsv encoder dxva2 frames etc. [15:06:56 CEST] <wm4> which jkqxz's work achives AFAIK [15:07:16 CEST] <PaoloP> wm4: same thing about the custom I/O: I used it for sending the muxed frames to a http streamer made with other libs (libevent, in my case) [15:07:35 CEST] <wm4> PaoloP: custom I/O should probably be a separate, simpler example [15:07:52 CEST] <nevcairiel> thats really the best rule for any examples [15:08:04 CEST] <nevcairiel> one mega-example that showcases all the features at once is often not very helpful [15:08:21 CEST] <nevcairiel> rather have small individual examples and the user can then cherry-pick the code they want into their project [15:08:32 CEST] <PaoloP> wm4: there's already one. In my case, i created an examnple which exposes all the containers to the user: input frame, resampled frame, encoded packet and muxed data [15:09:22 CEST] <nevcairiel> BtbN: qsv is implemented like cuvid, an actual separate decoder [15:10:05 CEST] <BtbN> strange, it doesn't show up as decoder for me, but only as hwaccel [15:10:09 CEST] <PaoloP> nevcairiel: I see, but consider that the snippet I provided includes reading from a custom source + resampling + encoding + muxing with custom I/O all put only in 270 lines [15:10:28 CEST] <nevcairiel> short isnt necessarily a good property of examples either =p [15:11:28 CEST] <nevcairiel> they should showcase how to use the API [15:11:42 CEST] <nevcairiel> a bit more verbose if it helps to understand [15:11:51 CEST] <PaoloP> nevcairiel: I see, but all these tasks are covered and they can be easily separated/adapted to other codecs/muxer. I decided to use the adts because it covers all these tasks [15:11:52 CEST] <wm4> BtbN: where? [15:11:59 CEST] <wm4> nevcairiel: all fine for h264 [15:12:08 CEST] <BtbN> in configure output [15:12:10 CEST] <wm4> I don't know if ffmpeg.c used hw decoding for that though [15:12:11 CEST] <nevcairiel> wm4: yeah h264 worked for me as well [15:12:15 CEST] <wm4> because it doesn't say [15:12:21 CEST] <PaoloP> and they are strictly sequential [15:12:23 CEST] <nevcairiel> check if the output format is nv12 [15:12:29 CEST] <BtbN> The ffmpeg.exe it built refuses to print any textual output though [15:12:30 CEST] <wm4> BtbN: the qsv decoders still need to expose AVHWAccels [15:12:41 CEST] <wm4> BtbN: but that's only because of I don't know why [15:12:52 CEST] <BtbN> same reason as cuvid I'd assume [15:13:33 CEST] <wm4> yeah, ff_get_format [15:13:38 CEST] <wm4> (but that part could be removed) [15:14:00 CEST] <PaoloP> nevcairiel: it showcases of to use the api in all the main tasks. [15:18:51 CEST] <nevcairiel> peloverde: I got a LATM AAC sample with PCEs, which apparently wasnt handled much in the decoder before, does this look extremely terrible? https://pastebin.com/gAkgv7k5 (sample https://files.1f0.de/samples/arte_HD_Test.ts, from german DVB-T2) [15:20:23 CEST] <jkqxz> ubitux: I can do QSV merge later today, if you can wait. [15:20:59 CEST] <ubitux> please do :) [15:21:01 CEST] <ubitux> thanks :) [15:21:24 CEST] <mateo`> jkqxz: can I push a patch ? (or you have already started the merge process) [15:22:21 CEST] <jkqxz> Go ahead, I'm not doing anything yet. [15:22:41 CEST] <cone-056> ffmpeg 03Matthieu Bouron 07master:afd257b43feb: doc/examples/filtering_video: switch to new decoding API [15:22:42 CEST] <cone-056> ffmpeg 03Matthieu Bouron 07master:03372d0a90c0: doc/examples/filtering_audio: switch to new decoding API [15:27:12 CEST] <jkqxz> nevcairiel: Errors like that sound more like collision of the decoder using reference frames with the readback, rather than inside the codec? (Some dxva2 drivers having problems with multiple readers at once.) [15:27:38 CEST] <nevcairiel> the hw calls would fail then, and those log specific messages [15:27:41 CEST] <nevcairiel> didnt see any of that [15:28:25 CEST] <jkqxz> I did try VP9 threaded hwaccel for <http://git.videolan.org/?p=ffmpeg.git;a=commit;h=9560766a6164ed362e7f274242…>, and it was fine there. [15:28:42 CEST] <jkqxz> I'll test your sample later, though. [15:28:55 CEST] <nevcairiel> i can try to bisect [15:29:03 CEST] <nevcairiel> i think vp9dec was refactored a bit last week [15:29:07 CEST] <nevcairiel> maybe something broke [15:29:29 CEST] <wm4> jkqxz: on windows or vaapi? [15:29:33 CEST] <jkqxz> Right, that's also possible. [15:29:43 CEST] <nevcairiel> anyway this w hole async safe business was supposed to avoid the multipler readers problem [15:29:46 CEST] <jkqxz> That was VAAPI. I don't have any Windows VP9 hardware. [15:30:04 CEST] <j-b> jkqxz: do you want one? [15:30:14 CEST] <wm4> nevcairiel: yes the approach is making any access exclusive to one thread [15:30:55 CEST] <jkqxz> Wasn't it only doing that in the decoder? What people do with the surfaces after that is not something we can restrict. [15:31:27 CEST] <wm4> jkqxz: no, globally (that's why it used async_mutex as "inverse" lock) [15:31:34 CEST] <nevcairiel> as long as they dont multi-thread, it should be fine [15:31:47 CEST] <nevcairiel> (ie. only use it on the same thread they call the decode API on) [15:32:23 CEST] <jkqxz> Right, yes, sorry. It only accesses the reference frames while inside the lavc calls. [15:35:26 CEST] <jkqxz> j-b: One what? (I could put Windows on existing stuff I have, it's just rather inconvenient.) [15:36:47 CEST] <jkqxz> Wrt comment above about qsvdec, one of my aims with the device/mapping stuff is to kill the qsv decoder entirely and replace it with platform hwaccel + mapping. [15:37:08 CEST] <jkqxz> (Not sure who that comment is aimed at, but wm4 mentioned it...) [15:40:17 CEST] <stevenliu> Hello wm4 can i move the strreplace into the libavutil if the original author agreed [15:40:28 CEST] <wm4> stevenliu: sure [15:40:33 CEST] <ubitux> jkqxz: speaking of hwmap, please confirm that it works when you have time, i couldn't test it [15:40:54 CEST] <stevenliu> or must under apache ,mit license? [15:42:16 CEST] <stevenliu> ok , thanks :) [15:44:15 CEST] <wm4> stevenliu: whatever the author agreed to [15:44:23 CEST] <wm4> I think apache would be incompatible though [15:44:51 CEST] <wm4> (and moving to libavutil is just my opinion - it's probably not absolutely required) [15:45:53 CEST] <stevenliu> Your think is maybe good, that function maybe a universal. [16:04:24 CEST] <rcombs> wm4: stevenliu: iirc the original is public domain, so it can be relicensed under LGPL just fine [16:04:45 CEST] <rcombs> original author's permission never hurts, though (particularly since public domain doesn't exist in all countries) [16:05:32 CEST] <wm4> if there was such a statement on the website I found I missed it [16:06:02 CEST] <stevenliu> yes , there is [16:06:22 CEST] <stevenliu> Author: Me (Laird Shaw). Licence: Public domain. Attribution: Optional. If you choose to indicate attribution when using this function, feel free to link to this page. [16:08:35 CEST] <rcombs> should it be av_ or avpriv_? [16:08:54 CEST] <rcombs> the API is reasonably simple, so av_strreplace seems reasonable [16:09:11 CEST] <nevcairiel> dont create new avpriv stuff [16:09:23 CEST] <nevcairiel> if something is deemed useful, make it public [16:09:26 CEST] <nevcairiel> otherwise its not useful =p [16:09:45 CEST] <rcombs> reasonable enough [16:09:59 CEST] <stevenliu> OK, av_strreplace [16:10:29 CEST] <stevenliu> move it to libavutil/avstring.c, ok? [16:10:35 CEST] <rcombs> sounds good [16:40:14 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:8779ec91b223: avformat/mux: Check return code of av_packet_split_side_data() [16:40:15 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:004f27f0fb6e: ffmpeg: Fix avframe memleak [16:40:15 CEST] <stevenliu> done [16:40:16 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:59b8c2a4e668: doc/examples/encode_audio: Favor a sample rate close to 44khz instead of the maximum sample rate [16:46:51 CEST] <jkqxz> ubitux: Simple cases of hwmap work (drawtext on mapped hardware frames, hardware decode and map for encode). I'll look at it more carefully later when doing qsv. [16:52:39 CEST] <ubitux> jkqxz: it would be nice to have some doc for the filter btw :) [16:59:13 CEST] <rcombs> hmm, I guess vf_overlay on hwmapped frames for bitmap subs would probably be faster or slower than doing download->overlay->upload [17:03:47 CEST] <wm4> rcombs: wouldn't it have to upload only a small part of the frame [17:03:55 CEST] <jkqxz> Depends how much you do. On Intel mapping gives you uncached memory so reading (for alpha blend, say) is a disaster. If you only write, or only work with a little bit of the frame, then it's good. [17:04:14 CEST] <rcombs> yeah, it's alpha-blend [17:04:24 CEST] <wm4> I thought we didn't need uncached memcpy on intel? [17:05:09 CEST] <serhii> Hello! I got error message "Your FFProbe version is too old and does not support `-help` option, please upgrade." How can I upgrade it? In linux apt update shows this is latest version [17:05:53 CEST] <wm4> serhii: install a better idstro [17:05:56 CEST] <wm4> *distro [17:06:30 CEST] <jkqxz> wm4: That was because it uses the GPU-driven copy there. That's also doable here, but it's a whole-frame download/upload anyway. [17:09:21 CEST] <serhii> what is distro? [17:09:49 CEST] <rcombs> it's generally all the same physical RAM, right? [17:10:23 CEST] <rcombs> I don't really have a great understanding of how the memory handling works here, e.g. why we can't map that same region as normally-cached [17:12:21 CEST] <wm4> serhii: something that doesn't ship a ffmpeg which is probably a decade old [17:13:37 CEST] <PaoloP> in case 1) I send a patch 2) some_user replies suggesting modifications 3) I do the modifications and I have to send both the new patch + a text (in the mail) which replies to some_user's observations, should I send two emails (one with the patch and one with my answer) or only one email? [17:50:18 CEST] <ubitux> this time_base thing needs to be fixed before any release [17:50:32 CEST] <ubitux> it's undocumented and probably conflicting with lavc settings [17:51:05 CEST] <wm4> which time_base thing (weren't there several issues) [17:51:21 CEST] <ubitux> the thing i just ping'ed on ffmpeg-devel [17:51:23 CEST] <ubitux> about 3ac46a0a62386a52e38c066379ff36b5038dd4d0 [17:51:34 CEST] <ubitux> conflicting with at least lavc [17:53:16 CEST] <wm4> hm don't see any mail [17:54:06 CEST] <ubitux> i only see the reply from michael [17:54:10 CEST] <ubitux> (ni) [17:54:29 CEST] <ubitux> oh you're refering to mine [17:54:41 CEST] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209426.html [17:55:07 CEST] <wm4> ah my mail reader just fetched it [17:57:49 CEST] <ubitux> also, should we revert the jpeg thing? [17:58:06 CEST] <ubitux> it's at least crashing openbsd [17:59:11 CEST] <wm4> (don't know what this refers to either) [18:00:43 CEST] <ubitux> wm4: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209103.html [18:01:18 CEST] <wm4> can the author be asked to fix it? [18:02:05 CEST] <ubitux> atomnuker: can you contact that guy? [18:04:48 CEST] <durandal_1707> can you fix it? [18:06:02 CEST] <BBB> ubitux: is that the patch that also had valgrind/asan warnings? [18:06:44 CEST] <wm4> if the author doesn't react and nobody can/wants to fix it, reverting would be reasonable [18:07:22 CEST] <kierank> wm4: far too much common sense [18:07:41 CEST] <kierank> michaelni: do you know how long clusterfuzz takes to react [18:07:48 CEST] <kierank> these h264 changes make me nervous [18:07:50 CEST] <kierank> esp with sliced threads [18:08:10 CEST] <ubitux> BBB: yes [18:08:28 CEST] <ubitux> valgrind/asan errors + openbsd crashes [18:08:36 CEST] <BBB> kierank: I can do more testing with slice threads if you want [18:08:48 CEST] <ubitux> (it's been 2 weeks now) [18:08:49 CEST] <kierank> I will fire up some fuzz machines at work tonight [18:08:52 CEST] <BBB> kierank: Im trying to make it more secure, not less [18:09:04 CEST] <kierank> I mean the merge itself is the problem [18:09:05 CEST] <BBB> ubitux: then revert, IMO [18:09:07 CEST] <kierank> the libav stuff [18:09:10 CEST] <BBB> oooo sorry [18:09:11 CEST] <kierank> not the fixes [18:09:14 CEST] <BBB> I thought you meant my stuff [18:09:16 CEST] <BBB> yes, agreed [18:10:55 CEST] <atomnuker> ubitux: he still hasn't responded, I'll try to fix it tonight [18:11:01 CEST] <michaelni> kierank, i saw it react within 24h i think to fixes being pushed [18:11:20 CEST] <kierank> ok, then frame threads should be tested, i will do slice threads [18:31:14 CEST] <michaelni> gcc: Internal error: Killed (program cc1) [18:31:15 CEST] <michaelni> common.mak:60: recipe for target 'libavcodec/h264qpel.o' failed [18:32:08 CEST] <michaelni> doesnt reproduce of course [18:32:37 CEST] <BBB> I believe after the vp9 split, h264qpel.o is the largest object file in libavcodec/ [18:32:48 CEST] <BBB> maybe its related to that? [18:32:54 CEST] <michaelni> yes, that makes sense [18:32:57 CEST] <BBB> (full HD, or whatever) [18:33:02 CEST] <BBB> (or OOM) [18:33:08 CEST] <michaelni> that was on a openbsd VM, with limited memory [18:33:16 CEST] <BBB> probably OOM then [18:33:19 CEST] <michaelni> yes [18:46:26 CEST] <michaelni> ubitux, btw vsynth1-ljpeg doesnt segfault if i run it manually on openbsd [19:17:32 CEST] <BBB> michaelni: is |= a good way to retain specific AVERROR(errno) values? [19:17:42 CEST] <BBB> michaelni: maybe its better to just store the first negative and then return? [19:17:53 CEST] <BBB> michaelni: (re:clearvideo) [19:18:36 CEST] <michaelni> if we return after the first iam not sure if that leaves uninitialized blocks [19:24:41 CEST] <BBB> Im no clearvideo expert and probably shouldnt be ;-) [19:24:51 CEST] <BBB> maybe the loop can continue but we dont or the return of _mb [19:25:23 CEST] <BBB> if one mb returns -3 and the other -4, the frame function returns -1 [19:25:26 CEST] <BBB> I dont think thats wanted [19:26:22 CEST] <michaelni> no, the |= is ugly but it was there before [19:26:44 CEST] <michaelni> ill fix that [19:28:07 CEST] <BBB> tnx :) [19:45:42 CEST] <thebombzen> the ffv1 spec at: https://www.ffmpeg.org/~michael/ffv1.html appears to be missing mathjax [19:47:10 CEST] <thebombzen> is this intentional [19:48:13 CEST] <thebombzen> it looks like it uses MathHTML but that doesn't seem to be as effective as MathJax (which is what Wikipedia and StackExchange use, afaik) [19:48:37 CEST] <thebombzen> also it lists the email as michaelni at gmx dot at [19:49:03 CEST] <nevcairiel> thats likely intentional to avoid spam =p [19:52:15 CEST] <thebombzen> no I mean [19:52:18 CEST] <thebombzen> it listes the actual email [19:52:23 CEST] <thebombzen> but that's not michael's email [19:52:37 CEST] <thebombzen> it might have used to have been [19:53:04 CEST] <thebombzen> but yea, it appears the LaTeX code doesn't render at all in Chromium but does render in Firefox, but incorrectly [19:53:05 CEST] <thebombzen> https://i.imgur.com/RqJMiOk.png [19:53:28 CEST] <thebombzen> this is not really a surprise, because the code at the top mentions Gecko [19:54:06 CEST] <michaelni> thebombzen, about math markup, dave rice was working related stuff in the ffv1 text, you likely want to talk with him [19:54:26 CEST] <thebombzen> okay [19:54:45 CEST] <michaelni> also i need to update that file, formating was changed recently [19:56:51 CEST] <thebombzen> ah yes, it appears that way from "make ffv1.html" [19:58:03 CEST] <michaelni> file updated from git [20:04:22 CEST] <thebombzen> michaelni: you probably also have to push style.css [20:04:37 CEST] <thebombzen> which currently is not there and referenced by ffv1.html [20:06:45 CEST] <atomnuker> thebombzen: mathjax is the worst choice you can make [20:06:57 CEST] <thebombzen> why [20:06:59 CEST] <atomnuker> its javascript outputting svg [20:07:14 CEST] <thebombzen> well it works, and what's currently happening doesn't [20:07:15 CEST] <atomnuker> you should just compile it on your machine, it spits out svg and you embed that in [20:07:34 CEST] <thebombzen> the whole point of mathjax is you don't have to do that [20:07:36 CEST] <atomnuker> mathml is the best choice the problem is the bastards working on chrome hate it [20:07:59 CEST] <thebombzen> MathML not only doesn't work but it's XML [20:08:05 CEST] <atomnuker> they'd rather have an entire javascript infrastructure you have to download over and over again [20:08:15 CEST] <thebombzen> MathML doesn't work [20:08:19 CEST] <atomnuker> works on firefox [20:08:20 CEST] <thebombzen> you keep saying it's better [20:08:28 CEST] <thebombzen> "works on firefox" is not working [20:08:31 CEST] <atomnuker> the best is obviously svg [20:08:37 CEST] <thebombzen> that's a browser-specific extension [20:08:40 CEST] <atomnuker> and mathml is better on paper [20:08:44 CEST] <thebombzen> MathML is XML [20:08:45 CEST] <atomnuker> its not, its svg [20:08:55 CEST] <thebombzen> MathML requires you to code in XML [20:09:01 CEST] <atomnuker> yes, and if it was standardized it is the best [20:09:10 CEST] <thebombzen> It is not the best [20:09:12 CEST] <atomnuker> you can compile from latex to that [20:09:13 CEST] <thebombzen> because it requires you to code in XML [20:09:27 CEST] <thebombzen> and "if it were standardized" is a bit pushing it [20:09:34 CEST] <atomnuker> you always write in latex so you always have machines doing the work [20:09:37 CEST] <thebombzen> it also doesn't render correctly even in firefox [20:09:48 CEST] <atomnuker> thebombzen: it would be if chrome people didn't hate it [20:10:01 CEST] <atomnuker> thebombzen: it does, I wrote something just a month ago and it works [20:10:02 CEST] <thebombzen> perhaps people hate it because it's not cross-browser and requires XML? [20:10:29 CEST] <atomnuker> its not cross browser because 1 browser doesn't like it and it being xml doesn't matter as I explained 3 times earlier [20:11:17 CEST] <atomnuker> what matters is bandwidth per view, and you don't get better than mathml [20:11:25 CEST] <atomnuker> you get close or better with just pure svg [20:11:30 CEST] <atomnuker> you get shit with mathjax [20:12:06 CEST] <atomnuker> so straight up svg is the best unless you're one of those people [20:12:06 CEST] <thebombzen> atomnuker: this is not correct https://i.imgur.com/XInnr5B.png [20:12:22 CEST] <thebombzen> the problem with MathML is that it *doesn't work* [20:12:38 CEST] <thebombzen> it doesn't actually matter how good it is in its environment and bandwidth [20:12:42 CEST] <thebombzen> because it doesn't render correctly [20:12:48 CEST] <atomnuker> that same file renders correctly here [20:13:39 CEST] <atomnuker> if you don't like it then yeah, submit a patch [20:14:02 CEST] <thebombzen> well if I were to submit a patch I'd change --mathml to --mathjax [20:14:05 CEST] <thebombzen> because MathJax actually works [20:14:24 CEST] <atomnuker> don't expect a javascript framework to be merged just for a pure html page [20:14:30 CEST] <atomnuker> use straight up svg [20:15:02 CEST] <thebombzen> "to be merged" [20:15:02 CEST] <thebombzen> what [20:15:07 CEST] <thebombzen> what are you talking about [20:15:11 CEST] <atomnuker> into the spec's repository [20:15:13 CEST] <thebombzen> this is what it should look like: https://i.imgur.com/i7LqRwM.png [20:15:20 CEST] <thebombzen> atomnuker: why would you merge it [20:15:23 CEST] <llogan> durandal_1707: any thoughts on http://www.ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209031.html ? [20:15:29 CEST] <thebombzen> when they literally provide CDN so you don't have to [20:15:32 CEST] <atomnuker> thebombzen: the specs are in a repository [20:15:43 CEST] <atomnuker> and if it goes down or you don't have internet? [20:15:55 CEST] <thebombzen> then use git submodules [20:16:06 CEST] <atomnuker> then you have to merge it obviously [20:16:08 CEST] <thebombzen> you don't have to commit the file [20:16:11 CEST] <atomnuker> into a repository [20:16:12 CEST] <durandal_1707> llogan: ok [20:16:24 CEST] <thebombzen> but either way atomnuker that doesn't change the fact that MathML renders it incorrectly [20:16:32 CEST] <thebombzen> none of what your'e saying matters if MathML doesn't work and MathJax does [20:16:33 CEST] <atomnuker> thebombzen: on your bloody system [20:16:41 CEST] <llogan> durandal_1707: thanks. i'll push it. [20:16:57 CEST] <thebombzen> my bloody system is using latest firefox with no extensions [20:16:59 CEST] <thebombzen> what do you want [20:17:28 CEST] <atomnuker> thebombzen: and you can't seem to get it through your thick bloody scull embedding svgs is better and more feasible than a fucking javascript monstrosity [20:18:19 CEST] <thebombzen> Monstrosity? [20:18:20 CEST] <thebombzen> 63k? [20:18:27 CEST] <thebombzen> hardley a monstrosity [20:18:29 CEST] <atomnuker> and how much for the entire spec html, huh? [20:18:52 CEST] <thebombzen> 90k [20:18:56 CEST] <atomnuker> exactly [20:19:32 CEST] <thebombzen> atomnuker: what you're failing to get through that thick bloody skull of yours [20:19:41 CEST] <thebombzen> is that overhead doesn't matter, if MathML doesn't work [20:20:07 CEST] <RiCON> thebombzen: https://chrome.google.com/webstore/detail/math-anywhere/gebhifiddmaaeecbaie… [20:20:10 CEST] <RiCON> there, fixed [20:20:12 CEST] <atomnuker> hey, don't steal my way of swearing! [20:21:43 CEST] <thebombzen> it's interesting that RiCON's suggested fix is to use MathJax [20:22:16 CEST] <thebombzen> should I be pointing out that MathJax is the solution to a problem caused by MathML? [20:22:28 CEST] <RiCON> for a browser missing mathml parsing, sure [20:22:31 CEST] <RiCON> firefox can render it fine [20:22:41 CEST] <thebombzen> no it can't [20:23:02 CEST] <thebombzen> this is not "fine": https://i.imgur.com/XInnr5B.png [20:24:26 CEST] <RiCON> what version is this? [20:25:39 CEST] <RiCON> https://i.fsbn.eu/CSK2.png [20:32:11 CEST] <cone-056> ffmpeg 03Gyan Doshi 07master:2104e3383fd1: avfilter/avf_abitscope: Correct range for framerate [20:46:31 CEST] <thebombzen> RiCON: 50.1.0 Release [20:58:31 CEST] <peloverde> Do you have the mathml fonts? [20:58:58 CEST] <peloverde> https://developer.mozilla.org/en-US/docs/Mozilla/MathML_Project/Fonts [20:59:58 CEST] <thebombzen> why should I have to download them [21:00:01 CEST] <thebombzen> and no that's no the issue [21:00:08 CEST] <thebombzen> the issue is the spacing doesn't work [21:00:36 CEST] <thebombzen> (and yes I do, I have Texlive installed) [21:13:10 CEST] <RiCON> oh, didn't think of that [21:13:19 CEST] <RiCON> yeah, i'm using Cambria Math, which comes with Windows [22:13:59 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:e976e68fc551: avcodec/atrac3: Check init_get_bits8() for failure [22:15:19 CEST] <BBB> michaelni: ty for the clearvideo change [22:15:32 CEST] <michaelni> np [22:16:23 CEST] <cone-056> ffmpeg 03Anton Khirnov 07master:b115a35ea62b: hwcontext_qsv: add support for the P8 format [22:16:24 CEST] <cone-056> ffmpeg 03Mark Thompson 07master:59b1942aae47: Merge commit 'b115a35ea62b8f479b48d99a601f0e157517301e' [22:16:47 CEST] <ubitux> yey [22:17:33 CEST] <cone-056> ffmpeg 03Anton Khirnov 07master:b91ce4860054: hwcontext_qsv: do not fail when download/upload VPP session creation fails [22:17:34 CEST] <cone-056> ffmpeg 03Mark Thompson 07master:7cb082ac2ff0: Merge commit 'b91ce4860054430d3712deb0d9487cac2fcb7d68' [22:45:59 CEST] <cone-056> ffmpeg 03Anton Khirnov 07master:8ea15afbf2c1: hwcontext_qsv: transfer data through the child context when VPP fails [22:46:00 CEST] <cone-056> ffmpeg 03Mark Thompson 07master:546524056d7c: Merge commit '8ea15afbf2c1ec89b5d4bac1f0b8345e4b906a5d' [22:47:13 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:4064f3f0dfe7: avfilter/af_sofalizer: Fix bad shift [22:47:14 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:4798237f01cf: avfilter/deshake_opencl: Remove redundant return [22:47:15 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:855305fac239: avfilter/vf_minterpolate: Use dx and dy [22:47:54 CEST] <jkqxz> ^ only works for DXVA2, which I don't think was intended. AFAIK it can't be invoked for VAAPI, though, so I'm ignoring it for now. [22:54:38 CEST] <jkqxz> Hmph. Same issue with the next one. That's more obvious, but I'll fix it separately. (I seem to already have fixed it without noticing when adding more mapping cases, so I'll drag that in somehow.) [22:55:09 CEST] <cone-056> ffmpeg 03Anton Khirnov 07master:e8bbacbf5290: hwcontext_qsv: support frame mapping [22:55:10 CEST] <cone-056> ffmpeg 03Mark Thompson 07master:e3f9c5826ace: Merge commit 'e8bbacbf529049c401bfeea70d5e0b5d2c8b6de6' [23:02:29 CEST] <cone-056> ffmpeg 03Anton Khirnov 07master:404e51478eca: qsv{dec,enc}: always use an internal mfxFrameSurface1 [23:02:30 CEST] <cone-056> ffmpeg 03Mark Thompson 07master:2f18e452f88f: Merge commit '404e51478ecad060249d5b9bee6ab39a8a9d8c1c' [23:06:11 CEST] <cone-056> ffmpeg 03Anton Khirnov 07master:00aeedd84105: qsv{dec,enc}: use a struct as a memory id with internal memory allocator [23:06:12 CEST] <cone-056> ffmpeg 03Mark Thompson 07master:c0f2a8eac172: Merge commit '00aeedd84105a17f414185bd33ecadebeddb3a27' [23:15:25 CEST] <cone-056> ffmpeg 03Anton Khirnov 07master:4ab61cd983b5: qsv{enc,dec}: extend the internal frame allocator [23:15:26 CEST] <cone-056> ffmpeg 03Mark Thompson 07master:ff821fdfced0: Merge commit '4ab61cd983b539749bd621ea271624ddb5196a8e' [23:16:58 CEST] <jkqxz> ubitux: (End of that qsv stretch.) [23:17:28 CEST] <ubitux> jkqxz: awesome! thanks a lot [23:19:47 CEST] <cone-056> ffmpeg 03Luca Barbato 07master:7471352f1915: pixfmt: Add GRAY12 [23:19:48 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:719f1a923f2f: Merge commit '7471352f1915813cda725ce624607d84b5a3a61c' [23:21:58 CEST] <cone-056> ffmpeg 03Luca Barbato 07master:ab839054e662: swscale: Add GRAY12 [23:21:59 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:62e46fac2646: Merge commit 'ab839054e662d3227e1f795ba1dfd01fe1cf305c' [23:22:41 CEST] <cone-056> ffmpeg 03Andreas Cadhalpun 07master:43de8b328b62: lzf: update pointer p after realloc [23:22:42 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:9813df118984: Merge commit '43de8b328b62cf21ec176c3989065168da471a5f' [23:23:27 CEST] <cone-056> ffmpeg 03Diego Biurrun 07master:943533d64c7f: avconv: Correct function pointer assignments in options array [23:23:28 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:aac40dd6154d: Merge commit '943533d64c7fa7a1b2fc9559e67652c349d21d51' [23:24:26 CEST] <cone-056> ffmpeg 03Diego Biurrun 07master:88f0cf8cd30c: avplay: Correct function pointer assignments in options array [23:24:27 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:2a68d3b1a508: Merge commit '88f0cf8cd30c8ea283430e6710a7bd98bb9c0301' [23:25:47 CEST] <jkqxz> nevcairiel: Trying your VP9 test, immediate segfault with VAAPI. avctx->sw_pix_fmt is no longer set. [23:26:12 CEST] <jkqxz> Having fixed that, it works fine with threads - run several times and the checksums are always the same. [23:26:15 CEST] <ubitux> time to sleep for me [23:26:17 CEST] Action: ubitux & [23:27:12 CEST] <durandal_170> ubitux: please make nlmeans faster and better [23:29:20 CEST] <nevcairiel> jkqxz: any particular place you set it? [23:30:13 CEST] <jkqxz> It's NONE at <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vaapi_vp9.c;h=d8e…>, and previously it was not. [23:30:53 CEST] <nevcairiel> i assume that problem also affected running without threads? [23:31:05 CEST] <jkqxz> Yes, that's entirely fatal to it working at all. [23:31:12 CEST] <nevcairiel> odd then [23:32:00 CEST] <jkqxz> It will break dxva2 for 10-bit as well, since it will allocate 8-bit surfaces. [23:36:07 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:fe46d92c15ca: avcodec/clearvideo: Do not lose the return code of decode_mb() [23:36:08 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:477ba8f9391f: avfilter/af_chorus & aecho: Handle NULL return from av_strtok() [23:36:09 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:bd8201566d75: avformat/libopenmpt: Check for avio_size() failure [23:36:10 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:77a3c288bd57: avformat/mov: Init ref_sc / ref_st to NULL [23:36:11 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:afebf470ca73: avutil/tests/dict: Check return of av_dict_parse_string() [23:38:03 CEST] <nevcairiel> this is the kind of output it get: https://pastebin.com/hZwB3PBH .. it somehows forgets any non-I frames and decodes to some weird hash [23:38:44 CEST] <nevcairiel> (that is one green image, so zero surface? [23:38:49 CEST] <nevcairiel> -?+) [23:39:22 CEST] <jkqxz> Where does the EPERM come from? [23:39:31 CEST] <nevcairiel> thats just w hat -1 translates t o [23:39:47 CEST] <nevcairiel> my spacebar really needs better manners [23:44:00 CEST] <iive> nevcairiel: yes, green is UV={0;0} [23:44:11 CEST] <nevcairiel> the question was by accident [23:44:13 CEST] <nevcairiel> but yes [23:45:05 CEST] <iive> ffmpeg usually allocates empty image buffers with 0x80, so they look gray. [23:45:22 CEST] <nevcairiel> not for hardware [23:45:26 CEST] <nevcairiel> although it could, i guess [23:45:54 CEST] <durandal_170> it shouldnt memset at all [23:47:34 CEST] <BBB> I dont believe it does; it used to, years ago [23:48:15 CEST] <nevcairiel> it only memsets frames if it generates missing references [23:48:20 CEST] <nevcairiel> for h264 anyway [23:48:26 CEST] <durandal_170> it does, we merged libav , and it was elenril idea iiirc [23:48:30 CEST] <nevcairiel> so it has an "empty" one to use as a reference frame [23:50:59 CEST] <jkqxz> nevcairiel: Haha, I think your problem is actually exactly the same as mine. Is your -1 coming from <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/dxva2_vp9.c;h=fd7…>? (So it isn't actually decoding at all, hence a blank frame.) [23:51:21 CEST] <nevcairiel> but it works with threads 1 for me [23:51:33 CEST] <nevcairiel> how did you fix yours? [23:52:01 CEST] <jkqxz> Um, by hard-coding AV_PIX_FMT_YUV420P. Still looking for the actual fix. [23:52:10 CEST] <nevcairiel> ah [23:52:52 CEST] <jkqxz> Huh, it works with -threads 1 for me as well. I wonder what I tried when I said that it didn't above? [23:53:00 CEST] <nevcairiel> that fixes it [23:53:25 CEST] <jkqxz> I suspect this is going to be because there are actually 9001 AVCodecContexts lying around and we only set sw_pix_fmt on some of them. [23:53:35 CEST] <jkqxz> When you have threads. [23:53:46 CEST] <nevcairiel> it worked once upon a time [23:54:35 CEST] <jkqxz> Are you sure? I went back to before (some of?) wm4's threading stuff and it was the same. [23:56:49 CEST] <nevcairiel> yes [23:57:05 CEST] <nevcairiel> BBB and myself worked some on it to make vp9.c handle that properly [23:57:11 CEST] <jkqxz> <http://sprunge.us/ZiFA> [23:57:19 CEST] <jkqxz> Nothing to do with VP9. [23:57:30 CEST] <jkqxz> (None of the other hwaccels look at sw_pix_fmt.) [23:58:01 CEST] <BBB> aha [23:58:04 CEST] <BBB> nice [23:58:17 CEST] <jkqxz> Does that work for you? [23:59:07 CEST] <nevcairiel> yes [23:59:48 CEST] <jkqxz> I'll send it to the ML? [00:00:00 CEST] --- Fri Mar 31 2017

1 0

ffmpeg.log.20170330
by burek 31 Mar '17

31 Mar '17

[00:00:46 CEST] <furq> http://vpaste.net/ZVW3Z [00:00:47 CEST] <petecouture> Going through them now [00:00:48 CEST] <furq> something like that [00:00:52 CEST] <thebombzen> furq: did you just read this? https://stackoverflow.com/questions/624857/finding-which-process-was-killed… [00:01:28 CEST] <thebombzen> also check dmesg [00:01:30 CEST] <furq> no i read a different so answer [00:01:39 CEST] <furq> or unix.se rather since that question obviously doesn't belong on so [00:01:47 CEST] <furq> .SE, not sweden [00:01:59 CEST] <petecouture> Mar 26 18:09:06 3q-dfw-01 kernel: Killed process 2408 (ffmpeg) total-vm:2649992kB, anon-rss:1344196kB, file-rss:32kB, shmem-rss:0kB [00:03:13 CEST] <furq> 1.3GB of rss [00:03:21 CEST] <furq> i take it your server doesn't have that going spare [00:03:31 CEST] <petecouture> It's not a big server no [00:03:37 CEST] <petecouture> About 2 megs of memory [00:03:40 CEST] <petecouture> gigs rather [00:03:42 CEST] <petecouture> lol [00:04:07 CEST] <furq> well if nothing else it's good that you stopped running it in node [00:04:21 CEST] <petecouture> Needs to be run via node [00:04:32 CEST] <furq> looks like you're off to the memory shop then [00:04:35 CEST] <petecouture> mp4 to hls converter tool. [00:05:30 CEST] <petecouture> Gotcha, thank you guys for your help. I'll make sure the system has more memory to run. [00:05:38 CEST] <thebombzen> try recompiling ffmpeg with memory optimizations [00:05:45 CEST] <thebombzen> afaik they exist [00:05:48 CEST] <furq> what's the actual command you're running [00:05:56 CEST] <furq> 1.3GB sounds really excessive for remuxing to hls [00:06:03 CEST] <thebombzen> yes it does [00:06:19 CEST] <alexpigment> yeah this sounds more like a memory *leak* than a memory deficit [00:06:27 CEST] <furq> well maybe something else is going on [00:06:32 CEST] <petecouture> It's processing 7 outputs at once [00:06:36 CEST] <furq> oh [00:06:38 CEST] <alexpigment> well [00:06:41 CEST] <alexpigment> there's that... :) [00:06:42 CEST] <petecouture> ;-) [00:06:44 CEST] <furq> even then that sounds like a lot [00:06:48 CEST] <furq> unless you're encoding [00:06:56 CEST] <furq> if you're encoding variants then that's probably about right [00:07:40 CEST] <furq> then again if you're running node you probably want at least 16GB anyway [00:08:10 CEST] <petecouture> It's converting a mp4 file to 7 different bitrates and resolutions in HLS format. It's for a baseball company and 5K is the upper threshold so it is probably a memory cpu problem. It runs fine on my Macbookbut i have 16 gigs ram. [00:08:56 CEST] <furq> most of that is probably just from decoding 5K [00:09:10 CEST] <furq> with that said i don't know where you found a box with enough cpu to deal with that but only 2GB [00:09:17 CEST] <furq> unless it's ok for this to take a week [00:09:36 CEST] <petecouture> It's running on veryslow for max compression. [00:09:49 CEST] <alexpigment> furq: you can get a stick of 2gb ddr4 even [00:09:59 CEST] <alexpigment> never underestimate the computer parts industry [00:10:16 CEST] <furq> well i assume by "server" he means in someone else's dc [00:10:21 CEST] <llogan> an asian restaurant opened today next door. engage permasmell. time to move. [00:10:36 CEST] <alexpigment> i know, i'm just joking about how something that *shouldn't* exist still does [00:10:40 CEST] <furq> llogan: use the opportunity to grow some weed [00:10:45 CEST] <alexpigment> lol [00:11:00 CEST] <furq> you'll never make it as an entrepreneur with that attitude [00:11:08 CEST] <petecouture> Thanks again for the help guys [00:12:44 CEST] <llogan> furq: the problem is that a needle exchange also moved into the same building, so it may attact its clients wanting a hit. [00:13:23 CEST] <furq> even better [00:13:38 CEST] <furq> think of all the car stereos you could be rolling in [00:14:09 CEST] <llogan> the percentage of skinny white guys with neck tats has increased exponentially [00:14:55 CEST] <furq> living in a big city sounds pretty cool [00:15:07 CEST] <llogan> it's not big. just shitty. [00:17:35 CEST] <celyr> Hi [00:17:45 CEST] <celyr> I want to cut a video, but I need two cuts [00:17:58 CEST] <celyr> is it possibile without making 2 separate video and 1 merge then ? [00:20:04 CEST] <Kadigan> Hey. How can I tell ffmpeg to output to /dev/null... on Windows? I don't recall what the abstract equivalent is. [00:20:10 CEST] <furq> -f null - [00:20:46 CEST] <Kadigan> Thanks, that worked. [00:21:03 CEST] <Kadigan> Say, can you try answering a question that is video-related but not ffmpeg-related? [00:21:21 CEST] <furq> sure [00:21:58 CEST] <Kadigan> I have a video file that for some reason doesn't play well with "ffmpeg video decoder raw" -- it flashes red-tinted and green-tinted frames quite often. [00:22:17 CEST] <Kadigan> I assume it's broken or otherwise out of spec, [00:22:27 CEST] <Kadigan> but I'm not sure what to do about it... [00:22:53 CEST] <Kadigan> (I use mpc-hc for playback, but in conjunction with SVP and madVR; when I use a second mpc-hc copy it plays back just fine w/o this issue) [00:23:07 CEST] <Tatsh> i have a weird DVD and its VOBs have streams in different positions [00:23:12 CEST] <Kadigan> ah [00:23:17 CEST] <Kadigan> ffmpeg = ffdshow [00:23:20 CEST] <Kadigan> I apologize [00:23:27 CEST] <Kadigan> (the second copy doesn't use madVR/SVP/ffdshowvdr) [00:23:29 CEST] <Tatsh> is this typical? [00:23:40 CEST] <llogan> celyr: sure, if you use the concat filter [00:23:42 CEST] <Tatsh> i'm using -filter_complex with the concat filter to encode to a single file, picking each stream [00:24:07 CEST] <furq> Tatsh: if you mean multiple titles/PGCs then use tccat [00:24:17 CEST] <celyr> llogan, but I guess I will have first to cat the original video two times with -ss and -t and then to merge them with concat ? [00:24:24 CEST] <Tatsh> where can i get tccat? [00:24:34 CEST] <furq> are you *nix or windows [00:24:42 CEST] <furq> +on [00:24:47 CEST] <Tatsh> found it [00:24:49 CEST] <Tatsh> i'm on gentoo [00:24:54 CEST] <Tatsh> it's the transcode package [00:24:56 CEST] <furq> yeah [00:25:47 CEST] <furq> that'll demux a single title/chapter/angle and output it on stdout, so you can pipe it into ffmpeg [00:25:58 CEST] <furq> ffmpeg's handling of anything but the simplest dvds is basically worthless [00:26:11 CEST] <Tatsh> ok [00:26:25 CEST] <Tatsh> yea when i merged the vobs even after figuring out how to pick the channels i got a strange result [00:26:33 CEST] <Tatsh> the audio of course was off sync in the second half [00:27:07 CEST] <llogan> celyr: you can use (a)trim and (a)setpts filters then concat filter. but note this will re-encode everything. or use the inpoint/outpoint options for the concat demuxer if you want to try to avoid re-encoding, but you'll need to cut on a keyframe for it to work properly. [00:27:33 CEST] <celyr> ok arab incoming lol [00:27:47 CEST] <celyr> sorry I'm really ignorant in maens of video encoding [00:28:40 CEST] <furq> celyr: if you're reencoding then it's something like this [00:28:49 CEST] <furq> -filter_complex "[0:v]trim=3:7,setpts=PTS-STARTPTS[v1]; [0:v]trim=22:25,setpts=PTS-STARTPTS[v2]; [0:a]atrim=3:7,asetpts=PTS-STARTPTS[a1]; [0:a]atrim=22:25,asetpts=PTS-STARTPTS[a2]; [v1][a1][v2][a2]concat=a=1" [00:28:59 CEST] <furq> replace 3:7 and 22:25 with your actual cut points [00:29:13 CEST] <llogan> concat=n=2:v=1:a=1 [00:29:20 CEST] <furq> i say "iirc" because that's the last entry in my command history for "setpts" so i assume that's the one which worked [00:29:28 CEST] <celyr> furq, No I don't want to loose quality [00:29:45 CEST] <furq> it's a good job i didn't type all that out by hand then [00:30:01 CEST] <celyr> furq, but I've made it easier, I made output1.mp4 and output2.mp4 [00:30:22 CEST] <llogan> furq: lucky. i can't type with my buttocks [00:30:58 CEST] <llogan> very well at least [00:33:45 CEST] <celyr> ffmpeg -i "concat:output1.mp4|output2.mp4" -c copy output.mp4 [00:34:00 CEST] <celyr> this is not working, it does not concat :/ [00:34:06 CEST] <celyr> just output1.mp4 is put in output.mp4 [00:34:33 CEST] <celyr> and no error is returned too [00:34:41 CEST] <Kadigan> Fun fact: transcoding the video w/ ffmpeg fixes it. Like I said, it's probably a badly encoded file, and ffdshow video decoder raw is probably less tolerant of such shenanigans. [00:38:14 CEST] Action: celyr hammer his head on the wall [00:39:52 CEST] <Tatsh> actually furq all i needed to do was use vobcopy -l [00:40:23 CEST] <Tatsh> vobcopy assumes you're on a bad file system that does not support > 2 GiB [00:40:26 CEST] <celyr> ok I did it I had first to transcode it [00:42:52 CEST] <celyr> llogan, now I see what you meant by concatenating this way it creates a long still frame [00:42:57 CEST] <celyr> long maybe .5 sec [00:43:23 CEST] <llogan> concat protocol doesn't work with MP4 [00:43:31 CEST] <llogan> use concat filter or concat demuxer [00:43:36 CEST] <celyr> llogan, I transcoded it to mpeg [00:44:08 CEST] <celyr> like this ffmpeg -i file.mp4 -c copy -bsf:v h264_mp4toannexb -f mpegts output1 [00:44:51 CEST] <llogan> why would you do that. you're encoding but you told furq you want to avoid that. [00:45:19 CEST] <celyr> because on tha manual i read that this is lossless [00:45:26 CEST] <furq> it is [00:45:39 CEST] <furq> but that's remuxing to mpegts, not transcoding to mpeg [00:45:55 CEST] <celyr> so this is ok to me [00:46:04 CEST] <celyr> the only problem is the still frame [00:46:16 CEST] <furq> use the concat demuxer [00:46:27 CEST] <furq> https://trac.ffmpeg.org/wiki/Concatenate#demuxer [00:47:03 CEST] <celyr> furq, does it work direcly with mp4 ? [00:47:09 CEST] <furq> it should do [00:47:14 CEST] <furq> but mpegts is generally better for that anyway [00:47:30 CEST] <celyr> furq, but it creates that frame [00:51:01 CEST] <celyr> now the still frame is not the first of the second video is the last of the first video [00:51:02 CEST] <celyr> lol XD [00:52:21 CEST] <celyr> the result is much better tho so I think I'll stick with it [01:04:46 CEST] <flyBoi> If you could have a cloud server instance with either 1) a ton of memory or 2) an insanely fast CPU (but not both), which would be better for ffmpeg speed-wise? [01:06:02 CEST] <llogan> flyBoi: CPU [01:07:34 CEST] <flyBoi> llogan: should have specified: for trimming very large video files [01:08:06 CEST] <furq> do you mean large in duration or in resolution [01:08:18 CEST] <furq> the former usually makes no difference [01:08:45 CEST] <furq> ofc if you're trimming without reencoding then the cpu makes no difference either. only the disk speed matters then [01:11:30 CEST] <flyBoi> both duration and resolution. Typically 45minute videos, near ProRes quality [01:12:26 CEST] <flyBoi> it's been a while since I've used ffmpeg- why wouldn't you reencode? [01:12:35 CEST] <chatter29> hey guys [01:12:50 CEST] <flyBoi> changing the file type? [01:13:11 CEST] <chatter29> allah is doing [01:13:16 CEST] <chatter29> sun is not doing allah is doing [01:13:18 CEST] <chatter29> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger [01:18:09 CEST] <Tauromancer> doing what? lol [01:21:56 CEST] <llogan> Tauromancer: what the sun is not doing. [01:23:58 CEST] <llogan> flyBoi: stream copy http://ffmpeg.org/ffmpeg.html#Stream-copy [01:31:55 CEST] <flyBoi> llogan: Thanks! Turns out we will be reencoding, so I guess stream copy won't work [01:33:43 CEST] <llogan> then go for the CPU option [03:17:35 CEST] <Fenrirthviti> What exactly the swscaler message "warning: Warning: data is not aligned! This can lead to a speedloss" actually mean? [03:18:24 CEST] <thebombzen> I think it means that certain CPUs work better if the data is aligned to certain bytes [03:19:01 CEST] <thebombzen> i.e. a 32-bit integer starting at a pointer that's amultiple of 4 will work better with cpu artihmetic than a 32-bit integer shifted by one byte [03:42:36 CEST] <Fenrirthviti> Gotcha. [03:52:40 CEST] <kepstin> that message is mostly intended at developers using the library, to make sure they align their frames, but you can get it sometimes on the command line if you crop or scale to unusual offsets. nothing to do about it, it'll just be a bit slower :/ [03:53:16 CEST] <unomystEz> I have an mp3 file that is around 5 mins and I want to create an mp4 video that just shows a static image the whole duration except for time 00:00:10-00:00:30 I want to show a different image [03:53:34 CEST] <unomystEz> is it possible without having to generate 5 mins worth of individual images (one for each frame?) [04:02:58 CEST] <furq> unomystEz: -loop 1 -i foo.png -i bar.mp3 -shortest out.mp4 [04:03:26 CEST] <furq> oh nvm i didn't read all of that [04:04:47 CEST] <furq> -loop 1 -i foo.png -loop 1 -i bar.png -i baz.mp3 -shortest -filter_complex "[0:v][1:v]overlay=enable=between(10\,30)[out]" -map "[out]" -map 2 out.mp4 [04:04:54 CEST] <furq> something like that [04:05:06 CEST] <unomystEz> holy moly [04:05:21 CEST] <furq> er [04:05:26 CEST] <furq> -loop 1 -i foo.png -loop 1 -i bar.png -i baz.mp3 -shortest -filter_complex "[0:v][1:v]overlay=enable=between(t\,10\,30)[out]" -map "[out]" -map 2 out.mp4 [04:08:38 CEST] <unomystEz> Stream specifier ':v' in filtergraph description [0:v][1:v]overlay=enable=between(t\,10\,30)[out] matches no streams [04:09:12 CEST] <furq> are the inputs in the right order [04:09:15 CEST] <unomystEz> https://pastebin.com/hag1tsXh [04:09:20 CEST] <unomystEz> I pasted the command [04:10:18 CEST] <furq> er [04:11:38 CEST] <furq> not sure if this is the problem but you don't actually need -loop 1 on the second input image [04:12:52 CEST] <unomystEz> err [04:12:57 CEST] <unomystEz> my bad, I think I was missing a -i [04:13:04 CEST] <furq> oh [04:13:05 CEST] <furq> yeah you were [04:13:27 CEST] <furq> 1 sure does look like i [04:13:50 CEST] <unomystEz> working [04:14:23 CEST] <unomystEz> hmm, mp3 file is 7 hours long, speedup is only 3x [04:14:25 CEST] <unomystEz> =( [04:24:46 CEST] <furq> you probably also want -c:a copy [04:24:54 CEST] <furq> otherwise it'll transcode the audio to aac [04:25:06 CEST] <JoAnywhere> hi there. Does anyone here have any experience getting ffmpeg working with a Raspberry PI? specifically, recording audio from a USB mic (well, a USB webcam with a built in mic) [04:25:17 CEST] <unomystEz> furq: yup I added that and it seemed to help a bit [04:25:30 CEST] <unomystEz> furq: btw, the video looks great [04:25:39 CEST] <unomystEz> furq: although, any idea how to make this even faster? [04:25:41 CEST] <furq> add -tune stillimage as well [04:25:58 CEST] <furq> and you can probably reduce the framerate [04:26:16 CEST] <furq> add -framerate x before the first -i [04:26:27 CEST] <unomystEz> this is for youtube, should I specify things like -v:c libx264 and -r 24? [04:26:34 CEST] <furq> if it's going to youtube then -framerate 6 [04:26:42 CEST] <unomystEz> oh [04:26:56 CEST] <furq> that should speed it up a lot [04:30:03 CEST] <unomystEz> cool, it's at 5.3x now [04:32:27 CEST] <unomystEz> thanks for your help! [04:40:57 CEST] <JoAnywhere> OK... So I'm going to back the bus up, and compile ffmpeg for my PI (again) using this guide.. https://trac.ffmpeg.org/wiki/CompilationGuide/RaspberryPi. I have to say, it is REALLY un-noob friendly [04:43:48 CEST] <JoAnywhere> can anyone help me out at all? [04:44:47 CEST] <furq> what distro are you running on your actual computer [04:46:35 CEST] <JoAnywhere> furq, on the PI? Latest Raspbian [04:46:41 CEST] <furq> not on the pi [04:46:43 CEST] <JoAnywhere> I'm just reinstalling from noobs as we speak [04:46:45 CEST] <JoAnywhere> windows 10 [04:46:48 CEST] <furq> oh [04:46:48 CEST] <JoAnywhere> on my PC [04:47:08 CEST] <furq> none of that page is useful to you then [04:47:09 CEST] <JoAnywhere> why? I can compile it directly on the PI, so why does my PC come into play? (sorry if I am being dense) [04:47:17 CEST] <furq> that's for cross-compiling from another (faster) computer [04:48:04 CEST] <JoAnywhere> can I just start at the 'Compiling additional libraries needed for FFmpeg' section? [04:48:33 CEST] <furq> if you're building on a pi then it's literally just ./configure; make; make install [04:48:54 CEST] <furq> depending on what dependencies you care about having [04:49:04 CEST] <JoAnywhere> I think I need the alsa library [04:49:26 CEST] <JoAnywhere> as everytime I've built it and use -f alsa, it fails on me; saying alsa is an unknown input format [04:49:36 CEST] <furq> install libasound2-dev [04:49:51 CEST] <JoAnywhere> but I see this guide specifically compiles the alsa library [04:49:58 CEST] <JoAnywhere> install with apt-get? [04:50:01 CEST] <furq> yeah [04:50:13 CEST] <furq> also you probably want to build ffmpeg with --enable-mmal --enable-omx-rpi so you can use the onboard hardware decoder/encoder [04:50:45 CEST] <furq> alsa will be automatically enabled as long as you have libasound2-dev installed [04:51:25 CEST] <JoAnywhere> so do I install that with apt-get install libasound2-dev? [04:51:29 CEST] <furq> yes [04:51:44 CEST] <thebombzen> I'm getting video artifacts when I try to decode a 10bit hevc video with hevc_cuvid, but not with software dec or vdpau [04:51:47 CEST] <JoAnywhere> OK. Once noobs has finished, I'll start being my own noob LOL and have another try [04:51:49 CEST] <thebombzen> is that just a bug in cuvid? [04:52:17 CEST] <JoAnywhere> do I need to go through the steps detailed around additional libraries? [04:52:20 CEST] <furq> no [04:52:28 CEST] <thebombzen> I can reproduce with ffplay -codec:v hevc_cuvid and also in mpv, with mpv --hwdec=cuda [04:52:35 CEST] <JoAnywhere> was that no to me, or no to thebombzen?? :) [04:52:36 CEST] <furq> you only need to build external libs yourself if the ones provided by your distro are old or not present [04:52:51 CEST] <JoAnywhere> OK. I'll have (about my 5th) try [04:53:02 CEST] <furq> or if you're cross-compiling and your host distro doesn't have multiarch [04:54:18 CEST] <JoAnywhere> OK. I'll let you know how I get on [04:54:50 CEST] <JoAnywhere> thanks for the help. file system still extracting, so I'm a ways from trying this [04:54:55 CEST] <furq> http://vpaste.net/uKlbc [04:54:58 CEST] <furq> that should be all you need [04:55:35 CEST] <JoAnywhere> but after grabbing libasound2-dev? [04:55:43 CEST] <furq> line 1 [04:56:18 CEST] <furq> also that should be "make -j4" or else it'll be even slower [04:56:21 CEST] <JoAnywhere> true dat LOL.. looks like it has been commented out [04:56:26 CEST] <furq> # is a root shell [04:56:31 CEST] <furq> i.e. sudo [04:56:36 CEST] <JoAnywhere> so a sudo -i first? [04:56:46 CEST] <JoAnywhere> or just a sudo for that one command? [04:56:54 CEST] <furq> just for the ones marked with # [04:57:15 CEST] <JoAnywhere> r'ok shaggy :) [04:57:51 CEST] <JoAnywhere> and yep - will definately use make -j4. Sends my PI3 into a state of thermal freak out.. but only for a while LOL [04:58:38 CEST] <furq> you might want to do this on /tmp so it's not hitting the sd card [04:59:07 CEST] <JoAnywhere> OK. normally I'd do it in usr/src or something? [04:59:22 CEST] <furq> normally you'd do it in ~ [05:00:41 CEST] <JoAnywhere> lol.. every guide says something different [05:00:46 CEST] <JoAnywhere> does /tmp do it all in RAM? [05:00:58 CEST] <furq> /tmp is normally mounted as a tmpfs, which is in ram [05:01:09 CEST] <furq> you can check with `mount` [05:01:36 CEST] <furq> although if an rpi-specific distro isn't doing that by default then you should probably throw it in the bin [05:02:37 CEST] <JoAnywhere> haha [05:03:03 CEST] <JoAnywhere> but the make install will end up putting it all back onto SD card? [05:03:10 CEST] <furq> yeah [05:03:18 CEST] <furq> that's what --prefix is for [05:04:13 CEST] <JoAnywhere> gotcha (mostly LOL) [05:05:26 CEST] <furq> and yeah most of the guides for this sort of thing are either written by idiots, outdated, or they just assume the worst possible set of circumstances [05:06:14 CEST] <furq> that giant wiki page about cross compiling becomes about seven commands when i cross compile, because my host distro isn't awful [05:08:40 CEST] <JoAnywhere> sorry, wasn't ignoring you.. just was busy doing critical setup on pi (localisation, networking, and changing pi user password) [05:13:19 CEST] <JoAnywhere> @furq... am starting in on it now.... wish me luck :) [05:15:51 CEST] <JoAnywhere> woot... and there is my CPU @ 100%..... [05:34:27 CEST] <JoAnywhere> dum de dooh... still building LOL [05:48:17 CEST] <JoAnywhere> hey furq..... YAY. Now I don't get the alsa error [05:48:38 CEST] <JoAnywhere> still can't record anything [05:48:45 CEST] <JoAnywhere> coz of a different error.. LOL [05:53:58 CEST] <JoAnywhere> furq... you still around mate? [05:55:46 CEST] <JoAnywhere> anyone out there who can help a noob? [05:55:48 CEST] <furq> hi [05:56:01 CEST] <JoAnywhere> hey.... so, your guide worked... that was crazy easy [05:56:05 CEST] <JoAnywhere> so, next problem [05:56:23 CEST] <JoAnywhere> I go arecord -l [05:56:27 CEST] <JoAnywhere> and get the following output [05:56:41 CEST] <JoAnywhere> **** List of CAPTURE Hardware Devices **** card 1: VX5000 [Microsoft LifeCam VX-5000], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 [05:57:45 CEST] <JoAnywhere> so my understanding is that this (given it is card 1, subdevice 0) this command should record audio for 5 seconds to out.wav [05:57:59 CEST] <JoAnywhere> $ ffmpeg -f alsa -i hw:1,1 -t 5 out.wav [05:58:04 CEST] <JoAnywhere> however, I'm getting an error [05:58:21 CEST] <JoAnywhere> [alsa @ 0x33a7230] cannot open audio device hw:1,1 (No such file or directory) hw:1,1: Input/output error [05:58:24 CEST] <JoAnywhere> any thoughts? [05:58:38 CEST] <JoAnywhere> sorry.. that was hw:1,0 - not 1,1 [05:58:50 CEST] <JoAnywhere> and the error was [05:58:58 CEST] <JoAnywhere> [alsa @ 0x3211230] cannot set channel count to 2 (Invalid argument) hw:1,0: Input/output error [05:59:09 CEST] <JoAnywhere> thoughts? [06:00:15 CEST] <furq> set -channels 1 before -i [06:00:23 CEST] <JoAnywhere> hey... adding in -ac 1 seems to have fixed it.. [06:00:36 CEST] <furq> they're probably mapped to the same thing [06:00:45 CEST] <JoAnywhere> what are mapped to the same thing? [06:00:49 CEST] <furq> -ac and -channels [06:01:32 CEST] <JoAnywhere> -ac = audio channels according to the man page [06:02:09 CEST] <furq> -f alsa has its own set of options [06:02:21 CEST] <furq> !indev alsa [06:02:21 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-devices.html#alsa [06:02:49 CEST] <furq> but sometimes global options like -ac will be mapped to the same thing as a private option [06:05:14 CEST] <JoAnywhere> gotcha [06:11:07 CEST] <JoAnywhere> furq... you are a FURQing legend !!!! [06:11:33 CEST] <JoAnywhere> now, to get it to record video at the same time (pretty straightforward) and trigger with motion (also I think fairly straight forward) [06:17:00 CEST] <Tatsh> hi all; i have the original interlaced source for this frame: https://i.imgtc.com/Xw6D2Wj.jpg [06:17:17 CEST] <Tatsh> this is what it looks like after yadif is used; is there any way to not have those blocky lines? [06:17:32 CEST] <Tatsh> any sort of filters i can try for this specific problem [06:21:14 CEST] <furq> Tatsh: you can maybe try nnedi, but it's really slow in ffmpeg [06:21:28 CEST] <furq> vapoursynth and qtgmc might be more useful [06:22:08 CEST] <furq> qtgmc has some really nice stuff for repairing bad deinterlacing artifacts [06:22:31 CEST] <Tatsh> ok [06:22:37 CEST] <furq> you could also try yadif mode 1 if that's not what you used [06:22:45 CEST] <furq> !filter yadif [06:22:45 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#yadif-1 [06:22:45 CEST] <Tatsh> i only specified 'yadif' [06:22:49 CEST] <furq> -vf yadif=1 [06:23:04 CEST] <Tatsh> one question i had also was if yadif should be applied before or after crop, etc? or does this not matter? [06:23:10 CEST] <Tatsh> in the -vf argument [06:23:25 CEST] <furq> it should ideally be before crop or anything else that changes the frame dimensions [06:23:30 CEST] <Tatsh> okay [06:23:32 CEST] <furq> generally it should be first [06:23:38 CEST] <Tatsh> so yadif=1, or qtgmc [06:23:43 CEST] <Tatsh> i'll try yadif=1 now [06:23:46 CEST] <furq> yeah [06:24:00 CEST] <furq> qtgmc is a pain to set up properly, and ffmpeg nnedi is incredibly slow [06:24:18 CEST] <furq> like <5 fps at 480p slow [06:26:49 CEST] <Tatsh> is qtgmc a really recent thing? [06:26:52 CEST] <furq> you might also want to try changing the parity option to yadif [06:27:03 CEST] <furq> although it'd probably look a lot worse than that if the field order was wrong [06:27:04 CEST] <Tatsh> when i run idet on this video, i get mostly bottom [06:27:14 CEST] <Tatsh> and yadif by default is top [06:27:24 CEST] <furq> by default it's "auto" but idk what heuristic it uses [06:27:26 CEST] <Tatsh> i tried to use parity=bff and it didn't seem to change anything [06:27:31 CEST] <furq> fair enough [06:27:55 CEST] <furq> i doubt it's that anyway [06:28:17 CEST] <furq> qtgmc isn't part of ffmpeg if that was unclear [06:28:34 CEST] <furq> it's an avisynth/vapoursynth filter that uses nnedi and some other trick stuff [06:28:44 CEST] <JoAnywhere> hey furq, not sure if you saw my comments before - you got my shit working.. you're a legend!!! [06:29:01 CEST] <furq> i sure am [06:29:09 CEST] <JoAnywhere> and modest with it TROLOLOL [06:29:36 CEST] <JoAnywhere> now, if I can just motion to trigger nicely, and fire up ffmpeg in the on_start_event section, I'll be sorted LOL [06:30:22 CEST] <Tatsh> furq, is the normal process then to use vapoursynth and then encode that video? [06:30:44 CEST] <furq> you filter with vapoursynth and pipe it into ffmpeg for encoding [06:31:16 CEST] <furq> http://avisynth.nl/index.php/QTGMC [06:32:11 CEST] <Tatsh> if this works i'll be impressed [06:32:25 CEST] <furq> https://github.com/HomeOfVapourSynthEvolution/havsfunc [06:32:30 CEST] <furq> the vapoursynth version is there [06:32:46 CEST] <furq> there's a bunch of C libraries you need as well although i forget which ones off the top of my head [06:33:08 CEST] <Tatsh> yea i already built it [06:33:12 CEST] <furq> oh neat [06:33:30 CEST] <furq> vapoursynth editor is useful as well fwiw [06:44:12 CEST] <JoAnywhere> furq, I'm out of here mate.. thanks again for the help. If I've got more grief with ffmpeg, I know where to come looking :() [06:51:26 CEST] <Ferman> Hi everyone, has anyone tried to use ffmpeg to mosaic rtmp streams? [07:01:27 CEST] <Tatsh> uh wow furq [07:01:39 CEST] <Tatsh> i got it working but that was a lot of stuff to compile and install to a random prefix [07:01:58 CEST] <Tatsh> i'm glad i use gentoo and make ebuilds or i wouldn't have gotten very far [07:02:22 CEST] <furq> i think some distros have it all prepackaged now [07:02:24 CEST] <furq> not mine though ;_; [07:03:48 CEST] <Tatsh> when you use qtgmc you get double the framerate [07:03:53 CEST] <Tatsh> 60000/1001 [07:04:05 CEST] <furq> you can set FPSDivisor=2 if you don't want that [07:04:10 CEST] <furq> i normally do want that though [07:04:23 CEST] <Tatsh> then on ffmpeg can you kill half the frames out? [07:04:37 CEST] <Tatsh> or am i not seeing this correctly for what it does [07:04:47 CEST] <furq> you can do one or the other [07:05:25 CEST] <furq> http://avisynth.nl/index.php/QTGMC#Shutter_Speed_Motion_Blur_.2F_Frame_Rate [07:05:35 CEST] <Tatsh> the quality is incredible [07:05:47 CEST] <Tatsh> but on my machine i'm only getting like 1.76x compared to 6x before [07:05:56 CEST] <furq> yeah it's still very slow compared to yadif [07:06:01 CEST] <furq> yadif is designed for realtime playback [07:06:23 CEST] <furq> there are presets you can use to speed it up if it's too slow [07:06:33 CEST] <furq> it's also much faster than ffmpeg nnedi [07:07:44 CEST] <Tatsh> i have nnedi for trying out later [07:07:49 CEST] <Tatsh> but that was quite a trip of finding all the deps [07:07:58 CEST] <furq> it's not really worth trying nnedi if you have qtgmc set up [07:08:07 CEST] <furq> ffmpeg's nnedi is single-threaded [07:08:37 CEST] <furq> vapoursynth is multithreaded and qtgmc does some other nice stuff on top of nnedi [07:08:45 CEST] <furq> at least that's what the wiki says. i couldn't tell you what any of that is [07:08:47 CEST] <Tatsh> thanks for the tip furq [07:08:49 CEST] <Tatsh> this is amazing [07:08:59 CEST] <furq> yeah i always use that for dvds [07:09:28 CEST] <furq> yadif is fine for clean sources but it struggles with a lot of sd stuff [07:09:57 CEST] <JoAnywhere> !leave [07:10:55 CEST] <Tatsh> this is my setup for VHS capture https://i.imgtc.com/EXXJBzg.jpg [07:11:12 CEST] <Tatsh> it goes into a happauge ImpactVCB-e PCIe card which has no comb filter, nor am i sure i would want one [08:19:57 CEST] <mavi> I'm making a generic encode profile for live action upload, and i'm setting up filters as well. I'm curious does a interlacer like yadif, hurt if ran through a video that isn't interlaced? is there an option to detect if a video is interlaced and run a deinterlacer if it is? [08:27:20 CEST] <c_14> yadif=deint=1 will only deinterlace frames that are marked as interlaced [08:28:52 CEST] <c_14> and you can use the idet filter in front of it to try and detect interlaced frames [09:01:59 CEST] <mavi> Would using something like this, -vf yadif=0:-1:0 only deinterlace if the content is interlaced, or will it auto attempt to deinterlace progressive content as well? [09:02:30 CEST] <mavi> ah just saw that, good to know. [09:04:51 CEST] <mavi> c_14 dunno if you have experience with denoisers, but is using a ultralight setting on a denoise filter like hqdn3d=1.5:1.5:6:6 more effective than using something like nr=300 on x264? [09:05:34 CEST] <mavi> Also are the mosquitonr filters and similiar ones any good for bitrate starved videos to remedy their artifacts, or is that just a matter of being bit rate starved? [09:07:07 CEST] <furq> do you mean low-bitrate source or output [09:08:34 CEST] <mavi> output [09:08:38 CEST] <mavi> the source is decent [09:08:42 CEST] <furq> i don't think that'll do anything then [09:09:11 CEST] <mavi> What if the input is blocky? Due to being a webrip from a fairly old source. [09:09:29 CEST] <furq> obviously if you have ringing in the source then it'll help [09:09:42 CEST] <furq> but if this is some generic pipeline then i wouldn't unconditionally use it [09:10:10 CEST] <mavi> got it. Yea it's fairly generic. It's for 720p and 480p live action videos. [09:10:17 CEST] <mavi> all ripped from youtube. [09:11:03 CEST] <furq> i'd probably just stick with denoising [09:11:48 CEST] <mavi> ah I see, any specific filter recomendations for denoising? I don't mind it taking longer to encode, attempting the highest quality within a low bitrate. [09:12:09 CEST] <furq> hqdn3d or nlmeans are probably the best ones in ffmpeg [09:12:11 CEST] <furq> although i've not tried them all [09:12:33 CEST] <mavi> i've tried those on handbrake a few times, I've read in the past that hqdn3d isn't as good as nlmeans [09:12:43 CEST] <mavi> but that it's faster. [09:12:53 CEST] <mavi> does it matter at ultralight generic settings? [09:12:55 CEST] <furq> you can be quite aggressive with denoising without it affecting output quality too badly [09:13:09 CEST] <furq> obviously you'll lose fine detail, but that's probably desirable at low bitrate [09:13:34 CEST] <furq> youtube denoises the hell out of everything and it looks pretty good [09:13:56 CEST] <robswain[m]> i'm trying to encode a set of dash representations into one mpd using ffmpeg [09:14:33 CEST] <robswain[m]> it seems like i can transcode one representation like this: ffmpeg -y -i orb.mov -c:v libx264 -preset veryslow -x264opts keyint=126:min-keyint=126:no-scenecut -b:v 8000k -maxrate 8000k -vf scale=-1:1440 -f dash -init_seg_name init-$RepresentationID$.mp4 -media_seg_name test-$RepresentationID$-$Number$.mp4 orb-8000.mpd [09:14:36 CEST] <robswain[m]> for example [09:14:43 CEST] <mavi> I'm curious what other prefilters youtube uses, probably a bunch of algorithms that detect the best filters to use [09:14:46 CEST] <furq> mavi: there's not really any right or wrong answer, it depends on what your source is and what you want from the output [09:14:56 CEST] <robswain[m]> but how do i encode multiple representations into one mpd? [09:15:01 CEST] <furq> run some test clips and see how they look [09:15:10 CEST] <mavi> Currently doing so :) Thanks [09:15:24 CEST] <furq> if there was a right answer then ffmpeg wouldn't have 12 different denoisers [09:15:26 CEST] <furq> or however many it is now [09:15:32 CEST] <mavi> yea for sure. [09:18:18 CEST] <DemoniacMilk> morning! [09:18:24 CEST] <mavi> Lol I'm on here hoping , there are some magic unicorn filters that magically makes my encodes look like amazing as lower freqencies. [09:18:49 CEST] <mavi> after some early tests nl means looks better for my sources [09:19:34 CEST] <furq> it's a shame ffmpeg doesn't have opencl nlmeans [09:19:37 CEST] <mavi> Combining it with a low -nr from x264 -250 or so seems to yield decent results [09:19:41 CEST] <furq> vapoursynth has that and it's pretty fast [09:20:01 CEST] <mavi> there's no hardware accel on it? [09:20:06 CEST] <mavi> That explains why it's so slow. [09:20:10 CEST] <furq> not on that filter [09:20:15 CEST] <furq> a couple of them can use opencl now [09:20:22 CEST] <furq> none of the denoisers though [09:21:11 CEST] <furq> i'm not sure -nr is really worth using if you're using a separate denoiser [09:21:11 CEST] <mavi> wasn't nlmeans just added to ffmpeg like 6-8 months ago? [09:21:17 CEST] <furq> probably [09:21:27 CEST] <mavi> think it kills too much detail? [09:21:38 CEST] <furq> shrug [09:21:45 CEST] <furq> it just seems weird to run a good denoiser and then a worse one [09:21:56 CEST] <furq> you're already taking the cpu hit from the good one, you might as well just turn that up [09:22:39 CEST] <mavi> i have more testing to do, makes sense. [09:22:41 CEST] <DemoniacMilk> is it intended/expected behaviour that setting --cross-prefix without setting --cc does not configure correctly? (uses gcc instead of cross compiler, then complains about a non-supported architecture) [09:22:48 CEST] <mavi> probably just seeing placebo differences. [09:22:51 CEST] <furq> DemoniacMilk: that works for me [09:23:07 CEST] <furq> pastebin the full configure command [09:23:07 CEST] <mavi> slightly smaller file size [09:24:24 CEST] <DemoniacMilk> https://pastebin.com/yAkiTtua [09:24:50 CEST] <furq> you're missing some hyphens there [09:25:04 CEST] <DemoniacMilk> ` these? [09:25:07 CEST] <furq> - [09:25:34 CEST] <DemoniacMilk> oh that was because i copied it from word (for documentation) [09:25:41 CEST] <DemoniacMilk> and it replaced -- with some weird - [09:25:54 CEST] <furq> nice [09:25:59 CEST] <furq> http://vpaste.net/DJ8yC [09:26:03 CEST] <furq> fwiw that's the config on my rpi ffmpeg [09:27:06 CEST] <DemoniacMilk> hm ye no --cc set [09:27:15 CEST] <DemoniacMilk> lemme try [09:31:01 CEST] <mavi> so i tested using handbrake. any idea what the nlmeans parameters on ffmpeg are? Can't find them anywhere. [09:31:18 CEST] <mavi> Looking for ultralight and light settings, or at least a way to figure them out. [09:31:40 CEST] <furq> !filter nlmeans [09:31:40 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#nlmeans [09:32:09 CEST] <DemoniacMilk> hm, interesting https://pastebin.com/SjKxnKPn [09:33:04 CEST] <furq> i sure am glad i use a distro which packages a working toolchain [09:33:28 CEST] <mavi> !filter nlmeans [09:33:28 CEST] <nfobot> mavi: http://ffmpeg.org/ffmpeg-filters.html#nlmeans [09:33:43 CEST] <mavi> thanks :) [09:34:08 CEST] <DemoniacMilk> ooohhh, i see why [09:34:20 CEST] <DemoniacMilk> theres an additional /arm in the path [09:34:25 CEST] <furq> nice [09:34:30 CEST] <DemoniacMilk> god im an idiot :D [09:34:30 CEST] <furq> also why are you running ./configure as root [09:35:10 CEST] <DemoniacMilk> i tink id have to change some permissions otherwise [09:35:14 CEST] <DemoniacMilk> and didnt bother to do so yet [09:35:40 CEST] <furq> you shouldn't if everything's in ~ [09:35:57 CEST] <furq> unless you ran some earlier step as root [09:36:54 CEST] <DemoniacMilk> i probably did [09:37:11 CEST] <DemoniacMilk> then again i could just change owenership of all of my home folder [09:37:24 CEST] <DemoniacMilk> to be owned by me, because that'd be the default anyways [09:37:44 CEST] <furq> that sounds prudent [09:37:59 CEST] <DemoniacMilk> i dont know the word prudent [09:38:23 CEST] <furq> http://chambers.co.uk/search/?query=prudent&title=21st [09:39:09 CEST] <DemoniacMilk> hhaevery explanation contains a word i dont know but i think i got it :D [09:41:03 CEST] <mavi> There seems to be a lack of people using nlmeans via ffmpeg. Only found one thread on it, and the guy is saying s=1 the lowest setting is too much. [09:41:08 CEST] <furq> also if this is for rpi then you'll want --enable-omx-rpi --enable-mmal [09:41:13 CEST] <furq> if not then ignore that [09:41:41 CEST] <mavi> for the syntax, how do i fix this [09:41:43 CEST] <mavi> -vf scale=-2:"min(ih\,480)":flags=lanczos nlmeans=s=1 [09:41:55 CEST] <furq> replace that space with a comma [09:42:15 CEST] <furq> also you might as well do a bicubic scale [09:42:22 CEST] <furq> it'll be faster and you're trying to lose fine detail anyway [09:42:57 CEST] <furq> i normally use bicubic to downscale low-quality sources [09:42:59 CEST] <mavi> I'm trying to keep detail within reason. Kind of a fine line between blurring and detail. [09:43:26 CEST] <mavi> is lancoz supposed to be a sharp downscaler while bicubic is a bit softer? [09:43:32 CEST] <furq> yeah [09:43:44 CEST] <furq> lanczos and spline are the sharper ones in swscale [09:43:52 CEST] <dystopia_> i use spline for everything [09:44:07 CEST] <mavi> i'll give it a try, i did notice some oddly sharp lines for the lines around the face. [09:44:41 CEST] <mavi> -vf scale=-2:"min(ih\,480)":flags=lanczos,nlmeans=s=1 [09:44:44 CEST] <mavi> like that? [09:44:46 CEST] <furq> yeah [09:44:55 CEST] <furq> lanczos and spline tend to amplify source artifacts if there are any [09:44:59 CEST] <furq> although probably less so when downscaling [09:45:06 CEST] <mavi> ah i see [09:45:19 CEST] <mavi> im using it just for downscaling.. no real point in upscaling in a low bitrate film [09:45:50 CEST] <furq> if this is a generic pipeline then bicubic is probably better [09:46:09 CEST] <furq> it's your pipeline though [09:47:52 CEST] <DemoniacMilk> Reducing images is a completely safe and rational operation. You're simply reducing precision and resolution by discarding information. Make the image as small as you want, and you have complete fidelity-- within the bounds of the number of pixels you've allowed. You'll get good results no matter which algorithm you pick. (Well, unless you pick the naive Pixel Resize or Nearest Neighbor algorithms.) (from https://blog.codinghor [09:47:57 CEST] <mavi> It's a generic pipeline. CRF 28-30, 480p some 720p stuff, going to be doing over 5000 videos.. so want to get the setting right first [09:48:37 CEST] <dystopia_> those crf values seem very high [09:48:46 CEST] <furq> i wouldn't sweat too much about excessive denoising at crf 28 [09:48:52 CEST] <mavi> yea they are. It's meant for a foreign audience with crap internet [09:48:56 CEST] <furq> you're going to be throwing a lot of detail away regardless [09:49:10 CEST] <furq> i would probably favour heavier denoising at that kind of bitrate [09:50:05 CEST] <mavi> if only I could wrap my head around the nlmeans settings on ffmpeg. The hq3d settings are well documented, the nlmeans settings on ffmpeg aren't. Only thing I gather is s=1 is the lowest and it goes up. [09:50:33 CEST] <mavi> on handbrake it's straightforward and uses a set of 6 or so numbers with colons in between. ffmpeg doesn't share that system. [10:02:07 CEST] <mavi> is bucubic better than bilinear ? been reading up on it. [10:03:37 CEST] <DemoniacMilk> biliniear uses a 2x2 grid i think, while bicubic uses a 4x4 grid with higher priority on centered pixels [10:03:50 CEST] <mavi> ah perfect, so bicubic retains a bit more detail? [10:03:56 CEST] <furq> bilinear is faster but softer [10:04:02 CEST] <DemoniacMilk> i have no idea what the results look like tho, but as bicubic requires more computing and is still around i guess it looks better [10:04:41 CEST] <mavi> isn't spline an offshoot of bicubic? It seems to be called bicubic split in some docs. [10:04:49 CEST] <mavi> "natural bicubic spline rescaling algorithm" [10:05:29 CEST] <DemoniacMilk> uh, no idea :( [10:08:51 CEST] <Azarus> hey guys [10:10:26 CEST] <mavi> My god, the ffmpeg filter nlmeans has taken my video fps from 80 down to 4 fps lol. Wow. [10:10:33 CEST] <Azarus> I am looking for a solution to dynamically generate rtmp streams using ffmpeg. And at the same mix images & videos. Additionaly draw text and other ui elements as an overlay [10:10:54 CEST] <Azarus> And I am not sure if such a thing is possible with ffmpeg [10:13:13 CEST] <Azarus> So right now, i have images generated with transparency by nodejs that i would like to put on a video stream as an overlay [10:14:18 CEST] <Azarus> also i would like to update that image every 5-10 seconds [10:14:27 CEST] <Azarus> And additionally i can't really get ffmpeg to continously stream the audio files over rtmp [10:14:32 CEST] <Azarus> can someone help me out please? [10:33:02 CEST] <mavi> Yea this is insane, the nlmeans plugin seems to be highly unoptimized on the s=1 default settings on ffmpeg nightly. Goes at 2fps, which is pretty unusable. Maybe I'm doing something wrong? [10:40:46 CEST] <DemoniacMilk> hm ffplay is not being built, maybe im missing something? I have installed SDL and found some line in config.mak (!ffplay=yes) that i mightwant to remove the ! in? [10:42:36 CEST] <DemoniacMilk> ah ye that worked, although it ends in SDL.h: No such file or directory [10:57:14 CEST] <DemoniacMilk> can i read/disaply a network video stream created by ffmpeg using ffplay only or may i use ffmpeg as well? [11:24:15 CEST] <mavi> anywhere I can submit a bug report, I doubt nlmeans should be getting 2fps, as i usually get 90. Wondering if the 3.2.4 build has different filters than the latest nightly one [11:33:24 CEST] <DemoniacMilk> guys, i cant get ffplay to be built :( [11:36:01 CEST] <DemoniacMilk> the cnfig log contains ffplay='yes' [11:36:25 CEST] <DemoniacMilk> and ffplay_libs='$sdl2_libs' [11:37:16 CEST] <DemoniacMilk> i have installed libsdl2-dev [11:37:51 CEST] <DemoniacMilk> (on my host system tho, as im cross compiling, do i need to cross compile sdl2 as well and pass the compiled version?) [11:39:37 CEST] <DemoniacMilk> ffplay.c:56:17: fatal error: SDL.h: No such file or directory [11:40:48 CEST] <DemoniacMilk> after running the config, i get a warning [11:40:54 CEST] <DemoniacMilk> WARNING: /home/lars/ti/linuxSDK/linux-devkit/sysroots/x86_64-arago-linux/usr/bin/arm-linux-gnueabihf-pkg-config not found, library detection may fail. [11:41:08 CEST] <DemoniacMilk> maybe those two are related? [13:16:24 CEST] <Tom_B> @jkqxz, that patch works great thanks! :) The small delay doesn't really matter and if needed I could just lower -g [13:18:34 CEST] <mavi> So I'm trying to figure out my scale algorithm. [13:20:19 CEST] <mavi> My current one is: scale=-2:'min(ih,480)':flags=bicubic but I also want to limit the width to a max of 854. So if a video has dimensions of 1050x 580 or so it would actually change to 854 width and scale accordingly or 480 height whichever is bigger [13:20:28 CEST] <mavi> How would I go about doing this? [14:39:38 CEST] <mavi> nvm got help at stackoverflow: scale=w='if(gt(dar,854/480),min(854,iw*sar),2*trunc(iw*sar*oh/ih/2))':h='if(gt(dar,854/480),2*trunc(ih*ow/iw/sar/2),min(480,ih))':flags=bicubic [14:58:43 CEST] <ZeDavidT> Hi guys, I'm trying to compile ffmpeg under centos7, using 3.2.4 realease. However, even if the flag "--enable-libebur128" is available under ./configure, it seems that it's missing a library. Do you know where I can find it? [15:09:07 CEST] <DemoniacMilk> anyone here used ffmpeg on e.g. an RPi (or any other embedded system)? [15:09:46 CEST] <DemoniacMilk> cause i was comparing the video conversion performance of my old laptop to the embedded prcoessor [15:09:55 CEST] <DemoniacMilk> on a ~700 frame raw video [15:10:16 CEST] <DemoniacMilk> and my laptop finished pretty much immediately, while the embedded system converted only ~13 fps [15:11:19 CEST] <DemoniacMilk> so im wondering if optimization / hardware accel might be used somehow [15:14:31 CEST] <BtbN> a classic RPi is just that slow. [15:46:28 CEST] <asda> is it possible to create an empty container with some arbitrary duration using ffmpeg? [15:47:24 CEST] <asda> I've already tried it with a silent audio track generated by anullsrc and no video stream [15:47:50 CEST] <asda> but can you have no streams at all and yet still have a duration? [15:52:37 CEST] <DemoniacMilk> does anyone know a video codec with low computing requirements for encoding? [15:53:45 CEST] <asda> DemoniacMilk: are you willing to sacrifice quality? [15:54:33 CEST] <asda> you could use x264 with some ultrafast preset, should be fast enough [15:54:41 CEST] <asda> but the quality will be mediocre [15:54:57 CEST] <asda> or the file will be huge if you want acceptable quality [15:56:36 CEST] <DemoniacMilk> quality is secondary, as long as the embedded system is able to keep up :P [15:57:00 CEST] <DemoniacMilk> so far mpeg2 seems to be the best [15:57:54 CEST] <DemoniacMilk> x264 needs to be added seperately i think? [15:58:06 CEST] <DemoniacMilk> as in: is not included in the ffmpeg package? [15:58:26 CEST] <asda> depends on the platform/distro/whatever [15:58:37 CEST] <asda> check with ffmpeg -encoders [15:59:07 CEST] <asda> ffmpeg -v error -encoders | grep x264 [16:00:23 CEST] <kepstin> DemoniacMilk: if you're on an rpi specifically, there's a hardware encoder on the chip which can be used. You need an ffmpeg with it enabled, then you can use the "h264_omx" encoder (iirc) [16:01:52 CEST] <asda> kepstin: how is the quality with that encoder? [16:02:39 CEST] <kepstin> I imagine it's similarly "not great" like any other hardware encoder, but it should be good enough if you crank up the bitrate, and it'll definitely be less cpu intensive than x264. [16:03:44 CEST] <DemoniacMilk> hm its an AM3359 [16:03:56 CEST] <DemoniacMilk> im not sure if it has a hardware encoder but thats probably a good thing to check [16:04:09 CEST] <DemoniacMilk> (same cpu as used b beaglebone black iirc) [16:06:09 CEST] <DemoniacMilk> hm seems like it doesnt have taht, but a "PowerVR SGX" Graphics Accelerator subsystem" [16:07:04 CEST] <DemoniacMilk> and a neon co processor, i htink i read some about that somewhere [16:09:20 CEST] <asda> DemoniacMilk: if you run ffmpeg, it should say --enable-neon [16:09:45 CEST] <asda> then it means it was built with support for the neon instructions [16:10:13 CEST] <DemoniacMilk> i dont think i configured ffmpeg to use neon (at least if its not the default) [16:10:37 CEST] <DemoniacMilk> but i guess i could do that [16:16:49 CEST] <DemoniacMilk> https://pastebin.com/BzwtZmiS [16:16:56 CEST] <DemoniacMilk> you mean it should be lising --enable-neon here? [16:19:19 CEST] <DemoniacMilk> i just explicitly stated --enable-neon for 'configure' [16:23:22 CEST] <asda> mine looks like this: https://spit.mixtape.moe/view/raw/52fd8a98 [16:24:34 CEST] <DemoniacMilk> ye okay so you added --enable-neon manually [16:24:44 CEST] <asda> I didn't build it [16:25:08 CEST] <DemoniacMilk> ah okay i need to build it myself, but it seemed like neon should be anebled by default [16:25:24 CEST] <DemoniacMilk> at least theres a --disable-neon option [16:26:43 CEST] <asda> well, it could be implied for some target platforms, I'm not sure [16:26:59 CEST] <DemoniacMilk> ill see when this build finished [16:34:00 CEST] <DemoniacMilk> ye it now says --enable-neon [16:34:50 CEST] <DemoniacMilk> i dont see a increase i performance tho [16:36:10 CEST] <DemoniacMilk> or do i? should have written down the old values :D [17:50:14 CEST] <DemoniacMilk> what does ffmpeg do if neon should be used but is not available? [17:50:36 CEST] <DemoniacMilk> does it stop or generate a log entry or soemthing? [17:58:41 CEST] <kepstin> DemoniacMilk: I believe that for assembly optimizations, ffmpeg should by default (you can disable this with a configuration) be doing runtime cpu detection to determine which optimizations to turn on. [17:59:06 CEST] <DemoniacMilk> i forced --enable-neon in one build and --disable-neon in another [17:59:40 CEST] <DemoniacMilk> but i dont see any difference in performance [17:59:47 CEST] <kepstin> also, the options on the ffmpeg configure script don't affect which optimizations the x264 encoder is built with; that's internal to the x264 library [17:59:59 CEST] <DemoniacMilk> im not using x264 tho [18:00:07 CEST] <kepstin> what encoder are you using? [18:00:08 CEST] <DemoniacMilk> i tried mpeg2 i think [18:00:24 CEST] <DemoniacMilk> and mpeg4 as well [18:00:50 CEST] <kepstin> i wouldn't be surprised if nobody has written any neon optimizations for mpeg2/4, they're old codecs that don't see much use any more, and are rarely if ever encoded on arm [18:01:34 CEST] <kepstin> well, mpeg2 still sees some use in tv broadcast and dvd/bd encoding, but that's something you'd do on a big workstation or dedicated server, not a little arm board :) [18:01:41 CEST] <DemoniacMilk> okay maybe thats why [18:02:05 CEST] <kepstin> that said, they do share some code with the jpeg encoder, i think, which is obviously still used :) [18:02:07 CEST] <kepstin> so... :/ [18:02:34 CEST] <DemoniacMilk> i think i saw some info somewhere that x264 needs to be compiled and provided to ffmpeg as a library? [18:03:05 CEST] <kepstin> DemoniacMilk: yes, it's an external codec library that ffmpeg can link to. [18:03:46 CEST] <DemoniacMilk> alright ill take care of that tomorrow [18:03:47 CEST] <DemoniacMilk> thankss a lot [18:03:58 CEST] <DemoniacMilk> and have a nice evening (or whatever time it may be at your place) [18:05:20 CEST] <artectrex> Hi, Telegram is violating the GPL by not updating its android source code (they use ffmpeg), correct? Would the FFmpeg maintainers consider legal action to get them to release it? Their have been numerous requests [18:11:27 CEST] <artectrex_> Hi, Telegram is violating the GPL by not updating its android source code (they use ffmpeg), correct? Would the FFmpeg maintainers consider legal action to get them to release it? Their have been numerous requests [18:24:58 CEST] <durandal_1707> artectrex_: nobody cares [18:25:37 CEST] <artectrex_> Thank you for your answer. [18:26:46 CEST] <iive> artectrex_: ffmpeg is LGPL, unless it includes something else that is gpl [18:27:28 CEST] <artectrex_> I think they do have gpl parts, I may have been mistaken so let me check, having doubts now [18:27:40 CEST] <JEEB> usual thing to look for is the string "--enable-gpl" [18:27:48 CEST] <JEEB> or just enabl-gpl [18:27:53 CEST] <JEEB> *enable [18:28:14 CEST] <artectrex_> https://github.com/DrKLO/Telegram/blob/55463a93db95dcc450c00af3918d9bbbebf4… [18:28:19 CEST] <JEEB> of course that can also be hidden but most people don't care enough [18:28:23 CEST] <artectrex_> enable-gpl is there [18:28:29 CEST] <iive> artectrex_: in the past FFmpeg had persued GPL violations, we had lawyer, but that all went to hell with the hostile fork. [18:29:12 CEST] <iive> we do merge a lot of their code too, and they are not very cooperative. [18:29:21 CEST] <pzy> turns out no one gives a fuck about "software licensing" unless you're big enough to bully people :P [18:29:46 CEST] <artectrex_> I would think a simple (friendly ) email to them in an official capacity would be a good nudge [18:29:52 CEST] <pzy> or the once-in-a-decade viral shaming of some company profiting from open source work [18:30:28 CEST] <iive> artectrex_: it's like a devorce... people don't act rationally [18:30:53 CEST] <artectrex_> Over at /r/android people seem to be getting aware of the issue, every telegram related post has comments about the GPL violations [18:32:00 CEST] <artectrex_> Or maybe a statement of the FFmpeg team about it, to induce this "viral shaming"? I'm sure this would go front-page on YC and/or reddit [18:32:26 CEST] <iive> there used to be a Hall of Shame [18:32:33 CEST] <iive> i'm not sure if it still exists [18:32:40 CEST] <thebombzen> well keep in mind that the violation in question is "not publishing an up-to-date version of the source and instead is publishing an older version" [18:32:55 CEST] <thebombzen> in the grand scheme of things this isn't particularly atrocious [18:33:41 CEST] <iive> well, they do need to publish the lgpl changes to the code. If they use them without change... [18:33:51 CEST] <thebombzen> whenever you apply some sort of action to fix a problem, you have to weigh the severity of the problem to the effort required to fix it [18:33:58 CEST] <artectrex_> yes, well the F-droid build (which is a FOSS fork) is getting 6 months out of date and missing more and more features, including VoIP [18:34:01 CEST] <thebombzen> in this case, the severity of the problem isn't very large [18:34:17 CEST] <thebombzen> yes, they're violating it, but it's not worth people's time to send a lawyer after them [18:34:33 CEST] <artectrex_> Effectively half the featureset is not there in the released code [18:34:51 CEST] <thebombzen> that can't be right [18:34:58 CEST] <iive> artectrex_: are they making binary releases? [18:35:02 CEST] <thebombzen> unless the version of ffmpeg they're using is from like 2007 [18:35:05 CEST] <artectrex_> Yes, weekly at least [18:35:52 CEST] <artectrex_> I mean by half the featureset that Telegram audio calling is not implemented in the released code, at all [18:36:23 CEST] <artectrex_> They have Google Play releases very often though, which are binary [18:36:36 CEST] <iive> ok, about the last source release. Can you make a build with it, that has all the featurs of the corresponding binary build? [18:37:02 CEST] <artectrex_> No. As I said, the Video/audio calls are not implemented in it [18:37:13 CEST] <artectrex_> Oh sorry yes [18:37:15 CEST] <artectrex_> misread that [18:38:56 CEST] <iive> LGPL allows you to keep your code private, but you should distribute it in a form that allows relinking with the LGPL part. e.g. in static library.a format [18:39:26 CEST] <iive> it's easier if lgpl is used as dynamic library.so for that case. [18:40:30 CEST] <artectrex_> The desktop client does not have those issues, they are maintained in the open. Android client ffmpeg dir is here : https://github.com/DrKLO/Telegram/tree/master/TMessagesProj/jni/ffmpeg [18:41:28 CEST] <artectrex_> Seems to have library.a format [18:41:47 CEST] <artectrex_> Not that I know what that means [18:42:32 CEST] <Fenrirthviti> Means they're not violating anything, pretty much [18:43:34 CEST] <artectrex_> But they are using GPL parts [18:43:59 CEST] <artectrex_> https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/jni/ffmpeg/buil… [18:46:22 CEST] <voip_> Hello guys i have problem with taking UDP live stream transcode and re-stream. [18:46:22 CEST] <voip_> Every 1-2 min. FFMPEG stops witch error: "udp @ 0x549fea0] Circular buffer overrun. To avoid, increase fifo_size URL option. To survive in such case, use overrun_nonfatal option." [18:46:22 CEST] <voip_> Problem still exists even if i take stream with option "?fifo_size=256000". [18:46:22 CEST] <voip_> When i run only one instance of FFMPEG, everyting is fine, and newer stops. [18:46:22 CEST] <voip_> https://pastebin.com/YiXpEAyb [18:50:02 CEST] <thebombzen> did you try doing what it told you to do [18:50:11 CEST] <thebombzen> "To survive in such case, use overrun_nonfatal option." [18:50:39 CEST] <thebombzen> also, you don't need -strict experimental with aac anymore [18:52:14 CEST] <iive> artectrex_: can you find what gpl parts they do use. e.g. ffmpeg need enable-gpl for libx264, however the library is available under second commercial license [18:58:43 CEST] <voip_> thebombzen, thank you so much. So my command should be like : ffmpeg -i 'udp://224.10.10.18:6000?fifo_size=256000&overrun_nonfatal=1' ? [18:59:02 CEST] <thebombzen> I don't actually know where to put the overrun_nonfatal option [18:59:09 CEST] <thebombzen> it might just be an option for ffmpeg [18:59:37 CEST] <thebombzen> ah yes what you ahve is correct [18:59:40 CEST] <thebombzen> documentation agrees [19:00:04 CEST] <voip_> nieed i fifo_size=25600 also ? [19:00:57 CEST] <thebombzen> Yes [19:02:29 CEST] <voip_> sorry one more question :) buffer size 25600 is ok, or i should experiment and increase/decrease ? [19:27:08 CEST] <artectrex_> iive: Well, I didn't really look into it myself, and trusted word of others, who probably trusted others who were talking out of their neck. I can't find any non-Telegram code actually under GPL in the repo, so they are probably not infringing on your rights. They still are violating the GPL by not updating their own code which is under "GPLv2 or later". I was hoping the FFmpeg project would be able to pressure them into updating their code but that [19:27:08 CEST] <artectrex_> was probably false hope. I want to thank you guys anyways, without FFmpeg lots of software I use daily would not be what it is today. Have a nice evening/afternoon/whatever [19:31:46 CEST] <pzy> keep fightin' the good fight! [19:37:09 CEST] <artectrex_> I don't really know what to do now. I certainly cannot litigate, would the FSF consider (threatening) legal action for something like this? And they use OpenSSL licensed stuff, is that violated in any way by Telegram not releasing their code? Doesn't seem like it. Oh well, they'll release it eventually I guess? It's just infuriating to me that a major selling point of the app is being FOSS, and it is *not* FOSS! [19:37:39 CEST] <artectrex_> Again, thanks a bunch, and see ya [20:43:28 CEST] <tokage> Dark_Arc: the license problem should be resolved in a few hours https://twitter.com/durov/status/847454485882355713 [20:43:57 CEST] <tokage> but the question is how long will it take next time? :-) [21:52:53 CEST] <alexpigment> has anyone used x262 yet? [21:53:12 CEST] <alexpigment> also, is there a way to build ffmpeg with x262 support? [21:59:45 CEST] <JEEB> alexpigment: x262 is pretty much dead by now [21:59:55 CEST] <JEEB> people are instead using the mpeg2 video encoder from lavc I think [22:00:07 CEST] <alexpigment> the one built into FFMPEG? [22:00:10 CEST] <JEEB> yes [22:00:17 CEST] <alexpigment> man, it's such a terrible encoder [22:00:24 CEST] <alexpigment> i was hoping x262 was better [22:00:44 CEST] <JEEB> in standard libavcodec tradition libavcodec's thing has quite a bit of params you need to just know to optimize it [22:00:48 CEST] <kepstin> if you know the all the tweak options, ffmpeg's encoder is ok, but really slow :/ [22:01:09 CEST] <alexpigment> i spent almost a week last year trying to match the quality of mainconcept [22:01:11 CEST] <kepstin> iirc it doesn't have rate distortion enabled by default, for example [22:01:25 CEST] <alexpigment> it was just terrible, no matter what settings i used [22:01:29 CEST] <JEEB> not sure x262 really beat lavc mpeg2 in the end, the development just stopped in favour of lavc after some things [22:01:47 CEST] <JEEB> and I don't think lavc has a libx262 wrapper [22:02:01 CEST] <alexpigment> kepstin: i can't recall if i messed with rate distortion last time i looked into this [22:02:19 CEST] <kepstin> it probably wouldn't be hard to hack a lavc wrapper together, it would be mostly copy/paste of the x264 wrapper [22:02:26 CEST] <JEEB> yea [22:02:42 CEST] <alexpigment> well, i guess a quality comparison between the two is in order first [22:03:06 CEST] <alexpigment> anyway, i'll take a look at all this stuff again. maybe 2017 me has a bit more information than 2016 me [22:03:08 CEST] <kepstin> somewhere I have some notes about mpeg2 encoding with lavc, lets see what I can dig up... [22:03:23 CEST] <alexpigment> kepstin, that would be awesome, to be honest [22:07:22 CEST] <JEEB> I also remember the x264dev blog having some lavc parameters back when D_S did a comparison on various encoders [22:08:53 CEST] <alexpigment> it's possible the problems i was seeing were related to trying to create strict DVD-formatted encodes [22:08:57 CEST] <kepstin> alexpigment: https://gist.githubusercontent.com/kepstin/9d60cde1f1714657737b8bdc58d673c5… is the options I was using when looking at DVD-spec encoding with lavc [22:09:02 CEST] <alexpigment> rather than a progressive HD encode, for example [22:09:31 CEST] <alexpigment> kepstin, you are awesome [22:09:31 CEST] <kepstin> alexpigment: with non-dvd stuff, drop the vbv options (bufsize, maxrate) and increase the bframes (-bf) [22:09:37 CEST] <alexpigment> i'm going to take a look at these [22:09:43 CEST] <alexpigment> yeah, it's all DVD testing [22:09:57 CEST] <kepstin> some of those options are a bit wierd or just guesses, or silly extra-large [22:10:00 CEST] <alexpigment> i don't recall what all params i used in the past, but this will be a good starting point [22:10:15 CEST] <kepstin> e.g. I think -dia_size is a bit ridiculous there [22:10:32 CEST] <kepstin> but not sure, and that option is a weird bitfield with mpeg2video [22:10:49 CEST] <alexpigment> i'm a bit green on dia_size [22:11:00 CEST] <alexpigment> i mean it involves motion estimation [22:11:15 CEST] <alexpigment> but it's nothing that changes how the video is decoded or how in spec the file is, right? [22:11:41 CEST] <kepstin> dia_size basically says how far away to look for motion vectors for optimizing the encode, but the field also encodes some details about the search algorithm in the upper bits [22:11:49 CEST] <kepstin> so the number itself is meaningless as-is [22:12:29 CEST] <alexpigment> k [22:12:35 CEST] <kepstin> '784' is actually 16 (counted in macroblocks, i think), with some extra bits set. [22:12:44 CEST] <kepstin> 16 is the max, iirc [22:12:55 CEST] <kepstin> or at least stuff starts breaking if you set it higher [22:13:22 CEST] <kepstin> or maybe i'm completely wrong! [22:13:27 CEST] <kepstin> it's a weird option :) [22:13:35 CEST] <alexpigment> k, i'll start at that, and assuming the quality is good, i'll work my way backward on removing those parameters or changing their values [22:13:43 CEST] <JEEB> lavc lossy encoders are not known for their easy understandability :) [22:13:54 CEST] <alexpigment> that is entirely true :) [22:14:34 CEST] <kepstin> x264 really revolutionized video encoder usage with that preset system [22:14:47 CEST] <alexpigment> yeah, i wasn't sure if it was the first [22:14:51 CEST] <kepstin> turned it from a cargo cult of weird options nobody understood into "pick how fast you want it" [22:14:51 CEST] <alexpigment> but certainly the first i knew about [22:15:10 CEST] <alexpigment> you didn't have to be an x264 dev to know how to use it :) [22:16:11 CEST] <kepstin> old versions of x264 suffered from the same "lots of parameters nobody understands" thing as most other encoders, the preset system was added later. [22:16:22 CEST] <JEEB> yup [22:16:37 CEST] <JEEB> and the defaults were set to preset medium [22:17:30 CEST] <kepstin> (and old versions of ffmpeg made it worse, by default it set some of the options on old x264 versions to settings bad enough that there's still code to this day in x264 which makes it error out if that combination of settings is used) [22:18:13 CEST] <alexpigment> i'm just glad that there are a lot of use-case parameters you can choose with the major codecs. like mpeg-2 has "target", x264 has bluray-compat, x265 has uhd-bd, etc [22:18:49 CEST] <alexpigment> not that those are equivalent to presets, but at least help you easily configure a bunch of parameters you don't know about to the appropriate settings for your use case [22:19:56 CEST] <JEEB> blu-ray compat doesn't really do much else than limit the coding in certain ways. you still have to set the level (refs) and VBV/HRD limiting [22:21:04 CEST] <alexpigment> yeah, it's true [22:21:15 CEST] <alexpigment> but at least there are sites that have a lot of documentation on what to set [22:21:44 CEST] <alexpigment> i tend to use it on non-blu-ray encodes just in case i want to go back and use tsmuxer to archive it to a playable disc [22:22:00 CEST] <alexpigment> the parameters are usually within reason enough to play on the players i've tested [22:22:31 CEST] <alexpigment> but yeah, there's a website that i've referenced a bunch with an exhaustive list of x264 parameters for every format in the blu-ray spec [22:24:51 CEST] <JEEB> the most limiting stuff wrt bluray-compat is something you really don't want to enable globally. it's a weird limitation of the BD spec and BD spec only [22:25:18 CEST] <JEEB> if you're not using actual BD mastering tools that try to verify the stream then it really doesn't matter :D [22:25:26 CEST] <kepstin> alexpigment: also see https://ffmpeg.org/faq.html#Which-are-good-parameters-for-encoding-high-qua… [22:25:36 CEST] <JEEB> the HRD params are what really matters :P [22:25:44 CEST] <JEEB> and being within level 4.1 [22:25:45 CEST] <JEEB> or so [22:28:20 CEST] <sikilikis> anybody on that can provide assistance? Google has failed me [22:29:05 CEST] <sikilikis> like furq since you been such a homie so far [22:33:04 CEST] <Fenrirthviti> asking to ask is so 2005 [22:33:32 CEST] <sikilikis> lol [22:33:47 CEST] <sikilikis> I cant be talking to the air. People will think I'm crazy [22:34:13 CEST] <sikilikis> anyways you wanna take a crack at this? [22:34:56 CEST] <Fenrirthviti> I have no idea, you've still given no information on the actual issue :P [22:35:26 CEST] <Fenrirthviti> Probably start here: http://rurounijones.github.io/blog/2009/03/17/how-to-ask-for-help-on-irc/ [22:35:26 CEST] <sikilikis> https://pastebin.com/kXEtkRgf [22:35:37 CEST] <sikilikis> commad and the log output [22:36:05 CEST] <sikilikis> I'm live streaming to youtube. Itts looping through images, overlaying text, and playing music [22:38:21 CEST] <sikilikis> ffmpeg version is 3.2.4 if that helps. I didn't use whatever is the latest. It's running on a raspberry pi 3 [22:39:34 CEST] <Fenrirthviti> trying to remember where the heck the list of error codes for librtmp is [22:41:44 CEST] <Fenrirthviti> I think 32 is packet failed to read? [22:42:48 CEST] <alexpigment> kepstin, do you combine all these mpv_flags with value:value:value ? [22:43:11 CEST] <kepstin> alexpigment: I think you can leave them separate or put them together with + [22:43:16 CEST] <kepstin> alexpigment: not sure :/ [22:43:18 CEST] <alexpigment> k [22:43:23 CEST] <sikilikis> it doesnt happen immediately by the way. [22:43:33 CEST] <sikilikis> It'll run for hours before it hits this [22:47:39 CEST] <tmm1> anyone know if freebsd has a /dev/dri equivalent for vaapi hwaccel [22:47:39 CEST] <Fenrirthviti> sikilikis: Error 104 occurs when connection is closed by remote end. <-- there we go [22:47:44 CEST] <Fenrirthviti> you're being dropped. [22:47:47 CEST] <sikilikis> by remote end? [22:47:52 CEST] <sikilikis> wtf so its youtube's fault? [22:50:16 CEST] <sikilikis> well shit [22:51:28 CEST] <sikilikis> i'm googling some more and people are saying that timestamp issues are the most likely reason youtube would close the connection. Is having +getpts not enough? [22:52:50 CEST] <alexpigment> kepstin: it's pretty funny rendering an MPEG-2 480i video at 8fps on a core i7 :) [22:53:14 CEST] <kepstin> alexpigment: I love how there's basically no multithreading in that encoder. [22:53:17 CEST] <alexpigment> this is a good sign though. it never took this long before with any of my settings, so i'm looking forward to some quality comparisons [22:53:54 CEST] <kepstin> in my experience, the DVD restrictions are so awful that there's some videos that are absolutely never gonna look good :/ [22:53:56 CEST] <alexpigment> oh you're right [22:54:14 CEST] <alexpigment> yeah, it's a pretty bad spec [22:54:38 CEST] <alexpigment> i don't consider it a reference quality format by any means [22:54:53 CEST] <alexpigment> blu-ray, on the other hand, they did pretty well with that as a home video format [22:55:50 CEST] <kepstin> particularly with modern BDs using a good h264 encoder, by someone who knows how to prepare video to reduce banding, etc. it can look really good. [22:56:04 CEST] <JEEB> yup [22:56:11 CEST] <JEEB> unlike DVD which was bit starved from the beginning [22:56:29 CEST] <JEEB> > 8 megabits per sec maxrate > bufsize of 1.5 or so megabits [22:56:30 CEST] <alexpigment> yeah, even if you don't use all the allotted bitrate - most use ~20mbps - it's still better quality than anything else out there [22:57:11 CEST] <JEEB> the least used thing in BDs is the 720p60/1.001 mode [22:57:16 CEST] <alexpigment> yeah, 8mbps mpeg-2 wasn't even effective for one of the common uses - converting analog tapes to digital [22:57:26 CEST] <sikilikis> what does the igndts flag do? [22:57:30 CEST] <JEEB> alexpigment: the bufsize is what kills it [22:57:44 CEST] <JEEB> like, if you are up to the maxrate it's like less than 1/4th of a second [22:57:51 CEST] <alexpigment> jeeb: i've actually used the 720p60 mode quite a bit ;) [22:58:14 CEST] <JEEB> alexpigment: I've mostly seen it on extras discs as back backgrounds for java games [22:58:21 CEST] <JEEB> and one demoscene blu-ray I think [22:58:21 CEST] <alexpigment> there are a handful of TV channels (ABC, FOX) that broadcast in 720p60. so i archive stuff to that spec when it comes from those channels [22:58:38 CEST] <kepstin> what's even worse is when they put 24p content on dvds telecined and encoded as interlaced, rather than progressive with field repeat flags [22:58:42 CEST] <alexpigment> i'd say the very least used format is 720p24 [22:58:48 CEST] <kepstin> so much efficiency loss from the interlaced encoding :( [22:59:06 CEST] <JEEB> well that doesn't actually give you much compared to just doing 1080p24 or 1080p24/1.001 :P [22:59:10 CEST] <alexpigment> kepstin: yeah, but it can be successfully reversed at least [22:59:11 CEST] <JEEB> other than longer GOPs [22:59:16 CEST] <JEEB> (Ž4@) [22:59:39 CEST] <alexpigment> yeah, i'm just saying that 720p24 is somehow part of the spec. i've never seen it used once nor used it myself [22:59:46 CEST] <alexpigment> even on bonus material, i've never seen it [22:59:53 CEST] <kepstin> alexpigment: not always, because in some cases there's such insufficient bitrate that the fields leak into eachother :( [23:00:12 CEST] <kepstin> so you have to filter it anyways to remove some semi-combing artifacts [23:00:39 CEST] <JEEB> but yea, I've seen a few 3DCG things that would have been awesome in 720p60/1.001, yet it's always done in 1080p24 - some even emulating the feel of 12Hz animation [23:00:46 CEST] <JEEB> which makes big ol' JEEB sad :< [23:01:22 CEST] <alexpigment> kepstin: true. i do know that 480p24 with pulldown has caused issues for me in that past as a consumer. i have 100s of music video DVDs that i ripped into a sorted collection. the ones in 480p24 always caused weird playback problems when ripped from the disc. the only way around it that i found was to play them on a dvd player, then capture the signal :(( [23:02:24 CEST] <kepstin> alexpigment: modern versions of ffmpeg can actually handle the 480p24 with pulldown stuff - you use the "repeatfields" filter, then detelecine it afterwards. [23:02:34 CEST] <alexpigment> JEEB: on that note, i hate how netflix and other streaming services do 1080p24 rather than 720p60 on a lot of stuff originally recorded in 1080i30/1080p60. unfortunately they don't care about original framerate [23:03:39 CEST] <alexpigment> kepstin: i'll have to try that out. interestingly, the whole point of that ripping project was to have untouched MPEG-2 masters, but that pulldown problem kinda forced me into some sort of secondary encoding anyway. i'll definitely keep that one in mind [23:05:16 CEST] <kepstin> the issue with a lot of stuff on dvd in p24 with pulldown is that it's not consistently applied - it looks like they often feed i60 into an encoder, and the encoder puts some frames in progressive if it matches a telecine pattern [23:05:26 CEST] <kepstin> so some parts are p24 others are i60 [23:05:50 CEST] <kepstin> the repeatfields filter turns it into all i60 so you can re-do the detelecine [23:06:34 CEST] <alexpigment> yeah, the weird part of it all is that standalone blu-ray players have no problem, but once ripped into separated vobs and played back in any software player, you'd get problems where there would be a frame that was interlaced and mixed with the previous and next frame [23:07:01 CEST] <alexpigment> sorry, i meant standalone dvd and blu-ray players [23:07:41 CEST] <alexpigment> but that makes sense forcing to 60i then detelecining [23:08:28 CEST] <kepstin> well, most of the standalone dvd players output 60i anyways... [23:08:55 CEST] <kepstin> I suppose some have "progressive scan", but they're probably running through a detelecine on the box anyways to handle dvds which weren't encoded progressive [23:09:06 CEST] <alexpigment> i suppose so. i just didn't understand why software players were so confused by the vobs [23:10:25 CEST] <kepstin> i think the classic mplayer/mencoder actually had some code to handle this, back in the day [23:10:56 CEST] <mavi> Does anyone know why the nlmeans filter only goes at 2fps while the hq3d ones goes at 83 on the same pc? Is it a broken build or is it just that slow? [23:10:58 CEST] <kepstin> until that repeatfields filter was added to ffmpeg, I kept around an old mencoder binary because it had a filter which did that ("softpulldown") [23:11:01 CEST] <mavi> using the latest nightly version [23:12:20 CEST] <kepstin> mavi: nlmeans is just a really slow filter (the algorithm's a lot more complex) [23:17:03 CEST] <alexpigment> i love this message for mpeg2video encoding: [23:17:10 CEST] <alexpigment> "Impossible bitrate constrains, this will fail" [23:17:29 CEST] <mavi> kepstin, using handbrake it's slower but not 2fps slow. It seems like it's ffmpeg. [23:17:35 CEST] <alexpigment> ok then, but either actually fail or don't give me the message [23:18:16 CEST] <mavi> Via ffmpeg the hq3d filter same settings goes at 80fps, while the nlmeans=s=1 goes at 2. On handbrake it is only 20% slower than hq3d. [23:18:51 CEST] <kepstin> mavi: huh, i thought handbrake mostly used ffmpeg filters? I guess not. It might be that the handbreak version is multithreaded and ffmpeg's isn't. [23:18:52 CEST] <mavi> So I believe the implementation must be either wrong, or i have a nightly ffmpeg from a few days ago which has an older nlmeans filter? [23:19:09 CEST] <mavi> Yea they do. That's why it's odd... [23:19:19 CEST] <kepstin> there's a few ffmpeg filters that are technically correct, but with slow implementations [23:19:24 CEST] <kepstin> nnedi has that issue too [23:19:50 CEST] <mavi> where it's like 20x slower? [23:20:25 CEST] <kepstin> mavi: well, first thing to do is make sure you're actually using comparable settings. [23:20:58 CEST] <mavi> I'm using the same test file. With weak settings on both hq3d and nlmeans [23:21:11 CEST] <mavi> Same settings for everything other than the denoise filters. [23:22:03 CEST] <kepstin> alexpigment: yeah, that message is kinda silly. you get it when bitrate and max rate are the same and minrate isn't set (i.e. bitrate=maxrate, but you aren't doing cbr) [23:22:31 CEST] <kepstin> alexpigment: when that really should be a perfectly valid option for "just use as much bitrate as you can, please", at least with 2-pass mode. [23:24:21 CEST] <ChocolateArmpits> Is fifo muxer broken? I can't get it to use rtsp, it aborts with no message [23:24:46 CEST] <mavi> btw when I use nr=300 combined with light hq3d 1.5:1.5:6:6 settings the file size and quality seems to be less than just light hq3d settings without nr300. Interesting stuff. Using it for lowbitrate crf encodes [23:25:06 CEST] <mavi> i mean file size is bigger than just the light denoiser, and the quality is slightly less. [23:25:21 CEST] <mavi> just using the denoiser alone yields better file sizes. [23:25:45 CEST] <kepstin> mavi: well, let us know if you come up with a patch to make ffmpeg's nlmeans filter faster. [23:26:02 CEST] <kepstin> (it's hasn't been touched since it was merged) [23:26:09 CEST] <mavi> I know what you mean. Just trying to see if it's a bug or it's my build. Trying to see if anyone has similiar results. [23:26:21 CEST] <mavi> or just a slow implementation. [23:26:48 CEST] <mavi> I'm not a coder. I appreciate everything the ffmpeg team has done. Just troubleshooting. [23:28:18 CEST] <alexpigment> ok, so i'm testing DVD with a 1080p60 source. part of my process is to scale down with lanczos then interlace with -vf interlace [23:28:25 CEST] <alexpigment> it was blurry, so i disabled the lowpass filter [23:28:47 CEST] <alexpigment> but then it gives me the warning: "Lowpass filter is disabled, the resulting video will be aliased rather than interlaced" [23:29:06 CEST] <alexpigment> is that just written poorly/incorrectly, or am i missing something about this warning? [23:29:15 CEST] <alexpigment> it will still be interlaced i'm pretty sure... [23:29:16 CEST] <kepstin> mavi: just keep in mind that the nlmeans implementation in ffmpeg appears to use different parameters from that in handbreak, so they're not directly comparable because they do different things. [23:30:00 CEST] <kepstin> mavi: given that ffmpeg is so much slower, i suspect it's using a larger search range than handbreak [23:30:16 CEST] <kepstin> (you might be able to tweak that) [23:30:45 CEST] <furq> nnedi being slow isn't really an issue with the filter afaik [23:31:03 CEST] <furq> nnedi is just that slow with one thread [23:31:10 CEST] <kepstin> furq: well, it could be faster if it was multithreaded, and some simd might help a bit [23:31:27 CEST] <furq> libavfilter can't do frame threading at all can it [23:31:34 CEST] <mavi> That means sense. I tried figuring out the customized settings but the documentation on it is somewhat sparse. Any ideas how to do a light denoise using custom ranges on ffmpeg's nlmeans filter? [23:31:54 CEST] <furq> mavi: like i said, it's really not worth worrying about this if you're encoding to crf 28 anyway [23:31:57 CEST] <furq> just use hqdn3d [23:32:17 CEST] <mavi> I currently am :) Just trying to squeeeeze before my 5k video mass encode. [23:32:41 CEST] <durandal_170> if you need only temporal denoiser try atadenoise [23:32:42 CEST] <kepstin> furq: the nnedia filter can be parallelized within frames easily so the filter could spawn threads internally. no frame threading needed. [23:32:44 CEST] <furq> you're not going to get nlmeans to run any faster without patching ffmpeg or filtering externally with vapoursynth [23:32:56 CEST] <furq> and the latter is really not worth the effort in this case [23:33:14 CEST] <kepstin> the ffmpeg nlmeans doesn't do temporal denoising at all, it's listed as a "todo" :) [23:33:23 CEST] <furq> nice [23:33:40 CEST] <mavi> yes it does seem like that is the cause. Vapoursynth seems to have the best implementation of nlmeans but yea not worth it for my current use. [23:34:13 CEST] <mavi> well then that takes care of that potential route. [23:34:15 CEST] <olspookishmagus> hello, I have a bunch of mp3s to which I would like to do the following in batch: 1. downmix them to mono 2. convert them from mono to stereo 3. convert them from variable bitrates to say: 96 CBR [23:34:20 CEST] <kepstin> I assume the only reason the handbreak nlmeans wasn't copied is that someone wanted an LGPL version for ffmpeg (handbreak is GPL) [23:34:20 CEST] <olspookishmagus> I guess that need some research [23:35:02 CEST] <kepstin> olspookishmagus: what do you even mean by "convert them from mono to stereo"? [23:35:37 CEST] <furq> https://github.com/VFR-maniac/VapourSynth-TNLMeans/blob/master/TNLMeans.cpp [23:35:41 CEST] <furq> there's an MIT implementation [23:35:56 CEST] <kepstin> olspookishmagus: keep in mind that the ffmpeg command line tool doesn't support batch/multi-file operations, so you'll have to write a shell or batch script to do that [23:36:29 CEST] <kepstin> furq: that file header says GPL-2? [23:36:43 CEST] <kepstin> (well, GPL-2+) [23:36:44 CEST] <furq> oh yeah i can't read [23:36:57 CEST] <furq> i saw a license header that wasn't two pages long and assumed it was MIT [23:37:04 CEST] <kepstin> also it's C++ :) [23:40:57 CEST] <thebombzen> where does the CUDA code for hevc_cuvid come from? [23:41:08 CEST] <thebombzen> is that part of libavcodec or is that part of the cuda installation [23:42:23 CEST] <alexpigment> olspookishmagus: are you on windows? [23:42:53 CEST] <olspookishmagus> kepstin: take that remaining mono channel and copy it, and somehow label the first LEFT channel and the other RIGHT? [23:42:59 CEST] <olspookishmagus> alexpigment: fortunately atm NO [23:43:13 CEST] <olspookishmagus> alexpigment: would you suggest using foobar2000? [23:43:18 CEST] <kepstin> olspookishmagus: ok, that's trivial to do. [23:43:39 CEST] <olspookishmagus> https://hydrogenaud.io/index.php/topic,111695.0.html [23:44:02 CEST] <alexpigment> olspookishmagus: i don't know too much about foobar2000. i was just going to say that i could easily help you create a batch script on windows to do that, but you're not on windows ;) [23:44:46 CEST] <alexpigment> kepstin probably knows more about the actual command line parameters to do what you want to do anyway though [23:46:32 CEST] <olspookishmagus> alexpigment: PowerShell? CygWin? [23:46:41 CEST] <alexpigment> but i assume it's like ffmpeg -i yourfile.mp3 -map_channel 0.0.0 -b:a 96kbps yourfile-left.mp3 -map channel 0.0.1 yourfile-right.mp3 [23:47:04 CEST] <llogan> i was assuming something more like: https://trac.ffmpeg.org/wiki/AudioChannelManipulation#Mixbothstereochannels… [23:47:31 CEST] <kepstin> olspookishmagus: to get a simple downmix/upmix, it should be enough to specify the '-ac' option when re-encoding; '-ac 1' will downmix to mono, then '-ac 2' will duplicate mono channel to stereo [23:47:43 CEST] <kepstin> (i.e. same data in both track) [23:47:52 CEST] <kepstin> if you want to do it in 1 step, you'll have to use filters [23:48:12 CEST] <alexpigment> oh i misread the original request. downmix to mono, then back to stero [23:48:15 CEST] <alexpigment> *stereo [23:48:16 CEST] <alexpigment> gotcha [23:48:42 CEST] <olspookishmagus> ok thanks kepstin, alexpigment [23:48:59 CEST] <olspookishmagus> and... sorry for breaking your converstation with my question [23:49:11 CEST] <alexpigment> you could also use pan i think. where you just make the pan ~50% for each side [23:49:30 CEST] <kepstin> olspookishmagus: and when encoding mp3, it will default to cbr if you just set a bitrate "-b:a 96K" [23:49:41 CEST] <kepstin> of course, 96K mp3 is kind of awful, but that's your call ;) [23:49:48 CEST] <olspookishmagus> what do you think on manipulating MP3 files with ffmpeg instead of avconv, lame, ... ? [23:50:19 CEST] <kepstin> olspookishmagus: I imagine is the same as avconv, except the awesome people in this irc channel will help you ;) [23:50:39 CEST] <kepstin> and ffmpeg uses lame to do the mp3 encoding anyways [23:50:59 CEST] <llogan> the output from libmp3lame, which ffmpeg can use to encode to MP3, should make an exact same output as lame (assuming the same input and options are used) [23:51:07 CEST] <olspookishmagus> oh ok [23:51:36 CEST] <furq> i'm surprised this hasn't come up yet, but [23:51:36 CEST] <furq> why [23:51:48 CEST] <llogan> i was wondering as well... [23:51:53 CEST] <olspookishmagus> kepstin: I don't have better option, my car hi-fi demands CBR on MP3s on CDs and I have bunch of youtube ripped MP3s (with youtube-dl) I want to burn [23:51:58 CEST] <kepstin> it won't be exactly the same, since lame writes some of the headers differently, but the actual audio data will be the same [23:52:06 CEST] <olspookishmagus> some albums are better quality but 96 kbit/s is just an example [23:52:08 CEST] <furq> i mean if you wanted to just take one channel and upmix that to stereo, it would sort of make sense [23:52:13 CEST] <furq> but why downmix and then upmix [23:52:18 CEST] <kepstin> olspookishmagus: sure, but why convert them to duplicated mono channels? [23:52:23 CEST] <llogan> i was referring to the actual audio stream, not any muxing [23:52:43 CEST] <olspookishmagus> furq: because some info might be just on the left channel and I want it to be on both after that? [23:52:58 CEST] <olspookishmagus> cc: kepstin [23:54:03 CEST] <olspookishmagus> it's rare but some people like to do left to right and right to left audio tricks on music but I don't really enjoy it as I'm suffering from severe hearing loss [23:54:13 CEST] <olspookishmagus> it's not cinema after all [23:55:07 CEST] <olspookishmagus> llogan: what's "muxing"? do you have a dictionary of terms I can have a look at? [23:56:09 CEST] <llogan> stuffing a muxer writes encoded packages to the output file [23:56:28 CEST] <llogan> omit that "stuffing". somehow pasted that... [23:57:32 CEST] <olspookishmagus> now why one would have stuffing on his clipboard? ^^ [23:57:35 CEST] <olspookishmagus> thanks llogan [23:57:39 CEST] <olspookishmagus> or hers [23:58:19 CEST] <kepstin> olspookishmagus: so, yeah, make a shell script loop that runs "ffmpeg -i "$INPUT" -af pan='stereo| c0 = 0.5*FL + 0.5*FR | c1 = 0.5*FL + 0.5*FR' -c:a libmp3lame -b:a 96K "$OUTPUT" [23:58:54 CEST] <llogan> the link i pasted is still in the "clipboard". i must have typed it but instantly forgot, wrote something else, then kept typing. [00:00:00 CEST] --- Fri Mar 31 2017

1 0

ffmpeg-devel.log.20170329
by burek 30 Mar '17

30 Mar '17

[00:01:19 CEST] <ubitux> mmh [00:01:41 CEST] <BBB> new patch sent [00:01:43 CEST] <ubitux> you shouldn't listen to me at this hour i think [00:01:46 CEST] <BBB> now it passes again [00:02:08 CEST] <ubitux> yeah, it ignores the problem [00:02:10 CEST] <ubitux> :)) [00:02:20 CEST] <BBB> I think thats OK [00:02:20 CEST] <ubitux> anyway, yeah i dunno [00:02:31 CEST] <BBB> the header is clearly not intended to be self-standing [00:02:32 CEST] <ubitux> http://ubitux.fr/pub/pics/2017-03-29-000007_640x400_scrot.png this is my current battle [00:02:44 CEST] <ubitux> my brain is not ready for some ffmpeg build system madness [00:02:49 CEST] <BBB> is that dosemu? [00:02:57 CEST] <ubitux> dosbox [00:03:10 CEST] <BBB> -enotsupported? [00:03:34 CEST] <ubitux> my first guess is #define HAVE_AVX2 1 [00:04:01 CEST] <ubitux> but dunno [00:04:06 CEST] <ubitux> so many things could be wrong [00:05:06 CEST] <BBB> no kidding [00:05:22 CEST] <BBB> so shall I push the h264/hevc/vp9/pthread_frame patches? [00:05:31 CEST] <BBB> it passes make fate with THREADS=3 and without threading on my system [00:05:39 CEST] <BBB> then you can poke the tsan instance [00:06:41 CEST] <ubitux> anytime [00:07:12 CEST] <BBB> Ill keep the skipheaders one local for now [00:07:20 CEST] <BBB> since I dont know if its correct [00:07:28 CEST] <jamrial> ubitux: try things like --disable-avx or --disable-inline-asm [00:07:43 CEST] <ubitux> jamrial: i'm rebuilding with --disable-asm currently [00:08:04 CEST] <ubitux> (does it imply --disable-inline-asm?) [00:08:13 CEST] <cone-560> ffmpeg 03Ronald S. Bultje 07master:f8c019944d45: vp9: re-split the decoder/format/dsp interface header files. [00:08:14 CEST] <cone-560> ffmpeg 03Ronald S. Bultje 07master:b823bbc10cc7: vp9: split out loopfilter functions in their own source file. [00:08:15 CEST] <cone-560> ffmpeg 03Ronald S. Bultje 07master:6d0d1c4a43f5: vp9: split out reconstruction functions in their own source file. [00:08:16 CEST] <cone-560> ffmpeg 03Ronald S. Bultje 07master:0c466417846f: vp9: split out generic decoding skeleton interface API from VP9 types. [00:08:17 CEST] <cone-560> ffmpeg 03Ronald S. Bultje 07master:8c2aa45d4a99: h264: revert 1189af429211ac650aac730368a6cf5b23756605. [00:08:18 CEST] <cone-560> ffmpeg 03Ronald S. Bultje 07master:bddabfaab658: hevc: initialize no_rasl_output_flag in hevc_frame_start(). [00:08:19 CEST] <cone-560> ffmpeg 03Ronald S. Bultje 07master:027ee9b3ed69: pthread_frame: don't sync items between threads for intra-only codecs. [00:08:24 CEST] <ubitux> nice [00:08:54 CEST] <BBB> youll still see some h264 failures related to def_build_list(), I have an idea on fixing it which Ill explore next [00:09:01 CEST] <BBB> hevc may be clean [00:09:08 CEST] <BBB> intra codecs should be clean [00:09:23 CEST] <BBB> gonna go home, poke me tomorrow with results ;) [00:09:31 CEST] <ubitux> it's running [00:09:35 CEST] <ubitux> sure, will do [00:12:19 CEST] <ubitux> jamrial: yeah well, none of it helps [00:13:15 CEST] <jamrial> then fuck freedos :p [00:13:31 CEST] <ubitux> :( [00:14:12 CEST] <jamrial> how about --disable-optimizations? [00:14:31 CEST] <jamrial> maybe gcc with -O3 is doing something wrong [00:14:31 CEST] <drv> what instruction is it hitting? djgpp has a working gdb port, I think [00:18:27 CEST] <ubitux> drv: no gdb here but i may be able to found out with the xcompiled objdump [00:19:22 CEST] <drv> plus I think dosbox only emulates original Pentium at best, so no MMX or anything fancier [00:19:29 CEST] <drv> probably not cmov etc. either [00:19:43 CEST] <ubitux> mmh [00:20:15 CEST] <ubitux> maybe i'll try again dosemu with their full cpu emulation [00:20:24 CEST] <ubitux> now that i have that dpmi thing [00:20:32 CEST] <ubitux> i have no idea what am i'm doing [00:23:28 CEST] <drv> I also have this thing set in my .dosemurc, don't know if it's still relevant: $_ignore_djgpp_null_derefs = (1) [00:26:22 CEST] <ubitux> so i have an invalid opcode @ eip=45909a [00:26:29 CEST] <ubitux> 45909a: 0f 4d 45 d8 cmovge eax,DWORD PTR [ebp-0x28] [00:26:32 CEST] <ubitux> would that be this? [00:26:42 CEST] <drv> in dosbox? that is probably due to not emulating cmov [00:26:49 CEST] <ubitux> yes in dosbox [00:27:27 CEST] <drv> cmov is P6 or newer, way too fancy for 90s DOS games :) [00:27:50 CEST] <ubitux> mmh ok, so i will actually need dosemu [00:28:07 CEST] <ubitux> which is much more of a pita to use than dosbox :( [00:29:37 CEST] <BBB> I think you just want to compile the binary without cmov [00:29:39 CEST] <jamrial> --disable-inline-asm --cpu=pentium should in theory prevent any cmov instruction being assembled [00:29:48 CEST] <BBB> right [00:30:08 CEST] <BBB> Im still going to wonder why on earth you want to run ffmpeg on dos, but Ill just shut up now ;) [00:32:09 CEST] <ubitux> jamrial: omg yes [00:32:23 CEST] <Compn> dos pople r weird [00:32:33 CEST] <ubitux> http://ubitux.fr/pub/pics/2017-03-29-003228_640x400_scrot.png [00:32:35 CEST] <ubitux> alright [00:32:35 CEST] <jamrial> \o/ [00:32:39 CEST] <ubitux> now i need to run FATE [00:33:15 CEST] <kierank> haha SET BLASTER [00:33:32 CEST] <ubitux> blast from the past yeah [00:33:33 CEST] <kierank> that's a blast from the past (no pun intended) [00:33:37 CEST] <ubitux> ;) [00:34:00 CEST] <jamrial> try to remove --disable-optimizations first, see if a build with -O3 also runs [00:34:10 CEST] <atomnuker> see I'm not crazy for using dosbox to emulate windows 98, ubitux's probably decoding vp9+opus from youtube [00:34:17 CEST] <jamrial> -O1 or whatever is used without it is super slow [00:35:13 CEST] <ubitux> i think i'll need to make dosemu work though [00:35:16 CEST] <jamrial> wonder why it didn't output the "Hyper fast Audio and Video encoder" line or the usage line, though [00:36:18 CEST] <drv> in theory, just --cpu=pentium should be enough, right? (assuming we protect all inline asm with the right feature macros) [00:36:20 CEST] <BBB> jamrial: because on dos, its not fast ;) [00:36:26 CEST] <jamrial> lol [00:37:19 CEST] <jamrial> drv: yeah, inline asm using cmov should be at least under a HAVE_I686 check [00:37:40 CEST] <ubitux> BBB: http://fate.ffmpeg.org/report.cgi?time=20170328223136&slot=x86_64-archlinux… [00:37:42 CEST] <ubitux> :) [00:37:57 CEST] <jamrial> or well, HAVE_FAST_CMOV [00:38:46 CEST] <ubitux> we went from 2828/3347 to 3015/3347 on tsan [00:38:59 CEST] <BBB> not bad [00:39:07 CEST] <BBB> crap dnxhr still fails [00:39:18 CEST] <jamrial> it used to be 2470 two days ago [00:39:29 CEST] <BBB> and all h264 ones are the multi-slice ones [00:39:34 CEST] <BBB> are there h264 tests that pass? [00:39:42 CEST] <BBB> all single-slice ones should pass now [00:40:28 CEST] <ubitux> the filter test failing seems to be due to lavc races [00:41:31 CEST] <ubitux> jamrial: works without --disable-optimization yeah, which is cool [00:42:36 CEST] <jamrial> ok, next step is removing --disable-inline-asm so it may use the pre-i686 inline stuff from mathops and cabac :p [00:42:47 CEST] <ubitux> well, we need to have the proper output of ffmpeg.exe first [00:43:08 CEST] <ubitux> because yeah, you noticed the Hyper fast thing is not present [00:43:19 CEST] <ubitux> it probably fails one way or another [00:43:39 CEST] <ubitux> any command ends up with that output [00:43:39 CEST] <jamrial> i suppose exit_program() was called somewhere without an av_log call [00:43:59 CEST] <ubitux> maybe at the first pthread thing [00:44:01 CEST] <ubitux> :p [00:44:25 CEST] <ubitux> they're disabled though [00:44:36 CEST] <ubitux> oh well, i'll see that later [00:44:40 CEST] <ubitux> enough BS for now [00:44:58 CEST] <jamrial> maybe some alloc() failure [00:45:08 CEST] <jamrial> those almost never get a log message and just bail out [00:45:40 CEST] <ubitux> ah, yeah :) [00:53:07 CEST] <ubitux> so, for most of the remaining tsan issues, it always happen in that update_context_from_thread() for random fields [00:53:20 CEST] <ubitux> is it a single issue or multiple ones? [00:55:42 CEST] <jamrial> michaelni: your ffprobe -show_log patch broke some ffprobe tests on SunOS [00:56:51 CEST] <jamrial> with gcc, since suncc hasn't worked in forever [00:59:29 CEST] <ubitux> lol [00:59:39 CEST] <ubitux> i was looking at the fic failure which was different that the others [00:59:43 CEST] <ubitux> then looked at the code [00:59:45 CEST] <ubitux> and saw: [00:59:53 CEST] <ubitux> * Set the frametype to I initially. It will be set to P if the frame [00:59:55 CEST] <ubitux> * has any dependencies (skip blocks). There will be a race condition [00:59:57 CEST] <ubitux> * inside the slice decode function to set these, but we do not care. [01:00:06 CEST] <ubitux> we don't need tsan [01:00:11 CEST] <ubitux> git grep 'race cond' is enoug [01:00:15 CEST] <ubitux> enough [01:01:17 CEST] <ubitux> the use of atomics could solve that case i suppose [01:02:55 CEST] <ubitux> the fifo-muxer-h264 one is funky [01:04:46 CEST] <michaelni> jamrial, do you have gdb output / backtrace ? [01:05:30 CEST] <jamrial> michaelni: no, i looked at the fate slot in question, sorry [01:05:42 CEST] <jamrial> Owner seems to be "opencsw_buildbot", so no idea who manages it [01:11:02 CEST] <BBB> how do I disable stirpping in my build again? [01:11:15 CEST] <BBB> (e.g. dont strip ffmpeg/ffplay) [01:11:39 CEST] <atomnuker> BBB: --disable-stripping [01:11:55 CEST] <BBB> is there some setting in my config.mak that corresponds to that option? [01:12:11 CEST] <BBB> (e.g. if I dont want to re-run configure) [01:12:32 CEST] <atomnuker> I don't think so [01:13:46 CEST] <BBB> ah I can just add echo to STRIP= [01:14:00 CEST] <iive> ffmpeg_g should remain unstripped at all times, i think [01:14:07 CEST] <jamrial> that's what --disable-stripping does [01:14:25 CEST] <jamrial> makes STRIP an echo command [01:16:09 CEST] <jamrial> iive: yeah, but make fate calls the non _g binaries [01:39:16 CEST] <BBB> hey guess what - tsan found an actual race condition this time [02:02:51 CEST] <BBB> I believe with these patches, the only codecs reporting race conditions are hevc and h264& both because of some multi-slice crap [02:03:00 CEST] <BBB> (video codecs) [02:03:03 CEST] <BBB> oh and lagarith [02:58:43 CEST] <tmm1> well i think the answer to my question is no, you cannot reliably detect interlacing _just_ with SPS. you need to look at the slices to see [03:02:32 CEST] <thebombzen> out of curiosity, what is the usual amount of time it takes to review a patch? [03:03:39 CEST] <kierank> couple of days [03:04:30 CEST] <thebombzen> thx [03:28:52 CEST] <michaelni> jamrial, cannot reproduce a issue with solaris (that is with gcc 4.8.3, ill try a closer version) [03:42:16 CEST] <michaelni> and installing gcc-5 succeeds but no gcc-5 seems to have been installed. If someone knows how to install gcc-5 on solaris ping me [04:03:06 CEST] <cone-874> ffmpeg 03James Almer 07master:c31cbeef584f: aarch64/vp9dsp: add missing header includes [04:09:57 CEST] <cone-874> ffmpeg 03James Almer 07master:53f1d6a8ee36: fate: add tests for ac3_fixed 5.1 downmix [04:09:58 CEST] <cone-874> ffmpeg 03James Almer 07master:91ccd38c0bef: avcodec/ac3dsp: add special-case handling for the C downmix_fixed function [04:27:20 CEST] <tmm1> ugh, apparently h264_analyze has a bug where it shows the wrong value for frame_mbs_only_flag [09:39:32 CEST] <ubitux> i'm in the process of renaming av_4cc2str() to av_fourcc2str() [09:39:45 CEST] <ubitux> as it seems people prefer that name [09:40:16 CEST] <ubitux> if you have a different opinion, now is the time [09:40:46 CEST] <ubitux> btw, any help deciphering what Carl Eugen just tried to ask me is welcome too [09:53:55 CEST] <mateo`_> michaelni: I'm investigating the ts/duration differences you reported [09:56:30 CEST] <durandal_170> ubitux: carl is asking again same thing [09:57:19 CEST] <ubitux> i'm not sure if he's trying to delay the patch or actually geniully don't understand what the macro does [09:57:31 CEST] <thebombzen> what is going on beweheen carl eugen and wm4 :O [09:58:29 CEST] <ubitux> damn, BBB fixed a ton of threading issue this night [09:58:49 CEST] <thebombzen> have they been committed? [09:58:55 CEST] <ubitux> no, patches on the ml [09:59:14 CEST] <thebombzen> ah okay [10:15:43 CEST] <mateo`_> michaelni: I can't reproduce the differences you reported, using the following method (based on what you mentionned in your email) http://sprunge.us/DWAJ [10:25:48 CEST] <ubitux> mateo`_: he's remuxing to mp4, not mpg [10:26:18 CEST] <mateo`_> oh, thanks [12:18:45 CEST] <cone-796> ffmpeg 03wm4 07master:4cf1f68903ce: pthread_frame: minor simplification to error handling [12:59:50 CEST] <ubitux> BBB: thanks for your threading patches :) [13:05:42 CEST] <mateo`_> I'm going to port the examples to the new decoding,encoding api [13:15:19 CEST] <ubitux> merge time for me [13:29:50 CEST] <cone-796> ffmpeg 03Anton Khirnov 07master:40aaa8dadfd1: examples/avcodec: split audio encoding into a separate example [13:29:51 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:b785af48687f: Merge commit '40aaa8dadfd1c69ff4460d04750e1403b5535a6d' [13:30:46 CEST] <cone-796> ffmpeg 03Anton Khirnov 07master:c00a11ab383f: examples/encode_audio: constify AVCodec instances [13:30:47 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:f38e7566c69b: Merge commit 'c00a11ab383ff276a2ab2fdba577945e48d465be' [13:31:12 CEST] <PaoloP> Hello wm4, thanks for the feedback. about "better to allocate the packet with the appropriate functions" ---> should I use av_packet_alloc() ? [13:31:20 CEST] <wm4> yes [13:32:38 CEST] <cone-796> ffmpeg 03Anton Khirnov 07master:f76698e759a0: examples/encode_audio: use the AVFrame API for allocating the data [13:32:39 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:780cc080d856: Merge commit 'f76698e759a08e8d3b629c06edb0439f474e7fee' [13:34:42 CEST] <PaoloP> wm4: ok. 2) "Some encoders (probably not all) signal what rates and formats they support in the AVCodec struct" <-- I already added a comment ("You can use any other sample rate provided by the input file on condition that it is supported by the codec (use AVCodec::supported_samplerates for listing supported sample rates"). would it be better if I use the get_default_format() function + get_first_sample_rate_in_the_codec_list() function? (I don't [13:34:44 CEST] <PaoloP> remember their names, but you understand) [13:37:34 CEST] <BBB> ubitux: youre welcome ;) [13:37:54 CEST] <BBB> ubitux: of all video decoders, only h264 and the ones based on mpegvideo have outstanding issues [13:38:34 CEST] <BBB> ubitux: frame-mt encoding has an issue (see utvideoenc) which I suppose is identical to the decoder one, mpegvideo has some pretty significant issues that I dont want to look at right now, and h264 has multi-slice issues [13:38:45 CEST] <BBB> ubitux: other than that its just filters, audio or other unrelated things [13:39:00 CEST] <ubitux> it's pretty cool to cleanup all the noise so we can focus on the real problems :) [13:39:06 CEST] <BBB> Im looking at h264 ATM [13:39:08 CEST] <BBB> yeah agreed [13:39:19 CEST] <BBB> the two avctx assignments are actual, real bugs [13:39:24 CEST] <ubitux> yep [13:39:26 CEST] <BBB> theyre not severe or anything, but they are bugs [13:39:39 CEST] <ubitux> i suppose they could cause logging errors? [13:39:53 CEST] <BBB> if you read profile and it changes, it would not be picked up by the user thread [13:40:09 CEST] <BBB> so the user thread would only ever read profile from once every N frames (where N = n_threads) [13:40:17 CEST] <BBB> (effectively) [13:40:20 CEST] <ubitux> ok [13:40:27 CEST] <BBB> thats a bug [13:40:35 CEST] <BBB> is it severe? probably not [13:40:54 CEST] <BBB> Im currently looking at a very, very weird h264 one and Im not quite sure whats going on there& [13:42:25 CEST] <BBB> hm& [13:42:34 CEST] <BBB> do mpegvideo and h264 have the avctx assignment issue also? [13:42:41 CEST] <BBB> now that would be incredibly interesting [13:43:24 CEST] <BBB> h264 doesn't [13:44:30 CEST] <cone-796> ffmpeg 03Anton Khirnov 07master:f5df897c4b61: examples/avcodec: split audio decoding into a separate example [13:44:31 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:878070cc5606: Merge commit 'f5df897c4b61985e3afc89ba1290649712ff438e' [13:45:35 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:9bed10afb8b2: doc/examples/encode_audio: add missing return [13:46:01 CEST] <BBB> I think mpeg4 does... [13:46:03 CEST] <BBB> hmm...... [13:46:24 CEST] <cone-796> ffmpeg 03Anton Khirnov 07master:90265814f993: examples/decode_audio: constify the AVCodec instance [13:46:25 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:dcdd52101f31: Merge commit '90265814f993098d79b0a0f40745ecdb403fbf56' [14:13:53 CEST] <cone-796> ffmpeg 03Anton Khirnov 07master:7b1f03477f1a: examples/avcodec: split the remaining two examples into separate files [14:13:54 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:925ce244d873: Merge commit '7b1f03477f1a43d2261fbd83e50a4ad90c7f806d' [14:15:34 CEST] <cone-796> ffmpeg 03Anton Khirnov 07master:e02524025bce: examples/encode_video: constify the AVCodec instance [14:15:35 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:e9bd45746511: Merge commit 'e02524025bce2c8bf8b5bffd96479785c75a70d4' [14:16:29 CEST] <BBB> hm, right, so I see the problem, I think& Im not 100% sure how to solve it [14:16:48 CEST] <BBB> so in h264, a call to avcodec_decode_video2() can decode just a single field [14:16:53 CEST] <BBB> then the next call decodes the other field [14:17:04 CEST] <cone-796> ffmpeg 03Anton Khirnov 07master:d0a603a534a0: examples/encode_video: set the framerate [14:17:05 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:4726bbb47156: Merge commit 'd0a603a534a0ee4b255e5e72742428a7f7f42b83' [14:17:12 CEST] <BBB> we dont reset ThreadFrame->owner between these two events [14:17:34 CEST] <BBB> and so all references to ->owner touch the one of the first fields AVCodecContext, not the "current" [14:17:47 CEST] <BBB> (I guess we should reset owner for the start of each field?) [14:18:26 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:944e5ce3ec7d: doc/examples/{de,en}code_audio: fix includes [14:22:24 CEST] <cone-796> ffmpeg 03Anton Khirnov 07master:5b4d7ac7ae5d: examples/encode_video: use the AVFrame API for allocating the frame [14:22:25 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:58f24adc05b0: Merge commit '5b4d7ac7ae5d821cfa6ab89f8eab4d31851ef32c' [14:22:58 CEST] <BBB> or maybe owner should be an array of two members, one for each field [14:23:02 CEST] <BBB> sooooo hacky [14:23:06 CEST] <cone-796> ffmpeg 03Anton Khirnov 07master:8191f960a669: examples/decode_video: constify the AVCodec instance [14:23:07 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:fdbc29ca70a6: Merge commit '8191f960a669819db4de33a2439ded1630b8a73e' [14:23:32 CEST] <BBB> I tihnk that may actually be the right solution [14:23:33 CEST] <BBB> hmm.... [14:23:47 CEST] <BBB> any objections? michaelni? [14:24:35 CEST] <cone-796> ffmpeg 03Anton Khirnov 07master:636515c324fa: examples/decode_video: remove a stray unrelated comment [14:24:36 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:63c41c53f355: Merge commit '636515c324facaa14ccd8ab0732740a240a31ba9' [14:27:49 CEST] <cone-796> ffmpeg 03Diego Biurrun 07master:85baef4ff151: vf_drawtext: Move static keyword to beginning of variable declaration [14:27:50 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:ca6f0f85bb78: Merge commit '85baef4ff1512bcc2544928bfa5f42072903a691' [14:28:33 CEST] <michaelni> BBB, no objection if that works [14:28:48 CEST] <BBB> do you have better ideas? [14:29:07 CEST] <BBB> Im not sure its the right solution [14:36:51 CEST] <cone-796> ffmpeg 03Diego Biurrun 07master:39cea6570c11: aactab: Move extern keyword to the front of array declarations [14:36:54 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:35494441b532: Merge commit '39cea6570c11a49b64b2ec8d71e218db03b4c742' [14:40:59 CEST] <ubitux> ok i'm going to push that fourcc/djgpp patchset in a few minutes [14:41:03 CEST] <ubitux> last time to object [14:41:52 CEST] <durandal_170> caaaarl [14:43:24 CEST] <ubitux> i don't think he objected [14:43:33 CEST] <ubitux> he was trying to figure out what the macro was for [14:44:40 CEST] <PaoloP> wm4 (but the question is for other people too): also, you wrote: "Also, if you put the receive call (avcodec_receive_packet() ) in a loop, it'd actually follow the proper send/receive data flow.". It's already put in a loop (while(1)) .. what do you mean exactly? http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209333.html [14:51:55 CEST] <michaelni> BBB, if you want to keep track of the owner of each field and they can be 2 seperate contexts then 2 are needed, If you want to keep track of no owners then the field can possibly be droped completely [14:52:06 CEST] <michaelni> anyway, didnt really think much about it [14:55:08 CEST] <cone-796> ffmpeg 03Diego Biurrun 07master:4cf2ffb7c458: idct: Have function pointer prototype match implementation [14:55:09 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:c1d822c554ac: Merge commit '4cf2ffb7c45840b09bc49e34da88d4053dd442cb' [14:55:10 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:bfdcdd6d829c: lavu: add av_fourcc_make_string() and av_fourcc2str() [14:55:11 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:f156d35321bb: lavc: deprecate av_get_codec_tag_string() [14:55:12 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:67e370ee527e: lavc: fix usages of av_get_codec_tag_string() [14:55:13 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:cd4d6cba122b: lavf: fix usages of av_get_codec_tag_string() [14:55:14 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:337c68d07142: tools/fourcc2pixfmt: fix usages of av_get_codec_tag_string() [14:55:15 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:fa0a8faaa451: ffprobe: fix usage of av_get_codec_tag_string() [14:55:16 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:656823220cde: ffmpeg_videotoolbox: fix usage of av_get_codec_tag_string() [14:55:17 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:d3cedc54cc87: lavf/ape: remove unused magic field [14:55:18 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:bec96a7286bc: lavf: use av_fourcc2str() where appropriate [14:55:19 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:2d12b910f710: lavc: use av_fourcc2str() where appropriate [14:55:20 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:8f9edf89d5d4: lavfi/dynaudnorm: rename pow2 to pow_2 [14:55:21 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:4ea8f57548f3: lavfi/psnr: rename pow2 to pow_2 [14:55:22 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:46068070314d: lavfi/xbr: undef PI if defined [14:55:23 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:1473afac5d11: lavu/mem: clamp alignment to 16 for DJGPP [14:55:24 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:549045254c46: Fix all -Wformat warnings raised by DJGPP [14:55:25 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:eaa67bb9c059: lavc/pthread_slice: remove pointless condition [15:00:43 CEST] <BBB> oh wow that fixed that tsan error [15:06:17 CEST] <JEEB> \o/ [15:07:49 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:d467740f45eb: lavc/idctdsp: use prefix restrict with av_ [15:10:06 CEST] <cone-796> ffmpeg 03Diego Biurrun 07master:baab87c4f30e: bink: Have function pointer prototype match implementation [15:10:07 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:a51867ee6bc7: Merge commit 'baab87c4f30e75ea309294b06adcd01ce678bdc5' [15:19:07 CEST] <cone-796> ffmpeg 03Diego Biurrun 07master:f4ca8ea92a8b: rtmpproto: Restructure zlib code to avoid unreachable code warning [15:19:08 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:72dbfe42efcb: Merge commit 'f4ca8ea92a8b36fe723412aefafc1b2fa89f8dc6' [15:22:52 CEST] <BBB> michaelni: if a slice uses mbaff, does that guarantee that the other slices in the frame use mbaff also? [15:23:04 CEST] <BBB> it does, right? [15:23:07 CEST] <cone-796> ffmpeg 03Diego Biurrun 07master:2025d3787158: doc: Turn off noisy deprecation warnings in the option printer [15:23:08 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:a1b3ded90236: Merge commit '2025d3787158ba272a1b8fbc0493fa20dd7a8484' [15:23:33 CEST] <ubitux> jkqxz: what to do about the 3 next commits? [15:23:40 CEST] <ubitux> (to merge from libav) [15:24:16 CEST] <michaelni> BBB, i would think so [15:25:32 CEST] <jkqxz> ubitux: Do they apply cleanly? [15:26:22 CEST] <ubitux> probably not [15:26:26 CEST] <ubitux> we have a frame pool system [15:26:30 CEST] <jkqxz> They are wanted, without them frame mapping doesn't work usefully. [15:27:34 CEST] <ubitux> i can't really test them [15:27:42 CEST] <ubitux> would you mind doing these merges? [15:28:00 CEST] <ubitux> (ETA: 704) [15:29:12 CEST] <jkqxz> Hardware frames already have a frame pool, so it should just be ignored. [15:30:37 CEST] <jkqxz> That is, just put the hw_frames_ctx change in front of the frame pool stuff. [15:32:25 CEST] <BBB> omg fate-h264 passes w/o tsan warnings here [15:32:29 CEST] <BBB> ubitux: ^^ [15:32:57 CEST] <ubitux> jkqxz: i can blind it but if i can't test... [15:32:59 CEST] <ubitux> BBB: yey ~ [15:33:11 CEST] <ubitux> btw, should we have a tsan isntance with THREAD_TYPE=slice? [15:33:19 CEST] <ubitux> i think they're covering more? [15:36:25 CEST] <jkqxz> I can't do it now. Blind merge should be fine (though note build failure fix for cuda a few commits further on, which you will probably see because ffmpeg enables cuda everywhere). [15:36:32 CEST] <atomnuker> I think so, I've heard of people complaining about slice threading bugs [15:36:40 CEST] <BBB> ubitux: yes we should [15:36:50 CEST] <jkqxz> If you prefer, I should be able to do it later today. [15:37:19 CEST] <ubitux> ok i'm going to do it [15:37:29 CEST] <BBB> ubitux: https://github.com/rbultje/ffmpeg/commits/tsan [15:37:41 CEST] <BBB> all video decoders are tsan-clear now afaics [15:37:45 CEST] <ubitux> BBB: i'll add such instance when that one is in the green [15:37:48 CEST] <BBB> theres still some encoder, filter, audio bugs etc. [15:38:02 CEST] <ubitux> i might increase the number of threads too btw, to something like 3 or 5 [15:38:09 CEST] <ubitux> (i like odd numbers) [15:38:09 CEST] <BBB> sure why not [15:38:11 CEST] <BBB> or make it random [15:38:23 CEST] <BBB> one of the things I like about checkasm is that it has some randomness to it [15:38:52 CEST] <BBB> oh wait mpeg4 is still buggy of course, and all mpeg-derived video decoders [15:39:05 CEST] <BBB> michaelni: do you have any interest in mpegvideo tsan cleaning? [15:41:02 CEST] <michaelni> BBB, ive quite a few things i want to look into, regressions, coverity, reinstalling some fate clients with bigger virtual disks maybe, ... i dont think i should add to my todo [15:41:09 CEST] <BBB> ok [15:50:35 CEST] <mateo`_> I'm looking at the next merge commits [16:01:52 CEST] <BBB> ubitux: utvideoenc fixes on my github also [16:02:06 CEST] <BBB> Ill send to ML in a little bit [16:05:19 CEST] <BBB> ubitux: maybe I can nudge myself to look into mpegvideo-related tsan reports later, but I think Im sort of ready to do something fun again ;) [16:05:44 CEST] <nevcairiel> something fun like making an av1 decoder? [16:05:45 CEST] Action: nevcairiel hides [16:05:49 CEST] <ubitux> i'm sure the next fate run will motivate you again after you push the patchset [16:05:51 CEST] <ubitux> :D [16:07:58 CEST] <wm4> when do we kill mpegvideo? [16:08:14 CEST] <wm4> I mean, it was already separated from h264, which was the most complex codec [16:08:29 CEST] <nevcairiel> it also didnt use all that much from it [16:08:42 CEST] <nevcairiel> but the actual mpeg codecs probably use quite a lot of it [16:08:44 CEST] <nevcairiel> mpeg124 [16:10:03 CEST] <BBB> also rv3/4 [16:10:06 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:247d0339ca5d: lavfi/signature: fix -Wformat warnings raised by DJGPP [16:10:11 CEST] <BBB> I believe vc1/wmv12 also use it [16:10:49 CEST] <nevcairiel> whatever happened to mpeg3 between 2 and 4 [16:12:43 CEST] <nevcairiel> (and noone say mp3 audio) [16:14:43 CEST] <BBB> anyone interested in tsan w/ audio decoders? [16:22:03 CEST] <BBB> ah I see [16:22:06 CEST] <BBB> the audio one is trivial [16:22:13 CEST] <BBB> are all audio codecs intra-only? [16:22:43 CEST] <BBB> I dont think so right? e.g. from what I recall, wmavoice uses overlapping postfilters [16:23:00 CEST] <BBB> so then it makes sense to mark intra-only audio codecs as such [16:23:33 CEST] <nevcairiel> i think all threaded audio decoders are intra only? [16:24:01 CEST] <nevcairiel> but yeah some use some data from previous frames [16:24:04 CEST] <nevcairiel> ie. dca does that too [16:24:16 CEST] <iive> doesn't mdct need some overlap from previous frame? [16:26:17 CEST] <atomnuker> BBB: mlp and truehd aren't [16:27:57 CEST] <BBB> hm& theres a jpeg2k issue in there [16:31:18 CEST] <BBB> or maybe thats pre-my patches [16:33:48 CEST] <wm4> BBB: uh, so with interlacing, there are really two threads which can write different fields to the same AVFrame? [16:33:59 CEST] <BBB> yes [16:34:16 CEST] <wm4> wtf... sounds like another case for outputting fields instead of weaved frames [16:34:37 CEST] <nevcairiel> really makes no difference if they write interleaved lines or interleaved memory buffers [16:35:04 CEST] <BBB> wm4: I dont know, I think the two issues are orthogonal [16:35:29 CEST] <nevcairiel> except that plenty APIs want weaved frames, so doing it right away is probably better for performance [16:36:30 CEST] <BBB> my logic is its what we do now and I dont see a strict problem with it, so Ill just bother with other things" [16:36:48 CEST] <BBB> anyway, my current patchset makes fate pretty clean as far as I can see [16:36:59 CEST] <BBB> theres a bunch of mpeg4 issues and perhaps some filtering stuff [16:37:54 CEST] <BBB> at least ffmpeg-filter_colorkey seems avfilter-related [16:44:36 CEST] <ubitux> i don't see colorkey in the last report [16:44:40 CEST] <mateo`_> here are the next merge commits https://github.com/mbouron/FFmpeg/commits/lavfi-merges, if someone wants to take a look / test [16:44:42 CEST] <BBB> oh cool [16:44:53 CEST] <BBB> I was probably looking at an older one [16:44:56 CEST] <BBB> Im fixing them one-by-one [16:45:09 CEST] <ubitux> maybe it happens sometimes though [16:45:32 CEST] <wm4> mateo`_: any notable problems/issues? [16:45:46 CEST] <mateo`_> i will split the content of ff_default_get_video_buffer later on [16:45:55 CEST] <ubitux> mateo`_: did you include 67c65e461cb073d61ffbc78845d4a3d8f14bf481? [16:46:20 CEST] <mateo`_> wm4: i blinded the merge, so i have no idea if it works [16:46:57 CEST] <mateo`_> ubitux: nope [16:47:07 CEST] <ubitux> you probably should [16:50:36 CEST] <mateo`_> ubitux: it's a separate merge commit, isn't it ? [16:51:02 CEST] <ubitux> it comes later in the history [16:51:13 CEST] <ubitux> but it's a fixup for one of the commit you're merging [16:54:02 CEST] <mateo`_> right [16:56:23 CEST] <mateo`_> branch updated [16:56:35 CEST] <ubitux> maybe ping jkqxz for testing [16:56:57 CEST] <ubitux> but you shouldn't wait too much, because as soon as someone pushes something you have to redo all the 3 merges [16:57:41 CEST] <mateo`_> jkqxz: would you kindly test the next lavfi merge batch (https://github.com/mbouron/FFmpeg/commits/lavfi-merges) ? [16:57:47 CEST] <ubitux> (and my rebase script won't help you in this situation) [16:57:57 CEST] <mateo`_> and i'll soon be afk [16:58:48 CEST] <wm4> for these situations rerere seems like a good iea [16:58:50 CEST] <mateo`_> the merge is trivial, there are only minor conflicts, i don't mind doing it again later [16:58:50 CEST] <wm4> *idea [16:59:31 CEST] <mateo`_> rerere ? [17:03:58 CEST] <ubitux> git rerere [17:06:03 CEST] <wm4> basically it re-applies conflict resolutions whenever possible [17:39:03 CEST] Action: mateo`_ afk [18:01:48 CEST] <ubitux> wm4: https://trac.ffmpeg.org/ticket/6275 [18:01:59 CEST] <ubitux> in case you didn't see it [18:03:46 CEST] <wm4> I'm looking forward to cehoyos' analysis [18:04:57 CEST] <ubitux> i know the conclusion of the analysis& :3 [19:23:25 CEST] <jamrial> so, how ugly would it be to remove a month old public enum value that's not part of any release? [19:25:32 CEST] <atomnuker> jamrial: I think its alright, its not part of any release [19:57:13 CEST] <Bitterblue> Hi. I have a vector of AVPackets which were previously decoded into one correct AVSubtitle. This happened during 100% linear access from the beginning of a PGS stream to the end. However, when I try to decode them again, starting just from the first AVPacket in the vector, things don't go so well. Either the resulting AVSubtitle contains a 0x0 AVSubtitleRect, or the image is "slightly" wrong. Is random [19:57:15 CEST] <Bitterblue> access in PGS just not possible? [19:59:00 CEST] <JEEB> Bitterblue: sounds like the initialization data for something is missing [19:59:16 CEST] <JEEB> I remember PGS containing different packets, such as palette etc [20:09:26 CEST] <Bitterblue> Hmm. [20:13:35 CEST] <wm4> Bitterblue: normally when I seek in something that has PGS I don't get artifacts [20:13:41 CEST] <wm4> so, should be possible [20:27:34 CEST] <Bitterblue> Decoding the previous ten subtitles seems to help, but that's not a very nice solution. [20:28:53 CEST] <nevcairiel> iirc AVPackets don't contain singular subtitles for PGS, but you get one AVPacket for every PGS packet, and one subtitle consists of a couple of those [20:29:14 CEST] <nevcairiel> typically a palette, windowing information, object information, etc [20:32:43 CEST] <wm4> I wonder if PGS packets typically have a useful keyframe flag set [20:32:53 CEST] <nevcairiel> where from? [20:33:01 CEST] <nevcairiel> mpegts, its only commercial source, dont carry such flags [20:33:32 CEST] <wm4> parser [20:33:53 CEST] <nevcairiel> has none [20:37:01 CEST] <Compn> Bitterblue [20:37:06 CEST] <Compn> nm [20:37:46 CEST] <wm4> sounds like a place for improvement [21:04:23 CEST] <jkqxz> mateo`: Tested with what's currently there, works fine (wants hwmap to do anything meaningful, though). [21:04:33 CEST] <jkqxz> mateo`: Two nits: in the first patch, you needn't bother with the else and the extra braces around the existing code; the hwupload_cuda fix wants to be in the second patch, not the third. [21:05:01 CEST] <jkqxz> mateo`: LGTM otherwise. [21:18:46 CEST] <BtbN> mateo`, the hwupload_cuda one also looks like it won't compile. As it uses outlink, but there is no outlink in the function where it uses it. [21:25:39 CEST] <Cheech> anyway to stream live MPEGTS with alpha channel please?? [21:27:05 CEST] <BtbN> Find a format it supports that can carry one [23:07:15 CEST] <mateo`> jkqxz, BtbN thanks for testing [23:08:43 CEST] <mateo`> I'll redo the first patch withtout the else {} and applied it immediately [23:20:10 CEST] <cone-796> ffmpeg 03Mark Thompson 07master:7433feb82f75: lavfi: Make default get_video_buffer work with hardware frames [23:20:11 CEST] <cone-796> ffmpeg 03Matthieu Bouron 07master:b265e5ba50b8: Merge commit '7433feb82f75827884d909de34d341a1c4401d4a' [23:22:52 CEST] <durandal_1707> ok to push sonething? [23:26:06 CEST] <durandal_1707> mateo`: ^ [23:26:54 CEST] <mateo`> durandal_1707: yes go ahead, thanks for taking care :) [23:29:56 CEST] <cone-796> ffmpeg 03Martin Vignali 07master:b4016ef31a6e: avcodec/exr: add support for uint32 [23:32:54 CEST] <PaoloP> I have to add a check for the sample rate of a chosen codec in my snippet. codec->supported_samplerates for AAC returns {16000, 12000, 11025, 8000, 7350} . Do I have to add 44100 to this list (as muxing.c and decoding_encoding.c do) ? [23:35:24 CEST] <nevcairiel> the list returned by AAC is far longer and already includes 44100 [23:35:46 CEST] <nevcairiel> in general, modifying the returned list is just wrong, it te lls you whats supported and thats that, you cant just add a format [23:36:39 CEST] <cone-796> ffmpeg 03Mark Thompson 07master:7e2561fa8313: lavfi: Use ff_get_video_buffer in all filters using hwframes [23:36:40 CEST] <cone-796> ffmpeg 03Matthieu Bouron 07master:78e871ebbcc6: Merge commit '7e2561fa8313982aa21f7657953eedeeb33b210d' [23:38:13 CEST] <PaoloP> nevcairiel: yes, I did not want to modify the list, I thought it was a sort of common default value. I don't understand why in decoding_encoding.c there's this line: if (!codec->supported_samplerates) return 44100; [23:38:43 CEST] <nevcairiel> its for when there is no list at all, which basically means anything is supported, so it picks some default [23:39:50 CEST] <PaoloP> I see, a comment for that should be added to the doxy, IMHO [23:40:31 CEST] <nevcairiel> it kind of says that [23:40:41 CEST] <nevcairiel> 44100 is a generally accepted default value [23:40:57 CEST] <PaoloP> nevcairiel: you are right, it says: "or NULL if UNKNOWN" [23:41:08 CEST] <PaoloP> sorry. [23:55:38 CEST] <mateo`> jkqxz, BtbN: are you ok with the following change on the next merge commit http://sprunge.us/WJZf ? [23:59:25 CEST] <jkqxz> Is anything similar necessary for the format it gets compared to? [23:59:34 CEST] <jkqxz> Also yes. [00:00:00 CEST] --- Thu Mar 30 2017

1 0

ffmpeg.log.20170329
by burek 30 Mar '17

30 Mar '17

[00:00:18 CEST] <thebombzen> it won't look as good [00:00:18 CEST] <bf_> is preset fast affecting aac or x264? [00:00:21 CEST] <furq> x264 [00:00:31 CEST] <alexpigment> thebombzen: anyway, it sounds like we agree here. the expanded color range of HDR (10-bit + bt2020) is a hell of a lot more meaningful than the 4K resolution itself [00:00:33 CEST] <thebombzen> no the :v in the -preset:v tells it "preset for the video stream" [00:00:40 CEST] <thebombzen> alexpigment: yea I agree [00:00:48 CEST] <bf_> thank you furq and thebombzen [00:00:54 CEST] <thebombzen> I have a 1080p 24 inch monitor and I don't really feel a need for extra resolution [00:00:58 CEST] <furq> also do you really need a 160kbps stream in this day and age [00:01:00 CEST] <bf_> is there anything else that jumps to the eye in that command? like bad rates? [00:01:06 CEST] <bf_> thanks :D [00:01:17 CEST] <TD-Linux> thebombzen, 144p is borderline watchable on a phone [00:01:21 CEST] <alexpigment> thebombzen: that's because you're a smart person who bought a monitor that is appropriately sized for the resolution ;) [00:01:31 CEST] <alexpigment> these jokers out here with 21" 1080p monitors... ;) [00:01:36 CEST] <furq> bf_: you're probably also going to want to downscale the lower bitrate videos [00:01:39 CEST] <bf_> furq: should I ditch it and only go med/high or use a higher setting for low? [00:01:41 CEST] <furq> although that will also cause a slowdown [00:01:48 CEST] <thebombzen> also 128k and 256k are very low resolutions [00:01:54 CEST] <furq> tbh 512+128 is probably what i'd be using for low [00:01:57 CEST] <thebombzen> very low bitrates* [00:01:57 CEST] <furq> unless this is really low res [00:01:58 CEST] <thebombzen> for video [00:02:06 CEST] <TD-Linux> you can try it on youtube [00:02:10 CEST] <bf_> no it is mainly a POC for desktop comuputers [00:02:26 CEST] <furq> but yeah unless this is sub-saharan africa, nobody's going to use 128+32 [00:02:26 CEST] <thebombzen> TD-Linux: was talking to me [00:02:33 CEST] <thebombzen> 128k and 256k are very low bitrates for video [00:02:38 CEST] <furq> that's too high for 56k and too low for literally anything better than 56k [00:02:40 CEST] <thebombzen> unless you've got absurdly low resolution [00:02:59 CEST] <bf_> furq: actually I only want 720p or higher [00:03:04 CEST] <TD-Linux> youtube's 144p is 128kbps video 60kbps audio [00:03:07 CEST] <furq> lol [00:03:14 CEST] <furq> you want 720p at 128kbps? [00:03:15 CEST] <TD-Linux> furq, terrible 2G and 3G connections [00:03:15 CEST] <thebombzen> lol but this is 720p [00:03:23 CEST] <furq> that's going to look fucking awful [00:03:34 CEST] <bf_> furq: %) sorry [00:03:35 CEST] <alexpigment> TD-Linux: it feels like they're using that for 360p too, lol [00:03:36 CEST] <thebombzen> yea 144p might only look okay on a phone if you have a small screen [00:03:38 CEST] <furq> i wouldn't even bother with mid without scaling [00:03:38 CEST] <thebombzen> like old iphone [00:03:49 CEST] <bf_> no I want 720p at a reasonable bitrate ofc [00:03:51 CEST] <TD-Linux> oh I was replying to the earlier conversation not the one involvinb bf_ [00:03:53 CEST] <furq> i wouldn't do anything less than 1mbit for 720p [00:03:57 CEST] <TD-Linux> bf_ ignore me [00:04:00 CEST] <furq> and even that's pushing it [00:04:07 CEST] <bf_> sorry to crash your conversation TD-Linux [00:04:17 CEST] <thebombzen> if you have a newer phone like a newer iphone or newer galaxy then 144p will look terrible on a phone [00:04:31 CEST] <furq> 144p will look terrible on anything newer than a nokia 3210 [00:04:34 CEST] <thebombzen> but 480p looks fine on the "plus-sized phones" even though they have 1080p screens [00:04:47 CEST] <alexpigment> 144p will look terrible even on a native 144p display [00:04:50 CEST] <bf_> furq: There is also a bitrate in nginx-rtmp config: hls_variant _low BANDWIDTH=160000; hls_variant _mid BANDWIDTH=320000; hls_variant _hi BANDWIDTH=640000; [00:04:51 CEST] <alexpigment> because it's youtube [00:04:51 CEST] <thebombzen> 360p on a modern phone that isn't nonplussed [00:05:00 CEST] <furq> bf_: that's just advisory [00:05:09 CEST] <furq> it's up to you to match that up with your ffmpeg command [00:05:17 CEST] <thebombzen> bf_: yea, I'd recommend testing out 1M bitrate for 720p video first [00:05:21 CEST] <bf_> furq: but it is sent in the m3u8 playlist, I think the clients will change resolution based on it? [00:05:25 CEST] <furq> they will [00:05:32 CEST] <thebombzen> the best way is to just look at it and see [00:05:34 CEST] <bf_> okay thank you guys, much appreciated [00:05:36 CEST] <thebombzen> is 1M tolerable? [00:05:39 CEST] <thebombzen> welll you can tell that [00:05:46 CEST] <thebombzen> but I can tell you that 128k will look atrocious [00:06:08 CEST] <furq> try 480p at 640+128 and 720p at 1280+128 [00:06:15 CEST] <furq> those should look ok-ish even with -preset fast [00:06:28 CEST] <furq> also that way you only need to encode the audio once [00:06:41 CEST] <bf_> furq: will ffmpeg do that optimization for me? [00:06:49 CEST] <bf_> I mean if both video streams use same audio bitrate, will it encode only onceP? [00:06:50 CEST] <alexpigment> if we're ranting about YouTube (and confusing bf_ with those unrelated rants), i can't understand how they chose to not have a 480p60 mode. the only way to get the correct temporal resolution is to upscale to 720p. SMH [00:06:53 CEST] <furq> no [00:07:00 CEST] <furq> you'd need to go through some indirection to get that [00:07:06 CEST] <bf_> fml [00:07:29 CEST] <furq> also yeah no 480p60 sucks [00:08:08 CEST] <bf_> furq: so -b:v 512K = 720p? [00:08:17 CEST] <furq> ? [00:08:19 CEST] <alexpigment> youtube could have done the right thing and converted 480i streams to 480p60 by default, or at the very least, support 480p60 so users could deinterlace prior to uploading [00:08:37 CEST] <alexpigment> 512K for 720p? that's no good [00:08:55 CEST] <bf_> furq: wait.. I dont do anything with resolution in my whole ffmpeg command [00:09:35 CEST] <furq> well yeah if you're not going to downscale then dropping the bitrate is a bit pointless [00:09:54 CEST] <furq> it'll look much worse if you don't downscale the lower bitrate variant [00:10:01 CEST] <bf_> I understand [00:10:02 CEST] <thebombzen> bf_: here's an example of 128k 720p: http://0x0.st/v1t.png [00:10:05 CEST] <thebombzen> notice how awful it looks [00:10:10 CEST] <bf_> Weird because I got this technique from the tutorial by the maker of nginx-rtmp [00:10:28 CEST] <bf_> thanks thebombzen [00:10:49 CEST] <alexpigment> 720p should be at least 2mbps imho [00:10:53 CEST] <alexpigment> if not 3mbps [00:10:56 CEST] <thebombzen> compare to 720p at 1M for this: https://0x0.st/v1v.png [00:10:58 CEST] <furq> depends on the content [00:11:06 CEST] <thebombzen> at 1M it's not particularly great [00:11:08 CEST] <alexpigment> furq: for non-static content [00:11:10 CEST] <bf_> so best approach would be to downscale source resolution to 1080p and offer second resolution at 720p? [00:11:11 CEST] <thebombzen> but it's at least vieable [00:11:17 CEST] <furq> bbc iplayer's 720p streams are 1.5mbit and they usually look ok [00:11:31 CEST] <furq> unless anyone gets on a boat [00:11:37 CEST] <thebombzen> bf_: I would not recommend providing higher than 1080p source unless you think the clients will be able to support it [00:11:46 CEST] <thebombzen> most people don't have >1080p monitors for example [00:12:22 CEST] <bf_> I also think so. Was just orienting at twitch.tv [00:12:28 CEST] <bf_> *on [00:12:34 CEST] <bf_> sorry I'm tired, a lot of spelling mistakes [00:12:56 CEST] <bf_> but 128k audio is also fine with hd? [00:13:02 CEST] <thebombzen> usually [00:13:21 CEST] <bf_> ok I will try to implement your suggestions, will come back tomorrow with a different set of problems [00:13:24 CEST] <furq> 128k aac is good enough for any streaming stereo audio [00:13:25 CEST] <thebombzen> it depends on what codec and what type of audio but for 97% of the things you're dealing with 128k is okay [00:13:30 CEST] <furq> that's what youtube uses for 4k iirc [00:13:34 CEST] <thebombzen> especially if you're streaming [00:13:34 CEST] <furq> certainly for 1080p [00:13:49 CEST] <thebombzen> 128k aac might not be transparent for heavy metal music but that's about it [00:13:55 CEST] <alexpigment> as a person who is a bit of an audiophile, even i will admit that 128kbps is fairly transparent for AAC [00:13:56 CEST] <thebombzen> but it's still okay [00:14:01 CEST] <bf_> Ok [00:14:04 CEST] <bf_> another audio question [00:14:24 CEST] <alexpigment> like basically unless you have someone wailing on an open hi-hat in a song, 128kbps is fine [00:14:33 CEST] <bf_> I want to build this thing where dozens of people speak at the same time, audio stream gets merged, people get placed within space using equalizer, and one audio stream is piped to viewers [00:14:39 CEST] <furq> whaling [00:14:55 CEST] <alexpigment> whaling? haha [00:14:57 CEST] <bf_> is this a scenario where higher audio bitrate helps? [00:15:09 CEST] <furq> i can't say i've ever done it [00:15:15 CEST] <thebombzen> higher audio bitrate would help if you have more channels [00:15:16 CEST] <furq> if you want more than two audio channels then yes [00:15:23 CEST] <furq> but if you're downmixing to stereo it probably makes no difference [00:15:24 CEST] <thebombzen> but if you're in stereo 128k is still fine [00:15:31 CEST] <thebombzen> especially if it's people speaking [00:15:36 CEST] <thebombzen> human speech is very easy to compress [00:15:47 CEST] <bf_> like stadium atmosphere, people chanting, shouting [00:16:01 CEST] <bf_> they get clustered by country [00:16:04 CEST] <thebombzen> if you're downsampling to stereo, it'll be just as easy [00:16:14 CEST] <thebombzen> I wouldn't recommend increasing the bitrate unless you're providing it as 5.1 or something [00:16:19 CEST] <bf_> okay thank you very much [00:16:27 CEST] <bf_> no it is all for desktop / laptop computers [00:16:30 CEST] <bf_> no home entertainment [00:16:52 CEST] <bf_> thanks again, I gotta go now. Ttyl [00:17:11 CEST] <alexpigment> not to tangent too much, but i've never understood how bitrates are subdivided for 5.1 audio [00:17:36 CEST] <alexpigment> for a 384kbps AC-3 5.1 stream, does each channel get an even 64kbps? [00:17:46 CEST] <alexpigment> or is more bitrate allocated to the L and R channels? [00:29:23 CEST] <sikilikis> so uh good news [00:29:34 CEST] <sikilikis> using your help, the pi is actually able to output at 1080p and like 25 fps [00:41:34 CEST] <mavi> Hi, I'm creating a site, and looking to perfect my encoding setting before encoding around 1000 video files or so. I'm curious if the built in AAC audio encoder for low 32kbps audio he-aac2 is better than fdk aac now [00:41:46 CEST] <mavi> or is fdk-aac still the king for that sort of thing? [00:42:39 CEST] <mavi> I read conflicting reports that in 2017 the built in encoder is now better or the same as fdk aac, just not sure if that is the case, or if that applies to the he-aacv2 encodes. [00:43:03 CEST] <furq> mavi: the builtin encoder can't do he-aac [00:43:09 CEST] <furq> which i assume you want for 32k [00:43:32 CEST] <furq> fdk is probably better at lc-aac at any bitrate, but nobody's done a proper listening test yet [00:43:36 CEST] <mavi> It can't? Interesting. [00:43:51 CEST] <mavi> That solves my potential problem in seconds :) [00:44:26 CEST] <mavi> Also for some reason running the command with vbr and fdk aac shows me this [00:44:27 CEST] <mavi> [libfdk_aac @ 0x2d38b40] Note, the VBR setting is unsupported and only works with some parameter combinations [00:45:22 CEST] <furq> you can probably ignore that [00:45:46 CEST] <mavi> I've been using the nero aac codec, and today im trying this version out. I prefer the vbr modes. Is fdk aac better than nero aac which is fairly old now at low bitrates or are they more or less the same? [00:45:52 CEST] <mavi> ah, alright will do. [00:47:29 CEST] <mavi> i had read that the nero aac encoded based on a floating point, while fdk was limited to a fixed point when it came to the vbr, at the same bitrate. Does this mean that for my needs, nero aac is better? They said it was something regarding the license that limited fdk to using fixed point integer calculations. [00:48:00 CEST] <mavi> Thanks for the help in advance. Been researching this stuff for a week, sorry for all the questions. [00:57:14 CEST] <thebombzen> okay kepstin so I found out that my weird framerate file (25.93 or something weird) alternates between 24 and 30 depending on the scene [00:57:18 CEST] <thebombzen> which is really really weird [00:57:29 CEST] <thebombzen> and 120 is the LCM of 24 and 30, so it uses that [00:57:38 CEST] <furq> can ffmpeg convert mov_text to srt [00:57:40 CEST] <furq> and if not, what can [00:59:04 CEST] <thebombzen> I'd think it could [00:59:07 CEST] <thebombzen> why wouldn't it be able to [00:59:20 CEST] <furq> i have a standalone mov_text file (ttxt) and i can't get anything to happen [00:59:42 CEST] <thebombzen> uh? [00:59:49 CEST] <thebombzen> how do you even specify standalone subtitle files [00:59:59 CEST] <furq> i downloaded it from youtube [01:01:08 CEST] <thebombzen> I'm not entirely sure how to demux standalone subtitles [01:01:12 CEST] <thebombzen> at least with ffmpeg.c [01:01:22 CEST] <thebombzen> but ffmpeg.c does have an mov_text decoder and a subrip encoder/muxer [01:02:32 CEST] <furq> oh nvm youtube-dl will give me the subs in vtt [01:02:36 CEST] <furq> this is probably easier [01:02:51 CEST] <furq> yeah that works without any coercion [01:04:15 CEST] <thebombzen> but why would I have a video that's sometimes 24 and sometimes 30 [01:04:21 CEST] <thebombzen> who would do that :P [01:06:07 CEST] <TD-Linux> anime [01:06:20 CEST] <furq> s [01:06:57 CEST] <thebombzen> yea it is anime but I still find that weird [01:07:04 CEST] <thebombzen> because that won't broadcast well on any monitor [01:07:05 CEST] <JEEB> broadcast often has truly interlaced shit and then normal telecine [01:07:16 CEST] <furq> well that worked but now i have an srt with 113-character lines [01:07:17 CEST] <furq> thanks youtube [01:07:22 CEST] <JEEB> and then you deint the interlaced shit and IVTC the rest of it [01:07:26 CEST] <TD-Linux> thebombzen, looks just fine on my 480i crt [01:07:39 CEST] <JEEB> and you are left with VFR [01:07:40 CEST] <thebombzen> but sometimes 24 and sometimes 30 won't work on any monitor <120 Hz [01:07:45 CEST] <furq> TD-Linux: i bet you can't play hi-ten bomberman on that though [01:08:16 CEST] <thebombzen> but sometimes 24 and sometimes 30 is just weird :P [01:08:24 CEST] <TD-Linux> furq, can't do any 31khz arcade boards [01:08:29 CEST] <thebombzen> I'm not sure why that makes any sense [01:08:31 CEST] <furq> that wasn't an arcade board [01:08:37 CEST] <furq> i don't think it exists in a playable form though [01:08:38 CEST] <thebombzen> and it sounds like that violates NTSC standards, doesn't it? [01:08:42 CEST] <furq> it was some hacked up pc engine [01:09:12 CEST] <furq> apparently it's two pc engines with a custom video output [01:09:16 CEST] <TD-Linux> sounds like an arcade board to me [01:09:33 CEST] <furq> well you played it with pc engine controllers [01:09:34 CEST] <TD-Linux> thebombzen, the content you found was originally ntsc interlaced [01:09:53 CEST] <furq> it is technically custom hardware though so i guess it's 50/50 [01:10:04 CEST] <TD-Linux> the person who made your file used ivtc for the 24fps parts and deinterlacing for the 30fps parts [01:10:42 CEST] <furq> http://vignette2.wikia.nocookie.net/bomberman/images/1/1c/HiTenBombermangam… [01:10:55 CEST] <TD-Linux> very nice [01:11:13 CEST] <TD-Linux> considered a HD crt but most have framebuffers [01:12:06 CEST] <TD-Linux> bvm-d20 is one exception [01:14:29 CEST] <mavi> Anyone know whether NERO AAC at 32kbps vbr is better than the fdk aac at 32kbps HE-AAC v2? [01:15:22 CEST] <furq> no idea [01:15:29 CEST] <furq> you'd have to test it yourself [01:15:42 CEST] <furq> i doubt it's worth the extra trouble though [01:16:47 CEST] <mavi> i actually have. With fdk aac checking via mediainfo, it says the rate is constant even though i picked VBR 1, while nero shows and classifies it as variable bit rate [01:17:04 CEST] <mavi> they are sound wise similiar, just wondering if there is anyone that's done more experimentation on it. [01:17:55 CEST] <mavi> may just stick with nero as media info recognized that it's actually a variable bitrate, unlike FDKAAC where it doesnt [02:26:42 CEST] <Kirito> If I have a raw (uncompressed) video file encoded at 120fps, what is the best way to encode it at half speed at 60fps, without resulting in any dropped frames? Would I use the same PTS trick done when re-encoding an existing x264 stream, or should I use another method since this is an uncompressed stream, not lossy? [02:28:17 CEST] <Kirito> I mean since it's uncompressed, wouldn't it just be a matter of altering the framerate it's encoded at (and running the audio through a filter)? As far as I'm aware uncompressed videos don't have reference frames or anything of that nature [02:29:46 CEST] <DHE> depends. true raw RGB or YUV to file has no framerate and you have to specify one on the command-line [02:30:00 CEST] <DHE> but if it's in some kind of container (AVI, MKV, etc) then the container will carry the framerate [02:30:15 CEST] <DHE> still, you can override that framerate as you would for true raw video which may be the easiest way to do it [02:32:52 CEST] <kepstin> Kirito: with an uncompressed video, you can either just use the -r input option to override the framerate - or you can use the setpts filter, since "re-encoding" an uncompressed video is a no-op anyways [02:35:48 CEST] <Kirito> ahh, overriding it with -r did just what I wanted, thanks [04:45:48 CEST] <thebombzen> I have a video that's partially 30 fps and partially 24 fps, and I want to re-encode it as CFR [04:46:05 CEST] <thebombzen> (and I don't want to re-encode it as 120 fps) [04:46:31 CEST] <thebombzen> would you remmend using -r 30 and having judder for the 24 fps, using -r 24 and having judder for the 30 fps, or some form of -vf framerate=30 or -vf framerate=24? [04:46:38 CEST] <thebombzen> (which interpolates) [04:47:11 CEST] <thebombzen> I want it to be CFR because many containers (like mp4) don't support vfr [04:47:46 CEST] <thebombzen> so if I use ffmpeg -i input.mkv output.mp4 it'll automatically force 120 fps, which is the tbr [05:01:15 CEST] <furq> i recommend the recycling bin [05:13:34 CEST] <thebombzen> furq: what [05:13:59 CEST] <thebombzen> you recommend that I open up my graphical DE file browser and hit the delete key on my keyboard [05:14:03 CEST] <thebombzen> what is that supposed to mean [05:14:42 CEST] <furq> i don't know how to respond to that [05:18:00 CEST] <thebombzen> well perhaps with a real answer to my original question [05:18:32 CEST] <thebombzen> if I have a VFR video that's sometimes 24 and sometimes 30 what's the best way to force it to cfr (that isn't just dup frames so it's 120 fps because 120 fps is kinda dumb) [05:19:58 CEST] <thebombzen> also apparently cuvid doesn't support chroma formats other than 420 [05:44:20 CEST] <alexpigment> thebombzen: what about re-encoding it as 30i? [05:44:32 CEST] <kepstin> thebombzen: you have to watch the video and determine whether the judder in the 30p or 24p sections would be worse [05:44:36 CEST] <thebombzen> are you actually suggesting that I make progressive video interlaced [05:44:38 CEST] <kepstin> thebombzen: there's no single answer [05:44:49 CEST] <thebombzen> kepstin: but would you recommend adding judder or interpolation [05:44:52 CEST] <alexpigment> thebombzen: yeah, because that's likely what it was originally [05:44:57 CEST] <thebombzen> it definitely wasn't [05:45:12 CEST] <alexpigment> in which case, the 30p sections would be doubled, and the 24p sections would be telecined [05:45:14 CEST] <kepstin> interpolation is probably worse, but it depends on the video [05:45:18 CEST] <kepstin> try both? [05:45:31 CEST] <alexpigment> it definitely wasn't? how was it originally broadcast? [05:47:25 CEST] <thebombzen> well if it was originally interlaced I could tell [05:47:32 CEST] <alexpigment> how so? [05:47:54 CEST] <thebombzen> highmotion interlaced content looks terrible [05:48:15 CEST] <alexpigment> yeah, but 30i to 24p when the source is 24p doesn't suffer from any sort of artifacts [05:48:36 CEST] <alexpigment> likewise, 30i to 30p when the original 30p doesn't suffer from any artifacts [05:49:13 CEST] <alexpigment> i deal with a lot of 30i material - pretty sure i'm 100% correct on these assertions [05:50:30 CEST] <alexpigment> aside from all this, the real question is which part of the video is 30p? the credits? the opening scene? or is it interspersed somewhere in the middle? [05:52:02 CEST] <alexpigment> welcome back i guess, thebombzen ;) [05:52:12 CEST] <alexpigment> did you miss anything i wrote above? [05:53:45 CEST] <thebombzen_> Yea and I'm on mobile. I'll check the backlog in an hour [05:54:31 CEST] <thebombzen_> Short answer: It's anime but notripped from the broadcast but the bluray release [05:55:12 CEST] <thebombzen_> it's animed in progressive and interlaced for the ntsc DVB but not bluray [05:55:14 CEST] <thebombzen_> bbl [06:45:03 CEST] <thebombzen_> alright I am back [07:00:04 CEST] <thebombzen> alexpigment: it's interspersed in the middle [07:00:17 CEST] <thebombzen> it's animated so they animated the highmotion content at 30 fps [07:00:26 CEST] <thebombzen> but left most of it at 24 [07:18:02 CEST] <thebombzen> out of curiosity [07:18:56 CEST] <thebombzen> so if you upscale yuv420p to yuv420p10le before encoding as H.264 or HEVC, you'll have a better compression ratio [07:19:00 CEST] <thebombzen> i.e. quality-to-bitrate [07:19:21 CEST] <thebombzen> but is the same true about upscaling yuv420p to yuv420p12le? [07:19:33 CEST] <thebombzen> or does the 50% extra data finally become a toll? [10:34:45 CEST] <DemoniacMilk> good morning [10:35:21 CEST] <DemoniacMilk> i got a question regarding the config script [10:35:47 CEST] <DemoniacMilk> i am trying to cross compile ffmpeg for an ARM based system [10:36:18 CEST] <DemoniacMilk> ./configure --enable-cross-compile --cc=~/ti/linuxSDK/linux-devkit/sysroots/x86_64-arago-linux/usr/bin/arm/arm-linux-gnueabihf-gcc --arch=arm --target-os=linux [10:36:57 CEST] <DemoniacMilk> so im telling the configure script to cross compile, for linux, arm architecture, using a cross compiler [10:38:10 CEST] <DemoniacMilk> but this results in [10:38:11 CEST] <DemoniacMilk> ~/ti/linuxSDK/linux-devkit/sysroots/x86_64-arago-linux/usr/bin/arm/arm-linux-gnueabihf-gcc is unable to create an executable file. C compiler test failed. [10:38:44 CEST] <DemoniacMilk> i can build executables using the cross compiler (and succesfully run them on the target system) [10:39:19 CEST] <DemoniacMilk> so I am wondering how the config script checks if executables may be built by a compiler [10:39:30 CEST] <DemoniacMilk> and why it might fail [11:48:50 CEST] <DemoniacMilk_> Hey, can anyone help me find an ffmpeg cross compiling issue? [11:49:57 CEST] <DemoniacMilk_> I am trying to compile ffmpeg for an arm based system but end up getting an error "C compiler test failed". [11:50:25 CEST] <DemoniacMilk_> a google search provides plenty of results but I wasnt able to find a solution in those yet [11:55:01 CEST] <DemoniacMilk_> ah the config.log gav some additional info [11:55:13 CEST] <DemoniacMilk_> as in : /tmp/ffconf.GNCumJGc.c:1:0: error: bad value (armv7) for -march= switch [11:55:55 CEST] <DemoniacMilk_> so i guess the CPU identifier is incorrect. Any idea how i may find out the correct identifier for the CPU on my target? (target running linux) [12:14:46 CEST] <Tom_B> is it possible to specify a sequence of decoders? E.g. try decoding with h264_cuvid but if that fails, use native instead? The problem I have is that not all streams will be h264, so setting -c:v before -i only works in some cases. I can do this myself by launching a second ffmpeg process if the first fails, but this causes an extra delay in actually playing the video. Can this be done with ffmpeg? [12:25:39 CEST] <dystopia_> you should set -c:v after -i [12:25:57 CEST] <dystopia_> how can it copy video codec if you haven't specified an input [12:30:59 CEST] <DHE> Decoders? While you may be able to force a decoder, most people let autodetection do its magic [12:33:21 CEST] <Tom_B> I can't rely on autodetection, because I want to use -deint from h264_decode when it's available [12:33:41 CEST] <Tom_B> The problem is, -deint does not get applied unless the input codec is specified [12:35:04 CEST] <Tom_B> I'm using the example from here: https://trac.ffmpeg.org/wiki/HWAccelIntro#CUDACUVIDNvDecode for hardware encode/decode but I want to add deinterlacing. As encode doesn't support filters it works with -hwaccel cuvid -c:v h264_cuvid -deint adaptive -i INPUT [12:35:38 CEST] <Tom_B> but removing -c:v h264_cuvid, -deint is no longer set and I can't get deinterlaced output [12:35:56 CEST] <mavi> Is this the most up to date CLI input for ffmpeg, or is there a more standard version that would do the same thing. IT works fine as it is. [12:36:12 CEST] <mavi> $command = 'ffmpeg -i '.$folder.$fileName.' -c:v libx264 -preset veryslow -crf 30 -refs 8 -bf 6 -c:a libfdk_aac -afterburner 1 -signaling implicit -profile:a aac_he_v2 -vbr 1 -movflags +faststart -f mp4 '.$videoFolder.$output.''; [13:08:23 CEST] <bf_> Good morning everyone [13:08:26 CEST] <DemoniacMilk_> hello [13:09:00 CEST] <bf_> I have had trouble compiling libfdk_aac and am using native aac from ffmpeg. Is this okayish or some sort of 10x performance penalty? [13:21:10 CEST] <acamargo> documentation says fdk is performant than native aac but don't show any number [13:24:01 CEST] <DemoniacMilk_> hm i cant get the config to run succesfully, it seems like the parameter for --cpu=foo gets passed to both -mtune and -march ? [13:24:44 CEST] <DemoniacMilk_> adding --cpu=armv7-a to the config execution results in error: bad value (armv7-a) for -march= switch [13:25:09 CEST] <DemoniacMilk_> while --cpu=arm results in error: bad value (arm) for -mtune= switch [13:52:20 CEST] <mavi> fdk vs native is more or less the same as of 2017, the only difference is for low bitrate under 92kbps where fdk is superior. [13:57:33 CEST] <SouLShocK> using the subtitles filter, is it possible to make the background "box" have different sizes when there are two lines of text? i.e. the first line says "Ok." and the second line says "So what do you want?" and I want the background to only be as big as the word "Ok" in the first line and as big as "So what do you want?" in the second line [14:02:38 CEST] <c_14> background box? [14:03:04 CEST] <SouLShocK> yeah. the black opaque background [14:03:43 CEST] <mavi> For ffmpeg, what makes for the best resizer, I want to aim for 480p videos. Keeping same aspect ratio as the original file. Trying to figure out how to do this on ffmpeg [14:03:50 CEST] <c_14> SouLShocK: what subtitle format are you using as input? [14:04:33 CEST] <c_14> mavi: are you asking about what scaling algorithm to use? [14:04:37 CEST] <SouLShocK> c_14: VTT [14:04:43 CEST] <SouLShocK> webvtt i mean [14:05:02 CEST] <c_14> SouLShocK: there shouldn't be a box [14:05:03 CEST] <mavi> Yes I'm trying to figure out which and how. [14:05:41 CEST] <c_14> unless the subtitle file specifies something I guess (though I've never seen that, at least with vtt) [14:05:42 CEST] <mavi> I think lancoz3 is best. But not sure. I'm downsizing from 720p, it's for film not anime. Fairly low bitrate 300kbps. [14:06:23 CEST] <mavi> im currently using the ffmpeg -s command but it's not what i need since it sets it by width. And not sure if it's the best for my application. [14:07:15 CEST] <SouLShocK> c_14: I want the box to be there. and I got it working, but both lines have the same length. this is my current commandline https://pastebin.com/q5sYQjSU [14:07:17 CEST] <c_14> lanczos is probably fine, I'd pick that or bicubic [14:08:29 CEST] <mavi> would it end up looking like this for what i want? [14:08:29 CEST] <mavi> -vf scale=-1:480:flags=lanczos [14:11:14 CEST] <c_14> mavi: if you have yuv420p use -2, but yes [14:11:52 CEST] <c_14> SouLShocK: try setting different values for BorderStyle [14:11:58 CEST] <c_14> 1-3 maybe [14:12:22 CEST] <mavi> I don't use yuv, my source files are just HQ 720p youtube mp4's more or elss. [14:12:37 CEST] <c_14> that's probably yuv420p [14:12:42 CEST] <mavi> interesting [14:12:43 CEST] <c_14> It's the pixel format [14:12:46 CEST] <mavi> how can i tell? [14:12:51 CEST] <c_14> check with ffprobe [14:13:23 CEST] <mavi> crap it says YUV color space [14:13:44 CEST] <mavi> if i use -1 will it negatively affect picture quality? [14:14:23 CEST] <c_14> mavi: no, but yuv420p needs an even width/height. using -2 is the same as -1 except it guarantees the height to be divisible by 2 [14:14:39 CEST] <mavi> perfect [14:14:55 CEST] <mavi> would -16 mean that it needs to be divided by 16pixels/ [14:15:11 CEST] <c_14> yes [14:15:27 CEST] <mavi> easy enough, thanks for the advice. Wouldn';t have figured it out otherwise. [14:15:44 CEST] <c_14> SouLShocK: or convert the vtt to ass and edit with aegisub until it looks like you want it to [14:16:18 CEST] <mavi> Do I put the -vf tag before the -c:v libx264 tag or after it? Or does placement not really matter? [14:16:36 CEST] <c_14> doesn't matter as long as it's after the input files and before the output [14:23:03 CEST] <SouLShocK> c_14: I'm creating a commandline I can reuse for many encodings, this would be used in our transcoding setup for many hours of video every day [14:23:09 CEST] <mavi> Thanks for all the help c_14. [14:23:13 CEST] <SouLShocK> so using aegisub each time would not be feasible [14:25:05 CEST] <Tom_B> can ffmpeg generate the relevant #EXT-X-DISCONTINUITY in HLS? It generates one at the start but not when the aspect ratio of the video changes [15:03:16 CEST] <robswain[m]> can ffmpeg be used for creating MPEG DASH manifests from a set of H.264/AAC in MP4 input files? [15:03:37 CEST] <robswain[m]> it looks like it can for webm but i don't see anything about mp4 [15:04:14 CEST] <c_14> there is a dash muxer [15:04:16 CEST] <c_14> so prabably [15:04:48 CEST] <robswain[m]> hmmm [15:05:47 CEST] <c_14> *probably [15:05:47 CEST] <JEEB> yes, MPEG-DASH can be created [15:06:03 CEST] <JEEB> -f dash or more likely just by the extension (".mpd") for the manifest [15:07:01 CEST] <robswain[m]> i found this: http://stackoverflow.com/questions/40046444/how-should-i-use-the-dash-not-w… [15:07:24 CEST] <robswain[m]> seems to be targeted at live whereas i'm looking into a VOD-type case [15:07:30 CEST] <robswain[m]> i.e. offline encoding [15:09:49 CEST] <robswain[m]> hmmmmm [15:10:07 CEST] <robswain[m]> not entirely clear how to handle multiple representations there either [15:10:52 CEST] <JEEB> well the thing either writes a live or VOD manifest I think [15:10:59 CEST] <JEEB> so that much should be a-OK [15:11:29 CEST] <JEEB> also I think multiple profiles are just done with multiple video/audio tracks, not sure if additional info is needed with multiple same bit rate audio tracks with different languages [15:27:54 CEST] <DemoniacMilk_> quick question: when cross compiling, is there a way to set the path to the stripper etc? [15:28:31 CEST] <bencoh> you must specify a toolchain prefix [15:28:44 CEST] <DemoniacMilk_> --cross-prefix i think? [15:29:44 CEST] <bencoh> yeah [15:29:57 CEST] <bencoh> don't forget --enable-cross-compile as well [15:30:13 CEST] <DemoniacMilk_> if my toolchain is named /a/b/cdef-gcc (and cdef-strip ...) [15:30:23 CEST] <bencoh> prefix is /a/b/cdef- [15:30:25 CEST] <DemoniacMilk_> i just add --cross-prefix=/a/b/cdef- [15:30:25 CEST] <DemoniacMilk_> ye [15:30:29 CEST] <DemoniacMilk_> okay i think i did that [15:30:57 CEST] <DemoniacMilk_> oh but i used ~ instead of the absolute path to my home directory [15:31:03 CEST] <DemoniacMilk_> ill try again, thanks [16:10:16 CEST] <psprint_> Hello. I'm using following to do volume-up, however it seems to re-encode h264 stream, correct? How to copy the stream instead? ffmpeg -i 1st.mov -af "volume=1.5" 1st_volup.mov [16:10:57 CEST] <kepstin> psprint_: if you want to copy the video stream, you can add "-c:v copy" [16:11:10 CEST] <kepstin> psprint_: since you're filtering the audio stream, the audio has to be re-encoded [16:19:35 CEST] <psprint_> yes with audio it's fine. I've used a phone bluetooth "handset" as microphone for Mac. How can I enhance the voice? I thought about some noise filter, and some filter that will sharpen the vowels etc. which filters to use? [16:57:27 CEST] <kepstin> psprint_: hmm, ffmpeg doesn't really have great filters for doing that sort of thing. you might consider extracting the audio to a wav, working on it in audacity or something, then muxing the result back int the file [17:13:48 CEST] <psprint_> kepstin: maybe I'll succeed, -af volume=10dB worked nice, now the low frequencies, but '-af afftfilt="1-clip((b/nb)*b,0,1)"' doesn't work, documentation doesn't state where to put the afftfilt. Any clues? [17:14:24 CEST] <kepstin> psprint_: if you're using multiple filters, you put them all in a single string after -af, separated by commas [17:15:17 CEST] <psprint_> hmm, the message is "No such filter: '0'", after: ffmpeg -i 1st.mov -af afftfilt="1-clip((b/nb)*b,0,1)" -c:v copy 1st_afftfilt.mov [17:16:39 CEST] <kepstin> psprint_: you need to escape the commas inside the expression, try this: -af afftfilt='1-clip((b/nb)*b\,0\,1)' [17:17:13 CEST] <kepstin> (note that I switched from double to single quotes too) [17:17:24 CEST] <psprint_> yeah now it works, thanks [17:17:46 CEST] <Tom_B> is there any way to get h264_vaapi to preserve aspect ratio changes? When I use it it will use the aspect ratio of the first frame but when the aspect ratio changes in the input, it will apply the original aspect ratio for the input. Content that changes from 4:3 to 16:9 will be 4:3 entirely in the output [17:19:01 CEST] <psprint_> kepstin: hyh the example produced silence [17:42:02 CEST] <bf_> Is 30fps for livestream okay, or should it be less? [17:42:29 CEST] <alexpigment> 30fps seems good [17:42:49 CEST] <alexpigment> 60fps would be ideal, but that's far from standard (yet) [17:42:57 CEST] <alexpigment> 30fps is what most livestreams are [17:42:59 CEST] <bf_> 60fps screencast over the internet? [17:43:24 CEST] <bf_> so I have this little thing running now: https://strivewire.com/stream with your help from yesterday :) [17:43:54 CEST] <bf_> frame=11605 fps= 30 q=24.0 q=24.0 size= 38097kB time=00:06:27.75 bitrate= 804.9kbits/s speed= [17:44:09 CEST] <alexpigment> nice, it looks very good [17:44:20 CEST] <bf_> thank you [17:44:41 CEST] <bf_> using -preset:v fast -s hd720 -c:v libx264 -b:v 640K and -s hd1080 -b:v 1280K [17:45:08 CEST] <alexpigment> yeah, 640k is perfectly fine for a stream like this (where the screen is mostly static) [17:45:27 CEST] <alexpigment> however, things will certainly get blocky if the screen changes a lot [17:45:29 CEST] <bf_> ok I understand. So I should play some video game or play a youtube video [17:45:41 CEST] <alexpigment> yeah, you could try that [17:46:11 CEST] <alexpigment> i have a feeling it's going to start turning bad really quickly :) but it'll be good for you to figure out what the ideal bitrate is [17:46:12 CEST] <bf_> let see %) [17:46:48 CEST] <bf_> Ok it looks a bit like puke [17:47:37 CEST] <alexpigment> not as bad as i was expecting, tbh, but i think it's because the input framerate is lower than 30fps on that video [17:47:50 CEST] <alexpigment> or the stream itself is dropping FPS [17:48:15 CEST] <bf_> so ffmpeg tells met my stream is 29 fps with 870kbit [17:48:21 CEST] <bf_> speed = 0.97X [17:48:37 CEST] <Tom_B> hmm, no matter what x264 codec I use (vaapi, nvenc, libx264) when I convert a .ts to .mp4 it doesn't preserve the aspect ratio change from 16:9 - 4:3, is there any way to keep this during the conversion? [17:49:02 CEST] <alexpigment> bf_ you know, it might be worth changing your preset to "veryfast" [17:49:13 CEST] <alexpigment> just to make sure you don't drop frames when the input gets a little complex [17:49:33 CEST] <bf_> how can I check framedrop over time? I don't always control the input [17:49:59 CEST] <bf_> I also only use preset:v not preset:a - is that something I should adD? [17:50:12 CEST] <alexpigment> nah, preset:v is the h.264 preset [17:50:22 CEST] <alexpigment> which changes what parameters are used to encode the video [17:50:30 CEST] <alexpigment> but audio doesn't usually have such presets [17:50:54 CEST] <kepstin> Tom_B: I doing think there's any way to signal an aspect ratio switch in the middle of an mp4 file, you might be out of luck there. [17:51:18 CEST] <kepstin> Tom_B: most container formats just stick the aspect ratio or sar in a global header in the file :/ [17:51:28 CEST] <alexpigment> Tom_B what source even switches aspect ratio midstream? [17:51:39 CEST] <alexpigment> seems like an odd thing to do and a recipe for failure :) [17:51:48 CEST] <Tom_B> I'm really just trying to convert to HLS but thought mp4 would be a simpler trial [17:51:48 CEST] <kepstin> mpeg-ts and mpeg-ps can, I think [17:51:57 CEST] <JEEB> I've seen broadcast switch between them just fine [17:51:59 CEST] <Tom_B> mpeg-ts from a dvb broadcast [17:52:03 CEST] <JEEB> 4:3 content and 16:9 content f.ex. [17:52:07 CEST] <JEEB> and I wouldn't limit it to DVB [17:52:21 CEST] <alexpigment> ah [17:52:22 CEST] <JEEB> broadcast in general can and you can always find people doing it from any side of the world :P [17:52:47 CEST] <bf_> %) [17:52:50 CEST] <alexpigment> US cable companies or OTA broadcasts don't do it, so i'm not familiar with it [17:53:08 CEST] <alexpigment> bf_ if you click on the gear icon on that person's stream and check "Video stats", what is their framerate? [17:53:26 CEST] <alexpigment> it's hard to tell how smooth your stream is because their stream might be choppy [17:53:27 CEST] <kepstin> most ATSC broadcasts around here, they upscale/re-encode everything into a continuous 1080i60 stream :/ [17:53:37 CEST] <Tom_B> perhaps I could enforce 16:9 and write black bars to the frame [17:53:40 CEST] <alexpigment> yep, that's my experience too kepstin [17:53:59 CEST] <alexpigment> Tom_B that would be my choice [17:54:02 CEST] <bf_> alexpigment: it is 60fps [17:54:02 CEST] <bf_> wow [17:54:06 CEST] <alexpigment> hmm [17:54:10 CEST] <bf_> I thought like 30 would be ok for everyone [17:54:17 CEST] <alexpigment> bf_ are they dropping frames? [17:54:29 CEST] <bf_> skipped frames: 15k [17:54:33 CEST] <alexpigment> oh ok ;) [17:54:34 CEST] <alexpigment> well [17:54:35 CEST] <alexpigment> there's that [17:54:46 CEST] <bf_> who drops frames? my pc because of performance? [17:54:49 CEST] <alexpigment> might want to find a better streamer to benchmark your own stream [17:55:03 CEST] <alexpigment> i want to say that skipped frames are on the broadcaster's side [17:55:23 CEST] <bf_> so he captures with 60fps but is only able to pipe out less than that via his upstream? [17:55:53 CEST] <alexpigment> bf_ nm, i'm seeing some conflicting info onlnie [17:55:54 CEST] <alexpigment> *online [17:56:15 CEST] <bf_> %) [17:56:24 CEST] <bf_> now I see why people use gigabits of bandwith [17:56:38 CEST] <bf_> If i need to pipe 2mbps to each viewer it is a shitload of traffic [17:56:43 CEST] <Tom_B> for my underlying issue though, it seems to be vaapi, converting from mpegts -> h264 in a ts container, the aspect ratio change works only if I encode using libx264, using h264_vaapi, it doesn't :( [17:57:42 CEST] <alexpigment> bf_ yeah it's going to be a lot of traffic for sure [17:57:56 CEST] <alexpigment> bf_ it might be worth stopping your stream, then checking the twitch stream again [17:58:03 CEST] <alexpigment> to see if it's still skipping a lot of frames [17:58:35 CEST] <kepstin> Tom_B: in general, x264 is a lot more capable and less buggy than hardware encoders :/ [17:58:48 CEST] <alexpigment> assuming it goes away, then there's a performance problem - which is very likely given how resource-intensive encoding is [17:59:11 CEST] <bf_> alexpigment: it still skips around 5 frames per second [17:59:20 CEST] <bf_> i stopped both streaming and viewing my own stream [17:59:24 CEST] <alexpigment> bf_ are you on chrome? [17:59:29 CEST] <bf_> yes chromium arch [17:59:51 CEST] <alexpigment> check the advanced settings in chromium to see if hardware acceleration is enabled [17:59:52 CEST] <bf_> 1920x1080 stream with 60fs, 2633kps [17:59:58 CEST] <alexpigment> i'd toggle it either way, just to see [18:00:07 CEST] <Tom_B> keepstin, unfortunately it's also incredibly slow in comparison. Is there a way to enforce an aspect ratio without setting a specific resolution? [18:00:17 CEST] <bf_> alexpigment: it is checked [18:00:25 CEST] <alexpigment> try unchecking it, just to see what happens [18:00:33 CEST] <alexpigment> you may have to restart the browser. not sure [18:01:57 CEST] <kepstin> Tom_B: it would be kind of tricky, I don't think the expressions in e.g. the pad filter get re-evaluated each frame, so doing it in filters might not work. [18:02:24 CEST] <bf_> alexpigment: skipping even more frames [18:02:28 CEST] <bf_> like 40 per 2 secs [18:02:31 CEST] <alexpigment> yeah i figured so ;) [18:02:36 CEST] <alexpigment> what GPU do you have? [18:02:43 CEST] <alexpigment> and have you updated the graphics in a while? [18:02:46 CEST] <bf_> nvidia but it is misconfigured [18:02:48 CEST] <alexpigment> the drivers, i mean [18:02:54 CEST] <bf_> no i dont touch them with a ten foot pole [18:02:57 CEST] <bf_> im on linux man :D [18:02:57 CEST] <alexpigment> ah [18:03:01 CEST] <alexpigment> yeah i hear you [18:03:02 CEST] <bf_> never change a running system [18:03:06 CEST] <alexpigment> true [18:03:16 CEST] <bf_> %) [18:03:25 CEST] <alexpigment> what nvidia card in particular? [18:03:47 CEST] <kepstin> Tom_B: actually, the pad and scale filters can be set to re-evaluate expressions each frame, so it is doable [18:04:09 CEST] <Tom_B> makes sense, I'll upscale to 1080p and see if it's fast enough. I've tried -aspect 16:9 -s 1920x1080 but it just stretches the 4:3 segment of the video [18:04:39 CEST] <kepstin> Tom_B: yeah, you need to use the scale and pad filters with expressions that calculate the needed scaling and padding based on the frame size and aspect ratio. [18:04:56 CEST] <Tom_B> are there any examples of doing something similar anywhere? [18:05:47 CEST] <bf_> alexpigment: GK107GLM [Quadro K2000M] [18:06:09 CEST] <kepstin> Tom_B: start by reading the examples for the scale and pad filters in the ffmpeg-filters doc... [18:06:47 CEST] <alexpigment> bf_ ok that's a Kepler-era chip, but i'm not intimately familiar with the differences in Quadro vs GeForce when it comes to video acceleration [18:06:55 CEST] <kepstin> Tom_B: I don't think there's anything there that specifically matches what you're doing, but there should be enough for a start [18:07:02 CEST] <alexpigment> at any rate, you may just want to simply drop the stream playback from Source to High Quality [18:07:13 CEST] <bf_> alexpigment: its my old thinkpad w530 [18:07:16 CEST] <bf_> yeah you're right i moved it up [18:07:18 CEST] <alexpigment> that should probably get you at zero / near-zero dropped frames [18:07:37 CEST] <bf_> yes not it is only 1 per 2 sec [18:07:44 CEST] <psprint_> has anyone tested filter for noise reduction (audio) ? [18:07:49 CEST] <alexpigment> Source is the only way to get 60fps, so I assume you were on Source [18:07:54 CEST] <bf_> yes %) [18:07:58 CEST] <bf_> alexpigment: are you also in gaming? [18:08:00 CEST] <alexpigment> did you recheck hardware acceleration? [18:08:10 CEST] <bf_> yes but not restart browser, it is still sw [18:08:18 CEST] <alexpigment> not really, although i do enjoy a few speedrunner's streams of retro games [18:08:24 CEST] <bf_> oh cool [18:08:39 CEST] <alexpigment> bf_ ok, so high quality setting + hardware acceleration probably will have no dropped frames [18:09:40 CEST] <bf_> I hope so :) [18:09:57 CEST] <DHE> alexpigment: there's no significant difference between quadro and geforce encoders except if you get into the really highend stuff. in that case the limit of 2 encoder instances is removed (no limit). [18:10:25 CEST] <bf_> I'm really not sure if my current driver setup is that advanced :) [18:11:22 CEST] <alexpigment> DHE: we were talking about hardware accelerated in decoding, but i assume what you say is probably true still [18:11:39 CEST] <alexpigment> *hardware accelerated decoding in web browsers, i mean [18:12:05 CEST] <DHE> oh... [18:12:20 CEST] <DHE> but still, the cards are mostly identical. it's like comparing a core i7 vs a Xeon [18:12:25 CEST] <bf_> alexpigment: I asked yesterday already, but as we're talking about encoders: [18:12:41 CEST] <bf_> I see high cpu usage: http://i.imgur.com/qiRYdDD.png but only convert rtmp to 720p and 1080 [18:12:44 CEST] <alexpigment> yeah, i just didn't want to speak from authority, but i assume Kepler is Kepler, or more specifically, GK107 is GK107 [18:12:51 CEST] <bf_> would putting a good graphics card into the server help? [18:13:24 CEST] <alexpigment> only if you're going to switch to NVENC [18:13:35 CEST] <alexpigment> which is a separate encoder from x264 [18:13:54 CEST] <alexpigment> admittedly, for real time streaming, nvenc is not a bad solution, even if the quality isn't as good at a given bitrate [18:14:18 CEST] <DHE> without looking at the spec sheets, kepler is going to be able to do 100fps at 1080p without trouble I think [18:14:25 CEST] <alexpigment> so if it's easier to up your stream birate by a mbit or two than it is to deal with this much CPU load, NVENC is not bad i guess [18:14:37 CEST] <bf_> alexpigment: what kind of improvement are we talking? because this is an 8 core server and I was expecting it to be able to handle 10 streams at the same time. now there is only one [18:14:56 CEST] <bf_> the higher the bitrate, the lower cpu? [18:15:10 CEST] <alexpigment> DHE: theoretical, of course:) the browser layer really screws up those figures. still though, i've watched twitch at 60fps before without dropping frames on a kepler chip [18:16:01 CEST] <alexpigment> bf_ bitrate has little to do with it. encoding is just resource-intensive. handling 10 streams at 720p is going to be basically impossible on consumer-grade hardware [18:16:06 CEST] <DHE> not really. it's mainly a matter of encoder settings. preset ultrafast can probably handle that at 720p or 1080p on that machine, but the image quality will be poor overall to the point that nvenc is better suited [18:16:52 CEST] <DHE> all other things being equal, double bitrate may increase CPU usage by some small factor, probably less than 10%. most of the effort is in the motion estimation [18:17:02 CEST] <alexpigment> well, he's using veryfast right now, so comparing ultrafast to NVENC isn't really relevant (at the moment) [18:17:15 CEST] <DHE> okay then [18:17:34 CEST] <alexpigment> but yeah, i don't imagine ultrafast would change the CPU usage that much either [18:17:52 CEST] <alexpigment> to really free up the CPU, you need to use hardware encoders [18:17:53 CEST] <bf_> okay, so if I put 4 nvidia cards into such an server it could handle 10 streams? or even more? [18:18:04 CEST] <alexpigment> bf_ i think you'd be able to handle 4 streams [18:18:29 CEST] <bf_> is it the same gpu stuff people use for rendering / cuda / bitcoin mining? [18:18:32 CEST] <alexpigment> i'm not 100% sure, but i was thinking that FFMPEG can't do more than one stream per card [18:18:49 CEST] <alexpigment> no, NVENC is specifically an encoder chip on the system, rather than using cuda cores [18:19:08 CEST] <alexpigment> you could thoeretically create a video encoder that uses the cuda cores, but no one does it to my knowledge [18:19:10 CEST] <DHE> ffmpeg can do 2 per card. but unless you get the EXPENSIVE cards ($1,000 each or more) you're restricted by the nvidia driver to 2 encoders regardless. [18:19:28 CEST] <bf_> such an interesting problem :) [18:19:43 CEST] <alexpigment> ok, well i guess 2 it is :) [18:19:44 CEST] <bf_> now I understand the market for encoding on demand, and all those other solutions [18:19:55 CEST] <bf_> thanks for your clarifications, really much appreciated [18:20:17 CEST] <DHE> I imagine with these expensive cards ffmpeg would have no limit (other than running out of card capacity and no longer doing realtime). not that I have any of these cards. :/ [18:20:49 CEST] <alexpigment> DHE is the 2-stream thing even true for the high end 1000 series cards? [18:21:37 CEST] <bf_> Amazon offers "High-performance NVIDIA K80 GPUs, each with 2,496 parallel processing cores and 12GiB of GPU memory", would that work? [18:22:03 CEST] <alexpigment> again, it really just comes down to the NVENC chip itself on the card [18:22:16 CEST] <alexpigment> those parallel processing cores and extra memory are kinda irrelevant [18:22:42 CEST] <bf_> I understand [18:22:52 CEST] <alexpigment> i'm researching newer GeForce cards though to see if that restriction has been changed [18:22:52 CEST] <bf_> I should probably go with nvidia then https://developer.nvidia.com/video-encode-decode-gpu-support-matrix [18:24:16 CEST] <alexpigment> the K2000 chip you have can only do 2 streams, but apparently the K2200 of that same generation can do more than 2... (still researching) [18:24:37 CEST] <bf_> but the k2000 is a consumer card, right? [18:24:46 CEST] <alexpigment> Noooooo... :) [18:24:54 CEST] <DHE> alexpigment: Only Quadro cards are unlocked. I don't know which exactly. I have a workstation quadro and it's locked [18:25:08 CEST] <alexpigment> DHE: he has a quadro right now ;) [18:25:23 CEST] <DHE> right. so do I. it's a tiny little workstation quadro and it's locked to 2. [18:26:01 CEST] <bf_> so wowza claims that aws g2.2xlarge works with nvenc, but amazon doesn't specify the nvidia gpu on those [18:26:09 CEST] <bf_> only says: Each GPU features an on-board hardware video encoder designed to support up to eight real-time HD video streams (720p@30fps) or up to four real-time full HD video streams (1080p@30fps) [18:26:44 CEST] <bf_> you can choose 1 or 4 gpus (so 4 streams or 16 streams) [18:26:59 CEST] <bf_> sounds like burning money [18:27:22 CEST] <alexpigment> yeah, but if a 1050 can do it, for example, that wouldn't be too bad [18:27:29 CEST] <alexpigment> <$500 USD [18:27:39 CEST] <alexpigment> i'm just not finding any info on Pascal cards [18:28:06 CEST] <DHE> bf_: those numbers are going to be based on the GPU chipset, not the speed or exact model. a kepler is a kepler. the nvenc chip is unchanged [18:28:21 CEST] <DHE> but from those numbers you could look up if it's maxwell, pascal or kepler [18:30:01 CEST] <bf_> so the amazon one i mentioned seems to be the GK104 Kepler [18:31:48 CEST] <alexpigment> http://developer.download.nvidia.com/designworks/video-codec-sdk/secure/7.1… [18:32:07 CEST] <alexpigment> check out "3. NVENC LICENSING POLICY" starting at the bottom of page 7 [18:32:15 CEST] <pzy> I am excited to play with the new NDI/SpeedHQ stuff in ffmpeg, anyone worked much with those? [18:32:27 CEST] <alexpigment> it says that it limits to do for all Geforce and for "low end Quadro" [18:32:57 CEST] <bf_> wow so it is only limited by their eula? [18:33:28 CEST] <alexpigment> not sure. it's either that, or they just put it in that section [18:33:40 CEST] <alexpigment> but the list of cards which support more is hard to find on the page they reference [18:35:26 CEST] <alexpigment> there's apparently a Quadro GP100 which 3 NVENC encoders on it [18:35:50 CEST] <alexpigment> and given that it's a high end quadro, that 2-stream limit probably isn't applicable [18:36:00 CEST] <alexpigment> i would be scared to know how much that costs :) [18:36:33 CEST] <bf_> ok ars says > 6k [18:36:39 CEST] <bf_> thank you very much alexpigment [18:36:52 CEST] <alexpigment> there's the Quadro P4000 as well, which has 2 NVENC encoders [18:36:56 CEST] <alexpigment> probably costs a lot less [18:37:03 CEST] <alexpigment> https://developer.nvidia.com/video-encode-decode-gpu-support-matrix#Encoder [18:37:50 CEST] <bf_> I think I'll go with the aws instance first [18:38:17 CEST] <alexpigment> k4000 [18:38:18 CEST] <alexpigment> er [18:38:25 CEST] <alexpigment> is that the one you're referring to? [18:38:39 CEST] <alexpigment> or are you talking about amazon web services? [18:39:06 CEST] <bf_> sorry i am talking about aws [18:39:08 CEST] <bf_> g2.2xlarge: 15 GiB Arbeitsspeicher, NVIDIA GRID GPU (Kepler GK104), [18:39:22 CEST] <alexpigment> ahh [18:39:39 CEST] <bf_> oh wait it only has one nvdec chip [18:40:16 CEST] <alexpigment> it should have 4 [18:40:34 CEST] <alexpigment> it's 1 nvenc / chip [18:40:38 CEST] <alexpigment> and there are 4 chips, right? [18:41:11 CEST] <bf_> no it only has once gpu, gk104 kepler and based on nvidia matrix it only has 1 nvenc chip : https://developer.nvidia.com/video-encode-decode-gpu-support-matrix [18:41:28 CEST] <bf_> but there is also one with 8x or 16x kepler gk210 [18:41:58 CEST] <bf_> which have 2 nvenc chips per gpu [18:42:19 CEST] <bf_> alexpigment: sorry it is all a bit confusing :) [18:42:19 CEST] <alexpigment> ok, but look at the "# of Chips" column [18:42:30 CEST] <alexpigment> no worries. i agree that it's very confusing [18:42:41 CEST] <alexpigment> the GRID cards all have multiple chips [18:42:55 CEST] <alexpigment> and then the next column is "# of NVENC / CHIP" [18:43:00 CEST] <bf_> so you think it is a grid card? [18:43:06 CEST] <bf_> I assumed they'd pick the lowest config %) [18:43:10 CEST] <alexpigment> i thought you said it was a grid card ;) [18:43:16 CEST] <bf_> oh yes, sorry [18:43:19 CEST] <bf_> stupid me [18:43:23 CEST] <alexpigment> no worries ;) [18:43:42 CEST] <bf_> so they indeed have 2 nvenc chips [18:43:45 CEST] <jkqxz> How much encode (or transcode?) capability do you actually need here? In general, NVENC is unlikely to be a sane solution in terms of cost or power for video unless you also need the graphics hardware for something else. [18:45:27 CEST] <alexpigment> jkqxz he was talking about 10 simultaneous streams, so nvenc seems like a more realistic way to go [18:45:44 CEST] <jkqxz> (Comparing against "just buy more CPUs and use libx264 veryfast", or even quicksync if you can tolerate Intel horribleness.) [18:46:30 CEST] <jkqxz> At what resolution/framerate? [18:47:03 CEST] <alexpigment> 720p30 at the moment, right bf_? [18:47:36 CEST] <bf_> so both 720p and 1080p for each incoming stream [18:48:22 CEST] <bf_> and I wanted to run more than one stream per server, I find it a bit uneconomic to spin up an instance for a streamer [18:49:00 CEST] <bf_> I'm just learning my way around ffmpeg and video streaming, so most of these questions are most likely very amateurish, just want to figure out a solution which lets me sleep at night [18:49:29 CEST] <bf_> jkqxz: with 30fs, yes alexpigment [18:49:36 CEST] <jkqxz> Um. Any normal Intel desktop chip can do that much in quicksync. [18:49:55 CEST] <jkqxz> Probably needs a decent server CPU to do it in software, but certainly not a huge one. [18:50:08 CEST] <alexpigment> jkqxz: have you had much experience with this? [18:50:20 CEST] <bf_> for 10x 720p+1080p rtmp to hls in parallel? [18:50:58 CEST] <bf_> jkqxz: i was a bit shocked after my htop told me http://i.imgur.com/qiRYdDD.png with one stream running [18:51:15 CEST] <jkqxz> bf_: Yes. That's around the expected throughput, though, so you might not manage 10 if you're doing other stuff. [18:51:47 CEST] <alexpigment> here's an excerpt of something i read earlier online:"Looking at the ffmpeg quick sync code, it tries to check QuickSync busy status, and if it is busy, then it sleeps for a very short period (e.g., 1000 microseconds), then tries again. When I run 15 ffmpeg instances simultaneously, they are spending a lot of time in that sleep/retry loop." [18:52:11 CEST] <alexpigment> which implies to me that, sure, you can do a bunch of streams at once, but they're all waiting most of the time [18:53:05 CEST] <jkqxz> Yes, the people who made libmfx don't understand how to design APIs. This is unfortunate, but not really a problem. [18:53:30 CEST] <bf_> so I should try to get rid of ffmpeg asap? [18:53:46 CEST] <alexpigment> well, i don't have any first-hand experience with concurrent quicksync encodes, so i'll defer to jkqxz's experience in this [18:53:47 CEST] <bf_> twitch.tv rolled their own golang thing [18:54:14 CEST] <jkqxz> I don't understand what your image is trying to show. [18:54:15 CEST] <bf_> jkqxz: the server with the htop screenshot is only doing the rtmp->hls with nginx-rtmp [18:54:25 CEST] <alexpigment> bf_ not sure if this is related to what you're asking, but FFMPEG supports quicksync [18:55:34 CEST] <bf_> ok so there are two hardware approaches to encoding, nvenc by nvidia and quicksync by intel. In your experience jkqxz, is quicksync preferable to nvenc? [18:55:47 CEST] <iive> bf_: 10x 720p+1080p could probably be done with nvenc on a single professional card. [18:56:14 CEST] <Cheech> how onw would transport alpha channel in MPEGTS compatible codec? [18:56:38 CEST] <iive> consumers cards are limited to 2 steams by the driver, or so I've heard. [18:56:40 CEST] <jkqxz> I have done little with NVENC beyond some minor testing and finding that it is very crippled on all sensibly-priced cards. [18:56:51 CEST] <bf_> iive: that's what i will try with aws's smallest g2.* instance [18:57:12 CEST] <bf_> I will try to use something out of aws preferably because our other setup is in there already [18:57:46 CEST] <iive> still, one professional card would cost less than 10 PC's [18:57:55 CEST] <kerio> is h264 somehow not supported in mpegts? [18:58:08 CEST] <kerio> i tried streaming a video over udp without transcoding, and i couldn't get it to work [18:58:08 CEST] <DHE> no, h264 in mpegts is quite normal [18:58:18 CEST] <kerio> does it require some special stuff [18:58:20 CEST] <DHE> kerio: make sure you set the pkt_size=1316 in yoru UDP output [18:58:39 CEST] <kerio> how do i do that [18:58:47 CEST] <kerio> is it an option to udp, or to mpegts [18:58:48 CEST] <DHE> "-pkt_size 1316" or "udp://1.2.3.4:5678?pkt_size=1316" [18:58:52 CEST] <iive> kerio: Annex B (bsf) , so that you have reatpeated headers [18:59:02 CEST] <iive> repeated [18:59:20 CEST] <DHE> usually mpegts will complain if it doesn't get annex b content [18:59:23 CEST] <kerio> oh ;o [18:59:47 CEST] <iive> also, make sure nothing reorders the udp packets [19:00:06 CEST] <DHE> also set -g to a sane value. huge numbers will prevent playback. maybe 100? at 30fps you may experience startup delays up to ~4 seconds [19:00:17 CEST] <bf_> thanks again alexpigment DHE jkqxz for your kind help [19:00:42 CEST] <kerio> wait, this isn't h264 at all [19:00:44 CEST] <kerio> this is mpeg4 [19:01:38 CEST] <kerio> i'm getting "[ffmpeg/demuxer] mpegts: PES packet size mismatch" in mpv [19:05:21 CEST] <alexpigment> bf_ np. i learned a lot from the conversation, so thanks for bringing it up. [19:05:44 CEST] <bf_> :) [19:05:53 CEST] <bf_> me too [19:28:54 CEST] <Tom_B> I'm trying to force all the content to 16:9 by padding black bars, but when the aspect ratio changes during play, it doesn't seem like the scale filter sees the change. I have if(lt(a,16/9) but `a` seems to have a fixed value, rather than applying to the current frame [19:29:47 CEST] <alexpigment> Tom_B: is this a one-time job, or an ongoing problem you'll have to deal with? [19:30:27 CEST] <alexpigment> if it's a one-time job, it might be worth just cutting the stream at the aspect ratio change and then treating each part separately [19:30:33 CEST] <alexpigment> then re-combine them later [19:30:34 CEST] <Tom_B> Ongoing, I'm converting dvb streams to HLS so the content will change frequently [19:30:40 CEST] <alexpigment> ah [19:30:42 CEST] <alexpigment> :( [19:34:35 CEST] <Tom_B> unfortunately the iw/ih variables also seem to be set once rather than apply to each frame. Obviously good for performance but not helpful when the aspect ratio changes during the video [19:44:09 CEST] <kepstin> Tom_B: you need to set the option 'eval=frame' on the pad filter [19:44:19 CEST] <kepstin> otherwise it only checks once at the start of the stream [19:45:02 CEST] <kepstin> (if your pad filter doesn't support that, you need a newer ffmpeg) [19:46:34 CEST] <kepstin> actually, that looks like a *really* recent addition, might need to build from git [19:47:04 CEST] <kepstin> or wait for ffmpeg 3.3 release, which is probably gonna be soon :) [19:47:06 CEST] <Tom_B> is this correct? pad=width=1920:height=1080:eval=frame assuming i had the latest git version [19:47:55 CEST] <kepstin> Tom_B: something like that yeah. In your stream, does only the aspect ratio switch, or also the resolution? [19:48:09 CEST] <kepstin> you'll probably need more complicated expressions, but that's a start :) [19:48:57 CEST] <Tom_B> It's actually only the aspect ratio but I'd probably need to handle resolution as well. I'm just trying to get a working example before tweaking it [19:50:41 CEST] <pzy> according to the changelog, SpeedHQ support was added recently. anyone know if that includes SpeedHQ2? newtek sucks at documentation [19:51:23 CEST] <pzy> Stream #0:0(eng): Video: none (SHQ2 / 0x32514853) [19:53:04 CEST] <pzy> Codec ID : V_MS/VFW/FOURCC / SHQ2 [19:58:11 CEST] <pzy> oh I see, it's slated for the next version [20:27:33 CEST] <Tom_B> hmm, I can't get eval=frame to work. The problem is the scale rather than the pad. Pad works, but obviously if it's already been scaled to a resolution it won't make any difference. I'd expect scale=iw*a:ih*a:eval=frame to at least give me some visible difference when the aspect ratio changes but it doesn't [20:38:20 CEST] <Tom_B> This should give me either a 400x300 or 160x90 image in a 1000x1000 video: scale="'if(lt(a,16/9),400,160)':'if(lt(a,16/9),300,90)':eval=frame",pad=1000:1000:eval=frame but still the size is always the same [21:02:37 CEST] <kepstin> Tom_B: huh. which size is it giving you? does it just match the initial state and not update, or is it always one or the other? [21:03:58 CEST] <kepstin> I assume this is non-HD content? I'd expect HD content will always be 16:9, I don't think dvb supports 4:3 HD stuff? [21:04:39 CEST] <kepstin> (and 576 line video ("PAL")?) [21:07:02 CEST] <JEEB> broadcast supports HD 4:3 and 16:9 just fine [21:07:57 CEST] <kepstin> my quick look at the DVB specs I can find say "MPEG-2 HDTV pictures have 16:9 or 2.21:1 aspect ratio; IRDs support 16:9 and optionally 2.21:1 aspect ratio." and "H.264/AVC HDTV pictures have 16:9 aspect ratio; IRDs support 16:9 aspect ratio." [21:08:12 CEST] <kepstin> of course, I live in ATSC land where they pillarbox everything in a 1080i stream, so :/ [21:08:41 CEST] <JEEB> don't worry [21:08:44 CEST] <JEEB> MMTP is coming [21:08:49 CEST] <JEEB> and then all of us FFFUUU [21:09:22 CEST] <kepstin> also from that same spec: "SDTV pictures may have either 4:3, 16:9 or 2.21:1 aspect ratio; IRDs support 4:3 and 16:9 and optionally 2.21:1 aspect ratio." [21:09:38 CEST] <kepstin> so yeah, only SDTV content listed as supporting 4:3? [21:09:54 CEST] <JEEB> ok [21:10:01 CEST] <kepstin> hmm. admittedly, this doc is from 2009, it might have changed [21:10:04 CEST] <kepstin> probably not tho [21:15:12 CEST] <ChocolateArmpits> what does "t" do in expressions ? [21:15:39 CEST] <jkqxz> Tom_B: You sent #6276 for aspect ratio in VAAPI? I think <http://sprunge.us/PLTC> kindof fixes it, if you don't mind waiting for the next GOP before it updates. If you do, then it requires more code to detect the change and actually push the reconfiguration immediately (as libx264 does). [21:15:49 CEST] <kepstin> ChocolateArmpits: depends on what's evaluating the expression, but in most places t or T means "the current pts value, converted to seconds" [21:16:41 CEST] <ChocolateArmpits> kepstin, why it's not listed in utilities document ? neither in drawtext that can use it [21:16:58 CEST] <ChocolateArmpits> ahhh [21:16:59 CEST] <ChocolateArmpits> >timestamp expressed in seconds, NAN if the input timestamp is unknown [21:17:01 CEST] <furq> it is listed in drawtext [21:17:10 CEST] <kepstin> ChocolateArmpits: because the variables available depend on the filter, it's not generic in all expressions [21:18:21 CEST] <mavi> Just curious is using an ultralight denoiser filter or x264's nr at 300 better? [21:18:31 CEST] <mavi> The content is fairly clean, just want to increase compressibility. [21:19:05 CEST] <furq> afaik nr is very fast but not very good [21:37:37 CEST] <gwohl1> I want to use FFmpeg to process stereoscopic video sources into monoscopic by outputting only the left video, and not the right. Should I do this by using the stereo3d filter and only outputting the left video, or should I just crop out the left eye using the crop filter? Is there a substantial difference between how the stereo3d and crop filters work in this context? [21:38:58 CEST] <ChocolateArmpits> mavi try hqdn3d, you can mix and match spatial and temporal filtering to your liking [21:51:40 CEST] <alexpigment> gwhol1: is the source SBS or top/bottom? [21:51:45 CEST] <alexpigment> or is it MVC? [21:55:37 CEST] <gwohl1> alexpigment it is mostly top/bottom [21:55:57 CEST] <alexpigment> is it full (1920x2160) or half (1920x1080)? [21:56:21 CEST] <gwohl1> alexpigment I am working with 4096x4096 [21:56:39 CEST] <gwohl1> this is for VR headsets, not the traditional blu-ray 3D [21:56:52 CEST] <alexpigment> oh gotcha [21:57:05 CEST] <alexpigment> so the actual visible resolution is 4096x2048? [21:58:33 CEST] <alexpigment> rather than confuse you with more questions, the question i'm trying to get at is if scaling is involved to get the correct aspect ratio once the top and bottom are separated. if so, it might be ideal to avoid cropping because you'll have to rescale as well [22:06:12 CEST] <gwohl1> alexpigment I see, thanks for your help! Luckily we will not be doing any scaling until after the monoscopic video has been generated. [22:06:37 CEST] <gwohl1> We receive 4096x4096 ProRes 422 sources directly from the content publishers [22:06:59 CEST] <alexpigment> and that consists of 2 4096x2048 streams, one on top of the other, right? [22:13:53 CEST] <durandal_1707> stereo3d is just easier to play with for ordinary user [22:16:11 CEST] <gwohl1> alexpigment No, each stream is 2048x2048, on on top of the other. So the full resolution of the stereoscopic video is 4096x4096 [22:16:30 CEST] <alexpigment> gwohl1: that is extremely confusing to me, but ok [22:21:38 CEST] <celyr> Hi [22:22:05 CEST] <gwohl1> @alexpigment err, my bad. You're right. I meant to say that the videos are 4096x2048, one on top of the other. [22:23:10 CEST] <alexpigment> k [22:23:34 CEST] <alexpigment> well then it shouldn't matter which method you choose in ffmpeg [22:28:31 CEST] <thebombzen> what is the purpose of pro-res [22:28:53 CEST] <thebombzen> why the hell is lossy intra-only intermediary-production a good idea [22:28:55 CEST] <JEEB> prores is what apple came up with after they thought they needed something like MJPEG [22:29:11 CEST] <JEEB> also welcome to broadcast or enterprise [22:29:18 CEST] <thebombzen> yea but prores is supposed to be like "an intermediary codec" [22:29:21 CEST] <JEEB> it's either raw or it's lossy with effing heavy bit rate [22:29:24 CEST] <thebombzen> which mjpeg is definitely not [22:29:37 CEST] <thebombzen> but if you're going to do Lossy with Heavy Bitrate [22:29:37 CEST] <alexpigment> MJPEG is intermediate if you throw enough bitrate at it [22:29:40 CEST] <JEEB> they don't seem to know the case of lossless and packed [22:29:50 CEST] <JEEB> although EU is standardizing FFV1 [22:29:54 CEST] <thebombzen> is it actually [22:29:55 CEST] <thebombzen> wow [22:30:01 CEST] <thebombzen> but if they're going to do Lossy with Heavy Bitrate [22:30:03 CEST] <thebombzen> why Intra-only [22:30:10 CEST] <thebombzen> that sounds like it sorta defeats the whole point of lossy [22:30:12 CEST] <alexpigment> intra-only is good for NLEs [22:30:12 CEST] <JEEB> because they need instant seeking [22:30:28 CEST] <thebombzen> but like [22:30:30 CEST] <thebombzen> why not just have like [22:30:39 CEST] <thebombzen> a keyframe interval of 5 frames or something [22:30:45 CEST] <thebombzen> and cache the GOPs [22:30:53 CEST] <JEEB> anyways, you're hitting the goddamn questions that everyone asks about broadcasting and enterprise [22:30:56 CEST] <kepstin> modern computers are fast enough that that's a reasonable option, yeah :/ [22:31:14 CEST] <thebombzen> so in other words, it just doesn't really make sense [22:31:16 CEST] <alexpigment> it *is* nice to have a snappy intra only codec in an NLE though [22:31:36 CEST] <alexpigment> even on fast computers, it makes a difference in the overall feel of the workflow [22:31:37 CEST] <JEEB> yes, but at this point that GOP can be a couple of frames, I remember like seven years ago someone tested with AVC [22:31:48 CEST] <kepstin> hey, on most videos encoded with x264 modes medium or faster, I can do backwards trick play by just holding down ',' in mpv :/ [22:31:53 CEST] <JEEB> and optimal GOP then was about 3 frames :P [22:32:00 CEST] <thebombzen> but you could mimic that "snappiness" with a 5-frame GOP [22:32:06 CEST] <thebombzen> just IPPPP [22:32:23 CEST] <thebombzen> and when you seek, you cache the GOP so framestepping doesn't require you to decode it every time [22:32:42 CEST] <thebombzen> modern computers are fast enough that this is viable [22:32:47 CEST] <alexpigment> thebombzen: i think the other thing to consider is that the industry that intermediate codecs are designed for don't care about fine tuned optimizations. they have the storage space [22:32:52 CEST] <llogan> broadcast is the best. especially when you get to fight with insane stream anal-yzers. [22:33:03 CEST] <kepstin> the reduction of IO needed to load UHD frames is probably enough to make it feel snappier like that than a big intra-only frame :/ [22:33:04 CEST] <JEEB> llogan: lol [22:33:21 CEST] <JEEB> "please up your bit rate because our expensive machine says you're not supposedly using it enough" [22:33:24 CEST] <pzy> where's ATSC 3.0 llogan?! :P [22:33:24 CEST] <JEEB> "..." [22:33:33 CEST] <thebombzen> lol JEEB [22:33:33 CEST] <thebombzen> this [22:33:35 CEST] <JEEB> or other technicalities that aren't illegal anywhere [22:33:43 CEST] <llogan> PMT interval was over 40 ms [22:33:48 CEST] <thebombzen> like when Bluray H.264 complains that you're not using 50 Mbps for your lowmotion video [22:33:49 CEST] <JEEB> :D [22:33:56 CEST] <alexpigment> is llogan the one keeping us from ATSC 3.0? [22:34:00 CEST] <thebombzen> alexpigment: but you have to consider the storage bottleneck [22:34:05 CEST] <pzy> yes alex [22:34:09 CEST] <thebombzen> compression actually can improve speed [22:34:11 CEST] <alexpigment> damn you llogan ;) [22:34:15 CEST] <thebombzen> this is why Linux Initcpios are compressed [22:34:22 CEST] <JEEB> thebombzen: please. you're preaching to the pan [22:34:28 CEST] <thebombzen> ah okay [22:34:36 CEST] <alexpigment> thebombzen: perhaps, but people are often dealing with RAIDed PCI-E SSDs [22:35:02 CEST] <thebombzen> you can't say "they have massive amounts of storage" and then say "it's on an SSD" [22:35:08 CEST] <alexpigment> i just did [22:35:10 CEST] <thebombzen> massive storage is done via cheap HDDs [22:35:15 CEST] <thebombzen> that's how you get massive amounts of storage space [22:35:21 CEST] <thebombzen> cause HDDs are cheap and big [22:35:22 CEST] <JEEB> well whatever the storage is, usually something crazy expensive and large [22:35:31 CEST] <pzy> I guess NAB this year will have lots of ATSC 3.0 stuff [22:35:31 CEST] <JEEB> and maybe fast [22:35:36 CEST] <alexpigment> like i said, the people who deal with UHD lossless and intermediate files regularly have the money do have massive amounts of storage on *RAIDED* SSDs [22:35:37 CEST] <JEEB> pzy: MMTP [22:35:37 CEST] <kepstin> yeah, they spend a ridiculous amount on large fast ssds in raid just to workaround the fact they're using raw video or giant intra codecs [22:36:00 CEST] <llogan> $3500 USD for an analyzer. that's just for the "core". $4000 more for the additional options, "stream, transport, quality". [22:36:04 CEST] <alexpigment> yes, and the budget is there, so they give zero shits about optimizing it [22:36:04 CEST] <pzy> neat JEEB [22:36:13 CEST] <thebombzen> but seriously what advantage does rawvideo have over something like huffyuv or ffvhuff [22:36:13 CEST] <JEEB> no it is not [22:36:15 CEST] <thebombzen> or even just png [22:36:19 CEST] <thebombzen> or Exr [22:36:20 CEST] <thebombzen> or Tiff [22:36:37 CEST] <JEEB> it's simple and the ENTERPRISE SOLUTIONS support it [22:36:41 CEST] <JEEB> like, uh [22:36:48 CEST] <alexpigment> well, i don't think many people work in actual raw these days to my knowledge, but i don't work for a major movie studio, so i could be wrong ;) [22:36:49 CEST] <thebombzen> EXR is literally entroprise [22:36:57 CEST] <JEEB> why the fuck are you still going on about this, I think you're seeing where we're going with this [22:37:04 CEST] <thebombzen> mostly @alexpigment [22:37:12 CEST] <thebombzen> alex is the only one not agreeing with me [22:37:20 CEST] <thebombzen> because it appears the answer to "why do they do that it doesn't make sense" is "It just doesn't make any sense" [22:37:20 CEST] <alexpigment> i'm not disagreeing with your point [22:37:31 CEST] <alexpigment> you asked a question above that i gave you the answer to ;) [22:37:42 CEST] <JEEB> no, he is. he is just saying that what they're doing to have it work [22:38:02 CEST] <alexpigment> like do i agree that it could be optimized? OF COURSE [22:38:10 CEST] <alexpigment> do the studios care? NO [22:38:13 CEST] <JEEB> yup [22:38:18 CEST] <JEEB> they have their solution and it works for them [22:38:23 CEST] <furq> do i have a shift key? YES [22:38:25 CEST] <alexpigment> they have a deeply-seeded solution [22:38:32 CEST] <alexpigment> and they're willing to throw money at it [22:38:56 CEST] <alexpigment> furq: you should get that key checked. the whole first part of your statement was de-emphasized [22:40:31 CEST] <llogan> ...then they want you to buy their muxer for $7000. [22:48:05 CEST] <SpeakerToMeat> Ok, sorry I tried searchign everywhere before comming to ask but I can't bloody find it... what was the way to get a list of all of an enconder's possible options? [22:49:19 CEST] <alexpigment> ffmpeg -h encoder=[encoder name] [22:49:31 CEST] <SpeakerToMeat> Thanks [22:49:34 CEST] <kepstin> SpeakerToMeat: not in general, since there's a lot of "generic" options in the ffmpeg core that may or may not be used by a given codec [22:49:34 CEST] <alexpigment> np [22:49:56 CEST] <SpeakerToMeat> kepstin: Eh I want stuff like profiles supported and pix formats for an encoder [22:50:03 CEST] <kepstin> that help thing only shows options which are specific to that encoder, but doesn't include the generic options [22:50:24 CEST] <kepstin> if it has the info you want, then great. I know the pix_fmts are there :) [22:50:43 CEST] <alexpigment> well, there's always ffmpeg -h full [22:50:47 CEST] <alexpigment> but that's a bit overkill ;) [22:51:12 CEST] <SpeakerToMeat> Aaaaand, I'm toast... [22:51:42 CEST] <SpeakerToMeat> There's no dnxhd profile that supports 30fps. [22:52:05 CEST] <alexpigment> i'd have to look at my notes, but you might be right [22:52:18 CEST] <SpeakerToMeat> I maybe should do a constant frame count reinterpret to 30000/1001 [22:52:39 CEST] <kepstin> SpeakerToMeat: you could do 2:2 pulldown and store in i60 :/ [22:53:27 CEST] <SpeakerToMeat> kepstin: I don't see the 60 either, but 60000/1001 [22:53:33 CEST] <kepstin> hmm, you're right [22:53:41 CEST] <kepstin> where did you get an exactly 30fps source anyways? [22:53:55 CEST] <alexpigment> there are definitely 30fps DNxHD profiles in the spec [22:53:57 CEST] <SpeakerToMeat> what was the option to reinterpret Xfps as Yfps with no frame blending? that is, constant frame count.... :/ [22:54:14 CEST] <SpeakerToMeat> kepstin: Cheap chinese GoPro copy. [22:54:32 CEST] <kepstin> SpeakerToMeat: using '-r' as an output option, equivalently the 'fps' video filter [22:54:33 CEST] <SpeakerToMeat> kepstin: I'm trying to massage it from H264 to something Resolve free will read [22:54:45 CEST] <kepstin> oh, reinterpret [22:54:54 CEST] <SpeakerToMeat> kepstin: that'd be -r 30000/1001 right? [22:54:58 CEST] <kepstin> (i.e. slow down the video by 1/1.001) [22:55:20 CEST] <kepstin> if you mean reinterpret, then use -r 30000/1001 as an input option (before the -i) [22:55:21 CEST] <SpeakerToMeat> Yeah reinterpret, I want static frame count, not static duration [22:55:30 CEST] <SpeakerToMeat> ok [22:55:35 CEST] <SpeakerToMeat> Lets see [22:56:29 CEST] <kepstin> nobody'll notice a speed change of that magnitude, it's probably a smaller difference than the inaccuracy on your camera in the first place :) [22:56:41 CEST] <kepstin> although if you have audio you might have to resample it to match :/ [22:57:01 CEST] <SpeakerToMeat> Yuppers and it's better quality than trying to do a frame blending, etc [22:57:36 CEST] <SpeakerToMeat> Eh I have external recorded audio from console, I'll sync and replace audio, and slow it down 0.1% [22:57:52 CEST] <SpeakerToMeat> Ok it's not liking something... let's see [22:58:23 CEST] <kepstin> heh, if you have audio recorded from a different source, you'd probably have to do some extra work to sync it up anyways [22:58:40 CEST] <thebombzen> yea [22:59:09 CEST] <thebombzen> also note you can recreate the timestamps with -vf setpts=N/TB/30 [22:59:37 CEST] <thebombzen> if you want to do it with a filter that is [23:00:01 CEST] <SpeakerToMeat> I had to match one of the profiles bitrates as well this was crazy [23:00:16 CEST] <SpeakerToMeat> thebombzen: That was the style I remembered [23:00:27 CEST] <SpeakerToMeat> thebombzen: Would -r before -i be equivalent? [23:00:53 CEST] <SpeakerToMeat> Aaaand DNxHD is 10 times bigger... sigh [23:00:58 CEST] <kepstin> SpeakerToMeat: using -r before -i is a bit different, but the same basic effect here [23:01:16 CEST] <thebombzen> in this case they'd do the same thing but in different ways [23:01:18 CEST] <SpeakerToMeat> kepstin: Different how? [23:01:37 CEST] <thebombzen> so using -r before -i tricks the demuxer into treating the input as CFR [23:01:49 CEST] <thebombzen> using -vf setpts=N/TB/<framerate> is a filter [23:01:59 CEST] <kepstin> SpeakerToMeat: the -r option changes the timestamps sort of in-between the demuxer and decoder stages, I think? it can work when stream-copying [23:02:10 CEST] <SpeakerToMeat> Ok [23:02:10 CEST] <thebombzen> using the filter it only works on decoded frames because libavfilter doesn't work on encoded frames [23:02:11 CEST] <kepstin> while the filters only work when re-encoding, but are a lot more flexible [23:02:25 CEST] <thebombzen> it's a bit like concat demuxer versus the concat filter [23:02:38 CEST] <thebombzen> the concat filter is less applicable but more flexible [23:02:59 CEST] <SpeakerToMeat> So basically -r before -i is telling the demuxer to discard the timing data and use a supplied constant framerate [23:03:06 CEST] <kepstin> that reminds me, i really need to finish cleaning up my patch to make concat filter work with different framerate videos [23:03:09 CEST] <kepstin> SpeakerToMeat: exactly. [23:04:54 CEST] <thebombzen> SpeakerToMeat: yes [23:05:20 CEST] <thebombzen> kepstin: would that just make the output VFR? [23:05:30 CEST] <kepstin> thebombzen: yes [23:05:45 CEST] <thebombzen> how would you deal with timestamps that don't start at zero [23:05:48 CEST] <petecouture> I have ffmpeg running in node via a wrapper. The script takes a mp4 file located on S3 and transcodes it to an HLS output with multiple bitrates. With no changes to the code all of a sudden I'm getting this error while running. Encoder ERROR ffmpeg exited with code 1: Conversion failed! [23:05:55 CEST] <petecouture> Should I recompile ffmpeg? [23:06:11 CEST] <kepstin> thebombzen: the concat filter code already handles it, it just needs a fix to mark the output as vfr so it doesn't trigger some frame dropping code. [23:06:19 CEST] <thebombzen> oh okay [23:06:49 CEST] <thebombzen> so you already *can* do it, but it effectively just adds a -vf fps afterward [23:07:29 CEST] <thebombzen> what happens if you try weird things like ffmpeg -ss 10 -copyts -i input1 -ss 5 -copyts -i input2 -lavfi concat=n=2? [23:07:43 CEST] <thebombzen> does it just ignore the timestamps [23:07:50 CEST] <kepstin> thebombzen: currently the output video will be the same "fps" as the first video, and it will drop any frames which don't fit that [23:08:07 CEST] <thebombzen> oh okay [23:08:33 CEST] <kepstin> thebombzen: -copyts simply means that the frames entering the filterchain don't have any extra cleanups applied, so copyts doesn't really do anything special here... [23:08:57 CEST] <thebombzen> yea but I mean how does the concat filter handle input that doesn't start at zero? [23:09:03 CEST] <kepstin> (admittedly, one of the cleanups is setting the pts to start at 0, but you could do that with a setpts filter in the filter chain too) [23:09:08 CEST] <thebombzen> or does the concat filter ignore the its offset? [23:09:30 CEST] <kepstin> i'm not sure, but it seems to work ok - I imagine it does the equivalent of "setpts=PTS-STARTPTS" on each of its inputs [23:09:56 CEST] <thebombzen> ah okay, it remaps to zero [23:09:58 CEST] <petecouture> Opps ignore my last question, I did update the script and broke it. [23:10:07 CEST] <thebombzen> petecouture: clearly [23:10:13 CEST] <petecouture> lawlz [23:10:20 CEST] <thebombzen> if you change the script and not ffmpeg and suddenly the script doesn't work [23:10:33 CEST] <thebombzen> it's really not a surprise that you broke the script [23:10:42 CEST] <thebombzen> and that ffmpeg didn't magically break and yet remain identical to how it had been [23:11:39 CEST] <petecouture> https://imgur.com/gallery/uQoHgUV [23:31:55 CEST] <thebombzen> why is planar rgb data in the format gbrp [23:31:59 CEST] <thebombzen> like why GBR [23:32:40 CEST] <thebombzen> I get that YUV is probably closest to GBR, but GBR seems really nonstandard for rgb data [23:56:40 CEST] <petecouture> Running script installed on Centos. The program runs for about 60% of the way and then I get a 'killed' status and SIGKILL was thrown. The thing is same script occasionally works usually right after a reboot. I'm running it using loglevel 48 to see why it's being killed but nothing is shown only 'killed'. Is there a way to know why it's occurring? The same script runs fine locally on my macbook pro. [23:57:15 CEST] <furq> oom killer? [23:57:38 CEST] <petecouture> That's what I assumed but is there a way to know that's the case? [23:57:43 CEST] <thebombzen> well SIGKILL is thrown by someone else [23:57:52 CEST] <thebombzen> a process doesn't kill itself with SIGKILL [23:58:04 CEST] <thebombzen> (I mean it technically could, but nobody does that) [23:58:20 CEST] <thebombzen> so you should try to figure out if something else iskilling it [23:58:32 CEST] <petecouture> This originally was in a node wrapper. which is where I got the SIGKILL notice. WHen I run it via the command line raw I just get 'killed' [23:58:34 CEST] <thebombzen> perhaps it's some SELinux bullshit [23:58:42 CEST] <thebombzen> well the command line says "Killed." [23:58:50 CEST] <thebombzen> if it receives SIGKILL [23:58:52 CEST] <thebombzen> so same thing [23:59:14 CEST] <thebombzen> Centos might have some sort of failsafe to prevent runaway processes [23:59:22 CEST] <petecouture> hmmm [23:59:23 CEST] <thebombzen> perhaps some SeLinux thing [23:59:43 CEST] <thebombzen> Centos is an Enterprise distro [23:59:44 CEST] <furq> the oom killer will log somewhere [23:59:57 CEST] <furq> either /var/log/messages, /var/log/syslog or /var/log/kern.log depending on distro [00:00:00 CEST] --- Thu Mar 30 2017

1 0

ffmpeg-devel.log.20170328
by burek 29 Mar '17

29 Mar '17

[00:11:16 CEST] <cone-883> ffmpeg 03Aaron Colwell 07master:b4189590a591: movenc: Add support for writing st3d and sv3d boxes. [00:11:17 CEST] <cone-883> ffmpeg 03James Almer 07master:a715e5a276c0: avformat/movenc: restrict st3d and sv3d mov atoms to MODE_MP4 [00:11:18 CEST] <cone-883> ffmpeg 03James Almer 07master:86dee47e397f: avformat/movenc: allow st3d and sv3d mov atoms to be written in strict unofficial mode [00:14:05 CEST] <cone-883> ffmpeg 03Michael Niedermayer 07master:bcd7153df382: ffprobe: Support adding av_log output to frames [00:14:06 CEST] <cone-883> ffmpeg 03Dave Rice 07master:52d9442a557e: ffprobe.xsd: add frame log data [00:14:07 CEST] <cone-883> ffmpeg 03Dave Rice 07master:3e0474ff3970: doc/ffprobe: add -show_log option [00:16:36 CEST] <wm4> wow did this av_log patch really make it... [00:16:53 CEST] <wm4> so wonderfully hacky and broken [00:19:34 CEST] <jamrial> well, it's almost a year old and nobody said anything in almost four months aside from saste approving it... [00:21:38 CEST] <iive> well, there is better solution, but it would make merges even bigger nightmare [00:23:33 CEST] <jamrial> contained within ffprobe? because afaik avprobe merges are more often than not noops, so it wouldn't be an issue [00:24:09 CEST] <ubitux> iive: ffprobe completely diverges from avprobe [00:24:24 CEST] <ubitux> the only common point is which fields we decide to print [00:24:25 CEST] <iive> i'm talking about error tracking in general [00:25:13 CEST] <iive> if it's another av_log, then sorry for intrusion. [00:26:07 CEST] <durandal_1707> so you have no idea about this patch? [00:36:47 CEST] <nevcairiel> a better overall logging framework might be neat, but alas such things are complicated and very intrusive [00:46:40 CEST] <PaoloP> jamrial: I added the files and did the commit. Should these operation appear in the irc channel? I see for example: "<cone-883> ffmpeg Michael Niedermayer master:bcd7153df382: ffprobe: Support adding av_log output to frames" [00:47:20 CEST] <jamrial> that has nothing to do with your git commands [00:49:58 CEST] <PaoloP> what are them? [00:53:03 CEST] <jamrial> a log of commits pushed to the main public repository [03:20:16 CEST] <Shiz> '/w 32 [04:39:39 CEST] <cone-433> ffmpeg 03James Almer 07master:b613245c9715: ffprobe: free log buffer's parent_name during cleanup [06:15:57 CEST] <cone-433> ffmpeg 03James Almer 07master:3fe7bb2bcf19: avcodec/extract_extradata_bsf: add missing break statement to extract_extradata_vc1 [06:24:56 CEST] <AaronL> Hi all, not sure if anyone is here right now, but I submitted a patch to the ffmpeg-devel e-mail list a couple of days ago [06:25:28 CEST] <AaronL> Other than someone responding, indicating that he thought this had already been dealt with (it hadn't, and I responded as such), I haven't seen anything else [06:25:47 CEST] <AaronL> do I need to get a small patch like this signed off on by someone else before pushing it to the repository? [06:25:57 CEST] <AaronL> I've never contributed to ffmpeg in the past [06:26:33 CEST] <AaronL> It's this one: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209129.html [06:57:28 CEST] <Compn> AaronL : hello, just saying its late and i dont think anyone is online right now [06:57:35 CEST] <Compn> but we do read this channel later, when we wake up :) [06:58:32 CEST] <Compn> since your patch changes h264 decoding behavior, it will have to be extensively tested against all of our samples [06:59:00 CEST] <Compn> AaronL: i understand you ran the fate tests, but those are only a handful of samples, while we have many TB of samples that we sometimes test against [06:59:29 CEST] <Compn> AaronL : the usual turnaround time for patches is 2 weeks for a review [06:59:37 CEST] <Compn> 2 weeks max... [06:59:58 CEST] <Compn> you posted the patch 2 days ago... have patience :) [07:00:08 CEST] <Compn> most of us here are volunteers and are not paid to do this work [07:02:33 CEST] <Compn> er, whoops i misread the patch re h264 [07:02:46 CEST] <Compn> was going by description not patch content :D [07:02:56 CEST] <Compn> i think michaelni maintains ffmpeg.c [07:03:06 CEST] <Compn> AaronL : but yes , 2 weeks... [07:04:15 CEST] <Compn> if you have other questions, please ask [07:04:20 CEST] Action: Compn going sleepy town now [07:04:32 CEST] <Compn> and feel free to stay here on irc. [10:53:15 CEST] <cone-792> ffmpeg 03Steven Liu 07master:c0628919b8c5: avformat/flvdec: check FLVHeader PreviousTagSize0 [10:55:34 CEST] <ubitux> that cleanup_step thing is... original [10:58:54 CEST] <ubitux> jkqxz: that AVHWDeviceType none change breaks ABI, doesn't it? [10:58:58 CEST] <ubitux> shouldn't it be -1? [10:59:23 CEST] <nevcairiel> he really wants it to be 0 so he can be lazy with explicit init [10:59:36 CEST] <nevcairiel> and libav just major-bumped [11:02:35 CEST] <wm4> yes Libav is in a phase where they can do arbitrary ABI changes [11:02:49 CEST] <wm4> so if you can think of anything, now is the time (well, and again when FFmpeg does the same) [11:08:32 CEST] <ubitux> ok [11:12:58 CEST] <jkqxz> I wonder how many things would break if we made AV_PIX_FMT_NONE zero, because that would be a good change for everyone (except horrible existing code using YUV420P implicitly). [11:13:26 CEST] <nevcairiel> Personally I think explicit init is always a good thing [11:25:18 CEST] <wm4> I think implicit init to sane or invalid values is always a good thing [11:25:31 CEST] <wm4> while init to some random but valid value (yuv420p) is pretty bad [11:40:10 CEST] <cone-792> ffmpeg 03Clément BSsch 07master:c3706bc25574: doc/examples/filtering_*: switch to codecpar [11:42:02 CEST] <cone-792> ffmpeg 03Matthieu Bouron 07master:7e3e0f87e6e9: doc/examples/muxing: re-indent block [12:50:24 CEST] <mateo`> dear ubitux, would you kindly review my extract_mvs patch ? [12:50:33 CEST] <ubitux> yes my love [13:12:33 CEST] <mateo`> thanks :) [14:32:53 CEST] <mateo`> transcoding.c is funny [14:36:41 CEST] <durandal_1707> what could be cause of ratecontrol error, when qscale is too big? [14:42:00 CEST] <atomnuker> durandal_1707: couldn't you scale back the qscale when sending it off to the rc system? [14:43:54 CEST] <durandal_1707> how? [14:45:02 CEST] <durandal_1707> this is dnxhr and it have some strange rc code [14:49:19 CEST] <atomnuker> just set it before the weird stuff and restore it after [15:01:15 CEST] <BtbN> Hm, I wonder what transcoding chip is on the 1080 Ti [15:41:06 CEST] <ubitux> mmh [15:41:21 CEST] <ubitux> how is ffmpeg able to read only specific streams? [15:41:54 CEST] <ubitux> it seems it's able to not even get given packet for given streams [15:42:13 CEST] <ubitux> which makes it much faster than a simple loop that filters out packet [15:43:00 CEST] <ubitux> maybe a discard mechanism [15:43:02 CEST] <ubitux> ? [15:44:50 CEST] <BtbN> I'd guess it just discards any packets coming out of the demuxer that don't match the requested streams? [15:45:15 CEST] <ubitux> omfg [15:45:32 CEST] <ubitux> you can speeds it up by setting st->discard = AVDISCARD_ALL [15:50:14 CEST] <ubitux> TIL... [15:53:37 CEST] <nevcairiel> its good to learn things [15:53:48 CEST] <ubitux> it really makes a difference, that's nice [15:53:51 CEST] <bf_> Hey guys, any of you have some time for freelancing this afternoon? I need to pick someones brain for half an hour but it seems thilo and thomas are not available. [15:55:44 CEST] <bf_> I'm trying to build a node.js RTMP server which is fed by OBS and spits out HLS or Dash, having problem to assemble the x264 frames coming through RTMP [16:00:31 CEST] <RiCON> bf_: you could try looking through https://github.com/sergey-dryabzhinsky/nginx-rtmp-module [16:01:23 CEST] <bf_> RiCON: thanks, I have already tried it out. Hit a lot of bugs unfortunately. discussing in #ffmpeg already [16:02:47 CEST] <jamrial> ubitux: i sent a port of examples/transcoding to the ml months ago, but it didn't get reviewed and i moved to something else [16:03:09 CEST] <mateo`> jamrial: :'( [16:03:23 CEST] <jamrial> i guess it still works, but maybe you or matthieu want to look at it [16:03:26 CEST] <jamrial> so we can push it [16:03:27 CEST] <mateo`> jamrial: I will review it now [16:04:31 CEST] <mateo`> jamrial: do you have the patch somewhere ? [16:05:36 CEST] <jamrial> mateo`: one sec [16:06:38 CEST] <jamrial> mateo`, ubitux: https://github.com/jamrial/FFmpeg/commits/examples [16:08:27 CEST] <mateo`> thanks [16:11:10 CEST] <PaoloP> Hello. Please have a look at the new API usage snippet I proposed. http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209256.html . I can provide other ones, which are useful for libav users, if it is accepted (I have to re-organize all the code and it requires much time) [16:14:09 CEST] <PaoloP> I made many snippets during these last months, and they all separate all the tasks in a strict procedural way, so that the reader can easily understand the sequence grabbing--> resampling ---> encoding ---> muxing ---> streaming [16:29:30 CEST] <PaoloP> wm4: what's wrong in the cleanup_step variable? [16:29:50 CEST] <wm4> it's fragile and hard to read [16:30:14 CEST] <wm4> you could replace error handling with a call to abort() (it's an example after all), or do proper C style error handling [16:30:33 CEST] <PaoloP> wm4: but in the other examples is even more fragile. I followed the style of the other examples and tried to improve it [16:31:08 CEST] <PaoloP> I mean: all the other examples do use the cleanup label [16:31:13 CEST] <PaoloP> with a goto jump [16:32:45 CEST] <PaoloP> (they are really messy, though) [16:33:14 CEST] <wm4> your approach is messier [16:33:35 CEST] <wm4> if you need to add a new error case in-between, you need to edit and revisit all the other cases [16:33:55 CEST] <wm4> and it's not easy to see at all which cleanup corresponds to which code [16:34:40 CEST] <PaoloP> wm4: I don't agree it's messier. Look at transcode_aac.c . the error handling is partially done in the if statement and finalized in the cleanup block [16:35:16 CEST] <PaoloP> you are right when you say that "[16:33] <wm4> if you need to add a new error case in-between, you need to edit and revisit all the other cases" [16:35:29 CEST] <PaoloP> but it's not messier than the other examples [16:35:41 CEST] <ubitux> it is [16:35:48 CEST] <ubitux> but it's also inconsistent [16:35:55 CEST] <ubitux> (with the rest of the codebase) [16:36:25 CEST] <ubitux> please copy the style, we want consistency within the project [16:36:39 CEST] <ubitux> s/but/and/ [16:37:00 CEST] <mateo`> jamrial: the patch looks good to me, nit: can you split the assignment from the if test (https://github.com/jamrial/FFmpeg/commit/6002f2d2a01656ad4290df7e3ae5b02225…) ? [16:37:13 CEST] <ubitux> PaoloP: typically in the same spirit you can drop the double line breaks [16:37:44 CEST] <PaoloP> ubitux: which rules do I have to change? [16:37:52 CEST] <jamrial> mateo`: sure [16:38:00 CEST] <PaoloP> (in order to have consistency within the project) [16:38:19 CEST] <ubitux> you don't change the rule, you follow it [16:38:32 CEST] <ubitux> so you drop this cleanup step thing and have a common error path [16:38:50 CEST] <PaoloP> ubitux: ok [16:38:54 CEST] <ubitux> thanks [16:39:17 CEST] <PaoloP> ubitux: and what else? it would be useful if you tell me a short list of things I should change [16:39:36 CEST] <ubitux> the double line breaks [16:39:44 CEST] <PaoloP> wm4: said to declare variables before statements. Is it necessary ? [16:39:55 CEST] <ubitux> look at the rest of the code and compare [16:40:01 CEST] <ubitux> yes it is [16:40:10 CEST] <PaoloP> ok [16:40:15 CEST] <ubitux> btw iirc you have tabs in the Makefile [16:40:51 CEST] <ubitux> btw, you can use av_err2str() instead of that get_error_text [16:40:58 CEST] <PaoloP> ubitux: ok again [16:41:09 CEST] <PaoloP> (I copied get_error_text from another example) [16:41:21 CEST] <wm4> ubitux: that's weird... it requires the examples to be in C99, which doesn't require decls-before-statements [16:41:34 CEST] <PaoloP> wm4: I agree [16:42:01 CEST] <ubitux> wm4: it's all about consistency... [16:42:13 CEST] <ubitux> yeah that transcode_aac shouldn't be like that [16:42:17 CEST] <mateo`> wm4: are you ok with the remuxing example patch (with the avformat_transfer_internal_stream_timing_info call removed) ? [16:42:20 CEST] <ubitux> i think that's because libav doesn't have av_err2str [16:42:28 CEST] <ubitux> and it comes from there [16:42:35 CEST] <wm4> mateo`: yeah, I have no further comments I think [16:43:05 CEST] <PaoloP> ubitux: IMHO, with the declaration after statements, the user can pick portions of the code and adapt them to his code in an easier way [16:43:11 CEST] <ubitux> PaoloP: you don't need to cast malloc, it's not C++ [16:43:22 CEST] <mateo`> wm4: thanks for the review [16:43:28 CEST] <mateo`> i'll push both patches (remuxing / extract_mvs) in a couple of minutes [16:43:31 CEST] <ubitux> PaoloP: i know, but it's not the current convention we're following [16:43:32 CEST] <PaoloP> ubitux: :-) yes again [16:43:40 CEST] <PaoloP> ubitux: ok, I'll follow the rule [16:44:07 CEST] <ubitux> you have to fix the coding style btw, like "if(" is missing a space [16:44:25 CEST] <ubitux> but i don't want to explicit that style, look at the rest of the code and copy it [16:44:48 CEST] <PaoloP> ubitux: just fixed [16:44:50 CEST] <ubitux> i'll make a proper review on the ml at the next iteration [16:45:30 CEST] <ubitux> PaoloP: squash your patches too [16:45:58 CEST] <PaoloP> ubitux: <ubitux> PaoloP: squash your patches too <--- what does it mean? [16:46:05 CEST] <ubitux> make one single patch [16:46:13 CEST] <PaoloP> ubitux: yes, wm4 told me that [16:46:29 CEST] <ubitux> sorry, missed it [16:46:44 CEST] <PaoloP> ubitux: he told me that in pvt msg, it's not your fault [16:48:17 CEST] <PaoloP> ubitux: the only thing I don't understand well is how to change the cleanup function. [16:38] <ubitux> so you drop this cleanup step thing and have a common error path ... which api example could I use as a model? [16:48:44 CEST] <ubitux> btw, you'll have to update the configure to add the example here too (there are two ways of building examples; as standalone with the Makefile which uses the system libraries, and with `make examples` within the FFmpeg build system) [16:48:53 CEST] <ubitux> you'll also have to update a .gitignore iirc [16:49:04 CEST] <ubitux> PaoloP: look at other examples [16:49:31 CEST] <ubitux> you generally just have a "end" label with a bunch of free [16:49:41 CEST] <PaoloP> ubitux: do you mean that I have to keep the goto? [16:49:47 CEST] <ubitux> yes, but only one [16:50:18 CEST] <ubitux> look at doc/examples/filtering_audio.c for example [16:50:22 CEST] <PaoloP> ok [16:50:48 CEST] <ubitux> you don't need to use exit(), but the general flow should be the same [16:51:14 CEST] <PaoloP> ok [16:52:01 CEST] <PaoloP> ubitux: about the double line break, I don't understand that as well [16:52:23 CEST] <PaoloP> do you mean \n\n in the code? [16:52:27 CEST] <ubitux> yes [16:52:31 CEST] <ubitux> actually \n\n\n [16:53:09 CEST] <PaoloP> how do I have to replace it? [16:53:09 CEST] <cone-792> ffmpeg 03Matthieu Bouron 07master:4a946aca7cf3: doc/examples/remuxing: switch to codecpar [16:53:09 CEST] <cone-792> ffmpeg 03Matthieu Bouron 07master:64b553998567: doc/examples/extract_mvs: switch to codecpar [16:53:18 CEST] <PaoloP> only one? [16:53:26 CEST] <ubitux> no, many [16:53:37 CEST] <ubitux> just keep one empty line between blocks [16:53:47 CEST] <PaoloP> I mean: I have to replace each double/multi line with only one line? [16:54:24 CEST] <PaoloP> I see, I used multi line in order to separate more clearly the blocks, but I'll follow the rule you said [16:55:06 CEST] <ubitux> it's not the "the rule i said", it's how it's written in the rest of the codebase [16:55:11 CEST] <ubitux> i'm not making them up as a whim [16:56:26 CEST] <PaoloP> Also: I mead comments with "//" instead of "/*" (I prefere the first one); I should replace them, right? [16:56:36 CEST] <PaoloP> (s/mead/made) [16:59:25 CEST] <ubitux> yeah, we usually use /* */ for the multiline ones [16:59:51 CEST] <ubitux> for single line ones i don't think that's important, i don't remember seeing a consistent convention on thjat [17:03:40 CEST] <PaoloP> ubitux, wm4: ok, I'm changing all these things right now. If you have other suggestions, just tell them here and I'll follow them [17:22:09 CEST] <ubitux> can i have reviews on the av_4cc2str() thing? i'll need to move on with the patchset [17:22:22 CEST] <ubitux> it's a dependency for the pending djgpp patchset [17:23:37 CEST] <cone-792> ffmpeg 03Ronald S. Bultje 07master:5ba8c3a0ed0e: dirac: make initialization of arithmetic coder tables threadsafe. [17:25:32 CEST] <ubitux> the whole thing is at https://github.com/ubitux/FFmpeg/compare/djgpp [17:27:06 CEST] <wm4> ubitux: well there were multiple comments on 4cc2str? address them in some form, then push? [17:27:32 CEST] <BBB> +1 that [17:27:51 CEST] <cone-792> ffmpeg 03James Almer 07master:3b80f73b186d: doc/examples/transcoding: convert to codecpar [17:28:02 CEST] <ubitux> wm4: i think i addressed all of them [17:28:16 CEST] <mateo`> jamrial: thanks :) [17:28:19 CEST] <BBB> is anyone interested in reviewing hevc: initialize no_rasl_output_flag in hevc_frame_start().? its fairly trivial and I believe it will remove some tsan warnigns for hevc [17:29:16 CEST] <PaoloP> ubitux: wm4 and others, are the cleanup functions avcodec_close(), avcodec_free_context(), av_frame_free() etc. safe if I pass a null pointer to them ? [17:29:32 CEST] <PaoloP> (So I can remove the "cleanup_step" variable [17:29:36 CEST] <ubitux> jamrial: are you going to push these atomic commits? i'd like to see if that helps wrt the tsan fate instance [17:29:38 CEST] <PaoloP> ) [17:29:48 CEST] <jamrial> ubitux: no, they are not correct as is [17:29:50 CEST] <ubitux> PaoloP: most if not all are [17:29:55 CEST] <ubitux> jamrial: ah? damn [17:30:09 CEST] <PaoloP> ubitux: this should be added to the documentation!!!!! [17:30:15 CEST] <ubitux> PaoloP: check the code [17:30:21 CEST] <PaoloP> ubitux: ok [17:30:30 CEST] <ubitux> send a patch for the doxy if not mentioned [17:30:34 CEST] <PaoloP> ubitux: ok [17:32:06 CEST] <jamrial> ubitux: only one was and i already pushed it. the rest use compare exchange and require more thought to them compared to the old implementation [17:34:05 CEST] <ubitux> mmh [17:34:07 CEST] <ubitux> ok [17:42:31 CEST] <PaoloP> swr_free doesn't seem safe with a null pointer: https://www.ffmpeg.org/doxygen/3.2/swresample_8c_source.html#l00140 (it calls av_freep() regardless of the NULL value). What to do? Is it necessary to patch it? [17:43:39 CEST] <BtbN> good thing av_freep is safe to call with a NULL Value. [17:43:46 CEST] <wm4> BtbN: nope [17:44:02 CEST] <BtbN> what? I have seen that happen in quite a few places [17:44:04 CEST] <wm4> the pointer you pass to it can be NULL [17:44:11 CEST] <wm4> but av_freep(NULL) crashes I think [17:44:24 CEST] <nevcairiel> av_freep(NULL) is not s afe, p = NULL; av_freep(&p) is safe [17:44:45 CEST] <wm4> I wonder if that's intended [17:44:59 CEST] <nevcairiel> the worse code in swr_free is that it dereferences ss right in the first line [17:45:04 CEST] <BtbN> It should be easy to fix if that's really the case, and prevent a few possible accidents [17:45:58 CEST] <nevcairiel> the way av_freep is commonly called, you wouldnt often run into this [17:46:06 CEST] <nevcairiel> since its typical to call it like av_freep(&mypointer); [17:46:43 CEST] <wm4> swr_free would better be named swr_freep (because that are its semantics) [17:47:11 CEST] <PaoloP> so, what to do? is it better to patch it or to do if(ptr != NULL) swr_free() ? [17:47:38 CEST] <BtbN> how would it even happen in normal usage for the ptr you pass to it to be NULL? [17:47:44 CEST] <nevcairiel> since its essentially a freep mechanic, are you sure you are not using it wrong in the first place [17:48:18 CEST] <PaoloP> BtbN: in the cleanup block of the code [17:48:35 CEST] <BtbN> you usually do something like swr_free(&ptr); [17:48:44 CEST] <BtbN> so there is normally no way for that to end up as NULL [17:48:57 CEST] <nevcairiel> calling swr_free(&audio_convert_context); will never error [17:48:58 CEST] <PaoloP> BtbN: right [17:49:30 CEST] <nevcairiel> since &var is never NULL [17:49:36 CEST] <nevcairiel> var might be NULL, but thats ok [17:51:38 CEST] <kkanungo17> where can I get the documentation for the native vorbis encoder and the AAC psychoacoustic system? [17:52:07 CEST] <nevcairiel> internal components like that often dont have specific documentation - read the code [17:52:14 CEST] <atomnuker> kkanungo17: sorry I didn't respond, been busy [17:52:19 CEST] <atomnuker> there isn't any like nevcairiel said [17:52:26 CEST] <atomnuker> you have to read the code [17:53:07 CEST] <ubitux> i think found the race in libavfilter [17:53:12 CEST] <kkanungo17> I've been busy too, so I delayed too, sorry [18:16:32 CEST] <PaoloP> I have adts_container_buffer = av_malloc(adts_container_buffer_size) in the main() and I put av_free(adts_container_buffer) in the "end:" cleanup block. How can I assure safety for that? should I check if adts_container_buffer is not null before calling av_free() ? [18:18:02 CEST] <nevcairiel> av_free is NULL safe [18:18:13 CEST] <PaoloP> thanks nevcairiel [18:19:17 CEST] <nevcairiel> better would be using av_freep(&adts_...) though [18:19:41 CEST] <PaoloP> nevcairiel: ok [18:37:19 CEST] <PaoloP> Ok. I made all the modifications suggested by ubitux and wm4. Now I have to git add encode_raw_audio_file_to_aac.c and the Makefile. But how can I squash the two patches into one file? [19:14:12 CEST] <jamrial> ubitux, BBB: https://bugs.kde.org/show_bug.cgi?id=378068#c1 the workaround mentioned here seems to work [19:14:21 CEST] <BBB> cool [19:14:30 CEST] <BBB> see? my code is never buggy[tm] :D [19:17:05 CEST] <ubitux> jamrial: yeah i didn't update my instance yet [19:17:10 CEST] <ubitux> i will add that option [19:17:24 CEST] <ubitux> PaoloP: learn how to use git rebase (-i) [19:23:47 CEST] <PaoloP> ubitux: I created the patch with "git diff HEAD~2 > mypatch.txt (changed two files) . Here's the patch: http://paste.ubuntu.com/24268946/ is it in the correct format? If so I send it to the ML [19:24:21 CEST] <ubitux> no, we need a git formatted patch (with author, commit message and description, etc) [19:24:30 CEST] <wm4> no, it makes it harder to apply [19:24:38 CEST] <wm4> (which you probably don't want) [19:24:59 CEST] <ubitux> https://help.github.com/articles/about-git-rebase/ [19:24:59 CEST] <wm4> so use git rebase or whatever to turn it into 1 commit, then use git format-patch to produce a proper patch [19:25:08 CEST] <ubitux> git rebase -i HEAD~2 [19:25:17 CEST] <ubitux> then replace pick with fixup on the second one [19:25:41 CEST] <ubitux> i'm not going to make a more advanced git tutorial, check on the net [19:30:12 CEST] <ubitux> so, anyway, if we ignore the dirac, hevc, resize and lavfi race [19:30:14 CEST] <ubitux> what's left? [19:31:06 CEST] <atomnuker> BBB fixed the dirac race, didn't he [19:31:15 CEST] <BBB> I hope so [19:31:22 CEST] <BBB> at least that was the goal [19:31:35 CEST] <ubitux> yeah, i mentioned the one that are supposed to be fixed in pending patches [19:31:35 CEST] <BBB> did it work? [19:31:41 CEST] <ubitux> is it pushed? [19:31:44 CEST] <BBB> yes [19:31:47 CEST] <BBB> only that one [19:31:49 CEST] <ubitux> oh [19:31:50 CEST] <BBB> the rest had no review so far [19:32:02 CEST] <ubitux> i don't see dirac [19:32:07 CEST] <ubitux> so i guess it's good :) [19:32:10 CEST] <BBB> where? [19:32:15 CEST] <ubitux> on tsan report [19:32:20 CEST] <BBB> link? [19:32:27 CEST] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20170328161749&slot=x86_64-archlinux… [19:32:39 CEST] <ubitux> can i have a review on the lavfi one? should help reducing the noise [19:32:40 CEST] <BBB> yup, indeed [19:33:24 CEST] <wm4> I almost read that as "BBB fixed the horse race" [19:34:22 CEST] <BBB> ubitux: I think it looks good but Im not that great with lavfi internal/core [19:34:41 CEST] <ubitux> the threading is pretty much isolated in that file [19:34:51 CEST] <BBB> ok [19:34:59 CEST] <BBB> I have some ideas on how to fix the tsan reports on intra-only codecs [19:35:13 CEST] <BBB> they are basically harmless, but they can be silenced by not syncing stuff for intra-only codecs [19:35:29 CEST] <ubitux> the lavfi one is mostly harmless too [19:36:00 CEST] <ubitux> actually, likely completely harmless as the concurrent write is never read [19:36:27 CEST] <BBB> :) [19:37:01 CEST] <BBB> the remaining h264 ones are basically multi-slice header readers where we need to move to init stuff only in the first slice and check for identical data in next slices instead of rewrite already-copied values [19:37:06 CEST] <BtbN> why is it written in the first place then? [19:37:17 CEST] <BBB> BtbN: its things like width/height [19:37:22 CEST] <BBB> BtbN: its pretty important to write them [19:37:37 CEST] <BBB> imagine having AVFrame->width be unset ;) [19:37:38 CEST] <BtbN> can't that just be limited to one thread, or just moved out of them? [19:37:48 CEST] <BBB> its intraonly, why? [19:37:53 CEST] <BBB> every thread can have a different value [19:38:03 CEST] <BtbN> With slice threading? [19:38:05 CEST] <BBB> imagine ffmpeg -f image2 -c:v mjpeg ~/Photos/*.jpg [19:38:14 CEST] <BBB> no with frame threading [19:38:34 CEST] <BBB> I dont see anything wrong with size changes [19:38:41 CEST] <BBB> but theres no sense in syncing width/height between threads [19:39:00 CEST] <BBB> and we dont want to wait spinning thread2 until thread1 has set width and height (which thread2 ignores anyway, because intraonly) [19:39:15 CEST] <BBB> so syncing in those cases is useless and needs to be prevented [19:39:15 CEST] <BtbN> the threads should be writing the different width/height fields in their own Frame anyway. The width/height in the codec context might be more complex [19:39:18 CEST] <BBB> that silences the races [19:39:38 CEST] <atomnuker> how about using atomic writes for that? [19:39:42 CEST] <BBB> Im talking about syncing w/h *between* AVCodecContext in update_thread_context() in pthread_frame.c [19:40:04 CEST] <BBB> atomics is more like a plastering issue [19:40:11 CEST] <BBB> we shouldnt sync values that we ignore [19:41:04 CEST] <BBB> dont worry about it, Ive got a pretty good idea on solving it without ugly hack [19:41:17 CEST] <BBB> I just need some time to sit down and verify it does what I think it will dop [19:41:19 CEST] <BBB> -p [19:41:29 CEST] <BtbN> do they need to be written to at all? Or is preventing that ugly? [19:41:54 CEST] <wm4> I suppose in theory, opening the decoder could set the video width/height in simple decoders [19:42:09 CEST] <wm4> which would prevent us "syncing" them simply from AVFrame [19:53:08 CEST] <PaoloP> wm4: is this ok? http://paste.ubuntu.com/24269103/ [19:55:35 CEST] <PaoloP> (I executed: git add file1; git commit -m "comment1"; git add file2; git commit -m "comment2"; git rebase -i HEAD~2; git format-patch -1" ) [20:05:06 CEST] <BtbN> why didn't you add both files right away? [20:05:44 CEST] <PaoloP> BtbN: what do you mean with "right away"? (forgive my poor english) [20:05:53 CEST] <AaronL> Compn: see that you are back now, perhaps you'll see this :-) [20:06:04 CEST] <BBB> see pthread_frame: don't sync items between threads for intra-only codecs. for what I meant [20:06:22 CEST] <BBB> I didnt test it at all, but my assumption is that it will fix tsan for most intra-only decoders [20:06:26 CEST] <BtbN> well, if you did the git add before the second commit, you'd have just one commit right away, and wouldn't need to squash them into one using an interactive rebase. [20:06:48 CEST] <AaronL> Compn: I had read 3 days for small patches--the overall amount of changes in the patch I submitted are small, although it does represent a change in the behavior, so maybe it is considered a large patch [20:07:25 CEST] <PaoloP> BtbN: I see. I'll do that in the future. But is the current patch in the correct fmt? [20:08:06 CEST] <ubitux> BBB: as soon as you apply your threading patches i'll apply mine a trigger a new tsan run [20:08:07 CEST] <AaronL> Compn: It is not specific to H.264 and is actually quite general. But, I think you noticed that when you took a look at it. [20:08:17 CEST] <BBB> ubitux: -eneedsreview ;) [20:08:57 CEST] <ubitux> can you run make fate THREADS=3 or sth on your patch just in case? :p [20:20:38 CEST] <ericdc> Hi guys I have a question. To get a 800x480 resolution at 30 FPS with H264 what kind of ARM chip would be the minimum requirement? Also is libavcodec designed to use extensions like DSP and NEON on ARM? [20:28:46 CEST] <BBB> ubitux: seems to work for png :) [20:28:55 CEST] <BBB> but something is broken w/ vp9, checking [20:34:32 CEST] <kkanungo17> ericdc: wouldn't any cortex a8 and up be able to do that? [20:36:07 CEST] <ericdc> kkanungo17: perhaps but what about older devices? [20:37:07 CEST] <kkanungo17> would have to look into it [20:45:14 CEST] <tmm1> is it possible to tell if a h264 bitstream is interlaced by looking only at the SPS? [20:55:10 CEST] <AaronL> tmm1: May be possible--you could review https://cardinalpeak.com/blog/the-h-264-sequence-parameter-set/ and see what the tool reports [20:55:29 CEST] <AaronL> and compare between an H.264 bitstream that is progressive and one that is interlaced [20:55:40 CEST] <AaronL> using the same encoder to produce both [20:57:21 CEST] <tmm1> funny, that's exactly what i'm doing [20:57:26 CEST] <atomnuker> BBB: isn't "av_codec_get_codec_descriptor(src)->props & AV_CODEC_PROP_INTRA_ONLY)" returns !0 for intra only [20:57:43 CEST] <atomnuker> so it'll sync for intra-only codecs only or if for_user is 1 [20:57:51 CEST] <BBB> oh did I forget a !? [20:57:52 CEST] <tmm1> previously i thought sps->frame_mbs_only_flag == 0 always meant progressive, but i found a sample where that's not true [20:57:53 CEST] <BBB> maybe I did [20:57:55 CEST] <BBB> sorry [20:57:59 CEST] <BBB> like I said, totally untested :D [20:58:16 CEST] <tmm1> err, ==1 [20:58:18 CEST] <BBB> atomnuker: lemmefix [20:58:32 CEST] <BBB> atomnuker: but do you think the idea of the patch makes sense? [20:59:38 CEST] <atomnuker> I'm not sure actually [20:59:53 CEST] <atomnuker> what if the width and height change between each avctx? [21:00:37 CEST] <atomnuker> what's usually the dst in this case? [21:03:35 CEST] <BBB> atomnuker: the dst in case of skipping is the next threads avcodeccontext [21:03:43 CEST] <BBB> if its the user or whaever, for_user=1 and we do sync [21:03:48 CEST] <BBB> from_user is done in a different function [21:04:04 CEST] <BBB> so the idea is to continue allowing synchronization between user and worker threads [21:04:11 CEST] <BBB> but not between worker threads (for intraonly) [21:11:56 CEST] <atomnuker> as long as the user's context has the same data as the thread which decoded the returned frame it should be fine [21:12:02 CEST] <AaronL> tmm1: you can see how MediaInfo figures it out [21:12:34 CEST] <AaronL> source code is available for MediaInfo [21:13:09 CEST] <BBB> atomnuker: yeah thats still guaranteed [21:16:23 CEST] <atomnuker> then yeah it makes sense, each worker reads the width and height itself always so there's no need to sync it [21:17:12 CEST] <atomnuker> (until some intra only codec appears which doesn't always send that data on every frame to save 8 bytes on a 1Mb packet :)) [21:17:36 CEST] <BBB> then its not intra-only [21:17:46 CEST] <BBB> ;) [21:17:50 CEST] <BBB> right? [21:18:02 CEST] <BBB> if I seek to frame 2, I cant decode it without having decoded frame 1 first (at least these 8 bytes) [21:18:37 CEST] <wm4> PaoloP: yes [21:18:51 CEST] <PaoloP> wm4: thnks [21:20:39 CEST] <PaoloP> when sending patches to the ML, is it better to attach them to the mail or paste it in the body of the msg ? [21:21:12 CEST] <ubitux> git send-email [21:21:28 CEST] <ubitux> (--in-reply-to) [21:26:55 CEST] <PaoloP> "git send-email --to ffmpeg-devel(a)ffmpeg.org mypatch.txt" is enough or I have to add some other fields/descriptions? [21:34:06 CEST] <ubitux> PaoloP: git send-email -1 --to=ffmpeg-devel(a)ffmpeg.org --in-reply-to=647710073.8448733.1490656403410(a)mail.yahoo.com [21:38:21 CEST] <PaoloP> thnks ubitux [21:48:36 CEST] <ubitux> should we start working on the bitstream merge? [21:48:52 CEST] <ubitux> as merges come, we're going to reach it and it's going to block any further merges [21:48:59 CEST] <ubitux> can we start considering it now? [21:52:35 CEST] <atomnuker> we can't merge the reader itself, its slower [21:53:28 CEST] <atomnuker> the API sucks donkeys [21:54:43 CEST] <thebombzen> so I just made a 2-line patch to add HEVC and Opus support to the nut container (two line addition to nut.c) [21:54:53 CEST] <thebombzen> and I did a few quick tests and it appears to work [21:55:08 CEST] <thebombzen> so I'd like to submit this patch to the maintainers but I don't know how or if this will even be approved [21:55:22 CEST] <thebombzen> can someone give me some tips? [21:56:49 CEST] <jamrial> thebombzen: https://ffmpeg.org/developer.html#Contributing [21:57:05 CEST] <jamrial> basically, send your patches to the ffmpeg-devel mailing list [21:59:15 CEST] <thebombzen> this is just me being unfamiliar with git, but I've made a few patches to my local git repo, so I'm not sure the sha-1 sums will match up [21:59:20 CEST] <thebombzen> is that a problem? [21:59:49 CEST] <jamrial> they will not matter once you make a patch with git format-patch and send them, no [22:00:06 CEST] <thebombzen> okay, cause this is the patch I would send: https://0x0.st/v1c.patch [22:00:20 CEST] <thebombzen> it's just a 2-liner but I've never done this before and I'm a bit worried something might messup [22:00:29 CEST] <Compn> thebombzen : so just ask michaelni to review it, i think he maintains nut [22:00:43 CEST] <Compn> there might be a reason why it wasnt adde [22:00:58 CEST] <thebombzen> well in this case my best guess is "never got around to it" [22:01:18 CEST] <thebombzen> cause Nut supports all riff/avi tags, plus a few extras that were explicitly added (like vp9) [22:01:18 CEST] <jamrial> thebombzen: yes, you can send that just fine [22:01:27 CEST] <thebombzen> jamrial: alright thanks [22:02:07 CEST] <thebombzen> I tested it a bit - I remuxed an hevc/opus from matroska to nut with ffmpeg -i input.mkv -c copy output.nut and I could play the file correctly in both ffplay and mpv (linked against the same ffmpeg) [22:02:12 CEST] <thebombzen> so I'd assume there'd be no real issues [22:02:29 CEST] <jamrial> ubitux: afaik the api is the same so it should be a search and replace for get_bits.h functions into bitstream.h functions for those codecs libav doesn't have, so not a lot of work [22:02:33 CEST] <jamrial> but what atomnuker said is true, it's apparently slower in some cases [22:02:55 CEST] <ubitux> "in some cases"; which? what can we do about it? [22:03:03 CEST] <ubitux> 32-bit? ARM? [22:03:08 CEST] <ubitux> which decoder(s)? [22:03:44 CEST] <jamrial> some audio codecs i think, don't recall which ones, and yeah, 32 bit [22:04:12 CEST] <jamrial> BBB tried to get them to fix or consider the latter, but didn't succeed [22:05:25 CEST] <atomnuker> just merge the API and find and replace everything with a script [22:06:19 CEST] <atomnuker> don't bother changing the few codecs which do reading using the macros directly, they'll still work as long as its just an API change [22:07:08 CEST] <BBB> jamrial: what did I do? [22:07:18 CEST] <BBB> oh get_bits vs. bitstream? [22:07:20 CEST] <atomnuker> down the road we could make the cache size dependent on architecture/#define for the few codecs that could benefit [22:07:25 CEST] <BBB> yeah Im not getting into that trollwar [22:07:43 CEST] <BBB> if they believe they know what theyre doing and dont want input from me, then thats totally their call [22:07:52 CEST] <BBB> its their project [22:08:03 CEST] <atomnuker> BBB: they ignored my small tiny request as well [22:08:11 CEST] <atomnuker> make the bloody API consistem for encoding and decoding [22:08:15 CEST] <atomnuker> but no, fuck encoding [22:08:27 CEST] <BBB> I think its really just all politics [22:08:34 CEST] <BBB> they dont want to do it because you asked for it [22:08:42 CEST] <BBB> if luca had made the same suggestion, they would do it instantly [22:08:58 CEST] <BBB> at this point I dont want to reason with it anymore, I try to be fair in my reviews but that means I cant help them anymore [22:09:16 CEST] <BBB> sorry j-b [22:09:31 CEST] <BBB> but Im not a politician, I just code [22:10:04 CEST] <jamrial> the author of the reader was also kinda reluctant about changing anything [22:10:35 CEST] <jamrial> like, considering all the suggestions would mean more work and delay committing their work [22:10:54 CEST] <ubitux> no improvement came up after that? [22:11:10 CEST] <durandal_1707> just commit api but keep old functionality [22:11:44 CEST] <BBB> ubitux: its faster for some codecs on some archs, slower for other codecs on other archs [22:11:46 CEST] <BBB> its fairly random [22:12:04 CEST] <BBB> I think theres a system to it and it can be dissected into a signal, but .. like I said, nobody cares [22:12:31 CEST] <durandal_1707> if its faster just add define to toggle it? [22:12:59 CEST] <atomnuker> durandal_1707: like I said we can just make our bitstream reader size be dependend on a define for the few codecs that could benefit from a larger/smaller one [22:13:15 CEST] <atomnuker> but any codec which hardcore depends on reading performance does reading on its own [22:13:22 CEST] <atomnuker> see dirac_vlc and dnxhd decoder [22:13:47 CEST] <BBB> mpeg* also [22:14:16 CEST] <BBB> even if you do it manually, there might be utility to having a bigger cache [22:17:57 CEST] <thebombzen> alright I sent the patch [22:25:48 CEST] <cone-560> ffmpeg 03Marton Balint 07master:7cfa98fd9460: configure: use c++11 and fallback to c++0x for c++ files [22:25:48 CEST] <cone-560> ffmpeg 03Marton Balint 07master:c395d230b128: avdevice/decklink_enc: convert to std::atomic [22:25:48 CEST] <cone-560> ffmpeg 03Marton Balint 07master:77d2cb88741a: avdevice/decklink: deprecate @mode syntax in device name to specify mode [22:40:22 CEST] <iive> i've said it before, ffmpeg used to have a bitstream reader that used same principle as their new one. It was slowe on 32 bit so Mans removed it. [22:56:54 CEST] <uau> i tested the new bitstream reader with vorbis on x86 - it was measurably slower, but OTOH decoding was still so fast that a significant portion of CPU was spent outside the codec (memory copying for packet handling and audio format conversion) [22:57:24 CEST] <uau> so unless you're going to do micro-optimizations to speed up such non-decoding parts, it doesn't matter much IMO [22:58:16 CEST] <atomnuker> everything matters on mips [22:58:47 CEST] <kierank> uau: in something like vorbis bitstream reading is tiny [22:59:01 CEST] <kierank> it's huffyuv, prores, dirac where it really matters [22:59:47 CEST] <thebombzen> uh, so the patch I sent to the ffmpeg-devel mailing list needs "moderator approval" because I'm not subbed to the list [22:59:48 CEST] <thebombzen> how does that work [23:00:10 CEST] <thebombzen> would subbing to the list automatically grant "approval" [23:00:29 CEST] <thebombzen> should I just sub and resubmit [23:00:30 CEST] <PaoloP> ubitux, wm4 (and other people of the ffmpeg team): done. please, give a feedback when you can, so I can provide other useful snippets (in the same style) [23:00:50 CEST] <thebombzen> is wm4 even on the ffmpeg team [23:01:09 CEST] <BBB> thebombzen: yes [23:01:14 CEST] <BBB> thebombzen: and yes, just sub and re-send [23:01:15 CEST] <PaoloP> http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209296.html [23:01:16 CEST] <thebombzen> oh okay [23:06:18 CEST] <wm4> there's no "team", just people who participate in development [23:07:02 CEST] <ubitux> there is a voting comittee though :) [23:07:09 CEST] <wm4> thebombzen: yes, subscribe to the list and you won't have to wait [23:07:13 CEST] <ubitux> (and people with write access) [23:07:42 CEST] <wm4> PaoloP: I'll look tomorrow [23:08:26 CEST] <thebombzen> I canceled the previous one just to be safe [23:08:30 CEST] <thebombzen> and yea I subbed and resent it [23:10:08 CEST] <PaoloP> ok wm4 thanks [23:11:01 CEST] <thebombzen> I just thought wm4 was the lead dev of mpv and thus had a lot of stake in the FFmpeg project [23:11:08 CEST] <thebombzen> but by "the team" I meant maintainers [23:11:49 CEST] <kierank> BBB: i agree, i don't have an objection to the technical changes behind the patch, but they just changed naming for no good reason [23:12:02 CEST] <BBB> kierank: NIH ;) [23:12:25 CEST] <BBB> thebombzen: wm4 is one member of the team of developers over here :) [23:12:53 CEST] <kierank> BBB: don't attribute to NIH that which is adequately explained by madness [23:13:24 CEST] <BBB> madness implies active malice, Im not sure about that [23:13:37 CEST] <BBB> Im not saying it isnt, Im just saying Im not sure about it [23:14:12 CEST] <BBB> e.g. most of the vp9 changes ubitux merged from them (thanks!) were just changes. they didnt make it better, they didnt make it worse. they just changed it for the sake of changing it [23:14:31 CEST] <BBB> (so we merge it to keep the diff small, which is an OK reason on our side) [23:15:13 CEST] <PaoloP> wm4: please, consider that the code is only 273 lines long. The transcode_aac.c is about 800 lines. I could provide another snippet which is equal to the one I posted + a decode block, so that transcoding is done, but with a much shorter (and hopefully clearer) code than the existing one [23:16:11 CEST] <ubitux> goddamnit how were they able to run that dosemu thing [23:17:54 CEST] <PaoloP> my idea is always to separate the blocks in a strict sequential and procedural way (demux --> decode --> resample --> encode --> mux). It's the only way to let the user of the API understand all the steps. [23:23:02 CEST] <BBB> ubitux: wanna review the vp9 changes on the ML so I can push them? or busy w/ merge and want me to find some other victim? [23:23:27 CEST] <ubitux> did something change from last time you asked me on irc? [23:23:33 CEST] <BBB> also if any poor soul wants to review h264/hevc/frame_thread changes, please do! :) [23:23:40 CEST] <BBB> ubitux: no [23:23:46 CEST] <BBB> but ML has no review yet [23:24:07 CEST] <ubitux> i can reply there if you want to proof of review [23:24:18 CEST] <ubitux> but i won't have anything additionnal to say i guess [23:24:31 CEST] <ubitux> i can still have a second look though [23:24:41 CEST] <BBB> up to you, if you dont have time I can find someone else [23:24:55 CEST] <BBB> Im just poking around to reduce my number of local patches [23:25:01 CEST] <BBB> so I can look at more/additional tsan errors [23:25:09 CEST] <BBB> we may actually be able to get it semi-clean this time [23:29:44 CEST] <ubitux> i suppose it passes make checkheaders? [23:30:09 CEST] <BBB> I actually had issues with that in one of the VDA files [23:30:21 CEST] <BBB> I can send a separate patch for that [23:32:09 CEST] <ubitux> honestly it looks pretty fine to me [23:32:25 CEST] <ubitux> btw, i haven't check, but i think all the tables not shared should be local to the c-files [23:32:49 CEST] <ubitux> but you may disagree due to object sizes [23:33:08 CEST] <ubitux> anyway, you have my "OKed by ubitux on IRC" [23:33:27 CEST] <BBB> but yes otherwise it passes make checkheaders [23:34:08 CEST] <BBB> I agree it may be worth spilling around some vp9data.c tables[] [23:34:15 CEST] <BBB> but I think that can be done separately [23:34:42 CEST] <ubitux> sure [23:35:06 CEST] <ubitux> michaelni: wanna have a look to the lavfi race fix? [23:35:26 CEST] <ubitux> i just realized you did something very similar in lavc/pthread_slice.c [23:36:32 CEST] <ubitux> BBB: do you need that Picture define? oO [23:36:58 CEST] <BBB> I dont know, I copied it from vda.h [23:37:05 CEST] <BBB> I have no idea how stuff like this works [23:37:16 CEST] <BBB> I think the vda dude should review it ;) [23:39:24 CEST] <wm4> thebombzen: no I don't [23:39:49 CEST] <wm4> BBB: I have another patch for pthread_frame.c on the ML that could use another pair of eyes (sent it on monday) [23:39:58 CEST] <BBB> subject? [23:40:28 CEST] <wm4> Subject: [PATCH] pthread_frame: minor simplification to error handling [23:40:32 CEST] <wm4> probably boring [23:42:27 CEST] <BBB> wm4: yeah that looks good [23:44:09 CEST] <ubitux> wait [23:44:19 CEST] <ubitux> it's already in the skipheaders [23:46:14 CEST] <ubitux> btw, i'm going to push the lavfi race fix [23:46:18 CEST] <BBB> ok [23:46:27 CEST] <ubitux> if anyone has thread related patches to push, now is the time [23:46:33 CEST] <ubitux> as i'm going to trigger that tsan instance manually [23:46:38 CEST] <BBB> I can push mine if you want [23:46:41 CEST] <BBB> but no review yet [23:47:00 CEST] <BBB> (hevc/h264) [23:47:05 CEST] <BBB> I guess theyre small so I can review [23:47:07 CEST] <BBB> er... [23:47:08 CEST] <BBB> push [23:47:23 CEST] <BBB> let me rebase after you push and Ill push [23:48:09 CEST] <cone-560> ffmpeg 03Clément BSsch 07master:473f0f75a16b: lavfi: fix race when func rets holder is NULL [23:55:46 CEST] <BBB> ubitux: any idea why SKIPHEADERS-yes isnt working? [23:56:00 CEST] <ubitux> a previous install of these files? [23:56:03 CEST] <ubitux> when it wasn't there [23:56:52 CEST] <BBB> is it because of this line in common.mak? ../common.mak:SKIPHEADERS += $(ARCH_HEADERS:%=$(ARCH)/%) $(SKIPHEADERS-) [23:57:01 CEST] <BBB> shouldnt that last one be $(SKIPHEADERS-yes)? [23:59:02 CEST] <BBB> oooooooo [23:59:03 CEST] <BBB> I get it [23:59:15 CEST] <BBB> SKIPHEADERS- skips stuff for libraries I dont have installed [23:59:23 CEST] <BBB> I do have VDA installed, since Im on mac [23:59:28 CEST] <BBB> so then its _not_ skipped [23:59:39 CEST] <BBB> so I think it needs to be moved from skipheaders-$(CONFIG_..) to SKIPHEADERS [00:00:00 CEST] --- Wed Mar 29 2017

1 0

ffmpeg.log.20170328
by burek 29 Mar '17

29 Mar '17

[00:00:02 CEST] <vader-> The original Source is VHS btw [00:21:19 CEST] <alexpigment> vader: is it possible that it's actually dark, but your video card on the capture system is set to a different color range? (e.g. Full vs Limited) [00:22:09 CEST] <alexpigment> generally speaking, Windows Media Player uses its own color range settings in my experience, but VLC is definitely affected by that setting [00:22:43 CEST] <alexpigment> Changing Limited to Full usually darkens playback to the correct levels [01:14:20 CEST] <vader-> where is this setting at? [01:43:36 CEST] <thebombzen> what is the purpose of using a partial color range? [01:43:44 CEST] <thebombzen> compared to full? [01:43:59 CEST] <thebombzen> what does one gain from this? [01:47:28 CEST] <TD-Linux> room for overshoot and undershoot for your ADC [01:47:49 CEST] <iive> idct stuff [01:47:56 CEST] <TD-Linux> when capturing ye olde NTSC signal you'd preserve any out of range signals [01:48:18 CEST] <TD-Linux> idct expands range anyway and JPEG gets away with full range [01:51:22 CEST] <thebombzen> but if jpeg can do it [01:51:26 CEST] <thebombzen> why can't NTSC [02:08:42 CEST] <TD-Linux> ye olde convention [02:09:07 CEST] <iive> it has nothing to do with ntsc [02:10:02 CEST] <vader-> ya i don't really have the option to change many settings on the Blackmagic H.264 recorder [02:11:50 CEST] <iive> it is more of a stuff of keeping the black back and the white white, after encoding and decoding. [02:12:11 CEST] <dystopia_> heh [02:12:37 CEST] <TD-Linux> yes I believe it came from SDI [02:12:40 CEST] <dystopia_> i bought one of those black magic intensity pro 4k cards [02:12:40 CEST] <iive> it involves stuff like color format changes, transformation and quantization. [02:12:50 CEST] <dystopia_> had nothing but trouble with it and it's software [02:15:10 CEST] <vader-> ya im working on a VHS archiving project [02:15:41 CEST] <vader-> trying to capture about 400-500 tapes [02:15:48 CEST] <vader-> that range from like 10-30 years old [02:16:06 CEST] <vader-> all editing, recorded, mastered, etc by amateurs [02:16:53 CEST] <vader-> so right now im just ripping them in with H.264 compression since this is what this box does... hardware H.264 compression [02:17:06 CEST] <vader-> running at 5Mbps bitrate which seems to be decent [02:17:12 CEST] <vader-> anything more has really diminishing returns [02:17:25 CEST] <vader-> and anything less isn't really worth the savings [03:36:55 CEST] <Justin_> Hi all, I have some questions about combining zoompan (and other filters) with a crossfade effect. [03:37:19 CEST] <Justin_> i pasted my code to the pastebin, here is the question: [03:38:30 CEST] <Justin_> if you input two images 640*480 px to this code, it will make kind of a slideshow, the first image will have the zoompan and then it will fade into the second image. [03:39:14 CEST] <Justin_> basically, the fadein this code is done speerate to the zoompan, and you will notice that it seems like it zooms back out befor ethe fade [03:39:40 CEST] <Justin_> I'm not sure how to sync the [crossfade] with the final frame of the zoompan [03:40:06 CEST] <jaredp> Hey everyone - can someone point me towards the documentation on the dash format? I don't see it on the official list of formats but it comes up when you run ffmpeg -formats [03:40:51 CEST] <Justin_> does anyone know how I can better integrate the zoompan with the crossfade effect [03:41:32 CEST] <Justin_> @jaredp, not me, sorry [03:42:17 CEST] <Justin_> in the pastebin the title of the paste is "crossfade with zoompan" [08:41:15 CEST] <turlando> Hello everyone [08:42:31 CEST] <turlando> I'm trying to write a tiny python script that will just get some audio files from a queue, make a continous stream with defined codec and bitrate and stream it over RTP [08:43:09 CEST] <turlando> Since I didn't actually find any actively supported python library I'm just scripting around ffmpeg [08:43:41 CEST] <turlando> I succesfully accomplished the stream part with ffmpeg -re -i in.ogg -map 0:0 -c:a:0 libvorbis -b:a:0 192k -f rtp rtp://127.0.0.1:1234 [08:45:18 CEST] <turlando> Since the client listening to che stream will exit as soon as the stream end on the server I'm trying to concatenate multiple files to send over rtp [08:45:51 CEST] <turlando> I have these two problems: I need a way to enqueue tracks, I need a way to play silence when the playlist reached its end [08:46:21 CEST] <turlando> Is this even possible with ffmpeg? Is it possible to script that? [08:51:06 CEST] <das_> hello [08:51:36 CEST] <turlando> hi [08:58:20 CEST] <jleclanche> I'm trying to record a video; audio is fine but the video itself is coming out running at 10x speed. Any idea why? Arch linux, this is the command line I'm using: ffmpeg -f video4linux2 -s 1024x576 -r 30 -i /dev/video0 -f alsa -i pulse -acodec libmp3lame -ab 48k [09:22:47 CEST] <thebombzen> turlando: there isn't a way to do that with ffmpeg [09:23:14 CEST] <thebombzen> but if you have your audio muxed into .ts for example, you can just concatenate .ts files [09:23:28 CEST] <thebombzen> and have ffmpeg read from standard input [09:23:39 CEST] <thebombzen> and use a concatenation-friendly container to feed files to it, like .ts [09:23:57 CEST] <thebombzen> although I recommend using libopus instead of libvorbis because it's better for streaming [09:24:03 CEST] <thebombzen> (and better quality audio) [09:24:22 CEST] <turlando> thebombzen I will stream mostly ogg and maybe some mp3. Isn't ts just a container format? I need to encode my audio to maybe aac inside the ts or not? [09:24:33 CEST] <thebombzen> yes mpegts is a container [09:24:47 CEST] <thebombzen> but mpegts is a container that supports concatenation [09:24:58 CEST] <thebombzen> also you should be using opus audio [09:25:10 CEST] <turlando> I got all my library in ogg, too late :P [09:25:14 CEST] <turlando> vorbis* [09:25:23 CEST] <thebombzen> well you're transcoding it anyway [09:25:58 CEST] <thebombzen> either way [09:26:18 CEST] <thebombzen> using a concatenation-friendly container like mpegts is probably the easiest [09:26:31 CEST] <thebombzen> cause then ffmpeg reading from standard input will effectively be reading a continuous stream of audio [09:26:46 CEST] <turlando> thebombzen I see, but I still need to handle silence and such corner cases, it still feels like an hack [09:27:06 CEST] <thebombzen> well have an audio file of pure silence [09:27:31 CEST] <turlando> The ffmpeg that will stream using rtp still needs the source file hasn't got an end [09:27:34 CEST] <thebombzen> given that your stream has to be broadcasting 24/7, the only way to send silence is to just send audio that is silent [09:27:53 CEST] <thebombzen> and yea that's why you have ffmpeg read from standard input [09:27:56 CEST] <thebombzen> rather than from a file [09:28:09 CEST] <thebombzen> and you feed the audio to ffmpeg's standard input [09:28:55 CEST] <jleclanche> @@@++ [09:28:56 CEST] <turlando> That is a great hint, thank yoy. I was just saying that I must be faster to transcode than to stream, which can seem obvious but still can give birth to race conditions [09:29:12 CEST] <thebombzen> what race conditions [09:29:35 CEST] <thebombzen> jleclanche: yes @@@ should have 1 added to it [09:30:00 CEST] <jleclanche> keyboard fell :( [09:30:12 CEST] <turlando> If not race conditions it will definitely make the streamer ffmpeg kill itself [09:30:21 CEST] <thebombzen> that makes no sense [09:30:32 CEST] <thebombzen> ffmpeg exits if it reaches end-of-file on input [09:30:43 CEST] <thebombzen> but if it's reading from standard input it won't reach end-of-file, unless you send it [09:30:47 CEST] <thebombzen> so just don't do that [09:31:02 CEST] <turlando> I was referring to files as input [09:31:09 CEST] <turlando> Which was by bad design [09:31:29 CEST] <thebombzen> yea that won't make ffmpeg kill itself [09:31:37 CEST] <thebombzen> it'll make ffmpeg gracefully exit [09:31:41 CEST] <thebombzen> if it reaches end-of-file [09:31:49 CEST] <thebombzen> so maybe you should use the thing I suggested [09:31:53 CEST] <thebombzen> which is to read from standard input [09:32:20 CEST] <thebombzen> instead of complaining that what you're already doing won't work [09:33:05 CEST] <thebombzen> and I have to go to bed [09:33:50 CEST] <turlando> Maybe I am bad at exmplaining myself but I was just saying thank you and that your way is a solution to my problem [10:01:16 CEST] <Snowie> Hi all, hope all is well. Trying to convert some files for use on PS4, feel like I'm getting closer, but I'm obviously missing something. This is what I have so far but i'm getting an error: ffmpeg -i input.mkv -sn -vcodec mpeg4 -profile:v high -level 4.2 -acodec mp3 output.mkv [10:02:02 CEST] <Snowie> target file types available are http://manuals.playstation.net/document/en/ps4/music/mp_format_m.html [10:02:37 CEST] <Snowie> Error message is Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [10:08:22 CEST] <Snowie> actually, going for h.265 instead seems to be building. hopefully it works, doing it for someone else. Anyone able to confirm if this will satisfy the PS4's unusually tight requirements? Error while opening encoder for output stream [10:08:26 CEST] <Snowie> #0:0 - maybe incorrect parameters such as bit_rate, rate, width [10:08:35 CEST] <Snowie> sorry, wrong paste [10:09:11 CEST] <Snowie> ffmpeg -i AdventureTimeTest.mkv -sn -vcodec h264 -acodec mp3 AdventureTimeTestConverted.mkv [10:10:39 CEST] <BtbN> The PS4 can play hevc? [10:10:44 CEST] <JEEB> not as far as I know [10:15:17 CEST] <Snowie> hevc? is there something i need to do differently for the audio or video encoding? [10:15:53 CEST] <JEEB> HEVC is the original name for H.265 [10:15:53 CEST] <Snowie> supported formats are super strict, listed here http://manuals.playstation.net/document/en/ps4/music/mp_format_m.html [10:15:59 CEST] <JEEB> or well, name of another standards body :P [10:16:09 CEST] <Snowie> JEEB: ahh, i see [10:16:10 CEST] <JEEB> (which was given to it before ITU-T blessed it) [10:16:20 CEST] <JEEB> just like AVC is the ISO/IEC name for H.264 [10:16:26 CEST] <JEEB> H.xxx is ITU-T [10:17:47 CEST] <Snowie> Friend of mine got these files, and they are mkv, which is a supported container, but within that they are strict. Audio was originally in what looked like the right format too though, same with video. I think i'm clutching at straws now [10:21:23 CEST] <Snowie> I think i want to try and crack this nut and script it so it can just work. Frustrating i don't have the ps4 here to test it though. [10:37:27 CEST] <termos> when getting the time_base from the deprecated AVCodecContext in AVStream i'm getting 1/6000, but when I'm getting it from the one I create myself with avcodec_alloc_context3 + avcodec_parameters_to_context I'm getting 0/2 as timebase from that AVCodecContext [10:37:47 CEST] <termos> is this a bug? if not how will I be able to obtain the correct codec time_base? [10:38:57 CEST] <termos> for audio they are the same, both time_bases are 1/44100 [10:51:06 CEST] <termos> I see the codecpar are not containing any time_base information either, not framerate either (but they have sample_rate) [11:05:06 CEST] <DemoniacMilk> hey everony [11:05:18 CEST] <DemoniacMilk> *everyone [11:06:47 CEST] <DemoniacMilk> are there any ressources that might help me to cross compile ffmpeg for an ARM based system? [11:35:46 CEST] <Snowie> So im settling with this to convert to ps4 compatible video. ffmpeg -i Test.mkv -codec:v h264 -profile:v high -level 4.2 -codec:a ac3 TestConverted.mkv [11:36:13 CEST] <Snowie> can anyone tell me if ac3 (Dolby) as listed on ps4 manual is just fine to encode as ac3 though [11:37:04 CEST] <Snowie> like, is ac3 just a Dolby proprietary format or is dolby ac3 a subset of ac3 [11:37:13 CEST] <Snowie> googling just got confusing [11:39:02 CEST] <BtbN> you probably don't want to encode ac3. [11:39:06 CEST] <BtbN> Just use aac and libx264 [11:40:10 CEST] <Snowie> BtbN: ok. ps4 only supports aac cl though. Do I need to add a parameter to get that output in the encoding? [11:40:18 CEST] <BtbN> cl? [11:40:33 CEST] <Snowie> BtbN: sorry LC http://manuals.playstation.net/document/en/ps4/music/mp_format_m.html [11:40:39 CEST] <BtbN> That's normal AAC. [11:40:46 CEST] <Snowie> ok, perfect [11:42:06 CEST] <Snowie> I think the issue is just that most videos found on the web are encoded for best fit, so older mpeg standards, where ps4 ONLY plays the latest (high 4.2). Does that make sense though? or am i misunderstanding the whole thing [11:42:06 CEST] <DemoniacMilk> guys, has anyone of you cross compiled ffmpeg before? [11:43:08 CEST] <DemoniacMilk> im trying to compile for an arm based system using arm-linux-gnueabi-gcc -I ./ ffmpeg.c -o ffmpeg_ARM [11:44:10 CEST] <DemoniacMilk> compilation is started, but stops saying something like /tmp/ccrUvte3.s: Assembler messages: /tmp/ccrUvte3.s:255: Error: Invalid Instruction »cmovg r3,r2« [11:45:28 CEST] <DemoniacMilk> i guess the instruction set and names might differ for the target platform, but i dont know how to work around that [11:56:21 CEST] <DemoniacMilk> oh i think i figured it out [11:56:51 CEST] <DemoniacMilk> i have to run configure, providing info on the cross compilation (target os, target arch, cross compiler) then make? [12:53:52 CEST] <BtbN> Snowie, a h264 decoder that supports high can always decode main and constrained baseline as well. [12:54:04 CEST] <BtbN> Normal baseline is a bit different, but most of them support it as well [13:05:24 CEST] <Tom_B> I'm using ffmpeg to convert video to HLS, is there any way to reduce the amount of time ffmpeg needs before it starts processing the input and creating the output? By default there's quite a few seconds delay [13:05:48 CEST] <__jack__> obviously, not [13:07:16 CEST] <vlt> Tom_B: Are you using the "-ss" option? If yes, there's a difference between putting it before and after the "-i" arg. [13:09:55 CEST] <Tom_B> I'm not seeking, I'm connecting to a live stream and re-encoding it, it's acceptable but there's a 5-10 second delay before it starts processing any output. ffmpeg shows me stream information and a bit of debug output. I wondered if somehow disabling this would improve startup time [13:16:39 CEST] <BtbN> you can't avoid the startup delay of joining a livestream [13:16:53 CEST] <BtbN> It has to wait at least for the next IDR Frame to come by [13:17:05 CEST] <BtbN> which can be anything between 1 and 10 seconds [13:17:15 CEST] <BtbN> or even more for weird stream setups [13:21:44 CEST] <Tom_B> ah thanks, makes sense [13:23:05 CEST] <libertas> hi, -autoexit for ffplay doesn't seem to work in the following command [13:23:10 CEST] <libertas> ffplay -autoexit -loglevel quiet -t 3 -x 800 -y 600 ./VID_20170131_194035.3gp [13:23:48 CEST] <libertas> I'm even unable to close the video window when clicking the close button [13:24:20 CEST] <libertas> have to Ctrl+c the bash command to close the window [13:24:31 CEST] <libertas> any tips for this problem? [13:25:39 CEST] <libertas> q, Esc don't work, too [13:28:55 CEST] <dwarfh> whose responsibilty of syncing dispay video stream? is it programmers? or avcodec_decode_video2 take of? Actually I have small program which plays video but it plays very fast when sound is disabled [13:30:55 CEST] <kepstin> dwarfh: it's up to the player to sync a/v; the decoder only gives you the info needed to do it [13:31:49 CEST] <kepstin> if you have sound it's "easy", because the sound card consumes it in realtime, so you just have to sync video frames to the audio. But with video only, you have to time it yourself with os clock. [13:39:22 CEST] <dwarfh> kepstin: ok great, thanks, I was confuse with pts and dts values, once again thanks for clearing my doubt [13:54:35 CEST] <Tyras> Could someone help me with YUV (UYVY/YUY2) macropixels? How do I store in a macropixel a black pixel alongside a "colored" pixel? [15:37:14 CEST] <bf_> I have a list of x264 frames and I want to convert them to mp4 with ffmpeg. What is the best way to do it? [15:37:38 CEST] <bf_> The x264 frames are extracted from an RTMP connection [15:54:55 CEST] <BtbN> You mean you have a raw .h264 file? [15:56:03 CEST] <bf_> BtbN: No I am extracting frames out of an rtmp stream [15:56:30 CEST] <BtbN> So, just use nignx-rtmp? [15:56:49 CEST] <bf_> BtbN: I spent yesterday with nginx-rtmp, it is very buggy, both in HLS and DASH [15:57:01 CEST] <bf_> As I need only a subset of its features I want to roll my own solution [15:57:12 CEST] <bf_> Because they all keep on using ffmpeg anyways [15:57:21 CEST] <BtbN> It works great for me, for HLS and rtmp re-streaming. [15:57:42 CEST] <BtbN> nginx-rtmp is by far the best rtmp server you'll find. [15:57:46 CEST] <bf_> HLS works but it does not respect the segment size / playlist length. I always end up with 30sec deplay [15:57:47 CEST] <BtbN> ffmpeg is not one, btw. [15:57:58 CEST] <BtbN> so you will have to write one yourself, which is not a simple task at all [15:57:58 CEST] <bf_> I mean ffmpeg is doing heavy listing in nginx-rtmp, right? [15:58:05 CEST] <BtbN> no? [15:58:27 CEST] <BtbN> you can call ffmpeg via exec or so, but nginx-rtmp does not depend on ffmpeg. [15:58:36 CEST] <bf_> hm? [15:58:54 CEST] <bf_> I read parts of its source and took away that it is indeed using ffmpeg [15:59:26 CEST] <bf_> the maintainer Roman Arutyunyan is a brilliant man but unfortunately he isn't maintaining the project any more [15:59:41 CEST] <bf_> I have already hit two bugs which are listed as 2+ year old issues.. [15:59:55 CEST] <bf_> And when I start compiling my own nginx I can also write my own rtmp server [16:00:09 CEST] <BtbN> No idea what you are doing with it, but it works great for me on the latest version of nginx. [16:00:20 CEST] <BtbN> Yeah, sure, write your own rtmp server... [16:00:32 CEST] <bf_> I mean there is already a node.js / cpp rtmp server out there [16:00:42 CEST] <bf_> which gives me a stream of x264 video frames and aac audio frames [16:01:12 CEST] <BtbN> So you misconfigured nginx-rtmp, and instead of figuring out the issue, you start to re-write it? [16:01:31 CEST] <bf_> why misconfigured? [16:01:42 CEST] <bf_> I read 20+ different configs and tried all day [16:01:49 CEST] <termos> with avcodec_send_frame/avcodec_receive_packet for encoding, will either of these functions do any encoding or will everything be done in a background thread? Asking because I'm thinking of doing a bunch of avcodec_receive_packet's in one single thread and I don't want there to be any performance issues [16:02:00 CEST] <bf_> HLS is working but with 30+ sec delay, but dash is not working (with listed bugs) [16:02:21 CEST] <bf_> So I want to build a node.js-based OBS -> RTMP -> DASH thing [16:02:57 CEST] <BtbN> HLS has inherent delay by design, same for DASH. No magic can change that. [16:03:12 CEST] <bf_> But it shouldn't be 30s on a local stream [16:03:14 CEST] <kepstin> having a delay is an inherent part of segmented streaming formats... 30s is consistent with a normal 3 segment delay 10s segment hls stream [16:03:27 CEST] <BtbN> With 10 seconds segment length, 30s delay is exactly what one would expect [16:03:45 CEST] <kepstin> you can use smaller segments to reduce the delay, but it reduces video coding efficiency, so :/ [16:03:52 CEST] <bf_> I was using hls_fragment 2s; hl_playlist_length 4s; [16:03:56 CEST] <bf_> it was not working [16:04:05 CEST] <kepstin> bf_: and you re-encoded the video to have 2s between keyframes? [16:04:07 CEST] <BtbN> it will only cut to the smallest possible gop length [16:04:15 CEST] <bf_> it is an obs live stream [16:04:17 CEST] <BtbN> so if you have 10 second GOPs, it will product 10 second segments [16:04:55 CEST] <bf_> I can't seem to configure that in OBS [16:05:22 CEST] <kepstin> bf_: https://i.imgur.com/ahJ6s4W.png [16:05:22 CEST] <bf_> Is GOP length defined through bitrate? [16:07:40 CEST] <alexpigment> GOP = -g ## [16:07:51 CEST] <alexpigment> or -x264-params keyint=## [16:08:04 CEST] <bf_> I'm trying to use imgur, my upload fials [16:08:20 CEST] <bf_> https://ibb.co/hiOaMF [16:08:33 CEST] <bf_> Linux f*cking with me again -.- [16:08:48 CEST] <bf_> kepstin: I dont have that option [16:09:00 CEST] <Tom_B> is it possible to select an audio streamm using a tag? E.g. select by language rather than ID? As each source can have streams in different indexes, using 0:1 or whatever requires knowing the stream order before launching ffmpeg [16:09:39 CEST] <bf_> alexpigment: for what does abbreviation gop stand? I cannot find it https://www.google.de/search?hl=de&q=gop#hl=de&q=gop+ffmpeg&* [16:10:02 CEST] <alexpigment> Group Of Pictures [16:10:11 CEST] <alexpigment> it's the arrangement of I, P, and B frames [16:10:23 CEST] <alexpigment> a value of -g 1 is only I frames [16:12:18 CEST] <bf_> thank you alexpigment [16:13:03 CEST] <alexpigment> np [16:13:11 CEST] <bf_> so if I get my users to configure obs to the right framerate then HLS would actually work with 2sec delay? [16:13:59 CEST] <kepstin> not framerate, but gop length (often called "keyframe interval") [16:14:07 CEST] <kepstin> and you probably won't get down below around 6s [16:14:49 CEST] <bf_> Ok that'd be so much better than 30s [16:15:05 CEST] <bf_> So just to make it clear, if I would've switched to dash this obs setting still would've given me 30sec delay? [16:15:23 CEST] <kepstin> depends on the player, but probably around 20-30s, yes [16:15:33 CEST] <bf_> Why is the default then 30? [16:15:52 CEST] <bf_> It looks like a premature optimization for recording storage space? [16:16:11 CEST] <kepstin> the default gop size of 10 seconds provides decent coding efficiency, and works ok for non-segmented streaming formats like rtmp [16:17:05 CEST] <bf_> thank you. just to make sure: GOP = keyframe interval? [16:17:05 CEST] <kepstin> (actually, i'm not sure that 10s is the default, but most encoders for hls end up doing something close to that) [16:17:25 CEST] <bf_> Or is GOP a higher concept? [16:18:52 CEST] <kepstin> GOP is a bit more accurate, since keyframe is sometimes used to refer to any I frames, but a GOP specifically is one that starts with an IDR frame [16:19:07 CEST] <kepstin> which is basically "a point where a decoder can start from" [16:21:47 CEST] <kepstin> but most gui encoder applications will probably have a field named 'keyframe interval' which actually sets the gop size [16:22:01 CEST] <kepstin> so in casual usage they're almost interchangable [16:22:08 CEST] <bf_> Thanks so much [16:22:38 CEST] <bf_> I've been diving into this topic for two days and I didn't know these small things before [16:23:13 CEST] <bf_> I use segment_size 2s and playlist_length 4s for HLS, but it still has ~8sec delay [16:24:01 CEST] <Tom_B> bf_ I'm doing something similar, the delay, for me, is actually due to ffmpeg opening the input (in my case a live stream) [16:24:51 CEST] <bf_> Tom_B: I was using "hls_fragment_slicing aligned;", removed it and now I am at ~6sec [16:26:11 CEST] <Tom_B> part of the problem is that the .m3u8 file doesn't get written until after the first segment has been created, it's a shame there's no way to create a 0.5s setgment0 then change it to a more sane number [16:27:17 CEST] <iive> x264 has some options for low latency [16:29:09 CEST] <DemoniacMilk> hello! im trying to compile ffmpeg for an ARM based system (since quite some time) and still have not been able to [16:29:45 CEST] <DemoniacMilk> i got a cross compiler set up and can compile ffmpeg on my host (using either the standard gcc or the cross compiler) [16:31:16 CEST] <DemoniacMilk> if i use the cross compiler, i need to manually start stripping the created files, because i havent figured out how to automate the strip selection [16:31:48 CEST] <DemoniacMilk> however, when i cross compile on my host, the target does not accept the created files (says its neither a file nor a directory) [16:32:04 CEST] <DemoniacMilk> while reading the elf header states its an executable for architecture ARM [16:32:24 CEST] <kepstin> DemoniacMilk: that error usually means that the path to the "interpreter" (dynamic loader) is wrong [16:33:04 CEST] <DemoniacMilk> you mean the stripping? [16:33:45 CEST] <kepstin> no, this probably is a misconfigured cross compile toolchain that doesn't match the fs layout of your target box [16:35:13 CEST] <bf_> Thank you very much again kepstin alexpigment and BtbN [16:35:28 CEST] <DemoniacMilk> hm how may i find out if there is a fs mismatch? [16:35:50 CEST] <alexpigment> does anyone know how to enable CBR mode for x265 within FFMPEG? i tried adding "-x265-params strict-cbr" (this gets ignored) and "-x265-params strict-cbr=1" (this causes a fatal error) [16:36:01 CEST] <alexpigment> the x265-params stuff is just a mess at this point :( [16:37:04 CEST] <kepstin> DemoniacMilk: run 'readelf -l ffmpeg' on your binary, it should print a line like "[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]" (except different, for the arm loader) [16:37:18 CEST] <kepstin> DemoniacMilk: that has to match where the linux distro on your arm board puts the loader [16:38:24 CEST] <DemoniacMilk> "[Requesting program interpreter: /lib/ld-linux.so.3]" [16:39:04 CEST] <DemoniacMilk> while there is only a ld-linux-armhf.so.3 in /lib [16:39:46 CEST] <DemoniacMilk> any hint where i can find out how to change the requested interpreter? [16:40:06 CEST] <kepstin> DemoniacMilk: sounds like you have the wrong cross compile env [16:40:29 CEST] <DemoniacMilk> please noooo :D [16:40:40 CEST] <DemoniacMilk> alright ill try to set that up again [16:41:07 CEST] <kepstin> make sure you build one for armhf this time :) [16:42:53 CEST] <DemoniacMilk> i hope ill figure out how to [16:43:11 CEST] <DemoniacMilk> got my hands on all this stuff (inlcuding linux) a few days ago so im really lost sometimes [16:44:15 CEST] <DemoniacMilk> oh one more question! [16:44:33 CEST] <DemoniacMilk> i tried to build ffmpeg on the target instead of cross compiling it on the host [16:44:52 CEST] <DemoniacMilk> but i got a ton of errors when running the configuration script [16:45:03 CEST] <DemoniacMilk> ./configure: line 466: pr: command not found [16:45:20 CEST] <DemoniacMilk> i guess i need to install some missing packet? [16:45:56 CEST] <kepstin> DemoniacMilk: yeah, you must have a really minimal linux distro on there. is this a raspberry pi or something? what linux distro? [16:46:07 CEST] <DemoniacMilk> arago i think [16:46:25 CEST] <DemoniacMilk> its the same chip that is used in beablebone blacks i think [16:47:00 CEST] <DemoniacMilk> the linux distro was provided as part of a linux SDK by texas instruments, so im not entirely sure whats in there [16:47:31 CEST] <kepstin> well, arago has decent docs for setting up a cross dev env, including a prebuilt compiler: http://arago-project.org/wiki/index.php/Setting_Up_Build_Environment [16:48:06 CEST] <kepstin> i have no idea how the packaging on that works, or how to get additional tools :/ [16:48:08 CEST] <DemoniacMilk> arm-linux-gnueabihf/ is the one i used actually (just randomly saw that in the doc) [16:48:17 CEST] <DemoniacMilk> its got opkg installed [16:48:24 CEST] <DemoniacMilk> but im not getting familiar with that [16:50:25 CEST] <DemoniacMilk> alright ill try to get things set up correctly here, thanks a lot for your help! [16:52:05 CEST] <alexpigment> FFMPEG doesn't seem to honor "strict-cbr" as an x265 param, and it fails when specifying "strict-cbr=1" (this trick is necessary for some x265-params) [16:52:46 CEST] <alexpigment> additionally ratetol=1 and -bt=1 both give errors stating that the value 0.000000 is out of range (i'm not specifying 0.000000 obviously) [16:53:22 CEST] <JEEB> x265-params should be passing options to the libx265 API as-is [16:53:36 CEST] <JEEB> so if it doesn't work then the API usage could be derp'd [16:53:37 CEST] <alexpigment> i agree that they should :) [16:53:45 CEST] <JEEB> no, I mean it most likely is [16:53:51 CEST] <JEEB> so most issues are then on the libx265 side [16:54:29 CEST] <alexpigment> well, does anyone have any ideas on how to make a CBR H.265 stream given the problems noted above? [16:54:45 CEST] <kepstin> the libx265 api requires being passed pre-split parameters key, value, iirc, so the string has to be pre-parsed in ffmpeg a bit :/ [16:55:18 CEST] <kepstin> the trick is to figure out what value some of these flag parameters actually need to work :/ [16:56:05 CEST] <alexpigment> well, i'm all open for any hints or suggestions. bt and ratetol obviously ignore whatever value you enter [16:56:14 CEST] <alexpigment> strict-cbr isn't honored [16:57:01 CEST] <alexpigment> oh wait [16:57:05 CEST] <alexpigment> i'm an idiot [16:57:09 CEST] <kepstin> strict-cbr should work if you can figure out the correct value to give it [16:57:19 CEST] <alexpigment> ok, so try something other than 1? [16:57:44 CEST] <kepstin> you could try the string "true" and the empty string, i guess :/ [16:57:49 CEST] <alexpigment> anyway, ratetol wasn't working because i had a bt from earlier elsewhere in the chain with an actual zero [16:57:59 CEST] <alexpigment> my bad ;) [16:58:08 CEST] <Tom_B> is there any way to automatically set one of many possible decoders? I have various streams, some are h264, others are mpegts. For the h264 streams I want to use h264_cuvid decoding, but only when it's applicable, is it possible to specify different decoders depending on the input type? [16:58:15 CEST] <kepstin> "ratetol" isn't even an x265 option as far as I can see [16:58:15 CEST] <alexpigment> either way, ratetol says it's an unknown parameter [16:58:30 CEST] <thebombzen> hmmm... I'm having issues with framerates in matroska containers [16:58:33 CEST] <alexpigment> -bt is accepted if 1 or more, but doesn't have any effect [16:58:57 CEST] <alexpigment> keptin: i'll try 'true'. thanks for the suggestion [16:58:59 CEST] <thebombzen> for some reason the matroska muxer/demuxer reports 120 fps erroneously: http://sprunge.us/XHcD [16:59:12 CEST] <kepstin> alexpigment: the options you can use should be the same as the cli options here: https://x265.readthedocs.io/en/default/cli.html [16:59:26 CEST] <kepstin> (in the x265-params string) [16:59:29 CEST] <thebombzen> I'm not entirely sure why [16:59:40 CEST] <alexpigment> yeah, i was only using ratetol because at some point this worked and it was deprecated [16:59:58 CEST] <alexpigment> i was hoping it still worked because strict-cbr wasn't working for me [17:01:19 CEST] <kepstin> thebombzen: what makes you think that's an error? it depends on the video souce, but sometimes if you have mixed 24 and 30fps content, it'll be encoded into a container with a 120fps nominal rate [17:01:42 CEST] <thebombzen> kepstin: because that should be listed as "tbr" not "fps" [17:01:57 CEST] <thebombzen> "fps" is the container's reported cfr [17:02:10 CEST] <thebombzen> whereas "tbr" is the timebase rate required to display alll frames accurately [17:02:35 CEST] <kepstin> right, but that original input file is reporting a framerate of 120, so that's just being preserved all the way through. [17:02:48 CEST] <thebombzen> no it's not [17:02:57 CEST] <thebombzen> the original input file is not 120 fps [17:03:09 CEST] <thebombzen> and if you look again it's not being preserved by the mp4 container [17:03:18 CEST] <thebombzen> which correctly reports 25.93 [17:03:47 CEST] <kepstin> that's... a really strange framerate [17:04:43 CEST] <thebombzen> I agree [17:04:49 CEST] <thebombzen> but it's also what the original content had [17:05:04 CEST] <kepstin> I have never heard of that being used anywhere. and to be honest, '120' tbr is strange too, the 120 rate is normally only used on ntsc stuff where it's actually 120/1.001 [17:05:24 CEST] <kepstin> so, you have a strange input file, and it's behaving strangely? :/ [17:05:45 CEST] <thebombzen> no what I find strange is the difference in behavior between matroska and mp4 [17:06:07 CEST] <kepstin> it's probably just a quirk of how metadata is stored vs calculated in the different formats [17:06:23 CEST] <thebombzen> actually to be honest [17:06:29 CEST] <thebombzen> the true original was muxed by libmatroska [17:06:35 CEST] <Tom_B> can you specify multiple values for -c:v before -i and have ffmpeg try each in order? At the moment it works out "conversion failed" can I specify that "if conversion fails, try this decoder instead" [17:06:36 CEST] <thebombzen> and the video was this: Video: h264 (High), yuv420p(tv, bt709/unknown/unknown, progressive), 1280x720, SAR 1:1 DAR 16:9, 500 fps, 120 tbr, 1k tbn, 719.28 tbc (default) [17:06:41 CEST] <kepstin> if there's no problem playing the video, then I wouldn't worry about it... [17:06:58 CEST] <thebombzen> is it because matroska uses a 1k tbn? [17:07:07 CEST] <thebombzen> speaking of which, is there any way to make it NOT use a 1k tbn? [17:07:15 CEST] <thebombzen> because I've had problems with matroska's 1k timebase [17:07:34 CEST] <kepstin> thebombzen: you can theoretically use a different power of 10, but it's limited to only powers of 10 and i've never seen a muxer supporting anything other than 1k [17:07:49 CEST] <thebombzen> that sounds like a limitation of matroska [17:07:53 CEST] <kepstin> yep [17:08:01 CEST] <thebombzen> but what else should you use [17:08:18 CEST] <thebombzen> I haven't found anything else that supports everything [17:08:30 CEST] <kepstin> if you need to actually preserve timebase in intermediate stuff, you could use nut, I think that does it. [17:08:39 CEST] <thebombzen> nut doesn't support hevc or opus [17:08:51 CEST] <thebombzen> which it should, but it doesn't [17:08:53 CEST] <kepstin> hmm, that's annoying [17:09:27 CEST] <kepstin> but yeah, I think the fps code in ffmpeg for matroska really just tries to "guess" the timebase and framerate that fits the video [17:09:56 CEST] <thebombzen> http://sprunge.us/haGF [17:10:12 CEST] <thebombzen> wait not that [17:10:34 CEST] <thebombzen> http://sprunge.us/BEgb [17:10:34 CEST] <thebombzen> this [17:10:37 CEST] <kepstin> (if you get messages like 'past duration too large' when transcoding a matroska file, it means the guess was wrong (framerate too low) [17:10:39 CEST] <kepstin> ) [17:10:59 CEST] <thebombzen> if you get that, how do you fix it? [17:11:15 CEST] <thebombzen> should I use -vsync cfr? [17:13:26 CEST] <kepstin> i usually end up rewriting the video timestamps with filters :/ [17:14:34 CEST] <kepstin> some reports are that -vsync 0 -copytb 0 might work :/ [17:15:26 CEST] <kepstin> or using the -r input option, if you know the input is supposed to be cfr and you know the exact framerate [17:18:13 CEST] <kepstin> (i only found out what that 'past duration too large' message even meant when I was doing some work on the 'concat' video filter to handle concatenating sources with different framerates) [17:18:52 CEST] <thebombzen> -copytb 0? what does that do [17:18:55 CEST] <alexpigment> ok, here's a more basic question. has anyone here ever been able to get x265 to honor a bitrate at all? [17:20:57 CEST] <kepstin> alexpigment: using the regular ffmpeg -b:v option should work for bitrate in x265 [17:21:56 CEST] <alexpigment> right [17:22:00 CEST] <kepstin> (based on the order that parameters are applied in, `-x265-params bitrate=N` should work too) [17:22:01 CEST] <alexpigment> i'm just not seeing that being the case [17:22:05 CEST] <alexpigment> i also tried that [17:23:40 CEST] <kepstin> does it work in multi-pass mode? [17:23:51 CEST] <kepstin> might just be that the 1-pass abr doesn't work very well :/ [17:23:58 CEST] <alexpigment> i haven't tried - ultimately i won't be able to use 2-pass [17:24:27 CEST] <kepstin> using vbv might help too if you have a specific target [17:24:45 CEST] <alexpigment> to be clear, i'm getting a *change* in bitrate when i set one vs the other, but the average bitrate just doesn't end up being close to what i set [17:24:57 CEST] <alexpigment> yeah i tried that earlier along with a bunch of other things [17:24:59 CEST] <alexpigment> trying again nowq [17:25:01 CEST] <alexpigment> *now [17:25:12 CEST] <kepstin> you're using fairly long samples to test this, right? short samples the bitrate will just not have time to converge :) [17:25:32 CEST] <alexpigment> i'm doing 10 second tests at the moment so my tests don't take all day [17:25:43 CEST] <kepstin> yeah, that's not nearly long enough. [17:25:45 CEST] <alexpigment> :( [17:26:10 CEST] <alexpigment> this is going to turn my hour of work into a day of work... [17:26:30 CEST] <kepstin> it would probably be getting close to the average bitrate you want by the end of the 10s, but the overal file average will be off quite a bit. [17:26:39 CEST] <alexpigment> (sorry for whining. was really just hoping to get some early positive results before i did longer tests) [17:27:00 CEST] <bf_> kepstin: Is there data on the 90% bitrate band for users by country? [17:27:25 CEST] <kepstin> bf_: I have no idea :/ [17:27:35 CEST] <bf_> Ok [17:29:44 CEST] <kepstin> alexpigment: i'm kind of curious why you can't use 2-pass. Either it needs to be realtime, in which case a few 5minute tests shouldn't take too long to encode, or it's not realtime, in which case 2-pass is just as not realtime :/ [17:30:09 CEST] <kepstin> alexpigment: and unless you actually need min bitrate for some reason, crf + vbv is probably preferable [17:30:17 CEST] <thebombzen> probably reading from a pipe [17:30:22 CEST] <thebombzen> that would be my only explananation [17:31:04 CEST] <alexpigment> kepstin: CRF+vbv will be the default option. i need to provide an option to fairly accurate hit a bitrate (and therefore file size) target due to burning onto disc [17:31:14 CEST] <alexpigment> and 2-pass unfortunately isn't an option in my case [17:31:23 CEST] <alexpigment> *accurately [17:32:07 CEST] <kepstin> so, 2-pass is designed to do what you want, target a file size accurately. any other option is going to compromise quality. [17:32:14 CEST] <alexpigment> right [17:32:25 CEST] <alexpigment> quality will be compromised for predictability [17:32:35 CEST] <alexpigment> but at high enough bitrate settings, that compromise won't be as great [17:32:38 CEST] <kepstin> and probably not hit the file size, because without future knowledge, you have less predictability [17:32:50 CEST] <alexpigment> and given blu-ray disc sizes, the bitrate allowance is pretty flexible in this case [17:33:01 CEST] <alexpigment> yeah [17:33:08 CEST] <alexpigment> that's why i'm hoping for an *actual* CBR mode [17:33:17 CEST] <alexpigment> which the FFMPEG wiki seems to imply is the default mode, and it's clearly not ;) [17:33:27 CEST] <kepstin> no, default is abr [17:33:40 CEST] <kepstin> which is design to approximately hit an average bitrate over long term [17:33:40 CEST] <alexpigment> https://trac.ffmpeg.org/wiki/Encode/H.265 [17:34:26 CEST] <kepstin> really, why can't you use 2-pass? if you're encoding from a pipe, just tee it to disk or encode to an intermediate format before doing the hevc final encode :/ [17:34:28 CEST] <alexpigment> "1-pass constant bitrate (by setting -b:v) [17:35:04 CEST] <kepstin> alexpigment: any time you see "constant bitrate" in simple encoding guides, it's probably actually abr :) [17:35:09 CEST] <alexpigment> it's going to be prohibitive for either a) time, or b) space considerations [17:35:11 CEST] <kepstin> unless you're talking about mp3 [17:35:24 CEST] <BtbN> if you are targeting a specific filesize, twopass encoding it is. [17:35:33 CEST] <alexpigment> yeah, i was really just making a joke about how ironically they only mention CBR on the wiki, as if CBR even works at all [17:35:49 CEST] <kepstin> i hope I'm not buying any of the BDs you're encoding if you're not gonna spend the time to do a proper 2-pass encode ;) [17:35:54 CEST] <BtbN> cbr can work. But at some point it starts inserting padding [17:36:07 CEST] <alexpigment> no, not at all [17:36:10 CEST] <alexpigment> i don't work for a studio [17:36:13 CEST] <kepstin> well, i suppose at BD bitrates even a bad hevc encode is probably tolerable [17:36:23 CEST] <alexpigment> nor am i producing any discs for distribution :) [17:36:58 CEST] <alexpigment> yeah, i mean if you're at 30mbps or so with H.264 using CBR, it's perfectly fine [17:37:12 CEST] <kepstin> honestly, if speed is important for you, just use x264 instead. it'll provide comparable quality at better speed, and is a more mature encoder [17:37:43 CEST] <kepstin> the only reason to use x265 is if speed isn't a problem, so you can spend the extra time the encoder needs to beat h264 [17:37:59 CEST] <alexpigment> kepstin, i appreciate your advice and i know you're right from the standpoint of "this is a better option". however, i'm telling you the constraints i'm working within to a achieve a goal [17:39:30 CEST] <kepstin> well, your constraints are "I need to do a 1-pass encode and hit a target filesize", and there's really no good solution to that :/ [17:39:36 CEST] <alexpigment> more than anything, i'm looking into customizability of HEVC streams to allow for the *possibility* of certain workflows. if it turns out that CBR is not functional at all, then that'll be scratched from the list. however, i can think of a handful of situations where it would be handy to have available, so i'm researching at the moment [17:40:16 CEST] <alexpigment> well, the solutions are in the documentation - they just don't work [17:40:42 CEST] <alexpigment> i mean i'm looking at a webpage that tells me it's possible within some small margin of error that i find to be acceptable [17:41:18 CEST] <alexpigment> but x265 through FFMPEG at the moment, is unfortunately like the Wild Wild West [17:41:23 CEST] <alexpigment> ;) [17:41:32 CEST] <kepstin> well, x265 in general is like that [17:42:05 CEST] <BtbN> x265 is real time capable for me now. [17:42:05 CEST] <alexpigment> do you think turning the rc-lookahead way down might have any effect? [17:42:22 CEST] <alexpigment> BtbN: at 1080p or UHD? [17:42:27 CEST] <kepstin> but yeah, it should be possible to get"strict-cbr" working via ffmpeg, with the caveat that it's marked as experimental in the docs, so make sure you're using a recent x265 library, and it would be difficult to tell what it's actually doing :) [17:42:48 CEST] <BtbN> 1080p at one of the fast presets [17:42:52 CEST] <alexpigment> oh gotcha [17:43:09 CEST] <BtbN> Well, given that a year ago it couldn't even hit 10fps... [17:43:33 CEST] <kepstin> alexpigment: if anything, having rc-lookahead higher should help it hit the bitrate more accurately. [17:44:02 CEST] <alexpigment> i hit ~21fps for 1080p over here on a 3770k. i'd probably do pretty close to realtime on my 5930k at home, but i haven't testesd [17:44:33 CEST] <alexpigment> kepstin: right, but if the encoder knows it can't lookahead further, wouldn't it stop deviating from the ABR as much? [17:46:59 CEST] <kepstin> hmm, looks like using the values "1", "true", or "yes" on boolean parameters in -x265-params should work [17:47:08 CEST] <kepstin> at least in the current x265 source code [17:50:27 CEST] <kepstin> the x265 encoder should be printing the params it's actually using in the log output, so you can check if they got passed through correctly [17:50:46 CEST] <BtbN> alexpigment, what preset? [17:50:54 CEST] <kepstin> if they're getting passed from ffmpeg, then it's really just up to the x265 encoder and whatever limitations it has in rate control :/ [17:52:09 CEST] <alexpigment> BtbN: oh sorry, that's a useful bit of knowledge, right? ;) i'm using veryfast for my current tests [17:53:08 CEST] <alexpigment> kepstin: 1, true, and yes all fail [17:53:28 CEST] <alexpigment> 0 gives no failure, but obviously doesn't do anything ;) same with not specifying a parameter at all [17:54:17 CEST] <alexpigment> kepstin: i'm a bit green on logging. is there something i need to specify to get a log file? [17:54:23 CEST] <thebombzen> how does x265 compare to x264? x264 is pretty mature and x265 is not [17:54:43 CEST] <bencc1> how can I count hls viewers? [17:54:45 CEST] <thebombzen> also is x265 still unusably slow for anything? [17:54:58 CEST] <alexpigment> x265 is only 'better' in theory - i don't think it's there yet. unfortunately, it's a standard that is enforced for certain mediums [17:55:01 CEST] <thebombzen> bencc1: that's a question for the webserver [17:55:12 CEST] <bencc1> thebombzen: ok [17:55:28 CEST] <thebombzen> whoever's actually serving the content over http can know that [17:55:30 CEST] <kepstin> alexpigment: ffmpeg just prints to stderr, should be on your terminal [17:55:39 CEST] <kepstin> interesting, strict-cbr mode only works if you're using vbv [17:56:38 CEST] <kepstin> i think? either that or the bitrate really isn't getting passed correctly :/ [17:56:48 CEST] <thebombzen> that's not a big surprise? [17:56:58 CEST] <thebombzen> because cbr is impossible without a vbv [17:57:03 CEST] <thebombzen> it just has to be very small to be "strict" [17:57:17 CEST] <kepstin> i suppose it's not. and yep, bitrate's being passed correctly, so I guess you just also need vbv params [17:58:30 CEST] <alexpigment> just looked in the 'log' in the place i think you're referring to. it says "ABR-5000 kbps" [17:58:49 CEST] <alexpigment> the problem is that i don't think it's being passed at all because all the "true" booleans cause a failure [17:59:13 CEST] <alexpigment> i'll try again with vbv settings to make sure that =1/=true/=yes all still result in failures [18:00:23 CEST] <kepstin> looks like in my quick test that the option is being accepted correctly. [18:00:30 CEST] <kepstin> https://gist.github.com/kepstin/b05650259a6b09d689477ed4751600ce [18:00:34 CEST] <alexpigment> ok, yeah i didn't get an error that time [18:00:42 CEST] <BtbN> https://bpaste.net/show/daab8309b731 [18:00:44 CEST] <kepstin> (it's obviously not hitting 1M there because i'm using a 320x240 testsrc, but still) [18:00:46 CEST] <alexpigment> i guess i was trying vbv stuff when strict-cbr wasn't being accepted [18:00:52 CEST] <BtbN> hitting exactly 60 fps for 1080p with veryfast [18:00:56 CEST] <alexpigment> so i wasn't using them together [18:01:06 CEST] <thebombzen> kepstin: ffmpeg 3.1.7? [18:01:20 CEST] <alexpigment> kepstin: thank you very much for your help. i would have been lost looking in the source code to find that info [18:01:32 CEST] <kepstin> thebombzen: hmm, i really should put a newer ffmpeg here. this is my work box, running a packaged ffmpeg :/ [18:01:51 CEST] <thebombzen> also I noticed it says "x265 8bit" [18:02:02 CEST] <thebombzen> can x265 do more than one bit depth per library [18:02:10 CEST] <thebombzen> which is probably the biggest limitation of x264 [18:02:10 CEST] <kepstin> thebombzen: yes, if compiled correctly [18:02:11 CEST] <furq> yeah but you need to enable it [18:02:14 CEST] <alexpigment> BtbN: what CPU? [18:02:21 CEST] <BtbN> R7 1800X [18:02:29 CEST] <kepstin> nice :) [18:02:43 CEST] <alexpigment> ah yeah, that thing has the advantage sheer numbers of cores [18:02:50 CEST] <alexpigment> *advantage of [18:03:23 CEST] <alexpigment> it's interesting to think that the new AMD chips might actually have the most use for video encoding :) [18:03:35 CEST] <alexpigment> their weakest area up until this point [18:03:53 CEST] <furq> BtbN: is it any good [18:03:58 CEST] <BtbN> I'd imagine a 16 core FX chip to be also quite decent for it [18:03:59 CEST] <thebombzen> furq: lol it says "enable main12 instead of main10" [18:04:07 CEST] <thebombzen> doesn't sound like it supports multiple bit depths [18:04:13 CEST] <furq> er [18:04:21 CEST] <furq> you should just need to build it with -DHIGH_BIT_DEPTH=YES [18:04:57 CEST] <kepstin> i think you actually have to build it multiple times, then do some extra step to link them all together? not sure [18:05:25 CEST] <BtbN> furq, it's not the "gaming monster" some people expected. Apparently that's enough for people to shit on it. [18:05:44 CEST] <BtbN> But an 8 core that can easily hit 3.8-4GHz, for that price, is more than decent. [18:06:29 CEST] <furq> yeah it's like half the price of the equivalent i7 isn't it [18:06:38 CEST] <furq> i'm not sure why people were expecting them to beat it all ends up [18:07:05 CEST] <BtbN> The platform itself has some nasty stability issues, which I hope AGESA and BIOS updates will address. [18:07:19 CEST] <furq> is that just the FMA3 erratum or is there more [18:07:26 CEST] <kepstin> it's rather tempting over a xeon chip for a workstation, other than the trickiness of finding a motherboard with working ecc ram [18:07:41 CEST] <kepstin> there's already a microcode update (bios upgrade) for the fma3 thing, iirc? [18:07:41 CEST] <thebombzen> so if you enable HIGH_BIT_DEPTH will it support 8bit AND 10bit? [18:07:46 CEST] <furq> yeah there is [18:08:01 CEST] <BtbN> It's quite hard to figure out what is going on with the Microcode [18:08:31 CEST] <BtbN> Like, I know which version I'm on, but no idea if that already has the fix [18:08:37 CEST] <kepstin> thebombzen: no, it's more complicated than that. each build of x265 gives a library that supports only one bit depth [18:08:54 CEST] <thebombzen> okay you're contradicting furq then [18:09:10 CEST] <thebombzen> actually you're contradicting yourself [18:09:13 CEST] <furq> i mean that's not my understanding but i've never actually used high bit depth [18:09:21 CEST] <thebombzen> [12:01:50] <thebombzen> also I noticed it says "x265 8bit" [18:09:21 CEST] <thebombzen> [12:02:02] <thebombzen> can x265 do more than one bit depth per library [18:09:21 CEST] <thebombzen> [12:02:09] <thebombzen> which is probably the biggest limitation of x264 [18:09:21 CEST] <thebombzen> [12:02:10] <kepstin> thebombzen: yes, if compiled correctly [18:09:22 CEST] <furq> trust someone who has over me [18:09:27 CEST] <kepstin> it looks like you can parallel install multiple x265 builds, and it'll dynamically reload one with the correct bit depth, or you can build x265 multiple times and link them into a single library [18:09:30 CEST] <BtbN> you have to to kind of a 4-pass-build to get all 3 bit depths [18:09:42 CEST] <thebombzen> kepstin: what [18:09:44 CEST] <thebombzen> how does that even work [18:09:51 CEST] <furq> i did always wonder why high bit depth wasn't the default if it supported multiple [18:09:54 CEST] <furq> i guess that answers my question [18:09:57 CEST] <kepstin> https://x265.readthedocs.io/en/default/api.html#build-implications [18:10:02 CEST] <BtbN> with a wrapper-library that redirects to the correct bit-depths version depending on the parameters. [18:11:23 CEST] <thebombzen> kepstin: I just read that and it doesn't actually say how to do this [18:11:26 CEST] <thebombzen> it only says that it's possible [18:12:00 CEST] <thebombzen> "In this way you can build one or more libx265 libraries without any exported C interface and link them into a libx265 build that does export a C interface. The build which exported the C functions becomes the default bit depth for the combined library, and the other bit depths are available via the bit-depth introspection methods." [18:12:06 CEST] <thebombzen> which it proceeds to NOT tell you how to do [18:12:08 CEST] <BtbN> by doing quite exactly that [18:12:22 CEST] <BtbN> you build the 2 other static libraries with the C interface disabled [18:12:32 CEST] <thebombzen> and do you make install them? [18:12:33 CEST] <BtbN> and then build the default one normally, but link in those two other static libraries. [18:12:47 CEST] <thebombzen> and how do you link in those other two? with the EXTRA_LIBS options? [18:12:57 CEST] <BtbN> With whatever way to link in stuff their build system offers [18:13:06 CEST] <BtbN> If all else fails, by invoking the linker manually [18:13:09 CEST] <kepstin> thebombzen: the exherbo package does it by doing the final link manually: http://git.exherbo.org/media.git/tree/packages/media-libs/x265/x265-2.3.exh… [18:13:28 CEST] <kepstin> looks like they have a shell script 'multilib.sh' which does the work for you when building manually? [18:14:35 CEST] <kepstin> https://bitbucket.org/multicoreware/x265/src/6e1edafd6dc767ae84c93bca2ff971… there it is [18:15:49 CEST] <alexpigment> sorry, just skimming above. does this wrapper library redirection work on Windows, or is this just a *nix thing? [18:16:48 CEST] <kepstin> windows: https://bitbucket.org/multicoreware/x265/src/6e1edafd6dc767ae84c93bca2ff971… [18:17:21 CEST] <alexpigment> ah, this is going to be incompatible with my cross compiling setup [18:17:53 CEST] <alexpigment> i guess if i'm cross compiling for windows on linux, i need to do some more research and possibly (read: definitely) get in over my head ;) [18:18:06 CEST] <kepstin> it looks like they have an msys version too, which is probably more like what a cross compile would look like [18:18:33 CEST] <alexpigment> but this is exactly what i've been needing, because i'm working with two separate copies of FFMPEG on Windows at the moment, and it's less than ideal [18:18:35 CEST] <BtbN> I don't see how cross compiling or building on/for windows would change anything. [18:18:37 CEST] <kepstin> I think it's actually very similar to the linux build [18:19:11 CEST] <alexpigment> i just looked at the Visual Studio 12 references, so i assumed it's specific to Visual Studio [18:19:39 CEST] <kepstin> alexpigment: yes, because that's the file in the vc12 directory. feel free to poke around in the source tree yourself :) [18:19:46 CEST] <BtbN> well, obviously the compiler and linker invocations change [18:19:50 CEST] <BtbN> but the general concept is identical [18:20:15 CEST] <alexpigment> k, i'll have to look into the build script i'm using a bit [18:20:34 CEST] <alexpigment> great to hear this though. i was thinking it wasn't possible to have multi-bit-depth in x265 up until now [18:20:55 CEST] <alexpigment> or rather, in ffmpeg [18:25:43 CEST] <thebombzen> yea I tried that [18:25:48 CEST] <thebombzen> it didn't work, it still always forces 8bit [18:26:42 CEST] <alexpigment> thebombzen: are you passing on the correct pix_fmt and/or profile? [18:26:50 CEST] <Tom_B> Why doesn't this respect hls_time 2, I'm getting the default 10s segments: ffmpeg -hwaccel cuvid -deint adaptive -i INPUT -hls_time 2 -hls_list_size 30 -hls_flags delete_segments -map 0:v:0 -map m:language:eng -c:v h264_nvenc -profile:v high -pixel_format yuv444p -level 5 -qp 20 -preset slow -sn playlist.m3u8 [18:26:51 CEST] <thebombzen> explicitly setting -pix_fmt yes [18:27:22 CEST] <thebombzen> Incompatible pixel format 'yuv420p10le' for codec 'libx265', auto-selecting format 'yuv420p' [18:27:25 CEST] <alexpigment> does it give you any warnings when you try to pass on yuv420p10le? [18:27:28 CEST] <alexpigment> yeah [18:27:28 CEST] <thebombzen> ^ [18:27:32 CEST] <alexpigment> have seen that error many times [18:28:05 CEST] <thebombzen> I'll have to investigate it later [18:28:09 CEST] <thebombzen> when I don't have class at 1pm [18:28:30 CEST] <alexpigment> thebombzen, it might also be worth trying x264 at some point [18:28:43 CEST] <alexpigment> just make sure it's not a problem specific to x265 rather than x264 [18:28:58 CEST] <thebombzen> it's very clearly not a problem specific to x265 [18:28:59 CEST] <alexpigment> (both of which don't allow multi-bit-depth on my end) [18:29:09 CEST] <thebombzen> the whole point of what I was trying was to get multiple bit depths to work in x265 [18:29:20 CEST] <alexpigment> k, i figured i'd just check since it sounds like you built with the workaround above [18:29:20 CEST] <thebombzen> like it's literally the purpose of this conversation [18:29:28 CEST] <thebombzen> so [18:29:55 CEST] <alexpigment> er, maybe i'm wrong. did you just now report this after following the instructions that kepstin listed above? [18:30:05 CEST] <thebombzen> yes [18:30:08 CEST] <alexpigment> k [18:30:22 CEST] <thebombzen> but you're trying to ask if the problem is specific to x265 and suggested I try x264 [18:30:27 CEST] <alexpigment> well, i'm going to look into trying this today, and i'll let you know if my results are different [18:30:30 CEST] <thebombzen> which is a bit of stupid suggestion [18:30:40 CEST] <thebombzen> because the problem WILL occur with x264 [18:30:49 CEST] <thebombzen> it's one of its major limitations [18:30:58 CEST] <kepstin> x264 does have some outstanding patches for multi bit depth support [18:31:00 CEST] <alexpigment> sorry, when i do my builds, i always make x264 and x265 the same bit depth [18:31:06 CEST] <kepstin> i should check the status of that again :) [18:31:10 CEST] <thebombzen> kepstin: do you mean they're phenomenal [18:31:22 CEST] <thebombzen> or do you mean they're not committed to master [18:31:29 CEST] <thebombzen> by "outstanding" [18:33:20 CEST] <kepstin> they've commited at least some of the work which adds prefixes to symbols [18:33:36 CEST] <kepstin> i think [18:35:38 CEST] <kepstin> still ongoing discussion about the big multi bit depth patch set [19:16:59 CEST] <Tom_B> none of the -hls_ options seem to be being applied, do I need to include them at a particular point in ffmpeg launch command? [19:17:11 CEST] <c_14> before the output they apply to [19:17:24 CEST] <c_14> and after any input/output they shouldn't apply to [19:19:24 CEST] <ronak> hy [19:19:40 CEST] <ronak> i am nwe for this [19:19:45 CEST] <ronak> new [19:22:01 CEST] <Tom_B> here's my full command: ffmpeg -threads 2 -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -i INPUT -vf hqdn3d=4.0:3.0:6.0:4.5,yadif,format=nv12,hwupload -map 0:v:0 -map m:language:eng -y -vcodec h264_vaapi -qp 15 -sn -hls_init_time 0.5 -hls_time 2 -hls_list_size 50 -hls_flags delete_segments out.m3u8 [19:22:22 CEST] <Tom_B> I'm getting 5 second segments and the number of segments seems to grown identinely [19:24:08 CEST] <ronak> hy [19:24:35 CEST] <c_14> (your command output) [19:24:43 CEST] <ronak> i am new for this [19:25:13 CEST] <c_14> ronak: do you have a question? [19:29:06 CEST] <Tom_B> c_14: here: https://pastebin.com/AXL0uGbg it works but it seems all -hls options are ignored. [19:30:49 CEST] <c_14> hmm [19:30:52 CEST] <c_14> again with -v debug ? [19:35:37 CEST] <Tom_B> it's very long but here's the debug output: https://gist.github.com/TomBZombie/29d900c5ef4b7fd247188bc9ffef103c [19:37:24 CEST] <Tom_B> actually hls_lis_size is having an effect, but not what I expected. I set it to 5 for testing... I get 13 .ts files [19:37:56 CEST] <c_14> yeah [19:38:00 CEST] <c_14> sounds about right [19:38:10 CEST] <c_14> though I think it should be 10/11 [19:38:53 CEST] <Tom_B> hmm, is hls_size limited by the input or output codec? I'm sure it was correctly giving 2 seconds before I started trying to use vaapi [19:39:07 CEST] <c_14> it only cuts on gops [19:39:11 CEST] <c_14> so that could be an issue [19:42:11 CEST] <Tom_B> ah, alright. The only annoying thing about that is that I can't start watching the video until the first file has been written, hence the lower hls_init_time, is it possible to change gop rate for h264_vaapi? [19:42:35 CEST] <c_14> probably [19:42:37 CEST] <c_14> try setting -g [19:45:28 CEST] <Tom_B> ah, yes -g 30 has done it thanks :) [19:46:57 CEST] <BtbN> c_14, it will do 2*list_length+3 iirc [19:47:02 CEST] <BtbN> so 13 is exactly right [19:47:29 CEST] <c_14> I thought it was just 2*length +- 1 [19:48:10 CEST] <BtbN> if a player downloads the playlist, and start downloading the last 3 files in real time, the +3 might be needed in edge cases [19:48:39 CEST] <BtbN> or rather, the entire list in real time, in reverse order, or something stupid like that [19:49:47 CEST] <pbos> Are there good x264 CBR one-pass command-lines? [19:49:55 CEST] <pbos> (for realtime) [19:50:10 CEST] <BtbN> x264 only supports abr [19:51:12 CEST] <pbos> abr with a low buffer size ~= cbr? [19:51:19 CEST] <alexpigment> kepstin: thanks again for helping me figure out CBR earlier. I also just now discovered why it wasn't working for me. out of habit, i often use -maxrate and -bufsize rather than vbv-maxrate and vbv-bufsize, because for x264, those parameters were passed on. that doesn't appear to be true in this case, so it was failing until i tried again with vbv-maxrate and vbv-bufsize in the x265-params. [19:51:19 CEST] <alexpigment> things like this are going to take a while to remember, but I suppose I'll just have to remember to always use x265-params from nowon [19:51:32 CEST] <alexpigment> pbos, i have a trick for it somewhere [19:51:34 CEST] <alexpigment> lemme see [19:52:01 CEST] <kepstin> alexpigment: yeah, very few of the x265 params are mapped to ffmpeg options - in fact, there's bitrate, crf, and... that's about it [19:52:03 CEST] <pbos> thanks, I'm looking for a fair comparison between x264 "realtime" and openh264 settings [19:52:18 CEST] <pbos> if the answer is just "pfft, don't use x264 for realtime", let me know :p [19:52:21 CEST] <alexpigment> pbos: i was using -nal-hrd-cbr according to my notes [19:52:24 CEST] <BtbN> openh264 can only do baseline, so x264 will crush it. [19:52:42 CEST] <kepstin> pbos: i'd expect x264 to do rather better at realtime than openh264 in most circumstances [19:53:10 CEST] <BtbN> the only reason openh264 exist is the licensing-workaround cisco pulled [19:54:04 CEST] <TD-Linux> would be interesting to see. I don't think many people use x264 for realtime [19:54:14 CEST] <kepstin> i kinda wish cisco had just done their license blessing workaround on an x264 build rather than their own library, but i guess they didn't want to have GPL stuff. [19:54:23 CEST] <alexpigment> pbos: more in my notes: to get CBR, i used -b:v XXXX, vbv-maxrate=XXXX, vbv-maxrate=XXXX then the -nal-hrd-cbr flag. this was a while back, so i don't recall how CBR-y it was [19:54:32 CEST] <atomnuker> TD-Linux: everyone and their dog uses x264 for realtime [19:55:05 CEST] <BtbN> TD-Linux, everyone using OBS or XSplit does... [19:55:09 CEST] <TD-Linux> atomnuker, for 1-frame latency? I know it has a single frame delta q rate control but I had never seen it usd in practice [19:55:22 CEST] <BtbN> Nobody cares about 1 frame latency [19:55:33 CEST] <TD-Linux> oh that's what I interpreted 1 frame latency as [19:55:36 CEST] <TD-Linux> *realtime [19:55:36 CEST] <alexpigment> BtbN: actually a lot of people are using NVENC these days due to hardware limitations on their laptops ;) [19:55:38 CEST] <kepstin> TD-Linux: if you need 1-frame latency, just use tune=zerolatency, tada. [19:55:39 CEST] <pbos> kepstin: I need rate control to behave though, hence the CBR issue :) [19:55:50 CEST] <TD-Linux> this ^ [19:55:53 CEST] <pbos> alexpigment: Thanks [19:55:55 CEST] <atomnuker> x264 won't overshoot [19:55:56 CEST] <alexpigment> np [19:56:02 CEST] <kepstin> pbos: you actually need padded cbr? [19:56:03 CEST] <BtbN> alexpigment, well, that's what happens when you want to stream on shitty hardware. Results in a stream with questionable visual quality. [19:56:13 CEST] <TD-Linux> atomnuker, with the buffer size being one frame long? [19:56:18 CEST] <pbos> kepstin: Nah [19:56:31 CEST] <alexpigment> BtbN - you're preaching to the choir. having said that, i don't personally stream, so it doesn't affect me personally [19:56:43 CEST] <BtbN> Well, it doesn't affect the streamer. [19:56:46 CEST] <BtbN> Just the viewers. [19:56:51 CEST] <kepstin> pbos: then you don't need cbr at all, you want limited vbr (i.e. either crf more or abr mode with vbv limits) [19:56:53 CEST] <alexpigment> yeah that's true ;) [19:57:08 CEST] <alexpigment> +1 kepstin [19:57:11 CEST] <pbos> kepstin: Thanks, I'm learning as I go [19:57:23 CEST] <atomnuker> TD-Linux: pretty much, even with slice threading [19:57:36 CEST] <BtbN> x264 can and will drop way below the desired bitrate if there is nothing to fill it with [19:57:37 CEST] <alexpigment> i personally use CRF + maxrate + bufsize when doing streaming encodes [19:57:42 CEST] <BtbN> Which is undesireable for live streaming. [19:58:03 CEST] <atomnuker> (it denoises based on quantizers) [19:58:08 CEST] <kepstin> some online streaming stuff (twitch specifically) does want padded cbr so the bitrate remains constant, to avoid issues with tcp [19:58:20 CEST] <BtbN> You can turn on padding with some x264-param or something [19:58:24 CEST] <kepstin> yeah [19:58:33 CEST] <alexpigment> -nal-cbr-hrd is the padding, right? [19:58:46 CEST] <alexpigment> er [19:58:47 CEST] <alexpigment> haha [19:58:50 CEST] <pbos> kepstin: For WebRTC we can do padding outside the codec. [19:58:52 CEST] <alexpigment> -nal-hrd-cbr [19:59:09 CEST] <BtbN> well, it's basically one line to enable it, so might as well [19:59:15 CEST] <pbos> I'm mostly interested in avoiding significant frame spikes [19:59:35 CEST] <BtbN> the vbv buffer size defines the maximum spike you can possibly see [19:59:37 CEST] <kepstin> pbos: yeah, iirc rtp has that builtin? or at least the dtls stuff allows it [19:59:54 CEST] <kepstin> if you want to completely avoid frame spikes, then intra-refresh mode is where it's at [19:59:55 CEST] <pbos> kepstin: IIRC RTP pads up to 255 bytes per packet [20:00:00 CEST] <pbos> or something like that [20:00:19 CEST] <pbos> Normally I turn off periodic intra frames [20:00:33 CEST] <TD-Linux> webrtc uses udp so you don't want padding [20:00:38 CEST] <pbos> we send nack/pli/fir [20:00:50 CEST] <BtbN> turning off I frames with UDP seems like a bad idea [20:00:54 CEST] <pbos> We pad for BWE purposes sometimes [20:00:59 CEST] <TD-Linux> BtbN, no, it's actually standard [20:01:06 CEST] <pbos> or add stream resilience by sending redundant data [20:01:11 CEST] <TD-Linux> if you want an I frame you request one with RTCP [20:01:12 CEST] <BtbN> So if a package is lost, you just start over...? [20:01:17 CEST] <TD-Linux> BtbN, no you request one [20:01:19 CEST] <kepstin> TD-Linux: for encrypted stuff, it's sometimes desireable to pad, because compressed frame size leaks info [20:01:37 CEST] <kepstin> but that's not done for most webrtc media [20:01:40 CEST] <BtbN> But doesn't the quality degrade over time if you never throw in an occasional I frame? [20:01:42 CEST] <TD-Linux> yeah, and more common for audio [20:01:46 CEST] <TD-Linux> BtbN, nope. [20:01:59 CEST] <pbos> BtbN: rtcp will nack missing packets or request a new frame [20:02:07 CEST] <BtbN> Applying Delta to Delta has to result in degration over time oO [20:02:08 CEST] <pbos> i-frame degrades quality generally [20:02:09 CEST] <kepstin> the video encoder sends enough info in each predicted frame to maintain the desired level of quality... [20:02:20 CEST] <TD-Linux> BtbN, nope, because decoders have exact reconstruction [20:02:25 CEST] <TD-Linux> there is no drift [20:02:26 CEST] <pbos> because it removes prediction capabilities [20:02:40 CEST] <pbos> so you can't maintain the same quality without huge bitrate spikes [20:02:43 CEST] <kepstin> sending I frames is problematic because it eats a v. large chunk of your vbv buffer, so you often have to send it at lower quality than the predicted frames [20:02:48 CEST] <pbos> generally delta frames just improve quality over time [20:03:15 CEST] <kepstin> if you see a live stream where the quality drops every x frames, that's an issue with keyframes not getting enough bitrate, then predicted frames recovering the quality [20:05:23 CEST] <pbos> BtbN: http://i.imgur.com/hQVymJo.png [20:05:53 CEST] <pbos> vp8 keyframes are significantly worse quality and then improve over time [20:06:02 CEST] <pbos> openh264 likely overshoots significantly in the beginning there [20:06:16 CEST] <pbos> (but I don't have per-frame size metrics for h264 decoding yet) [20:06:18 CEST] <TD-Linux> I see a flat line for openh264 rate? [20:06:19 CEST] <TD-Linux> ok [20:06:44 CEST] <TD-Linux> yes the only way to avoid that overshoot is to either reencode the first frame or use sub frame rate contorl [20:06:50 CEST] <TD-Linux> vp8 does the former, openh264 does the latter [20:07:32 CEST] <BtbN> shouldn't starting with a not completely filled vbv-buffer prevent it? [20:07:49 CEST] <TD-Linux> if your buffer is sufficiently large [20:08:36 CEST] <pbos> And if you do, it'll blow out any realtime end-to-end latency. [20:08:44 CEST] <pbos> Given a limited throughput, ofc. [20:09:44 CEST] <pbos> Or packet loss up the wazoo. [20:16:05 CEST] <pbos> alexpigment: you specified vbx-maxrate twice, was there any other flag you wanted in there? [20:29:13 CEST] <Justin_> If someone gets a chance, please take a look at this question I posted: https://superuser.com/questions/1192999/ffmpeg-how-can-i-use-the-last-frame… [20:31:44 CEST] <durandal_1707> Justin_: crossfade with zoompan? just transformation after last frame? [20:32:35 CEST] <Justin_> Yes, or continue zoompan through the crossfade. either option is fine. [20:32:57 CEST] <Justin_> ther ewill be up to 25 images i nteh slideshow [21:16:41 CEST] <alexpigment> pbos: sorry i just saw your question. try -b:v [your bitrate] -nal-hrd cbr -x264opts vbv-maxrate=[your bitrate]:vbv-bufsize=[your bitrate] [21:17:15 CEST] <thebombzen> does anyone know an easy way to get zoompan math working? i.e. suppose I have a video and I have an w:h:x:y that I could feed to -vf crop [21:17:37 CEST] <thebombzen> I couldn't find an easy way to zoom in on that particular rectangle [21:17:42 CEST] <thebombzen> at a linear rate with zoompan [21:19:06 CEST] <alexpigment> pbos: also note that -b:v can be in bytes (e.g. 20000000 for 20mbps), but vbv-maxrate and vbv-bufsize must be written in kilobytes (e.g. 20000 for 20mbps) [21:19:45 CEST] <furq> no those are both in kbit [21:19:54 CEST] <alexpigment> furq? [21:20:02 CEST] <furq> and bitrate is also in bits, obviously [21:20:47 CEST] <alexpigment> sorry, i meant *bits* up there obviously, but -b:v is definitely in bits unless you specify K or M [21:20:58 CEST] <furq> yeah i meant the vbv options are both in kbit [21:21:01 CEST] <furq> bitrate is in bits [21:21:32 CEST] <alexpigment> oh, nm. i thought you were saying -b:v and vbv-maxrate and vbv-bufsize were all in kbit [21:21:41 CEST] <alexpigment> you're just saying kbit vs kilobytes [21:21:53 CEST] <alexpigment> in which yeah, yeah, my bad [21:22:24 CEST] <alexpigment> point was really just to point out that you can't use the same numbers for all of them unless you define the bitrate in the x264opts [21:22:54 CEST] <kepstin> alexpigment: all ffmpeg options take bits, but if you're using -x264opts/-x264-params or -x256-params it's up to what the x264/x265 library takes [21:23:10 CEST] <alexpigment> yes, in which case x264opts take kbit [21:23:16 CEST] <alexpigment> which is all i was trying to point out [21:23:57 CEST] <alexpigment> i think i'm missing something that both of you guys are saying though :) [21:24:03 CEST] <kepstin> yep, but with x264, the -bufsize and -maxrate options are mapped, so you don't have to use -x264opts [21:24:13 CEST] <thebombzen> kepstin: I tried it manually but apparently I was missing -DLINKED_10BIT and -DLINKED_12BIT that it uses in ./mulitlib.sh [21:24:19 CEST] <alexpigment> right - i historically used bufsize and maxrate [21:24:24 CEST] <thebombzen> so I'm just running ./multilib.sh and seeing what happens [21:24:33 CEST] <alexpigment> but as i alluded to earlier today, that bit me in the ass with x265. today is the day i stop doing that ;) [21:25:25 CEST] <thebombzen> alexpigment: yes be careful with that [21:25:52 CEST] <thebombzen> if you use -bufsize you provide bps but if you use -x264-opts vbv-bufsize you provde kbps [21:26:00 CEST] <alexpigment> yes [21:26:05 CEST] <thebombzen> this has dinged me on a number of occasions [21:26:06 CEST] <alexpigment> that's exactly what i said up above [21:26:20 CEST] <thebombzen> yes it is, I'm seconding it [21:26:27 CEST] <thebombzen> saying that I have too suffered from this [21:26:35 CEST] <alexpigment> oh yeah [21:26:58 CEST] <kepstin> i wonder if the x265 api is stable enough nowadays that it might make sense to start mapping more ffmpeg options [21:27:01 CEST] <alexpigment> but as a person who switches between x264 and x265 a lot, i need to make sure and forget that bufsize and maxrate exist ;) [21:27:27 CEST] <alexpigment> kepstin: well, it will sure help a lot of people moving from x264 to x265 [21:27:45 CEST] <kepstin> then again, using x264 with ffmpeg is kind of confusing, because it's hard to tell which ffmpeg options it uses and which it ignores [21:27:48 CEST] <alexpigment> i almost didn't notice initially that -g doesn't map to keyint [21:28:50 CEST] <alexpigment> i just don't understand why x265 parameters can't just map back to same-named ffmpeg parameters [21:28:53 CEST] <kepstin> (and ffmpeg -h encoder=libx264 only lists encoder-specific avoptions, doesn't include the global stuff) [21:29:09 CEST] <alexpigment> i realize that's kinda weird, but i'd love to just type out things without having to use -x265-params all the time [21:29:23 CEST] <kepstin> alexpigment: they could, but someone would have to go and add avoptions for all the things. [21:30:07 CEST] <alexpigment> i don't know anything about modifying and submitting source code, but that seems like it would only take a day of work [21:30:52 CEST] <kepstin> well, adding them it's the hard part, it's keeping the list up to date and matching that's tricky - then you have to worry about different x265 versions maybe having different supported options [21:31:00 CEST] <kepstin> adding them isn't the hard part* [21:32:05 CEST] <kepstin> i assume that when the libx265 wrapper was added, it was fairly early in the x265 dev, and they weren't sure how stable the options were gonna be, so a minimal wrapper was done with the ability to use arbitrary extra options with -x265-params [21:32:22 CEST] <kepstin> but yeah, at least adding support for stuff like -g would be a good start :) [21:32:42 CEST] <alexpigment> well taking that one step further, why not add -keyint? [21:32:55 CEST] <alexpigment> (either in addition or in place of -g) [21:33:37 CEST] <alexpigment> the problem historically with x264 is that you find documentation online for either ffmpeg options or x264 options, and for novices, it's difficult to know how to handle those [21:33:51 CEST] <kepstin> but then there's a duplicate option that only works on one codec... unless you mean add it as a global alias to the ffmpeg cli tool? [21:33:53 CEST] <alexpigment> fortunately someone made a really nice translation wiki online that i reference a lot [21:34:29 CEST] <alexpigment> kepstin, i don't think i mind it working only on one codec. a lot of options don't translate from codec to codec anyway [21:35:22 CEST] <alexpigment> my main problem is that it's visually hard to parse a command line where -x265-params is packed and only separated with colons [21:35:37 CEST] <alexpigment> and that is currently very much the case with x265 [21:35:45 CEST] <kepstin> i suspect this discussion about using global parameters vs codec avoptions is the other reason why nobody has mapped the x265 options :) [21:35:52 CEST] <alexpigment> haha [21:36:14 CEST] <kepstin> the global parameters are nice for libavcodec api users, because it's a consistent api for different codecs [21:36:31 CEST] <alexpigment> seriously though, don't you think it'd be cleaner if you looked at the x265 documentation and were able to just drop a hyphen to map it on your ffmpeg command line? [21:37:22 CEST] <alexpigment> -crf 18 -vbv-maxrate 20000 -vbv-bufsize 20000 -keyint 60 [21:37:22 CEST] <alexpigment> etc [21:37:41 CEST] <kepstin> no, i think it would be cleaner if I can swap out x264 with x265 with the same options and get similar behaviour :) [21:38:37 CEST] <alexpigment> well i guess that makes me in favor of doing the same for x264, although i care less about that cause because most things can be done through ffmpeg commands rather than x264opts [21:38:38 CEST] <kepstin> that said, only if they actually do the same thing. I'm still kind of annoyed with how libvpx's cq mode got mapped to the crf option on ffmpeg. [21:39:26 CEST] <alexpigment> kepstin: yeah, except that it's completely useless unless you specify a maxrate, right? [21:39:37 CEST] <alexpigment> rather [21:39:53 CEST] <kepstin> well, they fixed that in vp9 at least [21:39:57 CEST] <alexpigment> more comically, *if you don't specify a -b:v which functions as a maxrate* [21:40:24 CEST] <kepstin> but unlike x264/x265, you actually get the best result with libvpx if you do a 2-pass encode with cq mode [21:40:33 CEST] <kepstin> which is... kinda strange [21:40:38 CEST] <alexpigment> weird [21:41:27 CEST] <alexpigment> i don't know what that even implies about vp8 [21:42:07 CEST] <alexpigment> still, vp9 is all good and all, but vp8 is just a fallback for HTML5 to me. i have no other reason to use vpx codecs [21:42:09 CEST] <kepstin> cq mode in vp8 was designed as an enhancement for abr rate control to cause it lower the bitrate below the abr setting if the content wasn't complex enough to warrant using all the rate [21:42:30 CEST] <kepstin> mostly to save bandwidth and storage on youtube [21:42:55 CEST] <alexpigment> kepstin: so how much of a difference is there in 1-pass vs 2-pass? [21:43:03 CEST] <alexpigment> i mean is it very significant? [21:43:38 CEST] <kepstin> alexpigment: the vp8 single-pass rate control isn't very good, and cq mode still uses the abr rate control for the most part :/ [21:44:07 CEST] <kepstin> by "isn't very good", i mean.. it hits the bitrate targets more or less, but it's used for realtime stuff (webrtc), not quality batch encoding [21:44:23 CEST] <alexpigment> gotcha [21:44:34 CEST] <alexpigment> again, i still use it strictly as a fallback. i could care less about it ;) [21:44:59 CEST] <alexpigment> basically if you're using Firefox on Windows XP, you get the quality you get [21:45:04 CEST] <kepstin> hmm. at this point, i don't think there's much reason to use vp8 as a fallback for anything [21:45:15 CEST] <kepstin> unless you care about those ff on xp users, i guess :/ [21:45:32 CEST] <alexpigment> well, they do exist [21:45:34 CEST] <alexpigment> somehow [21:45:39 CEST] <kepstin> vp9 gives better results for just about everything, and isn't really any slower than vp8 to encode. [21:45:55 CEST] <alexpigment> i assumed it was slower to decode [21:46:07 CEST] <alexpigment> if it's on par with h.264 [21:47:09 CEST] <alexpigment> after all, as a fallback for *xp users* in my usage, those slight differences are going to be amplified [21:47:34 CEST] <alexpigment> potentially pentium 3 era hardware [21:48:08 CEST] <thebombzen> kepstin: what? [21:48:14 CEST] <thebombzen> vp9 is much much slower than vp8 [21:48:37 CEST] <kepstin> hmm, isn't firefox 45 new enough that it should be able to do h264 decoding on xp? [21:48:43 CEST] <kepstin> or is there some weird limitations with that? [21:48:55 CEST] <furq> firefox has had h264 since 30something [21:49:06 CEST] <alexpigment> kepstin, pretty sure firefox avoided paying MPEG-LA by decoding with the system codecs [21:49:10 CEST] <kepstin> thebombzen: with some testing I've done, you can easily get vp9 to encode as fast as vp8 with better quality [21:49:23 CEST] <kerio> can ffmpeg mux fragmented isobmff? [21:49:28 CEST] <kepstin> (although I haven't done any faster-than-realtime stuff) [21:50:07 CEST] <alexpigment> furq: source? i'd love to get rid of the fallback tbh [21:50:15 CEST] <furq> i don't know for sure about xp [21:50:40 CEST] <alexpigment> yeah, it's the one exception because it doesn't ship with an H264 decoder on the system [21:51:36 CEST] <alexpigment> https://www.wired.com/2013/01/mozilla-brings-native-h-264-to-firefox-nightl… "Eventually all platforms except Windows XP will get OS-native codec support for H.264 video. Windows XP, which lacks OS-level tools for H.264, will continue to use the Flash plugin to play H.264 movies." [21:51:42 CEST] <kepstin> i don't even want to install xp on something to test it. [21:52:01 CEST] <thebombzen> kepstin: is that just because vp8 is slow as fuck or something? [21:52:14 CEST] <kepstin> thebombzen: libvpx encoder is, yes [21:52:16 CEST] <alexpigment> kepstin, i have a machine around here, but i'd rather not drag it out and fire it up unless someone has some information that is contrary to what was true a year ago [21:52:26 CEST] <thebombzen> kepstin: so if libvpx-vp8 is slow as fuck [21:52:31 CEST] <thebombzen> why not just use x264 [21:52:33 CEST] <furq> i was going to say maybe baseline would work with openh264 [21:52:40 CEST] <thebombzen> which in that case is far faster than vp8 and vp8 [21:52:41 CEST] <furq> but there's still no aac support [21:52:50 CEST] <thebombzen> also what is openh264 [21:52:57 CEST] <thebombzen> is there any reason to not just use avcodec's h.264 decoder [21:52:57 CEST] <furq> cisco's h264 implementation [21:53:15 CEST] <furq> firefox uses it for webrtc [21:53:15 CEST] <furq> the reason to use it is because it's free to use [21:53:15 CEST] <alexpigment> thebombzen: openH264 is cisco's version that only supports baseline [21:53:33 CEST] <furq> which is good if you want to ship an h264 encoder [21:54:03 CEST] <alexpigment> "come on, Cisco, at least give us Main profile" ;) [21:54:47 CEST] <furq> well that's probably important to know about xp anyway [21:54:50 CEST] <TD-Linux> most of the legacy equipment that it needs to interoperate with only supports baseline [21:54:51 CEST] <furq> i assumed h264 would just work everywhere now [21:55:15 CEST] <furq> i'm in a position that i can just ignore xp users, but i've definitely wrongly told people in here that h264 works everywhere [21:55:22 CEST] <kepstin> the correct thing to do with xp users, if you're allowed to, is just say "well, that's just too bad. go away" [21:55:22 CEST] <furq> hopefully they can do the same ;_; [21:55:24 CEST] <TD-Linux> firefox and chrome default to vp8 if there is no h264 only endpoint [21:55:44 CEST] <alexpigment> yeah, but licensing is still a problem for browsers. most people just pay the max fee to MPEG-LA. Firefox can't really afford to do that since they don't have a good revenue stream like Google, Microsoft, Safari, etc [21:56:22 CEST] <alexpigment> rather, Apple, not Safari [21:56:57 CEST] <furq> i did always wonder who youtube's vp8 fallback was for [21:57:24 CEST] <alexpigment> it was Google/YouTube's way to push a standard out there that would potentially save them millions of dollars if it caught on [21:57:39 CEST] <furq> i meant the fact that youtube still has a vp8 fallback format for new videos [21:57:57 CEST] <alexpigment> oh gotcha [21:58:02 CEST] <alexpigment> it's still in there probably just for xp [21:58:06 CEST] <furq> yeah [21:58:27 CEST] <alexpigment> although i think when they initially had the fallback, it wasn't necessarily for xp [21:58:40 CEST] <alexpigment> it was what they were actively pushing on their H.265 player [21:58:56 CEST] <furq> you meant html there, right [21:58:57 CEST] <alexpigment> trying to break free from Adobe and MPEG-LA at the same time, i'd guess [21:59:05 CEST] <kepstin> have they improved the speed of their vp9 encodes yet? iirc they only popped up after a while, or after a video hit a certain number of views or something [21:59:07 CEST] <alexpigment> yeah, sorry. HTML5 [21:59:14 CEST] <furq> kepstin: it's still after 150 views in my experience [21:59:20 CEST] <furq> purely anecdotal though [21:59:45 CEST] <alexpigment> out of curiosity, what do people use VP9 for these days? [21:59:50 CEST] <kepstin> I wonder why they do that. I'm sure they could afford the compute to do the vp9 encodes immediately :/ [22:00:01 CEST] <TD-Linux> I think they are doing it more aggresively [22:00:07 CEST] <TD-Linux> I have private videos with <10 views that are vp9 [22:00:08 CEST] <furq> i expect >90% of videos end up with <150 views [22:00:21 CEST] <TD-Linux> maybe they just do extra videos when they have spare compute [22:00:23 CEST] <kepstin> alexpigment: google uses it for HD and especially 4K videos since hevc isn't an option [22:00:43 CEST] <furq> TD-Linux: maybe, i've not uploaded anything in a while [22:00:55 CEST] <furq> i have a ton of videos close to that mark and it was consistently at 150 [22:00:55 CEST] <TD-Linux> for HDR videos I think they only offer VP9 encodes, so uploading a HDR clip is probably a sure way to get VP9 [22:01:00 CEST] <furq> but these were uploaded about two years ago [22:01:12 CEST] <alexpigment> kepstin: they use it *additionally* for HD - are you saying it's exclusive for 4k? [22:01:29 CEST] <furq> there's still an h264 format at 4k [22:01:32 CEST] <TD-Linux> VP9's advantage over H.264 is larger at higher resolutions [22:02:00 CEST] <BtbN> VP9 for 4K sounds like fun, with the lack of broad hwaccel for it [22:02:08 CEST] <kepstin> my impression was that on desktops, they were planning to only serve 4K content to systems with vp9 support [22:02:16 CEST] <alexpigment> BtbN: exactly what I was thinking [22:02:18 CEST] <kepstin> (mostly to annoy apple into adding it?) [22:02:21 CEST] <TD-Linux> BtbN, it decodes in realtime in software on most machines with a 4k monitor [22:02:28 CEST] <furq> yeah vp9 decode is pretty quick [22:02:43 CEST] <furq> and it's not like you're going to be watching it on a phone [22:02:55 CEST] <TD-Linux> even if you did, most phones have hwaccel now [22:02:56 CEST] <BtbN> Oh, there are phones with a 4K screen [22:03:03 CEST] <alexpigment> furq: you never know. the "resolution" wars on phones is dumb but very much a real thing [22:03:09 CEST] <furq> i'm sure people have tried [22:03:13 CEST] <kepstin> looks like since about december 2016, google stopped encoding 4k videos in h264 [22:03:30 CEST] <furq> oh really [22:03:38 CEST] <furq> i'm not surprised tbh [22:03:43 CEST] <furq> the bitrate of the h264 4k was like 12mbit or something [22:04:00 CEST] <alexpigment> is vp9 that much better than h.264? [22:04:06 CEST] <furq> yeah [22:04:11 CEST] <alexpigment> or is it just better than youtube's H.264 encoder? [22:04:15 CEST] <furq> i've seen noticeable quality bumps on videos after the vp9 went live [22:04:21 CEST] <furq> i'd imagine youtube are using x264 [22:04:32 CEST] <kepstin> i don't see why they'd use anything else [22:04:33 CEST] <BtbN> I'd guess YouTube just uses libx264? But probably an ancient version, same as their ffmpeg [22:04:37 CEST] <alexpigment> furq: well, they sure as hell strip out the metadata on the videos, if i recall [22:04:42 CEST] <furq> they do [22:04:55 CEST] <kepstin> that said, as we've seen with crunchyroll, using x264 doesn't mean you're using it correctly ;) [22:04:59 CEST] <TD-Linux> their h.264 encodes are limited because they have to be compatible with a lot of buggy hw decoders [22:05:00 CEST] <furq> people in here seem pretty sure they're basically using ffmpeg from 2013-ish [22:05:15 CEST] <furq> but obviously patched to remove any identifying metadata [22:05:18 CEST] <alexpigment> youtube are definitely not using x264 with the best settings, that's for sure [22:05:22 CEST] <BtbN> iirc it was a heavily modified ffmpeg 0.10? [22:05:38 CEST] <furq> well my source for that is this channel, so shrug [22:05:44 CEST] <kepstin> iirc, you can narrow down which ffmpeg they're using by checking for supported decoder features when uploading videos [22:05:45 CEST] <furq> i didn't find it surprising though [22:06:10 CEST] <BtbN> I find it surprising they never bothered with updating, given all the new stuff that's supported [22:06:31 CEST] <furq> well it gives them a good technical excuse to not support h265 [22:06:41 CEST] <BtbN> I can see them not touching their encoders, but it shouldn't be too hard to convert to a common lossless intermediate, to profit from the new input formats [22:06:53 CEST] <kepstin> well, they've added vp9 support to their encoder pipeline... [22:07:11 CEST] <BtbN> I'd assume that to run on a more recent ffmpeg, alongside the old one [22:07:27 CEST] <kepstin> I assume they're doing encoding by segmenting the videos, farming out segments to compute workers, and reassembling after [22:07:59 CEST] <kepstin> that said, they have to at least be patching their decoding ffmpeg, I'm sure they've had a few code execution from uploaded video vulnerabilities to fix. [22:08:01 CEST] <BtbN> From my experience the encodes never seemed faster than what one machine could do [22:08:16 CEST] <TD-Linux> yes they segment encodes [22:08:26 CEST] <TD-Linux> and oh yes they are [22:08:35 CEST] <alexpigment> admittedly, it is very fast [22:08:38 CEST] <TD-Linux> at least for long videos [22:08:56 CEST] <BtbN> I very frequently had to wait 6-12 hours for my series of 6h uploads [22:09:06 CEST] <BtbN> for the first low-qualality to come up [22:09:10 CEST] <alexpigment> Vimeo, by comparison doesn't hide the fact that they use x264. i think they're using highly-multi-cored systems though. i seem to recall the thread count was 32 or something [22:09:12 CEST] <BtbN> the better qualities easily took days [22:09:27 CEST] <furq> how long ago was that [22:09:36 CEST] <BtbN> a good year [22:09:39 CEST] <furq> the one thing i can say for sure about youtube internals is that they're changing all the time [22:10:14 CEST] <kepstin> they definitely have a small number of encodes they do really quickly, and a a remaining set that's added later, if at all. [22:10:23 CEST] <furq> i've not uploaded anything other than 720p1 for like five years though [22:11:06 CEST] <kepstin> I should take a look at my videos, I've got a channel with short (mostly) 1080p videos uploaded once a week for a year now. [22:11:07 CEST] <alexpigment> the 1080p encodes definitely take a bit longer [22:11:21 CEST] <alexpigment> but usually within a few minutes in my experience [22:11:27 CEST] <furq> yeah i should probably upload a new batch [22:11:33 CEST] <alexpigment> it's not like it was 5 years ago where your 1080p video might not show up for a day or so [22:11:45 CEST] <furq> after all youtube is constantly telling me that my subscribers are eagerly waiting for regular content updates [22:12:00 CEST] <furq> i'm all about that content baby [22:12:00 CEST] <alexpigment> :) [22:12:08 CEST] <alexpigment> monetize [22:12:15 CEST] <furq> content is my middle name [22:12:28 CEST] <alexpigment> furq content furqson [22:13:57 CEST] <alexpigment> i guess i'm going to have to start doing some quality comparisons between vp9 and HEVC. i kinda just presumed vp9 wasn't worth using for any reason, but if it's better than H.264 at high resolutions... [22:14:41 CEST] <alexpigment> hell, if it's faster to encode than x265 and even 2/3 of the quality per bitrate, that's probably a win overall [22:14:55 CEST] <furq> it's not faster than x265 [22:15:03 CEST] <alexpigment> :( [22:15:10 CEST] <sikilikis> yo furq, remember me? [22:15:11 CEST] <alexpigment> well, you gave me some bad news, but you also saved me from some work [22:15:13 CEST] <furq> it's faster to decode, but there's less hwaccel support [22:15:32 CEST] <kepstin> alexpigment: main improvement for high-res stuff over h264 is that vp9 adds 64px superblocks, i think [22:15:50 CEST] <furq> sikilikis: hi [22:16:09 CEST] <alexpigment> kepstin: ah that does sound familiar [22:16:12 CEST] <sikilikis> dont worry, everything is still working, but i'm wondering if you guys can help me push out a few extra frames from the pi [22:16:14 CEST] <TD-Linux> and larger transforoms [22:16:38 CEST] <sikilikis> right now its looping a gif over and over with text overlay and the text is constantly updating [22:16:52 CEST] <sikilikis> only thing I've played around with is changing the source gif. The bigger the gif, the less fps [22:17:03 CEST] <sikilikis> so i'm limited by that. [22:17:43 CEST] <sikilikis> I'm wondering if rather than doing like "-ignore_loop 0 -i some_gif.gif" if it'd be faster to do "-loop 0 -i image%03.png" [22:17:56 CEST] <furq> are you using the pi's hardware encoder [22:18:10 CEST] <sikilikis> I am, though when I tested stuff using the hardware encoder didn't improve performance [22:18:19 CEST] <sikilikis> h264_omx [22:18:19 CEST] <furq> it should definitely be faster than x264 on a pi [22:18:23 CEST] <sikilikis> compared to libx264 [22:18:45 CEST] <alexpigment> decoding bottleneck? [22:18:48 CEST] <furq> maybe [22:18:51 CEST] <sikilikis> they both run about as fast as each other. I'm assuming it's because I'm creating video from a gif rather than just encoding an already existing mp4 video or something [22:18:54 CEST] <kepstin> if it's being limited by the decoder, it might make sense to use the loop filter rather than loop the decoding [22:18:59 CEST] <sikilikis> but that leads me to my next question [22:19:17 CEST] <furq> you could maybe try -i image%d.bmp if you want to avoid decoding [22:19:17 CEST] <sikilikis> if I turn the gif into an mp4 and then loop that, would it be better? [22:19:25 CEST] <furq> er [22:19:30 CEST] <furq> did you build with --enable-mmal [22:19:36 CEST] <furq> if you can hardware decode then that should help [22:19:40 CEST] <sikilikis> I believe I did but I don't remember [22:19:59 CEST] <kerio> do keep in mind that decoding and encoding with ffmpeg will not be as efficient as it could be [22:20:10 CEST] <sikilikis> and I didn't actually bother using it but I can try that. What do I need to add to my command? [22:20:30 CEST] <sikilikis> actually I should show you guys what my command is shouldnt I [22:20:43 CEST] <kerio> sikilikis: -c:v h264_mmal before -i [22:20:51 CEST] <kepstin> if you're doing extra video processing (like adding overlays), the decoded video has to be in cpu-accessible ram and stuff anyways - might even need some colorspace conversions [22:20:51 CEST] <thebombzen> everyone always boasts about the improvements of HEVC over H.264 (and likewise vp9 over vp8) for 4k and other huge resolutions [22:20:57 CEST] <thebombzen> but what about at 1080p [22:21:01 CEST] <alexpigment> you could also try ffmpeg -hwaccels to see what's available (if anything) [22:21:10 CEST] <thebombzen> which is still what a large amount of content will be at for a long time [22:21:35 CEST] <alexpigment> thebombzen: i personally see no point in using HEVC for 1080p [22:21:37 CEST] <kepstin> thebombzen: 1080p is small enough that the benefits from larger transforms is marginal. It can be better, but at the expense of more power needed to encode. [22:22:02 CEST] <thebombzen> what about extra intra directions? [22:22:07 CEST] <thebombzen> or are those only useful for large blocks [22:22:21 CEST] <sikilikis> lets say I dont use hardware decoding. Do you think using separate images would be faster than a gif? [22:22:26 CEST] <thebombzen> also I feel like 64x64 can be useful if there's like, a large sky [22:22:26 CEST] <sikilikis> its got to loop forever [22:22:38 CEST] <furq> i have no idea [22:22:38 CEST] <thebombzen> sikilikis: gif can be decoded very fast but it's also terrible [22:22:43 CEST] <thebombzen> and you should not use it if you can avoid it [22:22:52 CEST] <alexpigment> agree with bombzen re: terribility ;) [22:22:52 CEST] <sikilikis> terrible in what way? [22:22:59 CEST] <sikilikis> slow? bad quality? [22:23:02 CEST] <furq> are you scaling the image [22:23:03 CEST] <thebombzen> the visual quality of gifs is atrocious [22:23:05 CEST] <kepstin> sikilikis: show us your command? it might make sense to use the "loop" filter to loop the frames if there's not too many, that way they only get decoded once, then just stored in ram [22:23:10 CEST] <furq> if you are then prescaling to the right size will help a lot [22:23:17 CEST] <kepstin> and yeah, with gif source there's some colorspace conversion... [22:23:21 CEST] <sikilikis> yeah i'm on it. gotta get on my other computer [22:23:21 CEST] <thebombzen> first of all, gifs are posterized and panels are forced [22:23:23 CEST] <furq> and yeah that [22:23:36 CEST] <thebombzen> second of all gifs have no inter prediction (alpha is a thing I know, it's fake inter prediction) [22:23:38 CEST] <sikilikis> um, I have the -s flag but its not scaling to a different size [22:23:47 CEST] <sikilikis> I just found that if I left it out, I'd get a lot of alsa errors [22:23:56 CEST] <kepstin> sikilikis: show us your command :) [22:24:07 CEST] <alexpigment> is the source true GIFs, or is that an intermediate format that you're creating? [22:24:07 CEST] <sikilikis> working on it lol. on my work laptop which is on vpn [22:24:09 CEST] <thebombzen> and the GIF palette thing counteracts the use of transparency [22:24:13 CEST] <sikilikis> which means i cant ssh into my pi [22:24:17 CEST] <thebombzen> because forcing a palette requires you to dither [22:24:31 CEST] <furq> i guess you'd want yuv420p tiff for minimum time spent decoding and colourspace converting [22:24:40 CEST] <furq> if you do split to images [22:24:45 CEST] <thebombzen> I'd even recommend mjpeg over TIFF [22:24:50 CEST] <thebombzen> over GIF* [22:24:54 CEST] <thebombzen> mjpeg is actually pretty fast [22:25:08 CEST] <furq> iirc mmal doesn't support mjpeg in ffmpeg [22:25:18 CEST] <thebombzen> mmal? [22:25:19 CEST] <alexpigment> WebM/VP8 is what a lot of modern GIFs are switching to under the hood, right? [22:25:24 CEST] <furq> the rpi hardware decoder [22:25:29 CEST] <thebombzen> alexpigment: sort of [22:25:40 CEST] <alexpigment> i'm out of the gif loop (no pun intended) [22:25:40 CEST] <thebombzen> it's definitely true video [22:25:48 CEST] <thebombzen> there's definitely a push to use video [22:25:53 CEST] <kepstin> alexpigment: the ".gifv" on imgur is just a video file in an html page, yeah, but I expect they do h264 encodes (in addition to vp8/9?) [22:25:54 CEST] <alexpigment> right, to get around the interent shittiness of gif [22:25:55 CEST] <thebombzen> but many websites are ignoring vp8 and just using H.264 [22:25:56 CEST] <furq> there's animated webp now but nobody uses it [22:26:07 CEST] <furq> gifv is mp4 iirc [22:26:09 CEST] <furq> twitter does the same thing [22:26:14 CEST] <thebombzen> yea gifv is just mp4 [22:26:15 CEST] <alexpigment> did animated PNG ever catch on? [22:26:23 CEST] <thebombzen> alexpigment: yes and no [22:26:25 CEST] <furq> funnily enough they finally added apng to chrome last month [22:26:28 CEST] <thebombzen> it did but then it un-caught on [22:26:36 CEST] <furq> it's been in firefox for years but nobody's been able to use it [22:26:42 CEST] <sikilikis> https://pastebin.com/XHP5LxCx [22:26:45 CEST] <furq> and now that there are viable alternatives, chrome go and add it [22:26:45 CEST] <thebombzen> chrome used to support apng but when they went from Webkit to Blink they lost the support [22:26:52 CEST] <furq> i bet it's part of the hostage exchange for webp in firefox [22:26:57 CEST] <furq> i can't see any other reason they'd do it [22:27:05 CEST] <thebombzen> Chromium doesn't support apng tho [22:27:09 CEST] <alexpigment> furq: i like this conspiracy theory [22:27:13 CEST] <thebombzen> Safari does as of like a year ago [22:27:16 CEST] <thebombzen> either way [22:27:22 CEST] <furq> didn't we have this conversation [22:27:23 CEST] <thebombzen> webp has pretty terrible support globally [22:27:25 CEST] <furq> chrome has never supported apng [22:27:30 CEST] <sikilikis> theres my command and I know it can be better [22:27:31 CEST] <thebombzen> it did actually [22:27:33 CEST] <thebombzen> it used to [22:27:37 CEST] <thebombzen> it doesn't anymore [22:27:40 CEST] <furq> i'm pretty sure it never did [22:27:48 CEST] <furq> you just said webkit only added support in 2015 [22:28:00 CEST] <furq> chrome switched to blink in 2013 [22:28:16 CEST] <sikilikis> remind me how to add hardware decoding? I think I may have compiled it with it already [22:28:18 CEST] <thebombzen> huh? [22:28:19 CEST] <thebombzen> hm [22:28:19 CEST] <kepstin> hmm, does drawtext only work on rgb frame? [22:28:26 CEST] <furq> sikilikis: -c:v h264_mmal before -i [22:28:29 CEST] <thebombzen> ohhey apparently Chromium supports apng as of March 2017 [22:28:33 CEST] <furq> but obviously that only works if you're inputting a video [22:28:35 CEST] <furq> thebombzen: i just said that ;_; [22:28:44 CEST] <thebombzen> lol okay [22:28:49 CEST] <thebombzen> l2read @me [22:28:50 CEST] <sikilikis> the hardware decoding does? or something else? [22:28:57 CEST] <furq> mmal [22:29:03 CEST] <furq> it's an h264 decoder [22:29:06 CEST] <sikilikis> okay so lets say [22:29:10 CEST] <furq> it does other stuff but i don't think it's wired up in ffmpeg [22:29:11 CEST] <sikilikis> I encode the gif to a video [22:29:21 CEST] <alexpigment> thebombzen: i have to laugh when someone *else* says "i just said that" to you ;) seems like there's a pattern :) [22:29:24 CEST] <sikilikis> is there any way I can loop that instead of a gif or set of images? [22:29:28 CEST] <furq> also [22:29:37 CEST] <furq> that's slow because you're scaling and doing a colourspace conversion [22:29:45 CEST] <sikilikis> I'm trying to get at the optimal of doing this [22:29:47 CEST] <alexpigment> (i'm only busting your balls a little bit of course, not serious at all) [22:29:48 CEST] <furq> also -x264opts and -preset do nothing with h264_omx, so remove those [22:29:56 CEST] <sikilikis> gotcha [22:30:05 CEST] <kahunamoore> anyone have experience with libavformat and mxf audio issues? [22:30:07 CEST] <furq> if you want to not scale or do a conversion, encode each frame of the gif to a pre-scaled yuv420p tiff [22:30:14 CEST] <furq> then use image2 to loop over those [22:30:23 CEST] <kahunamoore> muxing specifically [22:30:33 CEST] <thebombzen> alexpigment: haha when I did it to you I was repeating what you said to agree with you xD [22:30:42 CEST] <sikilikis> wait real quick [22:30:50 CEST] <alexpigment> oh right. that was *another* time. i want to say it happened yesterday too [22:30:52 CEST] <sikilikis> I use the x264 opts to set the keyframe interval [22:30:56 CEST] <thebombzen> anyway it's funny that the wikipedia page that states that chromium supports apng has an apng that doesn't work when I view the page in chromium [22:31:00 CEST] <sikilikis> how do I do that with the hardware encoder? [22:31:03 CEST] <thebombzen> maybe because Arch hasn't pulled from upstream yet [22:31:22 CEST] <furq> -g should work [22:32:10 CEST] <sikilikis> I'm assuming I can encode the gif using ffmpeg? [22:32:21 CEST] <furq> http://vpaste.net/AC1Y5 [22:32:23 CEST] <furq> something like that [22:32:25 CEST] <sikilikis> into separate frames that are already the correct format? [22:32:35 CEST] <furq> i think image2 works with tiff [22:32:45 CEST] <furq> if not then jpg shouldn't be too bad [22:33:04 CEST] <kepstin> jpg might still need some conversion tho, since it's full range? [22:33:06 CEST] <sikilikis> do I need to configure ffmpeg with image2 and jpg? [22:33:12 CEST] <furq> ? [22:33:23 CEST] <furq> kepstin: good point [22:33:26 CEST] <sikilikis> er, how do I know if I can use those with my current ffmpeg? [22:33:33 CEST] <furq> all of that except h264_omx is builtin by default [22:33:37 CEST] <sikilikis> or if I need to recompile [22:33:39 CEST] <sikilikis> oh okay [22:33:40 CEST] <sikilikis> sweet [22:34:06 CEST] <furq> actually you should be able to get rid of -c:v tiff in the first command [22:34:33 CEST] <kepstin> can you use the image2 demuxer with raw video frames? [22:35:00 CEST] <furq> yeah that works fine [22:35:04 CEST] <thebombzen> kepstin: afaik ffmpeg uses "yuvj" for fullrange and "yuv" for nonfullrange [22:35:04 CEST] <furq> i have no idea [22:35:29 CEST] <sikilikis> where would the -g option go for the keyframe interval? after the -c:v h264_omx part? [22:35:33 CEST] <thebombzen> so if you convert yuvj444p to yuv444p that'll fix the fullrange issue [22:35:45 CEST] <furq> anywhere after the input filename and before the output filename [22:35:50 CEST] <sikilikis> thanks [22:36:11 CEST] <kepstin> thebombzen: yes, but the problem is that we don't want to do any conversions ;) [22:38:57 CEST] <kepstin> hmm, looks like you can do raw frame files with image2 demuxer, just have the file extension ".raw" and give it pixel_format and video_size options [22:39:08 CEST] <furq> neat [22:39:11 CEST] <furq> that might be better then [22:41:01 CEST] <kepstin> (it has some weird stuff for having separate files per video plane if you give it a file with extension ".y", too) [22:43:28 CEST] <sikilikis> cant seem to look at the generated tiff images. At least not under windows. It just complains that it cant read the file [22:44:06 CEST] <furq> works here [22:44:19 CEST] <sikilikis> windows CAN read tiff images right? [22:44:35 CEST] <furq> i've got no idea what windows supports by default [22:44:50 CEST] <alexpigment> 1 sec [22:44:52 CEST] <alexpigment> i can test this [22:45:16 CEST] <alexpigment> yes, on a basic level [22:45:33 CEST] <alexpigment> having said that, it might just support embedded thumbnails in TFF files [22:45:42 CEST] <alexpigment> *TIFF, rather [22:46:15 CEST] <kahunamoore> ping #2: anyone have experience with libavformat and mxf muxing? [22:46:51 CEST] <alexpigment> kahunamoore: i think i have, but maybe that was FFMBC. let's assume i can't answer the question, but go ahead anyway [22:47:55 CEST] <kahunamoore> I'm having "last frame" audio issues, either the audio essence is incomplete (smaller than all the other CBR audio essences) or missing one of the channels/essences altogether [22:48:23 CEST] <kahunamoore> I'm properly writing out the footer, closing the file, etc [22:48:50 CEST] <sikilikis> yeah i used your command to get tiff images from my gif. it seems to work okay but I cant open them [22:49:02 CEST] Action: alexpigment moves out of the way for smarter people to make sense of kahunamoore's problem [22:49:17 CEST] <kahunamoore> BTW - I'm not using libavcodec (using hw codec) [22:49:18 CEST] <furq> well as long as ffmpeg can open them, it's fine [22:49:25 CEST] <kepstin> sikilikis: i'd expect there to be limited application support for opening yuv tiff files. that's ok, they're just a temporary file for ffmpeg [22:49:34 CEST] <sikilikis> I guess so. I'll have to try that [22:51:08 CEST] <kahunamoore> i've emailed the libav-user ml so maybe someone there can help. thanks! [22:53:16 CEST] <sikilikis> loop option doesnt work [22:53:18 CEST] <thebombzen> but what improvements does HEVC have over H.264 other than larger blocks and more intra directions (which afaik is just to make the larger blocks more effective) [22:53:42 CEST] <thebombzen> because it seems to me that a codec that's 10 years newer should be able to do 1080p significantly better [22:53:43 CEST] <sikilikis> [image2 demuxer @ 0x30a840] Unable to parse option value "-1" as boolean [22:53:57 CEST] <thebombzen> sikilikis: use -stream_loop [22:54:02 CEST] <thebombzen> not -loop or -loop_input [22:54:13 CEST] <thebombzen> although the image2 demuxer has always had trouble looping input [22:54:57 CEST] <thebombzen> sikilikis: wait nvm. -loop is a private option for the image2 demuxer [22:55:06 CEST] <thebombzen> from the docs it says: If set to 1, loop over the input. Default value is 0. [22:55:14 CEST] <thebombzen> this means you don't have an option for the # of loops [22:55:24 CEST] <thebombzen> just -loop 1 to loop it and -loop 0 to, not [22:55:34 CEST] <sikilikis> that seems to have done it [22:57:10 CEST] <sikilikis> hmm. Looks like there actually is something wrong with the tiff images [22:57:27 CEST] <sikilikis> stream is just buffering but ffmpeg seems to be chugging along nicely [22:58:57 CEST] <sikilikis> Is there any other formatting stuff I need to do? For youtube I need to have -f flv [22:59:25 CEST] <furq> pastebin the command and output [23:01:06 CEST] <sikilikis> https://pastebin.com/97YE0cVw [23:01:07 CEST] <thebombzen> furq why not use furqbot [23:01:25 CEST] <furq> my bot doesn't do that [23:01:30 CEST] <furq> sikilikis: paste the output as well [23:02:13 CEST] <sikilikis> gimme a sec [23:03:12 CEST] <sikilikis> https://pastebin.com/C0m5GQT6 [23:03:22 CEST] <sikilikis> I killed the command myself. ffmpeg doesnt complain or anything [23:04:29 CEST] <sikilikis> oh wait shit did you want the output of the tiff conversion? [23:05:54 CEST] <furq> no [23:06:03 CEST] <sikilikis> okay well thats basically it [23:06:36 CEST] <sikilikis> oh wait [23:06:38 CEST] <sikilikis> its working [23:06:41 CEST] <furq> oh fun [23:06:45 CEST] <furq> i was going to say you might need to set -g [23:06:48 CEST] <sikilikis> i just had to refresh the browser... [23:06:51 CEST] <furq> nice [23:07:03 CEST] <furq> youtube is pretty picky about gop size but idk what h264_omx spits out by default [23:07:05 CEST] <alexpigment> does anyone else here get a little gunshy when they see 854x480? [23:07:21 CEST] <furq> also yeah you might as well scale to 720p [23:07:24 CEST] <sikilikis> yeah dont trip I can fix that now that I have the super secret technique of streaming [23:08:09 CEST] <alexpigment> no, it's fine. i'm just saying that when i see 854x480, i think of all the problems that can arise (and I have personally dealt with). not that there's a problem here with your usage [23:08:12 CEST] <furq> not sure if google reencodes live streams but that'll improve audio quality for regular videos [23:09:27 CEST] <furq> oh, one other thing [23:09:34 CEST] <furq> make sure the textfile you're using for drawtext is on a tmpfs [23:09:40 CEST] <furq> otherwise it'll be hitting the sd card [23:09:46 CEST] <sikilikis> oh yeah [23:09:52 CEST] <sikilikis> I did that already dont trip [23:10:05 CEST] <sikilikis> that was one of the first things I read when googling for this [23:10:06 CEST] Action: alexpigment is tripping [23:10:09 CEST] <alexpigment> ;) [23:10:11 CEST] <furq> i wish i was tripping [23:10:19 CEST] <alexpigment> can we all just agree to trip? [23:10:31 CEST] <furq> depends on what my dealer's got in [23:10:42 CEST] <sikilikis> lol yeah no worries everything I ever read says "the pi can corrupt the sd card. dont write too much" [23:10:57 CEST] <furq> it's more "the sd card is slow as fuck" [23:11:15 CEST] <furq> but having it die is also concerning [23:11:21 CEST] <sikilikis> well that too but reading a text file wont be too difficult [23:11:39 CEST] <furq> i can imagine it having enough latency to cause a frame drop [23:11:48 CEST] <sikilikis> although if theres a way to have ffmpeg not read it every frame thatd be cool [23:11:58 CEST] <furq> you could maybe do something with sendcmd [23:12:03 CEST] <sikilikis> like have it read every 30 frames or something [23:12:03 CEST] <furq> i've never fully figured out how that works though [23:12:10 CEST] <sikilikis> naw thats too complicated [23:12:18 CEST] <sikilikis> I'll just let it read off of /tmp [23:12:20 CEST] <thebombzen> sikilikis: you want ffmpeg to read every 30 frames? [23:12:22 CEST] <furq> it shouldn't be a big deal if it's in memory [23:12:26 CEST] <thebombzen> and drop 29 of every 30? [23:12:31 CEST] <thebombzen> cause that's what the framestep filter does [23:12:32 CEST] <furq> he wants it to read the textfile in drawtext every 30 frames [23:12:35 CEST] <thebombzen> -vf framestep =30 [23:12:36 CEST] <sikilikis> the drawtext filter has a "reload" option [23:12:43 CEST] <furq> you're really bad at reading today [23:12:44 CEST] <thebombzen> oh hm [23:12:53 CEST] <thebombzen> yea I guess I am [23:12:55 CEST] <sikilikis> but all I found is that "reload=1" makes it reread the text file every frame [23:12:59 CEST] <sikilikis> which is fine but not necessary [23:13:08 CEST] <thebombzen> perhaps I'd suggest using some complex filtergraph [23:13:11 CEST] <sikilikis> if it could do like "reload=30" or something [23:13:21 CEST] <sikilikis> just to make things a little easier on ffmpeg [23:13:25 CEST] <sikilikis> but again, its not necessary [23:14:34 CEST] <thebombzen> whatever the framerate is, say it's R [23:14:43 CEST] <sikilikis> yeah [23:14:58 CEST] <sikilikis> basically "re read the text file every R frames" [23:15:06 CEST] <sikilikis> but again its not necessary [23:15:22 CEST] <sikilikis> i dont know if that would even give a performance boost [23:15:38 CEST] <furq> the Right Way to do this is probably sendcmd, but i've never figured out how to do that dynamically through an fd or something similarly simple [23:15:46 CEST] <thebombzen> you could do -lavfi 'color=black(a)0.0,drawtext=<options>:reload=1,fps=R[draw] ; [0:v] [draw] overlay [v]' -map '[v]' [23:16:03 CEST] <furq> i know you can do it through zmq but that's massively overcomplicated for this [23:16:08 CEST] <thebombzen> haha [23:16:30 CEST] <thebombzen> I mean actually this: -lavfi 'color=black@0.0:rate=R/30,drawtext=<options>:reload=1,fps=R[draw] ; [0:v] [draw] overlay [v]' -map '[v]' [23:16:37 CEST] <thebombzen> where R/30 is the actual number [23:17:21 CEST] <furq> that would incur a colourspace conversion wouldn't it [23:17:41 CEST] <sikilikis> now I need to increase the font [23:17:44 CEST] <thebombzen> it would, but not on the original video [23:17:48 CEST] <sikilikis> font size I mean [23:17:50 CEST] <furq> oh maybe not [23:17:55 CEST] <furq> apparently color is yuv420p by default [23:17:58 CEST] <thebombzen> so if your input is 60 fps, this will just run drawtext on 2fps transparent input with reload=1, and duplicate frames to make it 60 fps [23:18:15 CEST] <thebombzen> and then overlay the drawn image on the original [23:19:30 CEST] <sikilikis> also I can add -r at the end to set a constant fps right? [23:20:43 CEST] <furq> set -framerate before -i [23:20:58 CEST] <furq> -r will take the existing framerate and drop/dup frames [23:21:07 CEST] <furq> -framerate with image2 will just set the input framerate [23:21:21 CEST] <sikilikis> ah okay [23:45:03 CEST] <alexpigment> furq: related to our earlier convo about HEVC vs VP9, i just ran across this: http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Netflix-… [23:45:21 CEST] <alexpigment> it doesn't really cover 4k comparisons in the charts, but it's an interesting breakdown [23:45:52 CEST] <chovy> how do i convert an m3u8 feed to live audio stream? [23:46:02 CEST] <furq> well that's x265 vs libvpx, which isn't quite the same thing, although it is in practice [23:46:24 CEST] <furq> afaik google have pretty much abandoned libvpx vp9 at this point in favour of av1 [23:46:32 CEST] <thebombzen> has av1 been frozen yet? [23:46:36 CEST] <furq> no [23:46:39 CEST] <thebombzen> ah okay [23:46:43 CEST] <furq> some time this year iirc [23:46:43 CEST] <alexpigment> another codec i have to research... :) [23:46:55 CEST] <furq> av1 is the alliance for open media codec [23:46:56 CEST] <thebombzen> will av1 even be better than H.264 at hd1080 [23:47:04 CEST] <furq> ask TD-Linux, he's working on it [23:47:24 CEST] <thebombzen> cause from what you guys were saying, HEVC/VP9 don't have much improvement over H.264 at 1080p [23:47:35 CEST] <furq> define "much" [23:47:40 CEST] <thebombzen> what you just said [23:47:42 CEST] <TD-Linux> VP9 is quite an improvement [23:47:46 CEST] <TD-Linux> @ 1080p [23:47:53 CEST] <thebombzen> what about HEVC over H.264? [23:48:01 CEST] <alexpigment> thebombzen: i was just saying it wasn't *worth using*, not that it doesn't have much improvement, per se [23:48:02 CEST] <furq> the improvement is relatively bigger at 1440p/4k [23:48:08 CEST] <thebombzen> lol I know that [23:48:20 CEST] <TD-Linux> AV1 is hopefully better at lower resolutions too [23:48:21 CEST] <thebombzen> I am fully aware that HEVC and vp9 really shine at uhd [23:48:42 CEST] <thebombzen> but does HEVC really have a drastic improvement over H.264 at hd1080? [23:48:50 CEST] <nightlingo> Hello [23:48:54 CEST] <thebombzen> Hello [23:48:54 CEST] <TD-Linux> <furq> afaik google have pretty much abandoned libvpx vp9 at this point in favour of av1 <- there is a lot of activity in the libvpx tree still, they depend on it a lot for YT [23:49:05 CEST] <TD-Linux> certainly less dead than x264 :^) [23:49:19 CEST] <furq> fair enough [23:49:33 CEST] <thebombzen> TD-Linux: what do you mean by "AV1 is hopefully better at lower resolutions too" [23:49:35 CEST] <furq> i take it no major new features are planned though [23:49:48 CEST] <thebombzen> is it currently not better than H.264 with the given testing? [23:49:50 CEST] <furq> like, you know, frame multithreading [23:50:10 CEST] <furq> thebombzen: it was better than vp9 last time i asked him about this [23:50:17 CEST] <furq> which was about a week ago [23:50:38 CEST] <nightlingo> I want to slice a small part from an .mp4 file. How can I use the exact same format and settings on the output file as the input file? I dont want to use -c copy though, because it doesnt work well when the split happens in a non-keyframe moment [23:50:40 CEST] <thebombzen> yea cause remember that UHD is the new hip thing but most people still have 1080 monitors [23:50:48 CEST] <thebombzen> so many many people still consume 1080p video [23:51:10 CEST] <thebombzen> I think neglecting 1080p as "that's so 2010" or something like that is a mistake [23:51:10 CEST] <furq> well if you're targeting the mass market then vp9/hevc are out anyway [23:51:17 CEST] <furq> and av1 [23:51:32 CEST] <furq> and it's not like it'll perform worse than h264 at 1080p [23:51:45 CEST] <thebombzen> well "performing slightly better" isnt' good enough [23:51:53 CEST] <thebombzen> bitrate ratio-wise [23:51:55 CEST] <TD-Linux> thebombzen, no it's way better than h.264 [23:51:59 CEST] <furq> i don't think it's a case of "tuning for 4k" as it is that that's where the obvious gains are to be made [23:52:00 CEST] <thebombzen> at 1080? [23:52:03 CEST] <thebombzen> excellent [23:52:05 CEST] <furq> as much as it is [23:52:22 CEST] <thebombzen> because to be honest I don't really care about uhd [23:52:27 CEST] <thebombzen> and I suspect a very large number of people don't either [23:52:39 CEST] <thebombzen> so having it be significantly better at 1080p is a really nice [23:52:42 CEST] <furq> that number can only get smaller over time though [23:52:58 CEST] <TD-Linux> there's some stuff that will help with very low resolutions, like 360p over vp9 [23:53:14 CEST] <thebombzen> perhaps we'll finally be able to abandon codecs that are patent-encumbered [23:53:19 CEST] <TD-Linux> or even 144p [23:53:21 CEST] <thebombzen> wow that's low [23:53:25 CEST] <alexpigment> thebombzen: UHD is cool in the sense that it's throwing away less information, but the real selling point for UHD is actually HDR imho. [23:53:30 CEST] <furq> africa video 1 [23:53:31 CEST] <thebombzen> that seems mostly useful for "new gif" technology [23:53:49 CEST] <thebombzen> like websites that use actual video instead of GIFs [23:53:59 CEST] <thebombzen> alexpigment: not really [23:54:04 CEST] <furq> granted most of africa will have a higher gdp/capita than the usa by the time av1 is released [23:54:15 CEST] <thebombzen> alexpigment: it's pretty useless if you don't have a large or HDR monitor [23:54:21 CEST] <alexpigment> thebombzen? how do you figure? HDR is the only element of UHD that you can see from your couch? [23:54:28 CEST] <thebombzen> no I can't see it from my couch [23:54:36 CEST] <furq> uh [23:54:38 CEST] <thebombzen> because my monitor displays 8bit anyway so it'll be downsampled [23:54:41 CEST] <alexpigment> right [23:54:43 CEST] <furq> oh [23:54:49 CEST] <alexpigment> normal people watch TV from a TV ;) [23:55:01 CEST] <thebombzen> normal people don't have HDR tvs [23:55:10 CEST] <alexpigment> i realize monitor tech lags, but if 4k is really going to "take off", it's going to be because of HDR, not UHD [23:55:27 CEST] <thebombzen> again, you're neglecting the incredible number of people who *still* use 1080p [23:55:34 CEST] <alexpigment> thebombzen: more people have HDR TVs than have 10-bit monitors, by a very very wide margin [23:55:43 CEST] <thebombzen> in particular remember that people of my generation frequently don't have TVs [23:55:48 CEST] <thebombzen> and consume all multimedia on a computer [23:55:54 CEST] <thebombzen> (I'm 21 fyi) [23:56:10 CEST] <alexpigment> <-- *i* still use 1080p TVs. i'm just saying, the resolution is not a good selling point. HDR is the only hope of pushing along the new standard [23:56:15 CEST] <thebombzen> sure [23:56:22 CEST] <thebombzen> but remember that TVs themselves are declining [23:56:27 CEST] <thebombzen> but yes HDR is great [23:56:33 CEST] <thebombzen> also bt.2020 color primaries are good [23:56:40 CEST] <thebombzen> much better than 709 [23:56:48 CEST] <alexpigment> it was kinda like when they tried to sell 120hz tvs and found that most people couldn't tell the difference, so they had to come up with motion interpolation... (that was a horrible idea, btw) [23:57:17 CEST] <thebombzen> 120 Hz over 60 Hz is not useful if people are viewing 30 fps video [23:57:22 CEST] <alexpigment> right [23:57:24 CEST] <thebombzen> it's nice if you play video games tho [23:57:27 CEST] <alexpigment> the point is 24fps x 5 [23:57:28 CEST] <thebombzen> and you have a powerful card [23:57:35 CEST] <bf_> Could it be that ffmpeg tages up a lot of resources? [23:57:40 CEST] <bf_> *takes [23:57:42 CEST] <thebombzen> what? [23:57:44 CEST] <thebombzen> https://upload.wikimedia.org/wikipedia/commons/b/b6/CIExy1931_Rec_2020.svg [23:57:45 CEST] <furq> it could be [23:57:50 CEST] <thebombzen> but look at these primaries [23:57:51 CEST] <alexpigment> the only selling point as far as I know is just that 120hz TVs eliminate motion judder on 24fps sources [23:57:57 CEST] <alexpigment> not motion interpolation [23:57:59 CEST] <thebombzen> this is true they do [23:58:13 CEST] <thebombzen> but there are pretty good algorithms to remove judder [23:58:15 CEST] <alexpigment> yeah, you don't have to sell me on bt2020 [23:58:19 CEST] <thebombzen> mpv does it quite well [23:58:24 CEST] <thebombzen> but damn those color primaries [23:58:35 CEST] <bf_> this command uses 50%-100% on 8 cpus (in htop) /usr/local/bin/ffmpeg -i rtmp://localhost:1935/src/live -c:a aac -b:a 32k -c:v libx264 -b:v 128K -f flv rtmp://localhost:1935/hls/live_low -c:a aac -b:a 64k -c:v libx264 -b:v 256k -f flv rtmp://localhost:1935/hls/live_mid -c:a aac -b:a 128k -c:v libx264 -b:v 512K -f flv rtmp://localhost:1935/hls/live_hi [23:58:46 CEST] <furq> well yeah you're encoding video and audio [23:58:49 CEST] <alexpigment> i mean you *need* a 120hz display to eliminate 24fps judder fully. algorithms or not [23:58:49 CEST] <furq> twice [23:58:52 CEST] <furq> what do you expect [23:58:54 CEST] <thebombzen> compare to this gcrap [23:58:55 CEST] <thebombzen> https://en.wikipedia.org/wiki/Rec._709#/media/File:CIExy1931_Rec_709.svg [23:59:06 CEST] <bf_> furq: I expect to run 10 or 20 of those processes per server [23:59:18 CEST] <furq> well then use a faster x264 preset [23:59:18 CEST] <thebombzen> um [23:59:29 CEST] <thebombzen> well software encoding video is very computationally expensive [23:59:30 CEST] <bf_> hm [23:59:36 CEST] <thebombzen> so this should not surprise you [23:59:48 CEST] <thebombzen> try using -preset:v fast instead of the default (which is -preset:v medium) [23:59:49 CEST] <bf_> speedup options except buying dedicated encoding hardware? [23:59:57 CEST] <bf_> thank you [00:00:00 CEST] --- Wed Mar 29 2017

1 0

ffmpeg-devel.log.20170327
by burek 28 Mar '17

28 Mar '17

[01:49:11 CEST] <cone-348> ffmpeg 03Michael Niedermayer 07master:d65b59550b4d: avcodec/avcodec: Correct and make consistent AVERROR() in comments [09:37:12 CEST] <cone-047> ffmpeg 03Kyle Swanson 07master:b12693facf99: libavcodec/opusenc: use correct format specifiers [10:32:08 CEST] <ubitux> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80208 [10:33:44 CEST] <nevcairiel> is djgpp an actual gnu thing, sounded like somewhat of a modified gcc fork [10:34:07 CEST] <ubitux> they have a djgpp file :p [10:34:20 CEST] <ubitux> dunno exactly how djgpp fit within gcc [10:35:15 CEST] <ubitux> ok, now after that 4cc patchset, i can go back to fixing the djgpp warnings and then the merge [10:35:17 CEST] <ubitux> what a ride. [10:41:35 CEST] <ismail> djgpp port is more or less maintained. [10:42:29 CEST] <ubitux> it works with a mainstream gcc at least [11:08:45 CEST] <ubitux> btw, fun thing: the split of vp9 decoder is mandatory for djgpp support :3 [11:08:52 CEST] <JEEB> :D [11:08:57 CEST] <JEEB> avx2 etc? [11:09:06 CEST] <nevcairiel> is the file too big? :D [11:09:12 CEST] <ubitux> file is too big yes :) [11:09:21 CEST] <ubitux> /usr/lib/gcc/i686-pc-msdosdjgpp/6.1.0/../../../../i686-pc-msdosdjgpp/bin/as: libavcodec/vp9.o: /45: reloc overflow: 0x2096e > 0xffff [11:09:36 CEST] <ubitux> so i hope BBB figures out something with elenril soon [11:09:45 CEST] <ubitux> or i'll have to apply :) [11:10:19 CEST] <JEEB> hah :D [11:10:23 CEST] <ubitux> ok so i'm at 3+10+1 patch for djgpp support, one big remaining and we're good to go [11:10:36 CEST] <ubitux> and merges can continue [11:27:04 CEST] <mateo`> is it known that the mpeg2video encoder output has different outputs whether direct rendering is enabled or not ? [12:27:15 CEST] <durandal_1707> ubitux: since when freedos support is mandatory? [12:27:26 CEST] <ubitux> durandal_1707: git grep -i djgpp [12:27:39 CEST] <ubitux> it was supported for a while, it isn't anymore [12:28:01 CEST] <ubitux> it helps spotting warnings too [12:28:48 CEST] <ubitux> BBB: ping [12:52:17 CEST] <BBB> ubitux: pong [12:52:39 CEST] <BBB> ubitux: I asked elenril btw, and he said we can hold off for a while (unless we actively want to sync towards their version) since the re-split of our vp9 is still in his queue [12:52:40 CEST] <ubitux> BBB: i need to move on with the split, it prevents the compilation with djgpp [12:52:45 CEST] <BBB> (queue being todo list) [12:52:55 CEST] <ubitux> ah great [12:53:08 CEST] <BBB> sorry I didnt say that earlier, I didnt want to hold you up :( [12:53:19 CEST] <ubitux> /usr/lib/gcc/i686-pc-msdosdjgpp/6.1.0/../../../../i686-pc-msdosdjgpp/bin/as: libavcodec/vp9.o: /45: reloc overflow: 0x2096e > 0xffff [12:53:24 CEST] <ubitux> this was the error if you're curious :) [12:53:30 CEST] <ubitux> splitting the file fixes the compilation [12:53:33 CEST] <BBB> & [12:53:36 CEST] <ubitux> :D [12:53:43 CEST] <BBB> workaround" [12:53:49 CEST] <BBB> ok, so strange [12:53:59 CEST] <ubitux> that's legit, it's large :) [12:54:00 CEST] <BBB> is vp9.o the biggest file in our tree? [12:54:46 CEST] <BBB> oh it is [12:54:56 CEST] <BBB> it beats motion_est by a percent or so [12:55:12 CEST] <BBB> also worrying, no. 4 is vp8.o :-o [12:55:33 CEST] <ubitux> :) [12:56:01 CEST] <BBB> Ill go stand in the non-developer-corner-of-shame for a while and think about what Ive done [12:56:08 CEST] <ubitux> haha [12:56:31 CEST] <ubitux> so anyway, i'll rework my vp9 branch with your comments from the other day and poke you again [12:57:49 CEST] <wm4> still no review of this frame threading fix on libav-devel [12:57:56 CEST] <wm4> I guess I'll push the ffmpeg one [12:58:47 CEST] <ubitux> wm4: will that make tsan happy? [12:59:07 CEST] <wm4> I don't know? but likely [12:59:13 CEST] <ubitux> nice [12:59:15 CEST] Action: ubitux impatient [12:59:26 CEST] <ubitux> BBB: motion_est is small here [12:59:27 CEST] <wm4> I'll also push my rotation patch [13:00:07 CEST] <ubitux> BBB: this is my ranking: http://sprunge.us/SQfQ [13:01:18 CEST] <BBB> ubitux: strange& must be a compiler debug difference [13:01:31 CEST] <BBB> ubitux: I bet w/o debug symbols wed get more even results [13:01:42 CEST] <BBB> anyway& thinking of vp9 split [13:01:56 CEST] <BBB> if djgpp is a priority for you, I can poke elenril and we can work on the split in ffmpeg [13:02:08 CEST] <BBB> (if were going to split anyway and in the same way, it doesnt matter in which tree the split originates) [13:02:22 CEST] <BBB> then after that we can apply the oher patches on top of that [13:02:53 CEST] <BBB> is that helpful? [13:05:33 CEST] <durandal_1707> whats different with dnxhr 444 quantization versus dnxhd one? [13:06:35 CEST] <ubitux> BBB: i'm fine with re-adjusting the split afterwards [13:06:45 CEST] <ubitux> apply current split to match current libav [13:06:47 CEST] <durandal_1707> it have smthing different when decoding, trying to guess similar with encoding [13:06:53 CEST] <ubitux> then apply another split to match a potential new split [13:07:22 CEST] <ubitux> BBB: if he didn't start anything, reducing the differences ourselves will help them [13:22:32 CEST] <cone-883> ffmpeg 03wm4 07master:ddef3d902f0e: avformat, ffmpeg: deprecate old rotation API [13:22:32 CEST] <cone-883> ffmpeg 03wm4 07master:9e703ae30f91: pthread_frame: do not attempt to unlock a mutex on the wrong thread [13:22:32 CEST] <cone-883> ffmpeg 03wm4 07master:d7896e9b4228: pthread_frame: fix uninitialized variable read [13:23:25 CEST] <ubitux> wm4: thanks :) [13:23:56 CEST] <wm4> async_mutex is now a leaf lock, so I doubt it triggers tsan [13:24:06 CEST] <ubitux> we'll see [13:31:37 CEST] <uau> wm4: you applied the mutex commit without the commit message or broadcast->signal changes? [13:32:03 CEST] <wm4> uau: oops, yes [13:33:24 CEST] <wm4> uau: what do you mean "commit message" [13:33:52 CEST] <uau> as for the "uninitialized variable" commit, i don't understand why you talk about "possibly due to 32a5b" - it was your merge commit that caused the problem (as already mentioned before) [13:34:03 CEST] <uau> what i said about the commit message on libav-devel [13:34:16 CEST] <wm4> uau: I see no mail from you [13:34:45 CEST] <wm4> commit 32a5b didn't "cause" the problem, but it interacted badly with the merge [13:34:57 CEST] <uau> i mean on irc (and you replied "ok about the commit msg") [13:35:05 CEST] <wm4> well easy to forget [13:35:14 CEST] <wm4> what did you say about the commit msg? [13:35:28 CEST] <uau> <uau> wm4: about the commit message: "has is used", "It's not allowed" probably better as "That's not allowed" ("that" referring to a larger part of previous sentence), "a mutex and condition variable"->"a mutex and a condition variable" [13:36:15 CEST] <uau> as for "interacted badly", it looked like it must have required manual conflict resolution, and that's where the error was introduced [13:36:38 CEST] <wm4> sure, I'm not denying it [13:38:45 CEST] <durandal_1707> anyone understands how dct works? [13:41:19 CEST] <nevcairiel> yeah should probably change that to signal instead of broadcast, makes no sense to wake all threads just so all b ut one go to sleep again [13:44:35 CEST] <atomnuker> durandal_1707: page 496 of "The Scientist and Engineer's Guide to Digital Signal Processing" [13:45:47 CEST] <durandal_1707> atomnuker: yeah, but for dnxhd versus dnxhr 444 [13:46:35 CEST] <durandal_1707> they use some other numbers slightly different [13:46:51 CEST] <wm4> atomnuker: is there an online copy of this book [13:46:52 CEST] <durandal_1707> so i get blocky video [13:47:36 CEST] <BBB> ubitux: so, I think that if we split by their current split, they will not re-split [13:47:51 CEST] <BBB> ubitux: in other words, we have to review their split as the proposed split if we go with that, assuming they will not re-split [13:48:03 CEST] <ubitux> ooh [13:48:32 CEST] <ubitux> well, then, we split to match libav, and then we add another potential split if needed [13:48:36 CEST] <ubitux> it will be easier for them to import [13:48:40 CEST] <ubitux> (and simpler for :D) [13:49:05 CEST] <BBB> or we can bug the djgpp devs to fix their software [13:49:21 CEST] <ubitux> i don't think it's a problem with djgpp [13:49:30 CEST] <ubitux> but a limitation of the object format [13:49:57 CEST] <ubitux> you don't like the split? [13:50:17 CEST] <BBB> I dont know, I never reviewed it ;) [13:50:29 CEST] <BBB> Ill look at the patch, you have a link? [13:50:32 CEST] <durandal_1707> github.com/richardpl/FFmpeg/tree/dnxhd -> latest work [13:50:59 CEST] <BBB> I honestly think if we apply their split, well be stuck with it unless we make changes ourselves, elenril wont make additional changes if we integrate their split [13:51:09 CEST] <ubitux> BBB: https://github.com/ubitux/FFmpeg/compare/vp9sync first commit [13:51:11 CEST] <BBB> (which may be ok, but changes expectations) [13:51:14 CEST] <BBB> okay, checking [13:51:32 CEST] <ubitux> i'm fine with adjusting the split, but ideally on top of this [13:51:47 CEST] <BBB> so vp9 -> vp9 + prob + mvs + block, right? [13:51:59 CEST] <durandal_1707> atomnuker: try that one, it creates nice effect [13:52:04 CEST] <ubitux> + dsp (except the header which ends up in vp9.h) [13:52:27 CEST] <ubitux> and + data too (.c, not .h) [13:52:54 CEST] <BBB> we already had dsp and data [13:52:59 CEST] <BBB> they shouldnt change much [13:53:13 CEST] <ubitux> it ends up in a .c instead of a .h [13:53:14 CEST] <BBB> oh you split vp9data.h into vp9data.c? [13:53:19 CEST] <BBB> oh right of course [13:53:28 CEST] <ubitux> btw, i forgot "prob" in the commit message [13:54:20 CEST] <atomnuker> wm4: its a free book actually (http://www.dspguide.com/pdfbook.htm) (http://ft-sipil.unila.ac.id/dbooks/The%20Scientist%20and%20Engineer%27s%20G…) [13:55:07 CEST] <wm4> nice [13:56:37 CEST] <BBB> so this commit merges vp9dsp.h into vp9.h [13:56:44 CEST] <BBB> thats a pretty seriously bad idea design-wise [13:57:17 CEST] <BBB> vp9dsp is a software only thing, vp9.h is the interface through which we share vp9 as a bitstream parser and a decoder interface between the software decoder and hwaccel implementations [13:58:04 CEST] <BBB> so we would really need 2 or 3 header files, vp9.h as that interface, a separate one as the interface of the software-only decoder (which depends on vp9.h), and then optionally the third being the dsp-specific parts of this interface, which is whats currently in vp9dsp.h [13:58:17 CEST] <BBB> and the second one would obviously depend on the first and (optionally) third [13:58:53 CEST] <BBB> the advantage of splitting vp9dsp.h into its own interface is that the dsp implementation bits dont depend on the full software decoder interface header file, but only the dsp-specific parts of it [13:59:13 CEST] <BBB> (and you could go one step further into h264 territory and split the dsp into bits; the asm is already split, so only the c needs splitting) [13:59:34 CEST] <ubitux> BBB: yes, i don't like the merge into vp9dsp, but keeping the split was a real pain for the following unification [13:59:41 CEST] <ubitux> into vp9.h* [14:00:05 CEST] <durandal_1707> atomnuker: any ideas? [14:00:08 CEST] <ubitux> we could split it out again at the end [14:00:28 CEST] <BBB> if we just split ourselves, without their baseline [14:00:35 CEST] <BBB> is that worse from your perspective as merger? [14:01:05 CEST] <nevcairiel> if things are split differently then that'll make merging annoying if they change anything in vp9 later on [14:01:54 CEST] <ubitux> BBB: my main problems are the 8 commits that shuffle spaces, names and positions [14:01:59 CEST] <ubitux> which comes after that split [14:02:13 CEST] <ubitux> basically that split is a ground for diffing properly and reducing diffs [14:02:15 CEST] <atomnuker> durandal_1707: do you have the specs (or can you request the specs)? [14:02:18 CEST] <BBB> nevcairiel: theyve said theyll merge our version [14:02:24 CEST] <ubitux> if i have to adjust it, everything crumble on top [14:02:31 CEST] <nevcairiel> BBB: and you believed them? :) [14:02:39 CEST] <ubitux> and i have to redo everything (which i'll be honest, won't do again) [14:02:41 CEST] <BBB> nevcairiel: do I have an alternative? [14:02:56 CEST] <BBB> ubitux: what if I do the stuff after that also? [14:03:22 CEST] <BBB> ubitux: and then Ill see if I can get elenril to merge our version after that to re-unify it again [14:03:30 CEST] <ubitux> BBB: oh well, sure, take tne branch and adjust everything you want in it :) [14:03:45 CEST] <ubitux> but TBH it's a better approach to rework on top [14:03:49 CEST] <ubitux> if we plan to move things [14:04:13 CEST] <ubitux> it will also simplify merges from libav side, and will actually help being imported [14:04:56 CEST] <ubitux> i'll undo the tree indent and various others you point out [14:05:12 CEST] <ubitux> but i won't touch the "architectural" split of the first commit [14:05:17 CEST] <ubitux> feel free too though [14:05:30 CEST] <durandal_1707> atomnuker: there are only decoder specs [14:05:35 CEST] <ubitux> (but beware you'll loose or have to redo all kind of the spaces shuffling) [14:06:47 CEST] <durandal_1707> spaces saga yet again [14:08:31 CEST] <durandal_1707> atomnuker: if i change decoder to use other dct stuff it works as expected, so just need to figure what to change in dct quantization [14:09:44 CEST] <BBB> ubitux: understood, Im checking it [14:09:58 CEST] <BBB> ubitux: I agree we dont want to re-do work for no reason [14:11:11 CEST] <BBB> ubitux: in the vp9.c split, you said as far as you knew, there were no cosmetic changes in any part, right? did you verify that when importing the patch? or did you do the actual split yourself? [14:11:30 CEST] <ubitux> i redid the split myself [14:11:34 CEST] <BBB> (Im asking because decode_sb() isnt diffing correctly, and Im wondering if thats because of cosmetic changes or because githubdiff sucks) [14:11:59 CEST] <ubitux> i looked where things were split and moved them the same way [14:12:14 CEST] <ubitux> mmh, what kind of diff? [14:12:21 CEST] <ubitux> are you sure it's not because of the following commits? [14:12:50 CEST] <ubitux> it's probable that after the split i used vimdiff to correct a few spacing, but IIRC i did that in later commits [14:13:08 CEST] <ubitux> but i'm sure i have not taken code from the libav state tree [14:13:09 CEST] <BBB> Im looking at https://github.com/ubitux/FFmpeg/commit/f2723179b14d0e8df41974410f49973578f… [14:13:14 CEST] <atomnuker> durandal_1707: your dc looks fine, though your colors look off [14:13:25 CEST] <BBB> and then click to load, and search for decode_sb [14:13:28 CEST] <atomnuker> (why does the decoder output grbp10)? [14:13:41 CEST] <BBB> I think they look identical before/after, but it doesnt diff correctly; I think githubdiff just sucks [14:14:07 CEST] <ubitux> let me check [14:14:14 CEST] <durandal_1707> atomnuker: use gbrp10 , i have to add flag to signal yuv [14:14:42 CEST] <durandal_1707> in both header annd per block [14:17:33 CEST] <ubitux> BBB: http://sprunge.us/BISP [14:17:48 CEST] <durandal_1707> atomnuker: you see blocky artifacts? [14:17:53 CEST] <BBB> ok so its githubdiff [14:17:55 CEST] <BBB> thnx [14:18:06 CEST] <ubitux> BBB: just reconstructed that manually [14:18:11 CEST] <ubitux> and gave me that [14:18:29 CEST] <ubitux> never trust github [14:19:02 CEST] <BBB> so in terms of what makes things easier for you& do you want me to fix up the bugs that I see in each commit and hand you better patches? or do you want me to take the tree and work on top of it with new patches to fix up things I dont like? [14:19:45 CEST] <BBB> things I plan to do are: split the dsp interface back into its own file (this should undo the vp9dsp.h -> vp9.h changes in most simd/dsp files) [14:19:54 CEST] <ubitux> BBB: when do you want to do that? if you wait a few hours, i'll integrate the changes you wanted me to revert; then you can reconstruct the whole branch the way you see fit [14:20:10 CEST] <BBB> I can wait, Im not in a hurry [14:20:15 CEST] <BBB> Im trying to help :) [14:20:26 CEST] <BBB> so Ill do it when its helpful [14:21:07 CEST] <ubitux> i'd recommend splitting back the vp9dsp.h on top, it's really too sensible to changes that came later [14:21:15 CEST] <ubitux> having it on top will help being imported in libav [14:21:26 CEST] <ubitux> because we really want them to integrate it [14:21:37 CEST] <ubitux> otherwise it will be a pain yet again to diffing the two projects [14:21:53 CEST] <BBB> then the second thing Id like to do is that I notice in your tree that pre-split, vp9.o is 4MB, but post-split, block.o is only 1MB, and the other files are tiny (~100kb each), so vp9.o would still be 2.75MB or so& it may make sense to split more parts out of it, e.g. the header reading and the loopfilter bits [14:22:16 CEST] <ubitux> yeah splitting the lpf could be nice [14:22:21 CEST] <ubitux> again, i'd do that on top [14:22:37 CEST] <ubitux> especially as it's not "incompatible" with the previous split afaict [14:22:42 CEST] <BBB> correct [14:22:55 CEST] <BBB> ok lets do it after then, why not [14:23:27 CEST] <BBB> Ill probably need some help verifying I did all the bits correctly in the non-x86 simd files to fix the vp9.h->vp9dsp.h includes [14:24:01 CEST] <BBB> (and also make sure I didnt break the hardware decoding interface) [14:26:56 CEST] <BBB> you said youd fix the 32x32 zigzag scan and tree cosmetic changes right? [14:28:15 CEST] <BBB> thats all major comments I have, the rest is all personal like/dislike [14:29:36 CEST] <ubitux> BBB: yes i'll do that [14:29:36 CEST] <mateo`> I will port the examples to codecpar and the new decoding,encoding API in the upcoming days [14:29:58 CEST] <wm4> wasn't there someone who wanted to post completely new examples? [14:30:43 CEST] <BBB> ubitux: ok, poke me when your tree is updated w/ that and Ill do the 2 things I pointed out (re-introduce vp9dsp.h as an interface/split hardware decoding interface from software decoding interface, and split out lpf/header reading also) [14:31:46 CEST] <ubitux> i'll try to do that this afternoon, otherwise when i get home tonight [14:31:56 CEST] <mateo`> wm4: I don't know [14:32:49 CEST] <ubitux> it's probably additionnal examples [14:32:49 CEST] <atomnuker> durandal_1707: I do, that's why I said your DCs look okay (but your ACs do not) [14:33:26 CEST] <durandal_1707> ah, thanks [14:33:50 CEST] <mateo`> ubitux: you sure ? :p [14:34:06 CEST] <ubitux> ask him, "faLUCE" [14:35:58 CEST] <mateo`> he's not on irc atm, i'll start porting the examples one by one (after i've confirmed the output of the mpeg2video encoder changes if "direct rendering" is enabled) [14:39:04 CEST] <BtbN> I still think that guy is an elaborate troll. [14:40:35 CEST] <wm4> well he's not here [14:42:00 CEST] <BtbN> I'm not sure if I even want to see his C++ wrapper. [15:12:22 CEST] <BBB> ubitux: about valgrind error: https://bugs.kde.org/show_bug.cgi?id=375839#c4 (--vex-guest-max-insns=25) [15:12:44 CEST] <BBB> ubitux: the default value is 50, lower values make it slower but reduce the chance of that error [15:13:10 CEST] <ubitux> oh, ok [15:13:12 CEST] <ubitux> i'll try [15:13:19 CEST] <ubitux> thanks [15:13:35 CEST] <BBB> its a known bug, not yet fixed, that option is just a workaround [15:13:56 CEST] <ubitux> yeah i understand :) [15:14:03 CEST] <ubitux> wm4: 2469 2816 fate tests passing with tsan :) [15:14:05 CEST] <ubitux> thanks [15:14:15 CEST] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20170327125234&slot=x86_64-archlinux… [15:15:16 CEST] <ubitux> and vp9 not present in the list [15:15:22 CEST] <ubitux> h264 is though [15:15:46 CEST] <ubitux> BBB: if you're interested in threading issues, the tsan reports looks accessible :) [15:15:51 CEST] <ubitux> much much less noise [15:15:59 CEST] <BBB> I can check [15:16:04 CEST] <BBB> vp9 no longer there? [15:16:26 CEST] <ubitux> yup :) [15:16:58 CEST] <BBB> is libavfilter threading safe at the "core"? [15:17:00 CEST] <ubitux> i wonder if we have an issue with the filters [15:17:10 CEST] <BBB> hehe we thought the same issue ;) [15:17:21 CEST] <ubitux> we probably should use atomics somewhere in [15:17:35 CEST] <BBB> it also looks like size changes in various decoders cause issues [15:17:37 CEST] <ubitux> it may fix a large amount of reports as well [15:22:34 CEST] <BBB> the h264 ones seem to come from this code in output_frame(): [15:22:35 CEST] <BBB> h->avctx->width = dst->width; [15:22:36 CEST] <BBB> h->avctx->height = dst->height; [15:22:37 CEST] <BBB> h->avctx->pix_fmt = dst->format; [15:22:49 CEST] <BBB> that does honestly look very questionable, Im pretty sure that doesnt belong there, at least not w/ threading enabled [15:23:05 CEST] <BBB> possibly you need it w/o threading or for hwaccel, but certainly not w/ threading [15:23:19 CEST] <BBB> I can try removing it and see if that helps [15:23:26 CEST] <BBB> (as in: doesnt break anything) [15:31:15 CEST] <BBB> ubitux: https://pastebin.com/peba6whz [15:31:21 CEST] <BBB> ubitux: that should fix a couple of the h264 ones [15:31:40 CEST] <BBB> it works single-threaded and w/ frame-threads [15:32:26 CEST] <BBB> Ill submit a patch [15:34:58 CEST] <nevcairiel> i'm sure there is some reason for that code [15:35:04 CEST] <nevcairiel> even if its crazy [15:35:31 CEST] <BBB> oh crap [15:35:31 CEST] <BBB> 1189af429211ac650aac730368a6cf5b23756605 [15:35:39 CEST] <BBB> who on earth OKed that patch? [15:35:42 CEST] <BBB> that is fundamentally wrong [15:35:58 CEST] <BBB> that patch has to be reverted for the tsan warnigns to go away [15:37:40 CEST] <nevcairiel> see, there was some crazy reason [15:37:41 CEST] <nevcairiel> :D [15:46:08 CEST] <ubitux> :) [15:46:28 CEST] <ubitux> BBB: i'm always happy to see threading issues getting killed so we can rely on these tools [15:50:38 CEST] <BBB> the hevc one looks very strange [15:51:57 CEST] <ubitux> the lavfi race looks related to the threads returns code [15:52:33 CEST] <BBB> yeah I cant quite bring the hevc one down to something simple [15:52:41 CEST] <BBB> it looks like a properly synced header variable to me [15:53:02 CEST] <BBB> its probably a multi-slice thing [15:53:10 CEST] <BBB> yeah its multi-slice [15:54:11 CEST] <BBB> no_rasl_output_flag needs to be handled in the same way as nal_unit_type <> first_nal_type [15:54:21 CEST] <BBB> I can try to cook up a patch for that [15:56:57 CEST] <BBB> see ML [15:57:15 CEST] <BBB> any other interesting codecs? [15:58:30 CEST] <BBB> the dirac one looks relatively trivial [15:58:39 CEST] <BBB> it just needs a pthread_once for global tables [15:58:46 CEST] <BBB> whats our convention on pthread_once? [16:00:09 CEST] <BBB> aha, avonce [16:00:45 CEST] <wm4> is this about codec init? we mark confirmed "safe" codecs with a flag [16:01:05 CEST] <wm4> so you should look at anything without that flag, and if it's trivially safe, send a patch that sets it [16:09:10 CEST] <BBB> wm4: ok done [16:10:25 CEST] <BBB> I dont see any other interesting codecs& maybe rv3/4 and mpeg4? but the mpeg4 ones seem specifically related to size changes [16:10:35 CEST] <BBB> xvid is there too I guess& maybe michaelni wants to do those [16:11:16 CEST] <wm4> I think mpegvideo code has multiple of such tables all over the place? dunno [16:11:35 CEST] <BBB> oh rv3/4 is the same as mpeg4 [16:11:50 CEST] <BBB> theyre both writing to the qscale tables during regular frame decoding [16:12:05 CEST] <BBB> why is that a race though? [16:12:28 CEST] <wm4> (hm maybe we're talking about different things so I'll shut up) [16:12:51 CEST] <BBB> wm4: the threadsafe table init was dirac, I already sent a patch for that [16:12:55 CEST] <BBB> this is another race [16:13:02 CEST] <BBB> (I still dont know if its a race or not) [16:15:54 CEST] <BBB> yeah Im going to leave that to michaelni, this is mpegvideo internals and I really dont want to go there [16:16:11 CEST] <BBB> (it has its own version of AVFrame which is not synchronized between frame threads) [16:16:28 CEST] <BBB> (but it does share data) [16:16:39 CEST] <BBB> (you can probably imagine how awesome that works with threading enabled) [16:22:26 CEST] <BBB> dnxhd/r is intra-only right? [16:23:27 CEST] <BBB> some of the intra-only errors come from the fact that we sync variables (for inter purposes) between threads, whereas intra just ignores that entirely and overwrites it outside any scope [16:23:36 CEST] <BBB> maybe the syncing should be disabled for intra-only since it is useless anyway [16:23:53 CEST] <BBB> (in pthread_frame.c:update_context_from_thread() [16:24:07 CEST] <BBB> that would fix the dnxhr errors and possible other intra-only codecs also [16:43:25 CEST] <BBB> nevcairiel: aha [16:43:27 CEST] <BBB> nevcairiel: I see now [16:43:33 CEST] <BBB> nevcairiel: you actually blocked that patch [16:43:37 CEST] <BBB> nevcairiel: but it was applied anyway [16:43:52 CEST] <BBB> nevcairiel: michaelni also had concerns [16:43:59 CEST] <BBB> nevcairiel: so I have no idea how that got in [16:44:15 CEST] <BBB> there is no explicit approval for that patch in the thread [16:57:52 CEST] <ubitux> BBB: pthread functions are checked in lavu/thread.h with assert level > 1 [16:58:12 CEST] <BBB> I just copied avonce from h264dec.c [16:58:25 CEST] <BBB> I can remove the check if its unwanted, but then we should probably fix h264dec also [16:58:27 CEST] <ubitux> if they fail, you're going to have a bad time anyway (not sure there is any clean way of handling pthread errors) [16:58:40 CEST] <wm4> some code checks ff_thread_once, some doesn't [16:58:42 CEST] <BBB> pthread fail is like malloc fail [16:58:49 CEST] <wm4> not really [16:58:54 CEST] <wm4> malloc can reasonably fail [16:59:00 CEST] <wm4> those pthread calls not [16:59:40 CEST] <ubitux> i have the feeling trying to handle pthread errors is likely to end up in a deadlock [17:00:19 CEST] <ubitux> but i guess it depends on which errors [17:00:31 CEST] <ubitux> which funcs* [17:00:46 CEST] <wm4> I don't think trying to handle _lock/_unlock would result in meaningful or maintainable code [17:00:54 CEST] <wm4> other than calling abort() [17:07:38 CEST] <BBB> your call [17:07:48 CEST] <BBB> if you want me to not check avonce failures, Ill remove it [17:07:55 CEST] <BBB> if you dont care, I wont care either ;) [17:10:49 CEST] <BBB> oh h264 has some more issues [17:15:54 CEST] <wm4> it's up to you, I'm just saying that if you do it more often, you don't need to bother with an error path [17:16:10 CEST] <BBB> sounds like youd prefer me to remove it&? :) [17:16:39 CEST] <wm4> maybe not... I'm trying to reduce your potential workload, not make it larger (sorry) [17:16:59 CEST] <BBB> Im ok, ubitux sounds like hes busy [17:22:03 CEST] <BBB> so Im guessing h264 refs cant change between slices in the same frame right? [17:22:15 CEST] <BBB> in terms of dropped refs etc. [17:22:17 CEST] <BBB> that would be silly [17:22:42 CEST] <ubitux> i was just pointed out the assert in pthread, i don't mind the check staying there :p [17:22:47 CEST] <ubitux> pointing* [17:34:34 CEST] <mateo`> if I want to preserve the frame rate of a stream while transcoding, is it OK to copy inv(input_stream->r_frame_rate) to encoder->time_base ? [17:34:46 CEST] <mateo`> or avg_frame_rate ? [17:36:20 CEST] <rcombs> FreeBSD's pthread_mutex_lock can fail with ENOMEM if the mutex is initialized with PTHREAD_MUTEX_INITIALIZER; I _think_ in other cases it's guaranteed to succeed (assuming you don't hit one of the actual error conditions) [17:37:14 CEST] <rcombs> so, avoid PTHREAD_MUTEX_INITIALIZER, and check the return value of pthread_mutex_init (since that can also ENOMEM there) [17:37:23 CEST] <rcombs> (why the fuck are their mutexes heap objects) [17:44:21 CEST] <nevcairiel> BBB: i dont remember 2015 off-hand, sorry :) [17:44:26 CEST] <nevcairiel> but sounds like something i might do [17:48:16 CEST] <wm4> rcombs: only reason I can think of is isolating ABI [17:48:26 CEST] <wm4> if those really are just mallocs [17:52:58 CEST] <rcombs> technically it's calloc but yeah [18:15:22 CEST] <durandal_1707> atomnuker: whats wrong with ac in my patch? [18:16:18 CEST] <atomnuker> it looks like its 0, hence why its blocky [18:20:58 CEST] <atomnuker> going to push the af_asyncts removal patch soon, forgot about it [19:05:50 CEST] <durandal_1707> atomnuker: if i store multiplied qscale by 2 in bitstream it works great [19:06:15 CEST] <durandal_1707> what should i do instead? [19:06:24 CEST] <atomnuker> works great == works? [19:07:01 CEST] <durandal_1707> yes, expect bottom pixels because of odd height [19:07:52 CEST] <atomnuker> odd, so the coefficients end up being alot smaller due to the increased quantizer for 444? [19:09:55 CEST] <durandal_1707> they are different, dnxhr: 444 and hqx uses different params from dnxhd [19:10:50 CEST] <durandal_1707> see dnxhddec in decode dct block [19:11:22 CEST] <atomnuker> okay, so you're doing 2x the hqx params or 2x the dnxhd params? [19:11:46 CEST] <atomnuker> if its the latter then there's no problem and everything is as it should be [19:12:04 CEST] <atomnuker> if 444 and hqx are meant to have the same params but don't then there's something wrong [19:17:19 CEST] <durandal_1707> atomnuker: 444 and hqx are just dnxhr profiles [19:17:42 CEST] <durandal_1707> they are extending dnxhd codec [19:18:45 CEST] <durandal_1707> im trying to find where to multiply by 2 [19:19:49 CEST] <atomnuker> if it looks right and doesn't break anything then it probably is correct [19:24:12 CEST] <durandal_1707> i dont like it, so i found another way [19:30:52 CEST] <ubitux> BBB: i updated my branch [19:30:56 CEST] <BBB> cool [19:31:01 CEST] <ubitux> i restored the tree and the correct layout for the 32x32 scan [19:31:10 CEST] <ubitux> i'll check the backlog from yesterday [19:31:22 CEST] <ubitux> i think there was other thing you wanted me to correct [19:31:28 CEST] <BBB> no that was it [19:31:31 CEST] <BBB> I think [19:31:46 CEST] <ubitux> i'll check anyway :) [19:32:31 CEST] <cone-883> ffmpeg 03Rostislav Pehlivanov 07master:a8fe8d6b4a35: lavfi: remove af_asynts filter [19:32:43 CEST] <ubitux> ok seems so [19:32:43 CEST] <BBB> hm, the trees now have duplicate indenting? [19:32:54 CEST] <BBB> I guess that makes sense given we use 4-space indenting [19:32:57 CEST] <ubitux> duplicate indent? you mean 4-space? [19:33:05 CEST] <BBB> yes [19:33:12 CEST] <BBB> it used to be 2 (I dont know why) [19:33:13 CEST] <ubitux> yeah we use already a 4-space indent in avoption when representing const values [19:33:23 CEST] <ubitux> so i made it consistent with that [19:33:27 CEST] <ubitux> is it a problem? [19:34:31 CEST] <ubitux> (at least when we do, we use 4 spaces, be it before the '{' like here, or inside) [19:35:08 CEST] <cone-883> ffmpeg 03Rostislav Pehlivanov 07master:487ca38e8bc4: Changelog: reorder last entry [20:17:15 CEST] <ubitux> BBB: so what's the plan? do you want to work out that branch? should i push and you work on top? do you want a few days? [20:17:35 CEST] <BBB> Ill work on the branch [20:18:02 CEST] <BBB> whether you apply it now or later is up to you I guess, Im not the biggest fan but what can I do right? [20:18:24 CEST] <ubitux> i can wait if you want to work on it [20:18:45 CEST] <ubitux> but if you only plan to work on top of it, it's probably simpler to have it upstream [20:18:59 CEST] <ubitux> now if you want to rework the history i'll leave the branch to you and move on to something else [20:19:17 CEST] <ubitux> do you want me to try out a resplit of the dsp? [20:19:20 CEST] <ubitux> (on top) [20:19:43 CEST] <BBB> I can do that [20:19:47 CEST] <BBB> you have enough work on your plate ;) [20:19:57 CEST] <BBB> ok you can apply and Ill work on tip of tree instead of your branch [20:20:17 CEST] <ubitux> don't want a few hours/days to make another review? [20:21:24 CEST] <BBB> hm ... [20:21:30 CEST] <BBB> I dont think itll change the fundamental opinion much [20:21:37 CEST] <BBB> well probably find some things we dont like [20:21:43 CEST] <BBB> but well decide to fix it on top of it regardless [20:21:44 CEST] <BBB> right? [20:21:47 CEST] <ubitux> ok ok [20:21:54 CEST] <ubitux> i'll apply soon then [20:21:57 CEST] <BBB> ok [20:22:04 CEST] <BBB> nice work, elenril will be happy ;) [20:22:19 CEST] <ubitux> durandal_1707: no opinion on pow2 in dynaudnorm? [20:23:02 CEST] <durandal_1707> ubitux: dont care [20:23:06 CEST] <ubitux> ok [20:23:50 CEST] <ubitux> btw, as expected it appears gcc won't fix the error/warning for the max align, so i guess i'll try to FFMAX with DJGPP in DECLARE_ALIGN [20:29:04 CEST] <ubitux> curl -F 'sprunge=<-' http://sprunge.us [20:29:14 CEST] <ubitux> !@#$ [20:29:16 CEST] <ubitux> http://sprunge.us/PgJG [20:29:21 CEST] <ubitux> i wonder if this would be acceptable [20:37:44 CEST] <BBB> ubitux: nice hack ;) [20:37:51 CEST] <ubitux> :D [20:38:19 CEST] <ubitux> at least i don't need to patch gcc anymore [20:41:26 CEST] <atomnuker> durandal_1707: patch reviewed [20:58:10 CEST] <ubitux> av_log(s, AV_LOG_TRACE, "%X %X\n", st->codecpar->codec_tag, MKTAG('R', 'V', '2', '0')); [20:58:12 CEST] <ubitux> huh. [20:58:23 CEST] <ubitux> what's the point of this please? [20:59:44 CEST] <nevcairiel> presumably so you can compare the tag to rv20? :p [21:01:34 CEST] <ubitux> yeah well, whatever [21:02:37 CEST] <nevcairiel> i'm sure we have all sorts of weird logs on rarely used levels [21:03:51 CEST] <jamrial> that should be using ff_tlog() [21:03:59 CEST] <jamrial> or alternatively not exist [21:04:58 CEST] <ubitux> feel free to drop it anytime [21:05:10 CEST] <ubitux> i'm almost done with fixing the warnings [21:05:42 CEST] <ubitux> i'll just need av_4cc2str and the align hack and the whole thing is ready [21:08:19 CEST] <jamrial> if you want to speed things up you could make the new fourcc functions avpriv and then promote them to public if nobody argues [21:10:57 CEST] <ubitux> no it's ok, i'll wait patiently [21:41:17 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:1c9f4b507888: lavc/vp9: split into vp9{block,data,mvs} [21:41:18 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:12c44d637382: lavc/vp9: rename ctx to avctx [21:41:19 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:f4d95e0949fb: lavc/vp9: rename {ref,unref,alloc}_frame to frame_{ref,unref,alloc} [21:41:20 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:0f8ae9d7b29d: lavc/vp9: split a few assignment out of ifs [21:41:21 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:ff8436ba7694: lavc/vp9: rename res to ret [21:41:22 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:875f6955769b: lavc/vp9: misc cosmetics [21:41:23 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:37814a21cb7d: lavc/vp9: consistent use of typedef instead of struct [21:41:24 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:e6ffdc9582a2: lavc/vp9: shuffle header declaration [21:41:25 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:5dd37c684736: lavc/vp9: clarify inv_recenter_nonneg [21:48:56 CEST] <BBB> ubitux: oh I remember what you had to fix [21:49:03 CEST] <BBB> ubitux: you had to add prob to the first commit message [21:49:09 CEST] <BBB> (as files in which it was split) [21:49:13 CEST] <BBB> ubitux: too late, ohwell [21:51:55 CEST] <ubitux> damnit i thought i actually fixed it [21:52:39 CEST] <ubitux> i wonder if i didn't try to adjust it in the rebase -i stash text like an idiot [21:52:51 CEST] <BBB> ¯\_(Ä)_/¯ [21:53:06 CEST] <BBB> (I had to google that smiley) [21:53:14 CEST] <ubitux> ;) [21:53:29 CEST] <durandal_1707> what it means? [21:53:34 CEST] <BBB> ohwell" [21:54:46 CEST] <PaoloP> Hello. I received this message in the mailing list (http://ffmpeg.org/pipermail/libav-user/2017-March/010212.html) It says to send my file made with git format patch . What does it mean, pratically? [21:56:50 CEST] <durandal_1707> PaoloP: to run: git format-patch on branch you have [21:59:43 CEST] <PaoloP> durandal_1707: the file I have to send is new, I did not use git, I simply downloaded the stable version (3.2.4) and created a new file [22:00:12 CEST] <PaoloP> durandal_1707: in this case, which branch I have to use? [22:00:27 CEST] <ubitux> https://github.com/ubitux/FFmpeg/compare/djgpp alright, i'm done [22:00:37 CEST] <ubitux> back to the merges. [22:01:04 CEST] <durandal_1707> PaoloP: the one you gonna create [22:01:26 CEST] <durandal_1707> ubitux: have you pushed it? [22:01:31 CEST] <ubitux> nope [22:01:39 CEST] <ubitux> i need reviews for the api changes [22:01:44 CEST] <ubitux> and the djgpp align hack [22:01:53 CEST] <jamrial> PaoloP: new code to be submitted should be written for master branch [22:03:40 CEST] <PaoloP> jamrial: do I have to submit it with git format patch for master branch, then? [22:04:01 CEST] <JEEB> yes [22:06:09 CEST] <jamrial> yes. commit your code, export it a patch with format-patch then email the resulting file as an attachment [22:06:43 CEST] <cone-883> ffmpeg 03Diego Biurrun 07master:c454dfcff90f: Use ISO C printf conversion specifiers where appropriate [22:06:44 CEST] <cone-883> ffmpeg 03Diego Biurrun 07master:7a2b2b6a92c4: dxtory: Drop nonsense ISO C printf conversion specifiers for standard types [22:06:45 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:53dac6c23bde: Merge commit 'c454dfcff90f0ed39c7b0d4e85664986a8b4476c' [22:06:46 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:349a26f50901: Merge commit '7a2b2b6a92c4b528ecb640790eca0aa790d858f4' [22:07:38 CEST] <PaoloP> given given that this code has to be put in the doc/examples folder, I should commit a change for the Makefile too, right? (so It is compiled with all the other files) [22:08:27 CEST] <cone-883> ffmpeg 03Diego Biurrun 07master:3ec6f855d0f2: srt: Adjust signedness of sscanf format strings [22:08:28 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:7970888b67eb: Merge commit '3ec6f855d0f21d90a0494fb798c4cf203fdb3db0' [22:09:47 CEST] <cone-883> ffmpeg 03Diego Biurrun 07master:07cac07c0c03: dash: Use correct ISO C scanf conversion specifier [22:09:48 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:9fec43902c99: Merge commit '07cac07c0c0360d67e73a7472214c79d6c520a4b' [22:09:53 CEST] <atomnuker> ubitux: I think the VP9 split merge broke something because now mpv doesn't compile [22:10:09 CEST] <ubitux> atomnuker: ah? damn, what's failing? [22:10:27 CEST] <atomnuker> ../video/out/vo.h:270:23: error: unknown type name 'AVCodecContext' [22:12:01 CEST] Action: ubitux confused [22:12:32 CEST] <jamrial> PaoloP: yeah [22:13:28 CEST] <ubitux> atomnuker: you'll need to elaborate because i have no idea how that could be because of vp9 [22:13:51 CEST] <atomnuker> me neither, I compiled just before that merge and it was fine [22:14:06 CEST] <durandal_1707> ./waf configure? [22:14:09 CEST] <jamrial> ubitux: nice, split source files for vp9 :D [22:15:14 CEST] <atomnuker> durandal_1707: both reps cleaned up [22:16:56 CEST] <BBB> atomnuker: thats the most amazing bug ever [22:17:04 CEST] <BBB> well that does it then [22:17:10 CEST] <BBB> ubitux: youll have to revert all of it ;) [22:17:28 CEST] <atomnuker> not before I finish another cleanup and recompile [22:17:39 CEST] <PaoloP> jamrial: ok, so, for the new file: "git add myfile; git commit -m "some comment"; git format-patch -1 {commit-id}; " the last command generates a file and I have to send this file to the mailing list? [22:18:04 CEST] <ubitux> BBB: you don't like that split, don't you? :D [22:18:46 CEST] <BBB> Im just teasing [22:18:50 CEST] <cone-883> ffmpeg 03Diego Biurrun 07master:30015305f3b5: Use avpriv_request_sample() where appropriate [22:18:51 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:fa85d8dbb43e: Merge commit '30015305f3b523ed7640f2c3c58b017140533c58' [22:18:58 CEST] <BBB> lemme do some work on it now that its merged [22:19:06 CEST] <jamrial> PaoloP: git format-patch -1 is enough to export the last commit, and you'll also have to git add the Makefile and any other existing file you modified [22:20:03 CEST] <PaoloP> jamrial: yes, thanks. So, for the modified Makefile I have to do "add", and it will overwrite the old one?? [22:20:15 CEST] <atomnuker> ubitux: false alarm, turns out I was on my broken vulkan vo branch [22:20:27 CEST] <jamrial> no, git will simply track the changes you did to it [22:20:38 CEST] <wm4> eh and that uses AVCodecContext in vo.h? [22:20:39 CEST] <cone-883> ffmpeg 03Luca Barbato 07master:801ac7156d3e: qsv: Be informative when reporting that no data has been consumed [22:20:40 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:e59a4d1df75f: Merge commit '801ac7156d3efb8e088fb6024f568eb36a293887' [22:20:52 CEST] <ubitux> atomnuker: cool :) [22:21:23 CEST] <PaoloP> jamrial: then these changes will be analyzed by the ffmpeg's team and accepted/rejected ? [22:21:40 CEST] <cone-883> ffmpeg 03Luca Barbato 07master:c541a44e029e: Revert "rtmpproto: Don't include a client version in the unencrypted C1 handshake" [22:21:41 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:4e43c6df54e4: Merge commit 'c541a44e029e8a4f21db028c34fee3ad1c10a409' [22:21:54 CEST] <atomnuker> wm4: unfinished direct rendering thing, obviously it'd all be in vd_lavc calling vulkan vo functions [22:21:54 CEST] <jamrial> that's the idea [22:22:04 CEST] <PaoloP> jamrial: ok [22:23:38 CEST] <PaoloP> jamrial: after executing "git format-patch -1" where is the patch file (which I have to send to the ML) written? [22:23:55 CEST] <ubitux> any idea what dad7514f9ec8a8c5e44d70fcfbbcedeff16f7e13 is about? it doesn't apply cleanly [22:24:12 CEST] <jamrial> in the folder you ran the command from [22:24:21 CEST] <PaoloP> ok thanks again. let's try all [22:24:52 CEST] <ubitux> so basically they added "shapes" which it seems we have already [22:24:54 CEST] <ubitux> i guess i'll noop [22:25:57 CEST] <jamrial> ubitux: the code is there, but the order is different [22:26:26 CEST] <ubitux> i'll noop, we probably have that fixed since 54170a33c2c97b0f50347f57e8f0f2ea681dca1d [22:26:26 CEST] <jamrial> mmh, no, different flags [22:26:31 CEST] <jamrial> yeah [22:26:55 CEST] <cone-883> ffmpeg 03Luca Barbato 07master:dad7514f9ec8: xcb: Add all the libraries to the link line explicitly [22:26:56 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:fb79adfdcecf: Merge commit 'dad7514f9ec8a8c5e44d70fcfbbcedeff16f7e13' [22:29:53 CEST] <cone-883> ffmpeg 03Mark Thompson 07master:218ed7250c10: openssl: Allow newer TLS versions than TLSv1 [22:29:54 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:03c203875007: Merge commit '218ed7250c103a975e874fb16e8e5941f4cbe223' [22:31:30 CEST] <cone-883> ffmpeg 03Vittorio Giovara 07master:7d308bf84bda: avprobe: Add -show_stream_entry to get a single stream property [22:31:31 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:c7a5b40dd97f: Merge commit '7d308bf84bda78d47c01439ff625bb06624991a7' [22:37:52 CEST] <ubitux> i'll continue the merge tmr [22:41:22 CEST] <ubitux> btw, the jpeg is not being fixed? [22:43:49 CEST] <jamrial> atomnuker or the author of the commit that introduced the regression (Jerry Jiang) should ideallly look at it [23:00:21 CEST] <BBB> ubitux: quickest attempt ever @ https://github.com/rbultje/ffmpeg/commits/vp9split [23:00:37 CEST] <BBB> ubitux: with debug symbols, all object files are now well under 1MB [23:00:47 CEST] <ubitux> 3 last commits i suppose? [23:01:11 CEST] <BBB> yes [23:04:29 CEST] <ubitux> you leave quite a bunch of things in the "format" vp9.h file [23:04:52 CEST] <ubitux> i'm not sure i get the nuance between vp9dec.h and vp9.h [23:05:08 CEST] <BBB> whatever is there now is the minimum that the hardware decoders need [23:05:28 CEST] <BBB> so things like dxva2 only need that to interface witht he software decoder skeleton through the hwaccel interface [23:06:12 CEST] <BBB> the rest is internal only to the software decoder (vp9(*notdsp).c) [23:06:32 CEST] <ubitux> BBB: s/bwh_tab/ff_vp9_bwh_tab/ or place it only locally where it's used [23:06:44 CEST] <BBB> its used in 2 files now [23:06:47 CEST] <BBB> Ill add a prefix [23:07:26 CEST] <BBB> pushed new version with prefix fixed [23:07:30 CEST] <ubitux> BBB: why not have a vp9shared.h or vp9hwaccel.h? [23:07:42 CEST] <ubitux> anyway, i like the split of lpf [23:07:46 CEST] <ubitux> otherwise no other comment [23:08:13 CEST] <BBB> I think the filename vp9.h is just historic [23:08:28 CEST] <BBB> it used to be whatever was shared between vp9dsp.h and vp9.c [23:08:45 CEST] <BBB> and then it turned into hwaccel interface also [23:08:53 CEST] <BBB> I can split that into two things, it probably makes sense, yes [23:09:09 CEST] <BBB> (vp9dsp.h should not depend on the hwaccel interface decoder thingies) [23:22:17 CEST] <cone-883> ffmpeg 03Vittorio Giovara 07master:b90c8a3d08e3: fate: Add tests for mov display matrix [23:22:18 CEST] <cone-883> ffmpeg 03James Almer 07master:ba4d0a37b98a: Merge commit 'b90c8a3d08e3f9ad4de1253376d2d1d93abb8b8c' [23:25:51 CEST] <cone-883> ffmpeg 03Vittorio Giovara 07master:ecd2ec69ce10: mov: Evaluate the movie display matrix [23:25:52 CEST] <cone-883> ffmpeg 03James Almer 07master:cef2ba3603af: Merge commit 'ecd2ec69ce10e13f6ede353d2def7ce9f45c1a7d' [23:26:00 CEST] <ubitux> jamrial: nice, exactly how i was expecting it to be merged :) [23:26:22 CEST] <jamrial> of course i wasn't going to add two new tests for sar and dar :p [23:26:35 CEST] <ubitux> you could have just ignored the sar/dar :) [23:26:47 CEST] <ubitux> i like that you took care of it :p [23:26:54 CEST] <jamrial> yeah [23:34:05 CEST] <BBB> ubitux: I split out vp9.h in 2 files (one to be shared between vp9dsp/vp9dec, and the other to share between hardware/software decoding) [23:34:13 CEST] <BBB> ubitux: anything else that you think should be done? [23:34:38 CEST] <BBB> object file sizes: [23:34:41 CEST] <BBB> -rw-r--r-- 1 ronaldbultje staff 814212 Mar 27 17:31 libavcodec/vp9block.o [23:34:41 CEST] <BBB> -rw-r--r-- 1 ronaldbultje staff 604616 Mar 27 17:31 libavcodec/vp9recon.o [23:34:42 CEST] <BBB> -rw-r--r-- 1 ronaldbultje staff 374280 Mar 27 17:31 libavcodec/vp9dsp_8bpp.o [23:34:47 CEST] <BBB> thats not too terribly I think [23:35:00 CEST] <ubitux> djgpp will be happy [23:35:04 CEST] <ubitux> but yeah, no other comment [23:35:10 CEST] <BBB> ok Ill send it to the list [23:35:31 CEST] <atomnuker> ubitux: why the sudden interest in dos compilers? [23:36:27 CEST] <ubitux> i had to merge c454dfcff90f0ed39c7b0d4e85664986a8b4476c [23:36:42 CEST] <ubitux> but to do it properly, i needed to see these warnings [23:36:58 CEST] <ubitux> and these warnings were raised by gcc/djgpp [23:37:41 CEST] <ubitux> so i need to make that toolchain work, and patch gcc in various areas, and after starting to fix the warnings i realized it was quite helpful to introduce that av_4cc2str helper [23:38:12 CEST] <ubitux> it also caused the vp9 issue (which i initially assumed it was because of the file size but couldn't confirm it so in doubt split it all and it indeed fixed the problem) [23:38:18 CEST] <ubitux> so anyway [23:38:27 CEST] <ubitux> all this shit for stupid cosmetics [23:38:29 CEST] <ubitux> @_@ [23:38:59 CEST] <ubitux> (s/patch gcc in various areas/patch ffmpeg in various areas/) [23:52:09 CEST] <cone-883> ffmpeg 03James Almer 07master:064f19f39e2f: avconv: support parsing bitstream filter options [23:52:10 CEST] <cone-883> ffmpeg 03James Almer 07master:47c2ce2f75cd: Merge commit '064f19f39e2f17927278c6ad8fe884a5b92310d6' [00:00:00 CEST] --- Tue Mar 28 2017

1 0

ffmpeg.log.20170327
by burek 28 Mar '17

28 Mar '17

[02:07:42 CEST] <ZeroWalker> another day to try to figure out hot to compile ffmpeg with libx264 [02:10:18 CEST] <JEEB> with MSVC, you mena [02:10:31 CEST] <JEEB> I have gotten as far as building libx264 with MSVC [02:10:51 CEST] <JEEB> I *think* I got it linked against libavcodec but that was some time ago :P [02:11:29 CEST] <JEEB> I think there were issues wrt to include and lib search paths on the command line, I might have worked around that with the related env variables [02:17:19 CEST] <ZeroWalker> i kinda gave up on that as i couldn't make libx264 compile with it, i was able to compile it with mingw64, at least i think that's what i compile it with [02:17:25 CEST] <ZeroWalker> but ffmpeg doesn't detect it;( [02:17:54 CEST] <JEEB> mingw-w64 should be simple [02:18:37 CEST] <JEEB> 1) use a prefix (--prefix) 2) install with make install 3) define PKG_CONFIG_PATH=/your/prefix/lib/pkgconfig when configuring FFmpeg [02:20:17 CEST] <ZeroWalker> ah, i do the first two, wtih ffmpeg i tried using the extra-cflags and whatnot. will try the define. how do you write that though do i write it at it's own line before the configure? [02:21:34 CEST] <JEEB> any way is fine, I usually define it on the same line: PKG_CONFIG_PATH=... ../configure --params --more-params [02:22:00 CEST] <ZeroWalker> ah, didn't think that worked, okay, will try it out [02:22:22 CEST] <ZeroWalker> is it supposed to take ages when configuring ffmpeg btw? [02:22:37 CEST] <JEEB> yes, although I hear it's a bit faster with dash instead of bash [02:22:54 CEST] <JEEB> shell's doing a lot of fork()s which are emulated really slowly on windows [02:23:23 CEST] <JEEB> although if you're running the msys msys2 shell it might be wiser to do PKG_CONFIG_LIBDIR, which leaves out the msys search paths (_PATH appends, while _LIBDIR overrides) [02:24:44 CEST] <ZeroWalker> don't think i heard of dash, is it the native linux thing or something? [02:24:59 CEST] <ZeroWalker> hmm didn't seem to work, will try the PKG_CONFIG_LIBDIR instead [02:25:02 CEST] <JEEB> it's a much simpler shell [02:25:10 CEST] <JEEB> the effect should be the same, look at config.log [02:25:33 CEST] <JEEB> also did you actually build libx264? [02:25:46 CEST] <JEEB> --enable-static or --enable-shared with x264's configure [02:25:52 CEST] <JEEB> by default it builds neither [02:28:10 CEST] <ZeroWalker> last build was [02:28:20 CEST] <ZeroWalker> ../x264/configure --enable-strip --disable-cli --enable-static --prefix=../x264_installed [02:41:33 CEST] <ZeroWalker> that define didn't work either, guess i am doing something else wrong;( [02:45:01 CEST] <thebombzen_> out of curiosity, for lossless encoding, deblocking is always disabled, right? [03:03:05 CEST] <ZeroWalker> JEEB, was my configure wrong? [03:03:48 CEST] <ZeroWalker> thebombzen_, i would be very surprised if any encoder had deblocking on lossless mode, that would make it semi-lossless, it would just introduce artifacts on lossless content which makes no sense [10:48:36 CEST] <termos> i'm trying to create filter graph using the examples but I keep getting "Error number 1 occurred" when parsing the filter graph "null" [12:16:21 CEST] <termos> it seems the time_base of my AVCodecContext is set to 0/2 and not (what I assume is correct) 50/2. The time_base.num is always 0 it seems, this is after avcodec_parameters_to_context [16:07:15 CEST] <Soni> how can I use ffmpeg to merge/split audio/video and stuff? [16:07:47 CEST] <c_14> merge concatenate or merge different streams? [16:08:14 CEST] <Soni> well I first need to chop them up into pieces, then merge pieces from different videos [16:08:24 CEST] <c_14> so concatenate/trim [16:08:31 CEST] <c_14> https://trac.ffmpeg.org/wiki/Concatenate [16:08:48 CEST] <c_14> https://trac.ffmpeg.org/wiki/Seeking [16:13:31 CEST] <Soni> ok so I have a video that I wanna keep as-is, but I wanna replace part of the audio (and keep the rest) [16:13:45 CEST] <Soni> how painful is this gonna be? [16:15:25 CEST] <Soni> do I extract the audio, chop it up, concatenate it, then combine with the video? [16:15:38 CEST] <c_14> pretty much [16:15:58 CEST] <c_14> though you can do the chopping up while extracting it [16:16:44 CEST] <c_14> you can even do it all in one command (if you don't mind reencoding and you're slightly masochistic) [16:17:40 CEST] <c_14> but yes, the easiest thing is extract audio, cut, concat, combine [16:17:57 CEST] <Soni> ffmpeg -i video.mkv audio.flac or something? (not that I expect flac quality, I just don't want the quality to drop while I edit it) [16:18:13 CEST] <c_14> ffmpeg -i video.mkv -map 0:a -c:a copy audio.mkv [16:18:18 CEST] <c_14> that will copy the audio track out [16:20:19 CEST] <Soni> I need it to be lossless for the concatenate part no? [16:20:58 CEST] <Soni> I mean I don't really know what I'm doing [16:21:50 CEST] <c_14> hmm? [16:21:59 CEST] <c_14> you don't _need_ anything to be lossless [16:22:17 CEST] <c_14> -c:a copy is "lossless" in that there's no reencoding so the quality doesn't change [16:22:24 CEST] <c_14> you don't need a lossless codec to concatenate audio [16:24:03 CEST] <Soni> eh how do I just turn it into flac? :/ [16:24:30 CEST] <c_14> you don't have to? [16:24:50 CEST] <c_14> unless you _really_ _really_ want to [16:25:14 CEST] <Soni> I do want to [16:25:36 CEST] <c_14> then just drop the -c:a copy and used a filename ending with .flac [16:27:59 CEST] <Soni> alright thanks [16:28:22 CEST] <Soni> I'll probably do the chopping up thing with audacity tbh, since I don't wanna introduce clicks [16:32:00 CEST] <c_14> whatever works for you [16:59:53 CEST] <Soni> thanks c_14 [18:21:03 CEST] <TWIST_> I have written simple program which extract video stream. It's working fine but playing very fast, How can I introduce delay? Note: its decoding example given [18:25:54 CEST] <Darxus> TWIST_: I probably don't know the answer to your question, but I imagine you're going to need to provide a lot more info. [18:28:41 CEST] <TWIST_> Sorry for that, In a way I am asking how can we manipulate pts and dts of AVPacket or AVFrame? [18:33:53 CEST] <DHE> the pts and dts are a measure of time relative to the stream's time_base that the packet (and ultimate frame) came from [18:34:31 CEST] <DHE> the time_base varies. sometimes it's 1/30 in which case 30fps material will just have sequential PTS values. sometimes it's a big number like 1/90,000 or 1/1,000,000 and the PTS moves in large increments [18:55:27 CEST] <fred1807> how can I render this CSS backroung to a 1920x1080 static video file? https://uigradients.com/#SweetMorning [19:09:13 CEST] <furq> !filter geq @fred1807 [19:09:13 CEST] <nfobot> fred1807: http://ffmpeg.org/ffmpeg-filters.html#geq [19:15:22 CEST] <furq> fred1807: -f lavfi -i color=white:s=1920x1080 -vf "geq=r=255:g=(95*(X/W))+(195*((W-X)/W)):b=(109*(X/W))+(113*((W-X)/W))" [19:15:25 CEST] <furq> something like that [19:17:28 CEST] <alexpigment> does anyone know the status of HEVC/H.265 interlaced support? I can get it to be interlaced according MediaInfo either by a) using -x265-params interlaced=tff along with the ilme and ildct flags, or b) using -top 1 and the same flags. strangely, this produces two differently-encoded files, but neither of them decode correctly on any players I tested. [19:18:15 CEST] <fred1807> nice [19:18:18 CEST] <JEEB> first make sure you can get correct interlaced output with the x265 cli [19:18:29 CEST] <JEEB> after that start adding libavcodec into the mix [19:18:41 CEST] <alexpigment> JEEB, good thinking. i'll test that first [19:18:52 CEST] <furq> fred1807: you can replace 95 with 0x5f etc [19:19:03 CEST] <JEEB> but yes, -x265-params is probably the way you want to do it in addition to telling ffmpeg.c to output interlaced images [19:26:11 CEST] <furq> huh [19:26:33 CEST] <furq> how do i set the sar/dar after using nullsrc/color/etc [19:26:48 CEST] <furq> setsar is just being ignored [19:26:54 CEST] <JEEB> o_O [19:28:24 CEST] <furq> http://vpaste.net/OjAGf [19:28:35 CEST] <furq> same thing if i move scale before setsar [19:30:20 CEST] <Tom_B> is it possible to burn dvb_subtitle (or possibly dvb_teletext, I'm not sure which is which to be honest!) into the frame? I've tried the example from https://trac.ffmpeg.org/wiki/HowToBurnSubtitlesIntoVideo and get either no decoder/filtering impossible or "Impossible to convert between the formats supported by the filter 'Parsed_overlay_0' and the filter 'auto-inserted scaler 1'" [19:31:07 CEST] <furq> https://trac.ffmpeg.org/wiki/HowToBurnSubtitlesIntoVideo#Picture-basedsubti… [19:31:09 CEST] <furq> do you mean that example [19:31:11 CEST] <JEEB> Tom_B: it should be, dvb subtitles should work with the overlay filter and then the dvb teletext just requires libzvbi and it gets converted into ASS [19:31:26 CEST] <JEEB> in which case you can use a text-based subtitle thing to burn it on [19:31:43 CEST] <furq> oh right yeah dvb_teletext uses the subtitle filter, dvd_subtitle uses overlay [19:31:50 CEST] <furq> s/dvd/dvb/ [19:32:33 CEST] <Tom_B> yeah, I've been trying to use the picture based subtitles [19:33:32 CEST] <furq> oh wtf [19:33:39 CEST] <kepstin> furq: that's behaving exactly as expected, you use setsar, then override with setdar [19:33:43 CEST] <kepstin> furq: use one or the other [19:34:00 CEST] <furq> it works with just setdar [19:34:20 CEST] <Tom_B> I've tried [0:v][0:s:0]overlay[v] and [0:v][0:s:1]overlay[v] neither works, am I missing something obvious? [19:34:22 CEST] <furq> just setsar is broken [19:34:57 CEST] <kepstin> furq: setsar takes sar as input and sets both sar and dar -- setdar takes dar as input and sets both sar and dar [19:35:11 CEST] <kepstin> so whichever one you use last takes effect [19:35:52 CEST] <kepstin> it doesn't make sense to set sar and dar separately, because sar and dar are related based on the frame saize [19:36:39 CEST] <furq> i figured just setsar=1 would work, but it does nothing [19:36:46 CEST] <furq> i have to setdar=16/9 [19:36:56 CEST] <furq> which seems stupid when i'm scaling to a 16:9 resolution [19:37:28 CEST] <kepstin> furq: nullsrc makes 4:3 frames by default, so setsar sets sar to 1:1 on the 4:3 frame, then the scale filter preserves the dar [19:37:37 CEST] <kepstin> works as expected [19:37:48 CEST] <furq> it sets it to 3:4 [19:38:52 CEST] <kepstin> furq: no, the scale filter updates the sar to 3:4 when it's doing the scaling, so that the dar of 4:3 is preserved [19:39:13 CEST] <kepstin> you have 320x240 [SAR 1:1 DAR 4:3] -> scale -> 1280x720 [SAR 3:4 DAR 4:3] [19:39:18 CEST] <kepstin> works as expected. [19:41:13 CEST] <kepstin> technically, you have nullsrc -> 320x240 [SAR 1:1 DAR 4:3] -> setsar=1 -> 320x240 [SAR 1:1 DAR 4:3] -> scale -> 1280x720 [SAR 3:4 DAR 4:3] [19:42:15 CEST] <Teduardo> Howdy, is there a way to automatically cut the first frame off of a video? [19:42:56 CEST] <Tom_B> What commands do I need to convert dvb_teletext to ass? Presumably I need something like -vf "ass=[0:2]" [19:43:22 CEST] <kepstin> Teduardo: assuming you're re-encoding, you can use "-vf trim=start_frame=1", I think (the first frame is #0) [19:43:41 CEST] <kepstin> Teduardo: that doesn't update the audio tho, so it might slightly desync audio. [19:43:50 CEST] <Teduardo> there is no audio [19:44:15 CEST] <Teduardo> so just specify the input as the current file and the output as the new file and -vf trim=start_frame=1 and that should possibly work? [19:44:18 CEST] <Teduardo> thanks [19:44:59 CEST] <kepstin> Teduardo: should work, yes. Keep in mind that it will require re-encoding the video, with the associated generational quality loss. [19:45:12 CEST] <kepstin> (you can't remove arbitrary frames from video without re-encoding) [19:45:26 CEST] <Teduardo> ah. it sucks that I can't just fix the flips in premier quickly [19:45:29 CEST] <Teduardo> err, clips [19:45:50 CEST] <Teduardo> someone cut a long video into clips but they cut it so that the last frame of the previous clip is in the next clip [19:45:59 CEST] <Teduardo> because they didnt know what they were doing [20:20:04 CEST] <alexpigment> Teduardo: you may want to look into VideoRedo. It does "smart rendering", where it only re-renders the GOPs right around the cut points. I use it every day and consider it easily worth the cost [20:39:52 CEST] <bf_> Good evening everyone [20:41:10 CEST] <bf_> Is it advised to use ffmpeg to merge 10+ audio streams into a single audio stream with some equalizer fiddling? [20:41:40 CEST] <bf_> I can't think of a better tool for the job, but I'd like to ask you guys first before finding out the caveats myself [20:41:51 CEST] <JEEB> there's plenty of audio filters [20:42:01 CEST] <JEEB> so in that sense you should be able to do what you want [20:43:01 CEST] <bf_> Is it a good thing to do it with ffmpeg or would you advise a different tool? [20:43:15 CEST] <durandal_1707> paid pro tool [20:43:34 CEST] <bf_> I'd like to roll my own and learn :) [20:44:38 CEST] <JEEB> bf_: I don't see any reason why you wouldn't be able to do it [20:44:38 CEST] <bf_> which paid tool do you have in mind durandal_1707 [20:44:50 CEST] <JEEB> you just need to know what exactly you'd be doing :P [20:45:21 CEST] <bf_> so okay please don't laugh :) [20:45:39 CEST] <bf_> I want to build this thing over the browser where up to 1000 people can speak into their mics simultaneously [20:45:44 CEST] <durandal_1707> bf: only very expensive one, but if ffmpeg can do it and do it fast, there you go [20:45:58 CEST] <bf_> order the audio sources in space via equalizer so you it feels like a stadium [20:46:20 CEST] <durandal_1707> ugh [20:46:43 CEST] <bf_> I know it won't scale but I want to build a prototype to show it potentially works [20:47:45 CEST] <durandal_1707> you can use amix ffmpeg filter to mix multiple sources easy way [20:49:17 CEST] <bf_> thanks for your input, I will try it [21:38:34 CEST] <bencc1> are aac and libx264 suitable formats for hls? [21:38:35 CEST] <bencc1> '-acodec', 'aac', '-strict', 'experimental', '-b:a', '96k', [21:38:36 CEST] <bencc1> '-vcodec', 'libx264', '-pix_fmt', 'yuv420p', '-preset:v', 'veryfast' ,'-crf', '23', [21:39:07 CEST] <bencc1> I'm trying to capture the screen and output hls [21:39:46 CEST] <furq> they're the only codecs you can use with hls [21:40:07 CEST] <bencc1> furq: what I pasted above? [21:40:54 CEST] <alexpigment> bencc1 - i don't think -strict and experimental are necessary for any recent versions of FFMPEG [21:41:55 CEST] <bf_> I have another stupid question. I am unable to find out if ffmpeg can listen on a port for an incoming rtmp connection and convert it to ffmpeg [21:41:59 CEST] <bencc1> alexpigment: I'm using ffmpeg on ubuntu: 2.8.11 [21:42:05 CEST] <bencc1> recent enough? [21:42:14 CEST] <bf_> On the mailing list I found something like "nc -l 8888 | ffmepg -i pipe:0 ..." but it ain't working [21:42:19 CEST] <bf_> Is there a recommended way for it? [21:42:25 CEST] <alexpigment> not sure, although i'd update if you can. the AAC encoder is much better these days than it was a year ago or so [21:42:41 CEST] <furq> you need 3.0 or above for the new aac encoder [21:43:17 CEST] <furq> https://www.johnvansickle.com/ffmpeg/ if you don't want to build it yourself [21:43:31 CEST] <bencc1> alexpigment: better in what sense? [21:43:42 CEST] <bencc1> alexpigment: what version you'll consider recent enough? [21:43:54 CEST] <alexpigment> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=d9791a8656b5580756d5b7ecc3… [21:43:57 CEST] <bencc1> 3.0.7 is good? [21:44:13 CEST] <JEEB> just go with the latest unless you have a reason not to [21:44:32 CEST] <JEEB> (if you need some sort of check just check fate.ffmpeg.org for your OS/arch) [21:44:48 CEST] <furq> don't install from a ppa if that's what you're thinking of doing [21:45:15 CEST] <bencc1> I prefer to install from the official ubuntu repo [21:45:22 CEST] <bencc1> isn't this good enough? [21:45:22 CEST] <bencc1> http://packages.ubuntu.com/yakkety/ffmpeg [21:45:40 CEST] <furq> are you on yakkety [21:46:17 CEST] <furq> i assume you're on xenial if you have 2.8.11, in which case don't install shit from other repos [21:46:30 CEST] <furq> either do a full upgrade for 3.x or just use those static builds [21:46:56 CEST] <bencc1> furq: I'm using ffmpeg inside a docker container [21:46:58 CEST] <bf_> Is there an alternative to using nginx-rtmp for rtmp server? I have a hard time to find something that listens for incoming RTMP stream and calls ffmpeg to convert to HLS [21:47:11 CEST] <bencc1> so I don't mind upgrading to yakkety if needed [21:47:21 CEST] <furq> well yeah that's fine then [21:47:34 CEST] <JEEB> at that point just go to 17.04 as that is pretty much done [21:47:40 CEST] <furq> bf_: what's wrong with nginx-rtmp for that [21:47:42 CEST] <JEEB> and has an even newer thing [21:47:51 CEST] <bencc1> JEEB: good point [21:47:54 CEST] <furq> that's more or less the main use case for it [21:48:02 CEST] <BtbN> nginx-rtmp can convert to HLS on its own. [21:48:14 CEST] <furq> yeah [21:48:26 CEST] <bf_> furq: there might be something more lightweight? I just want to convert incoming stream to HLS, and don't want NGINX to serve the hls files [21:48:38 CEST] <bf_> hls files -> cdn [21:48:40 CEST] <furq> i'm not aware of anything more lightweight [21:48:54 CEST] <bf_> furq: okay, thank you [21:48:56 CEST] <furq> you can build ffmpeg without any of the http modules if you really don't want to use it [21:49:03 CEST] <bf_> ffmpeg? [21:49:06 CEST] <furq> er [21:49:06 CEST] <furq> nginx [21:49:06 CEST] <bf_> you mean nginx? [21:49:09 CEST] <bf_> ok [21:49:46 CEST] <bf_> https://github.com/arut/nginx-rtmp-module/issues -> 500 open issues o.o [21:50:01 CEST] <JEEB> there's a fork that's more active [21:50:01 CEST] <furq> https://github.com/arut/nginx-rtmp-module/issues/985 [21:50:03 CEST] <furq> 499 open issues [21:50:04 CEST] <bf_> I heard twitch is using a go server for incoming streams [21:50:17 CEST] <furq> a lot of these appear to be feature requests [21:50:24 CEST] <bf_> anybody know if some parts of that are open sourced? [21:50:31 CEST] <furq> although yeah it's pretty inactive [21:50:37 CEST] <furq> i expect most of those issues would have been closed otherwise [21:50:58 CEST] <bf_> yes, even though arut seems to be employed at nginx [21:51:48 CEST] <bf_> Ok so this proprietary go rtmp listener is twitch's secret sauce [21:55:07 CEST] <utack> is it possible that benchmark+seek uses the real time starting when ffmpeg launches, instead of actually going to the point it should seek to and then start the benchmark? [22:56:05 CEST] <ogopogo> What is the command to remove black bars from a .mp4 file? [23:02:34 CEST] <Darxus> ogopogo: There's a command for that? [23:09:44 CEST] <pbos> Possibly-wrong channel, but does anyone happen to know if openh264/h264enc is usable without welsenc.cfg config files? [23:09:53 CEST] <pbos> Getting: [OpenH264] this = 0x0x203c010, Error:Invalid settings in bitrate. the sum of each layer bitrate(2236000) is larger than total bitrate setting(100000) [23:10:14 CEST] <pbos> which is because I haven't specified multiple layers, hoping it would just ignore that. [23:11:03 CEST] <pbos> don't see any example use of this app online, so it might just be "guh no one uses it" [23:15:50 CEST] <pbos> Oh, it just hardcodes defaults implicitly even though I haven't provided anything. That's scary. [23:17:38 CEST] <thebombzen> I'm getting a slight audio desync in mpv [23:17:40 CEST] <thebombzen> compared to ffplay [23:20:26 CEST] <thebombzen> oops wc [23:22:58 CEST] <ader> I have written simple video player, which is working fine when I play audio and video, but when I disable audio play codes video plays too fast. So my queston is, is it the responsibilty of the programmer to set play timer or does library take care with dts and pts? [23:25:08 CEST] <BtbN> I'd assume it's entirely up to you how fast you show the pictures [23:29:48 CEST] <ader> Thanks, So you are saying I have to take care of delay with some timer and make thread sleep for while to slow playing speed right [23:39:58 CEST] <kepstin> yep. normally when you have audio, the sound card limits your playback rate because it plays the audio in realtime. but if you're not playing audio, you have to time the video to some other clock. [23:46:35 CEST] <bf_> furq: JEEB: durandal_1707 I have tried out nginx-rtmp. Unfortunately it is very buggy. [23:47:46 CEST] <BtbN> Works for me. [23:48:44 CEST] <furq> same [23:59:51 CEST] <vader-> hmmm strange issue... so I am capturing my video on a Windows 10 machine, with a Blackmagic H.264 Recorder. The video looks correct on the computer, during capture, during playback in both Windows Media Player and Quicktime. When I transfer that video to another computer is comes up really dark. I have tried playing in Windows media player, Quicktime, VLC, [23:59:51 CEST] <vader-> etc. Always comes up dark... Any thoughts? [00:00:00 CEST] --- Tue Mar 28 2017

1 0

ffmpeg-devel.log.20170326
by burek 27 Mar '17

27 Mar '17

[00:13:06 CET] <JEEB> kierank: sounds like funkiness wrt merging of side data [03:25:56 CEST] <cone-982> ffmpeg 03James Almer 07master:2f05d18ee2c7: ffmpeg: stop using deprecated codec flags [03:25:57 CEST] <cone-982> ffmpeg 03James Almer 07master:f5c8d004c28d: avcodec: stop using deprecated codec flags [03:25:58 CEST] <cone-982> ffmpeg 03James Almer 07master:963cd953fbf6: avfilter: stop using deprecated codec flags [03:25:59 CEST] <cone-982> ffmpeg 03James Almer 07master:d054069c1540: avformat/mov: stop using deprecated codec flags [03:39:43 CEST] <cone-982> ffmpeg 03James Almer 07master:ec996163c8db: avcodec/extract_extradata_bsf: use the parsing code from mpegvideo_split() [03:39:44 CEST] <cone-982> ffmpeg 03James Almer 07master:173fdc4dea13: avcodec/extract_extradata_bsf: use the parsing code from vc1_split() [03:39:45 CEST] <cone-982> ffmpeg 03James Almer 07master:b53ac2a5283d: avcodec/extract_extradata_bsf: use the parsing code from mpeg4video_split() [03:43:42 CEST] <cone-982> ffmpeg 03James Almer 07master:a044f8df6aff: ffprobe: support skip_samples packet side data information [11:03:40 CEST] <ubitux> http://sprunge.us/RBAh is this legit? [11:04:12 CEST] <nevcairiel> didnt someone post a patch for that [11:04:16 CEST] <nevcairiel> not sure if it was ever applied [11:04:58 CEST] <nevcairiel> it was applied [11:05:10 CEST] <nevcairiel> although they used tsan, not hellgrind [11:11:17 CEST] <ubitux> tsan still broken for me yet :( [11:11:25 CEST] <ubitux> -yet [11:11:36 CEST] <ubitux> where is that patch you're talking about? [11:12:44 CEST] <nevcairiel> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=fed50c4304eecb352e29ce… [11:14:19 CEST] <ubitux> thanks [11:17:21 CEST] <ubitux> yeah well it seems valgrind doesn't really care about atomics [12:00:00 CEST] <wm4> kierank: nice [12:00:33 CEST] <wm4> nevcairiel: it was, but some insisted the packet corruption was part pf abi [12:01:16 CEST] <wm4> so it'll stop doing that only once abi is bumped [12:45:19 CEST] <durandal_1707> stop the fight [13:10:12 CEST] <ubitux> http://valgrind.org/docs/manual/hg-manual.html#hg-manual.effective-use wth... [13:10:34 CEST] <ubitux> tldr: so actually helgrind can't figure out shit [13:11:02 CEST] <ubitux> "Avoid memory recycling." [13:11:09 CEST] <ubitux> "Avoid POSIX condition variables." [13:11:18 CEST] <ubitux> does that mean "avoid threading"? [13:13:51 CEST] <nevcairiel> seems a bit pointless [13:17:23 CEST] <BBB> hehehe [13:19:14 CEST] <flux> "The result of Helgrind missing some inter-thread synchronisation events is to cause it to report false positives." so you just need look deeper into them. [13:19:37 CEST] <wm4> analysis tools that generate too many false positives are useless [13:19:52 CEST] <flux> well, that is certainly true and helgrind produces a lot of diagnostics from x264 ;) [13:19:57 CEST] <ubitux> i was wondering if i could use these ANNOTATE_ macros [13:19:59 CEST] <wm4> because the time it takes to analyze those false positives manually outweights the bugs you'd find [13:20:10 CEST] <ubitux> but helgrind doesn't seem to even recognize stdatomics [13:20:18 CEST] <flux> it seemed to produce less false positives on a project I've worked on while finding actual problems. [13:20:44 CEST] <flux> as trying out helgrind is easy one could just try and see what it says. [13:21:23 CEST] <BBB> wm4: thats why I created my own runtime threading debugger for reproducing actual bugs ;) [13:21:31 CEST] <BBB> (printf") [13:22:01 CEST] <flux> works for many bugs but not for heisenbugs ;) [13:22:10 CEST] <wm4> yeah, amazes me how printf is still the most useful debugging tool [13:22:22 CEST] <BBB> flux: not true - https://blogs.gnome.org/rbultje/2014/01/12/brute-force-thread-debugging/ [13:23:19 CEST] <flux> I tried recently lttng, seems like a nice tracing framework if a bit tedious to start using. but I believe that should be low-overhead enough to remove the delay-effect of printf. [13:23:30 CEST] <flux> (well realistically almost anything is a lot faster than printf ;-)) [13:24:03 CEST] <ubitux> i only use printf for debugging, too [13:24:18 CEST] <ubitux> for threading, you often need... more [13:24:24 CEST] <ubitux> which doesn't seem to exist [13:25:24 CEST] <ubitux> the only time i use a debugger is when writing simd [13:25:35 CEST] <ubitux> and it reminds me everytime how much gdb sucks and why i never use it [13:25:55 CEST] <nevcairiel> gdb is way too l ow level [13:26:02 CEST] <nevcairiel> GUIs on top of gdb can be useful [13:27:51 CEST] <flux> is there a good GUI/TUI for GDB, though? I just use cgdb (almost daily). [13:28:28 CEST] <flux> mozilla has this tool that can replay executions under GDB. I think that might be a tool for solving heisenbugs. [13:28:58 CEST] <BBB> that sounds useful [13:29:03 CEST] <BBB> in fact, it sounds like chess ;) [13:29:12 CEST] <BBB> Ive always wished for a tool like that [13:29:31 CEST] <flux> http://rr-project.org/ [13:29:46 CEST] <ubitux> michaelni: is it possible to add mediacodec to your android builds? [13:29:50 CEST] <wm4> is there something that can go backwards yet? [13:30:03 CEST] <flux> gdb has recording as well and bandwards debugging, but it's much slower and latest ubuntu apparently broke it :( [13:30:04 CEST] <wm4> actually what I'd want is a tool that simplifies printf debugging [13:30:17 CEST] <ubitux> gdb supports backward debugging since a while [13:30:28 CEST] <flux> gdb's backwards debugging was nice if you are able to isolate the area where you need it. [13:30:40 CEST] <wm4> like, being able to set a breakpoint, that printfs an interesting set of variables if the line is executed, and only breaks if specific expressions evaluate true [13:30:54 CEST] <ubitux> also supported [13:30:55 CEST] <flux> wm4, well, conditional breaakpoints + breakpoint commands.. [13:31:06 CEST] <wm4> could never figure these out / get them working [13:31:30 CEST] <flux> I would like to be able to actally inject new C (or C++) code when running the debugger [13:31:41 CEST] <wm4> I even I still sometimes end up using glibc's backtrace function [13:32:08 CEST] <BBB> rr sounds sweet, Ill try that one day [13:32:55 CEST] <flux> the problem with gdb conditional breakpoints/commands is that they are super slow [13:41:18 CEST] <flux> on one project we had a separate tracing ring buffer for individual subsystems in memory. if (..when..) the program crashed the core dumps were delivered to us, and then there was a gdb python script that would combine and pretty print the traces. that was pretty nice and low overhead. [14:09:42 CEST] <michaelni> ubitux, added, iam not sure it will build/work though [14:19:09 CEST] <mateo`> michaelni: it should work (with gcc and clang), the code is used in production [18:25:40 CEST] <durandal_1707> anybody wants to debug dnxhdenc patch of mine? [18:47:06 CEST] <durandal_1707> anyone? [18:47:36 CEST] <atomnuker> durandal_1707: encoder? sure [18:47:51 CEST] <wm4> why debug [18:47:55 CEST] <wm4> did you mean review [18:48:43 CEST] <durandal_1707> atomnuker: dnxhd branch on github [18:50:50 CEST] <durandal_1707> wm4: its not working, somehow calculates too low number of bits [18:58:44 CEST] <atomnuker> durandal_1707: shouldn't you be setting ctx->bit_depth based on ctx->cid_table->bit_depth? [18:59:09 CEST] <atomnuker> why did you make the change to use ctx->bit_depth anyway? [18:59:19 CEST] <durandal_1707> no, as its 0 for 444 table [18:59:41 CEST] <durandal_1707> variable, can be 10 or 12 [18:59:54 CEST] <durandal_1707> cid 1270 [19:00:07 CEST] <atomnuker> why is it 0 for 444? [19:00:30 CEST] <durandal_1707> because its 10 or 12 for cid 1270 [19:01:13 CEST] <atomnuker> I see, DNXHD_VARIABLE [19:02:07 CEST] <durandal_1707> i dont get always same assert [19:02:43 CEST] <durandal_1707> seems its undefined behaviour introduced somewhere [19:03:33 CEST] <atomnuker> uninitialized vars? [19:04:04 CEST] <durandal_1707> no, out of array reads maybe [19:04:20 CEST] <atomnuker> valgrind? [19:04:22 CEST] <durandal_1707> valgrind is useless for me [19:04:40 CEST] <durandal_1707> at least with this case [19:24:23 CEST] <cone-752> ffmpeg 03Michael Niedermayer 07master:9dd1573423ca: doc/bitstream_filters: Fix project name after merge [19:24:23 CEST] <cone-752> ffmpeg 03Michael Niedermayer 07master:73fb40dc8795: avcodec/x86/idctdsp: Remove duplicate include [19:24:23 CEST] <cone-752> ffmpeg 03Michael Niedermayer 07master:0ba22831e1fc: avcodec/h264idct_template: Fix multiple runtime error: signed integer overflow [19:32:09 CEST] <ubitux> http://sprunge.us/hJFO [19:32:11 CEST] <ubitux> so [19:32:13 CEST] <ubitux> how do i fix that? :( [19:37:59 CEST] <ubitux> maybe i should just patch MAX_OFILE_ALIGNMENT in the gcc sources for djgpp [19:58:18 CEST] <ubitux> tsan instance is back btw: http://fate.ffmpeg.org/report.cgi?time=20170326174538&slot=x86_64-archlinux… [19:58:30 CEST] <ubitux> and much less noisy than helgrind afaict! [19:59:25 CEST] <ubitux> wm4: funny, it's only complaining on that async_mutex thing for the first test [19:59:45 CEST] <wm4> complaining about what? [20:00:29 CEST] <ubitux> lock-order-inversion [20:00:45 CEST] <ubitux> ThreadSanitizer: lock-order-inversion (potential deadlock) src/libavcodec/pthread_frame.c:747 in ff_frame_thread_init [20:01:47 CEST] <ubitux> it's wrt the global lock it seems [20:02:05 CEST] <wm4> ah I've been potentially worried about that too [20:02:10 CEST] <ubitux> Cycle in lock order graph: M1324 (0x7d100000dec0) => M1329 (0x7d280000ea20) => M1324 [20:02:16 CEST] <wm4> lock order doesn't seem to be defined at all for this [20:02:19 CEST] <ubitux> M1329 is the async lock [20:02:24 CEST] <ubitux> and M1324 is the global lock [20:02:35 CEST] <wm4> anyway, with the new patch the lock is a "logical" lock [20:03:26 CEST] <ubitux> heh tsan sounds pretty cool compared to helgrind [20:03:37 CEST] <ubitux> i guess i'll drop those useless helgrind and drd instances for now [20:03:44 CEST] <ubitux> they're useless [20:07:10 CEST] <ubitux> it seems tsan is mostly reporting about the global avcodec lock in all the tests [20:07:28 CEST] <ubitux> if that one gets fixed, it should silence all the noise [20:07:39 CEST] <ubitux> and we could potentially spot real races [20:07:45 CEST] <ubitux> (assuming that one isn't) [20:08:01 CEST] <wm4> the lock magaer one? [20:08:03 CEST] <wm4> *manager [20:11:54 CEST] <ubitux> the async_mutex vs the global avcodec one [20:11:58 CEST] <ubitux> the thing we just talked about [20:12:13 CEST] <ubitux> if you look at the entries in tsan, that's mostly about that [20:12:29 CEST] <ubitux> i'm curious what's remaining after it's fixed [20:16:59 CEST] <jamrial> ubitux: why do you need freedos for this merge? [20:17:55 CEST] <ubitux> jamrial: because that's how the warnings were spotted [20:17:55 CEST] <jamrial> also, last time i tried to add PRI specifiers lower than 32 i was told to not bother and keep it as %d/u [20:18:29 CEST] <jamrial> i see [20:20:03 CEST] <jamrial> ubitux: https://fate.libav.org/x86_32-freedos-gcc/20170326041147/compile [20:20:11 CEST] <ubitux> yep [20:20:12 CEST] <jamrial> "warning: alignment of 'sbr_qmf_window_ds' is greater than maximum object file alignment. Using 16 [enabled by default]" [20:20:18 CEST] <jamrial> instead of error like you got [20:20:32 CEST] <wbs> ubitux: you don't need freedos per se (only for running it), you can cross compile with djgpp from any modern/sane unix - you only need freedos/dosbox if you'd want to try to run it [20:20:32 CEST] <ubitux> yes, but that's because i'm using a more recent one i believe [20:20:41 CEST] <ubitux> s/one/gcc/ [20:20:57 CEST] <ubitux> wbs: yeah, i know, but i'm still at the compilation step :D [20:21:29 CEST] <ubitux> jamrial: it's curious btw, because it's forcing an align of 16 and doesn't seem to cause any problem at runtime [20:21:51 CEST] <ubitux> i suppose there is no 32-align compatible simd in use [20:22:51 CEST] <jamrial> 32-align is needed for avx instructions. i doubt freedos can run those :p [20:25:48 CEST] <ubitux> apparently it's not using the djgpp header with the max align, so instead i'll try to make that thing not fatal [20:26:03 CEST] <ubitux> let's hope s/error/warning/ restores properly the old behaviour [20:28:55 CEST] <ubitux> ahah it works [20:29:07 CEST] <ubitux> let's try to compile again taht stuff :) [20:30:00 CEST] <ubitux> http://b.pkh.me/max-ofile-align-warning.patch saved the day [20:35:29 CEST] <ubitux> with 3 small patches, compilation is restored for freedos [21:04:56 CEST] <ubitux> http://sprunge.us/QMWK let's go. [21:09:19 CEST] <jamrial> many of those should be reported by any compiler, like %d used for unsigned variables [21:09:33 CEST] <ubitux> i'm fixing all of them [21:09:41 CEST] <ubitux> so we can move on with the merges [21:11:33 CEST] <jamrial> i know, what i mean is that some should have been reported by other compilers but weren't [21:12:37 CEST] <jamrial> "warning: format %c expects argument of type int" [21:12:40 CEST] <jamrial> i thought %c was for char [21:13:42 CEST] <atomnuker> ubitux: I think its better to remove all instances of pow2 and instead just multiply [21:14:01 CEST] <atomnuker> we shouldn't invent functions with similar names to functions libc has [21:14:32 CEST] <atomnuker> let alone a function which directly maps to an operator (*) [21:16:02 CEST] <jkqxz> jamrial: It is. Integer promotion applies, though, so as a vararg function it takes an int. [21:17:21 CEST] <BBB> jamrial: %c has an int argument but only the lower 8 bits are interpreted for the serialization [21:17:46 CEST] <BBB> in the same way that %u and %d both take a 32bit argument but the serialization is not the same for a value like 0xFFFFFFFF [21:18:50 CEST] <cone-752> ffmpeg 03Michael Niedermayer 07master:eaf6f10f1b5c: avfilter/vf_signature: Replace uncommon spelling of seperate [21:39:22 CEST] <kierank> atomnuker: it had significant speed increases [21:39:31 CEST] <kierank> why not just define pow2() on platforms that don't have it [21:43:23 CEST] <kierank> oh i see [21:58:03 CEST] <ubitux> maybe i could check for pow2 and create a HAVE_POW2, but doing that only for djgpp sounds overkill (even though they actually have an asm optimized version of it) [22:01:17 CEST] <durandal_1707> so instead it should be deoptimized? [22:31:41 CEST] <cone-752> ffmpeg 03Mark Thompson 07master:a94972b2b2e6: ffmpeg: Remove hw_device_ctx output filter reinit hack [23:14:59 CEST] <ubitux> durandal_1707: it only affects djgpp, so who cares [23:15:16 CEST] <ubitux> i would do it if it was available on other platforms [23:15:21 CEST] <ubitux> but that doesn't seem to be the case [23:15:34 CEST] <ubitux> (otherwise we would have expected that compilation error already) [23:47:46 CEST] <ubitux> we need to make a macro like av_ts2str() with av_get_codec_tag_string()& [23:47:54 CEST] <ubitux> that will simplify a lot of the warning fixes [23:48:01 CEST] <ubitux> i guess i'll send a patch tmr [00:00:00 CEST] --- Mon Mar 27 2017

1 0

ffmpeg.log.20170326
by burek 27 Mar '17

27 Mar '17

[00:31:22 CET] <lindylex> Is there a way to maintain the the positon for the url.png in each video 10 units to the left and 10 units from the top? If I chaneg the location to start the crop it changes the url.png location. This is my command ffmpeg -i MVI_9579.MOV -i url.png -ss 00:00:14.0 -t 00:00:52.0 -codec:v libx264 -filter_complex "overlay=x=(main_w-overlay_w)/2-95:y=(main_h-overlay_h)/2-280,crop=640:640:440:50,setpts=.8*PTS" -profile:v baseline [00:31:22 CET] <lindylex> -preset slow -pix_fmt yuv420p -b:v 3500k -threads 0 -an -y 4.mp4 [00:37:32 CET] <furq> move crop before overlay? [00:42:26 CET] <lindylex> furq, let me try. [00:43:03 CET] <lindylex> I understand now why you suggested this. One sec. [00:54:52 CET] <ZeroWalker> when trying to compile x264 with msys2 msvc (for use in ffmpeg), i get complains about config.guess being too old. But i have installed automake and seem to have a newer version, but it uses one from 2009, any ideas? [01:03:12 CET] <lindylex> furq: truly thank for all your help. It helps speed up the learning of this application. You are the best! [01:11:53 CET] <lindylex> @search A Goal Digger's Guide [01:12:04 CET] <lindylex> Mistake [01:37:05 CET] <kittyfoots> im seeing some memory leaks from x264 when encoding, it seems to happen when there's an error on a frame. I've run the code through valgrind and it seems to come from x264_frame_pop_unused. Is there something I can do to release that memory? [04:19:49 CEST] <ZeroWalker> no one has any idead on my x264 question before, been searching a lot to no avail;( [05:38:24 CEST] <ZeroWalker> okay i was able to compiled x264, had to use mingw64 instead of msvc. anyhow, i can't understand how to compile ffmpeg with it. tried using ld and cl flags to point to the lib/include thing as pkg-config doesn't seem to do it automatically [05:38:47 CEST] <ZeroWalker> never had much clue about how this pkg-config stuff works so i am most likely doing something wrong [05:41:01 CEST] <ZeroWalker> JEEB, i am hinting for your assistance [05:41:14 CEST] <c3r1c3-Win> ZeroWalker: Jim created a script to cross-compile ffmpeg on linux for Windows. Have you tried that?... and actually do you run Linux at all? [05:41:45 CEST] <ZeroWalker> oh he did [05:42:04 CEST] <ZeroWalker> haven't, and no i don't run linux at all, my experience with it is close to none [05:42:18 CEST] <ZeroWalker> i am on Windows that will say [06:39:10 CEST] <ZeroWalker> so, no one;(? [08:36:08 CEST] <alexpigment> Zerowalker: I found it much much easier to cross compile ffmpeg on LInux with this script: https://github.com/rdp/ffmpeg-windows-build-helpers [08:36:50 CEST] <alexpigment> fwiw, i installed Ubuntu on a virtual machine via VMWare Workstation [08:37:06 CEST] <alexpigment> although VirtualBox (free) probably will work [08:37:23 CEST] <alexpigment> just make sure and allocation 30GB+ [08:38:06 CEST] <alexpigment> i made a tutorial too which i can give to you if you think it would help [08:42:01 CEST] <ZeroWalker> ah, would prefer to get it running on Windows, seems a bit wasteful to spend 30gb and use a virtual os just for that. I have actually done this before, somehow, with much help, don't remember any though [08:42:34 CEST] <ZeroWalker> i look at your scripts though, but can't see what's going on, it looks like ffmpeg just gets the information from --pkg-config=pkg-config [08:42:36 CEST] <kerio> why doesn't ffmpeg build in windows natively? [08:42:38 CEST] <ZeroWalker> that doesn't work for me [08:42:40 CEST] <kerio> with like mingw [08:42:59 CEST] <ZeroWalker> it does, doesn't it? [08:45:02 CEST] <furq> 30gb wtf [08:46:26 CEST] <ZeroWalker> i have x264 compiled with make install, so i would assume i just need to tell ffmpeg somehow where that is [10:34:14 CEST] <alexpigment> @furq: i was building 4 different copies - 32-bit 8-bit x26x and 10-bit x26x as well as the 64-bit versions. i hit the 20gb limit during that process on my VM [10:34:48 CEST] <alexpigment> Linux VMs are hard to expand, so i just made a 40GB VM and started again [13:29:23 CEST] <idlus> Hello, I try to capture X11 from an ssh session, and it coredumps with "operation not permitted". Is there security parameters/environment variables to set? [13:33:18 CEST] <thebombzen> idlus: the issue is your xauth [13:34:00 CEST] <thebombzen> xauth is a security that makse it so you can't interact with an X session from another tty (or ssh session) without authority [13:34:30 CEST] <flux> the ssh option ForwardX11Trusted is probably relevant. [13:34:40 CEST] <thebombzen> flux: not really [13:35:02 CEST] <idlus> I tried to set XAUTHORITY=~/.Xauthority, that did not suffice [13:35:10 CEST] <thebombzen> try also setting DISPLAY [13:35:21 CEST] <thebombzen> it also depends on your display manager [13:35:31 CEST] <thebombzen> if you use lightdm, your xauthority is in /var/run/lightdm/:0/root [13:35:32 CEST] <idlus> X11forwarding is set to yes [13:35:40 CEST] <thebombzen> X11 Forwarding with ssh allows you to start X applications on an ssh session as though it were a separate screen and forward the connection [13:35:42 CEST] <thebombzen> it's not relevant here [13:35:51 CEST] <idlus> true [13:36:09 CEST] <flux> so you're trying to capture the display of a remote host? [13:36:12 CEST] <thebombzen> idlus: is your X server from a display manager or from "startx" [13:36:22 CEST] <idlus> flux: basically yes [13:36:30 CEST] <idlus> thebombzen: from startx [13:36:45 CEST] <thebombzen> did you start it as an ordinary user as root [13:37:01 CEST] <thebombzen> but yes I'd also try setting the DISPLAY variable [13:37:04 CEST] <idlus> the same user that owns the X display [13:37:05 CEST] <thebombzen> not just XAUTHORITY [13:37:11 CEST] <flux> idlus, find a process running on the console, tr '\0' '\n' < /proc/processid/env | grep XAUTHORITY, export the XAUTHORITY to that value [13:38:12 CEST] <flux> (oh, it was /environ, not /env) [13:38:40 CEST] <idlus> yep, I figured it was environ, it gave the same value I set before [13:39:49 CEST] <idlus> thebombzen: I tried DISPLAY before (which I thought redundant with -i :0.0?), this time also with XAUTHORITY, to no avail [13:40:17 CEST] <idlus> I give you the command line in case I make an obvious mistake [13:40:27 CEST] <thebombzen> no, that's right [13:40:42 CEST] <thebombzen> it would be possibly relevant with x authority [13:40:58 CEST] <idlus> command line: DISPLAY=:0 XAUTHORITY=/home/clara/.Xauthority ffmpeg -y -f x11grab -r 25 -i :0 /tmp/v.mkv [13:42:10 CEST] <flux> idlus, are you running as used clara? [13:42:16 CEST] <flux> "user" [13:42:49 CEST] <thebombzen> idlus: either way, try this https://unix.stackexchange.com/questions/10121/open-a-window-on-a-remote-x-… [13:42:55 CEST] <thebombzen> see what this thing gives [13:43:02 CEST] <idlus> yes, technically I su clara from my default ssh user, Ill try to ssh directly as clara [13:43:20 CEST] <flux> idlus, btw, does anything work over X, such as xdpyinfo? [13:43:23 CEST] <idlus> thebombzen: thank you [13:43:51 CEST] <idlus> flux: scrot (screenshot utility) works, I tried for sanity [13:44:32 CEST] <idlus> and DISPLAY=:0 xdpyinfo as well [13:44:39 CEST] <flux> hmm, I would have expected x11grab to use the same facility as a general screenshot utility, is x11grab somehow optimized? [13:55:01 CEST] <idlus> Im not sure the problem lies with XAUTHORITY and DISPLAY, I think I set those right, Ill file a bug [15:23:39 CEST] <DHE> idlus: anything that might interfere with shared memory perhaps? ffmpeg uses shared memory extensively. performance would be terrible otherwise [15:30:31 CEST] <idlus> DHE: you mean ffmpeg needs access to X's memory? [15:42:00 CEST] <bencc1> mpeg-dash works in ios? [15:42:19 CEST] <bencc1> or do I need both hls and mpeg-dash for broad browser support? [15:43:50 CEST] <JEEB> there are SDKs for MPEG DASH but officially they support fragmented MP4 segments in HLS playlists [15:44:11 CEST] <JEEB> so you might be able to share the segments, but having two separate playlists [15:44:33 CEST] <kerio> just do hls with fmp4 [15:48:28 CEST] <DHE> idlus: yes [15:48:36 CEST] <bencc1> kerio: I'll have broad support for hls with fmp4? [15:48:54 CEST] <kerio> maybe :^) [15:49:01 CEST] <JEEB> I'm not sure of the support among stuff like exoplayer on android or hls.js on browsers [15:49:17 CEST] <kerio> surely it should be easier than remuxing mpegts into mp4 [15:49:19 CEST] <DHE> the dual playlist method looks interesting though [15:49:31 CEST] <JEEB> yes, that's what I'd do if possible [15:49:37 CEST] <JEEB> no support for both playlists yet in lavf tho [15:49:50 CEST] <kerio> honestly i'm pretty sure that the single-file playlist thing is the best thing ever [15:50:55 CEST] <bencc1> so the chunks are the same only two separate playlists point to them? [15:51:05 CEST] <JEEB> yea [15:51:10 CEST] <JEEB> one DASH and one HLS [15:51:55 CEST] <bencc1> hls use segment*.ts and playlist.m3u8 ? [15:52:01 CEST] <bencc1> or segment*.mp4? [15:52:22 CEST] <kerio> recent hls can use segment*.mp4 and playlist.m3u8 [15:52:39 CEST] <kerio> or even just a single mp4 and then byte ranges specified in the playlist [15:52:53 CEST] <JEEB> https://tools.ietf.org/html/draft-pantos-http-live-streaming-20#section-3.3 [15:52:56 CEST] <JEEB> related part of the spec [15:53:18 CEST] <bencc1> mpeg-dash can also use byte ranges in a single mp4? [15:53:25 CEST] <bencc1> can I create this mp4 in real time? [15:53:49 CEST] <kerio> yes, the point of fragmented mp4 is that you don't need to "backtrack" when writing it [15:54:04 CEST] <kerio> bencc1: https://developer.apple.com/streaming/examples/ see example here [15:54:26 CEST] <kerio> "fMP4 stream compatible with macOS v10.12 or later, iOS 10 or later, and tvOS 10 or later" [15:54:31 CEST] <kerio> so quite recent stuff [15:54:44 CEST] <bencc1> cool. thanks [19:01:18 CEST] <RonaldsMazitis> how do I convert every file in folder from mp4 to mp3 [19:01:42 CEST] <RonaldsMazitis> ok I think I got it [19:01:50 CEST] <kerio> no problem [20:01:18 CEST] <peg_the_ffm> Since this channel is publicly logged, I just want to say hi to my mom in Florida: "HI MOM" [20:06:50 CEST] <peg_the_ffm> Okay, so I use -i in.mp4 -i palette.png -lavfi "fps=25 [x]; [x][1:v] paletteuse" -f image2 out%05d.gif BUT the output is actually jpeg images with a gif extension [20:07:44 CEST] <peg_the_ffm> what I would like is individual GIF images with the -lavfi paletteuse actually being used [20:28:22 CEST] <yos> When I compile the folowing [20:28:46 CEST] <yos> #include <libavutil/avutil.h> #include <libavutil/imgutils.h> #include <libavcodec/avcodec.h> #include <libavformat/avformat.h> #include <libswscale/swscale.h> [20:29:04 CEST] <yos> int decode(AVCodecContext *avctx, AVFrame *pkt, process_frame_cb cb, void *priv) { AVFrame *frame = av_frame_alloc(); int ret; ret = avcodec_send_packet(avctx, pkt); // Again EAGAIN is not expected if (ret < 0) { av_frame_free(&frame); if (ret == AVERROR(EAGAIN)) return 0; } while (!ret) { ret = avcodec_receive_frame(avctx, frame); if (!ret) ret [20:29:55 CEST] <yos> I have an error of undifned reference to `avcodec_send_packet' [20:30:10 CEST] <yos> is thare any way to take care of it? [20:30:20 CEST] <JEEB> sounds like you're trying to use old libavcodec [20:31:17 CEST] <yos> #define LIBAVCODEC_VERSION_MAJOR 57 #define LIBAVCODEC_VERSION_MINOR 64 #define LIBAVCODEC_VERSION_MICRO 101 [20:33:32 CEST] <yos> I checked and this is the right version [20:33:54 CEST] <JEEB> yea but if it doesn't have those functions that doesn't exactly help does it [20:35:37 CEST] <yos> It has the function, but some how, the compiler dosnt see them. And I have the -lavcodec [20:36:35 CEST] <JEEB> then you're passing the wrong search paths to either I or L [20:37:01 CEST] <yos> JEEB can you explain? [20:37:30 CEST] <peg_the_ffm> how to output INDIVIDUAL .gif images but still use the -lavfi paletteuse conversion [20:37:34 CEST] <JEEB> header or library search paths [20:38:56 CEST] <BugzBunny> Hello, what would be the easiest way to concat to video files and transcode them to H.264 via VAAPI? [20:39:07 CEST] <BugzBunny> s/to/two/ [20:47:51 CEST] <peg_the_ffm> BugzBunny: probably using -f concat -i list_of_files.txt and list of files looks like this file file1.mov\nfile file2.mov\nfile file3.mov [20:48:59 CEST] <peg_the_ffm> and hello [20:49:52 CEST] Action: peg_the_ffm wonders if balrog used to hang out on #dsdev [20:50:50 CEST] <peg_the_ffm> with WinterMute & the boyz [20:53:38 CEST] <BugzBunny> peg_the_ffm, Would something like this would work http://pastebin.com/JkXkqHtW? [21:15:28 CEST] <peg_the_ffm> BugzBunny: can't see it [21:16:20 CEST] <peg_the_ffm> BugzBunny: but maybe this https://superuser.com/questions/607383/concat-two-mp4-files-with-ffmpeg-wit… [21:17:12 CEST] <peg_the_ffm> or in th edocs https://trac.ffmpeg.org/wiki/Concatenate [21:20:31 CEST] <BugzBunny> Yeah, I am looking over it, but I would preferably want hwaccel to reduce encoding time [21:20:51 CEST] <Duality> hi [21:21:05 CEST] <Duality> is there any way to disable input buffering ? [21:31:40 CEST] <ChocolateArmpits> Duality, you can try -probesize 32 or any other low value [21:31:49 CEST] <ChocolateArmpits> also there's a nobuffer flag [21:32:19 CEST] <ChocolateArmpits> ahh -fflags nobuffer [21:32:28 CEST] <ChocolateArmpits> both are input options [21:42:49 CEST] <BugzBunny> I am getting this error [concat @ 0x55ab4d3fd1a0] Line 1: unknown keyword 'intro_video.mp4', am I am doing something wrong here? [21:44:56 CEST] <ChocolateArmpits> BugzBunny, are you using a text file concatenation ? [21:48:16 CEST] <BugzBunny> Yeah, I looks I forgot to add 'file', I got further but it fails at encoder: Line 1: unknown keyword. However, I read, with dmux, both videos have to have the same codec right? [21:51:09 CEST] <BugzBunny> https://hastebin.com/unitudeqab.go [21:51:35 CEST] <BugzBunny> The exact error rather: Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height. [21:53:24 CEST] <BugzBunny> I noticed that the input file isn't added in the "stream" and I assuming that's because the second video is h.265. My end goal is concatenation two video files with different codecs via VAAPI to help speed up encoding. Doing on CPU atm, is about 2 hours each video. [22:08:28 CEST] <ChocolateArmpits> BugzBunny, when using text file concat they don't have to I believe, only when you're specifying the video files in the command line [22:08:55 CEST] <Duality> ChocolateArmpits: thanks i'll try those :) [22:11:53 CEST] <BugzBunny> Going over https://trac.ffmpeg.org/wiki/Concatenate, it appears you need to use concat filter to "Concatenation of files with different codecs", well that doesn't work as apparently I can't use filter_complex with -vf. [22:12:27 CEST] <BugzBunny> I think I am going to give on this endeavor. It's not possible. [22:13:11 CEST] <ChocolateArmpits> BugzBunny, you can specify video filters inside filter_complex just as well [22:13:34 CEST] <ChocolateArmpits> filter_complex signals that all types of filters can be used and that filter outputs can be mapped [22:13:48 CEST] <ChocolateArmpits> it's more complex but more powerful too [22:16:08 CEST] <furq> i heard a rumour that filter_complex was complex [22:16:16 CEST] <furq> but i forget where [22:16:42 CEST] <ChocolateArmpits> must've been me [22:18:09 CEST] <ChocolateArmpits> BugzBunny, So in your case it could be something like -filter_complex [0:v][1:v]concat=n=2:v=1:a=1[v1][aout];[v1]format=nv12,hwupload[vout] -map [vout]:v -map [aout]:a [22:18:17 CEST] <ChocolateArmpits> oh wait [22:18:23 CEST] <ChocolateArmpits> BugzBunny, So in your case it could be something like -filter_complex [0][1]concat=n=2:v=1:a=1[v1][aout];[v1]format=nv12,hwupload[vout] -map [vout]:v -map [aout]:a [22:18:35 CEST] <BugzBunny> Let me give it a shot [22:18:38 CEST] <ChocolateArmpits> or maybe something like that [22:18:46 CEST] <ChocolateArmpits> you need to try the input mapping for the concat filter [22:18:48 CEST] <ChocolateArmpits> with your source [22:18:56 CEST] <furq> you don't need to map the inputs to concat if they're in the right order [22:18:58 CEST] <furq> which is useful [22:19:02 CEST] <ChocolateArmpits> I'm not sure if you need to specify each stream separately there [22:19:11 CEST] <ChocolateArmpits> or maybe that [22:19:20 CEST] <furq> e.g. if you have file1.mp4 and file2.mp4 and they both have the same number of video/audio streams as specified in the concat filter [22:19:41 CEST] <furq> just -i file1.mp4 -i file2.mp4 -filter_complex concat=2:1:1 will work [22:24:32 CEST] <BugzBunny> Alright, for the simpler version, how would I incorporate format=nv12,hwupload? [22:26:13 CEST] <furq> -filter_complex "concat=2:1:1[tmp][a];[tmp]format=nv12,hwupload[v]" -map "[v]" -map "[a]" [22:26:34 CEST] <BugzBunny> Thanks. [22:29:57 CEST] <BugzBunny> Alright, now trying to figure why it's failing: https://hastebin.com/ofabewufab.sql. Error Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height. Can't tell yet if this is the culprit: [h264_vaapi @ 0x563e95540540] B frames are not supported (1). [22:30:33 CEST] <BugzBunny> My GPU doesn't not support B Frames in hardware period. I am not sure if that's ignored. [22:30:53 CEST] <furq> Reading option '-bf' ... matched as AVOption 'bf' with argument '2'. [22:31:14 CEST] <furq> that's probably wrong if your encoder doesn't support bframes [22:33:59 CEST] Action: BugzBunny is googling [23:02:08 CEST] <BugzBunny> I got it to do something, but it seems like it segfault [23:02:44 CEST] <BugzBunny> "[1] 16639 floating point exception (core dumped) ffmpeg -loglevel debug -hwaccel vaapi -vaapi_device :0 -i intro_video.mp4 -i " [00:00:00 CEST] --- Mon Mar 27 2017

1 0