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

[irc at mansr.com]

[02:57:12] <Dark_Shikari> mru: you know anything about gcc and linking?
[02:57:29] <Dark_Shikari> we're getting some very bizarre behavior with loading from extern'd arrays
[04:09:10] <saintd3v> peloverde: dud baudline work for what you needed?
[04:09:39] <peloverde> It's working better than audacity for what I do
[08:42:23] <thresh> 23095 broke libavcodec/mpegaudiodec.c compile for me, http://pastebin.com/nBVpdK2g
[08:46:32] <thresh> i've got CONFIG_MPEGAUDIO_HP as 0
[08:48:07] <thresh> no idea though why i disabled it
[08:53:31] <_av500_> isnt it floating?
[09:00:58] <thresh> suppose assert is wrong there
[09:01:00] <thresh> yes
[09:01:24] <thresh> and also I use hardcoded tables, so it fails to find expval_table_float in mpegaudio_tables.h
[09:01:30] <thresh> how do I update those tables?
[09:06:34] <thresh> aha i need to update mpegaudio_tablegen
[10:02:55] <CIA-7> ffmpeg: michael * r23105 /trunk/libavcodec/ (tableprint.c tableprint.h): Support writing 2d float arrays, patch by Michael Kostyle
[10:03:24] <thresh> grr
[10:03:37] <CIA-7> ffmpeg: michael * r23106 /trunk/libavcodec/mpegaudio_tablegen.c: Fix mpegaudio tablegen patch by Michael Kostyle
[10:03:51] <thresh> grrr #2
[10:04:02] <thresh> i've just sent two mails like that :(
[10:05:19] <CIA-7> ffmpeg: michael * r23107 /trunk/libavcodec/mpegaudiodec.c: Fix compilation with low precission mpeg audio decoding.
[10:06:49] <janneg> thresh: read cvslog, patch was pending since yesterday
[10:07:39] <thresh> yeah, seems like i missed it
[10:07:41] <janneg> sorry that I didn't noticed this before
[10:08:05] <thresh> n/p
[10:29:53] <lu_zero_> hi
[10:31:40] <lu_zero> hi
[11:04:56] <_av500_> lo
[11:17:02] <mru> Dark_Shikari: did you fix your linking problem?
[11:18:32] <thresh> mru: if i need to conditionally check for a library and link libavdevice with it, what do I check for in configure?
[11:18:59] <mru> what lib?
[11:19:11] <thresh> you probably wouldnt answer me if you know ;-)
[11:19:13] <thresh> libv4l2.
[11:19:24] <mru> I'd rather we didn't touch that
[11:19:37] <mru> it doesn't do anything we couldn't easily do
[11:19:42] <mru> and it does it worse
[11:19:43] <thresh> well, I don't want to add hacks to my package
[11:20:02] <thresh> and I'm not really a guru in conversions, so I wouldnt even try to write one needed for my camera
[11:20:15] <mru> what format does it output?
[11:23:48] <thresh> let me check
[11:23:55] <thresh> one of my users also have a problem like that
[11:25:57] <thresh> i've got a similar camera to the one mentioned in https://roundup.ffmpeg.org/issue1816
[11:27:06] <mru> tl;dr
[11:27:23] <mru> actually, I've read most of that thread
[11:27:32] <mru> so which colour format is missing?
[11:29:55] <thresh> let me ping the guy, I don't have needed kernel headers here
[11:33:02] <CIA-7> ffmpeg: mru * r23108 /trunk/tests/fate.mak: FATE: change -vfilters to -vf
[11:38:22] <thresh> mru: V4L2_PIX_FMT_SPCA561
[11:38:24] <thresh> for instance..
[11:38:33] <mru> doesn't mean much to me
[11:38:37] <mru> what does it look like?
[11:39:51] <DonDiego> everybody please help clean up incoming - it's full..
[11:40:12] <thresh> mru: it is some weird format that needs decompressing, says libv4l2 source.
[11:40:32] <mru> libv4l is smoking crack
[11:40:53] <mru> if it's a compressed format, we should write a decoder for it
[11:41:18] <thresh> oh, here's even the relevant issue for S561, https://roundup.ffmpeg.org/issue1837
[11:42:19] <thresh> anyone's up for that? seems no. I'd rather had the working solution (even if it is a hack from your POV)
[11:42:40] <mru> well, I don't have a camera
[11:42:52] <mru> is it possible to dump a few raw frames from one?
[11:46:21] <thresh> not at the moment, the guy's camera is at home
[11:48:17] <thresh> so, regarding my question, where should I go?
[11:51:22] <mru> home
[11:52:10] <mru> if you can get a description of the format and some samples, implementing it properly shouldn't be hard
[11:55:37] <thresh> what really matters is this is just the only one cam out of dozens with various formats
[11:56:05] <mru> then we have more formats to implement
[11:56:10] <mru> read the damn discussion you pointed at
[11:56:48] <thresh> I already see a whole null of people who tried implementing (or asked about it) there
[11:57:23] <mru> that just means that nobody so far cared enough about it
[12:11:27] <mru> yay, firefox using 3.3GB ram
[12:20:36] <spaam> Nice
[12:26:47] <thresh> anyway, http://whoknowsmy.name/stuff/0001-libavdevice-v4l2-use-libv4l2-when-requested.patch
[12:26:52] <thresh> not sure about configure part though
[12:29:08] <mru> I'm telling you, it's not going to happen
[12:30:06] <thresh> i dont care really if it's in main ffmpeg tree
[12:31:08] <mru> that hostname doesn't resolve
[12:31:47] <CIA-7> ffmpeg: vitor * r23109 /trunk/tests/ (lavf-regression.sh lavfi-regression.sh): Replace "-vfilters" by "-vf" in regtests. Should fix regtest breakage.
[12:32:04] <iive> maybe you should replace the host part with his name?
[12:32:52] <thresh> fucking xname
[12:34:24] <iive> e.g. i haven't heard of 1'st level domain ".name"
[12:34:32] <mru> it exists
[12:41:22] <Compn> saudia arabia's tld is strange
[12:41:31] <Compn> the entire country name is the tld
[12:41:47] <Compn> imagine typing www.ffmpeg.organization :P
[12:42:00] <twnqx> .sa is strange?
[12:42:41] <Compn> http://en.wikipedia.org/wiki/Internationalized_country_code_TLD
[12:43:17] <thresh> yeah, .рф is also there, stupid stuff
[12:43:35] <Compn> Although the word code is used, some of these ccTLDs are not really codes but full words. For example ???????? (as-sa'owdiya) is not an abbreviation of Saudi Arabia, but the full name of the country in Arabic.
[12:43:44] <mru> http://www.iana.org/domains/root/db/
[12:44:16] <Compn> still waiting for .moon ...
[12:44:28] <Compn> and .xxx
[12:47:59] <Compn> bbl
[12:51:31] <thresh> should be working now, seems like xname had troubles
[13:05:49] <BastyCDGS> hi
[13:09:16] <BastyCDGS> hi BBB :)
[13:09:20] <BBB> hola
[13:09:33] <BastyCDGS> how are u?
[13:09:40] <BBB> sleepy
[13:09:43] <BBB> need coffee :)
[13:09:57] * BastyCDGS teleports a cup of coffee to BBB
[13:10:03] <BastyCDGS> *BING*
[13:13:52] <BastyCDGS> BBB, I wonder if there are problems with my patches pending for review
[13:14:08] <BBB> no idea, I've been busy at work for two days
[13:14:10] <BBB> so I didn't check
[13:14:26] <BBB> I told you the patch with extradata_size > 0 to remove the "> 0", which you haven't done yet
[13:14:31] <BBB> the other patches I haven't looked at yet
[13:15:35] <BastyCDGS> BBB, should I write now count > 0 or just count?
[13:16:14] <BBB> just count
[13:16:21] <BBB> the shorter the code, the better
[13:16:37] <BastyCDGS> ok will submit now
[13:17:23] <BBB> I'll commit the decodeplane8() one -> do{..}while(..);
[13:19:17] <CIA-7> ffmpeg: rbultje * r23110 /trunk/libavcodec/iff.c:
[13:19:17] <CIA-7> ffmpeg: Move a while(..){..} -> do{..}while(..), slightly faster.
[13:19:17] <CIA-7> ffmpeg: Patch by Sebastian Vater <cdgs basty googlemail com>.
[13:20:22] <BBB> ok that's in
[13:20:24] <BBB> anything else?
[13:20:39] <BBB> spyfeng: sorry I haven't been available too much, but good work, I think Michael is almost ok with your patch
[13:20:49] <BBB> spyfeng: have you looked at mms-http already?
[13:20:58] <BastyCDGS> the lavf/lavc palette splitting stuff
[13:22:14] <BBB> uhm... let me see
[13:22:36] <BBB> oh right I meant to ask why we would want to change CODEC_ID_RAW to CODEC_ID_IFF...
[13:22:42] <BBB> could you test whether it's slower/faster?
[13:22:48] <BBB> for that one image that you hae
[13:22:51] <BBB> *have
[13:28:16] <BastyCDGS> yes I will, I have to change this patch anyway after you applied the grayscale patch
[13:33:31] <BastyCDGS> avpicture_fill(picture, buf, avctx->pix_fmt, avctx->width, avctx->height);
[13:33:48] <BastyCDGS> this is what rawdec.c does
[13:33:57] <BastyCDGS> so maybe I should use this, too?
[13:34:37] <thresh> here's another link to patch I mentioned earlier, http://git.altlinux.org/people/thresh/packages/ffmpeg.git?p=ffmpeg.git;a=commitdiff;h=14dc2b2b343850c65f40596bd7dcbf07a2c20dc2
[13:37:58] <BBB> BastyCDGS: that's quite literally a memcpy
[13:38:05] <BBB> BastyCDGS: just compare performance if you can
[13:38:32] <BastyCDGS> well my patch does just a memcpy but one for each line instead of copying them all
[13:38:39] <BBB> thresh: I'm sorry but I'm a little against that patch
[13:38:45] <BastyCDGS> the thing is when masking support is added the code has to care of that
[13:38:57] <BastyCDGS> as well as HAM
[13:39:04] <thresh> BBB: as i've mentioned earlier, I don't care if it goes into main ffmpeg
[13:39:23] <BBB> ok so this PBM can have masking or HAM?
[13:39:40] <BBB> I didn't know that...
[13:39:44] <BBB> I guess it's ok then
[13:40:26] <BastyCDGS> yes it's the same as IFF-ILBM just that the pixels are saved in chunky format instead of planar format
[13:40:35] <BBB> ok
[13:40:45] <BastyCDGS> but I'll try with     avpicture_fill(picture, buf, avctx->pix_fmt, avctx->width, avctx->height); right now
[13:40:57] <BastyCDGS> since at moment it doesn't not make any sense for the line based loop
[13:43:15] <BBB> right
[13:43:21] <BBB> I just replied one more comment in the  thread
[13:43:27] <BBB> if you change the patch, I'll apply it
[13:43:29] <BBB> looks good
[13:55:57] <BastyCDGS> when I try it with one memcpy the lines don't align any more, i.e. the image totally looks distorted
[13:57:00] <BastyCDGS> the two buffers have different width alignment
[14:09:52] <BBB> hmm....
[14:10:00] <BastyCDGS> BBB, updated patch submitted
[14:10:06] <BBB> BastyCDGS: ok, try avpicture_fill then
[14:10:10] <BBB> did that work?
[14:10:17] <BBB> or did you need the line-based approach?
[14:10:28] <BastyCDGS> yes line-based approach is needed
[14:10:47] <BBB> can avpicture_fill do that?
[14:10:57] <BBB> hm, probably not
[14:10:59] <BBB> hold on
[14:11:29] <BBB> ok, got it
[14:17:17] <BBB> can you also supply a patch to rename and privatize ff_cmap_..()?
[14:17:23] <BBB> (for applying after this patch)
[14:17:31] <BastyCDGS> I just tested it the old still does fine
[14:18:24] <BastyCDGS> since it just touchs iff.h which the other doesn't and the lavc patch to iff.c is in complete different functions
[14:18:32] <BBB> ah ok
[14:18:34] <BBB> good
[14:33:40] <BBB> BastyCDGS: so if there's extradata, it's a palette right?
[14:33:43] <BBB> and else i's grayscale
[14:33:52] <BastyCDGS> exactly
[14:33:55] <BBB> avctx->pix_fmt = avctx->extradata_size ? PIX_FMT_GRAY8 : PIX_FMT_PAL8;
[14:33:58] <BBB> isn't that wrong?
[14:34:06] <BastyCDGS> no it isn't
[14:34:42] <BastyCDGS> I decided not to use extradata at all for the HAM stuff the problem is that in IFF-ANIM compression etc. can change, masking and therefore such data has to be in AVPacket->data anyway
[14:35:04] <BBB> ok
[14:35:09] <BBB> but then the palette is in extradata
[14:35:13] <BastyCDGS> so the if (count) won't harm anymore, too...it in fact can't happen anymore that count < 0
[14:35:25] <BastyCDGS> yes just only the palette it will stay that way
[14:35:32] <BastyCDGS> or nothing if no CMAP chunk found
[14:35:33] <BBB> so if extradata_size != 0 (which is the same as if exradaat_size), then we're a palette
[14:35:37] <BBB> but you're setting it to gray8
[14:35:41] <BBB> and to pal8 otherwise
[14:35:44] <BBB> it's the wrong way around
[14:36:03] <BastyCDGS> the original demuxer just has extradata_size == 0 if no CMAP chunk found
[14:36:18] <BastyCDGS> and only then the palette should be set to GRAY8
[14:36:30] <BastyCDGS> oh I see
[14:36:37] * BBB waits
[14:36:39] <BBB> ...
[14:36:40] <BBB> ...
[14:36:41] <BBB> ...
[14:36:52] <BBB> +        if ((avctx->pix_fmt == PIX_FMT_PAL8) || (avctx->pix_fmt == PIX_FMT_GRAY8)) { - also many brackets here, some can be removed
[14:41:59] <BastyCDGS> submitted new patch to ML for HAM
[14:43:50] <BastyCDGS> HAM? sorry
[14:44:01] <BastyCDGS> grayscale
[15:04:05] <BBB> ok, so this is settled now
[15:04:12] <BBB> what reads gray_pal8[]?
[15:04:24] <BBB> what worries me is that the palette becomes 1-byte instead of 4-bytes
[15:04:29] <BBB> is all code changed to take that into account?
[15:04:50] <BastyCDGS> exactly this:
[15:04:51] <BastyCDGS> uint8_t *gray_pal = (uint8_t *) pal;
[15:05:02] <BastyCDGS> pal is uint32_t
[15:05:12] <BastyCDGS> (the function gets it as uint32_t
[15:05:24] <BastyCDGS> but actually palette is 1-byte then
[15:05:33] <BastyCDGS> so I'm writing it 1-byte instead of 4
[15:05:51] <BBB> is it used?
[15:06:02] <BBB> I don't think GRAY8 expects a palette
[15:06:03] <BBB> does it?
[15:08:38] <BastyCDGS> I try this out
[15:11:12] <BastyCDGS> you were right!
[15:11:27] <BastyCDGS> palette data for GRAY8 is unnecessary :)
[15:12:54] <BBB> maybe you want to use if(extradata_size) instead of if(count) then
[15:13:17] <BBB> I wonder what the specs expect you to do if exradata_size is 1 or 2
[15:13:26] <BBB> (so not a full palette entry, where count=0, but cmap is clearly there)
[15:13:33] <BBB> does it want b/w or does it want you to go all-black?
[15:13:54] <BastyCDGS> I have removed the if (count) completely
[15:14:55] <BastyCDGS> it does not say about any extradata not-divisable by 3
[15:15:37] <BastyCDGS> anyway for 1 or 2:
[15:15:39] <BastyCDGS> count = FFMIN(avctx->extradata_size / 3, count);
[15:15:51] <BastyCDGS> this is integer division rounding to zero
[15:16:02] <BastyCDGS> i.e.  it will skip uncompleted palette data
[15:16:34] <BastyCDGS> remember to apply the palette underflow removal patch first
[15:16:47] <BBB> at the bottom of decode_init
[15:16:49] <BBB> add this:
[15:16:51] <BBB> avctx->bits_per_coded_sample <= 8
[15:16:53] <BBB> make that
[15:17:00] <BBB> avctx->bits_per_coded_sample <= 8 && avctx->extradata_size
[15:17:07] <BBB> that way it only reads the palette for PAL8
[15:17:09] <BBB> not for GRAY8
[15:17:11] <BBB> and you're safe
[15:19:22] <BastyCDGS> it has to call this function for HAM stuff later
[15:19:31] <BastyCDGS> since it must initialize the palette if HAM or EHB
[15:20:03] <BastyCDGS> for HAM we have to create a custom grayscale palette
[15:20:22] <BBB> right
[15:20:26] <BBB> but HAM doesn't output GRAY8
[15:20:31] <BBB> HAM outputs RGB32 or PAL8
[15:20:51] <BBB> so you can use that and change it to bps<=8&&pix_fmt!=GRAY8 then
[15:21:01] <BBB> which accomplishes the same thing
[15:22:03] <BastyCDGS> you mean I should initialize HAM grayscale palette data outside cmap_read_palette?
[15:22:11] <BBB> no you can it inside
[15:22:19] <BBB> but PIX_FMT != GRAY8 then
[15:24:33] <BastyCDGS> the thing is that leaving the pix_fmt!=GRAY8 away is the same...
[15:24:43] <BastyCDGS> because of FFMIN it is 0 then and the palette init isn't called at all
[15:25:04] <BastyCDGS> it's just extra code for exactly the same result
[15:25:49] <BBB> I don't want it to call the function
[15:26:30] <BBB> (if it doesn't have to)
[15:26:48] <BBB> because then we can enhance the function for the palette case, without having to worry that we might accidently break GRAY8 support
[15:27:07] * BBB goes look for palette underflow patch
[15:27:17] <BastyCDGS> can I change that in an extra patch
[15:27:40] <BastyCDGS> because adding this right now makes it dependant on the ff_ removal patch of cmap_read_palette
[15:28:36] <BBB> I can't find the palette underflow patch
[15:28:41] <BBB> well...
[15:28:47] <BBB> let's just say I'll apply this one right away if it's fine
[15:28:56] <BBB> so I'd place this patch before the ff_cmap_ rename one
[15:29:10] <BBB> the problem with that one is that it removes a function from our ABI
[15:29:13] <BBB> want to make sure that's ok
[15:29:30] <BastyCDGS> [PATCH] IFF: Handle palette underflows...
[15:29:33] <DonDiego> did i just miss the discussion of the mp* float decoder or did michael really commit it out of the blue?
[15:29:42] <BBB> he committed it out of the blue
[15:29:43] <mru> yes, he did
[15:29:47] <BastyCDGS> 9th may, 21:27 UTC
[15:29:49] <mru> and botched it as usual
[15:29:55] <DonDiego> :)
[15:30:26] <mru> as in badly designed interface and numerous fate breakages
[15:30:53] <DonDiego> hmm
[15:30:59] <DonDiego> any speed tests?
[15:31:14] <mru> soon
[15:31:22] <mru> and it ain't pretty
[15:31:33] <BBB> that bad?
[15:31:35] <BBB> hm :(
[15:31:41] <DonDiego> i'm looking through the diff right now, macros...
[15:31:46] <DonDiego> is it slow?
[15:31:47] <janneg> without hardware fp?
[15:31:54] <mru> 4x slower on cortex-a8
[15:32:01] <mru> + audioconvert slowness
[15:32:03] <DonDiego> x86?
[15:32:11] <mru> I'm sure someone else will test that
[15:32:14] <DonDiego> slower than what?
[15:32:19] <mru> integer
[15:32:21] <BBB> sorry that audioconvert is slow
[15:32:35] <BBB> but please see that as a separate issue for now
[15:32:38] <mru> it is
[15:32:45] <mru> it's 4x slower *before* audioconvert
[15:32:59] <mru> it's so slow audioconvert doesn't even look bad
[15:34:02] <BBB> BastyCDGS: done
[15:34:03] <BBB> BastyCDGS: next?
[15:34:20] <BBB> I think I can start by removing the demuxer call to ff_cmap_read
[15:34:29] <CIA-7> ffmpeg: rbultje * r23111 /trunk/libavcodec/iff.c:
[15:34:29] <CIA-7> ffmpeg: Handle palette underflows, fill remaining space with black (zero) data.
[15:34:29] <CIA-7> ffmpeg: Patch by Sebastian Vater <cdgs basty googlemail com>.
[15:34:49] <BBB> then after that let's get grayscale support in
[15:34:51] <BBB> then ham
[15:35:12] <BastyCDGS> ignore the HAM patch for now there has to change something
[15:35:17] <BBB> ok
[15:35:24] <BastyCDGS> grayscale now
[15:36:12] <BastyCDGS> ok do the demuxer call now
[15:37:29] <BBB> can't, it depends on the grayscale one I think
[15:38:00] <BBB> let me see
[15:38:43] <BBB> hm no, I'm wrong
[15:38:43] <BBB> ok
[15:38:45] <BastyCDGS> iff-palette-remove-avf.patch is ok
[15:38:49] <BastyCDGS> to apply before grayscale
[15:39:55] <BastyCDGS> and indent patch of course for it
[15:40:36] <CIA-7> ffmpeg: rbultje * r23112 /trunk/ (libavcodec/iff.c libavformat/iff.c):
[15:40:36] <CIA-7> ffmpeg: Move handling of paletted data to the IFF demuxer. This allows future
[15:40:36] <CIA-7> ffmpeg: handling of things such as masking/EHB/HAM for this type of data.
[15:40:36] <CIA-7> ffmpeg: Patch by Sebastian Vater <cdgs basty googlemail com>.
[15:42:17] <BBB> done
[15:42:24] <BBB> now re-do the grayscale one
[15:42:31] <BBB> then let's talk about the ham work
[15:42:40] <BastyCDGS> yeah
[15:42:40] <CIA-7> ffmpeg: rbultje * r23113 /trunk/ (libavcodec/iff.c libavformat/iff.c):
[15:42:40] <CIA-7> ffmpeg: Reindent after r23112.
[15:42:40] <CIA-7> ffmpeg: Patch by Sebastian Vater <cdgs basty googlemail com>.
[15:43:44] <BBB> good work :)
[15:43:48] <BBB> brb
[15:46:19] <BastyCDGS> I will do a build clean from latest git and test if everything still works until now safe is safe ;)
[15:58:56] <BastyCDGS> BBB, is that layout ok?
[15:58:57] <BastyCDGS> if ( (avctx->bits_per_coded_sample <= 8) &&
[15:58:57] <BastyCDGS>          (avctx->pix_fmt != PIX_FMT_GRAY8) )
[15:58:57] <BastyCDGS>         err = ff_cmap_read_palette(avctx, (uint32_t*)s->frame.data[1]);
[16:00:25] <BastyCDGS> I added the parenthesis so the err = line is indented different than the statement belonging to if line
[16:00:47] <BBB> too many brackets again :)
[16:01:04] <BBB> but otherwise it's ok yes
[16:01:38] <BastyCDGS> so I just remove the brackets around the &&'s and it's fine?
[16:02:46] <BBB> basically ((..) && (..)) -> (.. && ..)
[16:02:51] <BBB> and yes
[16:03:02] <BBB> can you also look if av_picture_copy is useful as michael suggested?
[16:03:05] <BBB> if not it's ok
[16:03:20] <BBB> (i.e. you don't have to do anything, just reply saying "doesn't work because ...")
[16:17:11] <BastyCDGS> BBB, uhm I just figured out that when I do not initialize the grayscale palette it's way too dark for some images
[16:18:43] <BastyCDGS> one question does PAL_FMT_GRAY8 use the same graying method than (col_index * 255) >> bits_per_coded_sample?
[16:19:27] <BastyCDGS> col_index is the image pixel value at x,y
[16:22:51] <BastyCDGS> yes these two methods aren't compatible
[16:22:56] <BastyCDGS> so we can't use PIX_FMT_GRAY8
[16:23:12] <BastyCDGS> we just have to initialize the custom grayscale palette to display the images according to IFF specs
[16:24:06] <BBB> I think it depends on bits_per_coded_image
[16:24:16] <BBB> GRAY8 assumes bps=8
[16:24:27] <BBB> if bps!=8, you can't use GRAY8
[16:24:32] <BBB> you have to use something else
[16:25:04] <BastyCDGS> oh so I should just set to GRAY8 when bps == 8
[16:26:11] <KotH> moin boys
[16:26:23] <mru> what about the girls?
[16:26:41] <KotH> DonDiego: we're currently working on the 0.6 release notes, do you want to giv e any input?
[16:26:50] <KotH> mru: rounding error
[16:27:49] <CIA-7> ffmpeg: siretart * r23114 /branches/0.6/Changelog: update version string in changelog
[16:28:06] <janneg> mru: only probetest needs HAVE_AV_CONFIG_H
[16:28:56] <mru> are you sure?
[16:29:26] <mru> hmm, someone must have fixed trasher
[16:31:48] <CIA-7> ffmpeg: michael * r23115 /trunk/libavutil/ (internal.h attributes.h):
[16:31:48] <CIA-7> ffmpeg: av_alias is an attribute and belongs to attributes.h
[16:31:48] <CIA-7> ffmpeg: also attributes.h is public and external api and can thus not depend
[16:31:48] <CIA-7> ffmpeg: on configure tested compiler support thus this part is removed. A
[16:31:48] <CIA-7> ffmpeg: different solution must be found if this breaks for some compiler
[16:31:48] <CIA-7> ffmpeg: which i hope it does not.
[16:33:09] <CIA-7> ffmpeg: michael * r23116 /trunk/libavcodec/mathops.h:
[16:33:09] <CIA-7> ffmpeg: Use standard C for implementing sign_extend() and zero_extend().
[16:33:09] <CIA-7> ffmpeg: This fixes compilation of probetest
[16:34:56] <janneg> mru: yes, make alltools worked after fixing probetest but micheal fixed it
[16:35:10] <mru> and broke other things in the process
[16:38:06] <Dark_Shikari> mru: we had some weird cases with gcc using more complex instruction sequences to access extern arrays as opposed to static arrays...
[16:38:09] <Dark_Shikari> ... with pic off
[16:38:11] <CIA-7> ffmpeg: siretart * r23117 /branches/0.6/RELEASE: first draft of the release notes
[16:38:26] <mru> Dark_Shikari: pic or no pic doesn't matter there
[16:38:44] <Dark_Shikari> yes it does, because global arrays have to go through a layer of indirection
[16:38:44] <siretart> DonDiego: KotH: ^^
[16:38:48] <Dark_Shikari> because it has to support dynamic reloading
[16:38:54] <Dark_Shikari> hence visibility attributes
[16:39:12] <mru> exactly, pic or not doesn't matter
[16:39:21] <Dark_Shikari> but that's only in PIC, right?
[16:39:24] <mru> no
[16:39:34] <Dark_Shikari> Ah
[16:39:38] <mru> pic is entirely orthogonal to symbol resolution
[16:39:38] <Dark_Shikari> but then that's even weirder
[16:39:53] <Dark_Shikari> because what I'm talking about only occurred in some .c files
[16:39:58] <Dark_Shikari> sone .c files optimized correctly
[16:40:00] <Dark_Shikari> others didn't
[16:40:17] <mru> what was the difference?
[16:40:23] <mru> did it do a GOT indirection?
[16:40:40] <Dark_Shikari> http://pastebin.org/228417
[16:40:52] <Dark_Shikari> No indirection.
[16:40:58] <Dark_Shikari> which makes it weirder.
[16:41:20] <mru> %ebx holds the address of the array?
[16:41:23] <BastyCDGS> BBB, I just test and if it's ok I'll submit the grayscale patch to ML
[16:41:42] <Dark_Shikari> this is to do two loads from an array
[16:41:52] <Dark_Shikari> ebx holds the index into the array
[16:42:05] <mru> wtf?
[16:42:09] <mru> what's the base address?
[16:43:00] <mru> 32-bit immediate address?
[16:43:14] <mru> and a textrel?
[16:43:32] <Dark_Shikari> I think that particular example is obviously from x86_32
[16:43:34] <Dark_Shikari> with pic off
[16:43:44] <Dark_Shikari> also, gcc 4.4
[16:43:57] <Dark_Shikari> Oh, and we found that prior to gcc 4.5, gcc was unable to optimize out constant accesses to static local arrays
[16:44:03] <Dark_Shikari> *constant static
[16:44:23] <mru> not surprising
[16:44:51] <Dark_Shikari> also, more weirdness
[16:44:52] <Dark_Shikari> see this patch
[16:44:53] <Dark_Shikari> http://pastebin.org/pastebin.php?dl=228768
[16:44:59] <Dark_Shikari> important part is line 62-64
[16:45:14] <Dark_Shikari> This made the .so smaller, but made the executable file bigger
[16:45:31] <Dark_Shikari> it makes no sense
[16:45:52] <mru> check the sizes of different sections
[16:46:03] <Dark_Shikari> I did
[16:46:07] <mru> it could have make .text smaller and something else bigger
[16:46:14] <mru> perhaps with padding somewhere
[16:46:34] <mru> I've seen gnu tools create elf files hundreds of kilobytes larger than necessary
[16:46:41] <Dark_Shikari> 14:20 < Dark_Shikari> hmm in patched, .text is 762152 and rodata is 57356
[16:46:41] <Dark_Shikari> 14:20 < Dark_Shikari> unptached, .text is 761896 and rodata is 57356
[16:46:51] <mru> what about .rel.*
[16:46:59] <Dark_Shikari> how do those work?
[16:47:05] <mru> those are the relocations
[16:47:06] <Dark_Shikari> and which ones do you want?
[16:47:10] <mru> did they change?
[16:47:23] <Dark_Shikari> rela.dyn: 1080, rela.plt: 1800, data.rel: 2248 (unpatched)
[16:47:31] <mru> but if .text got larger, that's weird
[16:47:47] <Dark_Shikari> rela.dyn: 384, rela.plt: 1728, data.rel.ro: 2248 (patched)
[16:47:56] <Dark_Shikari> so we saved 600 bytes on rela.dyn, but text got larger
[16:48:42] <DonDiego> KotH: where are the release notes?
[16:51:18] <mru> anyway, about that addressing
[16:51:51] <Dark_Shikari> also, I'm looking for a tool that would allow me to measure the size of a program's working set
[16:52:07] <Dark_Shikari> where "working set" means "how many unique cachelines it reads and writes to during a particular period of time"
[16:52:07] <mru> can you show the machine code for those instructions?
[16:52:23] <mru> tried cachegrind?
[16:52:27] <Dark_Shikari> it doesn't really do that
[16:52:34] <Dark_Shikari> I want to e.g. see how many cachelines x264 needs to encode one macroblock
[16:52:45] <Dark_Shikari> it counts the number of refs, not the number of unique refs
[16:53:15] <mru> patch it
[16:53:19] <Dark_Shikari> lol
[16:53:24] <Dark_Shikari> wonder how hard that would be...
[16:53:32] <ohsix> you could do that with perf
[16:53:40] <mru> it's a simulated cache model so it shouldn't be terribly hard
[16:53:45] <Dark_Shikari> perf?
[16:53:51] <mru> perf events don't tell you that
[16:54:10] <mru> they can count number of memory accesses and number of hits/misses
[16:54:34] <Dark_Shikari> I could do it if it tracked where memory accessed occurred
[16:54:38] <Dark_Shikari> and gave me a list
[16:54:41] <ohsix> they can do any event counter, like oprofile can; but it works differently
[16:54:54] <mru> yes, but I've never heard of such a counter
[16:55:11] <Dark_Shikari> you'd think cachegrind could dump memory accesses
[16:55:26] <mru> you could probably patch it to do that
[16:55:34] <Dark_Shikari> Yeah, probably
[16:55:37] <Dark_Shikari> That sounds much easier
[16:57:36] <mru> Dark_Shikari: but can you post the machine code for that array access?
[16:57:51] <Dark_Shikari> I already did
[16:57:56] <mru> no
[16:57:58] <mru> you posted disasm
[16:58:03] <mru> I want the raw insns
[16:58:11] <Dark_Shikari> oh... I'd have to harass Gramner for that
[16:58:15] <Dark_Shikari> and it went away in gcc 4.5, so...
[16:58:18] <Dark_Shikari> oh wait, that wasn't what went away
[16:58:22] <Dark_Shikari> the constant propagation issue went away
[16:58:26] <Dark_Shikari> hmm, I'd have to ask him
[16:58:30] <Dark_Shikari> I had issues replicating it on my system.
[16:58:39] <mru> just the full objdump output for those lines
[16:58:47] <Dark_Shikari> ok, asked
[16:58:51] <mru> and the output of readelf -r on those files too
[16:59:01] <Dark_Shikari> wait but that was objdump output
[16:59:08] <mru> objdump -d
[16:59:15] <mru> _including_ raw instruction bytes
[16:59:18] <Dark_Shikari> ahhhh k
[16:59:26] <mru> address: hex mnemonic
[16:59:51] <mru> readelf -r prints the relocation table
[17:16:51] <BastyCDGS> BBB, new grayscale patch submitted to ML
[17:22:09] <BastyCDGS> oops posted it into the wrong thread, sorry
[17:27:10] <mru> BastyCDGS: you don't need to tell us here about every mail you send to the ml
[17:27:16] <kierank> lol
[17:27:24] <Dark_Shikari> yay, now we're getting the x264 commercial license written
[17:27:30] <BastyCDGS> lol ok you're right
[17:27:35] <Dark_Shikari> this is particularly fun, it's like writing a commercial license without all the evil parts
[17:28:01] <Dark_Shikari> well, fun until we see the bill, but hey...
[17:31:53] <Gramner> mru: http://files.gramner.com/x264/
[17:32:36] <BBB> BastyCDGS: don't forget AVPicture == AVFrame
[17:32:42] <BBB> decode_video() should have an AVFrame somewhere
[17:32:50] <BBB> you can cast between the two where required
[17:33:46] <BastyCDGS> ahh didn't know this thank
[17:34:34] <BastyCDGS> but anyway as said I need it this way for masking support
[17:39:39] <BastyCDGS> also only src parameter is AVPicture, the second one is raw data uint_8 * so I would have to add an extra structure anyway.
[17:41:53] <BBB> memcpy() also takes a uint8_t*
[17:42:14] <BBB> so instead of copying from buf to avpicture->data[0], you copy from buf to avpicture (period)
[17:42:20] <BBB> right?
[17:44:18] <BastyCDGS> yes
[17:44:36] <BastyCDGS> but they're exactly in the correct order with memcpy ;)
[17:46:01] <BastyCDGS> anyway, I will have to add some per line code when masking support will be added
[17:53:20] <BBB> so masking is per-line?
[17:53:27] <BBB> I mean, that might be a good reason to keep the code as-is
[17:53:28] <mru> Gramner: where are the bad instructions?
[17:53:31] <BBB> but then you need to reply that ;)
[17:53:38] <BastyCDGS> yes per line
[17:53:54] <BastyCDGS> that's why I'm saying it
[17:53:54] <Gramner> in the middle of that function
[17:55:43] <Gramner> starts at around line 250 i think
[17:56:19] <mru> Gramner: which address is that? firefox doesn't number the lines
[17:56:34] <Gramner> 7274
[17:58:17] <mru> can you please just say exactly which addresses are the interesting ones?
[17:58:25] <mru> you apparently figured it out once already
[17:59:12] <CIA-7> ffmpeg: michael * r23118 /trunk/libavcodec/mpegaudiodec.c:
[17:59:12] <CIA-7> ffmpeg: Cast constants to float to avoid gcc converting to and from
[17:59:12] <CIA-7> ffmpeg: float<->double in every operation.
[17:59:57] <Gramner> 732e in static / 7346 in extern for example
[18:07:31] <CIA-7> ffmpeg: michael * r23119 /trunk/libavcodec/mpegaudiodec.c:
[18:07:31] <CIA-7> ffmpeg: 1.0 and the resulting exactly representable value must be marked as float as well,
[18:07:31] <CIA-7> ffmpeg: gcc is hopelessly trash.
[18:07:43] <Dark_Shikari> lol
[18:08:17] <mru> adding -fsingle-precision-constant breaks lots of tests btw
[18:08:34] <BastyCDGS> and there's still missing:
[18:08:34] <BastyCDGS>  #   define FIXR_OLD(a)    ((int)((a) * FRAC_ONE + 0.5))
[18:08:36] <BastyCDGS> =>
[18:08:37] <BastyCDGS> #   define FIXR_OLD(a)    ((int)((a) * FRAC_ONE + 0.5f))
[18:10:15] <Dark_Shikari> btw, all these problems still occur with -ffast-math right?
[18:11:05] <mru> there is definitely code that isn't safe with that flag
[18:11:16] <mru> anything that might generate a NaN is unsafe
[18:12:33] <CIA-7> libswscale: ramiro * r31170 /trunk/libswscale/ (15 files in 6 dirs): (log message trimmed)
[18:12:33] <CIA-7> libswscale: Revert r31153. It failed to build on:
[18:12:33] <CIA-7> libswscale: x86_64 / Mac OS X gcc 4.0.1
[18:12:33] <CIA-7> libswscale: x86_64 / Linux icc (all)
[18:12:33] <CIA-7> libswscale: x86_64 / Linux gcc 4.0.4
[18:12:34] <CIA-7> libswscale: x86_64 / OpenBSD gcc 3.3.5
[18:12:34] <CIA-7> libswscale: x86_64 / Linux suncc 5.10
[18:13:42] <mru> Gramner: in the static one, what is the address of the array being indexed?
[18:14:20] <Dark_Shikari> hmm, I can't replicate michael's issue here
[18:14:53] <Dark_Shikari> I'm not getting redundant double->float casts
[18:15:25] <mru> anyway, if you look at the extern case, you'll see that the mov X, %esi has a textrel for x264_scan8_lut
[18:16:00] <mru> the static one doesn't have a relocation at all there
[18:16:04] <Dark_Shikari> why is that?
[18:16:18] <mru> isn't that the array you're indexing?
[18:16:35] <Dark_Shikari> why would the static one not have a relocation?  it's still rodata
[18:16:44] <BBB> I saw his problem
[18:16:47] <BBB> might be gcc-specific
[18:16:47] <mru> where does the value in %ebx come from?
[18:16:55] <BBB> better to help gcc if there's any chance it might screw up
[18:16:58] <BBB> if it can, it will
[18:17:00] <BBB> apparently
[18:18:29] * BBB notices that he's starting to bash gcc randomly
[18:18:31] <BBB> <- bad
[18:18:37] <mru> no, that's good
[18:18:41] <mru> you're finally learning
[18:19:44] <BBB> maybe it's because I'm finally learning how a compiler can do right and wrong
[18:19:59] <BBB> previously all I knew was that this compiler compiled this magic language C into machine code that looked rather creepy
[18:20:19] <janneg> gcc 4.5 needs probably -fexcess-precision=fast
[18:20:48] <janneg> -std=c99 activates -fexcess-precision=standard
[18:20:48] <mru> the 4.5 release notes had some warning about float being slower by default
[18:20:55] <Dark_Shikari> ahhhhh
[18:20:58] <Dark_Shikari> that might be it
[18:21:05] <Dark_Shikari> actually that's something we should do in x264
[18:21:08] <Dark_Shikari> we just threw in std=c99
[18:21:12] <Dark_Shikari> ... then again, we use -ffast-math
[18:21:13] * mru wouldn't touch 4.5 with a 10-foot pole just yet
[18:21:19] <Dark_Shikari> does ffast-math imply excess-precision=fast?
[18:21:25] <mru> rtfm
[18:22:17] <janneg> http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00105.html
[18:22:20] <mru> Gramner, Dark_Shikari: where does %ebx get set for those loads?
[18:22:40] <Dark_Shikari> I don't know, ask Gramner
[18:23:06] <Gramner> to be honest i'm not very knowledgeable about this sort of stuff, i only noticed that extra ops got inserted in some places for some reason
[18:23:36] <mru> well, here's my theory
[18:23:53] <mru> if the array is static, gcc knows its offset from .rodata
[18:24:40] <mru> so if it already knows some address in .rodata it can just use that and tweak the offsets
[18:24:58] <mru> if the array is extern, it has to fetch its address explicitly
[18:25:11] <mru> since the final location is resolved at link-time
[18:26:18] <Gramner> but why does that only happen in some files and not others?
[18:26:55] <CIA-7> ffmpeg: stefano * r23120 /trunk/libavfilter/parseutils.c: Make av_parse_color() return AVERROR(EINVAL) rather than -1.
[18:26:57] <CIA-7> ffmpeg: stefano * r23121 /trunk/libavfilter/vf_pad.c:
[18:26:57] <CIA-7> ffmpeg: Make the init and config_filter callbacks of the pad filter return
[18:26:57] <CIA-7> ffmpeg: AVERROR(EINVAL) rather than -1 in case of invalid parameters.
[18:26:57] <CIA-7> ffmpeg: stefano * r23122 /trunk/libavfilter/vf_pad.c:
[18:26:57] <CIA-7> ffmpeg: Remove the name of the file from the @file doxy, it is unnecessary and
[18:26:57] <CIA-7> ffmpeg: inconsistent with the other files.
[18:31:46] <bcoudurier> hi guys
[18:31:50] <Dark_Shikari> hi bcoudurier's onjoin script
[18:42:09] <CIA-7> ffmpeg: mru * r23123 /trunk/libavcodec/Makefile: Add mpegaudiodec_float.o dependency on tables header with hardcoded tables
[18:51:11] <BastyCDGS> BBB, changing avctx->pix_fmt == PAL8 ? .. : .. will break it for HAM
[18:51:18] <BastyCDGS> so the != GRAY8 check is better
[19:01:17] <BBB> why?
[19:01:32] <BBB> because ham uses rgb32 but does not a palette?
[19:01:47] <BastyCDGS> yes but ham needs the palette data to decode
[19:02:29] <BastyCDGS> I submitted fix vor inline function instead of macro though.
[19:04:15] <BBB> got it
[19:04:19] <BBB> ok, that part is fine then
[19:04:22] <BBB> one other comments, see email
[19:04:24] <BBB> then it's ok
[19:12:27] <BastyCDGS> so fixed ;)
[19:13:04] <wbs> bcoudurier: any objections to committing this one? http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100502/cc11fea2/attachment.patch
[19:14:20] <bcoudurier> nope, go ahead
[19:14:32] <wbs> ok, good
[19:14:33] <BastyCDGS> hi jai :)
[19:14:59] <BBB> BastyCDGS: ok, this is good
[19:15:03] <wbs> bcoudurier: this one, too? http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100502/b6b291a4/attachment.patch
[19:16:54] <CIA-7> ffmpeg: rbultje * r23124 /trunk/libavcodec/iff.c: Grayscale support. Patch by Sebastian Vater <cdgs basty googlemail com>.
[19:18:09] <CIA-7> ffmpeg: mstorsjo * r23125 /trunk/tools/qt-faststart.c: qt-faststart: Use the error_out cleanup code path for all error returns
[19:18:10] <CIA-7> ffmpeg: mstorsjo * r23126 /trunk/tools/qt-faststart.c: Cosmetics: reindent
[19:18:47] <CIA-7> ffmpeg: mstorsjo * r23127 /trunk/tools/qt-faststart.c: Cosmetics: Initialize pointers with NULL instead of 0, for consistency
[19:19:28] <CIA-7> ffmpeg: rbultje * r23128 /trunk/libavcodec/iff.c: Reindent after r23124. Patch by Sebastian Vater <cdgs basty googlemail com>.
[19:19:36] <BBB> next
[19:19:40] <BBB> where's the new ham patch?
[19:20:44] <bcoudurier> wbs, well ok
[19:22:39] <BastyCDGS> BBB, I think it's better to apply the make cmap_read_palette static and remove the public function
[19:22:52] <wbs> bcoudurier: great, thanks
[19:23:46] <CIA-7> ffmpeg: mstorsjo * r23129 /trunk/tools/qt-faststart.c:
[19:23:47] <CIA-7> ffmpeg: qt-faststart: Abort scanning of the input file if a badly sized atom is encountered
[19:23:47] <CIA-7> ffmpeg: If the atom size is 0, qt-faststart currently hangs forever while scanning
[19:23:47] <CIA-7> ffmpeg: the file.
[19:24:02] <BBB> BastyCDGS: can't, need to wait for distributor comments
[19:24:05] <BBB> maybe reinhardt
[19:24:20] <BBB> it's an ABI changen
[19:24:24] <BBB> let that one be for now
[19:24:30] <wbs> siretart: ping, on the "remove ff-prefixed function that lavf despite that uses currently" issue
[19:25:01] <wbs> siretart: aka http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-May/088457.html
[19:27:36] <BastyCDGS> BBB, then let's discuss HAM now
[19:29:20] <_av500_> yum
[19:29:31] <BastyCDGS> hi saste :)
[19:29:39] <mru> spanish or italian ham?
[19:29:54] <spaam> spam!
[19:30:04] <spaam> spam spam spam spam
[19:30:17] <siretart> wbs: thanks for pinging me. I'm looking up the thread
[19:31:38] <siretart> wbs: how likely is that function used outside of ffmpeg? e.g. does mplayer use it?
[19:32:54] <BBB> BastyCDGS: submit latest patch please
[19:32:56] <BBB> and we'll discuss
[19:33:09] <BBB> siretart: ff_cmap()?
[19:33:13] <BBB> only in libavf
[19:33:18] <BBB> mplayer can't use it
[19:33:22] <BBB> if it does, it's broken
[19:36:24] <siretart> in that case I think it's safe to just drop it
[19:38:05] <BastyCDGS> BBB, just submitted
[19:39:01] <wbs> siretart: btw, in the preliminary 0.6 releasenotes, did you miss rtp depacketization of amr (which usually goes hand in hand with h263)? and the packetization of both formats from sometimes last year seems to be missing, too?
[19:39:55] <siretart> wbs: probably. I take your comment that you feel that's noteworthy? in that case, please just add them, ok?
[19:40:33] <wbs> siretart: ok, will do
[19:41:44] <siretart> tahnks!
[19:42:37] <wbs> done
[19:43:26] <CIA-7> ffmpeg: mstorsjo * r23130 /branches/0.6/RELEASE: Mention that both packetizers and depacketizers of H.263 and AMR were added
[19:43:27] <wbs> the combination rtsp + rtp/h263/amr gives the highlevel "decode mobile youtube videos" feature :-)
[19:49:59] <BastyCDGS> well I think before actually doing the HAM stuff, we should discuss now how to do pass HAM, masking, compression, etc. from demuxer to decoder
[19:50:29] <BastyCDGS> I think using AVPacket->data is the best way, since some of these values can change during IFF-ANIM frames
[19:55:59] <siretart> wbs: pong on ""remove ff-prefixed function that lavf despite that uses currently" issue.
[19:57:54] <wbs> siretart: ok, thanks :-)
[19:59:23] <wbs> hmm, interestingly enough, if we first clean up more such stuff in lavf, it will actually be harder to notice which of the lavc-private functions actually are in use by older lavf-versions
[20:00:01] <wbs> but despite that, I guess it's good to clean up such stuff from lavf, and add notes to those functions in lavc saying that they're in practice public
[20:01:04] <BastyCDGS> I just added a dummy function for it
[20:04:07] <BBB> BastyCDGS: try AVPacket->data without any obvious hacks and see if that works
[20:04:10] <BBB> I'd like to see if that works
[20:04:28] <wbs> FWIW, http://pastebin.org/231453 are the ff_ prefixed functions used by lavf
[20:05:45] <BastyCDGS> do I have to transfer data in AVPacket with the bytestream functions, too? like I did with extradata?
[20:05:58] * BBB throws peloverde some cookies
[20:06:15] <peloverde> for?
[20:06:20] <BBB> how do you read it in the demuxer again?
[20:06:24] <BBB> is it part of the frame header?
[20:06:35] <BBB> peloverde: flaming michael
[20:07:10] * wbs throws a bunch of cookies at peloverde, too
[20:07:18] <wbs> for working on very useful stuff :-)
[20:08:36] <BBB> I wasn't trying to be negative
[20:08:40] <BBB> I threw him cookies, not dirt
[20:08:54] <wbs> I wasn't negative either
[20:09:01] <BBB> ok :)
[20:09:04] <siretart> wbs: you can look at the lavf  files that #include non-public lavc headers...
[20:13:21] <wbs> sure.. should I file roundup cases for each of them? I don't think I have the time to try to fix them
[20:13:59] <BBB> send an email and ask maintainers to fix it
[20:14:07] <BBB> after a week, file issue entries for the rest
[20:14:12] <BBB> might save you a lot of time
[20:26:36] <BastyCDGS> what is this in AVPacket?
[20:26:36] <BastyCDGS> void *internal_buffer;
[20:27:56] <BastyCDGS> or can I do such stuff with:
[20:27:56] <BastyCDGS> int (*execute)(struct AVCodecContext *c, int (*func)(struct AVCodecContext *c2, void *arg), void *arg2, int *ret, int count, int size);
[20:31:10] * BBB slaps BastyCDGS for thinking of random hacks
[20:31:34] <BastyCDGS> I just want to know what these are for
[20:31:39] <BBB> threading
[20:31:56] <BastyCDGS> internal_buffer, too?
[20:32:02] <BBB> not sure about that one
[20:32:51] <BastyCDGS> void  *AVPacket::priv what is this exactly for?
[20:34:10] <mru> :: doesn't mean anything around here
[20:34:53] <BastyCDGS> wanted just to mention that I meant AVPacket's priv
[20:35:09] <BastyCDGS> for whom it's private
[20:35:36] <BastyCDGS> can both demuxer and decoder access it?
[20:36:02] <wbs> I don't think it's for such use, it's probably private to the one that has allocated an AVPacket
[20:36:07] <BastyCDGS> so I can use it as extradata for the decoder from the demuxer
[20:37:00] <wbs> no, absolutely not
[20:37:26] <wbs> the decoder is not allowed to touch such data
[20:38:54] <BastyCDGS> then AVPacket->data is the only one possibility
[20:39:06] <BastyCDGS> so we have 2 possibilities here
[20:39:10] <BastyCDGS> prepend or append
[20:40:01] <BastyCDGS> prepend is problematic because it breaks compatibility between old + new decoder/demuxer
[20:40:22] <BastyCDGS> so append ensures that an old decoder can still decode data from new demuxer
[20:41:23] <wbs> is this still the same codec id as existing stuff? I know you suggested something that added like 10 new codec ids earlier, which was rejected
[20:41:42] <wbs> but something like CODEC_ID_IFF_HAM or such, would that make sense?
[20:42:28] <CIA-7> ffmpeg: cehoyos * r23131 /trunk/libavcodec/ac3dec.c: Fix compilation of AC3 decoder if E-AC3 decoder was disabled.
[20:42:52] <BastyCDGS> or use codec_tag i.e. create a fourcc for HAM and masked planar?
[20:43:19] <wbs> perhaps
[20:45:52] <BastyCDGS> I'm just thinking at the most compatible way to indicate a new format style packet with extradata
[20:46:25] <BastyCDGS> codec_tag is a bit problematic here, because the decoder only checks if it's ILBM and if not it always assumes PBM
[20:47:04] <BastyCDGS> a different codec_id will probably better, but only one
[20:48:45] <BastyCDGS> I have an idea, we add a new codec_id to:
[20:48:45] <BastyCDGS>     CODEC_ID_IFF_ILBM,
[20:48:45] <BastyCDGS>     CODEC_ID_IFF_BYTERUN1,
[20:48:48] <BastyCDGS> avcodec.h
[20:48:57] <BastyCDGS> CODEC_ID_IFF_NEW,
[20:49:49] <BastyCDGS> which takes a well defined structure to AVPacket->data before the beginning of the actual data.
[20:49:57] <mru> no
[20:50:17] <BastyCDGS> what's the problem with it, mru?
[20:50:37] <mru> codec id proliferation is bad
[20:51:49] <thresh> mru: thanks
[20:51:53] <BastyCDGS> so should I don't care about compatibility  when appending extradata to AVPacket->data
[20:52:07] <mru> what are you doing?
[20:52:18] <mru> that sounds very wrong
[20:52:54] <BastyCDGS> the stuff that was in extradata must go into AVPacket
[20:53:00] <mru> why?
[20:53:18] <BastyCDGS> because these values can change (esp. compression) during frames with IFF-ANIM
[20:53:38] <BastyCDGS> michael told me that such stuff can't goto AVFrame etc.
[20:53:46] <mru> how does iff-anim signal such changes?
[20:54:10] <BastyCDGS> ANHD chunk for each frame
[20:54:23] <BastyCDGS> but actual data is in DLTA chunk
[20:54:28] <mru> and you're putting that in extradata now?
[20:54:40] <BastyCDGS> that's what I wanted to do
[20:54:48] <BastyCDGS> masking transparent color can also change each frame
[20:55:03] <mru> but does the code currently in svn do that?
[20:55:04] <BastyCDGS> the only one which doesn't was ehb/ham flag
[20:55:52] <BastyCDGS> no it doesn't use either, except AVFrame->extradata for the palette lonely and AVPacket->data for the raw data from the BODY chunks
[20:56:06] <mru> if you'd only be "breaking" something that doesn't work anyway, there's nothing to be concerned about
[20:56:33] <wbs> BastyCDGS: the actual data for IFF-ANIM, would it use one of the existing codec ids, or would it use a new one?
[20:56:42] <mru> there is no AVFrame.extradata
[20:56:44] <mru> what did you mean?
[20:57:01] <BastyCDGS> sorry did mean AVCodecContext
[20:57:14] <wbs> if the actual data is totally different, you shouldn't be hijacking some old codec id for it
[20:57:53] <BastyCDGS> wbs, that's why I had my idea above for using a new codec id
[20:57:59] <BastyCDGS> und thus use a new one
[20:58:08] <mru> but that should have a proper name and not a silly _NEW suffix
[20:58:21] <wbs> like CODEC_ID_IFF_ANIM or something such?
[20:58:23] <BastyCDGS> because I'm still thinking of a better name ;)
[20:59:13] <BastyCDGS> codec ID anim should really indicate an IFF-ANIM stream
[20:59:13] <wbs> when you declare a new codec id, it should be quite well-defined and not just some id that you choose to use for passing your data for that particular day
[20:59:23] <BastyCDGS> not a HAM picture and/or masked picture
[21:00:49] <wbs> is each frame in IFF-ANIM a full keyframe in one of the earlier normal still picture formats, or can they be some totally separate format, too?
[21:01:05] <BastyCDGS> do you think it's acceptable that I call the CODEC_ID_IFF_ANIM codec for HAM6/masking pictures, too?
[21:01:30] <BastyCDGS> yes they can be a totally separate format, too.
[21:01:36] <mru> are still images a subset of anim?
[21:01:36] <BastyCDGS> DLTA chunks
[21:01:43] <BastyCDGS> yes
[21:01:51] <BastyCDGS> at least the first chunk is normal IFF-ILBM
[21:01:59] <BastyCDGS> the're can be as many as possible
[21:02:01] <mru> so a still could be considered a single-frame anim?
[21:02:29] <BastyCDGS> yes
[21:02:36] <mru> then they should use the same codec id
[21:02:57] <zorgy7> hi guys
[21:03:13] <zorgy7> i want to have a start on the small tasks
[21:03:14] <BBB> what you want is to use the PKT_FLAG_KEY in AVPacket->flags
[21:03:22] <BBB> BastyCDGS: if it's set, it's a regular ILBM frame
[21:03:23] <zorgy7> particularly the huffman one: http://guru.multimedia.cx/small-tasks-for-ffmpeg/
[21:03:32] <BBB> BastyCDGS: if it's not set, you're dealing with a DLTA chunk
[21:03:48] <BBB> (and set it in the demuxer where appropriate
[21:04:01] <wbs> BBB: i think he needs to pass a few more bits of info than that, since the raw data can be in a few different formats
[21:04:05] <zorgy7> do I need to edit the mjpeg.c in libavcodec?
[21:04:10] <mru> if we need to change the format of existing (extra)data, that's not a problem imo
[21:04:29] <BBB> zorgy7: yes
[21:04:30] <mru> the one user on the planet can surely cope with it
[21:04:34] <BastyCDGS> didn't you mean if it's clear it's regular ILBM?
[21:04:40] <BastyCDGS> and set is new DLTA, HAM6, etc. stuff?
[21:04:46] <BBB> no
[21:04:50] <BBB> DLTA means it's not a keyframe
[21:05:01] <BBB> so PKT_FLAG_KEY, which indicates it's a keyframe, should not be set
[21:05:02] <zorgy7> BBC: this function right? ff_mjpeg_build_huffman_codes
[21:05:06] * mru assumes that's a contraction of delta
[21:05:19] <BBB> right
[21:05:28] <zorgy7> :)
[21:05:29] <zorgy7> ty
[21:05:30] <BBB> zorgy7: I think, although I'm not very familiar with the code
[21:05:46] <wbs> mru: he needs to pass info about the format of each individual frame, though, since they can be in different formats, so extradata isn't useful for that
[21:05:52] <zorgy7> okay np, I was just making sure im on the right track
[21:06:00] <zorgy7> thanks for your advice :)
[21:06:01] <BastyCDGS> wbs, yes exactly that
[21:06:02] <mru> wbs: then don't put it in extradata
[21:06:20] <BBB> AVPacket->flags is good for indicating that the frame is a keyframe
[21:06:24] <mru> if current code is doing that, that's a bug
[21:06:29] <BBB> anything else, like masking, ehb or so needs to be done differently
[21:06:36] <BastyCDGS> no current code isn't doing that
[21:06:38] <BBB> we can look at all of that on a case-by-case basis
[21:06:49] <BastyCDGS> then let's start with masking
[21:07:24] <wbs> so, would it make sense to wrap this in CODEC_ID_IFF_ANIM, add a few bytes prelude to each packets data that explains what kind of packet it actually is?
[21:07:31] <BastyCDGS> masking differs that there's an extra plane per line which has to be skipped instead decoded
[21:07:31] <mru> what's the problem with dumping the frame header and frame data in the packet data?
[21:07:53] <mru> I don't see a need for a new codec id
[21:08:22] <mru> if mismatched lavf and lavc fail, so be it
[21:08:38] <BastyCDGS> so just don't care for backward compatibility?
[21:08:46] <mru> there's probably no more than one user of this anyway
[21:09:07] <wbs> true
[21:09:40] <BastyCDGS> well if we break compatibility here, then we can cut off ff_cmap_read_palette as well...
[21:09:49] <mru> if hypothetically inconveniencing one person reduces bloat and complexity on our part, I'd say it's worth it
[21:10:04] <wbs> BastyCDGS: no, that's a slightly bigger issue
[21:10:10] <mru> that could make linking fail
[21:10:16] <mru> whether or not it's used
[21:11:04] <BastyCDGS> then let's append format header stuff after the actual BODY data stuff with a length of additional data und the flags for ham, ehb, compression, etc.
[21:11:27] <wbs> in that case, how do you know how long the body data is?
[21:12:11] <BastyCDGS> s->planesize * avctx->height bytes
[21:12:24] <wbs> even if it is some delta data?
[21:12:58] <BastyCDGS> in that case we have a different pkt->flags
[21:13:06] <BastyCDGS> PKT_FLAG_KEY
[21:13:18] <wbs> yes, but do you know how long the body data is in that case, too?
[21:13:45] <BastyCDGS> when we have some delta data we can take the number of already decompressed bytes and compare that to above
[21:14:50] <BastyCDGS> well I see it's not a good idea
[21:15:07] <wbs> my point is, if it isn't crystal clear exactly how long the body data is and where to look for the extra flags, I'd prefer prepending them
[21:15:10] <BastyCDGS> only if you intend to always to decode the byterun stuff before then
[21:15:28] <BastyCDGS> maybe that's just hell easier
[21:15:31] <wbs> I wouldn't want a 5-if-statement block just to find out where to look for the flags
[21:15:40] <BastyCDGS> lol ;)
[21:16:00] <wbs> because that's the order you decode it anyway, first you check to see _what_ it is, then you proceed to actually decode the data when you know what format it is in
[21:16:01] <BastyCDGS> prepend starts with number of bytes to skip from this to find actual data
[21:16:28] <mru> is the header variable length?
[21:16:45] <BastyCDGS> if we don't define a fixed one, yes?
[21:16:56] <wbs> if you really need that flexibility, yes - if you just need a few bytes of flags/format numbers, a few bytes fixed header probably is simpler
[21:17:11] <BastyCDGS> but so we can add newer variables and the old versions still finding correct position
[21:17:36] <mru> why would we do that?
[21:17:44] <mru> the format is petrified and will never change
[21:17:47] <BastyCDGS> well prepending 16 bytes really sounds nice
[21:17:58] <mru> why 16?
[21:18:08] <BastyCDGS> should be enough for all times
[21:18:14] <mru> wrong answer
[21:19:10] <BastyCDGS> that's why I would prefer an actual size as uint32_t oder sth.
[21:19:20] <BastyCDGS> or sth. like that
[21:19:25] <mru> still wrong
[21:19:34] <mru> and we understand german :-)
[21:20:23] <BastyCDGS> but what do you think is the correct way then?
[21:20:50] <mru> make it exactly as long as it needs to be
[21:21:21] <BastyCDGS> and then if it has to be made longer someday all compatibility is broken again?
[21:21:43] <wbs> yes, but the whole format you're dealing with is ancient and doesn't get any updates
[21:21:53] <wbs> read through the specs, look for what you need to signal
[21:23:24] <BastyCDGS> I really can't tell right now, since there are other IFF formats, like IFF ACBM, IFF DEEP, IFF 16SV etc.
[21:23:36] <BastyCDGS> IFF TCM1
[21:23:56] <mru> then your first task is to find them all and check
[21:24:27] <BastyCDGS> please note that IFF format is as extensible as RIFF
[21:24:38] <BastyCDGS> in fact they're the same just that with big endian
[21:24:54] <BastyCDGS> so there also can be new IFF formats from PowerPC/ARM users etc.
[21:25:02] <mru> lol
[21:25:18] <mru> that's about as likely as Latin growing a seventh case
[21:25:40] <wbs> mru: that'd sure surprise you, wouldn't it? ;P
[21:26:33] <mru> yeah, I think it would
[21:26:46] <mru> the finns would probably handle it better
[21:26:52] <mru> having 17 or something already
[21:27:08] <wbs> yeah, finnish is a fantastic language ;P
[21:27:47] <wbs> luckily, it follows the rules of the language quite well (compared to swedish which is mostly exceptions all the way)... the downside is that the amount of rules is insane ;P
[21:27:52] <mru> spelling is consistent, got to give it that
[21:28:29] <mru> swedish isn't so bad with exceptions
[21:28:33] <BastyCDGS> well but what's the problem with having just a 4-byte long big endian length before actual packet data how long the prepended date is and that is
[21:28:38] <BastyCDGS> so we never run in any problem
[21:28:48] <mru> it's unnecessary complexity
[21:29:09] <wbs> ooh, 4 bytes length, in case we'd need more than 16 KB of format metadata :-)
[21:29:17] <wbs> eh, more than 64 KB
[21:29:23] <mru> people have managed to describe latin in great detail, and the romans didn't leave any PDFs behind
[21:29:40] <mru> now go read those docs
[21:31:32] <BastyCDGS> well what about storing the athere's at least one to be reverse engineered
[21:32:29] <BBB> where's the patch BastyCDGS ?
[21:32:32] <BBB> I'm waiting for review :)
[21:34:50] <BastyCDGS> btw, frame.data[0] is normal body data, frame.data[1] is palette if PAL8
[21:34:57] <BastyCDGS> what is frame.data[2] etc.?
[21:35:04] <BBB> planar YUV
[21:35:07] <BBB> data[0] is Y
[21:35:10] <BBB> data[1] is U
[21:35:12] <BBB> data[2] is V
[21:35:33] <mru> data[3] is W
[21:35:45] <BBB> SIGSEGV
[21:35:52] <BBB> or, rather
[21:35:55] * BBB throws an exception
[21:36:03] <BastyCDGS> then the IFF demuxer/decoder currently uses Y for actual BODY chunk, U for palette data
[21:36:04] <wbs> it can be A, in YUVA, too
[21:36:16] <BBB> yeah
[21:36:17] <mru> BBB: data[] has 4 elements
[21:36:37] <BBB> BastyCDGS: a demuxer has no access to a AVFrame
[21:36:43] <BastyCDGS> I want to use data[2] for storing the extradata stuff
[21:36:44] <BBB> it spits out AVPackets
[21:36:47] <BBB> completely differenty
[21:36:57] <BBB> video decoders decode into AVFrames
[21:37:11] <BastyCDGS> as I see the fif_read_packet sets data[0] to actual IFF BODY (graphics) data and data[1] to whole RGB palette bot doesn't do anything with data[2]
[21:38:09] <mru> eh?  AVPacket has only data, no data[]
[21:38:16] <BastyCDGS> sorry not iff_read_packet
[22:02:05] <wbs> bcoudurier: can you give an estimate on when you have time to review the movenc/rtphint stuff, btw? all the external stuff was ok'd by luca a and michael, so if you find something you don't like, I can try to fix it later, too
[22:02:22] <wbs> and just commit it now, if you don't have time to review it another time, that is
[22:21:39] <zorgy7> guys, is there a linked list in libavutil?
[22:22:17] <BBB> don't think so
[22:22:30] <BBB> if you want playutils, you could probably link against glib
[22:22:40] <BBB> it has GList/GSList etc.
[22:22:46] <Dark_Shikari> I'd just use an up-tree
[22:23:01] <Dark_Shikari> aka single-allocation linked data structure
[22:23:05] <Dark_Shikari> unless it has to be of unbounded size
[22:28:46] <BastyCDGS> BBB, one question...is AVPacket->data filled already when decode_init is called?
[22:29:10] <wbs> no, you don't have any AVPacket at that time yet
[22:29:17] <wbs> the function doesn't get any such parameter
[22:29:50] <BBB> AVPacket->data is unfilled when read_packet() is called, you allocate it with av_new_packet()
[22:30:03] <BBB> AVPacket->data is filled when you call decode_frame()
[22:30:13] <BBB> any other function does not take AVPacket as argument
[22:32:14] <BastyCDGS> BTW, I want to implement DPaint color cycling at a alter point, then I have to move palette to AVPacket->data, too
[22:32:18] <BastyCDGS> later
[22:49:48] <zorgy7> ok
[22:59:13] <zorgy7> is it okay to make my own heap structure in libavutil?
[22:59:42] <zorgy7> or should it be placed in mjpeg?
[23:07:36] <BBB> zorgy7: what kind of structure are you looking for?
[23:07:47] <BBB> if it belongs to the mjpeg codec, it should likely be in the mjpeg.c file
[23:08:34] <zorgy7> em
[23:08:49] <zorgy7> a min-heap for the huffman algorithm