Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

February 2014

1 participants
56 discussions

ffmpeg-devel.log.20140207
by burek 08 Feb '14

08 Feb '14

[00:00] <JEEB> orly, did you opt out? [00:00] <BtbN> no idea [00:00] <JEEB> or did they stop using it? [00:00] <JEEB> I would be surprised tho [00:00] <BtbN> The official way to use the CUDA sdk is via their new Visual Studio addon [00:00] <JEEB> since most SDKs for windows have their own env var [00:00] <BtbN> which handles all the path stuff [00:00] <JEEB> yes, those usually use the env var as well [00:01] <BtbN> it would also cause most distributions to not build it with nvenc support, because they won't setup the cuda and nvenc SDKs on their build environments [00:02] <nevcairiel> the nvenc sdk i downloaded is a zip file, it doesnt come with anything by default :p [00:02] <BtbN> it also depends on the CUDA sdk [00:03] <BtbN> which isn't needed at all, because i dynload a minimal subset of it, just enough to use nvenc [00:04] <nevcairiel> in any case, if the license doesnt allow including the header, then you can't include the header, and anyone that wants to build it with it needs to provide it somehow. [00:04] <BtbN> which would make it quite pointless for me to contribute it at all [00:05] <nevcairiel> its not exactly rocket science to get that one header if you care about that feature [00:05] <BtbN> but you have to build it yourself, as no distribution will ever include it [00:05] <BtbN> and that there is absolutely no default path for that header doesn't help [00:06] <BtbN> there isn't even a default name [00:08] <BtbN> i'm not sure if the header can't be included. The license header seems to allow that, it's just the (L)GPL which might have a problem with it, and i'm not sure what it says about headers [00:13] <BtbN> Hm, nope, can't be included... [00:14] <BtbN> So i can't implement it in any usefull way [00:18] <J_Darnley> Does fate.sh just exit successfully if no changes can be pulled? [00:20] <nevcairiel> i believe it stores the v ersion of the last run in a status file, if thats the same script i'm thinking about [00:21] <J_Darnley> Oh yes, there it is. Line 108: test ... && exit 0 [00:21] <J_Darnley> No wonder I can't get Windows to run it. [00:21] <J_Darnley> I'll remove the version file and try again. [00:57] <cone-595> ffmpeg.git 03Peter Krefting 07master:d5733936d857: configure: Remove dcbzl check for e500v1 and e500v2 architectures [00:57] <cone-595> ffmpeg.git 03James Almer 07master:a4e4948ffe36: x86/cpu: add missing avx2 AVOption in av_parse_cpu_flags() [01:09] <cone-595> ffmpeg.git 03Ronald S. Bultje 07master:5351964a2b52: vp8: fix bilinear C code to work if src_stride != dst_stride. [01:09] <cone-595> ffmpeg.git 03Michael Niedermayer 07master:9707b539b995: Merge remote-tracking branch 'qatar/master' [04:53] <cone-295> ffmpeg.git 03Michael Niedermayer 07master:951793717a28: avcodec/hevc_filter: assert validity of qp predictor input [04:53] <cone-295> ffmpeg.git 03Michael Niedermayer 07master:56985d26d705: avcodec/hevc: clear tab_slice_address in hevc_frame_start() [04:53] <cone-295> ffmpeg.git 03Michael Niedermayer 07master:a18f11158216: avcodec/hevc: clear tab_slice_address of ctb on error. [04:53] <cone-295> ffmpeg.git 03Michael Niedermayer 07master:6ef57f4d9a09: avcodec/hevc: hls_decode_entry: check that the previous slice segment is available before decoding the next [09:36] <cone-240> ffmpeg.git 03Clément BSsch 07master:f21d0beb0cc4: Fix a few heigth/height typo. [10:56] <ubitux> BBB: Carl pointed me out that the failure i told you about yesterday was because i didn't enable the vp9 parser [10:56] <ubitux> BBB: any idea why some tests actually need the parser, and will output something different (??) in case it's not present? [11:10] <ubitux> trac still down :( [11:10] <ubitux> sadness. [12:34] <BBB> ubitux: only if there's composite packets (i.e. one invisible frame - ARF - and a regular frame in a single matroska video packet [12:35] <BBB> ubitux: the parser splits them in two so the decoder can handle individual frames [12:35] <BBB> ubitux: similar to mpeg4 packet parsing in the avi container [12:35] <BBB> ubitux: so yes vp9 decoding absolutely requires the vp9 parser [12:43] <ubitux> BBB: should we add a dependency to the parser in the decoder then? [12:43] <ubitux> or just in FATE? [12:44] <nevcairiel> if the decoder cant really function without it, it should probably depend on it [12:44] <ubitux> -vp9_decoder_select="videodsp" [12:44] <ubitux> +vp9_decoder_select="videodsp vp9_parser" [12:44] <ubitux> i guess. [12:45] <nevcairiel> which brings me to another interesting question, what happens if you run the parser twice? is it smart enough not to wreak havoc? [12:48] <BBB> ubitux: yeah that looks good [12:48] <BBB> nevcairiel: it just ignores itself the second time I think [12:59] <ubitux> BBB: we're decoding at about 2 fps on a beaglebone black ("BBB" ;)) [13:00] <ubitux> i'm going to try to do something about it i guess :) [13:01] <ubitux> (ped1080p.webm) [13:12] <BBB> \o/ [13:12] <BBB> yeah arm is pretty much nothing-done-so-far territory [13:12] <BBB> as is ppc [13:12] <BBB> not that anyone cares about ppc [13:14] Action: Daemon404 remembers the vp9 fpga being larger than an a8 [13:16] <BBB> good thing I don't write fpgas [13:16] <BBB> how big is the hevc fpga? [13:18] <Daemon404> good question [13:19] <BBB> bash-3.2$ wc -l ../../libvpx/vp9/{decoder,common}/*.[ch] ../../libvpx/vp9/common/x86/*.{asm,c,h} | grep total [13:19] <BBB> 28321 total [13:19] <BBB> bash-3.2$ wc -l ../libavcodec/vp9* ../libavcodec/x86/vp9* | grep total [13:19] <BBB> 12530 total [13:19] <BBB> there's also that [13:20] <Daemon404> i was more referring to mobile use [13:20] <BBB> I know [13:20] <Daemon404> though, i think phones are *finally* getting vp8 hw [13:20] <Daemon404> mabe. [13:20] <Daemon404> maybe* [13:23] <kierank> Daemon404: you mean asic, right? [13:26] <Daemon404> probably [13:36] <kurosu__> the hevc decoder is already implemented in mediatek and qualcomm newest flag[sc]hips, but I don't know the respective sizes [13:37] <kurosu__> and I guess it depends on the process, eg 40nm or 28nm, so size is not a proper metrics [13:51] <BBB> bash-3.2$ du -ch libavcodec/{x86/,}vp9*.o|grep total [13:51] <BBB> 508K total [13:51] <BBB> bash-3.2$ du -ch ../../libvpx/x86-64/vp9/{decoder,common}/*.o ../../libvpx/x86-64/vp9/common/x86/*.o|grep total [13:51] <BBB> 932K total [13:51] <BBB> also good stuff [13:54] <ubitux> :) [13:54] <ubitux> BBB: did you have a chance to look at the latest fuzzed? [13:54] <BBB> is that fuzzy7? [13:54] <BBB> or are there new ones? [13:55] <BBB> because fuz7 doesn't crash for me [13:56] Action: BBB tries valgrind [13:56] <ubitux> fuz7 yes iirc [13:56] <ubitux> let me check [13:59] <ubitux> BBB: try with -threads 7 [14:00] <ubitux> BBB: valgrind output here: http://pastie.org/pastes/8708604/text [14:13] <BBB> ==23507== at 0x100AFE0B4: find_ref_mvs (vp9.c:1059) [14:13] <BBB> ==23507== by 0x100B018D2: fill_mv (vp9.c:1181) [14:15] <BBB> good we get the same thing :) [14:18] <ubitux> BBB: so, we want to have prefetch (& friends) for the coeffs decode, some AVX2 and ARM before doing a proper bench, or you want to do that soon? [14:22] <BBB> not coefs decode [14:22] <BBB> prefetch is for mc [14:22] <BBB> avx2 would be nice [14:22] <BBB> arm isn't necessary since we'll bench on x86 anyway, but it'd be nice to have anyway [14:22] <BBB> coefs decode is typically one of the hard-to-optimize slow parts of a decoder; so maybe we just have to live with it being slow? [14:24] <ubitux> fine with me :) [14:24] <BBB> it's up to us what we want finished before we bench, I guess [14:24] <BBB> there's no rules for this; we make the rules [14:24] <BBB> as long as it's fair [14:24] <ubitux> ok [14:24] <BBB> I'll look at the valgrind error tonight [14:24] <BBB> work now [14:24] <BBB> bbl [14:24] <ubitux> i'll have an avx2 cheap laptop in a few days [14:25] <ubitux> probably next week, maybe in 2 [14:25] <Compn> thats a lot of LOC [14:26] <Compn> :) [14:28] <kierank> I have some cargo cult avx2 patches to swscale somewhere [14:43] <kurosu__> iirc, there are a lot of low hanging fruits with audio dsps and avx [15:03] <J_Darnley> Even older SIMD sets have some fruit available. [15:04] <kurosu__> I'm particularly aware of this [15:28] <Compn> is any of the /mips/ ripe for stealing ? [15:38] <kurosu__> oh, I was restricting older SIMDs to < SSE2 [15:38] <kurosu__> as in, some stuff still hasn't x86 SIMD [15:39] <kurosu__> even fewer contributors there [15:42] <cone-240> ffmpeg.git 03Michael Niedermayer 07master:2a03eb4c99f9: avcodec/wmalosslessdec: use sizeof() instead of literal number [15:42] <cone-240> ffmpeg.git 03Michael Niedermayer 07master:ec9578d54d09: avcodec/wmalosslessdec: fix mclms_coeffs* array size [15:58] <J_Darnley> I don't mind writing for SSE2 and earlier [15:58] <J_Darnley> Until 5 months ago that was all I had. (I miss that Athlon64) [16:00] <J_Darnley> I would have done for my flac patch if it wasn't so easy to use one sse4 instruction for multiplying double words [16:00] <kurosu__> I remember people complaining about that SSE was so antiquated they disliked the fact I wrote code for that set [16:00] <kurosu__> I admit I often slip and use SSE2 insn sometimes [16:01] <J_Darnley> If they've ever used a float on x64 code they've "written" sse [16:02] <J_Darnley> Next thing people will say that with the PC being declared dead is that nobody should write any x86 code [16:04] <kurosu__> those were people actually quite seasoned in writing x86 asm, so it might have stemed from the maintenance burden. or something [16:07] <kurosu__> 3dnow (even the float part) is more debatable though as the pcs having this at most are now really old [16:08] <J_Darnley> Aren't new CPUs supposed to be dropping it at some point? [16:08] <kurosu__> since 2010 iirc [16:08] <kurosu__> I mean, newer amd models starting from around 2010 don't have support for 3dnow [16:10] <kurosu__> http://developer.amd.com/community/blog/2010/08/18/3dnow-deprecated/ <- confirmed [16:14] Action: J_Darnley is so very out of touch [17:10] <kurosu__> J_Darnley: btw, there is also the mlp decoder that might benefit from the flac work, but I remember an unorthodox mix of things in this [17:13] <Keestu> what it is all about cortex-v8, ? when i build latest ffmpeg/x264 , and loading in android i get the error /libx264.a(pixel-a.o) for Cortex-A8 erratum because it has no mapping symbols. [17:14] <Keestu> could someone kindly give me a hint ? [17:21] <J_Darnley> kurosu__: I might look tome time. I was working on the encoder. Another James was working on the decoder. [17:22] <J_Darnley> *some time [17:42] <yamyam> Does anybody may know if it is possible to compile ffmpeg arguments to auto start with the binary? like -af aresample=async=1000. I have to create a work around how to give ffmpeg arguments which is called by flussonic streaming server who is compiling the transcoder dynamically.I played around on several injects but winded up getting escaped by the other bin who is calling ffmpeg [17:47] <J_Darnley> yamyam: You could edit ffmpeg.c to change how it makes the filter graph [17:47] <J_Darnley> I can't say whether that is easy though [17:48] <wm4> create a script and let your broken software call that instead [17:48] <yamyam> ok thanks, that's allredy helpful :-) I was plying around in the filter.c and trying to call the option in any case [17:48] <wm4> the script would just call ffmpeg with additional args [17:49] <yamyam> I tried that with a script but the other bin is dynamically shifting with the arguments for ffmpeg (then they escape or crop my argument) [17:58] Action: J_Darnley curses firefox pdf viewer [18:49] <BtbN> What YUV format does AV_PIX_FMT_YUV420P mean? nvenc accepts NV12(Which has its own PIX_FMT), YV12 and IYUV(which seems to be identical to I420). It also supports YUV444, but doesn't specify a specific format for it. [18:50] <nevcairiel> its YV12 with different plane order [18:50] <nevcairiel> YUV is well, Y U V [18:50] <nevcairiel> while YV12 is Y V U [18:50] <BtbN> i know what the formats are, i mean what format AV_PIX_FMT_YUV420P is [18:50] <nevcairiel> i just told you [18:51] <wm4> isn't the difference that the planes are "packed" [18:51] <wm4> and come after each other in memory? [18:51] <nevcairiel> YUV420P is YV12 with a different plane order [18:51] <wm4> maybe packed is a bad word to describe it [18:51] <nevcairiel> there is nothing in ffmpeg that corresponds 1:1 to YV12 as-is [18:51] <BtbN> so i should be able to just copy it directly, swapping the two planes [18:51] <nevcairiel> yes [18:51] <BtbN> and honoring the diffrent pitches [18:52] <nevcairiel> wm4: I dont know of any special behaviour of YV12, always looked like plain planar YUV420 to me, except the different U/V ordering [18:52] <nevcairiel> which is quite obvious if you get it wrong, since all people look like smurfs [18:52] <nevcairiel> (blue skin) [18:52] <JEEB> NV12 is the half-packed one [18:53] <JEEB> YV12 is planar [18:53] <wm4> mplayer also has it, I was surprised when I realized that mplayer's YV12 is actually "swapped" (the same as YUV420P) [18:53] <JEEB> lal [18:53] <BtbN> nevcairiel, ah, so it's IYUV/I420. Which is YV12 with swapped planes [18:53] <nevcairiel> i guess, dont really know those two [18:54] <JEEB> usually it goes the other way [18:54] <JEEB> YV12 is I420 with swapped planes :D [18:54] <nevcairiel> in directshow world I420 isnt really used by anything, they prefer YV12 (or rather NV12) [18:54] <BtbN> but i have to copy it manualy anyway. Or can i request a specific pitch? [18:55] <nevcairiel> no you cannot, the caller sets the pitch in the incoming frame [18:55] <nevcairiel> so unless you can tell the encoder to deal with a specific pitch... [18:55] <BtbN> nope, it justs sets it [18:55] <BtbN> -s [18:56] <BtbN> are there ready to use accelerated copying functions? [18:57] <wm4> memcpy [18:57] <BtbN> that's not realy efficient [18:57] <BtbN> and causes a lot of load just for the copying [19:02] <BtbN> Hm, doesn't look like it. So that's over 3000 memcpy calls for each frame. For example VLC has a set of special functions for plane copying, which use sse4 and other optimizations if possible [19:03] <wm4> lol [19:03] <Plorkyeran> "optimized" memcpys tend to be trivially faster on the author's cpu and slower on all others [19:04] <BtbN> no [19:04] <BtbN> it's not an optimized memcpy [19:04] <BtbN> it's an optimised plane with line stride copy [19:04] <Plorkyeran> aka optimized memcpy [19:04] <wm4> so it doesn't copy the stride padding or what? [19:05] <BtbN> it does, but in a much faster way by using special cpu instructions [19:05] <wm4> haha that attitude [19:05] <BtbN> and the difference between 3000 memcpy calls and one call to the optimized function can easily be 3% vs. 30% cpu usage [19:05] <wm4> don't you think libc authors would optimize their memcpyies this way too? [19:05] <BtbN> memcpy is optimized, but it's called 3000 times for 1080p [19:05] <Plorkyeran> it really can't be 3% vs 30% unless you're comparing -O0 [19:06] <Plorkyeran> the number of calls to memcpy is not particularly relevant [19:06] <BtbN> it is 3% vs. 30%, just by enablind or disabling the SSE optimizations [19:06] <wm4> OTOH, I wouldn't surprised if these OMG OPTIMIZED memcpyies had a high startup overhead [19:06] <BtbN> no, they don't [19:07] <BtbN> http://software.intel.com/en-us/articles/copying-accelerated-video-decode-f… this is an intel article about it, the VLC copy functions are based on it [19:07] <BtbN> they also have a benchmark [19:07] <wm4> oh [19:07] <wm4> this talks about special memory, like video memory [19:08] <BtbN> yes, which is exactly what i'm talking about [19:08] <Plorkyeran> you should probably have mentioned that at some point, then [19:08] <BtbN> i did oO [19:09] <BtbN> i was looking for yuv frame copying functions which honor the line stride [19:09] <kurosu_> memcpy has too do many checks, like the length of the copy, whether dst/src are aligned etc [19:10] <kurosu_> I remember replacing such a memcpy in an fft or mdct function (already x86) and got a 10% speedup [19:10] <kurosu_> (for the function) [19:10] <wm4> BtbN: no, you want a memcpy which works with uncached memory [19:11] <wm4> or something like this [19:11] <BtbN> for 1080p it's over 3200 memcpy calls each frame to change the line stride, which is realy slow [19:11] <wm4> it doesn't have much to do with strides... unless startup overhead matters somehow [19:11] <BtbN> It does, if the strides where the same, i'd be just 3 memcpy calls [19:12] <BtbN> but as they are diffrent, each line needs its own memcpy call [19:24] <ubitux> BtbN: we could probably use that in av_image_copy_plane() [19:29] <ubitux> maybe you can test and send a patch if that provides a performance boost? [19:35] <BtbN> I benchmarked this with some xbmc guys, that's where i got that 30% to 3% from. With a simple memcpy each line solution, we had like 30% cpu usage with 1080p25 video. We then switched to the intel solutin, and got only 3% cpu usage [19:35] <BtbN> *solution [19:37] <BtbN> it's quite complicated to implement, though. Because it needs inline asm or sse intrinsics which aren't available everywhere [19:41] <nevcairiel> the special memcpy the intel article mentions is for copying FROM such memory, not to [19:41] <nevcairiel> and any good compiler has intrinsic inline memcpy so that there is no call overhead [19:42] <BtbN> it's still inefficient to do 3200 memcpy calls, even if memcpy itself is highly optimized [19:42] <nevcairiel> there are no special instructions to write to such special memory anyway [19:43] <BtbN> sse4.1 has some instructions which address the problem quite exactly [19:43] <nevcairiel> no, its for reading from such memory [19:43] <nevcairiel> not writing to [19:43] <BtbN> it's both [19:44] <nevcairiel> you keep believing that [19:44] <BtbN> there's nothing to believe here, i successfully implemented such a function and it was 30% cpu usage to 3% cpu usage. Compared to 3200 memcpy calls with gcc -O3 [19:45] <ubitux> and so, are you going to submit a patch to ffmpeg? [19:45] <BtbN> Maybe later [19:45] <wm4> BtbN: was that main memory to main memory? [19:45] <ubitux> you mean you won't? [19:45] <nevcairiel> your system must be rather weird if simply copying data around gives you 30% load [19:46] <BtbN> copying data around with 3200 memcpy calls creates load [19:46] <BtbN> wm4, what do you mean with main memory? [19:46] <nevcairiel> I can copy 1080p60 realtime with memcpy twice and still get like 1% load [19:46] <wm4> normal, cached system RAM [19:46] <nevcairiel> because you know, my software does it [19:46] <BtbN> yes, if you do one memcpy call for each plane that's no problem. [19:46] <nevcairiel> for every line [19:47] <BtbN> but if you have to do one memcpy call for every line, it creates extreme load [19:47] <nevcairiel> memcpy is inlined, there is very little overhead [19:47] <BtbN> wm4, it does normal system ram -> ucws block -> system ram [19:48] <wm4> I don't think gcc inlines memcpy when the size is runtime variable, but I don't know details [19:48] <ubitux> what's that specific scenario? [19:48] <ubitux> is it just after hw decode or something? [19:48] <BtbN> copying one yuv plane to another yuv plane, with a diffrent linesize [19:51] <ubitux> http://pastie.org/pastes/8709519/text [19:52] <ubitux> this is a ffmpeg -i big_buck_bunny_1080p_h264.mov -vf 'pad=iw*2' -f null - [19:52] <ubitux> so 15% of the time is in copying this [19:52] <ubitux> (it's indeed the memcpy of the pad since removing the filter drop the memcpy from the benchmark) [19:53] <ubitux> maybe we can reduce that 15% with that method [19:54] <BtbN> the vlc code can't be used directly unfortunately, as it relys on gcc features for it [19:54] <ubitux> what's the problem? [19:54] <nevcairiel> its nonsense, it doesn't do anything except in the special case when you need to copy from USWC video memory [19:54] <ubitux> BtbN: we can just add #ifdefery, that's not a problem [19:54] <nevcairiel> my code does several memcpys on a line-by-line base in some cases, and there is no higher load then the cases where its a full-plane copy [19:55] <BtbN> ubitux, but having it working in diffrent compilers would be better [19:55] <ubitux> can be added later [19:55] <BtbN> no idea how widespread the _mm_... intrinsics are [19:55] <ubitux> adding improvements just for one specific compiler/arch/whatever is fine as long as the generic path still works [19:55] <ubitux> no, no intrinsics though [19:55] <ubitux> inline asm would be fine [19:56] <nevcairiel> ubitux: it doesn't help [19:56] <BtbN> it does help... [19:56] <Daemon404> do you guys want big sticks to hit eachother with? [19:56] <ubitux> BtbN: well, i'd suggest you just send a PoC patch to prove what you say :) [19:56] <nevcairiel> I don't know what GCC does, but on MSVC the memcpy is so efficient that there is no difference between one call or 3000 calls [19:57] <nevcairiel> in performance anyway [19:57] <nevcairiel> because memcpy is a intrinsic compiler function [19:58] <wm4> nevcairiel: what code does msvc generate for a memcpy with the size not known at compile time? [19:58] <BtbN> Even if it's inlined, it's still far less efficient than a 4K block streamed copy using sse [19:59] <nevcairiel> memcpy uses sse instructions [19:59] <nevcairiel> even avx [20:00] <BtbN> it does, but it does not optimize accross multiple memcpy calls [20:00] <nevcairiel> proof it then [20:00] <nevcairiel> show an example we can benchmark [20:01] <wm4> all memcpy sse examples I see are quite lengthy and don't really look suitable for inlining [20:02] <BtbN> nevcairiel, i already did a benchmark for this, just in a diffrent software. Nothing that needs proof there. [20:02] <nevcairiel> And i benchmarked the opposite result just now [20:05] <BtbN> also, you can't just enable sse4 optimizations when compiling binary packages. [20:05] <ubitux> BtbN: do you have a thread/post/patch/whatever about the xbmc perf boost? [20:06] <BtbN> ubitux, no, we did that outselves during development [20:06] <BtbN> *r [20:06] <ubitux> what year was that? [20:06] <BtbN> last year... [20:07] Action: ubitux wonders where the memcpy happens in vf_pad [20:10] <BtbN> The way the streamed load/store plane copying works is by using an uncachable intermediate buffer. Which is filled with streaming load instructions, and then written to the destination buffer with streaming store instructions. So yes, it needs special memory, but only as intermediate storage. [20:10] <BtbN> that's something memcpy can never achive [20:10] <wm4> BtbN: I think you keep mixing these 2 things? [20:10] <BtbN> which two things? [20:10] <wm4> uncached special memory vs. calling memcpy "too often" [20:10] <BtbN> why would i mix them? [20:10] <nevcairiel> What you talk about is only really useful for weird memory, like USWC memory [20:10] <BtbN> nevcairiel, no, it's not. [20:10] <nevcairiel> like when copying FROM a GPU [20:11] <nevcairiel> BtbN: then show the proof already [20:11] <BtbN> ... [20:11] <BtbN> I don't have a written 3000 page proof paper ready for you [20:11] <nevcairiel> why would we believe you if all you give us is "i have benchmarked it" [20:11] <BtbN> I can just tell you from personal experience from two diffrent software projects that 3200 memcpy calls ARE inefficient [20:12] <nevcairiel> sure, doing one call is more efficient, but not 3% vs 30% cpu usage inefficient, more 3% vs 4% inefficient [20:14] <wm4> BtbN: the right way to go about this is to write a test program that confirms your claims, and then let us confirm it [20:15] <BtbN> so i should invest maybe a whole day just to prove something where even research papers from intel exist, which you just don't believe? [20:15] <nevcairiel> the paper you linked is about one specific case, reading from USWC memory [20:15] <BtbN> no, it's not [20:15] <nevcairiel> read it [20:15] <BtbN> it uses a 4k USWC memory block as intermediate storage, that's it [20:15] <nevcairiel> This paper explains best known methods for improving performance of data copies from Uncacheable Speculative Write Combining (USWC) memory to ordinary write back (WB) system memory. [20:15] <nevcairiel> no, the GPU memory is USWC [20:16] <BtbN> the other two buffers are normal system memory [20:16] <nevcairiel> i give up, you clearly havent even read the article you linked [20:17] <BtbN> i did, i even implemented a function based on it. And it was several hundret times faster than a memcpy based solution [20:17] <BtbN> for normal system memory to system memory copys [20:18] <nevcairiel> then give us a small test application that uses this function. If you've already written it, it should be a matter of half an hour [20:18] <nevcairiel> otherwise, stop claims you don't want to back with facts [20:18] <BtbN> The xbmc function needs gcc inline asm, so it can't be used right away [20:19] <nevcairiel> we can test with gcc, thats no problem [20:19] <BtbN> but i can't currently, because i only have MSVC here [20:20] <nevcairiel> here have a gcc; http://files.1f0.de/mingw/mingw-w64-gcc-4.8.2-stable-r10.7z [20:20] <BtbN> yes, gcc on windows is super usefull on its own... [20:20] <BtbN> and i don't want a full mingw/cygwin environment on this machine [20:30] <durandal_1707> for how long is trac going to be dead? [20:34] <llogan> durandal_1707: maybe today. probably by tomorrow according to beastd, IIRCAFAIK [21:09] <rcombs> anyone know if there's a way to access the current AVPacket from AVCodec.encode_sub? I need to do av_packet_get_side_data [21:11] <nevcairiel> rcombs: you cannot, the subtitle encode API doesn't accept AVPackets [21:11] <rcombs> ah, that's unfortunate [21:11] <wm4> there's a subtitle encode API? [21:11] <nevcairiel> sure [21:12] <nevcairiel> there is some bitmap sub encoders [21:12] <nevcairiel> vob and dvb, iirc [21:12] <wm4> nice [21:14] <cone-12> ffmpeg.git 03Lukasz Marek 07master:0792b8733570: lavc/evrcdec: fix const misplacement [21:14] <cone-12> ffmpeg.git 03Lukasz Marek 07master:7bb8b8765452: lavc/adpcm_data: fix const misplacement [21:39] <J_Darnley> Does anyone know a good visual representation of the instructions added by sse3 and later? [21:39] <J_Darnley> I mean something like: http://tommesani.com/index.php/component/content/article/2-simd/37-mmx-arit… [21:41] <J_Darnley> Or is there an updated NASM manual that explains the newer instructions? [21:46] <kurosu_> you mean, sorted by generation? ie these is from sse3, these from ss4 etc ? [21:47] <kurosu_> otherwise, if for the full set, I generally check a site in French, or this: http://download.intel.com/products/processor/manual/253667.pdf [21:50] <J_Darnley> It needn't be sorted into generations, I can see that elsewhere. [21:52] <J_Darnley> Yes, that should do [22:06] <kurosu_> the document also has the different sets, but there's value in having them sorted, as it helps not using an sse(y>x) insn in a ssex function [23:21] <j-b> good morning! [23:21] <nevcairiel> morning? did you move to australia? [23:24] <j-b> It's always morning on IRC [00:00] --- Sat Feb 8 2014

1 0

ffmpeg.log.20140207
by burek 08 Feb '14

08 Feb '14

[02:37] <iaaah> Hi, i am trying to do a standard-ish (as close to source) conversion to mpeg. the only settings im using are `-vcodec libx264 -qscale 18`; which gives me a VBV error. In this case the source is a .mov format. How can I set a standard/default VBV? Should I use a different codec? Thanks for your help. [06:14] <znf> Hi. Is there a "simple" way (ie: without involving external scripts) to overlay a short video over a longer video, while "stretching" the shorter one to extend to the duration of the long one? [06:20] <cjhmdm> hello, does anyone know when the trac site will be functional again? it's been giving a 503 error for the past day or so [07:56] <Waster> https://trac.ffmpeg.org/ Service Temporarily Unavailable [08:53] Last message repeated 1 time(s). [08:53] <relaxed> Waster: the devs know [08:53] <Waster> thanks [10:15] <Waster> still down I need docs for tee ASAP..8) [10:44] <relaxed> Waster: http://webcache.googleusercontent.com/search?q=cache:8EYClTmiO8YJ:trac.ffmp… [10:46] <Waster> relaxed: argh, thanks again..))) [11:03] <relaxed> Waster: you're welcome [11:33] <Samus_Aran> is there any way to record the X11 desktop with FFmpeg and maintain correct colours? [11:35] <Samus_Aran> I've tried libx264 and huffyuv. libx264 alters the colours badly. huffyyuv is closer to the original colours, but pixelates badly. [11:35] <Samus_Aran> is there any way to convert the colourspace of the rawvideo for the desktop to something libx264 can use? [11:37] <JEEB> 1) use RGB as output (libx264 has a separate 'codec' name for the RGB version) 2) if RGB is not possible, then make sure you use the same conversion matrix when convertin to and from YCbCr [11:37] <JEEB> any encoder doesn't alter colors at all, unless you are using something with lossy coding [11:38] <JEEB> encoders just encode what they are fed [11:38] <JEEB> the ffmpeg's log should tell you what pix_fmt the input was and what pix_fmt the output was, among other things [11:39] <Samus_Aran> Stream #0:0: Video: rawvideo (BGR[0] / 0x524742), bgr0, 640x480, 245760 kb/s, 25 tbr, 1000k tb [11:46] <Samus_Aran> JEEB: can you explain what you mean by "use the same conversion matrix when convertin to and from YCbCr"? using -codec:v libx264rgb I get videos I can't play in mplayer or vlc [11:46] <JEEB> then both of those are just too old [11:46] <JEEB> and just contain a too old libavcodec to deal with 4:4:4 H.264 [11:47] <Samus_Aran> how can I convert it to something playable on older players? [11:47] <Samus_Aran> it encodes the video fine, or seems to [11:48] <Samus_Aran> profile High 4:4:4 Predictive, level 3.0, 4:4:4 8-bit [11:48] <JEEB> and I mean exactly what I said, for example when you use the "normal" libx264 'codec', the default pix_fmt for that is 4:2:0 YCbCr, so your RGB gets converted to that in a specific way (usually with the BT.601 color matrix, welcome to swscale), and for the colors to (more or less) match (you've already lost information with the chroma subsampling), you will have to convert that YCbCr the same way back to RGB when playing it back [11:49] <JEEB> for 640x480 resolution most things should use the BT.601 color matrix if not specified in the bit stream (although many players just ignore what's in the bit stream and instead always guess by the resolution) [11:50] <JEEB> the chroma subsampling and the fact that YCbCr is generally kept in limited range instead of full range leads to some color degradation, and you really can't do much about that. [11:51] <JEEB> and if you want to encode for end users, then you will almost have to use 4:2:0 YCbCr for compatibility. When you are capturing I recommend using RGB. [11:52] <JEEB> and pretty much everything that's newer than, say, august or so 2011 should support 4:4:4 in libavcodec [11:52] <JEEB> so if something fails at that, it means you've got really old stuff there :P [11:52] <JEEB> or the player just fails at using it [11:53] <Samus_Aran> my ffmpeg is version git-2013-11-16-d7ebeba, libavcodec 55. 43.100 / 55. 43.100 [11:53] <JEEB> well naturally [11:53] <JEEB> your ffmpeg can encode it just fine and most probably is new enough [11:54] <Samus_Aran> is there no way to convert bgr0 losslessly to yuv420p? [11:54] <JEEB> no [11:54] <JEEB> unless you resize to 2x [11:54] <Samus_Aran> that would be fine [11:54] <JEEB> with nearest neighbor [11:54] <JEEB> although to be 100% honest [11:54] <JEEB> since you are converting from full range RGB to limited range YCbCr [11:54] <JEEB> you _will_ have some loss [11:55] <Samus_Aran> I just want to record my screen without the colours looking unusably awful [11:55] <JEEB> if you want to record then RGB is just fine for that [11:55] <JEEB> you only need to convert to 4:2:0 YCbCr for end user encoding [11:55] <JEEB> as in, something you are going to distribute [11:55] <Samus_Aran> if I can't share the video, there's not much point to recording it? [11:56] <JEEB> it's better to keep the original than keeping a degraded version, no? And then you can make a version of it that you can share [11:56] <JEEB> that way no matter how you fuck up with creating the distributed thing, you can always redo it [11:57] <sspiff> Samus_Aran: record RGB, keep that file, but for distribution scale to 2x NN, convert to yuv420 and rescale to 1x, and you've got a high quality original you might use eventually when people start having players that support 4:4:4 H264 and a lower quality version you can share right now? [11:58] <JEEB> sspiff, uhh [11:58] <JEEB> that last part [11:58] <JEEB> > rescale to 1x [11:58] <JEEB> that will pretty much derp it up :P [11:58] <sspiff> Ah right [11:58] <sspiff> sorry [11:58] <JEEB> so you scale to 2x NN in RGB, then convert to 4:2:0 YCbCr [11:59] <JEEB> also to be honest a whole lot of libavcodec-based solutions already support 4:4:4/RGB H.264 [11:59] <JEEB> the support was added around summer of 2011 after all [11:59] <JEEB> stuff like VLC did fix it rather late IIRC, though? [12:00] <sspiff> JEEB: wouldn't rescaling back to 1x only derp up a few pixels? They'd get the b&c of one of their neighbours, but most of the time that should be similar enough, no? Or would that just give us exactly the same as we got without rescaling at all? [12:00] <JEEB> also it's still not 100% lossless because you're converting from full range (0-255) RGB to limited range (16-235 luma/16-240 chroma) YCbCr [12:01] <JEEB> sspiff, it would lead to exactly the same thing as when you had when you just convert the original RGB picture to YCbCr [12:01] <JEEB> not exactly, but it pretty much is the same thing [12:01] <sspiff> alright [12:01] <JEEB> you are resizing 2x in order to not be affected by chroma subsampling, if you downscale that you start getting affected by it [12:02] <JEEB> Samus_Aran, build mpv with mpv-build to gain something you can check that RGB H.264 in [12:02] <znf> record as qtrle on a 1TB hdd, have fun! [12:02] <JEEB> https://github.com/mpv-player/mpv-build [12:02] <JEEB> since I assume you are on linux because you most probably have an old VLC too [12:02] <JEEB> from the repositories [12:06] <Samus_Aran> znf: I've not heard of qtrle, I assume something raw/lossless? [12:07] <znf> Samus_Aran, yeah, will produce huge files though [12:07] <znf> will most likely not be suitable for distribution [12:07] <JEEB> that's exactly the same as if using ffvhuff or lossless RGB H.264 [12:08] <Samus_Aran> I tried playing it with ffplay, and it is closer than either of the other methods, but isn't identical colours to what's actually on the screen [12:08] <Samus_Aran> putting the video over the real window it's obvious [12:08] <JEEB> ugh [12:08] <JEEB> first of all [12:08] <znf> qtrle should be identical to what you see on screen [12:09] <JEEB> how can lossless and lossless not be exactly the same, understand where the goddamn differences are doing and tell ffmpeg not to do that [12:09] <JEEB> it probably 'looks better' because you're not converting away from RGB [12:09] <Samus_Aran> JEEB: what lossless? libx264 isn't lossless [12:09] <JEEB> IT IS [12:09] <JEEB> -crf 0 [12:09] <JEEB> or -q:v 0 [12:09] <JEEB> everything else is not lossless [12:09] <Samus_Aran> that isn't lossless, it's "close to lossless" at least according to the docs [12:09] <JEEB> no [12:09] <JEEB> then you're reading the docs wrong [12:10] <JEEB> crf 0 with 8bit x264 most motherfucking definitely is bit-exactly lossless [12:10] <JEEB> if you have a 9 or 10bit x264 [12:10] <relaxed> you mean -qp 0 ? [12:10] <relaxed> or does -q:v 0 work too ? [12:10] <JEEB> yes, I have not ever set QPs manually in ffmpeg since crf is generally the preferred way [12:10] <JEEB> -q should but the fuck I know [12:10] <Samus_Aran> JEEB: why are you so angry at me when I've done nothing but ask questions? sheesh. I'm no video expert, that's why I'm here. [12:10] <JEEB> anyways, yes -- if your x264 is built as 9bit or 10bit then yes, the CRF range is changed [12:11] <JEEB> but I'm pretty goddamn sure you don't have that [12:11] <Samus_Aran> I have an ffmpeg that is 10 bit, and one that is 8 bit [12:11] <JEEB> so as long as you use crf zero or quantizer zero with x264 (first with 8bit only of course) [12:11] <JEEB> then it is LOSSLESS [12:11] <Samus_Aran> okay? [12:12] <JEEB> as I am trying to tell you for a long time now any difference otherwise is in any possible color space conversion before feeding your crap into the encoder [12:12] <Samus_Aran> so how can I make it the same as what's on my screen in 4:4:4? [12:12] <relaxed> can you pastebin what you're doing? [12:12] <JEEB> your input is RGB so you will want to make sure the output is RGB as well, and that swscale is not going in there somewhere unneededly [12:13] <JEEB> x264 has its own 'codec' name for that [12:13] <JEEB> otherwise use -pix_fmt after -i [12:13] <znf> Samus_Aran, what are you using to feed that into ffmpeg? [12:13] <znf> I mean the video stream [12:13] <JEEB> and if it STILL differs, then something wonky is going on [12:14] <znf> Samus_Aran, have you tried saving your output as a simple .png image and see if that image differs from what's on your screen? [12:14] <JEEB> just... just please learn to differentiate when something is due to color space conversions before feeding your input into an encoder [12:14] <JEEB> and when the actual encoder is doing something [12:14] <znf> ffmpeg -i (...) out.png [12:16] <Samus_Aran> relaxed: http://pastie.org/pastes/8708304/text [12:16] <JEEB> and if there still is a difference even when ffmpeg is not doing any color space conversion, then the problem is somewhere else. Either in the way you're inputting stuff into ffmpeg, or in the way you are checking that output. [12:17] <JEEB> you shouldn't have to set pix_fmt with libx264rgb, just btw [12:17] <Samus_Aran> znf: not today, but when I've used PNGs other times they were exact [12:17] <JEEB> it should be RGB by default [12:18] <Samus_Aran> I have -pix_fmt bgr24 in there because it would complain at me otherwise, but still use it. [12:18] <JEEB> also the swscaler warning is kind of weird [12:18] <JEEB> can you post the output with -v debug before -i [12:19] <Samus_Aran> sure, just a moment [12:21] <Samus_Aran> znf: I output to PNG and it was pixel-exact [12:21] <JEEB> well, that at least tells you that your input is OK [12:26] <Samus_Aran> JEEB: http://pastie.org/pastes/8708326/text [12:26] <JEEB> thank you [12:26] <Samus_Aran> the colours are fading toward white slightly [12:26] <Samus_Aran> or losing some saturation [12:27] <Samus_Aran> less vibrant, more pastel. [12:27] <JEEB> well the only thing that's poking the picture there is the swscale scaler [12:28] <JEEB> if the x264 line contains "qp=0" that means it's lossless [12:29] <JEEB> what are you using to preview that thing? [12:30] <Samus_Aran> ffplay [12:30] <JEEB> what happens if you output PNGs from that H.264 stream? [12:30] <JEEB> with ffmpeg [12:30] <JEEB> let's just say that ffplay has plenty of places it can go wrong [12:32] <Samus_Aran> that is pixel-exact [12:32] <JEEB> ok, that means that the H.264 stream is pixel-exact [12:32] <Samus_Aran> pngs from the mkv [12:32] <JEEB> so it was ffplay herping a derp [12:33] <Samus_Aran> my ffplay may be older, I have too many versions of ffmpeg installed for different things [12:33] <Samus_Aran> ffplay version git-2013-11-16-d7ebeba [12:33] <Samus_Aran> it's newish [12:33] <JEEB> well ffplay is in general something you should not trust too much [12:33] <JEEB> it's a proof-of-concept kind of hackjob [12:35] <squ> how to list time length of many files [12:35] <squ> of many .m4a files [12:35] <JEEB> anyway, an RGB<->RGB conversion in swscale is /generally/ safe, but swscale is swscale, there be dragons [12:38] <Samus_Aran> squ: perhaps parsing the output of ffmpeg -i file, or parsing the output of ffprobe [12:39] <squ> what is different between two? [12:40] <JEEB> ffprobe is made for metadata etc. grabbing [12:40] <JEEB> so you'll probably want to follow its usage manual [12:40] <Samus_Aran> I had an issue with ffprobe where some files would report no duration, but ffmpeg listed the correct durations [12:41] <JEEB> in theory it should do the same things, but it might need some extra settings since you can pick rather well if it will touch the actual streams in the container at all [12:43] <Samus_Aran> squ: I've used something like this in one of my Bash scripts: ffmpeg -i Screen_Capture.mkv 2>&1 | awk -F'(: |, )' '/^ Duration: / {print $2}' [12:43] <Samus_Aran> 00:00:05.10 [12:48] <relaxed> for seconds: ffprobe -show_format -i input.mkv 2>&1| awk -F= '/^dur/ { print $2 }' [12:49] <Samus_Aran> JEEB: thanks for your help [12:50] <JEEB> no problem :) [12:51] <squ> Samus_Aran: thank you [12:54] <Samus_Aran> squ: welcome [13:08] <squ> Samus_Aran: http://vpaste.net/Qsuxc [13:25] <Samus_Aran> squ: looks fine. might want to use ffmpeg if you're not using ffprobe's options to output stream info [13:27] <Samus_Aran> such as ffprobe -show_streams [13:27] <Samus_Aran> goodnight, thanks again for the help, screen capturing is going well. [14:06] <Bname> Hello friends, I was referred here after asking a rather specific question and was told you guys would be knowledgeable in this area. [14:07] <Mavrik> maybe. [14:07] <webchat21323> hello, i want to add scrolling text to a video. the text should only appear on the lower half of the video and scroll upwards. once a line reaches the middle of the screen it should disappear (or better fade away). How can I do that? what is the exact drawtext command ? thanks! [14:07] <Bname> I wish to re-stream live, streaming content from another website to one of my servers to any user who wishes to watch. Could somebody point me in the right direction? [14:08] <Mavrik> hmm [14:08] <Mavrik> how much do you know about basics of video / video streaming? [14:08] <Bname> I'd have to say very little. [14:09] <Mavrik> Bname, ok, first find out which protocol the source uses [14:09] <Mavrik> then find out which streams and which formats has the source :) [14:09] <Mavrik> we can continue then ;) [14:09] <Bname> Alright, I'll try. Thanks Mavrik [14:10] <Mavrik> when you know that it'll be easier to talk :) [14:32] <webchat21323> Can anyone give me some advice? [14:49] <webchat21323> How can i add scrolling text to avideo that's only shown on the bottom half???? [14:54] <webchat21323> At the moment I'm using ffmpeg -loop 1 -i "Pic.png" -i aud.mp3 -c:v libx264 -c:a aac -strict -2 -shortest -r 24 -vf drawtext="fontfile=/windows/fonts/calibri.ttf:textfile='text.txt':fontsize=24:fontcolor=white:y=h-10*t-40" test.mp4 . How to make text disappear after it reached thge middle of the screen ???????? [16:36] <coalado> how can I extract the m4a/aac audio track from a mp4 video file? [16:37] <coalado> just extract the audiostream, direct copy - no conversion [16:41] <Mavrik> coalado, use "copy" as a codec [16:42] <Mavrik> ffmpeg -i <file> -vn -codec:a copy out.m4a [16:46] <coalado> thanks [17:15] <yamyam> does anybody know if it is possible to compile ffmpeg arguments to auto start with the binary? for example -af aresample=async=1000 [17:29] <RenatoCRON> yamyam, can't you just use a bash or alias ? [17:30] <yamyam> well thats the prob, another bin is calling ffmpeg and building the argument chain, so I can''t inject arguments diretly&. thats the reason why I try to compile the filter as autostart on launch [17:31] <yamyam> I hacked around how to trick the other bin but they escape my strings and so I wind up trying to compile the wanted functions as auto active :-( [17:31] <RenatoCRON> yamyam, ok.. it's possible, but I guess you'll need implement the default only if you code [17:32] <RenatoCRON> yamyam, I assume it's linux, maybe you can export $PATH and create a fake ffmpeg script that arrange the arguments and pass it to the real bin [17:32] <yamyam> :-) that's exactly what I didn't wanted to hear (but feared to happen) haha :-) [17:33] <yamyam> Thanks Renato I tried that allready&. but this killed the other bin from the streamig server ans screwed there argument chain [17:34] <yamyam> I think I have to go the hard way and write the function&.. :-( [17:35] <RenatoCRON> yamyam, the thing that you say that scrwed up, is another ffmpeg or ffXXXX ? [17:36] <yamyam> it's flussonic streaming server solution and they call ffmpeg from a compiled erlang bin& and they did nice string escaping why I can't inject arguments [17:37] <yamyam> it's about the good old sound syn issue on low DVB input and they don't want to implement my solution so I have to do it on my own and recompile ffmpeg [17:38] <RenatoCRON> I guess you known what you doing, so you don't removed previous envs from $PATH [17:38] <RenatoCRON> yamyam, also, maybe #ffmpeg-dev can help you more [17:38] <RenatoCRON> sorry, #ffmpeg-devel * [17:39] <yamyam> that's a good idea, wanted to ckeck here first if somebody knows a solution I haven't thought about yet. I will ask them thanks a lot Renato [17:43] <relaxed> yamyam: can't you use ffmpeg directly? [17:44] <relaxed> you could turn on those options by default and recompile ffmpeg, but that would be horrible [17:46] <yamyam> the problem is that if i go with ffmpeg only, the playout server is not exception my input&. they may use metadata or something to check if ffmpeg is called by myself or flussonic [17:47] <yamyam> ok do you know how to turn them on? i searched in the configure file but found no solution - finally I started working in the filter.c file to try to start them [17:47] <relaxed> You would have to edit the source and recompile ffmpeg [17:47] <yamyam> ok :-( I'm allready there&.. just was hoping to get it easier done [17:48] <yamyam> but thanks a lot for sharing your brain for my issue :-) [17:48] <relaxed> can't you peek at how it's runninf ffmpeg with `ps` and mimic it? [17:48] <relaxed> running* [17:51] <yamyam> i tried to strace how they to it, but this guys compile ffmpeg into an erlang bin and redirect all output away&.. I tried to decompile the erlang bin but winded up at encrypted source :-( [17:52] <yamyam> my only solution is to recompile ffmpeg to force the erlang bin to call my "moded" ffmpeg with my additional arguments i guess [18:32] <w-wright> Hello, I'm just wondering but if I have compiled ffmpeg from source and I want to add something else afterwards. Will it wipe out my previous config? [18:33] <relaxed> what config? you'll have to compile a new binary. [18:34] <w-wright> when I do ./configure --enable etc [18:34] <w-wright> in source [18:35] <relaxed> yes, you'll have --enable everything again [18:35] <w-wright> Ok thanks for your time! [18:35] <relaxed> you're welcome [19:28] <Wa4> can ffmpeg do a fade out of an audio file? for example the last 10 seconds [19:28] <klaxa> http://www.ffmpeg.org/ffmpeg-filters.html#afade [19:29] <Wa4> cool [19:29] <Wa4> and now the superduper question: [19:30] <Wa4> I have 200 mp3s in a folder, I want to automate to cut the first 40 seconds of each file and make the last 10 seconds of each file do a fade out [19:30] <Wa4> and delete the original full mp3s [19:30] <klaxa> write a bash script that reads the duration [19:31] <Wa4> ffmpeg accepts this? ffmpeg -i *.mp3 [19:38] <RenatoCRON> Wa4, from what I known, with JPG, yes, so mp3 may work in a similar way [19:39] <RenatoCRON> Wa4, try "%d" [19:39] <RenatoCRON> ffmpeg -f [???] -i %*.mp3 [19:45] <three_le1s> hello [19:45] <three_le1s> I was wondering if i could offload some of the work onto the gpu [19:48] <RenatoCRON> quote "x264's dev IRC has been testing OpenCL lookahead for months. You can join the IRC, request for the patch, compile a binary, and test or use on your own risk." [19:49] <RenatoCRON> three_le1s, http://forum.doom9.org/showthread.php?t=164960 [19:49] <RenatoCRON> theholyduck, #ffmpeg-devel may have more info [19:52] <three_le1s> RenatoCRON: thank you :D [19:54] <RenatoCRON> three_le1s, you are welcome. if you plan to encode x264, you should also look at https://developer.nvidia.com/nvidia-video-codec-sdk [19:55] <RenatoCRON> there's people reporting very fast results with that. [19:57] <ChocolateArmpits> SD MOV files seem to report two different SARs. Is there any way to prioritize one of them for the scale video filter ? [20:00] <theholyduck> RenatoCRON, uguu [20:00] <theholyduck> i wish people could tab complete on last spoke order [20:02] <theholyduck> http://www.youtube.com/watch?v=uOOOTqqI18A if people are intrested in why gpu acceleration of encoding is hard, and what opencl lookahead is [20:02] <theholyduck> its a pretty nice talk [20:03] <pk__> can we encode RGB directly to h264 without converting to YUV? [20:03] <pk__> not asking whether it can be done by ffmpeg..i am asking in general can it be done specification/algo wise? [20:04] <theholyduck> h264 is yuv only as far as i know [20:04] <RenatoCRON> theholyduck, cool, i'd save it on favs. but I guess for a while I'll not use it, because i'm using -preset ultrafast and i'm under AWS until the cost to have a colocation justify [20:05] <theholyduck> pk__, but, ffmpeg can take rgb as input and output yuv h264. its not like you need a seperate conversion stage [20:05] <theholyduck> first [20:05] <RenatoCRON> pk__ I think theholyduck is right [20:05] <pk__> but there is conversion taking place right? [20:05] <theholyduck> pk__, yuv to rgb yeah [20:05] <theholyduck> er [20:06] <theholyduck> rgb to yuv [20:06] <theholyduck> pk__, there are rgb video formats, but h264 is not one of them [20:06] <theholyduck> rgb is just too wasteful [20:06] <theholyduck> compared to yuv [20:06] <pk__> i read somewhere that direct rgb is also possible as if we are doing yuv 4:4:4 [20:06] <theholyduck> yuv 4:4:4 is still yuv [20:07] <theholyduck> rgb is an entirelly different way of storing color data [20:08] <theholyduck> yeah, h264 supports yuv 4:0:0 4:2:0 4:2:2 and 4:4:4 [20:08] <pk__> yes but what happens if say..we take a rgb file and feed to encoder as if it were yuv 4:4:4 [20:08] <pk__> dont you think it will encode and decode fine? [20:08] <theholyduck> pk__, the encoder would do the conversion [20:08] <theholyduck> to make it yuv [20:08] <pk__> oh common [20:09] <ChocolateArmpits> It would get interpreted to horrible results [20:09] <theholyduck> pk__, rgb is fundamentally completely different from yuv [20:09] <theholyduck> if you could get the encoder to parse rgb as yuv, then, it would just break horribly [20:09] <pk__> okay :( [20:10] <theholyduck> pk__, rgb is very inefficient, cause it stores the luminoscity in all 3 channels [20:10] <pk__> yes i know [20:10] <theholyduck> yuv doesnt work like that at all. and so, no way in hell would you be able to parse it correctly [20:10] <theholyduck> pk__, colorspace conversions are automatic and relativly painless [20:11] <ChocolateArmpits> How can you call it inefficient when efficiency isn't in the mind of the format? [20:11] <theholyduck> ChocolateArmpits, well, thats why actual consume video formats dont use rgb [20:11] <theholyduck> or dont support it :P [20:11] <theholyduck> yuv is just a much much more efficient way to go about things [20:11] <pk__> i have a 720p RGB data which i want to pass thorugh a 100Mbps link with least computation [20:12] <theholyduck> pk__, take a look at the ffmpeg huffyuv encoder [20:12] <theholyduck> it might produce bitrates small enough for you. depending [20:12] <theholyduck> and it supports rgb [20:12] <ChocolateArmpits> Well I just think judging rgb on basis of efficiency isn't -correct- because efficiency isn't in the mind of rgb [20:12] <theholyduck> or was it ffv1? [20:13] <theholyduck> one of the speciality ffmpeg encoders [20:13] <theholyduck> does rgb [20:13] <pk__> huffyuv supports rgb? ;) [20:13] <pk__> you mean it converts? [20:13] <ChocolateArmpits> intra frames only [20:13] <ChocolateArmpits> then [20:14] <theholyduck> pk__, well, its not called huffyuv in ffmpeg [20:14] <pk__> how much bandwidth can i compress it to (any idea?) if i do intra only? [20:14] <theholyduck> it has a different name [20:14] <theholyduck> pk__, try it out? [20:14] <ChocolateArmpits> As much as you are ready to give bits [20:15] <pk__> actually i can't try unless i knowthe expected result...it is a totally different architecture and i will have to port the encoder to it [20:16] <pk__> ChocolateArmpits: you mean even with intra only we can compress to very low bandwidth? [20:16] <ChocolateArmpits> I mean with very low latency [20:16] <ChocolateArmpits> If you want bandwith savings you'll have to use inter frame coding too [20:17] <ChocolateArmpits> Which will add to the potential latency [20:17] <pk__> i just want it to make it through100Mbit thats it [20:17] <ChocolateArmpits> Are you familiar with intra and inter frame concepts? [20:17] <theholyduck> hmmi [20:17] <pk__> ChocolateArmpits: yes [20:17] <ChocolateArmpits> ok [20:17] <theholyduck> i could ahave sworn ffv1 or the ffmpeg version of the basic lossless huffman video encoder [20:18] <theholyduck> supported rgb [20:18] <theholyduck> but i cant seem to find any backup info on it [20:18] <theholyduck> pk__, why is it so important to preserve the RGB? [20:18] <pk__> not important [20:18] <pk__> thing is i will need to create a hard chip for this [20:18] <pk__> and i want the least exercise for me :) [20:19] <pk__> after the simplese algo is found i will write the hardware design [20:20] <pk__> huffyuv is lossless ..doesn't that mean it will save me very little in terms of bandwidth? [20:21] <theholyduck> pk__, sure, but its also a very simple codec [20:21] <theholyduck> pk__, but, since it doesnt support rgb afterall [20:21] <theholyduck> you could go with whatever [20:22] <pk__> okay i will convert rgb to yuv..but after that how much do you think huffyuv will compress the stream to? [20:22] <theholyduck> pk__, well, if you are willing to use yuv, theres bunch of other video formats with more options for compression [20:22] <theholyduck> huffyuvs virtue is that its fast and simple and gives a bit of gain [20:23] <theholyduck> pk__, i dont remember how much, been a while [20:23] <theholyduck> try it out yourself with ffmpeg [20:23] <theholyduck> see what numbers you get on your content [20:23] <pk__> right [20:23] <pk__> i can try it first using ffmpeg and then port later if it satisfies [20:24] <pk__> is there some simple lossy intra only algo also? [20:25] <pk__> is (m)jpeg easy? [20:25] <theholyduck> relativly i guess [20:25] <ChocolateArmpits> mjpeg is intra and a stack of jpegs [20:30] <pk__> okay for testing huffyuv i have this video mp4(1080p h264 + mp4a audio)...how to dump a 10 second raw YUV 420 out of it and then pass it through huffyuv? [20:30] <pk__> using ffmpeg [20:31] <pk__> can you please tell me a command line? [20:32] <theholyduck> ffmpeg is pretty easy to use and decently documented these days [20:32] <theholyduck> do some googling :P [20:32] <theholyduck> and trial and error? :P [20:32] <pk__> okay [20:32] <pk__> you are right [20:33] <pk__> my computer is pretty slow..do you think it will be possible to process only 10 seconds or so? [20:33] <pk__> just yes or no? rest i will find on google [20:34] <theholyduck> pk__, sure [20:34] <theholyduck> theres a commandline to restrict the number of frames it uses [20:34] <theholyduck> and i think one to set the endpoint in time [20:34] <theholyduck> aswell [20:35] <pk__> okay let me try [20:35] <pk__> i should convert firsmt to raw 420 file and then huffyuv or i can directly go for convert to huffyuv? [20:37] <theholyduck> just go directly [20:37] <theholyduck> ffmpeg can handle any colorspace conversion [20:38] <pk__> you were saying that it is not called huffyuv in ffmpeg then what is it calles? [20:38] <theholyduck> ffhuff or something [20:38] <theholyduck> should be some documentation on what flag to use somewhere [20:39] <theholyduck> i have to run away now [20:39] <theholyduck> some work needs doing [20:40] <pk__> okay thank you [20:40] <pk__> so much for you help [20:45] <llogan> libx264rgb [20:47] <pk__> llogan: what is libx264rgb? [20:47] <three_le1s> RenatoCRON: x264 already has it merged [20:50] <ChocolateArmpits> Does anyone know if 1st pass encoding takes encoding settings into account ? [20:55] <zennist> Hi guys [20:56] <zennist> I want to convert videos for best compatibility/smallest size; used for html5 [20:56] <zennist> anyone has any advice? [20:56] <ChocolateArmpits> compatability with what exactly? [20:56] <llogan> pk__: ffmpeg -h encoder=libx264rgb [20:56] <zennist> to be used as html5 video [20:57] <llogan> ChocolateArmpits: which encoding settings? what encoder? [20:58] <ChocolateArmpits> llogan, x264, bitrate, maxrate, bufsize, default x264 presets [20:58] <pk__> llogan: that will convert rgb to h264? [20:58] <llogan> pk__: Supported pixel formats: bgr24 rgb24 (i didn't really read the wall o' text...so maybe i'm out of context) [20:59] <pk__> llogan: yes you certainly are :) [20:59] <zennist> :P anyone? settings for html5 video that gives me smallest size [21:01] <llogan> zennist: depends on the format you want to use [21:01] <llogan> (and the browsers too) [21:01] <zennist> llogan: mp4 would be [21:02] <ChocolateArmpits> llogan, what does console output have to do with what 1st pass does? [21:02] <llogan> i want to see all of your options and your ffmpeg version so i can give you an accurate answer [21:03] <DeadSix27> anyone knows a backup page for http://trac.ffmpeg.org/ ? [21:03] <DeadSix27> since: Service Temporarily Unavailable [21:03] <ChocolateArmpits> DeadSix27, try google cache [21:03] <DeadSix27> ah right [21:03] <llogan> zennist: what are yout input formats? [21:04] <llogan> hopefully trac will be back today or tomorrow [21:04] <zennist> llogan: mhh, a bunch of mp4's I think. And also mov's. [21:04] <llogan> maybe you don't have to re-encode then [21:06] <zennist> llogan::'( but they are too big..and are exceeding my website storage limit [21:06] <llogan> zennist: a typical command can look like: ffmpeg -i input -c:v libx264 -crf 23 -preset medium -movflags +faststart -c:a libfdk_aac -vbr 5 output.mp4 (probably fine for progressize download) [21:07] <llogan> use the highest -crf value that gives you an acceptable quality. use the slowest -preset that you have patience for. [21:08] <rcombs> anyone know if there's a way to access the current AVPacket from AVCodec.encode_sub? [21:08] <llogan> zennist: crf range is a log scale of 0-51. 0 is lossless. 18 is roughly "visually lossless" (depending on input), 23 is default. [21:08] <zennist> llogan: crf...full name? Sorry for being a noob [21:08] <llogan> constant rate factorb. the b is for bargain. [21:08] <llogan> constant rate factor [21:08] <rcombs> erm, wrong channel [21:10] <ChocolateArmpits> llogan, I don't have access to my workstation currently but the command line for the 1st pass would go like this: [21:10] <ChocolateArmpits> %ffmpeg% -y -i input.avi -vf "[in]yadif=0:-1:0[yadif];[yadif]hqdn3d=4:4:6:6[denoise];[denoise]scale=out_h*dar:576:0[out]" -sws_flags bicubic -pass 1 -v:c libx264 -preset slow -b:v 430k -maxrate 680k -bufsize 200k -an -pix_fmt yuv420p output.mp4 [21:11] <ChocolateArmpits> probably NUL instead of output.mp4 [21:13] <ChocolateArmpits> oh forgot -profile:v main [21:14] <llogan> ChocolateArmpits: "fastfirstpass" is a default settings, IIRC, unless you use slow-firstpass via x264-params or -x264opts (or maybe disable it with -fastfirstpass 0 libx264 private option) [21:15] <llogan> ChocolateArmpits: http://mewiki.project357.com/wiki/X264_Settings#slow-firstpass [21:16] <llogan> shows a lost of settings that -pass 1 will apply [21:16] <llogan> *list [21:16] <ChocolateArmpits> The option describes placebo preset as enabling slowfirstpass too [21:17] <llogan> yes, but placebo is a joke. that's why it's called placebo to placate the "i wanna teh best encodning settingz" users. [21:17] <ChocolateArmpits> Can it be believed that the first pass doesn't take into account bitrate settings ? [21:18] <ChocolateArmpits> Or even the profile if trellis is off ? [21:20] <llogan> ChocolateArmpits: you can move use format=yuv420p within your filtergraph instead of -pix_fmt yuv420p so you can have more control as to when it is used [21:20] <llogan> same with sws_flags (see "flags" option for scale filter) [21:20] <pk__> ffmpeg -i d:\videos\ganjababe.mp4 -vcodec huffyuv -vframes 1 out.huff this is not working ..how do i dump raw huffyuv? [21:21] <pk__> it says Unable to find a suitable output format for 'out.huff' [21:21] <ChocolateArmpits> llogan, I believe pixel format transforms are done after applying video filters [21:22] <llogan> that's my guess if you use -pix_fmt, but you can also use the format filter instead so you can tell it when to do that [21:23] <ChocolateArmpits> I've had that previously but decided to cut down on filters used [21:23] <ChocolateArmpits> It would've went to the very end eitherways [21:24] <ChocolateArmpits> my inputs are 4:2:0 and 4:1:1 most times [21:26] <llogan> some DV inputs? [21:26] <ChocolateArmpits> DVCPRO and DVCAM for the time being [21:29] <ChocolateArmpits> back to the topic llogan, so do you know if first pass takes bitrate rendered video and then makes decisions or does it not do that and only access filters at most? [21:29] <ChocolateArmpits> Because the settings listed in the mewiki seem more like to speed up the process [21:30] <ChocolateArmpits> potentially to not use settings the firstpass won't be making decisions on at all [21:30] <llogan> sorry, but i don't quite understand your question. [21:30] <ChocolateArmpits> what does firstpass do? [21:31] <llogan> http://mewiki.project357.com/wiki/X264_Settings#pass [21:32] <ChocolateArmpits> >contains information about every input frame [21:33] <ChocolateArmpits> So I presume it doesn't render the video and then write information, but rather takes input only ? [21:34] <ChocolateArmpits> So having encoding information, video filter information would prove useless and only add to the encoding time ? [21:34] <ChocolateArmpits> If firstpass only does is write information about the input [21:34] <llogan> no. keep everything the same. just change to -pass 2 and add your audio info on the second pass. [21:35] <ChocolateArmpits> Are you saying those settings matter for the firstpass ? [00:00] --- Sat Feb 8 2014

1 0

ffmpeg-devel.log.20140206
by burek 07 Feb '14

07 Feb '14

[00:40] <cone-691> ffmpeg.git 03Janne Grunau 07master:5a0bccd2810d: fate: force the simple idct for xvid custom matrix test [00:40] <cone-691> ffmpeg.git 03Michael Niedermayer 07master:927696aab258: Merge remote-tracking branch 'qatar/master' [02:41] <cone-691> ffmpeg.git 03Timothy Gu 07master:4a37e2977cb2: libfdk-aacenc: disable hard version requirements [02:42] <BBB> Skyler_: oh wow thanks [02:42] <BBB> ubitux: really anything is fair game now, I don't think anything in particular is pressing anymore - really whatever you fancy [02:45] <BBB> ubitux: I think skyler's idea has merit btw, I was pretty much ready to move the /= 2 out of the loop (see my patchset), and then it may help [02:46] <BBB> ubitux: and as for simd, perhaps we're at a point where we need to start thinking about avx2 [02:47] <BBB> ubitux: that'll be a whole new world of fun, and things like mc can easily shave off another few percent [02:53] <BBB> ubitux: also I think the reason it's long in that instruction is because you just loaded ecx from memory 2 lines up, so it's still waiting for cl to finish loading (load latency, basically) [02:55] <BBB> ubitux: (and Skyler_ also) another thing is prefetch - absolutely nothing done there, and given the massive waits in the load statements of mc, I think that can gain another few %s [02:59] <cone-691> ffmpeg.git 03Loren Merritt 07master:9c978f243a47: flac/x86: add ff_flac_lpc_32_sse4() [03:00] <michaelni> BBB, btw do you want to mentor anything (in case ffmpeg is accepted this year) ? [03:00] <BBB> michaelni: it's kind of tricky because I'm only online 30 minutes a day... [03:01] Action: michaelni is impressed by how much BBB can do in 30 min per day [03:01] <BBB> it's mostly weekend stuff ;) [03:02] <BBB> can smarter mentor someone? or does he want to be a student? [03:03] <michaelni> if he wants yes of course he can [03:04] <smarter> I don't think I'll have the time to do either :) [03:04] <michaelni> :( [03:07] <smarter> if I have the time I may work informally on some stuff, like some basic 32 bits vp9 asm [05:09] <rcombs> can AVCodec.encode_sub() access the AVPacket for the subtitle being encoded? (Is there one?) [07:26] <ubitux> BBB: oh sure it probably has merit, i was just merely testing it :p [07:26] <ubitux> BBB: about avx2 i'm still waiting for the hw to arrive, dunno how long it will take.. [09:17] <Skyler_> BBB: did the patch help at all for you? I guess I'd divide it into ~2-3 separate ideas [09:27] <ubitux> anyone a bit familiar with the build system to explain me why something like --disable-all --enable-ffmpeg doesn't actually build ffmpeg? [09:35] <nevcairiel> probably lacks a dep which is not automatically enabled [09:38] <ubitux> the _select entries are not enabled [09:41] <ubitux> actually, the _deps aren't either [09:43] <ubitux> oh well, whatever [09:55] <ubitux> for some reason, i have fate-vp9 mismatches when building ffmpeg with ./configure --disable-everything --enable-decoder=vp9 --enable-demuxer=matroska --enable-muxer=null,framemd5 --enable-encoder=rawvideo --enable-protocol=file,pipe --disable-programs --disable-doc --enable-ffmpeg [09:55] <ubitux> like, md5 are mismatching [09:56] <ubitux> maybe because of something missing in sws [11:31] <j-b> drv: ping [11:48] <wm4> so, could OpenMAX (IL or DL) not be supported by libavcodec? [12:07] <av500> sure [12:08] <av500> you can glue it in [12:08] <av500> (and cry) [12:54] <BBB> Skyler_: will try over the weekend, didn't test yet (hard to do on weekdays) [12:54] <Skyler_> np, not a big deal, I was just futzing when I was bored [12:55] <BBB> ubitux: let's do prefetch then! that's actually fun [12:56] <BBB> ubitux: especially because I think our 2pass decoding solves a central problem we have in vp8/h264 - we don't know the mv yet of 2 blocks ahead (with 2pass, we do!) [12:59] <Compn> ubitux : carl usually fixes those build things [12:59] <Compn> if you report it to him [13:23] <pross-au> who's idea was it to have a webp codec that creates an instance of the vp8 decoder [13:30] <Daemon404> i am impressed that demuxing_decoding.c is architected so rigidl that i cannot fix a small problem with it without efactoring [13:40] <nevcairiel> a lot of effort went into making ensuring that [13:44] <BBB> Skyler_: also, please be bored again ;) - but seriously, if you have other ideas (coef decoding is indeed big and slow), we're very much open for other ideas worth exploring in that area (I've tried to do a bunch of stuff with context reading/writing in my vp9-context-opts branch on github, but coef decoding itself the only idea I had so far was to put the /2 out of the loop by making tx32x32 a separate function from the others [13:45] <BBB> (separate function is ofc not duplicate code, just putting inline and having 2 callers, one decode_coeffs_b_not32 and one decode_coeffs_b_32) [13:47] <Skyler_> most of my changes there were to eliminate the 1 in "top + left + 1 >> 1" [13:47] <Skyler_> via hackery and changing the shift to a 2 [13:47] <Skyler_> also things like avoiding the qmul multiplication when val = 1 [13:48] <Compn> pross-au : i think google [13:48] <Skyler_> I get the feeling there's something to be gained via optimizing branches and cmovs, like. the cmov version is actually slower on my system overall, which is weird? since HAVE_FAST_CMOV should be fast on a core i7 [13:49] <Skyler_> but it seems to depend on which arithdecode call. like. I would /guess/ that you'd want to make a prob=250 call branchy, since it'll be super predictable. [13:49] <Skyler_> and so cmov maybe isn't worth it there? I'm not sure [13:49] <Compn> Skyler_ : cmov stuff was benchmarked for mpeg4 asp codecs back in the p4 days. i dont think it has been rebenched as of i7 days. i could be wrong... [13:49] <Skyler_> it might also be because with the cmov version of the arithdecode code, it can't replace "bit = 1" with "bit = 1 << 2" or something like that [13:49] <Daemon404> [12:23] <@pross-au> who's idea was it to have a webp codec that creates an instance of the vp8 decoder <-- only for lossy :P [13:49] <Daemon404> lossless webp != webp [13:49] <Skyler_> Compn: I mean speciically the vp56 asm, which is predicated on that [13:49] <Skyler_> (it's a lot newer, I think I wrote it? not quite sure) [13:49] <Compn> ah [13:50] <BBB> hm, it's certainly true I didn't look veyr closely which ones should be _branchy and which ones shouldn't [13:50] <Skyler_> on my system it didn't actually configure with cmov by default?? I wonder what march you need to set for that [13:51] <Skyler_> but setting it in config.h slowed things down, so, I was curious [13:51] <Compn> so whats the question? is cmov on i7 a good idea ? [13:51] <Skyler_> well, more like in what contexts is it? like. which arithdecode calls ~really~ want cmov, and which don't [13:51] <Skyler_> and if cmov is slower, why, and is it just a problem with not being able to propagate constants or what? [13:51] <Compn> ah, way above my skills to figure that out :) [13:54] <Compn> intel has some docs on optimization reference [13:54] <Compn> http://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-optimiza… [13:54] <Compn> is it what you want, probably not [13:55] <Compn> code optimizations to eliminate branches using cmov [14:04] <BBB> Skyler_: this is just vp9 right? [14:04] <BBB> Skyler_: I'm pretty sure it's just me using _branchy vs non-branchy wrong [14:05] <Skyler_> I think you're using it right [14:05] <Skyler_> any time you have a control flow branch you want to use the _branchy version [14:06] <Skyler_> because it'll be merged [14:06] <BBB> right that's what I tried to follow in the code [14:06] <BBB> maybe cmov is indeed slow on 64bit [14:06] <BBB> or on i7 [14:06] <BBB> or both [14:06] <BBB> or rather, branches are fast [14:06] <Skyler_> I don't think it's slow, it's just a question of when it's worth it, I think? [14:07] <Keestu> what is this libpostproc? i dont get this .a file while building with latest ffmpeg ? [14:07] <ubitux> Keestu: --enable-gpl [14:09] <Keestu> ubitux, there you go ;). may i ask what it is used for ? [14:09] <BBB> ubitux: predecessor of libavfilter, has some video post-processing filters (like deblock, etc.) [14:09] <ubitux> deblocking filters [14:10] <ubitux> Keestu: see vf_pp for instance [14:10] <ubitux> which uses it [14:10] <Keestu> ubitux, Ok. if i want to enable every options by default any way to do while building? [14:12] <ubitux> --enable-gpl should add quite a bunch of things, remaining are external libs, and you need to specify them manually [14:12] <ubitux> like libx264, libvpx, etc [14:14] <Keestu> makes sense for the external libs, when i enable for example --enable-libx264, it enables only the wrapper that are in ffmpeg, it doesn't require x264 while compiling right ? [14:14] <Daemon404> uh [14:14] <Daemon404> yes it does [14:14] <Daemon404> linking is a thing. [14:14] <Keestu> not loading dynamically the library ? [14:15] <Keestu> ie: x264 lib. [14:15] <ubitux> there is no dynamic loading [14:15] <Daemon404> no [14:16] <Keestu> Ah. then it is yes, we ofcourse need to be compiled with libx264. :). Sorry if my questions are very basic. [14:16] <Keestu> somehow i have to start from the ground ;). [14:21] <Daemon404> holy shit a vp7 decoder [14:22] <JEEB> yeh pross-au was talking about it [14:26] <pross-au> the supply of "new" codecs is dwindling. [14:28] <BBB> oh sweet vp7 [14:30] <j-b> No fucking way... [14:32] <BBB> lol [14:32] <j-b> It's like a joke, gone bad [14:36] <BBB> pross-au: have you confirmed the changes to vp8dsp don't slow down vp8? [14:36] <BBB> pross-au: otherwise I'd love to give this some review over the weekend, don't wait for me before you commit it, but it surely looks interesting [14:36] <BBB> and non-bitexact mc, omg back to mpeg12days [14:36] <BBB> anyway work, bbl [14:45] <Compn> pross-au : no supply of "new" codecs? so many binary codecs in mplayer.... [14:45] <Compn> redcode codec too? [14:45] <Daemon404> dont forget vc-5! [14:45] <Daemon404> Compn, the proble with redcode isnt the codec [14:45] <Daemon404> its the colorspace [14:45] <Daemon404> which i bayer. [14:45] <Daemon404> is* [14:46] <Daemon404> (codec is just jpeg2000) [14:46] <Compn> i think someone committed the bayer [14:47] <Daemon404> no [14:47] <Compn> i asked someone to resend the bayer... [14:47] <pross-au> i have to cleanup those bayer patches [14:47] <pross-au> rings a bell ... [14:47] <Compn> yes, i keep bugging pross-au about it :) [14:48] <Compn> http://ffmpeg.org/pipermail/ffmpeg-devel/2012-December/135778.html [14:48] <Compn> so olddd [14:50] <Compn> Daemon404 : but thanks, i didnt know r3d was just jp2k + bayer. all i knew was the bayer [14:51] <Daemon404> it has a custom container [14:51] <Compn> they always do [15:13] <smarter> so, what's missing to complete the collection of VP* codecs? :) [15:16] <Compn> vp4 ? [15:20] <Compn> and whatever duck tm20 vp2x stuff from way back in the day [15:24] <Compn> there maybe one or two truemotion 2 variants not supported [15:39] <Compn> kostya is the one to talk to about vp* :) [16:36] <cone-595> ffmpeg.git 03Martin Storsjö 07master:49ec55159564: vp8: Use 2 registers for dst_stride and src_stride in neon bilin filter [16:36] <cone-595> ffmpeg.git 03Michael Niedermayer 07master:c73445a45cdb: Merge remote-tracking branch 'qatar/master' [16:36] <cone-595> ffmpeg.git 03Timothy Gu 07master:474db7a696a3: doc/texi2pod: make references bold [20:17] <kurosu_> michaelni: do you remember why you ever split out synth_filter out of dca ? [20:18] <kurosu_> I would have expected it to end up in dca dsp stuff, except if it is reusable [20:18] <kurosu_> by what is my question [20:30] <michaelni> kurosu_, thats quite long ago, but yes i think the idea was to reuse it [20:33] <michaelni> sadly i dont really remember details [20:36] <kurosu_> I was suggested this is because of the similarity to mp3 apply_window [20:36] <kurosu_> but on the other hand, we still want to compile them independently so it's better if they aren't together [20:38] <michaelni> mp3 and dca use slight different dcts IIRC [20:38] <kurosu_> yeah, there's some pretwiddling in dca [20:40] <kurosu_> note, there has been some reviewing already, and good suggestions were made to improve the first patches [20:40] <kurosu_> so if you ever had time to look at them, this is already something you can skip [20:45] <michaelni> pretwiddling ? [20:45] <michaelni> not sure what code you talk about [20:46] <michaelni> theres some code in the encoder that converts between FFT and 2x MDCT i think and [20:46] <michaelni> some code that does MDCT lapping but some will argue about my terminology here i know [20:47] <michaelni> also what patches ? [20:54] <kurosu_> A series of 11 patches [20:54] <kurosu_> sent yesterday [20:54] <kurosu_> to ffmpeg-devel(a)ffmpeg.org [20:54] <michaelni> ehm right :) [20:55] <kurosu_> (or maybe very early this morning, like 1am) [20:55] <kurosu_> I was wondering if I had broken my setup (trying to use aliases for git send mail) [20:55] <michaelni> i was up till 8 o clock today and apparently didnt sleep enough for my brain to fully work [20:56] <kurosu_> no problem [20:56] <kurosu_> I don't have further plans but this code has been aging far too much [20:57] <kurosu_> pretwiddling: negating half the coeffs [21:00] <michaelni> that sounds like fft<->mdct stuff [21:02] <kurosu_> anyway, I'm not about to rewrite the foundation around this code :) [21:10] <michaelni> kurosu_, why do you change int8x8_fmul_int32() in arm from static inline to static ? [21:11] <kurosu_> oh I did ? [21:11] <michaelni> yes in first patch [21:11] <kurosu_> anyway, the code will not change anymore [21:12] <kurosu_> let me verify and push my current code to show what it should be [21:21] <kurosu_> the first 2 patches should become: [21:21] <kurosu_> https://github.com/kurosu/libav/commit/a69b3cdbf5f441f0050d99b29473cffaabe1… [21:22] <kurosu_> https://github.com/kurosu/libav/commit/c3fa79549d1ab14113abd09e8e5a2a6ac72d… [21:40] <michaelni> kurosu_, can you cross post patches when there are new versions? i dont want to review code that has already been changes [21:40] <michaelni> s/changes/changed?/ [21:46] <BtbN> How does the ffmpeg configure system detect encoders and stuff? It just picked up the encoder i added, and i don't understand how. [21:47] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=1ab5a780424ae8755858e153de… you can see this as an example of an added video encoder [21:47] <JEEB> allcodecs/Makefile [21:47] <JEEB> there's a step-by-step checklist somewhere too [21:48] <BtbN> yeah, i added it successfully, but i expected that i'd need to edit more files [21:48] <BtbN> and i don't see how it does that [21:48] <JEEB> unless you have some specific needs, it's pretty simple [21:48] <BtbN> the nvenc encoder, the way i implement it, has no dependencies [21:50] <BtbN> What's the SKIPHEADERS part for? Is it for excluding some header from beeing installed? [21:53] <BtbN> The only thing i'm realy unsure about is what to do with this file: https://github.com/BtbN/FFmpeg/blob/nvenc/libavcodec/nvenc_api.h [22:21] <kurosu_> michaelni: sure, but those haven't been submitted anywhere yet [22:22] <michaelni> kurosu_, thanks [22:23] <kurosu_> as no review has been done yet, I think I'll just resend the whole [22:39] <michaelni> kurosu_, ok thx [22:56] <kurosu_> michaelni: about to send, but nothing really new (except first 2 patches) [22:56] <kurosu_> I'm thinking of moving back the synth dsp into the dca dsp [22:57] <michaelni> feel free to just send the 2 then [22:57] <michaelni> kurosu_, about sythn do what you prefer [22:58] <kurosu_> do you prefer I postpone sending the whole set until this is settled? I know one patch in the current set will be dropped [22:59] <michaelni> kurosu_, fine with me iam quite busy anyway currently [23:00] <kurosu_> ok I'll just wait then [23:16] <kierank> BtbN: doesn't seem gpl compatible [23:17] <BtbN> yes, that's the problem [23:18] <BtbN> but there is not realy an alternative, as there is only this one nvenc api [23:21] <BtbN> it's only the header, the library is dynloaded at runtime [23:53] <nevcairiel> could require the license to be supplied externally, like for other APIs [23:53] <nevcairiel> eh, the header [23:53] <nevcairiel> not the license :) [23:56] <BtbN> that would add the requirement for a several GB CUDA and NVENC SDK, which is extremely annoying to setup [23:57] <BtbN> which both have no default path or something like that [23:59] <JEEB> CUDA_PATH - C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v4.2\ [23:59] <JEEB> seems to exist on windows at least [23:59] <BtbN> In my case it's in D:\Lib\CUDA [23:59] <BtbN> the path can be freely configured in the installer [23:59] <JEEB> yes, the installer should set it correctly [23:59] <JEEB> CUDA_PATH being the env var [23:59] <BtbN> i don't have that var [00:00] --- Fri Feb 7 2014

1 0

ffmpeg.log.20140206
by burek 07 Feb '14

07 Feb '14

[00:23] <pw_> Hello, does anybody know if trac.ffmpeg.org is permanently down? [00:24] <pw_> a lot of the google search links to it [00:27] <tsjiller> pw_: probably not, it hasn't been down for that long [00:29] <beastd> pw_: will come up again. sorry for the inconvenience [00:34] <pw_> ts,beast: thanks [00:37] <dbro> eyo! Anyone know how to set the MPEG-4 Audio Object Types ID on a AVCodecContext? [00:37] <dbro> I'm muxing audio/video with the libav* libraries to "flv" output for rtmp. However, output file has an invalid Audio Object Type of 0 [00:38] <dbro> maybe AVCodecContext::profile is what I want... [02:09] <SenseiV183> JEEB, Encoding to utvideo my 2Gb source turned in to 20Gb. Are there quality settings to get the output under 10Gb for 2Gb input file? [02:12] <qbit_> join #ffmpeg-devel [02:53] <Logicgate> hey guys [02:54] <Logicgate> how would I resize a video that's 16:9 to be 1:1 [02:54] <Logicgate> I want to squish it, and not have black bars [02:54] <Logicgate> I want the video to fill the 480x480 square. [02:54] <Logicgate> Croping does not seem to work. [02:55] <Logicgate> whenever I crop a 16:9 video to 1:1 ratio, there's 2 black bars top and bottom. [03:07] <DeadSix27> Logicgate, so you want to suish?.. eg deformed? [03:08] <DeadSix27> +q [03:09] <DeadSix27> well, if so, try -> ffmpeg -i [input] -aspect 1:1 [output] [03:49] <x_> I want to pipe ffmpeg to another computer to do the bulk of the work but I have 100Mbit bandwidth what format do you think would be best in order to use the least amount of cpu? [03:50] <x_> would libx264 -crf 0 with ultrafast be the best bet? [03:53] <klaxa> least amount of cpu would be raw [03:55] <relaxed> x_: what are you actually doing? [03:55] <znf> can you fit 720p video on 100mbit in raw? [03:55] <relaxed> I doubt it [03:57] <znf> nope, you can't [03:57] <znf> 276480.0kbits/s [03:58] <Hello71> you could do it in gbit [03:58] <Hello71> but you probably increase latency with the network decoding [03:58] Action: znf wonders how much would 1080p be [03:58] <Hello71> and possibly cpu if that's in software [03:59] <x_> Yeah raw is simply too big. [05:04] <aji> $chan [05:35] <Logicgate> DeadSix27, you're the man. [05:35] <Logicgate> I've been looking for this forever [05:35] <Logicgate> Thank you [09:25] <SenseiV183> Problem with -vf to speed up or slow down video http://pastebin.com/5g9fNrRJ [09:29] <shaun__> Nevermind! I found the typo. I forgot a white space! [09:45] <shaun__> God bless you developers and helpers. [09:54] <Keestu> does ffmpeg depends on yasm library ? [09:55] <Keestu> i am behind building lastest ffmpeg on android. [10:13] <relaxed> Keestu: yasm is an assembler for x86 and amd64 [10:25] <Keestu> relaxed, thanks. ;) [11:51] <the1_> Hello im trying to record a livestream. The output video pauses on first stream while audio plays right away causing v:a to go out of sync. I guess this is caused by audio not waiting for video keyframe [11:51] <the1_> how do i make audio wait for keyframe? my command looks something like this: [11:52] <the1_> ffmpeg -i udp://broadcast-source:2220 -c:a libfdk_aac -ar 32000 -ab 48k -s 400x224 -c:v libx264 -b:v 300k -flags +loop+mv4 -cmp 256 -partitions +parti4x4+partp8x8+partb8x8 -subq 7 -trellis 1 -refs 5 -coder 0 -me_range 16 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -b:v 110k -maxrate 300k -bufsize 300k -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -level 30 -aspect 16:9 -r 15 -g 45 -async 2 -f mpegts /tmp/me.ts [12:15] <SirCmpwn> can I get the duration of a video stream with ffprobe? [12:15] <SirCmpwn> in seconds? [12:20] <SirCmpwn> answer: yes, but not for all media formats [12:55] <relaxed> the1_: which ffmpeg version are you using [13:03] <the1_> ffmpeg -v shows ffmpeg version git-2013-12-24-acafbb4 [13:06] <spaam> x-mas build [13:08] <d-fens_> hi, i have problem with the "-shortest" argument not cutting the audio to the vid length: http://pastebin.kde.org/pr9dvbhmn [13:09] <d-fens_> it always is 20sec long, shoudl be ~15 [13:09] <d-fens_> i've thrown -shortest into thw graph like no good [13:09] <the1_> spaam indeed [13:11] <d-fens_> what did i do wrong there? [13:24] <Keestu> while building ffmpeg, where can i find what the options by default is getting selected? for example, network, protocol ,devices.. etc.? [13:35] <Keestu> never mind i found, ;). it enables everything by default. [14:03] <RenatoCRON> Hello. i'm trying to low CPU usage, so I tried to pass -profile ultrafast, but I get that ffmpeg dont have this profile to use. [14:03] <RenatoCRON> http://pastebin.com/raw.php?i=1cNkKabt [14:03] <RenatoCRON> [libx264 @ 0xa8bc540] Possible profiles: baseline main high high10 high422 high444 [14:03] <RenatoCRON> so, anybody known why ultrafast is not available? [14:03] <RenatoCRON> do I need to compile ffmpeg with some more flag? [14:04] Action: RenatoCRON used http://pastebin.com/raw.php?i=mPtTL6Na [14:04] <JEEB> profile are feature levels in AVC/H.264 [14:04] <JEEB> you mean presets [14:04] <JEEB> which are x264's speed vs compression defaults [14:04] <JEEB> (as in, setting a preset sets defaults) [14:06] <RenatoCRON> JEEB, oh! [14:08] <RenatoCRON> JEEB, great! i set -profile main and -preset ultrafast and now my test (not stream) halt the time! [15:46] <SirCmpwn> how do I set a subtitle stream to be the default in an mkv file? [15:46] <SirCmpwn> I'm using ffmpeg -y -i input.mkv -i input.ass -vcodec copy -acodec copy -map 0:a:0 -map 0:v:0 -map 1:s:0 output.mkv [15:56] <SirCmpwn> I've tried -metadata:s:s:0 FlagDefault=1 to no avail [15:56] <SirCmpwn> also tried FlagForced [16:12] <bacon1989> Hi, I was wondering how the paramter -q:v works, is it bigger values are better, or bigger values are worse? [16:13] <bacon1989> and what's the scale? [16:13] <bacon1989> is it 0 --> 10, or 0 --> 100? [16:13] <bacon1989> I can't seem to find the documentation on it [16:13] <JEEB> scale depends on the encoder [16:13] <JEEB> and you only want to use constant quantizer with video formats that don't have anything better [16:13] <JEEB> for example with libx264 there's CRF [16:14] <JEEB> which is what should be used, and constant quantizer should only be used for development purposes by developers [16:14] <BtbN> Does ffmpeg support external encoders which are not a part of ffmpeg itself? [16:14] <JEEB> yes [16:15] <JEEB> libx264, libxvid, libtheora, libvorbis to mention a few [16:15] <BtbN> but those have special code in place in ffmpeg [16:15] <JEEB> yes [16:15] <BtbN> i mean something like a general interface [16:15] <JEEB> no, there is no general interface [16:15] <BtbN> hm, so i'd have to somehow hack it into ffmpeg itself... [16:16] <JEEB> in most cases that shouldn't really be too hard, and there should be multiple examples for it already in the libavcodec code base [16:16] <JEEB> (libutvideo and libfdk-aac being some of the latest ones you can take a look at) [16:17] <BtbN> Yes, but it forces me to allways use my patched version of it [16:17] <JEEB> unless you upstream the wrapper, of course [16:17] <BtbN> I don't think it would be accepted, because it doesn't work without a license key from nvidia [16:18] <JEEB> it would prevent testing yes, but not like the external encoders are getting tested much to begin with :P [16:18] <JEEB> wouldn't say it wouldn't get accepted purely on that basis [16:19] <BtbN> ne, it needs a license key put into the code to make it initialize at all. And nvidia won't like seeing that key freely available in some open source git [16:19] <JEEB> can't you make it be read from a file or something? [16:20] <BtbN> i think that would be possible, but would require some processing on the key [16:21] <JEEB> well, then it means it's more or less possible :) [16:22] <JEEB> also I wonder which API from nvidia this is :) [16:22] <BtbN> nvenc [16:22] <BtbN> their hardware h264 encoder [16:22] <JEEB> yeah, but is it all of it or just some specific part of it that's locked? [16:22] <BtbN> the api itself is public: https://developer.nvidia.com/nvidia-video-codec-sdk [16:23] <JEEB> yeah [16:23] <JEEB> that's why I was kind of surprised [16:23] <BtbN> But the init function wants a license key [16:23] <JEEB> ah [16:23] <BtbN> it works without a license key, but only on some (very expensive) Quadro/GRID cards [16:25] <JEEB> in any case, that sounds like something that could go into libavcodec [16:26] <JEEB> also you'd have to put the license key in a "resource file" loaded up by the code in any case, since if you were to distro your (say, LGPL) binaries you'd have to release the source code to that libavcodec [16:32] <BtbN> or just an environment variable [16:32] <JEEB> or that, yes [16:35] <JEEB> from #elsewhere "JEEB: the latest beta driver for Windows allows NVENC on GeForce cards, if that's what you want" [16:35] <BtbN> Yes, but i can't imagine that it this is intentional [16:36] <BtbN> or is it mentioned in some changelog? [16:36] <JEEB> well, that was an nvidia employee noting that to me. No idea of course if he has an idea of the PC GPU business's real motivations [16:41] <JEEB> <nevcairiel> apparently they removed this license GUID BS with the 3.0 version of the SDK though [16:41] <JEEB> (another person) [16:42] <JEEB> so yeah... it seems like it's getting better, too? [16:42] <BtbN> No, they didn't. SDK 3 still has the license stuff in it [16:43] <BtbN> it only works with an empty/zero license key with the latest beta driver [16:45] <JEEB> <nevcairiel> JEEB: the readme clearly specifies that the license is no longer required, and instead the driver checks for support, and if it works with an empty key, thats exactly what it does. Who cares which driver it works with if it works with one :P [16:45] <JEEB> <nevcairiel> JEEB: even more so if it works with a recent one, and not some old silly version [16:46] <BtbN> huh? I'm using the 3.0 SDK since it was released, and it did require a license key to work before the current beta driver. [16:47] <BtbN> It doesn't require a license to work on Quadro and Tesla cards [16:47] <BtbN> but for GeForce it did [16:47] <JEEB> what you just said doesn't contradict to the lines I posted :) [16:48] <BtbN> I'm just confused that it says so i some readme, i can't find something about that [17:28] <bparker> JEEB: in my experience with proprietary h264 encoders, they make using libx264 a magical walk in the park [17:29] <bparker> if I had the time I'd like to make a stupid simple C++ wrapper for libx264 unless a good one already exists [17:29] <JEEB> oh I've heard of those stories with proprietary things ;) [17:29] <bparker> that abstracts away the hard-to-understand stuff [17:30] <JEEB> which is why people were kind of smiling when the low-latency API for nvidia's ASICs came out [17:30] <JEEB> because the API was clearly designed after someone had taken a look at libx264's similar features [17:33] <bparker> we thought about using nvenc in the beginning, but honestly when I looked at it it was even more annoying [17:33] <JEEB> yeah, I've only heard about the certain part of the API and limited similarities [17:34] <JEEB> haven't looked into that stuff at all in detail yet [17:34] <bparker> and we thought that maybe in the future we would have products that don't have a quadro card [17:34] <bparker> and x264 was plenty fast enough [17:34] <bparker> license fee was reasonable [17:34] <bparker> so we went with it [17:35] <bparker> I still ended up making a wrapper class for it just for one application [17:36] <bparker> but it's not generic enough for general release, plus it's closed source anyway :/ [17:36] <bparker> but you can do like new Encoder(framesize, bitrate, etc.) and then just encoder->encode(framedata) and that's it [18:19] <pw_> Hi, I'm trying to write a program that would take a h264+ac3 wrapped in ts, and spit out the first I frame as an image. I've compiled the examples in doc/examples and am currently tracing it. The problem I have is that if the I stream is being probed, and I guess my short snippet containing the I frame is not long enough for it to auto-probe to recognize that one of the stream is h264.Can you give me some hints as to which field/struc [18:25] <Olivia_> hi what's the difference between rtbufsize and buffer_size with an udp source ? [18:40] <llogan> RenatoCRON: (four hours later...) you generally don't need to set a profile unless you're encoding for a limited device [18:43] <ChocolateArmpits> llogan, but wouldn't setting the profile to main from high realistically increase rendering speed ? [18:48] <RenatoCRON> llogan, i'm encoding segments of 20sec videos 352x240 4 FPS, in fact, the goal is reduce CPU while encoding. after that there's a player online made in HTML 5 to play these files. [18:49] <RenatoCRON> after setting -preset to ultrafast, it changed from 25% of cpu to 5% top [18:49] <RenatoCRON> now 1 AWS c1.medium machine is working fine (i anaylysing it) with 40 cameras [18:50] <RenatoCRON> analysing* [18:50] <pw_> renato: what's the latency of that encoding? just curious [18:51] <RenatoCRON> pw_, from the input ? [18:51] <RenatoCRON> I guess I don't understood your question very good. [18:52] <ChocolateArmpits> I think he's asking what time delay there is after the encoding [18:52] <pw_> input of the encoder to the output.. you said you have it hooked up to cameras... so if somebody were to walk by the camera, when does the image of that person show up [18:52] <RenatoCRON> pw_, I guess the input profile is 'main' or something like that, because is a RTSP camera [18:53] <RenatoCRON> pw_, it's almosty realtime, but I can't test this... maybe if I connect using 3g and what it in VLC and move my arms ! [18:54] <pw_> renatocron, just wondering. [18:54] <RenatoCRON> it's much very fast use -c:v copy, but I need to change framerate and segment, so I need to re-encoding to match keyframes [18:55] <RenatoCRON> storage is more cheap than CPU, so I and my team was wondering if is possible to save RAW segmented, [18:55] <RenatoCRON> but to play theses files, it may need 'back in time on files' until see a keyframe [18:56] Action: RenatoCRON can encode to a cpu-cheap format too, if you guys now, I can do it. [18:56] <RenatoCRON> maybe video2mpeg ( i guess is it) i'm very new as FFMPEG 'dev' user [19:01] <RenatoCRON> pw_, but just for info, i'm using a lot of extenal open cameras from second life for testing also! it's a little crazy universe. [19:02] <pw_> renatocron, ah. interesting. [19:02] <RenatoCRON> I found this on http://h264.wordpress.com/live/ [19:03] <RenatoCRON> not all are online [19:03] <RenatoCRON> and there's some that return invalid input but .mov is working [19:03] <RenatoCRON> I don't have time/priority to find why [19:04] <RenatoCRON> http://i.imgur.com/dMUuSDR.png < all theses cameras is working in the same machine. it's a dual Intel(R) Xeon(R) CPU E5506 @ 2.13GHz [19:04] <RenatoCRON> uptime is load average: 4.36, 3.55, 2.98 [19:05] <RenatoCRON> i dunno if this is much (I supposed to be) but the machine continue very fast (at least is responding to) [19:06] <BtbN> bparker, huh? The nvenc api is realy simple, i already used it for a few fully working encoders [19:06] <BtbN> It doesn't have as much features as x264, but it's not complicated or annoying to use [19:06] <Olivia_> what's the diff between rtbufsize and buffer_size for udp ? [19:07] <BtbN> libva intel hw encoding or OpenMAX encoding is horrible, but nvenc is realy great [19:07] Action: RenatoCRON hmm, looks nvenc is a h264 encoder! [19:09] <BtbN> is the github ffmpeg repo up to date? [19:16] <jnvsor> So what's up with the trac servers? [20:15] <ChocolateArmpits> Does Yadiff when set to Auto recognize progressive input and hopefully skip deinterlacing ? [20:16] <ChocolateArmpits> yadif* [20:22] <ChocolateArmpits> Ok, A few google searches are suggesting it will skip deinterlacing [20:28] <ChocolateArmpits> But what does "only deinterlace frames marked as interlaced " mean here ? Does it suggest a source input with different frame properties every other scene ? [21:34] <pw_> is there a way to force ffmpeg to use decode certain pids as a particular decoder? The closest I found was something like -codec:a:0, but it seems to specify the stream index and not the pid [22:59] <SirCmpwn> so are there any plans to fix the website [22:59] <SirCmpwn> it's been a while [23:18] <llogan> SirCmpwn: yes. should be back by Saturday. [23:18] <SirCmpwn> excellent [23:39] <SirCmpwn> can I convert a stero input to a mono output (encoding with libfdk_aac) [23:40] <SirCmpwn> stereo* [23:41] <JEEB> as usual, you can use -ac to set the amount of output channels [23:41] <SirCmpwn> thanks, I just didn't know the option [00:00] --- Fri Feb 7 2014

1 0

ffmpeg-devel.log.20140205
by burek 06 Feb '14

06 Feb '14

[00:04] <burek> is trac down? [00:18] <Rodeo> burek: someone mentioned not too long ago, so I guess it is [00:20] <burek> +1 [01:06] <michaelni> llogan, ubitux latest page of merged formatting, links and stuff: http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_of_Code_2014 [01:07] <michaelni> if trac will be up again in time we can move it back [01:08] <michaelni> but having it on multimedia.cx allows editing for all who have an account which is better than if its nowhere [01:12] <llogan> michaelni: ok. i'll try take a look at it tonight [01:12] <michaelni> thx [01:27] <cone-703> ffmpeg.git 03Vittorio Giovara 07master:d509ae5be0a9: jvdec: K&R formatting cosmetics [01:27] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:dcbc748ad11b: Merge commit 'd509ae5be0a9bac35a4cedbe68b774a74446bb27' [01:29] <cone-703> ffmpeg.git 03Diego Biurrun 07master:190d4a447bc6: avcodec: Suppress deprecation warnings from avcodec_alloc_frame() [01:29] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:bd9492174d97: Merge commit '190d4a447bc6ae4ecbbbb1c70f482a9c1fb6026c' [01:35] <cone-703> ffmpeg.git 03Justin Ruggles 07master:0e830094ad0d: samplefmt: avoid integer overflow in av_samples_get_buffer_size() [01:35] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:d80b9ea11da1: Merge commit '0e830094ad0dc251613a0aa3234d9c5c397e02e6' [01:56] <cone-703> ffmpeg.git 03Anton Khirnov 07master:5430839144c6: eacmv: clear references on frame dimensions change [01:56] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:e7724f346a92: Merge commit '5430839144c6da0160e8e0cfb0c8db01de432e94' [02:16] <cone-703> ffmpeg.git 03Anton Khirnov 07master:1713eec29add: shorten: pad the internal bitstream buffer [02:16] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:cd04f0da60bf: Merge commit '1713eec29add37b654ec6bf262b843d139c1ffc6' [02:41] <cone-703> ffmpeg.git 03Anton Khirnov 07master:2240e2078d53: truemotion1: check the header size [02:41] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:2b88cb2f4653: Merge commit '2240e2078d53d3cfce8ff1dda64e58fa72038602' [02:53] <cone-703> ffmpeg.git 03Anton Khirnov 07master:4c3e1956ee35: lagarith: reallocate rgb_planes when needed [02:53] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:6a4cc5098078: Merge commit '4c3e1956ee35fdcc5ffdb28782050164b4623c0b' [03:16] <BBB> ubitux: will check [03:24] <BBB> ubitux: I think lgtm [03:26] <cone-703> ffmpeg.git 03Luca Barbato 07master:d9ae1031f5ed: lavf: improve handling of sparse streams when muxing [03:26] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:3adb5f8d8b40: Merge commit 'd9ae1031f5edbd25c8526b4cb51aba66d3bee931' [03:26] <BBB> I'm kinda shocked that decode_coeffs_b is so high in the profile, is that -O0 or so? anyway, some of my optimizations (vp9-context-opts branch) should help in that function, and also in decode_b and memset [03:27] <BBB> for me, decode_coeffs_b is 9.4% or so, with another 9.5% for decode_b [03:27] <BBB> and 15.6% for 8tap_1d_h_16 [03:27] <BBB> if you want to decrease that, add prefetch handling like h264/vp8 have [03:36] <cone-703> ffmpeg.git 03Luca Barbato 07master:9ecb85877548: doxy: Format @code blocks so they render properly [03:36] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:6e380cc28f25: Merge commit '9ecb858775483a76c137e8e1ad45a95e318bca61' [04:13] <cone-703> ffmpeg.git 03Vittorio Giovara 07master:a91d3658d9a7: mpeg: K&R formatting cosmetics [04:13] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:acd7505351d1: Merge remote-tracking branch 'qatar/master' [07:18] <ubitux> BBB: no, no -O0, but --assert-level=2 and debug syms [07:26] <cone-989> ffmpeg.git 03Clément BSsch 07master:91d85bb167a9: x86/vp9lpf: add ff_vp9_loop_filter_[vh]_44_16_{sse2,ssse3,avx}. [07:26] <cone-989> ffmpeg.git 03Clément BSsch 07master:9a3b05b0a989: x86/vp9lpf: save a few mov in flat8in/hev masks calc. [07:26] <cone-989> ffmpeg.git 03Clément BSsch 07master:97dde561dec0: x86/vp9lpf: remove braindead double pxor. [07:26] <cone-989> ffmpeg.git 03Clément BSsch 07master:d92a725329e5: x86/vp9lpf: remove 8 SWAPs in 84/48 transpose. [07:37] <ubitux> BBB: no assert level: http://pastie.org/pastes/8700306/text [07:38] <ubitux> (another machine than previous test btw) [07:39] <ubitux> i'll try your vp9-context-opts branch [07:48] <ubitux> BBB: http://pastie.org/pastes/8700324/text with the vp9-context-opts branch (which i rebased on master to be consistent with previous test) [07:48] <ubitux> that's indeed much better for decode_b(), but decode_coeffs_b() is still slow :p [09:30] <pross-au> michaelni: i am removing vp7 from the gsoc 2014 list as i have just finished decoder for it [09:33] <JEEB> oh [09:33] <JEEB> nice [09:34] <JEEB> that's actually the thing I originally wanted to do in 2012, but was poked towards a Ut Video encoder :) [09:37] <pross-au> ut would be way more interesting. vp7 is essentially "vp8 with bugs". [09:37] <pross-au> vp4 still needs love [10:13] <ubitux> BBB: and btw, i just tried with clang instead of gcc, and that's even worse :p [10:14] <ubitux> (just in case it was a random miscomp or something) [13:08] <BBB> odd [13:08] <BBB> well eiter your simd is really fast or your regular assembly is really slow compared to mine [13:08] <BBB> the funny thing is that overall runtime is roughly the same [13:09] <ubitux> maybe there is a difference in the metering [13:09] <ubitux> like some function inlined or something [13:09] <BBB> possibly yes [13:10] <ubitux> BBB: what sample are you testing btw? [13:10] <BBB> ped1080p.webm [13:10] <ubitux> yeah, that sample is a bit short [13:10] <ubitux> try a longer one, like etv5k [13:10] <BBB> you're testing etv5k? [13:10] <ubitux> yes [13:10] <BBB> ok, will test that one and compare [13:11] <ubitux> BBB: http://pastie.org/pastes/8701093/text this is with ped1080p.webm [13:11] <BBB> what do you think of the vp9-context-opts patches? the commit messages are kinda messy and the code can probably be cleaned up a bit, but do you feel it helps? for me it helped about 0.2sec or so [13:11] <BBB> yeah that's a little more like what I get, so I guess it makes sense then [13:11] <BBB> should work more on decode_coeffs_b I suppose [13:12] <ubitux> i didn't look at the vp9-context-opts patches, will [13:12] <ubitux> i'll bench as well to see the benefit [13:12] <BBB> ok [13:12] <BBB> I'll clean up the commit msgs and try to make the code more consistent [13:15] <ubitux> 3.85s 3.68s (best scores) [13:15] <ubitux> (1 thread) [13:17] <BBB> ok not bad [13:17] <BBB> I'll clean and send out [13:17] <BBB> I have almost all intra pred functions simd'ed also [13:52] <ubitux> BBB: 40 38 with vp9-context-opts on etv5k.webm [13:56] <ubitux> (seconds) [13:59] <BBB> \o/ [13:59] <BBB> yeah so that's about the same percentage I saw also (5.5->5.3 or so) [14:13] <ubitux> BBB: according to perf, most of the time is spent on... a shift. wth. http://ubitux.fr/pub/pics/_wtf-shl-perf-timing.png [14:26] <cone-691> ffmpeg.git 03Marton Balint 07master:cec6dec7c8b2: ffplay: reorder the filters to ensure that inputs of the custom filters are merged first [14:26] <cone-691> ffmpeg.git 03Marton Balint 07master:23e77f0e33b7: ffplay: flush subtitle codecs as well with null packets [14:26] <cone-691> ffmpeg.git 03Michael Niedermayer 07master:95b13fb96f7e: Merge remote-tracking branch 'cus/stable' [15:16] <burek> did anyone fix trac.ffmpeg.org [16:09] <thardin> *stirs mxf pot some more* [16:10] <kierank> thardin: there are many libmxfs [16:11] <kierank> thardin: the bmx one is the latest one i think [16:11] <kierank> the ingex one is old [16:14] <cone-691> ffmpeg.git 03Timothy Gu 07master:9a4a559d6fbe: configure: use real libfdk-aac version instead of API version in help text [16:16] <thardin> ah [16:16] <thardin> well, using one written by people who actually work with mxf on a daily basis makes lots more sense [16:17] <thardin> regardless of what it's called [16:35] <j-b> +// EDIT JB thread_await for multi_threading [16:35] <j-b> omg [16:37] <ubitux> > [FFmpeg-devel] [WIP] H.264 MVC decoder [16:37] <ubitux> michaelni: we'll have to remove one entry in the gsoc page :( [16:39] <ubitux> nice horror diff btw [16:40] <ubitux> wth is this... o_o [16:40] <nevcairiel> its something a student wrote for a thesis without a care in the world for style or whatnot [16:41] <nevcairiel> koda from libav has been trying to untangle the decoder for a while as well [16:41] <ubitux> well there are thousands and thousands of commented line [16:42] <Daemon404> ... [16:42] <kierank> huge diff [16:42] <Daemon404> ubitux, this is a piece of crap [16:43] <Daemon404> in multiple ways [16:43] <michaelni> does it work and how can it be tested ? [16:43] <Daemon404> michaelni, all they did is make the ancient patch apply to the current codebase [16:43] <Daemon404> and comment out random stuff, liek a printf in ffplay [16:43] <Daemon404> it's completely broken/useless [16:43] <Daemon404> and insane [16:43] <Daemon404> :D [16:43] <michaelni> core |binary [16:43] <j-b> ubitux: I mean, even _I_ can see the patch is pure horrible [16:44] <michaelni> libavcodec/stG88jwK |binary [16:44] <wm4> a coredump file? [16:45] <michaelni> yes, seems though its missing in the attached patch "Binary files /dev/null and b/core differ" [16:48] <Compnn> gasp mvc decoder [16:49] <nevcairiel> I hope noone will do any rash decisions and merge something half-assed :p [16:49] <j-b> ubitux: "pure horror" [16:49] <kierank> nevcairiel: never :) [16:50] <Compnn> nevcairiel : you want to sit on it until it rots ? [16:50] <ubitux> j-b: sorry i forgot your copyright [16:50] <nevcairiel> Compnn: rather then merge something that will haunt us for years [16:50] <Compnn> oh master thesis :) [16:50] <nevcairiel> Either someone cares enough to do it properly, or noone cares enough so it also shouldnt be merged :) [16:50] <j-b> IMHO, you should merge this patch without looking at it :) [16:50] <Compn> those words arent good [16:51] <nevcairiel> But like I said, koda from libav has been poking the same decoder indepdently and is in the process of cleaning it up and also deciding on the API how to even expose multiple views from the decoder [16:52] <nevcairiel> so whoever wants to clean it up should probably talk to him, double work is useless [16:53] <michaelni> nevcairiel, who is koda ? [16:53] <Daemon404> the guy working on MVC properly [16:53] <nevcairiel> Vittorio Giovara [16:53] <Daemon404> and actually planning out how to return it from decode_video3 [16:53] <JEEB> I think koda got the MVC code before, and was poking at it to make it saner? [16:54] <JEEB> and still is of course [16:54] <nevcairiel> its been out there for a while [16:54] <JEEB> true [16:54] <michaelni> why was it not posted to ffmpeg-devel before ? [16:54] <nevcairiel> because the author didnt care [16:54] <nevcairiel> he just wanted his thesis [16:54] <Daemon404> welcome to academia [16:55] <Daemon404> proof of concept is all you ever need [16:55] <Daemon404> practical things considered harmful (to your career) [16:55] <Compn> i seem to remember someone talking about doing a thesis [16:55] <Compn> some people just dont talk on the mailing list every day [16:55] <Compn> but they do enormous amounts of code... [16:55] <nevcairiel> iirc, he wanted to take part in gsoc because the timing coincided with his thesis, but ffmpeg wasnt in gsoc that year, so he just vanished completely [16:55] <Daemon404> Compn, hiding in your hole silently and then dumping on the ML isnt very good [16:56] <Daemon404> nobody will accept such patches [16:57] <Compn> he did want to develop with us [16:58] <Compn> if nevcairiel's memory is correct [16:58] <nevcairiel> he could've done it without google giving him moneyz he really cared [16:58] <nevcairiel> alas he didnt [16:59] <Compn> Daemon404 : http://ffmpeg.org/pipermail/ffmpeg-devel/2012-June/126139.html [17:00] <Compn> "it would be great to get tips how to do this best." [17:00] <ubitux> "The patch applies against commit 69cc119d (0.11.x release branch, I think)" oh shit i missed that part [17:00] <Compn> Daemon404 : how come you failed to help him in 2012 ? [17:00] <nevcairiel> he got an answer from michael, but he never responded to that on the ML as far as i can see [17:01] <ubitux> Keestu: are you the one submitting the mvc patch? [17:01] <wm4> ubitux: so 100% useless [17:05] <ubitux> BBB: btw, do you want me to work on the _8 lpf variants or i can look at something else? [17:05] <ubitux> given the benchmarks, it doesn't look like a priority [17:05] <ubitux> (and i wonder if it will ever be) [17:19] <smarter> koda's cleaned up version of the MVC decoder is at https://github.com/kodabb/libav/commits/MVC_orig_clean [17:20] <smarter> he has also started a document on how the API should be designed: https://wiki.libav.org/Blueprint/MultiAVFrame [17:24] <kurosu__> I think the openhevc guys working on shvc would be interested by such new api, if they haven't yet participated [17:25] <kierank> shvc :( [17:26] <wm4> what would be the best API for mvc decoder output? I actually like 2 + padding if resolution mismatches [17:27] <nevcairiel> yeah build-in SBS might be useful, and you can always cheat with stride and width changes to reference them individually if you want to [17:28] <nevcairiel> i'm not sure how shvc is supposed to work exactly [17:29] <smarter> I think you first call the base layer decoder to get a frame and then the enhancement layer decoder [17:29] <smarter> https://github.com/OpenHEVC/openHEVC/commits/shvc [17:29] <nevcairiel> but the goal is to get one image out, not two, isnt it [17:30] <smarter> and yes, some sort of common API would be nice [17:30] <smarter> depends [17:50] <Daemon404> ... [17:51] <Daemon404> did the openhevc people just go ahead and hack it in? [17:52] <kierank> Daemon404: of course [17:52] <kurosu__> I don't think their goals are aligned with ffmpeg/libav (why should they?), more likely they want to be able to showcase the decoder as soon as possible [17:53] <Daemon404> of course [17:53] <kierank> I don't think their goals are aligned with ffmpeg/libav (why should they?) --> because they took smarter's code [17:53] <Daemon404> standard corproate practice [17:53] <smarter> I think they are interested into getting it in libav/ffmpeg at some point [17:53] <smarter> they're not corporate people but academia people [17:53] <Daemon404> isnt ateme involved [17:54] <smarter> not really [17:54] <ubitux> j-b: v.o is a bit laggy it seems [17:54] <kierank> Daemon404: just in the PR [17:54] <ubitux> j-b: randomly.. [17:54] <Daemon404> smarter, then why did one guy from openhevc say he implemented stuff in intrinsics "because his boss told him to" [17:54] <kurosu__> the code is (l?)gpl, except publishing it, they aren't bound by anything else - but yes they did push and get it integrated - it's more that the notion that they might have an obligation sounds strange to me [17:54] <Daemon404> kurosu__, its called not being a bag of dicks [17:54] <j-b> ubitux: releases days [17:54] <Daemon404> and working with the community [17:55] <ubitux> j-b: ah, ok [17:55] <kierank> kurosu__: they don't have an obligation but working with the community > working on your own [17:55] <Daemon404> when they so graciously provide you with your entire foundation [17:55] <smarter> Daemon404: mraulet is a researcher in Rennes and he has some grad students or something working for him [17:55] <Daemon404> biting the hand that feeds. [17:55] <Daemon404> thats the term. [17:55] <Daemon404> smarter, well academics are the only people i hate more than corporate types [17:55] <Daemon404> thats not a plus [17:56] <Daemon404> so... [17:56] <smarter> :p [17:56] <Daemon404> (my SO is a researcher, so i get all the fun insdie stuff) [17:56] <kurosu__> working with the "community" has always been a lot of time wasted for me - not efficient at all, so that doesn't really count as an argument [17:56] <kurosu__> (for me) [17:56] <Daemon404> so basically youre an asshole... [17:56] <kurosu__> and you are being rude [17:56] <Daemon404> so is wat you do [17:56] <kurosu__> but that doesn't matter to each other so it is ok [19:53] <llogan> cehoyos: are you enjoying the vacation from the bug tracker? [19:53] <cehoyos> LOL [19:53] <cehoyos> Actually not... [19:53] <llogan> also, i got a long rant from our resident troll involving you via a long email [19:54] <cehoyos> The last ts->mkv ticket is a duplicate iirc, on the forum there is a new sample for an existing ticket and on -user, a hevc ticket (drop initial non-key frame) was suggested. I wonder how many of those I will forget... [19:54] <cehoyos> Resident troll?? [19:55] <cehoyos> But please forward it, I like reading! [19:56] <cehoyos> Sorry, gtg [20:08] <Compn> llogan : people write you long troll emails? heh [20:08] <Compn> i'm glad i dont get those :) [20:09] <llogan> so far i haven't had the time or motivation to do reply. maybe in my spare-spare time. [20:09] <llogan> "to do reply". i've turned russian [20:10] <Compn> kurosu_ : Daemon404 doesnt speak for the project :) [20:11] <kurosu_> Compn: I don't mind, this was probably a spark of anger and I probably was not correctly presenting my point [20:11] <Compn> we have people that work with us and people that just work on the code and do dumps. we work with everyone we can [20:13] <Compn> we wont turn away people just because they didnt kiss our butts :) [20:13] Action: Compn pulls out double negatives [20:14] <kurosu_> I understand the origin of the thinking - it's morally wrong. But my issue is that for most people, first they need to achieve something then they can try contributing [20:14] <Compn> its fine, theres no right or wrong way to contribute [20:46] <J_Darnley> Who owns the cygwin machine that runs fate? [20:46] <llogan> what does the 129 mean in "Stream #0:1[0x101]: Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, stereo, fltp, 192 kb/s"? [20:49] <nevcairiel> its the "fourcc" [20:49] <nevcairiel> with 129 being the first character :p [20:49] <nevcairiel> (numeric value of it) [20:49] <nevcairiel> ie 0x81 [20:49] <J_Darnley> ... Nevermind I see the history page lists the owner as "beastd" [20:50] <beastd> hi [20:51] <llogan> nevcairiel: thanks. any idea why remuxing apparently changes it from 6 to 129? http://ffmpeg.gusari.org/viewtopic.php?f=11&t=1264#p3441 [20:51] <beastd> J_Darnley: I am the owner of what? [20:51] <Compn> cygwin box [20:51] <Compn> fate cygwin box [20:52] <nevcairiel> llogan: mpegts has a fixed list of stream ids, it must pick it from that list [20:58] <J_Darnley> beastd: the machine that runs fate on Cygwin, or is the page wrong? [21:01] <beastd> J_Darnley: yes, that is mine. I was just joining and was missing context. [21:04] <J_Darnley> Yes I see that and it explains why I couldn't tab-complete you name when I first went to do it. [21:05] <J_Darnley> Now my question. What do you use to run fate regularly? [21:07] <beastd> I think the program is named at.exe [21:08] <beastd> it is from Microsoft and comes with windows AFAICT [21:09] <beastd> oh seems i am wrong it is named taskschd.msc (maybe the program is named task scheduler in english, i see only the translated name here) [21:10] <J_Darnley> Yes, I think that's Windows own sheduler [21:10] <beastd> task scheduling can be configured extensively [21:11] <Skyler_> BBB / ubitux (?): http://privatepaste.com/01423e301f this makes that top function ~6% faster, at least on my system (x86_32, gcc 4.8) [21:11] <J_Darnley> I was considering setting up and running a cygwin64 instance. I might need to ask you some more questions later. [21:14] <beastd> nice, i wanted to try that for some time [21:15] <beastd> but didn [21:18] <ubitux> Skyler_: seems even slower in decode_coeffs_b() here [21:19] <Skyler_> huh, strange. I was using start/stop timer [21:19] <Skyler_> what test file are you using? [21:20] <cone-691> ffmpeg.git 03Vignesh Venkatasubramanian 07master:129e24f78e5d: lavf/oggparseopus: Setting seek_preroll in AVCodecContext [21:21] <ubitux> Skyler_: http://lucy.pkh.me/samples/vp9/etv5k/etv5k.webm [21:24] <ubitux> overall decode time goes from 30.743 to 31.413 [21:29] <ubitux> before: 3169 decicycles in decode_coeffs_b, 64834422 runs, 2274442 skips [21:29] <ubitux> after: 3369 decicycles in decode_coeffs_b, 64881776 runs, 2227088 skips [21:29] <ubitux> Skyler_ ^ [21:29] <Skyler_> huh, on mine it was ~11250 -> 10500 dezicycles [21:29] <Skyler_> anyways, downloading this on rather slow internet, I'll try with your sample [21:51] <durandal_1707> what about dejudder filter? [21:56] <Skyler_> ubitux: bizarrely, [21:56] <Skyler_> 7816 decicycles in decode coeffs, 32800764 runs, 753668 skips/A [21:56] <Skyler_> 8242 decicycles in decode coeffs, 32793514 runs, 760918 skips/A [21:56] <Skyler_> (after, before) [21:58] <Skyler_> though I guess I only timed calls from the Y decode, maybe I shold try the UV too. [22:09] <Skyler_> 1121 decicycles in uv decode, 33458798 runs, 95634 skipsate=N/A [22:09] <Skyler_> 7838 decicycles in y decode, 32802663 runs, 751769 skipsate=N/A [22:09] <Skyler_> 1163 decicycles in uv decode, 33448279 runs, 106153 skipste=N/A [22:09] <Skyler_> 8235 decicycles in y decode, 32790846 runs, 763586 skipsate=N/A [22:09] <Skyler_> weird. [22:35] <ubitux> Skyler_: so always faster in your case? [22:36] <Skyler_> strangely, yeah. I suspect the timer is a little inaccurate in maybe both of our cases (a very large number of skips due to variance in call time, since like, a 32x32 takes way longer than a 4x4 and might get skipped) [22:36] <Skyler_> but I'm not sure if that can fully account for yours being slower and mine being faster. [22:45] <Skyler_> okay, I fixed the timer to not skip everything [22:45] <Skyler_> 1224 decicycles in uv decode, 33554419 runs, 13 skipsitrate=N/A [22:45] <Skyler_> 10389 decicycles in y decode, 33554341 runs, 91 skipsitrate=N/A [22:45] <Skyler_> 1276 decicycles in uv decode, 33554409 runs, 23 skipsitrate=N/A [22:45] <Skyler_> 11052 decicycles in y decode, 33554294 runs, 138 skipstrate=N/A [22:45] <Skyler_> weird :/ I wonder if 64-bit and 32-bit give different results [22:46] <ubitux> i'm on 64, gcc 4.8 [22:47] <ubitux> test cmd was simply ffmpeg -threads 1 -i etv5k.webm -f null - iirc [23:17] <Compn> someone wants chromecast support in ffmpeg [23:18] <Compn> someone who sends a mail to webmaster@ [23:48] <cone-691> ffmpeg.git 03Ben Boeckel 07master:7eb84f2c3b30: ogg: allow streams to update metadata [23:48] <cone-691> ffmpeg.git 03Ben Boeckel 07master:0dc66553adb8: vorbis: append data from tags together [23:48] <cone-691> ffmpeg.git 03Ben Boeckel 07master:5a633ec2dd45: vorbis: extract metadata from the middle of a stream [23:59] <cone-691> ffmpeg.git 03Janne Grunau 07master:a1e1f35203bb: lavu: add missing log.h include in timer.h [23:59] <cone-691> ffmpeg.git 03Michael Niedermayer 07master:a3be0c334e8b: Merge commit 'a1e1f35203bbcbea0efb51d93e96769c826b8c64' [00:00] --- Thu Feb 6 2014

1 0

ffmpeg.log.20140205
by burek 06 Feb '14

06 Feb '14

[00:11] <DeadSix27> Wa4: did you get it to work? [00:11] <Wa4> kinda [00:12] <Wa4> -vf scale=720:404 -vcodec libx264 [00:12] <Wa4> only the cropping part left :) [00:12] <DeadSix27> use quotes arround the vf [00:12] <DeadSix27> -vf "filter1,filter2" [00:12] <Wa4> I tried that already [00:12] <DeadSix27> -> -vf crop:0,2,0,2 [00:12] <Wa4> hmm [00:12] <DeadSix27> thats a weird format [00:12] <DeadSix27> wont work [00:12] <DeadSix27> its: "crop=out_w:out_h:x:y" [00:13] <Wa4> euh [00:14] <Wa4> so if I want to crop 2px left and 2px right? [00:14] <DeadSix27> dont ask me how exactly the crop stuff works, i never got the fizzle [00:14] <DeadSix27> -> http://avp.stackexchange.com/questions/4563/how-can-i-crop-a-video-with-ffm… [00:16] <Wa4> Original frame is 1280x720. You want to crop 10 pixels from top and bottom but leave the width uncropped: [00:16] <Wa4> -vf crop=1280:700:0:10 [00:17] <DeadSix27> Wa4: http://i.imgur.com/lqoe4sn.png [00:17] <DeadSix27> i think it works like that [00:18] <GNU\colossus> how can I use ffmpeg to decode any number of (mixed, but audio only - Vorbis, MP3, AAC, possibly others) input files and see if there were probolems decoding (i. e. they were invalid or damaged in any way) any of those files? [00:19] <burek> ffmpeg -i bla.mp3 output.wav [00:19] <burek> and then check your output.wav [00:19] <burek> also monitor stderr output, if there are any errors, those will be displayed there [00:22] <Wa4> thanks DeadSix27, it works now [01:15] <vl4kn0> Hi, what's the difference between buffersink and ffbuffersink? [02:22] <chamunks> Is there some method to simplify this ffmpeg stuff for rookies? [02:22] <chamunks> I've kind of attempted to wrap my head around it a bit before for specific situations but it just doesn't seem to wanna stick. [02:23] <llogan> chamunks: just ask here [02:24] <chamunks> In this current situation I'd like to be able to use ffmpeg to livestream to twitch.tv from either a screen or a file. [02:24] <chamunks> The screen one would be more complicated because I'd want to overlay a logo or something in the lower third. [02:26] <chamunks> I've found this link http://nixc.us/1fNOoaQ it was an archived link but I'm kind of oblivious how to make this situation work. [02:27] <chamunks> llogan, ^ sorry for the wall of text. [02:32] <chamunks> So many arguments and variables. [02:33] <Fusl> hmm is trac.ffmpeg.org down? [02:33] <Fusl> or is it justme? [02:34] <Fusl> ... again? [02:34] <chamunks> I had to dip into google cache for that link. So it was down for me too. [02:35] <Fusl> hmm [02:37] <chamunks> Wish I could help [02:51] <llogan> chamunks: ffmpeg -re -i video.mkv -i logo.png -filter_complex "[0:v][1:v]overlay=(W-w)/2:H-h-20[out]" -map "[out]" -map 0:a -c:v libx264 -preset medium -maxrate 1000k -bufsize 2000k -g 2 -c:a libdsk_aac -b:a 128k -f flv rtmp://output [02:52] <chamunks> :) [02:53] <chamunks> I will give this a shot thanks ever so graciously. [02:54] <llogan> chamunks: you'll need to adjust maxrate and bufsize [02:54] <chamunks> Its probably going to need to scale a fair bit depending I'm sure. [02:54] <llogan> s/libdsk_aac/libfdk_aac [02:55] <llogan> scaling the whole thing or the logo to be overlaid [02:56] <llogan> maxrate being the minimum network transfer rate you want to support (or perhaps your max upload rate*.8 or something for overhead, etc) [02:57] <chamunks> For now I've only got a 5meg down .8 up [02:57] <chamunks> In the next few weeks it should be bumped up to 25/10 [02:57] <chamunks> but I can push any videos from one of my servers if I can that way. [03:01] <llogan> chamunks: that streaming guide needs to be cleaned up. most of it is from one guy and he is too verbose and sloppy [03:02] <llogan> looks like a bunch of notes to himself [03:10] <chamunks> yeah it certainly does. [03:19] <chamunks> I have a LUG that I attend on occasion that I was doing the livestreaming for via *Cough a windows box *Cough *Cough [03:19] <chamunks> I just donated a BlackMagic Intensity Pro card to them so they can stream. [03:20] <chamunks> I should see how this command you sent me would work out with that in the future. [04:59] <semslie> I have an ffmpeg problem that I am struggling to diagnose: my input is a directory of frames, the output is an mkv with video from the frames, and an audio track. In the output, the video just freezes before the end of the frames has been reached (the audio continues for the correct duration). Can anyone recommend an approach to diagnosing this? [05:19] <Keestu> Dear all, http://pastebin.com/rbHkDziE the CodecContext width and height is always zero in my code. [05:20] <Keestu> could someone help me to tell where i commit the mistake? [05:35] <kcm1700_> Keestu: sometimes the container doesn't have relevant video dimension info. In this case, you must try decoding some frames to get the correct width and height (this could also be changed during playing) [05:38] <Keestu> kcm1700_, Ah.. Thanks a lot, thats why i see the correct dimension after decoding the packet. Between av_read_frame() does it return more than one frame ? [06:04] <Logicgate> hey guys, when using video scaling, it doesn't resize the video properly [06:05] <Logicgate> I'm trying to resize a video to be 1:1 in ratio (480x480) [06:05] <Logicgate> but then resizing a 16:9 video, there's black bars at the top and bottom. [06:05] <Logicgate> is there a way to scale the video to fit the canvas fully? [06:23] <vineet> anyone here? [06:23] <vineet> for a two pass encoding test, do i need to provide -ss, and -t options in both command? [06:25] <vineet> ffmpeg -ss 0 -t 30 -i INPUT -pass 1-an -f rawvideo /dev/null && ffmpeg -i INPUT -pass 2 -f mp4 OUTPUT [06:25] <vineet> is this correct? [06:26] <vineet> os do i need to put -ss 0 -t 30 in second invocation as well? [06:43] <vineet> for a two pass encoding test, do i need to provide -ss, and -t options in both command? ffmpeg -ss 0 -t 30 -i INPUT -pass 1-an -f rawvideo /dev/null && ffmpeg -i INPUT -pass 2 -f mp4 OUTPUT. is this correct? [06:44] Last message repeated 1 time(s). [07:27] <apathadeus> I've tried to google this problem but haven't been successful: I have a bunch of RTP NAL h264 video packets that I want to assemble into a video file. Unfortunately, NAL does not encapsulate frame rates, and frame rate may not be fixed. How can I use libav or ffmpeg to generate a video in this situation properly? [07:29] <apathadeus> as a first attempt, I was able to concatenate the h264 packets properly, feed it thru ffmpeg and generate a video file. However, the frame rate is all wrong -- the video is sped up [07:35] <znf> apathadeus, I've slept like ~6 hours in the last 5 days, but, could you do something time-based? [07:35] <znf> I'm gonna asume you don't have audio with those [07:36] <apathadeus> audio would be ideal, but i want to get just video working first -- good first step [07:37] <apathadeus> i think i can figure out the FPS at a moment in time from the RTP packets, I just don't know how to tell ffmpeg [07:37] <znf> I'm asking about audio because you could sync it to the audio [07:38] <znf> (as I'm assuming the audio stream is fixed, somehow) [07:38] <apathadeus> well, i don't think sync-ing to audio is a good idea -- i know that the server sometimes saves bandwith by not outputting audio packets when there's silence [07:38] <apathadeus> so...if i sync to audio, the video might freeze when there's silence... [07:43] <znf> apathadeus, again, I'm extremely tired, but the server could probably still transmit audio-frames, even if they're empty or whatever, couldn't it? [07:46] <apathadeus> i'm 90% sure that it does this bandwidth shinanigans: when I use mplayer to play this SDP file, the video freezes on silence. same thing happens with ffplay. HOWEVER, if i use ffplay -sync ext, then video plays fine during silence [07:46] <apathadeus> znf: don't worry about it...go to sleep :) i'll continue my search [07:47] <znf> I'm not done with my stuff :) [07:47] <apathadeus> thanks for your help anyways [07:48] <znf> not much help :) [07:48] <apathadeus> do you know some good keywords to use to search for this problem on google? maybe i'm not supplying the right keywords :D [07:50] <apathadeus> anyways, i gtg...i'll probably stop by again tomorrow. thanks anyways! :D [07:51] <vineet> register 000000000 mvineetmenon(a)gmail.com [07:53] <anshul> I am unable to compile my code with binary files for windows given at zerone [07:54] <anshul> it shows me avfilter-4.dll missing when i eun the executable [07:55] <anshul> in the package at zerone there is no avfilter-4.dll [09:21] <Keestu> Hello, It is really confusing. i am trying ffmpeg in android, and my question is after reading frame from rtsp server, do we need to work with dts/pts for rendering?. [09:21] <Keestu> or do we have any library api to do the same ? [10:38] <excalibr> Hi! [10:39] <relaxed> howdy [10:39] <excalibr> I just ripped out the raw video and audio stream of a mp4 file. How do I merge these 2 files into a mkv container? [10:41] <JEEB> just remux from mp4 to matroska [10:41] <JEEB> don't extract the tracks in between [10:41] <JEEB> you'll lose timestamps, among other stuff [10:41] <JEEB> ffmpeg -i hurr.mp4 -c copy out.mkv [10:41] <JEEB> (and -map 0 if you really want to select all tracks from the first (zero'th) input) [10:43] <excalibr> ouh..didn't know its that easy. what if I want to embed a sub file into the mkv during the remux? [10:44] <relaxed> shouldn't matter [10:44] <JEEB> add another input file? [10:45] <JEEB> ffmpeg -i input.mp4 -i your.sub -map 0 -map 1 -c copy out.mkv [10:45] <excalibr> ok. because i thought i can only specify -i once [10:45] <relaxed> read the fine manual [10:46] <excalibr> i did (-h long) but i wasnt clear about that [10:46] <excalibr> thank you for help [10:46] <JEEB> http://ffmpeg.org/ffmpeg-all.html is what I generally use [10:46] <relaxed> man ffmpeg-all [10:46] <JEEB> for the "full help" [11:51] <xqo> hi [11:51] <xqo> im trying to convert an mp4 to webm with ffmpeg like so: ffmpeg -i nanaIndianDance2.mp4 -acodec libvorbis -aq 5 -ac 2 -qmax 25 -threads 2 nanaIndianDance2.webm, but it does not work. This is the output i get: Unable to find a suitable output format for 'nanaIndianDance2.webm' [11:54] <xqo> (i get the same output without all the settings too) [11:58] <Evgen26> Hi! Tell me please, what mux can I use with huff encoder? [12:07] <xqo> how can i give webm support to ffmpeg? [12:17] <relaxed> Evgen26: .avi or .mkv [12:17] <relaxed> xqo: your ffmpeg may be too old and lack support. [12:18] <Evgen26> relaxed: Apparently avi does not broadcast timestamps and the vlc stops playing after two minutes. [12:18] <relaxed> xqo: you can use http://johnvansickle.com/ffmpeg/ [12:18] <Evgen26> relaxed: I try to find another format, but so far unsuccessfully. [12:18] <relaxed> Evgen26: then use matroska [12:19] <Evgen26> relaxed: I've tried. does not operate it. [12:19] <Evgen26> relaxed: I need to transfer video from gstreamer to vlc by pipe without loss of quality and CPU load. [12:20] <relaxed> Evgen26: what are you actually doing? [12:20] <Evgen26> relaxed: I use gstreamer with av plugin [12:20] <relaxed> to capture what? [12:21] <Evgen26> EasyCap+Alsa [12:21] <relaxed> Easycap is screen capture? [12:21] <Evgen26> no, this is device on stk1160 chip [12:22] <relaxed> oh [12:22] <Evgen26> I use video muxer [12:22] <Evgen26> SnowMix [12:22] <Evgen26> It operate with gstreamer [12:22] <relaxed> did you ask in #gstreamer ? [12:23] <relaxed> maybe there's a better method [13:18] <xqo> thank you, relaxed, ill try. [13:19] <xqo> cant apt-get update the one ive installed though? i just did apt-get install ffmpeg today (debian) [13:23] <xqo> (the builds from your link worked though) [14:23] <Keestu> i am building ffmpeg in android, and i get the warning like pkg-config is missing in cross compiler. why .so is required this 'pkg-config' ? [14:23] <JEEBsv> it's a warning, nothing more. You always get it when you don't have pkg-config for a given cross-prefix [14:24] <JEEBsv> it's just that some libraries are found via pkg-config easier [14:24] <JEEBsv> if everything is found just fine for you, then just don't care [14:57] <Keestu> JEEBsv, this pkg-config is at compile time only right ? [14:58] <JEEBsv> yes, it's a tool to find the library/header directories easier [14:58] <Keestu> run time ofcourse not required right ?. sorry just updating my perception .:) [14:59] <JEEBsv> I think if you read my response I'd say it's pretty understandable ;) [15:00] <Keestu> yup. Thanks. if i enable --enable-libx264 does it have code already with x264 inside, or does it look outside that we need to give the source code to ffmpeg ? [15:00] <Keestu> i mean does x264 library is part of ffmpeg or it is a seperate [15:01] <JEEBsv> libavcodec only has a wrapper around libx264 :) so yes, you will have to compile and install libx264 to some prefix, and then have ffmpeg's configure know where you have it [15:02] <Keestu> JEEBsv, that helped ;). Where can i find such informations ? [15:03] <Keestu> because i compiled with --enable-libx264, but it is not showing any error that it required lib/headers. [15:04] <Keestu> JEEBsv, Ah i found here it is http://ffmpeg.org/general.html :) [15:22] <drizztbsd> hi, why is AVFormatContext->metadata empty for opus? [15:28] <maister> What's the difference between yuv444p and yuva444p pixel formats? [15:29] <drizztbsd> alpha? [15:30] <maister> hm, ye, that makes sense. Says 4 components here ... [15:30] <maister> Another question. Is it defined which color transform is used for yuv444p? I'd like BT.709. [16:48] <pw_> hello. I'm trying to use ffmpeg to extract just the I frame on a snippet of the video stream containing the I frame+audio and then telling ffmpeg to dump it to a file. [16:49] <pw_> i am, however, not getting ffmpeg to recognize one of the pid as a h264 stream. [18:55] <littulb__> Question. Anybody use ffmpeg with F# ??? [19:50] <ChocolateArmpits> Is libfdk_aac encoder compatible with AAC-LC? Are any additional settings needed? [19:51] <llogan> ChocolateArmpits: yes. no. AAC-LC is default. [19:53] <ChocolateArmpits> llogan, so -profile:a is only used to specify aac_he ? [19:54] <llogan> you can be explicit if you want to [19:54] <w-wright> Hello, I have been having trouble with compiling FFmpeg from source on Github and enabling libfdk-aac [19:55] <w-wright> Could I have some help as it seems I have missed something out! [19:56] <ChocolateArmpits> llogan, so it takes "aac_lc" as an option too? [19:58] <llogan> w-wright: what issues exactly? also, the official repo is git://source.ffmpeg.org/ffmpeg.git [19:59] <w-wright> I was using the official repo but when I try to do ./configure --enable-libfdk-aac it says it is not recognised. [20:00] <w-wright> I am quite new to FFmpeg as well though [20:01] <llogan> whats your distro? [20:01] <llogan> ChocolateArmpits: apparently it does. http://ffmpeg.org/ffmpeg-codecs.html#libfdk_005faac [20:02] <ChocolateArmpits> llogan, cool thanks [20:02] <w-wright> My distro is Debian 7.3 on i386 [20:03] <llogan> http://webcache.googleusercontent.com/search?q=cache%3Ahttp%3A%2F%2Ftrac.ff… [20:03] <llogan> the wiki server is currently down [20:04] <llogan> anyway, navigate to the ffmpeg source code directory, then run: "make distclean; git pull" [20:04] <llogan> also, did you install libfdk-aac? [20:05] <w-wright> Yeah I did. [20:05] <llogan> from git? [20:05] <w-wright> yeah and I also did the same for x264 which also does not wanna work [20:06] <llogan> what about config.log in ffmpeg directory, can you provide that via pastebin.com or similar? [20:08] <w-wright> I can't find the config.log [20:14] <w-wright> I have tried again. I think that forgetting the --enable-nonfree bit could make a big difference [20:19] <llogan> w-wright: you only need that if you use --enable-gpl with --enable-libfdk-aac [20:24] <llogan> looks like fdk-aac will be moving from AUR to [community] in Arch [20:30] <Evgen26> I try to execute http://pastebin.com/KnXGTEWU but no have audio data. When I cnange matroskamux to the avimux then I can see audio data. What problem? [20:36] <llogan> Evgen26: i don't see ffmpeg anywhere in there. maybe you should try the IRC channel for gstreamer...if one exists [20:37] <Evgen26> llogan: There's a silent channel :-) [20:37] <llogan> we only support FFmpeg stuff here [20:40] <pw_> is there a way to specify the decoder to be used when using avconv so that it doesn't probe around for it in mpegts? [20:41] <llogan> pw_: what's avconv? [20:41] <pw_> fine, ffmpeg [20:42] <pw_> i asked a simple question that can be answered by a yes or no, not a please paste your stuff into pastebin [20:43] <llogan> please understand that there are always more people asking questions than those providing answers. if you don't readily provide the required information then i'll just move on to the next question [20:48] <pw_> hrm. apparently, the libav side is a bit more direct. their answer to my simple question is a simple "not really" [20:48] <pw_> nothing that pastebin could've solved [20:49] <llogan> the pastebin would have indicated if you were using ffmpeg from FFmpeg [20:49] <llogan> we only support tools from FFmpeg here [20:51] <pw_> a quick "not really" would've suffice, even if i were using ffmpeg [20:52] <llogan> fake ffmpeg != ffmpeg [20:52] <pw_> are you implying that ffmpeg can do it but not the fake ffmpeg? [20:52] <pw_> if so, then that's a different story [20:53] <pw_> if your whole pastebin was to try to embarass me about using libav, then I would have to say that's pretty lame. [20:54] <llogan> that was not the intention [20:55] <llogan> 1. there are many questions to answer (and I don't mean just here) 2. i have limited time to provide answers 3. this is #ffmpeg. the support channel for FFmpeg. We only support stuff from FFmpeg. 4. I suspected you were not using ffmpeg [21:48] <zumba_addict> hey folks, is it possible to overlay a small image on an existing video using ffmpeg? [22:10] <llogan> zumba_addict: yes. it will require re-encoding unless you want to do it upon playback with ffplay. [22:11] <zumba_addict> reencoding is fine. How do I do it? [22:11] <llogan> see the overlay video filter: http://ffmpeg.org/ffmpeg-filters.html#overlay [22:11] <zumba_addict> cool [22:11] <zumba_addict> thanks [22:12] <llogan> zumba_addict: ffmpeg -i video.mp4 -i logo.png -filter_comples "[0:v][1:v]overlay[out]" -map "[out]" -map 0:a -c:v libx264 -crf 23 -preset medium -c:a copy output.mp4 [22:12] <llogan> for example [22:12] <zumba_addict> cool :) [22:12] <zumba_addict> thanks [22:13] <llogan> *filter_complex [22:13] <llogan> add "-movflags +faststart" if you use my example and your viewers will be watching it via a browser [22:18] <zumba_addict> ok [22:20] <vl4kn0> Hi, I'm decoding video for further processing of the retrieved frames using ffmpeg api but I get these error messages: http://fpaste.org/74784/39163510/ could anyone point me to the right direction? I have no idea what's going on. [22:25] <llogan> vl4kn0: you should also include your code, and try the libav-user mailing list if you don't get an answer here. [22:26] <JEEB> looks like you're either doing something wrong before feeding whatever you're getting to the decoder, or the input is just kind of garbage. Or there is a bug in the MPEG-4 Part 2 decoder [22:26] <JEEB> all of those are possible [22:27] <JEEB> PEBKAC is usually the reason tho [22:39] <littulb> How can I stop ffmpeg from opening terminal when outputting? [22:40] <littulb> I'm trying to optimize throughput [22:46] <littulb> ??? [22:58] <littulb> littulb How can I stop ffmpeg from opening terminal when outputting? [23:04] <llogan> littulb: i don't think anyone understands your question [23:07] <SirCmpwn> I'm trying to record from my webcam with ffmpeg [23:07] <SirCmpwn> and I was going to use ffplay show what was being recorded as it was doing so [23:08] <SirCmpwn> but ffmpeg can't use the webcam when ffplay is using it [23:08] <SirCmpwn> solutions? [23:10] <littulb> I'm using f# to convert files. The command <ffmpeg ... -vvodec...> opens a shell or a terminal that shows a log. [23:10] <littulb> It happens every time it encodes [23:11] <littulb> I want to keep that shell/terminal from opening [23:16] <littulb> Ok. How about getting the shell to run in the background? [23:16] <littulb> So sorry i can't find a better way to explain my problem [00:00] --- Thu Feb 6 2014

1 0

ffmpeg-devel.log.20140204
by burek 05 Feb '14

05 Feb '14

[00:03] <michaelni> thardin, ok if i remove that "TBA, possibly " ? i just added this to all i copied from last year [00:03] <michaelni> as i didnt know if they are again available this year [00:10] <michaelni> where did cone go ? [00:12] <michaelni> did the netsplits take her to a parallel plane of existence and she is now lonely announcing commits in empty space ? [04:50] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:8a3b85f3a795: avcodec/h264: update current_sps & sps->new only after the whole slice header decoder and init code finished [05:03] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:10238ada6dac: cmdutils: update year [05:03] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:e04f68f7c522: dnxhdenc: fix mb_rc size [05:04] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:7adf4a92a17d: avcodec/vmnc: Check that rectangles are within the picture [05:04] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:74821341b9ac: avcodec/takdec: always check bits_per_raw_sample [05:04] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:af74599e66b1: avcodec/vc1: reset fcm/field_mode in non advanced header parsing [05:07] <michaelni> thardin, i just tried avplay, its stuck after 4sec as well [05:34] <cone-703> ffmpeg.git 03Anton Khirnov 07release/1.1:e38c62fe0c24: lavf: simplify handling of offset in av_probe_input_buffer() [05:34] <cone-703> ffmpeg.git 03Anton Khirnov 07release/1.1:539d255871c9: lavf: use a fixed width type [05:35] <cone-703> ffmpeg.git 03Anton Khirnov 07release/1.1:8575f5362f98: lavf: make av_probe_input_buffer more robust [05:35] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:c06f8bac204a: avformat/utils: fix av_probe_input_buffer2() so it returns the probe score [05:35] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:35bf91c5b55b: Merge commit '8575f5362f98c937758b20ff8512d6767a56208e' into release/1.1 [05:35] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:82b44665e982: avformat/utils/av_probe_input_buffer2: Fix pd.buf_size [05:35] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:3994eebb1e87: avformat/utils/av_probe_input_buffer2: fix offset check [05:35] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:ee3ce73bfb29: avformat/utils/av_probe_input_buffer2: fix buffer passed to ffio_rewind_with_probe_data() [05:35] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:a5c3f596d1f7: avformat/utils: av_probe_input_buffer2 decrease difference to libav [05:58] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:af9799790d7a: dsputil/pngdsp: fix signed/unsigned type in end comparison [05:58] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:10d48fe6d396: flashsv: Check diff_start diff_height values [05:58] <cone-703> ffmpeg.git 03Luca Barbato 07release/1.1:f1476459b701: vmnc: K&R formatting cosmetics [05:58] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:fd856693defa: Merge commit 'f1476459b7013d306eb911573f1dc81e74ccd082' into release/1.1 [06:11] <cone-703> ffmpeg.git 03Luca Barbato 07release/1.1:9f9e773881cf: vmnc: Port to bytestream2 [06:11] <cone-703> ffmpeg.git 03Luca Barbato 07release/1.1:4b24eb1a03f2: vmnc: Check the cursor dimensions [06:11] <cone-703> ffmpeg.git 03Luca Barbato 07release/1.1:3485a07977f1: avi: DV in AVI must be considered single stream [06:11] <cone-703> ffmpeg.git 03Luca Barbato 07release/1.1:c85e5f13f6ac: cavs: Check for negative cbp [06:11] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:9ac7d8f85d71: Merge commit 'c85e5f13f6ac9c4c90125e7671d89009e57f9df9' into release/1.1 [06:32] <cone-703> ffmpeg.git 03Anton Khirnov 07release/1.1:969028870c6f: cavsdec: check ff_get_buffer() return value [06:32] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:d9c82cea11ce: h263: Check init_get_bits return value [06:32] <cone-703> ffmpeg.git 03Anton Khirnov 07release/1.1:b5275ca1a805: h264_cavlc: check the size of the intra PCM data. [06:32] <cone-703> ffmpeg.git 03Anton Khirnov 07release/1.1:f728782c0d30: segafilm: fix leaks if reading the header fails [06:32] <cone-703> ffmpeg.git 03Martin Storsjö 07release/1.1:44079902c49e: mov: Free intermediate arrays in the normal cleanup function [06:32] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:e2781db62a40: Merge commit '44079902c49e526f464bb4eb855665e1af867e91' into release/1.1 [06:39] <cone-703> ffmpeg.git 03Martin Storsjö 07release/1.1:a1b4d42d31ba: mov: Free an earlier allocated array if allocating a new one [06:39] <cone-703> ffmpeg.git 03Anton Khirnov 07release/1.1:62ed6da016b7: h264: check that an IDR NAL only contains I slices [06:39] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:cb8180885f22: Merge commit '62ed6da016b789eee00e0fff517df4a254e12e5d' into release/1.1 [07:05] <cone-703> ffmpeg.git 03Anton Khirnov 07release/1.1:299c5dcfb0cd: h264: reset num_reorder_frames if it is invalid [07:05] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:3cc8d9bc1ffc: vc1: Always reset numref when parsing a new frame header. [07:05] <cone-703> ffmpeg.git 03Anton Khirnov 07release/1.1:03bfd8419fba: mathematics: remove asserts from av_rescale_rnd() [07:05] <cone-703> ffmpeg.git 03Anton Khirnov 07release/1.1:bf7c240a50f8: oggparseogm: check timing variables [07:05] <cone-703> ffmpeg.git 03Reinhard Tartler 07release/1.1:27f60e2b0b41: Update Changelog for 9.11 [07:05] <cone-703> ffmpeg.git 03Michael Niedermayer 07release/1.1:08dde7567dea: Merge remote-tracking branch 'qatar/release/9' into release/1.1 [07:23] <ubitux> BBB: yes? [08:14] <thardin> michaelni: huh. strange [08:14] <thardin> but at least it's something to fix :) [11:57] <ubitux> BBB: i have a fast 44_16 working for vert, and i need to make a faster transpose for the horizontal one [11:57] <ubitux> i'll submit in a day or two i guess [12:20] <Keestu_> when i play h264 video with ffplay 0.11 and ffplay 2.0, i see significant difference, but same in 800*640, are there any changes gone after 0.11 version specifically for H264? [12:25] <nevcairiel> define difference [12:28] <ubitux> between 0.11 and 2.0: 3260 files changed, 312860 insertions(+), 159965 deletions(-) [12:29] <pross-au> thats like 1/3rd of the codebase [12:30] <nevcairiel> 0.11 is pretty old [12:30] <ubitux> 2.0 is as well btw [12:31] <ubitux> BBB: actually, i probably can't do anything about the transpose since i need 8 lines for 44 as well... [12:31] <ubitux> so i'll submit tonight [12:33] <Keestu_> nevcairiel, difference in terms of handling h264 format. :) [12:33] <nevcairiel> no, what differences do you see [12:33] <Keestu_> i am trying to port ffmpeg into android, hence asking. [12:34] <ubitux> BBB: overall time goes from 3.90s to 3.78s [12:34] <Keestu_> nevcairiel, ok, while i tried with ffplay in both the versions, in the new version, the video clarity is perfect, where as it is not in 0.11 [12:34] <ubitux> (ped1080p.webm) [12:34] <Keestu_> but if i play 800*640 video both the versions has no difference. [12:35] <Keestu_> sorry it is *2.1 [12:35] <Keestu_> :) [13:03] <BBB> ubitux: output transpose vs input transpose [13:04] <BBB> ubitux: same as for h_88 (where you don't need a 16x8, just a 8x8 for the output, and then use movq/movhps x8 instead of movqx16 to move back to memory) [13:04] <BBB> ubitux: so here you can do a fast 4x4 transpose that outputs to memory [13:04] <BBB> errr I mean output the result of that in chnks to memory [13:05] <BBB> (see vp8 also) [13:24] <BBB> ubitux: and yes input would still be a full 16x8, I guess that sucks but nothing you can do [13:25] <ubitux> indeed i can probably simplify the out transpose [13:25] <ubitux> especially given that i probably have some of the values in registers already [13:52] <cone-703> ffmpeg.git 03Anton Khirnov 07master:b25e84b7399b: hevc: check that the VCL NAL types are the same for all slice segments of a frame [13:52] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:a0d5204cd990: Merge commit 'b25e84b7399bd91605596b67d761d3464dbe8a6e' [14:11] <ubitux> http://pastie.org/8697703 seems like libav decided to remove some cosmetics now (jvdec.c) [14:11] <ubitux> spaces shuffling \o/ [14:15] <Compn> abandon prettyprinting ? [14:15] <ubitux> i guess it's just recursive cosmetics [14:37] <nevcairiel> its funny when they do that [14:41] <kierank> it's annoying because it makes stuff hard to merge [14:41] <kierank> in both directions [15:08] <cone-703> ffmpeg.git 03Keith Lawson 07master:de203abd71ba: vf_overlay: add eof_action switch [15:08] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:905cd28a5a0b: Merge commit 'de203abd71baae7f120313259b45cf935c85203e' [15:08] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:cddbe9fa2eb5: avfilter/dualinput: fix repeatlast to match docs and eof_action=pass [15:15] <cone-703> ffmpeg.git 03Jan Ekström 07master:5de64bb34d68: utvideoenc: Add support for the new BT.709 FourCCs for YCbCr [15:15] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:40fc1e2dda7b: Merge commit '5de64bb34d68d6c224dca90003172d7a27958825' [15:23] <cone-703> ffmpeg.git 03Anton Khirnov 07master:7b03b65bf0d0: lavf: do basic sanity checking on muxed packets [15:23] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:5144d919964f: Merge commit '7b03b65bf0d02519c86750d2da33f413e11cf0c6' [16:07] <cone-703> ffmpeg.git 03Anton Khirnov 07master:33c859c142ef: lavf: ignore attachment streams for interleaving purposes [16:07] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:073e771c9c53: Merge commit '33c859c142ef3f49b7a6227014ad92a680cf4d74' [16:07] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:c18cfd1001e0: ffserver: use avformat_alloc_context() [16:26] <cone-703> ffmpeg.git 03Anton Khirnov 07master:e46ad30a8087: vp8: use a fixed-size edge emu buffer [16:26] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:9a082fec1af5: Merge commit 'e46ad30a808744ddf3855567e162292a4eaabac7' [16:29] <ubitux> BBB: ok so i got a simpler transform [16:30] <ubitux> anyway, overall, it's not that much faster [16:30] <ubitux> do you want me to start looking at the _8 variants now? [16:53] <ubitux> mmh found a way to simplify some code [17:16] <cone-703> ffmpeg.git 03Anton Khirnov 07master:1f097d168d9c: h264: reset data partitioning at the beginning of each decode call [17:16] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:c93e69136925: Merge commit '1f097d168d9cad473dd44010a337c1413a9cd198' [17:16] <ubitux> yay, saved about 6 instructions [17:23] <ubitux> http://pastie.org/pastes/8698325/text [17:24] <nevcairiel> you should optimize that function on the top there [17:25] <ubitux> probably yes :p [17:26] <ubitux> i'm start lacking motivation for doing the remaining _8 variants of lpf [17:26] <ubitux> -'m [18:08] <relaxed> https://trac.ffmpeg.org/ seems to be down [18:21] <Compn> relaxed : server maint [18:25] <Daemon404> Compn, usually you would put up a page saying that [18:25] <Daemon404> instead of jst timing out [18:25] <nevcairiel> maybe the whole server is in maint [18:26] <nevcairiel> its a bit crazy to redirect dns for a few hours of maintenance =P [18:26] <Daemon404> usually they put a notice for the preceding few hours/days too [18:26] <Daemon404> warning of it [18:26] <Daemon404> ;) [18:26] <nevcairiel> maybe it was there!?!? [18:26] <nevcairiel> :D [18:27] <Compn> the whole server is down, correct [18:27] <Daemon404> rm -rf / [18:28] <Daemon404> woops [18:28] <Daemon404> server maitenence time [18:28] <nevcairiel> thats an impossible command on any recent linux [18:28] <Compn> i blame ubuntu [18:33] <Daemon404> nevcairiel, eh [18:34] <Daemon404> just 1.5 yers ago i did it on ubuntu [18:34] <Daemon404> must be pretty recent [18:34] <Daemon404> or well, i did: rm -rf dir /* [18:35] <nevcairiel> i just know that the plain rm -rf / requires an extra parameter to eb passed to work [18:35] <nevcairiel> not sure since when [18:35] <nevcairiel> but ubuntu isnt known for cutting edge versions of things [18:35] <Daemon404> lol [18:35] <Daemon404> since then ive stopped using bash [18:35] <Daemon404> i use zsh fulltime [18:36] <nevcairiel> rm is a builtin in zsh? [18:36] <Daemon404> no? [18:36] <nevcairiel> then why does it matter? [18:36] <Daemon404> it can check commands for stupidity before running them [18:36] <Daemon404> in nteractive mode [19:07] <ubitux> BBB: https://github.com/ubitux/FFmpeg/compare/vp9-simd [19:41] <llogan> Daemon404: don't feel bad. one user destroyed /var on a work server. he was trying out magento which smartly uses the name "var" for a directory, AFAIK. [19:41] <Daemon404> llogan, luckily this was just my personal workstation [19:41] <Daemon404> i just reinstalled the OS and sync'd my dot files [19:41] <Daemon404> it sure was a waste of time though [19:42] <llogan> yeah. this was before I had daily images. [20:38] <kierank> thardin: Aside: can we just use libmxf instead? Or would that cause problems? I [20:38] <kierank> know NIH runs deep in this project, [20:38] <kierank> lol [20:38] <kierank> opening a can of worms here [20:42] <Daemon404> kierank, do you think it i possible for a 3rd party (us) to independently implement mxf? [20:42] <Daemon404> i dont. [20:42] <Daemon404> because mxf. [20:43] <nevcairiel> isnt ffmpeg kinda a third party that implemented mxf independently? [20:43] <Daemon404> and it doesnt work a lot :P [20:43] <nevcairiel> i have no idea [20:43] <nevcairiel> i just got people complain to me once that they want to play mxf audio, and i only allow playing one stream [20:43] <nevcairiel> (while apparently mxf audio comes one channel in one stream or something) [20:46] <thardin> kierank: I am well aware :) [20:46] <kierank> I personally don't think there is anyone in the world who knows mxf better than the author of libmxf [20:47] <thardin> but I'm more worried about mxfenc producing crap files that need to be supported in future versions [20:47] <thardin> forever [20:48] <thardin> yeah. bbc is pretty safe bet [21:08] <kierank> libmxf is the ultimate troll tool [21:08] <kierank> since it's the reference implementation for mxf file delivery in the uk [21:08] <kierank> useful for proving people's shit is broken [21:20] <thardin> nice [21:20] <thardin> mxfdump and mxfsplit are also useful [21:22] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:41f974205317: avcodec/vc1dec: vc1_pred_b_mv() is not used for fields, simplify code [21:22] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:20be510887d0: avcodec/vc1dec: remove blocks_off use from vc1_pred_b_mv() [21:23] <kierank> thardin: many vendors are starting to attack open source [21:23] <kierank> so I have started a fightback [21:25] <kierank> they get angry when i prove their stuff is broken as Daemon404 saw [21:26] <ubitux> mxf generated with ffmpeg are libmix-compliant? [21:26] <ubitux> s/mix/mxf/ [21:27] <thardin> kierank: yeah, I've done similar things [21:28] <thardin> I suspect mxf is designed to create billable hours [21:42] <j-b> kierank: what is it? [21:42] <j-b> libmxf? [21:45] <kierank> yes [21:45] <kierank> j-b: thardin has suggested adding libmxf support to ffmpeg [21:46] <JEEB> sounds like a good idea [21:46] <JEEB> mxf is something that you might not want to divide resources on [21:47] <j-b> kierank: the BBC thing? [21:47] <kierank> Yeah [22:05] <saste> anybody going to mentor gsoc projects? [22:09] <llogan> Mentoring organization application deadline is Feb 14, so we have ~10 days. [22:12] <j-b> good luck [22:14] <llogan> j-b: we decided to give it a try, but personally i'm not expecting anything different from Google. [22:18] <j-b> llogan: good idea. [22:18] <j-b> please add DTS-HD decoder to the list [22:20] <saste> llogan, anyway any available mentor? [22:20] <saste> and, trac is down [22:25] <llogan> saste: i'm not sure of the status of trac, or who wants to mentor other than michael, paul, and maybe thomas. [22:27] <llogan> j-b: will copying this suffice? http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_of_Code_2013#DTS_.2… [22:27] <michaelni> llogan, saste ill probably put the gsoc wiki page onto wiki.multimedia.cx just trying to finish merging the formatting back in [22:27] <j-b> llogan: yes [22:27] <llogan> michaelni: why? due to trac being down lately? [22:28] <llogan> j-b: ok, i'll add it. would you like to mentor it? [22:28] <michaelni> because multimedia.cx seems more stable ATM than trac.ffmpeg.org [22:28] <michaelni> also we lost some formating when we copied it from archive.org [22:29] <llogan> what's the deal with trac today? [22:30] <michaelni> will write news entry about it but i need to work on gsoc wiki [22:30] <michaelni> now [22:31] <llogan> i don't like having to rely on a third party wiki, but i guess if trac is being shitty... [22:31] <michaelni> gsoc doesnt wait ... sadly [22:32] <ubitux> :( [22:32] <ubitux> i guess that gives me some delay before editing it [22:32] <llogan> is libaby applying too? [22:33] <JEEB> <facugaich> Hi, I was wondering if you guys have any plans for GSoC 2014 [22:33] <JEEB> <Keiler> probably not entering [22:33] <JEEB> <Keiler> Google has WebM after all [22:33] <JEEB> from #libav-devel [22:33] <llogan> ah. he asked in #ffmpeg too. [22:33] <llogan> "facugaich | llogan: Well... I was planning on doing it as a CS project, so I was looking for something with a little bit of academic interest" [22:34] <llogan> i told him to come here if he has additional questions, etc [22:35] <JEEB> he seemed to have asked around [22:35] <JEEB> he was in #videolan too [00:00] --- Wed Feb 5 2014

1 0

ffmpeg.log.20140204
by burek 05 Feb '14

05 Feb '14

[01:31] <mbhatnag> Hello. I am running ffmpeg version 2.1.1. I am trying to convert a h264,ac3 .mkv to a vp8,ogg .webm file with constant bitrate. the command I am using is "ffmpeg -i video.mkv -c:v libvpx -b:v 450k -minrate 450k -maxrate 450k -c:a libvorbis -b:a 48k -ac 2 video.webm". the output video file that is produced always has a very high bitrate (1000+kbps). I would like some help with making ffmpeg produce a constant bitrate file. the source file has a size of [01:31] <mbhatnag> 1280x714 and I am not altering that. [01:40] <atari_> Does anyone know if there's an inverse telecine filter for 1.2.5 or before on that same branch? There seems to be no pullup or fieldmatch filter, until the later 2* releases. Only issue is that I'm using gentoo and would like to be able to just use the stable version in their repos because it's easier to maintain, but the only thing missing is an inverse telecine filter. [01:42] <Demon_Fox> I believe the hardcoded tables are slow [02:00] <znf> Is it normal that when I create a video I get a pixel format of "rgba", but when I do ffmpeg -i I get back "argb"?! [02:03] <Demon_Fox> It probably needs some kind of conversion filter or something [02:03] <Demon_Fox> to take to yuv [02:04] <znf> Hmmm [02:04] <znf> this thing is so annoying :-( [02:05] <znf> I can't seem to create a semi-transparent progress bar [02:18] <Demon_Fox> ? [02:24] <znf> Actually I sort of made it :P [02:24] <znf> http://i.imgur.com/HIx7RiD.jpg [02:24] <znf> I created a progress bar animation [02:24] <znf> but it's a bit too on the white side :-/ [02:31] <dbro> Cross-compiled FFmpeg for Android, but can't get libavformat to properly link to librtmp [02:32] <dbro> my searching has only turned up others' misery on the subject, is there any hope? [02:32] <dbro> this sort of sums it up: http://stackoverflow.com/questions/20721445/undefined-reference-when-compil… [03:07] <znf> Oh. Drawbox has no time or frame parameters. Bummer. [03:08] <znf> Can I somehow else get the current framenumber? [07:34] <znf> How would I sync a video with audio of a different duration? Let's say I have a video of 1 minute but an audio file of 3 minutes; I need them to start both at 00:00 and end at the duration of the audio, but without looping the video. [11:50] <dannyzb> guys , i'm designing a platform that is going to need to convert 3000-4000 hd(720p) videos a day from avi to MP4.. what is the best setup for that ? (hardware-wise) [11:50] <dannyzb> should i stick to ffmpeg or are there faster hardware products? [11:51] <JEEB> the best hardware encoder is haswell's QS encoder so far, ~200fps or so? You can get a similar amount of speed with the CPU and libx264 with such a CPU as well, if not even faster. [11:52] <JEEB> so in theory I guess you could set up two things? One running on QS, the other on the CPU? Depends on how good quality QS gives out. [11:54] <JEEB> you'd probably have to code your own thing for the QS part and if you need *nix then I have no idea how good the QS SDK is there [12:01] <Samiarn> is there anyone who can help me please, im trying to use ffmpeg on ubuntu server 12.04 [12:03] <ePirat> hello [12:03] <ePirat> Is ffmpeg capable of handling mvc h264? [12:04] <JEEB> Samiarn, 12.04 comes with an old version of Libav, not FFmpeg. Thus you'll first want to try the avconv binary (support from #libav ), and if that doesn't work you can then try static binaries from FFmpeg [12:04] <JEEB> (available from the downloads) [12:04] <JEEB> ePirat, no -- there is no decoder done and merged yet [12:05] <Samiarn> JEEB incase of ubuntu versions, which do you recommend? [12:05] <Samiarn> or should i use completely different OS ? CentOS perhaps? [12:06] <JEEB> all of the current stable ones have an old Libav, 14.04 will be having a newer one. CentOS will be ancient as well. [12:06] <JEEB> I wouldn't change the OS basically, I'd either use a static binary or build it myself [12:16] <SenseiV183> http://pastebin.com/T2PEiAcK [12:17] <SenseiV183> can someone help me with this pastebin? [12:18] <SenseiV183> I am trying to transcode gopro footage to lossless jpeg2000 [12:18] <SenseiV183> for an intermediate file. [12:20] <SenseiV183> With Wav audio [12:20] <SenseiV183> wrapped in an avi [12:20] <JEEB> that's not wav [12:21] <SenseiV183> I have a hard time finding the format commands [12:21] <SenseiV183> wavpack is what I found [12:21] <JEEB> that's because it's one of the pcm things, wav just contains raw pcm :P [12:21] <SenseiV183> I only found 5 bit pcm lol [12:22] <JEEB> anyways, if you need this for editing and you need something lossless I recommend Ut Video, it's available as VFW and MF components on windows and for QT on OS X [12:22] <relaxed> SenseiV183: you probably want -c [12:22] <relaxed> er, -c:a pcm_s16le [12:22] <SenseiV183> I want to do everything in linux [12:23] <SenseiV183> The souce is 48khz 64bit mp4 [12:23] <JEEB> I don't see how your current selections are any better than what I'm noting [12:24] <JEEB> ffmpeg -i welp.mp4 -c:v utvideo -c:a pcm_s16le out.wav [12:24] <JEEB> uhh [12:24] <JEEB> avi [12:24] <JEEB> :P [12:24] <JEEB> if you want to do it all on lunix, most OSS editors packaged will most probably have very old libavcodec/-format libraries tho [12:25] <JEEB> so if you have such [12:25] <JEEB> you might want to use ffvhuff instead [12:25] <JEEB> of Ut Video [12:25] <JEEB> because that's a very old lossless format [12:25] <SenseiV183> Jeeb is that format good for Blender? [12:25] <SenseiV183> ut video? [12:26] <JEEB> depends on how old the libavcodec/-format libraries linked to it are [12:26] <SenseiV183> probably new. [12:26] <JEEB> if you are guessing you have no idea [12:27] <SenseiV183> Blender is an updated static build [12:27] <JEEB> that still doesn't mean it uses new APIs that come with newer versions [12:27] <JEEB> but feel free to try [12:27] <JEEB> if the clip isn't long [12:27] <JEEB> you can first encode with ut video [12:27] <JEEB> then if that isn't good, you can move to ffvhuff [12:28] <SenseiV183> Most souce files will be 2 gigabytes [12:29] <SenseiV183> I have a dual core but want to make the highest quality video in linux no matter how many days I have to wait for encoding [12:29] <JEEB> basically ffvhuff has been around since 2007 (?) or so, and Ut Video decoder was added in 2011 [12:30] <JEEB> also that last comment of yours has nothing to do with editing footage [12:30] <JEEB> it has everything to do with when you are creating a final non-lossless file for the end users [12:30] <SenseiV183> Are they friendly formats for footage you like to reverse and speeedup affects and compositing lossless friendly? [12:31] <JEEB> ffvhuff and ut video are both intra-only :P [12:31] <SenseiV183> Yes, No B frames. [12:31] <JEEB> ARGH [12:32] <JEEB> yes, you are right that intra-only means there are no bipredicted pictures, but intra-only means that there's only INTRA prediction, aka only prediction within a single picture, not within a GOP (group of pictures), which is called INTER [12:33] <SenseiV183> So what container and file formats and do the ffvhuff (colorspace??) and the ut codec go in? [12:33] <JEEB> also even for editing generally a short GOP (like three or so pictures) is OK, btw. [12:33] <SenseiV183> jeeb I will need to set the gop to 1 -g 1 I noticed makes files read backwards correctly [12:34] <JEEB> well, as I goddamn said [12:34] <JEEB> ffvhuff and ut video are intra only formats [12:34] <JEEB> also ffvhuff and ut video are generally seen in AVI [12:34] <SenseiV183> lol. I was typing before I could read all that came out this end [12:35] <JEEB> colorspace-wise Ut Video supports 4:2:0, 4:2:2 YCbCr and RGB/RGBA [12:35] <JEEB> ffvhuff supports at least 4:2:0 and possibly something else, I don't remember those all :P [12:35] <SenseiV183> I'ts coming from colorspace yuv420p. [12:36] <JEEB> yes, since your goddamn input is main profile H.264, which is 4:2:0 only. You don't have to set anything, unless you specifically want to have the stuff in some other colorspace [12:37] <JEEB> it's a lossless, intra-only format so you really don't have to set much settings at all [12:38] <SenseiV183> makes great sense. I've been up too late. Thank you. I will look in to this info. [12:38] <JEEB> anyways, you can just make a test sample with ffmpeg -i welp.mp4 -c:v utvideo -c:a pcm_s16le out.avi [12:38] <JEEB> and then try loading that up [12:38] <JEEB> if that doesn't work [12:39] <JEEB> then switch to -c:v ffvhuff [12:40] <SenseiV183> JEEB, Thanks a bunch. I sure will. I'm about to set away and leave this Xchat up to look at later. Got to rest. [12:49] <relaxed> SenseiV183: add "-t 30" after the input for a 30 second sample [12:55] <Samiarn> Seems like my ffmpeg / avconv not working.. [12:56] <Samiarn> after typing the command, i only get to see [12:56] <Samiarn> version, Copy right [12:56] <Samiarn> Built on Nov and nothing more, [12:57] <Samiarn> why isnt it responding? [12:58] <JEEB> if you are using the packaged one, I recommend you move towards #libav and pastebin your command and its full output there [13:15] <Jenser> hi there. i am searching for a way to combine two (or more) mpegts files to one new file with correct "gop time code". is there a fast and lossless way to rewrite this timestamps (something with concat ...) [13:18] <SenseiV183> JEEB, -b:a 64k not taking effect. Stream #0:1(eng): Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, mono, s16, 768 kb/s (default) [13:19] <SenseiV183> I will try right now a shot converted clip in blender.... [13:20] <JEEB> I TOLD YOU WHAT KIND OF COMMAND YOU NEEDED [13:20] <JEEB> HOW THE FUCKING HELL DO YOU SET A BIT RATE FOR RAW AUDIO [13:20] <JEEB> sorry for the caps [13:27] <SenseiV183> JEEB, I used the command it worked fine. I tried to add something too it and see what you mean I can't do that. Yeah. I've had my head in this all day and time to call it a night. [13:27] <dannyzb> JEEB: quicksync is much faster than credited .. but thats impractical since I'd need a windows machine for that ( or an uber-complex converter that mixes FFMPEG and QS libraries ) [13:28] <dannyzb> I was talking of transcoder boxes , the specially designed circuits .. are those any good? [13:28] <JEEB> no [13:28] <JEEB> I wouldn't touch those with any of my fingers [13:28] <dannyzb> so at the end of the day , we're stuck with ffmpeg over intel ,ideally? [13:29] <JEEB> also as far as I know haswell QS is as fast as I noted, the less good modes IIRC weren't really faster [13:29] <JEEB> and that's pretty much as fast bearable quality you can get [13:29] <JEEB> (HW encoders generally don't go further than 'bearable') [13:30] <dannyzb> JEEB: from tests i've run , decoding performance is even more important than encoding performance .. and decode->encode is much faster with quicksync due to the saved memory bandwidth [13:30] <JEEB> yes, but that completely depends on what you have there [13:30] <dannyzb> 1080p/720p high-quality [13:30] <dannyzb> those things take A-LOT of time to decode [13:30] <JEEB> which says EXACTLY NOTHING [13:30] <JEEB> about what it is [13:30] <JEEB> if it's something the hardware can decode, sure [13:31] <dannyzb> h264 / avi (probably XVID) [13:31] <JEEB> yeah... [13:31] <JEEB> xvid is MPEG-4 Part 2 and you said H.264 / avi [13:31] <JEEB> gg [13:31] <dannyzb> nope [13:31] <dannyzb> i meant both the options [13:31] <dannyzb> most of the files are MPEG4 [13:31] <dannyzb> others are h264 [13:32] <JEEB> well, yeah -- that says something [13:32] <dannyzb> god knows why people still use that crap format -_- [13:32] <JEEB> generally the H.264 decoder shouldn't be blocking your encoder too bad [13:32] <JEEB> it's generally something else that's blocking [13:32] <JEEB> like resizing or whatever in the middle [13:32] <dannyzb> the bigger the video the longer it takes to transcode ( everything transcodes to h264 720p eventually ) [13:33] <dannyzb> wouldn't that point to the decoding as the slowing factor? [13:34] <JEEB> yes, the more content there is the longer it takes, but that still doesn't change what is the bottleneck [13:35] <dannyzb> in any case that wasn't my main question .. what hardware should i use for a powerful transcoding machine , and stay cost effective ? (high number of processors isn't a problem because i convert many videos at the same time ) [13:36] <JEEB> intel, haswell or ivy, depends on which you can get a better price/speed ratio off of (haswell is generally 5% or so? faster than ivy) [13:37] <dannyzb> I'd probably use Xeon .. so last-prev gen only i guess [13:37] <dannyzb> is xeon inferior to I7 in conversion performance ? (same architecture , both highest end) [13:38] <dannyzb> and how much does memory clock speed affect ffmpeg? [13:38] <JEEB> no idea, I've never had much hardware around myself to test [15:13] <xda_dentex> Hello everyone. [15:15] <xda_dentex> I have a Q. about a couple of FFmpeg version I compiled for Android. They works. The question is on some comp switches I used. [15:15] <xda_dentex> May I? [15:15] <JEEB> feel free [15:15] <JEEB> if it's long, pastebin it [15:15] <xda_dentex> Hi. Thanks. [15:16] <xda_dentex> ok [15:16] <xda_dentex> http://pastebin.com/w8xfCKpx [15:16] <xda_dentex> the two configs: [15:17] <xda_dentex> they are for armva-a and for armv7-a-NEON [15:17] <xda_dentex> they are the same exact lenght as files. [15:17] <xda_dentex> How can it be possible? [15:17] <xda_dentex> if the are compiled differently, I mean [15:23] <xda_dentex> FOUND IT!!! [15:24] <xda_dentex> thanks anyway! [15:24] <xda_dentex> (double "--prefix=" switch, I was overwriting a version with the other one) [15:25] <JEEB> :) [15:25] <xda_dentex> good it took me just half an hour ;) [15:25] <JEEB> sometimes it's simple things like that [15:26] <xda_dentex> kinda new to compilation [15:26] <JEEB> also congratulations on not having completely pants-on-head retarded configure settings [15:26] <xda_dentex> Have a nice day guys! [15:26] <JEEB> although I think -fPIC is enabled by --enable-pic [15:26] <JEEB> and I'm not sure if you want software float unless that's all you get on those things [15:28] <xda_dentex> goodbye. [15:28] <xda_dentex> see U next time [15:29] <xda_dentex> eheh. DuckDuckGo is your friend, in those tasks. [15:29] <xda_dentex> (used to say Google, before) ;) [15:30] <xda_dentex> Anyway I must admit that in my case if mostly a "trial and error" process [15:34] <xda_dentex> makes sense. Thanks. [15:34] <xda_dentex> closing. See U. ;) [16:38] <reloadedc4> Hey guys, i have a bit of an odd/advanced question [16:38] <reloadedc4> anybody on? [16:39] <relaxed> just ask [16:39] <spaam> only if you tell us what kind of special question you have [16:39] <reloadedc4> ok so I'm using ffmpeg to record & transcode a live mjpeg stream from my security webcam [16:40] <reloadedc4> its called programatically when motion is detected on my insteon network [16:40] <reloadedc4> so when a motion sensor is tripped, ffmpeg fires up and starts saving the footage from the webcam [16:40] <reloadedc4> but what i want to do is dynamically control the length of time that ffmpeg records [16:41] <reloadedc4> i can set -t option to 10 seconds, but i would like to somehow dynamically extend that by 10 seconds each time motion is detected [16:41] <reloadedc4> is there a way to increase the value of -t while ffmpeg is running? [16:42] <reloadedc4> (did i explain the question clearly?) [16:42] <spaam> can you get a notification when there is no moment or something like that from the camera ? [16:42] <reloadedc4> yes i can [16:43] <spaam> maybe you can just start record the stream. then send some kind of kill signal to ffmpeg process and stop recording? [16:43] <reloadedc4> the motion sensor fires two messages. 1 when motion is detected and 1 after its been still for X seconds [16:45] <reloadedc4> spaam, i tried to do that first but the problem i ran into was if the kill command is sent too soon after ffmpeg starts, i get a corrupt movie file [16:46] <reloadedc4> not sure why [16:46] <spaam> what kind of signal did you send? [16:46] <reloadedc4> pkill ffmpeg [16:46] <reloadedc4> so 15? [16:46] <reloadedc4> SIGTERM [16:50] <relaxed> reloadedc4: killall -INT ffmpeg [16:50] <relaxed> seems to work [16:50] <reloadedc4> ok, let me give it a shot [16:50] <relaxed> even for .mp4 [16:51] <spaam> kill -INT $(pidof ffmpeg) [16:58] <reloadedc4> hmm, no joy. i end up with a 262 byte file that i can't open [16:58] <reloadedc4> i thought it was going to work [16:58] <reloadedc4> the ffmpeg log shows: Received signal 2: terminating. [16:59] <spaam> can you show us the commandline? [16:59] <reloadedc4> just a sec, ill create a temporary user/pass for the camera [17:02] <reloadedc4> ffmpeg -y -f mjpeg -i "http://temporary:password@25ssrdcam.mooo.com/nphMotionJpeg?Resolution=640x4…" -b:v 1500k -vcodec libx264 /tmp/test.mp4 </dev/null >/dev/null 2>/tmp/ffmpeg.log & [17:03] <relaxed> what is ">/dev/null" doing? [17:04] <reloadedc4> i read that from the ffmpeg site trying to figure out how to get it to run in the background [17:04] <reloadedc4> 2>/tmp/ffmpeg.log makes it send the output to my logfile [17:04] <relaxed> I think only </dev/null is needed [17:05] <reloadedc4> i would show you, but it seems the trac site is down [17:06] <reloadedc4> https://trac.ffmpeg.org/wiki/Using%20FFmpeg%20from%20PHP%20scripts [17:06] <reloadedc4> i think thats the link where i got the example [17:06] <relaxed> works here without >/dev/null [17:07] <reloadedc4> ok [17:08] <reloadedc4> here is my actual program: http://pastebin.com/iweMYeLc [17:08] <reloadedc4> my test.mp4 file is 262 bytes, unreadable [17:11] <reloadedc4> its because of the lag between ffmpeg and the camera. if i change the call and use -t 10 it works fine [17:20] <relaxed> reloadedc4: because ffmpeg is multithreaded I think you need to use killall [17:21] <reloadedc4> relaxed: that's what the script was doing. killall -INT ffmpeg [17:22] <relaxed> you lost me at php [17:24] <reloadedc4> ok, forget the php script [17:24] <reloadedc4> if i just run ffmpeg -y -f mjpeg -i "http://temporary:password@25ssrdcam.mooo.com/nphMotionJpeg?Resolution=640x4…" -b:v 1500k -vcodec libx264 /tmp/test.mp4 </dev/null >/dev/null 2>/tmp/ffmpeg.log & [17:24] <reloadedc4> and then wait 1 second and then run killall -INT ffmpeg [17:24] <reloadedc4> i get a garbage video file [17:25] <relaxed> bash shell? [17:25] <reloadedc4> yes [17:25] <reloadedc4> but if i call ffmpeg with a -t 1 parameter, it works fine. i get a 1 second video file [17:26] <relaxed> remove >/dev/null [17:26] <reloadedc4> ah crap, let me try [17:26] <relaxed> I already told you this [17:27] <reloadedc4> i tried once and then i copied /pasted from the wrong place [17:29] <reloadedc4> ok, made no difference at all [17:32] <relaxed> pastebin the ffmpeg.log [17:35] <relaxed> ffmpeg -y -f mjpeg -i "http://temporary:password@25ssrdcam.mooo.com/nphMotionJpeg?Resolution=640x4…" -b:v 1500k -vcodec libx264 /tmp/test.mp4 </dev/null 2>/tmp/ffmpeg.log & sleep 10; killall -INT ffmpeg [17:36] <reloadedc4> http://pastebin.com/dBrSgFTJ [17:37] <reloadedc4> relaxed, that gives you a useable video file? [17:39] <relaxed> yes, but I'm using a more recent version that you. Can you try this build? http://johnvansickle.com/ffmpeg/ [17:40] <reloadedc4> I'm on OSX, i think ill have to compile from source [17:42] <relaxed> er, can you try it on a local file? [17:44] <reloadedc4> its a timing thing. on a local source file it will probably work fine [17:44] <reloadedc4> i noticed if i run this from a machine thats local to that camera the time it takes to run is 1/2 [17:45] <relaxed> sure it's faster [17:45] <reloadedc4> i think ffmpeg is exiting before it captures any frames [17:45] <reloadedc4> when i run it remotely that is [17:50] <bmhm> Hi. A more ore less quick question. If I try to record from my usb video grabber, ffmpeg stops due to too small frames. Mplayer just continues. How can I enforce this behaviour on ffmpeg? [17:52] <relaxed> reloadedc4: Try this: ffmpeg -y -probesize 100000 -analyzeduration 0 -f mjpeg -i "http://temporary:password@25ssrdcam.mooo.com/nphMotionJpeg?Resolution=640x4…" -b:v 1500k -vcodec libx264 -pix_fmt yuv420p -y out.mp4 </dev/null 2>ff.log & sleep 15; killall -INT ffmpeg [17:52] <bmhm> a similar issue is this: http://ubuntuforums.org/showthread.php?t=2070480 [17:57] <relaxed> reloadedc4: I guess the real problem is $(sleep 15) is the time since ffmpeg was sent to the background [17:58] <relaxed> if this code is running on the machine with the camera you shouldn't have too much lag [18:03] <bmhm> relaxed: can you by chance say sth to my issue? [18:05] <bmhm> relaxed: ok, I'll be returning soon - don't have the exact output right now. thanks. [18:06] <relaxed> bmhm: first make sure you're using a recent version. [18:07] <bmhm> ok, thanks. See you, bye! [18:21] <bornpilot> znf ffmpeg or avonc are they equal in their output? [18:22] <znf> bornpilot, depends on what you mean by equal [18:22] <bornpilot> System resources and quality. [18:22] <bornpilot> that is usage of system resources. [18:23] <znf> I don't think anyone has done a benchmark between the two that is relevant [18:32] <bornpilot> thanks znf [18:54] <TSM> what is the state of play with ffmpeg hardware encoding [19:04] <joecool> still can't build ffmpeg with quvi support on libquvi-0.9.x [19:42] <reloadedc4> hey relaxed, you still on? [19:47] <gabamnml> how can I convert from gif to mp4 and it work in Flash? [19:47] <spaam> aha [19:47] <spaam> bah [19:49] <gabamnml> try -vcodec libx264 but did not work [19:49] <gabamnml> just works in VLC [19:51] <Goles> :D [19:51] <gabamnml> :) [19:53] <znf> gabamnml, you need to specify a frame-rate for .gif's, afaik [19:55] <gabamnml> this is my code http://pastebin.com/KYeKfNwe [20:04] <Goles> fflogger: wouldn't gabamnml need to specify a frame rate? I see nothing wrong with his code [20:17] <llogan> Goles: fflogger is a bot [20:18] <llogan> gabamnml: re-read the message from fflogger [20:19] <SirCmpwn> wiki down? [20:19] <llogan> yes [20:19] <SirCmpwn> :( [20:26] <llogan> SirCmpwn: what did you want to look up? [20:27] <SirCmpwn> I went to archive.org [20:35] <facugaich> Hi! I wanted to know if you guys have any plans for GSoC 2014 [20:37] <llogan> facugaich: yes, we will apply again this year. are you a student? [20:38] <facugaich> llogan: Yeah [20:38] <llogan> we are working on the ideas page, but the server is currently down for maintenance: https://trac.ffmpeg.org/wiki/FFmpegSummerOfCode2014 [20:38] <facugaich> Ah, right, I tried accessing that URL but it wasn't working [20:39] <facugaich> I'll keep an eye on it, thanks [20:40] <llogan> unfortunately it's currently an "orphaned" link so there is probably no cached version anywhere, AFAIK [20:40] <llogan> facugaich: is there something you're interested in particular? [20:43] <facugaich> llogan: Well... I was planning on doing it as a CS project, so I was looking for something with a little bit of academic interest [20:44] <llogan> facugaich: hopefully the server will be back soon. if you have any questions you can ask them in #ffmpeg-devel [20:44] <facugaich> llogan: Got it, thanks! [20:45] <Fusl> can someone tell me if -analyzeduration 0 is useless when reading from pipe:0 with a (pcm_)u8 format? [20:45] <Fusl> i know when i omit -analyzeduration 0 on (lib)mp3(lame) format, it keeps defaulting to 5 seconds but i'm not sure on u8 [20:58] <dbro> when I use ffmpeg with librtmp, is there a way to decouple networking from the encoding/muxing threads? [21:42] <AleXoundOS> Hi. I get lots of "Non-monotonous DTS in output stream" messages when streaming to rtmp (twitch). While these messages appear the stream gets frozen. I use libx264 and aac codecs on the input, convert aac to mp3 and copy video. Output container is flv. How can I fix this? [21:46] <AleXoundOS> forgot, ffmpeg version 2.1.1 Copyright (c) 2000-2013 the FFmpeg developers [21:59] <AleXoundOS> http://pastebin.com/h2TXL1pn [23:20] <Wa4> how can I use a videofilter like crop? [23:20] <Wa4> --vf or --video-filter don't work? [23:21] <Wa4> ffmpeg.exe -i input -vf crop:0,2,0,2/resize:width=720,height=404,method=spline -vcodec libx264 -preset slow -acodec copy output.ts [00:00] --- Wed Feb 5 2014

1 0

ffmpeg-devel.log.20140203
by burek 04 Feb '14

04 Feb '14

[00:42] <cone-977> ffmpeg.git 03Voyager1 07master:9f6f4962fbfd: avformat/utils: dvd still frames read thru libdvdnav ended up in internal lavf buffer [00:42] <cone-977> ffmpeg.git 03Michael Niedermayer 07master:1bc2fa447c22: avformat: use AVPROBE_SCORE_STREAM_RETRY, instead of AVPROBE_SCORE_RETRY - 1 [02:10] <cone-549> ffmpeg.git 03addr-see-the-website(a)aetey.se 07master:8e36fc0c3356: RoQ encoder: support different integer framerates [10:49] <pross-au> does daniel kang still come in here? [10:50] <Rodeo> not sure, but I don't think he's been around much lately? [10:51] <pross-au> trying to unravel the vp8 mt decoder [10:51] <pross-au> thx [10:57] <Rodeo> pross-au: http://git.videolan.org/?p=ffmpeg.git;a=search;s=Daniel+Kang;st=author nothing of his has been pushed for several months, AFAICT [10:58] <Rodeo> don't really know much more about ti, he could still be around, but I have a feeling he may not [11:08] <pross-au> no worries [19:23] <llogan> yet another user trying to send 25 MB file to ffmpeg-user... [21:48] <thardin> there we go [22:42] <thardin> michaelni: 32 KiB is alright for that UL -> WrappingKind table, right? [22:42] <thardin> (adding an MXF entry to the GSoC wiki page) [22:43] <michaelni> thardin, yes, 32kib sounds reasonable [22:45] <thardin> wait a sec [22:45] <thardin> the file plays fine in ffplay [22:46] <thardin> try: http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2776/MXF_DVCAM_not_demuxab… [22:47] <Daemon404> [21:42] < thardin> (adding an MXF entry to the GSoC wiki page) <-- "invent a time machine and prevent mxf from being created" [22:48] <nevcairiel> say you have a time machine and you can remove one format from history, exactly one, why would you choose mxf? :d [22:48] <michaelni> Daemon404, iam sorry but gsoc is about software development only [22:49] <thardin> lol [22:49] <michaelni> about the sample it plays but does it play completely ? wasnt it longer? [22:49] <michaelni> but i might misremember [22:50] <thardin> header says it's 51.8 econds [22:50] <thardin> seems to play fine for that long [22:50] <michaelni> hmm [22:50] <michaelni> here it stops at 4sec [22:54] <thardin> oops, "ffplay" not "./ffplay" [22:54] <thardin> apparently it works in avplay [22:58] <thardin> wiki updated [22:58] <thardin> https://trac.ffmpeg.org/wiki/FFmpegSummerOfCode2014 [23:31] <BBB> ubitux: pokey [00:00] --- Tue Feb 4 2014

1 0

ffmpeg.log.20140203
by burek 04 Feb '14

04 Feb '14

[02:08] <DopeLabs> a weeee [07:21] <anshul> Hi I am getting en error that my nb_sample are greater then frame size, what value should i set the nb_samples or what is this nb_sample and how is it related to frame size? [07:57] <anshul> if I am transcoding audio is it compulsory to use fifo , is there any way other then using fifo [08:05] <anshul> hey guys does any one know how nb_sample_size and frame size related [10:30] <anshul> why we select 264 and aac codec by default in mp4 and mpeg1 and mp2 for ts [10:51] <Mavrik> mornin [22:58] <bornpilot> So, I have a question about using ffmpeg to live stream to youtube. I have a DSLR connected via BMD Intensity Pro using Ubuntu for the OS. I have compiled ffmpeg to use libmp3lame, libfdk_acc, libx264. I am using bmdtools and piping that to ffmpeg and my ffmpeg string is as such ffmpeg -i - -c:v libx264 -preset fast -pix_fmt yuv420p -g 60 -r 30 -bufsize 64k -c:a libmp3lame -ar 12050 -ac 0 -f flv rtmp:// [22:59] <bornpilot> I can get it to youtube however my bit rate is about 500 kbs so the video is sub hd. Is there anything that I can do with ffmpeg to achieve a higher bit rate for HD? [23:01] <bornpilot> I did change the audio codec from libfdk_aac to libmp3lame and lower the sample rate, this helped some. [23:08] <znf> bornpilot, -b 1000k -minrate 1000k -maxrate 1000k ? [23:08] <JEEBsv> just out of interest [23:08] <znf> or, just set -b [23:08] <JEEBsv> why -minrate [23:08] <znf> no reason [23:09] <JEEBsv> you need -bufsize and -maxrate to keep your stream within VBV boundaries [23:09] <JEEBsv> -minrate is generally harmful [23:10] <znf> (how would I get access to creating live events in youtube, btw?) [23:11] <JEEBsv> I think their documentation states the needed things for that as far as an account is concerned [23:11] <znf> tells me I don't have permission to view that page :-/ [23:13] <bornpilot> Let me go try that. [23:15] <znf> bornpilot, what video size is bmdtools spitting out? [23:16] <bornpilot> 720p [23:18] <Mavrik> bornpilot, you're never really setting desired output resolution and bitrate are you? [23:18] <znf> Then I'd go with -b 2500k -maxrate 4000k -bufsize 4000k [23:18] <znf> and what Mavrik said [23:20] <bornpilot> znf in that case would could there be an inherited minrate? [23:20] <znf> as less as it can do, I guess [23:20] <znf> but like JEEBsv said, you don't really want a minrate [23:21] <bornpilot> Mavrik what is the setting for output resolution? [23:21] Action: Mavrik gets really annoyed when people don't even bother reading the doc. [23:22] <znf> well, ffmpeg's docs aren't exactly a lightread :P [23:23] <Mavrik> around here people who read documents for other people are called notaries :P [23:23] <znf> anyway, look at the -s flag [23:23] <bornpilot> Understood. [23:24] <znf> Mavrik, and around here a notary makes more money than most people :P [23:24] <bornpilot> setting the bitrate worked [23:24] <bornpilot> thanks! [00:00] --- Tue Feb 4 2014

1 0