你好,我注意到了你们关于#2613问题的修改 (Question regarding #2613)

[zhangyuankai]

你们的回答是这样的:
怀疑问题出在包含分片单元的RTP数据包丢失上。根据RTSP的H264和H265 RFC规范，"如果分片单元丢失，接收方应丢弃所有后续对应于同一NAL单元的分片单元”。ExoPlaver目前并未执行此操作，因此可能会写入不完整的NAL单元.

我的疑问是,如果出问题的这一个NAL单元有问题,下一个NAL单元应该是可以正常解码并播放的吧,那么问什么有问题的这个NAL单元会导致SampleDataQueue这个地方一直在增长,最终导致堆内存溢出呢,
感谢解答

Auto-translated in English:

Your response was as follows:
The problem is suspected to be the loss of RTP packets containing fragmented units. According to the RTSP H.264 and H.265 RFC specifications, "If a fragmented unit is lost, the receiver should discard all subsequent fragmented units corresponding to the same NAL unit." ExoPlaver does not currently perform this operation, and therefore may be writing incomplete NAL units.

My question is, if the problematic NAL unit has a problem, shouldn't the next NAL unit be able to decode and play normally? So why does the problematic NAL unit cause the SampleDataQueue to keep growing, eventually leading to a heap memory overflow?
Thank you for your answer.

[tonihei]

(Updated issue with auto-translated text in English)

[tonihei]

@microkatz Assigning to you as a follow-up to the other issue in #2613

[microkatz]

@zhangyuankai

Thank you for creating a new ticket to continue the issue first brought up in #2613.

As written in the old ticket, with this commit, 8f0b9ac, ExoPlayer should correctly start decoding from the next NAL unit.

Just to clarify, can you confirm that the linked fix did resolve the original issue of the missing fragmentation unit and the stream now plays as expected?

As far as the heap memory issue, would you be able to provide a bug report from the demo application with reproducing this issue?

[zhangyuankai]

感谢回答,我的版本是1.8.0,并且也按照新的提交合并了代码,测试后发现当我的RTP序列号有不连贯的情况时,视频会卡死掉,我尝试修复了卡死问题,测试后还是会有堆内存的问题

Edit: Thanks for your reply. My version is 1.8.0, and I've merged the code according to the new commits. After testing, I found that the video freezes when my RTP sequence number is discontinuous. I tried to fix the freezing issue, but the heap memory problem persists after testing.

[microkatz]

@zhangyuankai

How the Readers work is that they will write bytes to the SampleQueue via sampleData and then as soon as a full sample is finalized, the Reader will call sampleMetadata providing the size of the full, correct sample. If your stream is continually providing discontinuous RTP sequence numbers that cause invalid, non-full samples, then the allocations will continue to grow.

Since you are already debugging and able to reproduce the scenario, could you add trace logs to processFragmentationUnitPacket? I want to know how often your stream is sending discontinuous RTP sequence numbers. Is it a single mistake followed by a long stream of correct packets? Or after the first mistake, is there never again a packet that can be parsed? It would be great to have a list of sequence numbers starting at the mistake, printing the expected vs the actual, and then the packet numbers after that. Make sure to print out if a isLastFuPacket is found.

We might be able to fix the heap memory issue but if your stream is never fixing itself after the first discontinuous RTP sequence number then your scenario still won't work. This is why I'm asking for this additional trace information.

Thanks for your support!