<ndufresne>
I was expected fields to say which set of fields (top or bottom) is being referenced,
jagan_ has joined #linux-sunxi
<ndufresne>
arg never mind, got a wake up
<ndufresne>
reference in ffmpeg being binary compatible, just masking here
<ndufresne>
ok got it I think, if the current picture is a frame, then you upgrade complete ref to frame when both fiels are available, otherwise you only reference the available field, that logic is already implemented higher up in ffmpeg H264Ref
<ndufresne>
jernej: 125/135 ;-D
<jernej>
oh, that's even better than ffmpeg :)
<ndufresne>
I'll create a new summary and update the snippet on gitlab
<jernej>
great!
<jernej>
are you testing with tiled nv12?
<ndufresne>
with ffmpeg binary, strict = normal, I get 120 with sw decode, so I'm not sure we'll easily get further
<ndufresne>
yes, all test was with tiled NV12
<ndufresne>
but forcing NV12 gives identical results, I think the HW detiler is correct
<jernej>
you said strict = strict is worse, right?
ftg has joined #linux-sunxi
<ndufresne>
yeah, in the command line its worst, in gst libav, were we only set that to the decoder (not the parser) its better
<ndufresne>
I didn't figure-out how to set strict to the decoder only with the command line, the thing is global
<ndufresne>
note that some sample fails due to really large height (Even though in the spec, we have a squared restriction in most of the HW we have)
<ndufresne>
and then FMO/ASO samples fails too
<jernej>
so, is there any case left to fix?
<ndufresne>
in theory, 4 more on gst side
<ndufresne>
and that would match our results with libav sw dec, d3d11 and Intel VA
<jernej>
I'm not sure there is anything to improve on driver side, at least regarding decoding correctness
<ndufresne>
but I think I'll upstream what I got, as it way way better
<ndufresne>
indeed, we stated that ASO/FMO is out of scope, so if anything else comes, it will be about adding scalable extension other
<jernej>
so, next gstreamer release will be relly important for v4l2 request api decoding
<ndufresne>
but what is the point of looking at that till we have HW, and H264 is eol anyway
<ndufresne>
yep, will be a much better h264 decoder
<ndufresne>
but 1.20 also comes with async decode and better memory usage
<ndufresne>
we use to match the number of bitstream and picture buffers, which was a huge memory overhead
<ndufresne>
now if only someone dared reviewing code on FFMPEG side
<ndufresne>
APi is stable, conformance test shows this is really good
<ndufresne>
perhaps naming is ... but they could at least comment on that
<jernej>
ffmpeg code was already reviewed (current, lock step approach)
<ndufresne>
oh, missed that part
<ndufresne>
what was the main thing to fix ?
<jernej>
but kwiboo never followed up after (I think second) submission
<ndufresne>
isn't he still out of the game 6
<jernej>
he is
<ndufresne>
then no-one to blame, we are all human