Steinar Bjaerum wrote:
Unfortunately, not. The implementation of FFWD/REW expects to be able to seek on the handle to the audio source. For a local file this is possible, of course. When we're transcoding, we open a pipe (or in certain cases, a socket) to the transcoding application and it's not possible to seek on a pipe/socket. In the long term, we can investigate other options that allow us to seek in more cases, such as:Steinar Bjaerum wrote:
...
Is the FFWD/REW done by skipping to flac frame boundaries in the server before streaming to the client?
Yes, we do some rudimentary parsing on the server to find frame boundaries. This involves looking for a frame header sync mark and then confirming that the header CRC is correct. The existence of the CRC actually gives us a good confidence level that we're sending valid frames to the decoder on the box.
The same technique is used for FFWD/REW for MP3, but MP3 frame headers don't contain a CRC value (at least not for the header itself), so you can sometimes hear squeaks and pops while scanning through MP3 tracks. Luckily the MP3 decoder on the box is very robust. :-)
--Vidur
My follow-up question is then:
Is it feasible to get FFWD/REW for audio being transcoded to Flac on the
server.
1) Use a Perl package such as Audio::FLAC::Decoder to do the transcoding and not require a pipe. In fact, if we used this package, we could probably avoid doing FLAC->FLAC transcoding for cusheets and just do a time-based seek directly. This option might not make sense for other types of transcoding since we may still need to open a pipe to other transcoding applications.
2) Do server-side audio processing to speed up the stream. This would be done after the transcoding process and we wouldn't need to seek.
--Vidur
_______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
