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

[burek]

[00:08] <cone-6> ffmpeg.git 03Luca Barbato 07master:f121dbd9f760: mpegts: Provide an option to override the pcr period
[00:08] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:aff0912da551: Merge commit 'f121dbd9f76031d7f6d56261be2f14937a19d2dd'
[00:21] <J_Darnley> While doc/writing_filters.txt is helpful, I still have no idea why, when, or how I should be using the functions of an AVFilterPad.
[00:22] <J_Darnley> Do frames get pushed from the input or pulled from the output?
[00:25] <llogan> michaelni: feel free to try your imxdump _codec_tag() idea if you want. i don't know how. if you do i can update my crappy patch.
[00:29] <michaelni> jamrial, sounds logic but seems not to make a difference to any file in fate
[00:33] <michaelni> smarter llogan iam not sure we should or should not assume without user "command" that inpt that looks like imx from w/h/bitrate is
[00:33] <michaelni> sorry s/smarter// 
[00:34] <ubitux> J_Darnley: only if it's dynamic?
[00:35] <ubitux> it's ’ the i/o pads can not be defined staticlly
[00:35] <michaelni> jamrial, btw, probably best to notify the author of that shuffle discrepancy
[00:38] <llogan> michaelni: probably not worth the time investment. we can leave it up to the user to supply the proper vtag if it is needed as mentioned by my updated patch.
[00:39] <J_Darnley> ubitux: how does filter_frame on the input make its way to the output?
[00:40] <llogan> J_Darnley: bad timing
[00:41] <llogan> (as in 1 second later ubitux times out)
[00:42] <J_Darnley> yes...
[00:42] <J_Darnley> oh well
[00:43] <J_Darnley> I'll try reading some more filters
[00:44] <llogan> are you making a filter?
[00:45] <J_Darnley> Trying to.
[00:45] <J_Darnley> Specifically an A->V filter
[00:47] <llogan> good. i wanted another for https://trac.ffmpeg.org/wiki/Encode/YouTube#Usingfilters
[00:49] <J_Darnley> If I ever finish you should be impressed.
[01:43] <Timothy_Gu> jamrial: isnt imm==0 means to broadcast the least significant dword of src?
[01:43] <Timothy_Gu> doesn't
[01:44] <Timothy_Gu> then how does shufps/pshufd matter?
[01:44] <jamrial> shufps uses both dst and src. pshufd only src
[01:47] <Timothy_Gu> oh wait
[01:47] <Timothy_Gu> now i get what you meant
[01:49] <Timothy_Gu> i missed the important sentence in the instruction manual because i thought it was a typo ;)
[01:50] <Timothy_Gu> yeah i agree with you that overwriting a just calculated value is kinda odd
[02:07] <J_Darnley> Woo!  I drew a line moving left at ipx per frame!
[02:07] <J_Darnley> *1px
[02:09] <J_Darnley> but I don't create enough frames
[02:13] <J_Darnley> Must be something to do with timestamp-shenanigans
[02:27] <J_Darnley> Why do you only produce 206 frames?
[02:33] <cone-6> ffmpeg.git 03Diego Biurrun 07master:205fdd4ea5e1: ppc: Fix runtime CPU detection for apedsp, huffyuvdsp, svq1enc
[02:33] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:26be0e31fc48: Merge commit '205fdd4ea5e1264946917a26fde01e137a485f5a'
[02:50] <jamrial> kurosu, michaelni: seems there's a lot of fate systems having trouble with five vsynth3 tests
[02:51] <cone-6> ffmpeg.git 03Diego Biurrun 07master:27860819d508: ppc: Consistently use convenience macro for runtime CPU detection
[02:51] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:1290143fda93: Merge commit '27860819d508068f056cf48473af04868791ad77'
[03:09] <cone-6> ffmpeg.git 03Vittorio Giovara 07master:d7705be9617e: mpegvideoenc: check color_range
[03:09] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:b3a647d9ce59: Merge commit 'd7705be9617ed691c7a2924a2088de2d96f38af1'
[03:18] <Timothy_Gu> jamrial kurosu michaelni: to be exact, literally *all* slots with vsynth are failing
[03:19] <cone-6> ffmpeg.git 03Vittorio Giovara 07master:641e57230b46: fate: add on2avc audio test
[03:19] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:b2fb65cbebba: Merge commit '641e57230b460bef52c88e61087d97c223910bea'
[03:33] <BBB> Daemon404: I dont work for chrome...
[03:33] <BBB> sorry, cop-out response, I know, but I cant speak for them so responding doesnt make much sense
[03:48] <wm4> what was the gcc 4.9 ffmpeg/flac bug?
[03:51] <BBB> jamrial: I might have all of swri_resample() ready for yasmification of that buttugly inline asm of yours. are you interested in that or should I do that?
[03:52] <wm4> ah https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902
[04:04] <jamrial> no, not really interested. but you can use the yasm port i submitted a while ago if it's useful to save you some time
[04:04] <jamrial> and that buttugly inline asm of mine is merely an extension of an already existing buttugly asm :P
[04:05] <michaelni> Timothy_Gu, jamrial, kurosu, i cant reproduce any vsynth3 failures locally, though i know why qtrlegray fails, ill push a "fix" in a moment for that one
[04:07] <jamrial> i can't reproduce it here with mingw-w64 (native) either. oddly enough nevcairiel's did fail
[04:13] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:43d995e865f7: fate: Disable qtrlegray 34x34 test
[04:13] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:c69defd4d014: avcodec/qtrleenc: Check that width is a multiple of 4 for grayscale
[04:13] <BBB> jamrial: acknowledged :-p ok Ill do it then; the early asm may not help because I basically rewrote the function so its a double loop now
[04:14] <BBB> jamrial: that basically makes it tons faster, and less jumpy, so the dsp portion is slightly bigger (because its double loop instead of single), but should be faster than inline, or at least as fast
[04:58] <wm4> why does av_register_codecs exist?
[05:14] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:60ab6e24574a: avcodec/mpegvideo_enc: fix padding for odd dimensions and interlaced video
[10:24] <YNT> hi
[10:33] <YNT> Removing old source Cloning into ffmpeg... ERROR: libx264 not found
[10:33] <YNT> FFMPEG installation Failed
[12:00] <ubitux> > [PATCH 1/1] ppc: fix the bug of fft for little endian Environment on POWER7 and later
[12:00] <ubitux> 5 files changed, 1104 insertions(+), 0 deletions(-)
[12:00] <ubitux> "fix a bug" o_o
[12:56] <cone-113> ffmpeg.git 03Timothy Gu 07master:5c57e2b51bc0: MAINTAINERS: numerous grammar and discrepancy fixes
[13:41] <plepere> hmm. Should there be a rule for mova on INIT_AVX to use vmovdqa instead of movdqa ?
[13:42] <plepere> I'm seeing the rules for INIT_XMM and INIT_YMM
[13:43] <plepere> but they use only the 128b mov
[13:46] <BBB> plepere: INIT_AVX is INIT_XMM avx
[13:46] <BBB> plepere: so no
[13:46] <BBB> plepere: dont ever use INIT_AVX, its deprecated
[13:46] <plepere> ok
[13:46] <BBB> if you want avx2, just use INIT_YMM avx2
[13:46] <BBB> if you want float avx, use INIT_YMM avx
[13:47] <BBB> if you want avx 3-part instructions on xmm/sse4, use INIT_XMM avx
[13:47] <plepere> well I'm using h264 dc_add, so it's INIT_XMM avx
[13:47] <BBB> yes
[14:00] <plepere> BBB, what's the benefit of using the 3 instruction avx paddw instead of mova + paddw ?
[14:01] <BBB> its typically faster
[14:01] <BBB> and saves a register
[14:02] <J_Darnley> WTF?  Why is this AVFrame filled with NULLs?
[14:10] <J_Darnley> I'm going backwards now!
[14:21] <plepere> BBB : if I'm inspiring myself with h264 assembly code, where should I say it ?
[14:38] <BBB> plepere: nowhere imo
[14:39] <BBB> plepere: but if you insist, put it in a comment above the function maybe?
[14:39] <BBB> ; this was somewhat inspired by h264 code in function abc in file xyz by author a b. c <d at e.f>
[14:39] <BBB> do whatever you think feels right
[14:40] <plepere> ok ok
[14:44] <plepere> dang it. my idct16 works, but when I re-use it in a idct32 wrapper, it breaks in a most cases.
[15:15] Action: Daemon404 sees ubitux enjoying c-e again
[15:16] <ubitux> that's fine with me
[18:27] <cone-113> ffmpeg.git 03Michael Niedermayer 07master:27b8ef5bb709: avformat/oggparsevorbis: Dont attempt to calculate timestamps from gp=0
[18:57] <nevcairiel> Daemon404: am I blind or do you not define a default value for the filter size
[18:57] <Daemon404> yes
[18:57] <Daemon404> i noticed that 2 seconds later
[18:57] <Daemon404> i am very smart.
[19:01] <ubitux> what's the impact of a larger filtersize?
[19:02] <ubitux> slower init? larger memory consumption?
[19:02] <nevcairiel> both i guess
[19:02] <ubitux> anything else?
[19:02] <nevcairiel> should reallz just bump the default up as well
[19:02] <ubitux> anyway to make it dynamic?
[19:02] <nevcairiel> it was designed years ago when memory was smaller
[19:03] <nevcairiel> ubitux: very hard, since asm has offsets to the table
[19:03] <ubitux> ok
[19:03] <nevcairiel> could make them pointers and make the asm deref those, but thats still effort and potentially a bit slower :p
[19:03] <ubitux> what about making it slow/dynamic when a certain size is required?
[19:03] <Daemon404> [18:02] <@ubitux> anyway to make it dynamic?
[19:03] <Daemon404> not easily
[19:04] <Daemon404> i discussed it with michaelni before
[19:04] <Daemon404> and the conclusion was compile time option
[19:04] <Daemon404> its nontrivial to make dynamic
[19:04] <ubitux> ok
[19:04] <Daemon404> it even used to use fixed offsets before michael fixed it a while back ;)
[19:07] <Daemon404> you know
[19:07] <Daemon404> why the fuck do people reply with "fails build because no default"
[19:07] <Daemon404> after i *already* replied with that
[19:08] <Daemon404> just to rub it in?
[19:08] Action: ubitux going to try the patch and report problems
[19:11] <Daemon404> v2 send
[19:11] <Daemon404> sent*
[19:11] <Daemon404> ubitux, ^
[19:11] <Daemon404> if youre gonna test, then test that
[19:12] <ubitux> too late
[19:24] <Daemon404> kurosu, http://fate.ffmpeg.org/report.cgi?time=20140611171420&slot=i686-windows-icl
[19:27] <cone-113> ffmpeg.git 03Timothy Gu 07master:881ee369e637: tests: Add aic decoder test
[19:27] <Daemon404> msvc is broken too
[19:28] <Daemon404> and mingw
[19:28] <Daemon404> i guess all 32bitwindows.
[19:28] <nevcairiel> looks like all builds running on native windows fail
[19:28] <nevcairiel> 32 that is
[19:28] <Daemon404> yea
[19:34] <Daemon404> eh
[19:34] <Daemon404> http://fate.ffmpeg.org/report.cgi?time=20140611112041&slot=x86_32-linux-gnu-gcc-4.4.5
[19:34] <Daemon404> all 32bit is broken.
[19:37] <jamrial> vsynth3-svq1 and vsynth3-wmv2 are also failing in a couple x86_64 systems
[19:38] <jamrial> and all the mpeg4 ones are failing with valgrind http://fate.ffmpeg.org/report.cgi?time=20140611143502&slot=x86_64-archlinux-gcc-valgrindundef
[19:39] <jamrial> guess vsynth3 works as intended. It found a lot of corner cases :P
[20:31] <kurosu> regarding some of the huffyuv tests, the int16 encoder asm wrecks the stack and crashes
[20:31] <kurosu> I haven't investigated more why
[20:32] <kurosu> (int16 asm: can't even get a backtrace with it)
[20:36] <nevcairiel> stack smashing is fun like that
[20:43] Action: Daemon404 just saw the £400 a day contract on ffmpeg-devel
[20:43] <Daemon404> too bad im employed
[20:45] <llogan> i wonder what a "multimedia management platform" really is.
[20:46] <Daemon404> llogan, if theyre willing to pay £400 a day i doubt it will be a fun experience
[20:46] <Daemon404> on-site requirement too
[20:47] <llogan> you mean I'd have in live in a place whose name is an archaic for "hymen"?
[20:47] <Daemon404> relocating for 6 months isnt exactly a pleasing thing to o
[20:47] <Daemon404> do
[20:48] <Daemon404> reeks of enterpriseness too
[20:49] <Daemon404> theres someone in here who lives 40 minutes from tere, but theyre also employed
[20:49] Action: Daemon404 likes 2 hrs
[20:49] <Daemon404> lives*
[20:50] <llogan> have you developed an accent yet?
[20:50] <Daemon404> no
[20:50] <Daemon404> i probably wont
[20:50] <Daemon404> iirc accents develop in childhood
[20:50] <Daemon404> after some age, they dont go away
[20:51] <llogan> i've known some people who have lived in the US south that have come back talkin' funny...temporarily.
[20:54] <kierank> Daemon404: 400 quid a day is cheap
[20:55] <kierank> but yes it'll be a mess
[20:55] <kierank> and so they'd have to offer more
[20:56] <Daemon404> yeah
[20:56] <Daemon404> exactly
[20:56] <Daemon404> kierank, 400 quid a day works out to a pretty decent salary
[20:56] <Daemon404> but for that job, it is shit pay
[20:56] <Daemon404> contracting etc
[20:59] <JEEB> and often the more you're paid the more the people expect you to actually do per day if you're on such a payment scheme
[20:59] <Daemon404> JEEB, jobs like that tend to be akin to "bend over and lube up"
[20:59] <JEEB> yes
[20:59] <llogan> an on site they can loom over you while you're busy in #ffmpeg-devel
[20:59] <JEEB> reminds me of a tweet I saw today
[21:00] <JEEB> "HOW MUCH PIZZA AND COKE DO I HAVE TO GIVE THESE NERDS SO THEY WON'T COMPLAIN ABOUT THE 80 HOUR WORK WEEK"
[21:01] <JEEB> https://twitter.com/PHP_CEO/status/448821416113475584
[21:01] <JEEB> :3
[21:02] <Daemon404> thats a different thing
[21:02] <Daemon404> thats lolstartups
[21:03] <Daemon404> this is lolcontracting
[21:03] <JEEB> still shit
[21:03] <JEEB> like they both are
[21:03] <Daemon404> well yes.
[21:04] <Daemon404> i dont really know why peple restrict themselves to "on-site" a lot
[21:04] <Daemon404> it cuts off ... well most of this channel
[21:04] <JEEB> J_Darnley, unless you are enjoying that wbk person I recommend you set him on ignore
[21:04] <JEEB> he's been banned there twice or so already
[21:05] <JEEB> he's either retarded, or trolling
[21:05] <Plorkyeran> there are a lot of managers who can't comprehend any way to determine if someone is working other than seeing if their butt is in a seat in the office
[21:05] <J_Darnley> I should email the guy.  I am not experienced and I "dislike" c++ but its £400!
[21:05] <llogan> how long can they pay you befor ethey realize?
[21:05] <J_Darnley> 1 minute?
[21:06] <JEEB> I like "on-site" because it keeps a distinct difference between "work" and "not work"
[21:06] <Daemon404> Plorkyeran, my manager is also a coworker
[21:06] <Daemon404> he sees my code directly
[21:06] <JEEB> I'm still not sure how much my manager can code
[21:07] <J_Darnley> JEEB: I thought I recognised the name
[21:07] <Daemon404> JEEB, i know how intel management is
[21:07] <JEEB> he is a "software engineering manager", but I mostly see him doing random stuff in JIRA
[21:07] <Daemon404> if there is one thing that can kill intel
[21:07] <Daemon404> it's its management
[21:07] <JEEB> I'm kind of noticing it
[21:07] <JEEB> at the very least we're generally on OK terms
[21:07] <Daemon404> do they force you to use IBM "Rational" ClearShit
[21:07] <Daemon404> like i had t?
[21:08] <JEEB> haven't seen at least yet
[21:08] <Daemon404> lucky
[21:08] <Daemon404> you know how jira can be evil when used by management?
[21:08] <Daemon404> this is far worse.
[21:08] <llogan> i often make my own hours. and that's why i'm a thousandaire.
[21:09] <Daemon404> i keep EST hours but im in BST
[21:09] <JEEB> OTC seems to be relatively sane regarding tools
[21:09] <Daemon404> sleep patterns -> fucked
[21:19] <kurosu> One bug down, 6+ to go ?
[21:19] <Daemon404> kurosu, you mean 
[21:19] <Daemon404> such is coding.
[21:25] <cone-113> ffmpeg.git 03Clément BSsch 07master:76bce46d8fab: avfilter: add signalstats filter
[21:26] <kurosu> actually, it seems to have fixed all huffyuv cases here
[21:31] <jamrial> yeah, it did here as well
[21:31] <Daemon404> \o/
[21:32] <kurosu> 2 bugs down, 5 to go ?
[21:33] <nevcairiel> valgrind complains on a few others, but at least this should be the last actual failure on "normal" fate systems
[21:33] <jamrial> svq1, wmv2 on some x86_64, and mpeg4 and rgb with valgrind
[21:33] <Daemon404> theres a patch for one there
[21:34] <kurosu> I'd thought 60ab6e24 would have fixed mpeg4 as well
[21:34] <jamrial> ah right, missed michaelni's email
[21:35] <kurosu> ah nice that it is such a small issue
[21:35] <cone-113> ffmpeg.git 03Clément BSsch 07master:1786cd850f90: avfilter/showcqt: fix misc style issues
[21:35] <cone-113> ffmpeg.git 03Clément BSsch 07master:0180c4692864: avfilter/showcqt: move qsort_sparsecoeff closer to where it belongs
[21:35] <kurosu> err, that's just a single test - I thought it fixed mpeg*
[21:36] <kurosu> fate-vcodec passes here (win32/64)
[21:37] <kurosu> cpu is sse4.2 at most
[22:02] <cone-113> ffmpeg.git 03Lou Logan 07master:edeefeaaf9b6: doc/filters: add forgotten " to zoompan example
[22:06] <ubitux> BBB: it seems there is a bug in ff_vp9_ipred_vl_4x4_ssse3 (at least)
[22:28] <cone-113> ffmpeg.git 03Michael Niedermayer 07master:ef8725122d23: avcodec/motion_est: Only clip MVs which are used
[22:28] <cone-113> ffmpeg.git 03Michael Niedermayer 07master:67d29da4bd23: avcodec: increase FF_INPUT_BUFFER_PADDING_SIZE to 32
[22:33] <ubitux> llogan: the quotes are wrong
[22:33] <ubitux> why did you do that?
[22:38] <cone-113> ffmpeg.git 03Janne Grunau 07master:0ddc53dabbc6: mpegvideo: synchronize AVFrame pointers in ERContext fully
[22:38] <cone-113> ffmpeg.git 03Michael Niedermayer 07master:67911cc57bbe: Merge commit '0ddc53dabbc6f636d062b187ea27934610aaad30'
[22:43] <jamrial> i may be missing something, but why are the results of vsynth*-zlib and vsynth*-mpng lossy? aren't both supposed to be lossless?
[22:44] <Compn> png has both lossy and lossless modes 
[22:44] <Compn> but no idea on those specific tests
[22:48] <jamrial> maybe it's related to colorspace conversion
[22:48] <llogan> ubitux: i'll revert it.
[22:50] <kurosu> png might be lossy if forced to palettize, ie reduce number of different colors?
[22:51] <llogan> ubitux: why was there a trailing "?
[22:51] <ubitux> missed that one
[22:52] <ubitux> the correct fix was to remove it
[22:53] <llogan> i'll remove them both then
[22:53] <cone-113> ffmpeg.git 03Janne Grunau 07master:cd62c04d009b: h263enc: keep block_last_index always valid during advanced intra coding
[22:53] <cone-113> ffmpeg.git 03Michael Niedermayer 07master:2cf4d91cf221: Merge commit 'cd62c04d009b3baf7582556866a7029291b54573'
[22:54] <llogan> that's what i get for thinking it was trivial
[22:54] Action: Compn looks around for evrc decoder :(
[23:12] <llogan> ubitux: the examples are often inconsistent, but your version is at least easier to human read
[23:18] <wm4> https://git.videolan.org/?p=ffmpeg.git;a=commit;h=67d29da4bd23057a1f646568442a77b844cb2d1b
[23:18] <wm4> what
[23:18] <wm4> michaelni: I consider that an ABI breakage
[23:19] <wm4> michaelni: you can't just do this
[23:19] <wm4> how about lavc doesn't just read out of bounds of memory buffers by design
[23:19] <wm4> this is so unclean
[23:19] <wm4> /rant
[23:21] <kurosu> ...
[23:24] <michaelni> wm4, how is padding buffers by twice the amount an ABI breakage ?
[23:24] <wm4> because library users have to pad the buffer
[23:25] <michaelni> how is this related to the commit you point at ?
[23:26] <wm4> it's a bug that lavc reads outside of the bounds
[23:26] <michaelni> lavc does not read outside the old bounds AFAIK, some filters do
[23:27] <kurosu> has bitstream reading been changed in that way ? because that was the original intent, right ?
[23:28] <michaelni> bitstream reading can read a few bytes over, like 3 or 4 or so 
[23:28] <michaelni> on damaged streams its possible slightly more overread happens and the 0 padding arrests that
[23:29] <wm4> and that's why you potentially force every API user to copy the input buffer?
[23:29] <wm4> (same for buffer alignment)
[23:32] <michaelni> wm4, what do you suggest ? that there would be a flag that does the copy internally ?
[23:33] <michaelni> also, which applications actually do need a copy ? 
[23:33] <wm4> a clean solution would probably revolve around not requiring such a padding in the reader, but maybe it's too late to realistically change this, if at all
[23:33] <wm4> all applications that don't have direct control over the buffer allocation
[23:33] <wm4> imagine something that tries to do zero-copy by passing a pointer into a mmaped file to lavc
[23:34] <michaelni> not requiring the pading makes the reader slower
[23:34] <kurosu> there are actually 2 very different usages of this define. One is internally, to guarantee we don't have to waste code and speed
[23:35] <kurosu> the other is when those buffers are provided by the application I guess
[23:35] <kurosu> and that's where the issue is?
[23:36] <michaelni> wm4, i understand in what cases the copy is needed, i was wondering which actual real world applications are affected by this
[23:37] <wm4> michaelni: every API user who is naive enough to assume that the API doesn't require such intuitive and hard to track down artifacts
[23:37] <wm4> the bitstream reader could just copy an amount of bytes ahead when the buffer runs out or such
[23:37] <wm4> and the copy could be padded or whatever
[23:38] <TheFluff> a lot of api users don't seem to understand what FF_INPUT_BUFFER_PADDING_SIZE is for, in my experience
[23:38] <TheFluff> if they use it they usually use it wrong
[23:42] <michaelni> wm4, if one adds a check into get_bits() to copy and pad before the end, this could easily be slower than unconditional copying of the whole buffer before use. It would be possible of course to do the check and copy padding at some larger granularity like per row but that then would need changes and extra code to litterally every decoder
[23:43] <wm4> I suppose I don't enough about the bitstream reader to tell, but somehow I doubt it's impossible to improve this situation
[23:44] <michaelni> improvment is certainly possible, it almost always is for non trivial code
[23:45] <michaelni> the most obvious 2 things i see is 1. if users dont know how to use FF_INPUT_BUFFER_PADDING_SIZE there must be somethig seriously wrong with our documentation
[23:45] <wm4> maybe if a user has a lot of time, 100% attention, and reads all the docs, he won't miss this
[23:45] <michaelni> and we could check if the padding area is filled with zeroes and warn if its not but IIRC we dont strictly require zero filling the area
[23:46] <wm4> actually you could just read the padding on each packet and verify it's zerod
[23:46] <wm4> yeah
[23:46] <wm4> huh
[23:46] <wm4> you don't?
[23:47] <michaelni> "Note: If the first 23 bits of the additional bytes are not 0, then damaged * MPEG bitstreams could cause overread and segfault."
[23:48] <wm4> so, you don't require zeroing the padding, but you might segfault then?
[23:48] <michaelni> on damaged streams, yes
[23:48] <wm4> that's a strange definition of "not required"
[23:50] <michaelni> instead of 0 bytes at the end a sufficient amount of any bytes should also prevent segfaults, which may be usefull for mmap files
[23:51] <wm4> michaelni: how much slower would decoding become overall if the bitstream reader would check for the bounds in some way?
[23:55] <kurosu> wm4, no idea, but seeing how some small changes provided several % on a lossless video codec, I'd expect 10% worst-case
[23:56] <kurosu> more often 1% for the most common codecs
[23:57] <michaelni> wm4 also if you force UNCHECKED_BITSTREAM_READER to 0 then the overread i think would be limited to 3-4 bytes independant of if they are 0 at the end
[23:58] <michaelni> these checks probably could be extended to switch the buffer before the end to prevent that remaining overread
[00:00] --- Thu Jun 12 2014