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

[burek]

[01:42] <Compn> reading Daemon404 mail now
[01:42] <Compn> u mad?
[01:42] <Compn> :P
[01:42] <Daemon404> ;p
[01:43] <Compn> somewhat hilarious that no one has a problem with it but you
[01:43] <Compn> :P
[01:43] Action: Compn trolls harder
[01:44] <Daemon404> noone has a problem
[01:44] <Daemon404> because noone uses it
[01:44] <Compn> you know mplayer can use it , right ?
[01:44] <Compn> -vf lavfi
[01:44] <Daemon404> mplayer devs == ffmpeg devs
[01:44] <Daemon404> theyre the same people
[01:44] <Daemon404> and this not relevant
[01:44] <Compn> well doesnt it answer your question about what its supposed to be ?
[01:45] <Compn> a filter library for ffmpeg and 3rd party encoders/players ?
[01:45] <Compn> i'm only asking dumb questions because i am dumb
[01:45] <Compn> so dont be offended by them
[01:47] <Compn> to answer your question on dynamic plugins , yeah i think its a great idea
[01:47] <Compn> it would just take one dynamic loader to be compiled, then any filter could be dropped in
[01:58] <Compn> ok finished reading your mail
[01:58] <Compn> you did quote someone who has a problem with lavfi :)
[01:58] <Compn> dont mind me
[01:59] <Compn> Daemon404 : i am curious since you bring up NIH, do you want ffmpeg to just add avisynth support or do you want them to port filters ?
[02:00] <Daemon404> ffmpeg has avisynth support
[02:00] <Daemon404> and im working on vapoursynth support for my own purposes
[02:00] <Compn> then i'm curious what you want lavfi to be
[02:00] <Daemon404> i dont htink lavfi should exist.
[02:00] <ubitux> do you have a better solution on linux?
[02:01] <Compn> you think its not good for users and wastes time for devels ?
[02:01] <Daemon404> vapoursynth runs on linux
[02:01] <Daemon404> and mac
[02:01] <Daemon404> and windows
[02:01] <Daemon404> and even bsd.
[02:01] <ubitux> ok
[02:01] <Compn> ubitux : there is also avxsynth , bbut i'm not sure what it is :P
[02:01] <Daemon404> Compn, its an abomination created by netflix
[02:01] <Compn> i just reading wikipedia, i dont know these things
[02:02] <Compn> to answer your question about why lavfi started
[02:03] <Compn> was it my idea? so ffmpeg could take the filters, and mplayer wouldnt have to maintain them ?
[02:03] <Compn> so vlc could use them too
[02:03] <Compn> and then make it a wrapper for all other opensource filters
[02:04] <Compn> combine forces 
[02:04] <Compn> since ffmpeg had all the decoders and muxers
[02:05] <Daemon404> [20:03] < Compn> and then make it a wrapper for all other opensource filters
[02:05] <Daemon404> problem right here
[02:05] <Daemon404> dat monolthism
[02:06] <Compn> its like arguing the kernel should stop supporting systems ... because its too big
[02:06] <Compn> or something
[02:06] <Compn> a strange position to be , i dont understand
[02:07] <Daemon404> actually
[02:07] <Daemon404> the linux kernel
[02:07] <Daemon404> design wise
[02:07] <Daemon404> is the shittiest of all modern kernels
[02:07] <Compn> of course , i come from mplayer , which bundled so much stuff ...
[02:07] <Daemon404> it just has buttloads of devs
[02:07] <Daemon404> it wasnt to long ago when you had to make powerpc drivers pretend to be i386
[02:07] <Daemon404> to make the kernel happy
[02:08] <Compn> i just want to be clear that you are arguing against what basically open source was founded on (supporting everything)
[02:09] <Daemon404> no
[02:09] <Daemon404> im arguing it's a crap design
[02:09] <Daemon404> and that all teh filters exist in better places
[02:09] <Daemon404> opensource wasnt foudned om shitty design
[02:09] <Daemon404> it was founded on technical merit, and political ideology
[02:10] <Daemon404> not recreating the wheel 9000 times
[02:10] <Compn> thats true, it wasnt my idea to rewrite the filters
[02:11] <Daemon404> im not saying it shouldnt exist
[02:11] <Compn> i'm remembering someones quote
[02:11] <Daemon404> im saying it shouldnt exist in its current form
[02:11] <Daemon404> as its utterly useless
[02:11] <Daemon404> a call to arms
[02:11] <Daemon404> so to speak
[02:11] <Compn> 'theres no reason to reinvent the wheel, but if the wheel is square...'
[02:11] <Daemon404> except
[02:11] <Daemon404> our wheel is also square
[02:11] <Daemon404> were porting logn ancient filters
[02:11] <Compn> quite possible :)
[02:12] <Compn> those filters are old
[02:12] <ubitux> what about a sphere wheel?
[02:12] <Compn> i like sphere wheel idea, more stability
[02:12] <Daemon404> me and a prominent avs plugin dev were giggling in teh VDD room for lavfi
[02:12] <Daemon404> when they were like "hwdn3d is so cuttign edge!"
[02:12] <Daemon404> "and gradfun!
[02:12] <Daemon404> (hes teh AUTHOR of gradfun)
[02:14] Action: Daemon404 goes to grab a slice of pizza quickly
[02:14] <Compn> ugh
[02:14] <Daemon404> forgot to eat dinner because of trolling...
[02:14] <Compn> google for vaporsynth not get results for vapoursynth
[02:14] Action: Compn upset
[03:21] <cone-191> ffmpeg.git 3jamal 7tests/Makefile: tests/Makefile: fix ffprobe-test.nut with target-exec
[03:21] <cone-191> ffmpeg.git 3Michael Niedermayer 7libavcodec/h264.c: h264: fix integer avoption types
[03:21] <cone-191> ffmpeg.git 3Michael Niedermayer 7libavcodec/libvpxenc.c: libvpcenc: fix flags voption types
[03:21] <cone-191> ffmpeg.git 3Michael Niedermayer 7libavcodec/mpeg4videodec.c: mpeg4videodec: fix integer avoption types
[03:21] <cone-191> ffmpeg.git 3Michael Niedermayer 7libavformat/mov.c: mov: fix integer avoption types
[06:06] <cone-191> ffmpeg.git 3Michael Niedermayer 7libavformat/movenc.c libavformat/movenc.h: movenc: support an alternative to edit lists to handle the first DTS != 0 case.
[06:09] <Daemon404> oh wow
[06:09] <Daemon404> michaelni, whats the functionality of use_editlist
[06:10] <Daemon404> it might be exactly what i was going to implement
[06:15] <Daemon404> btw michaelni, do we support edit lists properly with timestamp offsets when demuxing?
[06:15] <Daemon404> i.e. skip the first N samples based off the edit list
[06:15] <Daemon404> thats the other thing i was going to implement
[06:34] <brimestone> Im getting a weird result when i add -timecode my footage end  up 5 times longer than it should..
[11:25] <michaelni> "<Daemon404> michaelni, whats the functionality of use_editlist" <--- its to prevent the muxer from writing edit lists as some software doesnt support it
[11:25] <thresh> michaelni: hey, where do you want the hash id in the string?
[11:25] <michaelni> Daemon404, i belive the full commit message explains this
[11:26] <michaelni> thresh, dunno, no real preferrance, where it looks good or maybe where CIA had it
[11:43] <cone-49> ffmpeg.git 3Martin Storsjö 7libavformat/smoothstreamingenc.c: smoothstreamingenc: Check the output UrlContext before accessing it
[11:43] <cone-49> ffmpeg.git 3Martin Storsjö 7libavformat/smoothstreamingenc.c: smoothstreamingenc: Properly return errors from ism_flush to the caller
[11:43] <cone-49> ffmpeg.git 3Martin Storsjö 7libavformat/smoothstreamingenc.c: smoothstreamingenc: Move the output_chunk_list and write_manifest functions up
[11:43] <cone-49> ffmpeg.git 3Martin Storsjö 7libavformat/smoothstreamingenc.c: smoothstreamingenc: Try writing a manifest when opening the muxer
[11:43] <cone-49> ffmpeg.git 3Martin Storsjö 7libavformat/smoothstreamingenc.c: smoothstreamingenc: Ignore the return value from mkdir
[11:43] <cone-49> ffmpeg.git 3Martin Storsjö 7libavformat/smoothstreamingenc.c: smoothstreamingenc: Add a more verbose error message
[11:43] <cone-49> ffmpeg.git 3Anton Khirnov 7doc/RELEASE_NOTES: doc/RELEASE_NOTES: update for the 9 release.
[11:43] <cone-49> ffmpeg.git 3Mans Rullgard 7libavutil/parseutils.c: parseutils: fix parsing of invalid alpha values
[11:43] <cone-49> ffmpeg.git 3Justin Ruggles 7libavformat/ffmdec.c libavformat/ffmenc.c tests/ref/lavf/ffm: ffm: do not write or read the audio sample format
[11:43] <cone-49> ffmpeg.git 3Justin Ruggles 7libavcodec/vorbisenc.c: vorbisenc: use float planar sample format
[11:43] <cone-49> ffmpeg.git 3Justin Ruggles 7libavcodec/libmp3lame.c: libmp3lame: use planar sample formats
[11:43] <cone-49> ffmpeg.git 3Justin Ruggles 7libavcodec/libvorbis.c: libvorbis: use planar sample format
[11:43] <cone-49> ffmpeg.git 3Justin Ruggles 7libavcodec/adpcmenc.c: adpcm_ima_wav: simplify encoding
[11:43] <cone-49> ffmpeg.git 3Justin Ruggles 7libavcodec/adpcmenc.c: adpcmenc: fix 3 instances of variable shadowing
[11:43] <cone-49> ffmpeg.git 3Justin Ruggles 7libavcodec/adpcmenc.c: adpcmenc: move 'ch' variable to higher scope
[11:43] <cone-49> ffmpeg.git 3Justin Ruggles 7libavcodec/adpcmenc.c: adpcmenc: use planar sample format for adpcm_ima_wav and adpcm_ima_qt
[11:43] <cone-49> ffmpeg.git 3Justin Ruggles 7libavcodec/aacenc.c: aacenc: use planar sample format
[11:43] <cone-49> ffmpeg.git 3Justin Ruggles 7libavcodec/ac3enc_fixed.c libavcodec/ac3enc_float.c libavcodec/ac3enc_template.c libavcodec/eac3enc.c: (e)ac3enc: use planar sample format
[12:02] <cone-49> ffmpeg.git 3Michael Niedermayer s537ef8bebf8a 7libavformat/movenc.c libavformat/movenc.h: movenc: support an alternative to edit lists to handle the first DTS != 0 case.
[12:03] <thresh> michaelni: like that?
[12:04] <michaelni> thresh, hmm s537ef8bebf8a doesnt work 537ef8bebf8a does
[12:04] <thresh> oups, indeed
[12:04] <michaelni> otherwise it looks fine
[12:05] <thresh> sweet
[12:12] <nevcairiel> s is obviously not a char valid in a hex hash :p
[12:53] <cone-49> ffmpeg.git 3Michael Niedermayer 87244c8f2015 7libavformat/matroskaenc.c: matroskaenc: remove MATROSKA_ID_VIDEODISPLAYUNIT 3
[12:56] <thresh> nevcairiel: yeah, it was a leftover I had when copy-pasting message template into ffmpeg.git update hook.
[13:47] <burek> one unusual use case question :) would using: "ffmpeg -i input -map 0 -c copy -vcodec libx264 ..." cause all the streams to be copied except the videos, which would be re-encoded?
[13:47] <burek> the point is in using "-c copy -c:v <codec>"
[13:48] <burek> was it designed this way at all?
[14:04] <burek> Daemon404, ubitux, JEEBsv, etc.. can you please check #ffmpeg and advise a guy accordingly
[15:31] <ubitux> Daemon404: how does the metadata work in *synth?
[15:31] <ubitux> should we consider some communication channel such as dbus or something? or just associate some AVDictionary with each bufferref?
[15:34] <ubitux> saste: the logger you're talking would be some kind of logging callback?
[15:34] <ubitux> talking about*
[15:34] <saste> yes
[15:34] <saste> ubitx: dbus??
[15:34] <saste> no please don't
[15:34] <ubitux> :)
[15:35] <ubitux> how would you configure the logging callback?
[15:35] <saste> metadata injection was implemented with a simple AVDictionary in the buffer
[15:35] <saste> opaque
[15:35] <ubitux> and how would you use it to make our filters communicate between then?
[15:35] <ubitux> them*
[15:35] <saste> through the evil opaque field
[15:35] <ubitux> mmh
[15:36] <saste> opaque could be used to define a callback
[15:36] <saste> communication: several flavours
[15:36] <saste> metadata or commands
[15:36] <saste> and a combination of them
[15:36] <saste> for example your filter processes metadata, and send a command to another filter
[15:36] <saste> the filter receive a command, and send metadata
[15:37] <saste> the exact interaction depends on the tackled problem
[15:38] <ubitux> i see two problems to solve: making our own filters re-use information from the previous one (like -af ebur128,volume), and make some metadata available for lavfi user (like the silencedetect filter mentioned)
[15:39] <ubitux> mpf, afk for a while, i'll be back in a few minutes
[15:45] <saste> ubitux, i already replied
[15:45] <saste> re-use information: you write metadata in the buffer, the next filter reads it, process it
[15:46] <saste> export metadata: you may have a metadata sink, which prints the metadata (or logs it, or sends it, or speaks it, etc.)
[15:53] <ubitux> yep right ok
[16:00] <ubitux> speak sink filter, yay :D
[18:17] <durandal_1707> i get segv in avfilter when checking decoder for robustness
[18:17] <durandal_1707> is runtime switching between channel number supported?
[18:35] <durandal_1707> is it allowed for decoder to change number or channels in decode_frame?
[18:39] <michaelni> yes, a decoder can do that
[18:40] <nevcairiel> yeah quite some decoders  do that, doesnt mean lavfi can deal with that, though :)
[18:40] <durandal_1707> but without using get_side_data stuff?
[18:40] <michaelni> no need for side data
[18:41] <durandal_1707> than why i get segfault, codecs get 10 channels, and i get segfault when copying stuff to frame.data[]
[18:42] <michaelni> hmm you arent changing channels in the demuxer ? the decoder can the demuxer cannot directly (would be a race)
[18:42] <nevcairiel> for more then 8, you need to use frame.extended_data
[18:42] <michaelni> yes that too
[18:42] <durandal_1707> aww!!
[18:43] <michaelni> and extended data is poorly tested so it  may have bugs
[19:07] <burek> just to say, I'm not sure if the guy has created a new ticket or just uploaded a sample media file (Love Thy Brother.m4v) to ffmpeg's ftp server, but if he didn't create an appropriate ticket, then this is the post related to that file: http://ffmpeg.gusari.org/viewtopic.php?f=11&t=695&p=1030
[19:08] <burek> I'm not sure should I create the ticket or ask him to create the ticket
[19:43] <cone-223> ffmpeg.git 3Michael Niedermayer 1822aee7e6d9 7libavcodec/dsputil_template.c: dsputil_template: replace assert() by av_assert2()
[19:43] <cone-223> ffmpeg.git 3Michael Niedermayer 979b9b1f470a 7libavcodec/h264.c: h264: switch some asserts to av_assert1/2()
[20:00] <cone-223> ffmpeg.git 3Paul B Mahol 27a341518e91 7libavformat/avformat.h: avformat: fix typo in comment
[20:58] <nevcairiel> hm, how does one flush any remaining frames out of a lavfi filter graph? right now my yadif is "losing" the last frame, because i don't flush it out, but i couldnt directly find a way how to
[21:00] <Compn> burek : just create the ticket for him
[21:00] <Compn> if he makes another we can merge/close whichever
[21:00] <Compn> rather have dup tix than no-tix
[21:07] <ubitux> Daemon404: hey we have some nice filters!
[21:08] <ubitux> :(
[21:10] <Daemon404> where?
[21:10] <Daemon404> audio? yes.
[21:10] <Daemon404> video? no.
[21:10] Action: michaelni like his mandelbrot filter ;)
[21:10] <ubitux> overlay, select, tile, life :D
[21:10] <ubitux> ebur128 \o/
[21:11] <ubitux> (ass!)
[21:11] <Daemon404> [15:10] <@ubitux> overlay, select, tile, life :D <-- all in avs and vs in betetr capacities
[21:11] <Daemon404> and ass STARTED as an avs plugin
[21:11] <ubitux> life in avs?
[21:11] <Daemon404> ebur128 might be useful
[21:11] <Daemon404> what is it?
[21:11] <ubitux> ffplay -f lavfi life=s=300x200:mold=10:r=60:ratio=0.1:death_color=#C83232:life_color=#00ff00,scale=1200:800:flags=16
[21:11] <ubitux> now what!
[21:11] <Daemon404> also mandelbrot
[21:11] <Daemon404> isnt really, like
[21:11] <Daemon404> useful.
[21:12] <ubitux> pff :(
[21:12] <ubitux> deshake should be improved
[21:12] <ubitux> Daemon404: we have showspectrum/showwaves too which are kind of nice
[21:12] <Daemon404> deshake as a better version of itself
[21:12] <Daemon404> which is foss
[21:12] <Daemon404> but not gpl compatible
[21:13] <Daemon404> :/
[21:13] <ubitux> showinfo filters are nice too
[21:13] <Daemon404> also existed in every otehr framework
[21:13] <ubitux> + as you said, audio.
[21:13] <Daemon404> everything you have mentioned as existed in avs (and now vs) for almost 10 years
[21:14] <ubitux> (ah and testsrc e)
[21:14] <Daemon404> yes, audio i have no alternative to
[21:14] <Daemon404> i should have made it clear i was talkign about video
[21:14] <ubitux> lavfi is kind of nice to deal with multiple and different inputs & outputs types
[21:15] <Daemon404> not really better than anything else
[21:16] <ubitux> ./ffplay -f lavfi -i 'testsrc,hue=H=2*PI*t:s=sin(2*PI*t)+1' e
[21:17] <ubitux> 21:11:21 <@Daemon404> ebur128 might be useful
[21:17] <ubitux> 21:11:24 <@Daemon404> what is it?
[21:17] <burek> Compn ok
[21:17] <ubitux> loudness thing
[21:17] <Daemon404> right
[21:17] <Daemon404> audio
[21:17] <ubitux> audio 2 video to be exact
[21:17] <ubitux> ffplay -f lavfi -i "amovie=input.mp3,ebur128=video=1:meter=18 [out0][out1]"
[21:18] <ubitux> IMO the biggest problem right now is the metadata
[21:18] <ubitux> but according to saste it should be fixable without much effort
[21:18] Action: michaelni wonders if theres another filterframwork than libavfilter thst can be used allocate buffers that can be used as internal buffers for a decoders like h264
[21:19] <michaelni> that is direct rendering / avoiding memcpies
[21:21] <Daemon404> i dont think anythign sane would do that
[21:21] <Daemon404> thats needlessly coupled with a decoder
[21:21] <Daemon404> and is messy
[21:21] <Daemon404> also it's nto the bottleneck
[21:21] <Daemon404> filtering is
[21:21] <Daemon404> so it really is irrelevant
[21:22] <Daemon404> come to think of it, ffms2 might decode directly into avs's buffer
[21:23] <michaelni> so you are saying its doing something messy and irrelevant ?
[21:23] <Daemon404> it's micro-optimizationt
[21:23] <Daemon404> athat im willign to be, when filtering, has very little benefit
[21:23] <Daemon404> with teh cost of coupling libarries to one another
[21:25] <michaelni> theres no coupling though
[21:26] <michaelni> its just using the get/release buffer callbacks of the decoder
[21:26] <Daemon404> i need to check
[21:26] <Daemon404> i think avs and vs can do this
[21:26] <Daemon404> with input plugins
[21:26] <Daemon404> it should be entirely possible
[21:26] <Daemon404> i was mistaken abotu what you meant before
[21:26] <Daemon404> apologies.
[21:36] <Daemon404> michaelni, i think i semi-agree with paul about the boatloads of packed yuv stuff being put in decoders
[21:37] <Daemon404> at the very least i think all the vXXX decoders should be in one file
[21:37] <Daemon404> its geting out of hand..
[21:37] Action: Daemon404 can volunteer to do it, if he wont get flamed
[21:37] <Compn> which decoders would you merge together ?
[21:38] <Daemon404> v<numbers>.c
[21:38] <Compn> ah
[21:39] Action: michaelni has no plans to flame
[21:40] <Compn> might want to see what carl thinks :P
[21:40] <Daemon404> i dont think hell mind
[21:40] <Daemon404> but i can ask
[21:40] <Compn> always good to ask authors / maintainers
[21:40] <Daemon404> were adding a huge number of packed formats to libavcodec
[21:40] <Daemon404> its pretty ugly
[21:56] <Daemon404> looks liek avs would handle direct render perfectly fine
[22:30] <cone-223> ffmpeg.git 3Justin Ruggles d58b25aaa261 7libavcodec/adpcmenc.c: adpcmenc: ensure calls to adpcm_ima_compress_sample() are in the right order
[22:30] <Daemon404> \o/
[22:45] <michaelni> Daemon404, well compressed (0.1k) ---> 1007 22:07 Buitenhuis, Der (0.1K) Public Key for FATE
[22:46] <Daemon404> compressed?
[22:46] <michaelni> there is no attachment
[22:47] <Daemon404> uh
[22:47] <Daemon404> yeah im awesome
[22:47] <Daemon404> let me resend that
[22:47] <nevcairiel> is it just me, or is that something everyone screws up at least once every other week? :d
[22:48] <Daemon404> sent
[22:49] <michaelni> Daemon404, i confirm reception, you need to wait for baptiste though, his admin powers are needed to add keys
[22:50] <Daemon404> k
[23:34] <cone-223> ffmpeg.git 3Michael Niedermayer f9b0694cc8ff 7libavcodec/motion-test.c: motion-test: fix height parameter
[23:34] <cone-223> ffmpeg.git 3Michael Niedermayer 2714e841bcfd 7libavcodec/x86/motion_est.c: x86/motion_est: assert->av_assert2()
[23:34] <cone-223> ffmpeg.git 3Michael Niedermayer f2a7e1a62b6d 7libavformat/mux.c: mux: change 1 assert->av_assert1()
[00:00] --- Mon Oct  8 2012