[00:00:25 CET] <ac_slater> wm4: stupid question. How much of a single line of YUV420P is Y ? [00:00:29 CET] <ac_slater> half? [00:00:38 CET] <Mavrik> Full. [00:01:42 CET] <ac_slater> Mavrik: oh so Y is just 2/3 of a frame? [00:01:51 CET] <Mavrik> ? [00:02:02 CET] <ac_slater> Mavrik: I'm looking athe picture on wikipedia [00:02:02 CET] <ac_slater> it's confusing [00:02:10 CET] <Mavrik> In 4:2:0, Y is full frame resolution , UV are half [00:02:20 CET] <ac_slater> https://en.wikipedia.org/wiki/YUV#/media/File:Yuv420.svg [00:02:32 CET] <ac_slater> I se [00:02:34 CET] <ac_slater> see * [00:04:02 CET] <wm4> that picture is confusing [00:06:05 CET] <ac_slater> Mavrik: what's resolution in your definition? [00:06:27 CET] <BBB> ac_slater: for a 100x100 image, y is 100x100 pixels and u/v is 50x50 each in 4:2:0, so in bytes, the y plane is twice as big as u+v together (so yes, 2/3rd) [00:06:49 CET] <BBB> ac_slater: but you cant really say per line because the line size is half, not quarter, its just that the number of lines is also half [00:06:51 CET] <Mavrik> ^ [00:07:21 CET] <Mavrik> The resolution of the raw frame before being stretched via SAR :) [00:08:45 CET] <ac_slater> interesting [00:09:13 CET] <ac_slater> in terms of bytes, Y is laid out FIRST then U, then V? [00:09:19 CET] <ac_slater> I hope that's the casr [00:09:21 CET] <ac_slater> case * [00:10:07 CET] <Mavrik> Aren't planes split in ffmpeg AVFrame structure anyway? [00:10:39 CET] <wm4> yes [00:11:00 CET] <wm4> but ac_slater has some omx thing that expects y/u/v all in one continuous buffer [00:11:09 CET] <wm4> and I'd expect Y comes first [00:11:13 CET] <Mavrik> Ah. [00:11:36 CET] <Mavrik> Yeah, I've mostly seen Y folloved by UV in those OMX cases. (NV12 or what's it called?) [00:11:46 CET] <durandal_170> kierank: yo evil, Trac thinks I'm spammer [00:11:53 CET] <wm4> Mavrik: he doesn't have nv12 [00:12:00 CET] <ac_slater> I'm confused since each channel/plane IS contiguous according the wiki image and what you guys said [00:12:04 CET] <wm4> just Y, then U and V (in whatever order) [00:12:07 CET] <Mavrik> Ok. I'll let you guys to it then :) [00:12:08 CET] <ac_slater> Trying to find a definition on "contiguous" [00:12:27 CET] <wm4> ac_slater: erm, that's not a specific term [00:12:29 CET] <ac_slater> Mavrik: thanks for the help mate [00:12:30 CET] <Mavrik> ac_slater, well, wiki image describes a theoretical case [00:12:44 CET] <ac_slater> wm4: I know I know ... but I still dont get it [00:12:46 CET] <wm4> the difference here is that ffmpeg can have each plane in an arbitrary place [00:12:53 CET] <ac_slater> ohhh [00:12:55 CET] <wm4> each plane can even be malloc'ed separately [00:13:06 CET] <wm4> all what counts is the plane pointers in AVFrame.data [00:13:10 CET] <ac_slater> I didn't know they cared about that [00:13:12 CET] <wm4> s/is/are [00:13:34 CET] <wm4> and in your omx thing it sounds like the U or V plane strictly follows the Y plane in memory [00:13:54 CET] <wm4> those av_image... functions also can give you this layout [00:13:55 CET] <ac_slater> I seeeeee now. [00:14:01 CET] <wm4> but AVFrame can be arbitrary [00:14:14 CET] <ac_slater> I do memcpy(in_buf, frame->data[0], n) [00:14:18 CET] <jkqxz> Remember that ffmpeg's YUV420P planes are ordered Y, V, U (Y, Cr, Cb), so if you copy them to your YUV buffer in that order you need to take data[2] before data[1] to get the colours right. (This will be obvious from the output, though.) [00:14:30 CET] <wm4> ac_slater: yeah [00:14:32 CET] <ac_slater> jkqxz: interesting [00:15:13 CET] <ac_slater> jkqxz: would this be the result of something like that? http://i.imgur.com/ERM8dQw.png [00:15:20 CET] <ac_slater> that == U and V swapped [00:15:56 CET] <Mavrik> Hrmf. [00:16:18 CET] <Mavrik> That looks more like wrong plane sizes, if the channels would be swapped you'd get colors broken uniformly. [00:16:22 CET] <Mavrik> But Y looks good :P [00:16:22 CET] <jkqxz> No, it swaps red and blue. Images all look kindof right, but people and whatnot are strangely coloured. [00:16:30 CET] <ac_slater> I'm all over the place. I'll see if simply copying planes 0,2,1 in that order to a contig buffer helps [00:16:38 CET] <ac_slater> jkqxz: I see thanks mate [00:17:25 CET] <BBB> jkqxz: wait what? yuv420p data[1] is u/cb in ffmpeg [00:18:28 CET] <wm4> ac_slater: ah wait a moment [00:18:30 CET] <JEEB> yeah, it's YCbCr in that [00:18:34 CET] <wm4> you can't use a single memcpy to copy a plane [00:18:46 CET] <jkqxz> The one OMX implementation I've worked on in the past required padding between planes (it was feeding into a H.264 encoder which needed the edge space). That would explain a strange offset if it were required here? (This is probably a very confusing thing to mention if it isn't.) [00:18:48 CET] <wm4> you have to copy line by line if stride is not equal to the plane width [00:19:23 CET] <ac_slater> my stride is equal the my plane width [00:19:53 CET] <wm4> but the AVFrame you get as input doesn't have to [00:19:55 CET] <jkqxz> How big is your image? 100x100? [00:20:02 CET] <BBB> the height of the buffer may be padded also [00:20:15 CET] <ac_slater> wm4: true. Dammit [00:20:22 CET] <BBB> that is, data[0] + stride[0] * height may not be equal data[1] [00:20:23 CET] <ac_slater> jkqxz: 640x480 [00:20:29 CET] <ac_slater> BBB: right [00:20:51 CET] <ac_slater> well shit [00:22:28 CET] <kierank> durandal_170: if you're at FOSDEM I'll fix it ;) [00:22:43 CET] <kierank> I have no idea how to fix in reality [00:23:38 CET] <jkqxz> (That was wondering about alignment: 640x480 is divisible by a large multiple of 2, so it probably isn't going to bite you here. Hardware things often care strongly about that too.) [00:23:50 CET] <ac_slater> agreed [00:26:30 CET] <ac_slater> BBB: so then if copying planes is difficult to do manually, what would you suggest - sws_scale? [00:27:17 CET] <ac_slater> and is linesize[n] a representation of the actual data in data[n] ? [00:28:32 CET] <ac_slater> oh wait, nevermind that last question... line != plane [00:31:04 CET] <ac_slater> avpicture_layout? [00:32:32 CET] <ac_slater> (av_image_copy_to_buffer() I mean) [00:38:22 CET] <ac_slater> woot! av_image_copy_to_buffer worked [00:38:50 CET] <ac_slater> wm4: I thought YUV420 was separated by line, not the entire image [00:38:55 CET] <ac_slater> so I was trying to manually pack things [00:39:15 CET] <wm4> oh [00:39:29 CET] <ac_slater> wm4: yea ....... [00:39:35 CET] <ac_slater> not to proud of myself there [00:39:43 CET] <ac_slater> too * [00:39:52 CET] <ac_slater> jkqxz: Mavrik wm4 BBB ... thanks guys [00:40:40 CET] <jkqxz> BBB: Gah, sorry about that. I was looking at this a day or two ago because of VAAPI formats, and it appears I got myself thoroughly confused. YUV420P == IYUV is YUV == YCbCr order. YV12 is YVU == YCrCb order. [00:42:14 CET] <jkqxz> I think that a platform I have worked on in the past has YV12 the wrong way around relative to everyone else. And the test I attempted a few days ago must have been wrong somehow (maybe I swapped twice), because repeating it in slightly different conditions I now get that answer. [00:55:58 CET] <jkqxz> (To which I think the lesson is mainly "this is confusing and you should check very carefully if dealing with multiple formats". The output makes a good check in itself, but that doesn't mean you haven't swapped twice.) [01:11:38 CET] <jkqxz> Might also be nice if the comment in pixfmt.h didn't have them the opposite way around. It doesn't make a statement on order, but if you try to infer something then you will be wrong. [01:13:33 CET] <nevcairiel> its called YUV420 not YVU420! :P [01:25:57 CET] <wm4> so which one is morally right [01:26:56 CET] <Plorkyeran> bgr24 [01:28:40 CET] <BBB> jkqxz: right, thats correct, thanks for clearing that up [01:56:36 CET] <cone-926> ffmpeg 03Marton Balint 07master:cfc040a49f4b: lavf: bump micro version after the new segment muxer options [01:56:36 CET] <cone-926> ffmpeg 03Marton Balint 07master:98e94dff7a59: configure: use -ldl for decklink [01:56:36 CET] <cone-926> ffmpeg 03Marton Balint 07master:995c7a6f5ad4: lavd/decklink_dec: add support for teletext [01:56:36 CET] <cone-926> ffmpeg 03Marton Balint 07master:6bc610b39efe: configure: remove libzvbi GPL dependency [02:06:45 CET] <ac_slater> thanks again guys [02:07:25 CET] <ac_slater> I'll share my pi2 openmax IL encoder in a few days. It's not worthy of being in the tree, but it's a fun toy [02:17:35 CET] <derekprestegard> hello, where can I find a description of ffmpegs IO patterns? [02:18:11 CET] <derekprestegard> Im trying to optimize for reading huge files out of S3 storage and this requires large IOs that are ideally highly parallel - not sure if ffmpeg can do this or not [02:25:43 CET] <Timothy_Gu> derekprestegard: are you doing it over the network or locally? [02:26:44 CET] <derekprestegard> @Timothy_Gu the storage is S3 so it will always be network. The server could either be an EC2 instance or a local server [02:27:14 CET] <derekprestegard> i.e. we will be using http or https for all communication with the storage [02:27:32 CET] <TD-Linux> it really depends on the file and isn't set in stone. [02:27:39 CET] <BBB> derekprestegard: I dont think i/o is parallelized in ffmpeg [02:27:50 CET] <BBB> derekprestegard: and more generally, i/o is really not the constraining factor in performance of ffmpeg [02:27:56 CET] <TD-Linux> s3 has really high latency, have you considered just pulling the entire thing? [02:28:09 CET] <derekprestegard> we have [02:28:12 CET] <BBB> derekprestegard: i/o is buffered, maybe a readahead buffer could be useful (in a thread) [02:28:18 CET] <derekprestegard> 200 GB source files ar ekind of unwieldy [02:28:25 CET] Action: TD-Linux actually uses a NFS mount on EC2 for this purpose [02:28:44 CET] <BBB> I would add a readahead thread in the caching layer (AVIOContext<>URLContext) [02:45:35 CET] <derekprestegard> thanks for the info guys [04:50:00 CET] <cone-926> ffmpeg 03Timothy Gu 07master:44304ae3220f: all: Add missing header guards [04:50:01 CET] <cone-926> ffmpeg 03Timothy Gu 07master:e74378aa8c53: amrwbdec_mips: Add missing ff_ prefix [05:16:58 CET] <Timothy_Gu> jamrial: lol, even your replies show how we have too many aac encoders [05:53:38 CET] <RiCON> Timothy_Gu: you forgot an ending "/" in decklink_common.h [05:56:11 CET] <RiCON> line 109 of libavdevice/decklink_common.h* [11:31:34 CET] <durandal_1707> Daemon404: does libutvideo x64 asm works on linux? [11:31:54 CET] <durandal_1707> I get crash when encoding [11:36:46 CET] <cone-795> ffmpeg 03Stefano Sabatini 07master:b91093a4111f: ffmpeg: replace "flush Media" with "flush_media" in benchmark_all output [12:33:58 CET] <cone-795> ffmpeg 03Michael Niedermayer 07master:2d163cbdabae: avcodec/huffyuvenc: Remove duplicate include [13:00:19 CET] <ubitux> kinda incredible the shitton of stuff you can find in sei [13:08:07 CET] <durandal_1707> ubitux: sei? [13:08:23 CET] <ubitux> h264 sei [13:39:23 CET] <cone-795> ffmpeg 03Michael Ira Krufky 07master:44a50feebe1f: libavdevice/decklink_common.h: fix broken build due to missing `/` [14:38:16 CET] <durandal_1707> who idiv instruction works? [14:38:48 CET] <durandal_1707> *how [14:40:37 CET] <J_Darnley> Sorry I just remember that it's complicated. [14:44:54 CET] <jamrial> durandal_1707: http://www.felixcloutier.com/x86/IDIV.html [14:49:05 CET] <durandal_1707> I always get fpe [14:54:47 CET] <J_Darnley> May I suggest that you post the code you've written and what you think the arguments hold? [14:59:34 CET] <durandal_1707> http://pastebin.com/tPg89A1X [15:01:33 CET] <Daemon404> g31 [15:01:35 CET] <durandal_1707> I'm missing smthing obvious [15:03:24 CET] <J_Darnley> What is "RDX:RAX" supposed to hold? A 128 bit signed integer number split over the two registers? [15:05:08 CET] <J_Darnley> You have checked the obvious thing that slices isn't zero? [15:09:02 CET] <jkqxz> You haven't written RDX? Signed overflow also gives you SIGFPE. [15:10:30 CET] <durandal_1707> divisor is 6, dividend is 0 [15:23:26 CET] <durandal_1707> xoring edx fixed it [17:00:03 CET] <cone-895> ffmpeg 03Mats Peterson 07master:b34c9d1b9d93: lavc/rawdec: Use AV_PIX_FMT_PAL8 for raw 1 bpp video in AVI [17:01:30 CET] <durandal_1707> is this pal8 saga finally over? [17:18:40 CET] <jamrial> ther guy is adhd as fuck, so probably no [17:19:38 CET] <wm4> I'm sure there's an infinite number of bugs with mov-in-mkv files [17:48:58 CET] <durandal_1707> kierank: that vlc t-shirt resembles something? [17:49:50 CET] <kierank> durandal_1707: reply on twitter [18:00:33 CET] <cone-895> ffmpeg 03James Almer 07master:6cc156793d4f: avcodec/dvaudio: add missing header include [18:42:17 CET] <ubitux> > Duration: 00:00:02.13, start: 0.533333 [18:42:20 CET] <ubitux> ffs [18:42:31 CET] <ubitux> 26.98 fps [18:42:37 CET] <ubitux> pretty sure fps is broken because of this [18:43:39 CET] <ubitux> playback is btw broken in most player [18:44:13 CET] <ubitux> that is, ffplay, mpv, vlc but not quicktime (obviously, and fuck edit list btw) [18:44:40 CET] <ubitux> i can't imagine the shit going on if some audio was present [18:46:26 CET] <wm4> what where [18:46:51 CET] <wm4> mpv doesn't normally use the reported fps, or if it does, only after attempting to verify it [18:47:01 CET] <ubitux> fps reported by ffmpeg [18:47:06 CET] <ubitux> i need to check if i can share that file [18:47:09 CET] <ubitux> just a sec [18:47:20 CET] <wm4> I've found many many files with broken fps reporting [18:47:34 CET] <wm4> usually mkv files with a wrong value in the file header [18:47:46 CET] <wm4> (and then there's vfr...) [18:48:57 CET] <ubitux> pretty sure it's because of the start time here [18:49:09 CET] <ubitux> (you have a bunch of frames with negative ts because of it) [18:49:40 CET] <ubitux> wm4: http://b.pkh.me/LZZX7353.MOV [18:49:41 CET] <ubitux> here you go [18:50:17 CET] <ubitux> so basically the beginning the video has a "laggy" effect [18:50:25 CET] <ubitux> in ffplay and mpv [18:50:53 CET] <ubitux> vlc seems to show the first one, and wait for the ts to reach 0, so it's freezing half a sec [18:51:02 CET] <ubitux> and quicktime plays it smoothly [18:52:05 CET] <wm4> hm just broken timestamps? [18:53:23 CET] <ubitux> who knows [18:53:35 CET] <ubitux> not sure if they are broken [18:53:42 CET] <ubitux> but they seem shifted by -start_time [18:54:07 CET] <ubitux> so starting around t=-0.5 [18:54:48 CET] <ubitux> would be nice to have some audio in it for a more pathologic case [18:56:05 CET] <wm4> fascinating, mplayer shows it flipped [18:56:09 CET] <JEEB> lol [18:56:38 CET] <wm4> ah it's the rotation hint [18:57:45 CET] <ubitux> yeah, i think i'll keep that sample for future tests, it has nice "properties" [18:58:24 CET] <JEEB> boxdumper is a great tool to quickly take a look at that info [18:59:11 CET] <JEEB> reminds me I should add compatibility for MS's tfxd's contents [18:59:20 CET] <JEEB> currently it just outputs it as a "UUID box" [19:20:21 CET] <cone-895> ffmpeg 03Neil Birkbeck 07master:c323c98ee348: libavutil/mastering_display_metadata.h: change fields to be rationals as this is how they are typically coded. [19:39:42 CET] <durandal_1707> what register number is edx? [19:45:43 CET] <BBB> durandal_1707: depends on the ABI [19:46:07 CET] <BBB> durandal_1707: mixing named registers and r%d gets hairy very quickly :D [19:49:04 CET] <ubitux> "i r" in gdb should give you a hint i suppose [19:51:13 CET] <jamrial> durandal_1707: look at the DECLARE_REG lines in x86inc [19:51:45 CET] <jamrial> as BBB said it depends on the abi (Win x64, Linux x64, x86_32) [19:57:43 CET] <BBB> do we have a filter that counts the number of frames and printf()s to stdout how many frames there were? [20:14:29 CET] <beastd> BBB: I guess idet kind of does it. Don't know if there's another filter that does something like you want. [20:16:38 CET] <ubitux> BBB: showinfo? [20:16:45 CET] <ubitux> otherwise you have a count frame mechanism in ffprobe [20:17:36 CET] <wm4> man I wish I knew how to use all the amazing functionality in ffprobe [20:17:49 CET] <wm4> but both docs and command line help are like "fuck you" [20:18:35 CET] <BBB> :D [20:19:18 CET] <ubitux> ffprobe -v warning -show_entries stream=nb_read_frames -of flat -count_frames <input> [20:20:41 CET] <wm4> why -v warning [20:20:58 CET] <ubitux> so you get only the useful info :p [20:23:41 CET] <cone-895> ffmpeg 03Michael Niedermayer 07master:8fac0d640341: avformat/avio: free url/avio options [21:21:21 CET] <Timothy_Gu> RiCON: crap. Seems like it was fixed [21:26:49 CET] <RiCON> Timothy_Gu: weird that it wasn't missing in the patch in ML [21:32:34 CET] <cone-895> ffmpeg 03Zhao Zhili 07master:1e2c2622120c: libavformat/network: use defined constant in poll [21:49:25 CET] <durandal_1707> there is thread on ha about native aac encoder [21:53:13 CET] <RiCON> oh, but still without the TNS fixes [21:54:14 CET] <durandal_1707> I just tested it with some flac sample and I could encounter difference [21:56:03 CET] <durandal_1707> s/encounter/hear [22:09:20 CET] <kierank> J_Darnley: if you are in town we are at moder lambic [22:09:59 CET] <J_Darnley> I was. [22:10:07 CET] <J_Darnley> I'm now back home. [22:10:46 CET] <J_Darnley> De Lijn have become cheap. Few busses after 21.00 [22:12:26 CET] <kierank> Sorry about that [22:12:37 CET] <kierank> We'll be at FOSDEM tomorrow [23:07:00 CET] <cone-895> ffmpeg 03Hagen Schmidt 07master:583a6431460a: mpegtsenc: Do not fail ADTS AAC muxing if the first frame is not ADTS [23:07:02 CET] <cone-895> ffmpeg 03Thierry Foucu 07master:9a0995269549: lavf/flvdec: Allow files where the PreviousTagSize is not set according to the spec. [00:00:00 CET] --- Sat Jan 30 2016