Sigh... I think you might not be familiar with the HTTP Live Streaming server
implementation that we *already* have (and have had for almost 6 months now).
See:
http://www.live555.com/mediaServer/#http-live-streaming
Our server can *already* stream a H.264-encoded Transport Stream file via HTTP
Live Streaming. We explicitly *do not* segment the file in any way. Instead,
we create (automatically, in our server) a playlist to serve to clients. Each
entry in the playlist refers (using time-based parameters in the URL) to a
specific region of the file, but we do not actually segment the file. Instead,
our server delivers the appropriate portion of the file automatically. Our
only requirement is that the file be indexed (using our normal 'trick mode'
indexing mechanism) beforehand.
And this works just fine - e.g., with a file made up from Apple's "bipbopgear1"
Transport Stream example.
However, it *did not* work with a Transport File that I created - using our
"testH264VideoToTransportStream" demo application - from the "CaptureH264.es"
file that you provided - ***even after*** I modified our
"MPEG2TransportStreamMultiplexor" and "MPEG2TransportStreamFromESSource"
implementations to exactly match what you did in your code.
So, as I said before, until I know for sure what changes, if any, are necessary
to the "MPEG2TransportStreamMultiplexor" and "MPEG2TransportStreamFromESSource"
code in order for HTTP Live Streaming to work, I'm going to hold off - at least
for now - on making any changes to this code.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
