Possible hardware bug on Tegra SoC used for Jetson TX1

Hi,

We are working on a critical project where the prototype is build using Jetson TX1.
The use case involves video playback at UHD (3840x2160) at 23.976 fps.
We are using the GStreamer pipeline that comes with the L4T 24.2.1 SDK.

In all the tests for UHD_23.976, we are seeing audio video sync issue.
To make sure the software side is proper we have time stamped video and audio at driver level and did not find any drifts there.

The final conclusion we have reached is that due to some hardware bug video is not rendered and presented on time to match vsync.

Please confirm that our deduction is correct and if there is any work-around for the issue.

-Raj

Hi Raj,
Is your case that there is possibly a one-video-frame delay in the beginning? If yes, we have similar discussion in the following topic:
https://devtalk.nvidia.com/default/topic/975667/jetson-tx1/maximum-av-sync-possible-with-gstreamer-1-8-0-in-l4t-24-2-at-23-976-fps/post/5029934/#5029934
We have clarified this case and think it is whtin tolerance in internal duscussion

But if you see video keep falling behind or audio keep falling behind, please share the steps to reproduce the issue on devkit.

Hi DaneLLL,

Yes, the issue is same as in the other post.

But in the case where issue is reproduced, this delay could not be correlated from time stamps of VSYNC in tegra_fb_ioctl() and of frame in tegra_dc_continuous_irq().

With this observation, we could rule out the rendering delay, right?
This is the reason we thought it could be an issue with the hardware.

Could you please give your opinion?

-Raj

Hi Raj,
We have conclusion aligned with
http://gstreamer-devel.966125.n4.nabble.com/Maximum-AV-sync-possible-with-gstreamer-1-8-0-in-L4T-24-2-at-23-976-FPS-td4680593.html#a4680668

And one-frame delay is within tolerance.

Hi DaneLLL,

We are observing this issue only with UHD@23.976

The offset between audio and video changes by one frame time for every 4-6 runs of the GStreamer application. e.g. if offset for first 4 runs is 10 ms, for the 5th run it could be around 50 ms and then for the 6th run it would be back to 10 ms. It is not fixed that it would be reproduced every time at every 4th run; it could vary - could be on the 4th or 5th or 6th run.

When we say “run”, it means launching the Gstreamer application, measuring the offset between audio and video using the meter from sync-one2.co.uk and exit the application. Next “run”, we launch the application again.

Kindly confirm if the scenario is clear and request you to please give pointers to solve this issue or give work arounds.

-Raj

Hi,
We don’t have the sync-one2 tool. Please other users can kindly share the free tool to check the av synchronization on linux. Thanks.

Hi DaneLLL,

We confirmed audio path has no issue by comparing the decoded audio data with the audio data captured using a frame grabber tool from http://www.unigraf.fi/products/video-test-hardware/ucd-323-hddp-dual

For video we added time stamps at two places: time stamps of Vsync in tegra_fb_ioctl() [in Tegra framebuffer driver] and of frame in tegra_dc_continuous_irq() [in display controller driver]
This could be one way to verify at your end.

You could also play UHD video at 23.976 fps and see if there is any jitter at the output using any suitable tool you may have.

-Raj

Hi Raj,
Does the method you shared have the same result as sync-one2? If sync-one2 reports 50 ms delay, we also can observe the same delay between first audio/video frame in the shared method?

Hi DaneLLL,

In fact the time stamping method we shared does not indicate this offset change.
The offset is observed only with the sync-one2 tool.
That is the reason we suspect HW bug in display controller.

-Raj

Hi DaneLLL,

We did another round of time stamping.
Here, frame was time stamped using FRAME_END and Vsync using VBLANK signals in DC_CMD_SIGNAL_RAISE register of Display Controller. There is no reading that indicates any shift/missing of a frame or a Vsync.

This strengthens the reasoning of the offset being introduced in the final hardware that outputs the HDMI data.

-Raj

This is a known issue and considered within tolerance.