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

Wed Mar 11 02:05:02 CET 2015

[01:14:58 CET] <cone-112> ffmpeg 03Mark Reid 07master:399e31419ab2: libavformat/mxfenc: write package name metadata
[03:45:08 CET] <cone-112> ffmpeg 03Michael Niedermayer 07master:3170b33e57b2: avfilter/vf_fftfilt: increase RDFT length by 10%
[10:15:44 CET] <ninten> can anyone tell for a general bit stream what is a max no. of channel we can have ??
[10:58:06 CET] <cone-618> ffmpeg 03Anton Khirnov 07master:dc7536ca3d2d: avconv: do not abort immediately if initializing hwaccel fails
[10:58:06 CET] <cone-618> ffmpeg 03Michael Niedermayer 07master:f063a0b33ddb: Merge commit 'dc7536ca3d2dbe47f40cc0fcd0fc2555a84d5f56'
[11:06:20 CET] <cone-618> ffmpeg 03Anton Khirnov 07master:96a06dbaf278: FATE: add support for testing hwaccels
[11:06:21 CET] <cone-618> ffmpeg 03Michael Niedermayer 07master:14ab6f9a268a: Merge commit '96a06dbaf278e8152487e08772946f63bd2a3843'
[11:17:19 CET] <cone-618> ffmpeg 03Martin Storsjö 07master:c83dd2d2a458: rtpenc_mpegts: Free the right ->pb in the error path in the init function
[11:17:20 CET] <cone-618> ffmpeg 03Michael Niedermayer 07master:967afad03b3b: Merge commit 'c83dd2d2a458075a58895c384372f57c1ec26276'
[11:27:30 CET] <cone-618> ffmpeg 03Martin Storsjö 07master:cf402d6fa88a: rtpenc_mpegts: Set chain->rtp_ctx only after avformat_write_header succeeded
[11:27:30 CET] <cone-618> ffmpeg 03Michael Niedermayer 07master:ebdae73125bd: Merge commit 'cf402d6fa88acd647cdff993429583bec8a34fdc'
[11:37:29 CET] <bencoh> hey ... is it just me, or recent ffmpeg releases (tested with 2.5.4 and 2.4.7) wont work with --prefix if the resulting lib folder is not in ld.so search path ?
[11:37:35 CET] <bencoh> I get /opt/dest/ffmpeg-2.5.4/bin/ffmpeg: error while loading shared libraries: libavdevice.so.56: cannot open shared object file: No such file or directory
[11:38:04 CET] <bencoh> looks like a missing -rpath
[11:38:54 CET] <nevcairiel> rpath is not added automatically for distribution purposes, if you want it, add --enable-rpath
[11:38:58 CET] <bencoh> building with LDFLAGS="-Wl,-rpath -Wl,/path/to/lib" works, but ... I dont think that's expected
[11:39:11 CET] <bencoh> nevcairiel: how is --prefix supposed to work now, then ?
[11:39:45 CET] <nevcairiel> just add --enable-rpath if you want to build shared libraries in a non-standard path
[11:39:51 CET] <cone-618> ffmpeg 03Martin Storsjö 07master:0c5e380c2c26: movenc: Don't rely on the fragment index for vc1 info gathering
[11:39:52 CET] <cone-618> ffmpeg 03Michael Niedermayer 07master:8d026861f5c2: Merge commit '0c5e380c2c266d2e8a13c000cc527529db837f10'
[11:39:55 CET] <bencoh> hmkay
[11:41:07 CET] <bencoh> thx
[11:41:38 CET] <nevcairiel> personally i think its odd that it wouldnt look for the libs in the same directory as what its loading, but what can you do
[11:50:10 CET] <bencoh> well, I know autotools enable -rpath through libtool on platforms where it is relevant, but ...
[11:54:24 CET] <cone-618> ffmpeg 03Martin Storsjö 07master:448c8cfe4c53: movenc: Support setting fragment_index before the moov atom is written
[11:54:25 CET] <cone-618> ffmpeg 03Michael Niedermayer 07master:f8f324cc16c3: Merge commit '448c8cfe4c53e9e806effd8505b46d57fa707061'
[13:31:21 CET] <cone-618> ffmpeg 03Xiaohan Wang 07release/1.1:6222ee068eeb: matroskadec: Fix read-after-free in matroska_read_seek()
[13:31:22 CET] <cone-618> ffmpeg 03Michael Niedermayer 07release/1.1:eb1aa871d4ef: h264_cabac: Break infinite loops
[13:31:23 CET] <cone-618> ffmpeg 03Michael Niedermayer 07release/1.1:31b697f19c0a: Merge commit '6222ee068eeb3d29a2bcc4a89ce31effdef5a061' into release/1.1
[13:31:24 CET] <cone-618> ffmpeg 03Michael Niedermayer 07release/1.1:b69c7f20e84f: Merge commit 'eb1aa871d4ef9fc11484de436fa02c352b1b7cac' into release/1.1
[13:45:01 CET] <cone-618> ffmpeg 03Vittorio Giovara 07release/1.1:11f98c83d1c2: img2dec: correctly use the parsed value from -start_number
[13:45:02 CET] <cone-618> ffmpeg 03Reinhard Tartler 07release/1.1:473281193bed: Update Changelog for v9.18
[13:45:03 CET] <cone-618> ffmpeg 03Reinhard Tartler 07release/1.1:42eaec076bbe: Prepare for 9.18 Release
[13:45:04 CET] <cone-618> ffmpeg 03Michael Niedermayer 07release/1.1:eb6d64edef4d: Merge commit '11f98c83d1c2a4eecd213bd94a907831fb36a590' into release/1.1
[13:45:05 CET] <cone-618> ffmpeg 03Michael Niedermayer 07release/1.1:94bd5793198e: Merge commit '473281193bed8dcb3f6954a18d03cf6298d651b3' into release/1.1
[13:45:06 CET] <cone-618> ffmpeg 03Michael Niedermayer 07release/1.1:c5587516ca91: Merge commit '42eaec076bbe2629c466695f71e7aa283a6fda51' into release/1.1
[13:57:38 CET] <cone-618> ffmpeg 03Martin Storsjö 07release/1.1:9841654c158c: arm: Suppress tags about used cpu arch and extensions
[13:57:39 CET] <cone-618> ffmpeg 03Federico Tomassetti 07release/1.1:c17da32ba26d: eamad: check for out of bounds read
[13:57:40 CET] <cone-618> ffmpeg 03Andreas Cadhalpun 07release/1.1:ded9931d1655: rv10: check size of s->mb_width * s->mb_height
[13:57:41 CET] <cone-618> ffmpeg 03Andreas Cadhalpun 07release/1.1:3756b306a259: rmenc: limit packet size
[13:57:42 CET] <cone-618> ffmpeg 03Michael Niedermayer 07release/1.1:dec5586bc734: Merge commit '9841654c158c80e9d525ba03754135d3f34e306e' into release/1.1
[13:57:43 CET] <cone-618> ffmpeg 03Michael Niedermayer 07release/1.1:396b47d2a717: Merge commit 'c17da32ba26d2c333bd9cd4afe38a1b36e3d6cba' into release/1.1
[13:57:44 CET] <cone-618> ffmpeg 03Michael Niedermayer 07release/1.1:0baea332cb42: Merge commit 'ded9931d165544c342795a1b66e4777b6e7daeb0' into release/1.1
[13:57:45 CET] <cone-618> ffmpeg 03Michael Niedermayer 07release/1.1:1beea3b85924: Merge commit '3756b306a259d1376ce90404771c4d0ea7e23162' into release/1.1
[14:19:24 CET] <cone-618> ffmpeg 03Michael Niedermayer 07release/1.1:789f433bc637: utvideodec: Handle slice_height being zero
[14:19:26 CET] <cone-618> ffmpeg 03Anton Khirnov 07release/1.1:62b0462e5fa7: tiff: Check that there is no aliasing in pixel format selection
[14:19:27 CET] <cone-618> ffmpeg 03Reinhard Tartler 07release/1.1:798b3ed3fbc3: doc: More changelog updates for v9.18
[14:19:28 CET] <cone-618> ffmpeg 03Michael Niedermayer 07release/1.1:a2dc8dcb66ea: Merge commit '789f433bc6376e6e45d41ae491007d482fa1df85' into release/1.1
[14:19:29 CET] <cone-618> ffmpeg 03Michael Niedermayer 07release/1.1:d7a8d07fd81c: Merge commit '62b0462e5fa78901380ca229ddb6a7625efd61a2' into release/1.1
[14:19:29 CET] <cone-618> ffmpeg 03Michael Niedermayer 07release/1.1:9e835572f80b: Merge commit '798b3ed3fbc31672e6400e18db37deef03fff44f' into release/1.1
[14:26:22 CET] <cone-618> ffmpeg 03Carl Eugen Hoyos 07master:732f46a6759b: lavd/qtkit: Silence deprecation warnings when using clang.
[14:26:23 CET] <cone-618> ffmpeg 03Carl Eugen Hoyos 07master:87b3c6e28b28: lavd/avfoundation: Silence c99 warnings when using gcc.
[14:26:25 CET] <cone-618> ffmpeg 03Carl Eugen Hoyos 07master:88bf16895a03: lavd/avfoundation: Silence warnings when compiling for iOS.
[14:26:26 CET] <cone-618> ffmpeg 03Carl Eugen Hoyos 07master:1d523ea89ab9: lavc/hevcdsp: Fix compilation for arm with --disable-neon.
[14:26:27 CET] <cone-618> ffmpeg 03Carl Eugen Hoyos 07master:dcddca934c0d: Force -D__EXTENSIONS__ on Solaris.
[14:41:05 CET] <cone-618> ffmpeg 03Ole Andre Birkedal 07master:c8372f800119: avfilter/aeval: Fixed a memory leak in EvalContext::channel_values
[14:44:57 CET] <ubitux> http://linux.softpedia.com/blog/FFmpeg-2-6-Out-Now-Devs-Hope-Google-and-Mozilla-Will-Use-ffvp9-for-1080p-Playback-475163.shtml :D
[14:49:54 CET] <Daemon404> ubitux, does literally anyone like libvpx?
[14:50:01 CET] <Daemon404> even google employees dont like it from what i hear
[14:50:30 CET] <ubitux> no idea
[14:51:03 CET] <Loriker> and why?
[14:51:50 CET] <Mavrik> probably because it's slow and single-threaded still? :)
[14:51:55 CET] <Daemon404> it is MT'd now
[14:51:58 CET] <Mavrik> at least it was a few months ago
[14:51:58 CET] <Daemon404> not that it makes it much better
[14:52:05 CET] <Daemon404> also it's ratecontrol is broken as fuck
[14:52:15 CET] <Daemon404> and the decoder is still hilariously slow
[14:54:30 CET] <Daemon404> i dare say its the worst ratecontrol in an encoder ive ever tried
[14:54:35 CET] <Daemon404> aside from early CUDA
[14:55:51 CET] <ubitux> 14:52 <@Daemon404> and the decoder is still hilariously slow // you mean the encoder?
[14:56:01 CET] <Daemon404> no decoder :P
[14:56:09 CET] <Daemon404> encoder too
[14:56:11 CET] <Daemon404> but also decoder.
[15:00:31 CET] <cone-618> ffmpeg 03Carl Eugen Hoyos 07release/2.6:c43e5faf0393: lavc/hevcdsp: Fix compilation for arm with --disable-neon. (cherry picked from commit 1d523ea89ab93eadd153983f3aefdcfcdede3c9a)
[16:13:14 CET] <Daemon404> on our way to 400
[16:15:38 CET] <nevcairiel> needs more patches on the ML
[16:18:19 CET] <Daemon404> nevcairiel, what you dont like 90s-style bug tracker development?
[16:39:19 CET] <nevcairiel> its not really that, its just one developer afterall
[16:39:35 CET] <nevcairiel> And he did start sending things, so i'm happy
[16:47:04 CET] <debianuser> Hello, I noticed a bug in ffmpeg limiting it to ~40 fps max. I.e. command `ffmpeg -y -f x11grab -r 60 -s 1280x1024 -i :0 -vcodec libx264 -preset ultrafast -pix_fmt yuv420p -t 30 out.flv` does ~40fps instead of 60fps for me and uses 100% of one core only.
[16:47:29 CET] <debianuser> This bug stops people from doing high-quality realtime streams with ffmpeg. :( But it's not in x11grab itself, because `ffmpeg -f x11grab -r 60 -s 1280x1024 -i :0 -t 30 -f null -` easily gets 60fps taking 5% CPU.
[16:48:10 CET] <debianuser> It seems the problem is in bgr0->yuv420p converter inserted between x11grab and x264, because I can get same ~40fps limit with `./ffmpeg -f x11grab -r 60 -s 1280x1024 -i :0 -vf format=yuv420p -t 30 -f null -`
[16:48:48 CET] <debianuser> I thought maybe it's impossible to make it faster so I looked for some examples and the first example I found : http://pastebin.com/2ZAR1kst (not sure if coefficients are correct) - gave me 170fps without any complex optimizations. So the question is - why ffmpeg is so slow? ;)
[16:49:44 CET] <nevcairiel> being slow is not a bug
[16:51:59 CET] <debianuser> Is it a feature? ;)
[16:53:51 CET] <wm4> preferably it's an user error
[16:54:28 CET] <wm4> there's probably a bottleneck
[16:54:31 CET] <wm4> maybe libswscale
[16:58:12 CET] Action: debianuser thought it could be in /libavfilter/formats.c, but there seems nothing about yuv420p, looking in /libswscale...
[16:58:39 CET] <wm4> libavfilter inserts vf_scale for conversions, which in turn uses libswscale
[16:58:45 CET] <wm4> also libswscale will make you blind
[16:59:29 CET] <nevcairiel> (or worse)
[16:59:42 CET] <Daemon404> impotent?
[17:24:04 CET] <shivi> @kierank i have executed 'make fate'
[17:27:56 CET] <ninten> Daemon404,  oing !!
[17:28:03 CET] <ninten> Daemon404,  ping !!
[17:28:37 CET] <Daemon404> what?
[17:29:50 CET] <debianuser> Well, it doesn't seem too complex, /libswscale/ contains just a few files. There're rgb2rgb.* and yuv2rgb.*. But the only rgb2yuv code I found so far is ff_rgb24toyv12_c() func which looks almost exactly as my test sample. Why would it be so much slower then...
[17:30:56 CET] <Daemon404> debianuser, i suggest actually verifying where the bottleneck is.
[17:31:18 CET] <wm4> yeah, it was just a guess
[17:33:55 CET] <Daemon404> glarg... i knew i would regret making the pts==dts assumption for keyframes
[17:34:17 CET] <ninten> Daemon404,  I have one doubt in floating point ALS decoder, during unpacking of difference of mantissa bit stream, it is given that difference value is separated into two parts (Part-A and Part-B). So we have respective flag for PartA in given structure, but nothing is given for PartB so should i just code by taking either PartA is thr or nothing. !!  
[17:34:31 CET] <Daemon404> ... i am not your mentor, ninten 
[17:34:32 CET] <nevcairiel> Daemon404: i could've told you that
[17:34:34 CET] <Daemon404> and i know nothing of ALS
[17:35:30 CET] <Daemon404> nevcairiel, "but pts==dts" was elenril's excuse for why all the seek functions just seek to "a timestamp"
[17:35:35 CET] <Daemon404> without specifying whether it is PTS or DTS
[17:35:39 CET] <Daemon404> or some magic crap.
[17:35:49 CET] <nevcairiel> his excuse fails
[17:36:01 CET] <nevcairiel> its actually those frames that are not references where pts==dts
[17:36:12 CET] <Daemon404> when you think about it, yeah.
[17:36:24 CET] <ninten> Daemon404,  yeah my mentor is not here right now, but last tym i asked one doubt and rectified it so i thought you can help !!
[17:36:31 CET] <wm4> when does pts==dts fail for keyframes?
[17:36:38 CET] <wm4> who is Tym?
[17:37:00 CET] <Daemon404> http://pastie.org/10016563
[17:37:16 CET] <wm4> ah
[17:37:35 CET] <wm4> whatever
[17:37:50 CET] <nevcairiel> keyframes have to be first in decoding order, noone ever said they should also be output immediately, they could be delayed and output much later =p
[17:38:47 CET] <nevcairiel> in a traditional IPBBBB struct, the I wouldnt be delayed, but we're not that traditional anymore
[17:44:27 CET] <shivi> hi, has anyone here worked on FATE previously?
[18:09:08 CET] <wm4> does the -hwaccel option for ffmpeg.c actually work?
[18:09:17 CET] <wm4> I'm trying to use it to test something
[18:09:25 CET] <wm4> but it seems to decode without hwaccel
[18:10:32 CET] <jamrial> seems to work for me with dxva
[18:11:11 CET] <wm4> get_format seems to be successful and inits the hwaccel, but get_buffer uses format==0 (yuv420)
[18:11:58 CET] <wm4> jamrial: like this? ffmpeg -hwaccel auto -threads 1 -i file...
[18:14:11 CET] <jamrial> yeah. doing that i get an extra line saying "Input stream #0:0 frame changed from size:1920x1080 fmt:yuv420p to size:1920x1080 fmt:nv12" and double the performance
[18:16:48 CET] <ninten> do we have Masked-LZ decompression code code already implemented !!
[18:44:40 CET] <nevcairiel> wm4: auto will silently fall back to software if it doesnt work, you can  force a specific option and it'll abort if that hwaccel doesnt work
[18:45:00 CET] <nevcairiel> but yes, it works for dxva for me too
[19:08:42 CET] <wm4> nevcairiel: that's what I first tried, it didn't indicate any failure or success either (just was using sw decoding)
[20:29:56 CET] <cone-618> ffmpeg 03Michael Niedermayer 07master:d3b25383daff: avcodec/012v: Check dimensions more completely
[21:16:29 CET] <Fyr> guys, is it possible to make ffmpeg easily compilable? I mean to create a bundle, like Boost or Qt, to compile it with ./configure && make && make install?
[21:16:59 CET] <Fyr> I just looked through the compilation guide and it was a shocker to me.
[21:17:39 CET] <BtbN> ffmpeg is ./configure && make
[21:18:03 CET] <Fyr> on windows - no.
[21:18:06 CET] <BtbN> sure
[21:18:12 CET] <BtbN> that's the only way to build ffmpeg
[21:18:16 CET] <BtbN> no matter what OS
[21:18:58 CET] <Fyr> "Download git <...> Download MSYS/MINGW <..> mingw-w64-i686-gcc <x264>" etc
[21:19:13 CET] <BtbN> Well, a working build environment is expected..
[21:19:23 CET] <Fyr> yasm, SDL.
[21:19:28 CET] <Daemon404> uh
[21:19:34 CET] <Daemon404> the official docs do not list stuff like SDL.
[21:19:42 CET] <Fyr> http://its.ffmpeg.org/wiki/CompilationGuide/MinGW
[21:19:49 CET] <BtbN> Just use cygwin, it has packages for all that stuff.
[21:19:51 CET] <Daemon404> thats a wiki.
[21:20:07 CET] <Daemon404> http://ffmpeg.org/platform.html#Windows
[21:20:22 CET] Action: Daemon404 will have to closer monitor the wiki...
[21:20:56 CET] <BtbN> cygwin is seriously the easiest way to get a working build env on windows.
[21:21:08 CET] <Daemon404> i'd say that's msys2 nowadays.
[21:21:24 CET] <nevcairiel> cygwin is terrible for building though, despite its easy setup
[21:21:35 CET] <BtbN> why would it be terrible? Works exactly like msys.
[21:21:44 CET] <BtbN> It has a propper terminal, a package manager, all you need
[21:21:53 CET] <Daemon404> because by default it does not use a native compiler.
[21:21:54 CET] <BtbN> setting up msys is way more annoying
[21:21:55 CET] <Fyr> Qt is a big framework and it needs only g++, Python, and Perl in PATH. Boost needs only standard building environment (MSVC or any other). =( only ffmpeg needs many toolchains and libraries.
[21:21:58 CET] <Daemon404> BtbN, no
[21:22:05 CET] <BtbN> You can just install a mingw-gcc via the cygwin package manager.
[21:22:11 CET] <Daemon404> msys2 -> setup.exe -> pacman -Si gcc
[21:22:12 CET] <Daemon404> done
[21:22:15 CET] <BtbN> I build all my stuff that way, works great.
[21:22:30 CET] <nevcairiel> all ffmpeg needs is a compiler and yasm
[21:22:34 CET] <reimar> MSVC is probably outdated, some of the steps should probably be replaced with "just use at least 2015"
[21:22:45 CET] <Daemon404> reimar, 2015 is not out yet
[21:22:48 CET] <BtbN> Isn't 2015 not even in alpha state?
[21:23:14 CET] <Daemon404> 2013 is sufficient on its own
[21:23:17 CET] <Plorkyeran> there's been CTPs out for months
[21:23:18 CET] <nevcairiel> 2013 works perfectly fine
[21:23:20 CET] <reimar> Ok, I'm not quite well-informed about these versions :)
[21:24:03 CET] <reimar> Well, the documentation still mentions the C99 wrapper. Is that needed for 2013? If yes it's not quite "works perfectly fine" IMO
[21:24:10 CET] <nevcairiel> no its not needed
[21:24:23 CET] <nevcairiel> only 2010 and 2012 need it
[21:24:43 CET] <reimar> Ah, I fail at reading documentation.
[21:25:37 CET] <reimar> Anyway ffmpeg should compile if you have bash, make and gcc in path. Yasm (or nasm) is certainly extremely recommended but not strictly required.
[21:26:35 CET] <Fyr> I need NVENC, fdc-aac and x264, but I have to download them by myself and do magic tricks reading many tricky manuals. =(
[21:26:55 CET] <nevcairiel> external libraries are never included in anything =p
[21:27:13 CET] <Fyr> also many other libraries which I don't know, but I will need them =(
[21:27:19 CET] <cone-618> ffmpeg 03Michael Niedermayer 07master:111456682f55: avcodec/mpegvideo: Fix undefined shifts in ff_init_block_index()
[21:27:20 CET] <cone-618> ffmpeg 03Michael Niedermayer 07master:eb7960b2bd36: avcodec/h264: Fix undefined shifts in pack16to32() and pack8to16()
[21:27:43 CET] <reimar> Well, Qt actually includes quite a few other libraries. I don't generally think it's a good idea though.
[21:27:46 CET] <nevcairiel> there are finished binaries with all sorts of features enabled
[21:27:57 CET] <Fyr> why don't we make them internal?
[21:28:06 CET] <nevcairiel> also, if you dont know the libraries, then you dont need them :P
[21:28:16 CET] <wm4> <Fyr> Qt is a big framework and it needs only g++, Python, and Perl in PATH. Boost needs only standard building environment (MSVC or any other). =( only ffmpeg needs many toolchains and libraries. <- lol
[21:28:22 CET] <wm4> Qt is fucking terrible to build
[21:28:35 CET] <wm4> and its bundled libraries don't make it easier (but make people think it's easier?)
[21:28:42 CET] <Fyr> yes, Qt needs many libraries, but they are included in the source, like Freetype or ANGLE.
[21:29:00 CET] <Fyr> they are in the same ZIP you download.
[21:29:06 CET] <nevcairiel> we will never include external libraries, because thats pointless
[21:29:10 CET] <wm4> that's because someone made this zip
[21:29:17 CET] <wm4> you could do the same for ffmpeg, but ffmpeg won't
[21:29:23 CET] <wm4> because it's not ffmpeg's responsibility
[21:29:39 CET] <reimar> Besides the philosophical argument, FFmpeg does not _need_ any of those library, which is a difference to Qt.
[21:30:17 CET] <jamrial> except for fdk-aac (which is non redist), msys2 and cygwin's package managers should offer pretty much all of the popular ones
[21:31:37 CET] <kierank> fdk-aac is redist if you pay the patents :)
[21:31:43 CET] <reimar> Well, for the example given (NVENC, fdk-aac and x264), 2 out of 3 are out due to licensing issues, so there's not much point in discussing bundling them.
[21:32:28 CET] <Fyr> ok, it's easy to create a download tool. =))
[21:32:57 CET] <Fyr> which adds them to proper directories and start compilation process. =))
[21:34:14 CET] <jamrial> packages from managers like apt and pacman are already compiled
[21:34:38 CET] <Fyr> I experienced many troubles in compilation on a native Linux system. =(
[21:34:47 CET] <Fyr> with standard packages
[21:34:55 CET] <reimar> Well, anyone's free to create such a tool, that doesn't have to be part of FFmpeg at all. Personally I don't use any of these, so if I tried to write it, it would certainly not give good results.
[21:35:03 CET] <Fyr> a tool would simplify everything.
[21:35:47 CET] <reimar> You mean "a well done tool". It's fairly easy to write one that will only make things worse ;)
[21:36:57 CET] <Fyr> ok, I'm pretty much sure that yasm, SDL, theora don't have license issues.
[21:37:05 CET] <reimar> But issues compiling against linux distribution packages should probably be considered bugs and reported (not sure how responsive we'd be to those reports I admit)
[21:37:56 CET] <reimar> Why would you want theora? Also SDL is mostly for ffplay, I'd expect most to have no use for it.
[21:38:20 CET] <wm4> Fyr: what you are describing is a package management tool
[21:38:28 CET] <Fyr> sort of
[21:38:37 CET] <wm4> Fyr: they exist for all linux distros and even windows and osx, so what's the issue again?
[21:38:44 CET] <Fyr> reimar, I want NVENC+FDK AAC+x264. =))
[21:40:07 CET] <Fyr> fine, you got my point.
[21:40:10 CET] <Fyr> I got yours.
[21:40:18 CET] <reimar> Fyr, my point was, our real goal is that anyone wanting external libraries does something wrong :P
[21:40:33 CET] <wm4> Fyr: just use msys2, your life will be easier
[21:41:17 CET] <jamrial> Fyr: install msys2, run the mingw64 bat, run "pacman -S mingw-w64-x86_64-gcc yasm mingw-w64-x86_64-x264 mingw-w64-x86_64-SDL", get the nvenc header, get the fdk-aac package and compile it, get ffmpeg and compile it with the libs you got
[21:41:49 CET] <Fyr> ='(
[21:41:54 CET] <reimar> I admit I still have a few issues along those lines when trying to cross-compile to Windows from a Linux computer. Luckily I almost never really need any of these dependencies
[21:42:04 CET] <jamrial> msys2's pacman also has mp3lame, x265, theora, vorbis, opus, if you want them
[21:42:32 CET] <jamrial> it's only missing fdk-aac pretty much
[21:42:53 CET] <wm4> for cross compilation, you can use mxe, which is literally easier to use than compiling stuff on Linux natively
[21:43:08 CET] <wm4> (as long as the lib you need is packaged)
[21:47:44 CET] <reimar> Yeah, I looked at MXE once. I didn't give it a proper chance because it seemed quite complex still (particularly where the compiled stuff actually ends up isn't documented), plus I still had to compile everything.
[21:48:11 CET] <wm4> it's basically a source-based distro
[22:05:49 CET] <Compn> Fyr : what you should ask for is someone to zip up an ffmpeg build enviro for windows
[22:06:04 CET] <Compn> that way you just unzip that, then unzip ffmpeg source and build.
[22:06:12 CET] <Daemon404> ... there is a simple setup.exe with simple instructiobs
[22:06:29 CET] <Daemon404> dont encourage crappy stuff like zipping up ens
[22:06:29 CET] <Compn> but a simple zip is better than .exe instructions, no?
[22:06:31 CET] <Daemon404> envs*
[22:06:32 CET] <Daemon404> ... no
[22:06:35 CET] <Compn> no
[22:06:41 CET] <Daemon404> that exactly  why msys1 sucked
[22:06:46 CET] <Daemon404> it existed as sets of zips
[22:06:47 CET] <Daemon404> with no home
[22:10:33 CET] <nevcairiel> yeah various people collected bundle zips
[22:15:29 CET] <himangi> how can I test a filter?
[22:16:30 CET] <reimar> Testing in what way? Does pointing you to tests/fate/filter-video.mak help?
[22:18:00 CET] <himangi> reimar: not really, I added a detelecine filter.. It compiles fine
[22:18:34 CET] <himangi> reimar: I can run it on few videos which are synthetic but not really sure if thats enough
[22:20:26 CET] <reimar> Well, you can pick any of the vsynth videos and anything from our fate suite for testing in that file for regular automated testing. But if you want to check the algorithm it gets tricky.
[22:20:52 CET] <himangi> reimar: i want to check the algorithm
[22:22:58 CET] <wm4> well, what filter is it?
[22:23:14 CET] <reimar> You can try "randomly" searching http://samples.ffmpeg.org/, but unless you can check it in some automated way that is probably too many useless files.
[22:24:27 CET] <Compn> Daemon404 : just because you dont like portable build env :P
[22:24:51 CET] <Compn> himangi : there is some interlace samples somewhere . not sure where though
[22:24:53 CET] <reimar> Otherwise the major source of telecined content used to be US DVD releases of US TV shows...
[22:29:02 CET] <himangi> wm4: a simple inverse telecine
[22:32:32 CET] <himangi> Compn: I'll try finding the telecined samples..
[22:32:39 CET] <himangi> reimar: cool :)
[22:34:30 CET] <reimar> http://samples.ffmpeg.org/allsamples.txt finds 2 samples with "telecine" in the name btw.
[22:35:23 CET] <reimar> At least some of http://samples.ffmpeg.org/nuv/ are interlaced, and there are more interlaced samples, but whether they are telecine or not isn't sure.
[22:36:20 CET] <reimar> The nuv files might be interesting as they are recorded from analog I believe, which might be a bit different from pure digital content
[22:36:54 CET] <adisas91> Hey is anyone attempting the qualification tasks for Animated PNG project for GSOC?
[22:37:13 CET] <adisas91> I wish to participate in this year's GSOC for that project
[22:37:37 CET] <kierank> everyone seems to be doing that project
[22:38:10 CET] <reimar> As can be seen here: http://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2015-Qualis
[22:38:19 CET] <himangi> thanks reimar, I'll test  for them
[22:38:59 CET] <reimar> Not that this necessarily says anything about how many will complete them. People sometimes just disappear.
[22:40:03 CET] <adisas91> @reimar, hey will we get a feedback from the mentor on wheither we have successfully completed a qualification task or will we have to wait till GSOC results are out?
[22:40:44 CET] <nevcairiel> would be kind of mean from the mentor to not give you any feedback =p
[22:41:13 CET] <adisas91> Haha!
[22:41:16 CET] <reimar> I expect the mentor can tell you when you've completed it and an indication how well. But we won't know how many slots we get until much later if I remember right.
[22:41:16 CET] <himangi> reimar: as I have the filter working at least, can I send in a patch before testing completely to know of any obvious mistakes? This will be my first patch to ffmpeg directly
[22:42:32 CET] <reimar> So your mentor can't tell you whether you'll be accepted or not. That depends mostly on how many slots we get and how well done the qualification task was if we do not get enough for all. I think. I haven't read up on all details.
[22:43:27 CET] <reimar> himangi: sending in patches early on is always recommended :) If you want to make clear it's not done yet you can add [RFC] or so in the subject line.
[22:47:34 CET] <adisas91> @reimar thank you for the information.
[22:49:45 CET] <reimar> adisas91: Also if there are multiple tasks that sound interesting it might make sense to ask the mentors. I'd think doing one qualification task should be ok to qualify you for most. In case we get enough slots we still can't have everyone doing the same thing...
[22:57:33 CET] <adisas91> @reimar hey .. ffmpeg was last selected in 2011 right .. how many slots did it get that time? There are already 9 people working on different projects already! I am thinking of either choosing one of these 9 or starting a new one so I kinda need this information
[22:58:47 CET] <reimar> I don't remember, I think it was something around 8 bit we gave one back since we didn't have enough promising candidates?
[23:00:28 CET] <adisas91> So .. Google gives all the slots you ask or does google cap it in anyway.. If Google doesn't cap maybe I will start a new one that hasn't been covered so far..
[23:02:56 CET] <adisas91> never mind .. I found article about this.. Thank you @reimar :)
[23:06:32 CET] <reimar> adisas91: you might also want to ask on the mailing list. I'm not the best-informed person anyway.
[23:29:09 CET] <cone-618> ffmpeg 03Carl Eugen Hoyos 07master:0637b59c2c6a: lavfi/boxblur: Fix colourpsace list.
[23:33:01 CET] <iive> hi reimar, good to see you around.
[23:33:56 CET] <reimar> Hi iive. Mostly trying to be available a bit for GSoC, but not sure I'll manage to be around IRC much in the end.
[23:34:36 CET] <iive> either way, i'm glad that you are around.
[23:56:39 CET] <cone-618> ffmpeg 03Michael Niedermayer 07master:48df30d36c3c: avcodec/012v: redesign main loop
[23:58:36 CET] <debianuser> Valgrinded x11grab+yuv420p filter - it does not use ff_rgb24toyv12_c() func, instead it goes by: sws_scale()->swscale()->yuv2plane1_8_c()+bgr32ToY_c()+hScale16To15_c()+bgr32ToUV_half_c() (most part is done by hScale16To15_c() func) Not sure how that works yet, and why hScale16To15 is needed for rgb->yuv conversion...
[00:00:00 CET] --- Wed Mar 11 2015