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

[burek]

[00:04] <ubitux> heh, merge troubles incoming
[00:06] <wm4> ubitux: where
[00:06] <ubitux> the new 250-patches patchset from libav
[00:06] <wm4> ow
[00:06] <ubitux> changing AVFrame/AVPacket internals
[00:06] <ubitux> and mmh the way buffer ref are in lavfi
[00:07] <wm4> oh, could that be the change that makes AVFrames refcounted?
[00:07] <ubitux> yes
[00:09] <wm4> you weren't joking
[00:09] <wm4> it's really a 250 patches patchset...
[00:10] <wm4> on a second look... facepalm
[00:10] <ubitux> ?
[00:11] <wm4> he skips some numbers
[00:11] <ubitux> they are likely not yet sent
[00:11] <ubitux> spam filtering or sth
[00:12] <wm4> 114 follows 013 directly etc.
[00:12] <Compn> ahhh email
[00:12] <Compn> why havent we moved onto something better yet ?
[00:12] <Compn> auto encryption, no spam, etc
[00:19] <cone-504> ffmpeg.git 03Clément BSsch 07b684f744ac1e: ffmpeg: use avformat_seek_file() instead of av_seek_frame().
[00:19] <cone-504> ffmpeg.git 03Clément BSsch 07ff3624b1ad9d: lavf/subtitles: add ff_subtitles_queue_seek().
[00:19] <cone-504> ffmpeg.git 03Clément BSsch 07ad5d72b1235a: lavf/subtitles: seek a little more backward when necessary.
[00:19] <cone-504> ffmpeg.git 03Clément BSsch 07bad4e112a24a: lavf: use ff_subtitles_queue_seek() for text subtitles demuxers.
[00:19] <cone-504> ffmpeg.git 03Clément BSsch 07e0260e25b050: lavf/assdec: rewrite using the demux subtitles API.
[00:19] <cone-504> ffmpeg.git 03Clément BSsch 07069c89754967: lavf/assdec: add ass_ prefix to callbacks.
[00:19] <cone-504> ffmpeg.git 03Clément BSsch 076d2892c9f597: lavf/assdec: return appropriate error code instead of -1.
[00:24] <ubitux> hey saste :)
[00:25] <ubitux> so, what do you think about latest libav latest evil plan? :p
[00:25] <ubitux> saste: btw, divVerent noticed some different default sws flags with -filter_complex and -vf
[00:25] <ubitux> https://gist.github.com/4184471
[00:25] <ubitux> any idea why?
[00:26] <cone-504> ffmpeg.git 03Clément BSsch 07f61369d7621b: lavfi/vsrc: switch to ff_filter_frame.
[00:44] <cone-504> ffmpeg.git 03Carl Eugen Hoyos 07196920060b52: Add FourCC V264 for H264 in CCTV recordings.
[00:48] <Compn> nooooooooooooo not another fourcc!
[00:52] <cone-504> ffmpeg.git 03Michael Niedermayer 0777693c541a54: xxan: more complete ybuf checks, fix out of array accesses.
[01:02] <wm4> isn't reimar a ffmpeg dev, basically? why does he keep improving mplayer's demux_avi, instead of fixing ffmpeg's avi demuxer? it even had something to do with non-interleaved files
[01:04] <ubitux> wm4: Reimar has always been very conservative
[01:05] <ubitux> given the activity of mplayer, it might be a wise choice
[01:07] <ubitux> arg no date test for vf hue :(
[01:07] <ubitux> nyuhu! :(
[01:08] <wm4> what does the state of mplayer have to do with ffmpeg?
[01:10] <ubitux> my point was that he doesn't want switch mplayer's demuxer to ffmpeg's one because he is a bit conservative
[01:10] <ubitux> and thus there is no point for him to contribute to ffmpeg's avi one
[01:55] <nyuhu> ubitux : !
[01:55] <ubitux> nyuhu: too late, i've submitted a patch
[01:55] <ubitux> :p
[01:55] <nyuhu> :D
[01:55] <nyuhu> what it is about ?
[01:56] <ubitux> but i can still blame you
[01:56] <ubitux> the hue fate test :)
[01:56] <saste> nyuhu, ehy
[01:56] <nyuhu> oh
[01:56] <nyuhu> :D
[01:56] <nyuhu> hi saste 
[01:56] <saste> so many people still awake at 2:00
[01:56] <nyuhu> saturday night ;)
[01:56] <ubitux> :)
[01:57] <saste> let's party
[01:57] <saste> patchfest
[01:57] <ubitux> \o/
[01:58] <ubitux> saste: what's the reason for having buffer queue in alphamerge?
[01:58] <ubitux> oh ok multiple source, i'm stupid
[01:58] <saste> because you have two inputs
[01:58] <saste> and you can't predict the order of arrival of the frames
[01:59] <ubitux> yeah right ok
[02:00] <nyuhu> ubitux : what's the filter_frame callback ?
[02:00] <saste> nyuhu, now everything is much simpler ;-)
[02:00] <ubitux> nyuhu: a replacement for start_frame/draw_slice/end_frame :p
[02:01] <nyuhu> (sorry I have been REALLY busy with school during the past month)
[02:01] <nyuhu> oh
[02:02] <nyuhu> so how does it differ ?
[02:02] <ubitux> it's simpler
[02:02] <ubitux> just one callback
[02:02] <nyuhu> nice
[02:03] <wm4> it might be slower, but nobody could prove that yet
[02:04] <nyuhu> then Ill have to update my patches that are still on hold
[02:06] <nyuhu> so this is usually as fast as the draw_slice callback ?
[02:06] <ubitux> it should
[02:06] <ubitux> mostly :)
[02:07] <wm4> if the whole video frame doesn't fit into cache, and all filters support slices, and you have many chained filters, slices might be faster
[02:08] <nyuhu> k
[02:10] <saste> ubitux, allright i'll review my patches when i'll be awake, tomorrow
[02:10] <saste> goodnight
[02:10] <ubitux> 'night :)
[02:10] <nyuhu> o/
[02:39] <ubitux> why isn't ff_null_get_video_buffer the default when get_video_buffer is NULL?
[02:39] <ubitux> don't we need ff_default_get_video_buffer only for sinks?
[02:42] <cone-504> ffmpeg.git 03Clément BSsch 07a3554bb45737: lavfi/gradfun: avoid use of uninitialized variable.
[02:43] <wm4> ubitux: how many more filters do you have compared to libav?
[02:43] <ubitux> ~50
[02:44] <wm4> that's going to be a fun merge indeed
[02:44] <ubitux> :)
[02:44] <wm4> but the new design looks very reasonable
[02:44] <ubitux> i believe so as well, but i didn't look closely
[02:45] <wm4> it's basically exactly what I wanted - rather than the extremely hostile libavcodec DR interface
[02:53] <cone-504> ffmpeg.git 03Clément BSsch 079e1914dfbafb: lavfi/hqdn3d: avoid use of uninitialized variable.
[03:14] <ubitux> this direct thing looks inconsistent
[03:14] <ubitux> or at least inefficient
[03:29] <ubitux> michaelni: any idea how i could get read-only frame in the filtergraph?
[03:41] Action: ubitux doesn't understand the need of out_buf->video->w = outlink->w; out_buf->video->h = outlink->h after a avfilter_copy_buffer_ref_props() unless the output has a different size than the input
[03:43] <michaelni> ubitux, to get a read only frame, just drop write permission
[03:44] <ubitux> it doesn't seem enough
[03:45] <ubitux> for instance i tried to remove the AV_PERM_WRITE from the input min_perms in delogo
[03:45] <ubitux> but the in buffer still has write perm
[03:46] <michaelni> ubitux, i meant remove the write permission from the reference that you do not want to have write permissions
[03:47] <ubitux> or right sure ok, i was just wondering how to trigger it from the cmd line
[03:47] <ubitux> how can that happen?
[03:49] <michaelni> one could write a permission filter that drops specified permissions
[03:50] <ubitux> yes for testing purpose, but my question is more general :p
[03:50] <ubitux> how can that happen "in the wild"? :p
[03:52] <wm4> a filter that drops perms when passing it along?
[03:53] <ubitux> yes, so we can test if a filter behaves correctly when receiving for instance a read-only buffer
[03:54] <wm4> is there no filter that keeps a reference to a frame after filtering it?
[03:55] <ubitux> there are
[03:55] <ubitux> any filter caching at least a frame
[04:01] <ubitux> btw, i see no point in the direct thing in gradfun since it is ignored
[04:02] <ubitux> a write perm in the min_perms should be enough if direct is supported&
[04:03] <ubitux> also, it seems to use the preserve thing in the wrong manner, unless i'm mistaken
[04:03] Action: ubitux is confused
[04:03] <michaelni> remove this: " && !(in->perms & AV_PERM_PRESERVE)" <--- is nonsense
[04:06] <ubitux> yes
[04:06] <ubitux> but then look
[04:06] <ubitux> the direct rendering can be used
[04:06] <ubitux> though
[04:06] <ubitux> it looks wrong
[04:06] <ubitux> can gradfun really use the function inplace?
[04:06] <michaelni> dunno
[04:06] <ubitux> if so, then we should just remove the get buffer thing
[04:06] <ubitux> and add the write perm in min_perms
[04:06] <michaelni> i just know the permission check is nonsense
[04:07] <ubitux> yes, i've removed it locally
[04:07] <ubitux> still, direct rendering looks wrong
[04:07] <ubitux> erm
[04:07] <ubitux> not rendering
[04:07] <ubitux> the direct thing i mean
[04:07] <michaelni> similar code exists in several filters since the desliceing
[04:08] <michaelni> this could be copy and paste effect
[04:08] <ubitux> the question is just: is gradfun really allowed to support dst=src
[04:08] <ubitux> if yes, then we can trash a lot of added code
[04:08] <ubitux> if not, it needs to be fixed
[04:09] <ubitux> by inconditionnally request the get buffer thing
[04:09] <ubitux> but looking at the function, dst=src doesn't look right
[04:13] <ubitux> IMO it should just be that way: http://pastie.org/5465016
[04:27] <cone-504> ffmpeg.git 03Michael Niedermayer 07ff7e2342bbc9: dcadec: fix reading from prior to an array
[04:27] <cone-504> ffmpeg.git 03Michael Niedermayer 07b61ba262a1e2: mpc8: check seektable size before attempting to use it.
[04:27] <ubitux> michaelni: btw, exact same issue with hqdn3d unless i'm missing something
[04:31] <michaelni> ubitux, have you confirmed that the filters fail with in==out ?
[04:33] <ubitux> not yet, i don't really know what good samples could be used to test them
[04:33] <ubitux> no fate for both of them :(
[04:34] <ubitux> but it never looked to be the case
[04:35] <ubitux> mmh there was ff_inplace_start_frame though
[04:37] <ubitux> well if they support it we can simplify even more
[04:43] <ubitux> but looking at the code, i see for instance av_image_copy_plane
[04:43] <ubitux> which doesn't support that
[04:45] <ubitux> i'm a bit lost, i think i'll go to sleep :)
[04:46] <ubitux> 'night
[04:47] <michaelni> night ubitux 
[12:19] <cone-653> ffmpeg.git 03Nicolas George 0786a2486812f1: lavu/parseutils: accept %J for hours >= 24.
[12:50] <vtwo> i have a problem with ffserver and ffmpeg. here's both cmd's + console output and my ffserver.conf, would anyone be so kind and help please? -> http://pastebin.com/KNyVn5mX (#ffmpeg is kinda dead and going through it logs with google brought up only one suggestion which is off the table: "use vlc")
[13:22] <cone-653> ffmpeg.git 03Stefano Sabatini 0783ab46a57e4b: lavfi/blackdetect: switch to new ff_filter_frame() API
[13:22] <cone-653> ffmpeg.git 03Stefano Sabatini 07217163eb985b: lavfi/alphamerge: switch to ff_filter_frame() API
[13:22] <cone-653> ffmpeg.git 03Stefano Sabatini 073d728207229c: lavfi/decimate: switch to ff_filter_frame() API
[13:53] <cone-653> ffmpeg.git 03Mans Rullgard 077e9e7cc2364c: configure: fix indentation in option parsing loop
[13:53] <cone-653> ffmpeg.git 03Michael Niedermayer 078be18ffd6a5e: Merge remote-tracking branch 'qatar/master'
[14:01] <cone-653> ffmpeg.git 03Nicolas George 076f3d2fb18bb6: lavfi/vf_tile: switch to filter_frame.
[14:01] <cone-653> ffmpeg.git 03Nicolas George 073b316247fb87: lavfi/vf_tile: cosmetic after last commit.
[14:01] <cone-653> ffmpeg.git 03Nicolas George 0724cb1f971838: lavfi/vf_tile: forward errors.
[14:13] <Compn> lol
[14:14] <Compn> vtwo : was the problem ? reading log now
[14:14] <vtwo> problem is (i guess) ffserver not accepting the connection
[14:15] <vtwo> i can stream to other things with rtmp but my local ffserver seems not to work
[14:15] <Compn> your ffmpeg is outputtng to http://feed.ffm and your ffserver is reading from /tmp/feed.ffm
[14:15] <vtwo> stream with ffmpeg i mean
[14:15] <vtwo> aah lemme check that, that would be awesome lol
[14:16] <Compn> well maybe i'm reading ffserver conf wrong
[14:18] <vtwo> hm yeah, changing /tmp/feed.ffm in the config to the full path of my public_http doesn't change a thing
[14:19] <vtwo> i guess that's just a buffer file
[14:20] <Compn> yep it is
[14:20] <Compn> try a new port ?
[14:21] <vtwo> yep, same problem
[14:21] <vtwo> av_interleaved_write_frame(): Connection reset by peer
[14:22] <vtwo> the weird thing is, if i use a port where ffserver doesnt listen on i get failed: Connection refused and Input/output error from ffmpeg
[14:22] <vtwo> so at least they react
[14:23] <vtwo> [POST] "/feed1.ffm HTTP/1.1" 200 1304 < even have that as output from ffserver
[14:23] <Compn> run ffserver with -v for more verbose
[14:24] <vtwo> -d and -v seem to be the same?
[14:25] <vtwo> ah nevermind
[14:25] <Compn> as you can see, i know nothing about ffserver :P
[14:25] <Compn> http://ffmpeg.org/ffserver.html needs to be rewritten methinks
[14:25] <vtwo> http://pastebin.com/pgHcfbUL
[14:25] <vtwo> nothing new besides the first 2 lines
[14:31] <Compn> hmm
[14:31] <Compn> no idea
[14:32] <Compn> try avi output instead of flv
[14:33] <Compn> also you wrote in ffserver config that video would be 320:240 but your ffmpeg output is 720x404 , might be problem
[14:33] <vtwo> that just runs through ffmpeg without any errors (but also not streaming)
[14:33] <Compn> oh thats the output 
[14:34] <Compn> yep, i have no idea whats wrong
[14:34] <Compn> better ask on ffserver list or #ffmpeg , or ffmpeg forums http://ffmpeg.gusari.org
[14:34] <vtwo> okay thanks
[14:48] <cone-653> ffmpeg.git 03Clément BSsch 0772e84a08e669: fate: add hue filter test.
[14:48] <cone-653> ffmpeg.git 03Clément BSsch 07adfd9ca3fabd: lavfi/hue: move to ff_filter_frame.
[15:03] <cone-653> ffmpeg.git 03Stefano Sabatini 07fbc339ff41fa: lavfi/super2xsai: switch to ff_filter_frame() API
[15:03] <cone-653> ffmpeg.git 03Stefano Sabatini 07bd465fdc7359: lavfi/framestep: switch to ff_filter_frame API
[16:42] <wm4> I don't understand why there's a "h264_vda" decoder, and a at the same time the "h264" decoder supports vda_vld as pixel format
[16:43] <wm4> it seems "h264_vda" is for the decoder that reads back pixel data from the GPU and behaves like a normal decoder, while "h264" + vda_vld is for decoding to hardware surfaces?
[16:44] <nevcairiel> the decoder exists because some guy didnt understand how to properly use a hwaccel from a player application, and some reviewer slept on the job and accepted it
[16:44] <wm4> awesome
[16:46] <nevcairiel> i think he wanted to use it in mplayer, and mplayer doesnt support the hwaccel, so instead of fixing mplayer, we ended up with it
[16:47] <ubitux> i'm looking for a noisy video sample to add a test for hqdn3d to fate; can anyone point me out one in fate samples?
[16:47] <wm4> so what should a player do if it wants hardware decoding with readback done by libavcodec? (like h264_vda does it, apparently)
[16:47] <ubitux> same question with "banding artifacts" for gradfun
[16:49] <wm4> in my understand, "h264" will always do software decoding if a non-hw pixel format is selected for decoding
[16:49] <nevcairiel> wm4: are you usre the vda hwaccel doesnt readback already?
[16:49] <wm4> *understanding
[16:50] <wm4> nevcairiel: maybe I don't really know how exactly this hwaccel stuff is supposed to work
[16:52] <wm4> unfortunately, it seems vdpau support is in a mess as well (because of mplayer devs, heh)
[16:53] <nevcairiel> vdpau is particularly messy because it was added before the HWAccel structure was introduced, so it uses its own deal
[16:57] <ubitux> (/home/ubitux/fate-samples/cram/skating.avi looks fine)
[16:58] <ubitux> smjpeg/scenwin.mjpg looks even better
[16:58] <wm4> anyway, grepped for CVPixelBufferGetBaseAddress and it's only in vda_h264_dec.c, so it seems pretty clear that the normal hwaccel stuff does not support read-back (so every application has to implement something like vda_h264_dec.c itself for other APIs?)
[16:59] <nevcairiel> that function doesnt even readback, all it does is put the pointers into the frame
[16:59] <wm4> well, I guess CVPixelBufferLockBaseAddress() would do the actual read-back
[17:00] <wm4> technically speaking
[17:00] <nevcairiel> so sure, you need to know how a hwaccel works when you want to use it, but readback may not always be wanted, and some hwaccels need initialization data as well (DXVA for example needs to be given some D3D resources that the code cannot "guess" by itself)
[17:05] <wm4> is my understand wrong: to use hwaccel decoding correctly, the application uses the normal AVCodecContext (requesting a normal decoder such as "h264"), has to request the special hw pixel format (corresponding to hardware surfaces), possibly setting hwaccel_context (depending on API), and implement get_buffer/release_buffer to manage hardware surfaces
[17:06] <nevcairiel> sounds right
[17:07] <nevcairiel> vda is a bit special because it offers a full bitstream parser and doesnt need the actual h264 decoder to function, thats why the vda decoder variant was so easy to hack together
[17:08] <wm4> the current architecture seems to be a big mess too: selecting the actual decoder (sw or hw) via get_format?
[17:08] <nevcairiel> dxva or vaapi dont have a bitstream parser and need the h264 decoder to parse the bitstream and only send actual frame slices to the decoder
[17:09] <nevcairiel> the design of the selection function is a bit messy, but its not like its more then three lines of code you need for the get_format function
[17:10] <wm4> the problem is, I don't want to use DR for software decoding, but I must use it for hw decoding - so things get messy again
[17:11] <wm4> multithreaded decoding too - I want it for sw; hw probably won't use it, but I want to disable it anyway for paranoia
[17:11] <nevcairiel> needs to be disabeld for hw, or things break
[17:11] <wm4> avcodec.h doesn't really specify when I can mutate all these fields
[17:12] <nevcairiel> the way i do it is to simply open a codec, try to use hardware, and if it fails, just start over clean
[17:12] <wm4> and as I understand, get_format will be called when decoding the first packet, but can also be called subsequently (pixel format changes?)
[17:12] <wm4> that's what I'm planning to do
[17:17] <wm4> also, it seems some hw decoders expect the application to do more in get_format - at least mplayer/mplayer2 call back into video output and vdpau specific code inside get_format()
[17:19] <nevcairiel> maybe they try to figure out if the vaapi/vdpau is available before setting the format?
[17:19] <nevcairiel> i only return the format
[17:21] <wm4> possible... it seems to work without
[17:21] <nevcairiel> personally i dont consider mplayer to be the best reference how to do things =p
[17:22] <wm4> definitely not, but since I'm hacking on my mplayer fork, it's not like I have a choice
[17:22] <cone-653> ffmpeg.git 03Nicolas George 07ddd87236f0eb: lavfi/vf_super2xsai: fix output ref size.
[17:23] <wm4> it's hard to guess whether a given piece of crap-code is just crap, or compensates for weird corner cases and bugs
[17:48] <ubitux> saste: you broke fate! :)
[17:48] <saste> ubitux, I'm still trying to understand why it didn't spot the problem here
[17:49] <saste> i was relying on ffmpeg+fate, so never tried ffplay
[17:49] <ubitux> i meant the memleak
[17:49] <iive> yes, mplayer inits the video system at get_format(). it is when it figures out if the requested format is available on the system.
[17:49] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20121202143847&slot=x86_64-archlinux-gcc-valgrind
[17:49] <ubitux> introduced by 217163eb985b6aad478e31ec84ac50498430afc2
[17:49] <iive> this way you won't init vaapi when you have only vdpau.
[17:51] <iive> unfortunately some people spent time to clean up the get_format() calls from decoders...
[17:57] <ubitux> meh i can't find a use case for gradfun :(
[18:00] <iive> not enough anime?
[18:01] <ubitux> well, i don't find anything where it actually makes any difference
[18:01] <ubitux> :p
[18:02] <cone-653> ffmpeg.git 03Paul B Mahol 0749435d3888bd: gifdec: read pixel aspect ratio
[18:02] <iive> to be honest, I've never used it myself either.
[18:06] <cone-653> ffmpeg.git 03Stefano Sabatini 07255be0734d92: lavfi/alphamerge: fix leak introduced in 217163eb
[18:06] <iive> ubitux: i think i found something, try it. the default strengs is not enough for it. 
[18:07] <ubitux> ok, thanks
[18:12] <durandal_1707> ubitux: why you picked such ugly sample?
[18:13] <ubitux> because the denoising is visible :p
[18:13] <ubitux> (especially at the bottom)
[18:14] <wm4> <iive> yes, mplayer inits the video system at get_format(). it is when it figures out if the requested format is available on the system.
[18:14] <wm4> <iive> this way you won't init vaapi when you have only vdpau.
[18:14] <wm4> iive: but vaapi isn't even supported?
[18:15] <wm4> and the mplayer-vaapi branch has a -va switch, which forces the user to select an api
[18:16] <cone-653> ffmpeg.git 03Stefano Sabatini 075148147b26f5: lavfi/bbox: switch to ff_filter_frame() API
[18:19] <iive> wm4: yes, because the way vaapi is implemented it cannot work with the auto detection, so it needs explicit options to make it work.
[18:19] <wm4> iive: that's wrong
[18:19] <wm4> at least going by the avcodec API
[18:19] <durandal_1707> iive: found 444 sample(s) ?
[18:19] <ubitux> iive: indeed, with a stronger thres it's visible :p
[18:20] <ubitux> iive: thanks! :)
[18:20] <iive> the person who implemented vaapi thought he knows better and incorporated the decoding into ffmpeg, so the libavcodec calls the api functions. not only parsing. 
[18:21] <iive> so he had to invent and a way to provide metadata like display variable and other X stuff.
[18:21] <iive> to provide them to the decoder.
[18:22] <wm4> iive: I don't know the internals, but the interface seems to be relatively straight-forward
[18:22] <wm4> though I would prefer if the application had not to use DR and do its own surface management
[18:23] <wm4> the worst is that almost every api works differently
[18:23] <iive> yeh, I've been thinking into making some generic functions that would go into libavdevice, as that library already interacts with X11 and similar stuff.
[18:24] <wm4> vdpau wants the slice callback, vaapi doesn't, crystalhd (whatever that is) outputs normal memory bitmaps, vda has _two_ decoders with completely different behavior...
[18:24] <iive> yes... every api works differently, even if vaapi and vdpau work in similar way they are implemented differently.
[18:24] Action: ubitux wonders if "tests/lena.pnm -vf gradfun=100" won't be enough to test gradfun
[18:25] <wm4> what would be useful if the decoder would simply return hardware surfaces, managing them itself, and the application only has to display them; though I don't know whether that would work
[18:25] <nevcairiel> not necessarily for dxva, as the application, you want to manage the surfaces if you want to avoid the readback
[18:26] <wm4> nevcairiel: what does dxva need additionally, other than possibly some generic context object shared between decoder and renderer
[18:27] <nevcairiel> there usually is a central surface allocator which is shared with the renderer which manages the surfaces, i dont think trying to plug that into avcodec is a good idea
[18:27] <ubitux>  ./ffplay ~/fate-samples/cyberia-c93/intro1.c93 -vf gradfun=50  this is funny
[18:28] <ubitux> it seems to work, but add a kind of dark band on top
[18:28] <iive> ubitux: no shadows around objects?
[18:28] <ubitux> oh it's because there is actually a black band on top :)
[18:29] <durandal_1707> you never tried that sample
[18:29] <ubitux> ?
[18:29] <durandal_1707> i have all fate samples in memory
[18:30] <iive> durandal_1707: no, I couldn't find it.
[18:34] <ubitux> ./ffplay ~/fate-samples/cyberia-c93/intro1.c93 -vf crop=iw:ih-15,gradfun=20:8  this one looks perfect! :)
[18:37] <ubitux> iive: thanks for the sample btw; i won't use them for the fate test, but i enjoy them ;)
[18:37] <ubitux> (and i'm going to watch them with gradfun on!)
[18:49] <iive> they are not my favorites in this contest. :)
[18:51] <ubitux> i like the first one :p
[18:51] <ubitux> feel free to share the one you like :D
[18:51] <cone-653> ffmpeg.git 03Nicolas George 072cb227f6a2a0: lavu/channel_layout: document the semantic of layouts.
[20:49] <cone-653> ffmpeg.git 03Michael Niedermayer 07936eaa89be5d: h264: check for integer overflow, fix null pointer dereference
[20:49] <cone-653> ffmpeg.git 03Michael Niedermayer 0780aa89bdff6e: asfdec: check extradata size before alloc and read
[20:54] <ubitux> saste: do you have a test file for vf removelogo?
[21:20] Action: ubitux discovers lavfi/transform.c
[21:49] <ubitux> anyone wants to switch to filter_frame the 6 remaining filters?
[21:50] <ubitux> (alphaextract, deshake, field, idet, overlay and tinterlace)
[22:32] <ubitux> michaelni: please disregard the latest mp patch as well, it leaks
[23:57] <saste> ubitux: about the removelogo test, we can use the official ffmpeg logo, add it to testsrc, and remove it through removelogo
[23:58] <saste> i don't know if the ffmpeg logo is already part of the samples collection
[23:59] <ubitux> sounds like a pain :p
[00:00] --- Mon Dec  3 2012