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

[burek]

[00:04] <cone-797> ffmpeg.git 03Anton Khirnov 07bb6c67bb36b1: lavfi: remove vf_slicify
[00:04] <cone-797> ffmpeg.git 03Michael Niedermayer 078c1f98d9542d: Merge commit 'bb6c67bb36b136de10256f0999128df4a42f9ffc'
[00:13] <cone-797> ffmpeg.git 03Anton Khirnov 07267290ce3b4d: vflip: switch to filter_frame
[00:13] <cone-797> ffmpeg.git 03Anton Khirnov 07a42b89910b07: vf_drawbox: switch to filter frame
[00:29] <ubitux> huh
[00:29] <ubitux> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?p=ffmpeg.git;a=commitdiff;h=2c3b665379de0358006199de8604e10323c1037a
[00:29] <ubitux> i don't understand the fate update
[00:34] <michaelni> ubitux, the old code analyzed the pixels of the input during start frame
[00:34] <michaelni> but the pixels only become available during draw_slice
[00:34] <michaelni> for each slice
[00:34] <michaelni> and all then during end_frame
[00:35] <ubitux> oh.
[00:35] <ubitux> ok
[00:37] <ubitux> mmh sampling dithering in lavr&
[00:38] <cone-797> ffmpeg.git 03Anton Khirnov 0771f82c3805eb: vf_crop: switch to filter_frame
[00:38] <cone-797> ffmpeg.git 03Anton Khirnov 07aa61728d0af9: vf_cropdetect: switch to filter_frame
[00:38] <cone-797> ffmpeg.git 03Anton Khirnov 078f21cfc6b39d: vf_aspect: switch to filter_frame
[00:38] <cone-797> ffmpeg.git 03Anton Khirnov 070a767ad796e4: vf_blackframe: switch to filter_frame
[00:55] <cone-797> ffmpeg.git 03Clément BSsch 078a12c96d2712: lavfi/mptestsrc: add FLAGS to AVOption array.
[00:55] <cone-797> ffmpeg.git 03Clément BSsch 07a5b765236bc5: lavfi: add priv_class for some forgotten filters.
[00:55] <cone-797> ffmpeg.git 03Clément BSsch 070b70ffa4acc1: lavfi/sendcmd: add FLAGS to AVOption array.
[00:55] <cone-797> ffmpeg.git 03Clément BSsch 073860e34b0865: lavfi/sendcmd: expose the options for both filters.
[01:24] <cone-797> ffmpeg.git 03Michael Niedermayer 0794fdef818e27: vf_scale: switch to filter_frame
[01:24] <cone-797> ffmpeg.git 03Anton Khirnov 0769d4420aeac4: libavfilter/split: switch to filter_frame
[01:45] <cone-797> ffmpeg.git 03Clément BSsch 0724f425319d79: lavfi/thumbnail: switch to filter_frame.
[01:45] <cone-797> ffmpeg.git 03Clément BSsch 07782993d9e424: lavfi/thumbnail: use avfilter_unref_bufferp() where appropriate.
[01:45] <cone-797> ffmpeg.git 03Clément BSsch 075d796270c537: lavfi/thumbnail: re-use ctx instead of inlink->dst.
[01:56] <cone-797> ffmpeg.git 03Anton Khirnov 07b5ecfa1d8d8d: buffersink: switch to filter_frame
[01:56] <cone-797> ffmpeg.git 03Anton Khirnov 0760e50dd96023: buffersrc: switch to filter_frame
[02:08] <ubitux> michaelni: if the filter is manually querying a new buffer for writing using ff_get_video_buffer in filter_frame(), it doesn't need AV_PERM_WRITE as minimum permissions for the input pads, right?
[02:09] <ubitux> (classic scenario with a filter modifying each frame passing by)
[02:13] <ubitux> i just made the change in vf colormatrix, and i was wondering about that flag
[02:14] <michaelni> WRITE is only needed if you write into that buffer
[02:14] <ubitux> into the input buffer passed to filter_frame() right?
[02:15] <wm4> why does vf_colormatrix even exist, when there's libswscale
[02:15] <michaelni> ubitux, yes if i understand you correctly
[02:15] <ubitux> alright, then i can push
[02:15] <ubitux> wm4: not the same thing
[02:15] <ubitux> bt701 etc
[02:16] <cone-797> ffmpeg.git 03Michael Niedermayer 07015c2b406662: libavfilter: default to filter_frame when neither it nor start/slice/end is set.
[02:16] <wm4> ?
[02:16] <cone-797> ffmpeg.git 03Anton Khirnov 07ece5decbe052: vf_null: switch to filter_frame
[02:16] <cone-797> ffmpeg.git 03Anton Khirnov 077c42814782e3: vf_copy: switch to filter_frame
[02:16] <cone-797> ffmpeg.git 03Anton Khirnov 0788f8af26a92b: vf_format: switch to filter_frame
[02:17] <ubitux> wm4: sws doesn't handle bt709,bt601,fcc etc convert
[02:17] <ubitux> afaik.
[02:18] <cone-797> ffmpeg.git 03Clément BSsch 07269cd07702de: lavfi/colormatrix: switch to filter_frame.
[02:20] <ubitux> oups&
[02:21] <cone-797> ffmpeg.git 03Clément BSsch 07502ecc9cc232: lavfi/colormatrix: 10l fix forgotten buffer unref.
[02:22] <wm4> ubitux: at least its interface would allow for it, and don't you agree it would be better to have this functionality to swscale instead?
[02:22] <ubitux> no idea, maybe yes
[02:22] <ubitux> patch welcome? :)
[02:26] <michaelni> sws has partial support for yuv type
[02:26] <michaelni> see the get/set colorspace functions
[02:33] <ubitux> huh
[02:34] <cone-797> ffmpeg.git 03Anton Khirnov 079178235ffb2d: avfilter: mark start_frame/end_frame/draw_slice as deprecated
[02:35] <wm4> removing documentation for deprecated functions is a nice way to say "fuck you" to whoever has to deal with code using these functions and is trying to port it to current API
[02:35] <wm4> just saying
[02:37] <ubitux> what are you talking about?
[02:37] <ubitux> that latest commit?
[02:38] <wm4> yes
[02:38] <ubitux> it's internally, it's just a fuck you to ffmpeg developers :)
[02:38] <cone-797> ffmpeg.git 03Clément BSsch 07031d6448782b: lavfi/ass: switch to filter_frame.
[02:38] <wm4> ubitux: mplayer uses them
[02:39] <ubitux> ???
[02:39] <iive> haven't followed development. is slice functionality completely removed?
[02:39] <ubitux> iive: in progress
[02:39] <ubitux> should be done soon
[02:39] <iive> why? too complicated?
[02:39] <wm4> ubitux: why "???"? it's as I'm saying, see vf_lavfi
[02:40] <wm4> though I wonder if mplayer's vf_lavfi even compiles still
[02:40] <ubitux> oh it's not a problem
[02:40] <ubitux> Nicolas is a ffmpeg developer ;)
[02:40] <ubitux> (and he is the author of that filter)
[02:40] <ubitux> oh
[02:41] <ubitux> i just got a great idea.
[02:43] <iive> still, somebody care to answer why is slice functionality removed?
[02:43] <iive> or at least prove meaningful link.
[02:45] <ubitux> "    Any alleged performance benefits gained from the split are purely
[02:45] <ubitux>     mythological and do not justify added code complexity.
[02:45] <ubitux> "
[02:45] <wm4> did anyone actually measure it?
[02:46] <iive> probably somebody run sd video on his i7
[02:49] <iive> ubitux: link?
[02:50] <ubitux> http://git.libav.org/?p=libav.git;a=commitdiff;h=565e4993c63f797e2d50ad2f1e8f62fdbe299666
[02:50] <ubitux> not yet merged since we are porting our filters
[02:52] <cone-797> ffmpeg.git 03Anton Khirnov 07565e4993c63f: lavfi: merge start_frame/draw_slice/end_frame
[02:52] <cone-797> ffmpeg.git 03Michael Niedermayer 0787b9dc098240: Merge commit '565e4993c63f797e2d50ad2f1e8f62fdbe299666'
[02:54] <ubitux> i guess it is now :)
[02:55] <iive> honestly, ffmpeg should stop merging all the crap from libav.
[02:56] <ubitux> i disagree
[02:56] <wm4> just like libav stopped merging all that crap from ffmpeg?
[02:56] <ubitux> :)
[02:57] <ubitux> iive: i will be maintainance mess if we stop merging
[02:57] <ubitux> especially that kind of work
[02:57] <ubitux> also, it actually simplifies a lot of things, and the filters are a lot more accessible now
[02:57] <iive> well, either you maintain it, or ;et them maintain it. in the latter case, better go work for libav, because your changes will be overwritten anyway.
[02:59] <ubitux> that's the burden ffmpeg developers have to live with
[02:59] <ubitux> but i'd better live with this than working for a project 2 years late in comparison to ffmpeg
[03:02] <cone-797> ffmpeg.git 03Anton Khirnov 0749dd71a6f1bc: vf_fieldorder: reindent
[03:02] <iive> ubitux: not sure what you mean... probably i'm not quite clear either.
[03:02] <cone-797> ffmpeg.git 03Anton Khirnov 074c973de9a5b6: vf_fieldorder: require write permissions
[03:02] <cone-797> ffmpeg.git 03Michael Niedermayer 071eb8809a4178: Merge remote-tracking branch 'qatar/master'
[03:02] <iive> but here we have a feature removal, that probably makes ffmpeg measurably slower in non-trivial cases.
[03:03] <michaelni> iive do you have a benchmark ?
[03:03] <iive> and it is just merged. It probably also removes the work of few developers.
[03:03] <iive> michaelni: do YOU have a benchmark?
[03:03] <michaelni> i tried it with vf_scale but it wasnt any faster with slices
[03:03] <michaelni> that is today before the merging
[03:04] <iive> i hope you tried with video chain that doesn't fit in the cpu cache.
[03:05] <wm4> the advantage of slices may show up better with several consecutive slice based filters too
[03:05] <iive> and, even if you did, then it could have been a sign of bug, not proof that it doesn't work.
[03:06] <iive> because it did provide measurable difference in mplayer.
[03:06] <iive> wm4: my point exactly.
[03:06] <wm4> mplayer can't even use the slices path in most cases
[03:06] <michaelni> iive, i know it was faster in mplayer at the time of single core cpus
[03:07] <wm4> because ffmpeg's slice callback is not thread-safe
[03:07] <wm4> (or actually the other way around, anyway, you get it)
[03:07] <iive> wm4: yes, and it still delivered.
[03:07] <michaelni> iive i tried 1920x1024 and 4096x4096 i do think they didnt fit in the cache
[03:08] <wm4> iive: also, what's even your use case? the more complicated filters can't even do slices
[03:09] <michaelni> iive, but lets imaging someone comes along tomorrow and throws a patch on the table that fixes a terrible bug that prevented slices from being faster ...
[03:10] <michaelni> what would happen, is we just would revert the patches if the difference and use case is significant
[03:10] <michaelni> worst would be that we would look stupid ...
[03:11] <iive> 1. nobody would look into fixing bugs in non-existing code.
[03:11] <iive> 2. you won't be able to remove it, because you would have built other stuff on top of it.
[03:13] <iive> I don't see saste around. Have somebody asked him about it?
[03:17] <iive> michaelni: you should spend less time merging stuff and more time writing your own code.
[03:17] <iive> n8 ppl.
[03:18] <Compn> ya we talked to saste
[03:18] <ubitux> iive: i strongly disagree
[03:18] <wm4> iive: the forkers said that too :)
[03:18] <ubitux> we can't keep up with libav if we don't merge with them
[03:18] <ubitux> IMO you better go complain/discuss with them about that drop
[03:19] <ubitux> don't expect much more than here though
[03:19] <iive> then merge only the good parts. not everything.
[03:19] <ubitux> not merging this is really problematic
[03:19] <ubitux> it will make the later merges way more complicated
[03:20] <iive> well, there is no point of ffmpeg if it is libav with just little dressing over it.
[03:21] <ubitux> we have thousands of bugfixes
[03:21] <iive> as I said, either you rely on them to do the heavy lifting, or do it on your own.
[03:21] <ubitux> dozens of formats/codecs/filters
[03:21] <ubitux> and we have several others differences
[03:21] <wm4> iive: you should make your own fork
[03:21] <michaelni> iive, if slices are faster we should revert if not we should not
[03:21] <wm4> that never merges anything
[03:21] <michaelni> noone showed them faster on a modern cpu
[03:21] <iive> wm4: there are enough of forks.
[03:22] <iive> michaelni: you were the best person to find how to make something faster.
[03:22] <iive> you would have never removed a acceleration feature without having through and through test.
[03:23] <iive> right now you just don't know why it is not faster.
[03:23] <iive> and you are too busy merging stuff to find out why.
[03:23] <wm4> by the way, clean, simple and maintainable code > fast shitcode
[03:23] <wm4> *faster
[03:24] <iive> wm4: so.. lets rewrite ffmpeg on C# ... 
[03:24] <wm4> iive: why is ffmpeg written in C, if assembler is "faster" than C?
[03:25] <iive> wm4: very few projects have more assembler code than ffmpeg. everything that matters for speed is asm.
[03:25] <cone-797> ffmpeg.git 03Marton Balint 07fc38bbcd6ab3: ffplay: disallow seeking before the start of the file
[03:25] <cone-797> ffmpeg.git 03Marton Balint 072efd01a32f0c: ffplay: fix updating external clock after seeking
[03:25] <cone-797> ffmpeg.git 03Marton Balint 07f7eb50f3c070: ffplay: increase maximum frame duration to 1 hour for streams without TS discontinuity
[03:25] <cone-797> ffmpeg.git 03Michael Niedermayer 0755a5ded67e0e: Merge remote-tracking branch 'cus/stable'
[03:26] <iive> and I need to get some sleep.
[03:27] <wm4> iive: then C# + asm should work out fine (assuming C# code is cleaner and more maintainable than C code)
[03:27] <wm4> though I'd suggest something like Rust rather than C#
[03:28] <iive> wm4: so it is win-win. go for it.
[03:28] <wm4> why does he compare rewriting thousands of lines of code to removing a minor source of complexity
[03:35] <ubitux> major source of complexity :p
[03:35] <ubitux> this function merge really simplifies everything
[03:40] <wm4> you could have the slice path without complicating normal frame filtering
[03:40] <wm4> like mplayer actually does
[03:48] <cone-797> ffmpeg.git 03Clément BSsch 079236e9f1e114: lavfi/ebur128: use ff_filter_frame() everywhere.
[05:53] <cone-797> ffmpeg.git 03Michael Niedermayer 073fd8e07265d2: vsrc_mandelbrot: switch to filter_frame
[10:23] <cone-348> ffmpeg.git 03Stefano Sabatini 07989c6a4943e3: doc/ffmpeg-codecs: add short description
[10:23] <cone-348> ffmpeg.git 03Stefano Sabatini 07cf56c2076180: doc/Makefile: rework component configuration logic
[10:23] <cone-348> ffmpeg.git 03Stefano Sabatini 07605f1d9865d4: lsws: define version in SWScaler class
[10:54] <saste> how can i know if a muxer supports negative timestamps?
[10:55] <durandal_1707> isn't there flag?
[10:56] <saste> avoid_negative_ts? it's an option
[11:04] <durandal_1707> saste: i mean .flags
[11:38] <ubitux> saste: i didn't understand what you said for CONFIG_PROTOCOLS/ffmpeg-protocols
[11:39] <saste> ubitux: i'm not yet sure I want to disable protocols doc generation if the user disabled protocols
[11:40] <ubitux> ah, ok
[11:40] <saste> also that will complicate the build logic
[11:40] <saste> i might reconsider that in the future though
[11:40] <saste> but doesn't seem crucial at the moment, so i just did the lazy thing and pushed as it was
[11:41] <ubitux> sure ok
[11:47] <cone-348> ffmpeg.git 03Clément BSsch 079262f13269b1: lavfi/show{spectrum,waves}: use ff_filter_frame().
[11:48] <saste> what's the name of the technique meant to generate corrupted video by altering the encoded bitstream?
[11:48] <saste> it was something like smooshing
[11:49] <ubitux> fuzzing?
[11:49] <durandal_1707> there is noise bitstream filter
[11:49] <saste> durandal_1707, no i read some time ago but can't remember
[11:50] <saste> that consisted of tweaking a few bits of an MPEG video so that the result was corrupted
[11:50] <saste> but generating funny effects on the played video
[11:50] <ubitux> that's exactly what zzuf does, and it's called a fuzzer :p
[11:51] <nevcairiel> its meant to expose code flaws like crashes though, and not produce funny effects in the resulting image .p
[11:51] <saste> ubitux, but it was acting on *specific* bits, and altering it in a deterministic way
[11:52] <saste> it was not meant as a tool device, but as a "recreational" effect
[11:52] <saste> tool device -> debugging device
[11:53] <saste> alright I'll have to dig in my mail archive
[11:54] <ubitux> michaelni: why did you remove the unref_buffer in 3fd8e07265d247fd502bc7c9fcf09fa922f82335?
[11:56] <ubitux> oh i'm stupid you add a reference in the original code
[11:58] <saste> http://www.youtube.com/watch?v=tYytVzbPky8
[11:59] <saste> any taker? :)
[11:59] <nevcairiel> somehow i dont find watching movies with missing reference frames particularly recreational
[11:59] <nevcairiel> thats really all required to make that effect :P
[11:59] <ubitux> oh yes
[11:59] <ubitux> it reminds me something
[11:59] <ubitux> in ruby maybe
[12:00] <ubitux> saste: http://ucnv.github.com/aviglitch/
[12:00] <ubitux> reminds me this
[12:01] <ubitux> heh it seems to link to your video ;)
[12:07] <ubitux> saste: so you want to write such filter?
[12:07] <saste> ubitux, bitstream filter
[12:07] <saste> seems easy and fun
[12:07] <saste> also useless
[12:08] <ubitux> :))
[12:09] <ubitux> saste: there are a few remaining filters using start_frame/draw_slice/end_frame, maybe some you maintain
[12:09] <ubitux> care to move them to ff_filter_frame?
[12:10] <saste> yes, give me a few days
[12:10] <ubitux> i can do it right now otherwise :)
[12:13] <saste> only if you have fun doing so
[12:13] <saste> which are left?
[12:13] <ubitux> ~20
[12:14] <ubitux> afaict
[12:14] <saste> damn why do we have so many filters?
[12:15] <av500> instagram
[12:53] <cone-348> ffmpeg.git 03Clément BSsch 07ea3bad0e9e3e: lavfi/smartblur: switch to filter_frame.
[12:54] Action: ubitux wonders about an filter_frame_alloc_out()
[12:57] <cone-348> ffmpeg.git 03Clément BSsch 07b99f1303ad9c: lavfi/concat: switch to filter_frame.
[12:57] <cone-348> ffmpeg.git 03Clément BSsch 07a7eabbb20dc0: lavfi/concat: prefer av_asprintf() over stack allocated buffer.
[13:04] <ubitux> saste: would be nice to have a fate test for decimate
[13:04] <saste> yes
[13:40] <cone-348> ffmpeg.git 03Diego Biurrun 0789145fbbfecf: x86: h264dsp: Fix linking with yasm and optimizations disabled
[13:40] <cone-348> ffmpeg.git 03Diego Biurrun 079534e0f552a6: fate: lossless-audio: Add dependencies
[13:40] <cone-348> ffmpeg.git 03Diego Biurrun 075116ac777424: fate: real: Add dependencies
[13:40] <cone-348> ffmpeg.git 03Diego Biurrun 071f3f89656450: fate: Add dependencies for Vorbis, ProRes, QTRLE, utvideo tests
[13:40] <cone-348> ffmpeg.git 03Michael Niedermayer 077dc0ed80e877: Merge commit '1f3f896564501c23b44fcf605567c78ce066b539'
[13:50] <cone-348> ffmpeg.git 03Diego Biurrun 079b15c0a9b38e: x86: dsputilenc: port to cpuflags
[13:50] <cone-348> ffmpeg.git 03Diego Biurrun 07a1d1fc9b4a8f: fate: Fix wavpack-matroskamode test dependencies
[13:50] <cone-348> ffmpeg.git 03Diego Biurrun 07db9dbfb72a65: fate: vpx: Add dependencies
[13:50] <cone-348> ffmpeg.git 03Justin Ruggles 07cdaa1f84fb6f: lavf: move "MP3 " fourcc from riff to nut
[13:50] <cone-348> ffmpeg.git 03Justin Ruggles 07bfe5454cd238: lavf: move ff_codec_get_tag() and ff_codec_get_id() definitions to internal.h
[13:50] <cone-348> ffmpeg.git 03Michael Niedermayer 07076300bf8b43: Merge commit 'bfe5454cd238b16e7977085f880205229103eccb'
[14:05] <cone-348> ffmpeg.git 03Justin Ruggles 07261e9348ef37: lavf: add a common function for selecting a pcm codec from parameters
[14:05] <cone-348> ffmpeg.git 03Justin Ruggles 075c7bf2dddee5: lavf: move nuv fourcc audio tags from riff to nuv
[14:06] <cone-348> ffmpeg.git 03Michael Niedermayer 07d7b20bfbb582: Merge commit '5c7bf2dddee5bdfa247ff0d57cb8a37d19077f66'
[14:14] <cone-348> ffmpeg.git 03Justin Ruggles 07c74f81786d43: nuv: cosmetics: pretty-printing
[14:14] <cone-348> ffmpeg.git 03Michael Niedermayer 0752066bdb300b: Merge commit 'c74f81786d434dfaf9b3dff06aa96bfd23d0127b'
[14:21] <cone-348> ffmpeg.git 03Justin Ruggles 07838ed296df91: nuv: use the stream indices generated by avformat_new_stream()
[14:21] <cone-348> ffmpeg.git 03Justin Ruggles 07ab87d9b6677c: nuv: check for malloc failure when allocating extradata
[14:21] <cone-348> ffmpeg.git 03Diego Biurrun 072c4593dd132e: rtpenc_chain: Remove unused variable
[14:21] <cone-348> ffmpeg.git 03Diego Biurrun 0747e7fb881584: fate: Do not unconditionally run libavutil tests
[14:21] <cone-348> ffmpeg.git 03Diego Biurrun 07d2f576bd4991: fate: ea: Add dependencies
[14:21] <cone-348> ffmpeg.git 03Diego Biurrun 07e4d349b4014e: fate: h264: Add dependencies
[14:21] <cone-348> ffmpeg.git 03Michael Niedermayer 079f8e2e92ae88: Merge commit 'e4d349b4014ee2a03f521027e0bd1ace4a9e60bd'
[14:24] <cone-348> ffmpeg.git 03Justin Ruggles 0795682d8cd210: avconv: fix variable shadowing in configure_input_audio_filter()
[14:24] <cone-348> ffmpeg.git 03Anton Khirnov 07e2718e7a7006: avplay: Do not use removed av_get_int()
[14:24] <cone-348> ffmpeg.git 03Michael Niedermayer 070ecfcf862136: Merge remote-tracking branch 'qatar/master'
[14:27] <cone-348> ffmpeg.git 03Paul B Mahol 0726f1b1a0fa6b: fate: add ADPCM 4XM test
[14:27] <cone-348> ffmpeg.git 03Paul B Mahol 07a9236b87b75f: fate: add tak dependencies
[15:28] <cone-348> ffmpeg.git 03Michael Niedermayer 073ae610451170: roqvideodec: check dimensions validity
[15:28] <burek> i can't find in the irc logs now, but is there a way to make stderr output of ffmpeg more frequent
[15:28] <burek> like 25 log lines / sec
[15:30] <Daemon404> -loglevel verbose
[15:30] <Daemon404> oh
[15:30] <Daemon404> you mean flushing?
[15:30] <ubitux> burek: someone asked for this a while ago, and iirc it was for the wrong reason
[15:31] <Daemon404> flushing tons isnt really a greate idea
[15:31] <burek> Daemon404 yes, more frequent flushing and ubitux i remember also that we talked about it recently but i cant find that in irc logs :S
[15:31] <Daemon404> what do you need it for?
[15:31] <ubitux> look on the user channel
[15:31] <burek> for #ffmpeg channel, a guy wants to get the info more frequently
[15:31] <ubitux> Daemon404: iirc it was a guy willing to get "real time" status for a java app or something
[15:32] <burek> i guess he displays that in his app or something
[15:32] <Daemon404> ubitux, "real time"
[15:32] <Daemon404> lol wat
[15:32] <Daemon404> the amount stderr flushes is more than enough for any progress meter
[15:33] <ubitux> maybe he was counting frames using that
[15:33] <ubitux> i don't remember exactly
[15:33] <ubitux> it was a stupid thing anyway
[15:33] <burek> yes, for most of normal use cases :) but is it possible to set the desired time period for that flush?
[15:33] <Daemon404> burek, i cnat help but think you are doing something evil
[15:33] <Daemon404> and wrong
[15:33] <Daemon404> :)
[15:33] <burek> not me :)
[15:33] <burek> im just trying to help a guy :)
[15:33] <ubitux> yes, even at 25 refresh seconds it would have been wrong
[15:34] <Daemon404> either way
[15:34] <burek> can ffprobe do this maybe
[15:34] <ubitux> burek: try to figure out why he wants this
[15:34] <Daemon404> i cant htink of any reason you need ro force flushing 
[15:34] <Daemon404> not 1 valid reason :V
[15:34] <burek> [15:07:58] <TwisteR> can I somehow increase the rate of stdout messages from ffmpeg during capture?
[15:34] <burek> [15:08:56] <TwisteR> I use ffmpeg's console output to generate subtitles
[15:34] <burek> [15:09:52] <TwisteR> and I want 1 line of console output every 40 ms (@ 25 fps)
[15:34] <Daemon404> what the hell?
[15:34] <burek> :)))
[15:34] <nevcairiel> subtitles....?
[15:34] <Daemon404> also why not just update teh dang subtitles
[15:35] <Daemon404> when theyre ready
[15:35] <Daemon404> i sense hes doing soemthing -really- dumb here
[15:35] <Daemon404> like one subtitle per frame
[15:35] <burek> well, people get that ffmpeg is all-in-one free tool for multimedia and they try to use it for a lot of things, i guess :)
[15:36] <Daemon404> burek, im syaing is entire appraoch is wrong :P
[15:36] <burek> i could see that coming :)
[15:37] <ubitux> he is right
[15:38] <ubitux> burek: i found the log
[15:38] <ubitux> "< Marlinc> So my original question was if it is possible to get those status messages more often"
[15:38] <ubitux> look for this
[15:39] <burek> oh thanks
[15:39] <burek> that was it
[15:39] <burek> :beer: :)
[15:39] <burek> -progress right?
[15:40] <ubitux> he was likely looking for a showinfo filter
[15:40] <ubitux> but well.
[15:40] <burek> maybe he is playing the video and in the background analyzing stderr and parsing/displaying something
[15:40] <burek> dunno
[15:41] <burek> i redirected him to read the docs about those 2 i hope he'll find what he is looking for :)
[15:41] <burek> thanks again :beer: :)
[15:42] <Daemon404> sounds like theyre writing something powered by duct tape and hope
[15:42] <Daemon404> :/
[15:43] <burek> :D
[15:43] <ubitux> powered by ducks
[16:04] <cone-348> ffmpeg.git 03Michael Niedermayer 0727eada287af5: tiffdec: better checks for bitstream offsets, fixes out of array reads
[16:04] <cone-348> ffmpeg.git 03Michael Niedermayer 076abb9a901fca: huffyuvdec: check width more completely, avoid out of array accesses
[16:07] <ubitux> strange, i was expecting more opposition to the subtitles filter
[16:07] <ubitux> then great, i guess i'll push it in a few days then :)
[16:52] <simonec77> I all, I'm confused, what is the list of experimental codec?
[16:52] <TimNich> ubitux: might give it a try, are there any libass version dependencies?
[16:52] <ubitux> yes it uses libass
[16:53] <ubitux> ah you mean a particular version?
[16:53] <ubitux> i don't think so
[16:55] <TimNich> I'll pull in the latest version and give it a try, once I've finished my current project let.
[17:02] <simonec77> Anyone of us is try to encode using the experimental AAC encoder in FFMPEG?
[18:00] <teratorn> anyone know what might be wrong seeing error like this, [libvpx @ 0x2ac7f8007cc0] Provided packet is too small, needs to be 27
[18:01] <teratorn> I encode a buncha frames then all of a sudden it starts to spit this out... where 27 is always different.. the one before was 16464
[18:22] Action: TimNich has just noticed that sometimes ffprobe puts [SAR &DAR] and sometimes leaves the brackets off...
[18:23] <Daemon404> TimNich, use -of
[18:23] <Daemon404> its your friend
[18:26] <TimNich> but it consistently does it one way on one set of files, and the other way on another set.
[18:27] <Daemon404> im sure there's a reason
[18:27] <Daemon404> but ffprobe has -of for a reason :P
[18:27] <Daemon404> (for pragmatic usage)
[18:30] <TimNich> you can prefix -of default and its still different...
[18:30] <Daemon404> you want -show_streams as well
[18:31] <TimNich> no I don't, I only need the summary, but I cannot see why its inconsistent...
[18:31] <TimNich> ffmbc is the same too...
[18:33] <Daemon404> -show_streams is basically a summary of the streats like what youre viewing...
[18:34] <Daemon404> but not using whatever weird way ffmpeg.c and ffprobe.c do it usually 
[18:34] <TimNich> yes, I know, but the insertion of the [] must mean something, perhaps inconsistent data or somesuch.
[18:35] <Daemon404> i gave up on trying to figure out these sorts of cosmic mysteries a long time a ago
[18:35] <Daemon404> :/
[18:36] Action: TimNich decides to have a beer instead...
[18:36] <Daemon404> good choice
[18:36] <Daemon404> i might do that too
[18:36] <Daemon404> cause im trapped in UK maybe
[18:36] <Daemon404> due to flooding
[18:36] <Daemon404> \o/
[18:37] <TimNich> trapped where?
[18:37] <Daemon404> exeter
[18:37] <TimNich> Ahh, yes. Trains still not running then?
[18:37] <Daemon404> nope.
[18:38] <TimNich> beer it is then!
[18:39] <Daemon404> yup.
[19:59] <ubitux> oh, animated gif strike back!
[20:07] <cone-186> ffmpeg.git 03Paul B Mahol 079a31997938c9: BRSTM demuxer
[20:11] Action: Compn throws a gif at ubitux
[20:12] Action: ubitux gif a throws at cone-186 
[20:12] <ubitux> haem
[20:12] Action: ubitux gif a throws at Compn 
[20:19] <cone-186> ffmpeg.git 03Piotr Bandurski 070b14c197f1ff: iff: mention all decoders
[20:22] <Compn> dont worry cone-186 , i'll protect you
[20:38] <llogan> why is it named "cone"?
[22:13] <cbsrobot> llogan: it's the irc bot from the coneheads
[22:14] <cbsrobot> meaning vlc
[23:07] <llogan> cbsrobot: thanks
[23:24] <cone-186> ffmpeg.git 03Michael Niedermayer 0710416a4d56fa: id3v2: check index against buffer size. Fix out of array access
[23:24] <cone-186> ffmpeg.git 03Michael Niedermayer 070b28abf903cd: vble: check packet size.
[00:00] --- Fri Nov 30 2012