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

[burek]

[02:04:09 CEST] <Compn> did anyone ever use the bitrate peeling of ogg vorbis (or was it supposed to be in opus?)
[02:10:51 CEST] <llogan> time for me to be a camera operator with a camera I've never used. mystery fun box time.
[02:11:21 CEST] <llogan> i'll just imagine i'm playing Contra
[02:12:33 CEST] <llogan> Compn: i first read "bitrate peeing".
[02:31:54 CEST] <cone-400> ffmpeg 03Michael Niedermayer 07master:733511fb53fe: avutil/common: Document FFABS() corner case
[03:11:15 CEST] <cone-400> ffmpeg 03Michael Niedermayer 07master:d1bdaf3fb2c4: avformat/dump: Fix integer overflow in aspect ratio calculation
[04:28:01 CEST] <BBB> I have a few more vp9 patches, shall I just commit them all at once? I dont think Ill get much sensible review, theyre all libvpx/vp9 bitstream idiosyncracies
[04:28:11 CEST] <BBB> they obviously pass fate etc.
[04:34:05 CEST] <jamrial> you're one of the maintainers, so sure
[09:07:36 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:d6cd614dac57: avutil/common: Add FFNABS()
[09:45:55 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:053e80f6eaf8: avformat/mov: Fix integer overflow in FFABS
[09:45:56 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:32f53958b8f6: swresample/swresample: Fix integer overflow in seed calculation
[10:29:50 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:bd70303ead78: avformat/swfdec: Check return value of init_get_bits8()
[10:49:51 CEST] <rcombs> looks like _dlerror_run allocates a thread-specific buffer that's freed when the thread terminates
[10:50:07 CEST] <rcombs> pretty widely agreed to be benign
[10:51:14 CEST] <rcombs> valgrind even has a builtin suppression for it now
[11:28:06 CEST] <cone-556> ffmpeg 03Paul B Mahol 07master:19dfbe929851: avfilter/vf_elbg: make it possible to output to pal8 pixel format
[11:28:06 CEST] <cone-556> ffmpeg 03Paul B Mahol 07master:1c88ef0c99c4: avfilter/vf_vectorscope: support more formats for color4 mode in common case
[11:28:08 CEST] <cone-556> ffmpeg 03Paul B Mahol 07master:7820197d2cd6: avfilter/vf_vectorscope: constify more variables
[11:28:09 CEST] <cone-556> ffmpeg 03Paul B Mahol 07master:81f7a2579b08: avcodec/vorbisdec: use init_get_bits8()
[11:28:09 CEST] <cone-556> ffmpeg 03Paul B Mahol 07master:8d2b4b8c8299: avfilter/vf_drawgraph: add rscroll slide mode
[11:41:19 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:879603fa3f8d: avformat/latmenc: Add assert to avoid coverity warning
[11:41:20 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:e3d8504fd043: avformat/hlsenc: Initialize vtt_oc to help static analyzers
[11:41:21 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:4cad4bd4ca6a: avformat/hlsenc: Fix memleak of path
[11:48:05 CEST] <cone-556> ffmpeg 03Paul B Mahol 07master:9136e65c405b: avcodec/fraps: use init_get_bits8()
[11:48:06 CEST] <cone-556> ffmpeg 03Ganesh Ajjanagadde 07master:c0ae4619ecf7: avfilter/vf_sab: use the name 's' for the pointer to the private context
[13:02:29 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:fddcd9e5702e: avformat/file: Fix copy and paste error
[14:24:10 CEST] <michaelni> durandal_1707, coverity found some potential issues in some of your filters, do you have time to look at them? or should i (when i have time)?
[14:25:25 CEST] <durandal_1707> feel free to do it i see nothing of emegency
[14:28:51 CEST] <michaelni> no emergency, no, but they should all be fixed anyway
[14:32:01 CEST] <wm4> does libswscale have libsamplerate support?
[14:34:22 CEST] <wm4> err
[14:34:25 CEST] <wm4> libswresample
[14:37:37 CEST] <cone-556> ffmpeg 03Carl Eugen Hoyos 07master:3cf0c959cd76: doc: Explain how to use the fps and the fieldmatch filter together.
[14:40:43 CEST] <nevcairiel> wm4: the only external one is soxr i think
[14:52:46 CEST] <durandal_1707> wm4: why?
[14:52:56 CEST] <wm4> someone asked for it
[14:53:14 CEST] <wm4> libsamplerate is the software equivalent of gold plated optical audio cables
[14:54:35 CEST] <durandal_1707> lol
[14:58:05 CEST] <wm4> exporting image attachments as video streams was always such a fucking great idea...
[15:16:17 CEST] <cone-556> ffmpeg 03Claudio Freire 07master:bcb3332b1bc1: AAC: Increase fuzziness of fate-aac tests
[15:34:29 CEST] <wm4> __gb__: are you still interested in that vaapi API change?
[15:41:43 CEST] <__gb__> hi wm4, yes, I was on vacation, but I have just locally rebased
[15:42:18 CEST] <__gb__> did you comment more on the initial patches or either way to proceed?
[15:42:51 CEST] <__gb__> I think the latest proposal could fill your requirement, though I do not really see the gain, but still possible to do, yes
[15:43:57 CEST] <wm4> __gb__: just what I wrote on the ML
[15:44:08 CEST] <wm4> I see no huge stoppers anyway
[15:44:16 CEST] <wm4> I'm hoping that my concerns are unfounded
[15:44:24 CEST] <wm4> (e.g. about surface allocation control)
[15:44:45 CEST] <__gb__> concerning, a data[2], or data[4], that was also an idea I wanted to explore, especially when hwaccel in libswscale or filters is to be involved in the future :)
[15:45:08 CEST] <BBB> hwaccel in swscale?
[15:45:24 CEST] <__gb__> but no firm plans (API-wise) laid out yet, just thinking
[15:45:46 CEST] <__gb__> yes, there is a need to color convert/resize from VA surfaces too
[15:45:54 CEST] <__gb__> and could benefit from HQ scaling from the HW
[15:46:21 CEST] <__gb__> I know there could be plenty discussion around it, but let me finish first the first steps :)
[15:47:43 CEST] <wm4> ok
[15:49:29 CEST] <__gb__> lots of things are possible, technically, but is there real interest, we certainly could discuss on the possibilities
[15:50:10 CEST] <wm4> some ffmpeg users would indeed like to have a full hw-based transcoding pipeline etc.
[15:50:24 CEST] <__gb__> e.g. if someone wants to extracts MVs for further analysis/processing, that's possible, but is it worth the effort, etc.
[15:54:43 CEST] <ubitux> what's this extracting MVs about?
[15:54:50 CEST] <ubitux> (we have an api for that)
[15:56:09 CEST] <wm4> it was an example for an obscure feature that could be implemented with vaapi
[16:06:14 CEST] <__gb__> yes, vaapi is one thing. the other thing is additional work would also be needed in the driver, hence the "is it worth the effort" part :)
[16:19:55 CEST] <ubitux> $ ffprobe D6774E697C2C9028FF327203DDEAC91B17FA203F.mp4 
[16:19:57 CEST] <ubitux> ffprobe: error while loading shared libraries: libxcb-xfixes.so.0: cannot open shared object file: No such file or directoyr
[16:19:59 CEST] <ubitux> fuck this shit
[16:20:01 CEST] <ubitux> FFS
[16:20:12 CEST] <ubitux> why is it fucking auto detected
[16:20:39 CEST] <wm4> yeah that seems weird
[16:20:46 CEST] <wm4> because it's a "system lib"
[16:21:38 CEST] <ubitux> i knew it was going to cause some shit
[16:21:41 CEST] <ubitux> rah i'm angry
[16:22:18 CEST] <JEEB> wat
[16:22:23 CEST] <JEEB> what's libxcb again?
[16:22:40 CEST] <wm4> X11 lib
[16:22:44 CEST] <wm4> for screen capture
[16:22:50 CEST] <JEEB> ah
[16:26:51 CEST] <cone-556> ffmpeg 03Claudio Freire 07master:5131ba565792: AAC: MIPS: Add missing codebooks in quantize funcs
[16:37:07 CEST] <iive> xlib is implemented over xcb
[16:38:42 CEST] <ubitux> and of course --disable-libxcb is not enough
[16:38:48 CEST] <ubitux> godammit
[17:24:55 CEST] <ubitux> so, we still can't disable the dithering with sws?
[17:32:49 CEST] <BtbN> __gb__, did you see my reply to your hevc patch comments? (It's already merged now, but obviously not set in stone)
[17:33:02 CEST] <BtbN> So far it's working fine.
[17:33:23 CEST] <BtbN> 4K playback didn't work at all first, but a libva/intel-driver update from 1.6.0 to latest master fixed that.
[17:33:36 CEST] <BtbN> My NUC now plays 4K60 perfectly.
[17:35:51 CEST] <ubitux> oh? nice
[17:35:54 CEST] <wm4> BtbN: does this use the kodi EGL interop?
[17:35:59 CEST] <ubitux> i guess i'll just buy one
[17:36:05 CEST] <ubitux> or two
[17:36:14 CEST] <wm4> are NUCs tearing-free?
[17:36:22 CEST] <BtbN> wm4, only works in kodi with EGL interop, yes
[17:36:32 CEST] <BtbN> mpv isn't fast enough with any available output method
[17:36:49 CEST] <BtbN> I can't notice any tearing
[17:37:02 CEST] <wm4> is it fast enough with --vo=null?
[17:37:14 CEST] <BtbN> How do i tell?
[17:37:37 CEST] <wm4> this still drops frames if they come too late
[17:38:40 CEST] <BtbN> yes, still dropping a lot of frames with vo=null
[17:38:48 CEST] <BtbN> oh
[17:38:54 CEST] <BtbN> it's not using vaapi?!
[17:39:19 CEST] <BtbN> "VO does not support requested hardware decoder, or loading it failed."
[17:39:31 CEST] <wm4> you probably don't have X
[17:39:36 CEST] <BtbN> i do
[17:39:56 CEST] <wm4> oh wait, with --vo=null you need --hwdec=vaapi-copy
[17:40:08 CEST] <BtbN> https://gist.github.com/BtbN/9200033a8e5194026b23
[17:40:38 CEST] <BtbN> yeah, that works.
[17:40:39 CEST] <BtbN> 0 drops
[17:41:07 CEST] <wm4> vo_vaapi probably goes through slow codepaths too
[17:41:21 CEST] <BtbN> Isn't that just vaPutSurface to an X drawable?
[17:41:22 CEST] <wm4> (I wonder why it even exists, but at least 1 user claimed it can prevent tearing)
[17:41:26 CEST] <wm4> yes
[17:41:33 CEST] <BtbN> Yeah, that's slow.
[17:41:42 CEST] <wm4> but in theory it could use overlays or whatever it wants
[17:41:49 CEST] <wm4> and probably did for some drivers
[17:41:49 CEST] <BtbN> yes, it could
[17:41:51 CEST] <BtbN> but it doesn't.
[17:42:08 CEST] <wm4> anyway, this EGL stuff sounds pretty much perfect
[17:42:10 CEST] <BtbN> The GLX interop is even slower.
[17:43:49 CEST] <wm4> BtbN: can't wait to throw that shit out
[17:44:34 CEST] <BtbN> EGL needs a lot of very bleeding edge software to work though
[17:44:54 CEST] <BtbN> Basicaly my entire graphics stack is running git master
[17:45:33 CEST] <nevcairiel> That means two decades until widespread adoption in Linux world?
[17:45:38 CEST] <wm4> that's why I didn't do anything yet
[17:46:08 CEST] <wm4> nevcairiel: it means it'll be available in some weeks or months in bleeding-edge distros
[17:46:37 CEST] <wm4> I hoped being able to run a second X server running on the Intel GPU, but so far I had no luck with this
[17:46:38 CEST] <BtbN> nevcairiel, mesa-11 is enough
[17:46:52 CEST] <BtbN> Gentoo already has every that's needed
[17:46:55 CEST] <wm4> in fact, just loading the intel driver breaks the nvidia GPU too
[18:02:20 CEST] <ubitux> haha the caps thing
[18:03:02 CEST] <wm4> BtbN: hm, what do I need from Gentoo to make it work?
[18:03:39 CEST] <BtbN> Basicaly just mesa-11
[18:03:56 CEST] <BtbN> If you are running an ~amd64 system, you should be good to go.
[18:04:16 CEST] <BtbN> And of course the egl useflag set globaly
[18:05:07 CEST] <BtbN> If applications start randomly running into unexplainable infinite loops, rebuild mesa without gallium support.
[18:10:12 CEST] <BtbN> I'm building mesa, libdrm, xf86-video-intel, libva and libva-intel-driver from git master.
[18:10:24 CEST] <BtbN> (And mpv and kodi of course)
[18:12:32 CEST] <iive> gallium is needed for radeon and nvidia, i think.
[18:12:45 CEST] <BtbN> As i have an intel nuc, i don't care.
[18:13:04 CEST] <BtbN> They messed up big time in their gallium code.
[18:13:15 CEST] <BtbN> https://bugs.freedesktop.org/show_bug.cgi?id=91646
[18:14:46 CEST] <BtbN> And from the looks of it, mesa-11 will be released with that bug still present.
[18:21:07 CEST] <iive> why do they need udev at all?
[18:21:51 CEST] <wm4> BtbN: why the heck will they release that`?
[18:22:18 CEST] <BtbN> Because mesa devs don't look at their bug tracker.
[18:22:29 CEST] <BtbN> None of the bugs I reported there have been fixed so far
[18:22:34 CEST] <BtbN> dating back several years now
[18:22:46 CEST] <wm4> fun
[18:22:50 CEST] <BtbN> This one seems like a release blocker to me.
[18:22:53 CEST] <iive> doesn't the tracker send mails to their maillist too?
[18:22:57 CEST] <BtbN> yes
[18:23:25 CEST] <BtbN> Starting with mesa-11, kodi will run into an infinite loop at a seemingly random location(Was somewhere inside systemd libs for me, so people refused to look into it entirely first).
[18:23:31 CEST] <BtbN> +s
[18:23:38 CEST] <BtbN> Because it links against libudev
[18:23:42 CEST] <iive> most likely every video player would
[18:23:53 CEST] <BtbN> And so will every other application that that links against some mesa GL lib and libudev
[18:24:17 CEST] <BtbN> calling dlopen during library load is just not well-defined, mesa must not do that.
[18:24:50 CEST] <iive> well, that's why he tries to move it to a function call.
[18:25:14 CEST] <BtbN> Well, "he" is just some other guy from gentoo that helped me finding out what the heck is going on.
[18:25:54 CEST] <iive> ouch
[18:26:08 CEST] <BtbN> You don't get much help when you are running a system with a huge bunch of git-master libraries all over the place.
[18:26:38 CEST] <BtbN> This bug will propably get a lot of attention once mesa-11 releases and the first major distro ships it.-
[18:27:29 CEST] <BtbN> I'm also still waiting for some mesa dev blaming glibc
[18:30:47 CEST] <wm4> or a glibc dev implementing a shitty workaround, and then the same thing happens on BSD?
[18:31:13 CEST] <BtbN> It's not the fault of glibc
[18:31:29 CEST] <BtbN> you are essentials re-entering the library load routine, while it's still running.
[18:31:30 CEST] <BtbN> *y
[18:31:49 CEST] <BtbN> Just don't load libraries when you are a library currently beeing loaded.
[18:32:24 CEST] <wm4> <BtbN> It's not the fault of glibc <- they might add workaround for other's bugs though
[18:32:40 CEST] <wm4> of course this would be the most terrible solution
[18:32:47 CEST] <wm4> which is why it's likely that it will happen
[18:33:09 CEST] <BtbN> Making dlopen re-entrant isn't a simple task
[18:39:42 CEST] <iive> BtbN: btw, i like how the glibc bug doesn't even have a single comment...
[18:57:19 CEST] <BtbN> also note that it's like 2.5 years old
[19:02:41 CEST] <iive> exactly!
[19:14:15 CEST] <Compn> maybe someone should bump the glibc bug
[19:15:42 CEST] <BBB> so uhm, re: ffm
[19:15:46 CEST] <BBB> is that considered a stable format?
[19:15:57 CEST] <Compn> which ffm ?
[19:16:01 CEST] <BBB> as in, can I take a ffm file streamed from ffmpeg 0.5 and stream it to ffserver 2.7 and should that work?
[19:16:09 CEST] <BBB> or does it only work within the same version?
[19:16:18 CEST] <BBB> I really dont feel like fixing ffm between versions
[19:16:34 CEST] <Compn> check git history on the ffm code ? probably no one touched it in years so it should be the same? 
[19:16:42 CEST] <BBB> Im about to chagne it
[19:18:05 CEST] <wm4> just ask why ffm should exist instead
[19:20:14 CEST] <BBB> ffmpeg-ffserver interaction
[19:20:39 CEST] <BBB> its like streaming ffmpegs internal representation of an avformat/codeccontext from one instance to the next
[19:20:55 CEST] <BBB> its somewhat useful for certain purposes
[19:24:24 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:9f6ca28e329e: avformat/concatdec: Check file variable before dereferencing
[19:24:25 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:629fcda4dace: avfilter/avf_showfreqs: Use floating point division in WFUNC_BHANN
[19:24:26 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:92b3c486b0e7: avfilter/af_dynaudnorm: Fix typo in assert
[19:24:27 CEST] <cone-556> ffmpeg 03Stephan Holljes 07master:dd7b486e8e5b: lavf/http: Fix incorrectly placed parenthesis.
[19:42:17 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:a212a983c7f4: avfilter/avf_showwaves: Check max_samples
[19:42:43 CEST] <kierank> what is ffm?
[19:52:45 CEST] <ubitux> BBB: it's supposed to be stable; but recently we had to add some fields or something, and so a mechanism was added to allow more extensiveness to make it more stable in next iterations
[19:52:59 CEST] <ubitux> it's probably done through a version bump of the format, i don't remember the details
[19:53:29 CEST] <ubitux> BBB: see 9829ec1a9c0d51d090c5060a7f430fddffaf52c5
[19:54:02 CEST] <ubitux> so yeah ffm1 should still work with limitations, and ffm2 should be easier to extend
[19:59:09 CEST] <BBB> kierank: a avcodec/formatcontext serialization format, with AVFrame serialization as packet data
[20:06:18 CEST] <jamrial> is Andreas Cadhalpun here?
[20:06:33 CEST] <ubitux> not often; he uses the nickname "aca"
[20:06:49 CEST] <jamrial> ok, thanks
[20:12:52 CEST] <cone-556> ffmpeg 03Stephan Holljes 07master:280d140cb02b: lavf/http: Remove superfluous parenthesis.
[22:20:11 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:9ed53d5a8a96: avformat/mov: Change the type of the r/g/b variables
[22:20:11 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:e5aa6f702130: avcodec/gsmdec_template: avoid undefined negative left shifts
[23:56:11 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:c97ea011f57f: avfilter/vf_histogram: Fix order of operations with flags
[23:56:12 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:d5710411c743: avfilter/vf_atadenoise: Check for ff_get_video_buffer() failure
[23:56:13 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:59361d8c9d31: avfilter/af_sidechaincompress: Also assert that i < 2
[00:00:00 CEST] --- Fri Sep  4 2015