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

burek burek021 at gmail.com
Sun Oct 14 02:05:02 CEST 2012


[00:00] --- Sat Oct 13 2012
[00:02] <ubitux> hey saste! :)
[00:02] <saste> hey
[00:02] <ubitux> saste: did you see my OT link the other day? :)
[00:03] <saste> ah yes the life thing
[00:03] <ubitux> yeah
[00:03] <ubitux> :D
[00:03] <saste> there are plenty of things of that kind...
[00:03] <ubitux> okay :)
[00:03] <saste> btw my attempt with libvisual failed some time ago
[00:03] <saste> the API is not meant to the low level usage that we require
[00:04] <saste> that is there is no way to pass audio data and get video data
[00:04] <ubitux> weren't you willing to look into milkdrop instead?
[00:04] <saste> milkdrop is even worse
[00:04] <saste> since it is tightly integrated with opengl iirc
[00:04] <ubitux> or maybe the other one i never remember the name
[00:04] <ubitux> something like projectx
[00:05] <saste> you could make a sink of it, but not that it's very useful...
[00:05] <saste> btw an opengl sink or device would be very welcome
[00:05] <saste> projectx?
[00:06] <ubitux> i don't remember the name :p
[00:06] <saste> there are plenty projects named like that
[00:06] <saste> proof that people has no inventive
[00:06] <ubitux> ah projectM!
[00:07] <saste> yes projectM is integrated with opengl
[00:07] <saste> that is there is no way to use it programmatically in a transmedia filter
[00:07] <ohsix> integrated? :p
[00:07] <ubitux> (http://projectm.sourceforge.net/)
[00:07] <ubitux> ok
[00:08] <ubitux> that's too bad then
[00:08] <ohsix> what about frei0r
[00:08] <saste> again, you could create an output device
[00:08] <saste> frei0r? doesn't deal with audio
[00:08] <ubitux> saste: btw, any idea about my question on the buffer ref metadata copy thing?
[00:08] <ubitux> (the =NULL & dict copy thing)
[00:09] <saste> no i still have to read that
[00:09] <ohsix> what's "deal" anyways
[00:09] <ohsix> you want some visualization where audio goes in, and you get a bitmap back?
[00:09] <saste> ohsix, yes
[00:09] <saste> as simple as it seems, yet i couldn't find any project delivering that feature
[00:09] <ohsix> not that anyone has done anything interesting with this on linux, but doing it without acceleration is pretty much a dead end
[00:10] <ohsix> you could use pbo's to stream the output back after it's been rendered with one of the opengl visualizers, but that way lies doom
[00:10] <saste> pbo?
[00:10] <ohsix> pixel buffer objects, just a sane way to access the contents
[00:11] <saste> yes the problem is that they are all focused on visualization
[00:11] <saste> while that's not our problem, that's only the final step
[00:11] <ubitux> saste: and we can't grab the opengl content or something?
[00:11] <saste> so we need to handle with raw data buffers
[00:11] <ohsix> i must have missed the premise then, what are you trying to do?
[00:12] <saste> ubitux, no experience with opengl, so maybe i'm missing something completely obvious
[00:12] <saste> ohsix, an audio visualization wrapper
[00:13] <ohsix> and given that, what does "being focused on visualization" mean?
[00:14] <ubitux> not audiobuffer2videobuffer oriented
[00:14] <saste> ohsix, that we don't want to immediately visualize it, we need to process it like other data
[00:14] <ubitux> but draw-the-audio-buffer-on-opengl-surface, i guess.
[00:14] <ubitux> still, i'm pretty sure we could grab the opengl content :p
[00:15] <ohsix> process the output or the input? i thought it was implied that you wanted audio in and a surface out
[00:15] <ubitux> a video buffer on surface out
[00:15] <ubitux> so it can be filtered in the filterchain, encoded, etc
[00:15] <saste> from what i remember
[00:16] <saste> the API i checked (libvisual) works like this
[00:16] <saste> you pass an audio buffer
[00:16] <ohsix> right, so by focused on visualization you mean it creates its own window or whatever, even if it ends up in a buffer it's still focused on visualization :p
[00:16] <saste> then there is a thread processing the audio and sending the video data to opengl, which does the rendering
[00:17] <saste> from our point of view such API is not useful at all, since we need to know when the video data is ready
[00:17] <saste> but again, i may be wrong
[00:17] <ubitux> saste: btw, did you look at coverity?
[00:18] <saste> but it was enough to realize that i couldn't easily get along with what i wanted, and i gave up
[00:18] <saste> ubitux, no
[00:19] <ohsix> shrug, from what i understood of frei0r it's data in data out, you could do this with it but you'd need to write your own plugins that behave that way
[00:20] <ubitux> saste: that's pretty neat: http://ubitux.fr/pub/pics/_coverity.png
[00:20] <saste> ohsix, are you aware that we already have a frei0r filter?
[00:21] <ubitux> (no idea if that particular issue is right or wrong though)
[00:21] <ohsix> yes
[00:21] <saste> but frei0r is video only
[00:21] <saste> we need audio in -> video out
[00:22] <saste> we could do it natively, but since geeks worked on that since years, i thought we could leverage their work
[00:22] <saste> i was apparently wrong
[00:23] <ohsix> there's nothing stopping you from putting audio data in the source images :p but like i said, you'd need to write your own visualization plugins for it to do anything useful
[00:24] <ubitux> we already have two visu in lavfi
[00:24] <ubitux> we were willing to support advanced visualizrs
[00:25] <ohsix> what practical use is it when you probably have something in mind when you do such a thing, and can do it better in a video editor
[00:25] <saste> uh audio data in video buffers, that's an hack
[00:25] <ohsix> no it isn't, heh
[00:25] <ubitux> not talking about the audio settings :p
[00:26] <ubitux> let's encode into wav and put them into frames and them to frei0r
[00:26] <ohsix> and they aren't "video buffers" anyways, that's just their typical usage
[00:26] <saste> i can already imagine some people screaming and with their eyes bleeding 
[00:26] <ubitux> :)
[00:26] <ohsix> frei0r basically does nothing but find plugins in standard places and provide a process() routine
[00:27] <saste> ohsix, but i don't wont to write plugins, i want to leverage existing code
[00:28] <saste> *wont -> want
[00:28] <ohsix> right, that's why i said it was useless
[00:29] <ohsix> you will definitely have to adapt something though
[00:29] <ohsix> cuz you don't even really get much with the linux visualization projects either
[00:30] <ubitux> <@saste> i can already imagine some people screaming and with their eyes bleeding // http://z0r.de/3564
[00:30] <saste> ubitux, ahahah
[00:33] <saste> it's a shame because projectM plugins are f***ing cool
[00:33] <saste> well we could still implement an output device in the worst case
[00:33] <ubitux> i have some contacts with mylkmist developers, i'll see if they can help :)
[00:33] <saste> we have already caca after all
[00:34] <ohsix> abusing frei0r for just general data moving would probably be a bad idea,  but as far as visualization (and most mathematical transformations) they are equivalent :p
[00:34] <ohsix> i say, if you're going to be doing work, port AVS; it's great
[00:35] <saste> ohsix, they're already doing it
[00:35] <saste> or better, ffmpeg supports avisynth since ages
[00:35] <ohsix> not that i'm fascinated with this junk anymore, but once there were 3d cards the 2d effects were kind of lame
[00:35] <ohsix> saste: advanced visualization studio, the winamp plugin
[00:36] <cone-741> ffmpeg.git 03Georg Lippitsch 0705b7315412c3: Fix DPX decoder * 03http://tinyurl.com/9546knz03
[00:36] <cone-741> ffmpeg.git 03Georg Lippitsch 0724778c32d80e: Fix writing 12 bit DPX * 03http://tinyurl.com/9n4cbsu03
[00:36] <cone-741> ffmpeg.git 03Michael Niedermayer 07c2340831b8e9: aacsbr: change order of operation to prevent out of array read * 03http://tinyurl.com/9mn7gqe03
[00:36] <cone-741> ffmpeg.git 03Michael Niedermayer 070f46825d9833: ffserver: prevent nb_streams from becoming too large * 03http://tinyurl.com/8fddhns03
[00:36] <ohsix> it supports a bunch of 2d effects that you compose
[00:36] <saste> ohsix, i wouldn't whence to start
[00:36] <saste> ohsix, i wouldn't know...
[00:37] <ohsix> download winamp, run it in wine and play with some of the presets :p
[00:37] <saste> bah, too much work
[00:37] <ohsix> the source is available,  but not under a great license, but i know the guy to be flexible
[00:37] <ubitux> and write a script to send a screenshot command, grab the picture and inject it in libavfilter with a filebuffersource filter
[00:38] <ubitux> careful, you have to run screenshot commands fast enough to grab all the pic
[00:38] <ubitux> 25 commands per second
[00:38] <ohsix> while you could get the opengl output, you probably wouldn't want to, it's a whole can of worms (like for one, needing an accelerated display, of the X variety to even work)
[00:40] <ohsix> oh wait, AVS is bsd licensed
[00:40] <ohsix> if you want the best outcome for the least amount of work, i would port AVS, it is amazing
[00:41] <ohsix> not to mention being able to use public presets, of which there are a million, and some very popular/legendary ones even; something linux really doesn't have
[00:43] <ohsix> http://www.1014.org/code/nullsoft/avs/
[00:44] <ohsix> google video "advanced visualization studio" to see some of the presets people have made, if you really can't be bothered to find a windows machine :p
[00:45] <saste> ohsix, that's not a problem, i have dual boot and a win7 VM
[00:46] <ohsix> it works with wine too
[00:46] <ohsix> it looks like libvisual already does AVS
[00:49] <ohsix> ah it's something else entirely
[00:49] <ohsix> it's a reimplimentation of one component of it, without all the goodies
[00:49] <saste> how should i add an xface test to FATE?
[00:50] <saste> i want to test both encoder and decoder
[00:50] <saste> most image tests are in image.mak, but they only test the decoder iiuc
[00:50] <ubitux> will you add a saste.xface? :)
[00:51] <saste> more something like lena.xface
[00:51] <Gnosis-> hello. I just checked out ffmpeg from git, and I can't build the ffmpeg command for some reason
[00:54] <Compn> what error Gnosis- ?
[00:56] <ohsix> anyways, AVS is freakin' great, if you want "meat", there it is, you'd have to port it or reimpliment it but the presets & scripting language is das infinito
[00:56] <Gnosis-> Compn, no error. The make was successful
[00:57] <Gnosis-> it's just that it only compiled ffplay, ffserver, and ffprobe
[00:59] <ohsix> nothing uses cpu like an old school 2d effect! :D (actually wasted memory bandwidth making pretty colors, bring it)
[01:00] <Gnosis-> Compn:  http://bpaste.net/show/8RmaJrWkYE1UUj6dR4vQ/
[01:01] <Gnosis-> I added --enable-ffmpeg at the end, but that didn't fix this problem
[01:08] <llogan> ubitux: i wonder when/if ioni/wonder will implement your request for the arch ffmpeg package. he used to be fairly quick, IIRC.
[01:08] <ubitux> heh you're stalking me!
[01:09] <llogan> nah, i just trawl the bugs on occasion
[01:09] <llogan> but i was the "damned dirty ape" who commented!
[01:12] <michaelni> Gnosis-, --disable-avfilter ----> no ffmpeg
[01:14] <Gnosis-> ah, okay, thanks!
[01:14] <Gnosis-> why does it have that effect in 1.0 but not 0.10 or earlier?
[01:14] <michaelni> ffmpeg depends on some filters now
[01:15] <michaelni> --enable-ffmpeg should do more than what it does though (thats a bug)
[01:16] <Gnosis-> yeah, I added it because it seemed logical based on what was in ./configure --help; I didn't see it listed there, though
[01:17] <saste> ubitux: +k)Yd; K(|`g]9BSqmrYkq#^P(y-P'r-c4u#?8|@de:G{]Q)Z>pf/az3sLsNl&+;(wRBInu4 M)}~Lap^q.:4wL&By6f8c6h; .QSIY%'\thr0/K);0KZW#Dx9g4Ko!3m>V+2y*Zs5?'rCn=[~?Qf3-*9Ovp:aK".KM at M9F*>X6sl/<Xxs`1|<Cp7Y=xWNs4mm
[01:17] <ubitux> god bless you.
[01:18] <ubitux> i was going to say it saste 
[01:18] Action: llogan just remembered that 12.10 is a week away after messing with the guide.
[01:18] <saste> ubitux: ^^ saste.xface
[01:18] <ubitux> oh, ok
[01:18] <ubitux> :D
[01:19] <ubitux> saste: how can i test your branch? :)
[01:23] <saste> ubitux, i'm going to send an updated patch in a few minutes
[01:24] <ubitux> i'll check this out tomorrow then :)
[01:24] <ubitux> 'night :)
[01:34] <burek> if i want to change the default 'analyzeduration' of '5000000' is this the right place to change it: ./libavformat/options_table.h:51:{"analyzeduration", "how many microseconds are analyzed to estimate duration", OFFSET(max_analyze_duration), AV_OPT_TYPE_INT, {.i64 = 5*AV_TIME_BASE }, 0, INT_MAX, D},
[01:34] <burek> more precisely -> 5*AV_TIME_BASE
[01:35] <burek> ?
[01:50] <saste> burek, yes
[01:53] <burek> thanks :)
[01:55] <cone-741> ffmpeg.git 03Michael Niedermayer 07f374e9989be2: vf_fade: fix memleaks of args * 03http://tinyurl.com/9k8hg3c03
[01:55] <cone-741> ffmpeg.git 03Michael Niedermayer 07d2a618ab2213: af_pan: fix memleak of arg * 03http://tinyurl.com/98mzh2903
[01:55] <cone-741> ffmpeg.git 03Michael Niedermayer 0754b2d317ed99: ffv1: avoid checking a double for equality * 03http://tinyurl.com/9xvu6nz03
[01:59] <Compn> should we mention somewhere that avfilter is required for ffmpeg binary ?
[01:59] <Compn> seems like we will get a lot of reports about this .
[01:59] <Compn> lots of people --disable-everything then just enable a few things. probably breaks all that
[02:06] <creep> so when will ffmpeg final version be released?
[02:07] <creep> and ffmpeg t-shirts?
[02:07] <creep> ffmpeg lollipops ?
[02:10] <burek> when hungary becomes the football world champion :)
[02:10] <llogan> creep: tshirts are on my todo list.
[02:11] Action: llogan forgot about that quote...
[02:11] <creep> burek<< i know nothing about that
[02:12] <llogan> i just don't know how we will pay for them yet with the lack of donations
[02:12] <creep> they used to sell t-shirts for money..
[02:12] <llogan> a novel concept.
[02:12] <creep> http://www.spreadshirt.com/i-love-boobies-C3376A8474877#/detail/8474877PC27159424
[02:14] <cone-741> ffmpeg.git 03Michael Niedermayer 07120b38b966b9: avio: redesign ffio_rewind_with_probe_data() * 03http://tinyurl.com/8kdfmep03
[03:37] <Compn> anybody know which tools can soft crop h264 ?
[03:38] <cone-741> ffmpeg.git 03Michael Niedermayer 07e47024d72f32: wtvdec: fix memleak on error * 03http://tinyurl.com/8q752fm03
[03:39] <cone-741> ffmpeg.git 03Michael Niedermayer 07f657d495b04d: rtpdec_qdm2: change one assert to av_assert0 * 03http://tinyurl.com/8zggp3v03
[03:39] <cone-741> ffmpeg.git 03Michael Niedermayer 073f350a482fd0: ff_celp_lp_synthesis_filterf: check that filter_length is within the supported range * 03http://tinyurl.com/9jc3w2803
[03:39] <cone-741> ffmpeg.git 03Michael Niedermayer 073f010421421f: ff_celp_lp_synthesis_filterf: change loop end check * 03http://tinyurl.com/8c29wwm03
[03:39] <cone-741> ffmpeg.git 03Michael Niedermayer 079f9307ff2a6c: rv30_decode_intra_types: make check tighter * 03http://tinyurl.com/94q4ygp03
[04:00] <cone-741> ffmpeg.git 03Michael Niedermayer 074acfe3d193c7: jpegls: fix off limit * 03http://tinyurl.com/9qw8zqu03
[04:00] <cone-741> ffmpeg.git 03Michael Niedermayer 078dc89944270a: jpegls: increase run_index to 4 * 03http://tinyurl.com/9znumsj03
[05:23] <ohsix> looking at libvisual, you can request an actor to explicitly render into a given buffer, and you can skip opengl plugins when enumerating
[05:23] <ohsix> seems to me that'd work fine
[05:28] <ohsix> so your usage _could_ be to just use an actor with a given visvideo (to which you've attached your own output buffer) and you can ignore the rest
[05:33] <ohsix> what would be done for invariance, the visualizations use random numbers but there's no way to make stuff repeatable
[05:34] <ohsix> presumably you'd want the same output each time
[06:24] <cone-741> ffmpeg.git 03Michael Niedermayer 07ff814c75a3f5: ffserver: fix return value of add_codec() * 03http://tinyurl.com/8aucgho03
[09:58] <cone-741> ffmpeg.git 03Paul B Mahol 07efb0e4e7afc6: truemotion2: use more meaningful return codes * 03http://tinyurl.com/8f586lm03
[10:10] <cone-741> ffmpeg.git 03Paul B Mahol 0792b3d8bc5337: bethsoftvideo: return meaningfull error codes * 03http://tinyurl.com/8kvlcxp03
[10:25] <cone-741> ffmpeg.git 03Paul B Mahol 07f2f711cde277: pcx: read sample aspect ratio * 03http://tinyurl.com/8qal7wd03
[10:25] <cone-741> ffmpeg.git 03Paul B Mahol 0779133fd0e58f: pcxenc: store sample aspect ratio * 03http://tinyurl.com/98hselk03
[10:25] <ohsix> you will single handedly add many digits to tinyurl, that's not very nice
[11:10] <cone-741> ffmpeg.git 03Paul B Mahol 07e8b50385cf90: fate: update pcx reference * 03http://tinyurl.com/8cpocnd03
[12:00] <cone-741> ffmpeg.git 03Carl Eugen Hoyos 076254ffe0cadc: Allow autodetection of some dnxhd files that can be decoded correctly. * 03http://tinyurl.com/9t7z9sh03
[12:50] <cone-741> ffmpeg.git 03Sami Pietilä 073cc025273251: vp8dec: reset loopfilter delta values at keyframes * 03http://tinyurl.com/8e6mymc03
[14:21] <cone-741> ffmpeg.git 03Luca Barbato 076d5600e8556a: avutil: add yuva422p and yuva444p formats * 03http://tinyurl.com/94p97he03
[14:21] <cone-741> ffmpeg.git 03Sami Pietila 070bf511d579c7: vp8: reset loopfilter delta values at keyframes. * 03http://tinyurl.com/8sdnygs03
[14:21] <cone-741> ffmpeg.git 03Michael Niedermayer 07eae35eadc0ae: rtspdec: Fix use of uninitialized byte * 03http://tinyurl.com/8l46j7k03
[14:21] <cone-741> ffmpeg.git 03Michael Niedermayer 072f1b2ff934e6: rtmpproto: Fix an out of array write * 03http://tinyurl.com/9zpndk903
[14:21] <cone-741> ffmpeg.git 03Michael Niedermayer 07c80b59f679a0: tscc2: Fix an out of array access * 03http://tinyurl.com/8p6jlv703
[14:21] <cone-741> ffmpeg.git 03Martin Storsjö 075a2cb7821916: rtspdec: Set the default port for listen mode, if none is specified * 03http://tinyurl.com/9mly29l03
[14:21] <cone-741> ffmpeg.git 03Diego Biurrun 07f6c38c5f4ed6: avfilter: call x86 init functions under if (ARCH_X86), not if (HAVE_MMX) * 03http://tinyurl.com/9bqr2td03
[14:21] <cone-741> ffmpeg.git 03Michael Niedermayer 073b0bb321a50c: Merge commit 'f6c38c5f4ed6683a6a61db2ed418a68bbe5f5507' * 03http://tinyurl.com/8u7r5au03
[14:29] <cone-741> ffmpeg.git 03Diego Biurrun 07930c9d4373e0: avutil: Duplicate ff_log2_tab instead of sharing it across libs * 03http://tinyurl.com/9adp2su03
[14:29] <cone-741> ffmpeg.git 03Michael Niedermayer 07d197bd4f5ee7: Merge commit '930c9d4373e0f3cb7c64fcfc129127a309f6d066' * 03http://tinyurl.com/8nmwvdk03
[14:34] <durandal_1707> this is nonsens libav folks just move stuff around and calls they are doing all the work
[14:36] <ubitux> well, diego doesn't represent the whole libav team :)
[14:37] <ubitux> i'd be tempted to say "fortunately for them" but that's a bit rude for him :p
[14:37] <durandal_1707> and when they do not move stuff around they start to rename random stuff
[14:38] <ubitux> btw, what's this AVCodecContext->coded_frame thing for decoders?
[14:38] <ubitux> is it some kind of reference frame?
[14:38] <durandal_1707> itn't documented somewhere?
[14:39] <ubitux> "the picture in the bitstream"
[14:39] <durandal_1707> michaelni: this *_LIBAV pixfmt is pointless, it is just there for cosmetics
[14:43] <cone-741> ffmpeg.git 03Diego Biurrun 07d5c62122a7b2: Move av_reverse table to libavcodec * 03http://tinyurl.com/9lrxpap03
[14:43] <cone-741> ffmpeg.git 03Michael Niedermayer 07d6c342fdc0b4: Merge commit 'd5c62122a7b26704bf867a1262df358623bf5edf' * 03http://tinyurl.com/9unzucr03
[14:43] <ubitux> mmh we can't have multiple side data of the same type in a packet? :(
[14:43] <iive> btw, diego is one of the root masters or at least used to be. In that meaning he literally represents the libav team, for all matters not related for coding.
[14:44] <durandal_1707> ubitux: what would you do with several width/channels packet side data?
[14:44] <ubitux> iive: sure, for the political aspect i agree, i meant technically speaking
[14:44] <durandal_1707> ubitux: pick one of them with random()?
[14:45] <ubitux> durandal_1707: easier to store the key/value thing of the metadata
[14:45] <ubitux> "gimme the next side data for this type"
[14:45] <ubitux> "ohai here is another key/value"
[14:45] <ubitux> but whatever, i'll come with another way of storing :p
[14:48] <durandal_1707> michaelni: somthing in eval use av_reverse
[14:49] <durandal_1707> michaelni: this becomes extremly stupid, please stop merging libav, if there is anything usefull pick it with cherry-pick
[14:51] <nevcairiel> moving these tables has a very real reason, you should understand thigns before you complain
[14:51] <durandal_1707> making both ABIs compatible is not possible
[14:52] <durandal_1707> nevcairiel: eval use av_reverse
[14:52] <ubitux> nevcairiel: the msvc thing?
[14:52] <durandal_1707> nevcairiel: once libav removes av_reverse  who will fix eval in lavu?
[14:52] <ubitux> afaict for these case a duplicate is made
[14:52] <ubitux> so tables are not exported
[14:53] <ubitux> iirc there was some issues with exported tables
[14:53] <durandal_1707> so every table will be now duplicated 
[14:54] <ubitux> they drop snow to make some place ;)
[14:54] <durandal_1707> :))))))
[14:54] <nevcairiel> msvc needs some special hackery to support tables in shared library builds, so instead of doing that, it was decided to finally clean the whole issue up, because loading data tables from other shared libs is never ideal
[14:54] <ubitux> i don't understand how that is a cleanup :/
[14:54] <nevcairiel> table is used in one lib, so move it to that lib
[14:54] <nevcairiel> seems cleaner to me
[14:54] <ubitux> in this particular case yes
[14:55] <durandal_1707> nevcairiel: not for ffmpeg
[14:55] <ubitux> but duplicating all the tables doesn't look fine
[14:55] <ubitux> of course if there are no other solutions..
[14:55] <ubitux> the problem looks stupid though :(
[14:55] <nevcairiel> its not "all the tables", its like 2 math related tables which are pretty small
[14:56] <ubitux> and some other external const as well, right?
[14:56] <ubitux> (like the crypto size thing)
[14:56] <nevcairiel> accessing cross-library even on linux is a performance overhead
[14:56] <durandal_1707> hmm? why have it duplicated across source, just use single header
[14:57] Action: durandal_1707 talking about ffmpeg lavu
[14:57] <ubitux> ah right, the header looks like a good way to do it :p
[14:57] <ubitux> duplicated in the binary, but not in the code
[14:57] <nevcairiel> thats how all these duplicates work, they dont duplicate code
[14:57] <nevcairiel> because thats stupid
[14:58] <nevcairiel> only in shared libraries tehy are dups
[14:58] <ubitux> i admit i didn't look closely
[14:58] <ubitux> okay
[15:03] <michaelni> i was planing to move it to a header, log2 is a c file ATM
[15:03] <michaelni> being a c file sucks because when you compile against libavutil you cant count on having the c file
[15:04] <michaelni> you only have the headers and libs to link to
[15:05] <nevcairiel> arent you supposed to have the full source if building any of the libs?
[15:06] <nevcairiel> oh its used from inline functions
[15:06] <nevcairiel> sounds like that would always fail, because ff* symbols are private anyway
[15:06] <durandal_1707> maybe for libav
[15:07] <cone-741> ffmpeg.git 03Diego Biurrun 07c1ef30a6ba2c: De-doxygenize some top-level files * 03http://tinyurl.com/8c8t2wq03
[15:07] <cone-741> ffmpeg.git 03Diego Biurrun 07bc4620e5d61a: Remove libmpeg2 #define remnants * 03http://tinyurl.com/9o9adtn03
[15:07] <cone-741> ffmpeg.git 03Michael Niedermayer 07b4ca1b159f4b: Merge commit 'bc4620e5d61a4dd9a1f654fadd281a172aab04be' * 03http://tinyurl.com/96g73pj03
[15:10] <durandal_1707> michaelni: is there reason why avcodec.h part is not applied for this LIBMPEG thing ^
[15:11] <michaelni> i wasnt planing to drop that idct before theres a good reason to do so
[15:11] <michaelni> btw, how do i test MMI ?
[15:14] <michaelni> or diferently said what options do i need to pass to gcc for it to try to build the MMI code ?
[15:18] <michaelni> noone ?
[15:19] <durandal_1707> what is MMI code?
[15:20] <michaelni> MIPS stuff
[15:20] <michaelni> libav droped it vaguly pointing to "it doesnt work"
[15:20] <michaelni> i am trying to decide if theres a point in keeping it or not
[15:21] <michaelni> but my mips cross compiler doesnt seem to accept MMI code by default
[15:22] <michaelni> ill probably just drop it and whoever wants it and knows how to test/fix it can then put it back
[15:23] <durandal_1707> it is some PS2 code
[15:28] <michaelni> seems there have been no non cosmetic commits to it in 9 years
[15:29] <ubitux> did you contact the mips guy to see if it makes sense to keep it?
[15:29] <michaelni> i will but i cant wait for his reply with the merge
[15:29] <michaelni> its trivial to revert and put it back
[15:30] <durandal_1707> michaelni: probably partially useful for old hw
[15:31] <michaelni> if it works
[15:31] <michaelni> but people say it doesnt
[15:32] <durandal_1707> because it got broken over time?
[15:32] <cone-741> ffmpeg.git 03Diego Biurrun 07ca411fc1d343: avcodec: Remove broken MMI optimizations * 03http://tinyurl.com/8bpqslu03
[15:32] <cone-741> ffmpeg.git 03Michael Niedermayer 0785fe70b64c3d: Merge commit 'ca411fc1d34329cd17b28627f697e391ae52073f' * 03http://tinyurl.com/8tzu5qy03
[15:32] <michaelni> durandal_1707, i suspect so
[15:35] <ubitux> "broken beyond repair" :/
[15:35] <ubitux> please... :D
[15:37] <durandal_1707> that's how thing works, broke some stuff and make sure fate does not detect it, when it becomes obvious that is is broken just remove whole thing
[15:39] <michaelni> iam happy to add it back and add a fate test if someone fixes it and tells me how to test it
[15:40] <cone-741> ffmpeg.git 03Diego Biurrun 0790558e848a29: rangecoder: K&R formatting cosmetics * 03http://tinyurl.com/8ttnfev03
[15:40] <cone-741> ffmpeg.git 03Michael Niedermayer 07c55bebe2cc7b: Merge commit '90558e848a29ef1e85ecb1832ad9a26eebe958e0' * 03http://tinyurl.com/8qq4qde03
[15:44] <ubitux> i hate some of the alignment nit "fixes" :(
[15:44] <ubitux> it makes sense to align when the data is related
[15:44] <ubitux> no when it's fun to draw a column of '=' :/
[15:46] Action: michaelni doesnt care much about whitespace, though yes i agree some of the fixes are of dubious value
[15:46] <michaelni> especially some of the 80 column fixes sometimes are kinda "interresting"
[15:47] <michaelni> i mean especially the ones where there was vertical alignment of table or function call argument columns before the improvment
[15:47] <burek> how can I debug flv muxer from ffmpeg, which is used by vlc
[15:48] <burek> i mean, when i set the output in vlc, like "mux=ffmpeg{mux=flv}" i get 640x368 instead 640x360 frame sizes
[15:48] <cone-741> ffmpeg.git 03Diego Biurrun 074c66af6141a0: rangecoder-test: Set error message log level to error, instead of debug * 03http://tinyurl.com/8ck8wjz03
[15:48] <cone-741> ffmpeg.git 03Diego Biurrun 079e6ea3cef992: fate: add avstring test * 03http://tinyurl.com/8hhvpf403
[15:48] <cone-741> ffmpeg.git 03Diego Biurrun 07717addecad77: Use proper return values in case of missing features * 03http://tinyurl.com/9kwf2sb03
[15:49] <cone-741> ffmpeg.git 03Mans Rullgard 077e76fc528d60: mpegvideo: remove write-only variable * 03http://tinyurl.com/94566da03
[15:49] <cone-741> ffmpeg.git 03Mans Rullgard 07366484fff172: smjpeg: fix type of 'ret' variable in smjpeg_read_packet() * 03http://tinyurl.com/9scg8ln03
[15:49] <cone-741> ffmpeg.git 03Mans Rullgard 070a7005bebd23: rtpdec_xiph: fix function return type * 03http://tinyurl.com/8klmuyf03
[15:49] <cone-741> ffmpeg.git 03Michael Niedermayer 0718884f159b61: Merge commit '0a7005bebd23ade7bb852bce0401af1a8fdbb723' * 03http://tinyurl.com/9o367em03
[15:52] <burek> I don't know how to provide useful logs for such issue :/
[15:53] <michaelni> burek, maybe ask on #videolan
[15:53] <burek> just did :)
[15:53] <burek> and we debuged it to the point of lavf's flv muxer
[15:54] <burek> for example: vlc v4l2:///dev/video0 --sout='...,mux=ffmpeg{mux=flv},dst=live.flv'
[15:54] <burek> sorry, for example: vlc v4l2:///dev/video0:width=640:height=360 --sout='...,mux=ffmpeg{mux=flv},dst=live.flv'
[15:54] <michaelni> burek, so av_logs dont show up with vlc+ffmpeg or what is the problem, ?
[15:54] <burek> live.flv (as shown by mediainfo) shows 640x368
[15:55] <burek> michaelni, to be honest I don't know, I'll take a look.. btw: http://pastebin.com/iGeEz2Rf
[15:55] <burek> I don't know which lines are av_logs
[15:56] <michaelni> you could hack av_log to add a prefix 
[15:56] Action: michaelni leaves in the direction of the kitchen to seek something to eat
[15:59] <durandal_1707> burek: 0x15fb798] main mux warning: option flags is unknown
[16:00] <burek> yes, I had a line like: ...,mux=ffmpeg{mux=flv,flags=+global_header},...
[16:00] <burek> and later realized vlc doesn't just support passing any option to ffmpeg
[16:00] <burek> but only listed ones in the docs
[16:00] <burek> so i removed it later
[16:01] <burek> now it's just ,mux=ffmpeg{mux=flv},
[16:01] <burek> let me repaste logs
[16:01] <durandal_1707> burek: not going to read that mess again
[16:02] Action: ubitux loves av_hex_dump_log()
[16:02] <durandal_1707> but i see nowhere ffmpeg logs
[16:02] <durandal_1707> so ask videolan are such put in logs at all
[16:02] <burek> i understand you guys, just tell me how can I extract anything useful for debug and i'll do it
[16:02] <burek> im now search where av_log is defined so i can prefix it with something
[16:03] <durandal_1707> burek: you need to pass -v debug or something like that to vlc ....
[16:03] <burek> durandal_1707 you mean -vvv ?
[16:03] <burek> i did
[16:04] <ubitux> michaelni: the side data things seems to work fine :)
[16:04] <ubitux> (lavfi meta inject)
[16:05] <durandal_1707> burek: does that mean ffmpeg logs are debug too?
[16:05] <burek> do they show in the vlc's output log too? i guess yes
[16:05] <burek> let me check
[16:06] <durandal_1707> our logs have nice hex numbers
[16:06] <burek> and colors, i know :D
[16:06] <burek> durandal_1707 does this look like that: [flv @ 0x1583860] Codec for stream 0 does not use global headers but container format requires global headers
[16:07] <ubitux> not all the debug lines have it 
[16:07] <ubitux> (like those with a NULL context)
[16:07] <burek> can you just tell in which file is av_log defined
[16:08] <burek> so i can prefix it
[16:08] <burek> :S
[16:09] <ubitux> burek: libavutil/mem.c
[16:09] <ubitux> meh
[16:09] <ubitux> log.c sorry
[16:09] <burek> thanks
[16:10] <ubitux> look at the snprintf for av_log_default_callback
[16:10] <ubitux> and just add some stuff there
[16:10] <ubitux> (hopefully vlc didn't change that callback)
[16:11] <burek> snprintf(line, sizeof(line), "%s%s%s", part[0], part[1], part[2]);
[16:11] <burek> that?
[16:12] <ubitux> yes
[16:13] <burek> thanks a lot :)
[16:13] <ubitux> try adding "HELLO THIS IS BUREK" before the "%s...
[16:13] <burek> :)
[16:13] <burek> do i need to recompile both vlc/ffmpeg now
[16:13] <burek> or just ffmpeg
[16:13] <ubitux> if it's a static build you need to relink vlc
[16:14] <ubitux> (if vlc is linked statically against ffmpeg i mean)
[16:14] <durandal_1707> what happened to hex editing?
[16:14] <burek> :D
[16:14] <ubitux> durandal_1707 :D
[16:14] <burek> how can I hex edit to add something :D
[16:14] <burek> the string was just "%s%s%s"
[16:14] <burek> no space for prefix :)
[16:15] <burek> also, to speed up things, when i make such small changes
[16:15] <ubitux> look for free data area in the binary and dump some asm opcode in it, then add a jmp where appropriate
[16:15] <durandal_1707> burek: not trivial
[16:15] <burek> is it enough to delete log.obj
[16:15] <burek> log.o *
[16:16] <burek> or i must distclean
[16:16] <burek> ubitux right :D
[16:17] <durandal_1707> there should not be need to remove anything
[16:17] <burek> i tried just rm libavutil/log.o && make
[16:17] <burek> :D
[16:17] <burek> let's see what did I scr.. up now :D
[16:17] <cone-741> ffmpeg.git 03Paul B Mahol 076571833d1a54: smjpegdec: use url_feof() * 03http://tinyurl.com/8gnqb7q03
[16:34] <burek> do you know of any tool that can generate dependency diagram for ffmpeg source code
[16:44] <cone-741> ffmpeg.git 03Mans Rullgard 070daac647af00: avstring-test: fix memory leaks * 03http://tinyurl.com/9tfouxa03
[16:44] <cone-741> ffmpeg.git 03Mans Rullgard 07a77f01c72529: configure: use utilities from /usr/xpg4/bin if it exists * 03http://tinyurl.com/9ygltjm03
[16:44] <cone-741> ffmpeg.git 03Justin Ruggles 0761d5313d94c9: dca: allocate a secondary buffer for extra channels when downmixing * 03Error03
[16:44] <cone-741> ffmpeg.git 03Justin Ruggles 07f5962229bfcb: avplay: use audio parameters from the decoded frame instead of AVCodecContext * 03http://tinyurl.com/9x77bc703
[16:44] <cone-741> ffmpeg.git 03Michael Niedermayer 0715ef1cfe6431: Merge commit 'f5962229bfcb14c2879e69ccdf7f1a4934168609' * 03http://tinyurl.com/98j2urm03
[16:45] <ubitux> is it me or AV_PERM_ALIGN doesn't have any effect?
[16:45] <burek> do we have this in ffmpeg's doxygen http://www.stack.nl/~dimitri/doxygen/diagrams.html
[16:47] <burek> i think it would really help people to visualize how ffmpeg is structured: http://www.stack.nl/~dimitri/doxygen/examples/diagrams/html/inherits.html
[16:47] <burek> i just dont know who to bug for this feature :)
[16:47] <ubitux> we have ascii diagrams
[16:48] <ubitux> that's even better
[16:48] <burek> do you have any link perhaps?
[16:48] <burek> i clicked everything there and couldn't find :S
[16:50] <ubitux> it was a bad joke :)
[16:50] <burek> :s
[16:50] <burek> ok :)
[16:51] <burek> so we don't have any diagrams atm right?
[16:52] <ubitux> except http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/swscale.txt;hb=HEAD or http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/ffmpeg.txt;hb=HEAD 
[16:52] <ubitux> i dunno
[16:52] <ubitux> (i'm not even sure ffmpeg.txt is still up to date)
[16:54] <burek> ok
[16:54] <burek> who maintains ffmpeg's doxygen?
[16:54] <michaelni> we also have ascii art in snow.txt and some libavfilter headers
[16:54] <burek> http://ffmpeg.org/doxygen/trunk/index.html
[16:55] <burek> :)
[16:55] <michaelni> burek, do you volunteer to maintain it ?
[16:55] <burek> well, I would update it to 1.8.x
[16:55] <burek> and add Graphviz 
[16:55] <burek> :)
[16:56] <michaelni> burek, ask arpi or reimar 
[16:56] <burek> they are not on irc i guess?
[16:57] <cone-741> ffmpeg.git 03Michael Niedermayer 07d0707677fa50: ffplay: use audio parameters from the decoded frame instead of AVCodecContext * 03http://tinyurl.com/8qgw69k03
[16:58] <michaelni> ive seen arpi & reimar on IRC but thats months ? year ago
[16:58] <burek> great :)
[17:00] <michaelni> btw anyone has samples that the 2 avplay changes fixed ? so i can test (i failed to find a sample that didnt work before when trying a few that change parameters)
[17:01] <durandal_1707> michaelni: you mean midstream change of channels/samplerate/bps and such?
[17:02] <durandal_1707> i can give you generate sample which crashes lavfi
[17:03] <michaelni> iam interrested in one that fails before these patches and works afterwards
[17:03] <durandal_1707> could be on trac
[17:04] <michaelni> ffplay does not seem to have any problem with changes to samplerate before these patches
[17:06] <durandal_1707> i think avplay resample if samplerate changes
[17:07] <burek> ubitux thanks, but that didn't work unfortunately :/ there is no a single prefix in vlc's output :S
[17:07] <burek> i guess i'll just drop it
[17:12] <cone-741> ffmpeg.git 03Justin Ruggles 076304f78edf6a: avplay: support mid-stream sample rate changes * 03http://tinyurl.com/9vq74hn03
[17:12] <cone-741> ffmpeg.git 03Mashiat Sarker Shakkhar 075d2be71b9ecf: vc1: Use codec ID from AVCodecContext while parsing frame header * 03http://tinyurl.com/8fga9sv03
[17:12] <cone-741> ffmpeg.git 03Michael Niedermayer 072a56e65c3b3b: Merge remote-tracking branch 'qatar/master' * 03http://tinyurl.com/8vr7dyu03
[17:27] <ubitux> there are a lot of FF_API_* ignored warnings, normal?
[17:28] <durandal_1707> they should be set to 0
[17:29] <ubitux> s/ignored/not defined/ sorry
[17:49] <durandal_1707> wtf dvaudio decoder code was just removed
[17:49] <durandal_1707> and now 99 years after vlc reinvent wheel
[17:51] <durandal_1707> see 7458ccbb02a98ece4b4a9018a46eb13fff05b7c2
[17:51] <durandal_1707> michaelni: should we resurect this?
[17:52] <nevcairiel> the commit is from 2003, how is that "just"? :P
[17:52] <durandal_1707> and in 2012 vlc added support for it in its own code
[17:53] <nevcairiel> the dv demuxer seems to shuffle the dv audio around to make it proper s16le
[17:53] <durandal_1707> we have bug report for this on trac to use vlc code (sic)
[17:54] <durandal_1707> nevcairiel: that hack does not work for dvaudio in other containers
[17:54] <Compn> hmm?
[17:54] <Compn> jb_afk : durandal_1707 is freaking out , what happen? :)
[17:54] <Compn> ehe
[17:55] <nevcairiel> he is permanently freaking out about something
[17:56] <nevcairiel> what does one put dv audio in anyway? i bet mov :P
[17:56] <nevcairiel> it has all kind of crazy codecs
[17:57] <durandal_1707> imho dv demuxer idea is just wrong - it is not demuxer job to do that ....
[17:57] <durandal_1707> there were similar case which have been fixed
[17:58] <Compn> dv audio is seen in a lot of places
[17:58] <Compn> its an old codec
[17:58] <Compn> mov , avi at least
[18:02] <durandal_1707> the whole situation is just .....
[18:06] <Compn> why was dvaudio code removed ?
[18:06] <Compn> i havent looked into this
[18:06] Action: Compn distracted
[18:06] <durandal_1707> removed in 2003
[18:06] <durandal_1707> actually moved from decoder to demuxer
[18:07] <durandal_1707> and nobody complained....
[18:07] <Compn> oh lol
[18:07] <Compn> decoders dont belong there! :P
[18:07] <Compn> but dv stuff is usually encapsulated in a demuxer
[18:07] <Compn> so maybe thats why
[18:07] <Compn> i mean, encapsulated in dv
[18:08] <cone-741> ffmpeg.git 03Paul B Mahol 078288c2b6cb07: pngdec: read sample aspect ratio * 03http://tinyurl.com/9pd3b2m03
[18:08] <cone-741> ffmpeg.git 03Paul B Mahol 07f58f90238fc6: pngenc: write sample aspect ratio * 03http://tinyurl.com/8ext99g03
[18:08] <cone-741> ffmpeg.git 03Paul B Mahol 0793931143feb0: lavc: return s->get_buffer() error code if it errors out * 03http://tinyurl.com/9efbl5a03
[18:10] <durandal_1707> both avi and mov have fourcc/twocc for it
[18:11] <Compn> still could be encapsulated
[18:13] <durandal_1707> except avi ones are missing in riff
[18:13] <michaelni> for avi 2 modes exist at least
[18:14] <michaelni> one puts a dv stream with audio and video muxed together in a single stream 
[18:14] <michaelni> into avi
[18:14] <michaelni> so you need to chain demuxers ...
[18:16] <Compn> itd be nice if lavf would pass on or fake a fourcc if one is not listed in riff.c
[18:17] <Compn> instead of 'no streams found' it would say 'no known streams found, using 0x1337' or so 
[18:18] Action: michaelni has a fix for the PIX_FMT warning storm locally
[18:19] <Compn> or we could just add twocc to the list as we find samples. ... http://wiki.multimedia.cx/index.php?title=Twocc
[18:22] <Compn> similar problem with mov and isom.c of course...
[18:25] <Compn> or i may be remembering a problem that doesnt exist anymore
[18:25] <Compn> ignore me
[18:25] <Compn> time toeat lunchbbl
[18:33] <durandal_1707> michaelni: what you mean by chain demuxer?
[18:34] <durandal_1707> and how to support both cases without duplicating code?
[18:43] <burek> omg, I tried using Graphviz on ffmpeg's source code :))))))
[18:44] <burek> now that's called a really big graph! :D
[18:48] <ubitux> here we go, let's go back to some subtitles things.
[18:50] <cone-741> ffmpeg.git 03Michael Niedermayer 07c45b829d5258: tests: fix checksums for png aspect ratio change * 03http://tinyurl.com/9kkecrf03
[18:50] <cone-741> ffmpeg.git 03Dmitry Samonenko 07083c7bf70131: sdp: output speex optional vbr parameter * 03http://tinyurl.com/9k69how03
[18:50] <cone-741> ffmpeg.git 03Michael Niedermayer 07183117fed7d0: libavutil: loose idiotic circular dependancies between version and avutil.h * 03http://tinyurl.com/9mrr5rw03
[19:12] <burek> here is ffmpeg's source code "diagram" :D http://ffmpeg.gusari.org/uploads/gv1.png
[19:12] <burek> no point of zooming it up i believe :)
[19:16] <burek> this is how it looks like when actually zoomed up :) http://ffmpeg.gusari.org/uploads/gvchunk.png
[19:43] <burek> oh, someone already did it in doxygen :) nice :) http://fossies.org/dox/ffmpeg-1.0/dir_b4b104e2afbab17aa9ef07180757c615.html
[19:44] <durandal_1707> michaelni: where samples uploaded to upload.ffmpeg.org go?
[19:46] <saste> how can I upload a sample for FATE?
[19:46] <saste> (xface stuff)
[19:47] <durandal_1707> you upload it to upload.ffmpeg.org
[19:48] <durandal_1707> in upload dir and tell michaelni about it (my experience)
[19:53] <michaelni> any url where i can wget the file will do
[19:54] <durandal_1707> michaelni: i need access to wavpack sample in upload dir if it is still there
[19:55] <michaelni> look in http://streams.videolan.org/incoming/ and http://streams.videolan.org/ffmpeg
[19:58] <durandal_1707> first one needs authorization and second one does not have it
[20:03] <cone-741> ffmpeg.git 03Paul B Mahol 07a5e0046a730b: xbmdec: s/av_reverse/ff_reverse * 03http://tinyurl.com/8r6zn4v03
[20:05] <saste> michaelni, just sent a sample in my latest mail
[20:05] <saste> the sample is just few bytes
[20:07] <durandal_1707> saste: XFACE is not audio codec
[20:08] <durandal_1707> nor it is subtitle codec
[20:13] <nevcairiel> how does swscale do with scaling rgb->yuv420 with an odd number of lines? :d
[20:14] <durandal_1707> saste: redundant bytestream usage
[20:14] <saste> durandal_1707, ??
[20:14] <durandal_1707> saste: xface patch
[20:15] <durandal_1707> nevcairiel: it is broken?
[20:16] <nevcairiel> just wondering what it does, since an odd height is technically invalid for 420
[20:16] <saste> durandal_1707, where?
[20:16] <durandal_1707> saste: also you put AVCODEC and description in wrong place
[20:16] <durandal_1707> saste: xface_decode_frame
[20:17] <durandal_1707> nevcairiel: try and report ;-)
[20:18] <saste> durandal_1707, can you reply on ML?
[20:18] <saste> where should I put AVCODEC/desc?
[20:19] <saste> ah subtitles codecs... got it
[20:19] <durandal_1707> saste: why?
[20:21] <durandal_1707> yes i can reply to ml, but do i really need to....
[20:24] <saste> durandal_1707, no need
[20:25] <saste> really we could use a one-line macro for the codec description entries
[20:25] <saste> the list would be easier to read/sort then
[20:25] <michaelni> saste, xface uploaded 
[20:25] <saste> michaelni, thanks
[20:29] Action: durandal_1707 ....premier...
[20:47] <cone-741> ffmpeg.git 03Michael Niedermayer 078ab0b9cabaca: trasher: check seek return value. * 03http://tinyurl.com/8wktknh03
[20:47] <cone-741> ffmpeg.git 03Michael Niedermayer 0780db07adfe8a: probetest: check command line arguments * 03http://tinyurl.com/8ovj2mb03
[20:47] <cone-741> ffmpeg.git 03Michael Niedermayer 07225d3cc1ccd8: ffeval: avoid folding EOF onto a valid char * 03http://tinyurl.com/9h8893v03
[20:52] <cone-741> ffmpeg.git 03Paul B Mahol 072c85727f6c17: lavc/codec_desc: add/update properties of some codecs * 03http://tinyurl.com/8ueqmuj03
[20:57] <durandal_1707> ffmpeg -codecs | grep DEVIL
[20:59] <durandal_1707> dpx and sgi should not be there
[21:18] <cone-741> ffmpeg.git 03Michael Niedermayer 07c0f0bec2f205: sws-test: check W/H * 03http://tinyurl.com/95cg26303
[21:18] <cone-741> ffmpeg.git 03Michael Niedermayer 073689ec3d28d7: pp: avoid overflow in w*h * 03http://tinyurl.com/9x7ns9903
[21:21] <saste> i'm dealing with a silly container format which stores all audio packets, followed by video packets
[21:22] <saste> does it make sense to cache all the video packets in the encoder context, and then release then at the end?
[21:22] <saste> do we already do something similar?
[21:22] <durandal_1707> you mean half files is audio and another is video?
[21:22] <saste> yes, silly no?
[21:23] <Daemon404> saste, what container is this
[21:23] <Daemon404> and why does it exist
[21:23] <durandal_1707> you do not write such muxers at first place
[21:23] <saste> http://dpg.software.informer.com/wiki/
[21:23] <Daemon404> oh
[21:24] <Daemon404> that abomination.
[21:24] Action: Daemon404 un-reads
[21:24] <saste> don't ask me why it exists, people do silly things all the time
[21:25] <saste> can't be worse than 8svx (left channel data, followed by right channel data)
[21:25] <durandal_1707> the only way i see it is write 2 temp files and cat it them at end
[21:26] <saste> durandal_1707, that would be basically a script
[21:26] <saste> i wonder if it makes sense to have a native muxer/demuxer in ffmpeg
[21:27] <saste> a lot of caching involved
[21:27] <durandal_1707> saste: with current API not
[21:27] <saste> well i could cache them, and hog the memory
[21:27] <saste> for small files (the typical use case) it shouldn't be really an issue
[21:28] <durandal_1707> ask them to remove older versions from internet and write new one
[21:29] <durandal_1707> but why you want to write muxer? you already wrote demuxer?
[21:30] <saste> no, i didn't even start
[21:30] <saste> so i'm asking if it makes sense
[21:30] <saste> as for demuxing, would it work, or i would need to cache data in the demuxer, when waiting for the video data?
[21:31] <durandal_1707> just do seek and tell user that pipe support is fantasy
[21:56] <ubitux> 19:12:25 < burek> here is ffmpeg's source code "diagram" :D http://ffmpeg.gusari.org/uploads/gv1.png // hehe i think i know where mpegenccontext is!
[21:59] <Compn> thats pretty neat
[22:03] <ubitux> what's the problem with anonymous typedef?
[22:03] <ubitux> i don't really see the point of writing the same name twice...
[22:04] <ubitux> (and well, that's actually an anonymous struct afaict)
[22:08] <Daemon404> if it has a name i dont mind
[22:08] <Daemon404> it's stuff like this that annoys me:
[22:08] <Daemon404> struct derp {
[22:08] <Daemon404> int a;
[22:09] <burek> ubitux, did you see the link to latest doxygen? :)
[22:09] <Daemon404> uninion {double a; uint64_t b;}
[22:09] <Daemon404> }
[22:09] <Daemon404> i.e. completely anonymous with no name
[22:09] Action: ubitux likes static const struct { int a, b; } foobar[] = { ... };
[22:09] <Daemon404> shame on you
[22:09] <Daemon404> thats horrible
[22:09] <ubitux> why?
[22:10] <burek> they did exactly what I was thinking it would be the best :) they separated that huge diagram into relevant pieces so while you browse the file structure (menu on the left) you get the relevant diagram for selected file(s)
[22:10] <ubitux> burek: no, i didn't open, i don't care that much :p
[22:10] <ubitux> oh or maybe i saw that one
[22:10] <Daemon404> it's ugly, harder to follow, etc
[22:10] <ubitux> there is nothing really to follow..
[22:10] Action: Daemon404 also dislieks compound literals
[22:17] <Compn> ubitux : Daemon404 wants to know what the code does
[22:17] <Compn> by giving it a name
[22:17] <Compn> like moving-derp-to-array or something, it makes reading the code easier
[22:18] <Compn> and people can reuse code too
[22:18] <Compn> if they know what the heck its doing :)
[22:18] Action: Compn guesses anyways. anonymous, named, makes no diff to me
[22:29] <ubitux> saste: reviewing your xface thing atm
[22:30] <Compn> what is xface ?
[22:30] <Compn> i refuse to google it
[22:31] <Daemon404> a horrible thign from the 80s
[22:32] <Daemon404> much like stryper
[23:01] <ubitux> anyone to review my swf patch?
[23:01] <ubitux> and/or the lavfi meta injection through side data?
[23:02] <ubitux> saste: btw, don't forget to bump
[23:11] Action: ubitux just opened saste.xface and laughed
[23:11] <ubitux> it reminds me some double-face mind trick picture...
[23:12] <ubitux> without the trick
[23:20] <ubitux> ok let's review the gif thing now.
[00:00] --- Sun Oct 14 2012


More information about the Ffmpeg-devel-irc mailing list