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

[burek]

[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