v4l2codecs: Delayed linking failed

[Nicolas Dufresne]

Le mardi 17 août 2021 à 21:51 +0530, Jagan Teki a écrit :
> Hi Nicolas,
> 
> On Wed, Aug 4, 2021 at 7:35 PM Nicolas Dufresne <nicolas at ndufresne.ca> wrote:
> > 
> > Sorry for the top post, I know it's confusing but only got a phone to reply.
> > 
> > The best way to debug this issue is to dump the v4l2 structure before they are passed to the kernel. You could implement static traces, but I've been using gdb script to do so. When you have that dumped for each implementation, you can then find what diverged and we can start debugging. If you can roll-back GStreamer and find a working revision, that also helps, as you can then bisect.
> > 
> > I assume now that decoding is clean with ffmpeg and mainline Linux.
> 
> Unfortunately, I was off due to Covid Infection. I will resume to work
> tomorrow. If you have anything for me to do please let me know. I
> wouldn't figure it any clue last time.

Hope you are getting better and do now have lasting side effects.

I've started to look into that today, it seems to break around frame 42, now
locating bitstream vs frame isn't simple due to reordering. This is very far and
a lot of data to deal with.

I've cross compiled Jernef ffmpeg with:

./configure --target-os=linux --arch=armv7 --enable-cross-compile --cross-prefix=arm-linux-gnu- --sysroot=/srv/nfs/tritium --prefix=/usr --enable-libudev --enable-libdrm --enable-v4l2-request --pkg-onfig=pkgconf --disable-doc

This is a bit specific to my setup though. Then I've use two gdb scripts
(attached), to dump the V4L2 controls:

gdb -x gdb/gst-h264.txt --args  gst-launch-1.0  filesrc location=videos/Big_Buck_Bunny_720_10s_1MB.mp4 ! qtdemux ! h264parse ! v4l2slh264dec ! videocodectestsink location=gst.yuv > trace-gst.log
gdb -x gdb/ffmpeg-h264.txt --args ./FFmpeg/ffmpeg_g -hwaccel drm -hwaccel_device /dev/dri/card0 -i videos/Big_Buck_Bunny_720_10s_1MB.mp4 -pix_fmt yuv420p -f rawvideo ff.yuv > trace-ffmpeg.log

>From there I've used meld to compare the traces (it's just a side-by-side diff
UI). And I've used YUView to diff the yuv files and locate the first broken
frame.

Note that FFMPEG POC are apparently off by 65536, but accelerators are not
affected by this and will work anyway. GStreamer seems to pass inactive
reference in the DPB, which makes the DPB entry bigger, I'll probably fix that
as it's noise (in fact it is super odd this ACTIVE flag int he DPB). The DPB
order will differ, different implementation, DPB have no meaningful order,
finally FFMPEG timestamps are +1000, an implementation detail.

So ignoring that, I found that FFMPEG sets that scaling list even if none are
present, I hacked something but that made no difference. Then I notice that
header_bit_size in the slice header differ on frame 42 (the breaking point). So
this is my best bet so far, I don't know yet why that value differ.

> 
> Thanks,
> Jagan.