[FFmpeg-devel-irc] IRC log for 2010-08-24

[irc at mansr.com]

[00:47:36] <CIA-11> ffmpeg: ramiro * r24894 /trunk/ffmpeg.c: indent
[02:11:05] <swatiardeshna> hi
[02:11:26] <swatiardeshna> how to install ffmpeg for iphone
[02:11:39] <BBB> please see topic
[02:12:01] <BBB> "Questions about using FFmpeg or developing with the libav* libraries should be asked in irc://irc.freenode.net/#ffmpeg."
[03:16:48] <xxthink> is the audio stream is mp2 layer-2
[03:16:53] <xxthink> if the audio stream is mp2 layer-2
[03:17:47] <xxthink> the difference of the pts and dts between two successive  audio frame should be the same
[03:17:51] <xxthink> is it right?
[04:11:57] <saintdev> kshishkov: ping
[04:31:52] <kshishkov> saintdev: what?
[04:33:09] <saintdev> kshishkov: pm
[05:07:55] <saintdev> well except for decimating anything above scalefactor 39, which as far as i can tell is intentional. i think long blocks are working
[05:08:54] <saintdev> so, on to short blocks
[05:11:07] <saintdev> oh, except for perceptual entropy.
[05:14:55] <saintdev> not sure yet how good it is, but it works :P
[05:52:31] <_av500_> xxthink: yes, samples per frame are constant
[06:00:55] <pJok> god morgon kshishkov
[07:28:21] <funman> any reason why AVCodec->encode() doesn't take a const void* for the input samples?
[07:35:12] <Tjoppen> funman: which function do you mean?
[07:35:47] <kshishkov> funman: instead of what?
[07:35:57] <funman> void *data
[07:36:12] <funman> Tjoppen: int (*encode)(AVCodecContext *, uint8_t *buf, int buf_size, void *data);
[07:37:22] <kshishkov> yes, const qualifier won't hurt, feel free to send a patch
[07:37:30] <funman> well i see that mpeg video encoder for example modify the picture
[07:37:46] <kshishkov> oops
[07:37:59] <kshishkov> then you know the awnser ;)
[07:38:06] <funman> perhaps that's a bug though
[07:39:16] <Tjoppen> I ran into a case where I thought the same, but the void* could be used as an opaque pointer to some non-const state
[07:39:38] <Tjoppen> not that exact function though. audio resampler IIRC
[07:42:46] <Tjoppen> well, load_input_picture() in mpegvideo_enc.c modifies display_picture_number
[07:45:25] <funman> r3833 -> s/pic/pic_arg/ is a typo maybe
[07:49:09] <kshishkov> that could be needed for picture reordering
[07:50:12] <funman> if some reordering must be done, i'd expect it to affect the output pictures only
[07:51:17] <kshishkov> ask the author, is anybody is able to make out something from that, he's the only person
[07:51:37] <funman> i should've asked about ->encode() in my reply
[07:52:19] <funman> const polishing isn't very exciting anyway
[07:52:37] <funman> much more adrenaline when playing with lego stuff!
[07:52:56] <saintdev> lego \o/
[08:38:50] <CIA-11> ffmpeg: stefano * r24895 /trunk/libavfilter/avfilter.c: (log message trimmed)
[08:38:50] <CIA-11> ffmpeg: Make avfilter_start_frame() invoke avfilter_get_video_buffer() on the
[08:38:50] <CIA-11> ffmpeg: link rather than avfilter_default_get_video_buffer().
[08:38:50] <CIA-11> ffmpeg: This is required as the buffer requested may be greater than the
[08:38:50] <CIA-11> ffmpeg: buffer allocated locally by avfilter_default_get_video_buffer(), for
[08:38:51] <CIA-11> ffmpeg: example if in filterchain there is a pad filter (like in "fifo,pad").
[08:38:52] <CIA-11> ffmpeg: In that case the pad filter will try to write beyond the data of the
[08:38:52] <CIA-11> ffmpeg: stefano * r24896 /trunk/ (5 files in 2 dirs): Add fifo filter.
[12:02:47] <kierank> where's a good place to visit in sweden?
[12:03:15] <mru> stockholm
[12:03:35] <thresh> border line when leaving it
[12:03:36] * thresh hides
[12:04:49] <thresh> mru: what does 'Hättan' mean?
[12:04:56] <thresh> (as in trollhättan)
[12:05:54] <mru> the hat
[12:06:00] <mru> so it's Troll Hat
[12:06:59] <thresh> awesome
[12:09:49] <kierank> hmm stockholm looks nice
[12:10:27] <spaam> kierank: norrland is nice :)
[12:10:31] <av500> doesnt it make people have a "syndrome"?
[12:10:49] <kshishkov> mru: it actually can mean "The Magic(ian) Hat", can't it?
[12:11:13] <mru> magician is trollkarl
[12:11:16] <kshishkov> spaam: I should check that
[12:11:39] <mru> which is derived from the verb "trolla"
[12:11:46] <mru> meaning "to perform magic"
[12:11:54] <mru> thus called because trolls do it
[12:12:04] <kierank> spaam: what is norrland?
[12:12:12] <spaam> kierank: the north part of sweden :)
[12:12:26] <av500> and south part does not exist :)
[12:12:26] <spaam> like the half of the country :)
[12:12:34] <kshishkov> mru: you should remind that to people often
[12:12:51] <kierank> spaam: can i crash with you ;)
[12:12:51] <kshishkov> av500: you can ask imaginary pJok about it
[12:13:13] <kshishkov> spaam: and remember, it's only half of pre-1809 Norrland
[12:13:35] <spaam> kierank: i live in the south part of sweden  =/
[12:13:43] <kierank> maybe i should try airbnb
[12:14:30] <mru> kierank: merbzt should have a spare room if superdump has moved out
[12:15:01] <superdump> as of last weekend, the room is probably occupied again
[12:15:07] <superdump> but speak to merbanan :)
[12:15:36] <mru> oh
[12:15:58] <mru> superdump: so you have moved out?
[12:16:09] <superdump> yup
[12:16:17] <mru> where do you live now?
[12:16:30] <superdump> with my g/f
[12:16:53] <mru> and where's that? just curious...
[12:17:19] <superdump> enskede gård
[12:17:36] <kshishkov> weren't you living there anyway?
[12:17:39] <superdump> just south of globen
[12:18:05] <superdump> well, it was more that i was staying with her than actually living here
[12:18:51] <superdump> though when i was 'living with ben' i spent basically all my time here so there wasn't much point
[12:24:38] * kshishkov should book an hotel
[12:27:26] <spaam> kshishkov: going to .se ? :)
[12:27:34] <kshishkov> spaam: javisst
[12:27:48] <kierank> kshishkov: when are you going?
[12:27:56] <kshishkov> kierank: this weekend
[12:28:22] <spaam> kshishkov: stockholm eller ?
[12:28:29] <thresh> на истоrическую rодину?
[12:29:35] <kshishkov> thresh: нет, просто на родину. А почему ви спrашиваете?
[12:29:46] <thresh> kshishkov: таки завидуем.
[12:30:13] <kshishkov> spaam: stockholm ock ! I usually try to visit several places though Stockholm usually takes lion share of time
[12:30:41] <mru> "och", not "ock"
[12:31:42] <kshishkov> mru: thanks, I'll try to remember it for longer time
[12:32:14] <mru> but it's "också" just to be confusing
[12:32:31] <kshishkov> yes
[12:32:40] <kshishkov> still better than Danish "og"
[12:33:19] <mru> pronounced "öuugh"
[12:33:31] <mru> like most danish words
[12:34:12] * kshishkov finds Danish to be less pleasant sounding than other Nordic languages
[12:36:00] <kshishkov> and I must admit that Norwegian language seems to have better writing system than Swedish
[12:36:24] <mru> not really
[12:36:40] <mru> they write kk instead of ck
[12:37:05] <mru> otherwise it's mostly the same
[12:37:40] <pJok> god sorensen squeeze is useless
[12:37:46] <kshishkov> look at words ending with "-tion"
[12:37:49] <spaam> finnish is harder to understand then dansih ;S
[12:38:00] <mru> finnish spelling is highly consistent
[12:38:13] <mru> kshishkov: .no spells those -sjon
[12:38:17] <kshishkov> yes, otherwise it would be real hell
[12:38:26] * pJok prods kshishkov to make ffmpeg encode VP6
[12:38:29] <kshishkov> mru: and it sounds like that too
[12:38:49] <mru> in swedish, -tion and -sjon sound the same
[12:39:03] <pJok> danish is horrible
[12:39:15] <kshishkov> pJok: no thanks, I'm against it
[12:39:37] <mru> obligatory: http://www.youtube.com/watch?v=s-mOy8VUEBk
[12:39:59] <kshishkov> mru: yes, but Norwegian writting seems to be a bit closer to pronunciation
[12:40:00] <pJok> kshishkov, squeeze does not believe in 23.976 as framerate and its mp3 encoder does not believe in 64kbit stereo
[12:40:30] <av500> pJok: so why use it?
[12:40:32] <kshishkov> pJok: well, depends on bitrate for audio
[12:40:43] <mru> av500: why use danish?
[12:40:50] <av500> that too
[12:40:58] <mru> what is the bitrate of danish?
[12:41:13] <av500> that sorenson sqeal
[12:41:17] <av500> +u
[12:41:19] <pJok> av500, i just got specs on something i need to deliver and they say they want flv vp6 with framerate 23.976 or 29.97 with 64kbit stereo mp3 audio
[12:41:29] <pJok> why i have no idea...
[12:41:43] <kierank> pJok: encode in squeeze and remux
[12:42:01] <kshishkov> don't forget to resample audio to 8kHz
[12:42:06] <av500> cat /dev/random > vp6_23.976_mp3_64k.flv
[12:42:28] <pJok> kierank, that was my first plan... but if squeeze doesn't support decimals in framerate, it doesn't matter :P
[12:42:38] <av500> encode at 23976 fps
[12:42:45] <av500> then slow down 100x
[12:42:57] <kierank> encode it 24fps
[12:43:00] <kierank> then slow it down
[12:43:01] <pJok> or i could just take a hammer and tell those who wants those specs to shove it...
[12:43:11] <av500> use shovel
[12:43:13] <pJok> but its typical with my job
[12:43:20] <pJok> i get specs 5 min before i have to deliver something
[12:43:28] <pJok> and im just the IT guy...
[12:43:33] <av500> at least you get specs!
[12:43:43] <kshishkov> pJok: at least you can be proud of your mountains.
[12:43:46] <av500> I get told, I am already late before I start
[12:43:46] <pJok> av500, it would be easier if i didn't get specs...
[12:43:58] <mru> pJok: why don't you show them what kind of power the IT guy can wield?
[12:45:03] <pJok> mru, i hate trying to convience people who think they know that what they see is different from what i see... already had a battle with a broadcast company about the specs they gave me... but at least they dont complain about the files i send them, even though they are out of spec according to what they gave me
[12:45:38] <pJok> mru, that i already did... im leaving two hours early today for a job interview at another company :P
[12:45:47] <mru> :-)
[12:46:06] <pJok> they don't know yet though
[12:46:15] <pJok> and till i've signed a contract, they wont know either
[12:46:32] <kshishkov> I imagine that Lego block carver may be more respectable and better paid profession
[12:47:04] <av500> dont forget lego block painter
[12:47:16] <av500> or lego adpcm encoder
[12:48:09] <mru> I can haz deblocking filter for lego?
[12:48:28] <kshishkov> of course!
[12:48:45] <pJok> mru, http://www.youtube.com/watch?v=4qsWFFuYZYI
[12:48:46] <kshishkov> ask any digital placeboist
[12:50:17] <mru> pJok: nice
[12:51:38] <pJok> ah well, time to call it a day and get to that interview
[12:51:56] <pJok> then fix what ever encoder that will do what i need with VP6 later
[12:51:59] <kshishkov> lycka till
[12:53:04] <mru> kshishkov: http://www.youtube.com/watch?v=hWTFG3J1CP8
[12:57:26] <kshishkov> mru: hmm
[12:58:31] <thresh> awesome
[13:00:47] <spaam> kshishkov: do you own a .su domain ? :)
[13:02:53] <kshishkov> spaam: I don't want to own any domains
[13:03:29] <av500> in .ua, domains own you....
[13:03:38] <spaam> haha
[13:04:00] <thresh> .su is stupidly expensive
[13:04:20] <av500> wouldnt that be .se?
[13:04:42] <thresh> two jokes in a minute, nicely done!
[13:04:59] <mru> if you want your own TLD, what's cheaper, the registration fee for a custom one, or buying a pacific island?
[13:05:05] <kshishkov> he's our biggest joker after all
[13:05:25] <kshishkov> buying an island of course!
[13:05:30] <mru> or buying an army to invade an island
[13:05:38] <kshishkov> good place to run your tracker as well
[13:15:14] <av500> kshishkov: what good is a tracker that sits on an island that has 1 fiber if lucky
[13:15:31] <kshishkov> av500: or 1 sat
[13:15:35] <av500> yep
[13:15:48] <mru> av500: choose the island carefully: http://www.cablemap.info/
[13:17:00] <av500> ok, not cyprus
[13:17:48] <thresh> huh, ibiza got no internets?
[13:18:21] <mru> probably only smaller cables
[13:19:14] <kshishkov> bootlaces
[13:19:31] <mru> besides, people there are too drunk to be on the internets anyway
[13:19:37] <thresh> indeed
[13:20:55] <av500> ok, so guam
[13:21:00] <thresh> sumatra looks nice as well
[13:21:03] <av500> will be hard to take by force though...
[13:24:03] <kshishkov> guam is harder
[13:24:14] <kshishkov> if they still have that US military base there
[13:24:30] <thresh> maybe if I tell Japan I'll give them Kuril islands back, they will attack US?
[13:24:31] <mru> unless you use said base to take it over
[13:25:31] <kshishkov> thresh: they can only self-defence themselves ;) so unlikely. But thanks for the islands
[13:25:57] <thresh> kshishkov: choose whatever you like
[13:39:36] <av500> how do I create a many frames video from one PNG?
[13:41:24] <Tjoppen> something like ffmpeg -r 0.1 -i frame.png -r 25 output.avi ?
[13:41:50] <mru> what a nasty way
[13:42:01] <Tjoppen> I rarely use the CLI, so.. :p
[13:43:20] <CIA-11> ffmpeg: mru * r24897 /trunk/libavformat/asfcrypt.c:
[13:43:20] <CIA-11> ffmpeg: asfcrypt: fix unaligned accesses with armcc
[13:43:20] <CIA-11> ffmpeg: Compilers may assume a pointer has natural alignment, even if it was
[13:43:20] <CIA-11> ffmpeg: assigned from a pointer type with weaker alignment requirements. It
[13:43:20] <CIA-11> ffmpeg: is thus not safe to assign a possibly unaligned value to a pointer,
[13:43:21] <CIA-11> ffmpeg: regardless of how it is subsequently dereferenced.
[13:51:59] <merbzt> how do I memcpy a struct with pointers in them and still abide alignment and other stuff ?
[13:53:33] <mru> what do you mean?
[13:54:50] <av500> Tjoppen: does not create several frames
[13:55:27] <Tjoppen> -loop-input (or whatever it's called)?
[13:55:29] <Tjoppen> and -t
[13:55:55] <av500> thx
[13:56:01] <kshishkov> merbzt: just memcopy
[13:56:59] <merbzt> kshishkov: are pointers allowed to be on random addresses on all platforms ?
[13:57:18] <kshishkov> nope
[13:57:21] <mru> merbzt: what are you trying to do?
[13:57:40] <astrange> pointers themselves are aligned to pointer size, their values are aligned to something else
[13:57:41] <kshishkov> mebzt: but compiler should know that and allocate structure object aligned
[13:57:43] <astrange> or not
[13:58:11] <merbzt> typedef struct {
[13:58:11] <merbzt>     char*   name;
[13:58:11] <merbzt>     void*   value;
[13:58:11] <merbzt>     int     type;
[13:58:11] <merbzt> } nvt;
[13:58:27] <merbzt> I have lots of structs with that
[13:58:30] <mru> yes, so?
[13:59:02] <merbzt> I wanna copy them a populate the copy's with data
[13:59:38] <mru> you sound like an indian student doing his homework
[13:59:49] <merbzt> yeah I know :)
[14:00:00] <kshishkov> if you use nvt a, b;  a = b; (or memcpy(&a, &b, sizeof(a))) it should work without any side effects
[14:00:39] <merbzt> I need to malloc a and b
[14:01:15] <av500> malloc outputs at least 8 byte aligned, no?
[14:01:20] <merbzt> or that was my original plan
[14:01:28] <kshishkov> av500: not on DOS, I think
[14:01:36] <mru> malloc returns memory suitably aligned for any machine type
[14:01:53] <kshishkov> merbzt: go ahead and don't worry unless you hit a VAX
[14:01:57] <merbzt> :)
[14:02:08] <av500> kshishkov: VAX runs DOS?
[14:02:43] <kshishkov> av500: nope, it was too advanced for that
[14:03:28] <CIA-11> ffmpeg: bindhammer * r24898 /trunk/ (5 files in 2 dirs):
[14:03:28] <CIA-11> ffmpeg: fixed some return values and deprecated CODEC_TYPE_VIDEO.
[14:03:28] <CIA-11> ffmpeg: dithering (faster) along a linear gradient now.
[14:03:49] <merbzt> mru: that's what I thought also, but as always I'm not 100% sure
[14:04:10] <mru> the C spec would have told you the answer
[14:04:56] <merbzt> it just did
[14:05:19] <merbzt> mr C spec
[14:08:47] * kshishkov wonders why there're no attempts on FFcc yet
[14:17:48] <kierank> imagine the bikeshedding for FFcc
[14:26:05] <kshishkov> kierank: that would be enough bikesheds for whole Denmark, Netherlands and China combined
[14:26:07] <BBB> wbs: I intend to review your g222 patch later today, poke me if I forget
[14:37:53] <twice11> merbzt: nvt *a, *b; a = malloc(sizeof a); b=malloc(sizeof b); /* init a */; *b=*
[14:37:59] <twice11> *b=*a;
[14:38:02] <twice11> will work.
[14:38:06] <twice11> everywhere.
[14:38:16] <kshishkov> sizeof(*a) though
[14:40:17] <twice11> kshishkov: Well spotted.
[14:56:30] <BBB> hi spyfeng
[14:56:37] <BBB> how's starcraft2 coming along
[14:56:52] <wbs> BBB: oh, thanks :-) I'd guess michael wants to have a say about it, too, since he was reviewing it last time around, but he seems a bit busy lately
[14:57:14] <BBB> he complained he has like 150 unanswered (reviewable) emails lying around
[14:57:24] <wbs> yeah, I saw that
[14:57:26] <BBB> poor guy, avfilter and so on are terribly complex and take ages
[14:57:36] <wbs> yeah
[14:57:46] <BBB> I'll help with codec review where relevant ;)
[14:58:19] <mru> he's not improving his situation by writing code so convoluted that nobody else will go near it
[14:59:34] <BBB> that problem will not solve itself other than us helping to fix it, I'm affraid
[14:59:42] <kshishkov> mru: you can start easy with reviewing swscaler first ;)
[14:59:44] <BBB> his mind might be wired so weirdly that he thinks the code makes sense
[14:59:45] <BBB> or so
[15:00:14] <mru> he refuses any such help
[15:00:30] <mru> didn't you seem him denying any problems with libswscale yesterday?
[15:00:48] <BBB> he'll accept patches that improve it even if there is no "problem"
[15:01:19] <mru> swscale is one of those things that can't be improved incrementally
[15:01:26] <mru> there's nothing sound to base a patch on
[15:02:30] <BBB> that's a little funny :)
[15:02:37] <kshishkov> well, some parts are not that bad. For example, I was able to figure out how YUV2RGB works
[15:02:48] <BBB> I heard that very exact same sentence with s/swscale/ffmpeg/ about 5 years ago from fellow gstreamer developers
[15:02:59] <mru> kshishkov: what kind of mind-altering drugs did you take when doing that?
[15:03:24] <mru> BBB: it is true for large parts of it
[15:03:28] <mru> e.g. mpegvideo*
[15:04:30] <kshishkov> mru: none, I shun drugs. Digging through heaps of code with questionable quality helps though.
[15:06:54] <kshishkov> I'd say that main tangled mess is hidden in swscale_template.h and swscale.c
[15:07:04] <kshishkov> I'm afraid to touch them
[15:07:10] <mru> what else is there to libswscale?
[15:07:23] <mru> those two files are like 90% of it
[15:09:42] <CIA-11> ffmpeg: mru * r24899 /trunk/libavformat/utils.c: avformat: free decryption key in av_close_input_stream()
[15:10:37] <kshishkov> only a half actually
[15:10:54] <kshishkov> rgb2rgb stuff is heavy too
[15:13:05] <CIA-11> ffmpeg: stefano * r24900 /trunk/libavfilter/ (avfilter.c avfilter.h internal.h): Implement ff_get_ref_perms_string() and use it for tracing.
[15:22:19] <CIA-11> ffmpeg: bindhammer * r24901 /trunk/libavcodec/ (a64colors.h a64enc.h a64tables.h a64multienc.c): added interlacing option and compression option for colorram (lut)
[15:41:50] <CIA-11> ffmpeg: mru * r24902 /trunk/libavcodec/msmpeg4.c:
[15:41:50] <CIA-11> ffmpeg: msmpeg4v1: fix undefined behaviour in msmpeg4_decode_picture_header()
[15:41:50] <CIA-11> ffmpeg: Because the order of evaluation of subexpressions is undefined, two
[15:41:50] <CIA-11> ffmpeg: get_bits() calls may not be part of the same expression. In this
[15:41:50] <CIA-11> ffmpeg: specific case, using get_bits_long() is simpler.
[15:41:51] <CIA-11> ffmpeg: This fixes msmpeg4v1 decoding with armcc.
[15:42:55] <mru> there, that should give us two more green on fate
[15:45:04] <superdump> merbanan: can you check the ffmpeg-soc moderation list to see if marcelo's mail(s) got blocked please?
[15:45:22] <peloverde> mru: there are other places where that maltrick is used
[15:45:47] <mru> do you have a good way to find them?
[15:46:44] <peloverde> grep get_bits.*get_bits is not perfect but it's somewhere to start
[15:49:02] <CIA-11> ffmpeg: stefano * r24903 /trunk/ffmpeg.c:
[15:49:03] <CIA-11> ffmpeg: Make configure_filters() return a meaningful error code rather than
[15:49:03] <CIA-11> ffmpeg: always -1.
[15:49:03] <CIA-11> ffmpeg: stefano * r24904 /trunk/ffmpeg.c:
[15:49:03] <CIA-11> ffmpeg: Cosmetics: rename out_video_filter to output_video_filter, for
[15:49:03] <CIA-11> ffmpeg: consistency with input_video_filter.
[15:49:04] <CIA-11> ffmpeg: stefano * r24905 /trunk/ffmpeg.c: Factorize opt_new_{audio,video,subtitle} definitions.
[15:49:31] <peloverde> I can go through and fix the ones I found
[15:50:14] <kierank> 15 years since: http://www.youtube.com/watch?v=5VPFKnBYOSI
[15:50:49] <kshishkov> never forget, never forgive
[15:50:52] <peloverde> I remember buying that on launch day
[15:51:08] <kierank> I remember watching the weezer video
[15:51:10] <kierank> and playing hover
[15:51:56] * kshishkov got his first computer in '97
[15:52:32] <mru> peloverde: if you don't mind
[15:53:13] <_skal_paris_> BBB: http://pastebin.org/760168
[15:54:35] <Dark_Shikari> _skal_: why
[15:56:25] <BBB> is that correct?
[15:56:52] <Dark_Shikari> he's just inlining get_sint
[15:56:57] <Dark_Shikari> which I don't get
[15:57:26] <_skal_> The spec^Wlibvpx says that, if the first bit is zero, you shouldn't touch the value. Not reset it to 0.
[15:57:59] <kshishkov> _skal_: we know that VP8 spec == libvpx
[15:58:21] <Dark_Shikari> _skal_: shouldn't get_sint be changed then?
[15:58:34] <_skal_> Dark: i tried that, but it's cumbersome
[15:58:49] <Dark_Shikari> Er...
[15:58:51] <Dark_Shikari> why do only those change?
[15:58:54] <Dark_Shikari> what about the segment info?
[15:58:55] <_skal_> you have to pass 'int8_t* value' pointer
[15:58:57] <BBB> as per kshishkov
[15:59:01] <BBB> please check against libvpx
[15:59:09] <_skal_> and i realized it was only meaningful in 2 places
[15:59:14] <Dark_Shikari> and what about quants
[15:59:18] <_skal_> the other two, the default value *is* 0
[15:59:19] <BBB> and provide a sample that shows the bug
[15:59:25] <BBB> otherwise we can't put it in the regtest
[15:59:31] <_skal_> quant = 0 for default too
[15:59:48] <Dark_Shikari> _skal_: then do it like this
[15:59:56] <Dark_Shikari> int x = getsint();
[15:59:57] <Dark_Shikari> if(x)
[15:59:59] <_skal_> BBB: i've pinged the relevant people to have them generate a proper test-vector
[16:00:03] <Dark_Shikari> ref[i] = x
[16:00:10] <_skal_> Dark: no
[16:00:21] <_skal_> Dark: because you *can* code zero with a leading non-zero bit
[16:00:27] <Dark_Shikari> huh?
[16:00:27] <_skal_> yeah, i know i know
[16:00:32] <_skal_> sub-optimal
[16:00:36] <Dark_Shikari> no no, you CAN, but does libvpx?
[16:00:42] <Dark_Shikari> if it doesn't, we don't care
[16:00:49] <_skal_> some encoder can
[16:00:57] <Dark_Shikari> No, it can't
[16:01:00] <Dark_Shikari> libvpx is the spec
[16:01:05] <_skal_> for decoding
[16:01:17] <Dark_Shikari> and?  its behavior for invalid bitstreams does not have to be replicated
[16:01:33] <Dark_Shikari> we don't replicate its behavior for invalid EOBs either
[16:01:50] <_skal_> another encoder can code zero using: 1 + 0000000 for get_sint(.., 6)
[16:01:56] <Dark_Shikari> That should be invalid
[16:01:58] <_skal_> or 1 + 0000000 for that matter
[16:02:03] <_skal_> or 0 simply, too
[16:02:03] <Dark_Shikari> libvpx doesn't do it, so fix the spec to say so
[16:02:23] <Dark_Shikari> If libvpx does not do X, and X is allowed by the decoder, you can define X to be invalid without breaking any existing software.
[16:02:45] <Dark_Shikari> a good example is that bug with reference frame swapping.
[16:02:47] <_skal_> Dark: libvpx *do* X
[16:02:58] <Dark_Shikari> _skal_: libvpx writes "1 + 000000"?
[16:03:03] <_skal_> libvpx does: if (get_bit()) { do something } else { do nothing }
[16:03:08] <Dark_Shikari> NO, I meant the encoder.
[16:03:11] <Dark_Shikari> Again, libvpx does NOT WRITE that
[16:03:19] <_skal_> we do: if (get_bit()) { do_something } else { do something }
[16:03:26] <Dark_Shikari> that is reading code, not writing code
[16:03:29] <Dark_Shikari> stop being intentionally thick
[16:03:31] <Dark_Shikari> the encoder does not do X
[16:03:38] <Dark_Shikari> therefore, X can be declared invalid without breaking anything
[16:03:49] <_skal_> come on, libvpx is not the only encoder
[16:03:53] <Dark_Shikari> Yes it is
[16:03:57] <_skal_> no it isn't
[16:04:04] <Dark_Shikari> Now, in a month or two, this might change
[16:04:09] <Dark_Shikari> when we remove libvpx from vlc and ffmpeg
[16:04:20] <Dark_Shikari> but for now, it's the only one
[16:04:31] <BBB> Dark_Shikari: so... the last argument to cglobal in yasm, for mmx functions
[16:04:36] <BBB> does it do anything?
[16:04:52] <Dark_Shikari> BBB: I think so.
[16:04:59] <Dark_Shikari> I think it still does the same thing
[16:05:03] <BBB> ok
[16:05:03] <Dark_Shikari> so you have to either not set it, or set it to 0
[16:05:14] <Dark_Shikari> reason: you can have INIT_MMX but still explicitly use some xmmregs.
[16:05:30] <BBB> right...
[16:05:52] <BBB> <=8 it does nothing right?
[16:06:02] <pengvado> <=6
[16:06:12] <_skal_> Dark: so, i'll have to supply an official test bitstream for you to change your mind?
[16:06:27] <_skal_> something that libvpx decodes but not ffvp8?
[16:06:34] <Dark_Shikari> No
[16:06:39] <pengvado> test bitsrreams don't count either, except insofar as they'd be evidence for the existence of an encoder that does it
[16:07:10] <Dark_Shikari> _skal_: we are at a point where there are still no encoders that do certain stupid things
[16:07:18] <Dark_Shikari> therefore, we can safely declare those things to be wrong
[16:07:30] <_skal_> Dark: why 'stupid'
[16:07:31] <_skal_> ?
[16:07:33] <Dark_Shikari> You apparently want to squander this chance
[16:07:33] <_skal_> i don't get it
[16:08:03] <_skal_> the algo is: if leading bit = 0, leave the value untouched, else update it with the following 6 bits + sign
[16:08:03] <Dark_Shikari> In the case of residual coding, you agreed with me.
[16:08:08] <_skal_> where is that stupid?
[16:08:26] <Dark_Shikari> because it adds pointless redundancy to the bitstream
[16:08:33] <_skal_> ffvp8 does: if leading is 0, reset to 0, else read 6 bits + sign
[16:08:41] <Dark_Shikari> yes, so change ffvp8 to do
[16:08:50] <_skal_> that was my patch, mind you
[16:08:59] <Dark_Shikari> oh, actually, setting to zero is valid
[16:09:07] <Dark_Shikari> ok, in that case, patch accepted
[16:09:07] <_skal_> sometimes, but not always
[16:09:09] <Dark_Shikari> wait
[16:09:11] <Dark_Shikari> why not always?
[16:09:20] <_skal_> some default values *are* 0
[16:09:28] <Dark_Shikari> what do you mean by default?
[16:09:29] <_skal_> and set just before callign get_sint()
[16:09:29] <Dark_Shikari> you said
[16:09:36] <Dark_Shikari> you just said that it leaves the existing one at zero
[16:09:40] <Dark_Shikari> er, it leaves the existing one
[16:09:42] <Dark_Shikari> if zero is set
[16:09:46] <Dark_Shikari> by definition then, there isn't a "default"
[16:09:49] <_skal_> let me find the exact line
[16:10:06] <Dark_Shikari> now I'm confused
[16:10:20] <Dark_Shikari> you're giving me contradictory information about the coding method for these syntax elements.
[16:11:20] <Dark_Shikari> if 10000000 is a value that cannot be represented any other way, patch accepted
[16:11:25] <Dark_Shikari> (a valid value)
[16:11:34] <BBB> I might need some thinking help
[16:11:35] <CIA-11> ffmpeg: alexc * r24906 /trunk/libavcodec/ (qdm2.c mjpegdec.c):
[16:11:35] <CIA-11> ffmpeg: Fix undefined expressions that use multiple calls to get_bits().
[16:11:35] <CIA-11> ffmpeg: Because the order of evaluation of subexpressions is undefined, two
[16:11:35] <CIA-11> ffmpeg: get_bits() calls may not be part of the same expression.
[16:11:35] <CIA-11> ffmpeg: See also r24902.
[16:11:41] <Dark_Shikari> BBB: writing the rac?
[16:11:44] <BBB> that bug on win64 with test sample 3 and 7
[16:11:52] <BBB> no that's waiting for me to fix vp8 on win64
[16:12:00] <BBB> the bug is caused by two functions in vp8 simd
[16:12:07] <BBB> if I disable either one half the bug goes awy
[16:12:13] <BBB> disabling both makes it go away 100%
[16:12:21] <BBB> the buggy functions are ... bilin4/16_mmxext
[16:12:26] <BBB> I don't understand how that's possible
[16:12:39] <_skal_> Dark: this 1000000 was an unfortunate digression of mine
[16:12:42] <BBB> how do mm registers screw up a double?
[16:13:04] <Dark_Shikari> someone didn't run emms?
[16:13:16] <BBB> what is emms?
[16:13:29] <BBB> you wrote this asm, not me :-p
[16:14:35] <Dark_Shikari> why are you talking about doubles?
[16:14:43] <Dark_Shikari> where does vp8 use doubles?
[16:14:57] <peloverde> http://www.intel.com/software/products/compilers/clin/docs/ug_cpp/comm1010.htm
[16:15:16] <mru> avcodec_decode_video2() does emms_c()
[16:16:20] <_skal_> Dark: back to topic: for delta_q's the default value is 0. So calling get_sint() is ok. For segmentation.base_quant[] and filter_level[] the default is also 0, and libvpx does a memset(..,0,...) before doing the get_sint(). We don't, but rely on get_sint() to return 0 when leading bit is 0. Last use of get_sint() is for lf_delta's, but this one was erroneous because there's no default in this case, but we just have to leave the values unto
[16:16:23] <_skal_> pfff.... that was long
[16:16:34] <_skal_> need a coffee
[16:16:55] <Dark_Shikari> patch ok as long as there is a commenbt explaining why we're not using sint
[16:17:01] <_skal_> k
[16:21:45] <BBB> Dark_Shikari: a double check in ffmpeg.c is screwed up by these two functions in vp8
[16:21:51] <BBB> if I disable these two, the bug goes away
[16:21:58] <BBB> disable one of them, the bug goes half-away
[16:22:11] <BBB> disable anything else, all other simd, the bug is still there
[16:22:32] <BBB> I'm wondering how a mmxext function could screw up a double
[16:22:50] <Dark_Shikari> because emms isn't being called afterwards
[16:22:52] <Dark_Shikari> because the stack was corrupted
[16:24:57] <BBB> hm... that's possible I guess
[16:25:05] * BBB goes check stack writing variables
[16:26:55] <Dark_Shikari> BBB: try cutting out parts of the function until it works
[16:26:59] <Dark_Shikari> i.e. let it generate invalid output
[16:27:05] <Dark_Shikari> but cut out parts until the double check succeeds
[16:27:13] <BBB> I think I found it
[16:27:17] <BBB> this is rather depressing
[16:28:16] * mru also found something depressing
[16:28:23] <mru> avfilter this time
[16:29:21] <Dark_Shikari> BBB: what was it?
[16:29:29] <Dark_Shikari> I want to know what stupid shit I did
[16:31:46] <kshishkov> mru: next thing you find even more depressing should be audio resampler then
[16:32:38] <mru> there's a function doing a huge malloc with no way of reporting an error
[16:32:45] <mru> and of course the malloc isn't checked
[16:32:59] <mru> error checking in lavfi is abysmal
[16:33:03] <mru> and that's being polite
[16:33:04] <BBB> Dark_Shikari: it was me forgetting to svn update and tracing the same bug I already fixed yesterday (sub r4 instead of sub r4d for an int height)
[16:33:14] <BBB> the real bug is still there, I'm re-doing the same shit now
[16:33:17] * BBB hits himself
[16:33:23] <twice11> audio resampler? Let's go straight into lavseq then...
[16:34:35] <BBB> this one appears in sse2 code, it seems... well at least it's a new bug then
[16:38:43] <peloverde> Is there a way to turn fate "inside out" and look at it per test instead of per-machine?
[16:39:14] <mru> not yet at least
[16:42:28] <BBB> ah got it, finally
[16:52:32] <mru> BBB: well?
[16:52:37] <BBB> committed
[16:52:49] <BBB> 24908 should have working VP8 on Win64
[16:52:55] <BBB> let's see if fate agrees
[16:53:01] <BBB> I can look at the others later or so
[16:53:11] <CIA-11> ffmpeg: mru * r24907 /trunk/configure: configure: fix typo in test deps
[16:53:12] <CIA-11> ffmpeg: rbultje * r24908 /trunk/libavcodec/x86/vp8dsp.asm:
[16:53:12] <CIA-11> ffmpeg: Clobber xmm registers in simple loopfilter. Should fix the last two VP8-related
[16:53:12] <CIA-11> ffmpeg: fate failures on Win64.
[16:53:31] <mru> that's a bad commit message
[16:53:40] <mru> the registers were being clobbered all along
[16:53:47] <mru> you just weren't telling anyone
[16:54:16] <mru> this reminds me of people who believe "assert" to be synonymous with "fail"
[16:54:38] <BBB> uh
[16:54:39] <BBB> right
[16:54:43] <BBB> "mark for clobber"
[16:54:45] <BBB> let me fix that
[16:55:36] <BBB> fixed
[16:56:03] <BBB> anyway
[16:56:14] <BBB> I can probably look at other win64-related bugs as long as it's in yasm-code
[16:56:23] <peloverde> all this win64 work makes me look forward to VLC for win64
[16:56:26] <BBB> I will not touch inline asm with a 20-foot pole
[16:56:54] <mru> inline asm is where most of the problems are
[16:57:00] <mru> missing clobber marks mostly
[16:57:08] <BBB> dontcarewontfix
[16:57:20] <BBB> I can rewrite it into yasm but apparently michael doesn't like that or so
[16:57:24] <mru> rewrite in yasm is the proper solution
[16:57:26] <BBB> or was the rewrite bad?
[16:57:29] <BBB> (eli's)
[16:57:50] <mru> the one today?
[16:58:12] <mru> that added a function call
[16:58:17] <BBB> oh
[16:58:21] <mru> making it 2 cycles slowr in theory?
[16:58:23] <mru> -?
[16:58:28] <mru> +e
[16:58:29] <BBB> so if I "manually" inline it by embedding the function inside it's ok?
[16:58:40] <mru> uh?
[16:59:27] <BBB> int func(a, b, c){func2(a, b, c, d, e);} eli rewrote func2, if I rewrite func with func2 inlined in it, it's ok?
[16:59:45] <mru> no, there was no func2 before
[17:00:04] * BBB will actually have to read the patch
[17:03:41] <BBB> how do I mark a register as clobeered in inline asm?
[17:03:45] <BBB> vp5/6 bug is easy
[17:03:55] <BBB> once I know how to fix it ;)
[17:03:58] <mru> what is the bug?
[17:04:05] <peloverde> list it on the third colon
[17:04:06] <BBB> doesn't mark xmm6/7 as clobbered
[17:04:20] <mru> almost all of those bugs are easy in the same way
[17:04:31] <BBB> good, let's mark them and fix it
[17:04:33] <mru> the problem is when you get to the amd64-only xmm regs
[17:04:47] <BBB> you mean xmm8-15?
[17:04:51] <mru> I guess
[17:04:57] <BBB> this one only uses xmm6/7
[17:04:59] <BBB> so this is easy
[17:05:08] <BBB> peloverde: how? got an example for me to peek at?
[17:05:09] <mru> then do it
[17:05:26] <mru> asm ("code" : outputs : inputs : clobbers);
[17:05:41] <mru> clobbers is a comma-separated list of strings
[17:05:44] <mru> each string one reg
[17:06:15] <BBB> "%xmm6", "%xmm7"?
[17:06:23] <BBB> let's try
[17:06:34] <peloverde> http://git.ffmpeg.org/?p=ffmpeg;a=blob;f=libavcodec/x86/idct_sse2_xvid.c;h=fc670e25d476a5329376b06dc048ff33a9332fee;hb=HEAD
[17:08:01] <BBB> what do I do if the same reg is used in two subsequent asm("..") calls?
[17:08:19] <BBB> won't it push/pop before/after each, thus the value not being preserved in the second?
[17:08:40] <peloverde> you aren't supposed to preserve register values across multiple asm calls
[17:08:47] <peloverde> that's why I redid the imdct
[17:08:50] <peloverde> in yasm
[17:09:16] * BBB kills whoever wrote this pos
[17:09:24] <BBB> ok, I'll rewrite it, it's not very long
[17:09:28] <BBB> in fact it'll be smaller :-p
[17:16:31] <BBB> VP6DSPContext good idea also?
[17:16:39] <BBB> would remove more crap from dsputil
[17:16:46] <BBB> crap_that_should_not_be_there
[17:16:49] <mru> one thing at a time
[17:16:57] <BBB> separate patches of course
[17:17:00] <BBB> but is it a good idea?
[17:17:08] <BBB> I mean, dude, I'm volunteering ;)
[17:17:22] <mru> which function?
[17:17:24] <BBB> it's just one function though
[17:17:27] <BBB> vp6_filter_diag4
[17:17:34] <BBB> used only in vp6.c
[17:17:35] <mru> if nothing else uses it, go for it
[17:17:38] <BBB> k
[17:18:04] <mru> put it in vp56dspcontext
[17:18:19] <mru> no need for yet another one
[17:18:26] <BBB> ah, ok
[17:47:57] <CIA-11> ffmpeg: mru * r24909 /trunk/libavcodec/ (15 files in 4 dirs): Remove global mm_flags variable
[17:48:52] <Dark_Shikari> \o/
[17:48:55] <Dark_Shikari> wait.  what about emms?
[17:49:03] <Dark_Shikari> what'd you do to solve that?
[17:49:05] <mru> compile-time static
[17:49:13] <peloverde> so much for all my compiled object code
[17:49:21] <mru> huh?
[17:50:22] <mru> I see no reason to carry around special support for the 3 non-mmx machines still in existance
[17:50:45] <peloverde> dsputil .h just changed, means almost everything gets rebuilt... it was more of a joke than a complaint
[17:50:46] <Dark_Shikari> inb4 distros supporting i386 complain
[17:50:59] <mru> peloverde: oh, I see
[17:51:21] * mru loves poking sticks in debian's eyes
[17:51:42] <peloverde> poor siretart
[17:51:57] <mru> didn't he say he was ok with this?
[17:52:39] <peloverde> then I'm curious as to what his plan is
[17:52:45] <kurosu> *famous last words*
[17:53:17] <Dark_Shikari> peloverde: I don't think they support i386, at least not on ubuntu
[17:53:35] <peloverde> what about debian?
[17:54:00] <mru> good luck running ffmpeg on a 386
[17:54:59] <peloverde> I don't see why you couldn't run it on a pentium-sans-mmx
[17:55:12] <mru> then you build with --disable-mmx
[17:56:11] <J_Darnley> When you're done encoding with that, DNF will be oldskool
[17:57:48] <CIA-11> ffmpeg: janne * r24910 /trunk/configure: configure: enable fast_cmov for 'atom'
[18:06:53] <BBB> I wonder if HD H264 plays above or below 1fps on a pre-MMX x86
[18:07:01] <BBB> or VP8, for that matter :-p
[18:07:18] <Dark_Shikari> you may have cache issues
[18:07:26] <mru> I guess <1fps
[18:07:29] <Dark_Shikari> though memory-cpu communication was faster back then
[18:07:34] <Dark_Shikari> (relative to clock speed)
[18:07:35] <mru> those machines were insanely slow
[18:08:02] <kshishkov> what about your avr?
[18:08:16] <peloverde> You know people always brink up how slow 1080p H.264 would play on those things but we watched low res divx videos just fine
[18:08:36] <Dark_Shikari> no you didn't
[18:08:47] <Dark_Shikari> back in the P1 days, you needed a PCI acceleration card for mpeg-2
[18:08:47] <ohsix> not without mmx anyways :D
[18:08:53] <Dark_Shikari> remember those?
[18:08:57] <BBB> haha
[18:08:57] <mru> not on pre-mmx pentium
[18:08:58] <mru> no way
[18:09:02] <BBB> i had one of those
[18:09:23] <BBB> there was even a linux driver
[18:09:26] <BBB> DXR2 or DXR3 or so
[18:09:34] <Dark_Shikari> in 1994? ;)
[18:09:48] <BBB> later 90s
[18:09:52] <BBB> but still 90s
[18:10:19] <BBB> (the card, not the linux driver :-p)
[18:11:36] <kshishkov> thank you all, you make me feel young
[18:13:08] <peloverde> 352x288 MP43 at 25 fps + mp3 stereo 22050 Hz
[18:14:14] <peloverde> After all these years it still looks pretty good
[18:18:31] <kshishkov> VideoCDs FTW!
[19:10:18] <peloverde> saintdev: I ran aacx under massif and don't see any leaks, my 285 frame file uses 40 MB
[19:10:38] <saintdev> peloverde: oh i don't think there are any leaks
[19:10:59] <saintdev> was just loading a 7minute file...
[19:11:17] <peloverde> ok
[19:11:46] <saintdev> just happened to notice my mem usage skyrocket
[19:14:53] <siretart> peloverde: sorry, WHAT happened?!
[19:15:47] <peloverde> siretart: emms() is now called if AV_MMX is present (i.e. it is no longer runtime detected)
[19:15:57] <peloverde> s/AV_MMX/HAVE_MMX/
[19:16:20] <siretart> peloverde: does this have any effect on existing binaries?
[19:16:49] <peloverde> binaries built from this point forward with MMX will not run on pre-MMX machines
[19:16:50] <mru> no, only on ones compiled after the change
[19:17:02] <mru> I'd love the ability to retroactively change compiled binaries
[19:17:27] <siretart> oh, that's just an SHLIBS bump then IIUC, that's really no problem
[19:18:05] <siretart> oh, does that mean that  FFmpeg officially dropped support for non-MMX machines on x86?
[19:18:22] <peloverde> does debian no longer support PPro?
[19:18:23] <mru> no
[19:18:32] <mru> --disable-mmx still works
[19:18:43] <peloverde> yes but you can't build one binary for both
[19:19:21] <siretart> again, that's also no problem, I have to compile several flavors anyways and let ld-linux.so pickup the best one based on hwcaps detection
[19:19:39] <siretart> don't know what other distros are doing, though.
[19:19:39] <peloverde> ok
[19:19:56] <siretart> but make sure that this change is documented properly
[19:20:06] <siretart> it will be important for the next release notes
[19:20:19] <siretart> pretty please :-)
[19:22:39] <siretart> hm. but that means that I really need to compile the base flavor with --disable-mmx
[19:26:41] <Dark_Shikari> siretart: does debian support pre-i586?
[19:26:44] <Dark_Shikari> I didn't think it did
[19:27:10] <peloverde> PPro is i686 without MMX
[19:27:11] <mru> debian supports clay tablets
[19:27:27] <mru> in fact, they build it on an abacus
[19:27:34] <mru> that's why all the packages are so old
[20:09:41] <lu_zero> hyc: ping
[20:12:46] <BBB> vp6 should work on win64 too now
[20:12:52] <BBB> let's see if it really does (totally untested)
[20:13:00] <BBB> now I wonder why fate-vp5 fails on fate
[20:13:04] <BBB> er, win64
[20:26:54] <lu_zero> win64 is actually getting used by people?
[20:27:10] <lu_zero> and more important mingw64 and wine are working?
[20:31:18] <Compn> ____ is actually used by people ?
[20:31:25] <Compn> and more important ____ and ____ are working?
[20:31:36] <Compn> insert any odd os/compiler combo here ^
[20:31:59] <mru> soon beos will be the only one not on fate...
[20:32:32] <Compn> http://i.imgur.com/I9sYr.jpg
[20:32:34] * mru has both tru64 and irix machines standing around unusued...
[20:44:33] * lu_zero could setup a kvm with haiku inside
[20:44:59] * mru wouldn't bother
[20:45:23] <mru> as far as we know, there is only one user of haiku anyway
[20:46:10] <lu_zero> nah
[20:46:14] <lu_zero> there is plenty
[20:46:49] <lu_zero> haiku is getting functional and there are many people who aren't developing it
[20:49:34] <thresh> poor souls
[20:49:53] <CIA-11> ffmpeg: vitor * r24911 /trunk/tests/ (ref/fate/txd-pal8 ref/fate/txd-16bpp fate2.mak): Renderware TeXture Dictionary FATE test
[20:54:02] <pJok> mru, that went fairly well...
[20:54:18] <mru> the interview?
[20:54:28] <pJok> yeah
[20:54:45] <pJok> next step is a phone interview
[20:55:08] <mru> what? you met them in person first, then phone interview?
[20:55:48] <pJok> no, it was a recruitment company interview
[20:55:53] <mru> ah
[20:56:10] <pJok> just to sift out any unwanted applications
[20:57:00] <pJok> but i think it went well, so the phone interview will hopefully be equally good
[20:57:26] <pJok> since  the person hirering is in london whilist the job is still in copenhagen
[21:10:40] <lu_zero> o_O
[21:25:00] <kierank> hehe using vlc at the chilean mine
[21:47:49] <mru> saste: vf_scale crashes badly if avfilter_get_video_buffer() fails
[21:48:01] <mru> and there's no way to error out of that function
[21:48:03] <Dark_Shikari> mru: fun pdf of the day
[21:48:05] <Dark_Shikari> http://www.intel.com/Assets/en_US/PDF/specupdate/323338.pdf
[21:48:15] <Dark_Shikari> start on page 18
[21:48:50] <Dark_Shikari> some of these errata are amazing, as in, I'm shocked that the actions necessary to trigger the bug are even _valid_
[21:49:25] <Dark_Shikari> e.g. AAY7 is about how if you use FXSAVE (store float registers) on an address at the top of memory with less than 512 bits left as is necessary to store it
[21:49:33] <Dark_Shikari> it'll only partially save the results, and won't wrap around to the low memory
[21:57:42] <mru> processor errata are always obscure
[21:58:40] <Dark_Shikari> some of them less so than others
[21:58:56] <mru> the non-obscure ones are the scary ones
[21:59:06] <Dark_Shikari> Yeah
[21:59:18] <Dark_Shikari> Is that even standard btw?
[21:59:24] <Dark_Shikari> to have a write of 4 bytes to 0xffffffff
[21:59:30] <Dark_Shikari> intend to wrap around to 0x00000003 ?
[21:59:41] <mru> on some CPUs, sure
[21:59:43] <Dark_Shikari> i.e. is that by-design in most processors?
[21:59:59] <mru> some don't support unaligned accesses, so they don't have to choose
[22:00:12] <Dark_Shikari> true
[22:01:57] <Dark_Shikari> heh, there are even some livelocks in those erratum
[22:02:38] <twnqx> well, it's the reason for the good old a20 gate..
[22:02:59] <twnqx> (the wraparound on x86)
[22:03:11] <Dark_Shikari> ?
[22:03:31] <twnqx> remember the 286, and real mode? :P
[22:03:40] <twnqx> with segment:offset addressing?
[22:04:11] <Dark_Shikari> >_>
[22:04:42] <twnqx> segments where always 64kbyte in size, but overlapping... and you had 20 address bits, so you could "use" a segment that would go from just below 1MB to the first few kB
[22:05:08] <twnqx> to emulate that, 386+ had the gate a20 that would turn off the 20th adress line off until requested by software.
[22:05:16] <twnqx> and it haunts us until today...
[22:06:30] <mru> Dark_Shikari: on ARM any memory access that crosses the top of the address space is unpredictable
[22:08:55] <Dark_Shikari> interesting
[22:09:33] <mru> overflow in an address calculation is defined the obvious way
[22:09:49] <Dark_Shikari> valid wraparound?
[22:10:02] <mru> unsigned wraparound as you'd expect
[22:10:22] <Dark_Shikari> yeah
[22:10:37] <mru> accessing both sides with a single instruction isn't possible
[22:10:56] <mru> be it an unaligned (half-) word access or a multiword access
[22:12:48] <roxfan> http://www.win.tue.nl/~aeb/linux/kbd/A20.html
[22:37:58] <BBB> ok what shall I port next?
[22:38:38] <Dark_Shikari> port?
[22:38:50] <saintdev> x264 -> vp8
[22:38:54] <Dark_Shikari> yes
[22:38:54] <Dark_Shikari> that
[22:38:59] <Dark_Shikari> get on with it, stop slacking =p
[22:39:02] <Dark_Shikari> and ask for help if you need it
[22:39:04] <Dark_Shikari> I'm not doing enough work
[22:39:25] <BBB> ok, ok
[22:39:36] <BBB> I have really been looking hard at understanding the boolcoder
[22:39:44] <BBB> maybe I need a book
[22:39:54] <Dark_Shikari> understanding?  there's not much to understand
[22:39:55] <BBB> it's purpose is to compress... but I don't see how it works
[22:39:56] <Dark_Shikari> it's just like x264's
[22:40:05] <Dark_Shikari> do I need to re-explain arithmetic coding?
[22:40:08] <BBB> and x264's is totally clear and understandable to me :-p
[22:40:13] <BBB> yes
[22:40:42] <Dark_Shikari> I will explain via induction
[22:41:00] <Dark_Shikari> I will explain the inductive step first
[22:41:16] <Dark_Shikari> At the start of the inductive step, we have the following data:
[22:41:32] <Dark_Shikari> 1) "low".  This is a value from 0.0 to 1.0.  (in reality, it's fixed point)
[22:41:53] <Dark_Shikari> 2) "high".  This is a value larger than low, and still <= 1.0.
[22:42:08] <Dark_Shikari> 3) In some coders, "high" doesn't exist, and instead "range" is stored (the difference between low and high).
[22:42:19] <Dark_Shikari> These two values together represent a range of values.
[22:42:22] <Dark_Shikari> So, for example
[22:42:24] <Dark_Shikari> 0.4 - 0.9
[22:42:30] <Dark_Shikari> That would be a low of 0.4, high of 0.9, range of 0.5.
[22:42:31] <Dark_Shikari> Got it?
[22:42:35] <BBB> yes
[22:42:56] <Dark_Shikari> What we are doing is writing an infinite-precision fraction.
[22:43:05] <Dark_Shikari> Suppose our range was in fact 0.6 - 0.9.
[22:43:14] <Dark_Shikari> This means that we KNOW the next bit of our fraction is a 1.
[22:43:16] <Dark_Shikari> Do you see why?
[22:43:48] <BBB> uhm... no
[22:43:56] <Dark_Shikari> Because we know that our fraction is larger than 0.5.
[22:43:59] <Dark_Shikari> Therefore, the next bit must be 1.
[22:44:09] <Dark_Shikari> Our fraction is somewhere between 0.6 and 0.9 (our range).
[22:44:11] <BBB> oh, range, not high
[22:44:12] <BBB> yes
[22:44:16] <Dark_Shikari> Therefore, we know that we can "write out" a 1.
[22:44:27] <Dark_Shikari> Writing out a 1 turns 0.6-0.9 into 0.2-0.8.
[22:44:28] <Dark_Shikari> Do you see why?
[22:45:29] <BBB> the 0.2 might be 0.6-low
[22:45:35] <BBB> but I don't really get it
[22:45:35] <Dark_Shikari> no, think about it
[22:45:38] <Dark_Shikari> we are rescaling it
[22:45:50] <Dark_Shikari> by writing out a 1, we are "magnifying" 0.5-1.0 into 0.0-1.0
[22:45:56] <Dark_Shikari> i.e. 0.5-1.0 becomes the new 0.0-1.0
[22:45:57] <Dark_Shikari> thus,
[22:46:01] <Dark_Shikari> 0.6-0.9 becomes 0.2-0.8
[22:46:06] <Dark_Shikari> This is called renormalization
[22:46:19] <Dark_Shikari> This codifies the number 1 rule of an arithmetic coder:
[22:46:26] <Dark_Shikari> The range must cross 0.5.
[22:46:37] <Dark_Shikari> When it does not, you write out bits until it does.
[22:46:52] <Dark_Shikari> If high < 0.5, you write out a 0 and renormalize.
[22:46:56] <Dark_Shikari> if low > 0.5, you write out a 1 and renormalize.
[22:47:05] <Dark_Shikari> this is repeated until high > 0.5 > low.
[22:47:20] <Dark_Shikari> what parts of this do you not understand?
[22:47:26] <BBB> I think I get this
[22:47:30] <Dark_Shikari> OK, now the second part
[22:47:37] <Dark_Shikari> how does the range even happen in the first place
[22:47:44] <Dark_Shikari> well, suppose we start our range at 0.0 - 1.0 (a nice initialization point)
[22:47:55] <Dark_Shikari> now, suppose we are writing a bit with probability 30%
[22:48:00] <Dark_Shikari> i.e. 30% chance it's 1, 70% chance it's 0
[22:48:14] <Dark_Shikari> "prob" in vp8 is a fix8 representation of this probability.
[22:48:57] <Dark_Shikari> If the bit is a 0, our range becomes 0.0 - 0.7.
[22:49:02] <Dark_Shikari> If the bit is a 1, our range becomes 0.7 - 1.0.
[22:49:14] <Dark_Shikari> In other words, we split the range: one side of the range is "if the bit is a 0", the other side is "if the bit is a 1".
[22:49:47] <Dark_Shikari> Notice how if the bit is a 0, no bit is immediately written to the output bitstream!
[22:49:54] <Dark_Shikari> in this case, a bit of "0" cost us *LESS* than one bit.
[22:50:07] <Dark_Shikari> and a bit of "1" cost us *MORE* than one bit, due to it taking up more than half of the range.
[22:50:18] <Dark_Shikari> So, suppose our bit is in fact a 1.
[22:50:20] <Dark_Shikari> 0.7 - 1.0
[22:50:22] <Dark_Shikari> This doesn't cross 0.5.
[22:50:25] <Dark_Shikari> So we renormalize.
[22:50:40] <Dark_Shikari> We write out the bit "1" and get a range of 0.4-1.0.
[22:50:46] <Dark_Shikari> Now it crosses 0.5.
[22:51:01] <Dark_Shikari> Now, suppose our next bit has probability 50%, and we write a "0"
[22:51:08] <Dark_Shikari> "0" range: 0.4 - 0.7
[22:51:12] <Dark_Shikari> "1" range: 0.7 - 1.0
[22:51:26] <Dark_Shikari> so now our range is now 0.4 - 0.7
[22:51:36] <Dark_Shikari> But this time, it still crosses 0.5, so we don't renormalize, and we don't write anything to the bitstream.
[22:51:53] <Dark_Shikari> Note the distinction between input bits (which are assigned probabilities) and output bits (which are written due to renormalization).
[22:51:58] <Dark_Shikari> what don't you get so far?
[22:52:21] <BBB> I think I get it
[22:52:26] <Dark_Shikari> Now, some other things to note...
[22:52:33] <Dark_Shikari> this is the GENERIC description of an arithcoder
[22:52:37] <Dark_Shikari> all range coders and arithcoders work this way.
[22:52:45] <Dark_Shikari> Some take shortcuts for speed, in terms of precision or whatnot.
[22:52:51] <Dark_Shikari> Others may use lookup tables instead of multiplies for calculations.
[22:53:00] <Dark_Shikari> Some are adaptive, and update their probabilities based on bits written.
[22:53:16] <Dark_Shikari> Next, most good implementations of arithcoders work based on bytes, not bits, as you saw in the vp56 one.
[22:53:48] <Dark_Shikari> In such an implementation, a renormalization becomes that branchless function in vp56.h
[22:53:53] <Dark_Shikari> instead of being a while() loop
[22:53:56] <Dark_Shikari> as I described above
[22:53:59] <Dark_Shikari> e.g. renorm until it crosses 0.5
[22:54:48] <Dark_Shikari> By the way, a simple example of how bit costs work out
[22:54:51] <BBB> so how does the writing work then? do we wait until 8 bit-probabilities have been written? or is it just a bitstream writer as before, but output is only written once every 8 output bits?
[22:55:01] <Dark_Shikari> no, you just write a bit at a time
[22:55:08] <Dark_Shikari> Or you can have a cache, etc
[22:55:13] <BBB> ok, so writing is the same
[22:55:16] <Dark_Shikari> in x264, we use a bytestream implementation I described above
[22:55:21] <Dark_Shikari> well, mentioned, not described
[22:55:24] <Dark_Shikari> Let me guide you through x264's.
[22:55:36] <Dark_Shikari> x264's is slightly munged for performance reasons, but it's largely the same.
[22:55:50] <Dark_Shikari> open common/cabac.c and turn to line 819
[22:55:52] <Dark_Shikari> and tell me when you're ready
[22:56:11] <BBB> done
[22:56:20] <Dark_Shikari> line 834
[22:56:27] <Dark_Shikari> range_lps is how much to adjust the range
[22:56:32] <Dark_Shikari> e.g. in the case of 0.0 - 1.0
[22:56:36] <Dark_Shikari> and 30% probability
[22:56:52] <Dark_Shikari> our range_lps would be 0.3
[22:57:08] <Dark_Shikari> e.g. if the bit is 0, we -= range_lps to get 0.0 - 0.7
[22:57:16] <Dark_Shikari> and if the bit is 1, we = range_lps to get 0.7 - 1.0
[22:57:24] <Dark_Shikari> since "range" is the distance between the two
[22:57:28] <Dark_Shikari> (low is also set accordingly)
[22:57:40] <Dark_Shikari> cabac_range_lps is a lookup table: h264 uses a LUT that's slightly approximate in order to avoid the multiply.
[22:58:01] <Dark_Shikari> The i_state>>1 and &1 bits are just a reorganization we made to the state table for speed reasons. Ignore them.
[22:58:02] <BBB> slightly approximate means...?
[22:58:10] <Dark_Shikari> It's quantized
[22:58:14] <Dark_Shikari> note the low [] of the table
[22:58:18] <Dark_Shikari> it's [num states][4]
[22:58:27] <Dark_Shikari> range_lps, in theory, should be different for every input range value.
[22:58:38] <Dark_Shikari> But here it's quantized so there's only 4 possible values.
[22:58:45] <Dark_Shikari> NB: "state" is the probability.
[22:59:05] <Dark_Shikari> line 841: we update the probability based on the transition table and bit (whether it's 0 or 1).
[22:59:06] <saste> mru: why are you saying that? are you actually having crashes in vf_scale.c?
[22:59:09] <Dark_Shikari> line 842: call renorm.
[22:59:27] <saste> mru: or is it just an API issue?
[22:59:27] <Dark_Shikari> line 821: calculate how much to renorm.  The number that results from this LUT is _equivalent_ to the number of times a bit-based implementation would need to renorm.
[22:59:35] <Dark_Shikari> so if this is "3", we need to renorm 3 times.
[22:59:45] <Dark_Shikari> The <<, <<, and + perform the renorm step.
[22:59:55] <Dark_Shikari> finally, putbyte is run if we have at least one byte to write out.
[23:00:07] <Dark_Shikari> any issues so far?
[23:00:22] <BBB> Ill have to re-read this tonight but makes sense so far
[23:00:32] <Dark_Shikari> ok, now to explain putbyte
[23:00:34] <Dark_Shikari> this is a little bit tricky
[23:00:46] <Dark_Shikari> NB: queue is offset by 8, same as in vp56
[23:00:50] <Dark_Shikari> in order to make the if() faster
[23:00:53] <Dark_Shikari> i.e. "0" is really 8
[23:00:56] <Dark_Shikari> and "-8" is really 0
[23:01:08] <Dark_Shikari> line 789: if we have a byte to write out...
[23:01:23] <Dark_Shikari> line 791: get the data to write out (the high bits of "low")
[23:01:43] <Dark_Shikari> 792: mask off the bits we're writing out, since, well, we're writing them out, so they should go away.
[23:01:50] <Dark_Shikari> 793: update queue (number of bits queued)
[23:01:58] <Dark_Shikari> 795: Here is the tricky part.
[23:02:17] <Dark_Shikari> It's quite possible to keep writing bits, and writing bits, until your range looks like ths:
[23:02:20] <Dark_Shikari> *this:
[23:02:22] <Dark_Shikari> 0.49  - 0.51
[23:02:25] <Dark_Shikari> And keep writing and writing.
[23:02:28] <Dark_Shikari> 0.49999-0.500001
[23:02:38] <Dark_Shikari> and so forth.
[23:02:43] <Dark_Shikari> Since it crosses 0.5, we can't renorm.
[23:03:04] <mru> saste: yes, it crashed there
[23:03:07] <Dark_Shikari> This is handled by bytes_outstanding.
[23:03:16] <Dark_Shikari> If we are in that situation, as defined by out&0xff == 0xff
[23:03:21] <Dark_Shikari> it increments bytes outstanding instead.
[23:03:32] <mru> saste: simulate an allocation failure and see for yourself
[23:03:33] <Dark_Shikari> And later, when it's time to actually write, it can handle that.
[23:03:44] <Dark_Shikari> got it so far?
[23:04:02] <mru> fixing it seems to involve changing the entire damn api
[23:04:39] <BBB> no... so why do you need i_bytes_oustanding?
[23:05:25] <Dark_Shikari> because we can accumulate an arbitrary number of bytes in that situation
[23:05:42] <saintdev> you get 'stuck' in a place where low and high are just on either side of 0.5
[23:05:43] <Dark_Shikari> pengvado can probably explain it better
[23:05:53] <Dark_Shikari> so basically, the thing is
[23:06:06] <BBB> so you mean "it's not actually writing bits to the output", so a reader wouldn't know what to do with it?
[23:06:16] <Dark_Shikari> BBB: it will write them when it comes time to write something
[23:06:19] <Dark_Shikari> e.g. they're "queued" bytes
[23:06:27] <Dark_Shikari> Then, as you can see in 807
[23:06:32] <Dark_Shikari> if it comes time to write a byte that isn't 0xff
[23:06:39] <Dark_Shikari> it will write out all the queued bytes.
[23:07:01] <Dark_Shikari> pengvado can explain this better.
[23:07:05] <Dark_Shikari> afk
[23:08:06] <BBB> will need to re-read it, but I think I sort of get it
[23:08:15] <BBB> I'll re-read vpx boolcoder also
[23:08:19] <BBB> maybe now it'll make sense
[23:11:01] <BBB> do we really need libavsequencer versioning symbols etc.?
[23:11:15] <mru> imo we don't need it at all
[23:11:21] <BBB> I'm not gonna bring it up again but it seems silly for something that we all agree probably should be in lavc for the time being, if anywhere at all
[23:11:28] <mru> certainly not without a _thorough_ review
[23:11:30] <BBB> it should NOT have a public API, esp. not now
[23:11:46] <mru> it shouldn't be in svn now
[23:11:56] <BBB> I think they're gonna commit it ;)
[23:12:05] <mru> can we stop them?
[23:12:10] <mru> well, I can...
[23:12:26] <BBB> saste: can you hold off committing lavseq until we've seen the actual real patches?
[23:13:23] <mru> gah, he ran away
[23:19:57] <BBB> thanks for the email
[23:19:59] <BBB> gonna go home
[23:20:01] * BBB bbl