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

Mon Aug 20 03:05:03 EEST 2018

[00:32:11 CEST] <kierank> michaelni: is raw mpeg4video actually supported
[00:34:36 CEST] <kierank> what does this mean
[00:34:37 CEST] <kierank> [mpeg4 @ 0x2f49a40] slice end not reached but screenspace end (2 left 000000, score= -28)
[00:55:32 CEST] <jamrial> kierank: that log error goes as back as 2003. end decode_slice() in h263dec.c
[00:55:45 CEST] <jamrial> some padding thing?
[00:55:48 CEST] <kierank> I know where's it's from but it of course makes no sense
[00:55:59 CEST] <jamrial> christ, this function depends 50% on workaround_bugs logic
[01:00:52 CEST] <kierank> problem is I don't know which samples are intra
[01:13:06 CEST] <michaelni> kierank, mpeg4-es (if i call it that way) is supported
[01:13:46 CEST] <kierank> well the reference samples don't decode
[01:13:48 CEST] <kierank> for some reason
[01:13:53 CEST] <kierank> but the ones I have do
[01:13:57 CEST] <michaelni> thats odd
[01:15:08 CEST] <kierank> the samples I have are mxf
[01:15:34 CEST] <kierank> http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_IEC_14496-4_2004_Conformance_Testing/video_conformance/studio/
[01:17:31 CEST] <kierank> [mpeg4 @ 0x2765440] slice end not reached but screenspace end (1 left 000000, score= -58)
[01:17:34 CEST] <kierank> that's the only error
[01:25:51 CEST] <michaelni> ahh these are studio profile, which of them is suppsoed to work ? many seem to use unsupported features like DPCM
[01:30:10 CEST] <kierank> the first frame of them are normal I frames
[01:30:22 CEST] <kierank> I'm trying to test my dpcm code now
[01:40:49 CEST] <michaelni> kierank, i think studio profile doesnt do the same padding that the other profiles do at the end of slices. This could trigger "slice end not reached..." i think
[01:42:30 CEST] <kierank> great, I have to now understand the messiest code in lavc
[01:45:52 CEST] <kierank> there might be assumptions in studio mode that 1 mb per slice
[01:53:05 CEST] <michaelni> i think you only need to return SLICE_END at the end of slices, especially the end of the last slice
[01:53:45 CEST] <michaelni> i have no testcase so iam guessing but the only code i see returning SLICE_END in studio profile requires 24 more bits
[01:54:14 CEST] <michaelni> maybe studio profile allows the last slice to end with less
[01:55:17 CEST] <michaelni> non studio doesnt require this
[01:57:50 CEST] <kierank> michaelni: eh?
[01:58:30 CEST] <kierank> do {
[01:58:30 CEST] <kierank> StudioMacroblock()
[01:58:30 CEST] <kierank> } while ( next_bits() != 000 0000 0000 0000 0000 0000 )
[01:58:30 CEST] <kierank> next_start_code_studio()
[01:58:38 CEST] <kierank> so 23 bits of zero is end of slicec
[02:00:00 CEST] <michaelni> this is maybe true if you consider a file to be a single bitstream but maybe is not once it is split into frames 
[02:05:30 CEST] <kierank> the predictor stuff might not work with multiple macroblocks per slice
[02:48:03 CEST] <cone-026> ffmpeg 03Michael Niedermayer 07master:46753bfdd018: avformat/dashdec: Fix strlen(rep_id_val) with it being NULL
[03:19:45 CEST] <kierank> michaelni: sorry I don't see what the issue is with the current code
[03:19:48 CEST] <kierank> it retuns at end of slice
[03:23:42 CEST] <kierank> michaelni: nobody can understand that magic padding code
[04:00:53 CEST] <cone-026> ffmpeg 03Ronak Patel 07master:223d2bde22ce: Improve hls VOD mode hls performance problem.
[04:43:39 CEST] <cone-026> ffmpeg 03James Almer 07master:de1b44c20604: avformat/matroskaenc: handle AV1 extradata in packet side data
[09:26:45 CEST] <Compn> is it emu edge, h264 cropping, or something else hmmm
[09:27:06 CEST] <Compn> i remember emu edge was a difficult thing back when h264 was new
[09:46:23 CEST] <gagandeepsingh> kierank:for that check everything will work if we keep check only on s->a_width, s->a_height, s->a_format 
[09:46:40 CEST] <gagandeepsingh> and remove check on s->coded_width, s->coded_height
[09:47:01 CEST] <gagandeepsingh> as s->a_width is set using s->coded_width during buffer allocations
[09:47:20 CEST] <gagandeepsingh> and later you set s->coded_width = 0
[09:47:52 CEST] <gagandeepsingh> and error is given when s->coded_width is non zero
[14:46:54 CEST] <kierank> michaelni: testing your patch, thanks
[15:08:27 CEST] <kierank> michaelni: did you actually get the first frame out?
[15:22:20 CEST] <kierank> ok on some samples I do
[16:01:39 CEST] <durandal_1707> kierank: where are you stuck?
[16:02:01 CEST] <kierank> can't get some blocks to look right
[16:02:24 CEST] <kierank> also chroma blocks can be wrong when same luma block is right
[16:02:26 CEST] <durandal_1707> so bitparsing is 100% working?
[16:02:39 CEST] <kierank> yes bitparsing is good for iframes I think with michaelni code to find slice end
[16:03:36 CEST] <durandal_1707> kierank: you pushed wip code somewhere?
[16:03:40 CEST] <kierank> I maybe got rice code wrong I guess
[16:05:37 CEST] <kierank> durandal_1707: https://github.com/kierank/ffmpeg-sstp
[16:05:42 CEST] <durandal_1707> you could add bunch of printfs to find what kind of blocks have artifacts
[16:05:52 CEST] <kierank> ffmpeg -loglevel debug -threads 1 -i vcon-stp11L1.bits -threads 1 -ss 0.04 -f rawvideo -y out.yuv
[16:06:01 CEST] <kierank> I can't
[16:06:07 CEST] <kierank> it's all i-blocks
[16:08:10 CEST] <atomnuker> durandal_1707: I got some mad fft code working, can't believe it works
[16:08:36 CEST] <atomnuker> supports floats and doubles and wraps complex.h if its there, otherwise does things manually with a macro
[16:09:58 CEST] <atomnuker> right now I've ported mdct15, just needs the ptwo fft to work as it did before
[16:10:40 CEST] <atomnuker> for some reason the ptwo fft uses doubles in some internal calculations but outputs floats
[16:12:12 CEST] <atomnuker> hopefully the asm doesn't, but if it doesn't that means there'll be a precision mismatch between c and asm and that's not good (more so than if you used fma occasionally)
[16:14:51 CEST] <durandal11707> kierank: so y plane is always correct? your program cant extract Y plane? mpv can
[16:15:02 CEST] <kierank> y plane is mostly correct
[16:15:51 CEST] <kierank> weird because y looks ok cb bad cr good
[16:15:52 CEST] <durandal11707> each macroblock have own sync code?
[16:15:58 CEST] <kierank> no
[16:16:04 CEST] <kierank> it has slices with n macroblocks
[16:16:22 CEST] <durandal11707> and with custom positions?
[16:16:53 CEST] <kierank> I think linear
[16:17:02 CEST] <kierank> custom mode and scan order
[16:21:21 CEST] <durandal11707> this T L TL prediction is strange
[16:22:36 CEST] <durandal11707> why is rice parameter 15 becoming 0 ?
[16:23:21 CEST] <kierank> rice_parameter: This is an unsigned integer that indicates the length of the rice_suffix_code field. The value 0 is
[16:23:21 CEST] <kierank> forbidden. The value 15 shall be interpreted as 0. 
[16:24:01 CEST] <kierank> i suspect a mistake in prediction code
[16:28:06 CEST] <durandal11707> kierank: is that sample triggering block_type == 2?
[16:28:14 CEST] <kierank> yes
[16:28:26 CEST] <durandal11707> well, it is wrong
[16:28:43 CEST] <kierank> I am trying to set block_type 2 to black
[16:28:45 CEST] <kierank> but it's not working
[16:28:51 CEST] <kierank> so I have a stride error I guess
[16:28:55 CEST] <kierank> durandal11707: how?
[16:30:02 CEST] <durandal11707> kierank: it starts from w to >0 but it should be w-1 to >=0
[16:31:57 CEST] <kierank> hmmm
[16:32:01 CEST] <kierank> yes true
[16:35:16 CEST] <kierank> durandal11707: not any better
[16:38:17 CEST] <durandal11707> you changed dest_pcm[i] too?
[16:38:50 CEST] <kierank> durandal11707: to do what
[16:39:37 CEST] <durandal11707> you can not make it to point to the end
[16:39:37 CEST] <kierank> afaik that's indexed correctly
[16:40:17 CEST] <kierank> already done I think
[16:40:24 CEST] <kierank> dest_pcm[i] += (linesize[i] / 2) * (16 >> vsub);
[16:40:31 CEST] <kierank> points to beginning of last row
[16:41:17 CEST] <kierank> just rewrote block_type=1 to black
[16:41:24 CEST] <kierank> no artefacts so must be block_type=1 broken
[16:41:49 CEST] <durandal11707> ((16 >> vsub) - 1)
[16:42:21 CEST] <kierank> yes true
[16:42:47 CEST] <kierank> god this reverse scan is confusing
[16:45:55 CEST] <kierank> ah get_bits(gb, 0 is forbidden)
[16:46:04 CEST] <durandal11707> yea
[16:46:58 CEST] <durandal11707> get_bitsz
[16:47:24 CEST] <kierank> ah there is function for this
[16:49:46 CEST] <durandal11707> atomnuker: you can use doubles in asm too i think
[16:50:03 CEST] <kierank> ah yes get_bitsz removes lots of artefacts
[16:51:08 CEST] <kierank> https://twitter.com/kierank_/status/1031191813858779136
[16:55:38 CEST] <kierank> block_type=2 still does nothing
[16:56:03 CEST] <kierank> I set to green (0x0 value) and still comes out black
[16:57:01 CEST] <atomnuker> durandal11707: yeah, but you have to truncate at some point, and whatever you do you halve throughput and have to pay the price for splitting registers
[16:57:17 CEST] <atomnuker> doesn't seem it would be worth it, so I'd rather have the float fft be fully float
[17:02:03 CEST] <kierank> durandal11707: bah, so close
[17:04:57 CEST] <durandal11707> kierank: it doesnt makes sense to be always black no matter what you set it to
[17:05:05 CEST] <kierank> yes
[17:05:20 CEST] Action: kierank looking at reference decoder source
[17:05:25 CEST] <kierank> 200MB of code
[17:08:00 CEST] <kierank> yeah doesn't have right things
[17:13:55 CEST] <durandal11707> perhaps prediction goes nuts and it sets everthying to negative numbers and that it is black? u/v should be black too
[17:14:28 CEST] <durandal11707> * u/v shouldn't
[17:15:20 CEST] <kierank> gonna printf some pixel values
[17:16:13 CEST] <durandal11707> exact output values? there is datascope filter for that
[17:18:46 CEST] <kierank> actually I think I know what hte problem is
[17:20:26 CEST] <kierank> I don't fully understand the predictor reset rules
[17:23:12 CEST] <kierank> actually it's not block_type=2 at the moment
[17:23:21 CEST] <kierank> crap
[17:36:54 CEST] <durandal11707> kierank: post screenshot of page where predictor rules are
[17:37:07 CEST] <kierank> i think bug might be clipping
[17:37:31 CEST] <kierank> clipping gives small improvement
[17:39:24 CEST] <kierank> this could be ffmpeg but with idct actually
[17:39:27 CEST] <kierank> values are not clipped correctly
[17:40:37 CEST] <kierank> michaelni: does ffmpeg not clip output of idct as per mpeg-4 specification?
[17:40:46 CEST] <kierank> between 0 and 2^(bit_depth) - 1
[17:48:37 CEST] <kierank> durandal11707: gonna give up
[17:49:08 CEST] <durandal11707> kierank: push your latest changes to github
[17:49:16 CEST] <kierank> I will
[17:49:36 CEST] <kierank> https://usercontent.irccloud-cdn.com/file/gNg3sb6e/image.png
[17:49:45 CEST] <durandal11707> kierank: so block type 2 is not triggered at all?
[17:50:08 CEST] <kierank> not when i force single frame decode
[17:50:09 CEST] <kierank> ffmpeg -loglevel debug -threads 1 -i vcon-stp11L1.bits -threads 1 -frames 1 -f rawvideo -y out.yuv
[17:51:35 CEST] <durandal11707> ugh, that doesnt make sense
[17:52:35 CEST] <kierank> sample may have unsupported features i guess
[17:55:39 CEST] <durandal11707> Here is my working BT20 decoder: https://github.com/richardpl/FFmpeg/blob/bt20/libavcodec/prosumer.c feel free to clean it up
[18:46:17 CEST] <kierank> durandal11707: I dunno what else to do
[18:56:01 CEST] <durandal11707> kierank: take a little break, then tomorrow try again :)
[19:00:09 CEST] <kierank> Got work tomorriw
[19:01:08 CEST] <durandal11707> quit job
[19:03:45 CEST] <durandal11707> hire someone to do it!
[19:34:10 CEST] <durandal11707> j-b: are you there?
[20:16:32 CEST] <kierank> durandal11707: hmm so it definitely on a rice code block
[20:42:04 CEST] <durandal11707> kierank: there are other blocks?
[20:42:16 CEST] <kierank> yes normal idct block
[20:42:30 CEST] <kierank> https://usercontent.irccloud-cdn.com/file/911nrluQ/image.png
[20:42:32 CEST] <kierank> rice blocks set to black
[20:44:02 CEST] <durandal11707> so only some rice blocks do not decode properly
[20:45:01 CEST] <kierank> yeah
[20:45:09 CEST] <kierank> depends on component
[20:49:08 CEST] <kierank> I think related to bizzare mpegvideo.c code
[20:49:24 CEST] <kierank> chroma blocks are stored in crazy way
[20:49:51 CEST] <durandal11707> ? so if you set chroma to 0 it is not green?
[20:50:17 CEST] <kierank> dunno
[20:50:23 CEST] <kierank> not sure any more
[20:51:02 CEST] <kierank> actually some luma is screwed too
[20:52:42 CEST] <durandal11707> kierank: perhaps parsing is source of that, the slice end finding looks strange
[20:52:50 CEST] <kierank> maybe
[20:53:01 CEST] <kierank> but that code is totally impossible to understand
[20:53:02 CEST] <durandal11707> check for underreads and for overreadds
[20:53:05 CEST] <kierank> michaelni: magic
[20:53:10 CEST] <kierank> michaelni magic
[20:54:16 CEST] <durandal11707> if single macroblock in slice is broken than all rest of slice should be too, if parsing is buggy
[20:55:50 CEST] <kierank> yeah i think parsing screwed
[20:56:57 CEST] <kierank> michaelni: do you know what was special with vcon-stp10L1.bits
[20:57:32 CEST] <kierank> vcon-stp11L1.bits i mean
[20:58:15 CEST] <kierank> seems like ffmpeg has read the right size
[22:09:21 CEST] <michaelni> kierank, about idct, the put/add idct stuff clips as required, it has to. about vcon-stp11L1.bits, without looking into it i have no idea at all
[22:10:34 CEST] <kierank> Ok
[22:10:41 CEST] <kierank> It was the only one that you didn't comment
[22:10:56 CEST] <kierank> Seems to be the only one FFmpeg can decode as well
[22:12:35 CEST] <michaelni> the comments are based on testing with abort(), if its not mentioned it triggered neither codepath or i missed it
[22:15:23 CEST] <michaelni> the 11L1 one doesnt seem to decode slices till their end with git master thats probably why it didnt trigger either end detection
[22:36:50 CEST] <kierank> I don't understand what is wrong
[22:42:28 CEST] <kierank> Amendment 1 (Studio Profile)
[22:42:28 CEST] <kierank> Actually, there is no available implementation to this amendment regarding to MS version of reference software. It requires some volunteer to take responsible for this part if possible.
[22:42:29 CEST] <kierank> ffs
[22:53:36 CEST] <kierank> % Modulus operator. Defined only for positive numbers
[22:53:40 CEST] <kierank> hmmm could be why
[00:00:00 CEST] --- Mon Aug 20 2018