[FFmpeg-devel-irc] IRC log for 2011-02-19

[irc at mansr.com]

[00:00:15] <BBB> Yuvi: I thought of that, but like I said, it's not always +128, it's also -128 (and no it's not going from signed->unsigned is always +128 and unsigned->signed is always -128, it's a little weirder than that
[00:00:26] <BBB> should I just provide a "bias" argument to the put_idct8x8 function?
[00:00:32] <BBB> that's kinda lame
[00:01:09] <BBB> also one of them does <<= 1
[00:01:39] <BBB> I'm currently considering having an idct_put_8x8[2], where [0] is the default one and [1] does the <<= 1, such as not to slow it down too much
[00:01:44] <BBB> vc1 is really weird
[00:02:02] <Dark_Shikari> Is the <<1 the range extension thing?
[00:02:25] <BBB> yes
[00:06:36] <BBB> or well VC1Context calls it range reduction
[00:14:10] <iive> BBB: one more thing, while we are in idct wave. is your mmx implementation working on words only? the C version uses int.
[00:14:47] <iive> the posibility of overflow with the "naive" version was the reason we didn't got mmx 3 years ago.
[00:16:40] <BBB> yes it's words only
[00:16:48] <BBB> the spec says you can do it in words
[00:16:52] <BBB> I don't know if the spec is right
[00:17:02] <BBB> make fate-vc1 is not affected
[00:17:13] <BBB> I'm hoping to get a bigger vc1 testsuite to test some more
[00:17:26] <BBB> I could try to mathematically show it but ohwell
[00:18:29] <iive> well... it says it is possible, it doesn't say _how_ :E
[00:18:59] <iive> aka, if binary version is also straight forward... then no-problem.
[00:21:37] <astrange> use dct-test
[00:23:27] <BBB> will look
[00:23:29] * BBB brb
[00:36:30] <j0sh> http://news.ycombinator.com/item?id=2237898
[02:23:39] <mru> Dark_Shikari: ping
[02:23:56] <Dark_Shikari> pong
[02:24:01] <mru> you broke vp3
[02:24:05] <Dark_Shikari> what
[02:24:07] <Dark_Shikari> I tested it
[02:24:12] <mru> http://fate.ffmpeg.org/
[02:24:33] <mru> fate does not lie
[02:24:50] <dalias> :)
[02:25:48] <Dark_Shikari> passes here
[02:26:00] <mru> seems 64-bit only
[02:26:11] <mru> and qnx
[02:26:24] <mru> and mingw
[02:26:37] <Dark_Shikari> could it relate to linesizes and signedness?
[02:26:55] <mru> no idea
[02:27:03] <mru> but I suggest you find out
[02:27:13] <Dark_Shikari> I don't know enough about VP3...
[02:27:26] <mru> it's a segv, how hard can it be?
[02:27:39] <mru> valgrind it or something
[02:27:39] <Dark_Shikari> oh.  a segfault.
[02:28:01] <Dark_Shikari> I don't have any such boxes to test on though
[02:28:22] <mru> no 64-bit or mingw?
[02:28:27] <mru> I find that hard to believe
[02:28:34] <Dark_Shikari> oh, let me try mno-cygwin
[02:28:56] <mru> it crashes on cygwin too actually
[02:29:12] <Dark_Shikari> Works here
[02:29:15] <Dark_Shikari> I'm on cygwin
[02:29:26] <mru> kostylev's cygwin fails
[02:34:53] <mru> valgrind has a lot to say
[02:35:23] <Dark_Shikari> what is s->current_frame.linesize[0] when edge_emu_buffer is allocated?
[02:35:44] <mru> it's complaining about edge_emu_buffer
[02:39:51] <mru> allocating a bit more makes it work
[02:40:08] <Dark_Shikari> o.0
[02:40:15] <Dark_Shikari> Was it only working before because too much was allocated?
[02:40:39] <Dark_Shikari> That seems unlikely?  It only needs 9 rows...
[02:41:14] <mru> another 16 bytes makes it work
[02:41:21] <Dark_Shikari> o.0 0.o o.0 0.o
[02:41:36] <Dark_Shikari> do I blame BBB's asm?
[02:41:43] <mru> no
[02:41:49] <mru> it fails on alpha and ia64 too
[02:42:21] <mru> 9 extra bytes is enough
[02:42:46] <mru> related to the 9 rows?
[02:42:49] <Dark_Shikari> I don't understand why it needs extra bytes...
[02:49:21] <mru> maybe you should figure it out then...
[02:49:29] <mru> I don't know that code any better than you do
[02:49:56] <Dark_Shikari>                             uint8_t *temp= s->edge_emu_buffer;
[02:49:56] <Dark_Shikari>                             if(stride<0) temp -= 9*stride;
[02:49:57] <Dark_Shikari>                             else temp += 9*stride;
[02:50:01] <Dark_Shikari> what is going on here?
[02:50:26] <mru> looks like you found your overflow
[02:51:03] <Dark_Shikari> But that would have broken before too.
[02:51:22] <Dark_Shikari> I don't understand how emulated edge mc works...
[02:51:27] <Dark_Shikari> i.e. why we have to do += 9*stride
[03:11:15] <Dark_Shikari> Yeah, I'm lost here, sorry.
[03:11:23] <Dark_Shikari> I don't know how to fix it, and the original code clearly worked by coincidence.
[03:12:54] <kierank> the troll hunter was really good
[03:17:12] <Yuvi> Dark_Shikari: probably you really only have to do that for negative stride (which theora basically always has since it's flipped)
[03:18:05] <Dark_Shikari> I tried only doing it for negative strides, it broke fate
[04:06:25] <Jumpyshoes> http://ffmpeg.pastebin.com/jR7Dh9aR both are on cygwin, does anyone know why one uses window's tmp dir while the other tries to use linux style tmp dir?
[04:18:58] <drv> maybe something sets TEMPDIR or TMP in between?
[04:20:32] <Jumpyshoes> should be the same config though, i think
[04:46:45] <kierank> http://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread/thread/80eedd7d4b94a789?pli=1
[04:46:49] <kierank> mike <3
[05:30:02] <Sean_McG> dinky little 200MHz SH-4, woopty do
[05:35:01] <pross-au> Sean_McG: the were a great console. i still have mine!
[05:35:31] <Sean_McG> I had one too, sold it about a year ago when I was cleaning up
[05:55:26] <Sean_McG> bootstrapping gcc trunk on one of my VMs, and building libgpac on my SPARC... both of these will take time so I'mma go get some sleep
[06:25:06] <Dark_Shikari> so, uh, yeah, anyone feel like figuring out why vp3 is broke?
[06:25:12] <Dark_Shikari> anyone who understands emulated edge mc at least?
[06:25:26] <Dark_Shikari> and why temp += 9*stride is required to make it work if stride > 0?
[07:14:41] <Yuvi> Dark_Shikari: do you mean stride > 0 for the buffers from get_buffer or stride > 0 as in non-flipped vp3?
[07:16:57] <Dark_Shikari> I mean in the emu_edge
[07:17:03] <Dark_Shikari> what's with the += 9*stride?
[07:35:02] <lu_zero> 9 rings a bell
[07:35:06] <lu_zero> well
[07:35:21] <lu_zero> any multiple of 3 rings a bell in vp3
[07:35:38] <lu_zero> but I just woke up and never touched that code =_=
[07:39:08] <dalias> hi
[07:39:10] <thresh> good morning
[07:41:08] <lu_zero> good morning
[07:43:45] * kshishkov does not believe thresh
[07:46:18] <thresh> kshishkov: yup, I don't believe myself either
[07:47:36] <kshishkov> probbly next thing would be ALT Linux rebasing on MeeGo
[07:47:52] <thresh> they actually think about autoimporting Fedora packages
[07:48:00] <thresh> not that I care much, I left the project
[07:52:41] <_av500_> and joined CTRL Linux?
[07:53:35] <lu_zero> good morning =)
[07:53:52] <lu_zero> feels another day already =P
[07:54:09] <pJok> ohayou gozaimasu
[08:18:34] <Yuvi> Dark_Shikari: get rid of the else, change -= 9 to -= 8
[08:20:09] <Dark_Shikari> if it works, want to just commit it?  since its your fix
[08:25:26] <Dark_Shikari> it works here, but I don't know if it fixes the crash
[08:39:03] <Yuvi> http://pastebin.com/VUT7grDs
[08:39:04] <Yuvi> good thing huffman_table is so big or that would have been potentially exploitable for all released ffmpeg
[08:40:31] <spaam> good thing that you removed that pastebin..
[08:42:37] <Dark_Shikari> Yuvi: just commit it?
[08:42:49] <Dark_Shikari> or send a mail and I'll approve it
[08:42:53] <Dark_Shikari> oh wait, do you have commit access?
[08:43:17] <Dark_Shikari> Wait, you're saying that it was broken before too?
[08:43:21] <Dark_Shikari> And it just happened to run into the huff table?
[08:43:50] <lu_zero> Dark_Shikari: what?
[08:43:54] <lu_zero> calm =)
[08:44:15] <Dark_Shikari> ?
[08:45:13] <lu_zero> what's up?
[08:45:44] * lu_zero doesn't have access to the pastebin
[08:54:25] <Yuvi> geh, what happened to that paste
[08:54:28] <Yuvi> http://pastebin.com/7Cp1d83m
[08:54:34] <Yuvi> don't have commit access I'm pretty sure
[08:56:41] <Dark_Shikari> send it to the ml and I'll commit it
[09:00:10] <CIA-15> ffmpeg: Young Han Lee <cpumaker at gmail.com> master * r9707f84fa7 ffmpeg/libavcodec/aacdec.c: aacdec: dsputilize the scalar multiplication in intensity stereo
[09:00:35] <lu_zero> hi j0sh
[09:02:00] * _av500_ proposes to make lavc and lavf only use RTS
[09:04:04] <j0sh> lu_zero: yo
[09:06:30] <j0sh> lu_zero: you won't like what i'm trying right now. replacing blocking read() with coroutines in librtmp
[09:09:54] <lu_zero> j0sh: why dislike?
[09:10:02] <lu_zero> if it works why not?
[09:10:26] <lu_zero> (I don't dislike the idea, last time I was looking for a quick fix ^^)
[09:10:46] <j0sh> heh... if it works, i will let you know in a few :)
[09:12:15] <kurosu> I'm having problem cloning:
[09:12:18] <kurosu> $ git clone http://git.ffmpeg.org/?p=ffmpeg.git ffmpeg
[09:12:18] <kurosu> Cloning into ffmpeg...
[09:12:32] <kurosu> fatal: http://git.ffmpeg.org/?p=ffmpeg.git/info/refs not found: did you run git update-server-info on the server?
[09:12:37] <lu_zero> kurosu: wrong url =)
[09:12:50] <kurosu> urg
[09:12:51] <kurosu> right
[09:12:57] <lu_zero> git://git.ffmpeg.org/ffmpeg.git
[09:12:57] <lu_zero> http://git.ffmpeg.org/ffmpeg.git
[09:13:06] <kurosu> yeah, just notice the "clone url"
[09:14:30] <kurosu> i was not getting why it wanted to clone into "?p=ffmpeg"
[09:16:21] <Dark_Shikari> Yuvi: you going to post it?
[09:43:26] <CIA-15> ffmpeg: David Conrad <davedc at kozue.local> master * ra89f4ca005 ffmpeg/libavcodec/vp3.c:
[09:43:27] <CIA-15> ffmpeg: Fix VP3 edge emulation
[09:43:27] <CIA-15> ffmpeg: With negative stride, the start of the edge_emu buffer should be pointing to
[09:43:27] <CIA-15> ffmpeg: the last line, not the end of the buffer.
[09:43:27] <CIA-15> ffmpeg: With positive stride, pointing to the end of the buffer was completely wrong.
[09:51:33] <astrange> 04:10 <@lu_zero> if it works why not? <- generation of dts from pts is easy if you have pts for every frame
[09:51:37] <astrange> sort it and you're done
[09:51:54] <astrange> but i don't know 1. what to do about sparse files 2. what to do about the last few frames in a file
[09:52:09] <lu_zero> astrange: I was referring to libtask =)
[09:52:23] <astrange> and you need generation of pts from dts to make mkvs
[09:52:38] <astrange> either way, it's educational
[09:52:56] * lu_zero is missing something...
[10:49:40] <mru> moroning
[10:50:05] <kshishkov> hello, dalatrollkarl
[10:55:56] <Flameeyes> lu_zero: aren't you supposed to .. not be home?
[10:56:29] <lu_zero> Flameeyes: I woke up exactly at 8 feeling really bad
[10:56:55] <Flameeyes> lu_zero: oh well, good news for me then, as I can get your help :P
[10:58:12] <lu_zero> sure
[11:20:26] <elenril> nice bikeshed about scalar products
[11:37:30] <ubitux> anyone knows a but about ctts (atom)?
[11:37:33] <ubitux> bit*
[11:37:38] <mru> dts
[11:37:49] <mru> sorry, pts
[11:37:54] <mru> composition time
[11:37:57] <mru> in mp4-speak
[11:38:53] <ubitux> i have a sample here with a big negative value, but it seems the workaround baptiste made is not enough/wrong
[11:39:17] <ubitux> in lavf/mov.c:mov_read_ctts
[11:40:10] <ubitux> the end of the samples look like this: http://pastie.org/1581970
[11:40:21] <mru> ctts defines the difference between dts and pts for each frame
[11:40:35] <mru> each entry in the table is non-negative by definition
[11:42:05] <mru> the dts is defined by the stts box, which lists positive deltas from the initial value provided by an edit list, if any
[11:43:13] <ubitux> why is there a negative value here?
[11:43:27] <ubitux> is the count invalid? is it a special case?
[11:44:29] <ubitux> ignoring the duration < 0 seems enough to fix the issue, but there is certainly something smarter to do
[11:45:29] <mru> what value is negative?
[11:45:39] <ubitux> the duration, look at the pastie
[11:45:40] <mru> the edit list duration is unsigned too
[11:46:13] <mru> where does that duration value come from?
[11:46:28] <ubitux> so the MOVStts struct is wrong?
[11:46:38] <ubitux> http://roundup.ffmpeg.org/issue2246 ← this is the issue
[11:47:09] <ubitux> the print is put in this loop: for(i=0; i<entries; i++) from mov_read_ctts (lavf/mov.c)
[11:48:01] <mru> those should be unsigned
[11:48:08] <mru> that's what the spec says
[11:48:09] <ubitux> int duration should be uint32_t then?
[11:48:16] <ubitux> (in the MOVStts struct)
[11:48:34] <mru> if that's supposed to correspond to entries in the stts box, yes
[11:48:52] <astrange> if the value in the file is large enough to wraparound to negative it's probably muxed wrong
[11:48:57] <ubitux> the value looks pretty big btw
[11:49:01] <astrange> but the torrent isn't seeded
[11:49:13] <ubitux> i have another torrent
[11:49:20] <ubitux> want it?
[11:50:12] <ubitux> astrange: that what i thought too, compared to the other values
[11:50:13] <mru> ubitux: what produced the content of your pastie?
[11:50:27] <ubitux> mru: as i said: <+ubitux> the print is put in this loop: for(i=0; i<entries; i++) from mov_read_ctts (lavf/mov.c)
[11:50:34] <ubitux> "COUNT=%d | DURATION= %10d (%10u) | dts_shift=%d\n", count, duration, duration, sc->dts_shift
[11:50:45] <ubitux> after count and duration are read
[11:50:47] <mru> there's nothing of the kind in my copy of ffmpeg
[11:51:01] <ubitux> i added it :p
[11:51:16] <mru> there's a different similar-looking debug line there though
[11:53:23] <mru> the value is absurdly large of course
[11:53:46] <mru> and what's with the 0-duration samples?
[11:53:53] <ubitux> since it's the last one i thought the count is wrong
[11:53:57] <ubitux> dunno
[11:54:40] <ubitux> it's like that since almost the first samples
[11:54:41] <mru> that's also invalid
[11:54:57] <mru> you can't have multiple frames with the same dts
[11:55:12] <mru> the spec is quite clear: The sample entries are ordered by decoding time stamps; therefore the deltas are all non-negative.
[11:55:40] <mru> wait a minute, you said ctts
[11:55:48] <mru> those can be zero of course
[11:58:36] <ubitux> http://paste.pocoo.org/show/341254/ ← here is the full sample table
[11:59:16] <siretart> lu_zero: regarding reimars patch, if you say it is okay, I'll push it, the thing is that it doesn't seem to make any difference on the sample in the bug: http://pbot.rmdir.de/ce71375b1d4aad1f827522f9c458f2ea
[12:00:27] <siretart> lu_zero: and https://roundup.ffmpeg.org/issue2584 (AKA CVE-2011-0723) seems to remain unfixed
[12:01:36] <siretart> oh, wait, I think I screwed up
[12:01:41] <siretart> redoing the diff
[12:03:37] <ubitux> btw mru, the video plays fine when the ctts are ignored, so what are there for? is it not noticable because of various workaround?
[12:03:48] <mru> ctts are pts
[12:03:50] <ubitux> (not only the last one, but all of them)
[12:04:45] <mru> or rather, stts defines pts, ctts defines pts-dts
[12:06:09] <siretart> lu_zero: yes, I did screw up. the diff clearly shows fixed overreads: http://pbot.rmdir.de/e5dedc8f07194683d6828fdc863ddd1a
[12:06:37] <siretart> do you guys think that this (arguably very long) diff of valgrind outputs is worth to copy in the commit message?
[12:09:31] <astrange> doesn't load
[12:09:43] <lu_zero> siretart: put it on the bug on roundup
[12:09:52] <lu_zero> hopefully roundup could stay stable
[12:10:40] <uau> ubitux: i looked at that issue2246 briefly before
[12:11:09] <uau> it's caused by insufficient handling of the dts_shift field in the lavf mov demuxer
[12:11:20] <astrange> i think -/+ on the error summary at the end is enough
[12:11:45] <mru> uau: please explain
[12:11:51] <mru> uau: those values are _unsigned_
[12:11:56] <mru> according to spec
[12:12:04] <mru> they cannot be negative, so the code makes no sense at all
[12:12:57] <twnqx> which bok was the dvd video? orange book?
[12:12:58] <uau> mru: i don't remember exactly what the values were (though i think they actually were calculated to be negative, whether conforming to the spec or not)
[12:13:00] <twnqx> book*
[12:13:12] <uau> but the actual problem was that other code didn't take the dts_shift amount into account
[12:13:21] <mru> uau: I'm looking at the code now
[12:13:31] <mru> the "negative" value is pulled directly from the file
[12:13:39] <twnqx> oh, no books for dvd, they were cd only, my bad.
[12:13:56] <uau> IIRC it was something like it calculated initial pts values, and then placed initial_pts+dts_shift into packet fields (where dts_shift was a *large* value)
[12:14:05] <uau> the resulting value the demuxer placed in packets was correct
[12:14:28] <mru> uau: why don't you look at the code if you want to discuss it?
[12:14:53] <uau> but other code used the unadjusted values; in particular code to interleave audio and video packets used the unadjusted values
[12:15:16] <uau> which resulted in all video packets being placed before audio or vice versa
[12:16:46] <mru> what's the dts_shift all about anyway?
[12:17:00] <mru> mp4 doesn't allow discontinuous timestamps
[12:17:08] <mru> edit list trickery aside
[12:17:50] <uau> i haven't checked any specs - the impression i got from checking the problem case was that there was a large offset in the coded pts values for video and audio in some files
[12:18:23] <uau> like one track going approximately from -2000 to 0, another from 0 to 2000
[12:18:37] <mru> you can't have negative values in mp4
[12:19:25] <astrange> you can have negative pts after applying the edit list
[12:19:49] <mru> how?
[12:20:00] <astrange> variables reading values directly from the file won't be negative though
[12:20:22] <mru> but the code wrongly uses signed types...
[12:20:52] <uau> anyway the main problem seemed to be that various code didn't use the dts_shift value (it was only used to calculate the final pts placed in output packet, when comparisons etc elsewhere should also have taken it in account)
[12:21:14] <mru> I'd like to see the contents of stts and ctts boxes in that file
[12:21:33] <mru> and elst
[12:21:51] <ubitux> want the beginning of the file/torrent?
[12:22:19] <ubitux> (notice for the torrent)
[12:22:26] <mru> whatever part of the file contains the headers
[12:23:01] <ubitux> (it's ep 178)
[12:25:52] <mru> is that relevant?
[12:26:38] <CIA-15> ffmpeg: Reimar Döffinger <Reimar.Doeffinger at gmx.de> master * r2bbec1eda4 ffmpeg/libavcodec/vc1dec.c:
[12:26:38] <CIA-15> ffmpeg: Fix invalid reads in VC1 decoder
[12:26:38] <CIA-15> ffmpeg: Patch discussed and taken from https://roundup.ffmpeg.org/issue2584
[12:26:55] <uau> the file i tested with is numbered 185v2, not sure if there are any differences
[12:26:58] <astrange> run qt-faststart and upload the first 5mb
[12:27:14] <astrange> or copy the first 5mb, see if that starts playing, upload if so
[12:27:40] <astrange> there's a negative start time mov in incoming/negative_start_time.mov according to issue1086
[12:27:51] <siretart> lu_zero: done
[12:28:00] <astrange> quicktime generates them as a way of letting you cut files at non-keyframes
[12:28:01] <lu_zero> siretart: thank you
[12:28:25] <uau> mru: want that 185 file?
[12:28:43] <astrange> the audio starts at time 0 or so but video has the first frame after the cut at time 0, and the keyframe+earlier frames needed for decode included
[12:28:52] <astrange> with the edit list shifting the track so they aren't displayed
[12:29:13] <astrange> ffplay/etc display the hidden parts but may have started syncing audio to the right place at some point
[12:29:29] <uau> has incoming been fixed to make files readable without excessive delay? i guess not?
[12:29:33] <astrange> anyway i don't feel like looking in there to remember what the edts/elst look like
[12:29:52] <astrange> it's sort-of a feature that should be implemented as playlists though
[12:30:16] <mru> astrange: nothing in mp4 can ever produce a negative timestamp
[12:30:48] <mru> if tracks start at different time, you must apply a positive offset the ones starting later
[12:30:58] <BBB> elenril: not lazy, I said I'd do it
[12:31:19] <uau> btw i recently added support for an external EDL file format to expose the timeline support i created for ordered chapters in mplayer2
[12:31:47] <uau> if the mov edit list information was exported that could probably also be used
[12:32:09] <astrange> ah, quicktime file format says that elst "media time" can be negative, but not very well
[12:32:26] <astrange> it says it's an integer and that -1 is a deletion
[12:32:30] <mru> I'm reading iso 14496-12
[12:32:52] <astrange> yes, they aren't exactly the same format
[12:33:01] <mru> there duration is unsigned
[12:33:15] <mru> and media_time=-1 means an "empty edit"
[12:33:17] <mru> aka gap
[12:33:35] <mru> so an empty edit at the start of a track gives a positive offset
[12:33:40] <mru> you can't encode a negative offset
[12:34:04] <mru> the file linked from that issue has ftyp isom so the iso spec applies
[12:38:39] <uau> hmm seems the negative time stamps are themselves produced as a result of the dts_shift value set
[12:38:49] <uau> current_dts -= sc->dts_shift;
[12:38:57] <mru> now we're talking
[12:47:28] <uau> well i'm uploading the file to incoming as issue2246.mp4 if anyone is interested
[12:47:45] <mru> is it not the torrent linked in the issue?
[12:48:12] <uau> different file from the same series
[12:48:37] <mru> which file has the values ubitux pasted?
[12:48:40] <uau> probably you can get that from torrent too (though getting just the start of a file from torrent is harder)
[12:48:46] <mru> I grabbed the torrent
[12:48:47] <ubitux> mru: ep 178
[12:48:57] <ubitux> from the torrent i noticed you
[12:49:02] <elenril> BBB: ofc you are lazy, all hackers are lazy =p
[12:49:26] * elenril is the laziest of them all
[12:51:02] <mru> I see the bad value
[12:51:15] <mru> the second last ctts entry
[12:51:45] <mru> the stts entries are all sane
[12:53:42] <mru> there doesn't seem to be an edit list
[12:54:16] <mru> looks like a simple case of fucked up file
[12:54:19] <uau> so r20458 fixed one kind of problematic/invalid file and broke another?
[13:00:07] <BBB> elenril: ok, I'll get on it then
[13:00:16] <BBB> seems like vc1 is not gonna progress for a couple of hours
[13:00:21] <BBB> then again, who uses vc1 anyway
[13:00:33] <BBB> andoma: ping
[13:00:33] <kshishkov> exactly
[13:01:14] <andoma> BBB: yeah
[13:03:04] <mru> taken literally, that file encodes the pts of the last frame as ~3h after the second-last one
[13:03:15] <mru> which is absurd but valid
[13:11:21] <uau> mru: the current code sets dts_shift because it sees a negative duration
[13:11:30] <mru> which isn't possible by spec
[13:11:32] <uau> so is something negative or is it overflow?
[13:11:34] <mru> so wtf is it meant to do?
[13:11:40] <mru> it's overflow
[13:11:51] <mru> the values are 32-bit unsigned in the file
[13:14:43] <uau> the duration interpreted as signed is -505555050
[13:14:49] <mru> that's a bug
[13:14:55] <uau> which is almost exactly minus the length of the file
[13:15:00] <mru> the file uses a time base of 1/360000 s
[13:15:12] <mru> the last frame has an insane pts set
[13:15:26] <mru> the file is syntactically valid
[13:15:30] <mru> afaics
[13:15:44] <uau> but insane in a way that looks like it's been set as signed
[13:15:51] <mru> no
[13:15:57] <mru> it's just a large unsigned value
[13:15:57] <ubitux> isn't it possible to check duration > max_duration or such?
[13:16:07] <mru> what duration?
[13:16:12] <mru> that variable is badly named
[13:16:14] <ubitux> of the whole file?
[13:16:17] <mru> these fields are not durations
[13:16:40] <ubitux> i read somewhere it was offset
[13:16:50] <ubitux> a random forum post
[13:16:55] <mru> the stts box codes dts for each frame as a delta from the previous one
[13:17:03] <mru> ctts codes pts as offset from dts
[13:17:14] <mru> I'm reading the spec
[13:17:34] <uau> mru: -505555050 / 360000 = -1404, and file duration is 1404 seconds - doesn't look like random (even if it should be unsigned according to spec)
[13:18:17] <uau> i guess the error is basically pts resetting back to 0 at the end
[13:20:38] <mru> good catch
[13:20:54] <mru> so it's a case of insane muxer
[13:24:14] <lu_zero_> ^^;
[13:29:40] <mru> wtf is that dts_shift meant to do?
[13:30:54] <mru> does the file play if dts_shift is forced to zero?
[13:31:06] <uau> what's the "cslg" atom?
[13:31:15] <uau> that's what the first commit adding it referred to
[13:31:24] <mru> not in the spec
[13:31:30] <mru> probably a quicktime thing
[13:36:30] <mru> nope, not in the quicktime spec either
[13:39:09] <uau> google finds it at http://www.mp4ra.org/atoms.html
[13:39:23] <uau> "Defined in/by: ISO"
[13:43:38] <BBB> elenril: you didn't do put_flush_packet() in your avio_ prefix thing
[13:44:46] <mru> uau: ah, it's in an amendment
[13:44:48] * mru downloads
[13:48:35] <elenril> BBB: it doesn't really belong with the other put_* functions
[13:49:06] <elenril> and i think the name is prett confusing and should be changed
[13:49:08] <BBB> why? it takes a ByteIOContext
[13:49:15] <BBB> and it starts with put
[13:49:22] <mru> so the amendment adds a new version of the ctts box with signed offsets
[13:49:42] <mru> but the file we're looking at uses version 0 of that box
[13:49:46] <mru> so it's still unsigned
[13:50:19] <elenril> BBB: the other put_* also take a 'what to put'
[13:51:12] <BBB> right, but you'd expect that
[13:51:30] <BBB> after all, open(2) and close(2) don't take data, but write(2) and read(2) do
[13:51:48] <BBB> and flush is called fflush() for the f*() API, or fdatasync (I believe) for this API
[13:51:56] <BBB> I'd recommend changing it also
[13:51:57] <BBB> it is public
[13:51:59] <BBB> isn't it?
[13:52:25] <elenril> yes, it should be renamed of course
[13:52:29] <elenril> just not in this batch
[13:53:10] <elenril> i'd rename it into something like avio_flush_buffer
[13:53:42] <BBB> hm... ok I guess
[13:56:55] <BBB> just don't forget it :) same for get_strz() did you already submit a patch for that?
[13:57:07] <BBB> if we fix it, I'd like to fix it all, not sort of half-fix it lamely and then forget about it
[13:57:28] <BBB> (i.e. I'm going through your patches now, ideally this is all committed at the same time, so that our API is fixed once-and-for-all[TM] :)
[13:57:58] <BBB> mru: it was already misaligned
[13:58:06] <BBB> mru: MANGLE(..) used to be a function argument
[13:58:10] <BBB> back before that it was aligned
[13:58:17] <BBB> it's misaligned now, and still is after this patch
[13:58:22] <mru> do as you please
[13:58:49] <BBB> ty
[14:01:14] <elenril> BBB: i'll fix it all before the bump ;)
[14:06:48] <mru> http://pastie.org/1582278
[14:06:59] <mru> that makes the file play sanely in ffplay
[14:07:03] <BBB> elenril: going through the patch I'll take a while, it's massive
[14:07:17] <BBB> elenril: I guess I'll have to do them one-by-one because it's way too massively big to all do at once
[14:11:20] <elenril> use the sed luke?
[14:11:26] * elenril did
[14:12:26] <uau> mru: issue419 (which looks like it was the motivation to change the logic from using cslg to the current one) has a comment from bcoudurier saying "File is non standard compliant, negative ctts are not allowed in atom version 0 in mp4."
[14:13:11] <uau> so i guess you could just as well revert r20458 (and break the file from issue419)
[14:14:05] <mru> the dts offset needs to be calculated somehow
[14:14:46] <mru> the cslg box is optional
[14:15:24] <mru> why you'd ever code pts<dts still stumps me though
[14:15:42] <uau> it was apparently changed from using cslg to the current calculation because of a file with version 0 and negative entries
[14:16:21] <uau> so i'd expect your change to break at least the file the current heuristic was originally created for
[14:16:37] <uau> do you think there are other files for which cslg wouldn't work but your code would?
[14:16:54] <mru> any file with negative ctts offets and no cslg
[14:22:51] <mru> the current code is plain wrong
[14:23:13] <mru> it's trivial to construct a file where it does something ridiculous
[14:23:32] <mru> just set a very small timebase
[14:23:52] <mru> so it pushes normal offsets into "negative" range
[14:44:03] <Sean_McG> wow, it failed bootstrap again...fun fun
[14:45:40] <kshishkov> sun sun
[15:23:23] <siretart> BBB: michael has a point. we should be very careful when making some API public. private APIs are (obviously) much easier to fix
[15:23:52] <mru> he has a point, but the way he makes it nobody will want to listen
[15:24:51] <kshishkov> mru: looks like you've worked for a long time with idiots, you should be a bit more tolerant
[15:25:15] <mru> working with idiots makes a man cynical, not tolerant
[15:25:25] <Sean_McG> mru++
[15:25:48] <mru> and I had cynical tendencies even before the idiots...
[15:25:51] <mru> you do the maths
[15:26:12] <siretart> :-)
[15:29:20] <elenril> siretart: basically everything in avio is already de facto public
[15:29:23] <elenril> and widely used
[15:29:29] <michaelni> elenril, where?
[15:29:47] * siretart suspects mplayer
[15:29:56] <michaelni> siretart, good you find insults funny
[15:30:12] <michaelni> about mplayer, it uses internal API
[15:30:22] <elenril> mpd does too
[15:30:25] <michaelni> that doesnt mean we should make it public, should we
[15:30:34] <michaelni> what is mpd?
[15:30:35] <siretart> michaelni: you misread me
[15:30:35] <mru> are the functions useful?
[15:30:41] <mru> if yes, why not make them public?
[15:30:43] <elenril> music player daemon
[15:30:45] <mru> or some variant at least
[15:31:06] <elenril> michaelni: your trolling stopped being amusing long ago
[15:31:25] <elenril> if you have specific suggestions about what should be kept private, i'll listen
[15:31:29] <michaelni> iam not against making them public but that doesnt belong in a "cosmtic" patch
[15:31:39] <elenril> but keep your insults to yourself
[15:31:40] <michaelni> elenril, no, fuck the api up
[15:32:33] <siretart> mru: I think /ignore would have been more appropriate at this point
[15:32:41] <Dark_Shikari> what siretart said.
[15:32:50] * Sean_McG sighs
[15:32:54] <mru> /ignore doesn't solve the problem
[15:33:12] <kshishkov> global /ignore called /ban does ;)
[15:33:33] <mru> I thought I was being nice by only kicking and not banning
[15:33:45] <uau> elenril: hmm how much of avio does mplayer use?
[15:34:26] <uau> demux_lavf uses something
[15:35:20] <elenril> and stream_ffmpeg
[15:35:34] <uau> yes was just looking at stream_ffmpeg
[15:35:40] <uau> that's probably the biggest user
[15:35:50] <uau> it's a 150 line file total though
[15:36:01] <uau> so not particularly hard to change if needed
[15:37:04] <BBB> siretart: which api is non-public?
[15:37:05] <uau> url_open, url_close, url_filesize, url_seek, av_url_read_seek, url_write, url_read_complete
[15:37:18] <uau> BBB: at least those are in installed avio.h
[15:37:28] <kurosu> I don't really see an insult in "fuck <something> up"; I don't know if that's the word, but isn't that "colloquial" language
[15:37:34] <BBB> siretart: because my impression is that all of this is installed and used by mplayer
[15:37:40] <mru> didn't Flameeyes have a list of fuctions used externally?
[15:37:40] <BBB> siretart: which pretty much means public
[15:38:04] <michaelni> i had no intent to insult anyone, i just wanted to point out that i wont/cant stop you from exportung randion functions
[15:38:09] <uau> the above are used in stream_ffmpeg
[15:38:12] <mru> kurosu: in general yes, in this particular case, no
[15:38:19] <wbs> michaelni: i thought all url_*() functions were public already
[15:38:40] <uau> i didn't read that as particularly insulting either
[15:39:05] <kurosu> nevermind anyway, i was not making any case on one or another side
[15:39:44] <elenril> if it's not public than what is it doing in an installed header
[15:39:46] <BBB> michaelni: I agree, we should make stuff public if not necessary
[15:40:02] <BBB> michaelni: unfortunately mplayer and other apps use a lot of this stuff already, and the avio.h header is installed
[15:40:19] <BBB> url_*()/put_*()/get_*() is not under #if HAVE_AV_CONFIG_H or anything
[15:40:26] <BBB> which pretty much implies it's public
[15:40:27] <uau> see also r11086
[15:40:44] <uau> that added av_url_* functions which are pretty much useless without the existing url_ ones i think
[15:41:17] <uau> looks like the idea was to use "right" names for the new functions, with the assumption that the existing functions already were public (even if not correctly named)
[15:41:32] <BBB> so we're "stuck" with av_url_*() as prefix then?
[15:41:34] <BBB> that sucks
[15:41:37] <BBB> I prefer avurl_*()
[15:41:46] <BBB> or anything shorter
[15:42:10] <Sean_McG> doesn't it make it easier for the prefix to have an _ ?
[15:42:19] <elenril> since we're renaming everything else already, renaming the few av_url to avurl_ isn't a big deal
[15:42:20] <michaelni> i greped in mplayer get_be and get_le but i dont think the matches are using the functions from ffmoeg
[15:42:26] <Sean_McG> in terms of regexs and all that?
[15:43:35] <Sean_McG> if you really wanted to make stuff private, you could deprecate it for a version or two
[15:44:03] <BBB> Flameeyes: ping
[15:44:09] <BBB> let's see what flameeyes' list has to say
[15:44:19] <BBB> he had actual, real data on this stuff
[15:44:28] <BBB> i.e. he knows which apps use which symbols
[15:44:34] <uau> get_be/get_le are not used in mplayer
[15:44:35] <Sean_McG> *nod*
[15:45:18] <michaelni> libavformat / codec is optional in mplayer if iam not mistaken so it shouldnt use it outside the wrapers and tiny bits of code depending on libav*
[15:45:47] <uau> michaelni: avio.h is only included in stream_ffmpeg and demux_lavf
[15:46:14] <michaelni> avio.h says at the top that its not allowed to include it directly :)
[15:47:07] <uau> well it's included by avformat.h
[15:47:15] <siretart> BBB: right. well, we can cleanup the names with the 'big bump'
[15:47:56] <mru> whatever that comment says, the things defined in that header are de facto public
[15:48:25] <uau> that comment was added in r17626
[15:48:35] <michaelni> public things have av* prefix if they dont they are not clearly public
[15:48:46] <uau> with commit message "This should prevent its direct inclusion in an external project, which results broken if avformat.h is not included before."
[15:49:01] <mru> that's not true anymore
[15:49:31] <uau> that sounds like it not really being internal, but rather just that it's supposed to be accessed by including avformat.h (which includes it)
[15:49:34] <mru> we've fixed all (?) implicit header dependencies
[15:52:01] <CIA-15> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> master * rbf6fa73245 ffmpeg/libavcodec/x86/dsputil_mmx.c:
[15:52:01] <CIA-15> ffmpeg: dsputil_mmx.c: remove ff_vector128.
[15:52:01] <CIA-15> ffmpeg: Remove ff_vector128, it is identical to ff_pb_80.
[16:38:25] <Flameeyes> BBB: I need to re-generate the data, I'm afraid, but you should have my mails with it
[16:40:29] <BBB> can't find the symbol names, just the project names :(
[16:42:22] <Flameeyes> uhm, okay anyway I'll re-gen the list
[16:43:15] <BBB> thanks
[16:47:34] <Flameeyes> launched; with jruby it shouldn't take much time
[17:10:21] <Flameeyes> two bugfix later, it's still running
[17:15:04] <lu_zero> ^^;
[17:15:07] <lu_zero> meanwhile
[17:15:30] <lu_zero> libxml2 python bindings are a bitch to cross compile =_=
[17:18:33] <CIA-15> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> release/0.5 * rf7494394ee ffmpeg/libavcodec/ (bitstream.h dv.c):
[17:18:34] <CIA-15> ffmpeg: Make get_bits_left() available for use in libavcodec (was previously held
[17:18:34] <CIA-15> ffmpeg: private in dv.c for some reason). See "[PATCH] get_bits_left()" thread.
[17:18:34] <CIA-15> ffmpeg: Originally committed as revision 20490 to svn://svn.ffmpeg.org/ffmpeg/trunk
[17:18:34] <CIA-15> ffmpeg: (cherry picked from commit c47ca25e74bbe465cdc8b99d4f6ab4f0ad5e4229)
[17:18:36] <CIA-15> ffmpeg: Reimar Döffinger <Reimar.Doeffinger at gmx.de> release/0.5 * r8069e2f6fb ffmpeg/libavcodec/vc1.c:
[17:18:36] <CIA-15> ffmpeg: Fix invalid reads in VC1 decoder
[17:18:36] <CIA-15> ffmpeg: Patch discussed and taken from https://roundup.ffmpeg.org/issue2584
[17:18:36] <CIA-15> ffmpeg: (cherry picked from commit 2bbec1eda46d907605772a8b6e8263caa4bc4c82)
[17:18:37] <CIA-15> ffmpeg: Change related to CVE-2011-0723
[17:18:39] <CIA-15> ffmpeg: Kostya Shishkov <kostya.shishkov at gmail.com> release/0.5 * r808f9ce727 ffmpeg/libavcodec/rv34.c:
[17:18:39] <CIA-15> ffmpeg: Call avcodec_set_dimensions() instead of simply setting avctx->width/height
[17:18:39] <CIA-15> ffmpeg: when frame dimensions change in RV3/4.
[17:18:39] <CIA-15> ffmpeg: Originally committed as revision 20595 to svn://svn.ffmpeg.org/ffmpeg/trunk
[17:18:39] <CIA-15> ffmpeg: (cherry picked from commit d90aeeaf569e4a08c30b3d1d09c3cff3a86eb431)
[17:19:58] <Flameeyes> lu_zero: mlt _still_ bundles its own ffmpeg?
[17:20:18] <mru> siretart: planning a new 0.5 release?
[17:20:32] <lu_zero> Flameeyes: I guess...
[17:22:00] <siretart> mru: yes, I want to get 0.5.4 out and start then on 0.6.2
[17:22:24] <siretart> mru: the last open thing I'm aware of is https://roundup.ffmpeg.org/issue2584 (AKA CVE-2011-0723), but that's still unfixed in master
[17:22:57] <siretart> mru: anyway, need to run to my parents-in-law now, cu later/tomorrow
[17:23:10] <lu_zero> siretart: take care =)
[17:23:44] <Flameeyes> uhm I/O error
[17:23:50] <Flameeyes> trying agian
[17:27:59] <BBB> Flameeyes: that's kinda funny
[17:28:03] <BBB> thank for trying so hard :)
[17:30:09] <Flameeyes> elfgrep: /media/tinderbox/opt/scratchbox/compilers/cs2009q1-eglibc2.8-armv7/arm-none-linux-gnueabi/libc/usr/lib/Scrt1.o: Unknown section type 0x70000001 for section .ARM.exidx (Elf::Section::UnknownType)
[17:30:09] <Flameeyes> guh :|
[17:30:21] <Flameeyes> stupid scratchbox
[17:30:25] <BBB> kshishkov: patch on ML for you, I'd appreciate if you could comment on my question there
[17:30:28] <Flameeyes> limiting to /usr instead
[17:30:33] <lu_zero> wbs: poing
[17:30:48] <BBB> kshishkov: in particular, my handling of the if(pq>=9&&overlap)/if(rangeredfrm) parts
[17:32:11] <Jumpyshoes> Dark_Shikari, pengvado, BBB, etc: can i copy x86inc directly without licensing mess? do i need to get approval?
[17:32:25] <BBB> x86inc is BSD
[17:32:27] <BBB> so you can
[17:32:38] <Jumpyshoes> ok
[17:33:40] <Jumpyshoes> uh, should i change the header? aka copyright info
[17:37:14] <lu_zero> why?
[17:37:25] <Jumpyshoes> it's outdated
[17:37:36] <BBB> ?
[17:37:45] <BBB> what do you mean?
[17:37:59] <Jumpyshoes> well it's copyright 2005-2008, should be 2011
[17:38:06] <BBB> it's ok
[17:38:10] <Jumpyshoes> okay
[17:38:18] <BBB> hasn't been changed since then, has it?
[17:38:39] <Jumpyshoes> well, i just changed it for AVX support
[17:40:58] <BBB> ah, then you can, yes
[17:41:02] <BBB> in the same patch :)
[17:41:44] <Jumpyshoes> kk
[17:44:14] <Flameeyes> BBB: http://www.flameeyes.eu/tmp/elfgrep.log
[17:49:25] <Jumpyshoes> derp
[17:49:27] <Jumpyshoes> how do i
[17:49:35] <Jumpyshoes> er, is it possible to enable gpl
[17:49:43] <Jumpyshoes> without distclean
[17:50:19] <elenril> thanks Flameeyes
[17:50:26] <elenril> michaelni: ^
[17:58:44] <BBB> xbmc uses put_buffer and put_byte
[17:58:52] <BBB> also get_buffer
[17:59:10] <BBB> put_be16/32 also
[17:59:19] <BBB> init_put_byte
[17:59:38] <wbs> init_put_byte shouldn't be used, the one that allocates should be used instead
[17:59:55] <BBB> I agree, but I'm just saying what it uses right now
[18:03:30] <elenril> in any case, imo it's sufficient proof that get/put_ should be officially public
[18:04:31] <BBB> elenril: agreed
[18:04:46] <BBB> maybe Michaelni wanted to see which are used and which are not
[18:05:18] <kshishkov> well, they are rather stable too
[18:05:20] <BBB> so we can make some public (get/put_buffer/{be/le}{16,24,32},byte}) but not others (tag, stuff
[18:11:06] <Jumpyshoes> is there a way to update fate samples without cloning the entire thing again
[18:11:38] <Jumpyshoes> and is there any way to set fate samples without having to configure and build again?
[18:11:58] <mru> make SAMPLES=/some/path fate
[18:12:08] <Jumpyshoes> thanks
[18:12:09] <mru> rsync only copies what's changed
[18:12:34] <Jumpyshoes> okay, cool
[18:15:46] <lu_zero> BBB: I'd like to know which ones should be private...
[18:16:22] <BBB> me too
[18:16:32] <BBB> kshishkov: I really need a conformance suite at this point
[18:16:35] <lu_zero> since I'd consider public any one used in a demuxer...
[18:16:46] <lu_zero> btw
[18:17:00] <BBB> lu_zero: well I'm not sure if I agree with it, demuxers are internal
[18:18:12] <lu_zero> BBB: couldn't we register external demuxers?
[18:18:23] <lu_zero> (or codecs)
[18:19:16] <BBB> maybe... but these usually have their own I/O anyway
[18:19:21] <BBB> e.g. libogg, libnut, etc.
[18:20:06] <lu_zero> BBB: When I think about those I try to consider this way:
[18:20:33] <lu_zero> - does it use internal stuff that could/I want randomly change in the future?
[18:21:28] <lu_zero> - could I consider an outside usage for it?
[18:21:58] <lu_zero> anyway
[18:22:19] <lu_zero> I'm thinking about adding a poll function pointer for protos
[18:24:23] <Flameeyes> mru: where can I find the documentation of ELF sections for ARM? seems like glibc's elf.h fails
[18:24:34] <lu_zero> it should be useful since it might lead to factor the polling code for the normal protocols (udp, tcp)
[18:24:36] <kshishkov> BBB: ask merbzt, I told you
[18:24:49] <mru> Flameeyes: infocenter.arm.com
[18:24:56] <Sean_McG> Flameeyes: would ARM's dev si... yeah what mru said
[18:25:01] <mru> there's a section there on ABI stuff
[18:25:09] <BBB> kshishkov: he's offline
[18:25:10] <BBB> :(
[18:25:17] <Flameeyes> mru: thanks
[18:25:41] <mru> Flameeyes: http://infocenter.arm.com/help/topic/com.arm.doc.subset.swdev.abi/index.html
[18:25:44] <kshishkov> BBB: send a mail
[18:25:48] <BBB> I did
[18:25:50] <BBB> no response
[18:25:57] <BBB> and vc1 makes no sense to me
[18:26:02] <BBB> this is outrageous
[18:26:15] <Sean_McG> anyone good at regexes?
[18:26:18] <kshishkov> I hope you fully comprehend ITU H.264 then
[18:26:31] <BBB> kshishkov: I would not in a 1000 years dare make that claim
[18:26:33] <Sean_McG> I need to filter out all lto options from CFLAGS
[18:27:30] <kshishkov> BBB: grab a copy of spec at least
[18:27:38] <BBB> got a link?
[18:27:54] <BBB> (vc1 spec)
[18:28:12] <BBB> hm, gotta go
[18:28:12] <BBB> bbl
[18:28:16] <Sean_McG> I guess what I need to match is: -flto<non-whitespace chars>
[18:28:18] <kshishkov> BBB: http://multimedia.cx/mirror/s421m.pdf
[18:28:46] <roxfan> Flameeyes: what section is an issue?
[18:28:54] <mru> Sean_McG: what flavour of regexes?
[18:29:02] <Sean_McG> bash script
[18:29:07] <mru> non-answer
[18:29:12] <mru> BRE, ERE, Perl, etc?
[18:29:21] <Sean_McG> it's not grep or perl or..
[18:29:25] <mru> what then?
[18:29:44] <roxfan> i don't think bash has built-in regexps
[18:29:50] <Flameeyes> roxfan: mostly found files in scratchbox with section types not listed in the elf.h files I used to set the section type ranges — I don't have time now, but at some point I'll probably add support for parsing those, now that I have the specs ;)
[18:29:51] <Sean_McG> bash variable replacement, currently I'm using ${CFLAGS//-flto/} , but that... OH.
[18:29:52] <roxfan> so you probably need sed or something
[18:29:59] <mru> Sean_McG: that's not a regex
[18:30:02] <Sean_McG> OK... I'll google
[18:30:12] <Flameeyes> it's a glob pattern
[18:30:36] <mru> you can do it with a shell function and a replacement expansion on $@
[18:30:42] <mru> in bash
[18:30:49] <mru> not straight sh
[18:31:03] <Sean_McG> argh...
[18:31:21] * Sean_McG punches Solaris /bin/sh in the junk
[18:31:32] <mru> that one is even worse
[18:31:34] <roxfan> afair there's only a couple of arm-specific sections and i think i've only seen .ARM.exidx in real life
[18:32:00] <roxfan> ah, also .ARM.attributes
[18:32:18] <Sean_McG> anyways, this is for GPAC which I suppose is off-topic here so I'll go poking around some more
[18:32:42] <Flameeyes> roxfan: exidx is the one I was missing
[18:33:40] <mru> ugh, exception unwinding nasties
[18:34:06] <Sean_McG> just another reason that C++ sucks ;)
[18:34:08] <kierank> Sean_McG: lol gpac
[18:34:22] <Sean_McG> kierank: yeah I'm well aware of how it's perceived
[18:34:38] <mru> gpac was responsible for that crazy mp4 file we were looking at earlier today
[18:36:46] <kierank> BBB: do you want a newer vc-1 spec?
[18:37:12] <kshishkov> kierank: it was standardised in 2006 anyway.
[18:37:20] <kierank> there are amendments
[18:37:28] <kshishkov> I would want them
[18:37:35] <kierank> http://dl.dropbox.com/u/2701213/Specs/SMPTE/SMPTE%20Standards/S421m-2006.pdf
[18:37:40] <kierank> http://dl.dropbox.com/u/2701213/Specs/SMPTE/SMPTE%20Standards/S421m-Am1-2007.pdf
[18:37:49] <kierank> all are on the ftp as well now
[18:39:25] <kshishkov> hmm, nothing serious in amendment though
[18:39:29] <kshishkov> that's good
[18:39:49] <elenril> Flameeyes: why am i getting 403 forbidden when trying to download that log
[18:40:09] <Flameeyes> elenril: wait
[18:40:15] <kierank> kshishkov: there are also compliance bitstreams on your nearest bay of pirates
[18:40:46] <Flameeyes> elenril: heh -U 'Pretty please'
[18:41:04] <Flameeyes> I forgot to disable the no-downloaders from my main website :)
[18:41:16] <elenril> heh
[18:41:23] <kshishkov> kierank: I've downloaded them long time ago, but please give a link to BBB
[18:41:32] <kierank> hmmm no seeders left
[18:41:34] <kierank> ah well
[18:46:29] <elenril> Flameeyes: i'll send a copy of it to the ml
[18:46:37] <Flameeyes> elenril: sure
[18:47:15] * elenril watches a cascade of conflicts
[18:47:26] <elenril> BBB: this is why i want them applied gradually ;)
[20:26:30] <Yuvi> Dark_Shikari: sorry, fell asleep
[20:26:30] <Yuvi> mru: ctts in .mov is allowed to be (and often is) negative
[20:26:30] <Yuvi> ISO 14496-12 defines the entries in ctts as a non-negative int(32)
[20:27:14] <mru> wrong
[20:27:46] <mru> isom ctts v0 is unsigned
[20:27:55] <mru> ctts v1 is signed
[20:28:12] <_av500_> kshishkov: btw, our players play .rcv
[20:28:12] <mru> but why the hell would you ever use a negative value?
[20:28:45] <_av500_> kshishkov: i wanteds to add it to ff then i saw you did thatalready :)
[20:28:58] <Yuvi> to get a pts of 0 in a cfr track w/ reordering
[20:29:18] <Yuvi> since dts can't be negative in either mov or mp4
[20:29:26] <mru> ah
[20:29:34] <mru> but why is pts of zero so important?
[20:29:51] <mru> just set a non-zero first pts for audio as well
[20:29:52] <_av500_> its the pts of the big bang
[20:31:33] <Yuvi> quicktime didn't show the first frame if pts was >0 when you opened a file (since it starts paused at 0
[20:31:57] <kierank> never really understood why mp4 didn't take vbv into consideration
[20:32:01] <kierank> like mpegts
[20:32:21] <kierank> so the first dts would never be zero
[20:32:47] <kshishkov> _av500_: make them play .ivf as well
[20:33:04] <kierank> dear Yuvi fix quicktime aac encoder bug. kthxbye
[20:33:18] <_av500_> kshishkov: when i am bored enough
[20:33:21] <Yuvi> kierank: totally not my area :P
[20:33:34] <_av500_> kshishkov: i even invented rcrv for real video testing
[20:34:03] <kierank> I wonder if I could release a binary patch to quicktime's aac encoder
[20:34:05] <kierank> that might work
[20:34:25] <_av500_> kierank: via the itunes store?
[20:34:44] <kierank> lol
[20:34:47] <_av500_> youd get 70%
[20:34:52] <kierank> 70% what?
[20:35:06] <_av500_> kierank: apple users pay for sw
[20:38:08] <kierank> I wonder if apple will accept bugfixes in the app store
[20:38:11] <kierank> probably will be rejected
[20:38:24] <kierank> and knowledge of the bug denied
[20:48:58] <lu_zero> yawn
[20:53:31] <_av500_> +1
[20:55:35] <lu_zero> michaelni: do you enjoy insulting people?
[20:55:53] <michaelni> lu_zero, what?
[20:56:26] <lu_zero> and that probably is the N-th time I tell you.
[20:57:07] <michaelni> is the truth an insult to you?
[20:59:03] <lu_zero> michaelni: I could say that you are particular and you should balance your opinion and try to deliver your concerns in a more proper way
[20:59:06] <lu_zero> OR
[20:59:30] <lu_zero> I COULD STATE THAT YOU ARE A FUCKING PRICK AND YOU SHOULD JUST SHUT THE HELL UP INSTEAD OF SPOUTING NONSENSE
[20:59:43] <lu_zero> I think you could tell the difference
[20:59:44] <mru> lu_zero: calm down
[21:00:15] <lu_zero> you usually are closer to the latter tone
[21:01:09] <mru> also, attaching a "btw, you suck" at the end of every message isn't very polite either
[21:01:28] <mru> even if the main part of the message wasn't directly insulting
[21:01:57] <mru> now about what's public api
[21:02:06] <mru> it doesn't really matter what is actually used
[21:02:28] <mru> even things not currently (to our knowledge) used can still make sense being public
[22:25:19] <Jumpyshoes> BBB, mru, Dark_Shikari, etc: any comments to the avx patch besides i can't test for speed atm? (http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2011-February/107514.html)
[22:26:39] <BBB> michaelni: I think what would help is that instead of complaining, you propose constructive solutiobs
[22:27:06] <BBB> michaelni: for example, your point of view is probably (please confirm) that we should split avio.h into public and private API, or even make all of it private
[22:27:34] <BBB> although I think stuff like ByteIOContext should be public, as should av_alloc_put_byte()
[22:27:41] <BBB> the rest can possibly be private
[22:28:18] <BBB> ByteIOContext, if public, needs a AV prefix also
[22:28:28] <BBB> like AVIOContext or AVByteIOContext
[22:29:50] <BBB> kshishkov: not getting any replies from sweden today - any other sources for vc1 conformance suite?
[22:31:44] <Flameeyes> BBB: it's fun.. microsoft's license on their specs is actually an acceptable one :P
[22:53:32] <CIA-15> ffmpeg: Marton Balint <cus at passwd.hu> master * r74d6871d62 ffmpeg/libavformat/mms.c:
[22:53:32] <CIA-15> ffmpeg: MMS: also discover streams in extended stream properties object
[22:53:32] <CIA-15> ffmpeg: Allows playback of nonprimary audio streams in multiple bitrate sources,
[22:53:32] <CIA-15> ffmpeg: such as mmsh://wmscr1.dr.dk/e02ch03m
[22:53:33] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[22:57:48] <j-b> this code looks quite like vlc's
[22:58:13] <mru> j-b: implying something?
[22:58:26] <j-b> no
[22:58:52] <j-b> just http://git.videolan.org/?p=vlc.git;a=commitdiff;h=dd3d1962db04a7d2c5e790056edc986ed527ec34
[22:59:21] <j-b> might be just following  the spec :)
[23:01:40] <iive> j-b: aren't both from same author?
[23:02:50] <BBB> wtf smpte 421 is like $400
[23:03:02] <michaelni> BBB, iam not against making all/most of avio.h public but iam against that this is done without reviewing each function one by one to make sure we want it to be public and that we understand the ABI issues we might have due to it
[23:03:11] <j-b> iive: yes, exactly
[23:03:17] <BBB> michaelni: now that sounds a lot nicer, great work!
[23:03:32] <BBB> michaelni: which ones would you like to see/not see exposed specifically?
[23:03:53] <ohsix> is it a form of bikeshedding to insist someone explain something a certain way
[23:04:40] <kierank> is it a form of bikeshedding to decide what bikeshedding means
[23:04:45] <michaelni> i think one question we should awnser first is if we want demuxers written outside to use this API
[23:05:02] <mru> ohsix: asking people not to be excessivly rude and insulting is not bikeshedding
[23:05:03] <michaelni> there are good argumebts for either way ...
[23:05:05] <ohsix> how do you name it without a definition, at best without one it acts as a pejorative
[23:05:29] <BBB> michaelni: well, so my take on it is that put/get is a wrong prefix
[23:05:35] <BBB> michaelni: internal is ff, otherwise it's av
[23:05:38] <michaelni> yes
[23:05:40] <BBB> michaelni: so we have to rename it either way
[23:05:43] <michaelni> yes
[23:05:43] <BBB> so let's do it right :)
[23:05:52] <BBB> I would hate to do a mass-commit twice
[23:05:56] <BBB> waste of my time (and yours)
[23:06:10] <michaelni> 3sec cherrypick
[23:06:14] <michaelni> ill survivie it
[23:06:20] <mru> possibly some functions should be made public in a slightly different form
[23:06:22] <BBB> yeah, well, I have to review the patch
[23:06:43] <BBB> so, do you want this api public? I don't care either way tbh
[23:06:53] <BBB> as long as AVByteIOContext and av_alloc_put_byte() are public
[23:06:58] <BBB> quite some apps use these 2
[23:07:04] <BBB> to hook into lavf demuxers
[23:07:07] <BBB> using their own i/o
[23:07:15] <mru> so it's obviously useful
[23:07:44] <mru> if the current interface is unsuitable to export, we should export the same functionality in a better way
[23:08:08] <BBB> I'm open to proposals
[23:08:15] <BBB> the api itself seems fine to me
[23:08:24] <BBB> whether to export it is indeed a different question
[23:08:41] * BBB can't find a free copy of the vc1 specs
[23:08:50] <mru> if the api is ok as is, there's no reason to make it private
[23:08:53] <kierank> BBB: I posted them above
[23:09:03] <BBB> oh
[23:09:05] <BBB> lemmesee
[23:09:42] <BBB> kierank: you have the testsuite also?
[23:09:49] <kierank> nope
[23:09:59] <kierank> only a document which describes the testsuite ;)
[23:10:38] <michaelni>  /* not implemented */
[23:10:42] <michaelni> url_poll() ;)
[23:11:01] <mru> url_poll() is useless
[23:11:15] <mru> more useful would be a way to get at the underlying fd
[23:11:31] <michaelni> url_get_file_handle() ?
[23:11:35] <mru> and feed it to poll together with unrelated fds the app might have for other reasons
[23:11:48] <michaelni> which needs better docs IMHO
[23:12:23] <mru> ah, it already exists
[23:13:14] <michaelni> extern URLInterruptCB *url_interrupt_cb;
[23:13:35] <michaelni> wasnt there some issue with globals ...
[23:14:28] <mru> globals are evil
[23:15:04] <michaelni> they are usefull in small programs but here i agree
[23:15:32] <lu_zero> mru: would be nicer not have a poll on every write or read call ^^;
[23:16:05] <mru> lu_zero: either you use blocking i/o or you use poll
[23:16:45] <mru> doing a poll/read loop that emulats a blocking read is of course silly
[23:16:54] <michaelni> I think the ByteIOContext and URLContext stuff should be put in 2 seperate headers
[23:17:08] <mru> avurl.h?
[23:17:17] <michaelni> whatever you prefer
[23:18:33] <michaelni> and all functions should be documented (except trivial ones)
[23:20:33] <BBB> lu_zero: that can be another URLContext flag
[23:20:38] <BBB> lu_zero: caller_will_poll_flag or so
[23:20:40] <michaelni> URLContext *url_fileno(ByteIOContext *s); <-- no docs
[23:20:46] <ohsix> uri?
[23:20:48] <BBB> lu_zero: also useful for rtsp
[23:20:55] <lu_zero> BBB: indeed ^^;
[23:22:06] <michaelni> int udp_set_remote_url(URLContext *h, const char *uri);
[23:22:13] <michaelni> somehow that looks ugly in there
[23:23:31] <michaelni> Also important is that all structs avio.h needs have allocator functions so we can add fields withiut ABI issues
[23:23:47] <BBB> udp_set_remote_url() is strictly internal
[23:24:00] <michaelni> good we agree
[23:24:12] <michaelni> theres a second udp_ function too
[23:24:13] <BBB> might need to move to udp.h
[23:24:20] <BBB> lu_zero: can you fix that? :)
[23:25:22] <michaelni> URLPollEntry is only used by url_poll()
[23:25:45] <BBB> function and struct need to die
[23:25:50] <BBB> elenril had patches to deprecate them
[23:25:57] <BBB> we can also just remove them
[23:27:24] <michaelni> url_is_streamed() looks useless
[23:27:39] <michaelni> ist just return s->is_streamed
[23:30:19] <michaelni> The structs look fine to me
[23:30:37] <BBB> structs = URLContext/ByteIOContext?
[23:30:39] <BBB> yeah, they're fine
[23:30:47] <michaelni> and URLProtocol
[23:30:51] <iive> is the struct public?
[23:30:51] <BBB> URLContext and url_*(): internal or extenral?
[23:31:02] <BBB> I don't think URLContext has any clear use on the outside
[23:31:18] <BBB> URLProtocol indeed also
[23:32:20] <iive> if struct is not public, and it is not recommended to be read directly, then you need functions to do that for you.
[23:32:48] <BBB> we don't have private structs with public API, afaics
[23:33:00] <BBB> unless you count things like AVFormat/CodecContext->priv_data
[23:34:48] <mru> and in other news, armcc outdoes itself with another botched loop unrolling
[23:35:03] <mru> this time it segfaults if called with a count of zero
[23:36:17] <michaelni> BBB, if you want to implement URLProtocols outside, i think you need URLContext
[23:36:41] <BBB> hm
[23:36:45] <BBB> oh right gstreamer does that
[23:36:47] <BBB> ugh
[23:36:56] <michaelni> mplayer did in the past too
[23:36:57] <thresh> kshishkov: heard of KBR & Elbrus stuff? :(
[23:36:59] <BBB> do we want to keep supporting that?
[23:37:09] <BBB> where's bilboed when you need him
[23:37:16] <michaelni> ive no strong oppinon either way
[23:37:32] <mru> thresh: the elbrus name always cracks me up
[23:37:39] <mru> thresh: do you know what that means in swedish?
[23:37:43] <thresh> mru: nope
[23:37:47] <mru> electrical noise
[23:37:57] <thresh> heh
[23:38:04] <mru> so apt
[23:38:24] <thresh> anyway, 3 tourists killed & ropeway blasted there. friends of mine are going home from that place tomorrow...
[23:38:45] <thresh> others cancel their tickets on vacations out there
[23:39:46] <mru> "there"?
[23:39:56] <thresh> in Caucasus
[23:40:06] <Flameeyes> lu_zero: ping
[23:40:31] <thresh> KBR stands for http://en.wikipedia.org/wiki/Kabardino-Balkaria
[23:41:02] <BBB> yeah gst still does that
[23:41:04] <BBB> that's not good
[23:41:27] <BBB> michaelni: I'd say we should promote people to not do that, the ByteIOContext* method is easier
[23:41:38] <BBB> and has less overhead anyway
[23:41:57] <BBB> let's make URL* and url_*() private (so ff_url_*() for functions, struct stays at it is)
[23:42:29] <BBB> michaelni: then make ByteIOContext public, AVByteIOContext, along with av_alloc_put_byte() which was already public
[23:42:43] <BBB> michaelni: as for the get/put_*() functions, there is some use, see ML, let's see if we want to support that
[23:42:59] <BBB> I might argue that stuff is better implemented inside lavf, e.g. a dvd player, would be nice to support
[23:43:30] <mru> some things are still better done outside
[23:44:10] * michaelni is always in favor of keeping things private if possible as its easy to make things public but hard the other way around
[23:44:40] <BBB> mru: well then again, all it uses it for is for writing out nals and an avcc atom
[23:44:47] <mru> true, but here we're dealing with things that are public, if by accident
[23:45:07] <mru> BBB: I wasn't talking about any specific case
[23:45:15] <BBB> fair enough
[23:46:43] <BBB> elenril: ping
[23:47:03] <BBB> elenril: let's start at the easy stuff, can you post a patch that renames ByteIOContext to AVByteIOContext? at least that one everyone agrees on
[23:58:54] <mmu_man> hmm I don't suppose mpeg2 TS allows the cat trick like PS, does it ?
[23:59:00] <mmu_man> the one on http://ffmpeg.org/faq.html#SEC27
[23:59:19] <mmu_man> oh well, I need to cut anyway, I can always remux to PS