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

[burek]

[00:21] <Vardan> hi all
[00:23] <Vardan> people I'm using AVFifoBuffer to buffer my AVFrame, but when I'm reading from buffer and show the frame on screen, it's showing the latest frame every time. As I understood that be cause in AVFrame there is data pointer which value always changing after each scale. Any suggestion? 
[00:25] <Compn> what you working on Vardan?
[00:26] <Vardan> I want to decode frames put them in buffer, and in other thread I'll check if buffer has time get it and show on screen
[00:26] <Vardan> *time=item
[00:26] <Vardan> it's video player
[00:26] <Compn> ah, no idea. ask on libav-user mailing list :)
[00:27] <Vardan> maybe you know how to duplicate AVFrame data?
[00:30] <Compn> i'm not much of a programmer Vardan , i dunno this stuff :)
[00:31] <Compn> some smarter person will wake up later, if you can wait
[00:34] <iive> Vardan: check get/release_buffer() callbacks. The decoder get_buffer() uses it to decode image, stores it for as long as it is needed for prediction and after returning its content to avframe, releases it.
[00:35] <iive> so basically, you have to either memcpy the image data along with the pts (presentation timestap) information to your buffer, or implement your own get/release functions.
[00:36] <Vardan> iive: any example?
[00:37] <iive> i would point mplayer-source/libmpcodecs/vd_ffmpeg.c probably the other players like vlc and xine have similar functions.
[00:37] <iive> not sure if there is api example in ffmpeg.
[00:39] <iive> another hack that comes into mind is that if the original/internal get/release functions are used, you may use them, just not release-ing the buffers until you are done playing them.
[00:41] <iive> actually, on second though, the filter system may already have something similar in implementation. 
[00:41] <iive> so looking at the source may be more useful.
[00:42] <Vardan> iive: my problem is when I add AVFrame in buffer, AVFrame's data member point to the same address as next AVFrame's data pointer
[00:43] <Vardan> be cause (I don't know why sws_scale write in the same place)
[00:43] <iive> yes, this is because same avframe structure is used, it is just filled with the info pointing to a different buffer.
[00:44] <iive> check codec_get/release_buffer(), it seems to do what you need. 
[00:46] <Vardan> can you please check my code http://pastebin.com/85Ps502F ?
[00:46] <Vardan> I add in buffer at line 121
[00:47] <Vardan> and read from there in line 136
[00:52] <Vardan> iive: are you looking to my code?
[00:52] <iive> yes.
[00:53] <Vardan> thanks
[00:54] <iive> basically the swscale should be enough to replace the need of memcpy, so in your case, you don't have to mess with get/release_buffers.
[00:56] <Vardan> when I read from buffer and print AVFrame->data pointer, it always print the same address
[00:56] <Vardan> as you can see I'm allocating pFrameRGB for each frame (line 115)
[00:57] <iive> data is an array, it contains 3 or 4 pointers to the real buffer.
[00:57] <iive> e.g. yuv420 have 3 planes so each one have its pointer into the data[]
[00:57] <iive> it's the same for the linesize/strides.
[00:58] <iive> rgb is planar, so it would contain only 1 valid pointer.
[00:58] <iive> i mean, rgb is packed.
[00:58] <Vardan> right, that is why for displaying I'm using data[0] only
[00:59] <Vardan> so, how to do that data[0] to point to different address for each frame?
[01:00] <Vardan> now it's point to the same address for each frame, and after each sws_scale it's write the last frame data there, that is why I see just latest frame in my screen
[01:01] <iive> the key point is the allocation of avframergb. let me check what the function you use actually does.
[01:01] <Vardan> this function: avcodec_alloc_frame() ?
[01:03] <iive> yes, I suspect that it allocates only the structure and does not fill any data. the swscale probably doesn't segfault because it detects null pointer and returns error.
[01:04] <iive> does not fill any data -> does not allocate any data buffers.
[01:06] <saste> michaelni: regarding av_frame_* accessors, should I use them whenever I'm accessing the corresponding fields from outside libavcodec?
[01:07] <saste> also why only *some* fields have the accessors?
[01:09] <Vardan> can't imagine what to do :(
[01:09] <iive> Vardan: you know what? swscale doesn't actually need AVFrame, you can just allocate 1280*720*4 buffer and present it to the destination, along with 1280*4 stride/linesize
[01:10] <michaelni> saste, which are missing accessors that would need them ?
[01:10] <saste> michealni: is that supposed to keep ABI compatibility with libav I suppose?
[01:11] <Vardan> int *b = malloc(1280*720*4);
[01:11] <saste> then only the last added fields have them, so seems right
[01:11] <michaelni> its for keeping ABI compatible to both 
[01:12] <saste> ok so I suppose i need to update some stuff in lavfi/avcodec and ffprobe
[01:13] <iive> Vardan: yes. atm I can't find  public function that would let you specify the pixfmt and dimension of your custom frame and allocate it. maybe somebody else could. after all get_buffer is what allocate picture buffer for avframe.
[01:13] <iive> Vardan: btw, *4 for 32bit rgb, *3 for 24. aka 24/8
[01:14] <Vardan> ok, let me try with buffer malloc. ..
[01:14] <iive> you can still use avframe if you like. e.g. avframergb->data[0]=b; in the above example.
[01:16] <Vardan> but for displaying I need linesize not only data[0]
[01:17] <Vardan> if I'll store data[0] in int *b = malloc(1280*720*3); then from where I should get linesize to display?
[01:17] <iive> you can linesize[0]=1280*24/8; too.
[01:19] <Vardan> you mean the linesize is the same for all frames?
[01:19] <iive> and copy few other fields as well, pts, keyframe
[01:20] <iive> no, linesize is the byteoffset between 2 vertical neighbor pixels.
[01:21] <iive> in your case one pixel is 4 bytes, so pixel_width*4 is good enough for it. the linesize could be larger if there are invisible pixels (padding).
[01:22] <Vardan> 1280*24/8 = width * 24 bit / 8?
[01:22] <iive> yes, for packed format.
[01:23] <Vardan> all my frames have same width, so that will be the same linesize
[01:23] <iive> yes.
[01:23] <Vardan> so, the linesize  will be the same for all frames
[01:24] Action: Daemon404 isnt sure why youd want to assume that
[01:25] <iive> for now, he just wants to make it work.
[01:25] <Daemon404> fair enough
[01:26] <Daemon404> humm
[01:26] <Daemon404> why isnt he using get_size
[01:26] <saste> iive: what about lavu/imgutils for allocating/copying image data?
[01:27] <Daemon404> thats the best method
[01:27] <iive> i was just looking for something like that :)
[01:27] <iive> i forgot that it was moved to avutil.
[01:27] <Daemon404> avpicture_get_size 
[01:28] <Daemon404> there's even functions for copying to a contiguous buffer :)
[01:28] <saste> Daemon404: i plan to move that to lavu as well
[01:28] <Daemon404> saste, sure
[01:28] <Daemon404> as long as they dotn go away
[01:31] <iive> avpicture_* are in libavcodec
[01:32] Action: Daemon404 assumes thats why saste said he was moving them to lavu
[01:33] <iive> why AVPicture doesn't store any additional info, e.g. width and height?
[01:35] <Daemon404> iive, you want AVFrame
[01:35] <Daemon404> AVPicture is a subset of it
[01:46] <iive> Daemon404: but these functions can't work with avframe.
[01:46] <iive> you need to go back and forth...
[01:47] <CIA-119> ffmpeg: 03Stefano Sabatini 07master * rb583ccc3db 10ffmpeg/libavcodec/rawdec.c: lavc/rawdec: propagate duration from packet to frame
[01:47] <CIA-119> ffmpeg: 03Stefano Sabatini 07master * r0b2ecf8224 10ffmpeg/libavcodec/imgconvert.c: lavc/imgconvert: remove pointless switch block from avpicture_fill()
[01:47] <CIA-119> ffmpeg: 03Stefano Sabatini 07master * r18b4404dc3 10ffmpeg/libavcodec/imgconvert.c: 
[01:47] <CIA-119> ffmpeg: lavc/imgconvert: fix check on av_image_check_size() return code in avpicture_get_size()
[01:47] <CIA-119> ffmpeg: The documentation states that av_image_check_size() will return a
[01:47] <CIA-119> ffmpeg: negative value in case of error, while the check is done on ret != 0.
[01:47] <CIA-119> ffmpeg: Also return a proper error code rather than -1 in case the check fails.
[01:47] <CIA-119> ffmpeg: 03Stefano Sabatini 07master * rc90e8054af 10ffmpeg/libavcodec/avcodec.h: 
[01:47] <CIA-119> ffmpeg: lavc/avcodec.h: fix reference to nonexistent function in av_picture_copy() doxy
[01:47] <CIA-119> ffmpeg: Mention av_image_copy() instead.
[01:48] <durandal_1707> 12bit pcm
[01:51] <durandal_1707> IACT chunks in san apparently use 12 bit pcm at 22050 hz
[01:52] <durandal_1707> so looks like i need to write pcm_s12 decoder
[01:53] <durandal_1707> but there are different versions even with IACT chunk
[01:56] <Vardan> iive: if I write this: uint8_t *frameData = malloc(1280 * 720 * 3); & scale with pFrameRGB (AVFrame struct)& frameData = pFrameRGB->data[0]; will frameData get pFrameRGB->data[0]; value? or frameData will point to the same address as pFrameRGB->data[0]?
[01:57] <iive> a=5;
[01:57] <iive> b
[01:57] <iive> oops
[01:58] <iive> a=b;
[01:58] <iive> would 'b' be 5?
[01:58] <Daemon404> iive, you can pass an AVFrame as an AVPicture you know
[01:58] <Daemon404> since AVPicture is a subset
[01:59] <iive> btw, sorry for not noticing this is the developer channel, should have moved to #ffmpeg long ago.
[01:59] <Daemon404> ;p
[02:01] <iive> no, it is not. it just happens to start with same fields.
[02:01] <iive> if it was subset, it would have used AVPicture :P
[02:01] <iive> i mean, superset.
[02:02] Action: iive should not give more ideas to libav master how to make the codebase even uglier :)
[02:06] <Vardan> iive: what do you think will this work? http://pastebin.com/xC3FDQgx
[02:06] <Vardan> iive: in real got this error: error: incompatible types when assigning to type 'uint8_t *[4]' from type 'uint8_t *'
[02:09] <iive> no, this is wrong.
[02:10] <iive> let's move to #ffmpeg, ok?
[02:10] <Vardan> need to ask again :( ?
[02:15] <Daemon404> iive, better not tell that to the buttload of code in ffmpeg that abuses that fact
[02:17] <Daemon404> may i add
[02:18] <Daemon404> even the api examples use this fact.
[02:18] <durandal_1707> so?
[02:20] <Daemon404> i wouldn't call it an invalid use if it is used all over the place, even by the people who designed it.
[02:21] <durandal_1707> but could be rewritten
[02:21] <Daemon404> that would cause major api and abi breakage
[02:23] <durandal_1707> so what just jump major
[02:24] <Daemon404> actually, the correct method is to deprecate them for a major release, and remvoe them the next
[02:24] <durandal_1707> whould there be any gain in doing that change?
[02:25] <Daemon404> (btw im pretty certain that avframe was explicitly made to have avpicture as a subset)
[02:25] <Daemon404> there's really no benefit to redoign everything so that ti doesnt use this fact
[02:26] <Daemon404> other than going "look ma!"
[02:28] <iive> Daemon404: i think avpicture is more recent than avframe, so it is likely the opposite :E
[02:29] <iive> durandal_1707: not any practical gain (aka the generated code should not change).
[02:29] <Daemon404> iive, uh no
[02:29] Action: durandal_1707 reading unreadable code 
[02:29] <Daemon404> according to git blame, avpicture was created by fabrice on teh very first commit
[02:29] <iive> just a few casts less and much more typing.
[02:30] <iive> Daemon404: ok, I'm wrong.
[02:30] <iive> Daemon404: was it data[4] and linesize[]?
[02:31] <durandal_1707> can anyone explain to me in simple terms what this code: https://github.com/scummvm/scummvm/blob/master/engines/scumm/smush/smush_player.cpp, line 438-468 is doing?
[02:31] <Daemon404> iive, im currently diving into 2001-2003 code
[02:31] <Daemon404> to find out
[02:31] <Daemon404> it's scary.
[02:33] <iive> "nobody goes there anymore"
[02:33] <llogan> "you should not have come here"
[02:33] <durandal_1707> it looks to me this is some stupid decompressor...
[02:34] <Daemon404> current i see AVFrame, formerly AVVideoFrame, used to be populated by FF_COMMON_PICTURE which had the contents of AVPicture
[02:34] <Daemon404> going further back in time..
[02:36] <Daemon404> iive, it originally was [3], but michaelni later chanegd it to for based on a request by fabrice, and this is what FF_COMMON_PICTURE was derived from
[02:36] <Daemon404> from what i  can scrap together from the svn logs
[02:37] <Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=commit;f=libavcodec/avcodec.h;h=d7425f59d5fc01bccde90cccd42ba592961b2d03 <-- the bad old days of commits having like 9 things
[02:37] <iive> llogan: ok, my quote should have been "We don't go there anymore." 
[02:38] <llogan> LGTM. applied.
[02:38] <iive> LOL
[02:38] <Daemon404> really.. that quote only makes me sad.
[02:39] <Daemon404> also im scared to think i was liek 12 when ffmpeg started....
[02:39] <durandal_1707> aw. good old days....
[02:40] <durandal_1707> there was no bikeshed about trailing whitespaces ...
[02:46] <durandal_1707> http://www.youtube.com/watch?v=C5fI5FlUwdc
[02:57] <iive> i've completely forgotten that game. I guess I should play it again.
[03:20] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * r80e857c967 10ffmpeg/libswresample/resample_template.c: 
[03:20] <CIA-119> ffmpeg: swr/resample: optimize C code for the most common case
[03:20] <CIA-119> ffmpeg: 15% speedup
[03:20] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[03:20] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * r0c142e4cda 10ffmpeg/libswresample/ (resample.c resample_template.c): 
[03:20] <CIA-119> ffmpeg: swr: introduce filter_alloc in preparation of SIMD resample optimisations
[03:20] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[03:33] <iive> n8 ppl
[12:08] <CIA-119> ffmpeg: 03Carl Eugen Hoyos 07master * rc47fc942d4 10ffmpeg/configure: 
[12:08] <CIA-119> ffmpeg: Fix dependencies for the atempo filter.
[12:08] <CIA-119> ffmpeg: Found, analysed and tested by trac user Jamal.
[12:08] <CIA-119> ffmpeg: Fixes ticket #1465.
[14:44] <brocatz> hi
[14:45] <brocatz> basically wanted to know what peoples opinion of https://ffmpeg.org/trac/ffmpeg/ticket/1463
[14:46] <brocatz> also if anyone is familiar with win32 builds on linux, i have read various websites and want to know it's not too much of a hassle before i give it a go, i'm not sure what kind of dependancies are going to be needed and how much hassle they are
[14:47] <brocatz> ideally if that patch is okay we could just get it accepted and i wont have to think about it agian, rather than maintaining our own ffmpeg build system as well
[14:47] <brocatz> i paid a guy to program that for us yesterday since researching it there were similar questions since 2009 at least on google
[14:47] <brocatz> figured if it was a fixable thing, and acceptable, i should just help get it done
[14:48] <brocatz> basically just want to use our normal popen() stuff with python to include ffmpeg into some windows automation we do
[14:49] <brocatz> anyway don't want to tread on anyones toes / piss anyone off, and i'm pretty sure no one probably cares that much about how ffmpeg interacts with win32
[14:50] <durandal_1707> actually everyone is pretty busy now and do not have time to answer
[14:50] <brocatz> sure thing
[14:50] <Compn> busy or sleeping
[14:50] <Compn> brocatz : win32 ffmpeg is easy to setup
[14:51] <Compn> win32 crosscompile i dont know, should be as easy as setting up the toolchain
[14:51] <brocatz> okay, ideally we wont have to maintain our own build of ffmpeg though in the future
[14:52] <Compn> as for the patch, have to wait until someone can review it :)
[14:52] <Compn> maybe michaelni
[14:53] <Compn> it looks ok, but it also looks like a lot of os-specific code just for one thing 
[14:53] <brocatz> well it makes ffmpeg act nicely if it's terminated through the gui or a break in windows in general
[14:54] <brocatz> right now it doesn't at all
[14:54] <Compn> sounds good then :)
[14:54] <brocatz> in a perfect world i'd just be sending a sigint
[14:54] <brocatz> the joy of windows
[14:54] <Compn> ffmpeg is working to have more windows support
[14:55] <Compn> even msvc support is in the works
[14:55] <brocatz> i keep using it for windows projects and all the foss software i use i tend to get clients to donate to
[14:55] <brocatz> but i see there is no way to do that with ffmpeg
[14:56] <Compn> we just partnered with a non-profit organization to handle our donations
[14:56] <brocatz> ok cool
[14:56] <Compn> should be a few weeks until we get a donate button up
[14:56] <Compn> depending on whos got the free time to work on it :)
[14:57] <brocatz> yeah i've looked for it a few times in the last few years
[15:29] <durandal11707> michaelni: does making filter source which produces smpte bars have more sense in RGB or in YUV colorspace?
[15:32] <Compn> you can do both
[15:32] <Compn> i think filters are mostly yuv tho
[15:32] <kierank> durandal11707: yuv
[15:33] <Compn> most codecs are yuv, so you will be scaling it every time if you make it rgb :P
[15:41] <saste> durandal11707: but rgb is usually easier to deal with (check testsrc for example)
[15:44] <durandal11707> hmm, where are mj2 files?
[15:49] <durandal11707> so mj2 is just mov or?
[15:50] <cbsrobot> never heard of mj2 - but sound like mjpeg2 in 8.3 format
[15:50] <durandal11707> mj2 is motion jpeg 2000
[15:56] <durandal11707> michaelni: AVClass in libaf do not need .category ?
[16:10] <michaelni> all AVClasses that are used for printing should probably get categories
[16:10] <durandal11707> but some of them do not have .category but still are colored
[16:11] <durandal11707> in libavfi case they where not
[16:13] <CIA-119> ffmpeg: 03Paul B Mahol 07master * ref8bea9107 10ffmpeg/libavformat/mov.c: 
[16:13] <CIA-119> ffmpeg: mov: use designated initializers for AVClass
[16:13] <CIA-119> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[16:13] <CIA-119> ffmpeg: 03Paul B Mahol 07master * r7238ed6c84 10ffmpeg/libavformat/avidec.c: 
[16:13] <CIA-119> ffmpeg: avidec: use designated initializers for AVClass
[16:13] <CIA-119> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[16:23] <michaelni> which av_log() call produces colored class info without category ?
[16:24] <durandal11707> avi demuxer
[16:24] <durandal11707> lol actualy not, it is white
[16:29] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * r97726e86be 10ffmpeg/libavutil/x86/intmath.h: 
[16:29] <CIA-119> ffmpeg: x86/intmath: fix type of FASTDIV
[16:29] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[16:29] <durandal11707> it is because that av_log use AVIOContext 
[16:53] <durandal_1707> and other avi lines have muxer color
[16:59] <saste> in this period of the year my computer gets slow, it was not designed to live in hot weather or to run FATE
[16:59] <saste> bloody dell studio...
[17:00] <CIA-119> ffmpeg: 03Stefano Sabatini 07master * r5793a6d9f9 10ffmpeg/libavcodec/libschroedinger.c: lavc/libschroedinger: add missing failure checks in ff_create_schro_frame()
[17:00] <CIA-119> ffmpeg: 03Stefano Sabatini 07master * r208c5a08da 10ffmpeg/libavcodec/qtrleenc.c: lavc/qtrlenc: return proper error codes from qtrle_encode_init()
[17:00] <CIA-119> ffmpeg: 03Stefano Sabatini 07master * rd5761fe47d 10ffmpeg/libavfilter/avcodec.c: lavfi/avcodec: copy pos field from AVFilterBuffer to AVFrame pkt_pos
[17:01] <CIA-119> ffmpeg: 03Stefano Sabatini 07master * r8f8d8b9538 10ffmpeg/libavfilter/avcodec.c: 
[17:01] <CIA-119> ffmpeg: lavfi/avcodec: always use av_frame* accessors in avfilter_copy_buf_props()
[17:01] <CIA-119> ffmpeg: Use av_frame_* accessors for the newly added fields in AVFrame (for which
[17:01] <CIA-119> ffmpeg: we are supposed to use such accessors), and group the istructions
[17:01] <CIA-119> ffmpeg: accordingly.
[17:01] <CIA-119> ffmpeg: 03Stefano Sabatini 07master * rdb142a8395 10ffmpeg/libavfilter/avcodec.c: 
[17:01] <CIA-119> ffmpeg: lavfi/avcodec: make avfilter_fill_frame_from*() functions use avfilter_copy_buf_props()
[17:01] <CIA-119> ffmpeg: The code in avfilter_copy_buf_props() is more generic, allow code
[17:01] <CIA-119> ffmpeg: factorization.
[17:01] <Compn> saste : you can stop running fate if it messes with your box you know :)
[17:02] <saste> Compn: how? i need to test stuff locally when i'm developing disruptive patches
[17:02] <saste> which unfortunately i'm doing in this period (messing with lavc/lavu)
[17:02] <Compn> oh make fate
[17:03] <Compn> well
[17:03] <Compn> find a shell 
[17:03] <Compn> ;P
[17:03] Action: Compn afk
[17:07] <durandal_1707> michaelni: i see no way how to find if item is demxer or muxer
[17:07] <durandal_1707> so category could be properly set
[17:10] <durandal_1707> michaelni: hmm, i could write function like format_to_name
[17:12] <michaelni> durandal_1707, theres patchset that adds get_category()
[17:12] <michaelni> on the ML
[17:12] <michaelni> ill apply it
[17:13] <durandal_1707> oww
[17:25] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * r82ac6a66f9 10ffmpeg/libavcodec/rv40dsp.c: 
[17:25] <CIA-119> ffmpeg: rv40dsp: use av_assert
[17:25] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:26] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * rb76f77ee0d 10ffmpeg/libavutil/log.c: 
[17:26] <CIA-119> ffmpeg: log: swap colors for muxer and codec layer
[17:26] <CIA-119> ffmpeg: This way the filters which are semantically closer to the codec layer
[17:26] <CIA-119> ffmpeg: have a (subjectively to me) more similar color.
[17:26] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:26] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * re69263cd01 10ffmpeg/libavutil/ (avutil.h log.c log.h): 
[17:26] <CIA-119> ffmpeg: avutil: add get_category() for the case where one AVClass can have more than 1 category
[17:26] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:26] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * r6fb7d03d74 10ffmpeg/libavcodec/options.c: 
[17:26] <CIA-119> ffmpeg: lavc: seperate encoder/decoder class category
[17:26] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:26] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * r08613d50d6 10ffmpeg/libavformat/options.c: 
[17:26] <CIA-119> ffmpeg: lavf: separate muxer/demuxer class category
[17:26] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:39] <Daemon404> saste / ubitux : ping
[17:39] <CIA-119> ffmpeg: 03Pavel Koshevoy 07master * r5fa8226420 10ffmpeg/libavfilter/af_atempo.c: (log message trimmed)
[17:39] <CIA-119> ffmpeg: libavfilter: improve atempo audio quality
[17:39] <CIA-119> ffmpeg: Reduce audio fragment alignment jitter by penalizing alignment
[17:39] <CIA-119> ffmpeg: correction offsets that deviate too much from the target offset.
[17:39] <CIA-119> ffmpeg: This is accomplished by multiplying the cross correlation search
[17:39] <CIA-119> ffmpeg: window with a quadratic function.
[17:39] <CIA-119> ffmpeg: Signed-off-by: Pavel Koshevoy <pavel at homestead.aragog.com>
[17:40] <ubitux> Daemon404: pong
[17:40] <Daemon404> so
[17:40] <Daemon404> im experience some extremely annoyign behavior with vf_scale
[17:40] <Daemon404> if i hard set it to x:y, it's fine
[17:40] <Daemon404> but if ido something liek calculate one side based on dar/sar
[17:40] <Daemon404> it tries ti be 'smart' and resizes differently
[17:41] <Daemon404> and sets the sra
[17:41] <Daemon404> sar*
[17:41] <Daemon404> how 2 force it to always resize and use a 1:1 sar
[17:41] <ubitux> there is a setsar filter
[17:41] <ubitux> iirc
[17:41] <ubitux> not sure if that would help
[17:42] <ubitux> btw anyone has any comment on the CSS for ffmpeg/web?
[17:42] <ubitux> i'll push it tonight i think
[17:42] <Daemon404> ...
[17:43] <Daemon404> '[...];setsar=1:1' does not have exactly one input and output.
[17:43] <Daemon404> wtf?
[17:43] <ubitux> ,
[17:43] <Daemon404> (i only appended setsar to the end)
[17:43] <ubitux> use ','
[17:43] <ubitux> (i guess)
[17:44] <ubitux> ';' is to separate "chains", and ',' to "queue" them
[17:44] <Daemon404> uhhhh
[17:44] <Daemon404> setsar made it go all sorts of crazy
[17:44] <ubitux> you have setdar too
[17:45] <Daemon404> ah nvm
[17:45] <Daemon404> no
[17:45] <Daemon404> setsar/setdar
[17:45] <Daemon404> do NOT do that
[17:45] <ubitux> i'm not doing it
[17:45] <Daemon404> scale sitll tries to be smart and doesnt resize at all
[17:45] <ubitux> :)
[17:45] <Daemon404> its infuriating
[17:45] <ubitux> i'm just suggesting stuff
[17:45] <Daemon404> filter thinks it knows better than me!
[17:45] <Daemon404> ;p
[17:45] <ubitux> setsar=...,scale=sar*... ?
[17:46] <Daemon404> wouldnt that fuck up the calculation
[17:46] <ubitux> no idea
[17:46] <Daemon404> since im calculating the height based on teh original sar
[17:46] <Daemon404> yeah it made no diff
[17:47] <Daemon404> hmm
[17:48] <Daemon404> i se ethe problem
[17:48] Action: Daemon404 fixes 
[17:55] <Daemon404> humm width = height * dar / sar is wrong
[17:55] Action: Daemon404 thinks his brain died
[18:10] <saste> ubitux: what do you think of the new showwaves?
[18:11] <durandal_1707> saste: can it work with ffplay?
[18:11] <saste> why not?
[18:12] <saste> ffplay -f lavfi -i "aevalsrc=sin(1*2*PI*t)*sin(880*2*PI*t):cos(2*PI*200*t),asplit[out0],showwaves[out1]"
[18:13] <durandal_1707> and with audio files?
[18:14] Action: durandal_1707 angry because ccache is not doing its job
[18:14] <av500> flog it
[18:14] <saste> ffplay -f lavfi -i "amovie=/home/stefano/s/slow.flv,asplit[out0],showwaves=r=60[out1]"
[18:15] <durandal_1707> saste: then push it
[18:15] <saste> durandal_1707: i'm waiting nicolas to reply to it, i addressed his comments
[18:16] <saste> then it would be fun to add background color and channel/color map options
[18:26] <durandal_1707> hah, demuxer lines are now bold pink ???
[18:27] Action: durandal_1707 ^ bikeshed
[18:27] <Daemon404> ubitux, turns out the problem was my own dumbness... i was using 'dar' where i should have been using (iw/ih)
[18:28] <RobertNagy> if set_common_formats is private and opaque shouldn't be null, how do I create a buffersink which takes any format?
[18:28] <CIA-119> ffmpeg: 03Paul B Mahol 07master * r6b9446e932 10ffmpeg/libavformat/avidec.c: 
[18:28] <CIA-119> ffmpeg: avidec: add .category
[18:28] <CIA-119> ffmpeg: While here make .class_name consistent with other AVClass.
[18:28] <CIA-119> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[18:30] <transplant> hi. if this is OT please tell me so. I'm trying to parallelize sws_scale in my app by calling two threads. One that scales the upper half of the image and one the lower. I tried to use the parameter srcSliceY for that but it doesn't seem to really work. Anybody ever used this parameter to value other than 0?
[18:30] <Zor> win 28
[18:31] <Zor> err, ignore that
[18:32] <durandal_1707> transplant: how it does not work?
[18:32] <transplant> i see two times the upper half
[18:36] <transplant> Given that srcSliceY + srcSliceH must be equal to total height if srcSliceY != 0
[18:36] <transplant> then is suspect that this is exactly the reason why this parameter exists in the first place
[18:39] <transplant> anyway. its a good idea, the api makes it easy but just can't make it work. ill look out for fixing commits. GTG
[18:44] <saste> RobertNagy: iirc there is currently no way, but you can still use the "deprecated" functions
[18:44] <RobertNagy> ic
[18:45] <saste> i plan to "undeprecate" them as soon as libav will apparently stop to mess with the public api
[19:20] <durandal_1707> saste: what those [color] strings after vsrc_color example means?
[19:21] <saste> durandal_1707: uh?
[19:21] <durandal_1707> in doc/filters.texi
[19:22] <saste> yep i was trying to save energy ;-), can you post the code?
[19:23] <durandal_1707> color=red@@0.2:qcif:10 [color]; [in][color] overlay [out]"
[19:23] <durandal_1707> "color=c=red@@0.2:s=qcif:r=10 [color]; [in][color] overlay [out]"
[19:24] <saste> durandal_1707: when there was no lavfi device, you had to use overlay to show a source
[19:25] <RobertNagy> saste: why not allow opaque or pix_fmts to be NULL if one doesn't care about the output format, I don't get the purpose of the warning that is currently printed
[19:25] <saste> now it is no longer required, so that example is overly complex (pun intended)
[19:26] <saste> RobertNagy: short answer, we recently merged from libav and that introduced some mess in the api, so there are a few things which don't make much sense
[19:26] <saste> long answer: patch
[19:26] <RobertNagy> ok
[20:09] <Daemon404> michaelni, does nut have a sar field?
[20:16] <Daemon404> hmm nvm
[20:18] <durandal_1707> hmm i fail to mux mp3 into nut
[21:13] <CIA-119> ffmpeg: 03Ronald S. Bultje 07master * rdb28b01dcf 10ffmpeg/libavcodec/dirac.c: 
[21:13] <CIA-119> ffmpeg: dirac: replace compound literal with normal initialiser
[21:13] <CIA-119> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[21:13] <CIA-119> ffmpeg: 03Martin Storsjö 07master * rbbc8038614 10ffmpeg/libavformat/rtsp.c: 
[21:13] <CIA-119> ffmpeg: rtsp: Send mode=record instead of mode=receive
[21:13] <CIA-119> ffmpeg: This seems to be the correct mode to send, according to the
[21:13] <CIA-119> ffmpeg: original RTSP RFC, and matches the method RECORD which is
[21:13] <CIA-119> ffmpeg: sent later when starting to send data.
[21:13] <CIA-119> ffmpeg: Darwin Streaming Server works fine with either of them.
[21:13] <CIA-119> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[21:13] <CIA-119> ffmpeg: 03Samuel Pitoiset 07master * r46743a859c 10ffmpeg/ (3 files in 2 dirs): (log message trimmed)
[21:13] <CIA-119> ffmpeg: rtmp: Don't send every flv packet in a separate HTTP request in RTMPT
[21:13] <CIA-119> ffmpeg: Add a new option 'rtmp_flush_interval' that allows specifying the
[21:13] <CIA-119> ffmpeg: number of packets to write before sending it off as a HTTP request.
[21:14] <CIA-119> ffmpeg: This is mostly relevant for RTMPT - for plain RTMP, it only controls
[21:14] <CIA-119> ffmpeg: how often we check the socket for incoming packets, which shouldn't
[21:14] <CIA-119> ffmpeg: affect the performance in any noticeable way.
[21:14] <CIA-119> ffmpeg: 03Martin Storsjö 07master * r3641b0489c 10ffmpeg/ (9 files in 3 dirs): 
[21:14] <CIA-119> ffmpeg: rtpenc: Support packetizing iLBC
[21:14] <CIA-119> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[21:14] <CIA-119> ffmpeg: 03Justin Ruggles 07master * r1168e29df1 10ffmpeg/libavresample/x86/ (audio_convert.asm audio_convert_init.c): lavr: Add x86-optimized function for s16 to s32 conversion
[21:14] <CIA-119> (16 lines omitted)
[21:14] <CIA-119> ffmpeg: 03Justin Ruggles 07master * rae46fbee1d 10ffmpeg/libavfilter/af_amix.c: af_amix: allow float planar sample format as input
[21:14] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * rcabbd271a5 10ffmpeg/: (log message trimmed)
[21:14] <CIA-119> ffmpeg: Merge remote-tracking branch 'qatar/master'
[21:14] <CIA-119> ffmpeg: * qatar/master: (24 commits)
[21:14] <CIA-119> ffmpeg:  flvdec: remove incomplete, disabled seeking code
[21:14] <CIA-119> ffmpeg:  mem: add support for _aligned_malloc() as found on Windows
[21:14] <CIA-119> ffmpeg:  lavc: Extend the documentation for avcodec_init_packet
[21:14] <CIA-119> ffmpeg:  flvdec: remove incomplete, disabled seeking code
[21:14] <CIA-119> ffmpeg: 03Ronald S. Bultje 07master * rbe1a839ca6 10ffmpeg/ (configure libavutil/mem.c): 
[21:14] <CIA-119> ffmpeg: mem: add support for _aligned_malloc() as found on Windows
[21:14] <CIA-119> ffmpeg: The check uses check_func_header, since this function is
[21:14] <CIA-119> ffmpeg: conditionally available depending on the targeted MSVCRT
[21:14] <CIA-119> ffmpeg: version.
[21:14] <CIA-119> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[21:28] <CIA-119> ffmpeg: 03Paul B Mahol 07master * r9e7543361c 10ffmpeg/ (doc/filters.texi libavfilter/vsrc_color.c): 
[21:28] <CIA-119> ffmpeg: lavfi/color: use AVOptions
[21:28] <CIA-119> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[21:38] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * r18d7bea695 10ffmpeg/libavcodec/mpegvideo_enc.c: 
[21:38] <CIA-119> ffmpeg: wmv2enc: fix rounding flag.
[21:38] <CIA-119> ffmpeg: Fixes Ticket1467
[21:38] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:05] <CIA-119> ffmpeg: 03Paul B Mahol 07master * r10952e0602 10ffmpeg/libavfilter/vsrc_color.c: 
[22:05] <CIA-119> ffmpeg: lavfi/color: fix typo
[22:05] <CIA-119> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[22:23] Action: llogan complains about cost of SMPTE stuff
[22:25] <durandal_1707> ?
[22:25] <Daemon404> he means specs
[22:25] <Daemon404> paywalls yo
[22:32] <llogan> i wonder if I can Inter-Library Loan them.
[22:32] <Daemon404> llogan, kierank may be able to help
[22:45] <CIA-119> ffmpeg: 03Paul B Mahol 07master * r420990db30 10ffmpeg/libavcodec/libilbc.c: 
[22:45] <CIA-119> ffmpeg: libilbc: use designated initializers for AVClass
[22:45] <CIA-119> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[23:00] <durandal_1707> y4mcolorbars output looks wrong
[23:39] <durandal_1707> michaelni: i think mp filter vf_pallete should be removed as it is doing swscale job
[00:00] --- Wed Jun 20 2012