fduncanh

see http://github.com/FDH2/UxPlay

@robobenklein rpiplay and uxplay in fact use the _raop._tcp (iTunes) service rather than the _airplay._tcp service for airplay, though they advertise both. default choices make the _airplay._tcp port p+1 if...

This shows wireshark listening to a samsung tv server with sourceVersion 377.17.24 (still below the 380 mentioned by FD). But the fpsetup dialog is shown is with server sourceVersion 220.68....

I have been trying to get [UxPlay](https://github.com/FDH2/UxPlay) to work on Raspberry Pi 4B 8GB (Raspberry Pi OS 64bit, Bullseye) with v4l2h264dec for GPU h264 decoding. Yesterday It finally worked great,...

Looking at your buffer len output I see that all frames are 6 bytes bigger than the sum of their NALs in the test video bitstream, but I see in...

As noted in the bug report, there are two distinct issues: the (1) why the the first few frames after the initial frame with SPS never get dequeued by VIDIOC_DQBUF,...

> So they have been decoded already (presumably the output buffer was of an appropriate size), but because it's doing a flush in stop_streaming, they're being discarded. I thought I'd...

@6by9 I tested with 3 more examples. For error 2. In each case the **first** CMD_STOP draining works perfectly. If the last pending frame is e.g. 209, the last VIDIOC_DQBUF...

@6by9 re: problem 1 (which does not involve CMD_STOP): (Edited) so if I understand it, the issue is the extra colourspace info which makes the decoder want to drop the...

@6by9 (Edited) For error 2 (incomplete draining after the second and all subsequent CMD_STOPs) I've looked at the debug=5 output from bcm2835-codec and can't see any reason why EOS is...