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

[burek]

[00:02] <iive> ubitux: madoka?
[00:02] <ubitux> ah yeah, madoka was nice :)
[00:03] <ubitux> epic stuff, i like that :p
[00:03] <Daemon404> usagi drop kinda... bored me
[00:03] <ubitux> i guess it requires particular sensibility to some stuff, like a few bunch of animes
[00:04] <iive> slice of life.
[00:04] <ubitux> well, that's a bit more that just a slice of life
[00:04] <ubitux> there is a "maturing character" theme somehow
[00:04] <ubitux> or at least "changing"
[00:04] <ubitux> that kind of stuff is pretty interesting i think
[00:04] <Daemon404> coming of age?
[00:05] <ubitux> mmh?
[00:06] <iive> ever seen "NieA Under 7" ?
[00:06] <ubitux> yes
[00:06] <ubitux> while i really love the artwork, op and stuff
[00:07] <ubitux> the niea character was pretty anoying
[00:07] <ubitux> i prefered haibane for instance
[00:07] <ubitux> haibane renmei*
[00:07] <iive> i know what you mean :)
[00:08] <ubitux> the last eps were really outstanding
[00:08] <ubitux> and the graphics and ambiant are awesome imo
[00:08] <iive> and the story.
[00:08] <ubitux> sure, ’ last 3 eps :)
[00:08] <ubitux> the concept is nice :p
[00:09] <iive> nah... the whole story.
[00:09] <ubitux> :)
[00:13] <cbsrobot> ubitux: an #ffmpeg someone is struggeling with subtitles
[00:14] <cbsrobot> does srt -> dvdsub work ?
[00:15] <ubitux> replied
[02:05] <cbsrobot> On an order from Russian Prime Minister and presidential candidate Vladimir Putin, web cameras have been installed at 91,000 of Russia's 96,000 polling stations in order to guarantee transparency for the vote. WHAT ?
[02:06] <cbsrobot> who's streaming these ?
[02:09] <cbsrobot> ah I see: http://en.ria.ru/russia/20120305/171734960.html
[02:25] <pasteeater> cbsrobot: do they have "yakety sax" as the soundtrack?
[03:32] <pasteeater> anyone mess with blackdetect yet?
[06:15] <CIA-17> ffmpeg: 03Anton Khirnov 07master * r52b0943f10 10ffmpeg/libavformat/utils.c: lavf: factorize freeing a packet buffer.
[06:16] <CIA-17> ffmpeg: 03Diego Biurrun 07master * r0a41f47dc1 10ffmpeg/libavformat/dv.c: dv: Do not redundantly initialize struct members to zero.
[06:16] <CIA-17> ffmpeg: 03Mans Rullgard 07master * r356ee8d7de 10ffmpeg/libavcodec/x86/dsputil_mmx.c: 
[06:16] <CIA-17> ffmpeg: x86: clean up ff_dsputil_init_mmx()
[06:16] <CIA-17> ffmpeg: This splits ff_dsputil_init_mmx() into multiple functions, one for
[06:16] <CIA-17> ffmpeg: each MMX/SSE level, somewhat simplifying the nested conditions.
[06:16] <CIA-17> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[06:16] <CIA-17> ffmpeg: Signed-off-by: Diego Biurrun <diego at biurrun.de>
[06:16] <CIA-17> ffmpeg: 03Fabian Greffrath 07master * rc9dbac36ad 10ffmpeg/libavcodec/srtdec.c: 
[06:16] <CIA-17> ffmpeg: Fix format string vulnerability detected by -Wformat-security.
[06:16] <CIA-17> ffmpeg: Signed-off-by: Diego Biurrun <diego at biurrun.de>
[06:16] <CIA-17> ffmpeg: 03Anton Khirnov 07master * rdcee811505 10ffmpeg/libavformat/utils.c: 
[06:16] <CIA-17> ffmpeg: lavf: make read_from_packet_buffer() more flexible.
[06:16] <CIA-17> ffmpeg: Make packet buffer a parameter, don't hardcode it to be
[06:16] <CIA-17> ffmpeg: AVFormatContext.packet_buffer.
[06:16] <CIA-17> ffmpeg: Also move the function higher in the file, since it will be called from
[06:16] <CIA-17> ffmpeg: read_frame_internal().
[06:16] <CIA-17> ffmpeg: 03Justin Ruggles 07master * rc019070fda 10ffmpeg/libavformat/riff.c: 
[06:16] <CIA-17> ffmpeg: riffenc: use av_get_audio_frame_duration()
[06:16] <CIA-17> ffmpeg: For encoding, frame_size is not a reliable indicator of packet duration.
[06:16] <CIA-17> ffmpeg: Also, we don't want to have to force the demuxer to find frame_size for
[06:16] <CIA-17> ffmpeg: stream copy to work.
[06:16] <CIA-17> ffmpeg: 03Justin Ruggles 07master * r9524cf79df 10ffmpeg/ (4 files in 2 dirs): 
[06:16] <CIA-17> ffmpeg: avcodec: add av_get_audio_frame_duration() function.
[06:16] <CIA-17> ffmpeg: This is a utility function for the user to get the frame duration based on
[06:16] <CIA-17> ffmpeg: the codec id, frame size in bytes, and various AVCodecContext parameters.
[06:16] <CIA-17> ffmpeg: 03Justin Ruggles 07master * r6699d07480 10ffmpeg/libavcodec/ (avcodec.h utils.c): 
[06:16] <CIA-17> ffmpeg: avcodec: add av_get_exact_bits_per_sample() function
[06:16] <CIA-17> ffmpeg: This only returns bits per sample when it is exactly correct. That is, the
[06:16] <CIA-17> ffmpeg: codec contains only raw samples with no frame headers or padding. This applies
[06:16] <CIA-17> (94 lines omitted)
[09:44] <luc4> Hi! I tested ffplay on two ARM boards and I noticed on both there is a frequent glitch with wma over 64 Kbps. Is this a known bug? Is there any modification I can do to solve this?
[09:44] <av500> do you have a test file?
[09:45] <luc4> av500: yes
[09:45] <av500> then you could open a ticket and attach it
[09:46] <luc4> av500: ok, thanks
[09:46] <luc4> av500: do you also have any suggestion on where I should look to solve this? Maybe it is something related to the decoding of the wma?
[09:47] <av500> yes
[09:47] <av500> you could compare the decoder output between arm and x86
[09:47] <av500> does the file play OK on your PC?
[09:47] <av500> also, it could be lack of CPU power
[09:47] <av500> what arm board?
[09:48] <luc4> av500: yes, on my Ubuntu it seems ok. I compiled the same exact ffmpeg version for x86 and ARM, and the desktop is ok, ARM is not.
[09:48] <av500> what arm board?
[09:48] <av500> you have th glitch when decoding to a file?
[09:48] <av500> to rule out lack of cpu power
[09:48] <luc4> av500: one is a Rockchip board, the other is a Tegra2.
[09:49] <luc4> av500: one board is 1GHz, the other is a 2 core. I doubt that.
[09:49] <av500> right
[09:49] <av500> well, there are 25mhz arm boards :)
[09:49] <luc4> av500: yes, sure.
[09:49] <av500> so compare the output on arm vs x86
[09:51] <luc4> av500: I've never worked inside ffmpeg, so I'll try. Thanks!
[09:54] <luc4> av500: it seems like the decoder sends decoded data to alsa a little late. I noticed also that the packages of Ubuntu for arm have the same problem. It seems quite strange to me that no one has noticed this.
[10:00] <av500> the decoder decodes
[10:00] <av500> it knows nothing about alsa
[10:00] <av500> are you using ffmpeg to output to alsa directly?
[10:02] <luc4> av500: I understand that, but for some reason it seems that ALSA is receiving too few frames. Yes, I'm using ffplay.
[10:02] <av500> ah ffplay
[10:02] <av500> that uses SDL, no?
[10:02] <luc4> av500: it seems to work very good for mp3 and also some videos. Yes, I cross-compiled that as well. I also see video.
[10:02] <av500> decode your wma to a file and compare to x86
[10:03] <luc4> av500: ok, thank you
[10:03] <av500> i guess it will be correct
[10:03] <av500> and not an issue with "wma" per se
[10:03] <av500> and more an issue with ffplav/sdl and alsa
[10:04] <luc4> av500: I think that as well. Do you know on top of your head of anything else than ffplay to test? To see if that is the problem.
[10:05] <av500> ffplay outputs audio using SDL
[10:05] <av500> it does that in the SDL callback, so all the timing is handled by SDL
[10:06] <av500> so I am afraid the issue it rather in your SDL/alsa setup than in ffmpeg/avplay
[10:07] <luc4> av500: I guess you're right. I'll try to work on this then.
[11:23] <ubitux> yet another idea for gsoc (or any bored ppl): quickdraw encoder + support for insert/extract preview in mov files
[13:46] <perrth1> how to apply ladspa plugins using this https://gitorious.org/~saste/ffmpeg/sastes-ffmpeg ?
[13:47] <perrth1> the audio-filters branch
[16:23] <michaelni> ubitux, add it to our gsoc page if you havnt yet ...
[16:24] <michaelni> perrth1, ask saste / stefano
[16:26] <ubitux> michaelni: i'm not sure i have an access to the wiki
[16:32] <michaelni> ubitux, send a mail to mike melanson if you need an account
[18:07] <Compn> michaelni : if i want to add files to our samples repo, i put them in home2/samples/unified ?
[18:21] <michaelni> Compn, sounds correct
[18:21] <Compn> k
[18:28] <ubitux> speaking of samples, if i want to add and move some samples in the fate suite, where should i do the request?
[18:31] <Compn> you mean what ml ?
[18:31] <ubitux> well ml, mail, dunno
[18:31] <Compn> or where the fate-suite is
[18:32] <ubitux> where should i ask for :p
[18:32] <Compn> you should probably mail mike , and tell him that samples.ffmpeg.org is rsync'ing samples.libav.org , so rsyncing with samples.ffmpeg.org would be a good idea...
[18:32] <ubitux> to do a request to someone having the perm, to request for the perm to do it myself, etc
[18:32] <ubitux> ok
[18:33] <Compn> i think its only possible to add files to samples/fate if you have access on one of the boxes (ffmpeg or libav). i dont think there is ftp access directly to those dirs
[18:34] <Compn> the easiest way would probably host the files you want added on an external http server so someone can wget them to the correct place easily
[18:35] <Compn> but yeah, michael and reimar are root on ffmpeg box, mike runs sample libav repo, so either of them would be who to ask
[18:35] <Compn> or you could ask in #libav-devel
[18:40] <michaelni> ubitux, for the fate samples as in "make fate-rsync" its me or baptiste to contact
[18:41] <michaelni> for our samples archive anyone with an account on ffmpeg.org should be able to put things there
[18:41] <michaelni> and you can have an account if you want
[19:12] <ubitux> michaelni: it was for the fate samples as in "make fate-rsync", so ok, great, i'll gather the samples i want to upload and ask you then
[19:29] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r0f13cc732b 10ffmpeg/libavcodec/diracdec.c: 
[19:29] <CIA-17> ffmpeg: diracdec: Correct the bytestream end pointer.
[19:29] <CIA-17> ffmpeg: This fixes some arith decoder overreads and a potential infinite loop.
[19:29] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[19:29] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[20:21] <CIA-17> ffmpeg: 03Bastien Bouclet 07master * rb521f11349 10ffmpeg/libavcodec/bink.c: 
[20:21] <CIA-17> ffmpeg: Fix bink decoder for files with 24px width.
[20:21] <CIA-17> ffmpeg: Fixes ticket #962.
[20:27] <pasteeater> ffmpeg head still works on a PII.
[20:28] <Daemon404> the question is : why?
[20:28] <pasteeater> trying to duplicate ticket 1041 with the most similar machine i have.
[20:29] <Daemon404> i have a geode if you want to use it
[20:29] <Daemon404> it doesnt even have SSE :D
[20:32] <ohsix> does it have cmov
[20:33] <Daemon404> not sure
[20:34] <pasteeater> Daemon404: someone's already asking about your encoder: http://ffmpeg.org/pipermail/ffmpeg-user/2012-March/005396.html
[20:34] <Daemon404> a is obvious
[20:35] <Daemon404> b is no
[20:35] <Daemon404> ut video itself doesnt support >8bit
[20:35] <Daemon404> im not subscribed to ffmpeg-users
[20:35] <Daemon404> maybe i should
[20:45] <Daemon404> pasteeater, yeah geode isnt much use
[20:45] <Daemon404> ffmpeg essentially just always crashes
[20:45] <Daemon404> cause the cpu support next to othing
[20:45] <Daemon404> nothing*
[20:47] <pasteeater> gotta collect 'em all!
[20:48] <Daemon404> it's running windows flp w/ mingw32 atm, so it isn't veyr development friendly...
[20:48] <Daemon404> peraps ill install some i386 linux on it later
[20:48] <pasteeater> what do you use it for?
[20:49] <Daemon404> atm? nothing.
[20:49] <Daemon404> it sits and collects dust
[20:49] <pasteeater> my PII is just a database backup-backup.
[20:49] <Daemon404> i cant use this geode -too- heavy
[20:49] <Daemon404> it's one of those case-is-the-heatsink
[20:49] <Daemon404> it almost lit my desk on fire once
[20:50] <ohsix> how did it not delaminate the pcb if it was nearly on fire
[20:50] <Daemon404> ohsix, thats actually a big problem with this particular model
[20:51] <Daemon404> but all it ended up doing was leaving burn marks on my desk
[20:51] <Daemon404> http://1000umbrellas.com/2010/09/09/how-i-destroyed-two-hard-drives-with-my-fit-pc-slim <--
[20:51] <Daemon404> one of those
[20:52] <pasteeater> you weren't joking about the heatsink-case.
[20:52] <Daemon404> yup
[20:53] <ohsix> heh: Ive discovered that some services that I thought wouldnt tax the processor, such as Folding At Home
[20:53] <Daemon404> nobody said that guy was smart
[21:40] <Daemon404> looks like this proc only has mmx and 3dnow
[21:40] <Daemon404> lulz
[21:40] <Daemon404> classy
[21:44] <Daemon404> https://japland.org/lol_geode.html
[21:55] <Rathann> Daemon404: is that an old olpc laptop?
[21:55] <Daemon404> no
[21:55] <Daemon404> [14:51] <+Daemon404> http://1000umbrellas.com/2010/09/09/how-i-destroyed-two-hard-drives-with-my-fit-pc-slim <--
[21:56] <Daemon404> one of these
[21:57] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * ra8d67efa53 10ffmpeg/libavcodec/aacdec.c: (log message trimmed)
[21:57] <CIA-17> ffmpeg: aacdec: Fix out of array writes (stack).
[21:57] <CIA-17> ffmpeg: This fixes an issue in the code to check the size that will
[21:57] <CIA-17> ffmpeg: be written to match the actual code writing. In the long
[21:57] <CIA-17> ffmpeg: term it would make sense to change this so the counting and
[21:57] <CIA-17> ffmpeg: writing code are the same so they dont need to be kept in sync.
[21:57] <CIA-17> ffmpeg: It also increases the array size, which was too small either way
[22:03] Action: overflow_0f8b wondering why can't ffmpeg have an 1.0 version that is final without bugs
[22:05] <Daemon404> that doesnt sound very possible.
[22:05] <Daemon404> >software without bugs
[22:05] <Daemon404> lul.
[22:06] <overflow_0f8b> i write software without bugs for myself lol.
[22:06] <Daemon404> anyone who claims to write code without any bugs is a filthy liar.
[22:06] <Daemon404> period.
[22:06] <overflow_0f8b> :)
[22:06] <overflow_0f8b> hard to believe eh ?
[22:07] <overflow_0f8b> you just have to start from the beginning, the fractals.
[22:07] <Compn> ffmpeg is a lot of code, over a long period of time (10 years)
[22:08] <Compn> we've never had a manual audit of the code i dont think
[22:08] <Daemon404> to quote joel:
[22:08] <Daemon404> Do you write perfect code the first time? If you answered Yes to question 1, you're a liar and a cheat. You fail. Take the test again.
[22:08] <overflow_0f8b> no ;<
[22:08] Action: Compn wonders why Daemon404 is biting troll
[22:08] <Compn> linux sucks am i rite?
[22:08] <Daemon404> Compn, i just like that quote
[22:08] <Daemon404> gotta use every opportunity.
[22:09] <Daemon404> [16:07] <@Compn> ffmpeg is a lot of code, over a long period of time (10 years) <-- could be worse
[22:09] <Daemon404> could be X.
[22:09] <overflow_0f8b> Daemon404 << but i can use my magic debugger (the printf) if in doubt
[22:09] <Daemon404> troll mode engaged
[22:11] <Compn> whoa
[22:12] <Compn> Unfortunately, there is no point to distributing music in 24-bit/192kHz format. Its playback fidelity is slightly inferior to 16/44.1 or 16/48, and it takes up 6 times the space.
[22:12] <Compn> so says xiphmont!
[22:12] <Compn> http://people.xiph.org/~xiphmont/demo/neil-young.html
[22:12] <overflow_0f8b> ok
[22:12] <overflow_0f8b> now we will revert to 22100hz 8 bit then
[22:13] <Daemon404> Compn, that link is pretty much correct
[22:13] <overflow_0f8b> *22050
[22:13] <Tjoppen> no need to be snarky. he's pretty much spot on
[22:13] <Tjoppen> audiofools need to be put in their place
[22:14] Action: Daemon404 slaps Tjoppen with a gold plated, diamond encrusted cable, forged by blind elves on mount doom
[22:14] <overflow_0f8b> actually i'm thinking about using functional representation of audio signals...
[22:15] <Compn> people just want music before its fucked-with and over compressed / loudness wars etc
[22:15] <Compn> http://en.wikipedia.org/wiki/Loudness_war
[22:15] <Daemon404> Compn, which is completely unrelated to 192khz/24bit
[22:15] <Daemon404> ;)
[22:19] <durandal_1707> overflow_0f8b: too much 11025 is enough
[22:21] <overflow_0f8b> durandal_1707 << for the bass drums you might not even notice the difference yeah (especially if it gets cleaned before output)
[23:54] <durandal_1707> michaelni: packed_at_lsb seems to be wrong in ffv1
[00:00] --- Wed Mar  7 2012