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

[burek]

[10:43] <cone-300> ffmpeg.git 03Diego Biurrun 07master:6c145ecf785d: twinvq: K&R formatting cosmetics
[10:43] <cone-300> ffmpeg.git 03Michael Niedermayer 07master:e28fabb4cbe5: Merge commit '6c145ecf785dc3d26ba3fed3ea9892cc80244625'
[10:49] <cone-300> ffmpeg.git 03Diego Biurrun 07master:4a2ef39442bf: cosmetics: Add '0' to float constants ending in '.'.
[10:49] <cone-300> ffmpeg.git 03Michael Niedermayer 07master:af7949fdea2f: Merge commit '4a2ef39442bf7f0150db07a1fbfcf8286e4d44a3'
[10:57] <cone-300> ffmpeg.git 03Rainer Hochecker 07master:582963a81565: vdpau: Fix VC-1 interlaced mode
[10:57] <cone-300> ffmpeg.git 03Michael Niedermayer 07master:bbc7d33a0d7d: Merge commit '582963a8156522582e55466be4a59974a8d909a5'
[11:08] <cone-300> ffmpeg.git 03Rémi Denis-Courmont 07master:93a51984a27f: mpeg12: Ignore slice threading if hwaccel is active
[11:08] <cone-300> ffmpeg.git 03Michael Niedermayer 07master:5dc2c99055ae: Merge commit '93a51984a27f3ba84d4e6f13d0c704ee9891603e'
[11:20] <cone-300> ffmpeg.git 03Diego Biurrun 07master:03039f4c8cdb: miscellaneous typo fixes
[11:20] <cone-300> ffmpeg.git 03Michael Niedermayer 07master:46ad2d9e4463: Merge remote-tracking branch 'qatar/master'
[12:07] <cone-300> ffmpeg.git 03Michael Niedermayer 07master:6663205338f5: avformat/dtsdec: Improve probe, reject things looking like analoge signals
[12:34] <cone-300> ffmpeg.git 03Michael Niedermayer 07release/1.0:34dfb907b222: avformat/dtsdec: Improve probe, reject things looking like analog signals
[12:34] <cone-300> ffmpeg.git 03Michael Niedermayer 07release/1.1:a1ac3c2d9cff: avformat/dtsdec: Improve probe, reject things looking like analog signals
[12:34] <cone-300> ffmpeg.git 03Rémi Denis-Courmont 07release/1.2:70127070dd9f: mpeg12: Ignore slice threading if hwaccel is active
[12:34] <cone-300> ffmpeg.git 03Michael Niedermayer 07release/1.2:875649bfaef8: avformat/dtsdec: Improve probe, reject things looking like analog signals
[12:34] <cone-300> ffmpeg.git 03Rémi Denis-Courmont 07release/2.0:ccf470fdb6e3: mpeg12: Ignore slice threading if hwaccel is active
[12:34] <cone-300> ffmpeg.git 03Michael Niedermayer 07release/2.0:18043e3d2282: avformat/dtsdec: Improve probe, reject things looking like analoge signals
[13:35] <durandal_1707> shit some guy started to send our code to fork
[13:44] <Compn> gasp!
[13:45] <durandal_1707> they can change random thing and break compability when merged by michaelni, as it already happened multiple times
[13:47] <cone-300> ffmpeg.git 03Paul B Mahol 07master:2a1a599bcb2b: lavfi/buffersrc: remove unused item from BufferSourceContext
[13:52] <Compn> did they rename jp2k twice ?
[13:56] <Compn> looks like i have to find samples of imc mode 1 for kostya :)
[14:05] <cone-300> ffmpeg.git 03Hendrik Leppkes 07master:af2a196e669c: lavfi: add attribute_align_arg to all public entry points
[14:47] <wm4> ffmpeg can't decode a simple 16384x16384 png
[14:47] <wm4> Picture size 16384x16384 is invalid
[14:50] <durandal_1707> wm4: how you got such sample?
[14:50] <wm4> http://dl.dropboxusercontent.com/u/5321377/Sierpinski%20Gaskets/sierpinski16384x16384.png
[14:53] <durandal_1707> you can actually display it with some other app?
[14:53] <nevcairiel>  there is some odd overflow check in imgutils which i dont really understand
[14:54] <nevcairiel> it checks if (w+128)*(h+128) is > INT_MAX/8
[14:54] <nevcairiel> not sure why
[14:54] <nevcairiel> probably for the image buffer size
[14:54] <durandal_1707> remove that check, and try to display it....
[14:54] <durandal_1707> good luck
[14:55] <nevcairiel> i see no reason it doesnt work
[14:55] <durandal_1707> on 64bit computer and bunch of RAM, maybe
[14:55] <wm4> it did work with some image viewer
[14:55] <wm4> on a 32 bit system
[14:55] <wm4> (ok maybe there's some luck involved)
[14:56] <durandal_1707> what image viewer?
[14:56] <wm4> simple gtk based thing
[14:56] <durandal_1707> and it have whole decoded image in memory?
[14:56] <nevcairiel> rgba 16384x16384 only uses a gigabyte of memory
[14:56] <wm4> yes
[14:56] <nevcairiel> should be well in thel imits
[14:56] <durandal_1707> yes,
[14:56] Action: nevcairiel removes check
[14:57] <durandal_1707> function is flawed
[14:57] <wm4> anyway, I don't understand that check either
[14:57] <wm4> maybe 8 because there's a maximum of 8 bytes per pixel?
[14:57] <nevcairiel> possible
[14:57] <durandal_1707> rgba64 would take 2 gb
[14:58] <durandal_1707> but design is flawed anyway
[14:58] <nevcairiel> thats near the signed integer overflow, which it will try to protect against i guess
[14:58] <durandal_1707> as monow would take even less memory
[14:58] <wm4> int sws_scale(struct SwsContext *c, const uint8_t *const srcSlice[],
[14:58] <wm4>               const int srcStride[], int srcSliceY, int srcSliceH,
[14:58] <wm4>               uint8_t *const dst[], const int dstStride[]);
[14:58] <wm4> oh... ok.
[14:59] <wm4> so that's why INT_MAX
[14:59] <durandal_1707> is sws_scale able to scale it on 32/64 ?
[15:00] <wm4> it does support RGBA64 if you mean that
[15:01] <durandal_1707> no, i mean is it able to scale down that png...
[15:01] <nevcairiel> at least the decode error went away, sadly my video player refuses ebcause it wants to allocate 3 or 4 image buffers already, which obviously doesnt work on 32-bit :p
[15:01] Action: nevcairiel builds 64-bit
[15:03] <durandal_1707> another nice feature would be decoding and displaying only part of image (if bitstream allows it)....
[15:03] <durandal_1707> it could be useful with tiled tiffs and exrs and others....
[15:05] <nevcairiel> ha on 64-bit it displays, but my players uses 6gb of memory :P
[15:05] <JEEBsv> :D
[15:06] <nevcairiel> so yeah the check is a bit overzealous
[15:06] <nevcairiel> sadly it doesnt have the correct information in that function to do it properly
[15:08] <wm4> my player manages to display hat png (after removing the check), but only with vo_x11 (the most crappy output)
[15:09] <nevcairiel> all my outputs try to allocate too many image buffers to hold in 32-bit
[15:09] <nevcairiel> so they bail
[15:09] <nevcairiel> but i'll worry about that once a video actually triggers that problem :p
[15:11] <durandal_1707> switch to 64bit and get min 1024GB of RAM ASAP
[15:53] <cone-300> ffmpeg.git 03Paul B Mahol 07master:cf5ab8b6f716: vmnc: make code independent of sizeof(AVFrame)
[15:53] <cone-300> ffmpeg.git 03Paul B Mahol 07master:94372592767f: vmnc: check return values of reallocation
[15:53] <cone-300> ffmpeg.git 03Paul B Mahol 07master:3838637bbb14: yop: check return value of av_frame_alloc()
[16:05] <cone-300> ffmpeg.git 03Paul B Mahol 07master:2868035d951b: pcxenc: get rid of unused PCXContext
[17:04] <durandal_1707> ahh random failures
[17:07] <cone-300> ffmpeg.git 03Paul B Mahol 07master:a4b899f588bd: lavfi/gradfun: remove nv21/nv12 as they are not supported
[17:28] <saste> ffprobe writers are painful
[17:29] <cone-300> ffmpeg.git 03Paul B Mahol 07master:0addc8288045: avdevice/x11grab: use AV_OPT_TYPE_VIDEO_RATE
[17:29] <cone-300> ffmpeg.git 03Paul B Mahol 07master:2634af575c2d: avdevice/fbdev: use AV_OPT_TYPE_VIDEO_RATE
[17:29] <cone-300> ffmpeg.git 03Paul B Mahol 07master:7ac736afbd18: lavfi/frei0r: use AV_OPT_TYPE_VIDEO_RATE
[17:34] <durandal_1707> saste: how?
[17:35] <wm4> saste: how does an application handle libavfilter EOF correctly? calling av_buffersink_get_frame() in a loop until no more data is available doesn't seem to do the right thing
[17:46] <nevcairiel> wm4: i flush the graph with a NULL frame for av_buffersrc_write_frame and then poll get_frame until it doesnt give me anything anymore, seems to work
[17:49] <wm4> just av_buffersrc_write_frame(s, NULL)?
[17:49] <nevcairiel> yes
[17:50] <wm4> ok thanks
[17:50] <wm4> of course this is not documented
[17:50] <nevcairiel> i think i read the code to figure this out
[18:39] <durandal_1707> descriptions of frei0r filters is really obscure
[19:17] <cone-300> ffmpeg.git 03Paul B Mahol 07master:be7d6710b45c: lavfi/frei0r: use AV_OPT_TYPE_IMAGE_SIZE
[20:24] <cone-300> ffmpeg.git 03Paul B Mahol 07master:fdf9296df7f5: sgienc: remove unused SgiContext
[20:33] <durandal_1707> michaelni: mpegvideo.c still calls assert
[20:35] <cone-300> ffmpeg.git 03Paul B Mahol 07master:1fa0284c57fd: qcelpdec: change asserts to av_asserts
[22:38] <cone-300> ffmpeg.git 03Michael Niedermayer 07master:c88bbc01eb7f: avcodec/mpegvideo: replace assert about interlaced EC by debug av_log()
[22:38] <cone-300> ffmpeg.git 03Michael Niedermayer 07master:205f423e28bc: libavcodec/mpegvideo: change some asserts to av_assert0()
[22:41] <wm4> so... why NIH assert()?
[22:51] <michaelni> wm4, is there an existing system that could be used ?
[22:52] <michaelni> some asserts are in speed critical code, some are checking conditions that the author really wants to be checked because failure may have security implications and theres no speed effect of te extra check
[22:53] <michaelni> so more than just 1 assert function is needed
[22:55] <wm4> what's the security issue?
[22:57] <michaelni> wm4, i dont understand the question
[22:58] <wm4> also, any reason why vf_scale uses AVFrame.color_range but not AVFrame.colorspace?
[22:58] <wm4> well you said "failure may have security implications"
[22:58] <wm4> if the assert is not compiled?
[22:58] <michaelni> well an example of  a security related assert would be "av_assert0(pics <= MAX_DELAYED_PIC_COUNT);"
[22:59] <michaelni> you would write out of array if that fails and isnt stoped there
[22:59] <wm4> ok...
[23:01] <michaelni> vf_scale does use AVFrame.colorspace
[23:01] <michaelni> inv_table = parse_yuv_type(scale->in_color_matrix, av_frame_get_colorspace(in));
[23:03] <wm4> hm, maybe it doesn't work for me
[23:04] <michaelni> you have to specify "auto"  as colorspace, which i wanted to make default after more tests
[23:06] <wm4> ok it does work with auto
[23:06] <wm4> why does vf_scale has its own array of coefficients instead of using the swscale functions?
[23:14] <cone-300> ffmpeg.git 03Michael Niedermayer 07master:f3f4e133d6a0: avfilter/vf_scale: use sws_getCoefficients()
[23:26] <durandal_1707> checking pointer that points out of array is safe or not?
[23:42] <durandal_1707> do you want to review my cosmetics patches?
[23:44] <wm4> durandal_1707: AFAIK out of bound pointers are never safe... unless they point right at the end of the valid range
[23:46] <durandal_1707> i have 10 patches here
[00:00] --- Sat Jul 27 2013