[gst-devel] MP4: Endless stream impossible?

Andres Gonzalez acandido at hi-iberia.es
Fri Aug 27 11:03:26 CEST 2010


  On 27/08/10 10:21, beast wrote:
> Hi,
>
> I have the general question about MP4 and streaming. Given are two raw data
> streams (h264 and aac) for input, which should be muxed into a streamable
> format. The input streams are potentially endless; those are real streams
> and not files. The scenario is similar to streaming from a web cam. The
> (muxed) output stream should be available as soon as some raw input data is
> available.
>
> To my current understanding, this cannot be done using MP4. For the given
> receiver, it is necessary to have the moov box before the mdat box. However
> the moov box must contain index information for the entire stream. This
> information is not available when streaming is started. Is this correct?
> Some confirmation would be highly appreciated, I am no expert in this field.
> Are there any workarounds?
Hi,
I am working in a similar problem. As far as I know, all players and 
processors require the moov atom being present to work with a MP4 file.
I don't have a deep understanding of MP4 format, but I think this index 
information is generated as the video is being produced, but written all 
together at the end. As I said, players require the information being 
present explicitly to play a MP4. What I am not sure is if this index 
information could be deduced from raw data by some "intelligent" processing.

This is not an easy task. I have been working on it for a while, but 
achieved no results, yet. If you want to do something like this, maybe 
you want to look at this project, from a person who tried to rebuild 
index information in a tuncated video:

http://vcg.isti.cnr.it/~ponchio/life/code/untrunk_readme.html

Regards,
Andrés

> For the given receiver, 3GP would be an alternative container format. But
> since it's also an ISO format similar to MP4 it has probable the same issue,
> right? I haven't looked at the details yet, so if someone would tell be the
> opposite, I would be very pleased.
>
> Thanks,
> beast







More information about the gstreamer-devel mailing list