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

burek burek021 at gmail.com
Thu Oct 18 02:05:03 CEST 2012


[00:11] <cone-412> ffmpeg.git 03Michael Niedermayer 076d55a40b0080: mov: print warning if ff_get_wav_header() fails * 03http://tinyurl.com/9vq6jdd03
[00:11] <cone-412> ffmpeg.git 03Michael Niedermayer 07cb65b32c97b0: mp3enc: remove unneeded null ptr check * 03http://tinyurl.com/8lgblqe03
[00:11] <cone-412> ffmpeg.git 03Michael Niedermayer 07a30972609ca3: yuvPlanartoyuy2_c: fix sign extension * 03http://tinyurl.com/8mblbvd03
[00:11] <cone-412> ffmpeg.git 03Michael Niedermayer 07a07e9d72a1d9: yuvPlanartouyvy_c: fix sign extension * 03http://tinyurl.com/9zhvwcu03
[00:11] <cone-412> ffmpeg.git 03Michael Niedermayer 073e0b29ccd075: ffmpeg: Make video filter graph reinit user selectable * 03http://tinyurl.com/9grcj2w03
[00:11] <cone-412> ffmpeg.git 03Michael Niedermayer 076cbb8a450f16: libavfilter/buffersrc: Do not fail hard on changes of input parameters. * 03http://tinyurl.com/8qmelxq03
[00:11] <cone-412> ffmpeg.git 03Michael Niedermayer 075d2b8850746b: lavfi: limit matching w/h/fmt asserts to non scale filters * 03http://tinyurl.com/98mjdlp03
[00:32] <michaelni> saste, your patch breaks compex filters
[00:32] <michaelni> example: ffmpeg -i matrixbench_mpeg2.mpg -i tests/lena.pnm -filter_complex 'overlay=10:main_h-overlay_h-10' out.avi
[00:32] <saste> michaelni, which patch?
[00:33] <michaelni> "lavfi/scale: accept named option, make parsing more robus"
[00:33] <saste> uhm, how's that?
[00:33] <ubitux> auto insert maybe?
[00:34] <michaelni> dont ask me iam just testing as i had a bad feeling 
[00:34] <saste> No option name near '(null)'
[00:34] <saste> ok got it
[00:35] <saste> well that is a pre-existing bug, but sure it must be solved
[00:35] <saste> we don't have FATE test for -filter_complex?
[00:36] <saste> i run make fate with my patchset and didn't catch the issue
[00:37] <saste> goodnight people
[00:37] <michaelni> n8 saste 
[00:37] <Daemon404> [18:37] <@Daemon404> how do i make a build-only fate instance?
[00:37] <Daemon404> same question here
[00:39] <michaelni> Daemon404, try makeopts="FATE="
[00:39] <Daemon404> "try" ?
[00:40] <michaelni> sorry wrong escaping, try 'makeopts="FATE="'
[00:40] <michaelni> :)
[00:41] <ubitux> still using that trick?
[00:42] <ubitux> is that really the official way?
[00:42] <ubitux> i mean, that's the way i workaround the problem but.. :D
[00:42] <Daemon404> 'official
[00:42] <Daemon404> well once the tilera patch is merged
[00:42] <Daemon404> ill add my tilera build to ffmpeg's fate too
[00:42] <ubitux> Daemon404: you have some config examples on lucy.pkh.me btw
[00:42] <ubitux> http://lucy.pkh.me/fate-configs/
[00:45] <michaelni> i never tried to find another way because it works ...
[00:45] <ubitux> :D
[00:46] <ubitux> i think i saw a build_only patch somewhere on libav
[00:46] <ubitux> so even if there is another solution, it's likely to be hacky as well
[01:25] <ubitux> michaelni: examples make works for me: http://pastie.org/5070391
[01:28] <ubitux> michaelni: maybe a shared build?
[01:45] <michaelni> #define CONFIG_SHARED 0
[01:47] <michaelni> theres a "-L/usr/local/lib" in there, if i remove it it links
[01:48] <michaelni> cc   muxing.o  -pthread -Lpc-uninstalled/../../../libavdevice -L/usr/local/lib -Lpc-uninstalled/../../../libavfilter ...
[01:51] <ubitux> is it better if you replace:
[01:52] <ubitux> CFLAGS := $(shell pkg-config --cflags $(FFMPEG_LIBS)) $(CFLAGS)
[01:52] <ubitux> LDLIBS := $(shell pkg-config --libs $(FFMPEG_LIBS)) $(LDLIBS)
[01:52] <ubitux> with:
[01:52] <ubitux> CFLAGS += $(shell pkg-config --cflags $(FFMPEG_LIBS))
[01:52] <ubitux> LDLIBS += $(shell pkg-config --libs $(FFMPEG_LIBS))
[01:52] <ubitux> ?
[01:53] <michaelni> no, same problem
[01:53] <ubitux> ok :(
[01:54] <ubitux> well i have to wake up ~5h so time for me to sleep..
[01:54] <ubitux> 'night
[01:56] <michaelni> ubitux, good night
[02:45] <cone-412> ffmpeg.git 03Michael Niedermayer 077b8fd298161d: examples/muxing: fix video pts * 03http://tinyurl.com/9lu7wzx03
[02:54] <cone-412> ffmpeg.git 03Michael Niedermayer 07adbb75dbd8ea: mov: fix time types related to mov_metadata_creation_time * 03http://tinyurl.com/8t2524303
[03:37] <cone-412> ffmpeg.git 03Michael Niedermayer 074e2e3d943ef0: ffv1: fix packed rgb with 1.3 * 03http://tinyurl.com/9h7xxos03
[07:46] <cone-343> ffmpeg.git 03Clément BSsch 07711ffb84df29: lavf/swfdec: support DefineBitsLossless{,2} tag. * 03http://tinyurl.com/93kes8303
[10:05] <ubitux> is the aac ssr profile in use?
[10:05] <ubitux> i mean, is there some encoders making use of it, and at least a few decoders supporting it?
[10:51] <nevcairiel> i dont think i ever saw a file
[10:51] <nevcairiel> and usually people give me the weirdest sample files
[10:53] <ubitux> ok :)
[11:17] <durandal_1707> how long in minutes is 2gb wav file (44100hz, 16bps, 2channels) ?
[11:19] <cptspiff> 2*1024*1024*1024/(44100*2*2)
[11:19] <nevcairiel> 203 minutes or so
[11:28] <merbanan> ubitux: I saw one ssr file
[11:28] <ubitux> and then you woke up ?
[11:28] <ubitux> according to a comment on top of the aacdec, there was a gsoc to support it
[11:29] <ubitux> i guess it never reached the review process?
[11:29] <merbanan> no diego wanted the ssr stuff from the gsoc resurrected
[11:29] <merbanan> then I woke up
[11:29] <ubitux> :D
[11:30] <merbanan> no one uses it though
[11:30] <merbanan> faad supports it iirc
[11:30] <durandal_1707> i cant generate silence with 2 chan with aevalsrc
[11:31] <ubitux> aevalsrc=0 ... -ac ? :P
[11:32] <durandal_1707> i get mono
[11:32] <durandal_1707> and if i specify layout i get error
[11:32] <ubitux> aevalsrc=0:0 ?
[11:33] <durandal_1707> thanks
[12:02] <cone-343> ffmpeg.git 03Michael Niedermayer 07364c60bf64a2: sws-test: parse command line args before initing contexts * 03http://tinyurl.com/cdmbgcv03
[13:59] <cone-343> ffmpeg.git 03Paul B Mahol 07d6ea59b8608d: tta: datalen is unsigned integer per reference library * 03http://tinyurl.com/cvjzkyg03
[14:13] <cone-343> ffmpeg.git 03Paul B Mahol 071ade37ae9c2b: lavc/tta: use meaningful error codes * 03http://tinyurl.com/cwts6hp03
[14:21] <cone-343> ffmpeg.git 03Mans Rullgard 073b20eb25e7b9: avserver: move avserver-specific code from ffmdec.c to avserver.c * 03http://tinyurl.com/cgnopxh03
[14:21] <cone-343> ffmpeg.git 03Luca Barbato 0721de6ba5c12f: nut: export codec_tag provided by rawvideo * 03http://tinyurl.com/cd9zvdl03
[14:21] <cone-343> ffmpeg.git 03Mans Rullgard 071fbaabefc4bb: network: #include stdint.h in network.h * 03http://tinyurl.com/c6x2g4d03
[14:21] <cone-343> ffmpeg.git 03Diego Biurrun 07c0a6cac2920e: fate: Add rangecoder test * 03http://tinyurl.com/clec3rs03
[14:21] <cone-343> ffmpeg.git 03Luca Barbato 079a978b334b9b: ffv1: K&R formatting cosmetics * 03http://tinyurl.com/c54ppwe03
[14:21] <cone-343> ffmpeg.git 03Christian Schmidt 074a7429203a39: pcm-mpeg: correct bitrate calculation * 03http://tinyurl.com/c2y73uu03
[14:21] <cone-343> ffmpeg.git 03Rafaël Carré 07a25d912dca9c: avcodec_encode_audio(): fix invalid free * 03http://tinyurl.com/cak54ek03
[14:21] <cone-343> ffmpeg.git 03Michael Niedermayer 07d6e87190fd07: Merge commit 'a25d912dca9cd553440167e0476c47581359c0fc' * 03http://tinyurl.com/brazqj603
[14:34] <cone-343> ffmpeg.git 03Anton Khirnov 07a119c64e38bd: avconv: fix disabling auto mappings with -map_metadata * 03http://tinyurl.com/cavmbvw03
[14:34] <cone-343> ffmpeg.git 03Victor Vasiliev 0771e92414bfd7: lavf: move RIFF INFO tag writing from avienc to riff * 03http://tinyurl.com/c4vkeu603
[14:34] <cone-343> ffmpeg.git 03Michael Niedermayer 07fadfbb354b30: Merge commit '71e92414bfd79e56ea6fff174a665ff7b9b86e68' * 03http://tinyurl.com/bt5kxc803
[14:59] <cone-343> ffmpeg.git 03Victor Vasiliev 070bca0283ccde: riff: do not write empty INFO tags * 03http://tinyurl.com/cvholko03
[14:59] <cone-343> ffmpeg.git 03Michael Niedermayer 07c079da507316: Merge commit '0bca0283ccded5e32da143a462168ad1988a58fd' * 03http://tinyurl.com/bo7umz503
[15:33] <cone-343> ffmpeg.git 03Victor Vasiliev 0758b619c8a226: wav muxer: write metadata * 03http://tinyurl.com/cxf7dsa03
[15:33] <cone-343> ffmpeg.git 03Michael Niedermayer 07d8cfa9835804: Merge commit '58b619c8a226cc4564ad5af291bc99a04f89ee56' * 03http://tinyurl.com/bsok2xw03
[15:40] <burek> one stupid question.. what does -flags +global_header apply to? (streams or containers)
[15:47] <cone-343> ffmpeg.git 03Anton Khirnov 0731c54711cc3f: lavf: split wav muxer and demuxer into separate files. * 03http://tinyurl.com/dyl6zz803
[15:47] <cone-343> ffmpeg.git 03Michael Niedermayer 07df5e089da95b: Merge commit '31c54711cc3f1484af101d629bbb805820d37ad1' * 03http://tinyurl.com/c3bffys03
[15:51] <Tjoppen> wee - I got an IFF file at work
[15:51] <Tjoppen> it's 1985 again
[15:52] <durandal_1707> why you get such files?
[15:52] <cone-343> ffmpeg.git 03Anton Khirnov 0779922d7237ab: wav: do not fail on empty INFO tags * 03http://tinyurl.com/crto9gw03
[15:52] <cone-343> ffmpeg.git 03Michael Niedermayer 07940ee636301a: Merge commit '79922d7237aba2b8c6abbd2e06a0c08e4f498ad4' * 03http://tinyurl.com/cotnawj03
[15:52] <Tjoppen> I have no idea. but the client seems to want support for them
[15:53] <Tjoppen> might be time to do my old "split wav into wavenc/dec, then share code with the avi demuxer" idea
[15:53] <Tjoppen> in which case an iff demuxer could share code too
[15:58] Action: durandal_1707 notices conflict list is becoming bigger and bigger
[16:00] <cone-343> ffmpeg.git 03Anton Khirnov 07a43283b6f4cf: wavdec: check size before reading the data, not after. * 03http://tinyurl.com/d99cgce03
[16:00] <cone-343> ffmpeg.git 03Derek Buitenhuis 07c75848cd4c09: configure: Add support for Tilera processors * 03http://tinyurl.com/bn6h47h03
[16:00] <cone-343> ffmpeg.git 03Michael Niedermayer 07775d41b617f0: Merge remote-tracking branch 'qatar/master' * 03http://tinyurl.com/d4przjb03
[16:00] <ubitux> does anyone have any idea of what particular case Nicolas is talking about in the lavfi metadata support?
[16:10] <cone-343> ffmpeg.git 03Paul B Mahol 079b762e2cba16: idcinvideo: remove redundant "  id CIN Video: " from av_log() * 03http://tinyurl.com/cj7b9p203
[17:11] <ubitux> saste: http://fate.ffmpeg.org/log.cgi?time=20121017114713&log=configure&slot=x86_64-archlinux-gcc-enableshared
[17:11] <ubitux> didn't you send some patches for this?
[17:12] <ubitux> mmh or maybe it was carl
[17:13] <Daemon404> it was carl
[17:13] <Daemon404> and it was pushed
[17:13] <ubitux> "just"?
[17:13] <Daemon404> no
[17:13] <Daemon404> and the patch was to make it fail when it wasnt foudn
[17:14] <ubitux> why did i read "just"....
[17:14] <Daemon404> instead of silently contining
[17:14] <ubitux> ok
[17:14] <ubitux> i'll mail him, thanks :)
[17:14] <Daemon404> maybe you should check why it fails first :P
[17:14] <ubitux> yes
[17:14] <ubitux> though, it's a syntax error :p
[17:15] <Daemon404> lol
[17:53] <durandal_1707> michaelni: that dca merge looks fishy
[17:54] <cone-343> ffmpeg.git 03Michael Niedermayer 07a4fe661157b2: mov_probe: fix integer overflows * 03http://tinyurl.com/blobmm603
[18:00] <ubitux> eh all my typo are spotted
[18:16] <Daemon404> tilegx and tilepro fate builds added
[19:55] <durandal_1707> what is nice way to look code changes of actual merges?
[19:55] <Daemon404> git cli or web? none
[19:56] <Daemon404> there might be a decent way in one of git's many guis
[19:56] <Daemon404> (probably mac based...)
[19:56] <durandal_1707> cli only
[19:56] <Daemon404> there's only the ugly way
[19:56] <Daemon404> which is the obvious one
[19:57] <durandal_1707> git is just for linux kernel maintainer
[19:58] <durandal_1707> hmm, so looks like i need to setup this web gui thing
[19:58] <ohsix> git instaweb ?
[19:59] <ohsix> there's gitk too
[19:59] <ohsix> but if you want to set something up, cgit
[19:59] <ohsix> gitk isn't bad
[19:59] <Daemon404> ohsix, none of those let you see merge stuff that easily
[19:59] <Daemon404> gitweb's is horrible
[20:00] <ohsix> wah, i look at that all the time on gitweb
[20:00] <ohsix> you mean with extra context, not just the changes?
[20:00] <durandal_1707> real changes to files no virtual crap
[20:00] <Daemon404> merge conflicts, any extra content in the merge commits themselves
[20:01] <Daemon404> and how it applies to THIS tree
[20:01] <Daemon404> not the tree you merged it from
[20:01] <ohsix> so you mean between branches
[20:01] <Daemon404> branches is too specific
[20:01] <Daemon404> just trees
[20:02] <ohsix> trees have branches, one or more, practically speaking it's always between branches
[20:02] <Daemon404> i suppose
[20:02] <ohsix> a tree has all branches, comparing all branches to another set of all branches doesn't make much sense
[20:03] <Daemon404> but thats not the definition of tree i use
[20:03] <ohsix> http://git.alsa-project.org/?p=alsa-lib.git;a=shortlog;h=HEAD commitdiff is what i use all the time, and it's good enough; interested to hear where it fails
[20:03] <Daemon404> ohsix, for example
[20:03] <Daemon404> micael merges the latest batch of libav changes into ffmpeg
[20:03] <Daemon404> via git merge
[20:03] <Daemon404> merge conflicts etc
[20:04] <Daemon404> or maybe it applies  slightly differently to teh ffmpeg tree
[20:04] <Daemon404> but ig you view teh diffs for the commits themselevs
[20:04] <Daemon404> theyre always against libav's, nto ffmpeg's
[20:04] <Daemon404> and the merge commit itself is very confusing to look at
[20:04] <Daemon404> if at all even relevant
[20:04] <ohsix> ah, can't help the confusion there, i think; because when you do a merge, they _are_ against libav's
[20:05] <Daemon404> exactly
[20:05] <Daemon404> but it's really annoying to track merged things
[20:05] <ohsix> you would have to do all the patches individually for that to not be
[20:05] <Daemon404> there's no good way to view teh dleta as it was applied to our tree
[20:05] <Daemon404> and there really should be
[20:05] <Daemon404> since thats what it ends up as
[20:05] <ohsix> ok, i took it to mean the web/gui interfaces were bad, not that merging was confusing
[20:06] <Daemon404> no webgui/gui displays it well
[20:06] <Daemon404> :P
[20:06] <Daemon404> afaik
[20:06] <ohsix> you put them on a different branch and then compare them, merging only when needed
[20:06] <ohsix> right, but the web ui isn't what's confusing you, the merge is
[20:06] <Daemon404> no i mean its way of displaying the merge
[20:06] <Daemon404> is poor
[20:06] <Daemon404> double +
[20:06] <Daemon404> like
[20:06] <Daemon404>  +
[20:06] <Daemon404> ++ a
[20:06] <Daemon404> -+ a
[20:06] <Daemon404> its a shitty way to visualize it
[20:07] <ohsix> maybe i've gotten used to it, or it never really mattered; i happen to agree with you tho i couldn't think of a better or less interesting way to do it
[20:07] <Daemon404> ;p
[20:08] <ohsix> interesting in the "may you live in interesting times" sense, not wow this is amazing sense
[20:08] <durandal_1707> i use log -m but it forks only for the first merge....
[20:10] <ohsix> hm, i'm not sure i wouldn't just apply the merge to another branch and compare them if i was in that situation often, isn't the patch posted before merges are done? or is this a situation where you land in the middle of a merge and you need to figure out what happened
[20:11] <ohsix> i'm presuming you want to review a merge, not like, doing a bisect then having to untangle a merge
[20:14] <durandal_1707> log -m is doing job well except i need to manually pick each merge
[20:15] <ohsix> hm, well, i might be able to think of some other useful tool if the use-case is different
[20:17] <Daemon404> bleh
[20:17] <Daemon404> *** drop!
[20:17] <Daemon404> ^ what causes this
[20:17] <ohsix> falling into the middle of a series of patches is usually confusing, merge or not; so i hadn't considered it as a source of extra confusion :p thus only thinking about reviews
[20:18] <ohsix> git grep? probably a frame with a bad timestamp or something
[20:18] <ohsix> (or an actual, genuine missed frame)
[20:19] <Daemon404> yes im looking
[20:20] <Daemon404> maybe ill send a patch for a less shitty message
[20:20] <Daemon404> by default it just drops thousands of frames for this clip\
[20:20] <Daemon404> and the "verbose" long is "*** drop!"
[20:20] <Daemon404> s/long/log/
[20:21] <ohsix> it eventually drops the "your computer may be too slow!" or maybe i'm thinking of mplayer
[20:21] <Daemon404> no
[20:21] <Daemon404> nb_frames = FFMIN(nb_frames, ost->max_frames - ost->frame_number);
[20:21] <Daemon404> if this is 0
[20:21] <Daemon404> it drops the frame
[20:21] <ohsix> ah something else then
[20:21] <ohsix> ok, gotta run; bbl
[20:21] <Daemon404> of course there are no comments.
[20:25] <Daemon404> and there is no indication what max_frames is at all
[20:25] <Daemon404> :|
[20:26] Action: durandal_1707 yes : git lgs --min-parents=1 libavcodec/dcadec.c
[20:26] <Daemon404> looks like INT64_MAX...
[20:27] Action: Daemon404 guess he asks michaelni wtf is going on
[20:35] <cone-343> ffmpeg.git 03Michael Niedermayer 07fd9e88fe6018: libavfilter/lavfutils: remove useless NULL check on codec context * 03http://tinyurl.com/cwlzux403
[20:36] <cone-343> ffmpeg.git 03Michael Niedermayer 07657998b5ee46: libavfilter/lavfutils: remove useless NULL check on format context * 03http://tinyurl.com/d4xmvd203
[20:36] <cone-343> ffmpeg.git 03Michael Niedermayer 077fd65104f489: ffm_seek: fix division by zero * 03http://tinyurl.com/c7ez86k03
[20:36] <cone-343> ffmpeg.git 03Michael Niedermayer 07378a5b9c5f1a: ffm_write_write_index: check lseek() return code * 03http://tinyurl.com/c8v27fa03
[20:36] <cone-343> ffmpeg.git 03Michael Niedermayer 0771bc8c95d7ca: ffm_read_write_index: check lseek return code * 03http://tinyurl.com/d9chjb403
[20:50] <ohsix> Daemon404: is it going to be reference frames or something? cuz there'd be no need to drop them unless something was exceeded, or they got too old
[20:51] <Daemon404> its not clear whats going on
[20:51] <ohsix> right, but there are only a handful of circumstances where frames would be dropped
[20:51] <ohsix> small enough to investigate each one, anyways
[20:51] <Daemon404> [14:33] <@elenril> in ffmpeg it's dropping frames when 1) two frames have the same timestamps or 2) you want cfr
[20:51] <Daemon404> [14:44] <@Daemon404> elenril, that cant be accurate...
[20:51] <Daemon404> [14:44] <@Daemon404> this is neitehr vfr input
[20:51] <Daemon404> [14:44] <@Daemon404> nor are there same timestamps
[20:51] <Daemon404> [14:45] <@elenril> Daemon404: my crystal ball is out of ord
[20:51] <Daemon404> [...]
[20:52] <Daemon404> [14:35] <@Daemon404> avconv's behavior is SO much better
[20:52] <Daemon404> [14:36] <@Daemon404> Press ctrl-c to stop encoding
[20:52] <Daemon404> [14:36] <@Daemon404> ^C^C^C^C^C  1 fps=  0 q=0.0 size=      -0kB time=0.01 bitrate= -17.6kbits/s    
[20:52] <Daemon404> [14:36] <@Daemon404> and starts using ALL of my memory
[20:52] <ohsix> ah, interesting
[20:53] <ohsix> i'm not in a situation where i can read the code, so i won't distract you further
[20:54] <durandal_1707> perhaps it keeps buffering stuff because timestamps are nonsense 
[20:54] <Daemon404> the timestamps are fine
[20:54] <Daemon404> i checked them maually
[20:54] <durandal_1707> what container?
[20:54] <Daemon404> mp4
[20:57] <durandal_1707> get sample so i can reproduce and play little with it?
[20:57] <durandal_1707> *got
[21:00] <Daemon404> i dont think i can share this sample
[21:00] <Daemon404> work-related
[21:05] <durandal_1707> how many streams it have?
[21:06] <cone-343> ffmpeg.git 03Michael Niedermayer 07a0e0e1e19254: ffmdec: fix hypothetical overflows * 03http://tinyurl.com/cw3cn8r03
[21:06] <cone-343> ffmpeg.git 03Michael Niedermayer 07f03c0f6afcb1: ffmdec: check av_new_packet() return value * 03http://tinyurl.com/bsltcsk03
[21:06] <cone-343> ffmpeg.git 03Michael Niedermayer 07d185c8a79bbd: tiff: run strlen() after setting the pointer * 03http://tinyurl.com/bqv9wzm03
[21:08] <ubitux> Daemon404: did you check them with -debug_ts?
[21:13] <Daemon404> ubitux, with ffms2
[21:13] <Daemon404> but same shared lib
[21:14] <Daemon404> -debug_ts output is ... dense... to say the least
[21:14] <ubitux> :(
[21:26] <durandal_1707> so riff info chunks are not 2byte aligned?
[21:33] <ubitux> saste, michaelni (and others): i'm going to rename AV_PKT_DATA_METADATA to FF_PKT_DATA_METADATA in the next version of the lavfi metadata patch if you don't mind
[21:33] <cone-343> ffmpeg.git 03Nicolas George 07709628aa71f2: lavfi/avf_concat: fix invalid exclusive test. * 03http://tinyurl.com/dywb5h603
[21:33] <ubitux> i'm actually pretty uncomfortable with what is libav going to do
[21:33] <durandal_1707> name will not help
[21:33] <ubitux> and i'm afraid they will introduce a AV_PKT_DATA_METADATA as well at some point
[21:33] <Daemon404> i thought FF_ was for internal only
[21:34] <ubitux> Daemon404: yes, but there is no point (at the moment) to make this side data available for users
[21:34] <durandal_1707> ubitux: AV_PKT_DATA_METADATA=666
[21:34] <Daemon404> as long as FF_* isnt public
[21:34] <ubitux> durandal_1707: that doesn't solve the issue, it's already the case
[21:34] <ubitux> durandal_1707: the problem is if they use the same name
[21:35] <durandal_1707> then put our initials in name
[21:35] <ubitux> i was just proposing to use FF so it's private and it doesn't matter
[21:36] <llogan> AV_PKT_DATA_METADATA_BETTEREST
[21:36] <ubitux> and it can be made public without much effort
[21:36] <ubitux> llogan: AV_PKT_DATA_METADATA_FFMPEGGOTITFIRST
[21:36] <Daemon404> if you make something with a FF_ prefix public
[21:36] <Daemon404> that is wrong
[21:36] <Daemon404> and inconsistent
[21:37] <durandal_1707> just FFMPEG
[21:37] <durandal_1707> is enough
[21:37] <ubitux> so you would prefer a public AV_PKT_DATA_METADATA_FFMPEG?
[21:37] <Daemon404> and thats just inconsistent with the entirety of thepublic api
[21:38] <durandal_1707> AV_PKT_DATA_METADATA_LOL
[21:38] <ubitux> Daemon404: you should worry, as a user, about a FF_PKT_DATAxxx defined somewhere imo
[21:38] <ubitux> durandal_1707: AV_PKT_DATA_METADATA_COME_ON_LIBAV_BREAK_API_IF_YOU_CAN
[21:39] <ubitux> anyway, what are your suggestions?
[21:39] <durandal_1707> add _EX
[21:39] <ubitux> AV_PKT_DATA_STRINGS_METADATA maybe?
[21:40] <durandal_1707> so libav introducen jet another regression into ffmpeg
[21:41] <Daemon404> theyve done nothing yet
[21:41] <Daemon404> ubitux is beign preemptive
[21:42] <durandal_1707> Daemon404: talking about merges - recent one being riff info thing
[21:43] <ubitux> Daemon404: yep, i'm just cautious on this one, especially after elenril told me today :D
[21:43] <ubitux> +what
[21:45] <saste> what's the problem with anonymous typedefs?
[21:45] <saste> *anonimous typdedeffed structs?
[21:45] <durandal_1707> personal preference
[21:46] <ubitux> it seemed to have caused "issues" with some public ones in header
[21:46] <ubitux> otherwise it just seems like a new diego-ing thing as durandal_1707 says
[21:46] <saste> anonymous typedeffed structs considered harmful?
[21:47] <saste> what about removing gotos then?
[21:47] <burek> [20:25:33] <wlan3> And what are the differences, not counting need to modify my scripts?
[21:47] <burek> [20:25:48] <relaxed> nothing really, they operate the same
[21:47] <burek> ?
[21:47] <saste> funny project for a boring winter afternoon
[21:47] <burek> why tell something like this and cofuse people even more
[21:47] <burek> confuse*
[21:48] <llogan> burek: ask relaxed in -user.
[21:48] <durandal_1707> burek: that is libav agent
[21:48] <burek> yes but still
[21:48] <burek> it's inappropriate to answer like that
[21:48] <llogan> it's all about perspective.
[21:49] <llogan> (not that i'm agreeing with that perspective).
[21:49] <burek> well not quite
[21:49] <burek> the reaction that has caused was [20:34:12] <wlan3> I'll have to change every reference of ffmpeg in the scripts. Easy but annoying.
[21:49] <burek> and tomorrow he'll come again asking for help saying some option is not working in avconv
[21:50] <cone-343> ffmpeg.git 03Stefano Sabatini 071f7962625cf3: examples/muxing: remove video_outbuf unused and useless code * 03http://tinyurl.com/d3598js03
[21:50] <cone-343> ffmpeg.git 03Stefano Sabatini 075ca298df2df8: examples/muxing: remove misleading comment about pending API change * 03http://tinyurl.com/bnnn2kf03
[21:50] <cone-343> ffmpeg.git 03Stefano Sabatini 07d6196d942191: examples/muxing: fix bogus setting of st->id * 03http://tinyurl.com/cq9tmsn03
[21:50] <cone-343> ffmpeg.git 03Stefano Sabatini 07eda0a52bf161: examples/muxing: check on frame * 03http://tinyurl.com/caxacx903
[21:50] <cone-343> ffmpeg.git 03Stefano Sabatini 07eebde404bc8c: examples/muxing: merge add_audio_stream() and add_video_stream() * 03http://tinyurl.com/d2o4dhc03
[21:50] <burek> if it was the same then there would be no fork at all
[21:50] <burek> .
[21:50] <llogan> burek: yes, it's the same old bullshit.
[21:53] <ubitux> saste: i need something faster than scene detection for my tests; i'm going to add some metadata in one of the black detection filter, which one is appropriate?
[21:53] <ubitux> (we have two of them iirc)
[21:54] <ubitux> blackframe & blackdetect
[21:54] <saste> ubitux, blackdetect is better
[21:54] <saste> blackframe is GPL, and has an inflexible syntax
[21:54] <ubitux> ok, thanks
[21:54] <saste> we should try to merge the remaining features to blackdetect and drop it
[21:56] Action: ubitux is stupidely laughing at the racist debug joke he added in his local tree in the blackdetect filter
[21:56] <saste> yes that filter is racist, that is colorist
[21:57] <saste> why a pink frame is better than a black one?
[21:57] <Daemon404> 4chan has a game with the same name as that filter
[21:57] <ubitux> haha
[21:57] <saste> colordetect would be a better filter (and less colorist)
[21:58] <Compn> you should just call it what its for
[21:58] <Compn> e.g. commercialdetect
[21:58] <saste> why such color discrimination?
[21:58] <saste> but a colordetect would be slower
[21:58] <Daemon404> Compn, thats a pretty shitty commercial detect
[21:58] <Daemon404> you need a logo mask too
[21:58] <ubitux> saste: i think it's overkill
[21:59] <Daemon404> and perhaps check channel changes and bitrate reductio
[21:59] <Daemon404> n
[21:59] <ubitux> saste: with vf compare it won't be needed anymore
[21:59] <ubitux> assuming we fix the code
[21:59] <ubitux> (aka making it work with a still image)
[21:59] <ubitux> so we can detect one frame in a stream
[21:59] <ubitux> black, white, pink, lena, etc
[22:00] <Daemon404> i assume this has a threshold?
[22:00] <ubitux> ask luca
[22:00] <Daemon404> right
[22:00] <Daemon404> it soudns really trivial
[22:00] <saste> i wonder how our psnr would compare to that
[22:00] <ubitux> do we have a psnr filter?
[22:00] <saste> no it was discussed on ML
[22:01] <saste> there were some optimization issues to be fixed
[22:01] <saste> it was never committed
[22:01] Action: ubitux is waiting for the filter to go in, fix the braindead N alloc & free per frame, make it work with still images, and rule the world
[22:02] <Daemon404> why dont you just tell luca
[22:02] <Daemon404> to fix it
[22:02] <ubitux> i did
[22:02] <ubitux> he will likely won't
[22:02] <Daemon404> grammar-sploded my head
[22:02] <ubitux> :D
[22:03] <ubitux> he will likely not do it
[22:10] <ubitux> meh the metadata don't reach the end of the graph
[22:10] <Daemon404> :D
[22:13] <saste> return -1 never seem to end...
[22:14] <Daemon404> -1 is very descriptive though
[22:14] <Daemon404> it tells me not to touch this part of the code
[22:14] <Daemon404> lest i endure pain
[22:15] <ubitux> saste: how is the buffer ref transmitted to the next filter in blackdetect?
[22:15] <ubitux> i mean, i add some meta to inlink->cur_buf, but that buffer is ignored afterward
[22:15] <saste> grep -R "return -1" (find -name '*.c') | wc -l => 3412
[22:16] <ubitux> so any idea how we can trick this?
[22:16] <saste> ubitux: can't say with no code
[22:16] <saste> my memory is overrated
[22:17] <saste> Daemon404, yeah permission denied to touch this code
[22:17] <ubitux> i think i missed something :p
[22:19] <ubitux> it seems to only work when i inject the metadata in the picref passed to start_frame()
[22:31] <ubitux> just curious
[22:31] <ubitux> do you guys feel like this metadata string in side data is a hack?
[22:33] <durandal_1707> sort of
[22:34] <ubitux> how so?
[22:34] <ubitux> (soon: batch normalization possible with a few lines of code!)
[22:35] <durandal_1707> the whole idea - it is not going to be used by any demuxer
[22:35] <ubitux> nicolas mentioned some
[22:35] <durandal_1707> ?
[22:36] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-devel/2012-October/132263.html
[22:36] <ubitux> * The v4l2 device uses the priv field to manage its DMA buffers, it could need to inject metadata if some device were able to report additional information, such as autofocus info or GPS position.
[22:37] <ubitux> also, i wonder if i couldn't use it for the timecode :)
[22:37] <ubitux> (when at format level, like most of the cases)
[22:37] <durandal_1707> what about waiting evils action?
[22:38] <ubitux> do you think those suggestions are not reasonable?
[22:46] <durandal_1707> i dunno what to think of it
[23:30] <cone-343> ffmpeg.git 03Michael Niedermayer 0735daf3ca8173: cmdutils: remove unneeded null check * 03http://tinyurl.com/chybjur03
[23:30] <cone-343> ffmpeg.git 03Alexis Ballier 07916352f28285: configure: do not quote arguments passed to filter{,_out} in check_ld. * 03http://tinyurl.com/d3zyabt03
[23:39] <ubitux> nyuhu: seems like my lavfi fate howto will be soon "deprecated"
[23:40] <ubitux> (the lavfi test listing at configure time is going away soon)
[23:41] <burek> if you find a better solution, let me know :)
[23:43] <ubitux> sounds legit
[23:43] <ubitux> fine with me burek :)
[00:00] --- Thu Oct 18 2012


More information about the Ffmpeg-devel-irc mailing list