MP4: Endless stream impossible?

[beast]

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?

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

[Andrés González]

  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




------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Wim Taymans]

On Fri, 2010-08-27 at 11:03 +0200, Andres Gonzalez wrote:
> 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.

Did you check this?

https://bugzilla.gnome.org/show_bug.cgi?id=596321

Wim

> >
> > 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
>
>
>
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel