Details
-
Type:
Task
-
Status:
Open
-
Priority:
Minor
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: 1.0.0+dev
-
Component/s: None
-
Labels:None
Description
As you may know, the POSIX semantics for sockets/streams is really (really) shitty.
One of its infamous case is the semantics for end of streams: no error code may be returned when a stream has ended. The "correct" way to detect an EOS on a socket is to check whether a read returned 0...
Our decoding infrastructure, on the other hand, relies heavily on exceptions, in particular for detecting end of streams. InLS-548, because the AAC decoder has a read buffer, we did not see the end of track: last Unix.read was returning 0 and we simply returned inifitely many time the last string in the buffer..
Although this is fixed forLS-548, I am filling this task in order to have a look at the code later. At every place where there is a Unix.read, we should think of what happends if this read returns 0 char. On a more general level, we may want to implement our own Utils.read and place there an exception raised when the read returned 0...
One of its infamous case is the semantics for end of streams: no error code may be returned when a stream has ended. The "correct" way to detect an EOS on a socket is to check whether a read returned 0...
Our decoding infrastructure, on the other hand, relies heavily on exceptions, in particular for detecting end of streams. In
Although this is fixed for
Activity
Hide
David Baelde
added a comment -
Permalink
The semantics of the read function in Decoder is the same: it returns a string together with its length, and ("",0) means end of stream. I don't remember this as a strong design choice on my part, but it may very well be more or less forced by the libs we use. For example, the Lame decoder expects a function with this specification, and properly treats 0 as end of stream, raising the appropriate exception. The problem with AAC+ is that the decoder doesn't take a read function but must be fed buffers of data, so read were done in the liquidsoap decoding module, not properly following the spec of read functions. You're right that it'd be good to check that all code looks more like the MP3 decoder than the AAC+ one.
Show
David Baelde
added a comment - The semantics of the read function in Decoder is the same: it returns a string together with its length, and ("",0) means end of stream. I don't remember this as a strong design choice on my part, but it may very well be more or less forced by the libs we use. For example, the Lame decoder expects a function with this specification, and properly treats 0 as end of stream, raising the appropriate exception. The problem with AAC+ is that the decoder doesn't take a read function but must be fed buffers of data, so read were done in the liquidsoap decoding module, not properly following the spec of read functions. You're right that it'd be good to check that all code looks more like the MP3 decoder than the AAC+ one.