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

[burek]

[00:04] <durandal_1707> michaelni: cdx/cdy is subsampling thing?
[00:23] <durandal_1707> michaelni: if i encode testsrc to j2c with imagemagick's convert and decode it with ffmpeg's jpeg2000 i get strange gradients
[00:23] <durandal_1707> jasper/display shows them fine
[00:26] <durandal_1707> similar happens with native jpeg2000 encoder
[00:27] <durandal_1707> always using rgb24 format ^
[00:33] <durandal_1707> jpeg2000 encoder writes invalid yuv444p
[00:33] <durandal_1707> because correct way to specify colorspace is via jp2 box
[00:34] <durandal_1707> which jpeg2000dec does not parse at all
[00:59] <cone-389> ffmpeg.git 03Paul B Mahol 07master:d5f7f1fef157: audio frame multi-threaded decoding
[00:59] <cone-389> ffmpeg.git 03Paul B Mahol 07master:d97044640c07: takdec: frame multi-threading support
[00:59] <cone-389> ffmpeg.git 03Paul B Mahol 07master:9300de0409d5: flacdec: frame multi-threading support
[00:59] <cone-389> ffmpeg.git 03Paul B Mahol 07master:495db0e3b097: ttadec: frame multi-threading support
[00:59] <cone-389> ffmpeg.git 03Paul B Mahol 07master:9684d7f1a226: wavpack: frame multi-threading support
[00:59] <cone-389> ffmpeg.git 03Paul B Mahol 07master:b28851a1d688: alac: frame multi-threading support
[01:28] <durandal_1707> michaelni: lol, actually return stuff i could copy paste from frame_thread_encoder.c
[01:29] <ubitux> durandal_1707: you should add a Changelog entry for audio multithreading
[01:29] <durandal_1707> really? its not that important...
[01:30] <durandal_1707> have you actually tried it, does it actually improves decoding speed?
[01:30] <ubitux> it looks important ;)
[01:30] <ubitux> no i didn't :p
[01:30] <durandal_1707> you should
[01:30] <durandal_1707> before i/someone else add it to Changelog, its better to to make sure its faster and not slower....
[01:31] <ubitux> looks slower here
[01:31] <ubitux> :))
[01:31] <ubitux> bench: utime=2.803s
[01:31] <ubitux> bench: maxrss=36200kB
[01:32] <ubitux> auto threading:
[01:32] <ubitux> bench: utime=5.373s
[01:32] <ubitux> bench: maxrss=37196kB
[01:32] <ubitux> :(
[01:32] <ubitux> (flac decoding)
[01:32] <durandal_1707> with -threads 0 ?
[01:32] <ubitux> yes
[01:32] <ubitux> 4.4s with -threads 10
[01:33] <ubitux> threads 1 ’ 2.8
[01:33] <ubitux> (aka no thread i suppose)
[01:34] <ubitux> durandal_1707: what have you done :(
[01:35] <durandal_1707> that's with short sample. or same happens with long ones?
[01:39] <ubitux> durandal_1707: 14 vs 19s
[01:39] <ubitux> 19s being -threads 0
[01:39] <ubitux> (sample duration 1h26
[01:39] <ubitux> )
[01:40] <ubitux> (less than 14s actually)
[01:42] <durandal_1707> difference is always that big, even for smaller files?
[01:44] <ubitux> smaller file: 0.8 vs 0.5
[01:44] <ubitux> but it's weird because it *looks* faster to me
[01:44] <ubitux> maybe that bench is for an average per thread
[01:44] <ubitux> i should use time
[01:45] <ubitux> ah indeed that's actually much better haha
[01:45] <durandal_1707> well for sure there is overhead, and it may be most obvious for flac
[01:45] <ubitux> ./ffmpeg -v 0 -threads 0 -i totoro.flac -f null -  19.69s user 0.49s system 470% cpu 4.290 total
[01:45] <ubitux> ./ffmpeg -v 0 -threads 1 -i totoro.flac -f null -  13.58s user 0.22s system 99% cpu 13.915 total
[01:45] <ubitux> so it's ok :)
[01:45] <ubitux> -benchmark was *not* a good idea
[01:46] <durandal_1707> i was very close to push revert button
[01:46] <ubitux> for small files 0.614 ’ 0.248
[01:46] <ubitux> which is much better as well
[01:46] <ubitux> so you can add a Changelog entry ;)
[01:47] <durandal_1707> now i need to do same for encoders
[01:47] <ubitux> so, good job, and sorry for the fright ;)
[01:49] <ubitux> durandal_1707: wanna bet on the helgrind report size increase? :)
[02:04] <ubitux> durandal_1707: didn't you wanted some bench for threading in filters as well btw?
[02:06] <durandal_1707> yes, looks like noise one did nothing
[02:07] <ubitux> durandal_1707: how can i be sure the threading is enabled?
[02:07] <durandal_1707> you could also try blend, normal and with all expressions
[02:08] <durandal_1707> try with filter=threads=X:... or edit avfiltergraph.c or send patch
[02:09] <ubitux> [Parsed_noise_0 @ 0x32f4b00] Option 'threads' not found
[02:09] <ubitux> :(
[02:18] <ubitux> next release will be all about filters, heh
[02:18] <ubitux> more than 30 matches for "filter" in the version <next>
[02:36] <michaelni> durandal_1707, ffmpeg -i tickets//1617/flac%2Btheora.ogg -f null
[02:36] <michaelni> Assertion s->max_blocksize failed at libavcodec/flacdec.c:132
[02:37] <michaelni> doesnt happen with -threads:a 1
[02:47] <cone-389> ffmpeg.git 03Michael Niedermayer 07master:c59ce1c98e5f: get_qcc: Check compno
[03:01] <llogan> taking bets that he will re-open ticket.
[03:04] <durandal_1707> michaelni: fixed
[03:08] <cone-389> ffmpeg.git 03Paul B Mahol 07master:a28f4fd1ea45: flacdec: don't call allocate_buffers() in init_thread_copy() when s->max_blocksize is 0
[03:14] <Plorkyeran_> how shocking
[03:17] <durandal_1707> lol, where is admin!!!!!
[03:18] <ubitux> haha
[03:19] <ubitux> wtf :')
[03:26] <llogan> i'll let carl take care of him now.
[03:36] <cone-389> ffmpeg.git 03Michael Niedermayer 07master:c51654fbc023: jpeg2000dec: Support 4 tile parts
[15:42] <cone-101> ffmpeg.git 03Michael Niedermayer 07master:c49d94487c61: jpeg2000dec: Use the matching coding style struct for transform selection
[15:44] <durandal_1707> saste: what's better?
[15:44] <saste> durandal_1707, my gut feeling is that i should avoid nesting
[15:45] <saste> but i'm not yet sure
[15:45] <saste> durandal_1707, what do you need chapters for?
[15:45] <saste> having a use case may help my decision about the design
[15:47] <durandal_1707> i just didn't like ffprobe ignoring chapters
[16:03] <michaelni> anyone wants to review the mips / fixed point patches ?
[16:11] <durandal_1707> why was #2644 removed?
[16:11] <ubitux> no more lulz :(
[16:33] <cone-101> ffmpeg.git 03Michael Niedermayer 07master:21d0f75f29ca: jpeg2000dec: check that we have enough components for MCT
[16:51] <cone-101> ffmpeg.git 03Stefano Sabatini 07master:4da5402256cf: ffprobe: show chapter and chapter metadata information
[16:55] <wm4> ubitux: if you really intend to have only one format in libavfilter for subtitles, how do you want to handle image subs?
[16:57] <av500> libaa?
[17:00] <durandal_1707> libav500
[17:01] <av500> +1
[17:02] <ubitux> wm4: just like AVSubtitle?
[17:03] <wm4> well, it'd probably have to be AVFrame
[17:03] <ubitux> you think it's relevant to merge AVSubtitles into AVFrame?
[17:03] <wm4> dunno
[17:03] <saste> why duration is not available in matroska? ticket #2642
[17:04] <wm4> it seems to be the central structure for filtered data in lavfi
[17:05] <durandal_1707> saste: there is global duration and per stream duration
[17:05] <ubitux> wm4: well yeah i guess it could be done like this but it will require to add a bunch of fields to AVFrame
[17:05] <saste> i'm referring to stream duration, as reported
[17:05] <ubitux> wm4: also, the way subtitles are handled is quite different from a/v frames imo
[17:05] <durandal_1707> just put it into data[X]
[17:06] <durandal_1707> saste: the reported duration is one from container
[17:07] <durandal_1707> if track duration is stored in matroska....
[17:07] <saste> durandal_1707, I see a default_duration field in MatroskaTrack
[17:08] <saste> but I don't know the Matroska spec and our implementation enough to say if we should export that information
[17:09] <durandal_1707> try it, you shold also set stream time_base
[17:09] <nevcairiel> what duration is missing?
[17:09] <nevcairiel> default_duration is the per-frame duration, if its not written explicitly for a frame
[17:09] <JEEB> yup
[17:09] <nevcairiel> and the demuxer should use it like that
[17:10] <nevcairiel> and does
[17:11] <durandal_1707> so matroska doesn't store stream/track duration and/or nb_frames?
[17:11] <nevcairiel> it only has a overall file duration
[17:11] <saste> if that's the case the ticket should be closed
[17:13] <nevcairiel> which ticket is that?
[17:14] <saste> nevcairiel, https://ffmpeg.org/trac/ffmpeg/ticket/2642
[17:15] <nevcairiel> yeah such information is not in the format
[18:16] <cone-101> ffmpeg.git 03James Almer 07master:b06717ef4096: APIchanges: Add missing entry for SHA-2 512
[19:37] <cone-101> ffmpeg.git 03Paul B Mahol 07master:27d3d61343ee: lavfi/framestep: add timeline support
[19:37] <cone-101> ffmpeg.git 03Paul B Mahol 07master:7d01533371aa: lavfi/framestep: cosmetics: reindent AVFilter
[19:39] <durandal_1707> does somene wants to write encoder for me?
[19:45] <saste> durandal_1707, what encoder?
[19:47] <cone-101> ffmpeg.git 03Paul B Mahol 07master:355423886352: lavfi/il: add timeline support
[19:51] <durandal_1707> saste: sonic
[19:56] <Daemon404> we had a sonic encoder -- sometimes it would compress to a larger filesize than the source
[19:56] <Daemon404> :>
[19:57] <saste> Daemon404, sometimes or always?
[19:57] <Daemon404> cant remember :P
[19:57] <Daemon404> it was still lolz tho
[19:57] <saste> durandal_1707, why do you want it?
[19:57] <gnafu> The memory exceeded the size of the original memory, so he can't remember.
[20:06] <durandal_1707> its pointless to have it in codebase
[20:07] <durandal_1707> it's rotting and broken since forever
[20:07] Action: gnafu wonders if a new encoder would meet the same fate.
[20:08] <Daemon404> youll notice libav removed it
[20:08] <Daemon404> because its fucking useless
[20:08] <Daemon404> in every sense of the word
[20:08] Action: gnafu waits for someone to link to no-fate.jpg.
[20:13] <durandal_1707> another thing that is rotting and seems nobody give a fuck (no its not libmpcodecs) is v4l
[20:13] <ubitux> it's not enabled
[20:13] <durandal_1707> because it does not work
[20:13] <Daemon404> didnt luca do a bunch of v4l2 stuff
[20:13] <Daemon404> like last year
[20:14] <ubitux> v4l2 is pretty ok
[20:14] <ubitux> we're talking about the legacy v4l
[20:14] <gnafu> Do people use that?
[20:14] <ubitux> ATM they can't, it's disabled
[20:15] <ubitux> i'm not sure at which kernel v4l2 was introduced
[20:15] <gnafu> Right, but I mean even outside of ffmpeg.  Does anyone use legacy v4l anymore?
[20:15] <ubitux> i don't know if it's relevant to keep the v4l code
[20:15] <Daemon404> ubitux, but ffmpeg has a policy if "never drop anything ever"
[20:15] <gnafu> I would imagine anyone using it would also be using an ancient ffmpeg release anyway.
[20:15] <Daemon404> remember the shitstorm about removing fucking gopher?
[20:15] <thetruthisoutthe> gnafu <= http://www.youtube.com/watch?v=dszf1QDvmGs
[20:16] <ubitux> Daemon404: why would you care about gopher if you don't use it?
[20:16] <Daemon404> ... i never said i cared
[20:16] <ubitux> Daemon404: did you ever have the need to keep change your code because gopher (or v4l or whatever) were present?
[20:16] <ubitux> s/keep//
[20:17] <Daemon404> so... you say [14:15] <@ubitux> i don't know if it's relevant to keep the v4l code
[20:17] <Daemon404> and then immediatly switch into mind-zombie "KEEP ALL THE CODE" mode when i mention gopher?
[20:17] Action: durandal_1707 my peanus is bigger then yours
[20:17] <ubitux> Daemon404: i just don't care much
[20:17] <ubitux> whether it's in or no
[20:18] <ubitux> i was just wondering if it made any sense
[20:18] <ubitux> having it in code base or not, who cares really...
[20:18] <durandal_1707> it pointless to keep code that cant be compiled
[20:18] <ubitux> 'depends
[20:18] <gnafu> durandal_1707: Is that, like... a different kind of anus than the rest of us have?  Or, like, are your penis and anus combined?
[20:19] <gnafu> ;D
[20:19] <llogan> that's what a bird has.
[20:22] <thetruthisoutthe> i think they call it hermaphrodite 
[20:23] <Daemon404> you use that word, but i do not think it means what you think it means
[20:25] <durandal_1707> ok, i gonna disable compilation of sonic by default, anyone against?
[20:25] <ubitux> durandal_1707: why?
[20:29] <cone-101> ffmpeg.git 03Clément BSsch 07master:00f4998997f3: lavf/tee: pesudo ’ pseudo.
[20:36] <durandal_1707> sonicls is not lossless
[20:41] <durandal_1707> and its bitstream sucks
[20:59] <ubitux> durandal_1707: btw, audio threading ’ approximately +35M to the log
[21:00] <ubitux> (helgrind & drd)
[21:25] <durandal_1707> michaelni: you fix for memleak appliet to old code
[21:26] <durandal_1707> before my refactor, not its pointless freee
[21:33] <ubitux> michaelni: wrong av_log in your last j2k dec patch
[21:33] <ubitux> michaelni: also, there are some uninitialized read spotted by valgrind
[21:49] <cone-101> ffmpeg.git 03Paul B Mahol 07master:8cc8adaa88a1: tiff: correctly decode saparate planes with horizontal differencing predictor
[21:51] <durandal_1707> also someone could refactor tiff decoder, because adding tile support is currently pita
[21:53] <cone-101> ffmpeg.git 03Michael Niedermayer 07master:7c3a296b4f1f: jpeg2000dec: fix av_log()
[21:59] <durandal_1707> why the only image encoder that uses frame threading is png, when easily tiff,bmp and others could use it too?
[22:00] <durandal_1707> also i did write patch for multi threaded png decoder, but it obviosly can't work with CorePNG crap
[22:02] <durandal_1707> hmm, should ONLY_IF_THREADS_ENABLED always be used?
[22:17] <cone-101> ffmpeg.git 03Michael Niedermayer 07master:ffb1051b9b9b: jpeg2000: Zero prec->cblk
[22:17] <ubitux> thx michaelni 
[22:19] <michaelni> durandal_1707, which memleak fix ? i fixed multiple recently
[22:19] <durandal_1707> tiff one
[22:20] <durandal_1707> i changed av_malloc to fast_padded one...
[22:20] <durandal_1707> int bbae6521136b
[22:20] <durandal_1707> *in
[22:21] <cone-101> ffmpeg.git 03Paul B Mahol 07master:61d900fd0df6: lavc: add ONLY_IF_THREADS_ENABLED where it is missing
[22:26] <michaelni> durandal_1707, i dont see anything else that frees zbuf
[22:30] <ubitux> michaelni: i'm on spp, what is that case were the qp table is defined and the width is 0?
[22:30] <ubitux> (L 487)
[22:35] <ubitux> also, why the qp w & h would be based on the frame size?
[22:37] <ubitux> (oh, it's the qp for each 16x16 blocks i suppose)
[22:38] <ubitux> still, that h=1 case where qstride is 0 sounds weird
[22:41] <michaelni> its because theres a lazy decoder that has all the same qp over the frame and thus uses qstride=0 while allocating just 1 line
[22:41] <ubitux> oh
[22:41] <michaelni> it could be implemented differently of course
[22:41] <ubitux> which decoders is it?
[22:42] <ubitux> i'd like to test that case
[22:42] <michaelni> IIRC jpeg
[22:42] <ubitux> ok
[22:46] <durandal_1707> michaelni: ah, indeed
[22:53] <ubitux> ok so mpeg and jpeg are exporting those qp tables
[22:54] <ubitux> michaelni: we plan to keep those exported qp that way, right?
[22:54] <ubitux> should we un-deprecate them from AVFrame?
[22:57] <ubitux> also, i wonder about those FF_QSCALE_* that should actually be AV_QSCALE_ if we export them
[22:59] <ubitux> ah, and maybe the qscale normalization func should be somehow exported too
[23:05] <michaelni> ubitux, we have av_frame_s/get_qp_table(), the AVFrame fields shouldnt be needed to be accessed from outside
[23:06] <michaelni> but internally, any fields that are needed for  av_frame_s/get_qp_table should stay of course
[23:07] <ubitux> sure, but i was talking about the deprecated flags for those fields
[23:07] <ubitux> which add pointless warnings at compilation time
[23:08] <ubitux> also, what i'm saying is that since the setter/getter for qp tables are exported for the users, in order to make it useful for them we need to expose the flags properly (FF_QSCALE_* ’ AV_QSCALE_*)
[23:08] <ubitux> and eventually export the qscale norm function
[23:13] <michaelni> sure the deprecation could be removed
[23:13] <michaelni> user apps wont get a warning for using the internal fields then though
[23:14] <michaelni> AV_QSCALE or equivalent is fine too
[23:44] <cone-101> ffmpeg.git 03Paul B Mahol 07master:86005184e3c4: tiff: simplify picking right pixel format
[23:46] <ubitux> durandal_1707: now add le/be and make a table with direct access
[23:47] <durandal_1707> ENOME
[23:47] <ubitux> :)
[23:49] <ubitux> "abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq" that is an original string :))
[23:49] <durandal_1707> what?
[23:50] <ubitux> RIPEMD hashing patch
[00:00] --- Fri Jun  7 2013