Why is FLAC Streaming over HTTP done with Ogg encapsulation instead of natively?

Question

All of the current FLAC streaming implementations (such as Edcast with Icecast) seem to use Ogg as a container for FLAC while streaming.

1. What is the reason for this?
2. What are the drawbacks of not using Ogg, and streaming the "native" FLAC stream instead?

I've done some tests streaming FLAC over HTTP, and it seems to work just fine in VLC. FLAC seems to be built in such a way that frames can stand independently, making it robust against stream corruption and/or dropped frames. Given this, I don't quite understand why wrapping FLAC in Ogg is necessary.

Answer 1

The FLAC-to-Ogg mapping page has a fairly thorough explanation of why it's desirable to use Ogg encapsulation in many cases instead of streaming native FLAC:

The original FLAC format includes a very thin transport system ... known as 'native FLAC'. ... It is very lightweight and does not support more elaborate transport mechanisms such as multiple logical streams, ...

The native FLAC transport is not a transport "layer" in the way of standard codec design because it cannot be entirely separated from the payload. ...

This presents a problem when trying to encapsulate FLAC in other true transport layers ...

The alternative is to treat native FLAC frames as Ogg packets and accept the transport redundancy. It turns out that this is not much of a penalty; ... The redundancy amounts to a fraction of a percent.

[emphasis added]

See the complete page for more information, but the upshot is that while usable for streaming, native FLAC isn't well-suited to more complex setups and the cost of Ogg encapsulation is quite low. If native FLAC works fine for your specific needs, you can go ahead and use it, but Ogg will ultimately give you more flexibility.