Hi,
I happen to have been looking into this issue too. The 3gp and mpeg4 formats
are based on the Quicktime mov format. This format works by having several
sections in the file with tags, with each tag needing to specify the size of
the tag at the start. One of these tags is the size of all the data in the
file, which is not known in advance of encoding (only a worst guess can be made
based on the bitrate and bitrate tolerance). Unlike ASF format, for example,
these formats must have the size element specified, or else they won't work.
So libavformat must first write the data to a file, and then go back and fill
in the size of the elements, which it obviously can't do with an http stream
(since the data will be at the client by the time it needs to go back and fill
it in).
The best solution to this just now is to pre-convert any videos into 3gp format
and then stream them directly. A future solution (which I am looking at a bit)
is to take the worst guess of the data size and then fill in any space not used
with some sort of padding. This will result in files that are always a bit too
big, but will at least allow the streaming of the data.
In the long long run, someone should come up with a better file format for
streaming that can be indexed that doesn't need to know the size of the data in
advance (flv could actually be quite good at this as it is searchable from the
end as well as the start, meaning that you could add a key-frame index to the
end of the file after streaming it - unfortunately, most standard media players
can't play flv and others wouldn't know to look at the end of the file for the
index).
Andrew :)
Have you tried running the qt-faststart program that comes in the tools
directory of ffmpeg? It (I think) rearranges mp4/3gp files so that they
can be streamed more easily.
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
