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

[burek]

[00:09] <durandal_1707> this is gonna be funny
[00:34] <Kovensky> <Kovensky> http://www.reddit.com/r/AskWomen/comments/1hkp8b/ladies_what_would_you_thinkdo_if_you_find_out/
[00:34] <Kovensky> <durandal_1707> Kovensky: post on #ffmpeg-devel too
[00:34] <durandal_1707> :)
[00:46] <durandal_1707> lol, i pinged patch 8 months old
[03:07] <cone-384> ffmpeg.git 03Carl Eugen Hoyos 07master:565140da178e: avcodec/rawdec: Fix 2bpp and 4bpp rawvideo in mov
[10:27] <BuxiNess> hello
[10:31] <burek> <michaelni> burek, can you make fflogger use trac.ffmpeg.org instead of ffmpeg.org/trac/ffmpeg
[10:31] <burek> you mean for the trac events
[10:31] <burek> like this one <fflogger> [editedticket] MrNice: Ticket #2504 (Audio glitches and distortion when recording alsa) updated https://ffmpeg.org/trac/ffmpeg/ticket/2504#comment:108
[10:56] <michaelni> BuxiNess, hello
[10:57] <michaelni> burek, yes thanks!
[11:25] <michaelni> burek, btw, how is the fate server rewrite going ?
[12:58] <nevcairiel> Daemon404: did MSE get its file system lock fixed? I'm building with msvc right now on a system with MSE installed and it goes to 100% cpu just fine
[13:00] <nevcairiel> of course this laptop has a SSD and maybe the filesystem action is just fast enough not to notice
[13:15] <JEEBsv> nevcairiel: I don't think the general speed of it has become better. At least it seems like compiling/linking ffmpeg doesn't crash MSE itself any more
[13:16] <nevcairiel> never did that for me
[13:16] <nevcairiel> except the short time
[13:17] <JEEBsv> yeah, it IIRC got fixed quite some time ago
[13:18] <nevcairiel> was only broken for a couple weeks
[13:30] <nevcairiel> but before it still managed to lock the filesystem so that you could usually only get one process compiling
[13:30] <nevcairiel> now it gives me 100%
[13:30] <nevcairiel> oh well
[13:31] <JEEBsv> SSD magic++
[13:33] <nevcairiel> my development PC has the code on a SSD as well now, i got a new one and used the old one for my code, guess i should test performance again there too
[13:34] <wm4> yeah could see this coming
[13:34] <wm4> who cares about bugs, it's not even my issue
[13:34] <nevcairiel> genpts is stupid anyway
[13:34] Action: nevcairiel never uses it
[13:35] <wm4> so how should one determine good PTS instead?
[13:36] <nevcairiel> genpts never really produces "good" PTS in my experience anyway
[13:36] <wm4> libavcodec has its own code for this (setting AVFrame.best_effort_timestamp), but it's even worse
[13:38] <nevcairiel> formats without any timestamps or any other timing info will most likely not play properly in my setup, but thats usually not all that common
[13:40] <cone-411> ffmpeg.git 03Paul B Mahol 07master:d2ce3b3857b2: riff: remove invalid fourcc 'exr '
[13:41] <cone-411> ffmpeg.git 03Michael Niedermayer 07master:df6acc81a851: avcodec/ra288: use init_get_bits8()
[13:41] <cone-411> ffmpeg.git 03Michael Niedermayer 07master:8c707a129a0f: avcodec/svq1dec: use init_get_bits8()
[13:41] <cone-411> ffmpeg.git 03Michael Niedermayer 07master:b237e6282ef5: avformat/h261dec: use init_get_bits8()
[13:41] <cone-411> ffmpeg.git 03Michael Niedermayer 07master:6d05039c7ecb: avcodec/sonic: Fix usage of init_get_bits() and use init_get_bits8()
[14:14] <cone-411> ffmpeg.git 03Paul B Mahol 07master:253e155251ec: lavfi/crop: support more pixel formats
[14:37] <wm4> JEEB: not sure if you know, but what software produces mkv files that uses Seek elements for indexing all clusters?
[14:37] <JEEBsv> hmm
[14:37] <JEEBsv> does mkvmerge do that?
[14:38] <wm4> actually yes
[14:38] <wm4> forgot to look at the muxer field
[14:38] <wm4> "mkvmerge v2.9.8"
[15:03] <durandal_1707> ubitux: have looked at #1618?
[15:04] <ubitux> nope
[15:06] <durandal_1707> ubitux: you seems inactive
[15:07] <ubitux> yes i'm busy with some other stuff currently
[15:33] <saste> ubitux, are you fine with my avfilter_graph_parse() fix?
[15:34] <ubitux> i don't really have time to look closely, sorry
[15:34] <ubitux> i'll be back on ffmpeg starting next month
[15:35] <saste> ubitux, ok, just wondering since you didn't comment on list
[15:35] <ubitux> yeah, sorry
[15:36] <saste> who is our MPEG-TS expert?
[15:36] <saste> JEEB?
[15:36] <saste>  http://blog.zencoder.com/2011/12/08/announcing-the-clouds-most-efficient-http-live-streaming/
[15:37] <JEEBsv> saste: more like kierank lol
[15:37] <kierank> saste: i spoke to them about that
[15:37] <kierank> basically they hacked mpeg-ts to save bits
[15:37] <kierank> but be out of spec
[15:37] <kierank> but work on mobile phones
[15:38] <saste> kierank, do you know how they did?
[15:38] <kierank> saste: lots of packets per PES
[15:38] <saste> we could add an MPEG-TS option for emulating that behavior
[15:38] <kierank> and at the end of the PES don't write stuffing
[15:38] <saste> also, IIRC the Apple streamer implements the same feature
[15:39] <saste> kierank, so why nobody posted a patch for that yet?
[15:39] <kierank> because it's evil
[15:40] <saste> kierank, what's the problem with that? we're evil as well
[15:40] <saste> as long as it is not the default and players are happy with it
[15:41] <nevcairiel> does the hls segmenter in avformat work decently anyway? I never tested, but i was kinda planning to use HLS for some things down the line
[15:41] <wm4> saste: did you see my comments about the inconsistent defines for the avfilter_graph_parse fix?
[15:50] <saste> wm4: no
[15:50] <saste> wm4, post or irc?
[15:52] <wm4> irc
[15:52] <saste> i was not logged
[15:53] <saste> so what's the problem?
[15:53] <wm4> <wm4> what defines AV_HAVE_INCOMPATIBLE_LIBAV_ABI? I get warnings like include/libavfilter/avfilter.h:1314:5: warning: "HAVE_INCOMPATIBLE_LIBAV_ABI" is not defined [-Wundef]
[15:53] <wm4> <wm4> installation problem?
[15:53] <wm4> <wm4> also I see both HAVE_INCOMPATIBLE_LIBAV_ABI and AV_HAVE_INCOMPATIBLE_LIBAV_ABI in the ffmpeg sources
[15:53] <wm4> it doesn't cause an actual problem currently, though
[15:53] <saste> uhm... i screwed
[15:53] <saste> up
[15:53] <saste> once
[15:53] <saste> again
[15:54] <wm4> it's not so bad, it didn't break compilation
[15:56] <saste> but... the problem was pre-existing
[15:58] <saste> uhm so we have the HAVE_ defined in config.h, and the corresponding AV_HAVE defines in avconfig.h
[15:59] <saste> michaelni, what should we use? why do we have both variants?
[15:59] <saste> and yes it should work as is, althought the double defines are a bit confusing
[16:00] <saste> nevcairiel, there are still a few compatibility issues, but mostly working
[16:01] <wm4> michaelni: is there anything planned that could make seeking in files with TS resets make sane? or is everyone stuck with byte seeks? if so, is there any sane way to map time based seeks to byte seeks? it'd require a good bitrate estimate
[16:02] <av500> wm4: read the whole file
[16:02] <av500> keep a mapping in memory
[16:03] <wm4> av500: yeah, but that's often not feasible... but for example an API to do relative time based seeks could help
[16:03] <av500> patches welcome I guess
[16:05] <wm4> I guess I can try with AVFormatContext.bit_rate
[16:05] Action: wm4 wonders how hard this will fail
[16:05] <av500> I doubt bit_rate is sane for TS
[16:06] <av500> you can do things like seek around in the file a bit, grab byte pos and time stamps
[16:06] <av500> and then deduct the bitrate and where it wraps
[16:06] <wm4> and libavformat doesn't do that?
[16:06] <kierank> bit rate won't be sane for vbr
[16:07] <av500> wm4: no
[16:07] <wm4> at least libavformat could try to use the same segment when doing ab absolute time based seek
[16:07] <av500> it could
[16:07] <kierank> segment?
[16:07] <av500> if somebody wrote the code
[16:07] <wm4> kierank: I don't know the proper term
[16:07] <av500> kierank: wrt timestamp wrap around
[16:07] <av500> I guess
[16:07] <kierank> ah oik
[16:08] <av500> but I guess broadcast TS can have TS wraps at any time
[16:08] <kierank> anyway the proper way is indexing :)
[16:08] <av500> not just when the counter runs over
[16:08] <saste> michaelni, durandal_1707, ping for muxing resampling patch
[16:08] <saste> also, there is some plan for a more high level resampling API?
[16:09] <wm4> saste: isn't it af_aresample?
[16:09] <kierank> av500: yes, some places splice for local news
[16:09] <michaelni> saste, with av prefix its public without its not
[16:09] <kierank> and other junk
[16:09] <michaelni> wm4, planed yes since many many years
[16:09] <wm4> ok
[16:10] <saste> wm4, if you use libavfilter
[16:10] <saste> and a filtergraph is still not trivial to setup
[16:10] <wm4> saste: yes, I thought libavfilter was supposed to be the high level API
[16:10] <saste> wm4, but you may want to resample without relying on libavfilter
[16:11] <saste> maybe a sort of push/pop samples API could be useful
[16:11] <saste> you buffer samples, and then call pop to get the converted samples (only if you get at least N samples)
[16:12] <av500> you dont need to resample
[16:13] <av500> android audioflinger does that for you :)
[16:23] <cone-411> ffmpeg.git 03Zhang Rui 07master:4a4c93cb3f2f: avformat/http: support relative url redirection
[17:16] <superware> michaelni: hi. do you have a few minutes to test the mpegts stream?
[18:57] <Daemon404> nevcairiel, could be either
[19:13] <cone-411> ffmpeg.git 03Carl Eugen Hoyos 07master:f32b8130f434: Fix opacity and increase colour dynamics of initial vmd palette.
[19:13] <cone-411> ffmpeg.git 03Sean McGovern 07master:bf18abb2eb79: Rename "AVClass class" as "AVClass component_class" for external codecs.
[19:23] <cone-411> ffmpeg.git 03Michael Niedermayer 07master:2ca48e466675: avformat: Append data in fill_buffer() when possible
[19:23] <cone-411> ffmpeg.git 03Michael Niedermayer 07master:186ec1784336: avformat/aviobuf: Add ffio_ensure_seekback()
[19:23] <cone-411> ffmpeg.git 03Michael Niedermayer 07master:8a8d9a738599: mpegts: use ffio_ensure_seekback()
[19:23] <michaelni> superware, you can test the fix tomorrow with zeranoes binaries
[19:56] <cone-411> ffmpeg.git 03Matthieu Bouron 07master:621ab4e4ef69: lavf/movenc: check ff_mov_init_hinting() return
[20:09] <superware> michaelni, great! thanks
[20:29] <saste> avoid_negative_ts integer (output)   Shift timestamps to make them positive. 
[20:29] <saste> michaelni, shouldn't it be "non-negative"?
[21:33] <durandal_1707> i demand creating release branch
[21:39] <durandal_1707> michaelni: for tickets are blocking release?
[21:42] <durandal_1707> s/for/what
[21:43] <Daemon404> 9 concurrent release. yep. nothing insane about that.
[21:43] <Daemon404> totally normal
[21:46] <Daemon404> damn webgit has blame disabled again
[21:46] <Daemon404> what a pain
[21:51] <durandal11707> did i missed somthing? (last thing i got is: what a pain)
[21:51] <Daemon404> no
[21:51] <Daemon404> [15:46] <@Daemon404> damn webgit has blame disabled again
[21:51] <Daemon404> [15:46] <@Daemon404> what a pain
[21:53] <michaelni> durandal11707, the tickets marked as regression (minus irrelevant things) should be fixed before the release. That doesnt mean they have to be fixed just that they should
[22:00] <Daemon404> hey ubitux 
[22:00] <Daemon404> dctdnoiz should be fine for sitll images
[22:00] <Daemon404> no?
[22:00] <Daemon404> (i am too lazy to check if it relies on temporal info)
[22:03] <ubitux> no temporal info
[22:03] <ubitux> still image denoising
[22:04] <Daemon404> oic
[22:04] <Daemon404> im FINALLY testing it
[22:04] <Daemon404> as soon as configure finishes taking its sweet time
[22:04] <ubitux> dctdnoiz will be slower
[22:04] <Daemon404> i used to encode using frequency denoisers at 0.05fps
[22:05] <Daemon404> on an athlon xp
[22:05] <Daemon404> im used to it
[22:05] <ubitux> that's pretty optimist for that filter
[22:05] <Daemon404> lol
[22:06] <ubitux> but i believe it can be simplified and optimized with a 3d fdct call
[22:06] <ubitux> like we have in the dsputils
[22:07] <Daemon404> depends if its any good
[22:07] <Daemon404> ;)
[22:07] <ubitux> btw, yet another denoiser was submitted to ipol.im
[22:08] <ubitux> possibly a better one
[22:08] <Daemon404> im pretty skeptical about "paper' denoisers
[22:08] <Daemon404> usually avs has ha something better for N years
[22:08] <Daemon404> than the latest papers, seemingly
[22:08] <Daemon404> tl;dr DSP papers tend to be full of crap
[22:10] <cone-411> ffmpeg.git 03Paul B Mahol 07master:dda8afc39179: libstagefright: unbreak compilation
[22:19] <cone-411> ffmpeg.git 03Paul B Mahol 07master:d1c96b28d7b6: libstagefright: port to refcounted frames
[22:21] <Daemon404> ubitux, wowwwwwwww
[22:21] <Daemon404> you werent kidding
[22:21] <Daemon404> took liek 30 sec for a 640x400 png
[22:21] <ubitux> :D
[22:21] <JEEB> :D
[22:21] <ubitux> you can possibly make it slower with a complex expression
[22:22] <Daemon404> ubitux, that was wth '-vf dctdnoiz'
[22:22] <Daemon404> which seemingly did nothing
[22:22] <durandal11707> try -vf owdenoise
[22:22] <ubitux> sigma is 0 by default, so yeah
[22:23] <Daemon404> ah ok
[22:23] <ubitux> Daemon404: feel free to set an overlap btw
[22:23] <ubitux> to make it faster
[22:23] <Daemon404> sigma3 did barely anythng xD
[22:23] <ubitux> like overlap=10 or something
[22:23] <Daemon404> i shouldnt test it on pc98 screenshots...
[22:23] <Daemon404> 30kb->290kb
[22:23] <Daemon404> w/ sigma=3
[22:31] <Daemon404> note to self: 8k photos + dctdenoiz = lol
[22:31] <ubitux> :D
[22:31] <ubitux> just set some overlap value :p
[22:32] <Daemon404> it's interesting how it seems to blur more
[22:32] <Daemon404> in some areas
[22:32] <ubitux> denoising is a blur op actually :p
[22:32] <durandal11707> you want unsharp
[22:33] <durandal11707> it can sharp
[22:33] <durandal11707> and blur
[22:33] <ubitux> :)
[22:33] <Daemon404> ubitux, im merely interested in how it has localized blur
[22:33] <Daemon404> i mean it's obv, but it looks funny
[22:34] <cone-411> ffmpeg.git 03Michael Niedermayer 07master:cb678cc2cf46: avcodec/svq1enc: fix frame rotation code
[22:35] <Daemon404> in: https://dl.dropboxusercontent.com/u/77349181/01970024.JPG
[22:35] <Daemon404> out: https://dl.dropboxusercontent.com/u/77349181/test.png
[22:36] <ubitux> high sigma :p
[22:36] <Daemon404> indeed
[22:36] <ubitux> how much did you set?
[22:36] <Daemon404> thats 30
[22:36] <Daemon404> ;)
[22:36] <ubitux> :p
[22:36] <ubitux> KILL ALL THE NOIZ
[22:37] <Daemon404> e.g. some rocks survive a lot better
[22:37] <ubitux> doesn't it look nice with sigma 10?
[22:38] <Daemon404> no
[22:39] <Daemon404> some of the trees still get chewed up
[22:39] <Daemon404> wayyyyyyy more than everything else
[22:39] <ubitux> the dark area looks more blurry
[22:39] <ubitux> or maybe that's how i perceive it :p
[22:40] <ubitux> Daemon404: feel free to try a better expression
[22:40] <ubitux> (and add it to the documentation if it's cool :P)
[22:41] <Daemon404> https://dl.dropboxusercontent.com/u/77349181/2test.png
[22:41] <Daemon404> look at the tree above the waterfall
[22:41] <Daemon404> it gets chewed up far more than most anything else
[22:43] <cone-411> ffmpeg.git 03Paul B Mahol 07master:35b02732b98c: configure: fix webp decoder dependency
[22:51] <durandal11707> why ffmpeg eats 330M when i run owdenoise on this image?
[22:53] <durandal11707> does its algo need that much memory?
[22:55] <durandal11707> unsharp=luma_msize_x=7:luma_msize_y=7:luma_amount=2.5 looks best
[23:03] <durandal11707> buxiness: do you plan to add yuv pixel format support to jpeg2000 ?
[23:04] <buxiness> durandal11707: In hat direction encoding or decoding? 
[23:06] <buxiness> And JPEG2000 is more RGB like, then YUV, even if all the decoding part is done in a YUV domain
[23:06] <durandal11707> decoding obviously
[23:06] <buxiness> I didn't find any matrix for that.
[23:07] <durandal11707> you are not making any sense
[23:07] <buxiness> But at the end of decoding the MCT do a YUV --> RGB conversion. May be just test to avoid it 
[23:07] <durandal11707> why would yuv need special matrix, and what kind of matrix?
[23:07] <buxiness> for collorspace conversion, the matrix
[23:08] <durandal11707> and where is that matrix in decoder?
[23:08] <buxiness> in decoder is the mct, in joeg2000dec.c
[23:09] <durandal11707> and why would that be rgb specific?
[23:10] <buxiness> The standard output of jpeg2000 dec is RGB. Hisorricaly is made for images
[23:10] <durandal_1707> nonsense
[23:10] <buxiness> Maybe 
[23:11] <durandal_1707> jpeg2000 can store any format
[23:11] <Daemon404> "any"?
[23:11] <Daemon404> so it can store LAB now?
[23:11] <Daemon404> or HSV?
[23:11] <durandal_1707> really anything
[23:12] <durandal_1707> except that it may not be efficient (compression wise....)
[23:12] <buxiness> jpeg2000 is supposed to be colorspace free, that's true
[23:12] <Daemon404> ah ok
[23:13] <buxiness> If we have jpeg2000 bitsream + jpeg2000 format( or container), we can have all kind of colorspace 
[23:14] <durandal_1707> in bitstream, subsampling are defined
[23:14] <buxiness> yep
[23:14] <durandal_1707> so i did not checked decoder yet, to find how hard would be to add yuv 420 support for example
[23:15] <Daemon404> i think 4:2:2 or 4:4:4 would be more useful
[23:15] <Daemon404> and far more likely to be used where j2k is actually used
[23:15] <Daemon404> (broadcast & editing
[23:15] <cone-411> ffmpeg.git 03Michael Niedermayer 07master:65abce67b52c: avformat/movenc: allow negative TS for the ipod muxer
[23:15] <Daemon404> nobody uses 4:2:0 there
[23:16] <durandal_1707> Daemon404: when you get one, you gen all of them
[23:16] <durandal_1707> usually, but code may be full of little tricks ...
[23:16] <Daemon404> "little tricks" is not how i would describe swscale :P
[23:17] <durandal_1707> swscale is not that much obfuscated
[23:18] <Daemon404> look in libswscale/x86/*template.c
[23:19] <Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libswscale/x86/swscale_template.c;h=f2567c1d8b5de20369c4d716a0fd8236ba56dea5;hb=HEAD
[23:19] <durandal_1707> bunch of deep macros, ease cake
[23:19] <Daemon404> i dont think you quite understand what obfuscated means
[23:19] <Daemon404> or have a concept of easily followable code
[23:20] <Daemon404> also iirc
[23:20] <Daemon404> some of that mmx
[23:20] <Daemon404> is self modifying
[23:20] <durandal_1707> its normal if there is C variant
[23:20] <durandal_1707> its assembly after all
[23:21] <durandal_1707> anyway, how would you improve it?
[23:21] <buxiness> If your jp2 headers specifies no mct, you have direct YUV output
[23:23] <buxiness> 4:4:4, is supported in current dec. 4:2:2 and 4:2:0 should be
[23:23] <durandal_1707> does decoder actually parse block that says what colorspace is in use?
[23:24] <buxiness> But so far, I never use chroma subsampling
[23:24] <durandal_1707> with bayer rgb
[23:24] <buxiness> durandal_1707: no, not at code stream file
[23:24] <buxiness> s/code stream level
[23:25] <durandal_1707> jp2 have it
[23:26] <buxiness> https://en.wikipedia.org/wiki/JPEG_2000#File_format_and_code_stream
[23:26] <buxiness> the file format have it, not the codestream
[23:26] <durandal_1707> so you telling one need to write jp2 demuxer?
[23:27] <buxiness> yes :-)
[23:28] <durandal_1707> that is suboptimal
[23:28] <buxiness> It depends if input is a video or just a file
[23:28] <durandal_1707> well jp2 usually have single image
[23:29] <durandal_1707> and looks like nobody use .jpx
[23:58] <cone-411> ffmpeg.git 03Michael Niedermayer 07master:46ad287a2a87: avutil/rational: avoid llrint() and rint()
[00:00] --- Fri Jul  5 2013