<ndufresne>
I believe I copy pasted that formula from VAAPI code, but this is legacy in VAAPI, no drivers actually uses it
<jernej>
interesting
<ndufresne>
that should fix a lot of streams I suppose
<jernej>
now we must make sure that this is indeed correct way and not an actual bug in Cedrus
<ndufresne>
frame 42 was the first frame with an emulation byte
<ndufresne>
right
<jernej>
ndufresne: hantro doesn't use this value?
<ndufresne>
no, hantro and rkvdec don't
<ndufresne>
cause they parse the slices
<ndufresne>
Just re-read va.h doc, and the fixed formula match
<ndufresne>
not sure which Intel driver used it, but it has been broken in gst since day one probably
<ndufresne>
jernej: My guess would be that the HW preprocess the emulation bytes prior to parsing, so it does not know were was located the emulation bytes and would not understand a skip value that includes these bytes
<ndufresne>
e.g. the skip is used lower in the processing pipeline
<jernej>
ok, then
<jernej>
I guess it would be time to run H264 fluster tests on Cedrus
<ndufresne>
you read my mind, I'm running it now
Mangy_Dog has joined #linux-sunxi
<ndufresne>
I'll share the report, doing your latest ffmpeg and gst
<ndufresne>
I'd like to bring that at least on par
<ndufresne>
jernej: btw, we discovered that by default, ffmpeg implement an out of spec DPB bump algo to decrease latency
<ndufresne>
but it has the side effect that it will skip b-frames with some pattern, which of course breaks couple of test
<ndufresne>
I need to figure-out how to set it to strict mode while running fluster
<jernej>
oh, I didn't know that
<ndufresne>
we also had similar algo in gst, but decided to put that under a properly
<jernej>
to be honest, I'm only familiar with HW decoding process and not so much with codec details
<ndufresne>
my knowledge is also full of wholes
<ndufresne>
e.g. I learn 3w ago that there exist closed gops that will output the result of a B frame first, not the keyframe
<ndufresne>
as long as the B frames only have future references, this is entirely valid, and that's what brings the negative timestamps
<jernej>
oh, joy
<ndufresne>
so far, ffmpeg Ran 119/135 tests successfully
<ndufresne>
quite devent result
<ndufresne>
* decent
<ndufresne>
what I hope for is that gst passes from test ffmpeg fails and vis-versa, so we can get both into better shape ;-P
<jernej>
that would be wonderful, but I think it's more likely some HW limitation
<jernej>
are those only 8-bit tests?
<jernej>
all 10-bit will fail
<ndufresne>
10bit will fail indeed
<jernej>
I have yet to implement proper 10-bit output on H6 (currently it's trimmed to 8-bit)
vagrantc has joined #linux-sunxi
<jernej>
and only HEVC
<ndufresne>
hmm, seems like something go wild when running fluster with gst
<ndufresne>
the driver stops working passed CABACI3_Sony_B
<jernej>
due to header size change?
<ndufresne>
no, I doubt its related
<ndufresne>
actually might be nfs issues
<ndufresne>
I need to look into removing the yuv write to disk, and use tool reported md5 instead, will be much faster, and less error prone
<ndufresne>
jernej: the difference between gst and ffmpeg, is that gst will submit multiple slices and get them queued in advance, while ffmpeg mostly operate in lock step
<ndufresne>
that should in theory trigger a different path to trigger the next decode operation, perhaps there is some race in there, or its just some gst bugs ... I'll have to work harder
<jernej>
I have yet to find motivation to rework ffmpeg patches in similar fashion
<ndufresne>
easyier to get that motivation when you actually got a stream to make it work
<ndufresne>
do you have any 4k@60 content ? I needed that in gst to reach that on rk3399
<ndufresne>
I was around 55fps before
<ndufresne>
iirc, JohnC was using some other mechanism, some threading in ffmpeg
<ndufresne>
uh, 57/135 for gst, got plenty of work
<jernej>
ndufresne: thanks, at least there are some tests that gst passes and ffmpeg does not :)
<jernej>
still, I'm not too concerned about them
<ndufresne>
yeah, 4 I think, but i need to find how to tick the "strict" mode first, cause it would be just that
<jernej>
at least not at this point
<jernej>
ndufresne: If I'm not mistaken, BA1_FT_C is test for multiple slices
<jernej>
maybe you have some bug there?
<ndufresne>
maybe
<ndufresne>
but as I said, in multislice, I use the VB queue a lot
<ndufresne>
I'm definatly investigate all this
<jernej>
how much tests gst passes with hantro?
<ndufresne>
I'm on hold on my project till Friday, and pretty much all my team is on vacation, so now is the time
<ndufresne>
I think about 120, but I would need to try again
<ndufresne>
things are moving as always
<ndufresne>
e.g. these days I'm getting driver hang with rkvdec, making regression testing really hard, but it looks like platform regression, fails setting some vdu power domain and then hang
<ndufresne>
I need create an up to date imx8m setup for hantro G1 testing, as it differ a lot from rk hantro g1
<ndufresne>
jernej: so current status, our new VA API plugin in gst scores at 130/135, that's very similar API to Cedrus, so my issue is likely in the translation and the mechanism to handle slices
<jernej>
kwiboo and I took a look of code from vaapi codecs in ffmpeg
<ndufresne>
oh, sw decode in ffmpeg seems to so 120/135, so we can pretty much assume cedrus/ffmpeg is passing the test (minus one)
chewitt has quit [Quit: Zzz..]
chewitt has joined #linux-sunxi
<jernej>
let me see if I can find that strict mode
<ndufresne>
looks like its just -strict <something>
<ndufresne>
but I don't see to be setting it properly, as I see no delta
chewitt has quit [Remote host closed the connection]
tllim has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit []
<ndufresne>
jernej: so on the command line, there is input and out file option, as output file option, it has no effect, as input file option, strict makes it worst
<ndufresne>
seems like strict is applied to more then just the decoder
<ndufresne>
in gst, I just reproduce the result, with gst ffmpeg wrapper, it goes from 100 to 129 indeed
<ndufresne>
(this is all very odd results)
<jernej>
that's unexpected, but ok...
tllim has joined #linux-sunxi
tllim has quit [Remote host closed the connection]
tllim has joined #linux-sunxi
tllim has quit []
chewitt has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
<ndufresne>
jernej: a bit unexpected, but tiled format got picked in fluster now, and that crashed in videoconvert