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

[burek]

[03:05:40 CEST] <Compn> internet dying ! oh nooo
[03:31:09 CEST] <haasn> Maybe somebody here knows why the motion vectors I get out of export_mvs are so weird? I have a sample that's a static image which moves by 12 pixels per frame, yet the motion vectors tell me that the motion is 28 pixels pretty much everywhere
[03:31:21 CEST] <haasn> (but not everywhere, and not all the time)
[03:31:36 CEST] <haasn> I'm mostly confused about the discrepancy between the numbers
[03:31:40 CEST] <haasn> 28 and 12 aren't even close to related
[03:32:09 CEST] <haasn> but eg. I get src: (820,712), dst: (792,712), w/h: (16,16)
[03:32:58 CEST] <haasn> (source is http://red.cachefly.net/learn/panning-24fps-180.mp4)
[03:33:04 CEST] <haasn> (maybe the source is just hilariously badly encoded?)
[03:33:15 CEST] <haasn> maybe it's a bug in lavc?
[03:53:40 CEST] <sreuter> Hey folks - Congrats on getting 2.6.x out the doors! I just gave it a spin, because 24bit WMA support. Unfortunately, it seems that the newly added feature is broken :( https://trac.ffmpeg.org/ticket/4134
[03:54:03 CEST] <sreuter> I gave it a spin with some of my test files, and they also sound distorted when converted to MP3/WAV&
[03:54:41 CEST] <sreuter> Just wondered if anyone is already on top of this?
[04:00:04 CEST] <jamrial> yeah, it's a know issue
[07:45:08 CEST] <Timothy_Gu> SIGSEGV in FATE uncaught. Joy.
[08:18:16 CEST] <Prelude2004c> hey
[08:18:17 CEST] <Prelude2004c> hey guys.. i ahve a full 24 core system... when i run ffmpeg alone per stream i get 60fps on each stream. ( 5 fo them so 300 fps ).. when i run ffmpeg with multi output on the same pid , i get 120fps max . anyone have any idea why ? its not hte CPU usage because i have threads 0 and it uses more than 100%
[08:18:24 CEST] <Prelude2004c> any ffmpeg limitations?
[08:22:21 CEST] <Timothy_Gu> Prelude2004c: yes. IIRC ffmpeg caps its threading on some number of threads because above that there aren't any improvements anymore
[08:22:41 CEST] <Timothy_Gu> (IIRC)
[08:26:03 CEST] <Timothy_Gu> I highly suspect Nedeljko made some modifications in his ffmpeg checkout&
[08:29:20 CEST] <Prelude2004c> really?
[08:29:40 CEST] <Prelude2004c> but... the problem is that i am trying to say ffmpeg -i Source . and output 3 or 4 differnet outputs of rhte same input
[08:29:45 CEST] <Prelude2004c> so FFMPEG threads are 1
[08:29:49 CEST] <Prelude2004c> but output is 3 or 4
[08:29:58 CEST] <Prelude2004c> probelm is, it seems limited to the 120fps
[08:30:13 CEST] <Prelude2004c> so i am slightly confused by this
[08:30:20 CEST] <Prelude2004c> any way around this or to override it ?
[08:30:34 CEST] <Prelude2004c> i want to output 4 or 5 HLS outputs at 60fps each
[08:31:36 CEST] <Timothy_Gu> Prelude2004c: have you tried running 4 or 5 ffmpeg commands at once?
[08:31:45 CEST] <Timothy_Gu> I suspect it's memory or io issue
[08:32:48 CEST] <Timothy_Gu> Prelude2004c: can you show your FUULLL ffmpeg command?
[08:34:49 CEST] <Prelude2004c> yup ran them all sepeartely and yes they all run jus fine
[08:35:37 CEST] <nevcairiel> its probably bottle-necking somewhere, the MT architecture in ffmpeg isnt that flexible
[08:35:45 CEST] <Prelude2004c> http://pastebin.com/vGZwNL70
[08:36:08 CEST] <Prelude2004c> it is very odd...
[08:36:25 CEST] <Prelude2004c> 5 channels at 60fps is 300fps .. i should be able to do that
[08:36:42 CEST] <Prelude2004c> provided the system can handle it of course
[08:36:57 CEST] <Prelude2004c> but i tried both with NVENC and with CPU .. same result when muilti outupt
[08:37:05 CEST] <Prelude2004c> so it can't be CPU or GPU
[08:37:17 CEST] <nevcairiel> there is no guarantees when multi-threading that it scales up linear
[08:37:17 CEST] <Prelude2004c> again i will try new system completely tomorrow.. different cpu / ram ,/ motherboard
[08:37:33 CEST] <Prelude2004c> just thought i would ask for help if anyone is aware of this problem
[08:37:45 CEST] <Prelude2004c> ya i know but i am trying to keep track of all the streams under one pid
[08:38:01 CEST] <Prelude2004c> anyone know a way in linux to basically have a pid started for each ( x number of seessions )
[08:38:28 CEST] <Prelude2004c> that way i can keep track of things correctly? right now its just ffmpeg , ffmpeg , ffmpet.. over and over
[08:38:36 CEST] <Prelude2004c> and also, some way to grab the input one time intead of 5 times
[08:38:45 CEST] <Prelude2004c> i dont want to increase load on the WAN UDP interface
[08:38:54 CEST] <Prelude2004c> no need.. i get it once, i should be able to output to all the other processes
[08:39:04 CEST] <Prelude2004c> that is what i have been trying to do with multi ffmpeg outputs
[08:39:13 CEST] <Timothy_Gu> BTW see https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/pthread_internal.h#L24-L26
[08:40:19 CEST] <Timothy_Gu> Prelude2004c: in bash you can do ffmpeg adsf & ffmpeg asfd & ffmpeg blah
[08:41:27 CEST] <Timothy_Gu> i'm too tired right now to think of anything so good luck&
[08:44:11 CEST] <Prelude2004c> yup i am doing that now .. just launches a bunch of ffmpeg commands
[08:44:12 CEST] <Prelude2004c> which is fine
[08:44:15 CEST] <Prelude2004c> :)
[08:44:20 CEST] <Prelude2004c> thank you for your help
[08:44:23 CEST] <Prelude2004c> i will check again tomrorow
[08:48:38 CEST] <ubitux> Daemon404: don't we have support for stl subs?
[11:08:59 CEST] <kierank> Prelude2004c: you're encoding with high10
[11:09:00 CEST] <kierank> why
[11:42:24 CEST] <ubitux> Timothy_Gu: i remember solaris libc or something related not liking "%s",NULL
[11:42:49 CEST] <ubitux> might be or might not be related to your crash in avstring
[11:43:16 CEST] <wm4> you mean printf("%s", NULL)?
[11:43:21 CEST] <ubitux> yes
[11:43:26 CEST] <wm4> this is not allowed by C
[11:43:46 CEST] <wm4> an implementation is free to crash on it (it's UB)
[11:43:56 CEST] <ubitux> not suggesting it is, but many libc seems to allow it an print "(null)"
[11:44:07 CEST] <wm4> that doesn't make it any less UB
[11:44:17 CEST] <ubitux> typically i remember this happening with codec string name being null being displayed in the output
[11:44:32 CEST] <wm4> that's a bug then
[11:44:36 CEST] <ubitux> sure
[11:45:00 CEST] <wm4> also I'm pretty sure this would invoke msvcrt's invalid parameter handler
[11:45:27 CEST] <wm4> so program behavior would depend on how this handler is configured
[11:47:56 CEST] <kierank> michaelni: is there anything I can do to help with #4440
[11:48:54 CEST] <cone-662> ffmpeg 03ferdo at bigroses.nl 07master:92f94fd5dd8b: libavcodec/hqx: correct clipping error
[12:45:28 CEST] <cone-662> ffmpeg 03Michael Niedermayer 07master:795199fca408: avcodec/h264: use consistent argument name in MB_FIELD() macro
[12:45:29 CEST] <cone-662> ffmpeg 03Michael Niedermayer 07master:386601286fed: avcodec/h264_slice: Dont reset mb_aff_frame per slice
[13:16:17 CEST] <cone-662> ffmpeg 03Michael Niedermayer 07master:845ab37b05e1: avcodec/h264_slice: Fix uninitialized variable
[14:02:47 CEST] <thardin> is 720p vp8 encoding supposed to go at 6 fps?
[14:50:35 CEST] <cone-662> ffmpeg 03Gilles Chanteperdrix 07master:21e034a47a2b: avformat/libquvi: Fix whitelist handling
[15:05:21 CEST] <cone-662> ffmpeg 03Paul B Mahol 07master:a0854c084ea1: avfilter: handle error in query_formats() in bunch of filters
[15:53:41 CEST] <kierank> michaelni: h264 sliced threads is looking resilient now
[15:53:47 CEST] <kierank> also I haven't heard from outreachy
[15:54:13 CEST] <michaelni> kierank, you have no access yet ?
[15:55:31 CEST] <vibr> hi, i'm considering applying to an outreachy internship
[15:55:32 CEST] <kierank> nope
[15:55:38 CEST] <vibr> the deadline is on the 10th
[15:55:55 CEST] <vibr> (i only stumbled across it yesterday night)
[15:56:17 CEST] <kierank> vibr: https://trac.ffmpeg.org/wiki/SponsoringPrograms/Outreachy/2015-05
[15:56:20 CEST] <kierank> have a look at that
[15:56:32 CEST] <vibr> do you think there's still a chance of getting the qualification task done in such a short time?
[15:56:51 CEST] <vibr> i did check that site, thanks
[15:56:52 CEST] <michaelni> vibr, make sure you submit an application to outreachy before the deadline also some contribution to ffmpeg / qualification task is mandatory if you want to be accepted
[15:57:15 CEST] <kierank> michaelni: they can apply but do their qualification task after 10th april, right?
[15:57:22 CEST] <vibr> i'd be interested in either the API regression testing
[15:57:32 CEST] <vibr> or the network servers
[15:57:41 CEST] <michaelni> kierank, yes
[15:58:34 CEST] <vibr> michaelni, are you sure about that?
[15:59:04 CEST] <vibr> because i would need to know if it's worthwile investing the time
[16:00:24 CEST] <selsta> Sorry for being on the wrong channel, but getting support on the one is quite difficult. Whats the best way to implement my own bitstream filter?
[16:00:36 CEST] <Prelude2004c> good day guys
[16:00:47 CEST] <michaelni> vibr, contributing to a free software is certainly worthwhile investing time, many people benefit from free software
[16:01:43 CEST] <vibr> michaelni, you are right, of course ;) but what i meant is: if i start now and then find out the application is closed it would be kind of sad ..
[16:02:23 CEST] <Prelude2004c> i have an odd one i was hopping someone could help me with.. i think its a bug or something.. When i encode something ( 1 session at a time , say at 60fps ) i can have 5 or 6 sessions going and i am only using like 5 CPU's ( of 24 ) .  Works well no problem. When i change ffmpeg to one input but 5 simultanious outputs i can't seem to get over a 120fps problem. I don't know why. It is the same thing really but instead of havi
[16:02:26 CEST] <Prelude2004c> any ideas ?
[16:02:26 CEST] <selsta> Currently Im using av_read_frame() to get a packet. Then Im saving the packet.data in my own memory and perform the bitstream filter, but getting the packets together again is what Im failing at.
[16:02:33 CEST] <kierank> Prelude2004c: don't use high10
[16:02:35 CEST] <kierank> use high profile
[16:02:36 CEST] <Prelude2004c> i am using HLS out .. oh and i have threads 0
[16:02:41 CEST] <Prelude2004c> i am not.. that was testing
[16:02:45 CEST] <Prelude2004c> i removed that comletely
[16:02:46 CEST] <kierank> and limit your threads to 4 or so
[16:03:02 CEST] <Prelude2004c> its not even using 1
[16:03:11 CEST] <kierank> i doubt that
[16:03:13 CEST] <Prelude2004c> after is tarted it , i am using about 1 core
[16:03:15 CEST] <vibr> so when do you have to decide on the internship, it it's not the 10th? What's the latest date for the qualification task to be done?
[16:03:16 CEST] <Prelude2004c> really ..
[16:03:26 CEST] <kierank> are you measuring the sum of all threads
[16:03:30 CEST] <kierank> or counting each thread individually
[16:03:56 CEST] <Prelude2004c> well when i run a reach individually it works well no issues
[16:04:06 CEST] <Prelude2004c> when i start ffmpeg with multi HLS out.. its all in one
[16:04:25 CEST] <Prelude2004c> so technically it should be using 500% of cpus intead of 100% on each for example
[16:04:51 CEST] <Prelude2004c> but it doesn't.. when i run 5 session ( they all hav about 70 or 80% on each cpu ) .. when i turn them all together.. 1 ffmpeg session = 40% cpu ( 1 core )
[16:05:02 CEST] <Prelude2004c> soo odd
[16:05:42 CEST] <Prelude2004c> http://pastebin.com/vGZwNL70 < code
[16:05:43 CEST] <nevcairiel> mt scaling is just not perfectly linear in many cases, unless the process is specifically optimized for that, so good luck w ith that
[16:06:04 CEST] <Prelude2004c> but is it an ffmpeg limitation?
[16:06:15 CEST] <vibr> What's the latest date for the qualification task to be done?
[16:06:25 CEST] <Prelude2004c> it has to be because i tried with nvenc and i tried with CPU, about same result
[16:06:29 CEST] <michaelni> vibr, theres not a single date, there are 2, first is the 13th at which we must know if we need any slots from general funding but theres then still a week or 2 more than to choose who gets the slot from our "own funding"
[16:06:54 CEST] <vibr> ah, ok, thanks!
[16:07:10 CEST] <Prelude2004c> oh and forget profile high10 btw, :) in the code.. its no longer there
[16:07:30 CEST] <Prelude2004c> its def. a problem of not being able to keep up.. i just don't know why
[16:07:44 CEST] <kierank> probably being input bottlenecked
[16:07:55 CEST] <kierank> not sure ffmpeg.c is fully optimised for doing multiple encodes at the same time
[16:07:59 CEST] <Prelude2004c> input bottlenecked? its a 1 GIG link ( local content )
[16:08:04 CEST] <Prelude2004c> + its only 1 input
[16:08:06 CEST] <kierank> input cpu bottlenecked
[16:08:08 CEST] <Prelude2004c> like 8Mbit/s
[16:08:41 CEST] <Prelude2004c> it is odd... 120fps seems like the number
[16:08:45 CEST] <Prelude2004c> that is where it dies
[16:09:03 CEST] <Prelude2004c> as if someone has limited ffmpeg to 120fps per session or something
[16:09:10 CEST] <vibr> michaelni, so ffmpeg is only going to have 1 intern?
[16:09:34 CEST] <wm4> whatever happened to gsoc
[16:10:10 CEST] <michaelni> 1 slot from our own funding in outreachy, unkown if we will have a 2nd slot, but atm there are no interns in outreachy that passed qualification
[16:10:25 CEST] <michaelni> gsoc will have more slots i would assume
[16:13:42 CEST] <vibr> michaelni, thanks. gsoc's not for me, im not a student, graduated already
[16:14:18 CEST] <selsta> maybe me current code makes it more clear what Im trying to achieve: https://github.com/selsta/HLS-Downloader/blob/sample-aes/hls.c#L351 - Im doing the decryption in the while loop, but I cant seem to save it. Ideally I could just change the memory of the packet, but that does not seem to work.
[16:15:08 CEST] <vibr> kierank, you're the mentor for the API regression test, could you give me some more hints about the qualification task?
[16:15:19 CEST] <kierank> vibr: yes
[16:15:23 CEST] <kierank> basically
[16:15:31 CEST] <kierank> all regression testing is done with ffmpeg.c currently
[16:15:36 CEST] <kierank> it would be nice to have api regression tests
[16:15:42 CEST] <wm4> yeah, sounds nice
[16:15:46 CEST] <kierank> based on the examples in /doc/
[16:16:06 CEST] <kierank> the task is to basically write simple test programs for decoders that can be used in FATE
[16:16:20 CEST] <wm4> in fact I'd argue that this would be one good step towards moving ffmpeg.c to its own repo
[16:16:29 CEST] <wm4> so ffmpeg.c becomes just another API user
[16:16:38 CEST] <kierank> wm4: besides the point for a student
[16:16:43 CEST] <wm4> sure
[16:16:48 CEST] <kierank> sorry an outreachy candidate
[16:17:00 CEST] <wm4> just saying it's potentially very useful
[16:17:18 CEST] <kierank> yes that's why i want to mentor it
[16:18:34 CEST] <rcombs> I'd like ffmpeg.c to be like 1/10 its current size
[16:19:04 CEST] <vibr> so the API documentation is in this file: https://ffmpeg.org/doxygen/trunk/group__libavc.html
[16:19:21 CEST] <wm4> yay found a mp4 file which works with Libav but breaks with FFmpeg
[16:19:27 CEST] <vibr> or is there other documentation?
[16:19:31 CEST] <wm4> and guess what, it's because Libav is saner
[16:19:48 CEST] <wm4> vibr: this API documentation is generated from doxygen comments in the source
[16:20:22 CEST] <kierank> vibr: yes, and in avcodec.h
[16:20:33 CEST] <kierank> the example files are in /doc/examples I think
[16:22:06 CEST] <vibr> yes, there's /doc/examples. I didn't see an example for a test there
[16:23:52 CEST] <vibr> so the test for the qualification task, is it supposed to be embedded in FATE?
[16:24:10 CEST] <kierank> it's not an example for a test
[16:24:19 CEST] <kierank> it's an example for a general user wanting to use it
[16:24:25 CEST] <kierank> the task is to convert one of those into a test
[16:24:34 CEST] <kierank> the easiest files to look at are h264 or flac
[16:24:38 CEST] <kierank> because they are bitexact
[16:26:41 CEST] <vibr> thanks. so the qualification task is mostly turning one of the examples into a test, which is independent from the testing platform (FATE)?
[16:26:46 CEST] <kierank> no
[16:26:55 CEST] <kierank> it needs to (eventually) all be in fate
[16:27:04 CEST] <kierank> the problem is fate only tests one (huge) implementation of the API
[16:27:09 CEST] <kierank> it should also test lots of little implementations
[16:29:21 CEST] <vibr> so for the qualification part i don't have to care about fate yet? Or do I?
[16:30:55 CEST] <kierank> I would try
[16:31:01 CEST] <kierank> but we would mark you on your effort I guess
[16:31:45 CEST] Action: kierank afk
[16:33:38 CEST] <vibr> kierank, thanks, i'm going to have a look at the code and then get back to you. Are you here on weekdays, generally?
[16:33:43 CEST] <kierank> yes
[16:34:13 CEST] <vibr> and one last question: have you been a mentor for outreachy or a similar program before?
[16:34:24 CEST] <wm4> you can also just ask the channel; someone who is present and knows what you're asking might just answer
[16:34:30 CEST] <kierank> gsoc and gci before
[16:34:49 CEST] <vibr> thanks to all of you!
[16:45:33 CEST] <BBB> so, Im doing a new round of lets get my ffmpeg build as small as possible
[16:45:50 CEST] <BBB> and shockingly, I get about 100 source files when doing a build with _just_ a vp9 decoder and ivf demuxer
[16:45:53 CEST] <BBB> why is that?
[16:46:15 CEST] <av500> utils?
[16:46:17 CEST] <BBB> most of them are things that I cant explain how they could possibly get in the dependency tree
[16:46:23 CEST] <BBB> like xiph.o, id3v2.o
[16:46:28 CEST] <BBB> theres sdp.o
[16:46:33 CEST] <av500> BBB: any file can have an id3 tag
[16:46:44 CEST] <BBB> if I build with --disable-all
[16:46:48 CEST] <BBB> why isnt it disabled?
[16:46:54 CEST] <BBB> I specifically say disable everything"
[16:46:58 CEST] <BBB> why isnt this stuff disabled?
[16:47:21 CEST] <av500> because historically, few people care for small builds
[16:47:22 CEST] <BBB> other things are also still enabled with disable-all, like vda, xlib, zlib, ...
[16:47:45 CEST] <BBB> (I know theres specific flags to disable them, but why arent they part of disable-all?)
[16:47:54 CEST] <av500> -disable-all is mostly to disable all codecs for legal reasons, then enablethe ones you want
[16:48:07 CEST] <av500> at least I guess thats how people use it
[16:48:10 CEST] <BBB> and esp. with the new work on ciphers etc., avutil is really growing out of proportions
[16:48:17 CEST] <BBB> so itd be nice if we can disable components there also
[16:49:03 CEST] <funman> systemavd.o
[16:49:06 CEST] <BBB> there was dv_profile.o
[16:49:17 CEST] <BBB> qsv_api.o
[16:49:20 CEST] <BBB> what is qsv anyway
[16:49:32 CEST] <BBB> vorbis_parser.o ?????
[16:49:57 CEST] <BBB> imgconvert, resample (arent all of these 100x deprecated with the new libs?)
[16:50:06 CEST] <funman> intel quick sync video presumably
[16:50:06 CEST] <BBB> x86/deinterlace.o
[16:51:03 CEST] <wm4> <BBB> I specifically say disable everything" <BBB> why isnt this stuff disabled? <- because if your ivf file has an id3 tag, it can't be read
[16:51:15 CEST] <BBB> my ivf file has no id3 tag
[16:51:24 CEST] <BBB> just like my .c source file has no id3 tag
[16:51:24 CEST] <wm4> <BBB> imgconvert, resample (arent all of these 100x deprecated with the new libs?) <- yes but ffmpeg never removes anything
[16:51:35 CEST] <Timothy_Gu> ubitux: idk
[16:51:57 CEST] <wm4> no matter how broken and unused it is, ffmpeg will keep it
[16:52:00 CEST] <wm4> it's a way of life
[16:52:16 CEST] <BBB> michaelni: can we remove imgconvert, resample and resample2 now?
[16:52:22 CEST] <BBB> michaelni: and deinterlace
[16:53:31 CEST] <BBB> michaelni: and can we remove all these non-generic things like qsv, xiph, vorbis, dv from the unconditional OBJS in libavcodec/Makefile?
[16:54:05 CEST] <michaelni> stuff surely should be removed from  the unconditional OBJS if possible
[16:54:25 CEST] <Timothy_Gu> qsv? isn't libav supposed to be writing clean code?
[16:54:32 CEST] <BBB> and then lastly, why do we compile libavutil/x86/emms.asm if HAVE_INLINE_MMX?
[16:55:41 CEST] <michaelni> imgconvert deinterlace is already under FF_API_DEINTERLACE so it should go away with the next major bump
[16:56:02 CEST] <BBB> what about resample/resample2?
[16:56:41 CEST] <michaelni> :#define FF_API_AVCODEC_RESAMPLE  FF_API_AUDIO_CONVERT
[16:56:42 CEST] <michaelni> #define FF_API_AUDIO_CONVERT     (LIBAVCODEC_VERSION_MAJOR < 57)
[16:57:09 CEST] <michaelni> so if iam not misreading the code it will go away too with the next bump
[16:58:51 CEST] <BBB> michaelni: http://pastebin.com/awiQ3QF9
[17:04:11 CEST] <nevcairiel> nonono!
[17:07:48 CEST] <poste9> hello guys... could you tell me if there's a better approach to do what I need to do? Basically I need to record a video from camera (wich is already beeing done with libav*) and add some texts, like the current date/time (also done using freetype) The thing is the text is being processed by the h264 encoder and losing a lot of quality(CFR 30). My next goal is to record the vídeo and make something like a subtitle, and when I need to see those video
[17:07:49 CEST] <poste9> s I would need to read the "subtitle" file and add at the screen using my custom player. Thats an acceptable solution... But I need to know if you guys know of anything less "hacky" or the proper way to acchive the same result. (CFR 30 and lossless subtitles)
[17:09:44 CEST] <BBB_> nevcairiel: why no?
[17:10:14 CEST] <nevcairiel> just quoting the fun variable name in your paste
[17:12:48 CEST] <BBB_> how about you can rename it to anything you want and Im ok with it
[17:12:59 CEST] <BBB_> like a cart blanche?
[17:13:04 CEST] <BBB_> (is that the correct word?)
[17:24:15 CEST] <av500> poste9: I dont think there is a way to tell the encoder to encode a portion of the screen with a higher quality
[17:25:52 CEST] <BBB_> if its text, I would just leave it as text
[17:26:01 CEST] <BBB_> it probably aids both video compression as well as text detail
[17:26:08 CEST] <BBB_> so both sides win
[17:26:11 CEST] <cone-662> ffmpeg 03Ronald S. Bultje 07master:b926f02e8116: avutil/x86/Makefile: Make building and linking of emms.c conditional
[17:26:29 CEST] <BBB_> isnt that what subtitles are for?
[17:26:32 CEST] <poste9> thats what I thought... thank you.
[17:26:53 CEST] <BBB_> yw
[17:26:56 CEST] <BBB_> michaelni: ty
[17:27:48 CEST] <michaelni> np
[17:27:51 CEST] <BBB_> michaelni: I think the idea of componentization of libavutil was brought up before, and the main issue is that some of it is public api (I suppose thats why avdct/vorbis_parser/& are in OBJS)
[17:28:02 CEST] <BBB_> I dont mind custom build flags for this
[17:28:46 CEST] <BBB_> as long as default builds work, are you ok with a disable-avutilcomp=murmur3,& etc. flag?
[17:29:04 CEST] <BBB_> itd basicaly work like disable-encoder=.. or enable-encoder=..
[17:29:08 CEST] <BBB_> just for avutil
[17:29:11 CEST] <BBB_> I think itd save some space
[17:29:45 CEST] <BBB_> and then maybe use that for things that are part of public api in avcodec also (disable-avcodeccomp=vorbis_parser,avdct,..)
[17:30:22 CEST] <BBB_> or even just a general disable-apicomp=.. flag
[17:30:35 CEST] <BBB_> disable-api=..?
[17:31:44 CEST] <Daemon404> or we could stop pretending libs are actually separate
[17:31:45 CEST] Action: Daemon404 runs
[17:32:00 CEST] <michaelni> i am fine with making libavutil more modular, it should maybe not be possible to install it as shared lib then though either way thats just my oppinion
[17:33:02 CEST] <michaelni> i mean if parts are disabled it should not be possible to install as shared lib
[17:33:53 CEST] <michaelni> or there should be a really big warning
[17:33:59 CEST] <iive> what was the name of the library that got merged into avutil?
[17:34:05 CEST] <BBB_> avcore
[17:34:19 CEST] <BBB_> splitting a big lib in two big libs does not solve the problem of the lib being big
[17:34:24 CEST] <BBB_> it just splits it into two problems
[17:34:29 CEST] <BBB_> its a diego-solution
[17:34:33 CEST] <iive> yep. I remember that avutil was designed to be small.
[17:34:38 CEST] <BBB_> lets get ri of dsputil by splitting it into two dsputils
[17:34:49 CEST] <BBB_> yay, dsputil is gone, hurray!
[17:34:56 CEST] <BBB_> now we have two new problems
[17:35:01 CEST] <BBB_> anyway
[17:35:12 CEST] <BBB_> avcore and avutil both had the same issues so merging them together made sense
[17:35:17 CEST] <BBB_> now we can fix the problem once and correctly
[17:35:22 CEST] <wm4> libavutil is big because ffmpeg refuses to use libc
[17:36:11 CEST] <BBB_> I dont care much why its big
[17:36:18 CEST] <BBB_> I care for how I can make it smaller for one specific use case
[17:36:21 CEST] <rcombs> > C90
[17:36:23 CEST] <BBB_> michaelni: I can look at that
[17:36:27 CEST] <BBB_> ty
[17:36:55 CEST] <Daemon404> rcombs, the issue isnt c90 per se
[17:37:01 CEST] <Daemon404> its that systems have broken libc
[17:37:04 CEST] <Daemon404> regardless of c spec
[17:38:12 CEST] <kierank> ffmpeg has too much mission creep
[17:38:16 CEST] <kierank> an in built web server
[17:38:22 CEST] <kierank> directory listing api
[17:38:23 CEST] <kierank> wtf
[17:40:46 CEST] <iive> avsystemd
[17:40:54 CEST] <BBB_> yeah the directory listing api kind of confused me
[17:41:08 CEST] <rcombs> isn't that supposed to be MKV ordered chapters and such
[17:41:11 CEST] <BBB_> as long as I can disable it I dont care I guess
[17:41:35 CEST] <wm4> rcombs: fuck no
[17:41:48 CEST] <rcombs> well then I have no idea what that's for then
[17:41:55 CEST] <wm4> nobody knows
[17:42:05 CEST] <wm4> because Lukasz wanted it and mini can't say no?
[17:42:54 CEST] <kierank> wm4: ding ding ding
[17:43:10 CEST] <wm4> good night?
[17:44:19 CEST] <rcombs> what's one supposed to do when a patch just sits on the ML untouched for a while? Reply to bump it?
[17:44:27 CEST] <Daemon404> yep
[17:44:59 CEST] <iive> rcombs: or commit it, if there are no objections
[17:45:10 CEST] <rcombs> iive: that's a thing I can't actually do
[17:45:39 CEST] <Daemon404> rcombs, ping it, i will look
[18:00:25 CEST] <kierank> wm4: heh more mission creep
[18:00:28 CEST] <kierank> youtube downloading
[18:00:39 CEST] <kierank> nice way to violate the TOS too
[18:01:01 CEST] <wm4> youtube downloading that puts the prober into an infinite loop
[18:05:33 CEST] <kierank> I guess this quvi thing is harmless
[18:06:38 CEST] <Timothy_Gu> I'm out of ideas on how the navigation buttons should look like: http://104.131.148.213:8081/report/arm7-cubox-gcc4.1-n2.4/20150330233955
[18:06:41 CEST] <wm4> as long as your distro doesn't actually enable it
[18:06:56 CEST] <Timothy_Gu> I know it looks ugly
[18:07:39 CEST] <loki_> can somebody explain me one thing
[18:07:57 CEST] <loki_> maybe it is little offtop... and can be #ffmpeg question.
[18:08:13 CEST] <loki_> i am trying to build ssr using my build of ffmepg libs.
[18:08:23 CEST] <kierank> what's ssr
[18:08:27 CEST] <loki_> ssr = simplescreenrecorder
[18:08:50 CEST] <loki_> ok, now i am really think that it is offtop lol.
[18:09:07 CEST] <loki_> can't get how to point it that i want use my libs and headers.
[18:10:06 CEST] <wm4> if it's not broken, use PKG_CONFIG_PATH (or whatever it was) to point it to the .pc file of your builds
[18:10:45 CEST] <loki_> awww, i will try.
[18:11:05 CEST] <loki_> because i started set up build env under coker :D
[18:11:09 CEST] <loki_> docker *
[18:11:09 CEST] <michaelni> Timothy_Gu, the fading when pressing buttons looks very nice but i think its better to not fade to reduce latency
[18:12:10 CEST] <Timothy_Gu> michaelni: whuc button?
[18:12:12 CEST] <Timothy_Gu> *which
[18:12:26 CEST] <michaelni> Information /Faied Tests /..
[18:13:20 CEST] <Timothy_Gu> michaelni: oh i didn't make that :d
[18:13:30 CEST] <Timothy_Gu> it's already in the css library we are using
[18:13:34 CEST] <Timothy_Gu> (bootstrap)
[18:14:04 CEST] <michaelni> that should probably be changed somehow then
[18:14:21 CEST] <Timothy_Gu> what device are you viewing it on?
[18:14:30 CEST] <Timothy_Gu> I don't see how it can cause latency at all
[18:14:49 CEST] <michaelni> firefox on desktop ubuntu linux
[18:15:05 CEST] <loki_> wm4: so all my pc files are here /home/loki/ffmpeg_clean_build/lib/pkgconfig/
[18:15:38 CEST] <loki_> and i see in configure script information about PKG_CONFIG_PATH
[18:16:15 CEST] <Timothy_Gu> michaelni: same &
[18:18:10 CEST] <wm4> loki_: export PKG_CONFIG_PATH=/home/loki/ffmpeg_clean_build/lib/pkgconfig/
[18:18:24 CEST] <wm4> loki_: you might also need to set LD_LIBRARY_PATH for the runtime case
[18:18:34 CEST] <loki_> need export?
[18:18:42 CEST] <loki_> just var before configure is not right?
[18:18:56 CEST] <wm4> that's equivalent
[18:18:56 CEST] <loki_> i don't see my path in compile proccess at all
[18:19:00 CEST] <loki_> ok
[18:19:04 CEST] <wm4> export just makes it permanent for the rest of the shell
[18:20:18 CEST] <loki_> i tried LD_LIBRARY_PATH before recompiling ssr, but looks it prefers system one
[18:20:25 CEST] <loki_> look like *
[18:20:28 CEST] <michaelni> Timothy_Gu, tried on a 2nd box, same effect when you click on "Passed Tests (1234)" the content fades out and the new in taking about 1second
[18:21:26 CEST] <Timothy_Gu> ok ill try on a 2nd box
[18:23:13 CEST] <Timothy_Gu> btw i finally fixed the stderr box scrollbar this morning :)
[18:23:58 CEST] <loki_> wm4: looks like it totally ignore my settings...
[18:24:15 CEST] <wm4> loki_: maybe it doesn't use pkg-config then
[18:25:59 CEST] <michaelni> Timothy_Gu, also the fade stuff isnt important, whatever it is it shouldnt be hard to fix later so dont waste time on it if you cannot reproduce
[18:28:25 CEST] <Timothy_Gu> michaelni: I can now. Fixing it rigt now.
[18:30:06 CEST] <Timothy_Gu> michaelni: there fixed
[18:30:26 CEST] <michaelni> confirmed, thanks!
[18:38:36 CEST] <loki_> wm4: there no another way to use custom headers and libs?
[18:42:39 CEST] <loki_> i added my lib path into ld.so.conf
[18:42:44 CEST] <wm4> loki_: depends entirely on the build system of the thing you're using
[18:42:47 CEST] <loki_> i see my libs in ldconfig -p
[18:43:05 CEST] <loki_> but looks like programm use old ones again...
[18:53:39 CEST] <Timothy_Gu> Which of these three looks best?
[18:53:41 CEST] <Timothy_Gu> http://104.131.148.213:8083/report/alpha-debian-qemu-gcc-4.7/20150408032905
[18:53:45 CEST] <Timothy_Gu> http://104.131.148.213:8082/report/alpha-debian-qemu-gcc-4.7/20150408032905
[18:53:48 CEST] <Timothy_Gu> http://104.131.148.213:8081/report/alpha-debian-qemu-gcc-4.7/20150408032905
[19:18:17 CEST] <michaelni> Timothy_Gu, 1 or 2 not the 3 that displayes the arguments as a long spagethi
[19:19:56 CEST] <Timothy_Gu> michaelni: meh I'll go with 8081 beause I like the color green
[19:20:08 CEST] <michaelni> sure
[19:47:59 CEST] <Timothy_Gu> michaelni: mail to baptiste sent
[19:51:20 CEST] <wm4> ubitux: are you sure the microdvd remux test is correct?
[19:51:50 CEST] <wm4> ubitux: tests/ref/fate/sub-microdvd-remux contains a 0 byte
[19:51:54 CEST] <Timothy_Gu> michaelni: also ping on the fateserver patch I sent last night
[19:59:10 CEST] <cone-662> ffmpeg 03Carl Eugen Hoyos 07master:79c11388e1f5: lavf/apngenc: Do not print a warning in the normal use-case.
[20:08:16 CEST] <Compn> huehuehue
[20:08:26 CEST] Action: Compn trolls and runs
[20:08:28 CEST] <michaelni> Timothy_Gu, ive given you write access to gil at git.ffmpeg.org:fateserver so you can push the patch if you like, i am no perl developer so my reviewing this would not be that usefull, also you have shell access to the server so you can update it too (the directry is baked by git)
[20:24:05 CEST] <Compn> ehe "out.mp4" either means ffmpeg or mencoder created it
[20:24:24 CEST] <Compn> in my opinion anyhow
[20:24:59 CEST] <Compn> do we still have libfaad in ffmpeg ?
[20:26:40 CEST] <wm4> Compn: no, I used that filename randomly
[20:26:50 CEST] <wm4> and no
[20:27:27 CEST] <rcombs> I have an unfortunate number of files laying around called out.<whatever>
[20:27:40 CEST] <rcombs> I've been trying to remind myself to use more unique names
[20:27:43 CEST] <Daemon404> ... my reandom files have significantly more childish names
[20:27:47 CEST] <Daemon404> random*
[20:29:42 CEST] <wm4> anyway, this file had "encoder         : Lavf56.29.100"
[20:29:51 CEST] <wm4> is there a way to find out what encoded the aac track?
[20:30:08 CEST] <wm4> and why is trac so slow
[20:33:26 CEST] <michaelni> wm4, has it become slower or was it always slow ?
[20:33:49 CEST] <michaelni> trac is not exactly fast nor was it ever ...
[20:33:50 CEST] <wm4> don't know, I noticed this in the last days...
[20:33:58 CEST] <wm4> I'm pretty sure it used to be much faster
[20:34:56 CEST] <michaelni> well i just randomly clicked around reading tickets and listing seem quite responsive
[20:37:16 CEST] <wm4> reloading a page takes at least 5 seconds or so
[20:38:38 CEST] <michaelni> about 2 sec here
[20:41:16 CEST] <michaelni> anyway beastd wanted to upgrade trac, maybe that will make it faster but i suspect it will take a while before he has time
[20:41:32 CEST] <michaelni> that is IIRC
[20:48:25 CEST] <Compn> possibly hex editor or strings (or media info)
[20:48:34 CEST] <cone-662> ffmpeg 03wm4 07master:c4d37cd9ef6e: matroskadec: export cover art correctly
[20:48:35 CEST] <cone-662> ffmpeg 03Michael Niedermayer 07master:8e1717cf12f8: Merge commit 'c4d37cd9ef6e374bb888f6273259b10fac5bd909'
[20:56:01 CEST] <cone-662> ffmpeg 03Diego Biurrun 07master:bb815dfc38b8: g2meet: K&R formatting cosmetics
[20:56:02 CEST] <cone-662> ffmpeg 03Michael Niedermayer 07master:edaca0812a05: Merge commit 'bb815dfc38b8ef7a89d6b9684ce0cdc296385d6d'
[21:09:25 CEST] <Timothy_Gu> michaelni: same slowness observed here. It takes literally 30 seconds to file a new ticket
[21:09:31 CEST] <Timothy_Gu> (or more)
[21:09:51 CEST] <Timothy_Gu> just viewing seems fine
[21:10:55 CEST] <Timothy_Gu> Fixed one last sorting problem& Now working on adding minirep/log
[21:18:24 CEST] <michaelni> if someone has an idea what could cause the trac slowness, ping me
[21:19:54 CEST] <michaelni> hmm maybe one of the spam detection services takes a long time to reply so creation of new tickets is delayed but thats just guessing ive not investigated
[21:22:36 CEST] <kierank> libffmpeg.so on android with --enable-gpl is a violation right?
[21:22:50 CEST] <Daemon404> android apps can be gpl
[21:22:55 CEST] <Daemon404> iirc
[21:23:11 CEST] <BtbN> What's libffmpeg.so?
[21:23:30 CEST] <Daemon404> similar to chrome's ffmpegsumo probably
[21:23:38 CEST] <Daemon404> just shvoing it in one lib
[21:23:53 CEST] <Daemon404> also: is this yt-dl thread on the ML a joke patch set or what?
[21:23:57 CEST] <Daemon404> utterly ridiculous
[21:25:12 CEST] <BtbN> Propably serious, and someone who will be upset once he realises that it will be rejected.
[21:25:35 CEST] <kierank> BtbN: problem is that it'll get merge
[21:25:59 CEST] <BtbN> A format that calls youtube-dl, what?
[21:26:16 CEST] <BtbN> Via system()?
[21:26:26 CEST] <kierank> yes
[21:27:22 CEST] <nevcairiel> its just a stupid idea, it just outputs a URL doesn't it? why not shove that into ffmpeg directly instead of requiring some stupid demuxer with lots of potential problems?
[21:27:47 CEST] <BtbN> It also combines dash elements iirc
[21:28:43 CEST] <nevcairiel> it looks like it just outputs URLs
[21:29:09 CEST] <nevcairiel> from the patch
[21:29:10 CEST] <wm4> youtube-dl can return quite advanced information via json
[21:29:31 CEST] <wm4> things like multipart video or extra subtitles
[21:29:39 CEST] <Daemon404> id wager it has to chaneg a lot as sites change
[21:29:45 CEST] <nevcairiel> it doesnt make any use of that
[21:30:05 CEST] <nevcairiel> it just wants to extract one url and open  a new demuxer context inside the demuxer with it
[21:30:27 CEST] <nevcairiel> (which smells like terrible design)
[21:30:31 CEST] <wm4> and I'd say most of these advanced things should be handled on a higher level too
[21:30:38 CEST] <wm4> why force everything to be a demuxer
[21:31:25 CEST] <Daemon404> duh.
[21:31:28 CEST] <BtbN> Great, it looks like DASH stops working after a while because the JavaScript player calculates the timestamps using floats with seconds in them. So after a not too long while the floating point imprecision breaks it.
[21:33:12 CEST] <kierank> BtbN: which player
[21:33:27 CEST] <BtbN> dash.js git master in chrome.
[21:33:33 CEST] <kierank> hahahah
[21:33:34 CEST] <kierank> hahaha
[21:33:36 CEST] <kierank> hahahah
[21:34:02 CEST] <BtbN> For some reason it only breaks "tuning in"
[21:34:16 CEST] <BtbN> If you are already playing the stream, it continues to work seemingly forever.
[21:35:05 CEST] <kierank> please open a pull request
[21:35:11 CEST] <kierank> slash troll
[21:35:17 CEST] <kierank> will be hillarious
[21:35:30 CEST] <BtbN> I'm not entirely sure if that's realy what's happening.
[21:35:42 CEST] <BtbN> As the time it starts happening varies a lot
[21:36:30 CEST] <Daemon404> BtbN, js is double, not float
[21:38:01 CEST] <BtbN> Now it doesn't feel like breaking at all, great.
[21:44:31 CEST] <Daemon404> "Use fork() + exec() directly to execute exactly the command you want. Even
[21:44:34 CEST] <Daemon404> better, use posix_spawn(), it takes care of a lot of details that people
[21:44:35 CEST] <Daemon404> oh fuck right off
[21:44:37 CEST] <Daemon404> usually get wrong with fork+exec."
[21:44:38 CEST] <Daemon404> kierank is right
[21:45:05 CEST] <kierank> what am I right about today :)
[21:45:20 CEST] <Daemon404> youtube-dl retardedness
[21:45:37 CEST] <Daemon404> literal review by nicholas saying "Dont use system, use exec"
[21:46:00 CEST] <BtbN> But fork doesn't work on Windows!!
[21:53:30 CEST] <Daemon404> there i replied
[21:53:39 CEST] <Daemon404> so you guys cant point and say "but you never said anythign at the time!"
[22:25:34 CEST] <wm4> "youtube-dl -J $url | ffmpeg -f youtubedl -i -"
[22:25:37 CEST] <wm4> what the fuck
[22:25:56 CEST] <Daemon404> wa
[22:25:57 CEST] <Daemon404> t
[22:27:04 CEST] <wm4> I'd probably reply something flame-inducing, but I'd rather go to bed now
[22:27:44 CEST] <BtbN> Why does ffmpeg have to be able to download youtube videos by itself anyway?
[22:27:51 CEST] <Daemon404> thats exactly my point
[22:27:55 CEST] <Daemon404> it doesnt belong in avformat
[22:27:56 CEST] <Daemon404> its fucktarded.
[22:28:13 CEST] <BtbN> Let vlc or mplayer or whatever handle that.
[22:28:46 CEST] <Daemon404> BtbN, same reason we have a dir listing api and http server
[22:28:51 CEST] <Daemon404> in av"format"
[22:29:31 CEST] <wm4> BtbN: mpv (which is based on mpv) actually can call youtube-dl -J
[22:29:45 CEST] <wm4> but it does this on exactly the opposite layer than demuxers
[22:29:45 CEST] <Daemon404> based on mplayer you mean
[22:29:51 CEST] <wm4> err, yes
[22:30:02 CEST] <Daemon404> vlc can too
[22:30:04 CEST] <Daemon404> it has its own thing
[22:30:21 CEST] <wm4> yeah, Lua scripts... probably on a similar layer
[22:30:31 CEST] <wm4> and NOT as a fucking demuxer
[22:31:47 CEST] <Compn> would you be happier with libavstream or something ?
[22:31:56 CEST] <Compn> and then move all http network code into there ?
[22:32:30 CEST] <Compn> the way people complain around here like nothing can be changed is silly. we can change it all, api breakages be damned full speed ahead.
[22:34:23 CEST] <BtbN> Wouldn't call it libavstream, but rather libffmpeg or something, and move most of the functionality of the ffmpeg cli program there, too.
[22:34:49 CEST] <BtbN> So it's a higher-level, media-player-framework like, library.
[22:35:17 CEST] <Compn> whatever makes developers more happy
[22:35:54 CEST] <wm4> BtbN: agreed
[22:51:14 CEST] <cone-662> ffmpeg 03wm4 07master:48f27b78f4bc: microdvd: do not export framerate hint as subtitle packet
[22:51:15 CEST] <cone-662> ffmpeg 03Michael Niedermayer 07master:32e06c485be9: avcodec/h264_ps: Move truncation check from VUI to SPS
[23:29:48 CEST] <Prelude2004c> hey guys.. sorry to bother again but i dont think i got a replay yet that made sense so i am trying again :)
[23:30:09 CEST] <Prelude2004c> does anyone know why ffmpeg has a problem going over 120fps on multi outputs ( eg. 5 segments at 60fps each )
[23:30:22 CEST] <Prelude2004c> has a problem using CPU / GPU  too
[23:30:36 CEST] <Prelude2004c> if i run seperate ffmpeg sessions ( 1 for each stream ) it doesn't have any issues
[00:00:00 CEST] --- Thu Apr  9 2015