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

[burek]

[00:01] <cone-855> ffmpeg.git 03Piotr Bandurski 07master:1ee1a3d9f4e1: avcodec/gsmdec: reject unsupported msn audio modes
[00:20] <pippin> michaelni: a patch that makes this dithering method a run-time option http://pippin.gimp.org/a_dither/0001-swscale-add-a_dither-dithering-method-for-GIFs.txt
[00:25] <pippin> hm, I spot a mistake - the flag value should probably be quite a bit lower
[00:55] <michaelni> pippin, the code can probably be optimized a bit, its doing quite a bit of stuff per pixel
[00:58] <pippin> the most natural optimizatiob would be to use a lookup-table the size of the framebuffer
[00:59] <pippin> which is what a proper blue noise dither also would need in terms of infrastrucure
[01:00] <pippin> (blue noise dithering, is doing the same thing, but with an expensively pre-computed threshold mask, yielding qualities similar to error-diffusion)
[01:01] <michaelni> also looking at your webpage the dithers have a different color tint / contrast
[01:02] <michaelni> either the existing ones are off or the new one is off
[01:02] <michaelni> whatever is, should be fixed
[01:02] <pippin> or they all are "off" in slightly different ways
[01:03] <pippin> though, for minimizing the average color - error diffusion should in principle be exact when done corectly
[01:05] <michaelni> the equation looks like it would produce a pattern that repeats in 512x512 blocks
[01:06] <Daemon404> while we're on the subject, how would you feel about a random dither using libautil's PRNG, michaelni?
[01:07] <Daemon404> libavutil*
[01:10] <pippin> Daemon404: plain random ends up with more objectionable clusterings of pixels
[01:11] <ubitux> plain random is not good for gif "compression" btw :(
[01:11] <pippin> Daemon404: you can try replacing the case 1: in the code at http://pippin.gimp.org/a_dither/ with "case 1:  return input < Math.random() ?0:1;" and compare with case 2
[01:12] <michaelni> Daemon404, i think we should add whatever is best / has users who want to use it / has usecases. i dont know if that applies to random dither
[01:13] <Daemon404> ubitux, again i dont mean for gif
[01:13] <michaelni> about PRNGs, a good LCG (64bit and discard the LSBs) will look indistinguishable from a perfect one for dither so no need for PRNG from avutil
[01:14] <Daemon404> michaelni, i only thought we'd liek deterministic behavior
[01:14] <michaelni> yes deterministic behavior is preferred
[01:14] <pippin> what I use for deterministic random in GEGL is: https://git.gnome.org/browse/gegl/tree/gegl/gegl-random.c
[01:17] <pippin> which gives a per-pixel random access sequence (with an additional seed)
[01:26] <michaelni> not that it matters for our purpose here but how does this prng perform in the various tests (diehard, u01) ?
[01:28] <michaelni> if i do need a good prng, i tend to use marsaglias kiss99 (one possible implementation of that:http://www.ffmpeg.org/~michael/git/noe/random_internal.h)
[02:26] <pippin> michaelni: no idea; I have only done perceptual evaluations of it
[02:27] <pippin> though I would imagine it to work well; if the initial random data it is seeded with is of good quality
[03:04] <cone-197> ffmpeg.git 03Michael Niedermayer 07master:640a36a05c4d: ffmpeg_filter: check that the input media type match the filter
[10:17] <cone-988> ffmpeg.git 03Luca Barbato 07master:aae159a7cc4d: nuv: Do not ignore lzo decompression failures
[10:17] <cone-988> ffmpeg.git 03Michael Niedermayer 07master:7ec7d626a121: Merge commit 'aae159a7cc4df7d0521901022b778c9da251c24e'
[10:44] <cone-988> ffmpeg.git 03Luca Barbato 07master:075dbc185521: nuv: Pad the lzo outbuf
[10:44] <cone-988> ffmpeg.git 03Michael Niedermayer 07master:86fe16a763ab: Merge commit '075dbc185521f193c98b896cd63be3ec2613df5d'
[10:54] <cone-988> ffmpeg.git 03Luca Barbato 07master:feaaf5f7f0af: nuv: Reset the frame on resize
[10:55] <cone-988> ffmpeg.git 03Michael Niedermayer 07master:1dee467d262d: Merge commit 'feaaf5f7f0afac7223457f871af2ec9b99eb6cc6'
[11:09] <zidanne> I wish ffmpeg was not converted to output FLTP instead of S16. Reason: When it was S16, ARM devices without VFP was working smoothly. After the FLTP change, ARM devices require VFP otherwise library becomes unusable because of the floating point operations :-/
[11:10] <nevcairiel> the decoder internally always used floating point, it just converted to S16 before output
[11:10] <nevcairiel> which is why the switch made so much sense, directly output the internal format except converting it everytime
[11:11] <nevcairiel> some decoders have fixed point alternatives, like mp3
[11:11] <zidanne> that is strange because codecs those accepting S16 as requested format works smoothly on devices without VFP but not the same for FLTP to S16 (swr_convert -ed codecs)
[11:12] <zidanne> I think "mp3" (as you've noted) is one of those accept S16 as the requested format.
[11:51] <cone-988> ffmpeg.git 03Luca Barbato 07master:2df0776c2293: nuv: Use av_fast_realloc
[11:51] <cone-988> ffmpeg.git 03Michael Niedermayer 07master:8da4305eb520: Merge commit '2df0776c2293efb0ac12c003843ce19332342e01'
[11:55] <cone-988> ffmpeg.git 03Luca Barbato 07master:62cc7a910801: rtjpeg: return meaningful error codes
[11:55] <cone-988> ffmpeg.git 03Michael Niedermayer 07master:d12bc01ec55a: Merge commit '62cc7a91080194d9ead162516f779f20931220d9'
[12:03] <cone-988> ffmpeg.git 03Luca Barbato 07master:f13fe6020e6a: rtjpeg: Use init_get_bits8
[12:03] <cone-988> ffmpeg.git 03Michael Niedermayer 07master:2bac839bd3c3: Merge commit 'f13fe6020e6a3871f9b0c96b240e58e6ed4fb5d7'
[12:22] <cone-988> ffmpeg.git 03Luca Barbato 07master:3562684db716: ogg: Always alloc the private context in vorbis_header
[12:22] <cone-988> ffmpeg.git 03Michael Niedermayer 07master:070c22d53a2b: Merge commit '3562684db716d11de0b0dcc52748e9cd90d68132'
[12:30] <cone-988> ffmpeg.git 03Luca Barbato 07master:5268bd2900ef: segafilm: Error out on impossible packet size
[12:30] <cone-988> ffmpeg.git 03Michael Niedermayer 07master:ab06436dbff5: Merge commit '5268bd2900effa59b51e0fede61aacde5e2f0b95'
[12:35] <cone-988> ffmpeg.git 03Martin Storsjö 07master:2427ac6ccd86: rtpproto: Update the parameter documentation
[12:35] <cone-988> ffmpeg.git 03Michael Niedermayer 07master:1a01f367a40f: Merge commit '2427ac6ccd868811d1fe9df7c64c50ca58abe6f6'
[12:42] <cone-988> ffmpeg.git 03Martin Storsjö 07master:6b58e11a8331: rtpproto: Add an option for writing return packets to the address of the last received packets
[12:42] <cone-988> ffmpeg.git 03Michael Niedermayer 07master:2425be894a52: Merge commit '6b58e11a8331690ec32e9869db89ae10c54614e9'
[12:48] <kurosu_> zidanne: AAC and AC3 have a fixed-point implementation, recently updated by MIPS iirc
[12:49] <kurosu_> I think you need to manually specify you want the FP decoder rather than the float one
[12:52] <cone-988> ffmpeg.git 03Martin Storsjö 07master:b56fc18b20d6: sdp: Add an option for sending RTCP packets to the source of the last packets
[12:52] <cone-988> ffmpeg.git 03Michael Niedermayer 07master:20904518e98b: Merge remote-tracking branch 'qatar/master'
[12:55] <zidanne> kurosu_: would you mind giving more hint about this? How can shall I manually specify? (the name of the fixed point decoder, etc..)
[12:58] <kurosu_> sorry, I don't remember, maybe -acodec
[12:58] <kurosu_> zidanne: I think this is in the documentation
[14:21] <pippin> michaelni: updated patch ( http://pippin.gimp.org/a_dither/0001-swscale-add-a_dither-dithering-method-for-GIFs.txt ) and sample, based on measurments - I was trying to evade too much noise; this trims down the size of the code as well.
[14:25] <pippin> (the measurements were of the actual tone reproduction curve / gamma of the half-toning method)
[14:25] <pippin> this improves the color reproduction
[14:33] <michaelni> pippin, i suggest instead of using flags, a enum dither should be added to the context otherwise not only will we run out of flags we also have ambigous cases where multiple dithers are enabled
[14:35] <michaelni> and please use something longer than 1 letter to identify the dither unless thats really supposed to be its name and is uniquely identifying it
[14:36] <pippin> it is the name I have chosen for the method; though - painful as it is; that is just one of the 2 (or 4) variations I've ended up playing with out of many more permutations...
[14:38] <michaelni> lets hope no other human on the planet will pick the first letter of the alphabet to identify their dither algorithm then ;)
[14:38] <pippin> it is worse it is "a dither" it isn't "a"
[14:39] <nevcairiel> the name is really quite .. bad. :) "a dither" could also simply be the english "a", describing "one" dither
[14:39] <nevcairiel> you should invent a new name :D
[14:40] <pippin> nevcairiel: be careful now,..
[14:41] <nevcairiel> i dont care for careful
[14:41] <nevcairiel> its boring
[14:41] <pippin> http://pippin.gimp.org/git/cairo/log/ <- that is what I named a cairo "backend", pronounced "circle" - in english
[14:43] <michaelni> isrgb8?4:4
[14:43] <michaelni> and " (A_DITHER (i+67,y)   - 128) / (isrgb8?4:4);" does 2 shifts which could be changed to 1
[14:43] <pippin> I'd be disappointed in a compiler not catching that one
[14:44] <pippin> (the isrgb8?foo:foo) one
[14:44] <nevcairiel> of course it does, still can be cleaned up in the code
[14:45] <pippin> not doing it, makes the code align with the line above and below
[14:45] <michaelni> also the / (2^x) should probably be >>x, the compiler will optimize that one but with signed numbers rounding differs so it will need extra code
[14:45] <nevcairiel> nonsene code for alignment? o.O
[14:46] <pippin> I'm not going to defend it hard; it is an artifact from me initially not caring about the !PAL8 case, and then mechanically transforming the code
[14:49] <pippin> will provide a new patch in some minutes; going afk for some mins first
[14:51] <kierank> pippin: is your nick named after the dog pippin?
[14:52] <kierank> durandal_1707: are you going to asterix?
[15:03] Action: michaelni afk
[15:09] <durandal_1707> kierank: you want to hire bodyguards?
[15:11] <kierank> durandal_1707: no
[15:12] <kierank> It's michaelni that wants bodyguards afaik
[15:13] <av500> what good are bodyguards that you dont hire yourself
[15:13] <pippin> hm, unifying the two shifts; ends up obfuscating the logic of the algorithm with more obscure shifting amounts
[15:15] <pippin> obfuscated - in that the numbers make sense in the wrong way; and if the method is reused for rgb565 16bpp naively - the results would be wrong
[15:22] <durandal_1707> kierank: i'm big, strong and fast
[15:23] <kierank> I don't plan to fight you or anyone else
[15:27] <wm4> durandal_1707 is an important tactical advantage in the expected deathmatch between ffmpeg and libav devs
[15:29] <av500> thats gonna be fun
[15:55] <Compn> wm4 : two projects enter, one project leaves
[15:56] <Compn> deathmatch of awkwardness
[16:00] <kurosu_> pippin / michaelni: I propose yadith as the name of that yet another dither algorithm
[16:01] Action: durandal_1707 ugh
[16:09] <cone-988> ffmpeg.git 03Paul B Mahol 07master:93f4277714ff: WavPack encoder
[16:09] <pippin> r9
[16:17] <pippin> michaelni: http://pippin.gimp.org/a_dither/0001-swscale-add-a_dither-dithering-method-for-GIFs.txt <- that is how it looks optimized for speed playing manual compiler, taking all the trinary operators out of it
[16:33] <zidanne> I couldn't find fixed point arc decoder, there is only fixed point encoder?
[16:33] <zidanne> *arc= aac
[16:33] <michaelni> pippin, when calculating pixels from left to right A_DITHER(i,y) ; A_DITHER(i + 67,y); ... calcukate the same values 3 times
[16:35] <pippin> michaelni: yes
[16:35] <durandal_1707> zidanne: native aac encoder is not fixed point
[16:35] <pippin> but any compiler worth its salt has common subexpression elimination, and I'v even taken loads of conditionals out of the inner loop...
[16:36] Action: pippin leaves any further tweaks to ffmpeg devs - especially touching enums vs flag differences :)
[16:37] <durandal_1707> but ffmpeg compiles on bunch of worthless compilers
[16:37] <michaelni> pipin ive not yet seen gcc create a ring buffer to save and reuse sub expressions
[16:37] <zidanne> so, I am mixing things.. I must stop drinking bear while coding 8-|. I need fixed point aac decoder because armv6 devices without VFP can't handle smooth streaming
[16:37] <zidanne> beer (:
[16:38] <pippin> michaelni: if you that is the part you are referring to; then you are willing to optimize this PAL8 thing much further than I am ;)
[16:39] <pippin> (the part where it recomputes the same value after >60 pixels)
[16:39] <pippin> using a full 512x512 lookup-table would be better then, for anything but micro-controllers
[16:39] <michaelni> i dont mind a 512x512 LUT if that happens to be faster
[16:40] <michaelni> but it seems a bit big to me
[16:40] <pippin> I'd guess it to be faster by ~10-15%  of the overhead over doing just shifting
[16:41] <pippin> (based on measurements of whether this was few enough instructions to beat a LUT, it is not)
[16:42] <zidanne> should I use libfaad for fixed point aacp decoding?
[16:43] Action: pippin needs to stop dithering and focus on some font code instead :)
[16:43] <michaelni> zidanne, look at the ML there are some patches for a aac fixed oint decoder
[16:44] <michaelni> zidanne, if you test it please post your benchmark results
[16:44] <zidanne> shame on me; what is ML?
[16:44] <michaelni> mailing list
[16:44] <michaelni> ffmpeg-devel
[16:45] <pippin> btw, I have a hunch about what the wrongly encoded GIFs I've seen is
[16:45] <pippin> I don't think GIF deals with more than 254 unique colors when used for animation...
[16:46] <pippin> unless one start mucking with per frame color maps
[16:46] <zidanne> michaelni: http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2013-June/144864.html
[16:48] <zidanne> I couldn't get attachments from archives
[16:48] <michaelni> pippin, btw how does your dither compare to the other 2 ? (for example in terms of gif compression)
[16:50] <michaelni> zidanne, try a message that contains a patch
[16:51] <pippin> michaelni: on the bunny clip I've used, with bayer as a baseline: bayer 100% (2.2mb) a-dither: 127% (2.8mb) error-diffusion: 300% (6.6mb)
[16:52] <pippin> the reason error-diffusion loses out is that it keeps changing all pixels all the time, making huge delta frames
[16:52] <michaelni> so what makes a-dither better than bayer ?
[16:53] <pippin> many more dithered gray-levels, and less apparent patterning
[16:53] <pippin> both bayer and a-dither are positionally stable
[16:53] <pippin> s/gray-levels/colors/
[16:53] <michaelni> did you try cluster & void dither ?
[16:53] <michaelni> its also positionally stable
[16:54] <pippin> cluster and void, are those other names for blue and green noise?
[16:58] <michaelni> i suspect, no
[17:00] <pippin> void and cluster is blue noise
[17:01] <pippin> no, I haven't tried it - might end up implementing it later for GEGL/GIMP, a dither is enough for my eink needs
[17:02] <pippin> "implement it" stated loosely;,. more preceisely implementing something more like blue/green noise LUT masks, rather than using a-dither which is a procedural such threshold mask
[17:03] <pippin> the core working mechanism is exactly the same for this and that method though, in the live js web example I use the comparison with the threshold mask instead of mixin it in as noise like this when doing multiple levels
[17:10] <michaelni> void and cluster might produce a blue noise like spectrum but iam not sure this is true the other way around, id have to find and read some paper
[17:29] <zidanne> I couldn't find Fixed Point AAC decoder files. So I will try to exclude armv6 devices those do not have VFP. :
[17:29] <zidanne> :/
[17:36] <michaelni> zidanne, you could post in the thread and ask the mips devels if they have a git repo with the patches applied
[17:37] <michaelni> it probably makes sense for other people too if that can simply be checked out instead of applying multiple patches from the ML
[17:37] <michaelni> pippin, see "FFmpeg devel (7.2K) [FFmpeg-devel] [PATCH] sws: add dither enum"
[17:37] <michaelni> review/comments welcome
[17:55] <pippin> michaelni: I think you'd want to check on something other than error_diffusion in utils
[17:56] <pippin> michaelni: since that is another location where I had to hook in when adding a-dither
[18:03] <XwZ> hi, i have a problem, I try to use ffmpeg API in VS2010, I add the libs but I still have an error :
[18:03] <XwZ> Error3error LNK2019: unresolved external symbol "int __cdecl avcodec_decode_video2(struct AVCodecContext *,struct AVFrame *,int *,struct AVPacket const *)" (?avcodec_decode_video2@@YAHPAUAVCodecContext@@PAUAVFrame@@PAHPBUAVPacket@@@Z) referenced in function "public: void __thiscall rtspPlayerObject::startCapture(void)" (?startCapture at rtspPlayerObject@@QAEXXZ)
[18:03] <XwZ> I've downloaded the binaries from ffmpeg.zeranoe.com
[18:04] <XwZ> do you have an idea ? I link all the libs I have in the folder
[18:04] <cptspiff> calling convention..
[18:05] <XwZ> is it possible to fix it ? 'cause for avformat_open_input i have no problem
[18:05] <Daemon404> ... you need lbavcodec
[18:05] <Daemon404> libavcodec*
[18:06] <XwZ> I have it, in the linker's settings I have : avcodec.lib avdevice.lib avfilter.lib avformat.lib avutil.lib postproc.lib swresample.lib swscale.lib
[18:12] <XwZ> I just tried using #pragma comment, but still the same error
[18:12] <nevcairiel> you need to set C linkage around the header imports
[18:13] <nevcairiel> ie: extern "C" {\n #import "libavcodec/avcodec.h" \n}
[18:13] <XwZ> i did it
[18:14] <cptspiff> ehrr, that's what i meant, not calling convention, sorry. saw cdecl vs thiscall and brain farted.
[18:14] <XwZ> oups may be I missed one
[18:14] <XwZ> it's linking !
[18:15] <XwZ> thank you
[18:18] <Daemon404> "import" ?
[18:19] <JEEB> someone writing too much objc? 8)
[18:19] <nevcairiel> he got the idea
[18:20] <nevcairiel> also, java
[18:32] <JEEB> nevcairiel, I hope it's at least java7 :)
[18:42] <XwZ> I have a crash on "avformat_open_input", I try to open an rtsp stream but but I reach this function, I have an error about memory and the debugger says that the problem is out of my own code like QWidget class or _unlock function ... do I need to do something particular ? I have : avformat_open_input(&pFormatCtx, "rtsp://192.168.1.17/h264", NULL, 0); and pFormatCtx is defined like this : AVFormatContext
[18:42] <XwZ> *pFormatCtx;
[19:13] <pippin> michaelni: cause of corrupted GIF encoding detected; gif.c does not deal correctly with frames with no change, encode a sequence of the same frame to reproduce
[19:19] <cone-505> ffmpeg.git 03Michael Niedermayer 07master:dabfa80ce27f: avcodec/mjpegdec: print a message when there was just a single field and no frame
[19:30] <michaelni> pippin, i tried to encode lena.pnm as 6 images in a gif, the file plays fine with ffplay thogh, how do i reproduce it ?
[19:31] <pippin> play it with mplayer, or try to open it in gimp
[19:32] <pippin> if frames that end up having  1x1 difference in the lower right are not written to the stream; those decoders no longer complain
[19:33] <pippin> (at least one web browser I tested in loops at the wrongly encoded no-diff frame)
[19:38] <pippin> michaelni: (here gimp prints a warning and continues; mplayer prints a warning as well as quits)
[19:41] <durandal_1707> michaelni: for such trivial stuf you do not need review
[19:42] <michaelni> durandal_1707, i just didnt want to step on anyones toes by doing such simplifications without asking
[19:43] <michaelni> also you might want to add yourself to maintainers for wavpackenc
[20:01] -:#ffmpeg-devel- [freenode-info] channel flooding and no channel staff around to help? Please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
[21:59] <zidanne> XwZ: use a debug build without stripping enabled.
[22:15] <cone-505> ffmpeg.git 03Alexander Strasser 07master:dc2e4c2e532b: lavf/wavdec: Fix seeking in files with unaligned offsets
[23:20] <cone-505> ffmpeg.git 03Michael Niedermayer 07master:5dd5985e0530: avcodec/gif: move BITSTREAM_WRITER_LE up
[23:20] <cone-505> ffmpeg.git 03Michael Niedermayer 07master:b4e2e0370999: avcodec/lzwenc: Add 1 additional bit of padding for gif
[23:20] <cone-505> ffmpeg.git 03Michael Niedermayer 07master:796b20fa1cef: avcodec/gif: use the whole allocated buffer
[23:20] <cone-505> ffmpeg.git 03Michael Niedermayer 07master:1a53ddd9a295: avcodec/lzwenc: change asserts to av_asserts
[23:26] <michaelni> pippin, the gif "corruption" should be fixed
[23:38] <durandal_1707> was that lzw change really required?
[23:38] <durandal_1707> it could be gimp bug
[23:54] <pippin> durandal_1707: then it is an mplayer, chromium and firefox bug as well
[23:54] Action: pippin has decided to label durandal_1707 mr-stop-energy ;]
[23:55] <durandal_1707> haha, no i prefer real solutions and not hacks
[23:56] <pippin> durandal_1707: considering your complains stop-energy is my real solution ;)
[23:58] <pippin> michaelni: and yep - none of the 4 decoding engines that had hickups have them now
[23:59] <durandal_1707> pippin: hmm, what specific complaining?
[00:00] --- Thu Aug 15 2013