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

[burek]

[00:00] <j-b> saste: so, it is not hard
[00:00] <j-b> but difficult to get right
[00:01] <saste> j-b: what's your current status with regards to that? why wasn't it never completed (in case it isn't yet committed in master)?
[00:03] <j-b> it works
[00:03] <j-b> nobody seems to give a shit
[00:05] <saste> j-b, just push it, so people can use it, and fix it if they care
[00:05] <j-b> maybe
[00:08] <Daemon404> i dunno
[00:09] <Daemon404> vlc generally prefers things that work
[00:09] <Daemon404> afaik
[00:14] <Compn> chinese qmv? oh no
[01:22] <kierank> Nevcairiel: what kind of close control do you want
[01:31] <ubitux> matthewjheaney_: what's broken about webvtt ts parsing?
[01:31] <ubitux> just missing the !milliseconds case?
[01:32] <ubitux> ah and seconds only i guess mmh
[01:46] <cone-14> ffmpeg.git 03Alexandre Sicard 07master:b1d61eb7aaae: avformat/mov: ignore samples overflowing next_root_atom
[01:51] <matthewjheaney> Actually, I just rechecked the parsing rules in the webvtt spec and it seems that only hours are optional; both minutes and milliseconds are apparently required.  The timestamp parser in libwebm is more permissive about input syntax than what is enunciated in webvtt spec.  "Be liberal about reading inputs and conservative about writing outputs" and all that.  Writing all components is probably best.
[01:54] <cone-14> ffmpeg.git 03Michael Niedermayer 07release/1.2:376a9f8e6e36: avcodec/utils: Fix encoder allocation size
[01:56] <ubitux> i don't remember the specs, and it probably changed since when i implemented it
[01:56] <ubitux> feel free to update the code
[01:56] <ubitux> i'll review your patches in a day or two, i'm slightly busy currently
[02:11] <cone-14> ffmpeg.git 03James Almer 07master:82ef67016ef7: lavu/hmac: Add support for SHA-2
[02:11] <cone-14> ffmpeg.git 03James Almer 07master:1163910a0059: fate: Add test vectors for HMAC SHA and SHA-2
[03:06] <llogan> looks like the qvodplayer may use ffmpeg libraries. (ticket 2662)
[10:14] <khali> I see that each filter option has a description string
[10:14] <khali> but I can't see how the user can retrieve it?
[10:27] <khali> Do I need to subscribe to the ffmpeg-devel list before I can post to it?
[10:28] <ubitux> ffmpeg -g filter=foobar
[10:28] <ubitux> -h*
[10:28] <ubitux> ffmpeg -h filter=foobar
[10:28] <ubitux> or -h full
[10:28] <nevcairiel> not necessarily, but its easier to communicate if you're subscribed, or you may not get the responses :P
[10:30] <khali> nevcairiel: well I don't know how much traffic there is on that list, but I'll only contribute a few patches
[10:31] <khali> so even if I subscribe I planned to disable message delivery
[10:31] <khali> ubitux: ah, that must be a new feature, didn't work on 1.0.6
[10:31] <khali> ubitux: thanks
[10:31] <ubitux> 1.0 wow
[10:32] <ubitux> you took your time machine?
[10:32] <ubitux> if you send a patch, make sure it's based on git master :p
[10:32] <khali> ubitux: sure
[10:32] <khali> ubitux: 1.0.6 is the packages ffmpeg in openSUSE
[10:32] <ubitux> ok :)
[10:32] <khali> I have the git version installed somewhere else
[10:33] <khali> and my encoding scripts use the git version
[10:33] <ubitux> (note: you don't need to "install" it)
[10:33] <khali> I'm fine installing it, /opt is there for that exactly
[10:34] <khali> ubitux: when you reply on ffmpeg-devel, do you reply to the list only, or also to the original poster?
[10:35] <ubitux> i hit 'r' like an autist, so i reply to the list only  :)
[10:35] <ubitux> but i can do the effort to make a proper reply with you in copy if necessary
[10:35] <ubitux> (not sure i will think of doing that everytime)
[10:36] <ubitux> also, if you're not subscribed you'll have to wait for moderation
[10:36] <ubitux> can take a few hours (days?)
[10:36] <khali> ubitux: I will subscribe, the question was if I can disable list traffic for my address, or rather not
[10:37] <khali> ubitux: if you're an R-maniac I will leave list traffic enabled ;) don't want to make your life harder
[10:37] <ubitux> if you're subscribed you're condemned to contribute to FFmpeg for eternity
[10:37] <ubitux> sorry
[10:38] <khali> seems I have been subscribed to ffmpeg-user at some point in time, but... "List-Id" matchcase "ffmpeg-devel.mplayerhq.hu", I guess that no longer works
[10:38] <khali> ubitux: this is seriously tempting
[10:38] <ubitux> mmh it should be the same server, but i don't know the dns details
[10:39] <ubitux> ffmpeg-devel at ffmpeg.org should be safer
[10:39] <khali> ubitux: whenever I look at video filter code, I see things that could be fixed or improved
[10:39] <ubitux> contributions welcome :)
[10:39] <khali> ubitux: the only issue is that my employer doesn't actually pay me to work on ffmpeg...
[10:40] <khali> and if I only do it on my "spare time", well I don't actually have spare time, so that would be 0
[10:40] <ubitux> then you work on ffmpeg on your work time and get paid for something else
[10:41] <ubitux> you just need to estimate 1 week of work for 20 minutes of actual work
[10:42] <khali> aha, I am already subscribed :)
[10:46] <khali> oh, I thought that would be my first contribution to ffmpeg but it turns out I already contributed two minor fixes to V4L2 support 5 years ago
[10:47] <khali> anyway, let me send a first patch for this decade
[10:49] <khali> patch sent, let me know if I did anything wrong
[10:49] <khali> I'll send the delogo patches later
[10:53] <ubitux> khali: can you send a git formatted patch? (git format-patch -1) or use git send-email?
[10:54] <ubitux> (that's easier to apply)
[11:08] <khali> ubitux: I'm afraid it will be difficult given that I don't use git :/
[11:09] <ubitux> why don't you?
[11:09] <khali> ubitux: I always use quilt when working on patches
[11:09] <khali> ubitux: if you tell me what you're missing in the format I send, I may be able to tell quilt to do the same
[11:10] <ubitux> well, it seems git is able to eat it so i guess that's ok :)
[11:16] <khali> ubitux: OK
[11:16] <khali> ubitux: FWIW nobody ever complained about the patches I send so I suppose they aren't too bad
[11:18] <ubitux> khali: you're in the multimedia community, we like to complain a lot for nothing
[11:34] <iive> ubitux: afaik khali is kernel developer and they are quite strict toward patches :P
[11:34] <iive> at least the famous ones.
[11:39] <khali> correct ;)
[12:16] <cone-900> ffmpeg.git 03Kostya Shishkov 07master:767ae86ceeae: g2meet: reset dimensions on header parsing errors
[12:16] <cone-900> ffmpeg.git 03Kostya Shishkov 07master:4d960d7f60f9: g2meet: more graceful cursor loading
[12:16] <cone-900> ffmpeg.git 03Kostya Shishkov 07master:7dfc3381dd03: g2meet: do not leak buffers
[12:16] <cone-900> ffmpeg.git 03Michael Niedermayer 07master:d3c4ea8b35f7: Merge remote-tracking branch 'qatar/master'
[12:54] <ubitux> khali: btw, no need to resend a patch now, but your patch will require a micro bump in lavfi/version.h
[13:00] <Compn> he didnt read all of the patch submission guidelines!? gasp!
[13:00] <Compn> :P
[13:12] <khali> ubitux: I was wondering about that
[13:13] <khali> ubitux: but I thought it was somehow automated so that different persons can send their patches without a collision
[13:15] <khali> ubitux: but if you want me to update version.h in my future patches, I'll do that
[13:15] <khali> Compn: I did not realize there was such a document, thanks for pointing it out, reading it now
[13:15] <khali> oh, I was supposed to Sign-off my patch as well
[13:16] <khali> I didn't know this kernel dev habit had leaked into ffmpeg :)
[13:19] <khali> "Is the patch attached to the email you send? " <- does this mean you prefer patches attached rather than inline?
[13:23] <khali> oh, I suppose I should configure with --cpu= for my local builds, so that ffmpeg is faster?
[13:27] <khali> ... if I can find a list of cpu options
[13:33] <ubitux> khali: no it's not automated; if you have an idea on how to do that i would be curious
[13:34] <ubitux> sign-off is not mandatory but you can as well
[13:36] <ubitux> < khali> "Is the patch attached to the email you send? " <- does this mean you prefer patches attached rather than inline? // nope, inline is definitely prefered
[13:37] <ubitux> it's just a reminder for "hey here is a patch" "oups i forgot to attach the patch"
[13:37] <iive> ubitux: it is now? geh, i've been away for quite a while. ;)
[13:38] <ubitux> iive: well if you want to do some review inline is way better
[13:38] <ubitux> as long as it's not wrapped/mangled by your mailer
[13:38] <iive> attaching patch is safer, mailer won't mangle it. and because kernel prefers inline they have a lot stricter guidelines what mail applications you can use.
[13:39] <ubitux> i "attach" my patches, but afaik they're inlined
[13:39] <iive> no, the mailer opens text mime types 
[13:40] <ubitux> mmh, so when i see the patch as attachement, it's just that the mime type is badly set by the sender?
[13:41] <iive> sometimes.
[13:41] <iive> inline patch is what git-format-patch creates.
[13:42] <ubitux> git send-email you mean?
[13:42] <iive> that sends it too, afair
[13:43] <khali> I'mc curious if --cpu=corei7 will make a visible performance change
[13:43] <ubitux> isn't "native" more appropriate?
[13:43] Action: ubitux never used --cpu
[13:44] <kierank> doubt it makes much difference
[13:44] <iive> khali: if the neutral have been i486, then cmov would give at least 5% improvement.
[13:44] <iive> most of the critical code is hand written assembler, so just make sure you have yasm/nasm
[13:46] <khali> iive: yes I have both installed
[13:47] <khali> ubitux: I didn't know about "native"
[13:47] <khali> ubitux: the gcc man page says native may be silently ignored so...
[13:48] <ubitux> oh you certainly should not trust me on that stuff
[13:48] <ubitux> that was an innocent question
[13:49] <ubitux> i just wonder if it makes any sense to use something else than --cpu=native if you're not cross compiling
[13:56] <iive> i think the silently ignoring of native is about the cases where the cpu cannot be identified. some of the more obscure variants like via c3 may suffer.
[14:00] <khali> kierank, iive, ubitux: I suppose most time is spent in the encoding libraries, so the compilation optimizations of ffmpeg itself must have a low impact on performance
[14:00] <khali> unless using many filters maybe
[14:02] <ubitux> we don't have much asm optim in filters (patches welcome!), so it might be interesting to test
[14:07] <khali> optimizing the C code would be a start...
[14:07] <ubitux> :)
[15:10] <khali> conclusion: --cpu=corei7 did not make any difference for me, using only external encoders
[15:12] <durandal_1707> for what?
[15:15] <nevcairiel> those differens are minimal at best anyway
[15:15] <nevcairiel> differences*
[15:22] <nevcairiel> i should measure the difference on my system one day for the internal decoders, but i doubt its going to be worthwhile
[15:48] <Compn> those cpu options should probably only affect internal stuff anyways
[15:48] <Compn> since you are using pre-compiled external encoders anyhow ?
[15:49] <Compn> and ffmpeg wouldnt compile external libs anyhow
[15:49] <Compn> mplayer does it for ffmpeg, but thats mplayer :D
[15:57] <khali> Compn: that's pretty much what I wrote 2 hours ago... <khali> kierank, iive, ubitux: I suppose most time is spent in the encoding libraries, so the compilation optimizations of ffmpeg itself must have a low impact on performance
[15:58] <khali> Compn: so the bottom line is, we agree :)
[15:58] <ubitux> you should compare with appropriate stuff such as filters, but who cares about such optim anyway :p
[15:58] <ubitux> i doubt it will make some filters suddenly fast
[15:58] <ubitux> khali: what are your other pending patches btw?
[16:00] <Compn> khali : well , ffmpeg has its own 'encoding libraries' , so your theory on compilation options might not be correct. as you never tested your theory.
[16:01] <Compn> but i'm splitting hairs and theories and scientific methods so whatever
[16:01] Action: Compn throws a scientific method at ubitux
[16:07] <iive> khali: no , we do agree ;)  btw, x264 may have -cpu like option too :) but it also uses yasm/nasm for speed critical stuff.
[16:08] <JEEB> trying to -march=native with most such apps is a rather useless experience :)
[16:16] <khali> doh, my code overflows despite the use of uint64_t
[16:16] <khali> I must be missing casts somewhere
[16:16] <khali> ubitux: my remaining 3 patches are for video filter "delogo"
[16:17] <khali> ubitux: but I am doing some extreme case testing to make sure the code is robust enough... and it is not yet :/
[16:29] <cone-900> ffmpeg.git 03Michael Niedermayer 07master:8aea2f05dc56: alacenc: Fix missing sign_extend()
[17:39] <saste> i'll have to simplify rotate a bit...
[18:55] <Daemon404> ubitux, looks like vf_fps works like i want out of the box
[18:55] <Daemon404> \o/
[18:56] <durandal11707> why not use vapoursynth?
[19:05] <Compn> or LAV FILTERS
[19:06] <Compn> or mpv2 herpes edition
[19:06] <Compn> oh i'm thinking hpv nevermind
[19:34] <durandal11707> huh i have warning that ffmpeg built have library configuarion mismatch, but its static build ...
[20:38] <thegeek> are there any plans for a new release soon?
[20:38] <ubitux> 'would be nice
[20:39] <ubitux> but i think it would be wise to fix the few regressions we have first
[20:41] <thegeek> ;P
[20:42] <ubitux> michaelni: what would be a sane qp max ?
[20:42] <ubitux> 64 ? 128 ?
[20:42] <ubitux> (spp)
[21:05] <ubitux> hehe reimar working on matrixview
[21:05] <durandal11707> LOL
[21:06] <ubitux>  libavcodec/on2avcdata.c | 7104 +++++++++++++++++++++++++++++++++++++++++++++++
[21:06] <ubitux> erk.
[21:08] <nevcairiel> on2avc is basically a cheap copy of aac, so take a whole aac decoder and mash it into one file, you get that =)
[21:08] <JEEB> :D
[21:09] <durandal11707> but does aac have that many tables too?
[21:33] <Daemon404> durandal11707, we genrate some at runtme iirc
[21:33] <Daemon404> or at compile time
[23:34] <michaelni> ubitux, 128 sounds ok
[23:53] <cone-900> ffmpeg.git 03Timothy Gu 07master:0ec65aa1046a: doc/encoders: Add libvo-amrwbenc doc
[00:00] --- Thu Jun 13 2013