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

[burek]

[00:05] <Compn> i was just curious whats going on. i'm not in this particular asian turf war.
[00:15] <well0ne> Hello
[00:17] <well0ne> Hi, i'm having a question HLS related (libav?!) ... I want to customize the HTTP-Request and add some headers, i see that avio_open2 works with options, but howto use this exactly? can anybody help?
[00:21] <well0ne> anybody here who can help my to modify the HLS requests in ffmpeg?
[00:22] <ruggles> hi, i just wanted to pop in and report a probable bug i've run into
[00:22] <ruggles> http://samples.ffmpeg.org/V-codecs/h264/sony-hdr-cx6-avchd-interlaced-decoding-problem/sony-hdr-cx-6-avchd-1080i-3-seconds.mts
[00:22] <ruggles> ffmpeg -ss <anything> -i <that file> ...
[00:23] <ruggles> hangs in seeking
[00:23] <ruggles> but doesn't from HEAD about 2 weeks ago or so
[00:24] <Compn> ok ruggles , someone will take a look :)
[00:24] <llogan> thanks. i wonder if it's already in trac
[00:25] <ruggles> i haven't checked trac. it seems related to .read_timestamp() in the mpegts demuxer
[00:26] <ruggles> and ff_find_last_ts()
[01:14] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:8088d6f5f11b: avcodec/pictordec: run av_image_check_size() unconditionally
[01:14] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:560612344edf: avcodec/pictordec: remove y checks, which have become redundant
[01:14] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:b78e75ebc9b0: fate: Force diff into text mode
[01:14] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:a66099192159: avformat/mpegts: Ensure that mpegts_get_dts() only considers packets at or after the given position
[01:15] <michaelni> ruggles, should be fixed
[01:49] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:e5c338ba7abd: avformat/utils: assert position monotonicity in ff_find_last_ts()
[01:58] <cone-105> ffmpeg.git 03Carl Eugen Hoyos 07master:6fcfafff8456: Show subtitle resolution in avcodec_string().
[01:58] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:54d628a580be: Merge remote-tracking branch 'cehoyos/master'
[09:03] <dmon_> what's up with this on a compile....
[09:04] <dmon_> ranlib: file: libavcodec/libavcodec.a(timecode.o) has no symbols
[09:08] <dmon_> are my config flags out?     ./configure --enable-libvpx --enable-libspeex --enable-libass --enable-libbluray --enable-libfreetype --mandir=/opt/local/share/man --enable-shared --enable-pthreads --cc=/usr/bin/gcc-4.2 --arch=x86_64 --enable-yasm --enable-gpl --enable-postproc --enable-libx264 --enable-libxvid; make -j10
[10:49] <dol> hi all. how am I supposed to delete AVCodecContext properly? I was using av_free after calling avcodec_close but this call is not available anymore. I was wondering if avcodec_close is enough?
[10:49] <dol> I allocate if with avcodec_alloc_context3
[10:53] <dol> no answer?
[10:55] <GoaLitiuM> patience
[11:52] <michaelni> dol, what is not available anymore ?
[12:04] <cone-497> ffmpeg.git 03Martin Storsjö 07master:f7c5883126f9: alac: Limit max_samples_per_frame
[12:04] <cone-497> ffmpeg.git 03Michael Niedermayer 07master:642207d29a48: Merge commit 'f7c5883126f9440547933eefcf000aa78af4821c'
[12:16] <cone-497> ffmpeg.git 03Martin Storsjö 07master:5bcd3ae5b167: matroskadec: Check that .lang was allocated and set before reading it
[12:16] <cone-497> ffmpeg.git 03Michael Niedermayer 07master:233ab0f02a31: Merge commit '5bcd3ae5b167fb74215520b01d5d810e0c8986ab'
[12:46] <Daemon404> michaelni, i do not think diff -a is POSIX compliant.
[12:47] <Daemon404> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/diff.html
[12:55] <cone-497> ffmpeg.git 03Martin Storsjö 07master:d719981273bc: 4xm: Check that the read track value is non-negative
[12:55] <cone-497> ffmpeg.git 03Michael Niedermayer 07master:9411e9cafb52: Merge commit 'd719981273bc779c7d1e879d88404fd867f93a0e'
[12:59] <michaelni> Daemon404, hmm, what else can we use then ?
[13:03] <cone-497> ffmpeg.git 03Martin Storsjö 07master:35cbc98b720d: alac: Check that the channels fit at the given offset
[13:03] <cone-497> ffmpeg.git 03Michael Niedermayer 07master:f1b15c1ef9d8: Merge commit '35cbc98b720db95b923cb2d745f77bb2ee4363dc'
[13:05] <Daemon404> michaelni, im not sure
[13:05] <Daemon404> i dont know if it s a proble in practice
[13:05] <Daemon404> i think all the BSDs have -a
[13:06] <Daemon404> ohlol... BSDs all use diffutils
[13:07] <Daemon404> openbsd's supports it too
[13:07] <michaelni> openbsd needs it for fate to pass it seems
[13:08] <Daemon404> i see
[13:08] <Daemon404> how do nonascii charactrs get into it?
[13:08] <Daemon404> unicode metadata?
[13:08] <michaelni> i think so yes
[13:10] <Daemon404> i guess leave -a unless someone complains
[13:10] <Daemon404> or breaks something
[13:10] <michaelni> ok
[13:12] <cone-497> ffmpeg.git 03Michael Niedermayer 07master:af11fa5409cc: mjpegb: Detect changing number of planes in interlaced video
[13:12] <cone-497> ffmpeg.git 03Michael Niedermayer 07master:49f5519345d2: Merge commit 'af11fa5409cc72fc45ca7f3527400beca10967b9'
[13:20] <Daemon404> heh... avfilter_unref_buffer is deprecated
[13:20] <Daemon404> but its docs dont say what to use instead
[13:20] <Daemon404> -_-
[13:21] <nevcairiel> avfilter uses avframes
[13:21] <nevcairiel> use avframe api
[13:21] <Daemon404> im porting an old filter from ffmbc
[13:21] <Daemon404> to the new api
[13:21] <Daemon404> there's NO info on how to do that
[13:21] Action: Daemon404 shrug
[13:22] <nevcairiel> i managed without a tutorial :)
[13:22] <nevcairiel> just replace all avfilter buffer things with the new av frame things
[13:22] <Daemon404> whic hare where
[13:22] <Daemon404> docs are not helpful
[13:22] <nevcairiel> most in avutil/frame.h
[13:23] <nevcairiel> there are some special allocation functions in avfitler which wrap a bit of logic
[13:23] <Daemon404> "lavfi: switch to AVFrame."
[13:23] <Daemon404> oh right
[13:23] <Daemon404> it wasa giant commit
[13:23] <Daemon404> lovely.
[13:24] <nevcairiel> kinda needs to be, or any intermediate commits would be broken
[13:24] <nevcairiel> thats the fate of big internal api changes
[13:24] <Daemon404> heh
[13:24] <Daemon404> i know
[13:24] <nevcairiel> there was a neat branch with individual commits while we were migrating
[13:24] <nevcairiel> but it got squashed
[13:25] <nevcairiel> TEP might look evil from all the required changes in big monolithic commits, but the end result was well worth it, imho :)
[13:27] <durandal_1707> Daemon404: what filter you porting?
[13:27] <Daemon404> w3fdif
[13:27] <Daemon404> anyway, http://chromashift.org/d.txt
[13:27] <Daemon404> good enough of an example for me
[13:28] <durandal_1707> for internal use or to post it to ml?
[13:28] <Daemon404> ml
[13:28] <Daemon404> we dont have an internal for
[13:28] <Daemon404> k
[13:29] <durandal_1707> there was another filter from ffbmc i planed porting too, but i removed locally...
[13:31] <durandal_1707> michaelni: spam on wiki again: http://trac.ffmpeg.org/wiki/MacOSXCompilationGuide?action=diff&version=22
[13:34] <durandal_1707> hmm i can't see reason to keep dint alive
[13:35] <wm4> most of that mplayer stuff has very little use in the first place...
[13:36] <wm4> of the filters left, only vf_pullup seems to actually have fans
[13:39] <durandal_1707> beastd is using all other filters (except dint, eq and fil)
[13:41] <cone-497> ffmpeg.git 03Luca Barbato 07master:7f9e893f56db: build: Report an error message when a pc file is not found
[13:41] <cone-497> ffmpeg.git 03Michael Niedermayer 07master:44d884f036fa: Merge commit '7f9e893f56db52078e0f46677ed337b2e25fa94d'
[13:41] <Compn> wm4 : did you remove old filters in your fork yet ?
[13:41] <wm4> some
[13:53] <ubitux> + * @note Pointers provided by av_malloc family of functions cannot be
[13:53] <ubitux> + * passed to av_realloc().
[13:53] <ubitux> wtf?
[13:53] <Daemon404> tmm...
[13:53] <Daemon404> what do i use instead of ff_start_frame
[13:53] <Daemon404> which doesnt exist anymore
[13:54] <durandal_1707> nothing
[13:54] <Daemon404> wat
[13:54] <wm4> [ C E N S O R E D ] <- I like your patch, durandal_1707 
[13:54] <Daemon404> durandal_1707, i can just remove the line... or?
[13:54] <durandal_1707> all code that produces frames are in filter_frame
[13:55] <Daemon404> there are no calls to flter_frame in this filter
[13:55] <nevcairiel> there have to be. :)
[13:55] <nevcairiel> now anyway
[13:55] <durandal_1707> well, whatever that returns frames
[13:55] <Daemon404> nevcairiel, well how
[13:55] <ubitux> Daemon404: what does the filter do?
[13:55] <nevcairiel> the filters were migrated to this as a preparation step before tep
[13:55] <Daemon404> i cant find a freakign commit
[13:55] <Daemon404> where it changed
[13:55] <durandal_1707> takes one frame returns 2
[13:55] <Daemon404> man i fucking hate lavfi
[13:55] <ubitux> Daemon404: just look at the logic of the current filters
[13:55] <Daemon404> thats a shit cop out
[13:55] <ubitux> that's really simple
[13:56] <ubitux> in most cases
[13:56] <Daemon404> this is why nobody develops for lavfi
[13:56] <ubitux> Daemon404: what does the filter do? multiple in/out? drop/add frames?
[13:56] <Daemon404> theres no info on how to do it
[13:56] <wm4> the info is #ffmpeg-devel
[13:56] <Daemon404> it's also got .start_frame    = start_frame,
[13:57] <Daemon404> this is going to be a massive pain to port
[13:57] <Daemon404> isnt it
[13:57] <nevcairiel> imho, the internal API is easy enough to get by without shitty docs  that are outdated when written
[13:57] <Daemon404> so much fuckign code churn
[13:57] <durandal_1707> start_frame end_frame is just for slice era...
[13:57] <ubitux> likely not
[13:57] <ubitux> you can likely just drop half of the code
[13:57] <Daemon404> heh
[13:57] <ubitux> just answer the questions...
[13:57] <durandal_1707> those functions where called once per put_frame(whatever ..)
[13:57] <Daemon404> can i just remove stastart and end frame?
[13:57] <Daemon404> start*
[13:57] <ubitux> yes
[13:57] <nevcairiel> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=5f648ce43eeb619c32e74aeb79699e56c9149296
[13:57] <nevcairiel> there, use yadif
[13:58] <ubitux> you just define a filter_frame callback
[13:58] <Daemon404> ...
[13:58] <durandal_1707> but code in them may still be needed...
[13:58] <Daemon404> you knwo what
[13:58] <Daemon404> fuck this
[13:58] <Daemon404> i dont care
[13:58] <Daemon404> lavf is shit
[13:58] <ubitux> what the hell..
[13:58] <nevcairiel> the way i see it right now, you're just weird :P
[13:58] <ubitux> man you don't even answer the basic questions
[13:58] <Daemon404> nevcairiel, its deinterlacing
[13:58] <wm4> he's been damaged by avisynth, probably
[13:58] <Daemon404> nevcairiel, these are nonobvious changes
[13:58] <Daemon404> wth no docs
[13:58] <Daemon404> oevr short periods of time
[13:58] <Daemon404> stable as a house of twigs
[13:59] <nevcairiel> what the filter actually does has no influence on the lavfi plumbing
[13:59] <Daemon404> sorry that was directed at ubitux
[13:59] <Daemon404> wm4, ive been spoiled by avs and vs
[13:59] <nevcairiel> and i even found you an example commit of how to change things, since you asked for one .P
[13:59] <Daemon404> which have SANE and STABLE apis
[13:59] <Daemon404> for developign plugins
[13:59] <Daemon404> with stable ABI too
[13:59] <ubitux> Daemon404: ok so just look at how yadif works for the logic
[13:59] <Daemon404> this is not a trivial matter, ubitux 
[14:00] <nevcairiel> sounds like it is
[14:00] <Daemon404> basically i have to rewrite the whoel plugin
[14:00] <Daemon404> to use the new stuff
[14:00] <Daemon404> it's not a "port"
[14:00] <ubitux> no
[14:00] <nevcairiel> i helped port a bunch of lavfi filters, and none where really hard
[14:00] <ubitux> you have to simplify it
[14:00] <nevcairiel> were*
[14:00] <Daemon404> nevcairiel, this is not just TEP stuff
[14:00] <Daemon404> this is form ffmbc
[14:00] <Daemon404> which has a very old lavfi api
[14:00] <ubitux> you have 3 things to deal with
[14:00] <ubitux> av options
[14:00] <ubitux> slice -> frames
[14:00] <ubitux> avbuffer -> avframes
[14:01] <Daemon404> i did the 3rd oen already
[14:01] <ubitux> then you only have to drop some code now
[14:01] <Daemon404> s/drop/move/
[14:01] <nevcairiel> drop too
[14:01] <ubitux> drop a lot
[14:01] <nevcairiel> the new api is much simpler
[14:01] <nevcairiel> start_frame/end_frame was terrible
[14:01] <Daemon404> so what do i need to move
[14:01] <Daemon404> from start/end
[14:02] <Daemon404> and what can i drop
[14:02] <ubitux> Daemon404: can you show the .c?
[14:02] <Daemon404> http://mdsh.com/patches/ffmbc_0.7rc7/FFmbc-0.7-rc7_w3fdif_2012112501.patch
[14:02] <Daemon404> but ive done a lot of work on it
[14:02] <nevcairiel> without knowning your code, in most filters you could basically rename start_frame to filter_frame and drop most of end_frame
[14:02] <Daemon404> so its not the same
[14:02] <durandal_1707> 1 file changed, 32 insertions(+), 106 deletions(-) -> vf_overlay when converted from slice api
[14:02] <Daemon404> ubitux, im porting it so im ready for the next ver
[14:02] <Daemon404> a new w3dif with threading (rewrite) is coming to ffmbc
[14:02] <Daemon404> im waiting to port that one
[14:02] <Daemon404> this was supposed to be an exercise
[14:02] <ubitux> Daemon404: end_frame becomes filter_frame
[14:03] <ubitux> null_draw_slice destroyed
[14:03] <ubitux> poll_frame destroyed
[14:03] <Daemon404> i can just remove those entirely?
[14:03] <ubitux> move start_frame content on top of your new filter_frame
[14:03] <Daemon404> and rename end_frame?
[14:03] <ubitux> "destroyed" = you remove them
[14:03] <wm4> so, why does ffmbc use an old lavfi?
[14:04] <nevcairiel> because its generally out of date
[14:04] <ubitux> Daemon404: and you can likely drop request_frame
[14:04] <wm4> over half a year out of date?
[14:04] <Daemon404> wait
[14:04] <Daemon404> ALL of this
[14:04] <Daemon404> is from half a year?
[14:04] <Daemon404> holy shit.
[14:04] <cone-497> ffmpeg.git 03Luca Barbato 07master:b4ec7a5fee64: mem: Document the av_realloc family of functions properly
[14:04] <cone-497> ffmpeg.git 03Michael Niedermayer 07master:1c10e89c5155: Merge commit 'b4ec7a5fee644ad9882e10c097817b65447b8e55'
[14:04] <ubitux> this is internal api
[14:05] <ubitux> for the request frame, you just have to replace it with a flag
[14:05] <Daemon404> ubitux, so what?
[14:05] <Daemon404> tahts my point
[14:05] <nevcairiel> wm4: latest ffmbc uses ffmpeg 7cbb856efe6ccab7485bb96ad3887472a6519ffa
[14:05] <nevcairiel> thats from 2011
[14:05] <Daemon404> people develop plugins for vs and avs
[14:05] <durandal_1707> if you port in once to lavfi, you do not need to bother with apis for rest of time
[14:05] <Daemon404> because its internal api for plugi ndev is STABE
[14:05] <Daemon404> STABLE
[14:05] <wm4> wow, 2011
[14:05] <ubitux> Daemon404: yes but fuck them after all
[14:05] <Daemon404> what?
[14:05] <Daemon404> basically you make it so only preexistign dev will want to touch lavfi
[14:06] <Daemon404> or write filters for it
[14:06] <durandal_1707> so what we should do now? go back to slice API?
[14:06] <ubitux> :D
[14:06] <Daemon404> decide on a fucking api
[14:06] <Daemon404> and stay with it
[14:06] <nevcairiel> vs uses a freaking scripting language, it automatically adapts to changes :P
[14:06] <Daemon404> dont change it 9000 times
[14:06] <Daemon404> nevcairiel, no i mean its c api
[14:06] <Daemon404> for developpign plugins
[14:06] <ubitux> we are actually "deciding"
[14:06] <ubitux> over time
[14:06] <wm4> Daemon404: that would require coming up with a good API
[14:06] <wm4> which is hard
[14:07] <nevcairiel> i dont think thats one goal of lavfi, to make external plugins easier :p
[14:07] <Daemon404> [13:06] <@ubitux> over time <-- vs and avs did it a lot faster than you
[14:07] <ubitux> you complain about too much changes, and then ask to have the final version with all the changes right now
[14:07] <Daemon404> lavfi is fucking old now
[14:07] <Daemon404> so sont give me this "it takes time" bulshit
[14:07] <ubitux> it's mostly stable right now
[14:07] <ubitux> but still missing few feature
[14:07] <Daemon404> i heard that months ago
[14:07] <wm4> can I add my own filters yet? (without patching it)
[14:07] <Daemon404> wm4, the devs thing monolthic lisb are great
[14:07] <nevcairiel> you cant compare a project which has a plugin api as its primary target with a project which just happens to have some video filters
[14:07] <Daemon404> because theyre idiots.
[14:08] <ubitux> i wonder why im trying to help again
[14:08] <Daemon404> sorry i just get reminded how fucking terrible lavfi is
[14:08] <nevcairiel> without plugins, vs or avs would be dead
[14:08] <Daemon404> every time i look at it or touch it
[14:08] <ubitux> it isn't
[14:08] <ubitux> the history is
[14:08] <Daemon404> ubitux, i have a dream where ffmpeg in general gets a stabelish api
[14:09] <Daemon404> this will never happen
[14:09] <wm4> I'd really much rather have something like vsynth, that allows everyone to contribute, without having to go through ffmpeg-devel patch review
[14:09] <wm4> or worrying about politics
[14:09] <ubitux> you dont have to care about it once it's in 
[14:09] <nevcairiel> stable api means stagnation
[14:09] <ubitux> since we will maintain it for you
[14:09] <Daemon404> wm4, you can add vs support with it's c api now
[14:09] <Daemon404> jst fyi
[14:09] <wm4> I know
[14:09] <Daemon404> [13:09] <+nevcairiel> stable api means stagnation <-- bullshit
[14:09] <ubitux> with current model it means stagnation
[14:10] <ubitux> look how much trouble we have to deal with bumping api every time
[14:10] <nevcairiel> i'm right and you know it
[14:10] <Daemon404> there's a reason teh libav* apis are soe of the most reviled apis in foss
[14:10] <Daemon404> second maybe to gtk
[14:10] <wm4> Daemon404: what about libpng and libjpeg
[14:10] <wm4> I was just recently amazed how bad these are
[14:10] <Daemon404> libjpeg is pretty awful
[14:10] <Daemon404> but not libav* awful
[14:10] <wm4> setjmp error handling
[14:10] <Daemon404> what do i s/avfilter_start_frame/???/ 
[14:11] <nevcairiel> i think its just bad developers that think its so terrible, i think its pretty easy to simply get some stuff decoded
[14:11] <Daemon404> nevcairiel, tons of boilterplate for simple things, constantly changing api
[14:11] <iive> well, with libav things got really horrible
[14:11] <wm4> having to change your code every other month is objectively bad
[14:11] <ubitux> 14:03:35 <@ubitux> move start_frame content on top of your new filter_frame
[14:11] <Daemon404> the fact that there's a fourth audio decodde fucntion s pretty epic
[14:11] <ubitux> Daemon404: ^
[14:11] <Daemon404> ubitux, filter_frame callsavfilter_start_frame
[14:11] <cone-497> ffmpeg.git 03Clifford Wolf 07master:0ebfdae099d2: doc: Describe TB option of setpts filter
[14:11] <Daemon404> as well
[14:11] <cone-497> ffmpeg.git 03Michael Niedermayer 07master:35307df53c57: Merge commit '0ebfdae099d2749240b6a565abcdf0bf62589748'
[14:11] <Daemon404> if you noticed
[14:11] <nevcairiel> avfilter_start_frame simply goes out
[14:11] <ubitux> Daemon404: you remove that part
[14:12] <nevcairiel> you need to call ff_filter_frame instead after the frame is done
[14:12] <wm4> nevcairiel: also, you're sparred from the horror, because of your different distribution model
[14:12] <Daemon404> er, request_frame
[14:12] <Daemon404> nevcairiel, ic ok
[14:12] <ubitux> Daemon404: that's simple, you will just have one callback
[14:12] <Daemon404> nevcairiel doesnt have to support N versions
[14:12] <ubitux> called filter_frame
[14:12] <Daemon404> like we do
[14:12] <ubitux> and you fuck all the rest
[14:12] <Daemon404> ubitux, i see
[14:12] <Daemon404> so request frame is now filter frame?
[14:12] <ubitux> for request_frame you'll have to add a flag
[14:12] <nevcairiel> even i would provide a linux version, i wouldn't fucking care and just package the version i tested against
[14:13] <ubitux> (iirc)
[14:13] <Daemon404> what?
[14:13] <nevcairiel> screw distributions, if my project gets popular, they will cave and ship static or something :p
[14:13] <ubitux> might not even be needed
[14:13] <ubitux> it depends on the logic
[14:13] <Daemon404> heh
[14:13] <ubitux> Daemon404: it if filter_frame returns all the time something
[14:13] <ubitux> or no
[14:13] <Daemon404> also i may note there are no documents for developing a filter
[14:13] <ubitux> if it returns something all the time
[14:13] <ubitux> you don't care
[14:13] <ubitux> otherwise there is simple flag
[14:13] <Daemon404> so i can destroy request_frame?
[14:14] <ubitux> FF_LINK_FLAG_REQUEST_LOOP
[14:14] <wm4> nevcairiel: still, requiring git versions of things won't get you far in the Linux world
[14:14] <ubitux> that one ^
[14:14] <ubitux> Daemon404: likely yes
[14:14] <ubitux> that flag will say to filter_frame again
[14:14] <ubitux> until the filter push a frame to the next filter
[14:14] <ubitux> (to simplify)
[14:15] <ubitux> and iirc :)
[14:16] <ubitux> so anyway
[14:16] <ubitux> can anyone tell wtf is going on here:
[14:16] <ubitux> + * @note Pointers provided by av_malloc family of functions cannot be
[14:16] <ubitux> + * passed to av_realloc().
[14:16] <ubitux> ?
[14:16] <durandal_1707> well cant just fire sed script you need to understand what filter does...
[14:17] <wm4> ubitux: maybe s/av_malloc/malloc typo?
[14:17] <nevcairiel> ubitux: its a bit stupid on linux systems because memalign doesnt produce pointers that realloc understands
[14:17] <durandal_1707> you cant call av_realloc on something created by av_malloc*
[14:17] <nevcairiel> on windows it works because there is also a aligned realloc
[14:17] <ubitux> why not?
[14:17] <ubitux> the result might just not be aligned
[14:17] <ubitux> but it should work, right?
[14:18] <Daemon404> ugh
[14:18] <nevcairiel> if realloc needs to move the block, it wont be able to properly free it, i think, or something
[14:18] <Daemon404> this is an intertangled mess
[14:18] <nevcairiel> its a big mess
[14:18] <Daemon404> request_frame calls process_frame
[14:18] <Daemon404> aka filter_frame
[14:18] <ubitux> yes
[14:18] <Daemon404> i dont know wtf to move where
[14:18] <ubitux> kill it
[14:18] <wm4> if nothing says that memalign returns a realloc-able pointer, it may be implementation defined...
[14:18] <durandal_1707> that is little ugly you do not need it...
[14:19] <Daemon404> ubitux, well see
[14:19] <Daemon404> yadif uses request_frame
[14:19] <ubitux> Daemon404: think of the final result
[14:19] <Daemon404> still sets it even
[14:19] <ubitux> lemme check
[14:19] <ubitux> we might be able to remove it
[14:20] <ubitux> ask Nicolas
[14:20] <soul-d> heya all  finaly bit of action here  im kinda trying to develop  some hardware  decoder  for my lcd    tried  to visualize  where im stuck  here >  http://i.imgur.com/lWVFlsP.png could  use some pointers  on fileformat  markers 
[14:21] <durandal_1707> well yadif calls it in loop, w3fdif doesn't
[14:21] <soul-d> http://i.imgur.com/2IioCPk.png is also a sorta visual represantation what im trying to do 
[14:22] <ubitux> Daemon404: see 79d8cfacf07863500d4fedec669c49e2552c3876
[14:22] <ubitux> commit description
[14:22] <ubitux> Daemon404: and then look at the change just after in vf_tile: 77fa554b6e083191fab7f6aea596a93f2a389da7
[14:23] <Daemon404> heh
[14:23] <Daemon404> i dont care anymore
[14:23] <ubitux> which is basically removing a similar loop  to yadif
[14:23] <Daemon404> its not worth my effort
[14:23] <Daemon404> ill port to vs instead.
[14:23] <ubitux> hf
[14:23] <ubitux> but you'll need to understand the filter first
[14:23] <ubitux> anyway :)
[14:23] <Daemon404> i do
[14:23] <Daemon404> mostly
[14:23] <Daemon404> the difference is vs has examples and docs
[14:23] <Daemon404> for writing filters
[14:23] <Daemon404> good ones.
[14:24] <Daemon404> not just people on irc and random commit history
[14:24] <ubitux> plenty of examples in libavfilter/*.c
[14:24] <durandal_1707> so conclustion: you abandoned porting it to lavfi (i like to avoid dupe work)
[14:24] <Daemon404> yes.
[14:24] <Daemon404> ubitux, those rae not good examples
[14:24] <ubitux> okay
[14:24] <Daemon404> i mean exampels with LOTS of comments
[14:24] <Daemon404> abotu how it works
[14:24] <durandal_1707> ok, I wanted to procastinate porting of pullup little more anyway....
[14:26] <Daemon404> you guys can go back to your ffmpeg kool aid of "we dont need docs", "we dont need external filters", "we dont need stable apis"
[14:26] <Daemon404> etc
[14:26] <Daemon404> lavfi is a gift fro teh gods.
[14:26] <ubitux> who said that?
[14:26] <ubitux> having no docs does not mean we agree with that
[14:26] <Daemon404> you still fail
[14:26] <Daemon404> because
[14:26] <Daemon404> you do NOT introduce change
[14:26] <Daemon404> WITHOUT associaed docs
[14:27] <Daemon404> it should simply not be allowed.
[14:27] <ubitux> that's assuming there is an API base doc already
[14:27] <Daemon404> no
[14:27] <Daemon404> if tehre isnt one
[14:27] <Daemon404> write one
[14:27] <ubitux> which is not the case except doxy
[14:27] <Daemon404> it's especially important for api breakages
[14:27] <Daemon404> you NEED to write migration docs
[14:27] <ubitux> in that case complain to elenril for not writing one, but i dont agree with that
[14:27] <Daemon404> APIchanges one line notes are useless
[14:28] <ubitux> "libav defines the api", and in that lavfi case that was the case for most of it
[14:28] <Daemon404> yes you all have no concept of usability.
[14:28] <Daemon404> oh
[14:28] <Daemon404> ive yelled at elenril for years
[14:28] <Daemon404> nothing changes.
[14:28] <Daemon404> "patche welcome" is not OK to say when you break api without docs
[14:28] <Daemon404> it's pretty much the shitty FOSS stereotype.
[14:29] <ubitux> fork it and make it closed source then
[14:29] <ubitux> documentation will appear magically
[14:29] <Daemon404> i never said closed sorce was better
[14:29] <Daemon404> i said it's the foss stereotype.
[14:30] <Daemon404> basically, if you break api without writing the related docs / help, then fuck you
[14:30] <ubitux> honestly you're complaining for nothing
[14:30] <Daemon404> you are a lazy peiece of shit
[14:30] <ubitux> porting filters from old ffmpeg is all done mostly
[14:31] <Daemon404> thats your problem
[14:31] <Daemon404> you guys thing its all porting
[14:31] <ubitux> so writing a documentation just for a few backports is completely overkill given how much documentation for everything else we need
[14:31] <Daemon404> or filters chan be "done"
[14:31] <Daemon404> that is not true.
[14:31] <ubitux> and about new filters
[14:31] <ubitux> it's really straightforward
[14:31] <Daemon404> TO YOU
[14:31] <ubitux> and there are plenty of examples
[14:31] <Daemon404> THE FUCKING LAFI GUY
[14:31] <Daemon404> LAVFI*
[14:31] <ubitux> you're complaining about the old api mainly
[14:31] <Daemon404> sayign "it's simple!" is not a substitue for docs
[14:32] <ubitux> just look for a filter with the same design, copy it, and go for it
[14:32] <Daemon404> thats a shit attitude.
[14:32] <ubitux> there is no documentation
[14:32] <Daemon404> sorry.
[14:32] <ubitux> deal with it, or continue to complain
[14:32] <ubitux> but that wont help
[14:32] <wm4> is at least the current internal API documented?
[14:32] <Daemon404> "wants docs? go fuck yourself." -- ffmpeg
[14:32] <Daemon404> wm4, nope!
[14:32] <ubitux> wm4: doxycommented yes
[14:32] <ubitux> every callback is documented
[14:32] <ubitux> all flags are documented
[14:33] <Daemon404> doxy is not the same as proper documentation
[14:33] <Daemon404> becaue you hae to find what you need to use
[14:33] <nevcairiel> docs are overrated, i rather have a example and api doxy
[14:33] <ubitux> what's missing is an howto for writing a filter
[14:33] <Daemon404> and that is by far the hardest thing
[14:33] <Daemon404> doxy is useless if oyu dont know where to look.
[14:33] <durandal_1707> wm4: if you    l i k e   my patch then reply with LGTM
[14:34] <Daemon404> nevcairiel, https://github.com/vapoursynth/vapoursynth/blob/master/sdk/invert_example.c
[14:34] <Daemon404> this is what  consider a good example
[14:34] <nevcairiel> and to be honest, todays lavfi api is easy
[14:34] <Daemon404> not some uncommented prexisting filters
[14:34] <ubitux> this is a too simple example
[14:34] <ubitux> if you want the same, we have it already
[14:34] <Daemon404> you do not
[14:34] <Daemon404> note the comments
[14:35] <ubitux> you can find them in the doxy of each callback of the example
[14:35] <Daemon404> so read exmaple -> look up every used function
[14:35] <Daemon404> seems a bit.. cumbersome.
[14:35] <ubitux> use a shortcut in your editor
[14:35] <cone-497> ffmpeg.git 03Martin Storsjö 07master:a711a2cb473d: mpegvideo: Avoid 32-bit wrapping of linesize multiplications
[14:35] <cone-497> ffmpeg.git 03Michael Niedermayer 07master:3eeca8b0e4e0: Merge remote-tracking branch 'qatar/master'
[14:35] <cone-497> ffmpeg.git 03Michael Niedermayer 07master:2ffead98ddd3: avcodec: add emuedge_linesize_type
[14:36] <ubitux> to jump and go back to doxy
[14:36] <ubitux> even with vim you can do it
[14:36] <Daemon404> heh
[14:36] <ubitux> s/to/from/
[14:36] <Daemon404> i simply cannot agree with you on what constitutes a good and usable doc then
[14:36] <Daemon404> i can only agree to disagree.
[14:36] <Daemon404> luckily much of the general public is on my side.
[14:37] <ubitux> yes, but im not willing to port that ffmbc filter, so that doesn't change a thing for me
[14:37] <ubitux> Daemon404: ten thousands derpers won't help you with your filter
[14:37] <Daemon404> im porting it to vs instead
[14:38] <wm4> lavfi vs wrapper please
[14:38] <Daemon404> wm4, you can nevcairiel can mayeb speak about it
[14:38] <Daemon404> since nevcairiel is liekly ading vs to lav
[14:39] <wm4> I think I actually asked Myrsloik whether a libavformat vs demuxer could be written, but back then it still sounded like he had reservations (that was after the scripting API was added)
[14:40] <wm4> but maybe that's over now
[14:40] <Daemon404> wm4, i think the avs "demuxer" is strange too
[14:40] <durandal_1707> isn't porting to vs harder than to lavfi?
[14:40] <Daemon404> then agan we also have http "demuxers"
[14:40] <Daemon404> durandal_1707, HAHAHA
[14:40] <Daemon404> no
[14:40] <Daemon404> far far easier
[14:40] <wm4> for lavfi, there's the question how to handle the architectural differences
[14:40] <Daemon404> wm4, lavfi will be real messy
[14:40] <wm4> because the data flow is reverse
[14:40] <nevcairiel> http is a protocol, not a demuxer =P
[14:40] <wm4> maybe start a thread or so to buffer frames...
[14:41] <wm4> and define a max. amount of frames that can be buffered
[14:41] <wm4> also, I seriously hope libavformat won't open vpy files by default
[14:42] <Daemon404> wm4, the nfor example
[14:42] <Daemon404> we have teh frie0r wrapper
[14:42] <Daemon404> and mplayer wrapper
[14:42] <Daemon404> those would be similar, no?
[14:42] <wm4> and a wrapper wrapper?
[14:42] <Daemon404> lol
[14:42] <wm4> mplayer is very similar to lavfi
[14:42] <wm4> don't lnow about frei0r (also what's with these 0s)
[14:42] <wm4> *know
[14:42] <durandal_1707> how much memory you need?
[14:43] <well0ne> did anyone see zeranoe?
[14:44] <Daemon404> wm4, i know
[14:44] <Daemon404> i want mplayer's plugins to all die
[14:44] <Daemon404> in mpv
[14:44] <Daemon404> the entire thing.
[14:44] <durandal_1707> mplayer1 lives
[14:44] <wm4> that would be nice
[14:45] <Daemon404> mplayer1 is inbred
[14:45] <wm4> what's holding me back is actually users saying "but this filter isn't in libav!"
[14:45] <Daemon404> and terrible
[14:45] <Daemon404> wm4, and theyre all weird useless things, right?
[14:45] <Daemon404> :P
[14:45] <wm4> probably
[14:45] <wm4> things like vf_delogo
[14:45] <wm4> or whatever it was
[14:45] <nevcairiel> delogo can be quite useful
[14:45] <Daemon404> depends how you define useful
[14:46] <Daemon404> id rather have a logo than a crappy blurry patch
[14:46] <nevcairiel> and ffmpegs was improved recently
[14:46] <wm4> at least it's weird
[14:46] <ubitux> wm4: tell them to use drawbox
[14:46] <ubitux> a nice red square in place of the logo
[14:46] <nevcairiel> lol
[14:46] <ubitux> or overlay
[14:47] <wm4> hm actually Libav has vf_delogo
[14:47] <Daemon404> ubitux, square > blurry patch that flickers
[14:47] <Daemon404> :D
[14:47] <ubitux> like you put a giant dick in front of the logo
[14:47] <Daemon404> also superior
[14:47] <wm4> maybe it was vf_removelogo
[14:47] <ubitux> (even animated!)
[14:47] <wm4> wasn't there something on darkhold about animated dicks with ASS
[14:48] <Daemon404> yes
[14:48] <Daemon404> yes there was.
[14:48] <wm4> I hope nobody reads this line out of context ever
[14:48] <ubitux> i'm afraid the context doesn't help much
[14:49] <mateo`> wm4: i did
[14:49] <Daemon404> wm4, an for the record
[14:49] <Daemon404> it was penises that shoot lazers.
[14:49] <durandal_1707> Daemon404: what is going to be added to w3fdif ?
[14:49] <wm4> ok...
[14:50] <Daemon404> durandal_1707, threading
[14:50] <Daemon404> and cleanup
[14:50] <Daemon404> i'd wait for the new version
[14:50] <durandal_1707> internal threading ?
[14:51] <durandal_1707> but i heard that ffmbc is going to be assimilated by ffmpeg
[14:51] <JEEB> lol
[14:51] <Daemon404> [12:16] < Daemon404> mdsh, how do you feel about me upstreaming your w3fdif filter to ffmpeg?
[14:51] <Daemon404> [12:18] < mdsh> Daemon404: if you have the time then feel free, but I'm just starting to make a faster version that can multi-thread - all I need as a free weekend...
[14:51] <nevcairiel> hm
[14:52] <well0ne>  I'll pay 10 ¬ to anyone how does 1-2 line patching in latest code && compile it for me w32/w64
[14:52] <nevcairiel> he cant be using the new lavfi threading
[14:52] <nevcairiel> so guess he will invent his own
[14:52] <durandal_1707> well0ne: patching of what?
[14:53] <well0ne> well i'm on windows and i want to use the  -headers funtction to send an additional http header
[14:53] <well0ne> unfortunately the windows shell does not accept to set an command argument with a newline
[14:53] <well0ne> but thats required
[14:53] <nevcairiel> use a bash shell then?
[14:53] <well0ne> lol?
[14:54] <nevcairiel> you can run bash on windows, you know
[14:54] <well0ne> i tried
[14:54] <well0ne> no success
[14:54] <well0ne> even no newline is beeing submitted
[14:56] <well0ne> so i tried to install the toolchain by zeranoe, but  my  gcc is not working well with his script, so building failed
[14:56] <well0ne> dont know howto continue
[14:58] <well0ne> hmm
[15:39] <ubitux> hey
[15:40] <ubitux> something is wrong with the examples
[15:40] <ubitux> filtering video does invalid read at least when freeing the frame
[15:40] <ubitux> it looks like a misusage of the avbuffer api
[15:40] <ubitux> can anyone confirm?
[15:40] <ubitux> saste_: you might know
[15:41] <wm4> ubitux: which file and line?
[15:43] <ubitux> http://pastie.org/private/kyqo6zqnmpkzhwefkfksq
[15:43] <ubitux> huh why private, im stupid
[15:43] <ubitux> whatever
[15:43] <ubitux> so filtering_video.c L240
[15:46] <wm4> hm, does it just forget to enable refcounting?
[15:47] <wm4> also, so much code
[15:47] <wm4> whoever designs APIs should be forced to write a complete example for it
[15:48] <ubitux> there is not that much code oO
[15:48] <ubitux> refcounting is not enabled by default?
[15:48] <wm4> no
[15:48] <ubitux> meh
[15:49] <wm4> because compatibility
[15:49] <wm4> (that was fun to debug, until I found out that you have to enable it explicitly)
[15:49] <saste_> ubitux, is that a regression?
[15:50] <saste_> I test examples from time to time, whenever I have to update them
[15:50] <ubitux> saste_: reproducible with 2.0
[15:50] <saste_> is the bug always reproducible?
[15:51] <ubitux> yes
[15:51] <ubitux> ffmpeg -f lavfi -i testsrc -t 1 test.avi
[15:51] <ubitux> comments the puts() in the example to avoid cluttering the output
[15:52] <wm4> also, sigh, still mencoder users around...
[15:52] <ubitux> then PKG_CONFIG_PATH=pc-uninstalled make filtering_video 
[15:52] <ubitux> and (valgrind) ./filtering_video test.avi
[15:52] <ubitux> sometimes it crashes, depending on the video
[15:52] <ubitux> gonna check with the ref counting but well... im wondering why it wasn't noticed
[15:54] <saste_> ubitux, problem detected with valgrind
[15:55] <ubitux> much better with the refcounting enabled
[15:55] <ubitux> thx wm4!
[15:55] <wm4> "better"? still some errors left?
[15:56] <ubitux> MUCH better
[15:56] <ubitux> ERROR SUMMARY: 0 errors from 0 contexts 
[15:56] <ubitux> not so sure about the memory
[15:56] <wm4> nice
[15:57] <wm4> please note that buggy example will make devs who have to use your library hate you most
[15:57] <ubitux> i still have some leaks
[15:57] <wm4> so it's worth putting effort into that
[15:57] <ubitux> yeah i agree
[15:58] <Compn> well0ne : use cygwin term ?
[15:59] <well0ne> no, ubuntu 12.04 cross compiling
[15:59] <Compn> well0ne : i mean, it works on linux you say ?
[15:59] <well0ne> by zeranoes script
[15:59] <Compn> the newline in http header
[15:59] <well0ne> yes it does
[15:59] <Compn> does it work on cygwin term on windows ?
[15:59] <well0ne> i think its working i didnt tried, just covered up you cant pass a newline as commands argument in windows
[16:00] <well0ne> i tried already other shells, even no success
[16:01] <Compn> shells? but terminal is the problem? heh
[16:01] <well0ne> terminal häh?
[16:01] <Compn> cygwin and rxvt on windows
[16:01] <well0ne> what are you talking bout, 
[16:01] <well0ne> i tried win-bash
[16:01] <Compn> you are talking about cmd.exe ?
[16:01] <well0ne> sure iam
[16:01] <Compn> i dont know what winbash uses
[16:02] <well0ne> cygwin
[16:02] <Compn> oh ok, then probably you need some patch
[16:02] <Compn> can -header accept .txt file ?
[16:02] <well0ne> i know, but i cant get my toolchain to work
[16:02] <Compn> oh you just need someone to compile a patch ?
[16:03] <well0ne> it would take some seconds to patch it in the http.c
[16:03] <well0ne> my problem is that my  toolchain is not build (by zeranoe) w32/w64
[16:03] <cone-497> ffmpeg.git 03Clément BSsch 07master:98b9bbb787bb: doc/examples: remove extra "the".
[16:03] <cone-497> ffmpeg.git 03Clément BSsch 07master:2c1eb38e5ef4: avcodec: fix AVpacket ’ AVPacket typo.
[16:03] <Compn> ah
[16:03] <cone-497> ffmpeg.git 03Clément BSsch 07master:dc8f732292fc: doc/examples: fix lib math dep for resampling_audio.
[16:04] <well0ne> so i'm not able to compile , even to try my patch
[16:04] <well0ne> internal compiler error: in c_builtin_function_ext_scope, at c/c-decl.c:3633
[16:04] <well0ne> geeee
[16:05] <ubitux> saste_: so anyway, this helps: http://pastie.org/8297577
[16:05] <ubitux> but still leaking
[16:07] <saste> is that option from the fork or compatibility stuff?
[16:08] <ubitux> it's the same in the fork afaict
[16:08] <saste> weird, because it has not even an help field
[16:09] <ubitux> we need the same example with scaling
[16:09] <ubitux> (for instance)
[16:09] <ubitux> to have a clue about the buffer stuff only
[16:09] <ubitux> not entangled with lavfi buffer management
[16:13] <ubitux> i wonder what we are supposed to do in case we dont use the refcounted api..
[16:15] <wm4> saste: when I mentioned this, I got a RTFM thrown against my head
[16:15] <wm4> saste: apparently it's buried in the doxygen for something else
[16:16] <wm4> ah no, the actual refcounted_frames field has doxygen
[16:17] <ubitux> ffprobe which isn't using the new api is actually leaking it seems
[16:17] <ubitux> ah my bad that leak is sth else
[16:18] <ubitux> ah ok, it's on the stack...
[16:18] <wm4> ubitux: so does the example work pre-TEP?
[16:19] <ubitux> i dont think it even builds
[16:19] <ubitux> its using the new avframe api
[16:19] <ubitux> but badly
[16:21] <wm4> so why use the avoption API?
[16:21] <wm4> to set that flag
[16:24] <ubitux> no idea
[16:28] <ubitux> http://pastie.org/8297619 here is the remaining leaks after switch to new api
[16:54] <cone-497> ffmpeg.git 03Nicolas George 07master:d5b58f678dcb: tools: add benchmark for crypto functions.
[16:54] <cone-497> ffmpeg.git 03Nicolas George 07master:d7ccfe58e3a3: lavc/libvorbisdec: do not return empty frames.
[16:54] <cone-497> ffmpeg.git 03Nicolas George 07master:83635ac67bc3: ffprobe: show bitmap subtitles size.
[16:54] <cone-497> ffmpeg.git 03Nicolas George 07master:04dcdc464087: lavc/avfft: init context to 0.
[17:32] <jangle_> I"m trying to use libswscale in my code.  but the linker is complaining that symbols found in the library can't be resolved.  are there other library dependencies for libswscale?
[17:33] <nevcairiel> if anything, only avutil
[17:35] <Daemon404> isnt this what pkg-config is for
[17:40] <ubitux> [NULL @ 0xabf0580] start time is not set in estimate_timings_from_pts
[17:40] <ubitux> am i doing sth wrong?
[17:46] <durandal_1707> what are you doing?
[17:47] <ubitux> gonna send a patch in a moment so you can try
[17:52] <durandal_1707> saste: so can that code in yadif request_frame be simplified?
[17:56] <mateo`> ubitux: nice patch :)
[17:56] <ubitux> if you say so..
[17:57] <ubitux> i tried to keep it as simple as possible
[17:57] <ubitux> with random ± useful explanations
[17:58] <ubitux> so anyway
[17:58] <ubitux> durandal_1707: with the patch on the ml:
[17:58] <ubitux> http://pastie.org/8297916
[17:59] <mateo`> will give it a try this evening
[17:59] <ubitux> maybe michaelni_ knows more, since that's his favorite sample
[18:00] <durandal_1707> explanations are to short, just single line
[18:00] <durandal_1707> did you read invert sample Daemon404 linked?
[18:01] <mateo`> ubitux: i mean the patch, not the weird sample :)
[18:01] <ubitux> durandal_1707: i can add some lorem ipsum if you want
[18:01] <jangle_> Daemon404: was that to me?
[18:01] <ubitux> or just copy/paste the doxy from each function, for developers which are unable to configure their editor
[18:01] <durandal_1707> also where is filtering example?
[18:02] <jangle_> nevcairel: thanks I'll take a look
[18:02] <ubitux> same directory, filtering_{audio,video}.c
[18:02] <durandal_1707> ubitux: not that, when writing new ones...
[18:04] <ubitux> ah yeah
[18:04] <ubitux> Daemon404 derped to much today, so i have an excuse for not doing what he asked for
[18:04] <Daemon404> i didnt ask you for anything
[18:04] <Daemon404> pls2not lie
[18:05] <ubitux> yeah you just insulted everyone
[18:05] <ubitux> for not doing something you want
[18:05] <Daemon404> for not writing docs for their own changes?
[18:05] <ubitux> right
[18:05] <ubitux> (even though they do actually)
[18:05] <Daemon404> "docs"
[18:06] <ubitux> here we go again
[18:10] <durandal_1707> i wonder how this w3fdif works at all, it overreads coef_lf
[18:12] <durandal_1707> actually it doesn't overread
[18:12] <durandal_1707> its just dead code
[18:44] <saste> ubitux: i'm afraid if we have too many examples then users will be confused
[18:44] <saste> also it's more code to maintain, and it's not like example code is sexy to many developers
[18:44] <durandal_1707> how?
[18:44] <saste> filtering video, decoding, decoding_video
[18:44] <saste> also demuxing
[18:45] <durandal_1707> so what?
[18:45] <saste> what example should the user look for?
[18:45] <durandal_1707> there should be useful examples
[18:45] <durandal_1707> that explain everything
[18:46] <durandal_1707> to stop dumb questions on ml and irc
[18:50] <wm4> I think the main problem is that simple things need lots of code
[18:50] <wm4> because the API is low level
[19:15] <ubitux> yes
[19:15] <ubitux> examples do too much things
[19:15] <ubitux> and don't detail some essential ones
[19:34] <Compn> theres no simple answer to documentation
[19:34] <Compn> some users want more, some users want less
[19:34] <Compn> some dont read documentation and want to talk to people to get answers
[19:34] <Compn> i think we can all agree we need more comments in the source code :)
[20:08] <saste> Compn, not even that, well written code should not need comments ;-)
[20:17] <Daemon404> do we have any of that?
[20:21] <durandal_1707> yes, it resides in libswscale
[21:22] <cone-497> ffmpeg.git 03Michael Niedermayer 07master:9cbb3fce5965: avcodec/avpacket: zero memory in av_packet_new_side_data()
[21:48] <ubitux> http://syntaxi.net/2013/01/20/storyboard/ fun
[21:53] <llogan> ubitux: nice find. also, good example. the cape.
[21:54] <ubitux> the guy is using recent features, that's nice
[21:54] <ubitux> ffprobe writers, scene detection, ...
[21:54] <ubitux> :)
[21:54] <ubitux> and possibly the gif encode
[21:55] <llogan> maybe i'll ping him with the format=rgb8,format=rgb24 hack (if that still somewhat helps..can't remember. lazy.)
[21:57] <ubitux> no
[21:57] <ubitux> not necessary anymore
[21:57] <ubitux> so please don't ;)
[21:57] <relaxed> he could have hardsubbed using ffmpeg
[21:58] <ubitux> yeah
[21:58] <llogan> i would have tested first, of course, but thanks anyway
[21:59] <relaxed> but still, that is a cool project
[22:00] <cone-497> ffmpeg.git 03Clément BSsch 07master:bc68927a0f2c: tools/crypto_bench: fix 2 typos.
[22:14] <cone-497> ffmpeg.git 03Clément BSsch 07master:36cd017acd9c: avformat: make avformat_close_input() more tolerant.
[22:14] <cone-497> ffmpeg.git 03Clément BSsch 07master:3e1f507f3e8f: avcodec: make avcodec_close() more tolerant.
[22:18] <BBB> ubitux: how's simd?
[22:19] <cone-497> ffmpeg.git 03Clément BSsch 07master:f9742896713d: doc/APIchanges: update hashes and dates after last two commits.
[22:19] <ubitux> BBB: nothing done yet
[22:19] <ubitux> BBB: i'll probably start this week end
[22:21] <BBB> ko
[22:21] <BBB> ok
[22:45] <durandal_1707> michaelni: mpeg4 in nut seems to give wrong fps like lxf
[23:16] <michaelni> durandal_1707, just tried storing 25fps video in nut and i get "25 fps"
[23:22] <Compn> stream copy or new stream ?
[23:54] <michaelni> i tried both, now, neither shows a wrong value, stream copy looses the fps information though. -> closed invalid (no reproduceable testcase)
[23:57] <michaelni> and no time guessing, there are real bugs with complete testcases on trac
[23:57] <michaelni> my time is much more efficiently spend there
[00:00] --- Thu Sep  5 2013