Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

March 2017

1 participants
62 discussions

ffmpeg-devel.log.20170320
by burek 21 Mar '17

21 Mar '17

[00:24:15 CET] <michaelni> ubitux, iam surprised they are unused but yes if they are you can drop them [01:34:30 CET] <cone-434> ffmpeg 03Michael Niedermayer 07master:5d996b56499f: avcodec/tiff: Check stripsize strippos for overflow [01:34:30 CET] <cone-434> ffmpeg 03Michael Niedermayer 07master:a84d610b372c: avcodec/h264_direct: Fix runtime error: signed integer overflow: -9 - 2147483647 cannot be represented in type 'int' [01:34:30 CET] <cone-434> ffmpeg 03Michael Niedermayer 07master:98da63b3f5f5: avcodec/vp56: Check avctx->error_concealment before enabling EC [02:39:52 CET] <cone-434> ffmpeg 03Michael Niedermayer 07master:656a17e126c0: avcodec/mjpegdec: Check quant_matrixes values for being non zero [02:39:53 CET] <cone-434> ffmpeg 03Michael Niedermayer 07master:23f3f92361a3: avcodec/mjpegdec: quant_matrixes can be up to 65535, use uint16_t [05:35:34 CET] <wm4> is it just me or does git://source.ffmpeg.org/ffmpeg.git not work [05:35:40 CET] <wm4> fatal: read error: Connection reset by peer [08:01:47 CET] <ubitux> wm4: works fine here [08:02:36 CET] <wm4> still doesn't work here [08:02:55 CET] <wm4> oh on the second and third tries it worked [08:03:25 CET] <wm4> actually works sporadically [08:06:33 CET] <cone-785> ffmpeg 03Clément BSsch 07master:08e1376d81f3: fate: add fate-sws-pixdesc-query [08:06:33 CET] <cone-785> ffmpeg 03Clément BSsch 07master:f052b1b40f94: swscale: use a function for isGray [08:06:33 CET] <cone-785> ffmpeg 03Clément BSsch 07master:9c2436e1e78f: lavu: add AV_PIX_FMT_FLAG_BAYER [08:06:33 CET] <cone-785> ffmpeg 03Clément BSsch 07master:c30875e8b2bd: swscale: use a function for isBayer [08:06:33 CET] <cone-785> ffmpeg 03Clément BSsch 07master:2b9a52bcca7d: swscale: use a function for isAnyRGB [08:06:33 CET] <cone-785> ffmpeg 03Clément BSsch 07master:ff6bc16c5ad9: swscale: use a (more correct) function for isPacked [08:06:33 CET] <cone-785> ffmpeg 03Clément BSsch 07master:d6635daded80: swscale: remove unused is{RGB,BGR}inBytes [08:06:34 CET] <cone-785> ffmpeg 03Clément BSsch 07master:e811f84a2ed0: swscale: cosmetics in is{RGB,BGR}inInt [08:08:43 CET] <cone-785> ffmpeg 03Derek Buitenhuis 07master:eb96505b761e: mov: Remove ancient heuristic hack [08:08:44 CET] <cone-785> ffmpeg 03Clément BSsch 07master:64722057b41d: Merge commit 'eb96505b761eb02b6a3efc76d854afa6a41941ff' [08:09:50 CET] <cone-785> ffmpeg 03Derek Buitenhuis 07master:8db804e8f549: mov: Remove old b-frame/video delay heuristic [08:09:51 CET] <cone-785> ffmpeg 03Clément BSsch 07master:6557d784d21d: Merge commit '8db804e8f549d5b86a1edf62736e0ef80f160da9' [08:11:34 CET] <cone-785> ffmpeg 03Clément BSsch 07master:5e5e7935523d: doc/APIchanges: fill date & hash for AV_PIX_FMT_FLAG_BAYER [08:13:37 CET] <cone-785> ffmpeg 03Vittorio Giovara 07master:95f80293456d: avprobe: Fix memory leak [08:13:38 CET] <cone-785> ffmpeg 03Clément BSsch 07master:b1a80bdb62ae: Merge commit '95f80293456d9d4b1b096621260c38bc90325ec0' [08:17:33 CET] <cone-785> ffmpeg 03Burt P 07master:728e80cd2e1d: High Definition Compatible Digital (HDCD) decoder filter, using libhdcd [08:17:34 CET] <cone-785> ffmpeg 03Clément BSsch 07master:45982bdcd0d2: Merge commit '728e80cd2e1d4b7c3e26489efcd77bd7a9e84a99' [08:19:25 CET] <cone-785> ffmpeg 03Vittorio Giovara 07master:80fc75d51e33: Changelog: Mention mov with multiple stsd [08:19:26 CET] <cone-785> ffmpeg 03Clément BSsch 07master:e514a1d4047f: Merge commit '80fc75d51e3312e1890591048eb6a3d499b6e49d' [08:21:38 CET] <cone-785> ffmpeg 03Diego Biurrun 07master:72eba6558ee4: wmavoice: Simplify GetBitContext initialization [08:21:39 CET] <cone-785> ffmpeg 03Clément BSsch 07master:464fcc979c50: Merge commit '72eba6558ee4f10239ba3f472c0b033ec70082a7' [08:25:44 CET] <cone-785> ffmpeg 03Mark Thompson 07master:123ccd07c55c: lavc: Rewrite VAAPI decode infrastructure [08:25:45 CET] <cone-785> ffmpeg 03Mark Thompson 07master:2fe93244ab94: vaapi_h264: Convert to use the new VAAPI hwaccel code [08:25:46 CET] <cone-785> ffmpeg 03Mark Thompson 07master:102e13c353de: vaapi_mpeg2: Convert to use the new VAAPI hwaccel code [08:25:47 CET] <cone-785> ffmpeg 03Mark Thompson 07master:520fb77285ff: vaapi_vc1: Convert to use the new VAAPI hwaccel code [08:25:48 CET] <cone-785> ffmpeg 03Mark Thompson 07master:ccd0316f7cab: vaapi_mpeg4: Convert to use the new VAAPI hwaccel code [08:25:49 CET] <cone-785> ffmpeg 03Mark Thompson 07master:3e8651a7ccd8: avconv_vaapi: Convert to use hw_frames_ctx only [08:25:50 CET] <cone-785> ffmpeg 03Mark Thompson 07master:851960f6f8cf: lavc: Remove old vaapi decode infrastructure [08:25:51 CET] <cone-785> ffmpeg 03Clément BSsch 07master:518961bc99b9: Merge commit '851960f6f8cf1f946fe42fa36cf6598fac68072c' [08:26:54 CET] <cone-785> ffmpeg 03Anton Khirnov 07master:24da43032473: Changelog: mark the release 12 branch [08:26:55 CET] <cone-785> ffmpeg 03Clément BSsch 07master:5d2354327725: Merge commit '24da430324735f95880c4a4a54298dc8023125bb' [08:31:22 CET] <ubitux> nevcairiel: ping [08:37:12 CET] <ubitux> actually, maybe wm4 knows too: ping :) [08:37:18 CET] <cone-785> ffmpeg 03Anton Khirnov 07master:d7bc52bf456d: imgutils: add a function for copying image data from GPU mapped memory [08:37:19 CET] <cone-785> ffmpeg 03Clément BSsch 07master:8200b16a9c77: Merge commit 'd7bc52bf456deba0f32d9fe5c288ec441f1ebef5' [08:38:01 CET] <ubitux> wm4: the next commit applies cleanly, but we have some differences in dxva [08:38:14 CET] <ubitux> would you mind merging it and test it? [08:39:05 CET] <ubitux> michaelni: opinion on the drop of memalign hack? [08:39:11 CET] <ubitux> (4fb311c804098d78e5ce5f527f9a9c37536d3a08) [08:39:49 CET] <ubitux> i think it's the followup of 46e3936fb04d06550151e667357065e3f646da1a [08:44:28 CET] <wm4> ubitux: which hash? [08:44:51 CET] <ubitux> f01f7a7846529b7c3ef343f117eaa2c0a1457af0 [08:46:52 CET] <wm4> ubitux: I think if it applies cleanly it should be fine [08:46:58 CET] <ubitux> ok [08:48:04 CET] <cone-785> ffmpeg 03Anton Khirnov 07master:f01f7a784652: hwcontext_dxva2: use the special UC copy for downloading frames [08:48:05 CET] <ubitux> thanks [08:48:05 CET] <cone-785> ffmpeg 03Clément BSsch 07master:a5cf6628d68e: Merge commit 'f01f7a7846529b7c3ef343f117eaa2c0a1457af0' [08:48:16 CET] <ubitux> alright, now the memalign hack... [08:48:47 CET] <ubitux> anyone has an opinion on this one? [08:49:32 CET] <wm4> fuck those hacks with a rusty rake [08:50:05 CET] <wm4> they're surely not needed anymore, but of course SOMEONE in ffmpeg will argue for keeping them "just in case" or because $FUCKED_UP_OLD_ENVIRONMENT [08:50:20 CET] <wm4> (if this is what I think it's about) [08:53:11 CET] <ubitux> ok :) [08:53:31 CET] <rcombs> does anything actually have neither memalign nor anything like it? [08:53:54 CET] <ubitux> the mingw case seems to have been avoided by 46e3936fb04d06550151e667357065e3f646da1a [08:57:22 CET] <cone-785> ffmpeg 03Diego Biurrun 07master:4fb311c80409: Drop memalign hack [08:57:23 CET] <cone-785> ffmpeg 03Clément BSsch 07master:3835283293bf: Merge commit '4fb311c804098d78e5ce5f527f9a9c37536d3a08' [09:18:31 CET] <cone-785> ffmpeg 03Diego Biurrun 07master:746c56b7730c: indeo: Change type of array pitch parameters to ptrdiff_t [09:18:32 CET] <cone-785> ffmpeg 03Diego Biurrun 07master:21e500ba647a: svq1dec: Change type of array pitch parameters to ptrdiff_t [09:18:33 CET] <cone-785> ffmpeg 03Clément BSsch 07master:bb3ad401fc65: Merge commit '746c56b7730ce09397d3a8354acc131285e9d829' [09:18:34 CET] <cone-785> ffmpeg 03Clément BSsch 07master:e59d8d030fd4: Merge commit '21e500ba647aec233d5930d3d1081489d0d53ceb' [09:25:42 CET] <cone-785> ffmpeg 03Diego Biurrun 07master:73f5e17a2037: copy_block: Change type of array stride parameters to ptrdiff_t [09:25:43 CET] <cone-785> ffmpeg 03Clément BSsch 07master:21c18b087822: Merge commit '73f5e17a203713c4ac4e5a821809823b383b195f' [09:25:44 CET] <cone-785> ffmpeg 03Clément BSsch 07master:64926292a68a: lavc/copy_block: style fix [09:26:14 CET] <nevcairiel> ubitux: the dxva changes are indeed fine, just in case you look for confirmation after the fact =p [09:26:34 CET] <ubitux> wm4 took responsibility so i'm safe ;) [09:26:36 CET] <ubitux> thanks :) [09:26:53 CET] <wm4> sure I'll take any blame [09:30:32 CET] <ubitux> ah, didn't take long before the memalign thing made someone angry [09:31:04 CET] <ubitux> michaelni: zhouxiaoyong(a)loongson.cn doesn't seem to exist anymore; are you still in contact with them? [09:31:35 CET] <ubitux> i want to poke them about updating the copy_block*_mmi prototypes in libavcodec/mips/h264qpel_mmi.c after the merge of 73f5e17a20 [09:37:34 CET] <wm4> who got angry? [09:37:52 CET] <ubitux> it was on cvslog, i forwarded [09:38:27 CET] <wm4> oh. [09:38:49 CET] <wm4> what next crash is he talking about [09:38:59 CET] <wm4> and why would freebsd not have a posix function [09:42:35 CET] <nevcairiel> its carl, he typically doesnt make much sense [09:44:52 CET] <cone-785> ffmpeg 03Diego Biurrun 07master:5b5ed92d9225: sanm: Change type of array pitch parameters to ptrdiff_t [09:44:53 CET] <cone-785> ffmpeg 03Clément BSsch 07master:7317b69630de: Merge commit '5b5ed92d92252a685e891a5d636870e223b63228' [09:46:56 CET] <cone-785> ffmpeg 03Diego Biurrun 07master:2610c9528f86: configure: Move initial VAAPI check to a more sensible place [09:46:57 CET] <cone-785> ffmpeg 03Clément BSsch 07master:6d6f79c737d4: Merge commit '2610c9528f86286e4c6e174411a26ff5b4815cde' [09:49:05 CET] <cone-785> ffmpeg 03Diego Biurrun 07master:b8c2d407efa4: configure: Simplify libopenjpeg check [09:49:07 CET] <cone-785> ffmpeg 03Clément BSsch 07master:715f781834bb: Merge commit 'b8c2d407efa41c3db6813ad67fadd51b814765bd' [09:49:07 CET] <michaelni> ubitux, why do you ask and then push 4fb311c80409 ? [09:49:55 CET] <ubitux> i assumed it wasn't a problem anymore [09:50:08 CET] <ubitux> it can still be reverted, there is nothing stacked upon [09:50:20 CET] <ubitux> any reason to keep it? [09:51:06 CET] <michaelni> whateveraliged() + realloc()/free()/... is supposedly not safe on various places [09:51:21 CET] <michaelni> some memory debugger at least had an issue [09:51:25 CET] <durandal_1707> what? [09:52:53 CET] <michaelni> libav seperates realloc() and malloc() we dont we use the memalign hack to handle these very obscure corner cases IIRC [09:52:56 CET] <durandal_1707> so it should then be alwaya enabled as we like hacks [09:54:15 CET] <michaelni> ill leave this to others, iam not interrested in trolling [09:54:52 CET] <ubitux> michaelni: sorry i don't understand what you're saying wrt realloc [09:54:59 CET] <durandal_1707> its named hack after all [09:55:17 CET] <ubitux> michaelni: i'm looking for a concrete example where it breaks [09:55:26 CET] <nevcairiel> ubitux: apparently on some systems its unsupported to call realloc on a pointer created by memalign [09:55:35 CET] <nevcairiel> not sure if we actually have any where this applies [09:55:45 CET] <nevcairiel> since i doubt most people even build with the hack e nabled [09:56:29 CET] <durandal_1707> i encountered some [09:56:46 CET] <nevcairiel> the only people you commonly see using the hack are people on windows that cargo-culted the command line from several decades ago [09:57:09 CET] <ubitux> are we actually supposed to support realloc on memaligned allocated buffer? [09:57:41 CET] <wm4> <michaelni> ill leave this to others, iam not interrested in trolling <- so you admit arguing against this merge is trolling? wow [09:57:46 CET] <ubitux> * @warning Unlike av_malloc(), the returned pointer is not guaranteed to be [09:57:48 CET] <ubitux> * correctly aligned. [09:57:56 CET] <durandal_1707> when we call memalign? [09:57:59 CET] <michaelni> ubitux, as it works almost everywhere its very hard to maitain seperation [09:58:47 CET] <nevcairiel> clearly everyone should be using windows where there is an aligned realloc function </troll [09:59:16 CET] <michaelni> also specs dont allow memalign() + free(), memalign hack would allow support for such systems too [09:59:33 CET] <nevcairiel> how are you supposed to free that memory then [09:59:35 CET] <michaelni> wm4, do not slander me [10:00:03 CET] <durandal_1707> but hack is not enabled automagically? [10:00:04 CET] <michaelni> nevcairiel, memalign hack uses malloc() [10:00:10 CET] <nevcairiel> posix specs do say free should work on memalign'ed memory [10:01:14 CET] <ubitux> can we add a FATE test doing a bunch of alloc-realloc and assert if misalign to detect such platforms on FATE? [10:01:32 CET] <michaelni> we could i guess [10:01:59 CET] <ubitux> i'll revert (or someone else will) if such a case is present [10:02:30 CET] <durandal_1707> is there FATE instance with this option? [10:02:41 CET] <michaelni> ubitux, i doubt we have a fate client affeced [10:03:08 CET] <wm4> <michaelni> wm4, do not slander me <- uh what [10:03:28 CET] <michaelni> anyway, asking me, then pushing before i reply and then attacking me when i reply is pretty lame [10:03:37 CET] <wm4> michaelni: so you didn't mean _you_ are trolling, but others are (including me), so wouldn't this mean that you've slandered me? [10:04:05 CET] <wm4> but as usual you're wasting our time arguing about unimportant obscurities just because you don't like cleanups [10:04:27 CET] <durandal_1707> i doubt having options for unreproducible problems is way to go [10:04:31 CET] <michaelni> wm4, you made a false statement about what i meant and you repeat now other false statements [10:04:36 CET] <michaelni> wm4 stop this [10:05:01 CET] <wm4> michaelni: how does "iam not interrested in trolling" not mean "I am not interested in trolling (you)" [10:05:22 CET] <wm4> michaelni: and the other interpretation, how does it not mean you accuse us of trolling? [10:05:32 CET] <durandal_1707> i just ignore personal vendetas [10:05:40 CET] <michaelni> i do accuse some here of trolling yes [10:07:39 CET] <wm4> michaelni: ok stop slandering me too, then [10:08:14 CET] <wm4> always the same shit [10:11:47 CET] <ubitux> note that i'm ok to revert if it's actually breaking something [10:12:03 CET] <ubitux> (if that wasn't already obvious) [10:12:42 CET] <durandal_1707> its already said that it breaks some obscure configuration [10:13:25 CET] <durandal_1707> "breaks" because option is not auto enabled afaik [10:15:12 CET] <wm4> still looking for proof that anything was actually broken [10:46:57 CET] <cone-785> ffmpeg 03Clément BSsch 07master:d0db00c80886: configure: remove pod2man from the config list [10:47:24 CET] <cone-785> ffmpeg 03Diego Biurrun 07master:0e5dde739943: configure: Fix --disable-pod2man / --disable-texi2html [10:47:25 CET] <cone-785> ffmpeg 03Clément BSsch 07master:4ae80c375398: Merge commit '0e5dde739943168d6f61d3fb40b3f622e7abfeff' [10:48:36 CET] <ubitux> what's the pipe for in a make dependency list? [10:48:45 CET] <ubitux> (refering to 3aa9d37d03da3c9b482d19b3988659287815280e) [10:49:59 CET] <wbs> ubitux: https://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html [10:50:13 CET] <wm4> wbs was faster [10:50:36 CET] <ubitux> oooh i was wondering how to do that the other day [10:50:38 CET] <ubitux> thanks! [10:57:32 CET] <ubitux> i'm not sure we actually need that commit sinces we have a bunch of mkdir in our configure [10:58:30 CET] <nevcairiel> the commit doesnt exactly elaborate what kind of failure condition it fixes [10:59:00 CET] <ubitux> it might be useful it cases such as make tests/pixfmts.mak when nothing is generated yet [10:59:44 CET] <ubitux> i guess it doesn't hurt [10:59:51 CET] <ubitux> i'll merge it [11:02:20 CET] <cone-785> ffmpeg 03Diego Biurrun 07master:3aa9d37d03da: build: Fix directory dependencies of tests/pixfmts.mak target [11:02:21 CET] <cone-785> ffmpeg 03Clément BSsch 07master:38343651a82f: Merge commit '3aa9d37d03da3c9b482d19b3988659287815280e' [11:06:35 CET] <cone-785> ffmpeg 03Diego Biurrun 07master:ec903058447a: configure: Simplify clock_gettime() test [11:06:36 CET] <cone-785> ffmpeg 03Clément BSsch 07master:100026bed651: Merge commit 'ec903058447ad5be34d89533962e9ae1aa1c78f7' [11:16:12 CET] <cone-785> ffmpeg 03Diego Biurrun 07master:6b52762951fa: error_resilience: Change type of array stride parameters to ptrdiff_t [11:16:13 CET] <cone-785> ffmpeg 03Clément BSsch 07master:d36a42344525: Merge commit '6b52762951fa138eef59e2628dabb389e0500e40' [11:20:52 CET] <ubitux> that next commit sounds pretty wrong [11:21:30 CET] <ubitux> he didn't seem to have updated the filter_flt prototype [11:21:51 CET] <ubitux> (in the context) [11:22:04 CET] <ubitux> and he a log.h dubious include [11:23:01 CET] <wbs> ubitux: there's no such context in the code where it came from [11:23:40 CET] <ubitux> oh indeed, that's only used by the mips code, my bad [11:23:43 CET] <ubitux> thanks [11:28:58 CET] <cone-785> ffmpeg 03Diego Biurrun 07master:52730e0f867f: iir_filter: Change type of array stride parameters to ptrdiff_t [11:28:59 CET] <cone-785> ffmpeg 03Clément BSsch 07master:8316a0e08b89: Merge commit '52730e0f867fe77b7d2353d8b44e92edb7079ca5' [11:34:48 CET] <cone-785> ffmpeg 03Diego Biurrun 07master:131a85a1fed9: utvideo: Change type of array stride parameters to ptrdiff_t [11:34:49 CET] <cone-785> ffmpeg 03Clément BSsch 07master:eed8ccde3e56: Merge commit '131a85a1fed9966bbd38517f76abfac0237e39dc' [11:35:55 CET] <ubitux> jkqxz: do you mind merging your vp8 hwaccel commits? [11:43:29 CET] <wm4> didn't he post them on the ML? [11:47:24 CET] <ubitux> ah? [11:48:13 CET] <ubitux> oh indeed [11:49:09 CET] <ubitux> i'll skip them then [11:54:39 CET] <cone-785> ffmpeg 03Mark Thompson 07master:4e528206bc4d: vp8: Add hwaccel hooks [11:54:40 CET] <cone-785> ffmpeg 03Mark Thompson 07master:a9fb134730da: lavc/vaapi: Add VP8 decode hwaccel [11:54:41 CET] <cone-785> ffmpeg 03Mark Thompson 07master:11c191b52ce0: vaapi_decode: Ignore the profile when not useful [11:54:42 CET] <cone-785> ffmpeg 03Mark Thompson 07master:75d642a944d5: vaapi_vp8: Explicitly include libva vp8 decode header [11:54:43 CET] <cone-785> ffmpeg 03Clément BSsch 07master:9785b1e21be1: Merge commit '75d642a944d5579e4ef20ff3701422a64692afcf' [11:56:43 CET] <cone-785> ffmpeg 03Luca Barbato 07master:e89cef40506d: checkasm: Read the unsigned value as it should [11:56:44 CET] <cone-785> ffmpeg 03Clément BSsch 07master:3c8f7a8f6b52: Merge commit 'e89cef40506d990a982aefedfde7d3ca4f88c524' [11:58:36 CET] <cone-785> ffmpeg 03Luca Barbato 07master:caccb3a0cdc7: audiodsp: ppc: Add VSX variant [11:58:37 CET] <cone-785> ffmpeg 03Clément BSsch 07master:9e8fd5c423da: Merge commit 'caccb3a0cdc7ee32cbed7eab156d35025133eadc' [12:02:49 CET] <ubitux> mmh [12:03:31 CET] <ubitux> so our ppc actually support BE [12:03:53 CET] <nevcairiel> ppc is primarily be [12:06:41 CET] <ubitux> sorry, i meant LE [12:07:27 CET] <cone-785> ffmpeg 03Diego Biurrun 07master:6ce93757ee6b: ppc: Update #endif comments [12:07:28 CET] <cone-785> ffmpeg 03Clément BSsch 07master:7c54e5870f2c: Merge commit '6ce93757ee6b81fe727bfdc9f546fd0ddf9139c3' [12:08:39 CET] <cone-785> ffmpeg 03Diego Biurrun 07master:468bfe38c66d: ppc: mpegvideo: Add proper runtime AltiVec detection [12:08:40 CET] <cone-785> ffmpeg 03Clément BSsch 07master:8e9dfe0d298b: Merge commit '468bfe38c66d4d020984158e53b09a6a5749f394' [12:23:47 CET] <cone-785> ffmpeg 03Diego Biurrun 07master:ab3554e1a7c0: configure: Drop check_lib()/require() in favor of check_lib2()/require2() [12:23:48 CET] <cone-785> ffmpeg 03Clément BSsch 07master:4563a86f011b: Merge commit 'ab3554e1a7c04a5ea30f9c905de92348478ef7c8' [12:43:49 CET] <jkqxz> I did put them on the ML twice, but I didn't really care very much and they got bikeshedded so I gave up. [13:40:25 CET] <ubitux> jkqxz: so you don't want to handle this with the suggested change from wm4 & michaelni? [13:47:01 CET] <jkqxz> I don't much like the idea of adding hacks to a clean decoder which does get some use to "fix" a terrible one that is barely used at all and which should never have been written like that in the first place. [13:48:22 CET] <ubitux> okay [13:48:37 CET] <ubitux> i won't fix it either, it's in the libav merge doc anyway [13:54:00 CET] <wm4> is this still about the vp8 hwaccel? [13:56:22 CET] <ubitux> yes [13:56:24 CET] <ubitux> vp8/ebp [13:56:27 CET] <ubitux> webp* [14:29:47 CET] <feliwir> hey, what is the exact purpose of using those macros: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/get_bits.h#L554 [14:30:10 CET] <feliwir> (why using macros instead of inline functions?) [14:31:01 CET] <wm4> feliwir: well, some declare variables [14:31:13 CET] <wm4> how would that work with inline functions? [14:31:26 CET] <wm4> also, bad compilers [14:31:39 CET] <feliwir> well not at all, but this is hardly readable/understandable [14:31:47 CET] <wm4> BBB: any chance you could look at those threading patches I've merged from Libav and posted on the ML? [14:31:59 CET] <BBB> any specifically? [14:32:43 CET] <wm4> BBB: hm, all of them I guess [14:32:50 CET] <atomnuker> feliwir: its a bitstream reader, just write one yourself, it takes like an hour and its fun [14:33:17 CET] <BBB> wm4: 1/9 is ok [14:33:21 CET] <feliwir> well the combination with get_vlc2 makes it difficult :D [14:33:26 CET] <wm4> feliwir: the way it's implemented sure is unreadable, although the functions should be rather easy to use [14:33:43 CET] <BBB> wm4: 2/9 is ok [14:34:02 CET] <wm4> BBB: that's a suspiciously quick review [14:34:17 CET] <BBB> wm4: Ive seen these two before, they were sent by chrome devs [14:34:27 CET] <wm4> yes, but the ffmpeg code is different [14:34:38 CET] <BBB> they were initially sent here [14:34:40 CET] <BBB> theyre fine [14:34:53 CET] <wm4> eh then I should compare them to the initial patches [14:34:56 CET] <BBB> I told them to send them to libav because anton was planning to do the same thing and I wanted to prevent the chaos from getting worse [14:35:07 CET] <wm4> and that was good [14:35:12 CET] <BBB> (50% chance that he chooses another solution and crap goes to shit even worse) [14:35:37 CET] <BBB> 3/9 is probably ok but maybe ask btbn or so? [14:35:59 CET] <BBB> 4/9 same [14:36:15 CET] <BBB> 5/9 is ok [14:37:10 CET] <BBB> 6/9 same as 3-4 [14:37:11 CET] <BtbN> I don't think the series affects cuvid/nvenc/cuda at all. As they don't use threads themselves, and are not hooked into external decoders. [14:38:38 CET] <BBB> 7/9 is probably fine, I am assuming you tested it in the relevant settings with dxva2 to make sure it works? [14:38:49 CET] <BBB> 8/9 is ok [14:39:00 CET] <BBB> 9/9 is ok [14:40:18 CET] <wm4> I didn't test with dxva yet, but with others [14:40:35 CET] <wm4> and yes, it only affects "classic" hwaccels [14:41:56 CET] <BBB> I would probably suggest testing it with dxva2 if that is practical [14:42:16 CET] <wm4> I will [14:42:31 CET] <BBB> ty [14:42:33 CET] <BBB> no comments then [14:42:33 CET] <wm4> I mean, I'm convinced that it works as well or as badly as say vaapi [14:42:35 CET] <BBB> :) [14:42:53 CET] <BBB> I guess I should commit the first few gsoc qualification task patches [14:46:48 CET] <durandal_1707> BBB: which ones? [14:46:55 CET] <BBB> vp8 tm avx2 [14:47:04 CET] <BBB> and vp9 ddl avx2 16x16 [14:47:06 CET] <RiCON> ubitux: xavs and probably x264 checks are probably broken with 4563a86f011 [14:47:09 CET] <BBB> vp8 tm avx2 is also 16x16 [14:47:55 CET] <ubitux> RiCON: broken how? [14:48:09 CET] <ubitux> did i derped the merge or the original commit is problematic? [14:48:14 CET] <RiCON> they need stdint.h before {xavs,x264}.h [14:48:28 CET] <jamrial> don't those use pkgconfig? [14:48:33 CET] <RiCON> x264 does [14:48:35 CET] <RiCON> xavs doesn't [14:48:35 CET] <jamrial> and not check_lib or require [14:48:38 CET] <jamrial> ah [14:48:52 CET] <RiCON> and if there's no pkgconfig x264 will probably fail [14:49:01 CET] <RiCON> since it's also missing stdint.h [14:51:31 CET] <ubitux> i don't see how that's a problem [14:51:50 CET] <ubitux> i didn't drop the stdint.h [14:52:27 CET] <jamrial> just tried wihtout pkgconfig. stdint.h is included but after x264.h so it breaks [14:53:19 CET] <jamrial> god, configure is painfully slow on windows [14:53:26 CET] <cone-785> ffmpeg 03Ronald S. Bultje 07master:f3cd2302a9c9: wmavoice: remove unused or write-only variables. [14:53:27 CET] <cone-785> ffmpeg 03Mirage Abeysekara 07master:5eb4f95bef2f: h264pred: added AVX2 implementation for tm_vp8 16x16. [14:53:28 CET] <cone-785> ffmpeg 03Ilia 07master:2f3d10a01ac5: avcodec/vp9: avx2 implementation of ipred_dl_16x16_16 [14:54:20 CET] <ubitux> jamrial: but what's different with previously? [14:54:42 CET] <DHE> can confirm x264 now fails without pkg-config whereas it did work before [14:54:45 CET] <jamrial> no idea if it's different. always used pkgconfig [14:54:48 CET] <DHE> (with warning) [14:55:24 CET] <jamrial> i'm trying a fix [14:55:35 CET] <ubitux> adding stdint.h to the require? [14:55:35 CET] <RiCON> couldn't the stdint.h always be before the added headers? [14:56:05 CET] <RiCON> or would that break if the headers then add stdint.h again? [14:56:15 CET] <ubitux> i understand it's broken now, but i don't understand how it's a regression [14:56:16 CET] <jamrial> http://pastebin.com/raw/JZK3ni1r seems to fix it [14:56:37 CET] <ubitux> jamrial: yes, exactly my thought; but can you confirm it worked before the merge? [14:56:49 CET] <jamrial> DHE did [14:57:45 CET] <ubitux> i'm actually confused how it could work [14:57:53 CET] <DHE> quick fix: http://pastebin.com/FPYTqhjQ [14:58:02 CET] <DHE> not sure HOW it broke, but it did [15:00:01 CET] <RiCON> 'check_header $header && check_func $func "$@"' does not do the same as 'check_func_headers "$headers" "$funcs" "$@"' [15:04:22 CET] <ubitux> olol check_func_headers has a stdint.h [15:04:37 CET] <RiCON> i can confirm http://sprunge.us/FTJV fixes it [15:05:39 CET] <ubitux> can you make a proper patch, including the regression hash in the description and an explanation about check_func_headers having stdint.h? [15:05:52 CET] <ubitux> and apply or share the patch [15:07:27 CET] <jamrial> http://pastebin.com/raw/3XUG8Pqq completely different checks [15:07:53 CET] <RiCON> oh, libav's xavs check does have stdint.h [15:08:05 CET] <jamrial> before this merge the check just made sure x264.h existed, but didn't actually try to use it [15:08:59 CET] <RiCON> ubitux: 20abcaa273a6 will fix it too [15:09:23 CET] <ubitux> ah sorry i missed that [15:09:30 CET] <ubitux> care to format your patch with both anyway? [15:13:23 CET] <rounaq> Hi. Sorry to interrupt an ongoing conversation. I am new to audio/video formats and other related areas. Is there a good reference to study all these terms so that I can understand the terms like "square decoder" etc. [15:15:36 CET] <durandal_1707> rounaq: if this is about gsoc, too late, another student completed that qualification task [15:16:00 CET] <RiCON> ubitux: http://sprunge.us/RYPQ how's that? [15:16:43 CET] <rounaq> Okay. No problem. But I would like to learn anyway. Thanks [15:17:03 CET] <ubitux> RiCON: LGTM; do you have push access? [15:17:07 CET] <RiCON> no [15:17:12 CET] <ubitux> ok will apply in a moment [15:19:03 CET] <cone-785> ffmpeg 03Ricardo Constantino 07master:20c4fb2e010f: configure: add stdint.h to x264 and xavs checks [15:19:06 CET] <ubitux> RiCON: thanks [15:37:25 CET] <cone-785> ffmpeg 03Paul B Mahol 07master:ce818d90bdb2: avcodec/wmaprodec: reset offsets when error happens [15:56:01 CET] <ubitux> please don't push anything for the next minutes, i'm rebasing a merge [15:59:55 CET] <cone-785> ffmpeg 03Diego Biurrun 07master:de452e503734: pixblockdsp: Change type of stride parameters to ptrdiff_t [15:59:56 CET] <cone-785> ffmpeg 03Clément BSsch 07master:e07fa3008bca: Merge commit 'de452e503734ebb0fdbce86e9d16693b3530fad3' [16:00:03 CET] <ubitux> i hope i didn't break anything in that one [16:05:30 CET] <ubitux> jkqxz: any reason 09a145b3c837273b1379321e44386a3233156e75 wasn't cherry-picked? it applies cleanly, i just deleted the #undef we had [16:41:23 CET] <feliwir> atomnuker, another thing i don't understand: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/huffman.c#L165 This is the only line where i see the symbols getting set. I thought the according symbols would depend on the bitstream, but there it is just set to i [16:41:25 CET] <jkqxz> ubitux: Don't think so. Probably missed because it just fixes a warning, hence meh? [16:41:47 CET] <ubitux> ok :) [16:42:00 CET] <cone-785> ffmpeg 03Mark Thompson 07master:09a145b3c837: hwcontext_vdpau: Remove duplicate definition of GET_CALLBACK [16:42:01 CET] <cone-785> ffmpeg 03Mark Thompson 07master:7081620aca36: hwcontext_vdpau: Fix missing subscripts [16:42:02 CET] <cone-785> ffmpeg 03Clément BSsch 07master:2feef75cb5e6: Merge commit '09a145b3c837273b1379321e44386a3233156e75' [16:42:03 CET] <cone-785> ffmpeg 03Clément BSsch 07master:6c3d2dad9e29: Merge commit '7081620aca36e616ea96f71fd71d2703e3abae09' [16:43:08 CET] <cone-785> ffmpeg 03Mark Thompson 07master:3a9662af6c74: vaapi_h264: Fix HRD bit_rate/cpb_size scaling [16:43:09 CET] <cone-785> ffmpeg 03Clément BSsch 07master:9a0f91314adc: Merge commit '3a9662af6c741f8354b1ca97642f78f5c02e2e8f' [16:44:16 CET] <ubitux> jkqxz: how about bdf7610eb266fd3de650040c97328791868abd82? [16:45:00 CET] <ubitux> (it applies cleanly) [16:45:23 CET] <jkqxz> That's not in ffmpeg already? Oops. Yeah, apply that. [16:45:45 CET] <ubitux> ok :) [16:46:11 CET] <cone-785> ffmpeg 03Mark Thompson 07master:bdf7610eb266: vf_scale_vaapi: Crop input surface to active region [16:46:12 CET] <cone-785> ffmpeg 03Clément BSsch 07master:bc1023eb36c6: Merge commit 'bdf7610eb266fd3de650040c97328791868abd82' [16:47:52 CET] <cone-785> ffmpeg 03Martin Storsjö 07master:df3795025337: rtsp: Fix a crash with the RTSP muxer [16:47:53 CET] <cone-785> ffmpeg 03Clément BSsch 07master:48cc083a301f: Merge commit 'df3795025337479a639cb3cd26c93a4e82ccd4db' [16:53:07 CET] <RiCON> wbs: any opinion on something like https://i.fsbn.eu/mipK.txt ? [16:54:11 CET] <cone-785> ffmpeg 03Josh de Kock 07master:bc7399934def: libdc1394: Distinguish between enumeration errors and no cameras found [16:54:12 CET] <cone-785> ffmpeg 03Clément BSsch 07master:f91bf71d69d9: Merge commit 'bc7399934def210c2a84ea51375d50f79c676c96' [17:19:17 CET] <durandal_1707> how much those recent asm optimizations helps overall performance? [17:22:31 CET] <kierank> durandal_1707: for h264? [17:23:17 CET] <durandal_1707> and others [17:24:34 CET] <kierank> i dunno what asm you talk about then [17:25:59 CET] <durandal_1707> those that were gsoc task [17:27:17 CET] <nevcairiel> Probably minimal improvements from single functions being optimized [17:27:29 CET] <nevcairiel> But a lot of small things... [17:32:56 CET] <jamrial> h264 and vp8 barely make a modern cpu sweat, so no real noticeable difference [17:37:27 CET] <durandal_1707> and vp9 and hevc? [17:37:52 CET] <jamrial> avx2 on those may help with 4k [17:38:06 CET] <jamrial> in any case, last time i checked perf for vp9 showed that half the time spent decoding was in decode_coeff() [17:39:10 CET] <tdjones> The preprocessed input from the aac psychoacoustic model is saved in the context's 'planar_samples' member, and the values are copied and used in the psy.model->window() for the current frame and look ahead samples. Where would be a good place to find these values within the vorbis context? The vorbis encoder does not copy samples frame to frame in the same way that aac enc does. [17:40:26 CET] <tdjones> That is for the qualification task with the vorbis encoder, detecting transients using the aac psychoacoustic model [17:40:50 CET] <durandal_1707> atomnuker: ^ [17:48:48 CET] <thebombzen> Does anyone know why nutenc defaults to mpeg4 for video codecs? [17:49:05 CET] <thebombzen> I can't see how anyone muxing a nut file would want that [17:49:20 CET] <cone-785> ffmpeg 03Matthieu Bouron 07master:d839c4716cdc: configure: error out if jni is enabled and cannot be found [17:52:35 CET] <atomnuker> tdjones: there isn't one, just introduce one in the context which points to the AVFrame's extended_data planes and feed that in [17:52:46 CET] <atomnuker> (into s->psy.model->window that is) [17:53:09 CET] <atomnuker> if you want to you can just make it like the AAC encoder and make it an array instead of a pointer [17:53:38 CET] <atomnuker> AAC did it this way since there was some time domain stuff going on [17:54:37 CET] <tdjones> atomnuker: thanks, I'll try that [18:29:33 CET] <cone-785> ffmpeg 03Diego Biurrun 07master:8c201dde0ab6: build: doc: more fine-grained dependencies for generated texi files [18:29:34 CET] <cone-785> ffmpeg 03Clément BSsch 07master:465a7a1b9f03: Merge commit '8c201dde0ab62e5cd581d958e78d7609e0ba710d' [18:30:31 CET] <cone-785> ffmpeg 03Janne Grunau 07master:15fcf6292ed7: build: remove hardcoded name of version header [18:30:32 CET] <cone-785> ffmpeg 03Clément BSsch 07master:6d43533286fa: Merge commit '15fcf6292ed79be274c824fedb099c2665f4cc15' [18:34:24 CET] <cone-785> ffmpeg 03Michael Niedermayer 07master:136f55207521: mpegvideo_motion: Handle edge emulation even without unrestricted_mv [18:34:25 CET] <cone-785> ffmpeg 03Clément BSsch 07master:71d3d96c9f69: Merge commit '136f55207521f0b03194ef5b55ba70f1635d6aee' [18:34:44 CET] <gh0st__> durandal_1707: I made the ipred_dl_16x16_16 avx2 implmentation. IIRC Amdahl's law can be applied here, e.g if the C version took 1% of the cpu time and the avx2 is 10 times faster then theoretically the overall performance of vp9 increases by 0.9%. [18:36:45 CET] <durandal_1707> my cpu doesnt have avx2 :( [18:36:49 CET] <gh0st__> durandal_1707: But real world tests are needed to get the practical performance impact. [18:37:14 CET] <cone-785> ffmpeg 03Yogender Gupta 07master:de64dd13cbd4: avcodec: Add the extended pixel format profile for HEVC [18:37:15 CET] <cone-785> ffmpeg 03Clément BSsch 07master:37cf0d0bbfa0: Merge commit 'de64dd13cbd47fd54334b6aa2a2cd3c7c36daae2' [18:37:51 CET] <gh0st__> durandal_1707: I can give you access to a broadwell machine. [18:38:37 CET] <gh0st__> If you want to run some tests. [18:38:41 CET] <cone-785> ffmpeg 03Alexandra Hájková 07master:07e1f99a1bb4: x86util: Document SBUTTERFLY macro [18:38:42 CET] <cone-785> ffmpeg 03Clément BSsch 07master:3898e346b335: Merge commit '07e1f99a1bb41d1a615676140eefc85cf69fa793' [18:39:39 CET] <durandal_1707> gh0st__: not needed [18:43:17 CET] <cone-785> ffmpeg 03Anton Khirnov 07master:1d6c76e11feb: audiodsp/x86: fix ff_vector_clip_int32_sse2 [18:43:18 CET] <cone-785> ffmpeg 03Clément BSsch 07master:072fad7cf536: Merge commit '1d6c76e11febb58738c9647c47079d02b5e10094' [18:46:08 CET] <nevcairiel> if functions achieve the expected optimizations, then its fine either way (ie. 2x the speed as 128-bit SSE2/3/.. would be ideal for AVX2, so getting somewhere close to that is fine), of course optimizing single functions will not make the entire encoder speed up substantially at that point, but it all counts [18:46:24 CET] <cone-785> ffmpeg 03Anton Khirnov 07master:75d98e30afab: audiodsp/x86: clear the high bits of the order parameter on 64bit [18:46:25 CET] <cone-785> ffmpeg 03Clément BSsch 07master:43a4c729d4f2: Merge commit '75d98e30afab61542faab3c0f11880834653bd6b' [18:47:23 CET] <nevcairiel> (of course not all functions can linearly scale with register size increase) [18:48:03 CET] <ubitux> philipl: what should we do about 340f12f71207513672b5165d810cb6c8622c6b21? [18:48:25 CET] <atomnuker> it doesn't help how avx2 is implemented as well [18:48:39 CET] <ubitux> it looks like we should noop it since they use AV_PIX_FMT_YUV444P16 because they lack P016 [18:48:43 CET] <nevcairiel> the vp8 function from above is even faster then 2x though, while the vp8 function didnt achieve 2x [18:48:53 CET] <nevcairiel> second vp8 should be vp9 [18:48:54 CET] <nevcairiel> :D [18:49:08 CET] <ubitux> philipl: but maybe we do need AV_PIX_FMT_YUV444P16 as well? [18:52:16 CET] <BtbN> Adding AV_PIX_FMT_YUV444P16 won't hurt, but doesn't gain anything. [18:53:08 CET] <BtbN> it's not a straight forward merge though, as the logic in ffmpeg is slightly different, because of alignment [18:53:34 CET] <ubitux> yes, and i can't test it [18:53:47 CET] <ubitux> it's blocking my merge so anyone can take over for now [18:53:48 CET] <BtbN> I'd say just noop it. If we'll ever need it, it will be added in turn. [18:53:59 CET] <ubitux> ok [18:55:25 CET] <cone-785> ffmpeg 03Yogender Kumar Gupta 07master:340f12f71207: hwcontext_cuda: Add P010 and YUV444P16 pixel format [18:55:26 CET] <cone-785> ffmpeg 03Clément BSsch 07master:87007ebc1688: Merge commit '340f12f71207513672b5165d810cb6c8622c6b21' [19:01:51 CET] <cone-785> ffmpeg 03Anton Khirnov 07master:eea9857bfd69: blockdsp: drop the high_bit_depth parameter [19:01:52 CET] <cone-785> ffmpeg 03Clément BSsch 07master:9010676ea324: Merge commit 'eea9857bfd6925d0c34382c00b971ee6df12ad44' [19:01:53 CET] <cone-785> ffmpeg 03Clément BSsch 07master:b78243c50401: lavc/arm: fix indent in blockdsp_init_neon [19:07:53 CET] <cone-785> ffmpeg 03Anton Khirnov 07master:2eb97af66af9: checkasm: add a test for blockdsp [19:07:54 CET] <cone-785> ffmpeg 03Clément BSsch 07master:c50b2164a6cd: Merge commit '2eb97af66af90ca3978229da151f0b8b3a5d9370' [19:11:28 CET] <cone-785> ffmpeg 03Anton Khirnov 07master:e9ef6171396d: checkasm: add tests for audiodsp [19:11:29 CET] <cone-785> ffmpeg 03Clément BSsch 07master:84147554865b: Merge commit 'e9ef6171396dc4106526aaa86b620c61ca3d1017' [19:11:44 CET] <BtbN> Wasn't there some new avx2 asm recently? I'd like to bench it. [19:12:08 CET] <cone-785> ffmpeg 03Anton Khirnov 07master:bf58545aace7: audiodsp: fix vector_clipf documentation [19:12:09 CET] <cone-785> ffmpeg 03Clément BSsch 07master:90f6433dcf37: Merge commit 'bf58545aace7d14522ce4fa680c7b3ff62109a3a' [19:16:48 CET] <BtbN> ubitux, I just got an E-Mail from Github, because there is @BtbN in the commit message. :D [19:17:03 CET] <ubitux> :D [19:17:11 CET] <ubitux> sorry ;) [19:17:18 CET] <JEEB> :D [19:22:59 CET] <ubitux> jamrial: opinion on 12004a9a7f20e44f4da2ee6c372d5e1794c8d6c5? [19:23:11 CET] <ubitux> it was apparently yasmified differently [19:23:42 CET] <ubitux> (it depends on the previous commit arg shuffle) [19:24:25 CET] <ubitux> i don't see the magic movsxdifnidn in your port btw [19:24:55 CET] <ubitux> it's a port from 1d36defe94c7d7ebf995d4dbb4f878d06272f9c6 [19:25:07 CET] <jamrial> seems better thanks to said arg shuffle [19:25:18 CET] <jamrial> the loop is the same, but init is simpler [19:25:43 CET] <jamrial> probably worth merging [19:25:52 CET] <ubitux> OK [19:25:56 CET] <ubitux> thanks [19:26:05 CET] <jamrial> curious they didn't make len ptrdiff_t after the previous bunch of commits, heh [19:26:34 CET] <ubitux> yeah indeed [19:27:04 CET] <ubitux> maybe it was a pain due to the other arch [19:27:09 CET] <ubitux> +s [19:46:52 CET] <cone-785> ffmpeg 03Clément BSsch 07master:bbc3bde14f14: configure: fix crystalhd detection [19:49:34 CET] <JEEB> crystalhd... now even the people who used to maintain it have their HW dying [19:53:05 CET] <wbs> RiCON: probably ok I guess, I don't know the swfverify stuff very well [19:54:07 CET] <kierank> will avfilter_graph_free free any internally buffered frames? [20:04:38 CET] <durandal_1707> michaelni: can you explain dnxhr changes to parser? [20:28:53 CET] <kierank> durandal_1707: i have memory leaks in drawtext, who do I ask if my fix is correct? [20:31:34 CET] <michaelni> durandal_1707, i assume you mean ed0dc14ebba1d2e65fe39b7e8c10359adbfba36f ? if so the author probably would be best in explaining the code [20:32:05 CET] <durandal_1707> kierank: your code? [20:32:16 CET] <kierank> in the filter itself [20:32:26 CET] <durandal_1707> hmm [20:33:09 CET] <kierank> i also have general big memory leaks in libavfilter which need fixing but I will fix simple stuff first [20:33:10 CET] <durandal_1707> kierank: valgrind report? [20:33:41 CET] <kierank> i have a patch coming [20:33:46 CET] <kierank> but I dunno who to ask if correct [20:34:21 CET] <kierank> i have lots of valgrind reports with lots of avfilter leaks :( [20:34:23 CET] <kierank> but I use old ffmpeg [20:34:25 CET] <kierank> from 2015 [20:34:28 CET] <durandal_1707> ask Carl or Nicolas [20:35:05 CET] <nevcairiel> lavfi was changed quite a lot s ince 2015 [20:35:15 CET] <kierank> the bug is still present [20:35:25 CET] <kierank> but it's a minor bug compared to the megabytes of frames leaks i have [20:35:38 CET] <durandal_1707> have way to reproduce? [20:35:55 CET] <kierank> not easily, will spend tonight trying to fix [20:36:37 CET] <durandal_1707> if it leaks mbs than you are not freeing refcounted frames [20:37:05 CET] <kierank> I am freeing every frame as soon as it leaves lavfi actually [20:37:12 CET] <kierank> in my debug code [20:38:46 CET] <durandal_1707> hard to guess without looking at code [20:39:39 CET] <kierank> I will start sending patches now, don't worry [20:39:48 CET] <kierank> but i regret using lavfi for anything serious now [20:49:32 CET] <michaelni> durandal_1707, i assume you plan to work on the dnxhd parser consulting job ? [20:52:04 CET] <durandal_1707> michaelni: no if you want to do it [20:53:37 CET] <michaelni> iam happy to leave it to you, i dont remember the code it just feels like not a impossible bug to fix [20:55:18 CET] <michaelni> also i have lots of other things to do [21:01:48 CET] <ubitux> kierank: a better $subj would be "lavfi/drawtext: fix a_pexpr memory leak" though (or s/lavfi/avfilter/ depending on your preference) [21:02:14 CET] <durandal_1707> michaelni: looks like best way is to pick compressed frame size from cid table [21:06:28 CET] <durandal_1707> but that doesnt fix issues with variable stuff [21:11:04 CET] <michaelni> Is that code actually skiping over the compressed frame size ? if not that should improve detection of the next header [21:15:33 CET] <atana> michaelni, repo updated. [21:18:01 CET] <michaelni> atana, memmove(p->data, p->data, SIZECHECK/2); moves data from p->data to p->data thats exactly where it was, you meant memmove(p->data, p->data + p->windowSize/2 ... [21:27:24 CET] <durandal_1707> michaelni: yes, current dnxhd parser code is very fragile [21:27:50 CET] <michaelni> atana, also the size in memmove should consider the element/sample size [21:33:37 CET] <hemalpatil> Hey everyone! New user here [21:33:47 CET] <hemalpatil> Any GSoC 2017 applicants? [21:36:28 CET] <Rathann> hemalpatil: welcome [21:38:10 CET] <hemalpatil> Hi [21:38:36 CET] <hemalpatil> has anyone taken up the Ambisonic decoder project? [21:38:37 CET] <feliwir> can someone explain me why the symbols for the huffman tree are just set to i here: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/huffman.c#L165 ? [21:38:40 CET] <feliwir> it makes no sense to me [21:41:33 CET] <atana> michaelni, code pushed [21:41:50 CET] <durandal_1707> hemalpatil: yes its taken [21:42:22 CET] <hemalpatil> any open mentored projects that I can take up for GSoC? [21:42:52 CET] <atomnuker1> feliwir: pengvado wrote that code but I doubt he'll respond [21:47:10 CET] <michaelni> atana, does it produce a better score now ? [21:47:53 CET] <atana> michaelni, no, now there are 114 failures [21:49:14 CET] <feliwir> atomnuker1, is he not active anymore? [21:57:07 CET] <michaelni> atana, sizeof(p->data) in the memmove should be sizeof(*p->data), its the size of a sample not the pointer [21:58:47 CET] <ubitux> dammit that DASH patch is huuuuge [22:01:26 CET] <hemalpatil> @durandal_1707: can the "Ambisonic decoder" project still be taken up? [22:01:43 CET] <durandal_1707> hemalpatil: nope [22:01:51 CET] <atana> michaelni, corrected and code pushed. still 114 failures [22:10:14 CET] <michaelni> atana, thats odd i have fewer failures here [22:12:43 CET] <atana> michaelni, what's the failure count at your side? [22:12:50 CET] <michaelni> 4 [22:13:28 CET] <atana> let me check [22:18:17 CET] <atana> I think I found it. For debugging I made some changes in test scripting and was printing file names that might got included in the count. checking now.. [22:20:16 CET] <atana> michaelni, yes it's 4 [22:23:06 CET] <michaelni> atana, very good ! [22:23:44 CET] <michaelni> atana, you can try if any other window works better [22:25:14 CET] <atana> Was thinking about it. I will try with diff window sizes also I should replace SIZECHECK with p->windowSize in the filter_frame code [22:25:36 CET] <michaelni> yes [22:27:34 CET] <hemalpatil> @BBB: mentor for "VMAF video filter". I want to take up this project [22:35:34 CET] <cone-785> ffmpeg 03Anton Khirnov 07master:683da86aabb4: audiodsp: reorder arguments for vector_clipf [22:35:35 CET] <cone-785> ffmpeg 03Anton Khirnov 07master:12004a9a7f20: audiodsp/x86: yasmify vector_clipf_sse [22:35:36 CET] <cone-785> ffmpeg 03Clément BSsch 07master:83cd80d10aeb: Merge commit '12004a9a7f20e44f4da2ee6c372d5e1794c8d6c5' [22:38:39 CET] <cone-785> ffmpeg 03Luca Barbato 07master:352741b5ead1: nvenc: Make sure that enum and array index match [22:38:40 CET] <cone-785> ffmpeg 03Clément BSsch 07master:e3ee67c85e69: Merge commit '352741b5ead1543d775ccf6040f33023e4491186' [22:39:51 CET] <ubitux> BtbN: any reason e02e2515b24bfc37ede6ca1744696230be55e50b wasn't merged completely? [22:40:27 CET] <ubitux> ah that's actually present in the other nvenc files, my bad [22:40:42 CET] <BBB> hemalpatil: ok& we need to find you a suitable qualification task [22:40:53 CET] <BBB> where is thilo [22:44:12 CET] <cone-785> ffmpeg 03Yogender Gupta 07master:e02e2515b24b: nvenc: Add some easier to understand presets that match x264 terminology [22:44:13 CET] <cone-785> ffmpeg 03Clément BSsch 07master:a5dea2b77305: Merge commit 'e02e2515b24bfc37ede6ca1744696230be55e50b' [22:46:55 CET] <ubitux> i see checks in 358c887a9fa0fb2e7ce089eaea71ab924a3e47a7 that are not present in our version [22:47:07 CET] <ubitux> anyone with a nvidia up to the merges please? [22:47:13 CET] <ubitux> i can't test that [22:49:24 CET] <jamrial> ubitux: you should probably just noop it. we already seem to have high bit support in nvenc [22:49:44 CET] <jamrial> also, libav supports old sdks while we only support the latest i think [22:50:01 CET] <ubitux> we don't want to support the old ones? [22:50:17 CET] <jamrial> don't think so. we're shipping the header in the compat folder after all [22:50:28 CET] <nevcairiel> indeed, no reason to bother [22:50:31 CET] <jamrial> and doing dynlink [22:52:13 CET] <ubitux> OK [22:53:08 CET] <ubitux> there are a few other differences though [22:53:33 CET] <ubitux> i'll reduce the cosmetics [22:54:20 CET] <ubitux> or maybe not.. [22:57:25 CET] <jamrial> IMO, just noop them and ask philipl_ or timo if these are useful/needed. they can be adapted for our tree later like with other commits before [22:57:43 CET] <cone-785> ffmpeg 03Yogender Gupta 07master:358c887a9fa0: nvenc: Add support for high bitdepth [22:57:44 CET] <cone-785> ffmpeg 03Yogender Gupta 07master:70de2ea4261f: nvenc: Extended rate-control support as provided by SDK 7 [22:57:45 CET] <cone-785> ffmpeg 03Clément BSsch 07master:99d081e6380e: Merge commit '358c887a9fa0fb2e7ce089eaea71ab924a3e47a7' [22:57:46 CET] <cone-785> ffmpeg 03Clément BSsch 07master:e849296d0a68: Merge commit '70de2ea4261f860457a04e3d0c58c5543f403325' [22:59:44 CET] <durandal_1707> BBB: i think its over for quallis, we just pick students now [23:00:03 CET] <BBB> what if new students come in? [23:02:21 CET] <nevcairiel> there is still a bit time until april 3, but if you have promising candidates already, might as well tell students that, can only have one per task afterall, and probably only a small subset overall [23:05:09 CET] <cone-785> ffmpeg 03Clément BSsch 07master:b7cc4eb3030b: lavc/nvenc: misc cosmetics to reduce diff with Libav [23:09:50 CET] <ubitux> tomorrow, swscale merges, yeeey ~ T_T [23:14:42 CET] <ubitux> ah it's actually stuff we have in ffmpeg since 2012 [23:15:15 CET] <ubitux> i guess i'll be able to continue my noop party [23:16:54 CET] <atana> michaelni, size->failures : 1024->4, 2048->138, 3072->143, 4096->4, 5120->147, 6144->148, 7168->148, 8192->145 [23:20:57 CET] <michaelni> atana, i have 7 failures with 2048, did you update all 1024 and 512 ? [23:21:32 CET] <michaelni> atana, also only power of 2 will work probably that is 1024, 2048, 4096, 8192, ... [23:24:41 CET] <atana> michaelni, does 'lim = 512' also needs to be update? I have updated others before testing [23:33:45 CET] <michaelni> atana, did you update SIZECHECK and the default window size in the AVOption table ? [23:34:18 CET] <michaelni> atana, also p->index = 512; [23:34:30 CET] <michaelni> lim = 512 isnt used i think currently [23:35:13 CET] <atana> michaelni, lim += 512 [23:35:21 CET] <michaelni> yes [23:35:26 CET] <atana> ok [23:52:21 CET] <stevenliu> Thanks guys [23:52:59 CET] <stevenliu> i will merge all the review comment :) [00:00:00 CET] --- Tue Mar 21 2017

1 0

ffmpeg.log.20170320
by burek 21 Mar '17

21 Mar '17

[00:46:45 CET] <Anthropohedron> My understanding of ffmpeg and various video formats is weak, but growing. I've put together a script for myself to rip (with dvdbackup) and encode (with ffmpeg) DVDs to m4v. I am trying to improve that script so I can include subtitles. [00:49:51 CET] <Anthropohedron> I'm working with a particular DVD that has subtitles in English, Spanish, and French. Using ffprobe on my rip (remember, with dvdbackup), I see three subtitle streams when I use "ffprobe -v error -show_entries stream=index,codec_name,codec_type", streams 6-8, but just ffprobe -i or ffmpeg -i only shows streams 0-5. [00:51:36 CET] <Anthropohedron> If someone can help me extract the English subtitles to its own file, I think I can figure out the rest, but the various flags I've tried with ffmpeg have failed me. It mostly seems to be an issue with specifying the correct stream. [00:52:31 CET] <Anthropohedron> This fails: ffmpeg -i concat:"$VOBFILES" -c:s:0:6 copy subtitles [00:52:45 CET] <Anthropohedron> Help? [01:09:09 CET] <klaxa> having some output would make a lot of things more concrete and keep people from guessing [01:21:46 CET] <Anthropohedron> klaxa: http://pastebin.com/CXs5kKU8 [01:22:38 CET] <Anthropohedron> klaxa: http://pastebin.com/8x3zQLJL [01:24:02 CET] <Anthropohedron> klaxa: http://pastebin.com/j0YvWniZ [01:24:11 CET] <Anthropohedron> klaxa: What else would you like to see? [01:24:38 CET] <klaxa> well the last one fails because it has no output [01:24:54 CET] <klaxa> and also only subtitles [01:25:06 CET] <klaxa> ah that's what you want [01:26:02 CET] <klaxa> hmm, i would suggest using .ass or .srt [01:26:38 CET] <Anthropohedron> Give me a commandline to try and I happily will. [01:27:24 CET] <Anthropohedron> http://pastebin.com/EQYYJpZ0 [01:28:56 CET] <klaxa> oh wait a minute [01:29:45 CET] <klaxa> with the concat protocol the subtitles seem to get lost [01:29:45 CET] <Anthropohedron> ? [01:29:53 CET] <klaxa> http://pastebin.com/j0YvWniZ [01:29:54 CET] <klaxa> that one [01:30:08 CET] <klaxa> there are no subtitle streams in concat:$VOBFILES [01:30:30 CET] <klaxa> maybe not every file has them? [01:31:17 CET] <Anthropohedron> http://pastebin.com/huU5tjYm [01:32:13 CET] <klaxa> ah, i'm a dumb, it also has to be: ffmpeg -i movie/VIDEO_TS/VTS_01_1.VOB -map 0:6 subtitles.ass [01:32:27 CET] <klaxa> you can't really copy dvd_subtitle i think [01:32:34 CET] <klaxa> someone might be wiser than me and know better [01:32:37 CET] <Anthropohedron> ffprobe shows the subtitle streams in that one .vob when I invoke it one way <http://pastebin.com/CXs5kKU8> but not the other <http://pastebin.com/8x3zQLJL> [01:32:56 CET] <Anthropohedron> I'll try that, one sec. [01:33:09 CET] <klaxa> it shows them both times? [01:34:43 CET] <Anthropohedron> If I explicitly ask for -show_entries stream then I see 8 streams. If I just do ffprobe <file> then it shows 5 streams. [01:35:17 CET] <Anthropohedron> Also, http://pastebin.com/B7SM60D8 looks a bit better. It just can't convert dvd_subtitle to ass. [01:36:01 CET] <klaxa> what about [01:36:01 CET] <klaxa> Stream #0:6[0x20]: Subtitle: dvd_subtitle [01:36:01 CET] <klaxa> Stream #0:7[0x21]: Subtitle: dvd_subtitle [01:36:01 CET] <klaxa> Stream #0:8[0x22]: Subtitle: dvd_subtitle [01:36:02 CET] <klaxa> ? [01:37:25 CET] <Anthropohedron> Right, I see that only under some circumstances and I don't understand why I don't sometimes. [01:37:48 CET] <klaxa> depending on the file maybe? [01:38:08 CET] <klaxa> also, i can't seem to find how to properly extract dvdsub subtitles [01:38:23 CET] <klaxa> https://trac.ffmpeg.org/wiki/ExtractSubtitles this is the closest documentation to what you need [01:40:08 CET] <Anthropohedron> Right, I see that only under some circumstances and I don't understand why I don't sometimes. [01:40:14 CET] <Anthropohedron> Whoops. [01:42:22 CET] <Anthropohedron> I've made some progress, but it seems to be picky about the naming of the output file and I don't know what I should be using: http://pastebin.com/15Ke5tc6 [02:55:48 CET] <lindylex> Is there a way I can get a display where this is record the screen? ffmpeg -f x11grab -r 25 -s 640x640 -i :0.0+7,53 -vcodec huffyuv screencast.avi [03:03:18 CET] <DHE> ffplay -f x11grab -r 25 -s 640x640 -i :0.0+7,53 (and move the player window out of the way when it pops up) [03:03:33 CET] <DHE> I'm assuming you have a big display, like 1080p, with lots of room to put the player aside [03:03:57 CET] <DHE> or, you know, record for a few seconds and play the video back to look. [03:09:21 CET] <lindylex> DHEDHe: Failed to set value '25' for option 'r': Option not found [03:11:02 CET] <lindylex> Thanks I used this ffplay -f x11grab -s 640x640 -i :0.0+7,53 [03:30:10 CET] <DHE> oh. oops. sorry. [03:44:25 CET] <thebombzen> lindylex: use -framerate [03:44:26 CET] <thebombzen> not -r [03:44:32 CET] <thebombzen> it depends on what your display is [03:45:06 CET] <thebombzen> lindylex: what happens if you run this? xrandr -q | grep '\*' | cut -d '*' -f 1 | xargs echo [03:45:26 CET] <lindylex> 1920x1200 59.95 [03:46:43 CET] <lindylex> thebombzen: this works perfectly ffplay -f x11grab -framerate 25 -s 640x640 -i :0.0+7,53 [03:47:02 CET] <thebombzen> well you should use -framerate 59.95 then [03:47:12 CET] <lindylex> ok let me do that. [03:47:17 CET] <thebombzen> the second # is the monitor's refresh rate [03:47:38 CET] <lindylex> Got it [03:47:40 CET] <thebombzen> the first # is your monitor's size [03:47:45 CET] <thebombzen> but you probably knew that [03:47:57 CET] <lindylex> I did. Thanks for still explaining. [03:48:19 CET] <thebombzen> also your monitor's refresh rate is set to 59.95 which is really weird [03:48:23 CET] <thebombzen> tbh it probably should be set to 60 [03:49:01 CET] <lindylex> I have no idea why this is so. Is this something on the hardware I need to adjust? [03:50:03 CET] <lindylex> On the monitor it says 1920 X 1200 74KHz 60 Hz 60HZ [03:52:56 CET] <lindylex> I have seen screen cast that follow the mouse around with a fix box recording dimension. Is this possible with ffmpeg? [03:57:32 CET] <thebombzen> try running this: [03:57:42 CET] <thebombzen> xrandr --output HDMI-0 --mode 1920x1200 --rate 60.00 [03:57:44 CET] <thebombzen> what happens? [03:58:40 CET] <thebombzen> or instead of HDMI-0 [03:58:44 CET] <thebombzen> whatever it's actually called [03:58:48 CET] <thebombzen> see xrandr -q for the list [04:10:12 CET] <lindylex> thebombzen: http://termbin.com/staw [04:28:15 CET] <thebombzen> lindylex: ah okay [04:28:24 CET] <thebombzen> it appears it doesn't support anything other than 59.95 [04:28:26 CET] <thebombzen> for some reason [04:33:39 CET] <lindylex> This is the hardware: samsung syncmaster 275t It broken once and I sent it back as RMA they sent me a used one. It has not failed since. I got it in 2008. I can not wait ofr it to finally fail so I can get a larger screen tv I can connect my computer to. [09:20:17 CET] <lindylex> I am trying to record audio with ffmpeg -f alsa -ac 2 -i hw:0,0 -y alsaout.wav and it has so much fuzziness in the background. [09:27:56 CET] <c_14> lindylex: probably your microphone, does arecord produce the same effect? [09:28:47 CET] <lindylex> I used it before in the past and it had no terrible background noise. Let me check with arecord. [09:31:43 CET] <lindylex> c_14: I did this arecord -vv -fdat o.wav and it sounds the same. FYI ffmpeg version 3.2.4-1 [09:32:26 CET] <c_14> then it's either your microphone or your alsa drivers/setup [09:32:58 CET] <lindylex> I do have pusleaudio installed. [09:33:06 CET] <c_14> try using that instead? [09:33:09 CET] <c_14> -f pulse -i default [09:34:52 CET] <lindylex> ok one sec [09:36:04 CET] <lindylex> This arecord -f pulse -i default o.wav gives me this error arecord: main:604: wrong extended format 'pulse' [09:36:15 CET] <c_14> ffmpeg -f pulse -i default [09:36:48 CET] <kerio> another patent dies ;o [09:37:17 CET] <lindylex> It sounds the same. Lots of background humming. [09:38:15 CET] <c_14> then it's probably the microphone [09:39:01 CET] <lindylex> This is what it sounds like https://expirebox.com/download/7ed6587d5f28c5cb1a09aaffd5069ac6.html [09:44:46 CET] <c_14> no idea, you might want to ask in #pulseaudio since it doesn't seem to be a problem with ffmpeg but rather with your audio setup [09:44:55 CET] <c_14> maybe the levels are messed up [09:45:54 CET] <lindylex> ok [09:46:03 CET] <lindylex> thanks [09:49:34 CET] <matkatmusic> anyone have any experience writing raw RGB uint8_t's into an AVFrame? [09:51:15 CET] <matkatmusic> I'm helping another coder figure out why this call to sws_scale() isn't writing data correctly (the output video is all black) [09:51:16 CET] <matkatmusic> https://github.com/filmstro/filmstro_ffmpeg/blob/master/modules/filmstro_ff… [09:53:04 CET] <Mavrik> why are you setting data 4 times? O.o [09:53:34 CET] <matkatmusic> See this reply: https://github.com/filmstro/filmstro_ffmpeg/issues/3#issuecomment-287697897 [09:53:39 CET] <matkatmusic> I asked the same thing [09:54:35 CET] <Mavrik> That's fugly. [09:55:02 CET] <matkatmusic> I didn't write that github lib. i'm just helping him get it working. [09:55:07 CET] <Mavrik> but probably not critically wrong [09:55:15 CET] <matkatmusic> the ffmpeg library is really hard to use [09:55:17 CET] <Mavrik> hard to say what's actually going on in that piece of code [09:55:27 CET] <Mavrik> because the code architecture is horrible [09:55:28 CET] <matkatmusic> if you're trying to use it via the API, i mean. [09:55:33 CET] <Mavrik> it accepts pixel format as a parameter? [09:55:48 CET] <Mavrik> and then it just ignores that and magically infers it needs 4 bytes per pixel in a single plane? [09:55:49 CET] <Mavrik> wat. [09:55:57 CET] <matkatmusic> what are you referring to? [09:56:31 CET] <matkatmusic> I'm assuming you're referring to this: https://github.com/FFmpeg/FFmpeg/blob/03ce71e4a1187340720e1569ac96c285c145a… [09:57:02 CET] <matkatmusic> er, more specifically https://github.com/FFmpeg/FFmpeg/blob/03ce71e4a1187340720e1569ac96c285c145a… [09:57:08 CET] <matkatmusic> that's the start of the function [09:57:13 CET] <matkatmusic> sws_scale() [09:57:29 CET] <Mavrik> I'm refering to this: https://github.com/filmstro/filmstro_ffmpeg/blob/master/modules/filmstro_ff… [09:57:39 CET] <Mavrik> vs this: https://github.com/filmstro/filmstro_ffmpeg/blob/master/modules/filmstro_ff… [09:57:49 CET] <Mavrik> the "scaler" gets input format as a parameter [09:58:08 CET] <Mavrik> but then it hardcodes the size of the plane [09:58:19 CET] <Mavrik> I suggest you take a look for those kind of code smells: [09:58:25 CET] <Mavrik> 1.) Is the format set properly for your encoder? [09:58:26 CET] <matkatmusic> I wish mcjack were here to cmoment, cuz that's his code. [09:58:34 CET] <matkatmusic> comment [09:58:39 CET] <Mavrik> 2.) Is the AVFrame actually allocated (your pointers should be valid) [09:58:56 CET] <Mavrik> 3.) Do you set a proper RGB vs. output format? [09:59:08 CET] <Mavrik> 4.) Do you get an error/warning in the log when running he scaler [09:59:15 CET] <Mavrik> All of that can easily be checked with a debugger through that code [10:00:17 CET] <matkatmusic> that brings me to the question, is there a way to use ffmpeg as raw code inside a c++ project instead of having to compile, and link against the compiled binary for a project? [10:03:25 CET] <Mavrik> Not sure I get the question. [10:03:32 CET] <Mavrik> You have to compile and link to it in any case. [10:03:41 CET] <Mavrik> The difference is just when you do it. [10:04:03 CET] <Mavrik> Due to complexity of the build system, use static libav [10:04:17 CET] <Mavrik> .. use static libav libraries that will get linked into your binary [10:09:43 CET] <matkatmusic> yeah, I am trying to understand how he's using it in this "dependencies" section:https://github.com/filmstro/filmstro_ffmpeg [10:10:06 CET] <matkatmusic> "you will have to build ffmpeg and link your project to it. We use this flags:" [10:10:22 CET] <matkatmusic> Why can't you just import the source code into a project? [10:12:16 CET] <Mavrik> Because you'd have to completely recreate the compilation flags for source, handle ASM compilation and for a lot of ffmpeg code that would be illegal. [10:12:38 CET] <matkatmusic> yuk [10:12:39 CET] <matkatmusic> lol [10:13:58 CET] <matkatmusic> ugh, why is ffmpeg so ugly lol [10:22:46 CET] <matkatmusic> like, why is it written in such a way that it's so difficult to use the API and you have to link against the compiled binary? [10:23:04 CET] <matkatmusic> because there are so many video formats and it handles all of them? [10:34:44 CET] <thebombzen> kerio: which patent? [10:34:51 CET] <kerio> ac-3 [10:35:16 CET] <thebombzen> huh [10:35:20 CET] <thebombzen> but ac-3 sucks so who cares? [10:38:07 CET] <kerio> dvd? bluray? [10:39:32 CET] <thebombzen> ah so apparently this explains it quite well https://ac3freedomday.org/ [10:39:40 CET] <thebombzen> it sucks so nobody cares about ac3 encoding [10:39:47 CET] <thebombzen> but now it's possible to decode ac3 without licensing fees [10:40:15 CET] <thebombzen> but afaik libavcodec has an ac-3 decoder that's LGPL, how does that mesh with the patent on ac-3? [10:40:49 CET] <furq> the same way all the other patented codecs in libavcodec do [10:41:01 CET] <furq> at least until yesterday [10:42:13 CET] <Spring> is there a way of finding the total duration of a video taking into account the trim values specified prior to encoding? [10:47:58 CET] <thebombzen> ah [10:47:59 CET] <thebombzen> speaking of which [10:48:06 CET] <thebombzen> how does ffmpeg have an HEVC or H.264 decoder [10:48:11 CET] <thebombzen> given that they're patented [10:48:14 CET] <thebombzen> legally how does that work [10:48:30 CET] <kerio> "¯\_(Ä)_/¯" [10:48:55 CET] <kerio> if you want to use libavcodec's h264 decoder, pay the fee [10:49:12 CET] <thebombzen> uh [10:49:13 CET] <thebombzen> what? [10:49:19 CET] <thebombzen> do you mean comercially [10:49:20 CET] <thebombzen> or like [10:49:28 CET] <thebombzen> technically are we all supposed to be paying the fee [10:49:36 CET] <furq> the latter [10:49:38 CET] <kerio> i have honestly no idea [10:49:41 CET] <kerio> and i don't care [10:49:50 CET] <thebombzen> but what about things like static mpv builds [10:49:54 CET] <furq> unless it's on a tv or something in which case the tv manufacturer paid the fee [10:50:03 CET] <kerio> but if you're selling stuff, you should probably get a lawyer to figure that out [10:50:14 CET] <thebombzen> cause publishing a static mpv build or static ffmpeg build like lacsh0r or zeranoe [10:50:17 CET] <kerio> thebombzen: again, that is completely irrelevant [10:50:21 CET] <thebombzen> that sounds more dubious compared to like [10:50:24 CET] <thebombzen> just building a local copy [10:50:35 CET] <kerio> zeranoe is not, as far as we know, using his static build to decode and play h264 content [10:50:45 CET] <thebombzen> lol [10:50:47 CET] <thebombzen> that loophole [10:50:50 CET] <thebombzen> also, if that's true, why is LAME still "nonfree" [10:50:52 CET] <kerio> ? [10:50:55 CET] <thebombzen> cas in [10:51:00 CET] <kerio> no i mean [10:51:01 CET] <furq> lame has never been nonfree [10:51:02 CET] <furq> it's gpl [10:51:03 CET] <thebombzen> Fraunhofer's mp3 patents are expired [10:51:10 CET] <furq> but nonfree has nothing to do with patents [10:51:11 CET] <thebombzen> furq: it requires --enable-nonfree [10:51:13 CET] <furq> it's gpl compatibility [10:51:17 CET] <furq> and no it doesn't [10:51:23 CET] <kerio> it's your fault if you're using it to play h264 without paying the fee [10:51:28 CET] <ritsuka> patents and source code license are two separated things [10:51:48 CET] <furq> fdk is nonfree because the license is gpl incompatible [10:51:52 CET] <furq> it has nothing to do with aac patents [10:52:10 CET] <thebombzen> ah okay [10:52:13 CET] <thebombzen> so I'm a criminal [10:52:13 CET] <kerio> and the question still stands, anyway [10:52:17 CET] <kerio> why are you using mp3 instead of opus? :^) [10:52:28 CET] <thebombzen> I'm not [10:52:33 CET] <furq> you're only a criminal if you're in the us [10:52:36 CET] <thebombzen> it was more just an "on principle" question [10:52:39 CET] <thebombzen> and I'm in the US [10:52:40 CET] <thebombzen> so yes [10:52:42 CET] <furq> if you're in the eu then there's no such thing as software patents [10:52:44 CET] <ritsuka> if you live if a state where software patents are a thing, nothing prevent the patent holders from suing you if you distribute a compiled binary probably [10:52:46 CET] <thebombzen> so given that I use lavc's h264 decoder I'm a criminal [10:52:47 CET] <kerio> excuse me sir, do you have a moment to talk about opus christ? [10:52:49 CET] <thebombzen> cause I don't pay the fee [10:53:12 CET] <thebombzen> and the only time I don't use opus is when I'm muxing mp4 [10:53:16 CET] <thebombzen> in which case I use voribs [10:53:22 CET] <furq> eww [10:53:42 CET] <thebombzen> well vorbis is better than aac [10:53:48 CET] <thebombzen> so not any reason not to use it [10:54:00 CET] <furq> why would you even use mp4 if you're going to mux nonstandard codecs into it [10:54:09 CET] <thebombzen> it's definitely supported [10:54:16 CET] <furq> not by 99% of things that support mp4 [10:54:18 CET] <kerio> >better than aac [10:54:20 CET] <kerio> what [10:54:22 CET] <thebombzen> it is [10:54:31 CET] <furq> kerio: it's probably better than fdk [10:54:36 CET] <thebombzen> libvorbis is a better encoder than fdk [10:54:36 CET] <furq> it's roughly on a par with apple aac [10:54:40 CET] <thebombzen> it's probalby on par with quicktime [10:54:42 CET] <thebombzen> fuck ninjad [10:54:48 CET] <furq> hi [10:54:48 CET] <kerio> apple \o/ [10:54:57 CET] <thebombzen> also mp4 technically does support opus according to the list of fourcc's [10:55:04 CET] <thebombzen> but libavformat refuses to mux it [10:55:18 CET] <thebombzen> weirdly enough, libavformat *also* won't mux opus inside nut [10:55:22 CET] <thebombzen> which is weird [10:55:22 CET] <furq> but yeah i don't see why you'd use mp4 other than for compatibility [10:55:30 CET] <furq> in which case vorbis is super dumb [10:55:46 CET] <thebombzen> short answer is that I've had issues with the matroska muxer sometimes [10:56:10 CET] <thebombzen> given that even windows media player supports 10bit HEVC + Opus + Matroska [10:56:17 CET] <thebombzen> not really any reason [10:56:27 CET] <furq> but yeah the official ffmpeg answer for "does ffmpeg infringe patents" is "we don't know" [10:56:36 CET] <furq> probably followed by "we don't care because we all live in germany" [10:56:37 CET] <thebombzen> lol [10:56:40 CET] <thebombzen> haha [10:56:47 CET] <__jack__> haha [10:57:01 CET] <thebombzen> software patents are really dumb tbh [10:57:03 CET] <__jack__> is there really human being in germany ? for real ? :O [10:57:12 CET] <thebombzen> it's one of the less nice things about the united states [10:57:16 CET] <furq> the license holders aren't going to come after you unless you're making money anyway [10:57:20 CET] <thebombzen> is our shitty business protectiosn [10:57:28 CET] <furq> they gain nothing from making an example from jimmy animes [10:57:34 CET] <thebombzen> furq: lol you say that but about 10 years ago they did that anyway [10:57:55 CET] <thebombzen> you remember when the RIAA tried to make examples of people right [10:57:55 CET] <kerio> furq: preventing the spread of anime is a virtuous act in and of itself tho [10:57:59 CET] <thebombzen> by suing them for lots of money [10:58:04 CET] <furq> that's the RIAA [10:58:08 CET] <furq> that's not software patent holders [10:58:19 CET] <furq> also, remind me how that worked out for the RIAA [10:58:29 CET] <thebombzen> it didn't [10:58:45 CET] <thebombzen> I just think it's funny to say "they don't go after small people" [10:58:48 CET] <thebombzen> because they totally used to [10:58:54 CET] <kerio> they didn't get 12 trillion dollars from that single mom? :o [10:58:55 CET] <thebombzen> the Intellectual Property Shitheads in the US [10:58:56 CET] <furq> i mean it's a different group of people really [10:59:04 CET] <thebombzen> it's really the same idea though [10:59:08 CET] <thebombzen> Intellectual Property Shitheads [10:59:22 CET] <furq> there's a case to be made there that they can scare people into paying [10:59:26 CET] <furq> and also everyone knows that piracy is illegal [10:59:38 CET] <thebombzen> essentially organizations formed on extorting money out of intellectual property they didn't create and only can because they already have money [10:59:38 CET] <furq> whereas 99% of people who are infringing decoder patents haven't got a fucking clue that they're doing anything of the sort [11:00:03 CET] <furq> and also the vast majority of people only consume media on devices where the licenses are paid for [11:00:12 CET] <thebombzen> but it's also the similar product where infringing on IP laws gets you a better product than not doing that [11:00:18 CET] <kerio> or devices for which there's no reasonable way to get a fee from [11:00:25 CET] <kerio> like those chinese knockoff phones [11:00:37 CET] <kerio> how do you even sue nokla [11:00:42 CET] <kerio> does nokla even exist [11:00:54 CET] <thebombzen> Nokia is indestructible, of course it still exists [11:01:03 CET] <furq> i prefer sumsang [11:01:12 CET] <thebombzen> but like just how pirates can get better quality TV than paying customers [11:01:13 CET] <Spring> nokla, the knock-off nokia [11:01:27 CET] <thebombzen> people who use illegal decoders get better decoders than those who pay money [11:01:30 CET] <thebombzen> encoders too [11:01:39 CET] <kerio> of course they get better decoders [11:01:39 CET] <thebombzen> x264 is better than "Adobe Media Encoder" or whatever it's called [11:01:45 CET] <thebombzen> it's the same idea [11:01:52 CET] <kerio> they're illegally-distributed ffmpeg [11:01:53 CET] <ritsuka> nokia is actually suing apple over some h.264 patents, lol [11:01:59 CET] <furq> people encoding video is a tiny drop in the ocean compared to people downloading torrents [11:02:13 CET] <kerio> ok that's not true, there's probably some weird chip doing the decoding in hardware [11:02:22 CET] <thebombzen> but I guess what I'm saying is that one of the problems with IP law is that people who violate it generally get better products than those who don't [11:02:28 CET] <furq> sure [11:02:30 CET] <thebombzen> and paying customers should not get inferior products to pirates [11:02:33 CET] <furq> nobody would disagree with that [11:02:51 CET] <furq> i doubt that even the guys implementing DRM for bluray would disagree with that [11:02:53 CET] <thebombzen> well for example if you wanted to watch anime in the US you'd need to use a site like crunchyroll, which streams 1080p and 1.5 Mbps [11:02:55 CET] <furq> it's just security theatre at this point [11:03:02 CET] <thebombzen> or you could pirate it [11:03:05 CET] <thebombzen> and get it at 8 Mbps [11:03:16 CET] <thebombzen> like [11:03:18 CET] <kerio> yeah but if you want to watch anime you're a weeaboo [11:03:23 CET] <thebombzen> guilty [11:03:23 CET] <kerio> so there's that [11:03:24 CET] <furq> why would you need 8mbps for 6fps static shots of a high school [11:03:30 CET] <kerio> LOL [11:03:36 CET] <furq> in which some kind of bakery contest is undoubtedly taking place [11:03:42 CET] <furq> and the bakers have got magic powers [11:03:49 CET] <furq> and one of them is a robot [11:03:54 CET] <thebombzen> but either way [11:04:00 CET] <furq> and they have a cute furry pal who's always there with a wisecrack [11:04:02 CET] <kerio> furq: -tune stillimage [11:04:03 CET] <kerio> :^) [11:04:04 CET] <furq> and also it all fucking sucks [11:04:06 CET] <thebombzen> my point is that pirating it gets you significantly better quality [11:04:46 CET] <Spring> trouble is bandwidth it would seem [11:04:55 CET] <Spring> torrenters can share the load [11:05:04 CET] <kerio> Spring: PLEASE [11:05:10 CET] <furq> yeah you can't blame stream quality purely on "heh heh...we'll screw the paying customers" [11:05:19 CET] <furq> streaming vs downloading is inherently different [11:05:49 CET] <furq> plus you already have the perfect example of pure evil in the form of bluray [11:06:08 CET] <kerio> why doesn't bluray use flac [11:06:18 CET] <furq> dolby got to get paid, son [11:06:27 CET] <Spring> is bandwidth not the reason crunchyroll lowered the quality recently? [11:06:37 CET] <kerio> why doesn't bluray use Super Patented Lossless Audio Codec By Dolby Digital" then [11:06:37 CET] <Spring> otherwise what else would they be doing it for [11:06:41 CET] <furq> i mean i hope it was because of pure contempt for their audience [11:06:44 CET] <furq> that's why i'd have done it [11:06:57 CET] <furq> but sadly there is probably a solid technical argument for it [11:07:07 CET] <kerio> "now introducing 6-bit h264" [11:07:19 CET] <__jack__> 11:05:19 < furq> streaming vs downloading is inherently different | indeed, they are both made by people with very differents goals [11:07:30 CET] <furq> kerio: it does [11:07:40 CET] <furq> it supports DTS-MA [11:07:41 CET] <kerio> oh, bluray audio is lossless? :o [11:07:48 CET] <furq> well not usually, but it can be [11:08:17 CET] <furq> there has to be an AC3 or DTS soundtrack for full compatibility, but a lot of disks have truehd or dtsma soundtracks as well [11:08:26 CET] <furq> discs [11:08:47 CET] <furq> you can also use lpcm if you're a crazy person [11:09:11 CET] <furq> 8-channel 96/24 lpcm [11:09:12 CET] <furq> yum [11:10:26 CET] <kerio> i wish i had 96khz radiohead :< [11:13:11 CET] <thebombzen> kerio: bluray does use flac [11:13:46 CET] <furq> what [11:14:36 CET] <tdr> it can [11:14:39 CET] <thebombzen> ah nvm just several players [11:14:42 CET] <thebombzen> it's "nonstandard" [11:14:47 CET] <thebombzen> also [11:14:52 CET] <thebombzen> why would you want 96 kHz audio [11:15:06 CET] <thebombzen> 96 kHz is completley unnecessary if you're listening to it [11:15:06 CET] <furq> so you can tell people about your 96khz audio on the internet [11:15:20 CET] <thebombzen> but what do you do when someone points out the Nyquist-Shannon Sampling Theorem [11:15:29 CET] <furq> you show them a screenshot of a sine wave in cool edit pro [11:15:33 CET] <tdr> it can be raw pcm or it can be dolby compressed soup, those are whats usually used [11:15:33 CET] <kerio> doesn't my dog have a right to proper audio [11:15:44 CET] <furq> why would you make your dog listen to radiohead [11:15:46 CET] <thebombzen> where 48 kHz is enough to construct a signal band-limited signal from 0 to 20 kHz [11:15:49 CET] <thebombzen> you know [11:15:53 CET] <kerio> thebombzen: 24 [11:16:11 CET] <thebombzen> well [0, 20) is a subinterval of [0, 24) [11:16:13 CET] <thebombzen> so we good [11:16:20 CET] <kerio> furq: why not [11:16:20 CET] <thebombzen> 96 kHz is useful if you're doing editing tho [11:16:23 CET] <thebombzen> like [11:16:26 CET] <kerio> they're the greatest band [11:16:30 CET] <thebombzen> if you're doing digital processing it can help the algorithms [11:16:33 CET] <furq> counterpoint: they're not [11:16:34 CET] <thebombzen> but just listening it's irrelevant [11:16:45 CET] <thebombzen> radiohead is not the greatest band [11:16:58 CET] <kerio> 1) you're all wrong [11:17:12 CET] <kerio> 2) my lappy's sound card supports 96khz output [11:17:20 CET] <kerio> for dem lappy speakers [11:17:58 CET] <kerio> probably by just resampling everything to 48khz [11:18:05 CET] <kerio> but i believe [11:18:06 CET] <thebombzen> also furq if you're wondering why you need 8 Mbps for anime, it's because you can't watch haasn beat up a guy in blue tights in fullmotion without 8 Mbps [11:18:08 CET] <furq> https://www.youtube.com/watch?v=LEdAkWOXcVM [11:18:10 CET] <furq> this is the greatest band [11:18:14 CET] <Nacht> Anyone here with some knowledge regarding AES and HLS (MPEG-TS) ? [11:18:17 CET] <thebombzen> in particular you can't at 2 Mbps with -preset fast [11:18:30 CET] <kerio> thebombzen: the only good anime is initial d [11:18:40 CET] <kerio> it's all downhill from there [11:18:44 CET] <thebombzen> like [11:18:45 CET] <kerio> (ha see what i did there) [11:18:45 CET] <thebombzen> http://0x0.st/tEX.mkv [11:18:51 CET] <furq> i do see what you did there [11:18:53 CET] <thebombzen> haasn needs his waifu [11:18:58 CET] <thebombzen> at 8 Mbps [11:19:30 CET] <kerio> thebombzen: ok i have to admit [11:19:37 CET] <kerio> that is some fucking high quality chinese animation [11:19:57 CET] <kerio> what's the crf [11:20:15 CET] <Spring> p good quality [11:20:27 CET] <thebombzen> this cause I just used a script which set -b:v to 7.5M [11:20:32 CET] <thebombzen> if I used crf it'd be better [11:20:36 CET] <furq> you said "it's all downhill from there", which is a joke about how initial d is an animes about young men using their cars to participate in "touge battles", a form of street racing where the cars drive down mountainous passes which is popular in japan, where "downhill" carries the double meaning of things becoming worse and also the way that the cars driven by initial d and his friends and rivals are [11:20:42 CET] <furq> travelling [11:20:48 CET] <furq> as such, it is a good joke [11:20:51 CET] <furq> well done [11:20:56 CET] <kerio> ty [11:20:58 CET] <thebombzen> and kerio I don't think Ufotable is a chinese studio [11:21:05 CET] <thebombzen> but they might have a chinese division [11:21:13 CET] <thebombzen> Madhouse has a division in Korea [11:25:56 CET] <Nacht> Anyone know how I can check if all packages of an TS files are 188bytes long with ffprobe ? [11:36:08 CET] <termos> I'm doing avcodec_send_packet in one thread and avcodec_receive_frame in another, but since I can have any number of codec contexts on the receiving end how do I know which one to pick? [11:36:56 CET] <BtbN> Nacht, if they weren't, it wouldn't be a .ts file. [11:36:57 CET] <DHE> the AVCodecContext is something you allocate and provide (except in older versions of ffmpeg where you can use the one in the AVStream of the input). [11:37:16 CET] <DHE> BtbN: sounds like the issue is, how do I check for corruption [11:37:34 CET] <Nacht> BtbN: The thing is, once I create an HLS VOD with AES on it, the files aren't x188 long anymore [11:37:48 CET] <BtbN> termos, I'm pretty sure you can't multithread libavcodec like that. [11:37:50 CET] <DHE> well that does happen because AES is a 16 byte block cipher [11:37:53 CET] <termos> I have it allocated myself not using the one in AVStream, when I do send_packet I use the context corresponding to the input packet based on AVPacket.stream_index [11:38:09 CET] <DHE> termos: that sounds right [11:38:25 CET] <termos> I'm guessing on the receiving end I need to loop through all my input streams and try to pull from each of the codec contexts? [11:39:11 CET] <DHE> I agree with BtbN here. libavcodec is likely not thread-safe when the same context is used in multiple threads without any locking on your end [11:40:16 CET] <Nacht> The thing is, we're trying out HLS AES for an Android Unity player, but it isn't working. They claim it's due to the packages not being 188bytes long. I just can't think up a way to check this. Since every TS package inspector I can find can't work with AES. FFprobe can, but I'm not sure where to find the value I need [11:40:18 CET] <termos> ah yes I have a mutex around all usage of the codec context [11:41:07 CET] <DHE> Nacht: then your player is broken. it's a requirement of AES that every file be a multiple of 16 bytes. even openssl enc will pad files [11:42:57 CET] <Nacht> DHE: Cheers mate, I can work with that. [11:52:54 CET] <termos> looping through all the codec context and trying to pull from each of them seems to be the way to go [12:00:37 CET] <thebombzen> out of curiosity, have there been any subjective comparisons between hevc_nvenc and x264? [12:01:06 CET] <furq> i'm pretty sure people in here have said x264 is a lot better [12:11:35 CET] <thebombzen> so I just did some testing and x264 is indeed better at the slower presets like -preset slow [12:11:43 CET] <thebombzen> but at faster presets nvenc wins [12:12:37 CET] <kerio> i shall stream with -preset placebo [12:13:04 CET] <thebombzen> I'm sure your viewers will love the 16 bframes [12:18:21 CET] <thebombzen> furq: by the way I was comparing x264 10bit to hevc_nvenc 10bit [12:18:26 CET] <thebombzen> this was also 1080p [12:18:40 CET] <thebombzen> and itappeared that at the fast presets x264 lost its edge [12:18:54 CET] <thebombzen> but it might also lose it for huge videos like 4k [12:19:50 CET] <nolaan> Hi, I'm trying to build ffmpeg 3.2.4, for some reason using --enable-omx doesn't result in CONFIG_OMX 1 [12:19:53 CET] <nolaan> Why? [12:28:32 CET] <BtbN> Does 3.2 even support omx? [12:29:41 CET] <furq> yeah [12:30:20 CET] <furq> https://github.com/FFmpeg/FFmpeg/blob/release/3.2/configure#L309 [12:30:58 CET] <furq> nolaan: some options are silently ignored if the headers/libs aren't found [12:31:06 CET] <furq> idk if omx is one of those but you might want to check config.log [12:32:46 CET] <nolaan> furq: I checked config.log and it was disabled (CONFIG_OMX 0) even though --enable-omx is specified [12:32:48 CET] <nolaan> :/ [12:33:36 CET] <nolaan> what are the headers it's looking for? [12:33:45 CET] <furq> https://github.com/FFmpeg/FFmpeg/blob/release/3.2/configure#L5829-L5833 [12:33:48 CET] <furq> nvm i guess that's not it [12:35:09 CET] <nolaan> furq: for the record I have a ffmpeg 3 compiled with omx support [12:35:25 CET] <mcjack> Hi everybody, where do I set the color_range? [12:35:38 CET] <mcjack> the h264 encoder complains: [h264_videotoolbox @ 0x103a17400] Color range not set for yuv420p. Using MPEG range. [12:36:07 CET] <mcjack> I tried: videoContext->color_range = AVCOL_RANGE_JPEG; [12:36:18 CET] <mcjack> that didn't change anything [12:36:43 CET] <mcjack> the result is a black video& [12:40:09 CET] <mcjack> I basically follow the encoding_decoding.c example [12:41:40 CET] <mcjack> you can see the code for setup here: https://github.com/filmstro/filmstro_ffmpeg/blob/master/modules/filmstro_ff… [12:49:17 CET] <mcjack> ok, I found av_frame_set_color_range(), that fixes the warning, but the video is still black& [12:50:11 CET] <mcjack> Also can I somehow deduce the desired color_range from the format? I don't want to hardcode the color_range& [13:08:55 CET] <mcjack> Hi Mavrik, matkatmusic copied me your conversation from this morning, thanks for the suggestions [13:10:14 CET] <mcjack> I use av_image_alloc() like in the example encoding_decoding, and I get three pointers pointing to '\0', the other 5 NULL, sooms correct? [13:10:27 CET] <mcjack> seems [13:14:12 CET] <nolaan> furq: In the context of cross compilation this might be an issue (at least for me ;) ) https://github.com/FFmpeg/FFmpeg/blob/release/3.2/libavcodec/omx.c#L144 [13:14:36 CET] <nolaan> I'm trying configure then I may open an issue [13:22:15 CET] <nolaan> nope [13:22:25 CET] <nolaan> still not able to cross compile omx [13:30:54 CET] <nolaan> meh, you said it : https://github.com/FFmpeg/FFmpeg/blob/release/3.2/configure#L5829-L5833 [13:31:07 CET] <nolaan> ! enabled cross_compile [13:32:31 CET] <furq> that just disables adding the rpi header path if you're cross-compiling [13:32:57 CET] <furq> you can definitely cross-compile omx-rpi [13:45:31 CET] <nolaan> I'm trying :D [13:51:48 CET] <momomo> anyone have any idea as to why hls is no longer playing on ios >= 10 iphones? used to work on my 4s [13:51:54 CET] <momomo> but not on 6 and 7 [13:58:18 CET] <momomo> on this site, i found this info: H.264 Baseline 3.0: All devices [13:58:48 CET] <momomo> my command basically looks like this: [13:58:53 CET] <momomo> /momomo/Other/Software/ffmpeg/ffmpeg-git-20160403-64bit-static/ffmpeg -re -i /momomo/Resources/Tv/Streams/Local/a -vf scale=floor(iw*min(1\,min(1024/iw\,768/ih))/2+0.4999999)*2:-2 -map 0:a:0 -map 0:v:0 -preset veryfast -x264-params scenecut=0 -crf 24 -g 125 -r 25 -x264opts keyint_min=125 -c:v libx264 -c:a aac -ac 2 -b:a 128k -f hls -hls_list_size 5 -hls_time 5 -sn /momomo/Generated/Tv/streams/2202367692__Locala/a [14:15:00 CET] <ZeroWalker> does rtp work with multiple streams? (audio + video)? [14:53:46 CET] <nolaan> ZeroWalker: normally yes [14:54:53 CET] <momomo> nolaan: anyone know why hls is no longer wokring in iios ? [14:54:59 CET] <momomo> >= 9.35 [14:57:04 CET] <nolaan> momomo: nope sorry [15:00:10 CET] <Nacht> momomo: No idea why it's not working. Just a question though, why a GOP of 125 ? [15:02:29 CET] <momomo> Nacht: i dont' remember .. i think it was to get a reliable ts length in seconds ... not sure though [15:02:46 CET] <momomo> Nacht: is that expensive / not good? [15:03:33 CET] <momomo> "consistent" .. maybe it was the file size .. not sure ... i don't think it's neccessary anymore [15:03:39 CET] <momomo> should I remove it? [15:16:25 CET] <Nacht> 125 is quite allot, means you have 5 seconds of P or B frames. Where the default is 1 second [15:16:52 CET] <Nacht> One fault slipping in, and you get lots of artifacts [15:18:14 CET] <furq> the default for x264 is 250 [15:18:16 CET] <alexpigment> Nacht: to be fair, i think ffmpeg defaults to 250 keyint these days [15:18:19 CET] <alexpigment> yeah [15:18:33 CET] <alexpigment> but i agree that 250 (or 125) is dumb [15:18:45 CET] <alexpigment> i usually do keyint = framerate [15:18:54 CET] <Nacht> Aye, same here [15:18:56 CET] <furq> you definitely don't want 1-second gops for hls because every segment is a new request [15:19:14 CET] <furq> five seconds is probably about right [15:19:24 CET] <furq> and there's not much point having keyframes within segments [15:19:42 CET] <Nacht> Means he has 5 I frames per fragment. [15:19:45 CET] <alexpigment> (oh i see this is related to HLS from an earlier convo - i'll defer to furq's expertise here [15:20:17 CET] <Nacht> You have a point there Furq [15:20:36 CET] <furq> i don't really see the problem with 10-second gops in general [15:20:39 CET] <Nacht> The 125 does make sense then. One 1 frame per segment [15:20:47 CET] <furq> or whatever 250 frames works out to [15:21:21 CET] <furq> it makes accurate seeking slightly more annoying but it's not often i care about that sort of precision [15:21:40 CET] <furq> and if your input is defective then you've got bigger issues than gop size [15:22:13 CET] <Nacht> Shouldn't it be 2 I-frames per segment tho ? With a 125 GOP and 5 sec fragments, he will only have 1 per segment [15:22:31 CET] <furq> why would you need two [15:22:52 CET] <Nacht> I recall reading that regarding HLS [15:23:02 CET] <Nacht> It's not requires, but adviced [15:23:06 CET] <Nacht> *d [15:23:32 CET] <furq> https://developer.apple.com/library/content/technotes/tn2224/_index.html#//… [15:23:53 CET] <furq> i'm not sure why it says "we recommend at least one" because i don't think it'll work without that [15:24:20 CET] <furq> i'm fairly sure ffmpeg won't let you do that [15:25:23 CET] <furq> oh, -hls_flags split_by_time [15:25:28 CET] <furq> so it's fairly well buried at least [15:27:36 CET] <alexpigment> momomo: did you see this article? https://flowplayer.org/forum/#!/flowplayer/setup:hls-not-longer-works-with-i [15:28:41 CET] <alexpigment> according to the last post, it was fixed in iOS on 2016-10-21 . presumably you're on the latest version of iOS? [15:29:00 CET] <alexpigment> typo; fixed on 2016-12-21 [15:29:07 CET] <momomo> alexpigment: no, i don't know .. i am on 9.3.5 [15:29:17 CET] <momomo> in 4s it is the latest [15:29:21 CET] <momomo> i don't have an iphone [15:29:24 CET] <alexpigment> momomo: as a 5s owner, i envy you [15:29:24 CET] <momomo> iphone 6 [15:29:28 CET] <momomo> hehe [15:29:31 CET] <momomo> can you try? [15:29:40 CET] <momomo> i will send you a private pm [15:30:01 CET] <alexpigment> lemme make sure *I'm* on the latest iOS first [15:31:47 CET] <momomo> alexpigment: i thought you said they fixed it on the latest version [15:31:59 CET] <momomo> or they broke it again? [15:33:02 CET] <momomo> furq: i missed gthe conversation about GOP's ... the conclusion was that I should keep or change something? [15:33:11 CET] <furq> what you have is fine [15:33:53 CET] <Nacht> What furq says [15:37:15 CET] <momomo> lol :) [15:38:58 CET] <DHE> it's not a bad setting, it just seems odd since it's not, shall we say, an obviously clean number of seconds. [15:39:22 CET] <DHE> oh, actually you set 25fps so it does kinda work [15:40:35 CET] <Nacht> Yeah, only note worty is that even apple advices an fragment size of 6 sec, as specified in that link furq gave [15:42:04 CET] <Nacht> Altho, I did read an article by bitmovin.com where they advice chunks of 2-4 seconds now-a-days [15:42:08 CET] <Nacht> https://bitmovin.com/mpeg-dash-hls-segment-length/ [15:45:34 CET] <momomo> Nacht: i use 5s [15:45:56 CET] <momomo> i think that's the minimum on ffmpeg [15:46:22 CET] <furq> it isn't [15:47:19 CET] <furq> but five is fine and it's not the problem anyway [15:53:01 CET] <momomo> on ios devices > 9.3.5 ... only the first playlist is ever served .. once it's served .. no requests for a ts file is made ... it fails on reception... maybe it's parsing it incorrectly .. maybe its responded with the wrong headers ... not containing new required hls tags? any ideas on the hls specifiation require,ments ? [16:45:39 CET] <momomo> I was able to play this playlist ( Apple ) : <video src="http://devimages.apple.com/iphone/samples/bipbop/gear1/prog_index.m3u8" /> [16:45:56 CET] <momomo> so it's wierd ... here is a comparison between theirs and my ffmpeg generated one [16:46:00 CET] <momomo> https://hastebin.com/ipatucexog.http [16:46:47 CET] <momomo> when i play mine in ios mobile browser .. the request for the playlist is made and i serve the playlist, but then an error occurs ... no request is every made for a ts segment file .. so it cant be the ts file format or encoding issues [16:46:51 CET] <momomo> it's related to the playlist file [16:47:03 CET] <momomo> i think the specification must have changed [16:47:59 CET] <Nacht> 2nd one is a VOD, so you only request the manifest once [16:49:14 CET] <benlieb> Im trying to reduce some file sizes of some audio that I use for music practice (doesnt need to be amazing quality). Currently Ive compressed the stereo into mono which helped a bit but wondering how to further reduce this: Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, mono, fltp, 96 kb/s (default) [16:49:55 CET] <benlieb> can I affect the 44100 or 96 kb/s directly? [16:50:08 CET] <benlieb> not sure what those correspond to. [16:50:13 CET] <benlieb> ie, not an expert here [16:50:19 CET] <alexpigment> ok so you don't need 96kbps [16:50:34 CET] <DHE> -b:a 96k # audio bitrate [16:50:56 CET] <alexpigment> audio bitrates are specified as the total bitrate for all channels, so reducing to mono doesn't change the bitrate [16:51:23 CET] <alexpigment> so if you change 48kbps, it'll have the size of the audio [16:51:34 CET] <alexpigment> and be the equivalent quality of a stereo 96kbps stream [16:52:24 CET] <Nacht> the 44100 is your sampling rate. (44.1 kHz) [16:53:39 CET] <Nacht> Some more info regarding them: http://wiki.audacityteam.org/wiki/Sample_Rates#rate [16:53:43 CET] <benlieb> looking a little more I found -ar 22050. This reduced the file size by half. Is this a good way to do what Im trying to do? [16:54:03 CET] <alexpigment> i don't recommend going to 22khz unless you just don't care about quality [16:54:14 CET] <benlieb> could you clarify the difference between sample rate and bit rate? [16:54:16 CET] <kepstin> try reducing the bitrate of the 44.1kHz file first [16:54:20 CET] <alexpigment> 32khz is somewhat transparent, but 44.1khz is CD quality [16:54:34 CET] <alexpigment> yeah, just go to 48kbps if you're going to be in mono [16:55:57 CET] <benlieb> alexpigment: how would I do that exacly? [16:56:08 CET] <benlieb> -b:a 48k ? [16:56:30 CET] <alexpigment> -c:a aac -ar 44100 -b:a 48000 -ac 1 [16:56:35 CET] <mcjack> benlieb: samplerate is the decoded rate vs. bitrate is the encoded rate [16:56:42 CET] <furq> what are you playing this back with [16:56:48 CET] <furq> if it's something that supports opus then you should use that [16:57:01 CET] <alexpigment> furq: HE-AAC is probably a safer bet than OPUS [16:57:11 CET] <furq> for compatibility, sure [16:57:16 CET] <furq> except the ffmpeg aac encoder doesn't support it [16:57:24 CET] <benlieb> furq: Im just playing it on any audio player. I have these on different devices and just use it to practice playing against different chord progressions [16:57:29 CET] <alexpigment> oh right. that's just fdk i guess [16:57:32 CET] <benlieb> exporting via iReal Pro [16:58:04 CET] <furq> if you're on *nix then you could maybe install the standalone fdk encoder [16:58:13 CET] <furq> he-aac is much better at low bitrates [16:58:24 CET] <benlieb> furq: on mac [16:58:26 CET] <furq> opus is still better but that's no good if you can't play it back [16:58:32 CET] <alexpigment> he-aac is usually 48kbps in my experience, except you get stereo and it sounds like true 44.1 [16:59:24 CET] <benlieb> thanks for the input everyone. I have my audio down to about 40% of the orig and that is a good start. [16:59:33 CET] <furq> fdk is in homebrew if you have that [16:59:59 CET] <furq> although if you have homebrew then you could potentially just rebuild ffmpeg with fdk [17:05:55 CET] <delicado> hi, are we allowed to package all the libraries into one binary? If so, how should I call it?... In ffmpeg license, it says here: "Do not rename FFmpeg dlls to some obfuscated name, but adding a suffix or prefix is fine (renaming "avcodec.dll" to "MyProgDec.dll" is not fine, but to "avcodec-MyProg.dll" is)." - so is it okay to rename the library as ffmpeg-codec.dll because it includes all those [17:05:55 CET] <delicado> separate libraries into one dll? [17:08:05 CET] <nido> [1;2Hffmpeg-libavcodec_libavdevice_libavfilter_libavformat_libavresample_libavutil_libpostproc_libswresample_libswscale.dll :) [17:08:26 CET] <kepstin> ask a lawyer? But you're not hiding the fact that they're ffmpeg libraries, so.. :/ [17:09:13 CET] <Mavrik> delicado, you can always statically link [17:09:20 CET] <Mavrik> of course if you obey the licesnes [17:09:59 CET] <kepstin> (I don't think there's any support in the ffmpeg build system for building all the libraries into a single shared object, so if you do that, make sure you make available the modified source...) [17:12:27 CET] <delicado> yes I woudn't hide that it is using the ffmpeg library. I just don't know why everytime i try to build the ffmpeg source code, it builds one big static library that includes all the ffmpeg modules.. So, I just let it and build it into a dll along with a wrapper.. [17:19:44 CET] <thebombzen> I mostly use opus for high bitrate stuff (like 128k) but how does it compare to he-aac at low bitrates [17:20:18 CET] <thebombzen> libopus outperforms everything else (including quicktime) at high bitrates [17:22:13 CET] <kepstin> thebombzen: only comparison I can find is 64kbit stereo, where opus was slightly better than he-aac. http://listening-tests.hydrogenaud.io/igorc/results.html [17:26:12 CET] <thebombzen> also [17:26:18 CET] <furq> opus is designed to work well across the whole range [17:26:18 CET] <thebombzen> if I want to patch my own local copy of ffmpeg [17:26:38 CET] <thebombzen> is there is a way to do this and still allow me to update the repo via git pull [17:26:39 CET] <furq> whereas aac had to have that retrofitted with stuff like he [17:26:42 CET] <thebombzen> ah [17:27:05 CET] <thebombzen> I want to patch an annoyance but I don't want to have to deal with git stuff [17:27:07 CET] <furq> not that you can brag about opus' compatibility, but at least you know that every opus file will work on something that supports opus [17:27:11 CET] <kepstin> thebombzen: just commit your patches, then use "git pull --rebase" to update from git [17:27:17 CET] <furq> which is more than can be said for aac [17:27:37 CET] <thebombzen> kepstin: do I need to use git pull --rebase once, or every time I git pull? [17:27:50 CET] <kepstin> every time you pull, otherwise it'll merge on top of your patch [17:28:01 CET] <kepstin> alternative: use 'git stash; git pull; git stash apply' [17:28:26 CET] <furq> what are you patching [17:28:55 CET] <thebombzen> I want to change nut's default video and audio to ffv1/flac [17:28:58 CET] <thebombzen> rather than mpeg4 [17:29:10 CET] <furq> oh [17:29:16 CET] <furq> i guess that's not the kind of thing that'd be accepted upstream [17:29:24 CET] <furq> mostly because it should obviously be rawvideo/pcm_s16le [17:32:12 CET] <thebombzen> yea I know that they'd reject it upstream [17:32:24 CET] <thebombzen> speaking of pcm_s16le [17:32:30 CET] <thebombzen> why isn't there just one codec [17:32:32 CET] <thebombzen> rawaudio [17:32:38 CET] <thebombzen> instead of one for each sample format [17:32:46 CET] <thebombzen> we don't have a different video codec for each pixel format [17:32:56 CET] <furq> probably the same reason as the last time you asked this [17:34:57 CET] <momomo> CAN SOMEONE PLEASE **** TELL ME WHAT THE DIFFERENCE IS BETWEEN THESE TWO PLAYLISTS ARE? BOTH ARE SERVED FROM MY SERVED, THE LOWER ONE TAKEN FROM APPLES M3U8 FILE. IVE MODIFIED IT AND SERVED IT FROM MY SERVER. THE LOWER ONE WORKS, THE UPPER ONE DOESN"T. [17:35:02 CET] <momomo> https://hastebin.com/qoroqukuye.css [17:35:58 CET] <momomo> it both cases the m3u8 is served .. but for the above one no ts file is asked for. for the lower one ... it works and the player plays ... [17:36:17 CET] <furq> er [17:36:26 CET] <furq> EXT-X-TARGETDURATION should be 5 in the upper one [17:36:33 CET] <kepstin> momomo: why did you set the target duration to 1 second in the top one? [17:36:40 CET] <furq> i assume ffmpeg did that [17:37:41 CET] <kepstin> hmm. but the segments are still listed as 5s, my impression is that ffmpeg uses the min of the segment lengths as target duration? [17:38:02 CET] <momomo> kepstin: because that has worked prioerly to have dynamic target duration [17:38:06 CET] <momomo> i just discovered it too [17:38:11 CET] <momomo> changing to 5 worked [17:38:29 CET] <momomo> the target duration if modified will tell the player when to request the next m3u8 [17:39:00 CET] <momomo> so I dynamically detect the file on the server and tell the playlist when the next one will be available [17:39:22 CET] <momomo> seems apple stopped supporting that [17:40:03 CET] <momomo> values of 3 works [17:40:07 CET] <momomo> but not lower, 2 or 1 [17:40:10 CET] <momomo> strange [17:40:23 CET] <furq> that's dumb that they'd break that but it is part of the spec [17:40:25 CET] <kepstin> huh, according to the spec, the targetduration is supposed to be set to the "maximum media segment duration" [17:40:29 CET] <furq> yeah [17:40:44 CET] <kepstin> so having it shorter than all the segments could cause issues, i guess :/ [17:41:09 CET] <furq> it's really dumb that "issues" would include the stream not playing at all [17:41:11 CET] <kepstin> they say "[having segments longer than target duration] longer segments can trigger playback stalls or other errors" [17:41:17 CET] <furq> thanks, apple [17:41:18 CET] <furq> thapple [17:41:29 CET] <kepstin> so "playback stalls or other errors" allows it not playing at all. [17:41:37 CET] <momomo> yeah, 1, 1, 1 worked [17:41:41 CET] <furq> i'm not saying it's outside the spec for it to break [17:41:45 CET] <momomo> however, 3, 5, 5 also worked [17:41:47 CET] <furq> just that it's really dumb that that would happen [17:41:51 CET] <furq> especially if 3 works [17:42:22 CET] <kepstin> i guess this player just has issues if the difference between the target duration and the segment durations is too big, maybe? [17:42:34 CET] <thebombzen> kepstin: do I need git pull --rebase each time [17:42:40 CET] <thebombzen> or is one successful pull enough [17:42:45 CET] <furq> you need to rebase every time [17:42:52 CET] <kepstin> thebombzen: I already answered that [17:42:54 CET] <furq> 16:27:50 ( kepstin) every time you pull, otherwise it'll merge on top of your patch [17:42:57 CET] <furq> 16:28:01 ( kepstin) alternative: use 'git stash; git pull; git stash apply' [17:43:04 CET] <momomo> the thing is that when a the player requests the first playlist ... i serve the last - 2 playlist .. in order to stay ahead of the buffer ... and to control the buffer ... so the next playlist is available immediately .. i normally set that to 1 .. prior, apple would fetch that next one at 1 [17:43:07 CET] <thebombzen> ohw elloka [17:43:10 CET] <thebombzen> oh well okay [17:43:11 CET] <momomo> i even tweaked hls.js to do that too [17:43:12 CET] <thebombzen> can't read [17:43:20 CET] <momomo> because that provided a better playing experience [17:43:22 CET] <furq> you'd think a too short target duration would just cause the player to make a bunch of redundant requests [17:43:35 CET] <furq> maybe it just dies if it makes two requests and the playlist hasn't updated [17:43:36 CET] <momomo> furq: not if the answer is with a new playlist [17:43:40 CET] <furq> which would explain why 3 works [17:43:52 CET] <momomo> furq: no, only one request is ever made [17:43:56 CET] <furq> oh [17:43:57 CET] <momomo> for the first playlis [17:43:58 CET] <momomo> t [17:44:15 CET] <furq> it must actually be checking targetduration against extinfs then [17:44:19 CET] <momomo> just so stupid that the have an if block < 3 .. break [17:44:20 CET] <furq> which is incredibly stupid [17:45:46 CET] <kepstin> well, they warn that setting targetduration too short can cause playback stalls, and that's... apparently what it does :/ [17:45:55 CET] <furq> it causes a stall that lasts forever [17:45:57 CET] <momomo> yes, it wasn't like this in previous versions eitehr ... i guess now my ios users will be supplied an old playlist .. but start the download of the next avaialble segment file 2 seconds too late .. which would ruin the experience for slow connected users [17:46:14 CET] <momomo> kepstin: it doesnt do that .. no stalls occur [17:46:21 CET] <momomo> an error is thrown when reading hte playlist [17:46:41 CET] <furq> if i was being generous i could call that a stall [17:46:51 CET] <momomo> if target duration has to be set to 5 .. then how can one control when to load the next segment file ... if one do not want to wait 5 full seconds? [17:46:57 CET] <furq> but this is iOS safari so i'm absolutely not going to be generous [17:47:19 CET] <thebombzen> also does anyone know why mpeg4 is the default for nut? [17:47:31 CET] <kepstin> momomo: the player is supposed to start downloading the next segment based on its estimation of when it'll be needed, that's not really something you control... [17:47:34 CET] <furq> probably because it's a builtin encoder [17:47:41 CET] <furq> that question might be better suited to #ffmpeg-devel [17:47:47 CET] <thebombzen> furq: but for audio it checks for libvorbis's existence [17:47:47 CET] <kepstin> if the segment lengths are set right, it should know when it'll need the next file :/ [17:47:52 CET] <thebombzen> and defaults to libvorbis if it'st here [17:48:00 CET] <furq> ok that's just completely stupid then [17:48:24 CET] <thebombzen> maybe because x264 is gpled [17:48:27 CET] <thebombzen> but still [17:48:33 CET] <thebombzen> the "existence" thing should deal with that [17:48:35 CET] <momomo> kepstin: if i decide that my player should start N back, and not close to the live edge ... then I should be able to tell player that next segment file is already available [17:48:43 CET] <momomo> maybe there is a tag for that [17:49:00 CET] <furq> surely if the next segment is available then it's already in the playlist [17:49:34 CET] <kepstin> so your problem is that the player isn't starting with the first segment in the playlist, but it rather skipping forwards to the latest one? [17:49:40 CET] <momomo> exactly [17:50:06 CET] <momomo> at least hls.js is hard to control without this dymanic target duration ... i have total control of it now .. which is ideal [17:50:11 CET] <momomo> with ios i no longer do [17:50:27 CET] <DHE> you need EXT-X-ENDLIST or EXT-X-PLAYLIST-TYPE to make it play from the beginning [17:50:45 CET] <DHE> without them it's assumed to be a live stream and players will play from near the end. [17:51:02 CET] <DHE> (ie. the most recent and most live) [17:51:06 CET] <momomo> kepstin: i don't want to start the begining ... but on N - 2 from live edge .. [17:51:15 CET] <kepstin> it sounds like they might have changed this on purpose in the ios player so that they control the buffers rather than have tricks played by against-spec servers :/ [17:51:57 CET] <momomo> anyhow .. i can probably figure out a way to beat it [17:52:31 CET] <momomo> i basically only tweak he playlist on the first requests ... then it gets back to 4 or 5 seconds ... which seemed to be fine [17:52:50 CET] <DHE> I don't think you, as the server owner, can force playback from any particular segment safely. maybe faking an EVENT? [17:52:56 CET] <kepstin> i'd expect it to work fine if the first playlist includes all the files except the last, the later playlists include all the files, and the segment durations are set correctly. [17:53:05 CET] <momomo> DHE: I will look into those tags [17:53:10 CET] <kepstin> i.e. the second request adds two files to the end [17:53:12 CET] <momomo> have to go... thanks [17:53:14 CET] <kepstin> instead of just one [17:53:23 CET] <momomo> kepstin: yes [17:53:25 CET] <momomo> thank too [17:53:27 CET] <momomo> that too [17:53:54 CET] <momomo> at least i figured out why today :S [17:54:26 CET] <DHE> yeah, all you can do is direct users to play "From the start" and "From near the end (intentionally vague)" [17:55:31 CET] <momomo> DHE: which tag is that specifically? [17:55:34 CET] <kepstin> hls is designed to be player-controlled, since presumably the player knows better than the server how much buffer ram it has, how fast its connection is. ANd it can be served from "dumb" http-only servers of course... [17:56:16 CET] <momomo> kepstin: that's stupid because the only thing the server can control is itself, not all the various players out there [17:56:52 CET] <DHE> momomo: with EXT-X-ENDLIST you're not allowed to modify the list, but the client will start from the beginning. with EXT-X-PLAYLIST-TYPE:EVENT you're only allowed to append to the list but it can grow and the player should start from the top (if I understand correctly) [17:57:21 CET] <kepstin> momomo: huh, looks like you might be able to do what you want with https://tools.ietf.org/html/draft-pantos-http-live-streaming-20#section-4.3… [17:57:26 CET] <kepstin> EXT-X-START [17:57:27 CET] <momomo> DHE: yes, i htink ENDLIST is for static m3u8's [17:57:29 CET] <kepstin> er, wrong link [17:57:33 CET] <momomo> not live content [17:57:47 CET] <kepstin> https://tools.ietf.org/html/draft-pantos-http-live-streaming-20#section-4.3… - works on non-live streams [17:58:03 CET] <kepstin> but it's just a "preferred point", and players can (and will) ignore it [17:59:06 CET] <momomo> kepstin: does it say it doesn't work on live streams? [17:59:41 CET] <kepstin> momomo: no, it just says that on a non-live stream you shouldn't start within 3 target durations of the last file in the playlist. [17:59:55 CET] <momomo> ook great, it must be the tag i am after :) [18:00:52 CET] <kepstin> with your playlist with a target duration of 5, you can probably just set it to "-15" as a hint to the player that you want it to buffer 3 segments. [18:00:56 CET] <momomo> however, i have to say dynamic target duration is still very good .. many times the player won't do the requests at the price time ... so if a file is served too late, it will still probably make the request 5 seconds later ... rather if tweaked you would almost always be spot on [18:02:03 CET] <kepstin> if you set the length of each segment in the playlist to the exact length of the segment file, i'd expect that to work fine... [18:03:35 CET] <momomo> kepstin: ffmpeg does that .. but playback issues do still occur .. also .. not sure how it works, but say if a ts file is served precisely when it is created, but takes 3 secondsd for the user to recieve for some temporary reason, the player will start to play it ... not sure if it subratacs 3 seconds from the asking of the next playlist [18:04:00 CET] <momomo> i think hls.js still waited 5 seconds [18:04:07 CET] <kepstin> momomo: the player is supposed to make the next playlist request when it decides it needs to find the next segment. that's up to the player :/ [18:05:48 CET] <kepstin> hmm, the hls spec does actually say some stuff about playlist reloading [18:06:29 CET] <kepstin> wait at least target duration between reloads, and if the playlist hasn't updated, try again after œ target duration [18:07:56 CET] <kepstin> huh, "If the EXT-X-ENDLIST tag is not present and the client intends to play the media normally, the client SHOULD NOT choose a segment which starts less than three target durations from the end of the Playlist file. Doing so can trigger playback stalls." [18:08:03 CET] <kepstin> is the ios player ignoring that? :/ [18:08:24 CET] <meldron> hey guys can somebody explain me the difference between x264 videos with avc1 and avc3 and how I can transcode them with ffmpeg? (has -preset veryfast something to do with it?) [18:11:24 CET] <alexpigment> meldron: where are you seeing avc3? [18:12:08 CET] <kepstin> meldron: it looks like https://lists.freedesktop.org/archives/gstreamer-bugs/2013-June/104266.html has a decent description of what avc1 vs avc3 does - it's a difference in the mp4 muxing, not in the actual video encoding. [18:12:59 CET] <kepstin> I have no idea which format ffmpeg outputs, someone with better knowledge of mp4 would have to answer that :) [18:13:17 CET] <kepstin> but probably avc1, at least by default [18:13:46 CET] <alexpigment> it sounds like we need more information about why meldron is forced to know the difference and why he needs to transcode [18:14:18 CET] <alexpigment> but if avc3 is causing a problem, i suspect that a -c:v copy -c:a copy would do the trick [18:38:32 CET] <meldron> I transcode several videos with ffmpeg afterwards I have to concat them into a single video [18:38:44 CET] <meldron> for the first step i am using ffmpeg and for the second mp4box [18:43:00 CET] <meldron> I thought that i encode all videos with 'ffmpeg -y -i {} -c:v libx264 -r 25 -pix_fmt yuv420p -level:v 4.1 -strict -2' i should be able to concat them without problems [18:45:24 CET] <kuroro> does anyone know android here? [18:46:33 CET] <kuroro> using static ffmpeg binary to do a concat of short mp4s and its currently very slow [18:46:57 CET] <kuroro> in android devices [18:47:54 CET] <kuroro> looking for faster alternative (i.e MediaCodec, MediaMuxer, or libffmpeg in-memory transcoding) [18:48:31 CET] <alexpigment> meldron: is that your entire command line? [18:48:51 CET] <BtbN> sounds like you forgot -c copy? [18:49:26 CET] <meldron> alexpigment: i left out the image overlay [18:49:44 CET] <meldron> but basically yeas [18:49:55 CET] <alexpigment> you mentioned -strict -2, which is required for AAC audio in older builds, but you didn't specify any other audio parameters [18:49:58 CET] <furq> do you nede to encode them separately [18:50:00 CET] <furq> need [18:52:32 CET] <alexpigment> i suspect furq is implying that concat with MP4box is unnecessary if you're going to re-encode with ffmpeg in the first place [18:53:37 CET] <sectroyer> I have a questions. Does reimar still appear here? [18:56:07 CET] <furq> meldron: if you do need to encode them separately then use mpegts or some format which is better at that than mp4 [18:56:18 CET] <furq> but otherwise, you can do it all with ffmpeg [18:56:24 CET] <furq> either by using the concat demuxer or the concat filter [18:56:37 CET] <furq> the filter is better but more annoying to automate [19:01:36 CET] <momomo> kepstin: the thing is that the target duration info is kind of useless to even provide.. as each segment length is already specified. the entire point of the target duration must be to forgo the actual length of the ts file being played and use target duration to load the next one... the player need not the target duration to determine that other than have the actual lengths of each ts file ... which it does .. so what is the intent of target duration if [19:01:36 CET] <momomo> not to be dynamically modified? [19:05:12 CET] <meldron> furq: so i have a multi step approach, in the first step i create all the video parts and in the second they will be concatnated but not all of them everytime [19:05:28 CET] <meldron> alexpigment: ah thanks, some artifcates I forgot what the were about [19:06:00 CET] <alexpigment> meldron: the other thing i was going to mention is that you haven't specified any quality options - like -crf or -b:v - i presume you're OK with the default quality? [19:06:21 CET] <furq> momomo: https://developer.apple.com/library/content/technotes/tn2235/_index.html#//… [19:06:41 CET] <furq> WARNING: INF tag with duration 2 seconds or more above the playlist's target duration (10.000 seconds) [19:06:45 CET] <furq> i guess that explains it [19:06:57 CET] <furq> they're obviously forcing that in the player now [19:07:07 CET] <furq> i'm still yet to find a decent explanation for why, though [19:08:32 CET] <furq> i guess users are more likely to blame choppy playback on apple/safari, but a straight error will be blamed on the stream operator [19:09:03 CET] <meldron> alexpigment: I also tried preset veryfast, but may be i have to do some fine tuning there, do you have any suggestions? [19:09:40 CET] <furq> meldron: if you have a good reason to concat them separately then you should definitely use something like mpegts as an intermediate container [19:10:14 CET] <meldron> furq: ah okay, can you point me to some info about mpegts? [19:10:31 CET] <furq> https://en.wikipedia.org/wiki/MPEG_transport_stream [19:10:35 CET] <furq> just replace .mp4 with .ts [19:10:52 CET] <furq> it's designed for streaming, so it's much less hassle for concatenating [19:12:19 CET] <momomo> furq: i have below though, not above [19:12:40 CET] <furq> that warning is for EXTINF > EXT-X-TARGETDURATION [19:12:47 CET] <momomo> ooh, ok [19:13:17 CET] <furq> that tool looks potentially useful but i have no idea if it works on anything but osx [19:13:46 CET] <momomo> it's stupid, because my tweaking of hls.js to use a dynamic target duration ( it uses a fixed and will ignore any values besides the first ) has led to much greater reliability [19:14:57 CET] <ZeroWalker> isn't there any point to point streaming for video and audio together? [19:16:55 CET] <meldron> thx alot [19:17:02 CET] <meldron> everybodt [19:22:15 CET] <meldron> furq: but then i will to have reencode during concat? [19:55:36 CET] <Dresk|Dev> I've Googled and oogled and oh so much, why is it when I extract the pure video stream from a file and audio stream and remux them with ffmpeg that the audio chops? [20:13:38 CET] <alexpigment> Dresk|Dev: What codecs are used for the elementary streams (video and audio), and what format/container are you muxing them into? [20:14:43 CET] <Dresk|Dev> Video is H.264 high profile, audio is aac made by some professional people, muxing into .mp4 [20:15:21 CET] <DHE> if you extracted into a pure H264 elementary stream, are sure you got the framerate right in the end? [20:17:13 CET] <Dresk|Dev> http://pastebin.com/Hj2ptNrX - Original video, before extraction [20:18:13 CET] <DHE> okay, looks like 30fps material in mpeg-ts [20:18:18 CET] <Dresk|Dev> http://pastebin.com/DMAdXtGw - Video after extraction [20:20:44 CET] <alexpigment> DHE - does it seem weird to you that the bitrate is way different between the two? [20:20:59 CET] <Dresk|Dev> It did to me [20:21:07 CET] <Dresk|Dev> I figured that was a calculation [20:21:29 CET] <kepstin> Dresk|Dev: what's the ffmpeg command you used to mux the files together, and its output? [20:21:35 CET] <Dresk|Dev> ffmpeg %CREATEVIDEOS_FFMPEG_PREFIX% -i %CREATEVIDEOS_INPUTFILE% -vcodec copy -an -y "%CREATEVIDEOS_VIDEOSTREAM_OUTPUT_FILENAME%" [20:21:42 CET] <Dresk|Dev> Easy to fill in the %s [20:21:49 CET] <Dresk|Dev> The prefix is just -stats [20:22:00 CET] <Dresk|Dev> So that's extract video [20:22:00 CET] <alexpigment> -an [20:22:04 CET] <alexpigment> oh nm [20:22:05 CET] <alexpigment> continue [20:22:10 CET] <Dresk|Dev> Here's audio : ffmpeg %CREATEVIDEOS_FFMPEG_PREFIX% -i %CREATEVIDEOS_INPUTFILE% -acodec copy -vn -y "%CREATEVIDEOS_AUDIOSTREAM_INPUT_FILENAME%" [20:22:19 CET] <Dresk|Dev> Here's mux : ffmpeg %CREATEVIDEOS_FFMPEG_PREFIX% -i %1 -i %2 -vcodec copy -acodec copy -y "%3" [20:22:31 CET] <alexpigment> MPEG-TS AAC is ADTS right? [20:22:33 CET] <kepstin> Dresk|Dev: and what are the output filenames? with those commands, ffmpeg's behaviour will depend on filename [20:23:02 CET] <kepstin> Dresk|Dev: and why aren't you using a single command to mux both rather than extracting then merging? [20:23:04 CET] <Dresk|Dev> kepstin: I noticed that, why doesn't ffmpeg write the same file despite what extension I give it? The audio only works if I give the filename an .m4a extension [20:23:31 CET] <kepstin> Dresk|Dev: if you don't specify an output format with -f, then ffmpeg guesses which format you want using the file extension [20:24:00 CET] <kepstin> Dresk|Dev: you should probably just run a single command "ffmpeg -i video_input -i audio_input -c copy combined_output" ... [20:24:04 CET] <Dresk|Dev> I'm confused, what format would it have to guess on if I'm extracting the audio just as it is? [20:24:20 CET] <kepstin> Dresk|Dev: it has to have some file format to store the audio in... [20:24:29 CET] <alexpigment> .aac is a raw stream , m4a is the stream inside an MPEG-4 container - which is the common delivery method [20:24:29 CET] <kepstin> some container format* [20:25:45 CET] <alexpigment> ok, so fwiw, i used to have problems like this when converting MPEG-TS to MP4, and the key was to do -c:a copy -bsf:a aac_adtstoasc [20:25:56 CET] <Dresk|Dev> The reason I can't do it at once is because technically the audio input file has over 12 streams, I'm trying to automate it, determining the correct stream is difficult, but doing it in a singular step is much easier in batch [20:25:58 CET] <alexpigment> i don't know if that's what's going on here, but i figured i'd mention it [20:26:26 CET] <kepstin> Dresk|Dev: there's multiple audio streams? [20:27:14 CET] <Dresk|Dev> And then of course I haven't been 100% straight with you guys, VLC plays it fine, but my custom 3D engine which uses FBOs to write ffmpeg frames to as textures and syncs by timestamps is what is causing the audio chopping [20:27:23 CET] <Dresk|Dev> kepstin: Yeah, multiple languages [20:27:59 CET] <kepstin> well, then the extract command you gave isn't what you're actually using either, since it would just pull out the first audio track... :/ [20:28:17 CET] <Dresk|Dev> If I re-encode the video the problem goes away, but I don't want to do that, I don't want more quality loss [20:28:55 CET] <alexpigment> "if i re-encode the video" = re-encode just the video portion, or do you mean re-encoding the video AND audio? [20:29:04 CET] <Dresk|Dev> Just the video [20:29:21 CET] <alexpigment> ok, ignore my AAC ADTS conversion suggestion from earlier [20:29:24 CET] <Dresk|Dev> My engine syncs on timestamps first, and if that doesn't work it tries audio [20:29:29 CET] <kepstin> Dresk|Dev: can you give an exact copy/paste of a command you used to "re-encode the video"? [20:29:37 CET] <kepstin> Dresk|Dev: just gotta make sure :) [20:30:05 CET] <userdr> please how to copy the discution : there is no copy option in my client context menu ? [20:30:31 CET] <Dresk|Dev> Sorry, this is a little longer [20:30:36 CET] <Dresk|Dev> ECHO - Kiosk Optimized MP4 - PASS 1... [20:30:36 CET] <Dresk|Dev> ffmpeg %CREATEVIDEOS_FFMPEG_PREFIX% -i "%CREATEVIDEOS_VIDEOSTREAM_OUTPUT_FILENAME%" -i "%CREATEVIDEOS_AUDIOSTREAM_OUTPUT_FILENAME%" -pass 1 -%CREATEVIDEOS_PIXEL_FORMAT% -an -codec:v libx264 -threads %CREATEVIDEOS_THREADS% -b:v %CREATEVIDEOS_KIOSK_VIDEO_BITRATE% -f rawvideo -y NUL [20:30:36 CET] <Dresk|Dev> ECHO - Kiosk Optimized MP4 - PASS 2... [20:30:36 CET] <Dresk|Dev> ffmpeg %CREATEVIDEOS_FFMPEG_PREFIX% -i "%CREATEVIDEOS_VIDEOSTREAM_OUTPUT_FILENAME%" -i "%CREATEVIDEOS_AUDIOSTREAM_OUTPUT_FILENAME%" -pass 2 -%CREATEVIDEOS_PIXEL_FORMAT% -strict experimental -codec:a aac -ac 2 -b:a %CREATEVIDEOS_KIOSK_AUDIO_BITRATE% -ar %CREATEVIDEOS_KIOSK_AUDIO_FREQUENCY% -codec:v libx264 -threads %CREATEVIDEOS_THREADS% -b:v %CREATEVIDEOS_KIOSK_VIDEO_BITRATE% -y "%CREATEVIDEOS_MP4_KIOSK_FILENAME%" [20:30:48 CET] <kepstin> Dresk|Dev: please use a pastebin site... [20:30:53 CET] <Dresk|Dev> Yeah, sorry [20:30:57 CET] <kepstin> and you *are* re-encoding the audio with that [20:31:01 CET] <kepstin> so, yeah. [20:31:08 CET] <kepstin> that's why I asked :) [20:31:38 CET] <kepstin> you're also maybe resampling the audio too [20:31:52 CET] <kepstin> so all sorts of changes to audio and video, it's hard to guess which one "fixed" it [20:32:13 CET] <alexpigment> ok, throwing this back in the ring. try -c:a copy -bsf:a aac_adtstoasc [20:32:48 CET] <alexpigment> mpeg-ts aac audio won't work correctly in MPEG-4 containers in my experience [20:32:50 CET] <Dresk|Dev> What is the preferred form of synchronization? Timestamps or audio? [20:32:58 CET] <kepstin> Dresk|Dev: ^^ add that to your command that extracts the audio track from the mpeg-ts to the standalone mp4 file [20:33:16 CET] <Dresk|Dev> Trying that now [20:33:46 CET] <kepstin> Dresk|Dev: in general, you should sync the video frame timestamps to the audio clock, since audio rate is determined by the soundcard which runs on a separate clock not synchronized with the cpu clocks [20:35:54 CET] <kepstin> (this gets more complicated when you're working with e.g. hdmi audio or some usb audio modes, but in general...) [20:36:07 CET] <Dresk|Dev> Testing now [20:37:25 CET] <Dresk|Dev> It might be my engine [20:37:28 CET] <Dresk|Dev> Testing again [20:38:11 CET] <kepstin> if it works in vlc and mpv and other players, then yeah, it's probably not the file that's the problem. [20:38:32 CET] <Dresk|Dev> Yeah it's my engine, I have issues in the render thread with vsync, dammit [20:41:07 CET] <Dresk|Dev> https://beam.pro/dresk - Here, this is something cool for you guys, thanks to all your hard work [20:44:18 CET] <furq> i saw that and thought "wow that is a pretty good 3d engine" [20:44:24 CET] <furq> and then realised it was a video of ubisoft's 3d engine [20:44:50 CET] <Dresk|Dev> Heh [20:45:22 CET] <Dresk|Dev> My engine is capable of playing back as many video as possible in a 3D scene, including normal videos and 360 videos in those spheres [20:45:51 CET] <Dresk|Dev> BUT, I've got to disable vsync because I've got some serious timing issues [20:46:07 CET] <Dresk|Dev> The render thread must be starving my other threads [20:47:36 CET] <Dresk|Dev> It's funny that the choppiness always happens at the same spot with vsync [20:47:48 CET] <kepstin> yeah, people are often more sensitive to audio "glitches" than frames being slightly irregularly timed, so make sure you keep the sound card buffers full :/ [20:48:25 CET] <kepstin> if you're getting "choppy audio" that's probably just an underrun on the sound card buffer [20:48:43 CET] <Dresk|Dev> I'm supposed to write a Vulkan renderer so I don't have to worry about single-threaded GPU commands anymore, but it's just a lot of work [20:49:26 CET] <kepstin> well, give the audio its own (high priority?) thread, and time the video to the audio :/ [20:51:46 CET] <Dresk|Dev> Oh it's much worse, that video is playing ever so slightly slower in my engine apparently [20:51:57 CET] <Dresk|Dev> I don't know whose timestamp to trust [20:53:28 CET] <Dresk|Dev> Good lord I hate synchronization [20:53:48 CET] <kepstin> you getting the audio sample rate correct? playing back a 48kHz file at 44.1kHz will be "slightly slower" :/ [20:54:12 CET] <Dresk|Dev> I'll double check, I wrote my own mixer so it should cover that [20:54:25 CET] <Dresk|Dev> ffmpeg mixes but outputs to my mixer [20:55:19 CET] <Dresk|Dev> kepstin: What do I do when a video has no audio? Sync to timestamps? I used to sync purely to audio but silent videos didn't work, I couldn't made a framerate hack but it didn't seem right [20:56:36 CET] <kepstin> Dresk|Dev: couple options - if you have an audio mixer running anyways, you can still sync based on sound card timestamps, so it plays at same speed as other videos, otherwise fallback to timing based on cpu clock when there's no sound. [20:59:47 CET] <kepstin> for example, mpv defaults to timing the video frames to audio, but falls back to system/cpu clock if there's no audio [21:00:36 CET] <kepstin> but it has crazy alternate modes that do stuff like time frames to system clock, then resample audio so it plays at the same rate... [21:01:24 CET] <Dresk|Dev> I'm not qualified for this, heh [21:02:53 CET] <Dresk|Dev> I need Vulkan so I'm thread free and OpenCL so I don't have to YUV / RGB conversion on the GPU [21:03:04 CET] <Dresk|Dev> Well, so it's faster [21:03:15 CET] <Dresk|Dev> Doing it in software can be faster [21:09:37 CET] <BtbN> There is portable OpenCL Vulkan Interop? [21:09:51 CET] <BtbN> And why do you need OpenCL for YUV to RGB conversion? [21:10:40 CET] <Dresk|DevBox> I'm all over the place, I want hardware decoding without an overlay, obviously, since I need my videos as textures [21:11:18 CET] <BtbN> best way for that is probably cuvid right now, but that's not exactly portable [21:12:11 CET] <kepstin> you can do yuv/rgb decently in plain opengl, don't need opencv [21:12:24 CET] <kepstin> (see e.g. mpv's opengl video output driver) [21:13:48 CET] <kepstin> if you have planar video and are ok with simple linear scaling, it's practically trivial in a pixel shader :/ [22:54:35 CET] <IntruderSRB> hey guys - anyone of you aware of the restriction [22:54:37 CET] <IntruderSRB> in regards to DRM protection of interlaced videos? [22:56:10 CET] <DHE> anything that encrypts the video doesn't care about the difference between progressive and interlaced [22:59:15 CET] <IntruderSRB> should be like that but I receive weird error from apple 'mediastreamvalidator' when using interlaced [22:59:35 CET] <IntruderSRB> saying it should be progressive [23:00:12 CET] <IntruderSRB> so I was just checking [23:24:41 CET] <st-gourichon-fid> Hello. I need to stream a video to RTP with payload 34, H263-1998 encapsulated with RFC2190 packets. [23:25:12 CET] <st-gourichon-fid> Inspired by https://trac.ffmpeg.org/wiki/StreamingGuide#StreamingasimpleRTPaudiostreamf… and https://superuser.com/questions/1125344/streaming-in-ffmpeg-using-rtp I try a standard streaming op. [23:25:25 CET] <st-gourichon-fid> This works: ffmpeg -re -i a.mp4 -vcodec h264 -an -f rtp rtp://127.0.0.1:1234 [23:26:29 CET] <st-gourichon-fid> ... and I've found an error in my other command. Let me check again. [23:29:15 CET] <st-gourichon-fid> This streams with ERP payload 96: ffmpeg -re -i a.mp4 -vf scale=352x288 -vcodec h263 -an -f rtp rtp://127.0.0.1:1234 [23:31:00 CET] <st-gourichon-fid> Payload 96 uses RFC2429/4629 encapsulation. I need to stream with payloas 34 which implied RFC2190 encapsulation. [23:38:52 CET] <st-gourichon-fid> got it working: ffmpeg -re -i a.mp4 -vf scale=352x288 -vcodec h263 -an -payload_type 34 -f rtp rtp://127.0.0.1:60263 [23:39:05 CET] <st-gourichon-fid> Thanks for the rubberducking. ;-) [23:41:36 CET] <st-gourichon-fid> Ah but, no [23:41:43 CET] <st-gourichon-fid> [rtp @ 0x7f9488009240] Guessing on RTP content - if not received properly you need an SDP file describing it [23:41:43 CET] <st-gourichon-fid> [rtp @ 0x7f9488009240] Interpreting H263 RTP data as RFC 2429/4629 even though signalled with a static payload type. [23:44:08 CET] <st-gourichon-fid> this is better ffmpeg -re -i a.mp4 -vf scale=352x288 -vcodec h263 -an -rtpflags rfc2190 -payload_type 34 -f rtp rtp://127.0.0.1:60263 [23:50:26 CET] <st-gourichon-fid> Facing [rtp @ 0x31175a0] Unable to split H.263 packet, use -mb_info 1452 or -ps 1.bits/s speed=0.944x [23:50:43 CET] <st-gourichon-fid> I follow advice: ffmpeg -re -i b.mp4 -vf scale=352x288 -vcodec h263 -an -payload_type 34 -rtpflags rfc2190 -mb_info 1452 -f rtp rtp://127.0.0.1:60263 [23:51:10 CET] <st-gourichon-fid> One thing remains: client complains [h263 @ 0x7feb440008c0] warning: first frame is no keyframe f=0/0 [23:51:19 CET] <st-gourichon-fid> and indeed, the display starts garbled. [23:51:34 CET] <st-gourichon-fid> Client is ffplay rtp://127.0.0.1:60263 [00:00:00 CET] --- Tue Mar 21 2017

1 0

ffmpeg-devel.log.20170319
by burek 20 Mar '17

20 Mar '17

[00:04:43 CET] <michaelni> commits like b53d8c3ccfeff77874f5ca7c68136b6d87a0a69c document fields that are currently not parsed/used [00:08:20 CET] <michaelni> for alternative code implementations, i would suggest to use something that can be grep-ed i the commit message wen its removed so it can be easily found again [00:10:15 CET] <michaelni> no more comments from me, i didnt look at all in depth, some of these are things i didnt touch since a long time [00:19:36 CET] <ubitux> michaelni: ok, thanks. i'll merge the set tomorrow taking into account what you just said [03:06:51 CET] <wm4> who did the work to relicense libswscale to lgpl? [06:48:29 CET] <cone-362> ffmpeg 03Muhammad Faiz 07master:de1308429ae6: swresample/x86/resample: extend resample_double to support avx and fma3 [13:47:04 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:e4d5b5519310: rangecoder: Kill non-compiling disabled cruft [13:47:04 CET] <cone-890> ffmpeg 03Clément BSsch 07master:3f049646717f: Merge commit 'e4d5b55193109d08be47c42d320334546c006b51' [13:54:23 CET] <ubitux> 23:59 <michaelni> the code removed from aa37d2bf4505afc106e2a23c44afc722bb204a8e looks cleaner than the remaining code // are you refering to the gray chunk or SWS_X one? [13:58:18 CET] <michaelni> gray chunk [14:02:11 CET] <ubitux> ok [14:02:15 CET] <ubitux> speaking of this [14:02:23 CET] <ubitux> we have the same case here about isPacked [14:02:34 CET] <ubitux> (same file) [14:04:29 CET] <michaelni> i think generic code to detect classes/proerties is better than litteral lists that need to be updated unless unexpectedly thats faster [14:05:02 CET] <michaelni> quite possibly the generic code gives the wrong result on some corner case though, i dont know/remember [14:05:07 CET] <ubitux> i agree [14:07:05 CET] <ubitux> i may try something. [14:56:00 CET] <ubitux> michaelni: should we consider monob and monow gray? [15:01:10 CET] <ubitux> michaelni: anyway, patch on the ml [15:09:21 CET] <ubitux> btw, isPacked is missing uyyvyy411 [15:30:23 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:d5fda00efa75: mpeg4videoenc: Kill non-compiling disabled cruft [15:30:24 CET] <cone-890> ffmpeg 03Clément BSsch 07master:efcba5a06acf: Merge commit 'd5fda00efa756387cffb4d7294691cd54cfe86cf' [15:40:12 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:aa37d2bf4505: swscale: Kill non-compiling disabled cruft [15:40:13 CET] <cone-890> ffmpeg 03Clément BSsch 07master:8e950c9b4235: Merge commit 'aa37d2bf4505afc106e2a23c44afc722bb204a8e' [15:43:27 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:a972fc1c0ab6: wma: Kill non-compiling disabled cruft [15:43:28 CET] <cone-890> ffmpeg 03Clément BSsch 07master:18cdef9ab7d7: Merge commit 'a972fc1c0ab6e7f169f9145d6da46e8cedbc291c' [15:49:05 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:562bec0e6907: pnm_parser: Drop broken disabled cruft [15:49:06 CET] <cone-890> ffmpeg 03Clément BSsch 07master:8a403b00d1bd: Merge commit '562bec0e690760fb93deb2843a7237713103a191' [15:49:30 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:dab2034b8679: roqvideoenc: Drop broken disabled cruft [15:49:31 CET] <cone-890> ffmpeg 03Clément BSsch 07master:4ded6f9b3127: Merge commit 'dab2034b8679aaacd8aef832cdeb71d0ee8a3358' [15:50:07 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:d9442d13033a: rm: Drop broken disabled cruft [15:50:08 CET] <cone-890> ffmpeg 03Clément BSsch 07master:3eed90b1ed6c: Merge commit 'd9442d13033a24b14ebae149dcdb42709430e2d9' [15:52:02 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:263efc095e6c: jfdct: Kill broken cruft [15:52:03 CET] <cone-890> ffmpeg 03Clément BSsch 07master:92cd2c04b1c2: Merge commit '263efc095e6c7ec2902119118b084cea29ea8916' [15:55:30 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:42c4c2d2a6dc: aac: Drop broken cruft [15:55:31 CET] <cone-890> ffmpeg 03Clément BSsch 07master:842e7853c73d: Merge commit '42c4c2d2a6dc48adb0e901ef5617acfba0a3a18e' [15:57:55 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:b96f0ab3d29c: h264: Kill broken disabled cruft [15:57:56 CET] <cone-890> ffmpeg 03Clément BSsch 07master:b6e88bf323bb: Merge commit 'b96f0ab3d29cdd9ea9ddabfb2052f72bf8615661' [15:59:37 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:17cb56b35672: ffv1: Remove broken disabled cruft [15:59:38 CET] <cone-890> ffmpeg 03Clément BSsch 07master:2f42aef3e40c: Merge commit '17cb56b35672a2cd6ad7abe926e6cc772b8f4710' [16:00:02 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:a4b1b5aa281c: wc3movie: Drop unused cruft [16:00:03 CET] <cone-890> ffmpeg 03Clément BSsch 07master:83706367e2b5: Merge commit 'a4b1b5aa281cacde8351d9947b54ccf82ff10cd0' [16:00:46 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:34c22a9ca656: faan(i)dct: Kill some disabled code [16:00:47 CET] <cone-890> ffmpeg 03Clément BSsch 07master:7a6514861ecf: Merge commit '34c22a9ca656603428b2c3490d1339c5a5966961' [16:04:38 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:b53d8c3ccfef: mjpegdec: Drop disabled code [16:04:39 CET] <cone-890> ffmpeg 03Clément BSsch 07master:1a48a51bfcd0: Merge commit 'b53d8c3ccfeff77874f5ca7c68136b6d87a0a69c' [16:05:00 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:be3363f664d7: nsv: Drop disabled cruft [16:05:01 CET] <cone-890> ffmpeg 03Clément BSsch 07master:56d63208d824: Merge commit 'be3363f664d7314d55b42860bd4077154752d769' [16:06:41 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:be1db21ba88f: mathops: Drop disabled alternative mid_pred() implementation [16:06:42 CET] <cone-890> ffmpeg 03Clément BSsch 07master:87cd8dc0b0b2: Merge commit 'be1db21ba88fe86036fea9f8d2c1a5f47c2a0a7e' [16:07:08 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:f2f145f3032b: msmpeg4: Drop disabled debug cruft [16:07:09 CET] <cone-890> ffmpeg 03Clément BSsch 07master:95a29b1a8205: Merge commit 'f2f145f3032bc8808708a4bd694fbce5f1b8b63c' [16:07:54 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:0e285c2f9087: mpegvideo: Kill some disabled code [16:07:55 CET] <cone-890> ffmpeg 03Clément BSsch 07master:adef752f1b18: Merge commit '0e285c2f908789e96e29bfd969ad5eaaa0eece65' [16:09:05 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:93fed46a92ba: timefilter: test: Drop some disabled debug cruft [16:09:06 CET] <cone-890> ffmpeg 03Clément BSsch 07master:b2c5f5054b5c: Merge commit '93fed46a92bab8be176d3e67be4354189a8dbe7f' [16:09:41 CET] <durandal_1707> remove merge cruft, please [16:11:01 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:7effebde7897: dvbsubdec: Remove disabled, near-duplicate debug code [16:11:02 CET] <cone-890> ffmpeg 03Clément BSsch 07master:ff66ba6feb3e: Merge commit '7effebde78977fafce935776153ea2f7c0981fa3' [16:11:33 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:e2b9993558b6: simple_idct: x86: Drop disabled IDCT implementation [16:11:34 CET] <cone-890> ffmpeg 03Clément BSsch 07master:8695ce73ca89: Merge commit 'e2b9993558b6adee42dcc6eb385a14943aaca974' [16:12:26 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:014852e932da: simple_idct: arm: Drop disabled code variant [16:12:27 CET] <cone-890> ffmpeg 03Clément BSsch 07master:a754fae4a7e1: Merge commit '014852e932dab6e9cf2a53e7a17ce8321f3e922c' [16:13:24 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:83b92a855e8e: golomb: Drop disabled cruft [16:13:25 CET] <cone-890> ffmpeg 03Clément BSsch 07master:01e188762fc4: Merge commit '83b92a855e8e08bdec484e13ee5a7c8996224772' [16:17:56 CET] <ubitux> michaelni: ping on f5d46d332258dcd8ca623019ece1d5e5bb74142b; Anton seems to compare rect x+w against bw and rect y+h against bh while your fix seems to compare against respectively against w-i and h-j [16:18:20 CET] <ubitux> do you think using bw and bh is less correct or not? [16:19:31 CET] <ubitux> (your fix is in 6ba02602aa7fc7d38db582e75b8b093fb3c1608d) [16:21:56 CET] <jamrial> that feeling when a git pull shows lines and lines full of red minus signs [16:47:58 CET] <durandal_1707> ubitux: how many merges are left? [16:48:21 CET] <ubitux> 930+ [16:48:26 CET] <michaelni> ubitux, maybe both do the same, maybe one breaks some valid files, maybe something else, i dont know [16:48:36 CET] <ubitux> (920+ actually) [16:49:04 CET] <ubitux> michaelni: do you prefer that i keep your condition? [16:50:36 CET] <michaelni> i have no preferrance in this case, backports should stay the simpler though as thats simpler to do [16:51:19 CET] <ubitux> well, i'd usually merge libav version, but this is a security issue you fixed, so i don't want to do a mistake here [16:51:39 CET] <ubitux> but OTOH i don't want our code to be more security unsecure than Libav [16:51:50 CET] <ubitux> -security [17:30:47 CET] <cone-890> ffmpeg 03Anton Khirnov 07master:f5d46d332258: vmnc: check that subrectangles fit into their containing rectangles [17:30:48 CET] <cone-890> ffmpeg 03Clément BSsch 07master:1080b7162f2c: Merge commit 'f5d46d332258dcd8ca623019ece1d5e5bb74142b' [17:31:56 CET] <ubitux> is 796dca027be09334d7bbf4f2ac1200e06bb054cb fixed differently in FFmpeg? [17:35:09 CET] <ubitux> maybe e11983bda073f8c63f60509ee753da9fba20ed10? [17:38:44 CET] <cone-890> ffmpeg 03Anton Khirnov 07master:796dca027be0: alac: do not return success if nothing was decoded [17:38:45 CET] <cone-890> ffmpeg 03Clément BSsch 07master:f09aa73b3050: Merge commit '796dca027be09334d7bbf4f2ac1200e06bb054cb' [17:40:25 CET] <cone-890> ffmpeg 03Anton Khirnov 07master:bba9d8bdfb20: qpeg: fix an off by 1 error in the MV check [17:40:26 CET] <cone-890> ffmpeg 03Clément BSsch 07master:a0220d949f2c: Merge commit 'bba9d8bdfb208b0ec2ccf182530347151ee3528b' [17:50:22 CET] <cone-890> ffmpeg 03Anton Khirnov 07master:409d1cd2c955: cook: use the bytestream2 API for reading extradata [17:50:23 CET] <cone-890> ffmpeg 03Clément BSsch 07master:d707e667c560: Merge commit '409d1cd2c955485798f8b0b0147c2b899b9144ec' [17:52:25 CET] <cone-890> ffmpeg 03Anton Khirnov 07master:15ee419b7aba: pcx: properly pad the scanline [17:52:26 CET] <cone-890> ffmpeg 03Clément BSsch 07master:2da66630dce7: Merge commit '15ee419b7abaf17f8c662c145fe93d3dbf43282b' [17:56:15 CET] <cone-890> ffmpeg 03Anton Khirnov 07master:221402c1c88b: pcx: check that the packet is large enough before reading the header [17:56:16 CET] <cone-890> ffmpeg 03Clément BSsch 07master:ca619cdf54ca: Merge commit '221402c1c88b9d12130c6f5834029b535ee0e0c5' [17:58:33 CET] <ubitux> durandal_1707: opinion on 09b23786b3? [18:00:30 CET] <ubitux> i should probably noop given 8cd1c0febe88b757e915e9af15559575c21ca728, but you may want to compare [18:04:11 CET] <durandal_1707> ubitux: what its about? [18:04:36 CET] <durandal_1707> i cant find that commit hash [18:04:40 CET] <ubitux> https://git.libav.org/?p=libav.git;a=commitdiff;h=09b23786b3 [18:05:10 CET] <ubitux> our pcx code differs quite a bit, even after that commit [18:05:31 CET] <ubitux> so i'm tempted to noop it, but you may find issues in our version or improvement to merge [18:16:55 CET] <durandal_1707> ubitux: nothing interested, our code is nicer, noop it [18:17:09 CET] <ubitux> alright, thanks :) [18:17:45 CET] <cone-890> ffmpeg 03Anton Khirnov 07master:09b23786b398: pcx: use the bytestream2 API for reading from input [18:17:46 CET] <cone-890> ffmpeg 03Clément BSsch 07master:81bc1782b6d0: Merge commit '09b23786b3986502ee88d4907356979127169bdd' [18:18:17 CET] <cone-890> ffmpeg 03Anton Khirnov 07master:33f10546ec01: vc1: check that slices have a positive height [18:18:18 CET] <cone-890> ffmpeg 03Clément BSsch 07master:d2f68be1e83d: Merge commit '33f10546ec012ad4e1054b57317885cded7e953e' [18:20:45 CET] <cone-890> ffmpeg 03Anton Khirnov 07master:6755eb5b2123: mss12: validate display dimensions [18:20:46 CET] <cone-890> ffmpeg 03Clément BSsch 07master:a45a623d4609: Merge commit '6755eb5b212384e0599f7f2c5de42df49fff57de' [18:22:25 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:46e3936fb04d: configure: Set __MSVCRT_VERSION__to 0x0700 for MinGW [18:22:26 CET] <cone-890> ffmpeg 03Clément BSsch 07master:206a9fb29cbc: Merge commit '46e3936fb04d06550151e667357065e3f646da1a' [18:25:12 CET] <cone-890> ffmpeg 03Luca Barbato 07master:24130234cd9d: rtpdec_mpeg4: validate fmtp fields [18:25:13 CET] <cone-890> ffmpeg 03Clément BSsch 07master:f4a39ceea0d2: Merge commit '24130234cd9dd733116d17b724ea4c8e12ce097a' [18:25:59 CET] <ubitux> hey [18:26:11 CET] <ubitux> what's the policy wrt new codec id from libav? [18:26:42 CET] <ubitux> adding it in the middle relying on our current offseting is fine, right? [18:27:06 CET] <ubitux> ah, my bad, they actually have that offsetting as well, forget this [18:27:32 CET] <Compn> we have to add the hex numbers or so ? [18:27:41 CET] <Compn> to make sure the codec id dont conflict [18:29:27 CET] <jamrial> ubitux: we dropped ABI compatibility, so just add it at the end of the corresponding part (video, audio, subtitle, etc) [18:29:41 CET] <nevcairiel> didnt we drop the offseting [18:30:17 CET] <nevcairiel> yeah we did [18:30:25 CET] <jamrial> we probably should on the next bump [18:30:25 CET] <nevcairiel> so just at the end of the section [18:30:41 CET] <nevcairiel> we only have the media type offsets like we always had [18:30:50 CET] <nevcairiel> the fourcc codec ids and the libav offset are gone already [18:31:26 CET] <jamrial> no, just the fourcc. some of the libav offsets are still there [18:31:32 CET] <jamrial> look for example the id for PCM_S64LE [18:32:34 CET] <nevcairiel> oh right it looked like a section offset [18:33:09 CET] <cone-890> ffmpeg 03Luca Barbato 07master:d42809f9835a: av1: Add codec_id and basic demuxing support [18:33:10 CET] <cone-890> ffmpeg 03Clément BSsch 07master:ed223eeab34c: Merge commit 'd42809f9835a4e9e5c7c63210abb09ad0ef19cfb' [18:35:58 CET] <cone-890> ffmpeg 03Luca Barbato 07master:963b3ab11f98: doc: Document FATE option HWACCEL [18:35:59 CET] <cone-890> ffmpeg 03Clément BSsch 07master:33dc6fcc4c77: Merge commit '963b3ab11f98fcc4a311f0dc7b268890c5675da2' [18:43:29 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:6892df9294d9: vp3: Change type of stride parameters to ptrdiff_t [18:43:30 CET] <cone-890> ffmpeg 03Clément BSsch 07master:6a42a54b9de4: Merge commit '6892df9294d93322d43255ada299507465bc93c8' [18:43:59 CET] <ubitux> i'll stop the merge for an hour or two, feel free to take over [18:48:42 CET] <jamrial> ubitux: i'll do a few. these ptrdiff_t sound like they could be tedious if they don't apply cleanly [18:59:27 CET] <ubitux> the first one applied cleanly, we had no extra function nor asm implementation afaict [19:00:01 CET] <ubitux> ETA: 906 commits [19:00:51 CET] <jamrial> the next one also applied cleanly [19:00:59 CET] <jamrial> i'm compiling currently [19:06:22 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:d9d26a3674f3: vp56: Change type of stride parameters to ptrdiff_t [19:06:23 CET] <cone-890> ffmpeg 03James Almer 07master:4004d33fcbbb: Merge commit 'd9d26a3674f31f482f54e936fcb382160830877a' [19:07:56 CET] <jkqxz> Anyone want to comment further on libturing? I'm inclined to apply the most recent patch now that they've fixed the library to work with a normal install. (Though still with the crazy boost libraries, they will need to clean that up to get into any distributions.) [19:09:12 CET] <ubitux> what's the most recent patch? [19:10:34 CET] <ubitux> the should probably require a minimal version of libturing [19:10:45 CET] <jkqxz> <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-February/207105.html> [19:11:38 CET] <jkqxz> I don't think they've heard of version numbering, so that may be tricky. [19:11:50 CET] <ubitux> lol [19:12:14 CET] <ubitux> that add_option() is crazy; it should use bprint api [19:12:51 CET] <ubitux> which call also simplify a lot the caller [19:13:23 CET] <ubitux> encoder_options should be memset to 0 instead of setting every single field and risking to forget one [19:13:52 CET] <ubitux> illegal_option could use av_match_name [19:14:50 CET] <ubitux> final error log should display the error code [19:15:14 CET] <ubitux> mmh wait, that's not an error code for the lib, so the log should go away [19:15:37 CET] <jkqxz> Please reply to it if you care. [19:15:46 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:87c6c78604e4: vp8: Change type of stride parameters to ptrdiff_t [19:15:47 CET] <cone-890> ffmpeg 03James Almer 07master:e5623aafd8f6: Merge commit '87c6c78604e4dd16f1f45862b27ca006da010527' [19:17:30 CET] <ubitux> will do, but i'll have to wait a few minutes for mutt to switch to the zomg big dir :p [19:18:22 CET] <ubitux> they really need some API lessons though [19:19:22 CET] <jkqxz> I think the whole point of the crazy string stuff is to avoid having to define any real API. [19:19:47 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:802727b538b4: vp8: Update some assembly comments left unchanged in bd66f073fe7286bd3c [19:19:48 CET] <cone-890> ffmpeg 03James Almer 07master:4e4dfcac58f3: Merge commit '802727b538b484e3f9d1345bfcc4ab24cfea8898' [19:25:41 CET] <ubitux> jkqxz: i'll make a review soon, sorry for delaying [19:25:55 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:f81be06cf614: cavs: Change type of stride parameters to ptrdiff_t [19:25:56 CET] <cone-890> ffmpeg 03James Almer 07master:aec42ebc27c4: Merge commit 'f81be06cf614919d71ded29b8f595bef40123ad8' [19:29:16 CET] <jkqxz> I don't mind; thank you for doing anything. (I was inclined to just give in to attrition.) [19:34:16 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:3fd22538bc0e: prores: Change type of stride parameters to ptrdiff_t [19:34:17 CET] <cone-890> ffmpeg 03James Almer 07master:663640d74527: Merge commit '3fd22538bc0e0de84b31335266b4b1577d3d609e' [21:20:01 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:721d57e608dc: vp56: Separate VP5 and VP6 dsp initialization [21:20:02 CET] <cone-890> ffmpeg 03James Almer 07master:6966a5e4d79c: Merge commit '721d57e608dc4fd6c86f27c5ae76ef559d646220' [21:20:14 CET] <jamrial> ^fuck that commit [21:20:43 CET] <ubitux> :D [21:21:33 CET] <jamrial> alpha channel was using a different context [21:26:07 CET] <cone-890> ffmpeg 03Diego Biurrun 07master:4ab496261b12: libvpx: Cast a pointer to const to squelch a warning [21:26:08 CET] <cone-890> ffmpeg 03James Almer 07master:54b19aaaeb3c: Merge commit '4ab496261b12e20ef293b7adca4fcaef1a67c538' [21:26:25 CET] <jamrial> ubitux: ok, done [21:29:14 CET] <ubitux> jamrial: i'll go back to it tomorrow :) [21:29:17 CET] <ubitux> thanks [21:29:26 CET] <jamrial> no prob [21:30:23 CET] <ubitux> ETA: 899 commits [22:02:03 CET] <cone-890> ffmpeg 03Martin Storsjö 07master:b7a565fe71d1: arm: vp9itxfm: Template the quarter/half idct32 function [22:02:04 CET] <cone-890> ffmpeg 03Martin Storsjö 07master:70317b25aa35: arm/aarch64: vp9itxfm: Skip loading the min_eob pointer when it won't be used [22:02:05 CET] <cone-890> ffmpeg 03Martin Storsjö 07master:21c89f3a26bb: arm/aarch64: vp9: Fix vertical alignment [22:02:06 CET] <cone-890> ffmpeg 03Martin Storsjö 07master:b46d37e93ab1: arm: vp9itxfm16: Use the right lane size [22:02:07 CET] <cone-890> ffmpeg 03Martin Storsjö 07master:c1619318e540: arm: vp9itxfm16: Fix vertical alignment [22:02:08 CET] <cone-890> ffmpeg 03Martin Storsjö 07master:32e273c111d8: arm: vp9itxfm16: Avoid reloading the idct32 coefficients [22:02:09 CET] <cone-890> ffmpeg 03Martin Storsjö 07master:25ced1eb1c6c: aarch64: vp9itxfm16: Fix a typo in a comment [22:02:10 CET] <cone-890> ffmpeg 03Martin Storsjö 07master:d613251622d6: aarch64: vp9itxfm16: Avoid .irp when it doesn't save any lines [22:02:11 CET] <cone-890> ffmpeg 03Martin Storsjö 07master:b76533f105cc: aarch64: vp9itxfm16: Restructure the idct32 store macros [22:02:12 CET] <cone-890> ffmpeg 03Martin Storsjö 07master:0ea603203d1a: arm: vp9itxfm16: Make the larger core transforms standalone functions [22:02:13 CET] <cone-890> ffmpeg 03Martin Storsjö 07master:0f2705e66b1f: aarch64: vp9itxfm16: Make the larger core transforms standalone functions [22:02:14 CET] <cone-890> ffmpeg 03Martin Storsjö 07master:d564c9018f8a: aarch64: vp9itxfm16: Move the load_add_store macro out from the itxfm16 pass2 function [22:02:15 CET] <cone-890> ffmpeg 03Martin Storsjö 07master:eabc5abf949b: arm: vp9itxfm16: Do a simpler half/quarter idct16/idct32 when possible [22:02:16 CET] <cone-890> ffmpeg 03Martin Storsjö 07master:61b8a9ea2930: aarch64: vp9itxfm16: Do a simpler half/quarter idct16/idct32 when possible [22:26:05 CET] <ubitux> michaelni: comment on patch 2? [22:31:15 CET] <ubitux> michaelni: btw, libavutil/pixdesc.c: if (!strncmp(d->name, "bayer_", 6)) [22:31:17 CET] <ubitux> :p [22:35:28 CET] <nevcairiel> the bayer pixfmts are a huge hack =p [22:37:37 CET] <ubitux> is it? [22:43:06 CET] <jamrial> ubitux: return !!(desc->flags & AV_PIX_FMT_FLAG_BAYER) would be "more correct(tm)" [22:46:12 CET] <michaelni> ubitux, about #2, no comment from me [22:46:40 CET] <michaelni> i have no good comment :) [23:32:24 CET] <ubitux> jamrial: sure, fixed locally [23:32:32 CET] <ubitux> i'll apply the patchset tmr [23:43:17 CET] <ubitux> michaelni: can i drop is{RGB,BGR}inBytes? they're unused [00:00:00 CET] --- Mon Mar 20 2017

1 0

ffmpeg.log.20170319
by burek 20 Mar '17

20 Mar '17

[00:00:02 CET] <thebombzen> yea they're both fine [00:00:05 CET] <JEEB> since the difference between samples is a duration of the sample [00:00:13 CET] <thebombzen> but it's not "monotonic" [00:00:21 CET] <thebombzen> I mean it turns out the timestamps are monotonic [00:00:37 CET] <JEEB> yes, that was incorrect [00:01:02 CET] <JEEB> what I mean was that the difference between two samples' timestamps would always be static (aka the duration of all samples is the same) [00:01:50 CET] <nyuszika7h> there must be something at the beginning of the file, I only see it in a sample if I cut it from there [00:01:51 CET] <nyuszika7h> https://ptpb.pw/u_FM [00:02:15 CET] <nyuszika7h> (this one didn't have any options to try to force CFR) [00:03:15 CET] <nyuszika7h> also if I add "-vsync 1", the only thing that achieves is that it also displays "Original frame rate: 25.000 fps" in addition to "Frame rate mode: Variable" [00:04:08 CET] <JEEB> oh, matroska. one of the three or so containers where you'll have fun with timestamps (although not necessarily with 25Hz, although I don't remember). MPEG-TS, FLV and Matroska have funky time bases, which often makes even CFR content VFR in them, and you can't do jack about it :P [00:04:19 CET] <JEEB> that said, you should now be able to calculate the duration of each sample [00:04:38 CET] <JEEB> do note that those aren't listed in presentation order there [00:04:41 CET] <nyuszika7h> the original MPEG-2 from the DVD remuxed to MKV is reported as 25 fps CFR [00:04:43 CET] <JEEB> because of the B-pictures [00:05:51 CET] <Threads> someone else having problems with cfr i see [00:06:28 CET] <Threads> i found out if you encode it into a avi container and and mux with mkvmerge its ok but if you try todo it directly into mkv its vfr [00:07:34 CET] <JEEB> avi input with mkvmerge engages its VFW mode [00:07:37 CET] <JEEB> that is not something you want [00:07:59 CET] <JEEB> and your "VFR" issues probably stem from something else although I have no idea if they're issues at all at this point [00:08:41 CET] <JEEB> unfortunately, it's 1AM here and I really don't have the power of taking newbies up until the "ooh! so *that's* why X is Y!" moment [00:08:44 CET] <JEEB> g'night [00:10:08 CET] <Threads> JEEB its ok i prefer going the long way round on things as thats how you learn, also gnight to you [00:11:53 CET] <nyuszika7h> hmm yes I can see many timecodes increasing by +80 or +120 instead of +40 [00:12:16 CET] <JEEB> nyuszika7h: that's because those timestamps are in coded order, not presentation order [00:12:23 CET] <nyuszika7h> I sorted them [00:12:40 CET] <JEEB> then that's weird [00:13:02 CET] <JEEB> anyways, sleep for me [00:14:50 CET] <nyuszika7h> https://t.6697.eu/g/file_23639.png [00:15:52 CET] <nyuszika7h> could that mean dropping frames maybe? I haven't noticed any glitches in the output file though [00:16:29 CET] <nyuszika7h> the duration is the same though [01:14:17 CET] <bencc1> what happens to hls stream when there are no packets? [01:14:42 CET] <bencc1> before the stream starts or when it is paused [01:15:07 CET] <bencc1> do hls players retry to load the stream every few seconds? [01:28:50 CET] <hiihiii> hey back again [01:29:27 CET] <hiihiii> I'm about to encode a loop of some scrolling text on a blue background [01:31:09 CET] <hiihiii> https://www.filepicker.io/api/file/Unjb5zolR0Wm6RcVQQJo?signature=42321892d… [01:31:49 CET] <hiihiii> my input is raw. it amounts to 5GB [01:32:56 CET] <hiihiii> -i input.avi -c:v libx264rgb -preset veryslow -crf 20 output.mp4 [01:33:28 CET] <hiihiii> only one problem left for me. what type of -tune to use [01:34:16 CET] <hiihiii> I've been using -tune grain for almost everything but I don't know how to differentiate between the different types [01:35:20 CET] <hiihiii> for my current input, film or grain? [01:44:16 CET] <c_14> For that I'd use stillimage [01:47:07 CET] <hiihiii> huh really [01:47:34 CET] <c_14> Well it's not film and you're not trying to preserve grain so those two are off. Also it is mostly a still image [01:47:36 CET] <hiihiii> would that yield better results [01:50:38 CET] <c_14> it might [02:12:39 CET] <hiihiii> my clip is 60fps and the text kinda scrolls fast, so how is that a still image? yes there are a lot of areas/patches of blue but still [02:13:39 CET] <hiihiii> anyway, I'd be grateful if someone could point me to a detailed post describing tune presets [02:42:11 CET] <obamoose> heya [02:42:49 CET] <obamoose> i'm having an issue with looping [02:42:53 CET] <obamoose> I used while : do my ffmpeg config done done [02:43:14 CET] <obamoose> and now it restarts the stream [02:43:16 CET] <obamoose> after every file [02:43:43 CET] <obamoose> http://pastebin.com/yaDHd52k [03:45:53 CET] <obamoose> anyone? [05:05:17 CET] <peels> anyone ever compile ffmpeg from source... on a raspberry pi zero?! [05:05:56 CET] <CoJaBo> I'm not a masochist, so.. [05:09:32 CET] <peels> lol [05:09:41 CET] <peels> guilty! [07:42:24 CET] <thebombzen> c_14: I'm not entirely sure when to use -tune stillimage and -tune animation [07:42:33 CET] <thebombzen> given certain low-motion cell-shaded things [07:42:48 CET] <thebombzen> how do I know which one is better (other than "just try both") [08:14:01 CET] <Spring> thebombzen, depends how low motion it is. I use still image for detailed scenes with a fixed camera and only subtle to low movement and it works very well as it reduces the deblocking so more detail is preserved. [08:14:48 CET] <Spring> on the other hand with more regular movement in the scene and camera the deblocking becomes apparent [08:15:48 CET] <Spring> I believe the animation tuning does the opposite wrt the deblocking [08:19:10 CET] <thebombzen> speaking of which, how do we check what the various presets and tunes turn on [08:28:09 CET] <Spring> thebombzen, this page lists the details from the ffmpeg help (though that command doesn't seem to work on my system, might have changed). https://superuser.com/questions/564402/explanation-of-x264-tune [08:31:04 CET] <thebombzen> yea, x264 --fullhelp did say it. but unfortunately I don't know how to interpret the deblock or aq setting. I'll have to read more about htat [10:44:54 CET] <Tom_B> Hi all, I'm using ffmpeg to take a HTTP stream and convert it into a hls stream but it seems to be re-encoding the video and audio: Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264)) is there any way for it just to pass the video through without re-encoding it? [11:00:07 CET] <furq> Tom_B: -c copy [11:10:06 CET] <Tom_B> @furq, thanks :) [11:52:15 CET] <jaggadak> hello [11:53:00 CET] <jaggadak> why a little noise is there in between concatenating two videos ? [12:28:00 CET] Last message repeated 1 time(s). [13:54:00 CET] <thebombzen_> How does one check x264 settings in an encoded file? [13:54:22 CET] <thebombzen_> Afaik they're embeded as metadata but idk what they're called [13:55:07 CET] <BtbN> they don't neccesarily are [13:55:43 CET] <thebombzen_> Does avformat embed them by default? [13:55:47 CET] <furq> libx264 does [13:55:51 CET] <furq> you need to patch it to prevent it [13:56:32 CET] <thebombzen_> If so furq do you know how to use ffprobe or equiv to extract thrm [13:56:39 CET] <furq> i don't think ffprobe does it [13:56:40 CET] <JEEB> strings file |grep x264 [13:56:42 CET] <furq> mediainfo does it [13:56:47 CET] <furq> or yeah strings will get it out [13:56:51 CET] <thebombzen_> Mediainfo? [13:56:54 CET] <thebombzen_> lol strings [13:57:00 CET] <furq> or if you have some x264 nalu inspector, it's in the sei nalu [13:57:00 CET] <thebombzen_> I wasn't expecting that [13:57:09 CET] <JEEB> it's a string in the SEI NALU, so strings should get it :P [13:57:13 CET] <furq> ^ [13:57:46 CET] <thebombzen_> "sei nalu" welp gtg google that [13:58:07 CET] <furq> http://vpaste.net/EjdLe [13:59:31 CET] <thebombzen_> That's useful [14:00:07 CET] <thebombzen_> Out of curiosity [14:00:16 CET] <furq> also wrt what you asked last night [14:00:17 CET] <furq> https://en.wikibooks.org/wiki/MeGUI/x264_Settings#aq-mode [14:01:12 CET] <JEEB> except now we have mode=3 as well :P [14:01:18 CET] <JEEB> which is a tweaked 2 IIRC [14:01:24 CET] <furq> well if you have a more up-to-date page i will bookmark it [14:01:37 CET] <JEEB> not that I know [14:01:50 CET] <JEEB> but anyways, psychovisual stuff is such a "let's try it out" kind of thing [14:02:05 CET] <JEEB> since you can't necessarily mathematically note how it's better [14:02:19 CET] <furq> yeah i rarely touch anything other than preset and tune [14:04:02 CET] <JEEB> IIRC the reason why aq-mode 3 wasn't made the default was mostly due to "well, we've had 2 around for long enough and we don't want to do extensive testing again welp" [14:04:21 CET] <thebombzen> so AQ basically allows x264 to look at the video holistically [14:04:32 CET] <thebombzen> so it doesn't have to quantize each block blindly [14:04:38 CET] <JEEB> yes [14:04:42 CET] <furq> aq-mode defaults to 1 doesn't it [14:04:49 CET] <JEEB> depends on the preset I bet [14:04:56 CET] <JEEB> since 1 might be faster? [14:04:57 CET] <furq> apparently it's always 1 [14:05:01 CET] <JEEB> ok [14:05:04 CET] <furq> but this page might also be outdated [14:05:14 CET] <furq> 0 in ultrafast, 1 in everything else [14:05:41 CET] <JEEB> thebombzen: anyways the algorithms behind the AQ methods are various. heck, there used to be a haali AQ which mostly preferred blue to red etc [14:05:57 CET] <JEEB> and then there was an overcomplicated mess called OreAQ [14:06:17 CET] <JEEB> from a Japanese guy, which required you to make up a set of values for a specific clip with an AviUtl preview thing [14:06:20 CET] <JEEB> :D [14:06:42 CET] <furq> by which point you'd have already finished encoding it with veryslow [14:07:06 CET] <furq> but you lost out on a 1% space saving so the joke's on you [14:07:26 CET] <JEEB> then there was a MixAQ which was normal AQ vs Haali's AQ I think? [14:07:40 CET] <JEEB> and you set the strengths of those two against each other [14:07:58 CET] <JEEB> I still think a chinese dude is maintaining those patches [14:08:06 CET] <thebombzen> and aq strenth is just a weight on how much it cares about low-detail sections? [14:08:36 CET] <JEEB> yea [14:08:38 CET] <JEEB> more or less [14:09:32 CET] <thebombzen> wow looking at ultrafast [14:09:34 CET] <thebombzen> it's a piece of shit [14:09:40 CET] <furq> yeah [14:09:40 CET] <thebombzen> but ultra fast [14:10:24 CET] <furq> even superfast is a big step up [14:10:33 CET] <thebombzen> yea [14:10:52 CET] <thebombzen> it seems like ultrafast is only useful if you're on terrible hardware [14:11:01 CET] <thebombzen> or you're use -qp 0 [14:11:09 CET] <thebombzen> and don't care b/c you're going to transcode it later anyway [14:11:35 CET] <JEEB> ultrafast is for benchmarks and certain lossless use cases, yes [14:11:44 CET] <JEEB> similar to placebo in the first case [14:11:50 CET] <furq> if you're doing 1080p60 and playing league of dotawatch at the same time then i can see superfast being a drag on modest hardware [14:12:11 CET] <thebombzen> league isn't super cpu-intensive afaik [14:12:21 CET] <furq> well i should hope not because it's not a real game [14:12:25 CET] <furq> i just made it up [14:12:31 CET] <thebombzen> league of legends i mean [14:12:31 CET] <thebombzen> or dota [14:12:35 CET] <thebombzen> mobas in general [14:12:40 CET] <JEEB> he just mashed the three popular things [14:12:41 CET] <thebombzen> I was under the impression that games with physics simulation were the biggies [14:12:47 CET] <JEEB> league, dota, overwatch :P [14:12:54 CET] <thebombzen> oh I didn't even notice the overwatch [14:12:57 CET] <thebombzen> lol [14:12:59 CET] <JEEB> but in any case, SW encoding does eat CPU cycles [14:13:10 CET] <furq> i forgot that card game thing where you have to pay for better cards [14:13:16 CET] <furq> people fucking love paying to win [14:13:17 CET] <thebombzen> hearthstone? [14:13:20 CET] <furq> that's the one [14:13:36 CET] <thebombzen> Hearthstone is very uninteresting [14:13:45 CET] <furq> and you don't even get real cards that you can use to scare away any girls who might come near you [14:13:47 CET] <thebombzen> coming from the persepctive of a magic the gathering player [14:13:57 CET] <thebombzen> hearthstone is very little skill [14:14:01 CET] <thebombzen> and has too much RNG [14:14:13 CET] <thebombzen> and girls who'd be scared away by cards aren't girls I want to hang out with [14:14:15 CET] <furq> so it's basically mario kart then [14:14:18 CET] <thebombzen> so I'm cool with that [14:14:25 CET] <furq> i now see why all the terrible nerds love it [14:14:28 CET] <thebombzen> well mario cart does take some skill [14:14:32 CET] <thebombzen> I have no idea how much [14:14:35 CET] <thebombzen> but all I know is I suck ass at it [14:14:40 CET] <thebombzen> so it's gotta take some nonzero amount of skill [14:14:58 CET] <furq> have you tried playing it until someone takes all the drivers in front of you out with randomised weapons that target them exactly [14:15:06 CET] <thebombzen> no [14:15:10 CET] <thebombzen> because I don't own it [14:15:12 CET] <thebombzen> and usually I lose the race [14:15:13 CET] <furq> that seems like the winning strategy [14:15:22 CET] <thebombzen> and then the next person in line says "you lose, you're out" [14:15:24 CET] <thebombzen> and I don't get to play [14:15:37 CET] <thebombzen> there's a reason it's a bad party game [14:15:44 CET] <furq> is it because it's a bad game [14:15:53 CET] <thebombzen> but I was under the impression that the games that drag on your cpu the most have physics sims [14:16:01 CET] <thebombzen> like FPS games [14:16:03 CET] <furq> nice segue [14:16:09 CET] <thebombzen> segue? [14:16:10 CET] <furq> and probably [14:16:21 CET] <furq> http://chambers.co.uk/search/?query=segue&title=21st [14:16:41 CET] <thebombzen> I'd been trying to say that for a while [14:16:42 CET] <thebombzen> lol [14:17:14 CET] <thebombzen> I also think it's amusing that when you said "League of Dotawatch" you referenced three popular games all of which are mobastyle [14:17:24 CET] <furq> i haven't played a new fps in years [14:17:30 CET] <furq> i think the newest one i played was battlefield 3 [14:17:34 CET] <furq> and only because someone bought it for me [14:17:43 CET] <thebombzen> lol at least it wasn't call of duty [14:17:52 CET] <furq> i have never played a call of duty game [14:17:55 CET] <thebombzen> Call of duty is a pretty terrible game [14:18:02 CET] <furq> not even cod4 which apparently has quake 3 physics [14:18:18 CET] <thebombzen> they're all bad [14:18:23 CET] <thebombzen> cod4 just was less bad than the others [14:18:28 CET] <thebombzen> the maps were awful though [14:18:45 CET] <furq> bf3 would have been sort of ok if it wasn't full of hackers [14:18:49 CET] <thebombzen> lol [14:19:00 CET] <thebombzen> the biggest problem with games like this is just the random death [14:19:09 CET] <thebombzen> There's a million things that oneshot you [14:19:11 CET] <furq> i had some fun with it when i wasn't being sniped from three miles away while inside a tank by a dude facing the other way in a basement in enemy spawn [14:19:12 CET] <thebombzen> for no reason [14:19:18 CET] <thebombzen> and you have basically no hitpoints [14:19:19 CET] <furq> because obviously client-side netcode is a great idea [14:19:23 CET] <thebombzen> in any of these games [14:19:36 CET] <thebombzen> lol [14:19:46 CET] <thebombzen> yea you have basically no hitpoints and there's a lot of random instakills [14:20:01 CET] <furq> well yeah that's not great [14:20:08 CET] <thebombzen> and what isn't an instakill is frequently almost instant [14:20:13 CET] <furq> but it becomes slightly less great when you can just tell the server you killed someone and it believes you [14:20:22 CET] <thebombzen> lol unsafe network code [14:20:34 CET] <furq> apparently it was fully client-side [14:20:40 CET] <thebombzen> I always love how games conistently start out with unsafe network code [14:20:50 CET] <furq> i'm pretty sure this finished with unsafe netcode as well [14:20:50 CET] <thebombzen> and then people take it apart in about three minutes [14:20:57 CET] <thebombzen> and they have to constantly release patches [14:20:59 CET] <thebombzen> fixing this stuff [14:21:16 CET] <furq> the funniest thing was that instead of banning hackers, they would just reset their level to 0 [14:21:22 CET] <furq> because obviously people don't ever hack to level up faster [14:21:22 CET] <thebombzen> oh [14:21:26 CET] <thebombzen> lol [14:21:30 CET] <furq> nice work EA [14:21:43 CET] <thebombzen> yea if you reset their level to 0 they're just gonna give themselves a whole bunch of xp [14:21:49 CET] <thebombzen> and endup exactly where they started [14:22:02 CET] <furq> i wouldn't mind if you could just hack extra XP directly [14:22:14 CET] <furq> but you had to do that by hacking in games and fucking it up for everyone else [14:22:35 CET] <furq> it only became tolerable if you could get into servers with community banlists [14:22:52 CET] <furq> the community had this big infrastructure set up to do EA's job for them [14:23:12 CET] <furq> or not EA's job, because that is "make as much money as possible right now" [14:23:20 CET] <furq> but what one would hope EA would consider their job [14:29:24 CET] <__jack__> 14:18:18 < thebombzen> they're all bad > you does not like them, does not mean they are bad [14:29:57 CET] <__jack__> I actually enjoyed modern warfare [14:46:10 CET] <thebombzen> __jack__: enjoying something does not mean it's good or bad [14:46:16 CET] <thebombzen> lots of people enjoy lots of bad things [14:46:32 CET] <thebombzen> lots of people enjoy things despite knowing they're bad [15:24:49 CET] <Tom_B> I have the same issue as described here: http://www.ffmpeg-archive.org/Exactly-one-WebVTT-stream-is-needed-td4673148… I'm trying to covert a DVB stream into an HLS stream including the subtitles. As it generates .ts files. I have set -scodec copy and ffmpeg output shows " Stream #0:3 -> #0:2 (dvb_subtitle (dvbsub) -> dvb_subtitle (dvbsub))" but I get the error "Exactly one WebVTT stream is needed" [15:31:54 CET] <JEEB> Tom_B: dvb subtitles are not a thing in HLS [15:32:12 CET] <Tom_B> is there any way to convert them into something that HLS can use? [15:32:25 CET] <JEEB> dvb subtitles are image-based so no [15:32:33 CET] <JEEB> dvb teletext is text-based [15:32:44 CET] <Tom_B> can the subtitles be read and embedded into the frame? [15:32:52 CET] <Tom_B> as pixels [15:33:02 CET] <JEEB> yes [15:33:24 CET] <JEEB> overlay filter is required for that and thus the subtitles cannot be disabled as they will be hardcoded into the video [15:34:23 CET] <Tom_B> yeah, that makes sense. Is it possible to send a message to a running ffmpeg process to change its settings? to turn on/off the subtitles being hardcoded into the video? [15:35:17 CET] <Tom_B> ah, it does look like hls supports webvtt: http://hlsbook.net/how-to-add-subtitles-to-a-live-hls-stream/ can ffmpeg be used to generate m3u8 files in this format? [15:35:38 CET] <thebombzen> Tom_B: also consider using ocr, depending on how legible the subs are [15:37:09 CET] <JEEB> Tom_B: it doesn't do dynamic track selection so if the subtitle type or PID changes that's not a thing you can handle in ffmpeg.c [15:37:31 CET] <JEEB> it actively ignores new AVStreams after the initial probe and track selection :P [15:37:55 CET] <JEEB> and yes, there's some control for some options but I recommend just doing the extra few meters and creating your own API-using app [15:38:21 CET] <JEEB> that way you can handle all the extra cases correctly and don't have to have the metric ton of awful stuff that's in ffmpeg.c that's unrelated to your use case [15:40:13 CET] <Tom_B> so the best way is to have ffmpeg extract the subs, and then load the subs manually into the video player? [15:55:15 CET] <thebombzen> is there a way to transfer frame metadata from one video stream to another? [16:16:14 CET] <thebombzen> hmmm, with avfilter I'm getting unterminated %{} errors [16:16:20 CET] <thebombzen> the example out of the docs verbatim doesn't work [16:18:45 CET] <thebombzen> if I use: -vf drawtext='fontfile=FreeSans.ttf:text=%{localtime\:%a %b %d %Y}' it will complain about an unterminated %{} near {localtime [16:19:05 CET] <thebombzen> if I drop the fontfile= it'll whine about a stray % [16:19:20 CET] <furq> i always needed to use \\: [16:20:52 CET] <faLUCE> Hello: AV_CODEC_ID_H264 shows: YUV422P, YUVJ422é, YUV444P, YUVJ444P, NV12, NV16, NV21 as supported pixel formats, but I can use YUV420P as well. Why? Is this last one automatically converted into one of the listed formats? [16:21:14 CET] <thebombzen> http://sprunge.us/fhDh [16:21:28 CET] <thebombzen> the second \ does work [16:21:35 CET] <thebombzen> but that sounds like an error in the documentation [16:26:16 CET] <faLUCE> I can read that AV_PIX_FMT_NV12 = planar YUV 4:2:0 12bpp, 1 plane for Y and 1 plane for the UV components, which are interleaved (first byte U and the following byte V) <----- is this the answer for my question? [16:39:19 CET] <rhoki2> Hi, I'm trying to record a h264 encoded RTSP stream in environtment where there is pretty high risk of power loss. I've figured out I need to store it in something like fragmented mp4, or matroska. The problem is that muxing into those containers consumes A LOT of CPU time. Why does it happen? Is there any alternative solution I can use? [16:40:50 CET] <furq> are you reencoding [16:41:20 CET] <rhoki2> nope, I'm just trying to dump the stream as it is [16:41:30 CET] <furq> what's the command [16:41:39 CET] <rhoki2> when I'm using non fragmented mp4, all is fine [16:43:29 CET] <rhoki2> ffmpeg i (url) -vcodec:copy -movflags frag_keyframe+empty_moov out.mp4 [16:43:48 CET] <rhoki2> -i, sorry [16:44:02 CET] <furq> that should be -c copy instead of -vcodec copy [16:44:05 CET] <furq> otherwise it'll reencode the audio [16:44:18 CET] <furq> i don't see any other part of that which will hit the cpu [16:44:22 CET] <rhoki2> there is no other stream than video [16:44:33 CET] <furq> fun [16:44:40 CET] <furq> i'd probably use mpegts fwiw [16:44:47 CET] <furq> muxing that to mkv definitely shouldn't hit the cpu though [16:49:14 CET] <rhoki2> by mpegts you mean hls muxer and mpegts segments, right? [17:14:14 CET] <rhoki2> I tried -codec copy -f mpets and it seems OK [17:14:33 CET] <rhoki2> I must have done something wrong, thank you for your help [17:36:52 CET] <jonascj_> Hi all. Can I disable the "size=N/A time=07:02:27.15 bitrate=N/A speed= 386x" output which is printed every now and then? It interfers with capturing the output of "-af silencedetect"... [17:46:42 CET] <furq> jonascj_: -nostats or -v error [17:51:27 CET] <jonascj_> furq: thanks, I did not find anything looking for "progress" in the docs [17:52:27 CET] <nyuszika7h> rhoki2: you can just mux the entire thing into a .ts container too [19:06:39 CET] <faLUCE> is there a function for calculating the size of the planes of an AVFrame (frame->data[0], frame->data[1], frame->data[2]) ? At the moment, I manually calculate them considering the frame's format. For YUV420P the values are: frame->linesize[0]*heigth, frame->linesize[1]*heigth/2, frame->linesize[2]*heigth/2 [19:31:55 CET] <DHE> faLUCE: if you're allocating, just use av_frame_get_buffer and let ffmpeg do it for you [19:32:34 CET] <DHE> are you actually processing the frame data yourself? [19:32:55 CET] <faLUCE> DHE: I know that, but I have to wrap the data into my own struct [19:33:08 CET] <faLUCE> then I need these sizes.... [19:33:59 CET] <faLUCE> DHE: I don't understand if libav lacks this function (planes' size) or is there some function in avutil for calculating that [19:41:38 CET] <faLUCE> DHE: just found: AVBufferRef * av_frame_get_plane_buffer (AVFrame *frame, int plane) let's try it [19:48:09 CET] <faLUCE> nothing done, it's not useful for what I want [19:52:12 CET] <faLUCE> found another one: av_image_get_linesize, let's try it [19:53:05 CET] <feliwir> In page 14 for VP6_DecodeSymbol there isn't an output: https://multimedia.cx/mirror/vp6_format.pdf [20:03:32 CET] <faLUCE> it works ;-) [20:15:05 CET] <faLUCE> is it possible to sws_scale() from a JPEG frame to a YUVJ444P frame without decoding? [20:18:07 CET] <BtbN> uhm, jpeg is a compressed image [20:18:14 CET] <BtbN> you need to decompress/decode it first to get YUV data [20:19:02 CET] <faLUCE> BtbN: I see [20:29:55 CET] <thebombzen> faLUCE: turning a jpeg image into a yuvj44p frame is literally decoding [20:30:02 CET] <thebombzen> that's like [20:30:06 CET] <thebombzen> literally what it means to decode jpeg [20:32:22 CET] <faLUCE> thebombzen: I see. Given that x264 encoder accepts YUVJ444P I thought it could accept encoded JPEG frames as well [20:33:06 CET] <thebombzen> why would you think that [20:33:19 CET] <thebombzen> x264 doesn't haven't a built-in mjpeg decoder [20:33:25 CET] <thebombzen> because it's not FFmpeg [20:33:27 CET] <faLUCE> thebombzen: because I saw the J letter in the pix-fmt ;-) [20:33:41 CET] <faLUCE> thebombzen: anyway, I understand [20:33:52 CET] <thebombzen> it's got a J because it's jpeg's old deprecated yuv [20:33:59 CET] <thebombzen> to distinguish it from modern yuv444p [20:34:39 CET] <faLUCE> yes. I had to view the code in order to see the "deprecated" word [20:34:51 CET] <faLUCE> it compiles without warning [20:40:43 CET] <furq> j denotes full-range [20:46:06 CET] <obamoose> hello [20:47:37 CET] <obamoose> can someone help me figure out why [20:47:48 CET] <furq> yes [20:47:54 CET] <obamoose> thanks [20:47:56 CET] <furq> it's because [20:48:02 CET] <obamoose> solved it [20:48:10 CET] <furq> what a nice young man [20:48:22 CET] <obamoose> welp another issue came up [20:48:28 CET] <furq> oh no [20:48:36 CET] <obamoose> Can someone help me figure out why it's restarting my stream after every file [20:48:37 CET] <rob0> this one is "because I said so" [20:48:38 CET] <obamoose> http://pastebin.com/yFqhG3G8 [20:48:43 CET] <obamoose> noo ;_; [20:48:45 CET] <rob0> or maybe not [20:48:50 CET] <furq> because that's how ffmpeg works [20:49:04 CET] <obamoose> huh [20:49:06 CET] <obamoose> for real? [20:49:15 CET] <obamoose> how do I turn it into a single stream [20:49:20 CET] <furq> you concat the inputs [20:49:35 CET] <obamoose> I what now? [20:49:48 CET] <furq> https://trac.ffmpeg.org/wiki/Concatenate#demuxer [20:50:07 CET] <furq> or use the concat filter, which is generally better, but is less amenable to running on the output of find|xargs [20:51:01 CET] <obamoose> I don't know how this works ;_; [20:51:05 CET] <obamoose> pls spoonfeed me [20:51:25 CET] <thebombzen> or use cat [20:51:28 CET] <thebombzen> and mpegts [20:51:29 CET] <thebombzen> lol [20:51:42 CET] <obamoose> I don't know any of those mean [20:51:47 CET] <obamoose> I got spoonfed my current config [20:51:49 CET] <obamoose> ;_; [20:51:51 CET] <furq> http://vpaste.net/qQ6IO [20:51:53 CET] <obamoose> i'm retarded [20:52:47 CET] <thebombzen> obamoose: it sounds like you have several files you're trying to just loop through a stream [20:53:00 CET] <thebombzen> the easiest way to do that is to remux them all to mpegts and concatenate them [20:53:13 CET] <thebombzen> for each of the files, do ffmpeg -i input.mp4 -c copy output.ts [20:53:14 CET] <furq> i don't think that's the easiest way [20:53:42 CET] <thebombzen> it is because they also want to loop the files [20:54:02 CET] <thebombzen> if you have a bunch of video.ts files, then you can just concatenate them together with "cat" and that will work [20:54:12 CET] <thebombzen> so you have the entire stream in one file, stream.ts [20:54:17 CET] <thebombzen> then to loop the stream you can do: [20:54:22 CET] <obamoose> http://pastebin.com/a0cTmPqE [20:54:23 CET] <obamoose> like this? [20:54:29 CET] <obamoose> I'm trying to loop a directory of files [20:54:30 CET] <furq> no [20:54:33 CET] <furq> not in any way like that [20:54:33 CET] <thebombzen> no [20:54:33 CET] <obamoose> all the same extension [20:54:50 CET] <thebombzen> obamoose: this will take a bit of prep [20:54:59 CET] <thebombzen> the easiest way to do it is to actually concatenate all the video files into one [20:55:24 CET] <obamoose> before or after? [20:55:30 CET] <thebombzen> well I'm not done answering [20:55:31 CET] <obamoose> i'm adding new files every day though [20:55:45 CET] <thebombzen> still easier to convert them all to ts [20:55:48 CET] <furq> well your existing command won't add new files [20:55:55 CET] <furq> actually nvm it's in a while loop [20:55:59 CET] <thebombzen> obamoose: you should put all of the files you want into a directory [20:56:05 CET] <obamoose> they're in home/me/cgn [20:56:05 CET] <thebombzen> and make sure they're mpegts formatted [20:56:09 CET] <furq> there's no way of doing this where new files will get added to the rotation without breaking the stream [20:56:11 CET] <obamoose> they're all mp4's [20:56:15 CET] <obamoose> ;_; [20:56:16 CET] <thebombzen> well that's a problem [20:56:26 CET] <furq> unless you want to write your own application using ffmpeg's libs [20:56:29 CET] <furq> and i suspect you don't [20:56:30 CET] <thebombzen> furq: it's possible, and i'm about to explain how [20:56:38 CET] <furq> is it going to be something fucking awful [20:56:43 CET] <thebombzen> obamoose: for each of the files, you need to do ffmpeg -i input.mp4 -c copy output.ts [20:56:45 CET] <thebombzen> or whatever [20:56:50 CET] <obamoose> I just want to create a tv channel in ubuntu [20:56:50 CET] <thebombzen> so they're all ts [20:56:52 CET] <thebombzen> I KNOW [20:56:53 CET] <obamoose> why is it so hard ;_;? [20:57:00 CET] <thebombzen> STOP WHINING ABOUT HOW HARD IT IS AND ACTUALLY LISTEN FOR ONCE [20:57:16 CET] <furq> are you going to suggest appending to the .ts while the stream is still running [20:57:23 CET] <thebombzen> furq: I'm not done [20:57:25 CET] <thebombzen> lemme talk [20:57:37 CET] <thebombzen> obamoose: you want to remux each of the videos in the directory to .ts [20:57:45 CET] <obamoose> yes [20:57:49 CET] <thebombzen> for each of them, do ffmpeg -i input.mp4 -c copy output.ts [20:57:50 CET] <thebombzen> then [20:58:01 CET] <obamoose> yes [20:58:08 CET] <thebombzen> make sure they're named in order you want them to play [20:58:16 CET] <thebombzen> then you can do this: [20:59:07 CET] <thebombzen> while true; do cat *.ts; done | ffmpeg -y -re -f mpegts -i - <rest of your command line> [20:59:39 CET] <thebombzen> if you drop a new .ts file into the directory it'll be added to the rotation once the old ones are done [20:59:45 CET] <thebombzen> and it restarts [21:00:23 CET] <rob0> I don't get why the while loop, why not just cat *.ts | ffmpeg ... ? [21:00:32 CET] <furq> because that won't loop [21:00:39 CET] <rob0> oh [21:00:50 CET] <furq> and you can't use -stream_loop because that won't add newly added files [21:00:51 CET] <thebombzen> read the question lmao [21:00:55 CET] <rob0> "and it restarts" [21:01:02 CET] <furq> although [21:01:16 CET] <furq> that doesn't satisfy the requirement of not dropping the stream [21:01:24 CET] <thebombzen> why not? [21:01:33 CET] <furq> because it'll drop out at the end of every rotation [21:01:36 CET] <thebombzen> no it won't [21:01:42 CET] <furq> of course it will [21:01:44 CET] <thebombzen> no it won't [21:01:50 CET] <furq> every time you restart ffmpeg, the stream will drop [21:01:55 CET] <thebombzen> this never restarts ffmpeg [21:01:59 CET] <thebombzen> just leave that running forever [21:02:05 CET] <obamoose> mom, dad stop fighting ;_; [21:02:11 CET] <furq> nvm i can't read [21:02:14 CET] <thebombzen> lol [21:02:24 CET] <thebombzen> do this basically: while true; do cat *.ts; done | ffmpeg -y -re -f mpegts -i - <rest of your command line> [21:02:40 CET] <thebombzen> this will loop all the .ts files in your directory [21:03:24 CET] <thebombzen> leave that running forever [21:03:38 CET] <thebombzen> note that you can save cpu time by doing your video encoding beforehand [21:03:39 CET] <thebombzen> but that should do it [21:03:48 CET] <thebombzen> now, what are you getting the files from? [21:04:02 CET] <thebombzen> obamoose: where are the video files originating [21:04:33 CET] <obamoose> youtube [21:04:34 CET] <furq> if he has bitrate constraints then it probably doesn't matter [21:04:35 CET] <obamoose> -> mp4 [21:04:39 CET] <furq> or maybe it does [21:04:47 CET] <thebombzen> furq: but he can bitrate constrain them beforehand [21:04:51 CET] <furq> if they're all from youtube and they're all the same resolution then you don't need to reencode at all [21:04:51 CET] <thebombzen> and use -preset slow or something [21:05:10 CET] <thebombzen> yea [21:05:15 CET] <thebombzen> if they're all from youtube and the same resolution [21:05:27 CET] <thebombzen> you can actually use -c copy instead of the previous stuff [21:07:28 CET] <obamoose> I'm confused [21:08:09 CET] <obamoose> http://vpaste.net/DbY6e [21:08:12 CET] <obamoose> this? [21:08:23 CET] <thebombzen> so <rest of your command line> [21:08:24 CET] <thebombzen> means the rest [21:08:27 CET] <thebombzen> not the entire thing [21:08:29 CET] <furq> forget the -f concat stuff [21:08:36 CET] <furq> and in fact most of that [21:08:42 CET] <thebombzen> also cat isn't spelled with a k [21:08:45 CET] <furq> you might as well just write the entire command for him [21:08:49 CET] <furq> it'll save everyone a lot of time [21:09:25 CET] <thebombzen> while true; do cat *.ts; done | ffmpeg -re -f mpegts -i - -c copy -f flv rtmp://live.twitch.tv/app/streamkey [21:09:28 CET] <thebombzen> try that [21:09:47 CET] <thebombzen> make sure you actually have a .ts video file there, otherwise it'll just fail [21:10:00 CET] <thebombzen> to get one of those, use ffmpeg -i video.mp4 -c copy video.ts [21:10:24 CET] <obamoose> ;_; [21:10:29 CET] <thebombzen> what [21:10:34 CET] <thebombzen> what are you crying about now [21:10:35 CET] <obamoose> oh [21:10:40 CET] <thebombzen> your inability to copy and paste [21:10:46 CET] <obamoose> wait I need to find an mp4 to ts converter [21:10:51 CET] <thebombzen> how about ffmpeg [21:10:55 CET] <thebombzen> I literally fucking told you how to do it [21:10:58 CET] <thebombzen> about thirty seconds ago [21:11:10 CET] <obamoose> I wasn't kidding when I said retarded [21:11:23 CET] <thebombzen> [16:09:47] <thebombzen> make sure you actually have a .ts video file there, otherwise it'll just fail [21:11:23 CET] <thebombzen> [16:10:00] <thebombzen> to get one of those, use ffmpeg -i video.mp4 -c copy video.ts [21:11:27 CET] <thebombzen> like [21:11:30 CET] <thebombzen> come on [21:11:58 CET] <obamoose> but but [21:12:01 CET] <obamoose> is that a test file? [21:12:10 CET] <thebombzen> lol it's whatever you want it to be [21:12:13 CET] <obamoose> or does it take all my files inside my folder [21:12:26 CET] <obamoose> and convert them? [21:12:28 CET] <thebombzen> okay, video.mp4 means the actual filename [21:12:43 CET] <thebombzen> if it's not called video.mp4, then instead use whatever the filename is [21:12:48 CET] <obamoose> yessir [21:16:20 CET] <obamoose> ffmpeg -i home/obamoose/cgn/1.mp4 -c copy 1.ts won't find it [21:16:28 CET] <obamoose> home/obamoose/cgn/1.mp4: No such file or directory [21:17:33 CET] <thebombzen> well [21:17:52 CET] <thebombzen> that's because you need a / in front [21:17:59 CET] <thebombzen> home/obamoose/cgn/1.mp4 is a relative path [21:18:08 CET] <thebombzen> from the CWD (current working directory) [21:18:38 CET] <thebombzen> if it starts with a / then it's an absolute path and it means "start from the root of the filesystem" not "start from the current working directory" [21:18:43 CET] <obamoose> oh [21:18:48 CET] <obamoose> thank you [21:18:53 CET] <thebombzen> so when you copy and paste [21:18:56 CET] <thebombzen> things like this matter [21:19:02 CET] <obamoose> indeed [21:19:16 CET] <obamoose> you know how I can confirm I'm retarded? [21:19:35 CET] <obamoose> I pasted this: /home/obamoose/cgn/1.mp4: No such file or directory [21:20:23 CET] <thebombzen> well [21:20:25 CET] <furq> is it the fact that you picked an irc client that interprets that as a command [21:20:29 CET] <furq> that's pretty dumb [21:20:45 CET] <furq> /there's/nothing/wrong/with/this [21:20:55 CET] <thebombzen> well kvirc does too but at least it whines at you that command not found [21:21:08 CET] <thebombzen> either way [21:21:27 CET] <thebombzen> obamoose: it's telling you that there's no such file or directory there [21:21:32 CET] <thebombzen> because there's no such file or directory [21:21:40 CET] <thebombzen> error messages are not always helpful but they usually are [21:21:43 CET] <thebombzen> you should probably read them [21:21:53 CET] <obamoose> Yessir [21:21:58 CET] <obamoose> it was fixed by adding a / [21:22:04 CET] <obamoose> but now I can't seem to find the file [21:22:29 CET] <thebombzen> well the file should be in /home/obamoose/cgn [21:22:38 CET] <obamoose> it's not ;_; [21:22:40 CET] <thebombzen> well then [21:22:45 CET] <thebombzen> it can't find a file that isnt' there [21:22:47 CET] <thebombzen> because it isn't there [21:23:01 CET] <thebombzen> if you're trying to remux a .mp4 into a .ts file [21:23:05 CET] <obamoose> File '1.ts' already exists. Overwrite ? [y/N] [21:23:08 CET] <thebombzen> perhaps try doing that on an actual file [21:23:27 CET] <thebombzen> well it sounds like you already ran the command once [21:23:30 CET] <thebombzen> and it already succeeded [21:23:35 CET] <thebombzen> so why are you trying again [21:23:53 CET] <obamoose> cause I can't find it in the cgn folder [21:24:30 CET] <thebombzen> perhaps you can't find it because it's not there [21:24:34 CET] <thebombzen> have you considered this possibility [21:24:47 CET] <obamoose> oh damn [21:24:48 CET] <obamoose> I'm slow [21:24:51 CET] <thebombzen> yes [21:24:53 CET] <obamoose> it's in the main folder [21:25:53 CET] <RossW> for next time: find / -name "1.mp4" [21:26:04 CET] <thebombzen> lolno [21:26:05 CET] <thebombzen> don't do that [21:26:22 CET] <thebombzen> that would take too long [21:26:52 CET] <RossW> it's quicker than wasting an hour looking everywhere it isn't :) [21:27:10 CET] <thebombzen> but slower than find /home/obamoose -name 1.mp4 [21:27:25 CET] <furq> it's probably best to assume he didn't write it somewhere that he doesn't have write permissions [21:27:33 CET] <furq> which is probably everywhere outside of ~ [21:27:41 CET] <RossW> sure - if you're certain it's in the /home/obamoose path... [21:27:43 CET] <furq> at least for his own safety i hope it is [21:28:01 CET] <thebombzen> if it's not in ~/ then he's got bigger problems [21:28:03 CET] <furq> if he had write permissions in /usr i doubt he'd be here talking to us [21:33:51 CET] <obamoose> I converted them all to ts \o/ [21:39:42 CET] <obamoose> I think [21:39:43 CET] <obamoose> I did it [21:40:33 CET] <obamoose> wait nvm [21:40:35 CET] <obamoose> It didn't work [21:40:50 CET] <obamoose> but no error message ;_; [21:41:09 CET] <obamoose> while true; do cat /home/obamoose/cgn/*.ts; done | ffmpeg -y -re -f mpegts -i ffmpeg -y -re -i $ -vcodec libx264 -preset veryfast -maxrate 3000k -bufsize 6000k -pix_fmt yuv420p -g 50 -c:a aac -b:a 160k -ac 2 -ar 44100 -f concat -i concatlist -f -f flv rtmp://live.twitch.tv/app/streamkey [21:41:22 CET] <obamoose> wait I have ffmpeg twice [21:42:07 CET] <thebombzen> have you considered [21:42:14 CET] <thebombzen> copy and pasting the command I gave you [21:42:24 CET] <thebombzen> rather than coming up with one that doesn't work yet again [21:43:15 CET] <obamoose> I thought [rest of your command line] [21:43:21 CET] <obamoose> meant the whole command line [21:47:47 CET] <thebombzen> no that's not what "rest of" means [21:48:33 CET] <thebombzen> https://www.oxfordlearnersdictionaries.com/us/definition/english/rest_1 [21:52:44 CET] <obamoose> http://pastebin.com/34gcJBxA [21:52:45 CET] <obamoose> is what I have [21:53:11 CET] <obamoose> ffmpeg: No such file or directory [21:53:16 CET] <nightlingo> hello! [21:53:46 CET] <obamoose> hello [21:53:46 CET] <nightlingo> how may I encode an mp4 video into having a fixed sample_size ? [21:55:04 CET] <nightlingo> either that, or , any ideas where can I find an example .mp4 file that has a fixed sample size? I really need it in order to analyze its format [22:01:28 CET] <thebombzen> obamoose: again [22:01:32 CET] <thebombzen> copy and paste what I wrote [22:01:37 CET] <thebombzen> which I will leave here for you, again [22:01:44 CET] <obamoose> i'm sorry ;_; [22:02:20 CET] <thebombzen> while true; do cat /home/obamoose/cgn/*.ts; done | ffmpeg -re -f mpegts -i - -c copy -f flv rtmp://live.twitch.tv/app/streamkey [22:02:44 CET] <petecouture> Can ffmpeg encode a file input from a url e.g. http://example.com/movie.mp4 [22:03:03 CET] <thebombzen> yes [22:04:33 CET] <petecouture> Can the output be saved to a S3 bucket? [22:04:53 CET] <thebombzen> well I assume you'd have to do that yourself [22:05:40 CET] <petecouture> gotcha [22:06:04 CET] <petecouture> @thebombzen thank you for your help [22:09:07 CET] <thebombzen> in general putting something with http is harder than taking it [22:12:48 CET] <asda> is it possible for ffmpeg to print out the actual versions of particular encoders ffmpeg was built against, for example libopus 1.1.3? [22:13:07 CET] <thebombzen> if it was dynamically linked? easily [22:13:37 CET] <asda> thebombzen: statically linked [22:14:26 CET] <thebombzen> I don't know, sorry [22:15:18 CET] <asda> thanks anyway [22:15:21 CET] <asda> :) [22:20:10 CET] <furq> https://www.youtube.com/watch?v=h4kBcm-ls8Y&t=67 [22:27:21 CET] <hky> Hi! When creating a buffersink filter context in AVFilterContext using avfilter_graph_create_filter, how can I specify the number of input pads? [22:28:47 CET] <obamoose> Malformed AAC bitstream detected: use the audio bitstream filter 'aac_adtstoasc' to fix it ('-bsf:a aac_adtstoasc' option with ffmpeg) av_interleaved_write_frame(): Invalid data found when processing input [22:28:52 CET] <obamoose> thebombzen: ;_; [22:29:36 CET] <furq> did you try doing the exact thing it explicitly tells you to do [22:29:57 CET] <obamoose> y-yes? [22:30:10 CET] <obamoose> all I did was replace streamkey with the actual key] [22:33:21 CET] <thebombzen> you should do the thing it tells you to do [22:34:13 CET] <obamoose> Option bsf:a (A comma-separated list of bitstream filters) cannot be applied to input url - -- you are trying to apply an input option to an output file or vice versa. Move this option before the file it belongs to. Error parsing options for input file -. Error opening input files: Invalid argument [22:34:56 CET] <furq> again, you should do the thing it tells you to do [22:43:09 CET] <obamoose> i placed it before | [22:43:10 CET] <obamoose> ;_; [22:43:23 CET] <thebombzen> well how about not doing that [22:43:32 CET] <obamoose> but isn't that input? [22:44:52 CET] <thebombzen> no [22:44:58 CET] <thebombzen> it's not even part of the ffmpeg command [22:47:27 CET] <obamoose> but where do I place it ;_;? [22:48:11 CET] <thebombzen> where it tells you to [22:49:07 CET] <obamoose> Move this option before the file it belongs to [22:49:51 CET] <obamoose> while true; do cat -bsf:a aac_adtstoasc /home/obamoose/cgn/*.ts; done | ffmpeg -re -f mpegts -i - -c copy -f flv rtmp://live.twitch.tv/app/streamkey [22:50:15 CET] <thebombzen> even I'm starting to lose my patience right now [22:50:20 CET] <thebombzen> have you ever used a command line before [22:50:28 CET] <obamoose> y-yes [22:50:39 CET] <thebombzen> are you sure [22:51:39 CET] <obamoose> yes? [22:52:31 CET] <thebombzen> do you know what a pipe is [22:52:35 CET] <thebombzen> in a command line [22:52:38 CET] <thebombzen> you know, the | thingy [22:52:52 CET] <obamoose> yessir [22:54:06 CET] <thebombzen> do you know what "cat" does [22:54:58 CET] <thebombzen> and obamoose have you considered using OBS instead [22:55:01 CET] <thebombzen> https://obsproject.com/ [22:55:30 CET] <obamoose> it's a headless ubuntu server somewhere in a datacenter in france [22:55:33 CET] <obamoose> can I run obs? [22:56:23 CET] <thebombzen> why do you have access to a headless datacenter in france [22:56:27 CET] <thebombzen> if you have no idea how to use a command line [22:56:48 CET] <thebombzen> who gave you access to that thing and how much do they hate their job [22:56:50 CET] <obamoose> for a 24/7 stream [22:56:58 CET] <obamoose> m-me myself and I [22:57:26 CET] <thebombzen> why do you want to have a 24/7 twitch stream of videos you downloaded off youtube [22:57:43 CET] <thebombzen> so much that you're willing to pay money for a server you don't know how to administer [22:58:18 CET] <obamoose> no bully ;_; [22:58:58 CET] <thebombzen> this is a serious question [22:59:09 CET] <thebombzen> why do you want to have a 24/7 twitch stream of videos you downloaded off youtube [22:59:20 CET] <obamoose> I'm creating an esports channel [22:59:21 CET] <BtbN> Just set up a playlist on Twitch, and let it plays those videos for you...? [22:59:33 CET] <obamoose> playlist is only for a select few streamers [22:59:44 CET] <BtbN> hm [22:59:49 CET] <thebombzen> what about a YouTube gaming playlist [22:59:52 CET] <thebombzen> that's a thing [23:00:03 CET] <obamoose> starting out on twitch [23:00:14 CET] <BtbN> I hope it's at least your own content you are broadcasting there? [23:00:14 CET] <thebombzen> by streaming other people's content? [23:01:35 CET] <obamoose> It's others content [23:01:39 CET] <obamoose> but with explicit permission [23:07:16 CET] <furq> i hope you at least bought the cheapest ovh server [23:14:38 CET] <obamoose> furq: yes, kimsufi [23:14:44 CET] <obamoose> furq: ;_; [00:00:00 CET] --- Mon Mar 20 2017

1 0

ffmpeg-devel.log.20170318
by burek 19 Mar '17

19 Mar '17

[02:22:29 CET] <J_Darnley> Is it a bad thing that while browsing/reseaching wifi routers I say "I hope one day I need that many wired ports (24) and an optican WAN port"? [02:22:43 CET] <J_Darnley> *optical [02:44:27 CET] <TD-Linux> used fiber is cheap enough around here that I've considered using it at home. but the equipment is generally power hungry and has noisy fans [03:19:51 CET] <wm4> I can't believe this side data merge shit is still being perpetuated [04:12:17 CET] <wm4> how do you run fate with threads again? does adding THREADS=4 to the make command (as argument) work? [04:25:19 CET] <jamrial> wm4: yes [04:27:36 CET] <wm4> ok [06:21:40 CET] <Ruyi> Hi, sir [06:22:34 CET] <Ruyi> When I check Ö [06:24:21 CET] <Ruyi> When I check the GSoC website, I find that now I can't submit my application before March 21 [07:28:02 CET] <wm4> Ruyi: what's your question? [07:50:03 CET] <lei-lhg> Hi,all.I was trying to build ffplay using bitbake. But it always complaint "SDL not found". [07:50:04 CET] <lei-lhg> | DEBUG: Executing shell function do_configure [07:50:06 CET] <lei-lhg> | ERROR: SDL not found [07:50:07 CET] <lei-lhg> In fact,I have run "bitbake -c install libsdl" successfully, I don't know why ffmpeg say "sdl not found" [07:50:09 CET] <lei-lhg> Did anyone have met this problem? [07:50:10 CET] <lei-lhg> any advice and suggestions will be greatly appreciated [07:55:00 CET] <wm4> ask on #ffmpeg, or whatever help channels bitbake provides [07:58:09 CET] <lei-lhg> ok.thanks [08:09:26 CET] <cone-069> ffmpeg 03Muhammad Faiz 07master:c52638cca255: swresample/swresample: do not use s32p internally by default when resampling [08:38:54 CET] <cone-069> ffmpeg 03Rostislav Pehlivanov 07master:3796fb2692f8: lavfi: deprecate AVFilterGraph->resample_lavr_opts [10:54:56 CET] <rcombs> wm4: what do you mean by "limiting it to determine the correct codec ID." [10:55:22 CET] <wm4> having 1 mp3 demuxer, and making it set the correct codec ID in read_header [10:58:07 CET] <rcombs> codec probing doesn't call read_header [10:58:13 CET] <rcombs> it just calls the probe functions [10:58:29 CET] <rcombs> and then if one passes, then the associated codec ID is used [10:58:42 CET] <rcombs> from the list in set_codec_from_probe_data [10:58:43 CET] <wm4> let me guess, this codec probing is actually some horrible hack I don't want to know about [10:59:36 CET] <rcombs> it's mostly for MPEGTS [10:59:47 CET] <rcombs> 'cause some files don't provide any other way to determine what codec a given stream is [11:00:20 CET] <rcombs> apparently it's also used in AVI, MPEGPS, and WAV [11:00:36 CET] <rcombs> and then also in MOV with my patch [11:00:39 CET] <wm4> ok looked how it works [11:00:48 CET] <wm4> it calls the demuxer probe functions on packet data [11:00:51 CET] Action: wm4 goes vomit [11:01:07 CET] <rcombs> it's not _too_ insane since they're all "raw" formats [11:01:14 CET] <JEEB> I think that was the stuff that was added to support MPEG-TS without PMT [11:01:28 CET] <wm4> still an abuse of abstractions [11:01:44 CET] <wm4> it should probably be done by a parser [11:02:52 CET] <rcombs> that'd be nice, and then the probe functions could call into the parsers [11:03:03 CET] <rcombs> for the raw formats [11:03:39 CET] <rcombs> for MOV in particular, we _could_ use the parser for this [11:04:07 CET] <rcombs> like, set need_parsing on the stream when the ID is ambiguous [11:04:21 CET] <rcombs> the MPEG audio parser will change the codec ID in _some_ cases [11:04:21 CET] <wm4> anyway, your patch makes sense considering these things [11:04:25 CET] <rcombs> (the others should be fixed) [11:04:31 CET] <wm4> + (p->buf_size < PROBE_BUF_MAX || layer == 3)) [11:04:35 CET] <wm4> really layer==3? [11:05:02 CET] <rcombs> that was to make sure that heuristic doesn't get applied to other layers [11:05:21 CET] <wm4> why? [11:05:40 CET] <rcombs> 'cause then you'd get AVPROBE_SCORE_EXTENSION - 2 for all 3 [11:05:58 CET] <JEEB> :D [11:10:52 CET] <BtbN> I wonder if it'd be worth adding a CPU usage indicator to the progress and speed line ffmpeg prints. [11:17:55 CET] <wm4> sounds too system specific [11:22:24 CET] <BtbN> Well, Posix and win32 only. Would cover most platforms [11:23:30 CET] <wm4> ah if posix has something for this why not [11:27:10 CET] <BtbN> hm, I remember there being some way to calculate CPU usage from some posix function. But I can't find it [11:34:05 CET] <atomnuker> that would be pointless unless -re is specified, it would only tell you how inefficient the decoder/encoder is with multithreading [11:34:55 CET] <BtbN> I'm more thinking about having an indicator of stuff being slow because the system is under heavy load [11:35:03 CET] <kierank> atomnuker: what does -re actually do [11:35:07 CET] <kierank> afaik it just measures [11:35:34 CET] <kierank> atomnuker: oh i see what you mean [11:35:34 CET] <wm4> isn't that realtime mode [11:36:51 CET] <JEEB> re mostly sleeps according to input timestamps [11:36:53 CET] <JEEB> :3 [12:39:05 CET] <wbs> BtbN: the "times" function ("man 2 times" on linux) should give you the amount of cpu time spent [13:13:09 CET] <BtbN> wbs, yeah, but that's only for the current process [15:28:36 CET] <tdjones> I'm trying to use the AAC pyschoacoustic system within the vorbis encoder for the GSoC qualification task. Should the grouping used by ff_psy_init be obtained from the mapping structs within the vorbis context? I'm struggling to understand how this can be supplied in the vorbis encoder. [15:29:17 CET] <atomnuker> since the vorbis encoder is stereo/mono only just assume stereo [16:14:49 CET] <cone-270> ffmpeg 03James Almer 07master:824d4062a172: compat/atomics/gcc: use __typeof__ instead of typeof [16:20:43 CET] <wm4> jamrial: "typeof" is not C99 [16:20:51 CET] <wm4> that's why it's hidden in C99 mode [16:21:04 CET] <wm4> __typeof__ is a reserved identifier, that's why it can be always available [18:34:37 CET] <tdjones> What are the scalefactor band sizes with ff_psy_init? The vorbis specs state that frames can be powers of two from 64 to 8192, should arrays of factors be provided similar to how aac handles this? [18:36:51 CET] <atana> michaelni, ping [18:40:21 CET] <atomnuker> tjablin: for now use the aac ones (and make sure the encoder uses the same transform size as aac for non-transients which is 1024) [19:23:46 CET] <cone-415> ffmpeg 03Anton Khirnov 07master:ec021d48445a: buffer: fix av_buffer_pool_init2() documentation [19:23:46 CET] <cone-415> ffmpeg 03Clément BSsch 07master:53587ca48280: Merge commit 'ec021d48445a414325ad59a73f9cde3212b173e4' [19:29:43 CET] <cone-415> ffmpeg 03Anton Khirnov 07master:e9bfff1cc66c: lavc: free buffer_frame/pkt on avcodec_open2() failure [19:29:44 CET] <cone-415> ffmpeg 03Clément BSsch 07master:822f1a7913da: Merge commit 'e9bfff1cc66c85b91b262c41e8aa5e8685606225' [19:32:51 CET] <cone-415> ffmpeg 03Anton Khirnov 07master:04763c6f8769: h264_direct: use the reference mask from the actual reference [19:32:52 CET] <cone-415> ffmpeg 03Clément BSsch 07master:39d2b4875741: Merge commit '04763c6f87690b31cfcd0d324cf36a451531dcd0' [19:35:56 CET] <ubitux> BBB: i'm going to continue to noop all the vp9 commits without much thinking [19:36:19 CET] <ubitux> at some point we'll need to make a final diff to spot all the tiny differences they put in [19:36:43 CET] <ubitux> but since the files are split in one repository and not the other, it's a pita to do it at every commit [19:36:48 CET] <ubitux> do you have any objection? [19:42:44 CET] <ubitux> anyway, feel free to look into details [19:42:48 CET] <cone-415> ffmpeg 03Ronald S. Bultje 07master:bc6e0b64a910: vp9: split last/cur_frame from the reference buffers. [19:42:49 CET] <cone-415> ffmpeg 03Ronald S. Bultje 07master:5b995452a63e: vp9: allocate 'b', 'block/uvblock' and 'eob/uveob' dynamically. [19:42:50 CET] <cone-415> ffmpeg 03Ronald S. Bultje 07master:1730a67ab99d: vp9: add frame threading [19:42:51 CET] <cone-415> ffmpeg 03Anton Khirnov 07master:f2143c57b6a6: vp9: reindent after last commit [19:42:52 CET] <cone-415> ffmpeg 03Clément BSsch 07master:9821aa7d3890: Merge commit 'f2143c57b6a61fef382f3128138d8558a9bdecee' [19:44:30 CET] <wm4> (I bet he'd have objections if you _did_ try to merge some of that) [19:45:27 CET] <cone-415> ffmpeg 03Luca Barbato 07master:602abe77b02f: avconv: Check the fifo allocation [19:45:28 CET] <cone-415> ffmpeg 03Clément BSsch 07master:e3b81d2d9bd8: Merge commit '602abe77b02f9702c18c2787d208fcfc9d94b70f' [19:49:29 CET] <ubitux> wm4: yeah [19:49:43 CET] <ubitux> wm4: btw, wrt f6d2fed811dea36c4ebaf991927e44c78eb0aca5; did you already included it in af1761f7b5b1b72197dc40934953b775c2d951cc? [19:52:51 CET] <ubitux> so much noop incoming [19:55:44 CET] <BBB> ubitux: I believe theyre all backports of my work, anton can confirm that [19:56:14 CET] <ubitux> yeah but sometimes backports with var renames, comments adjusts, and stuff like that, you know the story :) [19:56:23 CET] <wm4> ubitux: not sure, but probably not needed [19:56:24 CET] <BBB> ubitux: they realize at this point that forking the decoder and doing their own thing wasnt a great idea, so I think theyll go back to our version (upstream?) and then well work together on doing some work that they want (like splitting in multiple files) [19:56:34 CET] <wm4> ubitux: this part is a bit different in ffmpeg.c anyway [19:56:40 CET] <ubitux> wm4: -filter_complex testsrc works here so i'll skip it; thx [19:56:46 CET] <BBB> ubitux: I dont think their current version should be any different from ours, it should be identical [19:56:47 CET] <wm4> ubitux: I'd say skip it for now, I can verify and post a patch if needed later [19:56:51 CET] <ubitux> wm4: should i reference that commit anyway? [19:56:52 CET] <wm4> and NOPs are good [19:56:54 CET] <BBB> ubitux: but yes you can skip them [19:57:15 CET] <BBB> (I think youre just trying to decrease the backlog, and I 100% support that) [19:57:23 CET] <ubitux> BBB: would you be interested in splitting into files btw? [19:57:30 CET] <BBB> sure [19:57:30 CET] <wm4> ubitux: not sure, but maybe doesn't hurt [19:57:38 CET] <ubitux> wm4: alright, thanks [19:57:41 CET] <BBB> ubitux: I guess the correct answer is I dont care either way" [19:57:45 CET] <ubitux> back to noops [19:57:47 CET] <ubitux> BBB :) [19:57:48 CET] <BBB> ubitux: but if it makes them happy Im fine with it [19:57:57 CET] <ubitux> i doubt they care [19:58:03 CET] <BBB> ubitux: I think they prefer it [19:58:06 CET] <ubitux> but it may ease the merge effort [19:58:08 CET] <BBB> ubitux: vp9.c is pretty big [19:58:16 CET] <BBB> hevc/h264 are split also [19:58:17 CET] <ubitux> i mean they do not care what's in ffmpeg [19:58:30 CET] <BBB> I think in this case they did, because they couldnt backport our work anymore [19:58:43 CET] <BBB> things like 10/12bpc support, 422/444 support, avx2 assembly, etc. [19:58:44 CET] <ubitux> heh, yeah :) [19:58:48 CET] <BBB> thats kinda important [19:58:56 CET] <BBB> a vp9 decoder thats pretty but without simd isnt very useful [19:59:14 CET] <ubitux> if you want to do it, go ahead, i'm back to the noops, the next vp9 commits are much later [19:59:15 CET] <BBB> it also failed to decode valid 8bit content that uses some special features that are starting to become more mainstream [19:59:23 CET] <BBB> enjoy nooping ;) [20:01:04 CET] <cone-415> ffmpeg 03Luca Barbato 07master:f6d2fed811de: avconv: Make sure that inputless filtergraphs are configured [20:01:05 CET] <cone-415> ffmpeg 03Clément BSsch 07master:55dae222a0b3: Merge commit 'f6d2fed811dea36c4ebaf991927e44c78eb0aca5' [20:01:35 CET] <cone-415> ffmpeg 03Sean McGovern 07master:6fc944e6136b: Prepare for 12_alpha1 Release [20:01:36 CET] <cone-415> ffmpeg 03Clément BSsch 07master:bd37ffdbb240: Merge commit '6fc944e6136b050bf965f847bbfd69e1fe572f82' [20:02:33 CET] <cone-415> ffmpeg 03Mark Thompson 07master:121f34d5f0c8: hwcontext_vaapi: Try the first render node as the default DRM device [20:02:34 CET] <cone-415> ffmpeg 03Clément BSsch 07master:77d590cd9c5b: Merge commit '121f34d5f0c8d7d376829a467590fbbe4c228f4f' [20:03:52 CET] <cone-415> ffmpeg 03Mark Thompson 07master:03adfe913062: vaapi_h264: Constify pointers [20:03:53 CET] <cone-415> ffmpeg 03Clément BSsch 07master:54d839e80a06: Merge commit '03adfe913062c6995136eb1ca51152b6d596c0f4' [20:03:59 CET] <wm4> BBB: aw how mean [20:04:19 CET] <wm4> but as a superset-project we're in a good position to spot such things I guess [20:05:45 CET] <cone-415> ffmpeg 03Mark Thompson 07master:ee9061293e92: vaapi_mpeg2: Constify pointers [20:05:46 CET] <cone-415> ffmpeg 03Clément BSsch 07master:a6a6ed54d86b: Merge commit 'ee9061293e925916fe2e0b7c08fbbd1f981b1d29' [20:07:14 CET] <cone-415> ffmpeg 03Mark Thompson 07master:01d6f84f49a5: vaapi_vc1: Constify pointers [20:07:15 CET] <cone-415> ffmpeg 03Clément BSsch 07master:e788c50ce232: Merge commit '01d6f84f49a55fd591aa120960fce2b9dba92d0d' [20:07:50 CET] <cone-415> ffmpeg 03Mark Thompson 07master:5a667322f5cb: vaapi_vc1: Remove redundant version check [20:07:51 CET] <cone-415> ffmpeg 03Clément BSsch 07master:2c400ba7d1ab: Merge commit '5a667322f5cb0e77c15891fc06725c19d8f3314f' [20:08:41 CET] <ubitux> michaelni: any objection to 00a0419c7f7ebce9010cba93b7ff67c9f1165815? [20:08:58 CET] <ubitux> do you wish to replace that ifdefery with a comment above the "smart" code? [20:11:09 CET] <ubitux> this is actually a large serie of dead code drop [20:11:34 CET] <ubitux> http://sprunge.us/DdTB [20:11:45 CET] <ubitux> i'll merge those tomorrow unless you have some objections [20:12:07 CET] <ubitux> please be specific about the ones you wish to keep [20:12:38 CET] <ubitux> (i'm poking you because it affects most of your code, and probably no one else cares about the remaining instances) [20:13:11 CET] <atomnuker> bofh_: ping [20:16:43 CET] <BBB> wm4: can facts be mean? [20:16:51 CET] <wm4> yes [20:20:24 CET] <BBB> wm4: oh :D [20:31:53 CET] <BBB> kierank: whats up with you throwing parties with facebook? [20:32:32 CET] <kierank> BBB: blame Colleen I guess [20:32:40 CET] <BBB> it sounds like youre co-paying ;) [20:33:16 CET] <kierank> Yeah was her idea [20:33:35 CET] <BBB> it was her idea that you pay [20:33:39 CET] <BBB> amazing ideas ;) [20:33:45 CET] <BBB> hey, kierank, I have another great idea [20:33:47 CET] <BBB> ... [20:33:50 CET] <kierank> It was her idea to have a party in vegas [20:33:55 CET] <BBB> :-p [20:33:58 CET] <BBB> Im kidding you [20:34:01 CET] <BBB> so, should I go? [20:34:30 CET] <kierank> Dunno, NAB is super corporate [20:34:43 CET] <kierank> But might be good for you if you have meetings and the likes [20:35:23 CET] <BBB> I hate meetings :-p [22:27:22 CET] <michaelni> ubitux, 00a0419c7f7ebce9010cba93b7ff67c9f1165815 is basically documentation and a reference for the code, i dont see why that should be removd [23:29:54 CET] <ubitux> michaelni: that was my understanding, but while it is an easy dev helper, using an undocumented ifdefery is what makes it easily classified as cruft [23:30:30 CET] <ubitux> btw, it doesn't compile [23:31:01 CET] <ubitux> (and while break often if it can't be compiled [23:31:05 CET] <ubitux> will* [23:31:07 CET] <ubitux> ) [23:32:52 CET] <michaelni> what do you suggest ? [23:34:49 CET] <ubitux> /* (a * b + r) / c */ [23:34:51 CET] <ubitux> ? [23:36:11 CET] <ubitux> i also think it actually belongs as a comment to the doxy of the function [23:36:35 CET] <ubitux> ...but that's already the case [23:52:54 CET] <cone-302> ffmpeg 03Diego Biurrun 07master:00a0419c7f7e: mathematics: Kill non-compiling disabled cruft [23:52:54 CET] <cone-302> ffmpeg 03Clément BSsch 07master:1e1513d01aa8: lavu/mathematics: document so-called "cruft" [23:52:54 CET] <cone-302> ffmpeg 03Clément BSsch 07master:ea8efc959449: lavu/mathematics: split closing bracket out of ifdefery [23:52:54 CET] <cone-302> ffmpeg 03Clément BSsch 07master:3d5c2169e44e: Merge commit '00a0419c7f7ebce9010cba93b7ff67c9f1165815' [23:53:03 CET] <ubitux> michaelni: any other commit in the serie i should not merge? [23:59:23 CET] <michaelni> the code removed from aa37d2bf4505afc106e2a23c44afc722bb204a8e looks cleaner than the remaining code [00:00:00 CET] --- Sun Mar 19 2017

1 0

ffmpeg.log.20170318
by burek 19 Mar '17

19 Mar '17

[00:12:54 CET] <faLUCE> is there any test program for mpegts+h264+aac ? [00:13:14 CET] <faLUCE> (I mean: test code example) [01:12:39 CET] <obamoose> hello [01:12:46 CET] <obamoose> how do I eternally loop a directory? [01:13:04 CET] <obamoose> streaming* [01:24:07 CET] <obamoose> anyone ;_;? [01:25:45 CET] <Threads> would be helpful if you could explain abit more on what you want todo [01:26:18 CET] <obamoose> https://ubuntuforums.org/showthread.php?t=2083105 [01:26:21 CET] <obamoose> basically this [01:26:30 CET] <obamoose> but I'm looking for an ffmpeg-native solution [01:26:46 CET] <obamoose> I'm streaming a directory using *.mp4 [01:26:53 CET] <obamoose> all files in that directory [01:27:04 CET] <obamoose> But I want it to start over when the last file has finished playing [03:33:21 CET] <Dark_Arc> I recently discovered that the Telegram messenger is not releasing its source code for their Android client, despite touting open source clients, and releasing under GPL. Said Android client is also statically linking against ffmpeg in violation of LPGL. What would be the best way to report this? [03:37:05 CET] <Dark_Arc> This is the offending repo: https://github.com/DrKLO/Telegram [03:37:27 CET] <Dark_Arc> Which is not up to date with the latest release https://play.google.com/store/apps/details?id=org.telegram.messenger&hl=en [03:43:45 CET] <relaxed> Dark_Arc: open a bug report and state your findings [06:46:33 CET] <thebombzen> Dark_Arc: if the code is GPLed then it can be statically linked against ffmpeg and comply with the LGPL [06:46:43 CET] <thebombzen> the issue is that they're not distributing the source code [08:00:10 CET] <lei-lhg> Hi,all.I was trying to build ffplay using bitbake. But it always complaint "SDL not found". [08:00:11 CET] <lei-lhg> | DEBUG: Executing shell function do_configure [08:00:13 CET] <lei-lhg> | ERROR: SDL not found [08:00:14 CET] <lei-lhg> In fact,I have run "bitbake -c install libsdl" successfully, I don't know why ffmpeg say "sdl not found" [08:00:16 CET] <lei-lhg> Did anyone have met this problem? [08:00:17 CET] <lei-lhg> any advice and suggestions will be greatly appreciated [08:12:11 CET] <aster__> what is libavresample? thanks [08:17:01 CET] <cableguy> team [08:17:12 CET] <cableguy> when trying no snatch something from the web with ffmpeg -i [08:17:15 CET] <cableguy> why is it so slow [08:17:22 CET] <cableguy> is it encoding at same time or something [08:18:06 CET] <cableguy> i was snatching this 4k video from some .m3u that contained the video in partial .ts files [08:18:14 CET] <cableguy> and it took 1h to snatch 20min video [08:18:31 CET] <cableguy> im not following [08:18:44 CET] <cableguy> no, its not the internet speed. [10:56:15 CET] <BtbN> cableguy, are you just stream copying, or transcoding? [10:56:28 CET] <BtbN> lei-lhg, ffplay needs SDL 2. [10:59:10 CET] <cableguy> BtbN, idk i just want to dl it to my hdd but looks like its transcoding it while in process [10:59:18 CET] <cableguy> so it takes too long [10:59:30 CET] <cableguy> but why transcode raw files if i also want them raw [10:59:44 CET] <BtbN> Because the default is to transcode [10:59:54 CET] <BtbN> stream-copy is a special case. [11:00:04 CET] <BtbN> Just add -c copy in front of your output, if you don't have it already. [11:01:50 CET] <cableguy> uh u mean '-c copy -i' [11:02:12 CET] <BtbN> It's an output option, not an input one. [11:03:40 CET] <cableguy> the input is .m3u with multiple streams [11:03:55 CET] <cableguy> does ffmpeg have a command like youtube-dl that lets to select which format u want to dl [11:03:59 CET] <cableguy> like -f format_code [11:04:08 CET] <BtbN> no, use youtube-dl for that. [11:04:19 CET] <BtbN> youtube-dl can even call ffmpeg for you I think. [11:04:23 CET] <cableguy> i tried using youtube-dl but it toggles ffmpeg instead [11:04:32 CET] <cableguy> and then in which part i pass ffmpeg commands [11:04:51 CET] <BtbN> there is no logic in ffmpeg to decypher the always varying magic all those video sites do [11:04:54 CET] <BtbN> Would be insane to add [11:04:58 CET] <BtbN> That's why youtube-dl exists [11:06:11 CET] <cableguy> what im saying is that if i run youtube-dl it calls ffmpeg to download from that .m3u but like you said ffmpeg transcodes by default [11:06:29 CET] <cableguy> so i cant put in ffmpeg commands in youtube-dl command line [11:06:34 CET] <cableguy> the -c copy [11:06:39 CET] <BtbN> I'm pretty sure youtube-dl correctly uses a stream copy. [11:06:52 CET] <furq> it doesd [11:06:53 CET] <furq> -d [11:07:02 CET] <cableguy> whats -d [11:08:18 CET] <cableguy> e.g. [11:08:37 CET] <cableguy> youtube-dl http://stream.m3u -f 123 [11:08:40 CET] <cableguy> it calls ffmpeg [11:08:44 CET] <cableguy> and ffmpeg starts transcoding [11:08:50 CET] <cableguy> but i want copy [11:08:54 CET] <BtbN> No it doesn't. [11:08:57 CET] <cableguy> yes it does [11:08:58 CET] <BtbN> It copies [11:09:11 CET] <cableguy> frame= 361 fps= 58 q=-1.0 Lsize= 26505kB time=00:00:14.91 bitrate=14556.1kbits/s speed=2.39x [11:09:17 CET] <cableguy> isnt this transcoding [11:09:25 CET] <furq> no [11:09:25 CET] <BtbN> No, that's the progress indicator. [11:09:45 CET] <cableguy> so why its so slow [11:09:49 CET] <cableguy> and speed drops beloe 0.5 [11:09:59 CET] <BtbN> Is anything else faster at downloading that stream? [11:10:00 CET] <furq> is it using any cpu [11:10:25 CET] <cableguy> yeah i can download at 10mb/s from that site e.g. mp4 files [11:10:32 CET] <cableguy> youtube-dl downloads fast, ffmpeg is slow [11:11:09 CET] <BtbN> What is the exact ffmpeg commandline? [11:11:10 CET] <cableguy> ffmpeg is like at 1% cpu [11:11:20 CET] <furq> yeah that's not transcoding [11:11:34 CET] <furq> it's not unheard of for streaming sites to throttle live streams [11:11:39 CET] <furq> although 0.5x sounds a bit suspicious [11:11:42 CET] <cableguy> idk whats ffmpeg cli youtube-dl just calls it [11:11:49 CET] <BtbN> look it up [11:11:55 CET] <BtbN> should be in ps aux while it's running. [11:12:13 CET] <cableguy> let me make screenshot [11:12:22 CET] <BtbN> it's plain text... just copy it [11:12:55 CET] <furq> youtube-dl -v will print the ffmpeg command line [11:14:48 CET] <cableguy> http://i.imgur.com/t0SX5Qt.jpg [11:15:00 CET] <BtbN> Why do you take a picture... of text?! [11:15:10 CET] <furq> also text that doesn't contain the command line [11:15:16 CET] <BtbN> also, the command line is not in there [11:15:52 CET] <furq> when you say "10mb/s" do you mean 10MB/s or 10mbps [11:15:54 CET] <cableguy> u mean [11:15:58 CET] <cableguy> -i /playlist.m3u8' -c copy -f mp4 -bsf:a aac_adtstoasc file:master-master.mp4.part [11:16:04 CET] <furq> if it's the latter than that video is 15mbps, so that's not really a mystery [11:16:10 CET] <cableguy> 10mb/s as in 100mbit [11:16:39 CET] <BtbN> Is that a live stream? [11:16:42 CET] <cableguy> no [11:16:53 CET] <BtbN> It will download however fast the server can sustain then [11:16:58 CET] <BtbN> And your Internet Connection, that is [11:17:11 CET] <cableguy> well its 10 faster from save server with youtube-dl or browser or whatever [11:17:18 CET] <cableguy> but ffmpeg is x10 times slower [11:17:24 CET] <cableguy> and speed constantly dropping [11:18:42 CET] <cableguy> e.g. i can download same file from same server in e.g. mp4 extension with e.g. youtube-dl and its fast 10mb/s, but when it comes to .m3u source and it calls ffmpeg in same server its slow and drops under 0.5 [11:20:02 CET] <BtbN> ffmpeg can easily download m3u8 sustaining my 200Mbit/s downstream for me. It's something on your end. Like slow disk, slow connection, or both [11:20:23 CET] <cableguy> its ssd [11:20:33 CET] <cableguy> and 100/100 [11:20:56 CET] <cableguy> like i said everything is fast except when it comes to ffmpeg downloading same file from same server but from .m3u [11:21:16 CET] <BtbN> So it's not the same file, but an m3u playlist? [11:21:40 CET] <BtbN> ffmpeg -i "http://sample.vodobox.net/skate_phantom_flex_4k/skate_phantom_flex_4k.m3u8" -c copy out.mp4 [11:21:54 CET] <BtbN> that easily uses up all available downstream bandwidth for me. [11:22:55 CET] <cableguy> frame= 998 fps= 39 q=-1.0 size= 33708kB time=00:00:40.03 bitrate=6898.1kbits/s speed=1.55x [11:23:49 CET] <cableguy> thats from ur link [11:26:53 CET] <cableguy> it starts at speed 7x and constantly dropping till 0.5 [11:27:50 CET] <cableguy> but if u open that .m3u and download one .ts chunk from browser or whatever no problem quick and fast [11:27:54 CET] <cableguy> while ffmpeg is choking on it [11:29:23 CET] <BtbN> of course on chunk is fast, any kind of throtheling will kick in much later. [11:30:03 CET] <BtbN> It runs at a constant 2-2.5x speed for me, around 7Mbps [11:41:23 CET] <cableguy> alright [11:50:57 CET] <jubalh> So I have amazon prime, and they have some nice series. But I cannot watch them on my kodi media station. Now I think about downloading them somehow. it seems there is a lib that can decode the drm stuff but noone implemented anything with it yet? [11:51:01 CET] <jubalh> https://github.com/rg3/youtube-dl/issues/1753 [11:51:19 CET] <jubalh> kind of offtopic to ffmpeg but maybe someone in here knows about it [11:51:40 CET] <jubalh> since also with audible ffmpeg could help to decode the thing with the activation bytes [11:51:59 CET] <BtbN> Amazons DRM is not broken, if that's your question. [11:52:06 CET] <BtbN> And if it was, they'd probably quickly fix it. [11:55:39 CET] <jubalh> tbh I dont know how this works but to play the video in firefox and chromium etc i guess those browsers have to encrypt the stream [11:55:55 CET] <jubalh> since those are open source i thought that the same technique could be used by other applications? [11:57:32 CET] <BtbN> They download a binary blob from the server, that then decrypts the stream and opens a protected channel to the graphics card, to ensure nothing can intercept the video on its way there. [11:58:21 CET] <BtbN> best bet at capturing those streams is an HDMI capture card with an HDCP stripper in front of it. [11:59:14 CET] <jubalh> what? it works like that. i had no idea. i would prefer not having such binaries here.. good thing i didnt install the plugin yet [11:59:29 CET] <BtbN> Browses don't need a plugin for that anymore [11:59:52 CET] <jubalh> or enabled that feature [12:00:29 CET] <BtbN> Chrome recently decided that it should not be possible to disable it anymore iirc [12:01:23 CET] Action: jubalh uses Firefox [12:01:32 CET] <jubalh> with what reasoning? [12:02:40 CET] <BtbN> http://www.tomshardware.com/news/chrome-57-permanently-enabled-drm,33527.ht… [12:06:20 CET] <jubalh> interesting, thanks [12:11:58 CET] <cableguy> that top comment tho [12:39:17 CET] <furq> 10:51:59 ( BtbN) Amazons DRM is not broken, if that's your question. [12:39:21 CET] <furq> it has been broken and they did quickly fix it [15:11:17 CET] <kcghost> I have a quick question regarding the "tune" option in x264: https://trac.ffmpeg.org/wiki/Encode/H.264 [15:11:40 CET] <kcghost> For presets it says "you will simply save bitrate by choosing a slower preset." [15:12:08 CET] <kcghost> Does the same logic hold true for the tune parameter? e.g. When using crf 18? [15:12:22 CET] <kepstin> kcghost: most of the tune options are just minor tweaks to help with certain types of content, that hurt other types of content [15:12:40 CET] <kepstin> (exceptions are psnr, ssim, zerolatency which are only used in special cases) [15:13:00 CET] <kepstin> if you don't know why you might want to use a tune, you probably don't want to use a tune. The defaults are generally ok for most stuff. [15:14:43 CET] <kcghost> I was thinking of attempting to autodetect a proper tune. If the constant quality logic is true, then tune only affects filesize, and you could try a clip at different tunes and go with the one with the smallest size. [15:14:53 CET] <furq> it isn't [15:15:04 CET] <furq> film will generally increase bitrate, and grain will increase it even more [15:15:37 CET] <furq> animation will generally reduce bitrate (iirc) but it'll do so for live-action content as well [15:15:41 CET] <furq> which will make it look worse [15:15:59 CET] <kcghost> Good to know, thanks [15:19:47 CET] <furq> at crf 18 it might not be worth worrying about [15:19:54 CET] <furq> obviously given enough bitrate the tuning makes no difference [15:20:19 CET] <furq> it's just a way of biasing the bitrate allocation you do give it in a particular way [15:23:03 CET] <kcghost> Ah, so at crf 18 only the presets would affect the filesize and not tune? Or just that tune would make a very small difference at crf 18? [15:23:27 CET] <furq> tune will make less difference at lower crf [15:23:40 CET] <furq> it'll probably still be noticeable at 18, i've never checked [15:23:55 CET] <furq> obviously at -qp 0 then it makes no difference at all because that's lossless regardless [15:24:29 CET] <furq> it definitely makes a noticeable difference at 20, and i've never really touched anything lower [15:25:26 CET] <user128> hi, I am looking at https://github.com/FFmpeg/FFmpeg/blob/master/ffplay.c but I can't figure out the part where the audio is actually send to SDL for playing. any tips? [15:43:32 CET] <BtbN> user128, i don't think it sends audio to SDL [16:04:22 CET] <user128> BtbN, I see. I wonder how ffplay is sending audio to the sound card. I see calls to "pa_stream_write" in the debugger but I don't see them in ffplay source. need to spend more time looking at source! [16:04:38 CET] <user128> pa_stream_write is pulseaudio api function [16:04:40 CET] <BtbN> It'll probably just use lavd [16:07:12 CET] <user128> debugger says calls to pulseaudio functions are coming from PULSEAUDIO_PlayDevice <- SDL_RunAudio. so sdl does seem to be involved in the audio playback. [16:07:52 CET] <BtbN> So if you have a trace, you can just see where it comes from [16:08:51 CET] <user128> the problem is that this takes places in a different thread, I can see the ffplay code involved clearly. I will debug more, thanks! [17:49:35 CET] <mabynogy> hello [19:16:36 CET] <obamoose> Hello [19:16:54 CET] <obamoose> I'm using a 'while do do done' loop to loop a directory [19:17:03 CET] <obamoose> but it stops and starts a new stream every time it's done with a file [19:17:14 CET] <obamoose> can't I make it a single full stream? [19:25:21 CET] <BtbN> If the files are similar enough, you can just use a concat last as input [19:27:49 CET] <obamoose> extension similar? [20:05:35 CET] <MR-2> Hello [20:05:40 CET] <MR-2> :) [20:07:49 CET] <MR-2> how can i fix malformed pts/dts issues on a mp4. Last 35mins of it is dumped in the last 1-2sec right now:/ [20:07:52 CET] <MR-2> ? [20:20:32 CET] <c3r1c3-Win> MR-2: Did you try a simple remux? [20:29:43 CET] <MR-2> i have tried -c copy [20:31:58 CET] <MR-2> don't work [20:33:41 CET] <MR-2> really weird issue:/ [20:34:54 CET] <MR-2> first 90min works great but then te last 1-2sec has like 30-35min smoshed into it [20:50:36 CET] <Spring> is there anything I should keep in mind to always ensure proper audio sync when encoding to h264? I've realized the method I've been using produces out of sync audio /slightly/ [20:54:36 CET] <Spring> looking at the ffmpeg encoding options that I added to the metadata for reference I used both -ss/-to and -filter_complex with trim/atrim (set to the same beginning/end values). [20:55:07 CET] <BtbN> If your inputs have proper timestamps, there's usually nothing you have to do. [20:56:57 CET] <Spring> BtbN, any idea why h264 in particular has slightly off-sync'd audio, while libvpx doesn't using the same trim method described above? [20:57:32 CET] <BtbN> h264 is a video codec, it is not involved with audio. [20:58:24 CET] <BtbN> I'd guess h264 uses re-ordering, while VP9 doesn't, and the delay introduced by that clashes with your wonky input timestamps [20:58:40 CET] <Spring> sorry, should have specified, Mp4 with h264 and (vanilla) 'aac' for the audio [20:58:58 CET] <BtbN> to test, add -tune zerolatency to libx264, that disables any reordering and delays [20:59:12 CET] <JEEB> as long as your input timestamps are OK and you are not funkying with the timestamps that come from the encoders [20:59:16 CET] <JEEB> mp4 should be OK [20:59:22 CET] <JEEB> it should even have the audio encoder delay [20:59:41 CET] <JEEB> like, noted in the file. whether your player or whatever is decoding it reads it correctly is a separate thing [21:00:33 CET] <Spring> in this case I was taking the A and B trim timecodes from a video player (HH:MM:SS.MSS) for the timestamp values of the trims to give to ffmpeg. [21:00:57 CET] <BtbN> what? [21:01:25 CET] <BtbN> just don't mess with the timestamps unless they are broken, and stuff will just work [21:01:56 CET] <Spring> eg: -ss 00:02:44.641 -to 00:03:40.893 -filter_complex [0:v]scale=iw:ih,trim='00\:02\:44.641':'00\:03\:40.893'[v];[0:a]atrim='00\:02\:44.641':'00\:03\:40.893'[a] -map [v] -map [a] [21:07:26 CET] <Spring> hmm, maybe it's the source and I'm mistaking the lip syncing as being off. Will need to test with more sources. [21:11:54 CET] <BtbN> why are you adding the trim and atrim filters? [21:13:49 CET] <CptnOblivious> Hello, I'm trying to record a live stream but I'm getting errors every few minutes saying segments skipped. The video plays back but those skipped segments cause audio to stop through playback. Is there anyway to clean the file up? [21:15:29 CET] <Qas> hello everyone, I am using this command 'for f in *.flv; do ~/Downloads/ffmpeg-3.2.4-64bit-static/ffmpeg -i "$f" "${f%.*}.mp4"; done' in order to bulk convert flv files into mp4, but I get an error that says '*.flv: no such file or directory'. [21:16:36 CET] <Qas> sorry I will reconnect [21:16:54 CET] <Spring> BtbN, I believe it was as it was more accurate and the -ss/-to was to speed up skipping to the desired start point, or something like that. The complex filter also bit gets optional parts added to as necessary, some of which need the trim/atrim filter. [21:17:44 CET] <Qas> back again [21:18:05 CET] <BtbN> Qas, no -c copy? [21:18:15 CET] <BtbN> Also, your shell wants to tell you there there are no .flv files to be found. [21:18:26 CET] <Qas> BtbN, but there are. [21:18:51 CET] <Qas> I mean, I wanted to search recursively all subfolders, and there are flv files in them [21:18:55 CET] <BtbN> Your shell disagrees, and is usually right about that. [21:19:08 CET] <BtbN> that's not what you told your shell to do [21:19:18 CET] <BtbN> you told it to enumerate all files ending in .flv in the current directory. [21:19:38 CET] <Qas> I want to convert them to mp4 [21:20:23 CET] <BtbN> you should add -c copy and -movflags faststart for that [21:22:33 CET] <Qas> so, like 'for f in *.flv; do ~/Downloads/ffmpeg-3.2.4-64bit-static/ffmpeg -i -c -movflags "$f" "${f%.*}.mp4' ? [21:26:35 CET] <Qas> that returns error, too [21:27:42 CET] <Qas> could anyone help me with the right command please? I dont know why it doesnt work now, last time it didi [21:27:45 CET] <Qas> did* [21:33:04 CET] <BtbN> Because there are no .flv files in the directory where you run it [21:33:20 CET] <BtbN> Also you forgot half of the arguments I mentioned [21:33:46 CET] <BtbN> and put them in a strange place... [21:36:07 CET] <Qas> then where is the right place? [21:36:41 CET] <BtbN> not between -i and the input file... [21:37:02 CET] <BtbN> But still after -i, as they are output options [21:39:02 CET] <Qas> to make it clear, I dont know a thing about all these commands. I got them here and there and it worked before. therefore I dont know where to put them. if someone can tell it to me straight away, I'd be thankful. that's why I am here [21:41:53 CET] <BtbN> Well, I told you two times now why the original command does not work. [21:42:04 CET] <BtbN> There simply are no .flv files where you are running it [22:11:13 CET] <Qas> I am running it in directory1. and directory1 has subdirectories which contain flv files, which is what I wanted to do; apply the command to all subdirectories. [22:11:39 CET] <__jack__> how deep is the tree ? [22:11:47 CET] <Qas> 2-3 levels [22:12:07 CET] <__jack__> use find -iname "*.flv" -exec ffmpeg -i {} blablabla \; [22:12:27 CET] <Qas> I'd like to convert flv to mp4 [22:14:25 CET] <__jack__> use find -iname "*.flv" -exec ffmpeg -i {} -c copy -movflags faststart {}.mp4 \; [22:19:46 CET] <hiihiii> Hello. What's the proper wat to encode libx264 in RGB? I know about libx264rgb and have done it once but still do not know what are the sufficient switches to do it [22:21:12 CET] <furq> that is the switch to do it [22:21:46 CET] <__jack__> you're welcome qas .. [22:22:28 CET] <hiihiii> furq: so nothing else other than -c:v libx264rgb is needed? [22:22:38 CET] <hiihiii> ok thx [22:24:16 CET] <hiihiii> now should I switch to using RGB or stick to YUV? I'm not sure what is the pros or cons that RGB might bring? [22:26:30 CET] <BtbN> Well, I kind of like most players being able to play the video I encode. [22:26:47 CET] <BtbN> h264 with rgb in it will probably cause quite a mess [22:27:11 CET] <Qas> sorry, I was instantly cut off as I had a machine problem. [22:30:24 CET] <hiihiii> BtbN: not really sure about that but ok [22:35:46 CET] <furq> rgb is a bit bigger in my experience [22:37:15 CET] <BtbN> than yuv444? [22:37:27 CET] <furq> yeah [22:37:35 CET] <hiihiii> the only thing I know is that yuv is better in terms of compression [22:37:47 CET] <BtbN> yuv420 is obviously smaller [22:38:05 CET] <BtbN> But for 444 it's just a matter of how well the algorithm handles it [22:38:20 CET] <hiihiii> they feel as they if they have a yellow tint no? [22:38:27 CET] <BtbN> no? [22:39:12 CET] <hiihiii> idk I did some clips with yuv and then rgb. rgb came on top because of that yellowish tint yuv had [22:39:25 CET] <furq> sounds like something's fucking up the conversion [22:39:27 CET] <furq> or your player sucks [22:39:51 CET] <thebombzen> yuv444p should work just as well as rgb24 in theory [22:40:06 CET] <thebombzen> but I can imagine an encoder having better algorithms for yuv than rgb [22:40:39 CET] <hiihiii> I still have those clips if you like a screen shot [22:41:16 CET] <hiihiii> yuv was done with sony vegas' youtube preset [22:42:17 CET] <furq> that sure sounds like something that'd fuck up a colourspace conversion [22:43:22 CET] <hiihiii> rgb was done with ffmpeg [22:43:46 CET] <hiihiii> I don't think my player sucks be cause I can play the clip in raw [22:44:20 CET] <hiihiii> the ffmpeg clips were closer to the colors of raw than vegas' yuv clips [22:46:44 CET] <hiihiii> vega's out put : [22:47:22 CET] <hiihiii> https://thepasteb.in/p/xGhmkqQy116FM [22:47:32 CET] <hiihiii> ffmpeg's output: [22:47:38 CET] <hiihiii> https://thepasteb.in/p/KOh8Oxrl1BptJ [22:47:53 CET] <hiihiii> oh it was yuv420 for vegas [22:49:40 CET] <furq> do both with ffmpeg if you want to compare [22:50:01 CET] <furq> vegas isn't even using the same encoder [22:50:49 CET] <hiihiii> I might do that some day [22:51:01 CET] <hiihiii> i don't have enoug time today [22:51:13 CET] <hiihiii> but even with diff encoders [22:51:26 CET] <hiihiii> the algorithms are similar no? [22:51:27 CET] <furq> i mean the encoder shouldn't make a difference because that doesn't do the conversion [22:51:57 CET] <furq> but if you're noticing a colour shift after an rgb to yuv conversion then it's probably a bad conversion [22:52:17 CET] <furq> yuv444 and rgb should very rarely look perceptibly different [22:52:39 CET] <hiihiii> okay I'll just run some tests tomorrow and see what's on [22:52:49 CET] <hiihiii> take care [23:50:25 CET] <nyuszika7h> even if I do -r 25 on input and output, and -x264-params 'force-cfr=1', MediaInfo insists that the output file is variable frame rate [23:50:52 CET] <JEEB> you'd have to see what mediainfo actually reads for that information [23:51:29 CET] <JEEB> with some containers it has some weird ideas of what's CFR and what's not [23:51:58 CET] <JEEB> if you absolutely need to know, you actually use a timestamp tool to extract the timestamps from the container [23:52:49 CET] <nyuszika7h> well, it seems to be fine but I don't know why it thinks it's VFR [23:53:22 CET] <JEEB> you can just confirm it from the timestamps as I said, whatever mediainfo says being secondary [23:53:34 CET] <JEEB> if you see that the timestamps are monotonically rising [23:53:42 CET] <JEEB> then that's CFR no matter how you look at it [23:55:08 CET] <thebombzen> if you use force-cfr=1 with x264 it probably will encode the H.264 bitstream as cfr but if it's muxed as vfr then you're SOL [23:55:15 CET] <thebombzen> what happens if you use -vsync cfr [23:55:34 CET] <thebombzen> that'll tell the muxer that it's cfr, whereas x264-params is an encoder thing, not a muxer thing [23:56:05 CET] <JEEB> well first of all I recommend seeing if he has a problem at all [23:56:13 CET] <JEEB> before sticking more params at it [23:56:16 CET] <thebombzen> lol [23:56:37 CET] <thebombzen> I thought the problem was "I need mediainfo to report cfr" [23:56:41 CET] <thebombzen> otherwise /shrug [23:56:51 CET] <JEEB> mediainfo can be a very useful tool but you cannot trust its heuristics blindly [23:57:03 CET] <JEEB> and he already had -r 25 on both sides of his chain it seems [23:57:07 CET] <thebombzen> hm [23:57:08 CET] <nyuszika7h> well it's not a big deal because I can't see any issues with the output file, I'm just trying to find out why [23:57:10 CET] <JEEB> so any input timestamps would have already gotten rewritten [23:57:34 CET] <thebombzen> sure, but afaik by default ffmpeg.c will use vfr for vfr containers even if it ends up being cfr [23:57:34 CET] <JEEB> nyuszika7h: plain and simply if the timestamps are monotonically rising then mediainfo's just plain wrong [23:57:43 CET] <thebombzen> monotonically increasing? [23:57:48 CET] <thebombzen> that just means nondecreasing [23:57:52 CET] <thebombzen> doesn't mean cfr [23:57:58 CET] <JEEB> well derivate being stable I mean [23:58:07 CET] <JEEB> as in, monotonic amount of rise between samples :P [23:58:17 CET] <thebombzen> still doesn't mean cfr [23:58:30 CET] <JEEB> ok, so how the fuck else do you define CFR then? [23:58:34 CET] <thebombzen> the word monotonic has nothing to do with this [23:58:39 CET] <JEEB> if all timestamps have monotonically rising timestamps [23:58:45 CET] <thebombzen> that's not what monotonic means [23:58:48 CET] <JEEB> ok [23:58:59 CET] <thebombzen> https://en.wikipedia.org/wiki/Monotonic_function [23:59:09 CET] <JEEB> if each sample has exactly the same duration [23:59:11 CET] <JEEB> there [23:59:29 CET] <thebombzen> I mean the easiest way to describe it is the difference between consecutive timestamps is constant [23:59:50 CET] <JEEB> yes, that's another word for duration [00:00:00 CET] --- Sun Mar 19 2017

1 0

ffmpeg-devel.log.20170317
by burek 18 Mar '17

18 Mar '17

[00:45:42 CET] <ubitux> wow i'm impressed at the asan report [00:46:24 CET] <ubitux> http://sprunge.us/ZQHc this is cute [00:48:34 CET] <JEEB> is that gcc or clang asan? [00:49:34 CET] <ubitux> gcc [01:04:20 CET] <wm4> Assertion !c->frac && !c->dst_incr_mod && !c->compensation_distance failed at libswresample/resample.c:391 [01:04:21 CET] <wm4> heh [01:04:23 CET] <wm4> who broke it [01:04:51 CET] <wm4> that happens when I start mpv with current git master [01:04:56 CET] <wm4> *ffmpeg git master [01:05:13 CET] <jamrial> maybe the recent patch that enabled linear inter and extact rational [01:05:20 CET] <jamrial> by default, that is [01:05:25 CET] <jamrial> 1f7eb216b085cfd4f18f328182cabe3f89093edd [01:05:28 CET] <cone-551> ffmpeg 03wm4 07master:b4b8ca24f624: avcodec: fix uninitialized variable read [01:05:36 CET] <jamrial> try disabling those [01:06:27 CET] <nevcairiel> if they can assert, should turn that off again until fixed [01:06:49 CET] <wm4> setting exact_rational to 0 "fixes" it [01:07:37 CET] <jamrial> reply to the relevant thread on ffmpeg-devel and point this out [01:07:52 CET] <wm4> this is probably due to avresample_set_compensation() or something [01:07:54 CET] <jamrial> if Muhammad Faiz or michaelni can't fix it in the short term then that commit should be reverted [01:18:06 CET] <jamrial> wm4: swr_set_compensation() :P [01:20:28 CET] <wm4> oops [01:20:29 CET] <wm4> yes [01:20:39 CET] <wm4> my code is compatible to both swr and lavr [01:20:46 CET] <wm4> it #defines lavr names for swr [04:00:24 CET] <cone-551> ffmpeg 03Muhammad Faiz 07master:3ba7b47d5cb4: swresample/resample: do not assert compensation_distance on rebuild_filter [05:41:40 CET] <wm4> does anyone want to review this? some Libav changes for frame threading, and also allowing enabling threads for hwaccel decoding: https://github.com/wm4/FFmpeg/commits/thread-merge [05:42:05 CET] <wm4> there are weird differences between lock use in ffmpeg and libav, so I guess I have no idea what I'm doing [05:43:42 CET] <wm4> it appears to work, but that means nothing if threads are involved [09:18:00 CET] <kierank> BtbN: you can write one of those trivially [09:38:58 CET] <mateo`> i'm working on merging the next commit (0638b99cdb) [10:06:16 CET] <rcombs> are there any guarantees about AVFrame data and linesize alignments [10:07:59 CET] <nevcairiel> yes [10:08:29 CET] <nevcairiel> although there is one exception, if you decode rawvideo it may just map the packet into avframe without re-aligning it [10:08:33 CET] <nevcairiel> not sure if that was ever fixed [10:08:58 CET] <rcombs> what's the alignment [10:10:26 CET] <nevcairiel> 32 if build with AVX, 16 otherwise [10:11:17 CET] <rcombs> ah, so from mem.c [10:11:37 CET] <nevcairiel> avcodec/internal.h has STRIDE_ALIGN with the same things [10:11:43 CET] <wm4> uh [10:11:46 CET] <wm4> the alignment is random [10:11:54 CET] <wm4> the one who allocates the AVFrame can set it [10:12:12 CET] <wm4> so, I'm not sure what filters will do to it [10:12:14 CET] <nevcairiel> i assumed he talked about libav* internally allocated frames [10:12:29 CET] <rcombs> oh, I meant what lavc encoders and lavfi filters expect [10:12:44 CET] <wm4> e.g. if you use vf_crop, it could unalign the start pointer [10:12:45 CET] <rcombs> like, can lavfi code assume a particular alignment? [10:12:51 CET] <nevcairiel> giving it 32 aligned stuff for avx is always safe either way [10:13:00 CET] <rcombs> I know [10:13:07 CET] <rcombs> I'm asking if lavfi makes any assumptions about it [10:13:26 CET] <wm4> so I'd say any align should work (modulo tons of bugs), but 32 bytes should be safest [10:13:52 CET] <rcombs> like, does any lavfi or lavc code take a frame and do e.g. movdqa from it [10:14:13 CET] <nevcairiel> probably [10:14:14 CET] <wm4> they shouldn't [10:14:15 CET] <rcombs> obv being <mmsize> aligned is optimal for perf [10:14:20 CET] <wm4> (but maybe do) [10:14:22 CET] <rcombs> but does not being mmsize-aligned break things? [10:14:54 CET] <nevcairiel> surprisingly the random lavfi code i opened uses movu and not mova [10:15:30 CET] <rcombs> afaik movu isn't actually slower than mova on aligned data, right? [10:15:44 CET] <nevcairiel> to summarize, try to output aligned things w hen you can, but don't assume it is aligned on input data, i guess [10:16:05 CET] <nevcairiel> and yeah i believe the difference is minimal at best on modern cpus [10:16:14 CET] <rcombs> assuming unaligned just means you can't use SSE instructions that take input directly from memory [10:16:45 CET] <nevcairiel> at worst do what sws does and fallback to super-slow-c-mode when input isnt aligned [10:17:14 CET] <nevcairiel> (although sws being sws, i'm sure it still crashes) [10:40:54 CET] <Gramner> the penalty for unaligned memory accesses is significanlty lower on modern cpus than it used to be, but that doesn't mean that you shouldn't try to avoid it. the exact penalty varies between cpu archs, and depending on what boundaries it crosses. page split > cacheline split > within cacheline [10:41:51 CET] <rcombs> Gramner: I meant the penalty for using movdqu (as opposed to movdqa) in the data-is-aligned case [10:41:52 CET] <nevcairiel> the more important question is how bad is using movu for safety, if the data is aligned most of the time [10:41:57 CET] <rcombs> yeah [10:42:07 CET] <Gramner> movu is identical to mova on modern cpus when used on aligned data [10:42:20 CET] <rcombs> cool, so when in doubt, movu [11:01:39 CET] <wm4> Gramner: and that's how it should have been from the start [11:01:48 CET] <wm4> silly cpu designers [11:02:46 CET] <rcombs> and SSE doesn't allow unaligned access in non-movu instructions, but AVX does, right? [11:50:23 CET] <mateo`> another pair of eyes to review the merge commit before i merge it ? https://github.com/mbouron/FFmpeg/commit/ad87f71a4768193cd3b8c4cf6469d0ad36… [11:52:19 CET] <cone-610> ffmpeg 03Konda Raju 07master:2db5ab73d43a: avcodec/nvenc: allow different const-qps for I, P and B frames [12:16:39 CET] <cone-610> ffmpeg 03Anton Khirnov 07master:8db301deadfc: ffmpeg: set the encoding framerate when the output is CFR [12:16:40 CET] <cone-610> ffmpeg 03Tobias Rapp 07master:205b8fd078e5: avcodec: estimate output bitrate for uncompressed video codecs [12:47:41 CET] <cone-610> ffmpeg 03Diego Biurrun 07master:0638b99cdba5: aiff: Skip padding byte for odd-sized chunks [12:47:42 CET] <cone-610> ffmpeg 03Matthieu Bouron 07master:e2adbcbd97de: Merge commit '0638b99cdba52554691fc668d9e477bc184c7a33' [13:01:15 CET] <michaelni> ubitux, do you have a example of a filter command thats not bit exact for thomas ? [13:02:44 CET] <ubitux> mmh owdenoise? [13:03:50 CET] <ubitux> otherwise a random list of filters that probably arent either: lut3d, nlmeans, dctdnoiz, selectivecolor [13:04:16 CET] <ubitux> michaelni: http://ffmpeg.org/pipermail/ffmpeg-devel/2013-May/143810.html [13:04:28 CET] <ubitux> concrete example of non bitexact [13:05:15 CET] <ubitux> a command is given here [13:15:35 CET] <Gramner> rcombs: correct, only VEX-encoded (and EVEX for that matter) instructions support unaligned addresses. AMD had (or still has? no idea) some functionality where you could set a bit in some control reg and legacy-coded instructions would support it as well, but it was kind of annoying to use since it was a global flag and some poorly coded libraries would clobber it causing headaches [13:17:32 CET] <michaelni> ubitux, thx [13:24:31 CET] <atomnuker> "Hi sir, it takes me a great hornor for you to read my letter on your spare time." <- a GSoC applicant [13:24:48 CET] <atomnuker> 0 points if you guess where they're from [13:26:36 CET] <DHE> well don't leave us in suspense... [13:29:22 CET] <atomnuker> "I will spare no effort to make it successfully if I become the lucky dog." [13:29:45 CET] <kierank> wtf [13:30:45 CET] <J_Darnley> Well there is probably a lot of competition for thing in countries of 1 billion plus people [13:31:04 CET] <J_Darnley> So I guess they often use that level of politeness [13:37:41 CET] <michaelni> atomnuker, you should not quote private mail on a publically logged channel unless you have the consent of the author (dont know if yu have) [13:40:56 CET] <iive> atomnuker: japan? [13:41:27 CET] <atomnuker> I'm sure they're far from unique for a letter of this type (and a given century) [13:42:10 CET] <iive> you mean, country ;) [13:43:24 CET] <atomnuker> not necessarily, you need both the time and space to be able to describe where something is [13:46:09 CET] <wm4> michaelni: my patch will be applied, and I will fight for it [13:47:43 CET] <Compn> you guys hating on that country again [13:50:52 CET] <Compn> wm4 : arguing about policy is the least fun thing to do in the project :( [13:53:28 CET] <wm4> I'm not the one who's adding terrible hacks for obscure/nonsense reasons [13:53:39 CET] <wm4> which the side data merging exactly is [13:56:21 CET] <Compn> oh this is new battle, nevermind , i was looking at old thing [13:56:22 CET] Action: Compn hides [13:57:15 CET] <wm4> yes, we always have to have battles for this [14:01:54 CET] <nevcairiel> the framework excuse is a farce, you cant just put random data into media buffers and send it through a generic framework, because there could be non-avcodec components at the end. and if you only have avformat/avcodec stuff, you dont need a generic framework [14:04:57 CET] <iive> atomnuker: the earth continents doesn't move so fast, so you rarely need to type When something is. ;) [14:16:59 CET] <atomnuker> wm4: supposing that side data gets merged into the main packet and gets transmitted via like rtp or something [14:17:12 CET] <atomnuker> the receiver can misinterpret the side data as part of the main packet, right? [14:17:42 CET] <atomnuker> (particularly messing up the total size of the packet) [14:21:24 CET] <BBB> atomnuker: did you get that also? [14:21:31 CET] <BBB> atomnuker: I got that exact email [14:22:00 CET] <BBB> ndiswrapper etc. ;) [14:22:20 CET] <BBB> the experience that I participated a project involved in ndiswrapper [14:23:11 CET] <BBB> its probably poor habit to make fun of peoples language, but this is really hard to decipher& [14:23:59 CET] <atomnuker> ndiswrapper was a big thing 12ish years ago [14:24:23 CET] <atomnuker> (I think?) [14:24:31 CET] <atomnuker> suprising that crazy idea worked at all [14:25:11 CET] <J_Darnley> Now that I've sent those patches I can go run some errands. [14:25:24 CET] <iive> running windows wifi driver under linux [14:30:17 CET] <BBB> J_Darnley: Im not sure avx is worth the trouble in cases where its 1.0x as fast as sse2... [14:30:29 CET] <BBB> (e.g. idct8_add4) [14:31:03 CET] <BBB> J_Darnley: also what does broken FATE mean? is that a comment [14:32:13 CET] <nevcairiel> +; FIXME: I produce incorrect output [14:32:14 CET] <nevcairiel> :D [14:33:15 CET] <J_Darnley> Yeah. The patch doesn't work. It does something wrong and makes the decoder produce incorrect output, hence "broken FATE". [14:33:44 CET] <J_Darnley> BBB: yeah, feel free to object and block any patches which provide no speed up. [14:34:13 CET] <J_Darnley> I didn't push two deblock patches which were not any faster. [14:34:16 CET] <BBB> maybe if it breaks fate its not such a great idea ;) [14:34:27 CET] <J_Darnley> Only that one patch [14:34:28 CET] <BBB> or does that mean please help me figure out why its not working"? [14:34:36 CET] <J_Darnley> Also a little of that. [14:34:38 CET] <J_Darnley> :) [14:35:06 CET] <J_Darnley> But I am leaving for now so I will deal with that later. [14:35:09 CET] <BBB> hehe ok [14:35:12 CET] <BBB> later [14:35:16 CET] <J_Darnley> Sayonara [14:37:50 CET] <kierank> J_Darnley: i'm sure you're aware since you did the stats that some of your functions have dubious speedups [14:38:36 CET] <BBB> I have no idea what that code is trying to do, why create -d? and the upper half of the xmm register is not ever filled (xmm=16bytes=8words, youre loading 1 word and doing two punpcklwd which fills 4 words) [14:39:01 CET] <BBB> try to use the splat macros or something like that [16:28:55 CET] <rcombs> so allegedly, new Rockchip hardware can decode H.264 High 10 [16:32:57 CET] <JEEB> rcombs: surprising [16:33:18 CET] <rcombs> same [16:33:23 CET] Action: kierank makes sure to send 422 [16:33:26 CET] <kierank> so hardware decoders fail [16:33:28 CET] <JEEB> :D [16:33:40 CET] <JEEB> "it's all about the pentiums, baby" [16:35:07 CET] <rcombs> it's all about the A7s now [16:35:37 CET] <atomnuker> I wonder if its bitexact [16:35:54 CET] <rcombs> is H.264 bit exact? [16:36:39 CET] <atomnuker> I mean to a reference [16:36:59 CET] <rcombs> I mean, is decoding bitexact? [16:39:01 CET] <atomnuker> that's the whole point of having specifications [16:40:30 CET] <rcombs> I mean, e.g. MP3 has specifications but decoding it isn't bit-exact [16:41:11 CET] <BBB> rcombs: h264 decoding is bitexact, yes [16:41:16 CET] <BBB> its not like the old mpeg days [16:41:21 CET] <rcombs> OK, good to know [16:41:27 CET] <BBB> rcombs: decoding of hevc, vp8/9, etc. is also bitexact [16:41:46 CET] <rcombs> but not MPEG-4 Part 2, or MPEG2/1? [16:41:50 CET] <BBB> correct [16:42:32 CET] <BBB> rcombs: audio is indeed fundamentally not bitexact, which becomes self-evident if you imagine that the most popular way to represent audio samples nowadays is float [16:42:45 CET] <BBB> and therefore audio codecs are usually not requires to be bitexact either [16:42:52 CET] <nevcairiel> unless you use lossless codecs of course [16:42:56 CET] <rcombs> hey, float can be bit exact if you're a masochist [16:43:17 CET] <BBB> lossless codecs then again are not float-based ;) [16:43:23 CET] <nevcairiel> they can be! [16:43:30 CET] <nevcairiel> als has a crazy float mode [16:43:38 CET] <atomnuker> float is bitexact, its just that the C specs do not forbit using a higher precision float intermediates which breaks it [16:43:44 CET] <atomnuker> *forbid [16:43:53 CET] <jamrial> BBB: ALS apparently is to some extent :p [16:44:12 CET] <jamrial> ah, nevcairiel beat me to it [18:19:30 CET] <TD-Linux> video codecs became bitexact more out of necessity - reconstruction error would build up and destroy the image [18:33:57 CET] <uu8> hi [18:34:28 CET] <uu8> can someone tell me what the wd variable is at ffmpeg project [18:34:37 CET] <uu8> where it is declared? [18:35:28 CET] <uu8> ***where is it declared? [18:36:22 CET] <Compn> uu8 : in codec? demuxer ? [18:40:28 CET] <uu8> hmm [18:40:43 CET] <uu8> in codec [18:41:19 CET] <uu8> i tried to use grep to find the declaration but failed [18:41:58 CET] <uu8> may be i do not have enough c knowledge to understand such a project but... [18:43:26 CET] <uu8> or assembly [18:44:04 CET] <Compn> where are you seeing wd? error ? patch ? output ? [18:44:15 CET] <Compn> just trying to figure out where you are finding this variable :) [18:44:36 CET] <uu8> @Compn : at source [18:45:37 CET] <Compn> in what file ? sometimes wd means width , but i cant guarentee... [18:45:38 CET] <uu8> in libavcoded/x86/dirac_dwt.asm [18:45:45 CET] <Compn> ahhh diract [18:45:50 CET] <Compn> -t [18:46:30 CET] <Compn> so you're talking about like this , mov w2d, wd [18:46:41 CET] <Compn> yeah thats assembly [18:47:14 CET] <uu8> yeah :185 [18:51:37 CET] <Compn> that should be a standard cpu instruction for x86 [18:52:24 CET] <jkqxz> It's not a variable called "wd", it's a variable called "w" being used with doubleword width. [18:54:05 CET] <nevcairiel> assembly doesnt really have the concept of "variables", its just named registers (or sometimes stack space) [19:35:53 CET] <feliwir> BBB: i was told that you can explain me this: https://github.com/FFmpeg/FFmpeg/blob/967feea5ebb744dce97ab327d33502b43fca0… [19:36:21 CET] <feliwir> and also how the entire VLC stuff is working in ffmpeg. I know how Huffman works, but ffmpeg is calling this VLC stuff everywhere [19:36:35 CET] <feliwir> (when creating Huffman Trees etc.) [19:38:33 CET] <BBB> whats your specific question? [19:38:41 CET] <BBB> please explain this is too broad, I cant answer that [19:46:23 CET] <atomnuker> feliwir: are you asking how the vlc codes reader works? [19:52:17 CET] <feliwir> because the huffman decoding is the part i am missing for my own vp6 decoder [19:52:31 CET] <feliwir> and the reference implementation libvp62 doesn't support it [19:57:00 CET] <feliwir> atomnuker, why were you asking? [19:57:57 CET] <atomnuker> just asking, its unusual for someone to be writing a decoder for a format not used seriously in a decade [19:58:51 CET] <feliwir> atomnuker, well to be fair the specification is from 2006 :) I am mostly writing it because i am trying to rewrite an old game engine in C# (which used vp6 for videos) [19:59:18 CET] <feliwir> https://github.com/feliwir/sage/tree/master/vp6 [19:59:26 CET] <cone-527> ffmpeg 03Vittorio Giovara 07master:21a8e751ad6a: fate: Do not report side data size [19:59:27 CET] <cone-527> ffmpeg 03Vittorio Giovara 07master:f20bcec4c2b1: spherical: Change types of bounding and pad to uint32_t [19:59:36 CET] <feliwir> also it is interesting to see that C# doesn't perform as bad as i've expected [20:00:39 CET] <atomnuker> feliwir: which game? [20:01:06 CET] <durandal_1707> i know the answer but will not tell it for free [20:01:34 CET] <Compn> who bulgarian here ? [20:01:34 CET] <atomnuker> please tell me its the first and only need for speed most wanted [20:01:40 CET] <JEEB> lol [20:02:04 CET] <atomnuker> it had hilarious vp6 greenscreened full motion videos [20:02:08 CET] <Compn> er nevermind thats hungaruan... [20:02:22 CET] <atomnuker> "First I'm going to take your ride, then I'm going to take your girl!" [20:07:54 CET] <atomnuker> only command and conquer 3 fits the time frame [20:15:40 CET] <uu8> hey thanks for the answers [20:30:29 CET] <cone-527> ffmpeg 03Vittorio Giovara 07master:95a72aed764a: mov: Drop extra format specifier in error message [20:32:23 CET] <feliwir> sorry, my bouncer keeps dcing me [20:32:37 CET] <feliwir> did BBB already answer my question atomnuker ? [20:33:24 CET] <BtbN> * feliwir has quit (Excess Flood) [20:33:42 CET] <BtbN> your bnc does not disconnect you. Freenode kicks you for spamming them [20:34:11 CET] <Compn> uu8 : why are you learning assembly? working on a bug in dirac ? [20:34:28 CET] <feliwir> BtbN, what am i spamming? [20:34:40 CET] <BtbN> no idea [20:34:45 CET] <BtbN> It's your BNC, not mine [20:34:59 CET] <BBB> feliwir: I did not see a question [20:35:09 CET] <Compn> he means "excess flood" which is such a confusing quit message... :P [20:35:31 CET] <feliwir> BBB, i was asking about huffman decoding in vp6. atomnuker told me you were the right for asking about that [20:35:50 CET] <BtbN> well, it means your connection sent so much data to freenode that the server decided it's too much and kicked you [20:35:54 CET] <Compn> [14:35] <feliwir> BBB: i was told that you can explain me this: https://github.com/FFmpeg/FFmpeg/blob/967feea5ebb744dce97ab327d33502b43fca0… [20:35:54 CET] <Compn> [14:36] <feliwir> and also how the entire VLC stuff is working in ffmpeg. I know how Huffman works, but ffmpeg is calling this VLC stuff everywhere [20:35:54 CET] <Compn> [14:36] <feliwir> (when creating Huffman Trees etc.) [20:35:54 CET] <Compn> [14:38] <BBB> whats your specific question? [20:35:54 CET] <Compn> [14:38] <BBB> please explain this is too broad, I cant answer that [20:37:18 CET] <feliwir> sorry, didn't get that :) [20:38:03 CET] <feliwir> well i don't understand how ffmpeg creates a huffman tree. The first parts make perfect sense where it sorts the nodes by probabilities [20:38:29 CET] <feliwir> but then i starts calling some VLC functions, which are simply huge macro blocks [20:41:04 CET] <feliwir> this is the part i have replicated so far: https://github.com/feliwir/sage/blob/master/vp6/Huffman.cs#L61 But from then i don't understand what FFmpeg is doing anymore. Also it would be nice to know what get_vlc2 is doing [20:41:42 CET] <BBB> get_vlc2() is simply an optimized function for getting VLC codes [20:42:06 CET] <BBB> if you want to understand what it does, look at it; if you simply want to replicate what it does in a simpler way, its easier to implement your own [20:42:20 CET] <BBB> the function is hard because its optimized for speed, not readbility [20:42:47 CET] <BBB> the input to get_vlc2() is the VLC table, which is initialized elsewhere [20:43:00 CET] <BBB> the VLC table init stores codes, code length and respective values [20:43:05 CET] <feliwir> yeah it's initialized in huffman_create [20:43:15 CET] <BBB> thats really all there is to know; once you know that, its trivial to reimplement [20:43:27 CET] <BBB> probably not immediately at the same optimization level as get_vlc2(), but fucntionally identical [20:43:38 CET] <feliwir> but i don't know what VLC is at all. Never heard that term and documentation in ffmpeg is poor on it [20:43:50 CET] <BBB> if you want fast code, just copy the relevant code from ffmpeg without understanding it (or maybe just copy the whole vp6 decoder; I dont quite see the point in reimplementing it) [20:43:57 CET] <BBB> oh I see [20:44:00 CET] <BBB> VLC is variable length code [20:44:03 CET] <BBB> its like a tree [20:44:06 CET] <BBB> a binary tree [20:44:06 CET] <feliwir> well i can't copy it into C# [20:44:13 CET] <BBB> if you have a sequence of bits 011100001111& [20:44:16 CET] <BBB> what does that mean? [20:44:24 CET] <BBB> if you have a 1 bit element, you simply take 1 bit and its 0/1 [20:44:35 CET] <BBB> if you have a nbit element, you read n bits and make an integer from it [20:44:39 CET] <BBB> variable length is a tree [20:44:48 CET] <BBB> e.g. 0 means a, 10 means b, 11 means c [20:44:52 CET] <feliwir> my decoder is written in C#, and i can't use some macro functions there like ffmpeg does, so i am basically required to understand how it works :) [20:45:11 CET] <BBB> and usually variable length coding trees are longer than just 3 elements [20:45:49 CET] <BBB> so the tree (from init) maps sequences of 0/1 bits of a particular length to actual values [20:46:12 CET] <BBB> and get_vlc2() then reads bitstream values against the sequence+lengths from the table and returns the specified value for that sequence/length pair [20:46:35 CET] <BBB> its variable length because 0, 10 and 11 arent all sequences of the same length (0 is 1 bit, 10/11 are 2 bits) [20:47:55 CET] <BBB> huffman coding is a typical strategy for dynamically modifying the variable length coding tree/table (whether in the frame header or as part of the bitstream specification based on symbol entropy) [20:48:10 CET] <BBB> the result is typically that symbols with higher occurence have a smaller sequence length [20:48:27 CET] <BBB> so that the number of bits requires to code the stream of symbols decreases ( = better compression) [20:48:40 CET] <BBB> and techniques that accomplish that are called huffman optimizations [20:48:55 CET] <BBB> michaelni knows more about technical aspects of that than I do [20:49:08 CET] <BBB> but I suppose I know the general idea behind it [20:49:15 CET] <BBB> I gotta run, brb in 15 min or so [21:14:37 CET] <BBB> feliwir: I still think you should consider using C code directly and just copy ffmpeg code& c# has native code and allows linking against native C code also& re-writing obscure codecs like vp6 is somewhat wasteful IMO unless youre actually interested in it [21:17:20 CET] <atomnuker> just compile with --disable-everything --enable-decoder=vp6 and keep an ffmpeg repo as a git submodule [21:17:27 CET] <atomnuker> that's what rpcs3 and ppsspp do [21:18:02 CET] <JEEB> for some reason hw said that C#'s FFI was awful or something [21:18:05 CET] <JEEB> *he [21:20:30 CET] <feliwir> BBB, i am using .NET core which is cross platform [21:20:43 CET] <feliwir> and with C code i would require native binaries for each platform [21:21:05 CET] <BBB> you need that anyway [21:21:12 CET] <BBB> unless you dont want SIMD code and everything is mega-slow [21:21:42 CET] <BBB> (which you basically dont want) [21:22:32 CET] <nevcairiel> yeah video decoding is not something you can just do cross-platform without effort [21:22:35 CET] <nevcairiel> or its sloooow [21:23:07 CET] <feliwir> BBB, well not like C# doesn't make use of SIMD [21:23:36 CET] <BBB> cross platform and simd dont mix [21:23:59 CET] <feliwir> well C# introduced System.Numerics namespace which is basically SIMD for C# [21:24:14 CET] <BBB> Im gonna get liboil nightmares [21:24:22 CET] <BBB> sure, do as you please [21:24:37 CET] <feliwir> i'll try atleast :) [21:25:34 CET] <BtbN> sounds like numpy for C# [21:27:03 CET] <feliwir> well C# is faster than python by default [21:27:18 CET] <BBB> his point is that numpy isnt simd [21:27:33 CET] <BBB> numpy is just an higher-level integer manipulation utility [21:27:42 CET] <BBB> it allows things like regressions, matrices/vectors, etc. [21:27:47 CET] <BBB> and possibly uses simd for some of that [21:27:56 CET] <BBB> but thats not the same as making simd platform-independent [21:27:56 CET] <feliwir> it even states that System.Numerics is meant for SIMD abstraction [21:28:06 CET] <BBB> since most operations wont be accessible and will thus revert back to being scalar [21:28:39 CET] <BBB> also see aut-vectorization [21:28:41 CET] <feliwir> apart from that where does vp6 make use of SIMD? [21:28:44 CET] <BBB> (its a compiler feature) [21:28:50 CET] <BtbN> Granted, C# pretty much only needs to care about ARM and x86_64 [21:28:50 CET] <feliwir> the most function i saw so far are plain C [21:29:27 CET] <BBB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/x86/vp6dsp.asm;h=… [21:29:38 CET] <BBB> not much, I agree [21:29:52 CET] <BBB> theres http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/x86/vp56_arith.h;… [21:29:56 CET] <nevcairiel> vp6 is probably old and simple enough to actually work in pure C if you had to [21:30:33 CET] <BBB> we have significant simd for vp3 [21:31:28 CET] <BBB> vp6 also uses videodsp, vp3dsp and hpeldsp [21:31:37 CET] <BBB> I believe all of these are fairly well-optimized [21:31:58 CET] <BBB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/x86/hpeldsp_vp3.a… [21:32:08 CET] <BBB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/x86/hpeldsp.asm;h… [21:32:25 CET] <BBB> videodsp: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/x86/videodsp.asm;… [21:32:36 CET] <BBB> and vp3dsp: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/x86/vp3dsp.asm;h=… [21:33:10 CET] <BBB> whether playback of vp6 without simd is tolerable depends on how big the file is (datarate/sec, resolution, fps, etc.) and also on what type of machine you plan to use for playback [21:41:08 CET] <feliwir> well, my files are mostly low res (300*300px) [22:08:18 CET] <feliwir> BBB, .NET native might interest you: https://blogs.msdn.microsoft.com/dotnet/2017/01/30/announcing-net-core-net-… [22:08:29 CET] <feliwir> also with impressive examples [22:09:21 CET] <BBB> sorry Im really not the right person for that type of languages [22:09:28 CET] <BBB> I generally dont care the least about languages [22:09:39 CET] <BBB> I dont udnerstand the fuzz about them, theyre all the same [22:10:26 CET] <atomnuker> I still remember installing .net framework 4.0 for ati drivers on win xp x64 which seriously took around 4 hours [22:11:06 CET] <BtbN> Wasn't XP already quite dead by the time .NET 4 came to be? [22:12:39 CET] <atomnuker> then it was some older version [22:13:14 CET] <atomnuker> 3.0 probably [22:14:00 CET] <feliwir> .NET core is the future. It can compile to native binaries and there is no need for a preinstalled framework at all. Also it is much faster than that .NET framework garbage [22:15:02 CET] <atomnuker> its name is still stained for me after waiting 4 hours for an error message to fix which it was easier to reinstall windows [22:16:06 CET] <BtbN> .NET can and does compile to native binaries for quite some time now [22:16:08 CET] <JEEB> feliwir: so it builds a fat binary with the parts of framework in it that you're using for ARM/ARM64/intel32/intel64? [22:16:32 CET] <JEEB> because otherwise you're losing the "runs fukken everywhere" part of it [22:16:35 CET] <feliwir> JEEB, no when i want to do that i specify the platform & architecture [22:16:47 CET] <BtbN> No, it just natively compiles the framework as well, and has that as a dependency. [22:16:50 CET] <feliwir> well i am not required to that if i don't wish [22:17:10 CET] <feliwir> the framework is shipped as shared libraries in that case like BtbN said [22:17:23 CET] <BtbN> But .NET does that since almost a decade [22:17:27 CET] <BtbN> That's nothing new [22:17:31 CET] <feliwir> BtbN, on linux & mac? [22:17:36 CET] <BtbN> No, on Windows. [22:17:51 CET] <feliwir> well .Net core does it anywhere :P [22:18:01 CET] <BtbN> So running on more than windows is new [22:18:05 CET] <BtbN> but natively compiling is not. [22:18:19 CET] <feliwir> never tried it with .NET framework [22:18:32 CET] <BtbN> It does it implicitly, and caches the binaries somewhere [22:18:38 CET] <BtbN> but you can also tell it to give you a native .exe [22:18:42 CET] <feliwir> but i never saw a standalone .NET framework application [22:18:44 CET] <BtbN> then it pre-compiles [22:18:52 CET] <BtbN> It does not turn standalone [22:18:56 CET] <BtbN> it still depends on the framework [22:20:07 CET] <feliwir> so .NET framework still needs to be available on the target computer? [23:49:12 CET] <cone-090> ffmpeg 03Carl Eugen Hoyos 07master:9e6b269fea26: lavc/avcodec: Constify AVBitStreamFilter* in AVBitStreamFilterContext struct. [00:00:00 CET] --- Sat Mar 18 2017

1 0

ffmpeg.log.20170317
by burek 18 Mar '17

18 Mar '17

[00:00:04 CET] <iive> oh, he said it is fragmented above ... [00:00:48 CET] <iive> can ffmpeg muxer create fragmented mp4? it does support hls,so i guess it does. [00:00:49 CET] <JEEB> which is why I said what I said [00:00:56 CET] <iive> yeh. [00:01:01 CET] <JEEB> yes, movenc.c can do fragmented isobmff [00:01:04 CET] <JEEB> I use it daily [00:01:31 CET] <JEEB> also libavformat has a dashenc.c for MPEG DASH which utilizes movenc's fragmented ISOBMFF muxing capabilities [00:02:46 CET] <IntruderSRB> btw. I've finally got my hands on properly encrypted HLS/fMP4 combination that works natively in Safari [00:03:05 CET] <IntruderSRB> now I'm inspecting nal units produced by them and same nal units produced by mine encryptor... [00:03:14 CET] <IntruderSRB> hex is my friend... [00:03:18 CET] <JEEB> iive: -movflags frag_keyframe for on-IRAP fragmentation :P [00:03:33 CET] <JEEB> IntruderSRB: yes binary diff tools are love [00:03:52 CET] <IntruderSRB> I came from web development world .... we had postman and JSON [00:03:52 CET] <JEEB> vbindiff is what I used when making the Ut Video encoder when debugging failing test cases :3 [00:04:23 CET] <IntruderSRB> got Hex Fiend .... does the job right [00:04:33 CET] <IntruderSRB> not many features but all I need is compare :D [00:07:00 CET] <JEEB> ok, dropbox can now officially fuck off [00:07:08 CET] <JEEB> my old straight links no longer work >:| [00:07:44 CET] <JEEB> so I have no reason to host those things there any more (to keep old links alive) [00:08:29 CET] <IntruderSRB> lol [01:16:40 CET] <Sparkyish> Looking for help with multiple audio channels. I need to create a file that contains audio from the first 4 mono channels on an SDI/HDMI input. The output shouldn't have any audio manipulation (the kind which happens when using a 5.1 surround sound profile). Any direction? I've tried reading about pan, but I can't figure out a good command to make this work. [01:18:07 CET] <JEEB> I think you only need audio channel mapping [01:21:16 CET] <Sparkyish> JEEB, doesn't mapping create separate streams? If I understand the terminology correctly, I need a single stream with 4 active channels so that they all play at once (via SDI output) [01:22:07 CET] <JEEB> Sparkyish: -map yes, but I meant that there's a filter (the name of which I don't remember) which will let you select tracks and make one N channel track out of them [01:53:03 CET] <Sparkyish> JEEB: could it be -ac:[stream specifier] that you are thinking of? [01:54:47 CET] <IntruderSRB> btw. can someone confirm that ffmpeg -c copy copies exact copy of H264 nal units - it doesn't do Annex B conversion in the meantime [01:54:48 CET] <IntruderSRB> ? [02:09:55 CET] <IntruderSRB> hm ... -c copy with and without "-vbsf h264_mp4toannexb" produces same result [02:10:21 CET] <IntruderSRB> should I assume that in mp4 it's really annexb or -c copy implicitly uses "-vbsf h264_mp4toannexb" anyway? [02:24:07 CET] <iive> i could speculate that annex b is needed for fragments [02:24:23 CET] <iive> aka, it copies each extradata headers inside the video bitstream [02:24:51 CET] <iive> just a speculation... [02:34:05 CET] <thebombzen> IntruderSRB: h264_mp4toannexb changes how the frames are packed. certain streaming formats like mpegts require a different sort of thing than mp4 [02:34:29 CET] <thebombzen> however, my best guess is that you're getting the same behavior because this bsf is auto-inserted where relevant [02:34:40 CET] <thebombzen> so even if you don't specify -bsf:v it's still there [02:34:56 CET] <IntruderSRB> thebombzen: yes - thing is I have an fmp4 that I need to inspect and ffmpeg -c copy I see annexB (bitstream) [02:35:14 CET] <IntruderSRB> so I was wondering if it was already there or since I asked pure h264 ffmpeg added it anyway [02:35:35 CET] <IntruderSRB> but yea ... it was inserted by ffmpeg ... [02:36:27 CET] <IntruderSRB> weird thing is it addes leading_zero_8bits in front of any Access Delimiter NALU [02:36:36 CET] <thebombzen> "Please note that this filter is auto-inserted for MPEG-TS (muxer "mpegts") and raw H.264 (muxer "h264") output formats." - The documentation. [02:36:38 CET] <IntruderSRB> but doesn't add zero_byte in front of SPS and PPS [02:36:47 CET] <thebombzen> other than that [02:36:57 CET] <thebombzen> I can't really say anything b/c I don't exactly know how it works [03:21:42 CET] <AnonBaiter> hi [03:21:46 CET] <AnonBaiter> so, I have more samples from me [03:29:48 CET] <jinihm> Has anyone tried installing ffmpeg with nvenc support on Jetson TX1? I definitely have Cuda installed but when I try to install ffmpeg, it says "ERROR: nvenc requrested, but not all dependencies are satisfied: cuda" [03:45:22 CET] <jinihm> also it tries to compile some files like "window.h" that only exist on windows while my machine is ubuntu [03:50:00 CET] <memeka> hi; i have 2 ffmpeg installs - one in /usr one in /usr/local; both using shared libs; but both /usr/bin/ffmpeg and /usr/local/bin/ffmpeg use the same shared libav libraries (from /usr/lib); is there a way to point /usr/local/bin/ffmpeg to /usr/local/lib/libav* without LD_LIBRARY_PATH? [03:59:31 CET] <AnonBaiter> here is a sample [03:59:31 CET] <AnonBaiter> https://www.sendspace.com/file/a586wg [04:02:38 CET] <AnonBaiter> this sample was obtained from all three console versions(PS2, GC, XBOX) of Tiger Woods PGA Tour 2003. [04:45:24 CET] <memeka> hi; how do i specify device output to ffplay? e.g. xv, opengl, ... ? [04:52:20 CET] <memeka> anyone? [05:09:04 CET] <AnonBaiter> hi [12:06:44 CET] <Drazick> Hello. Anyone here? [12:08:19 CET] <Drazick> I have new user question. What's the difference between `-r` and `-framerate` in general and in the context of creating videos from still images? [14:20:08 CET] <faLUCE> hello, given rawH264EncodedVideo.h264, how can I split it into multiple files (one file per frame) ? [14:31:52 CET] <utack> is there a way for the "benchmark" mode to store minimum fps? [14:31:55 CET] <utack> isntead of average [15:50:45 CET] <nicomachus> hi all. I have about 50 video files (.mkv) that have multiple audio and multiple subtitle tracks embedded in the video. 3/4 audio are Russian and 1/2 subs are Russian, the other 1 of each is English. Can I use ffmpeg to re-encode them keeping only the english audio and sub tracks, without losing quality? [15:51:53 CET] <DHE> yes, you can use -c copy and clever use of -map to select the english tracks [15:52:26 CET] <nicomachus> I found some guides online about that but I wasnt sure about how it would work with multiple tracks [15:54:42 CET] <nicomachus> and I'm guessing this will be a bit CPU intensive. :) [15:54:44 CET] <DHE> when you use -map you're forcing your own selection of tracks rather than using ffmpeg's default selections. you'll have to include 3 - one for video, one for audio and one for subtitles. [15:54:53 CET] <DHE> no. copying streams tends to be disk intensive [15:55:31 CET] <nicomachus> ah. well disk is better than CPU when it comes to this HTPC. and I'm guessing it shouldn't be hard to set up a `for` loop to do it all in a batch? [15:58:15 CET] <DHE> should be, as long as all the videos are about identical. all have a subtitle track available in english, all have an audio track available in english, etc. [16:00:41 CET] <nicomachus> yea it's 5 seasons of a tv show. 10 episodes each. All from the same source. [16:15:09 CET] <nicomachus> ok I'm not sure about this -map option. If I have multiple audio streams, and I only want to keep the third one, do I do `-map 0:0:1:0` or `-map 0:3`? [16:16:01 CET] <nicomachus> well, I guess it counts subs as "streams" too, so I want to keep stream 3 and 6. [16:18:33 CET] <DHE> read the manual. there are more complex matches, including language selection. [16:18:53 CET] <DHE> or if "ffprobe" always shows the streams in the same order, then you can use "0:3" notation as indicated [16:22:04 CET] <nicomachus> yea I'm looking at the man page, the -map section just isn't all that clear for me, I guess. especially when it comes to working with multiple streams [16:26:38 CET] <nicomachus> yep, I did something wrong... Kept both audio and sub tracks I wanted, but didn't keep video. Lol [16:26:54 CET] <nicomachus> whoops... round 2 [19:33:26 CET] <feliwir> hey, can someone explain this function simplified: https://github.com/FFmpeg/FFmpeg/blob/967feea5ebb744dce97ab327d33502b43fca0… [19:33:50 CET] <feliwir> i know how huffman works, the VLC table stuff that ffmpeg is doing there is confusing me a lot [19:34:32 CET] <feliwir> also when the huffman tree is created there is some VLC stuff going on (which is a complete undocumented part of ffmpeg...) [19:35:07 CET] <atomnuker> feliwir: ask BBB on #ffmpeg-devel [19:35:46 CET] <feliwir> okay, i'll try [20:34:35 CET] <obamoose> hello [20:34:41 CET] <obamoose> how do I turn this into an infinite loop? [20:34:47 CET] <obamoose> find /home/me/cgn -name "*.mp4" | xargs -I $ ffmpeg -y -re -i $ -vcodec libx264 -preset veryfast -maxrate 3000k -bufsize 6000k -pix_fmt yuv420p -g 50 -c:a aac -b:a 160k -ac 2 -ar 44100 -f flv rtmp://a.rtmp.youtube.com/live2/my_id [20:35:06 CET] <obamoose> http://pastebin.com/dNFKjLfW [20:35:20 CET] <furq> by not using xargs for starters [20:35:58 CET] <furq> https://trac.ffmpeg.org/wiki/Concatenate [20:36:15 CET] <furq> you probably want the demuxer or the filter if you want the client to not drop out at file boundaries [20:36:32 CET] <furq> as for looping it forever, you probably want the loop filter [20:36:34 CET] <furq> !filter loop [20:36:34 CET] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#loop [20:39:47 CET] <obamoose> this is a lot of information [20:39:48 CET] <obamoose> thank you [20:44:10 CET] <obamoose> furq: okay I'm super confused [20:44:49 CET] <obamoose> furq: I want to loop a folder [20:45:08 CET] <obamoose> play all files -> play all files -> play all files -> play all files etc. [22:57:14 CET] <AnonBaiter> is there any way I can compile ffmpeg on windows xp? [22:57:43 CET] <__jack__> winxp ? common man, be serious [22:58:47 CET] <AnonBaiter> windows xp [22:59:02 CET] <AnonBaiter> i still use it through virtualbox [22:59:18 CET] <AnonBaiter> or are you going to adapt to anti-comsumer tactics? [23:02:29 CET] <AnonBaiter> I`m not in the mood to use windows 10 just to decode a file, you know [23:02:56 CET] <AnonBaiter> but at least I have debian wheezy now [23:19:40 CET] <Kadigan> AnonBaiter: there are ready-made binaries for Windows, but I don't think Windows XP is supported. [23:19:59 CET] <Kadigan> I mean, come on - I was unable to compile ffmpeg on Windows 7. What makes you think you'll have more luck on XP? [23:20:28 CET] <Kadigan> (granted, my inability to compile it on Windows was probably heavily influenced by my general ineptitude compiling linux-stuff on Windows...) [23:31:23 CET] <furq> the zeranoe builds don't support xp because of libmfx [23:31:31 CET] <furq> i'm not aware of anything else that'll prevent it from working [23:32:47 CET] <AnonBaiter> so you`re saying it`s not possible to compile ffmpeg on windows xp? [23:33:19 CET] <BtbN> Not caring about an ancient OS is not Anti-Consumer. It's just self-protection. [23:33:46 CET] <BtbN> It might work, but nobody tests it or will fix bugs if there are any. [23:34:39 CET] <rob0> I didn't see anyone say it wasn't possible to compile on XP. [23:35:21 CET] <rob0> It's just that no one else cares. [23:38:20 CET] <AnonBaiter> oops [23:39:08 CET] <Fenrirthviti> windows xp support was dropped back in 2014, there are 0 legitimate reasons left to still be using it. And no, ancient software that only works there isn't a legitimate reason. [23:40:12 CET] <AnonBaiter> so I have to use anything that`s not ancient regardless of how well they have aged? [23:40:26 CET] <AnonBaiter> or how badly they have aged, I must say... [23:40:30 CET] <Fenrirthviti> ...what? XP has not aged well at ALL. [23:40:39 CET] <Fenrirthviti> XP was terrible when it was still current. [23:40:53 CET] <AnonBaiter> even with the games you could play on it? [23:41:17 CET] <Fenrirthviti> There is not a single game you can run on XP that doesn't work on modern OS's with minor tweaking. None. [23:41:29 CET] <rob0> Entitlement [23:41:40 CET] <AnonBaiter> I mean games released during the XP era [23:42:00 CET] <Fenrirthviti> What does that have to do with anything? [23:42:35 CET] <__jack__> maybe AnonBaiter want to use ffmpeg to record an old game ? [23:42:39 CET] <AnonBaiter> well... [23:42:43 CET] <AnonBaiter> at least i have linux [23:42:51 CET] <AnonBaiter> but i have trouble installing ffmpeg on linux [23:43:02 CET] <__jack__> AnonBaiter: which linux ? [23:43:08 CET] <__jack__> which distribution [23:43:08 CET] <AnonBaiter> debian wheezy [23:43:11 CET] <AnonBaiter> wait [23:43:32 CET] <AnonBaiter> https://tracker.debian.org/pkg/ffmpeg [23:43:36 CET] <AnonBaiter> yeah that`s the one [23:44:18 CET] <Fenrirthviti> what issues are you having? compiles fine on my wheezy box [23:44:25 CET] <furq> wtf are you using wheezy for [23:44:36 CET] <furq> do you have some policy of only using abandoned operating systems [23:44:38 CET] <BtbN> well, at least it still has a tiny bit of support... [23:44:45 CET] <BtbN> Wheezy is still in LTS [23:45:18 CET] <Fenrirthviti> my wheezy box runs my arcade machine so I have no reason to update it :P [23:45:40 CET] <AnonBaiter> mine is a amd64 [23:45:49 CET] <furq> he said "at least i have wheezy now" so i assumed he had just installed it [23:45:55 CET] <furq> in which case, what the fuck are you doing [23:46:16 CET] <__jack__> what the furq are you doing, AnonBaiter ? [23:46:18 CET] Action: __jack__ runs [23:46:32 CET] Action: rob0 was thinking the same thing :) [23:46:33 CET] <AnonBaiter> trying to find a way to run ffmpeg on debian wheezy? [23:46:42 CET] <AnonBaiter> I changed my plans [23:47:02 CET] <BtbN> from running super ancient software to very ancient one? [23:47:22 CET] <rob0> __jack__, our minds are seriously furqed up. [23:47:36 CET] <__jack__> rob0: :3 [23:47:48 CET] <Fenrirthviti> ffmpeg should be available as a package in security on wheezy [23:47:53 CET] <furq> jessie at least has ffmpeg in backports [23:48:12 CET] <furq> stable distros are dumb though [00:00:00 CET] --- Sat Mar 18 2017

1 0

ffmpeg-devel.log.20170316
by burek 17 Mar '17

17 Mar '17

[01:04:54 CET] <kierank> atomnuker: seen that http://src.infinitewave.ca/ [01:05:16 CET] <cone-541> ffmpeg 03Michael Niedermayer 07master:45198477de19: avcodec/simple_idct_template: Fix several integer overflows [01:05:17 CET] <cone-541> ffmpeg 03Michael Niedermayer 07master:58e9c7f4a2fd: avcodec/wavpack: Fix multiple integer overflows [01:05:18 CET] <cone-541> ffmpeg 03Michael Niedermayer 07master:cfa10e11be4c: avcodec/tiff: Check palette shift [01:20:11 CET] <cone-541> ffmpeg 03Martin Storsjö 07master:25bacd0a0c32: Don't use expressions with side effects in macro parameters [01:20:12 CET] <cone-541> ffmpeg 03Martin Storsjö 07master:014773b66bdf: libavutil: Use an intermediate variable in AV_COPY*U [01:20:13 CET] <cone-541> ffmpeg 03Martin Storsjö 07master:230b1c070baa: intreadwrite: Add intermediate variables in the byteswise AV_W*() macros [01:20:14 CET] <cone-541> ffmpeg 03James Almer 07master:eedb44a605ce: Merge commit '25bacd0a0c32ae682e6f411b1ac9020aeaabca72' [01:20:15 CET] <cone-541> ffmpeg 03James Almer 07master:4708f978902b: Merge commit '014773b66bdff4de24f384066d1a85d2a5bb6774' [01:20:16 CET] <cone-541> ffmpeg 03James Almer 07master:916dff9cb102: Merge commit '230b1c070baa3b6d4bd590426a365b843d60ff50' [01:32:27 CET] <cone-541> ffmpeg 03Martin Storsjö 07master:f79d847400d2: intreadwrite: Use the __unaligned keyword on MSVC for ARM and x86_64 [01:32:28 CET] <cone-541> ffmpeg 03James Almer 07master:30fe4b8d4ce2: Merge commit 'f79d847400d218cfd0b95f10358fe6e65ec3c9c4' [01:34:50 CET] <cone-541> ffmpeg 03Martin Storsjö 07master:9806b9ab5c7f: Revert "Don't use expressions with side effects in macro parameters" [01:34:51 CET] <cone-541> ffmpeg 03Martin Storsjö 07master:fc94a1acc27a: Revert "libavutil: Use an intermediate variable in AV_COPY*U" [01:34:52 CET] <cone-541> ffmpeg 03James Almer 07master:86fb169df589: Merge commit '9806b9ab5c7fb2ac5efd8ffa8713fea0c5fd218d' [01:34:53 CET] <cone-541> ffmpeg 03James Almer 07master:8c0aacf0ec77: Merge commit 'fc94a1acc27ab7296edce3fa81ef36691af5c134' [01:37:12 CET] <cone-541> ffmpeg 03Diego Biurrun 07master:e723dce6f8ba: dvbsubdec: Use NULL instead of 0 as pointer value [01:37:13 CET] <cone-541> ffmpeg 03James Almer 07master:f073b2da8410: Merge commit 'e723dce6f8ba1e8260433b6ecfe5a3262f4c7a99' [01:39:19 CET] <cone-541> ffmpeg 03Diego Biurrun 07master:3ccec334b850: sbrdsp: Move a misplaced #endif directive to the right spot [01:39:20 CET] <cone-541> ffmpeg 03James Almer 07master:e298497f0c6e: Merge commit '3ccec334b8502701e72ef13bed25913c3578022e' [01:41:36 CET] <uau> jamrial: any reason to make separate merge commits for all those? even the consecutive merges that didn't change the tree? [01:42:29 CET] <wm4> maybe it's easier [01:42:32 CET] <jamrial> uau: never did single merge for several commits, so not sure how [01:42:48 CET] <jamrial> wm4: well, less prone to failure at least [01:42:50 CET] <uau> it's not any different? [01:43:03 CET] <nevcairiel> easier to keep track of things, and special casing a few special cases seems like extra effort not really worth it [01:43:04 CET] <uau> i mean you generally merge an arbitrary other tree [01:43:23 CET] <uau> whether it has one or more commits that do not exist in your current tree doesn't really make it any different [01:43:35 CET] <jamrial> also, i can reference the commit in our tree that already changed the code the merge would otherwise affect [01:44:05 CET] <nevcairiel> its usually a good idea to write down why a commit was skipped, indeed [01:45:10 CET] <uau> nevcairiel: in this case "merge -s ours COMMIT" with a message containing "skip, these were reverted in libav" should communicate everything relevant though [01:45:44 CET] <nevcairiel> perhaps, but its safer to just stick to the same pattern for all of them, i guess [01:45:45 CET] <cone-541> ffmpeg 03Michael Niedermayer 07master:e5b019725f53: m4vdec: Check for non-startcode 00 00 00 sequences in probe [01:45:46 CET] <cone-541> ffmpeg 03Anton Khirnov 07master:d3e4d406b020: h264dec: reset nb_slice_ctx_queued for hwaccel decoding [01:45:47 CET] <cone-541> ffmpeg 03James Almer 07master:67817468d3fd: Merge commit 'e5b019725f53b79159931d3a7317107cbbfd0860' [01:45:48 CET] <cone-541> ffmpeg 03James Almer 07master:65ff562c3b30: Merge commit 'd3e4d406b020b0464486318aceda08bd8f69ca41' [01:45:52 CET] <nevcairiel> such cases are extremely rare either way [01:46:27 CET] <wm4> did anyone look at the frame thread atomics changes yet? and the hwaccel threading patches? [01:49:46 CET] <jamrial> uau: so basically, git merge -s ours --no-commit HASH1 && git merge -s ours --no-commit HASH2 && git commit? [01:50:07 CET] <nevcairiel> nah, just use the hash of the last hash in the series [01:50:07 CET] <uau> jamrial: no, just the second [01:50:23 CET] <jamrial> ok, will keep that in mind [01:50:25 CET] <uau> you merge all changes in the given tree which don't already exist in your current one [01:50:34 CET] <uau> not individual commits [02:09:22 CET] <cone-541> ffmpeg 03Christophe Gisquet 07master:3c504bc3599f: x86: deduplicate some constants [02:09:23 CET] <cone-541> ffmpeg 03James Almer 07master:e632fe9babe9: Merge commit '3c504bc3599f00bfc5923adc114beef34bce11d0' [02:18:34 CET] <cone-541> ffmpeg 03James Almer 07master:63ac8e2d9308: lavu: add LOCAL_ALIGNED_32 [02:18:35 CET] <cone-541> ffmpeg 03Anton Khirnov 07master:89aebc5bcc6e: lavc: align the linesize to 32 when AVX is enabled [02:18:36 CET] <cone-541> ffmpeg 03James Almer 07master:b5122b040fe9: Merge commit '63ac8e2d93080b74f6be32c7c3c1a1e44aacf34e' [02:18:37 CET] <cone-541> ffmpeg 03James Almer 07master:6c4665deb4d2: Merge commit '89aebc5bcc6e23a0a79c3f51c3a55c3571692ba0' [02:23:20 CET] <jamrial> ubitux: there, cleared some of the backlog [02:23:39 CET] <jamrial> a lot of vp9 commits cherry picked from our tree circa 2013 come next [02:24:29 CET] <jamrial> imo, just noop them all and don't even bother checking if they made cosmetic changes [03:05:29 CET] <wm4> jamrial: definitely, BBB maintains his vp9 decoder well [03:05:34 CET] <wm4> you'd probably just add bugs [03:06:05 CET] <jamrial> that, plus these are four years old commits, so even cosmetic differences would probably not even apply [06:11:35 CET] <wm4> wasn't there something about sox being faster than swr? [06:11:53 CET] <wm4> because someone just posted some more swr optimizations [08:00:29 CET] <cone-551> ffmpeg 03Rostislav Pehlivanov 07master:911417f0b34e: ffmpeg: don't use resample_lavr_opts [08:17:57 CET] <TD-Linux> wm4, no there was this https://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/207981.html [08:18:41 CET] <TD-Linux> that looks like aliasing at like -75db, if that can be repeated that's pretty bad quality from swr [08:19:15 CET] <wm4> oh [08:22:15 CET] <TD-Linux> I would really expect the default to be closer to the noise floor of 16 bit audio (-96db) [08:29:38 CET] <wm4> why is -96db the noise floor of 16 bit audio? [09:23:13 CET] <memeka> hi; i have been playing around with some patches that add v4l2 encoder/decoder support to ffmpeg and i have some issues with encoding: while in 3.0.2 it works well, in 3.2.4 I lose the fps information from output file, I get like all frames in the clip in 1 second kind of, e.g. ffmpeg -i encoded.mp4 looks like: Stream #0:0(und): Video: h264 (Main) (avc1 / [09:23:13 CET] <memeka> 0x31637661), yuv420p, 1280x720, 868799 kb/s, 12800 fps, 12800 tbr, 12800 tbn, 25600 tbc (default) ----- 12800fps! (input was 25fps) .... [09:23:43 CET] <memeka> was there anything changed regarding encoding fps between 3.0 and 3.2 ?? [09:23:53 CET] <memeka> that could affect this? [09:25:43 CET] <memeka> i also get: "[mp4 @ 0x7f69b960] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly" and "[mp4 @ 0x7f69b960] Encoder did not produce proper pts, making some up." -- but i was getting this in 3.0.2 as well and the result was ok [09:54:29 CET] <durandal_170> why s32 is not asm optimized in libswr? [10:10:45 CET] <durandal_170> wm4: 96db is min that can be represented by 16 bit [10:12:39 CET] <nevcairiel> there is a formula for that .. 20 * log10(2^bits) [10:16:10 CET] <nevcairiel> or around 6 dB per bit [10:23:38 CET] <nevcairiel> heh even AMDs quad cores will use 2 CCX for a 2+2 combination, guess recycling is the way to go. If some of the performance troubles really come from the slow link between the two core complexes, thats a bit of a shame [10:52:25 CET] <mateo`> I'll push the aarch64 simpleneon idct patchset in a few minutes [11:03:36 CET] <cone-551> ffmpeg 03Matthieu Bouron 07master:4c8e528d19a3: lavc/aarch64: add ff_simple_idct{,_add,_put}_neon functions [11:03:37 CET] <cone-551> ffmpeg 03Matthieu Bouron 07master:0c6105dde0c4: lavc/tests/dct/aarch64: add ff_simple_idct_neon test [11:04:41 CET] <BtbN> nevcairiel, yeah, I'd guess at least the R5 and R7 are all made from the same die [11:04:51 CET] <BtbN> The R3 probably as well [11:10:13 CET] <BtbN> So there is no point in getting any of the smaller models, except for budget [11:10:20 CET] <BtbN> They don't even clock higher [12:56:28 CET] <memeka> when transcoding a file, the result has wrong fps (like 12000 fps) ... i tried using -r parameter but it's ignored .... any help? [13:48:37 CET] <aballier> michaelni: ping; did you notice i sent a followup to the vf_framerate patch ? (but failed to set v2 in subject or email headers...) [14:55:11 CET] <matkatmusic> are there any guidelines or steps for using the API to write to specific frame numbers? [15:05:08 CET] <durandal_1707> matkatmusic: no [15:24:44 CET] <matkatmusic> what about a guide that explains the design concept for creating video files with ffmpeg? [15:24:54 CET] <matkatmusic> from a programmers' point of view [15:50:06 CET] <endle> Excuse me, how can I disable "-Wdeprecated-declarations" warnings while compiling ffmpeg? [15:55:38 CET] <flux> arrange -Wno-deprecated-declarations to be used as a compiler flag? [16:01:01 CET] <J_Darnley> what ^ said: --extra-cflags [16:07:00 CET] <J_Darnley> Does moving (with mov) a byte/word/dword into the low byte/word/dword of a general purpose resiter change the contents of the high part? [16:08:14 CET] <endle> Thanks, it works [16:08:33 CET] <endle> Is ffmpeg accepting tiny patches only fixing a compile warning? [16:08:58 CET] <J_Darnley> Usually that depends on the warning [16:09:46 CET] <J_Darnley> Some compilers are overzealous with their warnings. [16:10:19 CET] <J_Darnley> If it is in a header which prodces many warnings in many C files then that is more likely. [16:10:36 CET] <J_Darnley> Why not say what warning? Or just submit anyway? [16:12:33 CET] <endle> Well, I want to submit some small patches to get familiar with ffmpeg's workflow [16:13:03 CET] <endle> By the way, why "http://coverage.ffmpeg.org/" is on 404 error? Temporary down? [16:13:15 CET] <J_Darnley> I don't know [16:16:30 CET] <J_Darnley> OMFG! The tiniest little typo! I curse this choice of variable name: dst and dst2 [16:17:10 CET] <cone-551> ffmpeg 03Alexis Ballier 07master:bbc8f3d20e09: lavf/vf_framerate: Fix frame leak when increasing framerate. [16:17:11 CET] <cone-551> ffmpeg 03Alexis Ballier 07master:21bed3c981d1: fate: Add vf_framerate test. [16:17:12 CET] <cone-551> ffmpeg 03Michael Niedermayer 07master:2898bc522da6: avcodec/h264idct_template: fix multiple runtime error: signed integer overflow [16:17:13 CET] <cone-551> ffmpeg 03Michael Niedermayer 07master:a3a408259912: avcodec/h264_cabac: Fix runtime error: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself [16:26:59 CET] <jamrial> J_Darnley: i think the lower 32 bits are not affected. only the high 32 bits on x86_64 gprs are cleared if you use dword or less [16:44:57 CET] <ubitux> jamrial: thx for yesterday; i'll work on the merge later today [16:45:05 CET] <jamrial> no prob [16:45:12 CET] <ubitux> endle: yes it's down for now, i need time to fix this, sorry about that [16:50:54 CET] <endle> ubitux, good luck:) [17:00:17 CET] <J_Darnley> endle: I forgot to ask. Does your change fix the warning or just hide it? (like with a cast) [17:00:50 CET] <endle> J_Darnley, for example, const int *p=(int*)s; [17:01:18 CET] <J_Darnley> Yeah. We are not a C++ project [17:01:25 CET] <endle> this caused a warning, and change (int*) to (const int *) is the fix, right? [17:01:56 CET] <endle> If I can guarantee that s is int* or const int* [17:58:21 CET] <wm4> does anyone have contact with Sascha Sommer? since he was a ffmpeg contributor too [18:06:25 CET] <J_Darnley> lolwut? yasm doesn't have %unmaco [18:30:45 CET] <cone-551> ffmpeg 03Muhammad Faiz 07master:1f7eb216b085: swresample/options: enable linear_interp and exact_rational by default [18:36:19 CET] <J_Darnley> WTF yasm! What is wrong with "movsx rNq, dword [...]"? [18:36:38 CET] <jamrial> use movsxd [18:37:59 CET] <jamrial> for a dword source (mem or reg) it's movsxd. movsx is for any other source [18:38:24 CET] <J_Darnley> Ah. Now I see nasm does that for me. [18:38:52 CET] <J_Darnley> Sneaky bastard [18:54:40 CET] <JEEB> always fun when things do automagic for you [19:16:17 CET] <wm4> michaelni: can you approve/disapprove the side data merging deprecation patch, so I can push it? [19:25:04 CET] <iive> LOL [19:30:28 CET] <wm4> iive: yes? [19:31:22 CET] <iive> your wording implies that you are going to push it, even if michael disapproves ;) [19:32:02 CET] <wm4> no, disapproval would mean there are some change requests, which I would do, and then would push (after approval) [19:32:30 CET] <wm4> what I don't want is that the patch has to bitrot for a week or so until maintainer timeout hits [19:33:36 CET] <iive> sure, but the wording was still funny. [19:42:39 CET] <ubitux> michaelni: coverage is back for now, not sure for how long [19:43:33 CET] <BtbN> it was gone? [19:44:48 CET] <ubitux> yeah this machine shits on itself on a regular basis [19:44:55 CET] <ubitux> i'm working on it [19:45:37 CET] <BtbN> The travis machine? [19:45:51 CET] <BtbN> I'm getting E-Mails from it constantly, seems to be running fine [19:46:26 CET] <BtbN> Ot id coverage something else than coverity? [19:46:32 CET] <BtbN> *Or is [19:47:17 CET] <atomnuker> could someone look at my lavr_sws deprecation patch to see if there's something wrong with it? [19:52:28 CET] <wm4> atomnuker: done [19:58:49 CET] <ubitux> BtbN: no it's running on my machine [19:59:17 CET] <BtbN> But we migrated it to run on TravisCi a while ago [19:59:29 CET] <BtbN> https://github.com/FFmpeg/FFmpeg-Coverity [19:59:46 CET] <BtbN> https://travis-ci.org/FFmpeg/FFmpeg-Coverity [20:00:21 CET] <ubitux> coverage ` coverity [20:00:24 CET] <ubitux> http://coverage.ffmpeg.org/ [20:00:45 CET] <BtbN> So it is something else, ok [20:01:10 CET] <BtbN> I guess that could also be done on a travis machine? [20:03:22 CET] <ubitux> http://lucy.pkh.me/ffmpeg-coverage-snapshots/ [20:03:25 CET] <ubitux> there is also this [20:03:34 CET] <ubitux> supposed to allow you to compare between runs [20:03:43 CET] <ubitux> but i guess no one uses it [20:13:54 CET] <cone-551> ffmpeg 03Anton Khirnov 07master:89466de4aeaf: vp9/x86: rename vp9dsp to vp9mc [20:13:55 CET] <cone-551> ffmpeg 03Clément BSsch 07master:a4f5e79f7cef: Merge commit '89466de4aeaf5e359489b81b8a9920a2bc7936d6' [20:27:42 CET] <cone-551> ffmpeg 03Ronald S. Bultje 07master:3a09494939dd: vp9mc/x86: add 16px functions (64bit only). [20:27:43 CET] <cone-551> ffmpeg 03Clément BSsch 07master:6ab642d69d18: vp9mc/x86: simplify a few inits. [20:27:44 CET] <cone-551> ffmpeg 03James Almer 07master:8be8444d01d8: vp9mc/x86: rename ff_avg[48]_sse to ff_avg[48]_mmxext [20:27:45 CET] <cone-551> ffmpeg 03Clément BSsch 07master:3cda179f180e: vp9mc/x86: rename ff_* to ff_vp9_* [20:27:46 CET] <cone-551> ffmpeg 03James Almer 07master:67922b4ee48b: vp9mc/x86: add AVX and AVX2 MC [20:27:47 CET] <cone-551> ffmpeg 03Ronald S. Bultje 07master:9790b44a89d1: vp9mc/x86: sse2 MC assembly. [20:27:48 CET] <cone-551> ffmpeg 03Ronald S. Bultje 07master:e99ecda55082: checkasm: add vp9 MC tests. [20:27:49 CET] <cone-551> ffmpeg 03Clément BSsch 07master:8286c359ad45: Merge commit 'e99ecda55082cb9dde8fd349361e169dc383943a' [20:28:13 CET] <jamrial> what i don't like of coverage is how all the fail code paths we have contribute to the awful coverage percentages [20:29:13 CET] <jamrial> like, some demuxers have complete coverage of actual code, but all the fail paths make it report like it's 80% or even less [20:29:32 CET] <ubitux> in a sense, that's actually a good thing to point out [20:29:41 CET] <ubitux> because failing code is almost never tested [20:29:58 CET] <ubitux> and could reveal memleaks or crashes in the error unstacking [20:30:10 CET] <ubitux> ideally, we should test failing code paths [20:30:54 CET] <ubitux> OTOH, testing every code allocation within a fate coverage is a bit non sense [20:31:19 CET] <jamrial> failing code paths are mostly tested with fuzzing [20:31:36 CET] <ubitux> wm4: does 24a362569bff1d4161742fffaca80a4a4428be8a affect ffmpeg? [20:31:39 CET] <BtbN> unless for random OOMs [20:31:56 CET] <ubitux> wm4: i suppose so, but just checking before merging [20:32:11 CET] <BtbN> Is there like a fuzz-allocator, that randomly fails like 1% of mallocs? [20:34:07 CET] <ubitux> i think derek wrote something like that some day [20:37:02 CET] <cone-551> ffmpeg 03Lou Logan 07master:e7282674a505: lavf/mpegtsenc: clarify pcr_period unit of measurement [20:59:04 CET] <cone-551> ffmpeg 03wang-bin 07master:b573e3f4845b: configure: clang -Oz for small size build to reduce size further [21:02:54 CET] <cone-551> ffmpeg 03Lou Logan 07master:396be0da59fa: doc/muxers: cleanup mpegts section [21:06:04 CET] <wm4> ubitux: not sure, but it looks like the ffmpeg code has the same problem [21:09:49 CET] <cone-551> ffmpeg 03Carl Eugen Hoyos 07master:0d34dbc27277: lavc/avpacket: Make pkt parameter of av_packet_get_side_data() const. [21:10:59 CET] <J_Darnley> Why has linking on Windows/Cygwin become so slow? I swear it gets worse every time gcc gets updated. [21:12:26 CET] <BtbN> doesn't seem overly slow to me [21:15:43 CET] <J_Darnley> Perhaps I've been using Linux too much so Windows' speed penalty just seems too much now. [21:16:05 CET] <cone-551> ffmpeg 03Carl Eugen Hoyos 07master:5dd7ea9f569b: lavc/internal: Constify AVPacket* in AVCodecInternal. [21:16:17 CET] <BtbN> it's just cygwin fork emu that's a bit slow [21:16:21 CET] <BtbN> but it's not too horrible [21:16:24 CET] <J_Darnley> I stillt hink 46 seconds to link ffmpeg is a long time [21:16:29 CET] <J_Darnley> *still think [21:16:41 CET] <RiCON> that's about right for windows [21:17:32 CET] <durandal_1707> wtf, now we are adding overflow messages all over the code? [21:20:08 CET] <durandal_1707> av_request_sample(avctx, "i just made a po\n"); [21:22:28 CET] <BtbN> make -j16 976,53s user 205,51s system 1032% cpu 1:54,50 total [21:22:44 CET] <BtbN> That's on Cygwin 64bit, a full make [21:24:08 CET] <J_Darnley> Mmm 16 threads, I'm jealous. [21:24:14 CET] <BtbN> make -j16 19,44s user 1,65s system 98% cpu 21,506 total [21:24:18 CET] <BtbN> if I rm ffmpeg_g.exe [21:24:56 CET] <BtbN> So it does spend a substantial amount of time on linking [21:25:15 CET] <BtbN> But this is also on a 3GB/s NVMe drive [21:25:28 CET] <BtbN> Can easily see it being super slow on a spinning disk [21:27:57 CET] <jamrial> yes, linking on mingw/msys2 trashes my hdd like mad [21:29:34 CET] <BtbN> I'd guess it's primarily slow on win32 because of NTFS not being exactly an amazing FS [21:30:12 CET] <J_Darnley> I remember the hype 10+ years ago. [21:30:26 CET] <J_Darnley> "NTFS will not need defragging" [21:30:47 CET] <JEEB> that was probably closer to 20 years ago [21:30:58 CET] <JEEB> since NTFS was already in use in win2000 and probably in NT4 [21:31:13 CET] <J_Darnley> Meh, when home users were moving to 2000/XP [21:31:19 CET] <BtbN> Todays NTFS is like ext4 compared to ext2 for it though [21:41:36 CET] <ubitux> wm4: ok [21:47:30 CET] <cone-551> ffmpeg 03Anton Khirnov 07master:24a362569bff: buffer: fix av_buffer_realloc() when the data is offset wrt buffer start [21:47:32 CET] <cone-551> ffmpeg 03Ronald S. Bultje 07master:0df4801105d8: vp9: make mv bounds 32bit. [21:47:33 CET] <cone-551> ffmpeg 03Clément BSsch 07master:5e4a5726995c: Merge commit '24a362569bff1d4161742fffaca80a4a4428be8a' [21:47:34 CET] <cone-551> ffmpeg 03Clément BSsch 07master:d006a075b89c: Merge commit '0df4801105d84883071b0978cb3afc7cd5184ce8' [21:48:02 CET] <ubitux> i'll stop the merge for today; i think mateo` will have a look to merging the next commit (aiff) [21:48:07 CET] <ubitux> i'll go back to the merges after that [21:48:38 CET] <durandal_1707> aiff what? [21:48:53 CET] <ubitux> a dubious fix, 0638b99cdb [21:49:18 CET] <ubitux> mateo` worked on this so i'm leaving it to him [22:18:35 CET] <cone-551> ffmpeg 03Carl Eugen Hoyos 07master:1cd58e915436: lavu/spherical: Make AVSphericalMapping pointer parameter const. [22:58:58 CET] <Compn> anyone know how to contact sascha sommer ? [22:59:09 CET] <Compn> he was listed in ffmpeg gsoc 2016 as a mentor [22:59:13 CET] <Compn> his emails are bouncing now [22:59:34 CET] <wm4> well his main email is not bouncing, just /dev/nulling [00:00:00 CET] --- Fri Mar 17 2017

1 0

ffmpeg.log.20170316
by burek 17 Mar '17

17 Mar '17

[00:31:44 CET] <shincodex> $TMPDIR does not exist on -msvc build [00:32:05 CET] <shincodex> so this happens [00:32:06 CET] <shincodex> 1> ./configure: line 4971: mktemp: command not found 1> ./configure: line 4972: mktemp: command not found 1> mkdir: cannot create directory `': No such file or directory 1> ln: target `' is not a directory: No such file or directory 1> rm: cannot lstat `': No such file or directory 1> rm: cannot lstat `': No such file or directory [00:32:21 CET] <shincodex> might be a way to redirect that to windows temp dirs [00:32:30 CET] <shincodex> since no /tmp or whatever [00:37:34 CET] <shincodex> 1> CC libavformat/rtpdec_ac3.o 1>cl : Command line warning D9025: overriding '/W0' with '/W4' [00:37:38 CET] <shincodex> you scoundrels! [00:37:47 CET] <shincodex> i need that to stop [06:30:14 CET] <matkatmusic> Howdy. slightly off-topic. has anyone taken a look at https://github.com/cisco/openh264 or http://git.videolan.org/?p=x264.git;a=summary [06:30:27 CET] <matkatmusic> they're open-source H.264 codecs [07:21:40 CET] <DHE> yeah. both are supported by ffmpeg as external libraries [09:25:39 CET] <matkatmusic> Does anyone know where in the API we can pass in jpegs or bitmaps and specify which frames and for how many frames they should be written into an mp4? [09:32:03 CET] <matkatmusic> i know you can pass in sequential images and it'll make a vid depending on parameters passed in. [09:32:46 CET] <matkatmusic> i guess i'm wondering how specific you can get. I didn't see anything in the CLI docs about passing in specific frame numbers per file [09:38:55 CET] <matkatmusic> I saw this: For creating a video from many images: ffmpeg -f image2 -framerate 12 -i foo-%03d.jpeg -s WxH foo.avi [09:42:15 CET] <matkatmusic> i did see -itsoffset : [09:42:20 CET] <matkatmusic> The offset is added to the timestamps of the input files. Specifying a positive offset means that the corresponding streams are delayed by the time duration specified in offset. [09:44:49 CET] <matkatmusic> Is it possible to even declare specific frame numbers that the input should be placed at? It seems like you can only specify a timestamp in HH:mm:ss:m format [10:12:14 CET] <d-fens_> hi, i need to generate 64 images with the counter printed on it, like "1" written on 01.jpg ... "64" written on 64.jpg, can this be automated in ffmpeg? [10:13:02 CET] <matkatmusic> d-fens_: https://ffmpeg.org/ffmpeg.html#toc-Video-and-Audio-file-format-conversion [10:13:28 CET] <matkatmusic> section 6.3 [10:14:39 CET] <d-fens_> matkatmusic: what filter woul accept a variabe to print the numbers on it? [10:15:09 CET] <matkatmusic> ffmpeg -f image2 -framerate 12 -i foo-%03d.jpeg -s WxH foo.avi is the example line [10:15:43 CET] <matkatmusic> %03d means an integer 3 characters long. [10:15:53 CET] <matkatmusic> so, 010, 004, 102, etc.. [10:16:01 CET] <matkatmusic> if you need two 0's, then use %02d [10:16:12 CET] <matkatmusic> er, two characters in length [10:16:46 CET] <matkatmusic> oh, you want to write it to the image itself [10:16:51 CET] <ikevin> i think he need the number inside the image, not in the name [10:16:52 CET] <matkatmusic> i have no idea how to do that [10:18:13 CET] <d-fens_> yep i start with nothing (or a white jpg) and need X images with the number written on the output images [10:19:17 CET] <d-fens_> maybe imagemagik is the better tool for that [10:24:42 CET] <durandal_170> drawtext [10:24:46 CET] <durandal_170> filter [10:39:34 CET] <nyuszika7h> why does MediaInfo say my encoded file is variable frame rate? I've checked and the duration is the exact same and subtitles fit, so it seems like it's wrong [10:40:04 CET] <nyuszika7h> ffmpeg -i 'C.mkv' -map 0:v:0 -vf 'crop=720:432:0:72,scale=1024:432' -aspect 2.35/1 -c:v libx264 -preset veryslow -tune film -crf 17 -map 0:a:0 -c:a libfdk_aac -vbr 4 -ac 2 -metadata:s:a:2 'title=Stereo' 'Come diventare grandi nonostante i genitori (encode 2).mkv' -y [10:40:08 CET] <nyuszika7h> oops [10:40:08 CET] <ZeroWalker> well, vfr should have the same duration, that's the point right? [10:40:22 CET] <nyuszika7h> accidentally cut the file name but you get the idea [10:40:25 CET] <nyuszika7h> this is what I used [10:41:04 CET] <ZeroWalker> and the input file is cfr? [10:41:06 CET] <nyuszika7h> yes [10:41:18 CET] <nyuszika7h> 25 fps (MPEG-2 from PAL DVD in .mkv) [10:41:33 CET] <ZeroWalker> then it's probably just not stating it's cfr [10:41:54 CET] <ZeroWalker> think you can force it to do some with some x264 command [10:42:02 CET] <ZeroWalker> think it's like -cfr or something [10:48:49 CET] <d-fens_> got it: this did the trick basically -loop 1 -i input.jpg -vf "drawtext=fontfile=arial.ttf: text=%{n+1}: x=(w-tw)/2: y=h-(2*lh): fontcolor=white: box= [10:48:50 CET] <d-fens_> 1: boxcolor=0x00000099" -t 1 out%d.jpg [10:53:09 CET] <d-fens_> actually text=%{eif\:n+1\:d} [11:02:50 CET] <Nacht> Goodmorning everyone. Does anyone know if HLS support AES on HEVC ? I can make an MP4 in HEVC and it plays perfectly, then make a non-AES HLS from it, works perfectly as well. But once I add AES I can't seem to play it. However, using the same settings with a 264 source does work. [11:03:18 CET] <Nacht> Simply using: ffmpeg -i ../265_mp4/movie.mp4 -c copy -hls_time 6 -hls_key_info_file key_info -hls_playlist_type vod -hls_segment_filename "segment_%d.ts" index.m3u8 [11:03:20 CET] <JEEB> the encryption should be the same with AVC and HEVC in HLS [11:03:20 CET] <Nacht> Nothing fancy [11:03:52 CET] <JEEB> so if HEVC doesn't work then either you have a player problem or there's some sort of weird bug with the HLS muxer [11:04:02 CET] <Nacht> I'm still not sure if it might be the player, but I've tried VLC, Windows Edge and MX Player, neither like it [11:13:42 CET] <ZeroWalker> how does set a lower frame size for opus? [11:16:48 CET] <JEEB> Nacht: uhh, as far as I know Edge doesn't support HEVC [11:16:58 CET] <JEEB> VLC can just be too old, try the nightlies for 3.0 [11:17:10 CET] <JEEB> also a recent build of mpv [11:17:30 CET] <JEEB> mpv utilizes libavformat+libavcodec in the back [11:17:40 CET] <JEEB> so if it fails then libavformat+libavcodec themselves fail at playing it :P [11:19:31 CET] <Nacht> From what I've read, Edge supports HEVC along with Hardware decoding [11:20:01 CET] <Nacht> Ill try those you suggested [11:23:09 CET] <Nacht> Thanks JEEB, VLC 3.0 Nightly did the job. It's playing now. [11:25:18 CET] <ZeroWalker> --framesize n Maximum frame size in milliseconds, this one is available in opus encoder, but i don't know how to set this in ffmpeg (through code) [11:53:09 CET] <furqa> helllo, how can i use trim filter in this command [11:53:10 CET] <furqa> .\ffmpeg -i intro.mp4 -i 1.MOV -i outro.mp4 -filter_complex "[0:v:0] [1:v:0] [2:v:0] concat=n=3:v=1 [v]" -map "[v]" output.mp4 [12:56:44 CET] <memeka> when transcoding a file, the result has wrong fps (like 12000 fps) ... i tried using -r parameter but it's ignored .... any help? [12:57:15 CET] <dt9> Hello, I've a question regarding to decoding with use coded_width/coded_height size. Is it possible to do that? For example encoded movie has 1920x1088 (coded size) and 1920x1080 as output size. I need to get to last 8 lines of data [13:19:07 CET] <Nacht> memeka: are you transcoding ? [13:19:37 CET] <Nacht> Or to be more exact: What's the command you're using [13:33:59 CET] <memeka> Nacht: yes [13:34:46 CET] <memeka> Nacht: it works well with ffmpeg 3.0, but not with 3.2 [13:38:31 CET] <matkatmusic> !topic [13:38:37 CET] <matkatmusic> hmmm [13:38:45 CET] <matkatmusic> i thought that would give me the channel topic and the link to the log.. [13:49:06 CET] <Nacht> Topic is 'Welcome to the FFmpeg USER support channel | Development channel: #ffmpeg-devel | Bug reports: http://bit.ly/cqvkhs | Wiki: https://trac.ffmpeg.org/ | FFmpeg 3.2.4 is released | FFmpeg forum: http://ffmpeg.gusari.org/ | This channel is publicly logged' [13:50:13 CET] <Nacht> memeka: does -vf fps=30 work ? [13:53:03 CET] <memeka> Nacht: no :( [13:54:50 CET] <memeka> Nacht: I am using custom encoder (patched ffmpeg), this is my command: "ffmpeg -vcodec h264 -i ./sintel_trailer-720p.mp4 -vcodec h264_v4l2m2m encoded.mp4" -- it worked with the same patches in ffmpeg 3.0, not anymore on 3.2 -- I get 12000 fps in resulting output, when i play the file it's like on fast-forward (the frames are there, encoded, but the fps is [13:54:50 CET] <memeka> wrong) .... [13:56:34 CET] <memeka> Nacht: the weird bit is that while encoding, it sees the right fps: http://pastebin.com/XxwQqhZt [13:57:00 CET] <memeka> Stream #0:0(und): Video: h264 (h264_v4l2m2m) ([33][0][0][0] / 0x0021), yuv420p, 1280x720, q=2-31, 200 kb/s, 24 fps, 12288 tbn, 24 tbc (default) [13:57:47 CET] <memeka> but after the encoding is done: Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1280x720, 10939868 kb/s, 12288 fps, 12288 tbr, 12288 tbn, 24576 tbc (default) [13:59:41 CET] <memeka> Nacht: if i write to .mkv => it's 1000 fps ... so i think the issue is at muxing [14:01:56 CET] <furq> sounds like the encoder is using the timebase as the framerate [14:02:43 CET] <furq> do you have a reason for using 3.2 [14:03:02 CET] <furq> if these are unofficial patches then all i can really suggest is downgrading until they make it upstream [14:03:19 CET] <memeka> furq: it's required by other packages on my os :( [14:03:35 CET] <furq> i don't see why that matters if you're building it yourself [14:03:50 CET] <furq> just have a separate local copy [14:04:33 CET] <memeka> furq: looks like i'll do that :( [14:05:04 CET] <memeka> what's even more strange [14:05:17 CET] <memeka> is that when outputting to mkv [14:06:14 CET] <furq> mkv's timebase has to be expressible in nanoseconds [14:06:21 CET] <memeka> mediainfo shows 1000fps (same thing to mp4 shows 12000fps); but ffmpeg -i encoded.mkv shows the correct 24 fps (ffpemg -i encoded.mp4 shows 12000fps like mediainfo) [14:06:33 CET] <memeka> but mkv also plays like fast forward ... [14:06:44 CET] <furq> fun [14:07:00 CET] <memeka> so i am assuming the issue is at muxing ... [14:07:01 CET] <furq> maybe different timestamps in the header and the stream itself [14:07:19 CET] <furq> it sounds like an encoder issue [14:07:33 CET] <memeka> i do get this: [14:07:34 CET] <memeka> [mp4 @ 0x7f6aeb10] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly [14:07:41 CET] <furq> you can probably demux the h264 stream and remux it with the right framerate [14:07:42 CET] <memeka> [mp4 @ 0x7f6aeb10] Encoder did not produce proper pts, making some up [14:07:51 CET] <furq> yeah that might be an issue [14:08:05 CET] <memeka> the same output i get on 3.0 tho`, and output is correct on 3.0 .... [14:08:08 CET] <furq> like i say, you can rewrite the stream timestamps, but it's two extra steps [14:08:20 CET] <furq> it sounds easier to just downgrade to 3.0 [14:08:43 CET] <memeka> furq: thanks .... not sure when V4L2 M2M will make it official into ffmpeg :( [14:08:52 CET] <furq> i've never even heard of it before [14:08:54 CET] <memeka> looks like i;ll downgrade :( [14:09:04 CET] <furq> i'm guessing it's something similar to h264_omx on rpi [14:09:38 CET] <memeka> yeah probably, just that more VPUs are looking to use V4L2 now ... [14:09:56 CET] <memeka> so hopefully it will push official development :) [14:10:04 CET] <memeka> thanks [14:21:39 CET] <piem> howdy! how should I cross-compile a package against ffmpeg to windows? builds from zeranoe do not seem to include the pkg-config .pc files [14:26:53 CET] <matkatmusic> found the logs.. http://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/2017-March/004171.html [14:51:51 CET] <temp> /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.0.1/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.0.1/../../../../lib64/libz.a(libz_a-inffast.o): relocation R_X86_64_32S against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC [14:51:51 CET] <temp> /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.0.1/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Nonrepresentable section on output [14:51:52 CET] <temp> collect2: error: ld returned 1 exit status [14:52:47 CET] <temp> what's reason for this error [15:42:37 CET] <Rathann> temp: your static libc wasn't compiled with -fPIC, so you cannot use it for linking [15:42:52 CET] <Rathann> for linking shared objects that is [16:08:05 CET] <feliwir> how is huffman implemented in libavcodec? I keep seeing some VLC struct, but nowhere is an explanation what exactly that VLC struct is supposed to represent [16:08:14 CET] <feliwir> https://github.com/FFmpeg/FFmpeg/blob/967feea5ebb744dce97ab327d33502b43fca0… [16:53:06 CET] <mcjack> Hi everybody, I try writing a mp4 file with the libs, and I get "track 1: codec frame size not set" as debug output. What does this relate to, and what did I do wrong? [16:53:20 CET] <mcjack> here is the full av_dump: http://pastebin.com/6PkJAZ1B [16:54:03 CET] <mcjack> and here is the source: https://github.com/filmstro/filmstro_ffmpeg/blob/master/modules/filmstro_ff… [16:54:31 CET] <mcjack> it is a wrapper to use ffmpeg in an audio centric framework named JUCE& [17:10:07 CET] <mcjack> or more precisely, which codec, the audio codec, video codec or container codec? [17:46:26 CET] <matkatmusic> mcjack: i'm sure you've stared at this a lot, but are you forgetting to set one of these properties? https://ffmpeg.org/doxygen/trunk/structAVCodec.html [17:49:03 CET] <mcjack> Hi matkatmusic, thanks& as I understand it, the AVCodec is the encoder, that you get using avcodec_find_encoder (codec_id); you are not supposed to alter that, instead you set your settings in the AVCodecContext [17:49:34 CET] <mcjack> I did set many, but I cannot claim to know, if I did all needed ones& [17:50:04 CET] <mcjack> The thing is, the debug doesn't tell me, which codec might be missing a setting [17:50:18 CET] <matkatmusic> https://ffmpeg.org/doxygen/trunk/structAVCodecContext.html#aec57f0d859a6df8… says it sets the audio frame size [17:50:43 CET] <matkatmusic> "Number of samples per channel in an audio frame." [17:51:03 CET] <mcjack> I'll try that& [17:51:56 CET] <mcjack> the thing with that is, the docs you linked say, when encoding avcodec_open2() will set that& [17:52:14 CET] <matkatmusic> maybe it's a public parameter, and you can set it? [17:53:44 CET] <mcjack> I definitely can, because there is no enforcement from the compiler (like encapsulation in C++), but the question is, will the code then do what I expect it to do? [17:53:49 CET] <matkatmusic> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/avcodec.h#L2497 [17:54:58 CET] <matkatmusic> seems public, since it's inside 'typedef struct AVCodecContext { }' [17:55:16 CET] <matkatmusic> it says on line 1707 of that file: [17:55:22 CET] <matkatmusic> You can use AVOptions (av_opt* / av_set/get*()) to access these fields from user applications. [17:55:32 CET] <mcjack> My understanding is, that when opening the codec with avcodec_open2() the lib will chose a reasonable framesize and set it& [17:56:02 CET] <mcjack> I don't even know, if it is the audio codec, that is complaining [17:56:22 CET] <mcjack> but you are right, probably [17:56:37 CET] <mcjack> as the docs say it relates to samples [17:58:11 CET] <mcjack> the other thing is, none of the examples set this, e.g. http://ffmpeg.org/doxygen/trunk/muxing_8c-example.html#a29 [17:58:36 CET] <matkatmusic> https://ffmpeg.org/doxygen/trunk/group__opt__set__funcs.html#details [17:59:49 CET] <matkatmusic> I'd see if I could find that error message in the source code for ffmpeg [18:00:05 CET] <mcjack> same thought, grep is running [18:00:52 CET] <matkatmusic> it's a shame searching for it on github doesn't find exact strings [18:02:35 CET] <matkatmusic> https://github.com/FFmpeg/FFmpeg/search?utf8=%E2%9C%93&q=%22size+not+set%22… [18:03:39 CET] <matkatmusic> https://github.com/FFmpeg/FFmpeg/blob/b05d8e7184f2f61c1e6261b79ef20abd48b53… [18:04:27 CET] <matkatmusic> so maybe you need to call av_set_audio_frame_duration2 ? [18:04:31 CET] <llogan> easy to find using "git grep" if you have a copy of the git repository [18:04:57 CET] <matkatmusic> you can search for quoted strings if you add 'in:file' after your string in quotes [18:05:13 CET] <matkatmusic> aka "frame size not set" in:file [18:08:12 CET] <piem> any idea of a project using ffmpeg and cross-compiling for windows? i'm missing the pkg-config.pc files in the binaries from ffmpeg.zeranoe.com [18:08:39 CET] <matkatmusic> mcjack: see those links [18:09:39 CET] <mcjack> yes, but I think it's: https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/movenc.c#L5778 [18:10:14 CET] <matkatmusic> ah [18:10:38 CET] <matkatmusic> yes, you didn't set your bits per sample in your code betwen line 219 and 225 [18:13:39 CET] <mcjack> didn't change anything :-( [18:14:43 CET] <matkatmusic> what about... https://ffmpeg.org/doxygen/trunk/structAVCodecContext.html#aec57f0d859a6df8… [18:14:54 CET] <matkatmusic> "May be 0 when the codec has AV_CODEC_CAP_VARIABLE_FRAME_SIZE set, then the frame size is not restricted." [18:18:18 CET] <matkatmusic> mcjack: what about setting it to that? [18:18:43 CET] <mcjack> to 0 or to an assumed value? [18:18:56 CET] <matkatmusic> to that AV_CODEC thing [18:19:30 CET] <matkatmusic> from that link you posted, it seems to want the audio format in Variable Bit Rate, and you're supplying a static bit rate? [18:20:08 CET] <matkatmusic> (link to your code) [18:20:40 CET] <mcjack> uhm, one thing is the input, that is a static value, because I'm feeding it raw floats. The encoder will do whatever is best for the selected Codec, as I understand it& [18:21:56 CET] <matkatmusic> hmm, well I'd add some breakpoints to line 5776 of movenc.c, and then probe st->codecpar and see what properties are available to you, and what they're set to. [18:22:29 CET] <matkatmusic> if (!st->codecpar->frame_size && !av_get_bits_per_sample(st->codecpar->codec_id)) it wants those two things set to something other than 0 [18:22:33 CET] <matkatmusic> afaik [18:22:49 CET] <mcjack> right [18:23:10 CET] <mcjack> no, it want's at least one of the two different from 0 [18:23:55 CET] <matkatmusic> you sure about that? [18:24:30 CET] <mcjack> argn, now I'm confused. slowly: the error will appear, if frame_size == 0 and bits per samples == 0 [18:24:47 CET] <matkatmusic> you could rewrite it: if( st->codecpar->framesize == 0 && av_get_bits_per_sample(st->codecpar->codec_id) == 0 ) [18:24:50 CET] <mcjack> so it won't if either of it is set different from 0 [18:25:08 CET] <matkatmusic> 'either' would be using || [18:25:14 CET] <matkatmusic> it's saying if both of them are 0 [18:25:23 CET] <matkatmusic> then, assume compressed audio [18:25:28 CET] <mcjack> yes, but I am reversing the outcome, so de morgans rules apply [18:26:34 CET] <mcjack> if both apply (&&) then the error is shown vs. if one is not (||) the error won't be shown... [18:26:59 CET] <matkatmusic> ok. Well, what does your stream->codecpar look like after line 225 in your code? is frame_size or codec_id 0? [18:28:05 CET] <matkatmusic> maybe add a breakpoint on 227 and inspect stream->codecpar? [18:28:21 CET] <mcjack> it's not !codec_id but !av_get_bits_per_sample(st->codecpar->codec_id) [18:29:28 CET] <matkatmusic> hmmm, so maybe you're supplying a codec_id that is set up for VBR? [18:30:34 CET] <matkatmusic> FFmpegVideoWriter::setAudioCodec() what kind of codec are you supplying? [18:31:12 CET] <mcjack> audio is aac [18:31:30 CET] <mcjack> I basicvally copy a video replacing the audio samples [18:31:37 CET] <matkatmusic> aac is VBR [18:32:22 CET] <matkatmusic> what if you choose a different audio codec. like, one for non-VBR. I don't know much about the different codecs, so ignore me if my statement is ill-informed [18:33:04 CET] <mcjack> well, that's a sane test& I could do that& [18:33:32 CET] <matkatmusic> i guess pick the audio codec that matches what JUCE's AudioSource spits out? [18:33:40 CET] <matkatmusic> where are the codec types listed? [18:35:30 CET] <mcjack> https://ffmpeg.org/doxygen/trunk/group__lavc__core.html#gaadca229ad2c20e060… [18:35:40 CET] <mcjack> quite a few to test [18:36:21 CET] <matkatmusic> right right [18:36:40 CET] <matkatmusic> I'm gonna guess that ID_PCM_S16LE is Signed 16bit Little Endian [18:38:32 CET] <matkatmusic> mcjack: can we see how you're using your FFmpegVideoWriter class? [18:39:34 CET] <mcjack> sure, it's all in the demo: https://github.com/filmstro/filmstro_ffmpeg/blob/master/examples/VideoPlaye… [18:40:06 CET] <mcjack> simply remove the #if 0 and corresponding #endif and a save button will appear [18:40:43 CET] <mcjack> then you load a video and click save, it asks for a filename and starts writing& [18:41:04 CET] <mcjack> but the files were not ok, unfortunately, nothing to be heard etc... [18:41:20 CET] <mcjack> so many rivers to cross [18:41:45 CET] <matkatmusic> I hear ya. hopefully i'm helping a little bit... [18:43:15 CET] <alexpigment> mcjack, are you trying to write PCM audio to an MP4 file? [18:43:38 CET] <matkatmusic> mcjack: just looking at line 190 in that file, trying to figure out what type of audio format your AudioSourceChannelInfo is in [18:43:54 CET] <matkatmusic> file:///Users/Shevy/Dropbox/CharlesShared/JUCE-4_2_4/doxygen/doc/juce__AudioSampleBuffer_8h.html#a97a2916214efbd76c6b870f9c48efba0 [18:43:57 CET] <matkatmusic> er [18:44:14 CET] <matkatmusic> it says it uses a A multi-channel buffer of 32-bit floating point audio samples. [18:44:29 CET] <matkatmusic> so, you probably want the codec AV_CODEC_ID_PCM_F32LE [18:45:25 CET] <alexpigment> just out of curiosity, is this problem that you're feeding it 32-bit audio and you're getting an error when trying to encode AAC? [18:45:51 CET] <mcjack> yes, is this not supported? [18:46:16 CET] <alexpigment> if so, why not try something like -c:a aac -sample_fmt s16 -ar 44100 -b:a 160000 [18:46:35 CET] <alexpigment> i don't know for sure that it's not supported, but i have never seen 32-bit aac ever [18:46:49 CET] <alexpigment> i would be surprised if it *did* support it [18:46:50 CET] <matkatmusic> alexpigment: he's writing an API to interface ffmpeg with the JUCE audio framework. [18:47:07 CET] <mcjack> thanks for the suggestion. However I use the library, not the commandline& [18:47:20 CET] <alexpigment> yeah i get that, it just seems like the error is that you need to convert to 16-bit [18:47:24 CET] <mcjack> but it's a good idea to double check the supported formats [18:47:56 CET] <matkatmusic> mcjack: does juce have a means to go from raw samples to aac data? [18:48:06 CET] <IntruderSRB> anyone have any idea if MBAFF stream can be encrypted using MPEG-CENC in order to be DRM protected? [18:48:16 CET] <matkatmusic> I'm looking in the API, and haven't seen anything about it. found some forum posts where Jules said he didn't plan on implementing it [18:48:41 CET] <IntruderSRB> my encryptor has no issue with progressive videos DRM protection (using CENC scheme) but when I provide MBAFF cenc protected - all players throw decode error [18:49:01 CET] <mcjack> there is an AudioFormatWriter which can produce AAC files, but that's here off topic, and it will not work for writing in a video file [18:59:06 CET] <alexpigment> IntruderSRB: are you trying to stream interlaced content? [19:01:03 CET] <alexpigment> i just haven't seen an interlaced stream ever, and i don't know how web players handle it. having said that, I trust that you get no decode errors when there's no DRM, so who knows what's going on [19:03:40 CET] <IntruderSRB> exactly ... [19:03:54 CET] <IntruderSRB> works perfectly fine in browser (native player or bitmovin/dash-if) [19:04:04 CET] <IntruderSRB> until I turn on encryption ('cenc') [19:04:15 CET] <IntruderSRB> than all hell break loose and I get decode_error instantly [19:05:21 CET] <IntruderSRB> I guess it can be deinterlaced before encryption but the CPU cost would probably be high ... [19:21:03 CET] <mcjack> alexpigment and matkatmusic: thanks for trying with me, I have to leave for today& [19:38:32 CET] <alexpigment> IntruderSRB: yeah deinterlacing is something i used to do a lot, but I leave everything as MBAFF these days because a) it takes a lot less time and b) it keeps blu-ray compatibility. [19:38:59 CET] <alexpigment> good luck on figuring that one out - i honestly have no idea why encryption would break because of mbaff [20:05:41 CET] <JEEB> encryption shouldn't unless it somehow handles stuff inside samples in a special way [20:05:52 CET] <JEEB> generally just encrypting contents of samples would make sense'ish [20:15:06 CET] <Mista-D> is there a global video filter command without ,split[1][2][3] ? [20:16:52 CET] <thebombzen> Mista-D: what are you trying to do [20:16:59 CET] <thebombzen> split[1][2][3] won't even work [20:17:35 CET] <Mista-D> encode to between 5 and 15 ouputs in one command while deinterlacing source. [20:18:18 CET] <thebombzen> ah. afaik using the same filterchain with several outputs is hard, but something you CAN do is output something lossless and pipe it to the encoding command [20:18:57 CET] <thebombzen> like ffmpeg -i input -vf filters -c ffv1 -f nut - | ffmpeg -f nut - output1.mkv output2.mkv output3.mkv [20:18:59 CET] <thebombzen> etc. [20:22:16 CET] <thebombzen> I think you can do it it one command too though with: ffmpeg -i input -lavfi '[0:v] yadif [v]' -map '[v]' out1.mkv -map '[v]' out2.mkv -map '[v]' out3.mkv [20:22:20 CET] <thebombzen> but this might not work [20:22:24 CET] <thebombzen> you could try i tthough [20:22:47 CET] <matkatmusic> does anyone here use the library instead of the CLI to do their conversion via an app of their own? [20:22:51 CET] <thebombzen> Mista-D: I'm not quite sure if -lavfi behaves globally or per-output, but I'm sure the docs would know [20:23:20 CET] <thebombzen> matkatmusic: someone definitely does (not me) so I suggest you ask the question you're actually trying to ask [20:23:26 CET] <Mista-D> thebombzen: will try that, thanks [20:24:42 CET] <thebombzen> matkatmusic: because then someone who does use libav* could potentially answer your question, which nobody knows yet [20:42:12 CET] <matkatmusic> i'm just trying to continue where mcjack left off with getting his API to work with ffmpeg [20:44:33 CET] <matkatmusic> interacting with the decoder/encoder via code as opposed to the CLI tool [20:44:56 CET] <JEEB> see the stuff under docs/examples [20:45:20 CET] <JEEB> and then there's stuff like Handbrake, VLC and mpv that utilize libav* [20:45:27 CET] <johoja> Hi, - I'm trying to compile ffmpeg 3.2.4 - with --enable-librtmp - on ubuntu 14.04 , and i have librtmp-dev installed, but i get an error ERROR: librtmp not found using pkg-config [20:45:41 CET] <JEEB> see config.log [20:45:47 CET] <JEEB> that should tell you what exactly failed at the end of it [20:45:58 CET] <JEEB> also do note that recent FFmpeg doesn't require librtmp for rtmp [20:46:03 CET] <furq> is there any reason to use librtmp now [20:46:03 CET] <JEEB> it has its own implementation [20:46:09 CET] <johoja> this is what I'm getting : [20:46:10 CET] <johoja> END /tmp/ffconf.HIc9WuDZ.c gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -I/root/ffmpeg_build/include -std=c99 -fomit-frame-pointer -pthread -I/usr/include/freetype2 -I/usr/include/fribidi -I/usr/include/freetype2 -I/usr/include/opus -I/usr/include/p11-kit-1 -R/usr/lib/x86_64-linux-gnu -c -o /tmp/ffconf.ygSadPNx.o /tmp/ffconf.HIc9WuDZ.c gcc: error: unrecognized command line [20:46:25 CET] <JEEB> johoja: do not post the content here, just pastebin your config.log and link it here [20:46:31 CET] <johoja> one second - sorr [20:46:42 CET] <JEEB> furq: no real reason to use librtmp unless the lavf one has a boog [20:46:48 CET] <johoja> http://paste.ubuntu.com/24190653/ [20:47:01 CET] <johoja> yeah - lavf is not working for a stream, i want to see if its lavf, or if it will work in librtm [20:47:02 CET] <furq> i assume there's some justification for not getting rid of --enable-librtmp [20:47:03 CET] <johoja> yeah - lavf is not working for a stream, i want to see if its lavf, or if it will work in librtmp [20:47:15 CET] <johoja> http://paste.ubuntu.com/24190653/ [20:47:22 CET] <johoja> Sorry for the double post there. [20:47:24 CET] <JEEB> > unrecognized command line option '-R' [20:47:30 CET] <JEEB> check if that's in the pkg-config file [20:47:38 CET] <johoja> Where would that be ? [20:47:39 CET] <JEEB> or what the flying F is going on [20:49:22 CET] <JEEB> johoja: you should be able to check with `pkg-config --cflags --libs librtmp` [20:49:32 CET] <JEEB> if it comes out of there then the pkg-config file is just busted [20:50:00 CET] <johoja> I don't see any -R in the output from pkg-config [20:51:06 CET] <JEEB> ok, then I officially have nfi where that shit's coming [20:51:23 CET] <johoja> :( - maybe the configure script ? [20:51:24 CET] <JEEB> because there's no -R in the configure file [20:51:55 CET] <JEEB> and something specifically is setting it as it even has a parameter [20:51:56 CET] <JEEB> -R/usr/lib/x86_64-linux-gnu [20:52:23 CET] <johoja> ya its weird. [23:55:26 CET] <IntruderSRB> hey guys, I'm trying to extract h264 nalunits into h264 file (bytearray) from fragment fmp4 [23:55:33 CET] <IntruderSRB> is there a way to pass "header" mp4 as an argument [23:55:39 CET] <IntruderSRB> ffmpeg -i fileSequence1.mp4 -an -vcodec h264 fileSequence1.h264 [23:55:48 CET] <IntruderSRB> this is what I managed to find out atm [23:55:58 CET] <IntruderSRB> got [23:56:01 CET] <IntruderSRB> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f8dfe000400] could not find corresponding trex [23:56:01 CET] <IntruderSRB> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f8dfe000400] error reading header [23:56:13 CET] <IntruderSRB> which is expected as the header alone is in fileSequence0.mp4 [23:56:56 CET] <JEEB> I'd just concatenate them and pass to ffmpeg through stdin [23:57:19 CET] <IntruderSRB> worth a try ... [23:57:27 CET] <JEEB> cat initSegment.mp4 actualSegment1.mp4 | ffmpeg -i -c copy out.264 [23:57:48 CET] <JEEB> that will copy the NAL units, -c:v h264 would be transcoding [23:58:18 CET] <iive> JEEB: you can concat .mp4? thats quite a news for me. [23:58:26 CET] <JEEB> fragmented isobmff yes [23:58:38 CET] <IntruderSRB> it worked... [23:58:47 CET] <IntruderSRB> sometimes the simplest solutions are the best :D [23:59:00 CET] <iive> :D [23:59:10 CET] <JEEB> the mov demuxer probably wouldn't like your usualy non-fragmented isobmff like that though [23:59:21 CET] <JEEB> but E_HAVE_NOT_TRIED [00:00:00 CET] --- Fri Mar 17 2017

1 0