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

[burek]

[00:18] <wm4> michaelni: thanks
[01:07] <clever> Daemon404: now its just being a pain, it crashes with 2 different errors
[01:07] <clever> without gdb, it gives *** glibc detected *** ./ffplay_g: munmap_chunk(): invalid pointer: 0xafec2008 ***
[01:07] <clever> but if i try to debug that, it gives Program received signal SIGSEGV, Segmentation fault.
[01:07] <clever> and a corrupt stack
[01:07] <clever> which ends in memcpy
[01:08] <michaelni> sounds like a job for valgrind 
[01:08] <clever> michaelni: and valgrind gets upset over the omx interface, it doesnt understand the ioctl's
[01:08] <clever> so it complains about all kinds of unset locations
[01:10] <clever> michaelni: if i'm operating in YUV420 at 1920x1072 with a linesize of 1920, the 2nd plane should be 960 * 1072 bytes in size?
[01:15] <michaelni> yuv420 is 2x2Y 1x1Cb 1x1Cr
[01:15] <michaelni> for a 2x2 image
[01:17] <clever> hmmm, the code should be the same as before but its now giving even less output
[01:18] <Daemon404> clever, as michaelni said, it should be 960 x 536 for chroma planes
[01:18] <clever> ah, my test tv sucks
[01:18] <clever> ahh, halve the height too, forgot about that
[01:18] <clever> explains the problems perfectly
[01:19] <clever> got distracted by the simplicity of your bit shifting and inverting trick
[01:19] <clever> forgot that height needs the same thing
[01:20] <clever> and the pocket tv from 3 decades ago doesnt help, not much contrast when dealing with a Y only image
[01:21] <clever> and ive double-checked, the linesize and stride match, so i can just memcpy the entire plane at once
[01:21] <clever> i added a check to make it fail if it doesnt match in the future
[01:22] <cone-808> ffmpeg.git 03Michael Niedermayer 07master:81ed7efbe24e: avcodec/indeo3: check the return code of ff_set_dimensions()
[01:22] <cone-808> ffmpeg.git 03Michael Niedermayer 07master:11679e1b90f6: avcodec/pthread_frame: Fix memleak of AVCodecContext on error
[01:22] <cone-808> ffmpeg.git 03Michael Niedermayer 07master:42874666a6cb: avcodec/snowdec: check av_frame_ref() return value
[01:23] <Daemon404> [00:21] < clever> and ive double-checked, the linesize and stride match, so i can just memcpy the entire plane at once <-- i told you you cannot
[01:23] <Daemon404> avframe does not necesarily have width == stride
[01:23] <Daemon404> it only does when teh width happens to also match the alignment on that particular platform
[01:24] <clever> in this case, it does match, i will fix the code if i encounter another file which doesnt
[01:24] <Daemon404> ...
[01:24] <Daemon404> that is a retarded attitude.
[01:24] <Daemon404> it's not soem rare occurrence, it's standard operating procedure
[01:24] <clever> just trying to make it as simple as possible right now
[01:25] <clever> ive been staring at no image at all for days, so justtrying to get something out of it
[01:30] <clever> and i forgot to enable the v plane, oops
[01:30] <Daemon404> :V
[01:38] <cone-808> ffmpeg.git 03Reinhard Tartler 07master:2a0fb7286d67: alsdec: check block length
[01:38] <cone-808> ffmpeg.git 03Michael Niedermayer 07master:43f925536844: Merge remote-tracking branch 'qatar/master'
[01:42] <clever> and now its drop everything time, the main server i admin was shut off for fail reasons
[01:57] <clever> and i cant do a thing, support phone# isnt answering
[02:23] <clever> Daemon404: and i have color!
[02:23] <clever> not the right colors, but thats still a major leap in progress
[02:28] <Daemon404> probably switch u and v
[02:28] <clever> there was a few patched of the green it was giving before
[02:29] <clever> fixing the memory leak now, then going to test it on the big tv to see whats wrong
[02:29] <clever> the pocket tv is too crappy to clearly see the issue
[02:32] <clever> Daemon404: looks like the colors arent aligned
[02:33] <clever> one of those standard color bar frames may help
[02:33] <Daemon404> smpte bars
[02:35] <clever> found a decent mov with those, now to see how well my patch handles mov
[02:35] <clever> i still dont have the extradata problem ironed out
[02:35] <clever> so i'm having to manualy extract the annex b formated header and put that into a 2nd file
[02:35] <clever> not sure how mov is going to complicate that
[02:43] <clever> nope, no output at all on the mov file
[04:45] <clever> Daemon404: still there?
[04:47] <clever> http://gallery.earthtools.ca/index.py/paste/before.png
[04:47] <clever> http://gallery.earthtools.ca/index.py/paste/color.png
[04:48] <clever> its missing 2 whole bars, the alignment is off, and the top is heavily corrupt
[04:49] <clever> and probly due to starting at the wrong offset, all the colors are wrong
[05:08] <cone-808> ffmpeg.git 03Michael Niedermayer 07master:39d11d599cd2: avformat/oggparseopus: factor opus_duration() out
[05:08] <cone-808> ffmpeg.git 03Michael Niedermayer 07master:7f39352a1b66: avformat/oggparseopus: calculate pts/dts for initial packets after seeking
[06:15] <clever> ok, half the corruption was just scaling not scaling it down
[09:42] <ubitux> meh decoding example is leaking again? arh.
[09:45] <ubitux> http://pastie.org/8544060 decoding example hacked for random fuzzing
[09:46] <ubitux> *seek* fuzzing
[09:46] <ubitux> (removing the 0 &&
[09:46] <ubitux> )
[09:48] <ubitux> http://pastie.org/8544067 ’ http://pastie.org/pastes/8544068/text
[09:49] <ubitux> could be adjusted to sometimes attempt outbound seek
[10:47] <Mavrik> hmm, I'm trying to fix TTX remuxing... does anyone know of a good MPEG2-TS stream analyzer I could use to find out where things break?
[11:00] <saste> ubitux, nice
[11:26] <ubitux> wtf
[11:26] <ubitux> wtf is going on in this thread o_o
[11:32] <saste> we have a trac fight
[11:51] <ubitux> this thread is awesome
[11:51] <saste> the guy is mental
[11:52] <saste> what about adding the tag "funny"?
[11:53] <ubitux> saste :D
[11:54] <ubitux> players #4 enter the game
[11:54] <ubitux> -s
[11:59] <ubitux> > You have no right to talk about professionalism when you have displayed such a poor attitude. You are deserving of any insults you have been given.
[11:59] <ubitux> :D
[12:23] <michaelni> ubitux, saste btw there are some coverity issues in the examples
[12:23] <kierank> Mavrik: not for less than £10k
[12:24] <Mavrik> yay. :)
[12:24] <kierank> the answer is almost always fucked timestamps
[12:25] <Mavrik> mhm, first issue were broken VBI/TTX data in PMT
[12:25] <Mavrik> so now the next suspect are indeed timestamps
[12:26] <Mavrik> or mpegtsen.c doing something funky with packets
[12:27] <kierank> timestamps are optional in dvb-ttx
[12:28] <kierank> because of a mistake in the original spec
[12:30] <Mavrik> hmm, I see how this could mess everything up, I'll look into it. Thanks for advice :)
[13:12] Action: Compn troooooolls
[13:12] <Compn> bbl
[14:12] <TimNich> michaelni:  that mxf patch should be OK, I don't think we expected audio only originally.
[14:16] <Compn> ubitux :  i dont have pkg-config on mingw , rather i dont have it installed because its a giant pain in the butt
[14:16] <Compn> maybe the newr mingw fixed all that
[14:18] <ubitux> Compn: not relevant ;)
[14:18] Action: Compn trolls hard
[14:19] <ubitux> Compn: stop spouting non sense in that ticket :p
[14:19] <Compn> bah
[14:20] <JEEB> pkg-config seems to work just fine in general (as well as it does elsewhere), the only problem I've noticed is that certain configure scripts expect you to have CROSS-PREFIX-pkg-config, and don't fall back to normal pkg-config :< (although that's a thing everywhere, and can be worked around by creating shell scripts for those prefixed things)
[14:21] <nevcairiel> pkg-config on windows is annoying
[14:21] <nevcairiel> especially if you try to distribute pre-compiled libs and dont have the final path under your control
[14:33] Action: Compn gets ready to troll the big one
[14:33] <ubitux> Compn: maybe you can try to propose a solution or come up with a patch instead? ;)
[14:34] <ubitux> oh come on Compn...
[14:34] <ubitux> are you serious?
[14:35] <cone-263> ffmpeg.git 03Carl Eugen Hoyos 07master:945a440d11ac: Force one stream for raw muxers.
[14:36] <Compn> ubitux : yes, sending annoying users to libav is what i've been doing for a long time :)
[14:36] <ubitux> that's stupid
[14:36] <Compn> i do it in mplayer, i send those users to vlc :)
[14:36] <Compn> in #videolan i send them to mplayer :)
[14:37] <ubitux> you should stop that
[14:37] <ubitux> the user actually raised an interesting problem
[14:37] <ubitux> even though the form quite sucks
[14:37] <Compn> he refuses to answer a single question
[14:37] <Compn> theres not much i can help him with
[14:38] <ubitux> it doesn't matter we figured out the problem
[14:38] <Compn> yes the problem is pebcak 
[14:39] <Compn> but ok , time to stop trolling now
[14:39] Action: Compn gives ubitux a hug
[14:59] <michaelni> TimNich, the patch fixes the crash but i dont think it succeeds muxing the audio or our demuxer is buggy in demuxing it
[15:00] <michaelni> at least in my test there was unexpectedly less audio coming out but then i didt investiagte why
[15:04] <TimNich>  I think the whole issue of audio only in mxf needs looking at because it wasn't an expected scenario. I need to try the demuxer with some audio only mxf muxed elsewhere, its just finding the time at the moment as I have two major projects on that are behind schedule. :(
[15:27] <saste> Compn, you need to install pkg-config yourself with mingw
[15:27] <saste> it is annoying but it is definitively possible
[15:27] <saste> you just need to install gtk and stuff
[15:38] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:0f65503799c8: avcodec/bitstream: remove unused variable
[15:38] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:b6eee405ffd9: avcodec/utils: Print warning if avcodec_set_dimensions() failed
[15:38] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:0fe6906d96cc: avfilter/aeval: Fix use of uninitialized variable
[15:40] <michaelni> pkg-config needs gtk ??
[15:42] <ubitux> no, glib
[15:54] <saste> https://trac.ffmpeg.org/wiki/MingwCompilationGuide => pkg-config
[15:55] <ubitux> installing gtk is likely a simple way of getting glib :p
[16:22] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:7441d1ec330d: avformat/aviobuf: fix null dereference in avio_close_dyn_buf()
[16:41] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:95d2fc6a76f3: avformat/hdsenc: Check rename() return value
[16:41] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:572965c9a6b8: avformat/hdsenc: fix unintentional integer overflow in hds_write_packet()
[16:43] <ubitux> 37a749012aaacc801fe860428417a6d7b81c103f made the example leak with the old method
[16:43] <ubitux> i'm not sure if this is actually fixing some code (so the example before my modification could have been working)
[16:44] <ubitux> but we released with that (maybe broken) behaviour
[16:45] <ubitux> fuck this shit
[16:45] <ubitux> seriously :(
[16:51] <michaelni> the non refcouted api should be only defined by avcodec from prior the whole refcounted code was added
[16:54] <michaelni> that also implicates that when the examples worked with old avcodec without leaking then they have to work with current 
[16:55] <michaelni> old == prior to refounting
[16:59] <ubitux> michaelni: see #3219
[17:00] <ubitux> anyway, any app relying on that logic without ref counting will be leaking hard
[17:00] <ubitux> old usage and new usage with no ref counting is leaking
[17:01] <ubitux> the api wasn't very clear anyway, so maybe the example was wrong in the first place
[17:01] <ubitux> still&
[17:15] <nevcairiel> the qp_table probably needs some handling as well, since its one of the things that leaks
[17:16] <nevcairiel> i think there is an upcoming change on the libav ML that should fix the sidedata leak
[17:18] <nevcairiel> the good news is that you can update the example to no longer use two different frame allocation functions
[17:18] <nevcairiel> unless you want to keep it for documentaiton sake =p
[17:19] <ubitux> that's of course for documentation sake
[17:19] <ubitux> also, being able to test the 3 methods is quite useful&
[17:20] <ubitux> those examples are actually pretty useful
[17:20] <ubitux> maybe we'll finally realize how bad our api is ;)
[17:39] <iive> ubitux: could you do a very quick explanation on how ref counting is used in avcodec. I assume that get_buffer increases it with one, and release_buffer decreases it. What else uses it?
[17:40] <ubitux> i have absolutely no idea.
[17:40] <ubitux> i "fixed" ref counting in the example merely by trial and error between memleak and invalid reads
[17:41] <iive> one usage might be video_decode output pitcture, In that case the application might +1 when getting the image and -1 when image is no longer visible (e.g. when getting the next picture).
[17:42] <iive> i mean, ref count have much more sense in filters.
[17:50] <nevcairiel> for filters to be able to refcount, the decoder needs to start with that though
[17:51] <nevcairiel> only if the decoder gives you a pitcture of which you control the lifetime, you can safely use it further
[17:51] <nevcairiel> my main use-case is multi-threading, it made handing the frames to a processing thread so much easier, since i know and control how long the frame is valid
[18:10] <wm4> ubitux: anton still has some patches in review, I think
[18:10] <ubitux> ok
[18:11] <wm4> the result should be that the old api just works
[18:11] <wm4> and that there's no difference between avcodec_free_frame and av_frame_free
[18:11] <wm4> (all of which should have done right when refcounting was introduced...)
[18:29] <iive> nevcairiel: but this means that you must have a function that frees the picture after it is not needed. This breaking the old decoding API completely.
[18:29] <nevcairiel> not if you turn off refcounting
[18:29] <nevcairiel> thats why there is a switch
[18:33] <wm4> iive: why?
[18:34] <wm4> the old API requires either 1. that you free the frame (with avcodec_free_frame or the other one), or that you pass the frame to the decoder again
[18:34] <wm4> both of these could unref the old frame
[18:34] <iive> wm4, read the previous line I wrote.
[18:35] <wm4> <iive> i mean, ref count have much more sense in filters.
[18:35] <wm4> ?
[18:35] <iive> well, not literally. above that.
[19:48] <cone-263> ffmpeg.git 03Timothy Gu 07master:d6c5fd9f15c1: tools/: Add gen-rc tool for generating Windows resource files
[20:39] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:6722e564a82b: avformat/hdsenc: fix off by 1 error in array size check
[20:39] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:81c1197494f5: avformat/utils: Check avcodec_open2() return code in av_find_stream_info()
[21:31] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:9ab5cf5417d7: avutil/avstring: fix () position
[21:32] <ubitux> mmh there is no simd byte shift instruction?
[21:33] <ubitux> (x86)
[21:33] <michaelni> no unless it was recently added
[21:33] <ubitux> meeh :(
[21:34] <michaelni> annoyed the hell out of me when optimizing libpostproc
[21:35] <ubitux> BBB: can i assume 0 d E d 127?
[21:37] <ubitux> i need to do a: X*2+Y/2 <= E, with X and Y in [0;0xff], but since i can easily divide (mul is ok with a few add), i was considering doing a X*4+Y d E*2
[21:37] <ubitux> i *can't* easily divide
[21:38] <michaelni> you can average with 0 to get a /2
[21:39] <ubitux> michaelni: oh, nice, thanks :)
[21:40] <michaelni> beware of the rounding though
[21:41] <ubitux> rounding with bytes?
[21:41] <ubitux> is it relevant?
[21:43] <michaelni> avg with 0 does a (a+1)>>1
[21:45] <ubitux> ah, i'll have to -1 then meh
[21:46] <michaelni> if you average with 1 you get a (a+2)>>1, dunno if thats easir but if you can -1 the output for free somewhere
[21:48] <ubitux> i don't think the avg with 1 will help
[21:48] <ubitux> but maybe i'm missing something
[21:56] <ubitux> anyway i can have the 1 in a reg for free
[21:57] <ubitux> (i need it later for something else)
[21:57] <ubitux> lucky \o/
[21:59] <clever> ok, i'm able to get yuv420 frames out of the omx api now, but something isnt right with how i'm handling them
[21:59] <clever> http://gallery.earthtools.ca/index.py/paste/color.png clearly doing something wrong
[21:59] <clever> it should look like http://gallery.earthtools.ca/index.py/paste/before.png
[21:59] <ubitux> share the code
[21:59] <clever> ubitux: http://pastebin.com/gHg6Cdfq
[22:00] <llogan> clever: heh. nice commenting.
[22:01] <clever> http://ext.earthtools.ca/download/rpi/frames/ and here is a dump of the first 7 frames
[22:01] <clever> which oddly, differe in a few areas
[22:02] <clever> the input mkv is also in that dir
[22:03] <clever> if i cat the frames together and play them with mplayer frames.yuv -demuxer rawvideo -rawvideo w=960:h=540 then it doesnt decode right
[22:03] <ubitux> memcpy(buf,src,stride * height);  isn't this valid only for Y?
[22:03] <clever> int stride = decoder->stride >> !!p;
[22:03] <clever> if p is greater then 0, it will halve the stride
[22:04] <ubitux> then isn't else if (p==2) src = decoder->outbuf->pBuffer + (stride*height) + ((stride/2)*(height/2)); wrong?
[22:04] <clever> oh, yeah
[22:04] <clever> let me change that
[22:04] <ubitux> don't we have a pix fmt for that layout already btw?
[22:05] <ubitux> well you can still copy for testing
[22:05] <clever> somebody mentioned that a few times lastnight, but never said what the exact function was
[22:05] <ubitux> but i'm pretty sure you could just set a 3 pointers :p
[22:05] <clever> they also mentioned the case when the gpu stride doesnt match the ffmpeg linelength
[22:05] <ubitux> function? you just make the decoder output the appropriate layout
[22:05] <clever> this buffer is coming directly from the gpu
[22:05] <ubitux> yeah but you could for the linesize, not sure how to do so
[22:06] <ubitux> could *set*
[22:06] <ubitux> anyway, better make it works first
[22:06] <ubitux> you're almost done, right?
[22:06] <clever> i ws told that the linesize field is read-only, but i could create the entire AVFrame from scratch
[22:06] <ubitux> i guess it's time for me to buy a rpi
[22:06] <clever> and point the custom AVFrame to my own buffers
[22:07] <clever> the other problem i have, is the annex b format vs what ffmpeg gives me
[22:07] <ubitux> you still haven't solve that?...
[22:07] <clever> nope
[22:08] <clever> and strangely, omxplayer is sending extradata bare, and works perfectly
[22:08] <clever> ive tried mirroring what it does, and it doesnt work
[22:09] <clever> so for any file i want to play, i have to manualy extract the video track, find the header size, copy it to a header file, then code it to read that file and prepend it
[22:09] <Daemon404> [21:05] <@ubitux> but i'm pretty sure you could just set a 3 pointers :p <-- yeah but DR is a benefit
[22:09] <Daemon404> imo
[22:09] <Daemon404> as a downstream api user.
[22:09] <clever> there is an api on the gpu to pipe the video data directly to the screen, without passing it thru the code at all
[22:09] <clever> but the entire reason i'm doing this is to get video filters to work
[22:10] <Daemon404> funnily enough
[22:10] <Daemon404> i own about 6 arm boards
[22:10] <Daemon404> but none are rpi
[22:10] <Daemon404> :V
[22:10] <Daemon404> so cant help debug
[22:11] <clever> and the api here appears to be a semi-custom one, for just the rpi
[22:11] <Daemon404> omx isnt exactly a well liked thing
[22:11] <Daemon404> amongst devs
[22:11] <clever> the firmware running on the gpu core does the actual parsing and decoding, using special instructions on the gpu core
[22:11] <clever> and i have a feeling that some parts of that firmware differ from platform to platform, even with matching die's
[22:12] <Daemon404> both the if p==1 and p==2 are wrong
[22:12] <Daemon404> in your paste
[22:12] <clever> i just edited those
[22:13] <Daemon404> both?
[22:13] <clever> yeah
[22:13] <Daemon404> k
[22:13] <clever> it also gave corruption if i just let it increment stride between all passes
[22:14] <Daemon404> paste the new code then
[22:14] <clever> http://pastebin.com/BeguDGj2 is currently compiling
[22:14] <Daemon404> p==1 is still wrong
[22:15] <Daemon404> youre only skipping half the luma buffer,
[22:15] <Daemon404> er, 1/4
[22:15] <Daemon404> er ignore me.
[22:15] <clever> it looks pretty decent now, 90% of it is perfect
[22:15] <clever> let me screenshot
[22:16] <Daemon404> also that src += at the end does nothing
[22:16] <clever> oh, yeah, have to remove that now
[22:17] <clever> http://gallery.earthtools.ca/index.py/paste/almost.png
[22:17] <clever> except for the top and bottom, its perfect
[22:17] <Daemon404> are you sure omx ends it raw
[22:17] <Daemon404> without some header
[22:17] <Daemon404> sends*
[22:17] <clever> http://ext.earthtools.ca/download/rpi/frames/frame7.yuv
[22:17] <clever> thats an exact copy of the buffer
[22:18] <clever> 00000000  eb eb eb eb eb eb eb eb  eb eb eb eb eb eb eb eb  |................|
[22:18] <clever> *
[22:18] <clever> 00000070  eb eb eb eb eb eb eb eb  a9 a9 a9 a9 a9 a9 a9 a9  |................|
[22:18] <clever> looks like about 0x75 bytes/pixels worth of Y for the white bar, followed by the yellow bar
[22:19] <clever> frame 1 is a bit more off
[22:19] <clever> http://pastebin.com/RUjKEJfh frame 1
[22:19] <clever> the first 16 bytes dont match the rest
[22:24] <clever> Daemon404: hmmm, can gimp show the y u and v components of a pixel?
[22:25] <clever> thats interesting, there is a 2 pixel distortion at the boundry of each color, when running mplayer on a proper computer
[22:25] <ubitux> do you know pgmyuv? @_@
[22:25] <Daemon404> clever, sounds liek alignment stuff
[22:25] <clever> the 2 drasticaly different colors must have landed on the same 2x2 block
[22:26] <Daemon404> omx might have N-bit slignment for panes
[22:26] <Daemon404> in memory
[22:26] <Daemon404> check its docks
[22:26] <Daemon404> er docs
[22:26] Action: Daemon404 stabs his hands
[22:26] <clever> ubitux: i tried image magic to convert it, it also gives corruption
[22:27] <clever> Daemon404: there are alignment requiremenets when i create the buffer itself
[22:27] <clever> posix_memalign(&decoder->output_buffer, portdef.nBufferAlignment, portdef.nBufferSize);
[22:27] <clever> this ensures that the buffer has the proper alignment when it gets allocated
[22:28] <Daemon404> clever, planes may need to start on an aligned place
[22:28] <Daemon404> hence the 2 byte padding
[22:29] <clever> i dont think there is any padding at all
[22:29] <clever> buffer size is 783360
[22:29] <Daemon404> so it can overread/write the previous buffer
[22:29] <clever> Got new port settings width=960, height=540
[22:29] <clever> 518,400 pixels total
[22:30] <Daemon404> *1.5 = 77760
[22:30] <Daemon404> *1.5 = 777600*
[22:30] <Daemon404> 777600 != 783360
[22:30] <clever> yeah, thats not what the math gave last night
[22:30] <clever> it was a perfect match when i was using the 1080 40mbps file
[22:30] <Daemon404> ...
[22:30] <clever> i didnt recheck the math on this 960x540 file
[22:30] <Daemon404> because that clip happened to have a widt hand height that matched perfectly with teh alignment requirements
[22:31] <clever> yeah
[22:31] <Daemon404> this is why you reads docs an dont just do imperical tests
[22:31] <Daemon404> er emprical
[22:31] <Daemon404> fff typos.
[22:37] <clever> Daemon404: the documents say that you must never put 2 planes in the same buffer payload
[22:37] <clever> which is exactly what the gpu is doing to me!
[22:38] <clever> they are breaking their own rules, or i am not reading them right
[22:39] <Daemon404> YOU must not
[22:39] <Daemon404> they can
[22:39] <Daemon404> english!
[22:40] <clever> lol
[22:40] <clever> but it doesnt say you or they
[22:41] <clever> 'when the uncompressed image data format is planar, data from 2 different planes cannot reside in the same buffer payload'
[22:41] <ubitux> this is just the definition of planar
[22:41] <Daemon404> it depend if theyre talking about input or output.
[22:42] <Daemon404> ubitux, no it is not
[22:42] <wm4> what is a "buffer payload"? some omx thing?
[22:43] <clever> i believe it refers to the buffers used to pass data in and out of the gpu
[22:43] <clever> and to pass data arround inside the gpu when 2 components are linked with a tunnel
[22:44] <clever> aha, the slice height is 544, but the actual height is 540!
[22:45] <nevcairiel> that happens
[22:45] <clever> now to modify the math to include that...
[22:45] <nevcairiel> needs to be mod16 or something like that
[22:45] <Daemon404> like i said
[22:46] <clever> yeah, thats why i was checking this field
[22:46] <clever> the example code i was going on never touched it
[22:46] <clever> but the example was also using OMX_COLOR_Format32bitABGR8888, which is much simpler
[22:46] <clever> 4 bytes per pixel, done
[22:50] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:f6173fed608b: postproc: fix null pointer dereference with invalid option strings
[22:50] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:37437d97a8e6: tools/probetest: Check av_realloc() return code
[22:54] <clever> Daemon404: yep, much much much better
[22:54] <clever> the artifacts are now so small, its hard to tell if its the tv or decoding
[22:55] <clever> need to screenshot and zoom in to compare things
[22:58] <clever> only 2 rows of pixels are bad, at the very bottom
[22:58] <clever> looks like i cut off the u and v for a single row
[22:58] <cone-263> ffmpeg.git 03Diego Biurrun 07master:3bb91a1b5c4a: configure: Add -D__USE_MINGW_ANSI_STDIO=1 to CPPFLAGS on MinGW64
[22:58] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:95ad2483c33a: Merge commit '3bb91a1b5c4a0c5ec9c4d3b6649b23285c3d7f26'
[23:00] <clever> hmmm, but this test pattern has no horizontal marks, so the entire image could be shifted up and i wouldnt know it
[23:01] <clever> back to the 1080 image to see how well that one does
[23:11] <clever> Daemon404: 1080 video looks great now
[23:11] <clever> so that just leaves the extradata issue
[23:14] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:b769cf4b44c8: hevc: do not dereference pointer before NULL check in verify_md5()
[23:14] <cone-263> ffmpeg.git 03Gildas Cocherel 07master:33452aede6ac: hevc: store the VPS list as an AVBufferRef, just like the others *PS
[23:14] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:1dbb3cfa17c1: Merge commit 'b769cf4b44c8112827c2fdfcab74bd95600fd6d3'
[23:14] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:12a404244523: Merge commit '33452aede6acab78f726cd1924824585f00765cc'
[23:20] <cone-263> ffmpeg.git 03Guillaume Martres 07master:17a10d51b835: hevc: set time_base when possible
[23:20] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:dee6d5f51c72: Merge commit '17a10d51b8351ce9a57fcb6537b6a3c6ec8ba5e9'
[23:24] <cone-263> ffmpeg.git 03Anton Khirnov 07master:eb891b3114f4: Replace all uses of avcodec_free_frame with av_frame_free().
[23:25] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:4cbf3eb9e6a8: Merge commit 'eb891b3114f499e96b9faddd0b0ae856345dfbd9'
[23:36] <cone-263> ffmpeg.git 03Anton Khirnov 07master:943135621830: lavc: deprecate avcodec_free_frame()
[23:36] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:409a143e4b49: Merge commit '943135621830ac3857d3cf766cfc280a95bb3c13'
[23:41] <cone-263> ffmpeg.git 03Anton Khirnov 07master:674fa49110a6: avconv: do not call avcodec_get_frame_defaults()
[23:41] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:e22e943ef90e: Merge commit '674fa49110a661694188a958be13d529b7c8c5dd'
[23:47] <cone-263> ffmpeg.git 03Anton Khirnov 07master:95a8a5aca60c: lavc: call av_frame_unref() instead of avcodec_get_frame_defaults().
[23:47] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:27e79779821e: Merge commit '95a8a5aca60ce37d3abdf121a0285c2e317cf521'
[23:56] <cone-263> ffmpeg.git 03Anton Khirnov 07master:84f131921ffb: avplay: do not call avcodec_get_frame_defaults().
[23:56] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:5a15bd6f2f40: Merge commit '84f131921ffb43d8070d5680e91f6a24d66ccac4'
[00:00] --- Thu Dec 12 2013