Description
MTL maint-25.02.1
It appears that the notify_frame_done callback is erroneously called twice when using st20p in external frame mode.
In this workflow, we are providing V210 frames in external frame mode. It looks like the notify_frame_done gets called after conversion (st20_pipeline_tx.c line 751) and then again, possibly in the tx_st20p_frame_done() method (line 134), although I didn't really follow the code.
To confirm the theory, I put nothing but logging (no free) in our callback function as follows:
std::wcerr << L"IN Intel2110VideoTx_2 tx_video_frame_done rtp-ts: "
<<frame->rtp_timestamp
<<L" opaque: "<<frame->opaque
<<L" status: "<<frame->status
<<L" secondField: "<<frame->second_field
<<L"\n";
And the output looks like this:
IN Intel2110VideoTx_2 tx_video_frame_done rtp-ts: 0 opaque: 0x5612e0cc9740 status: 0 secondField: 0
IN Intel2110VideoTx_2 tx_video_frame_done rtp-ts: 0 opaque: 0x5612e0cc9c20 status: 0 secondField: 1
IN Intel2110VideoTx_2 tx_video_frame_done rtp-ts: 0 opaque: 0x5612e0cc9c80 status: 0 secondField: 0
IN Intel2110VideoTx_2 tx_video_frame_done rtp-ts: 0 opaque: 0x5612bdf45980 status: 0 secondField: 1
IN Intel2110VideoTx_2 tx_video_frame_done rtp-ts: 0 opaque: 0x5612bdf45920 status: 0 secondField: 0
IN Intel2110VideoTx_2 tx_video_frame_done rtp-ts: 0 opaque: 0x5612de718c60 status: 0 secondField: 1
IN Intel2110VideoTx_2 tx_video_frame_done rtp-ts: 0 opaque: 0x5612c3d377a0 status: 0 secondField: 0
IN Intel2110VideoTx_2 tx_video_frame_done rtp-ts: 0 opaque: 0x5612bf490e40 status: 0 secondField: 1
IN Intel2110VideoTx_2 tx_video_frame_done rtp-ts: 792757688 opaque: 0x5612e0cc9740 status: 0 secondField: 0
IN Intel2110VideoTx_2 tx_video_frame_done rtp-ts: 792757688 opaque: 0x5612bf490d80 status: 0 secondField: 0
IN Intel2110VideoTx_2 tx_video_frame_done rtp-ts: 792759190 opaque: 0x5612e0cc9c20 status: 0 secondField: 1
IN Intel2110VideoTx_2 tx_video_frame_done rtp-ts: 792759190 opaque: 0x5612bdf45740 status: 0 secondField: 1
IN Intel2110VideoTx_2 tx_video_frame_done rtp-ts: 792760691 opaque: 0x5612e0cc9c80 status: 0 secondField: 0
IN Intel2110VideoTx_2 tx_video_frame_done rtp-ts: 792760691 opaque: 0x5612d6356cc0 status: 0 secondField: 0
IN Intel2110VideoTx_2 tx_video_frame_done rtp-ts: 792762193 opaque: 0x5612bdf45980 status: 0 secondField: 1
IN Intel2110VideoTx_2 tx_video_frame_done rtp-ts: 792762193 opaque: 0x5612d6357440 status: 0 secondField: 1
You can see 8 callbacks initially as the configured 8 MTL buffers fill up, then you can see duplicate callbacks (same opaque pointer - eg. 0x5612e0cc9740, 0x5612e0cc9c20, etc.)
Note - we are using the ST20P_TX_FLAG_USER_TIMESTAMP and ST20P_TX_FLAG_USER_PACING flags (1080i 29.97).
My colleague had to temporarily comment out the callback in st20p_tx_put_ext_frame() in order to prevent a crash (double free) of our buffers.
However, this doesn't feel like the correct solution. I imagine that code was there for a reason.
Perhaps the internal MTL data structure should have a boolean indicating that the done-frame callback has been performed, and not do it a second time.
Please advise if our analysis is correct.
Thanks.