Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

March 2016

1 participants
62 discussions

ffmpeg-devel.log.20160305
by burek 06 Mar '16

06 Mar '16

[00:02:17 CET] <Gramner> in general it's largely dependant on the function. you can get 20-50% even in non-optimal cases (e.g. when you don't have blocks that are 32 bytes wide). on the other hand, sometimes anything above mmx is pointless performance-wise [00:04:00 CET] <Timothy_Gu> Gramner: I'm asking since I recently wrote an SSE2 version of a MMX function, but the SSE2 version is not any faster, even though data are properly aligned etc. [00:04:14 CET] <Timothy_Gu> and I'm imagining that AVX2 is the same situation [00:04:59 CET] <Gramner> it's generally not worth it if you need to spend tons of time shuffling the data into the registers [00:05:25 CET] <JEEB> AVX2 has the funny part of lowering the speed of the CPU so your AVX2 functions really have to be quicker than the alternative for them to be useful [00:05:36 CET] <BtbN> time for 8 2MB registers! [00:05:56 CET] <Gramner> also ymm registers have the additional concept of 128-bit lanes where cross-lane instructions are slow as hell [00:06:42 CET] <JEEB> BtbN: reminds me of that one broadwell that could use its own iGPU "VRAM" as a very large l4 cache [00:06:53 CET] <JEEB> so you had 128MiB of cache [00:07:02 CET] <BtbN> actual VRAM? [00:07:07 CET] <BtbN> Or just the reserved RAM portion? [00:07:21 CET] <JEEB> actual memory on the CPU [00:07:31 CET] <BtbN> Interesting, wasn't aware Intel hat that. [00:07:34 CET] <BtbN> *had [00:08:24 CET] <Gramner> JEEB: ymm registers also have a warm-up time (on skylake at least) where it's powergated and takes a while to spin up [00:08:39 CET] <Timothy_Gu> Gramner: what are "lanes" [00:08:48 CET] <Gramner> and if you don't use any ymm registers for a few million cycles it's powergated again [00:09:06 CET] <Gramner> so you can end up in a situation where it turns on and off all the time and kills performance [00:09:33 CET] <JEEB> BtbN: I think the 5775C is the first and last such desktop chip we'll see in a while :) [00:10:32 CET] <Gramner> Timothy_Gu: basically the lower 128-bit and upper 128-bit of the register are separate lanes (they essentially copy&pasted two 128-bit simd pipelines to create a 256-bit one) and moving data between those lanes is bad [00:10:53 CET] <Timothy_Gu> So it's not actually one register, but two SSE ones... [00:11:19 CET] <nevcairiel> kinda, you just get twice as many and have to use them in pairs =p [00:12:06 CET] <Gramner> but an instruction takes the same amount of time (with some exceptions) on 128-bit and 256-bit, so you can process twice as much data in the same time [00:12:06 CET] <nevcairiel> i hope avx512 isnt the same again with 4 lanes, is it [00:12:18 CET] <Gramner> oh yes [00:12:21 CET] <Gramner> it is [00:12:25 CET] <Timothy_Gu> Gramner: ok [00:12:34 CET] <Gramner> but there's also more useful shuffles to deal with it [00:12:44 CET] <nevcairiel> well avx512 has another advantage, it actually gives you more xmm regs as well! [00:13:34 CET] <Gramner> avx-512 has various minor improvements all over the place so it can be useful even if you don't use the wider registers [00:14:12 CET] <Timothy_Gu> is AVX-512 going to be available on consumer hardware anytime soon? [00:14:22 CET] <atomnuker> nope, not until late next year [00:14:23 CET] <nevcairiel> for varying definitions of soon [00:14:25 CET] <Gramner> ~h2'17 [00:14:47 CET] <Timothy_Gu> So right now it's only on Xeon Phi... [00:15:06 CET] <Gramner> xeon phi only has a limited subset of avx-512 compared to what the xeons will get [00:15:09 CET] <nevcairiel> no, skylake xeons have it [00:15:16 CET] <nevcairiel> are those available yet? [00:15:23 CET] <nevcairiel> i thought the first ones would ship by now [00:15:54 CET] <Gramner> released? don't think so. engineering samples widely available with the right contacts [00:16:41 CET] <nevcairiel> didnt i read q4'15 somewhere [00:17:05 CET] <Gramner> no, it's always been 2016 iirc [00:18:46 CET] <llogan> why the "g" prefix in the short hash in version output? i assume it stands for "git", but i never thought that as informative [00:19:09 CET] <llogan> and it seems to confusers. [00:19:37 CET] <rcombs> http://www.newegg.com/Product/Product.aspx?Item=N82E16819117617 you mean these things? [00:19:55 CET] <Timothy_Gu> llogan: it's just part of the syntax [00:19:57 CET] <Gramner> no [00:19:57 CET] <nevcairiel> I don't think the E3s have AVX2 [00:20:03 CET] <nevcairiel> AVX512* [00:20:05 CET] <Timothy_Gu> llogan: blame Git [00:20:07 CET] <Gramner> E3 xeons are rebadged consumer cpus [00:20:19 CET] <nevcairiel> llogan: git decided to do that a long time ago [00:20:26 CET] <nevcairiel> also, users will be confused no matter [00:20:30 CET] <rcombs> meh [00:20:31 CET] <Gramner> E5 and E7 xeons (and skylake-E which are rebadged xeons) will have it [00:21:03 CET] <llogan> ah, ok. i guess i would have noticed that if i wasn't too lazy to look at version.sh. [00:21:12 CET] <rcombs> (also I'm having some hilarious issues trying to test QSV on that CPU) [00:21:36 CET] <rcombs> libva opens /dev/dri/renderD128 and then the process hangs in such a way that even SIGKILL does nothing [00:21:38 CET] <Timothy_Gu> llogan: what do you think about the versioning scheme? [00:21:59 CET] <nevcairiel> rcombs: qsv seems universally terrible, it hangs on windows for me as well more often than not [00:22:18 CET] <rcombs> nevcairiel: does it usually hang in the `open()` syscall, though? [00:22:24 CET] <rcombs> seems like a driver issue [00:22:38 CET] <nevcairiel> for me usually in some qsv call, which also seems like a driver issue =p [00:22:51 CET] <wm4> rcombs: what do you still need qsv on linux for? [00:23:20 CET] <rcombs> wm4: well any libva operation [00:23:33 CET] <rcombs> since opening the device hangs [00:23:37 CET] <wm4> with the glorious impeding vaapi patches (which are held back by eternal refactoring) [00:23:40 CET] <llogan> Timothy_Gu: i didn't look at that topic yet [00:24:02 CET] <Timothy_Gu> llogan: http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-March/190815.html [00:24:03 CET] <wm4> (maybe we should just have applied them in ffmpeg...) [00:24:38 CET] <llogan> Timothy_Gu: i have the emails. just still at work and not motivated yet. [00:24:42 CET] <Timothy_Gu> ah [00:25:08 CET] <Timothy_Gu> we don't have school today so I keep forgetting it's a Friday [00:36:49 CET] <Gramner> qsv is interesting, it's allegedly possible to access lower-level qsv hardware features through L3 cache and not-too-bad latency but it was all hush-hush NDA territory. not sure how useful that could potentially be [00:38:54 CET] <jkqxz> wm4: Eternal refactoring is eternal indeed. (Version eleven hopefully sometime tomorrow, if I don't run into too much more Intel driver flakiness.) [00:58:40 CET] <rcombs> Gramner: huh, interesting [01:51:04 CET] <cone-962> ffmpeg 03Michael Niedermayer 07master:dec816f92c7c: avcodec/utils: Fix memleak on error in convert_sub_to_old_ass_form() [02:05:23 CET] <cone-962> ffmpeg 03Michael Niedermayer 07master:b3dc51dd571f: avfilter/f_bench: Fix comparission condition [02:16:22 CET] <Daemon404> old-ass form... lol [02:16:24 CET] Action: Daemon404 sleep [03:13:21 CET] <llogan> damn. someone gave me incorrect start and end times for these analog tapes. 00:09:00 is not 00:00:09! i'll do it myself. [03:55:31 CET] <Compn> Timothy_Gu : you know carl does a majority of the bug reports on trac right ? :P [03:55:46 CET] <Timothy_Gu> Compn: yes why? [03:58:36 CET] <Compn> well you asked about his opinion on version.sh in ffmpeg output [03:58:55 CET] <Compn> i just wanted to make sure you understood that he deals with ffmpeg version line every day :P [04:01:18 CET] <Compn> also i think it was my idea for the version to have a linear revision number back when we were talking about switching to git [04:01:27 CET] <Compn> so this, is , in the end, all of my fault, yet again. :) [04:23:53 CET] <Compn> Timothy_Gu : so feel free to blame me for the N-rev tag. because i wanted a rev tag like svn had lol [04:24:41 CET] <Compn> Timothy_Gu : also thanks for working on it. changing default stuff always gets a lot of flames [04:25:59 CET] <Timothy_Gu> Compn: well I did propose to add the linear tag back... [04:26:19 CET] <Timothy_Gu> Can't really see what other complaint he would have [04:27:49 CET] <Compn> i only read half of the thread. so i'm not really sure what everyone wants. thats why i sent a reply put it up to a vote :P [04:40:58 CET] <cone-962> ffmpeg 03James Almer 07master:a3659ca0148a: avcodec/cos_tablegen: extend table generation to 17bits [04:50:57 CET] <ashish247> Hey [04:52:10 CET] <ashish247> Can anyone explain what exactly we have to do in create fuzzing testsuite [04:53:31 CET] <Compn> didnt you ask that yesterday ashish247 ? ehe [04:53:44 CET] <Compn> representing 962,204 lines of code <~~~ are we going to have a party when we reach 1 million LOC ? [04:54:15 CET] <Compn> Timothy_Gu : ashish247 is back to ask another question of you, assuming you are still alive ^ [04:54:21 CET] <ashish247> I am askimg what we have to do.... I know its a software technique [04:54:23 CET] <Compn> or kierank [04:54:55 CET] <ashish247> Software testing* [04:55:56 CET] <Timothy_Gu> Compn: we are already past one million [04:56:04 CET] <Timothy_Gu> ~/ffmpeg$ git diff --shortstat `git hash-object -t tree /dev/null` 5641 files changed, 1371043 insertions(+) [04:57:03 CET] <Timothy_Gu> ashish247: well exactly what's written on the wiki page [04:57:13 CET] <Timothy_Gu> ashish247: is there a point you don't understand [05:00:13 CET] <Compn> Timothy_Gu : probably not including documentation (and possibly ohloh's stats are old) [05:00:25 CET] <Compn> but thanks for the info. [05:00:30 CET] <Timothy_Gu> Compn: excluding doc/ it's 1302929 [05:00:48 CET] <Compn> ah neat then. [05:06:26 CET] <Compn> hmm lou isnt here to bug. who to bug... [05:06:49 CET] <Compn> wm4 : why do we link to a $10 / $30 book on our documentation page? http://ffmpeg.org/documentation.html [05:09:35 CET] <Compn> oh ok 10% donation thing [05:09:39 CET] <Compn> https://ffmpeg.org/pipermail/ffmpeg-devel/2013-January/137643.html [05:09:53 CET] <Compn> michaelni : ^^ hows this going ? did we recieve any donations from person? [05:16:29 CET] <mark4o> Timothy_Gu: sloccount says 961059 source lines of code [05:16:48 CET] <Timothy_Gu> mark4o: that's probably because I counted empty lines too [05:16:57 CET] <mark4o> it excludes blank lines, comment lines, files that aren't source code, etc. [05:17:30 CET] <Timothy_Gu> yeah figured [06:16:53 CET] <jamrial> frame_size [06:17:12 CET] <jamrial> whoops [06:49:56 CET] <tyagi221295> Hi, i am new to ffmpeg i want to apply for gsoc. [06:51:01 CET] <tyagi221295> i found TrueHD encoder project interesting. [06:51:29 CET] <durandal_1707> Contact mentor [06:52:15 CET] <tyagi221295> atomnuker: i saw your project on the idea page. [06:52:38 CET] <tyagi221295> i want to work on it. [06:56:52 CET] <tyagi221295> durandal_1701:Improve and Cleanup Swscale project can you help me to get started. [07:05:31 CET] <tyagi221295> durandal_1701: i previously work for gnome,sympy,python software foundation and made some significant contribution. [07:06:13 CET] <tyagi221295> in gnome i made significant contribution in gnome-music. [07:11:57 CET] <durandal_1707> why do you got last number wrong? [07:14:24 CET] <durandal_1707> tyagi221295: what you do for gnome-music? [07:15:39 CET] <tyagi221295> sorry for that. [07:17:04 CET] <tyagi221295> in gnome music i fixed duplicate playlist problem on creating new playlist first time. [07:17:36 CET] <tyagi221295> render favourite song behaviour for songs from database. [07:18:03 CET] <tyagi221295> in gnome-maps i implemented a round-about support. [07:18:43 CET] <tyagi221295> that is turning angle when there is round about in the routes. [07:18:59 CET] <durandal_1707> for swscale you would first need to get ffmpeg compiled and running [07:19:51 CET] <tyagi221295> durandal_1707: does anyone already working on this idea?? [07:20:21 CET] <durandal_1707> I don't think so [07:21:48 CET] <tyagi221295> durandal_1707: i will get back to you once i set up my code running. [07:27:05 CET] <Timothy_Gu> durandal_1707: does "1707" have any special meaning? [07:27:33 CET] <durandal_1707> yes, very [07:28:16 CET] <tyagi221295> durandal_1707: let me guess [07:29:01 CET] <tyagi221295> i think its your bday 17th july. [07:30:30 CET] <durandal_1707> haha, not even close [07:31:26 CET] <Shiz> it means he was born in 1707 [07:31:31 CET] <Shiz> he's actually 308 years old [07:38:12 CET] <tyagi221295> durandal_1707: i am following tutorial for building ffmpeg from here http://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu is it fine?? [07:39:25 CET] <durandal_1707> Should be [07:47:23 CET] <Timothy_Gu> so mysterious [08:10:22 CET] <tyagi221295> durandal_1707: compilation done :) [08:12:32 CET] <durandal_1707> you could now experiment with scale filter and explore swscale code, what time are you? [08:13:26 CET] <yashpatel> Hello people, I'm new here. [08:14:13 CET] <yashpatel> I'm looking forward to work on FFv1 P frame support project [08:14:29 CET] <yashpatel> I've cloned the repository and have built it [08:14:46 CET] <yashpatel> can anyone help me in getting started with the qualification task ? [08:16:06 CET] <yashpatel> I'm currently following the documentation on 'https://github.com/FFmpeg/FFV1/blob/master/ffv1.md' [08:16:43 CET] <yashpatel> PS : I'm an undergraduate student and researcher working in Computer Vision and Machine Learning [08:20:09 CET] <yashpatel> seems like someone is already working on that project ? [08:21:57 CET] <tyagi221295> durandal_1707: what about qualification task?? [08:30:22 CET] <durandal_1707> tyagi221295: wait for michaelni [08:33:22 CET] <tyagi221295> he is also a mentor of the project. [09:15:42 CET] <michaelni> <Compn> michaelni : ^^ hows this going ? did we recieve any donations from person? <-- i dont know [09:19:24 CET] <tyagi221295> michaelni: i am interseted in a project Motion interpolation in libavfilter. [09:19:36 CET] <yashpatel> michaelni: [09:20:21 CET] <yashpatel> michaelni: can you please let me know if the qualification task of FFv1 P frame support is already assigned to someone ? [09:20:35 CET] <yashpatel> michaelni: I'm looking forward to work on this project [09:20:36 CET] <michaelni> tyagi221295, for "Motion interpolation in libavfilter." durandal_1707 is the mentor [09:21:10 CET] <tyagi221295> durandal_1707: can you please assign me the task. [09:21:27 CET] <satinder___> Hi , With ffmpeg is that possible extract h.264 data in raw format and write it on a v4l2 video node for continue playing [09:22:07 CET] <michaelni> yashpatel, seems so, but theres an alternative qual task you can do [09:22:12 CET] <satinder___> with a ticker overlay [09:22:41 CET] <michaelni> also the taken qualification tasks are listed here: https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016-Qualis [09:22:43 CET] <satinder___> I am able to extract data but not able to write it in a node [09:22:51 CET] <satinder___> any one please help [09:23:25 CET] <michaelni> please anyone who does a qual task add ourself to that page -> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016-Qualis, also if someone stops working on a qua task please remove yourself [09:26:02 CET] <durandal_1707> tyagi221295: why you haven't picked swscale task? [09:27:30 CET] <durandal_1707> tyagi221295: the lavfi interpolation have already qualification task [09:28:01 CET] <durandal_1707> so you do what is in qual task [09:28:20 CET] <yashpatel> michaelni: I'm starting to work towards the alternative task "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" as stated in the ideas page. Do I need to make appropriate changes to 'qual-task' page ? [09:28:29 CET] <durandal_1707> ask questions if you need something [09:30:45 CET] <tyagi221295> so why the name of the applicants listed on the tasks. [09:30:47 CET] <durandal_1707> yashpatel: you can [09:31:17 CET] <durandal_1707> tyagi221295: what task? [09:31:29 CET] <yashpatel> durandal_1707: Thanks! ffmpeg seems so cool :D [09:31:52 CET] <tyagi221295> Basic but working motion estimation filter. [09:32:14 CET] <tyagi221295> as i see this is a task written on the page. [09:33:07 CET] <tyagi221295> and some of the project tasks already have applicants names on https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016-Qualis. [09:34:35 CET] <durandal_1707> tyagi221295: its there but nobody confirmed to work on it [09:36:04 CET] <tyagi221295> durandal_1707: i am ready to work on it. [09:38:29 CET] <durandal_1707> yashpatel: you sure removing another student from list is right thing? [09:39:37 CET] <durandal_1707> tyagi221295: then start working, you need to complete task to be accepted for project [09:40:13 CET] <durandal_1707> if something is not obvious ask [09:46:41 CET] <benjaminst> hi, can anybodoy say something to the vdpau filter qualy task? It's still TBA. [09:53:27 CET] <michaelni> benjaminst, contact the mentor for the "vdpau filter" project [09:54:42 CET] <benjaminst> ok, thanks [09:58:16 CET] <satinder___> Hi how I can write frame in buffer [09:58:24 CET] <satinder___> I getting following error [09:58:36 CET] <satinder___> [h264 @ 0xb64680] illegal short term buffer state detected [09:58:43 CET] <satinder___> please anybody help [10:17:12 CET] <cone-436> ffmpeg 03Clément BSsch 07master:0443b2cf790f: lavc: restore ABI compatibility with 3.x (sub_text_format) [10:34:50 CET] <yashpatel> durandal_1707: I'm working on the alternative qualification task. How to fit in both names ? Shall, I put two names/dates/task in each slot ? [10:36:36 CET] <durandal_1707> yashpatel: nevcairiel fixed it [10:36:50 CET] <yashpatel> Yes, I just noticed. Thank you. [11:56:27 CET] <satinder___> Hi how I get frame from video stream but I don't know I can write it on node [11:56:36 CET] <satinder___> please any body help ?? [12:29:18 CET] <ethe> err, do asm macro args start at %1? [12:35:11 CET] <nevcairiel> ethe: yes [12:46:38 CET] <ethe> and what are variableq variables which looks like they're created from the cglobal macro [12:50:42 CET] <nevcairiel> the d/q are size specifiers [12:51:12 CET] <nevcairiel> you can find the documentation of those in x86inc.asm [13:07:11 CET] <wm4> nevcairiel: is there still any dumb grunt work to do in the codecpar branch? [13:07:25 CET] <nevcairiel> sure, fix all the formats libav doesnt have [13:09:04 CET] <wm4> is there an overly convenient list of them? [13:09:26 CET] <nevcairiel> nah [13:09:50 CET] <nevcairiel> i've just been compiling libavformat.a and ctrl+c'ing when a wall of warnings appears, fixing, and resuming =p [13:11:45 CET] <wm4> nobody on etherpad [13:11:47 CET] <JEEB> hmm, just did make -j4 and "libavcodec/x86/h264_deblock_10bit.o: No such file or directory", seems like it tried to create libavcodec.a before it should have [13:20:02 CET] <nevcairiel> if you are on windows with mingw, that could've been caused by the faulty mkstemp causing binutils issues =p [13:20:44 CET] <JEEB> yeah, that could be it [14:09:38 CET] <Fyr> I already hear how cehoyos is typing that this is not a bug, but a feature. [15:24:43 CET] <JEEB> wm4: in which place the demuxer should set the delay field? although I bet it could break o9k assumptions around the code [15:25:33 CET] <wm4> AVCodecContext.delay [15:25:41 CET] <wm4> and whatever it is with the new codecpar stuff [15:25:41 CET] <JEEB> cheers [15:25:52 CET] <wm4> and then ffmpeg.c needs to learn to respect it [15:25:56 CET] <JEEB> :D [15:25:58 CET] <JEEB> of course [15:26:00 CET] <wm4> at least that's how I do things now [15:26:08 CET] <wm4> (made shit work with lavf mkv and opus) [15:26:43 CET] <JEEB> so in addition to negative timestamps you also need the delay, or otherwise it will just take the timestamps as a timeline that starts on the negative side? [15:27:47 CET] <wm4> maybe [15:27:54 CET] <wm4> I don't know what ffmpeg.c does [15:30:35 CET] <JEEB> yeah... ffmpeg.c is ffmpeg.c [15:48:29 CET] <satinder___> hi [15:48:35 CET] <satinder___> any body there [15:48:36 CET] <satinder___> ?? [15:48:56 CET] <satinder___> what i can do in this case [15:49:11 CET] <satinder___> I have following warning : warning: avpicture_fill is deprecated [15:49:25 CET] <nevcairiel> you want #ffmpeg instead [15:49:40 CET] <satinder___> how I can use av_image_fill_arrays [15:50:20 CET] <satinder___> I have no idea about uint8_t * dst_data[4], int dst_linesize[4] [15:50:43 CET] <satinder___> why the size of dst_data is 4 [15:51:21 CET] <satinder___> please anybody help [15:51:33 CET] <nevcairiel> this is not a help channel, go to #ffmpeg [15:52:11 CET] <satinder___> nevcairiel : but there have no body which can help about ffmpeg api [15:52:20 CET] <nevcairiel> then wait [15:52:23 CET] <nevcairiel> this is not a help channel [15:52:23 CET] <satinder___> ok [15:54:54 CET] <J_Darnley> Since you haven't asked I'm not surprised nobody can help you. [16:00:22 CET] <nevcairiel> you make nice progress, doing all these no-effort replacements, and then you find something like ffmdec.c which makes you want to kill yourself right here and now [16:02:19 CET] <wm4> lol [16:02:33 CET] <wm4> when do we kill ffserver [16:02:46 CET] <nevcairiel> its literally impossible to support ffmenc/ffmdec in the new model [16:03:06 CET] <nevcairiel> unless you require its users to violate the API and keep using st->codec as long as its available =p [16:03:47 CET] <wm4> does using the deprecated field work as makeshift solution? [16:08:11 CET] <nevcairiel> who knows, i have no clue how this ffserver thing even pretends to work [16:08:21 CET] <nevcairiel> or why it needs 100 properties from avcodeccontext [16:08:56 CET] <wm4> doesn't it copy/receive all fields from network [16:09:16 CET] <wm4> anyway, force those who want to keep ffserver to do this work [16:09:21 CET] <wm4> or remove it after a deadline [16:09:51 CET] <nevcairiel> forcing doesnt work, they will just moan and bitch and we wont get anything done [16:10:24 CET] <wm4> well either we get work done and they moan, or neither of both [16:11:08 CET] <nevcairiel> and like i said, its literally impossible, since demuxers and mxuers just dont have any access to this data [16:11:11 CET] <nevcairiel> nor are they supposed to [16:11:50 CET] <jamrial> sierravmd.c shows up as fixed on the etherpad but it's not [16:12:13 CET] <nevcairiel> i'm just going through everything alphabetically now, s would show up sooner or later [16:12:15 CET] <nevcairiel> at j now! [16:12:27 CET] <wm4> jamrial: ah that's my color, I can fix that if needed [16:14:33 CET] <wm4> pushed [16:15:01 CET] <wm4> maybe I can look at alsa and x11 lavd [16:15:17 CET] <nevcairiel> they look rather trivial, i just cant even compile them so [16:16:02 CET] <wm4> why do we still have x11grab etc [16:30:06 CET] <wm4> I'm going to look at libavdevice: lavfi, opengl, v4l, sdl, xv [16:30:11 CET] <wm4> since I can compile them [16:30:55 CET] <debianuser> wm4: "why do we still have x11grab" - is there another modern alternatives to capture a screencast? [16:31:04 CET] <wm4> debianuser: there's xcbgrab [16:31:10 CET] <wm4> which is the same thing, just using xcb [16:31:25 CET] <debianuser> ah, it uses more CPU sometimes. [16:31:53 CET] <debianuser> I.e. I could get a higher framerate with x11grab compared to xcbgrab. [16:31:55 CET] <wm4> then that should maybe fixed or xcb removed again, but not keep both [16:34:03 CET] <debianuser> It's just sometimes it was lower CPU... [16:35:34 CET] <debianuser> The trick is that they use CPU differently. If I remember correctly x11grab uses more CPU in ffmpeg, but Xorg server uses less CPU, while xcbgrab requires higher Xorg CPU usage with lower ffmpeg CPU. So depending on whether your Xorg server is doing anything else (besides capturing a video for ffmpeg) you may need one way or another. [16:36:00 CET] <nevcairiel> why does that matter, overall cpu use should be similar then [16:38:16 CET] <debianuser> If your Xorg server is loaded with some other graphical stuff then x11grab gives higher fps. But if Xorg is mostly idle and fps is limited just by ffmpeg's slow 0RGB->YUV conversion - then xcbgrab gives higher fps. [16:38:38 CET] <wm4> that's not a difference in x11 and xcb, but how they use x11 [16:39:45 CET] <debianuser> (and on single-core laptops x11grab may be faster too, not sure, never tested) [16:41:35 CET] <wm4> nevcairiel: is the problem with mux.c is that there are a lot of deprecations in there? or did I miss something bigger [16:41:56 CET] <nevcairiel> i didnt look, just that it still warns a lot, if the code is intentional, then the warnings should be disabled around it [16:42:24 CET] <wm4> well I'm not sure what to do with that; they're basically checking API usage [16:42:33 CET] <wm4> should probably go through a proper review [16:44:13 CET] <`md> is opening h264/ac3/ts/http a non supported case for ffmpeg? [16:44:45 CET] <wm4> `md: #ffmpeg [16:45:37 CET] <`md> right [17:19:13 CET] <nevcairiel> so many raw subtitle formats [17:42:34 CET] <Compn> what do you mean raw [18:07:32 CET] <ethe> how can I test if my changes to lpc.c break anything? [18:09:15 CET] <jamrial> encode some flac files [18:09:40 CET] <Fyr> are those multithreaded changes? [18:09:49 CET] <jamrial> using whatever lpc algorithm you changed [18:17:34 CET] <atomnuker> aac also uses lpc [18:18:22 CET] <Fyr> yeah, ethe, break everything. [18:20:58 CET] <Fyr> after a while we will find out that lossless is not really lossless if it's converted with FFMPEG. =) [18:22:24 CET] <ethe> ffmpeg -i in.wav out.aac, out.aac is 40 seconds longer than in.wav :/ [18:22:38 CET] <Fyr> ((= [18:22:49 CET] <Fyr> alright, regression is your friend. =) [18:23:35 CET] <ethe> although, mpv ends playing when it's supposed to end [18:23:52 CET] <Fyr> maybe, this is connected with ffmpeg's delay when converting into WAV. [18:24:23 CET] <Fyr> everything is longer in WAV if it's converted with ffmpeg. [18:24:27 CET] <Fyr> =) [18:24:41 CET] <ethe> but, 40 seconds? and it's at the end I think (also, it's shorter in wav) [18:25:14 CET] <Fyr> nothing is impossible when it comes to bugs. [18:26:18 CET] <satinder___> Hi I am able write data in .ppm but I want write it on a file [18:26:27 CET] <satinder___> please anybody help me [18:37:07 CET] <nevcairiel> satinder___: we told you hours ago, for support go to #ffmpeg [18:41:41 CET] <JEEB> ethe: have you tried running fate? [18:42:05 CET] <JEEB> ethe: https://ffmpeg.org/fate.html [18:42:40 CET] <JEEB> fate-rsync will grab the samples that it tests against [18:42:47 CET] <JEEB> and make fate will then run the FATE tests [18:43:47 CET] <ethe> JEEB: I havent, but I'm going to try writing it again, because I'm pretty sure I made some significant errors [18:44:00 CET] <cone-935> ffmpeg 03Mats Peterson 07master:698fdc85478f: lavf/riffenc: Handle palette for non-raw codecs [18:44:00 CET] <cone-935> ffmpeg 03Mats Peterson 07master:2df0bbaca5ab: lavf/avienc: Add support for palette side data [18:44:00 CET] <cone-935> ffmpeg 03Michael Niedermayer 07master:76019f5fed06: fate: Add pal8 copy test for avi [18:44:00 CET] <cone-935> ffmpeg 03Michael Niedermayer 07master:e0f5f9267a8b: avformat/avienc: assert that bits_per_coded_sample is within the supported range (out of array access otherwise) [18:44:25 CET] <JEEB> running FATE is in general a good idea, esp. if you're touching something touching a lot of stuff [19:11:33 CET] <ubitux> who tried to do microdvdenc? [19:12:01 CET] <ubitux> nevcairiel? [19:12:48 CET] <ubitux> nevcairiel: microdvd is {frame_id_start}{frame_id_end} [19:12:56 CET] <ubitux> using avg_frame_rate might work [19:13:34 CET] <wm4> shouldn't it just use AVStream.time_base? [19:14:17 CET] <ubitux> it actually needs the framerate of the video stream so... [19:14:36 CET] <wm4> that's up to the API user to get right [19:14:42 CET] <ubitux> yep [19:14:47 CET] <ubitux> so what is the user going to set? [19:15:31 CET] <ubitux> my nobrainer says he will use -r as output option [19:15:53 CET] <ubitux> no idea which field this is going to be set [19:16:28 CET] <ubitux> there is a microdvd test in fate, but no such option set, maybe i should add one at some point [19:16:42 CET] <ubitux> not that i want to encourage people to produce microdvd files [19:16:55 CET] <wm4> then remove the muxer [19:17:15 CET] <wm4> (who in their right mind would produce such files anyway, and with ffmpeg) [19:17:36 CET] <ubitux> maybe someone willing to have frame accurate subtitles [19:17:49 CET] <nevcairiel> ubitux: i figured either stream tb or avgframerate would work, but it smelt funny [19:17:50 CET] <wm4> lol [19:17:57 CET] <nevcairiel> especially since our muxer doesnt write the frame rate to the file [19:18:06 CET] <nevcairiel> while the demuxer reads it [19:18:07 CET] <nevcairiel> so.. [19:18:07 CET] <nevcairiel> :D [19:18:12 CET] <ubitux> the pts are frame ids [19:18:27 CET] <ubitux> basically. [19:18:44 CET] <ubitux> but yeah the demuxer faces the issue the other way around [19:18:58 CET] <nevcairiel> well apparently there is a hacky way to code the fps [19:19:14 CET] <ubitux> yep [19:19:22 CET] <ubitux> first event or sth [19:19:32 CET] <nevcairiel> but why not use time is the real question [19:19:35 CET] <nevcairiel> but oh well :D [19:19:37 CET] <ubitux> samples in the wild actually use that [19:19:38 CET] <wm4> I don't know why anyone would use a format that has the highest chance of getting completely mistimed for "frame accurate" subtitles [19:20:00 CET] <ubitux> wm4: well it's not surprise it's not that much in use anymore [19:20:12 CET] <nevcairiel> its 16 years old, back then it probably wasnt that bad [19:20:18 CET] <nevcairiel> in relative terms [19:20:19 CET] <ubitux> collateral damage being that the microdvd tags ended up in srt files [19:20:29 CET] <ubitux> thx to "converting" perl scripts [19:21:58 CET] <nevcairiel> anyone feel like doing tee.c [19:22:00 CET] <nevcairiel> i feel lazy [19:25:48 CET] <jamrial> nevcairiel: that one doesn't look easy. tons of fields not available in avcodecparameters [19:26:06 CET] <jamrial> poke nicolas, he's the author [19:28:35 CET] <wm4> doesn't it just need to copy the codecpar [19:28:36 CET] <jamrial> mmh, my bad, those are avstream fields [19:29:11 CET] <nevcairiel> the only annoying this is that it uses bsf [19:29:12 CET] <ubitux> btw, i just fixed build, if we want to start testing (if that's possible) [19:29:18 CET] <nevcairiel> which needs an avctx [19:29:42 CET] <wm4> oh right [19:29:59 CET] <nevcairiel> (new bsf api doesnt, btw) [19:30:54 CET] <jamrial> can't you just pass the AVStreamInternal avctx like with other muxers? at least for now [19:31:05 CET] <nevcairiel> thats what i did in concatdec [19:31:10 CET] <nevcairiel> but no clue if it works properly [19:31:23 CET] <jamrial> we'll know soon enough :p [19:32:28 CET] <nevcairiel> ubitux: so if you fixed build, you already did wtfenc then? [19:32:35 CET] <nevcairiel> wtvenc* [19:32:44 CET] <ubitux> not, just fixed one call [19:32:59 CET] <ubitux> that is, build [19:33:00 CET] <nevcairiel> i'll do it fully then [19:34:43 CET] <jamrial> nevcairiel: i can push tee fixed using the internal avctx if you agree, at least to get it building so we can test [19:35:50 CET] <nevcairiel> sure [19:35:59 CET] <nevcairiel> i'll finish going through all remaining components in avformat [19:36:02 CET] <nevcairiel> only 10 or so left [19:38:55 CET] <nevcairiel> pushed the remaining ones [19:39:12 CET] <nevcairiel> did someone actually fix the lavfi avdevice huh? [19:39:56 CET] <Daemon404> it seems like it wasnt even on the list [19:39:57 CET] <wm4> I think so [19:40:08 CET] <Daemon404> oh ti was [19:40:15 CET] <nevcairiel> Daemon404: well your list was only conflicts, does libav even have that [19:40:35 CET] <Daemon404> doubtful [19:41:03 CET] <Daemon404> ugh... what is ffm again [19:41:09 CET] <nevcairiel> ffserver [19:41:11 CET] <nevcairiel> have fun. [19:41:11 CET] <nevcairiel> :D [19:41:21 CET] <Daemon404> rm -rf ffserver.c [19:41:26 CET] <Daemon404> who uses it and to what end [19:41:27 CET] <Daemon404> and why [19:41:39 CET] <nevcairiel> no idea [19:41:41 CET] <kierank> carl will complain [19:41:43 CET] <kierank> fuck calr [19:41:45 CET] <kierank> carl [19:41:54 CET] <nevcairiel> all i know is that the new api made it entirely impossible to be implemented like it is today [19:41:57 CET] <Daemon404> you can say its a feature, but what does this feature *do* [19:42:03 CET] <Daemon404> nevcairiel, it doesnt use public api only [19:42:05 CET] <ubitux> - grep ffserver.c MAINTAINERS [19:42:07 CET] <ubitux> ffserver.c Reynaldo H. Verdejo Pinochet [19:42:08 CET] <Daemon404> it still uses internal crap [19:42:11 CET] <ubitux> ask him to fix it [19:42:13 CET] <nevcairiel> Daemon404: even ffmdec.c in avformat [19:42:15 CET] <nevcairiel> not just ffserver.c [19:42:20 CET] <Daemon404> ubitux, he still has TODO for not using internal stuff in it [19:42:24 CET] <Daemon404> that he promised hed fix [19:42:42 CET] <Daemon404> nevcairiel, so is ffm literally a "format" to "work" with ffserver? [19:43:00 CET] <nevcairiel> its a format to literally serialize an entire avcodeccontext [19:43:09 CET] <nevcairiel> like, everything [19:43:11 CET] <Daemon404> ... [19:43:29 CET] <Daemon404> brb going to go rub glass shards into my skull [19:43:32 CET] <Daemon404> because that sounds saner than ffm [19:44:32 CET] <jamrial> rm ffserver. then add a note somewhere saying anyone interested to adapt it and maintain it is very welcome to [19:44:38 CET] <Daemon404> many have tried [19:44:41 CET] <Daemon404> none have succeeded [19:45:00 CET] <nevcairiel> lets see what happens now when i try to run any ffmpeg command [19:45:31 CET] <wm4> maintain some distance or the explosion will get you [19:46:14 CET] <jamrial> ffmpeg_opt.c and ffmpeg_filter.c seem to use avstream.codec [19:46:20 CET] <nevcairiel> thats ok [19:46:24 CET] <nevcairiel> the CLI stuff gets fixed later [19:46:40 CET] <nevcairiel> afterall, it should be backwards compatible to callers [19:47:18 CET] <jamrial> ./ffmpeg -i random.wav -> segmentation fault [19:47:19 CET] <jamrial> :D [19:47:50 CET] <nevcairiel> fucking source test is taking ages, it didnt use to be this incredible slow [20:00:05 CET] <nevcairiel> pushed the fix for the always-crash [20:14:00 CET] <nevcairiel> something odd is going on, some of the options in the fate scripts are no longer reaching the encoders [20:15:36 CET] <Daemon404> O_o [20:15:59 CET] <nevcairiel> ie. this test fails because it encodes with the wrong audio bitrate [20:16:01 CET] <Daemon404> are we setting them on the stream codec contexts because we know were usin them [20:16:04 CET] <Daemon404> or something [20:16:17 CET] <nevcairiel> even then that should technically still work, i think [20:17:53 CET] <Daemon404> valgrind and see if some weird acesses are happening? [20:17:57 CET] <Daemon404> it's always the first thing i do [20:18:03 CET] <nevcairiel> cant valgrind =p [20:18:07 CET] <Daemon404> orite windows [20:18:24 CET] <jamrial> -c:a is not working [20:18:28 CET] <jamrial> for output stream [20:18:38 CET] <nevcairiel> all sorts of options dont seem to be working [20:19:34 CET] <nevcairiel> i wonder if its because of avformat_match_stream_specifier [20:19:40 CET] <nevcairiel> it uses codecpar now like it should [20:19:45 CET] <nevcairiel> but what if the caller didnt fill codecpar [20:19:52 CET] <nevcairiel> for output streams [20:21:16 CET] <nevcairiel> hm how to best approach this [20:21:23 CET] <nevcairiel> it could just fill codecpar if it detects this [20:21:29 CET] <nevcairiel> and ..unfill it after? [20:24:37 CET] <cone-935> ffmpeg 03Paul B Mahol 07master:f3c00be2a3dd: avfilter/vf_waveform: only use available components [20:24:53 CET] <omerjerk> Can anyone explain the int k in this function - https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/alsdec.c#L477 [20:25:10 CET] <omerjerk> I read about rice codes at various places, but not able to make sense of it. [20:25:40 CET] <Fyr> ((= [20:28:05 CET] <JEEB> ALS was a part of the MPEG-4 Audio spec, right? (Part 3, I think?) [20:29:18 CET] <omerjerk> yes. [20:30:19 CET] <JEEB> I hope you have a copy of that on hand :) [20:30:40 CET] <Daemon404> the concept of rice coding isnt specific to ALS though [20:30:44 CET] <JEEB> yeah [20:30:55 CET] <JEEB> just noting in general [20:32:23 CET] <omerjerk> I have it. [20:33:24 CET] <JEEB> so it reads a unary marked by zeroes (up to max) and then depending on whether or not we're limiting our reading (? the k var) a bit is either read or picked from the negation of the lowermost bit of the unary [20:36:23 CET] <nevcairiel> well this turned ugly quick [20:36:25 CET] <nevcairiel> but it works [20:36:59 CET] <nevcairiel> better ideas for the latest commit welcome [20:41:04 CET] <jamrial> nevcairiel: it doesn't compile here [20:41:07 CET] <nevcairiel> mov seems broken, but i think wm4 expected that [20:41:27 CET] <jamrial> it's the disable deprecation warning stuff it seems [20:44:45 CET] <nevcairiel> i'm building with msvc right now for better debugging, feel free to just fix it if its broken somewhere else [20:48:03 CET] <Daemon404> nevcairiel, am i misunderstanding in thinking avformat_match_stream_specifier will asplode on us once the api is removed [20:48:17 CET] <nevcairiel> should work with both now [20:48:35 CET] <nevcairiel> its just very ugly now [20:48:36 CET] <nevcairiel> :D [20:48:41 CET] <wm4> why is that function even in the lib [20:48:47 CET] <wm4> seems like a ffmpeg.c thing [20:49:09 CET] <nevcairiel> it is, but it does seem to have some kind of value for anyone that would maybe want to implement cli stream selection [20:49:27 CET] <nevcairiel> in any case, pointless to ask, we have to fix it anyway [20:49:51 CET] <nevcairiel> the logic of that function isnt too bad [20:50:00 CET] <nevcairiel> it just got ugly with the deprecation checks [20:56:05 CET] <jamrial> nevcairiel: done [20:57:50 CET] <nevcairiel> i suppose the macros in the middle of an if expression wasnt very nice [20:58:32 CET] <jamrial> gcc definitely didn't like it :p [20:59:01 CET] <Daemon404> why would gcc care [20:59:04 CET] <Daemon404> it runs cpp on it [21:00:02 CET] <nevcairiel> well the result of the macro =p [21:01:25 CET] <nevcairiel> squashing that mess will be fun btw, a whole bunch of commits that should remain separate and be re-ordered before the big one :D [21:02:59 CET] <Daemon404> reordering is two keystrokes [21:03:08 CET] <Daemon404> git rebase -i is great at it [21:03:19 CET] <Daemon404> mind you.. the sheer volume [21:03:38 CET] <Daemon404> i'll probably start a new branch and cherry pick those [21:03:50 CET] <nevcairiel> thats probably best [21:04:01 CET] <nevcairiel> there is also one or two fixes for one of the two preparation commits [21:06:11 CET] <Daemon404> probably gonna take a fair amount of time to sort through 100-200 commits [21:06:13 CET] <Daemon404> <_< [21:16:09 CET] <carpediem_> Hi [21:16:25 CET] <carpediem_> I have been trying to crash ffmpeg using zzuf [21:16:34 CET] <carpediem_> the qualification test for GSOC project [21:16:47 CET] <carpediem_> Its a bit hard... as I expected :D [21:17:04 CET] <carpediem_> Just a question, how will I know FFmpeg has crashed? [21:19:52 CET] <thardin> check $? [21:20:24 CET] <thardin> exit code that is [21:20:39 CET] <Daemon404> assuming it is scripted. [21:20:58 CET] <carpediem_> so far the exit code I have got is "Error while decoding stream...." [21:21:16 CET] <carpediem_> And this really seems like a (stable) good exit [21:21:26 CET] <Daemon404> crashes will have an exit code that is greater than 127 [21:21:33 CET] <Daemon404> if you are on linux [21:21:43 CET] <carpediem_> yes i am on linux [21:21:51 CET] <carpediem_> where is the exit code? [21:22:08 CET] <carpediem_> Example: Error while decoding stream #0:0: Invalid data found when processing input zzuf[s=0,r=0:0.05]: signal 9 (memory exceeded?) [21:22:27 CET] <carpediem_> 'signal 9'? [21:23:17 CET] <JEEB> I am pretty sure you are executing the ffmpeg binary with something, that something should have a way to get the exit code [21:24:49 CET] <carpediem_> yes, I am using zzuf [21:25:10 CET] <carpediem_> zzuf -r 0:0.05 -s 0:100 ffmpeg -i video.mp4 test.mp4 [21:25:34 CET] <JEEB> and you are executing that with something [21:25:40 CET] <JEEB> be it shell, python, C or whatever [21:25:46 CET] <carpediem_> shell [21:26:05 CET] <JEEB> echo $? [21:26:23 CET] <JEEB> or well, googling around "<your type of shell> exit code" [21:27:02 CET] <jkqxz> Signal 9 is SIGKILL, which won't be generated internally. Maybe it was killed by the OOM killer instead? (Check dmesg.) If it is the OOM killer then you've probably found some sort of unbounded memory use, which definitely counts as a crash worth fixing for these purposes. [21:29:50 CET] <Zeranoe> Trying to look into this MFX issue. I built the latest Media SDK manually after some tweaks (not using the dispatch). FFmpeg compiled fine, but I'm getting "Selected ratecontrol mode is not supported by the QSV runtime. Choose a different mode." [21:30:27 CET] <Zeranoe> command was: ffmpeg -i in.mp4 -loglevel verbose -c:v h264_qsv -an -y out.mp4 [21:31:13 CET] <JEEB> carpediem_: please do not pm me [21:31:21 CET] <JEEB> unless you have specifically something to me [21:31:29 CET] <JEEB> which you do not seem to have [21:32:07 CET] <carpediem_> got it. [21:33:29 CET] <Zeranoe> The MFX version is 1.17 (dispatch uses 1.16). Any ideas? [21:36:15 CET] <durandal_1707> omerjerk: you don't need to understand every bit of code, just enough to know what needs change [21:36:34 CET] <Daemon404> durandal_1707, arguably he does need to understand rice coding [21:36:43 CET] <Daemon404> since the gsoc project is to write an als encoder [21:37:52 CET] <omerjerk> durandal_1707: I'm trying to fix this bug - http://trac.ffmpeg.org/ticket/4715 [21:38:55 CET] <omerjerk> so want to make sure that that decode_rice function is okay. [21:49:11 CET] <Zeranoe> Looks to be failing somewhere in qsv_retrieve_enc_params. Seems to be initializing fine. [21:59:36 CET] <j-b> 'morning [22:09:28 CET] <Daemon404> https://www.dropbox.com/s/fy5hp2eylbc7vgp/mats.png?dl=0 [22:10:04 CET] <Daemon404> (also not sure what v5 1/4 v7 means) [22:10:30 CET] <JEEB> I am happy enough to not to look at those threads [22:12:14 CET] <ubitux> this thread has 24 mails [22:12:16 CET] <ubitux> 21 mails are from him [22:12:51 CET] <ubitux> actually not a thread [22:13:31 CET] <Daemon404> 15-20% of all ffmpeg-devel mails are replies to himself. [22:13:34 CET] <ubitux> http://ubitux.fr/pub/pics/mats-threads.png [22:13:37 CET] <ubitux> wth seriously [22:13:42 CET] <Daemon404> of *total* ffmpeg-devel mails [22:13:43 CET] <Daemon404> i mean. [22:20:46 CET] <carpediem_> Hi, I was trying to build ffmpeg for testing using american fuzzy lop and ran into an error [22:20:48 CET] <carpediem_> yasm/nasm not found or too old. Use --disable-yasm for a crippled build. [22:21:01 CET] <Daemon404> install yasm. [22:21:42 CET] <carpediem_> ok. [22:22:07 CET] <atomnuker> I heard nasm has been better lately [22:22:16 CET] <atomnuker> last yasm release was almost 2 years ago [22:22:27 CET] <Daemon404> not really relevanr for an assembler [22:22:41 CET] <JEEB> yeah, nasm is much more active dev-wise, and they even changed their license IIRC [22:23:01 CET] <JEEB> the license being one of the main reasons for yasm IIRC [22:23:18 CET] <carpediem_> that solved the problem. Thanks! [22:23:18 CET] <JEEB> yasm-ng (lolc++ rewrite) never came to be either [22:23:54 CET] <Daemon404> [B/g 3 [22:36:50 CET] <cone-935> ffmpeg 03Paul B Mahol 07master:361e48f0eda0: avfilter/vf_waveform: add graticule support [22:36:51 CET] <cone-935> ffmpeg 03Michael Niedermayer 07master:4ac4a2f4969d: fate/aac: Increase fuzz from of fate-aac-pns-encode from 72 to 74 for Loongson [22:37:25 CET] <Gramner> yasm is fine as long as you don't need avx-512 [22:37:57 CET] <Gramner> nasm still has issues with various stuff (although it should be able to assemble ffmpeg correctly) [22:38:57 CET] <cone-935> ffmpeg 03Michael Niedermayer 07master:c78a7267175a: fate/aac: Increase fuzz from of fate-aac-pns-encode from 72 to 74 for Loongson [22:39:27 CET] <Gramner> nasm can't assemble x264 with PIC enabled for example, although apparently one of the nasm guys was planning on looking into it [22:41:28 CET] <JEEB> yeah [23:01:22 CET] <carpediem_> hello developers [23:01:38 CET] <carpediem_> I tried building ffmpeg using afl [23:02:12 CET] <carpediem_> it builds successfully, but when I try to run afl-fuzz, it keeps showing instrumentation error [23:02:57 CET] <carpediem_> the target binary is not instrumented [23:03:23 CET] <carpediem_> any suggestions/solutions? [23:09:39 CET] <jkqxz> What does ("Missing reference picture, default is %d", ~2^16) from the decoder actually mean for an H.264 stream? [23:09:43 CET] <mark4o> carpediem_: make sure you are specifying the path to the instrumented executable and that it wasn't built with shared libav* libraries [23:09:45 CET] <jkqxz> I'm getting it every time on the frame immediately after an IDR frame, though the output appears correct unless there are later direct references to the IDR frame (B frames between the IDR frame and the first refernce, say). [23:10:38 CET] <carpediem_> ok, will try [23:15:58 CET] <carpediem_> how to remove build dependencies on the shared libav* libraries [23:16:00 CET] <carpediem_> ? [23:17:55 CET] <mark4o> carpediem_: do not use --enable-shared on configure [23:18:59 CET] <carpediem_> CC=afl-gcc ./configure [23:19:13 CET] <carpediem_> This is the command I use to build using afl-gcc [23:19:47 CET] <carpediem_> so, there should be a switch in this command to disable shared? [23:20:26 CET] <JEEB> default FFmpeg configuration has no shared [23:20:44 CET] <JEEB> it builds static libraries and links them to create the binary [23:21:20 CET] <mark4o> carpediem_: CC= doesn't work with ffmpeg configure, use ./configure --cc=afl-gcc [23:21:30 CET] <JEEB> and I was going to note that : [23:21:37 CET] <mark4o> you probably want to set a --prefix also [23:22:11 CET] <mark4o> and --assert-level=2 will be easier to find crashes [23:22:28 CET] <carpediem_> ./configure CC="afl-gcc" CXX="afl-g++" --disable-shared; make [23:22:33 CET] <carpediem_> should i try this? [23:22:46 CET] <JEEB> 1) shared libs are disabled by default [23:22:47 CET] <carpediem_> sorry, with the g++ removed ofc [23:22:58 CET] <mark4o> shared is disabled by default, just don't use --enable-shared [23:23:06 CET] <JEEB> 2) no, use --cc="afl-gcc" [23:23:22 CET] <JEEB> CC=thing doesn't do what you think it does with FFmpeg's configure [23:23:52 CET] <carpediem_> cool. will try and get back to you guys. Thanks for the help! [23:25:54 CET] <carpediem_> It worked! Thanks a ton! [00:00:00 CET] --- Sun Mar 6 2016

1 0

ffmpeg.log.20160305
by burek 06 Mar '16

06 Mar '16

[03:40:47 CET] <rsully> any recommendations (ffmpeg or not?) to combine a folder of mp3s into a single audio file with minimal quality loss? [03:40:55 CET] <rsully> no gap between songs or anything weird [03:45:12 CET] <furq> apparently you can do it with the concat demuxer and -c copy [03:45:33 CET] <llogan> you'll probably end up with a gap between songs if you concatenate with concat demuxer. [03:46:03 CET] <rsully> I'm looking at mp3wrap which is an interesting solution. Not sure if its a hack on the mp3 standard or not [03:46:22 CET] <rsully> but I assume concat would have problems with differing bitrates? which it sounds like mp3wrap somehow works around [03:46:53 CET] <rsully> yeah mp3wrap failed miserably [03:50:57 CET] <rsully> oh cool, bug id #1 is "does not work" https://sourceforge.net/p/mp3wrap/bugs/1/ [03:57:16 CET] <Kuukunen-> wouldn't gapless lossless concatenation be technically impossible...? [03:58:19 CET] <rsully> I'd guess so [03:58:33 CET] <rsully> but I am currently trying to compile vbrfix to see if this guide works http://lyncd.com/2011/03/lossless-combine-mp3s/ [04:06:45 CET] <rsully> surprising how undocumented this tool is [04:16:17 CET] <kepstin> gapless concatenation of mp3 files without re-encoding is unfortunately impossible [04:17:48 CET] <kepstin> since the way "gapless mp3 playback" works is to use metadata to know how many samples to throw away off the start and end after decoding [04:17:58 CET] <rsully> ah [04:18:14 CET] <rsully> what would you recommend then? lossy encode with highish bit rate to preserve detail? [04:18:28 CET] <kepstin> depends what you want to use the file for [04:18:46 CET] <kepstin> i mean, if you just need a single file that preserves all quality possible, throw it in a flac or whatever [04:19:22 CET] <rsully> i need it to put into final cut as a single audio clip [04:20:46 CET] <rsully> if it helps, all of the mp3 files are 320 CBR [04:22:15 CET] <kepstin> well, you could always just save to a wav or something that final cut can import [04:22:25 CET] <kepstin> then you only do one lossy encode on the audio during the final export [04:23:26 CET] <rsully> yeah might have to do that [04:26:03 CET] <rsully> kepstin would i need to use -f concat for that? [04:26:20 CET] <rsully> ffmpeg -f concat -i files.txt output.wav ? [04:26:42 CET] <kepstin> no, -f concat concats the streams before decoding. [04:26:47 CET] <kepstin> you need to concat them /after/ decoding [04:26:53 CET] <rsully> ah right [04:28:14 CET] <rsully> any pointer there? i've got the file names in files.txt [04:37:01 CET] <rsully> k i just converted all files to wav separately, then used -f on the wavs - should my output be fine or could i have done that better kepstin? [04:38:20 CET] <kepstin> rsully: that should work fine [04:39:05 CET] <kepstin> i probably would have output to raw audio and used >> shell redirects to concatenate the files, but that's just me ;) [04:41:44 CET] <rsully> hm what is considered raw audio? [04:41:50 CET] <rsully> isn't wav pcm? [04:42:35 CET] <kepstin> wav has a header [04:42:47 CET] <kepstin> "raw audio" is just the audio data with no headers [06:51:29 CET] <Fyr> atomnuker, Maybe you have an idea about PNS, but you obviously don't have an idea about signal processing. [06:51:51 CET] <Fyr> If you have a signal, then transform it into another with some frequencies being removed and some added, you will have a distorted signal with noise. Since distortion is small, the difference between signal and the signal with noise will give you noise. [06:52:04 CET] <Fyr> You owe me $10, because I know about delay and synchronized the signals. [06:54:46 CET] <Fyr> JEEB, highlight to you. [07:03:00 CET] <Fyr> an interesting thing that FFMPEG AAC adds some higher frequencies. [07:04:55 CET] <Fyr> they can be heard as chatter, https://youtu.be/ghO8N1s2Brc [07:12:28 CET] <durandal_1707> open bug report? [07:24:13 CET] <Fyr> those frequencies are distinctly seen in spectra. [07:24:41 CET] <durandal_1707> There is way to disable it? [07:24:49 CET] <Fyr> nope. [07:25:15 CET] <Fyr> not with standard FFMPEG features. [07:25:36 CET] <durandal_1707> isn't it pns? [07:26:31 CET] <Fyr> PNS must be silent to ear. [07:27:00 CET] <Fyr> moreover, FDK AAC doesn't have them, FFMPEG AAC does. [07:31:09 CET] <yongyung> I have a .mp4 source file that I'm reencoding with ffmpeg/x264. The source file seems to be 60 FPS, at least that's what VLC shows. If I use .mp4 as the container when re-encoding, the resulting file will also be exactly 60 FPS, shown by VLC. But if I use .mkv, the frame rate that gets shown is 60.0024 fps (ffprobe still shows 60 FPS). I thought it might just be a VLC bug, but just renaming the file to .mp4 doesn't change what VLC shows. [07:31:09 CET] <yongyung> Also, when I change the container with -c copy to .mp4, the frame rate that VLC shows is suddenly 59.991160 - and now even ffprobe shows the frame rate as 59.99. Any idea what's going on here? The ffmpeg container switch output is http://pastebin.com/SNze21v0 [07:35:08 CET] <yongyung> Fyr: Don't you think it's kinda pointless to make a youtube listening comparison when YT will reencode the audio anyway? [07:36:50 CET] <Fyr> yongyung, don't you see the message appended to the video description? [07:37:04 CET] <yongyung> Fyr: YouTube didn't even generate 256k AAC for that video, not even 160k opus, only 128k aac, ouch... [07:37:26 CET] <Fyr> it's not pointless since the original audio sounds almost the same. [07:38:09 CET] <Fyr> FFMPEG AAC adds higher frequencies, meanwhile FDK doesn't. [07:38:25 CET] <yongyung> Would've made more sense to just show the spectral analysis... [07:38:52 CET] <Fyr> right [07:39:08 CET] <Fyr> I'll post a picture later. [07:39:51 CET] <Fyr> ...or you can make it by yourself, since you've just downloaded the video. [07:42:39 CET] <yongyung> Spectral analysis of the files ffmpeg generates, not of what YouTube does to them^^ Although, if you send me the source .flac I can do it, I just can't compare it to libfdk_aac since I'm not compiling ffmpeg myself [07:43:11 CET] <Fyr> ok [07:44:33 CET] <durandal_1707> I only accept spectral analysis from ffmpeg itself [07:45:11 CET] <Fyr> do you have a grudge against audacity? [07:45:20 CET] <satinder_> Hi there have any one who have expertise in ffmpeg api development [07:45:23 CET] <satinder_> ?? [07:45:29 CET] <satinder_> I want help [07:45:39 CET] <Fyr> satinder_, #ffmpeg-devel ? [07:45:45 CET] <satinder_> ok [07:47:40 CET] <durandal_1707> Fyr: yes, its looking bad [07:48:16 CET] <Fyr> durandal_1707, then what is good-looking? [07:48:40 CET] <durandal_1707> Fyr: only ffmpeg output [07:53:21 CET] <yongyung> Holy shit the aac encoder is *horrible* lmao, I never tried it out but since they moved it from experimental to default I didn't think it's *that* bad [07:53:34 CET] <yongyung> Like, I just tried it out and it's OBVIOUSLY horrible even with 128k [07:53:48 CET] <yongyung> You can hear it within 2 seconds [07:53:50 CET] <yongyung> Jesus Christ [07:54:24 CET] <yongyung> It's the worst encoder I've ever heared in my life by a big margin [07:56:01 CET] <yongyung> Honestly it's so bad that can only be some sort of bug [07:56:43 CET] <kepstin> yongyung: are you sure you aren't accidentally using libvo-aacenc? :) [07:56:51 CET] <Fyr> =) [07:57:01 CET] <kepstin> vo-aacenc *is* actually that bad [07:57:24 CET] <yongyung> kepstin: I used -c:a aac on a ffmpeg version I *just* downloaded from https://ffmpeg.zeranoe.com/builds/ [07:57:47 CET] <yongyung> It also didn't want me to specify -experimental or -strict or whatever you had to do before [07:58:28 CET] <Fyr> yongyung, http://xtemp09.ucoz.net/result.flac [07:58:53 CET] <Fyr> durandal_1707, yongyung, JEEB, atomnuker, http://xtemp09.ucoz.net/result_spectrum.png [08:00:15 CET] <durandal_1707> That is not ffmpeg spectrum, its so low resolution [08:00:15 CET] <Fyr> see the high frequencies by yourselves. [08:00:48 CET] <durandal_1707> that's lowpass filter I guess [08:00:54 CET] <Fyr> durandal_1707, ok you have the original audio, perform spectral analysis by yourself. [08:01:34 CET] <Fyr> I did: [08:01:34 CET] <Fyr> $ ffmpeg -i input.wav -c:a aac -b:a 128k -f mp4 ffmpeg_aac_128k.m4a [08:01:34 CET] <kepstin> yeah, lowpass filter somewhere betweeen 14 and 40kHz is a standard part of most lossy encoders [08:01:46 CET] <Fyr> $ ffmpeg -i input.wav -c:a aac -b:a 32k -f mp4 ffmpeg_aac_32k.m4a [08:01:49 CET] <Fyr> and so on [08:02:08 CET] <Fyr> you can reproduce it by yourself. [08:02:31 CET] <Fyr> what, when FFMPEG AAC was introduced, nobody tried to compare it? [08:03:14 CET] <Fyr> it's the first thing I have done when I read the release announcement. [08:03:20 CET] <kepstin> Fyr: there's been lots of analysis done as it was being developed (and it's still under development) [08:03:20 CET] <durandal_1707> lowpass can be disabled [08:03:21 CET] <yongyung> Fyr, kepstin, durandal_1707: Here, listen for yourselves. The aac version is so bad you can here freaking *hissing* with 128k, even mp3 is nowhere near that bad https://drive.google.com/file/d/0B9W6HnKoRJNOS0lXdlNuSm1vUFE/view?usp=shari… [08:03:48 CET] <Fyr> yongyung, are you using FFMPEG AAC? [08:03:57 CET] <yongyung> Fyr: Yeah, -c:a aac [08:04:11 CET] <kepstin> the native aac encoder is certainly the best aac encoder that can be enabled in a redistributable ffmpeg build, at least. [08:04:13 CET] <Fyr> I don't think that it's THAT BAD. [08:04:26 CET] <yongyung> Jesus it hurts my ears [08:04:32 CET] <Fyr> it's way better than libvoaac_enc. [08:04:47 CET] <durandal_1707> I think it only is good from 256k to higher [08:04:54 CET] <Fyr> yeah, me too. [08:05:05 CET] <Fyr> it need some developement. [08:05:11 CET] <yongyung> kepstin: Well it might be the best one, but... if it sounds that bad it's still basically useless [08:05:27 CET] <Fyr> maybe, next year or too it will be comparable to libfdkaac_enc. [08:05:39 CET] <yongyung> Well I mean, except for compability reasons there's no reason to use aac anyway so I'm not too sad about it [08:05:58 CET] <kepstin> it's apparently missing some significant vbr-related features still (it's cbr only iirc) [08:06:14 CET] <kepstin> (or at least the vbr mode is still experimental) [08:07:16 CET] <Fyr> hhhhhhhhhhissssssssssing [08:08:34 CET] <yongyung> durandal_1707: You're right btw, with 256k the hissing is almost completely gone. I still feel like I hear something but I can't get a 16/16 blind test right now [09:37:02 CET] <k_sze> If I have built ffmpeg in the usual way (e.g. as per http://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu) is there a way I can tell which commit my ffmpeg was built against? [09:37:20 CET] <k_sze> I mean, if I don't remember which commit I used. [09:37:44 CET] <Fyr> oh [09:45:17 CET] <yongyung> I have a .mp4 source file that I'm reencoding with ffmpeg/x264. The source file seems to be 60 FPS, at least that's what VLC shows. If I use .mp4 as the container when re-encoding, the resulting file will also be exactly 60 FPS, shown by VLC. But if I use .mkv, the frame rate that gets shown is 60.002400 fps (ffprobe still shows 60 FPS). I thought it might just be a VLC bug, but just renaming the file to .mp4 doesn't change what VLC shows. [09:45:17 CET] <yongyung> Also, when I change the container with -c copy to .mp4, the frame rate that VLC shows is suddenly 59.991160 - and now even ffprobe shows the frame rate as 59.99. Any idea what's going on here? The ffmpeg container switch output is http://pastebin.com/SNze21v0 [11:34:50 CET] <flux> yongyung, can you either provide access to the file or use MP4Box to produce some information about it? [11:39:33 CET] <flux> yongyung, the difference could be that the average FPS of the track is different from the track length including/excluding audio, or that some frame (ie. first or last) could be of different duration [11:45:56 CET] <flux> actually ffprobe is able to retrieve this information as well a bit more precisely. [11:47:39 CET] <yongyung> flux: If you tell me the command line I can see what happens ;) [11:48:47 CET] <flux> yongyung, do you run Linux? [11:49:32 CET] <yongyung> flux: No, but the command shouldn't change for windows? [11:50:19 CET] <flux> well, I was thinking of using some other commands as well than pain ffprobe [11:50:35 CET] <flux> but ffprobe -of compact -show_frames will dump information about each frame [11:50:42 CET] <flux> the field to watch for is pkt_pts_time [11:51:13 CET] <flux> you could compare the rows that both have stream_index=0 (assuming the first track is video) against the value in pkt_pts_time [11:55:37 CET] <yongyung> flux: The duration always varies between 0.017, 0.016 and 0.015 [11:57:01 CET] <flux> yongyung, and if you compare the durations between the original video and the resulting video, are they different? [11:58:27 CET] <flux> actually there's already a field pkt_duration_time.. [11:58:35 CET] <yongyung> flux: In the .mkv file they're all 0.016 as far as I can see [11:58:44 CET] <flux> but I was thinking if you compare the raw pkt_pts_times, do they drift apart? [11:59:48 CET] <flux> and do the videos have the same number of frames, and is their length in time the same (video duration is usually not indicated to this precision though) [12:02:45 CET] <yongyung> flux: The frames in the .mkv file aren't in order, pts_times are 0.0, 0.05, 0.044, 0.028, 0.111, 0.094 [12:03:23 CET] <yongyung> With the mp4 file they're 0.0, 0.017, 0.034, 0.05, 0.067, 0.084 [12:06:19 CET] <flux> well, the packets may not be in presentation order in the stream, so you could compare the ordered values [12:08:02 CET] <yongyung> Well, they're drifting I guess - The weird thing is, this is an OBS recording, if I record to .mp4 the file shows 60 FPS, if I record to .mkv the file shows 60.0024 FPS. Same effect as if I converted it. [12:45:04 CET] <atomnuker> Fyr: *I* wrote most of the encoder apart from the base, and *you* need to stop thinking like the main point of an audio encoder is perfect looking spectra [12:45:28 CET] <atomnuker> the encoder boosts PNS volume as the bitrate/lambda decreases [12:45:57 CET] <atomnuker> and for a very good reason: it sounds a lot better at lower bitrates [12:46:38 CET] <atomnuker> masking the more horrible quantization artifacts which appear at around the midrange [12:47:39 CET] <atomnuker> so at lower bitrates it's never about replicating the original spectrum 1 to 1 [12:50:19 CET] <Fyr> atomnuker, why then FFMPEG AAC encoder sounds like ass? [12:51:04 CET] <atomnuker> because the fdk people had years to tweak and tune their encoder [12:51:20 CET] <atomnuker> and I've worked on our encoder for just under a year now [12:51:47 CET] <atomnuker> should've heard what it sounded like back then [12:51:51 CET] <Fyr> then removal of -strict experimental was a bit hastily. [12:52:24 CET] <Fyr> I think that the native FFMPEG's encoder is a great deal. [12:52:25 CET] <atomnuker> I disagree - it is good enough for most people at bitrates of over 128k [12:52:29 CET] <Fyr> yes [12:52:36 CET] <Fyr> more than 256k I would say. [12:53:08 CET] <Fyr> when VBR is implemented, it will look like a candy. [12:53:29 CET] <Fyr> right now it needs polishing. [12:53:50 CET] <atomnuker> VBR makes everything more difficult [12:53:59 CET] <Fyr> it does. [12:54:22 CET] <atomnuker> and some people would *kill* us if it overshot [12:55:38 CET] <atomnuker> if you think you can do better: the more important code is right there in libavcodec/aaccoder.c [12:56:05 CET] <Fyr> atomnuker, why does FFMPEG's AAC add a delay when converting into M4A? [12:56:17 CET] <Fyr> the very first 0.02 seconds. [12:56:20 CET] <JEEB> all AAC encoders have encoder delay [12:56:26 CET] <atomnuker> ^^ [12:56:32 CET] <Fyr> and in the end it adds some points. [12:56:33 CET] <JEEB> why you don't get it with fdk-aac is the question [12:57:05 CET] <atomnuker> I did tests on that a few months ago and fdk-aac was 200msec behind the original track [12:57:09 CET] <Fyr> JEEB, fdk adds 0.000 seconds, the native encoder adds 0.02. [12:57:17 CET] <atomnuker> compared to the ~20 msec of the native encoder [12:58:05 CET] <Fyr> it means, when it's converted ten times, the delay will be 0.2 second. [12:58:13 CET] <JEEB> Fyr: there's definitely some monkey business going on then because both have encoder delay and both should mark it. I do know that last I tested the WAV output was the broken one [12:58:23 CET] <JEEB> which I think I went over with you before :P [12:59:16 CET] <JEEB> and then you supposedly noted that the random FFmpeg binary you were using hadn't written... the delay with one of the encoders? [12:59:25 CET] <JEEB> since you didn't have the start: xxx thing [13:04:53 CET] <Fyr> I think that stealing the algorithms and the code is a good thing. [13:05:44 CET] <Fyr> we should disassemble QAAC and steal everything from them. [13:08:04 CET] <furq> you first [13:14:05 CET] <JEEB> ok, just built the latest FFmpeg here and 1) the encoder delay is clearly marked and 2) the WAV output is still as weird as it always was with negative timestamps [13:14:28 CET] <JEEB> so if you care about that not being handled correctly, please fill a bug :P [13:14:34 CET] <Fyr> how is it weird? [13:14:52 CET] <JEEB> it outputs all the samples, it doesn't ignore stuff you're supposed to ignore [13:15:24 CET] <JEEB> I went through this once with another guy and it was due to how the command line app handles negative timestamps [13:15:48 CET] <JEEB> because you've got encoder delay, the first samples will start at a negative timestamp [13:15:58 CET] <JEEB> yet because WAV is an "output format" that doesn't suppor that... [13:16:19 CET] <JEEB> it will do the thing that was "designed" to give you all the samples [13:16:34 CET] <JEEB> if you used the API, then you would be just throwing those samples out [13:17:03 CET] <JEEB> like foobar2000 is doing [13:17:29 CET] <JEEB> and pretty much every other API user of the libavcodec library I think [13:33:07 CET] <absence> i've encoded a raw h264 stream using x264. when i try to mux it to mp4 using ffmpeg, i get piles of messages "pts has no value" [13:34:35 CET] <absence> i've gotten the same error when remuxing from MTS, and it was suggested that the MTS file was bad. but now i have a .264 file directly from x264, surely that should work? [13:35:29 CET] <JEEB> well, there really isn't much of the form of PTS in raw AVC. You will have to specify a frame rate unless ffmpeg catches a header that is often (ab)used for that [13:36:03 CET] <JEEB> (raw AVC and such are the rare cases where IIRC -r before -i works) [13:36:20 CET] <absence> JEEB: ffmpeg does detect the right frame rate though [13:36:21 CET] <JEEB> although I usually do raw AVC to mp4 with L-SMASH's muxer [13:36:31 CET] <JEEB> absence: and the output is or isn't fine? [13:36:36 CET] <absence> Stream #0:0: Video: h264 ([33][0][0][0] / 0x0021), yuv420p, 1280x720, q=2-31, 50 fps, 50 tbr, 1200k tbn, 1200k tbc [13:37:09 CET] <absence> JEEB: i don't know yet, i'm just assuming something is wrong. last time i saw this i ended up with frames out of order [13:37:12 CET] <absence> and stuttering [13:37:39 CET] <JEEB> test it out with a simple command line ffmpeg -i hurr.264 -c copy out.mp4 [13:38:02 CET] <JEEB> if it does something wrong, file a bug and switch to using L-SMASH's muxer for the initial mux [13:39:56 CET] <absence> JEEB: btw there's also this message at the beginning: [mp4 @ 00000069ef4732a0] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly [13:41:31 CET] <JEEB> that is warning about internal code using something that has been marked deprecated [13:41:44 CET] <JEEB> it isn't something you'd worry about because you're not using the library [13:42:04 CET] <JEEB> Fyr: I can't replicate your results, both encoders mark encoder delay http://up-cat.net/p/10da2feb [13:42:48 CET] <absence> true, but it suggests that even if it runs right now, something is so wrong that in a future version it won't even try it. i'd really like to get to the bottom of this [13:42:48 CET] <Fyr> ok, I'll recheck this with the latest FFMPEG and post a bug report if I don't reproduce it. [13:44:01 CET] <JEEB> Fyr: and if I now decode these with the ffmpeg cli to WAV I expect both to have the encoder delay there because of the way negative timestamps are handled [13:44:37 CET] <Fyr> JEEB, i.e. the delay remains? [13:45:12 CET] <JEEB> i.e. the wav output doesn't get cut, because of a bug/feature in libavformat [13:45:29 CET] <JEEB> *that* IMHO should be where you should file a bug if you file one :P [13:45:31 CET] <Fyr> ='( [13:46:50 CET] <JEEB> and yup, I got exactly the same result [13:47:25 CET] <JEEB> ffaac has a smaller delay, thus ended up shorter after decoding to wav, and fdk-aac has a bigger one and thus ends up even larger :P [13:47:51 CET] <JEEB> but yeah, if you want this fixed you should file a bug against the WAV output [13:48:04 CET] <JEEB> since that is the component that is currently handling that delay wrong [13:50:15 CET] <JEEB> lemme try forcing the fdk-aac decoder if that got built, that might just be implicitly throwing out its own delay (but it should do it in both cases) [13:50:55 CET] <JEEB> which IMHO is even worse :D because it's not like the decoder can do anything else but assume things [13:53:13 CET] <JEEB> funky [13:53:24 CET] <JEEB> that actually seems to also output all samples [13:53:40 CET] <JEEB> Fyr: I have no idea how you got a wav out of ffmpeg that had the delay removed :DDD [13:53:51 CET] <JEEB> both ffaac and fdk-aac decoder output all samples it seems [13:54:00 CET] <JEEB> at least looking at the length of the output wav [13:54:22 CET] <Fyr> JEEB, ffmpeg -i X.m4a -ss 0.0232 -t XX -c:a pcm_s16le 1.wav [13:54:53 CET] <JEEB> uhh [13:55:05 CET] <JEEB> weren't you yesterday saying that with jus "ffmpeg -i file out.wav" [13:55:12 CET] <JEEB> was giving you no delay with fdk-aac? [13:55:37 CET] <JEEB> because supposedly only ffaac was creating that delay :P [13:55:37 CET] <Fyr> yes [13:55:51 CET] <JEEB> well I have right now shown that to be bollocks [13:55:57 CET] <Fyr> because libfdkaac_enc's delay was 0.0000 s [13:56:09 CET] <JEEB> http://up-cat.net/p/a4c1bfb1 [13:56:14 CET] <Fyr> I saw that. [13:56:14 CET] <JEEB> you can see the whole flow [13:56:19 CET] <JEEB> no, this is with decoding [13:56:23 CET] <JEEB> and decoding with fdk-aac [13:56:38 CET] <JEEB> so no matter which decoder you use, you get the length of all samples encoded, including the delay [14:02:35 CET] <JEEB> Fyr: so basically the only bug you should be filing is against the wav output :P [14:03:55 CET] <absence> JEEB: there are a bunch of old open tickets about this and related issues on trac, so i guess ffmpeg simply doesn't support muxing h264. with mp4 there's the deprecated warning, but with mkv or mts it simply stops with an error [14:04:35 CET] <JEEB> absence: so did you actually try the created file? [14:04:57 CET] <JEEB> the no pts warning is valid('ish) with raw AVC [14:04:57 CET] <absence> JEEB: the created mkv and mts files are empty [14:05:20 CET] <JEEB> please post your full command line and output on a pastebin'ish site that is not retarded [14:05:22 CET] <absence> JEEB: or well, "empty". less than 1kB [14:05:36 CET] <absence> which one isn't retarted? [14:06:33 CET] <JEEB> anything that doesn't require me to go through hoops [14:07:45 CET] <absence> JEEB: http://pastebin.com/quqVY1Wt [14:07:49 CET] <JEEB> thanks [14:08:52 CET] <absence> JEEB: if i mux to .mts the error is identical [14:09:16 CET] <JEEB> yeah, I guess they both check if there's a timestamp on the packets [14:09:20 CET] <absence> JEEB: the 264 file comes straight out of x264 [14:09:24 CET] <absence> no fancy options [14:09:31 CET] <JEEB> yeah, I understand [14:09:55 CET] <absence> JEEB: and i get the exact same problem if i read h264 from a .mts instead of from a .264 [14:10:05 CET] <JEEB> yeah, but that's completely different [14:10:19 CET] <JEEB> in that case either the mpegts demuxer or the input file is broken [14:10:49 CET] <JEEB> in this case it's just how the timestamps on a raw AVC streams are handled (or well, how the timestamps *aren't* created) [14:11:35 CET] <JEEB> you can either comment on an existing bug report or craft a bug report if there's not one specifically for muxing raw AVC into containers [14:11:51 CET] <JEEB> the mpeg-ts => something is a whole separate can of worms [14:12:04 CET] <JEEB> for now I recommend you create an initial mp4 with L-SMASH's muxer or so [14:12:17 CET] <JEEB> absence: or as I asked, did the mp4 you created work? [14:12:21 CET] <JEEB> with ffmpeg [14:12:26 CET] <JEEB> since you said that created a file fine [14:12:52 CET] <absence> JEEB: there are several open ones already, and they're like 4 years old [14:13:14 CET] <JEEB> for raw avc to containers? [14:13:22 CET] <JEEB> forget about the other case for now [14:13:41 CET] <absence> JEEB: yes [14:14:55 CET] <absence> https://trac.ffmpeg.org/ticket/1150 [14:14:57 CET] <absence> https://trac.ffmpeg.org/ticket/1598 [14:15:30 CET] <Fyr> ok, let's call it a day. [14:15:30 CET] <Fyr> JEEB, when people on #ffmpeg-devel try to close the bug, explain the details. [14:15:38 CET] <absence> JEEB: there are multiple open tickets for the other case too [14:15:48 CET] <absence> JEEB: not as old though, just two years [14:16:11 CET] <absence> https://trac.ffmpeg.org/ticket/3339 [14:16:13 CET] <JEEB> Fyr: funny enough your output doesn't seem to add anything to the duration :P [14:16:14 CET] <absence> https://trac.ffmpeg.org/ticket/3369 [14:16:33 CET] <JEEB> Fyr: so your ffmpeg build is borked or something, because the duration isn't longer with the WAV [14:16:41 CET] <absence> JEEB: the .mp4 it creates seems to work at a glance [14:17:19 CET] <absence> JEEB: whereas the .mkv and .mts are empty [14:17:42 CET] <JEEB> yea, the matroska case is at least simple enough. the muxer just doesn't take packets that haven't got a timestamp [14:18:05 CET] <JEEB> which can be explained by the raw avc "demuxer" not putting in all the values [14:18:18 CET] <JEEB> I would guess the mpeg-ts muxer also requires some fields to be set [14:19:16 CET] <absence> -fflags +genpts does nothing in all the cases. for which there is another open ticket :D (not complaining, but it is a bit funny) [14:19:42 CET] <JEEB> I don't even want to know what that does [14:20:12 CET] <absence> i think it generates the missing timestamps [14:20:19 CET] <absence> or is supposed to [14:20:20 CET] <JEEB> Fyr: OK, I'm just bad at this :P you never showed the source thing's actual length so yeah, it's all OK [14:20:48 CET] <absence> JEEB: the ticket suggests it's a "known limitation of our h264 decoder" [14:20:50 CET] <JEEB> this is definitely not something a user should expect so unless there's a big reason for pushing out all samples [14:25:37 CET] <JEEB> absence: that kind of flag is a huge hack and shouldn't be required with non-broken files [14:25:42 CET] <JEEB> so forget about genpts flag [14:53:45 CET] <absence> JEEB: it's usually presented as a workaround for the lack of timestamps on various forum posts and mailing lists, but it doesn't work anyway. maybe it used to [14:58:15 CET] <JEEB> absence: it can work in some rare occasions, maybe. it will try to come up with timestamps from thin air [14:58:24 CET] <JEEB> it shouldn't be needed with raw AVC anyways [15:06:28 CET] <wodim> is amv still not supported as an output format? [15:07:10 CET] <JEEB> which amv? [15:07:19 CET] <wodim> https://code.google.com/archive/p/amv-codec-tools/wikis/HowToConvertToAMV.w… [15:07:31 CET] <JEEB> ok, so the chinese MJPEG AVI hack if I recall correctly [15:07:35 CET] <wodim> no clue [15:07:40 CET] <wodim> but yes [15:07:49 CET] <wodim> it's for a shitty pocket player [15:08:14 CET] <JEEB> anyways, no - it's not in the list that comes up when I run `ffmpeg -formats` [15:08:16 CET] <wodim> so there's that fork there but it's from 2007 [15:09:20 CET] <JEEB> also I'm not sure how much of "AMV" is actually custom, so you might be able to use MJPEG and raw PCM with those values [15:09:33 CET] <wodim> I'll give it a spin [15:09:34 CET] <JEEB> although not that I remember the details of that crappy container [15:09:41 CET] <JEEB> you should see the patches for it [15:09:59 CET] <wodim> top notch chinese engineering [15:10:00 CET] <JEEB> also if I recall correctly there's even multiple things called "AMV" [15:10:36 CET] <JEEB> https://code.google.com/archive/p/amv-codec-tools/wikis/AmvDocumentation.wi… [15:10:37 CET] <JEEB> oh yeah [15:10:48 CET] <absence> for a second i worried that someone had invented a specific format for "anime music videos" :D [15:11:05 CET] <JEEB> basically AVI with various parts of the file filled with shit [15:11:45 CET] <JEEB> ugh [15:11:59 CET] <wodim> maybe regular AVI would work? [15:12:13 CET] <JEEB> both the video and audio formats seem to be raped [15:12:18 CET] <wodim> it comes with amv [15:12:20 CET] <wodim> err [15:12:20 CET] <JEEB> unless the players now can handle proper MJPEG right [15:12:27 CET] <wodim> sorry I mean [15:12:33 CET] <wodim> the player comes with an amv file [15:12:37 CET] <wodim> this is what it looks like [15:12:37 CET] <wodim> Stream #0:0: Video: amv, yuvj420p(pc, bt470bg/unknown/unknown), 160x120, 16 fps, 16 tbr, 16 tbn, 16 tbc [15:12:41 CET] <wodim> Stream #0:1: Audio: adpcm_ima_amv ([1][0][0][0] / 0x0001), 22050 Hz, 1 channels, s16, 352 kb/s [16:53:25 CET] <voodster> hello, I want concat two webm with audio into one webm [16:53:42 CET] <voodster> command does not work as I want -> ffmpeg -vcodec copy -acodec copy -i one.webm -vcodec copy -acodec copy -i two.webm result.webm [16:54:01 CET] <voodster> I got only first file in result, how to map correctly it? [16:56:48 CET] <furq> voodster: https://trac.ffmpeg.org/wiki/Concatenate#demuxer [16:57:15 CET] <voodster> I have not 'ffmpeg -f concat' [16:58:57 CET] <voodster> ffmpeg -i "concat:input1.mpg|input2.mpg|input3.mpg" -c copy output.mpg // does not work correctly for me too, in output I get first file [16:59:16 CET] <furq> you can't use the concat protocol with webm [16:59:24 CET] <furq> if you don't have the demuxer then upgrade ffmpeg [16:59:47 CET] <furq> http://johnvansickle.com/ffmpeg/ if your distro package manager is stuck on 0.8 [17:00:23 CET] <`md> is opening h264/ac3/ts/http a non supported case for ffmpeg? [17:00:36 CET] <`md> i was under the impression it should work [17:00:45 CET] <`md> certainly works very well with vlc [17:02:59 CET] <Prelude2004c> hey guys.. question.. i have a gif image that i want to loop because i only have audio from a source and i want to create a video with audio/video [17:03:21 CET] <Prelude2004c> >> /home/ffmpeg/ffmpeg -i "$2" -stream_loop -1 -i $5 -pix_fmt yuv420p -c:v mpeg4 -c:a copy -r 25 -t 30 [17:03:23 CET] <Prelude2004c> what am i doing wrong here ? [17:03:46 CET] <Prelude2004c> the first input is my live audio stream.. my second is the png ( $5 ) that i want to loop to create the video [17:04:18 CET] <furq> stream_loop should be before the image, not the audio [17:05:05 CET] <furq> you probably also want -shortest [17:06:54 CET] <JEEB> `md: it should work [17:07:08 CET] <JEEB> how does it not work? [17:07:15 CET] <JEEB> (command line and terminal output if possible) [17:07:21 CET] <JEEB> (in pastebin'like) [17:09:38 CET] <Prelude2004c> -stream_loop -1 -i $5 that is the image [17:09:46 CET] <Prelude2004c> $2 is the audio [17:10:00 CET] <furq> oh [17:10:06 CET] <furq> how does it not work [17:12:28 CET] <voodster> furq: thanks a lot for a link with new binary ffmpeg [17:12:29 CET] <Prelude2004c> no idea... seems that it can't loop the input of the gif image [17:12:39 CET] <voodster> all works fine with it [17:12:46 CET] <furq> Prelude2004c: is it a gif or a png [17:12:51 CET] <Prelude2004c> gif. [17:12:57 CET] <Prelude2004c> and it does like 2 frames and exits [17:13:09 CET] <Prelude2004c> when i run just the gif on it's own it works and starts to create the video [17:13:38 CET] <Prelude2004c> soon as i try to introduce the external audio into the mix, it does 2 frames and just stops [17:19:56 CET] <Prelude2004c> anyone ? > /home/ffmpeg/ffmpeg -re -i "external http://audio source" -stream_loop -1 -i "/location/file.gif" -pix_fmt yuv420p -c:v mpeg4 -c:a copy -r 25 [17:22:50 CET] <`md> JEEB: for example https://pastee.org/486h [17:23:55 CET] <`md> JEEB: and then on another computer i tried this on, it keeps going on, but with lotsa decoding errors as well [17:24:12 CET] <`md> JEEB: just watching that url in vlc is perfectly fine tho [17:25:43 CET] <JEEB> might want to try with current FFmpeg, but as it shows the stuff itself works fine. are you using lavc decoding or hw decoding with VLC? [17:25:54 CET] <JEEB> also you could try mpv as another player that's based on libavformat+-codec [17:25:56 CET] <`md> lavc [17:26:58 CET] <JEEB> seems like you were pushing your stream to another http thingy and that one reset the connection [17:27:12 CET] <JEEB> av_interleaved_write_frame(): Connection reset by peer [17:27:41 CET] <JEEB> but yeah, I recommend building the latest FFmpeg master with libx264 to try that out [17:28:24 CET] <`md> JEEB: mpv seems to play it fine [17:28:35 CET] <JEEB> yeah, so I guess it's the pushing to another HTTP thingy that's the issue [17:28:37 CET] <`md> JEEB: not pushing [17:28:40 CET] <`md> JEEB: serving [17:28:46 CET] <JEEB> oh right, -listen 1 [17:28:54 CET] <JEEB> that might have all quirks of its own :D [17:29:14 CET] <JEEB> should just be "./configure --enable-gpl --enable-libx264" after you install libx264-dev [17:29:24 CET] <JEEB> unless that 14.04 x264 is way way too old [17:29:41 CET] <`md> i i get the same issues with file output btw [17:29:48 CET] <`md> so it is not the http serving component [17:29:52 CET] <`md> -i [17:30:00 CET] <JEEB> ok, can you then post that? [17:30:05 CET] <`md> sure hold on [17:34:20 CET] <Prelude2004c> hum.. ok seems that it works if i output to mp4 but does not work if i try and output HLS and segment any ideas ? [17:34:56 CET] <`md> JEEB: https://pastee.org/kk38d i aborted the process after about 1000 frames, otherwise it would have kept going [17:35:58 CET] <Prelude2004c> http://pastebin.com/KdPfTXxP >> can anyone help with what is wrong with it [17:36:24 CET] <Prelude2004c> i can't seem to output directly to HLS .. so i piped the output to another session and then segment but still does not like it as it gets stuck waiting for input [17:38:54 CET] <JEEB> `md: if it kept on going then it's fine [17:39:16 CET] <JEEB> getting those errors for a while is normal [17:39:17 CET] <`md> JEEB: yes it kept on going [17:39:37 CET] <`md> JEEB: well yea normally i would ignore them... but they amount to glitches [17:39:46 CET] <`md> in hte output [17:40:25 CET] <JEEB> if the input stream is supposed to have normal closed GOPs then something's breaking it along the way [17:40:48 CET] <JEEB> anyways, we should stop looking at it with this old version, you should get a current one built and we can see how that goes [17:40:53 CET] <JEEB> 2.5 is quite old by now [17:41:05 CET] <`md> JEEB: i am not 100% sure how gop closing is defined for dvb broadcasts [17:41:44 CET] <JEEB> in general they can have open gop, but you should generally have a random access picture every 0.5 second or so? [17:42:10 CET] <JEEB> so either it's a bug in this old version of FFmpeg, or the stream's being broken somewhere [17:42:31 CET] <`md> well the output is playable, but very glitchy [17:42:36 CET] <JEEB> I have done quite a bit of work with http inputs so in general those should work [17:42:48 CET] <`md> yea i should update ffmpeg [17:43:00 CET] <`md> gonna do that and report back [18:35:45 CET] <Prelude2004c> hey guys.. i am closer but.. still a problem [18:35:45 CET] <Prelude2004c> http://pastebin.com/vfE4xgL7 [18:36:15 CET] <Prelude2004c> seems that now ti plays video and audio from the outside source but !!! when the video ends on the input $5 everything just stops [18:36:20 CET] <Prelude2004c> i don't get it.. i have the stream_loop there [18:46:53 CET] <Prelude2004c> an anyone help me with video loop ? [18:49:49 CET] <durandal_1707> Prelude2004c: how long is video in frames? [18:50:10 CET] <Prelude2004c> 935frames [18:50:15 CET] <Prelude2004c> but the audio source goes on forever [18:50:28 CET] <Prelude2004c> so i want to loop the input video ( which is just a blank page that says " audio stream " ) [18:50:37 CET] <Prelude2004c> and then play the realtime audio [18:50:54 CET] <Prelude2004c> but the video/audio stop after the original video hits 935frames [18:51:18 CET] <Prelude2004c> so everything stalls as if it can't continue because the video is over.. i was assuminmg it would just loop forever and keep playing the realtime audio source [18:51:38 CET] <satinder___> Hi I am able write data in .ppm but I want write it on a file [18:51:45 CET] <satinder___> please any body help [18:53:26 CET] <durandal_1707> Prelude2004c: try loop filters? [18:53:42 CET] <Prelude2004c> um.. trying stream_loop -1 [18:53:46 CET] <Prelude2004c> doesn't go around for the input [18:54:28 CET] <Prelude2004c> > /home/ffmpeg/ffmpeg -i "$2" -stream_loop 10 -re -i $5 .. the whole thign stops soon as the first run of the -i $5 ends [18:54:40 CET] <Prelude2004c> exactly 935 frames [18:57:10 CET] <durandal_1707> if video is single frame you can use loop filter, otherwise paste full ffmpeg output [18:57:25 CET] <Prelude2004c> what loop filter ? [18:57:59 CET] <Prelude2004c> i have tried loop - 1 ( not recognized ) .. only one that seems to have worked was stream_loop without error.. but still doesn't loop [19:02:14 CET] <jkqxz> satinder___: You're going to have to be much clearer about what you actually want for anyone to be able to help you. Try asking a question with precise details about what you want to do rather than vaguely stating that you need help with something nebulous. [19:05:08 CET] <satinder___> No , I am doing this with using ffmpeg api not ffmpeg binary [19:06:15 CET] <satinder___> jkqxz : I am writing a c code for get encoded stream and decode it then write raw data on fifo or v4l2 node [19:06:52 CET] <satinder___> I get successfully video frames but not able to write it in a video stream file or node [19:06:59 CET] <satinder___> so can you help me [19:13:30 CET] <Filarius> hello, do anybody can help me to fix audio/video lag at beginning of video ? Logs http://pastebin.com/pUGbbfRf Video http://rghost.ru/7N6Bz42RS [19:13:55 CET] <Filarius> I trying to record HLS live stream [19:14:26 CET] <Filarius> I have same lag with video-audio re-encoding too [19:25:19 CET] <Prelude2004c> still trying to loop an input .. can anyone help ? [19:40:51 CET] <bencoh> Filarius: what if you just download/concat chunks? do you notice any lag? [19:47:11 CET] <durandal_1707> Prelude2004c: there are loop filters, read docs [20:14:23 CET] <Prelude2004c> yes i have been trying to use lavif and stuff [20:14:30 CET] <Prelude2004c> having problems with it too [21:53:24 CET] <Filarius> bencoh, maybe i'm too late. I just have short video, withour parts/chunks. Video is unique and separete item [22:36:31 CET] <bencoh> Filarius: is that hls? [23:18:33 CET] <_Vi> ffplay says something about uploading a file to "incoming" and sending to a mail list when I try to play this: https://oitofelix.github.io/mininim/game-play.png [23:19:37 CET] <c_14> _Vi: seems to work for me. What version do you have? [23:20:26 CET] <_Vi> ffmpeg version 2.7.1 Copyright (c) 2000-2015 the FFmpeg developers [23:21:24 CET] <_Vi> File converted to V_MPEG4/ISO/AVC mkv also looks broken (not fluent compared to if view using browser). [23:22:26 CET] <_Vi> The message is "[apng @ 0xbd3900] Blending with pixel format rgb24 is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.". Maybe the main part is "pdate your FFmpeg version to the newest one from Git."... [23:23:09 CET] <c_14> _Vi: try with a git build [23:57:03 CET] <_Vi> Works well with FFmpeg from git. [23:57:11 CET] <_Vi> What multimedia container (apart from png itself) can store apng? matroska and nut fails... [00:00:00 CET] --- Sun Mar 6 2016

1 0

ffmpeg-devel.log.20160304
by burek 05 Mar '16

05 Mar '16

[00:18:51 CET] <cone-291> ffmpeg 03Paul B Mahol 07master:3e491a1fb613: avfilter/af_sofalizer: print size of FFT that failed to init [00:18:52 CET] <cone-291> ffmpeg 03Paul B Mahol 07master:21234c835d2d: avfilter/af_sofalizer: fix crash with odd IR size [00:20:58 CET] <Timothy_Gu> BtbN: thanks [00:22:15 CET] <Timothy_Gu> durandal_170: should 21234c835d2d be backported? [00:23:11 CET] <durandal_170> If you care :) [00:24:58 CET] <Timothy_Gu> ok [00:30:18 CET] <kierank> J_Darnley: can't see what you've done wrong [00:30:24 CET] <kierank> perhaps consider writing a haar transform [00:30:32 CET] <kierank> that's much simpler so might help you figure out what's wrong [00:36:00 CET] <atomnuker> the bug is definitely not in the coefficient deinterlacing code but during the lifting scheme [00:36:14 CET] <atomnuker> else there wouldn't be much of an image on the screen [00:36:45 CET] <atomnuker> I'd try to mess with the C transform to get something which looks like it gives the same artifacts [00:37:09 CET] <J_Darnley> thanks for looking [00:37:40 CET] <J_Darnley> i'll try another transform first [00:37:51 CET] <atomnuker> I'll try to debug the code when I have time during the weekend [02:21:31 CET] <ethe> I'm trying to make a jack outdev; it uses a lot of the same code as the indev, so I put the common functions in jack.c. One of the functions in jack.c requires a function callback, which are not common, however the function (which is in _enc & _dec) cant be found (when linking), I think it's because of the static. Anyone have an idea of how I can solve this? I dont think making it a public function is [02:21:33 CET] <ethe> the right solution, but that's just me [02:38:53 CET] <Timothy_Gu> ethe: can you post a diff [02:42:50 CET] <ethe> Timothy_Gu: https://gist.github.com/43c21e8c236bf4c7efa2 [02:43:32 CET] <ethe> hmm, I'm not tracking all the files it seems [02:43:58 CET] <Timothy_Gu> ethe: you know what, just send the files themselves, not a diff [02:44:17 CET] <Timothy_Gu> the diff is pretty hard to read [02:47:08 CET] <ethe> Timothy_Gu: https://gist.github.com/9f95c1be16f8b7519014 [02:47:41 CET] <Timothy_Gu> ethe: because those files are static, you can't use them in other files [02:48:05 CET] <Timothy_Gu> remove `static`, and add a ff_ prefix to the functions [02:48:31 CET] <ethe> and then I get a duplicate symbol [02:49:24 CET] <Timothy_Gu> what's duplicated? [02:54:39 CET] <ethe> ff_process_callback [02:55:59 CET] <ethe> alternatively I could just have start_jack in both _enc & _dec [03:00:40 CET] <Timothy_Gu> ethe: no, my comment only applies to functions in jack.c [03:00:47 CET] <Timothy_Gu> i.e. the shared functions [03:00:59 CET] <Timothy_Gu> functions in individual files should stay static [03:03:29 CET] <ethe> if I set them to static, then I get undefined symbol, because jack.c needs the process_callback function from _enc when ff_start_jack is called from _enc, and the same with _dec [03:13:23 CET] <Timothy_Gu> ethe: ah [03:14:11 CET] <Timothy_Gu> in that case remove jack_set_process_callback call in jack.c and stick it into the two individual files [03:14:53 CET] <ethe> >.< why didn't I think of that... thanks [03:56:43 CET] <Compn> Zeranoe : killing off xp support ? [03:57:05 CET] <Zeranoe> Compn: Yes [03:57:08 CET] <Compn> aww ;P [03:57:54 CET] <Compn> just for dailies :P [03:57:56 CET] <Compn> but still aww. [03:58:26 CET] <Zeranoe> Is that your primary OS? [04:07:30 CET] <Compn> my primary testing box [04:07:54 CET] <Compn> Uptime: 15wks 3days 12hrs 7mins 47secs [04:09:22 CET] <Compn> not truely important though [04:12:31 CET] <Compn> i dont know what the statistics of the users on your site are of course [04:12:36 CET] <Compn> maybe winxp is in minority :P [04:12:55 CET] <ashish247> Hi [04:13:07 CET] <Compn> hopefully it is. hopefully people have upgraded, although calling windows 10 anything positive remains difficult. [04:13:25 CET] <ashish247> I want to contribute to FFmpeg in gsoc 2016 [04:13:35 CET] <Compn> ashish247 : great! greetings. [04:13:53 CET] <jamrial> mingw-w64 should switch to defaulting to NT6+ API instead of XP already [04:13:57 CET] <ashish247> I am interested in project creating fuzzing [04:14:14 CET] <ashish247> Hey Compn [04:14:39 CET] <ashish247> Please tell me more about the project [04:14:49 CET] <Compn> i would but i got yelled at last time :D [04:14:51 CET] <Compn> ehe [04:15:30 CET] <Compn> ashish247 : talk to kierank and Timothy_Gu [04:15:39 CET] <ashish247> Did you worked for same project last time? [04:16:02 CET] <Compn> ashish247 : i just mean another student wanted to ask questions about fuzz project , and i gave wrong info :) [04:16:04 CET] <ashish247> When will be they online? [04:16:36 CET] <ashish247> Ohhh...you can give me some basic idea [04:16:53 CET] <Compn> ashish247 : no idea, try by email -- kieran at kunhya dot com and timothygu99(a)gmail.com [04:17:00 CET] <Compn> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016#Createafuzzingtes… [04:17:05 CET] <Compn> you saw this page ? [04:17:17 CET] <ashish247> No [04:17:29 CET] <ashish247> Thanks [04:17:49 CET] <Compn> ashish247 : ok, try to work on the qualification task there. building fffuzz etc [04:17:54 CET] <Compn> no problem :) [04:17:54 CET] <ashish247> So many students are working on same project?? [04:18:04 CET] <Compn> many students apply for the same project [04:18:25 CET] <Compn> then we have to find those students who actually give some effort and have good communications [04:18:39 CET] <Compn> e.g. idling on irc [04:18:41 CET] <ashish247> And what can I do to get ahead of them [04:19:01 CET] <ashish247> Cool [04:19:03 CET] <Compn> idle on irc, do the qualification task, which means you have to fuzz some parts of ffmpeg and create a patch to fix it [04:19:30 CET] <ashish247> Do I have enough time left to get selected? [04:19:43 CET] <ashish247> I kind of started late [04:19:44 CET] <Compn> https://developers.google.com/open-source/gsoc/timeline [04:20:18 CET] <Compn> the application starts march 14th, which is in 2 weeks. so you have 2 weeks to fuzz ffmpeg and find a crash and make a patch to fix the patch [04:20:20 CET] <Compn> plenty of time [04:20:39 CET] <ashish247> Yup [04:20:42 CET] <Compn> assuming you know how git and building applications works. [04:21:12 CET] <Timothy_Gu> ashish247: do you have any specific question about the task [04:21:34 CET] <ashish247> Yes [04:22:21 CET] <Timothy_Gu> ashish247: So what is your question? [04:22:52 CET] <Compn> is our ffmpeg wiki page on the gsoc page ? seems like students are missing our wiki page. [04:22:55 CET] <ashish247> I know c and git....so am I good enough for project [04:23:15 CET] <Compn> ashish247 : any experience working on open source projects? [04:23:28 CET] <sej> ashish247: as Compn said, try to do the qualification task first :) [04:23:29 CET] <ashish247> Not really [04:23:36 CET] <Compn> its not a prerequisite , just curious. [04:23:39 CET] <Timothy_Gu> ashish247: many people know C and Git, and all of them are "good enough" for this task. [04:23:41 CET] <Compn> yeah , do the qualification task. :) [04:23:53 CET] <Timothy_Gu> ashish247: And yes, many students have expressed the willingness to do this project [04:24:04 CET] <ashish247> I will first do the qualification task [04:24:09 CET] <Compn> Timothy_Gu : do you know if any projects in our list have less students asking ? [04:24:12 CET] <Timothy_Gu> so we will have to pick one student [04:24:16 CET] <Timothy_Gu> Compn: everything else :p [04:24:21 CET] <Compn> oh :D [04:24:23 CET] <sej> lol [04:24:39 CET] <Compn> ashish247 : there are less students working on our other project ideas, if you want to choose another. [04:24:40 CET] <ashish247> Hahaha [04:25:41 CET] <ashish247> Actually this project got my attention...I haven't looked into other projects [04:25:42 CET] <Compn> some of the other project ideas are more complicated than a fuzzing system :P [04:25:55 CET] <Compn> the other ideas on this page i mean, https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016 [04:26:04 CET] <sej> ^true story :P [04:26:29 CET] <ashish247> Can you suggest me something taking into account that I am a beginner [04:26:59 CET] <Compn> sej : you seem helpful, are you new? [04:27:02 CET] <Compn> :) [04:27:09 CET] <sej> yup :) [04:27:38 CET] <Timothy_Gu> ashish247: what subjects are you studying in college? [04:27:43 CET] <Timothy_Gu> (or major) [04:28:29 CET] <ashish247> Currently I am studying Operating system, algorithms, theory of compiler [04:28:32 CET] <Timothy_Gu> We offer a lot more "fun" but also more challenging projects, where you can learn a lot more (that's not to say that the fuzzing project is any less important to us) [04:29:04 CET] <Timothy_Gu> ashish247: so you have some experiences with algorithms etc. Then I would _really_ recommend looking at some other projects [04:29:06 CET] <ashish247> I am good at data structure [04:29:31 CET] <sej> imo your personal interests and projects help you more than ur university courses :P [04:29:40 CET] <ashish247> Please suggest me some [04:29:43 CET] <Compn> i think "dicom support" might be fairly easy, as there exists specs and implementations. [04:29:52 CET] <Compn> well not easy, but ... not extremely difficult [04:30:52 CET] <ethe> Timothy_Gu: So, none of the write functions are being called for some reason. (ffmpeg -f jack -i "1" -f jack "2") is my cmd. https://gist.github.com/3b68c313ff1a6603d381 "Output file #0 does not contain any stream" is the err. Maybe you could point out an obvious mistake? [04:31:18 CET] <Compn> self test coverage would also be beginner class. [04:31:24 CET] <Compn> i think. i could be wrong... [04:31:41 CET] <Compn> truehd encoder = difficult [04:31:46 CET] <ashish247> Actually ai was interested in fuzzing one [04:31:52 CET] <Timothy_Gu> Compn: yes, and therefore somebody has already set their eye on it :) [04:32:10 CET] <Timothy_Gu> ethe: can you post the log? [04:32:49 CET] <Timothy_Gu> ethe: also be careful with your editor configuration (the file contains some tabs) [04:33:00 CET] <Compn> ashish247 : no problem. just trying to help. let us know if you have more questions or comments. how can we help you? :) [04:33:18 CET] <sej> cehoyos not very active on irc? [04:33:29 CET] <Timothy_Gu> sej: not always [04:33:29 CET] <ethe> Timothy_Gu: yeah, I'm gonna fix it all up before submitting. I've been switching between editors. output: https://gist.github.com/66ef4adf168d08f6cab0 [04:33:30 CET] <Compn> once in a while he comes on irc [04:33:47 CET] <sej> oh okay [04:33:49 CET] <sej> ty [04:33:50 CET] <Compn> sej : he is easily reachable by email though [04:34:17 CET] <sej> okay, thanks [04:34:27 CET] <Compn> i think i can safely say that all ffmpeg devs are easily reached by email (when they arent on vacation anyways) [04:34:44 CET] <Compn> current ffmpeg devs* [04:34:54 CET] <sej> do they 'work' in ffmpeg :O [04:35:05 CET] <sej> i mean they get paid n shit? [04:35:10 CET] <sej> pardon my language :P [04:35:29 CET] <Compn> no, this is volunteer thing. some companies pay devs to work on features once in a while though [04:35:35 CET] <sej> oh [04:35:41 CET] <Compn> some devs run companies using ffmpeg [04:35:52 CET] <sej> ya, have seen that somewhere in the site [04:35:54 CET] <Compn> working on open source project can get you good jobs! :P [04:36:31 CET] <sej> :) [04:37:01 CET] <ethe> and it's fun [04:37:26 CET] <Timothy_Gu> ethe: can't spot anything obvious... [04:37:37 CET] <cone-824> ffmpeg 03Mats Peterson 07master:ba40b3520d91: lavf/utils: Normalize AVPacket.data to native endian in ff_get_packet_palette() [04:37:38 CET] <cone-824> ffmpeg 03Mats Peterson 07master:5111c1bef389: lavf/movenc: Add support for palette side data [04:37:39 CET] <cone-824> ffmpeg 03Michael Niedermayer 07master:2761e250cc87: fate: add qtrle/mace6 stream copy test [04:37:45 CET] <ethe> :/ [04:38:01 CET] <Timothy_Gu> I have the feeling that I'm missing something VERY obvious... [04:38:36 CET] <Timothy_Gu> ah [04:38:51 CET] <Timothy_Gu> ethe: I think you need a AVOutputFormat.audio_codec [04:38:51 CET] <ethe> Right. It's 3:40am, I have school in 4 hours. If you do find something please ping me, but I'm going to sleep. [04:39:07 CET] <ethe> oh. [04:39:53 CET] <Timothy_Gu> yeah that's probably it. ffmpeg doesn't know which codec to pick without that [04:40:54 CET] <sej> who has school at 7 40am :O [04:40:59 CET] <sej> s a d [04:41:11 CET] <ethe> sweet. it segfaulted, progress! [04:41:41 CET] <ethe> sej: that's when I can sleep til, it starts at 8:20 [04:41:57 CET] <Timothy_Gu> ethe: i usually wake up at 5:30 [04:42:03 CET] <sej> hmm [04:42:05 CET] <ethe> Timothy_Gu: thanks again [04:42:08 CET] <Timothy_Gu> np [04:43:26 CET] <sej> Timothy_Gu: not mentoring any other projects? [04:43:34 CET] <sej> i mean other than fuzzing [04:43:35 CET] <Timothy_Gu> sej: nah [04:43:52 CET] <Timothy_Gu> considering I'm younger than the minimum age allowed for a GSoC student one is enough :) [04:44:20 CET] <sej> haha [04:44:35 CET] <sej> no min age for mentors eh? xD [04:45:14 CET] <Timothy_Gu> sej: there is one (13 I believe) [04:45:18 CET] <Timothy_Gu> they just decreased it this year [04:45:25 CET] <Timothy_Gu> last year you had to be 18 to mentor [04:45:31 CET] <sej> oooh [04:45:38 CET] <sej> you got lucky ;) [04:45:47 CET] <Timothy_Gu> yeah I guess [04:45:48 CET] <sej> rather, the students got lucky ;) [04:45:59 CET] <Timothy_Gu> I actually really want to do that project myself :) [04:46:11 CET] <sej> hehe [05:05:57 CET] <Compn> Timothy_Gu is younger than 13? [05:06:28 CET] <ashish247> Thanks....Compn n Timothy_Gu [05:07:31 CET] <ashish247> Actually ....my teacher caught me while texting [05:07:52 CET] <ashish247> Looking forward to working with u guys [05:09:37 CET] <Timothy_Gu> Compn: no, that's why I can mentor [05:10:29 CET] <Timothy_Gu> but I was 13 when I sent my first patch to ffmpeg :) [05:10:48 CET] <Timothy_Gu> ashish247: good luck! [07:49:10 CET] <ashish247> Hi [07:49:41 CET] <ashish247> What is the qualifying task of project Discom Support? [07:51:17 CET] <sej> mail cehoyos [07:52:09 CET] <ashish247> Email id? [07:52:41 CET] <Shiz> on the page [07:58:47 CET] <ashish247> Can't find it [08:04:38 CET] <Timothy_Gu> ashish247: > Mentor: Carl Eugen Hoyos (cehoyos in #ffmpeg-devel on Freenode IRC, ce AT hoyos.ws) [08:04:56 CET] <Timothy_Gu> ce(a)hoyos.ws [08:05:31 CET] <ashish247> Thanks buddy [08:06:10 CET] <ashish247> This project is given last in the list does that mean it have least of getting selected? [08:06:16 CET] <ashish247> Chance* [08:10:26 CET] <Timothy_Gu> ashish247: the order makes no difference [08:10:40 CET] <Timothy_Gu> ashish247: plus we can have many difference projects [08:11:08 CET] <ashish247> Ok buddy [08:54:38 CET] <ubitux> PATCH v5 1/4 v3 [08:54:40 CET] <ubitux> lol [08:54:51 CET] <wm4> wat [08:55:13 CET] <ubitux> you have him on ignore list? [08:55:32 CET] <wm4> no I'm just selecting all his posts and click mark as read [08:55:47 CET] <wm4> but why does he have two version markers there [08:56:08 CET] <ubitux> semantic versioning! [09:24:51 CET] <ethe> "but I was 13 when I sent my first patch to ffmpeg :)" pretty impressive [09:27:03 CET] <sej> indeed [09:48:23 CET] <mateo`> wm4: i just had a look at the API you proposed, it looks like the mediacodecdec could be a good candidate for it. It would make possible to remove the internal buffer queue of the decoder. [09:49:42 CET] <mateo`> but when mediacodec returns "[...]_TRY_GAIN", it does not guarantee that it's because you have to send/receive on the other end of the decoder [09:50:31 CET] <mateo`> and the different timeouts will remain [09:55:55 CET] <wm4> mateo`: what about the async API? (http://sprunge.us/OBcM) [09:56:10 CET] <wm4> are these timeouts fundamentally needed? [10:05:54 CET] <mateo`> I would say yes, not 100% sure though [10:07:16 CET] <mateo`> I'll experiment, see how it goes if I remove them [10:07:55 CET] <mateo`> But I've seen (I don't remember where) that for some implementations, it allows the codec to do some processing [10:09:41 CET] <mateo`> wm4: on the other hand, mediacodec have an async API since Android 5 [10:12:16 CET] <wbs> yes, unless you use the new async mediacodec api, you need to use the timeouts, cleverly [10:12:31 CET] <wm4> who designed this crap [10:14:49 CET] <mateo`> wbs: thanks for the confirmation [10:17:07 CET] <wbs> (i.e. ideally zero timeouts, and once the input doesn't provide any free buffers, a longer blocking timeout wait for the output - and it might be good to still periodically poll the input as well) [10:19:56 CET] <mateo`> what I have at the moment is, fixed input timeout, no timeout on output until it returns a buffer (so the encoder gets feeded at fast as possible) [10:20:53 CET] <mateo`> it works quite well that way (at least with sw output) [10:41:40 CET] <cone-696> ffmpeg 03Paul B Mahol 07master:79a54f30c8ba: avfilter/af_sofalizer: fix crash when ir size is not aligned, usually when n_samples are not power of 2 [10:46:21 CET] <ubitux> durandal_170: http://anime.stackexchange.com/questions/5092/why-are-there-sometimes-darke… if you want to write a filter to detect peaks violating the regulation [10:50:51 CET] <cone-696> ffmpeg 03Agatha Hu 07master:362e05f1ea05: avcodec/nvenc: Fix H264 and HEVC vui info update [11:02:47 CET] <durandal_170> ubitux: you havent seen deflash filter I posted? [11:02:59 CET] <ubitux> :o [11:12:25 CET] <jrosser> https://en.wikipedia.org/wiki/Harding_test [11:15:30 CET] <kierank> durandal_170: there is a document about what the test needs to hit [11:15:46 CET] <kierank> jrosser: "other tests are available" :) [11:15:50 CET] <jrosser> indeed [11:19:51 CET] <ubitux> https://haneefmubarak.com/2016/02/25/assembly-optimizations-i-un-packing-st… [11:27:05 CET] <ubitux> (tl;dr owned by gcc at writing simd) [11:37:07 CET] <wm4> ubitux: interesting [11:37:15 CET] <wm4> also lol at icc being slowest [11:44:24 CET] <durandal_170> kierank: I see no documents [11:45:08 CET] <kierank> I will find them for you soon [12:02:15 CET] <kierank> durandal_170: http://stakeholders.ofcom.org.uk/binaries/broadcast/guidance/831193/section… [12:02:16 CET] <kierank> annex 1 [12:10:43 CET] <kierank> and email tim nich who might be able to help more [12:53:04 CET] <happysingh33> hey [12:53:59 CET] <happysingh33> I am having difficulty in deciding project for GSOC...help me guys [12:54:15 CET] <happysingh33> I am familiar with c++ [12:55:19 CET] <wm4> choose what is most interesting to you [13:47:37 CET] <durandal_170> michaelni: what's takes so long to push? [13:52:39 CET] <cone-696> ffmpeg 03Michael Niedermayer 07master:ae76b8422133: avcodec: Extend fft to size 2^17 [13:55:52 CET] <ismail> I have a very simple patch for enabling schannel on cross mingw-w64 on Linux: http://susepaste.org/view/raw/18997210 [13:55:55 CET] <ismail> can someone apply it? [13:56:04 CET] <ismail> it only lowercases lib names and header [13:56:35 CET] <rcombs> ismail: are those names valid with msvc as well? [13:56:54 CET] <ismail> rcombs: msvc is case-insensitive [13:57:02 CET] <rcombs> ah [13:57:15 CET] <rcombs> probably fine then; send to the ML and I'd expect it'll get applied [13:57:29 CET] <rcombs> (I can't test myself; no easily-accessible windows system) [13:57:33 CET] <ismail> well didn't want to register for one patch but guess I'll do so [13:57:55 CET] <rcombs> I don't _think_ you need to subscribe to send a patch [13:58:17 CET] <ismail> oh [13:58:21 CET] <rcombs> unsubscribed mails just need to be manually approved, but someone'll do that [13:58:25 CET] <nevcairiel> tell mingw to fix their shit then, Secur32 is spelled like that in msvc =p [13:58:52 CET] <ismail> windows is braindead nothing new there [13:58:58 CET] <wm4> I thought gcc now has a hack to "fix" include filenames [13:59:05 CET] <wm4> or did I dream that [13:59:14 CET] <ismail> wm4: well my gcc 5.3.0 doesn't have such magic :-) [13:59:17 CET] <nevcairiel> why is it braindead to use an uppercase letter =p [13:59:18 CET] <ismail> though it does make sense [13:59:23 CET] <rcombs> last I saw mingw is also missing a define or two [13:59:32 CET] <rcombs> but maybe that was on pre-mingw-w64 [13:59:47 CET] <ismail> rcombs: indeed, time and time I send fixes for those and wine developers do a lot of work too [14:06:23 CET] <durandal_170> michaelni: still error with afftfilt, looks like every second sample is 0 [14:25:54 CET] <Daemon404> carl wants to keep the N number [14:25:58 CET] <Daemon404> shock and awe [14:27:01 CET] <ismail> wtf is that N- anyway [14:27:06 CET] <wm4> a random number [14:27:12 CET] <wm4> which is increased linearly [14:27:23 CET] <wm4> why are there so many version numbers [14:27:31 CET] <Daemon404> it's akin to a svn revision. it's the commit count [14:27:43 CET] <wm4> (release number, the N number, each sub-lib has 2 more...) [14:27:53 CET] <ismail> ah [14:28:07 CET] <kierank> N is quite useful, no? [14:28:11 CET] <Daemon404> to whom and why [14:28:15 CET] <Daemon404> i have never, ever used it [14:28:17 CET] <ismail> not to me [14:28:18 CET] <ubitux> is there a problem with it? [14:28:29 CET] <ismail> ffmpeg version N-78868-gecba35b Copyright (c) 2000-2016 the FFmpeg developers [14:28:38 CET] <ismail> how do I know which ffmpeg version is this [14:28:42 CET] <Daemon404> [13:28] <@ubitux> is there a problem with it? [14:28:44 CET] <Daemon404> woops [14:28:50 CET] <Daemon404> git lgo ecba35b [14:28:52 CET] <Daemon404> log even [14:28:55 CET] <ubitux> it actually gives you a hint about how much above from last tag it is [14:29:03 CET] <ismail> Daemon404: users don't have a git tree [14:29:16 CET] <ubitux> so when you have snapshot tarballs based on the same tag, you know which one to take [14:29:27 CET] <ubitux> i actually "use" that feature [14:29:42 CET] <Daemon404> "how much above" is not really useful [14:29:47 CET] <Daemon404> in any practical sense [14:29:58 CET] <ubitux> it helps comparing multiple tarballs [14:29:58 CET] <wm4> I don't even know how to look up a git commit based on it [14:30:06 CET] <wm4> maybe one could search for it in gitk [14:30:06 CET] <Daemon404> wm4, you cant [14:30:13 CET] <Daemon404> not easily [14:30:23 CET] <Daemon404> ubitux, why the hell are you using tarballs from git [14:30:29 CET] <wm4> (it shows the commit "number", so you can do manual binary search by scrolling around) [14:30:32 CET] <Daemon404> use a release tarball or use got [14:30:33 CET] <Daemon404> git [14:30:52 CET] <ubitux> because i need to bump snapshot regularly [14:31:00 CET] <ubitux> it's like micro releases [14:31:01 CET] <wm4> the tarballs don't contain the N number? [14:31:08 CET] <Daemon404> "bump snapshot"? [14:31:21 CET] <ubitux> wm4: i create them with the git describe [14:31:33 CET] <ubitux> and i have several tarball, i know which one to take based on that number [14:31:38 CET] <Daemon404> ITC: https://xkcd.com/1172/ [14:31:50 CET] <ubitux> why do you want to remove it? [14:32:05 CET] <ubitux> i mean will it solve a problem for you to remove it? [14:32:08 CET] <Daemon404> it causes more confusion than it helps, IMO [14:32:12 CET] <Daemon404> for users filing bugs [14:32:22 CET] <nevcairiel> its not about removing it, its about putting some more meaningful information there [14:32:36 CET] <ubitux> i'd prefer to keep it, i feel that information is useful [14:32:41 CET] <nevcairiel> I have no clue how old 78868 really is, it could be from 0.8 for all i know [14:33:00 CET] <ismail> it would be nice to include major version in there [14:33:02 CET] <Daemon404> i feel like this is a biproduct of the insane versionign and release management [14:35:22 CET] <wm4> <ubitux> and i have several tarball, i know which one to take based on that number <- I don't understand the use-case [14:35:37 CET] <Daemon404> neitehr do i [14:35:49 CET] <Daemon404> see my xkcd link [14:35:55 CET] <ubitux> you have several snapshots in a directory [14:36:02 CET] <ubitux> you wanna find the latest one [14:36:03 CET] <Daemon404> but *why* [14:36:10 CET] <Daemon404> how do you end up in such a situation [14:36:12 CET] <ubitux> because i'm doing micro releases [14:36:20 CET] <Daemon404> [13:36] <@Daemon404> but *why* [14:36:38 CET] <nevcairiel> and why wouldnt that be possible if it says n3.1-dev-422 instead [14:36:41 CET] <ubitux> because i need a smaller granularity than 3 months [14:37:05 CET] <ubitux> what's 422? [14:37:20 CET] <nevcairiel> the number of commits since the tag [14:37:28 CET] <ubitux> well that's fine then [14:37:34 CET] <nevcairiel> you know, just like 78868, just with more context [14:37:47 CET] <ubitux> but aren't you talking about dropping that number? [14:37:50 CET] <ubitux> i don't get it [14:37:52 CET] <Daemon404> why tarballs [14:37:55 CET] <Daemon404> what precludes git [14:37:59 CET] <Daemon404> and just pinning it to a has [14:38:00 CET] <Daemon404> h [14:38:14 CET] <ubitux> i don't understand the question [14:38:26 CET] <Daemon404> why do you have a giant dir of micro version tarballs for whatever the hell you are doing [14:38:32 CET] <Daemon404> why do you not use git + hash [14:39:31 CET] <ubitux> i'm working on the git repository, then sometimes i need a release, so git archive a tarball and name it using git describe, this tarball is then uploaded in a directory, and i can point out to that release [14:39:47 CET] <Daemon404> it sounds a heck of a lot like a way to just vendor and track specific ffmpeg versions [14:39:51 CET] <ubitux> sometimes i need to rollback, so i just have to look at the release previously using that number [14:40:07 CET] <Daemon404> ... or... use a git submodule, which has teh netire history of changes [14:40:16 CET] <Daemon404> and when you update, and what all previosu versions where [14:40:22 CET] <Daemon404> i dont know what makes you require tarballs [14:40:48 CET] <ubitux> git submodule are shit, and the package manager takes tarball as input [14:41:19 CET] <Daemon404> the former argument is BS when its useful for exactly this usecase [14:41:24 CET] <Daemon404> and kind of dogmatic [14:41:32 CET] <Daemon404> the latter sounds like a tooling problem [14:41:36 CET] <Daemon404> but ill give you that one [14:41:40 CET] <Daemon404> nobody wants to fix package managers [14:43:33 CET] <omerjerk> can anyone exaplain the reason of the assert statement in the definiteion of get_bits function ? - https://ffmpeg.org/doxygen/trunk/get__bits_8h-source.html [14:43:43 CET] <omerjerk> why has n to be smaller than 25 ? [14:43:56 CET] <omerjerk> *smaller than 26 [14:43:57 CET] <Daemon404> because thats the max number of bits that function supports [14:44:02 CET] <Daemon404> and it is an internal function [14:44:14 CET] <Daemon404> there is get_bits_long for larger sizes [14:44:18 CET] <Daemon404> probably for perf reasons [14:44:34 CET] <omerjerk> ohkay. thanks. [14:45:04 CET] <BBB> omerjerk: the internal variable that holds cached bytes is unsigned int, so 32 bit [14:45:23 CET] <Daemon404> *at least [14:45:25 CET] <BBB> omerjerk: and you have an offset within the variable for bit offset, so you can have 0-7 bits already rad in the 32bit variable [14:45:35 CET] <BBB> so it can hold 32-(0-7) filled bits [14:45:42 CET] <BBB> which is (worst-case) 32-7=25 [14:45:59 CET] <BBB> omerjerk: ergo, 25 [14:49:19 CET] <omerjerk> ohkay. understood. thanks. [15:24:28 CET] <durandal_170> michaelni: had time to look at it? [16:05:41 CET] <ashish247> Hey [16:06:04 CET] <ashish247> Is ffmpeg available for Ubuntu 14.04? [16:06:16 CET] <cone-696> ffmpeg 03Michael Niedermayer 07master:305344d89e21: avcodec/fft: Add revtab32 for FFTs with more than 65536 samples [16:06:17 CET] <cone-696> ffmpeg 03Michael Niedermayer 07master:500cb984710c: avfilter/af_afftfilt: Extend to 17bit fft [16:11:11 CET] <ethe> ashish247: it's available for nearly all platforms [16:11:54 CET] <ashish247> ethe: thanks [16:12:22 CET] <wm4> ashish247: ask such questions on #ffmpeg [17:14:06 CET] <cone-696> ffmpeg 03Derek Buitenhuis 07master:93629735d76c: avformat: Add a protocol blacklisting API [17:15:23 CET] <cone-696> ffmpeg 03Anton Khirnov 07master:ec4c48397641: lavf: add a protocol whitelist/blacklist for file opened internally [17:15:24 CET] <cone-696> ffmpeg 03Derek Buitenhuis 07master:063b26d35857: Merge commit 'ec4c48397641dbaf4ae8df36c32aaa5a311a11bf' [17:17:43 CET] <cone-696> ffmpeg 03Vittorio Giovara 07master:0837d1dfe28f: libx264: Fix noise_reduction option assignment [17:17:44 CET] <cone-696> ffmpeg 03Michael Niedermayer 07master:f435d081b0a6: h264: Add an AVClass pointer to H264Context [17:17:45 CET] <cone-696> ffmpeg 03Marton Balint 07master:5e555f93009f: mpeg12enc: always write closed gops for intra only outputs [17:17:46 CET] <cone-696> ffmpeg 03Derek Buitenhuis 07master:a38eadd7e93d: Merge commit '5e555f93009f0605db120eec78262d0fe337e645' [17:18:52 CET] <cone-696> ffmpeg 03Diego Biurrun 07master:9328adcc8012: fate: Be silent when fetching Git updates [17:18:53 CET] <cone-696> ffmpeg 03Derek Buitenhuis 07master:18d8398caf91: Merge commit '9328adcc8012a1b0e00c465c85b5453589a4f5f7' [17:19:13 CET] <atomnuker> Daemon404: libavfilter macro went from 102 back to 100 after the blacklisting API addition [17:19:26 CET] <atomnuker> *micro version [17:21:27 CET] <nevcairiel> thats fine, when minor is incremented then micro resets to 100 [17:21:56 CET] <atomnuker> ah, makes sense [17:22:23 CET] <Daemon404> yes [17:22:54 CET] <cone-696> ffmpeg 03Diego Biurrun 07master:cd846b479774: fate: Ignore errors from concatenating report files [17:22:55 CET] <cone-696> ffmpeg 03Diego Biurrun 07master:257b30af8ec5: x86: hevc: Fix linking with both yasm and optimizations disabled [17:22:56 CET] <cone-696> ffmpeg 03Derek Buitenhuis 07master:89790ba2bfc9: Merge commit 'cd846b47977485bd4063e77a3324e6b7840567a2' [17:22:57 CET] <cone-696> ffmpeg 03Derek Buitenhuis 07master:61c554bd5fee: Merge commit '257b30af8ec520c1635092e429606c62d3bcca63' [17:23:47 CET] <Daemon404> nevcairiel, next commit is lavc: add codec parameters API [17:23:58 CET] <Daemon404> it doesnt break, but im unsure where i should merge up to, if at all [17:24:04 CET] <Daemon404> or where to start the Big Effort branch [17:24:57 CET] <nevcairiel> pushing the api without everything else ready seems like a waste, so probably start it there [17:25:08 CET] <Daemon404> i thought as much [17:25:26 CET] <Daemon404> where shall we coordinate [17:26:13 CET] <wm4> when you push it and something is fucked, you can't unpush it [17:26:16 CET] <wm4> so a branch seems better [17:26:19 CET] <Daemon404> yes [17:29:48 CET] <nevcairiel> just create a branch on github, merge the 2 api commits in and then the big commit, just commit it with all conflicts in place, and we can then slowly work on fixing those (and all other demuxers they dont have) [17:30:10 CET] <nevcairiel> thats how we did it last time [17:30:28 CET] <Daemon404> ok [17:30:37 CET] <Daemon404> i need a list of people to give access to [17:30:43 CET] <Daemon404> and their github names [17:31:00 CET] <nevcairiel> either that or just pull from whomever asks for it =p [17:31:00 CET] <michaelni> Daemon404, ./libavformat/avformat.h:1874:11: error: duplicate member protocol_blacklist [17:31:07 CET] <Daemon404> wtf? [17:31:41 CET] <Daemon404> kill me now [17:31:45 CET] <Daemon404> what a collosal fuck up [17:31:55 CET] <Daemon404> i removed the wrong struct memeber when moving it down [17:32:07 CET] <Daemon404> at least the ABI technicslly didnt break >_> [17:32:23 CET] <nevcairiel> well ABI i snt broken when you cant build a new B [17:32:24 CET] <nevcairiel> :D [17:32:33 CET] <Daemon404> its also the same size [17:34:01 CET] <cone-696> ffmpeg 03Derek Buitenhuis 07master:fb2f16459894: avformat: Fix member name 10L [17:34:06 CET] <Daemon404> michaelni, fixed [17:35:19 CET] <atomnuker> 3 minutes, not bad [17:35:32 CET] <wm4> 10L? is this about cola? [17:35:49 CET] <wm4> oh commit message says so [17:35:53 CET] <wm4> how classic [17:35:57 CET] <Daemon404> it's an old joke [17:36:33 CET] <Daemon404> atomnuker, i wanted to avoid carl appearing [17:36:39 CET] <Daemon404> and harassing me [17:36:47 CET] <kierank> fuck carl [17:36:58 CET] <Daemon404> do you have his name on hilight ot something, kierank [17:37:02 CET] <Daemon404> on* [17:37:03 CET] <kierank> no it's a reflex [17:37:07 CET] <jamrial> lol [17:37:19 CET] <kierank> see the name and I have to type fuck carl [17:46:00 CET] <JEEB> wm4 the 10L creeps into you. had to explain it to my coworkers, too [17:49:23 CET] <Timothy_Gu> "Bonus point if a version of this script is available online as a CGI." is this 2003? [17:50:35 CET] <thardin> who needs CGI when you can have your visitors run your code for you [17:51:35 CET] <thardin> by which I mean CGI is a perfectly usable technology [17:51:39 CET] <Daemon404> https://github.com/dwbuiten/FFmpeg/tree/codecpar [17:51:41 CET] <Daemon404> who wants to help [17:52:07 CET] <wm4> that's a nice list of conflicting files [17:52:15 CET] <Daemon404> hence TEP [17:52:17 CET] <Daemon404> is the name [17:52:32 CET] <Daemon404> ill add anyone to the push list on it who wants to help [17:52:47 CET] <wm4> github almost kills itself on the diff [17:52:57 CET] <Daemon404> using githubs diff ui is a bad idea [17:52:59 CET] <Daemon404> for any large commit [17:53:38 CET] <wm4> so did you automatically rename all AVStream.codec to AVStream.codecpar? [17:53:44 CET] <Daemon404> i didnt touch anything [17:53:52 CET] <Daemon404> [16:26] <@Daemon404> yes [17:53:52 CET] <Daemon404> [16:29] <@nevcairiel> just create a branch on github, merge the 2 api commits in and then the big commit, just commit it with all conflicts in place, and we can then slowly work on fixing those (and all other demuxers they dont have) [17:53:56 CET] <Daemon404> [16:30] <@nevcairiel> thats how we did it last time [17:53:58 CET] <wm4> I'm wondering why there are conflicts then [17:53:59 CET] <Daemon404> i did this [17:54:12 CET] <wm4> e.g. looking at alsa_dec.c [17:54:27 CET] <wm4> I must be missing something [17:54:46 CET] <Daemon404> st->codec->frame_size = s->frame_size; [17:54:48 CET] <Daemon404> we had this extra [17:54:50 CET] <Daemon404> git blew up [17:54:53 CET] <wm4> oh [17:55:10 CET] <wm4> so what's there to do? 1. fix trivial conflicts, 2. ...? [17:55:15 CET] <nevcairiel> my github name is my nick, i'll see what i can do later today [17:55:27 CET] <Daemon404> wm4, start with fixing all conflicts [17:55:29 CET] <nevcairiel> wm4: fix all the things [17:55:34 CET] <Daemon404> and then we can move to fixing stuff they dont have [17:55:36 CET] <Daemon404> and seeing if it builds [17:55:37 CET] <Daemon404> lol. [17:55:57 CET] <Daemon404> added both of you [17:56:00 CET] <nevcairiel> you can build individual files for testing, at least, but runtime tests are hard unless you configure carefully [17:56:08 CET] <Daemon404> true [17:56:19 CET] <nevcairiel> anyhow dinner time [17:56:31 CET] <Daemon404> ubitux / atomnuker / kierank / jamrial - anyone? [17:56:35 CET] <Daemon404> michaelni too [17:57:01 CET] <jamrial> i'll take a look. i'll have to adapt the few de/muxers i wrote anyway [17:57:12 CET] <Daemon404> github nick? [17:57:13 CET] <wm4> how do you partition the work? [17:57:19 CET] <jamrial> same as my nick [17:57:22 CET] Action: ubitux mixed up lines and though Daemon404 was inviting him to dinner [17:57:32 CET] <Daemon404> ubitux, sure just head over to britain [17:58:12 CET] <ubitux> anyway alright i'll help [17:58:25 CET] <Daemon404> added [17:58:26 CET] <ubitux> who handles what? [17:58:32 CET] <wm4> ubitux: that's the question [17:58:42 CET] <jamrial> instead of giving access, wouldn't it be better to just accept pull requests? [17:58:51 CET] <Daemon404> jamrial, thats a ton of work for one person [17:58:58 CET] <jamrial> fair enough [17:59:03 CET] <Daemon404> for now, we could just copy/paste the conflicts to an etherpad and just remove them as we push fixes [17:59:33 CET] <Daemon404> unless someone has a better idea [17:59:45 CET] <Daemon404> im open to anything. [17:59:51 CET] <wm4> so if someone wants to fix it -> add to etherpad, when done fixing -> add (fixed) to it [17:59:59 CET] <Daemon404> nah [18:00:03 CET] <Daemon404> start with a giant list [18:00:06 CET] <Daemon404> and just remove it [18:00:11 CET] <Daemon404> once fixed [18:00:35 CET] <wm4> "reserving" files seems like a good idea to avoid double work [18:00:37 CET] <Daemon404> or mark it as WIP or something [18:00:44 CET] <Daemon404> right [18:00:52 CET] <Daemon404> its multiplayer pastebin, nothing specia [18:01:10 CET] <michaelni> also maybe post a patch so others can take a look test / before its pushed if its a really large change [18:01:29 CET] <Daemon404> michaelni, we can send PRs maybe for large changes? [18:01:29 CET] <wm4> how do you post a merge commit as patch [18:01:39 CET] <Daemon404> wm4, there's no merge to be done [18:01:46 CET] <Daemon404> michaelni, oh you mean the whole thing [18:01:49 CET] <Daemon404> ok [18:02:03 CET] <Daemon404> wm4, merge the commit with -s ours, and commit it as a separate commit [18:02:08 CET] <wm4> Daemon404: it's fixing a merge so in theory it should be squashed [18:02:26 CET] <wm4> ok [18:02:39 CET] <ubitux> you merged the 2 commits? [18:02:43 CET] <ubitux> can't be done one at a time? [18:02:50 CET] <Daemon404> ubitux, ? [18:03:03 CET] <Daemon404> i merged the two api additions separately, and cleanly [18:03:07 CET] <Daemon404> theyre before the big broken one [18:03:16 CET] <ubitux> oh ok right sorry [18:03:16 CET] <atomnuker> Daemon404: I'll help [18:03:32 CET] <Daemon404> added [18:03:41 CET] <atomnuker> so AVCodecParameters only affects libavformat? [18:03:52 CET] <Daemon404> theres conflics in avdevice and stuf too [18:03:57 CET] <atomnuker> is it going to replace AVCodecContext [18:04:07 CET] <Daemon404> in lavf [18:04:11 CET] <Daemon404> yea [18:04:14 CET] <Daemon404> i think. [18:04:26 CET] <atomnuker> also, I see libavdevice/pulse was added, didn't we already have a pulseaudio backend? [18:04:37 CET] <Daemon404> oh [18:04:39 CET] <Daemon404> the file can be rm'd [18:04:43 CET] <Daemon404> that was git being dumb [18:04:48 CET] <Daemon404> because the file didnt exist in our tree [18:05:23 CET] <atomnuker> libavdevice/pulse_audio_enc.c libavdevice/pulse_audio_dec.c [18:05:29 CET] <Daemon404> done [18:05:36 CET] <wm4> the idea of codecpar is that the AVStream.codec field goes away [18:05:52 CET] <atomnuker> the new libavdevice/pulse.c uses the pulseaudio simple API [18:05:58 CET] <wm4> so demuxers should set AVStream.codecpar [18:06:13 CET] <Daemon404> anyway... enjoy, boys and girls [18:06:17 CET] <Daemon404> ill start hacking after dinner [18:06:22 CET] <wm4> Daemon404: where's that etherpad [18:06:22 CET] <Daemon404> i have work-work to do, then dinner, first [18:06:29 CET] <Daemon404> wm4, i need to figue it out [18:06:30 CET] <Daemon404> 1 sec [18:06:30 CET] <atomnuker> ours uses the real API [18:07:02 CET] <Daemon404> atomnuker, yes i removed the file in the branch just now [18:07:08 CET] <Daemon404> it wasnt supposed to be there [18:07:57 CET] <wm4> atomnuker: it's just the old version from Libav [18:08:09 CET] <atomnuker> yeah, I know [18:09:54 CET] <Daemon404> https://public.etherpad-mozilla.org/p/ffmpeg-tep2-merge [18:11:02 CET] <Daemon404> anyway... ill start in a few hrs [18:11:08 CET] <Daemon404> i dont expect this will be done quickly [18:12:00 CET] <wm4> and we can push to your repo? (what magic is that) [18:12:05 CET] <Daemon404> wm4, yes [18:12:11 CET] <Daemon404> i added you all as collaborators on the repo [18:14:24 CET] <ubitux> so we can all commit very small "wip" commits? [18:14:36 CET] <Daemon404> yes [18:14:47 CET] <Daemon404> itll all be squashed in the ned [18:14:48 CET] <Daemon404> end [18:15:01 CET] <wm4> jamrial: did you remove my "wip"? [18:15:08 CET] <jamrial> no [18:15:19 CET] <wm4> I thought I added this to srtdec.c [18:15:32 CET] <jamrial> i see it [18:15:35 CET] <jamrial> but not from your color [18:15:42 CET] <Daemon404> i see a wip [18:15:42 CET] <ubitux> wm4: i did, and put it back [18:15:47 CET] <ubitux> sorry [18:15:59 CET] <wm4> jamrial: I see it in red, and you're red in the user list [18:16:05 CET] <Daemon404> gmm [18:16:06 CET] <wm4> but I don't see ubitux or another red user [18:16:10 CET] <jamrial> no, i'm a darker red [18:16:12 CET] <jamrial> check the ogg stuff [18:16:19 CET] <wm4> well there are two jamrials there [18:16:28 CET] <ubitux> i think jamrial filled my nickname [18:16:30 CET] <ubitux> :D [18:16:44 CET] <ubitux> is this better? [18:17:38 CET] <wm4> "not unitux" [18:17:41 CET] <wm4> ok [18:17:59 CET] <ubitux> wat [18:18:11 CET] <wm4> is what I see in the userlist [18:18:22 CET] <ubitux> there is no ubitux? [18:18:30 CET] <wm4> no [18:18:35 CET] <jamrial> oh wow [18:18:35 CET] <wm4> yes [18:18:36 CET] <ubitux> in blue? [18:18:36 CET] <jamrial> lol [18:18:39 CET] <jamrial> yes i did [18:18:40 CET] <wm4> I had to scroll [18:18:46 CET] <jamrial> sorry :p [18:18:58 CET] <wm4> but there's still a "not unitux" [18:19:11 CET] <ubitux> yeah [18:19:21 CET] <jamrial> i see ubitux, blue [18:20:45 CET] <ubitux> wm4: you can fix the "wip" for srtdec :) [18:21:33 CET] <wm4> hm picked swfdec.c and I'm already lost [18:21:38 CET] <jamrial> there's no pix_fmt parameter in AVCodecParameters [18:22:01 CET] <jamrial> and oggparsedirac.c uses codec->pix_fmt [18:22:35 CET] <Daemon404> for what [18:22:45 CET] <wm4> I'd say add such a field for now, we can decide later if it's really needed [18:23:02 CET] <Daemon404> i dont know if its so valid to have a codec pix_fmt [18:23:59 CET] <wm4> in theory there's nothing against it [18:24:42 CET] <Daemon404> afaict that file sets it and nothing uses it [18:24:50 CET] <Daemon404> dirac.c seems not to [18:25:34 CET] <jamrial> nevermind, AVCodecParameters calls it format [18:26:01 CET] <wm4> ubitux: unrelated to the merge, but this fails to probe (vplayer subs) http://sprunge.us/hjUU [18:26:02 CET] <Daemon404> ah [18:26:30 CET] <Daemon404> even when ubitux isnt doing subtitles, he is doing subtitles [18:27:22 CET] <ubitux> wm4: ah, no '.', ok, will try to fix [18:27:47 CET] <ubitux> i'm still waiting for the promised 30GB db of subtitles from opensubtitles [18:27:54 CET] <ubitux> to "fuzz" ffmpeg [18:28:01 CET] <wm4> heh [18:28:08 CET] <wm4> 30gb, wtf [18:28:17 CET] <ubitux> apparently [18:28:19 CET] <ubitux> :D [18:28:23 CET] <ubitux> and only text! [18:30:09 CET] <ubitux> wm4: http://sprunge.us/AeFL [18:30:15 CET] <ubitux> untested, but might work [18:30:21 CET] <ubitux> need to check if it doesn't break some other [18:30:47 CET] <ubitux> actually, maybe not [18:30:54 CET] <ubitux> well, i'll test properly when i'm back home [18:39:55 CET] <wm4> dear god, utils.c looks like a mess [18:40:09 CET] <jamrial> just fixed one thing from that file [18:40:21 CET] <jamrial> since it's needed to get several other files working [18:40:35 CET] <wm4> please mark such changes and push, or it's going to turn into a mess [18:40:42 CET] <jamrial> i pushed it, yes [18:40:45 CET] <wm4> I'm not testing anything yet [18:41:07 CET] <wm4> just that fixed source files actually compile [18:42:32 CET] <Daemon404> you cant really test until they all do [18:42:56 CET] <nevcairiel> could try partial compiles, but that needs careful thinking [18:43:04 CET] <ubitux> the non conflicting files also need adjustment, right? [18:43:12 CET] <nevcairiel> some might [18:43:25 CET] <nevcairiel> easy to verify, there should be virtually no st->codec access anymore after [18:43:29 CET] <wm4> yeah, they'll throw deprecation warnings or fail to compile [18:43:30 CET] <nevcairiel> outside of utils.c [18:43:51 CET] <wm4> what's a good RE to catch ->codec but not ->codecpar [18:44:04 CET] <nevcairiel> ->codec->? [18:44:04 CET] <wm4> hm should be simple enough [18:44:09 CET] <wm4> or that [18:45:24 CET] <Daemon404> wm4, that wont fix the merge conflict crap though [18:45:30 CET] <Daemon404> <<<<<<< [18:46:30 CET] <nevcairiel> yeah its probably better to fix those first [18:47:41 CET] <nevcairiel> i already see the removal of frame_size breaking all sorts of things [18:48:34 CET] <wm4> yeah [18:48:59 CET] <nevcairiel> maybe we should just add it to codecparams before we start removing it in all sorts of places [18:49:09 CET] <jamrial> av_parser_parse2 takes AVCodecContext as parameter. oggparseflac uses it [18:49:27 CET] <jamrial> doesn't happen in libav. not sure how to deal with this [18:49:40 CET] <wm4> worst case, create a dummy avctx [18:50:37 CET] <jamrial> how? [18:50:39 CET] <nevcairiel> what specifically is it meant to lookup, we have a variety of flac header parsing functions [18:52:12 CET] <nevcairiel> the only thing it apparently extracts is the sample rate [18:53:22 CET] <nevcairiel> worst case, build some basic manual parsing like the flac_header function in the same file [18:54:17 CET] <jamrial> any sample using this "old" header around? [18:55:02 CET] <nevcairiel> its unfortunately not covered by fate [18:56:07 CET] <nevcairiel> jamrial: according to the commit it introduced, http://samples.mplayerhq.hu/flac/Yesterday.ogg [18:56:42 CET] <jamrial> ok, thanks [18:56:47 CET] <nevcairiel> also trac 1617 [18:57:05 CET] <nevcairiel> https://trac.ffmpeg.org/ticket/1617 [18:57:08 CET] <nevcairiel> has another sample [18:57:24 CET] <wm4> something here checks strict_std_compliance [18:57:30 CET] <wm4> it was avctx and is now codecpar [18:57:42 CET] <nevcairiel> demuxers that check codec compliance are mad [18:57:50 CET] <wm4> happens a bunch of times [18:57:51 CET] <nevcairiel> dont we have such a field on the formatcontext as well [18:57:54 CET] <jamrial> in any case, maybe we'll have to add a av_parser_parse3() that takes a codecpar instead at some point [18:57:58 CET] <wm4> also it's in muxer code [18:58:13 CET] <nevcairiel> jamrial: i believe they want to revamp parsers as well [18:58:23 CET] <Daemon404> theres a patchset posted [18:58:27 CET] <wm4> oh avformatcontext also has this field [18:58:33 CET] <nevcairiel> Daemon404: thats for bsf isnt it [18:58:36 CET] <Daemon404> oh, right [18:58:40 CET] <Daemon404> i always get the two mixed up [18:59:52 CET] <wm4> more frame_size, derp [19:06:00 CET] <nevcairiel> why did asfdec_o conflict, we dont usually modify that [19:12:00 CET] <jamrial> seek_preroll is in avcodeccontext but not avcodecparameters, and one is supposed to use av_codec_{set,get}_seek_preroll to access it [19:12:19 CET] <wm4> the accessors are probably Libav ABI compar nonsense [19:12:27 CET] <wm4> seek preroll should probably be in codecpar [19:13:20 CET] <jamrial> so we move it and deprecate the accessor functions? [19:13:30 CET] <wm4> yeah [19:14:33 CET] <nevcairiel> yeah seems to fit into the audio padding section in codecpar [19:14:44 CET] <nevcairiel> its kinda like initial padding, but different [19:15:30 CET] <wm4> rawdec.c wants a framerate and time_base field [19:15:34 CET] <wm4> (wat) [19:16:20 CET] <wm4> Libav removed this mechanism at some point [19:16:26 CET] <nevcairiel> somehow i remember at least one of those ending up in codecpar, but i see neither [19:16:27 CET] <nevcairiel> or blind [19:16:49 CET] <wm4> this fuckign code was refactored at leats 10 times [19:16:55 CET] <wm4> rawdec.c I mean [19:17:45 CET] <wm4> oh I see they just are in AVStream [19:22:26 CET] <wm4> st->codecpar->sample_rate = av_q2d(thp->fps); [19:22:28 CET] <wm4> seriously? [19:24:31 CET] <durandal_170> libav code? [19:24:40 CET] <wm4> yes [19:25:09 CET] <mateo`> I haven't followed the API changes, does codecpar stands for codec parameters ? [19:25:15 CET] <wm4> yes [19:25:24 CET] <wm4> it fucks up literally everything [19:26:34 CET] <nevcairiel> ff_get_extradata sure is a nice utility function, all those tripple error checks in every demuxer it just replaces [19:34:59 CET] <wm4> why are there even fate changes [19:35:30 CET] <nevcairiel> apparently handling of some time stamps changed, like duration of the last frame or some shit [19:35:56 CET] <jamrial> so, avcodeccontext->delay [19:36:23 CET] <ethe> what's a frame vs a packet vs a sample in terms of audio? and is the input data for an output device interleaved? [19:36:24 CET] <jamrial> it's also on libav but not moved to codecpar. we use it for opus on ogg and matroska but they don't [19:36:27 CET] <nevcairiel> usage of that field has always been super inconsistent [19:36:43 CET] <nevcairiel> isnt that initial_padding [19:37:33 CET] <wm4> seems so... [19:37:36 CET] <jamrial> oggparseopus sets it with the "pre_skip" from the opus ogg header [19:37:50 CET] <nevcairiel> sounds like initial padding [19:38:00 CET] <Daemon404> i would suggest checking libav-devel archives if something is confusing [19:38:12 CET] <Daemon404> for the smaller version of whatever bit is confusing [19:38:42 CET] <nevcairiel> A 'pre-skip' field in the ID header signals the number of samples which should be skipped at the beginning of the stream. [19:38:50 CET] <nevcairiel> from OggOpus "spec" [19:39:00 CET] <nevcairiel> so yes, move that into initial_padding [19:39:16 CET] <nevcairiel> maybe we'll manage to make this delay mess a bit cleaner in the process [19:41:44 CET] <wm4> wouldn't count on it [19:41:56 CET] <wm4> we also have a side data to skip samples [19:41:58 CET] <wm4> which does the same [19:42:28 CET] <nevcairiel> so ... avpriv_bprint_to_extradata takes an avctx, and its used from both avcodec and avformat [19:42:49 CET] <nevcairiel> should take the chance and get rid of its avpriv'ness and introduce a new avcodecpar version in avformat or something =p [19:42:54 CET] Action: wm4 wonders why sample_aspect_ratio is a AVStream field [19:43:09 CET] <wm4> nevcairiel: sounds good [19:43:12 CET] <nevcairiel> wm4: because streams and codecs can signal different aspect ratios [19:43:31 CET] <nevcairiel> so let the user decide which to use [19:44:09 CET] <wm4> makes sense, but there are MANY such ambiguities [19:44:17 CET] <wm4> matroska is just adding a whole new load of them [19:50:08 CET] <wm4> ubitux: user says the subtitle patch works [19:50:44 CET] <ubitux> huh [19:50:47 CET] <ubitux> it shouldn't but ok [19:51:53 CET] <nevcairiel> this stupid etherpad keeps forgetting some names and colors [19:53:20 CET] <wm4> when users log out? [19:53:41 CET] <wm4> ah, your color changed [19:53:42 CET] <wm4> fun [19:54:45 CET] <nevcairiel> i changed mine manually now [19:57:17 CET] <wm4> did anyone add seek_preroll yet? [19:58:22 CET] <nevcairiel> jamrial had that one, didnt he [19:58:34 CET] <jamrial> yeah, added it and pushed [19:58:54 CET] <jamrial> we should guard the old one and the functions inside some FF_API check [19:59:17 CET] <nevcairiel> make a note =p [19:59:39 CET] <nevcairiel> i also need to un-avpriv one function, but since avpriv is practically public ABI, need to do the dance etc [20:00:58 CET] <ubitux> time_base.. :( [20:01:14 CET] <wm4> what for? [20:02:15 CET] <ubitux> finding a matching dv profile [20:02:46 CET] <ubitux> it seems there is one in another place though [20:02:46 CET] <wm4> sounds messed up; maybe export pseudo profile values [20:02:49 CET] <ubitux> i might use that [20:03:48 CET] <ubitux> we should flag the one which weren't straightforward to merge [20:04:00 CET] <ubitux> to make final review more targetted [20:05:38 CET] <wm4> I tend to add odd things to the commit message, but not sure if they don't just get lost [20:06:43 CET] <ubitux> ah, right [20:10:26 CET] <ubitux> btw, any nasty type change of some sort in the codecpar struct? [20:10:40 CET] <ubitux> like, int to int64 or stuff like that which could create bugs© [20:12:37 CET] <wm4> why would int->int64 create bugs? [20:12:48 CET] <ubitux> the other way around maybe [20:13:18 CET] <ubitux> no one is adjusting av_parser_parse2()? [20:13:29 CET] <nevcairiel> it shouldnt be [20:13:44 CET] <ubitux> ah, we cant it's public [20:13:46 CET] <ubitux> meh [20:21:03 CET] <ubitux> durandal_170: 7b007a7c1fad57e9ed4b685c1d3b4222f02d9720 [20:21:07 CET] <ubitux> will this still be relevant? [20:21:40 CET] <durandal_170> what's it? [20:22:04 CET] <ubitux> one of your commit [20:22:21 CET] <ubitux> removing "ast->codec->sample_fmt = AV_SAMPLE_FMT_U8" from lavf/flic.c [20:22:22 CET] <durandal_170> Im on phone [20:22:29 CET] <ubitux> since "It is supposed to be set from lavc only" [20:23:08 CET] <durandal_170> is it set from decoder? [20:23:25 CET] <ubitux> maybe [20:23:38 CET] <ubitux> depends how we merge on lavc side [20:23:41 CET] <ubitux> it's about lavf right now [20:23:46 CET] <ubitux> anyway, i'm flagging the commit [20:24:25 CET] <Daemon404> damn, you guys have been busy while i ate [20:25:28 CET] <wm4> hm is one commit per file somehow preferable? [20:25:55 CET] <nevcairiel> its just how i work [20:25:59 CET] <nevcairiel> find your own way :D [20:26:21 CET] <wm4> these are get squashed anyway, so why bother [20:30:27 CET] <durandal_170> ubitux: I don't see it in ffmpeg repo [20:32:23 CET] <Fyr> FFMPEG AAC adds 1024 frames at the beginning of the file. [20:32:35 CET] <ubitux> durandal_170: you'll check later [20:32:46 CET] <Fyr> a few conversions can shift the timeline unexpectedly. [20:32:46 CET] <ubitux> no hurry [20:33:22 CET] <JEEB> Fyr: all AAC encoders have encoder delay [20:33:32 CET] <jamrial> avcodecparameters doesn't have an avclass [20:33:32 CET] <JEEB> you use a container like ISOBMFF to code that delay in [20:33:33 CET] <Fyr> JEEB, no [20:33:39 CET] <JEEB> yes, they do [20:33:39 CET] <jamrial> that means av_log can't be used with it, right? [20:33:48 CET] <Fyr> libfdkaac_enc doesn't give that delay. [20:33:50 CET] <wm4> jamrial: correct [20:33:59 CET] <Fyr> ffmpeg's aac does. [20:34:54 CET] <Fyr> I converted it ten times and found 0.5 s delay of FFMPEG AAC and 0 ms of that of Fraunhofer. [20:35:01 CET] <JEEB> you are going into incorrect conclusions [20:35:08 CET] <JEEB> also how exactly do you test [20:35:11 CET] <Fyr> 0.5 s matters [20:35:20 CET] <JEEB> of course it does [20:36:03 CET] <JEEB> anyways, just note how you're testing and I can possibly inform you of various funky things related to this stuff :P [20:36:14 CET] <Fyr> JEEB, http://pastebin.com/k16XA7us [20:36:26 CET] <Fyr> that will give you 0.5 s of delay. [20:36:47 CET] <Fyr> if you compare input.wav and 10 wav. [20:36:49 CET] <JEEB> ok, first of all ffmpeg cli handles encoder delay in a weird way when you output to a container that doesn't support it [20:37:01 CET] <JEEB> or well, doesn't support negative timestamps [20:37:12 CET] <JEEB> it automagically moves the first timestamp to zero :P [20:37:21 CET] <JEEB> also how are you testing fdk-aac, are you decoding with it per chance? [20:37:44 CET] <Fyr> I encode it according the scheme I've just posted. [20:37:51 CET] <JEEB> yes, but how are you decoding [20:37:54 CET] <JEEB> are you using its decoder? [20:37:58 CET] <JEEB> or the ffaac decoder? [20:38:02 CET] <Fyr> it doesn't matter where the problem occur, it must be fixed. [20:38:35 CET] <Fyr> JEEB, I don't use any decoder, I compare input.wav and 10.wav. [20:38:52 CET] <JEEB> I mean, when you decode the AAC to wav [20:39:02 CET] <JEEB> can you see which decoder you're using? [20:39:07 CET] <Fyr> ffmpeg -i 10.m4a 10.wav [20:39:24 CET] <Fyr> FFMPEG AAC decoder, methink. [20:39:29 CET] <JEEB> yeah, and the decoder used can be different depending on your configuration (although most probably it is the ffaac one) [20:39:36 CET] <JEEB> which is why I ask to make sure [20:40:00 CET] <wm4> lol sdp.c _actually_ wants to access the encoder [20:41:39 CET] <JEEB> anyways, let's start with this fact: all AAC encoders have encoder delay and that's just a thing of the audio format. no matter how much you say NONONO, that is a fact (esp. with those parameters). Second of all, encoder delay is marked into that container you're using as far as I can tell (if your FFmpeg is new enough), so when decoding the first packet(s) that contain the encoder delay should have a n [20:41:45 CET] <JEEB> egative timestamp accordingly (so you can cut the unneeded bits off) [20:41:50 CET] <JEEB> now, ffmpeg *cli* tries to be clever [20:42:06 CET] <michaelni> thresh just applied my patch to make diffs show up in merges, should i/someone push some dummy merge of a trivial commit to test it? [20:42:17 CET] <michaelni> that is merges on cvslog ML [20:42:18 CET] <JEEB> which is very confusing, but it puts the negative-starting packet at zero when the input doesn't start at zero [20:42:32 CET] <JEEB> when your output format doesn't support <0 timestamps (such as WAV) [20:42:52 CET] <Fyr> JEEB, Stream #0:0 -> #0:0 (aac (native) -> pcm_s16le (native)) [20:43:05 CET] <JEEB> ok, thanks for confirming [20:43:05 CET] <Fyr> i.e. FFMPEG's AAC decoder. [20:43:34 CET] <JEEB> the reason why you're not getting the delay with fdk-aac most probably is due to some special case in the decoder (I remember faac having one, too so I wouldn't be surprised :P) [20:43:47 CET] <JEEB> that said I didn't get to check the code yet [20:44:44 CET] <JEEB> Fyr: when you ffprobe or ffmpeg -i file.mp4|m4a it should show that the audio track doesn't start at zero [20:44:50 CET] <JEEB> if not, something's wrong [20:45:41 CET] <Fyr> JEEB, Duration: 00:00:09.50, start: 0.000000, bitrate: 130 kb/s [20:45:48 CET] <JEEB> ok, that is bugged [20:45:53 CET] <Fyr> something is wrong [20:46:01 CET] <JEEB> what version are you on? [20:46:10 CET] <Fyr> ffmpeg version N-53341-gbd9c587-static [20:46:20 CET] <Fyr> built with gcc 5.3.1 (Debian 5.3.1-10) 20160224 [20:46:43 CET] <JEEB> did you build it by yourself? [20:47:18 CET] <Fyr> ffmpeg version N-53341-gbd9c587-static http://johnvansickle.com/ffmpeg/ Copyright (c) 2000-2016 the FFmpeg developers [20:47:26 CET] <JEEB> ok, so most probably not [20:48:04 CET] <nevcairiel> hm, avidec uses avpriv_exif_decode_ifd which takes an AVCodecContext, but this codeccontext is only used for logging, nothing else [20:48:06 CET] <nevcairiel> how annoying [20:48:55 CET] <wm4> wow seems like 50% or so is already fixed [20:49:20 CET] <JEEB> Fyr: I have an older version on hand atm and I just did "ffmpeg -i file -c:a aac -b:a 192k delay_test.m4a" [20:49:29 CET] <JEEB> Duration: 00:03:42.17, start: 0.023220, bitrate: 196 kb/s [20:49:30 CET] <jamrial> ubitux: bit_rate [20:49:36 CET] <jamrial> it's int in codecpar [20:49:42 CET] <jamrial> should be int64_t [20:49:59 CET] <nevcairiel> we should probably change that again then [20:50:06 CET] <ubitux> ah! right ok [20:50:12 CET] <ubitux> dammit dv [20:50:13 CET] <jamrial> yeah [20:50:13 CET] <JEEB> Fyr: make sure you're not remuxing because more often than not that is gonna blow your encoder delay info to smithereens [20:50:41 CET] <ubitux> c->vst->codec->time_base, c->vst->time_base, c->sys->time_base, ... [20:50:45 CET] <ubitux> which am i supposed to use [20:50:47 CET] <ubitux> :( [20:50:50 CET] <JEEB> but yeah, the encoder delay is marked there in that container, and yes, wav output is "borked" as it outputs all the packets [20:51:02 CET] <JEEB> Fyr: feel free to make a bug report if you care about the WAV output [20:51:27 CET] <wm4> ubitux: never the codec one [20:51:34 CET] <JEEB> I think I once went through this with a foobar2000 dev, he similarly took some convincing that the API actually did the right thing [20:51:45 CET] <ubitux> wm4: yeh, i have to replace the use of c->vst->codec->time_base [20:51:50 CET] <ubitux> but with which... [20:51:53 CET] <JEEB> while testing with something like the WAV output seemingly did the wrong thing :P [20:52:00 CET] <wm4> well it sets it at one point, right [20:52:12 CET] <wm4> the user-visible timebase is in AVStream [20:52:34 CET] <wm4> it probably got moved there with the codecpar change, dunno [20:52:40 CET] <ubitux> there is also c->dv_demux->sys->time_base [20:53:05 CET] <JEEB> Fyr: and if you are not getting the encoder delay written, you'll have to build basic FFmpeg itself first and then test with it. if it still fails, that's worth a bug report [20:54:25 CET] <jamrial> i'm wondering if we should really deprecate seek_preroll. none of the other codecpar fields were deprecated from avctx [20:55:24 CET] <wm4> jamrial: right, the user still wants to access AVCodecContext fields in the actual decoder [20:57:42 CET] <jamrial> ok, undoing deprecation [20:58:58 CET] <wm4> if (avcodec_is_open(st->codec)) { [20:59:02 CET] <wm4> in the mpegts demuxer [20:59:03 CET] <wm4> wtf [20:59:12 CET] <JEEB> funky [20:59:20 CET] <wm4> is this a NOP now? [20:59:25 CET] <wm4> or can something still open it [21:03:48 CET] <wm4> assuming NOP [21:03:54 CET] <wm4> isom.c has another one [21:05:53 CET] <wm4> isom also wants to set rc_max_rate [21:07:06 CET] <Daemon404> btu why [21:07:07 CET] <Daemon404> but* [21:07:12 CET] <wm4> dunno [21:07:18 CET] <wm4> libav skips and discards it [21:07:18 CET] <Daemon404> git blame? [21:07:32 CET] <Daemon404> i thought rc_max_rate was for encoding [21:07:33 CET] <JEEB> probably so it can be re-used in remuxing or whatever? [21:07:34 CET] <wm4> 4547cf68a0d28c01549f84567e4d39a8b40230e7 [21:07:39 CET] <JEEB> nfi tho [21:07:46 CET] <wm4> some bitrate guessing bullshit [21:07:55 CET] <Daemon404> that commit explains nothing [21:07:56 CET] <wm4> "Fixes Ticket4546" [21:08:22 CET] <wm4> what's ganesh's github handle? [21:08:29 CET] <nevcairiel> for copy copy, apparently [21:08:32 CET] <nevcairiel> (what else) [21:08:42 CET] <nevcairiel> codec copy* [21:08:46 CET] <JEEB> yeah [21:09:01 CET] <nevcairiel> dont we have side data for cbp stats now [21:09:01 CET] <Daemon404> wm4, https://github.com/gajjanag [21:09:04 CET] <nevcairiel> wonder if those would work there [21:09:21 CET] <wm4> will use @gajjanag [21:10:08 CET] <Daemon404> st->codec->bit_rate = avio_rb32(pb); /* avg bitrate */ [21:10:10 CET] <Daemon404> this looks iffy btw [21:10:16 CET] <Daemon404> for corrupt files [21:10:23 CET] <wm4> yeah, but at least this field doesn't go away [21:10:26 CET] <wm4> so not my problem lol [21:12:57 CET] <Daemon404> of course i am sitting here fixing subtitles for work on the day TEP2 starts [21:13:07 CET] Action: Daemon404 blames ubitux, who put a jinx on him [21:13:11 CET] <JEEB> :D [21:13:21 CET] <ubitux> :D [21:13:25 CET] <nevcairiel> screw work =p [21:13:37 CET] <ubitux> Daemon404: hey i simplified it! [21:14:05 CET] <Daemon404> ubitux, this is unrelated to ffmpeg [21:14:17 CET] <ubitux> oh, ok [21:14:19 CET] <Daemon404> but its still a crapshoot [21:14:34 CET] <Daemon404> the ways programs manage to output mangled subtitles are astounding [21:14:40 CET] <Daemon404> especially character encoding [21:14:51 CET] <Zeranoe> Just ran into this: https://trac.ffmpeg.org/ticket/4832 I'll work on a backtrace. Anyone here know of this? [21:14:55 CET] <ubitux> Daemon404: is it an unsupported subtitles? is ffmpeg supporting that one? @_@ [21:15:10 CET] <Daemon404> ubitux, no it's IE11 being a piece of crap [21:15:14 CET] <Daemon404> and not doing vtt right [21:15:22 CET] <ubitux> ok [21:15:32 CET] <ubitux> if even browser can't handle vtt [21:15:36 CET] <ubitux> i wonder how we are supposed to [21:16:00 CET] <Daemon404> ubitux, by embedding a browser [21:16:04 CET] <Daemon404> like vlc will one day [21:16:13 CET] <JEEB> are you implying it hasn't yet? [21:16:21 CET] <Daemon404> it has? [21:16:39 CET] <JEEB> at least it has one available for it through Qt [21:16:47 CET] <Daemon404> Zeranoe, i dont think anyone outside of nevcairiel knows qsv here [21:16:49 CET] <ubitux> apparently we can't embed ie11 [21:17:04 CET] <JEEB> only its chakra engine [21:17:04 CET] <ubitux> not good enough for subtitles [21:17:18 CET] <nevcairiel> qsv likes to freeze sometimes, its just the way of the world [21:17:54 CET] <nevcairiel> i stopped considering it usable [21:17:55 CET] <Zeranoe> I noticed that [21:18:01 CET] <Daemon404> do our bug reporting guidelines ask for a backtrace built with debugging symbols? [21:18:08 CET] <Daemon404> i always see traces with absolute offsets [21:18:17 CET] <Zeranoe> It isn't every time either, and it's sometimes specific to a CPU [21:18:40 CET] <Daemon404> that sounds lovely [21:19:38 CET] <Zeranoe> I updated from a release to the git and it went away, until I jumped on an N3700. [21:20:16 CET] <wm4> <JEEB> at least it has one available for it through Qt <- chrome [21:20:21 CET] <wm4> the whole fat thing [21:20:32 CET] <JEEB> yup [21:20:45 CET] <Daemon404> yeah but i thought subtitles in vlc were done with the plugin/filter/whatever interface [21:20:54 CET] <Daemon404> not the gui [21:21:22 CET] <Zeranoe> I'll add this to the bug, but it can be reproduced with ffmpeg -i in.mp4 -vf unsharp=lx=7:ly=7:la=0.56:cx=7:cy=7:ca=0.28 -c:v h264_qsv -b:v 2000k -preset:v veryslow -y out.mp4 [21:21:43 CET] <Daemon404> Zeranoe, it sounds like the bug/problem is in the qsv library [21:21:46 CET] <Daemon404> to me [21:22:00 CET] <Zeranoe> it could be [21:23:43 CET] <wm4> got, 3rd party devs are going to kill themselves once we're done [21:23:49 CET] <wm4> god, even [21:24:09 CET] <Daemon404> wm4, i mena... 99.999% of the stuff that will break was wrong anyway [21:24:17 CET] <nevcairiel> so whatever happened to codec->framerate, codec->time_base, codec->ticks_per_frame? [21:24:35 CET] <Daemon404> codec->time_base never made any sense afaik [21:24:40 CET] <Daemon404> not sure about the other two [21:24:51 CET] <nevcairiel> apparently libav uses st->internal->avctx in this function .. must be during probing or something [21:24:51 CET] <wm4> nevcairiel: set AVStream fields [21:24:53 CET] <wm4> I suppose [21:24:59 CET] <wm4> oh fuck [21:25:02 CET] <nevcairiel> i took it upon myself to do utils.c [21:25:12 CET] <Daemon404> :D [21:25:18 CET] <wm4> well I guess there'll be a huge number of fate failures [21:25:47 CET] <nevcairiel> well the internal avctx should not be used by demuxers [21:25:56 CET] <Zeranoe> nevcairiel: Is a backtrace going to help here? [21:27:50 CET] <nevcairiel> Zeranoe: probably not [21:28:06 CET] <Zeranoe> My thoughts too [21:28:19 CET] <Zeranoe> Is there anything that would help... [21:32:24 CET] <ubitux> mmh so coded_{width,height} are not available either? [21:32:40 CET] <nevcairiel> why would the container set those [21:32:50 CET] <ubitux> it doesn't set them, it reads them [21:32:55 CET] <ubitux> to guess the dv profile [21:32:59 CET] <ubitux> just like the time base [21:33:02 CET] <nevcairiel> silly dv [21:33:11 CET] <ubitux> see 2139e584391b6db7ad315cf4f6443f87f7813d51 [21:33:17 CET] <ubitux> not sure what i'm supposed to do... [21:33:18 CET] <ubitux> :( [21:34:46 CET] <nevcairiel> the muxer needs to know the profile? [21:34:48 CET] <nevcairiel> dv sure is crazy [21:34:53 CET] <Daemon404> wut [21:35:39 CET] <nevcairiel> in any case, that code was ultimately wrong, since it was never guaranteed that the codec context there was actually the one used for encoding [21:36:09 CET] <Daemon404> nevcairiel, usually it was not [21:36:16 CET] <Daemon404> iirc you werent supposed to use it anyway [21:36:19 CET] <Daemon404> the stream ctx i meean [21:36:25 CET] <nevcairiel> ffmpeg.c probably did [21:36:27 CET] <nevcairiel> hence the "fix" [21:36:49 CET] <Daemon404> isnt there some sidedata/metadata/50 other ways to pass it [21:36:53 CET] <Daemon404> i cant keep track of then all [21:36:54 CET] <Daemon404> them [21:39:12 CET] <wm4> hm, nut, mfx, mov, and mux.c are still missing [21:39:22 CET] <wm4> and libavdevice shit [21:39:44 CET] <wm4> and oggparsflac.c (?) [21:40:27 CET] <wm4> right, that one has parse craziness [21:40:47 CET] <jamrial> i'm on it [21:40:56 CET] <jamrial> trying a dummy ctx [21:41:16 CET] <wm4> then you should mark it as wip [21:42:17 CET] <wm4> AVCodecContex.sample_aspect_ratio -> AVStream.sample_aspect_ratio, correct? [21:42:28 CET] <nevcairiel> wm4: no codecpar has one [21:42:32 CET] <wm4> mux.c tries to deal with both, so just remove the avctx one? [21:42:35 CET] <wm4> oh [21:43:08 CET] <wm4> ugh, indeed it has [21:43:13 CET] <wm4> I introduced some bugs earlier, then [21:43:21 CET] <ubitux> and again, dvenc needs the codec time base [21:43:33 CET] <Daemon404> ubitux, what is "codec time base" in this context [21:43:36 CET] <Daemon404> how can a codec have a timebase [21:43:50 CET] <ubitux> like i know [21:43:54 CET] <Daemon404> lol ok [21:43:57 CET] <Daemon404> let's see [21:44:03 CET] <ubitux> i picked the stream time base [21:44:05 CET] <Daemon404> dv just seems all sort of nutty [21:46:00 CET] <ubitux> i'm going to have some fun in dump.c [21:46:20 CET] <jamrial> wm4: http://pastebin.com/eXwBxkyF is that ok? [21:46:51 CET] <wm4> mux accesses AVCodecContext.flags & AV_CODEC_FLAG_BITEXACT => ??? [21:46:59 CET] <jamrial> it compiles, but i of course can't test it on this branch. it works when i do the same with git head [21:47:21 CET] <wm4> jamrial: you don't need to open it? [21:47:28 CET] <wm4> well maybe that's ok [21:47:42 CET] <wm4> the parser API will inevitably rewritten anyway [21:47:56 CET] <jamrial> guess not since it worked [21:48:00 CET] <ubitux> jamrial: just pass st->internal->avctx [21:48:04 CET] <ubitux> to the av parser [21:48:17 CET] <jamrial> oh, that sounds much simpler, haha [21:48:18 CET] <jamrial> lets see [21:48:28 CET] <ubitux> that's how it was done in other places apparently [21:49:42 CET] <wm4> den = (int64_t)st->time_base.num * st->codec->time_base.den; [21:49:45 CET] <wm4> some fucked up shit [21:50:52 CET] <ubitux> if num is st->time_base.num² that's fine! [21:51:16 CET] <ubitux> wm4: oh wait, tb from st, and tb from codec? [21:51:20 CET] <ubitux> hehehe [21:51:53 CET] <wm4> yes [21:52:02 CET] <wm4> looks like compat crap so I'm leaving it in [21:54:14 CET] <wm4> I'm stopping now, all what's left are juicy bits (nut, mov), and libavdevice [21:54:26 CET] <ubitux> what am i gonna do about 0578623? [21:54:37 CET] <Daemon404> doesnt nut basically use every field, just because [21:54:54 CET] <ubitux> well i guess i'll keep it as is [21:54:54 CET] <wm4> Daemon404: yes, it serializes all ffmpeg data structures, or something [21:55:07 CET] <Daemon404> it shouldnt be hard to fix [21:55:15 CET] <Daemon404> i dont think it's in the nut spec [21:55:21 CET] <Daemon404> otherwise libnut could not exist [21:55:27 CET] <wm4> lol spec [21:55:30 CET] <wm4> ok, I'll grab it [21:55:41 CET] <Daemon404> it's still more of a spec than vpx [21:56:09 CET] <wm4> st->codec->has_b_frames = stc->decode_delay; [21:56:11 CET] <wm4> fun start [21:58:04 CET] <Daemon404> ive only ever used nut for transporting raw video + timestamps myself [21:58:07 CET] <jamrial> ubitux, wm4: http://pastebin.com/j46bc46h ? can't test it of course since the avctx in avstreaminternal is new from this tep2 merge [21:59:14 CET] <nevcairiel> personally I would steal the approach from flac_header and parse the sample rate manually [21:59:22 CET] <nevcairiel> instead of mucking around with the avctx [21:59:25 CET] <nevcairiel> and the parser [21:59:27 CET] <jamrial> it's a mess and it's on libavcodec [21:59:30 CET] <ubitux> st->codecpar->sample_rate = st->internal->avctx->sample_rate; [21:59:33 CET] <ubitux> jamrial: why? ^ [22:00:13 CET] <nevcairiel> jamrial: well with manually i mean manually, see the flac_header function right above, it replicates extremely basic bitstream parsing [22:01:45 CET] <jamrial> ubitux: i can remove it, i assumed it would be useful and/or needed [22:02:09 CET] <jamrial> nevcairiel: i'll give it a try, but imo the internal approach is a simpler change [22:02:50 CET] <wm4> so what to do with has_b_frames? [22:02:57 CET] <wm4> do we want it in codecparams? [22:03:02 CET] <ubitux> jamrial: dunno, it looks out of scope [22:03:14 CET] <nevcairiel> wm4: which container mucks around with has_b_frames [22:03:23 CET] <wm4> nevcairiel: nut lol [22:03:35 CET] <wm4> but I think we also want to transfer it from lavf to lavc [22:03:46 CET] <wm4> didn't we revert the Libav change to kill it completely [22:03:53 CET] <nevcairiel> yeah [22:04:15 CET] <nevcairiel> itrs ratehr h264 specific with questionable meaning, but not having it makes decoding behave rather differently [22:11:02 CET] <ubitux> can we add dump_separator to codec_par? [22:11:16 CET] <ubitux> or i can keep using st->codec for now? [22:11:18 CET] <nevcairiel> wtf is that [22:11:31 CET] <ubitux> a way to customize the codec stdout dumping [22:11:41 CET] <nevcairiel> sounds terrible [22:11:47 CET] <ubitux> yeah whatever [22:11:58 CET] <ubitux> anyway, is st->codec still OK to use somehow? [22:12:03 CET] <nevcairiel> no [22:12:06 CET] <ubitux> :( [22:12:25 CET] <nevcairiel> but you can still access any AVCodecContext fields for your decoders of course [22:12:30 CET] <nevcairiel> just not through st->codec [22:12:45 CET] <ubitux> how then? [22:13:03 CET] <ubitux> i just need to read field [22:13:11 CET] <nevcairiel> however you store your decoder [22:13:48 CET] <ubitux> i'm in av_dump_format [22:14:01 CET] <carpediem_> Hi developers. I am interested in pursuing GSOC 2016 under FFmpeg. I would like to take a shot at the project "Create a fuzzing testsuite for FFmpeg" [22:14:03 CET] <ubitux> i only have access to avformat context [22:14:50 CET] <ubitux> well i'll skip the extraction of the option from the codec context [22:14:57 CET] <nevcairiel> ubitux: yeah thats not going to be accessible anymore [22:15:25 CET] <wm4> those nut commits are probably shoddy [22:15:34 CET] <wm4> Daemon404: be sure to read the commit messages when squashing the shit [22:17:28 CET] <wm4> carpediem_: contact the mentor [22:18:32 CET] <carpediem_> cool. Thanks! [22:18:42 CET] <cone-962> ffmpeg 03Paul B Mahol 07master:781195fa6229: avfilter/af_sofalizer: check if filename was set. [22:22:53 CET] <wm4> rc_max_rate again [22:25:02 CET] <Timothy_Gu> I wonder why every single student who requested the fuzzing project is from India... [22:25:11 CET] <cone-962> ffmpeg 03Paul B Mahol 07master:f81c81cc3abb: avfilter/af_afftfilt: add option for 17 fft case [22:25:17 CET] <wm4> most students who show interest are from india [22:26:07 CET] <ubitux> it's very interesting for them economically i believe [22:26:30 CET] <Timothy_Gu> well, I don't see a bunch of Chinese kids showing up [22:27:01 CET] <Timothy_Gu> (besides me :) and I can't say this isn't interesting for me economically [22:27:41 CET] <Daemon404> wm4, ok [22:27:53 CET] <ubitux> Timothy_Gu: maybe google promoted gsoc there at some point [22:28:01 CET] <wm4> Timothy_Gu: you'd make a pretty awesome gsoc student [22:28:12 CET] <ubitux> strange thing is, opw has the same thing [22:28:16 CET] <ubitux> most candidates were from india [22:28:42 CET] <ubitux> Timothy_Gu: yeah, can't do it? [22:28:51 CET] <Timothy_Gu> not in college yet [22:29:04 CET] <ubitux> that's a requirement? [22:29:10 CET] <Timothy_Gu> Yes [22:29:12 CET] <ubitux> :( [22:29:54 CET] <Timothy_Gu> So apparently I'm old enough to mentor but I'm too young to be a student... [22:29:58 CET] <wm4> lol [22:30:00 CET] <ubitux> haha [22:30:06 CET] <fritsch> hehe [22:31:01 CET] <nevcairiel> i bet this whole find_stream_info business is just going to explode [22:31:05 CET] <nevcairiel> but it compiles! [22:31:09 CET] <wm4> of course it will [22:31:22 CET] <nevcairiel> i got confused in between when to use codecpar and avctx [22:32:07 CET] <nevcairiel> there is a fundamental problem there .... it creates the internal avctx once for every stream from the codecpars, but demuxers could potentially still change the codecpars during demuxing [22:32:23 CET] <nevcairiel> there were a few libav patches before for such cases where they delayed thje stream creation until all info was available [22:32:33 CET] <nevcairiel> but alas we might still have that problem [22:32:59 CET] <nevcairiel> well, we will find out, wont we [22:33:22 CET] <wm4> yeah, through pain and suffering [22:33:41 CET] <nevcairiel> its probably very obscure formats that suffer from that [22:33:52 CET] <nevcairiel> but plenty ammo for carl to moan about merges again [22:34:26 CET] <Daemon404> id like to point out that it is sad that that is a thing to worry about [22:34:45 CET] <nevcairiel> i just ignore him, its not like that gets him anywhere on that front [22:35:34 CET] <nevcairiel> i'm sure tep2 will break mplayer three times over as well, since a bunch of parameters go missing that it needs to exist [22:35:43 CET] <wm4> let him moan [22:35:49 CET] <wm4> and mplayer gets broken all the time [22:35:53 CET] <Daemon404> mplayer doesnt need merges to break [22:35:54 CET] <wm4> mostly due to configure changes [22:35:56 CET] <Daemon404> it does that all on its own [22:36:01 CET] <nevcairiel> haha [22:37:37 CET] <ubitux> isn't mplayer still breaking everytime we add a codec id? [22:38:22 CET] <Daemon404> lolwut? [22:39:43 CET] <wm4> holy fuck mov contains avi [22:39:48 CET] <wm4> I didn't know... [22:39:48 CET] <JEEB> :o [22:39:54 CET] <wm4> mov_write_ms_tag... [22:40:00 CET] <JEEB> I knew of VFW mode in matroska [22:40:02 CET] <JEEB> but mov!? [22:40:04 CET] <ubitux> Daemon404: or maybe i'm mistaken with the addition of any CONFIG_<sth> that isn't format/codec/etc [22:40:30 CET] <iive> ubitux: i don't see how adding codec_id could break anything. [22:40:32 CET] <wm4> JEEB: well whatever mov mutation it is [22:40:46 CET] <ubitux> Daemon404: see r37795 r37432 r37421 [22:40:48 CET] <ubitux> stc [22:40:50 CET] <ubitux> etc [22:40:52 CET] <wm4> yeah, changing configure breaks mplayer almost certainly [22:41:01 CET] <JEEB> all these things you could just take to the back of the barn... [22:41:41 CET] <wm4> oh no frame_size again [22:42:45 CET] <jamrial> avctx->time_base. what do i do with that? [22:42:58 CET] <nevcairiel> hope its not crucial and hide [22:43:23 CET] <nevcairiel> which one? [22:43:28 CET] <jamrial> vfwcap.c in libavdevice. if removing it breaks something we'll not find until someone actually uses that .p [22:44:03 CET] <nevcairiel> shouldnt that set stream timebase or something rather [22:44:13 CET] <durandal_170> ubitux: flic demuxer have no need to set sample format [22:44:47 CET] <ubitux> ok ok [22:45:01 CET] <nevcairiel> jamrial: apparently libav sets st->avg_frame_rate instead [22:45:32 CET] <wm4> I'v been using st->time_base [22:45:57 CET] <wm4> which is probably wrong [22:46:13 CET] <nevcairiel> it is, that one should be set through avpriv_set_pts_info [22:46:29 CET] <nevcairiel> manually messing with it will likely cause trouble [22:47:06 CET] <jamrial> nevcairiel is probably right [22:47:17 CET] <jamrial> libav replaced avctx->time_base with st->avg_frame_rate [22:50:09 CET] <ubitux> ah [22:50:27 CET] <ubitux> i guess i know what to do about the dv then [22:51:37 CET] <nevcairiel> so who makes a new list with all the files we still need to fix? =p [22:52:16 CET] <ubitux> it's in commit messages, and i flagged them in the list too [22:52:30 CET] <ubitux> oh sorry you were talking about sth else [22:52:47 CET] <nevcairiel> i mean the files libav didnt have [22:53:42 CET] <Daemon404> grep ->codec-> ? [22:53:47 CET] <ubitux> git grep 'codec->' libavformat|cut -f1 -d:|sort -u [22:53:55 CET] <Daemon404> or make -k :P [22:54:15 CET] <Compn> re india and opw/soc ... probably related to h1b visas (shhh conspiracy time :P) [22:54:31 CET] <wm4> who wants to fix mov.c [22:54:49 CET] <Daemon404> i can do it tomorrow if its not Super Urgent [22:54:55 CET] <Daemon404> is it insane? [22:55:08 CET] <wm4> it's probably a lot [22:55:13 CET] <wm4> movenc.c was quite much [22:55:26 CET] <ethe> How does ref counting work? sometimes avpacket->ref is NULL, and other times ->data is NULL and other times, neither of them are NULL [22:55:28 CET] <wm4> (though mostly I did search&replace, and removing the Libav chunks) [22:55:45 CET] <wm4> ethe: ref should usually not be NULL [22:55:47 CET] <nevcairiel> what did we do with frame_size now? [22:55:50 CET] <nevcairiel> some codecs seem to need it [22:55:53 CET] <wm4> if ref is null, it's not refcounted [22:56:01 CET] <wm4> nevcairiel: I left it as is (deprecated codec access) [22:56:05 CET] <wm4> also, has_b_frames [22:56:19 CET] <wm4> I have no idea what frame_size is [22:56:25 CET] <wm4> audio frame size? [22:56:27 CET] <Timothy_Gu> Compn: gsoc doesn't allow for visas [22:56:32 CET] <ethe> wm4: is it random if it's refcounted or not? [22:56:42 CET] <nevcairiel> wm4: yeah size of audio frames typically [22:56:42 CET] <wm4> ethe: when do you get not refcounted packets? [22:56:48 CET] <nevcairiel> wm4: for odd raw formats [22:56:55 CET] <Compn> Timothy_Gu : i mean for those students who graduate and are then eligable for visas. investing in the future... [22:56:57 CET] <wm4> in some cases I might have tried to use that one function as replacement [22:57:20 CET] <Compn> Timothy_Gu : basically, google is poaching students for future employment :P [22:57:24 CET] <ethe> when reading from a AVFIFO [22:57:33 CET] <wm4> ethe: uh what [22:57:52 CET] <wm4> ethe: if you mean the data structure, who puts packets there? [22:57:53 CET] <JEEB> he's deep in avdevice IIRC [22:57:58 CET] <ethe> yes [22:58:17 CET] <ethe> wm4: a write packet function [22:58:41 CET] <wm4> well that's not sane [22:58:49 CET] <wm4> if it's not refcounted, the data is usually volatile [22:59:02 CET] <wm4> but this stuff is probably internal to whatever "demuxer" you're touching [22:59:06 CET] <Compn> Timothy_Gu : whats your opinion on some of the students whove contacted you about the fuzzing project? have any of them been able to google things for themselves ? like locating our wiki page that explains what needs to be done? [22:59:29 CET] <Timothy_Gu> Compn: we have one? [23:00:18 CET] <ethe> wm4: tbh I think it's more of a "oh god wtf am I doing, I have no idea" kind of thing [23:01:23 CET] <Compn> Timothy_Gu : i count at least 3 people interested in fuzzing project already. 4 including you. [23:01:43 CET] <Timothy_Gu> Compn: I mean, we have a wiki page that explains what needs to be done? [23:01:54 CET] <Timothy_Gu> or do you mean the main ideas page [23:02:09 CET] <Compn> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016 [23:02:27 CET] <Compn> main ideas page i mean [23:02:38 CET] <wm4> export_orphan_timecode() <- interesting function name [23:03:34 CET] <wm4> mov.c wants audio_service_type [23:05:42 CET] <Timothy_Gu> Compn: I think they know about that page, but the instructions aren't as speicfic as they can be [23:05:57 CET] <cone-962> ffmpeg 03Timo Rothenpieler 07master:95a5fd4581c6: configure: NVENC API version 6 is now required [23:06:22 CET] <Compn> Timothy_Gu : i'm wondering if i should edit that page and mention that students have already "picked " the fuzzing project and it would be better if other students picked another one ? [23:06:50 CET] <Compn> we used to do this in the past, explained to students how to make an account and do this themselves [23:07:02 CET] <Compn> not sure if thats happening this year or not [23:07:11 CET] <Timothy_Gu> Compn: well while it's true that a lot of students picked this one, as they say when the odds are good the good are odd [23:07:53 CET] <Timothy_Gu> the qualification task page should be updated to incorporate students who are willing to do it [23:08:10 CET] <Timothy_Gu> I don't want to block off any potential candidates right now [23:09:02 CET] <Compn> ok fair enough, i wont mess with it then. just bringing it to your attention. :) [23:09:16 CET] Action: Compn afk [23:09:23 CET] <wm4> the fuck is AV_CODEC_FLAG2_DROP_FRAME_TIMECODE [23:09:48 CET] <wm4> * timecode is in drop frame format. DEPRECATED!!!! [23:09:50 CET] <wm4> ok [23:10:16 CET] <cone-962> ffmpeg 03Paul B Mahol 07master:ac15d7a66633: avfilter/vf_histogram: explicitly set 10bit output formats [23:13:37 CET] <BtbN> what [23:13:46 CET] <wm4> lol [23:14:12 CET] <BtbN> at least it's just critical [23:15:19 CET] <Timothy_Gu> "please paste your full, uncut command output" [23:16:47 CET] <BtbN> No idea what that guy is doing, but there is no AVFrame in my version of lavc. [23:16:54 CET] <nevcairiel> there used to be [23:16:58 CET] <nevcairiel> it was moved [23:17:19 CET] <BtbN> so he... somehow managed to mix his code? [23:17:42 CET] <nevcairiel> who knows [23:21:16 CET] <ethe> Timothy_Gu: you got a small task I can do? avdevice, threads & async APIs are killing me. [23:21:42 CET] <Timothy_Gu> ethe: what kind of task are you looking for? [23:21:55 CET] <wm4> ethe: what is the task you're doing? (the avdevice one) [23:23:20 CET] <ethe> wm4: writing a JACK output device (this is the one I'm currently doing), and adding a SDL2 output device (which is completed but I implemented it without threads, so it's not ideal, but it works perfectly fine) [23:23:42 CET] <wm4> oh ok, that does sound pretty advanced [23:25:06 CET] <ethe> Timothy_Gu: An easier task probably. I'm interested in audio stuff, but I know so little about it (and even less about video stuff). [23:25:25 CET] <cone-962> ffmpeg 03Neil Birkbeck 07master:bbda13a7713b: lavf/matroskadec: Add early support for some of the new colour elements. [23:25:26 CET] <cone-962> ffmpeg 03Neil Birkbeck 07master:3c658e265517: lavf/dump.c: Print mastering display metadata [23:31:34 CET] <BtbN> O_O [23:32:42 CET] <wm4> a miserable mixture of Qt embedded ffmpeg and ARM stuff? [23:32:57 CET] <BtbN> It is actualy mixing two distinct ffmpeg trees [23:33:15 CET] <BtbN> And some weird Qt build system [23:33:42 CET] <BtbN> I'd say this ticket can be closed. [23:34:13 CET] <wm4> definitely [23:34:26 CET] <wm4> the interesting part would be how the mixture even happens [23:34:47 CET] <ethe> Timothy_Gu: got any ideas? [23:35:03 CET] <Timothy_Gu> ethe: you interested in assembly? [23:36:13 CET] <ethe> I dont know x86 at all, I know a bit of arm, although I dont have an arm device to test with currently. I'm up for trying something new though [23:37:47 CET] <Timothy_Gu> ok [23:38:04 CET] <Timothy_Gu> ethe: you see in https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/x86 we have lots of assembly optimization [23:38:25 CET] <Timothy_Gu> many of them are in .asm [23:38:47 CET] <Timothy_Gu> and are assembled by Yasm or NASM [23:38:57 CET] <Timothy_Gu> but some older ones are inline asm [23:38:59 CET] <Timothy_Gu> like https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/x86/lpc.c [23:39:18 CET] <Timothy_Gu> so what we are tring to do is convert them to Yasm/NASM format [23:40:09 CET] <Timothy_Gu> for the rationale see https://launchpad.net/ffmpeg/+announcement/12726 [23:41:04 CET] <Timothy_Gu> for some examples of how to convert see https://github.com/FFmpeg/FFmpeg/commits/master/libavcodec/x86?author=Timot… [23:41:14 CET] <Timothy_Gu> (my commits are usually the easiest ones :) [23:41:30 CET] <Timothy_Gu> and of course, the earlier it is the easier it is to understand [23:41:37 CET] <cone-962> ffmpeg 03Rostislav Pehlivanov 07master:b88be742fac7: vc2enc: do not allocate packet until exact frame size is known [23:41:38 CET] <cone-962> ffmpeg 03Rostislav Pehlivanov 07master:f21cf2b38365: vc2enc: remove useless alignment on slice encoding [23:41:39 CET] <cone-962> ffmpeg 03Rostislav Pehlivanov 07master:c45b1aa8241a: vc2enc: minor cosmetic changes [23:42:44 CET] <Timothy_Gu> https://wiki.videolan.org/X264_asm_intro/ is helpful too, although it's just a little bit outdated [23:48:39 CET] <wm4> Timothy_Gu: maybe you could think of a gsoc project involving asm? [23:49:14 CET] <Timothy_Gu> wm4: the part where asm is the most needed rn is probably hevc [23:49:29 CET] <nevcairiel> thats too complex for a student [23:49:50 CET] <Timothy_Gu> The student can port from openhevc though [23:50:14 CET] <nevcairiel> proper hevc asm would probably need a whole bunch of refactoring in the hevc decoder [23:50:36 CET] <nevcairiel> the openhevc stuff isnt the best [23:50:45 CET] <Timothy_Gu> there's also the problem of finding mentors [23:50:48 CET] <wm4> to be fair everyone cherry-picks these patches anyway [23:50:53 CET] <wm4> for their own builds [23:52:07 CET] <ethe> loren writes a lot of asm [23:53:10 CET] <Timothy_Gu> ethe: Yes, pengvado/Loren is probably the best at asm among anyone of us here [23:53:30 CET] <Gramner> avx2 can be written for a lot of stuff if you're looking for something to do. probably easier to add avx2 versions of existing functions in many cases than to write new asm from scratch [23:57:03 CET] <Timothy_Gu> Gramner: how much do the 256-bit regs help in performance? [23:58:08 CET] <Gramner> if you can fully utilize the wider registers? twice as fast as 128-bit regs [00:00:00 CET] --- Sat Mar 5 2016

1 0

ffmpeg.log.20160304
by burek 05 Mar '16

05 Mar '16

[08:27:48 CET] <pingufan> Good morning. I try to transcode an mkv video into a new one with same picture size but lower bandwidth. h264 and ac3 is what I want. [08:28:33 CET] <pingufan> Using my parameters from 1-2 years ago (I upgraded my system recently to openSUSE 13.2), this does not work any more. [08:28:44 CET] <pingufan> Can somebody, please, help me? [08:29:33 CET] <relaxed> pingufan: pastebin.com your command and console output [08:33:28 CET] <pingufan> This is my entire bash script: http://pastebin.com/iUtMAWGt [08:34:50 CET] <pingufan> This is the output on screen: http://pastebin.com/2QBJn6kw [08:35:05 CET] <relaxed> remove -target pal-dvd [08:36:19 CET] <pingufan> This is the output when using rerip0: http://pastebin.com/5cKZtQ3m [08:37:02 CET] <relaxed> do you want mpeg2 video or h264? [08:37:47 CET] <pingufan> I want h264. I have only limited network bandwidth. So I tend to use ~4-5 kbit/s only [08:38:26 CET] <pingufan> Can't I use a "target" and then re-define some of oits parameters? [08:38:30 CET] <furq> if you want to keep the same resolution then remove -target pal-dvd and -s hd1080 [08:38:54 CET] <furq> also i assume you have some specific reason to use keyint=5 because that's not going to help you save bitrate [08:39:21 CET] <furq> likewise -r 25 is redundant if you want to keep the same framerate [08:40:15 CET] <pingufan> This is a grown list of parameters. in old openSuSE 12.2, the parameters from "function rerip0 ()" gave a good result. Now I try to find out in a new function working parameters. [08:40:38 CET] <furq> well rerip0 is failing because -target pal-dvd sets the output codec to mpeg2 [08:40:56 CET] <furq> the other one is failing because [08:40:57 CET] <furq> Error writing trailer of rsg-extant-s01e01-1080p.mkv: Invalid data found when processing input [08:41:05 CET] <furq> which has nothing to do with your settings [08:41:28 CET] <relaxed> maybe an incomplete torrent download? [08:41:42 CET] <pingufan> But why does function "rerip0", the old one, work? [08:41:55 CET] <furq> it doesn't work, you just pasted it not working [08:42:04 CET] <pingufan> This happens at very beginning. [08:42:06 CET] <furq> oh nvm no you didn't [08:42:59 CET] <pingufan> I posted two outputs. The last one works, I only aborted with ^C. [08:43:23 CET] <relaxed> [matroska @ 0x1956100] Invalid chapter start (2458664000000) or end (2458581000000) [08:43:36 CET] <pingufan> This second output is when using "function rerip0" [08:44:01 CET] <furq> pingufan: try with -map_chapters -1 [08:44:39 CET] <furq> i also advise against -x264opts keyint=5 unless you have a very specific reason for doing that [08:44:47 CET] <furq> it'll almost certainly result in a bigger output file [08:44:47 CET] <pingufan> instead of -map 0:0 -map 0:1 [08:44:59 CET] <pingufan> Or in addition? [08:45:02 CET] <furq> in addition [08:45:21 CET] <pingufan> Before or after -map entries? [08:45:25 CET] <furq> makes no difference [08:45:42 CET] <furq> as long as it's an output option [08:47:51 CET] <pingufan> Seems to work: This is the output (using "function rerip()" with added "-map_chapters -1": http://pastebin.com/ip2ac7rK [08:48:11 CET] <pingufan> Does this look good now? I pressed "q" after some seconds. [08:50:52 CET] <pingufan> furq: What does "-map_chapters -1" do? I want to understand. [08:51:33 CET] <furq> -map_chapters 0 maps the chapters from input file 0 to the output file, which was causing your error [08:51:38 CET] <furq> setting it to -1 turns that off [08:52:13 CET] <furq> i'm not sure why that was only causing an error with x264 and not mpeg2 [08:53:33 CET] <pingufan> So "-map_chapters 0" is a default setting? (I didn't write this line) [08:54:14 CET] <relaxed> furq: different output containers [08:54:43 CET] <furq> they're both mkv [08:54:47 CET] <furq> pingufan: yes it is [08:54:53 CET] <furq> for mkv, at least [08:55:06 CET] <relaxed> well, Output #0, dvd, to 'rsg-extant-s01e01-1080p.mkv': [08:55:12 CET] <pingufan> Then this seems to be new in ffmpeg. :) [08:55:22 CET] <relaxed> so it was VOB named *.mkv [08:56:21 CET] <pingufan> Can ffmpeg convert a .ts stream from my dm800hdse box, too? Transport strams often cause biggest troubles. [08:57:26 CET] <pingufan> I want to record a movie, then convert it from .ts into a smooth "whatever", cut out advertising, then make an .mkv. [08:57:32 CET] <furq> probably [08:57:48 CET] <pingufan> I often lost A/V sync hereby. [08:59:07 CET] <pingufan> I think this is caused by hard cuts on sender side. They cut and start a new stream. this confused my older software. [09:00:03 CET] <pingufan> Or noise/artifacts in the video. They also cause A/V sync losses [09:01:57 CET] <pingufan> This is the current output: http://pastebin.com/ip2ac7rK <-- Looks good now? [09:06:51 CET] <pingufan> Result is perfect. THANK YOU for your kindly help. [09:09:28 CET] <shams> hi all [09:10:11 CET] <shams> is there anyone available who has experience with qnap ffmpeg package upgrade? [09:11:01 CET] <pingufan> Sorry. I make a wide, wide bow around qnap. [09:11:46 CET] <shams> on my qnap server i have 0.8.10 ffmpeg version [09:11:49 CET] <furq> i have experience of sitting on irc listening to a guy complaining about how terrible ipkg is, if that helps [09:12:05 CET] <shams> lolz [09:12:46 CET] <shams> may i get some help regards [09:14:31 CET] <furq> if it's x86 then you could try http://johnvansickle.com/ffmpeg/ [09:18:14 CET] <shams> @furq, how can i check the system architecture on qnap ssh ... any idea? [09:18:15 CET] <shams> :) [09:18:48 CET] <furq> uname -m [09:19:24 CET] <furq> you probably also want to check uname -r to make sure it's >=2.6.32 [09:21:53 CET] <shams> let me check ... thanks :) [09:22:23 CET] Action: relaxed guesses arm [09:22:39 CET] <furq> https://helpdesk.qnap.com/modellist.htm [09:22:46 CET] <furq> there are plenty of x86 ones [09:22:58 CET] <relaxed> oh [09:22:59 CET] <shams> yes, its x86_64 [09:23:16 CET] <relaxed> kernel version? [09:23:39 CET] <shams> 3.12.6 [09:24:06 CET] <shams> can i install new ffmpeg as other instance without touching the older one? [09:24:35 CET] <furq> probably [09:24:40 CET] <relaxed> yes, it's a binary you can place anywhere [09:24:57 CET] <furq> you'll need to make sure your PATH points to the new one before the old one though [09:24:59 CET] <shams> should i grab it from here [09:25:00 CET] <shams> http://johnvansickle.com/ffmpeg/ [09:25:01 CET] <shams> ? [09:25:09 CET] <furq> there's nowhere else to grab it from [09:25:09 CET] <relaxed> yeah, those are my builds [09:25:40 CET] <shams> Great... let me do and i'll update you if it works for me [09:25:56 CET] <shams> actually, i just have to make thumbnails of videos [09:26:12 CET] <shams> and when i run ffmpeg [09:26:29 CET] <furq> relaxed: out of interest, are you obliged to link to the source code even if it's unpatched [09:26:30 CET] <meldron> hi guys, i am trying to compile ffmpeg with x265 support, i got it working 2 weeks ago, but now if i try again (sticking to this guide: https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu) i always get "ERROR: x265 not found using pkg-config" even with this x265.pc http://pastebin.com/bZUMcaW7 in a custom PKG_CONFIG_PATH and --pkg-config-flags="--static", here my configure cmd: http://pastebin.com/Jxr3bRYF . Anybody got an idea? [09:26:45 CET] <furq> meldron: are you checking x265 out from git/hg [09:26:46 CET] <relaxed> furq: yes [09:27:10 CET] <furq> if so you need to switch to the stable branch, not master [09:27:22 CET] <furq> i should maybe report that as a bug [09:28:05 CET] <shams> ffmpeg encountered an error when attempting to read [09:28:06 CET] <meldron> furq: hey furq i am doing it like this http://pastebin.com/e1YipYpZ [09:28:13 CET] <meldron> so yeay i am not switching any branches [09:28:21 CET] <furq> https://github.com/videolan/x265/commit/85f72fe907fef56f5bb82bf1b38e07a9928… [09:28:28 CET] <furq> this commit breaks ffmpeg's configure script [09:28:37 CET] <furq> if you're using git then `git checkout stable` [09:28:38 CET] <shams> https://github.com/buggedcom/phpvideotoolkit-v2/issues/87 [09:29:54 CET] <meldron> ah okay, currently using the mercury but i think i will change it [09:30:11 CET] <furq> there's probably a way to do that with hg but i don't remember what it is [09:30:45 CET] <meldron> never used it, just copied the instruction from the guide i think i will switch to the github repo [09:30:49 CET] <meldron> thank you very much [09:31:31 CET] <furq> meldron: could you pastebin your config.log (the broken one) [09:31:48 CET] <shams> @relaxed... will your build resolve my issue? [09:31:50 CET] <furq> it saves me having to fire up this vm and compile the wrong x265 branch [09:32:11 CET] <shams> or can i fix the existing one? [09:33:45 CET] <relaxed> shams: huh? the url you pasted is using 0.8.10. My builds support -af [09:34:23 CET] <shams> yes i have 0.8.10 ffmpeg version on my qnap server [09:34:34 CET] <shams> what is -af? [09:35:49 CET] <relaxed> where is the old version installed? [09:36:21 CET] <shams> o /mnt/ext/opt/ffmpeg/usr/bin [09:36:29 CET] <meldron> furq: sure [09:36:36 CET] <meldron> give me a second [09:37:20 CET] <relaxed> shams: echo $PATH [09:38:36 CET] <meldron> furq: http://pastebin.com/M2VTjVsP [09:38:48 CET] <furq> thanks [09:38:59 CET] <furq> now to figure out how to report an ffmpeg bug [09:39:40 CET] <shams> --/share/CACHEDEV1_DATA/.qpkg/container-station/bin: [09:40:01 CET] <shams> --- /share/CACHEDEV1_DATA/.qpkg/container-station/bin:/share/CACHEDEV1_DATA/.qpkg/container-station/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin:/Apps/bin:/Apps/s [09:40:10 CET] <shams> the full path [09:40:38 CET] <relaxed> /mnt/ext/opt/ffmpeg/usr/bin isn't in your path [09:41:34 CET] <shams> i'm giving this path in phpvideotoolkit liberary [09:42:16 CET] <shams> ffmpeg -v is also working globally on ssh [09:43:22 CET] <relaxed> what's the problem? give the absolute path to the new ffmpeg binary [09:44:33 CET] <shams> Sorry, you mean i should install your binary and set your binary path in my phpvideotoolkit library? [09:44:53 CET] <shams> would your library work and make video thumbnails then? [09:45:43 CET] <relaxed> yes, but it's not a library [09:46:15 CET] <relaxed> it's a binary with statically linked libs [09:46:46 CET] <shams> yes, i got it [09:46:53 CET] <shams> let me try and i'll update you [09:47:05 CET] <shams> Thanks for the great greattttttttt help [09:47:09 CET] <shams> Stay blessed [09:47:40 CET] <shams> :) [10:10:06 CET] <absence> what other libs/utils than ffmpeg are there that can decode mpeg 2 transport stream? i want to do a comparison with ffmpeg [10:23:19 CET] <shams> @relaxed, @furq.... Thanks for your help... it was superb experience .. resolved my issue [10:23:34 CET] <shams> you may live long and have so much success in your future [10:40:45 CET] <pingufan> Hi, I have another minor issue with ffmpeg. I use this script to transcode a series of movies to a lower video bandwidth: http://pastebin.com/HDVCG4fF [10:41:38 CET] <pingufan> What I wonder about: It stops displaying the current frame number etc. in last line, but it still works, the output file is increasing. [10:42:00 CET] <pingufan> A bug? A missing option? -- If one could help me, please? [10:43:07 CET] <pingufan> I am reading the input and writing the output over NFS mount, if this is of any importance. [10:45:18 CET] <NoMercy78> Hello again [10:45:41 CET] <pingufan> Hi! [10:45:59 CET] <NoMercy78> I have a compilation issue :( [10:46:15 CET] <NoMercy78> if anyone can helpout? [10:46:32 CET] <pingufan> I never compiled it. I really cannot help you. :( [10:47:08 CET] <c_14> NoMercy78: pastebin your configure line and error [10:47:40 CET] <NoMercy78> well in case anyone else can here it goes; I know that newer intel compilers are not officially supported but is there a way to make it work? [10:48:12 CET] <NoMercy78> configure says (actually most likely icl says) that it can not create tmp files [10:49:07 CET] <c_14> NoMercy78: upload your config.log (or at least the last 50 or so lines) [10:55:46 CET] <pingufan> has ffmpeg difficulties when run on "nice -+15" with "-threads 2" ? After outputting some frame= ... updates, it stopped doing that, but it still converts/transcodes the movie. [10:56:06 CET] <NoMercy78> thank you, here is all the config.log; http://pastebin.com/3HWB0EnV [10:56:28 CET] <NoMercy78> trying to build on windows btw [11:18:12 CET] <c_14> NoMercy78: hmm, no clue, sorry [11:20:18 CET] <NoMercy78> well, thank you for your time. I'll try forums and mailing list [11:20:27 CET] <NoMercy78> I need to figure this out somehow [11:31:09 CET] <takacsv_> hi all [11:33:41 CET] <takacsv_> My google-fu failed me, so I'm not able to find out if ffmpeg supports h264 encoding using vaapi or not. I compiled ffmpeg and do have the respective hwaccel enabled but I'm either unable to create a proper CLI (I have one though that encodes using the cpu) that does what I want or maybe it can't be done. Does anyone have experience with this? [11:40:06 CET] <jkqxz> takacsv_: The hwaccel is decoding only. ffmpeg does not yet have VAAPI encoding support. [11:40:38 CET] <pkeuter> hey guys. is there a way to append to an mp3 file? e.g. in a livestream recording when the connection errors, i want to restart it and let the recording continue [11:41:05 CET] <takacsv_> jkqxz: thanks, good to know [11:54:31 CET] <mcmic> Hello [11:55:03 CET] <mcmic> While using ffmpeg to record my screen, I get a weird message I did not have before: [mp4 @ 0x563b675d5320] Non-monotonous DTS in output stream 0:1; previous: 358289, current: 346325; changing to 358290. This may result in incorrect timestamps in the output file. [11:55:36 CET] <mcmic> This is only happening if I try to capture sound with pulseaudio, If I only capture video with x11grab it works fine [11:56:16 CET] <mcmic> Full command I use is: ffmpeg -f x11grab -show_region 1 -thread_queue_size 16 -framerate 20 -video_size 1200x720 -i :0.0+0,40 -f pulse -ac 2 -i default -preset fast -c:a libmp3lame out.mp4 [12:16:48 CET] <mcmic> Ok, found a work around on your bug tracker, seems to work [15:16:50 CET] <flux> hello. I'm reading an ISO MP4 file with libavformat and I was wondering, is there a way to determine that the file has an edit list entry (with non-zero media time)? [15:21:45 CET] <t4nk699> Can anyone recommend a correct ffmpeg command for converting MOV to MP4. I am currently using ffmpeg -i vid.MOV -c copy out.mp4 which does not play on Ipads and Iphones. Thanks [15:29:02 CET] <c_14> t4nk699: https://trac.ffmpeg.org/wiki/Encode/H.264#AdditionalInformationTips see the compatibility heading [15:39:15 CET] <KevinA_> Hello, does anyone have a code example of encoding, or documentation on encoding, a file using h264_qsv and libavcodec? All I can find are decoding. And I know I'm doing something wrong, but i don't know what. I'm getting an MFX error "Unsupported" when qsvenc.c calls GetVideoParams [15:46:05 CET] <BtbN> did you do all the patch hackery intel expects you to do? [15:46:11 CET] <BtbN> like, patched kernel and libva? [15:53:26 CET] <KevinA_> it works from ffmpeg bin [16:18:52 CET] <satinder_> hi there have any one who using ffmpeg api [16:35:23 CET] <durandal_170> satinder_: question? [16:35:52 CET] <satinder_> PIX_FMT_RGB24 undeclared (first use in this function) [16:36:33 CET] <satinder_> error during compile ffmpeg first tutorial from https://github.com/phamquy/FFmpeg-tutorial-samples/blob/master/tutorial01.c [16:37:07 CET] <furq> satinder_: https://ffmpeg.org/doxygen/2.8/pixfmt_8h.html [16:37:11 CET] <furq> looks like it changed in 2.8 [16:37:26 CET] <durandal_170> satinder_: was renamed [16:46:00 CET] <satinder_> Hi I want capture video frame from video [16:46:08 CET] <satinder_> any body can help [16:46:18 CET] <satinder_> any link for that [16:46:32 CET] <satinder_> durandal_170 : ?? [16:49:04 CET] <satinder_> furq : ?? [17:19:58 CET] <Fyr> furq, http://xtemp09.ucoz.net/Codec_comparison.png [17:20:08 CET] <Fyr> does it look fancy to you? [17:21:41 CET] <furq> is that psnr [17:21:50 CET] <Fyr> just subtraction [17:22:09 CET] <Fyr> Original signal - Converted signal = Noise [17:22:16 CET] <furq> you also probably want to specify it's fdk and not fhg (winamp) [17:22:24 CET] <furq> since it's not clear if those are the same [17:22:51 CET] <Fyr> what name does Windamp use? [17:22:58 CET] <furq> fhg [17:23:08 CET] <furq> apparently they're two different implementations [17:23:45 CET] <furq> actually if you mean what it's called within winamp then i don't know [17:23:59 CET] <furq> i don't have winamp installed because it's not 2008 [17:26:26 CET] <Fyr> furq, reload the picture. [17:26:43 CET] <furq> that'll do it [17:28:08 CET] <Fyr> furq, https://youtu.be/ghO8N1s2Brc [17:28:43 CET] <furq> you know that youtube is converting this to fdk-aac right [17:28:58 CET] <Fyr> yeah [17:29:14 CET] <Fyr> I appended a message in the end of the description. [17:32:19 CET] <Fyr> furq, FFMPEG's wiki requires an account to edit pages? [17:32:26 CET] <furq> i've never tried [17:44:58 CET] <kaseano> Hi, I've spent the last week trying to restream/transcode a live feed from a camera (rtsp://.../media.smp) into OGG via FFMEG. I can play the rtsp from VLC, I can't seem to get ffmpeg to connect though. "ffmpeg -i rtsp://... -loglevel debug" idles for a couple minutes then returns Input/output error. Hoping someone can give me a hint [17:48:33 CET] <morphles> I'm having crazy trouble achieving basic thing. I have a video with power point presentation slide up effect on text. Source video is ogv, is 15 fps (acording to say vlc, but using avconv, when encoding it shows 14.67), in any case I try to transcode it to h264 (or even if I try to keep it theora), while merging with alternate (edited/cleaned up) soundtrack, in the resulting video that powerpoint/presentation slide up animation is hm, crazy stuttering, basical [17:48:40 CET] <morphles> Any advice? [17:52:53 CET] <satinder_> Hi I want read a network video stream and write it on v4l2 video node [17:52:59 CET] <satinder_> with ffmpeg api [17:53:13 CET] <satinder_> any one please help [17:53:20 CET] <satinder_> ;( [18:19:14 CET] <morphles> ffs problem is not output but somehow it manages to read input steam in some retarded way, even encoding with -g 1 and resulting size of x10 original i still shows choppy restult.... [18:20:11 CET] <aeer1> Possibly stupid question -- don't have a lot of background on this. Is there a way for me to produce a slower video without changing the framerate? [18:20:31 CET] <aeer1> I have an imagesequence, trying to avoid choppiness. [18:22:42 CET] <furq> aeer1: -framerate before -i is the input framerate, -r after -i is the output framerate [18:22:52 CET] <furq> you can set them differently [18:23:05 CET] <furq> assuming "imagesequence" means the image2 demuxer [18:27:44 CET] <aeer1> furq: Ok. So if I want to slow things down, but minimize the "choppy" effect I'm getting, I want to reduce the input framerate? [18:28:27 CET] <aeer1> (also, yes, imag2) [18:29:21 CET] <furq> i don't really know what you mean by choppy, but if you want to slow it down then reduce the input framerate [18:33:37 CET] <absence> aeer1: what you want is called optical flow or something [18:33:57 CET] <absence> aeer1: it's quite computationally expensive, and can't be done by ffmpeg i think [18:34:16 CET] <absence> aeer1: mvtools for avisynth/vapoursynth can do it [18:34:51 CET] <retard> what you want to do is creating information from nothing [18:34:59 CET] <retard> like one of those terrible 100hz tvs [18:35:09 CET] <retard> where the algorithm keeps getting thrown off by pans [18:35:12 CET] <furq> you two are reading a lot into this [18:35:21 CET] <retard> no, like.. eh [18:35:30 CET] <retard> that is what has to be done to slow down video while maintaining the framerate [18:35:36 CET] <retard> you need to add information that is not there [18:35:42 CET] <furq> he said he was using an image sequence [18:35:49 CET] <absence> retard: mvtools is a lot more advanced than the real-time algorithms in 100hz tvs :) it works quite well actually [18:35:53 CET] <furq> maybe "choppy" just means the images are transitioning too fast [18:35:53 CET] <retard> expand your image sequence [18:36:19 CET] <absence> furq: input format has nothing to do with it. he asks to slow down the video without reducing the framerate [18:37:06 CET] <furq> it has quite a lot to do with the assumption that he wants smooth motion [18:37:43 CET] <retard> absence: it's still not magic [18:37:58 CET] <absence> furq: an image sequence isn't more or less smooth than a video file, it's just a different way of storing it [18:38:14 CET] <absence> retard: nobody said it was [18:38:16 CET] <furq> yes but you're assuming he wants smooth video and not a slideshow [18:38:31 CET] <furq> the former makes less sense to me [18:38:35 CET] <retard> he says he wants to minimize the "choppy" effect he's getting [18:38:39 CET] <retard> there is no assumption [18:38:40 CET] <retard> it is plainly stated [18:39:35 CET] <absence> furq: "image sequence" means something specific in video terms. it's video stored as a sequence of separate files. i understand that you could think of it as a slide show, but that's not what the term usually means [18:46:55 CET] <aeer1> I am very much a novice with this, thus the silly questions/poor terminology. It's a timelapse built from a sequence of .png. I was using -r 24 and getting a nice smooth video, but rather quick. [18:46:56 CET] <aeer1> Before I posted here, I was cutting down -r, which gave a longer video, but the motion wasn't as smooth. [18:47:21 CET] <retard> yeah, to "smooth" it some kind of interpolation is required [18:48:59 CET] <furq> aeer1: try -vf framerate=24 instead of -r 24 [18:51:23 CET] <absence> aeer1: no about of ffmpeg flags will get you what you want, you need something that can do optical flow [18:51:47 CET] <absence> about = amount :) [18:52:59 CET] <absence> vapoursynth has a bit of a learning curve, but the mvtools plugin can do it. it's free and has good quality. not sure if there are non-commercial alternatives [18:53:20 CET] <absence> anyway gotta run [18:54:05 CET] <aeer1> Thanks for the help everyone. [21:32:30 CET] <atomnuker> Fyr: what an uninformed comparison [21:32:54 CET] <atomnuker> removed the links from the wiki because it's plain wrong to compare like that [21:33:18 CET] <atomnuker> read up on the perceptual noise subsitution coding tool in the AAC spec [21:33:46 CET] <atomnuker> in short, it substitutes random freqency bands with random noise [21:33:59 CET] <atomnuker> which makes it completely pointless to run the test [21:34:19 CET] <atomnuker> what's important is the perceptual quality, not the signal to noise ratio [21:34:34 CET] <atomnuker> and I bet you didn't even bother to sync up the original with the decoded track [21:34:59 CET] <JEEB> he was just complaining that he was getting the encoder delay in the WAV on -devel [21:35:07 CET] <JEEB> which is something way too many people get caught up in [21:35:24 CET] <JEEB> (also he had an issue where seemingly he didn't get the encoder delay written into the m4a) [21:36:31 CET] <JEEB> did the ffaac decoder have a thingy for nulling fdk-aac's encoder delay per chance? because he seemed to imply that he wasn't getting it with fdk-aac [21:36:52 CET] <JEEB> (which I would understand if one would use fdk-aac's decoder, but I think he was saying that he was using ffaac) [21:37:10 CET] <JEEB> although ffaac does have something to "probe" faac encoded streams, for example [22:07:08 CET] <t4nk408> hi! [22:07:40 CET] <t4nk408> i'm trying to stream videao with ffmpeg command [23:05:03 CET] <sophie___> hello [23:05:33 CET] <sophie___> i'm trying to stream with an ffmpeg command [23:05:44 CET] <sophie___> and i've this message [23:05:47 CET] <sophie___> Too large number of skipped frames [23:06:27 CET] <sophie___> i've put -framerate 30 in my command [00:00:00 CET] --- Sat Mar 5 2016

1 0

ffmpeg-devel.log.20160303
by burek 04 Mar '16

04 Mar '16

[01:03:16 CET] <michaelni> jamrial, the only way i can check it is to push it to master and rerun coverity [01:03:42 CET] <michaelni> well i could run coverity on my private tree but it would confuse everyone i think [01:04:22 CET] <michaelni> as it would look like ffmpeg master ... [01:05:02 CET] <jamrial> ah ok [01:05:13 CET] <jamrial> guess the only way would be to ask him then [01:05:57 CET] <michaelni> jamrial, actually i have a mail from today from foo86 in my inbox [01:06:00 CET] <nevcairiel> i had a brief look at the dca things, and they did look mostly like false positives, ie. coverity not recognizing the limitations [01:06:12 CET] <nevcairiel> .. of variable ranges [01:06:16 CET] <michaelni> "I took a look at those issues and they seem to be false positives." [01:06:52 CET] <nevcairiel> i think in particular coverity gets confused when you use get_bits etc, it cant figure out that it can only return a very limited value [01:07:25 CET] <michaelni> indeed i remember seeing that elsewhere as well [01:07:28 CET] <nevcairiel> ie. i dont need to check if get_bits(2) is below 3 [01:07:36 CET] <nevcairiel> it never can exceed 3 [01:07:37 CET] <nevcairiel> :d [01:11:28 CET] <wm4> but what if a bit gets flipped! [01:19:19 CET] <kierank> durandal_170: ? [01:27:02 CET] <Timothy_Gu> michaelni: do you have a script for uploading to coverity? [01:27:22 CET] <Timothy_Gu> also are you the only one doing the upload right now [01:33:07 CET] <michaelni> Timothy_Gu, if you call a configure line, one line to build it and one to make a tarball .... a script then yes [01:33:33 CET] <michaelni> AFAIK iam the only one doing the uploading [01:34:47 CET] <michaelni> but the uploading of the tarball i do by hand [01:39:31 CET] <michaelni> if someone wants to help with the upload, first that volunteer has to install as many external libs supported by ffmpeg as possible as coverity only tests whats enabled [01:39:49 CET] <michaelni> s/upload/build and upload/ [01:41:04 CET] <michaelni> anyway ive started my "script", ill upload it when its done [01:42:13 CET] <Timothy_Gu> michaelni: ok thx [01:44:13 CET] <cone-276> ffmpeg 03Paul B Mahol 07release/3.0:eb46065f4a08: doc/utils: fix typo for min() description [01:44:23 CET] <cone-276> ffmpeg 03Paul B Mahol 07release/2.8:f9f9f31c6c67: doc/utils: fix typo for min() description [01:44:35 CET] <cone-276> ffmpeg 03Paul B Mahol 07release/2.7:4ecb216ad447: doc/utils: fix typo for min() description [01:44:47 CET] <cone-276> ffmpeg 03Paul B Mahol 07release/2.6:53128080ebf0: doc/utils: fix typo for min() description [01:45:10 CET] <cone-276> ffmpeg 03Paul B Mahol 07release/2.5:c40ee0a107d4: doc/utils: fix typo for min() description [01:46:03 CET] <cone-276> ffmpeg 03Paul B Mahol 07release/2.3:49fb1f66f15f: doc/utils: fix typo for min() description [01:46:50 CET] <cone-276> ffmpeg 03Paul B Mahol 07release/2.2:c7fe604cf189: doc/utils: fix typo for min() description [01:47:01 CET] <cone-276> ffmpeg 03Paul B Mahol 07release/2.1:a9a5f5b388aa: doc/utils: fix typo for min() description [01:47:13 CET] <cone-276> ffmpeg 03Paul B Mahol 07release/2.0:72006016ae70: doc/utils: fix typo for min() description [01:48:00 CET] <cone-276> ffmpeg 03Paul B Mahol 07release/2.4:fcbbe360821d: doc/utils: fix typo for min() description [01:48:02 CET] <Shiz> .. [01:52:38 CET] <cone-276> ffmpeg 03Marton Balint 07master:e7dd97b5d8cd: avformat/utils: add a function to standardize creation time [01:52:39 CET] <cone-276> ffmpeg 03Marton Balint 07master:28fbdece79d2: avformat: use ff_standardize_creation_time for formats writing all format string metadata [01:52:40 CET] <cone-276> ffmpeg 03Marton Balint 07master:0418b0253aa1: ffmpeg: remove hardcoded 'now' creation_time support [01:54:32 CET] <michaelni> Timothy_Gu, iam uploading latest ffmpeg build to coverity, but if you want you can do it the next time: my "script" is here: http://pastebin.com/HMhtHSki [02:32:22 CET] <Timothy_Gu> michaelni: ok, how often do you do it? [02:33:03 CET] <michaelni> when i remember, like once every few weeks, which isnt optimal [02:33:25 CET] <Timothy_Gu> I guess I can set up a cron job doing it every day [04:02:43 CET] <cone-276> ffmpeg 03Michael Niedermayer 07master:38cd60c921c2: fate: add filter-hls [04:08:18 CET] <mark4o> hmm is anyone able to compile ffmpeg git master on OS X? [04:08:51 CET] <mark4o> libavcodec/videotoolboxenc.c:320:23: error: expected ')' [04:12:31 CET] <c_14> seems like they're all failing since 3af71ac (according to fate) [04:12:59 CET] <mark4o> void *CM_NULLABLE ctx, <- CM_NULLABLE is not defined anywhere, and is taken as an identifier [04:21:21 CET] <rcombs> that's defined in CMBase.h [04:21:30 CET] <rcombs> from CoreMedia.framework [04:22:33 CET] <rcombs> mark4o: what OS X version? [04:22:48 CET] <mark4o> rcombs: OS X 10.10.5 [04:22:56 CET] <rcombs> maybe it was added in 10.11 [04:23:30 CET] <c_14> rcombs: all darwin fate tests are failing [04:23:50 CET] <mark4o> maybe; my CMBase.h does not have CM_NULLABLE [04:24:43 CET] <rcombs> c_14: are there any 10.11 fate tests? [04:26:43 CET] <c_14> That I don't know. fate doesn't seem to mention the version [04:26:57 CET] <rcombs> probably as simple as `#ifndef CM_NULLABLE #define CM_NULLABLE #endif` [04:27:47 CET] <rcombs> mark4o: try sticking ^that after the `#include`s in videotoolboxenc.c and see if it fixes it for you? [04:28:13 CET] <rcombs> if so, send the patch and I'll signoff [04:28:35 CET] <rcombs> (I don't have a <10.11 system to test on myself) [04:31:01 CET] <mark4o> with that it has the same issue with CV_NULLABLE on line 982 [04:33:25 CET] <rcombs> #def that too [04:39:26 CET] <mark4o> that seems to work, I will send the patch [04:39:55 CET] <rcombs> thanks for the report and testing :) [04:40:01 CET] <rcombs> I'll take it there are no warnings, either? [04:41:03 CET] <mark4o> there are lots of warnings, but not on that file :) [04:41:41 CET] <rcombs> mark4o: actually, hold on a sec [04:42:01 CET] <rcombs> mark4o: https://gist.github.com/baffbb647ab6c1a18ac8 this compiles without warnings here; does it do the same for you? [04:42:26 CET] <rcombs> if the nullable annotations are optional and not particularly useful, we may as well just remove them [04:43:48 CET] <mark4o> that compiles fine as well [04:44:01 CET] <rcombs> OK, I'll send that then [04:44:16 CET] <mark4o> what are CM_NULLABLE and CV_NULLABLE defined to on 10.11? [04:44:22 CET] <rcombs> `__nullable` [04:57:00 CET] <cone-276> ffmpeg 03Rodger Combs 07master:ecba35bbe305: lavc/videotoolboxenc: remove *_NULLABLE annotations; fixes pre-10.11 build [04:57:03 CET] <jamrial> michaelni: posted a fix for the dependency stuff for the filter-hls* test [04:59:27 CET] <rcombs> mark4o: thanks again [04:59:46 CET] <mark4o> no problem [05:00:48 CET] <Akanksha> Hello everyone, I am new here! Please tell me from where should I start knowing more about FFmpeg and setting up a local instance for coding and testing? [05:01:04 CET] <twid> Just dumb question: what is videotoolbox is used for? [05:01:37 CET] <twid> start from examlpes given in repo [05:01:39 CET] <rcombs> twid: hardware video encoding on OSX [05:01:54 CET] <twid> thx @rcombs [05:10:51 CET] <jamrial> Akanksha: See http://ffmpeg.org/developer.html#Contributing [05:11:54 CET] <jamrial> basically, clone the git repo, look what you'd like to work on, then submit any patches you think are worth to the ffmpeg-devel mailing list [05:14:00 CET] <Akanksha> jamrial: Thanks a lot. I will do that for sure. :) Thanks again [07:44:40 CET] <md1001> What do I need to do for project DICOM support? [08:01:42 CET] <durandal_1707> md1001: ask via email mentor? [09:28:49 CET] <cone-676> ffmpeg 03Paul B Mahol 07master:dd2ea5cbfb30: avformat/yuv4mpegdec: fix seeking for partial files [09:44:06 CET] <wm4> remind me, is (int)(uint64)something always ok [10:14:41 CET] <mrec> hmm.. the deinterlacing using yadif=1 takes 33ms sometimes [10:21:23 CET] <fritsch> do it separately from the decoding thread [10:21:26 CET] <fritsch> and buffer some frames [10:21:29 CET] <fritsch> if you want to do it on the fly [10:21:39 CET] <fritsch> while watching interlaced content [10:22:07 CET] <fritsch> that being said, kodi also uses yadif for deinterlacing and 1080i50 works fine even on a Celeron 1008U [10:22:12 CET] <fritsch> or 1007 don't remember anymore [10:22:52 CET] <nevcairiel> yadif with slice threading is pretty fast these days [10:23:14 CET] <mrec> nevcairiel: hmm.. [10:23:41 CET] <mrec> I did not check which deinterlacer xine is using but the quality looks equal and the cpu is 20% lower here [10:24:21 CET] <mrec> I think there's still some space but I'll try to decode in a separate thread not in the displaying thread [10:25:04 CET] <durandal_1707> mrec: check xine code [10:36:09 CET] <wm4> mrec: unless you have a very weak CPU, it should be fine [10:37:51 CET] <mrec> I see juddering output from time to time .. sometimes it takes 35ms followed by around 8ms no wonder I see that something's not ok [10:38:01 CET] <mrec> well the decoding/deinterlacing should go into it's own thread.. [10:38:42 CET] <mrec> watching scrolling text gives a headache if you have to focus on it being smooth.. [10:39:04 CET] <mrec> especially since 90% of the time it is smooth [11:16:49 CET] <cone-676> ffmpeg 03Carl Eugen Hoyos 07master:8653d6e1a668: lavfi/drawutils: Add some missing GBRP pix_fmts. [11:43:58 CET] <rcombs> on one hand, stripping closed-captions SEIs should be pretty trivial [11:44:07 CET] <rcombs> on the other hand, I don't really care enough to do it [11:44:15 CET] <nevcairiel> why would that even matter [11:44:22 CET] <rcombs> ^ [11:47:49 CET] <kierank> why is that a bug [11:48:03 CET] <kierank> you break HRD by stripping closed captions [11:48:47 CET] <nevcairiel> its not a bug, its a feature request [11:49:04 CET] <nevcairiel> some people dont care about compliance, they just want their things gone =p [11:49:51 CET] <kierank> what harm is the CC doing? [11:50:15 CET] <nevcairiel> who knows [11:50:25 CET] <rcombs> "being a pain to decode and display" [11:50:34 CET] <nevcairiel> ignoring it is hard? [11:50:34 CET] <nevcairiel> :D [11:55:24 CET] <bencoh> l/47 [12:26:54 CET] <cone-676> ffmpeg 03Paul B Mahol 07master:256fa2ab1b28: avfilter: add ciescope filter [12:36:07 CET] <cone-676> ffmpeg 03foo86 07master:89813487491a: avcodec/dca: fix av_cold placement in declarations [12:36:08 CET] <cone-676> ffmpeg 03foo86 07master:00e3717b4a21: avcodec/dca: simplify condition [13:16:40 CET] <basisbit> am currently porting stuff to support ffmpeg 3. seems like the deprecated function avcodec_default_release_buffer is not there any more. any suggestion what should be used instead now? or is there some magic auto-freeing? [13:23:13 CET] <wm4> basisbit: av_frame_unref [13:28:33 CET] <cone-676> ffmpeg 03Paul B Mahol 07master:f5f34ee0de8c: avfilter/vf_zscale: unbreak RGB support [13:30:03 CET] <basisbit> wm4, thx. So you finally dropped avcodec_decode_audio3 :-\ seems like I have to fix my avcodec_decode_audio4 based code XD [13:31:20 CET] <nevcairiel> of course, its years old [13:31:39 CET] <wm4> the new API is simpler [13:32:50 CET] <basisbit> not in all use cases^^ [13:33:26 CET] <wm4> hm true it's not [13:33:35 CET] <wm4> I was thinking of the encode API I guess [13:34:06 CET] <nevcairiel> its more logical in any case, providing a pre-allocated buffer of some random size was always rather funky [13:34:15 CET] <nevcairiel> you never know which size you really need, so you just made it big [13:35:19 CET] <wm4> the big difference is that the new API requires the caller to deal with planar audio [13:35:28 CET] <wm4> the old API interleaved the result for a while [13:36:21 CET] <basisbit> this is especially difficult now when you want to play an audio and a video file and sync them perfectly while playback [13:36:39 CET] <nevcairiel> how is that related to which API is used [13:39:18 CET] <basisbit> with ffmpeg 2.8 I was able to get frames and other data from pointer positions which I could calculate from the expected bytes/s for coded bitrate stuff. I have no clue how to do that now with ffmpeg 3 with all these legacy API functions removed. [13:39:39 CET] <wm4> use samples per second instead [13:39:44 CET] <wm4> it's easier anyway [13:41:45 CET] <basisbit> hm... will have to read about the new api functions first. but samples per second sounds promising if they are always static and if you can quickly get the total amount of samples number and samples per second at video opening [13:46:21 CET] <JEEB_> oh well, RS only sent me my charger by not my rpi3 [13:46:35 CET] <JEEB_> and parcel 1/1 [13:46:58 CET] <wm4> lol [13:57:16 CET] <JEEB_> e-mailed the person who locally sent me my order confirmation [13:57:29 CET] <JEEB_> asked if I have to goto Great Britain to complain or what [14:07:02 CET] <JEEB_> ok, seemed to go rather painlessly - they just responded without asking any further that they will create another order for me with it [14:07:08 CET] <JEEB_> hopefully the things don't end before that [14:51:51 CET] <wm4> mateo`: looked at my API yet? I kind of hoped it could get rid of the FIFO business in the mediacodec wrapper [14:52:46 CET] <mateo`> wm4: no sorry I didn't get the time to look at it yet [14:57:09 CET] <mateo`> but I will do when I finish debugging the code on a particular device. [14:59:53 CET] <wm4> I've also thought about adding an async API, but I haven't posted a patch for it on the ML yet [16:25:03 CET] <GigaRoc> exit [16:32:55 CET] <cone-291> ffmpeg 03James Almer 07master:0786b28425ee: fate: fix filter-hls tests dependencies [16:33:46 CET] <mateo`> mmm this Nvidia decoder is giving me a hard time :( [16:41:57 CET] <cone-291> ffmpeg 03Michael Niedermayer 07master:50208a0424fa: avfilter/vf_ciescope: Fix "incompatible pointer type" warnings [16:41:58 CET] <cone-291> ffmpeg 03Michael Niedermayer 07master:ba687ae0bdd1: ffmpeg_vdpau: Free ctx on error path [17:01:37 CET] <Daemon404> hmmm [17:01:40 CET] <Daemon404> 8c0ceafb0f25da077ff23e394667119f031574fd is going to suck to merge [17:01:44 CET] Action: Daemon404 wonders how/what to do [17:02:37 CET] <nevcairiel> we have our own whitelist, so just dont? its only internal API [17:03:01 CET] <Daemon404> ec4c48397641dbaf4ae8df36c32aaa5a311a11bf adds a public api [17:03:10 CET] <ubitux> what are the advantages and drawback of each solution? [17:03:28 CET] <Daemon404> afaict there pretty much the same [17:03:31 CET] <Daemon404> jst different [17:03:37 CET] <nevcairiel> our whitelist has demuxer-specific defaults, which is much smarter [17:03:59 CET] <Daemon404> theirs is a whitelist and a blacklist... [17:04:02 CET] <Daemon404> to what end, i do not know [17:04:14 CET] <nevcairiel> i think ours supports that too [17:04:41 CET] <nevcairiel> i would just skip the e ntire thing, we have our own solution to that [17:05:46 CET] <Daemon404> nevcairiel, i was thinking of skipping the internal bits [17:05:51 CET] <Daemon404> and making the public api match [17:05:57 CET] <Daemon404> it's the same struct name as ours [17:06:00 CET] <Daemon404> and also a comma list [17:06:07 CET] <Daemon404> so it should be not too bad [17:06:29 CET] <nevcairiel> so, in fact you dont need to do anything, its already compatible? [17:06:51 CET] <Daemon404> close [17:06:57 CET] <Daemon404> we dont have a blacklist member of avformatcontext [17:07:05 CET] <Daemon404> also [17:07:08 CET] <Daemon404> ours: * - decoding: set by user through AVOptions (NO direct access) [17:07:09 CET] <nevcairiel> if its not implemented, i would rather not include it at all [17:07:15 CET] <Daemon404> libav;s is direct access. [17:07:21 CET] <nevcairiel> their is also avoption [17:07:26 CET] <Daemon404> ah ok [17:07:28 CET] <Daemon404> it just isnt listed [17:07:38 CET] <nevcairiel> * This field should be set using AVOptions. [17:07:39 CET] <nevcairiel> ? [17:07:44 CET] <Daemon404> yeah ok [17:07:56 CET] <Daemon404> the blacklist member should be trivial to implement [17:08:04 CET] <Daemon404> i'd rather not break API with libav [17:08:14 CET] <nevcairiel> its already incompatible in many places [17:08:22 CET] <Daemon404> is it? [17:08:28 CET] <Daemon404> where [17:09:10 CET] <jamrial> a couple functions have same name but different signature afaik [17:09:36 CET] <Daemon404> thats not as bad as a missing struct member [17:09:39 CET] <Daemon404> that will just fail to build [17:09:48 CET] <Daemon404> unless you mean differ in more than type [17:09:58 CET] <nevcairiel> actual different signatures [17:10:15 CET] <Daemon404> which funcs [17:10:17 CET] <Daemon404> im curious now [17:10:19 CET] <Daemon404> never run into it [17:10:26 CET] <nevcairiel> should get over this illusion that its a drop-in replacement on an API level [17:10:38 CET] <nevcairiel> the other direction doesnt work anyway, since we have a long list of extra things [17:10:44 CET] <Daemon404> sure, but if it is minimal effort to keep it, ill do it [17:10:48 CET] <Daemon404> i'd rather avoid a clusterfuck [17:11:00 CET] <jamrial> Daemon404: avcodec_find_best_pix_fmt2() seems to be one [17:11:08 CET] <nevcairiel> lavfi also has one or two somewhere [17:11:11 CET] <jamrial> although it's deprecated, so... [17:11:12 CET] <nevcairiel> i forgot which, since i dont care [17:12:04 CET] <jamrial> deprecated but without any apparent replacement or FF_API guards [17:12:52 CET] <jamrial> oh, guess that'd be avcodec_find_best_pix_fmt_of_list() [17:13:26 CET] <nevcairiel> i think there is one in avutil [17:13:40 CET] <nevcairiel> that whole class of functions is rather crazy [17:25:13 CET] <mateo`> so, the nvidia decoder from the nexus 9, on a h264 baseline 1080p sample, takes 41s to decode 305 frames with sw output and 1,7s with surface output ... [17:25:40 CET] <mateo`> did they put some calls to sleep on purpose on the sw output path ? [17:26:18 CET] <nevcairiel> some GPU architectures are just this slow when copying images out of GPU buffers [17:27:04 CET] <nevcairiel> sometimes you can optimize that due to fancy copy code, no clue about ARM [17:27:53 CET] <nevcairiel> You should see Intel GPUs on x86, they are also factor 10-20x in speed with an optimized copy vs naive memcpy [17:28:35 CET] <mateo`> ok [17:29:08 CET] <mateo`> at least it was not a bug on my side that makes it this slow [17:29:26 CET] <nevcairiel> well, i would never rule that out [17:29:36 CET] <nevcairiel> I'm just speculating from experience on x86 [17:30:31 CET] <mateo`> it makes sense and i've compared the FFmpeg code vs some java code that does the same, got the same results in sw output [17:32:13 CET] <atomnuker> wouldn't surprise me to see nvidia make the sw output path slower [17:32:27 CET] <atomnuker> after all they do that with cuda too [17:32:59 CET] <nevcairiel> dunno their cuda decoder on windows is equally fast as pure hardware [17:33:08 CET] <nevcairiel> with software output, i mean [17:34:10 CET] <atomnuker> if (not_an_nvidia_awesome_gpu_but_a_processor) sleep(); [17:35:37 CET] <mateo`> well i guess it's time to start working on the mediacodec decoder hwaccel [17:40:58 CET] <ubitux> http://www.quickmeme.com/img/a3/a3e74e84b75879442f73df18e67c1e0c8cb93e5919a… [17:41:30 CET] <mateo`> :D [17:51:20 CET] <cone-291> ffmpeg 03Anton Khirnov 07master:8c0ceafb0f25: urlprotocol: receive a list of protocols from the caller [17:51:21 CET] <cone-291> ffmpeg 03Derek Buitenhuis 07master:510046c228cb: Merge commit '8c0ceafb0f25da077ff23e394667119f031574fd' [17:53:26 CET] <Daemon404> i implemented blacklist [17:53:29 CET] <Daemon404> i will send it to the ML [18:09:56 CET] <Daemon404> weird... FATE occasionally uses a ton of disk i/o while running in parallel [18:10:03 CET] <Daemon404> (VM disks dont like this) [18:13:43 CET] <Daemon404> peloverde, is demuxed runnign in 2016? [18:23:22 CET] <sej> cehoyos there? [18:24:00 CET] <ubitux> cehoyos not here [18:24:14 CET] <sej> ya, figured when my tab didnt auto complete :P [18:24:29 CET] <sej> can anyone give more info on the vdpau filet project? [18:24:40 CET] <sej> reimar also not available [18:24:49 CET] <sej> or should i just email them? [18:24:50 CET] <durandal_1707> ask him via email [18:25:13 CET] <sej> okay great! [18:25:16 CET] <durandal_1707> You need hardware with vdpau support [18:25:24 CET] <sej> yes, i do :D [18:25:30 CET] <sej> have* [18:26:12 CET] <sej> have been experimenting with post processing for few weeks last year, was delighted to see it on the projects page [18:27:46 CET] <peloverde> Daemon404: That's the plan [18:28:28 CET] <peloverde> They are talking about launching the website for 2016 shortly [18:29:08 CET] <Daemon404> peloverde, ok [18:29:09 CET] <peloverde> info(a)demuxed.com should work now, I can also give you the main organizer's email [18:29:16 CET] <Daemon404> if i know with enough time in advance [18:29:21 CET] <Daemon404> i can tack it onto a NYC trip [18:29:50 CET] <Daemon404> assuming it's late 2016, as it was last year [18:29:50 CET] <peloverde> okay, I'll ping you when it goes up, they are still finalizing dates with teh venue right now [18:29:54 CET] <Daemon404> cool [18:29:58 CET] <peloverde> yeah, same time of year is the plan [18:30:03 CET] <Daemon404> cool [18:36:04 CET] <kierank> J_Darnley: have you tried with a 422 source encoding to yuv422p10 [18:36:08 CET] <kierank> just to avoid confusion [18:39:30 CET] <kierank> peloverde: nab? [18:40:15 CET] <peloverde> kierank: I'm skipping it this year [18:40:20 CET] <kierank> :( [18:40:59 CET] <Daemon404> other people in here might be going [18:43:00 CET] <wm4> I still don't get why this needs a blacklist [18:43:06 CET] <wm4> blacklists are still inherently insecure [18:45:14 CET] <Daemon404> wm4, an option i guess [18:45:17 CET] <Daemon404> if you want "all but X" [18:45:22 CET] <atomnuker> J_Darnley: https://0x0.st/8lC.png https://0x0.st/8Ur.png https://0x0.st/8Us.png [18:45:29 CET] <atomnuker> 420, 422, 444 [18:45:34 CET] <atomnuker> very weird [18:45:48 CET] <Shiz> atomnuker: is this vapourwave [18:47:11 CET] <sej> kierank: are you there? [18:48:38 CET] <kierank> sej: yes [18:49:04 CET] <atomnuker> Shiz: not vapourwave [18:49:40 CET] <sej> kierank: i have a doubt on the "fuzzing testsuite" project [18:49:51 CET] <kierank> Shiz: what's vapourware [18:49:52 CET] <sej> kierank: can you elaborate on this? Build a web interface able to extract information from each commit and run against an appropriate fuzz corpus. [18:50:17 CET] <Shiz> kierank: i did say wave, not ware [18:50:27 CET] <sej> haha [18:50:31 CET] <sej> "In the computer industry, vaporware (also spelt vapourware) is a product, typically computer hardware or software, that is announced to the general public but is never actually manufactured nor officially cancelled" [18:50:34 CET] <kierank> sej: basically the point is that a commit on jpeg shouldn't run fuzzing on h264 [18:50:34 CET] <sej> in any case :P [18:50:42 CET] <sej> oh [18:50:54 CET] <sej> okay [18:51:15 CET] <sej> ya, got it (y) [18:52:06 CET] <sej> does this higher priority or over other project? coz i'm really interested in vdapu also .... :P [18:53:18 CET] <wm4> I'm not sure if the vdpau project actually gives much [18:53:33 CET] <sej> to the people? [18:53:40 CET] <wm4> it might be too short/easy [18:53:51 CET] <wm4> no, it'd probably be somewhat useful (maybe) [18:53:55 CET] <sej> there are 2 of them actually [18:54:30 CET] <sej> one is harware acceleration (not limited to vdpau) other is post processing [18:54:51 CET] <sej> which one did you mean? [18:55:16 CET] <wm4> there is a project that wants to do postprocessing with vdpau, that one [18:55:33 CET] <sej> ya, vdpau filter .. okay [18:55:43 CET] <wm4> because vdpau has 1 API call to do this (plus some more to set it up) [18:56:16 CET] <wm4> but it's there as a project, so you can take it [18:56:16 CET] <sej> hmm [18:56:26 CET] <kierank> wm4: if it's a crap project I'm removing it [18:56:34 CET] <sej> :O [18:56:37 CET] <sej> :P [18:56:40 CET] <sej> hmm [18:56:44 CET] <sej> "all features should be usable to allow comparing the quality and performance of different hardware and hardware vs. software. " [18:56:56 CET] <sej> this part is also there in thta project [18:57:17 CET] <kierank> michaelni: why are you copy and pasting projects into outreachy [18:57:27 CET] <wm4> moreover, vdpau produces RGB output, while other filters usually remain in YUV [18:57:31 CET] <kierank> when I am the admin [18:57:43 CET] <sej> oh [18:57:43 CET] <wm4> that is, the vdpau video mixer (== postprocessor) outputs RGB [18:58:55 CET] <wm4> kierank: well I have my doubts that it's large enough, that is all [19:01:11 CET] <kierank> while carl can run gsoc and have it as a total mess outreachy will not be like that [19:02:13 CET] <kierank> I mean seriously, attracting people into open source by making them work on mxf [19:02:16 CET] <kierank> or cleaning swscale [19:03:40 CET] <Daemon404> i personally try and attract people with sweets [19:03:45 CET] <Daemon404> for some reason that is frowned upon [19:03:51 CET] <ubitux> how many gsoc/opw participants over the years stayed longer than 3 months in the project? [19:04:13 CET] <wm4> kierank: or libpostproc [19:04:24 CET] <ubitux> i really feel like trying to attract ppl with money is not a good principle anyway [19:04:44 CET] <ubitux> so since they probably won't stay, maybe better make them work on stuff we don't want to work on [19:04:45 CET] <kierank> they have mentorship as well [19:04:47 CET] <Daemon404> yes ive been saying that for years ubitux [19:04:48 CET] <ubitux> after all, we're paying them [19:05:03 CET] <Daemon404> re; money [19:05:07 CET] <Daemon404> not the other bit [19:05:10 CET] <kierank> Or actually give them interesting stuff to work on [19:05:20 CET] <kierank> instead of shit nobody wants to do [19:05:22 CET] <kierank> they aren't slaves [19:05:31 CET] <kierank> hint: when you treat people like human beings they respond like that [19:05:40 CET] <kierank> irrespective of the sociopathic nature of some in this community [19:05:59 CET] <ubitux> then my question again, who stayed after having interesting subject? [19:06:08 CET] <ubitux> but no more money income [19:06:18 CET] <Daemon404> atomnuker [19:06:44 CET] <ubitux> ah, the aac was a gsoc thing? [19:06:48 CET] <Daemon404> i think so [19:07:00 CET] <ubitux> didn't know that, okay [19:07:03 CET] <kierank> ubitux: have you had any interesting subjects [19:07:20 CET] <Daemon404> ubitux is only interested in subtitles, fact [19:07:26 CET] <ubitux> lol, please [19:07:34 CET] <ubitux> subtitles are a chore :( [19:07:45 CET] <ubitux> i hate them, i just do it because no one else wants to [19:07:50 CET] <sej> :O [19:08:21 CET] Action: sej asks ppl to kindly ignore his reaction :P [19:08:36 CET] <ubitux> kierank: i don't remember the gsoc students & subjects we had [19:09:09 CET] <kierank> it's no secret gsoc has poor leadership [19:09:14 CET] <kierank> it's why we have a stupid web server [19:09:14 CET] <ubitux> (my question was geniune, not trying to make a point) [19:10:45 CET] <kierank> if you want things to improve you have to do something about it [19:11:41 CET] <Daemon404> not a webserver, kierank [19:11:46 CET] <Daemon404> a directory listing api with samba support! [19:14:19 CET] <J_Darnley> kierank: 422, yes. 10-bit, no. [19:14:36 CET] <jamrial_> kierank: afaik it's more like someone wanted it in, mentored it for gsoc, then when everyone complained about how out of place it was for ffmpeg he ragequit and left us with the thing commited [19:15:26 CET] <kierank> gsoc is managed awfully [19:16:10 CET] <kierank> not to mention that certain people (tm) use it as a point of pride over libav [19:18:40 CET] <sej> kierank: should i do any qualification tasks to show my knowledge of creating web-interface? [19:18:49 CET] <sej> for the fuzzing testsuite [19:18:53 CET] <kierank> sej: you should do the fuzz task if you haven't already [19:19:09 CET] <sej> yes,i am currently doing that [19:19:13 CET] <kierank> ok [19:38:19 CET] <rcombs> Daemon404: I'm also interested in subtitles [19:38:39 CET] <rcombs> and should probably share more of ubitux's work on them [19:39:00 CET] <michaelni> kierank, i copy and pasted the projects from gsoc because the outreachy page was totally outdated, listing TBA placeholders for backup mentors and missing many other updates that had been done on the GSoC page [19:40:46 CET] <rcombs> [12:05:40] <+kierank> irrespective of the sociopathic nature of some in this community [19:40:46 CET] <rcombs> ^ heh, I got some genetic testing done a while back (23andme), and one of the results that came back was a predisposition towards a lack of empathy [19:49:55 CET] <michaelni> btw if noone wants to mentor the "MXF Demuxer Improvements" project then ill move it to the unmentored projects [19:50:44 CET] <michaelni> mateo`, durandal_1707, anyone else ^ [19:55:17 CET] <Daemon404> im confused by julian's email [19:55:30 CET] <Daemon404> is he using some sort of derived revision number, svn-style? [19:56:35 CET] <c_14> Daemon404: I think he means the 78734 in N-78734-g666e2ed [19:56:39 CET] <c_14> whatever that's derived from [19:56:51 CET] <Daemon404> its basically that [19:56:58 CET] <Daemon404> but usually youd give a hash [19:57:11 CET] <Daemon404> so you can actually find it [19:57:57 CET] <c_14> Not everyone knows that the part after the g is the hash. [19:58:45 CET] <Daemon404> tbh im not sure why we generate a svn-style number at all [20:13:08 CET] <Daemon404> TIL: OggSpots is a thing [20:24:34 CET] <kierank> michaelni: don't do it again [20:24:40 CET] <kierank> The page was fine [21:00:24 CET] <Daemon404> urg struct order stuff [21:03:37 CET] <cone-291> ffmpeg 03NagaChaitanya Vellanki 07master:df4b5f076e67: Add test for avpriv_get_trc_function_from_trc function [21:07:56 CET] <cone-291> ffmpeg 03Paul B Mahol 07master:768734a0ff24: avfilter/vf_vectorscope: add threshold option [21:07:57 CET] <cone-291> ffmpeg 03Paul B Mahol 07master:5e9f85925c6f: avfilter/vf_vectorscope: improve green graticule visibility [21:18:17 CET] <cone-291> ffmpeg 03Michael Niedermayer 07master:9b0eabdcdfc5: avutil/color_utils: Mark test_data as static const [21:27:49 CET] <JEEB_> heh, yadif and asm http://csbarn.blogspot.fi/2016/03/yadifmod-for-avisynth26-avisynth.html [21:28:18 CET] <JEEB_> (did yadif in lavfi have SSE2 and AVX2?) [21:28:46 CET] <Timothy_Gu> JEEB_: yes [21:28:53 CET] <cone-291> ffmpeg 03Michael Niedermayer 07master:fbfd2601f660: avcodec/utils: Fix 'ISO C90 forbids mixed declarations and code' [21:28:54 CET] <JEEB_> ok, so he probably ported that over [21:28:54 CET] <cone-291> ffmpeg 03Michael Niedermayer 07master:966eadeab317: avfilter/vf_ciescope: Fix 'ISO C90 forbids mixed declarations and code' [21:29:25 CET] <Timothy_Gu> well not sure about AVX2, but we definitely have SSE2 [21:35:12 CET] <durandal_1707> no AVX2 [21:43:08 CET] <durandal_1707> if we have only one outreachy slot why it have gsoc tasks,exp hard ones? [21:50:44 CET] <BtbN> Daemon404, usualy to have an easy way to tell if some version is more recent. That's not exactly easy with just a hash, without looking at the git log. [21:51:53 CET] <Timothy_Gu> I don't get why we don't use a more intelligent revision string [21:52:13 CET] <BtbN> Based on the latest release? [21:52:14 CET] <Timothy_Gu> like n3.1-dev-10-g5d82370 [21:52:19 CET] <Timothy_Gu> yes [21:52:23 CET] <Timothy_Gu> not based on N [21:52:36 CET] <BtbN> Probably because the tags are not in the master branch, so git describe doesn't see them. [21:52:43 CET] <Timothy_Gu> the -dev ones are [21:53:10 CET] <Timothy_Gu> in fact if you have a Git master checkout right now git describe will output one based on n3.1 [21:53:13 CET] <Timothy_Gu> -dev [21:53:37 CET] <BtbN> so the git describe that generates that version string needs to be adjusted, probably somewhere in configure? [21:54:00 CET] <Timothy_Gu> https://github.com/FFmpeg/FFmpeg/blob/master/version.sh#L8 [21:54:04 CET] <Timothy_Gu> `--match N` [21:54:16 CET] <Timothy_Gu> also see "Rants" section in http://willus.com/author/ffmpegbmark.shtml [21:56:46 CET] <BtbN> well, for me that still outputs "n2.9-dev-4001-g966eade" when done with --always [21:56:52 CET] <BtbN> because I never fetched the new tags [21:57:26 CET] <Daemon404> BtbN, true [21:57:30 CET] <Daemon404> im lazy and use dates :P [21:58:53 CET] <Timothy_Gu> BtbN: how do you not fetch tags? [21:59:02 CET] <Timothy_Gu> git fetch origin always fetches tags for me [21:59:09 CET] <BtbN> but git pull does not. [21:59:12 CET] <Timothy_Gu> oh [21:59:22 CET] <BtbN> So I only have the tags from when I first clones that repo. [21:59:25 CET] <BtbN> *d [21:59:52 CET] <Timothy_Gu> hmmff [21:59:54 CET] <BtbN> I think a plain "git fetch" also doesn't get them, you need fetch --tags [22:01:01 CET] <Timothy_Gu> My man page says that by default tags are fetched [22:01:04 CET] <Timothy_Gu> "By default, tags that point at objects that are downloaded from the remote repository are fetched and stored locally." [22:01:14 CET] <Timothy_Gu> under doc for --no-tags [22:01:20 CET] <J_Darnley> Simple solution: stop allowing merges and have a linear history [22:01:36 CET] <Timothy_Gu> but I guess this is an argument for N-<number> [22:01:56 CET] <BtbN> I'm not a fan ob the N-Thing and would like to see it go. [22:02:24 CET] <BtbN> maybe adding a silent fetch to the version.sh? [22:03:29 CET] <BtbN> Or just accept that the revision it's based on might be outdated? 2.9-dev-1234 is still better than N-70000 [22:07:41 CET] <BtbN> hm, adding git fetch in version.sh makes it show an ssh key password prompt for me. Not acceptable. [22:10:27 CET] <Compn> use web git version link to version.sh ? [22:10:51 CET] <BtbN> hm? [22:11:15 CET] <BtbN> you mean explicitly fetching from the anonymous url? [22:11:33 CET] <BtbN> That might pull in a lot of objects, depending on where the user cloned from [22:14:58 CET] <BtbN> git fetch --quiet "https://git.videolan.org/git/ffmpeg.git" "refs/tags/*:refs/tags/*" [22:45:28 CET] <durandal_1707> michaelni: is it doable to add 17 size to avfft? [22:50:16 CET] <BtbN> Timothy_Gu, sent a patch. [23:08:49 CET] <darkapex> Any pointers to helpful resources to brush-up dsp used in audio encoders/decoders? [23:09:53 CET] <atomnuker> not really, learning things as you go is probably the best way to go about it [23:10:34 CET] <atomnuker> but for lossless audio compression you don't really need to know much [23:11:53 CET] <darkapex> atomnuker: Yeah, I was still asking if I probably contribute to heavy-dsp codecs later on and I had some free time on hand. For now it's going smooth. [23:11:57 CET] <darkapex> Thanks :) [23:12:20 CET] <DHE> Question. If I want to make an API update which affects libav* but would be of no use to the ffmpeg commandline tool, would it still be accepted if I offered it as a patch via the mailing list, etc? [23:13:04 CET] <wm4> DHE: sure, but depends on the details [23:13:26 CET] <BtbN> if it doesn't pointlessly break API/ABI [23:16:41 CET] <nevcairiel> Still needs to be useful in general, bot everything is used by the CLI tools [23:16:57 CET] <nevcairiel> s/bot/not/ [23:17:57 CET] <DHE> the feature in question is for middle-of-the-stream events. I'm looking at a live streaming application which may have to deal with the source material changing in some way that renders the output file unusable from that point on without explicitly doing something not yet supported. [23:18:39 CET] <nevcairiel> We have side data to communicate changes midstream already [23:19:05 CET] <nevcairiel> Could just hook up something there [23:20:07 CET] <DHE> I'm using the HLS output format. The spec calls for a tag, "EXT-X-DISCONTINUITY" to be inserted at the time of the sequence break but that's not supported right now. [23:20:22 CET] <DHE> if the side channel is available it might be as simple as adding the feature to just HLS. that would simplify things [00:00:00 CET] --- Fri Mar 4 2016

1 0

ffmpeg.log.20160303
by burek 04 Mar '16

04 Mar '16

[00:10:35 CET] <TikityTik> for some reason i see an extra audio track in my file when i open it in mphc but it doesn't show up in ffprobe [00:11:08 CET] <TikityTik> ah nevermind, it's because i had the same filename as ogg in the same folder [00:38:29 CET] <Wildefyr> how to stop libx264 -qp 0 having muted colours? [00:45:34 CET] <Wildefyr> ah got it, I need to specify libx264rgb [02:33:59 CET] <voip_> Hello guys plase help me. How to take HLS live stream and multicast as MPEG2 480x720 AC3 [02:40:40 CET] <cine-deformed> Thank you for adding Cineform. It has been an annoying tool to deal with. [02:57:54 CET] <J_Darnley> voip_: no idea about the "multicast"bit but for the rest: -vcodec mpeg2video -s 480x720 -acodec ac3 [04:06:42 CET] <TikityTik> how do I do multiple betweens? [0:v][ovrl]overlay=0:0:enable='between(t,164,166.5) [04:16:12 CET] <TikityTik> for instance this, -filter_complex "[1:v]scale=480:270 [ovrl], [0:v][ovrl]overlay=0:0:enable='between(t,164,166.5)' [ovr2], [ovr2][ovrl]overlay=0:0:enable='be [04:16:12 CET] <TikityTik> tween(t,167,172.5)'" [04:16:43 CET] <TikityTik> gives me Stream specifier 'ovrl' in filtergraph description matches no streams [04:16:51 CET] <TikityTik> even though it worked for the first overlay [04:18:40 CET] <c_14> you need semicolons instead of commas there [04:18:58 CET] <c_14> but you can also use enable='between(t,164,166.5)+between(t,167,172.5)' [04:20:13 CET] <TikityTik> c_14: how do you know about this stuff [04:20:25 CET] <TikityTik> I find it very hard to find the information i'm looking for in the documentation [04:20:45 CET] <c_14> https://ffmpeg.org/ffmpeg-utils.html#Expression-Evaluation [04:21:29 CET] <TikityTik> how would i even know enable is an expression? [04:21:37 CET] <TikityTik> I couldn't even find the keyword enable when I was reading the overlay filter [04:22:16 CET] <c_14> https://ffmpeg.org/ffmpeg-filters.html#Timeline-editing [04:23:09 CET] <TikityTik> c_14: what kind of books do you read? [04:23:53 CET] <c_14> Interesting ones [04:24:16 CET] <TikityTik> c_14: You ready that whole web page right? [04:26:56 CET] <c_14> I haven't read all the manpages, but I've read a good portion of them [04:30:20 CET] <TikityTik> c_14: Just wondering what kind of books you read to be able to read all that. [04:30:38 CET] <TikityTik> I'm not a fan of walls of text as I never read books anymore. [04:30:57 CET] <TikityTik> so i only read the overlay filter section [04:31:21 CET] <c_14> I didn't read all of it at once, but over the time I've ended up reading most of it. [04:33:28 CET] <TikityTik> c_14: are you used to degeneracy? [04:33:45 CET] <TikityTik> if yes, then do you want to see what I was editing? [04:35:09 CET] <c_14> eeeh, sure? [04:35:40 CET] <TikityTik> it's almost done encoding [04:36:47 CET] <TikityTik> c_14: i'll PM you it [04:36:52 CET] <TikityTik> as it's nsfw [04:57:09 CET] <yongyung> Is the a guide for VP9 on how the -crf and -speed values compare to x264's -crf and -preset values? [04:58:39 CET] <TikityTik> yongyung: do you know what they do? [04:59:06 CET] <yongyung> TikityTik: Uhh what [04:59:26 CET] <TikityTik> yongyung: do you know what crf and speed does for vp9? [04:59:52 CET] <TikityTik> afaik, the values for crf in vp9 might be like vp9 where it's 10-63 [05:00:15 CET] <TikityTik> might be like vp8* [05:01:31 CET] <yongyung> I'm honestly not sure what you're trying to say^^ [05:07:13 CET] <c_14> yongyung: none I know of besides https://blogs.gnome.org/rbultje/2015/09/28/vp9-encodingdecoding-performance… which isn't quite what you wanted (since it only compares at one bitrate) [05:38:37 CET] <TikityTik> c_14: did you see that disugsting vid? [05:38:43 CET] <TikityTik> if not, i don't blame you [06:01:23 CET] <maco1717> Hi everyone, I'm trying to overlay a stream from an ipcam on another stream, video in video, and output it on a window on the same pc I've managed to do the video in video saving to file, I used a command from this page http://www.oodlestechnologies.com/blogs/PICTURE-IN-PICTURE-effect-using-FFM… [06:04:14 CET] <maco1717> My question is how to "output to screen" rated than to a file... I found piping to fplay but not shire if that be possible and if it would be the best solution as I understand fplay is more for Dev. Any recommendations? [06:40:01 CET] <yongyung> Do you guys know a sort of "music fidelity analyzer" tool that can give a "quality" estimate for audio files? [07:02:53 CET] <pzich> yongyung: what about bitrate? [07:21:12 CET] <parrot> is there a cmake utilitiy that checks if ffmpeg is installed? [08:13:15 CET] <odinsbane> If I want to use multiple filters, eg crop and rotate, do I specify -filter:v "rotate=-2.13*PI/180" -filter:v "crop=w:h:x:y" ? [08:13:39 CET] <c_14> no, separate filters with ',' [08:30:50 CET] <JakeJ> Hey, Anyone on that knows a bit about HLS and AVPlay [08:31:57 CET] <JakeJ> I am trying to decode an HLS stream, and im getting a weird issue that my PTS for audio doesn't start at 0. It starts at 132006 and increments by 2089 samples instead of 1024 (stereo audio) [10:30:01 CET] <mrec> do I still have to set the cpu optimization flags manually? [10:30:22 CET] <mrec> I remember years ago it had to be set manually [10:30:47 CET] <JEEB_> only if your cpu doesn't correctly report capabilities [10:49:13 CET] <quark67> hello, I have a question about creating Animated PNG image from a sequence of PNG images. I was able to do it on ffmpeg 2.8.4 (from macports), except, the .png created stop to loop quickly. How can I create animated PNG with infinite loop? I have tried the option -loop 0, without result. I have upgrade ffmpeg to the latest available version on macports (2.8.6), but no more result with infinite loop, and a regression (!): [10:49:14 CET] <quark67> instead of the sequence 1,2,3,...7 from the source images, the result on 2.8.6 is the sequence: 1,2,1,1,1,1,1. Any help about these (unable to obtain infinite loop, and broken 2.8.6)? Is this know? Thanks. [11:14:24 CET] <Fyr> when performing this command: [11:14:24 CET] <Fyr> ffmpeg -i input.wav output.mp3 [11:14:24 CET] <Fyr> what are the options for Lame? [11:17:16 CET] <c_14> ffmpeg -h encoder=libmp3lame [11:18:28 CET] <Fyr> nothing. =) [11:18:38 CET] <Fyr> only -reservoir, joint_stereo and abr. [11:18:59 CET] <Fyr> without -b:a or -q:a [11:19:09 CET] <c_14> It probably also supports all the generic options you know and love. [11:19:13 CET] <c_14> Those just aren't listed. [11:23:40 CET] <furq> Fyr: -b:a is -b, -q:a is -V [11:54:49 CET] <durandal_1707> quark67: open bug report [11:58:41 CET] <quark67> for the 2 questions? No way to obtain infinite loop in the animated PNG? The specification (https://wiki.mozilla.org/APNG_Specification#.60acTL.60:_The_Animation_Contr…) say num_plays must be 0. And is 2.8.6 broken (and also 3.0 that is not yet on macports?) ? [12:03:17 CET] <basisbit> hey, is the some documentation available whcih shows what changed form 2.8 to 3 regarding shared library functions of ffmpeg? [12:04:47 CET] <k_sze[work]> There is something weird about encoding as libx264. [12:05:17 CET] <c_14> basisbit: check doc/APIChanges [12:05:24 CET] <k_sze[work]> I downloaded the frame sequences of the open movie Elephant Dreams (the Blender project, you know). [12:06:39 CET] <k_sze[work]> And then I encoded it twice using -preset superfast, except the first time with `-g 250 -keyint_min=250 -sc_threshold 0`, and the second time without. [12:06:58 CET] <k_sze[work]> The two encodings result in keyframes in the exact same position, but the file sizes differ. [12:07:05 CET] <Wildefyr> anyone use nvenc here? feeding in data from x11grab but it messes up the colors as it changes the format from rgb to yuv420p, anyway I can manually set rgb? [12:07:40 CET] <c_14> Wildefyr: I don't think nvenc supports rgb [12:07:45 CET] <c_14> check ffmpeg -h encoder=nvenc [12:08:19 CET] <Wildefyr> c_14, yeah you're right [12:08:19 CET] <basisbit> c_14, thanks! [12:08:27 CET] <Wildefyr> damn that's annoying [12:13:49 CET] <Wildefyr> yeah x11grab has no option to output in anything else other than rgb too [12:13:54 CET] <Wildefyr> blast [12:14:00 CET] <Wildefyr> there goes my evil plan [12:14:25 CET] <c_14> If you think swscale is messing the conversion, you could try with zscale [12:14:57 CET] <Wildefyr> not familiar with those options [12:15:09 CET] <Wildefyr> time to go googling [12:51:19 CET] <mario78> Just go give you a note, the "FFmpeg Support Forum" link on this site: https://www.ffmpeg.org/contact.html is broken. You have to change the link to http://ffmpeg.gusari.org/index.php or fix your index.html on the domain ffmpeg.gusari.org It's very frustrating if you are looking for help and then the link to the support forum is borken. See also: http://ffmpeg.gusari.org/viewtopic.php?f=3&t=2706 [12:51:35 CET] <mario78> Bye [13:15:37 CET] <basisbit> am currently porting stuff to support ffmpeg 3. seems like the deprecated function avcodec_default_release_buffer is not there any more. any suggestion what should be used instead now? or is there some magic auto-freeing? [13:16:00 CET] <Fyr> basisbit, #ffmpeg-devel [16:04:42 CET] <GigaRoc> hello, i'm trying to use h264_qsv. But I can't get the encoder to open using avcodec_open2. i've traced the code and it's failing at the line https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/qsvenc.c#L684 q->async_fifo = av_fifo_alloc((1 + q->async_depth) * (sizeof(AVPacket) + sizeof(mfxSyncPoint) + sizeof(mfxBitstream*))); [16:04:58 CET] <GigaRoc> here is my initialzation: http://pastebin.com/RsDnuXFR [16:05:09 CET] <GigaRoc> what could be causing this error? [16:47:17 CET] <UKCoder> Hi folks, I'm trying to use ffmpeg to transcode an mt2s asset containing mpeg2video and layer 1 audio into an m2ts asset containing h.264 video and ac3 audio. Is there a way to specify the frequency at which the PCR is announced, as at the moment when I transcode the PCR is being announced every half a second or so and I would like to have the PCR announced 100ms (which I thought was required for a legitimate m2ts container) [17:04:11 CET] <basisbit> where can I get ffmpeg 3.0 shared library headers? [17:04:49 CET] <GigaRoc> basisbit: where how did you install ffmpeg [17:04:56 CET] <kepstin> basisbit: they should either come with your copy of ffmpeg or be provided in the same place as you got it from [17:06:48 CET] <basisbit> hm... then I guess I derped. didn't find them yet. will keep searching [17:07:11 CET] <GigaRoc> basisbit: if you installed ffmpeg from a package manager, you need to install the dev packages [17:08:01 CET] <basisbit> ok [19:27:20 CET] <MarcWebe1> Is it possible to use framerates < 1 ? [19:27:52 CET] <c_14> yes, but the lower you go the more likely the player is going to have issues playing it [19:28:41 CET] <MarcWebe1> I don't care, does it happen that you know the syntax? 0.1 ? I want to do screen capturing [19:29:04 CET] <c_14> iirc both fractions and decimals should work [19:37:12 CET] <podman> Hey there! I'm trying to run ffprobe on a hls manifest and i'm just getting back: [crypto @ 0x35290c0] Protocol not on whitelist 'file'! What does that mean? [19:38:15 CET] <MarcWebe1> c_14: Thanks! [19:39:30 CET] <klaxa> oh that's an interesting one, wasn't this protocol whitelisting stuff added just recently? [19:39:33 CET] <c_14> podman: try adding -protocol_whitelist file,hls [19:40:10 CET] <podman> c_14: thanks. i just tried that and now i get "Protocol not on whitelist 'file,hls'!" [19:40:26 CET] <podman> ffprobe -protocol_whitelist file,hls test.m3u8 [19:41:18 CET] <voip_> J_Darnley, thank you [19:41:56 CET] <podman> c_14: is that a compilation option? [19:42:11 CET] <c_14> no [19:42:33 CET] <podman> c_14: interesting, it doesn't seem to be working [19:42:44 CET] <c_14> it works for me... [19:42:55 CET] <c_14> What version are you running? [19:43:25 CET] <podman> 3.0 [19:43:27 CET] <c_14> And can you pastebin the m3u8? (at least one of the "filenames") [19:44:16 CET] <podman> c_14: so, this works on my mac locally, but not on Ubuntu... not sure if that's relevant [19:44:27 CET] <c_14> same version of ffmpeg? [19:44:41 CET] <podman> yep [19:44:44 CET] <podman> c_14: http://pastebin.com/76VJEi2Z [19:46:20 CET] <c_14> Does it work with the same file on your mac? [19:47:58 CET] <podman> c_14: haven't tried it, but i'd be surprised if it didn't. It was generated using the same FFMPEG commands [19:48:41 CET] <c_14> (I'm trying to figure out if it's specifically the crypto part that's failing the whitelist) [19:48:43 CET] <podman> c_14: the interesting thing to me is that it doesn't seem to use the protocol whitelist option [19:50:05 CET] <JakeJ> Hey, Anyone on that knows a bit about HLS and AVPlay [19:50:09 CET] <JakeJ> I am trying to decode an HLS stream, and im getting a weird issue that my PTS for audio doesn't start at 0. It starts at 132006 and increments by 2089 samples instead of 1024 (stereo audio) [19:51:42 CET] <podman> c_14: works locally with the same files. but... not the same version of ffmpeg. installing 3.0 now [19:59:43 CET] <podman> c_14: nevermind. doesn't work with 3.0 [19:59:45 CET] <podman> weird [19:59:55 CET] <podman> guess i'll downgrade [20:00:12 CET] <c_14> It might be a bug in the crypto portion of the hls demuxer [20:00:20 CET] <c_14> Could you report the issue on trac? [20:00:44 CET] <podman> c_14: yeah, i'll report it in a bit! [20:01:47 CET] <voip_> Hi guys, i need to take live HLS stream encode and push as MPEG2 stream. As result i recieve error: Invalid argument . Please help http://pastebin.com/SRkAHR8H [20:02:30 CET] <voip_> Also on output i need bitrate more than 3000 [20:02:32 CET] <c_14> add -f mpegts before udp:// [20:02:43 CET] <c_14> Then set a bitrate? [20:13:41 CET] <voip_> c_14, thank you it strat works, but wuality is very bad , sound chopping and picture stops [20:13:49 CET] <voip_> quality [20:20:22 CET] <voip_> i found new command it works good : -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 5000k -bt 350k -acodec ac3 -ab 192k -ar 44100 -async 1 -y -f mpegts [20:37:55 CET] <Meicceli> hi [20:38:12 CET] <Meicceli> is there a way to make ffmpeg to output converted files into a new directory [20:38:51 CET] <melkor> What about when you specify the output file name? [20:38:55 CET] <Meicceli> I'm trying ffmpeg -i input.flac /home/me/newDir/output.flac [20:39:16 CET] <Meicceli> "No such file or directory" [20:39:18 CET] <melkor> You want it to make the newDir? [20:39:19 CET] <furq> it won't create directories for you [20:39:23 CET] <Meicceli> melkor yes [20:39:47 CET] <Meicceli> furq are you sure? [20:40:30 CET] <furq> no but it's quicker to type "mkdir newdir" than it is to investigate [20:40:51 CET] <Meicceli> well [20:40:52 CET] <Meicceli> not really [20:41:17 CET] <Meicceli> for i in *.flac; ffmpeg -i "$i" -acodec mp3 -ab 256k /home/meicceli/Documents/Lumia/${${PWD%/*}##*/}/${PWD##/*/}/${i%%.flac}.mp3; [20:41:28 CET] <Meicceli> that's the full command i'm going for [20:41:38 CET] <melkor> do? [20:41:47 CET] <DHE> done? [20:41:53 CET] <Meicceli> oh yeah [20:41:54 CET] <Meicceli> :DDD [20:42:04 CET] <melkor> Meicceli: could you add a mkdir in that command too? [20:42:05 CET] <furq> i don't see how that would resist mkdir [20:42:09 CET] <Meicceli> didnt help [20:42:22 CET] <Meicceli> melkor perhaps [20:42:25 CET] <Meicceli> i'll see [20:42:37 CET] <furq> mkdir -p /home/meicceli/Documents/Lumia/${${PWD%/*}##*/}/${PWD##/*/}/; for... [20:43:27 CET] <Meicceli> for i in *.flac;do mkdir -p /home/marcus/Documents/Lumia/${${PWD%/*}##*/}/${PWD##/*/}/ && ffmpeg -i "$i" -acodec mp3 -ab 256k /home/marcus/Documents/Lumia/${${PWD%/*}##* [20:43:30 CET] <Meicceli> /}/${PWD##/*/}/${i%%.flac}.mp3;done [20:43:31 CET] <Meicceli> works [20:43:46 CET] <furq> there's no point calling mkdir inside the loop but ok [20:43:53 CET] <Meicceli> oh yeah [20:43:55 CET] <Meicceli> true [20:43:57 CET] <Meicceli> xddd [20:44:00 CET] <Meicceli> oh well [20:44:47 CET] <melkor> If I have two input files, how do I have one of them start a little bit later? [20:44:50 CET] <furq> also you should probably be using -q:a 0, not -b:a 256k [20:44:55 CET] <furq> unless you specifically need cbr [20:46:05 CET] <furq> melkor: -itsoffset 00:00:01 -i src.avi [20:46:06 CET] <furq> iirc [20:50:32 CET] <melkor> Worked. [20:50:53 CET] <melkor> Although it turns out I wanted -ss, but using that before the -i did what I needed. [21:08:04 CET] <Guest20> hi [21:08:31 CET] <Guest20> I need some help compiling ffmpeg on windows [21:10:23 CET] <NoMercy78> when I try it on msys2 as suggested on site, it says "internal error: Fatal Error: Can not create tmp file" [21:10:40 CET] <NoMercy78> I normally dont use msys much [21:10:52 CET] <NoMercy78> if anyone can help? [21:11:53 CET] <J_Darnley> What says that? configure? a configure test? make? gcc? [21:13:56 CET] <NoMercy78> sorry configure says this [21:16:09 CET] <J_Darnley> Strange. [21:16:35 CET] <J_Darnley> Can you create file where msys wants to store its temp files? [21:17:54 CET] <NoMercy78> the thing is I'm not sure where its trying to create those files [21:18:11 CET] <J_Darnley> neither am I [21:18:12 CET] <NoMercy78> in msys shell [21:18:23 CET] <J_Darnley> /tmp maybe? [21:18:26 CET] <NoMercy78> I've checked the /tmp/ folder [21:18:33 CET] <NoMercy78> and made it 777 [21:18:41 CET] <NoMercy78> and that didnot help [21:18:52 CET] <J_Darnley> does msys actually alter the Windows permissions? [21:19:15 CET] <NoMercy78> dont think so [21:19:18 CET] <J_Darnley> can you touch a file in there? [21:19:25 CET] <NoMercy78> let me try [21:19:51 CET] <NoMercy78> yes I can [21:20:16 CET] <NoMercy78> so it is trying to write somewhere else [21:30:06 CET] <furq> NoMercy78: have you checked config.log [21:30:56 CET] <NoMercy78> it says this in config log along with some other stuf, I can paste it in paste bin? [21:31:06 CET] <furq> sure [21:32:44 CET] <NoMercy78> http://pastebin.com/sgLamKhj [21:49:22 CET] <absence> i'm remuxing mts to mp4, and get thousands of messages like "[mp4 @ 000000055a1833e0] pts has no valueB". several sources online suggest adding -fflags +genpts at the beginning of the command line, but the warnings are still there, and the resulting mp4 files are bit identical. what's going on? [21:51:10 CET] <absence> at the beginning there's "[mp4 @ 000000055a1833e0] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly" [21:53:27 CET] <absence> if i try to remux to mkv instead of mp4, i get the same unset timestamps warning, followed by errors "[matroska @ 000000672c4a0540] Can't write packet with unknown timestamp" and "av_interleaved_write_frame(): Invalid argument" [22:33:32 CET] <Wader8> hello [22:34:03 CET] <JEEB_> absence: whatever you are using or whatever your input is it seems to lack timestamps [22:34:09 CET] <JEEB_> which is kind of... bad [22:34:18 CET] <JEEB_> if it's MPEG-TS that's deffo broken [22:34:40 CET] <JEEB_> unless your MPEG-TS is really broken and ffmpeg is trying to stuff it through even so [22:36:21 CET] <Wader8> I was wondering if there's a template script out there for batch convering a ton of files (mostly x264, some VP9 and VP8 (webm) and outputting with the same exact filename except changing the extension to mp4h - im trying to get x264 to x265 for archiving and preserving original quality as much as possible, thus lowering size, and videos are youtube, mostly 720p and 480p but birates and... [22:36:23 CET] <Wader8> ...exact resolutions vary so I think i have quite a hefty script to do [22:36:54 CET] <Wader8> And it's serious work, i need to get this done, since I also need to sort, but while I do sorting and archiving I might aswell conver to save on space [22:37:15 CET] <TD-Linux> I don't think you are goign to be able to outdo youtube's encodes, generally [22:38:21 CET] <kepstin> yeah, you're *always* going to get a quality loss when doing a lossy-lossy transcode, and unless you use really really slow encoding settings the size gain's gonna be not spectacular. [22:38:27 CET] <kepstin> just buy bigger hard drives :/ [22:39:00 CET] <furq> i doubt you'll get any size gain over vp9 without noticeable quality loss [22:41:04 CET] <Wader8> TD-Linux, outdo ? [22:41:55 CET] <Wader8> kepstin, i have around 3 TB ready, but I also bought this space to last me some time [22:41:55 CET] <TD-Linux> Wader8, what makes you think you can make files with smaller quality than youtube? [22:42:05 CET] <TD-Linux> *smaller filesize, same quality [22:42:15 CET] <TD-Linux> if anything, redownload your old youtube videos in the VP9 version [22:42:41 CET] <Wader8> TD-Linux, x265 lowers size by 30-40% [22:42:44 CET] <Wader8> AFAIK [22:42:50 CET] <TD-Linux> no it doesn't. [22:43:02 CET] <TD-Linux> at least not without compromising quality [22:43:15 CET] <furq> it especially doesn't do that over vp9 [22:43:23 CET] <furq> maybe over x264 on a very good day [22:44:12 CET] <Wader8> TD-Linux, old ones are probably still VP8 no ? - I have around 50 thousand videos in x264 - so I can only use your advices in the new downloads - i still need to get the existing ones ready for archival, even if not a big size drop, I need to transcode since old codecs won't be used 20 years from now [22:44:57 CET] <furq> if you're archiving then your best bet is to not lose any more quality by transcoding [22:45:52 CET] <furq> the chances of h.264 being unplayable in 20 years are roughly the same as the chances of there being no computers in 20 years because of the nuclear war that was probably caused by donald trump [22:46:45 CET] <Wader8> The little 1% probably doesn't matter, I just wanted to make sure that if there's an option to do this automatically for all the videos, since they're all different bitrates, an error of 5 % in ffmpeg determining what kind of bitrate to use for transcode might not be that bad, I just didn't want like a 50% loss of quality [22:46:55 CET] <furq> mpeg-2 is 20 years old and it's still being used in some broadcast systems afaik [22:47:06 CET] <jkqxz> H.264 is sufficiently omnipresent now that it is likely to exist ~forever. H.265 has not reached that volume yet, and may never if patent holders continue to strangle it. If you're concerned about that, stay with H.264. [22:47:12 CET] <TD-Linux> furq, more like "most" [22:47:22 CET] <furq> i thought a lot of them had moved to avc [22:47:30 CET] <TD-Linux> plus just put a copy of the decoder on the HDD if you're really worried :) [22:48:03 CET] <TD-Linux> furq, they are moving over, but I still see MPEG-2 most often [22:48:06 CET] <furq> also yeah if you use crf and you don't want quality loss, i'd expect a few videos which end up larger (and lower quality) [22:48:27 CET] <TD-Linux> in fact I've seen 4k hevc broadcast streams that had clear MPEG-2 prediction artifacts [22:48:33 CET] <furq> in my professional opinion as a guy who says things on irc, transcoding them is a waste of time [22:48:38 CET] <Wader8> Well, you're right i just kind of rather be safe than sorry, I am aware of the H265 problems I really think it's weird, and youtube said it won't support it so meh, but the TV industry probably will [22:48:53 CET] <furq> i don't think hevc is more "safe" than avc [22:49:50 CET] <Wader8> TD-Linux, those tv broadcasts are skewed, bitrates and transcoding optimized for bandwidth imo - plus these videos I have are mostly historical and are already in bad quality, just don't want them get any worse [22:50:03 CET] <furq> if you don't want them to get any worse then don't transcode them ;_; [22:50:43 CET] <absence> JEEB_: are you sure about that? the mts files i've tried are straight out of the avchd directory structure from two different cameras, and they all have the same problem [22:50:48 CET] <Wader8> furq, I'd agree too, but I just wanted to go on size, it's not a final archice, a temporary one, for 10 years :p or until I get life and work going so I can afford proper professional archive [22:51:17 CET] <furq> have you transcoded any test files to see what kind of filesize improvement you get [22:51:34 CET] <furq> i imagine that'll do a better job of convincing you that it's not worth the effort [22:51:37 CET] <Wader8> I need to fit them on the budget, and I download like 10 new per week, sometimes less or more, need to do something or it's going to fill up [22:51:54 CET] <JEEB_> absence: proper mpeg-ts should have timestamps so either your FFmpeg is broken or the file is broken [22:52:05 CET] <furq> plus if you have 50k videos being transcoded with x265 veryslow you could probably buy a new raid1 with the cost of electricity [22:52:08 CET] <Wader8> furq, I was going to use veryslow preset, i don't mind PC running through the night [22:52:37 CET] <Wader8> And ... I currently don't pay for electricity, right now I'm in a favorable position, I don't pay for internet either, and 120 Megabit [22:53:21 CET] <Wader8> And I was already making preparations to overclock my sandy bridge to somewhere around 4.2 GHZ from 3.6 stock to give it an extra boost [22:54:15 CET] <Wader8> furq, it's actually audio that's more imporatn, most videos are news, interviews, talks, reprorts, etc [22:54:32 CET] <Wader8> minority is where video is key [22:54:49 CET] <Wader8> That's why I was also researching what's better than AAC [22:54:58 CET] <Wader8> for archival [22:55:06 CET] <furq> opus [22:55:16 CET] <furq> although again i doubt it's worth it [22:55:51 CET] <kepstin> Wader8: trust me, anything ffmpeg can decode now, ffmpeg can decode in 20 years from now :) [22:56:02 CET] <absence> JEEB_: hmmm.. https://trac.ffmpeg.org/ticket/3339 [22:56:11 CET] <kepstin> the best archive format is "something that ffmpeg can read, and then don't transcode it because you lose information" [22:57:37 CET] <JEEB_> absence: can't say more specifically without there actually being technical details around [22:57:51 CET] <JEEB_> it's still possible that the camcorder is just writing broken mpeg-ts [22:58:14 CET] <JEEB_> otherwise it's FFmpeg parsing the timestamps (if they exist) incorrectly) [22:58:15 CET] <Wader8> furq, I was quite busy I couldn't get to do everything, but I put an old movie from 4.2 GB DVD Quality (MPEG2 i guess) into 1.2 GB HEVC - it's a bad example because it took me a week just for this one, because it was interlaced with some funky telecine and pulldown and stuff, but I managed, like this http://pastebin.com/PVHZTpKa [22:58:34 CET] <furq> well yeah that's the kind of filesize i'd expect x264 to be able to get [22:59:22 CET] <Wader8> I meant, busy until now, I did a ton of moving/sorting/stuff that grown in 5 years, bought 3 new HDDs in last 6 months, now I will continue, so that hevc test is from NOV 2015 [23:00:15 CET] <Wader8> And i didn't had OC, it was running stock 3.6 MHZ probably with power saving features enabled, i was doing it on a run, was renovating the room upstairs so I hooked it up through the night in the basement [23:00:36 CET] <furq> encoded 152659 frames in 44911.53s (3.40 fps) [23:00:50 CET] <furq> it's going to be quite a few nights transcoding 50,000 videos at that speed [23:01:15 CET] <Wader8> Well most vides are around 5 to 10 minutes [23:01:37 CET] <Wader8> Many of them less than 5 [23:02:02 CET] <furq> 50k 5-minute videos at 5fps comes to about two and a half years [23:03:48 CET] <Wader8> Well ... i guess, maybe I will transcode the ones that can be or just figure something out then, so ... we'll cross the bridge when we get to it on this one http://www.writeups.org/img/fiche/3179a.jpg [23:04:55 CET] <absence> JEEB_: i have no idea. mkvmerge seems to do the trick though [23:05:30 CET] <furq> well yeah this is why i said you should probably do some test encodes before committing to this [23:05:44 CET] <JEEB_> absence: it can just be assuming things, too :) [23:05:45 CET] <Wader8> But thanks for the warning, I expected it at some point, boy when I dig a hole [23:06:07 CET] <furq> if you can actually get 50% filesize improvements with no visible quality degradation then maybe it's a worthwhile use of time [23:06:16 CET] <JEEB_> but yeah, I really can't put a finger on it without actually looking at the file and unfortunately I don't have time to look at random mpeg-ts right now :/ [23:06:23 CET] <furq> but it seems like wishful thinking [23:06:24 CET] <JEEB_> but you can post another sample on that ticket [23:06:31 CET] <JEEB_> maybe someone can get into technical for you [23:06:40 CET] <Wader8> furq, certainly, the pastebin example was a test, but in that case of MPEG2, kind of skipping x264 just made sense [23:06:54 CET] <furq> sure [23:07:30 CET] <furq> if you're willing to put up with 3fps SD encodes then there's no point using x264 for archival [23:07:33 CET] <Wader8> furq, but making the commands for that test was way too time consuming, if all videos were like that it would be extremely difficult [23:08:06 CET] <Wader8> oh there's no command, furq i forgot to add the command lol, ... sec [23:08:31 CET] <Wader8> ffmpeg -v 9 -loglevel verbose -y -i VTS_CON.vob -map 0:0 -vcodec libx265 -preset slow -vf "yadif=parity=tff, fps=25/1" -pix_fmt yuv420p -x265-params crf=16 -map 0:1 -acodec aac -strict experimental -b:a 448k -ac 6 -ar 48000 -threads 8 -f mp4 VTS_FIN-crf.mp4 [23:09:04 CET] <Wader8> That line ... took me almost a week [23:09:19 CET] <furq> i should hope you'd never need -vf or -pix_fmt with videos sourced from youtube [23:09:40 CET] <Wader8> Yes this is the DVD interlaced weirness thingy [23:09:42 CET] <furq> and -threads is redundant with x265 afaik unless you explicitly want to free up cores [23:10:30 CET] <Wader8> It kind of worked with other cases, but the resulting video was all green or blue and blinking violently ugh [23:10:44 CET] <furq> should i mention that ffmpeg has a better deinterlacer than yadif now [23:10:47 CET] <furq> or would that be upsetting [23:11:28 CET] <furq> there's also avisynth and qtgmc if you don't care about encoding speed, which it seems you don't [23:11:40 CET] <Wader8> Nah, I deal with a lot harsher stuff on a daily basis so that wouldn't upset me at all [23:11:59 CET] <furq> https://ffmpeg.org/ffmpeg-filters.html#nnedi [23:13:03 CET] <Wader8> thanks [23:13:20 CET] <furq> i highly recommend qtgmc for dvd sources if you have the patience to get avisynth working [23:14:08 CET] <furq> i have a bunch of hybrid interlaced/badly deinterlaced pal tv dvds and it's done a pretty great job cleaning them up [23:15:21 CET] <absence> JEEB_: it's a two year old bug flagged as "important", but not "analyzed by developer". there are plenty of reports about this problem on various forums, i don't think lack of samples is the problem unfortunately :/ i'll check if the output from mkvmerge seems good and go with that :) [23:15:31 CET] <Wader8> I tell you this whole interlaced tech is one giant mess as we look at it now from a modern point of view, fractional framerates just don't compute in my head it just feels so wrong [23:16:05 CET] <furq> you really don't have to tell me that interlacing is the devil's signal [23:16:32 CET] <furq> and i'm sure that the hours of my life i've wasted dealing with it pale in comparison to other people in here [23:16:41 CET] <Wader8> Well, I thought if I pile on some more frustration it's gonna make it extra-sure ;) [23:17:02 CET] <JEEB_> absence: yeah, the only guy who analyzed it seems to have been cehoyos so I'm not sure how much it has been looked into. at least it was cehoyos himself who added that tag there, but he is not an MPEG-TS hacker as far as I remember [23:18:13 CET] <Wader8> And then all you need to think about is 1080i and you're ready to shoot yourself :D [23:18:18 CET] <JEEB_> absence: also check if VLC can handle the file fine, it has a separate MPEG-TS demuxer (based on libdvbpsi) [23:18:25 CET] <JEEB_> it can also remux if required [23:18:41 CET] <JEEB_> would be interesting if VLC says anything interesting about the file [23:19:53 CET] <Wader8> I understand it's serious, don't get me wrong, wasn't trying to pick on you. [23:20:50 CET] <Wader8> But i was just talking about 1080i with someone a few days ago ... [23:26:21 CET] <absence> JEEB_: i don't think i've ever had a positive experience with vlc, but maybe i'll install it some day if i get desperate enough :) [23:26:42 CET] <JEEB_> I don't use it for playback, but it's useful for some other means :) [23:27:15 CET] <absence> JEEB_: last time i tried that it didn't produce identical results from one run to another o_O [00:00:00 CET] --- Fri Mar 4 2016

1 0

ffmpeg-devel.log.20160302
by burek 03 Mar '16

03 Mar '16

[00:57:37 CET] <rcombs> atomnuker: hey, any idea when PCEs will be in aacenc? [01:11:58 CET] <atomnuker> well, I already have a patch to handle the bitstream side of things [01:13:01 CET] <atomnuker> I'll try to see if I can make it work [01:14:57 CET] <durandal_1707> atomnuker: looked at that my ascend bug report? [01:15:27 CET] <durandal_1707> aacenc* [01:15:39 CET] <atomnuker> no, can you give me a link? [01:15:47 CET] <atomnuker> is it that weird 10 second sound? [01:16:36 CET] <durandal_1707> Yes, look at spectrum, its ambient music [01:18:38 CET] <atomnuker> durandal_1707: was the name of the file artifacts.flac? [01:19:09 CET] <durandal_1707> yes, IIRC [01:26:59 CET] <atomnuker> durandal_1707: https://0x0.st/8YP.png https://0x0.st/8YZ.png [01:27:13 CET] <atomnuker> the only artifacts I can hear are the footstep-like sounds at +2 seconds [01:32:55 CET] <durandal_1707> there are vertical shapes not presented in source [01:35:04 CET] <durandal_1707> dunno if same happens with fdk-aac [01:36:41 CET] <rcombs> atomnuker: cool, thanks [01:46:15 CET] <atomnuker> durandal_170: yes, those are the footstep-like sounds [01:46:30 CET] <atomnuker> they seem to disappear with higher bitrates [01:47:00 CET] <atomnuker> I did try to see if any of the coding tools (pns, tns, is or ms) causes it but nope, seems to be the coder [01:48:48 CET] <durandal_170> ok [02:10:03 CET] <cone-228> ffmpeg 03Carl Eugen Hoyos 07master:2355b7458e63: lavf/mov: Set display aspect ratio for avid dv. [02:13:34 CET] <cone-228> ffmpeg 03Michael Niedermayer 07master:a870aa89bf38: avformat/seek-test: Support passing options to demuxers and protocols [02:13:35 CET] <cone-228> ffmpeg 03Michael Niedermayer 07master:5324882529f3: fate: add pipe and cache test [05:03:54 CET] <cone-228> ffmpeg 03Ganesh Ajjanagadde 07master:bd9c58756a50: lavc/aacenc_utils: replace sqrtf(Q*sqrtf(Q)) by precomputed value [05:45:11 CET] <chubchubcharles> hey i need help with understanding an error message [05:45:33 CET] <chubchubcharles> What does the error 'missing picture in access unit size XX' mean? [05:46:02 CET] <chubchubcharles> I got this error when I used a code from GitHub that supposedly converts video files (.avi) into key frames (images) [05:46:07 CET] <chubchubcharles> but I placed in .mkv files instead [05:46:19 CET] <chubchubcharles> is that the reason why i have this error -- because the input video format is incorrect? [05:48:15 CET] <chubchubcharles> anyone? [05:48:42 CET] <durandal_170> wild guess: missing bsf filter [05:50:10 CET] <chubchubcharles> hmm.. not very familiar with bsf filter.. [05:50:18 CET] <chubchubcharles> is there another way of explaining it? [06:26:15 CET] <Timothy_Gu> chubchubcharles: use #ffmpeg channel [06:26:20 CET] <jamrial> michaelni: valgrind complains about seek-cache-pipe test [08:35:41 CET] <PrateechiS> Hey [08:36:25 CET] <PrateechiS> Can anyone help me installing FATEserver on Mac? [09:51:56 CET] <cone-700> ffmpeg 03Paul B Mahol 07master:85dd497baad0: avfilter/vf_vectorscope: avoid crash by explicitly checking for 8-bit depth [09:51:57 CET] <cone-700> ffmpeg 03Paul B Mahol 07master:a7897bd3a6e1: avfilter/vf_vectorscope: add graticule [09:51:58 CET] <cone-700> ffmpeg 03Paul B Mahol 07master:29c6fd41fcf1: avfilter/vf_vectorscope: make background opacity customizable [09:59:14 CET] <mrec> hi, does anyone know which documentation I have to look at about the mpeg system stream header format 0x0000010 ? [10:10:52 CET] <j-b> 'morning [11:21:56 CET] <cone-700> ffmpeg 03Paul B Mahol 07master:bdf474bcff29: doc/utils: fix typo for min() description [11:57:21 CET] <JamJams> Hi just wondering does anybody know which file contains the resync code for transport streams? Save me digging around is all. [12:07:15 CET] <rcombs> mpegts.c [12:08:25 CET] <mateo`> if there is a change of configuration in the h264 bitstream, who is in charge of updating the decoder avctx with the new width/height, coded_width/coded_height ? [12:10:15 CET] <mateo`> the decoder itself ? or the layer above ? [12:12:06 CET] <wm4> there's no layer above [12:12:11 CET] <wm4> so the decoder [12:12:26 CET] <wm4> some formats may have an external mechanism to update them [12:12:43 CET] <wm4> but that's not the case with h264 [12:13:12 CET] <wm4> see apply_param_change() [12:13:43 CET] <mateo`> in the case of mediacodec, i should watch for resolution/format changes in the bitstream filter right ? [12:14:00 CET] <mateo`> and update the avctx accordingly [12:14:18 CET] <wm4> I'm not sure how exactly that works, but I don't think the annex b bitstream filter does that [12:14:28 CET] <wm4> the decoder itself would have to tell you [12:15:11 CET] <mateo`> i don't trust the value returned by mediacodec as they seem to be the coded values and not the actual ones. [12:15:35 CET] <wm4> usually a decoder will return the coded width/height, and a separate crop rectangle [12:16:14 CET] <wm4> (ffmpeg ignores this concept; for software decoding, it will adjust the plane pointers to "crop" the top/left borders) [12:20:46 CET] <mateo`> i'll double check again but from what i remember the crop values returned by mediacodec are missing most of the time [12:20:59 CET] <wbs> mateo`: as far as I've seen, it always returns crop values [12:21:13 CET] <JamJams> So mpegts.c has the code that will add extra video or audio frames to the stream to retain sync? [12:21:33 CET] <wm4> JamJams: no, ffmpeg.c does that [12:21:34 CET] <wbs> the width/height is whatever padded size the decoder chose (not necessarily the coded size), and then you have the crop-left/crop-right etc fields [12:21:51 CET] <mateo`> wbs: are the values correct ? [12:21:59 CET] <wbs> mateo`: I haven't seen a case where they wouldn't be [12:22:33 CET] <wm4> you should probably verify that they are not larger than the coded size [12:22:34 CET] <mateo`> i remember seeing cases when the crop-bottom is missing so you end up with 1920x1088 frames for example [12:22:54 CET] <wbs> (the only case where things are weird is the handling of the TI version of NV12 on the OMAP4 decoder, where one either has to adjust for the top crop offset for the second plane, or ignore the offset parameter) [12:22:59 CET] <wbs> hmm, haven't seen that [12:23:55 CET] <mateo`> ok I will double check then, my memories might be at fault here [12:24:44 CET] <JamJams> wm4 I thought so, do you know where exactly in that monster of a file :P Just looking to review how it handles sync got an odd stream here maybe a bug but probably just the stream being bad. [12:25:24 CET] <wm4> JamJams: I'm not familiar with it either, but I think at least some if it is in do_video_out() [12:25:53 CET] <JamJams> I thought it might be related to vf_framesync.c [12:30:43 CET] <JamJams> Ahhh I see it [12:30:45 CET] <JamJams> I see it [12:35:32 CET] <cone-700> ffmpeg 03Paul B Mahol 07master:5afe91833608: avfilter/vf_vectorscope: add 9 & 10 bit depth input & output support with alpha [12:57:37 CET] <JamJams> Line 946-947 of ffmpeg.c isn't it a little redundant to do that maths twice per frame :/ [13:43:05 CET] <ismail> nevcairiel: mkstemp patch is now upstream [13:43:19 CET] <ismail> master branch at least. [13:55:15 CET] <cone-700> ffmpeg 03Clément BSsch 07master:24a189e01647: fate/api: add missing FLV dependency to fate-api-seek [13:55:28 CET] <ubitux> the test is weird btw [13:55:38 CET] <ubitux> it's testing seeking on a 1sec video [13:55:46 CET] <ubitux> doesn't sound very useful [13:56:35 CET] <ubitux> it's also weird to have it depend on lavf-flv to get a synth flv [13:56:40 CET] <ubitux> anyway.. [13:58:13 CET] <wm4> hm I guess 1 seconds could get a bit tight for keyframe intervals [14:00:06 CET] <ubitux> heh, the recent thread fixes seem to allow about +80 additionnal tests to go green on helgrind fate instance [14:00:26 CET] <ubitux> ~820 more to go [14:03:39 CET] <wm4> lol [14:03:43 CET] <wm4> some progress [14:27:13 CET] <wm4> mateo`: in case you have looked at my decoder API changes, do you think that would simplify your mediacodec wrapper? [14:27:36 CET] <BBB> ubitux: hm& you mean the die one? [14:27:53 CET] <ubitux> apparently [14:28:10 CET] <BBB> ubitux: if you want more to go green, make h264slicecontext only copy the members it cares about for the next thread [14:28:18 CET] <cone-700> ffmpeg 03Michael Niedermayer 07master:554f6e930ce0: avformat/cache: Fix memleak of tree entries [14:28:25 CET] <BBB> its quite a bit of work but itll make probably about half of them go green [14:28:39 CET] <ubitux> there are still reported cases in the "core" of the threading, so that's why it get triggered in so many tests [14:29:01 CET] <BBB> and its a performance improvement if you do it correctly (i.e. only copy half of the struct and re-arrange members so they are consecutive on the top of the struct) [14:29:03 CET] <ubitux> BBB: many tests are not h264 specific [14:29:13 CET] <BBB> the same may apply to other codecs also [14:29:20 CET] <BBB> is vp9/8 having any issues? [14:29:24 CET] <BBB> their threading is much more contained [14:29:44 CET] <ubitux> almost every tests involving threading are basically failing one way or another [14:29:54 CET] <BBB> you said 80 succeed now [14:30:03 CET] <ubitux> yes, apparently [14:30:12 CET] <ubitux> http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-valgrind-threa… [14:30:14 CET] <ubitux> see scores [14:30:48 CET] <BBB> theres an asan issue btw [14:31:08 CET] <BBB> http://fate.ffmpeg.org/report.cgi?time=20160302095749&slot=x86_64-archlinux… [14:31:09 CET] <BBB> a memleak [14:31:14 CET] <ubitux> yes, valgrind reported it as well [14:31:32 CET] <BBB> and helgrind vp8/9 is clean [14:31:36 CET] <BBB> so Im not convinced [14:31:44 CET] <mateo`> wm4: I haven't looked at the new api but it's on my todolist [14:31:59 CET] <BBB> oh I see theres so many failues it doesnt fit the page [14:32:03 CET] <BBB> and vp* comes at the end [14:32:07 CET] <BBB> (its still loading) [14:32:54 CET] <ubitux> yeah, every report represents gigabytes of report [14:33:00 CET] <ubitux> of data* [14:33:29 CET] <BBB> omg wtf [14:33:32 CET] <BBB> I don't have tghat muc [14:33:38 CET] <ubitux> :)) [14:33:44 CET] <ubitux> the drd report are smaller iirc [14:33:47 CET] <BBB> much memory [14:33:48 CET] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20160302123319&slot=x86_64-archlinux… [14:33:55 CET] <BBB> my ysem is crashing thats ho ig it is [14:34:14 CET] <BBB> well that didnt work [14:35:12 CET] <ubitux> BBB: http://sprunge.us/PUCA [14:35:17 CET] <ubitux> here is one vp9 test with drd [14:36:04 CET] <ubitux> but most of the failure are probably not vp9 specific [14:36:30 CET] <BBB> oh its the p->state access outside the lock context [14:36:36 CET] <BBB> Im not sure I care about those [14:36:47 CET] <ubitux> when the core will be clean of all these issues it will be much easier to track the other codec specific issues [14:37:08 CET] <BBB> make state atomic [14:37:18 CET] <BBB> I think the google dude is doing that now [14:43:26 CET] <BBB> the drd page is also unresponsive as soon as I click any link [14:43:28 CET] <BBB> :( [15:06:50 CET] <ismail> what is the version of master atm 3.1? [15:11:30 CET] <nevcairiel> 3.1-dev, but thats really not a version worth using anywhere [15:13:03 CET] <ismail> nevcairiel: I am packaging git snapshots for unofficial purposes, thats why I asked [15:13:06 CET] <ismail> thanks! [15:13:17 CET] <nevcairiel> should just use git-describe for that =p [15:13:27 CET] <nevcairiel> thats what the binary will call itself as well when build from git [16:01:29 CET] <ubitux> Daemon404: do you have plans for the blacklist/whitelist mechanism in urlprotocol? [16:01:43 CET] <ubitux> or we're going to keep our system? [16:01:48 CET] <Daemon404> im unsure [16:02:01 CET] <Daemon404> i would not like to break compat [16:50:08 CET] <BBB> nevcairiel: how does a hwaccel signal that it does not support a particular stream? [16:50:23 CET] <Daemon404> (inb4 blows up) [16:52:05 CET] <nevcairiel> BBB: it doesnt [16:52:11 CET] <nevcairiel> you are supposed to check [16:52:35 CET] <nevcairiel> if its entirely incompatible, it will usually just not invoke the function to activate hwaccel [16:52:42 CET] <nevcairiel> ie. different chroma format or bitdepth [16:53:07 CET] <nevcairiel> but other than that, its the users responsibility to check the capabilities of the hardware [16:53:17 CET] <BBB> hm [16:53:29 CET] <ubitux> so apparently firefox is still unable to play mp4 properly [16:53:37 CET] <ubitux> i got a 1sec lag every second [16:53:40 CET] <nevcairiel> it really only applies to different types of 420 8-bit, like h264 lossless [16:53:49 CET] <ubitux> (even when playing the file locally within firefox) [16:54:20 CET] <mateo`> ubitux: maybe install flash player [16:54:34 CET] <JEEB> mp4 playback for me has worked pretty well for quite a few months [16:54:48 CET] <Daemon404> same [16:54:50 CET] <JEEB> although I've always used the "developer edition" firefox [16:54:50 CET] <ubitux> JEEB: http://b.pkh.me/tourbillons-de-neige.mp4 plays smoothly for you? [16:54:58 CET] <JEEB> ubitux: wait until I get home [16:55:02 CET] <Timothy_Gu> ff on windows work fine [16:55:09 CET] <Daemon404> ubitux, broken here [16:55:11 CET] <Daemon404> same lag [16:55:13 CET] <ubitux> right [16:55:14 CET] <Daemon404> on windows [16:55:19 CET] <ubitux> okay. [16:55:49 CET] <Daemon404> works in chrome [16:55:56 CET] <ubitux> yes, it works everywhere [16:56:01 CET] <ubitux> except firefox (even locally) [17:00:15 CET] <ubitux> but it seems caused by the ffmpeg remux though [17:01:52 CET] <ubitux> more specifically, by the time offsetting [17:02:26 CET] <Daemon404> 'time offsetting'? [17:02:28 CET] <ubitux> -ss [17:03:12 CET] <Daemon404> o [17:03:14 CET] <Daemon404> elst? [17:05:25 CET] <ubitux> yeah, probably related as usual [18:14:57 CET] <cone-596> ffmpeg 03Mats Peterson 07master:2be0366a7f5d: lavf/utils: Add ff_get_packet_palette() [18:16:19 CET] <kierank> pfft [18:22:30 CET] <ubitux> ffmpeg -f lavfi -i "aevalsrc=floor(t)/10:d=10" -lavfi showwavespic out.png [18:22:32 CET] <ubitux> what am i doing [18:39:48 CET] <mrec> can anyone recommend some good documentation about MPEG2? [18:40:20 CET] <mrec> even though I'm able to decode kind of everything using libavcodec I'm not satisfied with the video playback [18:40:46 CET] <mrec> xine seems to have the best deinterlaced playback [18:41:02 CET] <mrec> libavcodec using yadif=1 is second [18:41:13 CET] <BtbN> try the new neural network magic [18:41:16 CET] <mrec> but the cpu usage of libavformat is poor [18:41:45 CET] <BtbN> And i don't see how deinterlacing is related to mpeg2 documentation. [18:42:19 CET] <mrec> the presentation part is not clear to me and I seem to be stuck with that topic [18:42:44 CET] <BtbN> presentation is not the job of ffmpeg though [18:45:25 CET] <ubitux> ffmpeg has many deinterlacer, and maybe your source is just telecined and using yadif is wrong [18:50:29 CET] <wm4> xine also could be using random filters? [18:50:55 CET] <mrec> the cpu time xine vs ffplay 15:40 [18:51:06 CET] <mrec> ffplay using yadif=1 [18:51:22 CET] <mrec> there's some difference on the deinterlaced picture they're using another deinterlacer [18:51:35 CET] <mrec> however my main problem is the juddered picture from time to time [18:52:12 CET] <mrec> I only see that on scrolling video though [19:36:31 CET] <smontgomerie> Hey guys I'm wondering if I can get some help compiling ffmpeg on Windows 10 [19:36:42 CET] <smontgomerie> configure passes without error [19:36:50 CET] <smontgomerie> get this error: [19:36:51 CET] <smontgomerie> awk: cmd. line:1: /including/ { sub(/^.*file: */, ""); gsub(/\/, "/"); if (!match($0, / /)) print "libavdevice/alldevices.o:", $0 } [19:37:00 CET] Last message repeated 1 time(s). [19:37:00 CET] <smontgomerie> awk: cmd. line:1: ^ syntax error [19:37:18 CET] <smontgomerie> awk: cmd. line:1: ^ unterminated string [19:37:36 CET] <smontgomerie> but the awk line looks fine [19:38:26 CET] <smontgomerie> there was a mention of this on this thread: https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=2440 [19:38:33 CET] <kierank> probably some windows whitespace issue [19:38:39 CET] <smontgomerie> the solution being to update make [19:39:13 CET] <smontgomerie> huh, ok how would i debug that whitespace issue? [19:39:21 CET] <smontgomerie> This is MSYS btw [19:40:33 CET] <Daemon404> i mean, you kind of answered your own question [19:40:39 CET] <Daemon404> your make is probably ancient [19:40:49 CET] <Daemon404> which, if youre on the original msys, is certain [19:40:53 CET] <smontgomerie> $ make -v [19:40:53 CET] <smontgomerie> GNU Make 4.1 [19:40:53 CET] <smontgomerie> Built for i686-pc-cygwin [19:41:05 CET] <Daemon404> hmm [19:41:11 CET] <smontgomerie> I installed make from pacman [19:41:24 CET] <smontgomerie> and which make uses the right one (now) [19:41:34 CET] <Daemon404> did you per chance clone the git repo with 'native' endings instead of whats in the repo [19:41:37 CET] <Daemon404> some versions of git have that [19:41:40 CET] <Daemon404> byt defauly [19:41:44 CET] <Daemon404> by default* [19:42:29 CET] <smontgomerie> huh. well I'm seeing the same error in a fresh "git clone" as well as downloading the src zip from http://ffmpeg.zeranoe.com/builds/ [19:43:18 CET] <smontgomerie> on the git clone version, I do get this error prior: ./version.sh: line 2: $'\r': command not found [19:43:30 CET] <smontgomerie> so line endings are a possibility [19:44:40 CET] <smontgomerie> dos2unix version.sh got rid of the version error [19:44:53 CET] <Daemon404> nothing in the repo should have dos endings. [19:45:38 CET] <Daemon404> git config --global core.autcrlf false [19:45:41 CET] <Daemon404> ^ do this, then clone [19:45:55 CET] <Daemon404> also why does your make from cygwin [19:45:59 CET] <Daemon404> you said you were using msys. [19:46:12 CET] <smontgomerie> that is a good question... [19:46:39 CET] <Daemon404> $ make -v [19:46:39 CET] <Daemon404> GNU Make 4.1 [19:46:39 CET] <Daemon404> Built for x86_64-pc-msys [19:47:36 CET] <JEEB> <@Daemon404> git config --global core.autcrlf false <= autocrlf is the most !?!? option I know of in git [19:47:43 CET] <smontgomerie> ok... weird [19:47:45 CET] <smontgomerie> $ which make [19:47:52 CET] <smontgomerie> GNU Make 4.1 [19:47:52 CET] <smontgomerie> Built for x86_64-pc-msys [19:48:15 CET] <smontgomerie> so yeah it was using the wrong make somehow. [19:48:34 CET] <smontgomerie> sory [19:48:35 CET] <smontgomerie> $ /usr/bin/make -v [19:48:35 CET] <smontgomerie> GNU Make 4.1 [19:48:35 CET] <smontgomerie> Built for x86_64-pc-msys [19:49:32 CET] <smontgomerie> now i have a whole different set of errors. I'll bash my head against the wall on these for a while, thx. [19:49:49 CET] <Daemon404> your environment sounds broken [19:50:05 CET] <smontgomerie> it's a fresh install of msys [19:50:27 CET] <smontgomerie> maybe I'll reinstall everything [19:51:43 CET] <smontgomerie> ok i'll do that, thx for your help! [20:12:45 CET] <durandal_1707> people ask me to add features to lavfi for free [20:12:58 CET] <kierank> like what [20:16:14 CET] <durandal_1707> top secret, only shared with VIP like me [20:32:15 CET] <durandal_1707> its for sofalizer... [20:34:13 CET] <durandal_1707> BBB: y4m demuxer doesn't seek to begining if its partially downloaded [20:40:11 CET] <BBB> ? [20:40:20 CET] <BBB> I didnt write the y4m demuxer [20:46:29 CET] <durandal_1707> but seeking [20:56:53 CET] <durandal_1707> BBB: fixed it [20:57:21 CET] <BBB> ok [20:57:59 CET] <kierank> durandal_1707: make mats use trac [20:58:50 CET] <durandal_1707> kierank: he have book in pal8 format [21:00:26 CET] <Daemon404> kierank, or... irc [21:00:31 CET] <Daemon404> an actual instant messaging protocol [21:00:34 CET] <kierank> yes [21:00:35 CET] <Daemon404> which is how he uses email [21:00:38 CET] <kierank> then I could put him on ignore [21:03:45 CET] <durandal_1707> If I didn't looked in my spam folder I would never noticed him [21:04:48 CET] <Daemon404> his latest email is amusing [21:04:54 CET] <Daemon404> "I noticed that you, Paul, added a patch somewhere in 2012" [21:04:59 CET] <Daemon404> it's not even CC'd to durandal_1707 [21:05:13 CET] <JEEB> lol [21:13:26 CET] <jamrial> i added a filter to thunderbird to hide every single thread started by him until he stops spamming the list [21:15:26 CET] <Daemon404> he needs to learn to thread his patchsets too. [21:16:42 CET] <ilovewebm> Hi! Quick question, how did ffmpeg develop decoders/encoders of a proprietary codec whose specification was not available? Reverse engineering encoded files? [21:17:05 CET] <JEEB> you usually have some sort of decoder and/or encoder [21:17:09 CET] <JEEB> then you reverse engineer that [21:17:11 CET] <fritsch> there was a nice blog entry about that lately [21:17:29 CET] <Daemon404> i personally prefer to divine it from the gods of multimedia [21:17:32 CET] <JEEB> you can't do too much with just the files :P [21:17:36 CET] <JEEB> Daemon404: :D [21:17:36 CET] <ilovewebm> That sounds challenging [21:17:43 CET] <ilovewebm> :D [21:20:37 CET] <cone-466> ffmpeg 03Rick Kern 07master:3af71ac3f9f6: lavc: add VideoToolbox H.264 Encoder [21:21:40 CET] <ilovewebm> fritsch: Do you have the link around for the blog post? I'm trying to google but I suck :/ [21:21:57 CET] <fritsch> i don't find it - it was a dev from this channel [21:22:12 CET] <fritsch> that described how he reverse engineered a partly known format [21:22:18 CET] <fritsch> and gave a talk on a conference [21:22:22 CET] <fritsch> but I cannot find it anymore [21:22:38 CET] <ilovewebm> Cool np, I'll try and dig more, thanks! [21:23:29 CET] <fritsch> https://fosdem.org/2016/schedule/event/video_reverse_eng/attachments/slides… [21:23:32 CET] <fritsch> found it [21:23:42 CET] <durandal_1707> ilovewebm: there is fosdem video, recent [21:24:12 CET] <ilovewebm> Awesome, thanks a lot :) [21:25:11 CET] <Daemon404> is it up yet [21:25:40 CET] <Daemon404> indeed [21:25:40 CET] <Daemon404> so it is [21:27:36 CET] <Daemon404> the audio on this is so bad [21:27:38 CET] <Daemon404> A+ fosdem... [21:29:28 CET] <durandal_1707> and there are blogs [21:53:42 CET] <durandal_1707> how many outreachy slots we have? [22:35:36 CET] <J_Darnley> durandal_1707: last I heard, one [22:52:56 CET] <durandal_1707> kierank: have 4k pdf for pattern generation? [22:55:56 CET] <jamrial> michaelni: check foo86's recent patchset to see if they fix the coverity stuff you informed him about a few weeks ago. if not poke him about it again [23:30:40 CET] <Daemon404> urg i need to merge more tomorrow [23:33:39 CET] <jamrial> Daemon404: tep2 commits? [23:34:29 CET] <Daemon404> no theres some more stuff up to it [23:34:35 CET] <Daemon404> like 6-7 commits [23:34:37 CET] <Daemon404> wont take long [00:00:00 CET] --- Thu Mar 3 2016

1 0

ffmpeg.log.20160302
by burek 03 Mar '16

03 Mar '16

[01:07:23 CET] <nader> Is there any way to have the input url for ffmpeg be proxied? [01:08:16 CET] <nader> so for example: ffmpeg -i "%s" -acodec libmp3lame -f mp3 - [01:10:57 CET] <J_Darnley> What? [01:12:20 CET] <J_Darnley> http has a proxy server option [01:12:20 CET] <nader> Sorry, be more clear. I'm trying to convert a stream to a mp3, but want the stream to download through a proxy [01:13:03 CET] <nader> right i see http_proxy in the ffmpeg-protocols [01:13:32 CET] <nader> but I can't find a example of some one using the http [01:14:01 CET] <nader> so would I do something along the lines of "ffmpeg http "proxy url" -i "download url" ... [01:14:02 CET] <nader> ? [01:14:07 CET] <J_Darnley> isn'tit just ffmpeg -http_proxy PROXY -i ... [01:14:22 CET] <nader> ok cool thank you [01:22:12 CET] <t4nk046> Hi [01:24:49 CET] <t4nk046> Hello ??? [01:25:35 CET] <durandal_1707> yes? [01:25:45 CET] <t4nk046> I want to ask a question about ffmpeg [01:25:57 CET] <durandal_1707> ask [01:26:23 CET] <t4nk046> ok , how can make a time shift by ffmpeg? [01:27:02 CET] <t4nk046> i need a time shift for the past 6 hours [01:27:11 CET] <mattf000> I am trying to use ffmpeg/x264 for realtime streaming a capture card over RTMP. My current issue is that every GOP am seeing a "flicker" where the quality of the picture degrades and comes back right away. I'm guessing this is from each keyframe? Using intra-refresh seems to eliminate the flicker but it introduces about a second worth of latency which makes it unusable. Any suggestions? [01:32:12 CET] <isoboy> Hi relaxed, sorry I left abruptly. [01:34:15 CET] <durandal_1707> t4nk046: setpts filter? [01:35:41 CET] <isoboy> I figured that the problem was due to x264 encoding which sends a keyframe periodically [01:36:04 CET] <isoboy> ffmpeg had not received the keyframe, which makes it impossible to reconstruct the image [01:36:06 CET] <isoboy> https://stackoverflow.com/questions/15005436/errors-when-decode-h-264-frame… [01:37:37 CET] <t4nk046> sorry i don't know what you mean , i have a live streaming , i need to record to a file the past 6 hours . when its recorded the past 6 hours for example , it will continue recording and deleting the extra time [01:39:55 CET] <durandal_1707> select and aselect filter? [01:41:34 CET] <t4nk046> can you please copy and paste me from the documantation ? [01:43:00 CET] <durandal_170> Can't [04:45:10 CET] <yongyung> For two pass encoding, should I set a higher bit rate for pass 1 or the same? I've seen different things online [04:45:59 CET] <pzich> uh, I'm pretty sure it's supposed to be the same [04:52:03 CET] <yongyung> pzich: Yeah makes the most sense I guess - if I change the resolution, do I set the scaling filter in pass 1, pass 2 or both? [04:53:39 CET] <pzich> I believe the idea is the settings should be the same for both passes, just one as -pass 1 and one as -pass 2 [05:10:23 CET] <jookiyaya> typing in mirc [05:12:49 CET] <nader> I'm trying to use ffmpegs http_proxy option, but it's telling me its not found. I'm running fmpeg version git-2016-02-16-00bd237 [05:42:14 CET] <jookiyaya> what is the command to change just the container from flv to mp4 [05:43:10 CET] <jookiyaya> nevermind i found it [05:43:45 CET] <jookiyaya> for i in *.flv; do ffmpeg -i "$i" -vcodec copy -acodec copy "${i%.*}.mp4"; done [05:43:53 CET] <jookiyaya> is this cmd.exe command or bash command [05:46:18 CET] -jookiyaya:#ffmpeg- anybody know? [05:46:48 CET] <Fletcher> please don't do that [05:52:05 CET] <yongyung> "constant rate-factor is incompatible with 2pass." - well, that's a new one [05:52:32 CET] <whyze> i'm using ffmpeg indirectly through youtube-dl and most of the time the stream is incomplete and ffmpeg doesn't indicate that it was unsuccessful. an example that i have tried 5 times recently that only completes about 13 minutes of the expected 43 minutes: http://pastebin.com/raw/vmMmS3F7 [05:52:34 CET] <yongyung> I am supposed to use -b:v on the second pass right? It worked before... [05:55:00 CET] <yongyung> Oh LOL, ffmpeg can parse "20m" as bitrate for the first pass apparently, but gets confused on the second pass [05:56:39 CET] <jookiyaya> for i in *.flv; do ffmpeg -i "$i" -vcodec copy -acodec copy "${i%.*}.mp4"; done does this delete the source file? [05:59:52 CET] <furq> no [06:02:19 CET] <yongyung> jookiyaya: Do you want a windows .bat file that changes all containers in it's directory to .mp4? [06:02:37 CET] <jookiyaya> yongyung just *.flv [06:03:03 CET] <jookiyaya> youngyung yes i do but nobody knows how; people only know how to do it in bash [06:03:17 CET] <jookiyaya> so i forced to use winbash [06:03:27 CET] <jookiyaya> i am* [06:03:57 CET] <yongyung> jookiyaya: 1 sec [06:04:09 CET] <jookiyaya> yongyung wow you must be smart [06:14:34 CET] <yongyung> jookiyaya: Sorry had to do smth else, anyway http://codepad.org/0UsNsHSm - this *will* delete the source file no matter what, if you don't want that remove the del [06:14:50 CET] <yongyung> It will also overwrite any existing .mp4 file with the same name [06:15:25 CET] <yongyung> Also, mp4 doesn't support all video/audio codecs, so the conversion might file, and the source file will still be deleted. I'd recomment using mkv as a container format [06:15:28 CET] <jookiyaya> yongyung does that also do "file modification thing" [06:15:45 CET] <yongyung> jookiyaya: Not sure what you mean [06:16:25 CET] <jookiyaya> when i do ffmpeg -i input.mkv -vcodec copy -acodec copy output.mp4 output.mp4's file modification date becomes todays [06:16:37 CET] <jookiyaya> i want same file modification date as input.mkv [06:16:45 CET] <jookiyaya> or input.flv [06:17:58 CET] <yongyung> jookiyaya: That's not possible with batch, you'd need to use some external tool for i [06:17:59 CET] <yongyung> t [06:18:18 CET] <jookiyaya> what about bash then [06:18:22 CET] <jookiyaya> i have winbash [06:18:35 CET] <yongyung> No clue [06:19:16 CET] <furq> http://manpages.debian.org/cgi-bin/man.cgi?query=touch&format=ascii [06:25:52 CET] <jookiyaya> yongyung it worked but it didn't show the progress messages like it did with this command for i in *.flv; do ffmpeg -i "$i" -vcodec copy -acodec copy "${i%.*}.mp4"; done [06:25:58 CET] <jookiyaya> why is that [06:27:41 CET] <yongyung> jookiyaya: Because of -loglevel error, you can remove it if you want, it's just that I consider the output pretty pointless since you're not reencoding [06:28:14 CET] <jookiyaya> i see [06:28:38 CET] <jookiyaya> so there is no way to do the "file modification date" thing? [06:33:44 CET] <yongyung> jookiyaya: Not with windows board tools, you can probably download a tool to do it somehow [07:15:08 CET] <jookiyaya> is it normal that seeking is slow on .flv container compared to mp4/mkv [07:23:44 CET] <chubchubcharles> hey guys i need help in understanding an error message [07:23:50 CET] <chubchubcharles> what does "missing picture in access unit with size XX" mean? [07:24:30 CET] <chubchubcharles> I got this error after running a GitHub code that is supposed to perform key frame extraction and conver video files (.avi) into images files (images) [07:25:06 CET] <chubchubcharles> i put in .mkv file instead of .avi file -- is that the reason for the error? incorrect input format ? [07:25:23 CET] <chubchubcharles> any comments, suggestions welcomed [07:26:54 CET] <jookiyaya> where can i download ffmpeg that supports fdkaac [07:29:26 CET] <yongyung> jookiyaya: You can't, since fdkaac is licensed - what do you want to do? [07:29:59 CET] <jookiyaya> who owns fdk aac [07:30:44 CET] <yongyung> fraunhofer [07:31:49 CET] <jookiyaya> does ffmpeg support PsyTEL? [07:47:21 CET] <chubchubcharles> anyone? [07:47:34 CET] <chubchubcharles> know what "missing picture in access unit with size XX" mean? [08:02:34 CET] <jookiyaya> how many different mp3 encoder does ffmpeg support [08:34:57 CET] <durandal_170> jookiyaya: 2 [08:35:08 CET] <jookiyaya> one is lame, what is other [08:35:30 CET] <durandal_170> shine [08:36:14 CET] <jookiyaya> i never heard of such encoder [08:36:47 CET] <jookiyaya> are you making this up [08:37:46 CET] <durandal_170> no [08:38:44 CET] <jookiyaya> i don't see shine [08:49:28 CET] <varunvasudeva> Hi! I need a little help on -segment_list, I want to pass dynamic date as m3u8 file name. Anybody can help in that! [08:49:43 CET] <yongyung> I need help interpreting these quality analysis results - which file looks the best? Oo http://codepad.org/KVvzIvWT [09:59:00 CET] <Betablocker> some native speakers in here? how the hell did I pronounce this tool - http://weewx.com/ ?? [09:59:15 CET] <Betablocker> wee double u x ? [10:00:48 CET] <Betablocker> to wx means by the way on german - to wank ! [10:00:51 CET] <Betablocker> rofl [10:01:27 CET] <Betablocker> wix.com is on germaen like wanking a penis ! not the best domain& think they did not checked their name on german :D [10:02:07 CET] Action: Betablocker is mumbeling something about a perverted world [11:15:15 CET] <Eiken_> hi. been searching like a madman without finding what i need. is there some way of doing linear > sRGB conversion when encoding movies. our input files are linear exr [11:16:11 CET] <Eiken_> looked at colormatrix but couldnt figure it out [11:35:26 CET] <durandal_170> Eiken_: exr are already converted to sRGB [11:35:45 CET] <durandal_170> by just decoding [11:36:44 CET] <yongyung> Do you guys think crf or 2pass encoding with a similar bitrate would look better? [11:39:47 CET] <furq> if you want a specific bitrate use 2-pass, otherwise use crf [11:40:18 CET] <furq> there shouldn't be any difference in quality if they both happen to hit the same bitrate [11:54:24 CET] <yongyung> furq: That makes 2pass kind of obsolete unless you need to hit a very specific file size, right? I mean you can always kinda guess how big the file is gonna get with a crf value if you're willing to test it for a couple seconds of the video [11:55:51 CET] <furq> that couple of seconds probably won't give you a representative bitrate [11:56:04 CET] <furq> but yeah unless you have filesize constraints, don't use 2-pass [12:16:43 CET] <Carlrobertoh> How could i translate this ffmpeg pipe output "ffplay -rtsp_flags listen -i rtsp://ip:port/live.sdp" to vlc ? I would like to listen incoming stream. [12:28:31 CET] <jookiyaya> how many different mp3 encoder does ffmpeg support [12:28:50 CET] <isi1du> u asked the same yesterday jookiyaya? [12:29:12 CET] <isi1du> and got the answer 2, lame and shine [12:29:18 CET] <jookiyaya> i don't see shine [12:29:35 CET] <isi1du> libshine? [12:29:57 CET] <jookiyaya> i have never heard of shine mp3 encoder [12:30:16 CET] <isi1du> ok? [12:30:34 CET] <isi1du> u ever heard of google? [12:30:44 CET] <jookiyaya> and there is no libshine [12:30:53 CET] <isi1du> https://github.com/toots/shine [12:33:06 CET] <jookiyaya> there is no libshine [12:33:15 CET] <Carlrobertoh> someone? [12:33:45 CET] <isi1du> jookiyaya yes there is. [12:33:46 CET] <isi1du> sudo apt-get install libshine [12:33:46 CET] <isi1du> libshine2 libshine2-dbg libshine3 libshine3-dbg libshine-dev libshine-ocaml libshine-ocaml-dev [12:34:10 CET] <jookiyaya> Unknown encoder 'libshine' [12:34:47 CET] <jookiyaya> Unknown encoder 'libshine2' [12:34:49 CET] <jookiyaya> Unknown encoder 'libshine3' [12:34:54 CET] <isi1du> usage: shineenc [options] <infile> <outfile> [12:35:16 CET] <isi1du> shineenc v1.01 2007-01-02 [12:35:16 CET] <isi1du> USAGE : shineenc [options] <infile> <outfile> [12:35:16 CET] <isi1du> options : -h this help message [12:35:16 CET] <isi1du> -b <bitrate> set the bitrate [32-320], default 128kbit [12:35:16 CET] <isi1du> -c set copyright flag, default off [12:35:28 CET] <jookiyaya> shineenc? what does that have to do with ffmpeg [12:36:04 CET] <jookiyaya> R:\>ffmpeg64.exe -i a.wav -codec:a libshine3 b.mp3 [12:36:21 CET] <jookiyaya> Unknown encoder 'libshine3' [12:36:22 CET] <isi1du> https://trac.ffmpeg.org/wiki/Encode/HighQualityAudio - if you look here it shuld be named libshine [12:36:45 CET] <atomnuker> don't use libshine, use lame, lame is much better [12:37:31 CET] <jookiyaya> atomnuker that's not the point [12:37:34 CET] <atomnuker> the only reason libshine exists is because it *can* be faster on some systems (e.g. embedded) [12:38:04 CET] <jookiyaya> i want to encode using shine for testing purposes [12:38:12 CET] <jookiyaya> but there is no shine on my ffmpeg.exe [12:38:31 CET] <relaxed> you'll have to compile ffmpeg with libshine support [12:38:32 CET] <atomnuker> well, unless ffmpeg is compiled with libshine support it won't work [12:38:51 CET] <jookiyaya> and how do i do that [12:39:11 CET] <isi1du> https://trac.ffmpeg.org/wiki/CompilationGuide [12:39:17 CET] <jookiyaya> why doesn't include by default [12:40:13 CET] <jookiyaya> isi1du that's way too complicated [12:43:39 CET] <isi1du> then go with lame. [12:45:31 CET] <jookiyaya> i need shine for testing purposes [12:45:31 CET] <Carlrobertoh> i want to listen some incoming stream from vlc [12:45:37 CET] <Carlrobertoh> for ffmpeg i would use ffplay -rtsp_flags listen -i rtsp://127.0.0.1:8554/live.sdp [12:45:40 CET] <Carlrobertoh> but how could i see stream in vlc [12:46:49 CET] <isi1du> jookiyaya if you want to test using shine, then you have to compile a version with it yourself. [12:48:09 CET] <durandal_170> jookiyaya: its quality is low and only exist because its faster on one specific arch [12:51:41 CET] <jookiyaya> can i just download shineenc.exe then [12:56:17 CET] <Carlrobertoh> is here someone who can help me? [12:57:17 CET] <c_14> Carlrobertoh: as your question pertains to vlc ask in #videolan [13:12:24 CET] <Eiken_> durandal_170: hmm not for us [13:12:59 CET] <Eiken_> created some .cube lut files in nuke that we figured out we could use with lut3d filter [13:13:02 CET] <Eiken_> seems to work [13:14:34 CET] <durandal_170> Eiken_: ? [13:15:54 CET] <Eiken_> on the linear to srgb of exr files [13:35:14 CET] <mrec> is there any summary available what ffmpeg is really parsing when processing an mpeg2 elementary stream? [13:35:31 CET] <Mavrik> mpegps.c ? :) [13:36:23 CET] <mrec> just by looking at the stream there seems to be absolutely no logic [13:56:58 CET] <mrec> the confusing part about mpeg2 seems to be if I pass my own frames I get a very slightly juddering picture if the wrong thing gets passed it seems [15:16:53 CET] <Fyr> I have the two video files. I want to create one, with one video following another. is it called concatenation? [15:17:41 CET] <jhg_> hello [15:17:46 CET] <Fyr> hello [15:17:56 CET] <jhg_> =) [15:18:49 CET] <firewated> Fyr: yep [15:18:51 CET] <jhg_> Has anyone played around with AVFoundation's video capture? I am trying to expose the native USB camera's output formats [15:19:42 CET] <jhg_> For example, the Logitech C920 supports MJPEG, H264, and raw video via the v4l2 driver on linux, but only raw modes on OS X. [15:20:45 CET] <jhg_> When I list them with... for (AVCaptureDeviceFormat *format in [device formats]) [15:25:09 CET] <Fyr> firewated, does "-c copy" equal "-c:v copy -c:a copy" ? [15:25:17 CET] <furq> Fyr: yes [15:25:32 CET] <Fyr> cool, I'm growing up. [15:25:34 CET] <furq> and -c:s copy if you have subtitle streams [15:26:19 CET] <Fyr> thanks [15:28:41 CET] <DHE> if I copy mpegts source to mpegts output and copy all codecs, the stream metadata (ie. lauguage information on audio tracks) is copied with it automatically. but if I change "-f mpegts" to "-f hls" that metadata is lost and I end up with the wrong audio playing [15:43:37 CET] <Mavrik> DHE, sounds like a bug [15:44:13 CET] <Eiken_> anyone know why bright pixels become red when encoding from 16bit files to quicktime? [15:46:06 CET] <Eiken_> most probably because values bigger than 1 [15:47:06 CET] <Eiken_> anyone know what filter to use to clamp input values to 1? [15:51:17 CET] <durandal_170> lut [15:52:58 CET] <Eiken_> hmm i just want values above 1 to be 1 [15:53:48 CET] <Eiken_> ahh yeah i read that [15:53:51 CET] <Eiken_> with clip [15:53:56 CET] <Eiken_> but cant put it togheter [16:12:25 CET] <Amitari> Is there any way to extract all frames in a video clip to PNG, and then reassemble them into a video again, at the same frame rate? [16:12:52 CET] <Amitari> The resulting file should be encoded losslessly, I'll reencode it afterwards anyway. [16:15:53 CET] <furq> Amitari: https://www.ffmpeg.org/ffmpeg-formats.html#image2-1 and https://www.ffmpeg.org/ffmpeg-formats.html#image2-2 [16:16:44 CET] <Amitari> Thanks! [16:36:21 CET] <Fyr> guys, is it possible to run something like that: [16:36:21 CET] <Fyr> ffmpeg -i input.mp4 -crf 28 28.mp4 -crf 20 20.mp4 -crf 16 16.mp4 [16:36:21 CET] <Fyr> ? [16:36:58 CET] <DHE> umm. yes. I'd recommend a codec specification first [16:37:14 CET] <DHE> ffmpeg -i input.mp4 -c:v libx264 -crf 28 28.mp4 -c:v libx264 -crf 20 20.mp4 ... [16:39:52 CET] <Fyr> DHE, what if the codec specification is missing? [16:40:04 CET] <DHE> it'll use the default... in my system that's mpeg2 [16:40:10 CET] <Fyr> I want to set all the parameters, but different CRF for different files. [16:40:17 CET] <Fyr> ='( [16:41:00 CET] <ootje> soo.. This one file I encoded in After Effects as H264+AAC in MOV, if I do <ffmpeg -i file.mov file.mp4> and reopen that in AE, it loses 1 or 2 frames at the start... but only with libx264, not if i do -c:v mpeg4... if I take that .mp4 and transcode to huffyuv or mpeg4 it opens fine in AE (all frames). lovely. any takers on that? :P (probably more of an AE issue) [16:42:40 CET] <furq> Fyr: the default codecs for mp4 should be x264 and aac [16:43:03 CET] <furq> you will need to specify any non-default parameters for every output file though [16:43:11 CET] <Fyr> ok, thanks [16:43:12 CET] <Fyr> q [16:43:18 CET] <DHE> ah yes, codec defaults will vary by format [16:46:36 CET] <kepstin> Fyr: it's always best to not rely on the defaults, but specify a specific codec if you want a specific codec. [16:47:35 CET] <furq> i would be surprised if the default codecs for mp4 change any time soon, if ever [16:47:40 CET] <furq> but that is good advice in general [16:47:52 CET] <furq> certainly don't depend on things like the default crf being 23 [16:48:24 CET] <ibrezac> Hi, is there a way to remove embedded Closed Caption (cea-708) from an mp4 using ffmpeg? [16:56:19 CET] <Amitari> Alright, I've extracted all the images, and removed those I don't want, but now I can't reassemble it. [16:56:47 CET] <Amitari> http://pastebin.com/iKyCDkNQ [16:57:57 CET] <Fyr> Amitari, have you tried '%01d.png' or '%03d.png'? [16:58:08 CET] <Amitari> No, I didn't. [16:58:09 CET] <Amitari> Lemme try. [16:58:30 CET] <Amitari> Nope, same result. [16:58:56 CET] <firewated> what are the filenames of the images? [16:59:32 CET] <Amitari> The first one is named "26040.png" and the last one is named "28689.png". [17:00:12 CET] <firewated> maybe %05d.png then [17:00:40 CET] <Amitari> Same result. [17:01:20 CET] <sfan5> try a glob pattern [17:01:26 CET] <sfan5> https://trac.ffmpeg.org/wiki/Create%20a%20video%20slideshow%20from%20images… [17:01:28 CET] <firewated> think it needs to start from 00001 etc [17:01:51 CET] <Amitari> Oh, I'll try just renaming the files. [17:02:03 CET] <firewated> or you can try the glob first [17:03:26 CET] <Amitari> Well, I actually tried an asterisk at first before writing here, but that didn't work either. [17:04:06 CET] <firewated> think you need to specify you're using glob too [17:04:45 CET] <Amitari> There! [17:05:16 CET] <Amitari> Anyway to make it encode losslessly? [17:05:16 CET] <firewated> are the frames in the correct order? [17:05:19 CET] <Amitari> Yes, they are. [17:05:30 CET] <sfan5> -crf 0 [17:05:35 CET] <Amitari> Thanks! [17:05:54 CET] <Amitari> Where should I place that option in the command? [17:06:13 CET] <furq> -q:v 0 for lossless [17:06:24 CET] <sfan5> anywhere basically [17:06:29 CET] <Eiken_> anyone know to clamp input values so they are not out of range? i cant figure it out [17:06:35 CET] <sfan5> before the -i might or might not work [17:06:40 CET] <furq> and put it after -i and before the output file [17:07:05 CET] <furq> also use -start_number 26040 [17:07:18 CET] <furq> oh nvm you already fixed that [17:07:35 CET] <furq> well now you know anyway [17:07:45 CET] <Amitari> It doesn't work! [17:07:55 CET] <sfan5> pastebin! [17:08:06 CET] <furq> but yeah -crf 0 is only lossless for 8-bit [17:08:15 CET] <furq> -q:v 0 is always lossless [17:08:20 CET] <Amitari> http://pastebin.com/4RZ1jV8G [17:08:27 CET] <sfan5> i doubt ffmpeg is going to convert png to >8-bit video [17:08:38 CET] <furq> it probably makes no difference in this case but why would i miss an opportunity for pedantry [17:08:48 CET] <sfan5> Amitari: -q:v 0 [17:09:00 CET] <furq> also it goes after the input filename [17:09:12 CET] <Amitari> http://pastebin.com/UdhuhMv7 [17:09:33 CET] <furq> ^ [17:10:04 CET] <Amitari> So, what should I do? [17:10:13 CET] <sfan5> put it after the -i [17:10:16 CET] <furq> 16:09:00 ( furq) also it goes after the input filename [17:10:29 CET] <firewated> ffmpeg -framerate 50 -pattern_type glob -i '*.png' -q:v 0 out.mkv [17:10:40 CET] <kepstin> sfan5: it depends on whether you have an 8- or 10-bit x264 library, input source doesn't matter. [17:11:06 CET] <sfan5> oh right [17:11:12 CET] <Amitari> There we go! [17:13:02 CET] <Amitari> Great! [17:13:22 CET] <Amitari> In case you're wondering, I was losslessly extracting a clip from an animated TV-show. [17:13:29 CET] <Amitari> A cutaway gag. [17:13:32 CET] <Amitari> Frame-perfect. [17:13:42 CET] <Amitari> The sound was extracted and encoded in FLAC, timed by frame. [17:14:19 CET] <firewated> why did you need to extract the frames as pngs? [17:14:28 CET] <sfan5> sounds like a lot of work [17:14:46 CET] <furq> i'd better not have just helped you make a reaction gif [17:14:58 CET] <furq> is there blood on my hands now [17:18:50 CET] <Fyr> is there a comparison between FFMPEG AAC and other AAC encoders? [17:19:16 CET] <furq> no useful ones that i've seen [17:19:36 CET] <furq> but then there aren't any for fdk either [17:19:56 CET] <Fyr> furq, for fdk there's Hydrogen Audio tests. [17:20:06 CET] <furq> i've not seen any HA tests which include fdk [17:20:11 CET] <Fyr> they have done many comparison tests. [17:20:12 CET] <furq> the latest one i saw only had qaac [17:21:01 CET] <furq> oh there's one from 2011 with fdk [17:21:15 CET] <furq> i doubt that's still relevant though [17:21:31 CET] <JEEB> not like fdk has changed much if at all [17:21:34 CET] <JEEB> mostly bugfixes [17:21:50 CET] <JEEB> but yes, in 2011 the libavcodec AAC encoder was completely different :) [17:21:51 CET] <Fyr> ok, if I perform comparison, can I add it to the Wiki? [17:22:20 CET] <furq> oh [17:22:21 CET] <Amitari> firewated: I wanted to do it losslessly, duh! [17:22:26 CET] <JEEB> (I remember when the AAC encoder at least got to the level where there were clearly audible [hurting ears] artifacts) [17:22:29 CET] <furq> it's actually fhg, not fdk [17:22:34 CET] <furq> idk if those are substantially different [17:22:47 CET] <Amitari> furq: It's not a reaction gif, it's something completely different. [17:22:59 CET] <Amitari> Well, not too different, but I just extracted a cutaway gay. [17:23:04 CET] <furq> i guess i'm still going to heaven then [17:23:06 CET] <Amitari> https://www.youtube.com/watch?v=0VR8WgYyG28 [17:23:25 CET] <firewated> Amitari: if you just want to cut out a clip from a video you can do it losslessly without converting to png [17:23:26 CET] <JEEB> supposedly fraunhofer has some extra modes additionally compared to the one in android (fdk-aac), but in reality I would say that there would be little difference [17:23:46 CET] <Amitari> Amitari, Didn't know that, my brain just went to this directly. [17:23:59 CET] <Amitari> I wanted to do it at just the right frame too. [17:24:14 CET] <furq> http://listening-tests.hydrogenaud.io/igorc/aac-96-a/nonblocked_means.png [17:24:17 CET] <furq> that's nice to know anyway [17:24:27 CET] <firewated> you can do that also, just specify a start time and end time [17:24:31 CET] <furq> CVBR and TVBR are qaac if it's not clear [17:24:41 CET] <Amitari> Sure, but there was no way for me to know the right frames that way. [17:24:48 CET] <Amitari> VLC doesn't show what frame you are on. :( [17:25:23 CET] <furq> Fyr: [17:25:27 CET] <Fyr> ? [17:25:27 CET] <furq> Fyr: it's a wiki, you can do what you want [17:25:32 CET] <Fyr> ok [17:25:47 CET] <firewated> i see, well if you wanted ones that do, i can recommend mpc-hc and mpv [17:27:51 CET] <furq> Fyr: are you actually planning on doing a proper multi-participant abx test with fancy graphs that i can link to on irc [17:27:54 CET] <furq> that would be much appreciated [17:28:22 CET] <Fyr> link where? [17:28:33 CET] <furq> in here probably [17:28:42 CET] <Fyr> I'm good at creating plots. [17:28:59 CET] <furq> http://listening-test.coresv.net/s/scores_by_tracks_en.png [17:29:02 CET] <furq> i've had a lot of mileage out of that one [17:29:06 CET] <Fyr> ok, I'll perform the tests and make pretyy good-looking plots. [17:29:50 CET] <furq> i would suggest a 128k test since that's what people actually use, but i suspect you'd end up with too many 5s [17:30:19 CET] <Fyr> audio is function. there exist pretty developed function analysis. [17:30:31 CET] <Fyr> like PSNR or RMS [17:34:09 CET] <Eiken_> lutyuv=y=val <- what should I add to clip val at 1 ? [17:34:15 CET] <Fyr> is there a ffmpeg distributed with libfdk_aac and libfaac? I don't really want to recompile the source. [17:34:35 CET] <sfan5> there isn't because it breaks the license [17:34:41 CET] <furq> no there isn't [17:38:32 CET] <furq> http://listening-test.coresv.net/img2/ffaac_fdk_compare_en6.png [17:38:36 CET] <furq> looks like someone beat you to it [17:38:56 CET] <furq> that's two months old and only one participant though [17:41:41 CET] <Fyr> furq, give me the link to the page. [17:41:48 CET] <Fyr> the image says nothing. [17:41:54 CET] <furq> https://hydrogenaud.io/index.php/topic,111085.0.html [17:44:06 CET] <Fyr> too sad [17:44:23 CET] <Fyr> I expected more from FFMPEG AAC. [17:44:50 CET] <furq> i wouldn't put too much stock into one guy doing an ABX test by himself [17:44:59 CET] <Eiken_> i cant find any examples on how to use clip() with lutyuv :( [17:47:06 CET] <kepstin> well, unlike vo-aacenc, the ffmpeg aac encoder quality is actually useful - and unlike fdk_aac, it's actually redistributable when enabled in ffmpeg. [17:47:12 CET] <kepstin> so mostly a win overall, imo [17:47:18 CET] <zeryx> is there a way to concat images into a video using a concat file? [17:47:24 CET] <zeryx> It seems like my flags might be incorrect [17:47:25 CET] <furq> those scores seem suspiciously low in general [17:48:03 CET] <kepstin> zeryx: you probably want to use the 'image2' demuxer, which ... creates a video stream from a series of images. [17:48:41 CET] <zeryx> ffmpeg -threads 3 -framerate 15.0 -f concat -i inputFile.txt output.mkv -y [17:48:59 CET] <zeryx> using the image2 demuxer now, however that input does not parse, complains about framerate not being a valid option [17:49:47 CET] <zeryx> imageFile is essentially a .concat file used to concat videos together [17:49:48 CET] <Fyr> is there a roadmap for FFMPEG? [17:50:17 CET] <Fyr> maybe they will fix some things with their AAC. [17:50:39 CET] <Fyr> and add multithreaded FLAC conversion. ='( [17:51:49 CET] <zeryx> interesting, if I remove the framerate option it creates the video [17:52:11 CET] <kepstin> well, '-framerate' isn't an option supported by the concat demuxer [17:52:23 CET] <kepstin> I dunno how to get it to pass options to the underlying demuxers used for each file [17:52:33 CET] <zeryx> I'll try with -fps [17:52:57 CET] <kepstin> what's your source? do you just have a directory full of individual images? [17:53:18 CET] <zeryx> yes, potentially mutliple directories [17:53:22 CET] <kepstin> if so, you should be using the image2 demuxer with a pattern or glob, rather than concat with a list file, imo. [17:53:42 CET] <_Timon> hi guys, quick question http://i.imgur.com/SeXObmO.png [17:53:42 CET] <zeryx> yeah it won't be that easy, I'm encapsulating the filename pattern matching with the conat fil [17:53:55 CET] <zeryx> because the filenames will vary dramatically [17:53:58 CET] <_Timon> clearly my audio device's name is only displayed half [17:54:14 CET] <_Timon> How can I get the actual name [17:54:38 CET] <kepstin> zeryx: you can't rename the files? [17:55:14 CET] <kepstin> I don't see any way to pass options to the underlying demuxers with the concat demuxer, so if you want to set the framerate you'll have to use the 'setpts' video filter, probably. [17:55:40 CET] <zeryx> kepstin, the regular concat demuxer allows the -fps option [17:55:45 CET] <zeryx> I think [17:56:41 CET] <kepstin> zeryx: you mean -r as an input option? there is no -fps option [17:57:03 CET] <kepstin> hmm, that might work - it ignores the input timestamps and generates new ones assuming constant fps [17:57:18 CET] <kepstin> should be the same effect as a setpts video filter, in this case. [18:00:10 CET] <_Timon> Anyone? [18:02:48 CET] <zeryx> kepstin, what would the command for that look like? [18:02:54 CET] <zeryx> -r -fps 15.0 ? [18:03:01 CET] <zeryx> (not sure what -r is) [18:03:11 CET] <kepstin> ffmpeg -r 15.0 -f concat -i inputFile.txt output.mkv [18:03:22 CET] <zeryx> ahh [18:03:23 CET] <zeryx> kk [18:03:27 CET] <zeryx> I'll try that and see how it works1 [18:03:54 CET] <kepstin> -r is one of the options to set framerate, it does different things when used as an input vs. output option [18:04:11 CET] <kepstin> and it's different from '-framerate', which is a demuxer avoption only supported by some demuxers [18:04:22 CET] <kepstin> and '-fps' isn't an option at all, dunno where you got that from [18:05:27 CET] <kepstin> -r as an input option should only be used in special cases like this, because it ignores the framerate from the input file and rewrites it, which will cause audio desyncs if your source is an actual video [18:05:33 CET] <kepstin> but it'll do what you want here, i think. [18:06:25 CET] <zeryx> rad [18:07:33 CET] <kepstin> (if you use -r as an output option it's just a shortcut for inserting an 'fps' video filter) [18:19:34 CET] <_Timon> ok... -i video="viddevice":audio="audiodevice" works but -i video="viddevice" -i audio="audiodevice" doesnt [18:19:38 CET] <_Timon> makes sense [18:25:47 CET] <Eiken_> think ill give up soon, this is crazy [18:35:41 CET] <Eiken_> input exr files with values 0 to n. clamping n at 1. anyone know how? the prores get red artifacts in areas where n > 1 when expected result is white [18:39:36 CET] <Rutuja1> hi! i still have this problem: relocation R_X86_64_32 against `ff_a64_muxer' can not be used when making a shared object; recompile with -fPIC while compiling vlc [18:39:36 CET] <Rutuja1> how do i issue make with the -fPIC command? [18:45:38 CET] <Wildefyr> where do I place nvEncodeAPI.h in the ffmpeg directory for it to recognize it? [18:51:48 CET] <BtbN> nowhere [18:52:01 CET] <BtbN> it has to be in your compilers include path. [19:25:16 CET] <davidmichaelkarr> I've run into an issue where a video originally generated from "Record My Desktop", and then edited on OpenShot, is fuzzy. Someone on the openshot forum said this is because RMD encodes ogg-vorbis incorrectly, so they use ffmpeg to convert ogv to mp4. I'm trying to determine the best way to do this. One simple search found one answer on: [19:25:16 CET] <davidmichaelkarr> http://askubuntu.com/questions/12182/how-can-i-convert-an-ogv-file-to-mp4 . Is this the best approach? [19:27:23 CET] <BtbN> you aren't going to enhance the video quality by re-encoding it another time, it will only ever get worse. [19:28:36 CET] <davidmichaelkarr> BtbN: Great. Any other ideas? Is there an alternative to RMD that encodes in higher quality? [19:28:46 CET] <BtbN> No idea what RMD even is. [19:29:40 CET] <kepstin> you can of course capture the desktop directly with ffmpeg on command line and encode to whatever format you like [19:30:18 CET] <davidmichaelkarr> BtbN: "RecordMyDesktop" [19:31:41 CET] <furq> looks like it's been dead since 2008 [19:32:43 CET] <furq> davidmichaelkarr: https://trac.ffmpeg.org/wiki/Capture/Desktop [19:33:24 CET] <furq> i'm not sure if you can record a particular window with x11grab [19:37:19 CET] <t4nk309> I am trying to convert an MOVto MP4 with this command ffmpeg -i IMG_5770.MOV -c copy out.mp4 but the mp4 just freezes and plays the audio. Is my ffmpeg command ok? [19:38:03 CET] <JEEB> command by itself is ok [19:38:17 CET] <JEEB> what are you using to play back? [19:41:18 CET] <t4nk309> <video controls preload="auto" width="568" height="320"> [19:41:33 CET] <t4nk309> <source src='user_vids/<% v %>.mp4' type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"' /> [19:44:05 CET] <Fyr> guys, I want to render text on video (create video rom scratch). how do I do that? My guess is to render a black box, then to render text on the video. [19:44:14 CET] <Fyr> how to create the black box? [19:45:38 CET] <davidmichaelkarr> If I have to install ffmpeg on ubuntu, I see that there are two choices in the "Linux Packages" section on the ffmpeg site. I'm not sure which I should be using. [19:46:19 CET] <Fyr> I would recommend official packages. [19:46:43 CET] <furq> depends which ubuntu version [19:46:47 CET] <Fyr> if you're on openSUSE, I would advise you to install the Zeranoe binaries. [19:46:56 CET] <furq> if it's not 15.x then there is no ffmpeg package [19:53:15 CET] <derekprestegard> ffmpeg always whines about timestamps being unset when I mux elementary HEVC streams created by x265 to mp4 - should I care? [20:05:19 CET] <gnimbus> hello everyone [20:11:44 CET] <DHE> derekprestegard: did you set a framerate for the elementary stream? [20:13:20 CET] <gnimbus> I'm trying to add metadata to a MPEG-2 video in Python. I *think* I need to create a transport stream with 'mpegts' first, yes? Do I need to make one per frame or per time point? Sorry, n00b here... [20:14:11 CET] <davidmichaelkarr> furq: I'm on 14.04. So you're saying that ffmpeg isn't even supported on 14.04? [20:15:01 CET] <furq> there's no ffmpeg package in the 14.04 repos because of the whole libav mess [20:15:11 CET] <furq> the static build should work fine [20:15:22 CET] <furq> http://johnvansickle.com/ffmpeg/ [20:15:55 CET] <furq> i guess the PPA on the ffmpeg site should work too if you're willing to use a PPA [20:19:16 CET] <derekprestegard> DHE: do you mean when I encoded it using x265 or do you mean when I loaded it into ffmpeg? [20:19:36 CET] <DHE> derekprestegard: the latter [20:20:01 CET] <derekprestegard> I did this ffmpeg -y -i $output.h265 -an -c:v copy -r 60 -movflags faststart $output.mp4 [20:20:18 CET] <derekprestegard> should I add -r 60 before -i ? [20:20:33 CET] <DHE> more like move the -r to before the -i [20:20:37 CET] <derekprestegard> I see [20:20:48 CET] <DHE> ffmpeg -y -r 60 -i source.h264 .... [20:21:08 CET] <DHE> not that it hurts to specify the framerate both times, it's just not required [20:24:36 CET] <derekprestegard> DHE: that totally did it. Thank you! [21:27:54 CET] <Wildefyr> Hey, trying to get nvenc encoding to work, but ffmpeg gives me the error: "Failed loading CUDA library" even though libcuda is on my system (/usr/lib/libcuda), why can't ffmpeg see it? [21:30:03 CET] <Wildefyr> ldconfig -p | grep cuda also shows the library [21:34:13 CET] <DHE> Wildefyr: could be other reasons, such as the library failing to initialize. for example are the nvidia modules loaded? (you need 2) [21:34:33 CET] <Wildefyr> I have nvidia and nvidia_modeset loaded [21:34:57 CET] <Wildefyr> is there a specific cuda module? [21:35:08 CET] <iive> try `ldd ffmpeg` see if there are any missing libraries [21:35:40 CET] <iive> if cude is loaded at runtime, try ldd on the libcuda [21:36:04 CET] <Wildefyr> https://p.iotek.org/x11 [21:36:31 CET] <DHE> I believe the is a "nvidia-uvm" module needed for CUDA operation [21:36:48 CET] <DHE> the only other suggestion would be to use strace to see what ffmpeg/nvenc actually does and where it aborts [21:38:26 CET] <Wildefyr> well, that module loaded succesfully but still the same error [21:39:32 CET] <Mista_D> Is there a specific interlaced encoding mode for MPEG2VIDEO and X264? It seems to double bitrate vs progressive scan (-qscale:v 2). [21:43:10 CET] <odinsbane> I made a video from some jpg files to an mp4 with the default settings, then I cropped and scaled it to 800x450. It is about 122M for 3 minutes. So I changed it to a webm using CRF of 44. The file is now 42M for 3 minutes but there is very significant degredation to the video. [21:44:31 CET] <odinsbane> http://imgur.com/IaE61Qz one the left is the compressed version and on the left is the origin. The quality is ok for what I want, but 44M still seems large for 3 minutes. [21:44:48 CET] <odinsbane> Sorry the one on the right is the original. [21:45:24 CET] <DHE> you might want to framestep and see if there's noise in the video or something like that. a denoise filter might do wonders for compression [21:45:41 CET] <DHE> an encoder can waste a lot of bits preserving the noise [21:46:24 CET] <odinsbane> It is a time lapse movie with quite a bit of jiggle. [21:46:54 CET] <furq> if it's a timelapse of driving then it's probably not very compressible [21:47:07 CET] <Wildefyr> okay, well it's reporting it can't find /usr/lib/libcuda.so, but there is a symbolic link there to the library (libcuda.so.361.28 on my system) [21:48:11 CET] <furq> odinsbane: you could maybe try a slower preset (-preset slow/slower/veryslow) but i'm not sure if it'll make much difference [21:48:39 CET] <Wildefyr> here's the strace for reference https://p.iotek.org/i6a [21:48:48 CET] <DHE> yeah time lapse isn't going to compress too well. too much changing between frames [21:48:55 CET] <DHE> especially if the camera itself is moving [21:49:37 CET] <odinsbane> Cool, Ill check out the noise. The camera is definitely moving, it is on a bicycle helmet. [21:50:22 CET] <DHE> time lapse is going to severely affect bitrate, yeah. not much similarity between frames [21:50:46 CET] <odinsbane> Makes sense, I was just trying to make sure I wasn't doing something silly. [21:51:16 CET] <odinsbane> Ill try a time lapse tomorrow with a stationary camera and see if I get it to a reasonable size. [21:51:47 CET] <krakonos> Hi! I just tried creating timelapse video with ffmpeg, found some docs on it and decided to use image2. The problem is, I can't use nanosecond precision (as I want images generated from a script, and it seems too fiddly and uportable to use it). I came up with a solution to multiply timestamps by a constant, and add filter to modify timestamps. Unfortunately, this approach takes a bit more time AND ffmepg [21:51:53 CET] <krakonos> eats about 9GB of RAM, which is way too wasteful (I'm generating 1080p video from ~400 images). Any ideas on how to do this without nanosecond timestamps? [21:52:37 CET] <krakonos> I must say that I don't like the timestamp fiddling anyway, and wanted to use ffconcat instead, but ffmpeg seems to dislike non-integer durations anyway. [23:49:15 CET] <redalert> Hello, can someone confirm me if -progress "URL" has a bug? I tried it and FFmpeg doesn't post Data every 1 second as it says, but if i try -progress test.txt , it writes every second [00:00:00 CET] --- Thu Mar 3 2016

1 0

ffmpeg-devel.log.20160301
by burek 02 Mar '16

02 Mar '16

[00:00:54 CET] <durandal_1707> how much it would take for you * 10 [00:05:56 CET] <rcombs> wm4: probably not; most of the work is already done [00:14:15 CET] <nevcairiel> jamrial_: i dont think vlc 2.2 works with ffmpeg 3.0 either way due to API issues [00:14:20 CET] <T4ng10r> can someone help me? how to debug internals of libavformat? [00:14:52 CET] <nevcairiel> jamrial_: ie. it refuses to work with avutil > 55 already before that change [00:15:17 CET] <durandal_1707> T4ng10r: what exactly? [00:15:32 CET] <rcombs> wm4: basically I just need to add something to send a "extradata changed" packet side-data when that happens [00:15:36 CET] <nevcairiel> jamrial_: sorry, >= 55 [00:15:56 CET] <rcombs> and if the decoders don't handle that, well, sucks [00:16:02 CET] <T4ng10r> I would like to see what is goin on in eval_function and func_pts [00:16:23 CET] <T4ng10r> i start with cgdb ffmpeg from inside ffmpeg folder where I run configure and make [00:16:30 CET] <T4ng10r> but no symbols were loaded [00:16:53 CET] <durandal_1707> stripped binary? [00:16:57 CET] <drv> use ffmpeg_g [00:17:34 CET] <T4ng10r> objdump --debuging on libavformat.a shows that symbols are available [00:18:06 CET] <T4ng10r> @drv: wow - that it [00:18:12 CET] <T4ng10r> thank you [00:24:07 CET] <T4ng10r> wrr, still not satisfayin results [00:24:29 CET] <T4ng10r> ffmpeg_g runs, but no breakpoint set in vf_drawtext.c is triggered [00:24:51 CET] <T4ng10r> even when I go manualy to this file and set breakpoint [00:29:21 CET] <T4ng10r> doeasn't matter if I run from ffmpeg_g or ffmpeg - in both situations breakpoints on vf_drawtext arent triggered [00:29:24 CET] <T4ng10r> Linux, cgdb [00:29:47 CET] <JEEB> check if the libraries have debug symbols [00:29:56 CET] <JEEB> they should, but just in case [00:30:43 CET] <T4ng10r> objdum --debugiing libavformat.a show that they are [00:31:33 CET] <T4ng10r> how do you debug on linux? [00:31:43 CET] <T4ng10r> maybe my approach is faulty [00:32:49 CET] <JEEB> I just use standard gdb and then the binary name [00:32:50 CET] <T4ng10r> or perhapse cgdb ffmpeg uses system libraries without debug symbols [00:33:02 CET] <T4ng10r> and from where are you doing it? [00:33:03 CET] <JEEB> and yes, if you have an ffmpeg in path [00:33:15 CET] <JEEB> you will probably want to do gdb ./ffmpeg_g or so [00:33:24 CET] <JEEB> it should tell if it loaded symbols or not [00:34:07 CET] <T4ng10r> i'll try [00:34:08 CET] <jkqxz> "gdb --args ./ffmpeg_g -foo -bar -ffmpeg -args", "break function_name", "run". [00:34:41 CET] <JEEB> I usually just "gdb binary" and then "run parameters more of them" when inside [00:34:42 CET] <T4ng10r> still nothign [00:34:52 CET] <JEEB> so it says it couldn't load symbols? [00:35:10 CET] <T4ng10r> cgdb -x debug_cmd ffmpeg_g [00:35:11 CET] <JEEB> also please enlighten me what is cgdb :D [00:35:23 CET] <T4ng10r> its wraper on gdb with course [00:35:39 CET] <llogan> I assumed it was Canadian. [00:35:43 CET] <JEEB> :D [00:35:46 CET] <T4ng10r> it shows code in upper part of screan and gdb in lower [00:36:15 CET] <JEEB> try with plain gdb first, pastebin what it tells you when you load the binary [00:36:44 CET] <T4ng10r> with ffmpeg_g I see that breakpoint set on vf_drawtext.c functions name are successful [00:36:48 CET] <T4ng10r> no pedning [00:36:51 CET] <T4ng10r> ok, pure gdb [00:38:43 CET] <T4ng10r> http://pastebin.com/fWVipmjc [00:38:49 CET] <T4ng10r> pure gdb [00:39:18 CET] <JEEB> ok, so it does indeed read symbols, that's great [00:39:29 CET] <JEEB> otherwise it would say that symbols weren't found [00:39:43 CET] <T4ng10r> yes [00:39:58 CET] <jkqxz> None of your breakpoints were ever hit, because it didn't get that far? [00:39:59 CET] <ubitux> [Parsed_drawtext_0 @ 0x1ff35c0] Both text and text file provided. Please provide only one [00:40:04 CET] <T4ng10r> there's possibility that it didn't reached point of breakpoints [00:40:50 CET] <ubitux> which is a pretty strange error actually [00:41:19 CET] <T4ng10r> and you were all right [00:41:24 CET] <jkqxz> Look in libavfilter/vf_drawtext.c. The failure message is near the top of the init() function. [00:41:36 CET] <T4ng10r> I'm testing pts:gmtime and time value [00:42:00 CET] <T4ng10r> I've set breakpoint in init (vf_drawtext:596) and it hits [00:42:12 CET] <T4ng10r> thank you all for you help and patience [00:42:30 CET] <T4ng10r> now I can go sleep :) [00:43:02 CET] <ubitux> why the hell is textfile defined here [00:43:25 CET] <T4ng10r> to much \ [00:43:52 CET] <T4ng10r> i tried to escape time in place of delta parameter - and whole parsing is fooled [00:44:07 CET] <ubitux> oh, it's hitting the escaping madness, ok [01:20:55 CET] <atomnuker> michaelni: with 4096x4096 images ffv1 tries to allocate a packet over 2Gb per frame (which fails) [01:21:05 CET] <atomnuker> that doesn't seem right [01:21:15 CET] <atomnuker> test it with one of the images from here: http://svs.gsfc.nasa.gov/vis/a000000/a004100/a004128/frames/4096x4096_1x1_3… [01:28:53 CET] <cone-912> ffmpeg 03Ganesh Ajjanagadde 07master:7dabc78ce13e: lavu/rational: add more info regarding floor(x+0.5) usage [01:32:34 CET] <rcombs> that seems like a lot [01:33:12 CET] <Compn> bonus points to the dev who tests all encoders with those images ^^^^^^^^ [01:34:18 CET] <atomnuker> well, doesn't seem like a lot, ffv1 does this to calculate it: AV_INPUT_BUFFER_MIN_SIZE + avctx->width*avctx->height*3LL*4; [01:35:35 CET] <atomnuker> (shouldn't that 4 be just the number of planes?) [01:39:19 CET] <michaelni> atomnuker, -level 4 should use less than 2gb, also it could be chnaged to realloc if it runs out [01:40:18 CET] <michaelni> 4 should be planes, yes i think so too [01:41:06 CET] <michaelni> or rather channels, as in 1 plane packed RGBA64 [01:49:42 CET] <atomnuker> michaelni: yeah, that works [01:49:53 CET] <atomnuker> that enables version 2, right? [01:49:59 CET] <atomnuker> how to enable version 3 though? [01:57:30 CET] <atomnuker> nevermind, ffprobe reports the files as version 4 [02:20:22 CET] <cone-912> ffmpeg 03Andrew Shulgin 07master:1c7e2cf9d339: avformat/rtpdec_h264: Ignore invalid sprop-parameter-sets missing PPS [04:51:00 CET] <Timothy_Gu> 8%... that's quite a lot [06:13:28 CET] <Zeranoe> I'm dropping Windows XP support. This will allow Intel QSV support to be included in the Windows builds. I will provided periodic Windows XP builds, but the daily builds will not support it. [09:37:13 CET] <j-b> 'moroning [10:13:46 CET] <durandal_1707> j-b: why I get connection reset by peer? [10:13:57 CET] <j-b> durandal_1707: doing what? :D [10:14:05 CET] <ismail> j-b: git clone [10:14:16 CET] <durandal_1707> git pull [10:14:18 CET] <ismail> interminently having that [10:14:37 CET] <j-b> I'd guess because we're getting hammered once again by chinese IPs? [10:14:41 CET] <j-b> I'll ask our master. [10:36:42 CET] <cone-750> ffmpeg 03Clément BSsch 07master:090621d7cece: lavfi: add bench and abench filters [11:04:23 CET] <ubitux> http://pastie.org/pastes/10743129/text ./ffmpeg -nostats -f lavfi -i testsrc2=s=uhd2160:d=1 -vf format=yuv420p,bench=start,format=rgba,bench=stop -f null - [11:04:30 CET] <ubitux> before and after aarch64 optims [11:09:40 CET] <rcombs> Zeranoe: good call [11:10:18 CET] <nevcairiel> Zeranoe: qsv can be build with XP support, one just has to build the dispatcher library appropriately [11:10:32 CET] <nevcairiel> (although QSV itself wont work on XP, but thats beside the point) [11:12:58 CET] <rcombs> nevcairiel: btw, re: https://trac.ffmpeg.org/ticket/4828 afaik AudioToolbox falls under the GPL system library linking exception [11:13:43 CET] <rcombs> (much like VideoToolbox) [11:14:53 CET] <nevcairiel> i suppose [11:15:04 CET] <nevcairiel> anyone ever tried to debug mov seeking? [11:15:35 CET] <nevcairiel> i can see it finding a key frame index at a specific timestamp, but the first packet i get from the demuxer after the seek is 2 packets after said keyframe [11:24:09 CET] <nevcairiel> nvm i was confused, looks like the index just marks a keyframe which isnt actually one [11:31:05 CET] <rcombs> quality [11:42:09 CET] <nevcairiel> apparently it happens because there is a "rap group", whatever that is [11:42:24 CET] Action: nevcairiel digs up specs [11:42:50 CET] <wm4> better than "boy band" I guess [11:47:22 CET] <nevcairiel> supposedly its a way to mark random access points [11:50:34 CET] <nevcairiel> but there just isnt any at this point in the file [11:50:36 CET] <nevcairiel> oh well [11:57:18 CET] <rcombs> ISOBMFF BoyBandDescriptor [12:24:55 CET] <JEEB> lol [12:27:09 CET] <rcombs> the drummer is stored in a `rngo` atom [12:27:41 CET] <JEEB> now you just have to find a brand for it ;) [12:28:35 CET] <rcombs> hmm, "Apple Records" produces confusion with the tech giant [12:39:38 CET] <cone-750> ffmpeg 03Rostislav Pehlivanov 07master:6061b78e8374: vc2enc: remove redundant put_padding() and use skip_put_bytes() instead [12:49:32 CET] <kurosu_> anybody having a problem with latest msys2 vim package (7.4.1415-2) ? [12:49:57 CET] <kurosu_> Doesn't start but no error, and when running strace, complains about missing acl_free in msys-2.0.dll [13:12:20 CET] <Daemon404> kurosu_, yes, same here [13:13:50 CET] <kurosu_> Daemon404, while I have your attention, no issue running gdb? Haven't been able to insert breakpoints in months [13:14:23 CET] <Daemon404> i dont use gdb on windows much, but i can try and check [13:14:38 CET] <Daemon404> that sounds pretty broken though... [13:16:38 CET] <Daemon404> Type "apropos word" to search for commands related to "word". [13:16:38 CET] <Daemon404> Traceback (most recent call last): File "<string>", line 3, in <module> [13:16:38 CET] <Daemon404> ImportError: No module named libstdcxx.v6.printers [13:16:38 CET] <Daemon404> /etc/gdbinit:6: Error in sourced command file: [13:16:38 CET] <Daemon404> Error while executing Python code. [13:16:41 CET] <Daemon404> not off to a good start [13:16:47 CET] <kurosu_> only think deviating from a normal install is maybe that I allow loading .gdbinit in the current path, and that I set those breakpoints from there [13:16:56 CET] <kurosu_> only pthread and iconv msys2 dlls are linked by the ffmpeg binary, so shouldn't be the source of the issue [13:17:06 CET] <kurosu_> getting something like: [13:17:07 CET] <kurosu_> Cannot insert breakpoint 2. [13:17:07 CET] <kurosu_> Cannot access memory at address 0x140df4e30 [13:17:07 CET] <kurosu_> Cannot insert breakpoint 1. [13:17:07 CET] <kurosu_> Cannot access memory at address 0x140e06840 [13:17:42 CET] <kurosu_> from script of the shape: [13:17:49 CET] <kurosu_> file ffmpeg_g.exe [13:17:49 CET] <kurosu_> b main [13:17:49 CET] <kurosu_> b ff_butterflies_float_avx [13:17:56 CET] <kurosu_> r <parameters> [13:19:17 CET] <Daemon404> just installing gcc [13:20:05 CET] <kurosu_> (btw I think I edited out /etc/gdbinit to not list this anyway) [13:22:48 CET] <Daemon404> i can set bp on a test program (didnt try ffmpeg) [13:22:55 CET] <Daemon404> but i get other wierd issues [13:23:21 CET] <Daemon404> ah... wrong gdb [13:23:25 CET] <Daemon404> i forgot msys2 has 3. [13:24:03 CET] <kurosu_> invoking /mingw64/bin/gdb configured for x86_64-w64-mingw32 afaik [13:24:46 CET] <kurosu_> but I do have the msys/gdb package installed [13:26:29 CET] <Daemon404> i686 works fine [13:26:33 CET] <Daemon404> with vanilla install [13:26:44 CET] <Daemon404> and a simple test prog [13:27:40 CET] <kurosu_> huh [13:27:56 CET] <kurosu_> installing mingw-w64-i686-gdb in addition solved the issue [13:28:08 CET] <Daemon404> O_o [13:28:14 CET] <kurosu_> I mean msys/* [13:28:28 CET] <kurosu_> mingw64/mingw-w64-x86_64-gdb wasn't enough apparently [13:28:35 CET] <Daemon404> that seems... odd [13:28:45 CET] <nevcairiel> i feel so much happier not even bothering to use the msys2 provided toolchains [13:29:05 CET] <kurosu_> gcc used should be x86_64-w64-mingw32 [13:29:57 CET] <Daemon404> i've never used the msys2 toolchains/gdb myself either [13:29:57 CET] <kurosu_> nevcairiel, maybe the effort is worth it, but it's sad to actually have to go through those lengths - and I don't think I have been atypical [13:30:05 CET] <Daemon404> that too. [13:30:24 CET] <nevcairiel> well the msys2 people are a bit peculiar when it comes to their toolchain [13:30:45 CET] <nevcairiel> for some reason they insist to use mingw trunk, which is more often broken than not, and then apply a boatload of questionable patches on top [13:31:06 CET] <nevcairiel> so since i use my toolchain to produce production builds that get distributed to users, i prefer to make my own [13:31:10 CET] <Daemon404> their gcc was from svn too wasnt it [13:31:46 CET] <kurosu_> I wouldn't have time, patience nor knowledge to roll a few of those on my own [13:31:58 CET] <Daemon404> most people download nevcairiel's [13:32:00 CET] <Daemon404> afaik [13:32:00 CET] <nevcairiel> i have most of that scripted by now [13:32:18 CET] <kurosu_> at some point, it may be simpler for what I do to just use a linux vm [13:32:19 CET] <nevcairiel> but yes, plenty people use mine [13:32:39 CET] <kurosu_> "just" (btw) [13:32:41 CET] <ismail> nevcairiel: mingw trunk is fine now actually but msys people apply lots of weird patches [13:32:46 CET] <nevcairiel> (https://files.1f0.de/mingw/ btw) [13:34:46 CET] <kurosu_> nevcairiel, how do you "install" it (probably will wait for next such issue)? Unpack in <msys2 install path>/mingw64 ? [13:34:51 CET] <nevcairiel> i only apply one patch to my mingw to fix a bug that caused builds to randomly fail [13:35:05 CET] <nevcairiel> kurosu_: just unpack somewhere where the shell finds it [13:35:34 CET] <nevcairiel> could be any path if you update your PATH appropriately [13:35:40 CET] <kurosu_> k, could be /opt or whatever I may like then [13:35:44 CET] <kurosu_> ah yes, exactly [13:36:09 CET] <kurosu_> I never know if they stopped hardcoding rpath or whatever it is/was called [13:36:56 CET] <ismail> we should really upstream that patch, we (openSUSE) apply it too and apparently its written by one of our contributors [13:38:08 CET] <nevcairiel> which patch, the mkstemp one? [13:38:11 CET] <nevcairiel> i wrote that myself =p [13:38:27 CET] <nevcairiel> after a day of debugging [13:38:29 CET] <nevcairiel> was ratehr painful [13:38:58 CET] <ismail> https://sourceforge.net/p/mingw-w64/bugs/471/ [13:39:12 CET] <ismail> well surely you are not Jan :P [13:39:30 CET] <nevcairiel> no, but unfortunately I only found that ticket after hours of debugging [13:39:38 CET] <nevcairiel> since before I had no clue mkstemp was breaking everything [13:39:42 CET] <ismail> ah hehe, anyhow let me me mail upstream. [13:40:30 CET] <nevcairiel> The change was included in some huge diff dump as linked in that ticket, no clue how mingw works, but such dump seems unlikely to be very welcome [13:41:07 CET] <ismail> I'll post the one line fix: https://build.opensuse.org/package/view_file/windows:mingw:win64/mingw64-ru… [13:43:48 CET] <ismail> http://article.gmane.org/gmane.comp.gnu.mingw.w64.general/12244 [13:50:47 CET] <kurosu_> nevcairiel, you don't have a gdb in that file, though ? Meaning I still have to install it from msys2 ? [13:51:18 CET] <nevcairiel> hm i have gdb from soemwhere else [13:51:22 CET] <nevcairiel> i forget where its from [13:51:57 CET] <nevcairiel> but yeah this is compiler only [13:54:42 CET] <Daemon404> its like msys1 days all over again [13:54:50 CET] <Daemon404> lemme find some random zips of stuff i need, etc [13:55:03 CET] <nevcairiel> its not my fault msys2 does weird things =p [13:55:04 CET] <kurosu_> I'll still stick to gdb, even if I prefer msvc' debugger, because of yasm & co [13:55:14 CET] <nevcairiel> i really never use gdb [13:55:28 CET] <Daemon404> has gdb support now doesnt it [13:55:31 CET] <Daemon404> or is that only for ARM [13:55:40 CET] <nevcairiel> works for everything that gdb works on [13:55:48 CET] <nevcairiel> although setting it up is a bit finnicky [13:56:23 CET] <Daemon404> interesting [13:56:50 CET] <Daemon404> i figured it would be, since it uses teh gdb server stuff, iirc [13:57:07 CET] <wm4> I didn't know we had coded_side_data [14:02:04 CET] <nevcairiel> stream global side data? it was added a while ago [14:03:31 CET] <wm4> isn't that in AVStream [14:03:35 CET] <wm4> too many side datas [14:05:05 CET] <nevcairiel> stream and codec each have one [14:05:11 CET] <nevcairiel> i suppose codec is filled by decoders? [14:05:17 CET] <nevcairiel> or maybe encoders [14:05:20 CET] <nevcairiel> so confusing [14:13:24 CET] <ubitux> https://trac.opensubtitles.org/projects/opensubtitles/wiki/HashSourceCodes weird hashing... [14:15:06 CET] <nevcairiel> it just sums all bytes into a 64-bit value and lets it overflow? =p [14:15:15 CET] <Daemon404> seems like NIH gone wrong [14:15:44 CET] <nevcairiel> ah it only does that for the first and last chunk of the file [14:16:05 CET] <wm4> yeah that's dumb [14:16:06 CET] <ubitux> afaict it's sth like size+sum(content[:0xffff+1])+sum(content[:-0xffff]) [14:16:34 CET] <wm4> there's even a LISP impl [14:17:08 CET] <ubitux> wth is foxpro [14:17:09 CET] <nevcairiel> i have not even heard of "Vala" or what that is [14:17:12 CET] <nevcairiel> looks Cish [14:17:22 CET] <wm4> Vala is Gnome's C# clone [14:17:27 CET] <wm4> it's based on gobject [14:18:11 CET] <nevcairiel> FoxPro i know, its one of microsofts decades old things related to one of their database projects [14:18:29 CET] <nevcairiel> its like implementing this in SQL =PO [14:47:48 CET] <cone-750> ffmpeg 03Rostislav Pehlivanov 07master:41985d40c652: vc2enc: simplify slice cost caching [14:47:49 CET] <cone-750> ffmpeg 03Rostislav Pehlivanov 07master:7bcc57ad9938: vc2enc: fix packet underallocation and minimum bitrate with interlacing [14:48:44 CET] <wm4> I didn't realize ff_init_buffer_info accesses the "current" packet [14:48:47 CET] <wm4> how does this even make sense [14:49:03 CET] <wm4> oh well [14:53:54 CET] <kierank> nevcairiel: haven't heard FoxPro in years [14:54:04 CET] <nevcairiel> its been dead for ever [14:54:08 CET] <nevcairiel> its from DOS times [14:54:08 CET] <nevcairiel> :D [15:01:05 CET] <Daemon404> we learned foxpro in elementary school.... [15:04:55 CET] <kurosu_> nevcairiel, what's the default for your compiler? -m32? [15:05:33 CET] <nevcairiel> there is two in there, different binaries for x86 and x86_64, need to use a cross prefix for x86_64 builds [15:06:20 CET] <kurosu_> ok... [15:06:23 CET] <nevcairiel> ie x86_64-w64-mingw32-gcc [15:06:46 CET] <ubitux> hey btw, if you're looking for GSoC subject; https://trac.ffmpeg.org/ticket/4364 [15:07:48 CET] <ubitux> since we have a lot of advanced color filters it makes sense [15:08:06 CET] <ubitux> and there is enough to get busy if you're not relying on a library [15:09:07 CET] <Daemon404> raw camera files are a rabbit hole... [15:09:11 CET] <Daemon404> full of insanity [15:12:11 CET] <ubitux> Daemon404: yeah but this one has a standard [15:13:02 CET] <ubitux> it's actually the format used by chdk (alt firmware for canons) [15:13:41 CET] <Daemon404> ubitux, oic [15:14:41 CET] <RiCON> https://en.wikipedia.org/wiki/OpenRAW#Limitation reminded me of https://xkcd.com/927/ [15:24:17 CET] <Daemon404> BBB, fyi i will be in NYC again in may [15:24:26 CET] <Daemon404> if youre up for dinner/drinkd [15:25:04 CET] <BBB> yes absolutely [15:37:15 CET] <mateo`> wm4, JEEB: "bad" news, I will have to reintroduce a public function the set the java vm, the google c++ jni wrapper is only "available" since android 4.4 (i just found out by testing on a bunch of old devices) [15:45:25 CET] <JEEB> yeah, I noticed that but I was anyways thinking of limiting any apps to 4.4+ [15:45:38 CET] <JEEB> esp. due to the fact that libmpv's opengl renderer requires opengl es 3 :) [15:45:52 CET] <JEEB> of course I understand that you might want to support older ones, too [15:46:13 CET] <mateo`> I can still dlsym JNI_GetCreatedJavaVMs before android 4.4, but i have no idea what will be the result of calling this function from exec without a vm initialized (as opposed to an app env) [15:47:37 CET] <mateo`> btw I can keep the dlopen/dlsym code and give an api to set manually the vm, what do you think ? [15:47:57 CET] <JEEB> sounds good [15:58:35 CET] <atomnuker> Can I realloc a buffer allocated by ff_alloc_packet2? [15:59:27 CET] <Daemon404> i somehow doubt this is kosher [15:59:44 CET] <nevcairiel> i believe so, however since a realloc can result in a memcpy, wouldnt it be wiser to adjust the original estimate [16:00:28 CET] <atomnuker> well, since it would solve like 99% of all vc2 stability problems it might be a good idea to _not_ put any bits before I know the cost of everything [16:01:00 CET] <iive> just make ff_realloc function, if there isn't already one [16:01:27 CET] <iive> i think that manual memalign after malloc is still a thing, so... [16:01:54 CET] <Daemon404> i thought memalign hack was removed [16:02:41 CET] <Daemon404> apparently not [16:02:47 CET] <Daemon404> im not sure what systems would even need it [16:03:10 CET] <Daemon404> (it's all sorts of illegal/wrong) [16:03:40 CET] <nevcairiel> its not that wrong really, thats practically how many of such OS implementations also work [16:04:00 CET] <Daemon404> i meant by the c spec :P [16:04:07 CET] <Daemon404> casting pointers to long and doign arith on them [16:04:08 CET] <Daemon404> yum yum [16:04:20 CET] <nevcairiel> they even invented intptr_t for that purpose [16:04:25 CET] <Daemon404> we use long [16:04:31 CET] <nevcairiel> well easy enough to fix that [16:04:54 CET] <Daemon404> good luck finding a system that doesnt have aligned malloc to test on [16:05:03 CET] <nevcairiel> easy enough to fake that [16:05:04 CET] <nevcairiel> :D [16:05:10 CET] <Daemon404> not my point :P [16:05:23 CET] <Daemon404> as far as im concerned, it's now a theoretical problem [16:05:48 CET] <nevcairiel> its slightly odd though, the long thing worked all this time, but long is 32-bit on windows [16:05:58 CET] <nevcairiel> and people apparently still use the hack today [16:06:52 CET] <Daemon404> because we dont care [16:06:53 CET] <Daemon404> diff = ((~(long)ptr)&(ALIGN - 1)) + 1; [16:06:56 CET] <Daemon404> we calculate the diff [16:07:29 CET] <nevcairiel> still potentially casts a 64-bit ptr value to 32-bit long [16:07:54 CET] <Daemon404> i dont even know what the behavior is there [16:10:50 CET] <jamrial> maybe it should be changed to intptr_t just in case then? [16:11:32 CET] <kurosu_> using nevcairiel's gcc and tdm-gcc's gdb, still can't have valid breakpoints: it either fails (albeit at the correct line) to set them in the same fashion, or they are never triggered [16:11:47 CET] <Daemon404> that is super weird [16:11:55 CET] <jamrial> or just make configure fail (or silently disable) memalign hack if _aligned_realloc() is available [16:12:18 CET] <kurosu_> yes, and the issue is I don't think I did anything but install or reinstall various packages [16:13:33 CET] <kurosu_> full msys2 reinstall on the way... [16:14:03 CET] <Daemon404> :/ [16:15:12 CET] <durandal_1707> kierank: doing gradient thing for showvolume? [16:15:24 CET] <kierank> maybe later in the month [16:15:39 CET] <kierank> got to get lavfi into our pipeline first [16:16:11 CET] <Daemon404> RIP kierank [16:16:32 CET] <durandal_1707> haven't using smptehdbars? [16:16:44 CET] <kierank> different codebase [16:18:28 CET] <durandal_1707> there's no vs filter that could do this [16:21:15 CET] <kierank> VS? [16:21:31 CET] <Daemon404> vapoursynth [16:27:06 CET] <Timothy_Gu> hmm AudioToolbox [16:27:31 CET] <Timothy_Gu> next step: DirectShow audio decoder (with support for dshow DCA decoders) [16:29:46 CET] <kurosu_> well, same thing... [16:41:36 CET] <kurosu_> nice, just deleted my ffmpeg folder - see you next year I guess [16:44:01 CET] <kierank> what happened? [16:45:52 CET] <kierank> a real shame, osprey made good cards [16:47:21 CET] <Daemon404> kierank, he was reinstalling msys2 [16:47:25 CET] <Daemon404> no drama. [16:47:48 CET] <kierank> lol [17:01:49 CET] <wm4> sigh, trying to port my decode API patches to ffmpeg [17:02:24 CET] <wm4> but for some reason I get an obscure fate failure due to VSYNC_VFR dropping the last frame... [17:03:05 CET] <wm4> and it involves things like float timestamp calculations (???) [17:03:14 CET] <Daemon404> wut [17:03:29 CET] <durandal_1707> where? [17:04:20 CET] <wm4> durandal_1707: do_video_out [17:05:17 CET] <durandal_1707> I can't grep I'm outside [17:19:34 CET] <wm4> int64_t ts = av_rescale_q(decoded_frame->pts = best_effort_timestamp, ist->st->time_base, AV_TIME_BASE_Q); [17:19:37 CET] <wm4> such nice code [17:20:10 CET] <wm4> gotta save 1 line of code in a 250 loc function [17:21:02 CET] <J_Darnley> is that an assignment in a function call? [17:21:43 CET] <wm4> yes, isn't it concise and elegant [17:22:50 CET] <kierank> wow [17:24:45 CET] <fritsch> until you need to debug it ... [17:26:51 CET] <wm4> ok, I see my problem... apparently, the flush packet carries a dts, which is then output by the flushed AVFrame as pkt_dts, which is then used by the ffmpeg.c timestamp logic [17:27:11 CET] <wm4> maybe [17:28:45 CET] <wm4> ah yes [17:29:04 CET] <wm4> ffmpeg.c explicitly sets a dts on every video input AVPacket, even if it's a flush packet [17:29:10 CET] <wm4> is this a bug or feature [17:29:37 CET] <wm4> avconv does not do this [17:45:25 CET] <ubitux> omfg apple [17:45:32 CET] <ubitux> die please die ffs [17:45:54 CET] <ubitux> SO. apple asynchronous design summary [17:46:17 CET] <ubitux> you have a custom callback for when the frame is decoded, and a function to push data [17:46:20 CET] <ubitux> so far, everything is OK [17:46:42 CET] <ubitux> but now, you want to end shit, and decide that you need to make sure that callback won't be called again [17:47:14 CET] <ubitux> smartass like you are, you decide to call VTDecompressionSessionFinishDelayedFrames() to make sure the internal queue gets pushed to the user [17:47:34 CET] <ubitux> then because you don't trust apple one second, you also call VTDecompressionSessionWaitForAsynchronousFrames() [17:47:53 CET] <ubitux> now you are happy and pretty sure your callback won't be called again [17:48:12 CET] <ubitux> so you start trashing your internal queue which is filled in your callback etc [17:48:15 CET] <ubitux> AND THEN [17:48:20 CET] <ubitux> THIS SHIT FUCKING CALL YOUR CALLBACK AGAIN [17:48:22 CET] <ubitux> SEVERAL TIMES [17:48:24 CET] <ubitux> FFS [17:48:32 CET] <ubitux> I'M GONNA KILL THESE FUCKING STUPID DESIGNERS [17:48:40 CET] Action: J_Darnley is reminded of libavfilter [17:49:06 CET] <ubitux> i'm going to need to add a fucking counter [17:49:11 CET] <mateo`> :D [17:49:12 CET] <ubitux> with a lock and shit [17:49:32 CET] <ubitux> because these idiots can think for a second with their little brain [17:49:35 CET] <nevcairiel> isnt apple shit generally reference counted [17:49:56 CET] <ubitux> it's not the problem [17:50:41 CET] <mateo`> reference counted and in a dispatch queue [17:55:13 CET] <cone-865> ffmpeg 03Clément BSsch 07master:f1148390d7ed: sws/aarch64: add {nv12,nv21,yuv420p,yuv422p}_to_{argb,rgba,abgr,rgba}_neon [18:17:13 CET] <michaelni> "MXF Demuxer Improvements" has no mentor (thardin told me he doesnt have time this year) [19:17:25 CET] <wm4> Timothy_Gu: what are DCA decoders? [19:17:33 CET] <wm4> mateo`: that seems unfortunate, but whatever [19:23:23 CET] <kierank> wm4: dts coeherent acoustics [19:23:31 CET] <kierank> the official name afaik [19:23:38 CET] <kierank> like ac-3 to dolby digital [19:23:45 CET] <nevcairiel> why would anyone want that, we have a fully compatible decoder now =p [19:35:21 CET] <BBB> wm4: sweet! [19:43:54 CET] <mateo`> wm4: nice patchset :) [19:54:38 CET] <cone-817> ffmpeg 03Wan-Teh Chang 07master:4845f0720e38: Move the |die| member of FrameThreadContext to PerThreadContext. [20:02:09 CET] <hush> hi all, I am trying to improve the test coverage of the lib. Please review my first patch http://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/190530.html [20:02:37 CET] <crot^^^> hello All, I have an issue where I cannot consume a udp stream. Running ffprobe -v trace udp://237.1.1.0:1234 ends in nothing more than [udp @ 0x28c1940] end receive buffer size reported is 131072 [20:04:12 CET] <crot^^^> does anyone have any pointers to run this down I have verified via wireshark that the join is going out and the content is present after the command is ran. [20:12:10 CET] <Timothy_Gu> nevcairiel: yeah right, forgot about that :) [20:34:19 CET] <durandal_1707> nobody picking my hard project :D [20:35:24 CET] <Timothy_Gu> durandal_1707: didn't michaelni have a patch using motion est from avcodec? [20:35:57 CET] <wm4> durandal_1707: make it sound more interesting and friendly [20:36:03 CET] <durandal_1707> that one, from mpeg? [20:36:37 CET] <Timothy_Gu> durandal_1707: think so [20:37:01 CET] <Timothy_Gu> also what should the motion estimation filter do? print out motion vectors? [20:37:15 CET] <durandal_1707> Isnt it far from ideal? [20:37:44 CET] <durandal_1707> calculate mv and store in frame side data [20:37:53 CET] <Timothy_Gu> oh ok [20:38:01 CET] <Timothy_Gu> make your description more speicific then [20:56:45 CET] <cone-817> ffmpeg 03Mark Harris 07master:c3bb6166dd05: sdp: fix opus sprop-stereo fmtp syntax [21:02:33 CET] <iive> durandal_1707: michael had 100fps filter in maillist, then BBB flamed him and michael gave it up. Good work BBB :P [21:02:57 CET] <BBB> huh? [21:03:09 CET] <BBB> I almost never flame [21:03:12 CET] <BBB> only very sparingly [21:03:59 CET] <durandal_1707> iive: proper what is to have 3 separate filters [21:04:10 CET] <durandal_1707> *way [21:05:20 CET] <iive> durandal_1707: why 3? [21:06:39 CET] <durandal_1707> motion: estimation, interpolation, compensation [21:06:40 CET] <wm4> iive: the approach wasn't very good, it just pulled libavcodec implementation details into libavutil [21:08:06 CET] <iive> wm4: maybe it wasn't, maybe it was. The thing is we don't have such filter. [21:08:50 CET] <wm4> I'm talking about the motion est. API [21:09:11 CET] <iive> well, BBB wanted the API... [21:09:12 CET] <wm4> (which could have been used to write such a filter) [21:09:32 CET] <wm4> having such an API is a good idea (probably), hooking it to libavcodec internals is not [21:10:16 CET] <BBB> so, wait, am I being trolled now or do you agree with my complaints about that patch? [21:10:23 CET] <iive> durandal_1707: i don't think the interpolation merits its own filter. [21:11:02 CET] <iive> BBB: I do not agree with your complaints about that patch. What you demanded was academics. And of course, nobody is interested in doing it. [21:11:10 CET] <iive> engineers want to make stuff that works. [21:11:23 CET] <wm4> iive: that's completely wrong [21:11:26 CET] <BBB> Im slightly smiling now, I always heard the inverse complaint [21:11:36 CET] <BBB> (academics just want to make stuff work, engineers are tedious about details) [21:11:45 CET] <BBB> but ok thanks for explaining [21:11:47 CET] <fritsch> mmh [21:11:57 CET] <fritsch> academics want a proof of concept [21:12:00 CET] <fritsch> and are done after that [21:12:11 CET] <fritsch> no matter it works in the field [21:12:14 CET] <wm4> iive: if we create an unmaintainable mess, it will be hard to fix, improve, or optimize it later [21:12:34 CET] <wm4> iive: I know it goes against the ffmpeg doctrine, but look at libswscale what happens [21:12:38 CET] <durandal_1707> iive: several filters that are good are better than one big that sucks [21:13:09 CET] <durandal_1707> avscale and nascale [21:13:50 CET] <Timothy_Gu> what does the 100fps filter do any way [21:13:57 CET] <iive> wm4: at least we have a WORKING mess. [21:14:07 CET] <Timothy_Gu> iive: I disagree [21:14:28 CET] <wm4> iive: yeah, no user complaints about libswscale at all! [21:14:47 CET] <Timothy_Gu> mess is worse than nothing [21:14:59 CET] <iive> everybody complains about everything. [21:15:38 CET] <wm4> iive: that's an overly general statement completely ignoring the problem, but ok [21:16:07 CET] <iive> what goes around, comes around. [21:16:34 CET] <Shiz> engineering is not "makings things work", it's designing proper systems [21:17:28 CET] <iive> Shiz: it's literally, making stuff works. even when you don't know the math and tune things by trail and error [21:17:42 CET] <Shiz> uhm no [21:18:35 CET] <iive> Shiz: i'll give you an example. Have you heard of EmDriver? [21:18:37 CET] <BBB> well look [21:18:43 CET] <BBB> iive: I understand your point of view [21:18:45 CET] <Shiz> kindly lookup the definition of an engineer [21:18:45 CET] <iive> ops... [21:18:46 CET] <BBB> iive: but I disagree with it [21:18:50 CET] <BBB> iive: ok? [21:18:53 CET] <Shiz> i don't care whatever shoddy thing you're going to bring up [21:21:09 CET] <iive> Shiz: it's simple. engineers make stuff that works. academics figure out how and why stuff works. [21:21:30 CET] <Shiz> not gonna repeat myself [21:21:36 CET] <Shiz> engineers build systems, not hacks [21:21:43 CET] <Timothy_Gu> iive: FFmpeg isn't a hackathon product, which just needs to work. FFmpeg was back in 2003, but it is not any more. Now it needs to be stable, well-designed, and well-thought out. [21:21:45 CET] <JEEB> engineers have standards and rules [21:22:12 CET] <Timothy_Gu> and case in point: the 100fps filter raises a bunch of objections against its methodology [21:22:27 CET] <BBB> oops [21:22:31 CET] <BBB> crap, wrong button [21:22:38 CET] <JEEB> like, I build systems but I would never, ever consider myself an "engineer". [21:23:09 CET] <iive> Timothy_Gu: first time when you make something, it is always a hack. You need to see it work and grow in order to figure out its initial flaws. [21:23:11 CET] <Timothy_Gu> if you are at a hackathon, you need ot finish it. We are not. We don't have a deadline. We do have an obligation to make sure that it fits future needs. [21:24:04 CET] <Timothy_Gu> iive: Yes. THing is, these initial flaws have already been repeated elsewhere, and some people are just trying to prevent it from getting into FFmpeg again. [21:24:17 CET] <iive> if you want to make something perfect from the first iteration, then you will never make anything good enough. [21:24:40 CET] <iive> Timothy_Gu: And that's why we don't have 100fps filter. Thank you very much. [21:24:44 CET] <JEEB> you can't make things perfect, just that you can make something that doesn't raise general objections [21:24:59 CET] <JEEB> although I know, bikesheds et al [21:25:04 CET] <Shiz> @iive Timothy_Gu: first time when you make something, it is always a hack. [21:25:08 CET] <Shiz> i hope you never become an architect [21:25:34 CET] <Timothy_Gu> We don't want to make it perfect. We want to make it as good as it can be. If there are objections, we fix them. If there are conflicting objections, we fidn the "middle ground." [21:25:37 CET] <iive> Shiz: well, you start with bike sheds first :P [21:26:56 CET] <JEEB> also nothing wrong with hacks when you are trying out designs. think of scaled-down models of an actual work [21:27:11 CET] <iive> Shiz: however architecturing anything non-standard involves a lot of simulations. [21:27:37 CET] <Shiz> of course [21:27:37 CET] <JEEB> but those things don't automagically become the house, they are not necessarily anywhere close getting merged [21:27:42 CET] <Shiz> what jeeb said [21:28:40 CET] <iive> and that's why we don't have 100fps filter. [21:30:06 CET] <Timothy_Gu> ^^ that's a good thing [21:30:06 CET] <JEEB> yes, that's why we don't have a 100fps filter that could have accessed some internals in a rather not-necessarily-nice way (I don't remember the patch itself, but I will go by the hearsay that it used avcodec internals from outside in a hacky way) [21:30:27 CET] <JEEB> that it didn't become something merge'able is of course unfortunate [21:31:07 CET] <iive> let me say something and I'll drop the matter. [21:31:08 CET] <wm4> <iive> Shiz: however architecturing anything non-standard involves a lot of simulations. <- yeah, but not building it [21:31:16 CET] <wm4> they didn't make rocket tests by blowing up test pilots [21:31:26 CET] <Shiz> well actually [21:31:30 CET] <wm4> except sometimes [21:32:04 CET] <iive> Cleaning up and having perfectly designed API is LIbAV goal. It's one of the reason for their demise. Don't make the same mistake here. [21:32:18 CET] <wm4> the stupidest thing I've ever heard today [21:32:18 CET] <JEEB> nothing is perfect [21:32:20 CET] <JEEB> also wow [21:32:46 CET] <iive> it's ok to don't have perfectly designed stuff. especially if it stays internal. [21:32:46 CET] <wm4> could write an essay how stupid it is, but I'd rather do something else now [21:33:19 CET] <Timothy_Gu> iive: it's ok to don't have perfectly designed stuff. especially if it stays internal. <-- yes. the 100fps patch makes bad apis public [21:33:39 CET] <iive> Timothy_Gu: not the first patch. BBB request an API... [21:33:50 CET] <iive> to make it clean separation. [21:33:57 CET] <iive> and then he didn't like the API. [21:35:18 CET] <Timothy_Gu> Am I correct in saying that you like the first patch better? [21:36:29 CET] <rcombs> what are people mad about this time [21:36:47 CET] <iive> Timothy_Gu: let's say I had no issues with the first patch. [21:37:43 CET] <iive> especially since we already have some filters that literally reuse codecs code. e.g. mcdeint [21:38:04 CET] <michaelni> btw, i do plan to return to the mcfps code and improve it and get rid of the Motion est libavcodec dependancy. but too long todo list and other things where more interresting or more important ... [21:39:33 CET] <Timothy_Gu> iive: and that's your first mistake. It is simply wrong to say that it is technically acceptable to use a private API from another library. [21:40:56 CET] <iive> Timothy_Gu: technically it is. Academically, it's blasphemy. [21:42:57 CET] <iive> michaelni: it might also be good idea to port the h264 hexagonal search into ffmpeg. iirc [21:46:25 CET] <TD-Linux> BBB, what was your experience with frame-parallel and ffvp9? is it not worth using ever? [21:47:07 CET] <BBB> the bitstream feature? [21:47:19 CET] <BBB> like, vpxenc frame-parallel=1/0? [21:47:21 CET] <TD-Linux> BBB, yes. [21:47:32 CET] <BBB> hm & it depends on your goals (/me hides) [21:47:46 CET] <BBB> youll lose about 1-2% in coding efficiency, from what I recall [21:47:55 CET] <BBB> depending on the target bitrate and so on [21:48:03 CET] <TD-Linux> BBB, I had read earlier that ffvp9 doesn't gain additional parallelism from it [21:48:05 CET] <BBB> if your goal is to decode with ffmpeg, I wouldnt use it [21:48:22 CET] <BBB> if your goal is to decode with vpxdec/libvpx, maybe its worthwhile [21:48:42 CET] <BBB> I think vpxenc nowadays enables both tiling as well as frame-parallel, both cost 1-2%, I think having both isnt worth it [21:48:53 CET] <BBB> one should be enough, and Id probably use tiling over frame-parallel [21:49:10 CET] <BBB> but ffmpeg doesnt need them, it is always parallel even without either feature in the bitstream [21:49:20 CET] <TD-Linux> OK. I'm asking because I'm considering removing it as an encode possibility [21:49:58 CET] <BBB> youll get minor speedups from it, but not much [21:50:18 CET] <BBB> (over the already-existing frame parallelism) [22:26:41 CET] <user123> what are the parameters required to scale a video using scale_video.c program given in example of documentation [22:30:40 CET] <user123> please help with this [22:33:27 CET] <BBB> user123: #ffmpeg please [22:53:18 CET] <wm4> I wonder if there should be something between ffmpeg CLI help, and ffmpeg internal development [22:53:24 CET] <wm4> like the api mailing list [22:58:11 CET] <jkqxz> For help developing thing using the libav* APIs? It could be called libav-devel, perhaps... [23:01:30 CET] <ubitux> for some reason my fate instance --disable-everything seems to get stalled all the time [23:03:51 CET] <ubitux> the fuck is going on [23:05:23 CET] <ubitux> api-seek-test is stalled [23:05:57 CET] <ubitux> #0 0x00007ffff7bc93e8 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 [23:05:59 CET] <ubitux> #1 0x0000000000461e32 in udp_read (h=0x7107c0, buf=0x721220 "", size=65536) at src/libavformat/udp.c:923 [23:06:01 CET] <ubitux> here ^ [23:06:32 CET] <ubitux> ah, looks related to the URL protocol thing? [23:09:51 CET] <jamrial> ubitux: api-seek has failed on that client since it was introduced [23:10:08 CET] <jamrial> maybe the dependecies should be fixed so it doesn't run wiht --disable-everything? [23:10:09 CET] <ubitux> i don't remember having it stall [23:10:27 CET] <jamrial> i mean fail [23:10:31 CET] <jamrial> look at the history [23:10:40 CET] <ubitux> right, but then there is a regression [23:10:47 CET] <ubitux> because now it's blocking all my other fate instance :p [23:10:53 CET] <jamrial> yes, if it stalls now then it's a different issue, but nonetheless, it was never meant to run with --disable-everything [23:11:49 CET] <ubitux> Using network protocols without global network initialization. Please use avformat_network_init(), this will become mandatory later. [23:11:53 CET] <ubitux> erm [23:13:13 CET] <ubitux> bit doesn't help apparently [23:13:40 CET] <ubitux> oh fuck i don't have time for this [23:35:59 CET] <wm4> ubitux: why is a fate test using network? [23:36:46 CET] <ubitux> no idea [23:36:57 CET] <ubitux> the flv is triggering some network madness maybe? [23:37:21 CET] <wm4> shouldn't happen IMO [23:37:54 CET] <ubitux> it's actually in the probing [23:38:34 CET] <ubitux> http://pastie.org/pastes/10744176/text [23:39:47 CET] <ubitux> maybe it's trying to probe with the wrong protocol [23:40:01 CET] <ubitux> like, disable everything disabling file but still keeping network stuff [23:40:11 CET] <wm4> you should use a better paste site [23:40:26 CET] <ubitux> so the first/only protocol available would be udp, it would use that for probing [23:40:35 CET] <wm4> but yeah, sounds like something goes EXTREMELY wrong [23:41:10 CET] <ubitux> maybe i should add --disable-network to --disable-everything [23:41:23 CET] <ubitux> which makes me think that carl might be aware of this [23:42:40 CET] <ubitux> wm4: what's the issue with pastie? [23:43:12 CET] <wm4> look at your paste [23:43:21 CET] <wm4> it's not txt but html, and also corrupts the contents [23:43:31 CET] <J_Darnley> "[email protected]" [23:43:43 CET] <ubitux> wm4: i just miss copy the first '#' [23:43:56 CET] <ubitux> and yeah it's not txt, but doesn't really matter [23:44:15 CET] <ubitux> sprunge is not handy, i often need to pick a specific part, or edit it [23:44:18 CET] <wm4> often enough it does [23:44:34 CET] <wm4> sprunge has a web interface too [23:44:52 CET] <ubitux> ah? [23:44:59 CET] <ubitux> oh, indeed [23:45:02 CET] <ubitux> ok [00:00:00 CET] --- Wed Mar 2 2016

1 0

ffmpeg.log.20160301
by burek 02 Mar '16

02 Mar '16

[00:50:16 CET] <deweydb> looking for some tips about best approach to take. i want to take an input video (9x16 aspect ratio) and apply a "ken burns" effect to it. essentially cropping the video to 16x9 and then panning the crop window from the top to the bottom slowly through the duration of the video. [00:59:09 CET] <J_Darnley> deweydb: see whether the crop filter can use expressions [00:59:45 CET] <llogan> it can [01:02:19 CET] <llogan> like this lame one: "crop=w=iw:h=iw/(ih/iw):x=0:y=t*ih/10" [01:07:39 CET] <mrec> does anyone know the meaning of serial in ffplay? [01:08:23 CET] <llogan> what's the context? [01:08:39 CET] <mrec> struct Frame { ... int serial ... } [01:17:22 CET] <deweydb> llogan: nice [01:18:00 CET] <llogan> deweydb: "h=iw*a" is fewer characters [01:18:28 CET] <deweydb> such obfustication. reading docs to try to be able to read that [01:21:43 CET] <llogan> y=((ih-oh)*t)/5 might be more "useful" to show everything within the duration. where "5" is your duration. there is probably a better way though. [01:22:31 CET] <llogan> i should add more useless parenthesis [01:22:32 CET] <deweydb> is the duration available within the filter complex expression [01:22:39 CET] <deweydb> or do i retrieve that first via other means [01:23:56 CET] <llogan> not in crop, AFAIK. you can script it with ffprobe. [01:24:01 CET] <deweydb> wow just tried this out. man thanks so much! really helped me get started! [01:24:44 CET] <llogan> i'm an arithmetic retard, so doublecheck it [01:25:05 CET] <llogan> for duration see https://trac.ffmpeg.org/wiki/FFprobeTips#Duration [01:26:03 CET] <llogan> assuming your duration comes from another file [01:26:20 CET] <deweydb> yeah, well i need to play around with it a bit anyway, but this definitely gets me started. thanks. [01:26:47 CET] <llogan> it gave me a good distracton from borking work [01:26:52 CET] <llogan> *boring [02:38:52 CET] <snakeryslug> hello. do i use ffprobe to measure the size of a stream? [02:39:11 CET] <snakeryslug> i'm trying to figure it out, but i haven't found anything in ffprobe yet. [02:39:15 CET] <DHE> size? as in duration? it can do that if the stream supports it [02:40:02 CET] <snakeryslug> DHE: sorry i should've been more specific. i'm very ignorant in respect to av data in general so this question might not make sense. how do i find the size on my disk of a stream? [02:40:31 CET] <DHE> as in, only the audio or video? there isn't a reliable method except running through the whole file and counting [02:40:46 CET] <snakeryslug> DHE: i'm sorry, i don't understand. [02:41:01 CET] <snakeryslug> i know that ffmpeg can extract streams from AV files. [02:41:06 CET] <DHE> so a file usually consists of 2 streams: audio and video. maybe more, depending on the context. [02:41:13 CET] <snakeryslug> yep [02:41:32 CET] <DHE> and you want to know how big the audio (or video) would be if extracted? [02:41:38 CET] <snakeryslug> DHE: yes. [02:41:53 CET] <DHE> there is no 100% reliable consistent way other than doing it [02:42:16 CET] <snakeryslug> that is unintuitive to me, but again, I'm not experienced with the details. [02:42:19 CET] <DHE> unless the stream is constant bitrate, in which case it's (duration * bitrate). [02:42:19 CET] <snakeryslug> thanks. [02:42:48 CET] <DHE> some codecs may be used in constant bitrate mode, usually audio. but if the bitrate is variable you'll have to actually measure the whole thing for an accurate answer [02:42:59 CET] <snakeryslug> DHE: so ffprobe only works on steam disk space determination if it's a constant bitrate? [02:43:04 CET] <J_Darnley> I think ffprobe can tell you how much of the existing file is audio or video but it cannot tell you the result of a transformation. [02:43:34 CET] <snakeryslug> J_Darnley: I can't find the command to find the disk size of a stream yet. [02:43:44 CET] <DHE> for some codecs, like AC3, constant bitrate is actually the norm. in that case ffprobe will say something like 384k [02:43:56 CET] <J_Darnley> show frames and then sum the frames for each stream. [02:44:04 CET] <DHE> 384 * duration_in_seconds / 8 [02:44:09 CET] <DHE> = kilobytes [02:44:39 CET] <J_Darnley> When I said "ffprobe can tell you how much" I mean "ffprobe can show you data which you can use" [02:44:42 CET] <snakeryslug> so ffprobe doesn't do those calculations for me? [02:44:48 CET] <snakeryslug> okay [02:45:46 CET] <DHE> it's not a direct metric people are interested in most of the time. bitrates are usually what people are after [02:49:31 CET] <snakeryslug> DHE: i'll have to read more about streamable media. do you recommend literature that touches important points for intermediate programmers? [02:53:37 CET] <J_Darnley> lol [02:53:46 CET] <J_Darnley> why am I surprised that that doesn't work [02:53:58 CET] <J_Darnley> why am I *not* [02:54:30 CET] <J_Darnley> oh well that's just obvious(!) [02:55:05 CET] <snakeryslug> I also can't figure out if my stream is CBR or VBR from ffprobe output. when i search ffprobe --help, there's no occurence of bitrate bit rate or bit-rate. [02:55:12 CET] <J_Darnley> snakeryslug: try -show_entries 'frame=stream_index,pkt_size' and an output format of your choosing [02:56:22 CET] <snakeryslug> the packet sizes are different, so is that VBR? starting to read info about bitrates right now. [02:56:49 CET] <snakeryslug> thank you for finding that command [02:56:55 CET] <J_Darnley> no problem [02:57:37 CET] <J_Darnley> and you clearly don't grep very well: ./ffprobe -h | grep 'bit.\?rate' [02:58:33 CET] <J_Darnley> but I don't think it does what you want [02:58:55 CET] <J_Darnley> yeah, definitely not [02:59:14 CET] <snakeryslug> J_Darnley: maybe windows documentation is different, because i still don't find an instance. [03:00:06 CET] <J_Darnley> if there was a character separating bit and rate it would be an underscore in the option name [03:00:41 CET] <snakeryslug> you're right i need grep. [03:06:28 CET] <snakeryslug> my problem isn't critical. my intuition tells me that the mostly static video stream of my av file (is that what it's usually called?) doesn't take up much disk space, I was just wondering if the opensource tools for av data manipulation and inspection had a quick way of telling me how much space it took up on the file. i know ffmpeg can extract audio from av files and that's certainly one way to do it, but it's not quick. maybe ffmpeg [03:06:28 CET] <snakeryslug> has a dry run option that i haven't looked for yet. thank you for your help! [03:07:37 CET] <snakeryslug> and it sounds like finding the size of a stream in a file isn't a very quick task on a vbr file. [03:11:25 CET] <J_Darnley> If you want to know how large the audio would be is you extracted it then I suggest you do exactly that [03:11:36 CET] <J_Darnley> extract the audio and see how big it is. [03:12:17 CET] <J_Darnley> I thought you wanted to do something else, something fancy [03:12:33 CET] <snakeryslug> J_Darnley: yep. that's what i was gonna do if ffprobe couldn't help me. i'm interested in learning how ffprobe and ffmpeg work, so I'll learn the backends if I can make time. [03:12:47 CET] <J_Darnley> ooh [03:13:02 CET] <J_Darnley> that's a fairly big topic but if you want to, go ahead [03:13:36 CET] <snakeryslug> My intuition tells me that if ffmpeg extracting and copying the audio stream probably has an option that eventually outputs the file size of the stream, I'll look. [03:14:55 CET] <snakeryslug> And in the end, maybe my use case is dumb lol. [03:15:02 CET] <J_Darnley> ffmpeg does print the sum of audio and sum of video streams when its done [03:15:27 CET] <snakeryslug> J_Darnley: i'm looking for an option where it doesn't output the file. [03:15:29 CET] <jas99> hi guys [03:15:38 CET] <J_Darnley> write to /dev/null [03:15:41 CET] <snakeryslug> but i can always just then delete the file. [03:15:44 CET] <J_Darnley> or NUL on windows [03:16:17 CET] <jas99> hey J_Darnley [03:16:24 CET] <jas99> hows it going? [03:16:29 CET] <J_Darnley> meh [03:16:37 CET] <snakeryslug> J_Darnley: DUH! lol. Thanks. [03:16:37 CET] <jas99> :) [03:16:51 CET] <J_Darnley> stuck on tracking down the bug in this piece of assembly [03:17:12 CET] <J_Darnley> I guess I'll post it to the ML in the morning and ask for frash eyes. [03:17:31 CET] <jas99> that helps [03:17:46 CET] <jas99> 2 eyes are better then internet [03:18:21 CET] <jas99> hey quick question if u dont mind [03:18:28 CET] <J_Darnley> sure [03:19:00 CET] <jas99> so for yuv444 x265 [03:19:09 CET] <jas99> and yuv420 [03:19:22 CET] <jas99> can I compile setup to have both [03:19:45 CET] <jas99> ? [03:19:51 CET] <J_Darnley> No ideafor x265 [03:20:03 CET] <jas99> any idea for x264 [03:20:09 CET] <J_Darnley> x264 will have both with a regular build [03:20:15 CET] <J_Darnley> (and 422 and rgb) [03:20:15 CET] <jas99> hmm [03:20:41 CET] <jas99> yeah [03:20:43 CET] <J_Darnley> Is chroma subsampling really a compile time feature for them? [03:20:57 CET] <jas99> seems like it [03:21:12 CET] <jas99> was double chking on irc [03:22:16 CET] <jas99> package from msys2 wont work [03:23:16 CET] <jas99> [libx265 @ 00000000068140e0] 4:2:2 and 4:4:4 support is not fully defined for HE VC yet. Set -strict experimental to encode anyway. Could not open video codec: Error number -40 occurred [03:23:16 CET] <J_Darnley> oh shit, I forgot it used cmake [03:23:29 CET] <jas99> currently getting this [03:23:31 CET] <J_Darnley> I guess I can't check the source [03:23:37 CET] <J_Darnley> RTFE! [03:23:55 CET] <J_Darnley> Set -strict experimental to encode anyway. [03:24:16 CET] <J_Darnley> Literally tells you the solution [03:24:44 CET] <jas99> yeah I am using libav [03:24:56 CET] <jas99> not command line [03:25:07 CET] <J_Darnley> Then set the option! [03:25:19 CET] <jas99> yeah thats what I was gonna ask [03:25:36 CET] <J_Darnley> I think its one of the AVCodecContext options [03:25:54 CET] <jas99> thx man let me find out [03:26:13 CET] <J_Darnley> Otherwise use the AVOption system and "strict" [03:26:50 CET] <jas99> nice will try out both suggestion [03:27:06 CET] <jas99> thx for helping :) [03:27:24 CET] <jas99> you are canadian? [03:27:33 CET] <TD-Linux> yeah, in usual MPEG fashion 4:4:4 also includes a bunch of other random features [03:27:50 CET] <TD-Linux> in fact 4:4:4 has more features than 4:2:2 [03:27:54 CET] <J_Darnley> strict_std_compliance [03:28:53 CET] <J_Darnley> Me? Canadian? No [03:29:02 CET] <jas99> beligum? [03:29:21 CET] <J_Darnley> :) yes (almost) [03:29:29 CET] <jas99> okay in eu [03:30:42 CET] <jas99> belgium did I misspelled it?? :) [03:30:52 CET] <J_Darnley> yes you did [04:54:02 CET] <k_sze[work]> When using encoding with libx264, is there any guarantee that the I-frame (or key frame) is the first *presented* frame of the GOP? [04:56:03 CET] <k_sze[work]> e.g. if I specify a static GOP of 250 (--keyint 250 --min-keyint 250 --scenecut -1), is there any guarantee that seeking to every n * 250th frame is a key frame? [06:43:57 CET] <dave45376> Hi - I was wondering if anyone has any experience in piping content from something like wget to ffmpeg - I'm ideally trying to pipe content from aria2c (seemingly a pretty robust CLI download manager) to ffmpeg since some of the sources I access are slow and using multiple parallel connections doesn't seem to work too well --> this is my example syntax that doesn't work --> http://pastebin.com/iTzqLY1t [06:49:58 CET] <pzich> are you sure the pipe output from Dropbox is working properly? [06:50:41 CET] <pzich> I'd start with a short MP4 and first pipe the output to a file, then pipe that into ffmpeg (making sure that each command is working properly with pipes, and therefore it's a pipe I/O rate issue [06:50:43 CET] <dave45376> sorry guys [06:51:02 CET] <dave45376> I can download the file just fine from dropbox using aria [06:51:37 CET] <pzich> specifically by piping it (e.g. "dropbox url..." > file.mp4), and feed that as a pipe into ffmpeg, serially? [06:51:52 CET] <pzich> this is a debugging step before the parallel pipe [06:52:05 CET] <pzich> do you see an error? what happens besides "doesn't work"? [06:52:58 CET] <pzich> are you sure you can use --split=10 when piping the output? [06:53:32 CET] <dave45376> http://pastebin.com/CArJkGSA [06:53:48 CET] <dave45376> this is a windows shell fyi [06:54:19 CET] <furq> does aria2c even support outputting files to stdout [06:54:30 CET] <pzich> dunno [06:54:33 CET] <furq> https://github.com/tatsuhiro-t/aria2/issues/190 [06:54:36 CET] <furq> it doesn't look like it [06:54:37 CET] <pzich> he does have --file-allocation=none [06:54:43 CET] <furq> that's preallocation [06:54:43 CET] <pzich> welp, there you have it! [06:56:26 CET] <dave45376> should i disable preallocation? [06:56:52 CET] <pzich> you should not pipe [06:57:09 CET] <dave45376> :( [06:57:22 CET] <pzich> at least not with aria2c [06:57:25 CET] <pzich> maybe use curl? [06:57:28 CET] <dave45376> is there some other way to speed up direct http feeds that you are aware of? [06:58:23 CET] <pzich> what do you mean by speed up? get a faster ISP? [06:58:26 CET] <furq> there's also the issue with mp4 files that the moov atom might be at the end, in which case you won't be able to start decoding until the file is complete [06:58:53 CET] <dave45376> perhaps so, but I can simulate the pipe manually, it's just a hassle [06:59:10 CET] <dave45376> i.e., i can download the file with aria then, simultaneously, I can run ffmpeg on it with "-re" [06:59:14 CET] <dave45376> which seems to work fine [06:59:36 CET] <pzich> I'm not sure it's guaranteed to download in order. [06:59:52 CET] <pzich> and if it catches up to where you've downloaded to, it may just shit the bed [06:59:56 CET] <dave45376> perhaps so, but to the credit of aria, they give options to try to force it to do that [07:00:23 CET] <pzich> can it write its output linearly to a FIFO? [07:00:26 CET] <dave45376> that's true, but if i set "-re" it limits it to 1x whereas I would typically be downloading at 3-4x and the http client inside of ffmpeg would get like 0.3x [07:00:50 CET] <dave45376> "--stream-piece-selector=inorder" is the parameter to download it in order [07:00:52 CET] <pzich> depends on the bitrate [07:01:05 CET] <dave45376> yeah, you're totally right [07:01:13 CET] <dave45376> doing the process manually could break it [07:01:29 CET] <furq> a fifo could work but probably not on windows [07:01:31 CET] <dave45376> but i think you're starting to appreciate the inefficiencies of the native http client [07:01:41 CET] <dave45376> as far as i can tell at least [07:02:43 CET] <furq> actually a fifo probably won't work with --split [07:02:58 CET] <furq> not that it matters if you're not on *nix [07:03:56 CET] <furq> also if you're using --split=10 then that's not really ffmpeg's fault if it's 10x slower [07:04:02 CET] <furq> blame dropbox [07:05:51 CET] <dave45376> perhaps so [07:06:08 CET] <dave45376> but it would be nice if the internal http client had a little bit of multiconnection ability [07:52:51 CET] <isoboy> testing [07:53:03 CET] <isoboy> Hi everyone [07:54:00 CET] Last message repeated 1 time(s). [07:54:32 CET] Action: isoboy wonders if he is connected [07:54:47 CET] <relaxed> yes you are, do you have a question? [07:55:01 CET] <isoboy> hi there! [07:55:03 CET] <isoboy> Yes I do. [07:55:32 CET] <isoboy> I am trying to set up my webcam to stream from computer 1 to computer 2 on a local network [07:55:40 CET] <isoboy> http://pastebin.com/qzjfTgyM [07:57:10 CET] <isoboy> The commands worked when I tested them locally on one computer, but when I direct the stream to computer2 it failed with error message [07:58:26 CET] <isoboy> have you encountered a similar problem before? [07:59:43 CET] <isoboy> Could it be the settings in the SDP file? [08:00:22 CET] <isoboy> When I tried opening the SDP file using VLC player, it took a long time before one frame is shown, and nothing else. [08:03:20 CET] <relaxed> isoboy: have you seen https://trac.ffmpeg.org/wiki/StreamingGuide ? [08:04:13 CET] <isoboy> Yes. That was my starting point. [08:04:33 CET] <relaxed> and soes the example on that page work for you? [08:04:36 CET] <relaxed> does* [08:05:31 CET] <isoboy> yes [08:05:59 CET] <isoboy> Thanks for your help. [08:08:58 CET] <furq> is it just me or is git://git.videolan.org/x264.git not working [08:09:52 CET] <odinsbane> If I have a bunch of filenames like this G0025105.JPG could I use -i G%07d.JPG ? [08:10:33 CET] <c_14> sure, you might need to specify a start_number or something though [08:11:22 CET] <odinsbane> Ah, that is why it says "and no index 0-4" [08:16:02 CET] <deweydb> So i've got a couple different video clips. And i'm using an overlay filter to cross fade between them. i've got all my crossfades working ok. but at the end of the day, the final output is always much longer than what i want it to be. it gets to the end, and freezes on the last frame, and just pauses there for another 10-15 seconds. i can't figure out why. i end up having to do another pass with the trim filter. but th [08:16:02 CET] <deweydb> is seems really inneficient, i wish i could just get it to output the right length in the first place. [08:16:13 CET] <deweydb> how does the overlay filter calculate the total length of the output? [08:17:07 CET] <deweydb> http://pastebin.com/75vbfUR6 [08:17:44 CET] <c_14> https://ffmpeg.org/ffmpeg-filters.html#overlay-1 [08:17:53 CET] <c_14> you probabl want either :shortest=1 or one of the other eof_actions [08:18:30 CET] <deweydb> oh snap! [08:18:38 CET] <deweydb> man i should have asked earlier i've been stuck for like 6 hours [08:18:48 CET] <deweydb> thanks :) [08:26:18 CET] <deweydb> c_14: unf! yes! thank you so much man! totally fixed it :) [08:32:20 CET] <odinsbane> Odd, when I use .webm the result is a corrupt video file, but when I use .mp4 it works fine. There doesn't seem to be any error messages. [08:32:55 CET] <mrec> I wonder does anyone have experience with crappy pulseaudio? Sometimes it just kills my application. [08:33:16 CET] <mrec> seems to be some assert and then it goes crazy [08:33:44 CET] <mrec> it happens rarely but it happens with 2 different applications, in the other application I moved pulseaudio into another process so it can die whenever it wants [08:55:09 CET] <odinsbane> Can I do a list of images, eg $(find -name '*JPG') ? [08:55:34 CET] <c_14> no, but you can use -pattern_type glob [08:56:32 CET] <odinsbane> Yeah, I see the example for the blob. In my case I have two directories (or more) I would like to combine. [08:58:43 CET] <c_14> Either create a temporary directory for all the images (and link them there or something) or use img2pipe [09:18:33 CET] <jookiyaya> is it possible to do ffmpeg.exe convert source.flv output.mp4 (but make output.mp4 same date as source.flv) [09:20:53 CET] <c_14> You mean the creation_time tag? [10:00:33 CET] <jookiyaya> date modification [10:01:32 CET] <odinsbane> At the file system level, or metadata? [10:04:18 CET] <bencoh> .46 [10:04:21 CET] <bencoh> nevermind [10:08:27 CET] <jookiyaya> filesystem level [10:33:29 CET] <vozie> i numerized some old videos from hi8 tapes, but the image is a bit noisy; is there a way to remove this? (not talking about the audio, just the image) [10:43:51 CET] <atomnuker> vozie: try using -vf atadenoise or -vf dctdnoiz or -vf owdenoise and pick the one which looks the best [10:54:37 CET] <vozie> atomnuker: thanks i will try [11:05:57 CET] <mrec> are there any other good deinterlacers rather than yadif? [11:06:14 CET] <mrec> mcdeint=fast .. 80% cpu [11:06:20 CET] <mrec> yadif=1 .. 40% cpu [11:07:17 CET] <durandal_1707> bwdif [11:08:12 CET] <vozie> atomnuker: none of them helped ( [11:08:38 CET] <mrec> hmm bwdif is not available here by default. Xine seems to need 15% CPU (including mpeg2 decoding) [11:08:45 CET] <mrec> while ffplay is at 40% cpu [11:09:06 CET] <durandal_1707> ffplay uses sdl [11:09:43 CET] <durandal_1707> vozie: are denoising images or videos? [11:10:13 CET] <mrec> ffplay needs around 11-15% cpu without deinterlacing [11:10:43 CET] <mrec> seems like the xine deinterlacer is a winner [11:11:05 CET] <vozie> durandal_1707: videos [11:11:18 CET] <vozie> atomnuker: durandal_1707: there are horizontal black lines: http://i.imgur.com/20Efu7Q.png [11:12:18 CET] <mrec> ok the video source is not good .. it's progressive [11:12:32 CET] <mrec> can't say much about the quality then [11:13:25 CET] <durandal_1707> vozie: in source? [11:13:33 CET] <vozie> durandal_1707: yes [11:14:03 CET] <durandal_1707> than that's not noise [11:16:19 CET] <yongyung> So this is more of a theoretical question, but: If I understand correctly, resolution and bit rate have to be in some balance that depends on scene complexity for the best quality. For example a 4 mbit/s makeup tutorial might look best at 1080p because the scene isn't very complex and doesn't have much movement, but a gaming video with lots of foliage or something similar at the same bitrate might actually look better at 720p. Is that [11:16:19 CET] <yongyung> correct? So from there, wouldn't it make sense to have dynamic resolution codecs, that change resolution on the fly depending on scene complexity and bit rate, kind of like x264's -crf option already does for bit rate? [11:19:29 CET] <bencoh> good luck with the dynamic resolution, especially with hardware decoders :) [11:19:51 CET] <bencoh> (I'm pretty sure most software decoders/players would break at some point, but ... ;p) [11:28:35 CET] <BtbN> sounds like the most horrible idea i heard in a while [11:28:48 CET] <BtbN> The quality is dynamic, or the bitrate. But not the resolution. [11:33:53 CET] <jkqxz> It's done in videoconferencing-type systems. (Really it's dropping the bitrate because of bandwidth constraints, but at some point you have to drop the resolution as well or the stream is just a disaster.) [11:34:56 CET] <jkqxz> Typically they are operating on the lower bound of plausible bitrate for a given resolution, though. (720p at 1Mbit/s or so, which is fine as long as people don't move too much.) [11:35:03 CET] <BtbN> sure, inside of a single application it's a lot less troublesome than in a general code-implementation [11:35:15 CET] <BtbN> *codec [11:57:17 CET] <furq> mrec: https://ffmpeg.org/ffmpeg-filters.html#nnedi [11:57:24 CET] <furq> that's new in 3.0 [11:57:32 CET] <furq> i've not tried it in ffmpeg but i've had good results with it in avisynth [12:47:46 CET] <RadiatorHate> Hello, I'm trying to use ffserver (config - http://pastebin.com/N1ybtW3e) to livestream my webcam (video only). I'm using the command "ffmpeg -i /dev/video0 http://127.0.0.1:8090/feed1.ffm", but when I try to play the stream with "ffplay http://127.0.0.1:8090/live.webm", the video is 10 secounds behind, shows for 1-2 secounds, and then stops moving. Any help? - Need it for a school project, remote controlled robot.. [12:55:28 CET] <RadiatorHate> Any support forum I might have luck writing on? [12:57:01 CET] <furq> RadiatorHate: ffserver is basically unmaintained and generally broken [12:57:30 CET] <furq> i recommend using something better, such as nginx-rtmp [12:58:03 CET] <RadiatorHate> furq - You know any alternative that supports webM? I need an easy way to live stream to a webpage [13:02:09 CET] <furq> nginx-rtmp supports hls output if you want to view it on a webpage without using flash [13:02:20 CET] <furq> hls and dash have pretty bad latency though [13:02:41 CET] <CounterPillow> pretty sure nginx-rtmp doesn't care about the codec you're sending it [13:02:57 CET] <furq> no but flv does [13:03:01 CET] <CounterPillow> hmm, yeah [13:03:03 CET] <furq> and therefore actually yes nginx-rtmp does [13:03:07 CET] <CounterPillow> damn [13:03:56 CET] <CounterPillow> If somebody were to tackle this in a way that simply generates HLS/DASH fragments and a manifest for nginx to serve (as opposed to making it an nginx module) then that would be cool. [13:04:17 CET] <furq> RadiatorHate: if you just care about viewing it on a webpage you could output to hls or webm_dash_manifest directly [13:04:28 CET] <furq> https://www.ffmpeg.org/ffmpeg-formats.html#hls-1 [13:04:30 CET] <c_14> CounterPillow: ffmpeg -i video -f hls out.m3u8 [13:04:51 CET] <CounterPillow> c_14: doesn't really do the whole "receives a stream from a client" part [13:04:52 CET] <furq> the latency might be tolerable if you use a short gop length [13:05:11 CET] <CounterPillow> furq: yeah, it's what hitbox does too, and they get like ~5 seconds of latency [13:05:54 CET] <c_14> CounterPillow: you can do it, but you need a separate ffmpeg command per client [13:06:16 CET] <furq> yeah it sounds like you'd want it to be embedded in some kind of high-performance network server in that case [13:06:52 CET] <c_14> FFmpeg has support for multi-client network servers (at least for http), but you need to use the libraries [13:07:00 CET] <CounterPillow> furq: which is what nginx-rtmp did, but I don't really like the idea of rebuilding my nginx with some C module from John Doe. [13:07:21 CET] <furq> so run a second nginx [13:07:29 CET] <furq> don't run the rtmp module on your actual httpd [13:07:54 CET] <CounterPillow> A self-contained clean solution would be the bee's knees, I might actually tackle that at some point [13:08:12 CET] <CounterPillow> what are the go-to client-to-server transport protocols aside from rtmp? [13:08:15 CET] <furq> https://gist.github.com/fur-q/d7028f51c38f7d0bb56e [13:08:18 CET] <furq> that's pretty much what i do [13:08:44 CET] <CounterPillow> oh, cool [13:10:23 CET] <c_14> CounterPillow: rtp is the goto for low-latency multimedia [13:10:26 CET] <RadiatorHate> I'm lost a hell, using ffserver and ffmpeg together just seemed so easy and cool. I really only care about live streaming a webcam, and being able to play it in a browser easily. Livestreaming+Webpages aren't really my thing :/ [13:10:56 CET] <CounterPillow> c_14: k, thanks [13:11:26 CET] <c_14> RadiatorHate: you should be able to use webm_dash and something like dash.js or so (but all dash browser players are shitty) [13:11:51 CET] <furq> you'd still need to run an httpd to serve the manifest and fragments though [13:12:20 CET] <furq> you'd think live streaming would be easier than this in 2016, wouldn't you [13:13:03 CET] <furq> especially given browser vendors' long tradition of working together towards a brighter future for mankind [13:13:09 CET] <CounterPillow> :D [13:13:22 CET] <c_14> Setting up lighttpd or nginx isn't that hard. [13:13:33 CET] <furq> did you just say the l word [13:13:55 CET] <CounterPillow> Hey now, Mozilla spent $15000 to get somebody to change all instances of "master" and "slave" in buildbot to "leader" and "follower", they've done their good deed for the year. [13:13:57 CET] <c_14> Do you dislike lighty? [13:14:47 CET] <RadiatorHate> Couldn't I just use apache2? [13:15:16 CET] <c_14> sure, but apache is a pain [13:15:20 CET] <furq> you can use whatever httpd you want [13:15:38 CET] <furq> literally all you're doing is serving a directory of files [13:17:19 CET] <c_14> All you care about is how hard it is for you to set up and if it can handle $number_of_users [13:17:53 CET] <RadiatorHate> c_14: It's a school project, the number of users is going to be 1 :p [13:18:04 CET] <furq> you can use python -m SimpleHTTPServer if you really want [13:20:10 CET] <RadiatorHate> I'm so close to saying, fuck it, and just make a stream with ffmpeg I can open with VLC... [13:20:23 CET] <RadiatorHate> Sorry for no censoring [13:20:37 CET] <bencoh> just add the proper content-type header and you should be fine [13:30:31 CET] <RadiatorHate> Close to killing myself, so used this instead - http://phoboslab.org/log/2013/09/html5-live-video-streaming-via-websockets [13:30:48 CET] <RadiatorHate> Works really well, and easy to setup [14:48:08 CET] <lroe> I'm using hls.js to serve a video stream. Can anyone hlep me figure out how to add controls (ie full screen option) [14:53:51 CET] <GigaRoc> Hello, i'm building ffmpeg for windows with QSV support. and when i try to use the libs i build, i get 4 unresolved symbols. _ff_vc1_qsv_hwaccel, _ff_mpeg2_qsv_hwaccel, _ff_h264_qsv_hwaccel, _ff_hevc_qsv_hwaccel. I'm including the mfx.lib [14:54:19 CET] <GigaRoc> i tried to use --enable-hwaccel=h264_qsv... but it said that wasn't a valid option [14:55:56 CET] <GigaRoc> do i need to enable something else besides --enable-libmfx [14:56:38 CET] <J_Darnley> What is giving you the error? Building ffmpeg or building something else? [14:58:38 CET] <GigaRoc> building the c++ code that is using avcodec.lib [14:59:10 CET] <J_Darnley> Are you linking to all the required third-party libraries? [14:59:42 CET] <GigaRoc> yes, when i don't link against mfx.lib, i get more link errors [14:59:43 CET] <J_Darnley> oh wait, those are ffmpeg symbols (probably) [14:59:58 CET] <J_Darnley> oh i see [15:00:04 CET] <J_Darnley> You're doing it wrong. [15:00:16 CET] <J_Darnley> --enable-hwaccel=h264_qsv does not do what you think [15:00:31 CET] <J_Darnley> so then you need --enable-libmfx [15:00:56 CET] <GigaRoc> that command doesn't seem to work at all. it only compiles with --enable-libmfx [15:02:09 CET] <furq> lroe: <video controls></video> [15:03:04 CET] <lroe> furq, that was easy [15:03:06 CET] <lroe> thanks [15:04:45 CET] <GigaRoc> Do i need anything else, like with libx264 you need --enable-gpl? [15:05:07 CET] <J_Darnley> configure will tell you if you need to change license [15:17:36 CET] <max246> hello [15:18:52 CET] <max246> I am capturing with ffmpeg via Blackmagic card a video from a camera [15:19:58 CET] <max246> I got some issues that it returns 9 fps [15:20:01 CET] <max246> ops 0 fps [15:20:31 CET] <max246> but sometimes I get the right 60 fps [15:21:00 CET] <max246> is someone good at these stuff? :D [15:21:27 CET] <J_Darnley> I'm sure someone might [15:21:55 CET] <J_Darnley> if you don't get a good response here try emailing the ffmpeg-user mailing list [16:26:02 CET] <nindustries_> Hi, is there always quality loss when converting x264 to x265 ? [16:27:08 CET] <furq> yes [16:27:21 CET] <furq> unless you're using both in lossless mode [16:39:53 CET] <nindustries_> both? [16:40:03 CET] <nindustries_> Supposing the x264 is downloaded from somewhere else, furq [16:41:03 CET] <J_Darnley> Encoding using x264 will cause loss in the first place but I guess you can ignore that for your case [16:41:37 CET] <J_Darnley> encoding with x265 will result in loss unless you use a lossless mode [16:41:42 CET] <furq> technically it won't cause quality loss if you transcode lossy x264 to lossless x265 [16:41:50 CET] <furq> but it would be really idiotic to do that [16:42:12 CET] <furq> because the new file will be worse in every other aspect except quality [16:42:47 CET] <nindustries_> hm, okay [16:42:52 CET] <nindustries_> thanks guys [18:11:45 CET] <sophie___> HI [18:12:14 CET] <sophie___> i want to stream from a video cam corder [18:12:30 CET] <sophie___> i can stream the video [18:12:36 CET] <sophie___> but not de sound [18:13:05 CET] <sophie___> my command is : [18:13:07 CET] <sophie___> ffmpeg -f v4l2 -framerate 25 -video_size 640x480 -i /dev/video0 -c:a libfaac -ab 96k -ar 22050 -threads 0 -f flv [18:13:32 CET] <sophie___> wy dont i have the sound ? [18:13:38 CET] <sophie___> any idea ? [18:13:42 CET] <c_14> you need to add an alsa/pulse sound source [18:14:30 CET] <sophie___> after -i /dev/video0 ? [18:15:10 CET] <c_14> either after -i /dev/video0 or before -f v4l2 [18:16:33 CET] <davidmichaelkarr> I'm attempting to use ffmpeg for the sole purpose of extracting a single image from a video at a particular timestamp. Does the "-dframes N" option let me specify how many images to create? [18:17:24 CET] <J_Darnley> no [18:17:43 CET] <J_Darnley> you might be looking for -vframes instead [18:18:24 CET] <davidmichaelkarr> J_Darnley: What's the difference between data frames and video frames? [18:30:40 CET] <c_14> Video frames are frames of video, data frames are frames of "data". i.e. they depend on the type of the codec if it's a video codec or a "data" codec [18:56:58 CET] <mrec> is there a way to display how many threads were allocated when setting threads to auto? [19:00:03 CET] <furq> which codec [19:00:10 CET] <mrec> mpeg2 .. [19:00:14 CET] <furq> no idea then [19:00:56 CET] <c_14> use something like ps and count [19:01:16 CET] <sophie___> hey [19:01:29 CET] <sophie___> now i have white noise [19:02:00 CET] <sophie___> i 've add -f alsa -i hw:0,2 [19:02:34 CET] <sophie___> ok [19:04:02 CET] <sophie___> i've put my code here [19:04:05 CET] <sophie___> http://pastie.org/10743720 [19:04:39 CET] <sophie___> i don't understand why i just have white noise [19:08:29 CET] <sophie___> and there my arecord results [19:08:31 CET] <sophie___> http://pastie.org/10743725 [19:09:46 CET] <c_14> try the name you get from arecord -L [19:30:50 CET] <sophie___> this is the result for arecord -L [19:30:58 CET] <sophie___> for my cam recorder [19:31:14 CET] <sophie___> but i don(t no how to put it in my code [19:33:03 CET] <c_14> that was arecord -l, not arecord -L. and then just use the name of the device you want like "sysdefault" or something [19:37:21 CET] <sophie___> you that after i could use command like : default:CARD=Intel [19:37:22 CET] <sophie___> ? [19:38:00 CET] <c_14> yep [19:41:49 CET] <sophie___> program always send me : [19:41:50 CET] <sophie___> cannot open audio device default:CARD=DVC (Invalid argument) [19:42:14 CET] <sophie___> with differents entries [19:53:01 CET] <c_14> works for me [20:10:26 CET] <crot^^^> hello All, I have an issue where I cannot consume a udp stream. Running ffprobe -v trace udp://237.1.1.0:1234 ends in nothing more than [udp @ 0x28c1940] end receive buffer size reported is 131072 Does anyone have any pointers to run this down I have verified that the igmp join is going out and the stream is hitting the box after running this command [20:25:10 CET] <debianuser> sophie___: Can you hear the audio back from your cam, for example, with `arecord -fdat -Dplug:dsnoop:DVC | aplay` ? [20:25:53 CET] <debianuser> (of course if you have not solved your issue yet) [20:27:55 CET] <sophie___> hey [20:28:13 CET] <sophie___> debianuser, i've partially solved my problem [20:28:36 CET] <sophie___> by usaing -f oss -i /dev/dsp [20:29:02 CET] <sophie___> but sound is not good quality [20:29:44 CET] <debianuser> What OS/distribution are you using? [20:29:52 CET] <sophie___> i'm not sure if it's the mike of my cam [20:30:00 CET] <sophie___> ubuntu studio [20:30:08 CET] <sophie___> 13.0... [20:30:25 CET] <sophie___> when i try your command [20:30:34 CET] <sophie___> i have : [20:30:52 CET] <sophie___> unable to open slave [20:32:14 CET] <debianuser> sophie___: There should be another line explaining why the slave pcm could not be opened. Can you copy full command and its output to some pastebin? [20:32:30 CET] <sophie___> ok [20:34:07 CET] <sophie___> here [20:34:08 CET] <sophie___> http://pastebin.com/PBHSQHyY [20:44:55 CET] <debianuser> Ah, device or resource is busy... Do you have pulseaudio or jack installed? Let's check where default recording stream comes from. Can you copy the output of `arecord -v -d1 /dev/null` to some pastebin? [20:47:55 CET] <sophie___> here : [20:47:57 CET] <sophie___> http://pastebin.com/RhiRSYPW [20:52:49 CET] <debianuser> Yes, "ALSA <-> PulseAudio PCM I/O Plugin". Let's try to record from pulse then. Run `arecord -fdat -Dpulse | aplay` (it should run until you press Ctrl+C to stop it), and while it's still running - open `pavucontrol` and on the "Playback" tab find something like "arecord (alsa-plugin)" - there should be a dropdown menu next to it, there you can select what card it records from. [21:07:22 CET] <sophie___> yes, thank you, the sound is better [21:11:11 CET] <debianuser> sophie___: The same should work for ffmpeg. Use "-f alsa -i pulse" and then select an input device for ffmpeg on pavucontrol's Playback tab. [21:14:20 CET] <sophie___> ok, but how do you use -f alsa -i pulse in a ffmpeg command ? [21:15:54 CET] <debianuser> ffmpeg -f v4l2 -framerate 25 -video_size 640x480 -i /dev/video0 -f alsa -i pulse ... [21:16:07 CET] <sophie___> ah okok [21:23:38 CET] <sophie___> ah yes! ok [21:23:50 CET] <sophie___> i've understood [21:24:19 CET] <sophie___> thank u debianuser , far more simple like that way [21:44:12 CET] <spookypeanut> i'm trying to scale a vob that i created using vobcopy, using the method on this page: https://trac.ffmpeg.org/wiki/How%20to%20speed%20up%20/%20slow%20down%20a%20… but i always end up with audio being greatly out of sync with video. anyone any suggestions as to why? [21:44:32 CET] <spookypeanut> (i'm also converting it to mp4 at the same time) [21:48:17 CET] <J_Darnley> does the audio remain in sync when you aren't trying to change speed? [21:49:50 CET] <spookypeanut> i *think* there might be a very slight sync issue, but i've just watched the raw vob and i think that might be the same [21:52:57 CET] <Mista_D> Is there a command to convert subtitles SRT to ISMT (for Silver Light) please? [21:53:31 CET] <J_Darnley> -scodec ismt ? (unlikely) [21:54:06 CET] <J_Darnley> spookypeanut okay sounds mostly fine to me [21:54:20 CET] <J_Darnley> can you please show us exactly what you are doing? [21:56:11 CET] <spookypeanut> currently going from a remuxed mpg [21:56:45 CET] <spookypeanut> ffmpeg -i in.mpg -r 24 -crf 21 -preset superfast -vcodec h264 -acodec aac -strict -2 -filter_complex "[0:v]setpts=(25/24)*PTS[v];[0:a]atempo=24/25[a]" -map "[v]" -map "[a]" out.mp4 [21:57:06 CET] <spookypeanut> maybe i should try with a different acodec... [21:57:12 CET] <J_Darnley> I would suggest you remove the -r 24 [21:57:29 CET] <spookypeanut> pretty sure i've tried that [21:57:47 CET] <spookypeanut> i need it if i want the output to be 24 fps, right (from 25fps input) [21:57:50 CET] <spookypeanut> ? [21:57:55 CET] <furq> if this is pal to film then that should be setpts=25025/24000*PTS [21:58:03 CET] <J_Darnley> isn't that what the setpts is for? [21:58:07 CET] <furq> and no, you shouldn't need to provide any framerate [21:58:23 CET] <spookypeanut> furq: it is [21:58:29 CET] <spookypeanut> i'll try that, thanks [21:58:30 CET] <J_Darnley> You are telling ffmpeg to convert to 24 in two different ways [21:58:32 CET] <furq> well yeah film isn't 24fps, it's 24000/1001fps [21:58:44 CET] <furq> 24 would be far too simple [22:00:43 CET] <furq> also atempo should be 24000/25025 [22:00:51 CET] <furq> in case that wasn't obvious [22:01:02 CET] <furq> that would only account for a slight desync though [22:01:04 CET] <spookypeanut> J_Darnley: i got the -r 24 from that page i linked earlier [22:01:19 CET] <spookypeanut> seemed to say it was required to get a 24fps output [22:01:32 CET] <J_Darnley> oh god it really does have it [22:02:36 CET] <spookypeanut> when i remove that, the ffmpeg output says: Stream #0:0: Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv420p, 720x576 [SAR 16:15 DAR 4:3], q=-1--1, 25 fps, 12800 tbn, 25 tbc (default) [22:03:07 CET] <spookypeanut> (it'll take a while till i can check the output: should really get a shorted vob to work with :-) ) [22:03:13 CET] <furq> also do you actually need filter_complex with one video and one audio filter [22:03:18 CET] <furq> i'd have thought -vf and -af would work [22:04:22 CET] <spookypeanut> furq: maybe. i was just using the example on that page: i can try with -vf and -af if you think it'll make a difference [22:04:40 CET] <furq> i doubt it makes a difference, it'd just make the command simpler [22:05:34 CET] <furq> also (again) it'll be -r 24000/1001 if you do need -r [22:06:08 CET] <spookypeanut> yeah [22:06:38 CET] <furq> i was sure i remembered doing a pal to film conversion but that was a horrible field-blended source which went through a bunch of fancy avisynth filters [22:06:48 CET] <spookypeanut> i'll do this correctly with that factor in the long term, but for now it's simpler just to use 24fps [22:07:16 CET] <furq> well that's one frame every 40 seconds so it could cause a pretty big desync [22:07:33 CET] <furq> wait no it isn't. shut up furkan [22:07:36 CET] <furq> and furq too [22:08:16 CET] <spookypeanut> hehe [22:08:22 CET] <furkan> lol that was a confusing alert [22:08:30 CET] <furq> i thought i told you to shut up [22:08:35 CET] <furkan> haha [22:09:15 CET] <spookypeanut> but it won't cause a desync anyway, will it? so long as i do video and audio the same, i could do them 50fps and the sync should be ok [22:09:31 CET] <furq> idk i assumed setpts would set the right framerate anyway [22:10:06 CET] <spookypeanut> i'll see in a few minutes, but it looks like i'm go to end up with a 25fps video out of the end without -r 24 [22:10:39 CET] <furq> i like it when films run 4% faster. it's more efficient [22:25:05 CET] <bencoh> it's not that bad but it's still a frame every 20mn, isn't it? [22:25:26 CET] <bencoh> (24000/1001 vs 24fps) [22:25:32 CET] <furq> 16:40 [22:25:41 CET] <bencoh> yeah [22:26:42 CET] <spookypeanut> it just finished, and yes, i got a 25fps video out [22:27:39 CET] <spookypeanut> back later [22:29:22 CET] <bencoh> I'd say you need to drop frames if you want to "convert" from 25fps to 24fps with ffmpeg, unless we have a special filter to rebuild frames (which we dont in ffmpeg iirc) [22:29:44 CET] <furq> he's using setpts to slow the video down [22:29:56 CET] <bencoh> furq: I remember the same about an ugly avisynth filter [22:30:07 CET] <ibrezac> Hi, is there a way to remove embedded Closed Caption (cea-708) from an mp4 using ffmpeg? [22:30:19 CET] <bencoh> I even remember reading the (atrocious) source code to port it to another pipeline framework [22:30:44 CET] <bencoh> (I didn't do it in the end) [22:33:29 CET] <furq> the filter itself was pretty good, it was the source which was awful [22:33:55 CET] <furq> http://avisynth.nl/index.php/Srestore [22:34:36 CET] <furq> i should probably just track down an ntsc dvd of the film though [23:47:00 CET] <crot^^^> hello All, I have an issue where I cannot consume a udp stream. Running ffprobe -v trace udp://237.1.1.0:1234 ends in nothing more than [udp @ 0x28c1940] end receive buffer size reported is 131072 Does anyone have any pointers to run this down I have verified that the igmp join is going out and the stream is hitting the box after running this command [00:00:00 CET] --- Wed Mar 2 2016

1 0