Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

March 2016

1 participants
62 discussions

ffmpeg-devel.log.20160310
by burek 11 Mar '16

11 Mar '16

[00:31:24 CET] <cone-909> ffmpeg 03Mats Peterson 07master:caeed0479fca: lavf/avidec: Skip xxpc entries in index; fixes trac #5311 [01:59:04 CET] <Timothy_Gu> So what's the reason why some hwaccels are AVHWAccel and some have decoders? [01:59:19 CET] <Timothy_Gu> like VAAPI is an AVHWAccel but MediaCodec is a decoder [02:19:13 CET] <rukhsana> hi [03:36:51 CET] <cone-966> ffmpeg 03Michael Niedermayer 07master:689211d57272: avformat/concatdec: set safe mode to enabled instead of auto [04:48:47 CET] <philipl_> Timothy_Gu: I think it depends on what level the underlying library works at. Some of them consume the entire bitstream and don't require any parsing. For those, it makes sense to just write a decoder. For the ones that require metadata parsing, then HWAccel makes sense with the hooks into the regular decoder. [04:49:10 CET] <rcombs> (VideoToolbox would make more sense as a decoder but was implemented as a HWAccel because ?????) [04:49:25 CET] <philipl_> MediaCodec is a full decode api so that's not a surprise. The one I did was CrystalHD where the library did full bitstream parsing [04:49:29 CET] <philipl_> Can't speak to VTB [05:11:59 CET] <rcombs> philipl: VTB does full bitstream parsing [05:12:26 CET] <rcombs> there's awkward code in lavc to regenerate the bits of the bitstream that aren't provided to hwaccels for it [05:12:33 CET] <rcombs> apparently it's& not especially stable [05:53:44 CET] <philipl> rcombs: ugly [05:58:24 CET] <Timothy_Gu> ok [08:58:22 CET] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20160310021753&slot=x86_64-archlinux… [09:35:10 CET] <mateo`_> Timothy_Gu: for MediaCodec, you can't expect the API to get one output for one input; it does not fit to be an hwaccel of the h264 decoder, this is why it has its own decoder and it will gain "soon" its own hwaccel. [09:37:28 CET] <wm4> Timothy_Gu: it's worth noting that a AVHwaccel struct is required to use a hw pixfmt [09:37:38 CET] <wm4> because libavcodec/utils.c forces it so [09:38:25 CET] <wm4> so that struct and the concept of slice hwaccels as the lavc native h264 decoder uses it are a bit distinct [09:45:31 CET] <nevcairiel> mateo`_: what good is a hwaccel if it doesnt actually behave like a hwaccel, like you said yourself :D [09:48:48 CET] <mateo`_> nevcairiel: it can't be an hwaccel of the h264 decoder [09:52:05 CET] <mateo`_> because the h264 decoder expect to get a frame when you submitted all the frame slices [09:54:00 CET] <mateo`_> so it makes perfect sense for mediacodec to have its own decoder with CODEC_CAP_DELAY (and have its own hwaccel to support surface output) [09:54:06 CET] <cone-319> ffmpeg 03Carl Eugen Hoyos 07master:cb3f99e4d3f8: version.sh: Fix spurious rebuilds. [10:01:37 CET] <cone-319> ffmpeg 03Carl Eugen Hoyos 07master:ac1974652b9c: lavf/mxfdec: Support Canopus codecs. [10:55:51 CET] <wm4> wbs: why is 9a7dc618c50902e7a171f2deda6430d52c277a95 applied for decoding [10:56:08 CET] <wm4> insanity [11:24:42 CET] <wbs> wm4: I suppose it should only be done for encoding, sure [11:51:53 CET] <BtbN> hm, I kind of feel like writing a generic GLSL filter/source, like shadertoy [11:53:59 CET] <ubitux> iq didn't release it's weird live editor? [11:54:05 CET] <ubitux> s/it's/his/ [11:54:28 CET] <BtbN> hm? [11:55:37 CET] <ubitux> Inigo Quilez, the guy who won so many demo parties, and who actually made shadertoy (look for "iq" on it) [11:55:50 CET] <ubitux> he wrote some kind of live editor, which you see using in some of his vids [11:56:14 CET] <ubitux> https://www.youtube.com/watch?v=y8aL4Cnb9m4 [11:56:27 CET] <BtbN> Primarily thinking about GLSL based filtering though, the audio/video source would just be another possible use [11:57:19 CET] <ubitux> well i guess he moved to shadertoy at some point [12:11:11 CET] <wm4> would that read back to CPU memory? [12:19:03 CET] <wbs> on the topic of intrinsics vs asm, the tricky thing about intrinsics is that the compiler can only use them if you build with enough -msse flags, and that means that the compiler is allowed to use such instructions anywhere, not just within the intrinsics part. so effectively, it's hard to sensibly do runtime detected features [12:19:25 CET] <nevcairiel> gcc has some crazy attribute flags to enable them [12:19:29 CET] <wbs> oh [12:19:34 CET] <nevcairiel> although i dont know if that works on per-function or only per-file [12:19:53 CET] <nevcairiel> i prefer the msvc way where they just work without weird flags [12:19:55 CET] <JEEB> yeah, you basically would have to separate them per file if not per function [12:20:16 CET] <ismail> gcc ifuncs? [12:20:23 CET] <ismail> hmm no [12:21:24 CET] <nevcairiel> apparently since gcc 4.8 you can specify it per-function [12:21:33 CET] <ismail> target attribute I guess [12:21:36 CET] <ismail> it works for clang too [12:21:49 CET] <nevcairiel> although according to the docs, gcc is supposed to pick the appropriate variant by itself [12:21:51 CET] <nevcairiel> which sounds weird [12:22:31 CET] <ismail> https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html target section. [12:24:46 CET] <nevcairiel> anyway, i still think using yasm code has more advantages that outweigh the "i cba to learn how to do it" argument [12:33:25 CET] <BtbN> wm4, yeah, kind of like the OpenCL based filters already do [12:33:46 CET] <BtbN> An OpenGL PIX_FMT would be possible though, but that's not something i planned to do [12:34:06 CET] <wm4> passing GL textures would be nasty [12:34:25 CET] <wm4> because it somehow needs a cooperating context [12:34:46 CET] <wm4> in fact, just a filter creating a GL context would be nasty (what if the API user also uses GL) [12:35:33 CET] <BtbN> could be put in a thread to prevent breakage in client applications [12:36:12 CET] <wm4> just to isolate the state? [12:36:54 CET] <BtbN> To isolate the active context, and not override a potential context that's active in the application using lavf [12:39:33 CET] <BtbN> The biggest problem I see is the context creation itself. It works fundamentaly diffrent on every platform [14:37:23 CET] <BBB> Timothy_Gu: decoders is old model, avhwaccel is new model [14:37:31 CET] <BBB> Timothy_Gu: consider hw decoders deprecated in favour of avhwaccel [14:37:36 CET] <wm4> BBB: not true [14:37:41 CET] <wm4> at all [14:37:44 CET] <BBB> :( [14:37:54 CET] <wm4> you evne mix concepts [14:38:13 CET] <wm4> the AVHWAccel struct is just a meaningless helper [14:38:35 CET] <wm4> it's for listing hwaccel support, and somehow libavcodec/utils.c uses it to exclude hw pixfmts if they're not used [14:39:09 CET] <BBB> well why dont you explain it then, not to me but to him [14:39:12 CET] <wm4> the hwaccels like vdpau and vaapi are actual hwaccels which built upon a software decoder and accelerate it by grabbing certain entrypoints [14:39:37 CET] <wm4> (they're called slice decoders, and you need to do significant bitstream parsing etc. to use them) [14:40:09 CET] <wm4> and then there are full bitstream hw decoders - these have their own AVCodec (and also a AVHWAccel to make utils.c happy at least) [14:40:17 CET] <wm4> like qsv and mmal [14:41:07 CET] <wm4> and then we have a very old thing, the vdpau hw decoder, which is a slice decoder and actually uses the h264 decoder to do some work, and this thing has been deprecated for years [14:55:32 CET] <durandal_1707> Isn't that Carl thing? [14:58:21 CET] <BBB> I believe so, yes [14:58:27 CET] <kierank> bloody carl [14:58:34 CET] <BBB> my mplayer build from 1988 uses it" [14:58:44 CET] <BBB> it works, why break it" [14:59:00 CET] <BBB> and now someone wants intrinsics [14:59:48 CET] <wm4> what a terrible world to live in [15:00:52 CET] <BBB> at least this one I have voting rights in [15:01:38 CET] <wm4> so can someone remove the old vdpau decoder [15:02:04 CET] <BBB> carl has blocked that every single time, no? [15:02:25 CET] <Daemon404> >carl [15:02:32 CET] <Daemon404> vote, he can fuck himself [15:02:36 CET] <Daemon404> sorry for the poor language [15:02:39 CET] <Daemon404> my carl patience is long gone [15:02:57 CET] <kierank> he is the cancer of this project [15:03:10 CET] <kierank> but has too many neckbeard supporters [15:03:24 CET] <ismail> wow slow down :) thats some really bad language there. [15:03:37 CET] <Daemon404> ismail, try dealing with carl for years and come back [15:03:38 CET] <ismail> <-- not a Carl fan [15:03:47 CET] <wm4> I guess too many people have run out of patience [15:03:49 CET] <Daemon404> or alternatively [15:03:54 CET] <ismail> I remember having weird mails from him after libav fork [15:03:58 CET] <Daemon404> recieve some hate male to your personal email fro mcarl [15:04:01 CET] <Daemon404> like many of us have [15:04:06 CET] <ismail> I did so too :) [15:04:07 CET] <kierank> Hello! [15:04:11 CET] <kierank> you are a liar and a thief [15:04:15 CET] <ismail> lol [15:04:17 CET] <ismail> indeed [15:04:33 CET] <ismail> He thought libav guys were paying me to put libav in openSUSE [15:04:37 CET] <ismail> weird guy [15:04:40 CET] <Daemon404> lolwut [15:05:07 CET] <ismail> kierank: at least he greets properly [15:24:18 CET] <durandal_1707> ismail: who paid you then? [15:36:20 CET] <BtbN> why does the mfx encoder have a huge bunch of binary arrays? [15:36:43 CET] <Daemon404> because mxf is sadness [15:36:46 CET] <Daemon404> theyre probably uuids [15:37:17 CET] <BtbN> no, carl just send a patch that modified one of them [15:38:07 CET] <rcombs> because nobody knows if it's spelled mfx or mxf off the top of their head [15:38:15 CET] <rcombs> (might help if anyone knew what it stood for) [15:38:36 CET] <Daemon404> BtbN, looks like he added it brokenly originally [15:39:02 CET] <wm4> rcombs: they're different things [15:39:15 CET] <rcombs> wm4: also doesn't help [15:39:37 CET] <rcombs> (I don't remember which is which _and_ don't know which either stands for) [15:39:39 CET] <Gramner> ugh intrinsics. let's not create a soup of various "languages" that does essentially the same thing but in completely different ways. I'm also no fan of intrinsics "functions" with super-long names that's often very different from the instructions they map to [15:39:56 CET] Action: Daemon404 clobbers Gramner's registers [15:40:06 CET] <mateo`_> rcombs: hahahaha, I had this confusion first time I saw the "mfx" decoder, I was like what the ... [15:40:17 CET] <rcombs> one's a container used in cinema and the other's a weird intel hwaccel binary blob thing [15:40:39 CET] <ubitux> 3 letters combinations are causing too much confusion, we should stick with 1-letter naming [15:40:39 CET] <Gramner> e.g. _mm_cvtsi64x_si128 vs movq [15:41:35 CET] <durandal_1707> what? [15:43:13 CET] <rcombs> convert signed integer 64-bit (x?) to signed integer 128-bit? [15:43:27 CET] <rcombs> I guess because movq to an SSE register clears the upper half? [15:44:18 CET] <Gramner> "convert unsigned 64-bit int to unsigned 128-bit int" would be more accurate. but "convert" is a weird description for a move [15:44:42 CET] <rcombs> what's the `si` stand for then [15:44:44 CET] <Gramner> "si" means "unsigned integer" i guess [15:44:47 CET] <rcombs> :| [15:44:57 CET] <jkqxz> Not that I really disagree, but that's cherry-picking pretty much the worst possible example. (Half the time you can't even generate the movq you want in intrinsics at all.) [15:48:19 CET] <nevcairiel> _mm_cvtsi64x_si128 is for signed values, it takes an __int64 afterall, they use i and u for signed and unsigned [15:48:55 CET] <nevcairiel> i forgot what the s specifically was for [15:48:59 CET] <Gramner> there's also _mm_cvtsi64_si128 which "copies a 64-bit integer into a 128-bit parameter" unlike _mm_cvtsi64x_si128 that "copies a 64-bit value to a __m128i structure" [15:49:37 CET] <nevcairiel> who defined those names anyway, Intel? [15:49:42 CET] <Gramner> no idea [15:49:42 CET] <J_Darnley> Perhaps someone would like to show how to use our existing *aligned* constants without loading them into a register [15:49:58 CET] <J_Darnley> particularly pb_0 [15:51:20 CET] <J_Darnley> That is my second biggest gripe after the names. [15:53:58 CET] <nevcairiel> if the instruction in question can read from memory, then just reference them? [15:55:09 CET] <nevcairiel> its used in some functions like this, ie. paddsb m2, [pb_4] [15:56:11 CET] <jkqxz> (I remember banging my head against movq specifically when forced to write some stuff in intrinsics a few years ago. As long as you never need to touch memory, intrinsics are basically fine. Once you do, making the compiler do something more sensible than a load of single-word transfers is an immense pain. And NEON is (was?) even worse.) [15:57:05 CET] <J_Darnley> I have tried "just referencing them" in my own project and gcc bitched about types or incompatible something else [15:57:22 CET] <J_Darnley> The assembler doesn't care about types. If the linker can resolve the location of pb_4 then it will work. [15:57:36 CET] <nevcairiel> so you are trying to use them outside of asm? [15:57:46 CET] <jkqxz> -flax-vector-conversions [15:57:55 CET] <J_Darnley> Yes. Intrisics. Like the guy here is trying to sell us on. [15:58:19 CET] <nevcairiel> cast to __m128i* ? :d [15:59:30 CET] <nevcairiel> no idea though, those constants were not designed for such use [16:04:12 CET] <jkqxz> Explicit load intrinsics like _mm_load_si128((__m128i*)pb_0) will work. Normal assignment may not. [16:04:36 CET] <Daemon404> why are we even discussing this [16:05:14 CET] <Gramner> intrinsics are nice if you have an existing c/c++ project with no asm and just need to add SIMD to one or a few functions because it's easy to get it going, with yasm you need to set up the build environment etc. but that's a moot point in ffmpeg's case since all of that is done and works [16:07:26 CET] <rcombs> I've seen people argue it's better for NEON because you can easily share between armv7 and armv8 [16:07:54 CET] <rcombs> which reminds me that someone needs to put together a set of as macros for that [16:09:36 CET] <wm4> why is there no pixdesc function that returns how many bytes per pixels there are on a plane [16:10:19 CET] <Daemon404> you can derive it from the pixdesc itself [16:10:23 CET] <Daemon404> i suppose. [16:10:38 CET] <wm4> yes after destroying a wall with your head [16:10:46 CET] <wm4> because it's that simple [16:11:14 CET] <Daemon404> stuff liek android has the concept of "pixel stride" iirc [16:11:20 CET] <Daemon404> i assume this is why you want t [16:11:21 CET] <Daemon404> it [16:11:35 CET] <wm4> not really [16:11:48 CET] <wm4> but yes sounds equivalent [16:15:38 CET] <rcombs> wm4: AVComponentDescriptor.step? [16:16:18 CET] <rcombs> or, well, more complex if you're non- or semi-planar [16:16:37 CET] <durandal_1707> there's function to get pixelstep and than you just multiply [16:16:46 CET] <wm4> actually I've thought maybe it's av_image_fill_max_pixsteps, but I don't understand its doxygen [16:16:48 CET] <rcombs> or if you're subsampling and want to count per pixel instead of per (sub)sample [16:16:59 CET] <rcombs> wm4: what's the context for this? [16:17:39 CET] <wm4> trying to layout microshit surfaces [16:17:52 CET] <rcombs> oh lovely [16:17:58 CET] <wm4> they only have pitch for plane 0 (if you're _really_ lucky, most time you don't have a pitch) [16:18:15 CET] <wm4> so how the fuck do you calculate the pitch for the other planes [16:19:13 CET] <rcombs> so what is this, NV12? [16:19:22 CET] <wm4> there are many supported formats [16:20:41 CET] <rcombs> pitch here meaning step between the start of 2 samples in a component? [16:21:00 CET] <wm4> no, linesize (as ffmpeg calls it) [16:21:11 CET] <Daemon404> so, strode. [16:21:12 CET] <Daemon404> stride [16:21:15 CET] Action: Daemon404 runs [16:24:07 CET] <rcombs> wm4: so it's probably expecting either stride of the chroma planes to be <luma stride / 2> or <width/2, aligned to& something> [16:24:14 CET] <jkqxz> Do any of the formats actually run into that problem? YUV420P can be laid out line-interleaved so that the pitch is the same for all planes. [16:24:28 CET] <wm4> rcombs: that's how it usually is, and that's not the problem [16:24:44 CET] <wm4> I just didn't want to hardcode the shit [16:26:41 CET] <rcombs> what's that got to do with bytes per pixel on a given plane [16:27:43 CET] <wm4> I just thought that'd be a good idea to derive the plane pitch, or maybe not, I've given up on it anyway [16:28:55 CET] <rcombs> are there formats available that have >1 byte per sample? [16:29:20 CET] <wm4> packed yuv and p010 [16:29:34 CET] <rcombs> I mean per component [16:30:00 CET] <wm4> p010 (but you can treat that exactly like nv12) [16:30:16 CET] <rcombs> turns out I have no idea what p010 is [16:30:32 CET] <wm4> 16 bit nv12 [16:30:41 CET] <wm4> or 10 bit padded [16:31:18 CET] <nevcairiel> its what gpus like to use to output 10-bit content [16:32:56 CET] <kierank> silly format [17:45:08 CET] <j-b> mateo`_: wbs: "Android N includes namespace changes to prevent loading of non-public APIs." [17:53:13 CET] <wm4> lol [17:57:29 CET] <mateo`_> j-b: yeah i saw that [17:57:56 CET] <mateo`_> I think I will remove the use of this JniInvocation stuff and only rely on av_jni_set_java_vm [17:59:10 CET] <j-b> mateo`_: yes, I'd say so. [17:59:11 CET] <mateo`_> Also i'm trying to compile FFmpeg for arm with their new ndk using clang3.8 as they said gcc 4.9 is deprecated [17:59:23 CET] <mateo`_> and clang3.8 does not support .altmacro ... [18:00:02 CET] <mateo`_> and we are using it everywhere in the arm code :( [18:01:56 CET] <mateo`_> another note about this new ndk release, android-ndk-r11-linux-x86_64.zip unzip as android-ndk-r11-linux-x86_64.tar.bz2 [18:02:29 CET] <mateo`_> and it's not a bz2 tarball, it's a directory [18:05:40 CET] <rcombs> j-b: are they adding a public way to start the IPC thread pool? [18:07:08 CET] <rcombs> also advising everyone to statically link libcrypto.a [18:07:17 CET] <rcombs> (kek) [18:07:34 CET] <Daemon404> wut [18:07:38 CET] <Gramner> yeah, that seems like such a good idea [18:07:53 CET] <rcombs> "Use of SSL_ctrl symbol from libcrypto.so should be replaced with an app local version. For example, you should statically link libcyrpto.a in your .so file or include your own dynamically libcrypto.so from BoringSSL or OpenSSL in your app." [18:07:58 CET] <Daemon404> but it's boringssl! google assures me it will never have a secuerity issue! [18:08:01 CET] <Gramner> because everyone obviosuly keeps their statically linked crypto libs up to date [18:08:19 CET] <rcombs> https://developer.android.com/preview/behavior-changes.html#ndk [18:09:30 CET] <mateo`_> https://www.reddit.com/r/androiddev/comments/49qup4/ndk_r11_release_is_live/ (there are some useful comments about the situation of their new ndk release) [18:09:39 CET] <Daemon404> rcombs, i also like how it's broken english [18:09:59 CET] <rcombs> Daemon404: libcyrpto.a is my favorite static archive [18:12:30 CET] <Daemon404> yes [18:17:25 CET] <Daemon404> rcombs, also when you link your own libcrypto, its now gpl violating [18:17:30 CET] <Daemon404> since it is no longer a system library [18:17:44 CET] <rcombs> Daemon404: assuming your app is GPL, yeah [18:17:53 CET] <Daemon404> see: vlc [18:18:05 CET] <Daemon404> well, lgpl [18:18:09 CET] <rcombs> GNUTLS to the rescue [18:18:15 CET] <cone-066> ffmpeg 03Matthieu Bouron 07master:8d0a21805820: lavc/ffjni: fix uninitialized variable [18:18:21 CET] <rcombs> ETA on that OpenSSL Apache 2.0 relicense? [18:18:53 CET] <Daemon404> never [18:19:07 CET] <Daemon404> for hysterical raisins [18:19:09 CET] <Daemon404> (ssleay) [18:19:10 CET] <rcombs> they said it was happening but yeah seems& difficult [18:19:30 CET] <rcombs> what does eay actually have to say on the topic [18:19:40 CET] <Daemon404> i dont know [18:24:12 CET] <Zeranoe> Does anyone have experience debugging FFmpeg on Windows with GDB? [18:30:32 CET] <JEEB> for me it worked like everywhere else [18:30:37 CET] <JEEB> gdb ffmpeg.exe [18:30:43 CET] <JEEB> > shows it loaded symbols [18:30:48 CET] <JEEB> run muh params [18:30:53 CET] <JEEB> > wait for crash [18:30:56 CET] <JEEB> bt full [18:30:57 CET] <Zeranoe> Just trying a simple "start" and I get "Cannot insert breakpoint 1." "Cannot access memory at address 0x140e0bd20". Everything works find on an old build (2.8.6) but git always does that error [18:31:10 CET] <Zeranoe> fine* [18:33:29 CET] <Zeranoe> Both versions built the same exact way with the same toolchain [18:34:28 CET] <nevcairiel> i noticed that something seems to have caused this to break, but i didnt bother to research yet what [18:39:31 CET] <Zeranoe> Would anyone be willing to try and reproduce if I provide the exe with the symbols? JEEB perhaps? [18:41:36 CET] <JEEB> unfortunately I have still work to do :) [18:43:21 CET] <cone-066> ffmpeg 03Carl Eugen Hoyos 07master:bd2cc3c42c0f: lavf/movenc: Fix help output. [18:44:10 CET] <nevcairiel> my gdb crashes the app when i put a breakpoint in, thats fun [18:44:54 CET] <Zeranoe> nevcairiel: Same error? What's your platform? [18:45:20 CET] <nevcairiel> nah it inserts the breakpoint fine, it just crashes when trying to run ffmpeg when i did set a breakpoint [18:46:05 CET] <Zeranoe> Mine wont even start... [18:51:22 CET] <nevcairiel> i should probably fetch a gcc that matches my toolchain more closely [18:53:05 CET] <Zeranoe> I just compiled my own gdb using the same toolchain that built FFmpeg and got the same error [18:53:50 CET] <nevcairiel> maybe i should start doing that, include gdb in my toolchain build [19:01:00 CET] <nevcairiel> with a fixed gdb version i can reproduce the issue though [19:01:06 CET] <nevcairiel> with 2.8 it still worked, with 3.0 its broken [19:01:09 CET] <nevcairiel> lets bisect! [19:03:55 CET] <nevcairiel> way too many commits between 2.8 and 3.0 [19:05:02 CET] <Zeranoe> Yeah there's a ton [19:12:26 CET] <Zeranoe> is there an env variable or something that will cause FFmpeg to break early? [19:13:05 CET] <kierank> eh? [19:13:17 CET] <kierank> break early how [19:13:51 CET] <Zeranoe> Sometimes programs implement a debugger check that triggers a breakpoint if it finds it's being watched [19:15:25 CET] <Zeranoe> I'd like to attach a debugger to a running instance of FFmpeg, but my command doesn't cause FFmpeg to prompt. I could probably do something with -y if there's no way to break otherwise [19:26:12 CET] <nevcairiel> Bisecting: 223 revisions left to test after this (roughly 8 steps) ... zzz [19:26:35 CET] <Zeranoe> nevcairiel: I was just about to get started [19:26:36 CET] <nevcairiel> if only configure wouldnt be that slow on windows [19:26:49 CET] <Zeranoe> nevcairiel: Cross compiling? [19:27:07 CET] <nevcairiel> that would even be slower since it needs far more manual steps =p [19:27:19 CET] <Zeranoe> how? [19:27:43 CET] <Zeranoe> I run Debian in a VM and just copy the compiled exe over [19:27:55 CET] <nevcairiel> see, one extra step, copying [19:28:00 CET] <Zeranoe> lol [19:28:01 CET] <nevcairiel> now i just run a script that does all of it [19:28:12 CET] <nevcairiel> it just takes a while, but i dont need to do anything [19:29:13 CET] <nevcairiel> someone should come up with a special optimized bash version that implements a bunch of this stuff as built-ins so that it has to fork less [19:29:31 CET] <drv> ffsh [19:30:01 CET] <Daemon404> uh, like busybox? [19:30:15 CET] <nevcairiel> something complete enough to run ffmpeg configure =p [19:37:22 CET] <Daemon404> it can [19:37:24 CET] <nevcairiel> really curious what might have broken this [19:37:33 CET] <jamrial> compiling on windows sucks. configure takes ages, gcc trashes my hdd really hard (especially during linking) [19:37:45 CET] <jamrial> ccache doesn't perform as good as on linux [19:37:47 CET] <nevcairiel> i have a ssd, i dont notice that, just configure being slow [19:38:26 CET] <nevcairiel> maybe i should test if busybox is actually any better then [19:38:35 CET] <nevcairiel> who knows if their windows port is as complete [19:39:17 CET] <nevcairiel> (and i never bothered with ccache) [19:44:53 CET] <Compn> jamrial : every time i use mingw on windows it corrupts one of my harddrives :D [19:45:10 CET] <atomnuker> color me impressed, we have a tta encoder and asm for ttadec [19:45:35 CET] <atomnuker> never knew the format had so much attention [19:46:01 CET] <nevcairiel> it doesnt, some people like their pet projects though [19:46:05 CET] <nevcairiel> sounds like something durandal_1707 would do [19:46:15 CET] <jamrial> he did [19:46:44 CET] <nevcairiel> the encoder appears pretty simple from code size [19:46:58 CET] <jamrial> yeah, it's fairly simple compared to other lossless codecs [19:47:32 CET] <nevcairiel> Bisecting: 13 revisions left to test after this (roughly 4 steps) [19:47:38 CET] <nevcairiel> cant it just tell me which these 13 are [19:47:47 CET] <nevcairiel> faster to read them than to make it recompile 4 times =P [19:48:49 CET] <nevcairiel> hm git bisect view apparently [19:49:42 CET] <jamrial> tta is open source and has an official library with a c api. tak is the real fringe lossless codec, being closed source and written in i think pascal [19:50:53 CET] <nevcairiel> configure: Force mingw's ld to keep the reloc section [19:50:56 CET] <nevcairiel> this one, apparently [19:52:53 CET] <nevcairiel> 91b668acd6decec0a6f8d20bf56e2644f96adcb9 [19:53:39 CET] <Zeranoe> Interesting... [19:54:31 CET] <Zeranoe> Makes sense [20:22:06 CET] <J_Darnley> Zeranoe nevcairiel: dash in cygwin runs configure at about twice the speed [20:22:28 CET] <J_Darnley> perhaps there's a msys version [20:22:38 CET] <nevcairiel> i should time various alternatives [20:22:43 CET] <J_Darnley> (or whatever toolchain you're using) [20:26:08 CET] <Zeranoe> I started cross compiling in a VM and I'll never go back. [20:49:53 CET] <Zeranoe> It looks like 4d8f536b535487063a08609636e712ad86d2ad54 breaks QSV for Haswell-DT 4th gen CPUs, or at least mine [20:54:38 CET] <Zeranoe> nevcairiel: Do you need me to do anything to get that gdb issue resolved? [21:10:03 CET] <durandal_1707> anyone saw nice pull request with splendid yasm optimizations? [21:14:00 CET] <Daemon404> ... this one: https://github.com/FFmpeg/FFmpeg/pull/183 ? [21:14:02 CET] <Daemon404> lmao [21:14:40 CET] <wm4> I don't understand why there are dozens of PRs even after I added that "warning" [21:15:05 CET] <wm4> and stupid comments that we should switch to github [21:15:18 CET] <Daemon404> github effect [21:15:27 CET] <Daemon404> the general level of discourse on github is... concerning. [21:16:17 CET] <Daemon404> ... why did i read the comments on your thread [21:16:19 CET] Action: Daemon404 barfs [21:17:14 CET] Action: wm4 hands out barf bags [21:24:59 CET] <cone-066> ffmpeg 03Martin Cracauer 07master:73d1398f0c4c: avutil/channel_layout: AV_CH_LAYOUT_6POINT1_BACK not reachable in parsing [21:37:31 CET] <Compn> do you think people are using github repos as resume fodder? [21:37:40 CET] <Compn> i have over 5 repos on github... :P [21:40:48 CET] <Compn> maybe we need a dev to play github ? [21:41:03 CET] <Daemon404> have you seen the quality of those PRs? [21:41:10 CET] <Daemon404> we're missing nothing of value [22:53:31 CET] <atomnuker> what happens when seeking to the audio samples? [22:53:53 CET] <atomnuker> for example if a codec uses 1024 samples per frame [22:54:14 CET] <atomnuker> and you want to seek to some point in the future which would land you on sample 623 of a frame [22:54:39 CET] <wm4> decode the frame and skip 623 samples? [22:55:07 CET] <atomnuker> ah, ok [22:55:44 CET] <atomnuker> I'm experimenting with huge avctx->frame_size so I was wondering if that had implications on seeking [22:57:07 CET] <cone-066> ffmpeg 03Michael Niedermayer 07master:2540d884f3fd: avutil/random_seed: Add the runtime in cycles of the main loop to the entropy pool [23:00:15 CET] <nevcairiel> seeking is never this accurate anyway, you should consider yourself lucky if it finds the perfect packet to seek to [23:00:41 CET] <Daemon404> depends on the format ;p [23:02:35 CET] <wm4> Daemon404: and the demuxer [23:04:10 CET] <nevcairiel> Daemon404: always fun when people uise idiotic pull requests as bug reports because you disabled the issue functionality, isnt it [23:04:30 CET] <Daemon404> lulz [23:11:32 CET] <Zeranoe> nevcairiel: Shall I submit a bug for the GDB issue? [23:14:49 CET] <nevcairiel> no need [23:20:10 CET] <Zeranoe> Ah, I see http://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/191195.html [23:20:39 CET] <Zeranoe> Thank you [00:00:00 CET] --- Fri Mar 11 2016

1 0

ffmpeg.log.20160310
by burek 11 Mar '16

11 Mar '16

[00:03:10 CET] <roddyr> c_14, is the file available? [00:06:57 CET] <c_14> It should have returned a url which you then paste here. The one you pasted earlier was empty [00:09:05 CET] <roddyr> please try: http://sprunge.us/JeJh [00:09:37 CET] <c_14> still empty, try copy pasting the output into the web form [00:09:48 CET] <roddyr> Ok, http://sprunge.us/GPOK [00:09:57 CET] <c_14> there we go [00:10:05 CET] <c_14> the file has 2 audio streams [00:10:20 CET] <c_14> When creating the file do what kevmitch recommended with -map 0:a -map 1:v [00:13:29 CET] <roddyr> Move from "ffmpeg -i wav -i mp4 -map 0 -map 1 -c:v copy -c:a aac out.mp4" to "ffmpeg -i wav -i mp4 -map 0:a -map 1:v copy -c:a aac out.mp4" or "ffmpeg -i wav -i mp4 -map 0:a -map 1:v out.mp4"? [00:13:54 CET] <c_14> the former [00:36:47 CET] <roddyr> c-14, thank you that did the trick! [00:42:34 CET] <SpaceManiac> Does ffmpeg have any facility for getting an input's metadata in a machine-readable format? [00:42:58 CET] <J_Darnley> ffprobe [00:43:08 CET] <J_Darnley> json, xml, others [00:43:23 CET] <SpaceManiac> the json output option is just the human-readable output wrapped in { and } [00:44:26 CET] <SpaceManiac> on closer inspection, that's stream intermingling... rather, stderr has the human-readable output, and stdout is just {} [00:58:39 CET] <SpaceManiac> should have read docs closer I suppose, discouraged by past-buffer `ffmpeg -h` output and didn't realize I needed extra args to make it actually print anything [01:28:11 CET] <furq> well in case anyone was wondering, the answer is: rm version.sh && touch version.sh && chmod +x version.sh && touch .version [01:33:31 CET] <gzeus> Hello, is it possible to record only one applications audio output (via pulse, most likely, in this case)? [01:35:30 CET] <J_Darnley> Maybe. I guess it depends on what pulse can do. [01:35:43 CET] <gzeus> pulse is... mysterious [01:40:36 CET] <TD-Linux> you need a virtual sink for that application [01:40:51 CET] <TD-Linux> there are some pulse modules that create a virtual output device that you can then capture from [01:43:53 CET] <gzeus> TD-Linux: ah, yes. I've had to do similar things for loopbacks etc. I wish pulse were less obtuse (not sure if that's the right word) to configure, though. I think that'll put me on the right track, thanks. [01:44:57 CET] <furq> obscure [01:45:51 CET] <gzeus> that as well, but it's... clunky. Coming from a sound mixing background it seems 'off' somehow. only able to set something to a single output etc. [01:46:11 CET] <TD-Linux> gzeus, yeah, you would like JACK [01:46:25 CET] <gzeus> well, jack is cool on paper, but setting it up is like _building_ a mixer [01:46:50 CET] <TD-Linux> pulse is intentionally designed this way so that you always have only one clock source [01:47:09 CET] <gzeus> fair enough. specific things for specific purposes [01:47:15 CET] <TD-Linux> though grabbing the output from only one application shouldn't actually affect that constraint [01:47:30 CET] <TD-Linux> in that case it probably just needs code written [01:49:24 CET] <gzeus> I mean, I could, theoretically, build a mixer from a bunch of inputs/outputs or set up a modular synthesizer (which isn't that different) but it would be nice to just have something detect all available sources and outputs and let you manipulate them. qjackctrl seems to be the closest thing. [01:49:33 CET] <gzeus> eh. I think things will improve. [01:50:07 CET] <gzeus> thanks, though [01:52:05 CET] <furq> pro tip of the day: if zscale seems really slow, maybe try remembering to compile it with --enable-x86simd [01:52:28 CET] <TD-Linux> that's not default? [01:52:31 CET] <furq> it would have been nice to remember that before transcoding ~15 hours of video with it [01:52:33 CET] <J_Darnley> Wat? [01:52:34 CET] <furq> and no it isn't [01:52:59 CET] <furq> thank you for making me feel less dumb for not realising [02:35:57 CET] <SpaceManiac> Is -rtbufsize the appropriate option for fixing occasional interruptions decoding from an http:// source? I would think that the 3M default would be large enough... [03:43:33 CET] <avih> hi, i have a crash which i suspect in ffmpeg, but i don't have a reproducible strict ffmpeg case. it manifests in mpv but maybe someone can think of an ffmpeg reason for it. the issue is crash on windows when playing an hevc file with hwdec (dxva2) with --start=NN (i.e. jump to some place at the middle of the file). it doesn't happen with h264 hwdec, and doesn't happen in plain seek - mostly. with plain seeks it happens very very very rarely. [03:43:36 CET] <avih> any idea? [03:45:13 CET] <avih> AFAIK ffplay doesn't support hevc hwdec on windows, and currently also neither ffmpeg.exe. so this leaves me with mpv as the only test case. [03:45:35 CET] <avih> this was reproduced on more than one system with three different mpv builds [03:46:13 CET] <avih> (one built with msys2, two cross from linux but different setups) [03:47:33 CET] <avih> the crash can be reproduced in gdb, but two people tried to get useful stacks and failed. not sure why. printf debugging possibly points to ffmpeg [03:49:31 CET] <J_Darnley> I would suggest filing a bug on trac but *someone* will probably close it for not using ffmpeg. [03:49:46 CET] <J_Darnley> Most ffmpeg are probably asleep now [03:49:51 CET] <J_Darnley> *ffmpeg devs [03:50:13 CET] <J_Darnley> you might want to try contacting again during daytime hours in Europe [03:57:20 CET] <avih> yeah, that's why i didn't file a bug. it's far from a good bug report. will take your advice on trying again later. thanks [04:09:16 CET] <avih> (also, the rare case where it happens on plain seek - only hevc hwdec. not with any other codec hwdec) [04:14:59 CET] <avih> (and not with hevc swdec) [04:28:43 CET] <needmorespeed> In FFmpeg 2.7, MMAL acceleration was added (MMAL-accelerated H.264 decoding) - does this have to be compiled in with configure flags? [04:29:14 CET] <needmorespeed> or is it enabled by default [04:31:57 CET] <J_Darnley> External libraries usually need enabling [04:32:05 CET] <J_Darnley> also, what does --help say? [05:04:57 CET] <qmr> ffmpeg -i MAH00006.MP4 -vf transpose=2 -crf 28 -c:a copy 1.mp4 <- can someone help me out? want to flip that and squish the video [05:15:36 CET] <J_Darnley> What does "squish" mean? [05:16:25 CET] <J_Darnley> perhaps you arelooking for the scale filter? [05:16:45 CET] <J_Darnley> perhaps you need to know that you chain filters together with a comma [05:18:19 CET] <qmr> squish in size not resolution. preferably something encoded quickly [05:19:14 CET] <J_Darnley> I want to argue that resolution is size [05:19:31 CET] <qmr> You can be pendantic when I'm not in a hurry to show people my awesome video [05:19:36 CET] <J_Darnley> do you want to read this http://trac.ffmpeg.org/wiki/Encode/H.264 [05:19:48 CET] <qmr> my ffmpeg is built without that :9 [05:19:49 CET] <qmr> :( [05:19:58 CET] <J_Darnley> omg [05:20:25 CET] <J_Darnley> then -vcodec mpeg4 and -qscale 4 [05:20:56 CET] <qmr> only 13 FPS :( [05:21:27 CET] <J_Darnley> then you'd better paste the whole output so I can see what you're doing [05:22:31 CET] <J_Darnley> perhaps all the time is eaten by the transpose [05:23:00 CET] <qmr> https://ptpb.pw/zDZu [05:23:12 CET] <J_Darnley> OMFG! [05:23:14 CET] <qmr> is there something quick and dirty and faster than mpeg4? thi si sslow even with high qscale [05:23:20 CET] <J_Darnley> 0.5?! [05:23:36 CET] <J_Darnley> mpeg2? [05:23:40 CET] <J_Darnley> mpeg1? [05:24:36 CET] <J_Darnley> Also I'm not surprised encoding full hd is a little slow [05:25:21 CET] <J_Darnley> you really should update your ffmpeg [05:25:27 CET] <qmr> think going down to 720P would help? [05:25:38 CET] <J_Darnley> Maybe, why not try [05:25:40 CET] <qmr> I'm out of time now I guess. this VPS sucks, I should just get a cheap dedicated box [05:25:56 CET] <J_Darnley> download a static build and run that [05:25:58 CET] <qmr> the source video is just kind of ridic high to stream to my phone [05:26:07 CET] <qmr> k, I'll do that when I get back [05:27:25 CET] <J_Darnley> I wonder how much has changed since then [05:27:39 CET] <J_Darnley> AVX is the obvious standout feature. [05:27:53 CET] <qmr> since when? [05:27:59 CET] <J_Darnley> 2009 [05:28:06 CET] <qmr> oh [05:28:19 CET] <qmr> some hypervisors mask AVX, idk if mine does [05:28:49 CET] <J_Darnley> oh, I guess you'll want -g 250 too [05:29:28 CET] <J_Darnley> I wonder if the x264 improvements had been ported then. [05:30:29 CET] <qmr> anything sustained over 4-8Gs is rather dangerous [05:32:31 CET] <J_Darnley> and I guess I'll go to sleep [05:32:51 CET] <J_Darnley> Thanks for being some light entertainment [08:32:25 CET] <t4nk981> anyone alive this time of night? [08:33:26 CET] <t4nk981> I've got questions about the Omneon MXF format and how it differs with it's SMTPE 426 track [08:33:58 CET] <t4nk981> Basically, got some gear that I recently upgraded to a newer version and now no longer carries captions properly [08:34:11 CET] <t4nk981> I suspect my video gear is looking for embedded 708 captions [08:34:46 CET] <t4nk981> but I also suspect that embedded 708 is depricated in the latest omneon SDK and all ancillary data should be in the smtpe 426 track [08:35:02 CET] <t4nk981> I'm having trouble finding a right combination of settings [08:35:24 CET] <t4nk981> tried FFMPEG, telestream flipfactory 7.5, latest vantage, latest promedia carbon, and WFS 2.0 [08:36:10 CET] <t4nk981> Im hoping someone will pop their head up and has so experience, so I can bounce some ideas and attempts off them. [08:37:11 CET] <t4nk981> lastly, ffmpeg is a great tool and thanks to anyone that helps make it possible. [08:38:12 CET] <t4nk981> methodical at gmail if anyone reads this in logs and is willing to have me bounce ideas off them. [09:13:41 CET] <kgkg> I am trying to forward an IP Camera to youtube but get a "Failed to update header" error. CLI and error: http://pastebin.com/KJX9mZFV [11:56:29 CET] <BAWSTi> Hi there, I'm new to audio manipulation and therefore ffmpeg. I need to transcode some audio files (mp2 to wav + the other way around). That is not the problem. The problem I have is that I also want to transcode those files or rather formats into broadcast wav and from broadcast wav also back to mp2 and wav. Can someone pls help me accomplish that? [12:03:46 CET] <Mavrik> What's a broadcast wav? [12:17:06 CET] <BAWSTi> @Mavrik it's like a part of the wave formats [12:17:33 CET] <BAWSTi> used by radio stations for example [13:47:58 CET] <sopparus> hello [13:48:19 CET] <sopparus> what will happend if I compile ffmpeg without libressl/openssl? [13:48:25 CET] <sopparus> what does ffmpeg use it for? [13:48:40 CET] <sopparus> say I use kodi doesnt curl to the ssl'ing [13:49:21 CET] <J_Darnley> ssl, obviously [13:49:33 CET] <J_Darnley> accessing things over https [13:49:52 CET] <J_Darnley> and probably some of the other protocols have encrypted variants [13:50:02 CET] <sopparus> ok [13:51:06 CET] <J_Darnley> if you are stikcing strictly with local files then you probably have no need for it. [13:52:01 CET] <sopparus> im going to use https [13:52:14 CET] <sopparus> its just that it wouldnt compile with --enable-libressl so I went without it.. :) [13:52:19 CET] <sopparus> ill put some more thought into that then [13:52:44 CET] <J_Darnley> I didn't know we had an option for that yet [13:54:02 CET] <sopparus> this isnt clean ffmpeg but ffmpeg that comes with openelec [13:57:50 CET] <furq> sopparus: you can try with gnutls instead [14:13:27 CET] <sopparus> yeah worked now, thanks [14:33:08 CET] Action: Fyr slaps atomnuker around a bit with a large trout [14:34:58 CET] <TOM22> Hi! I was wondering how i can find out on what device a video is recorded. [14:36:15 CET] <J_Darnley> Read any metadata it may have written [14:38:14 CET] <TOM22> is there some sort of reference data to compare the metadata output with? [14:38:50 CET] <J_Darnley> Not that I know of [14:39:04 CET] <J_Darnley> if it isn't plain text then you are probably SOL [14:41:40 CET] <TOM22> oke thanks, do you recommend a specific type of software to extract everything there is in a file [14:41:56 CET] <J_Darnley> ffmpeg? ffprobe? [14:42:51 CET] <DHE> ffprobe gets most of it [14:47:05 CET] <TOM22> mm not finding something unique, all data is the same. 3 iphones, 1 file sended by whatsapp, which iphone made the recording. [14:57:41 CET] <dystopia_> mediainfo is a good tool for reading the metadate [14:58:02 CET] <dystopia_> open file -> view -> text [15:16:25 CET] <Fyr> JEEB, is it possible that the delay bug I posted will be fixed? [15:16:31 CET] <Fyr> (eventually) [15:16:32 CET] <JEEB> yes [15:16:37 CET] <Fyr> alright [15:16:48 CET] <JEEB> I mean, it's already fixed on the API level [15:17:00 CET] <JEEB> it just has to be fixed on the WAV muxer level or so [15:17:14 CET] <Fyr> i.e. I cat download the fresh copy from Zeranoe? [15:17:16 CET] <JEEB> although now people have noticed that there's like three fields in the API for delays [15:17:25 CET] <JEEB> Fyr: are you an API user? :P [15:17:31 CET] <JEEB> sounds like you're a cli user [15:17:46 CET] <Fyr> ok [15:17:59 CET] <Fyr> maybe, avconv doesn't have such bugs. [15:18:04 CET] <JEEB> oh it does [15:18:21 CET] <JEEB> AFAIK this is a common issue in this muxing logic :P [15:26:41 CET] <Filarius> hello, I making grid from 6 videos, how to mix audio from this 6 videos ? Commandline is here http://pastebin.com/4EyJsceg [15:27:46 CET] <durandal_1707> ,Use amerge and then pan filter [15:27:49 CET] <DHE> Filarius: there's audio filters as well as video filters. might start with looking at amix [15:29:18 CET] <durandal_1707> Filarius: use vstack and hstack instead of overlay and pad [15:37:43 CET] <Filarius> thanks for vstack/hstack, but I will change locations of videos in future [15:40:55 CET] <durandal_1707> how you mean change location? [15:41:17 CET] <J_Darnley> furq: you were having problems with version.sh, perhaps the latest commit can help you. [15:41:44 CET] <J_Darnley> (sorry, second newest) [15:41:50 CET] <Filarius> like add some space to separate videos [15:42:06 CET] <durandal_1707> ah [16:22:35 CET] <furq> J_Darnley: i don't think so [16:23:00 CET] <furq> it's not really an issue that's worth fixing upstream anyway, it's a byproduct of the dumb build system i'm using [16:23:28 CET] <furq> ffversion.h will show the wrong git hash if you remove ffmpeg/.git and are inside another git repo [16:25:08 CET] <furq> the makefile makes it look as though generating ffversion.h and touching .version will prevent version.sh from being run, so if that's intended behaviour then i guess that is broken [16:25:40 CET] <furq> but i worked around it anyway so idc [16:27:13 CET] <J_Darnley> fair enough, i just thought i should bring i to your attention [16:30:25 CET] <Filarius> so, it cannot allocate memory while muxing 6 audio streams, LOL [16:30:38 CET] <Filarius> *mixing [16:31:10 CET] <Filarius> http://pastebin.com/7rneFHmv [16:33:07 CET] <durandal_1707> because amix is shit [16:33:16 CET] <Filarius> suggestion ? [16:34:33 CET] <durandal_1707> amerge+pan [16:34:59 CET] <_Vi> Help for "mp4 muxer AVOptions" look suspicious: list of option value variants is the same after -movflags, -encryption_scheme, -encryption_key and -encryption_kid. [16:39:36 CET] <J_Darnley> that does look wrong [16:42:12 CET] <J_Darnley> If you want to file a proper bug report, use trac [16:42:27 CET] <J_Darnley> alternatively send an email to the ffmpeg-user mailing list [16:45:28 CET] <_Vi> Does FFmpeg have a github repository with issue tracker for easy bug reports? [16:45:58 CET] <J_Darnley> no [16:46:03 CET] <durandal_1707> Trac.ffmpeg.org [16:46:21 CET] <J_Darnley> what he said ^ [16:50:12 CET] <_Vi> https://trac.ffmpeg.org/ticket/5323 [16:51:19 CET] <_Vi> How do I quick-edit typos in Trac? [17:35:54 CET] <ChrisTheNoob> I have compiled ffmpeg from source using the guide on the website. Where can I locate the executable to use? [17:36:35 CET] <Fyr> xD [17:36:49 CET] <Fyr> find . -iname ffmpeg [17:36:50 CET] <Fyr> ? [17:37:37 CET] <kepstin> if you just built it, it's right there in the source tree. If you installed, it, it's in the spot where you installed it to. [17:41:24 CET] <ChrisTheNoob> inside the bin folder is only x265 [18:24:36 CET] <Filarius> do somebody can explain PAN filter parameter "c0<c0+c1", i see "c0+c1" is sum of 1-st and 2-nd audio channels, but what is for "c0 < something" ? [18:27:40 CET] <kepstin> < is the 'less than' operator. it returns 1 if the c0 is less than c0 + c1, and 0 otherwise. The result of that is then used as a gain, where 1 is full volume and 0 is silence. [18:28:42 CET] <kepstin> dunno why exactly you'd use that, but it selects whether to put a channel in the mix depending on whether the other channel is louder, more or less [18:28:52 CET] <kepstin> unless I'm misreading it [18:29:05 CET] <Filarius> i just trying to undertand examples [18:30:08 CET] <Filarius> i need mix stereo from 6 video files to one stereo, and guy from here said to use amerga + pan [18:30:30 CET] <Filarius> *amerge [18:30:44 CET] <kepstin> that's obviously only part of a filter spec to set the gain, it should have some stuff following a '*' sign as well [18:30:59 CET] <kepstin> only part of an "outdef" spec [18:31:19 CET] <Filarius> I did not found any example with '*' [18:32:24 CET] <kepstin> if you have a bunch of stereo files and you simply want them all playing at the same time in out stereo output track, you probably want to just use amix, and maybe do some volume normalization or dynamic range compression after. it would be simpler. [18:32:35 CET] <durandal_1707> Filarius: amix simply divides each channel by 1/6 [18:32:50 CET] <durandal_1707> *multiplies [18:33:26 CET] <durandal_1707> amix can't work in his case for some reason [18:34:58 CET] <kepstin> Filarius: ah, I misunderstood. The < has a special meaning in the pan filter, which is clearly described in the docs. [18:35:12 CET] <Filarius> with amix I have memory allocation error at end of encoding, but seems it is really end of video (all 6 videos must be same time length) [18:35:20 CET] <kepstin> it's not less than at all; it replaces the = but does renormalization. [18:35:31 CET] <durandal_1707> so use 0.166666 *c0 [18:36:06 CET] <Filarius> oh, okay, thanks, english is not my native [18:36:27 CET] <Filarius> I miss that part [18:36:28 CET] <kepstin> if you have a memory allocation error, that's an ffmpeg bug, you should report it... [19:03:50 CET] <nidhoegger> hi. i am currently building ffmpeg 2.7 on the raspberry pi. I need shared libraries, so I added the options --enable-shared and --enable-pic [19:04:00 CET] <nidhoegger> but the compilation still fails complaining I should use -fPIC [19:04:08 CET] <nidhoegger> is that a known issue or/and is there a workaround? [19:05:02 CET] <JEEB> it means that one of your dependencies you're building against has no PIC [19:05:09 CET] <JEEB> most probably something static [19:05:18 CET] <nidhoegger> there should be nothing static... [19:05:49 CET] <JEEB> pastebin your error? [19:05:59 CET] <nidhoegger> the only thing I build myself is x264 from the videolan repo using shared and pic also [19:06:55 CET] <nidhoegger> ./configure --arch=armel --target-os=linux --enable-gpl --enable-libx264 --enable-nonfree --enable-shared --enable-pic --enable-nonfree --prefix=/usr [19:06:58 CET] <nidhoegger> this is the configure line [19:07:28 CET] <JEEB> having enable-nonfree with that configuration makes no sense :P [19:07:39 CET] <JEEB> it enables exactly zero things [19:07:43 CET] <nidhoegger> :) [19:07:49 CET] <nidhoegger> then ill remove it, thx [19:08:27 CET] <JEEB> also if you are compiling on the rpi itself you most probably don't require arch, target-os [19:08:47 CET] <JEEB> anyways, pastebin your error when you get to it :P [19:08:54 CET] <nidhoegger> one question: will this config install ffmpeg with mp3 support? [19:09:04 CET] <nidhoegger> or do I need libmp3lame for that? [19:09:06 CET] <JEEB> decoding yes, since it's internal [19:09:11 CET] <JEEB> encoding, yes - you need LAME [19:09:13 CET] <JEEB> *no [19:09:15 CET] <nidhoegger> i only need decoding for x264 and mp3 [19:09:27 CET] <JEEB> x264 is not a format [19:09:32 CET] <JEEB> AVC or H.264 you mean [19:09:41 CET] <nidhoegger> yes, H.264 it is :P [19:09:50 CET] <JEEB> but yes, AVC and MPEG-1 Layer 3 decoders are in the default configuration [19:10:01 CET] <nidhoegger> perfect, thx [19:10:09 CET] <nidhoegger> is there a way to disable all encoders? since i do not need them [19:10:23 CET] <JEEB> yeah, but you will want to make sure your thing works first [19:10:31 CET] <JEEB> also when you do major configuration changes remember make distclean [19:10:35 CET] <nidhoegger> ah, --disable-decoders [19:10:47 CET] <JEEB> (or git clean -dfx if you like it the git way) [19:10:50 CET] <nidhoegger> hehe [19:11:04 CET] <nidhoegger> encoders i mean [19:11:11 CET] <JEEB> and please start limiting your configuration *after* you get some things done [19:11:21 CET] <nidhoegger> okay [19:11:27 CET] <JEEB> there's been way too many cases of people starting out with disable-everything or something [19:11:30 CET] <nidhoegger> just wanted to make it compile faster [19:11:50 CET] <JEEB> "I just disabled everything and enabled the demuxers and decoders that I needed" [19:11:54 CET] <nidhoegger> hehe [19:11:55 CET] <JEEB> "Why do no files open?" [19:12:05 CET] <JEEB> "Maybe because you lack the file protocol?" [19:12:21 CET] <JEEB> but yeah, basically the first step is always to get a basic thing built [19:12:43 CET] <JEEB> then when you've confirmed that your stuff works with it, then you can go poke at the optimizing params [19:14:42 CET] <nidhoegger> i will, thanks for your help! [19:14:52 CET] <nidhoegger> ill report back if it worked [19:20:12 CET] <deadamerican> Apple TV 4th gen with a remuxed mkv with aac and ac3 playing both streams at the same time, is it a known issue or am i just lucky? [19:20:49 CET] <Fyr> deadamerican, what ffprobe says? [19:23:11 CET] <deadamerican> nothing out of the ordinary, audio stream index 1 is aac and index 2 is ac3 [19:24:16 CET] <Fyr> then I don't know. [19:25:21 CET] <deadamerican> yeah, i am kind of stumped with it. what comes out of ffmpeg plays perfect on everything else but that [19:25:42 CET] <Fyr> do other players play it right? [19:25:52 CET] <deadamerican> yup [19:26:09 CET] <Fyr> then post a bug report to Apple. [19:26:16 CET] <deadamerican> ok [19:51:15 CET] <nidhoegger> JEEB, it worked now, thx! [19:51:20 CET] <JEEB> 'grats [19:56:55 CET] <nidhoegger> hmmm...does someone know this error: version LIBAVCODEC_56 not defined in file libavcodec.so.56 with link time reference [19:57:08 CET] <nidhoegger> relocation error: ./ultrastardx: symbol av_audio_resample_init, version LIBAVCODEC_56 not defined in file libavcodec.so.56 with link time reference [20:03:30 CET] <nidhoegger> when running ffmpeg: ffmpeg: relocation error: /usr/lib/libavfilter.so.5: symbol avpriv_vga16_font, version LIBAVUTIL_54 not defined in file libavutil.so.54 with link time reference [20:04:29 CET] <durandal_1707> nidhoegger: broken build/install [20:04:41 CET] <nidhoegger> hmmmm [20:04:46 CET] <nidhoegger> its a fresh build [20:04:52 CET] <nidhoegger> some ppl write its an --enable-shared issue :/ [20:07:59 CET] <momomo> hey guys, it is possible to start serving an unifinished hls file, out10.ts for instance? or do we have to wait for it to finish ? [20:08:40 CET] <Mavrik> MPEG-TS files should be playable while being written :) [20:08:51 CET] <Mavrik> at least while they're streamed, no idea what filesystem does with files tho [20:11:00 CET] <momomo> yes, that seems to be right [20:11:02 CET] <bencoh> momomo: your client will fetch an incomplete file, and will either stop playing after reaching the end or skip to the next one (if available) [20:11:23 CET] <bencoh> I don't really see how you want to use that with HLS [20:11:27 CET] <momomo> bencoh, yes, probably difficult to stream an incomplete file [20:11:46 CET] <momomo> but I am having serious lagging issues due to hls files not being consistent [20:11:48 CET] <Mavrik> You just need to outpace playback [20:11:51 CET] <bencoh> actually we usually do it the over way around - ensure a file is published *only* once it's complete [20:11:56 CET] <Mavrik> But for HLS you usually want to be one segment behind [20:12:05 CET] <Mavrik> e.g. not show partial segments in XML [20:12:14 CET] <bencoh> exactly :) [20:12:15 CET] <momomo> if the average file is 500kb ... some files will eventually be 1.2 - 1.5 mb ... and the live feed has to wait for these to complete [20:12:42 CET] <momomo> quetion is if these files are playable .. why is ffmpeg having such a difficulty splitting them at consistent sizes ? [20:12:54 CET] <momomo> it should be a matteer of just splitting [20:13:39 CET] <momomo> i am using hls_size 10 ... which is based on seconds .. so the size might differ .. but that should be based on kb .. otherwwise streaming becomes unstable [20:13:50 CET] <bencoh> no [20:13:58 CET] <bencoh> you should re-read the HLS draft [20:13:59 CET] <furq> it can't be based on size because splitting has to occur on an IDR frame [20:14:34 CET] <bencoh> and because CBR encoding isn't that constant anyway (see vbv) [20:14:43 CET] <momomo> furq, according to what? some spec? override it and input one .. the files seems to be playable no matter if such a frame has been encountered [20:14:59 CET] <furq> "input one" [20:15:00 CET] <bencoh> momomo: apple's updated documentation [20:15:02 CET] <furq> you make that sound so easy [20:15:39 CET] <momomo> bencoh, but do you agree that live streaming becomes an issue in such cases ? otherwise I have to wait alot before playing .. so these extra sizes are already accounted for .. and once it catches up .. it might still occur later [20:16:11 CET] <bencoh> momomo: HLS doesn't mean "live" at all, yeah, indeed. [20:16:22 CET] <bencoh> (I'd also say it's mostly crap, but ... :>) [20:16:32 CET] <furq> it's better than the alternatives [20:17:03 CET] <momomo> furq, maybe not easy ... but ffmpeg is not easy software .. and it appearrs as if it is theoritacally possible to improve .. since vlc is able to play these streams .. [20:17:03 CET] <bencoh> yeah, they all suck, this one sucks a bit less (thus far) :) [20:17:11 CET] <bencoh> (just like mutt/mail reads) [20:17:18 CET] <furq> i mean RTMP is better in theory but not since the world turned on flash [20:17:35 CET] <momomo> furq, i need one solution for all devices ... [20:17:40 CET] <momomo> :( [20:17:48 CET] <furq> surely if VLC can play it then the issue is browsers, not ffmpeg [20:17:56 CET] <bencoh> momomo: well, you'll have to live with not-so-live "live" [20:18:21 CET] <furq> all i can really suggest is smaller/larger segment/gop lengths [20:18:28 CET] <bencoh> furq: not necessarily, VLC can be more lenient [20:18:29 CET] <momomo> furq, well .. if ffmpeg is generating average files of 400kb and then generates a 2mb one .. that's a problem [20:18:32 CET] <momomo> and it's ffmpeg [20:18:32 CET] <bencoh> (VLC always is) [20:18:47 CET] <bencoh> momomo: it could be your ffmpeg parameters as well [20:19:01 CET] <momomo> whatever those ts files are .. and whatever they contain ... ffmpeg could generate those as it pleases and update the m3u8 [20:19:27 CET] <furq> momomo: do you have keyint_min on (or scenecut off) [20:19:39 CET] <furq> that in conjunction with strict vbv params should result in more stable segment sizes [20:19:57 CET] <furq> and also worse quality, but oh well [20:20:04 CET] <momomo> bencoh, i tried a bunch of them yesteday inclduing bitrate and what not .. but the same behaviour was encountered .. only way was to decrease quality enough to have the difference become insignifcant [20:20:46 CET] <momomo> furq, no, i don't know about those params [20:20:59 CET] <furq> -x264opts keyint_min=50 [20:21:03 CET] <furq> change 50 to whatever you've set -g to [20:21:59 CET] <momomo> whatabout strict ? i've seen that before .. and zerolatency ? [20:22:49 CET] <furq> zerolatency will have no real effect with HLS [20:23:17 CET] <JEEB> if you want actual low latency, use an actual streaming protocol [20:23:37 CET] <JEEB> because HLS will have the latency of at least a couple of segments [20:23:54 CET] <JEEB> (I think three is the usual minimum for a playlist for most implementations?) [20:24:23 CET] <furq> firefox uses less in my experience [20:24:26 CET] <furq> s/less/fewer/ [20:24:31 CET] <momomo> 1 is minimal it appearrs ... m3u8 is generated after 1 .. but then usually there is lag right after [20:24:32 CET] <furq> i have nothing to back that up though [20:24:33 CET] <momomo> ffmpeg -i ${URL} -x264opts keyint_min=100 -g 100 -r 20 -framerate 20 -b:v 512k -bufsize 512k -maxrate 1024k -c:v libx264 -c:a libvo_aacenc -b:a 64k -ac 2 -f hls -hls_list_size 10 -hls_time 10 -hls_flags delete_segments ${OUT} [20:24:49 CET] <momomo> any issues/improvements with this command ? [20:25:19 CET] <JEEB> yes, after your first segment finishes you will most probably have the playlist, I'm just saying that due to player buffering you will most probably have the players wait for at least three to be buffered [20:25:41 CET] <JEEB> also for static GOPs you use -x264-params scenecut=0 [20:25:47 CET] <JEEB> that just disables dynamic GOPs [20:25:52 CET] <momomo> JEEB, yes, the player is not aggressive enough to ask for next playlist file sometimes [20:25:54 CET] <JEEB> that way you can just use -g VALUE and it [20:26:30 CET] <momomo> are some of these options expensive computing wise ? [20:27:08 CET] <momomo> i am going to go for a couple of 1000s eventually and cheap is good .. but I guess i have no option right now [20:28:24 CET] <momomo> latest and greatest: [20:28:26 CET] <momomo> ffmpeg -i ${URL} -x264-params scenecut=0 -x264opts keyint_min=100 -g 100 -r 20 -framerate 20 -b:v 512k -bufsize 512k -maxrate 1024k -c:v libx264 -c:a libvo_aacenc -b:a 64k -ac 2 -f hls -hls_list_size 10 -hls_time 10 -hls_flags delete_segments ${OUT} [20:28:44 CET] <furq> there's no reason to disable scenecut and set keyint_min [20:28:46 CET] <momomo> is both -r 20 and -framerate 20 ? i understand they arre not the same .. right ? [20:28:48 CET] <furq> they both do the same thing in this case [20:28:57 CET] <furq> and get rid of -framerate 20, it's redundant there [20:29:17 CET] <momomo> what if -r is 20 and framerate is like 50 ... what would be the difference ? [20:29:22 CET] <momomo> what would happen? [20:29:30 CET] <momomo> or the opposite [20:29:34 CET] <furq> afaik as an output option, -framerate is an alias for -r (which is an alias for -vf fps) [20:29:42 CET] <furq> so it'd set the framerate to 50 because it came after -r [20:33:07 CET] <momomo> i have no idea what those options actually do ... i am running a test now to see if I notice any big inconsistencies in sizes [20:33:40 CET] <bencoh> you really should read some documentation about HLS, mpegts, x264, and ffmpeg ... [20:34:25 CET] <bencoh> otherwise you'll keep running into these "I have no idea what I'm doing" kind of issues [20:36:35 CET] <momomo> bencoh, it's difficult to get into something totally new .. but since a few weeks back, i have learnt quite a lot .. mostly through good people here ... but I was completely out of it at the beginning .. didn't even know what ffmpeg was or hls .. furq has helped quite a lot :) [20:37:14 CET] <momomo> so I am getting better .. eventually i would research these options .. but right now it's a lot of trial and error [20:38:52 CET] <momomo> sizes somewhat more consistent ... http://s29.postimg.org/5npspckzr/Screenshot_from_2016_03_10_20_38_03.png [20:39:08 CET] <momomo> but still some big differences at times [20:41:53 CET] <kepstin> yeah, well, it's vbr. you could make the constraints on the bitrate tighter, but it'll reduce your overall video quality. Also, you should probably be checking whether the files all have the same duration. [20:42:12 CET] <bencoh> trial and error with HLS can be quite tedious, since your usual target players behave like black boxes [20:47:04 CET] <momomo> kepstin, constraints ? like minrate and maxrate ? [20:47:21 CET] <momomo> ffmpeg -i ${URL} -x264-params scenecut=0 -x264opts keyint_min=100 -g 100 -r 20 -framerate 20 -b:v 512k -bufsize 512k -maxrate 1024k -c:v libx264 -c:a libvo_aacenc -b:a 64k -ac 2 -f hls -hls_list_size 10 -hls_time 10 -hls_flags delete_segments ${OUT} [20:47:38 CET] <kepstin> momomo: unless you need specific constraints for bandwidth or device processing reasons, don't worry about it. [20:47:47 CET] <kepstin> better to avoid them if you don't need them [20:48:10 CET] <momomo> i would like to get a more consistent size of the ts files .. so lagging won't occur [20:48:36 CET] <kepstin> if you want to reduce issues with connection setup, etc. use longer segments [20:48:51 CET] <kepstin> not sure what you mean by "lagging" [20:51:15 CET] <momomo> the problem is that if I get a ts file that is 500 kb first .. 0.ts .. then say the next one is 1mb or longer than the original one .. then the m3u8 playlist won't include it until it finishess ... so if it hits 1.2mb .. the player has to wait for it to finish .. [20:51:28 CET] <momomo> maybe it is not an mb issue but a length issue [20:52:31 CET] <momomo> i think lenghts are more consistent now though [20:53:38 CET] <kepstin> well, the player delay and buffering in HLS is always going to be somewhere between 1-2 segments long, you can't get lower than that [20:54:18 CET] <kepstin> I wouldn't normally expect any issues as long as the bitrate on the segments is low enough that you can download them faster than realtime. [20:56:49 CET] <bencoh> physical segment size is a non-issue as long as you get the proper duration [20:59:13 CET] <momomo> bencoh, yes, i think it is the duration that is focus here [20:59:31 CET] <momomo> i remember earlier that they werent always the same [20:59:42 CET] <momomo> but now i am hitting 5.00000 SEC every time [20:59:53 CET] <momomo> must be some added option [20:59:59 CET] <furq> that's keyint_min [21:00:03 CET] <bencoh> re-read what you were told about gop size and keyint_min ... [21:00:10 CET] <momomo> -x264-params scenecut=0 or -x264opts keyint_min=100 ? [21:00:19 CET] <bencoh> and read the doc, seriously. [21:00:24 CET] <furq> they'll both do the same thing in this case [21:00:42 CET] <momomo> i will :) .. i googleed it .. but this doesn't explain really what they do: https://sites.google.com/site/linuxencoding/x264-ffmpeg-mapping [21:01:19 CET] <momomo> but ok .. so thanks guys, once again! [21:01:22 CET] <bencoh> well it does, unless you dont know what an I-frame is, in which case you need to dig further [21:01:24 CET] <furq> that explains almost perfectly what they do [21:01:28 CET] <bencoh> and compare that info to apple documentation. [21:01:30 CET] <momomo> i love you [21:02:59 CET] <momomo> so much to learn, i am on 99.9% of the internet .. just ffmpeg left :P [21:03:15 CET] <nidhoegger> still getting the relocation error [21:03:23 CET] <nidhoegger> everything uninstalled and built from scratch again [21:05:11 CET] <t4nk507> hello [21:05:26 CET] <t4nk507> plz what means -bt parameter [21:05:40 CET] <bencoh> nidhoegger: what about --enable-pic (I don't think it should be relevant in your case, but ...) [21:05:42 CET] <t4nk507> like in ffmpeg -i %s -f image2 -bt 20M -vf fps=%s -aspect 16:9 %s/tv%%03d.jpg" % [21:06:49 CET] <t4nk507> i m doing sprite preview image, and I m looking to decrease the resulting image size [21:07:08 CET] <kepstin> t4nk507: that's not an ffmpeg parameter as far as I know, maybe a typo? [21:07:20 CET] <kepstin> are you trying to set the bitrate? [21:12:39 CET] <t4nk098> so what could be the alternative to -bt [21:12:56 CET] <momomo> is there any reasons why you would set bitrate and -bv to control quality over crf ? is crf preferable ? [21:12:57 CET] <t4nk098> this is what I got from a nice python script that automate sprite creation [21:13:25 CET] <t4nk098> https://github.com/vlanard/videoscripts/blob/master/sprites/makesprites.py [21:13:47 CET] <t4nk098> line 107 [21:14:42 CET] <t4nk098> I donno this isn't encoding videos, this is capturing frame over the video to make a sprite [21:19:15 CET] <kepstin> momomo: if you want a specific output bitrate or filesize, you set bitrate. if you don't care about the exact output bitrate but want constant quality over the length of the file, use crf [21:19:23 CET] <kepstin> momomo: they're for completely different use cases [21:20:03 CET] <kepstin> (for internet streaming to clients with a certain target internet connection quality, you want to use bitrate, not crf) [21:20:49 CET] <t4nk098> i use crf for streaming [21:20:59 CET] <t4nk098> fixed bitrate is great for 2 pass encoding [21:21:12 CET] <t4nk098> but this is not the purpose of my question :) [21:21:54 CET] <t4nk098> it s weird i dont find documentation of this, especially since it works really fine.. [21:22:06 CET] <kepstin> t4nk098: documentation of what? [21:22:13 CET] <t4nk098> of that -bt cmd [21:22:25 CET] <furq> -bt is bitrate tolerance [21:22:36 CET] <furq> equivalent to x264 --ratetol [21:22:52 CET] <furq> ffmpeg -h full | grep -- -bt [21:22:58 CET] <t4nk098> i could put -bt 10M and get half picture weight then [21:23:12 CET] <kepstin> furq: where is that documented? it doesn't show up in the ffmpeg man page, and it's not an avoption on the mjpeg encoder [21:23:24 CET] <furq> oh, mjpeg [21:23:39 CET] <kepstin> my guess is that it's being accepted as an avoption... and ignored. [21:23:45 CET] <furq> it's a global avoption so yeah [21:23:48 CET] <furq> it's probably just being ignored [21:23:56 CET] <furq> it normally goes from 0 to 1, so 20M makes no sense anyway [21:24:23 CET] <kepstin> so yeah, someone probably wanted to set the bitrate, and made a typo on the option name. [21:24:48 CET] <furq> 20:22:58 ( t4nk098) i could put -bt 10M and get half picture weight then [21:24:51 CET] <kepstin> bitrate is, of course, -b (with optional stream specifiers) [21:24:51 CET] <furq> also that's not what bitrate tolerance is [21:33:46 CET] <t4nk098> hm ok let s assume that bt does nothing then [21:34:08 CET] <t4nk098> how would I lowered the bitrate when outputting to jpeg [21:34:21 CET] <t4nk098> simply -b:v xx [21:34:27 CET] <t4nk098> or crf:v xx [21:34:51 CET] <kepstin> t4nk098: crf is codec-specific option only supported by x264/5 and vpx [21:35:10 CET] <t4nk098> right [21:35:14 CET] <kepstin> but -q:v would probably be useful - although I don't know the value range mjpeg takes for that [21:36:22 CET] <kepstin> (probably similar to ffmpeg's mpeg1/2 encoders, so lower numbers are higher quality) [21:39:37 CET] <t4nk098> ok thanks, the best is to test it [21:46:02 CET] <t4nk098> tried q:v 50 and 10 [21:46:05 CET] <t4nk098> doesn't change at all [21:58:07 CET] <t4nk098> thanks [21:58:09 CET] <t4nk098> later [22:06:27 CET] <explodes> When freeing a AVFormatContext*, must I also manually free my AVCodecContext*'s ? [22:06:38 CET] <explodes> AVFormatContext* is being closed with avformat_close_input [22:22:38 CET] <explodes> I have old code that manually frees these things, but it doesn't make any sense to... [22:40:27 CET] <Mavrik> Why not? [22:40:33 CET] <Mavrik> You have to, they're separate [22:41:32 CET] <deadamerican> Is there a way to set the default audio stream? when using map 0:1 for DTS to 2 channel aac and 6 channel ac3 both streams are set to default. [23:33:14 CET] <explodes> Mavrik: The references I have are pulled from my AVFormatContext* [23:33:37 CET] <explodes> ie. strm->audioCodec = strm->pFormatCtx->streams[strm->audioStream]->codec; [00:00:00 CET] --- Fri Mar 11 2016

1 0

ffmpeg-devel.log.20160309
by burek 10 Mar '16

10 Mar '16

[00:01:21 CET] <cone-905> ffmpeg 03Reimar Döffinger 07master:b91e3763905a: aacenc: use generational cache instead of resetting. [00:01:22 CET] <cone-905> ffmpeg 03Reimar Döffinger 07master:b60dfae7af65: aacenc_utils: Use temporary variable. [00:58:50 CET] <ethe> I'm a little confused, I think I need timefilter, but not sure. How would I go about syncing output to samplerate? I want to say use ff_timefilter_eval to check how long since the last frame was sent, and if it's above 1/samplerate, then I need to send a frame again [03:13:11 CET] <Timothy_Gu> ethe: why would you have to do that? [03:13:32 CET] <ethe> Timothy_Gu: to output at the samplerate to JACK [03:14:14 CET] <ethe> using -re breaks it, because (I think), it's not getting frames to the write quick enough [03:17:17 CET] <Timothy_Gu> ethe: just dumping all the frames you get to JACK doesn't work? [03:18:39 CET] <ethe> then it goes to jack at 4x speed, and outputs crazy fast [03:19:22 CET] <Timothy_Gu> ethe: that shows that the pipeline should be able to satisfy a much higher throughput [03:19:40 CET] <Timothy_Gu> and -re limits that throughput to a normal rate [03:19:53 CET] <Timothy_Gu> and JACK apparent can't take the normal rate? [03:22:50 CET] <ethe> lemme get a patch quick, might be easier to explain [03:26:52 CET] <ethe> Timothy_Gu: https://gist.github.com/cefad88c48e83f5a57fd [03:29:20 CET] <ethe> I reckon I'm thinking that the wrong thing is the problem, even if it is faster playback it shouldn't be *so* distorted, just pitched up. [03:29:59 CET] <Timothy_Gu> ethe: do I need jack2 or jack1 [03:30:03 CET] <Timothy_Gu> to build it [03:30:23 CET] <ethe> they use a common api, so in theory, either. [03:30:26 CET] <ethe> ABI* [03:31:16 CET] <ethe> I'm testing with jack2 though [04:48:04 CET] <cone-628> ffmpeg 03Michael Niedermayer 07master:89862cd73401: avcodec/ffjni: Fix ;; [04:48:04 CET] <cone-628> ffmpeg 03Michael Niedermayer 07master:a008a7cc953e: avcodec/ffjni: Fix occured typo [04:53:30 CET] <Timothy_Gu> ethe: I'm fairly sure the slowness results from your allocating memory in process_callback [04:53:46 CET] <Timothy_Gu> jack_dec explicitly warns against that [04:56:11 CET] <Timothy_Gu> for me even without -re the output still stutters [05:58:55 CET] <arthcp> Where can I find more information about the rm container? [05:59:14 CET] <Compn> THE GARBAGE! [05:59:16 CET] <Compn> haha :P [05:59:28 CET] <Compn> arthcp : realmedia put a lot of info in openhelix website [05:59:45 CET] <Compn> arthcp : http://wiki.multimedia.cx/index.php?title=RM [06:00:29 CET] <arthcp> Compn: I'll give it a try [06:01:55 CET] <arthcp> Compn: thb [06:02:18 CET] <arthcp> Compn: thanks... It's what I was looking for [06:02:35 CET] <Compn> no problem [06:02:44 CET] Action: Compn afk [07:45:35 CET] <rcombs> `rm *.rm` [08:29:19 CET] <flux> yes, when you want to watch some files real quick, it's best to use the RealMedia player, "rm". [11:45:15 CET] <carpediem> Hello developers [11:46:11 CET] <carpediem> I have been running afl-fuzz on ffmpeg as part of the GSOC Project "Create a fuzzing testsuite for FFmpeg" for the past few days [11:46:58 CET] <carpediem> during this period, afl-fuzz has reported quite a lot of hangs (almost 500+) [11:47:07 CET] <kierank> that can be because your PC is too slow [11:47:14 CET] <kierank> you should increase the timeout threshold [11:47:22 CET] <kierank> unless you can specifically reproduce the hang [11:47:49 CET] <carpediem> ok. Now I will be working on reproducing the hangs and reporting them to your bug tracker [11:48:04 CET] <kierank> if you can't reproduce the first couple then increase the threshold [11:48:17 CET] <kierank> I would still use zzuf though, much quicker to find low hanging stuff [11:48:37 CET] <carpediem> ok [11:48:53 CET] <carpediem> should I batch process these hang files through zzuf? [11:49:07 CET] <kierank> no [11:49:16 CET] <kierank> zzuf is an alternative to afl-fuzz [11:49:22 CET] <kierank> try reproducing the hangs first [11:49:28 CET] <kierank> it could be they are just files which are slow to decode [11:49:28 CET] <carpediem> ok [11:50:19 CET] <carpediem> one more thing, qualification task for this project included building fffuzz [11:50:32 CET] <carpediem> I git cloned it from the repo [11:51:03 CET] <carpediem> but when I try to build it, it does not detect the include files(the libraries) [11:51:24 CET] <kierank> well the idea should be that you use fffuzz to fuzz [11:51:24 CET] <carpediem> even when the directory is changed to that one which contains the libraries [11:51:38 CET] <kierank> you need to do "make install" on ffmpeg and have pkg-config available [11:52:08 CET] <carpediem> ok. I will try again. [11:53:44 CET] <cone-861> ffmpeg 03Paul B Mahol 07master:953b8c5a43ef: avfilter/vf_waveform: use intensity for other components too [12:34:32 CET] <thardin> woo [12:35:36 CET] <carpediem> Hi, I tried building fffuzz and ran into an error [12:35:39 CET] <carpediem> build.sh: 1: build.sh: afl-clang-fast: not found [12:36:00 CET] <carpediem> should I post a pastebin? [12:42:55 CET] <kierank> there's away of installing afl-clang-fast in the afl-help [12:43:03 CET] <kierank> can't remember where exactly [12:44:36 CET] <carpediem> ok. will find it out and install. [13:05:51 CET] <DSM_> hi everyone [13:08:58 CET] <durandal_1707> Hi [13:29:22 CET] <nevcairiel> michaelni: the seek-cache-pipe test you added last week fails on one of my fate boxes [13:42:08 CET] <kierank> does the lavc api provide a way to signal if the frame had corrupt data [13:42:20 CET] <nevcairiel> there is a flag [13:43:55 CET] <kierank> I haven't found that flag [13:44:38 CET] <nevcairiel> AVFrame.decode_error_flags [13:45:14 CET] <nevcairiel> there is also AV_FRAME_FLAG_CORRUPT for AVFrame.flags [13:50:52 CET] <michaelni> nevcairiel, seems it fails on your enable-shared box while passing on the static one, no information is shown about the failure. Is there something special about shared msvc builds and pipes or something ? [13:51:38 CET] <nevcairiel> no idea why shared should be failing [13:51:56 CET] <nevcairiel> due to the piping i cant attach a debugger though [13:52:07 CET] <nevcairiel> unless there is a gdb flag that i dont know about =p [13:57:08 CET] <nevcairiel> looks like it aborts because cache tries to seek the fd [13:57:14 CET] <nevcairiel> which it doesnt allow [13:58:21 CET] <nevcairiel> no idea why static wouldnt also do that [14:00:48 CET] <cone-861> ffmpeg 03Carl Eugen Hoyos 07master:144ef773c714: Use correct msvc type specifiers for ptrdiff_t and size_t. [14:02:46 CET] <cone-861> ffmpeg 03Carl Eugen Hoyos 07master:a6a52ef29ac2: lavc/hevc_ps: Fix offset for yuv422 and yuv444. [14:04:45 CET] <nevcairiel> why does the cache protocol create a temp cache file and then delete it right after? o.o [14:06:46 CET] <michaelni> so it wont leave a stale file on exit [14:06:51 CET] <nevcairiel> michaelni: i found the problem, av_tempfile returns a file handle across dynamic library boundary, thats not allowed [14:08:28 CET] <nevcairiel> because the way we build msvc shared libs, every lib has its own CRT, and handles are not interchangeable [14:08:30 CET] <cone-861> ffmpeg 03Carl Eugen Hoyos 07master:260c12cdd1df: lavc/mjpegdec: Set sar for multiscope videos. [14:11:42 CET] <nevcairiel> (ie. a very bad idea for public API) [14:12:31 CET] <BtbN> Really? Aren't they per-application? [14:12:50 CET] <nevcairiel> not if you statically link the CRT in like we do [14:13:16 CET] <BtbN> so the handle is more complex than a fd number on linux i assume [14:13:51 CET] <nevcairiel> there is a low level fd handle somewhere behind it, but what you get is higher level and tracked by the current CRT [14:14:07 CET] <cone-861> ffmpeg 03Carl Eugen Hoyos 07master:fb9036b3142e: lavf/mpeg: Identify sub-stream ID 0xa1 as mlp. [14:15:37 CET] <nevcairiel> ie. you can call _get_osfhandle and _open_osfhandle to get the OS handle and create a CRT handle for an OS handle [14:15:54 CET] <nevcairiel> but thats really rather special to want that [14:17:00 CET] <ismail> nevcairiel: (just wondering) whay are you statically linking crt for each DLL? [14:19:00 CET] <nevcairiel> doesnt require shipping around specific runtime versions [14:19:51 CET] <cone-861> ffmpeg 03Carl Eugen Hoyos 07master:a62d76889470: configure: Check for msghdr struct. [14:19:53 CET] <ismail> I see [14:21:36 CET] <michaelni> nevcairiel, s it safe to pass pointers to open/mkstemp between dlls and when called later will actually provide a local useable fd ? [14:22:29 CET] <nevcairiel> seems evil, why not just return a temp filename instead [14:22:47 CET] <ubitux> are we going to do tep2 lavc this week end? [14:23:28 CET] <nevcairiel> i still have no idea what you mean with lavc [14:23:33 CET] <nevcairiel> lavc does not change with this [14:23:43 CET] <nevcairiel> its lavf only [14:23:55 CET] <nevcairiel> and the old one isnt even remotely finished [14:24:28 CET] <ubitux> oh my bad [14:24:42 CET] <ubitux> yeah ok, sorry [14:25:02 CET] <ubitux> so there is only this big commit followed by the tools [14:25:29 CET] <nevcairiel> the big commit introduces the new API, everything else is just moving the cli tools to the new API [14:25:53 CET] <michaelni> nevcairiel, yes it seems evil, but then to fix the av_tempfile() implementation we need to call open/mkstemp from a inline function of a public header [14:26:20 CET] <michaelni> iam not sure about what kind of headers and config.h stuff that would need [14:26:58 CET] <michaelni> or we could deprecate av_tempfile() [14:27:27 CET] <nevcairiel> to solve the problem with generic file opening, we have file_open.c in every library that includes a C file from libavutil [14:27:32 CET] <nevcairiel> but no public API of course [14:32:08 CET] <nevcairiel> so we could use that mechanism to offer ff_tempfile, deprecate av_tempfile with a warning that its not safe on all systems [14:33:23 CET] <ubitux> arent most of the failing tests due to mov? [14:36:29 CET] <michaelni> nevcairiel, is the av_fopen_utf8() call in ffmpeg_opt.c havng the same issue ? [14:36:43 CET] <nevcairiel> probably [14:36:56 CET] <nevcairiel> someone that added that didnt think very hard about why this whole mess exists =p [14:37:47 CET] <nevcairiel> its only used for pass1 logfile, who really uses that anyway :D [14:38:44 CET] <michaelni> low impact is good but it should be fixed anyway [14:39:06 CET] <nevcairiel> lets see who to blame for even adding that public api [14:39:23 CET] <nevcairiel> hey its you =P [14:40:13 CET] <michaelni> i should have realized :( [14:40:23 CET] <nevcairiel> but yes, we should not have any public API that returns file pointers [14:40:26 CET] <nevcairiel> its not quite portable [14:40:52 CET] <michaelni> it could be done with static inline functions in theory [14:41:10 CET] <nevcairiel> that would be private since it needs config.h, not good for the CLI tools [14:42:25 CET] <nevcairiel> for the libraries the existing solution worked fine with including a file from avutil [14:42:32 CET] <nevcairiel> for ffmpeg.c, thats not so easy [14:43:27 CET] <nevcairiel> just to confirm, I build ffmpeg with dynamically linked CRT and that fixed it, so.. [14:44:55 CET] Action: nevcairiel adds a new fate box that tests building that configuration as well, just in case [14:49:00 CET] <ubitux> btw, i'm adding an assert-level=2 fate instance [14:50:15 CET] <rcombs> why aren't they all assert-level=2 unless doing perf tests [14:52:32 CET] <ubitux> rcombs: yeah maybe they should [14:54:01 CET] <ubitux> the risk i'm seeing is a developer might trigger an assert without realizing because his local build hasn't the option, and then all fate instances turn red [14:54:51 CET] <nevcairiel> one instance should be enough, doesnt sound like something that would be very setup dependent [14:56:14 CET] <ubitux> grep 'av_assert[12]' -r **/{x86,arm,ppc,aarch64,mips}|wc -l [14:56:16 CET] <ubitux> 47 [14:56:23 CET] <ubitux> seems there isn't that much [14:56:25 CET] <ubitux> indeed [14:57:10 CET] <ubitux> btw, fate with --disable-everything is still freezing, so i disabled the instance [14:58:43 CET] <rcombs> could we have a branch that commits go to before merging to master that gets run through fate, and then master ffwd's to that if everything passes? [14:59:13 CET] <nevcairiel> isnt that what our master is for =p [15:11:45 CET] <Compn> we could just run fate before committing [15:11:48 CET] <Compn> (oh shit i said it) [15:11:54 CET] <Compn> :P [15:25:43 CET] <Daemon404> [13:40] <@nevcairiel> but yes, we should not have any public API that returns file pointers <-- we have api that consumes file pointers too [15:25:46 CET] <Daemon404> also evil [15:26:04 CET] <Daemon404> presumably it should be aviocontext instead [15:26:07 CET] <durandal_1707> which ones? [15:26:47 CET] <Daemon404> https://ffmpeg.org/doxygen/trunk/group__lavf__misc.html [15:48:15 CET] <BBB> so, hows TEP2 going? [15:48:31 CET] <BBB> should I just merge my patches for vp9_superframe or do you want me to wait for you guys merging all your stuff? [15:59:18 CET] <Daemon404> BBB, im nto sure if your patchset would be affected by TEP2 anyway> [15:59:19 CET] <wm4> does it conflict anywhere? [15:59:35 CET] <BBB> well, libav had some patch to change bsf api right? [15:59:45 CET] <BBB> I dont know if thats tep2 or after [16:00:36 CET] <wm4> after [16:02:18 CET] <Daemon404> P.S. >2>@8< ?> @CAA:8. [16:02:19 CET] Action: Daemon404 luls [16:02:36 CET] <Daemon404> Please email your resume and questions to toronto.ffmpeg(a)gmail.com <-- this stuff is always so sketchy [16:03:16 CET] <kierank> it's yet another streaming company [16:03:24 CET] <Daemon404> of course [16:03:28 CET] <Daemon404> but they dont share their name ;P [16:03:59 CET] <kierank> well the biggest problem with these things is they want someone who's good at ffmpeg but who suddenly has expertise in java and other stuff [16:04:10 CET] <kierank> and they'll pay a pittance no doubt [16:04:36 CET] <kierank> but at the same time pay huge sums to some company using ffmpeg inside [16:07:01 CET] <Daemon404> java can be learned [16:07:10 CET] <Daemon404> but you get what you pay for [16:15:00 CET] <ubitux> endless agony? [16:18:35 CET] <Compn> working with canadians? [16:20:36 CET] Action: wm4 awards Compn 50 micro-courmisch [16:24:22 CET] Action: nevcairiel knows both java and ffmpeg [16:24:30 CET] Action: nevcairiel has a well paid job, though [17:53:07 CET] <BBB> kierank: thats why you set up a company that uses ffmpeg inside ;) [17:53:33 CET] <kierank> and claim it's super secret technology [17:53:50 CET] <BBB> Daemon404: so since youre merging, do you mind if I merge my patches? theyll require minor extra effort once you merge the patch from libav [17:54:08 CET] <Daemon404> BBB, teh bsd stuff isnt so bad [17:54:10 CET] <Daemon404> so its fine [17:54:15 CET] <Daemon404> its TEP2 that == pain [17:54:16 CET] <Daemon404> er [17:54:20 CET] <Daemon404> bsf stuff* [17:54:22 CET] <Daemon404> best typo. [17:54:25 CET] <BBB> indeed [17:54:27 CET] <BBB> freudian [17:54:39 CET] <Daemon404> lol [17:55:05 CET] <BBB> Ill help make vp9_superframes work after the bsf merge if you want [17:56:00 CET] <BBB> kierank: its always best to keep key technology super secret [17:56:21 CET] <BBB> itd be hard to sell to investors if they heard that your super secret technology could be downloaded for free and that you have no friggin clue how it works [17:56:57 CET] <BBB> even though you gave a stanford newgrad co-founder 40% equity because he has technical knowledge [17:59:08 CET] <BBB> (technical knowledge means he converted an algorithm written originally in python to scala some day - he still doesnt quite know what the algorithm does but it uses additions and subtractions in some places) [18:00:31 CET] <Daemon404> i see you've been to the bay area [18:00:50 CET] Action: kierank is going to visit for first time soon [18:01:02 CET] <kierank> not sure I can stomach the smell of BS everywhere [18:01:08 CET] <Daemon404> kierank, after NAB? [18:01:12 CET] <kierank> yeah [18:47:38 CET] <ethe> Timothy_Gu: even when not allocating at all in the process_callback function, and not blocking the write function, throughput is still way below jack. the only solution I can see is limiting jack to samplerate (or other, lower fps) [18:52:22 CET] <t_than> Hello. I'm I student and I'm thinking of applying for this year's GSoC with ffmpeg (I was mainly thinking about the FFv1 P-frame support) [18:53:38 CET] <t_than> I have some (academic) experience with video coding, but I haven't developed for ffmpeg. Could someone give me some pointers on where to begin? [18:54:55 CET] <durandal_1707> t_than: ask michaelni for qualification task [18:58:36 CET] <t_than> Ok, thank's for your response. [19:04:25 CET] <michaelni> t_than, you can do the "Improve the compression of the existing FFV1 Intra frames, you can change any part of the algorithm but it must be practical, the more improvement you can achieve, the better " task if you like. If so please add yourself to https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016-Qualis [19:04:52 CET] <michaelni> t_than, you can of course also suggest some other qualification task [19:07:52 CET] <JEEB> wm4: funky with the start_time patch [19:07:57 CET] <JEEB> more timestamp madness [19:10:01 CET] <wm4> yeah I'm not sure if I get it [19:10:21 CET] <t_than> michaelni: Thanks for the response. Do you have in mind any resources that you think would be helpful (an academic paper or development-wise?) [19:11:05 CET] <JEEB> wm4: I stopped understanding it after I heard about the delay field [19:11:16 CET] <JEEB> negative timestamps = cut kind of made sense [19:11:25 CET] <JEEB> and I thought that was why the start_time was positive with mov [19:11:50 CET] <michaelni> t_than, thats a good question [19:12:04 CET] <wm4> the start_time is just informational (libavformat/libavcodec itself won't do anything with it) [19:12:17 CET] <JEEB> ok [19:12:19 CET] <wm4> as I understand it, the user can use it to rebase timestamps to 0 [19:12:26 CET] <wm4> e.g. if the stream starts at timestamp 24525634 [19:12:46 CET] <wm4> but with codec delay, the interactions with it are a bit more subtle [19:13:23 CET] <michaelni> t_than, maybe theres some recent paper that surveys dfferent lossless compression methods / compares them, that might be usefull but i dont know one specific that i culd point to [19:13:27 CET] <nevcairiel> thats what i do with it, rebase to zero, since directshow wants that [19:15:35 CET] <t_than> I'll look around then to see if I can find anything useful. In case I do, I'll let you know. [19:51:40 CET] <BBB> kierank: it doesnt smell like bullshit, it smells like the uttermost happiness [19:51:49 CET] <BBB> kierank: people who see bs move out as quickly as they can :-p [19:51:59 CET] <BBB> kierank: so the people left are still drinking the koolaid [19:52:56 CET] <BBB> michaelni: if youre gonna have hm work on ffv1, why not give him the ffv1 specs that were under construction? [19:53:07 CET] <BBB> michaelni: ts a standard isnt it? [19:54:37 CET] <michaelni> t_than, you can look at the ffv1 spec, its a good idea to learn about how ffv1 works but they wont directly tell you how it can be improved [19:54:40 CET] <michaelni> BBB ^ [19:56:11 CET] <BBB> to kno what can be improved, one must first know what it currently does [19:56:12 CET] <michaelni> http://www.ffmpeg.org/~michael/ffv1.html or http://www.ffmpeg.org/~michael/ffv1.pdf [19:57:31 CET] <michaelni> and also of course the source code libavcodec/ffv1*.c [20:07:26 CET] <cone-909> ffmpeg 03Vicente Olivert Riera 07master:ad16eff64ba7: mips: add support for R6 [20:07:27 CET] <cone-909> ffmpeg 03NagaChaitanya Vellanki 07master:285fda093732: Add tests for functions in hash.c [20:08:51 CET] <jamrial> michaelni: i was waiting (and hoping) for reimar to comment and push that instead, seeing how he's the maintainer [20:08:56 CET] <jamrial> but guess he missed the thread [20:09:23 CET] <jamrial> oh, nevermind, he just replied [20:11:24 CET] <michaelni> jamrial, yes, i just didnt want to let a student wait especially when he already is pinging a patch ... [20:11:49 CET] <jamrial> she said she's not going to apply for gsoc, though [20:12:10 CET] <jamrial> was this for outreachy? [20:13:48 CET] <michaelni> NagaChaitanya mentioned gsoc so i assume it was gsoc [20:14:45 CET] <michaelni> but "full time employed and a part time student." is a problem for both gsoc and outreachy [20:15:15 CET] <jamrial> she said she didn't qualify, yes [20:16:06 CET] <michaelni> maybe (s)he wrote the patch before realizing that (s)he will be full time employed during the summer [20:18:02 CET] <michaelni> just guessing, ask her or him (ive no idea about gender) why (s)he posted a qualification patch even tough she doesnt qualify due to employment ... [20:20:16 CET] <michaelni> either way iam happy about every contribution and some extra tests for better coverage really doesnt hurt ... [21:24:41 CET] <dinux5> I am getting error message: libavutil/buffer.h does not exist while compiling a file which includes avcodec.h [21:24:56 CET] <dinux5> but the file exists. Why is the error coming then? [22:15:05 CET] <kierank> 6:51 PM <"BBB> kierank: people who see bs move out as quickly as they can :-p [22:15:05 CET] <kierank> 6:52 PM <"BBB> kierank: so the people left are still drinking the koolaid [22:15:08 CET] <kierank> explains a lot actually [22:15:32 CET] <BBB> ;) [22:15:44 CET] <kierank> I guess that's what happens in a city oriented around one industry [22:17:26 CET] <Daemon404> kierank, the other possibility is detroit [22:48:04 CET] <jabashque> Hi, i'm a student who might be interested in applying for 2016's GSoC. I looked at the unmentored projects and saw the one relating to subtitles, and i'd like to know what i'm supposed to do once i successfully complete the the qualification task [22:48:23 CET] <jabashque> since there isn't an assigned mentor for that specific task [22:52:11 CET] <wm4> jabashque: for now, ask ubitux (he isn't going to mentor this, though) [22:53:46 CET] <ubitux> i can't tell more than what i said in the thread... [22:54:29 CET] <ubitux> you might not be the same person though, i'm refering to http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-March/191048.html [22:54:39 CET] <jabashque> yeah, i'm not the same person [22:55:50 CET] <jabashque> also, thank you for pointing me to that. [00:00:00 CET] --- Thu Mar 10 2016

1 0

ffmpeg.log.20160309
by burek 10 Mar '16

10 Mar '16

[02:26:12 CET] <mrec> the ffmpeg configure script is super complicated... [02:37:07 CET] <ethe> mrec: indeed, there's a lot to configure. [02:37:48 CET] <ethe> well, it's just large, which is why it looks very complicated. [02:39:48 CET] <mrec> if you want to trace where the ffmpeg binary is enabled or disabled it's almost impossible [02:40:14 CET] <mrec> it's very compact... [02:43:45 CET] <J_Darnley> mrec: would you prefer some autotools? [02:44:19 CET] <mrec> J_Darnley: I'd prefer some comments inside .. I'm digging my way through it [02:44:28 CET] <J_Darnley> :) [02:44:39 CET] <J_Darnley> true, it does lack those [02:44:39 CET] <ethe> mrec: I guess the point is that it's meant to be pretty self documenting [02:44:49 CET] <ethe> in terms of code clarity [02:44:51 CET] <mrec> try to trace which checks "ffmpeg" is going through! [02:44:53 CET] <mrec> good luck! [02:46:45 CET] <ethe> why do you need to trace it, it's all output into the config.log anyways [02:47:00 CET] <mrec> I want to modify it a little bit for my needs [02:47:11 CET] <mrec> it's okay I'm getting forward [02:52:12 CET] <mrec> I'm removing SDL1 and using it with SDL2 for testing (on MacOSX) [02:52:17 CET] <mrec> that's basically what I'm doing [02:52:27 CET] <mrec> seems to fail with SDL [02:53:31 CET] <J_Darnley> I was sure someone was working on that. [02:53:32 CET] <ethe> SDL -> SDL2 is a little more involved than changing the config [02:53:36 CET] <ethe> J_Darnley: me.. lol [02:57:06 CET] <mrec> I modified the source already and compiled it manually using gcc [02:57:34 CET] <ethe> ffplay, or the sdl device? [02:57:45 CET] <ethe> or both? [02:58:15 CET] <mrec> well a little bit more.. I split ffplay removed SDL from it completely and moved SDL to a separate file [02:58:32 CET] <mrec> finally I'll use it with cocoa [02:58:40 CET] <mrec> it works well so far [03:04:02 CET] <mrec> the sdl version check disabled it it wasn't just changing sdl-config to sdl2-config :-) [03:12:26 CET] <vladmg> guys, do you know how to install ffmpeg on centos with http://pastebin.com/jvKpP0c1 [03:12:52 CET] <vladmg> on ubuntu I use "sudo add-apt-repository ppa:kirillshkrogalev/ffmpeg-next" [03:13:17 CET] <furq> http://johnvansickle.com/ffmpeg/ [03:13:20 CET] <furq> are those builds not good enough [03:13:23 CET] <mrec> furq: I wouldn't do that [03:13:36 CET] <furq> ? [03:14:01 CET] <mrec> some existing applications might be linked against an older version and break if you compile and install the latest version [03:14:26 CET] <furq> those are static binaries [03:14:33 CET] <mrec> --enable-shared ? [03:15:06 CET] <mrec> if you remove it maybe ;-) [03:15:10 CET] <furq> you seem to have me confused with somebody else [03:15:25 CET] <mrec> oh with vladmg [03:15:27 CET] <mrec> sorry [03:15:42 CET] <vladmg> hahah [03:16:09 CET] <furq> anyway if i was stuck on centos i'd probably just use those static builds [03:16:19 CET] <furq> they don't have all the libraries from that paste but they have everything common [03:17:32 CET] <vladmg> ok, i will test [03:21:00 CET] <vladmg> furq: still not working.. i hate centos [03:21:13 CET] <vladmg> thanks anyway [04:18:22 CET] <t4nk624> Hi, does anyone know how to apply slow motion to only a specific time in an mp4? I can do it for the portion of video with this command: `ffmpeg -y -ss 00:02:10 -i KobeDunk.mp4 -filter:v "setpts=4.0*PTS" -t 10 slow-kobe-dunk.mp4` but what I would really like to do is have the whole original video and apply slow motion in that specific timeframe. Thank you very much for any help or links even if it's not a specific answer to my que [05:13:41 CET] <PrestonL> Trying to do a live audio stream with ALSA Stream Source -> Server says "RECEIVE_DATA", but when a client connects it just says, "WAIT_FEED" [05:14:06 CET] <PrestonL> When I kill ffserver, a brief second of audio gets played by the client. [05:14:10 CET] <PrestonL> Any ideas? [05:14:46 CET] <PrestonL> using ffmpeg 3.0 [05:14:59 CET] <PrestonL> for both server and the alsa source [05:15:12 CET] <PrestonL> does the same if I even try to stream a .ogg file to the server [05:51:41 CET] <jookiyaya> i need a player that can do menu on bluray [05:57:11 CET] <relaxed> jookiyaya: did you try vlc? [05:57:48 CET] <jookiyaya> yup [05:58:04 CET] <jookiyaya> why is it so hard to support menu [05:59:19 CET] <relaxed> probably because it requires java [06:00:25 CET] <jookiyaya> and? [06:00:44 CET] <jookiyaya> if it wasn't in java. then it would have supported menu by now? [06:01:28 CET] <jookiyaya> what about for dvd ,is it in java? [06:02:55 CET] <relaxed> no [06:03:35 CET] <jookiyaya> then what is it in? [06:17:47 CET] <relaxed> jookiyaya: vlc supports bluray menus [06:17:53 CET] <jookiyaya> it doesn't [06:17:58 CET] <jookiyaya> i just tried [06:18:39 CET] <jookiyaya> where does it say that it does [06:19:03 CET] <relaxed> google, as in #videolan [06:19:08 CET] <relaxed> ask* [06:27:49 CET] <galex-713> Hi, whats the common container for .flac and is it possible to include chapters in it? [06:29:39 CET] <TD-Linux> flac has its own container format by default and no, there are no chapters [06:29:48 CET] <TD-Linux> but you can do chapters with flac in matroska [06:30:09 CET] <TD-Linux> alternately, a separate cue file, or just separate flac files per chapter because you can play them back gaplessly [06:36:29 CET] <galex-713> TD-Linux: so I have to make an mka? [06:36:36 CET] <galex-713> whats a separatue cue file? [06:58:00 CET] <TD-Linux> a way to index into an audio file. not that great of a solution [06:58:59 CET] <galex-713> ANd whats about that? https://wiki.xiph.org/Chapter_Extension [06:59:05 CET] <galex-713> Is that supported by VLC? [07:03:38 CET] <galex-713> Oh wait that makes VLC crash [07:03:50 CET] <galex-713> And mplayer freeze [07:06:28 CET] <galex-713> Well no now I defined a chapter at 00:00:00.000 and mplayer just take a lot of time to seek [07:06:36 CET] <galex-713> but doesnt freeze [07:06:48 CET] <galex-713> VLC still crashes [07:09:03 CET] <galex-713> Removed chapters, VLC works [07:09:10 CET] <galex-713> Going to #vlc to see [08:17:50 CET] <jookiyaya> how do i cut videos without losing x264 encoding setting info [08:19:28 CET] <jookiyaya> and how come this command does not work? ffmpeg64 -ss 03:00 -i 1.mkv -to 29:00 -c copy R:\1.mkv -y [08:21:02 CET] <pzich> jookiyaya: what doesn't work about it? [08:21:24 CET] <jookiyaya> -ss 03:00 works but -to 29:00 doesn't work [08:22:15 CET] <relaxed> jookiyaya: see if it works with -ss after the input [08:22:16 CET] <jookiyaya> if the original video is 30 min, i want to cut 3 min of the beginning video and last 1 min of end of the video [08:22:17 CET] <pzich> if you're using -c copy, you'll need to copy at keyframes, and there may be other restrictions [08:22:34 CET] <jookiyaya> -ss part works [08:22:35 CET] <pzich> if you want frame/time accurate encoding, you'll probably need to re-encode [08:22:56 CET] <jookiyaya> if i do: ffmpeg64 -ss 00:00 -i 1.mkv -to 29:00 -c copy R:\1.mkv -y [08:22:58 CET] <jookiyaya> it works [08:23:09 CET] <pzich> -ss 0? [08:23:13 CET] <pzich> so, no seek? [08:23:43 CET] <jookiyaya> no [08:24:05 CET] <jookiyaya> if you have 30 min video, and if you want to cut 1st min of the video and the last 1 min of the video. what do you type [08:24:39 CET] <jookiyaya> ffmpeg64 -ss 01:00 -i 1.mkv -to 29:00 -c copy R:\1.mkv -y is it this? [08:25:21 CET] <relaxed> place -ss after the input [08:25:41 CET] <jookiyaya> no, that will screw up the video [08:26:00 CET] <relaxed> explain [08:26:20 CET] <jookiyaya> besides it's ss part that is working [08:26:27 CET] <jookiyaya> -to part that is NOT working [08:27:06 CET] <relaxed> you ask for help but assume you know everything [08:27:19 CET] <jookiyaya> i don't [08:27:24 CET] <relaxed> I believe with -ss after the input, -to will work [08:27:40 CET] <jookiyaya> i just know if you put -ss after then it screws up the video [08:27:44 CET] <jookiyaya> that part i do know [08:28:19 CET] <relaxed> "screw up" is vague [08:29:01 CET] <jookiyaya> when you play back the video, it won't play for about 3 seconds [08:29:16 CET] <jookiyaya> if you dont' believe me try it [08:29:40 CET] <kgkg_> Hiall. A small problem: I need to add a (silent) audio stream to an IPCamera Stream. I tried both -i anullsrc -i aevalsrc=0, which I found on some guides. Both produce a "No such file or directory". I'm on Win 10 with yesterdays ffmpeg build. [08:30:18 CET] <relaxed> jookiyaya: add -copyinkf [08:36:47 CET] <relaxed> kgkg_: did you use "-f lavfi -i aevalsrc=0" [08:36:49 CET] <relaxed> ? [08:38:38 CET] <jookiyaya> relaxed okay, what do i type exactly [08:39:32 CET] <relaxed> jookiyaya: try, ffmpeg64 -i 1.mkv -ss 01:00 -to 29:00 -c copy -copyinkf -y R:\1.mkv [08:39:48 CET] <jookiyaya> ok thanks [08:41:54 CET] <jookiyaya> it worked but i screwed up the video like i said [08:41:59 CET] <jookiyaya> it [08:42:18 CET] <relaxed> does audio start first? [08:42:30 CET] <jookiyaya> yes [08:42:39 CET] <jookiyaya> but cutting part worked [08:42:41 CET] <relaxed> add -async 1 [08:43:17 CET] <jookiyaya> can i just do this? ffmpeg64 -ss 01:00 -i 1.mkv -to 29:00 -c copy -copyinkf -y R:\1.mkv [08:44:00 CET] <relaxed> I don't think -to will work if -ss is before the input, which you've already found [08:44:19 CET] <relaxed> ffmpeg64 -i 1.mkv -ss 01:00 -to 29:00 -c copy -copyinkf -async 1 -y R:\1.mkv [08:45:43 CET] <jookiyaya> didn't work [08:45:58 CET] <jookiyaya> cutting part worked [08:47:23 CET] <jookiyaya> you are right: cutting park did not work with : ffmpeg64 -ss 01:00 -i 1.mkv -to 29:00 -c copy -copyinkf -y R:\1.mkv [08:47:28 CET] <jookiyaya> part* [08:48:35 CET] <relaxed> you may have to transcode, then [08:49:56 CET] <jookiyaya> i don't understand why this is so difficult [08:50:00 CET] <jookiyaya> [03:54] <c_14> ffmpeg -ss 1:00 -i input -t 58:00 out.mkv [08:50:00 CET] <jookiyaya> [03:54] <c_14> or ffmpeg -i input -ss 1:00 -to 59:00 out.mkv [08:50:00 CET] <jookiyaya> [03:55] <relaxed> maybe -copyinkf would help [08:50:00 CET] <jookiyaya> [03:55] <jookiyaya> oh, so i have to use -to instead of -t [08:50:00 CET] <jookiyaya> [03:57] <c_14> you can also use ffmpeg -ss 1:00 -i input -copyts -to 59:00 out.mkv [08:50:34 CET] <jookiyaya> what about what C_4 said? [08:52:56 CET] <jookiyaya> is that reencoding? [08:55:21 CET] <kgkg_> relaxed: no -f flv which I need to stream to youtube [08:58:29 CET] <jookiyaya> relaxed what does -copyinkf exactly do [09:00:27 CET] <kgkg_> relaxed: oh, I see complex filter for the input. now it wroks! thx a bunch! [09:05:21 CET] <jookiyaya> and is there way i don't lose the x265/x264 encoding setting info after i cut/edit the mkv file with ffmpeg [09:06:20 CET] <jookiyaya> x264 core 65 [09:06:21 CET] <jookiyaya> Encoding settings : cabac=0 / ref=5 / deblock=1:-2:-2 / analyse=0x1:0x111 / me=esa / subme=7 / psy_rd=1.0:0.0 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=1 / nr=0 / decimate=1 / mbaff=0 / bframes=0 / keyint=250 / keyint_min=25 / scenecut=40 / rc=2pass / bitrate=5840 / ratetol=1.0 / qcomp=0.70 / qpmin=10 [09:06:21 CET] <jookiyaya> / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00 [09:06:21 CET] <jookiyaya> Default : Yes [09:25:34 CET] <relaxed> jookiyaya: did you see https://trac.ffmpeg.org/wiki/Seeking ? Look at the bottom [09:26:05 CET] <jookiyaya> yes [09:42:33 CET] <rossome> so im running fedora with the nvidia binary driver. i have an i4790k capable of intel's quicksync. i've got libmfx and an ffmpeg binary with quicksync enabled [09:43:10 CET] <rossome> however i keep getting "Error initializing an internal MFX session" [09:43:40 CET] <rossome> is there a way i can tell ffmpeg to ignoe the nvidia driver and intels so i can make this configuration work? [09:44:05 CET] <rossome> ignor the nvidia driver and use intel's* [09:47:25 CET] <rossome> it looks like my motherboard does not have the igpu turned on, derp [09:50:31 CET] <relaxed> rossome: wouldn't nvenc be faster? [09:53:01 CET] <rossome> it would and is, however the 2 stream limit is a problem [09:53:34 CET] <rossome> i'm trying to get this to work with my emby install and i usually have 2+ streams going at once [09:54:00 CET] <relaxed> you have a beefy cpu too [09:54:14 CET] <rossome> wouldnt be a problem if i could afford a quadro card :'( [09:55:09 CET] <relaxed> yeah, they are spendy [09:55:39 CET] <rossome> here's a new rig i just build my buddy for the same purpose http://i.imgur.com/LJiLtJy.jpg [09:56:40 CET] <relaxed> couldn't you add another nvidia card? [09:57:11 CET] <rossome> not in my rig, and that one will eventually have an hba and a 10Gbit nic installed [09:57:38 CET] <rossome> my rig already has the extra pcie slots used up [09:58:24 CET] <relaxed> your cpu is enough to pick up the slack [09:59:04 CET] <rossome> totally is, it's just be nice to make it run that much more efficiently. the cpu in the imgur pic is an i7-6900k [09:59:47 CET] <rossome> we have no issues with transcoding as of now. i'd just like to utilize all available resources to the fullest [10:00:12 CET] <relaxed> enable intel's igpu and use it too [10:01:49 CET] <rossome> yeah that's what i was forgetting i think. hopefully with it enable in bios and no monitor plugged in, it's not being automatically disabled [10:02:26 CET] <rossome> im fairly certain on the 6900 rig its enabled but not showing up in lspci [10:02:34 CET] <rossome> enabled in bios* [10:04:19 CET] <rossome> ill play with it on mine later tonight [11:51:02 CET] <tuga> any one in where that can help compile ffmpeg with nvenc suport please [11:52:03 CET] <relaxed> tuga: sure [11:52:53 CET] <relaxed> tuga: http://johnvansickle.com/ffmpeg_nvenc.txt [11:53:20 CET] <relaxed> note: the latest nvidia SDK is 6.0.1 [12:05:41 CET] <marco_c> Good morning everyone! I have been trying to setup a stream from my webcam using ffmpeg and ffserver, but no luck. It seems that the server is receiving the data, but when I try to connect to the stream, I don't get any data. If I use the Preroll option, I do see the start of the stream, but then it stops. I'm sure I'm missing something silly... My current setup is here: http://pastebin.com/jbtaTnSL [12:06:37 CET] <marco_c> I am using version 3.0 on Mac (precompiled binaries). I adde the details about the versions of the libraries used on the paste [12:32:48 CET] <rossome> tuga: you still around? [12:33:54 CET] <tuga> yes i am where? [12:34:10 CET] <rossome> still need halp with nvenc? [12:34:14 CET] <tuga> yap [12:34:24 CET] <rossome> what os you runnin? [12:34:33 CET] <tuga> ubuntu 14.04 [12:34:40 CET] <rossome> ... [12:36:30 CET] <rossome> all you need to do is obtain nvEncodeAPI.h and put in in /usr/include/nvenc then run ldconfig [12:36:47 CET] <tuga> i tink i have done all [12:36:54 CET] <tuga> i tryed all the ways [12:36:58 CET] <rossome> https://developer.nvidia.com/video-sdk-601 [12:37:01 CET] <tuga> but seam like sdk 5.0 [12:37:03 CET] <tuga> is out date [12:37:09 CET] <rossome> i use the newest [12:37:33 CET] <tuga> i am tired to try and try [12:37:58 CET] <rossome> you're obviously using --enable-nvenc correct [12:37:59 CET] <rossome> ? [12:38:05 CET] <tuga> yap [12:38:21 CET] <tuga> and --enable-nvresize [12:38:21 CET] <rossome> is it compiling and installing? [12:38:36 CET] <tuga> no it is no compling [12:38:42 CET] <tuga> ift give a error on hx264 [12:38:44 CET] <tuga> :( [12:38:53 CET] <rossome> can you elaborate on the error [12:39:03 CET] <tuga> is compli once again [12:39:06 CET] <rossome> give me the full error message [12:39:10 CET] <tuga> i will tell you in a few seconds [12:39:15 CET] <rossome> k [12:39:29 CET] <tuga> libavcodec/libavcodec.a(libx264.o): na função `X264_init': /teste/ffmpeg/libavcodec/libx264.c:820: referência indefinida a `x264_encoder_open_1 collect2: error: ld returned 1 exit status make: ** [ffmpeg_g] Erro 1 [12:39:34 CET] <tuga> amazing [12:40:44 CET] <rossome> apt-get install libx264-dev [12:41:14 CET] <tuga> already done this [12:41:22 CET] <rossome> or try libavcodec-extra [12:42:06 CET] <rossome> the problem is with your x264 library not nvenc [12:42:22 CET] <tuga> trying the extra [12:42:44 CET] <tuga> --extra-cflags="-I"$HOME"/nvenc_5.0.1_sdk/Samples/common/inc" [12:42:51 CET] <tuga> what i put on $home? [12:43:10 CET] <rossome> dont do that [12:43:19 CET] <rossome> you do not need to [12:43:35 CET] <tuga> what i do? [12:43:36 CET] <rossome> is nvEncodeAPI.h in /usr/include ? [12:44:43 CET] <tuga> nvEncodeAPI 163 kb [15:07:52 CET] <leonora> Hi! [15:08:12 CET] <leonora> I'd like to create a timelapse video with ffmpeg, can some one help me with that? [15:08:32 CET] <flux> leonora, so in practice you have a lot of images you want to convert into a video? [15:08:41 CET] <leonora> flux: exactly [15:18:21 CET] <relaxed> leonora: https://trac.ffmpeg.org/wiki/Create%20a%20video%20slideshow%20from%20images [15:48:20 CET] <j03> /join #postgis [15:48:22 CET] <j03> oops [16:51:50 CET] CTCP VERSION: from PrestonL (PrestonL!~Preston(a)node3.thefirehorn.com) to #ffmpeg [17:16:27 CET] <_ggg_> Hi all, I'm trying to write some color converter in C and using ffmpeg. At this moment I'm stucked as I got some distorted frame. I've posted the code and image here: http://stackoverflow.com/questions/35894522/how-to-extract-grayscale-image-… Has anybody some hints? Thanks in advance [17:26:44 CET] <kepstin> _ggg_: looks like you didn't update the ppm header to say that the image you wrote is greyscale [17:27:39 CET] <kepstin> probably want to change the P6 to P5 - also, you want to use the 'GREY8' pixel format, not 'GREY16' [17:47:29 CET] <_ggg_> Hello Kepstin, I've edited the code like you wrote but now there's some zoom problem. The inner part is zoomed into the picture and the rest is cropped. Any further hints? I've added a comment at http://stackoverflow.com/questions/35894522/how-to-extract-grayscale-image-… too [18:25:56 CET] <Boscop> hi. is it possible to use the ffmpeg library to build a program that acts as a filter in a webcam stream? [18:26:09 CET] <Boscop> (for both audio and video) [18:26:23 CET] <Boscop> on windows [18:26:27 CET] <Boscop> with low latency [18:28:48 CET] <Boscop> so essentially the question boils down to, if virtual camera output is possible with ffmpeg? [18:31:02 CET] <Boscop> DirectShow output [18:33:11 CET] <Mavrik> There's no DS output in ffmpeg at this time. [18:33:16 CET] <Mavrik> You could use the API and write your own tho. [18:47:39 CET] <gvas> Hi. I'd like to downsample an audio file to ~1 sample/s. The new sample should be the moving average of the source samples. For .vox files I have tried the following switches: [18:47:47 CET] <gvas> ffmpeg -f s16be -ar 8000 -c adpcm_ima_oki -i source.vox -af aresample=1 -map 0:a -c pcm_u8 -f data out.dat [18:47:56 CET] <gvas> The resulting .dat file contains only 0x80 and 0x7F bytes, and the transcoding is very slow. Can somebody help me with the correct command line switches? [19:08:33 CET] <lroe> anyone have any good ideas for load testing a live internet stream? [19:09:30 CET] <JEEB> write emulated clients to connect to it from various VMs that you can punch into any "cloud" provider available [19:10:25 CET] <JEEB> or if you are wanting to maximize load and not emulate an actual user, just wham the streaming server by getting all of the segments :P [19:10:42 CET] <JEEB> (I will guess this is using one of the HTTP based streaming things) [19:11:58 CET] <lroe> yea an HLS stream [19:13:33 CET] <ninjudd_> is there a way to get the total duration of the video as a variable for use in a filter? [19:14:15 CET] <ninjudd_> specifically, i want a crop filter that will pan from left to right and back, ending at the far right exactly when the video ends. [19:16:07 CET] <durandal_1707> nope [19:18:17 CET] <ninjudd_> ok. good to know :) I'll stop searching for it and just hardcode it [20:56:01 CET] <SpeakerToMeat> Hello [20:57:05 CET] <SpeakerToMeat> When I'm working with independant pictures for each frame as input, a) the right form would be (for files called 000000.j2c onwards) "-start_number 0 -i %06d.j2c" right? and b) how do I tell ffmpeg to interpret input format to be at a 24fps cadence? [20:58:02 CET] <furq> yes, and -framerate 24 (before -i) [20:58:23 CET] <SpeakerToMeat> Thanks [20:58:40 CET] <SpeakerToMeat> Can I mux audio files with the images to produce a full audio/vid output in a single run? [20:58:45 CET] <furq> sure [20:58:49 CET] <SpeakerToMeat> Do I just add more -i ? [20:58:57 CET] <furq> yeah it's the same way as it would work for a video [21:00:07 CET] <SpeakerToMeat> Perfect, tyvm, I guess ffmpeg recognizes the image files as a single video track, and audio files as audio tracks... what about if I have audio in 2 mono files, should I premux them into a stereo? or can I use 2 -i and specify each to be left/right channel? [21:00:35 CET] <furq> https://trac.ffmpeg.org/wiki/AudioChannelManipulation#a2monostereo [21:00:42 CET] <SpeakerToMeat> Thank you [21:01:40 CET] <SpeakerToMeat> furq: That is a supreme guide! My heartfelt thanks [21:08:05 CET] <SpeakerToMeat> furq: Stream specifier ':a' in filtergraph description [0:a][1:a]amerge=inputs=2[aout] matches no streams [21:08:39 CET] <SpeakerToMeat> Yet it recognizes the audio files being read: Stream #1:0: Audio: pcm_s24le ([1][0][0][0] / 0x0001), 48000 Hz, 1 channels, s32 (24 bit), 1152 kb/s [21:09:08 CET] <furq> it should presumably be 1:a and 2:a [21:09:22 CET] <SpeakerToMeat> Ah of course [21:09:26 CET] <SpeakerToMeat> since streams are 1 and 2 [21:09:39 CET] <SpeakerToMeat> Bingo. thanks [21:10:32 CET] <llogan> don't forget to add a -map for your video too [21:11:35 CET] <SpeakerToMeat> llogan: Yes I just found out..... [21:11:38 CET] <SpeakerToMeat> humm [22:32:05 CET] <radu> hi! I'm processing a live stream into a mpeg1 file, however I can't tell if I'm using any GPU acceleration and if it's possible at all [22:32:07 CET] <radu> http://pastebin.com/rdnpWipa [22:32:22 CET] <radu> I'm not specifying any codecs [22:33:16 CET] <J_Darnley> no, you're not [22:33:21 CET] <radu> I run multiple processes on a server and it's starting to choke.. probably normal [22:34:11 CET] <radu> I've read the HWAccelIntro doc [22:34:33 CET] <radu> If I have an Intel Video Card and I use -c:v h264_qsv it would make things better fe? [22:34:50 CET] <J_Darnley> If you want to run several, I doubt it [22:35:04 CET] <J_Darnley> last I heard hardware decoders didn't like being shared [22:35:15 CET] <radu> oh, didn t know that [22:35:17 CET] <radu> :) [22:35:57 CET] <JEEB> it's basically an ASIC [22:36:11 CET] <JEEB> so it's limited in its performance by the drivers and the ASIC's capabilities [22:37:13 CET] <J_Darnley> I wouldn't expect your use to be that demanding [22:37:29 CET] <J_Darnley> What CPU is it running on? [22:37:42 CET] <J_Darnley> What options was ffmpeg compiled with? [22:37:46 CET] <jkqxz> Intel hardware can easily run multiple streams simultaneously, in independent processes or not (at least, it can using the vaapi/libva on Linux). [22:38:47 CET] <radu> CentOS Intel Core i7 (Nehalem Class Core i7), 8-core, 8GB RAM [22:38:58 CET] <radu> it's ok atm, running ~16 processes like the above [22:39:04 CET] <radu> but I need to add more, double that [22:39:23 CET] <radu> I'm basically doing the jsmpeg thing: http://phoboslab.org/log/2013/09/html5-live-video-streaming-via-websockets [22:39:29 CET] <jkqxz> Nehalem doesn't have any graphics hardware. [22:39:30 CET] <kepstin> radu: nehalem doesn't support qsv (it doesn't have a gpu video decoder block) [22:39:43 CET] <radu> I know, I was wondering if it'd improve with different hardware [22:41:02 CET] <kepstin> hmm. you'd be using it for the decoder only (it doesn't support encoding mpeg1). It's hard to say, but it might free up some cpu for encoding the output stream, i guess? [22:43:29 CET] <J_Darnley> Even if you don't use the qsv feature, a better CPU will speed things up a little. [22:44:10 CET] <kepstin> nehalem is a pretty old core design, it doesn't even support AVX extensions :) [22:44:47 CET] <kepstin> (although that would only affect the decoder if anything, i doubt anyone's done avx optimizations to the mpeg1 encoder ;) [22:45:08 CET] <radu> I m not a hardware guy :) I'll look into that [22:45:11 CET] <radu> thank you! [22:53:04 CET] <roddyr> Greetings, first and foremost great code! [22:53:46 CET] <roddyr> Could you please assist with a command to add a wav file (audio) to a mp.4 video file? [22:55:12 CET] <c_14> ffmpeg -i wav -i mp4 -map 0 -map 1 -c:v copy -c:a aac out.mp4 [22:55:33 CET] <roddyr> I've crafted "ffmpeg -i video.mp4 -i audio.wav -c:v copy -c:a aac -strict experimental merged.mp4" and it successfully runs, but no audio in the mp.4 afterwards. [22:55:44 CET] <roddyr> Thank you let me give that a try right now! [22:56:53 CET] <kepstin> your command should have worked; if there's no '-map', it'll use all streams [22:57:39 CET] <c_14> "all" [22:57:44 CET] <c_14> 1 audio, 1 video and 1 subtitle [22:58:40 CET] <kepstin> hmm, right, if the video file already had an adio track... [22:59:03 CET] <kepstin> might want -map 0:v -map 1:a then [23:01:22 CET] <roddyr> FANTASTIC! [23:01:32 CET] <roddyr> ffmpeg -i wav -i mp4 -map 0 -map 1 -c:v copy -c:a aac out.mp4 [23:01:40 CET] <roddyr> did the trick, AWSOME code! [23:01:44 CET] <roddyr> Thank you! [23:16:46 CET] <roddyr> Greetings, after successfully adding a wav file to a mp4, on my local machine the mp4 wroks great, i.e. vid and audio. I've uploaded to youtube, now no audio. [23:17:27 CET] <roddyr> we used: ffmpeg -i wav -i mp4 -map 0 -map 1 -c:v copy -c:a aac out.mp4 [23:18:09 CET] <roddyr> I'm researching, and so far all we have seen is "To get a single file, with both the Audio & Video Streams, you want Multiplexing set to anything but "None."" [23:18:22 CET] <roddyr> Could this be the problem, i.e. Multiplexing? [23:20:59 CET] <c_14> Can you upload an ffprobe of the file to a pastebin service? [23:22:33 CET] <roddyr> Did not try, could you please recommend a known good pastebin service? [23:22:43 CET] <c_14> sprunge.us ix.io [23:24:19 CET] <roddyr> could you please share the ffprob syntax? [23:24:43 CET] <c_14> ffprobe file [23:27:32 CET] <roddyr> Thank you for your help! ffprobe file all good, syntax to upload an ffprobe of the file to sprunge.us ix.io. I'm on Linux... [23:27:50 CET] <J_Darnley> Copy, paste! [23:28:23 CET] <roddyr> sprunge.us ix.io copy-paste-output? [23:28:43 CET] <furq> is there some way to prevent version.sh from running at compile time (i'm running it before configure to get around this ropey build system) [23:28:55 CET] <furq> i tried touch .version but it still seems to run [23:29:00 CET] <J_Darnley> Change the makefile? [23:29:06 CET] <furq> ideally without changing the makefile [23:30:08 CET] <c_14> roddyr: sprunge.us has a form you can use to paste into, that or pipe into curl -F 'sprunge=<-' http://sprunge.us [23:30:28 CET] <furq> maybe i'm reading the makefile wrong but it looks like version.sh shouldn't run if .version is present [23:35:30 CET] <roddyr> ffprobe mp4 | curl -F 'sprunge=<-' http://sprunge.us ix.io [23:35:44 CET] <c_14> without the ix.io [23:36:14 CET] <roddyr> Thank you: http://sprunge.us/Ojhd [23:36:45 CET] <c_14> you probably need |& instead of | [23:37:20 CET] <roddyr> Thank you for your help c_14! [23:37:46 CET] <roddyr> and J_Darnley [23:37:59 CET] <roddyr> 100% new to ffmpeg [23:38:22 CET] <J_Darnley> 100% new to computers too by the look of things. [23:38:30 CET] <roddyr> :-) [00:00:00 CET] --- Thu Mar 10 2016

1 0

ffmpeg-devel.log.20160308
by burek 09 Mar '16

09 Mar '16

[00:19:50 CET] <darkapex> atomnuker: ping [00:22:19 CET] <atomnuker> darkapex: pong? [00:23:21 CET] <darkapex> Hi, I was working on updating the mlpenc.c file in the latest master of ffmpeg, some of my commits are here https://github.com/jailuthra/FFmpeg/tree/mlpencoder [00:23:58 CET] <darkapex> It would be cool if you could review it and tell me if there are some glaring errors or if I'm doing something wrong [00:25:41 CET] <darkapex> Plus the old encoder file is accessing some FilterParams members that never existed, I haven't exactly figured what should I exactly use in place of them. [00:26:18 CET] <atomnuker> that malloc/free gets called on every frame, right? [00:26:42 CET] <atomnuker> better do it in the init/close functions for the maximum filter count [00:26:46 CET] <darkapex> Yep, I had some doubts here too, whether it would be suboptimal [00:27:09 CET] <darkapex> Okay [00:38:45 CET] <darkapex> Most of the compiling errors got fixed by fixing all the VLA issues, still some remain, and I think the git-history of ramiro's soc repo will point me to how to use coeff_bits. Here's the current make output http://pastebin.com/raw/XNrVcDTs [00:39:21 CET] <darkapex> *FilterParams.coeff_bits and coeff_shift [00:39:32 CET] <darkapex> I'll ping you if I need help, thanks :) [00:47:58 CET] <atomnuker> cool, nice progress [00:48:53 CET] <atomnuker> if in doubt, just look at what the decoder does [00:52:03 CET] <darkapex> sure thanks a lot :) [02:57:10 CET] <cone-792> ffmpeg 03Michael Niedermayer 07master:de1de4932419: avformat/utils: fix dts from pts code in compute_pkt_fields() during ascending delay [05:34:10 CET] <rcombs> how long has sofacoustics.org been down [05:34:19 CET] <rcombs> (it's mentioned in the filters docs) [05:38:52 CET] <cone-792> ffmpeg 03Michael Niedermayer 07master:50615791ca8c: fate: Add test similar to ticket 1242 [07:08:46 CET] <Timothy_Gu> Daemon404, nevcairiel: speak of the devil: https://github.com/FFmpeg/FFmpeg/pull/185/files [07:28:51 CET] <twid> what is the exact purpose of libpostproc? [07:33:53 CET] <sprkv5> hello durandal_1707 , i presume you're the mentor for "motion interpolation in libavfilter" [07:34:36 CET] <sprkv5> I am Subhashish, CS undergrad and I am interested in taking up this project. [07:43:24 CET] <twid> what is libpostproc is exactly used for? [09:20:42 CET] <durandal_1707> sprkv5: questions? [09:39:45 CET] <sprkv5> hello again durandal_1707 [09:41:27 CET] <durandal_1707> sprkv5: hello [09:42:55 CET] <sprkv5> Motion interpolation, I read about it here - https://github.com/mpv-player/mpv/wiki/Interpolation [09:44:36 CET] <sprkv5> So my first question is - am looking at the right explanations? Or does libavfilter require something different? [09:46:34 CET] <wm4> that wiki article briefly compares different types of interpolation [09:46:48 CET] <wm4> I assume what's wanted here is "Motion-based interpolation" [09:51:19 CET] <durandal_1707> sprkv5: yes, it even lists existing implementations [09:53:47 CET] <sprkv5> Second, I would like to learn the architecture of libavfiilter, the way to hack and learn would be? would it be better if I try to solve bugs related to libavfilter or start with the implementation? [09:56:46 CET] <sprkv5> this should help right? https://www.ffmpeg.org/ffmpeg-filters.html [09:57:08 CET] <wm4> try to find out how simple filters work [09:57:27 CET] <wm4> maybe things like vf_crop and vf_lut are good places to start [09:57:41 CET] <sprkv5> okay [09:57:58 CET] <sprkv5> what would be the test files if any? [09:59:08 CET] <durandal_1707> sprkv5: the only thing you need to create for qualification task is creating frame side data with motion vectors [09:59:46 CET] <durandal_1707> sprkv5: any nonstatic video file [10:00:55 CET] <wm4> that sounds like a quite heavy qualification task [10:01:49 CET] <durandal_1707> the motion vectors don't need to be perfect [10:03:18 CET] <durandal_1707> but project is really non trivial one [10:03:45 CET] <ubitux> sprkv5: http://git.videolan.org/?p=ffmpeg.git;a=blob_plain;f=doc/writing_filters.tx… [10:05:19 CET] <sprkv5> okay, the writing filters doc is a path ahead, i'll look into it; [10:06:01 CET] <sprkv5> i'll also look into the generation of motion vectors from the frames of the video and report back with simple implementations [10:06:37 CET] <ubitux> you might want to have a look at the codecview filter [10:08:07 CET] <sprkv5> thanks! [10:09:01 CET] <sprkv5> my contact mail is sprkv5(a)gmail.com, i've subscribed to the ffmpeg-devel mailing list [10:22:36 CET] <BtbN> "bobobo-at-google.com(a)ffmpeg.org" huh, does the ML do that, or is this his actual email address? [10:24:28 CET] <ubitux> i saw that with mats as well [10:24:45 CET] <ubitux> maybe a privacy option in the ml? [10:25:01 CET] <BtbN> well, it's kinda useless as the real bobobo(a)google.com is in the mail headers [10:26:02 CET] <ubitux> i don't think scammers often register to ml to get mails [10:26:15 CET] <ubitux> more likely they're crawling archives etc [10:26:30 CET] <BtbN> hm, yeah. So i wonder which E-Mail I should put as git author [10:27:39 CET] <ubitux> Author: Wan-Teh Chang <wtc-at-google.com(a)ffmpeg.org> [10:27:44 CET] <ubitux> Author: Mats Peterson <matsp888-at-yahoo.com(a)ffmpeg.org> [10:28:08 CET] <ubitux> probably mistakes but a common one [10:28:12 CET] <ubitux> :) [10:28:57 CET] <BtbN> I can't figure out a propper workflow to apply E-Mail based patches, so I apply them manualy. Probably wouldn't have noticed otherwise either. [11:09:29 CET] <michaelni> ubitux, alot of your fate clients seem to have an issue with iv8-demux, not sure but ive not seen this locally ... [11:11:43 CET] <ubitux> huh yeah wtf is wrong [11:14:54 CET] <michaelni> ubitux, btw, about <wtc-at-google.com(a)ffmpeg.org> <-- that from rewriting is needed due to DMARC otherwise the mail will bounce as our mail server is not authorized to send @google.com mails [11:15:15 CET] <michaelni> it will become more common likely and sadly [11:21:56 CET] <cone-836> ffmpeg 03Lucas Cooper 07master:fd55470c657f: avcodec/nvenc: Add encoder stats [11:21:56 CET] <cone-836> ffmpeg 03Timo Rothenpieler 07master:f2bdf9d26a23: avcodec/nvenc: Fix typo and preset error message [11:32:59 CET] <BtbN> So does ffmpeg now redirect all mails it gets in response to such addresses, or do they just bounce? [11:39:52 CET] <cone-836> ffmpeg 03Lior Mualem 07master:baec6d8affc6: ffserver: Fixed ffserver to support large ffm files [11:40:01 CET] <ubitux> michaelni: http://sprunge.us/OXOd [11:40:10 CET] <ubitux> this should be 7a97e6e1d0c79d4c5687f5b552e33a0d [11:40:22 CET] <ubitux> rsync might be broken either client or server side [11:42:00 CET] <ubitux> there is like 1 bit off [11:42:42 CET] <michaelni> ubitux, maybe try -c, --checksum skip based on checksum, not mod-time & size [11:43:05 CET] <ubitux> rsync: The server is configured to refuse --checksum (-c) [11:43:28 CET] <ubitux> was that file introduced recently btw? [11:43:41 CET] <BtbN> maybe some bitrot on the hdd? [11:43:51 CET] <ubitux> i checked dmesg, no i/o errors [11:44:09 CET] <BtbN> well, a bit flipping wouldn't cause any errors [11:44:19 CET] <ubitux> i just want to check if it's a fs issue (maybe raid bug) [11:44:26 CET] <ubitux> or if it's a transmission issue [11:46:21 CET] <ubitux> so iv8-demux wasn't introduced recently, so it's unlikely a transmission issue (i didn't remove the samples recently) [11:46:45 CET] <ubitux> so i guess that's a raid issue of some sort... [11:48:39 CET] <ubitux> anyway, i rm'ed the file and updated the samples again [11:51:56 CET] <BtbN> A single bit flipping in files isn't very uncommon. [11:53:28 CET] <BtbN> Since i migrated my server to ZFS it already corrected 2 checksum errors. [12:12:46 CET] <cone-836> ffmpeg 03Paul B Mahol 07master:f78ef2d885aa: avfilter/vf_vectorscope: short for Magenta is Mg [13:42:15 CET] <durandal_1707> michaelni: this format negotiation in lavfi needs to be extended [13:49:45 CET] <ismail> finally sent the schannel configure patch [13:49:51 CET] <ismail> please review :) [14:02:17 CET] <J_Darnley> You claim that it won't break because Windows is case insensitive. I must try it then. [14:05:12 CET] <ismail> please [14:08:17 CET] <J_Darnley> Oh you said msvc. I guess I can't test that part then. [14:08:23 CET] <J_Darnley> sorry [14:09:15 CET] <nevcairiel> you could still try whatever is on your mind [14:09:21 CET] <ismail> J_Darnley: do you have msys on windows? That would be also good to test [14:10:02 CET] <J_Darnley> No. I use cygwin or cygwin's mingw64 compilers and my libraries are lowercase [14:10:16 CET] <ismail> J_Darnley: ok thats the same case as Linux [14:10:24 CET] <ismail> so it'll work for you too [14:10:34 CET] <nevcairiel> cygwin is actually smart though, it ignored the case before already [14:10:57 CET] <ismail> true [14:11:04 CET] <J_Darnley> Except I am looking to make it fail because I enabled case sensitivity long ago. [14:12:20 CET] <ismail> it would already fail for you before the patch. [14:12:28 CET] <ismail> it looks for uppercase Secur32 lib [14:13:07 CET] <nevcairiel> because thats how the microsoft sdk lib is named :D [14:13:18 CET] <ismail> nevcairiel: yes true. [14:13:58 CET] <nevcairiel> security.h is lowercase even in the ms sdk though [14:14:08 CET] <nevcairiel> the docs just have it uppercase [14:14:24 CET] <ismail> so we are halfway there already ;) [14:26:43 CET] <Daemon404> Timothy_Gu, you make me sad [14:28:44 CET] <guest___> @michaelni: Sir can you tell me which type of bugs are we related to the project in ffmpeg [14:36:20 CET] <durandal_1707> guest___: which project? [14:37:55 CET] <guest___> @durandal_1707: Project which you are in involving in the GSoC. I am asking about the kind of bugs we have to deal with within this project? [14:39:25 CET] <durandal_1707> I'm still confused, for list of bugs see trac.ffmpeg.org [14:41:15 CET] <guest___> @durandal_1707: Can you tell me more that how can i contribute in your open source projects? [14:41:40 CET] <toot> maybe you mean this list? https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016 [14:43:44 CET] <guest___> @toot: Yes,I am talking about one of your project named Improve Selftest coverage. I wanted to know more about it? [14:48:35 CET] <arthcp> For GSOC I would like to work on the project to implement missing features in AAC decoder [14:48:50 CET] <arthcp> It doesn't have a mentor [14:49:01 CET] <arthcp> how exactly should I proceed? [14:49:55 CET] <arthcp> Do I search for a mentor first or do I directly start working on the qualification task? [14:53:09 CET] <wm4> arthcp: you should first make sure that you have a mentor [14:53:48 CET] <cone-836> ffmpeg 03Muhammad Faiz 07master:fd0c9789cfe8: avfilter/avf_showcqt: add performance debugging log [14:55:20 CET] <arthcp> wm4: do i ask people individually for mentor me? [15:00:22 CET] <BBB> find people who know something about aac [15:00:37 CET] <atomnuker> IMO that project is challenging [15:00:38 CET] <BBB> e.g. git log libavcodec/aacdec.c and look at authors of relevant patches touching actual coding technology [15:00:44 CET] <atomnuker> too challenging [15:00:46 CET] <BBB> atomnuker is one of them :) [15:01:41 CET] <Daemon404> im pretty sure asking people to find their own mentor is not gsoc olicy [15:01:43 CET] <Daemon404> policy* [15:01:49 CET] <Daemon404> that's supposed to be our job [15:02:04 CET] <arthcp> I talked to thilo regarding another project about implementing mpeg4 als encoder [15:02:15 CET] <arthcp> he said that too is very challenging [15:02:32 CET] <atomnuker> everything in the encoder and decoder assumes that the window sizes are 128 or 1024, so it'd be hard to actually fit support for 960/120 without huge amounts of duplication and/or breakages [15:03:01 CET] <Daemon404> or giant macros [15:03:16 CET] <Daemon404> a simple way is to do something like [15:03:27 CET] <Daemon404> #define WINDOW_SIZE 960 [15:03:31 CET] <Daemon404> #include "implementayion.c" [15:03:33 CET] <Daemon404> in 2 files [15:03:35 CET] <Daemon404> or w/e [15:04:01 CET] <atomnuker> that file would be templated 4 times over even in that case (for fixed and float decoders) [15:04:14 CET] <Daemon404> blame the people who [15:04:18 CET] <Daemon404> made aac [15:04:18 CET] <Daemon404> ? [15:04:22 CET] <atomnuker> SSR would be just as challenging [15:05:59 CET] <arthcp> I have worked with audio previously [15:06:34 CET] <arthcp> and my college has a multimedia teacher who could help me out if needed [15:07:05 CET] <arthcp> I think i'll give the project a try [15:08:19 CET] <arthcp> is there anybody here who could mentor me? [15:15:17 CET] <guest___> quit [15:17:09 CET] <durandal_1707> arthcp: and what would be your qualification task? [15:18:00 CET] <arthcp> I need to fix a bug related to AAC [15:18:16 CET] <arthcp> I haven't selected a bug yet [15:20:46 CET] <durandal_1707> well, if you really want aac project you would need to complete that qualification task, I can be your mentor. [15:21:40 CET] <durandal_1707> and isn't policy that you code alone? [15:21:48 CET] Action: rcombs points at PCEs [15:22:35 CET] <rcombs> ^ fair bit of that is already done thanks to atomnuker, in general it shouldn't be too complex, and it'd probably at least give you a good look around at least some parts of the encoder [15:22:44 CET] <arthcp> durandal_1707: i'll code alone i was just saying he could mentor me if need be [15:23:51 CET] <arthcp> but now that i have a mentor, it wouldn't be required [15:24:41 CET] <arthcp> durandal_1701: do you want me to work on any specific bug? [15:27:32 CET] <durandal_1707> no, feel free to pick any aac related [15:28:14 CET] <durandal_1707> tell me which so I could tell you if its fine [15:28:34 CET] <arthcp> okay! i'll inform you in some time. [15:33:47 CET] <cone-836> ffmpeg 03Mats Peterson 07master:e1aa88dc09a7: lavf/avienc: Palette changing code only concerns AV_PIX_FMT_PAL8 [16:43:49 CET] <cone-836> ffmpeg 03Moritz Barsnick 07master:72babb8566bd: lavc/mjpegdec: avoid printing useless message in default log level [17:03:10 CET] <cone-836> ffmpeg 03Moritz Barsnick 07master:8a90e0fd21f7: lavf/mp3dec: avoid printing useless message in default log level [17:38:29 CET] <cone-836> ffmpeg 03Shivraj Patil 07master:b59d06d5f415: configure: add check_inline_asm_flags() [17:38:30 CET] <cone-836> ffmpeg 03Shivraj Patil 07master:8ca2c872b650: configure: build fix for P5600 with mips code restructuring [17:48:57 CET] <nevcairiel> rcombs: dont get your hopes up, the task is about decoding =p [17:49:04 CET] <rcombs> ah [17:57:49 CET] <atomnuker> yes, we can decode PCEs, but no idea whether the channel mapping will be correct [18:02:07 CET] <kierank> peloverde: quite interesting what these argon people have done [18:02:11 CET] <kierank> with their "spec compiler" [18:02:19 CET] <Daemon404> argon? [18:19:09 CET] <nevcairiel> Daemon404: http://www.argondesign.com/products/argon-streams-hevc/ [18:19:38 CET] <nevcairiel> also vp9 i think [18:49:16 CET] <Zeranoe> Are there H.264 decoder features that are GPL only and thus will be disabled with an LGPL build? [18:49:58 CET] <Daemon404> i dont think so [18:51:20 CET] <Zeranoe> Does it support other profiles than Main? [18:51:29 CET] <JEEB> yes [18:51:30 CET] <Zeranoe> (If built for LGPL) [18:51:54 CET] <JEEB> there's actually not that much GPL-specific stuff in general within libavcodec [18:52:00 CET] <JEEB> some MPEG-2 asm from libmpeg2 I think? [18:52:03 CET] <JEEB> some FLAC asm? [18:52:15 CET] <nevcairiel> there is like one optimized DSP function thats GPL only [18:52:23 CET] <Daemon404> and its mmx or something [18:52:24 CET] <nevcairiel> so it might be minimally faster in GPL [18:52:35 CET] <jamrial> Zeranoe: h264 doesn't care what license you choose [18:53:53 CET] <Shiz> i always wondered if there was a list of gpl stuff... [18:54:02 CET] <jamrial> license.md [18:54:20 CET] <nevcairiel> most gpl components are avfilter things [18:54:23 CET] <jamrial> but it's not 100% correct. it mentions a libavcodec/x86/idct_mmx.c file that doesn't exist [18:54:35 CET] <nevcairiel> it keeps being forgotten when things are refactored [18:54:49 CET] <JEEB> http://up-cat.net/p/6c73933c [18:55:21 CET] <JEEB> although I guess those are just things that get changed during compilation [18:55:34 CET] <JEEB> configure just disables something altogether if the license is not compatible [18:55:35 CET] <Zeranoe> So to summarize: The internal H.264 decoder will preform the same (speed wise) and contain the same features regardless of the licenses FFmpeg is built with? [18:55:47 CET] <JEEB> Zeranoe: yes [19:01:22 CET] <Zeranoe> Thank for the clarification. I asked because ramiro seems to have been under a different opinion: https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=311#p991 [19:02:01 CET] <JEEB> that probably includes all of the rest around it [19:02:34 CET] <JEEB> I'm not sure if the AVC decoder uses those libmpeg2 optimizations that you can notice being matched in my grep :P [19:02:55 CET] <Timothy_Gu> JEEB: in ppc optim there's a comment on libmpeg2 [19:03:08 CET] <Timothy_Gu> the author seems to have released it under LGPL for FFmpeg [19:04:00 CET] <JEEB> Timothy_Gu: isn't the me_cmp stuff under GPL from there? [19:04:26 CET] <Timothy_Gu> /shrug [19:04:29 CET] <JEEB> ok, so this definitely is one thing under GPL [19:04:31 CET] <JEEB> SET_CMP_FUNC(dct264_sad) [19:04:36 CET] <JEEB> in me_cmp.c [19:04:44 CET] <Timothy_Gu> It's not used anywhere though [19:05:03 CET] <Timothy_Gu> See http://coverage.ffmpeg.org/src/libavcodec/me_cmp.c.gcov.html [19:05:09 CET] <Timothy_Gu> l. 388 [19:05:11 CET] <JEEB> hah [19:05:56 CET] <Daemon404> BBB, you are talking to a wall [19:24:49 CET] <BBB> Daemon404: ? [19:24:59 CET] <Daemon404> mats [19:25:05 CET] <Daemon404> in one ear, out the other [19:25:08 CET] <Daemon404> spam keeps coming [19:26:50 CET] <BBB> very frustrating [19:34:44 CET] <jamrial> if he doesn't stop just force unsubscribe him from the ml so his emails have to be moderated. that way all the nonsense self replies can be ignored and only the latest iteration of every patch is allowed to pass through at the end of the day [19:35:00 CET] <Daemon404> thats a huge workload for the mod [19:35:07 CET] <Daemon404> remember 20% of all ML traffic is him [19:35:58 CET] <thardin> mats list [19:36:06 CET] <BBB> mats-list(a)ffmpeg.org? [19:36:26 CET] <Daemon404> whats with his email btw [19:36:39 CET] <Daemon404> its like his-email-at-yahoo-dot-com(a)ffmpeg.org [19:36:41 CET] <Daemon404> or something [19:37:22 CET] <JEEB> seemingly mail servers have an issue with ffmpeg.org MX sending e-mails for random addresses [19:45:56 CET] <nevcairiel> mailing lists arent exactly a new invention, you would think there would be a proper solution to those [20:00:48 CET] <ubitux> huh [20:00:56 CET] <ubitux> someone kept the subtitles thing in the gsoc page? [20:02:13 CET] <durandal_1707> yes, smth wrong? [20:03:11 CET] <ubitux> it's not up-to-date at all [20:03:44 CET] <ubitux> well, not that much mentioned actually [20:29:37 CET] <rcombs> JEEB: well yeah, of course they would [20:30:01 CET] <rcombs> JEEB: that's all kinds of SPF violation and we obviously don't have the DKIM signing keys for everybody's domains [20:30:07 CET] <JEEB> yup [20:41:10 CET] <Gramner> something something X-Original-Authentication-Results to deal with SPF. not sure how well it works though [20:50:29 CET] <rcombs> relies on the receiving mail server explicitly trusting the forwarder (here, ffmpeg's mailing list server) [20:58:55 CET] <qiubit> Hey, I'm fairly new to ffmpeg and I want to do some fuzz testing on libavformat, libavcodec... Any suggestions on some new/untested features that might hide some bugs? Maybe users complaining about something recently? [21:01:03 CET] <llogan> kierank might be able to answer your questions about that. also, if you qualify for Outreachy or GSoC you may be interested in https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016#Createafuzzingtes… [21:01:37 CET] <jamrial> qiubit: look at changelog for recently commited decoders. things like Cineform HD, dxv, VC-2 HQ profile [21:02:32 CET] <kierank> qiubit: hello, was it you who emailed me today? [21:02:44 CET] <qiubit> kierank: yup, that's me :) [21:06:47 CET] <wm4> ubitux: you want a beginner parse a XML format (that _nobody_ on this earth uses) with smil helper functions? [21:07:31 CET] <ubitux> wm4: https://en.wikipedia.org/wiki/Universal_Subtitle_Format walking through subtitles should be doable [21:07:59 CET] <wm4> I mean more like that parsing XML with those smil helpers is total crapshoot [21:08:00 CET] <ubitux> check the sami demuxer, it's not that much work [21:08:12 CET] <ubitux> well, using xml lib might be tricky [21:08:22 CET] <ubitux> since as soon as you shit a tag, it's often a nightmare [21:08:30 CET] <ubitux> but i might be wrong [21:08:48 CET] <ubitux> i'm fine with using an xml lib though [21:09:04 CET] <ubitux> it was just a suggestion [21:09:07 CET] <ubitux> again, i'm not a mentor [21:09:25 CET] <qiubit> kierank: BTW, I've been thinking about how to approach this fuzzing issue (never done that before). From what I read, to get good results, I would need a lot of testcases, so I need to create them somehow. I've been thinking about looking at code coverage stats, latest commits, then based on that create a list of potentially bugged features, and then take a bunch of files that would test them... [21:09:27 CET] <Daemon404> ubitux, parsing xml is a nightmare regardless [21:09:35 CET] <JEEB> ^this [21:09:49 CET] <Daemon404> hope you like trees [21:09:53 CET] <ubitux> we are able to parse broken html [21:09:58 CET] <JEEB> esp. with user based input [21:10:00 CET] <ubitux> we should be able to deal with clean xml [21:10:08 CET] <Daemon404> >subtitles [21:10:10 CET] <Daemon404> >clean [21:10:11 CET] <Daemon404> pick one [21:10:17 CET] <qiubit> kierank: ...split them into a lot of smaller files (for example 1 minute video to a lot of 5 seconds segments) and then start fuzzing software. What do you think? Does that sound good? [21:10:30 CET] <kierank> qiubit: I would do it for now based on the most recent commit [21:10:42 CET] <kierank> Like we do with fate testing fate.FFmpeg.org [21:11:01 CET] <kierank> The easiest way is to use short videos [21:11:14 CET] <kierank> And other samples from the internet or samples.videolan.org [21:11:40 CET] <kierank> samples.FFmpeg.org I mean [21:11:55 CET] <qiubit> hmmm, ok, will check that out, thanks for the suggestions [21:13:12 CET] <wm4> <ubitux> we should be able to deal with clean xml <- but getting this right is tricky [21:13:22 CET] <wm4> which is why XML libs are _always_ bloated and broken [21:13:27 CET] <ubitux> who cares about usf anyway [21:13:32 CET] <ubitux> it's just as an exercise anyway [21:13:50 CET] <ubitux> approximately locating the text and the timing is enough to cover 90% of the case [21:13:50 CET] <wm4> ok, just don't merge it into lavc [21:14:16 CET] <ubitux> wm4: look at the sami demuxer [21:14:31 CET] <ubitux> pretty sure we can do something similar [21:14:47 CET] <wm4> well what this demuxer does is Wrong [21:15:02 CET] <ubitux> yeah, it can be improved [21:15:20 CET] <ubitux> but it's not proper xml [21:15:38 CET] <ubitux> it's 90' broken html handly edited madness [21:15:54 CET] <ubitux> so... you can't rely on a structure [21:16:19 CET] <wm4> oh right, sami is not proper xml [21:16:50 CET] <wm4> but SMIL is [21:22:34 CET] <BBB> please dont write your own xml parser [21:22:35 CET] <BBB> please [21:22:38 CET] Last message repeated 1 time(s). [21:22:38 CET] <BBB> please pretty [21:24:35 CET] <ethe> Why write a parser, when you can write a regex? [21:25:17 CET] <Shiz> please don't use xml [21:27:33 CET] <BBB> Shiz: input can be xml [21:37:08 CET] <ubitux> BBB: too late [21:37:10 CET] <ubitux> :s [21:37:20 CET] <BBB> crapcrapcrapcrapcrap [21:37:28 CET] <BBB> its not in a release yet can we rm -fr it? [21:37:36 CET] <ubitux> it's used in multiple demuxers [21:38:56 CET] <BBB> ff_htmlmarkup_to_ass? [21:39:20 CET] <Compn> iirc we didnt want to pull in any xml libs to convert our subtitles ? [21:39:28 CET] <Compn> or not [21:39:30 CET] Action: Compn runs [21:39:40 CET] <ubitux> BBB: ff_smil* [21:41:00 CET] <BBB> :'( [21:41:35 CET] <ubitux> :( [21:41:43 CET] <TD-Linux> ooh can I write mmx for it [21:41:55 CET] <ubitux> for ff_smil* functions? [21:42:00 CET] <ubitux> that will please BBB [21:42:06 CET] <BBB> no it won't [21:42:08 CET] <ubitux> :D [22:00:43 CET] <rcombs> so Slack introduced audio calling [22:00:48 CET] <rcombs> with webrtc and opus [22:01:30 CET] <rcombs> nothing really ffmpeg-related in there, but I thought it was pretty neat [22:01:43 CET] <rcombs> and it sounded excellent despite being very low-bandwidth [22:03:06 CET] <rcombs> and they're spending more CPU doing an animated effect around the speaker's avatar than on actually processing audio [22:07:46 CET] <rcombs> "The audio quality was so good, I could actually hear an echo of myself through someone elses computer and easily recognize that it was me instead of a garbled mess." [22:08:49 CET] <cone-905> ffmpeg 03Paul B Mahol 07master:209cff2d9ca1: avfilter/vf_waveform: make sure that x/y for text position is positive [22:10:19 CET] <jkqxz> That's a brilliant way of saying "the echo cancellation sucks epically". [22:10:56 CET] <rcombs> well that's tangential to the actual audio quality [22:11:03 CET] <rcombs> (and I didn't hear any echo myself) [22:57:00 CET] <Timothy_Gu> 3500 stars on GitHub today [23:16:04 CET] <cone-905> ffmpeg 03Paul B Mahol 07master:b3e037181891: avfilter/vf_waveform: make it possible to draw dots instead of lines [23:16:17 CET] <ethe> Could low throughput be a cause of noise in a realtime muxer? [23:17:26 CET] <nevcairiel> you mean like a jack output which feeds an actual hardware buffer in realtime? then sure, if you cant keep the buffers full, its going to give you glitches [23:18:25 CET] <ethe> nevcairiel: that's awfully specific, and yes... exactly like that. [23:18:43 CET] <nevcairiel> well i do remember what you are working on =p [00:00:00 CET] --- Wed Mar 9 2016

1 0

ffmpeg.log.20160308
by burek 09 Mar '16

09 Mar '16

[03:01:08 CET] <mariang> hello [03:01:23 CET] <jookiyaya> i cannot find any player that support bluray menu [03:02:02 CET] <Guest66065> Hello all, I run a video site, but watermark logo still in different sizes in every video with different resolution. My question: is there a way to scale watermark image in every video by some kind of percentage to have the same size of watermark whatever the resolution of the video. [03:02:28 CET] <Guest66065> i tryed finding with scale filter but without success [03:02:55 CET] <mariang> anyone know how to put a mp3 song to a mp4 file? [03:03:17 CET] <mariang> I use http://pastebin.com/xj1zDA0q [03:03:59 CET] <mariang> it works but with random file generated, I have a problem with firefox [03:04:09 CET] <mariang> i can't play the video [03:31:14 CET] <J_Darnley> mariang: please post the full output from ffmpeg [03:31:43 CET] <J_Darnley> Guest66065: I'm sure someone earlier suggested something for you [03:31:56 CET] <J_Darnley> jookiyaya: what about mpv or mplayer [03:32:06 CET] <J_Darnley> uh I mean mpv or mpchc [03:32:15 CET] <jookiyaya> doesn't support bluray menu [03:32:15 CET] <J_Darnley> (how did I say mplayer?) [03:33:31 CET] <mariang> J_Darnley: I fixed the problem with mozilla with http://pastebin.com/qq5dWE43 but idk how to put mp3 on video [03:34:04 CET] <J_Darnley> I can't see why the input audio matters at all [03:34:09 CET] <J_Darnley> you are encoding to aac [03:34:25 CET] <J_Darnley> This is why we ask for the full output! [03:37:48 CET] <furq> mariang: -c:a copy [03:39:32 CET] <mariang> J_Darnley http://pastebin.com/3SARULrj [03:39:37 CET] <mariang> it works on chrome [03:39:40 CET] <mariang> with audio [03:40:05 CET] <mariang> they tell something about Use -pix_fmt yuv420p for compatibility with outdated media players. [03:40:25 CET] <furq> if only there was some way to know what that means [03:40:27 CET] <furq> but there isn't [03:40:27 CET] <Guest66065> J_Darnley yes , he told me to check the scale filter but i tryed a lot of code and without success [03:40:47 CET] <Guest66065> i just need my watermark to be in a fixed size whatever the resolution of the video [03:59:54 CET] <k_sze[work]> Not strictly a ffmpeg question, but I suppose you guys and gals would know better: can YUV values be averaged in a straightforward way in general? e.g sum(all Y)/number of pixels [04:00:22 CET] <J_Darnley> Yes. [04:02:24 CET] <J_Darnley> Guest66065: if you can't work scale2ref then I don't know how anyone can help. [05:15:25 CET] <k_sze[work]> I mean, e.g. the H in HSV clearly can't be averaged naively by doing a sum and then a division, because it's a circular value. Is there any similar pitfalls with YUV? [07:05:26 CET] <jookiyaya> why is it that i cannot find any player that support bluray menu [09:38:59 CET] <Fyr> atomnuker, could write down a range of -q:a and corresponding bitrate for AAC? [09:49:45 CET] <Fyr> or corresponding quality of LAME units. [09:49:54 CET] <Fyr> or libfdk_aac [10:51:09 CET] <termos> Hi I have some script that runs ffmpeg -i rtmp://somestream somefile.flv, and if the input rtmp goes down I want to retry forever and if it comes back up the somefile.flv should be appended to and not overwritten. Is there a way to do this? [10:52:09 CET] <relaxed> termos: does ffmpeg exit when rtmp goes down? [10:53:21 CET] <termos> hm I thought it did [10:53:25 CET] <relaxed> if so, a simple script would be: while true; do ffmpeg -i rtmp://somestream somefile.flv; done [10:54:26 CET] <termos> but won't that poll me asking if I want to overwrite? I can supply the -y flag and it will not ask just overwrite, but I have found not way to append to the output file [10:58:15 CET] <relaxed> while true; do ffmpeg -i rtmp://somestream -f flv ->> somefile.flv; done [10:59:15 CET] <relaxed> that would append to somefile.flv [11:16:34 CET] <myztic> if this is off-topic I am sorry: what are some obvious things which might be wrong/screwed up in audio files, so they play correctly using one application, but are cut short (by approximately a second) in another application [11:17:16 CET] <myztic> normal .mp3 files [11:20:18 CET] <myztic> oh, and the issue is "fixed" if I convert the .mp3 files to .ogg for some reason [12:01:05 CET] <relaxed> myztic: the mp3 was encoded with ffmpeg [12:06:22 CET] <relaxed> ? [12:29:12 CET] <myztic> relaxed: no [12:29:16 CET] <myztic> relaxed: downloaded from the net [14:52:08 CET] <momomo> i am generating a hls stream from a remote source, here is my command: [14:52:14 CET] <momomo> ffmpeg -i "${URL}" -c:v libx264 -crf 23 -c:a libvo_aacenc -b:a 128k -ac 2 -f hls -hls_list_size 5 -hls_time 5 -hls_flags delete_segments -b:v 64k -bufsize 64k -minrate 0K -maxrate 1000k "${OUT}" [14:52:30 CET] <momomo> at the end I've been trying to limit the bitrate ... [14:52:48 CET] <momomo> but I am not sure this is working ... shouldn't 64k degrarde the quality alot ? [14:54:43 CET] <J_Darnley> Which do you want to use crf 23 or bitrate? [14:54:46 CET] <BtbN> So you want crf but with a maximum bitrate? [14:55:13 CET] <BtbN> combining -crf and maxrate/bufrate is valid, though strange [14:56:44 CET] <momomo> J_Darnley, the original source is high quality and I only wish to serve medium quality because of our users limited internet speed [14:57:07 CET] <J_Darnley> Again, crf or bitrate? One or the other. [14:57:19 CET] <momomo> bitrate gives more control, right? [14:57:27 CET] <J_Darnley> Control of what? [14:57:30 CET] <J_Darnley> Quality? [14:57:30 CET] <momomo> the output [14:57:31 CET] <J_Darnley> No [14:57:40 CET] <furq> won't -crf be overriden by -b:v anyway [14:57:46 CET] <J_Darnley> What property of output? [14:58:02 CET] <momomo> J_Darnley, the size and quality [14:58:11 CET] <momomo> the size in bytes per second [14:58:20 CET] <furq> i've not messed with the vbv much but those minrate and maxrate settings look wrong [14:58:35 CET] <momomo> furq, taken from: https://trac.ffmpeg.org/wiki/Limiting%20the%20output%20bitrate [14:58:47 CET] <momomo> and http://superuser.com/questions/536001/variable-bit-rates-with-vb-and-minrat… [14:59:10 CET] <furq> that doesn't say to set the maxrate to 15x the bitrate [14:59:16 CET] <momomo> 3.5 [14:59:32 CET] <J_Darnley> You don't even know what you are trying to do. How can anyone help you? [14:59:39 CET] <momomo> what is maxrate ? what does it do? i tried to understand it but no proper explanation [14:59:55 CET] <momomo> J_Darnley, I do [15:00:07 CET] <J_Darnley> It is the maximum input rate to the VBV "leaky bucket" model [15:00:16 CET] <momomo> I want to control the output quality and size of the video per second [15:00:22 CET] <BtbN> combining -crf and maxrate will result in ffmpeg, or rather x264, using whatever results in the lower bitrate [15:00:39 CET] <momomo> BtbN, ok, so I won't combine ... one step forward [15:00:53 CET] <momomo> this look better: ffmpeg -i "${URL}" -b:v 64k -bufsize 64k -minrate 0K -maxrate 128k -c:v libx264 -c:a libvo_aacenc -b:a 128k -ac 2 -f hls -hls_list_size 5 -hls_time 5 -hls_flags delete_segments "${OUT}" [15:01:08 CET] <BtbN> you realize 64kbit is next to nothing for a video, right? [15:01:16 CET] <furq> how limited is this internet speed [15:01:30 CET] <furq> if it's not ISDN then you can probably go a bit higher [15:01:39 CET] <furq> especially if you're using 128kbps audio [15:02:04 CET] <momomo> BtbN, i am just experimenting .. and the results are bad quality but not that bad [15:02:31 CET] <momomo> furq, maybe i will go lower on audio then .. 64k ? [15:02:50 CET] <furq> 64k should be ok with aac but not necessarily with that encoder [15:03:12 CET] <furq> if you have fdk-aac then that should do a much better job [15:03:28 CET] <furq> or the builtin encoder if you have an up-to-date ffmpeg [15:03:28 CET] <momomo> -c:a fdk-aac ? [15:03:31 CET] <furq> yeah [15:03:45 CET] <furq> it's not included by default due to licensing issues [15:04:00 CET] <furq> in binaries, that is [15:04:32 CET] <momomo> sometimes, due to the source rresulting in alot of errors .. i am getting this wierd annoying sharp noices when theere is a jump or lag ... maybe that was the audio encoder ? [15:04:47 CET] <momomo> Unknown encoder 'fdk-aac' [15:04:52 CET] <momomo> ffmpeg -i "${URL}" -b:v 64k -bufsize 64k -minrate 0K -maxrate 64k -c:v libx264 -c:a fdk-aac -b:a 64k -ac 2 -f hls -hls_list_size 5 -hls_time 5 -hls_flags delete_segments "${OUT}" [15:05:10 CET] <furq> like i said, you can't distribute fdk with ffmpeg due to licensing issues [15:05:15 CET] <furq> you'd have to build it yourself [15:05:32 CET] <momomo> hmm .. install a separrate package ? [15:05:35 CET] <J_Darnley> Well it might help if you get the name right! [15:05:42 CET] <J_Darnley> libfdk_aac [15:05:44 CET] <furq> oh yeah [15:05:55 CET] <furq> it won't be there though ;_; [15:06:15 CET] <J_Darnley> You mean not everyone compiles ffmpeg from source? [15:06:15 CET] <furq> if you have it then you'll know already (or someone is violating GPL) [15:07:41 CET] <momomo> i place it in ~/ffmpeg_sources ? [15:08:00 CET] <furq> that depends on what ~/ffmpeg_sources is [15:11:47 CET] <momomo> i will postpone that to another time .. [15:11:52 CET] <momomo> what I have now is: ffmpeg -i "${URL}" -b:v 256k -bufsize 256k -minrate 256K -maxrate 256k -c:v libx264 -c:a libvo_aacenc -b:a 64k -ac 2 -f hls -hls_list_size 5 -hls_time 5 -hls_flags delete_segments "${OUT}" [15:12:50 CET] <momomo> i was just wondering -minrate 256k vs -minrate 0 ... i can't really spot any difference ... is that for the control of the size of the output each .ts file ? i though bufsize was supposed to do that [15:13:22 CET] <BtbN> bufsize sets the vbv buffer size, it's an encoder option, hls doesn't care. [15:15:38 CET] <momomo> is there a way to control the hls file sizes ? some are hitting 1mb .. others are hitting 200kb ... [15:15:48 CET] <momomo> i tried to increase from 5 to 10 on both params [15:16:05 CET] <BtbN> Don't use variable bitrate if you want them to be the same size. [15:16:46 CET] <momomo> don't use -b:v 256k or -bufsize 256k ? [15:16:49 CET] <momomo> or both ? [15:17:06 CET] <momomo> sorry guys, i know I am noob here .. but I am learning .. sorry for all the questions :( [15:17:26 CET] <momomo> it's almost impossible trying ot figure this out by myself [15:23:07 CET] <momomo> is tehre a way to generate smaller hls part files ? [15:24:13 CET] <BtbN> make them shorter [15:24:35 CET] <BtbN> also, you can't split the stream at random locations, the beginning of each segment has to be an IDR frame [15:25:08 CET] <BtbN> so you have to set your gop length accordingly, or hls_time won't do much [15:25:49 CET] <momomo> hmm hop length ? yes, I've tried to increase from 5 to 10 and 20 .. .but not much seems to happen [15:25:51 CET] <momomo> ffmpeg -i ${URL} -b:v 256k -bufsize 256k -maxrate 256k -c:v libx264 -c:a libvo_aacenc -b:a 64k -ac 2 -f hls -hls_list_size 20 -hls_time 20 -hls_flags delete_segments ${OUT} [15:26:01 CET] <momomo> gop* [15:31:03 CET] <J_Darnley> What? You want smaller segements so you decide to try making them longer? [15:32:43 CET] <momomo> ah .. so I need to decrease that number [15:33:55 CET] <BtbN> 5 seconds is already very short [15:36:13 CET] <momomo> ok, i think i understand how these two params work now .. learning :) [15:38:38 CET] <momomo> i have another issue .. i am executing this from a java program ... and on occasion, for some reason, ffmpeg appears to get stuck and use up to 70% of the processor ... I am not able to reproduce this so it's hard to figure out why ... at one time it appeared as if the output in the command line stood still... and alot of .ts files where being generated .. fast ... this would not be too good in the production environment ... [15:38:55 CET] <momomo> is there a safe guard against such scenarios, so the process would die or restart ? [15:39:41 CET] <momomo> another scenario is if i run the command, and then pull out my etherrnet cable .. and then after a while put it in agian ... the ffmpeg command would exit ... is there a failsafe to allow to to continue or retry no matter what ? [16:57:16 CET] <momomo> guys, when i run the ffmpeg command, the first 00.ts file might take some time ( up to 20 seconds ) ... which will delay the creation of the m3u8 playlist, and make the player take as long to load ... is there a way to jumpt start the creation of the first few ts files ? [16:57:25 CET] <momomo> and the playlist so therre won't be a lag [16:57:26 CET] <momomo> ? [16:59:54 CET] <mariang> hey guys [17:00:28 CET] <kepstin> momomo: what codec/options are you using? [17:00:44 CET] Action: kepstin scrolls up [17:00:53 CET] <momomo> ffmpeg -i ${URL} -b:v 256k -bufsize 256k -maxrate 256k -c:v libx264 -c:a libvo_aacenc -b:a 64k -ac 2 -f hls -hls_list_size 10 -hls_time 20 -hls_flags delete_segments ${OUT} [17:01:18 CET] <kepstin> if your input is a remote stream, a good chunk of that time is just gonna be the connection setup [17:01:35 CET] <matthias___> Hello, i want to open a flv stream from my ip camera with ffmpeg but i get [flv @ 0x55c00deecde0] Packet mismatch 45 41 [17:01:47 CET] <kepstin> some of it will be the encoder delay in x264, you can try "-tune zerolatency" to remove that at the expense of encoding efficiency [17:01:49 CET] <momomo> yes, i know ... but then there is alot of additiooanl time spent on creating the first ts file .. [17:01:58 CET] <matthias___> ffmpeg -i "http://192.168.178.140/videostream.flv?user=admin&pwd=" [17:02:02 CET] <mariang> any way to get this http://pastebin.com/9pgHHAGX working with Android devices? [17:02:43 CET] <momomo> matthias___, girls/performers ? haha [17:03:36 CET] <momomo> kepstin, will that apply for the entire lenght of the command running ? [17:03:37 CET] <matthias___> momomo: nope, just surveillance [17:03:53 CET] <momomo> i was hoping that I could run something like that only at the beggining [17:04:00 CET] <J_Darnley> mariang: What isn't working? [17:04:31 CET] <furq> momomo: use a lower segment duration? [17:04:39 CET] <kepstin> momomo: it wouldn't really make sense to do only at the beginning if the source is realtime. [17:04:51 CET] <kepstin> you can't exactly increase the delay while keeping it realtime... [17:05:08 CET] <momomo> furq, you mean hls_time 5 ? [17:05:13 CET] <furq> sure [17:06:18 CET] <kepstin> oh, right, if you have 20s long hls segments, of course it'll be 20s before the stream is playable... [17:06:51 CET] <momomo> i had 5 sec before, and I think it was pretty much the same [17:06:56 CET] <momomo> i will rettry [17:07:17 CET] <kepstin> momomo: you should also set the gop size (-g) to make sure there's keyframes near where you want the hls splits to happen [17:07:39 CET] <furq> yeah i assume that if you have 10-second gops then ffmpeg will just split there and ignore hls_size [17:07:50 CET] <furq> s/size/time/ [17:08:10 CET] <mariang> J_Darnley: I can't play the video in browser [17:08:31 CET] <momomo> furq, you recommended me hls.js last time ( 3 weeks ago ) and it's been great .. but with small hls_size it doesn't seem to be buffering enough [17:08:36 CET] <momomo> know anything about that ? [17:08:45 CET] <momomo> i will look into gop [17:08:55 CET] <kepstin> mariang: if you want an mp4 to play properly in a browser, you should add "-movflags faststart" [17:09:20 CET] <momomo> btw, the standard pics per second is 25 .. right ? is there a way to half that ? to decrease size further / [17:09:21 CET] <momomo> ? [17:09:26 CET] <furq> -r [17:09:40 CET] <furq> 25 is standard for pal, it could be 24 or 30 for film or ntsc [17:09:46 CET] <furq> or double that for high framerate stuff [17:09:47 CET] <momomo> -r 13 would work ? [17:09:56 CET] <kepstin> momomo: you can use the -r output option or 'fps' filter (both are equivalent) to set any lower rate you like; it'll drop the extra frames. [17:10:08 CET] <momomo> i say mathias had the option -framerate 1/2 ... is that the same ? [17:10:12 CET] <furq> you can use 12.5 if you want to drop every other frame [17:10:12 CET] <kepstin> 13's kind of a funny number, but sure - probably. [17:10:16 CET] <furq> 1/2 is 0.5fps [17:10:31 CET] <matthias___> momomo: any idea? [17:10:34 CET] <momomo> so framerate and r is pretyt much the same ? [17:10:47 CET] <furq> -r = rate [17:10:59 CET] <kepstin> momomo: as input options, -framerate and -r are completely different [17:11:01 CET] <furq> -framerate is usually an input option [17:11:10 CET] <furq> although i think it's just mapped to -r as an output option [17:11:34 CET] <furq> and i believe both of them are actually mapped to -vf fps [17:11:39 CET] <momomo> here is my latest version: [17:11:40 CET] <momomo> ffmpeg -i ${URL} -g 10 -r 12.5 -b:v 256k -bufsize 256k -maxrate 256k -c:v libx264 -c:a libvo_aacenc -b:a 64k -ac 2 -f hls -hls_list_size 10 -hls_time 10 -hls_flags delete_segments ${OUT} [17:12:13 CET] <furq> if you want 5-second GOPs then -g should be r * 5 [17:12:19 CET] <kepstin> momomo: the argument for -g is in frames, not seconds. [17:12:32 CET] <furq> although maybe not in this case because it'll need to be a whole number [17:13:09 CET] <furq> also what resolution is the input video [17:13:18 CET] <furq> you probably want to downscale it if you're using such low bitrates [17:13:28 CET] <momomo> -g 50 -r 10 [17:13:36 CET] <furq> that works [17:13:57 CET] <furq> 10fps is not going to look good though [17:14:39 CET] <furq> for hls you might also want to set -x264opts keyint_min [17:14:45 CET] <furq> to the same as -g [17:15:01 CET] <J_Darnley> Or disable scenecut detection [17:15:05 CET] <furq> yeah [17:15:11 CET] <momomo> yeah, that looked like shit [17:15:36 CET] <furq> like i said, you're probably better off downscaling [17:16:00 CET] <momomo> -s ? [17:16:03 CET] <furq> yeah [17:18:52 CET] <furq> what's the default scaling algorithm for swscale [17:19:01 CET] <furq> it doesn't seem to mentioned in the docs [17:19:14 CET] <furq> i assume it's bilinear or bicubic which is probably what you want in this case [17:19:57 CET] <momomo> what I want ? [17:20:14 CET] <momomo> ah, ook... [17:21:20 CET] <momomo> latest [17:21:21 CET] <momomo> Strings.create("ffmpeg -i ${URL} -s 1024x768 -g 100 -r 20 -b:v 256k -bufsize 256k -maxrate 256k -c:v libx264 -c:a libvo_aacenc -b:a 64k -ac 2 -f hls -hls_list_size 10 -hls_time 20 -hls_flags delete_segments ${OUT}", [17:21:39 CET] <furq> that's still really high for 256k [17:21:47 CET] <momomo> scaling ? [17:21:49 CET] <furq> unless it's a screencast or something where you need to read small text [17:21:49 CET] <furq> yeah [17:22:38 CET] <momomo> is it expensive to create two separate qualities at once, in the same command? processor wise ? [17:23:16 CET] <furq> it's roughly twice as expensive as what you're doing now [17:23:39 CET] <furq> but encoding 256k at 20fps shouldn't be taking much cpu time [17:23:50 CET] <furq> if it's an issue you can use a faster x264 preset [17:24:12 CET] <momomo> tell me :) [17:24:27 CET] <momomo> is there a better encoder / [17:24:28 CET] <momomo> ? [17:25:37 CET] <momomo> i am using libx264, right ? [17:25:39 CET] <furq> yes [17:25:45 CET] <furq> http://dev.beandog.org/x264_preset_reference.html [17:25:54 CET] <furq> -preset fast (or whatever) [17:26:10 CET] <furq> slower presets compress better [17:26:26 CET] <momomo> what is the defualt ? [17:26:29 CET] <furq> medium [17:26:46 CET] <momomo> so just adding -preset fast would change that / [17:26:47 CET] <momomo> ? [17:26:50 CET] <furq> yes [17:27:36 CET] <kepstin> -preset fast would make it use less cpu to encode, and make the video quality slightly worse. [17:28:52 CET] <momomo> mm .. tough one [17:29:50 CET] <furq> is that command using an excessive amount of cpu [17:30:18 CET] <furq> i'd be using the slowest preset which doesn't cause dropouts [17:30:27 CET] <furq> except placebo which is pretty much worthless [17:31:15 CET] <momomo> dropouts ? I am getting alot of issues with laggign sound and images .. but it might be the source ... or the command i am running .. not sure .. [17:31:33 CET] <furq> the encoder lagging behind the source [17:31:47 CET] <momomo> http://hastebin.com/udojubijoz.rb [17:32:15 CET] <furq> that sure looks like an issue with the source [17:32:17 CET] <momomo> ooh. so I have too much dragging it down? but i have a fast computer .. and resource is around 3-6% [17:32:23 CET] <furq> ^ [17:32:36 CET] <momomo> good to know [17:32:42 CET] <momomo> i am executing this from a java program ... and on occasion, for some reason, ffmpeg appears to get stuck and use up to 70% of the processor ... I am not able to reproduce this so it's hard to figure out why ... at one time it appeared as if the output in the command line stood still... and alot of .ts files where being generated .. fast ... this would not be too good in the production environment ...V [17:32:51 CET] <momomo> is there a safe guard against such scenarios, so the process would die or restart ? [17:32:59 CET] <momomo> another scenario is if i run the command, and then pull out my etherrnet cable .. and then after a while put it in agian ... the ffmpeg command would exit ... is there a failsafe to allow to to continue or retry no matter what ? [17:33:45 CET] <furq> i don't think there's any builtin functionality for retrying [17:34:10 CET] <furq> the other thing sounds like a java issue [17:34:23 CET] <momomo> no, i think it is ffmpeg.. never occured for you ? [17:34:28 CET] <furq> in my expert opinion as a guy who's never used java but says bad things about it on irc [17:34:32 CET] <momomo> java is only executing it as a command [17:34:48 CET] <momomo> i can detect the process dying .. so that part is not a big issue ... but process hogging is a tough one ... [17:34:49 CET] <furq> it could be down to the wonky source [17:35:18 CET] <momomo> yes, the source right now is a eebox .. so i think thast might the issue [17:36:32 CET] <momomo> but still would like to protect myself against such scnearios .. i saw that one could configure threads and stuff like that ... maybe I could try to start parsing the error stream as well .. is there a consistent error log format and documenttion for different stuff online ? [17:37:02 CET] <galex-713> Hi, why when I encode two opus file with same bitrate but compression_level at 0 or 10 it gives a different filesize with vbr? [17:37:31 CET] <Fyr> oh [17:37:45 CET] <Fyr> different quality? [17:37:52 CET] <galex-713> btw, setting -vbr on and setting the bitrate mean its not vbr but abr? or is more correct to say that abr is a way to use vbr? [17:38:15 CET] <galex-713> The same file, same size (wav), same bitrate, but one is 10 and other is 0 of -compression_level [17:40:14 CET] <kepstin> galex-713: '-vbr on' is the default in ffmpeg; with that setting, the bitrate value is treated basically as a quality setting (over a large corpus of test files, the average bitrate at the given quality is n) [17:40:35 CET] <galex-713> not of a lot though, most of time its less that 0,1M, but for example with a bitrate of 80kbps I get 70M for compression_level=0 and 68M for compression_level=10 [17:41:01 CET] <kepstin> i'm not sure exactly what the 'compression_level' option does, it's not listed as an avoption for libopus encoder [17:41:15 CET] <J_Darnley> Its a global option [17:41:18 CET] <galex-713> kepstin: oh, like with a limit tending to infty you mean? so that average is not the one of the entire file? [17:41:41 CET] <J_Darnley> What it does depends on the encoder [17:41:54 CET] <J_Darnley> for flac it conrols the compression [17:42:04 CET] <galex-713> Yeah I think, just like -q, which btw doesnt exist for opus but does for mp3 [17:42:10 CET] <J_Darnley> for lame it controls a minor quality option [17:42:33 CET] <galex-713> https://www.ffmpeg.org/ffmpeg-codecs.html#Option-Mapping [17:42:42 CET] <kepstin> lets see - in libopus, it sets the "complexity" option [17:42:42 CET] <galex-713> why minor? [17:42:58 CET] <galex-713> comp stands for complexity? not compression? [17:43:16 CET] <kepstin> it controls basically "how hard the encoder will work" [17:43:42 CET] <J_Darnley> Minor because the main control over quality is the bitrate or -V quality level [17:43:47 CET] <kepstin> so think of it as similar to the x264 encoder's tune option - you can control it between "faster" and "more efficient audio encoding" [17:44:12 CET] <kepstin> so with vbr mode, using more complexity should result in smaller bitrates for the same audio quality [17:44:39 CET] <galex-713> okkk [17:44:44 CET] <furq> i assume you should never use a compression level lower than 10 unless you need to decode it on very low-end hardware [17:44:55 CET] <kepstin> the default is 10 [17:44:59 CET] <galex-713> oh ok [17:45:03 CET] <galex-713> Yeah using 10 [17:45:15 CET] <furq> opus is designed to be usable on like 20mhz arm cpus [17:45:27 CET] <galex-713> I think less is maybe suited for wide-minded voip/streaming [17:45:28 CET] <kepstin> hmm, not really :) [17:45:42 CET] <galex-713> ? [17:45:43 CET] <kepstin> best i could get it decoding on my ipod classic (armv5) was around 60-70mhz [17:45:51 CET] <furq> well it says that on the wikipedia page [17:46:01 CET] <kepstin> with 128k music files tho; lower bitrate voice might be faster [17:46:38 CET] <furq> it's designed with a view to being usable for telephony, so it needs to run on potatoes [17:46:44 CET] <galex-713> While encoding just a man speaking with almost no other sound (some quite low background noise/beverage), what would be a suited bitrate? 16kbps? 8kbps? more? something in between? [17:46:56 CET] <furq> test it and find out [17:47:44 CET] <galex-713> Well, I dont trust my hears, so just wanted what is the common usage for that ^^ [17:47:50 CET] <galex-713> (using -application voip of course) [17:49:47 CET] <kepstin> (keep in mind that the ipod cpu is nominally around 216mhz, so even at 60-70mhz decoding opus it was still in a power-saving mode most of the time) [17:50:35 CET] <mariang> guys, do you know a command to make a video from images with audio from a mp3 file and compatible with mobile and desktop devices? my command is broken, i can't play on android http://pastebin.com/rWjZPQxm [17:52:28 CET] <Fyr> mariang, how is it broken? [17:52:53 CET] <Fyr> is the profile too high for your player? [17:54:03 CET] <galex-713> If the volume of a sound file is pretty low, is there a way to normalize it? like to make the higher value stored the higher pick of the sound stream? so not to have to set manually some gain? (btw how to achieve that with ffmpeg otherwise?) [17:54:39 CET] <kepstin> galex-713: ffmpeg can do that with audio filters, there's a couple ways [17:54:52 CET] <kepstin> can either do a 2-pass normalization, and i think there's a dynamic compressor too [17:55:32 CET] <galex-713> 2-pass can be fine [17:55:59 CET] <galex-713> Ive the time and I want to get the best possible result :) [17:56:13 CET] <mariang> Fyr: i'm loading mp4 in brower and when i play, .. nothing [17:56:24 CET] <mariang> in chrome on android [17:56:33 CET] <kepstin> well, the reason that it's two pass is that you need to see the whole audio to find the peak before you can know what to set the gain to :) [17:56:53 CET] <galex-713> I knew it :p [17:57:18 CET] <galex-713> So how to do that with ffmpeg? is there a example section in some filter section in some document? ^^ [17:57:18 CET] <Fyr> mariang, try different -profile:v [17:57:20 CET] <galex-713> *doc [17:57:23 CET] <Fyr> baseline or so [17:59:04 CET] <kepstin> galex-713: can use the volumedetect or ebur128 filters to check the audio, then use the output of them to set a gain via the volume filter in a second pass. [17:59:45 CET] <kepstin> or use one of the acompressor, compand, or dynaudnorm to to a single pass dynamic normalization. [18:00:18 CET] <galex-713> whats the difference between volumedetect and eburl28? [18:00:43 CET] <kepstin> the single-pass ones will change the volume over the course of the stream so it's all the same loudness, while the 1-pass ones will preserve relative loudness between parts and change only the overall volume [18:01:27 CET] <kepstin> galex-713: read the filter docs. volumedetect provides only simple measurements like peak and rms, while ebur128 does a fancy perceptual loudness measurement. [18:02:10 CET] <kepstin> if you want "all files to sound the same loudness", ebur128 is the way to go. [18:04:28 CET] <galex-713> kepstin: should I do the first pass on the flac or opus file resulting from it? [18:05:16 CET] <kepstin> any different would be unnoticable, and doing it on the flac is probably faster. [18:05:39 CET] <galex-713> Ok cool [18:06:52 CET] <galex-713> kepstin: And after the first pass ended what should I use in order to normalize? [18:09:02 CET] <kepstin> galex-713: the filter will print out a value in either dB (volumedetect) or LUFS (ebur128). You need to pick a reference level (the ebur128 standard is -23LUFS, but some people find that kind of quiet) and then use a volume filter like "volume=+3.2dB" or whatever is needed to adjust it to the reference level you picked. [18:10:04 CET] <furq> mariang: -pix_fmt yuv420p [18:11:52 CET] <mariang> furq: yes, i tried but nothing [18:11:59 CET] <mariang> I have a warning, deprecated pixel format used, make sure you did set range correctly [18:12:13 CET] <furq> yuv420p, not yuvj420p [18:12:47 CET] <mariang> yes [18:12:47 CET] <mariang> http://pastebin.com/s9Zj0ZPP [18:13:29 CET] <mariang> and the video is broken in vlc also. the sound is good but the images is locked [18:14:01 CET] <furq> that's probably due to the framerate [18:14:21 CET] <mariang> http://i.imgur.com/c8kRYEQ.png [18:14:41 CET] <furq> actually nvm i don't think the input framerate affects the output framerate [18:14:58 CET] <Fyr> mariang, are you sure about yuvj420p? [18:15:11 CET] <kepstin> you could try just using the -r output option to set a higher output framerate, like 12 or 24 or whatever. It'll duplicate the image frames and give something that might work better in players. shouldn't increase the size too much. [18:15:32 CET] <Fyr> mariang, try yuv420p. [18:15:44 CET] <furq> Fyr: 17:12:47 ( mariang) http://pastebin.com/s9Zj0ZPP [18:15:49 CET] <mariang> i tried [18:16:13 CET] <Fyr> mariang, have you tried profile? [18:16:27 CET] <galex-713> kepstin: https://paste.debian.net/413298/ there are several values in LUFS, which is the one I need to increase my stream by? (btw should I do -filter_complex volume=+<N>LUFS just as -filter_complex volume=<N>dB?) [18:16:38 CET] <mariang> Fyr: yes [18:16:46 CET] <Fyr> mariang, do you have a video that your phone can play? we can take a look at working case and analyze its parameters. [18:17:13 CET] <kepstin> galex-713: LUFS is basically like dB, you'll use dB in the volume filter. You want the integrated loudness ("I") value [18:17:45 CET] <galex-713> so like -filter_complex volume=+33.2dB? [18:17:53 CET] <furq> mariang: if you need to support legacy android devices then -profile:v baseline [18:18:10 CET] <kepstin> galex-713: so for that example you'd use volume=+10.2dB to bring it up to the -23LUFS reference level [18:18:34 CET] <furq> and like kepstin said you probably want to set -r 24 [18:18:34 CET] <Fyr> mariang, maybe, it's not the video that causes dysfunction, maybe this is audio. I would recommend you to try the latest version of ffmpeg. it has improved AAC encoder. [18:19:06 CET] <mariang> Fyr: I've compiled myself on centos [18:19:21 CET] <galex-713> kepstin: ohhh ok, same unit different 0, like Kelvin and Celcius? [18:20:25 CET] <kepstin> galex-713: it's actually basically the same unit (dbFS and LUFS both are "relative to digital full scale"), they just renamed it so you know it's a perceptual loudness rather than simple power measurement. [18:20:52 CET] <galex-713> oh ok [18:21:32 CET] <Fyr> mariang, could you pastebin ffprobe output.mp4 ? [18:21:40 CET] <kepstin> galex-713: what the ebur128 filter I value says is that "this file has a loudness of -33 LUFS". Since that's 10LU = 10dB quieter than the reference level of -23LUFS, you use volume=+10dB to adjust it. [18:22:13 CET] <galex-713> yeah I see [18:22:21 CET] <kepstin> (you can obviously play around with it and pick a different reference level if you like) [18:22:27 CET] <galex-713> Yeah [18:22:50 CET] <galex-713> Well Im a bit maniac, I hate using magic numbers/values, so I prefer to keep that ^^ [18:23:00 CET] <mariang> Fyr: http://pastebin.com/zgwtU6dE [18:23:12 CET] <mariang> lol [18:23:43 CET] <furq> that sure looks like it should work [18:23:54 CET] <furq> although since your build includes fdk-aac you should probably use that to encode the audio [18:25:09 CET] <furq> maybe it's having an issue with the framerate [18:25:18 CET] <furq> try setting -r 25 [18:26:26 CET] <galex-713> kepstin: does something alike chapters exist but for sound streams? or does that require a complex container like mkv? [18:59:05 CET] <kepstin> galex-713: "chapters" are pretty much always handled as part of the container [20:36:57 CET] <voip_> hello guys , am taking live rtmp stream and transcoding to mpeg2. Sourse is good, but on output sometime i have droped frames. [20:37:09 CET] <voip_> -vcodec mpeg2video -pix_fmt yuv420p -me_method epzs -threads 4 -r 29.97 -g 45 -bf 2 -trellis 2 -cmp 2 -subcmp 2 -s 720x480 -b 4000k -minrate 3000k -maxrate 4000k -bt 350k -acodec ac3 -ab 192k -ar 44100 -async 1 -y -f mpegts udp://10.110.11.16:7000?pkt_size=1316 [20:37:16 CET] <voip_> how to fix ? [20:39:30 CET] <silentquasar> Hi! I'm searching for hardware recommendations for a PC that will be used to stream 720p video (and audio) from a USB webcam (MS LifeCam Studio) to YouTube via ffmpeg. Up to this point we've been using a second-hand Core 2 Duo PC and streaming through the Hangouts interface, but the stream struggles a bit and sometimes drops out altogether. We have a ~$600 budget for an upgrade. [20:40:47 CET] <llogan> silentquasar: are you using ffmepg with the current machine? [20:41:36 CET] <silentquasar> No, we've been using the Hangouts web interface for YouTube Live Events. [20:42:50 CET] <silentquasar> Windows often shows alerts saying that the webcam may not perform well due to low system resources. [20:43:36 CET] <llogan> you should try ffmpeg before buying a new computer, but i don't know if your cpu will suffice or not. [20:44:01 CET] <furq> is that even transcoding before uploading [20:45:31 CET] <furq> low system resources usually means low memory [20:45:36 CET] <silentquasar> Sorry to be unclear--this is live streaming on YouTube. [20:45:41 CET] <furq> as far as windows is concerned anyway [20:46:21 CET] <silentquasar> Right. Well I'll give ffmpeg a shot on its own. But for the sake of argument, if I had no PC to begin with, what would you recommend for this application? [20:46:34 CET] <voip_> llogan, hi , ssory [20:47:02 CET] <furq> it depends on what hangouts actually does. if it's a web interface then i assume it's just receiving the webcam feed and transcoding it remotely [20:47:11 CET] <furq> in which case the only requirement would be fast enough internet [20:47:45 CET] <silentquasar> I'm pretty sure it is doing client-side transcoding--I don't think it would be feasible to stream 720p raw video over a broadband connection. [20:48:02 CET] <furq> it depends what format your webcam puts out [20:48:06 CET] <voip_> llogan, do you know how to fix issue with frame drops isuue? [20:48:18 CET] <furq> i'd assume it's mjpeg which could be feasible [20:48:39 CET] <furq> what's your cpu usage like while it's running [20:49:15 CET] <silentquasar> I'll have to get back to you on that one. [20:49:23 CET] <furq> also if it is transcoding then i'd expect ffmpeg to do a better job, so try that if you can [20:49:38 CET] <silentquasar> It's usually running pretty hot, but I don't remember the particulars. [20:49:46 CET] <furq> if you want a general recommendation for video encoding then any recent-ish intel quad core (or 6-core) should be fine [20:49:52 CET] <furq> the higher base clock the better [20:50:03 CET] <llogan> voip_: i'm waiting for your full command and complete console output [20:50:20 CET] <voip_> oh [20:50:29 CET] <voip_> one min [20:51:04 CET] <silentquasar> Thanks furq and llogan. Much appreciated. [20:52:11 CET] <llogan> was going to tell him to use VBV if re-encoding [20:53:40 CET] <alesan> hello I have a question - ffmpeg supports "SVC"? [20:53:56 CET] <Fyr> what is that? [20:53:56 CET] <alesan> as in the multi-stream H.264 thing [20:54:04 CET] <alesan> https://en.wikipedia.org/wiki/Scalable_Video_Coding [20:54:12 CET] <J_Darnley> no, unless another h264 encoder supports it [20:55:02 CET] <alesan> what I do not understand is [20:55:16 CET] <alesan> it does not seem to me to require any different encoder or decoder [20:55:26 CET] <alesan> it seems more like a muxing/demuxing thing to me [20:58:03 CET] <klaxa> iirc the main x264 dev said it's not feasible [20:58:52 CET] <alesan> I honestly wonder why, in a technical sense [20:58:58 CET] <alesan> note I am talking about encoding here [20:59:06 CET] <alesan> but the same should be for decoding [21:00:25 CET] <klaxa> http://x264.nl/developers/Dark_Shikari/consulting.html (ctrl+f svc) [21:00:32 CET] <klaxa> not sure if that's still relevant [21:00:39 CET] <alesan> I'll have a look [21:01:18 CET] <klaxa> it's merely a short passage where he says he won't implement it [21:02:58 CET] <voip_> llogan, pasted http://pastebin.com/P9DRKY10 [21:03:56 CET] <alesan> I see [21:05:19 CET] <llogan> voip_: ffmpeg is dropping frames because you're using -r. also, why are you using -minrate and -async? [21:05:24 CET] <llogan> and why mpeg2video? [21:13:36 CET] <jkqxz> H.264 SVC encode is immensely difficult to do well in the general case, and any specific case requires a lot of effort on the part of the user to actually be of value. H.264 SVC decode is totally doable, but it would be a lot of work for little gain given the lack of SVC encoders. [21:14:46 CET] <voip_> llogan, its live stream i think for live stream i shuld use -r. I dont know why i am using -asinc, somone recomend it. Our customer is TV company theyr equipment needs minimum 3mb bitrate and mpeg2 [21:17:01 CET] <voip_> whats the right commands for my cas e? [21:21:33 CET] <voip_> when i taking HLS from same command i have too much drop frames [21:21:37 CET] <furq> voip_: don't use -r unless you want the output to be a different framerate than the input [21:23:32 CET] <voip_> so, also i dont need use -async ? [21:24:09 CET] <furq> i doubt it [21:27:22 CET] <alesan> thanks [21:27:40 CET] <llogan> voip_: if you want to use -r, don't use 29.97, but use 30000/1001 or ntsc [21:31:08 CET] <voip_> llogan, thank you , shuld i also remove commands -async 1 -y ? [21:31:38 CET] <llogan> probably [21:32:39 CET] <llogan> why "4" for threads? IIRC, by default it will choose appropriately. [21:34:55 CET] <voip_> because 4 cores on cpu [21:35:15 CET] <voip_> ok, i will delete [21:44:08 CET] <voip_> thank you [21:50:07 CET] <Prelude2004c> hey everyone good day... i am trying to launch an mp4 and overlay a bunch of text on the video.. is drawtext the best way to do it ? [21:52:05 CET] <kepstin> depending how much text exactly, it might make sense to do it via subtitles instead. [21:52:33 CET] <llogan> Prelude2004c: it depends on what you're doing. you can use drawtext but that will require re-encoding. you can use softsubs, but playback support may suck. you can do it upon playback if your player supports it, such as just using ffplay [21:52:54 CET] <Prelude2004c> yes i am transcoding the video [21:53:04 CET] <Prelude2004c> which is perfectly fine... but the problem is the text i want to add is a bunch of lines [21:53:12 CET] <Prelude2004c> like it could be 5 or 6 lines of text [21:53:36 CET] <Prelude2004c> like a customer notice or something.. not just a word or a single line.. so i am having trouble with it as it does not understand something siple like \n for new line [21:53:39 CET] <Prelude2004c> or <center> etc [21:53:48 CET] <kepstin> even if you're putting the text in hard, it might make sense to use subtitles and the subtitle filter, simply so you can use something like aegisub to do the timing and typesetting. [21:54:10 CET] <Prelude2004c> the problem is the text changes [21:54:36 CET] <Prelude2004c> so i have to always restart the encoding but since i am using HLS i continue segmenting from the same place so from customers perspect it just flips the new .ts with the new data [21:54:42 CET] <llogan> or if you want to use drawtext you can use textfile option which may be easier to deal with new lines [21:54:55 CET] <Prelude2004c> yes . never used htat before.. i was looking for that [21:56:14 CET] <Prelude2004c> llogan, exacxlty what i wanted :P haha [22:07:36 CET] <voip_> guys, what is mean option -y ? [22:09:07 CET] <furq> voip_: https://ffmpeg.org/ffmpeg.html#Main-options [22:09:31 CET] <voip_> thank you ! [23:03:08 CET] <debianuser> Hello, a short question, but I can't find an answer. :( I have .mkv with 1 video track, one ac3 and one dts track. And I want to recode dts track to ac3. If I set `-acodec copy` both tracks get reencoded, even the ac3 one. So how can I say something like `-acodec copy -acodec ac3` to make it copy first track and reencode second one? [23:03:54 CET] <c_14> -c:a:0 copy -c:a:1 ac3 ? [23:05:27 CET] <debianuser> Ah! I can do that? Thanks! [23:09:55 CET] <debianuser> Yes, looks working! Thank you! [23:38:51 CET] <galex-713> kepstin: does ogg support chapters? [23:39:12 CET] <galex-713> Otherwise should I make a .mka? [00:00:00 CET] --- Wed Mar 9 2016

1 0

ffmpeg-devel.log.20160307
by burek 08 Mar '16

08 Mar '16

[02:16:43 CET] <cone-161> ffmpeg 03Raymond Hilseth 07master:86db71b402e9: avformat/ftp: Support response code 125 for STOR and RETR commands [03:11:34 CET] <rcombs> does stefano hang out here [03:12:36 CET] <cone-161> ffmpeg 03Zhao Zhili 07master:6f5048f4a0f7: rtp: Fix play multiple multicast streams with the same port [03:18:40 CET] <jamrial> rcombs: sometimes. his nick is saste [03:18:53 CET] <rcombs> ah [04:46:21 CET] <Timothy_Gu> good to see GCC vectorization actually doing something [04:49:22 CET] <llogan> Timothy_Gu: as for your question regarding the version stuff. doesn't matter to me as long as the git short hash is there. that's all i really use. [05:04:25 CET] <Timothy_Gu> llogan: ok [06:47:01 CET] <Akanksha> what does index mean in streams. Sorry for naive questions. I am new to all these things. Thanks in advance. :) [06:54:52 CET] <Timothy_Gu> Akanksha: go to #ffmpeg [06:55:23 CET] <Timothy_Gu> usually it's the id assigned to the stream in the container [10:44:23 CET] <ubitux> i'm so confused at the way the skip samples thing is supposed to be handled [10:56:18 CET] <mateo`> Hello o/, I'm about to push the mediacodec patchset as no one objected, but I want to double check, so ... any objections before I push ? [11:15:08 CET] <ubitux> wth do we have public functions such as av_dv_codec_profile() and av_dv_codec_profile2() [11:18:10 CET] <ubitux> static const int32_t av_sqrttbl_sf [11:18:12 CET] <ubitux> meeh [11:18:26 CET] <nevcairiel> a static av table? [11:18:49 CET] <nevcairiel> oh its in a header [11:19:03 CET] <nevcairiel> stupid softfloat crap [11:19:09 CET] <nevcairiel> build float into your CPUs, MIPS! [11:19:29 CET] <ubitux> just like av_dv shitcrap, i suppose av_dirac_parse_sequence_header() should be avpriv? [11:20:17 CET] <nevcairiel> avpriv isnt very popular, and not that much harm to just expose it [11:20:34 CET] <ubitux> av_downmix_info_update_side_data() do we really need this exposed? [11:22:01 CET] <nevcairiel> probably not, the function is super trivial and only used once [11:22:16 CET] <ubitux> av_xiphlacing @_@ [11:22:44 CET] <ubitux> av_subtitle_rect_class wut [11:31:39 CET] <cone-599> ffmpeg 03Matthieu Bouron 07master:3ab178516ec8: lavc: add JNI support [11:31:39 CET] <cone-599> ffmpeg 03Matthieu Bouron 07master:4737fe6907d2: lavc: add h264 mediacodec decoder [11:42:20 CET] <ubitux> http://codeology.braintreepayments.com/ffmpeg/ffmpeg what am i looking at [11:54:03 CET] <JEEB> oh nice, mediacodec's in [11:55:49 CET] <mateo`> JEEB: yeah :), next step is implementing the hwaccel part. [12:00:41 CET] <cone-599> ffmpeg 03Carl Eugen Hoyos 07master:b872b98bb466: lavfi/extractplanes: Move endianness calculation up. [12:00:42 CET] <cone-599> ffmpeg 03Carl Eugen Hoyos 07master:0ba844a053da: lavfi/extractplanes: Fix in_pixfmts. [12:03:50 CET] <nevcairiel> evil hacks are evil https://github.com/dwbuiten/FFmpeg/commit/a3b54e814c932f93982b12d063fcac42d… [12:06:13 CET] <mateo`> is there still some help needed to port lavf to the codecpar api changes ? [12:06:38 CET] <cone-599> ffmpeg 03Carl Eugen Hoyos 07master:bba9bed3f3b1: lavfi/extractplanes: Add RGB0 and friends as supported pix_fmts. [12:15:53 CET] <ubitux> wm4: you sure it was a vplayer file btw? extension was... txt? [12:16:05 CET] <wm4> ubitux: srt [12:16:12 CET] <ubitux> lol [12:16:16 CET] <wm4> yeah [12:16:37 CET] <wm4> at least from what I remember [12:20:37 CET] <wm4> apropos probe failures, there are a lot of ass files with "unexpected" file headers [12:21:21 CET] <nevcairiel> i documented a bunch of failing fate tests on etherpad, if anyone feels bored [12:22:11 CET] <nevcairiel> unexpectedly, a bunch of avfilter tests fail [12:22:31 CET] <wm4> huh [12:23:44 CET] <nevcairiel> wonder if maybe the crc muxer is broken or something =P [12:32:25 CET] <nevcairiel> and a bunch of h264 tests fail, probably has_b_frames related [12:33:25 CET] <wm4> why would anything fail without has_b_frames? [12:34:00 CET] <nevcairiel> because it drops frames then [12:35:02 CET] <wm4> shouldn't it instead assume the maximum delay possible? [12:35:16 CET] <nevcairiel> it cant differentiate between 0 and unset though =p [12:36:09 CET] <nevcairiel> should probably just expose has_b_frames again somehow, its kinda handy to have avformat find out this value [12:42:38 CET] <cone-599> ffmpeg 03Matthieu Bouron 07master:81f14884b593: lavc/mjpegdec: avoid unneeded allocation if the frame is to be skipped [12:53:15 CET] <cone-599> ffmpeg 03Clément BSsch 07master:920f592b81c7: lavf/vplayerdec: support time durations with no ms specified [12:53:41 CET] <wm4> lol this bug report cehoyos just created doesn't have "full, uncut console output" [12:53:52 CET] <wm4> instead some output is skipped [12:53:53 CET] <ubitux> wm4: can you share the ass sample? [12:54:32 CET] <ubitux> vplayer should be fixed in last commit [12:54:57 CET] <wm4> ubitux: mpv issues 2846, 2821, 2506 [12:55:31 CET] <wm4> here's apparently a sample, unfortunately zipped https://github.com/mpv-player/mpv/files/129635/sample-ass.zip [12:55:50 CET] <wm4> some ass scripts miss [Script Info] completely [12:57:46 CET] <ubitux> that sample looks supported [12:58:03 CET] <ubitux> i remember adding a check for that [12:59:31 CET] <ubitux> should i look for "[Aegisub Project Garbage]" instead? :D [13:00:10 CET] <ubitux> wm4: can you should me a sample where the "[Script Info]" is missing? [13:00:16 CET] <ubitux> i want to check if it's missing the whole section [13:00:19 CET] <ubitux> or just that line [13:00:40 CET] <ubitux> if it's the whole section, i can just look for [V4+ Styles] or whatever [13:01:37 CET] <wm4> I asked for a sample [13:01:39 CET] <ubitux> wm4: so #2506 is closed, #2821 should be closed as well since it's the same issue [13:10:38 CET] <ubitux> wm4: any other issue? [13:11:04 CET] <ubitux> if everything goes well, i might receive the GB of text subtitles samples today... [13:11:13 CET] <ubitux> it's gonna be fun [13:13:11 CET] <wm4> not that I know of [13:16:02 CET] <j-b> I don't get this JNI patch, tbh. [13:17:13 CET] <wm4> why not [13:17:30 CET] <j-b> Why not use directly the JNI_OnLoad? [13:17:59 CET] <wm4> whatever that is [13:27:49 CET] <wm4> so where are those protocol whitelists stored? [13:28:09 CET] <wm4> oh, .default_whitelist = "http,https,tls,rtp,tcp,udp,crypto" [13:32:13 CET] <JEEB> ok, my rpi3 finally arrived [13:33:27 CET] <cone-599> ffmpeg 03Paul B Mahol 07master:f659b70eb093: avfilter/vf_waveform: draw graticule for color filter too [13:34:48 CET] <wm4> meanwhile everyone is hyping that odroid thing [13:36:24 CET] <ubitux> competition, faster [13:36:45 CET] <ubitux> heat issue with rpi3 apparently too [13:37:03 CET] <nevcairiel> still comes wihtout a heaksink by default? [13:37:13 CET] <nevcairiel> heat* [13:38:17 CET] <wm4> it comes without anything by default [13:38:37 CET] <nevcairiel> the previous models already benefit from adding a small heatsink [13:38:47 CET] <JEEB> I'll just leave it in the snow and ice [13:38:54 CET] <ubitux> you can buy one [13:38:54 CET] <JEEB> probably helps [13:38:58 CET] <mateo`> j-b: because for an unknown reason I thought that I couldn't use it there (even though I use it in other places in Android apps) [13:40:27 CET] <j-b> mateo`: if the goal is libavcodec+libavformat, then, I believe it's a cleaner way to get the JavaVM* than having an API that might be wrongly used. [13:40:52 CET] <wm4> didn't we discuss this to exhaustion [13:41:45 CET] <mateo`> wm4: we discussed it, but I haven't proposed the use of JNI_onLoad (which solve the issue) [13:42:02 CET] <jkqxz> The HiKey one is a bit of a joke in that respect. It can barely run above 200MHz if you use all the cores, so performance testing on it is very tricky. [13:42:41 CET] <mateo`> so I will do a patch that uses JNI_onLoad, and remove the public API part [13:43:12 CET] <j-b> mateo`: it's just a suggestion. [13:43:18 CET] <wbs> if you link libavcodec statically into a lib that already has a JNI_OnLoad of its own, won't that be an issue? [13:43:30 CET] <j-b> it would, yes. [13:43:39 CET] <j-b> mateo`: it requires people to use the Load Library from the Java [13:44:03 CET] <mateo`> ok, (then this is why i didn't think of using JNI_onLoad) [13:45:29 CET] <j-b> I'd argue it's cleaner, and avoid the calling twice the call to set the JavaVM* [13:45:34 CET] <j-b> but it's debatable. [13:46:53 CET] <mateo`> wbs: what's your opinion ? [13:47:02 CET] <wm4> the call to set the VM can be avoided on newer android versions [13:47:07 CET] <wm4> from what I undestood [13:47:23 CET] <wm4> as in, the lavc jni code can get the VM automatically [13:47:38 CET] <j-b> well, you cannot change the VM from your process, as far as I know. [13:47:38 CET] <mateo`> yes by calling their private API [13:55:29 CET] <wbs> mateo`: in which versions does JNI_GetCreatedJavaVMs work? and what does _ZN13JniInvocation15jni_invocation_E gain? does the latter startup the necessary IPC communication and whatnot, to make it work for commandline ffmpeg? [13:58:29 CET] <mateo`> wbs: from Android 4.4.2 (not too sure about the micro version), checking if _ZN13JniInvocation15jni_invocation_E is initialized just guarantee that we can safely use JNI_GetCreatedVMs [13:59:05 CET] <mateo`> otherwise it will crash (https://android.googlesource.com/platform/libnativehelper/+/idea133/JniInvo…) [13:59:55 CET] <wbs> mateo`: oh, ok [13:59:56 CET] <mateo`> and it does not start the necessary IPC communcation for commandline :( [14:00:38 CET] <wbs> ok - that's probably not too interesting in practice though, other than for testing. (although some people ship apps with ffmpeg/avconv binaries and invoking those, instead of using the API) [14:02:20 CET] <wbs> mateo`: when called from within a lib, in which cases would JNI_GetCreatedVMs crash? is there any way of running a lib within an app without actually having the full JVM running and set up already? [14:03:27 CET] <mateo`> I don't think there is a way of running an app without having a full jvm running [14:03:45 CET] <mateo`> (AFAIK) [14:05:41 CET] <wbs> indeed, so the jni invocation stuff is just academic safetychecking then, right? [14:07:42 CET] <mateo`> the check of _ZN13JniInvocation15jni_invocation_E before using JNI_GetCreatedVMS is ( when running the lib under an app) but if it happens that the lib is ran from the commandline without vm it will crash [14:08:14 CET] <wbs> ah, yes, then it makes sense [14:08:25 CET] <mateo`> the use of this api remove the need of calling av_jni_set_java_vm on newer devices [14:09:45 CET] <mateo`> but in practice, since this is private api, i don't for how much time we will be able to call it [14:10:12 CET] <wbs> yeah, having av_jni_set_java_vm allows to avoid the dependency on private api, that's always nice [14:18:50 CET] <Daemon404> _ZN13JniInvocation15jni_invocation_E? [14:18:56 CET] <Daemon404> is that zome C++ mangling? [14:18:59 CET] <Daemon404> some* [14:19:06 CET] <mateo`> exactly [14:19:23 CET] <Daemon404> is it safe to call it from C like that even? [14:19:27 CET] <Daemon404> stable, rather [14:20:18 CET] <wbs> Daemon404: "echo <foo> | c++filt" to unmangle it [14:20:38 CET] <ismail> c++-filt <foo> works [14:20:56 CET] <ismail> without the minus of course [14:21:03 CET] <Daemon404> what's C++-filt? some android thing? [14:21:12 CET] <wbs> and it's safe to call such things from C, but it's all private API so you can't of course rely on it existing and behaving well [14:21:12 CET] <ismail> Daemon404: c++ demangler from binutils [14:21:14 CET] <Daemon404> ah [14:21:35 CET] <Daemon404> wbs, i suppose you must manually pass the first arg as 'this'? [14:21:49 CET] <wbs> Daemon404: if it's a non-static method, yeah, but afaik this one is static [14:21:58 CET] <Daemon404> right [14:22:13 CET] <Daemon404> my knowledge of how c++ behaves after compilation is limited to REing crappy C++ codecs [14:22:45 CET] <wbs> on some architectures (32 bit x86 on msvc at least), you can't easily call C++ methods from C at all, since the this pointer isn't passed in the same way as normal parameters, i.e. in a register instead of on the stack [14:23:30 CET] <Daemon404> hex rays displays it as a first param when it decompiels x86 c++ dlls made with msvc [14:23:35 CET] <Daemon404> so i geuss it mislead me [14:24:16 CET] <wbs> https://en.wikipedia.org/wiki/X86_calling_conventions#thiscall [14:25:20 CET] <wm4> guys, the mangled symbol is not a function [14:25:22 CET] <wm4> just a variable [14:25:52 CET] <wbs> ah, even better [14:26:09 CET] <wm4> and it's because google devs can't code [14:26:23 CET] <wm4> we check if it's NULL, and if it is, we avoid calling the public API because it'd crash [14:26:51 CET] <wm4> (which is also why the public API is useless...) [14:27:53 CET] <wm4> ubitux: https://dl.dropboxusercontent.com/u/3988935/%5BVCB-Studio%5DPSYCHO-PASS%5B0… [14:28:08 CET] <wm4> "; [Script Info]" [14:28:39 CET] <ubitux> thefuck [14:28:55 CET] <ubitux> so i'm supposed to support this? [14:29:19 CET] <wm4> yep [14:29:29 CET] <wm4> after all, vshitler does [14:29:42 CET] <wm4> (it doesn't care about sections at all btw.) [14:29:54 CET] <ubitux> ============================================================ [14:29:58 CET] <ubitux> this line isn't even commented [14:43:53 CET] <cone-599> ffmpeg 03Matthieu Bouron 07master:8c24523cc52b: lavc/mediacodec: fix chroma width for yuv420p [14:49:58 CET] <Daemon404> http://pastebin.com/KMuZPqJQ [14:50:07 CET] <Daemon404> why am i suddenly getting so many of these sorts of emails [14:50:17 CET] <Daemon404> too many git lgo entries with my name [14:50:19 CET] <Daemon404> ? [14:52:13 CET] <DHE> I get spam. I've just disabled the mailbox entirely as a result [14:52:42 CET] <nevcairiel> i get such mails about LAV all the time, I just answer with a blanket response that i do not provide email support [14:52:53 CET] <nevcairiel> not about ffmpeg tho [14:55:36 CET] <ubitux> wm4: it's going to be a bit hard for probing [14:55:49 CET] <ubitux> i mean, i can fix that particular sample by ignoring ';' but... [14:55:59 CET] <ubitux> btw, it works if you for the format as ass [14:56:27 CET] <ubitux> do you know any app where the probing of such file does actually work? [14:56:57 CET] <ubitux> i assume whatever you feed vsfilter with, it will consider it as ass so... [14:58:09 CET] <ubitux> s/if you for/if you force/ [15:01:19 CET] <wm4> ubitux: mpc-hc, vlc, ... [15:01:40 CET] <wm4> as I said, vsvilter doesn't even look at the section headers [15:01:45 CET] <wm4> or most of them [15:02:39 CET] <ubitux> aren't they relying on the extension? [15:02:51 CET] <ubitux> or do we really need to look every line for a "Dialogue" line? [15:02:59 CET] <wm4> don't know [15:03:10 CET] <ubitux> i'm not sure how to proceed here [15:11:04 CET] <wm4> ubitux: the only problem I see is accidentally probing mkv files [15:11:27 CET] <ubitux> mkv files do not contain "Dialogue" [15:11:31 CET] <ubitux> well, at least theorically [15:11:38 CET] <ubitux> the actually could if they are commented [15:11:40 CET] <ubitux> :D [15:11:58 CET] <ubitux> but "\nDialogue: " should work [15:12:05 CET] <ubitux> i'm just concerned about the speed in this case [15:13:24 CET] <ubitux> it might slow down probing significantly [15:13:34 CET] <kierank> lol "critical" [15:15:21 CET] <wm4> ubitux: just from scanning a few KB of text (at most) for a static string? [15:17:20 CET] <ubitux> remember how using a scanf in srt was slowing down shit? [15:17:30 CET] <wm4> but that was scanf [15:17:50 CET] <Compn> Daemon404 : guess you need a copy and paste reply telling them to use ffmpeg-user ? [15:18:06 CET] <ubitux> wm4: well, i'll submit a patch with a strstr later [15:18:15 CET] <Daemon404> Compn, indeed i will [16:05:02 CET] <mateo`_> i'm a bit confused, the frames of an aac sample say, nb_samples=1024, pkt_duration=993 using ffprobe. The stream duration reflects the 993 samples per packet (and not the 1024 ones) is that common ? [16:06:04 CET] <nevcairiel> is that the last one? [16:06:16 CET] <mateo`_> nope, all the packets are like that [16:06:36 CET] <nevcairiel> maybe the timebase is screwed up [16:07:08 CET] <nevcairiel> ie. its not based on samples [16:07:50 CET] <mateo`_> the time base looks good, ie: 1/44100 [16:09:02 CET] <mateo`_> nevcairiel: you confirm it shouldn't be like that (except on the last packet) ? [16:09:40 CET] <nevcairiel> if the timebase equals the sample rate, then having duration and num samples be different sounds weird [16:14:04 CET] <ubitux> michaelni: double p = -2.196152422706632; (libswscale, spline code), is this 3*(1-sqrt(3)) or just a coincidence? [16:17:30 CET] <ubitux> i lack too much knowledge about this code to have meaningful remarks but it looks like it could involve the filter parameter [16:17:51 CET] <ubitux> sth like param * (1-sqrt(3)), like in other algorithms [16:35:50 CET] <Daemon404> man... the OBB website has some iffy english [16:41:33 CET] <Daemon404> eh, too early to buy it seems. [17:10:05 CET] <Daemon404> nevcairiel, you say ffserver will die, then why are you fixing ffm> [17:10:10 CET] <Daemon404> surely ffm would die with ffserver [17:11:09 CET] <nevcairiel> it works as long as the deprecated api is available [17:11:21 CET] <Daemon404> hurr hurr [17:11:30 CET] <nevcairiel> (and you use it) [17:11:36 CET] <wm4> does it really? then why are we fixing all the deprecations inside the merge? [17:11:37 CET] <nevcairiel> no clue if ffserver uses ffmpeg.c in some capacity [17:12:32 CET] <nevcairiel> wm4: because you would otherwise have an inconsistent state where some things work with new and some with old [17:12:38 CET] <nevcairiel> ffm doesnt work with new, at all =p [17:13:34 CET] <nevcairiel> in any case, if it uses ffmpeg.c, then it will likely break again once thats moved to the new API [17:13:41 CET] <nevcairiel> if its entirely standalone, it should remain working [17:14:20 CET] <nevcairiel> its not like the fix for ffmdec was complicated [17:14:28 CET] <wm4> oh I see, so utils.c won't translate new API to old API for old (de)muxers [17:16:16 CET] <Daemon404> lol "entirely standalone" [17:16:21 CET] <Daemon404> it cosumes internal APIs [17:16:53 CET] <nevcairiel> you know what i mean, now resume productivity! [17:17:48 CET] <durandal_1707> can't it be rewritten? [17:18:00 CET] <nevcairiel> durandal_1707: go for it, we expect results in three days [17:19:04 CET] <wm4> those who want to keep it can rewrite it - or it goes [17:19:23 CET] <Daemon404> the entire concept seems just wrong to me [17:19:24 CET] <Daemon404> but eh [17:19:44 CET] <wm4> of course a rewrite should use only public API [17:20:54 CET] <durandal_1707> and what it is using? [17:21:12 CET] <durandal_1707> private only fields? [17:21:28 CET] <Daemon404> it acceses ->internal among otehr things [17:21:35 CET] <Daemon404> and uses a special format to 'serialize' an avctx [17:26:56 CET] <durandal_1707> well if it must access internal things than the only solution is to expose it [17:27:08 CET] <nevcairiel> it doesnt have to, its just the lazy way [17:27:11 CET] <Daemon404> yeah [17:27:18 CET] <Daemon404> i told them to fix it properly [17:27:31 CET] <Daemon404> all i got in response was "it's in the TODO, and i always finish my TODOs" [17:27:35 CET] <Daemon404> oh look. you didn't. [17:27:46 CET] <wm4> "them"? [17:27:51 CET] <nevcairiel> hey he didnt give yo ua time frame [17:27:54 CET] <Daemon404> the maintainer [17:32:12 CET] <durandal_1707> you mean it can be fixed without adding new API? [17:32:32 CET] <Daemon404> yes. [17:32:54 CET] <Daemon404> at least the exisiting problems can [17:32:59 CET] <Daemon404> im not sure it can be after TEP2 [17:33:36 CET] <nevcairiel> the current ffm implementation is clearly an API violation, if someone wanted to communicate an entire AVCodecContext, that shouldnt happen in a mxuer [17:34:55 CET] <Daemon404> the entire concept is dumb [17:34:59 CET] <Daemon404> you shouldnt be doing that anyway [17:35:14 CET] <ubitux> Daemon404: after tep2 is merged, send a patch to drop it [17:35:19 CET] <ubitux> we'll probably have to vote though [17:35:34 CET] <Daemon404> ubitux, as i said before, i expect full scale riots [17:35:35 CET] <nevcairiel> i have no idea why it does that, just wants to allow configuring everything on the client side i suppose? [17:35:46 CET] <Daemon404> nevcairiel, it's the only thing ever that works this way [17:35:53 CET] <ubitux> Daemon404: we have a vote system, let's make use of it [17:36:00 CET] <Daemon404> sure. [17:36:16 CET] <Daemon404> i expect there will be heavy "but it's a FEATURE" and "we cant DROP code" resistance [17:36:23 CET] <Daemon404> mostly from old timey moplayer guys [17:36:25 CET] <Daemon404> mplayer* [17:36:31 CET] <nevcairiel> what will happen: some people will ignore the system and put up some kind of ultimatum, and the more peaceful people will cave [17:36:35 CET] <nevcairiel> ie. we dont have a working system [17:36:42 CET] <Daemon404> oh you mean like hwaccel [17:36:43 CET] <Daemon404> :) [17:38:08 CET] <ubitux> we are accumulating delay in the merges, and if we haven't enough manpower to hold our balls and chain we should just get rid of them [17:38:22 CET] <ubitux> let's not call for witches before the vote happens [17:39:28 CET] <Daemon404> were not really far behind in merges [17:39:54 CET] <nevcairiel> i even "fixed" ffserver for the one we're currently working on, just need to fix everything else :p [17:40:51 CET] <ubitux> tep2 lavf, tep2 lavc, tep2 tools, bsfv2, (soon hwaccelv2?), dozens of random commits [17:40:52 CET] <kierank> Daemon404: or carl [17:40:54 CET] <kierank> fuck carl [17:41:07 CET] <Daemon404> hey i didnt mention him. [17:41:18 CET] <Daemon404> ubitux, except i think they are all net improvements [17:41:37 CET] <Daemon404> all the problems we run into merging are because of retarded shit in ffmpeg's codebase [17:41:42 CET] <Daemon404> that shouldnt have been done in the first place [17:41:59 CET] <ubitux> never said they weren't improvements, i actually support the merge [17:42:07 CET] <wm4> and yet certain people tell us these things in the code are ok... [17:42:11 CET] <ubitux> and i believe that's kind of a priority [17:42:15 CET] <Daemon404> i agree [17:42:28 CET] <Daemon404> whats left to do for TEP2? [17:42:34 CET] <Daemon404> now that im not in weekend lazymodo [17:42:36 CET] <nevcairiel> fix all the things [17:42:43 CET] <Daemon404> grepping n' fixing? [17:42:53 CET] <nevcairiel> the pad has most info [17:43:05 CET] <Daemon404> all praise The Pad [17:43:16 CET] <wm4> are there still files with deprecation warnings? [17:43:46 CET] <nevcairiel> there are a bunch of lib*.c files which still use the old way [17:44:18 CET] <nevcairiel> mov(enc) seems entirely broken for some reason [17:44:20 CET] <wm4> what was the resolution for micrtodvd? [17:44:26 CET] <nevcairiel> and we have to decide what to do about has_b_frames [17:44:27 CET] <mateo`_> where the pad located at ? I'd like to participate (if I have time) [17:44:28 CET] <wm4> bleh [17:44:33 CET] <Daemon404> mateo`_, https://public.etherpad-mozilla.org/p/ffmpeg-tep2-merge [17:44:44 CET] <Daemon404> i can add you to collaborators [17:44:46 CET] <Daemon404> if you wish to push [17:45:06 CET] <ubitux> are we going to push the lavf work before we start merging lavc? [17:45:18 CET] <ubitux> so we can have a first wave of fixes in between [17:45:30 CET] <Daemon404> ubitux, probably a better idea not to push all that stuff at once [17:45:54 CET] <Daemon404> and it builds up less of a giant code dump [17:45:55 CET] <nevcairiel> lavc is not impacted by this tep [17:46:06 CET] <mateo`_> Daemon404: you need a github account for that ? [17:46:11 CET] <Daemon404> mateo`_, yes [17:46:25 CET] <Daemon404> i dont think github lets you add non-github people [17:46:31 CET] <mateo`_> Daemon404: my account is mbouron [17:46:48 CET] <ubitux> nevcairiel: yes i know (there are a few changes though), i was wondering if we were going to push the 2 merge commits respectively for tep2-lavf and tep2-lavc at the same time [17:46:55 CET] <Daemon404> done [17:46:57 CET] <Daemon404> @ mateo`_ [17:47:05 CET] <mateo`_> Daemon404: thanks [17:49:06 CET] <nevcairiel> Daemon404: and why would the packet size change? sounds fishy :) [17:49:24 CET] <Daemon404> nevcairiel, because it uses nut [17:49:27 CET] <Daemon404> for ffprobe* [17:49:35 CET] <nevcairiel> thats not an explanation [17:49:44 CET] <nevcairiel> why do nut packets suddenly change size then? [17:50:06 CET] <Daemon404> i need to re-read, but somethig similar happened i na recent merge of nut [17:50:08 CET] <Daemon404> lemme dig it up [17:50:22 CET] <nevcairiel> nut is one of the things were all related tests seem to fail, anyway [17:50:25 CET] <nevcairiel> needs revisiting [17:50:42 CET] <Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=14a69ae60c64a071eb65a8521b… [17:51:53 CET] <Daemon404> padding related i think [17:53:03 CET] <nevcairiel> someone should figure out why avfilter barfs at us [17:53:05 CET] <nevcairiel> that seems unrelated [17:53:08 CET] <nevcairiel> unless also nut :p [17:53:11 CET] <Daemon404> nevcairiel, looks related to vlcs [17:53:27 CET] <Daemon404> does nut pack headers? [17:54:12 CET] <durandal_1707> nevcairiel: what in lavfi barfs? [17:54:19 CET] <nevcairiel> everything [17:55:00 CET] <durandal_1707> because of codecpar? [17:55:37 CET] <nevcairiel> oh the video_filter test uses nut encoding [17:55:41 CET] <nevcairiel> thats probably a reason then [17:55:49 CET] <Daemon404> i image most of these failures are nut or mov [17:56:30 CET] <nevcairiel> should probably fix those to get a cleaner view of whats happening [17:57:17 CET] <Daemon404> i dont know if it will be easy to 'fix' [17:57:32 CET] <Daemon404> it uses ff_get_v_length to find the minimal amount of bytes it can use to write given values [17:57:40 CET] <Daemon404> so even if they change slightly, which may be expected [17:57:44 CET] <Daemon404> packet sizes change [17:58:07 CET] <Daemon404> and fate is hash based [17:58:18 CET] <nevcairiel> any why would such a function change behavior [17:58:56 CET] <nevcairiel> if we write something differently to before, thats a bug first, unless we can prove the new value is clearly better [17:59:28 CET] <Daemon404> in the case i saw before, it was "both values are equally dumb" [18:02:34 CET] <nevcairiel> the nut muxer doesnt seem to access anything too crazy, unless it was removed entirely in the merge somewhere [18:02:45 CET] <nevcairiel> should diff it, i suppose [18:04:54 CET] <nevcairiel> the only thing it accesses is has_b_frames, which raw video shouldnt set [18:07:20 CET] <Daemon404> hmm [18:07:25 CET] <Daemon404> can you diff the fate results? [18:07:34 CET] <Daemon404> ffprobe ones should make it clear what changed [18:07:43 CET] <Daemon404> ffprobe_json should be easy [18:09:20 CET] <ubitux> oh, ffmpeg/libswscale is mentioned in http://www.ipol.im/pub/art/2011/g_lmii/ [18:09:49 CET] <nevcairiel> looks like the codec timebase is something it previously wanted [18:10:03 CET] <nevcairiel> i wonder why anton didnt want to keep that, so many formats seem to want it somehow [18:10:18 CET] <Daemon404> i keep asking, and people keep not answer [18:10:21 CET] <Daemon404> *what is codec timebase* [18:11:17 CET] <bencoh> :] [18:11:27 CET] <durandal_1707> nonsense, it shouldnt exist [18:11:41 CET] <bencoh> agreed [18:11:52 CET] <Daemon404> people cant even tell me what it is, so i am erring on "this was wrong to begin with" [18:12:31 CET] <nevcairiel> many coded formats encode timing information in the bitstream, that. [18:12:37 CET] <nevcairiel> for some reason some containers want to know it [18:13:11 CET] <durandal_1707> write parsers [18:13:17 CET] <Daemon404> nevcairiel, nut doesnt use it for anything other than writing r_frame_rate metadata [18:13:26 CET] <Daemon404> in which case... why the hell doesnt it use st->time_base? [18:13:32 CET] <Daemon404> it tries st->frame_rate above first too [18:13:44 CET] <nevcairiel> because nut controls st->time_base [18:13:49 CET] <nevcairiel> it has nothing to do with the incoming data [18:13:53 CET] <Daemon404> ah right [18:14:06 CET] <Daemon404> so why does it need to write r_frame_rate when there is no framerate given [18:14:20 CET] <wm4> how the hell do parsers work now at all [18:14:32 CET] <ethe> eeyyy rekt [18:14:38 CET] <ethe> jack outdev working [18:25:29 CET] <jamrial_> the trailing_padding field in codecpar, is it meant to do the same thing we're doing with AV_PKT_DATA_SKIP_SAMPLES? [18:28:05 CET] <wm4> jamrial_: yes [18:28:30 CET] <wm4> to be honest, I don't know how the trailing_padding field is supposed to be applied [18:28:40 CET] <wm4> you rarely know whether something is the last packet/frame [18:29:37 CET] <jamrial> libav doesn't seem to be using it yet. at leat the lavf commit we're currently messing with didn't touch it [20:01:00 CET] <nevcairiel> so i've been getting an report that some odd mp3 files start playing with an audible glitch, and i was looking into them. the files look like they had an id3 tag cut off incompletely, and now the file just happens to start at a string [20:01:07 CET] <nevcairiel> said string has a utf8 bom for some reason [20:01:16 CET] <nevcairiel> .... and a bom looks like a valid mpeg audio header [20:01:21 CET] <nevcairiel> fuck this mp3 format [20:01:32 CET] <kierank> everything is an mp3 [20:01:39 CET] <nevcairiel> well the file is an mp3 [20:01:46 CET] <nevcairiel> but i wanted to skip the garbage [20:01:51 CET] <nevcairiel> but it appers somewhat valid =p [20:03:08 CET] <nevcairiel> for some reason one other mpeg decoder seems to not have this problem [20:03:11 CET] <nevcairiel> i wonder what it does [20:07:40 CET] <J_Darnley> crc check maybe [20:07:56 CET] <J_Darnley> if it fails, play silence [20:08:05 CET] <nevcairiel> where would i get a crc from =p [20:08:38 CET] <jamrial> the format's crc field nobody uses, of course [20:09:21 CET] <nevcairiel> i dont even know where i would find a spec on this mp3 format, mpeg-2 audio i suppose? [20:10:36 CET] <J_Darnley> but a not-mp3 frame might say "crc: yes" which then fails to match [20:15:40 CET] <relaxed> /quit [20:23:06 CET] <jamrial> kierank: ^ [20:36:51 CET] <iive> nevcairiel: it's mpeg1 layer3 [20:51:04 CET] <kierank> can't remember if I implemented that stuff [20:55:22 CET] <jamrial> you implemented the opus in mpegts demuxing code, yes [20:55:42 CET] <jamrial> commit 9cfa68c560bdec82d2d5ec079f9c5b0f9ca37af0 [20:56:13 CET] <kierank> I mean the preskip thing [21:02:31 CET] <jamrial> no, this is about the trailing padding information (or discard samples/padding) for the last Opus frame [21:02:48 CET] <jamrial> preskip is codecdelay or initial padding, afaik [21:25:20 CET] <ubitux> damn, flif marketting strikes back after 1yr [21:31:48 CET] <durandal_1707> are there lossless compresed derf samples? [21:50:43 CET] <cone-792> ffmpeg 03Clément BSsch 07master:2b7a61cbd8ae: lavc/utils: fix extra ASS sanity check in convert_sub_to_old_ass_form() [22:39:19 CET] <cone-792> ffmpeg 03Paul B Mahol 07master:f20cdcbc055d: avfilter/vf_vectorscope: draw color points names [23:01:35 CET] <cone-792> ffmpeg 03Michael Niedermayer 07master:da904faaa546: avcodec: try to document timebase a bit more [23:02:33 CET] <TD-Linux> durandal_1707, I maintain those samples, what sort of compression do you mean? [23:03:34 CET] <durandal_1707> xiph ones? [23:03:59 CET] <TD-Linux> https://media.xiph.org/video/derf [23:05:23 CET] <durandal_1707> just y4m in gigs ffv1 could lower it [23:06:44 CET] <TD-Linux> durandal_1707, yeah currently some of them are xz'd, ffv1 might be a better choice [23:30:33 CET] <TD-Linux> durandal_1707, I assume matroska is the preferred container for ffv1? [23:31:46 CET] <durandal_1707> its fine [23:58:27 CET] <cone-792> ffmpeg 03Carl Eugen Hoyos 07master:51bcc0bf38d8: lavf/riff: Add fourcc GTM4 from Telefactor digital audio for ASP. [00:00:00 CET] --- Tue Mar 8 2016

1 0

ffmpeg.log.20160307
by burek 08 Mar '16

08 Mar '16

[00:00:10 CET] <J_Darnley> He might mean Libav. [00:03:38 CET] <galex-713> jookiyaya: err yeah libav sorry [00:04:08 CET] <galex-713> So yeah Im reading wikipedia now, but Id like to know what happened again [00:04:52 CET] <J_Darnley> Drama(TM) [00:30:53 CET] <galex-713> A little question: when -compression-level description says better quality and slower encoding, does it mean quality as more audio quality/nice to hear or more efficient compression? [00:31:06 CET] <TD-Linux> the latter, generally [00:31:49 CET] <TD-Linux> to be specific, it increases the quality per bit that you get. [00:32:02 CET] <galex-713> Ok [00:32:14 CET] <TD-Linux> whether that means your quality is better, or your bitrate is less depends on the rate control mode you use [00:34:36 CET] <TD-Linux> you can probably get a better answer in #opus [00:34:42 CET] <galex-713> Ah ok [00:34:44 CET] <TD-Linux> note that opus's slowest compression setting is still pretty fast for most purposes [00:34:59 CET] <galex-713> Yeah I noticed that [00:36:35 CET] <galex-713> I just noticed for a 2Gio/2 hours wav libmp3lame gave me a 5,3M file and opus gives me at minimum 70M for 80kbps/-compression_level=10, and both sounds the same at my hears, and I find this disturbing/questionning [00:36:44 CET] <galex-713> Since I always heared that opus > vorbis > mp3 [00:38:37 CET] <TD-Linux> galex-713, I think your settings are off [00:39:29 CET] <galex-713> are off? [00:39:50 CET] <TD-Linux> those file sizes imply 155kbps for Opus and 12kbps for MP3. [00:40:11 CET] <galex-713> vbr for both I think [00:40:23 CET] <TD-Linux> yeah something is getting set wrong because neither should be that far from 80kbps [00:40:24 CET] <galex-713> And thats just a guy speaking with pretty low sound [00:41:23 CET] <TD-Linux> can you paste your command line? (also brb) [00:42:41 CET] <galex-713> for opus I used ffmpeg -i file.wav -acodec libopus -vbr on -compression_level <0 or 9> -b:a <80, 96, 128 or 256 kbps> -application voip -y file.<compression_level>.<bitrate>.opus [00:43:51 CET] <galex-713> for mp3 it was something like ffmpeg -i file.wav -acodec libmp3lame -q <0 or 9> -y file.<bitrate>.mp3 I think [00:43:57 CET] <galex-713> Maybe I did set bitrate on it [00:58:40 CET] <rainabba> I'm still stuck on multi-casting and I'm wondering if it's because I've made a bad assumption. If I output to udp://192.168.1.10:5501 (and this is an address on the machine running ffmpeg), I can connect using VLC and the same address. I cannot from another machine on the same lan. Should I be able to (firewalls not withstanding of course)? [01:04:42 CET] <TD-Linux> galex-713, hmm, that looks pretty much correct. try dropping -compression_level, -vbr, and -application and see what happens [01:05:07 CET] <TD-Linux> you could also try opusenc directly [01:05:17 CET] <TD-Linux> note that if you're compressing voice 80kbps is overkill [01:05:50 CET] <Burlington> Good evening folks, I am trying to use FFMPEG to receive a UDP MpegTS and output it on a DeckLink SDI 4K. Here is my problem: http://pastebin.com/Szqz4PMA [01:11:44 CET] <c_14> Burlington: [decklink @ 0xa678960] Unsupported video size or framerate! Check available formats with -list_formats 1. [01:16:41 CET] <rainabba> Trying to get HLS setup with "-f hls -use_localtime 1 -use_localtime_mkdir 1 -hls_segment_filename %Y%m%d/%Y%m%dT%H%M%S-%s.ts playlist.m3u8", but I get "[mpegts @ 000001dc33190fe0] Could not get segment filename with use_localtime", debug makes it appear that all options are recognized and are valid. Any suggestions? [01:17:13 CET] <rainabba> I found the following, but don't have enough context to really use it in troubleshooting: https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/hlsenc.c#L528 [01:18:49 CET] <c_14> The call to strftime is failing [01:19:12 CET] <c_14> hmm, it should work though [01:22:10 CET] <c_14> works for me [01:22:16 CET] <rainabba> Linux or WIndows? [01:22:19 CET] <c_14> linux [01:22:47 CET] <rainabba> I'm going to bet a bad assumption was made :) One more reason I need to setup my own compile. [01:24:01 CET] <c_14> POSIX doesn't define %s [01:24:09 CET] <c_14> That's a (probably GNU) addition [01:25:42 CET] <rainabba> "-f hls -use_localtime 1 -use_localtime_mkdir 1 -hls_segment_filename foo.ts playlist.m3u8" Works fine so it's the resolution of %s failing. That is the token for the .ts file index though right? [01:26:28 CET] <c_14> %s is seconds since epoch [01:26:45 CET] <rainabba> ahh [01:27:55 CET] <rainabba> 'foo-%Y%m%d.ts' works [01:28:19 CET] <rainabba> 'foo-%Y%m%d%S.ts' works!!! [01:28:50 CET] <c_14> you should be able to use the one you have know just with the -%s removed [01:29:21 CET] <rainabba> Chunk names will need more resolution. Need to add minutes in there in fact. [01:30:17 CET] <rainabba> %Y%m%d%H%M%S.ts does it :) [01:37:31 CET] <Burlington> @c_14 Thank you. That seems to have corrected the problem/moved me on to the next problem! [01:43:45 CET] <Wader8> hello [01:45:22 CET] <Wader8> trying to figure out CRF setting for x265 since I heard it work a bit different, i'm converting from youtube's x264 and wish to use same quality for lower size (preset veryslow) and sometimes I download 720p HD, sometimes 480 and sometimes 360 depending on the type of content [01:46:14 CET] <JEEB> re-encoding youtube stuff makes no sense due to how heavily youtube compresses while not trying to compress well [01:46:40 CET] <JEEB> if you are the person who created those clips you should be able to still get the source, I think? [01:46:58 CET] <JEEB> and then you can re-encode if you want a proper encode in another format [01:47:09 CET] <JEEB> in case of already raped stuff it just doesn't matter at all [01:47:22 CET] <JEEB> it's already bad so it doesn't matter [01:48:06 CET] <Wader8> Why do I get this response from everyone ? No offencce, but a lot of stuff I donwload is in the range of 100-300 MB, I could lower that by 40% according to x265 capabilities right, while preserving "same" quality as the original download [01:48:39 CET] <JEEB> because youtube is really bad at compression? [01:48:45 CET] <Wader8> And I have a ton of videos to sort,archive, store etc, I download like 10-20 videos per week [01:48:55 CET] <JEEB> it both bit rate starves as well as applies fast settings [01:49:29 CET] <JEEB> like, if its output looks good enough for you and it's not your clip - sure. I just don't believe you will get a major win [01:49:32 CET] <Wader8> JEEB, why does that matter with what I'm trying to achieve, lower size on same quality the video I got from YT ? [01:49:47 CET] <JEEB> because the more artifacts you have the harder it is to compress [01:50:17 CET] <JEEB> and you won't get the same quality. there will be loss no matter what, but it's not necessarily visible [01:50:18 CET] <Wader8> According to x265 specs it should achieve 40% lower size than x264 at same bitrate I heard in headlines [01:50:27 CET] <JEEB> that's source to output [01:50:31 CET] <JEEB> not source to output to output [01:50:42 CET] <JEEB> also that is theoretical, the implementations are a whole separate thing [01:50:44 CET] <jkqxz> Have you actually tried reencoding with H.265 and compared the output? The quoted 40% bitrate benefits of H.265 require you to have the raw source. If very lossy compression has already been applied then it is hard to make useful improvements. [01:51:46 CET] <jkqxz> (If the input is relatively high bitrate (i.e. closer to the raw source) then you may still be able to win, but youtube will not provide that.) [01:53:13 CET] <Wader8> The videos are important to me but they're not like professional archiving here, as long as some key text can be read and the speech-sound heard so it can be understood it's fine, I don't might the small % of loss if I save 40% size that's huge, I have a lot of space ready, 2x2TB drives, but gosh stuff piled up in the last 5 years and in the last 2 years I downloaded like 5 thousand videos... [01:53:14 CET] <Wader8> ...probably, ranging from 2GB to 300 MB but a lot of them are around 50 to 150 MB [01:53:27 CET] <jkqxz> As a simple rule, if you can ever see any significant artifacts in the input (macroblock edges, say) then there will be no significant benefit (because the reencode will see the macroblock edges as detail and reproduce them rather than what you actually wanted). [01:55:28 CET] <Wader8> jeeb well I appreciate the technical explanation, but jkqxz would ever x265 have ability to detect these and not do what it would do, shouldn't there be an option to make the codec treat input not as raw source but as bad output and apply different set of processings ? [01:57:27 CET] <Wader8> Mostly it's 720p, but some of the stuff doesn't need that high quality, i mean, i need to save on space if I can make my personal small archive, I can't DL everything in HD, so I've started using 480p and 360p links but they're all HD source uploads that go to 1080 and these usually look good and without artifacts even on the lowest resolution links [01:58:22 CET] <Wader8> it doesn't look like streaming, i don't see any of such artifacts when I put this 360p video into fullscreen [02:00:28 CET] <Wader8> So if I would do this the CRF setting to use should work OK for all these qualities, cause the point is to automate this, i have like 20 thousand videos total, a lot of them from different times with different version of YT compressers over the years, i know it's a mess, http://slhck.info/articles/crf so this page has for x264 should this also apply to x265 ? [02:04:38 CET] <Wader8> JEEB, what if I download from the 1080p link, then put it into 360p and same bitrate/settings with x265 as YT has it for the 360p link in x264 .... workaround ;) ? [02:05:10 CET] <jkqxz> Yes, CRF works in essentially the same way for x265. The range is not exactly the same, but since you will need to test it to determine what value you actually want that doesn't actually matter (and it may vary significantly by the input because the compression will have different properties, making automation hard). [02:07:03 CET] <Wader8> jkqxz, please let there be an app on the net I could sort/move video files according to metadata statistics, I can then make several groups, 720p ones got this settings and 480p gets that, separate batch file, etc [02:07:29 CET] <Wader8> Let me see if File Menu Tools can do that [02:07:34 CET] <Wader8> Im on Windows btw [02:07:54 CET] <Wader8> But obviously I can put Linux live on any time just to get this done [03:03:58 CET] <tema_> hi all [03:04:36 CET] <tema_> I would like to know where can I report a problem with ffmpeg rss [03:04:54 CET] <tema_> rss xml is broken [03:05:41 CET] <tema_> feedvalidator.org reports that 'Sorry This feed does not validate' [03:05:52 CET] <c_14> ffmpeg has an rss? [03:06:01 CET] <tema_> surprisingly yes [03:06:11 CET] <c_14> ah, found it [03:06:14 CET] <c_14> it's empty [03:06:31 CET] <c_14> open an issue on trac [03:06:50 CET] <tema_> I don't know how to do it [03:07:30 CET] <tema_> I used to get ffmpeg news on updates via rss a couple of years ago [03:07:53 CET] <c_14> https://trac.ffmpeg.org/ [03:07:57 CET] <c_14> create an account and then create an issue [03:08:03 CET] <tema_> I will try [03:22:23 CET] <tema_> cool. round number: https://trac.ffmpeg.org/ticket/5300 [03:26:51 CET] <tema_> thanks c_14 and good night/day/... [06:47:15 CET] <jookiyaya> why is it so hard to split a .mkv file exact seconds [06:56:19 CET] <Akanksha_> What does index mean in streams? Sorry for naive question. I am new to all these things. Thanks in advance. :) [06:59:48 CET] <yongyung> jookiyaya: What do you mean? [07:02:47 CET] <jookiyaya> for example i want split the video 5 min video into 1:00 and 4:00 [07:02:58 CET] <jookiyaya> for example i want split 5 min video into 1:00 and 4:00 [07:03:47 CET] <yongyung> jookiyaya: Do you mean from 1:00 to 4:00? [07:04:10 CET] <jookiyaya> no [07:04:18 CET] <yongyung> Or do you mean you want to split it in 5 1:00 minute parts? [07:04:24 CET] <jookiyaya> no [07:04:32 CET] <jookiyaya> originalvideo = 5:00 [07:04:40 CET] <jookiyaya> video1 duration 1:00 [07:04:44 CET] <jookiyaya> video2 duration 4:00 [07:05:27 CET] <yongyung> jookiyaya: Alright, so what exactly isn't working? [07:05:55 CET] <jookiyaya> it's splitting into 1:05 and 3::55 [07:05:59 CET] <jookiyaya> or something like that [07:06:09 CET] <yongyung> jookiyaya: What command have you used? [07:07:41 CET] <jookiyaya> ffmpeg -i input.mkv -vcodec copy -acodec copy -ss 00:00:00 -t 01:00:00 output1.mkv [07:07:46 CET] <jookiyaya> is that right [07:10:36 CET] <yongyung> jookiyaya: What happens with "ffmpeg -ss 00:00 -i input.mkv -t 60 -c copy output1.mkv"? [07:10:48 CET] <yongyung> Or just leave the -ss away for the first one [07:10:55 CET] <yongyung> -ss 00:00 is probably stupid [07:13:10 CET] <jookiyaya> if the video is 1 hour and i want from 2 min mark to 57 min mark: what do i type [07:14:20 CET] <yongyung> "ffmpeg -ss 02:00 -i input.mkv -t 55:00 -c copy output1.mkv" [07:15:32 CET] <jookiyaya> does that command work for every container format? [07:16:20 CET] <yongyung> Yes [07:17:06 CET] <yongyung> Well, every container format where you can seek and cut without reencoding I guess, also -c copy only copies the first video and audio stream I think or something like that, but basically yes [07:19:37 CET] <jookiyaya> didn't work [07:20:15 CET] <yongyung> jookiyaya: Could you be a bit more specific [07:20:52 CET] <jookiyaya> especially the 57 mark [07:21:56 CET] <yongyung> Sorry but nobody can help you with error descriptions like that [07:22:07 CET] <jookiyaya> if the video is 1 hour and i want from 2 min mark to 57 min mark [07:22:32 CET] <jookiyaya> so total video duration of output.mkv = 55min [07:22:55 CET] <jookiyaya> it did cut the 1st 2 mins but not the last 3 min [07:24:08 CET] <jookiyaya> and it didn't cut the 1st 2 min precisely [07:26:07 CET] <jookiyaya> do you understand or no? [07:26:59 CET] <yongyung> jookiyaya: Well, if it doesn't cut precisely the keyframe interval of the video stream might be too big, but it should've cut the last 3 minutes regardless, what's the console output? [07:27:06 CET] <yongyung> post on pastebin.com [07:29:35 CET] <jookiyaya> http://pastebin.com/AZAYqcDh [07:34:05 CET] <yongyung> jookiyaya: Yeah my guess is that the video files keyframe interval is too high, so you'd have to transcode for accurate cuts [07:34:33 CET] <jookiyaya> yongyung before that, how come it's not cutting the last 3 min [07:35:10 CET] <jookiyaya> if the video is 1 hour and i want from 2 min mark to 57 min mark [07:35:22 CET] <jookiyaya> assuming original video is 1 hour [07:36:08 CET] <yongyung> jookiyaya: I don't know, if you could send me the file I could try it out, but it seems rather big. If you cut like a minute out of the video, and then try to cut 30s out of that cut, does it work? Because if it doesn't, just send me the 1 minute clip [07:37:04 CET] <jookiyaya> could be the command is wrong [07:39:28 CET] <jookiyaya> i want to cut the 1st 2min of the video and the last 3 min of the video [07:41:11 CET] <yongyung> command isn't wrong [07:41:20 CET] <yongyung> unless you want to transcode [07:42:18 CET] <jookiyaya> if i do it works: ffmpeg64 -ss 00:00 -i 5.mkv -t 36:13 -c copy R:\5.mkv" [07:42:55 CET] <jookiyaya> this doesn't work though: ffmpeg64 -ss 01:10 -i 5.mkv -t 36:13 -c copy R:\5.mkv" [07:44:23 CET] <jookiyaya> is this a bug [07:48:31 CET] <jookiyaya> and if i do ffmpeg64 -ss 01:10 or ffmpeg64 -ss 01:12 or ffmpeg64 -ss 01:13 it makes no difference [07:51:52 CET] <jookiyaya> i don't understand why this is so difficult [07:55:17 CET] <yongyung> jookiyaya: Frames aren't saved as pictures in a video, they're basically deltas from the previous frame. Keyframes are, though. So without reencoding, you can only cut from keyframe to keyframe. If your video does only have a keyframe every 5 seconds or so, that's where you can cut without reencoding. Some containers have features that allow you to skip frames at the start of the stream, so it seems like you cut somewhere else, but I'm not [07:55:17 CET] <yongyung> sure about mkv [07:55:48 CET] <jookiyaya> i don't have this problem with .wmv file [07:56:03 CET] <jookiyaya> i can cut precisely with wmv file [07:56:08 CET] <yongyung> Well it's a completely different file with completely different keyframes [07:56:54 CET] <yongyung> Also not "from keyframe to keyframe", sorry, but only from a keyframe [07:57:20 CET] <yongyung> Which is why I'm not sure why the last 3 minutes aren't cut, they should be cut, but like I said, I'd need access to an example file to fiddle with it [07:57:28 CET] <yongyung> Because it works for every normal .mkv file just fine [07:57:33 CET] <jookiyaya> yongyung just get any mkv file [07:57:37 CET] <jookiyaya> and try, it won't work [07:57:47 CET] <yongyung> jookiyaya: It works just fine [07:58:05 CET] <jookiyaya> if i am cutting just the last 3 in, it works [07:58:21 CET] <jookiyaya> but if am cutting beginning and the end, in one command, then it doesn't work [07:58:30 CET] <jookiyaya> min* [08:00:04 CET] <jookiyaya> are you doing both at the same time in one command? [08:01:09 CET] <yongyung> yes [08:04:52 CET] <rainabba> Possible to have ffmpeg listen for rtmp then use an input? Basically, I've got an app that can only push to RTMP and I need to grab that and handle it with ffmpeg (directly or indirectly). [08:05:24 CET] <rainabba> I found the rtsp_flags so it seems likely enough, but I don't see rtmp equivalent. [08:53:35 CET] <JoEMoMMa> when using the following command....i get a error during the movie scan but nothing is writing to the error.log file. [08:53:37 CET] <JoEMoMMa> ffmpeg -v verbose -i Room.mkv -f null - > error.log [09:34:46 CET] <relaxed> JoEMoMMa: 2> error.log [09:43:41 CET] <JoEMoMMa> tried that and i get .... [09:43:45 CET] <JoEMoMMa> [NULL @ 0x809052c20] Unable to find a suitable output format for '2' [09:43:45 CET] <JoEMoMMa> 2: Invalid argument [10:05:15 CET] <rainabba> I've got 2 BlackMagic DeckLink 4K Pro cards installed and can't figure out how to target a particular one with ffmpeg. Can anyone help? [10:09:51 CET] <rainabba> listdevices shows them both, but with the same name: [decklink @ 000002253401bf00] Blackmagic DeckLink devices: [10:09:51 CET] <rainabba> [decklink @ 000002253401bf00] 'DeckLink 4K Pro' [10:09:51 CET] <rainabba> Last message repeated 1 times [10:58:27 CET] <Wader8> hello again [11:01:56 CET] <Wader8> I'm suppose to lower the bitrate I would get similar quality for lower size ... i guess having the bitrate same like x264 file when putting to x265 doesn't make it smaller by much ..... I guess bitrate doesn't mean quality i figured, it's relative to the codec, In the past I always thought bitrate to be the decoded stream, not the compressed file [11:04:30 CET] <Hfuy> Hello. [11:05:15 CET] <JoEMoMMa> still cant figure this out...when i run ffmpeg -v verbose -i file.mkv -map 0:1 -f null - > error.log it will scan and fit finds a error but it will not log to the error.log file. When i try to add a "2" like so...ffmpeg -v verbose -i file.mkv -map 0:1 -f null - 2> error.log it gives me a [NULL @ 0x809052020] Unable to find a suitable output format for '2' [11:05:42 CET] <Hfuy> Let's say I do this: ffmpeg -i foo.mov -c:v prores_ks -profile:v 4444 foo_prores.mov [11:06:21 CET] <Hfuy> Will that maintain the 10-bit information from the 10-bit input, or will it get truncated? [11:06:34 CET] <Hfuy> Do I need to specifically say -pix_fmt yuv444p10le? [11:07:49 CET] <c_14> JoEMoMMa: works for me. What shell? [11:07:52 CET] <c_14> Hfuy: check the output, it should say [11:08:11 CET] <Hfuy> It said a lot of things. [11:08:30 CET] <Hfuy> This is more of a generic question. [11:09:00 CET] <Hfuy> I'm trying to understand what the internal architecture is, so I can understand how this sort of thing will behave in general. [11:09:20 CET] <Hfuy> I mean, it's certainly producing a 10-bit output file, but I have no idea if it's really got 10 bits of information in it. [11:10:13 CET] <c_14> If the encoder supports both bit depths, it should maintain 10bit [11:10:41 CET] <Hfuy> Well, there wouldn't be a lot of point in supporting ProRes 4444 if it didn't, I guess. [11:10:42 CET] <c_14> Unless a filter in the filterchain doesn't support 10bit (not sure if there are any of those) [11:11:07 CET] <Hfuy> It doesn't seem to support RGB. [11:11:39 CET] <Hfuy> ProRes 4444 in general should do, but I don't think the ffmpeg implementation does. Certainly it barfs on -pix_fmt gbrp10le [11:12:07 CET] <JoEMoMMa> freenas, inside a jail [11:12:10 CET] <Hfuy> This is slightly counterintuitive as I'm not sure what difference it would make mathematically. [11:12:24 CET] <JoEMoMMa> so freebsd basiclly [11:12:34 CET] <c_14> JoEMoMMa: that's not a shell. bash, ksh, tcsh, zsh, heirloom sh? [11:12:41 CET] <c_14> csh? [11:12:43 CET] <JoEMoMMa> tcsh [11:13:01 CET] <Hfuy> Is r10k even a pix_fmt anymore? [11:14:38 CET] <c_14> JoEMoMMa: tcsh afaik doesn't support 2> either use something bashy or use >& [11:14:49 CET] <JoEMoMMa> i could try bash but have not [11:15:09 CET] <c_14> Hfuy: it's not listed in my pix_fmts at least [11:15:36 CET] <Hfuy> Hmm. I'm pretty sure it used to be, though I could be wrong. [11:15:50 CET] <Hfuy> Is there a standard way of indicating codec options such as "RGB please?" [11:17:19 CET] <c_14> you could use the format filter with pix_fmts=[a '|' separated list of all rgb pixel formats] [11:17:33 CET] <c_14> Don't know of any other way. [11:17:54 CET] <Hfuy> Hmm. [11:18:05 CET] <Hfuy> It would surprise me somewhat if they'd supported YUV 444 and not RGB [11:34:51 CET] <hyponic> I am restreaming a stream using ffmpeg but the source streams seems to have a quick drop every few minutes. i have script that respawns the connection but the problem is that the clients disconnect. is there a way to get ffmpeg to fill up the gap or keep the client connection while waiting to respawn? the respawn time is about half a second. [12:17:54 CET] <relaxed> JoEMoMMa: read the tcsh man page or use sh [12:19:42 CET] <jookiyaya> i cannot cut the 3 seconds of a mkv video using ffmpeg [12:24:55 CET] <odinsbane> jookiyaya: What did you try, and what is the error? [12:25:23 CET] <jookiyaya> it cuts 6 seconds [12:25:43 CET] <jookiyaya> even if i choose 3/4/5 [12:27:05 CET] <odinsbane> did you use ffmpeg -i source.mp4 -ss 3 ... [12:27:52 CET] <jookiyaya> ffmpeg64 -ss 00:03 -i 5.mkv -t 60:00 -c copy R:\5.mkv" [12:28:02 CET] <jookiyaya> assuming original video is 1 hour [12:28:30 CET] <jookiyaya> when i am cutting the end , then it works fine by seconds [12:28:39 CET] <jookiyaya> but cutting the beginning, it has problems [12:29:00 CET] <odinsbane> http://stackoverflow.com/questions/12208639/ffmpeg-convert-video-from-speci… [12:29:33 CET] <jookiyaya> so it's a known issue? [12:30:09 CET] <odinsbane> The location of -ss can make a difference. [12:30:23 CET] <jookiyaya> i don't understand [12:30:56 CET] <odinsbane> ffmpeg -ss 00:03 -i 5.mkv vs ffmpeg -i 5.mkv -ss 00:03 ... [12:31:18 CET] <jookiyaya> oh [12:32:04 CET] <jookiyaya> are you sure that will magically fix my issue [12:32:27 CET] <odinsbane> no. [12:33:31 CET] <jookiyaya> how do i fix it then [12:37:18 CET] <odinsbane> jookiyaya: http://trac.ffmpeg.org/wiki/Seeking [12:39:09 CET] <jookiyaya> not understanding what that page is trying to do in the first place [12:39:29 CET] <jookiyaya> i am trying to cut 3 seconds of video in the front [12:39:39 CET] <odinsbane> That is what the -ss parameter does. [12:39:53 CET] <odinsbane> It is called seeking, that is what that page is about. [12:40:37 CET] <odinsbane> Scroll to the bottom, and read Seeking while doing a codec copy [12:42:31 CET] <jookiyaya> why is this so difficult [12:42:32 CET] <odinsbane> Using the -ss after you specify the input *can* be more accurate. Using copy will cause you to only be able to cut at keyframes, so you *most likely* cannot use copy. You will have to re-encode. [12:43:10 CET] <jookiyaya> explain why cutting the end of the video works fine [12:43:24 CET] <jookiyaya> precisely to the second [12:49:36 CET] <jookiyaya> also this does not work: ffmpeg64 -ss 01:00 -i 5.mkv -t 59:00 -c copy R:\5.mkv" [12:50:12 CET] <odinsbane> What doesn't work about it. [12:50:24 CET] <jookiyaya> it cuts 1st min but not last 1 min [12:50:43 CET] <jookiyaya> asssuming original video is 1 hour [12:51:00 CET] <jookiyaya> ffmpeg64 -ss 00:00 -i 5.mkv -t 59:00 -c copy R:\5.mkv" [12:51:04 CET] <jookiyaya> that works though [12:51:08 CET] <odinsbane> Yes, you start at minute 1 and go for 59 minutes, which means it goes to thte end. [12:51:10 CET] <c_14> jookiyaya: 60 - 1 = 59 [12:51:32 CET] <c_14> odinsbane: using -ss after the input doesn't make it more accurate than before (assuming you don't set -noaccurate_seek) [12:51:38 CET] <jookiyaya> so what is the command then if i want to cut 1st min and last 1 min [12:52:04 CET] <jookiyaya> 1 hour original video [12:52:13 CET] <c_14> jookiyaya: either calculate the duration beforehand or use -ss after -i and -to instead of -t [12:52:34 CET] <c_14> You need to know the duration of the file beforehand in either case [12:52:39 CET] <jookiyaya> so if the video is 1 hour exactly, what do i type [12:53:29 CET] <c_14> To do what? [12:54:18 CET] <jookiyaya> original video = 1 hour exactly: i want to cut 1st one min and last one min: final video's duraction = 58 min [12:54:38 CET] <c_14> ffmpeg -ss 1:00 -i input -t 58:00 out.mkv [12:54:59 CET] <c_14> or ffmpeg -i input -ss 1:00 -to 59:00 out.mkv [12:55:19 CET] <relaxed> maybe -copyinkf would help [12:55:50 CET] <jookiyaya> oh, so i have to use -to instead of -t [12:57:09 CET] <c_14> you can also use ffmpeg -ss 1:00 -i input -copyts -to 59:00 out.mkv [12:59:53 CET] <JoEMoMMa> can ffmpeg be used to repair video files that contain errors? [13:06:37 CET] <jookiyaya> why is it that when i play the out.mkv it doesn't play right away [13:10:30 CET] <jookiyaya> is that have to do with slower seek [13:24:52 CET] <hyponic> I am restreaming a stream using ffmpeg but the source streams seems to have a quick drop every few minutes. i have script that respawns the connection but the problem is that the clients disconnect. is there a way to get ffmpeg to fill up the gap or keep the client connection while waiting to respawn? the respawn time is about half a second. [13:24:56 CET] <hyponic> anyone? [13:28:42 CET] <Carlrobertoh> How could I listen incoming ffmpeg video in VLC? Right now I can play outcoming stream by this command ffplay -rtsp_flags listen -i rtsp://127.0.0.1:8554/live.sdp [13:48:58 CET] <Carlrobertoh> anyone? [14:58:47 CET] <Fyr> what, JEEB, did anybody care about the delay lag? [15:27:39 CET] <galex-713> TD-Linux: hi, re [15:27:45 CET] <galex-713> Sorry, I felt asleep yesterday [15:27:51 CET] <galex-713> So here some stats I did: https://paste.debian.net/412782/ [15:28:18 CET] <galex-713> Also Id like to know& is there a way to calculate the average bitrate of an audio stream using vbr? [15:29:56 CET] <c_14> size/length [15:29:58 CET] <retard> divide filesize by length [15:30:26 CET] <galex-713> oh yeah obsviously x) [15:30:54 CET] <J_Darnley> I don't know what input you are using but please make sure it does not have an embedded cover image [15:31:02 CET] <J_Darnley> ffmpeg likes to copy those. [15:31:10 CET] <galex-713> it doesnt [15:31:20 CET] <galex-713> Oh, wait [15:31:24 CET] <J_Darnley> good [15:31:34 CET] <J_Darnley> (actually worse, ffmpeg will reencode them to png!) [15:31:59 CET] <galex-713> (waaat? why?) [15:32:20 CET] <J_Darnley> Because it is a "video stream" st ffmpeg instead of a binary attachment [15:32:30 CET] <J_Darnley> *to ffmpeg [15:32:41 CET] <galex-713> Heres duration is added: https://paste.debian.net/412784/ [15:33:08 CET] <galex-713> J_Darnley: Oh, you mean like a one-frame video input? [15:33:13 CET] <J_Darnley> yes [15:33:14 CET] <galex-713> So why png and why not jpeg? [15:33:26 CET] <galex-713> I thought jpeg was more near to what video encoders do than png [15:33:33 CET] <J_Darnley> perhaps png comes first in some list of supported formats [15:33:47 CET] <galex-713> thats a non-sense& [15:33:56 CET] <galex-713> Noone did report a bug for that? [15:35:57 CET] <galex-713> Also, is there a way to know the size of a stream itself, instead of file size, so it also works without having to creating a temporary demultiplexed file and make sure theres no cover image, etc.? [15:36:56 CET] <J_Darnley> -vn would stop the cover from being copied. [15:37:11 CET] <J_Darnley> and I think ffmpeg prints the size of audio and video streams [15:37:19 CET] <mkj3729> Is it possible to enforce the usage of a specific encoder in ffserver? [15:37:23 CET] <J_Darnley> ... when its finished [15:37:59 CET] <J_Darnley> mkj3729: yes in the sttings file I think [15:38:28 CET] <Carlrobertoh> How could I listen incoming ffmpeg video in VLC? Right now I can play outcoming stream by this command ffplay -rtsp_flags listen -i rtsp://127.0.0.1:8554/live.sdp [15:39:24 CET] <mkj3729> I tried to stream h264 in mpeg-ts using the nvenc encoder, but ffmpeg always falls back to libx264 [15:39:40 CET] <J_Darnley> open the input in vlc, obviously! [15:40:50 CET] <Carlrobertoh> VLC could not connect to "127.0.0.1:8554". [15:41:04 CET] <J_Darnley> Isn't that the output? [15:41:31 CET] <Carlrobertoh> how could i open the input ? [15:42:09 CET] <furq> galex-713: mediainfo will show you the audio stream bitrate [15:42:13 CET] <J_Darnley> By opening it in vlc! [15:42:16 CET] <furq> ffprobe apparently isn't smart enough [15:42:25 CET] <J_Darnley> What's not to understand about that? [15:43:19 CET] <Carlrobertoh> Media->Open network stream and url ? [15:43:42 CET] <Carlrobertoh> also i used vlc rtsp://127.0.0.1:8554/live.sdp [15:43:46 CET] <Carlrobertoh> still nothing [15:45:59 CET] <Carlrobertoh> J_Darnley: Connection failed: VLC could not connect to "127.0.0.1:8554". Your input can't be opened: VLC is unable to open the MRL 'rtsp://127.0.0.1:8554/live.sdp'. [16:03:57 CET] <galex-713> J_Darnley: so why ffmpeg does that and why wasnt it fixed? [16:07:26 CET] <Carlrobertoh> What are the reasons for quality drop ? I mean I am streaming a video from one host to another and the quality is dropping [16:12:23 CET] <durandal_1707> trascoding? [16:14:16 CET] <Carlrobertoh> right now i've set encoding options to: bit_rate 400k, time_base.num 1, time_base.den = 25, gop_size 10, max_b_frame 1, pix_fmt AV_PIX_FMT_YUV420P [16:18:01 CET] <atomnuker> Fyr: yes, the encoder supports VBR, just use -q:a 0.0-1.0 instead of -b:a 128k [16:18:34 CET] <Fyr> it's time to make another comparison! [16:18:36 CET] <Carlrobertoh> -q stands for ? [16:19:27 CET] <Fyr> unfortunately, ffmpeg -h encoder=aac says nothing. [16:19:44 CET] <J_Darnley> Because it's a global option! [16:20:00 CET] <J_Darnley> You may think of it as quality [16:20:31 CET] <J_Darnley> Carlrobertoh: No fucking wonder it looks like shit! 400k and gop size 10? [16:21:19 CET] <Fyr> atomnuker, what is the range of the -q:a parameter? [16:21:46 CET] <Carlrobertoh> J_Darnley, what should it be? [16:22:01 CET] <J_Darnley> 250 would be x264's default [16:22:41 CET] <Carlrobertoh> 250k ? [16:22:52 CET] <J_Darnley> oh bitrate you mean? [16:22:52 CET] <Carlrobertoh> i'm using MPEG2VIDEO [16:22:53 CET] <J_Darnley> no [16:22:59 CET] <J_Darnley> oh even worse [16:24:06 CET] <Carlrobertoh> when i capture the video on disk, then it is good [16:24:13 CET] <Carlrobertoh> but when i stream it, then it looks like shit [16:25:45 CET] <dsl42> cant you just stream a copy? no encoding, i mean [16:25:56 CET] <Fyr> atomnuker, does it mean that the range is from 0.0 to 1.0? why is it different from that of libfdk_aac, which is 1-5? [16:26:40 CET] <Carlrobertoh> i want it in real time [16:28:21 CET] <furq> Fyr: why does lame go from 0 to 9? why does flac go from 8 to 1? why does x264 go from 0 to 51? [16:29:38 CET] <durandal_1707> flac? [16:29:48 CET] <Fyr> because the developers want to cause pain in the ass of a user. [16:30:00 CET] <dsl42> B-) [16:30:05 CET] <furq> which user [16:30:18 CET] <Fyr> furq, what is the range of the native FFMPEG AAC encoder? [16:30:24 CET] <furq> don't ask me [16:30:27 CET] <Carlrobertoh> damn, i cant figure out why the quality gets fd up [16:30:38 CET] <furq> i was told not to use it for vbr [16:30:56 CET] <Jhokkar> Are you streaming over wifi? [16:30:59 CET] <furq> also does fdk even have q:a mapped [16:31:04 CET] <furq> last time i used it it was -vbr [16:31:06 CET] <Carlrobertoh> lan [16:31:21 CET] <Carlrobertoh> but yes [16:31:23 CET] <dsl42> Carlrobertoh, you need mpeg2? i would always use x264 if possible [16:31:43 CET] <Carlrobertoh> honestly i dont need it [16:33:04 CET] <furq> 15:26:40 ( Carlrobertoh) i want it in real time [16:33:07 CET] <Carlrobertoh> AV_CODEC_ID_H264 instead of AV_CODEC_ID_MPEG2VIDEO [16:33:09 CET] <furq> how does this prevent you from copying the stream [16:33:54 CET] <Carlrobertoh> I dunno, right now I have able to record packets and send it to web using rtsp protocol [16:34:13 CET] <Carlrobertoh> code acts as a client [16:34:21 CET] <dsl42> ah i thought huge filesize and less bandwidth [16:34:32 CET] <Carlrobertoh> and it can be listened ffplay -rtsp_flags listen -i rtsp://127.0.0.1:8554/live.sdp [16:36:39 CET] <maco1717> hi, im trying to output to a window "a command" that takes to streams and overlays them sort of picture in picture, I have managed to do the PIP to record to a file, ive looked around and apprently the way to put this to a windows would be namepipe to ffplay? this is the command [16:36:50 CET] <maco1717> ./ffmpeg -i 'rtsp://' -i 'rtsp://' -filter_complex "[1]scale=iw/2:ih/2 [pip]; [0][pip] overlay_w-10:10" pipe:1 Š ./ffplay -i pipe:1 [16:36:59 CET] <maco1717> i get unable to find a suitable output format for pipe:1 pipe:1: invalid argument pipe:: invalid data found when procesin input [16:49:29 CET] <atomnuker> Fyr: initially, the -q:v or -q:a argument was mapped to the MPEG2 VBR quality setting (which ranges from 0-31) [16:49:38 CET] <atomnuker> but every encoder has been doing it's own thing with it [16:50:00 CET] <Fyr> I would copy everything from lame. =) [16:50:23 CET] <Fyr> atomnuker, so what is the range for the native AAC encoder? [16:53:59 CET] <basisbit> anyone here who could maybe spare a few minutes and help me at an issue with sws_scale which I get now that I tried to get the open source ultrastar deluxe karaoke game to work with ffmpeg 3.0? I get a swscale-4!sws_getCachedContext unhandled exception when clling sws_scale now after changing from ffmpeg 2.8 to 3.0 here: https://github.com/UltraStar-Deluxe/USDX/blob/master/src/media/UVideo.pas#L… [16:55:38 CET] <rainabba> I've got 2 BlackMagic DeckLink 4K Pro cards installed and can't figure out how to target a particular one with ffmpeg. Can anyone help? listdevices shows them both, but with the same name: [decklink @ 000002253401bf00] Blackmagic DeckLink devices: [decklink @ 000002253401bf00] 'DeckLink 4K Pro' Last message repeated 1 times [16:56:35 CET] <basisbit> already am struggling with that issue for lots of days :-( I checked the sws_getContext creation and it does not throw any error or similar. [16:57:28 CET] <kepstin> Fyr: looks like the native ffmpeg aac encoder probably uses the same range for -q as the faac encoder, so around 10-500? I have no idea if it's actually hooked up or works, last i heard, the vbr mode was still experimental. [16:58:11 CET] <atomnuker> Fyr: it's from 0 to around 25, depending on the input [16:58:32 CET] <Fyr> ok, thanks. [16:58:47 CET] <Fyr> I have a comparison to perform. =) [16:59:32 CET] <atomnuker> Fyr: though it's not linear e.g. 2 won't have twice the bitrate of 1 [16:59:52 CET] <Fyr> atomnuker, where do I read about it? [17:00:10 CET] <Fyr> libfdk_aac, libfaac - they all have documentation. [17:00:19 CET] <atomnuker> so usually for a 128kbps level you need to use -q:a 0.8 [17:00:35 CET] <atomnuker> there's doc/encoders.texi [17:03:52 CET] <Fyr> atomnuker, doc/encoders.texi says to use "used to set the quality value used by libfaac. A reasonable range for the option value in QP units is [10-500]" [17:05:43 CET] <furq> https://github.com/FFmpeg/FFmpeg/blob/master/doc/encoders.texi#L46 [17:07:45 CET] <furq> there is no global_quality item in that subsection [17:08:09 CET] <Fyr> ok, now I'm confused more. [17:50:58 CET] <atomnuker> nothing confusing, it's just that -q:a sets global_quality inside the main avctx struture [18:13:48 CET] <maco1717> hi, im trying to output to a window "a command" that takes two streams, from an ipcam on another stream, and overlays them, like video in video or sort of picture in picture, I have managed to do the PIP to record to a file, Ive looked around and apprently the way to put this to a windows would be namepipe to ffplay? this is the command from this page http://www.oodlestechnologies.com/blogs/PICTURE-IN-PICTURE-effect-using-FFM… [18:14:08 CET] <maco1717> command: ./ffmpeg -i 'rtsp://' -i 'rtsp://' -filter_complex "[1]scale=iw/2:ih/2 [pip]; [0][pip] overlay_w-10:10" pipe:1 Š ./ffplay -i pipe:1 [18:14:15 CET] <maco1717> I get unable to find a suitable output format for pipe:1 pipe:1: invalid argument pipe:: invalid data found when procesin input My question is how to "output to screen" rather than to a file... I found piping to fplay but not shure if that'be possible and if it would be the best solution as I understand fplay is more for Dev. Any recommendations? [18:16:20 CET] <c_14> add -f nut before the first pipe:1 and change the second pipe:1 to pipe:0 [18:16:24 CET] <durandal_1707> error says it all, [18:43:34 CET] <andrey_utkin> is it possible to send commands to filter-sources like "color" via "sendcmd"? seems not. [18:47:29 CET] <durandal_1707> andrey_utkin: isn't it documented? [18:50:15 CET] <andrey_utkin> durandal_1707: it is only said that "sendcmd" must be inserted between two video filters. I _guess_ commands are supposed to be transmitted towards output, just like frames, and not both ways, in which case what I want (to reinint colorsrc) won't work. Is that correct or wrong? [18:50:23 CET] <andrey_utkin> http://ffmpeg.org/ffmpeg-filters.html#sendcmd_002c-asendcmd the doc section [18:52:02 CET] <Fyr> atomnuker, could you add to the wiki the range of -q:a and corresponding quality/bitrate like was done for the other AAC encoders? [18:52:11 CET] <durandal_1707> andrey_utkin: try it, use sendcmd immediately after color source [18:52:40 CET] <andrey_utkin> ok will try [18:52:42 CET] <andrey_utkin> thanks durandal_1707 [18:58:30 CET] <andrey_utkin> sendcmd reaches "upstream" targets [19:04:29 CET] <maco1717> thank that worked for me! [19:04:34 CET] <maco1717> thanks* [19:09:54 CET] <Duality> what happens when i run ffmpeg without -framerate ? [19:10:02 CET] <Duality> does it run at the max it can ? [19:10:48 CET] <Fyr> it takes it from the input file. [19:11:09 CET] <Fyr> or, if it's broken somehow, it sets something by default. [19:11:25 CET] <Duality> Fyr: ok, but I am screen capturing [19:15:02 CET] <Fyr> Duality, might I suggest to run a test and analyze the output file? [19:15:29 CET] <Duality> good idea! :) [19:15:41 CET] <Fyr> 10 fps, my guess. [19:20:27 CET] <andrey_utkin> "Filtergraph syntax" doc lacks explanation how to set filter instance name, all existing references to filter instance names are abstract or use default form "filtername_parsed_N" [19:20:52 CET] <andrey_utkin> is it impossible to set filter instance names in filtergraph syntax? [19:23:24 CET] <voip_> hello guys [19:25:47 CET] <durandal_1707> andrey_utkin: isnit filtername_n? [19:26:42 CET] <Duality> Fyr: ffmpeg output says that the fps get less and less but is now stabalizing around 33 fps :) but it's using all my cores! :D [19:28:55 CET] <andrey_utkin> according to libavfilter/graphparser.c:104, it is not customizable and is "Parsed_%s_%d", filt_name, index. Unless avfilter_graph_alloc_filter() is used directly [19:31:02 CET] <voip_> I for taking leave rtmp stream and converting to MPEG2 ai am using next commands, but on output i have variable stream speed. I need 4-5 mb on output. How to fix that . My commands: -f flv -i "$INPUT" -vcodec mpeg2video -pix_fmt yuv420p -me_method epzs -threads 4 -r 29.97 -g 45 -bf 2 -trellis 2 -cmp [19:31:03 CET] <voip_> 2 -subcmp 2 -s 720x480 -b 5000k -bt 350k -acodec ac3 -ab 192k -ar 44100 -async 1 -y -f mpegts "$OUTPUT" [19:39:01 CET] <ethe> How do I limit the rate of decoding? [19:39:19 CET] <JEEB> the only hack for that is -re before -i [19:39:28 CET] <JEEB> which limits you to realtime decoding (kind of) [19:40:03 CET] <ethe> ah thanks [19:48:55 CET] <Fyr> JEEB, how much would you bet that the delay bug will be fixed within the next three years? [19:49:48 CET] <JEEB> I think a lot of people just won't care because API users already get it right. but you're definitely not the first one who WTF'd at the WAV output [20:17:39 CET] <Guest66065> Hello all, I run a video site, but watermark logo still in different sizes in every video with different resolution. My question: is there a way to scale watermark image in every video by some kind of percentage to have the same size of watermark whatever the resolution of the video. [20:18:19 CET] <Fyr> to write a wrapper script? [20:18:52 CET] <kepstin> Guest66065: sure, using the 'scale2ref' filter to adjust the size of the overlay image. [20:19:35 CET] <kepstin> can use expressions for the width/height to do arbitrary calculations based on the video size [20:20:47 CET] <Guest66065> kepstin : do you have an example of use?= [20:21:23 CET] <kepstin> Guest66065: not really, but it shouldn't be hard to figure out from the documentation of the scale and scale2ref filters. [20:36:40 CET] <voip_> I am taking live rtmp stream and converting to MPEG2 [20:36:40 CET] <voip_> I need 4-5 Mb on output, but my speed on output is variable 2.5-3.5 [20:36:40 CET] <voip_> My commands: [20:36:40 CET] <voip_> -f flv -i "$INPUT" -vcodec mpeg2video -pix_fmt yuv420p -me_method epzs -threads 4 -r 29.97 -g 45 -bf 2 -trellis 2 -cmp [20:36:40 CET] <voip_> 2 -subcmp 2 -s 720x480 -b 4000k -bt 350k -acodec ac3 -ab 192k -ar 44100 -async 1 -y -f mpegts [20:36:42 CET] <voip_> How should i change commands for having constant bitrate on output [20:51:07 CET] <voip_> any help, guys ? [20:52:50 CET] <DHE> -minrate and -maxrate [20:53:06 CET] <DHE> set them to the same value, 4000k along with the current settings [21:09:14 CET] <voip_> DHE, thank you thats works! One more question . In my commands i have -b 4000k -bt 350k whats means those commands ? [21:11:40 CET] <DHE> bitrate tolerance. how much it's allowed to deviate [21:12:15 CET] <DHE> it's usually best to give ffmpeg as much to work with as you can. strict CBR isn't usually a good idea [21:17:36 CET] <voip_> so, better if i leave ( -b 4000k -bt 350k ) in commands or delete them ? [21:19:48 CET] <DHE> leave them [21:24:00 CET] <voip_> thank you! [21:44:33 CET] <godofgrunts> I'm trying to normalize video lengths (avoiding spoilers this way) and I want to concatenate two videos to a certain duration. For example, first video is 8 minutes long and the second video is 30 minutes long. All videos will be normalized to 30 minutes. So I want to concatenate the 8 min video and the 30 min video but I only want to use the firs [21:44:33 CET] <godofgrunts> t 22 minutes of the video. [21:46:57 CET] <godofgrunts> More simply x = 8 y = 30 x+y=z [ concatenate x + (y-z) ] [21:47:16 CET] <godofgrunts> nope that's wrong [21:47:58 CET] <godofgrunts> x = 8 y = 30 (x+y)-30=z [ concatenate x + (y-z) ] [21:48:46 CET] <godofgrunts> lol or x = 8 y = 30 [ concatenate x + (y-x) ] [22:13:31 CET] <J_Darnley> sounds impossible with ffmpeg [22:22:57 CET] <flux> wouldn't it be nice if ffmpeg had host-endian pixel formats.. [22:23:52 CET] <J_Darnley> I'm pretty sure it does. [22:24:19 CET] <ubitux> godofgrunts: concat+trim filter? or concat demuxer + -t option if inputs are compatibles [22:26:28 CET] <flux> j_darnley, oh :-). now I looked past the obvious part in pixfmt, and indeed it chooses some pixel format names by AV_HAVE_BIGENDIAN, thank you :) [22:26:42 CET] <jookiyaya> i cannot cut the 3 seconds of a mkv video using ffmpeg [22:27:20 CET] <godofgrunts> @ubitux they are compatible. How do I only apply -t to the second input? [22:27:55 CET] <ubitux> you do the calculation yourself and set the -t for the total duration of the output [22:28:26 CET] <ubitux> but your constraint is that final duration unless i'm mistaken, so nothing to compute [22:28:51 CET] <jookiyaya> ffmpeg64 -ss 00:03 -i 5.mkv -t 60:00 -c copy R:\5.mkv" [22:29:12 CET] <furq> jookiyaya: you can't do frame-accurate cuts with -c copy unless you cut on a keyframe [22:29:27 CET] <jookiyaya> furq okay, then what option do i have [22:29:29 CET] <godofgrunts> @ubitux one second [22:29:31 CET] <furq> cut on a keyframe? [22:29:33 CET] <ubitux> jookiyaya: you're extracting 57sec starting at t=3s [22:29:46 CET] <kepstin> godofgrunts: should be trivial to do, just use the -t output option or a trim filter after the concat. [22:29:54 CET] <jookiyaya> furq what is the command to do that [22:30:41 CET] <ubitux> kepstin: if he's using a concat demuxer, he doesn't want to transcode, and so won't be able to use a trim filter, -t will do [22:30:48 CET] <furq> there isn't one [22:30:50 CET] <godofgrunts> @ubitux @kepstin maybe like ffmpeg -i "concat:input1.mp4|input2.mp4" -c copy -t 00:30:00 output.mp4 ? [22:30:58 CET] <ubitux> godofgrunts: concat demuxer, not protocol [22:31:04 CET] <furq> -ss will start at the closest keyframe unless you reencode [22:31:21 CET] <godofgrunts> I don't need to start at a certain key frame though [22:31:33 CET] <godofgrunts> like right now input1 and input 2 are the same size and codec [22:31:35 CET] <ubitux> there are 3 concats, concat protocol (shit), concat demuxer (can't transcode with it, input matching constraints), and concat filter (accurate, transcode) [22:31:47 CET] <ubitux> look up the concat demuxer documentation [22:32:18 CET] <godofgrunts> I did [22:32:20 CET] <ubitux> then ffmpeg -f concat -i ... -c copy -t 30:00 ... [22:32:25 CET] <godofgrunts> ffmpeg -i "concat:input1.mpg|input2.mpg|input3.mpg" -c copy output.mpg is the example they give [22:32:31 CET] <ubitux> no [22:32:31 CET] <godofgrunts> okay yea that's what I asked [22:32:34 CET] <ubitux> this is the concat protocol [22:32:51 CET] <godofgrunts> oh [22:32:53 CET] <godofgrunts> Yeah you'e right [22:32:56 CET] <jookiyaya> furq with .wmv i can cut exact to a second [22:33:02 CET] <ubitux> godofgrunts: http://ffmpeg.org/ffmpeg-formats.html#concat-1 [22:33:03 CET] <jookiyaya> but i cannot seem to do this with .mkv [22:33:30 CET] <ubitux> godofgrunts: heh, you can even set the duration here, but in your case you actually don't [22:34:32 CET] <jookiyaya> what is the switch to overwrite automatically [22:35:03 CET] <godofgrunts> So am I supposed to put everything into one file? Like /path/file1.mp4 /path/file2.mp4 duration 00:30:00 ? [22:35:21 CET] <godofgrunts> Because I do need the duration [22:36:15 CET] <godofgrunts> Oh wait, do I have to manually set the duration of the file? That kind of sucks [22:36:27 CET] <jookiyaya> anybody know the switch to overwrite file automatically, without confirmation [22:36:48 CET] <furq> -y [22:37:36 CET] <jookiyaya> thanks [22:38:54 CET] <jookiyaya> i just did ffmpeg64 -ss 00:01 to 00:09 -i 6x.mkv -c copy R:\6.mkv -y and nothing made a difference [22:39:18 CET] <jookiyaya> i don't understand [22:40:12 CET] <kepstin> jookiyaya: if you're using -c copy, the accuracy you get with -ss depends entirely on where the keyframes are located in the input file. If you want an exact cut, you have to re-encode. [22:41:27 CET] <jookiyaya> kepstin i had to do -ss 00:10 to make a difference, so i cannot change anythign lower than 10 seconds [22:42:06 CET] <kepstin> jookiyaya: that means that your input file probably has keyframes every 10 seconds or so [22:42:30 CET] <jookiyaya> kepstin is this mkv thing? [22:42:30 CET] <kepstin> so with that input file, you'll get ~10s accuracy with copy mode. [22:42:45 CET] <kepstin> jookiyaya: no, depends on the settings used with the video encode. [22:43:07 CET] <jookiyaya> kepstin then explain why if i am cutting end of the video, then i can get precise second [22:43:22 CET] <jookiyaya> only beginning of the video, i cannot do precise [22:43:33 CET] <kepstin> jookiyaya: because you can only start decoding a video at a keyframe. you can stop decoding anywhere [22:44:19 CET] <jookiyaya> so ending cut is always be precise despite what kind of encoding was used? [22:44:29 CET] <kepstin> jookiyaya: i think so, yeah. [22:44:55 CET] <jookiyaya> then how come with wmv i can cut to the precise (beginning of the video) [22:45:46 CET] <kepstin> jookiyaya: you can't - you said it only worked to second accuracy. That means the wmv file had a keyframe every second. [22:46:03 CET] <kepstin> again, just a setting that the person who encoded that file picked [22:46:32 CET] <jookiyaya> i never heard of such a video encoding setting [22:47:53 CET] <kepstin> jookiyaya: if you're encoding a video with ffmpeg, you can set the keyframe interval with the '-g' option. Most encoders let you set it. [22:48:39 CET] <jookiyaya> we know the advantage of choose low number keyframe setting, but what is the advantage [22:48:45 CET] <jookiyaya> choosing* [22:49:00 CET] <kepstin> having the keyframes farther apart generally makes a modern video codec more efficient, since it can use more predicted frames. [22:49:19 CET] <jookiyaya> farther apart = higher number? [22:50:08 CET] <kepstin> not sure what you mean. farther apart means that there's one key frame, then lots of non-keyframes before the next keyframe. [22:50:11 CET] <pzich> fewer overall, spaced further apart [22:51:19 CET] <jookiyaya> kepstin That means the wmv file had a keyframe every second. so what is the advantage (for example of using 10 second per keyframe) vs (1 second per keyframe) [22:51:33 CET] <furq> 21:49:00 ( kepstin) having the keyframes farther apart generally makes a modern video codec more efficient, since it can use more predicted frames. [22:52:01 CET] <jookiyaya> farther apart meaning higher keyframe number? [22:52:35 CET] <kepstin> jookiyaya: i don't know what you mean by "higher keyframe number" [22:52:39 CET] <J_Darnley> Yes! More frames between each one! [22:52:42 CET] <kepstin> we just went over what father apart means [22:52:43 CET] <jookiyaya> 10 is higher number than 1 [22:52:53 CET] <furq> i need to go and lie down [22:53:26 CET] <kepstin> having 1 keyframe then 10 non-keyframes then 1 keyframe is father apart then 1 keyframe then 5 non-keyframes then 1 keyframe [22:54:03 CET] <jookiyaya> then why not use like 50 keyframe per second (although it would suck to end videos) [22:54:13 CET] <jookiyaya> end = edit [22:54:22 CET] <J_Darnley> Because that is an utter waste of bits [22:54:28 CET] <furq> my mind is crying [22:54:51 CET] <kepstin> jookiyaya: having every frame be a keyframe (like 50 keyframes per second) makes editing video really easy, but the video will be really, really big since keyframes are big. [22:56:13 CET] <jookiyaya> sorry my bad i had it backward [22:56:34 CET] <jookiyaya> i meant .1 keyframe per second [22:56:53 CET] <kepstin> jookiyaya: your mkv file is like that - 1 keyframe every 10 seconds (=0.1 keyframe per second) [22:57:00 CET] <kepstin> it's probably a fairly common value [22:57:02 CET] <jookiyaya> right [22:57:23 CET] <jookiyaya> why not make it .01 keyframe per second then [22:57:47 CET] <kepstin> jookiyaya: if the keyframes are too far apart, then seeking is really slow, since you can only seek to keyframes. [22:57:53 CET] <jookiyaya> i see [22:57:58 CET] <kepstin> so it's a balance. [22:58:11 CET] <jookiyaya> and editing is hard too [22:58:41 CET] <kepstin> editing's not too bad, if you're re-encoding. it's just that when you use 'copy' mode, the copy has to start at a keyframe. [22:59:13 CET] <jookiyaya> how do i tell what keyframe was used for any video [22:59:29 CET] <kepstin> (when you use -ss while re-encoding, it decodes starting at the previous keyframe, then throws out the decoded frames until it's at the exact right spot, then starts encoding there) [23:00:05 CET] <godofgrunts> @kepstin so when I try to concat these videos I get spammed with 'Non-monotonous DTS in output stream 0:0' and the video only plays until the beginning of the second video [23:00:13 CET] <kepstin> jookiyaya: you need to use a video analysis tool to tell. It's not always a constant interval - e.g. x264 will sometimes add extra keyframes if it thinks it needs to. [23:00:36 CET] <kepstin> jookiyaya: "ffprobe -show_frames" includes a field which says whether each frame is a keyframe or not, for example. [23:02:15 CET] <jookiyaya> wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=1 / tu-inter-depth=1 / me=3 / subme=3 / merange=57 / rect / no-amp / max-merge=3 / temporal-mvp / no-early-skip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=250 / min-keyint=25 / scenecut=40 [23:02:15 CET] <jookiyaya> / rc-lookahead=25 / lookahead-slices=4 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=4 / limit-refs=3 / limit-modes / weightp / no-weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=4 / psy-rd=2.00 / rdoq-level=2 / psy-rdoq=1.00 / signhide / deblock / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=20.0 / qcomp=0.60 / qpmin=0 / [23:02:15 CET] <jookiyaya> qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30 [23:02:27 CET] <jookiyaya> does it show in here? [23:02:50 CET] <kepstin> jookiyaya: that's a bit of a big paste for irc... [23:02:53 CET] <J_Darnley> keyint=250 / min-keyint=25 [23:03:15 CET] <jookiyaya> darnley there 2 numbers, which one [23:03:23 CET] <kepstin> that means that x264 will put at least one keyframe every 250 frames, but no more often than one every 25 frames [23:03:25 CET] <J_Darnley> fucking read it! [23:04:13 CET] <furq> kepstin: that's x265 [23:04:24 CET] <furq> although obviously the same applies for x264 [23:04:25 CET] <jookiyaya> furq how did you know? [23:04:26 CET] <kepstin> ok, sure, but it's almost the same thing [23:04:38 CET] <jookiyaya> furq how did you know that was 265 [23:05:02 CET] <furq> i guess i must be psychic [23:05:05 CET] <kepstin> jookiyaya: because he's psychic. [23:05:09 CET] <furq> see [23:05:11 CET] <jookiyaya> serious, how did you know that [23:05:12 CET] <furq> i knew you were going to say that [23:05:37 CET] <kepstin> jookiyaya: by looking at the options, then going, "huh, those look like options for x265" [23:05:49 CET] <furq> that's completely wrong. i didn't say "huh" [23:06:00 CET] <kepstin> ok. but I would have said 'huh' [23:06:03 CET] <kepstin> :) [23:06:19 CET] <jookiyaya> so for keyint=250 / min-keyint=25 video, how many seconds increments can i cut off using -ss [23:06:24 CET] <furq> i said "jiminy jillickers" [23:06:41 CET] <kepstin> jookiyaya: you can't tell without analyzing the video to know where the keyframes are. [23:07:14 CET] <kepstin> jookiyaya: it'll be variable over the course of the video. [23:07:34 CET] <godofgrunts> @kepstin "Your paste cannot be larger than 64 kb. Sorry." lol [23:08:06 CET] <kepstin> godofgrunts: ok, just the full command-line then? [23:08:51 CET] <furq> or use a better pastebin [23:09:19 CET] <godofgrunts> @kepstin I'm going to cut out a lot of reduant parts since the error message is the same over and over [23:09:23 CET] <jookiyaya> and also if i do -ss 00:10 -i ouput.mkv output.mkv video plays fine at least but if i do -i ouput.mkv -ss 00:10 the output.mkv video plays weird [23:10:04 CET] <kepstin> jookiyaya: don't use -ss as an output option when using -c copy. [23:10:29 CET] <kepstin> if you do that, the video won't start on a keyframe, so it won't decode properly. [23:10:54 CET] <jookiyaya> right, why even have such an option to do that [23:11:01 CET] <jookiyaya> ffmpeg should remove that option [23:11:14 CET] <godofgrunts> @kepstin http://pastebin.com/raw/HMzxSFfB [23:11:45 CET] <furq> why are there trains when you can get hit by them? we should just walk everywhere [23:11:54 CET] <godofgrunts> Now where you see the Non-monotonous DTS just imagine about a million more of them [23:16:22 CET] <kepstin> godofgrunts: huh, not sure how to handle that. if you know the input videos are both constant-framerate, you could try using the -r input option to overwrite the timestamps, i guess. [23:16:42 CET] <godofgrunts> Okay I'll try that [23:17:17 CET] <kepstin> and the other option would be to actually re-encode the videos (and use e.g. the concat filter), so you can tweak the timestamps in the filter chain. [23:19:40 CET] <godofgrunts> @kepstin yeah I'd really like to avoid that for obvious reasons [23:19:44 CET] <godofgrunts> -r didn't work either [23:19:58 CET] <kepstin> you could also just output to a format that supports discontinuous pts, like mpeg-ts, rather than use mp4 :) [23:20:09 CET] <kepstin> (then you're relying on the player to work around the issue tho) [23:20:26 CET] <kepstin> did you use -r as an input option? (before the -i?) [23:23:48 CET] <godofgrunts> @kepstin yeah ffmpeg -r 60 -f concat -i mylist.txt -c copy ./finished/crispy.mp4 [23:24:08 CET] <kepstin> but yeah, the way ffmpeg handles timestamps in stream copy mode is kinda problematic, imo. there might be some other tool you can try - I think MP4Box can do concatenation? [23:24:33 CET] <godofgrunts> @kepstin that's annoying to have to use a different tool, but I'll give it a try [23:37:01 CET] <beeep1> in order to merge 2 files, i know you have to use same video/audio encoder, same resolution, but does it have to have exact same settings [23:43:29 CET] <kepstin> beeep1: by merge you mean concatenate? [23:43:39 CET] <beeep1> append [23:44:03 CET] <kepstin> some variation is acceptable; different bitrate/quality is ok, different fps is usually ok depending on container. [23:44:57 CET] <beeep1> what about audio bitrate: what if 1.mkv is using 128kbps and 2.mkv is using 160kbps but everything else is same [23:46:03 CET] <kepstin> beeep1: hmm, audio appending is tricker. you can't do a "gapless" append - there'll be a bit of silence added. [23:46:12 CET] <kepstin> but different bitrates of the same codec is probably usually ok [23:47:15 CET] <beeep1> can i use 2 different source and reencode to 1 output.mkv video [23:47:18 CET] <hyponic> I am restreaming a stream using ffmpeg but the source streams seems to have a quick drop every few minutes. i have script that respawns the connection but the problem is that the clients disconnect. is there a way to get ffmpeg to fill up the gap or keep the client connection while waiting to respawn? the respawn time is about half a second. [23:48:19 CET] <beeep1> can i use 2 different source and reencode to 1 output.mkv video: for example vid1.mkv = 1 hour vid2.mkv = 30 min = output.mkv = 90min [23:48:46 CET] <beeep1> sorry but vid2 is not vid2.mkv it's vid2.wmv [23:49:19 CET] <beeep1> with totally different container/video/audio codec [23:49:21 CET] <kepstin> beeep1: sure. if they're different video codecs in the source files, you'll have to use the "concat" filter and re-encode the output. [23:50:19 CET] <kepstin> beeep1: could be as simple as "ffmpeg -i vid1.mkv -i vid2.wmv -filter_complex concat=n=2:a=1:v=1 out.mkv" [23:50:36 CET] <kepstin> haven't tested that, but some variation on it would probably work [23:50:46 CET] <beeep1> i want to renencode [00:00:00 CET] --- Tue Mar 8 2016

1 0

ffmpeg-devel.log.20160306
by burek 07 Mar '16

07 Mar '16

[00:06:37 CET] <jkqxz> To answer myself, it just means that num_ref_idx_lN_active_minus1 > 0. Immediately after an IDR frame there is only one reference picture present, so you can't fill the RefPicListNs. Maybe the message shouldn't be at error level. [00:08:05 CET] <nevcairiel> streams that rely on the default ref frame behavior are rather odd [00:08:19 CET] <nevcairiel> most do not in fact output such warnigs [00:14:03 CET] <jkqxz> You expect that the frame immediately after an IDR frame in such a stream will contain ref_pic_list_modification which fills the other slots? (With the same frame, presumably, since there's only one.) [00:14:35 CET] <jkqxz> Or maybe just noone sets it in the PPS. [00:20:03 CET] <jkqxz> Anyway, it seems the real answer to my problem is that the Intel driver does not support weighted_bipred_idc == 2, so if you set it your B frames will all be subtly wrong (presumably assumes 0). Thanks for documenting that, Intel. [01:15:55 CET] <nevcairiel> for encoding? [01:16:00 CET] <nevcairiel> i never noticed problems decoding [01:34:19 CET] <jkqxz> Yeah, encoding. They certainly couldn't omit it for decoding. [03:32:45 CET] <cone-701> ffmpeg 03Mark Harris 07master:238ddd6482d7: avformat/dump: Fix context/level for payload dump [06:37:18 CET] <Timothy_Gu> ethe: https://gist.github.com/TimothyGu/23ec15872465cd295444 [08:08:44 CET] <Zeranoe> I built the latest (1.17) Intel MFX after some minor tweaking. FFmpeg compiled fine, but when I try to use the h264_qsv encoder I get "Error retrieving encoding parameters." Digging a little deeper and it's failing at MFXVideoENCODE_GetVideoParam in qsvenc.c line 604. ret is -3 or "MFX_ERR_UNSUPPORTED" which intel documents as "undeveloped feature". [08:10:22 CET] <Zeranoe> I find it odd that 1.16 from lu-zero's mfx_dispatch [08:10:22 CET] <Zeranoe> works fine, but the newer version is "undeveloped". Does anyone have an idea what's going on here? Maybe nevcairiel? [10:52:12 CET] <cone-161> ffmpeg 03Muhammad Faiz 07master:7dd60a0b54ee: avfilter/avf_showcqt: remove CoeffsType [11:54:19 CET] <cone-161> ffmpeg 03Reimar Döffinger 07master:0a04c2885f02: aacenc: avoid double in quantize_bands. [12:21:39 CET] <cone-161> ffmpeg 03Michael Niedermayer 07master:40aeff5f0287: avformat/avienc: Remove unneeded seekable tests [12:36:25 CET] <cone-161> ffmpeg 03Reimar Döffinger 07master:5f5e6033cd98: bitstream.c: improve init_vlc error messages. [13:24:47 CET] <cone-161> ffmpeg 03Umair Khan 07master:7d6c264e0227: avcodec/alsdec: treat quant_cof as a signed value [13:55:30 CET] <cone-161> ffmpeg 03Kieran Kunhya 07master:247fe3e494ca: avcodec/cfhd: Fixes cfhd_odd.mov which has a resolution of 496x241 [13:57:02 CET] <Fyr> alright, let's wait a few years till somebody make it. [13:58:00 CET] <Fyr> all the video editors can do that, only ffmpeg determines itself as something different. [14:02:01 CET] <wm4> do what [14:02:55 CET] <JEEB> Fyr: trying to imply that FFmpeg is a video editor is kind of derp, not to mention that filters like that are most probably better off be done on hardware that actually specializes in graphics. FFmpeg's job is to get video decoded or encoded, and the further you go from that the closer you are to just being better off making something on top of FFmpeg [14:03:38 CET] <JEEB> wm4: he made that ticket :P [14:03:53 CET] <wm4> whatever "3D cube effect" is, it sounds useless [14:05:14 CET] <JEEB> but sure, since it's OSS if someone cares enough about it and produces a patch of good enough quality then libavfilter will have yet another funky filter [14:05:52 CET] <wm4> it's so special and high effort that I can't imagine that [14:05:52 CET] <JEEB> which I'm not even sure how you'd use because I'm pretty sure doing filtering on a "stitching point" of two clips is a PITA with libavfilter anyways [14:06:05 CET] <wm4> even if you get opengl support in lavfi, would you hardcode the cube? [14:08:58 CET] <JEEB> anyways, just saying that it most probably won't get closed as a ticket, but really it is out of the main scope of FFmpeg (and I do agree there's plenty of such stuff already in libavfilter et al) [14:09:55 CET] <JEEB> also talking of FFmpeg as a "video editor" is really funny in my opinion, even with just the intent of using it as a way of mocking the project [14:11:42 CET] <wm4> if only it had EDL capabilities or so (instead of the crazy concat shit) [14:12:24 CET] <JEEB> btw, as we're on the subject of libavfilter, does filter_complex let you do stuff like "if subtitle track exists in input, do something"? [14:12:31 CET] <JEEB> IIRC no [14:15:33 CET] <rcombs> JEEB: no but someone asked about a similar feature a while back [14:15:51 CET] <rcombs> and it's probably useful enough to be worth implementing but also would be work [14:15:56 CET] <JEEB> yeah [14:16:14 CET] <JEEB> and I f.ex. haven't even gotten properly looking into libavfilter madness yet [14:16:29 CET] <rcombs> like, I only recently added that to `-map` in ffmpeg_opt [14:16:37 CET] <JEEB> yeah, I noticed that [14:16:40 CET] <JEEB> quite useful [14:16:45 CET] <JEEB> except when you want to do hardsubbing :) [14:16:46 CET] <rcombs> well, maybe it could be easy if you did it in ffmpeg_filter.c in lazymode [14:16:52 CET] <JEEB> hmm [14:16:57 CET] <JEEB> hafta check that [14:17:02 CET] <JEEB> because lazymoodo best moodo amirite? [14:17:07 CET] <rcombs> do the same check as what I did for -map [14:17:13 CET] <J_Darnley> u r right [14:17:23 CET] <rcombs> and if the stream doesn't exist, make a fake one that never gets any packets [14:17:29 CET] <JEEB> yeah [14:17:42 CET] <rcombs> JEEB: oh also subtitle streams don't exist in lavfi yet [14:17:51 CET] <JEEB> uh [14:18:00 CET] <JEEB> then what is the input in lavfi for subtitle overlays? [14:18:06 CET] <rcombs> a filename [14:18:19 CET] <rcombs> something something ubitux something [14:18:21 CET] <JEEB> you can't overlay a dvd/dvbsub track!? [14:18:31 CET] <rcombs> that's the overlay filter [14:18:45 CET] <rcombs> ffmpeg.c contains a hack to convert bitmap subtitles to video streams for lavfi [14:18:46 CET] <JEEB> yeah, that's why I noted "subtitle overlays" since I remembered the overlay filter [14:18:53 CET] <JEEB> hah :D [14:18:58 CET] <JEEB> ffmpeg.c fug yeah [14:19:00 CET] <rcombs> it's bad [14:19:08 CET] <Daemon404> uh... the fuck [14:19:12 CET] <Daemon404> does anyone speak dutch? [14:19:22 CET] <rcombs> Daemon404: I think I know a guy, why? [14:19:24 CET] <Daemon404> someone sent me an email in dutch, about ffmpeg [14:19:31 CET] <Daemon404> and hls and some merge [14:19:47 CET] <JEEB> "English motherfucker, do you speak it?" [14:20:12 CET] <JEEB> probably caught your surname and thought you could habla dutch [14:20:37 CET] <J_Darnley> That's unusual. [14:20:46 CET] <Daemon404> i geuss my surname is dutch [14:20:50 CET] <Daemon404> but still. [14:20:56 CET] <J_Darnley> Most dutch speakers I've met speak good english [14:21:03 CET] <Daemon404> https://www.dropbox.com/s/dugd1xlv5scqbzm/wat.html?dl=0 [14:21:03 CET] <rcombs> JEEB: so it'd probably be relatively easy to do for bitmap subs since the sub2video hack is already within ffmpeg.c [14:21:07 CET] <ubitux> JEEB: the lavfi subtitles thing is a hack to extract eia subs, isn't it? [14:21:35 CET] <JEEB> rcombs: yeah - bitmap subs is what I was thinking of [14:21:36 CET] <Daemon404> email is the html file i linked [14:21:50 CET] <rcombs> JEEB: so yeah, you could totally lazymode that [14:23:04 CET] <J_Darnley> He's asking whether you could address a ticket someone filed [14:23:32 CET] <J_Darnley> He claims that the issue was created by a commit of yours [14:23:50 CET] <J_Darnley> oh no, he says someone else claims that [14:24:07 CET] <rcombs> Daemon404: turns out I indeed knew a guy [14:24:11 CET] <rcombs> Daemon404: "looking at your last name, I believe I can just talk Dutch with you" [14:24:16 CET] <Daemon404> ... [14:24:25 CET] <rcombs> JEEB: nice call [14:24:25 CET] <Daemon404> lol. [14:24:26 CET] <JEEB> yeah, I guessed [14:24:38 CET] <JEEB> lol [14:24:43 CET] <Daemon404> nobody has spoke dutch since my great gandfather [14:24:46 CET] <Daemon404> :D [14:24:52 CET] <rcombs> "two weeks ago I opened a new ticket on the bug tracker. User 'kyl416' said the cause was something you commited. I don't know if you've seen the ticket already or knew the problem, but I would like it if you could take a look" [14:25:07 CET] <Daemon404> all righty... [14:25:17 CET] <rcombs> so basically "pls look at ticket" [14:25:32 CET] <Daemon404> too bad i have bo protected hls streams to test [14:25:38 CET] <Daemon404> no* [14:26:13 CET] <Daemon404> unless the one in the ticket works [14:27:14 CET] <rcombs> Daemon404: apparently google translate also does a fairly good job on that message [14:27:22 CET] <Daemon404> interesting [14:27:28 CET] <rcombs> so, <insert admonishment for not checking that first> [14:27:46 CET] <Daemon404> bad part of doing merges: everything ever is your fault [14:29:29 CET] <nevcairiel> of course [14:29:50 CET] <nevcairiel> did he at least link the issue [14:30:10 CET] <Daemon404> i would post on the trac issue [14:30:11 CET] <Daemon404> but [14:30:11 CET] <Daemon404> carl. [14:30:13 CET] <Daemon404> so no. [14:30:41 CET] Action: Daemon404 surprised he hasnt demanded a revert yet [14:31:33 CET] <nevcairiel> apparently the link in the ticket still works [14:32:02 CET] <Daemon404> ill check it on monday [14:32:07 CET] <Daemon404> sunday is my no coding day [14:32:29 CET] <Daemon404> i.e. xbox day [14:32:59 CET] <Daemon404> someone with a trac account want to post something akin to "derek will look at it on monday"? [14:33:37 CET] <Fyr> wm4, ffmpeg has effects. [14:34:01 CET] <Fyr> 3D cube is an effect. [14:34:10 CET] <nevcairiel> Daemon404: its not exactly a pressing issue, so just look at it when you have time without a comment =p [14:34:34 CET] <Fyr> if there are many such effects are implemented, why is the cube rotation missing? [14:35:29 CET] <Daemon404> nevcairiel, its pressing in the sense that i dont want to deal with carl demanding a revert [14:35:33 CET] <Daemon404> thats all [14:35:34 CET] <Daemon404> ;) [14:35:48 CET] <wm4> I'll have to quote kierank here [14:36:07 CET] <nevcairiel> last action on the ticket was 8 days ago [14:36:11 CET] <nevcairiel> why would that suddenly show up [14:36:43 CET] <Daemon404> :P [14:37:30 CET] <nevcairiel> just wait until we push tep2! [14:37:36 CET] <JEEB> :D [14:37:41 CET] <Daemon404> lol [14:37:56 CET] <kierank> tep2 isnt that extreme [14:38:07 CET] <nevcairiel> high potential was subtle behavior changes [14:38:12 CET] <nevcairiel> also, ffserver dies with it =p [14:38:14 CET] <ubitux> kierank: it will probably break many things [14:38:25 CET] <Fyr> wm4, ffmpeg developers are bad people and they know it. [14:38:29 CET] <Daemon404> nevcairiel, i cant see killing ffserver being allowed [14:38:33 CET] <Daemon404> i expect full scale riots [14:38:37 CET] <kierank> tep1 was the patchset that turned this project from a neckbeard project into a 21st century project [14:39:14 CET] <JEEB> Daemon404: "muh company depends on ffserver" [14:39:22 CET] <nevcairiel> Daemon404: the new api makes it literally impossible [14:39:23 CET] <JEEB> "muh router streaming depends on ffserver" [14:39:37 CET] <nevcairiel> we could keep supporting it for the deprecation period if you use the deprecated st->codec [14:39:47 CET] <wm4> I still don't get what exactly ffserver does [14:39:55 CET] <wm4> I mean I know some of the mechanism it uses [14:40:06 CET] <JEEB> it's a crappity crappy streaming server [14:40:26 CET] <Daemon404> lol [14:40:27 CET] <JEEB> of which there are multiple by now [14:40:39 CET] <JEEB> ffserver just happens to come with FFmpeg [14:40:45 CET] <JEEB> which is why many poor souls try to run to it [14:40:49 CET] <JEEB> and then hit a brick wall [14:40:56 CET] <JEEB> because it's bad and undocumented, among other things [14:40:58 CET] <Daemon404> we broke someone usign m3u8 as local playlists... [14:41:01 CET] <Daemon404> i forgot people did that [14:41:05 CET] <Daemon404> 'broke' [14:41:41 CET] <wm4> to be fair testing hls from filesystem is nice [14:41:44 CET] <JEEB> yeah, I think I still have old libavformat because I often grab live playlists and segments [14:41:48 CET] <wm4> but it probably shouldn't work by default [14:41:50 CET] <JEEB> for debugging/testing [14:42:03 CET] <Daemon404> its not hls, wm4 [14:42:08 CET] <Daemon404> it's a mplaylist of mp3s [14:42:11 CET] <wm4> oh lol [14:42:14 CET] <Daemon404> aka where m3u started [14:42:16 CET] <Daemon404> iric? [14:42:20 CET] <wm4> tell him to get a real player then [14:43:33 CET] <nevcairiel> where are these whitelists defined anyway [14:43:40 CET] <Daemon404> there is a default one [14:43:44 CET] <Daemon404> for each protocol [14:43:51 CET] <Daemon404> other than that, it is a user [14:43:53 CET] <nevcairiel> but hls is a demuxer, not a protocol [14:44:06 CET] <Daemon404> pretty sure its a protocol [14:44:09 CET] Action: Daemon404 checks [14:44:09 CET] <wm4> yeah, but http and file are protocols [14:44:21 CET] <wm4> no hls is a demuxer [14:44:29 CET] <Daemon404> well it's in .default_whitelist [14:44:29 CET] <nevcairiel> we have a hls protocol, but its old and deprecated [14:44:38 CET] <wm4> eh [14:44:45 CET] <Daemon404> or something [14:45:10 CET] <nevcairiel> so should crypto have a default whitelist of allowing it to be used on everything? [14:45:34 CET] <wm4> crypto is basically just a filter, isn't it [14:45:39 CET] <nevcairiel> exactly [14:45:42 CET] <nevcairiel> no reason to restrict it [14:45:43 CET] <nevcairiel> is there? [14:45:46 CET] <Daemon404> https://github.com/FFmpeg/FFmpeg/blob/9c75148e6ebc88a0501e3d0242defb6dbdc3c… [14:46:07 CET] <Daemon404> should that not work? [14:46:17 CET] <nevcairiel> why would file have a whitelist of itself [14:46:25 CET] <nevcairiel> how can a file protocol open another file [14:46:57 CET] <Daemon404> i think it's for whitelisting stuff opened via that protocol [14:47:03 CET] <Daemon404> i think [14:47:04 CET] <Daemon404> i dunno [14:47:06 CET] <Daemon404> ask michaelni [14:47:07 CET] <Daemon404> he wrote it [14:47:25 CET] <wm4> I totally want a remote playlist poking around in my /dev [14:50:03 CET] <nevcairiel> hls should just not allow mixing protocols, ie. a manifest from https should not allow opening a llocal file, but if the manifest starts as a file, no reason to block it from opening files [14:50:06 CET] <nevcairiel> or so i would think [14:50:40 CET] <nevcairiel> no clue if thats how this whitelist thing works [14:54:24 CET] <wm4> nevcairiel: yeah, I think the security issue was mainly about a local playlist accessing remote URLs [14:54:44 CET] <nevcairiel> btw the example playlist in that ticket looks like valid HLS [14:54:46 CET] <nevcairiel> just downloaded [14:57:34 CET] <wm4> yeah, that one might be HLS [14:58:40 CET] <Daemon404> wm4, it says he got it from youtube-dl [14:59:53 CET] <wm4> youtube-dl can present you HLS and other adaptive streaming crap in the same format, AFAIK [15:00:08 CET] <wm4> can't be bothered to read what _exactly_ his youtube-dl script does [15:00:33 CET] <Daemon404> pretty sure it could just concat them [15:00:35 CET] <Daemon404> since theyre ts [15:00:36 CET] <wm4> so, what youtube-dl does is exporting such things as list of segments, and you can piece them together yourself [15:00:48 CET] <Daemon404> im pretty sure thats only one output method [15:01:00 CET] <Daemon404> im pretty sure it can cobat [15:01:41 CET] <wm4> yeah, youtube-dl by default concats them with ffmpeg or whatever [15:02:00 CET] <Daemon404> o [15:03:08 CET] <Daemon404> BBB, there was an inflate impl by mans btw [15:03:24 CET] <Daemon404> wait that was reimar [15:03:31 CET] <Daemon404> i shifted columns in my brain [15:04:14 CET] <BBB> :) [15:04:52 CET] <Daemon404> i dont want to NIH zlib [15:04:58 CET] <Daemon404> its omni-pesent on everything but windows [15:05:01 CET] <Daemon404> and it has asm for x86 [15:09:37 CET] <Fyr> KKKK [15:13:28 CET] <Daemon404> ...lol [15:14:13 CET] <wm4> lol? [16:06:11 CET] Action: Daemon404 doesnt buy any of these arguments in favour of NIH zlib [16:07:09 CET] <JEEB> "I'm lazy to build zlib for my cross-compile target [16:10:04 CET] <nevcairiel> unfortunately its not only about NIH'ing zlib, but also littering the code with #ifs to support both, because it doesnt sound like he wants to emulate the zlib api =p [16:10:37 CET] <JEEB> yup [16:11:31 CET] <Daemon404> wtf? [16:11:53 CET] <nevcairiel> i mean, whats the point of implementing such an API if it wouldnt get used anywhere [16:12:37 CET] Action: Daemon404 cant wait for libavlibc [16:13:56 CET] <j-b> [= [16:13:59 CET] <j-b> Ž [16:14:00 CET] Last message repeated 1 time(s). [16:14:12 CET] <j-b> oops [16:14:21 CET] <j-b> my cat walked on my keyboard, sorry [16:15:30 CET] <Daemon404> "cat" [16:16:00 CET] <j-b> no, really :) [16:18:41 CET] <Daemon404> ;) [16:34:27 CET] <iive> j-b: now you are obligated to show us a picture of your cat :) [16:35:39 CET] <durandal_1707> or mouse [16:48:24 CET] <cone-161> ffmpeg 03Paul B Mahol 07master:5451be50a89d: avfilter/vf_waveform: use nonsubsampled yuv output format for lowpass filter [16:48:25 CET] <cone-161> ffmpeg 03Paul B Mahol 07master:23d8b79a1833: avfilter/vf_waveform: add text to graticule [16:54:15 CET] <Compn> ; ELSA QUick Codec / MJPEG Codec [16:54:16 CET] <Compn> aha! [16:54:20 CET] <Compn> its just mjpeg. [17:30:05 CET] <cone-161> ffmpeg 03erankor 07master:dd34e89f313b: mov - support seek in encrypted mp4 [17:47:02 CET] <yashpatel> michaelni: For the alternate qualification task for 'FFv1 P frame support' project. what exactly is expected ? I went through the documentation of FFv1, am I supposed to experiment around with the parameters and check corresponding results ? or I need to think for some alternate algorithmic approaches ? [17:55:50 CET] <michaelni> yashpatel, the idea is to improve the algorithm or anything thats part of the algorithm that cannot be adjusted via the command line [17:56:40 CET] <lkajshdf> hello, i'd like to extend the format that ffmpeg's hls muxer accepts, that is i want my segments to contains some timestamp. Where would the most appropriate place to do such a change? Reading the code it seems that the filename generation is happening in hls_start [18:00:37 CET] <yashpatel> michaelni: Can you please provide me a benchmark video for the purpose ? [18:04:56 CET] <durandal_1707> yashpatel: just about any video could do it [18:05:17 CET] <yashpatel> durandal_1707: Thank You. [18:11:07 CET] <Compn> any video _with motion_ [18:11:08 CET] <Compn> :) [18:11:09 CET] Action: Compn runs [18:11:54 CET] <durandal_1707> yashpatel: you are improving encoding performance, do you know how to do it? [18:12:40 CET] <yashpatel> durandal_1707: I'm an undergraduate researcher in Computer Vision and Machine learning. So trying to figure out things :P [18:13:11 CET] <yashpatel> durandal_1707: looking for appropriate research papers, and trying to get idea of things I can change in current algorithm used. [18:13:38 CET] <yashpatel> durandal_1707: Any suggestion / guidance ? Please ? [18:14:53 CET] <yashpatel> durandal_1707: I'm planning to make changes and compare compression ration outputs and stuff! [18:15:22 CET] <durandal_1707> first find out what current ffv1 use [18:27:28 CET] <cone-161> ffmpeg 03foo86 07master:db44b599805f: avcodec/dca: clear X96 channels if nothing was decoded [18:29:34 CET] <JEEB> anyone want to poke this with a review https://github.com/VFR-maniac/ffmpeg/commit/172fe56b1a4a063ff2feb14d3394129… ? [18:32:45 CET] <lorddoskias> is there an easy way to add a timestamp to the filename generate by the hls muxer? [19:07:48 CET] <wm4> lol [19:19:25 CET] <Prelude2004c> hey guys.. i hope you are all doing well. I would like some advice. Using ffmpeg with vdpau but vdpau has some issues with decoding h264. Does anyone know if a fix is in the works or some other way to do it? [19:19:56 CET] <wm4> Prelude2004c: I know no of such problems, either your code is broken or your GPU (or drivers) are [19:22:57 CET] <Prelude2004c> my code ? seems pretty simple.. -hwdecoder vdpau [19:23:08 CET] <Prelude2004c> same code decoding mpeg2video works just fine ... [19:23:27 CET] <Prelude2004c> i see the GPU decoder work correctly without any issues with mpeg2video [19:23:32 CET] <Prelude2004c> when it comes to h264 .. its a no go [19:24:52 CET] <MelchiorGaspar> what do you have for a GPU? [19:50:33 CET] <MelchiorGaspar> <Prelude2004c> what type of graphics card do you have? [19:54:40 CET] <carpediem_> Hello developers. I have been doing the fuzzing tests on ffmpeg and found some files which cause it to hang. Still searching for files which can cause a crash. Wanted to ask if you guys use some specific test files(or format) to check ffmpeg stability? [19:58:28 CET] <kierank> carpediem_: a hang is fine [19:58:41 CET] <kierank> that's also a bug [19:58:49 CET] <kierank> the trick is to use small files at around 10kB [19:58:52 CET] <kierank> obscure formats too [19:58:57 CET] <Compn> carpediem_ : any files at http://samples.ffmpeg.org [20:02:17 CET] <carpediem_> small files, but a large number? [20:02:29 CET] <carpediem_> I have been using afl-fuzz for testing of files [20:03:37 CET] <kierank> zzuf is probably better to begin with [20:03:45 CET] <kierank> but hangs are bugs so please report them [20:03:49 CET] <kierank> and fix if possible [20:04:25 CET] <carpediem_> where should I report the files which caused hangs? [20:04:56 CET] <carpediem_> will try fixing the bugs [20:08:06 CET] <kierank> carpediem_: https://ffmpeg.org/bugreports.html [20:08:39 CET] <Compn> http://trac.ffmpeg.org , read those intructions ^^ [20:08:40 CET] <Compn> :) [20:10:58 CET] <carpediem_> Thanks (for almost pointing it out)! [20:18:49 CET] <Prelude2004c> sorry for the huge delay.. i am using an M4000 card [20:32:32 CET] <cone-161> ffmpeg 03Paul B Mahol 07master:02f84215461a: avfilter/vf_histogram: add 12bit depth support [20:32:33 CET] <cone-161> ffmpeg 03Paul B Mahol 07master:6e19120ea206: avfilter/vf_vectorscope: add 12bit depth support [21:19:38 CET] <cone-161> ffmpeg 03Boris Nagels 07master:1109ed7973c7: avformat/rtpenc: Fix integer overflow in NTP_TO_RTP_FORMAT [21:23:17 CET] <cone-161> ffmpeg 03Carl Eugen Hoyos 07master:719276b8609e: lavc/cfhd: Sanitize avpriv_report_missing_feature() usage. [21:39:27 CET] <cone-161> ffmpeg 03Carl Eugen Hoyos 07master:59793785f4ba: lavc/cfhd: Remove one more \n from avpriv_report_missing_feature(). [21:40:47 CET] <cone-161> ffmpeg 03Carl Eugen Hoyos 07master:aebfbe5c1368: lavf/riffdec: Remove \n from avpriv_report_missing_feature(). [22:29:28 CET] <cone-161> ffmpeg 03Carl Eugen Hoyos 07master:e356487fdae8: lavf/img2dec: Use jpeg constants in jpeg_probe(). [22:32:23 CET] <MelchiorGaspar> <Prelude2004c> sorry for the huge delay.. i am using an M4000 card [22:33:39 CET] <MelchiorGaspar> ^ Whats the maufacturer? is it ATI, Nvidia, etc? because I've never heard of the m4000 [22:34:47 CET] <ethe> nvidia m4000 quadro maybe [22:35:21 CET] <Prelude2004c> nvidia [22:35:26 CET] <Prelude2004c> yes quadro [22:36:04 CET] <MelchiorGaspar> so this is a work station? [22:36:46 CET] <MelchiorGaspar> quadro are best for CAD/CAM [22:38:25 CET] <JEEB> please ask for support from nvidia then. if it works with other pieces of hardware it's either due to your drivers or hardware [22:39:01 CET] <MelchiorGaspar> Geforce is the best of Nvidia I have a http://www.amazon.com/EVGA-GeForce-Display-Graphics-02G-P4-3757-KR/dp/B00J0… [22:40:18 CET] <Shiz> i don't think this is #recommend-a-gpu-devel [22:41:46 CET] <JEEB> the m4000 is listed as vdpau level E in the latest nvidia drivers, so please goto nvidia if you are having issues that nobody else seems to be having. if it's actually noted as an issue in FFmpeg, it will get fixed but until then it seems more likely that either your driver or hardware is borked [22:41:51 CET] <JEEB> so please [22:41:52 CET] <JEEB> goto nvidia support [22:46:17 CET] <wm4> most likely his code is just buggy [22:46:36 CET] <JEEB> he seems to be a cli user [22:46:43 CET] <JEEB> using whatever hack there is in ffmpeg cli [22:47:06 CET] <JEEB> at least him noting that there his "code" was something that looked like a ffmpeg cli parameter [22:50:13 CET] <dinux5> Hi everyone. I want to apply for Outreachy 2016. [22:50:24 CET] <Compn> hello [22:50:28 CET] <Compn> welcome dinux5 [22:51:12 CET] <dinux5> I have cloned the code base and need help on my further steps . :) [22:51:36 CET] <Compn> sure , ask away [22:52:10 CET] <dinux5> I have selected TrueHD encoder as the project where I would want to work(keeping in mind my set of skills.) [22:52:27 CET] <dinux5> How do I proceed with completing the Qualification task? [22:53:27 CET] <dinux5> Or is there something else i was supposed to do before I select any project :) [22:55:43 CET] <nevcairiel> contact the mentor first to make sure everything is in order, he can then also inform you about how to start [22:58:51 CET] <dinux5> Thanks ! I have already mailed my project's mentor. Is there anything suggested I should do till I get a reply. :) [23:11:41 CET] <ethe> dinux5: getting familiar with the FFmpeg codebase (particularly libavcodec), if you're not already might be a good idea [23:13:51 CET] <dinux5> ethe: Oh k. Thanks a lot :) . [00:00:00 CET] --- Mon Mar 7 2016

1 0

ffmpeg.log.20160306
by burek 07 Mar '16

07 Mar '16

[01:49:34 CET] <JamJams> libavcodec question, getting some memory leaks. I'm decoding then if a condition is met I duplicate the frame using av_buffersrc_add_frame_flags(buffersrc_ctx, av_frame_clone(newframe), AV_BUFFERSRC_FLAG_KEEP_REF); but when I do that the memory is leaked for the duplicated frame. [01:49:45 CET] <JamJams> How should I go about duplicating frames so that it doesn't leak memory? [02:03:18 CET] <_Vi> Is there any use of this hack for amateurs of static linking: https://github.com/vi/FFmpeg/commit/a554d6451e041ec6cb3297830e94903d64368cad . Shall I try to make a proper patch? [02:05:08 CET] <J_Darnley> People with small, vary small disk space? [02:06:01 CET] <J_Darnley> If you want to submit a patch then you are welcome to [02:06:13 CET] <_Vi> J_Darnley, People that does not like unnecessary duplication. One can include FFmpeg as a tool, not as a library and when you want both to convert files and to analyze them, it's better to have both ffmpeg and ffprobe. [02:06:41 CET] <J_Darnley> Just explain why and your reasoning. [02:07:06 CET] <_Vi> J_Darnley, I mean does patch that adds such mode (although less invasively) have a change to be accepted? [02:07:17 CET] <J_Darnley> No idea, sorry [02:48:41 CET] <fundies> whats the difference between colorprim and transfer in x265? [04:27:16 CET] <jookiyaya> i want to able to use shine mp3 encoder [04:28:40 CET] <grublet> fundies: colorprim is the color primaries, transfer is the transfer coefficients [04:33:51 CET] <fundies> :/ [04:51:52 CET] <svnpenn> If I use "-ss", "-t" and "-c copy", the duration is reduced, but not the reported duration. This happens with "-ss -t -i", "-ss -i -t" and "-i -ss -t" [06:27:58 CET] <fundies> why ffmpeg only using ~ 1/2 my cpu? [07:59:34 CET] <flux> fundies, by cpu do you mean one or more cores? [09:48:25 CET] <Fyr> guys, when using DXVA2 I experience low speed in contrast to the option -hwaccel dxva2 off. [09:49:03 CET] <Fyr> how to get a speed gain when using hardware acceleration? [11:24:31 CET] <ku1dne> Hello, is there any advantage at all to using bitrates that are divisible by 8 (for example 1536 instead of 1500) for video encoding with x264? [11:34:27 CET] <furq> no [12:40:35 CET] <_Vi> ku1dne, If you want some advantage but don't need strict bitrate, you can use alternative modes like -crf or use two-pass encoding. [13:36:24 CET] <Fyr> is it possible to make cube rotation with ffmpeg like KDE effect? [13:36:36 CET] <Fyr> first introduced in compiz [13:40:55 CET] <J_Darnley> Cube rotation? Do you have an example of what you want to see? [13:41:12 CET] <J_Darnley> I can think of perspective which might dowhat you want. [13:41:17 CET] <Fyr> yes, KDE effect. [13:41:25 CET] <J_Darnley> I don't know what that is. [13:41:30 CET] <ubitux> the compiz thing? [13:42:21 CET] <Fyr> http://www.youtube.com/watch?v=4QokOwvPxrE [13:43:13 CET] <Fyr> http://www.youtube.com/watch?v=4417_9UjuqQ [13:43:21 CET] <Fyr> the last one is shorter. [13:43:40 CET] <J_Darnley> Fuck you youtube and your overlays and your geo restrictions [13:44:44 CET] <Fyr> I would give you the link to VK video, but you won't be happy about it too. =) [13:44:48 CET] <J_Darnley> No [13:44:54 CET] <J_Darnley> ffmpeg cannot do that [13:45:08 CET] <J_Darnley> What would you want shown on the other faces anyway? [13:45:18 CET] <furq> another video, presumably [13:45:30 CET] <Fyr> right [13:45:33 CET] <Fyr> or the same thing or a screenshot. [13:46:02 CET] <Fyr> sometimes blackscreen is good too. [13:47:42 CET] <furq> https://www.youtube.com/watch?v=y3YcsAOttO0&t=3m02s [13:47:45 CET] <furq> ffmpeg has got some catching up to do [13:48:45 CET] <Fyr> agreed [13:48:46 CET] <J_Darnley> I doubt people want an aliased effect [13:48:55 CET] <J_Darnley> they would bitch about the quality [13:49:55 CET] <Fyr> they won't. [14:15:20 CET] <Filarius> Hello, how do I can ask ffmpeg to retry connection if it found 404 error while trying to get source from link ? [14:24:08 CET] <JEEB> Filarius: no way to do that within FFmpeg, I mean it goes backwards from any usual use case. You should build your own thing that re-starts FFmpeg or the libraries if you're using them in case you need to probe for input all the time [14:26:11 CET] <Filarius> okay, thanks [14:42:50 CET] <AlexQ> Hi. How to slow down a matroska video with h.264 content without reencoding video? (Slow down from "PAL progressive" (25 FPS) to "NTSC progressive" (23.976 FPS)? Can I just force ffmpeg to think that the input video is 23.976 FPS? And I also want to replace the original audio with a soundtrack from another file (which is 23.976 FPS) [14:44:05 CET] <AlexQ> As the soundtrack in PAL version is dubbing only, unfortunately [14:47:22 CET] <flux> alexq, this seems relevant to your question: https://trac.ffmpeg.org/wiki/How%20to%20speed%20up%20/%20slow%20down%20a%20… - or are you asking if the change could cause issues? [14:48:55 CET] <AlexQ> Thanks, flux. Is that possible without reencoding the video? [14:52:13 CET] <AlexQ> I thought that maybe it is just as simple as changing the FPS metadata in the Matroska file, but there are also these PTS for each frame I believe which need to be changed as well (these are in the H.264 stream itself, right?) [14:53:44 CET] <AlexQ> Found something like that, flux: http://ffmpeg.org/pipermail/ffmpeg-user/2014-May/021673.html [15:01:23 CET] <flux> alexq, ah sorry, I sort of assumed the examples wouldn't re-encode anything [15:02:22 CET] <flux> and yes, H.264 stream has presentation time stamp and decoding time stamp [15:06:43 CET] <AlexQ> so what happens when I change the framerate metadata in a video file, but without changing presentation and decoding time stamps? [15:07:11 CET] <JEEB> most containers don't have a notion of "frame rate" really [15:07:22 CET] <JEEB> and if they have it's completely cosmetic [15:07:29 CET] <JEEB> I think AVI was the last thing that only had a frame rate [15:07:42 CET] <JEEB> (well there are probably mangled non-generic things as well) [15:07:54 CET] <AlexQ> http://forum.doom9.org/showthread.php?t=173107 - someone reports to have succeeded with mp4box, but the problem is quite different. I just can't believe it is impossible to do such a conversion without reencoding [15:08:07 CET] <JEEB> what are you trying to do? [15:08:22 CET] <JEEB> most containers have a per-stream or global timebase, and then every stream has their own timestamps for each "sample" [15:08:50 CET] <flux> it certainly is possible, but if there's a tool to do it is another matter [15:09:03 CET] <JEEB> if you are trying to change the rate of a clip I recommend extracting the video track and remuxing it with L-SMASH's muxer and specifying the rate you want [15:09:23 CET] <JEEB> because the pts video filter requires re-encoding and -r doesn't work [15:10:05 CET] <JEEB> muxer -i input.264?fps=24000/1001 -o output_at_24000_1001_fps.mp4 [15:10:29 CET] <JEEB> and you can mux in the audio track at the same time if you have it around [15:10:39 CET] <AlexQ> Replace original soundtrack from a 25 FPS video with a soundtrack from a 23.976 FPS video. Thought it would make much more sense just to change to slow the 25 FPS video down rather that tempo up the audio from 23.976. [15:10:51 CET] <JEEB> yeah [15:10:56 CET] <JEEB> because that way you don't have to re-encode either [15:10:57 CET] <JEEB> so yeah [15:11:15 CET] <JEEB> ffmpeg -i initial_input -c copy out.264 [15:12:13 CET] <JEEB> muxer -i out.264?fps=24000/1001 -i your_audio (if the audio is in raw bit stream, otherwise you use ffmpeg or L-SMASH's remuxer) -o out_with_new_rate.mp4 [15:14:33 CET] <JEEB> and yes, "23.976" is really 24000/1001 [15:16:21 CET] <AlexQ> So I should extract that audio to an aac raw stream (as that's the format I believe), right? From the 23.976 FPS file? And what "muxer" program is that? I got lost. I am using Ubuntu, what package should I install? Or if there is no package in the official repo, should I use some ppa or (least preferably) compile something, or maybe get a .deb or a pre-compiled tarball [15:16:22 CET] <AlexQ> ? [15:17:00 CET] <JEEB> nah, the video thing is what matters for now [15:17:16 CET] <JEEB> just in case you had the other audio track as a raw bit stream you'd be using that [15:17:38 CET] <JEEB> you extract the video track like in the first command to raw "Annex B" AVC/H.264 [15:17:56 CET] <JEEB> then you use L-SMASH's muxer to mux it with a different frame rate [15:18:19 CET] <JEEB> not sure l-smash has any official packaging [15:18:33 CET] <JEEB> thankfully, building it is rather easy https://github.com/l-smash/l-smash [15:19:02 CET] <JEEB> after configure and make you should have the tools under cli [15:19:13 CET] <JEEB> including muxer [15:20:01 CET] <JEEB> then you should be able to mux the AVC/H.264 track into mp4 with it with the new rate [15:20:13 CET] <JEEB> after that it's pretty simple to stick the audio track to it with whatever you want, really [15:20:20 CET] <JEEB> f.ex. ffmpeg [15:21:10 CET] <JEEB> but yeah, we can look into the audio side after you've confirmed that you've gotten the video done :) [15:21:45 CET] <AlexQ> Indeed, no need for any libs or anything for L-SMASH's muxer [15:21:51 CET] <AlexQ> installed [15:22:43 CET] <AlexQ> extracting h264... [15:23:59 CET] <JEEB> yeah, it's kind of unfortunate that retiming tracks isn't working well with ffmpeg cli. I guess you could do it with the library, but there's no way to do it through the ffmpeg cli [15:26:12 CET] <JEEB> but since I've got L-SMASH and I can live with some unfortunate data duplication for a moment, I'm fine with taking that route for now [15:27:16 CET] <AlexQ> So in that ffmpeg -i initial_input -c copy out.264 ffmpeg knows I want to copy vid only by guessing the output format from the output file extension? Cool [15:28:40 CET] <JEEB> yeah, because the output format guessed by the extension can't contain anything else [15:29:09 CET] <JEEB> if it could, it would copy what it could or even error out due to the output container not supporting some video/audio/subtitle format [15:29:10 CET] <AlexQ> and if I use -c option it specifies the codec for all streams? [15:29:17 CET] <JEEB> yup [15:30:43 CET] <AlexQ> So I should remux that raw stream to .mp4, not .mkv now? With muxer? I don't care, whatever is safer. In your example you had mp4 [15:32:43 CET] <AlexQ> muxing to 24000/1001 FPS mpeg4 container then [15:34:03 CET] <JEEB> L-SMASH is a thing that is specifically made to correctly implement the video/audio/timed text specific parts of MPEG-4 container [15:34:09 CET] <JEEB> you can later change that to matroska if you require [15:35:00 CET] <JEEB> one of the good sides of the MPEG-4 container is that it can deliver your timestamps as specific as you want, so as a source it's probably one of the best ways to do it [15:35:38 CET] <JEEB> mpeg-ts has a global timebase of 90000, and matroska is usually limited to millisecond precision [15:36:30 CET] <AlexQ> Wow, it was using a lot of RAM, almost 2 gigs. Dunno what [15:36:36 CET] <AlexQ> but it crashed, unfortunately [15:36:45 CET] <JEEB> huh [15:37:13 CET] <JEEB> would be great to see how that happened, but unfortunately can't really do it without a sample [15:37:13 CET] <AlexQ> first it displayed "MP4 muxing mode" and started using HDD and memory heavily (CPU not as much intensely) [15:37:28 CET] <AlexQ> and then I got [15:37:29 CET] <AlexQ> "[importer: Error]: failed to find the matched importer. [15:37:30 CET] <AlexQ> Error: failed to open input file. [15:37:30 CET] <AlexQ> Error: failed to open input files. " [15:37:56 CET] <JEEB> can I get a full command line and terminal output in a pastebin-like? [15:38:03 CET] <AlexQ> ffmpeg exported with no errors [15:38:17 CET] <JEEB> also if possible it'd be nice to get the sample if you can share that (even if in private) [15:38:27 CET] <JEEB> would be nice to debug if it happens to me, too [15:38:42 CET] <AlexQ> How can I check if the 264 file plays correctly? [15:38:54 CET] <JEEB> ffmpeg -i file.264 -f null - [15:39:06 CET] <JEEB> it will say something about bad timestamps with the null muxer, but that's OK [15:39:16 CET] <JEEB> because null muxer will just throw things into the void anyways [15:39:37 CET] <JEEB> (it will decode the thing and throw it out) [15:42:21 CET] <AlexQ> should I update to ffmpeg 3.0 as well? I have 2.7.6 from Ubuntu 14.10 repo [15:42:59 CET] <JEEB> the versions aren't much, in general if possible you should be following the master branch as long as FATE looks green [15:43:11 CET] <JEEB> FATE = http://fatebeta.ffmpeg.org/ [15:43:37 CET] <JEEB> but yes, in general the newer the better [15:44:31 CET] <AlexQ> 15.10* obviously [15:50:43 CET] <AlexQ> http://paste.ubuntu.com/15307781/ [15:51:03 CET] <AlexQ> that decode-testing of the extracted video [15:52:10 CET] <JEEB> ooh-kay [15:52:13 CET] <JEEB> now that looks fun [15:52:18 CET] <JEEB> no wonder you get issues [15:52:45 CET] <JEEB> it's as if there's no parameter sets [15:53:02 CET] <JEEB> which contain that little stuff like picture size and parameters for compression etc [15:53:51 CET] <JEEB> you might want to git clone ffmpeg (git://git.videolan.org/ffmpeg.git) and compile without any options. if you aren't going to re-encode, that should bring you up to snuff with a basic binary [15:54:01 CET] <JEEB> no need to install it, just use from the build dir [15:54:19 CET] <JEEB> you will probably have to have yasm installed but that should be it [15:54:40 CET] <JEEB> then try extracting the video track once again with that [15:55:14 CET] <AlexQ> but the vid plays well in VLC, I mean the original matroska file with audio. Maybe I should try to null-decode the whole original Matroska file with the ffmpeg I have? And enable verbose mode as well? [15:55:51 CET] <JEEB> nah, focus on updating FFmpeg and see what happens when you extract the video with that [15:56:00 CET] <JEEB> (when you try to decode that) [15:58:24 CET] <AlexQ> okay, already running raw decode on the original vid file with -loglevel debug [15:58:28 CET] <AlexQ> I already got something like [15:58:36 CET] <AlexQ> [null @ 0x2699e40] Encoder did not produce proper pts, making some up. [15:58:43 CET] <JEEB> that's what I said is OK [15:58:50 CET] <AlexQ> okay [15:59:05 CET] <JEEB> it's because the null muxer is basically void [15:59:18 CET] <JEEB> throws everything out so various fields aren't filled [15:59:31 CET] <AlexQ> but that is the original Matroska file. Okay [16:00:07 CET] <JEEB> anyways, I wouldn't focus on the matroska file but rather what happens when you extract the video stream from it with the latest FFmpeg [16:02:15 CET] <Filarius> Hello, how to fix recording from livestream, seems some livestream have lag on start on video/audio syncronization. Logs http://pastebin.com/pUGbbfRf and video http://rghost.ru/7N6Bz42RS down load video - online player have another lag. I tryed to upload to Youtube, and somehow it fix it - lag changes to no audio for 50-90 ms [16:03:17 CET] <AlexQ> okay, I'll compile it later. I just wanted to decode the whole Matroska file to check if it isn't corrupted, as I haven't watched it yet [16:03:32 CET] <AlexQ> will be back later! Thank's JEEB! [16:03:42 CET] <JEEB> even if it is later, parameter sets are required from the beginning [16:04:06 CET] <Filarius> I have same lag after re-encoding record [16:04:28 CET] <JEEB> so if it properly starts decoding, it got those from somewhere :P [16:06:59 CET] <AlexQ> :D [16:07:13 CET] <AlexQ> JEEB: Maybe that will be of some interest for you: http://paste.ubuntu.com/15307964/ [16:07:31 CET] <AlexQ> didn't let it run all the way, have it stopped for the moment [16:07:45 CET] <JEEB> AlexQ: aka it got the parameters just fine [16:07:59 CET] <AlexQ> as you can see, my machine isn't a speed demon :D [16:08:56 CET] <JEEB> so yeah, build a standard configuration FFmpeg from master (just ./configure) and run that from the directory you built it in and see what comes out when you try to extract the track with it [16:10:50 CET] <AlexQ> 50 tbc - does that mean it is a raw recoding from a PAL HDTV source? [16:11:48 CET] <JEEB> don't read into those values too much [16:12:18 CET] <JEEB> I don't even remember which bits of data ffmpeg cli uses to come out with them :) [16:12:29 CET] <JEEB> tbn is the matroska timebase at least [16:12:45 CET] <JEEB> millisecond precision so one second is 1k ticks [16:12:58 CET] <AlexQ> Okay, I'll be back later, with the newest ffmpeg master [16:13:01 CET] <JEEB> ok [16:13:03 CET] <AlexQ> Thanks very much! [16:13:15 CET] <JEEB> np [17:52:35 CET] <AlexQ> JEEB: Compiling, takes a while... [17:53:44 CET] <JEEB> yeah, although you can `make -jX` where X is the amount of cores you have or so [17:54:00 CET] <JEEB> FFmpeg does have a few files :) [17:55:02 CET] <furq> AlexQ: http://johnvansickle.com/ffmpeg/ [17:55:46 CET] <JEEB> furq: he doesn't need anything fancy so better to just keep him compiling if he's already doing it :P [17:56:51 CET] <AlexQ> good to know, JEEB. Pity I had no idea that it doesn't do it in parallel automatically, it uses only one core indeed [17:57:31 CET] <furq> if you cancel make and rerun it with -jn it should pick up where it left off [17:58:11 CET] <AlexQ> furq: Just Ctrl+C? [17:58:14 CET] <JEEB> yeah [18:06:04 CET] <AlexQ> I decided to install it after compiling, so I first removed ffmpeg package from Ubuntu [18:06:07 CET] <AlexQ> done make install [18:06:24 CET] <AlexQ> but now when I type ffmpeg I get /usr/bin/ffmpeg: no such file or directory [18:06:30 CET] <AlexQ> what's up? [18:06:35 CET] <furq> it'll probably be in /usr/local/bin [18:06:39 CET] <furq> although that should really be on your PATH [18:07:29 CET] <AlexQ> apparently it isn't, as there is ffmpeg there indeed [18:07:40 CET] <AlexQ> how should I add it to PATH? [18:08:00 CET] <AlexQ> uum [18:08:01 CET] <JEEB> yeah, that's why I said just use it from the build dir :P [18:08:03 CET] <AlexQ> it is in PATH [18:08:04 CET] <furq> "/usr/bin/ffmpeg: no such file or directory" isn't the right error message for it not being on your path [18:08:12 CET] <JEEB> you'll have to reload or whatever [18:08:21 CET] <furq> i guess something else on your PATH is pointing to /usr/bin/ffmpeg [18:08:21 CET] <JEEB> because the shell has already once picked which ffmpeg it will run [18:08:21 CET] <AlexQ> is it some cache issue or what? [18:08:25 CET] <JEEB> yes [18:08:42 CET] <JEEB> rehash or reload [18:08:44 CET] <JEEB> whichever it was [18:09:05 CET] <furq> hash -r [18:09:12 CET] <AlexQ> just closed the vterm window and opened again and it worked :D [18:09:16 CET] <furq> yeah that'll do it [18:10:23 CET] <JEEB> anyways, check if the latest FFmpeg extracts the AVC track properly (by trying to decode it afterwards) [18:11:39 CET] <AlexQ> doing just that [18:11:58 CET] <AlexQ> BTW. Could I pipe ffmpeg with muxer? [18:12:14 CET] <AlexQ> for the future, I'll have a few more files to convert like that [18:12:39 CET] <JEEB> I don't remember how well muxer takes in AVC from stdin, so feel free to try [18:12:44 CET] <JEEB> if it works, great [18:12:55 CET] <JEEB> if not, I can look into it when I have time [18:13:33 CET] <AlexQ> BTW2. So muxer can't demux mkv, but it could mp4, or it can only mux raw streams? [18:13:53 CET] <JEEB> it can only mux raw streams into ISOBMFF derivatives [18:14:09 CET] <JEEB> remuxer can remux streams from ISOBMFF derivatives into ISOBFMM derivatives [18:14:20 CET] <JEEB> L-SMASH is a purely ISOBMFF-specific project [18:14:35 CET] <JEEB> you can then remux that ISOBMFF into matroska or whatever you want [18:17:06 CET] <AlexQ> That's the demux log, if want to have a look: http://paste.ubuntu.com/15309676/ [18:17:12 CET] <AlexQ> running null decode... [18:20:28 CET] <AlexQ> failed :( [18:21:28 CET] <AlexQ> http://paste.ubuntu.com/15309791/ [18:23:38 CET] <AlexQ> So that means any remuxing of that source file would file? E.g. if I decided to tempo up the audio file from the other source to 25 fps? [18:24:39 CET] <AlexQ> fail* [18:24:40 CET] <JEEB> nah, it just means that the demuxing failed [18:25:30 CET] <AlexQ> so how can e.g. VLC play the source file when demuxing fails even with the newest ffmpeg? [18:25:53 CET] <JEEB> ok, I said it wrong [18:26:00 CET] <JEEB> the writing of the raw Annex B fails :P [18:26:02 CET] <JEEB> demuxing works [18:26:13 CET] <JEEB> otherwise you would've not been able to decode the source [18:26:27 CET] <JEEB> ffmpeg -i input.mkv -bsf:v h264_mp4toannexb -c copy out.264 [18:26:28 CET] <JEEB> try this [18:26:31 CET] <JEEB> just in case [18:26:39 CET] <JEEB> it should put that BSF there by default [18:26:43 CET] <JEEB> but just in case [18:26:54 CET] <Paranoialmaniac> ffmpeg h264 bsf is broken. apply this patch https://github.com/VFR-maniac/ffmpeg/commit/172fe56b1a4a063ff2feb14d3394129… [18:27:39 CET] <JEEB> a wild VFR Maniac appears [18:27:50 CET] Action: Paranoialmaniac hides [18:28:33 CET] <JEEB> not sure if that is the reason for the parameter sets not being found, though... but sure, looks like a valid fix for too short start codes [18:28:43 CET] <JEEB> because it looked like it didn't use the BSF at all [18:30:51 CET] <JEEB> AlexQ: anyways try with the BSF inserted there (-bsf:v h264_mp4toannexb) [18:31:02 CET] <JEEB> if that still fails, try V-maniac's patch [18:31:05 CET] <AlexQ> before trying to apply the patch? Okay [18:31:23 CET] <bencoh> hmm, is this bug in ffmpeg bugtracker? [18:32:01 CET] <JEEB> no idea, it looked useful so I poked the -devel channel with the patch [18:32:30 CET] <JEEB> not sure if he has already posted it on -devel ML [18:33:01 CET] <JEEB> seems like not [18:33:28 CET] <bencoh> can [18:33:29 CET] <Paranoialmaniac> i didnt since i have planed to post on libav-devel :P [18:33:33 CET] <bencoh> cant find it either :) [18:33:39 CET] <bencoh> Paranoialmaniac: ah [18:33:39 CET] <JEEB> ok [18:33:51 CET] <JEEB> and then it would flow to ffmpeg through the merges [18:34:31 CET] <JEEB> but since it's a few months old... I guess you wouldn't mind at this point unless you're actually going to post it :) also I think Libav just started reworking the BSF API together with related FFmpeg folk [18:34:34 CET] <bencoh> looks like the kind of bug I might have encountered months ago without knowing why [18:35:02 CET] <JEEB> (seems like Libav is becoming the kettle where breaking changes are first introduced) [18:35:40 CET] <JEEB> (although I guess it's nothing new since elenril kind of started such way of improving things a few years back) [18:36:44 CET] <Paranoialmaniac> i dont have time to rewrite the patch for libav recently :P i guess the patch cant be applied cleanly [18:36:53 CET] <JEEB> yeah [18:37:22 CET] <JEEB> I had a similar issue with some of my patches that I've still not posted on the ML [18:37:50 CET] <bencoh> which reminds me I still have a ffmpeg/libssh patch lying around [18:38:10 CET] <bencoh> and I need help regarding libssh caching ... forgot about that too [18:38:23 CET] <bencoh> (caching/read-ahead) [18:41:52 CET] <AlexQ> Demux log with that option added: http://paste.ubuntu.com/15310043/ [18:42:26 CET] <JEEB> alright, now see if you can decode that extracted track [18:45:16 CET] <AlexQ> seems to be decoding, 5 mins already decoded with no errors. Guess that means it works then? [18:45:25 CET] <JEEB> most probably yes [18:45:41 CET] <AlexQ> So now back to muxer... [18:47:51 CET] <AlexQ> Decode log, if you were interested for debug purposes or sth: http://paste.ubuntu.com/15310151/ [18:48:17 CET] <JEEB> not really, just shows that the extraction worked :) [19:00:18 CET] <AlexQ> JEEB: http://paste.ubuntu.com/15310342/ :( [19:02:03 CET] <AlexQ> VLC can't play that 264 file either. Not even a single frame displayed, and "[h264 @ 0x7f943d239f20] mmco: unref short failure" in the terminal output [19:02:28 CET] <JEEB> VLC is quite different and most probably using a different version [19:02:38 CET] <JEEB> aanyways [19:03:00 CET] <AlexQ> So I don't even know if the .264 file is correct or not [19:03:14 CET] <JEEB> ooh-kay.. now try with the patch (in the FFmpeg source dir `git remote add vmani https://github.com/VFR-maniac/ffmpeg.git` `git fetch vmani` `git cherry-pick 172fe56b1a4a063ff2feb14d3394129eb155b40d`) [19:03:43 CET] <JEEB> haven't tried it myself yet, but by chance it could match as-is [19:03:59 CET] <JEEB> and then run make and it should rebuild the related components [19:14:45 CET] <AlexQ> These two files were compiled after make "CC libavcodec/h264_mp4toannexb_bsf.o AR libavcodec/libavcodec.a", guess that means the patch worked, right? [19:15:20 CET] <JEEB> if the patch worked git successfully cherry-picked the patch [19:15:28 CET] <JEEB> it should have told you that the cherry-pick failed otherwise [19:18:38 CET] <AlexQ> JEEB: Extracting after make and make install. MD5'ed previous .264 to check if they will differ in any way [19:18:51 CET] <JEEB> ok [19:24:13 CET] <AlexQ> JEEB: Guess I should let ffmpeg test decode run through the whole file this time? [19:24:19 CET] <JEEB> nah [19:24:28 CET] <JEEB> just make sure it *can* start decoding it [19:24:59 CET] <AlexQ> well, it could before patching, but muxer couldn't. So try muxer now then? [19:25:25 CET] <JEEB> sure [19:25:58 CET] <AlexQ> md5sums differ, so the patch apparently influenced the output file [19:26:31 CET] <JEEB> yeah, it made the start codes longer for parameter sets [19:27:49 CET] <JEEB> you can either have 0x00 00 01 or 0x00 00 00 01 , and it seems like that bit stream filter in FFmpeg wasn't properly making four byte start codes for parameter sets, even though the specification says they should be at least 4 bytes long [19:28:01 CET] <AlexQ> Yes, the file is slightly larger as well [19:28:39 CET] <AlexQ> 2050729719 to 2050731491 bytes [19:33:31 CET] <AlexQ> [H.264: Info]: Analyzing stream as H.264 [19:33:36 CET] <AlexQ> maybe it'll work then [19:33:44 CET] <JEEB> looks good [19:34:14 CET] <rainabba> I'm learning my way around capture from a DeckLink 4K Pro. When I attempt UHD60 capture and copy to avi, I get an "input buffer overflow" Anyone familiar with this? How do I enlarge that buffer or what does it indicate? [19:36:11 CET] <AlexQ> and in the meantime, what approach should I take when trying to synchronize with the new soundtrack when muxing? [19:37:12 CET] <JEEB> ffmpeg -i your_mp4.mp4 -i your_mkv_video_with_audio.mkv -map 0:v -map 0:a -c copy out.your_extension_of_liking [19:37:28 CET] <JEEB> maps the video track(s) from the first input file, and the audio track(s) from the second [19:37:36 CET] <JEEB> which disables automatic track selection [19:38:42 CET] <AlexQ> and what about sync? [19:38:47 CET] <maco1717> hi where can i find the irc logs for this channel? [19:39:45 CET] <JEEB> AlexQ: you should be able to check that after that [19:39:56 CET] <AlexQ> it is very likely that some shift will be required. Can you sync without reencoding audio? [19:40:02 CET] <JEEB> yeah [19:40:31 CET] <JEEB> you can extract a part of the audio track only first, making sure it has the parts you need only [19:40:42 CET] <JEEB> and then mux that together with the video [19:43:57 CET] <AlexQ> Importing stage finally [19:46:35 CET] <rainabba> maco1717: There isn't a universal answer to that as the various servers may/may-not maintain logs. If you check the server you're using and find that organization on the web, you may find logs they maintain. [19:47:22 CET] <furq> maco1717: http://ffmpeg.gusari.org/irclogs/ [19:47:35 CET] <rainabba> nice :) [19:48:15 CET] <rainabba> furq: That a server provider or maintained by the ffmpeg project? [19:48:33 CET] <furq> server provider? [19:48:43 CET] <rainabba> IRC server [19:48:45 CET] <furq> oh [19:49:02 CET] <furq> i don't think any irc servers keep channel logs [19:49:14 CET] <furq> especially not on a network the size of freenode [19:49:48 CET] <furq> i assume those logs are provided by someone who has a logging bot in here [19:50:00 CET] <AlexQ> JEEB: So in other words, you mean I should mux a few minutes first, then sync audio with e.g. VLC and that apply that shift when muxing the whole thing? [19:50:10 CET] <rainabba> That was my expectation. Been some years but I recall back in the day there were some logging systems, but they weren't part of the IRC network itself and didn't cover all channels; just ones they were setup for. Might have even been efnet (been a while). [19:51:21 CET] <furq> i assume they just use regular clients (or bots) [19:51:43 CET] <furq> maybe some services packages can do it [19:52:02 CET] <rainabba> Can anyone link me to any info about the buffer referred to in my "Input buffer overflow" issue? I can't find anything other than about -bufsize and -rtbufsize which I think are unrelated. [19:52:46 CET] <rainabba> Only found a couple results on Google that even look like a match and they have no useful replies (one mentiones Queue depth, but I have single input). [19:54:43 CET] <AlexQ> JEEB: Wow, that process takes ages. Is it really that computationally expensive, or is muxer just really slow for that kind of tasks? [19:54:59 CET] <rainabba> Unrelated, If I'm encoding h.264 (using x264) and pushing to Wowza, am I better off using mpegts udp:// or flv rtmp:// (if there's even a "better")? [19:57:40 CET] <basisbit> according to https://www.ffmpeg.org/doxygen/2.8/group__libsws.html#gae531c9754c9205d90ad… calling sws_scale from code should not have changed from ffmpeg 2.8 to 3.0 from what I can see. for some reason now after switching to ffmpeg 3.0 I get an exception in swscale-4!sws_getCachedContext. any idea what changes in ffmpeg 3 could have caused that or are there any known issues? (most likely the issue is on my side but I can't find what causes this) [20:00:00 CET] <jkqxz> rainabba: You'll need to offer more information than that, such as complete log output. (The string "input buffer overflow" does not appear anywhere in the ffmpeg source, so your problem might well be some other component.) [20:00:29 CET] <furq> rainabba: depends if you want to use formats which are unsupported by flv [20:00:36 CET] <furq> s/formats/codecs/ [20:03:42 CET] <AlexQ> JEEB: Muxing completed! Finally :D Let's check if it plays in VLC [20:04:42 CET] <rainabba> furg: Ahh. Could be decklink source then perhaps? Mabye time for me to start compiling myself :/ I'll turn out output and pastebin it. As for the Woqza question. The source will be the decklink and I'm looking at using Wowza (also considering bitcodin and Elemental Cloud) to handle the transcoding where it will become h.264/ts/HLS. This will be real-time and with a decent pipe behind it (Some [20:04:42 CET] <rainabba> pretty noteworthy sponsors at a VERY large music festival) [20:07:10 CET] <rainabba> Heh, that was easier than I expected, "[decklink @ 0000020dcfdeca00] Decklink input buffer overrun!" Might also explain why there's so little info out there. I'm guessing there aren't a lot of people doing UHD60 capture on a Decklink card using ffmpeg. :) [20:08:18 CET] <furq> rainabba: fwiw if you've not already paid for wowza then https://github.com/arut/nginx-rtmp-module will do hls [20:08:31 CET] <rainabba> Even on debug there's not much more to be found. Happens when the filesize is betweten ~600MB and ~1.4GB [20:12:11 CET] <rainabba> furq: I have, but that's trivial only $60/mo/server and we only need 1 server per stream at worse) compared to what we're doing so it wouldn't stop me :) Checking that out now. Thank you. For additional information, we're using CloudFront as CDN (Amazon is a direct sponsor) so it's really the transcoding thats primary. [20:21:18 CET] <rainabba> Hmm. Even with 1080p60, I'm hitting that input buffer error, just way further in. [20:23:53 CET] <bencoh> hmm, I've worked with the decklink cards (for the upipe project), and to be honest I never ever thought of using it through ffmpeg [20:25:04 CET] <bencoh> I guess most people use it in some appliance/proprietary software or VLC (for live applications at least) [20:25:31 CET] <rainabba> As best I can tell, this is the project providing decklink support to ffmpeg, but that error doesn't show at all: https://github.com/henriklied/decklink-ffmpeg same for the project it branched from: https://github.com/lu-zero/bmdtools [20:26:21 CET] <rainabba> bencoh: Hmm. VLC for the capture/push to next step in the pipe? [20:26:51 CET] <bencoh> rainabba: you'd need to encode, and VLC isn't really good at live low-latency encoding [20:27:04 CET] <bencoh> but that'd be the idea yeah [20:27:05 CET] <rainabba> I'm basically looking to build an appliance that would handle capture, [stitching for 360,] encoding, then push to a transcoder. [20:27:13 CET] <bencoh> or have a look at upipe if you're into writing code [20:27:55 CET] <rainabba> bencoh: I'm not too concerned with latency. We're looking at minimum 18 seconds thanks to HLS alone and from what I've seen the latency most people are concerned about is in the order of ms (telecommunications). [20:27:56 CET] <bencoh> (I wont advertise for proprietary appliance here but the guys behind upipe might have what you're looking for) [20:28:11 CET] <bencoh> ah, HLS, right. you definitely dont care about latency :D [20:28:15 CET] <rainabba> bencoh: Thanks. Not familiar so I'll check it out. [20:29:06 CET] <Mavrik> Yeah, you should expect latency in terms of seconds not ms [20:29:56 CET] <bencoh> you can reach ~140ms latency with decklink input + h264 intra-refresh/zerolatency settings [20:30:13 CET] <bencoh> (and around 40mbps output stream iirc) [20:30:29 CET] <rainabba> Anyone in the Phoenix area and interested in helping with this? We're a poor startup, but for the right skills, it wouldn't have to be pro-bono :) Me: https://www.linkedin.com/in/rainabba Project: https://vantage.tv No real expectations, but I've seen stranger coincidences along the way. [20:30:33 CET] <Mavrik> Yeah, and then iPhone player buffers 5 seconds :P [20:30:50 CET] <bencoh> Mavrik: yeah, HLS kills it all :) [20:30:55 CET] <Mavrik> Just don't want him to have unrealistic expectations on what players do :) [20:31:43 CET] <rainabba> We're delivering between 1.7Mbps and 28Mbps depending on the source, and device (iPhone chokes arond 12Mbps where my Note4 and Nexus 6P will take 40Mbps without an issue, but start to overheat from GPU (VR environment) after a couple minutes. [20:36:07 CET] <Mavrik> Hmm, that seems like it could be problematic for playback [20:36:17 CET] <Mavrik> Getting a 28Mbps wifi connection on a phone is not really common. [20:36:26 CET] <Mavrik> Check if your users have that. [20:37:26 CET] <rainabba> Mavrik: Hence HLS adaptive :) [20:38:24 CET] <rainabba> I can sustain 150Mbps at home but many will be lucky if they can sustain an average close enough to 3Mbps to be able to stream without buffering. We go as high as we do because 1) We can 2) We are already kicking everyone's ass in the field and want to continue that pattern :) [20:40:37 CET] <rainabba> bencoh: You were referring to https://github.com/cmassiot/upipe ? [20:43:19 CET] <bencoh> rainabba: yup [20:43:42 CET] <Zeranoe> Does the location of -threads 1 matter when forcing FFmpeg to use a single core? Before or after the -i that is [20:44:07 CET] <JEEB> yes [20:44:10 CET] <JEEB> decoding vs encoding [20:44:26 CET] <Zeranoe> thought so [20:52:31 CET] <rainabba> It appears that my output .mp4 isn't written to until ffmpeg is stopped (vs the file growing as encoding happens). Is that the case? Expected? I'd expect that to cause RAM usage to increase over time and I'd think it would make more sense to write as it goes. There a flag that controls that or am I seeing this all wrong to begin with? [20:53:02 CET] <BtbN> mp4 is useless until the final header is written at the end anway [20:53:31 CET] <JEEB> or if you use fragments [20:56:40 CET] <Mavrik> yep, mp4 is not a streamable format really. [20:56:55 CET] <Mavrik> rainabba, don't use mp4 as a format to pass data from encoder to streaming server. [20:59:12 CET] <rainabba> Mavrik: See my question above about pushing to Wowza? I'm doing this right now to figure out my capture, cropping and understand encoding load mostly. Ideally, the transocder in my flow will be independant and handle it, but I need to figure out the best format for that intermediate transfer and admittedly, I'm very new to ffmpeg and anything outside of camera formats and h.264. I'm considering [20:59:12 CET] <rainabba> ffmpeg, Wowza and Elemental Cloud (in that order right now). [21:00:18 CET] <Mavrik> We used ffmpeg that muxed H264/AAC into MPEG-TS and passed it to wowza over UDP [21:00:31 CET] <Mavrik> wowza then remuxed that into MP4 and other crap required for output [21:00:36 CET] <rainabba> cropdetect is only really meant to work on a rectangular image right? I've got a spherical image with lots of black on the sides and would love to auto-detect (different lens shims mean that sphere can be >20px in either direction on the horizontal). [21:01:04 CET] <Mavrik> No idea about cropdetect :/ [21:01:11 CET] <Mavrik> It's not an online algorithm at all afaik. [21:01:40 CET] <rainabba> Mavrik: Other than using FLV/RTMP, that's what I've done so far. MPEGTS is advantageous though? Can you explain why? [21:01:52 CET] <Mavrik> It's a muxing format built for streaming. [21:02:18 CET] <Mavrik> Which MP4 and FLV aren't (they have global headers at start of file without which you cannot playback content. MPEG-TS retransmits that) [21:02:23 CET] <rainabba> I assume I should focus on ensuring GOP matches what I intend to use for the HLS TS chunks? [21:02:30 CET] <Mavrik> RTMP is a very chatty protocol that requires two-way communication. [21:02:40 CET] <rainabba> Mavrik: Good info. Thank you. [21:02:52 CET] <Mavrik> MPEG-TS does have a bit more of the overhead though (it's about 100kbit/s I think) [21:03:06 CET] <Mavrik> But it's good enough for DVB-everything, ATSC and IPTVs ;) [21:03:14 CET] <Mavrik> HLS uses it as it's underlying container as well. [21:03:14 CET] <rainabba> We're likely sending > 8Mbps on the low-end so that's fine with me. [21:03:24 CET] <Mavrik> Wowza will remux it anyway. [21:03:48 CET] <rainabba> Referring to the GOP question? [21:03:53 CET] <rainabba> "remux it anyway" [21:04:01 CET] <rainabba> Or just in general? [21:04:02 CET] <Mavrik> No, you can't fix GOP by remuxing :) [21:04:03 CET] <bencoh> dont they have decklink support (wowza)? [21:04:09 CET] <bencoh> I thought they did [21:04:14 CET] <Mavrik> Since GOP is a property of the video stream / encode. [21:04:27 CET] <Mavrik> And yeah, afaik you must make sure you have an IDR frame when your chunk starts. [21:04:36 CET] <bencoh> yeah, you do [21:04:48 CET] <Mavrik> And some non-iOS devices choke on HLS if the chunks aren't equal over several qualities. [21:04:48 CET] <rainabba> bencoh: To my knowledge, Wowza has zero capture ability natively. [21:04:50 CET] <bencoh> especially since the RFC draft has been superseeded by apple doc [21:05:03 CET] <bencoh> https://developer.apple.com/library/tvos/documentation/General/Reference/HL… [21:06:20 CET] <JEEB> Mavrik: funny enough I haven't noticed that in any of the stuff I've poked. I could just be lucky, but there's stuff that has been running with mismatched GOPs for years [21:06:35 CET] <JEEB> what mostly is an issue with mismatched GOPs are the streaming servers [21:06:42 CET] <JEEB> those are usually really dumb regarding those things [21:06:47 CET] <Mavrik> Asbis STBs and some old Androids with Vivino or what that DRM crap is were sensitive. [21:07:40 CET] <JEEB> oh, STBs. I've only dealt with actual TV sets and mobiles so far. Actual DRM vendors' SDKs are a separate world of pain, yes. [21:07:40 CET] <Mavrik> Granted, not really relevant for everyone :) [21:08:03 CET] <JEEB> and TVs often, too. Thankfully the mobile space at least here seems to be relatively good [21:08:15 CET] <bencoh> *cough*good*cough* [21:08:19 CET] <bencoh> (sorry) [21:08:22 CET] <Mavrik> Also Windows Phones. [21:08:26 CET] <Mavrik> Fuck those :) [21:08:38 CET] <JEEB> but yeah, DRM vendors' demuxing is very bad often [21:08:49 CET] <JEEB> and then the streaming servers that handle the DRM :P [21:08:57 CET] <JEEB> E_CANNOT_STAB_ENOUGH [21:09:04 CET] <bencoh> they're all mostly shit, but some shit works better than others :p [21:09:08 CET] <JEEB> yeah [21:09:58 CET] <JEEB> and because everyone else just dumbs their transcodes down they don't get an incentive to really improve unless someone puts some heat under them. I tried but no idea how successfully :P [21:23:15 CET] <rainabba> Generally speaking, is there a good way to "split/duplicate" a stream? For example, if I wanted to use VLC to monitor locally and also push mpegts/udp to another server? [21:23:51 CET] <rainabba> Definitely think it's time to start compiling myself. Just found unsharp with opencl support :) [21:26:58 CET] <bencoh> rainabba: mpegts+multicat? [21:27:12 CET] <bencoh> multicast* [21:27:22 CET] <bencoh> but you prolly want to have a look at "multicat" too :p [21:27:56 CET] <bencoh> (multicast on lo works quite well) [21:35:25 CET] <nadermx> I have multiple instances of ffmpeg running at a time but when more than a few source urls with large input streams it only converts each of them for about 15 minutes worth and then cuts out. I thought the buffer was set large by default? [21:36:01 CET] <nadermx> I have a many instances of ffmpeg running at a time* [21:37:20 CET] <nadermx> would I have to pass a buffer size sufficiently large for each input stream? [21:43:37 CET] Action: rainabba just had a "moment" with ffmpeg that isn't appropriate for children [21:44:13 CET] <J_Darnley> Please don't abuse the software in that manner. [21:44:21 CET] <rainabba> Capture, upscale, unsharp, crop and encoding without even really taxing CPU and I don't even have OpenCL support yet. This single command does what it's taken us 3 devices costing more than $75k to do previously :) [21:44:24 CET] <J_Darnley> Some of us have to work with it [21:44:25 CET] <J_Darnley> :) [21:44:39 CET] <rainabba> J_Darnley: I will clean the mess and hug you all :) [21:45:10 CET] <rainabba> ... after I setup my build environment so I can get opencl support and ensure my decklink support is as updated as possible (damn input buffer overflow). [21:45:18 CET] <rainabba> Not looking forward to this [21:45:25 CET] <bencoh> underflow*? [21:45:50 CET] <rainabba> Overrun: "[decklink @ 000001aab97acc00] Decklink input buffer overrun!" [21:45:54 CET] <bencoh> ah [21:46:12 CET] <bencoh> hmm btw, can't this come from a clock drift of some kind? [21:46:32 CET] <bencoh> and/or your input not being 60hz while you think it is? [21:46:51 CET] <rainabba> Seems the harder I push ffmpeg, the quicker it happens (UHD almost instantly, 1080p60 with fast encoding and no filters, just keeps going. Move to medium encoding preset and add filters and it takes a bit) [21:46:53 CET] <bencoh> (30000/1001 interlaced for instance) [21:47:20 CET] <bencoh> (or the other way around, it being real interlaced 60hz while you're waiting for 30000/1001) [21:47:34 CET] <rainabba> Input is definitely 1080p59.94 and I'm using "DeckLink 4K Pro@12" though the /1000 vs /1001 isn't clear to me so maybe I'm off there? [21:48:02 CET] <bencoh> 60000/1001 == 59.94 :) [21:48:09 CET] <bencoh> so nevermind [21:49:35 CET] <rainabba> That was my suspicion. Kinda wish I'd been wrong and that's all it was :) [21:49:37 CET] <maco1717> hi, im trying to output to a window "a command" that takes to streams and overlays them sort of picture in picture, I have managed to do the PIP to record to a file, ive looked around and apprently the way to put this to a windows would be namepipe to ffplay? this is the command [21:49:46 CET] <maco1717> ./ffmpeg -i 'rtsp://' -i 'rtsp://' -filter_complex "[1]scale=iw/2:ih/2 [pip]; [0][pip] overlay_w-10:10" pipe:1 Š ./ffplay -i pipe:1 [21:51:00 CET] <maco1717> i get unable to find a suitable output format for pipe:1 pipe:1: invalid argument pipe:: invalid data found when procesin input [21:56:46 CET] <rainabba> Looks like the lower my speed is, the quicker I hit that input buffer error. [21:57:10 CET] <JEEB> since it's a realtime capture thing, not surprising [21:58:28 CET] <JEEB> you should try -q:v 0 -preset ultrafast for initial lossless capture if you can't handle it with whatever you would be doing otherwise [21:58:47 CET] <JEEB> (lossless is the only case where you should be using -q:v with any sane video encoder) [21:59:12 CET] <rainabba> bencoh: "mpegts+multicast" Can I source that multicast to another ffmpeg instance? (Admittedly, I didn't Google first) [22:01:05 CET] <rainabba> JEEB: Where would I take that from there? Also, can I control the buffer being used to buy myself a little margin of error (in some cases, speed is between .9 and 1.1)? The other thing I'm wondering about is why I'd go below speed 1.0x when I've got plenty of CPU, RAM and Disk IO to spare (this machine is a beast and I'm never going over 75% total CPU) [22:01:39 CET] <JEEB> you have a bottleneck somewhere along the way? [22:01:51 CET] <rainabba> I'm doing 1080p60, Preset Medium, high422 just fine until I add the unsharp. [22:01:56 CET] <JEEB> I'd say it's not the encoder if you're using libx264 that's properl built [22:02:22 CET] <JEEB> well yeah, I bet your filtering/possible colorspace conversions take a toll [22:02:52 CET] <JEEB> you should check with -v debug what kind of stuff it does and try to pinpoint where your bottleneck is [22:02:54 CET] <rainabba> Also bm_v210 on source so maybe I ease that and the profile up a bit? [22:03:25 CET] <JEEB> so yeah, you are at the very least doing a colorspace conversion to planar 4:2:2 from that [22:03:37 CET] <JEEB> then you are throwing that into some filter [22:03:46 CET] <bencoh> rainabba: the great thing about multicast is you can have multiple receivers on the same host ;) [22:03:47 CET] <JEEB> then you are passing that to the encode [22:06:07 CET] <rainabba> I think something is off because main and high throw "[libx264 @ 000001f2e2dc7fa0] Error setting profile main" and "[libx264 @ 000001f2e2dc7fa0] Error setting profile high", but high422 works. [22:06:20 CET] <JEEB> those profiles don't support 4:2:2 [22:06:25 CET] <rainabba> Ahh [22:07:13 CET] <rainabba> 4:2:0 only or something else entirely? [22:07:23 CET] <JEEB> 4:2:0 only for those, yes [22:07:37 CET] <JEEB> you don't really have to specify a profile unless you specifically want to [22:07:48 CET] <JEEB> libx264 should select one depending on your input and parameters [22:07:52 CET] <rainabba> Okay [22:08:17 CET] <JEEB> usually it's in cases where you're doing 4:2:0 and want to limit the encoder specifically to some profile [22:08:21 CET] <rainabba> Should I stick with bm_v210 for input from decklink or omit and go with 422 (think that's the default)? [22:08:38 CET] <rainabba> ... or is that entirely a quality question? [22:08:40 CET] <JEEB> v210 is the packed 4:2:2 format [22:09:08 CET] <JEEB> I think it might handled as a video format instead of a colorspace [22:10:27 CET] <rainabba> "If set to @option{true}, video is captured in 10 bit v210 instead of uyvy422. Not all Blackmagic devices support this option." [22:10:34 CET] <rainabba> That clarify? [22:10:45 CET] <JEEB> ok, so they support two forms of packed 4:2:2 [22:11:16 CET] <JEEB> actually not sure which is more optimal with a straight thing to libx264 [22:11:31 CET] <JEEB> you would probably want to bench stuff in a very simple manner [22:11:47 CET] <JEEB> (and making sure how much implicit filtering goes on with -v debug) [22:11:50 CET] <rainabba> Okay. Thanks. How about that buffer question; giving myself some safety margin when speed isn't consistently > 1.0x? [22:12:05 CET] <JEEB> probably quite specific to your capture card where the buffer is [22:12:33 CET] <JEEB> if it's set in libav<whatever that thing is in> or in your actual system/driver [22:13:16 CET] <rainabba> "Clipping frame in rate conversion by 0.000053" Because I'm capturing 59.94 and encoding 60? Can I encode with x264 in 59.94? [22:13:32 CET] <JEEB> of course [22:13:38 CET] <JEEB> it's not frame rate based anyways [22:13:43 CET] <JEEB> it takes in input timestamps :P [22:13:53 CET] <JEEB> https://github.com/FFmpeg/FFmpeg/blob/master/libavdevice/decklink_dec.cpp#L… [22:14:03 CET] <JEEB> seems like the 1GiB limit is set there if that's what you're getting [22:14:37 CET] <rainabba> That's what I thought but I've never seen 59.94 as an option. Googling now. Not seeing anything else with -v debug that looks interesting (aside from a cur_dts message that I think doesn't matter). [22:14:47 CET] <JEEB> uhh [22:14:53 CET] <JEEB> why would it be a special option? [22:15:11 CET] <JEEB> I mean, you get input timestamps and in 99%+ of all cases you just want those timestamps to be used [22:15:16 CET] <rainabba> JEEB: I bet it is, but then it wouldn't matter with mpegts (vs mp4) right? [22:15:24 CET] <JEEB> !? [22:15:40 CET] <JEEB> I don't get what you're basing your assumptions on [22:16:04 CET] <rainabba> I'm not specifying -r right now so I'd think that the 59.94 would just pass through, yet I'm seeing those messages so I need to do something to maintain 59.94 right? [22:16:22 CET] <rainabba> The 1GB assumption is based on anetedotal evidence :) [22:16:34 CET] <rainabba> Nothing more [22:16:49 CET] <JEEB> if you are not specifying -r then no frame rate conversions should happen [22:16:58 CET] <JEEB> unless some filter in your chain requires one [22:17:08 CET] <rainabba> Hmm. [22:17:18 CET] <JEEB> or that message does not mean what you think it does [22:17:33 CET] <JEEB> i have no idea what part of FFmpeg output it [22:17:46 CET] <JEEB> since you cut off the part that says which component output the message [22:18:30 CET] <JEEB> anyways, -v debug always tells you the whole story regarding any filter chains that were done. of course it also spams you with a whole lot of messages because it enables that log level with everything :P [22:18:40 CET] <rainabba> That's the whole line. No prefix. [22:18:59 CET] <JEEB> no [COMPONENT@MEMORY]? [22:19:16 CET] <rainabba> not that I can see. Happy to share more log. [22:19:49 CET] <JEEB> please just share your command line and terminal output in a pastebin-like :P [22:20:22 CET] <JEEB> Most messages that come from inside FFmpeg's libraries come in the form of: [ogg @ 02cd6a60] Page at 3550503 is missing granule [22:20:40 CET] <rainabba> http://pastebin.com/WCUr3fE3 [22:21:00 CET] <bencoh> rainabba: you should be able use with uyvy, unless your decklink card is exotic [22:21:29 CET] <bencoh> (all my SDI/composite cards worked with uyvy) [22:21:47 CET] <bencoh> (afaicr) [22:22:37 CET] <rainabba> bencoh: That's effectively 422 no? How do I specify that? [22:23:12 CET] <bencoh> I've never ever used this ffmpeg-decklink patch, you know :p [22:23:19 CET] <rainabba> :) [22:23:23 CET] <rainabba> Me either [22:23:36 CET] <JEEB> ok, so v210 is handled as a "decoder" which then converts to yuv422p10le as its "output", and then for unsharp it gets converted to yuv422p [22:23:38 CET] <bencoh> I've only used decklink cards with VLC and through the libDecklink API ;p [22:23:54 CET] <bencoh> s/and/or/ [22:23:59 CET] <JEEB> so that explains why the unsharp makes it slower [22:24:05 CET] <JEEB> not only are you adding filtering [22:24:15 CET] <JEEB> but you are also adding another format conversion [22:24:23 CET] <bencoh> is that kierank's v210 decoder? [22:24:35 CET] <JEEB> not fully sure, but I'd guess so? [22:25:21 CET] <JEEB> actually no [22:25:35 CET] <JEEB> the copyrights on the file are mini and baptiste [22:26:12 CET] <JEEB> kierank did add V210 SIMD tho [22:26:38 CET] <bencoh> ah, I prolly only had the optim in mind [22:26:57 CET] <rainabba> [Without v210], this hits 35-40% CPU and 1.1-1.2x speed: ./ffmpeg -f decklink -i 'DeckLink 4K Pro@12' -vf "crop=1412:1080:254:0, unsharp=luma_msize_x=5:luma_msize_y=5:luma_amount=1.5" -vcodec libx264 -preset:v fast -level 4.2 1080p60_fast_unsharp.mp4 [22:27:01 CET] <bencoh> (I think he wrote a full decoder at some point though, but maybe he never merged it) [22:27:22 CET] <JEEB> probably for his own project? [22:27:24 CET] <JEEB> no idea [22:27:27 CET] <rainabba> While this uses ~25% CPU: ./ffmpeg -f decklink -i 'DeckLink 4K Pro@12' -vf "crop=1412:1080:254:0" -vcodec libx264 -preset:v fast -level 4.2 1080p60_fast.mp4 [22:27:31 CET] <bencoh> maybe yeah [22:27:43 CET] <rainabba> So the unsharp is still heavy. To be expected? [22:27:51 CET] <JEEB> yes, random filters are heavy [22:27:55 CET] <rainabba> k [22:28:00 CET] <JEEB> do not use them unless you specifically need them [22:28:08 CET] <JEEB> minimize the bottlenecks between input and encoding [22:28:11 CET] <bencoh> rainabba: do you really need unsharp? [22:28:23 CET] <JEEB> after that your problems will become encoder and output I/O :P [22:28:25 CET] <bencoh> (I know "sharp" content can be pretty tough to encode, but...) [22:28:38 CET] <rainabba> For our application, it's a significant improvement. More valuable that 20% increase in bandwidth or resolution. [22:29:30 CET] <JEEB> but yeah, without v210 you should now see that it should only be unpacking the 4:2:2 [22:29:37 CET] <JEEB> not doing bit depth conversions (hopefully) [22:29:45 CET] <rainabba> Any chance you were at Lollapalooze or Austin City Limits last year and visited the Samsung Activation? We were the ones streaming VR for them :) I'm off to Auckland NZ for the 1st Auckland City Limits in less than a week and come back to Coachella next. [22:29:46 CET] <JEEB> when you look at the filter chain [22:31:02 CET] <rainabba> Tryin to read those now to check [22:31:36 CET] <rainabba> This covers it? " Stream #0:1, 1, 1/1000000: Video: rawvideo, 1 reference frame (UYVY / 0x59565955), uyvy422, 1920x1080, 1001/60000, -10 kb/s, 59.94 tbr, 1000k tbn, 59.94 tbc" [22:31:46 CET] <JEEB> that tells you the input [22:31:55 CET] <bencoh> do filters all run in the same thread or is there some threading/queueing support in libavfilter nowadays? [22:32:05 CET] <JEEB> I have no idea, libavfilter is a damn mess [22:32:23 CET] <bencoh> I was under that impression too last time I had to deal with it [22:32:54 CET] <bencoh> but having queues between threaded filters might help in his case [22:33:04 CET] <JEEB> yeah [22:33:42 CET] <JEEB> rainabba: what you want to read into is the stuff after the parameter parsing by libavfilter (the Parsed_crop and Parsed_whatever) [22:33:43 CET] <rainabba> JEEB: That shows "yuv422p" now instead of "yuv422p10le" so that confirms right, or is there something more specific to the filter I should look for? [22:34:03 CET] <JEEB> after that it should be listing the filter graph iti builds for you [22:34:06 CET] <JEEB> within libavfilter [22:34:42 CET] <JEEB> rainabba: that just means you're getting 8bit YCbCr instead of 10bit, which can be better off if the conversions or filters for it are quirecker [22:34:44 CET] <rainabba> This? [auto-inserted scaler 0 @ 000002745c52dba0] w:1412 h:1080 fmt:yuv422p10le sar:0/1 -> w:1412 h:1080 fmt:yuv422p sar:0/1 flags:0x4 [22:35:12 CET] <JEEB> that means that the filter chain decided to convert to 8bit from 10bit at some point, yes [22:35:14 CET] <bencoh> hmm [22:35:50 CET] <rainabba> JEEB: That's the most significant log entry in light of the conversion you pointed out? [22:35:55 CET] <bencoh> why would you still have fmt:yuv422p10le in the chain? [22:36:06 CET] <bencoh> if you moved to uyvy? [22:36:16 CET] <JEEB> he probably was looking at an old log? [22:36:20 CET] <rainabba> yep [22:36:58 CET] <rainabba> Here's the new one: http://pastebin.com/gBvVpZZE [22:38:18 CET] <rainabba> Okay, between my want to play with opencl, NVENC and QSV along with that buffer (potentially), I need another build (for windows). Can you guys recommend one? If not, best compiling guide you can suggest? [22:38:57 CET] <rainabba> For that matter, is the opinion still that NVENC and QSV produce garbage in light of the benefits or have them improved? [22:42:23 CET] <JEEB> compiling with msys2's mingw-w64 environment should be relatively easy [22:42:34 CET] <JEEB> so I recommend that over random builds [22:42:48 CET] <rainabba> ty [22:42:49 CET] <JEEB> not to mention that you usually only need a couple of dependencies [22:43:14 CET] <JEEB> the GPU-based ASIC things are only good if you absolutely can't handle stuff otherwise [22:43:27 CET] <JEEB> or if you are just not giving a darn about quality and have way underpowered CPUs [22:43:41 CET] <JEEB> (at which point I am not sure if you have stuck your money into the wrong place) [22:44:08 CET] <JEEB> opencl can be "fun" because you have to take into mention that data has to be pushed onto the GPU and then put back [22:44:13 CET] <JEEB> keep that in mind [22:44:24 CET] <JEEB> latency n' all [22:44:27 CET] <rainabba> I need https://msys2.github.io/ and http://mingw-w64.org/doku.php then code and in theory, nothing more? (have 3 version of VS installed already) [22:44:44 CET] <JEEB> msys2 should already package 32bit and 64bit mingw-w64 packaged [22:45:02 CET] <JEEB> so installing the toolchains from its package management is most probably going to be the path of least resistance [22:45:34 CET] <rainabba> So just install msys2 and use it to provide any other dependencies for the toolchain? [22:45:57 CET] <JEEB> I am not sure about that, but you should be able to grab yasm and basic building tools with it [22:46:07 CET] <bencoh> you can have a look at win-builds.org too [22:46:11 CET] <rainabba> JEEB: What about pure CPU vs QSV, same conclusion? [22:46:19 CET] <JEEB> pretty much [22:47:03 CET] <rainabba> bencoh: That instead of msys2? [22:48:00 CET] <bencoh> if you feel the need for some "easy" windows buildenv installation on linux [22:48:25 CET] <rainabba> I'm live-streaming 1080p60 with unsharp right now at 60% CPU so that's not too bad. Might not hold up to the UHD stuff though so I don't think even an 8-core would make me feel safe. Other CPU considerations that might buy me more capacity? Not afraid to invest in CPU if that's the way to go. [22:48:37 CET] <rainabba> bencoh: Ahh [22:48:54 CET] <rainabba> I'd prefer to build on Windows, but that's good to know. [22:50:08 CET] <bencoh> are those real 8cores, or hyperthreading? [22:50:15 CET] <rainabba> Hmm. Getting a couple rows of macro-blocks that are freaking out :/ [22:50:40 CET] <rainabba> bencoh: I've got a real 6-core now and can get 8. Is hyperthreading any good with encoding? [22:50:53 CET] <bencoh> absolutely not :) [22:51:34 CET] <rainabba> Figured :) [22:51:53 CET] <rainabba> Does it make things worse, or just not help? [22:52:06 CET] <bencoh> YMMV [22:52:20 CET] <rainabba> gotcha [22:52:53 CET] <bencoh> in my case it helped a bit with other processes running on the server [22:53:48 CET] <rainabba> The unsharp filter supports opencl when it's enabled, that should help (offloading to opencl) right? [22:59:11 CET] <JEEB> not necessarily [22:59:15 CET] <JEEB> opencl is not a magic bullet [22:59:22 CET] <JEEB> as I noted, it has its latencies etc [22:59:35 CET] <JEEB> also I wouldn't be surprised if the opencl filters were just POCs [23:00:27 CET] <JEEB> also I definitely recommend looking at your bottlenecks before thinking of more cores [23:00:41 CET] <JEEB> more cores don't help jack shit if you can't utilize them [23:04:52 CET] <rainabba> I've got HT on right now (with a real 6-core) and have the load down to around 40%. I'm under the impression that x264 will use more threads if they're there which would bring the load down more (allowing perhaps a 2nd stream of the same). No? [23:05:38 CET] <JEEB> I think at this point libx264 is the least of your issues, esp. if you're doing thread-per-picture threading instead of slice-based threading [23:06:28 CET] <JEEB> that can utilize your stuff pretty well up until I think 80 samples in height? I really don't remember the threading limitations in libx264 with picture-based threads [23:06:31 CET] <rainabba> Trying to figure out the "splitting" idea with UDP, but I think I'm missing a networking concept here. If I use: "-f mpegts -muxrate 12000k udp://192.168.10.10:5501?pkt_size=1316C", then I should be able to hit the same address on that machine as an input to then push to another machine, or do transcodes and such right? [23:07:31 CET] <bencoh> when in auto threads mode x264 spawns a number of threads based on the number of cpu threads available [23:07:41 CET] <JEEB> yes [23:07:45 CET] <bencoh> enabling HT would roughly double that value [23:07:46 CET] <JEEB> *3/2 [23:07:52 CET] <JEEB> is the algo [23:08:07 CET] <bencoh> but as JEEB said it's not your issue right now [23:08:08 CET] <JEEB> for logical cores (as opposed to physical) [23:08:14 CET] <jookiyaya> does ffmpeg still has: libfdk_aac, libvo_aacenc [23:08:32 CET] <JEEB> I think vo_aacenc was removed as it's way worse than the libavcodec one by now [23:08:45 CET] <jookiyaya> what is libavcodec [23:08:59 CET] <jookiyaya> according to ffempg it has aac, libfaac, libfdk_aac, libvo_aacenc [23:09:01 CET] <rainabba> JEEB: Okay. That's a bit over my head still. You mentioned bottlenecks before cores. Based on that log, can you suggest more I can do to identify/reduce bottlenecks? I assume you don't mean RAM/IO (which shouldn't be an issue right now with my 32GB DDR4, Quad-Channel and Samsung Pro 950 nvme) [23:09:02 CET] <JEEB> the library in FFmpeg that handles video/audio/subtitle encoding and decoding [23:09:17 CET] <JEEB> jookiyaya: it's the "aac" one [23:09:27 CET] <JEEB> that's ffaac which is the libavcodec internal one [23:09:41 CET] <JEEB> vo_aacenc was removed lately due to the reasons I mentioned [23:09:56 CET] <JEEB> fdk_aacenc can still be used, but it's probably only useful if you require HE-AAC [23:09:57 CET] <jookiyaya> you just gave me 2 different answers [23:10:19 CET] <JEEB> no, I did not [23:10:26 CET] <JEEB> I am just detailing my replies :P [23:10:43 CET] <bencoh> jookiyaya: ffac == default aac, libfaac is a wrapper around the FAAC project [23:10:58 CET] <JEEB> which was also removed I think [23:10:59 CET] <JEEB> lately [23:11:12 CET] <JEEB> because only the internal one and the fdk_aac one are worth using at this point [23:11:16 CET] <jookiyaya> is libavcodec = libfaac ? [23:11:19 CET] <JEEB> no [23:11:35 CET] <JEEB> libavcodec is a part of FFmpeg that contains video/audio/subtitle decoders and encoders (and their wrappers) [23:12:23 CET] <JEEB> the "lib" somethings are libavcodec things that use a separate library in the background, otherwise it's a thing that is internal to libavcodec and doesn't require 3rd party libraries to work [23:12:50 CET] <jookiyaya> okay let's start over; how many different aac encoder is in ffmpeg now? [23:13:29 CET] <bencoh> git pull && find libavcodec -iname "*aac*" ? :) [23:13:48 CET] <ethe> two, the native one and libfdk-aac [23:13:48 CET] <bencoh> but JEEB pretty much answered your question now [23:13:52 CET] <jookiyaya> C:\> git pull && find libavcodec -iname "*aac*" [23:13:52 CET] <jookiyaya> 'git' is not recognized as an internal or external command, [23:13:52 CET] <jookiyaya> operable program or batch file. [23:14:02 CET] <JEEB> in FFmpeg itself without 3rd party libraries there's one [23:14:05 CET] <bencoh> ah, windows, nevermind :p [23:14:11 CET] <JEEB> there is also one that is based on 3rd party library, fdk-aac [23:14:14 CET] <JEEB> as I noted [23:14:44 CET] <jookiyaya> i thought ffmpeg removed fdk-aac [23:14:49 CET] <jookiyaya> due to licensing issue [23:15:00 CET] <JEEB> no, it just made it usable only if you made your binary non-distributable [23:15:19 CET] <rainabba> I'm seeing nasty artifacts that stick around for a while (until motion occurs?). What might that be about? [23:15:59 CET] <JEEB> the license incompatibility means that you cannot distribute the binary and have both licenses be OK [23:16:00 CET] <ethe> jookiyaya: there are patents in the code, but libfdk-aac is released as open source [23:16:09 CET] <JEEB> the patents have nothing to do with it [23:16:40 CET] <JEEB> it's with the license specifically noting that you have to do some things to be able to distribute binaries, among other things [23:16:59 CET] <JEEB> FFmpeg has never cared about patents as such, otherwise we would not have DCA or Dolby formats' decoders [23:17:07 CET] <ethe> "The license states that the library may only be distributed as authorized by patent licenses" [23:17:18 CET] <JEEB> yes, that is a *license* issue [23:17:26 CET] <JEEB> not a *patent* issue [23:17:27 CET] <ethe> yeah, my bad [23:17:29 CET] <JEEB> two different things [23:17:37 CET] <jookiyaya> i don't fdk anymore when i do ffmpeg.exe -encoders [23:17:49 CET] <JEEB> that's because you built without it [23:18:02 CET] <jookiyaya> i didn't do anything [23:18:19 CET] <JEEB> if it's a random binary from somewhere near a road then it most probably is built without it [23:18:29 CET] <JEEB> because building with fdk-aac makes the binary non-distributable, as I said [23:18:36 CET] <JEEB> you have to set --enable-nonfree [23:18:45 CET] <JEEB> (and have the fdk-aac libraries around when building) [23:19:18 CET] <JEEB> that said, if you are using a new enough FFmpeg and don't need HE-AAC you can just use the internal aac encoder [23:19:38 CET] <JEEB> fdk-aac's main good point at this point is HE-AAC support, which the intenral encoder doesn't yet support [23:19:55 CET] <jookiyaya> internal aac encoder = aac or faac ? [23:20:18 CET] <JEEB> internal stuff is often called ffSOMETHING, but fSOMETHING is a different thing [23:20:41 CET] <rainabba> Reducing GOP makes the issues go away much more quickly so it seems like bad B frames somehow. [23:20:44 CET] <JEEB> faac is another library that also was found to be non-distributable [23:20:57 CET] <jookiyaya> jeeb since when [23:21:18 CET] <JEEB> I think it was found that it was using reference code licensed under a non-compatible license in around 2011 or so? [23:21:24 CET] <jookiyaya> i see [23:21:27 CET] <JEEB> after which it was put under --enable-nonfree [23:21:50 CET] <jookiyaya> so ffmpeg removed 3 aac encoders libvo_aacenc, fdk and faac [23:21:55 CET] <JEEB> uhh, no [23:22:04 CET] <JEEB> at most only vo_aacnenc and faac were removed [23:22:14 CET] <JEEB> all of those three are wrappers around 3rd party libraries [23:22:41 CET] <JEEB> (also libaacplus was also removed because fdk-aac supports HE-AAC well enough) [23:22:47 CET] <JEEB> (and both are nonfree) [23:23:52 CET] <JEEB> so now you can build FFmpeg with the following AAC encoders: internal (ffaac, shows up as just 'aac'), and libfdk_aac (requires the 3rd party library and --enable-nonfree, making that FFmpeg build[4~ nondistributable) [23:24:15 CET] <jookiyaya> i see [23:24:55 CET] <jookiyaya> so you cannot include faac anymore even if you build it yourself with --enable-nonfree [23:25:15 CET] <JEEB> no, it is now worse than both fdk-aac and the internal aac encoder anyways [23:25:19 CET] <JEEB> so there is no reason to have it [23:25:26 CET] <JEEB> same with vo_aacenc and libaacplus [23:25:43 CET] <jookiyaya> i see [23:25:48 CET] <JEEB> if there is an alternative that does things better, why leave the worse things in there :P [23:26:11 CET] <JEEB> if you are only going to be encoding LC-AAC then you are fine with just the internal one [23:26:18 CET] <JEEB> since it's much better than it used to be [23:26:38 CET] <jookiyaya> according to ffmpeg site: libopus > libvorbis >= libfdk_aac > aac > libmp3lame >= libfaac >= eac3/ac3 > libtwolame > vorbis > mp2 > wmav2/wmav1 [23:26:56 CET] <JEEB> that is rather random [23:27:02 CET] <jookiyaya> sorry [23:27:03 CET] <furq> is anyone else getting a sense of déjà vu [23:27:12 CET] <jookiyaya> they didn't include libvo_aacenc in that ranking list [23:27:23 CET] <JEEB> because it's stereo only and shit [23:27:35 CET] <JEEB> even before the major improvements the internal one was better off [23:27:56 CET] <JEEB> it was only taken in because it was interesting at the time it was pushed to android [23:28:03 CET] <JEEB> but google also noticed it was shit [23:28:09 CET] <JEEB> so it was there only for less than a year I think [23:28:13 CET] <jookiyaya> what does google use now then [23:28:13 CET] <JEEB> replaced by fdk-aac [23:28:58 CET] <JEEB> anyways, I've now noted a couple of times under which cases you want fdk-aac [23:29:07 CET] <jookiyaya> if libopus is so great, how come nobody uses it [23:29:08 CET] <JEEB> which is if you want HE-AAC encoding [23:29:28 CET] <jookiyaya> i see [23:29:43 CET] <jookiyaya> and when does someone wants to use he-aac encoding method? [23:29:51 CET] <JEEB> when you want to go under 64kbps [23:29:58 CET] <jookiyaya> i see [23:30:20 CET] <AlexQ> 64 per channel or per 2 channels? [23:30:29 CET] <JEEB> for stereo [23:30:32 CET] <jookiyaya> alexq good question [23:31:37 CET] <JEEB> but really, you should know if you are doing encoding like that :P [23:31:44 CET] <JEEB> base your ffmpeg build on your requirements [23:31:45 CET] <jookiyaya> i am surprised that ffmpeg support wma? i thought wma is closed [23:32:03 CET] <JEEB> that encoder is shit, but exists because someone cared to implement it [23:32:11 CET] <JEEB> it's still shit because nobody really cares [23:32:35 CET] <jookiyaya> but how did they manage to include closed source encoder [23:32:40 CET] <JEEB> they didn't [23:32:49 CET] <JEEB> they looked at how the format works by looking at references [23:32:56 CET] <JEEB> and implemented accordingly [23:33:05 CET] <jookiyaya> so it's not even real [23:33:22 CET] <JEEB> as long as it creates the format it is "real" [23:33:26 CET] <JEEB> or decodes it correctly [23:33:34 CET] <JEEB> that's as real as it gets [23:33:40 CET] <jookiyaya> ok [23:34:05 CET] <jookiyaya> what do you think about the author putting opus as #1 [23:34:13 CET] <jookiyaya> is that bias? [23:34:41 CET] <JEEB> it's a random list. opus is really good and if you can use it with lossy encoding, you should [23:34:51 CET] <JEEB> if you can't due to hw decoding etc [23:34:57 CET] <JEEB> then that's a limitation of your use case [23:35:12 CET] <JEEB> there's a reason why European Broadcasting Union got opus standardized in broadcast [23:35:20 CET] <jookiyaya> i have yet to seen a single opus encoded file [23:35:34 CET] <jookiyaya> jeeb how recent? [23:35:35 CET] <furq> do you not use youtube [23:35:45 CET] <jookiyaya> furq huh? [23:35:53 CET] <jookiyaya> i use youtube [23:35:56 CET] <JEEB> youtube has pretty much all of its stuff available as opus [23:36:00 CET] <furq> then you've heard plenty of opus encoded files [23:36:07 CET] <jookiyaya> i see [23:36:16 CET] <JEEB> you get fed either avc+aac or vp8+vorbis or vp9+opus [23:36:33 CET] <JEEB> dpeending on the profile and other things [23:36:33 CET] <jookiyaya> why no avc+opus [23:36:45 CET] <JEEB> because they don't mish-mash them for whatever reason, ask them rather than us :P [23:36:47 CET] <bencoh> because google bought on2 [23:36:53 CET] <bencoh> :> [23:37:15 CET] <jookiyaya> bencoh i see, but didn't know vp and opus came as package [23:37:29 CET] <jookiyaya> i thought they are 2 competely different [23:37:36 CET] <furq> because webm can't contain avc and mp4 can't contain opus [23:37:44 CET] <furq> not that it particularly matters now that they're serving ts over dash [23:37:54 CET] <furq> but they still serve mp4 or webm over http to non-dash clients [23:37:55 CET] <JEEB> yeah, but they are not limited to that due to using MSE for higher profiles anyways [23:37:58 CET] <jookiyaya> does flv container support opus? [23:38:02 CET] <furq> no [23:38:14 CET] <jookiyaya> then how are they able to use opus [23:38:16 CET] <JEEB> flv is completely adobe-specific and even adobe has given up on it [23:38:21 CET] <furq> because they don't use flv? [23:38:25 CET] <JEEB> 'tube hasn't used FLV for a while [23:38:28 CET] <furq> because it's not 2008 [23:38:41 CET] <JEEB> go check what profiles youtube-dl lists for you [23:38:46 CET] <JEEB> when you post a random link into it [23:38:59 CET] <jookiyaya> if you cannot use flv or mp4 then what can you use opus with [23:39:21 CET] <JEEB> mpeg-ts, matroska, OGG and raw bit streams as far as I know. [23:39:25 CET] <JEEB> mp4 is coming [23:39:27 CET] <furq> you forgot webm [23:39:33 CET] <JEEB> webm is a matroska subset [23:39:38 CET] <jookiyaya> webm = container ? [23:39:40 CET] <JEEB> so it is included there [23:39:58 CET] <jookiyaya> i have never seen videofilename.webm [23:40:27 CET] <furq> well then you must look harder [23:40:38 CET] <JEEB> the most popular user of such specific files is 4chan, but without seeing the file names youtube is probably the biggest user [23:41:08 CET] <furq> yeah that's really going to sell him on using it [23:41:18 CET] <JEEB> I don't give a flying fuck [23:41:29 CET] <JEEB> if he can't use it due to device limitations he wouldn't use it anyways [23:42:26 CET] <furq> well this is at least the third run at this exact conversation [23:42:36 CET] <furq> although to be fair we have at least made it past "why can't i use fdk" this time [23:42:50 CET] <jookiyaya> i tried to download webm youtube site: it saves as .flv [23:43:11 CET] <JEEB> then it saves it like that no matter what the data is [23:43:21 CET] <jookiyaya> it should save as .webm [23:43:31 CET] <furq> are you downloading it from l33tkrewyoutubeconvert.ru or something [23:43:31 CET] <jookiyaya> i am confused [23:43:40 CET] <JEEB> just use youtube-dl to list the profiles for fuck's sake https://rg3.github.io/youtube-dl/download.html [23:43:48 CET] <JEEB> that should tell you all the available video and audio profiles [23:44:02 CET] <furq> the only flv format still available on youtube is h.263 and mp3 [23:44:08 CET] <jookiyaya> somebody from firefox gave me a click thing to convert youtube video to webm javascript:if(!location.hash)location.href=location.href+'&webm=1&html5=1';else{location.href=location.href.substr(0,(location.href.length-location.hash.length))+'&webm=1&html5=1'+location.hash} [23:44:14 CET] <jookiyaya> #firefox [23:44:54 CET] <furq> well then it's shit [23:44:59 CET] <furq> otherwise it wouldn't be saving flv [23:45:24 CET] <JEEB> I don't give a fuck if it was jesus who gave you enlightenment, right now the least retarded tool for looking at what youtube can serve you is youtube-dl [23:46:13 CET] <JEEB> youtube-dl -F "your-url" [23:46:16 CET] <JEEB> lists all formats [23:46:32 CET] <jookiyaya> i see [23:47:18 CET] <furq> even if that bookmarklet works then i assume it'll download the http webm which is vp8+vorbis anyway [23:47:20 CET] <JEEB> example http://up-cat.net/p/39f8900f [23:47:43 CET] <jookiyaya> furq how did you know it was bookmarklet [23:48:24 CET] <JEEB> not sure if it discerns the opus/vorbis correctly or this video just didn't hit youtube's random decision algorithms regarding opus [23:49:03 CET] <jookiyaya> so many different format show up when i use that command [23:49:19 CET] <jookiyaya> even 3gp [23:49:20 CET] <JEEB> http://up-cat.net/p/68a1219d [23:49:32 CET] <JEEB> yes, it lists literally everything youtube can offer :P [23:49:43 CET] <JEEB> they have all kinds of weird crap for very old mobile devices and such [23:49:44 CET] <furq> did you just trick me into clicking on a totalbiscuit video [23:49:46 CET] <furq> that's pretty low [23:49:53 CET] <JEEB> that one had opus [23:50:25 CET] <jookiyaya> wow google must think opus is better than aac [23:50:40 CET] <JEEB> fuck if I know [23:50:42 CET] <jookiyaya> too bad mp4 container doesn't support it [23:50:53 CET] <JEEB> well I know it's being worked upon [23:51:05 CET] <JEEB> although even if it is standardized you still have to have things implement it [23:51:25 CET] <JEEB> https://vfrmaniac.fushizen.eu/contents/opus_in_isobmff.html [23:51:29 CET] <JEEB> this is the draft [23:51:29 CET] <jookiyaya> or why don't they just make mkv the standard [23:51:51 CET] <JEEB> they are trying to standardize that one, but it's a crapshoot that never had a specification for the past 12 years [23:52:11 CET] <JEEB> if ISOBMFF is fucked, then Matroska is even more fucked [23:52:34 CET] <jookiyaya> what is isobmff ? [23:52:40 CET] <JEEB> what you call mp4 [23:52:51 CET] <JEEB> ISO Base Media File Format [23:53:15 CET] <jookiyaya> ok [23:54:01 CET] <jookiyaya> google is pushing for vp9 but h265 is better [23:54:26 CET] <furq> better how [23:54:51 CET] <jookiyaya> smaller size for equal quality [23:56:37 CET] <galex-713> Hi, I heard ffmpeg and libavconv merged again ^^ how did it happen? [23:56:50 CET] <J_Darnley> That's news to me [23:57:28 CET] <furq> i heard that elvis is still alive and he works at burger lord [23:57:38 CET] <galex-713> ? [23:59:12 CET] <jookiyaya> galex-713 what is libavconv ? [00:00:00 CET] --- Mon Mar 7 2016

1 0