[Ffmpeg-devel-irc] ffmpeg-devel.log.20160305

[burek]

[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> /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