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

[burek]

[00:00:01 CEST] <wm4> rcombs: which one? libyami? qsv? gstreamer?
[00:00:04 CEST] <rcombs> and then like 5 ways to get a display for vaapi (X? DRM? Wayland?)
[00:00:09 CEST] <rcombs> wm4: any and all of the above
[00:00:14 CEST] <rcombs> (I was thinking qsv)
[00:00:28 CEST] <nevcairiel> but of course Microsoft actually has an interest to see things work on their platform, so they push vendors to support "the" API, and not build their own
[00:00:36 CEST] <nevcairiel> somewhat surprised there is no unified encoding API yet =p
[00:00:38 CEST] <wm4> yeah, of course there has to be support for 2 windowing systems (X11/wayland), as well as raw access (DRM)
[00:00:49 CEST] <rcombs> more than 2
[00:00:53 CEST] <rcombs> I don't remember the others
[00:01:01 CEST] <wm4> and add some non-working OpenGL interop
[00:01:09 CEST] <nevcairiel> speaking of OpenGL
[00:01:09 CEST] <wm4> (for which vaapi has 2 or so sub-APIs)
[00:01:15 CEST] <nevcairiel> how the f' do you get vsync to work reliably on linux
[00:01:34 CEST] <rcombs> nevcairiel: I'm guessing the answer is "you DON'T"
[00:01:36 CEST] <wm4> don't use a compositor, pray, if you use intel, there might be obscure xorg.conf options
[00:01:56 CEST] <nevcairiel> there is like 3 opengl extensions that give you a vsync option, none of which seem to work properly
[00:02:08 CEST] <wm4> there are 2 problems
[00:02:20 CEST] <rcombs> all that but you still have to parse the bitstream yourself
[00:02:25 CEST] <wm4> the simple one is requesting double buffering (so swapbuffers does an atomic flip without tearing)
[00:02:27 CEST] <rcombs> or if you're encoding, write it yourself
[00:02:32 CEST] <wm4> the hard part is having a driver that actually works
[00:03:44 CEST] <nevcairiel> its that then probably
[00:04:31 CEST] <nevcairiel> another fun one for linux, fullscreen windows that only occupy one screen, and dont span all of them
[00:04:32 CEST] <wm4> Intel drivers have multiple rendering backends
[00:04:40 CEST] <wm4> there's something called SNA etc.
[00:04:44 CEST] <nevcairiel> apparently my code using window manager hints works on some machines, and not on others :d
[00:04:54 CEST] <wm4> these are internal driver frameworks, but you can bet the sane, working one isn't enabled by default
[00:05:54 CEST] <philipl> http://forum.kodi.tv/showthread.php?tid=231955
[00:06:07 CEST] <philipl> There's a new way!
[00:06:10 CEST] <philipl> A better way!
[00:06:24 CEST] <philipl> This time they got it right. They promise.
[00:06:44 CEST] <nevcairiel> vaapi with egl does look like they actually put the required APIs into place this time
[00:07:00 CEST] <nevcairiel> sadly switching the entire code from glx to egl is a bit annoying
[00:07:31 CEST] <wm4> inevitable big buck bunny screenshot
[00:07:31 CEST] <nevcairiel> especially since egl isnt supported everywhere yet
[00:08:22 CEST] <wm4> well, vaapi is intel, and intel drivers support egl
[00:08:40 CEST] <nevcairiel> would still mean i need two code paths, egl and glx
[00:08:52 CEST] <nevcairiel> that post is full of wtf's though
[00:09:00 CEST] <wm4> didn't nvidia move towards egl as well? but yeah, having them both is still annoying
[00:09:03 CEST] <nevcairiel> bugs here and there, install special versions from this personal dropbox
[00:09:19 CEST] <wm4> I wonder of the new vaapi EGL interop is documented anywhere
[00:09:22 CEST] <wm4> most likely not
[00:09:54 CEST] <nevcairiel> __gb__ talked about it some time ago, but if you dont count .h files as docs, then probably not
[00:11:02 CEST] <wm4> have fun guessing: http://cgit.freedesktop.org/vaapi/libva/tree/va/egl/va_egl.h
[00:11:07 CEST] <wm4> (this one is old though)
[00:11:11 CEST] <nevcairiel> As a primarily windows user, this whole linux video topic keeps me entertained at least!
[00:11:41 CEST] <wm4> my main problems are with windows, but whatever
[00:12:08 CEST] <nevcairiel> just dont try to use opengl on windows and you're fine
[00:12:16 CEST] <philipl> nvidia supports egl/x11 on their latest drivers - dunno how well it really works.
[00:12:23 CEST] <wm4> nevcairiel: then I have to maintain multiple renderers
[00:13:01 CEST] <nevcairiel> cross platform is a bitch, isnt it
[00:13:38 CEST] <wm4> and even with native d3d9, it doesn't seem to be possible to get the dxva YUV data without copying back to the CPU
[00:13:56 CEST] <wm4> there's no fullscreen mode, it's just some hack (if the window "covers" the screen it's fullscreen?)
[00:14:09 CEST] <nevcairiel> d3d has a proper fullscreen exclusive mode
[00:14:10 CEST] <wm4> there's no good C99 compiler, despite being a 16 year old standard
[00:15:25 CEST] <philipl> As you know, many new C99 features are highly controversial.
[00:15:30 CEST] <philipl> *sigh*
[00:15:46 CEST] <nevcairiel> and getting the yuv data from a d3d9 surface onto a d3d9 texture can be a bit tricky because d3d9 textures have no nv12 mode
[00:16:21 CEST] <nevcairiel> (and textures is what you want for further rendering)
[00:16:43 CEST] <wm4> there's a format that could serve as nv12, but it's not supported by any hw
[00:16:54 CEST] <wm4> (which makes it hilariously hard to render nv12 from a normal texture)
[00:17:12 CEST] <wm4> though later d3d versions seem to add such a format
[00:17:14 CEST] <nevcairiel> if you care about quality, you can get it as 4:2:2 with a nearest neighbor, so you can reverse it if you wanted to
[00:17:38 CEST] <nevcairiel> if you dont care, you can just get it as 4:2:2 using bilinear =p
[00:17:52 CEST] <nevcairiel> and yeah d3d11 fixes that
[00:17:55 CEST] <wm4> why 4:2:2?
[00:17:57 CEST] <nevcairiel> 10 maybe already
[00:18:04 CEST] <nevcairiel> dunno, because there is a texture format for that
[00:18:58 CEST] <nevcairiel> I think what MS expects you to usually do is just use DXVA to also scale and convert the surface first, so you just get a RGB surface out at the end, which you can just convert into a texture
[00:19:04 CEST] <nevcairiel> ie. what the EVR does
[00:19:20 CEST] <wm4> yeah but then you get random color levels
[00:20:34 CEST] <nevcairiel> you'll want to invoke DXVA at that point anyway for deinterlacing, but of course you can do that without scaling or conversion if you so desire
[00:20:55 CEST] <nevcairiel> speaking of, it was something I wanted to explore, adding deint to my code before the copy-back to sysmem for transcoding or so
[00:21:07 CEST] <nevcairiel> I should keep a better task list
[00:21:33 CEST] <wm4> what does the deinterlacer output?
[00:21:47 CEST] <nevcairiel> same format, just twice as many frames
[00:21:57 CEST] <nevcairiel> (if you want it to)
[00:22:22 CEST] <wm4> better than vdpau, which essentially conflates deint, scaling, and color conversion in a single function
[00:22:33 CEST] <nevcairiel> dxva can do that too
[00:22:37 CEST] <nevcairiel> but it doesnt have to
[00:22:48 CEST] <nevcairiel> you can just NO-OP the th ings you dont want happening
[00:25:17 CEST] <nevcairiel> anyway time to sleep
[00:28:34 CEST] <kierank> wm4, D404|Ghetto; other api test ideas?
[00:28:46 CEST] <kierank> swresample, avresample?
[00:36:43 CEST] <wm4> hm
[00:37:06 CEST] <wm4> could start with testing various combinations of conversions, maybe
[00:37:21 CEST] <wm4> testing a matrix of input and output sample rates / formats / channel layouts
[00:37:43 CEST] <kierank> anything else you want tested in libavcodec or libavformat?
[00:38:23 CEST] <wm4> same could be done for libswscale
[00:38:35 CEST] <wm4> and there's still a lot to test in lavc
[00:38:46 CEST] Action: wm4 trying to think anything concrete
[00:39:09 CEST] <wm4> it's a bit hard to recall these if you haven't just hit one of those strange issues
[00:39:32 CEST] <wm4> oh right, I think the test which flushes the decoder etc. should be refined (it was part of the seek test)
[00:52:58 CEST] <cone-613> ffmpeg 03Michael Niedermayer 07master:503ec7139f88: ffmpeg: Fix cleanup with ost = NULL
[00:52:59 CEST] <cone-613> ffmpeg 03Michael Niedermayer 07master:4bde1a4a374e: avcodec/mpegvideo: Fix null pointer dereference of picture array
[01:02:56 CEST] <cone-613> ffmpeg 03Alexandra Hájková 07master:c571424c7f62: asfdec: prevent memory leaks found with Coverity Scan
[01:02:57 CEST] <cone-613> ffmpeg 03Michael Niedermayer 07master:db1ab7e5af6a: Merge commit 'c571424c7f6276a6374e1784ce2a33d4b6a4292d'
[01:30:54 CEST] <cone-613> ffmpeg 03Luca Barbato 07master:8e373fe04881: hevc: Factor out the pixel format mapping from the sps parser
[01:30:55 CEST] <cone-613> ffmpeg 03Michael Niedermayer 07master:e17a459af06e: Merge commit '8e373fe048812a25b238ea60a7052b8c07639a42'
[01:41:46 CEST] <cone-613> ffmpeg 03Luca Barbato 07master:32c8d89c036b: hevc: Print the non-supported chroma_format_idc
[01:41:47 CEST] <cone-613> ffmpeg 03Michael Niedermayer 07master:3edc6d1cd9ef: Merge commit '32c8d89c036b0e75ece74aea638df587099def0b'
[02:00:17 CEST] <cone-613> ffmpeg 03Luca Barbato 07master:a5a6a786bfeb: mp3: Forward seeking errors
[02:00:18 CEST] <cone-613> ffmpeg 03Michael Niedermayer 07master:96e1cc3f8b6b: Merge commit 'a5a6a786bfebb85c269abc25559fd71963983581'
[02:13:10 CEST] <cone-613> ffmpeg 03Ivan Uskov 07master:ce91bab70f69: libavcodec/qsv.c: Issue fixed: QSV engine does not release display handler under linux platform.
[02:54:58 CEST] <cone-613> ffmpeg 03James Almer 07master:39a04ebcaf04: avutil/mem_internal: add missing header includes
[05:07:35 CEST] <cone-613> ffmpeg 03Ronald S. Bultje 07master:dfc58584b4e5: vf_ssim: x86 simd for ssim_4x4xN and ssim_endN.
[10:51:04 CEST] <bove> I'm writing a new demuxer based on a cpp file reader I got, but can't understand how it finds the specific fields in the header. Can the fields simply be read the same order as the class is defined?
[11:17:27 CEST] <wm4> bove: uh, what class? ffmpeg has no classes
[11:17:58 CEST] <bove> Yes, I just realized I have to go from cpp to c
[11:25:05 CEST] <bove> wm4: Here's the cpp version: http://pastebin.com/6tzTc3y3 Not sure where to start ...
[11:25:35 CEST] <wm4> haha
[11:25:59 CEST] <wm4> fread()ing a class from a file
[11:26:03 CEST] <wm4> that's not going to work
[11:26:24 CEST] <wm4> even if the class happens to be POD (or whatever the C++ term is), that's not portable
[11:26:29 CEST] <bove> Not even if I define a matching struct?
[11:26:31 CEST] <wm4> you have to read the fields one by one
[11:26:34 CEST] <wm4> no
[11:26:55 CEST] <bove> ok
[11:27:13 CEST] <wm4> there are functions to read data of various types and sizes from a avstream
[11:27:20 CEST] <wm4> (or from memory)
[11:27:26 CEST] <BtbN> Well, you can define a packed struct, but i don't think that's portable.
[11:27:56 CEST] <BtbN> i have seen an mpeg-ts parser that worked that way
[11:27:58 CEST] <wm4> so e.g. avio_rl32() read a little-endian 32 bit integer
[11:28:22 CEST] <wm4> BtbN: yeah, in ffmpeg we just don't do this
[11:28:25 CEST] <wm4> too many subtle problems
[11:28:39 CEST] <BtbN> isn't it also gcc magic, and not standard C?
[11:28:59 CEST] <wm4> many compilers allow you to specify packed structs
[11:29:03 CEST] <wm4> (in different ways)
[11:29:09 CEST] <wm4> but then you still have to deal with endian issues
[11:29:19 CEST] <wm4> and who knows what other problems
[11:30:23 CEST] <bove> So I guess I should start by finding the byte offset for the fields I want?
[11:31:16 CEST] <wm4> why? just read them sequentially from the stream
[11:33:27 CEST] <bove> wm4: I assume a int32_t will be 32 bytes, but how is fileHeader(); or void print(); represented? Not at all?
[11:34:46 CEST] <wm4> not sure what you're asking about
[11:35:05 CEST] <bove> Neither am I ...
[11:38:05 CEST] <bove> I'm basing the demuxer on yuv4pipedec, but not sure what will arrive first in AVFormatContext *s
[13:01:32 CEST] <durandal_1707> bove: bytes arrive in order they are in file
[13:09:48 CEST] <bove> durandal_1707: Which object holds the values in xxxxx_read_header(AVFormatContext *s)?
[13:11:10 CEST] <durandal_1707> s->pb you read from it with avio_ functions
[13:11:29 CEST] <bove> durandal_1707: what kind of object is that?
[13:12:05 CEST] <durandal_1707> too much cpp
[13:13:08 CEST] <durandal_1707> avio_rb32 reads directly from stream
[13:13:39 CEST] <bove> ok
[13:13:42 CEST] <durandal_1707> and returns integer
[13:14:45 CEST] <Sucharitha> I was calling a couple of functions of ffmpeg from my code and I want to see the errors that are logged. How can I do that?
[13:15:06 CEST] <durandal_1707> avio_read reads bytes how much you specify
[13:17:03 CEST] <Sucharitha> durandal_1707:  I was calling a couple of functions of ffmpeg from my code and I want to see the errors that are logged. Do you know how to do that? Sorry for bothering .
[13:22:30 CEST] <cone-562> ffmpeg 03Michael Niedermayer 07master:bd27dc910248: ffmpeg: Fix deallocating input threads with partly failed file allocation
[13:22:30 CEST] <cone-562> ffmpeg 03Michael Niedermayer 07master:fd4c87fa3bec: ffmpeg: Fix crash with ost->last_frame allocation failure
[13:23:45 CEST] <bove> durandal_1707: Can I do avio_r1024 to read a char[128]?
[13:24:07 CEST] <J_Darnley> That probably isn't a defined function.
[13:24:29 CEST] <J_Darnley> There will be one to read N byte which you should use
[13:25:11 CEST] <bove> is avio_rb32 in bits or bytes?
[13:25:16 CEST] <J_Darnley> 32
[13:25:19 CEST] <J_Darnley> bits
[13:26:58 CEST] <bove> thanks. I'll just skip TC and tapename for now ...
[13:27:31 CEST] <J_Darnley> Yes, he said it just above: avio_read
[14:52:03 CEST] <bove> When I try to compile the demuxer, I get a conversion error on strncmp in the probe function. It's copy-pasted from yuv4mpeg, so I don't see why it should be different :\ http://pastebin.com/mnAbbkue
[15:33:52 CEST] Action: D404|Ghetto wonders if there is a reasonable way to cut h264 elementary streams
[15:40:44 CEST] <bove> How do I register a new demuxer? I've added it in libavformat/allformats.c and libavformat/Makefile, but configure says --enable-muxer=mistika did not match anything
[15:44:22 CEST] <bove> Ooops. Didn't realize I only had a demuxer ...
[16:12:26 CEST] <durandal_1707> bove: is mistika_magic string?
[16:12:49 CEST] <cone-562> ffmpeg 03Michael Niedermayer 07master:0ff4953e1be5: avfilter/vf_ssim: Fix "incompatible pointer type" warnings
[16:12:50 CEST] <cone-562> ffmpeg 03Michael Niedermayer 07master:15629129dde7: avformat/mov: Fix deallocation when MOVStreamContext failed to allocate
[16:12:51 CEST] <durandal_1707> You do not need own bswap function
[16:12:51 CEST] <cone-562> ffmpeg 03Michael Niedermayer 07master:6e80fe1ecd98: ffmpeg: Fix cleanup after failed allocation of output_files
[16:13:15 CEST] <bove> durandal_1707: Yes (but only numbers)
[16:13:54 CEST] <durandal_1707> bove: there is avio_rl32 no need for own bswap stuff
[16:13:56 CEST] <bove> I think I managed to compile it now. Waiting for ffmpeg to be done with all the codecs ...
[16:14:53 CEST] <bove> Guess I should disable all codecs but rawvideo on next test compile ...
[16:15:41 CEST] <bove> is avio_rb for big endian?
[16:19:00 CEST] <durandal_1707> yes
[16:19:25 CEST] <durandal_1707> it reads int in big endian order
[16:21:12 CEST] <bove> hehe. I've learned a lot today :p
[16:24:23 CEST] <bove> durandal_1707: What kind of number does avg_frame_rate hold?
[16:27:53 CEST] <durandal_1707> probably rational
[16:59:34 CEST] <D404|Ghetto> damn i lost vf_example.c in my buffer
[16:59:42 CEST] <D404|Ghetto> :(
[17:00:09 CEST] <J_Darnley> vf_example: http://codepad.org/OQjPwIcg
[17:00:22 CEST] <D404|Ghetto> thx
[17:00:37 CEST] <nevcairiel> if that is supposedly so enlightening, why is it not in the docs folder
[17:00:59 CEST] <J_Darnley> Because it is incomplete and I never got around to finishing it.
[17:02:30 CEST] <J_Darnley> It doesn't touch on init vs. config_props
[17:03:09 CEST] <J_Darnley> I don't think I explain Pads at all
[17:03:26 CEST] <D404|Ghetto> do i need to care for such a simpel filter as reverse?
[17:04:00 CEST] <J_Darnley> Probably not.  YOu just buffer whatever frames you get then return them when needed, I guess.
[17:04:38 CEST] <D404|Ghetto> aye
[17:06:05 CEST] <J_Darnley> My first point (about init vs. config_props) is that you cannot know colour space when init is called so the writing_filters.txt file is wrong about "allocating buffers" when it talks about init.
[17:06:24 CEST] <nevcairiel> maybe you only support one color space
[17:06:24 CEST] <D404|Ghetto> i dont care about colorspace
[17:06:35 CEST] <D404|Ghetto> cant i just say "let it all work" ?
[17:06:46 CEST] <J_Darnley> Yes, don't use config_props
[17:06:51 CEST] <D404|Ghetto> right ok
[17:07:29 CEST] <J_Darnley> Oh wait, there's also query_format!  (I don't think you need to worry about that either D404|Ghetto)
[17:09:27 CEST] Action: J_Darnley goes back to making vim do what he wants
[17:13:58 CEST] <D404|Ghetto> J_Darnley: it doesnt add it to the filters list
[17:14:09 CEST] <D404|Ghetto> ffmpeg -filters doesnt list it
[17:14:35 CEST] <J_Darnley> Becuase that is just the C file, I can't change the makefile for you.
[17:14:46 CEST] <D404|Ghetto> no i did all that
[17:15:02 CEST] <D404|Ghetto> it is compiled during configure and linked.
[17:15:08 CEST] <D404|Ghetto> durign build*
[17:15:43 CEST] <J_Darnley> Did you add it to all_filters.c?
[17:15:57 CEST] <D404|Ghetto> sure did
[17:16:01 CEST] <J_Darnley> ...
[17:16:29 CEST] <D404|Ghetto> +OBJS-$(CONFIG_REVERSE_FILTER)                += vf_reverse.o
[17:16:32 CEST] <D404|Ghetto> +    REGISTER_FILTER(REVERSE,        reverse,        vf);
[17:16:41 CEST] <D404|Ghetto> names in .c file all reflect this.
[17:16:49 CEST] <J_Darnley> git diff
[17:17:02 CEST] <D404|Ghetto> that is the entire diff, not including the new file
[17:17:03 CEST] Action: J_Darnley needs to relax
[17:17:12 CEST] <J_Darnley> sorry that was the wrong window
[17:17:16 CEST] <D404|Ghetto> o
[17:18:31 CEST] <J_Darnley> make distclean?
[17:19:34 CEST] <J_Darnley> Weird.  That is all you should need.  Makefile, allfilters, your own files.
[17:20:05 CEST] <J_Darnley> I wonder if you need to run configure again also.
[17:20:14 CEST] <D404|Ghetto> i did
[17:20:18 CEST] <D404|Ghetto> didnt distclean tho
[17:23:54 CEST] <D404|Ghetto> J_Darnley: nope.
[17:24:00 CEST] <D404|Ghetto> didnt help.
[17:24:06 CEST] <J_Darnley> ugh
[17:24:18 CEST] <durandal_1707> its ff_vf_reverse?
[17:24:36 CEST] <D404|Ghetto> yes
[17:24:41 CEST] <D404|Ghetto> and name is set to reverse too.
[17:25:16 CEST] <D404|Ghetto> AVFilter ff_vf_reverse = { .name        = "reverse",
[17:27:12 CEST] <durandal_1707> and when registering its also under vf in last column?
[17:27:35 CEST] <D404|Ghetto> 17:16 <@D404|Ghetto> +    REGISTER_FILTER(REVERSE,        reverse,        vf);
[17:30:51 CEST] <durandal_1707> its built?
[17:31:57 CEST] <D404|Ghetto> [AVFilterGraph @ 0x838880] No such filter: 'reverse'
[17:32:02 CEST] <D404|Ghetto> durandal_1707: i already said that
[17:32:04 CEST] <D404|Ghetto> please read.
[17:32:51 CEST] <D404|Ghetto> oh fuck me
[17:32:59 CEST] <D404|Ghetto> it eas loading the system libavfilter
[17:33:10 CEST] <durandal_1707> ffmpeg -h filter=reverse
[17:33:16 CEST] <D404|Ghetto> because apparently there is no mechanism to do it properly
[17:33:20 CEST] <D404|Ghetto> (libtool does it properly)
[17:33:38 CEST] <durandal_1707> static build...
[17:34:50 CEST] <D404|Ghetto> ... or the build system could just do it properly
[17:34:56 CEST] <D404|Ghetto> like every other one does
[17:36:01 CEST] <D404|Ghetto> it's the same reason you have to screw with LD_LIBRARY_PATH to even run FATE on a shared build 
[17:38:18 CEST] <J_Darnley> What exactly does libtool do (other than spam your terminal with text)?
[17:39:56 CEST] <cone-562> ffmpeg 03Zhang Rui 07master:fcbea93cf877: avutil/fifo: Fix the case where func() returns less bytes than requested in av_fifo_generic_write()
[17:43:57 CEST] <D404|Ghetto> eh wtf
[17:44:04 CEST] <D404|Ghetto> ff_request_frame never returns EOF??
[17:45:35 CEST] <J_Darnley> ... that doesn't surprise me.
[17:45:54 CEST] <D404|Ghetto> how do i find the end then?
[17:46:48 CEST] <D404|Ghetto> i put in a debug statement
[17:46:53 CEST] <D404|Ghetto> and a clip with 900 frames
[17:46:58 CEST] <D404|Ghetto> keeps going to finite
[17:47:01 CEST] <D404|Ghetto> infinite*
[17:47:11 CEST] <D404|Ghetto> ff_request_frame called over 12k times before i killed it
[17:47:35 CEST] <J_Darnley> I honestly have no idea.  I returned errors from filter_frame but still get called 3300 more times.
[17:48:51 CEST] <D404|Ghetto> it seems to return -11 on every single call.
[17:48:53 CEST] <D404|Ghetto> even for frame 0
[17:49:35 CEST] <D404|Ghetto> ... that seems to be AVERROR(EAGAIN)
[17:49:36 CEST] <D404|Ghetto> what the shit?
[17:49:45 CEST] <D404|Ghetto> async i guess...?
[17:49:59 CEST] <nevcairiel> sounds like the source didnt tell it about eof and the sink still wants more frames
[17:50:18 CEST] <D404|Ghetto> no its -11 from the very first frame
[17:51:09 CEST] <D404|Ghetto> 5365838 calls later
[17:51:11 CEST] <D404|Ghetto> still -11
[17:51:23 CEST] <nevcairiel> something is wrong in your thingy :)
[17:52:03 CEST] <D404|Ghetto> this is J_Darnley's example filter
[17:57:58 CEST] <cone-562> ffmpeg 03Ronald S. Bultje 07master:ae4c9ddebc32: vf_psnr: sse2 optimizations for sum-squared-error.
[17:59:32 CEST] <D404|Ghetto> looks like it needs some crap to return non-eof errors inside the liip
[17:59:35 CEST] <D404|Ghetto> loop
[17:59:37 CEST] <D404|Ghetto> what amazng design
[18:00:10 CEST] <D404|Ghetto> i dunno
[18:00:21 CEST] <D404|Ghetto> i cant believe how compelx this is for a simple filter
[18:00:42 CEST] <nevcairiel> Personally I find other people have vastly different ideas of "complex"
[18:00:58 CEST] <nevcairiel> I must have just seen too much corporate code in my time
[18:01:12 CEST] <J_Darnley> :noh
[18:01:22 CEST] <D404|Ghetto> lavfi seems to push much of the complexity onto the filter writer
[18:01:25 CEST] <D404|Ghetto> rather than handling it itself
[18:01:38 CEST] <D404|Ghetto> tons of copypasta
[18:03:38 CEST] <D404|Ghetto> reading ubitux's txt again
[18:03:46 CEST] <D404|Ghetto> looking like i dotn fucking wanna do this, again
[18:04:45 CEST] <bove> How can I convert a framerate from double (25.0) to AVRational?
[18:05:12 CEST] <nevcairiel> we have a function for that, dont we
[18:05:21 CEST] <bove> I suspect so ...
[18:05:22 CEST] <J_Darnley> Probably, try reading rational.h
[18:05:26 CEST] <D404|Ghetto> .... fuck
[18:05:28 CEST] <D404|Ghetto> fuck lavfi
[18:05:30 CEST] <D404|Ghetto> i give uop
[18:05:36 CEST] <D404|Ghetto> i cannot be arsed to figure its shit out
[18:05:39 CEST] <D404|Ghetto> piping it is.
[18:06:50 CEST] <BBB> lol lol
[18:06:57 CEST] <BBB> D404|Ghetto: heres how my filter writing works
[18:07:00 CEST] <BBB> D404|Ghetto: learn from it
[18:07:08 CEST] <BBB> D404|Ghetto: you post your pipe script for inclusion on ffmpeg-devel
[18:07:23 CEST] <BBB> D404|Ghetto: and you wait for durandal_1707 to flame/troll you and tell him to write a filter for you then
[18:07:27 CEST] <BBB> $$profit
[18:07:30 CEST] <D404|Ghetto> lol
[18:07:37 CEST] <BBB> worked for me ;)
[18:07:40 CEST] <D404|Ghetto> ive written filters for nmerous framworks...
[18:07:44 CEST] <D404|Ghetto> lavfi is by and far away the worst
[18:07:49 CEST] <D404|Ghetto> and the only i consistently say "fuck it"
[18:07:59 CEST] <BBB> I have no opinion
[18:08:10 CEST] <BBB> I dont understand the complexity of any of these supposedly frameworks
[18:08:47 CEST] <BBB> michaelni: ty for pushing my patches
[18:11:31 CEST] <durandal_1707> D404|Ghetto: you don't need request frame for reverse filter
[18:11:47 CEST] <D404|Ghetto> absolutely nothing made this clear
[18:12:29 CEST] <durandal_1707> Acttually only to return left queue on eof
[18:13:10 CEST] <D404|Ghetto> i can no langer be arsed
[18:13:11 CEST] <D404|Ghetto> longer*
[18:13:24 CEST] <D404|Ghetto> i asked my coworker to see if theyll write it
[18:13:31 CEST] <D404|Ghetto> as theyve doen lavfi before
[18:13:35 CEST] <D404|Ghetto> libav's lavfi mind you
[18:13:39 CEST] <D404|Ghetto> which id probably 9000x different
[18:14:03 CEST] <J_Darnley> before you delete things in disgust can you send me your file?
[18:14:18 CEST] <D404|Ghetto> i didnt modify your example.c much
[18:14:31 CEST] <D404|Ghetto> i added a check for ret < 0 && ret != AVERROR_EOF in teh do{} loop
[18:14:35 CEST] <D404|Ghetto> and changed the name
[18:15:26 CEST] <michaelni> iam interrested too in code, can you post a patch ?
[18:15:31 CEST] <J_Darnley> Did you actually get on to buffering frames?
[18:15:46 CEST] <D404|Ghetto> no.
[18:15:50 CEST] <D404|Ghetto> michaelni: he pasted it above
[18:15:54 CEST] <D404|Ghetto> it's already here.
[18:16:23 CEST] <J_Darnley> vf_example: http://codepad.org/OQjPwIcg
[18:20:04 CEST] <sucharitha> I was calling a couple of functions of ffmpeg from my code and I want to see the errors that are logged. Do you know how to do that? Sorry for bothering .
[18:20:33 CEST] <bove> av_log ?
[18:21:07 CEST] <bove> Also, how can I include an int32 in an av_log line?
[18:21:21 CEST] <nevcairiel> its just a fancy printf
[18:21:26 CEST] <nevcairiel> so %d
[18:21:35 CEST] <bove> sucharitha: av_log(s, AV_LOG_ERROR, "Hello world");
[18:22:04 CEST] <J_Darnley> it is a printf function
[18:22:47 CEST] <J_Darnley> strictly speaking, an int32_t should be "%" PRId32
[18:23:11 CEST] <nevcairiel> frankly speaking, these macros are annoying as shit :P
[18:23:43 CEST] <wm4> they are
[18:23:48 CEST] <wm4> just cast the arguments to int etc.
[18:24:50 CEST] <michaelni> D404|Ghetto, id like to see your code which doesnt work so it can be fixed, IIUC J_Darnley code differs from it
[18:25:08 CEST] <D404|Ghetto> i said exactly what i changed
[18:25:11 CEST] <D404|Ghetto> one if statement.
[18:25:18 CEST] <D404|Ghetto> and that was only a test
[18:25:26 CEST] <D404|Ghetto> i also changed the check to only be EOF
[18:26:06 CEST] <D404|Ghetto> http://chromashift.org/thing.txt
[18:27:56 CEST] <durandal_1707> actually reverse need stack of frames and not queue so lavfi/bufferqueue.h can't be used
[18:28:28 CEST] <D404|Ghetto> i know
[18:28:34 CEST] <D404|Ghetto> but i didnt even get that far.
[18:30:22 CEST] <durandal_1707> I could write it in under 15 mins....
[18:30:30 CEST] <D404|Ghetto> youve also written numerous filters
[18:30:33 CEST] <D404|Ghetto> and know all the internals
[18:30:42 CEST] <D404|Ghetto> youre not some guy reading the "Documents" and code
[18:30:44 CEST] <D404|Ghetto> for teh first time
[18:31:12 CEST] <D404|Ghetto> im sure the lovecraftian horror is easy to slay after your Nth fight with it
[18:34:29 CEST] Action: D404|Ghetto goes to catch the bus home
[18:37:11 CEST] <bove> I'm using avio_rb64() to read a double, but the value I'm getting is way off. (4627730092099895296.000000 instead of 25.0) Any ideas?
[18:38:13 CEST] <J_Darnley> Is it really a big-endian double?
[18:39:14 CEST] <bove> Reads correctly when I unpack it as big endian double in python
[18:39:25 CEST] <bove> I'm sure it's a user error, I just can't find it
[18:40:22 CEST] <bove> Could it have something to do with memory alignment?
[18:41:06 CEST] <J_Darnley> are you just assigning the returned uin64_t to a double variable?
[18:41:57 CEST] <bove> It's stored as a double from the cpp writer
[18:42:37 CEST] <bove> Gonna check if the next field lines up like I expect it to
[18:43:04 CEST] <bove> It does :\
[18:43:07 CEST] <J_Darnley> Yes... but you are reading a 64-bit unsigned integer from the file...  what are you doing with it?
[18:43:49 CEST] <J_Darnley> Are you assigning it to the double part of a double-uint64_t union?
[18:43:53 CEST] <bove> double  	rate; rate = avio_rb64(s->pb); av_log(s, AV_LOG_ERROR, "rate %f\n", rate);
[18:44:17 CEST] <J_Darnley> Yes, so the compiler converts the integer to a double ansd then prints it.
[18:44:38 CEST] <wm4> wbs: h, I think xbmc still uses libstagefright
[18:44:59 CEST] <bove> J_Darnley: avio reads everything as int?
[18:45:13 CEST] <J_Darnley> Look at the return type!
[18:45:37 CEST] <J_Darnley> union {double f, uint64_t i} rate; rate.i = avio_rb64(s->pb); av_log(s, AV_LOG_ERROR, "rate %f\n", rate.f);
[18:46:26 CEST] <durandal_1707> bove: see av_int2double from lavu/intfloat.h
[18:48:18 CEST] <bove> thanks guys. I'm almost through the whole header now
[18:48:40 CEST] Action: J_Darnley is too distracted by IRC
[18:49:26 CEST] <michaelni> D404|Ghetto, i dont understand your code, you discard all frames in filter_frame(), did you assume that filter_frame() would only be called in response to ff_request_frame() ? thats not so it can be called without request. also i get EOF from ff_request_frame()
[18:50:13 CEST] <michaelni> if i dont discard all frames the filter outputs them fine (in normal order) also i saw no infinite loop, 
[18:50:29 CEST] <michaelni> iam happy to help fix it but i need to understand first how to reproduce the issue
[18:51:26 CEST] <bove> Where is avio defined?
[18:51:38 CEST] <bove> lol
[18:51:46 CEST] <bove> avio.c
[18:52:27 CEST] <bove> or?
[18:53:31 CEST] <durandal_1707> and aviobuf.c
[18:54:15 CEST] <bove> Found it. I'm looking for a function to read a char[128]
[18:57:19 CEST] <bove> timeCode = avio_read(s->pb, 1024); ?
[18:59:30 CEST] <bove> avio_read(s->pb, timeCode, 1024); segfaults ...
[19:04:08 CEST] <bove> avio_read wants the length in bytes, not bits. avio_read(s->pb, tapeName, 128); works better ...
[19:05:25 CEST] <D404|Ghetto> michaelni: if course it doesnt work. the problem was the api is confusing. not "thing doesnt work".
[19:05:45 CEST] <D404|Ghetto> saying what it does wothout the "why" is not helpful.
[19:05:55 CEST] <D404|Ghetto> it is not a matter of "reproducing"
[19:18:03 CEST] <bove> Where is AVCodecContext defined?
[19:18:33 CEST] <kierank> avcodec.h
[19:18:51 CEST] <JEEB> many structs and such also have doxygen pages http://ffmpeg.org/doxygen/trunk/structAVCodecContext.html
[19:19:10 CEST] <D404|Ghetto> grep is your pal
[19:19:15 CEST] <JEEB> aye
[19:19:18 CEST] <JEEB> git grep for the win
[19:19:30 CEST] <D404|Ghetto> i use normal grep
[19:19:49 CEST] <nevcairiel> i let my IDE get me to the definitions =p
[19:19:50 CEST] <JEEB> well git grep just automagically limits grep the git files
[19:20:02 CEST] <JEEB> *to the git files
[19:20:25 CEST] <JEEB> and unlike mercurial's grep, seems to just pass params to grep
[19:20:52 CEST] <D404|Ghetto> yeah, but muscle memory
[19:20:57 CEST] <D404|Ghetto> memory*
[19:21:55 CEST] <JEEB> aye
[19:25:47 CEST] <wm4> everyone knows that IDEs are a thing of the devil
[19:26:15 CEST] <bove> What controls the packet size when ffmpeg calls _read_packet(AVFormatContext *s, AVPacket *pkt) ?
[19:34:56 CEST] <bove> It looks like the demuxer is only working on one packet at the time, so the packet must be defined somewhere, right?
[19:48:42 CEST] <durandal_1707> demuxer controls it, like with av_get_packet
[20:11:33 CEST] <bove> I'm using the read_packet() from rawvideodec.c, but I'm only getting the first frame
[20:12:43 CEST] <bove> http://pastebin.com/Xxq1huHu
[20:15:08 CEST] <cone-562> ffmpeg 03Arttu Ylä-Outinen 07master:b90b6af710d0: avcodec: add libkvazaar HECV encoder
[20:21:36 CEST] <jamrial> interesting, lgpl hevc encoder
[20:21:57 CEST] <nevcairiel> havent there been several of those that died before they could produce a recognizable image
[20:22:44 CEST] <jamrial> that's why it's interesting. this one apparently didn't :p
[20:23:05 CEST] <nevcairiel> well its not like its super advanced either
[20:23:55 CEST] <jamrial> but it will be popular among the crappy paid ffmpeg wrappers you can find online
[20:24:05 CEST] <jamrial> just like libopenh264
[20:24:24 CEST] <philipl> How do you market a crappy paid ffmpeg wrapper?
[20:24:27 CEST] <philipl> Who buys it?
[20:24:33 CEST] <philipl> especially for encoding
[20:24:36 CEST] <JEEB> oh
[20:24:45 CEST] <JEEB> just noticed in samsung's OSS release notes
[20:24:48 CEST] <JEEB> for their tizen tvs
[20:24:53 CEST] <JEEB> they contain ffmpeg
[20:26:04 CEST] <philipl> JEEB: there's a terrifying thought that they're using ffmpeg -> libstagefright :-)
[20:26:27 CEST] <JEEB> it's tizen so I'm not sure why there'd be stagefright in there
[20:26:46 CEST] <JEEB> also it's the first thing in real life where libsmack is being used as far as I can remember
[20:30:40 CEST] <JEEB> http://up-cat.net/p/01393f07
[20:43:45 CEST] <wm4> what the fuck http://git.videolan.org/?p=ffmpeg.git;a=blobdiff;f=libavformat/utils.c;h=a123a59177716a532deb37fad863ec1fe4d0bc24;hp=d91d84805dd0a181bd03dd7234c1c29913de6c18;hb=b5136612510052a7acacd560b9b5edad69402519;hpb=f5c281daa8aed4618f94e4131be17e772f6673f8
[20:43:47 CEST] <wm4> I mean
[20:43:47 CEST] <wm4> what
[20:45:25 CEST] <D404|Ghetto> i dont really know whats going on in there
[20:45:27 CEST] <wm4> also this function is in utils.c, but is only used (and was only added for) mov.c
[20:45:43 CEST] <wm4> shit is going on there
[20:46:55 CEST] <wm4> and if avio_find_protocol_name returns NULL (which it can and will), this shit will crash
[20:54:37 CEST] <durandal_1707> michaelni ^
[21:09:28 CEST] <wm4> sent a patch
[21:27:01 CEST] <durandal_1707> mistyping hevc as hecv...
[21:27:19 CEST] <philipl> hvec...
[21:28:20 CEST] <durandal_1707> does anybody need convolution filters?
[21:32:12 CEST] <ubitux> durandal_1707: it reminds me i had a very old "enhance" filter with all kind of filter like this
[21:32:39 CEST] <ubitux> http://b.pkh.me/0001-lavfi-WIP-enhance-filter.patch
[21:32:42 CEST] <ubitux> > 2012, heh
[21:32:48 CEST] <ubitux> i don't remember what works and what doesn't
[21:33:05 CEST] <ubitux> it probably doesn't work at all
[21:33:40 CEST] <ubitux> maybe needs sws patching
[21:37:02 CEST] <durandal_1707> I want custom 3x3 and 5x5 convolution and why use libswscale?
[21:39:57 CEST] <ubitux> because it already had the feature iirc
[21:40:24 CEST] <ubitux> (with asm?)
[22:20:50 CEST] <durandal_1707> ubitux: ok to rename it to convolution?
[22:21:25 CEST] <ubitux> do whatever you want with it :p
[22:21:41 CEST] <ubitux> you probably want to make it work first
[22:22:45 CEST] <durandal_1707> Those filter stuff for libswscale are nowhere documented
[22:27:52 CEST] <matija_> hello
[22:39:53 CEST] <matija> http://pastebin.com/YyFxG2B9
[22:39:58 CEST] <matija> anyone has an idea about this?
[22:40:04 CEST] <matija> happens during make
[22:40:37 CEST] <J_Darnley> Old headers?
[22:40:38 CEST] <BtbN> did they release a new SDK?
[22:40:49 CEST] <BtbN> old headers would automaticaly cause an error
[22:41:02 CEST] <matija> i use latest one
[22:41:06 CEST] <matija> 5.0.1
[22:41:07 CEST] <BtbN> nope, no new SDK
[22:41:14 CEST] <BtbN> should work just fine with that.
[22:41:27 CEST] <matija> i copied headers to /usr/include
[22:41:32 CEST] <matija> configure gives no error
[22:41:49 CEST] <BtbN> configure only checks the version and presence of the header
[22:41:53 CEST] <matija> latest git repo
[22:42:40 CEST] <BtbN> are you using a weird C compiler, that has trouble understanding anonymous unions?
[22:42:55 CEST] <matija> i use debian wheezy
[22:43:00 CEST] <matija> could that be an issue?
[22:43:09 CEST] <BtbN> what gcc version are they using?
[22:43:37 CEST] <matija> 4,4 and 4.7
[22:44:05 CEST] <BtbN> 4.7 should work.
[22:44:21 CEST] <BtbN> i never tested it with anything older than 4.8 though
[22:44:52 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/nvenc.c#l91 it's complaining about that struct
[22:45:03 CEST] <BtbN> it can't propperly parse it, all the other errors are just follow ups
[22:45:30 CEST] <BtbN> you can easily workaround it by just commenting out line 93 and 96
[22:46:05 CEST] <matija> let me try with gcc 4.7
[22:46:06 CEST] <matija> sec
[22:47:25 CEST] <matija> ha
[22:47:27 CEST] <matija> worked :D
[22:47:41 CEST] <BtbN> with 4.7 or with commenting out the union?
[22:47:51 CEST] <matija> with 4.7
[22:48:37 CEST] <matija> i'd rather not mess with commenting out the files
[22:48:52 CEST] <BtbN> It would just make it slightly less memory efficient
[22:49:00 CEST] <BtbN> no functional change
[22:49:32 CEST] <nevcairiel> that seems like an odd use for a union
[22:49:46 CEST] <BtbN> yes, i'm thinking about just getting rid of it
[22:50:12 CEST] <matija> hm ffmpeg binary is not built
[22:51:32 CEST] <matija> just ffprobe is built
[22:51:43 CEST] <BtbN> the union might make the difference between the value beeing small enough for a register. No idea how relevant it is, but as only one value is used at a time, i thought it wouldn't hurt.
[22:52:48 CEST] <matija> tyrying with just nvenc and nonfree
[22:53:30 CEST] <cone-562> ffmpeg 03wm4 07master:130a8e0eef2f: avformat: don't crash API users when demuxing mp4
[22:56:39 CEST] <matija> other then disable-ffmpeg what would signal not to build ffmpeg?=
[22:57:13 CEST] <matija> i use--enable-nvenc --enable-libx264 --enable-version3 --enable-libass --enable-libbluray --enable-libmp3lame --enable-libopencv --enable-libopenjpeg --enable-libopus --enable-libfaac --enable-libtheora --enable-libvpx --enable-libwebp --enable-opencl --enable-x11grab --e
[22:57:17 CEST] <matija> nable-openssl --enable-libvorbis --disable-static --disable-^Cserver --disable-avfilter --disable-ffplay --enable-shared --enable-gpl --enable-nonfree
[22:57:31 CEST] <matija> where ^C is ff
[22:57:40 CEST] <BtbN> you disable avfilter, it propably needs it
[22:58:18 CEST] <matija> k thx, testing
[22:58:49 CEST] <matija> good thing i have 24 cpu cores to compile it
[22:59:32 CEST] <matija> now we'll see how good is that titan x
[22:59:42 CEST] <durandal_1707> I will apply dynaudnorm if nobody objects..
[22:59:47 CEST] <matija> too bad that this is cusromers box :/
[22:59:57 CEST] <nevcairiel> video encoding doesnt get faster or better with faster cards
[23:00:13 CEST] <matija> then why use it?
[23:00:34 CEST] <nevcairiel> encoding uses fixed-function hardware, which is always the same speed pretty much
[23:01:03 CEST] <nevcairiel> you can buy a mid-range card and get the same functionality
[23:01:43 CEST] <BtbN> matija, https://github.com/BtbN/FFmpeg/commit/550e872bcd49547564414b1cef69a8de8280064d.patch should make it work with gcc 4.4
[23:01:48 CEST] <BtbN> would apreciate if you test it
[23:02:09 CEST] <nevcairiel> dont think anyone cares about gcc 4.4 still =p
[23:02:27 CEST] <BtbN> Well, i'm not even sure if that anonymous struct is valid C, so i rather fix it.
[23:03:08 CEST] <nevcairiel> they are C11
[23:03:39 CEST] <matija> BtbN: will do, let me jsut fix something here
[23:05:53 CEST] <BtbN> with 4.4 of course
[23:09:53 CEST] <matija> BtbN: works
[23:10:02 CEST] <BtbN> nice
[23:10:17 CEST] <matija> 10 more secs to confirm
[23:11:11 CEST] <matija> built with gcc 4.4.7 (Debian 4.4.7-2)
[23:13:04 CEST] <matija> BtbN: one more thing 
[23:13:05 CEST] <matija> i get
[23:13:10 CEST] <matija>   WARNING: library configuration mismatch
[23:13:25 CEST] <jamrial> Is that an actively supported debian release? gcc 4.4 has been EOLed for years now
[23:13:37 CEST] <matija> jamrial: that is debian wheezy
[23:14:08 CEST] <matija> has both 4.4 and 4.7
[23:14:44 CEST] <BtbN> I'd guess it's trying to use the libs from your system with the ffmpeg you built yourself
[23:15:01 CEST] <BtbN> Use a static build to avoid that.
[23:15:40 CEST] <matija> compiling with --enable-static
[23:16:38 CEST] <BtbN> Is it ok to just push a simple non-functional fix like that, or should I send it to the ml?
[23:18:35 CEST] <matija> i still get that warning
[23:18:52 CEST] <BtbN> strange, never seen it before, not sure what exactly it means
[23:19:25 CEST] <jamrial> BtbN: if you're the maintainer (or one of the people that wrote the stuf to begin with) then just apply it
[23:20:02 CEST] <BtbN> Ok, i'm both.
[23:21:29 CEST] <cone-562> ffmpeg 03Timo Rothenpieler 07master:550e872bcd49: avcodec/nvenc: Fix build with older gcc versions
[23:35:12 CEST] <matija> BtbN: thank you so much took me whole day to fix this :)
[23:35:43 CEST] <matija> bye guys, have fun
[23:46:51 CEST] <BtbN> That Past duration too large warning is also annoying me recently though. 
[23:47:13 CEST] <BtbN> I don't think i can fix it, and it just clutters up the console.
[23:47:53 CEST] <iive> yeh...
[23:48:08 CEST] <BtbN> I'm not even sure what exactly it wants to tell me.
[23:48:27 CEST] <iive> i was just going to say that i had no idea what it means :)
[23:49:06 CEST] <BtbN> i can get rid of it by settings -vsync passthrough
[23:49:17 CEST] <BtbN> but then i get libx264 warning about non monotonic dts instead.
[23:52:43 CEST] <BtbN> Just looked at the code that procudes it, still not sure what it means or how to fix it.
[23:53:04 CEST] <BtbN> And i can't type anymore...
[23:54:55 CEST] <iive> BtbN: it would be great if you have a way to reproduce it with small test samples.
[23:55:15 CEST] <iive> because most of my samples are quite big.
[23:55:15 CEST] <BtbN> My testcase involves a webcam
[23:55:24 CEST] <BtbN> that produces mjpeg
[23:55:34 CEST] <BtbN> And does weird stuff with its timestamps
[23:59:06 CEST] <iive> :\
[00:00:00 CEST] --- Wed Jul 15 2015