[Ffmpeg-devel-irc] ffmpeg-devel.log.20120304

[burek]

[00:33] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * rcd0cfdc0a7 10ffmpeg/libavcodec/pcm-mpeg.c: 
[00:33] <CIA-17> ffmpeg: pcm-mpeg: Check for valid bps.
[00:33] <CIA-17> ffmpeg: The code only supports 16 and 24 bps currently, 20bps causes
[00:33] <CIA-17> ffmpeg: out of array reads.
[00:33] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[00:33] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:33] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r8f1bb3d598 10ffmpeg/libavcodec/xxan.c: 
[00:33] <CIA-17> ffmpeg: wc4: fix out of chroma LUT reads
[00:33] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[00:33] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:33] <CIA-17> ffmpeg: 03Rick van der Zwet 07master * rd33a091cb3 10ffmpeg/ffmpeg.c: 
[00:33] <CIA-17> ffmpeg: ffm options should also set discard automatically.
[00:33] <CIA-17> ffmpeg: commit 13f6917ca91dfdc0fd785235b2dae891a9604859 handles discards automatically,
[00:33] <CIA-17> ffmpeg: but the ffm discard options are not fully parsed. Causing the input streams not
[00:33] <CIA-17> ffmpeg: to be used, so no stream towards the ffserver after the initial probing.
[00:46] <CIA-17> ffmpeg: 03Carl Eugen Hoyos 07master * rf972193a15 10ffmpeg/libswscale/ (input.c utils.c): 
[00:46] <CIA-17> ffmpeg: Support RGBA64 as input colour space.
[00:46] <CIA-17> ffmpeg: Mostly fixes ticket #503,
[00:46] <CIA-17> ffmpeg: opaque still overflows for RGBA64 -> RGBA conversion.
[01:05] <rickk> is bigendian used in the network packet?
[01:05] <rickk> all the time?
[01:05] <kierank> yes
[01:05] <kierank> very common
[01:06] <rickk> is there a reason for that?
[01:06] <rickk> I was making PTS into mpeg ts. 
[01:07] <rickk> It took many ours to find out how to put the numbers..
[01:07] <rickk> hours*
[01:08] <rickk> starting floating point and double..
[01:08] <rickk> very confusing
[01:08] <kierank> don't use floats
[01:08] <kierank> why are you writing a mux anyway
[01:09] <rickk> just for study..
[01:10] <kierank> i wrote one from scratch
[01:14] <rickk> is there a better way to create a pts rather than like "pts = (1000 / 30) * 90 * (frame_count++);"
[01:14] <rickk> It is hard to find the pts code in the ffmpeg
[01:16] <kierank> bit of a bizzare way of doing it
[01:19] <rickk> I thought so..
[02:05] <Daemon404> [19:06] < rickk> is there a reason for that? <-- tons of network hardware is mips or ppc :P
[02:05] <Daemon404> or telco hw
[02:05] <rickk> oh i c
[02:12] <ubitux> Daemon404: feel free to send your patches with -M
[02:13] <ubitux> so the rename like you did with libutvideo.c ’ libutvideodec.c will be more obvious
[02:13] <ubitux> also mentioning it in the description would be welcome
[02:14] <ubitux> btw, you have a typo: deps ’ derps
[02:14] <ubitux> (i mean the contrary)
[02:14] <ubitux> well, i guess i'll write a review
[02:18] <Daemon404> oh
[02:18] <Daemon404> yes i wondered that
[02:18] <Daemon404> i didnt realize tehre was an option to make git less dumb
[02:21] <Daemon404> ubitux, i see a few typos
[02:21] <Daemon404> ill fix them once reviewed
[02:31] <ubitux> s/precision/prediction/ of course
[02:31] <ubitux> time for me to sleep
[02:32] <ubitux> 'night ppl
[02:36] <Daemon404> nn
[02:37] <Daemon404> I need to figure out how to get thunderbird to stop crapping all over quoted code
[02:37] <Daemon404> and moving symbols and spaces around
[02:41] <ohsix> it messes with things even if you use a plain text format?
[02:41] <Daemon404> yup
[02:41] <Daemon404> lemme make a screenshot
[02:41] <Daemon404> or well :Effort:
[02:41] <Daemon404> but it will take say
[02:41] <Daemon404> (a & 1)
[02:42] <Daemon404> and make it (a& 1)
[02:42] <Daemon404> same for most all operators
[02:54] <ohsix> ah, maybe sloppy quoting, or doing html shits for plain messages
[03:05] <Daemon404> ohsix, likely.
[03:05] <Daemon404> thunderbird has a lot of insane defaults.
[04:47] <CIA-17> ffmpeg: 03Alex Converse 07master * r1aa708988a 10ffmpeg/libavformat/mpegts.c: 
[04:47] <CIA-17> ffmpeg: mpegts: Pad the packet buffer in handle_packet().
[04:47] <CIA-17> ffmpeg: This allows it to be used with get_bits without the thread of overreads.
[04:47] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[04:47] <CIA-17> ffmpeg: CC: libav-stable at libav.org
[04:47] <CIA-17> ffmpeg: 03Anton Khirnov 07master * r7fb6c9225c 10ffmpeg/libavcodec/ (avcodec.h utils.c): lavc: free the output packet when encoding failed or produced no output.
[04:47] <CIA-17> ffmpeg: 03Justin Ruggles 07master * r737ca4482b 10ffmpeg/libavcodec/vorbisdec.c: 
[04:47] <CIA-17> ffmpeg: vorbisdec: read the previous window flag for long windows
[04:47] <CIA-17> ffmpeg: When reading sequentially, we are using the actual flag from the previous
[04:47] <CIA-17> ffmpeg: frame, but when seeking we do not know what the previous window flag was, so
[04:47] <CIA-17> ffmpeg: we need to read it from the bitstream.
[04:47] <CIA-17> ffmpeg: 03Anton Khirnov 07master * re42e9b0e4d 10ffmpeg/libavcodec/utils.c: 
[04:47] <CIA-17> ffmpeg: lavc: preserve avpkt->destruct in ff_alloc_packet().
[04:47] <CIA-17> ffmpeg: Also, don't bother with saving/restoring data, av_init_packet doesn't
[04:47] <CIA-17> ffmpeg: touch it.
[04:47] <CIA-17> ffmpeg: 03Justin Ruggles 07master * r5a9b952201 10ffmpeg/libavformat/thp.c: thp: set audio packet durations
[04:48] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r6776a8f189 10ffmpeg/libavcodec/mpegaudio_parser.c: 
[04:48] <CIA-17> ffmpeg: mpegaudio_parser: be less picky about the start position
[04:48] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[04:48] <CIA-17> ffmpeg: Signed-off-by: Justin Ruggles <justin.ruggles at gmail.com>
[04:48] <CIA-17> ffmpeg: 03Justin Ruggles 07master * r5602a464c9 10ffmpeg/ (9 files in 2 dirs): 
[04:48] <CIA-17> ffmpeg: avcodec: add a Vorbis parser to get packet duration
[04:48] <CIA-17> ffmpeg: This also allows for removing some of the Vorbis-related hacks.
[04:48] <CIA-17> ffmpeg: 03Justin Ruggles 07master * r0b8b7db01b 10ffmpeg/ (4 files in 3 dirs): 
[04:48] <CIA-17> ffmpeg: mpegaudio_parser: do not ignore information from the first parsed frame
[04:48] <CIA-17> ffmpeg: Update some demuxing and seeking fate tests.
[04:48] <CIA-17> ffmpeg: 03Justin Ruggles 07master * r101c369b7c 10ffmpeg/libavformat/tta.c: tta demuxer: set packet duration
[04:48] <CIA-17> ffmpeg: 03Justin Ruggles 07master * rd0ab585074 10ffmpeg/ (libavformat/vqf.c tests/ref/fate/vqf-demux): 
[04:48] <CIA-17> ffmpeg: vqf: set packet duration
[06:37] <zamb> Hi everybody... Could someone double-check cd0cfdc0a74cbf45f0d00b65faaf3cf5bd93c016, please. It doesn't look right.
[06:52] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r39a3a53b66 10ffmpeg/libavcodec/pngdec.c: 
[06:52] <CIA-17> ffmpeg: pngdec: validate length.
[06:52] <CIA-17> ffmpeg: Fixes out of array reading.
[06:52] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[06:52] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[08:34] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r2b693546ad 10ffmpeg/libavcodec/truemotion2.c: 
[08:34] <CIA-17> ffmpeg: truemotion2: check motion vectors for validity
[08:34] <CIA-17> ffmpeg: Fixes out of array read
[08:34] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[08:34] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[08:54] <CIA-17> ffmpeg: 03Ronald S. Bultje 07master * r999d38f3a9 10ffmpeg/libavcodec/dsicinav.c: 
[08:54] <CIA-17> ffmpeg: dsicinvideo: validate buffer offset before copying pixels.
[08:54] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[08:54] <CIA-17> ffmpeg: CC: libav-stable-LOOeJiBropLYtjvyW6yDsg at public.gmane.org
[08:54] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[09:01] <nevcairiel> michaelni: you should re-check cd0cfdc0, the condition you build there is backwards and breaks all files except 20-bit. :d
[09:19] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r37fca5daa0 10ffmpeg/libavcodec/mmvideo.c: 
[09:19] <CIA-17> ffmpeg: mmvideo: fix overreads of the input buffer.
[09:19] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[09:19] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[12:17] <ubitux> http://lucy.pkh.me/dmesg.log srsly :(
[12:17] <ubitux> second time in a row i get a crappy machine :p
[12:18] <kierank> poor ubitux :(
[12:19] <ubitux> :(
[12:33] <CIA-17> ffmpeg: 03Stefano Sabatini 07master * r409a3bda07 10ffmpeg/ (6 files in 3 dirs): 
[12:33] <CIA-17> ffmpeg: lavfi: add blackdetect filter
[12:33] <CIA-17> ffmpeg: Address trac ticket #901.
[13:45] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r4a9f466b99 10ffmpeg/libswscale/output.c: 
[13:45] <CIA-17> ffmpeg: Fix alpha overflow when converting from RGBA64 to RGBA.
[13:45] <CIA-17> ffmpeg: Fixes converting the sample from ticket #503 to 32bit RGB.
[13:52] <ubitux> http://upstream-tracker.org/index.html  can anyone explains to me wtf is going on with the end of the graph? :))
[14:00] <Compn> ubitux : obviously they went back in time
[14:01] <ubitux> :D
[14:03] <ubitux> i hope ffmpeg is able to handle time travel api breakage
[14:06] <ubitux> saste: ping
[16:43] <michaelni> nevcairiel, thanks, ive fixed it locally, will push in a moment
[16:46] <ubitux>                 if (frame.pts == AV_NOPTS_VALUE)
[16:46] <ubitux>                     frame.pts = frame.pkt_dts == AV_NOPTS_VALUE ?
[16:46] <ubitux>                         frame.pkt_dts : frame.pkt_pts;
[16:46] <ubitux> this looks wrong to me
[16:46] <ubitux> can anyone confirm?
[16:47] <ubitux> the condition seems inverted
[16:53] <michaelni> ubitux, from where is that ?
[16:54] <ubitux> filtering_video.c
[16:54] <ubitux> (doc/examples)
[16:54] <ubitux> is that necessary anyway?
[16:55] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r52807022ab 10ffmpeg/libavcodec/pcm-mpeg.c: 
[16:55] <CIA-17> ffmpeg: pcm-mpeg: fix 10l condition flip
[16:55] <CIA-17> ffmpeg: Original issue Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[16:55] <CIA-17> ffmpeg: 10l bug Found-by: nevcairiel
[16:55] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:03] <michaelni> ubitux, probably it should use *(int64_t*)av_opt_ptr(avcodec_get_frame_class(), frame, "best_effort_timestamp");
[17:14] <ubitux> why isn't this done internally?
[17:15] <ubitux> afaiu, frame has pkt_dts and pkt_pts, which is the "real" decoded data, and also a pts value for the end user
[17:15] <ubitux> so why does the user need some extra heuristic with best_effort_timestamp instead of just use a corrected frame.pts value?
[17:32] <michaelni> ubitux, frame.pts is the decoder bitstream timestamp if there is one
[17:33] <michaelni> frame.best_effort_timestamp is what it says it is
[17:36] <michaelni> that is until someone from libav fixes it, after that it will be random nonsense
[17:39] <michaelni> the choice that frame.pts is a decoder layer specific thing was maybe not ideal, it should ideally be renamed probably
[17:39] <michaelni> but then AVFrame is a decoder layer specific structure
[17:39] <Compn> michaelni : did you ever see this huge description of yadif? https://trac.handbrake.fr/wiki/yadif
[17:41] <ubitux> michaelni: ok&
[17:42] <ubitux> Compn: i'm curious how these graphics are generated
[17:42] <ubitux> looks like a graphviz++
[17:42] <Compn> so am i, maybe mike would like to know too
[17:42] <Compn> melanson, always the graph nerd ;)
[18:27] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * rd8d1fbbd7f 10ffmpeg/libavcodec/dsicinav.c: 
[18:27] <CIA-17> ffmpeg: dsicinav: fix 10l bug introduced in 999d38f3a94eb963c073512e5dad7940456eb634
[18:27] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:43] <ubitux> Daemon404: i think Paul is concerned about the fact that assignment to avctx->coded_frame->key_frame is conditionnal, while pkt->flags |= AV_PKT_FLAG_KEY isn't
[19:43] <Daemon404> oh
[19:43] <Daemon404> good point
[19:44] <Daemon404> tbh
[19:44] <Daemon404> the api for keyframe
[19:44] <Daemon404> is useless
[19:44] <Daemon404> it alwas gets set to 1
[19:44] <Daemon404> every single time.
[19:44] <ubitux> i guess a comment or something would be welcome :)
[19:44] <Daemon404> i just thought i ought to use what teh api provides
[19:44] <Daemon404> but it is indeed pointless
[19:45] <ubitux> isn't it supposed to make a distinction between key frames and intra frames?
[19:46] <Daemon404> ubitux, ut video is entirely intra
[19:46] <Daemon404> and eveyr frame is a keyframe.
[19:49] <ubitux> i don't have enough knowledge on the subject, but couldn't we have a codec with intra only but sparse key frames? (to help long seeking or sth) 
[19:51] <ubitux> and thus the libutvideo could raise a keyframe sometimes because "hey this one is an interesting key point for seeking"
[19:53] <ubitux> Daemon404: am i saying total nonsense?
[19:53] <Daemon404> even if that were possible
[19:53] <Daemon404> libutvideo does not do this
[19:54] <Daemon404> i mean
[19:54] <Daemon404> an intra frame is as good a place to seek as anything
[19:54] <Daemon404> no intra frame will be 'better' than others
[19:54] <Daemon404> i think the point of the keyframe flag is for codecs like h.264
[19:54] <Daemon404> where you have I and IDR frames
[19:55] <Daemon404> which have different guarantees for farmes that come after it
[19:56] <ubitux> libutvideo may not do this at the moment, but could in a later update; since you assume it is always set, maybe you should raise a warning when it isn't, and set key frame and flag key inconditionally
[19:56] <Daemon404> no it cant.
[19:56] <Daemon404> not unless it gets intere frames too
[19:56] <Daemon404> inter*
[19:56] <ubitux> <+Daemon404> an intra frame is as good a place to seek as anything // what if the concern is to have a small index?
[19:56] <Daemon404> i guess thats plausible
[19:56] <Daemon404> i have never ever seen such a thing in practice
[19:57] <Daemon404> for intra-codecs
[19:57] <ubitux> why "it can't"?
[19:57] <ubitux> if you think it will never change, you could add an assert then
[19:57] <Daemon404> i know teh ut video author personally. 
[19:58] <ubitux> that might change in the future ;)
[19:58] <Daemon404> ut video is solely a intra-only codec
[19:58] <ubitux> some project takeover or something :-°
[19:58] <Daemon404> slice-based
[19:58] <Daemon404> ... it's a personal project
[19:58] <Daemon404> one guy
[19:58] <ubitux> then what was the point of the key frame flag?
[19:58] <Daemon404> it's a VCM thing
[19:58] <ubitux> what if the codec evolve to non-intra at some point (let's say a few years)
[19:58] <Daemon404> it's requried by VCM iirc
[19:58] <Daemon404> to have such a function
[19:59] <ubitux> if the key_frame is supposed to be always 1, i think it's better not to have conditionnal code for this
[19:59] <Daemon404> OK
[19:59] <Daemon404> also
[19:59] <ubitux> so av_assert it, ignore it, or add a warning if it is
[19:59] <Daemon404> if ut-video goes inter
[19:59] <ubitux> eventually with a codec
[19:59] <Daemon404> ill have a lot more to change than that one line
[19:59] <Daemon404> so i dont see an issue
[19:59] <ubitux> s/codec/comment/ her.
[19:59] <ubitux> ok
[20:00] <ubitux> then better make sure this code is going to work in the next decade :P
[20:00] <ubitux> imho :)
[20:00] <Daemon404> ;p
[20:00] <Daemon404> this reminds me
[20:00] <Daemon404> i have like 3 things to fix in configure
[20:00] <Daemon404> regarding C++ support
[20:01] <Daemon404> it explodes with teh touch of a feather atm
[20:02] <ubitux> can't comment on c++ stuff, as you already realized :)
[20:02] <Daemon404> :P
[20:02] <Daemon404> i dont liek c++ myself.
[20:03] <Daemon404> i just ported the asm code to work properly on linux ofr libutvideo, and must send it upstream
[20:03] <Daemon404> but it relied on some arcane c++ evil that didnt work when linked as an external lib to init it
[20:07] <ubitux> maybe it would be wise to write a native encoder?
[20:07] <Daemon404> i am :P
[20:07] <ubitux> :)
[20:07] <Daemon404> but using the reference is nice too
[20:07] <Daemon404> cause it has asm alrady done
[20:08] <Daemon404> and slice-basedm ultitrheading
[20:09] <ubitux> too bad the author is blogging in japanese :(
[20:10] <Daemon404> he speeks rudimentary english
[20:10] <Daemon404> there's #UtVideo on freenode
[20:11] <ubitux> what's the benefit of this codec over the range of other more widespread ones?
[20:11] <Daemon404> speed/median compression really. it's really just a slice-based huffy
[20:11] <Daemon404> median prediction + huffman encode
[20:11] <Daemon404> with some tweaks
[20:12] <Daemon404> it can be beaten, and marc fd has.. which im supposed to be implementing
[20:12] <ubitux> ok
[20:12] <Daemon404> (ffv1-level compression, huffy speeds)
[20:12] <ubitux> do you know how much it's in use?
[20:12] <Daemon404> the entire anime communicty
[20:13] <Daemon404> er, community
[20:13] <ubitux> seriously? :)
[20:13] <Daemon404> lol yea
[20:13] Action: Daemon404 is one of those "anime people"
[20:13] <ubitux> it looks pretty recent though
[20:13] <ubitux> what was used before?
[20:13] <ubitux> h264 lossless?
[20:13] <Daemon404> it came into popularity teh last few years
[20:14] <Daemon404> before that most used ffvhuffy
[20:14] <Daemon404> or... ugh... lagarith (ugh)
[20:16] <ubitux> is ffvhuff used outside ffmpeg?
[20:16] <ubitux> reimplemented in another encoder or something?
[20:16] <Daemon404> no
[20:16] <Daemon404> ffdshow vfw
[20:16] <Daemon404> lol.
[20:17] <JEEB> yeah, ffdshow(-tryouts)'s vfw interface let you use ffvhuff
[20:18] <Daemon404> mind you
[20:18] <Daemon404> i always used ffmpeg itself
[20:18] <Daemon404> then i had to go back to vfw for utvideo...
[20:19] <JEEB> I remember trying either ffmpeg or mencoder
[20:19] <JEEB> and ending up with a 30GB avi that really didn't work that well
[20:19] <JEEB> vdub's avi muxer was <3
[20:21] <Daemon404> JEEB, lol
[20:21] <Daemon404> i always used avimuxgui
[20:41] <Daemon404> ubitux, think i should wait for pauls reply?
[20:43] <ubitux> it doesn't cost anything to resend your patch :)
[20:43] <Daemon404> lol
[20:50] <pasteeater> Daemon404: thanks for working on this. i might use it as a intermediate for the windows guys here who were too lazy to figure out how to get huffyuv.
[20:51] <Daemon404> lol
[20:51] <Daemon404> pasteeater, mingw-built ut video wont work with its asm optimizations without a patch i wrote to utvideo
[20:51] <Daemon404> but thats it
[20:51] <pasteeater> ...as in they can install the exe from the author, and i'll just use ffmpeg.
[20:51] <Daemon404> ah
[20:52] <Daemon404> lol.
[20:52] <Daemon404> what no "enterprise" formats?
[20:52] <Daemon404> liek mxf and shit
[20:52] <pasteeater> i'm not enterprise enough yet, but when i am i'll buy a $25k device to do that.
[20:52] <pasteeater> trolololol
[20:53] <Daemon404> lol
[20:53] <Daemon404> btw pasteeater, it's a shame in oen respect
[20:54] <Daemon404> up into about 10.2.0, utvideo had msi installers
[20:54] <Daemon404> for easy distribution on windows clients... but ni more
[20:54] <Daemon404> no*
[20:54] <pasteeater> if you want to make money, selling proprietary BS to state governments is apparently easy. they are easily convinced by buzz and marketing.
[20:55] <Daemon404> or broadcast people
[20:55] <Daemon404> gotta buy those 10x priced SD cards
[20:55] <pasteeater> gotta but that real media helix server
[20:55] <pasteeater> *buy
[20:55] <Daemon404> i dont know any companies doing that
[20:55] <Daemon404> .... maybe in china.
[21:26] <Compn> i wonder if real is doing anything sneaky in china
[21:26] <Compn> like watermarking videos so chinese secret police can find protestors
[21:34] <CIA-17> ffmpeg: 03Nicolas George 07master * r7f06ca6e2b 10ffmpeg/libavfilter/vf_mp.c: 
[21:34] <CIA-17> ffmpeg: vf_mp: uninit filter chain.
[21:34] <CIA-17> ffmpeg: Most of the code was taken from MPlayer's vf_uninit_filter_chain.
[21:34] <CIA-17> ffmpeg: 03Nicolas George 07master * r14aa1ba802 10ffmpeg/libavfilter/libmpcodecs/vf_pp.c: libmpcodecs/vf_pp: import memleak fix from MPlayer.
[23:24] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r33a183df46 10ffmpeg/libavcodec/indeo3.c: 
[23:24] <CIA-17> ffmpeg: indeo3: Fix overreading requant_tab.
[23:24] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[23:24] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:24] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r56ffa3fefb 10ffmpeg/libavcodec/indeo3.c: 
[23:24] <CIA-17> ffmpeg: indeo3: Check motion vectors.
[23:24] <CIA-17> ffmpeg: Fixes overread of reference frame.
[23:24] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[23:24] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:28] <ubitux> http://scenerules.irc.gs/t.html?id=2012_SDTVx264r.nfo
[23:28] <ubitux> "ffmpeg is banned" :(
[23:29] <ubitux> (for aac audio encode, of course)
[23:30] <Daemon404> cant say theyre wrong there :P
[23:31] <ubitux> :)
[23:33] <Daemon404> as usual they contain derpiness
[23:33] <Daemon404> and i read some article about people freaking out over lolnoxvid
[23:33] <Daemon404> its like 2005 all over again
[23:34] <Tjoppen> the sense of entitlement in some torrent users is strong
[23:35] <ubitux> what i find a bit disturbing is the confusion between x264 and h264
[23:35] <Daemon404> ubitux, thats nothing new
[23:35] <ubitux> everyone seems to mixup this, even the ppl writing that nfo
[23:35] <Daemon404> the scene is not known for it;s technical prowess when it comes to  video.
[23:36] <ubitux> well i know, but still :p
[23:36] <iive> well... i don't see anything bad if there was some transition period
[23:36] <Daemon404> its 2012.
[23:37] <iive> aka, release the mp4 first and xvid later.
[23:37] <Daemon404> my phone can play 720p h264
[23:37] <Daemon404> :V
[23:37] <iive> it doesn't matter, a lot of people keep using their dvd players with divx playback support
[23:37] <Daemon404> divx players now play h264/mkv :P
[23:37] <Daemon404> and tons of players use h264/mp4
[23:37] <iive> the point is _now_
[23:37] <Daemon404> for years now
[23:37] <Daemon404> this is not a new thing
[23:38] <iive> read again what I wrote!
[23:38] <ohsix> reading is for suckers
[23:38] <Daemon404> anyway, ive already experienced teh 'fun' of xvid->h264 for the masses 5 years ago
[23:38] Action: Daemon404 is putting it on ignore this time
[23:39] <iive> first of all, the mp4 have been neglected for a long time by the release scene.
[23:39] <iive> it is not even clear if they would be able to make proper releases, unless there are some people from the anime scene.
[23:39] <Daemon404> er wait.. 7 years ago
[23:39] <Daemon404> derp... time flies
[23:40] <Daemon404> <-- anime scene
[23:41] <Daemon404> [17:39] <@iive> it is not even clear if they would be able to make proper releases, unless there are some people from the anime scene. <-- or someone with the ability to use google or read.
[23:41] <ohsix> u r da bestest
[23:41] <Daemon404> :V
[23:41] <ohsix> maybe you can get the tv scene to use crc's in release names and version numbers
[23:41] <Daemon404> crcs are kinda silly :P
[23:41] <ubitux> instead of rar? :)
[23:41] <Daemon404> rar > crc
[23:41] <ubitux> why?
[23:41] <iive> second, the transition period would give people the incentive to try the "new" formats on their "new" gadgets, And to get new gadgets that support it.
[23:41] <Daemon404> ubitux, less easy to fake
[23:41] <iive> this would of course smooth the transition.
[23:42] <Daemon404> tho not hard per se
[23:42] <Daemon404> iive, this transition period is really something that should have started years ago
[23:42] <ubitux> the rar thing really sucks from a user PoV imo
[23:42] <iive> crc are peace of cake to fake
[23:42] <Daemon404> if so
[23:42] <Daemon404> ubitux, mist 'users' use torrents which some dude alreayd dled and unrared fro ma topsite
[23:42] <iive> Daemon404: of course it should have started years ago. But this is not an argument to avoid it now.
[23:43] <Daemon404> [17:42] <@iive> crc are peace of cake to fake <-- yes
[23:43] <ubitux> is there really that much "faking"?
[23:43] <ubitux> i mean, does this really matter?
[23:43] <ohsix> anyways if the only answer you have for people that can't play that content is to buy new hardware, you probably shouldn't be the one to make the case, even if your phone can play them :]
[23:43] <Daemon404> ubitux, only for  trolling purposes
[23:44] <Daemon404> ohsix, anyone with a pc from the last 10 years or so is fine.
[23:44] <ohsix> a PC?
[23:44] <Daemon404> yes. a pc.
[23:44] <ohsix> i thought you said everyones dvd players did mp4
[23:44] <iive> well, rar is also thing from the last 15 years.
[23:44] <ohsix> which one is it
[23:44] <Daemon404> its both
[23:45] <Daemon404> and ive never really given a crap about little plastic divx players
[23:45] <ohsix> "both" all of my computers and my wii can play xvid fine
[23:45] <Daemon404> i nall honesty.
[23:45] <ohsix> well that's big of you :]
[23:45] <Daemon404> ohsix, do you ever not sound liek an arogant dick?
[23:45] <Daemon404> arrogant even
[23:45] <ohsix> does that bother you? heh
[23:46] <ohsix> at least you've stated that it doesn't matter from your perpsective, i'm glad you're not in a position to impose that
[23:46] <iive> Daemon404: you sound a magnitude more arrogant.
[23:46] <Daemon404> iive, fair enough. ill try and tone it down.
[23:47] <Daemon404> iive, i guess you could agrue there was a semi-transition period. sort of.
[23:47] <Daemon404> since hd release have been using h264 for a fair while now
[23:47] <ohsix> the wii has trouble playing h264 when the bitrate gets over a certain surprisingly low number
[23:47] <ohsix> and playing it off a dvd on the wii, due to its read rate is a nonstarter
[23:47] <iive> your arguments so far are basically "it doesn't concern me, sucks to be you"
[23:47] <iive> Daemon404: yes, but all i've seen were mkv.
[23:47] <Daemon404> yes
[23:48] <iive> .mp4 have its own... quirks
[23:48] <Daemon404> i understand the problem of hardware support, and ill agree on that
[23:48] <Daemon404> but i wont say people who complai nabout pc playback are justified.
[23:48] <ohsix> and i don't think anyone is out of the loop on how much better h264 is for about everything, but that's not their criteria
[23:49] <ohsix> if you're going to bother with anything w>640 you probably should be using something else ... yeaaaa
[23:49] <Daemon404> latest spec finally uses something larger
[23:49] <Daemon404> i never did quite understand that partiicular bit
[23:49] <ohsix> for tv
[23:49] <Daemon404> i dont follow
[23:50] <Daemon404> no tv natively uses 640, or even square pixels
[23:50] <Daemon404> sdtv*
[23:50] <ohsix> you weren't referring to the thing that was posted on irc.gs? 14:49 <+Daemon404:#ffmpeg-devel> latest spec finally uses something larger
[23:51] <Daemon404> that spec doesnt use w = 640 for WS
[23:51] <ohsix> i didn't say it did ...
[23:51] <ohsix> i said if your w>640 you should be using something other than xvid
[23:51] <Daemon404> why?
[23:52] <Daemon404> there is n orelatio nto res...
[23:52] <ohsix> ok
[23:53] <Daemon404> anyway, ill agree with iive about the transition period bit i guess
[23:53] <Daemon404> m not sure what youre on about though...
[23:54] <ohsix> important xvid scene stuff!
[23:54] <ohsix> like bitrates, and when it's actually useful or a waste of effort
[23:55] <Daemon404> sounds like trolling to me :/
[23:55] <ohsix> that eventually gets trotted out every time you speak at me, yes
[23:55] <Daemon404> its usually pretty accurate.
[23:56] <ohsix> but lets just wrap it up into not a lot of the cheaper older players do any advanced xvid features, no GMC no nothing, no special quants; and nothing above w>640
[23:56] <ohsix> there are other reasons but apparently nobody knows or cares :]
[23:57] <ohsix> is there any concensus on what bitrates the players that do h264 do?
[23:57] <Daemon404> they do certain levels
[23:57] <ohsix> or is this all just targeted at PC playback
[23:57] <Daemon404> and certain levels have such things defined
[23:57] <Daemon404> (tho hot as bitartes, but mb-based thigns)
[23:57] <ohsix> right, not unlike xvid
[23:57] <ohsix> but if you're publishing content that is to be played on anything but a PC you need to know what the players do, right?
[23:57] <Daemon404> mpeg-4 asp didnt have levels like avc does afaik
[23:57] <ohsix> not literally
[23:58] <Daemon404> the only thign close asp had was divx's guidelines for their players
[23:58] <Daemon404> and nobody followed those anyway unless they wanted to be cetrified
[23:58] <iive> Daemon404: it definitely have levels.
[23:58] <ohsix> ok, even if nobody cared or followed them, they knew what they were
[23:59] <Daemon404> iive, interesting
[23:59] <Daemon404> ive never seen mention of them
[23:59] <ohsix> but yea, suffice it to say people encoding the stuff care a lot about where it can be played, that's where the on the face of it silly limits come from, it's not for uniformity or anything
[23:59] <iive> well, most of the standard have never been implemented
[00:00] --- Mon Mar  5 2012