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.
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.
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.
We confirmed audio path has no issue by comparing the decoded audio data with the audio data captured using a frame grabber tool from Products – Unigraf
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.
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?
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.
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.