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.

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
     }
 }

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
     }
 }