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

[irc at mansr.com]

[00:02:27] <peloverde> I was told that people would do LATM when I made a public PS repo
[00:02:36] <peloverde> I have fufilled my side of the bargain
[00:03:19] <peloverde> http://github.com/aconverse/ffmpeg-heaac/tree/ps_pub
[06:20:52] <hyc> grumble... rtsp streaming was only working while my phone was on my wifi network
[06:21:16] <hyc> when I switched to T-mobile 3G, it's not. apparently T-mobile blocks UDP or something
[06:22:15] <hyc> and it doesn't look like Android supports RTSP with interleaved RTP
[06:23:04] <hyc> so ... anyone got an rtsp relay? talk to the real rtsp server using tcp only, and talk to the localhost client using regular rtp/udp
[07:57:24] <CIA-7> ffmpeg: stefano * r23144 /trunk/libavutil/pixfmt.h: Clarify description for the MONOWHITE and MONOBLACK pixel formats.
[07:57:24] <CIA-7> ffmpeg: stefano * r23145 /trunk/ (libavformat/riff.c libavcodec/raw.c):
[07:57:24] <CIA-7> ffmpeg: Add NV12 and NV21 AVI tags.
[07:57:24] <CIA-7> ffmpeg: Both are listed in fourcc.org.
[08:00:28] <wbs> hyc: hmmm, strange if udp doesn't work over cellular, that's part of the services that "should work" imo, unless the operatos wants to allow only certain stuff of course..
[08:01:50] <wbs> rtsp/udp is part of stuff that should work, that is
[08:02:30] <wbs> or is your rtsp server behind NAT of some kind?
[12:36:54] <Kovensky> mru: "planar" audio? o_O
[12:37:41] <mru> separate arrays for each channel
[12:37:59] <Kovensky> ic
[13:13:49] <hyc> wbs: no, I've setup DSS on my linode and that's on a real IP address, no NAT
[13:15:07] <hyc> but the phone on 3G is NATd
[14:22:01] <wbs> hyc: hmm, ok.. the rtsp client on the phone should be able to punch NATs to get proper forwarding though
[14:26:16] <hyc> hmmm. you're right.
[14:26:26] <hyc> I just found this page with test audio streams, works.
[14:26:33] <hyc> http://www.orban.com/products/streaming/opticodec-pc1010/eval/
[14:27:02] <hyc> so there must be something wrong with the program I'm trying to stream
[14:28:22] <hyc> do you have a quick reference handy for allowed bit rates and such for 3GP streaming, perchance?
[14:28:25] <hyc> still googling...
[14:30:42] <wbs> i don't think that should be an issue, if it works over wifi it should work over 3g, too, as long as you've got enough bandwidth
[14:31:48] <hyc> ok, lemme try a much lower bitrate...
[14:32:23] <hyc> 128kbit AAC is fine at least
[14:32:36] <wbs> hm, ok
[14:35:36] <hyc> weird. one of my test streams that didn't work yesterday is OK now.
[14:36:33] <wbs> weird
[14:37:37] <wbs> http://pda.etsi.org/exchangefolder/ts_126234v090200p.pdf - this should be a reference of what's allowed within rtsp/3gpp, but I doubt that actually helps anything in this case
[14:42:45] <hyc> thanks, will check it out anyway
[14:43:14] <hyc> ok, so using the DSS sample files, the 50kbit 3gp worked and the 100kbit mp4 worked
[14:43:26] <hyc> doesn't seem like the 100kbit h264 will work
[14:46:15] <hyc> and the 300kbit mp4 didn't work either
[14:47:06] <BastyCDGS> hey greetz to all
[14:50:17] <hyc> wbs: have you examined those DSS sample files?
[14:50:28] <hyc> the mp4s have 4 streams inside
[14:50:42] <hyc> one audio, one video, two marked data / rtsp. you know what they are?
[14:57:08] <hyc> oh those are the hint track,s never mind
[15:13:18] <wbs> yeah
[15:13:57] <wbs> and if you still is interested in producing such stuff for non-live viewing; create just a normal mp4/3gp file and run MP4Box -hint <file>, or use the movenc/rtphint patches I sent a few weeks ago, they allow creating such
[15:14:01] <hyc> I see mpeg4ip and mp4box as two tools to do that
[15:14:09] <hyc> ah ok
[15:14:17] <hyc> I'm compiling mp4box now...
[15:14:24] <wbs> with those patches, you can add -fflags rtphint when transcoding with ffmpeg to get it all at once
[15:14:54] <hyc> that sounds great. will have to dig thru the archives to find the patch.
[15:15:01] <hyc> patches aren't committed yet?
[15:15:24] <wbs> no, baptiste did a first review in a few days after submitting it, but that was like 3 weeks ago
[15:15:34] <wbs> he hasn't had time to review the updated version yet
[15:16:07] <hyc> I see "[RFC] RTP hint tracks in the mov muxer"
[15:16:29] <hyc> is there a reason this is only for the mov muxer? I guess the container format is irrelevant here
[15:16:42] <wbs> it's the same for mov/3gp/mp4
[15:16:49] <wbs> the same muxer for all of them
[15:17:36] <hyc> ah, ok
[15:17:36] <wbs> the latest ones are in the thread [PATCH] Add RTP hinting to the mov muxer, a mail from 26th april
[15:17:57] <hyc> ok, found that
[15:30:40] <hyc> 500kbit hinted mp4 file played on 3G for a while then glitched and hung
[16:09:21] <siretart> can someone please explain me the difference between palette8torgb16 and palette8torgb15 in libswscale? I'm trying to document them.
[16:09:42] <Dark_Shikari> rgb16 is r5 g6 b5 iirc
[16:09:47] <Dark_Shikari> and rgb5 is r5 g5 b5
[16:09:50] <Dark_Shikari> *rgb15
[16:10:45] <BastyCDGS> hi BBB
[16:10:47] <siretart> Dark_Shikari: hm. and why is then the code identical?
[16:10:52] <BBB> hello
[16:10:56] <BBB> I'm still reviewing the ham patch
[16:11:01] <Dark_Shikari> siretart: dunno
[16:11:09] <BastyCDGS> BBB, I just made some changes to byterun decoder where you found the return value pity
[16:11:28] <BastyCDGS> it now returns number of bytes consumed or an error if the byterun1 stream is malicious
[16:12:05] <BBB> malicious?
[16:12:06] <BBB> ok
[16:12:08] <BBB> will look
[16:12:11] <BBB> one thing at a time :)
[16:12:52] <BastyCDGS> yes that was the case where the FFMIN and FFMIN3 were used previously, they simply cut the data
[16:13:07] <BastyCDGS> but I think it's better to return AVERROR_INVALIDDATA if there's not enough space to decompress them
[16:21:13] <BBB> I wonder how many consts you can put on a line without getting a syntax error, sometimes
[16:21:24] <BBB> try, where appropriate, to not over-use const
[16:21:28] <BBB> in many cases it makes no difference
[16:21:48] <BBB> and we'll have to remove it again once we use ptrs to keep track of buffer location, e.g. const uint8_t * const buf
[16:21:57] <BBB> you can't do val=*buf++; on that
[16:22:25] <BastyCDGS> that's why I did const uint8_t *buf,
[16:22:26] <BastyCDGS> ;)
[16:23:14] <BastyCDGS> btw, the new decode_byterun is a bit faster I just noticed, 3.4k dezicycles as 4.3k it was before ;)
[16:23:44] <BBB> excellent
[16:23:52] <BBB> still lots of comments on the ham thing
[16:23:59] <BBB> I'll have more later, but this should get you started
[16:24:15] <BBB> gcc did really well on that macro of yours, I was surprised
[16:24:33] <BastyCDGS> yes I playing around with approx 2-3 hours to get it optimal
[16:24:58] <BastyCDGS> I will now separate the err thing
[16:29:27] <BastyCDGS> so new function merge patch submitted to ML
[16:29:53] <hyc> wbs: fyi http://forum.xda-developers.com/showpost.php?p=6495551&postcount=8
[16:30:28] <BBB> ok, will apply in a bit if it's ok
[16:31:20] <wbs> BBB: thanks for the point on reordering only if !tcp, i'll try to get that included, too
[16:31:55] <BBB> wbs: that's all I could think of for now, you have to admit the 10-item fixed-size cache was butt-ugly though
[16:32:08] <BBB> but I see as proof-of-concept it was funny ;)
[16:32:11] <wbs> BBB: yeah, it is. :-)
[16:32:27] <wbs> and getting all that to work with editing code in ~3 places is quite ok :-)
[16:32:27] <BBB> also make sure you don't leak the cache on exit
[16:32:59] <wbs> yeah, forgot it this time when it was that kind of hack :-)
[16:33:10] <BBB> that's ok :)
[16:33:19] <BBB> hey, I do hacks like that too ;)
[16:37:22] <wbs> hyc: nice writeup
[16:37:36] <wbs> BBB: i've found the second user for the rtsp muxer - hyc :-)
[16:38:25] <BBB> now if only hyc would start working on a rtmp muxer + demuxer inside lavf
[16:40:05] <hyc> BBB eh? what else do you need?
[16:41:35] <BastyCDGS> BBB, about transparency/masking in HAM patch where you suggest removal
[16:41:42] <BastyCDGS> they're used for bumping error messages
[16:42:00] <BastyCDGS> I could of course remove the local stuff but then I've to change code later at other points when I add them
[16:44:49] <hyc> BBB: the rtmp protocol just transports flv, and there's already an flv mux/demux
[16:44:49] <BBB> BastyCDGS: right, that's normally what we do
[16:44:56] <BBB> you add it not pre-emptively, but when you start using it
[16:45:08] <BBB> hyc: rtmp uses libZYX
[16:45:12] <BBB> should be in lavf
[16:46:02] <hyc> oh... not going to revisit that conversation.
[16:47:07] <hyc> there are still going to be external dependencies, remember? DiffieHellman, at least.
[16:47:23] <hyc> so it's a lot of work for really no gain
[16:47:31] <hyc> and no overall change in the situation
[16:50:20] <BBB> like you said, "not going to revisit"
[16:53:07] <hyc> better to re-use good code than to rewrite it. I've now adapted librtmp to XBMC, ffmpeg, mplayer, and libcurl.
[16:53:32] <hyc> If I had rewritten librtmp exclusively for ffmpeg it would have taken more time and gotten less coverage.
[16:54:13] <wbs> hyc: btw, how much work would it be to add support to librtmp for doing generic method invocations for custom applications?
[16:54:40] <wbs> that is, not just setting up video streaming, but calling custom server methods and getting the results
[16:55:00] <hyc> wbs: dunno, will have to think about it. you need a way to specify the syntax of each request in AMF
[16:55:13] <hyc> kinda like OpenLDAP's liblber for ASN.1 I suppose
[16:55:40] <wbs> ok
[16:56:08] <hyc> are you familiar with ASN.1 or AMF?
[16:56:40] <wbs> just a tiny bit with AMF, it's some way of serializing generic objects of a few different classes, right?
[16:56:56] <hyc> I guess you could say that
[16:57:06] <wbs> if I need such support from librtmp I guess I can try to add it myself, I'm not sure yet if I'll need it or not
[16:57:48] <hyc> librtmp only encodes 3-4 data types, but it decodes a couple dozen.
[16:58:51] <hyc> ASN.1 has hierarchically nested data structures. Most software projects use dedicated IDL compilers to go from a structure definition to code.
[16:59:36] <hyc> In OpenLDAP we just do stuff like ber_printf(ber, "{{IAAI}{B}}", ...)
[16:59:45] <wbs> ah
[17:00:48] <hyc> it's much more flexible since you can encode any structure you can conceive of on the fly, instead of having to know them all in advance...
[17:01:08] <hyc> I would consider taking a similar approach for arbitrary RTMP requests
[17:01:19] <wbs> sounds reasonable, yeah
[17:01:31] <hyc> (we of course have ber_scanf to decode these things.)
[17:09:40] <CIA-7> ffmpeg: stefano * r23146 /trunk/libavcodec/raw.c: Add missing rawvideo pixel formats to codec tags mappings for nut.
[17:19:58] <mt> There's something that I don't understand about the wma decoder; what does it make data_size = 16k when all that was written into the output buffer is really 2k ?
[17:24:46] <BBB> mt: data_size is in bytes?
[17:24:58] <mt> BBB:  Yes
[17:25:14] <BBB> it works for ffplay, right?
[17:26:14] <mt> I have tried ffmpeg_g not ffplay, and it worked
[17:26:32] <mt> (ffmpeg_g -i foo.wma foo.wav)
[17:27:23] <BBB> so what do you mean that only 2k was written? that 2048 bytes (for stereo, that's /int_16_t*2 = 512 samples) were written?
[17:30:08] <mt> Sorry I meant 4k bytes ..
[17:30:28] <mt> 1024 samples for stereo
[17:31:28] <BBB> is this wmapro or wma1/2?
[17:31:33] <mt> pro
[17:31:41] <BBB> output=float, so that's 4bytes per sample
[17:31:42] <BBB> not 2
[17:31:48] <BBB> 8 bytes because stereo
[17:32:00] <BBB> so 1024 samples = 8182 bytes
[17:32:04] <BBB> that explains one thing
[17:32:14] <BBB> but why is it 16k?
[17:32:34] * BBB doesn't know that last piece
[17:33:19] <BBB> well it's probably something similar to that
[17:33:56] <mt> Ah I convert the pcm samples to s16-bit btw .. (*data_size/2)
[17:35:03] <BBB> so what's the bug?
[17:35:05] <BBB> I'm confused
[17:39:35] <mt> data_size is double the actual number of bytes. I didn't mean it was a bug btw, I might just be confused :) .. I don't know where this doubling comes from.
[17:40:33] <mt> like that 16k vs 8k example.
[17:51:04] <BBB> right
[17:51:08] <BBB> I don't know exactly
[17:51:09] <BBB> sorry :(
[17:54:19] <BastyCDGS> BBB, one question
[17:54:24] <BBB> si?
[17:54:27] <BastyCDGS> Use av_mallocz(), memset(x, 0) or something to zero the remaining
[17:54:27] <BastyCDGS> (unpaletted) entries, e.g. if extradata is too small.
[17:54:39] <BBB> yes
[17:54:43] <BastyCDGS> the thing is it's interleaved zeroes...i.e. zero, palette data, zero...
[17:55:20] <mt> BBB:  No problem.. Thanks anyways. :)
[17:55:28] <BastyCDGS> the mask is always zero, but not the palette data so I just fill out the first count*2 entries with 0
[17:55:45] <BBB> BastyCDGS: the palette data is what I meant
[17:55:51] <BBB> the palette data is read from the extradata
[17:55:55] <BastyCDGS> I could of course let start the memset where anything is always zero but then i have to set mask to 0 by hand like grayscale part
[17:56:04] <BBB> but what if count = 1<<bps is 256 and extradata is only 200?
[17:56:08] <BBB> the last 56 would be uninitialized
[17:56:12] <BBB> you need to zero them somehow
[17:56:19] <BastyCDGS> yes that's what the memset does ;)
[17:56:33] <BastyCDGS> it's * 2 because mask has to be zero, too
[17:57:34] <BBB> oh there is a memset!
[17:57:36] <BBB> now I get it
[17:57:38] <BBB> nevermind
[17:57:38] <BastyCDGS> about MASK_NONE, stefano just said I should use MASK_NONE instead of 0 and use a comment
[17:57:42] <BBB> I didn't see that whole thing
[17:58:32] <BBB> saste: did you say that?
[17:58:37] <BBB> if he thinks so, then it's ok
[17:58:44] <BBB> the others should still go -> iff.c
[17:58:59] <BastyCDGS> that's why I was changing this again, actually ;)
[18:01:30] <BastyCDGS> BBB:         if ((screenmode & 0x800 /* Hold And Modify */) && iff->bpp <= 8) {
[18:01:33] <BastyCDGS> is that ok?
[18:01:54] <BastyCDGS> iff->flags        = (screenmode & 0x80 /* Extra HalfBrite */) && iff->bpp <= 8 ? 1 : 0;
[18:03:44] <BBB> too many ()
[18:03:48] <BBB> also 1:0 can be done as !!
[18:04:01] <BBB> so !!(screenmode & 0x80 /* .. */ && bpp <= 8);
[18:04:20] <BBB> otherwise it's ok, yes
[18:05:27] <BastyCDGS> iff->flags        = screenmode & 0x80 /* Extra HalfBrite */ && iff->bpp <= 8;
[18:05:40] <BastyCDGS> !! is double inverse => remove
[18:06:03] <BBB> oh right && takes care of that
[18:06:14] <BBB> you need !! only for &
[18:06:19] <BBB> !!(x & 0x80)
[18:06:52] <BastyCDGS> do you think this one looks better?
[18:06:52] <BastyCDGS>         iff->flags        = (screenmode & 0x80 /* Extra HalfBrite */) && iff->bpp <= 8;
[18:07:07] <BBB> not really
[18:07:11] <BBB> but no strong opinion
[18:07:16] <BastyCDGS> so which one of these two should I take
[18:08:59] <BastyCDGS> This number may change between frames.
[18:09:03] <BastyCDGS> this is correct
[18:09:31] <BastyCDGS> it can also send an empty structure (size == 2) in that case it means to the decoder, don't change anything this frame except the frame data itself
[18:13:49] <BBB> 1 second
[18:14:45] <CIA-7> ffmpeg: bcoudurier * r23147 /trunk/libavfilter/graphparser.c: use filter name when graph parser add filters
[18:25:44] <mt> BBB:  in wma pro, samples_per_frame == samples per frame _per channel_ ?
[18:27:01] <BBB> mt: I didn't write that codec, but usually yes
[18:29:11] <BBB> BastyCDGS: that wasn't immediately clear to me
[18:29:17] <BBB> BastyCDGS: the comment should be clearer
[18:29:24] <BBB> the number doesn't change
[18:29:28] <BBB> it's always 9, if there's data
[18:29:34] <BBB> but it can be 2 also if there's no data
[18:30:17] <BastyCDGS> * This number may change between frames, e.g. the demuxer might
[18:30:17] <BastyCDGS>  * set it to smallest possible size of 2 to indicate that there's
[18:30:17] <BastyCDGS>  * no extradata changing in this frame.
[18:30:39] <BastyCDGS> in fact it's always 9 in current version data, but future versions might add new fields
[18:30:46] <BastyCDGS> in this case it can be larger
[18:31:46] <BBB> something like that is ok
[18:31:53] <BBB> also, I'd set it to size without the size field
[18:31:59] <BBB> right now you have to check that size >= 2
[18:32:01] <BBB> else it's invalid
[18:32:03] <BBB> that's silly
[18:32:20] <BBB> and make sure to check that size <= pkt->size
[18:32:24] <BBB> (if you didn't already)
[18:32:46] <BastyCDGS> it does GET_EXTRA_SIZE and GET_PACKET_SIZE return <= 0 in this case
[18:32:47] <BastyCDGS> ;)
[18:33:05] <BastyCDGS> a size of 0 or 1 doesn't make any sense right? ;)
[18:33:20] <BastyCDGS> because actual raw data and extra data would overlap then
[18:33:26] <BBB> yes
[18:33:31] <BBB> but you're not checking that that's not the case
[18:33:35] <BastyCDGS> for now these values are illegal but maybe they might have a meaning in the future
[18:33:45] <BBB> no, no, we don't work like that :)
[18:33:50] <BastyCDGS> if (buf_size <= 1 || (int) GET_PACKET_SIZE(avpkt) <= 1) {
[18:33:57] <BBB> we define things in a sensible way :)
[18:33:58] <BastyCDGS> this does do both checks
[18:34:16] <BBB> GET_PACKET_SIZE() is a little weird
[18:34:22] <BBB> I think all that is overegineering
[18:34:32] <BastyCDGS> why it's weird?
[18:34:32] <BBB> it's not necessary to make macros for such simple stuff
[18:34:35] <BBB> size=avpkt->size;
[18:34:39] <BBB> size -= buffer_size;
[18:34:46] <BBB> if size < 0 return error;
[18:34:48] <BastyCDGS> I use this macro pretty often
[18:34:49] <BBB> handle (data, size);
[18:35:36] <BBB> again, up to you, I have no strong opinion (except that they shouldn't be in public header files), but I think it's overengineering
[18:35:41] <BBB> generally leads to poor performance
[18:35:58] <BBB> see glib's gobject :)
[18:36:50] <BastyCDGS> well these macros are only used upon init or if data changes between frames
[18:37:00] <BastyCDGS> not in actual decoding
[18:37:52] <BastyCDGS> one other question about factorzing the decode_frame_ilbm & byterun1
[18:37:58] <BastyCDGS> do you mean I should put the start in a macro?
[18:38:19] <BBB> I haven't looked into that in detail
[18:38:24] <BBB> whichever you think is best, basically
[18:38:30] <BBB> again, keep the macro for GET_...()
[18:38:32] <BBB> if you want
[18:38:43] <BBB> I personally don't consider it pretty, but it's your codec more than mine, so do as you please
[18:39:04] <BBB> same for the factorizing, it's clear there's a lot of duplicate code, I think it can be factorized, you appear to agree (good!)
[18:39:13] <BBB> how to do that best is now up to you :)
[18:40:03] <hyc> I keep getting this complaint about AAC running ffserver. comes from sdp.c line 244 "AAC with no global headers is currently not supported"
[18:40:19] <hyc> what is it expecting to see in codec->extradata ?
[18:40:55] <hyc> this is using an ffm feed. why isn't ffmpeg sending what sdp wants? the codec->extradatasize is zero.
[18:41:24] <BBB> during encoding, set AVCodecContext->flags &= GLOBAL_HEADERS;
[18:41:33] <wbs> hyc: hmm, you're encoding aac in a ffmpeg process, sending it over to ffserver as ffm, and ffserver wants aac global headers?
[18:41:46] <hyc> wbs: right
[18:41:47] <BBB> might be a bug btw, send us a patch ;)
[18:42:03] <wbs> the ffmpeg encoder would need to know that aac should have global headers then, which it checks from the global header flag of the selected muxer
[18:42:04] <hyc> I'm sure it's a bug, but I don't know what it really wants here.
[18:42:14] <BastyCDGS> +#define DECODE_FRAME_INIT                                           \
[18:42:14] <BastyCDGS> +    IffContext *s = avctx->priv_data;                               \
[18:42:14] <BastyCDGS> +    const uint8_t *buf = GET_PACKET_DATA(avpkt);                    \
[18:42:37] <hyc> wbs: isn't ffm the muxer here?
[18:42:51] <wbs> hyc: yeah, and I don't know that one, I guess it can do both with and without global headers
[18:42:57] <BBB> BastyCDGS: that sounds like it'll be really ugly
[18:43:06] <BBB> BastyCDGS: can you wrap the code in the middle into a common subfunction?
[18:43:15] <wbs> it is mostly up to what ffserver wants to do with the data later, and ffmpeg doesn't really know if the ffserver target format wants global headers or not
[18:43:28] <BastyCDGS> BBB, then it won't make any sense
[18:43:31] <BBB> wbs: ffmpeg.c has some hack in it for ffserver output
[18:43:44] <wbs> BBB: ah, I see
[18:43:48] <wbs> then disregard me :-)
[18:43:55] <hyc> BBB: where is this hack?
[18:44:17] <hyc> if it depends on the target format, then should ffmpeg always send it?
[18:44:19] <BastyCDGS> BBB, or should I move the define to the beginning?
[18:46:43] <BBB> BastyCDGS: let me pastebin something for you
[18:47:21] <wbs> hyc: not necessarily (exept that I don't know what ffserver does), for some output formats you don't want global headers enabled if the output format doesn't want that, since it may change the format of the raw data
[18:47:50] <wbs> for aac, you get an adts stream if global headers aren't enabled, and raw aac if global headers are enabled
[18:47:57] <wbs> hyc: oh btw, are you stream copying aac?
[18:48:21] <BastyCDGS> BBB, btw: I meant it this way:
[18:48:21] <hyc> wbs: ok. when ffmpeg starts talking to ffm, it first fetches the ffm definition from ffserver
[18:48:21] <BastyCDGS> http://pastebin.org/241899
[18:48:33] <BBB> BastyCDGS: http://ffmpeg.pastebin.com/2Ens29yF
[18:48:41] <BBB> that is the difference between ilbm/byterun1 decoding
[18:49:06] <hyc> wbs: stream copying? I would like to, but I don't think I can.
[18:49:19] <BBB> BastyCDGS: my view is, minus the cosmetic stuff which os obvious, you should put the planar-to-plane decoding for() loops under an if (ctx->codec_id == BYTERUN1)
[18:49:25] <BBB> BastyCDGS: and then you have them merged
[18:49:26] <BBB> no?
[18:49:39] <hyc> that is, I don't know how to tell ffserver to just copy whatever ffmpeg's source stream verbatim
[18:49:44] <BastyCDGS> both are different decoders
[18:49:50] <wbs> hyc: hmm, ok
[18:49:56] <BBB> I know :)
[18:50:00] <hyc> there's no analogue to ffmpeg -acodec copy inside ffserver.conf, as far as I know
[18:50:31] <BastyCDGS> BBB, but does this really fit in the HAM patch?
[18:50:56] <BastyCDGS> can you just look at my pastebin and look how I solved that DECODE_FRAME_INIT stuff?
[18:51:04] <hyc> wbs: and this may not even be possible, since a single ffm feed can be turned into many different types of streams.
[18:51:24] <wbs> hyc: ah, ok
[18:53:49] <hyc> hm... I guess in that case the ffm header must contain parameters for every target stream
[18:54:37] <hyc> so probably it should attach whatever it was expected to stuff into the global headers into the ffm header, if any target stream wants it
[19:02:10] <BBB> BastyCDGS: that's your ham patch
[19:02:17] <BBB> what's DECODE_FRAME_INIT()?
[19:02:43] <BastyCDGS> it just merges the 100% identical init stuff of decode_frame_ilbm & decode_frame_byterun1
[19:03:15] <BBB> oh boy
[19:03:19] <BBB> no, that's hideous
[19:03:21] <BBB> that's not ok
[19:03:31] <BastyCDGS> how I should do it then?
[19:03:38] <BBB> don't, for now :)
[19:03:41] <BastyCDGS> ok
[19:03:44] <BBB> but look at the diff I pastebin'ed
[19:03:55] <BBB> basically the only difference is the plane decoding
[19:04:02] <BBB> so put that under an if (codec_id == BYTERUN1)
[19:04:04] <BBB> and you're done
[19:04:09] <BBB> plus some smart pointers
[19:05:22] <BBB> but later, we'll do ham first
[19:05:25] <BBB> one thing at a time :)
[19:05:43] <BastyCDGS> what's wrong with the DECODE_FRAME_INIT though?
[19:07:35] <hyc> wbs: I'm suspicious of this, ffm encodes the codec_id but not the name. we have both aac.c and libfaac.c
[19:07:50] <hyc> and I see libfaac.c checks for GLOBAL_HEADER but aac.c doesn't
[19:08:45] <hyc> so it seems that no matter whether you specify libfaac in ffserver.conf, you still get aac instead.
[19:08:57] <hyc> and aac isn't setting the global header stuff
[19:09:31] <wbs> hyc: aah, that might be the reason
[19:11:09] <hyc> I guess I should try --disable-encode=aac ?
[19:11:29] <BBB> BastyCDGS: http://ffmpeg.pastebin.com/aZRSsYPL
[19:11:32] <BBB> that's what I meant
[19:11:35] <BBB> BastyCDGS: rough version
[19:11:37] <wbs> hyc: yeah, that's a good idea
[19:12:25] <BBB> ffserver can't transmit faac
[19:12:28] <BBB> it can only transmit a codec_id
[19:12:30] <BBB> which is AAC
[19:12:37] <BBB> thus it uses the default aac encoder on the sending side
[19:12:39] <BastyCDGS> BBB, I want to keep that if outside the loop at least...for speed reasons
[19:12:49] <BastyCDGS> please note that a lot of code is inlined in the loop automatically
[19:12:52] <hyc> yeah, that's what I just figured out. going to turn off aac and see if faac works
[19:12:57] <BBB> BastyCDGS: I know that
[19:13:10] <BBB> BastyCDGS: you could do it macrobased so the source is one function but it expands into two, just like now
[19:13:20] <BBB> BastyCDGS: that way you get binary identical code from a single source function
[19:13:34] <BBB> but you see that they're easy to merge, right?
[19:13:35] <BastyCDGS> that's a much better idea, yes
[19:13:42] <BBB> if it's not too ugly :)
[19:14:06] <BastyCDGS> so maybe I do a DECODE_FRAME macro instead of DECODE_FRAME_INIT which covers both parts?
[19:14:08] <BBB> try some stuff out, show me what you learned :)
[19:14:21] <BBB> ?
[19:15:02] <BastyCDGS> the DECODE_FRAME merges both code, it just takes a parameter if it's for byterun1 or raw
[19:15:05] <BBB> #define decode_function(name) \ static int decode_frame_ ## name (bla bla bla) { bla bla reget buffer for loop return bytes; }
[19:15:08] <BBB> decode_function(ilbm);
[19:15:14] <BBB> decode_function(byterun1);
[19:15:41] <BBB> if that's what you meant, then yes, but it should be purely cosmetic and result in binary identical code (if done correctly)
[19:17:57] <BastyCDGS> ok
[19:18:22] <BastyCDGS> just one question, saste recommended me in the HAM review that I change:
[19:18:23] <BastyCDGS>     if (avctx->reget_buffer(avctx, &s->frame) < 0){
[19:18:23] <BastyCDGS>         av_log(avctx, AV_LOG_ERROR, "get_buffer() failed\n");
[19:18:23] <BastyCDGS>         return -1;
[19:18:23] <BastyCDGS>     }
[19:18:29] <BastyCDGS> to return err instead of -1
[19:18:37] <BastyCDGS> what do you think? separate patch or within HAM?
[19:18:49] <BBB> always separate ptch
[19:18:53] <BBB> it's completely unrelated to ham
[19:24:39] <hyc> ah. using libfaac didn't work either. ffmpeg is writing an ffm header back to ffserver before it has even init'd the codec, so that info isn't available yet.
[19:26:11] <BBB> BastyCDGS: oh right, as michael said, but_size implies that it's the size of "buf" (a variable), but it isn't, it's buf's size * 8, so give it a better name please
[19:28:38] <BastyCDGS> new HAM patch submitted to ML
[19:28:43] <BastyCDGS> will now do the functional merge patch
[19:32:42] <hyc> nope, I was wrong about that. using libfaac, ffmpeg definitely sent the global header info
[19:33:00] <hyc> but ffserver still didn't use it. wtf...
[19:35:20] <BBB> BastyCDGS: where did saste say to keep MASK_NONE?
[19:35:23] <BBB> I can't find that email
[19:36:18] <BastyCDGS> 15 may 2010 21:52 UTC
[19:36:25] <BBB> he said "use the macro if it's there"
[19:36:39] <BBB> you should use unsigned masking = 0; // = no mask
[19:36:40] <BastyCDGS> > +    uint32_t screenmode = 0;
[19:36:40] <BastyCDGS> > > +    unsigned transparency = 0;
[19:36:40] <BastyCDGS> > > +    unsigned masking = 0; // MASK_NONE
[19:36:40] <BastyCDGS>  
[19:36:40] <BastyCDGS> directly use the macro value
[19:36:40] <BastyCDGS>  
[19:36:57] <BBB> well duh, the comment is an actual macro
[19:37:01] <BBB> of course he'd say use the macro
[19:37:08] <BBB> you should make the comment be useful :)
[19:43:07] <Kovensky> [mp3 @ 004280b0]max_analyze_duration reached <-- isn't this equivalent to that MAX_READ_SIZE thing that was downgraded to verbose a while ago?
[19:43:11] <Kovensky> shouldn't it go to verbose too?
[19:44:56] <BastyCDGS> BBB, regarding to iff-function-merge.patch you said I should add the error checking later
[19:45:42] <BastyCDGS> can I do the first patch with the uint8_t * return parameter then?
[20:54:48] <BastyCDGS> hey saste :)
[20:55:22] <saste> hi basty
[21:04:03] <CIA-7> ffmpeg: cehoyos * r23148 /trunk/libavcodec/iff.c:
[21:04:03] <CIA-7> ffmpeg: Factorize code into a single function.
[21:04:03] <CIA-7> ffmpeg: Patch by Sebastian Vater, cdgs D basty A gmail
[22:36:11] <DonDiego> gnite
[23:01:15] <CIA-7> ffmpeg: stefano * r23149 /trunk/libavcodec/ (opt.c eval.c avcodec.h eval.h ratecontrol.c):
[23:01:15] <CIA-7> ffmpeg: Change the order of parameters for ff_eval_expr() and
[23:01:15] <CIA-7> ffmpeg: ff_parse_and_eval_expr(), place the names for constants/functions
[23:01:15] <CIA-7> ffmpeg: before the corresponding values.
[23:01:15] <CIA-7> ffmpeg: This looks more readable, as the user is expected to know the names
[23:01:16] <CIA-7> ffmpeg: before the values.
[23:15:21] <hyc> wbs: well, 2 problems down, 1 major one to go, ffserver rtsp is almost working now.
[23:16:25] <hyc> there's also a minor problem that it busyloops on input, and spends a lot of time reading 1 byte at a time from the network. frightening...
[23:16:54] <hyc> eats up 100% of a core on my laptop...