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

[burek]

[00:30] <CIA-101> ffmpeg: 03Michael Niedermayer 07master * rbbe25b4f3e 10ffmpeg/libavcodec/mjpegdec.c: 
[00:30] <CIA-101> ffmpeg: ljpegdec: support non zero MCU for RGB. 2nd try
[00:30] <CIA-101> ffmpeg: Fixes Ticket875
[00:30] <CIA-101> ffmpeg: Compared to patch 1 this fixes a bright line at the right side.
[00:30] <CIA-101> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:30] <CIA-101> ffmpeg: 03Michael Niedermayer 07master * r53918a1c54 10ffmpeg/libavcodec/dca.c: 
[00:30] <CIA-101> ffmpeg: dca: Fix uninitialized variable warnings.
[00:30] <CIA-101> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:30] <CIA-101> ffmpeg: 03Michael Niedermayer 07master * ra407baba85 10ffmpeg/libavcodec/g723_1.c: 
[00:30] <CIA-101> ffmpeg: g723_1: Fix "libavcodec/g723_1.c:988:8: warning: assignment from incompatible pointer type [enabled by default]"
[00:30] <CIA-101> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:30] <CIA-101> ffmpeg: 03Michael Niedermayer 07master * r2d6f317d71 10ffmpeg/libavcodec/jpeglsdec.c: 
[00:30] <CIA-101> ffmpeg: jpegdec: support ilv=1 grayscale jpeg-ls.
[00:30] <CIA-101> ffmpeg: Fixes Ticket851
[00:40] <OanaStratulat> ubitux: ping
[00:40] <ubitux> yup
[00:40] <OanaStratulat> have time to discuss about the bug earlier reported?
[00:41] <ubitux> yeah somehow
[00:41] <ubitux> did you find something?
[00:42] <OanaStratulat> my valgrind report is http://pastebin.com/hVS9n4is
[00:42] <ubitux> oh so you fixed your valgrind? :)
[00:42] <OanaStratulat> working on ubuntu, i`m not using osx no more because of valgrind, i`m not sure it is stable
[00:43] <ubitux> hehe ok :)
[00:43] <OanaStratulat> my valgrind has a patch for memory on osx, and maybe it is faulty
[00:43] <OanaStratulat> so you say the problem is in decode_frame ?
[00:45] <ubitux> i'm not saying this, valgrind is
[00:46] <OanaStratulat> ubitux: avctx->reget_buffer(avctx, f)) this is line 255
[00:46] <OanaStratulat> what does reget_buffer do? copy struct avctx in f ?
[00:47] <OanaStratulat> michaelni: please extend time for http://www.google-melange.com/gci/task/view/google/gci2011/7195360 . working on it as we speak
[00:47] <ubitux> look at libavcodec/avcodec.h, and libavcodec/utils.c for the default reget_buffer
[00:49] <OanaStratulat> ubitux: cr buffer what is it?
[00:50] <ubitux> chroma red i guess
[00:50] <ubitux> https://en.wikipedia.org/wiki/YCbCr
[00:51] <OanaStratulat> ubitux: so basically is like a copy function no?
[00:53] <ubitux> it get a chroma red buffer "again" i guess
[00:54] <ubitux> and it seems to copy the old frame at some point
[00:54] <ubitux> not sure of the details, i don't know that code
[00:54] <OanaStratulat> but my problem is that it wants to copy unallocated space no?
[00:55] <ubitux> the invalid reads may suggest it tries to copy by reading to much of the temp_pic
[00:56] <ubitux> so i'd check how temp_pic is allocated, and also if the the width & height look valid
[00:56] <OanaStratulat> temp_pic being the f struct ?
[00:57] <ubitux> i'm looking in avcodec_default_reget_buffer right now
[00:57] <ubitux> but you will certainly need to check the passed avframe pic yes
[00:58] <OanaStratulat> where is AVframe struct declared to see its members ?
[00:58] <ubitux> you should use some ctags or something with your editor ;)
[00:59] <ubitux> it's in libavcodec/avcodec.h
[00:59] <ubitux> anyway, just add some av_log(0,0,"... everywhere to debug and understand the code
[00:59] <OanaStratulat> ctags ? what are those ?
[01:00] <ubitux> it helps browsing code
[01:00] <ubitux> if your editor has an integration with it, you can jump to struct, functions, macros definition with a keyboard shortcut
[01:02] <OanaStratulat> i`m using gedit
[01:03] <ubitux> check gedit-symbol-browser-plugin maybe
[01:03] <ubitux> or sth like that
[01:05] <OanaStratulat> my height and width are 0
[01:05] <OanaStratulat> for the error frames
[01:06] <OanaStratulat> http://pastebin.com/vN1UXuee
[01:13] <OanaStratulat> but wait, any video file must have frames with width and height !=0 no?
[01:19] <OanaStratulat> ubitux: ^
[01:20] <ubitux> mmh i guess that's not correct but i can't confirm; try looking at various other codecs, and also check if it happens with valid files
[01:21] <OanaStratulat> so you don`t think that my affirmation is good ?
[01:21] <ubitux> it's not i don't think, it's i don't know :)
[01:21] <ubitux> without context, obviously a frame needs a height & width
[01:22] <OanaStratulat> it`s a bit illogical to have a video file with frames that have width and height 0, it`s like having video with only audio. and fraps it`s a video coded for videogames
[01:22] <OanaStratulat> codec*
[01:23] <ubitux> yes i agree, but if the frame fails to decode, maybe the helpers are supposed to deal with a frame with width or height = 0
[01:23] <ubitux> but i don't know the api enough
[01:23] <OanaStratulat> my neither 
[01:23] <ubitux> then stare at the code ;)
[01:23] <ubitux> and do more debug :)
[01:23] <OanaStratulat> AVFrame * const f = (AVFrame*)&s->frame; 
[01:24] <OanaStratulat> here is f initialized and for the error frames it`s initialized with 0 height and width
[01:25] <OanaStratulat> s being the fraps context which has data from AVCodecContext *avctx
[01:26] <OanaStratulat> michaelni: ping
[01:27] <ubitux> isn't reget_buffer supposed to set the width/height based on the context width/height values?
[01:28] <ubitux> (reget_buffer or another function)
[01:28] <OanaStratulat> but i get 0 width and height from the start
[01:28] <OanaStratulat> right after the header of decode_frame, after the declarations
[01:28] <ubitux> that's the frame from the local context
[01:28] <ubitux> by default all fields are zero
[01:29] <OanaStratulat> so AVCodecContext *avctx has all fields 0?
[01:29] <ubitux> i was refering to the fraps context (declared on top of the file)
[01:30] <OanaStratulat> http://pastebin.com/uGGCYYXi the fraps context has its data from avctx
[01:30] <OanaStratulat> FrapsContext * const s = avctx->priv_data;
[01:30] <OanaStratulat> and then AVFrame * const f = (AVFrame*)&s->frame;
[01:31] <ubitux> the get_buffer() callback (see avcodec_default_get_buffer -> video_get_buffer()) sets the width/height of the frame using the avcodeccontext if everything goes fine
[01:31] <ubitux> yes
[01:31] <OanaStratulat> so it must have data in it right?
[01:31] <ubitux> the frapscontext is allocated and put in the priv_data of the codex context
[01:32] <ubitux> but when it is allocated, it has all its value to zero
[01:32] <ubitux> and the fraps decoder is supposed to use them internally
[01:32] <OanaStratulat> ahh, so the real problem is in reget_buffer
[01:32] <ubitux> so basically, the AVFrame declared in the frapscontext is just filled with zero
[01:33] <ubitux> well, check any function where the frame is passed
[01:33] <ubitux> it might be supposed to init the width/height correctly
[01:33] <ubitux> check with a valid fraps file if they are init after calling reget_buffer
[01:33] <OanaStratulat> ok
[01:39] <OanaStratulat> ubitux: no, they are still 0 with a good fraps file
[01:41] <OanaStratulat> i have put an av_log after each switch case and used different versions
[01:46] <OanaStratulat> i have checked the witdh and height in default_reget_buffer and they are !=0 
[01:47] <OanaStratulat> ubitux: when it executes av_picture_copy((AVPicture*)pic, (AVPicture*)&temp_pic, s->pix_fmt, s->width,s->height); gives the segfault
[01:52] <durandal_1707> when width or height is 0?
[01:52] <OanaStratulat> before calling reget_buffer they are zero and reget_buffer must set them
[01:52] <OanaStratulat> in avcodec_default_reget_buffer they are initialized with good values but the segfault appears when ffmpeg executes av_picture_copy((AVPicture*)pic, (AVPicture*)&temp_pic, s->pix_fmt, s->width,s->height);
[01:59] <OanaStratulat> ubitux: ping
[02:00] <OanaStratulat> when a var has & in front of it like &temp_pic what does it mean ?
[02:01] <ubitux> the address of temp_pic
[02:01] <OanaStratulat> can the address be negative ?
[02:01] <OanaStratulat> temp_pic : -1098108784
[02:01] <ubitux> a pointer is unsigned
[02:01] <OanaStratulat> like this 
[02:01] <ubitux> print it with %p
[02:02] <OanaStratulat> 0xbee21090
[02:02] <OanaStratulat> is this valid?
[02:02] <ubitux> should be
[02:02] <OanaStratulat> how can i find if it is valid?
[02:02] <ubitux> assume it is if not NULL ;)
[02:03] <ubitux> or not too low
[02:03] <ubitux> did you notice something different with width/height between the valid and the invalid fraps?
[02:04] <OanaStratulat> it`s the same
[02:04] <OanaStratulat> the problem is not there i think
[02:04] <ubitux> ok
[02:05] <OanaStratulat> i think the problem is in av_picture_copy 
[02:05] <OanaStratulat> in the source AVPicture or destination
[02:05] <ubitux> generally, "primitive" functions are fine, because they are well tested
[02:06] <ubitux> OTOH, input sent to those functions might be "invalid"
[02:06] <ubitux> or not expected by the function
[02:06] <ubitux> and av_picture_copy is a commonly used function
[02:06] <OanaStratulat> the input for this function is bad surely
[02:06] <OanaStratulat> is there any way i can check for this?
[02:07] <ubitux> i don't have any ultimate rule for this, use your common sense :p
[02:09] <OanaStratulat> utils temp_pic : 0xbe9fa090    utils pic : 0x4e8b544
[02:09] <OanaStratulat> this are my addresses for the src and destianation
[02:10] <ubitux> remember: valgrind says there is overread
[02:11] <OanaStratulat> overread meaning reading out of memory?
[02:11] <ubitux> like if the destination buffer would have less bytes allocated than requested for copy
[02:11] <ubitux> mmh invalid read so source* and not destination
[02:11] <OanaStratulat> so a good way is to check the size of eachother ?
[02:12] <ubitux> Invalid read of size 4  invalid read when trying to memcpy
[02:12] <ubitux> look where the source pointer is allocated
[02:12] <ubitux> print the size
[02:12] <ubitux> and then look how much byte is requested to copy
[02:12] <OanaStratulat> is there any function for the size?
[02:12] <ubitux> you can't easily print the size allocated with the pointer only
[02:12] <OanaStratulat> sizeof() will work?
[02:13] <ubitux> you have to look where it is allocated in the code
[02:14] <ubitux> sizeof works only if it's an array on the stack (or any common type)
[02:14] <ubitux> but if it's a pointer it will print the size of a pointer
[02:15] <ubitux> (4 for 32 bits, 8 for 64, ...)
[02:15] <OanaStratulat> yes...av_log(0,0,"utils temp_pic : %d\n",sizeof((AVPicture*)&temp_pic));     av_log(0,0,"utils pic : %d\n",sizeof((AVPicture*)pic));   the same sizeof 
[02:15] <OanaStratulat> done it now 
[02:15] <ubitux> look at where temp_pic and pic are allocated
[02:15] <ubitux> and their respective sizes
[02:16] <ubitux> void *p = av_malloc(100)  this will returns a pointer pointing on an area in the memory where you have 100B available
[02:16] <ubitux> you must not overread or overwrite
[02:17] <OanaStratulat>  temp_pic = *pic;  is this where temp_pic is allocated ?
[02:17] <ubitux> and it's likely the parameter of the memcpy makes it overread
[02:17] <ubitux> it's just copying the content here
[02:18] <OanaStratulat> temp_pic is AVFrame temp_pic; how do i know where it is allocated ?
[02:18] <OanaStratulat> this is the blackout for me
[02:18] <ubitux> here the AVFrame temp_pic is allocated on the stack
[02:18] <ubitux> just like a local variable
[02:18] <ubitux> what are the parameter of the read?
[02:18] <ubitux> s/read/memcpy/ sorry
[02:20] <OanaStratulat> the memcpy from the valgrind report?
[02:20] <ubitux> isn't it trying to copy from temp_pic->data to pic->data?
[02:20] <OanaStratulat> did not find this, dunno where to look
[02:21] <ubitux> ok well
[02:21] <ubitux> looking at avcodec_default_reget_buffer, you receive a AVFrame *pic
[02:21] <ubitux> locally, you have AVFrame temp_pic
[02:21] <ubitux> with temp_pic = *pic;
[02:21] <OanaStratulat> yes
[02:22] <ubitux> this means you have two AVFrame with the exact same content at that time, right?
[02:22] <OanaStratulat> yes
[02:22] <ubitux> so same pointers, same width/height attributes, etc
[02:22] <ubitux> then pic is changed with s->get_buffer()
[02:22] <ubitux> and after that you get a av_picture_copy(pic, temp_pic
[02:22] <ubitux> so from temp_pic (original picture)
[02:23] <ubitux> to the new one (pic)
[02:23] <ubitux> but pic got change in the get_buffer
[02:23] <ubitux> you may want to look in that direction
[02:23] <ubitux> the av_picture_copy fails, so it's likely the pic got changed wrongly after the s->get_buffer()
[02:24] <ubitux> at least, this is what the code suggest, i might be wrong as usual
[02:24] <OanaStratulat> now i understand what you`re saying, the code thinks that they are the same and try to copy but one of the members got scrambled and it fails
[02:29] <OanaStratulat> ubitux: AVMediaType epecially s->codec_type how do i print it?
[02:30] <ubitux> source and destination are the same at first (i guess because it needs to keep the same properties), then the destination is changed (maybe wrongly) and the copy happens; but since it's the source which is at fault, maybe i was wrong with get_buffer, and you need to check how the original AVFrame *pic is allocated
[02:30] <ubitux> it's an int, print it with %d
[02:31] <ubitux> it should be 0 for video
[02:31] <OanaStratulat> yes
[02:32] <OanaStratulat> pff video_get_buffer is too complicated for me to understand
[02:35] <OanaStratulat> i think i`ll stick to check the size for each var, the pic and temp_pic
[02:36] <OanaStratulat> i cannot find where pic and temp_pic are allocated, where i find them they are only *
[02:40] <OanaStratulat> ubitux: maybe michaelni has another idea
[02:40] <ubitux> heh he certainly have more insight on the issue than me yes
[02:41] <OanaStratulat> ubitux: anyway i`m feeling a bit overwhelmed by this bug, it`s not comparable with the others i have fixed
[02:42] <ubitux> the bug might be simple to fix, but since i'm not familiar with that code, i can't really help in spotting the source of the issue
[02:42] <durandal_1707> there is av_image_check_size()
[02:42] <OanaStratulat> and works for pointers dirrectly?
[02:43] <durandal_1707> there is no point to continue if width or height is 0
[02:44] <OanaStratulat> i was checking for width and height int the wrong place
[02:54] <OanaStratulat> anyway i think i need to talk with michaelni , otherwise i`m on a wild goose chase. closing the night here. good night guys
[04:21] <CIA-101> ffmpeg: 03Paul B Mahol 07master * r17aa02b9a1 10ffmpeg/libavcodec/interplayvideo.c: 
[04:21] <CIA-101> ffmpeg: interplayvideo: Handle changed video dimensions on the fly
[04:21] <CIA-101> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[04:21] <CIA-101> ffmpeg: 03Martin Storsjö 07master * rc5d907b6b0 10ffmpeg/libavcodec/utils.c: 
[04:21] <CIA-101> ffmpeg: libavcodec: Handle param change side data in avcodec_decode_video2, too
[04:21] <CIA-101> ffmpeg: Also call avcodec_set_dimensions on dimension param change packets.
[04:21] <CIA-101> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[04:21] <CIA-101> ffmpeg: 03Janne Grunau 07master * r73b16198b6 10ffmpeg/libavformat/electronicarts.c: 
[04:21] <CIA-101> ffmpeg: electronicarts: check bytes per sample for validity
[04:21] <CIA-101> ffmpeg: Prevents division by zero.
[04:21] <CIA-101> ffmpeg: 03Michael Niedermayer 07master * rb18a0cc781 10ffmpeg/libavcodec/ivi_common.c: 
[04:21] <CIA-101> ffmpeg: indeo5: Fix null pointer dereference.
[04:21] <CIA-101> ffmpeg: Bug found by: Oana Stratulat
[04:21] <CIA-101> ffmpeg: Signed-off-by: Janne Grunau <janne-libav at jannau.net>
[04:21] <CIA-101> ffmpeg: 03Martin Storsjö 07master * r867f923df4 10ffmpeg/libavcodec/utils.c: 
[04:21] <CIA-101> ffmpeg: libavcodec: Move apply_param_change up above avcodec_decode_video2
[04:22] <CIA-101> ffmpeg: 03Justin Ruggles 07master * r77c5b66cbe 10ffmpeg/ (libavcodec/g722enc.c tests/ref/acodec/g722): 
[04:22] <CIA-101> ffmpeg: g722enc: set frame_size, and also handle an odd number of input samples
[04:22] <CIA-101> ffmpeg: The fate reference is updated because the previous test skipped a sample in
[04:22] <CIA-101> ffmpeg: each encode() call due each input frame having an odd number of samples.
[04:22] <CIA-101> ffmpeg: 03Justin Ruggles 07master * r52e9854a83 10ffmpeg/libavcodec/tta.c: 
[04:22] <CIA-101> ffmpeg: tta: fix 24-bit decoding.
[04:22] <CIA-101> ffmpeg: Decode to the correct output buffer.
[04:22] <CIA-101> ffmpeg: 03Vitor Sessak 07master * r96219141e2 10ffmpeg/libavcodec/mpegaudiodec.c: 
[04:22] <CIA-101> ffmpeg: mpegaudiodec: Use clearer pointer math
[04:22] <CIA-101> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[04:22] <CIA-101> ffmpeg: 03Mike Melanson 07master * r15f073ee6d 10ffmpeg/tests/ (fate/demux.mak ref/fate/xmv-demux): 
[04:22] <CIA-101> ffmpeg: FATE: xmv-demux test; exercise the XMV demuxer without decoding the perceptual codecs inside.
[04:22] <CIA-101> ffmpeg: Code coverage:
[04:22] <CIA-101> ffmpeg: libavformat/xmv.c: 3% -> 91%
[04:22] <CIA-101> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[04:22] <CIA-101> (63 lines omitted)
[04:23] Action: michaelni hates chello
[04:23] <Daemon404> you mean cello?
[04:24] <michaelni> i mean my fine ISP
[04:24] <michaelni> spend 5min doing the merge, 3 hours to push it 
[04:24] <Daemon404> woah what?
[04:25] <Daemon404> that's like sub-dialup speed
[04:25] <michaelni> and i could only copy 3 of 4 new fate samples to our server
[04:25] <michaelni> less than 1kb/sec download
[04:25] <Daemon404> pretty sure you could getter a better rate by printing out a hex dump and driving to the data center
[04:26] <michaelni> i was just preparing to reboot and setup a connection over 3G
[04:26] <michaelni> when suddenly it worked again
[04:27] <Daemon404> i thought europe was supposed to have godd nets
[04:27] <Daemon404> good*
[04:43] <CIA-101> ffmpeg: 03Michael Niedermayer 07master * rce39ba92c0 10ffmpeg/tests/fate/video.mak: 
[04:43] <CIA-101> ffmpeg: fate: enable wc4-xan test, the sample is now on our rsync server.
[04:43] <CIA-101> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[04:58] <durandal_1707> guess ffmpeg doesn't handle midstream width/height size changes
[04:59] <durandal_1707> ffplay doesn't have that problem
[07:52] <CIA-101> ffmpeg: 03Ronald S. Bultje 07release/0.5 * r3eb6983dbc 10ffmpeg/libavcodec/vp3.c: (log message trimmed)
[07:52] <CIA-101> ffmpeg: vp3: fix oob read for negative tokens and memleaks on error.
[07:52] <CIA-101> ffmpeg: (cherry picked from commit 8370e426e42f2e4b9d14a1fb8107ecfe5163ce7f)
[07:52] <CIA-101> ffmpeg: Fixes: #189
[07:52] <CIA-101> ffmpeg: Chromium-Bug: 101172,100465
[07:52] <CIA-101> ffmpeg: CVE-2011-3892
[07:52] <CIA-101> ffmpeg: Removed the parts that are related to multi-threading, which is not
[07:53] <CIA-101> ffmpeg: 03Chris Evans 07release/0.5 * r665421f3b1 10ffmpeg/libavcodec/vorbis.c: (log message trimmed)
[07:53] <CIA-101> ffmpeg: vorbis: Avoid some out-of-bounds reads
[07:53] <CIA-101> ffmpeg: Fixes Bug: #190
[07:53] <CIA-101> ffmpeg: Chromium Bug: #100543
[07:53] <CIA-101> ffmpeg: Related to CVE-2011-3893
[07:53] <CIA-101> ffmpeg: Signed-off-by: Reinhard Tartler <siretart at tauware.de>
[07:53] <CIA-101> ffmpeg: (cherry picked from commit 57cd6d709565e84e84385f8f2a9641ca3fa718be)
[07:53] <CIA-101> ffmpeg: 03Chris Evans 07release/0.5 * r7ee536e87a 10ffmpeg/libavformat/matroskadec.c: (log message trimmed)
[07:53] <CIA-101> ffmpeg: matroskadec: Fix a bug where a pointer was cached to an array that might later move due to a realloc()
[07:53] <CIA-101> ffmpeg: Fixes bug #190
[07:53] <CIA-101> ffmpeg: Chromium bug #100492
[07:53] <CIA-101> ffmpeg: related to CVE-2011-3893
[07:53] <CIA-101> ffmpeg: Signed-off-by: Reinhard Tartler <siretart at tauware.de>
[07:53] <CIA-101> ffmpeg: (cherry-picked from commit faaec4676cb4c7a2303d50df66c6290bc96a7657)
[07:53] <CIA-101> ffmpeg: 03Michael Niedermayer 07release/0.5 * r7209c2b13f 10ffmpeg/: 
[07:53] <CIA-101> ffmpeg: Merge remote-tracking branch 'qatar/release/0.5' into release/0.5
[07:53] <CIA-101> ffmpeg: * qatar/release/0.5:
[07:53] <CIA-101> ffmpeg:  matroskadec: Fix a bug where a pointer was cached to an array that might later move due to a realloc()
[07:53] <CIA-101> ffmpeg:  vorbis: Avoid some out-of-bounds reads
[07:53] <CIA-101> ffmpeg:  vp3: fix oob read for negative tokens and memleaks on error.
[07:53] <CIA-101> ffmpeg: Merged-by: Michael Niedermayer <michaelni at gmx.at>
[07:53] <CIA-101> ffmpeg: 03Ronald S. Bultje 07release/0.6 * rc9c7db0af2 10ffmpeg/libavcodec/vp3.c: (log message trimmed)
[07:53] <CIA-101> ffmpeg: vp3: fix oob read for negative tokens and memleaks on error.
[07:53] <CIA-101> ffmpeg: (cherry picked from commit 8370e426e42f2e4b9d14a1fb8107ecfe5163ce7f)
[07:53] <CIA-101> ffmpeg: Fixes: #189
[07:53] <CIA-101> ffmpeg: Chromium-Bug: 101172,100465
[07:53] <CIA-101> (74 lines omitted)
[09:58] <OanaStratulat> michaelni: ping
[11:24] <CIA-101> ffmpeg: 03Stefano Sabatini 07master * r5ccdb907c1 10ffmpeg/ffprobe.c: 
[11:24] <CIA-101> ffmpeg: ffprobe: use more meaningful names for writer chapter/section header/footer function
[11:24] <CIA-101> ffmpeg: The passed argument is supposed to be the chapter/section name, rather
[11:24] <CIA-101> ffmpeg: than the header/footer. Less confusing.
[11:24] <CIA-101> ffmpeg: 03Stefano Sabatini 07master * rec624d7c5c 10ffmpeg/ffprobe.c: 
[11:24] <CIA-101> ffmpeg: ffprobe: use "%*" printf syntax in XML_INDENT() in place of a loop
[11:24] <CIA-101> ffmpeg: Possibly faster/cleaner.
[11:24] <CIA-101> ffmpeg: Suggested-By: Clément BSsch <ubitux at gmail.com>
[14:40] <Jonno> I saw your call for a Debian/Ubuntu maintainer on your homepage and has been thinking about it since.
[14:40] <Jonno> Are you looking for FFmpeg packages to replace the current Libav packages in Debian and Ubuntu, or for something that can be installed in parallel?
[14:41] <Jonno> I'm asking because I'm already doing most of the required work for the former for my Ubuntu PPA ( https://launchpad.net/~jon-severinsson/+archive/ffmpeg ),
[14:41] <Jonno> and I would be willing to take the plunge and try to push it upstream (applying to become a Debian Maintainer in the process)
[14:52] <ubitux> Jonno: hi, it's not to replace the libav package, but allowing debian/ubuntu users to choose between the two projects
[14:53] <Jonno> ubitux: OK, that is a bit more complicated to pull off...
[14:53] <ubitux> libav and ffmpeg are two distinct projects and we are not willing to "destroy" libav :p
[14:53] <ubitux> well, the packages can be in conflict
[14:54] <ubitux> (and that will certainly be required)
[14:54] <Jonno> ubitux: Yes, but you will still have lots of problems with what to build agains, and what that implies for dependencies.
[14:55] <ubitux> ffmpeg is trying to keep ABI compatibility with libav
[14:55] <ubitux> so it shouldn't cause issues as long as the application linking with doesn't use specific ffmpeg features
[14:56] <Jonno> Yes, but there is both a "should" and an "if" in that sentence.
[14:58] <ubitux> I don't know debian and the packaging politics very well, so I'm afraid I won't be of much help right now
[14:58] <ubitux> maybe you can discuss the matter with michaelni, or siretart who is the libav debian package maintainer
[14:58] <Jonno> I guess if you built against libav by default, and let packages build against libav work with (libav | ffmpeg), and packages build agains ffmpeg depend on "ffmpeg" that *should* work as long as you keep version numbers straight and ffmpeg relly manages to keep ABI compatibility
[14:59] <Jonno> Still, more work than I'm willing to put into it right now...
[15:11] <siretart> Jonno: keep in mind that the two projects are definitly not ABI compatible.
[15:13] <iive> Jonno: imho libav and ffmpeg cannot coexist on same system, so there is no point trying to do that at the moment.
[15:14] <iive> so just try to make a package for ffmpeg that could be installed on debian/ubuntu.
[15:14] <j-b> well,  FFmpeg is safer than libav, security-wise...
[15:18] <Jonno> siretart: I thought ffmpeg was backwards compatible with libav, but libav was not backwards compatible with ffmpeg.  My experiences with my PPA shows that to be the case too.
[15:18] <Jonno> iive: No they can not coexist on the same system, but to coexist in the same software repository, packages depending on them must be able to work with either of them installed, or every package using ffmpeg/libav would have exist in two versions in the archive, which wouln't be acceptable.
[15:20] <Jonno> iive: My ppa contains such a package, but if uploaded to the main archive it would replace the libav packages (as they include the same binary packages, but the ffmpeg packages have a higher version number).
[15:21] <iive> aren't libav packages under different name?
[15:21] <iive> i mean, they don't use ffmpeg name, do they?
[15:24] <Jonno> iive: Both ffmpeg and libav contains the following packages with the same names: ffmpeg libavutil51 libavcodec53 libavdevice53 libavformat53 libavfilter2 libpostproc52 libswresample0 libswscale2 libavutil-dev libavcodec-dev libavdevice-dev libavformat-dev libavfilter-dev libpostproc-dev libswresample-dev libswscale-dev
[15:24] <Jonno> Additionally libav contains libav-dbg libav-source and libav-doc (plus ffmpeg-dbg and ffmpeg-doc transitional packages), while my ffmpeg packages contains ffmpeg-dbg ffmpeg-source and ffmpeg-doc (plus libav-dbg and libav-doc transitional packages)
[15:25] <Jonno> In the libav source package the ffmpeg binary package contains the ffmpeg, ffplay ffserver and ffprobe binaries.
[15:25] <iive> ouch....
[15:27] <Jonno> Yea, I guess you could use ffmpeg and libav as two separate binary packages conflicting with each other, and make libavutil51 etc a virtual package for libavutil-ffmpeg-51 or libavutil-libav-51 etc, and drop the transitional packages. However, dependencies for anything built agains any lib*-dev package from either source package would be a nightmare...
[15:27] <iive> breaking the package on mini-packages. It may be good idea to keep the project name as prefix for all of them. so it becomes ffmpeg-libavutil and libav-libavutil
[15:28] <Jonno> iive: The debian standard in such case is libavutil-*-soversion
[15:29] <iive> Jonno: then change the standard.
[15:30] <greentemik> Hi! My question is anyone could pls help me to compile ffmpeg on freebsd with v4l support?
[15:30] <iive> or you mean.. libavutil-ffmpeg-soversion?
[15:30] <siretart> Jonno: ABI compatibility is not a one-way deal, either two libraries are or they are not as far as applications that link against them are concerned
[15:31] <Jonno> iive: yes, that is what I meant, eg the binary packages libavutil-ffmpeg-51 or libavutil-libav-51 (and on ubuntu libavutil-ffmpeg-extra-51 or libavutil-libav-extra-51) would al provide the virtual package libavutil51
[15:32] <iive> Jonno: well... typical debian... making things their own way. sorting by first name would have grouped related packages together... but that's advantage for humans not scripts.
[15:32] <siretart> Jonno: you cannot make library packages 'virtual'. That'll break versioned dependencies and the shlibs system
[15:32] <Jonno> .siretart: Of coure they are one way. For example ffmpeg-0.7.10 is backwards compatible with ffmpeg-0.7.1, but ffmpeg-0.7.1 is not compatible with ffmpeg-0.7.10
[15:34] <siretart> Jonno: sure. and?
[15:36] <iive> Jonno: so, there is no problem is your ffmpeg packages like libavutil-ffmpeg-51 ?
[15:36] <iive> is/if
[15:37] <Jonno> siretart: I know, they would be "virtual" in the same sense that libavutil-extra-51 "provides" libavutil51 in ubunti, eg you make all packages depending on them have a verry uggly dependancy libavcodec-ffmpeg-53 (>= 0.8.7-1) | libavcodec-ffmpeg-extra-53 (>= 0.8.7) | libavcodec-libav-53 (>= 0.7.2-1) | libavcodec-libav-extra-53 (>= 0.7.2)
[15:39] <Jonno> iive: Well, I would also have to change the libav packages, in order to allow packages build against libav to depend on either ffmpeg or libav, and then do a one-time rebuild of every package depending on libav/ffmpeg...
[15:39] <siretart> Jonno: libavutil-extra-51 does not provide libavutil51 as that would blow up versioned depends.
[15:40] <siretart> Jonno: I've thought a long time about this, and I don't think there is a feasible solution
[15:41] <Jonno> siretart: Not in the "includes a Provides: line in debian/control" sence, but libavutil-dev contains a controll file making all packages that would depend on libavutil51 depend on libavutil51 | libavutil-extra-51 instead, which is realy just a more complex implementation of the same concept.
[15:42] <siretart> Jonno: as said, I don't think that's feasible
[15:44] <Jonno> siretart: What I'm saying is that there *is* a solution, but it is very complex (if it is feasible is a matter of opinion and work you are willing to put down. I'm not willing to put down that much work, but perhaps someone else is)
[15:44] <iive> Jonno: there are some projects that would prefer to be distributed linked against ffmpeg and that's not possible at the moment as there is no package in debian/ubuntu.
[15:45] <iive> so i think the first step would be to make it available and then solve the more complex problems.
[15:46] <iive> even using ffmpeg as standalone application would be a major improvement.
[15:48] <ubitux> it might require to --disable-ffmpeg on libav side, and --disable-avconv on ffmpeg side
[15:48] <ubitux> i'm not sure about the preset files too
[15:49] <ubitux> but i agree that having at first the tools available would be nice
[15:51] <Jonno> iive: ubitux: You can not make the applications availible without making the libraries availible too (well, with static linking you could, but that is strongly frowned upon in debian, and would never be accepted in the archive). And as the libraries are not co-installable you must solve the reverse dependancy problem first...
[16:06] <j-b> I don't get how some distros can live with security issues
[16:25] <Jonno> Well, even if it seems my packages won't make it to upstream, feel free to put a link to my ppa ( https://launchpad.net/~jon-severinsson/+archive/ffmpeg ) on the download page under "FFmpeg Linux Builds", next to the Debian link.
[16:25] <Jonno> The PPA provides builds for lucid/maverick/natty/oneiric/precise amd64 and i386.
[16:31] <michaelni> Hi Jonno
[16:31] <michaelni> thx alot for your interrest and effort :)
[16:32] <michaelni> yes, ill surely add a link to your ppas (that is unless you want to send a patch for the download page?)
[16:34] <michaelni> about debian packages, iam surely in favor of replacing libav by ffmpeg in main debian, it is technically the most sane decission but its not my decission ...
[16:41] <Jonno> michaelni: patch sent to ffmpeg-devel at ffmpeg.org
[16:44] <michaelni> Jonno, patch applied, thanks
[16:45] <ubitux> Jonno: thank you
[16:59] <Jonno> michaelni: ubitux: You are welcome
[16:59] <Jonno> got to go, bbl
[17:10] <CIA-101> ffmpeg: 03Clément BSsch 07master * r0c01947316 10ffmpeg/ (6 files in 3 dirs): lavfi: add audio silencedetect filter.
[17:42] <dilaroga> michaelni: no objection if i use pthread directly instead of lock manager in VDA ?
[17:57] <CIA-101> ffmpeg: 03Reimar Döffinger 07master * ree4ba9aecd 10ffmpeg/libavcodec/sgidec.c: 
[17:57] <CIA-101> ffmpeg: Fix incorrect increment in sgidec.c
[17:57] <CIA-101> ffmpeg: Fixes trac issue #899.
[17:57] <CIA-101> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
[17:57] <CIA-101> ffmpeg: 03Reimar Döffinger 07master * rfe21ea1798 10ffmpeg/tests/ (fate/microsoft.mak ref/fate/wmv8-x8intra): 
[17:57] <CIA-101> ffmpeg: Add wmv8-x8intra fate test.
[17:57] <CIA-101> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
[18:03] <michaelni> dilaroga, you are maintainer, its your decission what to use
[18:08] <dilaroga> ok, i will use pthread directly as it's already done in libav implementation
[18:11] <dilaroga> vda decoder only accepts 2 or 4 byte NAL sizes, I need to convert 3 byte NAL size extradata to 4 byte
[18:11] <dilaroga> http://pastie.org/3149418
[18:11] <dilaroga> ^ ^ this is the change i will push if no objection
[18:13] <nevcairiel> thats because 3 byte NAL size is invalid
[18:14] <nevcairiel> the patch looks wrong though, you also need to actually change the data thats going in to have a 4 byte NALsize  instead of 3
[18:15] <dilaroga> data have already 4 byte NAL size in the current implementation
[19:12] <CIA-101> ffmpeg: 03Reimar Döffinger 07master * raeeb0e6deb 10ffmpeg/ (3 files in 2 dirs): 
[19:12] <CIA-101> ffmpeg: indeo4, swresample: add some missing static/const to tables.
[19:12] <CIA-101> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
[19:19] <CIA-101> ffmpeg: 03Clément BSsch 07master * rca324f9869 10ffmpeg/tests/fate/ (11 files): fate: add generic rules for most of the remaining tests/fate/*.mak files.
[20:25] <dilaroga> michaelni: i pushed changes into my public repo, with 2 more cosmetic commits
[20:26] <michaelni> dilaroga, should i merge them ?
[20:26] <michaelni> or do you want me to wait ?
[20:27] <dilaroga> michaelni: yes, you can merge them, it's ok for me, I already tested these changes
[20:27] <michaelni> ok
[20:31] <OanaStratulat> michaelni: ping
[20:32] <michaelni> OanaStratulat, pong
[20:32] <OanaStratulat> do you have some time to help me with a bug?
[20:34] <OanaStratulat> michaelni: this is my valgrind report http://pastebin.com/g4PZmrZA  those av_logs are from utils.c with those vars
[20:34] <OanaStratulat> michaelni: as i found out so far the seg fault comes from av_picture_copy
[20:39] <OanaStratulat> michaelni: the file which makes the crash is http://google-melange.appspot.com/gci/work/download/google/gci2011/7195360?id=7001
[20:59] <OanaStratulat> michaelni: any suggestion ?
[21:03] <michaelni> the bug is in default_reget_buffer()
[21:05] <OanaStratulat> michaelni: yes, especially when it tries to execute the copy
[21:07] <OanaStratulat> michaelni: i have discussed with ubitux yesterday and he think that the src and destianation do not have the same size
[21:10] <michaelni> yes possible
[21:10] <ubitux> i suggested to check ;)
[21:10] <OanaStratulat> michaelni: how can i do that?
[21:11] <OanaStratulat> 1st of all i cannot find where the 2 vars are allcocated 
[21:18] <OanaStratulat> michaelni: can i check the size of the pic with avpicture_get_size?
[21:30] <OanaStratulat> michaelni: ^
[21:31] <michaelni> AVFrame.width/height/pix_fmt may work
[21:33] <OanaStratulat> michaelni: it does not work. av_log(0,0,"pic w : %d\n",pic.width);
[21:44] <ubitux> if pic is a pointer, pic->width
[21:45] <OanaStratulat> ubitux: av_log(0,0,"size pic : %d\n",avpicture_get_size((AVPicture*)pic->pix_fmt,(AVPicture*)pic->width,(AVPicture*)pic->height));
[21:45] <OanaStratulat> like this?
[21:46] <ubitux> why are you casting?
[21:46] <OanaStratulat> ubitux: please be more explicit
[21:46] <ubitux> (AVPicture*) is a cast
[21:46] <ubitux> (into a pointer to AVPicture)
[21:46] <OanaStratulat> so it does not need casting?
[21:47] <OanaStratulat> pic->pix_fmt without (AVPicture*) ?
[21:47] <ubitux> it's not that it's not needed, it's wrong; the cast applies to the final attribute
[21:48] <ubitux> also the avpicture_get_size will give you the size needed for a picture with pix_fmt of size width x height, but it won't tell you the allocated size in pic
[21:48] <OanaStratulat> mhmh
[21:48] <OanaStratulat> so wrong here too
[21:48] <OanaStratulat> i cannot find where this 2 vars are allcocated..
[21:48] <OanaStratulat> this is my biggest issue
[21:49] <OanaStratulat> ubitux: some hint?
[21:50] <ubitux> you need to check where pic->data is allocated iirc
[21:51] <OanaStratulat> i have done grep -r pic->data * in my ffmpeg folder and no results
[21:52] <ubitux> not related but you have the git grep command
[21:53] <OanaStratulat> no result, the same
[21:53] <ubitux> yes sure
[21:53] <ubitux> it might not be named "pic"
[21:53] <drv> make sure you escape the >
[21:53] <drv> otherwise it will be a shell redirection character
[21:53] <OanaStratulat> you think it is allocated in the fraps.c ?
[21:55] <ubitux> i don't know how the codecs work
[21:56] <OanaStratulat> michaelni: any hint?
[21:56] <durandal_1707> codecs operates like regular file compressor
[21:57] <durandal_1707> except there are lossy codecs so you lose some information
[22:00] <durandal_1707> should line 170 return INVALID_DATA instead?
[22:00] <OanaStratulat> durandal_1707: can you show me where the 2 vars from avctx->reget_buffer(avctx, f) are alloc ?
[22:00] <durandal_1707> guess it would not actually fix bug
[22:01] <durandal_1707> what frap version is that junk file?
[22:02] <OanaStratulat> durandal_1707: 4
[22:02] Action: durandal_1707 these code needs some refactoring
[22:03] <OanaStratulat> durandal_1707: http://google-melange.appspot.com/gci/work/download/google/gci2011/7195360?id=7001  this is the file
[22:04] <durandal_1707> you looked at avcodec_default_reget_buffer()?
[22:04] <OanaStratulat> yes, the segfault comes when it executes av_picture_copy()
[22:05] <OanaStratulat> but i cannot find the size of pic and temp_pic
[22:06] <durandal_1707> well it use memcpy
[22:07] <durandal_1707> looked at av_image_copy in libavutil/imgutils.c ?
[22:07] <OanaStratulat> nop
[22:08] <durandal_1707> so that file cause segfault for you?
[22:08] <OanaStratulat> yes
[22:08] <durandal_1707> doesn't for me
[22:08] <OanaStratulat> durandal_1707: so may i check here if dst_data[4] and src_data[4] are null or smth like that
[22:10] <durandal_1707> yes
[22:10] <durandal_1707> but they are already checked
[22:10] <durandal_1707> if the are null function just returns
[22:11] <durandal_1707> but line 259 is not checked
[22:11] <durandal_1707> but I doubt fraps use PAL pixfmt
[22:12] <OanaStratulat> mhmh
[22:12] <OanaStratulat> i am remaking ffmpeg as we speak to get the latest patches
[22:12] <OanaStratulat> and then check for the segfault again
[22:12] <OanaStratulat> you`re using the latest version no?
[22:12] <durandal_1707> tried that file yesterday too
[22:13] <durandal_1707> does others experience segfault?
[22:14] <OanaStratulat> ubitux: has the segfault again
[22:14] <durandal_1707> hmm, me too but with ffmpeg, ffplay survives
[22:16] <durandal_1707> hehe probably something corrupts complete stack
[22:21] <OanaStratulat> ok 
[22:21] <OanaStratulat> so you say line 259 should be the problem?
[22:22] <durandal_1707> fraps does not use PAL pixfmt
[22:22] <durandal_1707> so it can not be source of problem
[22:22] <OanaStratulat> my fuzzed file has PAL pixfmt ?
[22:23] <durandal_1707> no
[22:23] <OanaStratulat> durandal_1707: so i must further look into av_image_copy_plane no ?
[22:23] <durandal_1707> do you have full bt from gdb?
[22:24] Action: durandal_1707 hates building static ffmpeg with full debug symbols
[22:24] <OanaStratulat> yes
[22:25] <durandal_1707> paste it on pastebin or similar
[22:25] <OanaStratulat> http://pastebin.com/sp4iv3n0
[22:26] <durandal_1707> compile ffmpeg without optimizations
[22:26] <OanaStratulat> how to do that?
[22:29] <durandal_1707> --disable-optimizations
[22:30] <durandal_1707> you could also enable only some decoders and demuxers to speed up compilation on slow machine
[22:30] <OanaStratulat> doing it as we speak
[22:31] <OanaStratulat> what can you tell from the bt ?
[22:31] <OanaStratulat> michaelni: please extend my time....i haven`t figured out a solution http://www.google-melange.com/gci/task/view/google/gci2011/7195360
[22:33] <OanaStratulat_> durandal_1707: said smth ? connection went down
[22:33] <durandal_1707> nope :)
[22:34] <OanaStratulat_> durandal_1707: the problem is in av_image_copy_plane at memcpy
[22:36] <mcbaine1> hi there .. aloha
[22:41] <OanaStratulat_> durandal_1707: can src_linesizes be 0?
[22:42] <durandal_1707> that is invalid
[22:42] <OanaStratulat_> in my fuzzed file i get src_linesized 0 once
[22:42] <durandal_1707> it should not
[22:42] <OanaStratulat_> and then the segfault
[22:42] <OanaStratulat_> think this is the problem?
[22:42] <durandal_1707> find from where scr_linesize get 0
[22:45] <OanaStratulat_> av_picture_copy((AVPicture*)pic, (AVPicture*)&temp_pic, s->pix_fmt, s->width,s->height); s->height is the linesize
[22:46] <durandal_1707> where?
[22:46] <OanaStratulat_> in utils.c at reget_buffer
[22:46] <OanaStratulat_> then it calls av_image_copy(dst->data, dst->linesize, src->data,                   src->linesize, pix_fmt, width, height); from imgconvert.c
[22:47] <OanaStratulat_> wrong
[22:47] <OanaStratulat_> temp_pic->height is the linesize
[22:47] <durandal_1707> i think i found solution
[22:48] <OanaStratulat_> but i think the problem is that the code does not handle erros if linesize is 0, my fuzzed files has a frame with 0 linesize i think
[22:48] <durandal_1707> hint compare case 1: with case 4:
[22:49] <durandal_1707> case 4: is missing something
[22:49] <OanaStratulat_> does not compare the buffers
[22:50] <durandal_1707> so found difference?
[22:50] <OanaStratulat_> yes
[22:51] <OanaStratulat_> but now how can i calculate the correct buff size for the YUV420 ?
[22:52] <durandal_1707> by setting small limit and trying valid file and more hacking or learning code and come up with formula on your own
[22:54] <durandal_1707> huh they are huffman coded
[22:55] <OanaStratulat_> you`re losing me here :))
[23:03] <durandal_1707> OanaStratulat_: just call av_image_check_size() and see if that helps
[23:04] <OanaStratulat_> for pic and temp_pic ?
[23:04] <OanaStratulat_> in av_picture_copy ?
[23:05] <durandal_1707> no, in fraps.c
[23:05] <durandal_1707> or could check linesize in av_picture_copy
[23:06] <durandal_1707> but that one would make that function slower
[23:06] <OanaStratulat_> i `m checking linesize in av_picture_copy
[23:06] <OanaStratulat_> how to i use av_image_check_size for avctx, f ?
[23:07] <durandal_1707> find where function is defined
[23:07] <durandal_1707> it is in libavutil/imgutils.c
[23:07] <OanaStratulat_> it has 4 params width height log_offset and log_ctx
[23:08] <OanaStratulat_> log offset and log ctx are unknown for me
[23:08] <OanaStratulat_> offset being 0 and the ctx is avctx and f ?
[23:08] <durandal_1707> just set them to 0
[23:08] <OanaStratulat_> ok
[23:09] <OanaStratulat_> and the ctx is avctx and f ?
[23:09] <durandal_1707> 4th arg could be avctx
[23:10] <michaelni> OanaStratulat_, durandal_1707 the problem is mismatching w/h/pix_fmt between previous and current picture
[23:11] <OanaStratulat_> so it`s not the linesize ?
[23:11] <michaelni> best place to check for this is in avcodec_default_reget_buffer()
[23:11] <michaelni> rgb has linesizes X,0,0
[23:12] <michaelni> planar yuv has linesizes X Y Z
[23:12] <OanaStratulat_> michaelni: so how can i check that ? temp_pic is AVFrame and pic is also AVFrame
[23:12] <OanaStratulat_> temp_pic.pix_fmt ?
[23:12] <OanaStratulat_> like this?
[23:12] <durandal_1707> switching pix_fmt is not supported at all?
[23:13] <michaelni> it is supported but you cant reget a yuv buffer from a rgb buffer 
[23:14] <michaelni> the code should checl for mismatch and then release_buffer() + get_buffer()
[23:14] <michaelni> + av_log() 
[23:15] <OanaStratulat_> for pic how can i av_log the height
[23:15] <OanaStratulat_> i am having  error: request for member height in something not a structure or union 
[23:15] <michaelni> pic->height
[23:15] <OanaStratulat_> av_log(0,0,"%d\n",pic.height);
[23:15] <durandal_1707> lol, i would probably never found that file is using 2 different versions
[23:16] <durandal_1707> OanaStratulat_: compare old frame version with new one and do what michaelni said
[23:17] <OanaStratulat_> how to compare the version?
[23:17] <durandal_1707> loging picture height is irrelevant here
[23:18] <OanaStratulat_> how can i log the version?
[23:18] <durandal_1707> version is unsigned int
[23:18] <durandal_1707> and it is initialized at line 145
[23:19] <OanaStratulat_> i mean the member of the struct
[23:19] <OanaStratulat_> how it is named
[23:19] <durandal_1707> struct for what?
[23:20] <OanaStratulat_> you said to check the version of the frame with the previous one
[23:20] <OanaStratulat_> how can i find the version in the 1st plac
[23:20] <OanaStratulat_> place *
[23:20] <durandal_1707> it is on line 145
[23:20] <durandal_1707> version = header & 0xff
[23:21] <durandal_1707> add old_version and initialize it to -1
[23:21] <durandal_1707> but not in decode_frame but in FrapsContext
[23:22] <durandal_1707> no need to name it old_version just version would be fine
[23:22] <durandal_1707> then initialize s->version to -1 in decode_init
[23:23] <durandal_1707> so you could know if older version need to be compared with new one
[23:23] <OanaStratulat_> ok
[23:23] <durandal_1707> michaelni: when i tried different pix_fmt with cdxl it did not worked (ffplay)
[23:24] <OanaStratulat_> so now i compare avctx->version with f->version ?
[23:25] <durandal_1707> no, compare version in decode_frame() with s->version
[23:25] <durandal_1707> f->version is for decode_init
[23:25] <durandal_1707> wrong 
[23:25] <durandal_1707> it is s->version always
[23:26] <durandal_1707> I messed it up with AVFrame
[23:26] <OanaStratulat_> ok so if they are different ?
[23:26] <michaelni> maybe changing pix_fmt works only with ffmpeg
[23:26] <OanaStratulat_> av_log and exit program ?
[23:28] <durandal_1707> OanaStratulat_: and/or release_buffer()
[23:28] <OanaStratulat_> release buffer how ?
[23:29] <durandal_1707> decode_end() have example
[23:30] <OanaStratulat_> s->release_buffer(s,&s->frame) ?
[23:30] <durandal_1707> no avctx->....
[23:32] <OanaStratulat_> durandal_1707: http://pastebin.com/U8iR6J2H
[23:32] <OanaStratulat_> this is my output now
[23:35] <OanaStratulat_> michaelni: ping
[23:38] <OanaStratulat_> durandal_1707: what message should i put in my patch ?
[23:39] <durandal_1707> something like: av_log(avct, AV_LOG_INFO, "Multiple versions encountered in file\n");
[23:41] <OanaStratulat_> and what commit message ?
[23:43] <OanaStratulat_> durandal_1707: ^
[23:45] <durandal_1707> do not crash when decoding different versions in same file
[23:46] <durandal_1707> fraps: release_buffer when ....
[23:46] <durandal_1707> i'm really out of ideas
[23:47] <OanaStratulat_> Patch : release_buffer() when multiple versions are found in fraps file
[23:47] <OanaStratulat_> good for you?
[23:48] <durandal_1707> fraps: fix crash when mult...
[23:48] <durandal_1707> and use "git format-patch"
[23:49] <OanaStratulat_> yes
[23:49] <durandal_1707> oh, and dont write fraps twice
[23:51] <OanaStratulat_> ok
[23:52] <OanaStratulat_> durandal_1707: Fraps : fix crash when multiple versions are found in file
[23:52] <durandal_1707> no need for big _F_
[23:53] <durandal_1707> no need for extra whitespace
[23:53] <durandal_1707> fraps: fix....
[23:55] <OanaStratulat_> michaelni: ping
[23:57] <durandal_1707> OanaStratulat_: no need ping him multiple times
[00:00] --- Mon Jan  9 2012