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

[burek]

[00:28] <durandal_1707> sorry for spam
[00:35] <durandal_1707> michaelni: if i want to mux qtrle into nut, shoult i add qtrle tag to nut.c or isom tags table to nut.c ?
[00:41] <michaelni> id say table to nut.c if this has no negative sideeffects
[00:42] <michaelni> also nut4cc.txt needs to be updated which needs a patch to be sent to nut-devel for discussion there
[00:45] <durandal_1707> i'm not going to subscribe to yet another mailing list nobody use
[00:46] <durandal_1707> also nut does not store bits_per_coded_sample anywher
[00:46] <llogan> nobody? then you won't have to worry about getting any messages from it
[00:46] <durandal_1707> and adding extradata handling in encoder/decoder and muxer smells wrong
[00:47] <durandal_1707> in this case extradata would just store bits_per_coded_sample
[00:48] <durandal_1707> llogan: why you do not comment other, bigger patch?
[00:49] <llogan> which one is the bigger patch?
[00:49] <durandal_1707> very big patch
[00:51] <llogan> sorry, but i don't know which one that is.
[00:52] <wm4> too bad
[00:52] <durandal_1707> llogan: one i sent the other day not this day
[00:53] <llogan> compand?
[00:57] <durandal_1707> and perspective, and whole doc/*
[01:42] <cone-300> ffmpeg.git 03Michael Niedermayer 07master:8efe96ee6f3f: swscale/fill_rgb2yuv_table: fix default detection
[01:42] <cone-300> ffmpeg.git 03Michael Niedermayer 07master:8720d3ac217e: avfilter/vf_scale: set in_color_matrix default to "auto"
[01:47] <wm4> michaelni: would it be possible to add ycgco to swscale?
[01:47] <wm4> that's really just a "why not", not a serious feature request
[02:03] <Compn> wm4 : got a sample ?
[02:14] <michaelni> everything is possible, i suspect its not trivial though
[08:59] <cone-368> ffmpeg.git 03Hendrik Leppkes 07master:779e6c2b985f: lavfi: add attribute_align_arg to all public entry points
[08:59] <cone-368> ffmpeg.git 03Michael Niedermayer 07master:2fffc05f424f: Merge commit '779e6c2b985f2ad461a1ae704160822f97709ba7'
[09:05] <cone-368> ffmpeg.git 03Martin Storsjö 07master:1297f7b87f8a: rtpenc: Fix some odd comments
[09:05] <cone-368> ffmpeg.git 03Michael Niedermayer 07master:5cb3d35dcc23: Merge commit '1297f7b87f8a84930a23eca705765c7c353dfcd5'
[09:12] <cone-368> ffmpeg.git 03Hendrik Schreiber 07master:b512360184ad: avio: Don't set the seekable flag if no seek function is provided
[09:12] <cone-368> ffmpeg.git 03Michael Niedermayer 07master:103b8d876a86: Merge commit 'b512360184ade835fba621f5042d643fc9e2ee9d'
[09:18] <cone-368> ffmpeg.git 03Michael Kostylev 07master:80ade7985cd9: AIX: add support for shared builds
[09:18] <cone-368> ffmpeg.git 03Michael Niedermayer 07master:e64dc86a13c0: Merge commit '80ade7985cd95156e2156f50adc7b86d0e43a07a'
[09:25] <cone-368> ffmpeg.git 03Martin Storsjö 07master:86f042dcabde: wtv: Make WTV_SECTOR_BITS a 64 bit constant
[09:25] <cone-368> ffmpeg.git 03Michael Niedermayer 07master:902792852279: Merge commit '86f042dcabde2a5386dbd95ab0451b274987d253'
[09:52] <cone-368> ffmpeg.git 03Martin Storsjö 07master:979e9e8f3671: wtv: Drop some casts that now are unnecessary
[09:52] <cone-368> ffmpeg.git 03Michael Niedermayer 07master:e8023dbaf0db: Merge remote-tracking branch 'qatar/master'
[10:24] <ThePuppetMaster_> i try to recode a avi file into a mpeg file. but i get a error: Insufficient thread locking around avcodec_open/close() ... thats the full output: http://pastebin.com/SGn1UH3j .... can anyone tell me whats wrong, and how i can fix it?
[10:33] <michaelni> ThePuppetMaster_, check what is calling avcodec_open/close at the same time
[10:35] <michaelni> and if these calls are valid & intended to occur at the same time then set a lock manager with av_lockmgr_register
[10:35] <ThePuppetMaster_> well ... how i can check this? ... i'm only use mencoder ... i'm not develing in it ... but, i search in the source the point, where calling this output, but foudn a lot and i don't know whats the right
[10:36] <ThePuppetMaster_> and, avcodet lib is realy big :P
[10:37] <michaelni> a gdb backtrace from where the message is printed will tell you one of the 2 conflicting uses of avcodec_open/close
[10:37] <ThePuppetMaster_> can u give me a searchpoint for me?
[10:37] <ThePuppetMaster_> ok
[10:37] <ThePuppetMaster_> i try it
[10:49] <michaelni> also to find the 2nd one, you can make gdb print stacktraces on calls to avcodec_open/close, something like break avcodec_open // commands 1 // bt // continue
[10:56] <ThePuppetMaster_> well .. gdb is not my favorite .. .. its hard for me to use it
[10:56] <ThePuppetMaster_> but, it looks, my mencoder was compiled without -debug flags
[10:57] <ThePuppetMaster_> i only get adresses of the break
[10:57] <ThePuppetMaster_> like this #0  0x00007fffefa221b5 in ?? ()
[13:00] <durandal_1707> perhaps those failures with clang 2.9 are because of clang bug?
[13:16] <ThePuppetMaster> which?
[13:20] <ubitux> hey
[13:20] <ubitux> i'm alive
[13:20] <ubitux> i'm soon back on ffmpeg
[13:20] <durandal_1707> who are you?
[13:21] <ubitux> BBB / BBB-work is the vp9 prect still ok?
[13:21] <ubitux> durandal_1707 :D
[13:23] <ubitux> s/prect/project/
[13:23] <ubitux> anyway, 1st august i'm on the plane on my  way back
[13:53] <saste> ubitux, hey!
[13:53] <saste> why, where are you this time?
[13:55] <ubitux> japan again saste
[13:55] <ubitux> lost in hokkaido :)
[13:55] <saste> eheh
[13:55] <ubitux> i love this country so much seriously...
[13:57] <JEEB> hokkaido seems nice
[13:57] <JEEB> TT is currently in Japan, too
[13:57] <durandal_1707> japan doesn't have internet?
[13:57] <JEEB> very little free wifi
[13:57] <JEEB> the only one I know is at the tokyo metro
[13:58] <JEEB> basically if you need internets your best bet is to buy a b-mobile (virtual operator on the NTT DoCoMo network) prepaid SIM card for data
[13:58] <JEEB> you don't need papers that you live in Japan for getting a data-only line, thank goodness
[13:58] <saste> JEEB, probably he has better things to do there than checking his emails
[13:59] <JEEB> haha, most probably :)
[13:59] <JEEB> still, people in Japan don't SMS
[13:59] <JEEB> they e-mail
[13:59] <JEEB> (because of the differing types of networks and the fact that you couldn't even send SMS to other networks within the same technological system until very lately)
[14:00] <JEEB> So, even if DoCoMo and SoftBank f.ex. both used W-CDMA for 3G, you couldn't still send SMS between these two until very recently IIRC :)
[14:00] <JEEB> and then you have au with CDMA2000rev0
[14:01] <JEEB> and willcom with le HPS
[14:05] <cone-656> ffmpeg.git 03Paul B Mahol 07master:5efa5103b0e7: sgidec: simplify return path
[14:05] <cone-656> ffmpeg.git 03Paul B Mahol 07master:997e2b59e354: sgidec: return meaningful error codes
[14:05] <cone-656> ffmpeg.git 03Paul B Mahol 07master:86e722ab97d7: sgidec: safer check for buffer overflow
[14:05] <cone-656> ffmpeg.git 03Paul B Mahol 07master:573018c61fad: lclenc: cosmetics: reindent
[14:05] <cone-656> ffmpeg.git 03Paul B Mahol 07master:6dbcecd78e02: lclenc: allocate FF_INPUT_BUFFER_PADDING_SIZE for extradata
[14:05] <cone-656> ffmpeg.git 03Paul B Mahol 07master:3ea5d01a12ed: escape130: make "chroma_vals" static
[14:05] <cone-656> ffmpeg.git 03Paul B Mahol 07master:d9954ccff07b: targa: set pict_type
[14:05] <cone-656> ffmpeg.git 03Paul B Mahol 07master:88b071a47392: exr: set pict_type
[15:31] <cone-656> ffmpeg.git 03Michael Niedermayer 07master:5e763920a44f: avcodec/mpegvideo: update disabled assert() to av_assert0()
[15:31] <cone-656> ffmpeg.git 03Michael Niedermayer 07master:3adf054b22d6: avcodec/vorbisenc: change 6 asserts to av_asserts()
[15:45] <mateo`> is ffplay enable to use vaapi for decoding ?
[15:46] <JEEB> if it's a hwaccel, no -- those need extra code to use it from the using side
[15:47] <mateo`> would it be a good idea to add such code to ffplay ?
[15:54] <durandal_1707> JEEB: ut patch sent
[15:56] <JEEB> ah
[15:57] <JEEB> at a quick glance looks OK
[15:57] <JEEB> have to run to the Koff's park soon
[15:57] <JEEB> free sausages
[15:58] <ubitux> < JEEB> still, people in Japan don't SMS // there is some kind of gateway between the two afaict
[15:58] <ubitux> which is cool
[15:58] <JEEB> yeah, lately
[15:58] <ubitux> and for free internet mmh, guest houses & hostel have them :)
[15:58] <JEEB> well, yeah :)
[15:59] <JEEB> I just need e-mail when I'm mobile generally in Kantou
[15:59] <ubitux> i actually have internet access almost every day, but i'm busy wondering about where i can go the next day :)
[15:59] <JEEB> since phone calls are lolexpensive and I was stupid enough not to make a softbank prepaid back when I had the papers
[15:59] <JEEB> also I should have definitely made a bank account in '05
[15:59] <durandal_1707> ubitux: are you near sea or vulcano or nuclear reactor?
[15:59] <JEEB> they made the rules harsher in '06 and now it's quite herp derp
[16:00] <ubitux> durandal_1707: i did a few island, and passed along fukushima
[16:00] <ubitux> right now, i'm at sapporo, going down to tokyo, yukuri~
[16:00] <ubitux> no volcano this time
[16:01] <ubitux> but i went to aso last time
[16:02] <ubitux> not a single earthquake yet
[16:02] <ubitux> almost disappointed :(
[16:03] <JEEB> you get used to them rather quickly
[16:03] <JEEB> and most are like shindo 1-3
[16:03] <ubitux> i didn't get any
[16:03] <ubitux> well it's not like i've lived in a earthquake-area for 5 years but well
[16:04] <ubitux> anyway, gtg 'see ya
[16:24] <durandal_1707> how much log() is slow?
[16:51] <cone-656> ffmpeg.git 03Stefano Sabatini 07master:b4bd21b7fe2a: doc/codecs: fix dangling reference to codec-options chapter
[17:38] <wm4> has anyone tried this lavfi opencl stuff? does it actually help?
[19:01] <cehoyos> Compn: Hi, in case user hotwings reappears and asks about vdpau again, please ask him to test current MPlayer and send him to one of the mailing lists. (I don't even understand his question.)
[19:02] <BBB> ubitux: yes
[19:02] <BBB> ubitux: we start in about a week right?
[20:18] <BBB> durandal_1707: pretty awful
[20:18] <BBB> durandal_1707: you can get faster if you know limitations on use
[20:19] <BBB> e.g. lower precision, lower range, ec.
[20:19] <BBB> *etc.
[20:35] <durandal_1707> hmm, filter does log+exp for every sample which is pretty costly...
[20:35] <BBB> lol that sounds awful yes
[20:35] <BBB> try profiling it
[20:35] <mateo`> michaelni, durandal_1707: hi, do you think it would be acceptable to add a write_apic_packet function to the muxers ?
[20:51] <durandal_1707> BBB: for 44100 sample rate its fast enough....
[20:52] <durandal_1707> but 96000 would already be slow here
[21:07] <michaelni> mateo`, which muxers and what would the function do ?
[21:10] <cone-656> ffmpeg.git 03Tim.Nicholson 07master:84e345b38e58: Forward interlaced field information from mov to v210 decoder.
[21:10] <mateo`> michaelni: it would be implemented in all muxers which handle cover arts (mp3, aiff, flac, ...)
[21:11] <mateo`> michaelni: all packets from streams with AV_DISPOSITION_ATTACHED_PIC will be pushed into it
[21:12] <mateo`> so we have a "generic" way to handle thoses streams in muxer (and avoid a if block)
[21:12] <michaelni> sounds reasonable ...
[21:13] <mateo`> but as I said on the mailing list, since my goal is still to add this support in the mp4 muxer, it won't simplify the support for this muxer
[21:14] <mateo`> or at least all the instrusive part
[21:14] <michaelni> i think something should be done about the intrusive stuff
[21:17] <mateo`> me too, but without addind a mapping between stream indexes and track indexes, the only solution left, is to not consider apic streams as normal streams (and not reference them in s->streams)
[21:17] <mateo`> (afaik)
[21:18] <michaelni> if theres no good solution then we have to accept a not so good one :(
[21:18] <michaelni> iam not objecting to the intrusiveness if its the least problematic path
[21:20] Action: michaelni afk
[21:20] <mateo`> it seems to be the least problematic path without modifying the way attached pics are handled
[21:21] <durandal_1707> the current (iirc only?) patch on ml?
[21:22] <mateo`> durandal_1707: yes
[22:08] <cone-656> ffmpeg.git 03Paul B Mahol 07master:60a7fac61b81: utvideoenc: use av_image_copy_plane()
[22:23] <cone-656> ffmpeg.git 03Paul B Mahol 07master:0909f3edbdfa: zmbv: return meaningful error code
[22:54] <cone-656> ffmpeg.git 03Paul B Mahol 07master:9d099b9ae4b6: targa_y216dec: remove empty function
[22:54] <cone-656> ffmpeg.git 03Paul B Mahol 07master:6a574942040c: dpxenc: cosmetics: reindent
[22:54] <cone-656> ffmpeg.git 03Paul B Mahol 07master:94ad38e2e8a5: dpx: use av_image_copy_plane()
[23:09] <cone-656> ffmpeg.git 03Marton Balint 07master:63c0113588d6: lavc: do not override format if neither text nor bitmap codec prop is set
[23:09] <BBB> durandal_1707: define fast enough
[23:10] <BBB> durandal_1707: you make it sound like there is a specific threshold above which it is 100% ok and below which it is 0% ok
[23:10] <BBB> durandal_1707: I don't think that's how these things work
[23:10] <nevcairiel> fast enough = still works in realtime :P
[23:10] <BBB> durandal_1707: we should make it afap (as fast as possible), so that it can be used in combination with as many features combined on as many systems combined that are as low-power as possible
[23:10] <durandal_1707> well its 40x fast for 44100
[23:10] <Compn> cehoyos : hotwings is on irc, send him a pm
[23:10] <Compn> cehoyos : hes just not on this channel...
[23:11] <durandal_1707> BBB: i just removed log/exp and it was 10x slower (I did not scaled other numbers to get correct output)
[23:12] <BBB> you are trying to say log/exp made it faster?
[23:12] <BBB> or you mean log/exp is 90% of its runtime?
[23:13] <durandal_1707> no, i think its because long float multiplications are slower or faster depending on input
[23:13] <durandal_1707> i did not looked how much log/exp costs
[23:13] <BBB> hm...
[23:14] <durandal_1707> or its CPU...
[23:36] <saste> mmh saturday night, time for nerds to send patches...
[00:00] --- Sun Jul 28 2013