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

[burek]

[00:24] <wm4> durandal_1707: what kind of setup do you have where +fast is useful?
[00:25] <durandal_1707> it is for playing 1080p on slow machine
[00:27] <durandal_1707> actually it is 1920x800
[00:28] Action: durandal_1707 hates filters with *pp* in their names
[00:29] <wm4> lol
[00:40] <Compn> durandal_1707 : would you rather it be named 'enhance' ?
[00:41] <durandal_1707> it is not about name......
[00:42] <Compn> arent fspp and uspp just based on ffmpeg ?
[00:43] <Compn> er nevermind
[00:43] <wm4> I still don't get why you think these filters are important at all
[00:44] <wm4> if users want them, let them use mplayer and mencoder
[00:45] <Compn> let them ... eat cake!
[00:46] <durandal_1707> there is whole library that does just that: PostProcessing
[00:46] <durandal_1707> and guess what: it is very popular
[00:46] <wm4> libpostproc? well yeah, use that
[00:47] <wm4> or let whoever is interested merge vf_pp7 etc. with libpostproc
[00:53] <durandal_1707> no comment: gate ... Noise gate filter similar to the comp audio filter.  This filter is untested, maybe even unusable.
[00:53] <wm4> lol
[00:54] <durandal_1707> similar for comp (compressor/expander)
[00:54] <Compn> ssecret nsa backdoor filter
[00:55] <pippin> "There will be no 'need to know'."
[00:56] <durandal_1707> at least they do not lie that filter is tested and usable
[01:26] <cone-488> ffmpeg.git 03Michael Niedermayer 07master:ae57e82469c9: avcodec/dsputil: add 12bit simple idct
[01:26] <cone-488> ffmpeg.git 03Michael Niedermayer 07master:15071ed4fc55: avcodec/mjpegdec fix last_dc for bits != 8
[01:26] <cone-488> ffmpeg.git 03Michael Niedermayer 07master:1deeb9437c9c: avcodec/mjpegdec: Fix normal jpeg with bits < 8
[01:26] <cone-488> ffmpeg.git 03Michael Niedermayer 07master:c407c73457df: avcodec/mjpegdec: 12bit Grayscale support
[02:17] <BBB> ubitux: michaelni: ok I think I have emu-edge with split src/dst stride working (including simd)
[02:17] <BBB> still needs some profiling, but my feeling is it should be faster (I rewrote the assembly and it's a lot more clever now)
[02:18] <BBB> now need some minor wrapping code for the vp9 block reconstruction code and then -fflags +emu_edge is functional also
[02:38] <cone-488> ffmpeg.git 03Michael Niedermayer 07master:b155fb08b8fe: avcodec/mjpegdec: move shift_output() to its own function
[02:38] <cone-488> ffmpeg.git 03Michael Niedermayer 07master:bcd1c2061211: avcodec/mjpegdec: support >8bit in mjpeg_decode_scan_progressive_ac()
[02:41] <BBB> av500: is that from oz?
[04:05] <cone-488> ffmpeg.git 03Michael Niedermayer 07release/1.0:49237131e980: avcodec/mjpegdec: Add some sanity checks to ljpeg_decode_rgb_scan()
[04:05] <cone-488> ffmpeg.git 03Michael Niedermayer 07release/1.0:fcd46cfbbd90: update for 1.0.8
[04:46] <cone-488> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n1.0.8': unknown revision or path not in the working tree.
[04:46] <cone-488> Use '--' to separate paths from revisions
[04:46] <cone-488> refs/tags/n1.0.8:HEAD: avcodec/mjpegdec: support >8bit in mjpeg_decode_scan_progressive_ac()
[04:46] <michaelni> hmm
[04:47] <michaelni> cone is still buggy :(
[04:58] <Kovensky> https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html
[09:46] <ubitux> the non refcounting api looks broken
[09:46] <ubitux> you can't use av_frame_alloc() and av_frame_free() without it
[09:47] <nevcairiel> you have to keep using the old api
[09:49] <ubitux> so AVFrame on the stack?
[09:49] <ubitux> that sucks a bit
[09:49] <ubitux> you may not have the need of the reference counting system
[09:49] <ubitux> (and that's actually the default)
[09:49] <ubitux> that should not mean the need of using AVFrame on the stack
[09:49] <ubitux> IMO
[09:50] <nevcairiel> you dont need to put it on the stack
[09:50] <ubitux> then how do you do it?
[09:52] <nevcairiel> avcodec_alloc_frame and avcodec_free_frame
[09:52] <nevcairiel> like i said, old API
[09:52] <nevcairiel> should probably be documented somewhere
[09:53] <nevcairiel> however, using refcounting isnt actually harder
[09:53] <nevcairiel> you just need to free the frame with av_frame_free or av_frame_unref after every decode call
[09:55] <ubitux> mmh
[09:59] <ubitux> nevcairiel: thx! perfect :)
[10:00] <ubitux> i guess i'll update my example then
[10:53] <ubitux> nevcairiel: so yeah, the overhead is an unref, and the need to enable the ref counting mode
[10:54] <ubitux> saste: so, are you going to fix the filtering examples?
[10:55] <saste> ubitux, if you tell me how, sure
[10:55] <ubitux> saste: you need to make a choice
[10:55] <ubitux> either enable the ref counting mode, and add an unref
[10:56] <ubitux> or change the frame alloc/frame functions
[10:56] <ubitux> saste: look my latest patch, it displays how to choose between one mode or another
[10:56] <ubitux> if it's not clear, tell me :)
[10:56] <saste> uhm ok
[10:57] <saste> btw i'm a bit afraid of having too many decoding examples
[10:57] <saste> looks more work to maintain them, also what's wrong with decoding.c?
[10:57] <ubitux> we could rewrite some examples
[10:57] <ubitux> it doesn't exists saste 
[10:57] <ubitux> decoding_encoding.c you mean?
[10:57] <saste> yeah
[10:57] <nevcairiel> some of the examples are a bit too complex
[10:57] <ubitux> it's too much IMO
[10:58] <ubitux> decoding_encoding is 650LoC
[10:58] <ubitux> it does a LOT of things
[10:58] <ubitux> (and it's likely outdated
[10:58] <ubitux> i'd rather remove it and add a encoding_video.c just like the decoding_video.c I added
[10:58] <ubitux> this time with a very simple data generation, but only the encoding process
[10:59] <ubitux> then another with decoding_audio.c and encoding_audio.c
[10:59] <saste> nevcairiel, i can't but agree
[11:00] <saste> why different examples for audio and video? we should try to abstract the differences as much as possible
[11:00] <ubitux> you can't
[11:04] <durandal_1707> there is no way to select frame from several inputs?
[11:16] <durandal_1707> is there mplayer repo i can browse?
[11:16] <ubitux> there is a git mirror
[11:17] <ubitux> probably Vous jtes diclari(e) comme itant contact administrateur d'un ou plusieurs
[11:17] <ubitux> domaines chez OVH.
[11:17] <ubitux> oh god.
[11:17] <ubitux> probably git://git.mplayerhq.hu/mplayer
[11:19] <durandal_1707> saste: so why select filter can't select from multiple inputs?
[11:27] <saste> durandal_1707, why? there is no specific answer
[11:27] <saste> i think it could be done, do you have an use case?
[11:28] <durandal_1707> straming from multiple cameras
[11:28] <saste> probably the interleave logic could be used
[11:29] <durandal_1707> after X seconds pick another camera
[11:30] <saste> also there is the queuing issue
[11:30] <saste> you need to queue incoming frames, and queues and memory is limited
[11:31] <durandal11707> not wanted frames are droped
[12:16] <cone-419> ffmpeg.git 03Diego Biurrun 07master:b634b36fcebf: mem: Improve documentation wording and spelling
[12:16] <cone-419> ffmpeg.git 03Michael Niedermayer 07master:92424a45d0c3: Merge commit 'b634b36fcebfe16b837b6c4044f5d5cb99a75040'
[12:23] <durandal_1707> michaelni: you gonna comment w3fdif?
[12:32] <durandal_1707> why nobody comments nicolas multiple inputs patch?
[12:33] <cone-419> ffmpeg.git 03Diego Biurrun 07master:c3e6e8f06c42: mem: Do not check unsigned values for negative size
[12:33] <cone-419> ffmpeg.git 03Michael Niedermayer 07master:5866c107a9b9: Merge commit 'c3e6e8f06c42499bd020fd0b37f9542150e6067b'
[12:42] <michaelni> durandal_1707, the code has already been reviewed by multiple other developers
[12:43] <cone-419> ffmpeg.git 03Vittorio Giovara 07master:66f091053f11: mpeg12enc: drop forward declarations
[12:44] <cone-419> ffmpeg.git 03Michael Niedermayer 07master:61845dc74afc: Merge commit '66f091053f11a8957b2175480d2f368d2cf4474c'
[12:46] <durandal_1707> good, whoever find issues later is left to fix it ;-)
[13:06] <cone-419> ffmpeg.git 03Vittorio Giovara 07master:7f93a861aaf2: mpeg12enc: K&R formatting cosmetics
[13:06] <cone-419> ffmpeg.git 03Michael Niedermayer 07master:2a27e5255071: Merge commit '7f93a861aaf2e76fd63b53ccc465909873b8dc29'
[13:33] <cone-419> ffmpeg.git 03Diego Biurrun 07master:befe044bb956: avcodec: Stop exporting the removed audio_resample* symbols
[13:33] <cone-419> ffmpeg.git 03Michael Niedermayer 07master:c4a696fb5465: Merge commit 'befe044bb9561c9d7d6559db06bba375e82a4b66'
[13:46] <cone-419> ffmpeg.git 03Diego Biurrun 07master:97b052e56807: avisynth: Add missing #include for NULL_IF_CONFIG_SMALL
[13:47] <cone-419> ffmpeg.git 03Michael Niedermayer 07master:86ca6a756849: Merge commit '97b052e56807fab6887e9ba210a28a622e6a4b78'
[13:59] <cone-419> ffmpeg.git 03Diego Biurrun 07master:c16ddcc90b8b: avisynth: K&R formatting cosmetics
[13:59] <cone-419> ffmpeg.git 03Michael Niedermayer 07master:911a100da9f5: Merge remote-tracking branch 'qatar/master'
[14:12] <saste> ubitux, what's your plan with regards to decoding_encoding.c?
[14:13] <ubitux> i have nothing planed so far
[14:13] <ubitux> 'cuz i don't like the current examples except mine :D
[14:13] <saste> do you want to create decoding_audio.c, encoding_* and kill encoding_decoding.c?
[14:14] <ubitux> ideally, but i've nothing planed so far
[14:14] <ubitux> if i start working on it i'll notice you
[14:16] <saste> btw did you check the demuxing.c loop?
[14:16] <saste> does it suffer from the same issue?
[14:17] <ubitux> i just looked at filtering_*
[14:17] <ubitux> the others might be affected as well
[14:18] <durandal_1707> what about this "All Rights Reserved" above license?
[14:18] <ubitux> the logic is a bit different in demuxing, because it deals with audio
[14:19] <ubitux> video can only have 1 frame per packet, right?
[14:19] <ubitux> <= 1 frame actually
[14:20] <saste> and we really need to document this refcounted_frames thing
[14:20] <ubitux> the pkt.{data,size} thing was always a bit obscure to me
[14:20] <saste> like for example in the manual
[14:20] <ubitux> saste: is my example clear enough?
[14:20] <saste> ubitux, i'm reviewing it by now
[14:21] <saste> i already told you why i am concerned, we have several decoding loops in examples already (decoding_encoding, demuxing, filtering_video)
[14:21] <ubitux> yeah
[14:22] <ubitux> i'm wondering for instance right now about the decode packet loop in demuxing.c
[14:22] <ubitux> afaik it's audio specific, but i may be wrong
[15:22] <cone-419> ffmpeg.git 03Paul B Mahol 07master:898c6191ff3d: lavfi: Weston 3 Field Deinterlacing Filter
[15:45] <durandal_1707> what tool dumps formats supported by filter?
[15:46] <Compn> what
[15:51] <durandal_1707> filtfmts
[18:00] <j-b> Kamedo2 ?
[19:04] <cone-419> ffmpeg.git 03Paul B Mahol 07master:6508bd4aa332: pixfmt: add native GBRAP16 format
[19:43] <cone-419> ffmpeg.git 03Paul B Mahol 07master:6b024d8a7ac3: avcodec/xan: use uint8_t instead of unsigned char
[19:43] <cone-419> ffmpeg.git 03Paul B Mahol 07master:c9b5ad124e9b: s302m: s/bits_per_coded_sample/bits_per_raw_sample
[20:49] <cone-419> ffmpeg.git 03Paul B Mahol 07master:9b35bee69673: lavfi/fieldorder: remove redundant get_video_buffer()
[20:49] <cone-419> ffmpeg.git 03Paul B Mahol 07master:df7e3572c333: lavfi/fieldorder: use av_image_fill_linesizes()
[20:49] <cone-419> ffmpeg.git 03Paul B Mahol 07master:86cb986ce12a: lavfi/fieldorder: add timeline support
[20:49] <cone-419> ffmpeg.git 03Paul B Mahol 07master:33dacda40b7a: lavfi/fieldorder: remove pal8 format
[20:49] <cone-419> ffmpeg.git 03Paul B Mahol 07master:6770fa4df8e1: lavfi/fieldorder: work with non writtable frames too
[20:50] <cone-419> ffmpeg.git 03Paul B Mahol 07master:50b90d5e0ba0: lavfi/telecine: remove bitstream and pal formats
[22:04] <ubitux> it's fun how vf deshake is actually pretty close to vid.stab
[22:04] <ubitux> ...and how the author of vid.stab is actually in the deshake copyright
[22:18] <Compn> did you read the thread ?
[22:18] <Compn> where he was interested in getting vid stab into ffmpeg
[22:18] <ubitux> vid stab is in ffmpeg
[22:18] <ubitux> i pushed it
[22:19] <ubitux> i mean, the wrapper
[22:19] <Compn> for the external lib ?
[22:19] <ubitux> yes
[22:19] <Compn> and we told him he could either do it externally, which means barely anyone would use it, or he could do an internal filter that would be default built into every ffmpeg  and widely used 
[22:19] <ubitux> it's still heavily broken with ffplay
[22:19] <Compn> so he chose the 2nd option iirc
[22:19] <ubitux> yes i know i was participating
[22:19] <Compn> oh ok :)
[22:20] <wm4> if only we had something like avisynth!
[22:20] <wm4> which doesn't mean giving away control over a filter to ffmpeg
[22:20] <Compn> that works on linux ?
[22:20] <wm4> yes
[22:20] <Compn> mac ?
[22:20] <nevcairiel> avxsynth is horrible, fwiw
[22:20] <wm4> vapoursynth is similar to avisynth (designed as successor), and it's highly portable 
[22:20] <Compn> oh no, another synth battle
[22:20] <Compn> :P
[22:20] <ubitux> wm4: why are you raising that up again?
[22:21] <ubitux> can we try to have just one day without the VS fag shit? :)
[22:21] <wm4> it'as important
[22:21] <Compn> ubitux : maybe he wants ffmpeg synth wrapper
[22:21] <iive> at least under windows.
[22:21] <Compn> like mencoder has ?
[22:21] <wm4> we all know lavfi will never be as useful as avisynth, because it's too unstable, too tightly coupled, too ffmpeg controlled
[22:21] <iive> yeh...
[22:21] Action: pippin used to have his own synth alternative, ages and ages ago :)
[22:22] <wm4> nevcairiel: didn't you say something about writing a lavfi vsynth wrapper?
[22:22] <iive> next step would be integrating wine...
[22:22] <pippin> http://codecave.org/bauxite/
[22:22] <Compn> ffmpeg needs a dll loader anyway
[22:22] <ubitux> why don't ppl who care about vs don't get that wrapper done for once?
[22:22] <Compn> binary codecs here we come!!!!!!!1
[22:22] <ubitux> instead of derping everytime we mention lavfi on the channel?
[22:22] <wm4> pippin: that's a xml format
[22:23] <Compn> wm4 : did you talk to libav about vsynth wrapper in lavfi ?
[22:23] <ubitux> Compn: no, rectification, youtube wants ffmpeg to have a dll wrapper
[22:23] <wm4> uh why libav
[22:23] <wm4> a dll loader would be nice
[22:23] <wm4> but it's not as important anymore
[22:23] <Compn> was just a suggestion
[22:24] <ubitux> anyway, i may be working on vf deshake soon
[22:24] <ubitux> like, right now
[22:24] <Compn> cool
[22:24] <pippin> wm4: xml was irrelevant to it, it was a full on demand driven graph based video frame filtering processor/framework; using ffmpeg for video frame input/output
[22:24] <wm4> ubitux: also, should that be the case, don't view vsynth as enemy, but as a friend
[22:24] <ubitux> wm4: why do you think i view vs as an enemy?
[22:25] <wm4> personally I really dislike how you can't add filters to lavfi, and how you can't get closer control over lavfi filter instances
[22:25] <pippin> I stopped caring about video processing/editing, when I stopped making short-films/music videos ;)
[22:25] <wm4> ubitux: because you complain about it being brought up
[22:25] <ubitux> the enemy is the continuous trolling about lavfi every single day and how vs is awesome
[22:25] <ubitux> just get that wrapper done, i personally really don't care
[22:25] <ubitux> because it's packaged nowhere
[22:25] <wm4> ffmpeg isn't packaged much either, trollol
[22:26] <ubitux> :)
[22:27] <wm4> the main problem is that to add a filter to lavfi, you have to become a ffmpeg contributor
[22:27] <ubitux> no
[22:27] <wm4> that's a high barrier of entrance, and doesn't encourage experimentation at all
[22:27] <ubitux> too bad
[22:27] <ubitux> we should move to bbs+zip development driven too
[22:27] <wm4> yes that's bad
[22:28] <ubitux> because a lot of contributors don't know how to send an email but knows bbcodes
[22:28] <wm4> now you're just trolling
[22:28] <ubitux> sorry, i was following your pace
[22:29] <wm4> look, using ffmpeg as utility is way less nice than using avisynth
[22:30] <ubitux> then use avisynth?
[22:31] <wm4> most do
[22:31] <wm4> and laugh at lavfi
[22:31] <wm4> :)
[22:31] <ubitux> cool
[22:31] <wm4> ok now we trolled each other properly
[22:31] <wm4> let's go back to thinking about how to make this kind of video processing nice
[22:32] <Compn> we all agree we should have a avisynth wrapper filter
[22:32] <Compn> so why are we arguing ?
[22:32] <ubitux> because they are lazy and want the dev to write it so they realize the supremacy of it
[22:32] <Compn> :p
[22:33] <ubitux> ...instead of just learning how to use lavfi and send patches
[22:33] <Compn> wm4 : start a kickstarter to fund development of a wrapper
[22:33] <ubitux> haha
[22:33] <pippin> wm4: if I ever end up doing video editing again, I'd most likely resurrect a combined non linear editor/compositor framework similar to bauxite, but this time use the project I took over maintership of when I gutted bauxite and its underlying libs :)
[22:33] <wm4> there's already a wrapper
[22:33] <wm4> but avxsynth sucks
[22:33] <ubitux> Compn: don't mistaken vsynth for avisynth btw
[22:33] <pippin> though, for experimenting with plug-ins and such, what's wrong with long tanding simple plug-in things like frei0r ?
[22:34] <pippin> s/tanding/standing/
[22:34] <ubitux> Compn: vapoursynth is the new trending avisynth - basically the only fork maintained
[22:34] <wm4> avisynth by itself is crap, what's so great is the community, and how everyone can actually create useful filters (without having to deal with patch review on some mailing list)
[22:34] <ubitux> or should i say "compatible alternative"
[22:34] <nevcairiel> yeah its not a fork, a fork of the concept maybe =p
[22:35] <ubitux> wm4: we are an alternative, we different way of working
[22:35] <Plorkyeran> 90% of what makes avs useful is that people good at signal processing and terrible at software development can manage to release filters for it
[22:35] <ubitux> with benefits and drawbacks
[22:35] <ubitux> you need to realize that
[22:35] <wm4> before libav destroyed it, at least you could add your own filters to lavfi without patching it...
[22:35] <wm4> (though it wasn't pretty)
[22:35] <Plorkyeran> so the filters are mostly terribly written and terribly distributed, but at least actually do useful things
[22:36] <Compn> so kickstarter, yay or nay ?
[22:36] <ubitux> wm4: i think the api still needs some slight reshape before re-opening the api, and maybe we need some essential features (which might require re-design)
[22:37] <ubitux> typically, simplify the request_frame() thing, and add seeking
[22:37] <ubitux> when this is done, i believe we could make it stable and open a way to write filters
[22:37] Action: pippin shrugs at video effect frameworks that insist on YUV and non 4:4:4 processing :p
[22:37] <wm4> isn't seeking just as easy as adding a command
[22:38] <ubitux> i'm not sure
[22:38] <ubitux> maybe a reconfigure option
[22:38] <ubitux> saste might be able to comment, dunno what's the state
[22:57] <durandal_1707> state is 'lazy'
[22:58] <durandal_1707> i can't get it. but why lavfi can support real scripting?
[23:09] <durandal_1707> ubitux: why edgedetect supports only gray format?
[23:09] <durandal_1707> isn't adding sobel detector trivial?
[23:11] <ubitux> it uses sobel
[23:12] <ubitux> the filter is not meant to have colors
[23:12] <ubitux> or then that's another algo
[23:13] <ubitux> it's a canny edge detector
[23:13] <ubitux> feel free to add more modes
[23:14] <durandal_1707> other detectors have colors
[23:15] <wm4> you could use the result of the edge detector to modulate the color image or so?
[23:16] <durandal_1707> nope. it runs algo only on one plane
[23:17] <durandal_1707> so one filter can not run other filters?
[23:17] <wm4> I mean, you can multiply each pixel in the source filter with the output of the edge detector
[23:17] <wm4> surely there's a filter for that?
[23:17] <wm4> maybe vf_blend
[23:18] <durandal_1707> but that is not what i'm talking about....
[23:19] <durandal_1707> ubitux: why some of your copyright does not list your email? (this is inconsistent)
[23:25] <ubitux> durandal_1707: because i dont like/care having my mail all around
[23:25] <ubitux> i think it's not important
[23:26] <ubitux> when there are copyrights with mails i add mine, otherwise i dont put it
[23:27] <cone-419> ffmpeg.git 03Kirill Gavrilov 07master:0f48acf29bab: lavu: provide msvc implementation of attribute_deprecated
[23:27] <ubitux> i think that's what i followed
[23:28] <ubitux> add the pkh one if you want to
[23:29] <ubitux> but obfudcated like i did in other places plz...
[23:29] <durandal_1707> i will apply s/edgedetect/s/ thing instead
[23:30] <ubitux> lol
[23:30] <durandal_1707> why i need to type edgedetect when trying to reads priv context... when i can type just s
[23:31] <ubitux> gtg, hf with sed
[23:31] <durandal_1707> perhaps i should do something like PullupVideoFilterPrivateContext
[23:32] <durandal_1707> sed doesn't work if there is s variable
[23:50] <durandal_1707> am i the only one left to do filter of the week? I'm doing it since mid of May.
[23:59] <durandal_1707> hmm does asetnsamples really need .needs_writable ?
[00:00] --- Sat Sep  7 2013