[
http://dev.sourcefabric.org/browse/LS-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17227#action_17227
]
David Baelde commented on LS-549:
---------------------------------
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.
> Investigate shitty POSIX semantics for end of stream..
> ------------------------------------------------------
>
> Key: LS-549
> URL: http://dev.sourcefabric.org/browse/LS-549
> Project: Liquidsoap
> Issue Type: Task
> Reporter: Romain Beauxis
> Priority: Critical
> Fix For: 1.0
>
>
> 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. In LS-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 for LS-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...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://dev.sourcefabric.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
_______________________________________________
Savonet-devl mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/savonet-devl
