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

[burek]

[00:09] <ubitux> 80+ comments
[00:09] <ubitux> that sure is a chatty ticket
[00:23] <Compn> ehe
[00:23] <Compn> 2085 is up to 47
[00:23] <Compn> er 48 :P
[00:30] <Compn> that is one in depth alsa audio problem
[00:30] <Compn> carl spent a lot of time helping that user
[00:31] <llogan> he's also the most "active" user on bureks ffmpeg forum
[00:32] <ubitux> oh? carl is on the ffmpeg forum?
[00:32] <ubitux> or you're refering to the user?
[00:32] <llogan> no, the guy he's helping
[00:32] <ubitux> ok
[01:08] <cone-845> ffmpeg.git 03Stefano Sabatini 07master:57655c608078: doc/metadata: add notes and examples regarding metadata usage with ffmpeg
[01:16] <cone-845> ffmpeg.git 03Michael Niedermayer 07master:175e916fa20b: avcodec/utils: Fix encoder allocation size
[02:53] <cone-845> ffmpeg.git 03Carl Eugen Hoyos 07master:7800b09ece52: Check more completely for invalid pix_fmts in planarRgb16ToRgb16Wrapper()
[02:53] <cone-845> ffmpeg.git 03Michael Niedermayer 07master:0f88a98b43b8: Merge remote-tracking branch 'cehoyos/master'
[04:10] <Compn> the dvd-cca copyright DMCA exemption fight is still going on in the courts ?
[04:12] <Compn> er at copyright office , not in the courts
[04:23] Action: Compn digs around
[04:23] <Compn> http://csc.lsu.edu/~kooima/avpan/index.html
[04:23] <Compn> interesting videos
[08:32] <cone-979> ffmpeg.git 03Martin Storsjö 07master:2aa332545454: configure: arm: Don't try to enable pic for shared libraries on win32
[08:32] <cone-979> ffmpeg.git 03Michael Niedermayer 07master:1603c9bd9caf: Merge commit '2aa3325454545b63cd63e3d5884f8558790d51df'
[08:53] <cone-979> ffmpeg.git 03Martin Storsjö 07master:3fd0d166aa24: configure: Don't explicitly disable PIC for windows targets
[08:53] <cone-979> ffmpeg.git 03Michael Niedermayer 07master:f556f27d298a: Merge commit '3fd0d166aa240ef547482d1af397c4a653031c2d'
[09:00] <cone-979> ffmpeg.git 03Martin Storsjö 07master:3965d404ccd9: configure: Don't add -fPIC on windows targets
[09:00] <cone-979> ffmpeg.git 03Michael Niedermayer 07master:529ebc90f242: Merge commit '3965d404ccd9b6cac95c4aee6cb668845031b685'
[09:21] <cone-979> ffmpeg.git 03Sean McGovern 07master:8835c554ff50: matroskadec: introduce resync function.
[09:21] <cone-979> ffmpeg.git 03Michael Niedermayer 07master:045e371cf1f0: Merge commit '8835c554ff506992c47f6e347c74216ae073f0fa'
[09:34] <cone-979> ffmpeg.git 03Anton Khirnov 07master:799f57ac96f9: lavc: use AVFrame API properly in pad_last_frame().
[09:34] <cone-979> ffmpeg.git 03Michael Niedermayer 07master:5d199c3ad985: Merge commit '799f57ac96f9891d1a0f7d6c4b218ed536e8aca5'
[09:42] <cone-979> ffmpeg.git 03Anton Khirnov 07master:84d3ff50cd67: lavc: add a libwavpack encoder wrapper
[09:42] <cone-979> ffmpeg.git 03Michael Niedermayer 07master:73d5cf8f4378: Merge remote-tracking branch 'qatar/master'
[11:07] <khali> hi all
[11:08] <khali> this is the first time I am looking into the ffmpeg code and joining this channel, so please let me know if I do anything wrong
[11:12] <khali> I am doing computations which would easily overflow a 32-bit int
[11:13] <khali> would I rather use type unsigned long long or double to solve this problem? is there a policy in this regard?
[11:13] <nevcairiel> i would try to stick to integers
[11:16] <khali> nevcairiel: OK, will do, thanks
[11:16] <khali> nevcairiel: I suppose unsigned long long is faster than double on x86-64, but I seem to remember the opposite is true on i686
[11:19] <khali> I've been looking at my code for an hour now, trying to figure out a way to avoir the overflow
[11:19] <khali> but no matter what I do it results in a loss of accuracy
[11:25] <av500> to avoid a 32 bit overflow?
[11:25] <av500> use 64 bitr
[11:25] <av500> -r
[11:26] <khali> av500: yes, unsigned long long is always 64-bit right?
[11:27] <av500> uint64_t is
[11:27] <nevcairiel> ffmpeg style would be uint64_t
[11:27] <nevcairiel> but sure
[12:05] <khali> nevcairiel: oh I can use uint64_t if this is the preferred way, no problem
[13:30] <khali> is there an equivalent of the linux kernel's DIV_ROUND_UP macro available in ffmpeg?
[13:35] <wm4> khali: FF_CEIL_RSHIFT for rounding up chroma sizes, apparently
[13:38] <khali> wm4: I need something more generic
[13:38] <khali> wm4: ah, ROUNDED_DIV it is :)
[13:38] <khali> thanks
[13:39] <khali> (my question was bad actually, I was really looking for an equivalent of DIV_ROUND_CLOSEST, not DIV_ROUND_UP)
[14:07] <khali> BTW I'm working on the delogo video filter, if anyone is interested
[14:07] <av500> hmm, all my video files come without a logo
[14:09] <khali> av500: I wish mine did too, but I am recording a lot of cartoons on TV for my kids, and they almost always have two logos
[14:09] <wm4> khali: there are already 2 (crappy) ones in libavfilter (you probably know this)
[14:09] <khali> wm4: yes, "delogo" is in libavfilter
[14:10] <khali> wm4: I am precisely trying to make it less crappy ;)
[14:10] <wm4> good
[14:10] <khali> with some good results so far
[14:10] <av500> good
[14:10] <wm4> there's also "removelogo", but it's the worse one
[14:11] <av500> replace all logos with ffmpeg logo
[14:11] <khali> wm4: actually I started using removelogo first
[14:12] <wm4> watermark all ffmpeg produced streams to find GPL violations!
[14:12] <khali> wm4: and found delogo after that
[14:12] <wm4> khali: ow
[14:12] <khali> wm4: and I'd say both have their own merits
[14:12] <JEEBsv> hmm, what happened to that one MVC decoder guy?
[14:12] <khali> wm4: I think delogo gives better results for "plain" logos... but removelogo gives much better results when the logo has holes in it
[14:25] <ubitux> khali: working on those filters is very welcome, thanks :)
[14:27] <khali> ubitux: I am currently testing my changes to delogo and the output is very promising
[14:27] <khali> better than I expected actually
[14:27] <khali> I still must test on other video samples to make sure there are no unexpected drawbacks
[14:28] <khali> my only remaining worry is the handing of clipping
[14:28] <khali> it makes things much more complex and I doubt it is of much use in practice
[14:29] <khali> I wonder if there would be any pushback if I proposed dropping it
[14:29] <wm4> you mean the width/height parameters?
[14:30] <khali> wm4: no
[14:30] <khali> these parameters are needed and useful, clearly
[14:30] <khali> wm4: but the algorithm needs some space around the logo for interpolation
[14:30] <khali> and if the logo was very close to the border, the space in question could be outside of the actual picture
[14:30] <khali> there's clipping applied to avoid that
[14:31] <khali> but personally I've never seen a TV logo that close to the border
[14:31] <khali> and if it is then interpolation will be very bad anyway
[14:39] <ubitux> you can print a warning at init, and while processing look at the opposite side, and if no opposite side assume black
[14:43] <khali> ubitux: how could there be no opposite side?
[14:44] <ubitux> logo_h == video_h || logo_w == video_w
[14:44] <khali> ah
[14:44] <khali> yeah, I suppose that could happen ^^
[14:46] <khali> not sure if looking at the opposite side would be such a good idea to start with...
[15:05] <wm4> is Mr. Coldwind sending his reports to libav instead of ffmpeg now?
[15:06] <durandal_1707> who?
[15:08] <wm4> Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[15:11] <ubitux> afaik the reports were already available for libav but they didn't want to fix them because lacking of info to reproduce
[15:11] <ubitux> or ETOOSECRET or something
[15:19] <saste> ubitux, spp?
[15:19] <saste> do you have specific arguments for wanting to remove the remaining pp mpcodecs filters?
[15:22] <saste> the rotate patch is more than 5 years old...
[15:23] <khali> and still spinning?
[15:25] <ubitux> saste: i planned to push spp this week, is there any urge?
[15:25] <microchip_> push it nao!
[15:25] <ubitux> saste: about the other filters, it was mostly a question of efficiency or usage spread
[15:25] Action: microchip_ pushes :D
[15:25] <ubitux> microchip_: no i'm waiting for your comparison against the other filters to save me some time
[15:27] <ubitux> saste: transpose filter doesn't do that btw?
[15:27] <ubitux> (rotate thing)
[15:27] <ubitux> oh it's an arbitrary angle
[15:27] <ubitux> cooool
[15:28] <khali> cool and soooo useful in practice ;)
[15:31] <ubitux> saste: and don't worry i'll just drop mp=spp in the first place, and send another patch for the others (when microchip_ will be done with the comparison)
[15:31] <microchip_> ubitux: i can't see much difference, but pp7 looks slightly better than spp
[15:32] <ubitux> ah
[15:32] <ubitux> well maybe it could be merged within spp
[15:32] <microchip_> ubitux: for the rest, fspp and uspp are equal (AFAIK)
[15:33] <ubitux> fspp is 1d while spp is 2d according to iive
[15:33] <ubitux> and uspp depends on snow codec
[15:33] <microchip_> i don't know
[15:33] <ubitux> microchip_: pp7 looks slightly better than spp=6?
[15:33] <durandal_1707> remove. if someone notice that would be miracle
[15:33] <microchip_> ubitux: pp7=4, yes
[15:34] Action: microchip_ needs coffee
[15:34] <ubitux> fuck, i should have ported only pp7 then?
[15:35] <durandal_1707> no, all of them
[15:35] <ubitux> :(
[15:35] <wm4> still wonder why you bother with these filters
[15:36] <ubitux> wm4: because microchip_ use them, and because as you can see that's easier to port them than convince to drop them :)
[15:39] <microchip_> ubitux: i think spp is good enough, with a sower strength than 6. With 6, it tends to smudge a bit
[15:39] <durandal_1707> imho it would be much better to NIH rest of gimp stuf
[15:40] <ubitux> microchip_: did you try the different modes?
[15:40] <microchip_> no
[15:40] <ubitux> then what are you waiting for? :(
[15:43] <microchip_> ah, spp=6:0:4 looks pretty good to me
[15:43] <microchip_> not as blurry as it was
[15:46] <ubitux> using B-frames' QP you get good results?
[15:46] <ubitux> fun
[15:46] <ubitux> you're testing with mplayer or the port i did btw?
[15:46] <ubitux> (or the mp wrapper?)
[15:46] <microchip_> mplayer
[15:47] <ubitux> ok
[15:47] <microchip_> 6:0:5 looks slightly better (it's sharper)
[15:47] <ubitux> strange, it should be blurrier
[15:47] <microchip_> yes
[15:48] Action: microchip_ has to go :/
[15:48] <ubitux> hf, thx
[16:42] <khali> ok, I'm done
[16:43] <khali> almost all frames look much better with my new interpolation algorithm
[16:43] <khali> so I think I'm good to post
[16:44] <ubitux> khali: don't forget the fate test update
[16:44] <JEEBsv> Anyone has any comments on my attempt at writing a proper definition for the 'keyframe' flag in Matroska @ http://up-cat.net/p/7ad9092e ?
[16:47] <khali> ubitux: fate test? what is this?
[16:48] <ubitux> ffmpeg automated testing environment
[16:49] <ubitux> https://www.ffmpeg.org/fate.html
[16:49] <khali> ubitux: is this "make check" or something else?
[16:49] <ubitux> make fate
[16:49] <khali> FWIW "make check" fails for me even without any of my changes
[16:49] <ubitux> and more precisely fate-filter-delogo in your case i would guess
[16:51] <khali> ah, "make check" tests the installed ffmpeg, not the one in the build directory
[16:51] <khali> I didn't expect that
[17:31] <khali> ubitux: OK, I have the test suite in place and can see the failure with my changes
[17:31] <khali> ubitux: should I just apply the resulting diff to tests/ref/fate/filter-delogo?
[17:32] <ubitux> you will likely need apply the diff (make fate-filter-delogo|patch -p1), but make sure the resulting output is better
[17:32] <ubitux> you can make fate-filter-delogo V=1 to see what command is used
[17:36] <wm4> ubitux: I have a terrible idea to hack utf-16 support on top of ffmpeg's subtitle demuxers in mpv
[17:36] <wm4> ubitux: re-encode all input to ffmpeg :D
[17:39] <Daemon404> ok so
[17:39] <Daemon404> where IS the vsync algo located
[17:39] <Daemon404> i cant find it at all with grep
[17:41] <ubitux> Daemon404: git grep -i vsync 
[17:41] <ubitux> ’ ffmpeg_opt.c:    if      (!av_strcasecmp(arg, "cfr"))         video_sync_method = VSYNC_CFR;
[17:41] <Daemon404> already did that
[17:41] <ubitux> then git grep video_sync_method
[17:41] <Daemon404> i found nothing but changing nb_frames
[17:42] <Daemon404> and then a wall of code with a single "duplicate frames if needed" comment
[17:42] <ubitux> and then i see format_video_sync
[17:42] <ubitux> around line 820 in ffmpeg.c
[17:42] <Daemon404> already been there
[17:43] <Daemon404> tehres no obvious place where it has a sync alg
[17:43] <Daemon404> o
[17:43] <Daemon404> unelss its broken up between funcs
[17:43] <ubitux> dunno, i never used vsync
[17:43] <Daemon404> everyone i ask tells me they dont know
[17:43] <Daemon404> saste's explanation was "voodoo"
[17:44] <ubitux> wm4: when you have a good idea to add support in ffmpeg, feel free to share
[17:45] <Daemon404> oh lawd
[17:45] <Daemon404> nb_frames isnt ottal frames
[17:45] <Daemon404> it's applied to some section
[17:45] <Daemon404> good lord this wont be fun to figure out
[17:45] <Daemon404> also magic numbers
[17:45] <Daemon404> \o/
[17:50] <Daemon404> oh
[17:50] <Daemon404> yes it's splti between functions
[17:50] <Daemon404> awesome
[17:50] <ubitux> meh
[17:50] <ubitux> did i miss something?
[17:50] <Daemon404> [11:45] <@Daemon404> oh lawd
[17:50] <Daemon404> [11:45] <@Daemon404> nb_frames isnt ottal frames
[17:50] <Daemon404> [11:45] <@Daemon404> it's applied to some section
[17:50] <Daemon404> [11:45] <@Daemon404> good lord this wont be fun to figure out
[17:50] <Daemon404> [11:45] <@Daemon404> also magic numbers
[17:50] <wm4> you missed Daemon404 cursing
[17:50] <Daemon404> [11:45] <@Daemon404> \o/
[17:50] <Daemon404> this is why nobody understands the sync code except michael
[17:50] <Daemon404> :<
[17:50] <ubitux> <@ubitux> <@Daemon404> i found nothing but changing nb_frames // and sync_opts for the output stream depending on the mode  this was seen?
[17:50] <wm4> ubitux: well, I think you should do it like subreader.c and retry detection with utf-16le/be
[17:50] <Daemon404> ubitux, no
[17:52] <ubitux> wm4: yes, possibly the probing code could be re-run for subtitles formats with pre-proc re-encoding of the input
[17:54] <Daemon404> btw ubitux 
[17:54] <Daemon404> sync_opts is reused and modified in 3 places
[17:55] <Daemon404> yes. 'fun'.
[17:55] Action: Daemon404 always gets mad when he reads ffmpeg.c
[17:55] <wm4> ffmpeg.c is probably like mplayer.c
[17:55] <wm4> doing EVERYTHING
[17:55] <Daemon404> at least they split out opt parsing
[17:55] <Daemon404> to its own file
[17:56] Action: ubitux doesn't actually like that split
[17:56] <Daemon404> -_-
[17:56] <Daemon404> probably for some retarded reason
[17:56] <wm4> maybe a larger source file looks more impressive
[17:56] <wm4> *slander slander*
[18:00] <ubitux> Daemon404: i believe that split doesn't make much sense unless you have a stupid editor
[18:00] <Daemon404> ...
[18:00] <Daemon404> please
[18:00] <ubitux> compilation time shouldn't be relevant
[18:00] <Daemon404> ...
[18:01] <Daemon404> so yea
[18:01] <khali> ubitux: the delogo test case is so bad in the first place that I honestly can't judge my changes on it... so I'll just trust my own testing, and update the reference
[18:01] <Daemon404> [11:56] <@Daemon404> probably for some retarded reason
[18:01] <durandal_1707> compilation time does matter
[18:01] <Daemon404> because organization and logical units
[18:01] <Daemon404> who needs those?
[18:01] <Daemon404> MONOLITHIC FFMPEG.C FOR LIFE
[18:01] <durandal_1707> lets merge everything into ffmpeg.c
[18:01] <Daemon404> yeah
[18:01] <ubitux> Daemon404: that split doesn't make a better organization into logical units, it replaces 1 garbage into 3 garbages
[18:02] <Daemon404> all of teh opt parsing is in one file
[18:02] <Daemon404> taht is just about opt parsing
[18:02] <Daemon404> whats the problem?
[18:02] <ubitux> khali: ok
[18:02] <wm4> I agree that the splitted opt parsing is kind of hard to follow
[18:02] <ubitux> Daemon404: that's harder to follow when splitted
[18:02] <Daemon404> ...
[18:02] <ubitux> Daemon404: that said, i don't care much honestly
[18:02] <Daemon404> [12:02] <@ubitux> Daemon404: that's harder to follow when splitted
[18:02] <Daemon404> please
[18:02] <Daemon404> never develop anything
[18:02] <Daemon404> for people
[18:02] <Daemon404> again
[18:02] <Daemon404> ever.
[18:02] <ubitux> 18:02:24 <+wm4> I agree that the splitted opt parsing is kind of hard to follow
[18:02] <wm4> so there might be an underlying design problem if it can't be split well
[18:02] <wm4> which should be fixed
[18:03] <ubitux> Daemon404: that's not a general statement, that's a statement in this particular case
[18:03] <wm4> in general it's better to have small, self-contained source files
[18:03] <wm4> nobody would doubt that
[18:03] <Daemon404> anyway
[18:03] <wm4> also why does utils.c exist?
[18:03] <Daemon404> back to the issue at hand
[18:03] <ubitux> now we have 3 not small not self-contained source files
[18:04] <Daemon404> does /anybody/ have a good understanding of vsync
[18:04] <Daemon404> that can explain how it works overall
[18:04] <Daemon404> like.. .a single person?
[18:04] <Daemon404> i will patch docs if someone provides
[18:04] <Daemon404> because this is insane
[18:04] <ubitux> don't you have more specific questions?
[18:05] <Daemon404> ...
[18:05] <Daemon404> what is teh algo
[18:05] <Daemon404> and how does it work
[18:05] <Daemon404> its a pretty fuckin basic question
[18:05] <ubitux> there are different algo for each mode, i would guess
[18:06] <Daemon404> yes
[18:06] <Daemon404> but no
[18:06] <Daemon404> theyre all intertwined
[18:06] <Daemon404> with different magic numbers
[18:07] <ubitux> where do you think it mismatches with the doc?
[18:07] <Daemon404> the doc doesnt explain sht
[18:07] <Daemon404> shit
[18:07] <ubitux> i mean, "explain vsync to me" might be a basic question, but the answer might not :p
[18:07] <Daemon404> HOW
[18:07] <Daemon404> DOES
[18:07] <Daemon404> er
[18:07] <Daemon404> DO
[18:08] <Daemon404> THEY WORK
[18:08] <Daemon404> taht si the question
[18:08] <Daemon404> NOBODY seems to know
[18:08] <Daemon404> teh code seems to just exist
[18:08] <Daemon404> nobody wrote it
[18:08] <Daemon404> it just exists
[18:08] <Daemon404> im not asking WHAT each does
[18:08] <Daemon404> that is what teh docs say
[18:08] <Daemon404> im asking HOW
[18:10] <wm4> you'll have to reverse engineer it
[18:11] <Daemon404> wm4, it's harder to follow that c++ vtables decompield with hex rays
[18:11] <Daemon404> than*
[18:11] <wm4> get a closed source job, then
[18:13] <Daemon404> arg bit blame
[18:13] <Daemon404> ->
[18:13] <Daemon404>  avconv: refactor vsync code.
[18:13] <Daemon404> by anton
[18:13] <Daemon404> (surprisingly not diego)
[18:13] <ubitux> and unfortunately, with anton it's actually real refactoring
[18:13] <ubitux> and not a fancy alias for moving the code
[18:13] Action: wm4 gets popcorn
[18:14] <Compn> lets see 
[18:14] <Compn> vsync you say
[18:14] <Daemon404> ubitux, yes i cant use -w
[18:14] Action: Compn never used that option
[18:14] <ubitux> wm4: that was an indeed compliment
[18:14] <ubitux> Daemon404: -w doesn't deal with moves
[18:14] <Daemon404> it does help with copious whitespace changes
[18:14] <Daemon404> alla "K&R fixes"
[18:14] <Daemon404> which i usually hit
[18:16] <ubitux> (by refactoring being moving code i was more refering to 016c5b066d for example)
[18:16] <Compn> Daemon404 : you're asking how setting the delta and nb_frames changes the sync ?
[18:17] <Daemon404> ...
[18:17] <Daemon404> god dammit people
[18:17] <Compn> or how ffmpeg changes the sync with that
[18:17] <Daemon404> learn to english
[18:17] <ubitux> :))
[18:17] Action: Compn makes stuff up
[18:17] <Daemon404> Compn, im NOT askign such lwo leve lquestions
[18:17] <Daemon404> i masking teh actual vsync algo
[18:18] <Daemon404> not ho the 9 functions interact with eachotehr
[18:18] <Compn> AH
[18:18] <Daemon404> how. the. algo. actually. works.
[18:18] <Compn> er dumb caps lock
[18:20] <ubitux> Daemon404: well looking quickly at the code, i see 2 things: recomputing nb_frames (1 ’ copy dat frame, 0 ’ drop dat frame, 2+ ’ dup dat frames)
[18:20] <Daemon404> dont use var names
[18:20] <Daemon404> that is not an algorithm explanation
[18:21] <ubitux> and a sync_opts being a output pts (frame counter) for pts syncing
[18:21] <Daemon404> that is a low-level explanation
[18:21] <ubitux> and thus used in different places
[18:21] <Compn> ubitux : Daemon404 wants the actual equasion, possibly a flowchart?
[18:21] <Daemon404> i see no explanation of n algo
[18:21] <Daemon404> only a code to english tl
[18:21] <Daemon404> which is not what an algorithm is
[18:21] <Daemon404> :|
[18:22] <ubitux> not sure you can map that code into a real algorithm anyway
[18:22] <ubitux> that's mostly various heuristics afaict
[18:22] <Daemon404> figures
[18:22] <Daemon404> it's the Duct Tape & Hacks algo
[18:22] <Compn> Daemon404 : why do you want it? patent + rip it out of ffmpeg for your own project ?
[18:22] <ubitux> well, replace it with a clear water mathematical algorithm
[18:22] <Daemon404> ubitux, it's non-trivial to rip otu and repace
[18:22] <Daemon404> its spread across many funcs
[18:23] <ubitux> (Compn: i believe he just wants to understand it to fix something)
[18:23] <Compn> its obfuscated on purpose to keep out dirty stealing people
[18:23] <Compn> :P
[18:23] <Compn> ehehe
[18:23] <Daemon404> i like how its such a huge problem to even ask "how does ffmpeg decide to drop frames"
[18:23] <Compn> ubitux : (someone who cant find it, wont be able to fix it anyways)
[18:23] <Daemon404> ubitux, i am trying to make it stable across chunks
[18:23] <Daemon404> consistent
[18:23] <Daemon404> it currently isnt
[18:23] <Compn> did you go back into the version 1 o ffmpeg to find initial vsync commit ?
[18:24] <Compn> it probably hasnt changed much since 2000 :P
[18:24] <Daemon404> "initial commit" -- fabrice
[18:24] <Daemon404> ive actually hit that one before
[18:24] <Daemon404> i cried.
[18:24] <Compn> well that shrinks the code at least :D
[18:24] <Compn> ahah
[18:24] <Compn> try askin him ?
[18:24] <Compn> michael didnt start the project, cant blame him for everything!
[18:24] <Daemon404> i dont think fabrice wrote vsync
[18:24] <Compn> well it didnt wish itself into existence
[18:25] <Daemon404> meh
[18:25] <Daemon404> otehr parts of the vsync code map to freaking merge commits
[18:25] <Daemon404> with changes in the merge commtis themselves
[18:25] <Daemon404> -_-
[18:25] <Compn> yes the spaghetti history isnt helping anything
[18:25] <Compn> poisoning that well
[18:26] <ubitux> Daemon404: consider yourself on your own, and make something cool out of it ;)
[18:26] <Daemon404> the only thing i might make
[18:26] <Daemon404> is a dead body
[18:26] <Compn> when was -vsync added? in initial commit ?
[18:26] <Daemon404> Compn, i dont kno
[18:26] <Daemon404> because teh history is fucked
[18:26] <ubitux> i don't think looking at the original vsync code would really help
[18:26] <Daemon404> that too
[18:27] <Compn> ubitux : at least we could ask original author about it
[18:27] <Compn> for the original algo
[18:27] <durandal_1707> git log -p -m --follow --min-parents=1 --graph --stat --format=fuller
[18:27] <Daemon404> i somewhat doubt it was designed
[18:28] <Daemon404> durandal_1707, that is am impressive list of args
[18:28] <Daemon404> an*
[18:28] <ubitux> -M
[18:28] <Compn> i find it difficult to believe that someone added frame dropping code so many times in seperate funcs that it came together to be a vsync
[18:28] <Daemon404> "timestamp discontinuity correction try #1"
[18:28] <Compn> its possible i guess
[18:28] <Daemon404> next oen i found
[18:28] <Compn> lol
[18:28] <Daemon404> Compn, are you sure?
[18:29] <Daemon404> look at that message!
[18:29] <Compn> its a poor commit message!
[18:29] <Daemon404> >try #1
[18:29] <Compn> you just give it the wrong connentation
[18:29] <Daemon404> >#1
[18:29] <Compn> hmm
[18:29] <Compn> is there a try #2 ?
[18:30] <Daemon404> no idea
[18:30] <Daemon404> this is back from the old days
[18:30] <Daemon404> ~r3000
[18:30] <Compn> did we ever vote on the best commit message ?
[18:30] <Compn> funniest ?
[18:30] Action: ubitux likes the commit message ";"
[18:31] <Compn> where to even find commits from 2001-2004 ?
[18:31] <Compn> i mean -cvslog 
[18:31] <ubitux> 2003
[18:31] <ubitux> anyway,
[18:31] Action: ubitux &
[18:31] <Compn> Daemon404 : whats worse, the api renames/refactorings or the history poisoning ?
[18:31] <Compn> Daemon404 : http://lists.ffmpeg.org/pipermail/ffmpeg-cvslog/2005-April/000072.html
[18:32] <Daemon404> Compn, combining them
[18:32] <Daemon404> is worse.
[18:32] <wm4> looked at the initial revision... all the code was in the source dir named "libav"
[18:32] <wm4> haha
[18:32] <Daemon404> i think vsync is like c++
[18:32] <Daemon404> no one man understands all of it
[18:34] <Compn> but i'm serious, is the sourceforge mailing list archive still there ?
[18:35] <Compn> forgot my sourceforge login :\
[18:35] <Daemon404> sf.net feels liek a ghetto
[18:35] <Daemon404> nowadays
[18:35] <Daemon404> their ML archives are so bad
[18:35] <Compn> http://sourceforge.net/mailarchive/forum.php?forum_name=ffmpeg-cvslog
[18:35] <Compn> it does
[18:36] <durandal_1707> ubitux: there is such commit message ";" ?
[18:36] <wm4> wow so many mini commits
[18:36] <ubitux> durandal_1707: yes ;)
[18:36] <Daemon404> it's almost as if michael is a large contributer
[18:37] <wm4> this worsens my opinion about a certain fork's opinion about him
[18:38] <Daemon404> no opinion on any side is without merit
[18:38] <nevcairiel> you didnt know that he wrote like half of it ? :p
[18:38] <Daemon404> insanity everywhere
[18:38] <Compn> worsens your opinion of their opinion ... what
[18:38] <Compn> nevermind, dont care
[18:39] <Compn> cant access sourceforge mailing list without my login huh
[18:39] <Compn> :\
[18:39] <nevcairiel> i logged in, and it still doesnt give me the list :D
[18:39] <Compn> it wasnt called ffmpeg-svnlog or anything
[18:39] <Compn> does anyone have those archives ?
[18:39] <Daemon404> it's called cvslog even to this dya
[18:39] <Daemon404> for the git log
[18:40] <Compn> gmane has it
[18:40] <Compn> er nope
[18:41] <Compn> sourceforge screewed us!
[18:41] Action: Compn afk
[21:19] <BBB-work_> hey guys, can I use a -vf scale=-1:360 style commandline that makes sure w is not odd?
[21:19] <BBB-work_> if for whatever reason I want to do that
[21:20] <Daemon404> you can ue the eval stuff
[21:20] <Daemon404> (x/2)*2
[21:20] <Daemon404> lol.
[21:21] <BBB-work_> but how does that work if it's -1?
[21:22] <Daemon404> i dont know what -1 does, but it certainly could be emulated via eval
[21:22] <BBB-work_> -vf scale=-1:360;w=(w+1)/2*2?
[21:22] <Daemon404> wha does -1 do
[21:23] <Compn> keeps the correctly scaled res or something
[21:24] <nevcairiel> that would've been my guess
[21:24] <Compn> mplayer has had that syntax for years
[21:24] <Daemon404> -vf scale=trunc((((oh*iw)/ih)*sar)/2)*2:360
[21:24] <Daemon404> enjoy your AIDS
[21:25] <Compn> BBB : it shouldnt be hard to code up if its not possible  . better ask ubitux / saste
[21:25] <Compn> Daemon404 : hows vsync going ? learn anything new ?
[21:25] <Daemon404> pretty sure i just pasted exactly that
[21:25] <wm4> I hate this syntax
[21:25] <Compn> Daemon404 : well i thought you just made something up :P
[21:25] <Daemon404> Compn, i leaned fuck vsync and use -vf fps instead
[21:26] <Compn> lol\
[21:26] <Compn> does vsync actually work ?
[21:26] <Daemon404> for varyng definitions of work
[21:26] <Compn> wm4 : the -1 ?
[21:26] <Compn> work , as in , fix one sample ?
[21:26] <wm4> all aspects of it
[21:26] <Compn> wm4 : curious what syntax you would like
[21:27] <Compn> i'm guessing mixing aspect into scale ?
[21:27] <BBB-work_> that doesn't scale at all
[21:27] <Daemon404> BBB-work_, ?
[21:27] <BBB-work_> that trunc thing just scales to 1920x1080
[21:27] <Daemon404> thats not even possible
[21:27] <Daemon404> it has :360
[21:28] <BBB-work_> I know
[21:28] <BBB-work_> it just completely ignores it
[21:28] <Compn> are you supposed to use "quotes" around it ?
[21:28] <Compn> Daemon404 : paste your ffmpeg output to prove it works.... :P
[21:28] <Daemon404> ffmpeg -i obama.mov -vf scale'=trunc((((oh*iw)/ih)*sar)/2)*2:360' herp.avi
[21:29] <Daemon404> in:
[21:29] <Daemon404>     Stream #0:1(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1248x702, 4840 kb/s, 30.12 fps, 30.12 tbr, 5994 tbn, 11988 tbc
[21:29] <Daemon404> out:
[21:29] <Daemon404>     Stream #0:0(und): Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 640x360, q=2-31, 200 kb/s, 30.12 tbn, 30.12 tbc
[21:29] Action: Compn sees the '' 's
[21:29] <Daemon404> thats not related to ffmpeg
[21:29] <Daemon404> thats shell stuff
[21:29] <Compn> well sometimes you have to explain bash rules to experienced developers
[21:30] <Daemon404> it wouldnt do what BB said
[21:30] <Daemon404> because it wouldnt run
[21:30] <Daemon404> it would fail with a parsing error
[21:30] <BBB-work_> -vf scale='scale=trunc((((oh*iw)/ih)*sar)/2)*2:360'
[21:30] <Daemon404> -bash: syntax error near unexpected token `('
[21:30] <BBB-work_> Stream #0.0(eng): Video: rawvideo, yuv420p, 1920x1080, q=2-31, 200 kb/s, 90k tbn, 25 tbc
[21:30] <Daemon404> BBB-work_, why do you have two scales
[21:30] <Compn> ...
[21:30] <BBB-work_> typo
[21:31] <BBB-work_> one scale gives same error :)
[21:31] <BBB-work_> or well, not error
[21:31] <BBB-work_> "problem"
[21:31] <Daemon404> ... you know
[21:31] <Daemon404> this probably wont work with libav
[21:31] <Daemon404> if you think you can use avconv.
[21:31] <BBB-work_> -vf scale=-1:360 gives me
[21:31] <Compn> ohhh
[21:31] <BBB-work_> Stream #0.0(eng): Video: rawvideo, yuv420p, 640x360, q=2-31, 200 kb/s, 90k tbn, 25 tbc
[21:31] <BBB-work_> no I'm using ffmpeg
[21:31] <Daemon404> how old?
[21:31] <BBB-work_> pfffff... dunno recent enough
[21:31] <Daemon404> can you paste teh whoel cmd
[21:32] <Compn> btw it works for me
[21:32] <Daemon404> maybe something is interfering
[21:32] <Compn>  Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 490x360
[21:32] <BBB-work_> hm newer version works
[21:32] <BBB-work_> wtf
[21:32] <BBB-work_> old buggy crappy version I guess
[21:32] <Daemon404> thats probably why
[21:32] <Daemon404> eval isnt new... but it's nto ancient either
[21:32] <Daemon404> not*
[21:33] <Compn> raw 1080? thats some big file
[21:33] <Compn> 200kb/s not big ... hmm
[21:33] <Daemon404> could be piping
[21:34] <Daemon404> and 200 kb/s is wrong
[21:34] <Daemon404> ffmpeg cli output is shitty
[21:36] <Compn> why did i get a battle.net message in korean hmm
[22:10] <ubitux> BBB-work_: another funny trick: -vf "scale='bitand(oh*iw/ih,-2)':360"
[22:11] <ubitux> Daemon404: i wonder if you will stop complaining for nothing at some point ;)
[22:11] <Daemon404> 'for nothing' ?
[22:11] <ubitux> you sound like an annoying girl, or a french guy
[22:11] <Daemon404> no they are all valid complaints
[22:11] <Daemon404> and you all sound liek cult members
[22:11] <Daemon404> having drunk the ffmpeg kool aid
[22:11] <durandal_1707> ubitux: you aren't french guy?
[22:11] <ubitux> durandal_1707: yes :D
[22:12] <ubitux> Daemon404: you don't like it, but eval is pretty nice
[22:12] <Daemon404> ?
[22:12] <ubitux> you just refuse to recognize the awesomeness
[22:12] <Daemon404> where i i complain about eval
[22:12] <Daemon404> are you sure youre reading what I wrote?
[22:12] <wm4> ffkoolaid (explodes if you don't provide input padding)
[22:13] <ubitux> Daemon404: maybe i misread :)
[22:13] <Daemon404> the AIDS quip was referring to my solution
[22:13] <Daemon404> (*2)/2 is a kludge
[22:13] <ubitux> bitand() is better :D
[22:13] <Daemon404> lawl
[22:15] <durandal_1707> isn't there some example in documentation?
[22:15] <ubitux> for that case, i don't think so
[22:15] <Daemon404> i'd think it's a pretty common use case
[22:15] <Daemon404> for anything 4:2:0
[22:15] <durandal_1707> there is hsub case, which is almost same thing
[22:20] <durandal_1707> is there way too hide -configure spam from every ffmpeg output, its spamming terminal...
[22:21] <Daemon404> 'every' ?
[22:21] <nevcairiel> use simpler configure lines :D
[22:21] <Daemon404> or avconv
[22:21] <Daemon404> :P
[22:21] <Daemon404> (they hide it)
[22:21] Action: Daemon404 runs
[22:22] <durandal_1707> also if one enables only audio stuff, ffmpeg is not build as it needs swscale, which is lame
[22:22] <nevcairiel> yeah thats rather annoying
[22:22] <Daemon404> convert your audio to rgb
[22:23] <Daemon404> synesthesia
[22:24] <durandal_1707> nevcairiel: enabling less stuff helps when working on something, no need to recompile bunch of other stuff you never use, and it saves memory
[22:24] <Daemon404> use ccache
[22:24] <Daemon404> duh
[22:25] <nevcairiel> i never was a big fan of ccache
[22:25] <Daemon404> i used it extensively for work for a while
[22:25] <Daemon404> at my old job
[22:25] <nevcairiel> but i also usually have very fast computers so the effect is mitigated a bit
[22:25] <Daemon404> the problem actually became i/o
[22:25] <Daemon404> ccache being i/o bound
[22:25] <Daemon404> :D
[22:31] <ubitux> 22:21:50 <@Daemon404> (they hide it) // while as an option it's nice, having those info is extremely useful when dealing with users output
[22:32] <ubitux> and i'm pretty happy we didn't drop it by default
[22:32] <durandal_1707> can i use macro inside macro?
[22:32] <ubitux> durandal_1707: define a define, no
[22:33] <ubitux> but you can call macro inside macro yes
[22:33] <Daemon404> careful.
[22:33] <Daemon404> there are reprocussions
[22:33] <durandal_1707> yes i mean use ...
[22:33] <ubitux> i personally love to nest at least 3 macro level to piss off Daemon404 
[22:34] <Daemon404> nno i meant real problems
[22:34] <Daemon404> im finding you a relevant has
[22:34] <Daemon404> h
[22:34] <nevcairiel> parameter expansion can go funny if its not properly managed
[22:36] <Daemon404> god dammit
[22:36] <Daemon404> i hit yet anotehr diego code shuffle
[22:36] <nevcairiel> haha
[22:38] <durandal_1707> merges should be abandoned and instead cherry pick deployed
[22:38] <Daemon404> that wouldnt help
[22:39] <Daemon404> anyway
[22:39] <Daemon404> 0db2d94280e260af5f3ad7993c5a6357462f17c9
[22:39] <Daemon404> is the relevant hash
[22:39] <Daemon404> turns out it's related to variadic macro expansion only
[22:43] <saste> can i create simple widgets through lua?
[22:43] <saste> http://lua-users.org/wiki/GraphicalUserInterfaceToolkits
[22:43] <saste> any first hand experience to share?
[22:44] <Daemon404> kind of a pain when i did
[22:44] <Daemon404> i ended up using python and pyside
[22:44] <nevcairiel> i like the simplicity of Lua, but i've never used it with a window toolkit
[22:45] <saste> pain? in which sense?
[22:45] <Daemon404> stuff not working, outdated, documentation nonexisting
[22:45] <Daemon404> this was 2-3 year ago
[22:45] <saste> it turns out that lua scripting would end up like some serious C API binding, something like it is done in VLC
[22:46] <Daemon404> yes
[22:46] <saste> choosing another language should be still possible
[22:46] <wm4> are you eying lua for libavfilter?
[22:46] <nevcairiel> lua is a good choice for adding scripting to some app, easy to use and rather lightweight
[22:46] <saste> otoh i see that VLC adopted lua also for providing customized controls/widgets
[22:47] <saste> wm4, i actually already started
[22:47] <wm4> awesome
[22:47] <Daemon404> it seems mroe logic to extend lua with lavfi
[22:47] <saste> but i need to map a good part of the ffmpeg API
[22:47] <Daemon404> than to extend lavfi with lua
[22:47] <Daemon404> imho
[22:47] <Daemon404> logical*
[22:47] <wm4> Daemon404: that sounds right
[22:48] <saste> Daemon404, I need both
[22:48] <saste> i'll create a module from which i can call ffmpeg API (e.g. imgutils, sound utils etc.)
[22:49] <saste> and another module which allows to call internal lavfi API
[22:49] <wm4> you probably don't want to bind ffmpeg API directly...
[22:49] <wm4> and rather provide something high level
[22:49] <Daemon404> hi
[22:49] <Daemon404> ffms2
[22:49] <Daemon404> it exists
[22:49] <Daemon404> and can be used from lua
[22:49] <Daemon404> via vapoursynth
[22:49] Action: Daemon404 runs
[22:49] <durandal_1707> hi
[22:49] <durandal_1707> i
[22:49] <durandal_1707> do
[22:50] <durandal_1707> not
[22:50] <durandal_1707> want
[22:50] <durandal_1707> to
[22:50] <durandal_1707> use
[22:50] <durandal_1707> vapoursynth
[22:50] <Daemon404> NIH NIH NIH NIH
[22:50] Action: durandal_1707 runs
[22:50] <wm4> saste: but what does GUI widgets have to do with that?
[22:50] <saste> wm4, custom GUI for ffplay for example
[22:50] <wm4> also, where does VLC allow custom widgets via Lua?
[22:50] <saste> you want a knob to control volume
[22:50] <wm4> why does ffplay need a custom GUI
[22:51] <saste> a knob for controlling brightness and so on...
[22:51] <nevcairiel> ffplay has a GUI?
[22:51] <nevcairiel> :)
[22:51] <saste> or you could tweak QP during encoding with ffmpeg
[22:52] <wm4> interactive encoding, huh
[22:52] <saste> the alternative is to code the GUI, which needs recompilation and is not very flexible
[22:52] <Daemon404> wm4, you knwo what else used to do that?
[22:52] <saste> scripting looks like the right solution
[22:52] <Daemon404> sny's h264 encoder
[22:52] <Daemon404> cause it had no ratecontrol
[22:52] <saste> same for custom logic in filters
[22:52] <wm4> manual ratecontrol?
[22:52] <saste> which you don't want to code in C
[22:52] <Daemon404> wm4, yea
[22:52] <wm4> wow
[22:53] <nevcairiel> apparently quite a bunch of professional encoders allow such very detailed control over the encoding process, or so the discussion on doom9 went
[22:53] <Daemon404> nevcairiel, allow?
[22:53] <Daemon404> no.
[22:53] <Daemon404> require.
[22:53] <Daemon404> i mean x264 allows it
[22:53] <Daemon404> if you really want.
[22:53] <nevcairiel> didnt sound like that in the discussions
[22:55] <Daemon404> nevcairiel, the anime pedants use it
[22:55] <Daemon404> in x264, ofc.
[22:56] <cone-14> ffmpeg.git 03Paul B Mahol 07master:0354bc39eb3e: fate: wavpack: add more dependencies
[22:56] <cone-14> ffmpeg.git 03Paul B Mahol 07master:df084adbf730: doc/general: s/Libav/FFmpeg
[22:59] <nevcairiel> can x264 even offer such interactive control? Or do i encode, find weakness, adjust params, and try again? :p
[22:59] <nevcairiel> i haven't seen anything in x264 that can make that interactive
[23:05] <ubitux> La stLa   Lasst t message repeamessagmessae trepeatege d 2 edreti mes2 pt
[23:05] <ubitux> imes
[23:05] <ubitux> lol
[23:06] <ubitux> sounds like a threading problem
[23:13] <Daemon404> [16:59] <+nevcairiel> can x264 even offer such interactive control? Or do i encode, find weakness, adjust params, and try again? :p <-- x264cli would need to be a separate encode
[23:13] <Daemon404> libx264 certainly can
[23:13] <Daemon404> i think
[23:23] <saste> SWIG is sexy...
[23:25] <durandal_1707> ?
[23:26] <saste> durandal_1707, http://www.swig.org/Doc2.0/Introduction.html#Introduction_nn2
[23:43] <ubitux> durandal_1707: did you progress with your encoder?
[23:51] <saste> j-b: any specific reasons you didn't consider swig in VLC?
[23:51] <saste> or should i ask on #videolan?
[23:53] <j-b> saste: swig for? bindings?
[23:53] <saste> j-b: yes
[23:53] <saste> I'm looking through your modules/lua implementation, and I understand the C->lua conversion was mostly done by hand
[23:54] <saste> i'm going to do something similar for ffmpeg, and I'm considering to use SWIG instead, with the advantage to be more automated and support many languages
[23:54] <j-b> saste: http://git.videolan.org/?p=vlc/vlc-darthgandalf.git;a=summary
[23:56] <saste> j-b: does it mean you're migrating to SWIG?
[23:57] <j-b> migrating?
[23:57] <j-b> that would mean we have something already
[23:57] <saste> j-b, is that the long term plan?
[23:58] <saste> or are you just fine with your lua bindings?
[23:58] <j-b> lua is VLC scripting.
[23:58] <j-b> internal and such
[23:58] <j-b> SWIG is for libVLC
[23:59] <saste> j-b, ok
[23:59] <saste> what was the outcome of the gsoc task, in short?
[23:59] <saste> so I also get an idea how much work it could imply
[00:00] --- Wed Jun 12 2013