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

[burek]

[00:00] <burek> ubitux, by just "changing the message", you are actually accepting that it's ok for libav to distribute your own tool.. wouldn't it rather be ok to ask debian to either entirely remove ffmpeg or to entirely remove the problematic (3rd party) message
[00:00] <burek> and if they really want to inform their users about avconv, they can do it in the description for the deb package itself
[00:01] <burek> and not crippling the binary with falsified messages that confuse a lot of people
[00:01] <ubitux> by changing the message, i'm accepting the debian has technical and political issues with packaging ffmpeg
[00:01] <cone-946> ffmpeg.git 03Carl Eugen Hoyos 071a104bf641b1: Fix broken timestamps for some mp3 in avi samples. * 03http://tinyurl.com/9crqlqs03
[00:01] <ubitux> burek: well, if debian decides to package libav, which is their choice, they have to inform the user that a given program will disappear
[00:02] <burek> when people see that ffmpeg binary outputs that "message" it is normal to expect that they understand that FFmpeg developers wrote that message.. that's what is wrong in all this
[00:02] <ubitux> (and that syntax will change etc)
[00:02] <ubitux> yes
[00:02] <ubitux> that's why i just want to fix the message :)
[00:02] <burek> you don't need to make effort and ask them politely to "change" the message
[00:02] <ubitux> really it's not much.
[00:02] <burek> you should either sue them for copyright infringement or demand they remove it immediately
[00:03] <ubitux> i'm not familiar with the legal system, and i don't like that stuff
[00:03] <burek> well, if someone takes your work and changes the output of your program, claiming that you did it, then what?
[00:04] <burek> any country will take you to the jail for that
[00:04] <burek> but, anyway, as one smart person here told me once :) I have much important things to do then to fight other people's battles :)
[00:05] <ubitux> burek: really, it's quite complex to switch package names in debian
[00:05] <ubitux> since they want to keep retro compat
[00:05] <ubitux> it's a "stable" distro
[00:05] <burek> it's their problem, not yours
[00:05] <ubitux> yes but i understand it's not solvable now
[00:05] <iive> imho, switching the project is not the most compatible thing to do.
[00:05] <ubitux> and if they aren't even willing to fix a fucking message
[00:06] <ubitux> they won't take the pain to fix that correctly
[00:06] <gnafu> lol at going to jail for modifying an open source program's output
[00:06] <burek> gnafu, you are not modifying it, you are distributing it
[00:06] <burek> not just *
[00:06] <gnafu> Still I have never once heard of someone going to jail for that.
[00:06] <ubitux> enough derping for tonight
[00:06] Action: ubitux &
[00:06] <ubitux> 'night
[00:07] <j-b> gnafu: over-reaction, maybe
[00:07] <Skyler_> burek: the LGPL explicitly allows you to do that
[00:07] <Skyler_> Trademark law is what's relevant here, not copyright.
[00:07] <burek> I don't know why I even spend my time on this topic any more
[00:07] <burek> do what ever you want guys
[00:08] <burek> its you who will profit/suffer from all the results
[00:08] <Skyler_> You're probably better off not unless you understand the details involved
[00:08] <burek> (@devels)
[00:08] <Skyler_> Just yelling about suing people doesn't actually solve problems
[00:08] <burek> I agree
[00:08] <burek> & :)
[00:10] <iive> ubitux: hi is not changing the message because the issue is obscure and he can get away with it. But if it is a public issue... then pointing that he had rejected a perfectly acceptable proposal would be quite damning.
[00:10] <iive> hi/he
[00:10] <Skyler_> (Basically, using legal solutions to social problems isn't generally a good idea)
[00:11] <iive> absolutely. court should be the last instances, and the first thing they would ask is "what you did in order to try fixing this problem?"
[00:11] <burek> [22:33:23] <llogan> burek, relaxed: interested in making a mini guide on trac wiki on how to make static builds? <-  yes, but i _really_ need some help with that, since i'm in no way the best person to write about such thing
[00:12] <burek> that cron for static builds i've made was.. so to say.. a lucky shot :)
[01:16] <llogan> burek: ok. it was just an idea, and i'm willing to help
[01:18] <burek> no problem, we'll see in next couple of days to get it done :)
[01:18] <llogan> days? i usually take months, but you're uncommonly fast (ie fflogger, etc)
[01:21] <burek> i hope it will stay that way :)
[01:43] <michaelni> who wants an account at coverity for ffmpeg ?
[01:46] <Compn> michaelni : just make up some new accounts and you can pass them out whenever someone wants one :P
[01:47] <llogan> I think you should ax this question on the mailing list
[01:47] <michaelni> llogan, yes
[01:47] <michaelni> Compn, i need to enter full name and email address of each person
[01:47] <llogan> but compn has no last name
[01:48] <llogan> sorry, you're excluded
[01:48] <Compn> john doe - random at ffmpeg.org etc 
[01:48] Action: Compn has never truthfully filled out a form on the internet
[01:48] <Compn> ehe
[01:48] <Compn> lots of people live at 123 fake street
[02:00] <burek> true :D
[02:23] <cone-946> ffmpeg.git 03Michael Niedermayer 07cac749a551b2: vf_idet: fix free after use * 03http://tinyurl.com/8goykuz03
[02:23] <cone-946> ffmpeg.git 03Michael Niedermayer 074d4f431ab7b1: vf_idet: zero pointers after freeing references * 03http://tinyurl.com/9q5jscz03
[02:23] <cone-946> ffmpeg.git 03Matthieu Bouron 07e782d8728f1e: fate: add vf_idet filter to lavfi regression tests * 03http://tinyurl.com/9k5hvap03
[02:23] <cone-946> ffmpeg.git 03Michael Niedermayer 07fac1ccbda1bb: swscale-test: fix freeing of uninitialized variable * 03http://tinyurl.com/94tzctg03
[03:05] <cone-946> ffmpeg.git 03Michael Niedermayer 074e4ae2f82caa: sha: change loop condition to be tighter. * 03http://tinyurl.com/9g2tzya03
[03:05] <cone-946> ffmpeg.git 03Michael Niedermayer 07989c91b5042c: asrc_aevalsrc: Fix use of uninitialized pointer inside av_strtok() * 03http://tinyurl.com/95c795603
[03:07] <michaelni> j-b, can you or thresh make cone print more than the first line ? (for example one cant see if a commit fixes some/which ticket coverity id now)
[03:08] <Daemon404> was this coverity scan just published or something?
[03:11] <Compn> oh
[03:11] <Compn> i had a naughty idea
[03:11] <Compn> argh no that wont work, nevermind
[03:38] <cone-946> ffmpeg.git 03Michael Niedermayer 07bdcff5af7f08: af_volumedetect: fix use of uninitilaized variable in case of planar audio. * 03http://tinyurl.com/8lxcxdv03
[03:38] <cone-946> ffmpeg.git 03Michael Niedermayer 074334ba043e96: ffprobe: fix use of uninitialized pointer in av_strtok() * 03http://tinyurl.com/8zeftwy03
[04:03] <cone-946> ffmpeg.git 03Michael Niedermayer 07e47ab0b2c93e: ffmpeg_opt: dont fail for sameq/same_quant. * 03http://tinyurl.com/8aczbce03
[04:38] <burek> Program received signal SIGSEGV, Segmentation fault. :)
[04:47] <cone-946> ffmpeg.git 03Michael Niedermayer 077df9f595c912: swri_resample_init: unsupported sample formats are an internal error. * 03http://tinyurl.com/8oym4k603
[04:47] <cone-946> ffmpeg.git 03Michael Niedermayer 07492b8ec4c5f5: av_opt_set_from_string: fix memleak * 03http://tinyurl.com/8wn8mow03
[07:26] <ubitux> what's this CID thing?
[07:30] <ubitux> oh, a coverity thing.
[10:11] <cone-308> ffmpeg.git 03Paul B Mahol 078cd1c0febe88: pcx: convert to bytestream2 API * 03http://tinyurl.com/8sza24f03
[10:54] <ubitux> saste: a few seconds to encode a xface? oO
[10:54] <ubitux> fear :D
[10:55] <saste> ubitux, ~1000 bigint divisions, and apparently our division algo can be improved
[10:55] Action: durandal_1707 wtf, facebook ask me to log in
[11:10] <cone-308> ffmpeg.git 03Stefano Sabatini 07396648cc6a3e: configure: link flite against libasound * 03http://tinyurl.com/9fa28bu03
[11:18] <saste> damn my last commit is wrong
[11:18] <saste> disallow compilation wherever asound is not available
[11:24] <cone-308> ffmpeg.git 03Stefano Sabatini 07c4aaff8c02ce: Revert "configure: link flite against libasound" * 03http://tinyurl.com/8lbb8k603
[12:45] <saste> ubitux: any plan to support metadata printing through drawtext?
[13:08] <ubitux> saste: nope but that would be nice
[13:09] <ubitux> saste: btw, about moving scene detection out of select can be done but...
[13:09] <ubitux> how do you add metadata support in select?
[13:09] <saste> yes that's no easy
[13:09] <saste> maybe we could have a separate selectmeta
[13:09] <ubitux> and same for drawtext actually
[13:10] <ubitux> we need another formatting systeme
[13:10] <ubitux> -e
[13:10] <saste> yes, desigining it in a generic way may be tricky
[13:10] <ubitux> (so we could add meta replace, or timestamp, or things like that)
[13:11] <ubitux> the string interpolation thing i wrote a while ago might help for the drawtext thing
[13:11] <ubitux> but for select i don't know
[13:11] <ubitux> we need to extend the eval api
[13:11] <saste> ideally: drawtext="$$pts:$pts $$pts_time:$pts_time ${meta/comment}"
[13:12] <ubitux> to support an AVDictionary or something
[13:12] <ubitux> well you could imagine in eval something like "@scene"
[13:12] <ubitux> so it will pick in the passed dict 
[13:49] <ubitux> saste: unrelated: https://www.youtube.com/watch?v=KJe9H6qS82I :)
[14:08] <cone-308> ffmpeg.git 03Diego Biurrun 07ada12f836657: svq1: K&R formatting cosmetics * 03http://tinyurl.com/95akuqh03
[14:09] <cone-308> ffmpeg.git 03Mans Rullgard 0741e46a5fbacc: parseutils-test: do not print numerical error codes * 03http://tinyurl.com/965ukvg03
[14:09] <cone-308> ffmpeg.git 03Diego Biurrun 0763a46c6101ff: svq1: Drop a bunch of useless parentheses * 03http://tinyurl.com/953zgp903
[14:09] <cone-308> ffmpeg.git 03Jean-Baptiste Kempf 07507dce2536fe: arm: call arm-specific rv34dsp init functions under if (ARCH_ARM) * 03http://tinyurl.com/9a8anm303
[14:09] <cone-308> ffmpeg.git 03Janne Grunau 07706a559b3008: a64multienc: change mc_frame_counter to unsigned * 03http://tinyurl.com/8gm6wxy03
[14:09] <cone-308> ffmpeg.git 03Mashiat Sarker Shakkhar 077fb35ee931c8: vc1dec: Use correct spelling of "opposite" * 03http://tinyurl.com/8cqtaam03
[14:09] <cone-308> ffmpeg.git 03Luca Barbato 0782569b01a1cb: mpegtsenc: set muxing type notification to verbose * 03http://tinyurl.com/9ud7n6t03
[14:09] <cone-308> ffmpeg.git 03Luca Barbato 07b522000e9b2c: avio: introduce avio_closep * 03http://tinyurl.com/8rngceh03
[14:09] <cone-308> ffmpeg.git 03Michael Niedermayer 07de31814ab07f: Merge commit 'b522000e9b2ca36fe5b2751096b9a5f5ed8f87e6' * 03http://tinyurl.com/9xnz9ga03
[14:12] <j-b> \o/
[14:32] <cone-308> ffmpeg.git 03Luca Barbato 0726db9100b2fa: segment: support applehttp style list * 03http://tinyurl.com/9dn55ux03
[14:32] <cone-308> ffmpeg.git 03Mashiat Sarker Shakkhar 0788058d9a994f: vc1dec: Set chroma reference field from REFFIELD for 1REF field pictures * 03http://tinyurl.com/8d8mry603
[14:32] <cone-308> ffmpeg.git 03Michael Niedermayer 07b6c3487e7f2f: Merge commit '88058d9a994f42e4e9ed4e67baf696bbfe53128c' * 03http://tinyurl.com/8crhvvn03
[14:36] <cone-308> ffmpeg.git 03Mashiat Sarker Shakkhar 077cc3c4e1d417: vc1dec: Invoke edge emulation regardless of MV precision for 1-MV chroma * 03http://tinyurl.com/8v98af403
[14:36] <cone-308> ffmpeg.git 03Michael Niedermayer 07ce27c9eb2598: Merge commit '7cc3c4e1d4179aeabcd891090e31ee5e5bfd9692' * 03http://tinyurl.com/8lsxjqf03
[14:39] <cone-308> ffmpeg.git 03Mashiat Sarker Shakkhar 07eb657ecefdeb: vc1dec: Set opposite to the correct value for 1REF field pictures * 03http://tinyurl.com/94hcfq203
[14:39] <cone-308> ffmpeg.git 03Michael Niedermayer 07a75dd13b1bc2: Merge commit 'eb657ecefdeb8b2ed9bfb55d3c2c9e0f568486bf' * 03http://tinyurl.com/9aabvqk03
[15:02] <durandal11707> if input is pipe there is no way to find its size?
[15:02] <nevcairiel> no, pipes dont tell you their size
[15:02] <iive> what would the size represent? the number of bytes written?
[15:10] <durandal11707> how parser than work for last packets when using pipes?
[15:18] <durandal11707> what's about this coverity account?
[15:51] <cone-308> ffmpeg.git 03Mashiat Sarker Shakkhar 0735a35d49d23c: Double motion vector range for HPEL interlaced picture in proper place * 03http://tinyurl.com/8qnj74u03
[15:51] <cone-308> ffmpeg.git 03Janne Grunau 07bd141f5ec97f: mxfdec: return error if no segments are available in mxf_get_sorted_table_segments * 03http://tinyurl.com/8q9ec2e03
[15:51] <cone-308> ffmpeg.git 03Janne Grunau 076d556e8327f6: indeo4/5: remove constant parameter num_bands from wavelet recomposition * 03http://tinyurl.com/9pxaala03
[15:51] <cone-308> ffmpeg.git 03Janne Grunau 07c466eb174699: flashsv: propagate inflateReset() errors * 03http://tinyurl.com/9fq5yxt03
[15:51] <cone-308> ffmpeg.git 03Janne Grunau 0725227c3a78fe: averror: explicitly define AVERROR_* values * 03http://tinyurl.com/8dvnddg03
[15:51] <cone-308> ffmpeg.git 03Janne Grunau 078d09d39a4b87: avconv: remove bogus warning when using avconv -h without parameter * 03http://tinyurl.com/9l8hcg203
[15:51] <cone-308> ffmpeg.git 03Janne Grunau 07b404c6605627: fate: add h263 obmc vsynth tests * 03http://tinyurl.com/9krchdj03
[15:51] <cone-308> ffmpeg.git 03Mans Rullgard 07568c70e79ee2: lavfi: convert input/ouput list compound literals to named objects * 03http://tinyurl.com/8rtgys803
[15:51] <cone-308> ffmpeg.git 03Mans Rullgard 074436f25a1682: build: remove references to unused EXTRAOBJS variable * 03http://tinyurl.com/8lte4qf03
[15:51] <cone-308> ffmpeg.git 03Michael Niedermayer 07526cb36e4b23: Merge commit '4436f25a1682ada3f7226cb6fadf429946933161' * 03http://tinyurl.com/9xfd3rz03
[16:00] <cone-308> ffmpeg.git 03Mans Rullgard 07e5c6e9a6f2d0: build: remove single-use variable THIS_LIB * 03http://tinyurl.com/8wpfwne03
[16:00] <cone-308> ffmpeg.git 03Mans Rullgard 071c7428e6554a: build: whitespace cosmetics * 03http://tinyurl.com/9puetax03
[16:00] <cone-308> ffmpeg.git 03Mans Rullgard 07effe443877c5: build: do not use LIB as variable name * 03http://tinyurl.com/8f6f3kz03
[16:00] <cone-308> ffmpeg.git 03Janne Grunau 071a2c7880aa1c: averror: make error values proper negative values * 03http://tinyurl.com/8hz8qy703
[16:00] <cone-308> ffmpeg.git 03Mans Rullgard 0725dc79bc1433: sh4: add required #include, fix build * 03http://tinyurl.com/8d8q99c03
[16:00] <cone-308> ffmpeg.git 03Luca Barbato 072d6caade2233: dsputil: split out mlp dsp function * 03http://tinyurl.com/9an7mkq03
[16:00] <cone-308> ffmpeg.git 03Luca Barbato 071ec629308652: mlpdsp: adding missing file * 03http://tinyurl.com/94n5pjx03
[16:00] <cone-308> ffmpeg.git 03Michael Niedermayer 07bb3586475919: Merge remote-tracking branch 'qatar/master' * 03http://tinyurl.com/97ebva303
[16:07] <michaelni> durandal11707, if you want an account i can create one, you can then see all the bugs coverity found in ffmpeg once the account is approved by them, i dont know how long that takes
[16:09] <durandal11707> michaelni: yes i want to kill bugs
[16:12] <michaelni> durandal11707, account requested
[16:15] <michaelni> Tjoppen, mateo`, ctx leaks in mxf_read_local_tags() in the error cases (CID733800)
[16:16] <michaelni> do you 2 want accounts ?
[16:18] <ubitux> michaelni: thx for adding me :)
[16:19] <michaelni> ubitux, did you already get the account or are you still waiting ?
[16:19] Action: michaelni us curious how long it takes
[16:20] <michaelni> Is
[16:21] <Tjoppen> michaelni: uh.. where? I don't see anything on the ml
[16:22] <michaelni> Tjoppen, what do you want to see on the ml ?
[16:23] <ubitux> michaelni: nope i'm still waiting
[16:25] <Tjoppen> what error case are you talking about?
[16:26] <michaelni> Tjoppen, mxf_read_local_tags allocates MXFMetadataSet *ctx
[16:26] <michaelni> its not freed on returns in case of some errors
[16:27] <michaelni> and not stored anywhere where it could be freed later
[16:28] <Tjoppen> oh yeah, you're right
[16:28] <Tjoppen> it also breaks strict aliasing
[16:30] <Tjoppen> oh, goody:
[16:30] <Tjoppen> if (ctx_size && tag == 0x3C0A)
[16:30] <Tjoppen> avio_read(pb, ctx->uid, 16);
[16:30] <Tjoppen> so if I put a UID tag in the primer package it'll overwrite.. MXFPartition *partitions in MXFContext
[16:32] <Tjoppen> mxf_metadata_read_table[] ought to be split up into two parts - one for reading directly into MXFContext and one for reading into an MXFMetadataSet
[16:34] <Tjoppen> anyway, ctx should only be av_free()'d if ctx_size > 0
[16:35] <Tjoppen> heh, it does check ctx_size before reading UID. doi!
[16:39] <burek> has anyone built static ffserver, ffplay and ffprobe?
[16:39] <burek> for linux
[16:48] <Daemon404> many, why?
[16:49] <burek> are there any docs about it?
[16:49] <Tjoppen> what kind of problem are you having?
[16:51] <burek> dlopen and dns-related libs wont compile statically
[16:51] <burek> so I'm looking for some docs of the people that managed to build it
[16:51] <burek> to see what I was doing wrong
[16:53] <JEEBsv> yeah, Daemon404 probably understood as a static bin that doesn't have /everything/ from the OS side in it. Those system libs are always "fun" to hack to be "static"
[16:53] <JEEBsv> aka "there be dragons"
[16:54] <michaelni> Tjoppen, do you want a coverity account so you can see bugs like that mxfdec leak ?
[16:55] <Tjoppen> sure
[16:55] <av500> WHERE ARE MY DRAGONS!!!
[16:55] <cone-308> ffmpeg.git 03Michael Niedermayer 077457da3698c6: drawtext: fix leak with timecodes * 03http://tinyurl.com/9ad2xor03
[16:55] <cone-308> ffmpeg.git 03Michael Niedermayer 079ba2484ece53: af_aresample: fix leak on alloc failure * 03http://tinyurl.com/95y7cqp03
[16:55] <cone-308> ffmpeg.git 03Michael Niedermayer 074b20b21b8dab: tiff: fix leak on error return in doubles2str() * 03http://tinyurl.com/93akwgr03
[16:56] <Daemon404> burek, dlopen and statis are mutually exclusive
[16:56] <Daemon404> static*
[16:56] <Daemon404> and yes i have build an entirely static ffmpeg
[16:57] <Daemon404> built*
[16:57] <Daemon404> but not with networking crap
[16:57] <durandal_1707> with kernel in it?
[16:57] <Daemon404> obviously not relevant
[16:57] <Tjoppen> I have a new PGP key btw
[16:57] <Daemon404> but iwht libc and pals
[16:57] <Daemon404> with*
[16:57] <burek> Daemon404, well I didn't ask about ffmpeg, read again :)
[16:57] <Tjoppen> I should send in a patch to update MAINTAINERS I suppose
[16:58] <Daemon404> burek, statically linking network libs is a Bad Idea
[16:58] <Daemon404> end of story
[16:58] <Daemon404> dont do it.
[16:58] <michaelni> Tjoppen, coverity account creation requested
[16:59] <Tjoppen> k
[17:07] <durandal_1707> framesha256
[17:16] <cone-308> ffmpeg.git 03Michael Niedermayer 07229ccce6cca7: libxvid_rc: fix leaks in ff_xvid_rate_control_init() * 03http://tinyurl.com/9p7hsvx03
[17:16] <cone-308> ffmpeg.git 03Michael Niedermayer 07c9454cb643f5: av_tempfile: fix leak in error case * 03http://tinyurl.com/9nrzk6e03
[17:19] <ubitux> this analyzer looks quite useful :)
[17:44] <Tjoppen> how do I search for filenames on coverity?
[17:45] <ubitux> you already have your account?
[17:45] <Tjoppen> yes. I'm in there looking around. the interface is very JS heavy
[17:46] <ubitux> maybe i should check my spam inbox...
[17:48] <durandal_1707> ubitux: my is in spam!!!
[17:48] <Tjoppen> there we go. this is rather neat
[17:48] <ubitux> durandal_1707: ah indeed mine too
[17:50] <ubitux> heh fun.
[17:59] <ubitux> ah i'll fix the ebur128 derp.
[17:59] Action: ubitux &
[18:01] <Tjoppen> the warnings in the h264 templates are rather.. interesting
[18:02] <burek> h264 encoder in c920 logitech webcam is ok, but is far from libx264.. libx264 could stream 640x360 @ 30fps at 512k without any artifacts, I don't know how :)
[18:07] <cone-308> ffmpeg.git 03Michael Niedermayer 07104b1d9e103f: libvpxenc: fix memleak on error path * 03http://tinyurl.com/8skfd6r03
[18:07] <cone-308> ffmpeg.git 03Michael Niedermayer 0734bbab432ca0: jpeglsnec: fix memleak of state in error case * 03http://tinyurl.com/8vkgbo703
[18:07] <cone-308> ffmpeg.git 03Michael Niedermayer 07b96d1859d523: jpeglsenc: favor av_freep() for saftey over av_free() when a variable is still accessible afterwards * 03http://tinyurl.com/8nyzb7h03
[18:08] <durandal_1707> michaelni: truemotion ones looks like false positive
[18:14] <michaelni> durandal_1707, if they are false positives, please mark them as such
[18:19] <michaelni> hi philipl, do you want a coverity account ?
[18:32] <cone-308> ffmpeg.git 03Michael Niedermayer 07adcbb3fd8b23: yuv2rgb: fix declared array sizes, so they match actuals. * 03http://tinyurl.com/8uym7vz03
[18:32] <cone-308> ffmpeg.git 03Michael Niedermayer 077fe554853152: random_seed: fix out of array read * 03http://tinyurl.com/9ydq9bg03
[18:33] <cone-308> ffmpeg.git 03Michael Niedermayer 0726474d1098eb: random_seed: fix digest size * 03http://tinyurl.com/8eny4t603
[18:39] <cone-308> ffmpeg.git 03Clément BSsch 079ad1ea13e08f: lavfi/ebur128: fix typo in condition. * 03http://tinyurl.com/9meuw3703
[18:40] <ubitux> does "Fix submitted" means still pending for review?
[18:40] <ubitux> or i'm supposed to select the fixed/tested/documented option?
[18:42] <ubitux> also, what's the "Apply + Next"?
[18:46] <Compn> probably 'apply changes and move to next bug
[18:47] <ubitux> saste: there are a lot of easy bugfixes all over lavfi and stuff spotted by coverity :p
[19:22] <llogan> saste: i got the ppc, but i can't figure out how to separate it from the existing lan. duh.
[19:24] <ubitux> pull the cable
[19:24] <llogan> oops. wrong one.
[20:07] <cone-308> ffmpeg.git 03Paul B Mahol 07313b40efbd63: bmp: unbreak non BMP_RGB compression for v4 and v5 * 03http://tinyurl.com/9lhq4y703
[20:29] <durandal_1707> michaelni: how to handle out of read in tgq_decode_block? it may cost too much
[20:42] <michaelni> durandal_1707, the index from the scantable is 8bit thus if block is oversized a bit no overread can happen
[20:43] <llogan> michaelni: the coverity login worked fine
[20:44] <durandal_1707> michaelni: the i++ happens more than once and it can be bigger than 64 inside loop
[20:46] <michaelni> i is used as index in perm[] that is a array in a struct, after the array is another array of 64 elements
[20:46] <michaelni> so i can be up to 127 
[20:47] <michaelni> perm[] again is used as index into block[] but this index is just 8bit
[20:47] <durandal_1707> hah
[20:47] <michaelni> so if block has some spare elements at the end it looks safe from a quick look
[20:54] <durandal_1707> the mpc8 one is false positive but code looks fishy
[21:01] <DelphiWorld> hi ffmpeg developers
[21:01] <DelphiWorld> anyone arround ?
[21:08] <DelphiWorld> opening rtmp stream sucsessfully but hanging on99,99
[21:09] <DelphiWorld> llogan: HERE!:-P
[21:10] <DelphiWorld> llogan: sadly the bug gui of ffmpeg is not spoken using my screen reader
[21:11] <llogan> then describe your issue, including steps to duplicate if possible
[21:12] <DelphiWorld> llogan: issue: opening RTMP stream using ffmpeg or ffserver hang.
[21:12] <DelphiWorld> describing how to duplicate.
[21:12] <DelphiWorld> FYI, i used --enable-librtmp
[21:27] <DelphiWorld> llogan: log here: http://dpaste.com/812586/
[21:34] <llogan> DelphiWorld: i don't have any ffserver experience, but ffplay plays the stream just fine if that means anything
[21:35] <DelphiWorld> llogan: is my config correct ?
[21:35] <DelphiWorld> llogan: do you have output using ffplay ?
[21:35] <llogan> no, but it tells you that the issue isn't with decoding
[21:35] <DelphiWorld> llogan: but ffplay have sound output ?
[21:36] <llogan> yes, it is a simple player
[21:36] <DelphiWorld> llogan: i dont have ffplay
[21:37] <llogan> maybe someone can help you on the ffserver-user mailing list. i can't offer much help with ffserver and rtmp junk.
[21:37] <DelphiWorld> i compiled ffmpeg from git. where's ffplay ?
[21:38] <ubitux> you need sdl libs to get ffplay built
[21:38] <ubitux> #define HAVE_SDL 1
[21:38] <ubitux> (config.h)
[21:38] <ubitux> will be set to 1 automatically if you have the necessary libs
[21:39] <ubitux> DelphiWorld: this isn't the user channel btw
[21:39] <DelphiWorld> ubitux: i know, i thought this is a ffmpeg bug
[21:40] <DelphiWorld> ubitux: can you see that junky bug?
[21:40] <ubitux> sorry i didn't backlog enough
[21:40] <ubitux> dunno for your bug
[21:43] <cone-308> ffmpeg.git 03Paul B Mahol 073632f35c8e16: bethsoftvid: check return value of av_packet_new_side_data() * 03http://tinyurl.com/8r3tt5g03
[21:43] <DelphiWorld> opening rtmp stream sucsessfully but hanging on99,99
[21:43] <DelphiWorld> ubitux:  log here: http://dpaste.com/812586/
[21:44] <ubitux> i saw, but i don't have time for this, sorry :p
[21:44] <DelphiWorld> ubitux: i give you time:-P
[21:45] Action: ubitux smallows it all
[21:46] <DelphiWorld> ubitux: ;)
[21:55] <DelphiWorld> ubitux: work using a feed. but not using a file. so i  am using feeds.
[22:06] <bryno> how would I be able to add a custom protocol? ffurl_register_protocol is considered "private"...
[22:08] <durandal_1707> bryno: contribute it?
[22:09] <bryno> err.. no?
[22:11] <ohsix> no? heh
[22:12] <bryno> if that's the answer, then why expose any of the register functions? :P
[22:13] <bryno> i'm just wondering what happened to that protocol layer
[22:13] <ohsix> didn't you say it was private?
[22:13] <bryno> the other register functions like for registering input/output formats or codecs
[22:20] <durandal_1707> bryno: it got removed long ago
[22:20] <ubitux> michaelni: any comment on the metadata in AVPacket->priv?
[22:21] <durandal_1707> if you want it back fill bug report (and it was removed by fork)
[22:25] <michaelni> ubitux, i dont like using pkt.priv for metadata
[22:25] <michaelni> it feels wrong
[22:25] <ubitux> do you have any other suggestion?
[22:26] <michaelni> what needs to pass metadata to what through avpackets ?
[22:27] <ubitux> the lavfi device use its internal filtergraph
[22:27] <ubitux> and it needs to get the metadata out of the buffer ref from its sink
[22:27] <ubitux> and transmit them up to the AVFrame
[22:27] <ubitux> since it produces AVPacket, we need a way of communicating through them
[22:28] <ubitux> maybe it would make sense to use this flag *only* for this lavfi device
[22:28] <ubitux> AV_PKT_FLAG_HACKLAVFI
[22:28] <ubitux> or even FF_PKT_FLAG_HACKLAVFI
[22:29] Action: durandal_1707 it ruins my day when i read HACK in code
[22:30] <ubitux> i can call it FF_PKT_FLAG_ILY_DURANDAL if you prefer
[22:30] <ubitux> but that's less accurate
[22:30] <Compn> heheh
[22:30] <Compn> echo "hello //HACK world" :P
[22:30] <michaelni> if its just for lavfi i dont care so much but
[22:30] <ubitux> michaelni: the other solution i tested was to store the pointer to the metadata in the side data, but that's even crappy IMO
[22:31] <ubitux> (and it also needs to introduce a weird flag)
[22:31] <durandal_1707> please no hacks
[22:31] <michaelni> ptr to metadata im sidedata now sounds like a really really bad idea
[22:31] <ubitux> durandal_1707: i don't see any proper solution for this problem
[22:31] <michaelni> what about storing the metadata itself in sidedata ?
[22:31] <ubitux> michaelni: i meant an allocated data with the pointer written in it, not abusing the pointer
[22:32] <michaelni> consider someone (un)intentionally might stream copy lavfi into some container and then read it again
[22:32] <michaelni> a pointer in side data would not make sense after that
[22:33] <michaelni> priv would be lost (that may be ok or not)
[22:33] <ubitux> i don't follow the stream copy thing
[22:34] <michaelni> if you store AVPackets with a muxer side data will be stored too
[22:34] <michaelni> .priv will not
[22:34] <michaelni> new funny flags also likely will not
[22:35] <michaelni> so a question is what we want to happen in this case
[22:35] <ubitux> note that the priv is just pointing to a locally allocated metadata (in the lavd/lavfi device) and will be automatically deteletd from there
[22:35] <ubitux> its existence is limited to one AVPacket scope
[22:35] <michaelni> so av_dup_packet() will crash later ?
[22:35] <ubitux> when you demux another packet, the old metadata is destroyed
[22:36] <ubitux> let me check
[22:36] <michaelni> this sounds like not only a hack not actually not working at all :)
[22:37] <ubitux> av_dup_packet doesn't seem to care about the priv pointer
[22:37] <michaelni> well either it looses it (=NULL afterwards) or it preserves the pointer
[22:37] <ubitux> looks like it will loose it
[22:38] <ubitux> which doesn't really matter (from a leakage or crash point of view)
[22:38] <ubitux> afaict
[22:38] <durandal_1707> i dont see point in abusing metadata and using tags for this, just add another struct
[22:38] <michaelni> so lavfi will not work if an application callas dup_packet
[22:38] <ubitux> it's not that it won't work, it's just that the metadata would be lost if you don't copy it
[22:39] <michaelni> yes
[22:39] <nevcairiel> what does lavfi have to do with packets, doesnt is use decoded data? :d
[22:39] <ubitux> michaelni: do you see a better solution?
[22:39] <ubitux> durandal_1707: can you be more specific?
[22:40] <durandal_1707> ubitux: write new API to handle such stuff
[22:40] <michaelni> ubitux, what about putting the metadata in side data itself ?
[22:40] <ubitux> michaelni: right, storing key\0value\0 per metadata?
[22:40] <michaelni> yes
[22:40] <ubitux> iirc it was causing problems for mem leak
[22:41] <michaelni> side data will also be copied correctly in dup_packet
[22:41] <ubitux> like you needed to add av_free in the frame destruct callback but i think it was a problem if the frame->metadata was a pointer to a metadata somewhere else
[22:41] <ubitux> (and not a dup like in this case)
[22:42] <michaelni> also such side data could be used by a demuxer returning per frame metadata
[22:42] <ubitux> durandal_1707: that's vague, please be more specific
[22:43] <ubitux> michaelni: don't you think it's problematic to arbitrary dict free in the frame destruct callback the AVFrame->metadata ?
[22:43] <ubitux> since AVFrame->metadata can be pointing to a shared dictionary
[22:43] <ubitux> iirc that was the main issue i had with that solution
[22:44] <michaelni> i dont think i fully understand the problem but shared dictionaries sound like a fragile thing
[22:45] <durandal_1707> ubitux: do not use AVFrame.metadata
[22:46] <ohsix> you're repeating yourself now
[22:46] <ohsix> i don't think that's what he meant
[22:46] <ubitux> ohsix: i didn't understood it as is :p
[22:46] <ubitux> durandal_1707: right ok but well..
[22:46] <ubitux> what are you proposing instead?
[22:47] <durandal_1707> i cant tell you what is right thing to do, but i know what is not right thing
[22:47] <ubitux> from a user PoV, using the AVFrame->metadata is pretty nice
[22:48] <ubitux> michaelni: i was thinking of lavc/tiff.c, where the internal context has an AVFrame->metadata stored & destroyed regularly
[22:49] <ubitux> and i was wondering if it wouldn't cause problem to have the output AVFrame->metadata destroyed outside this codec
[22:49] <ubitux> which will be required if we construct a new AVDictionary in the AVFrame in case of meta in side data
[22:49] <durandal_1707> ubitux: i you like AVDictionary so much (I really see no point in that) add another AVDictionary to AVFrame
[22:50] <ubitux> sure, we can do that
[22:50] <ubitux> along with key/value in side data
[22:50] <ubitux> would you guys prefer that?
[22:51] <michaelni> ubitux, why do you want to destroy it outside the codec ?
[22:51] <durandal_1707> but how that will work in future? would it be better/faster than vapoursynth?
[22:51] <ubitux> michaelni: the side_data to avframe->metadata will need to be constructed outside any codec
[22:51] <ubitux> so it will be needed to destroy it in the destruct avframe function
[22:52] <michaelni> now i dont understand you
[22:52] <ubitux> anyway, we can indeed add a AVFrame->filters_metadata and use the AVPacket->side_data with key\0value\0
[22:52] <ubitux> michaelni: ok just a sec, will quote code
[22:53] <ubitux> durandal_1707: i guess optimizing AVDictionnary would make sense :)
[22:53] <michaelni> lavfi device would generate avpackets with side data but this would not go to tiff
[22:53] <michaelni> because lavfi device returns no tiff i guess but raw
[22:53] <durandal_1707> ubitux: i doubt that have any future
[22:54] <ubitux> michaelni: that's right, but when you decode the (raw) video/audio, you'll need to construct an AVDictionary from the side data
[22:54] <ubitux> when would you destroy it?
[22:54] <michaelni> same as other AVFrame fields
[22:55] <ohsix> it's about the lifecycle of something that isn't strictly frame data, but needs to be accessed with a frame, right?
[22:55] <ubitux> avcodec_free_frame()? or otherwise the dict would need to be the avctx, right?
[22:55] <ubitux> and the problem is in case we would want to destroy it in avcodec_free_frame()
[22:56] <ubitux> (because the dict would be destroyed there and not in the tiff for example)
[22:56] <ubitux> ohsix: kind of yes
[22:57] <ubitux> durandal_1707: you doubt about what exactly?
[22:57] <michaelni> AVFrame fields are never destroyed in avcodec_free_frame()
[22:57] <ubitux> aren't extended data destroyed there
[22:57] <ubitux> ?
[22:57] <michaelni> yes, thats the single exception
[22:58] <michaelni> and its a bad idea
[22:58] <ubitux> i agree
[22:58] <ubitux> that's why i wanted to avoid putting the metadata free there
[22:58] <ubitux> but where would i put it then?
[22:58] <ubitux> since it can't be stored in any specific decoder
[22:59] <michaelni> where the decoder frees/reuses other fields
[22:59] <ubitux> we are dealing with raw audio & video
[22:59] <ubitux> (and it could be another decoder?)
[23:00] <ubitux> it is likely the dictionnary construction will remain in the common a/v decode functions
[23:00] <michaelni> i guess other decoders could contain metadata in their bitstream
[23:00] <ubitux> then the metadata will need to be stored somewhere in the avctx or something
[23:00] <michaelni> could be in the private context of the raw decoder
[23:01] <ubitux> is there a raw audio decoder?
[23:02] Action: michaelni thinks: libavcodec/pcm.c
[23:02] <ubitux> will need to introduce a new context there mmh okay..
[23:04] <michaelni> you could use AVCodecInternal too if that simpler
[23:05] <ubitux> ok so we add a local avdict metadata in raw a/v decoders, and we use them exactly like the tiff decoder except that we will put a new constructed dict each time from the metadata side data
[23:05] <ubitux> idk the AVCodecInternal, 'will look
[23:05] <ubitux> won't that be a bit heavy processing btw?
[23:05] <ubitux> not that's a real issue yet but..
[23:06] <michaelni> the build of AVDict ?
[23:07] <michaelni> per frame
[23:07] <ubitux> yes
[23:07] <ubitux> re-allocating each entry and stuff
[23:07] <ubitux> as well as constructing the side data from the buffer ref av dict
[23:08] <michaelni> its ugly but iam not sure what alternative there would be
[23:08] <michaelni> no copy would mean reference counting and mutexes probably
[23:09] <michaelni> thats except that AVDict itself is poorly implemented
[23:09] <ubitux> i'm ok with that, i'm just wondering how it would be possible to improve it later
[23:10] <ubitux> btw, another related question
[23:10] <ubitux> should we introduce a new dedicated metadata dict in AVFrame?
[23:10] <ubitux> like filters_metadata or something
[23:10] <ubitux> so we don't need the key prefix thing
[23:11] <michaelni> this is a good question
[23:12] <michaelni> in what use cases would we want to treat them differently, in what the same ?
[23:13] <michaelni> i might want to run a advertisement detect filter and store the found positions with the frames in a file for example
[23:13] <michaelni> like other metadata
[23:14] <ubitux> the only benefits are avoiding naming conflicts with other metadata, as well as an arbritrary "hacky" prefix to workaround that first problem
[23:14] <ubitux> i don't see much more
[23:16] <michaelni> btw that reminds me that the nut spec says something about X- prefixes for not in the spec things
[23:16] <michaelni> we forgot following thatg ...
[23:16] <michaelni> noone noticed and iam not sure it would really be better with half the fields having X- prefixes
[23:18] <ohsix> metadata mime types :>
[23:19] <michaelni> full address and phone number of the person adding the tag, so you can ask what he meant ;)
[23:24] <burek> j-b, do you know maybe what is the analogy in vlc for ffmpeg's -analyzeduration ? (i have a h264 stream which has a gop of 20-30 seconds so it never gets recognized correctly)
[00:00] --- Fri Oct 12 2012