[FFmpeg-devel-irc] IRC log for 2010-09-09

[irc at mansr.com]

[00:20:04] <Compn> anyone feel like building ffmpeg with a small change ?
[00:20:31] <Compn> i'm wondering if turning on parsing for amr-in-asf will allow the 7A21 / 7A22 gsm-amr (amr in asf) to play
[00:40:05] <xxthink> does someone know the function of MBAtab in libmpeg2?
[01:40:53] <astrange> is 7A22 a twocc?
[01:50:52] <Compn> yes
[01:50:56] <Compn> 0x7A22
[01:51:31] <Compn> astrange : http://samples.mplayerhq.hu/A-codecs/amr/gsm-amr/
[01:51:42] <Compn> actually i dont think it will help , i havent seen any amr decoder handle these
[02:56:38] <funman> guten morgen,
[03:07:25] <Compn> you again!
[03:07:29] <Compn> heh
[03:13:17] <funman> Compn: me again?
[03:18:45] <Compn> just kidding funman
[03:19:46] <funman> nice to hear
[03:19:55] <funman> i thought the matrix was being disrupted or something ;)
[03:21:17] <Compn> still no way to force codecs in ffmpeg ?
[03:21:30] <Compn> e.g. if there is a new fourcc or wrong fourcc
[03:22:51] <funman> -vcodec doesn't work on input stream?
[03:23:29] <Compn> oh i guess it does
[03:23:47] <Compn> tho, this is a nonstandard file, so the demuxer goes nuts
[03:23:52] <Compn>   Stream #0.0: Video: mpeg4, 94x1819440243 [PAR 1:1 DAR 0:1], 30 fps, 29.97 tbr, 30 tbn, 29.97 tb
[03:24:06] <Compn> resolution looks a bit lopsided
[03:24:59] <Compn> funman : what about forcing a res ?
[03:25:32] <funman> -s works when the res cant be guessed but i dont know if it forces the demuxer to ignore res from the stream
[05:06:38] <CIA-11> libswscale: ramiro * r32106 /trunk/libswscale/swscale-test.c: av_fill_image_linesizes -> av_image_fill_linesizes
[05:19:46] <funman> http://www.relisoft.com/science/Physics/sound.html
[05:35:27] <funman> my jew's harp give a peak very close to 500Hz on different sounds
[07:53:03] <wbs> hmm.. for the G722 decoder, I'm planning to add fate tests, too
[07:53:23] <mru> good plan
[07:53:47] <wbs> the standard comes with reference test samples, but the document accompanying the reference samples also come with this notice: "All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the ITU."
[07:54:14] <mru> we could just ask them
[07:54:21] <mru> maybe they don't mind
[07:54:29] <wbs> true
[07:55:04] <wbs> what's the procedure of adding the samples then, btw? is that something I should have access to?
[08:08:24] <KotH> moin
[08:09:46] <mru> morning KotH
[09:52:50] <feliks> hi guys, could someone of you tell me what the svn revision of the 0.5.1 release is? #ffmpeg is unable to tell (yet). thanks!
[09:53:10] <av500> its in the release branch
[09:53:54] <av500> r22146
[09:54:46] <feliks> great, thanks a lot, av500!
[11:15:28] <kierank> i love the tackiness of promo videos: http://www.youtube.com/watch?v=vF0ALmcCiLA&feature=player_embedded
[11:18:34] <spaam> kierank: i want one! :O
[11:20:31] <kierank> I want to start a processor company called LEG
[11:22:40] <lu_zero> why?
[11:22:51] <kierank> so you can have ARM and LEG
[11:24:58] <J_Darnley> How much will they cost? *chuckle*
[11:25:07] <kierank> finally
[11:25:10] <lu_zero> J_Darnley: a finger
[11:25:16] <kierank> the wait was killing me J_Darnley
[11:53:25] <pentanol> kierank how about other parts of body?
[16:30:19] <mru> which reminds me, whatever happened to ami_stuff?
[16:31:02] <kierank> he finally realised that the amiga is long dead?
[16:31:26] <mru> maybe he was replaced with basty
[16:31:42] <av500> mru: dont forget the C64 guy!
[16:32:35] <kierank> av500: the guy with the epic name
[16:32:44] <kierank> bindhammer iirc
[16:32:56] <mru> what's so epic about that?
[16:33:02] <kierank> it has the word hammer in it
[16:33:07] <mru> sound fairly typically german
[16:33:28] <av500> donnerhammer would be better
[18:09:37] <janneg> mru: I've refreshed your av_get_cpu_flags clean up patch. I hope you don't mind
[18:10:52] <mru> I mind
[18:11:55] <_av500_> http://www.readwriteweb.com/archives/vlc_submits_ipad_app_to_app_store.php
[18:12:05] <_av500_> or did i miss that?
[18:12:28] <mru> old news
[18:12:41] <mru> and it's little more than vapourware
[18:13:05] <mru> until maybe, hopefully, it possibly gets approved
[18:13:28] <mru> janneg: I don't like adding random weird stuff to internal.h
[18:13:28] <bilboed> I thought the apple store license was incompatible with (L)GPL
[18:13:47] <mru> bilboed: not if the copyright owners say it's ok
[18:14:21] <mru> besides, that was just the fsf bitching because that's what they do
[18:15:11] <bilboed> unless vlc requires copyright assignement... I wish them luck tracking all contributors :)
[18:15:20] <mru> janneg: such headers only lead to things getting far more entangled than they should be
[18:16:12] <mru> btw, is it just me are the comments in libavutil/cpu.h a little bizarre?
[18:16:22] <mru> #define AV_CPU_FLAG_ALTIVEC      0x0001 ///< standard
[18:16:25] <mru> wtf
[18:16:38] <mru> standard what?
[18:16:42] <mru> what standard?
[18:16:44] <janneg> mru: I'm not particular happy with it but it looked less clumsy than adding an extra header file for the cpu specific functions
[18:16:58] <mru> I'd rather leave them in cpu.h then
[18:18:33] <mru> bilboed: I honestly don't see a problem distributing gpl apps through the app store as long as you somehow tell the users how to get the source
[18:19:00] <mru> since apple don't own the copyrights they can't alter the licence terms
[18:19:14] <mru> any attempt of them to do so must be considered void
[18:19:21] <janneg> mru: it was added in r1283 as '/* standard AltiVec */'
[18:19:44] <mru> only slightly less confusing
[18:19:49] <mru> the name already says altivec
[18:20:06] <mru> now the reader wonders what non-standard altivec might be and how to detect it
[18:21:25] <janneg> was still the same in r15770 when moved to avcodec.h
[18:21:36] <mru> where was it before?
[18:21:50] <janneg> dsputil.h
[18:21:58] <mru> fantastic
[18:22:08] <mru> oh well, we're getting better
[18:23:05] <janneg> flame saste, he changed it in r25040
[18:25:15] <mru> he clipped the _SLOW doxy too
[18:26:37] <mru> hmm, we should make those functions return unsigned too
[18:43:23] <mru> janneg: http://git.mansr.com/?p=ffmpeg.mru;a=shortlog;h=refs/heads/master
[18:43:34] <mru> ^^ what I was about to commit
[18:51:04] <janneg> mru: looks good
[18:51:58] <mru> committing
[18:52:39] <CIA-11> ffmpeg: mru * r25084 /trunk/libavutil/ (9 files in 4 dirs):
[18:52:39] <CIA-11> ffmpeg: Clean up av_get_cpu_flag()
[18:52:39] <CIA-11> ffmpeg: Instead of defining functions in per-arch header files included
[18:52:39] <CIA-11> ffmpeg: by the main cpu.c, define them normally and call them from the
[18:52:39] <CIA-11> ffmpeg: generic one.
[18:52:40] <mru> and wait for fate to tell if anything broke horribly
[18:52:40] <CIA-11> ffmpeg: mru * r25085 /trunk/libavutil/cpu.c: Cache detected CPU flags
[19:05:23] <peloverde> Do we have any sort of public domain 5.1 audio test clip?
[19:10:43] <kierank> dunno about public domain but there's one in samples.mplayerhq.hu
[19:18:12] <peloverde> I'd rather distribute test streams that are PD or not copyrightable or copyright me
[19:20:41] <peloverde> Also most of the broken samples that people uploaded to samples.mplayerhq.hu are in mkv and after remuxing them to mp4 with FFmpeg the reference decoder seems to complain about timestamp issues
[19:21:23] <peloverde> So I'd like to make sure that if a decoder is choking on them it's from the actual AAC content not the timestamp problems
[19:21:46] <kierank> i think the big buck bunny soundtrack is 5.1
[19:22:12] <CIA-11> ffmpeg: mstorsjo * r25086 /trunk/ (6 files in 3 dirs): Add G.722 ADPCM audio decoder
[19:23:12] <peloverde> I think I will just create tones in audacity, I don't want something long form and I want to be able to verify that all 6 channels are present
[19:28:47] <CIA-11> ffmpeg: mstorsjo * r25087 /trunk/libavformat/ (Makefile rawenc.c allformats.c avformat.h rawdec.c): Add a muxer and demuxer for raw G.722
[19:41:53] <CIA-11> ffmpeg: mru * r25088 /trunk/libavutil/x86/cpu.c: Add missing #include <string.h> in x86/cpu.c
[20:01:02] <Kovensky> <@peloverde> Do we have any sort of public domain 5.1 audio test clip? <-- there's one on the CCCP test dir that's specifically for testing 5.1
[20:01:33] <Kovensky> http://www.cccp-project.net/beta/test_files/%5BCCCP%5D_Manhole_Test_Your_5.1_%5Bmodified%5D.mkv http://www.cccp-project.net/beta/test_files/%5BCCCP%5D_Manhole_Test_Your_5.1_%5Brevamped%5D.mkv (dunno the difference between them)
[20:03:59] <merbanan> er wtf did just happened ?
[20:04:33] <Kovensky> merbanan: ?
[20:04:45] <merbanan> http://thread.gmane.org/gmane.linux.kernel.wireless.general/55418
[20:07:16] <Kovensky> :o
[20:08:00] <peloverde> Someone who knows the mp4 muxer may want to look at http://roundup.ffmpeg.org/issue2224
[20:23:18] <bcoudurier> hi guys
[20:23:43] <bcoudurier> peloverde, are you around ?\
[20:23:48] <peloverde> yes
[20:24:10] <peloverde> the problem may lie somewhere in the adts parser but I don't know where to look on the mov side of things
[20:24:33] <bcoudurier> did you upload the file ? :>
[20:24:33] <CIA-11> ffmpeg: reimar * r25089 /trunk/libavcodec/cscd.c: Fix indentation.
[20:26:33] <peloverde> I uploaded the input .aac file to roundup
[20:27:29] <peloverde> hmm, I failed at that, one second I'll put it in incoming
[20:28:36] <peloverde> it is in incoming/bad_concat.aac
[20:36:08] <peloverde> (ignore the fact that FFmpeg gets pissy half way through if you actually try to decode it)
[20:36:23] <peloverde> (I was going to tweak the aac channel code to handle it)
[20:41:16] <peloverde> I hope this isn't some sort of annoying timebase problem
[20:43:38] <lu_zero> hi
[20:45:43] <lu_zero> 20:19 <@mru> now the reader wonders what non-standard altivec might be and how  to detect it
[20:46:01] <lu_zero> the closest thing is the xbox360 extension
[20:46:31] <mru> I doubt the author that stupid comment had that in mind
[20:59:03] <CIA-11> ffmpeg: mstorsjo * r25090 /trunk/ffmpeg.c: Update the audio sample rate when doing lowres audio decoding, before opening the decoder
[21:13:13] <lu_zero> since we also have VMX-not-different-than-altivec-but-different
[21:14:03] <lu_zero> but I doubt anybody would try to discover which is which and remove the altivec stream/cache instruction or replace them with the ppc ones...
[21:15:19] <kierank> wow nearly 30 mins or trolling
[21:17:44] <peloverde> Why is audio timebase based on samples per second and not audio frames per second
[21:18:39] <janneg> lu_zero: I doubt Micheal knew of the xbox360 at the end 2002
[21:18:41] <_troll_> define frame
[21:19:24] <_troll_> there is nothing fundamental about the audio frame
[21:21:34] <lu_zero> janneg: eh eh
[21:22:38] <mru> setting the timebase to the length of an audio frame would be like using gop length for video
[21:22:44] <mru> some codecs even have variable frame size
[21:22:48] <mru> like vorbis
[21:22:50] <bcoudurier> peloverde, set the timebase to lcm of all allowed sample rates
[21:22:54] <bcoudurier> that should fix it
[21:24:36] <peloverde> really, that seems strange?
[21:25:25] <bcoudurier> not really it's like mp3 demuxer does
[21:25:35] <bcoudurier> you could set it to the sample rate too
[21:25:43] <bcoudurier> currently it's 90000
[21:25:46] <peloverde> It is set to the sample rate atm
[21:25:50] <bcoudurier> no
[21:25:54] <bcoudurier> it's set to 90000
[21:26:46] <peloverde> but then it gets overridden
[21:26:55] <peloverde> I put a debug print in av_set_pts_info()
[21:27:12] <peloverde> I see "time_base 1 90000" twice and "time_base 1 44100" once
[21:27:23] <peloverde> (in that order)
[21:27:50] <bcoudurier> ffmpeg -debug 1 -i <file> print 1/90000
[21:28:02] <bcoudurier> I don't where it could be overriden though
[21:28:09] <peloverde> ff_raw_read_header() calls av_set_pts_info(st, 64, 1, st->codec->sample_rate)
[21:34:23] <bcoudurier> adts_aac_read_header ?
[21:36:41] <peloverde> what about adts_aac_read_header()?
[21:37:03] <astrange> BBB: what's the status of those h264 yasm patches?
[21:38:47] <BBB> will commit in 1 day or so
[21:38:52] <BBB> nobody reviewed the last one yet
[21:38:58] <BBB> with that, all's in yasm
[21:39:00] <BBB> no more inline asm
[21:39:07] <BBB> please help me kill inline asm
[21:41:16] <astrange> i'll look at xvid sse2 again at some point, maybe i can untangle it and add sse4 too
[21:41:36] <wbs> can someone copy http://samples.mplayerhq.hu/A-codecs/g722/conf-adminmenu-162.g722 into fate-samples somewhere? I mailed ITU and asked for permission to redistribute their test vectors, so if that works out, I'll add them too later
[21:42:55] <peloverde> The time base doesn't get set to the sample rate until the after the pts is all calculated
[21:47:25] <bcoudurier> where is that ?
[21:47:34] <bcoudurier> it seems to me that the demuxer used is in aacdec.c
[21:50:25] <Vitor1001> wbs: You don't have the password to samples?
[21:50:40] <wbs> Vitor1001: nope
[21:52:46] <Vitor1001> wbs: Don't forget to let 24 hours pass between uploading the samples and committing the test to let boxes the time to sync
[21:53:39] <wbs> yeah
[21:53:53] <wbs> do all test machines sync daily, or is it only "most of them"?
[21:54:32] <Vitor1001> wbs: Nothing is waranteed
[21:54:38] <Vitor1001> I'd say all in 48h
[21:55:12] <Vitor1001> But I think 24h is a good time. It makes more sense to flame admins tha sync less often
[21:55:32] <wbs> true, and with rsync, more frequent syncs doesn't cost much bandwidth anyway
[21:55:43] <Vitor1001> indeed
[22:10:42] <peloverde> How are demuxers that use parsers supposed to set a timebase?
[22:19:53] <pentanol> peloverde it suppose to be after that 1153:                st->parser = av_parser_init(st->codec->codec_id);
[22:24:42] <pentanol> peloverde in that source ./libavformat/utils.c
[22:29:03] <peloverde> The parser usually gets initialized earlier
[22:30:49] <mru> what is it with michael and his blind love for inline asm?
[22:31:39] <mru> it's simply a matter of using the right tool for the job
[22:31:47] <mru> for most of our asm, that tool is yasm
[22:35:14] <BBB> yes please
[22:36:30] <Dark_Shikari> mru: He likes what he used.
[22:36:32] <Dark_Shikari> Whatever it was.
[22:36:34] <Dark_Shikari> Even if it sucked/.
[22:36:56] <mru> that's a bizarre attitude
[22:37:27] <mru> if I use something as awful as inline asm, I pretty quickly come to hate it passionately
[22:37:30] <BBB> Dark_Shikari: can you commit the h264_idct_sse2.asm license change (or pengvado)?
[22:37:46] <BBB> maybe back then yasm didn't exist?
[22:37:56] <mru> nasm sure did
[22:38:14] <Dark_Shikari> BBB: give me a patch and a commit message
[22:38:23] <mru> http://xkcd.com/763/
[22:38:25] <BBB> uh, ok, will send it tonight
[22:55:12] <bcoudurier> peloverde, mp3 has the same problem
[22:55:18] <bcoudurier> did you try to set the time base to the lcm ?
[22:55:31] <peloverde> aac can handle arbitrary samplerates
[22:57:36] <peloverde> hmm... they aren't allowed in ADTS
[23:05:52] <peloverde> bcoudurier: LCM works
[23:06:06] <peloverde> can I go ahead and commit?
[23:10:29] <bcoudurier> sure
[23:16:16] <CIA-11> ffmpeg: alexc * r25091 /trunk/libavformat/aacdec.c: adts demuxer: Set the time base to be the LCM of all ADTS sample rates.
[23:17:57] <astrange> what's the largest time value you can store with that?
[23:25:20] <peloverde> How do I calculate that?
[23:28:29] <astrange> 2^64-1 / 28224000 seconds
[23:28:53] <astrange> ok, a lot
[23:29:01] <astrange> *63