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

[burek]

[00:03] <pippin> durandal_1707: not much I'd find in my intentionally short irc-backlog - likely more about delivery than message
[00:04] <pippin> durandal_1707: but the "it could be a gimp bug" is insulting me ;)
[00:09] <pippin> durandal_1707: ( btw michaelni's commit messages is incomplete; .. neither mplayer nor any web-browser I have tried likes the previous .GIFs either )
[00:10] <michaelni> i used gimp to debug it, which was a more or less random pick
[00:12] <pippin> it gave the least vague - though still quite odd - debug warning during loading of the decoders
[00:12] <durandal_1707> i still do not know what is actual bug that commit hypothetically fixed
[00:15] <durandal_1707> so fix may be just band-aid
[00:15] <pippin> durandal_1707: insert 2 or more identical frames in your video to be made gif of.. and most browsers would hick-up and loop on that frame back to the beginning
[00:16] <durandal_1707> i'm not saying previous solution was perfect
[01:31] <ubitux> mmh i wonder if mails from my new address will pass
[01:32] <ubitux> "Sender address rejected: Greylisted, try again later" aw
[01:40] Action: ubitux just learned about greylisting, funny.
[01:43] <Compnn> i love people who use automated -listings
[01:43] <Compnn> because then i automatically stop trying to contact them :)
[01:56] <ubitux> weird configuration
[07:23] <BBB> ubitux: any 32x32 intra pred patches ready for merging or review yet?
[09:59] <ubitux> BBB: basically just one, but i'm "waiting" for the others because i'm still unsure about having them unrolled
[10:01] <BBB> how did you implement the first one? unrolled or looped?
[10:01] <ubitux> unrolled
[10:02] <ubitux> but i generated it
[10:03] <ubitux> (it helps me see if the unrolled logic is that much smaller)
[10:03] <ubitux> (at least i was hoping so :p)
[10:03] <ubitux> and yeah sorry again for being slow
[10:04] <ubitux> i'll try to rush thing a bit
[10:04] <BBB> how much code is it?
[10:04] <BBB> (compared to e.g. the 16x16)
[10:05] <BBB> like quite literally 4x the screen content? or better? or worse?
[10:05] <ubitux> my code didn't 80-line break, so it doesn't look 4x, but i believe it is
[10:06] <ubitux> is/will-be
[10:06] <ubitux> isn't this code supposed to be simd at some point btw?
[10:07] <ubitux> i mean, is it worth the effort trying to unroll-optimize the C versions?
[10:07] <BBB> it'll be simd'ed yes
[10:08] <BBB> I wrote some simd for libvpx' intra pred already, which we can use in ffmpeg also
[10:08] <BBB> (it's not very difficult)
[10:08] <ubitux> ok
[10:08] <BBB> whether it's worth having an unrolled or not is totally up to you I think
[10:08] <nevcairiel> isnt this something a good compiler could even unroll?
[10:08] <ubitux> btw, i had to "trick" to build your branch recently because of the VLA
[10:09] <ubitux> nevcairiel: do you know a good compiler?
[10:09] <nevcairiel> if you really cared you could look up the asm of that function after compiling the looped version
[10:09] <ubitux> BBB: my question was also about 16 and 8 actually, not specially the 32 implem
[10:09] <nevcairiel> or you just join the not caring train and hope for simd :)
[10:10] <BBB> ubitux: oh right that VLA
[10:10] <BBB> ubitux: I'll kill that, it's a hack b/c I'm lazy
[10:11] <BBB> ubitux: right... well I'm not against making 8x8/16x16 loopy also, but do keep in mind that this code may be re-merged with h264pred.c and possibly shared with hevc (which also has large intra predictors, and they're presumably similar), so if that's the case then maybe performance of the C is slightly more important? not sure, maybe ask michaelni
[10:12] <ubitux> ok :)
[10:12] <ubitux> i'll eventually check how it's done in hevc
[10:17] <zidanne> mailing list didn't help yet. anyone knows a git repo which has fixed point aac* decoder or it's patches?
[10:29] <zidanne> Are there any implementations of integrating opencore-aacdec into ffmpeg? 
[11:35] <cone-734> ffmpeg.git 03Michael Niedermayer 07master:bfbe07670bb0: wavpackenc: simplify "sign = ((sample) < 0) ? 1 : 0;"
[11:35] <cone-734> ffmpeg.git 03Dave Yeo 07master:c3386bd5b4d3: rtpproto: Check for the right feature when reading a sockaddr_in6
[11:35] <cone-734> ffmpeg.git 03Michael Niedermayer 07master:2c959eccc69c: Merge remote-tracking branch 'qatar/master'
[12:07] <michaelni> zidanne, you can just apply the patches from the ML to a matching old version to get fixed point aac if its so important to you
[12:09] <michaelni> zidanne, also check https://github.com/FFmpeg-mips/FFmpeg, there may be some old versions too
[12:09] <zidanne> I see it from the archives and it's not formatted which is hard to get the patches from there in the right way. Is there any other place that keeps the archive with attachments as files?
[12:10] <michaelni> and patches that add support for currently unsupported external decoder libs are welcome!
[12:11] <michaelni> zidanne, there should be mbox files for the ML on the archive page on ffmpeg.org
[12:11] <michaelni> you can download them and use your MUA
[12:37] <zidanne> this is the only content I could find: http://ffmpeg.org/pipermail/ffmpeg-devel/2013-June/144437.html
[12:37] <zidanne> (which is not fixed point aacdec code. but fft)
[12:39] <zidanne> this should also apply (with a configure parameter) to arm builds too, not just mips :|
[12:47] <durandal_1707> well my understanding is that fixed point fft is step for fixed point aacdec
[12:52] <durandal_1707> zidanne: and there are patches from Jun 3 for fixed point aacdec modules
[13:08] <BBB> ubitux: oh btw one more thing, don't forget performance isn't of uttermost importance at this point, we're really just caring about building a working decoder. performance comes only after it works, so getting it working is probably preferrable to any refactoring or anything else (if that helps decisions wrt anything you're doing right now)
[13:08] <ubitux> yeah
[13:08] <BBB> one we have tools to measure realworld performance (e.g. a working decoder and media files as part of a testsuite), we'll care about perf
[13:09] <ubitux> BBB: if i didn't mess anything, the unrolled 32 looks like this: http://pastie.org/8238678
[13:09] <BBB> inter mode bitstream parsing is almost finished, only mv coding is left now
[13:09] <ubitux> and it's likely not the smallest one
[13:09] <ubitux> (so i don't think that's a good idea)
[13:09] <BBB> tis is diagdown_left?
[13:09] <ubitux> yes
[13:09] <nevcairiel> sure is a wall of text
[13:09] <BBB> that's kinda big yes
[13:10] <ubitux> :p
[13:10] <BBB> maybe it's ok for now and we should refactor it to be loopy later
[13:10] <BBB> up to you
[13:10] <BBB> whatever makes it easiest to get a working decoder ;)
[13:10] Action: BBB off to dinner, bbl
[13:10] <ubitux> if it was generated by some random pass i wouldn't mind, but maintaining such thing is not really a cool thing :p
[13:42] <cone-734> ffmpeg.git 03Michael Niedermayer 07master:8ec618826302: ffv1dec: support printing information about the global header
[13:42] <cone-734> ffmpeg.git 03Michael Niedermayer 07master:c387c45e8301: ffv1: fix plane_count at version 1.4
[13:42] <cone-734> ffmpeg.git 03Michael Niedermayer 07master:1a01147d7ae5: avcodec/ffv1enc: fix chroma_plane for rgb/rgba
[13:45] <KGB> 01[13FFV101] 15michaelni pushed 1 new commit to 06master: 02http://git.io/gDqirg
[13:45] <KGB> 13FFV1/06master 147fa692a 15Michael Niedermayer: ffv1: document plane_count...
[15:04] <cone-734> ffmpeg.git 03Michael Niedermayer 07master:23606f27f081: avcodec/ffv1enc: bump minor_version for the chroma_plane fix
[15:47] <cone-734> ffmpeg.git 03Piotr Bandurski 07master:165b65771de9: avformat/riff: add DM4V FourCC
[15:51] <zidanne> I still couldn't figure it out :D sorry. How to extract attachments from these: http://ffmpeg.org/pipermail/ffmpeg-devel/2013-June/144441.html
[19:11] <Daemon404> michaelni, just a heads up: my FATE instances will be gone for 2 weeks
[19:11] <Daemon404> while i move to england
[20:26] <michaelni> Daemon404, ok, thx for the info
[21:39] <cone-498> ffmpeg.git 03Michael Niedermayer 07master:60e9b8556ab3: swscale_unscaled: make dither_scale static, its not used elsewhere and has no prefix
[21:44] <pippin> michaelni: I am not entirely sure dithering and scaling are done in the right order
[21:45] <pippin> michaelni: I had to pre-scale my big buck bunny clip to the target resolution, and then use that video as input - to be able to create the 3 different GIFs, without doing so; it almost seemed like the scaling was done after the dithering
[21:51] <michaelni> dither is done after scaling, maybe you somehow ended up with 2 scalers or maybe theres a bug in the scaled+dither codepath
[21:52] <michaelni> if you have a reproduceale testcase for this problem then please open a ticket on trac 
[21:53] <pippin> mhm, I also notice that if I make the dither very computationally expensive; also the frame before the frames I want encoded are dithered (using -ss and -frames)
[21:59] <pippin> michaelni: unable to reproduce it now; it was before I fully understood the workings of -sws_flags ; likely a pebcak
[21:59] <Daemon404> pippin, out of curiosity, what motivated you to work on sws?
[21:59] <Daemon404> merely curious.
[22:01] <pippin> I was experimenting with dithering with hacked kobo ereaders in mind,.
[22:01] <pippin> the constraints of dithering for eink are similar to dithering for gif, reducing changes between "frames" is desirable
[22:02] <pippin> then I became curious and wondered how GIFs would look like, when piped through the dithering I was hacking on...
[22:02] <Daemon404> ah
[22:03] <pippin> the screen of a kobo mini can be driven at almost 15fps when in "1bpp mode"
[22:04] <pippin> and my image viewer/browser/slideshow thingy for it, also has a GIF decoder in it ;)
[22:07] <Daemon404> sounds like something you'd see at an art show
[22:10] <pippin> I already use that "image viewer" for boarding passes and such; I keep it in the bootproceess before the regular "OS-app" of the device; and can shut_it_down_ with an image visible
[22:10] <pippin> (and it boots back to the same image in <5s ;) )
[22:11] <pippin> with more dithering applied,. the 16 'a bit fuzzy' gray levels, works well for photos
[22:12] <pippin> thus dithering improves both "animated things" (pan/zoom), as well as static display in 4bpp mode
[23:04] <ubitux> nevcairiel: to answer your previous question, gcc doesn't really unroll shit
[23:05] <ubitux> at least not completely
[23:05] <ubitux> it won't unroll a 8x8 loop
[23:20] <ubitux> i might have found a way to unroll a bit better
[23:20] <ubitux> anyway
[23:20] <ubitux> BBB: the "intra" samples from libvpx don't seem to trigger the downleft pred; do you have a sample for that?
[23:26] <ubitux> i'm stupid, the intra sample were vp8 only
[23:26] <ubitux> 'seems most of the vp9 triggers them
[23:28] <ubitux> btw, it crashes a lot since your recent commit(s)
[23:54] <cone-498> ffmpeg.git 03Michael Niedermayer 07master:1e0e193240a8: sws: add dither enum
[23:54] <cone-498> ffmpeg.git 03Michael Niedermayer 07master:6d246f440e46: avfilter/vf_scale: generic swscale option support
[00:00] --- Fri Aug 16 2013