[FFmpeg-devel-irc] IRC log for 2010-03-28

[irc at mansr.com]

[01:15:56] <CIA-24> ffmpeg: aurel * r22705 /trunk/libavformat/oggparseskeleton.c: correct first pts for ogg skeleton
[03:51:47] <Emess> anyone able to tell me what order libavcodec does 5.1 and 6.1 flac in?
[05:09:30] <Dark_Shikari> pentanol: so, want to write our own qsort? ;)
[05:10:18] <pengvado> problem is, it's not just writing our own. it has to have a hardcoded comparison function.
[05:10:48] <pengvado> I suppose the entire qsort could be a macro...
[05:12:39] <Dark_Shikari> sure, that'd work
[05:12:41] <Dark_Shikari> or make it a template
[05:13:37] <pentanol> Dark_Shikari hi our and own are wrong unites ;)
[05:14:27] <Dark_Shikari> ?
[05:16:02] <pentanol> you first asks me about qsort
[05:16:17] <Dark_Shikari> lol
[05:16:23] <Dark_Shikari> autocomplete, lol
[05:16:26] <Dark_Shikari> pengvado: ;)
[05:16:51] <Dark_Shikari> but yeah, pengvado, I would think qsort should naturally be a macro
[05:16:56] <Dark_Shikari> the fact that it isn't is an artifact of C
[05:18:50] <astrange> qsort is typically recursive too
[05:19:29] <pengvado> glibc's isn't recursive. or rather, they implemented their own stack, rather than using C function calls.
[05:19:40] <Dark_Shikari> lol
[05:20:34] <pengvado> I would think qsort should naturally take a closure. the fact that it's a function pointer instead is an artifact of C.
[05:21:02] <Dark_Shikari> exactly
[05:28:57] <pengvado> oh wow, just excluding short vlc codes from the sort helps a bunch
[05:30:28] <Dark_Shikari> why would that help that much?
[05:30:33] <Dark_Shikari> short ones should make up only a small portion
[05:31:05] <pengvado> when you have 1300 codes, and "short" is <=11 bits, it doesn't have to be a small fraction
[05:32:58] <Dark_Shikari> how can you get away with not sorting them then
[05:33:49] <pengvado> @param codes
[05:33:49] <pengvado> descriptions of the vlc codes
[05:33:49] <pengvado> These must be ordered such that codes going into the same subtable are contiguous.
[05:33:53] <pengvado> Sorting by VLCcode.code is sufficient, though not necessary.
[05:34:16] <Dark_Shikari> ahhhh
[06:42:19] <Dark_Shikari> mru: ok, it isn't flv
[06:42:24] <Dark_Shikari> both mp4 and flv desync due to the bitstream errors
[06:42:25] <Dark_Shikari> this is bad.
[06:48:00] <Dark_Shikari> -vsync 1 fixes it.
[07:18:57] <mru> Dark_Shikari: well, blame michael
[07:19:19] <Dark_Shikari> the vsync options seem to be impenetrable
[07:19:20] <Dark_Shikari> even code-wise
[07:19:30] <kshishkov> is no sync done when none is requested  a bad thing?
[07:19:40] <mru> I've always been against that tampering with timestamps
[07:19:48] <Dark_Shikari> kshishkov: by default it should sync
[07:19:52] <mru> kshishkov: ffmpeg by default does insane things
[07:19:55] <Dark_Shikari> vsync just adjusts the method used
[07:20:05] <Dark_Shikari> the thing is: the input file is _CBR_
[07:20:10] <Dark_Shikari> it's bloody EASY
[07:20:12] <mru> -vsync is entirely undocumented
[07:20:19] <kshishkov> -async then?
[07:20:27] <mru> also undocumented
[07:20:28] <Dark_Shikari> async didn't fix it
[07:20:41] <mru> and the defaults are horribly broken
[07:21:00] <mru> usually you get crazy frame duplication or dropping
[07:21:03] <kshishkov> next thing is someone may dislike default settings for encoders used in FFmpeg. Oh wait, x264 have done that
[07:21:24] <Dark_Shikari> mru: well, Kovensky is writing audio + sync support for x264 for gsoc
[07:21:32] <mru> nice
[07:21:36] <mru> replace the shit
[07:21:36] <Dark_Shikari> so maybe we can do it better.
[07:21:44] <elenril> Kovensky is in gsoc?
[07:21:48] <mru> teach michael a lesson
[07:21:48] <Dark_Shikari> he's applying
[07:21:55] <kshishkov> wanna borrow synchronization from default Theora player?
[07:22:09] <Dark_Shikari> he's currently wrangling with the hilarity of variable audio frame size
[07:22:12] <Dark_Shikari> i.e. input and output not matching
[07:22:18] <Dark_Shikari> one of those fun issues that never comes up in video
[07:23:31] <mru> it's not a problem in audio either with a good design
[07:23:39] <Dark_Shikari> of course not
[07:23:48] <Dark_Shikari> But it's still something the design has to deal with
[07:24:04] <mru> of course
[07:24:14] <mru> but it's fairly trivial
[07:24:39] <kshishkov> video frames have variable duration though defined by external means
[07:29:40] <pentanol> anyone? which demuxer will be enough for receaving rtsp h264 acc ?
[08:49:34] <CIA-24> ffmpeg: mstorsjo * r22706 /trunk/libavformat/rtpenc.c: Initialize ssrc and base_timestamp using ff_random_get_seed()
[08:51:36] <astrange> i've got an h264/mp4 file using PAFF with slices for two fields in each packet
[08:51:47] <astrange> can you do that? ffmpeg writes one packet per field instead of one per frame
[08:52:18] <Dark_Shikari> I didn't know you could do the latter
[08:53:31] <astrange> it's also bottom field first which is the first time i've seen that
[08:54:09] <mru> bottom field first is _very_ common in dvb/mpeg2
[08:54:32] <Dark_Shikari> he meant ordering of packets
[08:54:34] <Dark_Shikari> I think
[08:54:38] <astrange> yeah, but i hadn't seen it in h264
[08:54:46] <Dark_Shikari> that's because bff is basically SD-only
[08:54:51] <Dark_Shikari> and h264 is mostly hd for DVB
[08:55:16] <astrange> i can't find the copy of 14496-15 i had, but i'm pretty sure it didn't mention fields at all
[08:56:06] <astrange> anyway, it's a pain because i can't support it in -mt without something like packed b-frame support
[08:56:22] <mru> if it's proper non-interlaced HD there's of course no bff
[08:56:32] <mru> I haven't looked at 1080i crap
[10:00:57] <CIA-24> ffmpeg: vitor * r22707 /trunk/libavformat/ (nut.c nut.h nutenc.c nutdec.c): (log message trimmed)
[10:00:57] <CIA-24> ffmpeg: Fix NUT (de)muxer warnings:
[10:00:57] <CIA-24> ffmpeg: CC libavformat/nutdec.o
[10:00:57] <CIA-24> ffmpeg: libavformat/nutdec.c: In function ?read_seek?:
[10:00:57] <CIA-24> ffmpeg: libavformat/nutdec.c:862: warning: passing argument 3 of ?av_tree_find? from incompatible pointer type
[10:00:57] <CIA-24> ffmpeg: ./libavutil/tree.h:44: note: expected ?int (*)(void *, const void *)? but argument is of type ?int (*)(struct Syncpoint *, struct Syncpoint *)?
[10:00:58] <CIA-24> ffmpeg: libavformat/nutdec.c:871: warning: passing argument 3 of ?av_tree_find? from incompatible pointer type
[10:05:03] <CIA-24> ffmpeg: stefano * r22708 /trunk/ (doc/ffprobe-doc.texi ffprobe.c):
[10:05:03] <CIA-24> ffmpeg: Implement -convert_tags option, which converts showed tag names to the
[10:05:03] <CIA-24> ffmpeg: FFmpeg generic tag names.
[10:32:10] <CIA-24> ffmpeg: stefano * r22709 /trunk/libavformat/avio.h: Document url_seek().
[10:42:32] <saste> kshiskov: if you're ok with the librtmp patch i'll commit it
[10:44:01] <kshishkov> ok, just don't forget to bump lavf version and update documentation ;)
[10:45:03] <saste> good :)
[10:45:35] <kshishkov> unlike RTMP itself :P
[10:46:04] <saste> ehe...
[10:48:57] <kshishkov> at least all gross stuff is now swept under librtmp
[12:49:37] <enkidu> hi there. What about adding template support for FFServer status page? It might be nice addition.
[12:49:56] <kshishkov> patchiswelcome
[12:50:41] <enkidu> Ill try making it, but need some skill-up in C coding, and FFServer sources are not so Qt ;)
[12:51:19] <kshishkov> you're lucky I can't hit you with a stick
[12:51:25] <jai> heh
[12:51:31] <jai> we are glad it isn't like Qt
[12:52:16] <kshishkov> not to mention that C is sipler than C++
[12:52:26] <jai> mandatory bash.org reference : http://www.bash.org/?4281
[12:53:43] <Kovensky> <@mru> but it's fairly trivial <-- well, I am writing all the samples, but the audio still sounds broken and plays too fast ._.
[12:53:51] <Kovensky> I guess I need to interpolate the pts
[12:54:04] <kshishkov> what pts?
[12:54:08] <Kovensky> audio pts
[12:54:09] <enkidu> :} anyways, Ill try writing that support
[12:54:27] <kshishkov> Kovensky: num of samples divided by sampling rate
[12:54:40] <kshishkov> there are no audio codecs with B-frames
[12:55:11] <kshishkov> and if it plays too fast you either screwed sampling rate or dropping parts of audio packets
[12:55:43] <kshishkov> enkidu: it's not that hard - and you can find those pieces where HTML is written anyway
[12:56:53] <Kovensky> <@kshishkov> and if it plays too fast you either screwed sampling rate or dropping parts of audio packets <-- it sounds like dropped samples
[12:57:09] <twnqx> KotH?
[12:57:18] <kshishkov> yes, that's called "very poor man resampler"
[12:57:46] <enkidu> kshishkov: I have found them already :) things I have to do: 1) reading template file; 2) replacing tags with strings; 3) return stream to sockeh
[12:57:48] <Kovensky> http://pastebin.org/126594 <-- current code (input.decode_audio is a avcodec_decode_audio wrapper (reads packets from an AVPacketList), input.encode_audio is an avcodec_encode_audio wrapper)
[12:59:18] <kshishkov> it will fail when encoding pcm16->pcm24 for sure
[12:59:36] <Kovensky> well, for now I'm just doing 44100 s16le to mp3 and aac
[12:59:41] <Kovensky> it works with mp3, fails with aac
[13:00:16] <Kovensky> the decode_audio call gives me 4608 samples, the mp3 encoder consumes 4608 samples, but the aac encoder only consumes 4096
[13:00:40] <kshishkov> and?
[13:01:09] <Kovensky> and I don't know what to do in that case :P
[13:01:23] <kshishkov> you do memmove() and that's correct
[13:01:25] <Kovensky> I tried making a circular buffer as you can see
[13:01:50] <Kovensky> so at least in aud_samples all samples are preserved
[13:02:29] <kshishkov> you also need to check for needed input size and refill buffer in that case too
[13:02:53] <jai> essentially, you need to replicate most of ffmpeg.c ;)
[13:03:31] <Kovensky> <@kshishkov> you also need to check for needed input size <-- haud->framesize (the wrapper sets it to ctx->frame_size * ctx->channels * the sample size)
[13:04:50] <Kovensky> and what would be "refill buffer"
[13:06:17] <kshishkov> why "pos = inlen;" is unconditional?
[13:08:22] <kshishkov> also I'd suggest you to add some printf()s to trace what it really does with both input and output
[13:08:31] <Kovensky> to make decode_audio always write past the last preserved byte
[13:27:29] <enkidu> after some investigation I decided to make CSS styling by now, template may wait few days, Ill commit patch when I check code
[13:40:27] <CIA-24> ffmpeg: stefano * r22710 /trunk/ (6 files in 2 dirs):
[13:40:27] <CIA-24> ffmpeg: Implement support to RTMP, RTMPT, RTMPE, RTMPTE, RTMPS protocols via
[13:40:27] <CIA-24> ffmpeg: librtmp.
[13:40:27] <CIA-24> ffmpeg: Patch by Howard Chu <hyc * highlandsun * com>.
[13:45:12] <enkidu> strange... code compiled without errors
[13:45:37] <kshishkov> it's not Qt after all
[13:46:15] * enkidu <3 fairy tales ;)
[13:46:43] * kshishkov prefers fractured fairy tales
[13:47:35] * Kovensky <3 fairy tail's OST
[13:49:14] <enkidu> time to check it :}
[13:53:55] <enkidu> where can I send patch for css-styling?
[13:54:21] <Kovensky> ffmpeg-devel mailing list
[13:54:29] <Kovensky> though I prefer IRC patch reviewing :>
[13:54:43] <enkidu> ok, so pastebin first :)
[14:03:43] <enkidu> http://pastebin.org/126617
[14:03:59] * enkidu notes to self: never use pastebinit
[14:11:55] <Kovensky> enkidu: pastebin it as diff, not as C
[14:12:06] <enkidu> Kovensky: sorry :x
[14:12:54] <Kovensky> http://pastebin.org/126621 <-- fixed version :>
[14:13:33] <enkidu> Kovensky: ok :)
[14:13:44] <Kovensky> shouldn't you use stylesheet instead of template_file?
[14:13:56] <Kovensky> it is a stylesheet after all, not a template =p
[14:14:42] <enkidu> its just keyword name, but for sure - I should change it :)
[14:14:57] <Kovensky> the TemplateFile command too
[14:15:04] <Kovensky> hey, variable naming is important :P
[14:15:12] <enkidu> I know it ;)
[14:15:26] <Kovensky> as master pengvado said, it's actually better to be vague than wrong :P
[14:16:33] <enkidu> ok, ill upload changed patch
[14:17:30] <enkidu> http://pastebin.org/126623 check it
[14:19:31] <enkidu> what about V4L device unmute on startup?
[14:22:44] <enkidu> frequency setting could be nice too
[14:27:56] <Kovensky> <@kshishkov> there are no audio codecs with B-frames <-- re: this, btw; I'm ATM muxing to flv and it requires a dts on every packet, and at least some players respect audio dts
[14:28:24] <Kovensky> I'll try to use the dts of the first audio packet as the initial dts, and then just increment it as I encode ._.
[16:03:17] <j0sh> lu_zero, vorbis stream copy from feng rtp is identical to the old code... if it's broken, it always was
[16:04:02] <j0sh> i should note that "-vcodec copy" for theora makes ffmpeg hang, it has to re-encode through libtheora, will file a bug
[16:07:05] <DonDiego> j0sh: assign it to david conrad
[16:07:53] <j0sh> DonDiego, ok
[16:23:15] <ramiro> astrange: so it's safe to compile for 32-bit mac os x with --extra-cflags=-mdynamic-no-pic?
[17:02:03] <enkidu> nice lag
[17:18:40] <CIA-1> ffmpeg: jai_menon * r22711 /trunk/libavcodec/tta.c: TTA : Check if the output buffer size is within bounds.
[17:21:50] <CIA-1> ffmpeg: jai_menon * r22712 /trunk/MAINTAINERS: Add myself as co-maintainer of tta.c
[17:39:42] <Dark_Shikari> http://akuvian.org/src/x264/ffv2.94.diff cool beans
[18:01:57] <j0sh> can someone see if they can play a normal ogg vorbis file through ffplay?
[18:02:11] <j0sh> mine keeps complaining about not being able to find codecs; i want to be sure im not crazy before i file a bug
[18:02:29] <ramiro> mru: is there a way to tell make test to create all files on the target filesystem? (not through nfs)
[18:02:57] <saintdev_> Dark_Shikari: Johnny Chimpo?
[18:03:14] <j0sh> the samples on mplayerhq don't seem to be working...
[18:04:18] <mru> ramiro: that won't work
[18:04:35] <mru> because then the host can't check them
[18:06:36] <ramiro> then can the mount be the other way around? the host mounts some dir from target
[18:06:51] <ramiro> because target_path is being used both for output files and the ffmpeg executable
[18:07:06] <mru> why is this a problem for you?
[18:07:31] <ramiro> nfs too slow and some files aren't being created properly
[18:07:35] <jai> j0sh: any specific sample you had in mind?
[18:08:02] <j0sh> jai, ive tried lumme.ogg and the o1_duran_duran sample
[18:08:03] <jai> you might find this weird, but i really dont have any ogg files around :|
[18:08:03] <ramiro> such as: encode to file X, decode (file X not there yet).
[18:08:43] <j0sh> jai, it also doesnt seem to be playing audio that i've extracted from, eg, theora samples
[18:09:01] <j0sh> jai, basically nothing works for vorbis
[18:09:06] <jai> j0sh: could you link to the sample you are having troubles with?
[18:09:58] <ramiro> mru: but I think make fate is good enough for me, and it's working fast&fine. I remember you mentioned some way to run only some tests (for example h264-*), how does that work?
[18:10:25] <j0sh> jai, try this: (http://samples.mplayerhq.hu/A-codecs/vorbis/floor_type_0/01_Duran_Duran_Planet_Earth.ogg)
[18:10:35] <mru> you can run individual fate tests with make fate-$testname
[18:12:31] <jai> j0sh: works fine here
[18:12:54] <j0sh> jai, just using ffplay? no other options?
[18:13:25] <jai> j0sh: ffplay vanilla trunk build
[18:13:42] <j0sh> hmmm thats weird, thanks
[18:13:58] <jai> j0sh: did you try with a clean build with a fresh checkout?
[18:15:57] <j0sh> jai, i have a few patches but they should be unrelated... let me try it clean
[19:12:21] <j0sh> jai, i think the problem is my sound system is completely broken. wonder how long it's been going on... thanks anyway
[20:11:13] <astrange> ramiro: --enable-shared might not compile, otherwise it's safe
[20:16:59] <CIA-1> ffmpeg: diego * r22713 /trunk/doc/general.texi:
[20:16:59] <CIA-1> ffmpeg: Clarify (Open)Solaris section of the documentation.
[20:16:59] <CIA-1> ffmpeg: patch by Michael Kostylev, michael.kostylev gmail com
[22:14:31] <KingofCamelot> Anyone know how to contact Alex Converse in regards to a GSoC project?
[22:15:22] <kierank> he goes by the nick peloverde
[22:15:32] <astrange> email ffmpeg-soc if you haven't already
[22:17:03] <KingofCamelot> Ok. Thanks guys.
[23:11:02] <astrange> output_example has lines from 2003 that "will be removed ASAP"
[23:12:05] <Dark_Shikari> lol
[23:16:27] <DonDiego> nothing lasts as long as a temporary solution, *sigh*
[23:16:58] <DonDiego> astrange: btw, you mentioned speeding up mpeg2.. - anything new?
[23:50:43] <astrange> i need to get better ideas first
[23:51:46] <Dark_Shikari> debug mode/verbose
[23:51:47] <Dark_Shikari> er
[23:51:49] <Dark_Shikari> wrong channel.
[23:51:59] <Dark_Shikari> what I meant to say: write it in fortran ;)
[23:53:16] <astrange> http://pastebin.com/CrYend33
[23:53:25] <astrange> idct=14 is xvid sse2