Headless stream

[ritiek]

What platform does your feature request apply to? Linux (and maybe Windows)

Is your feature request related to a problem? Please describe. I want to stream only the audio from my PS4 to my headless Raspberry Pi using Chiaki. This will allow me to listen to real-time audio from my PS4 from the external speakers that are connected to my Raspberry Pi, which would be very cool!

Describe the solution you'd like I want to be able to run something like this on my Raspberry Pi which will write the audio data to STDOUT and other tools like ffplay or mpv would be able to play this audio stream.

$ chiaki-cli audiostream --host=192.168.1.2 --registkey=123abc12 --morning=abcdABCDabcdABCDabcdAB== | ffplay -

This feature would also allow users to redirect this audio output to a file which would allow them to record the audio from PS4.

Describe alternatives you've considered It is already possible to listen to the audio stream by running the Chiaki GUI but this requires an X server to be available and is unnecessarily more expensive on resources as the video stream from the PS4 is decoded and displayed too.

Additional context I've tried to implement something like this in this draft PR myself and I think I'm pretty close. To try out this draft PR:

The option to build the CLI needs to be ON in: https://github.com/thestr4ng3r/chiaki/blob/736b4835dfee77e34c09faa2623612691f7c1489/CMakeLists.txt#L13

Then compile and run:

$ chiaki-cli audiostream --host=192.168.1.2 --registkey=123abc12 --morning=abcdABCDabcdABCDabcdAB==

This should write what I believe is the OPUS encoded audio to stderr. It writes to stderr because currently all the chiaki log output is written to stdout, so the output would mix up if we were to write the audio data to stdout too (it would be a good idea to write logs to stdout which AFAIK is the convention, but that is a thing for a another day). However, when I pipe this audio output from stderr to ffplay or mpv with:

$ chiaki-cli audiostream --host=192.168.1.2 --registkey=123abc12 --morning=abcdABCDabcdABCDabcdAB== 2>&1 > /dev/null | ffplay -

The player fails to recognize it as a valid audio data and nothing can be heard. I'm stuck here and need help to know why the player doesn't recognize and play the audio data received.

Also, I'm a novice in C and low-level stuff so there is a good chance this draft PR can potentially segfault at places or allocate unnecessary memory.

[ritiek]

I got the video working on mpv with next to no lag with:

$ chiaki-cli stream --host=192.168.1.2 --registkey=123abc12 --morning=abcdABCDabcdABCDabcdAB== 2>&1 > /dev/null | mpv --no-cache --untimed --no-demuxer-thread --vd-lavc-threads=1 -

However, this still results in this warning from mpv (and in turn ffmpeg):

[lavf] This format is marked by FFmpeg as having no timestamps!
[lavf] FFmpeg will likely make up its own broken timestamps. For
[lavf] video streams you can correct this with:
[lavf]     --no-correct-pts --fps=VALUE
[lavf] with VALUE being the real framerate of the stream. You can
[lavf] expect seeking and buffering estimation to be generally
[lavf] broken as well.

I wonder if it is possible to write some kind of header information to pipe so these warnings do not show up?

[ritiek]

Sorry, I haven't been able to work on this. This stuff is still something on the woodoo side for me. If someone else wants to work on supporting headless mode, feel free to take stuff from this PR!

[thestr4ng3r]

I think I'll finish it when I have time. The timestamp warning is probably expected given the nature of the video data.