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

[burek]

[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