[FFmpeg-devel-irc] IRC log for 2010-05-23

[irc at mansr.com]

[13:21:15] * Terminating due to: TERM
[13:21:28] * /join #ffmpeg-devel ...
[13:21:30] *** TOPIC: Welcome to the FFmpeg development channel. That is, development of FFmpeg, not using FFmpeg, nor libav*. | Users should redirect their questions to #ffmpeg | FFmpeg 0.5.1 has been released! | this chat is now publicly logged.
[13:21:30] *** TOPICINFO: superdump!~rob at unaffiliated/superdump, 1267604523
[13:21:40] <BastyCDGS> doesn't seem to ;)
[13:22:34] <Vitor1001> lol
[13:25:31] * Vitor1001 kicks CIA-93
[13:25:33] <CIA-93> ow
[13:25:43] <BastyCDGS> didn't said it? he's still alive and loud :D
[13:26:03] <BastyCDGS> oh why it's 93 now and not 7 anymore?
[13:26:33] <Vitor1001> Should be random every time it logs in, probably to avoid nick clashing in freenode...
[13:27:33] <BastyCDGS> I just remember that it was always 7 in the past at least from the time on where I was joining FFmpeg
[13:35:38] <BastyCDGS> btw, I need an account for: ftp://upload.mplayerhq.hu/incoming I just can use: ftp://anonymous@upload.mplayerhq.hu/MPlayer/incoming
[13:41:29] <CIA-93> libswscale: stefano * r31192 /trunk/libswscale/swscale.h:
[13:41:29] <CIA-93> libswscale: Add empty newline to separate function declarations, for better
[13:41:29] <CIA-93> libswscale: readability.
[13:47:26] <_av500_> KotH: there will be good chinese food!
[13:48:13] <BastyCDGS> av500, who I can ask for a FTP account?
[13:48:21] <_av500_> BastyCDGS: anonymous works for me
[13:48:30] <_av500_> whats the issue?
[13:48:42] <BastyCDGS> the thing is that the folder I created disappears after some minutes and I can't access it anymore
[13:48:53] <_av500_> mkdir folder
[13:48:55] <_av500_> cd folder
[13:48:55] <BastyCDGS> I think it's moved from MPlayer/incoming to /incoming
[13:48:56] <_av500_> put
[13:49:31] <BastyCDGS> it doesn't seem to work with anon in /incoming
[13:49:38] <_av500_> it works for me
[13:50:02] <BastyCDGS> as said some few minutes everything is normal but then the folder disappears with all files in it
[13:50:06] <BastyCDGS> I know it's still lthere
[13:50:12] <BastyCDGS> since I can't recreate the folder
[13:50:27] <BastyCDGS> I'm using FTP kio slave from KDE as well as filezilla
[13:50:53] <_av500_> BastyCDGS: yes, the folder is there
[13:51:01] <_av500_> so you uploaded the files
[13:51:08] <BastyCDGS> one is still uploading
[13:51:08] <_av500_> so what is the issue?
[13:51:16] <BastyCDGS> that I can't update the folder anymore etc.
[13:51:33] <_av500_> what are all these files you upload?
[13:51:49] <BastyCDGS> for testing & compiling TuComposer
[13:52:15] <BastyCDGS> it contains the complete development environment for amiga since TuComposer today just builds on that
[13:52:24] <BastyCDGS> for the upcoming MOD support in ffmpeg
[13:52:27] <_av500_> and why to mplayer?
[13:52:41] <_av500_> few ffmpeg devs work on amigas
[13:52:51] <BastyCDGS> was recommended by me at very first day I was in #ffmpeg-devel
[13:53:04] <BastyCDGS> although not MPlayer
[13:53:15] <_av500_> but the src code is available on your website, no?
[13:53:17] <BastyCDGS> but /incoming w/o MPlayer demands auth from me
[13:53:35] <BastyCDGS> yes but not the amiga development environment as well as lots of test files
[13:53:49] <_av500_> but who is supposed to use all that?
[13:54:04] <BastyCDGS> stefano wanted to take a look onto it
[13:54:50] <_av500_> ah ok
[13:55:30] <BastyCDGS> he's my mentor ;)
[13:55:59] <BastyCDGS> btw, could you give me the FTP url that works for you?
[13:57:03] <_av500_> upload.ffmpeg.org
[13:57:47] <BastyCDGS> still doesn't work :(
[13:57:56] <BastyCDGS> tried ftp://upload.ffmpeg.org/incoming
[13:58:47] <_av500_> http://www.ffmpeg.org/bugreports.html
[13:59:00] <mru> incoming is write-only
[14:00:18] <peloverde> The password is easily findable on the web if one is clever
[14:03:20] <BastyCDGS> mru, yes but when the folders disappear I can't even blindly upload any files to my created folder
[14:03:48] <mru> you can cd even if you can't see it
[14:04:00] <BastyCDGS> I tried that it returns error
[14:04:14] <BastyCDGS> maybe it's a KIO slave issue but also happens with filezilla
[14:04:23] <peloverde> Try a commandlien client
[14:04:50] <peloverde> eg lftp or ncftp
[14:06:12] <BastyCDGS> basty at cdgs-basty:/var$ lftp upload.ffmpeg.org
[14:06:12] <BastyCDGS> lftp upload.ffmpeg.org:~>
[14:06:12] <BastyCDGS> lftp upload.ffmpeg.org:~> ls
[14:06:12] <BastyCDGS> drwxrwsr-x   11 0        1004         4096 Mar 05 22:23 MPlayer
[14:06:12] <BastyCDGS> drwx------    2 0        0           16384 Dec 09  2005 lost+found
[14:06:13] <BastyCDGS> lftp upload.ffmpeg.org:/> cd MPlayer/incoming/AMIGA
[14:06:13] <BastyCDGS> cd: L'accès a échoué : 550 Failed to change directory. (/MPlayer/incoming/AMIGA)
[14:06:14] <BastyCDGS> lftp upload.ffmpeg.org:/> cd incoming/AMIGA
[14:06:14] <BastyCDGS> cd: L'accès a échoué : 550 Failed to change directory. (/incoming/AMIGA)
[14:06:15] <BastyCDGS> lftp upload.ffmpeg.org:/>
[14:07:02] <BastyCDGS> AMIGA is the directory I'm right uploading now and that disappeared after some minutes
[14:08:56] <mru> try again, but hurry
[14:09:35] <BastyCDGS> cd ok merci
[14:10:34] <BastyCDGS> lftp upload.ffmpeg.org:/MPlayer/incoming/AMIGA> put ~/Desktop/ROMS.7z.txt
[14:10:34] <BastyCDGS> put: L'accès a échoué : 553 Could not create file. (ROMS.7z.txt)
[14:10:41] <BastyCDGS> damn upload and ls still doesn't work
[14:12:16] <mru> now then
[14:13:05] <BastyCDGS> transfer successful
[14:13:08] <BastyCDGS> but still no ls
[14:13:13] <BastyCDGS> what is the issue with that?
[14:13:13] <mru> that's intentional
[14:13:18] <mru> I said it's write-only
[14:13:34] <BastyCDGS> but when I created it and uploaded the first files a ls did work
[14:13:45] <mru> you got lucky
[14:13:55] <BastyCDGS> well, after all I have now all files
[14:14:02] <BastyCDGS> except the WB39.7z
[14:14:07] <BastyCDGS> but this is still uploading
[14:14:25] <BastyCDGS> @ 25%
[14:14:53] <_av500_> you are uploading all amiga warez you have? ;)
[14:15:16] <BastyCDGS> nope 90% of these are TuComposer Modules as well as the original mod/s3m/xm/it files
[14:18:10] <BastyCDGS> there's a FFmpeg.txt on the workbench screen which you should read, it contains basic amiga UI stuff and compile HOWTO of TuComposer
[14:27:42] <BastyCDGS> I will finish now the patches from last weekend
[14:45:19] <KotH> _av500_: chinese food is overrated
[14:46:12] <_av500_> KotH: iKnow
[14:46:23] <mru> are you comparing the amiga to chinese food?
[14:48:59] <BastyCDGS> mru, funny how do you come to the idea he could compare cf to amiga?
[14:49:15] <mru> he said it was overrated...
[14:49:29] <_av500_> some is even overheated
[14:49:37] <mru> and full of MSG
[14:49:37] <kierank> what is so brilliant about the amiga?
[14:49:50] <KotH> it was ahead of it's time
[14:49:57] <KotH> 30 years ago
[14:50:10] <BastyCDGS> kierank can you image that a full-featured multitasking OS was able to run smooth in 1986 with a 7MHz CPU
[14:50:12] <mru> the amiga is a fixed point in time
[14:50:16] <mru> c. 1988
[14:50:24] <mru> before that, it was ahead of its time
[14:50:27] <mru> after, well...
[14:50:41] <BastyCDGS> yes with the approach of pentium the amiga lost
[14:50:41] <kierank> 22 years later, what is so brilliant about it?
[14:50:46] <KotH> nowadays i have a cell phone that has higher computation power, better graphics, higher resolution screen, more memory than my pc 10y ago
[14:50:56] <mru> sun was making m68k-based Unix workstations well before that
[14:51:03] <mru> far more powerful than any amiga
[14:51:17] <_av500_> they used them to develop amiga afaik...
[14:51:25] <KotH> BastyCDGS: have you ever heard of the pdp-11?
[14:51:31] <BastyCDGS> pdp-11? no
[14:51:35] <mru> rotfl
[14:51:45] <KotH> BastyCDGS: it was running a full featured unix on a 8bit processor
[14:51:56] <BastyCDGS> cewl
[14:52:09] <spaam> mru: do you own an amiga?
[14:52:14] <KotH> oops.. sorry, 16bit
[14:52:33] <kierank> 16-bit sounds more realisitc
[14:52:38] <kierank> realistic*
[14:52:51] <_av500_> we were once an amiga company...
[14:53:07] <BastyCDGS> av500, really...which one?
[14:53:19] <_av500_> archos ,ade cdrom for amiga
[14:53:20] <KotH> kierank: there were unix systems implemented on 8 bit machines
[14:53:24] <_av500_> made
[14:53:54] <mru> isn't that like fitting afterburners on a model T Ford?
[14:54:02] <BastyCDGS> mru, what made these m68k SUN stations so special that they were far ahead from the amiga?
[14:54:15] <KotH> mru: if the model t can fly after that, why not?
[14:54:17] <mru> they ran SunOS
[14:54:35] <mru> not a dinky toy OS only capable of simple games and "demo scene" material
[14:54:38] <BastyCDGS> don't know SunOS so I can't compare that to AmigaOS
[14:54:46] <mru> it's a full Unix
[14:54:52] <BastyCDGS> lol the OS from the amiga was never used for games and demo scene stuff
[14:54:57] <_av500_> mru: who cares, it made monex
[14:55:29] <BastyCDGS> apart from user/group permissions amigaos could do almost everything that unix can do
[14:55:39] <KotH> BastyCDGS: could it be that you are new to computers?
[14:55:55] <BastyCDGS> if you consider since 1986 as new...yes
[14:56:40] <KotH> BastyCDGS: new as in "has not seen anything but a single niche of computers"
[14:56:40] <BastyCDGS> but this was a Plus 4...I got my A500 in 1988
[14:57:43] <BastyCDGS> amiga wasn't a niche during that time, it was the most widespread home computer besides the C64
[14:58:07] <KotH> s/niche/class/ if you want to be pedantic
[14:58:15] <mru> KotH: http://www.snopes.com/autos/dream/jato.asp
[14:58:24] <kierank> BastyCDGS: you haven't answered my question yet [15:50] <kierank> 22 years later, what is so brilliant about it?
[14:58:56] <KotH> mru: knonw
[14:58:59] <KotH> mru: known
[14:58:59] <_av500_> that it was brilliant back then
[14:59:07] <BastyCDGS> kierank, nothing really as I said already, since the arrival of pentium the amiga got behind
[14:59:33] <mru> KotH: you asked if the model T would fly...
[15:01:19] <BastyCDGS> kierank, I also don't have experience with today's PPC based amigas...so I can't really tell how brilliant they are, but from what I read, they're most like today PCs with no custom chips, so I wouldn't probably buy one...
[15:01:49] <BastyCDGS> AmigaOS 4 is probably fine, but I doubt hardly that it can kill any recent Linux
[15:02:19] <spaam> can you run AmigaOS 4  on x86 ?
[15:02:43] <mru> of course not
[15:03:01] <BastyCDGS> porting it could be pretty easy (HAL stuff) but as far as I know there's no x86 port
[15:03:08] <BastyCDGS> but you can use AROS instead for x86
[15:03:31] <mru> or you can grow up and run linux
[15:03:46] <BastyCDGS> yes that's what I do now ;)
[15:04:17] <kierank> BastyCDGS: how many people are in CDGS?
[15:04:23] <BastyCDGS> just me
[15:04:24] <mru> later, some people suffer a mid-life crisis in which they fork another bsd
[15:05:16] <BastyCDGS> kierank, hadn't really dealed with CDGS itself the last years...was just too busy with other stuff
[15:05:21] * _av500_ must fork a bsd then
[15:05:39] <Gottaname> this channel is way more lively than #ffmpeg
[15:05:40] <_av500_> av-bsd
[15:05:41] <Gottaname> :(
[15:05:42] <BastyCDGS> hehe, everyone of us NOW forks a bsd :D
[15:06:07] <_av500_> Gottaname: its sunday afternoon
[15:06:39] <Gottaname> I'm mean, not to sound too demanding or something, I'm almost at wits end asking for help in the other channel...
[15:06:40] <Gottaname> :(
[15:07:31] <KotH> that's because we talk here about amiga and not about ffmpeg
[15:07:44] <_av500_> whats ffmpeg anyway?
[15:07:58] <KotH> something that uau has not forked yet
[15:08:11] <spaam> haha
[15:08:19] <Gottaname> is he around?
[15:08:20] <spaam> do you think he will fork ffmpeg? ;)
[15:08:23] <mru> has he forked bsd?
[15:08:27] * Gottaname notes he comes for the bittornado channel
[15:08:38] <KotH> "es wird empfohlen laufende programme vor der installation zu beenden" WTF? this is fucking unix!
[15:08:57] <_av500_> u run german locale?
[15:09:05] <BastyCDGS> It is recommended to terminate running programs before doing install
[15:09:08] <KotH> _av500_: german software
[15:09:13] <mru> we speak german
[15:09:15] <BastyCDGS> just translated it for anybody not speaking german here
[15:09:17] <iive> spaam: he would fork ffmpeg-mt
[15:09:24] <_av500_> BastyCDGS: only a few
[15:09:24] <KotH> spaam: ofc he will, as soon as he is dissatisfied with the development of ffmpeg
[15:09:46] <_av500_> iive: ffmpeg-mt forsk itself, no?
[15:10:11] <iive> well, having more forks in the fork doesn't fork^Whurt
[15:10:14] <Gottaname> anyway, nobody to help newbies with using the ffmpeg libavcodec in the other channel?
[15:10:19] <KotH> BastyCDGS: dont worry about translation. this channel speaks fluently german, swedish, japanese and arm assembler
[15:10:21] * Gottaname is sadded
[15:10:52] <KotH> Gottaname: only if you get atmel fix the bugs in their USB core
[15:11:04] * BastyCDGS neither speaks / understands swedish and japanese
[15:11:07] <KotH> or at least admit they have bugs
[15:11:42] <_av500_> and he does usefull stuff more years and u will...
[15:11:48] <_av500_> err
[15:11:49] <KotH> "falls auf ihrem rechner ein virenscanner aktiviert ist (z.B. Norton Antivirus)...." ???
[15:11:50] <_av500_> undo
[15:11:59] <BastyCDGS> av500, lol and this on linux
[15:12:03] <BastyCDGS> wine Norton.exe :D
[15:12:41] <_av500_> KotH: pray tell what sw is that?
[15:13:41] <KotH> _av500_: very shitty ported software, as it seems
[15:14:18] <_av500_> KotH: ramdoubler will not help you on linux
[15:14:19] <BastyCDGS> I guess the wanted to know the name of that piece of sh^Hsoftware...
[15:15:02] <Evgeny> hi all!
[15:15:14] <KotH> salom
[15:15:40] * _av500_ starts a fire...
[15:16:11] <BastyCDGS> hi evgeny
[15:16:19] * BastyCDGS sits to the fire
[15:16:23] <Evgeny> shalom :) how can i generate cookie in ffmpeg code? is it special option?
[15:16:35] <spaam> _av500_: going to eat BastyCDGS ? ;D
[15:17:47] <BastyCDGS> damn you must be really hungry then ;)
[15:18:38] <Gottaname> okay guys, anyone knowes who coded api-example.c>
[15:18:45] <Gottaname> in libavcodec?
[15:18:49] * BastyCDGS cuts a bit of fresh flesh from himself and then reprograms his DNA to recreate that missing part quickly
[15:19:07] <spaam> Gottaname: did you read the log for that file? :)
[15:19:53] <spaam> Gottaname: svn log libavcodec/api-example.c | less
[15:20:07] <Evgeny> :'( anyone, please, help me
[15:21:03] <KotH> Evgeny: you're aware that this is the ffmpeg development channel and not the "how do i use ffmpeg" channel?
[15:21:49] <Evgeny> yes, i use ffmpeg channels
[15:22:13] <Gottaname> spaam: read it
[15:22:15] <Evgeny> but i trying to create RTSP over HTTP
[15:22:25] <Gottaname> also, it appears I'm not the first one reporting it
[15:22:32] <Evgeny> and i need cookie there
[15:22:39] <votz> DonDiego: ping
[15:22:52] <wbs> Evgeny: trying to "create", as in, implementing it?
[15:22:55] <DonDiego> votz: pong
[15:23:08] <DonDiego> votz: what did i miss?
[15:23:08] <Evgeny> yes, implementing
[15:23:12] <votz> DonDiego: hey qt
[15:23:20] <votz> a few people in #ffmpeg have run into trouble with api-example.c
[15:23:22] <wbs> Evgeny: well, just add a cookie header to the http requests you make then?
[15:23:34] <DonDiego> why does that concern me? :)
[15:24:09] <votz> DonDiego: your poor name was on api-example.c's history ;)
[15:24:11] <votz> someone set you up the bomb
[15:24:23] <DonDiego> it seems
[15:24:24] <_av500_> DonDiego: you fixed all the spelling in that file
[15:24:36] <votz> I just thought I'd bring it to your attention if you weren't already aware
[15:24:56] <DonDiego> that's not my area, go look for someone else :)
[15:25:06] <Gottaname> problems is semantic, not syntax
[15:25:16] <Gottaname> the probkem*
[15:25:44] <Gottaname> pardon my bad spelling, my left wrist maybe fractured
[15:25:52] <Gottaname> going to the doctor's tommorrow for a x-ray...
[15:26:02] <votz> DonDiego: who else should I bother? :)
[15:26:17] <DonDiego> go for any other op around here :)
[15:26:37] <Gottaname> direct us to the person so that we may continue burning torches and wielding pitchforks in that person's direction.
[15:26:44] <Evgeny>  <@wbs>  ok. i'll try.
[15:27:36] <votz> Gottaname: ah, I see youre in here anyhow
[15:28:19] <Gottaname> well, I don't mind lurking around, but its like 11:30pm here in singapore
[15:28:38] <wbs> noone of you have yet said what the problem is with output-example.c yet
[15:28:46] <Gottaname> there's no problem with it
[15:28:51] <Gottaname> that's the funny thing
[15:29:05] <Gottaname> everything else works EXCEPT that particular function
[15:29:35] <wbs> which function is that?
[15:29:43] <votz> wbs: talk to Gottaname. I was just playing carrier pidgin on this one :)
[15:30:38] <Gottaname> avcodec_decode_audio3
[15:30:53] <Gottaname> in the audio_decode_example
[15:31:14] <Gottaname> http://ffmpeg.pastebin.com/vF7xxAqd <- error
[15:31:17] <Gottaname> no args
[15:34:37] <wbs> I'll have a look
[15:34:52] <Gottaname> thanks
[15:35:31] <CIA-93> ffmpeg: reimar * r23258 /trunk/libavcodec/avcodec.h: Document CODEC_FLAG_EMU_EDGE and avcodec_align_dimensions interaction.
[15:37:27] <_av500_> api-example should be FATE tested...
[15:39:50] <lu_zero> yawn
[15:40:51] <lu_zero> where is hosted ffmtech website and how has a way to push stuff there?
[15:45:13] <BastyCDGS> hey jai :)
[15:45:16] <BastyCDGS> how are u?
[15:47:04] <jai> hello BastyCDGS
[15:48:17] <BastyCDGS> sorry I had been inactive last week but had to do the exams work
[15:48:30] <BastyCDGS> had to develop a complete software with devel/user manual from last mon - fri
[15:52:43] <DonDiego> has anybody else received mail from admin at mp3rocket.net, subject "FFMPEG Consultant Desired" and asking about audio to MP3 conversion?
[15:54:22] <lu_zero> I didn't
[15:56:04] <Compn> not i
[15:56:37] <BastyCDGS> me neither
[15:58:46] <_av500_> there is money in audi0o to mp3 conversion?
[15:58:53] <_av500_> -0
[15:59:06] <wbs> it's quite advanced, not many people know how to do that nowadays
[15:59:08] <DonDiego> i have my doubts..
[15:59:09] <wbs> ;P
[15:59:13] <BastyCDGS> a lot of money...when you get sued from RIAA etc. ;)
[16:00:16] <jai> where is the RIAA nowadays anyway, i'd have expected them to sue grooveshark
[16:00:23] <_av500_> BastyCDGS: riaa is not picky, they sue for any encoding std, mabe not if your convert brtittny to .mod though..
[16:00:35] <jai> _av500_: ouch :)
[16:00:42] <BastyCDGS> my poor ears :D
[16:01:20] <BastyCDGS> we should get pain money for listening to britney & co. ;)
[16:01:25] <BastyCDGS> not the other way around :P
[16:01:32] <jai> is it just me having all these problems with ffplay after avfilter support
[16:01:50] <BastyCDGS> what problems you have with ffplay?
[16:02:16] <jai> quite a few
[16:02:33] <jai> crashes, borked output etc
[16:02:59] <BastyCDGS> well IFF crashes with enabled avfilter too ;)
[16:03:08] <BastyCDGS> do you have any idea, what's wrong there?
[16:03:51] <jai> BastyCDGS: that one is because you are trying to call get_buffer during init
[16:04:06] <BastyCDGS> is that illegal?
[16:04:13] <BastyCDGS> where I should put it instead?
[16:05:09] <jai> BastyCDGS: ideally, do that in decode_frame
[16:05:31] <jai> but i haven't looked at the code in detail, so i dont know what, if anything, prevents that
[16:05:40] <BastyCDGS> funny...in decode frame it does reget_buffer again
[16:05:40] <BastyCDGS> so I just probably can remove the getbuffer in init and replace reget_buffer in these with get_buffer?
[16:05:50] <jai> yeah
[16:05:59] <BastyCDGS> I'll try this out, if it works I will submit a patch
[16:06:22] <jai> it might still crash :)
[16:06:28] <jai> (if you use reget buffer)
[16:06:49] <BastyCDGS> I said will replace reget_buffer with get_buffer so there won't be any reget_buffers then anymore ;)
[16:06:55] <jai> oh
[16:08:04] <BastyCDGS> after all it gets the buffer twice as it is implemented now
[16:08:52] <BastyCDGS> hmm get segfault now
[16:09:52] <DonDiego> btw, does anybody know of a FOSS project with an invite-only dev mailing list?
[16:10:01] <Dark_Shikari> for reading or writing?
[16:10:07] <DonDiego> both
[16:10:11] <Dark_Shikari> glibc has one invite-only write mailing list
[16:10:13] <Dark_Shikari> but anyone can read
[16:13:54] <BastyCDGS> jai, it seems the problem is that init also calls ff_read_cmap_palette
[16:14:03] <BastyCDGS> which expects frame to be initialized so I move that too
[16:17:13] <BastyCDGS> yeah it was the cmap_read stuff and it still works having that only in decode_frame
[16:17:19] <BastyCDGS> now I rebuild with --enable-avfilter ;)
[16:34:31] <BastyCDGS> IFF works with avfilter enabled!!!!!!!!! YEAH!!!
[16:35:14] <spaam> \o/
[16:35:18] <ramiro> isn't avfilter enabled by default now?
[16:36:04] <BastyCDGS> yes but IFF crashed always with enabled avfilter ;)
[16:36:13] <BastyCDGS> so I had do build with disable-avfilter up to now
[16:36:19] <BastyCDGS> will prepare the patch and submit :)
[16:36:34] <ramiro> shouldn't you get started on your actual gsoc project?
[16:37:47] <spaam> how many gsoc students does ffmpeg have?
[16:38:05] <BastyCDGS> ramiro, tomorrow
[16:38:19] <BastyCDGS> that's the reason I'm uploading the amiga stuff for tucomposer
[16:38:37] <ramiro> spaam: http://wiki.multimedia.cx/index.php?title=Summer_of_code
[16:39:26] <spaam> ramiro: ty
[16:39:30] <jai> BastyCDGS: good for you
[16:39:43] <jai> now if only we could fix the rest...
[16:39:55] <BastyCDGS> jai, what's good to me exactly?
[16:40:08] <jai> BastyCDGS: ilbm works
[16:42:12] <BastyCDGS> patch submitted to ml
[16:45:45] <BastyCDGS> jai, I will then close the issue regarding this, ok?
[16:45:57] <BastyCDGS> or at least mark as patch available
[16:45:59] <wbs> BastyCDGS: not until the patch has been committed
[16:46:22] <BastyCDGS> then I just attach the patch there, ok?
[16:46:32] <wbs> yes, that's better
[16:47:41] <jai> BastyCDGS: if you are feeling lazy, then just wait for it to be committed, and close it
[16:47:43] <BastyCDGS> btw, as a side effect the bad aspect ratio stuff is also fixed with enabled avfilter ;)
[16:47:51] <BastyCDGS> there's no black border anymore with the IFF images
[16:47:55] <jai> i doubt anyone tracks issues at that granularity
[16:50:08] <BastyCDGS> https://roundup.ffmpeg.org/issue1895
[16:58:04] <DonDiego> what's the status of the vp8/webm stuff?
[16:58:09] <DonDiego> everything merged already?
[16:58:49] <peloverde> WebM demux is merge
[16:58:53] <peloverde> nothing else is
[16:59:12] <DonDiego> k, thx
[16:59:17] <peloverde> well except for the CODEC_ID stuff
[16:59:40] <DonDiego> peloverde: when do you expect to finish PS?
[17:00:00] <peloverde> It depends on how long review takes
[17:00:02] <DonDiego> and what's the further roadmap for obsoleting libfaad? :)
[17:00:39] <peloverde> faad supports LTP and some of the ER AOTs
[17:02:38] <Compn> arg i forgot to ask sesse to upload his cfdecode2.ax
[17:03:42] <peloverde> We are missing SSR, LTP, ER_LC, ER_LTP, and ER_LD
[17:04:10] <peloverde> Of those probably only ER LC and ER LD matter
[17:07:22] <DonDiego> do you plan to implement them (eventually)?
[17:08:06] <peloverde> maybe LTP, because it is simple and non invasive
[17:08:51] <peloverde> but I don't think I've ever encountered LTP in the wild
[17:13:34] <wbs> Gottaname: for what it's worth, apiexample.c seems to have been broken since rev 9144, 27 may 2007
[17:14:41] <Gottaname> wbs: crap
[17:14:52] <Gottaname> wbs: any way of getting it to work again?
[17:15:06] <wbs> I'm not sure how the audio decoding really is intended to work there
[17:15:58] <Gottaname> alot of ffmpeg tutorials point to using api-example.c as a guide for development...
[17:16:04] <wbs> it writes encoded data to a file without any framing, and then reads arbitrarily sized chunks out of it and feeds it to the decoder. the last frame of the buffer will be cut off, and you get a decoding error
[17:16:31] <Gottaname> no wonder
[17:16:31] <wbs> well, it shows the basics, but for most audio codec, the file format needs to provide some kind of framing
[17:16:37] <jai> better use ffmpeg.c as a reference ;)
[17:17:02] <wbs> so if you just ignore the decoding error of the last half frame in each buffer read from disk, you get the picture of how it's supposed to work
[17:17:05] <Gottaname> wbs: so the last frame is cut off, anyway of forcing it to read the last frame?
[17:18:10] <Gottaname> wbs: input buffer is about 4600ish
[17:18:23] <wbs> Gottaname: uhm.. well, you could increase the buffer size so that you read the whole file at once
[17:18:23] <Gottaname> oh wait, that's the output
[17:18:29] <Gottaname> the input is set at 4096
[17:18:46] <Gottaname> wbs: do away with the while loop?
[17:19:04] <wbs> if you read partial data from a file, you'd need to provide proper framing, that is, read full frames from disk (or feed them through a parser, if one exists for that format)
[17:20:02] <wbs> so one way to fix that would be to redesign it to write e.g. each frame to a separate file
[17:20:16] <Gottaname> wbs: is it a major redesign?
[17:20:40] <wbs> nah, it isn't that big a change I think
[17:21:20] <Gottaname> I'm technically n00b at this... the api-example.c was supposed to give a refernece point...
[17:21:21] <Gottaname> hmmm
[17:21:30] <Gottaname> no chance of it being fixed anytime soon?
[17:22:15] <wbs> can't give any promise
[17:22:48] <wbs> but I can try to write a mail to ffmpeg-devel with a short analysis of it, with a question to michael (or someone else who's authoritive on that part) on how to fix it
[17:22:50] <Gottaname> hmm, so the current generation of avcodec_decode_audio3
[17:23:25] <Gottaname> wbs: that would help
[17:23:27] <wbs> but if you just want to learn how the API works, the code is a good starting point nevertheless
[17:23:39] <Gottaname> yeah, but it doesn't do much good if it doesn't work
[17:23:59] <wbs> yes, it does work, it just fails after a while
[17:24:13] <wbs> I'll try to explain it slowly
[17:24:38] <Gottaname> try to be abit patient since its 1:20am here, I might not be thinking so clearly...
[17:24:47] <wbs> you've got a number of compressed frames written to the file. generally, you don't know the size of a compressed frame
[17:24:59] <wbs> depending on format, you may need more or less a full decoder to know how long a frame is
[17:25:17] <Gottaname> each frame is specific to its own format right?
[17:25:18] <wbs> so therefore, you _normally_ write frames to disk using some container format, that clearly says how many bytes each frame is
[17:25:21] <wbs> yes
[17:25:33] <Gottaname> this is going to be painful...
[17:25:40] <Gottaname> okay
[17:25:46] <wbs> so then you can read out exactly one frame at a time
[17:25:48] <Gottaname> assuming MP3
[17:26:03] <wbs> or for some formats, you may get multiple frames at a time
[17:26:19] <wbs> then you pass this frame (or this packet containing many frames) to a decoder, which decodes one frame at a time from the buffer
[17:26:37] <Gottaname> audio decode takes in a context, the input buffer, the output buffer
[17:26:38] <wbs> this returns how many bytes it did output and how many bytes it consumed from the buffer
[17:27:05] <Gottaname> I assume that would be the last part of the arguements taken in
[17:27:16] <Gottaname> namely &pktavc or something
[17:27:19] <Gottaname> at the end right?
[17:27:29] <wbs> that's the input compressed data
[17:28:24] <wbs> the problem with api-example.c is that it reads an arbitrary amount of data from the file, and pass it to the decoder. first it successfully decodes one frame at a time, about 18 times
[17:28:43] <wbs> then you've only got partial data for the 19th frame, since you just read 4096 bytes from file
[17:28:46] <Gottaname> yeah, but it isn't accurate isn't it?
[17:29:12] <Gottaname> wbs: I assume similiar to SDL buffering?
[17:29:53] <Gottaname> so this partial frame, I have to shrink the output buffer for it right?
[17:31:09] <wbs> no, no.. no..
[17:31:40] <_av500_> no
[17:31:54] <wbs> as a purely fictional example, lets say each of the compressed frames are about 220 bytes long
[17:32:12] <wbs> frame 1 is at bytes 0-219, frame 2 at 220-439 in the file, etc
[17:32:21] <wbs> you read bytes 0-4095 from file, and feed them to the decoder
[17:32:39] <wbs> the decoder first decodes the first 220 bytes and outputs the corresponding uncompressed audio data
[17:32:47] <wbs> and returns that it used 220 bytes of data from the source
[17:32:58] <wbs> you then feed bytes 220-4095 to the decoder and tells it to decode more data
[17:33:07] <wbs> which again returns 220 and the corresponding decoded audio data
[17:33:16] <wbs> at the end, you've decoded 18 frames correctly
[17:33:23] <wbs> and you've used 3960 bytes of the input
[17:33:28] <wbs> but you read 4096 bytes from file
[17:33:32] <Gottaname> but the 19th is the exception
[17:33:37] <Gottaname> so how does one handle it?
[17:33:45] <wbs> you normally use a container format
[17:33:50] <_av500_> one reads more data
[17:33:52] <votz> wbs: why doesnt the api-example.c use av_input_file(...) and av_read_frame(...), etc?
[17:34:06] <wbs> votz: because it's an example of libavcodec, not libavformat
[17:34:15] <votz> sensible enough :)
[17:34:20] <Gottaname> that would be output_example right?
[17:34:21] <ramiro> for libavformat there's output-example
[17:34:39] <Gottaname> ah, but output example lacks an audio decode
[17:34:46] <_av500_> and for all of it there is ffmpeg
[17:34:47] <wbs> yes, but don't you see the big picture already?
[17:34:59] <_av500_> and for all of it there is ffmpeg.c
[17:35:45] <Gottaname> wbs: yeah
[17:36:04] <wbs> normally, you would have a file format, and libavformat would handle that for you. or you could invent you own file format
[17:36:15] <wbs> you could put a 2-byte header for each data packet, saying how many bytes it is
[17:36:16] <votz> _av500_: ffmpeg.c can be kind of hard for some to parse for more specific use cases
[17:36:29] <wbs> then you read 2 bytes, saying how many bytes the packet is, and then read exactly that many bytes
[17:36:50] <Gottaname> that would work
[17:36:59] <Gottaname> god, I should have stayed more alert during SDL class
[17:37:07] <wbs> this has NOTHING to do with SDL
[17:37:25] <Gottaname> yeah, but it deals with roughly the same concept
[17:37:33] <wbs> uh, well, whatever
[17:37:37] <Gottaname> I used SDL with FFMPEG before
[17:38:00] <votz> what changed with avcodec_decode_aduio2 to avcodec_decode_audio3?
[17:38:04] <votz> *audio2
[17:38:24] <_av500_> the pkt, no?
[17:38:26] <wbs> votz: you provide an AVPacket instead of a plain buffer+size
[17:38:48] <votz> ah
[17:38:55] <votz> that simplifies things a bit
[17:39:00] <Gottaname> wbs: this would be a task better suited for avformat anyway
[17:39:32] <wbs> yes, it would
[17:39:58] <wbs> mpeg codec perhaps may provide such framing in the codec itself, but the behaviour seems to have changed at some point (rev 9144)
[17:42:55] <Gottaname> I'll tackle this tommorrow morning
[17:42:56] <Gottaname> good night all
[17:43:06] <BastyCDGS> good night
[18:23:06] <KotH> http://digitaldaily.allthingsd.com/20100520/googles-royalty-free-webm-video-may-not-be-royalty-free-for-long/
[18:29:27] <_av500_> old news
[18:29:57] <spaam> _av500_: .ch dont get news so fast ;)
[18:30:49] <_av500_> all the mountains make internet reception diffcult
[18:31:05] <ramiro> the journalists were too busy eating chocolate
[18:31:11] <kierank> and they are too busy eating fon due
[18:34:11] <_av500_> KotH: but lol at the comment that mentions metabox AG
[18:34:20] <_av500_> that wasindded a big fail iirc
[18:35:08] <CIA-93> ffmpeg: stefano * r23259 /trunk/libavformat/ (nut.c nut.h nutenc.c nutdec.c):
[18:35:08] <CIA-93> ffmpeg: Define ff_nut_video_tags and make Nut muxer and demuxer set it in
[18:35:08] <CIA-93> ffmpeg: codec_tag.
[18:35:08] <CIA-93> ffmpeg: stefano * r23260 /trunk/libavformat/nutdec.c:
[18:35:08] <CIA-93> ffmpeg: Make the nut decoder read the ff_nut_video_tags to detect codec id of
[18:35:09] <CIA-93> ffmpeg: the input file.
[18:35:10] <CIA-93> ffmpeg: This is required as Nut codec tags are not contained in
[18:35:10] <CIA-93> ffmpeg: ff_codec_bmp_tags.
[18:40:11] <BastyCDGS> so amiga stuff is finished uploading
[18:48:18] <DonDiego> siretart: i think baptiste's ogg muxer improvement is 0.6 material..
[18:49:51] <DonDiego> then there is the question what to do with the vp8 stuff
[18:50:00] <DonDiego> obviously nobody could expect this..
[18:51:02] <siretart> looking
[18:51:07] <CIA-93> ffmpeg: siretart * r23261 /branches/ (0.6 0.6/cmdutils.c 0.6/ffmpeg.c): (log message trimmed)
[18:51:07] <CIA-93> ffmpeg: Open 2-pass logfile in binary mode for both reading and writing.
[18:51:43] <CIA-93> ffmpeg: This fixes a regression on Windows introduced by r22769 in which the data read
[18:51:43] <CIA-93> ffmpeg: from the file was not properly zero terminated. The file was read as text,
[18:51:43] <CIA-93> ffmpeg: which caused the \r characters to be suppressed. Since the zero termination
[18:51:43] <CIA-93> ffmpeg: happens at the end of the buffer, and there was one byte less read per line,
[18:51:43] <CIA-93> ffmpeg: this caused the remaining space on the buffer to contain random data.
[18:53:01] <siretart> DonDiego: vp8 is a good question, I think if we don't have it ready for 0.6, we should promise it for 0.6.1
[18:53:18] <DonDiego> yes, exactly my thought
[18:53:28] <siretart> what's the status on webm/vp8 in trunk? - is trunk ready for it yet?
[18:53:33] <DonDiego> we would need to do 0.6.1 in close proximity
[18:53:43] <DonDiego> or wait a little more..
[18:53:57] * siretart feels 0.6 is already long overdue
[18:56:33] <DonDiego> yeah :-/
[19:02:06] <KotH> how about doing it ... now?
[19:04:34] <siretart> :-)
[19:06:05] <siretart> DonDiego: with 'baptiste's ogg muxer improvement' you mean r23231, right?
[19:07:20] <DonDiego> yes
[19:12:39] <CIA-93> ffmpeg: stefano * r23262 /trunk/libavfilter/vf_scale.c:
[19:12:39] <CIA-93> ffmpeg: Prefix value for flags with "0x", to make it clear that it is an
[19:12:39] <CIA-93> ffmpeg: hexadecimal value.
[19:13:17] <CIA-93> ffmpeg: siretart * r23263 /branches/ (4 files in 4 dirs):
[19:13:17] <CIA-93> ffmpeg: In ogg muxer, pack multiple frames into one page, much lower overhead
[19:13:17] <CIA-93> ffmpeg: backport r23231 by bcoudurier
[19:14:09] <CIA-93> ffmpeg: jai_menon * r23264 /trunk/ffplay.c:
[19:14:09] <CIA-93> ffmpeg: FFplay : Avoid manipulating NULL data pointers so that future checks
[19:14:10] <CIA-93> ffmpeg: remain valid. This fixes segfaults for those cases where data copy to
[19:14:10] <CIA-93> ffmpeg: this invalid pointer is attempted.
[19:15:52] <CIA-93> ffmpeg: jai_menon * r23265 /trunk/ffplay.c: Cosmetics : re-indent after last commit.
[19:16:41] <siretart> how much disk space does the fate repository take?
[19:18:26] <drv> the samples? about 300 M currently
[19:24:15] <siretart> ah, right. thanks
[19:24:46] <drv> now i am trying to update them and remembering why i avoid writing my own rsync commands :)
[19:24:58] <jai> :)
[19:25:40] <KotH> rsync -Pvrt --delete-during <src> <dst> ?
[19:25:48] <jai> for the release, wouldnt it make more sense to actually run the suite across all platforms?
[19:28:04] <siretart> jai: indeed, but I understand mike's mail that this was not possible
[19:30:36] <jai> siretart: ah, ok
[19:30:42] <jai> must've missed that
[19:31:05] <wbs> siretart: I guess he meant that there's no way to push the 0.6 to the current fate machines and use them to test it
[19:34:27] <siretart> wbs: yes, and exactly that would be extremly helpful
[19:43:36] <lu_zero> yawn
[19:43:46] * lu_zero is feeling quite lazy
[19:48:09] <lu_zero> wbs: I'm eventually trying your reorder patch
[19:49:23] <lu_zero> I just need to recall how to use netem correctly
[19:59:48] <siretart> DonDiego: I've just managed to build a shared ffmpeg 0.6 on ia64. I'll try to do a fate run on that machine as well.
[20:01:07] <thresh> i've got a HPUX/ia64 if you want
[20:02:55] <DonDiego> cool
[20:03:02] * DonDiego pets siretart
[20:04:01] <siretart> thresh: did ffmpeg 0.5 work on that machine?
[20:04:26] <siretart> DonDiego: looks great so far, the machine has plenty of ram but isn't the fastest machine
[20:06:10] <thresh> siretart: oh, never tried
[20:06:28] <siretart> DonDiego: shall we test on some other arch as well, or do we consider this 'good enough'?
[20:07:04] <siretart> thresh: a regression would be bad, but if it never worked, I wouldn't delay the release for that
[20:08:35] <siretart> yay, fate test suceeded :-)
[20:11:11] <DonDiego> do we have support for chained ogg files now?
[20:11:35] <mru> depends on what you mean by support
[20:11:48] <mru> they're not semantically clear
[20:16:37] <DonDiego> i'm writing up a mail to the foms list
[20:16:40] <wbs> lu_zero: good :-)
[20:16:49] <DonDiego> mentioning xiph-related changes in 0.6
[20:17:19] <wbs> lu_zero: if you'd have time to add a comment on the discussion with michael on how to handle it in the best way regarding low delay and not queueing too much, it would be appreciated :-)
[20:19:11] <lu_zero> I just did now
[20:20:14] <wbs> great, thanks!
[20:20:15] <thresh> god i wish git.ffmpeg.org provided branches also
[20:20:17] <thresh> who do I poke?
[20:20:53] <thresh> or who do I beer?
[20:21:33] <siretart> DonDiego: do you think we can do a 0.6 release today or tomorrow? - what's left on your list?
[20:22:27] <ramiro> siretart: thanks for the backport
[20:22:57] <DonDiego> nothing much..
[20:23:00] <lu_zero> wbs: thanks for you contribution =)
[20:23:54] <siretart> ramiro: thanks for nominating it :-)
[20:25:42] <wbs> lu_zero: thanks for supporting it :-)
[20:32:44] <siretart> DonDiego: what about my first question?
[20:34:01] <DonDiego> hmm
[20:34:20] <DonDiego> well, we might as well go for it
[20:34:27] <DonDiego> siretart: ready to do it today?
[20:36:23] <siretart> I'm currently doing a compile/fate run on a debian powerpc portmachine right now, but I don't expect failures
[20:36:29] <siretart> so in principle, sure, why not
[20:37:46] <DonDiego> ok
[20:38:02] <siretart> it's a shame that vp8/webm is not in 0.6, but since that's not in trunk either, I think we can defer that to 0.6.1
[20:39:19] <DonDiego> we could do 0.5.2 along with it
[20:39:31] <DonDiego> and yes, we could defer vp8 stuff to 0.6.1
[20:48:37] <bcoudurier> hi guys
[20:53:30] <DonDiego> hi
[20:53:41] <saintd3v> hi onjoin
[20:53:50] <DonDiego> bcoudurier: say, did you make overhead comparisons with libogg?
[20:54:20] <elenril> bcoudurier: can you fix author->artist thing in mov demuxer?
[20:55:05] <DonDiego> ah, just saw your reply..
[20:55:21] <bcoudurier> elenril, I thought you were going to do it
[20:55:49] <bcoudurier> but that's fine, it's a oneliner, I can do it right now
[20:56:39] <elenril> cool, thanks
[20:56:51] <DonDiego> siretart: reimar just proposed an ogg patch on -devel, hmmm
[20:57:09] <DonDiego> the changelog contains nothing about ogg and theora-related changes
[20:58:53] <siretart> DonDiego: hm. I don't see reimar's mail. what's the subject?
[20:59:01] <enkidu> I promised to make a patch for grouped streams and droping zombie connections, but I realised, that it need some more work
[20:59:10] <siretart> I see his '[PATCH] enable generic index for ogg demuxer' - do you mean that?
[20:59:39] <enkidu> even it mostly works correct
[21:00:19] <DonDiego> yes
[21:02:11] <DonDiego> Yuvi: you around?
[21:03:18] <siretart> ugh..  I somehow misread your line as if reimar had commented on an existing patch. - now, it's surely a new one
[21:04:11] <CIA-93> ffmpeg: bcoudurier * r23266 /trunk/libavformat/ (movenc.c mov.c avformat.h): change author metadata to artist in mov de/muxer
[21:05:00] <elenril> avformat?
[21:05:12] <DonDiego> oops
[21:05:27] <DonDiego> the changelog was not updated for the branch
[21:05:36] <CIA-93> ffmpeg: bcoudurier * r23267 /trunk/libavformat/movenc.c: albm 3gp tag has optional track field not date
[21:05:37] <DonDiego> i.e. the trunk changelog was not branched..
[21:07:01] <CIA-93> ffmpeg: bcoudurier * r23268 /trunk/libavformat/movenc.c: write 3gp perf tag for artist metadata
[21:10:39] <bcoudurier> elenril, yes I bumped the micro version
[21:10:46] <bcoudurier> so people complaining can check it
[21:10:56] <CIA-93> ffmpeg: bcoudurier * r23269 /trunk/libavformat/avformat.h: oups, 100l, revert unrelated hunk from commit r23266
[21:12:28] <elenril> ah
[21:12:29] <bcoudurier> this is what happens when you change things at the last minute :(
[21:12:37] <elenril> :)
[21:12:45] <elenril> DonDiego: i think that fix should go into 0.6
[21:12:55] <bcoudurier> DonDiego, do you know how you can output i420 with mplayer and not yv12 ?
[21:13:08] <DonDiego> format filter i think
[21:14:03] <bcoudurier> says md5sum does support i420 :(
[21:16:20] <_av500_> wtf, nero ag sues mpegla
[21:16:34] <siretart> uh? in that direction?
[21:16:38] <mru> in january
[21:18:27] <siretart> elenril: what svn revision?
[21:19:03] <elenril> siretart: r23266/r23269
[21:20:36] <CIA-93> ffmpeg: diego * r23270 /trunk/Changelog: Reflect the 0.6 branch in the Changelog.
[21:21:41] <bcoudurier> DonDiego, we are waiting for vp8 right ?
[21:22:09] <DonDiego> we dunno, really
[21:22:19] <DonDiego> vp8 might go in 0.6.1 as well
[21:22:28] <DonDiego> it's not sure how long this will take
[21:22:43] <DonDiego> and 0.6 has been delayed for too long already
[21:25:31] <siretart> bcoudurier: if vp8/webm was already in trunk, that would be something else, but I don't see those patches applied in say, a week
[21:26:16] <siretart> bcoudurier: waiting a few more weeks to get that tested and integrated and then backport it to a point release doesn't seem unreasonable
[21:26:42] <siretart> OTOH, we could of course delay for another 2-3 weeks and have vp8 as excuse ;-)
[21:26:56] <siretart> btw, fate/0.6/powerpc suceeded :-)
[21:28:32] <BastyCDGS> so I just wrote to ML my ideas about MOD support
[21:29:59] <bcoudurier> it seems stupid to release without vp8
[21:30:06] <bcoudurier> everybody will notice it
[21:31:11] <CIA-93> ffmpeg: diego * r23271 /branches/0.6/RELEASE: small spelling fixes
[21:31:20] <siretart> hm. the headline 'ffmpeg misses vp8' doesn't look great, indeed
[21:53:50] <Yuvi> DonDiego: pong
[21:55:21] <spaam> BastyCDGS: is it a big diff between .mod and .xm ? :)
[21:55:43] <BastyCDGS> like IFF-8SVX => RIFF-WAVE
[21:56:09] <BastyCDGS> xm supports 16-bit samples which mod doesn't and also instruments
[21:56:14] <BastyCDGS> mod only knows samples
[21:56:30] <BastyCDGS> otherwise they're pretty similar
[21:56:39] <spaam> ok :)
[21:56:40] <BastyCDGS> just the internal file format is totally different
[21:57:12] <BastyCDGS> the biggest change was made with IT
[21:57:27] <BastyCDGS> that's almost like DPaint => GIMP/Photoshop
[21:57:34] <spaam> hehe ok :)
[21:57:48] <CIA-93> ffmpeg: banan * r23272 /trunk/libavformat/aea.c:
[21:57:48] <CIA-93> ffmpeg: Fix detection of some stereo atrac files by not comparing the
[21:57:48] <CIA-93> ffmpeg: block size mode and info byte. Reduced the probe score just in case.
[21:58:16] <DonDiego> Yuvi: could you update the changelog with your theora and ogg changes?
[21:58:37] <Yuvi> sure
[21:58:41] <DonDiego> my bad memory will likely miss half of them, for you it should be a matter of seconds..
[21:59:55] <Yuvi> did r22931 get into 0.6? it should if not
[22:00:02] <BastyCDGS> DonDiego, changelog? hmm maybe it's time to write a changelog for IFF as well, since there has changed quite a bit now
[22:00:35] <BastyCDGS> spaam, what do you think of my MOD post?
[22:00:41] <BastyCDGS> was it clear and comprehensive?
[22:00:59] <kierank> some of the things like MOD in AVI was scary
[22:01:06] <kierank> just because it can be done doesn't mean it should
[22:01:11] <BastyCDGS> someone here in #ffmpeg-devel had this idea ;)
[22:01:21] <ramiro> scary nonetheless
[22:01:29] <BastyCDGS> but why?
[22:02:27] <CIA-93> ffmpeg: banan * r23273 /trunk/libavformat/aea.c: 10l, now the score is reduced
[22:03:23] <BastyCDGS> ramiro, they of course can convert the MOD to PCM before putting it into AVI ;)
[22:03:35] <BastyCDGS> or mp3 whatever you want
[22:03:53] <BastyCDGS> at least when the video is release-ready
[22:04:10] <kierank> it's still in avi
[22:04:23] <Yuvi> siretart: could you port r22931 to 0.6 please?
[22:04:39] <BastyCDGS> no I meant putting the PCM result instead of the MOD in the avi, the MOD itself is just used for composing
[22:05:22] <BastyCDGS> although it could be a good idea to use the MOD itself unless the movie is finished (for easier editing the musical part)
[22:05:40] <Yuvi> or nm
[22:05:45] <Yuvi> the branch was created after that
[22:05:50] <BastyCDGS> like you use lossless audio for editing a PCM sample and release the final as mp3/ogg vorbis
[22:06:58] <kierank> it's still putting something in avi ;)
[22:07:42] <siretart> Yuvi: it already is?
[22:07:47] <DonDiego> BastyCDGS: was iff added without changelog entry?
[22:08:16] <BastyCDGS> DonDiego, I meant the changes I made since I started with FFmpeg
[22:08:19] <CIA-93> ffmpeg: diego * r23274 /branches/0.6/VERSION: Add VERSION file for 0.6 release.
[22:08:26] <BastyCDGS> don't know if there's an initial changelog for iff
[22:09:01] <BastyCDGS> did a grep for IFF:
[22:09:02] <BastyCDGS> - IFF PBM/ILBM bitmap decoder
[22:09:02] <BastyCDGS> - AIFF/AIFF-C audio format, encoding and decoding
[22:09:02] <BastyCDGS> - TIFF picture encoder and decoder
[22:09:02] <BastyCDGS> - Beam Software SIFF demuxer and decoder
[22:09:02] <BastyCDGS> - IFF demuxer
[22:09:05] <BastyCDGS> that's all
[22:15:09] <Yuvi> DonDiego: don't know if all the various bugfixes should be mentioned, which leaves it at http://pastie.org/973834 (dunno about the ogg stuff even)
[22:16:20] <DonDiego> BastyCDGS: ok, so the demuxer is mentioned..
[22:16:44] <BastyCDGS> yes but only mentioned no list of features, should I add something like this?
[22:16:45] <siretart> Yuvi: that reads great to me
[22:17:09] <DonDiego> i'll tweak and apply it, thanks
[22:17:55] <Yuvi> actually a quick run puts the speedup at around 35%
[22:21:08] <CIA-93> ffmpeg: conrad * r23275 /trunk/libavformat/matroskadec.c: matroskadec: Revert adding the doctype to metadata; it has no meaning elsewhere
[22:23:12] <bcoudurier> is reimar on irc sometimes ?
[22:23:34] <BastyCDGS> one question regarding to keyframes
[22:23:47] <BastyCDGS> should the keyframe bit be set for single images?
[22:23:53] <ramiro> bcoudurier: no
[22:24:06] <BastyCDGS> I ask because I'm thinking why images get black with ffplay after resize or switch from/to fullscreen
[22:24:17] <BastyCDGS> that it doesn't redraw because the keyframe flag is missing?
[22:24:45] <bcoudurier> yes you must set it
[22:25:12] <janneg> lol "But absolute power has corrupted MPEG LA absolutely"
[22:25:30] <BastyCDGS> just took a look, iff_read_packet has a line:
[22:25:30] <BastyCDGS>     if(iff->sent_bytes == 0)
[22:25:30] <BastyCDGS>         pkt->flags |= AV_PKT_FLAG_KEY;
[22:25:36] <BastyCDGS> so it sets it but only once
[22:25:46] <mru> janneg: if I were in charge and received that I'd send it back with the words "get real"
[22:25:56] * janneg didn't expected to read that in Nero's antitrust complaint against mpeg la
[22:26:04] <mru> not saying they haven't done anything wrong
[22:26:16] <mru> but such language does not belong in legal proceedings imo
[22:27:54] <janneg> yes, very strange. I would have asked if that is intended language even if not in charge
[22:28:28] <mru> it's full of stuff like that
[22:31:20] <kierank> I think it's because of a bad translation
[22:31:41] <janneg> like "to add insult to injury", maybe it's just a joke
[22:32:18] <mru> kierank: it's signed by a US lawyer
[22:32:38] <janneg> kierank: their LA attorneys should have fixed that
[22:39:24] <BastyCDGS> Fuck, by mistake I linked FFplay with libpthread (which is required by libxvidcodec) and there was a conflict between pth and sdl threads, so false alert - everything works correctly!
[22:39:39] <BastyCDGS> ami_stuff just wrote me this per mail while he was testing my latest patches
[22:39:55] <BastyCDGS> thought would be a good idea to post that here, maybe we can fix this conflict
[22:40:26] <BastyCDGS> false alert was:
[22:40:26] <BastyCDGS> Please try to view some iff file with ffplay, resize the sdl window (so you will get black screen) and next press "f" key a few times to swicht between fullscreen/windowed mode.
[22:40:26] <BastyCDGS>  
[22:40:26] <BastyCDGS> Here after some time the stats (time value) stop to be printed in the console and quit button or "q" key doesn't work, so I can't exit ffplay.
[22:45:28] <BastyCDGS> suggested fix by me:
[22:45:28] <BastyCDGS> We either should do not allow this at all or provide a fix:
[22:45:28] <BastyCDGS> If pthreads is enabled then FFplay should also use pthreads instead of SDL threads.
[22:45:28] <BastyCDGS>  
[22:45:28] <BastyCDGS> What do you think?
[23:12:32] <bcoudurier> BastyCDGS, indeed, a patch changing this is welcome I guess
[23:18:40] <CIA-93> ffmpeg: diego * r23276 /trunk/Changelog: Mention some more changes related to HTML 5 issues.
[23:20:30] <CIA-93> ffmpeg: diego * r23277 /trunk/Changelog: small wording fix
[23:29:15] <CIA-93> ffmpeg: diego * r23278 /branches/ (0.6 0.6/Changelog): Merge last round of Changelog updates for HTML 5 features.
[23:34:42] <CIA-93> ffmpeg: reimar * r23279 /trunk/libavformat/oggdec.c:
[23:34:42] <CIA-93> ffmpeg: Enable AVFMT_GENERIC_INDEX for Ogg demuxer. This avoids the many
[23:34:42] <CIA-93> ffmpeg: seeks needed for binary search when seeking to a previously seen
[23:34:42] <CIA-93> ffmpeg: location.
[23:36:43] <mru> but monty says that's not necessary...
[23:56:14] <bcoudurier> mru
[23:56:32] <bcoudurier> can you please help me moving x86/cpuid.c to libavutil ?
[23:56:48] <mru> what's the problem?
[23:57:07] <bcoudurier> I'm not sure how do you want libavutil Makefile to be
[23:57:22] <mru> same as libavcodec is now of course
[23:57:26] <bcoudurier> OBJS-$(HAVE_MMX) += x86/cpuid.c ?
[23:58:56] <bcoudurier> or separate Makefile in x86 ?
[23:59:19] <mru> I guess a separate makefile is overkill for this one case
[23:59:28] <mru> but shouldn't that be $(ARCH_X86) ?
[23:59:49] <bcoudurier> dunno
[23:59:59] <bcoudurier> cpuid.o is under HAVE_MMX in libavcodec