Default type assignment makes mono HTTP input impossible

David Baelde added a comment - 04/Dec/11 5:41 PM Not really a bug: in fact, input.http() is declared as returning a source with a fixed content type. When we use this in audio_to_stereo, we end up with the HTTP source having type source(?#A+1,0,0), ie. fixed with at least one channel, and the unknown is removed by taking the default, ie. 2 channels. What I was expecting is an HTTP source with a variable type, which would have allowed mono and stereo. Now I need to figure out if we can declare it as variable, or if this is tied to a technical restriction.

David Baelde added a comment - 04/Dec/11 5:50 PM Changing Lang.audio_video_any into (Lang.Unconstrained (Lang.univ_t 1)) in src/sources/http_source.ml seems to work fine, and I didn't find any trace of a deliberate restriction on that parameter. I'll investigate a bit more later, and also enhance error (and content-type) reporting, before finalizing all this.

David Baelde added a comment - 13/Jun/12 3:36 PM A few notes: first, the fix should be applied to input.harbor() as well, which should in any case have the same type as input.http() -- this is not currently the case. I ran a few tests. Sending a stream to harbor that isn't compatible with the declared type results in a runtime error that is cleanly handled. The thing to pay attention to is: do the generators used for those inputs really support mixed content type?

Romain Beauxis added a comment - 15/Jun/12 2:08 PM Fixed and tested for harbor. Variable audio channels now works like a charm.. I think we should document these tricks and then close this issue..

David Baelde added a comment - 20/Jun/12 12:06 PM I'm confused by your comment, Romain. The only change I see so far is switching harbor to audio_video_any, which is a fixed content kind. So any variable audio test _shouldn't_ work! Also, to address my worry about generators being unsuitable for variable content kinds, there's no problem: the set_mode API is there to handle this cleanly. The only constraint is that a decoder doesn't change its content type without notifying the generator, but that's not new. In most cases, each new connection triggers the creation of a new decoder, which figures its content type and informs the generator about it. I'll fix the issue for real tonight.

David Baelde added a comment - 21/Jun/12 8:03 PM My confusion is now resolved -- it was caused by a tricky effect of the type annotation system. The issue has been clarified by giving sources a fully general type, and everything works fine.