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

burek burek021 at gmail.com
Fri May 24 02:05:02 CEST 2013


[02:05] <ubitux> so pedantic ;)
[02:18] <llogan> i am the new diego.
[03:06] <ubitux> wow the frame buffering overlay logic is crazy.
[03:50] <cone-780> ffmpeg.git 03Dale Curtis 07master:c54a1565f512: avformat/utils: Keep internal and external av_read_frame() packets in sync.
[10:30] <cone-549> ffmpeg.git 03Janne Grunau 07master:3eae9b030cbb: mpegvideo: unref buffers in ff_mpeg_unref_picture on frame size changes
[10:30] <cone-549> ffmpeg.git 03Michael Niedermayer 07master:1724123c65b5: Merge commit '3eae9b030cbbdc263f69834b791624613032d548'
[10:40] <cone-549> ffmpeg.git 03Anton Khirnov 07master:f36d7831d96a: pixdesc: mark gray8 as pseudopal
[10:40] <cone-549> ffmpeg.git 03Michael Niedermayer 07master:1fded9b69cc7: Merge commit 'f36d7831d96aeb072db5a2b78892a534d96e288e'
[10:54] <cone-549> ffmpeg.git 03Luca Barbato 07master:3f0b6d7a6248: wavpack: use bytestream2 in wavpack_decode_block
[10:54] <cone-549> ffmpeg.git 03Michael Niedermayer 07master:402bec52d4d3: Merge commit '3f0b6d7a6248a33df37b98cfcb37a1acce263f62'
[11:05] <cone-549> ffmpeg.git 03Luca Barbato 07master:fd06291239c1: wavpack: check packet size early
[11:05] <cone-549> ffmpeg.git 03Michael Niedermayer 07master:b7d16dc4bd21: Merge remote-tracking branch 'qatar/master'
[11:36] <ubitux> durandal_1707: i'll review colorlevels today
[11:36] <ubitux> in maybe an hour
[11:37] <ubitux> durandal11707: 11:36:13 <@ubitux> durandal_1707: i'll review colorlevels today
[11:42] <durandal11707> ubitux: got first one already, you can pm next time for that
[12:07] <cone-549> ffmpeg.git 03Paul B Mahol 07master:591fa0527827: doc/general: remove obsolete info about APE decoder
[12:07] <cone-549> ffmpeg.git 03Paul B Mahol 07master:79f452f4e686: fraps: set avctx->color_range
[12:07] <cone-549> ffmpeg.git 03Michael Niedermayer 07master:ac2c52174fc6: avcodec/wavpack: remove ;;
[12:22] <cone-549> ffmpeg.git 03Paul B Mahol 07master:fbd0f91a3a04: escape130: switch to init_get_bits8()
[14:03] <cone-549> ffmpeg.git 03Darryl Wallace 07master:3e1604750707: s302m encoder
[14:53] <cone-549> ffmpeg.git 03Michael Niedermayer 07master:1d3476f258f8: postproc/postprocess_template: remove empty comments
[14:53] <cone-549> ffmpeg.git 03Michael Niedermayer 07master:ef43b9496b88: avcodec/mpegvideo: remove empty comments
[14:53] <cone-549> ffmpeg.git 03Michael Niedermayer 07master:e8c26557a4ee: avformat/mtv: remove empty comments
[15:13] <raulnuno> hello everybody
[15:15] <raulnuno> I come from #ffmpeg without any reply and I don't know where I have to ask this...
[15:15] <raulnuno> it's a quick question
[15:15] <raulnuno> regarding bug https://ffmpeg.org/trac/ffmpeg/ticket/1444
[15:16] <raulnuno> I'm trying to get the last frame using duration
[15:16] <raulnuno> but I get an error with the "Output file is incorrect, nothing was encoded" message
[15:17] <raulnuno> seems duration keeps being incorrect
[15:21] <roxlu> hey 
[15:22] <roxlu> I asked this in #libav-devel too, but it looks like there are not much windows developers there :). 
[15:22] <roxlu> I want to compile libav (libavutil, codec,filter etc..) for windows 
[15:22] <roxlu> and found this description: http://libav.org/platform.html#Microsoft-Visual-C_002b_002b 
[15:23] <roxlu> Now, my question: why does the build prefer /MT and not /MD as I think that /MT makes distributing the application difficult because it links with the runtime of that platform if I'm correct
[15:23] <funman> you can build for windows with gcc
[15:43] <cone-549> ffmpeg.git 03Michael Niedermayer 07master:eee19198ef5a: avcodec/libfaac: fallback to a supported bitrate if the requested is not supported
[17:30] <cone-549> ffmpeg.git 03Clément BSsch 07master:288f91664302: lavfi/testsrc: move color options to the color scope filter definition.
[17:30] <cone-549> ffmpeg.git 03Clément BSsch 07master:a0a41db3398e: lavfi/testsrc: make nb_decimals available only in testsrc.
[17:30] <cone-549> ffmpeg.git 03Clément BSsch 07master:d51dfc7ec4f7: doc/filters: fix wording of color option in testsrc filters.
[19:13] <cone-549> ffmpeg.git 03Michael Niedermayer 07master:0fb7fef87941: tools/patcheck: fix misdetection with stuff like const_names
[19:17] <ubitux> Daemon404: a patch from justin for ffmpeg sent by you on ffmpeg-devel, i'm confused :p
[19:19] <Daemon404> thats fine
[19:19] <Daemon404> ;)
[19:28] <ubitux> argl, it might be simpler to integrate haldclut withing vf overlay than vf lut3d :(
[19:29] <durandal11707> why you think timing is so important?
[19:30] <ubitux> because the hald clut stream will likely be generated at constant frame rate
[19:30] <durandal11707> anyway in most usual case only single frame is gonna be used
[19:30] <ubitux> while your input might not be
[19:30] <durandal11707> afaik there are no such streams at all
[19:31] <ubitux> we could generate one with ffmpeg easily
[19:31] <ubitux> to optimize a color filtering process
[19:31] <durandal11707> and why would timing be important then?
[19:31] <ubitux> 19:30:02 <@ubitux> because the hald clut stream will likely be generated at constant frame rate
[19:31] <ubitux> 19:30:08 <@ubitux> while your input might not be
[19:32] <ubitux> ?
[19:34] <durandal11707> then generate it in variable frame rate
[19:34] <ubitux> how would you do that?
[19:34] <durandal11707> doesn't that means you will just skip some frames?
[19:36] <durandal11707> anyway i do not like sound of incorporating one filter into another just because of missing funcionality in framework
[19:36] <ubitux> imagine a vfr input with an avg fr at 25 fps, you generate a clut stream for one minute to process it, so -f lavfi haldclutsrc,curves,negate,whatever, you get a cfr 25 fps stream; now unless you have some heuristic in the haldclut filter just like overlay, it's the pts won't match
[19:36] <ubitux> durandal11707: i don't plan to actually hack into vf overlay
[19:37] <ubitux> that's just a remark to say that the current crazyness of frame buffers & pts handling in overlay should be out of it
[19:37] <durandal11707> anyway if timings are really so importan it should be available to all filters
[19:38] <ubitux> most filters with that multiple inputs model yes
[19:38] <ubitux> i quoted blend, but possibly some others
[20:15] <michaelni> durandal11707, as you pushed s302m you might want to reply https://github.com/FFmpeg/FFmpeg/pull/12#issuecomment-18358847
[20:22] <durandal11707> i have nothing to reply
[20:28] <Compn> hmm
[20:30] <Compn> s302m decoder copyright 2010 
[20:31] <Compn> do we have any other patches from 2010 that need to be merged ?
[20:31] <Compn> errr encoder*
[20:40] <michaelni> replied and closed the pull request
[20:41] <Daemon404> why do people send pull reqs anway
[20:52] <Compn> Daemon404 : is there a better way ?
[20:53] <Daemon404> .. the documented way thats on our contributing page?
[20:53] <Daemon404> which details how to contribute?
[20:56] <Compn> didnt michael ask people to make pull requests ?
[20:56] <Compn> maybe contributing page should be updated
[21:06] <michaelni> Compn, yes, pull requests are one of several ways to contribute
[21:18] <BBB-work> why would chrome's recent ffmpeg roll use 12mb more memory compared to a month earlier when playing 2k video?
[21:18] <BBB-work> did the refcounting changes introduce buffer copying when we input a non-ff-owned buffer through get_buffer api?
[21:20] <Daemon404> BBB-work, if you havent, you should probably witch to get_buffer2
[21:20] <Daemon404> but im not sure if the old get_buffer now copies
[21:20] <BBB-work> way2go on keepings things compatible :(
[21:21] <BBB-work> bah
[21:21] <Daemon404> it's compatible...
[21:21] <Daemon404> api-wise
[21:22] <Compn> BBB-work : didnt we just add a new j2k decoder ?
[21:22] <Compn> one that is supposed to be more feature complete for dcp users
[21:23] <Daemon404> what has that got to do with anything he just said
[21:24] <Daemon404> BBB-work, i could also be completely wrong btw
[21:24] <Daemon404> i.e. dont take my work for it
[21:24] <Compn> oh 2k video
[21:24] <Daemon404> also
[21:24] <Compn> i thought he said j2k...
[21:24] <Daemon404> chroem uses a bajillion gb of ram for websites
[21:25] <Daemon404> as it is
[21:25] Action: Daemon404 sorta luls at omg 12 mb
[21:25] <Daemon404> BBB-work, https://github.com/dwbuiten/d2vsource/compare/58af9033a4f56ce8e57356acc18cb6b17b594322...a6741ad0676214a65f18a747fce7a90b6282a685 <-- if there is a plan to switch, here's an example of switching from get_buffer to get_buffer2
[21:30] <llogan> roundup has returned.
[21:30] <Daemon404> i thought it was thrown into the great fires of hades
[21:35] <towolf> salve, is it a bug that i cannot use -vf setpts on the .ts output of the segmenter, or am i not using it correctly?
[21:37] <BBB-work> daemon404: for a chromebook, 12mb is a lot
[21:37] <llogan> towolf: that's probably a question for #ffmpeg
[21:38] <Daemon404> BBB-work, ah
[21:38] <Daemon404> yeah.
[21:38] <towolf> llogan, i posted there two hours ago, no replies.
[21:39] <Daemon404> Daemon404, it shoud be easy-ish to convert to get_buffer2... i'd do it if i wasn't terrified of chromium's codebase
[21:39] <Daemon404> er
[21:39] <Daemon404> BBB-work*
[21:39] <Daemon404> as if i just hilighted myself.
[21:39] <llogan> towolf: paste your link in #ffmpeg
[21:42] <llogan> i wonder how big the roundup samples collection is (considering mirroring it).
[21:54] <towolf> llogan, done, any idea?
[21:59] <cone-549> ffmpeg.git 03Paul B Mahol 07master:963c58006f9e: libaacplus: move profile check above, simplifies code a little
[21:59] <cone-549> ffmpeg.git 03Paul B Mahol 07master:6d53034483f6: libaacplus: cosmetics: fix indentation
[21:59] <cone-549> ffmpeg.git 03Paul B Mahol 07master:abf1e59ef2f7: libaacplus: return meaningful error codes
[22:13] <cone-549> ffmpeg.git 03Paul B Mahol 07master:cdc3f8f3072e: escape124: pass context to av_log()
[22:13] <cone-549> ffmpeg.git 03Paul B Mahol 07master:15b9c0b49ff3: escape124: switch to init_get_bits8()
[22:15] <durandal_1707> should we add tag for s302m in nut?
[22:15] <gnafu> Of course.
[22:22] <kierank> no because s302m is ts specific
[22:26] <durandal_1707> why is s302m marked as lossy, when it's not?
[22:51] <cone-549> ffmpeg.git 03Paul B Mahol 07master:d683271753be: lavc/codec_desc: SMPTE 302M is not lossy
[22:51] <cone-549> ffmpeg.git 03Paul B Mahol 07master:e75ddb7df5d2: s302menc: fix bits_per_raw_sample for 21, 22 & 23 case
[22:52] <durandal_1707> shit
[22:53] <cone-549> ffmpeg.git 03Paul B Mahol 07master:102848e3b6d6: s302menc: unbreak compilation
[00:00] --- Fri May 24 2013


More information about the Ffmpeg-devel-irc mailing list