[garbear]

I'm working on better understanding VideoPlayer. Specifically, I'm wondering why PTS are out of order:

http://paste.ubuntu.com/23640002/

(excerpt: )

Code:

22:15:49.649 T:2348807136   DEBUG: Calling m_pVideoCodec->Decode() - iSize: 1151, dts: 0.000000, pts: 83416.666667
22:15:50.223 T:2348807136   DEBUG: Calling m_pVideoCodec->Decode() - iSize: 54, dts: 41708.333333, pts: 250250.000000
22:15:50.224 T:2348807136   DEBUG: Calling m_pVideoCodec->Decode() - iSize: 53, dts: 83416.666667, pts: 166833.333333
22:15:50.224 T:2348807136   DEBUG: Calling m_pVideoCodec->Decode() - iSize: 53, dts: 125125.000000, pts: 125125.000000
22:15:50.224 T:2348807136   DEBUG: Calling m_pVideoCodec->Decode() - iSize: 53, dts: 166833.333333, pts: 208541.666667
22:15:50.527 T:2348807136   DEBUG: CVideoPlayerVideo::CalcDropRequirement - hurry: 1
22:15:50.527 T:2348807136   DEBUG: Calling m_pVideoCodec->Decode() - iSize: 60, dts: 208541.666667, pts: 417083.333333
22:15:50.528 T:2348807136   DEBUG: Calling m_pVideoCodec->Decode() - iSize: 55, dts: 250250.000000, pts: 333666.666667
22:15:50.528 T:2348807136   DEBUG: Calling m_pVideoCodec->Decode() - iSize: 53, dts: 291958.333333, pts: 291958.333333
22:15:50.529 T:2348807136   DEBUG: Calling m_pVideoCodec->Decode() - iSize: 53, dts: 333666.666667, pts: 375375.000000
22:15:50.694 T:2348807136   DEBUG: CVideoPlayerVideo::CalcDropRequirement - hurry: 1
22:15:50.694 T:2348807136   DEBUG: Calling m_pVideoCodec->Decode() - iSize: 60, dts: 375375.000000, pts: 583916.666667
22:15:50.694 T:2348807136   DEBUG: Calling m_pVideoCodec->Decode() - iSize: 55, dts: 417083.333333, pts: 500500.000000
22:15:50.695 T:2348807136   DEBUG: Calling m_pVideoCodec->Decode() - iSize: 53, dts: 458791.666667, pts: 458791.666667
22:15:50.696 T:2348807136   DEBUG: Calling m_pVideoCodec->Decode() - iSize: 53, dts: 500500.000000, pts: 542208.333333
22:15:50.861 T:2348807136   DEBUG: CVideoPlayerVideo::CalcDropRequirement - hurry: 1

This causes packets to be dropped because they're detected as late.

With all the h.264 videos I've tried, pts fluctuates until every 4th frame, where it matches dts. Also, every 4 frames is the period of the "CVideoPlayerVideo::CalcDropRequirement - hurry: 1" message, which shows up about 15 times before going away.

If I have my decoder drop the pts, VideoPlayer will use the rendertime, no packets are dropped, and the video plays fine.

Is this normal behavior? Can someone clarify what's going on?

What does "hurry: 1" mean?

Is it always true that 1 demux packet sent to Decode() == 1 frame?

Thanks for the insights.

[FernetMenta]

Is this normal behavior? Can someone clarify what's going on?

I don't see anything wrong here. On h.264 streams frames may be not in output order before decoding. They get reordered by decoder.

What does "hurry: 1" mean?

Render buffers are about to run dry. Decoder is requested to output as quickly as possible

Is it always true that 1 demux packet sent to Decode() == 1 frame?

This API is outdated. I dropped the Decode method. retroplayer needs to adapt to this: https://github.com/FernetMenta/kodi-agile

[garbear]

That answers all my questions ATM. thanks!

Do you have an idea of when/how the agile dev is expected to make it to v18?

[FernetMenta]

Do you have an idea of when/how the agile dev is expected to make it to v18?

That depends on when devs like you submit required adaptions to the agile branch. Once all required changes are submitted I can create a PR for merging back changes to kodi master.

[da-anda]

FernetMenta, have you pinged the devs and notified them about the required changes? Garbear didn't seem to be aware, and probably others aren't as well.

[FernetMenta]

FernetMenta, have you pinged the devs and notified them about the required changes? Garbear didn't seem to be aware, and probably others aren't as well.

At least I informed popcornmix, koying, peak3d, garbear. Also aware at least fritsch, wisler, ace, alwin

[fritsch]

I already sent patches for ffmpegimage

[da-anda]

thanks