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

[burek]

[00:00:24 CET] <cone-895> ffmpeg 03James Almer 07master:8514f6dcfd29: avcodec/amrwbdec: use av_mod_uintp2
[00:00:25 CET] <cone-895> ffmpeg 03James Almer 07master:1bb3b90db833: avcodec/pngdec: use av_mod_uintp2
[00:00:26 CET] <cone-895> ffmpeg 03James Almer 07master:5893e8753702: avcodec/proresdec_lgpl: use av_mod_uintp2
[00:05:23 CET] Action: durandal_170 wonders who wrote vf_transforn
[00:11:24 CET] <jkqxz> ffmpeg_filter.c:423: "if (codec->width || codec->height) {" <- can anyone suggest what this conditional actually wants to test?  It doesn't trigger on the first graph configure because the encoder isn't initialised yet, and then does on all subsequent ones even if nothing has changed.
[00:12:31 CET] <jkqxz> (This messes with you if want to pass something through the filter graph which vf_scale doesn't support, because it adds extra scalers which then barf on your frames.)
[01:59:51 CET] <mattervr> wondering if someone can help me out with a nvenc_hevc hardware encoding issue.  Seems that I am unable to transcode prores or dnxhd to h265 using the hw accelerated nvenc_hevc codec.  Works just fine transcoding from h264.  I have a full trace log posted here http://pastebin.com/Q05KVbBS
[01:59:58 CET] <mattervr> is that a limitation of the nvenc_hevc encoder?  or do I need to re-compile ffmpeg with additional flags?
[02:13:31 CET] <Timothy_Gu> mattervr: does encoding to h264 work?
[02:13:40 CET] <Timothy_Gu> you might want to file a ticket at trac.ffmpeg.org
[02:15:01 CET] <cone-895> ffmpeg 03Timothy Gu 07master:9ba54c1b82a8: avcodec: Remove libaacplus
[02:18:28 CET] <mattervr> yeah encoding to h264 using hw nvenc_x264 and cpu works just fine
[02:27:50 CET] <cone-895> ffmpeg 03Kieran Kunhya 07master:e07e88cd82f7: avcodec: Remove libvo-aacenc support.
[10:38:13 CET] <durandal_1707> in what room are everybody?
[10:44:47 CET] <kierank> durandal_1707: open media
[10:44:49 CET] <kierank> are you here?
[10:44:54 CET] <kierank> not sure where atomnuker is
[10:47:10 CET] <durandal_1707> nah, i wanted to watch live video stream
[10:51:32 CET] <durandal_1707> will it be recorded and available to watch later?
[11:40:46 CET] <kierank> durandal_1707: yes
[11:42:02 CET] <funman> http://video.fosdem.org/2016/h2214/
[12:30:07 CET] <cone-218> ffmpeg 03Stephen Hutchinson 07master:0dd201d947e2: libx265: Remove experimental flag when encoding 4:2:2 and 4:4:4
[13:09:01 CET] <cone-218> ffmpeg 03Clément BSsch 07master:d3d03fd55e08: lavf/vqf: fix suported/supported typo
[13:10:25 CET] <cone-218> ffmpeg 03Clément BSsch 07master:54ab90c05b9d: lavc/utils: fix instanciate/instantiate typo
[13:23:54 CET] <wm4> hm trac is sloooooooow
[13:31:00 CET] <cone-218> ffmpeg 03Carl Eugen Hoyos 07master:0275b2d91754: Changelog: Sanitize Common Encryption entries.
[13:32:18 CET] <nevcairiel> wm4: always has been
[13:33:07 CET] <cone-218> ffmpeg 03Carl Eugen Hoyos 07master:d391feff544f: lavc/v210dec: Allow odd width.
[13:40:44 CET] <cone-218> ffmpeg 03Carl Eugen Hoyos 07master:31f5fa21b03d: lavc/exr: Move setting SAR down.
[13:53:55 CET] <ubitux> any idea how i can make check_code actually do check up to linking?
[13:53:59 CET] <ubitux> (configure)
[14:43:13 CET] <luc4> Hello! How do I propose an update to an example code of ffmpeg? Through a bug report?
[14:43:20 CET] <BBB> send a patch?
[14:45:07 CET] <luc4> BBB: through a bug report?
[14:49:35 CET] <wm4> to the mailing list
[14:51:04 CET] <wm4> clone the git repo, make your change, commit, run "git format-patch HEAD~1" to produce a patch, and send it as attachment to the ML
[14:53:16 CET] <luc4> wm4: ok, thanks
[15:15:25 CET] <luc4> Anyone who knows if there is a specification about the seek callback to be provided to avio_alloc_context?
[15:17:54 CET] <wm4> the code comments
[15:51:11 CET] <luc4> wm4: you mean ffmpeg code? Not sure where to look as that callback should be implemented by me.
[15:52:04 CET] <wm4> yeah
[15:52:11 CET] <wm4> most functions are probably under-documented
[15:52:33 CET] <wm4> patches for making the doxygen comments more precise would be welcome too
[15:54:19 CET] <luc4> wm4: to complete the implementation of my code I need a proper definition. Im confused about the SEEK_END value for whence and AVSEEK_SIZE. Not sure how to behave for those values.
[15:55:07 CET] <luc4> wm4: my code works, but an example should be very precise and I cant simply return -1 for those values.
[15:57:06 CET] <wm4> you can e.g. look at libavformat/file.c to find out what they're supposed to do
[16:01:00 CET] <durandal_1707> still old stuff in filter_design, anu volunters?
[16:01:08 CET] <durandal_1707> *any
[16:17:07 CET] <durandal_1707> the native aac topic seems gone from ha
[16:19:30 CET] <luc4> Anybody who has ever seen a crash like this? http://pastebin.com/f7adHQ9W
[16:46:50 CET] <RiCON> durandal_1707: https://hydrogenaud.io/index.php/topic,111085.0.html ?
[16:54:18 CET] <jkqxz> wm4:  On the codec profile constraint thing, would you be happy with trying possibly-compatible profiles iff the vaapi hwaccel is explicitly requested?  If you are trying to autodetect, it will fail out and software can do it.  If you explcitly requested it then it will give up anyway if we fail that test, so we might as well try.
[16:57:11 CET] <wm4> jkqxz: I think the user should be made a conscious decision that the decoded video might be corrupted
[16:58:43 CET] <wm4> (for profiles which are not strictly reported as supported by the hardware, and which are not strict subsets of supported profiles)
[17:05:29 CET] <jkqxz> I don't think that conscious decision is a useful one, except to users who fully understand the problem.
[17:13:50 CET] <jkqxz> Given my suggestion above, the user already explicitly requested that we decode on their VAAPI hardware.  If it works, good.  If it fails, ok, they asked for no software fallback anyway.  Silently giving a wrong result is the problem, and in this case the user will have a warning message telling them what the problem was.
[17:15:45 CET] <jkqxz> This is better than the DXVA2 hwaccel, which won't even give you a warning message for that case because it can't distinguish profiles far enough out to do so.  (And it's the same hardware underneath, so silent failure will likely be equivalent?)
[17:25:08 CET] <Daemon404> that src/ dir really screws up my grepping if i dotn distclean first
[17:25:12 CET] <Daemon404> i get all my results twice
[17:25:15 CET] <Daemon404> unless i build out of tree
[17:25:16 CET] <Daemon404> -__
[17:28:27 CET] <nevcairiel> build on windows :D
[17:28:49 CET] <Daemon404> ... is this src bs from andreas
[17:28:53 CET] <Daemon404> seriously?
[17:28:55 CET] <nevcairiel> of course
[17:31:18 CET] <BBB> its so that we dont have to revert his patch, right?
[17:31:37 CET] <BBB> although I seriously doubt that explanation, it looks mostly like a macho penis size contest
[17:32:32 CET] <Daemon404> i dont really care why
[17:32:37 CET] <Daemon404> i just care that it's a pain in the ass
[17:33:54 CET] <BBB> I think you should bring that up in the ML and wait for the next hack that gives you a git grep equivalent that filters out each second line or so
[17:33:55 CET] <BBB> :D
[17:34:41 CET] <Daemon404> i dont even use git grep
[17:34:41 CET] <jamrial> why does he need "bitexact" out of tree builds anyway?
[17:34:43 CET] <Daemon404> i use grep
[17:34:59 CET] <Daemon404> if i cant use standard unix unilities, that's ad
[17:35:01 CET] <Daemon404> sD
[17:35:02 CET] <Daemon404> sad*
[17:38:27 CET] <wm4> I prefer in-tree builds because it's less of a bother generally
[17:38:31 CET] <Daemon404> so do i
[17:38:42 CET] <wm4> so do I hear this right, the debian bullshit broke windows builds and they're still broken?
[17:38:49 CET] <Daemon404> and when im working on stuff i dont distclean between every change/build
[17:39:07 CET] <Daemon404> but if i dont clean, grep is broken because of the src symlink
[17:39:12 CET] <Daemon404> sure i could sort | uniq
[17:39:14 CET] <Daemon404> but that's vs
[17:39:15 CET] <Daemon404> bs
[17:45:14 CET] <nevcairiel> Daemon404: way to edit your quotes before posting them on the ML =p
[17:45:55 CET] <ubitux> fuck this pthread naming shit ffs
[17:45:59 CET] <Daemon404> nevcairiel, only typos :P
[17:46:28 CET] <iive> your grep should have option to not follow symlinks
[17:47:01 CET] <Daemon404> iive, that's not a good argument
[17:47:04 CET] <Daemon404> i could uniq|Sort too
[17:48:09 CET] <iive> well, I guess moving all files is better solution.
[17:49:31 CET] <Daemon404> it was working just fine until the series of 4 or 5 hacks that slowly broke different thinsg were pushed without much review
[17:49:39 CET] <Daemon404> for a "feature" of dubious value
[17:50:16 CET] <wm4> ubitux: heh
[17:50:34 CET] <wm4> why is it so hard to check a specific signature, though?
[17:50:56 CET] <ubitux> i can compile link and execute with a wrong sig
[17:51:50 CET] <nevcairiel> cant you also test headers for presence
[17:52:03 CET] <nevcairiel> i t hought we had crazy tests that can test all these aspects
[17:52:08 CET] <ubitux> feel free to, i'm done with that crap
[17:53:41 CET] <Daemon404> ubitux, you can work on subtitles again instead?
[17:53:44 CET] <Daemon404> ;)
[17:53:51 CET] <Daemon404> you love painful tasks apparently
[17:54:19 CET] <ubitux> well actually
[17:54:23 CET] <ubitux> that's exactly what i was doing
[17:54:25 CET] <ubitux> :p
[18:01:16 CET] <wm4> ubitux: don't know, mpv uses it on osx, glibc, bsd and netbsd
[18:01:27 CET] <wm4> they're all different of course
[18:01:55 CET] <nevcairiel> I use it on windows, only on windows, and its the same on every windows! :P
[18:02:17 CET] <nevcairiel> (although a bit weird, you have to raise an exception with the string as an argument and a ratehr specific code, and it magically works)
[18:02:31 CET] <wm4> does windows have an API for that? which one?
[18:02:36 CET] <wm4> oh
[18:02:52 CET] <nevcairiel> https://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx?f=255&MSPPError=-2147217396
[18:03:22 CET] <wm4> ridiculous
[18:03:22 CET] <ubitux> wm4: well, feel free to submit, i'd be really happy if you come up with a working solution
[18:03:31 CET] <wm4> even requires MS extensions...
[18:03:59 CET] <wm4> ubitux: sorry it's all in waf, and I didn't write the osx and bsd versions
[18:05:53 CET] <nevcairiel> wm4: you dont need to use their extensions, just need to raise and catch the exception
[18:08:42 CET] <nevcairiel> no idea what pthread emulation libraries do, probably just register an exception handler that ignores this one
[18:09:26 CET] <BtbN> What the hell kinda method to set the thread name is that, wtf
[18:09:57 CET] <nevcairiel> its a way to communicate with the debugger to inform it about the thread name =p
[18:29:45 CET] <Timothy_Gu> durandal_1707: is there any asm that needs to be ported for former libmpcodecs filters?
[18:30:57 CET] <durandal_1707> Timothy_Gu: nope, buth vf_phase seems simdable
[18:31:30 CET] <Timothy_Gu> hmm ya
[18:37:25 CET] <nevcairiel> hm I think I'll rebase, update and prepare the new dca decoder for pushing, its been sitting on the ML for so long now
[18:38:33 CET] <Daemon404> nevcairiel, with remvoal of the old one...?
[18:38:39 CET] <nevcairiel> of course
[18:38:41 CET] <Daemon404> ok
[18:38:42 CET] <nevcairiel> why would we have two
[18:38:49 CET] <Daemon404> because ffmpeg is insane
[18:39:06 CET] <Daemon404> i think this is the right move =p
[18:39:16 CET] <Daemon404> but i expect at least a few regressions
[18:39:21 CET] <Daemon404> mostly of broken files
[18:42:28 CET] <Timothy_Gu> as long as it's better than when the new asf demuxer is first committed &
[18:43:14 CET] <Daemon404> i trust foo86 a lot more as a programmer.
[18:46:42 CET] <wm4> and I guess Libav will maintain the old decoder
[18:46:46 CET] <wm4> sigh
[18:46:49 CET] <kierank> going to push cfhd
[18:46:56 CET] Action: Timothy_Gu really needs to set up distcc
[18:46:58 CET] <kierank> when koda finishes
[18:47:31 CET] <Timothy_Gu> durandal_1707: when you say log scaler, you meant using log scale for the freq axis?
[18:50:09 CET] <durandal_1707> no, amplitude axis
[18:50:29 CET] <durandal_1707> its default
[18:50:35 CET] <Timothy_Gu> oh ok
[18:50:58 CET] <Timothy_Gu> so the way i made the graphs is fine?
[18:52:55 CET] <durandal_1707> Timothy_Gu: the height need to be power of two, otherwise half of freq are lost
[18:53:46 CET] <atomnuker> durandal_1707: that ticket is from you, right?
[18:54:06 CET] <durandal_1707> yes
[18:54:26 CET] <atomnuker> you mean the beeps at the start are the artifact, right?
[18:54:43 CET] <Timothy_Gu> durandal_1707: the height of the graph? what do you mean by "half of freq"?
[18:55:58 CET] <durandal_1707> atomnuker: listen flac file and then aac file, aac file have strange sounds in right channel
[18:57:32 CET] <atomnuker> durandal_1707: just tested it, I can't hear anything wrong with the right channel
[18:57:40 CET] <atomnuker> but I don't have my headphones here, so
[18:58:31 CET] <durandal_1707> Timothy_Gu: for 44100 you have 22050 freq, so y axis should have freq values up to 22050
[18:58:38 CET] <Timothy_Gu> ah ok
[18:59:14 CET] <cone-218> ffmpeg 03Kieran Kunhya 07master:3485332bf996: avcodec: Cineform HD Decoder
[18:59:57 CET] <Timothy_Gu> I thought the graph scales automatically with height ...
[19:00:35 CET] <Daemon404> kierank, you forgot to bump the version
[19:00:40 CET] <kierank> bah
[19:01:05 CET] <kierank> should I just commit a bump?
[19:01:15 CET] <Daemon404> yes
[19:01:27 CET] <kierank> what do I bump?
[19:01:44 CET] <Daemon404> should be avcodec minor version bump (and reset micro to 100 if it's >100)
[19:01:55 CET] <nevcairiel> practically everything bumps minor, i dont even know what would bump micro
[19:01:57 CET] <durandal_1707> atomnuker: headphones here
[19:02:41 CET] <Daemon404> kierank, also add it to codecs.texi
[19:02:44 CET] <Daemon404> with the bump
[19:03:06 CET] <kierank> ?
[19:03:08 CET] <durandal_1707> Timothy_Gu: that would technically masquerade real freq output
[19:03:09 CET] <Daemon404> and changelog
[19:03:38 CET] <Timothy_Gu> I see what you mean
[19:03:42 CET] <Daemon404> we not codecs.texi
[19:03:44 CET] <Daemon404> wtf file was it
[19:03:54 CET] <Timothy_Gu> general.texi
[19:03:56 CET] <durandal_1707> Timothy_Gu: it could be done, same as log scaler for freq axis
[19:04:16 CET] <Daemon404> Timothy_Gu, ok
[19:04:20 CET] <Daemon404> kierank, general.texi and changelog
[19:04:21 CET] <Timothy_Gu> what is "window size" in this context
[19:04:25 CET] <Daemon404> it's just a table entry
[19:07:26 CET] <durandal_1707> Timothy_Gu: talking to me?
[19:07:31 CET] <Timothy_Gu> durandal_1707: yeah
[19:08:49 CET] <durandal_1707> Timothy_Gu: now it is directly correlated with height, next power of two defines size off fft window
[19:09:00 CET] <jamrial> nevcairiel: changes in codec specific options and such bump micro
[19:09:43 CET] <Timothy_Gu> now I know I will sound like a total noob but what is an FFT window?
[19:10:44 CET] <cone-218> ffmpeg 03Kieran Kunhya 07master:32bf4a72e326: avcodec: Add forgotten minor bump, add Changelog and add Cineform to general.texi
[19:12:16 CET] <durandal_1707> Timothy_Gu: fast Fourier transform
[19:16:35 CET] <kierank> Bah I lost j-darnley
[19:18:00 CET] <jamrial> kierank: no fate test?
[19:18:23 CET] <kierank> I'll find a suitable sample
[19:19:01 CET] <Daemon404> nobody will beat my sexy elenril sample
[19:30:19 CET] <wm4> (slight morbid curiosity setting in)
[19:31:09 CET] <Daemon404> it's the ficv sample
[19:31:26 CET] <Daemon404> it's not as sexy as you think
[19:36:53 CET] <Timothy_Gu> durandal_1707: seems like GCC is smart enough to automatically vectorize vf_phase
[19:38:48 CET] <durandal_1707> Timothy_Gu: how you found it?
[19:38:56 CET] <Timothy_Gu> disasm
[20:40:55 CET] <atomnuker> Daemon404: why restrict the vectorization enabling patch to x86 only?
[20:41:25 CET] <Daemon404> it's well known to be broken on x86 for quite a while.
[20:41:34 CET] <Daemon404> and i would not enable it on lesser-user platforms without testing
[20:41:39 CET] <Daemon404> it's only been tested on x86.
[20:41:54 CET] <Daemon404> auto-vectorization is not exactly platform independent
[20:42:00 CET] <atomnuker> yeah, makes sense
[20:42:24 CET] <atomnuker> what was it that was broken about auto vectorization? made slower and larger code?
[20:42:43 CET] <Daemon404> slower or miscompiled
[20:42:50 CET] <Daemon404> every tried icl's autovectorization? :P
[20:42:54 CET] <Daemon404> "it's faster, and slightly wrong
[20:43:00 CET] <Gramner> aucto vectorization was known to miscompile stuff which caused alll kinds of fun breakage and debugging
[20:43:28 CET] <Daemon404> didnt icl used to default to "fast float"
[20:43:32 CET] <Daemon404> which just plain broke a lot of stuff
[20:44:11 CET] <atomnuker> wow
[20:45:47 CET] <Daemon404> https://github.com/FFmpeg/FFmpeg/blob/master/configure#L3825-L3827
[20:45:54 CET] <Daemon404> see
[20:45:54 CET] <Daemon404> :D
[20:46:43 CET] <Daemon404> also https://github.com/FFmpeg/FFmpeg/blob/master/configure#L3812
[20:47:04 CET] <Daemon404> https://github.com/FFmpeg/FFmpeg/blob/master/configure#L3809
[20:47:10 CET] <Daemon404> lol... icl.
[20:47:59 CET] <Gramner> (@Daemon404) didnt icl used to default to "fast float"
[20:48:01 CET] <Gramner> they still do
[20:48:10 CET] <JEEB> :D
[20:48:23 CET] <Daemon404> o ok
[20:48:32 CET] <Daemon404> default for icl is to miscompile
[20:48:36 CET] <Daemon404> as seen in links above
[20:49:43 CET] <Gramner> --ffast-math and -fp:fast are good options that are quite useful, but they really shouldn't be on by default
[20:50:02 CET] <Gramner> I'm guessing intel just enabled t by default so they can show how much better they are over MSVC in benchmarks
[20:50:36 CET] <Daemon404> look how fast we are! no, ignore the output, look at the speed!
[20:50:42 CET] <Daemon404> just make everything NOPs
[20:50:44 CET] <Daemon404> much faster
[20:53:20 CET] <Gramner> they are fine to use if you use floating point numbers as just approximate numbers which is quite common so comparing it to NOP is a bit silly. it's a problem if you rely on specific rounding behavior though
[20:56:05 CET] <Daemon404> youre forgettign all the other bits that are enabled by default
[20:56:07 CET] <Daemon404> that miscompiler
[20:56:08 CET] <Daemon404> not just fp
[20:56:11 CET] <Daemon404> s/r$//
[20:58:37 CET] <Gramner> which are those? I mean there's a difference between fp optimizations that changes behavior by design and auto vectorization miscompilations that are just bugs
[20:59:02 CET] <Gramner> because all compilers have bugs
[21:00:03 CET] <Daemon404> Gramner, see linked
[21:00:11 CET] <Daemon404> autovec and simd seem to be enabled by default.
[21:00:14 CET] <Daemon404> and they miscompile.
[21:02:13 CET] <Gramner> gcc also turns auto-vectorization on by default
[21:02:19 CET] <Gramner> unless they changed it
[21:02:33 CET] <Daemon404> i dont think that's a good argument in favour :)
[21:03:03 CET] <Daemon404> gcc at leasts seems to compile most stuff correctly with it on
[21:03:08 CET] <Daemon404> every 2nd thing i build with icl seems to break
[21:03:19 CET] <Daemon404> perhaps a bit antecdotal.
[21:03:27 CET] <Gramner> and gcc vectorization also miscompiles (or at least used to, I havn't really studied in a long time)
[21:04:08 CET] <Daemon404> hey now
[21:04:15 CET] <Daemon404> gcc is good at micompiling all on its own
[21:04:18 CET] <Daemon404> with no autovec
[21:04:30 CET] <nevcairiel> we talked about enabling tree vectorization on recent gcc versions some time ago
[21:04:34 CET] <nevcairiel> not sure what happened to that
[21:04:46 CET] <Gramner> I'm not sure I understand the business model of intel's compilers though. doesn't seem to be that many people buying and using them over msvc/gcc/clang/whatever
[21:04:46 CET] <Daemon404> i mentioned it cause there's a new patch on the ML
[21:05:05 CET] <Daemon404> Gramner, not for C/C++
[21:05:10 CET] <Daemon404> their fortran compiler however
[21:05:15 CET] <Daemon404> very popular in certain communities
[21:05:45 CET] <Daemon404> though that may be small. not sure.
[21:05:51 CET] <nevcairiel> all I know of the intel co mpiler is that its popular in the ricer crowd, but those tend to not buy the compiler, so no clue who does
[21:06:13 CET] <wm4> enterprise companies?
[21:06:18 CET] <Daemon404> ive never known even 1 person who had a legit company
[21:06:20 CET] <Daemon404> er
[21:06:24 CET] <Daemon404> legit intel license
[21:06:30 CET] <Gramner> enterprise usually go for msvc for windows stuff what I've seen
[21:06:39 CET] <Daemon404> msvc from 10 years ago
[21:06:56 CET] <nevcairiel> the performance difference to intel compiler on windows is marginal at best, and compatibility is worse
[21:07:07 CET] <nevcairiel> does it still need this hack to not destroy performance on AMD CPUs
[21:07:11 CET] <Daemon404> it had c99 going for it for a while
[21:07:12 CET] <Daemon404> but thats gone now
[21:07:24 CET] <Daemon404> oh, i know IPP is pretty popular
[21:07:29 CET] <Daemon404> does that work with msvc, or just ICL?
[21:07:30 CET] <nevcairiel> you can use IPP with msvc
[21:07:35 CET] <Daemon404> ah ok
[21:07:36 CET] <Gramner> and to be honest, minor performance differences is largely irrelevant for the vast majority of software nowadays
[21:08:04 CET] <Daemon404> most perf problems i seem to read about are alloc related
[21:08:05 CET] <Daemon404> not cpu
[21:09:10 CET] <Gramner> or just retarded algorithms. e.g. (O^n) when you could make it O(n*log n) or better in like half an hour. an comoilers aren't gonna fix that for you
[21:09:24 CET] <Daemon404> for(){for(){for(){for(){
[21:09:33 CET] <Daemon404> shit we need HPC / supercomputer!
[21:09:37 CET] <Daemon404> ^ every academic
[21:11:04 CET] <jamrial> you say that as if libavcodec isn't filled with nested fors :p
[21:11:35 CET] <Gramner> nevcairiel: yes, intel only enables optimizations on intel cpus
[21:12:02 CET] <Gramner> but it's fine. becase they have a 3px disclaimer about that in the manual
[21:12:41 CET] <Daemon404> jamrial, :D
[21:12:52 CET] <durandal_1707> where are retarded algos in FFmpeg?
[21:13:18 CET] <Daemon404> there's a patch on the ML right now fixing one for wtv :P
[21:14:43 CET] <durandal_1707> I ask for others :)
[21:24:59 CET] <omerjerk> Hey so I was looking at ffmpeg trac
[21:25:21 CET] <omerjerk> Is there any way to find if someone has already sent a patch to the ML for that particular bug ?
[21:26:13 CET] <Daemon404> usually carl notes it
[21:26:21 CET] <Daemon404> in the trac comments
[21:26:23 CET] <Daemon404> but not always
[21:27:32 CET] <omerjerk> I was planning to start with this - https://trac.ffmpeg.org/ticket/5160
[21:28:08 CET] <Daemon404> i dont remember seeign any doc patch for that
[21:28:44 CET] <wm4> the easiest to know is following the ML
[21:29:56 CET] <omerjerk> I follow that. 
[21:30:55 CET] <omerjerk> but it's too many mails and a high chance of missing the mails. 
[21:32:36 CET] <durandal_1707> omerjerk: no such patch have ever been sent
[21:38:15 CET] <omerjerk> thanks. 
[22:13:46 CET] <durandal_1707> when are fosdem recordings going to be available?
[22:23:11 CET] <Daemon404> if it follows last years schedule... 2 months
[22:23:21 CET] <Daemon404> and given their live stream was broken the full day....
[22:23:26 CET] <Daemon404> i dont have high hopes.
[22:23:33 CET] <nevcairiel> there all done, dca decoder nicely wrapped and ready for action
[22:23:53 CET] <Daemon404> git drama origin master:master
[22:24:28 CET] <nevcairiel> all intermediate steps build and pass fate and everything
[22:25:06 CET] Action: Daemon404 pushes a subtle change which breaks dca but not fate
[22:25:13 CET] <omerjerk> Btw there's also fossasia in March. Are you guys coming there ?
[22:25:25 CET] <Daemon404> omerjerk, maybe, but seems unlikely
[22:25:30 CET] <Daemon404> most of us are in europe 
[22:25:46 CET] <nevcairiel> yeah its easier for most to travel to fosdem if your flight is 1-2 hours at most
[22:25:54 CET] <Daemon404> or train.
[22:25:55 CET] <nevcairiel> or god beware you can even take the train
[22:25:59 CET] <omerjerk> okay, I'll be there though.
[22:26:26 CET] <BBB> Daemon404: lies, half of us is in the US
[22:26:34 CET] <wm4> a train would have taken 6 hours or so for me
[22:26:42 CET] <wm4> probably slightly longer than a flight
[22:27:15 CET] <BBB> fosdem was just now?
[22:27:28 CET] <BBB> any interesting talks?
[22:27:35 CET] <nevcairiel> train takes 7 hours for me
[22:27:39 CET] <nevcairiel> would probably favor flying
[22:29:14 CET] <Daemon404> BBB, probably less than half, but yes
[22:29:45 CET] <furkan> can anybody here comment on this issue? https://github.com/ZoneMinder/ZoneMinder/issues/811
[22:29:59 CET] <omerjerk> What do you guys mostly use to edit the source code ? Some IDE or a normal text editor like sublime ?
[22:30:07 CET] <omerjerk> or vim ? :P
[22:30:15 CET] <furkan> same issue is reported here for omxplayer on the raspberry pi (which uses ffmpeg as the back-end) https://github.com/huceke/omxplayer/issues/242
[22:30:21 CET] <nevcairiel> most proably just use their favorite text edito
[22:30:23 CET] <nevcairiel> +r
[22:30:34 CET] <furkan> i posted a screenshot near the bottom of that thread, of what it looks like https://www.dropbox.com/s/8s6m1ssi1wowbky/IMAG0096.jpg?dl=0
[22:30:40 CET] <Daemon404> and some people use their os (emacs)
[22:30:41 CET] <furkan> the problem seems to be related to UDP buffering
[22:31:06 CET] <wm4> rtsp with ffmpeg seems to be an endless source of pain
[22:31:14 CET] <nevcairiel> thats just UDP being UDP
[22:31:24 CET] <nevcairiel> if you stream high bandwidth, you need to increase the kernel buffers
[22:31:24 CET] <cone-305> ffmpeg 03Michael Niedermayer 07master:8619582bdf1b: avformat/format: Replace nodat by enum
[22:31:24 CET] <cone-305> ffmpeg 03Michael Niedermayer 07master:77864be44a0d: avformat/format: Weight the filename extension higher if there is nearly no data after an ID3 available
[22:31:27 CET] <furkan> but there seem to be reports that increasing the buffer size fixes the issue
[22:31:28 CET] <nevcairiel> sad story but true
[22:31:36 CET] <Daemon404> that lines up
[22:31:51 CET] <furkan> would it help, then, to add a paramter for rtsp streams to allow increasing the buffer size?
[22:31:53 CET] <nevcairiel> for some people just increasing the UDP buffer in ffmpeg already helps
[22:32:04 CET] <nevcairiel> i think someone suggested increasing it by default just recently
[22:32:09 CET] <furkan> there seems to be an option already for udp:// streams, but not rtsp://
[22:32:58 CET] <furkan> man reason i'd like to use UDP is to allow multicasting
[22:33:03 CET] <furkan> *main
[22:34:06 CET] <furkan> this is all on a LAN, btw, so no packet loss or anything
[22:38:39 CET] <furkan> for starters, would anybody mind exposing the "buffer_size" parameter that's already there for UDP streams to RTSP as well?
[22:39:10 CET] <nevcairiel> rtsp has a buffer_size option
[22:39:37 CET] <furkan> is this out of date then? https://www.ffmpeg.org/ffmpeg-protocols.html#rtsp
[22:39:51 CET] <nevcairiel> probably
[22:40:31 CET] <furkan> ok i see
[22:40:37 CET] <nevcairiel> but rtsp is a demuxer, so you should be able to simply do ffmpeg -buffer_size 123 -i rtsp://...
[22:47:47 CET] <furkan> i see, i'll try testing it out
[22:50:04 CET] <nevcairiel> hm should adapt the existing synth filter simd for the new synth filter types, the differences between the two look trivial
[22:50:12 CET] <nevcairiel> unless thats the simd jamrial said he already wrote :D
[22:50:32 CET] <jamrial> nope, i wrote lfe1
[22:50:51 CET] <furkan> also, any idea why increasing the kernel's buffer size might help (as some are suggesting)? or do you guys not believe that it would?
[22:51:20 CET] <furkan> or would that only help in the scenario where the application's buffer is filling up?
[22:51:48 CET] <furkan> because i'm assuming that the kernel will just pass the UDP datagrams on to the application, and it's the application's responsibility to buffer until it has a full frame
[22:52:51 CET] <furkan> given that there's no packet loss, and plenty of bandwidth (we're just talking a 6-10Mbps VBR stream here) i just don't see why there should be any trouble
[22:56:22 CET] <nevcairiel> man the asm for that synth filter looks  more complicated than I thought it would be
[22:58:35 CET] <nevcairiel> just doubling all offsets used should probably still make it a valid synth64
[22:58:50 CET] <jamrial> with functions that are full of different paths for different cpuflags i usually remove every preprocessor check to get a cleaner view of wtf is going on
[22:59:19 CET] <nevcairiel> thats probably not a bad idea
[23:00:00 CET] <jamrial> this one function for example removes the main loop if you're using avx on x86_64, but not if you're using anything else
[23:00:21 CET] <nevcairiel> yeah i saw that, it can process all 16 entries in one go on 64-bit
[23:10:22 CET] <kierank> J_Darnley: sorry I spent ages trying to find you
[23:10:37 CET] <nevcairiel> well i'll revisit that idea once its pushed, too much alternative code paths in there to start cleaning it up now
[23:11:07 CET] <nevcairiel> should just enlist kurosu to write the 3 new variants, he wrote the original =p
[23:11:36 CET] <kierank> J_Darnley: if you want to meet we will be around tomorrow
[23:11:54 CET] <J_Darnley> Then I am truely sorry about that.  I did leave without saying bye.  /me hangs head in shame.
[23:12:57 CET] <J_Darnley> I hope you all had a nice dinner.
[23:24:58 CET] <kierank> Well please find me tomorrow
[23:25:02 CET] <kierank> I am leaving late
[00:00:00 CET] --- Sun Jan 31 2016