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

[burek]

[00:00] <tab> and the binaries link to it
[00:00] <ubitux> if it works without the patch your test case is not really interesting
[00:01] <tab> without the patch it detects iconv and compiles up until linking ffmpeg, then the linker fails
[00:02] <ubitux> ok, and after the patch --enable-iconv has no effect? or maybe configure stops you?
[00:03] <tab> no after it still detects it and succeeds to link iconv
[00:03] <tab> everything works
[00:04] <ubitux> wtf
[00:04] <ubitux> i wonder how this is possible
[00:05] <tab> idk
[00:05] <ubitux> tab: grep ICONV config.h
[00:05] <ubitux> do you indeed have "#define CONFIG_ICONV 1"?
[00:05] <tab> the only difference is the placement of -liconv but they should have the same result
[00:06] <tab> yeah
[00:06] <ubitux> ._.
[00:06] <ubitux> rm -f ffmpeg{,_g} && make ffmpeg V=1
[00:06] <ubitux> can you paste me this?
[00:10] <tab> before patch: clang -Llibavcodec -Llibavdevice -Llibavfilter -Llibavformat -Llibavresample -Llibavutil -Llibpostproc -Llibswscale -Llibswresample -Wl,-dynamic,-search_paths_first  -o ffmpeg_g ffmpeg_opt.o ffmpeg_filter.o ffmpeg.o cmdutils.o  -lavdevice -lavfilter -lavformat -lavcodec -lswresample -lswscale -lavutil -L/opt/local/lib -lSDLmain -Wl,-framework,AppKit -lSDL -Wl,-framework,Cocoa -liconv -lm -lbz2 -lz
[00:10] <tab> after: clang -Llibavcodec -Llibavdevice -Llibavfilter -Llibavformat -Llibavresample -Llibavutil -Llibpostproc -Llibswscale -Llibswresample -Wl,-dynamic,-search_paths_first  -o ffmpeg_g ffmpeg_opt.o ffmpeg_filter.o ffmpeg.o cmdutils.o  -lavdevice -lavfilter -lavformat -lavcodec -lswresample -lswscale -lavutil -liconv -L/opt/local/lib -lSDLmain -Wl,-framework,AppKit -lSDL -Wl,-framework,Cocoa -lm -lbz2 -lz 
[00:15] <tab> let me see how libavcodec/utils.c is being compiled in either case
[00:23] <tab> nevermind the only difference is that linker command
[00:24] <ubitux> mmh
[00:25] <ubitux> so that creates two interrogation
[00:26] <ubitux> just one in fact
[00:26] <ubitux> why it didn't worked with BBB and the other users when they moved the -liconv before the -L/opt/...
[00:26] <ubitux> but well ok
[00:26] <ubitux> tab: thx for your testing
[00:27] <tab> probably different version of clang/os x
[00:27] <tab> but that shouldn't matter
[00:28] <tab> also LIBRARY_PATH/INCLUDE_PATH
[00:47] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:058e1f8dd71b: vc1dec: odd sized sprites are unsupported
[01:08] <ubitux> michaelni: is there any frame prediction or anything in ffv1 or huffyuv?
[01:11] <ubitux> because i tried this: for c in copy huffyuv ffv1 libx264; do ffmpeg -nostats -loop 1 -i image.png -i input.mp3 -shortest -c:v $c -c:a copy -y test-$c.mkv; done
[01:11] <ubitux> and this is the result:
[01:11] <ubitux> -rw-r--r-- 1 ubitux ubitux 410M Mar  6 01:10 test-copy.mkv
[01:11] <ubitux> -rw-r--r-- 1 ubitux ubitux 231M Mar  6 01:11 test-ffv1.mkv
[01:11] <ubitux> -rw-r--r-- 1 ubitux ubitux 311M Mar  6 01:10 test-huffyuv.mkv
[01:11] <ubitux> -rw-r--r-- 1 ubitux ubitux 1.8M Mar  6 01:11 test-libx264.mkv
[01:11] <ubitux> (with -qp 0, test-libx264.mkv because 2.4M, still waaay smaller)
[01:12] <ubitux> i guess ffv1 is intra only?
[01:12] <ubitux> (like the others)
[01:12] <ubitux> ^because^becomes
[01:24] <kierank> ubitux: looks wrong
[01:24] <kierank> probably settings aren't being propagated to x264 correctly
[01:24] <ubitux> what's wrong?
[01:24] <ubitux> libx264 is the sanest output
[01:24] <ubitux> :D
[01:25] <kierank> what kind of file is it?
[01:25] <kierank> input
[01:25] <ubitux> ffmpeg -i tests/lena.png image.png
[01:25] <kierank> ah
[01:25] <ubitux> and a random mp3 of about 1 or 2 min long
[01:25] <kierank> oh i see x264 is using inter
[01:25] <kierank> so basically it's all skips
[01:25] <ubitux> yes, it's doing the smart thing you're expecting
[01:26] <kierank> but intra only you'll get similar results
[01:26] <ubitux> yes but i don't want to :p
[01:26] <ubitux> i want OTOH that ffv1 for instance does a similar thing
[01:29] <kierank> ok
[01:32] <michaelni> ubitux, if you want to add motion compensation to ffv1, i guess noone would be unhappy
[01:32] <ubitux> i was just surprised it doesn't have it :)
[01:49] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:7bab631f7df5: mss2dsp/upsample_plane: fix 0x0 handling
[02:26] <Compn> ... 'not content with screwing up the audio side of linux, ubuntu now takes aim at the video display'
[02:52] <highgod> Compn:are you online?
[02:56] <Compn> yes?
[03:06] <highgod> I send you the binary file of mpc,but it si to big, it is uploading now
[03:06] <highgod> the binary is compiled by us
[03:20] <Compn> ok
[03:51] <highgod> Compn:I have sent it to you,check your mail
[04:00] <Compn> highgod : ok
[04:07] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:bb01be80462a: rv20: Fix handling of frame skip.
[05:36] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:5c8ffbaa7fe7: qdm2: simplify arithmetic coder tables generation
[05:36] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:a3541896c6f4: qdm2: check "AC" codewords
[05:43] <cone-714> ffmpeg.git 03Reimar Döffinger 07master:940b06aeb892: kgv1dec: Simplify kega decoding by using memcpy instead of loops
[05:43] <cone-714> ffmpeg.git 03Carl Eugen Hoyos 07master:96d2e4d61a51: Use uint8_t instead of uint16_t pointer in kega decoder.
[05:43] <cone-714> ffmpeg.git 03Carl Eugen Hoyos 07master:b45e85ab7e5e: Make 32bit zmbv colour-space opaque.
[05:43] <cone-714> ffmpeg.git 03Carl Eugen Hoyos 07master:34e7a3d74cce: Move the iconv test to the bottom of configure.
[05:43] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:28adecf0fa1f: Merge remote-tracking branch 'cehoyos/master'
[10:40] <cone-791> ffmpeg.git 03Diego Biurrun 07master:c57a59367030: hwaccel: consistent name prefixes for start_frame/end_frame/decode_slice
[10:40] <cone-791> ffmpeg.git 03Michael Niedermayer 07master:baf10ad186ed: Merge remote-tracking branch 'qatar/master'
[11:35] <cone-791> ffmpeg.git 03James Zern 07master:1811f1d84079: libopusenc: use ff_alloc_packet2
[11:38] <durandal_1707> michaelni: there is strange comment on ticket 2255
[11:43] <durandal_1707> How to programmatically get directshow devices with ffmpeg?
[11:55] <cone-791> ffmpeg.git 03Paul B Mahol 07master:037adf589a8e: libilbc: use ff_alloc_packet2
[11:58] <durandal_1707> the cover hack also leaks memory
[12:07] <ubitux> what about the alac memleak?
[12:28] <durandal_1707> ubitux: that is what i said, it leaks in cover art
[12:28] <ubitux> ok
[12:32] <durandal_1707> michaelni: how easy & smart is to use existing huff code in lavc for piz exr huffman stuff?
[13:12] <burek> what does "PES packet size mismatch" usually mean? is it a damaged input or something? -> http://ffmpeg.gusari.org/viewtopic.php?f=11&t=853
[13:14] <av500> burek: yes, can be some currupted packets
[13:15] <burek> ok, thanks :)
[13:30] <michaelni> durandal_1707, i didnt look at piz-exr but most code uses get_vlc* when readimng huffman coded codewords
[13:32] <durandal_1707> this one just do wavelet transform and than compress it with huffman
[13:37] <durandal_1707> and huff code seems to do much more, i fail to see how i could make use of it
[13:47] <burek> how can i search ffmpeg-devel ML to find a thread that I don't know in which particular month it was active?
[13:47] <av500> google?
[13:48] <Compn> search term inurl:ffmpeg-devel site:ffmpeg.org
[13:52] <cone-791> ffmpeg.git 03Michael Niedermayer 07master:2dd2ee96eb95: vc1dec: use av_log_ask_for_sample for odd sprites
[13:52] <burek> you're kidding right? it has got no search at all? :(
[13:53] <ubitux> gmane maybe
[13:53] <michaelni> or your MUAs search function
[13:54] <av500> burek: use google, it reads all mailing lists
[13:55] <burek> ok, I'll try all the suggestions, thanks
[13:56] <Compn> download all .gz archives and grep them ?
[13:56] <Compn> hehe
[13:57] <Compn> there is no search built into pipermail (or enabled by ffmpeg/mplayer anyways0
[14:01] <burek> I was going to propose a setup of a VM which would have linux 32/64, win 32/64 on it and would be configured to do automated static builds of ffmpeg
[14:01] <burek> since the machine i configured for such things is going down frequently due to power outages and it drives me crazy now :)
[14:01] <michaelni> Compn, maybe you should add a link to some ML search method gmane or whatever on our mailing lists page ?
[14:05] <Compn> michaelni : sounds like a good idea.
[14:05] <Compn> ffmpeg-ml custom google search and gmane search box
[14:06] <Compn> burek : didnt someone float that idea based on the FATE boxes? e.g. they compile ffmpeg every couple hours
[14:06] <Compn> they can output static binaries too...
[14:06] <burek> that would be even more great!
[14:06] <burek> but I think they are not quite suited for that
[14:07] <burek> although I might be wrong
[14:07] <Compn> they dont compile in external libs, so yeah
[14:07] <burek> yes
[14:19] <av500> burek: make sure you serve binary builds of ffmpeg from a patent-averse jurisdiction
[14:20] <burek> well, they are all gpl libs, is there anything to be worried about?
[14:20] <burek> those*
[14:21] <av500> codec patents
[14:34] <Compn> he means mpegla licenses
[14:34] <Compn> but i think it only applies to commercial things
[14:34] <Compn> who knows
[14:35] <av500> no
[14:56] <JEEB> indeed, MPEG-LA wants you to license those things no matter how you are giving out the binaries (source code is all good in their game afaik)
[14:56] <JEEB> and VIA licensing for aac and so forth
[14:57] <JEEB> naturally, MPEG-LA f.ex. won't take you money until you distro over X things (that X being in the thousands IIRC), but with open source software and free downloads that can go over pretty quickly
[15:01] <av500> you can aks j-b how many nice letters he gets for hosting VLC binaries
[15:02] <JEEB> those methinks mostly come from the D companies, though. Which I forgot to mention.
[15:02] <JEEB> so yeah
[15:03] <JEEB> MPEG-LA generally is not going against people unless they're making money and in their juristiction
[15:03] <JEEB> but then there are the D companies 8)
[15:04] <av500> yes
[15:05] <Compn> doh'by
[15:06] <JEEB> and duh'tee'ass
[15:10] <burek> i give up
[15:10] <burek> https://ffmpeg.org/trac/ffmpeg/ticket/2332#comment:1
[15:10] <burek> i wont submit any more bug tickets
[15:10] <burek> i was willing to do this task myself
[15:10] <burek> but i just get bounced every time i submit any ticket
[15:10] <burek> so, it's easier just not to use bug trac any more
[15:11] <burek> for me.
[15:14] <tab> i think technically you'd end up violating either the patent license or the (l)gpl to distribute from a territory that recognizes the patent license
[15:25] <michaelni> burek, https://ffmpeg.org/trac/ffmpeg/ticket/2332#comment:3
[15:26] <burek> I have a will to update the docs regarding this issue
[15:27] <av500> send a patch :)
[15:27] <burek> I'm just not sure if others agree with it, but it seems to me that it should be done in such a way
[15:27] <burek> because it will be more clear to read
[15:27] <burek> av500, no problem, it's just not very motivating when i prepare the patch and everything, just to get bounced in a fashion like "it's not needed" or such
[15:27] <michaelni> i think if X is default then noX should be documented/grepable 
[15:27] <burek> that's why i first created the ticket
[15:28] <burek> i stated also the reason why i think like that (from user's perspective)
[15:28] <av500> yes, but the ticket does not get the same eyeballs
[15:29] <durandal_1707> cehoyos is just afraid of open bugs - they are torturing him in dreams
[16:43] <cone-791> ffmpeg.git 03Michael Niedermayer 07master:188c08247742: snowenc: initialize edges
[17:01] <cone-791> ffmpeg.git 03Nicolas George 07master:87a954d6f4e3: lavf/concat: document the use of the files durations.
[19:31] <michaelni> I think the gsoc page needs some love/work ...
[19:32] <michaelni> Daemon404, do you want to mentor something ?
[19:33] <michaelni> hey beastd 
[19:33] <beastd> hi
[19:33] <michaelni> do you want to mentor something?
[19:33] <michaelni> or help improve the gsoc page ?
[19:33] <beastd> didn't have time to think about that. will look right now.
[19:34] <michaelni> its current state is not acceptable
[19:34] <Daemon404> michaelni, i dont mind mentoring something.
[19:35] <michaelni> Daemon404, please add yourself together with a task you want to mentor to the gsoc page then
[19:35] <michaelni> http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_of_Code_2013
[19:38] <michaelni> mateo`, Tjoppen, TimNich do you mxf experts want to mentor something ? if so please add yourself to the gsoc page (there should be a mentor and a backup mentor at least)
[19:39] <michaelni> bcoudurier, want to mentor something for gsoc ? if so please add yourself to the gsoc page
[19:40] <michaelni> and everyone else, want to mentor something? if so please add yourself to the gsoc page
[19:40] <michaelni> yourself with the task to mentor + suggested qualification task for it that is
[19:41] <michaelni> want to be backup mentor? dont hesitate to add yourself as backup mentor then!
[19:43] <cone-791> ffmpeg.git 03Michael Niedermayer 07master:70a2a4934a51: snowenc: add forgotten emms_c()
[19:43] <cone-791> ffmpeg.git 03Michael Niedermayer 07master:a3e0fc9803a6: snowenc: fix indention
[19:43] <cone-791> ffmpeg.git 03Ronald S. Bultje 07master:c257fe1fdee5: Move ff_cropTbl and ff_zigzag_direct from dsputil to mathtables.
[19:58] <beastd> hmm, currently some tasks are missing the mentor information.
[20:16] <ubitux> saste: should we split the lavfi entry into multiple tasks?
[20:16] <ubitux> typically we could have different mentors for different filters
[20:17] <ubitux> i'm adding myself as a backup mentor for lavfi, but i would be happy to be the main mentor for some specific filters (such as porting eq2), or backup mentor for some other
[20:17] <ubitux> Daemon404 could be the mentor for an ivtc port too :-°
[20:25] <ubitux> btw, http://lucy.pkh.me/ffvintage.webm
[20:26] <ubitux> (improved settings compared to last time)
[20:26] <durandal_1707> poring single filter as gsoc task is too easy, you need something to work on for 3 month
[20:27] <ubitux> i think an ivtc filter can occupy the student for 3 month
[20:27] <ubitux> especially given the number of broken input we can come up with
[20:29] <gnafu> It's like, I love listening to a cappella groups, but I hate watching them.
[20:29] <beastd> ubitux: maybe it is easier keeping it a in a collection task and mentors be react depending on demand/number of students?
[20:31] <gnafu> I would love to see a decent ivtc filter in ffmpeg.  It would be nice to do DVD reencoding with just ffmpeg and have things that need, for example, pullup in mplayer/mencoder come out with the correct 24000/1001 fps.
[20:32] <ubitux> gnafu: i think a lot of ppl are waiting for such filter
[20:32] <ubitux> but it seems no one is motivated enough to do the port
[20:32] <gnafu> Yeah :-P.
[20:32] <ubitux> TBH i could do it, but it's likely it will take all my time
[20:33] <ubitux> and what i fear the most is the lack of testing material
[20:35] <gnafu> ubitux: I can provide you with at least one DVD that required pullup to get 24 fps.
[20:36] <gnafu> For only certain scenes, too, so it might be a good test for mixed content.
[21:20] <ubitux> i'm going to propose a task for this
[21:22] <llogan> i think it was mentioned previously as a GSoC task but not added to the idea list.
[21:23] <llogan> we need more mentors attached to tasks
[21:23] <ubitux> i'm going to add myself
[21:24] <ubitux> i have a very good qualification task in mind..
[21:24] <llogan> is html and css considered code for GSoC? i could mentor a site redesign
[21:24] <Compn> imo we should drop dvd crap and work on bluray
[21:24] <Compn> but hey what do i know :D
[21:24] <Compn> llogan : i think documentation was, i dont know current gsoc rules..
[21:25] <Compn> maybe i'm thinking summer code in rules
[21:26] <llogan> also the lists page need a Qualification Task section, or at least something that mentions/explains what a QT is.
[21:27] <Compn> people didnt like my ideas for the soc page so i kinda gave up :P
[21:27] <llogan> and what did you learn in your experiences? Never try.
[21:27] <Compn> of course, never try
[21:28] <llogan> im joking of course
[21:28] <Compn> :)
[21:28] <Compn> llogan : what about search links for the ml ?
[21:29] <llogan> i emailed you back 17 minutes ago
[21:29] <Compn> oh 
[21:29] <ubitux> Daemon404: http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_of_Code_2013#Inverse_telecine_filter
[21:29] <ubitux> comments?
[21:29] <llogan> that was fast
[21:30] <ubitux> can we add images in the wiki?
[21:30] <ubitux> i'd like to illustrate some tasks with a picture
[21:30] <llogan> i approve
[21:30] <Compn> ubitux : yes, add pictures or make a new page that explains ivtc and link to that
[21:30] <Compn> ubitux : and please add some ivtc sample links to the task/page too
[21:31] <Compn> samples which need ivtc that is
[21:31] <Compn> ubitux : you can upload images using this page http://wiki.multimedia.cx/index.php?title=Special:Upload
[21:31] <Compn> or remote host them elsewhere
[21:32] <ubitux> Compn: great thx
[21:32] <Compn> i can throw them up on ffmpeg.org also if you want
[21:32] <llogan> Compn: feel free to email back if you want, or i'll be back here in an ~hour if you have comments/questions
[21:32] <Compn> not sure where,  but at minimum in my home dir, ffmpeg.org/~compn/
[21:32] <ubitux> Compn: do you know some page with floating image inserted?
[21:32] <Compn> yes, lemme dig
[21:32] <Compn> llogan : ok, i'll probably email back then
[21:32] <ubitux> btw, when this page should be done?
[21:32] <Compn> no rush
[21:32] <Compn> you mean the soc deadline ?
[21:32] <Compn> before google makes decisions for sure
[21:32] <Compn> :P
[21:33] <ubitux> yes
[21:33] <ubitux> i mean when are we supposed to present that page?
[21:33] <llogan> March 29 at 19:00 UTC is the application deadline for interested organizations
[21:33] <beastd> ubitux: 29 March
[21:33] <ubitux> oh
[21:33] <ubitux> this is a very special date..
[21:33] <ubitux> :)
[21:33] <ubitux> thx
[21:34] <Compn> ubitux : http://wiki.multimedia.cx/index.php?title=ATRAC3plus
[21:34] <Compn> has some images 
[21:34] <Compn> or one image i should say
[21:34] <Compn> check special pages > gallery for new files > ...
[21:34] <ubitux> any page with a floating one?
[21:34] <Compn> whats floating mean ?
[21:34] <Compn> mouseover ?
[21:34] <ubitux> at the right or left of the text
[21:34] <ubitux> like newspapers
[21:34] <Compn> oh
[21:35] <Compn> should be able to use wiki markup to find that 
[21:35] <Compn> i mena, on wikipedia
[21:35] Action: Compn looks
[21:36] <Compn> ubitux : http://en.wikipedia.org/wiki/Wikipedia:Image_markup_with_HTML
[21:36] <burek> it might seem as if af_join has a broken parser, particularly for SL channel: http://ffmpeg.gusari.org/viewtopic.php?f=11&t=849&p=1716
[21:36] <Compn> thats for html, heres wiki stuff > http://en.wikipedia.org/wiki/Wikipedia:Extended_image_syntax
[21:36] <burek> the guy used the example from the docs
[21:37] <burek> (the last post only is enough)
[21:37] <ubitux> Compn: thx a lot
[21:37] <ubitux> ok let's grab some images now.
[21:37] <Compn> burek : file report :)
[21:37] <burek> not me :)
[21:38] <Compn> ask user to do it then
[21:41] <burek> not that either
[21:41] <burek> asked once and got flamed why did i do that when they flame him on the tracker
[21:41] <burek> so, no :)
[21:41] <Compn> lol :)
[21:41] <Compn> ask in #ffmpeg if anyone wants to test and report a bug then
[21:42] <burek> it's clear that ffmpeg obviously works too great to have embarrasing bug issues
[21:42] <Compn> its not that
[21:42] <Compn> just devs are busy doing stuff or dont want to test bugs
[21:42] <Compn> or lazy :)
[21:42] <Compn> email it to carl 
[21:42] <burek> nobody forces anyone to use or reply at bug tracker...
[21:42] <Compn> its a volunteer project
[21:43] <burek> i dont want to flame carl either
[21:43] <burek> it's just easier for me not to get involved in all that again
[21:43] <Compn> lol ok
[21:43] <burek> if you dont need reports, im fine with that really :)
[21:43] <Compn> maybe i'll take a look then
[21:44] <burek> ffmpeg works great for me :)
[21:44] Action: Compn hopes he can reproduce
[21:44] <Compn> can you reproduce it burek ? 
[21:44] <Compn> i dont mind making a report ....
[21:45] <burek> thank you
[21:45] <Compn> machine translated bugreport :)
[21:45] <burek> well, ill try, but im having a hard time accessing my machines lately
[21:45] <Compn> turning 6 mono files into something ...
[21:45] <burek> due to stupid power outages...
[21:45] <Compn> ah that sucks
[21:46] <Compn> hate power outs
[21:46] <Compn> burek : can you ask what his source is? how does he get 6 mono files ?
[21:46] <Compn> i think its more of a 'user is doing something in the wrong way' problem
[21:47] <Compn> but there might also be a bug... just that, if we get the user to convert it properly in the first place 
[21:47] <Compn> then we wont have to deal with a crazy corner case like this
[21:48] <Compn> 'is this from a dvd' 'what program did you use to extract each channel to a seperate wav, and why did you do that?'
[21:49] Action: Compn wonders if he has an account on the forum
[21:51] <burek> well, as i can see from input logs all 6 wavs are the same
[21:52] <ubitux> yay first pic added.
[21:53] <gnafu> ubitux: DAT ASS.
[21:55] <ubitux> second one.
[21:55] <ubitux> ok for filtering now...
[21:57] <ubitux> gnafu: extra bonus point if you guess the source
[21:57] <Compn> ubitux : on your subtitle qt, what sub muxers/demuxers need to be coded? can you add that list to the page ?
[21:58] <Compn> or if you know them, i guess thats good enough :)
[21:58] <Compn> since you are mentor
[21:58] <ubitux> that's not very specific i know
[21:58] <ubitux> i don't know very much yet what to propose TBH
[21:58] <Compn> i'm just making sure they all have samples and specs
[21:58] <Compn> if we're going to ask students to look at 
[21:59] <Tjoppen> michaelni: eh, perhaps. I'll have many projects in the future
[22:00] Action: Compn goes afk
[22:22] <ubitux> http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_of_Code_2013
[22:22] <ubitux> any comment on the pictures?
[22:22] <ubitux> what should i add now?
[22:23] <Compn> samples that need to be ivtc'd 
[22:23] <ubitux> no i mean to illustrate the tasks
[22:23] <Compn> oh
[22:23] <ubitux> does firefox/chromium support apng?
[22:24] <ubitux> mmh seems it does
[22:25] <Compn> how about 3d h264 or interlaced vc1 screens ?
[22:25] <Compn> :)
[22:25] Action: Compn gone gone
[22:31] <gnafu> Aah, it's MNG that isn't so widely supported.  I always get those mixed up.
[22:33] <ubitux> michaelni: so you're not adding yourself anywhere?
[22:54] <Daemon404> ubitux, the IVTC gsoc project is tiny
[22:54] <Daemon404> thats no work at all for an entire summer
[22:54] <ubitux> honestly i'm not so sure about that
[22:55] <Daemon404> porting vivtc to libavfilter is probably a few days of work
[22:55] <Daemon404> max
[22:55] <ubitux> it's a student work
[22:55] <ubitux> it might require to add various features
[22:55] <ubitux> or improve it
[22:55] <Daemon404> not really.
[22:55] <Daemon404> no.
[22:55] <ubitux> why?
[22:56] <Daemon404> there arent any 'new features' to add
[22:56] <Daemon404> and it wont require any new things
[22:56] <Daemon404> afaik
[22:56] <Daemon404> its a straight port job to lavfi
[22:56] <ubitux> some other implementation might be more effective in some situations
[22:56] <ubitux> it might be interesting to improve it
[22:57] <Daemon404> uh
[22:57] <Daemon404> thats simply is not going to happen
[22:57] <Daemon404> and you are naive for thinking so
[22:57] <ubitux> why?
[22:57] <Daemon404> its been defacto for a long time
[22:57] <wm4> lol
[22:57] <Daemon404> and nothign does better in ANY stuation
[22:57] <Daemon404> speakin from eyars of ivtc filter poking.
[22:57] <ubitux> Cf the qualification task
[22:57] <wm4> must port vf_noise first!
[22:57] <ubitux> wm4: isn't it already done?
[22:57] <Daemon404> ubitux, im saying i know form my own year of experience.
[22:58] <wm4> yeah, I was just trolling
[22:58] <ubitux> Daemon404: did you try VLC one?
[22:58] <Daemon404> years*
[22:58] <Daemon404> yes
[22:58] <wm4> however, there are more worthless filters to spend time on
[22:58] <Daemon404> in fact i provided soures
[22:58] <Daemon404> for its development
[22:58] <ubitux> !
[22:58] <Daemon404> when it was being written
[22:58] <ubitux> i asked for the samples many times!
[22:58] <ubitux> :((
[22:58] <wm4> like vf_telecine is still there in libmpcodecs
[22:58] <Daemon404> i have a sexy 18fps->24fps->30ps telecined file
[22:58] <ubitux> wm4 :D
[22:58] <Daemon404> and a few hybrid files
[22:58] <ubitux> Daemon404: please share!
[22:59] <Daemon404> wm4, and it's still shit.
[22:59] <Daemon404> ubitux, i need to rescue it from a harddrive then
[22:59] <Daemon404> its not on the net right now
[22:59] <ubitux> Daemon404: please do, i beg you :(
[22:59] <Daemon404> and ul it
[22:59] <ubitux> i read the comments in vlc code
[22:59] <ubitux> i saw various ref
[22:59] <ubitux> and i tried to find the ntsc raws
[22:59] <ubitux> i didn't find most of them
[22:59] <wm4> so, why not just a vsynth bridge
[22:59] <michaelni> ubitux, added myself to h264 MVC
[22:59] <Daemon404> anyway, tivtc/vivtc beats the crap ut of everything
[23:00] <ubitux> but i have a few ones
[23:00] <Daemon404> end of story
[23:00] <Daemon404> :)
[23:00] <Daemon404> and for deinterlacing/bobbing
[23:00] <Daemon404> QTGMC beatst he crap outta everything
[23:00] <ubitux> Daemon404: i would like to try myself, i have no idea how that's even supposed to be used with the various different situation
[23:00] <Daemon404> 'supposed to be' ?
[23:00] <nevcairiel> i assume those things have auto-cadence detection and dont need me to tell them? :d
[23:01] <ubitux> Daemon404: if you provides me the samples and tell me how to make something clean out of them with VS, i'm going to port it right away.
[23:01] <Daemon404> ubitux, a lot hinges on my terribly upload speed
[23:01] <cone-791> ffmpeg.git 03James Zern 07master:bcaf64b60544: normalize calls to ff_alloc_packet2
[23:01] <ubitux> Daemon404: i'm going to look at the samples i've already have to save you some bandwidth
[23:02] <Daemon404> i have some really sexy samples
[23:02] <wm4> again, is  a vapoursynth bridge not feasible?
[23:02] <ubitux> Daemon404: did you do some testing with something else than animes btw?
[23:02] <Daemon404> with mixed 60i, soft telecined (24), hard telecined, doouble hard telecined, and 30fps progressive cotent
[23:02] <Daemon404> all within 10 mins
[23:02] <Daemon404> it's so sexy.
[23:02] <ubitux> awesome
[23:02] <ubitux> i need it!
[23:02] <ubitux> Black Lagoon Vol 1 NTSC Dual Audio
[23:02] <ubitux> Sol Bianca The Legacy
[23:02] <Daemon404> wm4, vs_script.py | ffmpeg -i pipe.y4m
[23:02] <ubitux> i have this
[23:03] <michaelni> nevcairiel, do you want to mentor something ?
[23:03] <Daemon404> ubitux, thats likely not too bad
[23:03] <wm4> Daemon404: having it in the filter chain would be useful for various purposes
[23:03] <gnafu> Daemon404: It's interesting to call it "sexy" and use terms like "soft", "hard", and "double hard".
[23:03] <nevcairiel> wm4: i think that would be a good idea, running a full vapoursynth script as a lavfi filter
[23:03] <ubitux> Daemon404: AZUMANGA_DAIOH_1.ISO  this one never started
[23:03] <wm4> but porting it to libavfilter doesn't sound so useful
[23:03] <ubitux> and  actually the 2 i quoted are not done... :'(
[23:04] <gnafu> ubitux: Azumanga Daioh is one of my all-time favorites.
[23:04] <Daemon404> there are otehr filters that lavf lacks too btw
[23:04] <wm4> duplicating work and maintainance etc.
[23:04] <Daemon404> liek proper derainbowing and dot crawl removal
[23:04] <ubitux> gnafu: yes it's nice, i'm just looking for some raw right now though
[23:04] <Daemon404> for cross-luma and cross-chroma artifacting
[23:04] <Daemon404> from analogue conversion
[23:04] <Daemon404> [17:03] < wm4> but porting it to libavfilter doesn't sound so useful
[23:05] <Daemon404> you clearly dont get the "ONE MONOLITHIC LIB 4 LYFE" mentality
[23:05] <Daemon404> duh.
[23:05] <wm4> lol
[23:05] <Daemon404> id be far more keen to port things if i could do it dynamicall
[23:05] <Daemon404> so then the code could remain in the same codebase
[23:05] <Daemon404> just with different frontends
[23:05] <Daemon404> for vs of lavfi
[23:05] <Daemon404> or avs
[23:06] <wm4> uh, what, like libivtc?
[23:06] <Daemon404> ?
[23:06] <Daemon404> no?
[23:06] <Daemon404> seem for example
[23:06] <Daemon404> ffmpegsource
[23:06] <Daemon404> has both avs, lib, and vs
[23:06] <Daemon404> proper way is to decouple frontend from actual processing code
[23:06] <nevcairiel> michaelni: possibly, if i find a task that i actually know stuff about :)
[23:07] <wm4> well, anything in ffmpeg seems to be geared towards ffmpeg.c :(
[23:07] <michaelni> nevcairiel, ok thanks
[23:07] <Daemon404> what you dont like parsing stdout from lavfi to get output wm4?
[23:07] <Daemon404> :D
[23:07] Action: Daemon404 runs
[23:07] <michaelni> wm4, do you want to mentor something ?
[23:07] <wm4> yeah, that kind of stuff
[23:08] <wm4> michaelni: no I have my own trouble (like maintaining a giant heap of crap code)
[23:08] <ubitux> Daemon404: hey, we fixed that!
[23:08] <nevcairiel> we all have our giant heaps of crap code, thats no excuse!
[23:08] <Daemon404> but mplayer is extra crappy
[23:09] <Daemon404> i think satan hiself wrote mencoder.c
[23:09] <wm4> my fork has 1/4 the size of mplayer proper
[23:09] <wm4> but still...
[23:09] <Daemon404> you nuked all the internal forks of libs?
[23:09] <ubitux> you should have forked ffplay instead
[23:09] <wm4> yes, for example
[23:09] <wm4> or kernel drivers for linux 2.4
[23:09] <Daemon404> ubitux, no because SDL is crap
[23:09] <ubitux> and added gl output and subtitles support
[23:10] <wm4> ffplay is a nice clusterfuck
[23:10] <ubitux> :D
[23:11] <wm4> apropos clusterfuck
[23:11] <wm4> it appears the evil plan is ready soon
[23:11] <wm4> what will ffmpeg do?
[23:11] <ubitux> start the angel plan
[23:12] <nevcairiel> last i heard was merge,  i wonder how many decoders there are only in ffmpeg that still need updating then
[23:12] <wm4> they're going to squash all these dozens of patches
[23:12] <wm4> and make it an atomic change from A to B
[23:12] <ubitux> yes
[23:12] <ubitux> just like filters.
[23:12] <wm4> so, I suppose you have a plan (otherwise, pure chaos)
[23:12] <nevcairiel> on the one hand, i can understand doing one commit, because it can break bisecting when you end up in the middle, stuff just wouldnt build or something
[23:13] <nevcairiel> but it really makes stuff harder =p
[23:13] <ubitux> then maybe a transition code would have been helpful?...
[23:13] <wm4> I don't know the code, so I can't tell how hard it would be to add emulation layers for the old API
[23:13] <wm4> but it sure sounds a bit saner
[23:13] <Daemon404> emulation layers sounds liek a horrible idea
[23:13] <Daemon404> full of epic pain
[23:14] <wm4> assume you find a regression
[23:14] <wm4> and bisect
[23:14] <wm4> and the offending commit is THAT
[23:14] <wm4> have fun
[23:14] <ubitux> accumulating 1 year of code and pushing it in one commit is full of insanity
[23:14] <nevcairiel> as far as i know, not everything will be in one giant commit, but spread in about 3 or 4
[23:14] <Daemon404> wm4, assume you fin a regression
[23:14] <Daemon404> you bisect
[23:14] <Daemon404> the offending commit i a massive megre commit
[23:14] <wm4> lol
[23:14] <Daemon404> with code changed in the merge commit too
[23:14] <Daemon404> >.>
[23:15] <ubitux> nevcairiel: it should have been progressive
[23:15] <ubitux> well, whatever.
[23:15] <saste> no the "evil" about the evil plan is that it was meant to be disruptive
[23:16] <saste> probably for the sake of being disruptive
[23:16] <nevcairiel> a lot preparation was already commited
[23:16] <ubitux> saste: that's indeed what we all have in mind, but i'm afraid we'll be called paranoids idiots if we say so
[23:16] <wm4> and some of that has been reverted / not merged
[23:16] <nevcairiel> but adding ref-counting to the decoders is hard to do step by step, have to hit all decoders at once
[23:17] <Daemon404> ^
[23:17] <saste> so, how are we going to deal with that?
[23:17] <Daemon404> also ref counting is USEFUL
[23:17] <saste> or better, how michaelni is going to deal with that?
[23:17] <wm4> nevcairiel: I don't see the problem... it'd be easy to provide a refcounting emulation for decoders that support DR or nothing at all (like ffplay does)
[23:17] <nevcairiel> the actual decoder changes arent that big, for what its worth
[23:17] <nevcairiel> its just a few lines per decoder
[23:17] <wm4> even if it gives a performance hit during the transition
[23:17] <saste> Daemon404, yes there are some cons about the new design
[23:18] <nevcairiel> most lines of code are in actual new code
[23:18] <saste> otoh in the short term it will be extremely annoying
[23:18] <Daemon404> short term pain for longter gain
[23:18] <Daemon404> the way of life.
[23:18] <saste> short term pain for long term pain
[23:18] <ubitux> Daemon404: anyway, back to the original topic; as soon as you send me the sample(s) and tell me how to VS-it/them them in a sane way, i'm looking at the port
[23:18] <saste> the way of life
[23:18] <Daemon404> ubitux, btw be scared
[23:19] <Daemon404> TIVTC was written by an EE
[23:19] <Daemon404> who didnt have the best
[23:19] <Daemon404> erm
[23:19] <nevcairiel> coding skills?
[23:19] <Daemon404> practices.
[23:19] <nevcairiel> :p
[23:19] <ubitux> i looked at it a little, a bit "noisy"
[23:19] <wm4> ubitux: again, why not a complete vsynth wrapper?
[23:20] <saste> wm4: how hard that would be?
[23:20] <Daemon404> ubitux, you should see the original code
[23:20] <Daemon404> 2000 lines for text parsing
[23:20] <ubitux> wm4: i'm not interested in writing such code
[23:20] <Daemon404> using ascii codes
[23:20] <Daemon404> not even 'a'
[23:20] <ubitux> tivtc has some kind of scripting support right?
[23:20] <Daemon404> no
[23:20] <ubitux> (which vivtc lacks, right?)
[23:20] <Daemon404> it has support for override files
[23:20] <Daemon404> lists of manual matches
[23:20] <Daemon404> if you want to force it
[23:21] <ubitux> override files?
[23:21] <wm4> saste: here's the API http://code.google.com/p/vapoursynth/source/browse/trunk/include/VapourSynth.h
[23:21] <Daemon404> ubitux, a list of frame #s and matches
[23:21] <saste> btw, anyone volunteers as admin or coadmin for gsoc?
[23:21] <Daemon404> likes
[23:21] <Daemon404> for example
[23:21] <Daemon404> 0,100,ccnnc
[23:21] <Daemon404> applies that pattern from 0-100
[23:21] <ubitux> exactly
[23:21] <ubitux> the last part of the doc iirc
[23:21] <ubitux> isn't this what's missing from vivtc?
[23:22] <Daemon404> yea
[23:22] <Daemon404> nobody cared
[23:22] <wm4> FFMPEG WILL
[23:22] <Daemon404> and that was 2000 lines of hirrible text parsing code
[23:22] <Daemon404> that nobody wanted to decode
[23:22] <ubitux> exactly
[23:22] <ubitux> we know how to write text parsing code
[23:22] <Daemon404> except when you dont
[23:22] <Daemon404> :P
[23:22] <ubitux> i'll write a subtitle decoder for it
[23:22] <Daemon404> overengineer much?
[23:22] <wm4> sorry I find most ffmpeg text parsing code quite incomprehensible
[23:23] <saste> why people always bitch about bad ffmpeg documentation when nobody gives a *hi* about even documenting the headers in other projects?
[23:23] <wm4> too much pointer juggling
[23:23] <Daemon404> saste, which projects
[23:23] <ubitux> wm4: :(
[23:23] <saste> Daemon404,  http://code.google.com/p/vapoursynth/source/browse/trunk/include/VapourSynth.h this one for example
[23:23] <Daemon404> saste, documentation is elsewhere
[23:23] <Daemon404> it isnt doxygen style
[23:24] <Daemon404> https://code.google.com/p/vapoursynth/source/browse/trunk/sdk/invert_example.c
[23:24] <Daemon404> needs a bit more publicity i agree, and moved to the header
[23:24] <Daemon404> also http://vapoursynth.com/doc/
[23:24] <ubitux> http://vapoursynth.com/doc/apireference.html ?
[23:24] <ubitux> :/
[23:25] <nevcairiel> its still a project in its early stages, give it a break =p
[23:25] <Daemon404> yell at Myrsloik 
[23:26] <saste> Daemon404, documentation by examples, no reference, no good
[23:27] <Daemon404> im not disagreeing
[23:27] <Daemon404> but ive ritten with both apis
[23:27] <Daemon404> and theres one major difference
[23:27] <Daemon404> ffmpeg violatest he principle of least surprised at every turn
[23:27] <Daemon404> in crazy ways
[23:27] <wm4> what's the most crazy thing
[23:27] <wm4> input buffer padding?
[23:27] <Daemon404> most rage ive had is from:
[23:28] <Daemon404> 1) when i wrote custo mget buffer impls and ran itno edge emu
[23:28] <Daemon404> 2) teh fucking order things need to be set in AVCTX is NOT DOCUMENETD ANYWHERE
[23:28] <Daemon404> so itll work
[23:28] <Daemon404> but just work differently
[23:28] <Daemon404> depending on which order you set struct members
[23:28] <Daemon404> or which order you call funcs
[23:28] <saste> what about the moon phase?
[23:29] <Daemon404> saste, that is reserved for any and all timestamp handling code
[23:29] <Daemon404> in ffmpeg
[23:29] <Daemon404> vsync, async
[23:30] <saste> :)
[23:30] Action: BBB-work snickles
[23:30] <ubitux> Daemon404: so can i expect the samples from you at some point, or i'm damned for the eternity?
[23:31] <Daemon404> ubitux, not within a few days
[23:31] <Daemon404> gb of file on a 512 kbit/s upload pipe
[23:31] <Daemon404> gonna take forever.
[23:31] <ubitux> :'(
[23:31] <ubitux> Daemon404: i guess i have no other way to grab it?
[23:31] <nevcairiel> snail mail a usb thumb drive somewhere!
[23:32] <Daemon404> ubitux, i got these off of japanese p2p over years
[23:32] <cone-791> ffmpeg.git 03Luca Barbato 07master:4987faee78b9: h264: check for luma and chroma bit dept being equal
[23:32] <Daemon404> and ripped from physical discs
[23:32] <cone-791> ffmpeg.git 03Luca Barbato 07master:02055b6d40d0: vorbisdec: check memory allocations
[23:32] <cone-791> ffmpeg.git 03Michael Niedermayer 07master:c10da30d8426: shorten: set invalid channels count to 0
[23:32] <Daemon404> so likely not
[23:32] <cone-791> ffmpeg.git 03Michael Niedermayer 07master:be493ca2a8c4: Merge commit 'c10da30d8426a1f681d99a780b6e311f7fb4e5c5'
[23:32] <ubitux> Daemon404: if i send you a physical usb drive, would you send it me back?
[23:32] <ubitux> (how large are they?)
[23:33] <Daemon404> i have several tb of random stuff
[23:33] <ubitux> TB mmh
[23:33] <Daemon404> but several hundred gb of screwy stuff
[23:33] <Daemon404> rest is all nice
[23:33] <Daemon404> mostly.
[23:33] <TheFluff> isn't there some .txt with a lot of vs stuff in it floating around on some pastebin
[23:33] <TheFluff> where did that go
[23:33] <Daemon404> ubitux, a good example of how tivtc beats the shit outta everything else is in anime where the only thing moving is a tiny (10x10) mouth
[23:33] <Daemon404> mouth combs.
[23:33] <ubitux> Daemon404: how much space do you need to put all the interesting samples?
[23:34] <Daemon404> i dont know
[23:34] <Daemon404> i'd need to look
[23:34] <Daemon404> i have about 40,000 usb keys and sd cards lying around
[23:34] <Daemon404> i can just send one
[23:35] <ubitux> i can go buy some and send you a letter with 5 or 6 in it
[23:35] <TheFluff> I have a bunch of weird shit too
[23:35] <TheFluff> but I have 10mbit/s up so I can actually do something useful with it
[23:35] <Daemon404> ubitux, just ask for a bunch of weird stuff in The Other Network/Channel
[23:35] <ubitux> !
[23:35] <TheFluff> how the hell do you only have 512k up anyway d404
[23:35] <Daemon404> people will load you up
[23:35] <Daemon404> TheFluff, because Canada
[23:35] <Daemon404> also brb my food is going to burn
[23:35] <TheFluff> o you moved away from nyc?
[23:35] <ubitux> Daemon404: i already did, just got a few references once, but no sample
[23:36] <Daemon404> for a few mo, UK in june
[23:36] <Daemon404> periodically NYC
[23:36] Action: Daemon404 grabs food before fire
[23:36] <TheFluff> now to figure out which ones of these random vobs from 2006 I kept around because they were "interesting" and which ones I just forgot to delete
[23:37] <ubitux> TheFluff: i'm looking for all kind of various samples to test the efficiency of ivtc filters, and basically try the code i'll port/write
[23:37] <ubitux> if you have something else than animes too that would be welcome
[23:37] <nevcairiel> TheFluff: that sounds like my sample archives
[23:37] <saste> burek: time to do some doc work?
[23:38] <TheFluff> nevcairiel: does it have a million files named "test %d.foo" and "buttes.avi" in it?
[23:38] <nevcairiel> i really need a better system to track my samples
[23:38] <nevcairiel> TheFluff: and millions of sample.avi
[23:38] <TheFluff> ubitux: most stuff that isn't anime is pretty easy to ivtc
[23:38] <TheFluff> yeah
[23:38] <TheFluff> except like, star trek
[23:38] <ubitux> because of the non moving scenes?
[23:39] <TheFluff> there are several factors that contributes to anime nastiness
[23:39] <TheFluff> low framerate and very low motion scenes is one
[23:39] <llogan> and the monsters that can suck salt out of the living
[23:39] <TheFluff> the tendency to mix digital with analog content and "film" with 30fps cgi is another
[23:39] <ubitux> what about 3D material with slowmo and stuff?
[23:40] <ubitux> or animes with 3D in it
[23:40] <saste> michaelni, ping about the avcodec_set_dimensions() stuff and ffprobe patch
[23:40] <TheFluff> it varies, but 3d at least usually has some pans in it to make it more interestin
[23:40] <TheFluff> g
[23:41] <ubitux> TheFluff: so, would you mind to upload all that kind of nasty material somewhere?
[23:41] <ubitux> or can i somehow send you some usb drives or something?
[23:42] <TheFluff> http://mod16.org/samples/nastystuff/
[23:42] <TheFluff> here's one to start you off
[23:42] <TheFluff> uploading more stuff now
[23:42] <ubitux> thanks a lot
[23:42] <ubitux> gonna mirror that stuff
[23:42] <TheFluff> no problems
[23:43] <TheFluff> that one is a music video dvd that I used to test wannabe fansubbers with
[23:43] <Daemon404> TheFluff, what happened to those horrible samples i gave you
[23:43] <Daemon404> like 2 years ago
[23:43] <ubitux> 30MB/sec, great.
[23:43] <TheFluff> I must've put them in some "good place"
[23:44] <llogan> saste: i can possibly be a backup admin.
[23:45] <TheFluff> I should probably try to explain why some of these are nasty
[23:45] <cone-791> ffmpeg.git 03Luca Barbato 07master:a2ad554def21: shorten: K&R formatting cosmetics
[23:45] <cone-791> ffmpeg.git 03Michael Niedermayer 07master:09131ebb5624: Merge commit 'a2ad554def214d2d03b7c16f68dc081a8622f9ca'
[23:46] <ubitux> TheFluff: yes, and if you're awesome, how to get good results out of them with VS
[23:46] <llogan> ubitux: images look nice. thanks.
[23:46] <Daemon404> ubitux, well keep in mind many of use oly use ivtc filters for metrics collection
[23:46] <Daemon404> and use YATTA.
[23:47] <TheFluff> dude most of these are like 6 years old and most of them were tuned by hand to look good
[23:47] <Daemon404> tivtc is just least bad
[23:47] <TheFluff> no way I remember how to fix them
[23:47] <ubitux> ok
[23:47] Action: Daemon404 has kept every avs script he ever wrote
[23:47] <Daemon404> so i can provide some for sources
[23:48] <ubitux> http://ivtc.org/ oh shit
[23:48] <Daemon404> yes.
[23:48] <ubitux> yatta is closed source and windows only?
[23:48] <Daemon404> its open sourc
[23:48] <Daemon404> and windos only
[23:49] <ubitux> ok
[23:49] <TheFluff> http://code.google.com/p/yatta-ivtc/
[23:49] <TheFluff> the codebase is pretty nasty though
[23:49] <Daemon404> hope you like pascal
[23:49] <Daemon404> from 2001
[23:49] <TheFluff> also written in object pascal
[23:50] <Daemon404> https://warpsharp.info/yatta.txt
[23:50] <Daemon404> this should really be added to ivtc.org
[23:50] <ubitux> looks different than http://ivtc.org/manuals/yatta.txt
[23:50] <Daemon404> because this one was written a few years back
[23:50] <TheFluff> there are many yatta.txt's out there
[23:50] <Daemon404> and is actually useful
[23:50] <TheFluff> it's a pretty cryptic program
[23:50] <saste> llogan, i'll send an update to the gsoc thread soon
[23:51] <Daemon404> i suffer from a disease where i think yatta isnt cryptic
[23:51] <Daemon404> even though i know it is.
[23:51] <TheFluff> that's because you've been desentisized
[23:52] <cone-791> ffmpeg.git 03Luca Barbato 07master:4c364eb2b856: shorten: report meaningful errors
[23:52] <cone-791> ffmpeg.git 03Michael Niedermayer 07master:90f8b2ce48cf: Merge commit '4c364eb2b856fc33cf7b42f7c7b979e69fde5f3a'
[23:54] <Daemon404> wow
[23:54] <Daemon404> that bug above
[23:54] <Daemon404> has nobovody ever heard of encoder delay?
[23:54] <Daemon404> (sample priming)
[23:58] <Daemon404> TheFluff, seems im as bad as you
[23:59] <Daemon404> bars_tcd.mp4  derp.mp4  qt_busted_gpac.mp4  test_in.mp4
[23:59] <Daemon404> copy.mp4      poop.mp4  qt_busted.mp4       test.mp4
[23:59] <TheFluff> haha
[23:59] <ubitux> Daemon404: so in practice, what does it looks like? you run VIVTC on your material, get a trace log of what it did (in a dummy pass), and load it in YATTA to adjust it?
[00:00] --- Thu Mar  7 2013