video, audio: don't actively wait for demuxer input

If feed_packet() ended with DATA_WAIT, the player should have gone to
sleep, until the demuxer wakes it up again when there is new data. But
the call to read_frame() unconditionally overwrote this status code, so
it never waited. The consequence was that the core burned CPU by
effectively polling the demuxer status, which was noticeable especially
when seeking in network streams (since seeking is async, decoders will
start out with having to wait for network).

Regression since commit 33e5755c.

2 files changed, 4 insertions, 0 deletions

diff --git a/audio/decode/dec_audio.c b/audio/decode/dec_audio.c
index cd83cfd55e..111f981690 100644
--- a/audio/decode/dec_audio.c
+++ b/audio/decode/dec_audio.c
@@ -284,6 +284,8 @@ void audio_work(struct dec_audio *da)
     read_frame(da);
     if (!da->current_frame) {
         feed_packet(da);
+        if (da->current_state == DATA_WAIT)
+            return;
         read_frame(da); // retry, to avoid redundant iterations
     }
 }
diff --git a/video/decode/dec_video.c b/video/decode/dec_video.c
index 243c38a0a8..6eaed8a85a 100644
--- a/video/decode/dec_video.c
+++ b/video/decode/dec_video.c
@@ -504,6 +504,8 @@ void video_work(struct dec_video *d_video)
     read_frame(d_video);
     if (!d_video->current_mpi) {
         feed_packet(d_video);
+        if (d_video->current_state == DATA_WAIT)
+            return;
         read_frame(d_video); // retry, to avoid redundant iterations
     }
 }