From 2d08f568e914f8429136630b7d14fc8432327530 Mon Sep 17 00:00:00 2001
From: NanoTech <nanotech@nanotechcorp.net>
Date: Fri, 9 Sep 2016 23:59:02 -0600
Subject: [PATCH] Fix off-by-one when looking for an I-frame NAL

Between finding the NAL and checking its type,
reassembleFrame is called and overwrites the
cachedSpecialDesc with the data and NAL type
from the previous NAL. If the only IDR NAL in the
packet is the last NAL in the packet, it gets
missed and the depacketizer is stuck waiting
for it.
---
 .../src/com/limelight/nvstream/av/video/VideoDepacketizer.java | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/moonlight-common/src/com/limelight/nvstream/av/video/VideoDepacketizer.java b/moonlight-common/src/com/limelight/nvstream/av/video/VideoDepacketizer.java
index 224d5484..dce813b7 100644
--- a/moonlight-common/src/com/limelight/nvstream/av/video/VideoDepacketizer.java
+++ b/moonlight-common/src/com/limelight/nvstream/av/video/VideoDepacketizer.java
@@ -274,6 +274,9 @@ public class VideoDepacketizer {
 						// Reassemble any pending NAL
 						reassembleFrame(packet.getFrameIndex());
 						
+						// Reload cachedSpecialDesc after reassembleFrame overwrote it
+						NAL.getSpecialSequenceDescriptor(location, cachedSpecialDesc);
+						
 						if (isReferencePictureNalu(cachedSpecialDesc.data[cachedSpecialDesc.offset+cachedSpecialDesc.length])) {
 							// This is the NALU code for I-frame data
 							waitingForIdrFrame = false;