[00:09] <ubitux> any reason we don't support dct for nbits < 4? [00:10] <ubitux> it's not really problematic, but nbits=3 might be relevant in some situations [00:12] <durandal_1707> michaelni: why FF_API_OLD_AVOPTIONS is still keept? [00:49] <michaelni> durandal_1707, someone could check if any user apps still use them [00:54] <bcoudurier> what's the reason for allowing broken aac frames in mp4 and flv ? [00:56] <cone-308> ffmpeg.git 03Michael Niedermayer 07master:59a3b6b75148: avcodec_string: remove the "(hq)" listing [00:56] <cone-308> ffmpeg.git 03Michael Niedermayer 07master:24bb01f03865: avcodec_string: Print the used codec if it differs from the codec_id name. [00:58] <durandal_1707> bcoudurier: what creates broken aac frames? [01:02] <bcoudurier> that's a good question [01:05] <bcoudurier> Write broken aac frames to mov files instead of skipping them. (from carl eugen) [01:08] <durandal_1707> well that can happen virtually with almost any muxer [01:09] <durandal_1707> michaelni: so c99-to-c89 link is dead and still not resurected? [01:14] <ubitux> http://ubitux.fr/pub/pics/_dctdn-a-bit-better.png [01:14] <ubitux> now it's ugly AND slow [01:15] <durandal_1707> i like libav commits that "fix" something and breaks valid files [01:24] <michaelni> j-b, "<durandal_1707> michaelni: so c99-to-c89 link is dead and still not resurected?" [01:34] <j-b> michaelni: will come back, after the crash is fixed [01:38] <cone-308> ffmpeg.git 03Paul B Mahol 07master:7becddd5f38d: doc/filters: remove non-existent ft_load_flags entry [01:42] <durandal_1707> who added negate_alpha option to negate? [01:46] <cone-308> ffmpeg.git 03Paul B Mahol 07master:785eb5fc57e0: lavfi/negate: unbreak negate alpha [01:51] <durandal_1707> the transpose doc still mention removed [4-7] range [01:53] <bcoudurier> OMG, hq gone [01:53] <bcoudurier> what's legacy disappearing [01:53] <durandal_1707> that silly thing in log.... [01:54] <durandal_1707> it can be reverted, if some serious thing depend on it.... [09:12] <highgod> Hi, all, is there any tools than can make the code style the some as the community? thanks [10:33] <ubitux> highgod: uncrustify eventually [11:40] <cone-490> ffmpeg.git 03Diego Biurrun 07master:7c00e9d8aed8: x86: ac3dsp: Remove 3dnow version of ff_ac3_extract_exponents [11:40] <cone-490> ffmpeg.git 03Michael Niedermayer 07master:3fa6c992d9c3: Merge remote-tracking branch 'qatar/master' [11:44] <highgod> thanks [12:40] <burek> is there anyone competent to write a wiki article on "constant" bitrate encoding (probably using libx264), which would describe the proper use of -minrate, -maxrate, -bufsize and -b:v ? [12:40] <burek> competent in the sense of understanding those options [12:41] <burek> because a lot of people are trying to use ffmpeg to produce a media stream, constraining the output bitrate to some predefined bandwidth range [12:41] <nevcairiel> i'm sure there are such examples for x264 specifically, can easily recycle this for ffmpeg usage [12:42] <kierank> there aren't any really good examples. people don't understand vbv anyway [12:43] <kierank> they stick it into a crappy stream analyser and blame x264 for "violating the bitrate" [12:59] <JEEB> yes, those cases are always "fun" >_> [13:05] <ubitux> https://en.wikipedia.org/wiki/Discrete_cosine_transform#DCT-II "Some authors further multiply the X0 term by 1/2" [13:05] <ubitux> isn't it 1/N ? [13:07] <nevcairiel> 2 is a value of N [13:08] <nevcairiel> (i have no idea) [13:08] <ubitux> :( [13:09] <ubitux> i'm just comparing the ff dct results with another implementation, and it seems i need to scale the DC by 1/N and not 1/2 [13:44] <burek> is there any place that describes what really happens when someone does this: ffmpeg -i input http://<ip_of_ffserver_machine>:8090/feed1.ffm [13:45] <burek> the thing that is interesting to me the most is if the stream between ffmpeg-ffserver is encoded and using which codec [13:46] <burek> the way i understood it so far is that ffserver tells ffmpeg how to encode the stream (consulting its ffserver.conf) and later on ffserver just re-broadcasts that stream [13:46] <burek> is my assumption right? [13:49] <burek> for example, is it the same if we type this: ffmpeg -i input http://ffserver:8090/feed1.ffm [13:49] <burek> and this: ffmpeg -i input -c copy http://ffserver:8090/feed1.ffm [14:12] <durandal_1707> ubitux: gifenc reports leaks [14:23] <durandal_1707> https://github.com/xbmc/xbmc/tree/master/lib/ffmpeg/patches [14:27] <xlinkz0> why is the Y linesize only 2 times bigger and U and V ? [14:27] <xlinkz0> isn't there 4 times as many Y values? [14:28] <clkao> win 48 [14:28] <durandal_1707> xlinkz0: there are subsamples yuvs [14:29] <durandal_1707> *subsampled [14:30] <xlinkz0> but are all the planes on contiguous memory? [14:30] <Skyler_> xlinkz0: YUV 4:2:0 is subsampled vertically, too [14:30] <xlinkz0> i don't know these terms :( [14:31] <durandal_1707> xlinkz0: planar yuv, liky yuv420p have y, u and v in separate array [14:31] <xlinkz0> and it's not necessary that the arrays are one after the other in memory right? [14:31] <Skyler_> In 4:2:0, U and V have half as many columns and half as many rows. [14:32] <Skyler_> Therefore, the linesize is typically around half. [14:32] <Skyler_> The width is half. [14:32] <Skyler_> The height is half. [14:32] <xlinkz0> ah [14:32] <Skyler_> 1/2 * 1/2 = 1/4 [14:32] <xlinkz0> thanks ! [14:33] <xlinkz0> so i read AVFrame->height lines from Y and AVFrame->height/2 lines from U and V [14:33] <xlinkz0> right? [14:33] <durandal_1707> xlinkz0: there is bunch of existent usage in source code [14:34] <xlinkz0> i'm not sure where i should be looking [14:41] <cone-490> ffmpeg.git 03Paul B Mahol 07master:cc5c15595930: astats filter [14:44] <xlinkz0> omg i think i get it [14:44] <xlinkz0> but i need to know, does ffmpeg guarantee that the 4 planar vectors are contiguos? that is, after the Y plane comes U and then V [14:45] <xlinkz0> i need to know this because i want to make a hash of the pixel data [14:45] <xlinkz0> 3 vectors * [14:46] <durandal_1707> no it, can have loops [14:46] <durandal_1707> even every stride have loops [14:46] <durandal_1707> it for SIMD [14:46] <durandal_1707> nothing is contiguous except one image row [14:47] <durandal_1707> even for interleaved yuvs [14:47] <durandal_1707> so they may be contiguous - but that is very special case.... [14:48] <xlinkz0> thank you [15:08] <xlinkz0> Skyler_: could you please take a quick look at this and tell me if i've done it right? http://codepad.org/atlFd7IZ [15:09] <xlinkz0> if all the pixel data gets in the hahs [15:09] <xlinkz0> hash [15:30] <xlinkz0> when anyone has a minute please check it and leave me a message [15:31] <xlinkz0> it seems to work but.. this stuff is a little too arcane to me to have full confidence in it [16:31] <cone-490> ffmpeg.git 03Michael Niedermayer 07master:1a392fc550fd: ffv1: Store a flag in the global header that indicates if all frames are keyframes [16:31] <cone-490> ffmpeg.git 03Michael Niedermayer 07master:ff0b4c08ca0c: ffv1dec: add code to support frame threading with gop=1 ffv1 [16:36] <durandal_1707> michaelni: why you readded log to ffv1dec, isn't redudant now, eg. being displayed twice? [16:38] <michaelni> copy & paste error [16:46] <cone-490> ffmpeg.git 03Michael Niedermayer 07master:d4868a960bf8: ffv1dec: remove redundant error message. [17:19] <ubitux> durandal_1707: mmh indeed [17:19] <ubitux> i'll look in a moment [17:23] <j-b> 1m [17:23] <j-b> oops [17:32] <nevcairiel> ubitux: how does that denoiser compare in quality/behavior to the denoiser we already have? [17:33] <nevcairiel> i realize dct will probably look differently, just wondering "how" :) [17:33] <ubitux> except that it's slower i don't really know :) [17:36] <ubitux> nevcairiel: i pushed the filter in a branch on my github if you want to experiment [17:39] <ubitux> nevcairiel: i'd say this filter is mainly a PoC [17:39] <ubitux> also, the expression thing is kinda cool to experiment [17:39] <ubitux> if you want to have a custom dct coeff filtering [18:00] <ubitux> http://lists.libav.org/pipermail/libav-devel/2013-April/046042.html wtf [18:04] <iive> DonDiego... fixing warnings with bugs, since 2003 (just made that up) [18:15] <zimbatm> hi, i'm trying to debug why ffmpeg is producing moov headers that are twice as big than after processing into MP4Box [18:15] <zimbatm> is this the right channel to ask ? [18:16] <zimbatm> https://gist.github.com/zimbatm/5473549 [18:16] <ubitux> you can check if it uses cmov [18:16] <ubitux> also possibly compressing some sample tables [18:17] <ubitux> it's the right channel if you're willing to discuss the code [18:17] <ubitux> otherwise, maybe a bug report as enhancement/wish or something [18:20] <zimbatm> thanks for the pointers [18:20] <zimbatm> it's possibly a regression in ffmpeg but i have yet to point to the exact spot [18:21] <zimbatm> i'll be back later if i have more details :) [18:23] <ubitux> isn't mp4box dropping the samples when the video is not available? [18:23] <ubitux> your sample indicates a duration of 2h+ [18:24] <ubitux> while there is just a few seconds [18:24] <ubitux> and the header describes the whole presentation of 2h [18:24] <ubitux> possibly they are not stripped by ffmpeg because the sample is small [18:24] <ubitux> (sounds strange though) [18:26] <zimbatm> the 2h+ comes from the original file that I truncated using dd actually [18:27] <zimbatm> it's the same behavior on the 600MB file but I wanted to speed up iterations [18:27] <ubitux> ffmpeg has a lot more stco and stsc samples [18:27] <zimbatm> it seems like ffmpeg generates more stsc samples [18:28] <zimbatm> yeah [18:28] <zimbatm> in the 2h+ video file it makes a 8MB table which is quite bad when people try to stream the video :p [18:31] <ubitux> http://pastie.org/7729610 [18:31] <ubitux> looks like it's very ineffective [18:31] <ubitux> i wonder how mp4box is able to figure out it can simplify this [18:32] <ubitux> well i don't have time to debug more [18:32] <ubitux> have fun [18:32] <zimbatm> ubitux: what's the tool you used for that output ? [18:32] <ubitux> custom tool [18:32] <ubitux> which i can't share unfortunately [18:33] <zimbatm> too bad [18:33] <zimbatm> thanks for the help, i'm going to go back in time [18:33] <zimbatm> i think older versions of ffmpeg did it differently [18:47] <ubitux> iive: a v2 of that patch, almost equaly broken, just got oked :) [18:47] <iive> \o/ [18:49] <cone-490> ffmpeg.git 03Stefano Sabatini 07master:efff09418dd5: doc/filters: fix grammar for removelogo filter doc sentence [18:49] <cone-490> ffmpeg.git 03Stefano Sabatini 07master:1e4f75debdc3: doc/filters: readjust w/h option descriptions [18:49] <nevcairiel> the second patch at least doesnt break the code [18:49] <nevcairiel> but its still terrible [18:50] <ubitux> nevcairiel: it doesn't behave the same [18:50] <durandal_1707> saste: transpose doc still list removed 4-7 [18:51] <nevcairiel> that function is trivial and read-only, calling it does no harm (except possibly some minor speed loss), but the outcome should be the same [18:52] <saste> uh why were they removed? [18:52] <durandal_1707> in evil merge [19:06] <durandal_1707> how do you find people new active e-mail address? [19:14] <burek> durandal_1707 what do you mean? [19:16] <durandal_1707> i want contact someone, send e-mail to only address i have but got no reply [19:18] <burek> oh i see, you assume the person has changed its e-mail address, and you want to find his/her new e-mail addr? [19:19] <burek> usually when they change their e-mail, they setup some kind of a forwarder, so it's pretty much possible that the person got your mail, but didn't reply to it (yet) :) [19:20] <burek> btw, if it's gmail, try searching on google+ [19:21] <burek> http://findpeopleonplus.com/ [19:23] <zimbatm> do you guys have any tricks to speed up ffmpeg bisects ? [19:24] <zimbatm> each step I do; make distclean; ./configure... ; make ; ./ffmpeg sample... + test [19:25] <durandal_1707> why you do bisect? [19:26] <zimbatm> i'm trying to find when ffmpeg started to bloat moov headers in mp4s [19:27] <zimbatm> at f821f98126595002c8cb7a5f17521908d746dc8a my sample gives me a 4209 header [19:27] <zimbatm> on HEAD it's around 6311 [19:28] <zimbatm> MP4Box -inter 500 gives me 3775 [19:29] <zimbatm> but maybe i'm looking at the wrong way to speed up streaming starts over http [19:31] <ubitux> zimbatm: to speed up: ccache, bisecting only libavformat/movenc.c, and disable a lot of things in the configure [19:34] <zimbatm> nice, i didn't know you could bisect just a path :) [19:35] <ubitux> if you're motivated you can also write a script to say yes/no [19:35] <ubitux> and let it run [19:42] <saste> more boring patches [19:42] <saste> (which noone is going to review?) [19:52] <durandal_1707> michaelni: avcodec context in parsers is not print with logs [20:01] <durandal_1707> oh delay & reverb not in lavfi :(( [20:37] <cone-490> ffmpeg.git 03Stefano Sabatini 07master:d33c77b14aec: lavfi/transpose: restore validity of values in range 4-7 [20:37] <cone-490> ffmpeg.git 03Stefano Sabatini 07master:028c73358a1e: lavfi/transpose: reindent constants [20:37] <cone-490> ffmpeg.git 03Stefano Sabatini 07master:9f3d873f5f98: doc/filters: update/extend transpose filter documentation [20:37] <cone-490> ffmpeg.git 03Stefano Sabatini 07master:1c1a2d131942: lavu/mem: remove redundant comment from av_dynarray_add() [20:56] <durandal_1707> there is no way to edit chapters? [21:22] <durandal_1707> saste: why is mp=tinterlace still alive? [21:48] <saste> durandal_1707, becnhmark to show? [21:50] <durandal_1707> benchmark showed that difference is irrelevant [21:51] <saste> durandal_1707, can you show benchmark on *your* machine? [21:51] <saste> I don't trust mine anymore [21:52] <saste> also waiting an explicit reply from michaelni, since he vetoed removal previously [21:53] <ubitux> seriously who care [21:53] <ubitux> just drop it :p [21:54] <saste> i'll drop in a day [21:55] <durandal11707> saste: what modes where slow? [21:55] <saste> durandal11707, check the benchmark output [21:55] <saste> they seem mostly equivalent [21:56] <durandal11707> do you seriously consider i will waste my time on parsing that numbers? [21:56] <durandal11707> make graphs next time.... [21:56] <durandal11707> like on phoronix [21:57] <ubitux> yes, please waste 1hour making graph to save 1 minute on durandal11707's time :) [21:57] <saste> durandal11707, do you seriously consider i will waste my time on creating a graph from those numbers? [21:58] <ubitux> we don't bikeshed that much, but when we do it's for a long time, and on the most absurd things :D [21:59] <durandal11707> ubitux: it can be automated... [21:59] <ubitux> it's called a moto [21:59] <saste> my favourite: third person vs. impersonal form in doxy [22:01] <durandal11707> so nobody remembers what modes where always slover and for what % percentage? [22:02] <saste> durandal11707, really how hard is to look and compare 5 number pairs? [22:02] <saste> also the result was inconsistent [22:02] <durandal11707> 2, 3 and 4 [22:02] <ubitux> durandal11707: for i in 0 1 2 3 4; do for f in mp=tinterlace tinterlace; do filter="$f=$i"; echo "$filter:"; ./ffmpeg -v 0 -f lavfi -i "testsrc=d=200,format=yuv420p,$filter,setpts=nan" -f null - -benchmark; done; echo; done [22:02] <saste> ubitux got tinterlace always faster than mp=tinterlace [22:03] <ubitux> increase d if necessary [22:03] <saste> i had inconsistent results [22:03] <saste> but then my machine is not much reliable [22:03] <saste> (the result may depend on order of execution) [22:03] <ubitux> i can redo the test with a longer duration [22:03] <durandal11707> what about start/stop counters? [22:04] <saste> durandal11707, see the thread [22:04] <saste> from my previous tests mp=tinterlace is always faster [22:04] <saste> but then it's not a valid tests, since that doesn't account for the wrapping code [22:05] <saste> i already wrote about it ad nauseam [22:05] <durandal11707> well you said that tinterlace call extra code, mp=tinterlace doesn't [22:05] <durandal11707> field merging/copying [22:06] <saste> durandal11707, if you want to help, run the test and post the benchmarks [22:06] <saste> it will take ~1 minutes [22:08] <ubitux> new bench results: http://pastie.org/7730361 [22:08] <durandal11707> i'm on really slow cpu here [22:09] <durandal11707> celeron m, (i think its SSE2 is useless) [22:14] <durandal11707> i just run d=20 test, and tinterlace was always faster [22:14] <durandal11707> d=500 eat bunch of mem here for mp=tinterlace for some reason [22:15] <durandal11707> but benchmark may be flawed [22:16] <durandal11707> ok, i run tinterlace first, and results are same [22:17] <saste> i think we can safely assume that tinterlace is at least equivalent, or faster [22:18] <saste> michaelni, ^^ [22:20] <durandal11707> as i increase d, mp=tinterlace becomes more memory hungry [22:20] <durandal11707> and reported value have nothing to do with reality [22:21] <durandal11707> *shit, it makes machine sloooow [22:22] <durandal11707> it reported 6.652 vs native one that is 8.785, which is strange considering that it used swap a lot [22:28] <michaelni> saste, if ours is equally fast or faster then droping the other is fine of course [22:29] <durandal11707> why is black stuff aligned to 1? [22:33] <durandal11707> so why mp=tinterlace use so much of memory? [22:33] <durandal11707> perhaps its sole reason why its sometimes faster [22:38] <saste> durandal11707, i think mp has a problem since evil merge [22:38] <saste> there was some discussion in a recent ticket [22:40] <durandal11707> saste: what about this output framerate patch for tinterlace? [23:51] <zimbatm> ubitux: do you mind taking a look at this video with your personal tool ? http://ffmpeg-debug.s3.amazonaws.com/big-header-video-old.mp4 [23:52] <ubitux> what do you want to know? [23:52] <zimbatm> the bisect points around 0a593de38aa02d752eb44cfbe2d6cd4595a8c059 but it's skipped [23:52] <zimbatm> i would like to know if it's also inefficient like you pointed out before [23:53] <ubitux> in that sample you have 1 stsc [23:53] <ubitux> what do you want me to tell you? [23:53] <zimbatm> sorry i'm not 100% confident of what I'm doing [23:53] <ubitux> http://pastie.org/7730666 [23:53] <zimbatm> that one shows a smaller moov header from my bisect [23:54] <zimbatm> but it ends on a series of skipped bisects and one of them is when you guys changed the default preset to medium [23:54] <zimbatm> so i'll have to rerun with -vcodec copy i guess [23:55] <zimbatm> this is the result of the bisect: https://gist.github.com/zimbatm/5473549#file-gistfile1-txt [23:56] <zimbatm> the moov size varies between 4187 and 6309 [23:59] <zimbatm> gonna keep hacking away, hoping that perseverence compensates the lack of knowledge :p [00:00] --- Sun Apr 28 2013