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

[burek]

[00:00] <cone-851> ffmpeg.git 03Michael Niedermayer 07release/1.0:3ac97550ce3b: asfdec: parse payload extension list
[00:00] <cone-851> ffmpeg.git 03Michael Niedermayer 07release/1.0:19de5478f027: asfdec: correctly parse payload extensions
[00:00] <cone-851> ffmpeg.git 03Michael Niedermayer 07release/1.0:08d75bf545f3: asfdec: parse aspect ratio payload extension
[00:00] <cone-851> ffmpeg.git 03Michael Niedermayer 07release/1.0:e432bd071c4f: asfdec: flip the interpretation of the header aspect back
[00:00] <cone-851> ffmpeg.git 03Michael Niedermayer 07release/1.0:41bcde602127: asfdec: check stream_index for validity
[00:00] <ubitux> heh where is the space?! :(
[00:00] <saste> release/1.0/3ac97550ce3b also would be good
[00:01] <ubitux> release/1.0 41bcde60 should be enough
[00:01] <ubitux> btw, i'd remove the ':' at the end too
[00:01] <ubitux> to ease copy/paste
[00:01] <saste> uhm that's an argument
[00:02] <ubitux> saste: btw, is it me or af volume is missing a avfilter_copy_buffer_ref_props? (in case of RO+alloc)
[00:02] <ubitux> (instead of the cheap pts copy)
[00:03] <saste> possible
[00:04] <saste> BTW about the out_buf, should we still use it?
[00:04] <saste> do you know if it was removed from libav, or it is planned to be removed?
[00:04] <ubitux> was it ever present in libav?
[00:05] <saste> well now that I think maybe not
[00:05] <ubitux> i think it was nice to have an automatically allocated out buf for some filter since it can save ~6 lines
[00:05] <saste> so i guess the better solution is to store it in the filter private context
[00:05] <ubitux> but well
[00:06] <saste> OTOH, all this implicit behavior was hard to follow
[00:06] <ubitux> yep
[00:07] <cone-851> ffmpeg.git 03Michael Niedermayer 07master:b11a88905518: vf_tinterlace: default of mode switch is impossible, add assert.
[00:07] <cone-851> ffmpeg.git 03Michael Niedermayer 07master:0a60f8307588: http: dont null check p, its unneeded
[00:07] <cone-851> ffmpeg.git 03Michael Niedermayer 07master:22e4988673df: opt: fix memleak on error of range_array
[00:20] <cone-851> ffmpeg.git 03Stefano Sabatini 07master:8e9056559e11: lavf/segment: add reset_timestamps option
[00:22] <Daemon404> ubitux, no select filter for audio i take it?
[00:22] <Daemon404> (i.e. wanna drop negative pts audio)
[00:23] <ubitux> i don't think so :p
[00:23] <Daemon404> dman
[00:23] <Daemon404> damn*
[00:23] <Daemon404> so i cant handle negative pts for audio
[00:25] <wm4> I thought you don't care about lavfi
[00:25] <Daemon404> i have to for audio
[00:25] <Daemon404> or well, i could use sox
[00:26] <ubitux> sox can filter out negative pts audio frames?
[00:26] <Daemon404> ubitux, ffprobe->get start ptrs -> calculations -> cut N samples off with sox -> encode
[00:26] <Daemon404> pts*
[00:26] <saste> don't we have aselect?
[00:26] <saste> weird I think we had
[00:27] <Daemon404> nope
[00:27] <ubitux> we have asetpts
[00:27] <ubitux> but no aselect
[00:27] <saste> well it's a simple hack, let's see if i can write it in half an hour ;-)
[00:28] <Daemon404> how does astreamsync act with negative pts?
[00:28] <Daemon404> er not astreamsync
[00:28] <Daemon404> asyncts
[00:29] <saste> on the other hand, selecting audio is trickier, since you have to fill the gaps
[00:29] <Daemon404> first_pts
[00:29] <Daemon404> Assume the first pts should be this value. This allows for padding/trimming at the start of stream. By default, no assumption is made about the first frames expected pts, so no padding or trimming is done. For example, this could be set to 0 to pad the beginning with silence if an audio stream starts after the video stream.
[00:29] <Daemon404> that seems to do what i want
[00:29] <ubitux> i think you need to build ffmpeg with avresample for this filter
[00:30] <saste> padding can be done with aresample as well
[00:30] <Daemon404> ubitux, thats no a problem
[00:30] <ubitux> saste: what about trimming?
[00:30] <saste> ubitux: what do you mean by trimming?
[00:31] <ubitux> strip, delete, etc
[00:31] <ubitux> dunno what's the final goal, but what Daemon404 is looking for i guess
[00:31] <saste> aselect, but then you have to fill the discontinuities
[00:31] <saste> aresample can surely work by filling the initial gap, i'm not sure it also cover the midstream gaps
[00:31] <saste> also it pads with silence
[00:32] <Daemon404> ubitux, "drop negatively timestamped audio frames"
[00:32] <saste> we could have an apad with fill with data coming from a source (e.g. noise)
[00:32] <ubitux> Daemon404: you could use ffprobe and use a ffmpeg -ss :p
[00:33] <Daemon404> why?
[00:33] <Daemon404> so i can have the inaccuracy that comes with seekign in ffmpeg?
[00:33] <Daemon404> no thanks.
[00:33] <ubitux> it's accurate
[00:33] <Daemon404> -ss is nto accurate on tons of formats
[00:33] <Daemon404> at all.
[00:33] <Daemon404> thats essentially why ffms indexes.
[00:33] <ubitux> it's perfectly accurate as output option
[00:34] <Daemon404> i wonder how seeking works as an output option
[00:34] <ubitux> (as long as you re-encode)
[00:34] <ubitux> it decodes everything
[00:34] <Daemon404> does it pad and trim properly?
[00:34] <ubitux> (or maybe it does something smarter with the seeking?)
[00:35] <Daemon404> either way i'd rather use asynctx
[00:35] <Daemon404> s/x/s/
[00:35] <Daemon404> there's nothing to parse
[00:35] <ubitux> for pad/trim, -async
[00:35] <Daemon404> just set it to 0
[00:35] <Daemon404> youre proposing /more/ compelx solutions
[00:35] <Daemon404> which is Not Cool
[00:35] <ubitux> how is -async more complex?
[00:36] <Daemon404> -async has proven to break a bunch of shit in the past
[00:36] <Daemon404> a LOT.
[00:36] <Daemon404> i dont use it
[00:36] <ubitux> -async now inserts a aresample filter
[00:36] <Daemon404> or i could just call asyncts
[00:36] <Daemon404> whats your problem with that?
[00:36] <ubitux> (and a asyncts filter on the fork)
[00:36] <Daemon404> oh so thats why youre bitchign about it
[00:36] <Daemon404> grow up.
[00:36] <ubitux> sure, you do what you want :)
[00:36] <ubitux> huh?
[00:36] <ubitux> i'm not bitching, i'm proposing solutions&
[00:37] <Daemon404> solutions to a solved problem.
[00:37] <ubitux> you were asking questions& whatever
[00:40] <Daemon404> i get annoyed whenever people say stuff liek:
[00:40] <Daemon404> [18:36] <@ubitux> (and a asyncts filter on the fork)
[00:40] <Daemon404> regardless of whom or which project. is all.
[00:40] <ubitux> &
[00:41] <ubitux> i was just saying how it works
[00:41] <ubitux> and saying you might expect a different behaviour elsewhere
[00:41] <Daemon404> that latter part makes no sense
[00:42] <ubitux> ?
[00:42] <Daemon404> 'different behavior elsewhere' doesnt really make a lot of ense?
[00:42] <Daemon404> elsewhere is undefined for one thing
[00:42] Action: Daemon404 lacks context
[00:42] <ubitux> "-async option inserts aresample on ffmpeg, -async option inserts asynts on libav" was my point, nothing more
[00:42] <ubitux> i was just sharing some info on how it works
[00:43] <Daemon404> i never asked how -async worked
[00:43] <Daemon404> i even specifically said im not using it
[00:43] <Daemon404> so idunno why it's relevant
[00:43] Action: Daemon404 shrugs
[00:44] <ubitux> well i won't give you extra information unless you explicitely ask then
[00:44] <ubitux> it looked particularly relevant at that point to explain that
[00:44] <Daemon404> if it convolutes what's actually being discussed (not -async), then why mention it
[00:44] <ubitux> i have no idea what bitching your were talking about, nor why you are angry
[00:44] <Daemon404> it came off as "im going to keep proposing more non-fork solutions" after i had decided on asyncts
[00:44] <ubitux> i was just mentioning various ways of doing the same thing, depending on your need
[00:45] <Daemon404> yes, AFTER i said i had fullfilled mine
[00:45] <ubitux> so what?
[00:45] <ubitux> is it a sin to give more solution?
[00:45] <ubitux> this is not a private discussion, it can interest various other ppl
[00:47] <Daemon404> fair enough, but i feel it served no purpose.
[00:47] <Daemon404> i conede i overreacted
[00:47] <Daemon404> concede even
[00:48] <ubitux> no worry e
[00:51] <Daemon404> hmmm pysox maybe be useful one day
[00:53] Action: saste reminds he has a sox wrapper rotting in his hard disk
[00:53] <Daemon404> i thought vf_sox.c was a thing already
[00:53] <Daemon404> or maybe that was mplayer
[00:53] <saste> af_sox.c?
[00:54] <wm4> no such thing in mplayer
[00:54] <wm4> just a broken lavfi wrapper
[00:54] <saste> there is a ladspa wrapper though
[00:54] <wm4> and that
[00:54] <saste> the mplayer lavfi wrapper is broken?
[00:54] <saste> did it ever worked with audio?
[00:54] <wm4> there's also a xmms demuxer to use xmms plugins, if you need that
[00:55] <wm4> (lol)
[00:55] <ubitux> we have a libmodplug demuxer!
[00:55] <wm4> saste: I didn't check, but last time I tried (some months ago), it "didn't work" (tm)
[00:55] <wm4> saste: and yes it's video only
[00:55] <Daemon404> saste, maybe vf_sox is for people with synesthesia
[00:58] <bcoudurier> I activate async by default personnally
[00:58] <bcoudurier> I don't want to dup/drop frames, I want to add audio instead
[00:59] <bcoudurier> add/remove audio
[01:00] <saste> ubitux, alength looks more like an apad rather than a clone of setnsamples
[01:00] <Daemon404> bcoudurier, harder when you process vid/sound separately
[01:01] <bcoudurier> you doing a/v sync separately ? :)
[01:01] <Daemon404> sort of.
[01:01] <Daemon404> but async has problem to break lot of the more busted files
[01:01] <Daemon404> s/problem/proven/
[01:02] <Daemon404> youre lucky you dont deal with user generated content :)
[01:02] <bcoudurier> with broken demuxer probably
[01:02] <Daemon404> demuxer?
[01:02] <Daemon404> you mean muxer?
[01:03] <Daemon404> only demuxing happens inside ffmpeg
[01:04] Action: Daemon404 heads home
[01:05] <bcoudu> had to go to a meeting :)
[01:05] <bcoudu> so I think -async was kinda broken in the past because it was widely used
[01:05] <bcoudu> by activating by default I got to see a lot of problems with demuxed that basically output wrong timestamps
[01:16] <cone-851> ffmpeg.git 03Michael Niedermayer 07release/1.0:dad5b9560a5c: ffplay: Prevent 0/0 aspect from being passed on to lavfi
[01:16] <cone-851> ffmpeg.git 03Michael Chinen 07release/1.0:59d765e30cda: flac_parser.c: fix issue with looping output for small files.
[01:16] <saste> well i wrote aselect, i'll post it soon after i test and document it
[01:16] <saste> night
[01:17] <ubitux> 'night :)
[01:23] <michaelni> if someone knows a case where asyncts works better than -async / aresample then please open a bug report
[01:27] <cone-851> ffmpeg.git 03Carl Eugen Hoyos 07master:71b191296386: Print bpc (for bits per component) with pixel format if it is smaller than expected.
[01:29] <ubitux> michaelni: afaict asyncts has a lot of accessible options, which might not be obvious just using -async
[01:29] <ubitux> also the documentation is refering to asyncts
[01:32] <michaelni> as asyncts is redundant and not compiled in by default the docs shouldnt refer to it
[01:32] <michaelni> aresample should have similarly accessible options
[01:34] <Daemon404> ubitux, start_pts is the killer 
[01:34] Action: Daemon404 checks aresample
[01:35] <Daemon404> huh... all filters lists i aresample=N
[01:35] <Daemon404> where N is sample rate
[01:35] <ubitux> michaelni: the aresample documentation is& cheap :)
[01:35] <ubitux> michaelni: http://ffmpeg.org/ffmpeg.html#aresample
[01:35] <Daemon404> yeah
[01:35] <ubitux> there is no mention of the hidden options
[01:35] <Daemon404> btw what happened to the toc?
[01:35] <Daemon404> it's missing
[01:37] <Daemon404> i also looked for swresample docs today (here: http://ffmpeg.org/doxygen/trunk/) didnt find any
[01:37] <ubitux> what toc?
[01:37] <ubitux> https://www.ffmpeg.org/ffmpeg.html  i see one here :p
[01:37] <Daemon404> table of contents on filters.html
[01:37] <Daemon404> there used to be one
[01:37] <Daemon404> now it's just a massive list
[01:37] <ubitux> oh here mmh
[01:37] <ubitux> i think the server needs some updates after the recent changes into the doc
[01:38] <ubitux> but saste left
[01:38] <ubitux> :(
[01:38] <ubitux> the server needs some updates
[01:38] <Daemon404> i thought it was autogenerated
[01:38] <ubitux> for swr as well
[01:38] <Daemon404> libav's is
[01:38] <ubitux> it is
[01:38] <Daemon404> long time between crons?
[01:39] <ubitux> but scripts are not in sync with git/master
[01:39] <ubitux> and iirc pages are not added automatically
[01:39] <Daemon404> ah
[01:39] <ubitux> are you sure there was a toc in filters.html?
[01:39] <Daemon404> i thought it regerated the docs daily based on git master
[01:39] <Daemon404> yes
[01:40] <Daemon404> i spent a lot of time reading it
[01:40] <ubitux> it is, what's not is for instance the styles and other files
[01:40] <michaelni> aresample docs atm are only in source or ffmpeg -h full : SWResampler AVOptions
[01:40] <Daemon404> michaelni, i mean api docs
[01:40] <Daemon404> i.e. i was choosing between swr and avr
[01:40] <Daemon404> avr had docs; swr didn't
[01:41] <ubitux> yeah michaelni was answering to the initial thing
[01:41] <ubitux> swr doxy isn't generated indeed
[01:41] <Daemon404> ah
[01:41] <ubitux> no dev are reading them :p
[01:41] <Daemon404> ubitux, i think it had a toc up until teh styles change
[01:41] <ubitux> so we didn't realize
[01:41] <Daemon404> back when it was a crappy white page
[01:42] <Daemon404> i make heavy use of doxy
[01:42] <Daemon404> :(
[01:42] <ubitux> yes, same, but the raw doxy
[01:42] <ubitux> :P
[01:42] <Daemon404> i use the on-site one
[01:42] <Daemon404> since it's convenient
[01:42] <michaelni> if someone tells me whats wrong with the swr doxy compared to avr then i can fix it
[01:42] <ubitux> michaelni: it's not present
[01:42] <Daemon404> michaelni, the lack of doxy on ffmpeg.org
[01:42] <ubitux> http://ffmpeg.org/doxygen/trunk/
[01:42] <Daemon404> :P
[01:44] Action: ubitux wonders why avfilter and swscale doxy aren't present either
[01:44] <Daemon404> the other weird thing i've noticed, is that some random guy put ffmpeg's doxy online, and it outranks both ffmpeg's and libav's official doxy in google
[01:44] <Daemon404> consistently
[01:44] <Daemon404> it's lulz
[01:45] <michaelni> also our doxy is generated daily so it should be upto date
[01:46] <ubitux> michaelni: yes but it's not parsing swresample
[01:46] <ubitux> :p
[01:46] <ubitux> (and it's lacking css integration btw, which is available in git/master afaik)
[01:47] <michaelni> ubitux, i think it is parsing it just something is wrong like a typo in the doxy or some missing but neeeded statment
[01:47] <michaelni> about css, patch welcome
[01:49] <ubitux> make apidoc && firefox doc/doxy/html/index.html show all the libraries + links
[01:49] <ubitux> and css is properly integrated
[01:50] <ubitux> well not much info into it though&
[01:51] <michaelni> ubitux, not here
[01:51] <michaelni> locally make apidoc does not show all links eoither
[01:51] <ubitux> yeah that's because i have doxygen 1.8
[01:51] <ubitux> so it behaves a little differently
[01:51] <ubitux> there is not much content anyway
[01:53] <michaelni> ive found the issue
[01:54] <michaelni> "typo" in doxy as i said
[01:54] <ubitux> strange
[01:54] <ubitux> the output doesn't say anything
[01:55] <ubitux> anyway, about css integration, the files on the server need to be updated to use doc/doxy/*
[01:57] <cone-851> ffmpeg.git 03Michael Niedermayer 07master:5595e7a10221: doxy: fix swr group name
[01:58] <ubitux> ah nice
[02:04] <michaelni> about "the files on the server need to be updated to use doc/doxy/*", patch is welcome
[02:04] <ubitux> i think it's just a matter of cp the 3 files
[02:07] <ubitux> Daemon404: it's fun to see the differences between what's being displayed by doxygen, and what's actually in the doxy
[02:07] <Daemon404> ;p
[02:07] <ubitux> some information (alot~) are lacking :p
[02:08] <michaelni> ubitux, i think you should run doxygen on your server
[02:08] <michaelni> and we just link to it
[02:08] <ubitux> fine with me :p
[02:12] <Daemon404> i really wonder how ami finds these things
[02:13] <cone-851> ffmpeg.git 03Clément BSsch 07master:18d9398143ac: doxy: add ref for lavfi, lpp and lsws.
[02:20] <ubitux> Daemon404: http://lucy.pkh.me/ffdoxy/  temporary unstable/testing/draft page
[02:20] <ubitux> looks like indent is broken :)
[02:23] <michaelni> ubitux, your files list is well a bit short
[02:24] <ubitux> no idea why :p
[02:24] <michaelni> apidoc vs the full doxy over all files i guess
[02:25] Action: michaelni is tired, and goes to bed
[02:25] <ubitux> what's the full doxy rule?
[02:26] <ubitux> oh well, i'll see another day
[02:26] <ubitux> it's not like i ever use doxygen
[02:26] <ubitux> :p
[02:26] <michaelni> the server does a doxygen with a doxyfile
[02:26] <michaelni> no rule unless i misremember
[02:27] <michaelni> i dunno how to do it with a git checkout
[02:27] <michaelni> maybe doxygen doc/doxyfile or something
[02:29] <michaelni> i can send you the doxyfile from the server if you dont have it but i dunno how that would interact with the css
[02:29] <ubitux> no it's ok
[02:29] <ubitux> i'm really not motivated to look deeper tonight, sorry
[02:29] <ubitux> but yeah you're right the problem is here
[02:30] <ubitux> i think i know how to fix it, just don't wanna do it now :p
[02:55] <cone-851> ffmpeg.git 03Clément BSsch 07master:7eafd274d85f: build: fix prores decoder dependencies.
[03:40] <Compn> wm4 : what you got against carl ?
[03:57] <cone-851> ffmpeg.git 03Clément BSsch 07master:80e5c51d7324: doc: fix a -map syntax in one command line example.
[04:14] <highgod> Hi,I got a version form git to merge our code,the time is 2012-12-10 10:11:16,SHA1 ID is 7aabeea9ba0e557e834c886de5ea4db8e9a5193d.After I configure it,then I make it on mingw, it report an error:library.mak:106: *** missing separator.  Stop.
[04:15] <Daemon404> disable autocrlf in git
[04:15] <Daemon404> re-clone
[04:18] <highgod> OK,Thanks.I'll try it.
[04:30] <cone-851> ffmpeg.git 03Clément BSsch 07master:fd3cdcaf5f4d: lavfi: remove mp=denoise3d filter.
[04:43] <highgod> Hi, at Daemon404.I set the core.autocrlf=false and than re-clone the version using command git clone git://source.ffmpeg.org/ffmpeg.git ffmpeg, but it doesn't work.Is there anything wrong?
[04:47] <Daemon404> i would double check to make sure it cloned with lf line endings...
[04:50] <highgod> I add a tab before 106,than it can be compiled
[04:50] <highgod> I will check whether the result is correct
[04:51] <ubitux> smells like a finger-keyboard-fart
[08:17] <highgod> Hi, can I use the code on git snapshot to merge and submite our code? I use command git clone git://source.ffmpeg.org/ffmpeg.git ffmpeg to get the code, but it can't be compiled,report library.mak:106: *** missing separator.  Stop.,When I modify the library.mak,then it report error C:\MinGW\bin\ar.exe: libavcodec/: Permission denied
[08:21] <nevcairiel> you need to checkout with LF line endings
[08:22] <highgod> OK,I check again,it seems to work,thanks
[08:38] <cone-715> ffmpeg.git 03Carl Eugen Hoyos 07master:2ddf7c88d162: ZeroCodec: Flip output
[08:38] <cone-715> ffmpeg.git 03Mans Rullgard 07master:395c3feb3bb1: build: fix 'clean' target
[08:38] <cone-715> ffmpeg.git 03Michael Niedermayer 07master:9696ad6a7653: Merge remote-tracking branch 'qatar/master'
[09:03] <cone-715> ffmpeg.git 03Michael Niedermayer 07master:a70b38d2dd0d: lavf: fix memleak
[09:03] <cone-715> ffmpeg.git 03Michael Niedermayer 07master:b688a2847062: astenc: fix assignment vs compare
[09:39] <cone-715> ffmpeg.git 03Michael Niedermayer 07master:67c1b5b0269d: lavf: remove unneeded pb check
[10:35] <cone-715> ffmpeg.git 03Peter Ross 07master:53ae32d33109: iff demuxer: support RGB8 and RGBN
[10:35] <cone-715> ffmpeg.git 03Peter Ross 07master:7016aa655b10: iff decoder: support RGB8 and RGBN
[10:47] <simonec77> Hi, anyone of us are using the native ffmpeg AAC encoder?
[10:48] <simonec77> I know still now the implementation only support LC profile...
[11:15] <simonec77> none is present?
[11:25] <pross-au> No i have not used it
[11:57] <cbsrobot> pross-au: nice patchset
[12:07] <pross-au> yw
[12:41] <cone-715> ffmpeg.git 03Paul B Mahol 07master:237513900769: fate: add BRSTM demuxer test
[12:48] <cone-715> ffmpeg.git 03Paul B Mahol 07master:17d5746d9672: build: fix dca encoder dependencies
[12:57] <cone-715> ffmpeg.git 03Michael Niedermayer 07master:7dee5f04acdb: svq3: fix cast type to be independant of "sizeof(int)"
[12:57] <cone-715> ffmpeg.git 03Michael Niedermayer 07master:9e28c7ef646d: filters.texi: document more aresample options
[13:00] <durandal_1707> new alength filter with bells and whistles
[13:34] <durandal_1707> ffmpeg -codecs outputs evrc and i can transcode evrc in qcp without problems
[13:34] <durandal_1707> it this LGPL violation?
[13:35] <iive> hum?
[13:36] <durandal_1707> iive: ffmpeg binary from some share/paidware program that do not even mentions it is using ffmpeg
[13:38] <durandal_1707> old issue 2404
[13:38] <durandal_1707> carl did not notice extra codecs
[13:52] <durandal_1707> there are 5 codecs: evrc(-a), evrc-b, evrc-wb, evrc-nw and evrc-nw2k
[14:47] <cbsrobot> durandal_1707: just all em: http://www.sbwire.com/company/locations/bigasoft-23039.htm
[14:49] <cbsrobot> is it the same company ?
[14:52] <cbsrobot> lol: http://www.virtual-strategy.com/2012/04/15/bigasoft-announces-release-apple-prores-converter
[14:52] <cbsrobot> how did they do that ?
[15:19] <Compn> durandal_1707 : why 'evrca' ? is there evrcv ? 
[16:47] <cone-715> ffmpeg.git 03Michael Niedermayer 07master:b65570808cb3: mxfdec: fix leak of extradata
[16:47] <cone-715> ffmpeg.git 03Michael Niedermayer 07master:7d05bbb656d3: mxfdec: drop unneeded extradata padding
[16:56] <durandal_1707> Compn: there are 5 codecs: evrc(-a), evrc-b, evrc-wb, evrc-nw and evrc-nw2k
[17:13] <Daemon404> ubitux, are filters in -vf processed in left to right order?
[17:13] <ubitux> yes
[17:13] <Daemon404> e.g. ffmpeg -copyts -i herp.mov -vf select...->fps=
[17:14] <Daemon404> since copyts is needed to actually let select see if there are negative pts
[17:14] <Daemon404> but i still wanna framerate convert
[17:14] <Daemon404> seem plausible?
[17:14] <ubitux> i don't understand
[17:14] <Daemon404> which part?
[17:14] <ubitux> select=...,setpts=...  select then setpts
[17:15] <ubitux> setpts=...,select=...  setpts, then select
[17:15] <Compn> durandal_1707 : oh no.... 
[17:15] <Daemon404> inb4 fps filter is fork filter
[17:15] <ubitux> huh there is a fps filter?
[17:15] <Daemon404> yes
[17:15] <Daemon404> -r uses it doesnt it
[17:16] <ubitux> oh yeah i remember
[17:16] <ubitux> well, it's the same anyway
[17:16] <ubitux> select=...,fps=...  will run fps filter on the selected frames
[17:16] <Daemon404> yeah
[17:16] <ubitux> fps=...,select=...  will set fps, then select what comes out
[17:17] <Daemon404> that wont be very good, since it modifies timestamps ;)|
[17:18] <ubitux> select=...,fps=... isn't what you want?
[17:18] <Daemon404> it is
[17:18] <Daemon404> was commenting on the latter
[17:19] <ubitux> so your question is "will select=...,fps=... work?" ?
[17:20] <Daemon404> basically, and you said it would.
[17:21] <ubitux> secretly i just hope it works
[17:21] <ubitux> but i'll say it definitely works
[17:21] <Daemon404> lol
[17:23] Action: ubitux just ported vf pp
[17:23] <ubitux> the documentation is larger than the code
[17:23] <ubitux> :s
[17:23] <wm4> lol
[17:24] <Daemon404> most of that os probably postproc docs
[17:24] <Daemon404> <_<
[17:24] <ubitux> what postproc doc?
[17:24] <Daemon404> exactly.
[17:24] <ubitux> well, the pp filter usage in mplayer is pretty well documented
[17:25] <ubitux> but yeah it would belong to a dedicated pp doc
[17:25] <ubitux> i'll court saste so he does it
[17:29] <durandal_1707> is there some tool to do bswap?
[17:30] <Daemon404> tool? no but there are funcs
[17:34] <durandal_1707> i'm puzzled why soft i downloaded from 3gpp site decodes only silence
[17:40] <Compn> durandal_1707 : no one checks to make sure ref decoder works ?
[17:42] <Daemon404> or the stream is nonstandards compliant
[17:43] <durandal_1707> i do not think so, because reference code have higher priority over pdf spec
[17:43] <durandal_1707> i also tried 3gpp file with sevc
[17:43] <durandal_1707> i also get near silence
[17:45] <durandal_1707> perhaps it is packed in some stupid way
[17:50] <Daemon404> -vf fps='fps=30'
[17:50] <Daemon404> lulz
[17:51] <durandal_1707> hmm evrc in 3gp(skm) have extra byte, maybe because it is stereo and not mono....
[17:51] <ubitux> Daemon404: we can add a shorthand if you want
[17:51] <Daemon404> ubitux, i'd rather be explicity
[17:51] <Daemon404> doesnt bother me, just humerous
[17:51] <ubitux> it's something like a 2 line patch
[17:53] <Daemon404> no objections\
[17:55] <ubitux> erm nice documentation&
[17:56] <ubitux> i guess i'll send a patchset
[18:02] <Compn> durandal_1707 : did you email that windows app using ffmpeg to decode evrc ? 
[18:02] <Compn> or wrapping it anyways
[18:03] <durandal_1707> Compn: no, i do not officialy represent ffmpeg
[18:04] <Compn> did you forward it to anyone? if no one is working on it, i can send an email...
[18:05] <durandal_1707> send email to right person and put me on cc
[18:05] <Compn> wheres the app url ?
[18:09] <durandal_1707> Compn: http://www.bigasoft.com/audio-converter.html
[18:16] <ubitux> michaelni: http://lists.mplayerhq.hu/pipermail/mplayer-users/2012-December/085693.html
[18:17] <cone-715> ffmpeg.git 03Clément BSsch 07master:0e0e3db189d3: lavfi/fps: add shorthand.
[18:17] <cone-715> ffmpeg.git 03Clément BSsch 07master:b2f2321cecf3: doc/filters: extend fps documentation.
[18:17] <cone-715> ffmpeg.git 03Clément BSsch 07master:4b4f16cdc000: lavfi/fps: remove parse opt error message.
[18:17] <ubitux> Daemon404 ^
[18:17] <ubitux> fps=30 will work now
[18:17] <Daemon404> ;p
[18:18] <Daemon404> huh weird
[18:19] <Daemon404> if i disable all filters
[18:19] <Daemon404> ffmpeg -copyts -i in.mp4 -r 30 out.mp4
[18:19] <Daemon404> or even
[18:19] <ubitux> (btw, you can mix both, like -vf fps=30:round=zero)
[18:19] <Daemon404> ffmpeg -copyts -i in.mp4 out.mp4
[18:19] <Daemon404> it padds/trims as needed
[18:19] <Daemon404> that seems to fly in the fact of what copyts says it does
[18:24] <Daemon404> cant seem to find any docs about what copyts -does-
[18:25] <Daemon404> -copyts
[18:25] <Daemon404> Copy timestamps from input to output. 
[18:25] <ubitux> "Copy timestamps from input to output." :))
[18:25] <Daemon404> this is a damn lie ^
[18:25] <Daemon404> it changes the framecount!
[18:25] <ubitux> [FFmpeg-devel] [PATCH] doc/ffmpeg: fix/extend documentation for -copyts
[18:25] <ubitux> Thu, 22 Nov 2012
[18:26] <Daemon404> ah
[18:26] <Daemon404> time to necro that thread
[18:27] <ubitux> -debug_ts may help too
[18:27] <Compn> Daemon404 : arcane magic
[18:28] <Compn> if you explain what it does, it will lose its power
[18:48] <durandal_1707> Compn: why you put such name?
[18:49] <Compn> what name ?
[18:49] <durandal_1707> you put in mail
[18:50] <Compn> "-compn" ?
[18:50] <Compn> did you want me to bcc you ?
[18:50] <durandal_1707> no Patriot ACT
[18:51] <Compn> oh that 
[18:51] <Compn> i dont want to enter my name into google :D
[19:00] <ubitux> Daemon404: btw, about the "first_pts" asynts, i think you can do that with asetpts=PTS+...
[19:00] <ubitux> or something like that
[19:00] <Daemon404> probably
[19:00] <ubitux> unless i misunderstand the option
[19:00] <Daemon404> i have ro read into it more
[19:08] <wm4> so, what exactly is the reason that ffmpeg forces everyone who wants to use DR1 to duplicate codec_get_buffer() as it's implemented in cmdutils.c
[19:09] <wm4> what is the reason in the first place that avcodec_default_get_buffer() wasn't just slightly modified so that ffmpeg.c/ffplay.c could use it?
[19:10] <durandal_1707> mostly historic reasons
[19:46] <Daemon404> wm4, i dont know
[19:47] <Daemon404> but i have a very small example implementation
[19:47] <Daemon404> that you can peek at
[19:47] <Daemon404> if it helps
[19:47] <wm4> I just copied the crap from cmdutils.c
[19:47] <Daemon404> lol
[19:47] <Daemon404> remember to align your w/h before allocing
[19:47] <wm4> I'm hoping that The Evil Plan will make it unnecessary again
[19:47] <Daemon404> or you will be sorry
[19:47] <Daemon404> (and crashy)
[19:48] <wm4> you should see mplayer's DR implementation... I'm surprised it works in any way
[19:49] <Daemon404> [13:48] < wm4> you should see mplayer... I'm surprised it works in any wa
[19:49] <Daemon404> ftfy
[19:55] <durandal_1707> i think i got source of problem, packets i dump are wrong
[20:01] <durandal_1707> packets heve two bytes that sets rate no wonder why i got nothing ...
[20:13] <ubitux> michaelni: is vf mp doing some particular processing to the input buffer?
[20:14] <ubitux> i've some differences in output between vf mp=pp and my port
[20:14] <ubitux> the parameters to the pp functions are identical
[20:14] <ubitux> i guess the input got modified in vf mp but i'm a bit lost in it
[20:14] <ubitux> any hint?
[20:17] <michaelni> ubitux, is the buffer that gets modified correctly marked as not writeable ?
[20:19] <ubitux> i don't understand
[20:19] <ubitux> in my port?
[20:20] <gnafu> "It's more likely than you think."
[21:58] <cone-715> ffmpeg.git 03Stefano Sabatini 07master:bbc8f0cd9b89: doc/filters: fix grammar mistake in setfield documentation
[22:17] <cone-715> ffmpeg.git 03Michael Niedermayer 07master:e8e575633faf: lavc/utils: Do not require dimensions for PNG.
[22:17] <cone-715> ffmpeg.git 03Rob Sykes 07master:5a5d70748c5d: swr: Add API to make resample engine selectable.
[22:17] <cone-715> ffmpeg.git 03Michael Niedermayer 07master:431dcc49d2dc: swr: make realloc_audio() available outside swresample.c
[22:17] <cone-715> ffmpeg.git 03Michael Niedermayer 07master:ae5a55e77a20: swr: move flush into Resampler
[22:17] <cone-715> ffmpeg.git 03Rob Sykes 07master:41049d07f2e8: swr: add a lowpass default so that each Resampler can have its own default.
[22:17] <cone-715> ffmpeg.git 03Rob Sykes 07master:801b31572945: swr: Add SOX resampler support
[22:18] <wm4> <cone-715> ffmpeg.git Michael Niedermayer master:e8e575633faf: lavc/utils: Do not require dimensions for PNG.
[22:18] <wm4> wtf
[22:18] <wm4> just because mplayer broke?
[22:19] <Compn> lol
[22:19] <wm4> how about fixing mplayer instead
[22:19] <michaelni> wm4 mplayer should be fixed but
[22:20] <michaelni> old mplayer should not breal with new ffmpeg
[22:20] <michaelni> breaK
[22:20] <ubitux> isn't mplayer supporting only ffmpeg git/master?
[22:20] <michaelni> in all distros ?
[22:21] <wm4> I bet mplayer is paired with random ffmpeg versions which leads to random breakages
[22:22] <beastd> well. MPlayer development version (SVN) is meant to be used ffmpeg git master. But we do usually not try to break things just because we can.
[22:22] <beastd> also for all deployed versions it is great to still work after ffmpeg updates
[22:30] <Daemon404> [16:18] < wm4> just because mplayer broke?
[22:30] <Daemon404> welcome to ffmpeg
[22:30] <Daemon404> nejoy your stay!
[22:36] <ubitux> context: it broke after a commit in ffmpeg
[22:36] <beastd> wb Daemon404
[22:36] <ubitux> sounds legit to fix it in ffmpeg first
[22:36] <wm4> mplayer's API usage has been incorrect for years
[22:36] <Daemon404> >implying mplayer uses teh api
[22:36] <Daemon404> ahahahaha
[22:36] <Daemon404> yeah right.
[22:36] <ubitux> is there that much usage of the private api?
[22:37] <Daemon404> some of its filters use codec specific contexts
[22:37] <Daemon404> among other thongs
[22:37] <Daemon404> things*
[22:38] <beastd> Daemon404: compare apples with oranges it always leads to nice results regardless of what you want to prove
[22:38] <Daemon404> i dont even know what point youre trying to make with that
[22:38] <beastd> ditto
[22:38] <Daemon404> defending mplayer's abuse of internal apis?
[22:39] <ubitux> mplayer abusing internal api is imo a proof that improvement is necessary in ffmpeg side
[22:39] <beastd> not at all. besides it is not correct what you say
[22:39] <ubitux> not especially the other way around
[22:39] <wm4> ubitux: that is true
[22:39] <wm4> ffmpeg's API is horrible
[22:39] <Daemon404> beastd, there are fi;ters using e.g. mpegenccontext
[22:39] <wm4> extremely horrible
[22:39] <Daemon404> which is -not- public
[22:39] <Daemon404> it's entirely true
[22:39] <beastd> Daemon404: yes. but filters are *not* mplayer.
[22:39] <ubitux> wm4: if stated step by step, i'm sure we can improve some points
[22:39] <wm4> the worst about mplayer is that it somehow frankensteins ffmpeg into its build system
[22:39] <michaelni> Daemon404, for these filters its either use internal API or no filter at all
[22:40] <michaelni> that is in the situation from mplayers point of view
[22:40] <wm4> and mplayer's configure is probably the only configure that performs a git checkout on its own... while being located in svn
[22:40] <beastd> wm4: ack with the build system. would be good to fix this at some point
[22:40] <wm4> beastd: mplayer2 etc.
[22:40] <ubitux> beastd: if you care about mplayer, you should backport stuff from mplayer2 & mpv, clearly
[22:41] <wm4> no he should make a new mplayer fork
[22:41] <ubitux> mplayer's fork are mostly harmless IMO
[22:41] <j-b> yes, another fork!
[22:41] <ubitux> contrary to fork of libraries
[22:42] <Daemon404> ubitux, harmless -> useful
[22:42] <Daemon404> theyve cleaned up a lot of crap
[22:42] <ubitux> yes, agree
[22:42] <Daemon404> mplayer2 and mpv have actually addressed most all my complaints
[22:42] <wm4> there's also mplayer-ww, which is exactly mplayer... plus directshow
[22:42] <ubitux> forking allow breaking things easily btw
[22:43] <wm4> and heaps of windows specific code
[22:43] <wm4> and chinese fonts
[22:43] <ubitux> (breaking compat i mean)
[22:43] <Daemon404> ubitux, thats why it was forked
[22:43] <Daemon404> people wouldnt part with the horribleness
[22:43] <Daemon404> of course it's incompatible
[22:44] <Daemon404> mplayer has a massively hard time doign naything major
[22:44] <Daemon404> look how hard it was to remove some ancient mp3 lib
[22:44] <wm4> if it runs 1 ms slower for just one user, it's a bad change
[22:44] <beastd> Daemon404: I do not agree mp3lib is a good point.
[22:44] <beastd> i mean is good for the point you want to make
[22:45] <beastd> anyway. i need to go afk and use mplayer on another box
[22:45] <Daemon404> in what way
[22:45] <beastd> see you
[22:46] <ubitux> michaelni: input buffer is not supposed to be writable, right?
[22:46] <beastd> Daemon404: mp3lib was not important in anyway and there was a good chance that you didn't even use it (depending on how your binary was built)
[22:46] <Daemon404> beastd, my point was that it was useless, and it STILL met with such resistance
[22:46] <Daemon404> to removing it
[22:46] <wm4> looking at mplayer, I still see things like libmpeg2
[22:46] <wm4> or vidix
[22:46] <wm4> museum
[22:46] <beastd> Daemon404: useless not to all people and not harmful
[22:47] <Daemon404> yeah that one guy with a pentium mmx
[22:47] <Daemon404> who struggles with m3p decoding
[22:49] <beastd> Whatever you like, it still doesn't make a good point at least not in my opinon.
[22:49] <beastd> And I do think there are other things that would make a good point, but you and others don't mention them at all.
[22:50] <beastd> Anyway, see you...
[22:50] Action: beastd really goes away now
[22:50] <ubitux> cya
[22:50] <Daemon404> i dream one day that the inbreeding between ffmpeg and mplayer devs will stop
[22:50] <Daemon404> and sanity will prevail
[22:51] <wm4> well, at least it stops ffmpeg's API from forcing all users to be ffplay.c/ffmpeg.c?
[22:51] <Daemon404> ?
[22:51] <Daemon404> ive personally reimplemnted a bunch of logic from those files
[22:51] <Daemon404> in my own code
[22:51] <Daemon404> cause it's kinda required for ltos of stuff
[22:51] <Daemon404> and teh api is too low-level / gernic
[22:51] <Daemon404> generic*
[22:52] <Daemon404> usually if i have a problem, there's a solution/hack in ffmpeg*c
[22:52] <wm4> it's hidden behind a generic function?
[22:52] <Daemon404> wm4, ?
[22:52] <Daemon404> maybe generic was a bad word to use
[22:52] <wm4> oh, misunderstood
[22:54] <michaelni> ubitux, input buffers can be writeable or not
[22:55] <michaelni> depends on the pervious filter
[22:56] <ubitux> i don't see anything to tell this to pp
[22:58] <michaelni> pp itself should not write in its input
[00:00] --- Wed Dec 12 2012