[00:17] <Soyo> So I have a bunch of mp4 files that have this --> http://pastebin.com/mfzS1rme mediainfo results how would I convert that to something that Kino would work well with like a .DV file? [00:32] <Soyo> Keeps saying stream contains no data [00:32] <Soyo> file is 0 bytes [00:32] <Soyo> :/ [00:33] <llogan> Soyo: ffmpeg -i input.mp4 -target ntsc-dv output.dv [00:34] <Soyo> llogan: Thanks that seems to be doing something now [00:35] <llogan> i haven't seen anyone use Kino in some time [00:35] <Soyo> Yeah it is pretty old school [01:47] <llogan> does --extra-cflags and --extra-ldflags work with libraries that require_pkg_config, or is PKG_CONFIG_PATH generally used for those? [07:49] <kcm1700> where can I find deinterlace implementation in the ffmpeg library code? [07:51] <kcm1700> I found it, thanks [07:52] <JEEB> in the current ffmpeg code base there's the yadif filter for actual deinterlacing, and then there's a separate inverse telecine filter [07:59] <kcm1700> :) thanks [08:05] <thetruthisoutthe> hey [08:05] <thetruthisoutthe> http://www.rottentomatoes.com/m/zero_dark_thirty/ [08:05] <thetruthisoutthe> is this cool movie? [11:23] <superware> I'm trying to do something similar to http://ffmpeg.org/doxygen/trunk/doc_2examples_2demuxing_8c-example.html, but av_find_best_stream returns zero which can't be found in decode_packet: if (pkt.stream_index == video_stream_idx), any ideas? [11:24] <ubitux> are you able to make the example compile & work? [11:25] <superware> yes, av_find_best_stream returns 0 [11:27] <superware> ubitux: ? :| [11:29] <superware> the "file" is "udp://224.0.0.0:1234" which is a h.264 over TS [11:31] <superware> maybe 0 is ok, maybe pkt.stream_index isn't [11:31] <ubitux> if the example code works, then start from here, and modify it progressively [11:32] <superware> it "works", but (pkt.stream_index == video_stream_idx) is always false [11:32] <ubitux> maybe because there are multiple streams? [11:32] <ubitux> you need to wait for a video stream packet [11:34] <superware> that's open_codec_context(pvideo_stream_idx, _fmt_ctx, AVMediaType.AVMEDIA_TYPE_VIDEO) job [11:38] <superware> av_read_frame(_fmt_ctx, ppkt) sets _pkt.stream_index to values like 98141248, does it make sense? [11:43] <superware> anyone? :( [11:49] <Mavrik> you're probably passing a pointer where you shouldnt [11:49] <Mavrik> or the other way around [11:49] <Mavrik> or something is wrong with your linkage [11:51] <superware> well, the struct *is* being changed :) [11:51] <superware> after av_read_frame... [12:16] <superware> what's av_dump_format? [12:24] <superware> never mind [13:16] <superware> Mavrik: you here? :| [13:26] <superware> does it make sense that pkt.stream_index equals something like 98141248 after av_read_frame(fmt_ctx, &pkt) ? [13:30] <Mavrik> no. [13:30] <Mavrik> you're messing something up. [13:31] <superware> and I guess I'm doing it for hours now [13:32] <superware> I double checked, this is what I'm doing: http://ffmpeg.org/doxygen/trunk/doc_2examples_2demuxing_8c-example.html [13:43] <Mavrik> well, that can't be what you're doing since that is official doxygen for master git branch example [13:44] <superware> Mavrik: what do you mean? [14:00] <leandrosansilva> Hello to all. I'm using an i7 processor (8 cores) and I'd to know why the h264 decoder is using 9 threads by default. In my application I open and decode simultaneously 4 h264 HD (2 megapixels) streams. So having 4*9 threads isn't something very efficient. Am I going to loose performance or having any other side effect if I use only 2 threads by decoder? [14:00] <leandrosansilva> lose* [14:18] <Mavrik> leandrosansilva, um& that's a good question actually [14:19] <Mavrik> you probably shouldn't lose a noticable amount of performance [14:19] <Mavrik> you can use "-threads" BEFORE "-i" to set number of decoding threads [14:19] <Mavrik> measure and report if you can :) [14:36] <leandrosansilva> Mavrik, yeah, I was just curious about why 9 threads by decoder. It makes sense if you're watching a movie and have 8 cores. But in my case I have 4 streams being proceessed in real time. So I think I'll have to do some benchmarks :-) Thx [14:37] <Mavrik> leandrosansilva, "numcpu + 1" is a paralellization heuristic that works well in most general cases [14:37] <Mavrik> it's usually safe to assume that paralelizable process will be the only one on the machine and the user wants max utilization of cores ;) [14:40] <leandrosansilva> I'll try (8/4 + 1 == 3) threads per decoder and see if it changes the performance. Thx for the explanation. I'll investigate it better [15:43] <superware> using the libs, is there a way to do demux + decode at once? or must it be avcodec_decode_video2 to get demuxed frame and then avcodec_decode_video2 again to get raw bitmap? [15:44] <Mavrik> that would make no sense [15:44] <Mavrik> since frames arent only video. [15:44] <superware> Mavrik: you were right before regarding signature mismatches [15:45] <superware> thanks [15:45] <Mavrik> ;) [15:45] <superware> so calling avcodec_decode_video2 right after the other is common practice you say [15:47] <Mavrik> well [15:48] <Mavrik> checking if you got a video frame (and not, say, audio, subtitles, teletext or data) is common before that as well ;) [15:48] <Mavrik> and unless you have a rather strange video format the frames wont be RGB [15:50] <superware> but for video only I'm using av_find_best_stream(&fmt_ctx, type, -1, -1, null, 0) [15:50] <superware> where type = AVMEDIA_TYPE_VIDEO [15:51] <Mavrik> yeah, that'll just return you an index of stream you should look for [15:51] <Mavrik> as "best" video stream [15:52] <Mavrik> av_read_frame will always return all video frames [15:52] <Mavrik> er [15:52] <Mavrik> all frames - (not just video), it does no filtering [15:52] <superware> oh [15:55] <superware> is each video frame a single image? [15:55] <Mavrik> uuuh [15:55] <Mavrik> for most formats it is, nut it's not guaranteed [15:55] <superware> h.264? [15:56] <Mavrik> that's why you always get a result from decode_video2 which tells you if a frame was decoded [15:56] <Mavrik> "usually, not always" [15:56] <Mavrik> :) [15:56] <superware> 0 or 1 sounds better than 0 or more... [15:59] <Mavrik> superware, for H.264 you'll get either a frame or nothing from decoder [16:00] <superware> great, thanks [16:09] <superware> Mavrik: where can I find an example of demux+decode? [16:10] <Mavrik> doesn't decode_encode.c example do that? [16:11] <superware> yeah, but I'm kinda lost here. avcodec_decode_video2 gets me a h.264 frame (one or none), what should I do next? [16:12] <superware> I know av_image_copy will place it somewhere [16:13] <Mavrik> avcodec_decode_video2 will give you decoded frame [16:13] <Mavrik> not h.264 [16:13] <Mavrik> a raw frame. [16:13] <Mavrik> I have no idea what are you trying to do. [16:13] <Mavrik> Soooo& do with it what do you want to do with a decoded video frame ;) [16:15] <superware> my source is udp://224.0.0.0:1234 (h.264 over TS), do you mean to say that avcodec_decode_video2 will give me a bitmap? [16:16] <Mavrik> no, it will give you a raw uncompressed image in whatever format yout stream has it stored [16:16] <Mavrik> hmm, which could be called a bitmap yeah [16:16] <Mavrik> sorry for misleading you :) [16:16] <Mavrik> superware, what are you trying to achieve_ [16:16] <Mavrik> ? [16:17] <superware> np. but wow, I really thought demuxing is one process where I'll get h.264 and that I'll have to decode it to get the raw video.. [16:17] <superware> play udp://224.0.0.0:1234 :) [16:18] <Mavrik> ah :) [16:18] <superware> according to you ffmpeg does "h.264 over TS over UDP" directly to raw images [16:18] <Mavrik> mhm [16:19] <Mavrik> well, now you need to just use the timestamps on the frame to render it to screen ;) [16:19] <Mavrik> oh, and the frames are almost certanly YUV420 instead of RGB, so make sure you compensate for that :) [16:19] <JEEB> superdump, yes -- reading via some protocol and demuxing is one step, that would be done with libavformat [16:19] <JEEB> libavcodec comes your way after you have done that [16:24] <superware> JEEB: but according to Mavrik the process is being done automatically (one pass) [16:25] <JEEB> you were talking about av_decode_video2 [16:25] <JEEB> which is part of libavcodec [16:25] <JEEB> so he was expecting that you had already dealt with demuxing it [16:25] <Mavrik> indeed [16:28] <superware> I was talking about avcodec_decode_video2 which is used in the demuxing example [16:30] <superware> novice warning [16:31] <Mavrik> hmm well, the demuxing example deals with decoding as well ;) [16:33] <superware> ok. so after using av_image_copy, how do I know how many bytes is the raw image (to render it on screen etc). I didn't really understand void av_image_copy (uint8_t *dst_data[4], int dst_linesizes[4], const uint8_t *src_data[4], const int src_linesizes[4], enum AVPixelFormat pix_fmt, int width, int height) [16:34] <Mavrik> superware, hmm, you don't really have to copy the image [16:34] <Mavrik> basically you have an AVFrame [16:34] <Mavrik> your image data is in frame->data[0] [16:34] <superware> oh :) [16:34] <Mavrik> it's stored line by line, where each horizontal image line is frame->stride[0] large [16:35] <Mavrik> frame->linesize[0] actually [16:35] <JEEB> linesize is the picture line size [16:35] <JEEB> stride is the amount needed to get to the next line [16:35] <Mavrik> e.g. if you have a 1280x720 frame in RGBA (where each pixel is stored with 4 bytes) your linesize would be 1280 * 4 [16:36] <JEEB> stride can be equal to linesize, but you should never write code that assumes that because there are many reasons for why the stride would be bigger [16:36] <JEEB> mostly related to being able to optimize [16:36] <Mavrik> and pixels of image from (1,1) to (1280,1) would be stored from frame->data[0][0] to frame->data[0][5120] [16:37] <Mavrik> but as JEEB said, always use the number from frame->linesize to traverse the image [16:37] <Mavrik> never width :) [16:37] <JEEB> hmm [16:37] <Mavrik> the size of frame->data[0] should be image_height * frame->linesize[0] [16:38] <JEEB> ugh [16:38] <JEEB> you're equalling stride to the size again :s [16:38] <Mavrik> at least that's what most code in ffmpeg takes as a given :) [16:38] <JEEB> unless I'm missing something [16:39] <Mavrik> JEEB, there is no vertical stride [16:39] <JEEB> oh right [16:39] <JEEB> vertical [16:39] <JEEB> didn't notice you were talking about vertical [16:39] <JEEB> lol [16:39] <Mavrik> ^^ [16:39] <JEEB> and linesize is the actual amount of memory used? [16:39] <JEEB> as in stride-like [16:40] <Mavrik> yeah, linesize holds stride [16:40] <JEEB> k [16:40] <Mavrik> in decoded images [16:40] <superware> my linesize[0] is 352 [16:40] <Mavrik> JEEB, for multiplane images you get multiple data[] fields filled with strides in linesize[] array :) [16:40] <superware> format is AV_PIX_FMT_YUV420P [16:40] <JEEB> Mavrik, yes [16:40] <JEEB> that I know [16:40] <JEEB> I've written an encoder after all :D [16:40] <Mavrik> ^^ [16:41] <Mavrik> who hasn't :P [16:41] <superware> I have non-null in data[0 to 2] [16:41] <Mavrik> but yeah, it's been awhile since I did it so I'm kinda muddy on details [16:42] <JEEB> Mavrik, I mean inside libavcodec lol [16:42] <JEEB> which is why I am not that good at actually *using* libavcodec [16:42] <Mavrik> ah :) [16:42] <superware> how can I know the amout of memory used in data[0]? [16:43] <Mavrik> I've only written a subtitle encoder, no video encoder :) [16:43] <Mavrik> superware, (number of bytes per pixel) * linesize[0] * image_height [16:43] <JEEB> not sure why you'd need an exact copy of it, though [16:43] <Mavrik> mhm [16:44] <Mavrik> the next step is usually feeing it to libswscale to convert to RGBA or something :)( [16:44] <JEEB> superdump, YUV420P is "4:2:0 YCbCr, planar". So you have the luma on the first memory plane, then chroma planes come next [16:45] <JEEB> "YUV" is a colloquial way of saying YCbCr (and incorrect in a way, since "YUV" is an analog thing) [16:45] <superware> is this standard they aren't interleaves? [16:45] <superware> interleaved [16:46] <JEEB> that picture type is planar, so yes -- not interleaved [16:46] <JEEB> the P stands for that [16:57] <superware> can ffmpeg convert to RGB? [16:57] <JEEB> libswscale is for that [16:58] <JEEB> depending on your needs you can use that, or you can implement it yourself on a GPU or whatever if you're doing playback [16:59] <superware> I'm on .NET [16:59] <superware> I rather unmanaged code will do that [17:01] <Mavrik> yep, libswscale is probably your best bet [17:01] <Mavrik> since the API is made to be used with existing ffmpeg datastructures :) [17:01] <JEEB> it should be the simplest way of getting something out :D [17:02] <JEEB> and if you don't need too optimized performance and results, then it could be just fine for the final usage, too [17:02] <superware> might be HD :) [17:03] <Mavrik> swscale is pretty fast ;) [17:03] <Mavrik> with exception of HW accelerated colorspace converters [17:03] <Mavrik> check if your rendering method (like OGL etc.) supports colorspace conversion on the GPU :) [17:04] <superware> btw: avpicture_get_size [17:04] <superware> http://stackoverflow.com/questions/11815433/ffmpeg-yuv-to-rgb-distored-color... [17:06] <JEEB> what about it? [17:06] <bunniefoofoo> is there an lgpl aac encoder that ffmpeg supports? [17:07] <superware> JEEB: yuv to rgb [17:07] <bunniefoofoo> the "aac" encoder segfaults on me sometimes [17:07] <Mavrik> hmm, I think all other AAC encoders are proprietary [17:07] <JEEB> bunniefoofoo, nothing better than the aac encoder [17:07] <Mavrik> bunniefoofoo, check licence on libvo_aacenc [17:08] <JEEB> vo-aacenc would be compatible with LGPLv3 [17:08] <JEEB> not v2 [17:08] <JEEB> but it's really not in any way a better selection [17:08] <JEEB> you're better off trying to find out why it crashes and get that fixed / updated [17:08] <bunniefoofoo> that is going to be tough since it doesn't crash when I run the debugger [17:09] <Mavrik> compile with debug symbols and enable coredumps system-wide [17:10] <bunniefoofoo> voaac says LGPL v2.1 or later [17:11] <bunniefoofoo> so does wrapper code in libav [17:11] <bunniefoofoo> mavrik, unfortuately I am on win32 and a bit limited for debugging tools. same app does not segfault on linux [17:12] <Mavrik> well, win32 has debuggers as well :) [17:12] <superware> JEEB: it seems there's no PIX_FMT_YUV420P, but rather PIX_FMT_YUV420P10, PIX_FMT_YUV420P12, PIX_FMT_YUV420P14 etc [17:23] <bunniefoofoo> mavrik do you know something better than gdb for win32 that works with gcc-compiled executables? [17:33] <superware> JEEB: if I use avpicture_fill to go from yuv to rgb, how can I get the RGB's linesize? [17:33] <JEEB> avpicture_fill doesn't do the conversion >_< [17:34] <JEEB> swscale's scaling does [17:39] <Diogo> hi i need to get 1 thumbnail in diffent resolutions videos.. [17:40] <superware> JEEB: what's PIX_FMT_YUV420P9? [17:40] <Diogo> command: /servers/ffmpeg/bin/ffmpeg -i "rod.mp4" -vf "scale=560:-1,pad=max(iw\,ih):420:(ow-iw)/2:(oh-ih)/2" -frames:v 1 best.png ...if necessary i need to add padding.. [17:40] <JEEB> superdump, 9bit picture, as in 9 bits are used from 16 [17:40] <Diogo> i need the exact size of 560x420 (with black border ) [17:40] <JEEB> superdump, don't worry there most certainly is a YUV420P colorspace [17:40] <Diogo> any best command? [17:40] <JEEB> otherwise most of the things just wouldn't work [17:40] <JEEB> lol [17:42] <superware> my fault [17:44] <JEEB> superware, http://ffmpeg.org/doxygen/trunk/pixfmt_8h.html#a9a8e335cf3be472042bc9f0cf80c... [17:44] <JEEB> :) [17:51] <Diogo> this is possible generate different sizes thumbnails in the same command? [17:51] <Diogo> -vf "scale=560x360" -vf "scale=100x100" [17:53] <superware> JEEB: thanks, success at last [17:57] <ubitux> Diogo: what are you trying to do? [17:57] <ubitux> ah, multiple output, yes sure. [17:58] <Diogo> generate multiple thumbnails with different sizes [17:58] <Diogo> ubitux: -vf "thumbnail,scale=320:-1,pad=max(iw\,ih):240:(ow-iw)/2:(oh-ih)/2" [17:58] <ubitux> ./ffmpeg -f lavfi -i testsrc -vf scale=560x360 -frames:v 1 out1.png -vf scale=100x100 -frames:v 1 out2.png [17:58] <Diogo> 320 and 240 changes [17:58] <Diogo> ok [17:58] <Diogo> thanks [17:59] <ubitux> if you need to run a complex filtergraph, you should do that differently [17:59] <ubitux> to avoid running it twice [18:01] <Diogo> ubitux: /servers/ffmpeg/bin/ffmpeg -i "rod.mp4" -vf "thumbnail,scale=560:-1,pad=max(iw\,ih):420:(ow-iw)/2:(oh-ih)/2" -frames:v 1 best560x420.png -vf "thumbnail,scale=320:-1,pad=max(iw\,ih):240:(ow-iw)/2:(oh-ih)/2" -frames:v 1 best320x240.png -vf "thumbnail,scale=320:-1,pad=max(iw\,ih):240:(ow-iw)/2:(oh-ih)/2" -frames:v 1 best320x240.png [18:01] <Diogo> appear [18:01] <Diogo> Killed 0 fps=0.0 q=0.0 q=0.0 q=0.0 size=N/A time=00:00:00.00 bitrate=N/A [18:01] <Diogo> lol [18:01] <Diogo> :) [18:01] <ubitux> looks totally overkill. [18:01] <Diogo> ehehe [18:02] <Diogo> 2 works more than this no [18:02] <ubitux> of course [18:02] <ubitux> thumbnail eats a butload of memory [18:02] <ubitux> use vf split after the thumbnail [18:02] <ubitux> then for each split, scale it [18:03] <ubitux> and you need to re-interleave them somehow then [18:03] <Diogo> split can you give an example please.. [18:03] <ubitux> http://ffmpeg.org/ffmpeg-filters.html#split_002c-asplit [18:03] <Diogo> ok thanks [18:08] <ubitux> ./ffmpeg -f lavfi -i testsrc=s=1280x800 -filter_complex 'split[a][b]; [a] scale=-1:360 [o360p]; [b] scale=-1:240 [o240p]' -map '[o360p]' -frames:v 1 out-360p.png -map '[o240p]' -frames:v 1 out-240p.png [18:08] <ubitux> this works for me [18:09] <ubitux> so you would just add the thumbnail before the split [18:10] <ubitux> also note that you might want to look at the scene detection in vf select instead of the thumbnail filter [18:11] <ubitux> you might want to write an external script at some point btw [18:11] <ubitux> ok bye. [18:23] <Hans_Henrik> when ffmpeg is encoding, and is printing stuff like frame=X fps = X q = X time = ~~ [18:23] <Hans_Henrik> what does the "FPS" mean? [18:24] <saste> frames per second [18:24] <saste> or first person shooter [18:24] <Hans_Henrik> i thought it was frames per sec for playback but doesn't make sense [18:24] <JEEB> nope [18:24] <JEEB> it's the speed of how quickly it gets through the content [18:25] <Hans_Henrik> thanks [18:36] <nellynel90> has anyone gotten pyffmpeg or ffvideo to compile on fedora? i cant get it to build [18:40] <trose> nellynel90: not sure about pyffmpeg but it's pretty easy to just pipe data into ffmpeg from python without that library [18:40] <trose> http://stackoverflow.com/questions/10400556/how-do-i-use-ffmpeg-with-python-... [18:40] <nellynel90> trose: like with sp.Popen() ? [18:41] <trose> yeah [18:42] <trose> you use the flag '-i -' in your ffmpeg call [18:42] <trose> and you specifiy the stdin is a pipe [18:42] <nellynel90> for stdin yeah. [18:42] <trose> then you just write you data to stdin [18:44] <KalD> Hi Guys - got a quick question: I'm running ffmpeg on win32 - I am recording 5 min chunks of mp4 video from a webcam, i need to add current date/time to the video. I've looked around online and see many examples for linux, etc, but i cant get any of them to work on win32. [18:47] <nellynel90> trose: in that example you pointed to me, i can do all sorts of regex stuff in that while loop right? [18:47] <sacarasc> KalD: In the file name? [18:47] <trose> nellynel90: should be able to, what are you trying to do? [18:48] <KalD> sacarasc: no in the video stream (i.e. on the actual video stream) [18:48] <KalD> sacarasc: like you'd see on a security camera feed [18:50] <nellynel90> trose: if data = p.stdout.read(1024), ffmpeg should spit out a 'Output: foo ..... blah blah blah...' line into data right? [18:51] <trose> yeah [18:51] <trose> that should spit out everything that ffmpeg normally writes to terminal [18:52] <nellynel90> i want to start printing all lines when it finds that "output foo blah blah" line [18:52] <nellynel90> regex should take care of that right? [18:52] <trose> well if you just leave it alone it'll print to terminal anyways [18:52] <trose> oh, yeah actually [18:52] <nellynel90> yeah but it also prints out a bunch of garbage i dont need [18:53] <nellynel90> i guess what im having trouble with is the part that tell the loop that if that expr has been found to start print everything else [18:53] <trose> you could just say if 'Output' in data then [18:54] <nellynel90> wouldnt that print a line only if 'Output' is in it? [18:54] <trose> and use a bool start_printing :P [18:54] <nellynel90> ah [18:55] <trose> so if 'output' in data: start_print = true [18:55] <trose> if start_print: print data [18:55] <trose> lol [18:56] <nellynel90> i see. [18:56] <nellynel90> let me try [18:56] <nellynel90> thanks by the way [18:56] <trose> no problem [19:02] <trose> nellynel90: lemme know if you need any other help, slow day at work today :P [19:02] <nellynel90> thanks trose i appreciate that a whole lot [23:19] <nellynel90> f [23:20] <nellynel90> i cant seem to be able to set the profile to high when using libx264 [23:21] <nellynel90> i've tried -profile:v high, -x264opts profile:high, but to no avail. ffmpeg keeps defaulting to Main [23:22] <nellynel90> funny thing is that when i do -profile:v baseline, it works. [23:22] <nellynel90> anyone have an idea what im doing wrong? [23:24] <JEEB> by default libx264 sets the profile to the highest your stream needs according to the settings set otherwise (preset and such) [23:25] <JEEB> thus in general when you need to set it you are in a position where you have to limit the profile, not the other way [23:25] <bunniefoofoo> is there a difference between avpicture_alloc and av_image_alloc besides the align parameter? Apparently avpicture_alloc does not align data correctly for sws_scale anymore [23:25] <JEEB> I don't think the libx264 library itself overrides stuff to the default if you set "high" and it doesn't need it, but I have no idea of ffmpeg's mappings [23:26] <JEEB> but you really need to have some specific need to want to set the profile at high [23:26] <JEEB> because it is just the flag in that case [23:26] <bunniefoofoo> old code: avpicture_alloc((AVPicture*)_avFrame, (PixelFormat)pixelFormat, w, h); [23:26] <bunniefoofoo> new code: av_image_alloc(_avFrame->data, _avFrame->linesize, w, h, [23:26] <bunniefoofoo> (AVPixelFormat)pixelFormat, 32); [23:28] <Seanduncan> I seem to have ended up wi multiple versions if libavformat , swscale, on my Ubuntu 12.04 system. Anyone know how to completely purge any trace of ffmpeg and related libs from my system. I've already tried apt-get remove <insert library name here> but that still results in libs hanging around. I also don't want to completely wipe my whole system and start all new. Ay ideas? [23:29] <nellynel90> apt-get purge? [23:29] <nellynel90> apt-get autoremove ? [23:29] <bunniefoofoo> > locate libavcodec.so ... see how may copies there are [23:31] <nellynel90> JEEB: i have a couple of files that need to converted to h264 high at level 5.1. i can set the level fine but not the profile. [23:31] <JEEB> if you really want them to be of that kind I recommend you actually enable some high profile features then [23:31] <JEEB> easiest way is to use a slower preset [23:34] <bunniefoofoo> sw_scale prints this: [swscaler @ 0219b680] Warning: dstStride is not aligned [23:34] <bunniefoofoo> should I be concerned? [23:34] <JEEB> not all optimizations can be used that means [23:35] <bunniefoofoo> yeah, I don't get it though... the dst is yuv420p 720x480 [23:35] <bunniefoofoo> not some weird size [23:35] <JEEB> print out the stride, I guess [23:36] <JEEB> or wait [23:36] <JEEB> aligned so the starting pointer might have to be aligned, too [23:36] <bunniefoofoo> stride == AVFrame lineSize[] ? [23:36] <bunniefoofoo> ok [23:36] <nellynel90> JEEB: would the preset overwrite any -x264opts options i include? [23:37] <bunniefoofoo> data pointer was allocated with av_picture_alloc [23:42] <bunniefoofoo> data[0]=0645A020 linesize[0]=720 [23:43] <bunniefoofoo> thats a multiple of 16 stride, with 48 bytes alignment, no? [23:44] <bunniefoofoo> oh this is interesting... sws_scale is called several times before that warning comes out [23:46] <nellynel90> actually -preset slower did work! [23:51] <JEEB> nellynel90, -preset sets the defaults, after that come your settings [23:56] <bunniefoofoo> jeeb, alignment seems to be 16-bytes which I assume is the requirement for most simd stuff: http://pastebin.com/YbBAZPw5 [23:56] <bunniefoofoo> alignment does not seem to change before or after the error comes out [23:57] <bunniefoofoo> my bad... data pointers are changing! sorry [23:57] <bunniefoofoo> this is too wierd [23:58] <bunniefoofoo> heh my bad again.. data pointers should change, using about 15 frame buffer... they all look aligned right to me [00:00] --- Sat Jun 1 2013