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

[burek]

[00:09:12 CET] <kierank> durandal_1707: can you help me find VLCs in binary?
[00:11:10 CET] <durandal_1707> sure . sleeping now. send email with binary and specification
[00:13:06 CET] <kierank> ok maybe bug found
[00:13:08 CET] <kierank> thanks
[00:32:39 CET] <iive> nevcairiel: compiler should be using cmov, when using march that supports it.
[00:32:50 CET] <nevcairiel> compilers arent always smart
[00:33:36 CET] <iive> they better be, for the cpu power they are wasting :D
[00:39:24 CET] <llogan> kierank: want me to retweet that?
[00:39:30 CET] <kierank> llogan: yes please :)
[00:40:24 CET] <ubitux> https://godbolt.org/g/dD86ee
[00:40:54 CET] <ubitux> i see some cmov here, but i guess you're talking about another implementation? :p
[00:51:54 CET] <nevcairiel> shorter then https://godbolt.org/g/SV5JgX :p
[00:52:50 CET] <nevcairiel> inline asm seems to generate a whole lot of boilerplate around it
[00:53:29 CET] <nevcairiel> oh adding O2 makes it nicer
[00:53:46 CET] <nevcairiel> silly default
[00:55:22 CET] <nevcairiel> clang actually uses more cmov and makes it branchless
[01:30:10 CET] <kierank> what does this mean
[01:30:10 CET] <kierank> Input stream #0:0 frame changed from size:1920x1088 fmt:yuv422p10le to size:1920x1080 fmt:yuv422p10le
[01:30:10 CET] <kierank> Output pad "default" with type video of the filter instance "Parsed_null_0" of null not connected to any destination
[01:30:10 CET] <kierank> Error reinitializing filters!
[01:30:10 CET] <kierank> Conversion failed!
[01:38:43 CET] <llogan> how did you get that?
[01:40:05 CET] <kierank> In the decoder I am writing:
[01:40:05 CET] <kierank> ./ffmpeg_g -threads 1  -i A003C002_SR_Lite_23.98p.mxf -f rawvideo -y /dev/null
[01:40:22 CET] <kierank> seems to be reading 1920x1088 from the container perhaps
[01:40:23 CET] <kierank> not sure
[01:47:22 CET] <kierank> michaelni: do you know why this is the case?
[01:47:23 CET] <kierank> FF_ALLOCZ_OR_GOTO(s->avctx, s->blocks, 64 * 12 * 2 * sizeof(int16_t), fail)
[01:47:32 CET] <kierank> is there already an mpegvideo codec that is doing 10-bit?
[02:11:35 CET] <iive> kierank: 12 is for yuv444
[02:13:17 CET] <iive> but indeed i don't know what the *2 is about.
[02:25:14 CET] <michaelni> kierank, i think the encoder uses the 2nd set
[02:26:09 CET] <kierank> michaelni: can a 10-bit decoder can use it?
[02:27:26 CET] <kierank> also where are the mpeg-4 dcts setup?
[02:28:03 CET] <kierank> oh mpv_decode_mb_internal perhaps
[02:29:35 CET] <michaelni> a 10 in 32bit decoder can maybe use it
[02:33:28 CET] <kierank> michaelni: any idea what this is?
[02:33:28 CET] <kierank> Input stream #0:0 frame changed from size:1920x1088 fmt:yuv422p10le to size:1920x1080 fmt:yuv422p10le
[02:34:00 CET] <kierank> why the hell does it care about 1920x1088 from the container
[02:34:01 CET] <kierank> Output pad "default" with type video of the filter instance "Parsed_null_0" of null not connected to any destination
[02:35:28 CET] <kierank> there's so much magic code in mpegvideo
[02:44:06 CET] <kierank> commenting out the codecpar crap in mxfdec stops the first error
[02:44:09 CET] <kierank> now to deal with this
[02:44:09 CET] <kierank> Output pad "default" with type video of the filter instance "Parsed_null_0" of null not connected to any destination
[02:44:56 CET] <nevcairiel> the first is no error, it just informs you if something changes
[02:45:27 CET] <nevcairiel> if it doesnt stop the second from happening, then you might as well just leave it
[02:45:57 CET] <kierank> I didn't know that
[04:29:49 CET] <kierank> michaelni: what does the -1U mean in ff_init_block_index
[04:29:50 CET] <kierank>     s->dest[0] = s->current_picture.f->data[0] + (int)((s->mb_x - 1U) <<  mb_width);
[04:29:50 CET] <kierank>     s->dest[1] = s->current_picture.f->data[1] + (int)((s->mb_x - 1U) << (mb_width - s->chroma_x_shift));
[04:29:50 CET] <kierank>     s->dest[2] = s->current_picture.f->data[2] + (int)((s->mb_x - 1U) << (mb_width - s->chroma_x_shift));
[04:31:41 CET] <kierank> atomnuker: any idea what's causing this? https://usercontent.irccloud-cdn.com/file/YTZ9723B/frame000000.bmp
[04:31:43 CET] <kierank> the transform or the coefficients?
[04:31:55 CET] <kierank> durandal_1707: also ping when you are awake
[04:45:27 CET] <kierank> hmm dc coefficients look ok
[04:45:31 CET] <kierank> must be something wrong with AC
[04:47:45 CET] <atomnuker> yep, it's the ac
[04:48:43 CET] <kierank> https://usercontent.irccloud-cdn.com/file/u9sSbQg9/dc.bmp
[04:48:45 CET] <kierank> atomnuker: dc coeffs ^
[04:48:52 CET] <kierank> atomnuker: does that imply that the idct scaling is ok?
[05:24:03 CET] <atomnuker> yep, dc looks fine
[05:24:17 CET] <kierank> crap
[05:24:24 CET] <kierank> so close yet so far
[06:34:56 CET] Action: kierank loses the will to live
[09:14:35 CET] <atomnuker> seriously, why a linked list?
[09:16:10 CET] <atomnuker> I don't think I've ever had to use a linked list in any of my programs ever (except in an octree structure, but that only went one way)
[09:17:03 CET] <atomnuker> is that something only people who had formal education in computer science do?
[09:34:19 CET] <durandal_1707> atomnuker: what?
[09:34:30 CET] <durandal_1707> kierank: pong
[09:34:40 CET] <atomnuker> durandal_1707: the mjpegenc patch on the ML
[10:23:13 CET] <ubitux> atomnuker: it's very common to promote linked list in formal CS, it's often presented with only advantages over arrays (even speed)
[10:25:55 CET] <nevcairiel> its more common in object oriented languages though, where fancy language features make it far easier to access elements in them
[10:26:57 CET] <nevcairiel> and if you have huge individual elements but an uncontrolled amount of them, its probably better then reallocing an array
[10:28:38 CET] <atomnuker> no wonder CS people scream null pointer dereferences are the number one source of crashes when they use C, they dug themselves into this hole
[10:29:13 CET] <atomnuker> linked lists won't be faster than an array if all you do is you loop over the elements sequentially
[10:29:50 CET] <atomnuker> its an extra dereference to get the next address rather than just an add
[10:35:09 CET] <JEEB> yup
[10:35:51 CET] <JEEB> "- use of ++var instead of var++. this is not a c++ project." <- also, did C++ do something fancy with pre-addition?
[10:36:20 CET] <JEEB> I remember people saying there was some "possible optimization" with ++var but I don't think it was C++ specific
[10:36:21 CET] <nevcairiel> there are some reasons to use ++var in c++ on dumb compilers, but any decent compiler just optimizes that away
[10:39:42 CET] <nevcairiel> personally i just find it ugly
[10:39:43 CET] <nevcairiel> :D
[10:41:13 CET] <JEEB> yes, that it is
[10:48:45 CET] <cone-380> ffmpeg 03Burt P 07master:f31708002464: af_hdcd: more FATE tests
[12:50:57 CET] <michaelni> kierank, the -1U subtracts 1, the U is needed to avoid some undefined behavior with the shift
[14:44:14 CET] <kierank> michaelni: yes, why subtract 1
[14:58:31 CET] <michaelni> so its correct after ff_update_block_index(), and it was faster this way than in some other order of operations 
[16:05:24 CET] <cone-380> ffmpeg 03Thomas Turner 07master:d7a3c7427f95: avutil/tests/audio_fifo.c: Corrected test error messages
[16:05:25 CET] <cone-380> ffmpeg 03Michael Bradshaw 07master:616513ef6e6d: avcodec/libopenjpegdec: Set key frame metadata
[16:19:11 CET] <cone-380> ffmpeg 03Jan Sebechlebsky 07master:7c91ee01cc8b: libavformat/tee: Add fifo support for tee
[17:04:16 CET] <cone-380> ffmpeg 03Paul B Mahol 07master:49abd5dbb8d1: avfilter/avf_aphasemeter: make video output optional
[17:48:24 CET] <kierank> michaelni: i have problems with the idct writing before the allocated buffer, that's why i ask
[17:49:15 CET] <kierank> BBB: ping
[17:49:23 CET] <BBB> pong
[17:51:12 CET] <kierank> BBB: so I've tried with some success getting the 10-bit dct into mpegvideo, but the picture looks ok-ish but weird. With only the dc coefficients the picture looks like I would expect. Do you have any suggestions about how to debug AC?
[17:51:31 CET] <kierank> dc https://usercontent.irccloud-cdn.com/file/U4l7FE9d/dc.png
[17:52:36 CET] <kierank> also the idct writes before the allocated buffer
[17:53:37 CET] <kierank> I suspect this is mpegvideo.c madness though
[17:54:47 CET] <BBB> the white/black patches look like near-infinite dc values in some frequency
[17:55:00 CET] <BBB> assuming the input coefficients are reasonable, Id assume that means theres an overflow somewhere
[17:55:09 CET] <BBB> probably intermediates not being wide enough somewhere
[17:55:16 CET] <BBB> (try sanitize=integer)
[17:55:52 CET] <BBB> easiest way to debug this is to take one of these blocks and print out coefficients in a 8x8 array (right?) and then print out the 8x8 residual, compare that to a standard matrix float 8x8 idct and see whats different and why
[17:56:10 CET] <BBB> maybe write a checkasm function to do that with synthetic input using only 1 or 2 dc values
[17:56:19 CET] <BBB> and then go from there
[17:56:24 CET] <kierank> it's intra without any prediction so no residual but yes, 8x8
[17:56:45 CET] <BBB> residual is literally diff[]=idct(coeff)
[17:56:58 CET] <kierank> yeah
[17:57:00 CET] <kierank> michaelni: s->dest[0] = s->current_picture.f->data[0] + (int)((s->mb_x - 1U) <<  mb_width);
[17:57:17 CET] <kierank> when s->mb_x = 0 what happens?
[17:57:35 CET] <BBB> if you can give a coeff[8x8] and diff[8x8] and compare that to a float matrix idct we can start from there
[17:57:47 CET] <kierank> BBB: I will fix these mpegvideo segfaults first
[17:57:55 CET] <BBB> okiedokie
[17:58:06 CET] <kierank> mpegvideo has been most of my problems implementing this...
[17:58:17 CET] <kierank> ah I can use a float dct, that's a good point
[18:01:24 CET] <kierank> michaelni: yes, that line is definitely causing the segfault for me
[18:08:04 CET] <kierank> frame start 0x114b0080 write location 0x114b0060
[18:13:30 CET] <michaelni> maybe you dont do the equivalent of ff_update_block_index()
[18:14:13 CET] <kierank> as far as I can tell it's done in h263
[18:14:49 CET] <michaelni> "mb_width" is correct for 10bit ?
[18:15:10 CET] <michaelni> block_size in ff_update_block_index()
[18:15:25 CET] <kierank> -    const int mb_size= 4 - s->avctx->lowres;
[18:15:25 CET] <kierank> +    const int mb_width= 5 - s->avctx->lowres;
[18:15:25 CET] <kierank> +    const int mb_height= 4 - s->avctx->lowres;
[18:16:09 CET] <kierank> I believe i've handled all the width = height assumptions
[18:18:30 CET] <durandal_1707> adding big structures into Ida makes it very slow
[18:19:39 CET] <kierank> michaelni: http://pastebin.com/5N9fhKLh
[18:19:43 CET] <kierank> those are my current mpegvideo.c changes
[18:19:52 CET] <kierank> mainly removing inter for now
[18:19:57 CET] <kierank> for ease of reading
[18:20:13 CET] <kierank> and dealing with the two cases where width is assumed = to height
[18:23:46 CET] <kierank> forcing 1920x1088 for now seems to shut valgrind up
[18:24:03 CET] <kierank> oh maybe not
[18:24:06 CET] <kierank> just doesn't segfault...
[18:38:33 CET] <mjbshaw> I'm making a video filter source for ffmpeg. I see the width/height need to be set in AVFilterPad.config_props. The width and height of my video source is dynamic and may change from frame to frame. Is that problematic? Does the frame size change need to be signaled at all?
[18:40:03 CET] <nevcairiel> dynamic reconfig is one of the silly areas of avfilter, its not supported well, there is somewhere a whitelist of filters known to handle it, iirc
[18:48:20 CET] <durandal_1707> mjbshaw: why would it change from frame to frame?
[18:48:35 CET] <kierank> durandal_1707: why not
[18:53:39 CET] <mjbshaw> durandal_1707: The video frame is dynamically generated based on some user-specified rules. I plan on using heuristics to estimate the initial size of the output frames and will try to adhere to the estimated size, but some frames just might require a larger size to avoid information loss.
[18:54:36 CET] <mjbshaw> nevcairiel: Thanks for that info. I think I'll try following buffersrc.c's behavior and permit frame size changes but log an INFO message.
[18:55:11 CET] <nevcairiel> you can probably do it but expect scale filters to show up in many cases to "fix" it =p
[19:01:00 CET] <BBB> nevcairiel: want to help a user get msvc 64bit working?
[19:02:01 CET] <BBB> I was just called a n00b by someone who says its theoretically impossible to compile ffmpeg on msvc/64bit
[19:02:26 CET] <nevcairiel> and you then want to help them? seems odd
[19:02:32 CET] <BBB> good point
[19:06:12 CET] <BBB> stackoverflow is interesting that way; I just stumbled on a question which is more popular: cabac or cavlc
[19:06:17 CET] <BBB> which would be an interesting question
[19:06:53 CET] <BBB> but the question is about an already-encoded video that he doesnt want to modify, he just wants to overlay a watermark and then encode only the watermark in cavlc/cabac (again, without re-coding the source)
[19:06:55 CET] <nevcairiel> cabac probably, you only use cavlc if you are very concerned about performance I wager
[19:07:00 CET] <BBB> o_O
[19:13:45 CET] <nevcairiel> i see similar questions like that all the time, I want to somehow process a h264 video in its encoded form
[19:13:49 CET] <nevcairiel> seems like a very crazy  idea
[19:19:49 CET] <cone-380> ffmpeg 03Michael Niedermayer 07master:a830ab3f3b1d: ffmpeg: remove stop_encoding variable and related code, it is dead / unused code
[19:50:54 CET] <jkqxz> ~.
[23:16:18 CET] <kierank> BBB: does that look sane http://pastebin.com/yYf6CzwQ
[23:17:06 CET] <kierank> the dct coeffs are already zigzagged
[23:17:07 CET] <BBB> not really
[23:17:24 CET] <BBB> the coeff array looks sane
[23:17:28 CET] <BBB> the idcted residual doesn't
[23:18:28 CET] <BBB> I mean, theres a lot of zeroes, which suggests overflows& the concentration of zeroes in line 4 and 5 is also veyr suspicious
[23:18:51 CET] <kierank> would explain the black patterns I get
[23:19:29 CET] <BBB> I would say that horizontally, the data is essentially mirrored
[23:19:41 CET] <BBB> look at line 1: imagine a divider in position 5
[23:19:46 CET] <BBB> left is 219, right is 220
[23:19:50 CET] <BBB> one step, both 117
[23:19:54 CET] <BBB> one step, 119/118
[23:19:59 CET] <BBB> one step, 662/659
[23:20:05 CET] <BBB> same is true for all following lines
[23:20:14 CET] <BBB> I dont think thats right
[23:20:42 CET] Action: kierank tries with only one AC coefficient
[23:22:30 CET] <BBB> can you give the intermediates after the first 1d idct also? if thats not a ton of trouble
[23:23:05 CET] <kierank> http://pastebin.com/SGyWFnm7
[23:23:08 CET] <kierank> that's one ac coefficient
[23:23:33 CET] <BBB> yeah that makes sense
[23:23:41 CET] <BBB> and if you do the ac in the other direction? same?
[23:23:49 CET] <BBB> (but vertically)
[23:26:14 CET] <kierank> one sec, that's a bit more fiddly to memset
[23:28:57 CET] <kierank> BBB: http://pastebin.com/eNpbcetG
[23:29:18 CET] <BBB> still looks good
[23:30:07 CET] <BBB> I dont know if you can run this on a complete picture, but this should visibly improve the picture relative to the dc-only case
[23:30:37 CET] <BBB> I guess at this point itd make sense to try the 2x2 and 4x4 topleft coefficients non-zero, and zero the rest, and see what happens
[23:31:06 CET] <BBB> if the picture shows artifacts with the 1-ac coefficient (whereas the dc-only looked fine), then maybe we need to look at something else :/
[23:31:18 CET] <kierank> yes I thought the dc looked better throughout
[23:31:25 CET] <kierank> but let me get some pictures
[23:33:54 CET] <kierank> https://usercontent.irccloud-cdn.com/file/xHjD3nu1/dc_singleblock.png
[23:34:20 CET] <BBB> whats the blackness?
[23:36:39 CET] <kierank> I only did one 8x8 block in case I got something wrong in my mpegvideo.c hacking and were overlapping
[23:39:14 CET] <BBB> I mean, the dc_singleblock.png looks like a mosaic tile of (obviously) dc blocks on an otherwise black background, but only ever 2nd block hor/ver is actually drawn (so 25% of total), is that intended?
[23:51:09 CET] <BBB> brb - gotta run home
[00:00:00 CET] --- Thu Dec 29 2016