Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

March 2017

1 participants
62 discussions

ffmpeg-devel.log.20170315
by burek 16 Mar '17

16 Mar '17

[00:02:09 CET] <jkqxz> Hardware codecs are the best. (Recently in wtf hardware codec bugs: <https://github.com/01org/intel-vaapi-driver/issues/87>.) [00:04:24 CET] <philipl> 8bit signed wrap around anyone? [00:04:35 CET] <philipl> 120fps should be enough for everyone, right? [00:05:57 CET] <jkqxz> Looks like all their testing thought so. [00:37:51 CET] <cone-255> ffmpeg 03Steven Liu 07master:e90ad882819c: avformat/hlsenc: fix duration wrong when no pkt duration [09:06:38 CET] <matkatmusic> howdy. I'm browsing the API and i'm wondering if it's possible to specify which frame number an image should be placed at, along with for how many frames. [09:07:32 CET] <deepak> Hello..I am deepak aggarwal. I am trying to fix http://trac.ffmpeg.org/ticket/5943#no1 [09:07:44 CET] <deepak> I have produced the error [09:13:13 CET] <matkatmusic> or perhaps the ability to read a text file as input that specifies images and frame-ranges per image per line and turn it into a video [09:19:04 CET] <matkatmusic> like, ffmpeg -i file.txt -r 24 where file.txt is File001.jpg 0 4, File002.jpg 5 12, meaning File001 is the image for frames 0 thru 4, File 002 is the image for frames 5 thru 12, etc.. [09:41:38 CET] <ubitux> what's the politic wrt color_range? avctx or frame or both? [09:42:56 CET] <atomnuker> I'd expect it to be always flagged everywhere [09:43:40 CET] <ubitux> so if the information is only in the frame [09:43:47 CET] <ubitux> at each frame decode we set it to the avctx? [09:44:48 CET] <ubitux> reason i'm asking: i'm trying to merge the next vpx commit; we are currently setting avctx color_range at every frame (libav doesn't), and the current change from libav set its into the frame instead (which makes more sense, IMO) [09:45:09 CET] <ubitux> so i'm now wondering about keeping the avctx color range set [09:45:15 CET] <nevcairiel> should probably update avctx as well so it doesnt desync and cause funnyness [09:45:49 CET] <ubitux> ok [09:46:21 CET] <ubitux> now second question: our code looks currently unsafe in case libvpx add more color ranges [09:46:43 CET] <ubitux> it's simpler that a switch case though [09:46:46 CET] <ubitux> what do we prefer? [09:59:17 CET] <atomnuker> there can't be more than 2 color ranges [10:00:31 CET] <ubitux> yeah well we use the same method for color spaces [10:00:52 CET] <ubitux> (i'm refering to libvpxdec.c:set_pix_fmt()) [10:01:10 CET] <nevcairiel> you would think that, but the microsoft color format specification also specifies 48-208 for some reason, whats to stop someone else from also d oing such weird things =p [10:01:24 CET] <atomnuker> what [10:02:00 CET] <nevcairiel> https://msdn.microsoft.com/en-us/library/windows/desktop/ms705659(v=vs.85).… [10:02:21 CET] <ubitux> btw, looking at lavc/utils, it seems we are setting the frame color_range based on the avctx value [10:02:32 CET] <ubitux> so the commit might be noop-able altogether [10:02:39 CET] <nevcairiel> if its unset in the frame i believe yes [10:02:51 CET] <ubitux> (at least for decoding) [10:04:04 CET] <atomnuker> I'm sure that its all for filters [10:04:14 CET] <atomnuker> they can't keep cutting precision down and getting away with it [10:05:12 CET] <nevcairiel> not that i have ever seen either of the narrower ones used anywhere [10:57:01 CET] <cone-541> ffmpeg 03Matthieu Bouron 07master:1ade4d87bae8: lavc/h264dec: use OFFSET macro [12:30:09 CET] <cone-541> ffmpeg 03Luca Barbato 07master:b183abfb5b63: vpx: Support color range [12:30:10 CET] <cone-541> ffmpeg 03Clément BSsch 07master:89a032634b6e: Merge commit 'b183abfb5b6366b177cf44f244c66156257a6fd6' [12:32:58 CET] <cone-541> ffmpeg 03Luca Barbato 07master:40ad05bab206: checkasm: Cast unsigned to signed [12:32:59 CET] <cone-541> ffmpeg 03Clément BSsch 07master:8b13492c9ecf: Merge commit '40ad05bab206c932a32171d45581080c914b06ec' [12:34:27 CET] <cone-541> ffmpeg 03Diego Biurrun 07master:48b80f8393d4: hpeldsp: Explain why put_no_rnd_pixels_tab is larger than necessary [12:34:28 CET] <cone-541> ffmpeg 03Clément BSsch 07master:6426c58b1cb9: Merge commit '48b80f8393d418ad35d73f5a36f5011de1928f3c' [12:38:03 CET] <ubitux> wbs: i suppose 56af0bc10 should also include strtoull? [12:41:26 CET] <michaelni> ubitux, http://coverage.ffmpeg.org/ is not working [12:41:29 CET] <wbs> ubitux: yes [12:41:44 CET] <ubitux> wbs: ok thanks [12:41:53 CET] <ubitux> michaelni: will fix [12:44:05 CET] <cone-541> ffmpeg 03Martin Storsjö 07master:56af0bc10f49: configure: Check for strtoll and redirect to _strtoi64 in the msvcrt block [12:44:06 CET] <cone-541> ffmpeg 03Martin Storsjö 07master:79fb0692992c: configure: Move defines for controlling MSVCRT headers to the CRT detection section [12:44:07 CET] <cone-541> ffmpeg 03Clément BSsch 07master:132523448ba4: Merge commit '56af0bc10f49654b5b5f3efe82c69a13bf15fc8b' [12:44:08 CET] <cone-541> ffmpeg 03Clément BSsch 07master:50d303a66ad0: Merge commit '79fb0692992c74214c6cf8e81350fc93eeffc5ec' [12:52:28 CET] <cone-541> ffmpeg 03Martin Storsjö 07master:100fb0ddfda9: configure: Allow detecting and using LLVM lld-link as linker for windows [12:52:29 CET] <cone-541> ffmpeg 03Clément BSsch 07master:67e2ba36ec50: Merge commit '100fb0ddfda958da70f98feac81f924c02483789' [13:05:58 CET] <ubitux> michaelni: i'm going to have to switch boxes, this box is dying; it will stay down for maybe 2 days [13:28:51 CET] <michaelni> ubitux, ok, ill tell thomas, he is using it to decide/check were to add self test [13:29:14 CET] <ubitux> it can be run locally [13:29:33 CET] <ubitux> spoiler alert: lavfi needs more testing [13:29:57 CET] <ubitux> but many filter are not bitexact so improvements needed in that area [13:30:02 CET] <nevcairiel> testing lavfi more is probably more meaningful then adding yet more algorithmic tests for lavu =p [13:30:24 CET] <michaelni> ill tell thomas about lavfi, i think he knows that coverage can be run locally [13:30:59 CET] <ubitux> basically any filter that uses float should use a new test mechanism which needs to be added badly [13:31:14 CET] <ubitux> i'm happy to add tests to my filters if such thing were present [13:31:43 CET] <ubitux> (i have way too many float based filters) [13:43:41 CET] <michaelni> ubitux, ok, just suggested thomas to look into a mechanism for non bitexact filter testing [13:44:22 CET] <ubitux> thanks! [14:04:21 CET] <temp> hello [14:05:44 CET] <temp> i build ffmpeg source encounter problem [14:06:13 CET] <temp> error like : libavcodec/ffjni.c:23:10: fatal error: jni.h: No such file or directory #include <jni.h> ^~~~~~~ [14:10:33 CET] <ubitux> didn't you just --enable-jni for a non-android system? [14:10:41 CET] <ubitux> this is probably a #ffmpeg question [14:10:41 CET] <temp> yes [14:10:56 CET] <ubitux> well, why? [14:11:08 CET] <temp> ok, thanks for notice [14:11:47 CET] <temp> i don't know, just try use --enable-jni [14:12:25 CET] <ubitux> it's java native stuff for android [14:13:24 CET] <temp> ok, is it cannot for other java native program? [14:15:00 CET] <mateo`> in theory it can enable the jni helpers on desktop too, but it's not tested and you should not be able to enable jni on a platform other than the android one in the first place [14:15:42 CET] <temp> oh, thank your help [14:17:42 CET] <temp> and what's --enable-mediacodec for , why it need --enable-jni [14:18:15 CET] <BtbN> Because it's an Android API. [14:18:30 CET] <temp> ok [14:18:44 CET] <temp> thanks so much [14:18:55 CET] <mateo`> I'll patch the configure asap to error out when needed [14:21:25 CET] <BBB> durandal_170: do you have more libavfilter qualification tasks? Ive got another 3 vmaf students that need a new, fresh qualification task [14:22:11 CET] <BBB> (I didnt think this qualification task thing throug very well) [14:22:31 CET] <atomnuker> ask if anyone wants to work on audio encoders [14:25:33 CET] <durandal_170> BBB: port some filters from mlt/frei0r/vapoursynth/avisynth [14:26:58 CET] <durandal_170> add gray planar >8 with alpha to swscale [14:28:32 CET] <cone-541> ffmpeg 03Diego Biurrun 07master:e46a6fb7732a: avconv: Check that muxing_queue exists before reading from it [14:28:33 CET] <cone-541> ffmpeg 03Clément BSsch 07master:a283665693e1: Merge commit 'e46a6fb7732a7caef97a916a4f765ec0f779d195' [14:32:24 CET] <jamrial> BBB: port the vf_noise asm from inline to yasm [14:32:48 CET] <BBB> jamrial: thats not very appropriate for vmaf, I dont think it includes a lot of assembly, more basic filtering stuff and algorithms [14:33:01 CET] <BBB> jamrial: that would work for vp9 qual task though (since thats a ton of avx2) [14:33:14 CET] <jamrial> fair enough [14:34:50 CET] <mateo`> ubitux seems to love cosmetic merges :D [14:35:08 CET] <ubitux> grrr [14:35:57 CET] <BBB> durandal_170: Im unfortunately not very familiar with mlt/frei0r/vapour/avisynth [14:38:08 CET] <temp> libavcodec/libopusenc.c: In function libopus_encode_init:libavcodec/libopusenc.c:337:15: error: implicit declaration of function opus_multistream_surround_encoder_create; did you mean opus_multistream_decoder_create? [-Werror=implicit-function-declaration] enc = opus_multistream_surround_encoder_create( [14:38:09 CET] <temp> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [14:38:09 CET] <temp> opus_multistream_decoder_create [14:38:09 CET] <temp> libavcodec/libopusenc.c:337:13: warning: assignment makes pointer from integer without a cast [-Wint-conversion] [14:38:10 CET] <temp> enc = opus_multistream_surround_encoder_create( ^ [14:38:27 CET] <temp> what's this mean [14:39:05 CET] <cone-541> ffmpeg 03Steven Liu 07master:0052f3f527c4: avcodec/videotoolboxenc: add rc_max_bitrate control into videotoolbox [14:40:09 CET] <durandal_170> BBB: port defish0r plugin from frei0r [14:40:24 CET] <mateo`> temp: please ask on #ffmpeg, this channel is dedicated to ffmpeg development [14:42:14 CET] <temp> there no answer, sorry for trouble, i'll go and wait :P [14:42:42 CET] <BBB> durandal_170: okiedokie, tnx& Ill suggest that as first qual task to the student [15:16:08 CET] <ubitux> any reason libnpp is treated differently than libfdk_aac and openssl? [15:18:38 CET] <BtbN> it is? [15:18:49 CET] <ubitux> sorry, wrt licenses in configure [15:19:06 CET] <BtbN> It's nonfree, unless someone accidentially changed that [15:19:20 CET] <nevcairiel> so are the two ubitux listed [15:19:38 CET] <ubitux> i'm asking about the gpl incompat bit [15:19:40 CET] <nevcairiel> although people argue about openssls system library exception all the time [15:20:13 CET] <BtbN> Well, libnpp is a closed source non-system-library that's under a definitely not GPL compatible license. [15:20:20 CET] <BtbN> I don't see how it could ever be not nonfree [15:21:21 CET] <ubitux> so it should be treated the same as the other two? [15:21:27 CET] <BtbN> It is? [15:21:40 CET] <ubitux> it isn't, should it? [15:21:56 CET] Action: ubitux wonders if he's failing at english again [15:22:30 CET] <RiCON> fdk/openssl only fail if --enable-gpl is used without --enable-nonfree [15:22:39 CET] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=configure;h=d486cfde37e43411… [15:22:39 CET] <RiCON> libnpp fails even with lgpl [15:22:52 CET] <nevcairiel> why would lgpl allow linking to a nonfree library [15:23:20 CET] <nevcairiel> distributing it would still be nonfree [15:23:29 CET] <BtbN> openssl and libfdk also require gpl instead of lgpl. The libnpp code in ffmpeg is LGPL [15:23:37 CET] <BtbN> Maybe that's the difference you mean? [15:24:11 CET] <ubitux> (side node: "enabled gpl &&" could be in die_license_disabled_gpl) [15:24:27 CET] <BBB> nevcairiel: assuming the library is distributed separately, there is no issue, right? [15:24:38 CET] <BtbN> it seems weird though. Indeed loks like fdk/openssl are only nonfree in GPL mode? [15:24:55 CET] <BtbN> BBB, only if it's a system library [15:24:56 CET] <BBB> nevcairiel: e.g. assume you link against nvidia drivers .so, if nvidia lets you download the .so and some rpm repo lets you download a ffmpeg build that links to it& everyones happy, right? [15:24:59 CET] <BtbN> which npp is clearly not [15:25:08 CET] <BBB> thats gpl [15:25:11 CET] <nevcairiel> BBB: depends who you ask, some peole argue even having code t hat uses a nonfree library is therefore nonfree [15:25:15 CET] <BBB> he asked lgpl [15:25:42 CET] <BBB> puretards are entitled to their opinion too, indeed [15:26:37 CET] <nevcairiel> also the license of the header matters, i guess [15:26:38 CET] <RiCON> also, cdio/cdio-paranoia probably should require --enable-version3? [15:26:39 CET] <BBB> nevcairiel: the lgpl says nothing of that sort in my reading ;) [15:26:51 CET] <RiCON> or is it not about the libs license but the FFmpeg code using them? [15:27:13 CET] <BBB> nevcairiel: but its indeed possible the nonfree part doesnt allow it, but you cant make blanket statements about that since each nonfree modules license is different [15:27:53 CET] <BtbN> also the entire nvidia/cuda license stuff was deemed too fucked up and confusing, so making it nonfree was the safest thing to go for [15:28:21 CET] <BtbN> libnpp is not part of any nvidia driver, they expect you to bundle the DLLs with your application. [15:39:59 CET] <ubitux> http://sprunge.us/dRWf so& any objection? [15:40:23 CET] <nevcairiel> libnpp should also fail when you try to use it with lgpl [15:40:36 CET] <nevcairiel> without nonfree [15:41:59 CET] <ubitux> but not the others? [15:42:18 CET] <ubitux> i'm trying to make these check consistent for the next merge :( [15:42:20 CET] <BtbN> it should always fail trying to build it without nonfree [15:42:39 CET] <BtbN> So basically like it is right now from my understanding. [15:43:45 CET] <nevcairiel> i have no clue why lgpl would allow linking against an incompatible library in the first place [15:43:59 CET] <nevcairiel> libav certainly doesnt have it like that [15:46:41 CET] <nevcairiel> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=f997ac1c8bc2124c4c6bf3… .. maybe it applies to openssl and its apache license specifically [15:47:30 CET] <nevcairiel> but libnpp is a propietary license, both on the binary and the headers used [15:59:20 CET] <ubitux> so i should deal with the current behaviour? [16:03:21 CET] <BBB> nevcairiel: its possible that apache/ssl are specifically lgpl-incompatible [16:03:27 CET] <BBB> nevcairiel: i.e. lgpl+ssl = gpl [16:03:38 CET] <BBB> or lgplv3 or whatever [16:03:40 CET] <BBB> I dont remember [16:12:30 CET] <J_Darnley> Dammit. Why doesn't movh as a macro default parameter work? Is it because it is another macro? [16:19:09 CET] <BBB> J_Darnley: gramner would probably know that [16:19:27 CET] <BBB> J_Darnley: but Ive always just done some integer parameter to the macro and then assin/define movtmp to movh/mova inside the macro [16:19:31 CET] <jamrial> J_Darnley: if you're writing ymm code then it wont work [16:19:35 CET] <BBB> depending on the integer constant [16:19:40 CET] <BBB> and yes, movh in ymm doesnt exist [16:19:41 CET] <jamrial> movh is not defined for that [16:19:52 CET] <J_Darnley> Wait, I try again and it works? Did I not save the correct changes before? [16:19:58 CET] <J_Darnley> jamrial: I know [16:19:59 CET] <Gramner> macro expansion rules probably [16:19:59 CET] <BBB> lol [16:20:28 CET] <J_Darnley> Clearly it is just user error [16:48:02 CET] <kierank> atomnuker: bought dell laptop like yours [16:48:11 CET] <kierank> did you get the thunderbolt to ethernet or usb3 to ethernet [16:52:24 CET] <durandal_170> i have dell to [16:54:02 CET] <kierank> i bought usb-c to thernet [16:54:09 CET] <kierank> wasn't sure the apple one was gfoing to work [16:59:56 CET] <atomnuker> kierank: I got a usb-c to ethernet, though it really doesn't matter [17:00:08 CET] <atomnuker> they all have the same realtek chipset in them [17:00:31 CET] <atomnuker> its pretty decent too in terms of offloading capabilities [17:00:59 CET] <atomnuker> I recommend staying away from usb-c hubs though [17:01:34 CET] <kierank> I read that the apple one doesn't hotplug on windows [17:01:38 CET] <atomnuker> all use the same messed up chipset which for some reason breaks compatibility with usb 2 devices if you turn the usb connector 1 way [17:02:28 CET] <atomnuker> even though its usb-c and it shouldn't matter, it does with that chipset [17:38:56 CET] <wm4> does thunderbolt work yet in Linux [17:39:12 CET] <wm4> couldn't ever get apple's thunderbolt ethernet adapter to work on my macbook (with Linux) [18:47:21 CET] <tmm1> how can i add a file to fate? [18:47:29 CET] <tmm1> and what are the guidelines for file size for samples [18:59:39 CET] <nevcairiel> as small as possible for the task at hand [19:09:19 CET] <J_Darnley> BBB jamrial Gramner: I know REP_RET should be used when it is a jump target but does the return from a function call count as one? [19:11:27 CET] <jamrial> J_Darnley: i think you don't need to use REP_RET anymore [19:12:23 CET] <jamrial> RET is enough for all cases [19:12:30 CET] <J_Darnley> RET knows when the previous instruction was a jump but not if it is a target/label. Or did you mean somethign else? [19:14:53 CET] <Gramner> I don't remember if ret counts as a branch as far as that issue goes, but the cpu:s affected by it (old amd ones) are getting kinda rare nowadays so it doesn't really matter. I usually don't bother with REP_RET anymore [19:15:40 CET] <J_Darnley> yeah, the comments say that ssse3 is enough to know [19:33:43 CET] <J_Darnley> Gah! I don't suppose people would let me add a dedicated file for avx functions. [19:35:17 CET] <JEEB> why not? [19:36:48 CET] <J_Darnley> Not sure. Some would dislike the duplication I'm doing in it. [19:37:22 CET] <BBB> the duplication is still there if its in a separate file [19:37:23 CET] <J_Darnley> Nesecary in my opinion because many of these macros are written with mm registers in mind. [19:37:38 CET] <BBB> and I think its fine to duplicate code if de-dup requires ugliness [19:37:44 CET] <BBB> the h264 simd code is sometimes very very old [19:37:47 CET] <BBB> h264 is old :-p [19:39:12 CET] <Gramner> or just nuke mmx code from orbit when there's sse2 implementation :> [19:40:34 CET] <J_Darnley> Some of it would be ugly if I add conditionals to the macros, sometimes not. [19:41:47 CET] <BBB> J_Darnley: youre smart enough to be able to make a decision yourself on when its worth it and when not ;) [19:41:54 CET] <BBB> J_Darnley: dont forget youre the main person touching h264 simd right now [19:42:09 CET] <BBB> so if youre ok with it, & [19:42:47 CET] <JEEB> aye [19:42:58 CET] <Gramner> duplicating is better than an unreadable mess of a template that tries to be compatible with everything under the sun [19:43:04 CET] <JEEB> ^this [19:43:41 CET] <wm4> <tmm1> how can i add a file to fate? <- contact someone who has access [19:43:46 CET] <BBB> %macro INC 17 [19:43:53 CET] <wm4> (might be a couple of people, but I only know michaelni) [19:44:11 CET] <BBB> %if %0 == 1 inc %2 %elif .. add %2, %3 & [19:44:19 CET] <J_Darnley> :D [19:44:40 CET] <J_Darnley> Ouch my face is a little distorted with this font [19:44:41 CET] <BBB> I believe at some point I could add files, but I forgot how it works [21:08:23 CET] <kierank> J_Darnley: what function are you working on [21:16:33 CET] <atana> michaelni, ping [21:17:22 CET] <atana> I have updated the peakspoint2 repo. Now it has 8 failures [21:20:06 CET] <cone-541> ffmpeg 03Diego Biurrun 07master:ae90119c6701: configure: Simplify license incompatibility check [21:20:07 CET] <cone-541> ffmpeg 03Clément BSsch 07master:9f28db47accb: Merge commit 'ae90119c6701fa09ff747cca35238e36b2d2ab2f' [21:25:34 CET] <cone-541> ffmpeg 03Anton Khirnov 07master:a115eb9e7505: mimic: do not release the newly obsolete reference at the end of decoding [21:25:35 CET] <cone-541> ffmpeg 03Clément BSsch 07master:e40fd81809ea: Merge commit 'a115eb9e750543f1d8bf951414d291069bf396c2' [21:29:30 CET] Action: michaelni sees a ping from atana and 7min later "atana has quit (Ping timeout: 240 seconds)" [21:30:35 CET] <cone-541> ffmpeg 03Luca Barbato 07master:2ac00d2d1d51: mov: Validate the ID number [21:30:36 CET] <cone-541> ffmpeg 03Clément BSsch 07master:8636ccb5c0ff: Merge commit '2ac00d2d1d51047c6ce69d5fbe1a08392d142658' [21:45:29 CET] <cone-541> ffmpeg 03Luca Barbato 07master:a5ebe5d12179: ac3dec: Split spx-specific code from decode_audio_block() [21:45:30 CET] <cone-541> ffmpeg 03Clément BSsch 07master:7c4dbd1df985: Merge commit 'a5ebe5d1217942238c641c83b24ef1106e53934a' [21:57:12 CET] <cone-541> ffmpeg 03Luca Barbato 07master:f0ccc65bc9ab: ac3dec: Split coupling-specific code from decode_audio_block() [21:57:13 CET] <cone-541> ffmpeg 03Clément BSsch 07master:2e3221c30320: Merge commit 'f0ccc65bc9ab9ddf1366066395564c71bcc825ee' [21:58:35 CET] <cone-541> ffmpeg 03Luca Barbato 07master:3db51bf671de: ac3dec: Simplify skipping [21:58:36 CET] <cone-541> ffmpeg 03Luca Barbato 07master:8495d84f0101: ac3dec: Add some inline hints [21:58:37 CET] <cone-541> ffmpeg 03Clément BSsch 07master:151b5e4a53c2: Merge commit '3db51bf671defd47f2ec5ab67b11fb7730fb5e5a' [21:58:38 CET] <cone-541> ffmpeg 03Clément BSsch 07master:4ac44520e526: Merge commit '8495d84f0101464b15517860db33e8605586d87e' [22:00:40 CET] <ubitux> next merge might get me killed [22:02:11 CET] <iive> hum? [22:02:32 CET] <jamrial> iive: remove x11grab [22:03:07 CET] <iive> is there any replacement/alternative? [22:03:24 CET] <JEEB> xdg? [22:03:30 CET] <ubitux> xcb [22:03:35 CET] <jamrial> there's a replacement already, but people may still bitch. i guess that's what ubitux is talking about :p [22:03:39 CET] <JEEB> right, xcb [22:04:28 CET] <iive> isn't xcb just another lib that talks to xorg ? [22:04:50 CET] <nevcairiel> yes [22:05:22 CET] <nevcairiel> which is why having 2 is silly, and xcb is more modern [22:05:54 CET] <iive> does it have any benefit compared to x11 one? [22:06:22 CET] <JEEB> if it works better [22:06:25 CET] <JEEB> does that count? [22:06:40 CET] <iive> this is a big if [22:06:56 CET] <wm4> ubitux: what is it? [22:06:59 CET] <JEEB> as far as I know the xcb one was added due to the x11 one sucking [22:07:25 CET] <iive> i mean, is there any measurable and demonstratable way to prove that it works better? [22:08:42 CET] <nevcairiel> even if they work equally well, having two is still silly if they serve the exact same purpose [22:08:45 CET] <ubitux> wm4: the old gpl-version using old-style x11 api to grab the screen [22:09:04 CET] <wm4> oh ok [22:09:14 CET] <iive> nevcairiel: if they work equally well, then the one that works on more systems should be preffered [22:09:18 CET] <wm4> oh so license is the issue with x11 vs. xcb? [22:09:27 CET] <ubitux> it's one of them [22:09:42 CET] <JEEB> oh, and the license thing :V [22:10:04 CET] <iive> gah, licenses. [22:10:17 CET] <ubitux> but xcb is definitely the modern way [22:10:50 CET] <iive> ubitux: something been modern doesn't mean it is better. [22:11:09 CET] <nevcairiel> xcb is also rather old already [22:11:20 CET] <nevcairiel> in xorg terms, everything is old [22:11:45 CET] <iive> the X protocol is much older ;) [22:12:39 CET] <iive> libx11 uses xcb to talk to the server [22:13:11 CET] <iive> so unless the new code exploits some of the locking improvements that xcb offers, it should run the same. [22:14:20 CET] <jkqxz> Using XCB makes error handling possible - X11 offers little more than "oh noes, abort". [22:14:24 CET] <uau> the xcb version is shorter, so it's probably better code [22:14:28 CET] <TD-Linux> libx11 on modern systems is emulated using libxcb [22:14:34 CET] <wm4> jkqxz: true [22:14:44 CET] <cone-541> ffmpeg 03Diego Biurrun 07master:4fef648d10bf: Remove the legacy X11 screen grabber [22:14:45 CET] <cone-541> ffmpeg 03Clément BSsch 07master:4a9c5f6bc5a8: Merge commit '4fef648d10bf3bcfd4b8fa5755c1128966a2427c' [22:14:49 CET] <iive> TD-Linux: that's what i said above too. [22:14:50 CET] <wm4> to be honest, there are many libx11 things that could just have been fixed [22:15:32 CET] <JEEB> I'm gonna poke #ffmpeg so that they update their olden tutorials on the wiki [22:15:44 CET] <JEEB> since it seems like a lot of that stuff still points towards x11grab [22:15:55 CET] <wm4> so the x11 one was dropped? [22:16:03 CET] Action: JEEB points at the commit in the log [22:16:18 CET] <wm4> ah [22:16:41 CET] <wm4> to be honest a deprecation period wouldn't have hurt [22:17:07 CET] <jamrial> there's no way to deprecate modules like this afaik [22:17:36 CET] <jamrial> aside from an av_log() saying "stop using this" [22:17:37 CET] <uau> are there any practical API/usage differences? [22:17:55 CET] <uau> so could you just have an alias as a deprecation mechanism? [22:18:09 CET] <JEEB> most of the options seemed to similar [22:18:11 CET] <ubitux> -f x11grab is kept [22:18:14 CET] <JEEB> ah [22:18:17 CET] <JEEB> ok [22:18:45 CET] <ubitux> compil' flags change; you don't need --enable-gpl anymore, and it's autodetected anyway [22:19:35 CET] <ubitux> i'm going to fix a few remaining references after next commit [22:21:11 CET] <cone-541> ffmpeg 03Diego Biurrun 07master:5ed4644d6de7: x11grab: Rename internal component to "xcbgrab" [22:21:12 CET] <cone-541> ffmpeg 03Clément BSsch 07master:f6d61eb6f95a: Merge commit '5ed4644d6de7f6112431dc2d9a5cfe9a0a75a688' [22:21:19 CET] <uau> ubitux: if it's just disabling the older implementation of the same API, i don't see why you thought it'd be particularly controversial [22:21:36 CET] <ubitux> because removing anything in ffmpeg is taboo [22:21:52 CET] <ubitux> especially if it belongs in a museum [22:22:15 CET] <nevcairiel> if common commandlines still work etc, then i d ont see any reason to not do it [22:22:45 CET] <nevcairiel> but its done already now anyway .) [22:23:14 CET] <cone-541> ffmpeg 03Clément BSsch 07master:2f6661c94016: doc: remove remaining legacy x11grab references [22:24:38 CET] <debianuser> ubitux: Last time I checked x11grab was providing higher fps than xcbgrab. I.e. 60fps grab was with some additional hacks possible with x11grab but not possible with xcbgrab. [22:25:16 CET] <ubitux> did you test after 0bd1be65e88d6a4f367e698d7a2b105424eb1905 ? [22:26:36 CET] <debianuser> No. I haven't tested it for about a year. [22:27:04 CET] <ubitux> you should :) [22:27:45 CET] <debianuser> You think it's os-dependent? I mean does xcbgrab gives higher fps to you? [22:28:19 CET] <debianuser> (I'll definitely retest again, by the way, thank you!) [22:33:06 CET] <wm4> <jamrial> aside from an av_log() saying "stop using this" <- good enough [22:33:24 CET] <wm4> <ubitux> -f x11grab is kept <- oh, could be fine then [22:42:44 CET] <iive> is it possible to create x11grab alias, that uses xcbgrab? [22:42:59 CET] <JEEB> iive: that was already added [22:43:02 CET] <iive> oh, it does this already [22:53:31 CET] <ubitux> debianuser: the commit i'm pointing out is a huge optimization [23:01:45 CET] <cone-541> ffmpeg 03Anton Khirnov 07master:5ebef79abecc: Fix instances of broken indentation found by gcc 6 [23:01:46 CET] <cone-541> ffmpeg 03Clément BSsch 07master:dd0abace3ec7: Merge commit '5ebef79abecc3ffcc4ab0d46e203d13b068107c9' [23:21:11 CET] <cone-541> ffmpeg 03Anton Khirnov 07master:ed1cd8107643: flac demuxer: improve probing [23:21:12 CET] <cone-541> ffmpeg 03Clément BSsch 07master:e887d685f741: Merge commit 'ed1cd81076434b76f37576d4d806973476a8e96c' [23:23:45 CET] <cone-541> ffmpeg 03Anton Khirnov 07master:e328178da90f: qsvdec: only access hwaccel_context is the pixel format is QSV [23:23:46 CET] <cone-541> ffmpeg 03Clément BSsch 07master:aabe525734aa: Merge commit 'e328178da90f44690e0076f4dbfd16da9175f441' [23:26:33 CET] <RiCON> ubitux: does 9f28db47a mean libnpp no longer needs --enable-nonfree for lgpl? [23:28:45 CET] <cone-541> ffmpeg 03Martin Storsjö 07master:7ebdffc353f3: dxv: Check to make sure we don't overrun buffers on corrupt inputs [23:28:46 CET] <cone-541> ffmpeg 03Clément BSsch 07master:d96f6df3a649: Merge commit '7ebdffc353f3f0827864e8e3461fdc00cc243b14' [23:29:13 CET] <ubitux> RiCON: ah, erm mmh... i will fix this tomorrow until someone does, i need to test it properly [23:29:34 CET] <jamrial> ubitux: you can probably noop the next two commits, btw. they are reverted a few commits ahead [23:29:35 CET] <RiCON> i thought that's what was discussed earlier [23:29:46 CET] <ubitux> jamrial: yep, i will [23:30:03 CET] <ubitux> RiCON: yeah i'm sorry [23:30:22 CET] <ubitux> RiCON: any clean solution welcome btw [23:30:32 CET] <ubitux> maybe another list is needed [23:31:22 CET] <RiCON> isn't libnpp already in a separate list? [23:31:31 CET] <ubitux> http://sprunge.us/LDKj [23:31:48 CET] <RiCON> yeah, that's what i'd suggest too [23:31:49 CET] <ubitux> RiCON: yeah but... the name isn't license-behaviour related [23:32:13 CET] <RiCON> yeah, but the issue is with fdk/openssl being nonfree only with gpl [23:32:27 CET] <ubitux> feel free to commit, it's late for me, i'll likely make a mistake [23:32:32 CET] <ubitux> i'll go back to merges tmr [23:32:46 CET] <RiCON> i don't have push :) [23:33:29 CET] <ubitux> ask jamrial :° [23:33:32 CET] Action: ubitux running away [23:34:18 CET] <jamrial> RiCON: should i push that diff? [23:46:19 CET] <RiCON> jamrial: wait, the error configure shows is wrong [23:47:16 CET] <jamrial> RiCON: ok [23:47:27 CET] <RiCON> jamrial: http://sprunge.us/XGIP [23:47:54 CET] <jamrial> RiCON: give me a commit message for this :P [23:51:19 CET] <RiCON> jamrial: http://sprunge.us/FZFe good enough? [23:51:37 CET] <jamrial> RiCON: yes, thanks [23:52:57 CET] <nevcairiel> imho openssl and possibly fdk should rather be special cased [23:53:05 CET] <nevcairiel> they are those with a nonfree-but-not-really license [23:53:30 CET] <kierank> dunno about openssl but why fdk [23:53:50 CET] <BtbN> The FDK license is weird [23:53:52 CET] <BtbN> but not nonfree [23:54:00 CET] <kierank> the nonfree part is that it forces you to get a patent licence [23:54:11 CET] <kierank> even if you don't want one [23:54:25 CET] <BtbN> Not even, the nonfree part according to some FSF guy I asked is the part where it forces you how to name your derived work. [23:54:50 CET] <kierank> you mean the bit where you can't mention fraunhofer? [23:55:12 CET] <BtbN> They have a part where they very specifically describe how a derived work should be named [23:56:20 CET] <cone-541> ffmpeg 03Ricardo Constantino 07master:b409d8d4a276: configure: libnpp is always nonfree, even with LGPL [23:56:26 CET] <kierank> amazing that wbs is still fixing crashes to this day [00:00:00 CET] --- Thu Mar 16 2017

1 0

ffmpeg.log.20170315
by burek 16 Mar '17

16 Mar '17

[00:02:15 CET] <SpeakerToMeat> If I'm reading from/to files and not a stream, a "Thread message queue blocking" doesn't mean it's gonna drop frames, only that it's gonna go slower, right? [00:06:25 CET] <shincodex> Im back [00:06:55 CET] <shincodex> in my frantic scramble to solve h264 being just garbage [00:06:59 CET] <shincodex> or ffmpegs imp of it idk [00:07:07 CET] <shincodex> I do a init packet [00:07:29 CET] <shincodex> int error = av_read_frame(formatContext, &packet); [00:07:38 CET] <shincodex> if all good [00:07:49 CET] <shincodex> avcodec_decode_video2(codecContext, frameNative, &frameFinished, &packet); [00:08:06 CET] <shincodex> LIB say you fool that deprecated [00:08:15 CET] <shincodex> and i say the examples must be deprecated fool [00:08:29 CET] <shincodex> attribute_deprecated [00:08:39 CET] <shincodex> * @deprecated Use avcodec_send_packet() and avcodec_receive_frame(). [00:08:49 CET] <shincodex> I wonder if this do something with packet that i not do right [00:08:59 CET] <shincodex> and i have bad corrupt poop frames cause [00:09:01 CET] <shincodex> of this [00:10:27 CET] <shincodex> When my avdecode is finish or not [00:10:32 CET] <shincodex> at end of loop i av_free_packet(&packet); [00:10:39 CET] <shincodex> for files I see they dont do this [00:10:41 CET] <shincodex> they init once [00:10:58 CET] <shincodex> and move in size based on avcodec decode returns the bytes it decode [00:11:01 CET] <shincodex> they move the packet by this [00:11:12 CET] <shincodex> for next decode but that all great for file [00:11:18 CET] <shincodex> I get my h264 from rtsp [00:11:29 CET] <shincodex> allow only video kick rest out [00:11:31 CET] <thebombzen> are you just rambling or do you actually have a question [00:11:40 CET] <shincodex> Thats my question [00:11:48 CET] <thebombzen> what is [00:11:50 CET] <shincodex> I was directing at jeeb or furq or engineers [00:11:56 CET] <shincodex> That understand libavcodec [00:11:57 CET] <thebombzen> you've been talking at this channel for five minutes straight [00:12:06 CET] <shincodex> No [00:12:09 CET] <shincodex> I been talking all day [00:12:11 CET] <shincodex> I come and go [00:12:26 CET] <thebombzen> I know that but your last stream has been fight minues straight of talking [00:12:33 CET] <thebombzen> but you still haven't actually asked a question [00:12:39 CET] <thebombzen> you've just said stuff that didn't work [00:13:54 CET] <shincodex> Well tell me [00:14:07 CET] <thebombzen> you haven't actually asked a question [00:14:45 CET] <shincodex> Why does VLC decode h264 better(Less pixelation, scanline mirroring, ink splooging) than h264 even though libavcodec is used in VLC? [00:15:08 CET] <thebombzen> there's no such thing as "decode it better" [00:15:22 CET] <thebombzen> a decoder is "dumb" in that it has to produce exactly the same output for a compliant bitstream [00:15:32 CET] <thebombzen> it doesn't get to make any choices [00:15:48 CET] <c_14> in many cases, yes it does [00:15:55 CET] <c_14> a lot of codecs don't specify bit-exact decoding [00:15:55 CET] <thebombzen> shhh [00:16:04 CET] <thebombzen> you're overcomplicating things :P [00:16:14 CET] <c_14> I'm guessing the difference is probably somewhere in the renderer [00:16:18 CET] <thebombzen> if you're wondering why a decoded frame in VLC might look better, it's probably because it's doing post-processing [00:16:25 CET] <c_14> ye [00:16:49 CET] <thebombzen> some players like mpv (and maybe VLC) do postprocessing like deblocking or derining [00:16:57 CET] <thebombzen> deringing* wow I can't spell [00:17:11 CET] <nolaan> Hi guys there's a problem with the hflip and vflip video filters. They are inversed.... [00:17:28 CET] <thebombzen> what do you mean "they are inversed" [00:17:38 CET] <shincodex> thats the thing [00:17:54 CET] <shincodex> is post-proc responsible for taking care of artifacts [00:17:59 CET] <shincodex> it is disabled currently [00:18:07 CET] <thebombzen> nothing to do with libpostproc [00:18:12 CET] <shincodex> huh [00:18:19 CET] <shincodex> Maybe its a useless lib? [00:18:30 CET] <thebombzen> no it's not just the point here :P [00:18:42 CET] <thebombzen> a video player has its own internal routines for making a video prettier before putting it on the screen [00:18:44 CET] <shincodex> i destroyed my configure line to find the problem [00:18:53 CET] <shincodex> Yes... well [00:19:01 CET] <thebombzen> if you're comparing the output of a video player to the raw decoded frame [00:19:03 CET] <thebombzen> then you're doing it wrong [00:19:10 CET] <thebombzen> because you should not expect those to look the same [00:19:10 CET] <c_14> nolaan: you're probably just confusing the terminology [00:19:59 CET] <c_14> hflip flips across the horizontal axis, i.e. the axis that partitions the horizon into two equal halves [00:20:29 CET] <shincodex> Are you saying that avcodec_decode [00:20:35 CET] <shincodex> is a raw frame? [00:20:55 CET] <shincodex> poor ffplay [00:21:24 CET] <thebombzen> ffplay is not supposed to be a good player [00:21:33 CET] <thebombzen> it's supposed to be a quick n dirty thing that uses ffmpeg [00:21:37 CET] <shincodex> i have yet to run it [00:21:41 CET] <shincodex> Its not quick [00:21:44 CET] <shincodex> but it is dirtyy [00:21:56 CET] <thebombzen> clearly you've never heard the expression quick-n-dirty [00:21:58 CET] <shincodex> how many lines was that thing again? [00:22:07 CET] <shincodex> No I just opened up a player with less lines [00:22:15 CET] <shincodex> It stabbed my eyeballs in the ear [00:22:36 CET] <shincodex> but hmmm maybe should look to see if it has post processing [00:22:39 CET] <thebombzen> again you've probably never herad the phrase quick-n-dirty [00:22:46 CET] <shincodex> No I never heard it [00:22:50 CET] <shincodex> Even when you just said it now [00:22:50 CET] <thebombzen> there you go [00:22:52 CET] <shincodex> never heard it [00:23:08 CET] <c_14> turn on your tts [00:23:20 CET] <thebombzen> text-to-speech? [00:23:25 CET] <shincodex> Yes [00:23:34 CET] <shincodex> You must have not heard of tts before [00:23:44 CET] <shincodex> but now you know [00:23:45 CET] <shincodex> now.... [00:23:47 CET] <c_14> He was making a pun based on the usage of "heard" in a text chat [00:23:48 CET] <shincodex> you know... [00:23:57 CET] <shincodex> heard of cows? [00:24:21 CET] <thebombzen> wow you're just misinterpreting everything today [00:24:35 CET] <thebombzen> "quick-n-dirty" does not reference the number of lines of code [00:26:08 CET] <shincodex> my video quick-n-dirty was less than 80 [00:26:22 CET] <shincodex> thats shy of 100 by 20 [00:26:46 CET] <shincodex> so... but besides this point [00:27:48 CET] <thebombzen> well ffplay is 3700 lines [00:28:01 CET] <shincodex> I really think something in h264 decoder or h264dec.c is stopping me here [00:28:10 CET] <thebombzen> compared to mpv, which is 137000, I'd say, yea ffplay is quickndirty [00:28:10 CET] <shincodex> a dict option? [00:28:11 CET] <shincodex> maybe [00:28:23 CET] <shincodex> copy paste code means nothing [00:28:34 CET] <thebombzen> >copy paste code [00:28:41 CET] <shincodex> you saw the configure script right [00:28:52 CET] <shincodex> lots of lines [00:28:57 CET] <thebombzen> mpv doesn't have a configure script [00:28:59 CET] <shincodex> Lots... [00:28:59 CET] <thebombzen> it uses waf [00:29:01 CET] <shincodex> ffmpeg [00:29:19 CET] <thebombzen> now why do you think FFmpeg's configure script is large [00:29:22 CET] <thebombzen> think about that for a second [00:29:33 CET] <shincodex> Oh there is plenty of platforms to think about [00:29:33 CET] <shincodex> pcpc [00:29:37 CET] <shincodex> ppc mips [00:29:40 CET] <shincodex> arm [00:29:42 CET] <shincodex> etc [00:29:49 CET] <shincodex> in each Libwhatever [00:29:52 CET] <shincodex> you see those folders [00:30:02 CET] <shincodex> Then outside of these folders you have many encoders [00:30:07 CET] <shincodex> decoders muxers demuxers etc [00:30:24 CET] <thebombzen> I'm outa here cause this convo is a waste of my time [00:30:33 CET] <shincodex> run away little girl [00:30:35 CET] <shincodex> run away [00:30:39 CET] <shincodex> deadly boss mobs [00:31:46 CET] <shincodex> suntory whisky toki... try it [00:31:51 CET] <shincodex> its pretty tasty [00:32:00 CET] Action: shincodex cackles this idle chatroom to death [00:33:29 CET] <nolaan> c_14: the video had a rotated bit sorry [00:33:56 CET] <c_14> aah, yeah. that can be disconcerting if you don't realize [00:38:48 CET] <shincodex> Ill be back [00:55:42 CET] <SpeakerToMeat> SHould I be worried about this? "[jpeg2000 @ 0x55840c9511e0] End mismatch 1" [03:02:15 CET] <Rathann> looks like there might be a bug in 3.1.x that is fixed in 3.2.x and which trips over HandBrake (SIGSEGV in decomb filter) [03:02:46 CET] <Rathann> predictably, HandBrake upstream said "FFmpeg is unsupported, use libav." [03:04:04 CET] <Rathann> it's 100% reproducible and happens with every file if you just open something and click start encoding (default settings) [03:04:23 CET] <Rathann> https://github.com/HandBrake/HandBrake/issues/631 [07:17:20 CET] <matkatmusic> howdy [07:18:03 CET] <matkatmusic> I have a question the API. is it possible to pass in images and assign them to specific smpte frame numbers? [07:18:50 CET] <matkatmusic> like, i want image Image003.jpg to appear at SMPTE time 1:00:00:45.23, for example. or even FrameNumber 764 [07:20:28 CET] <matkatmusic> Image004.jpg might appear at FrameNum 790, so Image003 would need to be the image used for frames 764-789 [07:21:16 CET] <matkatmusic> I'm trying to figure out if it's possible to take images spit out from my JUCE app whenever it repaints and turn 'em into a movie with ffmpeg [09:22:39 CET] <termos> I remember seeing this new encoding/decoding API in libFFmpeg where you push and retrieve frames somehow, similar to filter graphs. Not the got_pkt integer that's being set in avcodec_encode_video2 [09:28:00 CET] <termos> seems like avcodec_encode_video2 is marked as deprecated by all the examples are still using it. Yet I remember seeing an example where it was done in a more modern way [09:29:23 CET] <termos> aha, avcodec_send_frame/avcodec_receive_frame [09:32:00 CET] <JEEB> yeah examples usually get updated... at some point [10:43:52 CET] <feliwir> where in ffmpeg is the code to convert yuv420p to rgb? [10:44:04 CET] <thardin> swscale? [10:44:32 CET] <feliwir> thardin, i mean the exact code. Because my own yuv420p to rgb conversion isn't working [10:44:46 CET] <feliwir> so i thought i can look at the ffmpeg sourcecode for that task [10:45:30 CET] <thardin> one does not simply look into swscale [10:45:59 CET] <thardin> or rather: it helps if you realize it's a circular buffer of circular buffers (last time I looked) [10:49:10 CET] <feliwir> hm okay [10:50:55 CET] <nido_> thardin: reminds me of https://upload.wikimedia.org/wikipedia/commons/5/58/Magic_Roundabout_Schild… [10:53:49 CET] <thardin> :] [10:54:17 CET] <thardin> actually, I think it's a circular buffer of lines. plus some magic to set up the scaling filters [10:55:31 CET] <thardin> but how everything is hooking up internally in sws takes a bit of time to digest. but not impossible [11:29:41 CET] <furq> https://chromium.googlesource.com/chromium/src/+/7d2b8c45afc9c0230410011293… [11:29:44 CET] <furq> what [11:31:11 CET] <thardin> yes, apng is a thing. firefox supports it [11:33:51 CET] <furq> i know [11:34:04 CET] <DHE> https://en.wikipedia.org/wiki/Multiple-image_Network_Graphics aka the MNG format... [11:34:09 CET] <furq> chromium has spent the last nine years not supporting it [11:34:31 CET] <furq> i wonder if this is some kind of hostage exchange for webp in firefox [11:35:09 CET] <furq> also apng and mng are different [11:35:18 CET] <thardin> mng is a mess iirc [12:28:06 CET] <thebombzen> Safari supports apong too [12:28:14 CET] <thebombzen> Chromium used to support it, because WebKit does [12:28:24 CET] <thebombzen> but when Chromium switched from WebKit to Blink, they lose support [12:28:30 CET] <thebombzen> apng* not aponglol [12:28:44 CET] <thebombzen> wow I can't type [12:45:00 CET] <furq> er [12:45:06 CET] <furq> i don't think that's right [12:45:21 CET] <furq> apparently webkit only added apng in late 2015 [12:45:52 CET] <furq> the blink split was back in 2013 [12:46:37 CET] <furq> nothing but firefox supported apng when i last checked a couple of years ago [12:47:31 CET] <furq> it's good that the thing i wanted to do two years ago would finally be possible now that i don't care any more [13:13:04 CET] <scam> good morning [13:14:09 CET] <termos> when doing avcodec_open2(stream->codec, ...) I'm passing the deprecated "codec" into the function, is there another way to do this that's not deprecated? [13:14:48 CET] <scam> will ffmpeg take usb webcam to rtmp url? [13:32:50 CET] <DHE> termos: use your own AVCodecContext object stored in your own data structures instead [13:34:37 CET] <ZeroWalker> is it possible to set the timestamp before the encoding, cause as the encoding might buffer, writing the timestamp to the package when it's done will be incorrect. Was hoping one could set it in the frame and that it would be copied to the package when retrieved [13:38:24 CET] <DHE> umm.. what? the timestamps usually come from the input and are not changed (unless you specifically request it like with an FPS change) [13:38:37 CET] <termos> DHE: thanks, that's what i'm doing now [13:39:22 CET] <DHE> termos: the main reason was that the libavformat code was previously reading that 'codec' field to get information like what codec was being saved for file header reasons. They wanted to break that up. [13:39:50 CET] <DHE> so they marked that field as deprecated and made a new field specifically for libavformat to get its codec metadata from instead. it's caused some confusion, yeah [13:42:46 CET] <mcjack> DHE and termos: I struggle at the same point, if I don't set stream->codec on encoding avformat_write_header fails, because the codecs are all set to unknown& [13:43:42 CET] <termos> aha I haven't made it that far yet, but that sounds annoying [13:46:31 CET] <DHE> mcjack: avcodec_parameters_from_context(stream->codecpar, my_avcodeccontext); [13:47:00 CET] <ZeroWalker> well it's a live capture, so i have to set the timestamps myself [13:47:19 CET] <ZeroWalker> so can i set it at frame->pts, and it will stick to that package when it's retrieved? [13:48:30 CET] <mcjack> thanks DHE, I will try that [13:50:18 CET] <mcjack> in that case I have to use my_avcodeccontext = avcodec_alloc_context3 (encoder); instead of the preallocated stream->codec [13:50:26 CET] <mcjack> right? [13:53:09 CET] <DHE> mcjack: looks right [13:55:07 CET] <mcjack> thanks, I'll try [13:58:43 CET] <ITR> Needing some help with making a slideshow: http://pastebin.com/1mDhmw97 [14:03:47 CET] <ITR> To append on my previous message, uploading it to youtube works fine, so I guess I'll just download it from there and use that, if everything else fails [14:04:11 CET] <ikevin> hi [14:05:43 CET] <ikevin> i'm trying to recode a video with multiple audio track, i want to merge audio tracks to 1, is there a way to do that? [14:06:58 CET] <temp> i encounter problem when build ffmpeg source code like :libavcodec/ffjni.c:23:10: fatal error: jni.h: No such file or directory #include <jni.h> [14:10:25 CET] <BtbN> you probably need to do some magic to build Java stuff [14:12:15 CET] <temp> no need now [14:36:12 CET] <mcjack> DHE: avcodec_parameters_from_context works perfect, thanks! Now I can start fixing the data filling [14:40:17 CET] <temp> libavcodec/libopusenc.c: In function libopus_encode_init:libavcodec/libopusenc.c:337:15: error: implicit declaration of function opus_multistream_surround_encoder_create; did you mean opus_multistream_decoder_create? [-Werror=implicit-function-declaration] enc = opus_multistream_surround_encoder_create( ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ opus_multistream_decoder_create libavcodec/libopusenc.c:337:13: warning: a [14:40:18 CET] <temp> ssignment makes pointer from integer without a cast [-Wint-conversion] enc = opus_multistream_surround_encoder_create( what's this mean [14:43:30 CET] <Xtro_M> Hello , I am in first year of my college and i don't have experience in advanced c programming using algorithms or data structures but i am still determined to join GSOC program . Can I get some tips that could help me ? I am open to suggestions about learning algorithms and data structures too but since i have limited time till GSOC I am not sure whether its possible to learn that much till the program starts. [15:21:23 CET] <SpeakerToMeat> When working with an image progression source, how do you set the original material fps for conversion? [15:23:08 CET] <SpeakerToMeat> ... -r it seems [15:23:42 CET] <SpeakerToMeat> nope. [15:24:42 CET] <SpeakerToMeat> Ok, -r for conversion, but -framerate for input [15:25:26 CET] <SpeakerToMeat> Thanks :D [15:26:34 CET] <SpeakerToMeat> I wonder, with the original conversion which took the rate erronously as 25fps what ffmpeg did with the audio, the separate audio was set for fps, so 2000 units per frame. It was probably cut at the end. But it'd be interesting to see what it did [15:27:58 CET] <temp> libavcodec/libopusenc.c: In function libopus_encode_init: [15:27:59 CET] <temp> libavcodec/libopusenc.c:337:15: error: implicit declaration of function opus_multistream_surround_encoder_create; did you mean opus_multistream_decoder_create? [-Werror=implicit-function-declaration] [15:27:59 CET] <temp> enc = opus_multistream_surround_encoder_create( [15:27:59 CET] <temp> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [15:27:59 CET] <temp> opus_multistream_decoder_create [15:28:11 CET] <temp> who can help me on this [15:29:04 CET] <alexpigment> did you install libopus from a repo? [15:29:13 CET] <temp> yes [15:29:17 CET] <alexpigment> it's probably just old [15:29:55 CET] <temp> also try build opus code [15:30:11 CET] <alexpigment> "also try" = "i also tried"? [15:30:19 CET] <alexpigment> or are you telling me to do something? [15:30:33 CET] <temp> yes i tried [15:30:36 CET] <alexpigment> k [15:31:03 CET] <SpeakerToMeat> did you remove the repo version of the opus lib so you don't have conflicting versions? [15:31:57 CET] <SpeakerToMeat> Or, in the case you (probably?) installed the newer libopus to /usr/local pointed configure to the newer location for the lib? [15:33:10 CET] <temp> i did not configure the location [15:34:48 CET] <SpeakerToMeat> for libopus? if it's using configure it probably defaulted to /usr/local, did you just build it or built and install it? and, did you remove the distro packages? [15:37:20 CET] <SpeakerToMeat> If you just built libopus but not install it, you'll have to indicate to the ffmpeg configuration script (I'm not sure which build system is ffmpeg using right now) where the lib and its include files are [15:37:43 CET] <SpeakerToMeat> it wont find it in /home somewhere on its own [15:38:23 CET] <SpeakerToMeat> If libopus was built and installed, but the distro package is still there, it's possible the build system is just still hooking onto the distro version and not your custom compiled one [15:43:18 CET] <c4017> When I use '-f alsa' I get the error 'Unknown input format 'alsa'', but it works with avconv. Is there a configure flag that needs to be set to enable alsa when compiling ffmpeg? [15:43:46 CET] <temp> now, i tried remove the distro packages about opus*, built and installed the opus. [15:43:58 CET] <temp> then i get error like : libavcodec/libopus.c:22:10: fatal error: opus_defines.h: [15:45:54 CET] <SpeakerToMeat> temp: did you reconfigure the ffmpeg so it'd find the new directory opus is in? [15:46:06 CET] <temp> no [15:47:51 CET] <temp> i see , let me try again [15:59:06 CET] <yariv_slidely> Hi, I am trying to blur a video after 12 second. But I also want the video to gradually blur for 2 seconds sort of "blur-in" (like you would fade a video in by changing alpha over time). I was only able to do a simple blur for the 12 second and on: ffmpeg -i input.mp4 -vf "boxblur=enable='gte(t,12)'" -strict -2 output.mp4 Can someone help? Thanks for the help, Yariv [16:07:03 CET] <c4017> or is there there something other than alsa i can use to input audio? [16:22:41 CET] <DHE> for live audio from a sound card, alsa is probably your best bet. maybe you could use pulseaudio if you're into that kind of thing. [16:24:58 CET] <c4017> I would prefer alsa, I just dont understand why theres an error when I try to use it. [16:26:11 CET] <furq> c4017: is alsa listed in ffmpeg -devices [16:26:29 CET] <furq> if the alsa development libs/headers aren't installed when you build it then it won't be enabled [16:26:33 CET] <furq> libasound2-dev on debian-alikes [16:27:00 CET] <Sparkyish> Hi all - Looking for help with multi-channel AAC Audio encoding if anybody can point me in the right direction please. I need to encode 4 channels of full-range audio without the audio transformations and remapping that happens when using profiles like 5.1 and 7.1. These are essentially 4 mono channels that all need to be input (on the encoder) and output (on the decoder) at the same time. The audio channels are input & output via [16:27:04 CET] <Sparkyish> If I use -channels 8 on the input, and -c:a aac -ac 4, the output for ch 1 and 2 are fine, but ch 3 and 4 are output on ch 1 and 2. If I use -c:a aac -ac 6, the 5.1 profile is applied and low frequency on ch 1, 2, 5, 6 outputs on a different channel, ch 3 if fine, but ch 4 is low frequency only. Can anybody help with encoding [the first] 4 full range channels without the 5.1 effects? Thank you! [16:28:07 CET] <c_14> use the pan filter [16:29:47 CET] <Sparkyish> okay I'll read up... thank you [16:29:51 CET] <c4017> furq, nice one I didnt have libasound2-dev. Time to rebuild i guess [16:30:05 CET] <c4017> any configure flags i need? [16:31:07 CET] <furq> no [16:31:17 CET] <furq> just make sure alsa shows up in the configure output [16:31:30 CET] <furq> it's enabled by default if the deps are installed [17:17:33 CET] <nyuszika7h> [libfdk_aac @ 0x2e4d6e0] Note, the VBR setting is unsupported and only works with some parameter combinations [17:17:53 CET] <nyuszika7h> does this mean it didn't work with my parameters or how can I tell if it did VBR? it's encoding... [17:21:10 CET] <furq> nyuszika7h: what params did you use [17:21:48 CET] <nyuszika7h> ffmpeg -ss 15:00 -i in.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 18 -map 0:a:0 -c:a libfdk_aac -vbr 4 -ac 2 -t 05:00 sample.mkv -y [17:22:50 CET] <furq> oh nvm i guess i do get that warning [17:23:00 CET] <furq> i'm not sure what that's all about [17:23:07 CET] <furq> it seems to work fine anyway [17:31:11 CET] <nyuszika7h> also I've noticed tha x264 seems to use q=crf+5 most of the time at least on this source [17:51:19 CET] <acresearch> JEEB: you online? [18:31:51 CET] <acresearch> anyone online? [18:32:00 CET] <DHE> plenty. just ask your question. [18:33:35 CET] <acresearch> i ran this command: ffmpeg -i in.mkv -vf scale=1920:1080 out.mkv to scale a video down from 4k to 1080p but the file size went from 23GB to 1 !!!! did i lose quality? [18:34:30 CET] <DHE> well clearly. you didn't specify any quality options and the defaults are not very good [18:34:32 CET] <JEEB> you used libx264 with crf that is nonzero [18:34:48 CET] <JEEB> he did set crf and preset [18:34:50 CET] <acresearch> oh [18:34:59 CET] <JEEB> just didn't post it for some reason [18:35:07 CET] <DHE> oh... well that's misleading [18:35:23 CET] <furq> you also made the video a quarter of its original resolution [18:35:42 CET] <acresearch> JEEB: DHE so this would be better? ffmpeg -i in.mkv -c:v libx264 -vf scale=1920:1080 out.mkv [18:35:50 CET] <JEEB> acresearch: basically it will always be lossy coding but the thing that matters is if it looks good enough for you [18:36:07 CET] <JEEB> acresearch: default for libx264 is crf=we [18:36:11 CET] <JEEB> *23 [18:36:20 CET] <JEEB> darn touchscreens [18:36:22 CET] <acresearch> JEEB: i want to be blown with quality because it is a spacial video for me hehe [18:36:59 CET] <JEEB> if it looks bad, lower crf. if it looks good, try a higher [18:37:11 CET] <JEEB> that's how crf works [18:37:14 CET] <kepstin> acresearch: then why re-encode at all? [18:37:22 CET] <acresearch> furq: yes i 1/4 the size becuase my tv cannot handle more the 1080p, but i am surprised the file size went down so much [18:37:28 CET] <JEEB> also for the tv you used level 41 [18:37:46 CET] <JEEB> which you also left out [18:37:49 CET] <JEEB> :V [18:38:38 CET] <acresearch> JEEB: the video we made both (with your advised command) is 4GB and i kept it, i am just trying to understand how to replicate this on my own [18:38:58 CET] <JEEB> acresearch: you can't do it lossless because very few hw decoders support lossless coding, and thus you adjust crf accordingly [18:39:11 CET] <acresearch> hmmmm [18:39:37 CET] <JEEB> crf is the closest we have to "constant quality" [18:40:09 CET] <JEEB> higher value = compress more [18:40:15 CET] <acresearch> JEEB: so this command is still the best option? ffmpeg -i input.mkv -c:v libx264 -preset veryfast -level 41 -crf 21 -vf scale=1920:1080 -c:a copy -sn out.mp4 [18:40:46 CET] <JEEB> start with 23, encode about 2500 frames of content and adjust [18:41:13 CET] <JEEB> looks bad => lower, looks good => higher [18:41:14 CET] <acresearch> JEEB: -crf 21 to 23 ? [18:42:14 CET] <JEEB> that way you should find the highest value that still looks good to you [18:42:37 CET] <acresearch> so you are saying to try -crf 23? [18:43:08 CET] <JEEB> and then there's the preset which you can adjust to slower or faster [18:43:18 CET] <kepstin> acresearch: try a few different values of crf until you find one that *you* like. [18:43:25 CET] <JEEB> according to how much time you want to use [18:43:46 CET] <JEEB> veryfast is pretty much the fastest useful one [18:44:13 CET] <acresearch> so i should remove -preset veryfast? [18:44:16 CET] <JEEB> (crf values are not exactly the same between presets, so you'd have to adjust) [18:44:54 CET] <JEEB> I'm telling you that if you want to adjust your compression, that's how you do it [18:45:16 CET] <acresearch> JEEB: ok 1 moment, let me write these down so i memorise them [18:45:36 CET] <acresearch> -crf is the compression rate?quality? 23 is best? [18:45:47 CET] <JEEB> also -level 41 you shouldn't remove, it makes sure the thing plays on your hardware plastic toy [18:46:00 CET] <JEEB> oh for fuck's sake [18:46:18 CET] <kepstin> acresearch: -crf is an "constant quality" more or less; lower numbers look better, higher numbers give smaller files, there is no such thing as "best" [18:46:38 CET] <acresearch> oohhhhh [18:46:44 CET] <JEEB> 23 is the fucking default and it's high enough so that you might see artifacts depending on things [18:47:33 CET] <JEEB> if you didn't set a preset and crf in your random 1gb test then it set crf=23, preset=medium [18:48:05 CET] <JEEB> which unsurprisingly is fucking smaller than 21,veryfasy [18:48:06 CET] <acresearch> JEEB: ok i get it [18:48:21 CET] <JEEB> *veryfast [18:48:41 CET] <acresearch> ok and for -level 41 i leave the same correct? what is level 41? [18:49:18 CET] <furq> https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels [18:49:57 CET] <JEEB> that sets level to 4.1. as in tells the encoder to limit memory requirements for the encoded stream within that level [18:50:18 CET] <JEEB> so that fucking plastic boxes can decode the result [18:50:41 CET] <JEEB> (level 4.1 is the most common for HD things) [18:51:13 CET] <acresearch> ohhhh [18:52:34 CET] <acresearch> JEEB: ok, don't kill me: one last thing -> what is -preset veryfast? [18:52:45 CET] <JEEB> libx264 preset [18:52:57 CET] <JEEB> compression vs speed [18:53:10 CET] <furq> slower presets compress better but take longer (hence the name) [18:53:30 CET] <acresearch> i don't care about speed, if i left it out as furq said will take long time but compresses better? [18:53:47 CET] <kepstin> acresearch: the default is "medium". If you don't care about time, then use "-preset veryslow" [18:53:47 CET] <JEEB> -preset placebo is slowest [18:53:53 CET] <furq> if you omit it then it'll use preset medium [18:53:55 CET] <furq> yeah what kepstin said [18:54:12 CET] <JEEB> veryslow is the one that is the slowest generally recommended for use [18:54:19 CET] <furq> veryslow at 1080p will be pretty slow [18:54:25 CET] <furq> you might even say very slow [18:54:37 CET] <acresearch> ok i get it :-) [18:54:42 CET] <acresearch> thanks guys :-) [18:55:01 CET] <JEEB> well I am waiting for this bastard to soon complain about speed [18:55:14 CET] <furq> that's what ctrl-c is for [18:55:29 CET] <JEEB> le sigh [18:55:46 CET] <acresearch> me? haha no i care about quality more than speed [19:44:18 CET] <c4017> So I have a webcam that outputs h264, but the bitrate is 4 Mbit/s regardless of framerate and resolution. Is there someway to decrease bitrate without having to re-encode? [19:45:06 CET] <JEEB> no [19:45:31 CET] <JEEB> unless it is pushing out padding, which I would guess it isn't [19:46:45 CET] <c4017> How else could it make a 10fps 320x240 video so damn big? [19:47:59 CET] <JEEB> just using low quantizers? [19:48:13 CET] <JEEB> I meae/32 [19:49:44 CET] <c4017> I wonder if I can communicate with the webcam to make it output a lower bitrate... [19:51:36 CET] <alexpigment> i'm trying to build a leaner install of ffmpeg for win64 and seeing what I can disable. does libwavpack get used all for processing normal PCM audio, either encoding or decoding? [19:51:53 CET] <furq> no [19:52:11 CET] <alexpigment> furq: thanks. do you know what it's used for? [19:52:16 CET] <furq> it's used for encoding wavpack [19:52:26 CET] <furq> https://en.wikipedia.org/wiki/WavPack [19:52:27 CET] <alexpigment> just that? ok cool [19:52:37 CET] <alexpigment> i saw the website and it made it seem like it did a lot more [19:52:46 CET] <alexpigment> anyway, disabled now. thanks furq [19:54:08 CET] <furq> apparently there's an internal wavpack encoder now so you don't even need libwavpack for that [19:54:41 CET] <furq> i'm not really sure why anyone bothered to implement that in 2017 [20:21:23 CET] <alexpigment> do you guys know if opencore-amr is necessary for *decoding* either AMR WB or NB? [20:21:26 CET] <alexpigment> or is it just encoding? [20:21:48 CET] <furq> https://www.ffmpeg.org/general.html#Audio-Codecs [20:23:02 CET] <alexpigment> yeah i already read that [20:23:08 CET] <alexpigment> the thing i'm confused about is "FFmpeg can make use of the OpenCORE libraries for AMR-NB decoding/encoding and AMR-WB decoding." [20:23:18 CET] <alexpigment> *can make use of* in particular [20:23:38 CET] <alexpigment> if i just need basic decoding, do i need to enable opencore-amr? [20:24:33 CET] <furq> doesn't look like it [20:24:56 CET] <alexpigment> k, thanks for the info [20:25:09 CET] <furq> i can decode amr_nb and i don't have opencore installed [20:29:28 CET] <alexpigment> ok, thanks for confirming that [20:46:01 CET] <JEEB> alexpigment: `ffmpeg -codecs |grep "amr"` should show you decoders and encoders for amr [20:46:34 CET] <JEEB> I've just built FFmpeg without any specifically enabled libraries [20:46:50 CET] <JEEB> amrnb/wb both have internal decoders available in the list [20:47:10 CET] <JEEB> no encoders, which is for what I expect opencore be used [20:47:18 CET] <alexpigment> JEEB: thanks for the info. i suppose it's not a bad idea to build a copy without any external libraries to test against in the future [20:48:00 CET] <alexpigment> there are other situations i'm not sure about, like whether libtwolame is preferable to the built-in MPEG-2 encoder, so that could be good to test with [20:48:19 CET] <JEEB> libtwolame is only mp2 audio [20:48:49 CET] <alexpigment> jeeb: but that includes mp2 audio within a DVD formatted stream, right? [20:48:58 CET] <JEEB> uhh [20:49:03 CET] <JEEB> DVD Video doesn't support mp2 [20:49:13 CET] <JEEB> raw PCM, AC3 or DTS [20:49:13 CET] <alexpigment> well, technically you might be right [20:49:19 CET] <alexpigment> it's official in PAL countries [20:49:26 CET] <JEEB> in *broadcast*, yes [20:49:30 CET] <alexpigment> and unofficially supported by almost everything in the US [20:49:39 CET] <JEEB> but for *broadcast* all receivers by now support AAC [20:49:45 CET] <alexpigment> no, MP2 is 100% part of the PAL DVD spec [20:49:46 CET] <JEEB> or AC3 [20:49:57 CET] <JEEB> uhh [20:50:07 CET] <alexpigment> and MP2 is unofficially supported by ~all DVD players in NTSC regions [20:50:13 CET] <JEEB> I'd be deeply surprised since I don't think I've ever seen a PAL DVD with mp2 [20:50:17 CET] <alexpigment> JEEB: trust me on this one [20:50:19 CET] <JEEB> and I'm from PAL areas [20:50:23 CET] <furq> it's part of the spec [20:50:27 CET] <JEEB> wow [20:50:28 CET] <JEEB> ok [20:50:30 CET] <JEEB> TIL [20:50:39 CET] <alexpigment> to be fair, it's not used commercially for any reason [20:50:43 CET] <JEEB> that said, why on earth would you use mp2 [20:50:51 CET] <JEEB> AC3 and PCM are available [20:50:52 CET] <alexpigment> to avoid ac-3 licenses and save bandwidth [20:51:00 CET] <alexpigment> PCM is 1.5mbps of your total bandwidth [20:51:00 CET] <furq> i think i might actually have seen it but i don't remember where [20:51:10 CET] <JEEB> ok, ~kind of makes sense [20:51:19 CET] <alexpigment> it's common for consumer-grade software that creates DVDs [20:51:47 CET] <furq> i've definitely seen lpcm on video dvds [20:51:49 CET] <alexpigment> ac-3 licensing is expensive, and it doesn't gain much over AC-3 if you're just encoding 2-channel audio [20:51:54 CET] <furq> that's probably quite a bit more common though [20:51:58 CET] <alexpigment> LPCM is very common, yes [20:52:06 CET] <alexpigment> especially on music DVDs [20:52:21 CET] <JEEB> I've seen a lot of TV show DVDs from Japan with LPCM [20:52:31 CET] <alexpigment> i own a lot of music video DVDs from various artists - probably a few hundred - and a good chunk of them use LPCM [20:53:19 CET] <JEEB> also AC-3 patents are running out as far as I can see as dolby made AC-4 as its next-gen cash grab [20:53:41 CET] <alexpigment> yeah, i'm kind of doing this as a safety measure tbh [20:54:03 CET] <alexpigment> but yeah, a lot of the DVD-era patents are expiring [20:54:06 CET] <JEEB> I'm not sure of the AC-3 licensing anyways [20:54:08 CET] <furq> yeah i've only seen lpcm on japanese dvds [20:54:10 CET] <alexpigment> MPEG-2 video got WAY cheaper last year [20:54:24 CET] <JEEB> since you're not using Dolby's software to encode [20:54:30 CET] <furq> lol what ac-4 [20:54:37 CET] <JEEB> furq: there's even samples of it out there [20:54:40 CET] <JEEB> but no real usage [20:54:40 CET] <alexpigment> yeah i've not heard of ac-4 either [20:54:42 CET] <furq> oh man [20:54:45 CET] <JEEB> because it's a meme format [20:54:54 CET] <JEEB> similar to MPEG-H Audio [20:55:11 CET] <furq> When tested for ATSC 3.0 the bit rates needed for the required audio score was 96 Kbit/s for stereo audio, 192 Kbit/s for 5.1 channel audio, and 288 Kbit/s for 7.1.4 channel audio. [20:55:12 CET] <alexpigment> man, MPEG-H? lol. i think i've seen that written a total of 1 time [20:55:14 CET] <furq> so it's aac then [20:55:24 CET] <furq> except with new and exciting patents [20:55:39 CET] <JEEB> alexpigment: it only has one semi-sane thing in it anyways, MPEG-H Part 2 which is HEVC [20:55:55 CET] <alexpigment> furq: is this whole thing another way to get HEVC OTA without people actually investing money into doing it right? ;) [20:56:16 CET] <JEEB> no, they're investing money into going the way of dodo with MPEG-H Part 1 [20:56:19 CET] <JEEB> which MMT [20:56:22 CET] <alexpigment> JEEB: ah, i didn't realize that was part of that [20:56:24 CET] <JEEB> which is insane, just fyi [20:56:40 CET] <JEEB> NHK is all mouth foaming about MMT/MMTP as well [20:56:49 CET] <JEEB> NOM NOM IP OVER BROADCAST [20:57:30 CET] <JEEB> at least ARIB (the Japanese broadcast standards body) made specs for both MMTP and MPEG-2 TS next-gen broadcast [20:58:00 CET] <alexpigment> ARIB also did the HLG standard, right? [20:58:28 CET] <JEEB> ARIB has it standardized as ARIB STD-B.67, yes [20:58:51 CET] <JEEB> and both SMPTE ST.2084 and HLG are in BT.2100 [20:58:55 CET] <alexpigment> yeah, i've been dealing with a lot of HDR lately, so i end up typing arib-std-b67 a lot [20:59:18 CET] <JEEB> -32 [20:59:19 CET] <alexpigment> yeah, i know bt.2100 is an overarching thing, but i don't really know the distinction [20:59:28 CET] <JEEB> BT.2100 just contains various things for HDR [20:59:45 CET] <JEEB> so that you don't have to go outside ITU-T to read about HLG and SMPTE ST.2084 [20:59:59 CET] <alexpigment> ahh [21:00:26 CET] <JEEB> talking of HDR I should really get my thing ready with zimg support .-. [21:00:56 CET] <alexpigment> what is zimg in relation to HDR? [21:01:07 CET] <JEEB> https://github.com/sekrit-twc/zimg [21:01:25 CET] <alexpigment> oh gotcha [21:01:35 CET] <alexpigment> the colorspace conversion [21:02:02 CET] <JEEB> haven't got any real sources with HDR video, kind of wished I could capture float video out of games :P [21:02:32 CET] <alexpigment> well, i'm coming at it from the other realm, which is creating native HDR from RAW images [21:02:46 CET] <alexpigment> rather, creating native HDR video streams [21:03:01 CET] <JEEB> well yeah, that's why I'd like float output out of apps :P [21:03:18 CET] <alexpigment> yeah i hear you [21:04:15 CET] <JEEB> something like iD tech having float output with demos or so :V [21:04:22 CET] <JEEB> since you can render demos as slowly as you want [21:04:23 CET] <alexpigment> btw, if you need HDR video to test with, there's a free site that aggregates a lot of them [21:04:48 CET] <alexpigment> http://demo-uhd3d.com/ [21:05:08 CET] <JEEB> yeah, I used some of those on my TV as I first got it [21:05:32 CET] <alexpigment> i'm still very much in SDR land at home [21:05:34 CET] <JEEB> but I'm more interested in testing with lossless sources [21:05:54 CET] <alexpigment> well, if you have after effects, you can create simulations [21:06:05 CET] <JEEB> btw, do you know of any actual HLG content? [21:06:17 CET] <JEEB> I know BBC said they'd publish stuff but that was for limited amount of hardware [21:06:19 CET] <alexpigment> pretty sure i have some demo vides [21:07:11 CET] <alexpigment> http://demo-uhd3d.com/fiche.php?cat=uhd&id=154 [21:07:13 CET] <JEEB> oh, travelxp actually used HLG [21:07:23 CET] <JEEB> yea, that's the one [21:07:39 CET] <JEEB> finally a real life sample of it :P [21:07:44 CET] <alexpigment> haha [21:07:49 CET] <JEEB> I mean, it's all good and fun to implement it from the spec [21:08:00 CET] <JEEB> but not being able to test is not fun [21:08:07 CET] <alexpigment> yep [21:08:21 CET] <alexpigment> i'm still getting my head around the specs and what's required for the various formats [21:08:43 CET] <alexpigment> i just want to let it all shake out and one format just become the main one [21:08:49 CET] <alexpigment> but that doesn't seem to be happening yet [21:09:08 CET] <alexpigment> HLG is promising though, due to its graceful fallback to SDR [21:09:34 CET] <JEEB> well the BT.2020 part is already set, and thus you are only left with two different EOTFs [21:09:44 CET] <JEEB> either HLG or SMPTE ST.2084 [21:15:15 CET] <alexpigment> maybe i've got my info mixed up [21:15:37 CET] <alexpigment> i thought that HDR10 and DolbyVision both looked incorrect on a TV where they weren't supported, but HLG looked correct [21:16:12 CET] <alexpigment> "correct", i should say [21:16:46 CET] <JEEB> well if your thing doesn't support the colorimetry specified at all then you're fscked anyways. HLG just IIRC has somewhat better changes of looking better [21:17:00 CET] <JEEB> saying things "look correct" with hardware at this point is *really* hard [21:17:11 CET] <JEEB> even if the thing implements colorimetry correctly [21:17:12 CET] <alexpigment> that is a very true statement [21:17:35 CET] <JEEB> because there is no standard on how to handle out-o-range values and tone mapping etc [21:18:01 CET] <alexpigment> well i think the deal is that HLG's defining characteristics are largely in the metadata [21:18:17 CET] <alexpigment> so in absence of the metadata, it's a 10-bit SDR video [21:18:25 CET] <alexpigment> (in bt2020) [21:19:02 CET] <JEEB> uhh, I wouldn't put it like that [21:19:25 CET] <JEEB> but the EOTF on a certain range of values is gamma [21:19:31 CET] <alexpigment> i'm not speaking from any sort of authority here. that's just what i remember when reading up on it [21:20:13 CET] <JEEB> so on that range of values as long as the rest of it is supported correctly you will get possibly a better looking result than with SMPTE ST.2084 [22:16:42 CET] <JEEB> btw, if anyone here is maintaining the wiki, x11grab was just removed with xcbgrab being the more modern alternative [22:16:51 CET] <JEEB> pls update desktop capture pages etc [22:19:35 CET] <JEEB> (-f x11grab will still work, but it's better to use the actual name) [22:21:25 CET] <kepstin> but... what about my sunos5 box that doesn't have libxcb? ... (I kid, I kid...) [22:22:07 CET] <JEEB> just rejoice that *something* got removed from FFmpeg for once (although it came from a Libav merge and thus totally went in through a push instead of ML drama) [22:28:58 CET] <alexpigment> ok, so i just finished some Windows FFMPEG builds, now i'm moving onto OS X builds. usually i just run "brew install ffmpeg" and several --with-[library] flags [22:29:18 CET] <alexpigment> but there are no --with-nvenc or --with-qsv options [22:29:27 CET] <alexpigment> anyone know what i need to do to build with those enabled? [22:29:32 CET] <BtbN> both don't exist on OSX. [22:29:47 CET] <thebombzen> how does one put an NVidia card inside of a mac [22:29:59 CET] <JEEB> still doesn't mean that API works [22:30:00 CET] <alexpigment> thebombzen: lots of macs come with them [22:30:12 CET] <thebombzen> that doesn't answer my question [22:30:16 CET] <alexpigment> anyway, so you're saying that at this point, neither nvenc or qsv will work on a mac via ffmpeg [22:30:21 CET] <thebombzen> hwo does one *put* an nvidia card inside of a mac [22:30:25 CET] <BtbN> they simply don't exist on OSX. [22:30:34 CET] <alexpigment> k, thanks BtbN [22:30:42 CET] <alexpigment> thebombzen: i'm not sure if you're even asking a real question here [22:31:15 CET] <thebombzen> basically I'm asking if Apple still solders everything together and makes it so you can't customize it [22:31:27 CET] <alexpigment> yeah, they do [22:31:43 CET] <alexpigment> and they switch GPU vendors seemingly every year [22:32:12 CET] <alexpigment> so if you're buying a laptop or desktop, it'll vary from year to year [22:32:31 CET] <alexpigment> having said that, the Mac Pro *was* a modular PC up until a few years ago [22:32:50 CET] <alexpigment> in which case, you could definitely put an Nvidia card in it the same way you would a PC [22:33:36 CET] <alexpigment> having said all that, i think statistically most Macs with dedicated GPUs use Nvidia [22:34:11 CET] <kepstin> hmm, they've switched back and forth a few times. a lot of the older macbook pros had amd. [22:34:28 CET] <BtbN> Apple has the crazy habit of writing their own drivers for everything [22:34:28 CET] <kepstin> all their recent models have been nvidia tho, i think [22:34:37 CET] <BtbN> Even GPUs [22:35:26 CET] <kepstin> but yeah, if Apple has exposed hardware video encoder/decoder support, it's probably just via the quicktime apis :/ [22:35:40 CET] <alexpigment> yeah, i mean we know they're using those technologies [22:35:55 CET] <alexpigment> airplay is most certainly using QuickSync [22:36:09 CET] <JEEB> yeah, they have videotoolbox [22:36:13 CET] <JEEB> also QT APIs are being actively removed [22:36:15 CET] <alexpigment> although i'm not sure if they use Nvenc / VCE on systems with dGPUs [22:36:26 CET] <JEEB> IIRC the latest xcode removed headers [22:37:05 CET] <kepstin> huh, is videotoolbox on the desktop macs? I was under the impression that was used on ios [22:37:16 CET] <JEEB> I think it was a common Apple API [22:38:15 CET] <thebombzen> wait [22:38:24 CET] <thebombzen> writing your own driver defeats the whole point of nvidia [22:38:30 CET] <alexpigment> haha [22:38:34 CET] <thebombzen> that's why nvidia cards are better than ati [22:38:38 CET] <thebombzen> cause the drivers are better [22:38:44 CET] <alexpigment> that's not the *only* reason [22:38:47 CET] <alexpigment> but yeah, it's a reason [22:38:57 CET] <thebombzen> ati has faster hardware but nvidia has better real-world performance because the drivers are really really good [22:39:00 CET] <thebombzen> or one of the reasons [22:39:09 CET] <thebombzen> but yea it defeats one of the major points of nvidia [22:39:33 CET] <alexpigment> i just don't think of AMD as a company that provides professional products [22:39:38 CET] <alexpigment> i know that doesn't mean a lot [22:39:39 CET] <alexpigment> but [22:39:45 CET] <matkatmusic> termos: Just saw your comment after my question. "I remember seeing this new encoding/decoding API in libFFmpeg where you push and retrieve frames somehow, similar to filter graphs. Not the got_pkt integer that's being set in avcodec_encode_video2" [22:40:08 CET] <alexpigment> it's pervasive throughout the industry. if you use professional video editing and creation software, AMD is unheard of [22:41:01 CET] <alexpigment> then again, i think it's just that they got their foot in the door with CUDA and NVENC early enough that developers utilized those technologies [22:41:10 CET] <kepstin> as far as video editing stuff goes, yeah, nvidia got pretty big buy-in with their proprietary 'cuda' gpgpu stuff, and nvenc seems easier to use than UVC [22:41:14 CET] <alexpigment> AMD lagged behind on hardware encoding and computing [22:41:31 CET] <matkatmusic> I'm wondering if that was answering my question about specifying a jpg to use AT a specific frame number FOR a specific number of frames. [22:41:35 CET] <kepstin> of course anyone seriously doing professional video editing shouldn't be using a hardware encoder, imo :) [22:42:06 CET] <alexpigment> kepstin: i disagree with that. perhaps for the actual video encoding of the final product, yes [22:42:23 CET] <alexpigment> but cuda is very helpful for a lot of processing functions [22:42:24 CET] <JEEB> after nvidia started supporting lossless coding it became much more relevant for me [22:42:30 CET] <kepstin> i suppose if you throw a ton of bitrate at it, nvenc might not be that bad as intermediate [22:42:44 CET] <alexpigment> and nvenc is great for quick draft stuff [22:47:19 CET] <alexpigment> anyone have any word on VCE being integrated into FFMPEG? [22:48:58 CET] <BtbN> Nobodys going to stop you if you do [22:58:58 CET] <kepstin> huh, looks like there's some linux drivers for it that provide the openmax (omx) api, it might be possible to get that working with ffmpeg - who know how much work that would need, tho... [23:01:46 CET] <jkqxz> Like all good OpenMAX IL implementations, it has it's own set of conflicting assumptions about how the API should work. (It doesn't work at all with the lavc client.) [23:04:01 CET] <alexpigment> BtbN: nobody will stop me except my complete lack of coding ability ;) [23:08:16 CET] <jkqxz> It kindof works with VAAPI, but not very well. Good enough for simple encoding (upload + encode), not really usable for GPU transcode or doing anything interesting. [23:15:50 CET] <alexpigment> kepstin: just looked into a OpenMax a little bit. i didn't know too much about it until now, but it's good to know it exists (and potentially paves a path to AMD hardware encoding in FFMPEG) [23:16:39 CET] <alexpigment> with all the 4K HEVC stuff that's going on, we're rapidly pushing ourselves into a corner in terms of processing requirements for video encoding [23:17:16 CET] <alexpigment> so the hardware encoders are going to need to get better and more customizable [23:17:44 CET] <alexpigment> because i don't see CPUs getting significantly faster anytime soon [23:18:25 CET] <kepstin> for large-scale batch video processing, it's normally scaled horizontally by segmenting files and encoding them over many cpus [23:18:43 CET] <kepstin> but that doesn't really help for the video workstation use case ;) [23:18:47 CET] <alexpigment> yeah, but what about stuff that is done in realtime? [23:19:54 CET] <alexpigment> the TV market is saying "this is ready for primetime", but the computer industry is saying "whoa... slow down buddy" [23:20:53 CET] <alexpigment> i don't even know how TV networks will be able to make the conversion to 4K HEVC [23:21:10 CET] <kepstin> half of them haven't even switched from mpeg2 to h264 [23:21:12 CET] <kepstin> so, yeah... [23:21:50 CET] <alexpigment> well if you're talking about regional affiliates for major networks, i doubt any of them have switched over [23:22:08 CET] <TD-Linux> by encoding really bad quality HEVC [23:22:20 CET] <alexpigment> and yeah, it doesn't benefit the major networks to go from MPEG-2 to H.264 because they're just going to get re-encoded anyway by the cable and satellite companies [23:22:39 CET] <kepstin> I suppose really bad quality HEVC has the potential to be better than really bad quality H264 :/ [23:22:51 CET] <alexpigment> hmmmm [23:23:08 CET] <alexpigment> i just think H.264 is still very viable for 4K [23:23:14 CET] <TD-Linux> the local feed at work is horrific enough that they have a long ways to before 4k even makes sense [23:23:34 CET] <alexpigment> and the only reason HEVC exists is because of people thinking that bandwidth and storage is still at a premium [23:23:43 CET] <TD-Linux> it is [23:25:25 CET] <alexpigment> i don't know. i think a 20-30mbps H.264 is good enough for 4K streaming, and 60mbps+ is good enough for Blu-ray [23:25:48 CET] <alexpigment> *4k Blu-ray [23:26:24 CET] <alexpigment> a 30mbps H.264 broadcast standard for 4K wouldn't be terrible in my opinion [23:26:54 CET] <alexpigment> it would probably be a hell of a lot better than the 10-12mbps MPEG-2 that my local stations put out [23:27:32 CET] <TD-Linux> sure but where is your magical 20mbps extra coming from [23:28:34 CET] <alexpigment> that's exactly the point i was trying to make earlier. these standards are always assuming a worst-case scenario in terms of bandwidth [23:29:13 CET] <alexpigment> ATSC is 18mbps (and then further divided up into HD and SD streams), but it doesn't have to be [23:29:29 CET] <alexpigment> especially considering that people don't rely as much on OTA feeds [23:30:00 CET] <alexpigment> but DVB-T is already there in terms of their spec, right? [23:31:35 CET] <TD-Linux> only if you're willing to throw away a lot of range [23:32:19 CET] <alexpigment> td-linux, we already threw away most of that range when OTA switched to digital [23:32:42 CET] <TD-Linux> come on it's a function of symbol rate [23:33:10 CET] <alexpigment> ? [23:33:24 CET] <TD-Linux> there is a direct tradeoff between bitrate and range [23:33:31 CET] <alexpigment> yes, of course there is [23:33:50 CET] <TD-Linux> you want to run at 64-QAM with highest rate? [23:33:51 CET] <alexpigment> and what i'm saying is that we already threw away most of the range of "watchable tv" when the digital switch happened [23:34:35 CET] <alexpigment> if you don't have a perfect digital signal, it's basically unwatchable. if you had a less-than-optimal analog signal, it was very watchable [23:35:33 CET] <TD-Linux> might as well do a gigabit stream that goes 10 feet then :^) [23:35:52 CET] <alexpigment> TD-Linux 801.11AD? [23:35:57 CET] <alexpigment> ;) [23:36:00 CET] <TD-Linux> whoa dvb-t2 does qam-256 [23:36:05 CET] <alexpigment> yes [23:36:18 CET] <alexpigment> DVB is way more aggressive on their bitrate standards [23:36:35 CET] <alexpigment> ATSC is based on the assumption that most americans live far from cities [23:50:15 CET] <shincodex> av_dict_set(&options, "rtsp_transport", "tcp", 0); [23:50:22 CET] <shincodex> force this on RTSP when your h264 is a piece of shit [23:50:38 CET] <shincodex> To anyone else who is getting trolled by college kids this will help you [23:50:53 CET] <JEEB> sounds like a crappy network or connection [23:51:00 CET] <shincodex> thats the thing [23:51:01 CET] <JEEB> where UDP is getting fscked [23:51:08 CET] <shincodex> I thought it was buffer size [23:51:23 CET] <shincodex> but then i was like well turn it all off yep... shite and lo! ffmpeg log spam of problems [23:51:40 CET] <shincodex> turn that one on and its fine... its fine... [23:52:03 CET] <JEEB> ordering and making sure packets can come through don't help latency but can help with getting data through :P [23:53:55 CET] <shincodex> I upset another guy last night [23:54:00 CET] <shincodex> cause of my frusteration [23:54:08 CET] <shincodex> "X" works better than "Y [23:54:09 CET] <shincodex> " [23:54:26 CET] <shincodex> vlc is "Y" and "Y" tells me... ahhh no we no use lavc we use gpu [23:54:34 CET] <shincodex> and i says... THAT DOESNT HELP ME FIGURE SHITE OUT [23:54:37 CET] <shincodex> I USE GPU TOO [23:54:42 CET] <shincodex> AND CPU! [23:54:45 CET] <shincodex> fpu1111111 [23:54:47 CET] <shincodex> woohoo [23:59:53 CET] <shincodex> Welcome to your doom [00:00:00 CET] --- Thu Mar 16 2017

1 0

ffmpeg-devel.log.20170314
by burek 15 Mar '17

15 Mar '17

[00:02:29 CET] <BtbN> https://community.amd.com/community/gaming/blog/2017/03/13/amd-ryzen-commun… AMD please... "Specifically, the AMD Ryzen" 7 1700X and 1800X carry a +20°C offset between the tCTL° (reported) temperature and the actual Tj° temperature. In the short term, users of the AMD Ryzen" 1700X and 1800X can simply subtract 20°C to determine the true junction temperature of their processor." [00:02:53 CET] <BtbN> They could at least have made their software substract that again [00:03:04 CET] <BtbN> countless people are desperately trying to fix their cooling [00:04:40 CET] <iive> LOL [00:05:21 CET] <nevcairiel> the entire page is full of "our stuff works fine, re-write your software" =p [00:05:22 CET] <JEEB> :D [00:05:57 CET] <BtbN> Well, except for the weird temperature, which is explained by that, I didn't have any issues with the CPU itself [00:06:02 CET] <BtbN> Only the Mainboard behaves weird [00:06:13 CET] <BtbN> Do one wrong setting, and you have to perform some voodoo to make it boot again [00:06:20 CET] <BtbN> Clear CMOS does not clear the CMOS all the time [00:06:28 CET] <nevcairiel> everyone has been blaming performance issues on the scheduling, and amd just says "its fine", guess they need a new rumor [00:06:40 CET] <BtbN> There are no performance issues [00:06:53 CET] <BtbN> A CPU with slightly worse IPS, on a lower clock, is bound to be slower. [00:07:03 CET] <nevcairiel> tell that to everyone else [00:07:04 CET] <BtbN> It performs exactly as I'd have expected. [00:07:16 CET] <BtbN> *IPC [00:07:50 CET] <BtbN> Lets just hope they push the 4 core variant to 4GHz+ on stock settings [00:07:56 CET] <nevcairiel> I mean, just days ago your claimed that there were issues yourself [00:07:57 CET] <nevcairiel> :) [00:07:59 CET] <BtbN> A 3.6GHz Quad Core will have a hard time otherwise [00:08:07 CET] <BtbN> Performance issues? [00:08:16 CET] <nevcairiel> its a cpu, what else can there be [00:08:23 CET] <BtbN> Way too high temperature [00:08:28 CET] <nevcairiel> [22:05:46] <BtbN> Windows still has massive issues with the NUMA like architecture of Ryzen [00:08:28 CET] <nevcairiel> [22:05:55] <BtbN> And with the asymetric SMT [00:08:28 CET] <BtbN> which is explained by the CPU adding 20° [00:08:31 CET] <nevcairiel> thats what i meant ^ [00:08:43 CET] <nevcairiel> AMD says all is fine, apparently [00:08:50 CET] <BtbN> ah, that [00:09:04 CET] <BtbN> Yeah, the Ryzen 8 core is basically two 4 core CPUs in a NUMA-Like setup [00:09:16 CET] <BtbN> so migrating threads between the first 4 cores to the last 4 ones is slow [00:09:46 CET] <BtbN> OS scheduler does not seem to address that yet [00:09:51 CET] <BtbN> But under full load it doesn't matter [00:10:00 CET] <nevcairiel> seems like a dumb design if you make the bus between those so slow that its noticeable [00:10:24 CET] <iive> BtbN: NUMA on a single core?! [00:10:36 CET] <iive> i mean, sincle CPU die [00:10:38 CET] <nevcairiel> that AMD page still claims all is fine with scheduling [00:11:08 CET] <BtbN> Probably only time will tell what actual performance there is to gain by scheduler-patches [00:11:24 CET] <nevcairiel> its because the two core complexes don't fully share the caches [00:12:24 CET] <nevcairiel> L3 cache is local to a core-complex (ie. a 4 core unit) [00:13:00 CET] <nevcairiel> while intel cpus have a central shared L3 for all cores [00:13:49 CET] <iive> is l3 the closest to cpu or the one further? [00:13:56 CET] <BtbN> L1 is closest [00:13:57 CET] <nevcairiel> l3 is the furthest [00:14:01 CET] <iive> i think l1 should be closest [00:14:13 CET] <nevcairiel> L1 and L2 are linked to one core only, though [00:14:19 CET] <BtbN> http://valid.x86.fr/hqdvq3 [00:14:47 CET] <BtbN> shows the Caches in the screenshot [00:14:48 CET] <nevcairiel> L3 is typically the only cache shared between cores [00:15:01 CET] <BtbN> Yeah, it has 2x8192kB [00:15:07 CET] <nevcairiel> but on ryzen its only shared between half the cores [00:15:11 CET] <BtbN> so 8MB for each 4 core cluster [00:15:25 CET] <iive> so, 8 core version is actually 2xCPU(4cores) that run in NUMA? [00:15:32 CET] <BtbN> Not actual NUMA [00:15:46 CET] <BtbN> But if a thread gets migrated accross the clusters, the L3 cache is lost/need to ge moved [00:15:51 CET] <BtbN> *be [00:16:07 CET] <iive> maybe that's the problem. actual numa cares care of such migrations. [00:16:17 CET] <BtbN> Windows is not good at actual NUMA [00:16:18 CET] <iive> btw, do you have numa enabled in the kernel? [00:16:40 CET] <BtbN> No idea what microsoft enables in their Kernel [00:16:52 CET] <iive> BtbN: you don't run linux? [00:16:56 CET] <BtbN> no [00:17:04 CET] <iive> sorry, for assuming that. [00:18:14 CET] <iive> at least in the past, microsoft enabled different kernels, depending on the cpu during installation. [00:18:31 CET] <iive> no idea if they are unified now, or if they allow change after install. [00:18:43 CET] <nevcairiel> there are ways to change, but its tricky [00:18:46 CET] <BtbN> They only need to slightly change scheduler policy [00:18:57 CET] <nevcairiel> but AMD said its fine [00:18:57 CET] <nevcairiel> :p [00:19:07 CET] <iive> no [00:19:08 CET] <BtbN> It tends to move threads around on single-core loads [00:19:21 CET] <BtbN> So they need to teach it to only do that on the same cluster [00:20:55 CET] <iive> what flavor of windows are you running? desktop, server ? [00:20:59 CET] <BtbN> 10 [00:21:19 CET] <BtbN> Not going to touch 8/8.1 [00:21:23 CET] <BtbN> And Win7 is a nightmare [00:21:41 CET] <BtbN> Spent an entire day installing Win7 on a friends new 1700X system [00:22:06 CET] <BtbN> need to splitstream the USB drivers into the installer. Otherwise you have no mouse and keyboard [00:22:29 CET] <iive> ? [00:22:32 CET] <nevcairiel> you can usually cheat by putting the mainboard into legacy usb mode [00:22:36 CET] <BtbN> No [00:22:42 CET] <nevcairiel> at least on intel boards that option exists [00:22:48 CET] <BtbN> The AM4 platform has no EHCI mode anymore [00:22:57 CET] <BtbN> everything, even the USB2 controlers, run via XHCI [00:23:03 CET] <nevcairiel> seems like a silly idea to strip that [00:23:13 CET] <BtbN> It's normal, the Kaby Lake platform does the same [00:23:24 CET] <BtbN> You have the same issues installing Win7 there [00:23:31 CET] <iive> win7 needs another service pack [00:23:41 CET] <BtbN> Microsoft wants it to die [00:23:42 CET] <nevcairiel> my Z170 board at least still had the uefi option to enable legacy usb [00:23:45 CET] <BtbN> so not going to happen [00:23:47 CET] <rcombs> does anyone have a DTS-HD sample that actually requires 8-channel SPDIF bandwidth? [00:24:04 CET] <BtbN> You can enable legacy USB, but it has no effect on stuff booted in UEFI mode [00:24:09 CET] <iive> yeh, but i'm not touching 8 or 10. [00:24:13 CET] <BtbN> And to install on an NVMe drive, you are bount to use UEFI boot [00:24:22 CET] <BtbN> *bound [00:26:21 CET] <iive> what is nvme drive? non volatile memory? ssd ? flash? NAND/NOR ? [00:27:38 CET] <nevcairiel> NVMe drives are PCIe based SSDs [00:28:35 CET] <iive> do they allow directly mapping NAND memory into address space? [00:29:14 CET] <nevcairiel> rcombs: i dont know about needing full bandwidth, but there is really no point, its either SPDIF which is limited to non-HD formats anyway, or its HDMI, which supports full bandwidth either way [00:29:35 CET] <wm4> "Is there someone trying to upgrade the crystalhd code? This device is old, but is still useful. I hope I'm not the only one using it." [00:29:43 CET] <wm4> I'm afraid that might be the case... [00:30:01 CET] <rcombs> nevcairiel: in theory SPDIF is limited to non-HD-only, but some HD bitstreams fit anyway [00:30:24 CET] <rcombs> nevcairiel: and some fit in 6 channels but not 8, and some devices support 6-channel output bandwidth but not 8-channel over HDMI for whatever reason [00:30:25 CET] <wm4> <rcombs> does anyone have a DTS-HD sample that actually requires 8-channel SPDIF bandwidth? <- I thought all dts-hd does [00:30:46 CET] <nevcairiel> rcombs: screw special device hacks, call it a day [00:30:57 CET] <nevcairiel> support full HDMI specs, and not some cheap crap that implements them wrong [00:31:01 CET] <wm4> and I never heard about using 6 channels for that [00:31:17 CET] <nevcairiel> me neither [00:31:17 CET] <rcombs> lavf has code for it in spdifenc [00:31:19 CET] <iive> wm4: the rule is, for everybody who complains there are 9 that do not. [00:31:22 CET] <nevcairiel> DTS-HD always transmit from 8ch 192khz for me [00:32:00 CET] <wm4> the lavf cares only about output bitrate [00:32:08 CET] <wm4> which you adjust via dtshd_rate [00:32:08 CET] <rcombs> see spdif_header_dts4 [00:32:35 CET] <rcombs> if you get packets too big then it strips to core [00:32:38 CET] <nevcairiel> i always set dtshd_rate to 768000 to get it into mode 4 [00:32:49 CET] <wm4> me too [00:33:57 CET] <nevcairiel> the only thing i keep getting reports of not working reliably is E-AC3 [00:34:09 CET] <nevcairiel> but all hardware i have it works on, so :( [00:35:02 CET] <wm4> I got reports that passing dts-core via 8 spdif channels doesn't always work, so I need to know the dts profile [00:35:06 CET] <wm4> which is slightly annoying [00:35:12 CET] <nevcairiel> yeah i do that too [00:35:29 CET] <nevcairiel> switch into non-HD mode for core streams [00:35:33 CET] <rcombs> macOS is whacky about it [00:35:39 CET] <rcombs> on like the Mac Mini [00:35:45 CET] <nevcairiel> its mac, its hardly a good multimedia os [00:35:46 CET] <wm4> and last but not least, fuck spdif passthrough and HDMI, it's all horrid consumer garbage [00:35:58 CET] <nevcairiel> indeed [00:36:06 CET] <rcombs> and apparently the Roku will refuse to passthrough DTS iff the MKV-specified channel count is > 6 [00:36:15 CET] <wm4> lol [00:36:26 CET] <rcombs> but if you give it a DTS-HD stream with 8 channels, but propedit the mkv to say 6 channels, it works [00:36:27 CET] <nevcairiel> I don't use it myself, but people kept pestering me and the lavf spdifenc did all the hard work, soo [00:36:38 CET] <nevcairiel> roku is crap hardware, did noone tell you? :) [00:36:42 CET] <rcombs> I know [00:36:44 CET] <nevcairiel> it has all sorts of such funny things in it [00:36:46 CET] <rcombs> but ~users~ [00:36:58 CET] <rcombs> so I want to find out if it blows up if you give it a stream with too-high a bitrate [00:37:14 CET] <rcombs> spdifenc comment says * This generally only happens if the caller is cramming a Master * Audio stream into 192kHz IEC 60958 (which may or may not fit). */ [00:37:36 CET] <nevcairiel> in my tests trying to use any other output configuration didnt really work at all [00:37:39 CET] <rcombs> Roku has HDMI out but I guess sorta pretends it's SPDIF optical/coax? [00:37:53 CET] <nevcairiel> but then i only work with windows, and not some crazy STBs running who-knows-what [00:38:02 CET] <rcombs> maybe because it thinks you might be using a SPDIF passthrough out on the TV [00:38:10 CET] <rcombs> or, remind me, what bandwidth does HDMI ARC have [00:38:20 CET] <nevcairiel> basic spdif i think [00:38:25 CET] <nevcairiel> it gets HD support in HDMI 2.1 [00:39:04 CET] <rcombs> thought so [00:39:18 CET] <rcombs> oh lol [00:39:34 CET] <rcombs> apparently if you give Roku an 8-channel file pretending to be 6, it strips it to the core bitstream [00:39:55 CET] <nevcairiel> at least its consistent about failing [00:40:26 CET] <rcombs> but if you give it 8 that's honest about being 8 then on some models it plays silent audio, and on some models it refuses to play [00:40:40 CET] <rcombs> despite apparently being entirely capable of stripping to core when it needs to [00:40:42 CET] <rcombs> wtf even [00:41:06 CET] <rcombs> well I guess I'll use the dts_core bsf and fix it to set the channel count in codecpar [00:41:21 CET] <rcombs> by looking at the input channel layout and masking out the channels that aren't in core [00:41:59 CET] <nevcairiel> The worst i get exposed to is having to deal with DLNA capabilities of all those crappy STBs, and luckily thats not really my area, a colleague mostly deals with that [00:43:37 CET] <wm4> well, a player should not read those matroska headers in the first place for dts [00:43:54 CET] <Compn> dnla is such a major pita [00:44:00 CET] <nevcairiel> its one of those things thats just not specified [00:44:02 CET] <rcombs> DLNA is so bad [00:44:12 CET] <nevcairiel> clearly a coded bitstream takes precedence over some container info [00:44:17 CET] <Compn> how can it be worse to setup than ftp server :\ [00:44:31 CET] <nevcairiel> but then crazy people try to use container info to augment bitstream info [00:45:05 CET] <nevcairiel> is specifying 6 channels in the container for a 8 channel audio then "audio cropping"? :D [00:49:23 CET] <wm4> well, a DTS decoder could of course downmix the audio to 6 channels, or something [00:49:30 CET] <wm4> (whatever it does) [00:50:03 CET] <nevcairiel> well with DTS thats even a acceptable solution since commercial DTS encodes often have downmix coefficients [00:50:46 CET] <wm4> (are there non-commercial DTS encodes) [00:51:02 CET] <nevcairiel> probably not [00:51:07 CET] <rcombs> isn't it often that the core is the 6-channel downmix, and then xch/xxch/whatever adds the back channels and replaces the side ones? [00:51:17 CET] <nevcairiel> but some people steal the dts encoder and then probably dont use it right [00:51:26 CET] <rcombs> or am I thinking of the blu-ray eac3/ac3 thing [00:51:36 CET] <nevcairiel> nah dts works similar [00:51:49 CET] <wm4> is it as horrible as mixed ac3/eac3 [00:52:53 CET] <nevcairiel> in case of lossless DTS-HD MA: decode the core, un-downmix the 6ch with some coefficients, decode residuals from the XLL extensions to generate lossless [00:53:28 CET] <rcombs> ah, so it doesn't actually _replace_ the channels so much as& augment them, I guess [00:53:37 CET] <nevcairiel> yeah [00:53:37 CET] <rcombs> DTS is all about dat matrix coding [00:53:45 CET] <nevcairiel> the bluray ac3/eac3 thing is worse [00:53:53 CET] <nevcairiel> actually encodes 10 channels just to throw away 2 [00:54:12 CET] <nevcairiel> luckily its super rare [00:54:27 CET] <nevcairiel> havent had a request for that in ages [00:54:33 CET] <rcombs> same [00:54:55 CET] <rcombs> isn't DTS core like, 6-band ADPCM or something [00:55:01 CET] <rcombs> something trivial [00:55:10 CET] <nevcairiel> its some form of adpcm iirc [00:55:19 CET] <nevcairiel> with extra shit on top [00:55:22 CET] <rcombs> no real psy or anything? [00:55:35 CET] <rcombs> I guess that makes it easy to do residual coding at least [00:55:46 CET] <wm4> imagine blurays would ship cinepak, but highly patented and obfuscated [00:56:00 CET] <rcombs> lolcinepakman [00:56:13 CET] <nevcairiel> core dts is definitely not the most advanced format, which is why its base bitrates are also so high [00:56:16 CET] <iive> BtbN: do you have some nice article, where they explain how did they finally got Instructions per Cycle count that is closer to intel? [00:56:26 CET] <nevcairiel> you know how ac3 goes to 640kbps, and dts core to 1.5mbps [00:56:59 CET] <rcombs> yup [00:57:05 CET] <rcombs> "just throw more bits at it" [00:57:15 CET] <rcombs> and then people claim DTS is better because it has a higher max rate [00:57:22 CET] <TD-Linux> wm4, they would also ship indeo and bink to be "fair" [00:57:23 CET] <rcombs> (not saying AC3 isn't shit) [00:57:30 CET] <nevcairiel> yeah [00:57:48 CET] <nevcairiel> Just today I had some guy asking about our choice of aac bitrate for stereo audio encodes in video transcoding [00:58:10 CET] <nevcairiel> he was like, my source has 320kbps mp3, why do you only use 224kbps, thats going to sound terrible [00:58:20 CET] <nevcairiel> 224kbps for aac stereo is outrageously high, but ok [00:58:54 CET] <rcombs> max is 258kbps at 48kHz [00:58:59 CET] <rcombs> so couldn't do 320 even if you wanted to [00:59:20 CET] <rcombs> lol mp3 with video, though [00:59:27 CET] <rcombs> what is this, 2002 [00:59:30 CET] <nevcairiel> probably [00:59:39 CET] <wm4> used to be really common with xvid [00:59:39 CET] <nevcairiel> i mean, old videos exist of course [00:59:51 CET] <rcombs> sure [00:59:57 CET] <wm4> though no idea what rates they used [01:00:03 CET] <rcombs> y'know I still get people complaining about weird AVI shit [01:00:05 CET] <nevcairiel> 128 for stereo probably =p [01:00:12 CET] <rcombs> with MPEG-4 Part 2 and MP3 audio [01:00:19 CET] <rcombs> apparently people are still making those [01:00:22 CET] <rcombs> fuck if I know why [01:00:31 CET] <nevcairiel> what do scene SD encodes uses these days [01:00:35 CET] <rcombs> that [01:00:40 CET] <JEEB> I think the rules did add AVC [01:00:50 CET] <JEEB> but yea, still you see MPEG-4 Part 2 [01:00:50 CET] <rcombs> yeah it's allowed and some people do it [01:00:56 CET] <rcombs> but part 2 encodes are still common [01:01:04 CET] <nevcairiel> just call it xvid, will ya =p [01:01:21 CET] <rcombs> these are the same people who split an mkv into a bunch of rars and then put them in a torrent, though [01:01:27 CET] <rcombs> I shouldn't expect competency [01:02:28 CET] <wm4> they do that? [01:02:34 CET] <wm4> I thought it was for FTPs or some shit [01:02:36 CET] <nevcairiel> not sure thats the same people d oing the encodes [01:02:44 CET] <nevcairiel> the splits are usually for ftp or newsgroups [01:02:44 CET] <jamrial> 1kbps xvid and 128kb mp3 is the most early 2000 you can get [01:02:51 CET] <nevcairiel> its the idiot users that torrent this then [01:03:00 CET] <rcombs> yeah, it goes up on FTP, but then people post the rars on usenet and torrent sites [01:03:00 CET] <jamrial> 1000kbps, sorry [01:03:02 CET] <iive> i think that they distribute the rars via ftp, and then put the files on torrents [01:03:20 CET] <rcombs> dunno why they rar to begin with, though [01:03:40 CET] <iive> because rar does crc and recovery via RS [01:03:52 CET] <iive> also, to redownload just parts of it. [01:03:59 CET] <iive> i mean... you can't trust sha1 [01:04:07 CET] <iive> ;) [01:04:24 CET] <nevcairiel> newsgroups need some kind of splitting, since the entire thing wasnt really designed for binaries =p [01:04:25 CET] <jamrial> par2 [01:04:35 CET] <jamrial> not rar recovery [01:05:07 CET] <rcombs> good old "we're using a protocol that's objectively terrible for what we're using it for" [01:05:16 CET] <rcombs> that doesn't make sense for FTP though [01:05:21 CET] <rcombs> (also, lolftp) [01:05:26 CET] <nevcairiel> i just tested some random SD encode and its actually a mkv with h264 and aac lc [01:05:33 CET] <rcombs> oh, storytime [01:05:47 CET] <jamrial> nevcairiel: one of the so called "bdrip"? [01:05:53 CET] <nevcairiel> no, broadcast [01:05:59 CET] <rcombs> so I once was given access to a shared FTP server to grab a file [01:06:07 CET] <jamrial> ah [01:06:40 CET] <iive> btw, i do still see xvids, and it is usually the smaller than the h264 releases. [01:06:41 CET] <jamrial> blu ray rips at dvd resolution are distributed as "bdrip" or something like that [01:06:42 CET] <iive> I guess that some people still have xvid only players. [01:07:06 CET] <rcombs> server was in France, and like half the users in the US [01:07:06 CET] <rcombs> one of the admins actually advised me to download a specific FTP client [01:07:07 CET] <rcombs> that opens several connections and downloads a segment of the file on each one [01:07:07 CET] <rcombs> because they were getting really low speeds on each connection, but in aggregate they were fast [01:07:21 CET] <nevcairiel> everyone used to have those t hings back in the day, wonder why allowing more bandwidth on one connection was so hard [01:07:28 CET] <rcombs> and I'm like "wtf you people are idiots" [01:07:32 CET] <rcombs> nevcairiel: it was never actually hard [01:07:41 CET] <rcombs> nevcairiel: you just need to increase your server's TCP send buffer size [01:07:49 CET] <rcombs> to allow more packets in-flight at once [01:08:03 CET] <iive> nevcairiel: to do load balancing. [01:08:05 CET] <rcombs> that's how you deal with long (high-latency) fat (high-bandwidth) networks [01:08:19 CET] <rcombs> so I told them to do that and whaddayaknow suddenly single-connection transfers are fast [01:08:27 CET] <nevcairiel> jamrial: run of the mill HDTV encode, but i guess both types may still exist, some may still do the old-style encodes [01:08:32 CET] <jamrial> iive: what i'm starting to see are hevc releases at half the size the h264 ones. and those i checked looked worse [01:08:44 CET] <rcombs> but people invented whole workarounds (like using multiple connections) because they didn't know that was the solution [01:08:45 CET] <iive> i mean, you do not want one T1 user to take over your small ftp server. [01:08:56 CET] <nevcairiel> thats because hevc cant realistically deliver half the size at same quality [01:08:57 CET] <iive> jamrial: yes, megusta or something like that [01:09:19 CET] <nevcairiel> not with any current encoders, anyway [01:09:39 CET] <iive> it can [01:09:45 CET] <nevcairiel> 30-25% less *maybe* if you do 10-bit encodes [01:09:45 CET] <iive> but it takes a lot more time [01:09:47 CET] <rcombs> maybe one day there'll be an HEVC encoder built by anime nerds [01:10:11 CET] <iive> well, x264 was build by anime nerds [01:10:17 CET] <rcombs> HEVC might realistically be dramatically better than H264 if the H264 encoder is shitty [01:10:27 CET] <nevcairiel> even with all the time in the world, you cant get x265 to spit out a say 720p or 1080p encode at half the size and the same quality [01:10:28 CET] <rcombs> maybe it's better for hardware, I dunno [01:10:33 CET] <rcombs> iive: exactly [01:10:34 CET] <nevcairiel> .. as a x264 encode [01:10:40 CET] <rcombs> x265 is MCW people [01:10:54 CET] <nevcairiel> (and i'm not talking anime content :p) [01:11:01 CET] <nevcairiel> animes are easy anyway [01:11:02 CET] <wm4> h265 is still a patent mine field [01:11:06 CET] <nevcairiel> grainy live action is hard [01:11:29 CET] <iive> grain is artifical [01:11:33 CET] <iive> remove it :D [01:11:42 CET] <rcombs> I'm just generalizing about anime nerds being good at actually improving visual quality instead of lolPSNR [01:13:17 CET] <nevcairiel> the thing about hevc is that some of its coding tools just tend to blur rather then produce blocking artifacts or other visible artifacts [01:13:27 CET] <JEEB> yeh [01:13:33 CET] <nevcairiel> and many sheeple just accept lack-of-artifacts as a good image [01:13:35 CET] <iive> well, loopfilter should do the same [01:13:37 CET] <rcombs> nevcairiel: 03.2 [01:13:39 CET] <nevcairiel> nevermind lack of sharpness [01:13:50 CET] <nevcairiel> rcombs: its a factor of hevc itself, not necessarily encoder [01:14:10 CET] <iive> and h265 does have 32x32 dct? doesn't it? [01:14:11 CET] <JEEB> yea, it's a set of coding tools that really optimizes for that blurriness fact [01:14:15 CET] <JEEB> *factor [01:14:27 CET] <rcombs> nevcairiel: doesn't blurring help PSNR though [01:14:32 CET] <JEEB> yes [01:14:44 CET] <nevcairiel> incidentally, some of the artifacts in h264 can "fake" sharp detail [01:14:50 CET] <iive> you mean, blur before encoding? [01:14:55 CET] <TD-Linux> iive, yes, compared to 8x8 max of h.264 high profile [01:14:59 CET] <TD-Linux> (and 4x4 of bluray h.264) [01:15:06 CET] <TD-Linux> that's where the majority of the gains came from. [01:15:12 CET] <JEEB> wait what [01:15:14 CET] <nevcairiel> so a h264 encode with slight artifacting can a ppear sharper when the artifacts are in the right spot :D [01:15:26 CET] <JEEB> oh right [01:15:48 CET] <rcombs> given how blurry everything turns out, it seems like both the codec design and the encoders were designed to optimize for PSNR [01:15:53 CET] <JEEB> nevcairiel: psy-* in x264 tried to utilize that [01:15:55 CET] <rcombs> does that seem inaccurate? [01:16:00 CET] <JEEB> rcombs: no [01:16:08 CET] <JEEB> you can go look at JCT-VC documents [01:16:13 CET] <JEEB> regarding metrics utilized [01:16:28 CET] <TD-Linux> rcombs, they literally search through all possible modes and choose the one with the best PSNR inside the encoder [01:17:02 CET] <rcombs> maybe one day AV1 will save us [01:17:02 CET] <rcombs> (that's the new meme codec, right?) [01:17:02 CET] <rcombs> (daala is the old meme) [01:17:02 CET] <nevcairiel> the x265 people always claim that they dont optimize for metrics, but if the standard itself tends to go that way there is maybe only so much they can do [01:17:20 CET] <TD-Linux> rcombs, yes I'm literally a paid shill for it :^) [01:17:30 CET] <iive> the standard shoulde define only the decoder, not the encoder [01:17:35 CET] <wm4> just use vp9 lol [01:17:39 CET] <rcombs> who pays people to shill for HEVC [01:17:43 CET] <TD-Linux> iive, it does, but there's also a reference encoder [01:17:45 CET] <rcombs> MCW? MPEG-LA members? [01:17:46 CET] <JEEB> also it then starts making sense that disabling new tools in x265 starts making funky results [01:17:58 CET] <rcombs> lolvp9 [01:18:00 CET] <jamrial> rcombs: av1 is a mix of all the meme codecs [01:18:07 CET] <rcombs> jamrial: dank [01:18:17 CET] <JEEB> I still remember being surprised by the cisco dude [01:18:20 CET] <JEEB> at VDD'15 [01:18:21 CET] <rcombs> bringing together all the best memes [01:18:32 CET] <JEEB> > cisco > people @ VDD [01:18:35 CET] <JEEB> woah.jaypeg [01:18:53 CET] <wm4> were those openh264 people or what [01:19:00 CET] <JEEB> no [01:19:01 CET] <JEEB> thor [01:19:06 CET] <wm4> oh [01:19:10 CET] <rcombs> lolopenh264 as well [01:19:12 CET] <JEEB> as meme codecs were being talked of [01:19:20 CET] <rcombs> I appreciate the effort tho [01:19:26 CET] <JEEB> yea [01:19:31 CET] <wm4> what effort [01:19:41 CET] <iive> is openh264 the baseline codec that cisco released with payed patents? [01:19:50 CET] <TD-Linux> yes [01:19:59 CET] <iive> thanks obama! [01:20:13 CET] <nevcairiel> a codec like av1 will never fully replace the mpeg codec category however, for web sure, but broadcast and optical media? not seeing it [01:20:19 CET] <wm4> thanks trump for the h265 patent situation? [01:20:24 CET] <TD-Linux> because broadcast tv is the future :^) [01:20:42 CET] <nevcairiel> the way content providers are moving, internet streaming certainly isnt either =p [01:20:44 CET] <nevcairiel> or noone told them [01:21:20 CET] <TD-Linux> but yeah there's no point to target optical media (a slice of that lucrative bluray 4k market!) [01:21:26 CET] <jamrial> nevcairiel: is bluray uhd even remotely success right now to think about a successor? [01:21:33 CET] <iive> wm4: i think obama made a patent reform at the start of his first term. nothing major. But I was just joking. [01:21:46 CET] <nevcairiel> jamrial: still too new to draw a ny conclusions, i guess [01:22:06 CET] <rcombs> up until the election things were looking like software patents as a concept might get thrown out in court [01:22:13 CET] <rcombs> I'm less optimistic now [01:23:00 CET] <iive> rcombs: hey, be more optimistic, maybe no patent laywer would survive the atomic armagedon :D [01:23:16 CET] <nevcairiel> jamrial: but optical discs are on a decline anyway, and i guess more people still buy DVDs then normal Blu-rays, so what can you do [01:23:46 CET] <iive> talking aobut dvd and br sales [01:23:50 CET] <wm4> iive: you bet patent lawyers would be on the list of people who get to survive in secret government bunkers [01:23:51 CET] <jamrial> was going to say, the "looks and sounds good enough" mentality for even low quality streaming or even dvd are playing against new optical formats [01:23:55 CET] <iive> netflix are working on their encoder. [01:25:07 CET] <nevcairiel> if only the big content makers could be convinced to open up just a tiny bit to get their stuff on netflix (et al) sooner, and ideally in more regions of the world [01:25:40 CET] <nevcairiel> sucks to live in a country where all content is dubbed, it also means our local netflix variant does not carry any content thats not been dubbed yet, even if we want to watch it in english [01:26:14 CET] <iive> well, at least netflix went global. [01:26:28 CET] <iive> things will fall into place with time. [01:26:28 CET] <wm4> fortunately piracy still exists [01:26:42 CET] <jamrial> iive: if only their full library also went global [01:27:10 CET] <nevcairiel> interestingly in a few days amazon launches a new series globally that was produced in germany [01:27:14 CET] <nevcairiel> wonder if its any good [01:27:27 CET] <iive> jamrial: "their" library did. but not the things that they licensed from others. iirc [01:27:44 CET] <iive> nevcairiel: is uve bow invovled? [01:27:58 CET] <nevcairiel> no [01:28:06 CET] <iive> then it might be good :D [01:28:28 CET] <iive> what's the name of the series? [01:28:38 CET] <nevcairiel> You Are Wanted [01:29:02 CET] <nevcairiel> no clue if its any good, only saw like half a trailer [01:30:10 CET] <nevcairiel> launches globally on amazon video on friday [01:30:10 CET] <kierank> TD-Linux: 12:15 AM <TD-Linux> (and 4x4 of bluray h.264) [01:30:20 CET] <kierank> blu-ray allows 8x8 [01:30:27 CET] <JEEB> yup [01:30:33 CET] <JEEB> high profile as usual [01:30:46 CET] <JEEB> I think it had some b-frame limits? [01:30:56 CET] <kierank> some weird open gop yes [01:30:58 CET] <kierank> and b-pyramid [01:30:59 CET] <TD-Linux> kierank, I thought it was Main [01:31:09 CET] <JEEB> nope [01:31:11 CET] <kierank> maybe for some of the SD stuff but HD was high [01:31:22 CET] <kierank> in fact iirc it was blu-ray that put High in [01:31:24 CET] <TD-Linux> ah okay. [01:31:56 CET] <nevcairiel> JEEB: max 3 b frames [01:32:23 CET] <nevcairiel> and bpyramid strict [01:32:31 CET] <JEEB> yup [01:32:47 CET] <iive> nevcairiel: the trailer doesn't grab me... looks kind of cliche - a hacker destroys their life [01:33:20 CET] <nevcairiel> i have amazon prime anyway, so i'll give it a look when its out, can judge then [01:34:13 CET] <nevcairiel> (i had it for free shipping and never canceled it when they piled more features on top :p) [01:35:09 CET] <iive> nevcairiel: have you watched "black mirror"? [01:35:22 CET] <nevcairiel> no [01:35:32 CET] <iive> highly recommended. [01:35:41 CET] <nevcairiel> has pretty good ratings i see, maybe i should try it [01:35:43 CET] <iive> also very depressing. [01:36:01 CET] <iive> don't watch more than one per day. [01:36:12 CET] <kierank> i wonder if they censored man in the high castle for germany [01:37:05 CET] <nevcairiel> in movies or tv its usually fine to show these things [01:37:09 CET] <JEEB> oh [01:37:17 CET] <nevcairiel> for some reason games however cannot [01:37:20 CET] <JEEB> yea [01:37:27 CET] <kierank> what about castle wolfenstein? [01:37:27 CET] <JEEB> that I remembered being NG [01:37:30 CET] <kierank> did that just not exit [01:37:34 CET] <kierank> -st [01:38:21 CET] <JEEB> the new order did get released there [01:38:26 CET] <JEEB> https://www.youtube.com/watch?v=1hK4Px4O8aE [01:38:41 CET] <nevcairiel> the original as well, but it was modified [01:39:15 CET] <nevcairiel> no swastikas and other insignias, highly reduced violence levels [01:39:44 CET] <nevcairiel> and the story was slightly rewritten so you fight some cult and not the nazis [01:40:13 CET] <jamrial> hydra :p [01:41:15 CET] <nevcairiel> but yeah they do a lot of effort for games, while movies often get away just fine [01:48:16 CET] <BBB> wbs: have your patches been applied? [01:50:38 CET] <nevcairiel> the big arm set? that came through here on saturday [02:25:56 CET] <cone-003> ffmpeg 03Michael Niedermayer 07master:a557ae8d52ce: avcodec/h264_direct: Fix runtime error: signed integer overflow: 2147483647 - -14133 cannot be represented in type 'int' [02:25:56 CET] <cone-003> ffmpeg 03Michael Niedermayer 07master:1467143a6ebf: avcodec/wavpack: Fix runtime error: shift exponent 137 is too large for 32-bit type 'int' [02:25:56 CET] <cone-003> ffmpeg 03Michael Niedermayer 07master:acdacb108d98: avcodec/targa: Skip hflip on blank images [02:25:56 CET] <cone-003> ffmpeg 03Michael Niedermayer 07master:7cebc5a9ccba: avcodec/wavpack: Fix runtime error: shift exponent 32 is too large for 32-bit type 'int' [02:50:32 CET] <rcombs> lol just found out libmad is a thing [02:50:41 CET] <rcombs> that people think is "better quality" than lavc's mp3 decoder [02:54:15 CET] <jkqxz> Fixed point <3 [02:54:22 CET] <jkqxz> (Floating point <2.9999999992793472) [02:56:05 CET] <rcombs> well lavc has fixed-point [02:57:01 CET] <rcombs> and MP3 isn't bitexact [02:57:15 CET] <rcombs> also they spit out 24-bit 'cause ¯\_(Ä)_/¯ [03:01:10 CET] <jkqxz> Huh, so it does. (I only remember that as the point of libmad.) [03:05:02 CET] <wm4> 3 bytes per sample or padded? [03:07:09 CET] <rcombs> dunno, presumably padded though [03:16:37 CET] <cone-003> ffmpeg 03Steven Liu 07master:d3ce067e7687: avformat/hlsenc: fix ticket 6231 [03:25:02 CET] <BBB> rcombs: VLC devs keep saying that very loudly& [03:25:23 CET] <BBB> nevcairiel: youre right, I missed that [03:25:28 CET] <BBB> wbs: nevermind [03:25:33 CET] <rcombs> what do they claim it is, 16- instead of 32-bit intermediates in lavc's fixed-point decoder? [03:25:43 CET] <rcombs> (i.e. inaudible?) [03:26:15 CET] <BBB> rcombs: I have no friggin clue, Im a video dev ;) [03:26:37 CET] <BBB> rcombs: I once broken the wmavoice decoder and couldnt hear the difference (I actually tested it and thought it sounded fine) [03:27:01 CET] <rcombs> >wmavoice [03:27:03 CET] <BBB> since then I use wave analyzers to test audio decoder changes, since my ears are useless for that sort of stuff [03:27:29 CET] <BBB> I agree wmavoice is garbage, but thats a different issue ;) [03:36:02 CET] <philipl> so ffplay was never ported to the new decode api? [03:39:58 CET] <wm4> apparently not [03:40:55 CET] <philipl> git rm ffplay.c [03:40:55 CET] <wm4> I still have a patch for ffprobe [03:41:05 CET] <wm4> should send it [03:42:40 CET] <philipl> Might as well. [03:42:53 CET] <philipl> Does libav have an avplay or did they nuke it? Presumably they ported it if they still have it. [03:44:50 CET] <wm4> seems like they haven't converted it [03:45:01 CET] <wm4> maybe ask the ffplay maintainer [03:45:44 CET] <philipl> heh. [03:52:00 CET] <jamrial> poke marton. he ported ffplay to codecpar in a heartbeat when asked [03:52:11 CET] <jamrial> out of all the tools, ffplay has the least hacks. or none [04:12:37 CET] <philipl> Ok, will do [04:13:05 CET] <philipl> Is he on IRC? I don't think so [10:40:13 CET] <mateo`> mmm looking at the crystalhd thread, i wonder, is the new decoding api (send_packet/receive_frame) now mandatory ? [10:42:31 CET] <nevcairiel> its mandatory if the encoder or decoder you try to use only implements it [10:42:55 CET] <nevcairiel> but crystalhd is the only so far that does not implement the old api, afaik [10:44:07 CET] <mateo`> ok [10:45:59 CET] <mateo`> porting the mediacodec decoder to the new api is still on my todo though [11:12:52 CET] <cone-655> ffmpeg 03Steven Liu 07master:4e3cc4bdd8ac: avformat/flvenc: flx flvflags no_metadata bug [11:46:23 CET] <BtbN> mateo`, for cuvid I just implemented a wrapper, so it supports both. But the new API is "native" for it. [14:37:21 CET] <wm4> mateo`, nevcairiel: Libav have a change that makes it possible to use the new API from the old one, to some degree [14:38:52 CET] <nevcairiel> did they really add that [14:39:01 CET] <nevcairiel> guess my voting against that every chance i had didnt help [14:39:13 CET] <nevcairiel> its just going to cause trouble [14:40:16 CET] <wm4> yes they really did that [14:40:20 CET] <wm4> plus they rewrote everything [14:40:29 CET] <nevcairiel> its the libav way [19:08:26 CET] <durandal_1707> michaelni: the mpegvideo code is unparsable, is there another codec like scpr regarding frame handling? [20:06:44 CET] <uau> ffmpeg supports platforms with size_t less than 32 bits? that sounds really implausible [20:07:53 CET] <uau> that would pretty much require that int is less than 32 bits too, or else trying to malloc int-sized areas could silently wrap around the requested size to a smaller value [20:09:08 CET] <wm4> uau: indeed [20:24:46 CET] <durandal_1707> who is responsible for allowing ssim spam on devel ml? [20:27:49 CET] <wm4> that's allowed, AFAIK [20:28:22 CET] <durandal_1707> promoting company x? [20:31:30 CET] <wm4> posting job offers [20:37:52 CET] <kierank> not sure it's a bit vague [20:37:56 CET] <kierank> should I troll it back [21:26:29 CET] <jamrial> uau: we should probably remove the freedos/opendos checks from configure then [21:27:39 CET] <wm4> apart from WTF, are you sure those don't use 32 bit mode [21:30:30 CET] <jamrial> not really sure, but a google search gave me that impression [21:31:03 CET] <wbs> the dos instances on fate, at least the ones I've seen, are djgpp, which is 32 bit mode [21:31:29 CET] <jamrial> size_t is only guaranteed to be at least 16 bits by the standard, but if it's not in those two targets then i guess it's not a problem for us [21:32:33 CET] <wbs> it's most certainly not a problem on those targets, no [21:33:04 CET] <wm4> the max image size on such a system would be 256x256 even at pal8 [21:37:46 CET] <uau> jamrial: yes the standard minimum size is only 16 bits (like it is for ints), but there is plenty of code in ffmpeg which requires ints larger than 32767 [21:38:34 CET] <uau> it's obvious that many things would fail on such a platform, and i would be quite surprised if you were able to run ffmpeg usefully at all [21:51:09 CET] <uau> jamrial: about your latest mail, your "types defined in the standard for this exact scenario" claim is false [21:51:28 CET] <uau> the "scenario" only requires the type to be large enough to store the minimum required range of values [21:51:50 CET] <uau> it's quite normal to use int to store variables which are never above 100 [21:52:33 CET] <jamrial> but that's mostly because it's native (aka usually fastest) type [21:52:39 CET] <uau> do you claim it "makes no sense" to do that instead of using either char or int8_t/uint8_t? [21:53:32 CET] <uau> if you accept the "native" argument, doesn't int / unsigned int fit the case here? (as in practice ffmpeg requires those to be at least 32 bits too) [21:53:47 CET] <jamrial> for many arrays we do use uint_8 for such values [21:54:47 CET] <uau> yes it is more common for arrays with lots of entries to use minimal types to reduce size [21:58:57 CET] <faLUCE> I still believe that the decision of separating the ADTS header from the AAC encoder, in ffmpeg 3.2, is a wrong decision. ADTS works only with AAC, then there's no reason for decoupling them. And in order to write a playable AAC file you have to mux it, which increases complexity of the code. Why don't you do a regression in the source code of libav? [21:59:19 CET] <jamrial> uau: from that pov i agree "makes no sense" was not the best way to put it. pointless would work better i guess [22:05:05 CET] <SpeakerToMeat> Good evening. Sorry to interrupt your day, but I just wanted to come and thank you all profussely for the work you do on ffmpeg and for the marvelous tool you've created in it. [22:10:37 CET] <philipl> curious. [22:23:30 CET] <atomnuker> wm4: weren't you going to push the side packet stuff on monday? [22:33:45 CET] <wm4> yes [22:38:41 CET] <cone-255> ffmpeg 03Katherine Nagels 07master:b2206475b459: doc/filters: Add colourspace values for colormatrix filter [22:50:32 CET] <cone-255> ffmpeg 03Michael Niedermayer 07master:0728d9a28106: avcodec/pictordec: Fix runtime error: left shift of 805306368 by 2 places cannot be represented in type 'int' [22:50:33 CET] <cone-255> ffmpeg 03Michael Niedermayer 07master:108b02e5471c: avcodec/tiff: Check for multiple geo key directories [22:50:34 CET] <cone-255> ffmpeg 03Michael Niedermayer 07master:8ebed703f153: avcodec/mpegaudiodec_template: Make l3_unscale() work with e=0 [23:02:11 CET] <cone-255> ffmpeg 03Alexander Strasser 07master:6693d57e99d9: lavf/avio: Remove unnecessary escaping of ' in string literals [23:02:12 CET] <cone-255> ffmpeg 03Alexander Strasser 07master:a70d5e259364: lavf/avio: Be more explicit in logging white/black list matches [23:08:30 CET] <wm4> philipl: I've played with nvidia+vdpau9hevc for a while [23:08:56 CET] <philipl> anything interesting? [23:08:56 CET] <wm4> nvidia+vdpau+hevc and mapping them as textures in GL [23:09:03 CET] <philipl> broken? [23:09:13 CET] <wm4> yes [23:09:22 CET] <wm4> so as you know the first two textures contain the first and second luma fields [23:09:41 CET] <wm4> because originally the GL interop wanted to make bob deint simple, or something absurd [23:10:09 CET] <wm4> so in theory, the first textures contains all even lines, and the second all odd lines [23:10:26 CET] <wm4> but with hevc... the first textures contains the top half of the image, and the second texture the bottom half [23:10:29 CET] <wm4> WELL DONE NVIDIA [23:10:31 CET] <philipl> yep. [23:10:41 CET] <philipl> and is it exact? or is there a dead space in the middle due to alignment? [23:10:45 CET] <wm4> but I didn't get it to work because there's some weird offset [23:10:47 CET] <philipl> that happens with the read-back api [23:10:51 CET] <wm4> heh [23:10:53 CET] <philipl> ah. there you go [23:10:54 CET] <wm4> that's probably it [23:11:17 CET] <wm4> I didn't go as far as writing complex code to save the texture to png (and apitrace doesn't work), so I'm still confused [23:11:38 CET] <wm4> but seriously how do they get this so wrong, and why don't they just add a way to map textures as single frame? [23:12:25 CET] <philipl> Up until hevc, hardware produced fields, so they made the api use fields. [23:12:39 CET] <philipl> With hevc, they need to explicitly split the fields and didn't do it consistently [23:12:52 CET] <wm4> they didn't even get the most basic thing... [23:14:55 CET] <wm4> so the only thing that works is using the video mixer [23:15:05 CET] <wm4> for which they have a test program on github (how ironic) [23:15:44 CET] <iive> there is no way to get a whole frame?! [23:16:06 CET] <wm4> their shit is just randomly broken [23:16:15 CET] <iive> btw, mpeg4-2 (asp) also doesn't support field pictures, only interlaced mb. [23:16:28 CET] <wm4> some amazing incompetence (I mean couldn't they at least be honest and disable hevc in vdpau completely?) [23:17:01 CET] <iive> ha... ha... the PR department would kill them [23:18:39 CET] <iive> wm4: if you have a way, report it as bug. hevc is not the first format that doesn't support field pictures. [23:20:22 CET] <wm4> I'm sure they know this [23:20:30 CET] <wm4> and I'm not sure why you're talking about field pictures [23:21:18 CET] <iive> first and second luma fields ? [23:22:11 CET] <iive> aren't chroma fields also separated? [23:22:13 CET] <wm4> all video is represented as fields, doesn't matter if the codec supports or uses them [23:22:14 CET] <wm4> yes [23:27:02 CET] <jkqxz> The AMD guy on the Mesa list had patches for H.265 Main10 with VDPAU, but he gave up on it when noone replied and there was nothing to test with (because it's all broken on Nvidia so noone enables it). [23:27:15 CET] <jkqxz> Maybe if you made it all work on AMD then Nvidia might pay more attention? [23:27:35 CET] <wm4> doesn't libva work for AMD? [23:28:31 CET] <jkqxz> Yes, though not yet for passing the surfaces to display. [23:30:44 CET] <jkqxz> <https://lists.freedesktop.org/archives/mesa-dev/2017-March/147152.html> [23:32:02 CET] <nevcairiel> kaveri doesnt have hevc 10bit decode hardware, are they running this through 8-bit again and calling it supported [23:32:07 CET] <wm4> jkqxz: the dmabuf thing is missing? [23:33:01 CET] <jkqxz> I don't know about Kaveri. The VAAPI stuff all works properly for me on Polaris. [23:34:24 CET] <jkqxz> wm4: Yes. [23:44:39 CET] <cone-255> ffmpeg 03wm4 07master:55eab1733b9e: ffmpeg, ffprobe: don't "merge" side data into packet data by default [23:47:17 CET] <rcombs> jkqxz: (decode-only, I take it?) [23:47:25 CET] <philipl> wm4: It's worse. Remember the first driver release with hevc support was broken like this in the mixer too. [23:47:56 CET] <philipl> I managed to communicate directly with the vdpau engineer about it and he got it fixed (but didn't fix GL or read-back API) [23:48:33 CET] <wm4> philipl: they have a vdpau engineer? [23:48:41 CET] <philipl> Not anymore. He works for my company now. Whoops. [23:48:47 CET] <wm4> lol [23:49:22 CET] <jamrial> wm4: those gapless fate changes look weird. why an empty line, or why no separator between side_data and the packet duration? [23:49:34 CET] <wm4> jamrial: I have no idea [23:49:35 CET] <jamrial> looks like it could be a ffprobe bug [23:53:53 CET] <jkqxz> rcombs: Yes, decode-only. There isn't any encode beyond barely-usable H.264. [23:54:09 CET] <rcombs> and they use OMX for that, right [23:54:28 CET] <nevcairiel> i hear the AMD encode SDK on windows is also rather impossible to work with [23:56:08 CET] <nevcairiel> (this https://github.com/GPUOpen-LibrariesAndSDKs/AMF) [23:57:14 CET] <Fenrirthviti> nevcairiel: not quite impossible, we have someone from the OBS community team who built a very workable encoder there [23:57:45 CET] <nevcairiel> impossible means you want to kill yourself while working on it, not that its impoossible to actually produce some kind-of working code [23:58:01 CET] <Fenrirthviti> Oh, well yeah he's basically suicidal all the time these days :) [00:00:00 CET] --- Wed Mar 15 2017

1 0

ffmpeg.log.20170314
by burek 15 Mar '17

15 Mar '17

[00:00:06 CET] <feliwir> (guessing because YUV 420 allocates 3 planes) [00:00:08 CET] <JEEB> that's the P in YUV420P [00:00:23 CET] <JEEB> and that's why I used + and the 2* [00:00:36 CET] <JEEB> so you have one that is without subsampling (Y) [00:00:47 CET] <JEEB> and then you have two that are width and height subsampled (4:2:0 chroma) [00:01:36 CET] <feliwir> the calculation in libvp62 is like this: totalSize = pVP62->ySize + (pVP62->uvSize * 2); .I guess that makes sense [00:05:05 CET] <feliwir> is there a way to disable inlining during configure stage? It makes it hard for me to debug some av_always_inline functions [00:06:44 CET] <feliwir> currently i am using those settings: "./configure --enable-debug --disable-optimizations --disable-stripping [00:06:44 CET] <feliwir> " [00:36:30 CET] <faLUCE> "More than one AAC RDB per ADTS frame is not implemented" <--- what can cause this problem while encoding? [00:37:00 CET] <linuxuser9000> howdy-do ffmpeg-erinos [03:17:45 CET] <ZeroWalker> anyone know how to use swr_convert_frame? [06:33:05 CET] <acresearch> hey JEEB are you online? [06:39:13 CET] <acresearch> hello people, anyone can explain to me these flags? http://paste.ubuntu.com/24175062/ [09:13:18 CET] Action: abxy hot girls http://sexygirls2000.xyz [09:17:51 CET] <acresearch> hello people, anyone can explain to me these flags? http://paste.ubuntu.com/24175062/ [09:25:34 CET] <sile> Hi! i'm playing with filter_complex, stitching some videos together side by side. All of them last 5 seconds, I want to make some of the loop twice ( so the total duration of the video is 10 seconds ). So far I got this http://pastebin.com/WrdvuY5M, but for some reason the video stops at around the 7 seconds mark. Any clues? [09:25:38 CET] <sile> thanks! \o/ [09:30:05 CET] <sile> woo, i fixed it by using "fifo" [10:23:42 CET] <Drugbird> Heya, I have some trouble cross compiling ffmpeg with cuda support for ARM with the latest ffmpeg version from the git. Is this the right place to look for help for that? [10:49:00 CET] Last message repeated 1 time(s). [10:58:15 CET] <spaam> Drugbird: tell us about your issue. then maybe someone can help you. [11:08:58 CET] <Drugbird> I have problems getting configure to run properly when cross compiling for arm and enabling cuda support with the error message: "ERROR: cuda requested but not found". I can configure properly for my own system (x86) properly, where cuda is properly found and the corresponding hardware decoders are enabled. [11:11:12 CET] <fried> Hello there. In my software I want to get the metadata of each frame from a video stream (as "ffprobe ... -show_entries frame_tags=lavfi.signalstats.XYZ" it does). Unfortunately there are no meaningfull examples in this point. Anyone an idea or an example Link, how to setup a stream and iterate its frame metadata? [11:13:12 CET] <Drugbird> Minimal example that fails: ./configure --cc="aarch64-linux-gnu-gcc" --extra-cflags="-march=armv8-a -mcpu=cortex-a57" --enable-cuda --cross-prefix=aarch64-linux-gnu- --target-os=linux --arch=aarch64 --cpu=armv8-a [11:14:13 CET] <fried> to track ffprobe (together with cmdutil) in this point to find out is much to heavy; too many options and global dependencies/variables. [11:16:49 CET] <fried> to track ffprobe.c (together with cmdutils.c) in this point to find out is much to heavy; too many options and global dependencies/variables. [11:44:55 CET] <acresearch> hey JEEB are you online? [11:45:12 CET] <acresearch> JEEB: can you explain to me these flags? http://paste.ubuntu.com/24175062/ [11:49:27 CET] <DHE> 6 and 7 are parameter and value [13:02:35 CET] <acresearch> DHE: can you help with this? i do not understand the flags, so i can change them [13:13:02 CET] <trapchat> whats so many people doing in here? [13:13:13 CET] <acresearch> asking questions [13:13:44 CET] <trapchat> sony pictures employees? [13:13:54 CET] <acresearch> what? [13:14:10 CET] <trapchat> what question do you have? [13:15:02 CET] <acresearch> to explain to me these flags? http://paste.ubuntu.com/24175062/ [13:15:12 CET] <trapchat> what question does ilove11ven has? [13:15:24 CET] <trapchat> fried: what is your question? [13:15:41 CET] <trapchat> dont see anyone with questions [13:16:06 CET] <fried> hello, I asked it already, but I cant see the history [13:16:53 CET] <DHE> acresearch: https://ffmpeg.org/ffmpeg-all.html it's a mountain, but these are the docs for the ffmpeg tool. [13:17:18 CET] <fried> In my Software I want to access frames metadata such as "ffprobe ... -show_entries "lavfi.signalstats.<XYZ>" does [13:17:49 CET] <trapchat> what question does ilove11ven1 has? [13:18:25 CET] <fried> I need to know how to setup/open the stream, so that I get the metadata Dictionary for each frame [13:19:13 CET] <fried> there is no documentation to use the lib in this pont (only ffprobe examples) [13:19:37 CET] <trapchat> at this point [13:20:14 CET] <trapchat> at this point in time [13:20:28 CET] <trapchat> not in this point at time [13:23:13 CET] <fried> what do you mean? It's a ffmpeg channel, right?! [13:24:37 CET] <acresearch> DHE: this is a big document [13:25:22 CET] <BtbN> fried, I'd guess it's just in the AVFrames metadata field. [13:25:36 CET] <fried> right [13:25:50 CET] <fried> but empty [13:26:05 CET] <BtbN> Well, did you run it through the signalstats filter? [13:26:17 CET] <fried> probably not set up right [13:27:19 CET] <fried> I tried to setup via av_dict_set() before open the stream [13:27:49 CET] <acresearch> what does -sn (output) do? [13:28:03 CET] <BtbN> -sn disables subtitles on that output. [13:28:10 CET] <acresearch> ohhh ok [13:28:26 CET] <BtbN> fried, if you want signalstats, you have to actually use the signalstats filter. [13:28:30 CET] <BtbN> They don't appear on their own [13:29:59 CET] <fried> right, du you have an example link for me? [13:30:06 CET] <acresearch> what does -ac 2 do? [13:30:35 CET] <BtbN> https://ffmpeg.org/ffmpeg-filters.html#signalstats-1 [13:31:06 CET] <fried> thanks, but its for the ffprobe command line tool. [13:31:15 CET] <BtbN> It's for the signalstats filter [13:31:21 CET] <BtbN> It doesn't matter who invoked it [13:31:33 CET] <BtbN> It's just a regular video filter [13:31:39 CET] <fried> .. so I have to trace ist in the code [13:31:47 CET] <BtbN> no? [13:31:58 CET] <BtbN> Just run the frame through that filter, and it propagates the metadata. [13:32:02 CET] <fried> ok, so I have to learn about the filter usage [13:32:31 CET] <fried> ok, Ill see, thank you [13:36:29 CET] <acresearch> what does -c:v libx264 mean? [13:40:22 CET] <furq> codec, video, libx264 [13:44:16 CET] <acresearch> furq: oh so ffmpeg will code the output with libx264? [13:44:54 CET] <furq> yes [13:45:30 CET] <acresearch> so is libx264 a compression algorithm? [13:45:55 CET] <furq> https://en.wikipedia.org/wiki/X264 [13:52:41 CET] <DHE> it's an H264 encoder [13:53:16 CET] <acresearch> i am sorry guys, i am new to this and having a hard time understanding all the terms, H264 is HD? is there something higher? [13:54:15 CET] <DHE> h264 is a codec. image resolution is largely irrelevant beyond the decoder's capabilities [13:54:35 CET] <acresearch> ok [13:54:42 CET] <acresearch> what is -preset veryfast? [13:55:11 CET] <BtbN> Have you tried reading the documentation? [13:55:28 CET] <acresearch> BtbN: trying to understand it, it is very LARGE [13:55:31 CET] <acresearch> and complicated [14:00:30 CET] <lelduayen> Hi there, I'm new to IRC so any directions on how to behave are welcome [14:01:03 CET] <lelduayen> I'm having problems installing ffmpeg using https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu guide [14:01:23 CET] <lelduayen> the error is "ERROR: libass not found using pkg-config" [14:02:52 CET] <acresearch> lelduayen: are you on linux? [14:06:30 CET] <acresearch> BtbN: what does 2 audio channels mean? (-ac 2) [14:07:57 CET] <Kadigan_KSB> Hi. I'm seeing some weird issues with ffmpeg on Windows (nonfree) build by Kyle Schwarz (git-e18d9d9) when converting from MKV to MKV with overlay applied. The audio plays properly to the end, but the video (and the progress slider) both stop a few seconds short. [14:08:03 CET] <Kadigan_KSB> Is this a known issue, perhaps? [14:09:09 CET] <lelduayen> Hi acresearch, yes, ubuntu 14.04 [14:15:16 CET] <lelduayen> config.log suggest to add the directory containing `libass.pc' to the PKG_CONFIG_PATH environment variable, but no success in there [14:27:51 CET] <lelduayen> I've pasted entire log in http://pastebin.com/wikkinHG [14:29:32 CET] <nyuszika7h> how do I properly crop a 1.85:1 PAL DVD and scale it to 16:9 (so Display Aspect Ratio is not needed)? [14:29:47 CET] <nyuszika7h> I'd also like to burn in the vobsubs [14:30:11 CET] <nyuszika7h> (the MPEG-2/AC3/VobSub streams are already in an .mkv) [14:30:51 CET] <nyuszika7h> cropdetect is giving me negative values [14:33:10 CET] <nyuszika7h> here's a 1 minute sample if it helps: https://u.nya.is/jwmbqe.mkv [14:34:13 CET] <nyuszika7h> oh cropdetect gave me proper values now on the sample [14:34:34 CET] <nyuszika7h> crop=720:432:0:72 [14:38:02 CET] <acresearch> lelduayen: did you try sudo apt-get install ffmpeg? [14:44:21 CET] <nyuszika7h> oh so it's more like 2.35:1 [14:48:49 CET] <nyuszika7h> how do I crop/scale in filter_complex? [14:49:00 CET] <nyuszika7h> I can't do -filter_complex "[0:v:0][0:s:0]overlay[vid]" -filter:v:0 "crop=720:432:0:72,scale=720:304" [14:51:25 CET] <nyuszika7h> okay I think I got it [14:52:07 CET] <IntruderSRB> hey everyone, can someone share good tutorial or good documentation with use cases [14:52:09 CET] <IntruderSRB> for AVCodec/AVParser [14:52:24 CET] <IntruderSRB> I'm sending from my Java app to my JNIBridge C app byte arrays containing VideoNAL units [14:52:32 CET] <IntruderSRB> and I want to use libavcodec to read information from those slices [14:52:40 CET] <acresearch> IntruderSRB: https://ffmpeg.org/documentation.html [14:52:43 CET] <nyuszika7h> okay, now just one more problem [14:52:56 CET] <nyuszika7h> how do I reposition the vobsub so that it's *inside* the cropped video? [14:53:00 CET] <nyuszika7h> hmm maybe if I overlay it after crop/scale [14:53:35 CET] <IntruderSRB> acresearch: yes I was there but it's related to the usage of ffmpeg command line tools, failed to find library documentation on how to use it inside my source code [14:53:48 CET] <acresearch> oh [14:53:51 CET] <feliwir> JEEB, you see what i am doing wrong at my conversion to RGB?: https://gist.github.com/feliwir/e5da8d64f47fdde67d4656a6264f1a2a [14:53:59 CET] <IntruderSRB> or I'm reading it wrong :/ [14:54:06 CET] <feliwir> i am getting IndexOutofBounds (so my loop is going for too long) [14:54:57 CET] <IntruderSRB> found https://ffmpeg.org/libavcodec.html but it's not very usefull :) [14:55:03 CET] <nyuszika7h> now the subtitles didn't get overlayed at all [14:56:09 CET] <nyuszika7h> what's wrong with this? http://dpaste.com/06G5W5Q [14:57:50 CET] <nyuszika7h> (I realized I should also probably downmix the audio to 2.0, but that's irrelevant now, the problem is the subtitles not showing up) [14:58:59 CET] <nyuszika7h> http://dpaste.com/0CYV8TR here, this may be better, removed the hard newlines from the command prompt window [14:59:26 CET] <c_14> IntruderSRB: https://ffmpeg.org/doxygen/trunk/index.html [15:03:30 CET] <nyuszika7h> my sample file gets smaller with every encode (of course encoding from the original every time), lol [15:05:30 CET] <IntruderSRB> c_14: thanks! there's examples ... just what I was looking for :) [15:06:27 CET] <nyuszika7h> hmm so overlay takes x and y parameters, I'll trythat [15:10:08 CET] <lelduayen> acresearch: i haven't tried with apt-get because of trac msg "The static builds do not support non-free encoders." [15:11:05 CET] <lelduayen> I couldn't found which are non-free encoders, so I decided to compile instead [15:11:18 CET] <furq> fdk-aac is the only nonfree encoder [15:11:56 CET] <nyuszika7h> and now this happened http://t.6697.eu/g/file_22368.jpg [15:11:59 CET] <nyuszika7h> with overlay=0:-50 [15:12:03 CET] <lelduayen> thanks furq, I going to check if I need fdk-acc [15:15:18 CET] <luc4> Hello! I'm studying this doc http://ffmpeg.org/sample.html and I see it is possible to stream content via RTSP multicast. I used the same configuration and I can make it work. However I see the sdp can only be provided with http. Isn't it somehow possible to get it using rtsp protocol? [15:17:47 CET] <lelduayen> I've checked and ffmpeg is not available for 14.04 [15:19:07 CET] <lelduayen> Someone can point me where is the problem? [15:29:31 CET] <c_14> ffmpeg is only available from 16.04 up [15:29:34 CET] <c_14> use a static build [15:29:38 CET] <c_14> http://johnvansickle.com/ffmpeg/ [15:32:04 CET] <nyuszika7h> okay I got it [15:34:02 CET] <nyuszika7h> but now I have another problem, it's dropping frames [15:39:29 CET] <nyuszika7h> http://dpaste.com/1VV9ASG [15:44:58 CET] <nyuszika7h> okay, it seems it doesn't handle the cover attachment right, it shouldn't even be a video track, I'll just tell it to ignore that [15:45:42 CET] <nyuszika7h> perfect [15:54:53 CET] <feliwir> any idea what this could be related to: http://imgur.com/a/HMAaG .My custom vp6 decoder decodes the first video frame as green, eventhough it should be black :( [15:55:12 CET] <feliwir> might this be a YUV to RGB issue? [16:05:23 CET] <atomnuker> { 0, 0, 0 } in yuv is green, not black [17:29:13 CET] <feliwir> atomnuker, can you maybe take a look if my conversion code makes any sense: https://gist.github.com/feliwir/1f83f65e60b4ec41230a5a49c40a97c4 ? [17:30:45 CET] <atomnuker> feliwir: does it only happen on the first frame? [17:45:49 CET] <feliwir> hm, what exactly does this do on a short: "!!s->block_coeff[b][0]" ? I think my C# code is behaving differently there [17:45:58 CET] <Kadigan_KSB> So... Converting from .mkv to .mkv, same a/v codec settings, applying a complex_filter overlay as 1:1 (had the image prepared for the final resolution beforehand) -- result video file has a weird issue where upon playback video progress bar finishes, the video freezes on the frame that's seen last, but audio continues for another 3-4 seconds. I am 100% sure the frame seen as "last" is in fact not the last. [17:46:19 CET] <Kadigan_KSB> Happens on a Windows build from 2014, and on a Mac build from late 2016. [17:46:53 CET] <Kadigan_KSB> I convert to interim file (say, prores_ks + pcm_s16le mov) and then back to .mkv w/ overlay - issue doesn't occur. [17:47:52 CET] <Kadigan_KSB> I -may- have had "-c:a copy" in the first method, but this behavior I wouldn't have expected -- should I have? [17:51:28 CET] <Kadigan_KSB> Hm... seems specifying audio settings fixes this. I am obviously not understanding the "copy" option. [18:12:31 CET] <DHE> feliwir: '!!' is used to normalize boolean values. any non-zero value of is logically true such as '7', but '!!' will convert it to a standard 0 or 1. At least that's what normal C does, not sure what C# does different [18:21:25 CET] <feliwir> thanks DHE , so values below lower than 0 are converted to 1 aswell? [18:27:42 CET] <shincodex> #define LIBAVCODEC_VERSION_MAJOR 56 #define LIBAVCODEC_VERSION_MINOR 12 #define LIBAVCODEC_VERSION_MICRO 101 [18:27:51 CET] <shincodex> h264 pixelation big time [18:27:54 CET] <shincodex> Yet vlc dont do this [18:28:02 CET] <shincodex> Default h264 codec on ffmpeg decoding [18:28:14 CET] <shincodex> vlc i think default libx264 anyone confirm? [18:28:23 CET] <BtbN> x264 is an encoder. [18:28:25 CET] <shincodex> Pixelation scanline mirroing [18:28:33 CET] <BtbN> vlc uses lavc to decode h264. [18:28:41 CET] <shincodex> when ytou say LAVc [18:28:53 CET] <bencoh> LibAVCodec [18:28:58 CET] <shincodex> you mean -lavcodec [18:29:07 CET] <shincodex> ok [18:29:11 CET] <shincodex> I think you said this before [18:29:15 CET] <shincodex> and I guessed right [18:30:01 CET] <shincodex> So your saying I dont encode with same file h264.c [18:30:10 CET] <shincodex> but rather libx264 is the encoder [18:30:29 CET] <shincodex> so if i try to encode without configure of libx264.. then i wont encode squat [18:30:54 CET] <BtbN> It will probably default to some poor default quality [18:32:20 CET] <shincodex> I have tested [18:32:23 CET] <shincodex> options all over [18:32:29 CET] <shincodex> from profile main baseline High [18:32:31 CET] <shincodex> High 10 [18:32:56 CET] <shincodex> FF_PROFILE_H264_BASELINE [18:33:00 CET] <shincodex> FF_PROFILE_H264_HIGH_10 [18:33:13 CET] <shincodex> No matter what i set [18:33:14 CET] <shincodex> int ff_h264_get_profile(SPS *sps) [18:33:19 CET] <shincodex> always returns 77 i think [18:33:20 CET] <shincodex> which stands for [18:33:29 CET] <shincodex> #define FF_PROFILE_H264_MAIN 77 [18:33:56 CET] <shincodex> if (avcodec_open2(codecContext, codec, 0) > -1) [18:34:02 CET] <shincodex> i set options passed it where you see the zero there [18:34:05 CET] <shincodex> I set it in priv_data [18:34:15 CET] <shincodex> and part of int err = avformat_open_input(&formatContext, openPath.c_str(), inputFormat, &options); [18:34:16 CET] <shincodex> what gives [18:38:18 CET] <DHE> feliwir: 0 is false. all other values are true. but for normalization '1' is preferred as true. [18:39:19 CET] <brabo> hello, i am trying to make qsv work, but ffmpeg keeps segfaulting when i try to use either h264_qsv/hevc_qsv/mpeg2_qsv and the debug output is not very helpful, are there known issues with qsv in ffmpeg? [18:40:04 CET] <brabo> note, i am atm using intels mediasdk, not https://github.com/lu-zero/mfx_dispatch [18:50:05 CET] <feliwir> thanks DHE [19:02:37 CET] Action: brabo oggles https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=1f26a231bb065276cd80c… [19:14:46 CET] <jkqxz> brabo: Segfaulting early generally indicates that you missed something in the installation (libmfx is not very robust to that). [19:16:03 CET] <jkqxz> You need the modified libva and libdrm (and to not allow your distribution to override them with newer vanilla versions), and you need to have built the specific old kernel it requires with all 9001 patches applied. [19:17:21 CET] <brabo> jkqxz: going to try out that commit now, the ffmpeg repo we were using was missing that one, we have the libs in place and stuff so that should all be okay [19:17:42 CET] <brabo> the vlc qsv plugin succesfully detects the hardware, and the sample tests of the media sdk all go perfect [19:18:17 CET] <brabo> but vlc either also segfaults (maybe same commit will help) or the fifo buffer gets filled and cleared on vlc side [19:18:21 CET] <shincodex> [NULL @ 05962E40] non-existing SPS 1 referenced in buffering period [h264 @ 0A30AB20] non-existing SPS 1 referenced in buffering period [h264 @ 0A30AB20] Invalid POC 2<8 [NULL @ 05962E40] RTP: missed 70 packets [h264 @ 0A38EB40] left block unavailable for requested intra4x4 mode -1 at 0 41 [h264 @ 0A38EB40] error while decoding MB 0 41, bytestream 26979 [19:18:54 CET] <brabo> since the vlc qsv plugin is not to be considered working, but ffmpeg is, i'm first trying to make ffmpeg work [19:21:26 CET] <brabo> then ofc using the intel sdk vs the lu-zero mfx_dispatch may cause problems as well, will have to test that too if it keeps failing [20:41:41 CET] <kn0w> codecs fscc for catancia debian ? [20:41:56 CET] <kn0w> tscc (camtasia) -> h264 (libx264)) << for Linux ? codecs ? [20:42:18 CET] <kn0w> formt Video.dm2 << ? [21:00:11 CET] <FFmpegFTL> Hey guys ... I am currently trying to get a RTSP server working with ffmpeg command as mentioned here (https://lists.ffmpeg.org/pipermail/ffmpeg-user/2013-April/014726.html) The problem is that when a client connects, the server stops with no error message [21:01:09 CET] <FFmpegFTL> When a client connects to the server, ffmpeg has the following output : [21:02:15 CET] <FFmpegFTL> [rtsp @ 0000000001be26a0] Host myHostname differs from expected 0.0.0.0 Last message repeated 1 times [rtsp @ 0000000001be26a0] Updating control URI to rtsp://myHostname:8080/test0 [udp @ 000000000048ce60] 'circular_buffer_size' option was set but it is not supported on this build (pthread support is required) [udp @ 0000000001bf41a0] 'circular_buffer_size' option was set but it is not supported on this build (pthread support [21:02:44 CET] <FFmpegFTL> [rtsp @ 0000000001be26a0] Could not find codec parameters for stream 0 (Video: h264, none): unspecified size Consider increasing the value for the 'analyzeduration' and 'probesize' options [21:23:50 CET] <FFmpegFTL> Here is the pastebin link for the error log [21:23:52 CET] <FFmpegFTL> http://pastebin.com/jgsapit1 [21:27:07 CET] <alexpigment> FFmpegFTL: have you seen this thread? https://github.com/ZoneMinder/ZoneMinder/issues/811 [21:28:31 CET] <alexpigment> actually, disregard that. it came up with a google search but that error message is not explicitly mentioned - it just has "circular buffer" a few times in the article [21:40:28 CET] <FFmpegFTL> The question is, is that message ('circular_buffer_size' option was set but it is not supported on this build (pthread support is required)) an error ? [21:40:35 CET] <FFmpegFTL> Or is it a warning ? [21:40:46 CET] <FFmpegFTL> It has a yellow color [21:41:13 CET] <alexpigment> i believe it's just a warning [21:41:16 CET] <alexpigment> here's more info here; http://ffmpeg-devel.ffmpeg.narkive.com/cxOIY8TZ/patch-lavf-udp-warn-in-case… [21:41:46 CET] <alexpigment> now for the other issue, i'm not entirely sure, it's related, but this thread has the exact same error: https://github.com/datarhei/restreamer/issues/3 [21:42:24 CET] <alexpigment> see the second post from "yangpu" in that thread [21:44:14 CET] <c_14> yellow is warning [21:53:56 CET] <shincodex> vlc say haha fool we no use lavc it sucks we use gpu [21:54:03 CET] <shincodex> but that dont help solve anything [21:54:13 CET] <shincodex> he might even just be troll idk [21:54:23 CET] <shincodex> Maybe my configure script to anal [21:54:28 CET] <shincodex> I disable post proc [21:54:42 CET] <shincodex> so now Im just going to bernie sanders the configure and hope [22:00:06 CET] <FFmpegFTL> Okay. I dont see how this should help alexpigment [22:00:25 CET] <FFmpegFTL> This guy tries to grab a stream from some source [22:01:09 CET] <alexpigment> honestly, i don't know. you asked a question and it was crickets in here. I was googling around to help spark some information that might relate to your problem. I presume you've already googled around as well? [22:02:17 CET] <faLUCE> I still believe that the decision of separating the ADTS header from the AAC encoder, in ffmpeg 3.2, is a wrong decision. ADTS works only with AAC, then there's no reason for decoupling them. And in order to write a playable AAC file you have to mux it, which increases complexity of the code. Why don't you do a regression in the source code of libav? [22:02:42 CET] <shincodex> googled around is what sluts do [22:02:45 CET] <shincodex> or do they? [22:03:06 CET] <JEEB> faLUCE: if you care that much about enabling the ADTS muxer, then please report that as an issue on the trac [22:03:09 CET] <JEEB> kthx [22:03:16 CET] <shincodex> its a jeeb [22:03:19 CET] <JEEB> will get more caring eyes than on this IRC channel [22:03:42 CET] <FFmpegFTL> yes I did. I dont find any solution [22:03:54 CET] <shincodex> so since my version to know i noticed that they changed source code names.. h264.c h264dec.c [22:04:09 CET] <faLUCE> JEEB: yes, I'll do that [22:04:19 CET] <SpeakerToMeat> Ok not here [22:04:31 CET] <faLUCE> but I'm asking for IRC people's opinion [22:06:07 CET] <JEEB> in theory I do actually agree with things becoming more modular instead of automagically enabling things, if you are doing disable-everything builds. but that's just me so go on and post an issue [22:06:39 CET] <faLUCE> JEEB: yes, but then MP2 should be changed in the same way, for choerency [22:07:13 CET] <JEEB> sure [22:07:32 CET] <faLUCE> JEEB: currently, there's not a choerency [22:07:48 CET] <JEEB> but thankfully I'm one of those people who doesn't do disable-everything builds so fortunately idgaf [22:08:02 CET] <FFmpegFTL> What about the "bind failed: Error number -10048 occurred" error alexpigment [22:09:44 CET] <shincodex> hue hue hu ^ [22:09:50 CET] <furq> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/adtsenc.c#L102-L103 [22:09:51 CET] <furq> oh man [22:09:53 CET] <shincodex> i had a disable everything build [22:09:54 CET] <furq> don't tell me this is a thing [22:10:02 CET] <shincodex> but enable what i need [22:10:06 CET] <JEEB> furq: unfortunately it fucking is [22:10:10 CET] <shincodex> now im going other way to see what the shit is going on [22:10:11 CET] <furq> ;_; [22:10:20 CET] <furq> as if id3v2 hasn't done enough damage [22:10:24 CET] <JEEB> because awful people somehow think it's a good idea to mux without container [22:10:31 CET] <JEEB> and still want metadata [22:11:08 CET] <furq> the only argument against using m4a as an audio container is not one that's resolved by using id3 [22:11:33 CET] <shincodex> --disable-libopus there needs to be something for this [22:11:41 CET] <shincodex> so i dont have to disable-everything [22:12:14 CET] <JEEB> exceot by default most libs aren't enabled... (except some). in which case I agree, there should be coherency with it :P [22:12:24 CET] <shincodex> you know whats funny [22:12:24 CET] <JEEB> either you autodetect things, or you don't [22:12:44 CET] <shincodex> --enable-libopus enable Opus de/encoding via libopus [no] [22:12:47 CET] <shincodex> i assume no means [22:12:48 CET] <shincodex> no [22:13:11 CET] <shincodex> also if it helps [22:13:11 CET] <JEEB> which means the library isn't enabled even if found, unless that doc is fucked [22:13:11 CET] <shincodex> --toolchain=msvc [22:13:26 CET] <shincodex> Snapshot zip file i downloaded [22:13:28 CET] <JEEB> there's now an internal opus decoder and encoder, just fyi :P [22:13:30 CET] <shincodex> hoping it worked i did [22:13:31 CET] <furq> are external decoders/encoders ever enabled by default [22:13:42 CET] <JEEB> some random libs are [22:13:47 CET] <JEEB> zlib being one [22:13:48 CET] <furq> i thought that was only ever for devices [22:13:55 CET] <furq> and miscellaneous libs like zlib [22:14:04 CET] <JEEB> anyways, it's still lulzy [22:14:05 CET] <shincodex> libavcodec.a(opusdec.o) : error LNK2019 [22:14:11 CET] <shincodex> _swr_alloc referenced in function _opus_decode_init [22:14:12 CET] <shincodex> so [22:14:16 CET] <shincodex> Its ignoring me [22:14:21 CET] <JEEB> shincodex: no, that's the internal one [22:14:22 CET] <furq> that's the internal one [22:14:51 CET] <shincodex> oh oh [22:14:53 CET] <JEEB> having a second decoder was a requirement by European Broadcast Union [22:14:55 CET] <shincodex> Wait a minute your saying... [22:15:04 CET] <JEEB> so we got opus standardized [22:15:07 CET] <JEEB> in le broadcast [22:15:16 CET] <shincodex> im not linking swsresample [22:15:35 CET] <furq> well you probably should [22:15:36 CET] <JEEB> yea, then that thing might be broken in your random snapshot [22:15:44 CET] <shincodex> Well [22:15:51 CET] <JEEB> since it should have brought swresample in or disabled [22:16:02 CET] <shincodex> normally only link in my compact build codec util scale format [22:16:14 CET] <shincodex> i forgot that when i turn everything on it want everything [22:16:49 CET] <JEEB> unless you fucked around with the configure script and all, it should have not enabled the opus decoder in case swresample wasn't being built [22:16:58 CET] <shincodex> Negative [22:16:59 CET] <JEEB> or that was a bug [22:17:07 CET] <shincodex> this configure script is pure from my fingers [22:17:10 CET] <shincodex> so far [22:17:26 CET] <JEEB> anyways, if it still happens with current HEAD report it, that sounds like a booger [22:17:36 CET] <JEEB> if you have disabled swresample and it still tries to enable shit requiring it [22:18:11 CET] <shincodex> what is a latest safe build [22:18:13 CET] <shincodex> :P [22:18:41 CET] <JEEB> if there's any similar configuration to yours on FATE, then the last passing one there, but I have a feeling we don't have --disable-swresample build :P [22:18:46 CET] <shincodex> https://github.com/FFmpeg/FFmpeg.git [22:18:49 CET] <shincodex> is this safe? [22:19:08 CET] <FFmpegFTL> yes it is [22:19:16 CET] <JEEB> https://git.videolan.org/git/ffmpeg.git [22:19:23 CET] <FFmpegFTL> its just a clone of the regular ffmpeg repo [22:19:24 CET] <JEEB> the github if ever gets sync'd manually [22:19:31 CET] <JEEB> so always use the videolan one [22:19:55 CET] <shincodex> http://pastebin.com/kd16t2bv [22:20:01 CET] <shincodex> that my configure for debooger [22:20:19 CET] <shincodex> ignore opus disable [22:20:21 CET] <JEEB> oh, we actually did have disable-swresample FATE instance [22:20:32 CET] <shincodex> #--disable-everything --disable-sdl --disable-avdevice --disable-swresample --disable-postproc --disable-avfilter \ [22:20:34 CET] <JEEB> last run Feb 25th [22:20:35 CET] <JEEB> http://fate.ffmpeg.org/report.cgi?time=20170225125446&slot=x86_64-archlinux… [22:20:39 CET] <shincodex> i comment that out part of my line [22:21:05 CET] <shincodex> that was part of my configure just testing with bare minimum to try and solve h264 problems [22:21:46 CET] <JEEB> wait you don't even do disable-swresample?! [22:21:47 CET] <JEEB> wtf [22:21:55 CET] <shincodex> I did [22:21:57 CET] <JEEB> oh, it's in your IRC only :P [22:22:00 CET] <shincodex> should i put it back [22:22:00 CET] <JEEB> not in the pastebin [22:22:01 CET] <shincodex> lol [22:22:11 CET] <shincodex> you see where that fake disable-opus is [22:22:16 CET] <shincodex> thats where the # i posted just now is [22:22:19 CET] <shincodex> was [22:22:33 CET] <shincodex> I dont need device [22:22:40 CET] <shincodex> i dont do anything with web cams scanners or those things [22:25:15 CET] <FFmpegFTL> So hopefully someone could help me. I am trying to stream with OBS to an RTSP server, created by ffmpeg. The problem is that as far as ffmpeg picks the stream from the incoming connection its stops almost immediately [22:25:39 CET] <FFmpegFTL> My console in and output is this [22:25:40 CET] <FFmpegFTL> http://pastebin.com/eeVUPDn5 [22:26:18 CET] <JEEB> shincodex: at least the configure script's output had the opus decoder disappear after disable-swresample [22:26:32 CET] <JEEB> lessee if the libs build [22:27:28 CET] <BtbN> ffmpeg can act as rtmp server? [22:27:48 CET] <FFmpegFTL> yes [22:27:51 CET] <furq> in a sense [22:27:54 CET] <furq> in a more real sense, no [22:28:25 CET] <FFmpegFTL> but u have to build it without --enable-librtmp [22:28:39 CET] <BtbN> Well... don't do that I'd say [22:28:54 CET] <BtbN> Use a proper rtmp server [22:29:22 CET] <furq> what he said [22:30:32 CET] <shincodex> does ur name mean [22:30:36 CET] <shincodex> ffmpegforthelose [22:30:42 CET] <shincodex> or for the loose? [22:49:10 CET] <SpeakerToMeat> Hello all. [22:51:21 CET] <SpeakerToMeat> Couple questions, I need to convert three sets of image sequences to video and change colorspace. a) the concat demuxer file list in -i mylist.txt accepts the "directory/file%06D.png" notation in it? (do I need to explicitly set -f image2 ? will this conflict with -f concat ?) [22:52:08 CET] <furq> probably, no, and no [22:52:27 CET] <SpeakerToMeat> 2) Hmmm maybe I should split this in 2 parts, first convert each set of images and 5.1 audio channels into a video, and then concat all the videos. [22:52:35 CET] <furq> although it'd be simpler to just use the concat filter [22:53:32 CET] <SpeakerToMeat> Yes, I have 3 sets of images, and 3 sets of 6 single channels wav files, I need to concat, color space change and map all of those :/ it might be easier to do it in blocks, convert, color and map each set, and then concat the three results [22:53:49 CET] <furq> you can do all that in one command [22:54:09 CET] <SpeakerToMeat> Yes but it'll turn into a hairy (if fun) command... let's see I'll see the different parts and see if I can manage that [22:54:16 CET] <c_14> 3 image2 demuxers, 6 wav demuxers, a concat filter and an amerge [22:54:19 CET] <c_14> shouldn't be that hard [22:54:25 CET] <furq> you might want to combine the wavs first just to make the command less horrible [22:54:39 CET] <furq> but after that, it's easy enough [22:55:13 CET] <SpeakerToMeat> Ok for the filter, I'd need to use a filter_complex right? [22:55:25 CET] <c_14> yes [22:55:47 CET] <SpeakerToMeat> furq: Yes I think I'll join the wavs into multichanel single files, that'll shorten the map notably wouldn't it? [22:55:58 CET] <furq> -i a%d.png -i b%d.png -i c%d.png -i a.wav -i b.wav -i c.wav -filter_complex "concat=n=3:v=1:a=1[out]" -pix_fmt yuv420p -map "[out]" [22:56:19 CET] <SpeakerToMeat> Thanks I'll use that as a guide [22:56:28 CET] <SpeakerToMeat> let me sox these wavs first [22:56:29 CET] <furq> you might need to add the inputs to the start of filter_complex [22:57:00 CET] <c_14> you will have to add the inputs (or sort the -i differently) [22:57:16 CET] <c_14> since concat needs video,audio,video,audio and that'll pass video,video,video,audio,audio,audio [22:57:37 CET] <SpeakerToMeat> the inputs in this style: [0:v:0] right? for the audio, if it's 6 channel, how would I do, [0:a] ? [22:57:50 CET] <c_14> Just 1:a [22:57:53 CET] <furq> sounds easier to just sort the inputs like c_14 said [22:58:01 CET] <SpeakerToMeat> yes [22:58:25 CET] <SpeakerToMeat> Now let me clear some HDD space, throw XYZ->RGB on that mix and try it [22:58:32 CET] <SpeakerToMeat> Thanks furq and c_14 [23:02:39 CET] <SpeakerToMeat> Sorry how was it I could show the pixel formats, and options for a specific encoder? [23:02:53 CET] <c_14> ffmpeg -h encoder= [23:03:14 CET] <SpeakerToMeat> Thanks [23:10:52 CET] <SpeakerToMeat> Aaaand, last thing, sorry how was it to make a "center cut" transform? material is in 2048x1080 with black bands up and down... I... I did this the other day and lost the command and forgot.... let me google. [23:11:19 CET] <furq> !filter crop [23:11:19 CET] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#crop [23:12:14 CET] <SpeakerToMeat> I can add this as an extra filter after the concat, right? not to touch the complex filter... or should I glue it onto the complex filter [23:12:30 CET] <furq> you can't specify more than one filterchain [23:12:44 CET] <furq> just add ,crop=... before [out] [23:12:54 CET] <SpeakerToMeat> Ok, so I need to add it to the complex filter. [23:13:10 CET] <SpeakerToMeat> I will, thanks [23:36:57 CET] <feliwir> any idea where such a pattern might come from: http://imgur.com/RDJa8VA [23:37:06 CET] <feliwir> this image is supposed to be completly black [23:37:52 CET] <SpeakerToMeat> The x and y for crop or similar filters are indexed from 0 or 1? [23:38:04 CET] <c_14> SpeakerToMeat: 0, always [23:38:15 CET] <feliwir> hehe it looks like a optical illusion :P [23:40:17 CET] <SpeakerToMeat> c_14: Sorry to ask directly, do you have any experience with prores (in quicktime muxing)? [23:40:37 CET] <c_14> not really, why? [23:41:12 CET] <SpeakerToMeat> c_14: I know PCM audio to be used in mov with prores must be 16 bits, but I'm unsude if little endian or big endian, signed or unsigned [23:43:06 CET] <c_14> signed, but I don't think endianess matters [23:43:13 CET] <SpeakerToMeat> Ok, thanks [23:45:40 CET] <SpeakerToMeat> When using -i file%08d.png is there any way to overcome an error if the numbering doesn't start at 00000000 ? [23:45:51 CET] <c_14> -start_number [23:46:17 CET] <SpeakerToMeat> c_14: Right after/before the corresponding -i ? [23:46:21 CET] <c_14> before [23:46:42 CET] <c_14> options always affect the "file" they're in front of [23:46:48 CET] <SpeakerToMeat> And it wont affect other previous -i [23:46:51 CET] <SpeakerToMeat> ok [23:48:09 CET] <SpeakerToMeat> Hmmm [23:48:11 CET] <SpeakerToMeat> Too many inputs specified for the "crop" filter [23:48:32 CET] <SpeakerToMeat> -filter_complex "concat=n=2:v=1:a=1,crop=2048:858:0:111[out]" [23:48:41 CET] <c_14> you can't put the crop filter right after the concat [23:48:46 CET] <c_14> because crop doesn't accept audio [23:49:06 CET] <c_14> do concat=n=2:v=1:a=1[vout][aout];[vout]crop[out] -map [out] -map [aout] [23:49:06 CET] <SpeakerToMeat> hmmm ok... so I need the crop... before the concat... will it affect all inputs anyhow? [23:49:17 CET] <SpeakerToMeat> sure [23:50:15 CET] <SpeakerToMeat> And, working, thanks for all the toil c_14 [23:50:28 CET] <SpeakerToMeat> Filter language always sacres me, someday I ought to learn it more deeply [23:52:01 CET] <c_14> you get used to it [23:52:20 CET] <c_14> especially once you've started debugging filtergraphs spanning >10 lines [23:52:27 CET] <SpeakerToMeat> holy [23:52:50 CET] <SpeakerToMeat> Do you debug them the old fashioned way, or do you use tools like graphviz to see the structure? [23:53:00 CET] <JEEB> at that point you might want to think about running your own libav* API user [23:53:11 CET] <JEEB> instead of doing it with filter_complex :D [23:53:20 CET] <SpeakerToMeat> Yeah [23:54:05 CET] <SpeakerToMeat> It reminds me of going from 10 component SQL calls to 20 line PL/SQL monstrosities [23:57:27 CET] <SpeakerToMeat> Hmmm prores_ks profile hq should be using yuv422 but it's using yuv444 [23:57:36 CET] <SpeakerToMeat> Maybe I'll specify the pixel format by hand [23:57:55 CET] <JEEB> default picked usually depends on your source format [23:58:13 CET] <JEEB> prores has both 4:2:2 and 4:4:4 modes [23:58:25 CET] <SpeakerToMeat> Yeah, thing is -h encoder=prores_ks didn't list valid pixel formats (or I missed it) so I was wary at hand picking one [00:00:00 CET] --- Wed Mar 15 2017

1 0

ffmpeg-devel.log.20170313
by burek 14 Mar '17

14 Mar '17

[01:09:54 CET] <ubitux> jkqxz: thanks a lot for the qsv merges :) [02:46:09 CET] <atomnuker> bofh_: does fate pass? [02:51:54 CET] <stevenliu> Hi guy,can concatdec.c add live streaming support? or i saw concatdec have only file, is there have some problem to support live stream and file complex in list? [03:24:21 CET] <Compn> where steven go [03:24:30 CET] <Compn> i thought we figured a way for concat:http to work... [04:49:15 CET] <cone-224> ffmpeg 03Michael Niedermayer 07master:a720b854b0d3: avcodec/mpeg12dec: Fix runtime error: left shift of negative value -1 [04:49:15 CET] <cone-224> ffmpeg 03Michael Niedermayer 07master:a66c6e28b543: avcodec/rv34: Fix runtime error: signed integer overflow: 36880 * 66288 cannot be represented in type 'int' [04:49:15 CET] <cone-224> ffmpeg 03Michael Niedermayer 07master:967feea5ebb7: avcodec/vp6: clear dimensions on failed resolution change in vp6_parse_header() [04:59:23 CET] <cone-224> ffmpeg 03Steven Liu 07master:33e997d992cc: avformat/hlsenc: second_levels flags process function extract [07:55:34 CET] <andrey_turkin> Did anybody experienced issues with cuvid+nvenc transcoding with recent ffmpeg? It stopped working for me since lazy filters initialization patch came in [09:23:28 CET] <stevenliu> Hi Carl here? [09:23:57 CET] <ubitux> rarely [09:24:05 CET] <stevenliu> This is a duplicate of other h264-related tickets. Which ticket? [09:25:29 CET] <stevenliu> if the pkt->duration is 0, the hlsenc will has wrong duration at the last segment or discontinuity start segment [09:48:49 CET] <nevcairiel> like I wrote in the ticket, its not the demuxers job to try to guess the packet duration [09:49:07 CET] <nevcairiel> it works for s ome si mple codecs with fixed packet sizes [09:49:15 CET] <nevcairiel> because its just hard-coded somewhere [11:08:00 CET] <BtbN> andrey_turkin, worked for me when I tested that merge. [11:08:17 CET] <BtbN> Haven't tested after the recent batch of merges though [11:30:28 CET] <ubitux> http://b.pkh.me/ffmpeg.jpg so i got bored [13:57:45 CET] <BBB> michaelni: I dont disagree that he should be on ffmpeg-devel, but well& he isnt& ;-) [13:58:36 CET] <durandal_1707> who? [13:59:21 CET] <durandal_1707> vittorio? he just prefer less mails in inbox [14:00:43 CET] <BBB> yeah vittorio [14:01:13 CET] <BBB> Im getting a bunch of students that want to do vmaf now [14:01:18 CET] <BBB> I need more qualification tasks... [14:01:42 CET] <BBB> maybe Ill make turn netflix code into library a qualification task& although that might be quite a bit of work& too much? [14:03:28 CET] <wm4> isn't it conceptually pretty simple? [14:03:37 CET] <wm4> isn't it just basically a function [14:12:14 CET] <BBB> what is? [14:12:31 CET] <BBB> vmaf? sure, yes, but their code isnt organized quite like that :) [14:33:01 CET] Action: kierank hopes the next step isn't an IMF demuxer [15:31:30 CET] <cone-307> ffmpeg 03Paul B Mahol 07master:62c8dc46429b: avfilter/vf_lut3d: actually skip lines when encountering DOMAIN_ string [15:45:54 CET] <Compn> BBB : that realplayer ivr format? [15:46:07 CET] <BBB> kierank: imf=mxf [15:46:36 CET] <BBB> kierank: ffmpeg already supports it [15:47:10 CET] <Compn> http://samples.ffmpeg.org/real/ivr/ [15:47:35 CET] <Compn> guess it hasnt been REd by us, wonder if theres spec elsewhere, https://wiki.multimedia.cx/index.php/IVR [15:47:48 CET] <JEEB> no, IMF is much more complex [15:47:50 CET] <JEEB> than MXF [15:47:58 CET] <JEEB> it's multiple MXF files and XML [15:48:25 CET] <JEEB> also virtual timelines etc defined in the XML if I recall correctly [15:48:50 CET] <JEEB> IMF is a horrible, horrible format and I hope it dies in a fire [17:14:04 CET] <pps> is any one online [18:59:14 CET] <atomnuker> bofh_: ping [19:33:21 CET] <BBB> JEEB: omg :D well the mxf demuxer can read imf files for me [19:33:37 CET] <BBB> JEEB: but thats all I know, Ive never looked at these files and it doesnt sound like the type of thing Id care much about [20:42:03 CET] <cone-334> ffmpeg 03Paul B Mahol 07master:fbfbd97be25c: avcodec/xpmdec: there are XPM files with dos line endings [21:42:47 CET] <durandal_1707> michaelni: do you know why scpr doesnt work with vlc direct rendering? [21:57:44 CET] <JEEB> BBB: yea, the separate media files in an IMF package is something that lavf can handle [21:57:47 CET] <JEEB> https://media.xiph.org/video/derf/meridian/MERIDIAN_SHR_C_EN-XX_US-NR_51_LT… [21:57:51 CET] <JEEB> this is an IMF sample [21:58:00 CET] <JEEB> (and a simple one at that) [21:58:31 CET] <JEEB> N levels of XML because muxing things together is way overrated :D [21:59:02 CET] <nevcairiel> its probably designed for use in mastering houses and whatnot, where replacing or adding streams is a common workflow? [21:59:17 CET] <JEEB> yea [21:59:35 CET] <michaelni> durandal_1707, no i dont know that [21:59:48 CET] <JEEB> although the idea is that IMF is what the mastering people export for final encodes [22:00:23 CET] <durandal_1707> michaelni: then who will know? [22:12:28 CET] <michaelni> durandal_1707, whats different between scpr and others which work ? [22:13:50 CET] <durandal_1707> michaelni: it needs to keep prev decoded untouched, for mv stuff and others [22:14:14 CET] <durandal_1707> using reget buffer doesnt work [22:14:48 CET] <michaelni> sounds like mpeg P frames [22:15:03 CET] <kierank> JEEB: yeah it's like a dvd i guess [22:15:13 CET] <kierank> all these multiformat things don't really fit into lavf [22:15:20 CET] <kierank> ffmpeg -i imf:// [22:15:21 CET] <kierank> eugh [22:16:26 CET] <JEEB> kierank: don't call it out, it might actually appear ;) [22:16:45 CET] <kierank> in java [22:17:01 CET] <JEEB> iä iä [23:07:09 CET] <nevcairiel> i nominate JEEB to work on it [23:11:27 CET] <JEEB> after I finally get ATRAC3+ parsing and earthsoft dv upstreamed [23:11:41 CET] <nevcairiel> havent you been talking about those things for a while now [23:12:53 CET] <JEEB> that's the idea 8) [23:13:03 CET] <JEEB> earthsoft dv demuxing I had done [23:13:30 CET] <JEEB> although then I hit the whole thing about bitstream'd audio [00:00:00 CET] --- Tue Mar 14 2017

1 0

ffmpeg.log.20170313
by burek 14 Mar '17

14 Mar '17

[00:52:52 CET] <faLUCE> is there any function in libAV which I can use in order to obtain the number of bytes for a given format ? [00:53:31 CET] <faLUCE> for example: AV_SAMPLE_FMT_FLT must return 4 (32 bits) [01:02:08 CET] <faLUCE> found it: av_get_bytes_per_sample() [01:06:53 CET] <the_k_> can anyone help? [01:06:56 CET] <the_k_> ffmpeg -i rtsp://10.0.0.10:554/Streaming/Channels/2 -vf "select=gt(scene\,0.005),setpts=N/(25*TB)" -f segment -segment_time 21600 -strftime 1 fd_motion_%%Y-%%m-%%d-%%H;%%M;%%S.ts [01:07:42 CET] <the_k_> i added everything after "-vf" to make it so that i can read the file as it's being written, but this makes the recording really blurry [01:07:51 CET] <the_k_> oops no [01:08:20 CET] <the_k_> i added the "-f segment ..... " and everything following that [01:09:16 CET] <the_k_> can anyone suggest what i could change to keep the original quality of the stream? [01:45:34 CET] <the_k_> a friend seems to think that changing the output filename extension from .ts to .mkv will alter what ffmpeg does when outputting the file, could this be true? [01:51:37 CET] <ps-auxw> the_k_: I'm pretty sure it does, yes. [01:52:48 CET] <ps-auxw> If you put .mkv, it should use the matroska muxer and will probably use different default encoders for audio and video. [01:54:00 CET] <ps-auxw> The output being blurry with your previous commandline might be due to insufficient bitrate or otherwise undesirable encoder default settings. [01:56:39 CET] <ps-auxw> the_k_: Try with something like "-acodec copy -vcodec libx264 -crf 18 out.mkv", if the filesize is too big, make the crf number bigger, if quality isn't high enough make it smaller. You can also try different -preset settings for encoding time/quality trade-offs. [02:05:42 CET] <the_k_> yeah i just looked at the file in a hex viewer [02:05:45 CET] <the_k_> i couldn't believe it [02:06:15 CET] <the_k_> can't i just dump it raw? it's an rtsp stream [02:06:27 CET] <the_k_> i really don't want to reencode it [02:11:04 CET] <ps-auxw> You can try -vcodec copy, but I'm not sure you can use -vf with that then. [02:11:39 CET] <ps-auxw> Most filters work in a decode-process-encode way. Maybe all, I'm not sure. [02:14:03 CET] <the_k_> -c:all copy [02:14:20 CET] <the_k_> friend said to try this and it outputs fine to mkv [02:15:07 CET] <the_k_> i'm not sure if it's actually doing anything though as when i tried the command without that and was outputting to mkv it was also fine.. no blur [02:19:06 CET] <the_k_> it's possible to write another copy straight to disk without the motion detection part in the same command, right? [02:29:08 CET] <the_k_> weird.. i get over 50% cpu when i do [02:29:19 CET] <the_k_> but i dont' if i'm using two instances of ffmpeg [02:29:24 CET] <the_k_> also it loses a ton of framesa [02:30:24 CET] <the_k_> would be a lot better if i could use a single rtsp stream because then it means there's more available bandwidth for the camera and then it leaves room for one more device to connect to it [05:17:36 CET] <the_k_> is there a way to stop ffmpeg from terminating when it reaches the end of an input file? [05:18:00 CET] <the_k_> i need it to wait till the file is a bit bigger [05:20:05 CET] <ZeroWalker> pipe it and close it manually or something perhaps [05:22:30 CET] <the_k_> ahh [05:22:31 CET] <the_k_> ok [05:22:41 CET] <the_k_> hmm [05:22:55 CET] <the_k_> wouldn't piping it stop it from writing a file though? [05:23:13 CET] <the_k_> it would need two outputs then.. which always makes it drop frames [05:30:36 CET] <ZeroWalker> well you are supposed to have one input and one output [05:31:01 CET] <ZeroWalker> the output can be a standard one, and the input could be a pipe [05:31:43 CET] <ZeroWalker> then you just write to that pipe somehow and when you are done with that input file you just close the pipe [05:33:17 CET] <the_k_> so it's not good to have one input and two outputs [05:33:19 CET] <the_k_> ? [05:34:39 CET] <the_k_> i need one file to be written so that i get a HD recording 24/7 of the camera for security reasons [05:34:52 CET] <ZeroWalker> and the other output? [05:35:17 CET] <the_k_> and the secondary file is just so i can do motion detection on it so that i can fairly quickly scan through to check for any idiots that have been around as has been the case lately [05:35:28 CET] <the_k_> gang of 3 tried to push the way in through the front door [05:35:32 CET] <the_k_> all dressed in black [05:36:19 CET] <ZeroWalker> so it's a different encoding, not just a copy [05:36:27 CET] <the_k_> so i require these things: the best HD recording i can obtain .. written to file that doesn't skip a beat [05:36:53 CET] <the_k_> and an easy way to view movement / line crosses throughout the day [05:37:03 CET] <the_k_> oh and also a live feed.. doesn't need to be HD but is nice [05:37:14 CET] <ZeroWalker> well it's all up to the performance of the hardware rly [05:37:17 CET] <the_k_> the motion detection is, yes.. and the quality again doesn't really matter [05:37:30 CET] <the_k_> i920 cpu, overclocked to 3.9mHz [05:37:43 CET] <ZeroWalker> ghz i would assume [05:37:45 CET] <the_k_> i have an nvidia 1080 gfx card though.. [05:37:49 CET] <the_k_> ah yea :D [05:37:52 CET] <the_k_> haha [05:37:57 CET] <the_k_> no it's a new model calculator! [05:38:05 CET] <ZeroWalker> hmm is it called i920? [05:38:06 CET] <ZeroWalker> ;P [05:38:15 CET] <the_k_> yeah chinese branding [05:38:18 CET] <ZeroWalker> well with the gpu you could use NVENC to encode [05:38:26 CET] <the_k_> right yeah [05:38:29 CET] <ZeroWalker> that's super fast and then performance is no problem [05:38:32 CET] <the_k_> anything to split the loaed [05:38:33 CET] <the_k_> load [05:38:36 CET] <the_k_> mm [05:38:39 CET] <ZeroWalker> though, size and quality will take a tole [05:38:49 CET] <the_k_> for the HD recording? [05:38:57 CET] <ZeroWalker> for anything that uses NVENC [05:39:03 CET] <the_k_> i'm sure raw dumping is less intensive [05:39:17 CET] <the_k_> so as long as the initial file recording is best quality i don't care [05:39:21 CET] <ZeroWalker> NVENC is fast, but quality is bad, so you have to bump up the bitrate to get it closer to x264 level [05:39:24 CET] <the_k_> the motion detection bit can use gpu [05:39:39 CET] <ZeroWalker> well there is no such thing as "best quality" unless you do lossless [05:39:58 CET] <the_k_> that's not a problem. i just need to see if there's any idiots outside [05:39:58 CET] <ZeroWalker> you have to find what you think works best in terms of quality/size/performance [05:40:09 CET] <the_k_> 1) live 2) looking back at the day [05:40:27 CET] <ZeroWalker> well then you probably dont' need any "good" quality [05:40:33 CET] <the_k_> i think it's a raw dump that i'm doing wiht this? :... [05:40:47 CET] <the_k_> e:\fd\ffmpeg -i rtsp://fd:554/Streaming/Channels/1 -c copy -f segment -segment_time 86400 -strftime 1 cam_fd_HD.ts [05:40:51 CET] <ZeroWalker> a raw dump would probably be massive in size [05:40:58 CET] <the_k_> that's a raw dump, right? [05:41:03 CET] <the_k_> i don't mind [05:41:10 CET] <ZeroWalker> hmm, yeah so it sends in mpeg2 [05:41:13 CET] <the_k_> i have a 3tb drive for it [05:41:20 CET] <the_k_> erm [05:41:22 CET] <ZeroWalker> well then it's easy enough, you can just do the copy thing [05:41:25 CET] <the_k_> it's sending in h.264 [05:41:31 CET] <ZeroWalker> oh [05:41:38 CET] <ZeroWalker> didn't know .ts supported that [05:41:46 CET] <ZeroWalker> but that's even better [05:41:55 CET] <the_k_> MPEG-4 AVC [05:42:04 CET] <the_k_> i've never heard of the ts format before.. it's new to me [05:42:09 CET] <ZeroWalker> yeah if you get that without encoding, then the camera handles that for you [05:42:16 CET] <the_k_> but it worked for the job of being able to play the file at the end of the file live [05:42:31 CET] <the_k_> so that saves me bandwidth and allows others to view the live view of the camera [05:42:31 CET] <ZeroWalker> well it's a weird format, i personally would suggest mp4 or mkv, but whatever works [05:42:51 CET] <the_k_> right [05:42:57 CET] <the_k_> can test mp4 now [05:42:59 CET] <ZeroWalker> well with that setup, does it actually close randomly? [05:43:09 CET] <the_k_> no [05:43:12 CET] <ZeroWalker> i would have thought it would only close after the server closes [05:43:15 CET] <ZeroWalker> ah [05:43:17 CET] <the_k_> i close it manually [05:43:28 CET] <ZeroWalker> so, what's the problem with that one? [05:43:31 CET] <the_k_> i segment the file up into 24 hourly files [05:43:34 CET] <the_k_> erm [05:43:38 CET] <ZeroWalker> ah [05:43:48 CET] <the_k_> the problems only come in when i want to do motion detection [05:43:51 CET] <the_k_> and live viewing it [05:44:11 CET] <ZeroWalker> you can't live view it while it's copynig? [05:44:23 CET] <the_k_> i can have two inputs into two seperate instances of ffmpeg so that i get my hd recording and my motion dectection file [05:44:48 CET] <ZeroWalker> hmm [05:44:52 CET] <the_k_> then i need a live view, so i play the hd recording near the end of the file (currently having issues with that for some reason and it's gone from 3s lag from live to 20) [05:45:18 CET] <ZeroWalker> well i mean, the motion detection files, can't you just check the last 24 hours instead? [05:45:40 CET] <the_k_> but that's two inputs .. two rtsp streams the camera has to fill the network with.. and like i say.. i want to be able to have other ppl and devices able to view the live feed [05:45:54 CET] <ZeroWalker> hmm, pretty sure you should be able to display it with ffplay or something while you are copying, so you always have a live window [05:46:02 CET] <the_k_> instead of live? no.. no doorbell up here and i prefer a live view [05:46:10 CET] <the_k_> lots of deliveries [05:46:41 CET] <ZeroWalker> you would get live if you display it right before you copy, or vice versa, in the same command thing [05:46:43 CET] <the_k_> hmm.. did try that but it dropped frames [05:46:56 CET] <ZeroWalker> hmm, on the result file or the display? [05:47:03 CET] <the_k_> maybe i should have had the live view first [05:47:09 CET] <the_k_> both [05:47:20 CET] <ZeroWalker> yeah try the live view first [05:47:20 CET] <the_k_> the image starts losing some of it's horizontal lines [05:47:27 CET] <the_k_> so you see the bottom of the image crawl upwards [05:47:34 CET] <the_k_> ok [05:47:38 CET] <the_k_> -f nut - | e:\fd\mpv\mpv.exe - [05:47:45 CET] <the_k_> that's what i added to get a live view [05:47:52 CET] <the_k_> but it uses a pipe so.. [05:48:02 CET] <the_k_> not sure that'll work but can test.. [05:48:11 CET] <ZeroWalker> that's... odd, it it feels like it doesn't read the entire frame then, and it then you will get this "circular frame" thingy occuring [05:48:14 CET] <the_k_> e:\fd\ffmpeg -i rtsp://fd:554/Streaming/Channels/1 -f nut - | e:\fd\mpv\mpv.exe - -c copy -f segment -segment_time 86400 -strftime 1 cam_fd_HD.ts [05:48:31 CET] <the_k_> it says something about circular something in the output [05:48:32 CET] <the_k_> sec [05:48:38 CET] <ZeroWalker> not sure what mpv is, isn't there like ffplay? [05:48:53 CET] <the_k_> it's a player more updated [05:49:00 CET] <the_k_> ffplay was apparantly outdated and buggy or something [05:49:06 CET] <the_k_> ppl here and elsewhere preffered it [05:49:13 CET] <ZeroWalker> ah [05:49:17 CET] <the_k_> it did seem better anyweay [05:49:31 CET] <the_k_> [udp @ 000000000064c6e0] 'circular_buffer_size' option was set but it is not supported on this build (pthread support is required) [05:49:31 CET] <the_k_> [udp @ 000000000064c7a0] 'circular_buffer_size' option was set but it is not supported on this build (pthread support is required) [05:49:53 CET] <the_k_> ah that's weird.. it doesn't even bring up mpv [05:50:09 CET] <ZeroWalker> hmm, not sure what that does, but it does say that the build doesn't support it, so it might be well to try another version [05:50:13 CET] <the_k_> e:\fd\ffmpeg -i rtsp://fd:554/Streaming/Channels/1 -f nut - | e:\fd\mpv\mpv.exe - -c copy -f segment -segment_time 86400 -strftime 1 cam_fd_HD.ts [05:50:16 CET] <the_k_> this must be badly formatted [05:50:27 CET] <the_k_> i can't see a pipe int hemiddle of the command working [05:50:45 CET] <ZeroWalker> hmm looks weird, you just open the exe file, then again [05:50:46 CET] <the_k_> well this is the latest build [05:50:48 CET] <ZeroWalker> hmm [05:51:00 CET] <the_k_> then again? [05:51:02 CET] <ZeroWalker> what happens if you open the stream manually in mpv while you are copying in ffmpeg? [05:51:10 CET] <the_k_> it ends [05:51:10 CET] <the_k_> sec [05:51:16 CET] <the_k_> lemme make sure i'm right [05:51:26 CET] <the_k_> e:\fd\ffmpeg -i rtsp://fd:554/Streaming/Channels/1 -c copy -f segment -segment_time 86400 -strftime 1 cam_fd_HD.ts [05:51:29 CET] <the_k_> with this : [05:52:01 CET] <the_k_> some players handle end of file differently [05:52:17 CET] <the_k_> ah i'm 10s lagged but this is working now [05:52:31 CET] <the_k_> 2 lagged [05:52:33 CET] <the_k_> this is fine [05:52:35 CET] <the_k_> hnn [05:52:36 CET] <the_k_> hmm [05:52:43 CET] <ZeroWalker> wait so you are currently copying and you have it play in mpv separately? [05:52:51 CET] <the_k_> yeah [05:52:56 CET] <ZeroWalker> well, that's great [05:52:57 CET] <the_k_> i just opened the file up in mpv [05:53:03 CET] <ZeroWalker> oh [05:53:07 CET] <ZeroWalker> i meant, open the stream [05:53:14 CET] <the_k_> in mpv? [05:53:16 CET] <ZeroWalker> i rtsp://fd:554/Streaming/Channels/1 this [05:53:18 CET] <ZeroWalker> yeah [05:53:20 CET] <the_k_> no that would be bad [05:53:23 CET] <the_k_> waste of bandwidth [05:53:40 CET] <the_k_> the stream is max bandwidth the cam can output [05:53:48 CET] <the_k_> highest fps, highest quality [05:53:51 CET] <ZeroWalker> ah [05:54:00 CET] <ZeroWalker> but, you have tried it? [05:54:03 CET] <the_k_> and if i stream it twice then everything will drop frames [05:54:26 CET] <the_k_> yeah but i ALSO need at least one more client to be able to get the stream from the webpage it serves [05:54:37 CET] <the_k_> this is why i really need to be conservatve [05:55:01 CET] <ZeroWalker> ah, not that knowledgeable about how rtsp works [05:55:21 CET] <the_k_> so at the moment i can play the file that's outputted and i have a good recording.. but if i want motion detection i have to start another ffmpeg up [05:55:24 CET] <ZeroWalker> but hmm well the problem with playing the file is that it can play it faster then it records (or vice versa) [05:55:31 CET] <the_k_> well it just eats bandwidth [05:55:44 CET] <the_k_> it's not like a network multicast [05:55:49 CET] <the_k_> some cameras can do that [05:56:24 CET] <the_k_> i.e. just spams the network but everyone can access it .. infinite clients without any extra bandwidth [05:56:29 CET] <the_k_> like tuning into a radio [05:56:46 CET] <the_k_> that would be ideal. the camera even has an option to set that but it doesn't work [05:56:57 CET] <ZeroWalker> ah, heard about multicast, but never knew what it was, nice [05:57:10 CET] <the_k_> it breaks the webpage live view that it serves and it doesn't reduce bandwidth [05:57:24 CET] <the_k_> so i just turned it back to UDP [05:57:45 CET] <the_k_> which means for each client that accesses the live view.. it sends out another stream [06:00:55 CET] <ZeroWalker> e:\fd\ffmpeg -i rtsp://fd:554/Streaming/Channels/1 -f nut - | ffplay - | - -c copy -f segment -segment_time 86400 -strftime 1 cam_fd_HD.ts [06:01:19 CET] <ZeroWalker> does something like that work. not really how how you normally make a passthrough in a pipe [06:02:43 CET] <the_k_> when you make a pipe you can't just carry on the command [06:02:54 CET] <the_k_> it dumps the output data into the pipe [06:03:03 CET] <ZeroWalker> think you can use -f tee [06:03:26 CET] <ZeroWalker> https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs [06:03:57 CET] <ZeroWalker> https://ffmpeg.org/ffmpeg-formats.html#tee [06:04:10 CET] <the_k_> '-' is not recognized as an internal or external command, [06:04:28 CET] <the_k_> tha'ts what i get from that [06:04:36 CET] <ZeroWalker> yea mine is plain wrong, but you should try using tee [06:04:41 CET] <ZeroWalker> seems to do precisely what you want [06:04:44 CET] <the_k_> ah [06:04:52 CET] <the_k_> ah right nice! [06:22:11 CET] <the_k_> [mpegts @ 00000000047415c0] H.264 bitstream malformed, no startcode found, use the video bitstream filter 'h264_mp4toannexb' to fix it ('-bsf:v h264_mp4toannexb' option with ffmpeg) [06:22:11 CET] <the_k_> av_interleaved_write_frame(): Invalid data found when processing input [06:22:34 CET] <the_k_> oh it's working now [06:22:46 CET] <the_k_> skipping a couple frames but not too many [06:25:32 CET] <the_k_> losing quite a lot of frames actually [06:26:04 CET] <the_k_> e:\fd\ffmpeg -i rtsp://fd:554/Streaming/Channels/1 -c copy -f segment -segment_time 86400 -strftime 1 cam_fd_HD.ts -f tee -vf "select=gt(scene\,0.005),setpts=N/(25*TB)" -f segment -segment_time 21600 -strftime 1 fd_motion_%%Y-%%m-%%d--%%H;%%M;%%S.ts -f tee -f nut - | e:\fd\mpv\mpv.exe - [06:26:10 CET] <the_k_> is my command formatted right? [11:09:29 CET] <feliwir> wow... This file was changed a lot recently: https://github.com/FFmpeg/FFmpeg/blob/6e913f212907048d7009cf2f15551781c69b9… [11:11:41 CET] <feliwir> vp56_render_mb isn't inside the latest ffmpeg version i have locally [11:13:22 CET] <kfolman> Hi guys. I'm fiddling around with a problem mapping audio tracks. Discreet channels map find, and mono channel is mapped fine as well. However if i mix those two, i run into problems. track 0:1 and 0:2 are mono tracks. ch 0:3 has a two channel discreet track. But i can't seem to nail the command where i'm able to map 0:1 and 0:2:1 to a two channel output. This is my syntax so far. http://pastebin.com/GaGXZwiM [12:21:42 CET] <faLUCE> Hello. How can I list with ffmpeg the PCM sound formats supported by AAC encoder? [12:49:48 CET] <mmsky> https://thepasteb.in/p/mwh1z8vBKJPt5 [12:50:07 CET] <mmsky> hello anyway [12:50:31 CET] <mmsky> can anyone help me with that? (above) [12:50:59 CET] <c_14> ldd $HOME/bin/ffmpeg [12:51:48 CET] <c_14> It's probably linking (at runtime) to a system version of ffmpeg, prefix the command with LD_LIBRARY_PATH="$HOME/ffmpeg_build/lib" [12:52:02 CET] <mmsky> https://thepasteb.in/p/zmh86EK6X2wiZ [12:52:21 CET] <c_14> yeah, exactly what I said [12:52:45 CET] <c_14> either prefix the command at runtime with the LD_LIBRARY_PATH or set LD_RUN_PATH at compiletime [12:52:56 CET] <c_14> Or --enable-static --disable-shared [12:53:12 CET] <c_14> So that the libav* libraries are linked into the binaries statically instead of dynamically [12:56:37 CET] <furq> cool, a new pastebin [12:56:40 CET] <furq> i'll add it to the ball [13:02:26 CET] <mmsky> ok, for now it is works. I tried before with static but got other error with vaapi version, but now it is able to run. I will testing it [13:02:34 CET] <mmsky> thank very much;) [13:23:38 CET] <mmsky> another error with library [13:23:51 CET] <mmsky> https://thepasteb.in/p/oYhlE5JBrJnfZ [13:24:47 CET] <mmsky> i run with: ~/bin/ffmpeg -f decklink -i 'DeckLink Duo (0)@12' -c:v libx264 -pix_fmt yuv420p -preset ultrafast -y -f avi abc1.avi [13:30:41 CET] <c_14> where is libDeckLinkAPI.so? [13:37:14 CET] <acresearch> JEEB: hey, you online? the video works, but i get (AUDIO codec not supported),,, what should i do? this was the last command you sent me (ffmpeg -i input.mkv -c:v libx264 -preset veryfast -level 41 -crf 21 -vf scale=1920:1080 -c:a copy -sn out.mp4) [13:39:08 CET] <acresearch> anyone here who can assist me? [13:39:55 CET] <JEEB> acresearch: switch -c:a copy to -c:a aac -b:a 192k -ac 2 [13:40:01 CET] <JEEB> that should work [13:40:47 CET] <acresearch> JEEB: so the final command is this? (ffmpeg -i input.mkv -c:v libx264 -preset veryfast -level 41 -crf 21 -vf scale=1920:1080 -c:a aac -b:a 192k -ac 2 -sn out.mp4) [13:41:42 CET] <IntruderSRB> can someone point me in the right direction (documentation/tutorial/stackoverflow). I'm trying to pass byte array that contains multiple NAL units (one of them is VideoNAL H264) to my C lib (through JNI). My C lib will than utilize libavcodec to parse that byte array. [13:41:58 CET] <JEEB> acresearch: looks good enough [13:42:02 CET] <IntruderSRB> most of the stuff I found are related to file inputs ... any suggestions/point-to will be appritiated :) [13:42:04 CET] <JEEB> that will transcode your DTS audio to AAC [13:42:06 CET] <acresearch> JEEB: thanks [13:42:18 CET] <JEEB> and makes it stereo [13:43:03 CET] <acresearch> oh ok i see [13:47:17 CET] <mmsky> ok i dont install drivers but included headers in compilation. But now got another error when run command above: "Segmentation fault [13:47:17 CET] <mmsky> " [13:49:04 CET] <mmsky> with that decklink is trouble at least, dunno what could be wrong? [13:50:51 CET] <mmsky> i install .deb from Blackmagic_Desktop_Video_Linux_10.8.4/deb/amd64/desktopvideo_10.8.4a4_amd64.deb [16:41:23 CET] <DelphiWorld> yo everyone [16:41:49 CET] <DelphiWorld> how to transcode the entire content of a containair, including all audio tracks? [16:44:15 CET] <furq> DelphiWorld: -map 0 [16:44:50 CET] <DelphiWorld> furq, but for a stream where i dont know how many audio stream, how to get them all? [16:45:54 CET] <DelphiWorld> ah [16:46:05 CET] <DelphiWorld> so -map 0 will copy everything, including subtitles [20:13:26 CET] <tatack> Hi guys, can ffmpeg act as rtmp server (receiving rtmp stream as input)? [20:13:39 CET] <tatack> According to https://www.ffmpeg.org/ffmpeg-protocols.html#rtmp it seems so, but i can't find how use the listen parameter :-( [20:14:05 CET] <furq> tatack: -listen 1 -i rtmp://0.0.0.0:1935/live/foo [20:14:43 CET] <BtbN> That's an rtmp client though. [20:16:37 CET] <furq> ? [20:17:13 CET] <furq> tatack: you probably want to use a proper rtmp server anyway [20:17:38 CET] <furq> that works the same way as all of ffmpeg's server functionality, i.e. badly [20:18:17 CET] <tatack> furq: :-) ok, thanks, i will try. [20:19:21 CET] <DHE> yeah, get a real rtsp server and have ffmpeg feed it instead [20:22:40 CET] <Fenrirthviti> tatack: nginx-rtmp is kinda the go-to free solution [20:22:52 CET] <Fenrirthviti> for small scale private RTMP servers [20:26:11 CET] <tatack> Fenrirthviti: thanks, i just looked at nginx. seems nice. [20:26:23 CET] <furq> it is nice [20:27:49 CET] <Fenrirthviti> It's got some quirks, but overall it's pretty solid for most things rtmp [21:19:43 CET] <sinanksu> hi [21:29:19 CET] <feliwir> Call me crazy but to me it seems like it does do Colums first and then rows: https://github.com/FFmpeg/FFmpeg/blob/c87ea47481d35b0219e2e22d60f2a431286f7… [21:29:42 CET] <feliwir> atleast it seems like this from the calculation. So the comment would be wrong [21:30:36 CET] <feliwir> also the original vp62 sourcecode does do it the opposite way: https://gist.github.com/feliwir/8aadbfdaca177ec67ebd6abc6d31b222 [21:35:23 CET] <faLUCE> is it possible to decode a "raw" AAC file? If I call avcodec_encode_audio2() and then fwrite() the encoded packets, I can't play the produced file with ffplay. I can play it if it's encoded with MP2 codec [21:36:38 CET] <acresearch> hey JEEB you online? [21:36:49 CET] <durandal_1707> never [21:37:54 CET] <acresearch> JEEB: ok finished converting, the video went down from 23 GB to 1.4GB big difference, i don't think it is HD anymore, the last command you sent me was this (ffmpeg -i in.mkv -c:v libx264 -preset veryfast -level 41 -crf 21 -vf scale=1920:1080 -strict -2 -c:a aac -b:a 192k -ac 2 -sn out.mp4) [21:38:58 CET] <furq> 1080p looks pretty hd to me [21:48:39 CET] <acresearch> furq: how do i know it is truly 1080p? could the convertion compressed it wrongly? [21:49:14 CET] <furq> because it says "-vf scale=1920:1080" [21:49:49 CET] <acresearch> ok [21:51:58 CET] <JEEB> acresearch: it's not Ultra HD (2160p), but it is HD (1080p) :P [21:52:12 CET] <JEEB> your TV cannot play Ultra HD anyways [22:07:00 CET] <faLUCE> any advice about that? It seems that AAC encoder needs an AAC muxer. in ffmpeg 3.2, while in the previous version (2.8) it doesn't [22:07:11 CET] <furq> it works fine here [22:07:23 CET] <faLUCE> furq: what? [22:07:30 CET] <acresearch> JEEB: hmmm, well i have a working copy, i want to try to see if i can increase the HD, the next step after 1080 is ? [22:07:31 CET] <furq> decoding aac [22:07:37 CET] <BtbN> I don't think there even is such a thing as an aac muxer [22:07:53 CET] <furq> no idea about with the api, but ffmpeg decodes adts just fine [22:08:59 CET] <faLUCE> If I simply add a fwrite() after avcodec_encode_audio2(), I can't decode the produced file [22:09:35 CET] <faLUCE> so, it seems that a container (avformat) is needed [22:10:36 CET] <faLUCE> I just added "fwrite(output_packet.data, 1, output_packet.size, encodedFile);" in transcode_aac.c example [22:12:39 CET] <BtbN> of course, you always need to mux stuff. Writing raw data to disk rarely ever works. [22:12:57 CET] <BtbN> aac and mp3 should be formats where it does though. Probably still needs some mini-container, like a header or something [22:14:10 CET] <BtbN> Yeah, the .aac files are made using the adts muxer. [22:16:14 CET] <faLUCE> BtbN: exactly. But in the previous version it were not [22:16:55 CET] <JEEB> are you sure? that the parser/muxer weren't just silently enabled [22:17:19 CET] <BtbN> Using which encoder? Maybe you're using fdk, faac or something, and it happens to output adts [22:17:21 CET] <faLUCE> JEEB: I'm pretty sure. In addition, even if I do a simple fwrite, I see a header [22:17:52 CET] <faLUCE> and I remember that I could decode the "raw" aac file in the previous version [22:18:52 CET] <BtbN> those raw aac files are usually adts. If you write actual raw aac to disk, I don't think anything will be able to parse it [22:19:29 CET] <faLUCE> this is pretty bad. I think it's a failure in the API, because with mp2 I can do that. And mp2 is conceptually the same as aac [22:24:33 CET] <faLUCE> otherwise, the previous version of ffmpeg automatically added adts mux to aac encoded frames... what do you think? [22:26:00 CET] <JEEB> or the muxer was just quietly enabled [22:26:06 CET] <JEEB> or it was separated recently [22:27:05 CET] <faLUCE> JEEB: uhmmmmm [23:20:55 CET] <aptalca> While attempting hardware encode with intel haswell, I'm getting the following error "avcodec_open2 returned -38 for encoder 'h264_vaapi'" Does anyone know what code 38 means? Thanks. [23:25:00 CET] <aptalca> Log here between lines 100 and 117: http://pastebin.com/NKkhfpsj [23:35:50 CET] <jkqxz> It's just an errno. [23:36:00 CET] <jkqxz> So ENOSYS. [23:36:16 CET] <jkqxz> The interesting bit of log is "Encoding entrypoint not found (7 / 6).". [23:37:25 CET] <jkqxz> Which suggests that your driver doesn't support encoding H.264 at high profile. [23:51:16 CET] <feliwir> so for YUV 420 i get 3 planes created in ffmpeg. But i have no clue how to figure out the size of each plane in bytes (depending on width * height) [23:52:44 CET] <DHE> ENOSYS - function not implemented. hardware capabilities (in part or in whole) not available [23:53:21 CET] <JEEB> feliwir: there's something that gives you the size per sample (although you could look at the pix_fmt as well and make assumptions), and then you have to know that it's Y,Cb,Cr and that Cb and Cr in 4:2:0 are subsampled in width and height [23:54:06 CET] <feliwir> JEEB, i just want to know how to do the calculation :( Completly not depending ffmpeg [23:54:18 CET] <JEEB> and then you have linesize which tells you the amount of uint8_t to go to the next line in the plane [23:54:33 CET] <JEEB> (which can be more than just width*bytes_per_sample due to alignment etc [23:54:49 CET] <JEEB> feliwir: well YUV420P is 4:2:0, planar, 8bit [23:55:02 CET] <DHE> but the number of bytes for a plane should be linesize * height, right? [23:55:14 CET] <JEEB> yes [23:55:17 CET] <kerio> are our eyes really so bad that they're fine with 4 bits of color [23:55:18 CET] <JEEB> although it can be more [23:55:22 CET] <feliwir> it's 6 bytes per 4 pixels for YUV 420 i've read [23:55:38 CET] <DHE> kerio: more like 2 pixels can use the same 8 bits of colour [23:55:43 CET] <iive> kerio: even worse [23:56:03 CET] <iive> kerio: eyes are most sensitive to luminance [23:56:22 CET] <feliwir> so it would would be: (width*height/4)*6 bytes for a plane i'd guess? [23:56:28 CET] <JEEB> feliwir: in 4:2:0 chroma is "one sample for 2x2 area" and then you have chroma location which has two defaults (one MPEG-1 style and another MPEG-2+ style) [23:56:44 CET] <JEEB> top-left for mpeg-2 was it? [23:56:50 CET] <JEEB> and mpeg-1 had just top or bottom? [23:58:08 CET] <JEEB> feliwir: at the very minimum, without any alignment it would be (width*height) + 2*((width/2)*(height/2)) [23:59:27 CET] <feliwir> okay, thanks [23:59:50 CET] <feliwir> that is per plane? Because it seems like every component has a seperate plane in ffmpeg [00:00:00 CET] --- Tue Mar 14 2017

1 0

ffmpeg-devel.log.20170312
by burek 13 Mar '17

13 Mar '17

[03:11:45 CET] <chatter29> hey guys [03:11:48 CET] <chatter29> allah is doing [03:11:55 CET] <chatter29> sun is not doing allah is doing [03:11:57 CET] <chatter29> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger [03:22:13 CET] <Compn> this allah guy sounds needy [04:38:49 CET] <cone-347> ffmpeg 03Michael Niedermayer 07master:47cc9c1d77f5: avcodec/wavpack: Fix runtime error: signed integer overflow: -2147483648 + -83886075 cannot be represented in type 'int' [04:38:49 CET] <cone-347> ffmpeg 03Michael Niedermayer 07master:f4c2302ee24d: avcodec/dca_xll: Fix runtime error: signed integer overflow: 1762028192 + 698372290 cannot be represented in type 'int' [04:38:49 CET] <cone-347> ffmpeg 03Michael Niedermayer 07master:44e2105189ac: avcodec/amrwbdec: Fix runtime error: left shift of negative value -1 [04:38:49 CET] <cone-347> ffmpeg 03Michael Niedermayer 07master:ce010655a6b8: avcodec/dca_xll: Fix runtime error: signed integer overflow: 2147286116 + 6298923 cannot be represented in type 'int' [11:33:58 CET] <paras2052> durandal_1707: Did you see the latest patch i sent ? [11:48:35 CET] <durandal_1707> paras2052: yes i did [11:48:51 CET] <paras2052> durandal_1707: is it fine ? [11:49:28 CET] <durandal_1707> mostly [11:50:32 CET] <paras2052> okay, what do i have to do next. any other task ? [11:52:02 CET] <durandal_1707> you need to complete gsoc stuff [11:52:50 CET] <paras2052> durandal_1707: yes i know that. Student applications date is 20th march. Should i start making proposal now ? [11:52:58 CET] <durandal_1707> yes [11:53:05 CET] <paras2052> okay [12:37:03 CET] <cone-378> ffmpeg 03Paul B Mahol 07master:807d5dcde9d8: avcodec/scpr: use correct linesize for prev frame [13:11:10 CET] <cone-378> ffmpeg 03Anton Khirnov 07master:b0f36a0043d7: avconv: stop using setpts for input framerate forced with -r [13:11:11 CET] <cone-378> ffmpeg 03Clément BSsch 07master:993a9a3d72af: Merge commit 'b0f36a0043d76436cc7ab8ff92ab99c94595d3c0' [13:13:26 CET] <cone-378> ffmpeg 03Anton Khirnov 07master:6f40181cad8a: avconv_qsv: align the surface size to 32 [13:13:27 CET] <cone-378> ffmpeg 03Clément BSsch 07master:e514309a916e: Merge commit '6f40181cad8ac04adff7bd10e1e1ab65f22bc1f0' [13:14:11 CET] <cone-378> ffmpeg 03Anton Khirnov 07master:8b7a9729aa16: avconv_qsv: use the actual pixel format provided by lavc [13:14:12 CET] <cone-378> ffmpeg 03Clément BSsch 07master:15f6e5f2a956: Merge commit '8b7a9729aa162e2bbd571933f1aa40767f1ff47b' [13:16:38 CET] <ubitux> hwaccel folks: any comment on f65285aba ? [13:18:38 CET] <ubitux> seems to apply cleanly [13:19:44 CET] <ubitux> after f65285aba0df7d46298abe0c945dfee05cbc6028, the doxy of sw_pix_fmt becomes invalid [13:19:54 CET] <ubitux> i'll leave this to someone else to fix it [13:23:20 CET] <BtbN> in what way does it become invalid? [13:23:27 CET] <BtbN> The check it adds seems reasonable to me. [13:23:43 CET] <nevcairiel> the doxy probably says its unused for encoding or something [13:23:49 CET] <cone-378> ffmpeg 03Anton Khirnov 07master:d59641abfd25: lavc: initialize AVCodecContext.sw_pix_fmt properly [13:23:50 CET] <cone-378> ffmpeg 03Anton Khirnov 07master:f65285aba0df: lavc: set sw_pix_fmt for hwaccel encoding [13:23:51 CET] <cone-378> ffmpeg 03Clément BSsch 07master:8d2d81709882: Merge commit 'd59641abfd25a1007bdf4723d952887b1e3619c6' [13:23:52 CET] <cone-378> ffmpeg 03Clément BSsch 07master:5e193daaa28d: Merge commit 'f65285aba0df7d46298abe0c945dfee05cbc6028' [13:24:33 CET] <ubitux> BtbN: what nevcairiel said [13:24:47 CET] <ubitux> btw, should we merge ac7bfd69678f3966e38debdb27f4bde94dc0345c now? [13:24:57 CET] <ubitux> i'm seeing a bunch of commit related to qsv [13:25:05 CET] <ubitux> i think we can merge it now, don't we? [13:26:07 CET] <nevcairiel> is that the scale filter? [13:26:13 CET] <nevcairiel> probably can [13:27:25 CET] <ubitux> i guess i'll have to test it a little [13:27:35 CET] <ubitux> or someone wants to take over the qsv-mostly-noop merge? [13:42:48 CET] <ubitux> ./ffmpeg -hwaccel qsv -c:v h264_qsv ... [13:42:51 CET] <ubitux> is this supposed to crash? [13:42:56 CET] <ubitux> Assertion avctx->codec_id != AV_CODEC_ID_NONE failed at src/libavcodec/parser.c:144 [13:43:08 CET] Action: ubitux still trying to figure out how to make qsv work [13:43:21 CET] <nevcairiel> thats what you are supposed to do =p [13:43:34 CET] <nevcairiel> but no, it should not trigger that assertion usually [13:43:46 CET] <ubitux> well, i'm trying to have it working before merging the stuff [13:43:54 CET] <ubitux> but it looks pretty sportive already [13:44:14 CET] <ubitux> -hwaccel qsv has no effect and -hwaccel qsv -c:v h264_qsv crashe [13:44:16 CET] <ubitux> +s [13:44:23 CET] <nevcairiel> havent tried to use it in ages, but jkqxz would hopefully know [14:18:08 CET] <jkqxz> ubitux: What is the problem? [14:26:59 CET] <jkqxz> -hwaccel qsv indeed does nothing on its own. [14:33:21 CET] <ubitux> jkqxz: shouldn't it warn or something? [14:34:07 CET] <ubitux> i had 3 problems: -qsv has no effect, hwaccel qsv -c:v h264_qsv asserts, and dropping the assert leads to "HWCTX Error initializing an MFX session" [14:34:17 CET] <ubitux> i'm not yet familiar with that stuff though [14:35:23 CET] <jkqxz> What platform? Has it ever worked on that machine? [14:40:18 CET] <jkqxz> <http://sprunge.us/GQSK> [14:40:51 CET] <jkqxz> The ffmpeg default of having lookahead enabled on the encoder messes with it somewhat, because it needs a huge output pool for that to work. Otherwise it's fine. [15:07:15 CET] <ubitux> jkqxz: i guess not compat, i7-4770R [15:07:44 CET] <ubitux> anyway, if i can't test, someone else should probably do the merges [15:12:02 CET] <jkqxz> The next seven (2196226..ad71d32), which are all qsv? [15:13:54 CET] <ubitux> + ac7bfd696 which was skipped [15:13:59 CET] <jkqxz> How do I do the two-part merge step? I've only ever cherry-picked from another branch before. [15:15:14 CET] <ubitux> you can check http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/libav-merge.txt;hb=HEAD#… [15:15:40 CET] <ubitux> it's basically running tools/libav-merge-next-commit merge or tools/libav-merge-next-commit noop [optionnal-hash-ref] [15:16:13 CET] <ubitux> (with a remote to libav repository) [15:23:28 CET] <jkqxz> How does the source commit get into the repo on push? Does git do something magical to make that happen? [15:25:46 CET] <BtbN> it just pushes it there [15:33:01 CET] <jkqxz> So there is some internal magic? There is only one commit in the ffmpeg tree, and I don't see how it is referencing the change. [15:34:33 CET] <jkqxz> push --dry-run does not look like it's going to do the right thing, since it only mentions the main tree. [15:40:32 CET] <BtbN> A merge commit has two parrents. [15:40:35 CET] <BtbN> That's the entire point of them [15:52:15 CET] <ubitux> jkqxz: push it in a private repo and we can check [15:56:38 CET] <jkqxz> <https://github.com/fhvwy/FFmpeg/commits/master> Looks like yes? [15:59:18 CET] <ubitux> jkqxz: yes it looks fine [16:00:49 CET] <cone-378> ffmpeg 03Anton Khirnov 07master:21962261c74a: qsv: handle the semi-packed formats in map_fourcc as well [16:00:50 CET] <cone-378> ffmpeg 03Mark Thompson 07master:210dd7bbb2c0: Merge commit '21962261c74aed4df00ae8348a5e2d1ecb67c52d' [16:03:51 CET] <cone-378> ffmpeg 03Anton Khirnov 07master:807a3b30d291: lavfi: add a QSV scaling filter [16:37:44 CET] <jkqxz> The deinterlacer doesn't work because of some difference in lavfi. It keeps calling ff_request_frame(), which succeeds but never gives it a frame. [16:57:24 CET] <wm4> jkqxz: is that the thing that requests 2 output frames at once? [16:57:28 CET] <jkqxz> Making the obvious change to return the lack of error kindof works, but it doesn't actually deinterlace anything. [16:58:09 CET] <jkqxz> Maybe? It sits in a loop asking for input frames until it gets some. [16:59:11 CET] <jkqxz> Also it doesn't seem to actually do anything when run with avconv. (Looks like the interleaved frames on input are just passed through unchanged?) [16:59:19 CET] <ubitux> btw, be careful: if you merge a bunch of commit but someone pushes something upstream, you're going to be in trouble to rebase [16:59:31 CET] <ubitux> are you already up to the deinterlace commit? [16:59:53 CET] <jkqxz> Yes. [17:00:06 CET] <jkqxz> Rebasing doesn't work somehow? [17:00:22 CET] <ubitux> yeah, with merges it's a pita [17:00:38 CET] <ubitux> you can trick with one, but multiples you're asking for troubles [17:02:58 CET] <ubitux> the request frame thing changed in FFmpeg [17:03:20 CET] <ubitux> see 02aa0701a i guess [17:03:41 CET] <cone-378> ffmpeg 03Anton Khirnov 07master:37a9015ee84c: qsvenc: add support for p010 [17:03:42 CET] <cone-378> ffmpeg 03Anton Khirnov 07master:d9ec3c60143b: qsvenc: take only the allocated dimensions from the frames context [17:03:43 CET] <cone-378> ffmpeg 03Anton Khirnov 07master:95414eb2dc63: qsv: print more complete error messages [17:03:44 CET] <cone-378> ffmpeg 03Anton Khirnov 07master:0956fd460681: qsvenc: do not re-execute encoding on all positive status codes [17:03:45 CET] <cone-378> ffmpeg 03Anton Khirnov 07master:8e07c22e508b: qsvenc: print warnings from encode/init [17:03:46 CET] <cone-378> ffmpeg 03Mark Thompson 07master:562f386c7715: Merge commit '37a9015ee84c15fec5247ba8f6577351a25fa8d2' [17:03:47 CET] <cone-378> ffmpeg 03Mark Thompson 07master:723a542d6c67: Merge commit 'd9ec3c60143babe1bb77c268e1d5547d15acd69b' [17:03:48 CET] <cone-378> ffmpeg 03Mark Thompson 07master:15887a410c5a: Merge commit '95414eb2dc63a6f934275b4ed33dedd4369f2c49' [17:03:49 CET] <cone-378> ffmpeg 03Mark Thompson 07master:80fa5a0bcc13: Merge commit '0956fd460681e8ccbdae19f135f0d3970bf95c2f' [17:03:50 CET] <cone-378> ffmpeg 03Mark Thompson 07master:a7434ef19585: Merge commit '8e07c22e508b349d145b9f142aa3ee8b3ce1d3a4' [17:04:15 CET] <wm4> wow merges [17:04:29 CET] <JEEB> I think those are still cherry-pick merges? [17:04:32 CET] <JEEB> or is that merging proper? [17:04:38 CET] <ubitux> no it's real merges [17:04:45 CET] <JEEB> ooh, coal [17:04:48 CET] <jkqxz> Those were made with the magic script. [17:05:05 CET] <ubitux> only 994 left [17:05:07 CET] <ubitux> @_@ [17:06:04 CET] <ubitux> jkqxz: does it work if you simply drop the request_frame? [17:07:01 CET] <ubitux> mmh i suppose it won't [17:07:13 CET] <jkqxz> Yeah, it gets past that problem if you just return the result. It doesn't do any deinterlacing, though (nor does avconv). [17:09:10 CET] <durandal_170> bunch of remaining are bitstream commits [17:10:09 CET] <ubitux> there are hundreds to deal with before bitstream [17:21:13 CET] <wm4> I was starting to work on some threading commits (those which keep threading enabled for hwaccels), but stopped having time [17:21:33 CET] <wm4> partially because I was fighting with michaelni for this side data merging shit [17:41:22 CET] <atomnuker> bofh_: ping [17:53:00 CET] <durandal_170> can i push my stuff? [17:58:42 CET] <jkqxz> durandal_170: Wait a few minutes, please. [18:04:07 CET] <bofh_> atomnuker: pong, sec let me first grab the latest code from master since it seems you added a separate mdct15 from the imdct15? [18:04:45 CET] <cone-378> ffmpeg 03Anton Khirnov 07master:ad71d3276fef: lavfi: add a QSV deinterlacing filter [18:04:46 CET] <cone-378> ffmpeg 03Mark Thompson 07master:b9acc7fbd9fe: Merge commit 'ad71d3276fef0ee7e791e62bbfe9c4e540047417' [18:04:53 CET] <jkqxz> durandal_170: Go ahead. [18:05:27 CET] <nevcairiel> there is some "tricks" to manually rebase, i still wonder why git doesnt just rebase the merge commit like any other, but i'm sure there is some weird reason for that [18:05:36 CET] <jkqxz> ubitux: That's all of this set of qsv stuff. [18:28:27 CET] <cone-378> ffmpeg 03Paras Chadha 07master:5dab7b91adf6: avcodec: add XPM decoder and demuxer [18:28:28 CET] <cone-378> ffmpeg 03Paul B Mahol 07master:eda78c8b7f8a: avcodec/xpmdec: make convert function more picky about its input [18:28:29 CET] <cone-378> ffmpeg 03Paul B Mahol 07master:404d2b977fde: avcodec/codec_desc: add mime type for X-PixMap [18:28:30 CET] <cone-378> ffmpeg 03Paul B Mahol 07master:01b069c1b81f: avcodec/codec_desc: add mime type for X-BitMap [18:28:31 CET] <cone-378> ffmpeg 03Paul B Mahol 07master:e73325b971b3: avcodec/xpmdec: skip everything before signature [18:29:38 CET] <cone-378> ffmpeg 03James Almer 07master:88deeb3eba00: tests/api-seek: make the crc array uint32_t [18:29:39 CET] <cone-378> ffmpeg 03James Almer 07master:bdd07d7796e9: test/api-seek: clean up properly on failure [18:29:41 CET] <cone-378> ffmpeg 03James Almer 07master:ff17c76e92cd: tests/api-seek: fix memory leak on realloc() failure [18:38:57 CET] <durandal_170> i had a dream with swscale having modular pix fmts support where each pix fmt can be disabled/enabled [18:39:09 CET] <nevcairiel> was it a nightmare [18:39:37 CET] <DHE> dream? that's the thing where you experience hallucinations at night and then suffer amnesia about them in the morning? [19:04:39 CET] <durandal_170> no seriously, why not? [19:05:35 CET] <durandal_170> ubitux: i fixed silly cube bug in lut3d \Ë/ [19:14:39 CET] <cone-378> ffmpeg 03Jun Zhao 07master:bf238a6a3ca9: vf_hwupload: Add missing return value check [19:25:07 CET] <BBB> durandal_170: I think itd be cool, but I dont think well ever quite get there :-p [19:43:42 CET] <adeel1> durandal_170: I have made the skip_chars_comment more compact and removed a parse_video method, not sure if there's any other useless code in there: https://gist.github.com/adl1995/ff687e9748d5b3b5aad04536f766e89f [19:47:44 CET] <durandal_170> adeel1: still calling coded_frame, not checking allocation failure, also another student already completed qualification task [20:00:26 CET] <adeel1> durandal_170: removed coded frame usage, added checks: https://gist.github.com/adl1995/ff687e9748d5b3b5aad04536f766e89f [20:00:46 CET] <adeel1> what does it mean if 2 students complete same qualification task? [20:02:25 CET] <durandal_170> adeel1: you havent passed, also i helped you too much, even for pointer usage [20:06:13 CET] <adeel1> durandal_170: In the beginning, yes. But, I did follow through along the way. Could you please assign be a different task? This time I will solve it without any external guidance. [20:07:01 CET] <durandal_170> adeel1: i dont get it, FITS is already taken [20:07:31 CET] <ubitux> durandal_170: it's curious i haven't spot that one, pretty sure i tested the DOMAIN thing [20:07:40 CET] <ubitux> tell the guy to drop those lines as a workaround [20:07:50 CET] <ubitux> (i suppose that's fixing the ffmpeg-user issue) [20:17:45 CET] <adeel1> durandal_170: It was mentioned on the page "each student should work on a different qualification task", isn't it un-fair that you gave us both the same task? Also, don't you think I have the motivation and the will to improve? I have been contiously coming here for almost past 2 weeks. [20:27:05 CET] <durandal_170> adeel1: dwa/dwb in exr is even harder task [20:27:35 CET] <durandal_170> so i didnt want to give it to unexperienced students [20:29:28 CET] <durandal_170> there is minterpolate and dicom task [20:35:09 CET] <adeel1> durandal_170: okay, I can choose either? [20:35:57 CET] <durandal_170> adeel1: they have different mentors, so ask them for more info [20:36:28 CET] <adeel1> alright [20:45:38 CET] <adeel1> michaelni: I want to work on Minterpolate improvement's qualification task. I have briefly gone through vf_minterpolate.c Is there any specific method to which I should add improvements? [20:46:32 CET] <durandal_170> adeel1: first you need to know what you are doing [20:47:04 CET] <durandal_170> do you know how to use filters via ffmpeg? [20:47:58 CET] <adeel1> durandal_170: Through the CLI commads? yes, I tried some examples. [20:53:07 CET] <durandal_170> adeel1: basically you need to find way to reduce number of artifacts in minterpolate filter when it produces extra frames [21:07:38 CET] <cone-378> ffmpeg 03Muhammad Faiz 07master:6c7a0876fefd: swresample/swresample: do not reset tsf on swr_alloc_set_opts [21:19:39 CET] <michaelni> adeel1, its up to you what you improve and how [21:27:08 CET] <bofh_> atomnuker: posting code to the mailing list in a sec. [21:48:39 CET] <jamrial> michaelni: give others the chance to comment on the spherical patch before pushing since afaik there were some in favor of instead dropping sizeof(sidedata) from ffprobe's output [21:49:06 CET] <nevcairiel> there is no reason we cant do both [21:51:46 CET] <jamrial> true [23:09:05 CET] <cone-378> ffmpeg 03Paul B Mahol 07master:7133ab435abb: avcodec/xpmdec: improve comment for one function and also fix 2 identation issues [23:09:06 CET] <cone-378> ffmpeg 03Paul B Mahol 07master:9d7e71a233e3: avcodec/xpmdec: rename convert to hex_char_to_number [23:09:07 CET] <cone-378> ffmpeg 03Paul B Mahol 07master:fbc1f323dbda: avcodec/xpmdec: rename yet another function [23:09:08 CET] <cone-378> ffmpeg 03Paul B Mahol 07master:2b790b1c9e3b: avcodec/xpmdec: do not allow number of colors to be higher than allocated [23:09:09 CET] <cone-378> ffmpeg 03Paul B Mahol 07master:dd0090eb2112: avcodec/xpmdec: fix colors values which are different for X11 [23:09:10 CET] <cone-378> ffmpeg 03Paul B Mahol 07master:58f0bbc1eafb: avcodec/xpmdec: avoid "magic" numbers in function hex_char_to_number() [00:00:00 CET] --- Mon Mar 13 2017

1 0

ffmpeg.log.20170312
by burek 13 Mar '17

13 Mar '17

[00:15:56 CET] <Rickky> I'm trying to simply forward an incoming RTMP stream to another RTMP endpoint, but keep running into [NULL @ 0x3da41a0] Unable to find a suitable output format for 'rtmp://xxx.com' rtmp://xxxx.com: Invalid argument [00:16:35 CET] <Rickky> I tried to force certain format types but think I am messing in the wrong order [00:17:18 CET] <aguardar> what's your command [00:17:23 CET] <Rickky> See http://pastebin.com/raw/v9xpZnCZ [00:21:25 CET] <JEEB> -f flv after the input [00:21:36 CET] <JEEB> although it should have guessed by the protocol... I think? [00:21:45 CET] <Rickky> Input is HLS [00:22:07 CET] <Rickky> Input stream actualluy seems to be recognized properly [00:22:11 CET] <JEEB> yes [00:22:16 CET] <JEEB> because that gets probed [00:22:16 CET] <Rickky> e.g. reads metadata correctly [00:22:34 CET] <JEEB> it's just that it can't guess the *output* format from the "file name" [00:22:50 CET] <JEEB> so you have to tell it that the output (thus, after -i INPUT) is flv [00:23:06 CET] <JEEB> also if the input is RTMP like you said before it cannot be HLS, it's FLV [00:23:14 CET] <Rickky> Ah [00:23:15 CET] <JEEB> because RTMP is an FLV-only protocol [00:25:05 CET] <Rickky> yeah [00:26:26 CET] <Rickky> JEEB: yep that's it! [00:26:35 CET] <Rickky> quality not that good, but let's tweak that [00:26:44 CET] <JEEB> first of all kill minrate [00:27:01 CET] <JEEB> that's a libavcodec option (somehow?) implemented in there [00:27:11 CET] <JEEB> in other words it's not something within libx264 itself [00:27:21 CET] <JEEB> which is a separate library, and which is well tested [00:28:08 CET] <JEEB> also you're not specifying bufsize [00:28:27 CET] <JEEB> which is not required but you most likely want to set it in addition to maxrate, since I have no idea what the default is [00:28:42 CET] <the_k_> can anyone help me get something that's working into something better?! [00:28:52 CET] <JEEB> VBV/HRD in libx264 works with both maxrate and bufsize - in other words maxrate over bufsize [00:29:14 CET] <JEEB> the_k_: are metaquestions so darn hip nowadays? [00:29:14 CET] <the_k_> i have a camera feed being recorded to disk with motion detection enabled that only writes frames that have changes in them [00:29:18 CET] <the_k_> ffmpeg -i rtsp://fd:554/Streaming/Channels/2 -vf "select=gt(scene\,0.005),setpts=N/(25*TB)" fd_motion.mp4 [00:29:24 CET] <the_k_> yep [00:29:38 CET] <the_k_> gotta feed the crowd maan [00:30:31 CET] <the_k_> i have that and it works fine, but i'd like to have it so that it writes to a dated filename [00:31:21 CET] <the_k_> on my other recording feed, i have it so it demuxes it so i can play the file that's being written in near realtime (2-5s delay at the end of the file) and the fiodated [00:31:23 CET] <the_k_> loops [00:31:25 CET] <the_k_> oops*** [00:31:32 CET] <the_k_> ..and the file is dated correctly [00:31:53 CET] <the_k_> and the command for that is: [00:32:07 CET] <the_k_> ffmpeg -i rtsp://fd:554/Streaming/Channels/1 -c copy -f segment -segment_time 21600 -strftime 1 fd_HD_%%Y-%%m-%%d-%%H;%%M;%%S.ts [00:32:40 CET] <the_k_> my problem is just that when i try to add the -f segment .. etc part to the previous command it doesn't like it [00:33:39 CET] <Rickky> JEEB: -bufsize is set to $CBR right, which is 3000k [00:34:09 CET] <JEEB> oh, I missed it on the third line [00:34:21 CET] <the_k_> "filtering and streamcopy can not be used together" [00:34:39 CET] <JEEB> basically set it to the amount of buffer the client would have to do to 100% not have to buffer again [00:34:51 CET] <JEEB> the bigger the buffer the more fluctuation you can have [00:35:01 CET] <JEEB> within that buffer [00:35:37 CET] <JEEB> (in other words in a simplistic way of saying it, maxrate is the overall average bit rate over bufsize at all points of the clip) [00:39:17 CET] <the_k_> ok nevermind i got it working, i thought i had tried taking "-c copy" out [00:42:37 CET] <ZeroWalker> how do you initialize an audio codec context? (libopus). cause basically all the parameters are for video:s [00:49:30 CET] <Rickky> JEEB: Pretty sure this is why minrate got into it: " To force CBR video output: xxx -minrate 4000 -maxrate 4000" http://ffmpeg.org/ffmpeg.html#Video-and-Audio-file-format-conversion one but last example [00:50:11 CET] <JEEB> yea, that's for some other encoders [00:52:14 CET] <Rickky> JEEB: So just drop minrate? [00:52:18 CET] <JEEB> yes [00:53:42 CET] <Rickky> Got a pretty stable stream now, tweaked around a bit. Apparently I missed implementing $FPS. Now set that using -r [01:03:29 CET] <Rickky> That's great... After enabling reload=1 on drawtext, speed drops from 1.2x to 0.08x... [01:11:04 CET] <Rickky> How could I improve performance/speed with drawtext enabled? I turned down both framerate as 264 quality beyond acceptable already, and I still consistently see okay-ish framerate first couple of seconds, quickly see it drop to 0.5-0.8 speed now tops [01:11:23 CET] <Rickky> What is it bound? bitrate? [01:11:34 CET] <Rickky> FPS obviously but putting it below 15 is pretty ridiculous [01:45:02 CET] <Rickky> Trying to figure out what the bottleneck is. Doubled the VM in CPU, still same result once enabling drawtext [02:05:04 CET] <Rickky> I really don't understand why my speed drops to 0.3x while I see 8 CPUs at 100% idle... Threads = 6 but don't see that actually happening [02:31:09 CET] <DHE> ffmpeg isn't 100% multithreaded. there's a single thread taking input, submitting it to the filters, and submitting it to the outputs [02:31:28 CET] <DHE> some decoders are multi-threaded, some filters are multi-threaded, and some encoders are multi-threaded. but that doesn't mean 100% usage all the time [04:22:54 CET] <hiihiii> what's the correct way to encode an RGB mp4 [04:23:49 CET] <hiihiii> -c:v libx264rgb -pix_fmt bgr24? [04:24:42 CET] <hiihiii> -c:v libx264 -pix_fmt bgr24? [04:24:55 CET] <hiihiii> -c:v libx264rgb -pix_fmt rbg24? [04:25:41 CET] <hiihiii> 1st worked. 3rd did not [04:26:20 CET] <hiihiii> *sorry I meant : 1st worked. 2nd did not [04:36:05 CET] <relaxed> hiihiii: ffmpeg -h encoder=libx264rgb | less [15:05:33 CET] <ldiamond> is it supposed to take a long time to cut a small part of a video starting ~10mins in? ffmpeg seems to be working hard (80% cpu usage) but no frame is being encoded. [15:05:40 CET] <ldiamond> This is my command: ffmpeg -i P3101158.MOV -ss 00:10:53 -t 00:00:18 -r 60000/1001 -async 1 cut1.mp4 [15:06:07 CET] <ldiamond> seems like its working hard to reach 10:53, idk if there's a more efficient command I could use [15:06:56 CET] <BtbN> put -ss before the -i [15:07:48 CET] <ldiamond> yea much better. [15:08:23 CET] <ldiamond> so putting the -i before makes ffmpeg convert the whole file then seek and get the part I want? [15:24:11 CET] <jarkko> i had this line in my winff -c:a aac -strict experimental -b:a 128k -b:v 3000k -filter:v yadif -b:a 128k -r:a 44.1 -ac 2...i dont know why its so complicated, it has been much simpler before. but it doesnt produce the result i want [15:24:24 CET] <jarkko> i want 2 channel 44.1 128 audio [15:30:38 CET] <BtbN> you don't need the experimental flag for aac anymore. [15:30:44 CET] <BtbN> And I'm pretty sure it's -ar [15:30:48 CET] <BtbN> and it takes it in Hz, not kHz [15:31:41 CET] <jarkko> so its "-ar 44100" ? [15:32:34 CET] <JEEB> note: AAC-in-FLV doesn't require specific audio rates [15:33:07 CET] <jarkko> JEEB: FLV? [15:33:23 CET] <JEEB> well I guess that if you're writing -ar 44100 you most likely are pushing out FLV :P [15:33:34 CET] <JEEB> (either into a file or to an rtmp(e) server [15:36:10 CET] <jarkko> is it possible to use crf=28 rate control and kilobytes same time? for video? [15:36:52 CET] <BtbN> you can't have a constant quality at a constant bitrate, with what magic would that work? [15:37:02 CET] <JEEB> CRF/ABR as main rate controls can't be mixed, but you can set a bufsize and a maxrate over the bufsize [15:37:12 CET] <JEEB> so you can have CRF but limitede by VBV/HRD [15:37:31 CET] <jarkko> what's the meaning of bufsize? i can understand maxrate [15:37:49 CET] <furq> bufsize is the amount of data over which maxrate is measured [15:37:54 CET] <JEEB> ^this [15:38:20 CET] <jarkko> makes sense but how do you "measure" what's good value [15:38:22 CET] <JEEB> that way the client has to buffer bufsize amount of data and to have a connection at the very least of maxrate, and it will *always* be able play that stream afterwards [15:38:46 CET] <JEEB> jarkko: the bigger the better. you just have to decide the amount of buffering the client should do [15:38:53 CET] <JEEB> then you match the encoder and playback [15:38:54 CET] <furq> -maxrate 1500k -bufsize 1000k means the bitrate will never exceed 1500kbps in any given 1000kB of data (note kB, not kbit) [15:39:10 CET] <JEEB> really? [15:39:14 CET] <furq> yeah [15:39:21 CET] <JEEB> I thought both were in kilobits [15:39:26 CET] <JEEB> that'd be really surprising if not :D [15:40:07 CET] <furq> http://vpaste.net/hz1Go [15:40:15 CET] <furq> maybe ffmpeg maps it differently though [15:40:25 CET] <furq> oh wait that says kbit [15:40:28 CET] <furq> the fuck am i thinking of then [15:40:51 CET] <JEEB> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libx264.c#L500 [15:41:04 CET] <JEEB> yea, they get handled exactly the same way, too [15:41:15 CET] <kepstin> the ffmpeg command uses bits, yeah. so there is a conversion - bit kbit :) [15:41:15 CET] <furq> oh i'm thinking of slice-max-size [15:41:19 CET] <furq> ignore me, i'm dumb [15:41:46 CET] <furq> that one actually makes sense for it to be in bytes [15:43:57 CET] <kepstin> jarkko: it often makes sense to think of bufsize as time not size - so maxrate 1500k bufsize 1000k means that if you have a 1500k internet connection, you'll need about 1.5s of buffer to handle bitrate fluctuations. [15:44:46 CET] <kepstin> er, i got that backwards [15:44:58 CET] <kepstin> bufsize / maxrate = time [15:45:06 CET] <kepstin> iirc? [15:45:13 CET] <kepstin> ah, i'm still half asleep. [15:45:49 CET] <furq> thank you for this show of solidarity [15:46:23 CET] <jarkko> kepstin: i am not encoding for streaming...i am still figuring out the options [15:46:54 CET] <kepstin> if you're not encoding for streaming or for a media with limited speed (dvd/bd), then don't use bufsize/maxrate at all. [15:46:59 CET] <furq> if it's not for streaming then just don't cap the bitrate [15:47:07 CET] <furq> let crf do its thing [15:47:17 CET] <JEEB> you just need to find the highest CRF value that still looks good for you [15:47:18 CET] <jarkko> but i want to have minimum bitrate, anyway to set that? [15:47:28 CET] <JEEB> encode ~2500 frames or so with different values [15:47:31 CET] <furq> there's absolutely no point doing that [15:47:48 CET] <JEEB> just use a CRF you know is good enough for you and then you get the quality you want [15:47:50 CET] <JEEB> that's all that matters [15:47:52 CET] <JEEB> in the end [15:47:52 CET] <JEEB> :P [15:47:54 CET] <furq> setting a minimum bitrate will just waste bits with no quality gain [15:48:03 CET] <furq> or it would if you could do it, which iirc you can't with crf [15:48:36 CET] <JEEB> getting too low bit rate usually manifests with bad quality, and in that case you just go and lower your CRF value [15:48:46 CET] <JEEB> because then you've picked the wrong CRF value [15:49:03 CET] <JEEB> start with 23 and go up if it looks good, down if it looks bad. [15:49:20 CET] <furq> i use the same crf for more or less everything and it's fine [15:49:30 CET] <furq> 20 for <720p, 21 for >=720p [15:49:53 CET] <JEEB> I'd also limit that to similar types of content and of course to the usual presets you use [15:50:03 CET] <furq> i only change that for really pathological cases like old fps footage [15:50:03 CET] <JEEB> but yes, after you get the ranges you want it gets pretty automagic [15:50:09 CET] <furq> and i've not fucked with that in years [15:50:15 CET] <jarkko> i installed winff and it seems to make things more complicated than really helping [15:50:21 CET] <furq> although yeah i should have pointed out that i use the same preset as well [15:50:47 CET] <furq> and yeah ffmpeg guis are universally shit [15:51:12 CET] <furq> they're either more complicated than ffmpeg or they're missing one option you want [15:51:14 CET] <jarkko> the thing is that i want to downgrade audio from 48000 to 44.1 and 2 channels. also i want subtitles to be copied over to the mkv file even i wouldnt use it [15:51:16 CET] <furq> or both, usually [15:51:33 CET] <BtbN> why do you want to resample? [15:51:35 CET] <furq> it's easier to just learn ffmpeg [15:51:41 CET] <furq> at least that knowledge is useful [15:51:57 CET] <jarkko> not really fmpeg own website is refering often to x264 and then saying that this doesnt work on x265 [15:52:10 CET] <furq> huh [15:52:12 CET] <JEEB> it's two different encoders, so d'uh [15:52:22 CET] <jarkko> see yourself how x265 quide is made [15:52:25 CET] <furq> if you mean the wiki then that's often wrong [15:52:38 CET] <furq> it's usually best to ignore that [15:52:48 CET] <JEEB> well the libx265 wrapper is rather minimal :P [15:52:55 CET] <JEEB> it's more geared towards "use x265-params" [15:53:12 CET] <JEEB> it will take some basic things from CRF,preset etc, but anything more requiring would end up with x265-params [15:53:40 CET] <JEEB> including maxrate/bufsize/level/profile I think? [15:54:07 CET] <JEEB> so yes, different encoders within FFmpeg require different parameters. who wudda known?! [15:54:27 CET] <jarkko> what preset you usually use? [15:54:34 CET] <furq> slower or veryslow [15:54:48 CET] <JEEB> what preset I use shouldn't matter for you [15:54:57 CET] <JEEB> because I have my needs, you have yours [15:55:00 CET] <jarkko> well do you think thats helpful [15:55:10 CET] <JEEB> as I said, encode like 2500 frames with different presets [15:55:13 CET] <furq> ^ [15:55:13 CET] <JEEB> compare the speed [15:55:23 CET] <JEEB> then pick the slowest that is still fast enough for you [15:55:28 CET] <furq> it depends how patient you are and how much quality you care about [15:55:43 CET] <furq> and how good your cpu is [15:55:47 CET] <JEEB> and if you say you don't care about the speed then just go fsck yourself with preset placebo and come back crying you want it faster [15:55:53 CET] <jarkko> but do you see any difference between the presets with human eye if the presets are close to each other [15:56:05 CET] <furq> it depends on the content [15:56:09 CET] <JEEB> I do see differences between them when compression is actually required [15:56:21 CET] <furq> some content you'll see a big difference between slower and veryslow [15:56:25 CET] <furq> most of the time you won't [15:56:28 CET] <JEEB> CRF just makes it really easy to make files which look good, whatever the preset [15:56:47 CET] <JEEB> so thus it comes down to your speed preference and how much you care about file size [15:56:51 CET] <furq> you're probably overthinking it really [15:56:56 CET] <furq> the x264 defaults are already pretty good [15:57:09 CET] <jarkko> have they always been? [15:57:28 CET] <JEEB> for the last... six? years, yes [15:57:28 CET] <furq> they have been for a long time [15:57:37 CET] <JEEB> I don't even remember when the preset system was made [15:58:12 CET] <kepstin> unfortunately, you still sometimes see cargo cult x264 options hanging around on forums and wikis and stuff from before the preset system was added :/ [15:58:32 CET] <furq> wait are you saying that forum posts might have incorrect ffmpeg information [15:58:34 CET] <furq> now this i gotta see [16:06:40 CET] <jarkko> well i am getting somwehere...but [16:06:43 CET] <jarkko> -c:a aac -b:a 128k -ar:44100 -ac2 [16:06:50 CET] <jarkko> is that constant bitrate or variable? [16:07:08 CET] <JEEB> depends on the encoder but for audio you usually get CBR [16:07:23 CET] <jarkko> aac.. [16:07:44 CET] <jarkko> if you have 5.1 sounds. does it sound any good with 128 bitrate? [16:07:50 CET] <jarkko> i have no idea [16:08:07 CET] <JEEB> fuck if I fucking know. in most fucking cases the audio is so small it makes no fucking sense to re-encode it even if it's raw PCM [16:08:27 CET] <JEEB> so feel free to think once again why the flying fuck you're raping the audio [16:10:02 CET] <jarkko> well audio is consuming most likely more bits than video then [16:10:15 CET] <jarkko> go fuck yourself [16:11:26 CET] <furq> what a nice young man [16:11:44 CET] <JEEB> such cases just get tiring as hell [16:11:55 CET] <furq> i thought the finns were more robust than that [16:12:08 CET] <JEEB> we're different :P [17:14:12 CET] <acresearch> hello people, i have a 23GB 4k mkv video that is not playing on a samsung TV, how can i convert it so it can play on a samsung tv while maintaining the high def? [17:14:35 CET] <JEEB> first of all find out what your thing supports [17:15:16 CET] <acresearch> JEEB: well my TV support mkv, but for some reason it is not playing this one, i read somewhere that the mkv header is different, i do not understand what that means or how to change it [17:15:33 CET] <JEEB> oh [17:15:43 CET] <JEEB> but I mean, video and audio formats within the container [17:16:09 CET] <JEEB> anyways, the first thing I'd do is do `ffmpeg -i input.mkv -c copy -sn -movflags faststart out.mp4` [17:16:13 CET] <JEEB> and put the video into mp4 [17:16:24 CET] <JEEB> (that grabs the primary video and audio track) [17:16:30 CET] <JEEB> then try that first [17:16:43 CET] <acresearch> JEEB: would i lose quality? [17:16:44 CET] <JEEB> given that your TV supports whatever was inside that matroska file [17:16:46 CET] <JEEB> no [17:16:51 CET] <JEEB> that's just bit stream copying [17:16:56 CET] <acresearch> ok, i will try that, :-) thanks JEEB [17:17:05 CET] <JEEB> take the streams out of matroska, then push them into mp4 [17:18:18 CET] <acresearch> ok [18:25:53 CET] <ren0v0> Hi, i'm trying to simply split a file using ffmpeg, but the first 4-5 seconds are frozen > ffmpeg -i input.avi -vcodec copy -acodec copy -copyinkf -ss 00:09:17 -t 00:10:00 output.avi [18:25:54 CET] <ren0v0> any ideas? [18:26:14 CET] <ren0v0> i think it's related to key frames somehow, but need a solution [18:29:50 CET] <BtbN> "first few frames are frozen"? [18:40:51 CET] <ren0v0> yea [18:41:06 CET] <ren0v0> no movement on the video for like 2-5 seconds [18:43:41 CET] <ren0v0> also, a separate question. If i'm generating a video (h.264 codec), from JPEGs, at 15fps 1080p res, what bitrate should i use for best quality? [18:55:05 CET] <BtbN> for litterally best quality you want to use lossless mode [18:57:38 CET] <DHE> start with -crf 18 and see how it goes. lower the number for better quality, raise it for a smaller file size [19:01:26 CET] <ren0v0> DHE, i'm using this currently, where would -crf fit in? [19:01:28 CET] <ren0v0> -r 15 -codec:v libx264 -profile:v high -preset slow -threads 0 -b 4000k -minrate 800k -maxrate 6000k [19:02:11 CET] <ren0v0> the stream where the JPEGs are generated from is set i believe to 8192 bitrate, not sure if that makes any difference [19:09:34 CET] <furq> -profile high, -threads 0 and -minrate are all doing nothing in that command [19:09:51 CET] <furq> replace -b 4000k with -crf 18 [19:10:29 CET] <furq> also probably get rid of -r 15 [19:10:58 CET] <furq> if you have -framerate set on the input then -r is redundant as well [19:12:17 CET] <ren0v0> i see, is -crf in the docs? [19:12:34 CET] <ren0v0> will be interesting to see how this effects filesize [19:12:39 CET] <furq> -h encoder=libx264 [19:13:54 CET] <ren0v0> -h encoder=libx264 -codec:v libx264 -preset slow -crf 18 < so this ? [19:14:27 CET] <furq> uh [19:14:28 CET] <furq> no [19:14:37 CET] <furq> you asked if crf was in the docs [19:14:47 CET] <furq> -h is help [19:16:31 CET] <ren0v0> doh [19:16:38 CET] <ren0v0> what is FLT_MAX denoted by? [19:22:30 CET] <furq> http://vpaste.net/yGbA7 [19:23:52 CET] <ren0v0> err [19:24:40 CET] <ren0v0> so 18 is well within limits then :D [19:24:58 CET] <ren0v0> so where are you picking 18 from, experience? [19:25:34 CET] <furq> something like that [19:25:55 CET] <furq> anything below 18 is overkill [19:26:18 CET] <furq> i've never used anything below 20 [19:26:43 CET] <furq> obviously that doesn't stop some people from using 14 and then releasing their stupidity to the internet [20:15:03 CET] <rexxster> I had a gstreamer->gstreamer stream setup, but due to distro upgrades my client gstreamer doesn't work anymore. My distro includes MPV with a working vdpau implementation. [20:15:05 CET] <rexxster> So, what I need from the experts here is a replacement mpv(ffmpeg pipeline) invocation for the client. http://pastebin.com/QAnXWLL3 I had no help in #mpv and was refered here by someone. [20:51:22 CET] <acresearch> JEEB: are you still here? [20:51:27 CET] <JEEB> never [20:51:57 CET] <acresearch> haha, i tried your command (ffmpeg -i input.mkv -c copy -sn -movflags faststart out.mp4) but still the TV says not supported codec [20:52:32 CET] <JEEB> then most likely the video format is not something that your TV supports, or it utilizes features not supported by the ASIC decoder in your TV [20:53:14 CET] <acresearch> this is very complicated, and i don't know how to prevent it [20:53:39 CET] <acresearch> the problem with TV is that i cannot just install a program for every codec out there [20:54:09 CET] <JEEB> and due to it being low on computational strength (as it uses a HW ASIC decoder for most formats) you wouldn't even get too much help from sw decoders :P [20:54:33 CET] <JEEB> now find out what profiles and levels of different video/audio formats it supports [20:54:46 CET] <acresearch> JEEB: i am sorry, i do not understand what that means, i am not very professional in video codecs [20:55:12 CET] <acresearch> let me see what the samsung tv likes to support [20:55:26 CET] <JEEB> if it's samsung there is a list somewhere (most likely :P) on the profiles and levels of video,audio formats it supports [20:55:36 CET] <JEEB> like H.264 up to high profile, level 4.1 or so [20:56:25 CET] <acresearch> i found this, but i am not sure if it is my tv or not, http://www.samsung.com/uk/support/skp/faq/884733 [20:56:44 CET] <acresearch> i am not sure what my tv sub brand is, there are many samsung tvs [20:56:44 CET] <JEEB> that's the containers [20:57:38 CET] <acresearch> JEEB: this is better? http://samsung-galaxy-video-converter.blogspot.com/2016/01/best-video-forma… [20:57:55 CET] <JEEB> no [20:58:01 CET] <JEEB> usually it's in your manual [20:58:09 CET] <JEEB> samsung should offer you the manual as PDF [20:58:57 CET] <acresearch> the problem there are many different sumsung tv types, i am not sure which one is mine, (its not as easy as just searching iphone 7) [20:59:21 CET] <JEEB> yes, I know. but for example in my case I could search for KS8005 for example :P [20:59:58 CET] <JEEB> and yes, samsung also likes to use slightly different model numbers between continents just to make it that much easier to compare reviews [21:00:42 CET] <JEEB> also you could post the output of `ffprobe file.mkv` in a pastebin or so [21:00:48 CET] <JEEB> and link it here [21:02:10 CET] <acresearch> JEEB: http://paste.ubuntu.com/24166543/ [21:02:42 CET] <acresearch> isn't there just a universal codec? [21:03:10 CET] <JEEB> who the fuck encoded that thing... [21:03:34 CET] <JEEB> yuvj420p(pc, bt709) <- I'm pretty sure no broadcast or media source uses full range [21:03:45 CET] <JEEB> (the *j* in there) [21:03:46 CET] <acresearch> i don't understand [21:04:01 CET] <JEEB> also I would deeply recommend you update your FFmpeg, 2.8.x is *old* [21:04:30 CET] <JEEB> if you are just using the command line tools probably the simplest way for you would be to grab one of those static binaries linked around here every now and then [21:04:44 CET] <JEEB> that way you can extract it and just run it by executing the full path [21:05:02 CET] <JEEB> https://johnvansickle.com/ffmpeg/ seems to be it [21:05:07 CET] <JEEB> but do note, I have never used these [21:05:19 CET] <JEEB> since they get so often linked there they probably are OK, but just sayin' [21:05:25 CET] <JEEB> s/there/here/ [21:06:44 CET] <acresearch> JEEB: i am sorry, i am completely lost, i have no idea what you are talking about, i am not a video professional, i just want to watch a movie in 4K HD [21:07:22 CET] <JEEB> I'm just trying to take you one step a time towards a better experience :P [21:07:26 CET] <JEEB> also how old is your TV :P [21:07:35 CET] <acresearch> i bought it in 2014 [21:07:48 CET] <JEEB> ok, so forget about watching that video in any way or form as-is [21:07:57 CET] <JEEB> HEVC stuff was added in 2015, I think? [21:08:17 CET] <JEEB> also not sure if it will support 2160p too easily [21:08:27 CET] <acresearch> hmmm [21:08:49 CET] <JEEB> unless something specifically says it does, in which case you'll have good fun transcoding that to an older format [21:09:33 CET] <JEEB> and that will take time as well as not be lossless (although not necessarily visible) [21:10:48 CET] <acresearch> i am trying to find the serial number to identify it, but there is nothing [21:11:04 CET] <acresearch> webites say it should be on the right, but there is nothing,,, so annoying!!! [21:14:25 CET] <acresearch> JEEB: ok i found the model code: ua55f6400 [21:15:04 CET] <acresearch> JEEB: but this is the only page i get: http://www.samsung.com/uk/support/skp/faq/884733 [21:15:16 CET] <JEEB> not this? http://www.samsung.com/sa_en/consumer/tv-av/tv/full-hd/UA55F6400ARXUM/ :P [21:15:23 CET] <JEEB> although this is for saudi arabia but seems similar enough [21:16:24 CET] <acresearch> maybe it is, yes i am in saudi arabia [21:16:42 CET] <feliwir> Hey, i don't quite understand how AVFrame->data works. Is it an array of buffers? [21:16:44 CET] <acresearch> it looks like all their TV, i do have a 55" [21:16:49 CET] <feliwir> If so, where do they get allocated [21:17:13 CET] <feliwir> because i can't find that for vp6 codec (the line where anything gets allocated) [21:17:13 CET] <JEEB> feliwir: yes. as the https://ffmpeg.org/doxygen/trunk/structAVFrame.html says [21:17:28 CET] <feliwir> JEEB, so where do the planes get allocated? [21:17:28 CET] <JEEB> you should only care if you are creating the AVFrame yourself manually [21:17:37 CET] <JEEB> decoder should be creating them for you [21:17:55 CET] <JEEB> if you are creating them by yourself then you will have to utilize av_malloc etc [21:18:05 CET] <feliwir> JEEB, i am trying to understand the vp6 decoder and that makes use of those buffers. But in the decoder itself those planes don't get allocated [21:22:06 CET] <acresearch> JEEB: ok upgraded ffmpeg [21:25:21 CET] <kubast2> If LAME - Lame Ain't an MP3 Encoder Ain't an MP3 Encoder ,how come LAME is an MP3 Encoder [21:25:44 CET] <acresearch> JEEB: ok then what is the highest HD i can work with? [21:25:51 CET] <JEEB> feliwir: https://ffmpeg.org/doxygen/trunk/group__lavu__frame.html#ga6b1acbfa82c79bf7… [21:26:15 CET] <JEEB> this thing gets called based on some variables, as well as some decoders need to update the size [21:34:08 CET] <feliwir> hm, never saw a call to that from vp6 decoder [21:34:52 CET] <JEEB> yes, there are wrappers around it and formats that don't need to change width/height/pixel format on the fly wouldn't be needing it [21:35:11 CET] <feliwir> just loads of av_frame_ref and av_frame_unref [21:35:27 CET] <JEEB> generally at the point where avcodeccontext is initialized the framework knows various information on the data that's going to be pushed into the AVFrame [21:35:30 CET] <feliwir> well but somewhere the memory still needs to be allocated [21:35:43 CET] <JEEB> yes, after init and before decode() I would guess [21:36:09 CET] <JEEB> and formats which would have to support different sizes and pixel formats on the fly most likely call a function that re-calls that one :P [21:36:23 CET] <JEEB> (I would guess mostly H.264 supports that) [21:36:48 CET] <JEEB> so in case of VP6 I would guess it just gets created and you don't need to be overriding it [21:37:34 CET] <acresearch> JEEB: ? [21:38:28 CET] <JEEB> acresearch: most likely something like this would work `ffmpeg -i input.mkv -c:v libx264 -preset veryfast -crf 21 -vf scale=1920:1080 -c:a copy -sn out.mp4` would work [21:38:33 CET] <JEEB> uhh, wait [21:38:52 CET] <JEEB> `ffmpeg -i input.mkv -c:v libx264 -preset veryfast -level 41 -crf 21 -vf scale=1920:1080 -c:a copy -sn out.mp4` [21:38:58 CET] <JEEB> forgot the level definition :P [21:39:09 CET] <JEEB> (41 gets parsed as 4.1) [21:39:20 CET] <JEEB> anyways, that will take quite a bit of time [21:39:44 CET] <JEEB> it will decode the video, and re-transcode it with libx264, preset veryfast :P [21:39:48 CET] <acresearch> JEEB: no problem, thanks for your help, i hope it works, will update you when it finishes :-) [21:39:59 CET] <JEEB> and before transcoding it will scale it down to 1080p [21:40:06 CET] <acresearch> oh ok [21:40:30 CET] <JEEB> it's a HD screen and I'd be surprised if your TV's ASIC could take 2160p AVC [21:40:57 CET] <acresearch> oh ok, so my screen cannot handel more than 1080p? [21:41:17 CET] <feliwir> JEEB, well for YUV 4:2:2 what would the size be? Just width*height? [21:41:50 CET] <JEEB> depends on what sort of pixel format you're aiming for [21:41:58 CET] <JEEB> additionall there's a helper for that so you don't have to do it yourself [21:42:05 CET] <JEEB> (which I linked to you from the docs) [21:42:14 CET] <acresearch> where is the helper in the tv or ffmpeg? [21:44:57 CET] <feliwir> JEEB, i am not using the FFMPEG Api for my project [21:45:03 CET] <feliwir> so i can't use that to allocate my frame [21:45:22 CET] <JEEB> well good luck and have fun since you're as far as I can tell making your life much more painful for yourself [21:45:29 CET] <feliwir> trying to do the Vp6 decoder in C#, so some ffmpeg functions don't help me [21:45:33 CET] <JEEB> is C# FFI really that much of a trainwreck? [21:45:49 CET] <feliwir> well i was told vp6 decoding is relatively simple [21:45:53 CET] <feliwir> it's the worst^^ [21:46:12 CET] <feliwir> and then when doing cross platform development with C# i need native binaries for every platform [21:46:14 CET] <JEEB> then how the flying fsck do people get away with the libmpv C# example, for example? [21:46:20 CET] <JEEB> well yes [21:46:53 CET] <JEEB> I mean, it's not like you can't really evade native libraries altogether. none of the UI libs are 100% .NET either [21:47:32 CET] <feliwir> i am not doing UI. I am using OpenTK which gets away without native libraries :P [21:48:31 CET] <JEEB> anyways, even if VP6 is simple it's probably going to bring you much more blood sweat and tears trying to implement it yourself [21:48:50 CET] <JEEB> which is OK for a hobby project but for something that you're going to be distributing... not necessarily [21:49:12 CET] <JEEB> also if it's a player then I recommend looking into libmpv if you can get an opengl context out of opentk [21:52:14 CET] <feliwir> JEEB, it's just for a hobby project. I know ffmpeg is great and i always use it when i am doing C/C++. The problem is i am rewritting a game engine in C# and that particular engine uses the Vp6 codec :) [21:52:51 CET] <JEEB> feliwir: basically if you are going to be publishing it and wanting people to use it I would just bite the bullet and require libavcodec et al [21:52:58 CET] <JEEB> and just not show the videos if not found [21:53:17 CET] <JEEB> if it's truly just a hobby thing which isn't supposed to be used by others and just for your learning - just fine :) [21:53:22 CET] <JEEB> learning's fun and all [21:55:11 CET] <feliwir> well it should eventually be used by others. But i only require a single codec/container combination [21:55:36 CET] <feliwir> so i guessed before wrapping the entire ffmpeg library for C# i just go ahead and write that single codec & container myself [21:55:49 CET] <JEEB> there's no single library :) [21:56:01 CET] <JEEB> there's N libraries, most commonly used being libavformat and libavcodec [21:56:31 CET] <feliwir> yea, you know what i meant :D But i would eventually require avfilter and swsresample aswell. [21:57:04 CET] <feliwir> Also ffmpeg is lacking a vp6 encoder, so i thought when i write the decoder i might learn some useful things that i could put into an encoder [21:57:24 CET] <feliwir> eventhough an encoder is probably X times more difficult [22:00:34 CET] <JEEB> depends really, you can make a really limited encoder if you want [22:00:50 CET] <JEEB> but yea, don't get my words wrong - learning these things is fun [22:01:49 CET] <feliwir> yup. I think starting with H264 or something similiar would be much more complicated than vp6 [22:03:26 CET] <JEEB> I started with something even less complicated [22:03:29 CET] <JEEB> Ut Video [00:00:00 CET] --- Mon Mar 13 2017

1 0

ffmpeg-devel.log.20170311
by burek 12 Mar '17

12 Mar '17

[02:51:40 CET] <cone-015> ffmpeg 03Michael Niedermayer 07master:dc0b9b218c19: avcodec/h264_ps: Forward errors from decode_scaling_list() [02:51:40 CET] <cone-015> ffmpeg 03Michael Niedermayer 07master:6e913f212907: avcodec/vp56: Reset have_undamaged_frame on resolution changes [04:13:05 CET] <cone-015> ffmpeg 03Steven Liu 07master:51e3501993e3: ffprobe: add AVCodecContext help message into ffprobe [05:40:06 CET] <adeel1> durandal_1707: I have tried adding " everywhere even in the middle of pixels section, but it still works fine [09:59:00 CET] Last message repeated 1 time(s). [10:28:52 CET] <durandal_1707> adeel1: really? im really dont have time to guide you through every single step [10:53:45 CET] <durandal_1707> also test with 5k number of colors [11:03:56 CET] <adeel1> durandal_1707: I was merely stating what I found. Okay, let me check for more colors. [11:27:26 CET] <adeel1> durandal_1707: Using GIMP, I have converted a 2048x1356 image to XPM, and I'm getting "unsupported number of chars per pixel" error. However, last night I used a web based converted at it worked! [11:29:36 CET] <durandal_1707> adeel1: im not going to help you this time, you are on your own [11:57:01 CET] <cone-699> ffmpeg 03Moritz Barsnick 07master:114bbb0b74ed: libavfilter/avf_showwaves: make sqrt and cbrt scale option values available to showwavespic by name [12:01:41 CET] <adeel1> durandal_1707: got it to work. I had to remove cpp ==2 check, and add 94 * 94 * 94 in av_fast_padded_malloc [12:02:34 CET] <durandal_1707> but that allocates too much when not needed [12:04:21 CET] <adeel1> durandal_1707: yes, it allocates 94 * 94 * 94 when cpp !=2. I'll add 3 checks if cpp == 1 then 94... and so on [12:13:22 CET] <adeel1> durandal_1707: I have added this updated check: av_fast_padded_malloc(&x->pixels, &x->pixels_size, cpp == 1 ? 94 : cpp == 2 ? 94 * 94 : 94 * 94 * 94); [12:13:57 CET] <durandal_1707> thats wrong and ugly [12:23:05 CET] <adeel1> durandal_1707: Would you prefer this? if (cpp == 1) av_fast_padded_malloc(&x->pixels, &x->pixels_size, 94); else if (cpp == 2) av_fast_padded_malloc(&x->pixels, &x->pixels_size, 94 * 94); else av_fast_padded_malloc(&x->pixels, &x->pixels_size, 94 * 94 * 94); [12:26:51 CET] <durandal_1707> adeel1: no, you missed point [12:27:13 CET] <adeel1> durandal_1707: it's wrong? [12:27:25 CET] <nightlingo> I would like to change ffmpegs code, adding an option to skip writing the mdat part when performing a conversion. Would that be too difficult? [12:28:19 CET] <durandal_1707> adeel1: wrong, incomplete, buggy [12:53:27 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:31e41350d283: arm: vp9itxfm: Avoid .irp when it doesn't save any lines [12:53:28 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:52c7366c83ab: aarch64: vp9itxfm: Restructure the idct32 store macros [12:53:29 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:f8fcee0daf42: arm: vp9itxfm: Make the larger core transforms standalone functions [12:53:30 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:dc47bf3872fd: aarch64: vp9itxfm: Make the larger core transforms standalone functions [12:53:31 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:3bd9b3910807: arm: vp9itxfm: Move the load_add_store macro out from the itxfm16 pass2 function [12:53:32 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:a681c793a303: aarch64: vp9itxfm: Move the load_add_store macro out from the itxfm16 pass2 function [12:53:33 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:824589556cb7: arm: vp9itxfm: Do a simpler half/quarter idct16/idct32 when possible [12:53:34 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:9532a7d4d060: aarch64: vp9itxfm: Do separate functions for half/quarter idct16 and idct32 [12:53:35 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:1d8ab576a7e4: arm: vp9itxfm: Share instructions for loading idct coeffs in the 8x8 function [12:53:36 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:3006e5253afc: aarch64: vp9itxfm: Share instructions for loading idct coeffs in the 8x8 function [12:53:37 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:19a0f9529ccd: aarch64: vp9itxfm: Use a single lane ld1 instead of ld1r where possible [12:53:38 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:6752318c7376: aarch64: vp9itxfm: Use the right lane sizes in 8x8 for improved readability [12:53:39 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:d0fbf7f34e72: aarch64: vp9itxfm: Update a comment to refer to a register with a different name [12:53:40 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:16ef000799b2: aarch64: vp9itxfm: Fix incorrect vertical alignment [12:53:41 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:ac6cb8ae5b1c: aarch64: vp9mc: Simplify the extmla macro parameters [12:53:42 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:bff07715904c: arm: vp9mc: Calculate less unused data in the 4 pixel wide horizontal filter [12:53:43 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:045e33ae3fee: aarch64: vp9mc: Calculate less unused data in the 4 pixel wide horizontal filter [12:53:44 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:758302e4bc14: arm: vp9itxfm: Optimize 16x16 and 32x32 idct dc by unrolling [12:53:45 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:148cc0bb8908: aarch64: vp9itxfm: Optimize 16x16 and 32x32 idct dc by unrolling [12:53:46 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:f0ecbb13cf1c: arm/aarch64: vp9lpf: Calculate !hev directly [12:53:47 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:92ab8374b105: arm: vp9lpf: Use orrs instead of orr+cmp [12:53:48 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:83399cf569c9: arm: vp9lpf: Interleave the start of flat8in into the calculation above [12:53:49 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:9f3a8863648e: aarch64: vp9lpf: Interleave the start of flat8in into the calculation above [12:53:50 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:c8d6eec85d6a: aarch64: vp9lpf: Fix broken indentation/vertical alignment [12:53:51 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:dda45c087b2c: aarch64: Add parentheses around the offset parameter in movrel [12:53:52 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:3fbbad29847c: arm/aarch64: vp9lpf: Keep the comparison to E within 8 bit [12:53:53 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:f32690a298ba: aarch64: vp9lpf: Use dup+rev16+uzp1 instead of dup+lsr+dup+trn1 [12:53:54 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:a88db8b9a016: arm: vp9lpf: Implement the mix2_44 function with one single filter pass [12:53:55 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:600f4c9b03b8: arm: vp9itxfm: Avoid reloading the idct32 coefficients [12:53:56 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:2905657b902f: aarch64: vp9itxfm: Avoid reloading the idct32 coefficients [12:53:57 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:4f693b56bdcf: arm: vp9itxfm: Reorder the idct coefficients for better pairing [12:53:58 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:f95227301998: aarch64: vp9itxfm: Reorder the idct coefficients for better pairing [12:53:59 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:b2e20d89844b: arm: vp9itxfm: Reorder iadst16 coeffs [12:54:00 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:26ee83acc4eb: aarch64: vp9itxfm: Reorder iadst16 coeffs [13:09:37 CET] <adeel1> durandal_1707: im working on 83k colors image. its working but pixels not scattered over full height. also code for skipping " ptr += strcspn(ptr, "\"") + 1; was already in there [13:13:16 CET] <durandal_1707> nope, you are mistaken [13:14:40 CET] <durandal_1707> that skips just " before, after chars that resembles pixels [13:41:34 CET] <adeel1> durandal_1707: I have added a strcspn call before the end (meaning " in between are skipped). I have also verified it making changes in xpm file. [13:44:39 CET] <durandal_1707> not enough [13:48:30 CET] <durandal_1707> you need good and fast way to skip comments [13:58:13 CET] <adeel1> durandal_1707: should both these comment styles (//, /**/) be taken care of? [13:59:28 CET] <durandal_1707> yes, if you do any of two you did all of them, eg its easily expandable [14:00:36 CET] <paras2052> durandal_1707: hi [14:01:00 CET] <durandal_1707> hi [14:01:26 CET] <paras2052> i have a few doubts [14:01:54 CET] <paras2052> what should i do when a comment is not proper like i have found /* but ending */ is not there [14:02:13 CET] <ubitux> i'm starting the merge again [14:02:24 CET] <ubitux> we just crossed the 1k+ limit [14:02:32 CET] <durandal_1707> nothing, you function should take care of that [14:02:37 CET] <ubitux> next commit is b0f36a0043 avconv: stop using setpts for input framerate forced with -r [14:02:48 CET] <ubitux> if anything has something to say about it, please share [14:02:55 CET] <ubitux> s/anything/anyone/ [14:03:51 CET] <paras2052> durandal_1707: inside the modified strcspn function, should i ignore '/*' this and continue processing rest of the string ? [14:04:26 CET] <durandal_1707> no, if its invalid file its invalid [14:07:13 CET] <paras2052> durandal_1707: okay, i actually added that ignoring thing inside modified strcspn in the lastest patch, that's why it was complicated. Now, should i reimplement or use the previous version created by me ? [14:08:13 CET] <durandal_1707> paras2052: reimplement it, its very simple actually [14:09:33 CET] <durandal_1707> see how strcspn is implemented [14:09:33 CET] <paras2052> durandal_1707: okay, i am doing it [14:09:50 CET] <paras2052> okay [14:12:32 CET] <cone-699> ffmpeg 03Steven Liu 07master:70a9407b509f: doc/muxers: move hls_flags temp_file to after SECOND LEVEL hls example [14:15:27 CET] <adeel1> durandal_1707: I have created a function with two strcspn calls, first it skips till /* then till */ [14:16:21 CET] <adeel1> durandal_1707: however, in case of // comments since there's no closing. should i skip till newline [14:16:22 CET] <adeel1> ? [14:16:23 CET] <durandal_1707> and? [14:16:39 CET] <durandal_1707> off course [14:16:43 CET] <adeel1> okay [14:17:37 CET] <ubitux> michaelni: do you have a moment to talk about our lord the pts management in ffmpeg? [14:18:00 CET] <ubitux> wrt b0f36a0043 it appears that our "best effort timestamp" is enough to deal with this [14:18:13 CET] <ubitux> like, if i just drop the auto-inserted setpts [14:18:23 CET] <ubitux> the rate is correctly honored [14:18:44 CET] <ubitux> this input pts is obtained through av_frame_get_best_effort_timestamp() [14:19:07 CET] <ubitux> so my question is: will this be always reliable, or i should keep the extra counter in ffmpeg side? [14:19:48 CET] <ubitux> my simple test was running "./ffmpeg -r 5 -f rawvideo -s cif -pix_fmt rgba -i /dev/zero -f null -" and FATE [14:19:54 CET] <ubitux> but i assume this might not be enough [14:24:40 CET] <ubitux> actually, this may have an impact wrt stream tb [14:24:49 CET] <ubitux> we need tests for this stuff& [14:26:59 CET] <michaelni> ubitux, i agree, more tests are needed [14:28:02 CET] <ubitux> we need tests that uses -r for input and output, where both could be cfr or vfr and with different tb [14:38:43 CET] <adeel1> durandal_1707: okay, done. both style comments are now skipped [14:38:51 CET] <adeel1> should I share code? [14:53:20 CET] <ubitux> meh, what happened to gif muxing [15:28:47 CET] <Mirage20> Hello @BBB, I updated the avx asm code with your suggestions. https://github.com/Mirage20/FFmpeg/blob/vp8-avx2/libavcodec/x86/h264_intrap… [15:43:33 CET] <paras2052> durandal_1707: Can you review please new strcspn and coding style, https://gist.github.com/paraschadha2052/b5d663dcf1bdd2dff7ecccf210da038f [15:55:31 CET] <adeel1> durandal_1707: please review the updated code, check for skipcomments method: https://gist.github.com/adl1995/b8a25d8f81d0b7218e319c25d5427ed1 [16:00:58 CET] <durandal_1707> paras2052: no need to call external functions [16:05:29 CET] <durandal_1707> adeel1: fragile, i have headache of so many calls and its flawed logic [16:06:20 CET] <adeel1> durandal_1707: are you refering to the skipcomments method? [16:07:26 CET] <BBB> mirag20: hi [16:07:50 CET] <mirag20> hi [16:08:14 CET] <BBB> mirag20: looks better. few more comments: vextracti128 can go directly to memory, youre doing 8 lines per iteration, but I think thats no faster than 4 per iter, even though that would half the amount of code, youre still using unnamed registers for r2/3/4/5, you need to test this on x86-32 [16:08:46 CET] <BBB> paddw ma, mb, ma is the same as paddw ma, mb but the second is shorter, so please use that [16:09:02 CET] <BBB> (priority 1: fast code, priority 2: small binary size, priority 3: small source size) [16:09:42 CET] <durandal_1707> adeel1: yes, also calling it that way is not going to work always [16:09:47 CET] <mirag20> i will update with vextracti128.i test it with 4 and 2 iterations [16:09:55 CET] <BBB> ok [16:10:01 CET] <BBB> I think 4 will be equally fast and 2 will be slower [16:10:02 CET] <mirag20> after loop is unrolled it get avrage 44 and 45 [16:10:12 CET] <BBB> but Im just randomly guessing, so test is better :) [16:10:32 CET] <mirag20> i though it get slow bcz of branch prediction [16:10:45 CET] <mirag20> i will re check with 4 iterations [16:10:52 CET] <durandal_1707> adeel1: also you havent cleaned other buggy code i pointed out [16:13:47 CET] <mirag20> "youre still using unnamed registers for r2/3/4/5" how should i declare a variable? I'm bit new to asm :) [16:15:06 CET] <BBB> cglobal function, num_args, num_gpr_regs, num_xmm_regs, [stack memory (optional)], name1, name2, name3, name4, name5, etc. [16:15:20 CET] <BBB> name1 refers to r0, name2 to r1, etc. [16:15:25 CET] <adeel1> if you are refering to the av_fast_padded_malloc call, shouldn't memory be allocated this way? 94 times cpp? [16:15:29 CET] <BBB> so e.g. r2d would become name3d [16:15:38 CET] <BBB> and r5 would become name6q [16:15:40 CET] <BBB> etc. [16:17:41 CET] <mirag20> thanks. I will update and test the performance. [16:20:15 CET] <durandal_1707> adeel1: having if/else is unacceptable, it must supports even 5 [16:20:31 CET] <adeel1> okay, i will simply multipl by cpp [16:21:06 CET] <adeel1> av_fast_padded_malloc(&x->pixels, &x->pixels_size, 94 * cpp); [16:21:10 CET] <adeel1> is this fine? [16:21:15 CET] <durandal_1707> adeel1: you can not just multiply [16:21:54 CET] <adeel1> durandal_1707: but it was 94 * 94 for cpp == 2 before. isnt that the same thing? or am i missing something? [16:22:22 CET] <durandal_1707> basic math [16:23:50 CET] <JEEB> &32 [16:26:36 CET] <adeel1> durandal_1707: since our character lie in range ' ' to '~' the difference comes to be 94. Also, shouldnt the memory be assigned on the basis of character? 94 * cpp would mean all possible options. [16:27:17 CET] <durandal_1707> nope [16:27:45 CET] <durandal_1707> think again [16:28:16 CET] <durandal_1707> 94*94 != 2 * 94 [16:29:42 CET] <BBB> mirag20: okay, cool [16:30:20 CET] <BBB> mirag20: its relatively normal for first-time contributors patches to go through review rounds a couple of times, so this is all fairly normal, just so you know ;) [16:34:25 CET] <adeel1> durandal_1707: my bad. so multiplying 94 by 94 cpp times should be good? or do we add in to the previous result? like for cpp == 3, (94) + (94*94) + (94*94*94) [16:35:21 CET] <durandal_1707> add to prev result [16:36:57 CET] <adeel1> durandal_1707: okay, and you mentioned previously that "calling it that way is not going to work always", what other way is there to call the function? [16:39:32 CET] <durandal_1707> adeel1: you completly missed the point, one should skip commmemnts whenever they occur [16:43:15 CET] <BBB> mirag20: also please fix your indenting, the code should be aligned by the comma after the first source operand [16:43:56 CET] <BBB> mirag20: so e.g. if you have paddw m0, m1 followed by mova [address], m0, the two lines should be vertically aligned by their comma [16:44:01 CET] <cone-699> ffmpeg 03PrzemysBaw Sobala 07master:89c0fda5f43d: lavf/dashenc: update bitrates on dash_write_trailer [16:44:25 CET] <BBB> mirag20: look at the other functions around there for more practical examples of idnentation [16:57:17 CET] <paras2052> durandal_1707: Check this one, https://gist.github.com/paraschadha2052/b5d663dcf1bdd2dff7ecccf210da038f [17:03:26 CET] <durandal_1707> paras2052: you can simplify that further, checking for 2 chars at once in if [17:05:12 CET] <paras2052> okay, by using uint16_t, i guess ? [17:07:38 CET] <paras2052> not that maybe, if i check two chars inside i, then further inside if i have to add two more if's to check for the type comment because ending style is different for both the comments. Am i wrong ? [17:08:28 CET] <paras2052> if i check two chars inside if* [17:20:44 CET] <durandal_1707> paras2052: yes [17:26:29 CET] <paras2052> okay [17:30:20 CET] <paras2052> durandal_1707: So, you mean something like this, https://gist.github.com/paraschadha2052/b5d663dcf1bdd2dff7ecccf210da038f [17:32:28 CET] <durandal_1707> paras2052: you need to check for 0/NULL [17:32:36 CET] <durandal_1707> in while loop [17:36:05 CET] <paras2052> durandal_1707: yup, done, https://gist.github.com/paraschadha2052/b5d663dcf1bdd2dff7ecccf210da038f [17:37:28 CET] <paras2052> durandal_1707: i have a question, will checking not make it more slow. I mean we are adding two extra operations in the loop ? [17:43:53 CET] <mirag20> hi I updated the code [17:43:54 CET] <mirag20> https://github.com/Mirage20/FFmpeg/blob/vp8-avx2/libavcodec/x86/h264_intrap… [17:44:44 CET] <mirag20> i ran few tests with both 2 and 4 iterations [17:45:43 CET] <mirag20> x64 2 iterations pred16x16_tm_vp8_sse2: 95.6 pred16x16_tm_vp8_avx2: 37.9 [17:46:07 CET] <mirag20> x64 4 iterations pred16x16_tm_vp8_sse2: 93.8 pred16x16_tm_vp8_avx2: 41.1 [17:46:31 CET] <mirag20> what should i do? [17:47:54 CET] <mirag20> Also I compiled to x86_32 "./configure --disable-stripping --enable-debug=3 --extra-cflags="-gstabs+" --disable-optimizations --arch=x86_32" [17:48:30 CET] <mirag20> x86 result is pred16x16_tm_vp8_sse2: 93.1 pred16x16_tm_vp8_avx2: 38.2 [18:05:09 CET] <durandal_1707> paras2052: its fine [18:05:48 CET] <paras2052> durandal_1707: any coding style changes ? [18:09:48 CET] <durandal_1707> paras2052: see style of other files and follow thern [18:09:58 CET] <durandal_1707> dont use tabs [18:10:38 CET] <paras2052> i will remove tabs with whitespace and also trailing spaces (actually posting on github gist they got automatically added) [18:11:39 CET] <paras2052> for, loops and conditionals i am following k&r style [18:11:49 CET] <paras2052> any other style conventions ? [18:19:35 CET] <durandal_1707> paras2052: no [18:21:54 CET] <paras2052> durandal_1707: okay, thanks for helping so much. Also, can you give more details of "Please also add xpm_pipe demuxer with its probe function." I don't know much about demultiplexer's and probe functions. [18:22:53 CET] <durandal_1707> paras2052: look at other code, see for example png_probe [18:23:09 CET] <BBB> mirag20: if 2 iterations is faster, then we keep the 2 [18:23:23 CET] <BBB> mirag20: the code as-is cannot work on x86-32, thats why I asked you to test it ;) [18:23:41 CET] <BBB> mirag20: use extra-cflags=-m32 extra-libs=-m32 as configure options [18:23:47 CET] <BBB> then it compiles a 32bit binary [18:23:50 CET] <mirag20> so actually --arch=x86_32 is not working? [18:23:51 CET] <mirag20> :D [18:23:53 CET] <paras2052> durandal_1707: okay, thanks [18:23:59 CET] <BBB> mirag20: I suppose ;) [18:24:37 CET] <durandal_1707> paras2052: libavformat/img2dec.c [18:26:57 CET] <paras2052> durandal_1707: okay, i have to implement in img2dec.c ? [18:27:13 CET] <durandal_1707> yes [18:27:35 CET] <durandal_1707> its easy, just look how others are done [18:27:36 CET] <mirag20> you mean AVX is not working on 32bit? [18:27:52 CET] <paras2052> durandal_1707: okay, on it [18:37:11 CET] <BBB> mirag20: no, it is; but your imlpementation cannot work on 32bit :-p [18:37:27 CET] <BBB> mirag20: compile it first, then see it crash [18:37:32 CET] <BBB> mirag20: then Ill help you fix it [18:51:12 CET] <decepto> BBB: I want to start working on VMAF video filter project for GSoC. For the qualification task, could you please let me know if it's still available? [18:51:25 CET] <BBB> someone else already took it [18:51:33 CET] <BBB> so were going to have to find you another qualification task [18:51:38 CET] <BBB> hm& this is getting rather complicated [18:51:54 CET] <BBB> I cant keep track of all the qualification tasks anymore [18:52:21 CET] <BBB> is thilo on IRC? [18:53:33 CET] <BBB> I guess not [18:53:46 CET] <BBB> durandal_1707: do you have any filters that need writing and could serve as gsoc qual task? [18:54:08 CET] <BBB> decepto: Ill be honest, Ive had more interest than anticipated so I ran out of potential qualification tasks :-/ [18:54:49 CET] <durandal_1707> BBB: yes i have [18:55:26 CET] <atomnuker> send some my way, I have had 1 person for the vorbis encoder who went awol [18:56:11 CET] <durandal_1707> BBB: write qr code filter source using libqrencode [18:57:06 CET] <BBB> decepto: interested in that as a qualification task? [18:58:17 CET] <decepto> BBB: I'll give it a try :) [18:58:21 CET] <durandal_1707> BBB: what about student that already posted vmaf via some stuff? [18:58:46 CET] <BBB> durandal_1707: that student is finished& but multiple students can apply for the same project I suppose [18:58:58 CET] <BBB> its probably better to spread it out over multiple projects if we have no applicants for others [18:59:30 CET] <durandal_1707> ugh, so what they will do? together? [18:59:35 CET] <BBB> but it seems to me that if 2 students are interested in A, we should sort of let them fight it out over who gets to do A, and then if theyre both good but only one got A and theres no students for B, we can sort of nudge the other student to do B [18:59:43 CET] <BBB> (if the other student is interested) [18:59:52 CET] <BBB> we can also do that during qualification time I suppose [19:00:17 CET] <BBB> I agree this is all very strange, but googles application structure seems sort of intended for this type of competition [19:00:22 CET] <durandal_1707> ah yes, if they are interested in minterpolate or dicom or vorbis [19:00:52 CET] <BBB> vorbis is fun [19:00:58 CET] <BBB> should do opus also [19:01:20 CET] <durandal_1707> atomnuker: only you can make vorbus encoder useful [19:01:41 CET] <BBB> decepto: so, Ill try to be helpful for this qualification task, but I have to be honest that I dont know all the details about it yet, so the first few questions may take me a while to get up to speed also& [19:03:18 CET] <durandal_1707> http://fukuchi.org/works/qrencode/manual/ [19:10:37 CET] <mirag20> BBB: ok got it, not every one in this world have 64bit :D [19:10:57 CET] <BBB> right& importantly, chrome for windows is to my knowledge still sometimes 32bit [19:11:12 CET] <BBB> (maybe thats outdated? ...) [19:11:26 CET] <mirag20> yes most of the programs [19:15:53 CET] <mirag20> BBB: here is the update version :) [19:15:54 CET] <mirag20> https://github.com/Mirage20/FFmpeg/blob/vp8-avx2/libavcodec/x86/h264_intrap… [19:18:37 CET] <BBB> ah he found the 32bit bug, nice work [19:18:43 CET] <BBB> he=you [19:19:13 CET] <BBB> make r5 a named register also [19:19:27 CET] <BBB> otherwise it looks OK, send it to the ML so it can be reviewed officially and committed [19:19:50 CET] <mirag20> how is the process works? [19:19:59 CET] <mirag20> I mean should i send the git link to mail? [19:20:10 CET] <BBB> https://ffmpeg.org/developer.html#Submitting-patches-1 [19:43:38 CET] <adeel1> durandal_1707: I have updated code for size calc and skipping comments, please review: https://gist.github.com/adl1995/ff687e9748d5b3b5aad04536f766e89f [19:45:06 CET] <durandal_1707> adeel1: not good enough [19:46:24 CET] <adeel1> durandal_1707: because it will only look for comments only after parsing colors? [19:47:28 CET] <durandal_1707> adeel1: its limited and fragile [20:02:18 CET] <adeel1> durandal_1707: I have wrapped other calls in the new method and modified return value [20:05:08 CET] <adeel1> durandal_1707: https://gist.github.com/adl1995/6260b8a88c7bea49393be34b801635bc [20:10:13 CET] <durandal_1707> adeel1: whats max number of colors you tried? [20:10:35 CET] <adeel1> 83k [20:11:11 CET] <durandal_1707> really? [20:11:37 CET] <adeel1> yes, I used gimp to convert the image. to see no of colors i printed ncolors var. [20:12:44 CET] <mirag20> BBB: I sent the mail. Thanks for helping :) [20:13:10 CET] <BBB> mirag20: your patch to the ML needs some more information [20:14:27 CET] <BBB> mirag20: check e.g. http://permalink.gmane.org/gmane.comp.video.ffmpeg.devel/216587, ideally your commit message specifies how much faster the function became (e.g. just by copypasting the cycle counts from checkasm) [20:16:17 CET] <adeel1> durandal_1707: what is the next step? [20:19:51 CET] <durandal_1707> adeel1: fixing code and removing unneded code [20:20:44 CET] <adeel1> I see parse_str_int method isnt being used anywhere [20:23:57 CET] <durandal_1707> there is more [20:38:38 CET] <adeel1> durandal_1707: are some methods to be added for mapping to color to correct location? [20:40:04 CET] <adeel1> the color* [20:48:18 CET] <durandal_1707> adeel1: no [21:08:02 CET] <andrey_turkin> BtbN: here? [21:10:57 CET] <mirag20> BBB: I updated the email with results [21:31:50 CET] <cone-699> ffmpeg 03Muhammad Faiz 07master:0bab78f7e729: avfilter/af_firequalizer: add av_restrict on convolution func [00:00:00 CET] --- Sun Mar 12 2017

1 0

ffmpeg.log.20170311
by burek 12 Mar '17

12 Mar '17

[00:02:54 CET] <diverdude> hi, i am trying to run this command : ffmpeg -f lavfi -i testsrc=duration=10:size=4096x3000:rate=30 testsrc.mov but I cannot play it back and it only takes up 536kb, so something is going wrong. Why acnt i generate this testsource? [00:05:19 CET] <r0ute> Huh, threads just for multi core stuff? Seems they've been around for quite a while and I've used them plenty on single core architectures. [00:05:54 CET] <BtbN> diverdude, that exact command works fine for me. [00:06:01 CET] <BtbN> Defaults to mpeg4 for the video codec [00:06:23 CET] <diverdude> BtbN: which OS are you on? [00:06:32 CET] <BtbN> That shouldn't matter at all [00:07:46 CET] <diverdude> BtbN: how big is the file you generate when you run the command? [00:08:02 CET] <BtbN> 12 [00:08:06 CET] <BtbN> MB [00:08:11 CET] <diverdude> 12MB? [00:08:12 CET] <diverdude> ok [00:08:32 CET] <BtbN> using latest ffmpeg master [00:09:23 CET] <diverdude> i have ffmpeg version 3.2.4 [00:09:45 CET] <diverdude> and file i create is just 583K [00:10:07 CET] <llogan> nightlingo: if you want to save to local file and stream it at the same time see tee muxer (but maybe I didn't really follow what you wanted) [00:12:12 CET] <r0ute> diverdude: 3.2.4 here as well and I get a @12MB file [00:12:17 CET] <r0ute> ~12MB [00:13:37 CET] <nightlingo> llogan: Id like to avoid saving to a local file but maybe Ill do it as a last resort. What about that tee muxer? [00:13:38 CET] <diverdude> so why on earth is mine not working :/ [00:14:24 CET] <llogan> nightlingo: oh, so you don't even need a local mp4 file. i guess I don't know what you want to do then. as for tee: http://ffmpeg.org/ffmpeg-formats.html#tee [00:14:54 CET] <diverdude> r0ute: you are running this command right? ffmpeg -f lavfi -i testsrc=duration=10:size=4096x3000:rate=30 testsrc.mov [00:16:25 CET] <nightlingo> llogan: what I want to do is to be able to split an .mp4 file (say a 5 min part out of an hour long video) and output that part to sdtout [00:16:54 CET] <diverdude> llogan: this is my exact command and output from terminal : http://paste.ubuntu.com/24154404/ [00:17:34 CET] <llogan> nightlingo: ffmpeg -ss 30 -i input -t 00:05:00 -f mpegts - [00:17:55 CET] <r0ute> diverdude: I copied ad pasted yours and it worked fine [00:18:07 CET] <nightlingo> llogan: unfortunately the output of this doesnt work well with Windows Media Player on Windows 7 [00:18:07 CET] <llogan> diverdude: from your console output: "No pixel format specified, yuv444p for H.264 encoding chosen. Use -pix_fmt yuv420p for compatibility with outdated media players." [00:18:18 CET] <llogan> ah, WMP. [00:18:40 CET] <llogan> assumed a sane player [00:18:44 CET] <nightlingo> lol [00:19:02 CET] <nightlingo> llogan: if it was up to me I would ban this from my users :) [00:19:57 CET] <diverdude> llogan: hmmm then i get error : Option pixel_format not found. [00:20:14 CET] <diverdude> llogan: this is my command : ./ffmpeg -f lavfi -pix_fmt yuv420p -i testsrc=duration=10:size=4096x3000:rate=30 testsrc.mov [00:20:51 CET] <llogan> option placement matters. use it as an output option [00:21:23 CET] <diverdude> llogan: mm ok. how so? Can you show me an example? [00:21:41 CET] <llogan> ./ffmpeg -f lavfi -pix_fmt yuv420p -i testsrc=duration=10:size=4096x3000:rate=30 -vf format=yuv420p testsrc.mov [00:21:47 CET] <llogan> ./ffmpeg -f lavfi -pix_fmt yuv420p -i testsrc=duration=10:size=4096x3000:rate=30,format=yuv420p testsrc.mov [00:21:54 CET] <llogan> ./ffmpeg -f lavfi -pix_fmt yuv420p -i testsrc=duration=10:size=4096x3000:rate=30 -pix_fmt yuv420p testsrc.mov [00:22:08 CET] <llogan> oh, remove that input one [00:22:19 CET] <llogan> c&p fail [00:26:33 CET] <llogan> also, you're exceeding level limits so maybe your player won't like that. [00:27:39 CET] <diverdude> llogan: ok it works now....but strange enough file is only 836kb and not 12mb [00:28:09 CET] <diverdude> llogan: what level limits? [00:28:46 CET] <llogan> https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels [00:30:14 CET] <llogan> why should it be 12mb? it's not a very complex input. [00:31:40 CET] <diverdude> llogan: because some other guys in here ran my command and got a 12mb file output [00:32:46 CET] <llogan> they ran a different command and some used a different encoder [00:33:19 CET] <diverdude> llogan: ok...so exceeding level limits...it seems..at least according to that table that no level can handle 4096x3000 reslution, so that is probably what you are referring to when you say 'exceed level limits'. But then how should i encode a video of this size if its not supported in any level? [00:35:59 CET] <llogan> you can still encode 4096x3000. just make sure your player likes it. or use a different encoder such as libx265. [00:37:01 CET] <diverdude> llogan: right ok i see. [00:37:07 CET] <ZeroWalker> which library has "sws_getContext", i thought it was swscale.lib but it seems not [00:40:08 CET] <thebombzen> diverdude: yea around 400-500 kbps is fine for libx264, but I recommend libx265 [00:40:36 CET] <thebombzen> 12M is what you'll get if you use mpeg4 as the default, which defaults to 2 Mbps rather than crf 23 [00:41:09 CET] <thebombzen> I"m not sure why BtbN's build defaulted to mpeg4 when the mov muxer requests h.264 by default [00:41:33 CET] <llogan> because it probably wasn't built with --enable-gpl --enable-libx264 [00:41:44 CET] <thebombzen> haha true lol [00:42:02 CET] <thebombzen> speaking of which, why does nut still not support opus [00:42:11 CET] <thebombzen> nut still requests mpeg4 [00:42:17 CET] <thebombzen> and vorbis afaik [00:42:27 CET] <thebombzen> which is really annoying. it should request ffv1 and flac [00:42:32 CET] <thebombzen> and it should support opus [00:44:35 CET] <kepstin> probably needs some work done to add an opus codec mapping, which iirc mostly means some way of storing the samples to discard at start/end. Might need some work to handle seeking differently? I dunno how exactly seeking works in nut. [00:47:21 CET] <llogan> thebombzen: i don't know. patch welcome, but be warned that there are like some who will automatically oppose any change. [00:47:45 CET] <llogan> don't know where that "like" came from. [00:48:08 CET] <thebombzen> well the issue is more that "nut should support anything that ffmpeg can produce" [00:48:12 CET] <thebombzen> which is currently not the case [00:48:26 CET] <thebombzen> the defaulting to mpeg4 is annoying but not as problematic as "doens't support opus" [01:41:55 CET] <nightlingo> is there any option to skip mdat when writing the output ? or just extract the MOOV atom of the operation? [04:09:46 CET] <FFmpegFTL> Hello folks. We currently trying to get a rtmp server up and running, only using ffmpeg. We have found a old version of ffmpeg with build in rtmp_listen option. After we downloaded the latest ffmpeg version from the official website we saw there is no option like rtmp_listen anymore. Has rtmp_listen been removed, or does it changed in any way ? [04:11:00 CET] <FFmpegFTL> The old repo can bei found here https://github.com/WatchBeam/ftl-ffmpeg [04:13:28 CET] <furq> FFmpegFTL: it's just listen now [04:13:42 CET] <furq> although i don't think that'll work as you hope it will [04:14:04 CET] <FFmpegFTL> So it has been completely removed ? [04:15:59 CET] <furq> no, the option was renamed [04:16:17 CET] <FFmpegFTL> Thats sad. We are currently trying to get multiple streams (4) and merge them together to one stream to push it to streaming services like twitch [04:16:50 CET] <furq> but it works the same as all the other ffmpeg server functionality, i.e. not very well [04:17:07 CET] <furq> it'll only serve one client, it won't do anything until a client connects and then it'll die when the client disconnects [04:17:18 CET] <furq> use nginx-rtmp or something [04:17:41 CET] <FFmpegFTL> We tried to avoid that :/ [04:17:57 CET] <furq> what's wrong with it [04:18:23 CET] <FFmpegFTL> In my opinion, it just adds more latency to the stream [04:19:35 CET] <FFmpegFTL> So when using streaming services like beam.pro which have nearly realtime (~500ms delay) [04:19:58 CET] <FFmpegFTL> Thats not a good thing to add more latency to the stream [04:23:00 CET] <FFmpegFTL> Can you give me a starting point on how to get the latest ffmpeg to listen for a incoming rtmp stream ? [04:23:35 CET] <furq> oh [04:23:40 CET] <furq> i don't know if it can listen for an incoming stream [04:24:14 CET] <furq> -listen will serve a stream to the next client that connects [04:24:35 CET] <FFmpegFTL> Thats what i meant with the rtmp_listen option [04:24:57 CET] <FFmpegFTL> It actually listens for an incoming rtmp stream [04:25:30 CET] <furq> oh i guess that does work [04:28:13 CET] <furq> just put -listen 1 before -i rtmp://.. [04:28:23 CET] <furq> this seems incredibly flaky though [04:29:18 CET] <FFmpegFTL> The syntax when using the old source is [04:29:35 CET] <FFmpegFTL> ffmpeg -rtmp_listen 1 -re -i rtmp://0.0.0.0:8090 [04:29:47 CET] <furq> like i said, -listen is the same option [04:29:49 CET] <furq> it was just renamed [04:32:37 CET] <FFmpegFTL> When Ich try this, it says that ist cant connect [04:32:51 CET] <FFmpegFTL> *when i try this [04:34:23 CET] <FFmpegFTL> RTMP_Connect0, failed to connect socket. 10049 (Unknown Erröten) [04:34:32 CET] <FFmpegFTL> *Error [04:34:58 CET] <furq> it works for me but i was providing the app name [04:35:05 CET] <furq> -i rtmp://0.0.0.0:1935/live/foo [04:40:58 CET] <FFmpegFTL> Same error [04:41:17 CET] <FFmpegFTL> Just for make thing [04:41:51 CET] <FFmpegFTL> Just for making things clear, can u send me the complete line ? [04:43:51 CET] <furq> ffmpeg -listen 1 -i rtmp://0.0.0.0:1935/live/foo -f null - [04:44:11 CET] <furq> ffmpeg -f lavfi -re -i testsrc -c:v libx264 -f flv rtmp://localhost:1935/live/foo [04:48:25 CET] <FFmpegFTL> Ich think something is wrong here on my side [04:48:37 CET] <FFmpegFTL> RTMP_Connect0, failed to connect socket. 10049 (Unknown error) rtmp://0.0.0.0:1935/live/foo: Unknown error occurred0 [04:48:59 CET] <FFmpegFTL> Thats what I get then [04:50:14 CET] <FFmpegFTL> I am using version 3.2.2 on windows [04:58:07 CET] <FFmpegFTL> Does it make a difference when using this on Windows ? [04:58:39 CET] <furq> it shouldn't [04:58:48 CET] <furq> it might make a difference if you have a build with librtmp [04:58:58 CET] <furq> mine doesn't have it [04:59:28 CET] <FFmpegFTL> Mine has --enable-librtmp flag set [05:02:18 CET] <FFmpegFTL> I will try to compile it without this flag, and try again tomorrow. Thanks for your help :) [05:46:31 CET] <ZeroWalker> anyone know how to convert rgba to yuv420p with swscale (coding) [11:20:00 CET] <nightlingo> hi [11:20:18 CET] <nightlingo> is there any option to skip the mdat part when writing the output ? or just save the MOOV atom of the operation? [11:38:00 CET] <thebombzen> nightlingo: why do you want to do that [11:38:17 CET] <thebombzen> you could always use -movflags +faststart to move it to the front of the file instead [11:38:22 CET] <thebombzen> and then just cut it [11:40:58 CET] <nightlingo> thebombzen: the reason is that I want to avoid having to produce the whole [11:41:52 CET] <nightlingo> thebombzen: file. My ultimate goal is to be able to split an mp4 and have the output sent to stdout. Since ffmpeg doesnt allow writing mp4 format to stdout Im trying to do it manually [11:42:13 CET] <nightlingo> thebombzen: faststart requires the whole file to be written anyway [11:53:48 CET] <kerio> what about fragmented mp4 [11:54:35 CET] <nightlingo> kerio: fragmented mp4 doesnt work well on some older players like WMP windows 7 [11:55:02 CET] <kerio> sorry :( [11:55:26 CET] <nightlingo> :) [11:55:39 CET] <kerio> i mean [11:56:12 CET] <kerio> i don't think there's a way to write the moov atom beforehand [11:56:48 CET] <nightlingo> kerio [11:57:02 CET] <nightlingo> kerio: seems like it. I was hoping at least a way to skip writting the mdat part altogether [11:57:09 CET] <nightlingo> but cant find anything [12:43:23 CET] <luc4> Hello! I frequently build ffmpeg for embedded platforms. I sometime get these kinds of errors: https://paste.kde.org/pjc33vtva. It seems like configure cannot find libs that are actually on the device. I added rpath as you can see in the command line. Isnt this sufficient? Maybe it is not added to the link command? Any advice? [12:58:46 CET] <DHE> is this the real thing or a cross compiler on your own PC? [13:16:39 CET] <luc4> DHE: crosscompiler [13:18:05 CET] <JEEB> luc4: you would have to have the sysroot on the build machine as well [13:18:18 CET] <JEEB> otherwise the cross-compiler will just be "lol cannot find what against to link" [13:18:31 CET] <DHE> with all the needed libraries, and probably the pkg-config metadata [13:18:58 CET] <JEEB> pkg-config files help together with PKG_CONFIG_LIBDIR set correctly, yes [13:20:53 CET] <luc4> JEEB, DHE: the sysroot is properly mounted, I already built GBs of sources with the same toolchain and sysroot [13:21:38 CET] <luc4> also I already built ffmpeg for the same platform a hundred times, but this problem with libssh and libsmbclient keeps popping up [13:22:08 CET] <luc4> I was hoping someone could explain the situation properly because it is not completely clear to me what is happening [13:22:30 CET] <luc4> paths to the pkg-config paths are set [13:23:19 CET] <JEEB> right [13:23:23 CET] <luc4> pkg-config libssh libs and cflags properly returns -L/opt/rpi/sysroot/usr/lib/arm-linux-gnueabihf -lssh [13:23:29 CET] <JEEB> that seems pretty obvious, though. a library is missing [13:23:38 CET] <JEEB> warning: libgssapi_krb5.so.2, needed by /opt/rpi/sysroot/usr/lib/arm-linux-gnueabihf/libssh.so, not found [13:23:41 CET] <luc4> where /opt/rpi/sysroot is where the sysroot is mounted [13:24:12 CET] <luc4> JEEB: I checked a few and those where installed, let me check that specifically [13:24:54 CET] <luc4> JEEB: preset in /usr/lib/arm-linux-gnueabihf/libgssapi_krb5.so.2 [13:25:22 CET] <JEEB> which is not your sysroot :D [13:25:31 CET] <luc4> of course it is [13:25:39 CET] <luc4> that is the path in the board [13:25:55 CET] <JEEB> well then tell me if you have /opt/rpi/sysroot/usr/lib/arm-linux-gnueabihf/libgssapi_krb5.so.2 [13:26:11 CET] <JEEB> on the build machine [13:26:47 CET] <luc4> JEEB: -rw-r--r-- 1 root root 233K feb 4 2016 /opt/rpi/sysroot/usr/lib/arm-linux-gnueabihf/libgssapi_krb5.so.2 [13:27:15 CET] <luc4> it is there [13:27:17 CET] <JEEB> alright, so your lovely toolchain is fscking things up for some reason :) [13:27:33 CET] <JEEB> if it can find the ssh lib there, but not look for the gssapi one [13:28:32 CET] <luc4> JEEB: I had situations like this other times, and the solution was to, in fact, set a rpath [13:29:09 CET] <luc4> JEEB: https://paste.kde.org/pt9ejv2cy [13:29:17 CET] <luc4> here I set rpath manually [13:29:41 CET] <luc4> but I see it appears in the compile line and not in the link line [13:29:55 CET] <luc4> do you think that may be the problem? [13:30:48 CET] <JEEB> that's still weird because I would expect a cross-toolchain to just find things in its own sysroot (I've had multiple ARM/x86 cross-compilers and I've not needed rpath) [13:33:06 CET] <JEEB> also both of those calls seem to be just calling the compiler and outputting an object file, so I would say similar thing would be needed for similar results, although I would really check what rpath does and any possibility of you actually doing something "non-standard" (path-wise or otherwise for the cross-toolchain/sysroot) in a way that the library searches would break [13:40:32 CET] <luc4> JEEB: actually I think this cross compiler is not entirely related to the sysroot [13:41:09 CET] <luc4> JEEB: they are not providing a proper toolchain, but this seemed very good and worked with many many other frameworks [13:41:45 CET] <luc4> do you think it is possible to configure so that rpath appears also in the linker command? [13:42:15 CET] <JEEB> well that's why ./configure --help |grep "extra-" [13:46:38 CET] <luc4> JEEB: --extra-ldflags maybe? [13:46:48 CET] <JEEB> that's for linker lines, yes [13:50:05 CET] <Voltasalt> Trying to make a screen recorder using ffmpeg, it's dropping a lot of frames under a relatively simple workload. Any tips on tuning? [13:55:19 CET] <durandal_1707> Voltasalt: what coded? [13:55:52 CET] <Voltasalt> x264 [13:57:25 CET] <durandal_1707> preset? [13:57:30 CET] <Voltasalt> ultrafast [14:01:20 CET] <vlt> Hello. Im using ffmpeg to encode h.264 video. When I use the default settings (no -preset or -profile) a "High" profile video file is created and its playable also on my Samsung TV. When I try to use -preset veryslow that TV doesnt recognize the video format. Any idea what might be the reason? What could I tweak to get smaller file sizes? [14:13:00 CET] <furq> vlt: check the level of the first file and set -level xx when using veryslow [14:13:49 CET] <furq> i forget if level caps bframes but it definitely caps refs [14:52:09 CET] <vlt> furq: -level 4.0 helped [14:52:12 CET] <vlt> Thanks! [14:58:50 CET] <JEEB> furq: it sets refs since bframes are unrelated to memory limiting [17:07:10 CET] <Voltasalt> Is it possible to make ffmpeg output the status updates more often? [17:08:19 CET] <aguardar> loglevel [17:08:47 CET] <Voltasalt> thanks [17:16:39 CET] <Voltasalt> Wait no, loglevel=debug doesn't print more status updates (as in, the ones going frame=xxx time=xxx fps=xxx etc), just prints more internal encoder garbage [17:18:15 CET] <DHE> no, it's hard-coded to aim for 1/2 second intervals. see print_report() in ffmpeg.c [17:18:20 CET] <Voltasalt> dang [18:00:59 CET] <thebombzen> Voltasalt: if you build ffmpeg yourself you can change that [19:52:32 CET] <Tatsh> confused by this message [19:52:32 CET] <Tatsh> [Parsed_pan_0 @ 0x2366f20] This syntax is deprecated. Use '|' to separate the list items. [19:52:44 CET] <Tatsh> from -af pan=1:c0=c0 [19:53:24 CET] <c_14> use | instead of : [19:53:28 CET] <durandal_1707> its self explanatory [19:53:54 CET] <c_14> https://ffmpeg.org/ffmpeg-filters.html#pan [19:54:46 CET] <Tatsh> oh [20:25:07 CET] <DHE> also use quotes or backslashes so your shell doesn't interpret pipes for itself [20:31:58 CET] <Tatsh> yea [20:32:03 CET] <Tatsh> so analyzeduration works wonders [20:32:35 CET] <Tatsh> on cut h264 streams i get 'unspecified pixel format' a lot [21:58:49 CET] <ldiamond> I have a MP4 taken from an android phone which I want to use in Blender for video editing. mediainfo says it's variable framerate, not sure it actually is, but the framerate on blender is 60000/1001 (59.94fps) so the imported video doesn't play properly (it's faster on the video). [21:59:11 CET] <ldiamond> I assume I need to convert the android mp4 to a 59.94fps video. [22:22:52 CET] <jarkko> has anyone solved this issue? http://www.makemkv.com/forum2/viewtopic.php?f=3&t=224 [22:23:13 CET] <jarkko> makemkv doesnt find up to date libavcodec [22:27:42 CET] <JEEB> if they utilize old APIs then their configure check probably doesn't catch it [22:32:29 CET] <Rickky> Hi guys, I'm trying to compile ffmpeg on Debian. I keep getting "ERROR: librtmp not found using pkg-config" in my configure.log. I'm a bit stuck as I confirmed librtmp to be present in /usr/lib/x86_64-linux-gnu/librtmp.so. Even while it's in a default path, I've included the dir explicitly in the pkg config path. "pkg-config --exists --print-errors librtmp" is also pretty silent (= ok afaik). [22:33:06 CET] <JEEB> Rickky: do you have the -dev package installed for it? [22:33:32 CET] <JEEB> also do note that libavformat now has an internal RTMP(E) protocol handler, so librtmp is not necessarily required unless something specifically doesn't work with the libavformat one [22:35:12 CET] <Rickky> JEEB: Yup, apt-get install librtmp-dev [22:35:59 CET] <Rickky> JEEB: I'm not sure about libavformat tbh -- ./configure keeps complaining about librtmp [22:37:00 CET] <JEEB> post your config.log on pastebin or so [22:37:03 CET] <JEEB> and link here [22:37:16 CET] <Rickky> JEEB: Sure, hang on [22:37:17 CET] <JEEB> also librtmp is one of those things that you have to specifically enable in the configuration [22:37:28 CET] <JEEB> while the libavformat one is always built unless you specifically disable it [22:37:49 CET] <JEEB> so effectively if you build with librtmp and the internal one enabled, you have two things handling rtmp protocol :P [22:38:31 CET] <JEEB> so if you don't know why you are enabling librtmp specifically, try building without it and see if it works. because it should unless there's a bug in the libavformat one [22:40:27 CET] <Rickky> JEEB: http://pastebin.com/raw/zbNsLavu [22:41:01 CET] <JEEB> so yes, you are trying to enable librtmp specifically on your command line [22:41:26 CET] <Rickky> Yeah I just realized that as well -- so while I do need rtmp that's actually not needed I take from your earlier message [22:41:41 CET] <JEEB> yea, unless there's a bug in the libavformat one [22:42:00 CET] <Rickky> Out of curiousity, why does it fail anyway? [22:42:01 CET] <JEEB> also the reason for librtmp not getting found is actually simple it seems :P [22:42:03 CET] <Rickky> The lib is there for sure [22:42:04 CET] <JEEB> gcc: error: unrecognized command line option '-R' [22:42:17 CET] <Rickky> lol [22:42:21 CET] <JEEB> -L/usr/lib/x86_64-linux-gnu -R/usr/lib/x86_64-linux-gnu [22:42:27 CET] <JEEB> wherever that came from [22:42:47 CET] <Rickky> That's the dir where apt installed librtmp into... [22:42:57 CET] <JEEB> yes, but I have no idea what -R is :P [22:43:04 CET] <JEEB> but it seems like the pkg-config file might contain that [22:43:20 CET] <JEEB> in which case it would be a boog [22:43:28 CET] <Rickky> Let me just try without librtmp then, if av already provides an rtmp handler [22:43:30 CET] <JEEB> (in debian's librtmp thing) [22:43:34 CET] <JEEB> yea [22:44:15 CET] <Rickky> Seems to pass, sort of, ERROR: libvpx decoder version must be >=0.9.1 [22:44:18 CET] <Rickky> On to the next error :D [22:45:35 CET] <JEEB> as a quick hint I recommend you just enable the exact stuff that you specifically need [22:46:11 CET] <JEEB> especially if you're trying to keep to what's in likely by now ancient debian's repositories [22:46:32 CET] <Rickky> JEEB: Yeah I already omitted some stuff I didn't need. librtmp was one I did specifically needed for my usecase [22:46:52 CET] <Rickky> The others... copy and pasting from a ffmpeg installation I know works as I need it [22:47:13 CET] <Rickky> But it's failing on openssl now as well for example, removing that one now as well indeed [22:47:37 CET] <JEEB> openssl or gnutls is needed for HTTPS [22:47:42 CET] <JEEB> and RTMPE, I think? [22:47:55 CET] <Rickky> I understand, but I'm not pushing over an encrypted endpoint for now [22:47:58 CET] <JEEB> ok [22:48:46 CET] <Rickky> yup, it got through configure. make running now [22:48:51 CET] <Rickky> ... for the next 30 mins probably [22:49:50 CET] <Rickky> JEEB: I was running in a working docker container first, but I got stuck with fontconfig issues with drawtext, so somewhat against my will I'm compiling it manually myself now [22:50:24 CET] <JEEB> do note that anything configured with enable-nonfree is not OK to distribute [22:50:47 CET] <Rickky> JEEB: completely fine, this is for own use, not re-distribution [22:50:53 CET] <JEEB> k [22:51:00 CET] <Rickky> thx for the pointers though :) [22:51:08 CET] <JEEB> also thank goodness for the internal AAC encoder getting useful [22:51:25 CET] <JEEB> because fdk-aac is pretty much the only real reason to build with enable-nonfree [22:51:51 CET] <Rickky> exact reason why I'm running nonfree [22:52:43 CET] <Rickky> JEEB: out of curiousity, have you ever run ffmpeg continously as a stream encoder? [22:53:06 CET] <JEEB> yes, but I would really recommend making a thing with libavformat/avcodec for it [22:53:09 CET] <Rickky> e.g. continous stream for consecutive hours / non batch/file based processing [22:53:23 CET] <JEEB> you end up with having to deal with ffmpeg.c bullshit which will eat you inside [22:53:41 CET] <JEEB> (granted, it's scary how far you can get with just ffmpeg.c) [22:54:05 CET] <Rickky> You mean omitting ffmpeg all together? [22:54:18 CET] <JEEB> ffmpeg.c, yes. but using FFmpeg's libraries [22:54:52 CET] <Rickky> yeah I'm not experienced enough with this to use libavformat/codec directly [22:55:18 CET] <JEEB> also ffmpeg.c really does lack some things with regards to broadcast [22:55:38 CET] <JEEB> although partially due to how for example the mpeg-ts demuxer handles some things [22:57:19 CET] <Rickky> Not really sure what you mean with difference between ffmpeg as a bin and ffmpeg.c tbh -- not a C dev [22:57:36 CET] <Rickky> I'm not writing any code, just using ffmpeg bin [22:58:58 CET] <JEEB> ffmpeg.c is the command line ffmpeg application [22:59:15 CET] <JEEB> the project is called FFmpeg and while some people understand the difference I usually end up talking about the cli application as ffmpeg.c [22:59:18 CET] <JEEB> to differentiate [22:59:41 CET] <JEEB> because quite literally a fuckload of the bullshit is in ffmpeg.c [23:00:55 CET] <Rickky> JEEB: yeah okay just making sure, I'm indeed using the command line binary ffmpeg.c then yeah [23:01:42 CET] <Rickky> I've used ffmpeg for pretty straight forward stuff, but now first time really digging into it trying to generate real time overlays and such on input stream and outputting it again as a stream too [23:01:57 CET] <Rickky> First thing I've noticed is how _much stuff_ you can do through ffmpeg.c indeed [23:02:02 CET] <Rickky> endless amount of params [23:02:05 CET] <JEEB> yes [23:02:18 CET] <JEEB> that's one of the good and bad things, because those things can and will end up having limitaitons [23:02:44 CET] <JEEB> plus, then you have various hacks for various cases that happened N years ago, and nobody knows if they're still required. usually for broken input [23:03:03 CET] <Rickky> story of any monolithic, old, app [23:03:10 CET] <JEEB> yup [23:03:15 CET] <Rickky> I face this shit day to day at work [23:04:18 CET] <JEEB> which is why usually for some use cases, of which live broadcast is one, I would just recommend making a limited tool with the APIs provided. there's examples under docs/examples, even [23:04:32 CET] <Rickky> I'm afraid compiling is still going to take a while... It's just at libswscale [23:04:38 CET] <JEEB> but yes, you can get scary far [23:04:40 CET] <Rickky> Only using 50% cpu unfortunately as well [23:04:41 CET] <JEEB> with just ffmpeg.c [23:04:50 CET] <JEEB> didn't put enough -j into your make :P [23:04:56 CET] <Rickky> :p [23:05:02 CET] <Rickky> so you mean basically forking ffmpeg.c? [23:05:05 CET] <JEEB> no [23:05:25 CET] <JEEB> I mean, in theory ffmpeg.c could even be in its own repo, the libraries are just something it utilizes [23:05:37 CET] <Rickky> ah like that [23:05:39 CET] <Rickky> yeah definitely [23:06:02 CET] <Rickky> it seems unnecessarily coupled [23:06:10 CET] <JEEB> so you just make a limited, meant for something specifically kind of app [23:06:10 CET] <Rickky> but I haven't looked at the internals that much [23:06:20 CET] <JEEB> usually that works even better than ffmpeg.c :D [23:06:26 CET] <Rickky> hehe [23:06:39 CET] <Rickky> For starters I'm eager to get this proof of concept running [23:06:43 CET] <JEEB> yea [23:07:09 CET] <JEEB> the problem is if that ends up being the end product and then you're stuck with ffmpeg.c. which will work for a while but will sooner or later start pulling your speed down [23:07:26 CET] <Rickky> tbh for this use case it's not that much of an issue [23:07:35 CET] <Rickky> if this end up working, it wouldn't become a redistributable app anyway [23:07:42 CET] <Rickky> more to server internal purposes with a single use case [23:07:50 CET] <Rickky> not like it's going to become a product [23:07:59 CET] <Rickky> but I get what you're saying, but ymmv [23:08:05 CET] <JEEB> indeed [23:08:35 CET] <Rickky> ah, compile is done already [23:08:46 CET] <Rickky> This is weird to say but I'm only now realizing how much I miss IRC [23:08:56 CET] <JEEB> :) [23:08:57 CET] <Rickky> I used to hang around all day long in tons of chatrooms and communities [23:09:15 CET] <Rickky> When I started at this job almost 4 years ago IRC was blocked and it kind of faded away in my routine [23:09:29 CET] <Rickky> But I just realized I miss it :) [23:22:27 CET] <Rickky> JEEB: stream --> stream remotely over mpeg1 is _really_ laggy [23:22:36 CET] <Rickky> audio dropping, frames dropping etc. [23:31:35 CET] <jarkko> when i run .configure what file i need to start looking for that could have this text "configure: error: The libavcodec library is too old. Please get a recent one from http://www.ffmpeg.org" ? [23:31:58 CET] <jarkko> i need to just disable the version check and it could work [23:32:02 CET] <JEEB> that is the configure script you're running [23:32:10 CET] <JEEB> and no, it is likely testing for APIs [23:32:12 CET] <JEEB> which might be old [23:32:29 CET] <JEEB> but you might want to check config.log if that third party thing has that for specifics [23:36:36 CET] <jarkko> frustfrating, it worked around 2-3 versions ago [23:37:12 CET] <JEEB> find out what it is and report upstream [23:41:13 CET] <jarkko> hmm actually that configure might be right [23:41:21 CET] <jarkko> libavcodec-dev_7%3a2.8.11-0ubuntu0.16.04.1_amd64.deb [23:41:51 CET] <jarkko> googling that gave filename ffmpeg56_ [23:42:02 CET] <jarkko> and i think that configure needs 57 [23:42:35 CET] <JEEB> weren't you supposed to have your own built and setting PKG_CONFIG_PATH to the install prefix of your copy :P [23:42:47 CET] <JEEB> also learn to look into actual logs [23:43:00 CET] <JEEB> config.log in case of configuration issues for anything having a configure script [23:43:26 CET] <jarkko> JEEB: it didnt work any better [23:44:23 CET] <JEEB> and since this has nothing to do with upstream FFmpeg, please move on to #makemkv or some other media which the makemkv folks are running [00:00:00 CET] --- Sun Mar 12 2017

1 0