List Info

Thread: libnut muxer: write at least one timebase




libnut muxer: write at least one timebase
user name
2007-01-22 07:24:07
This patch adds code to make sure that there is at least one
timebase.
Otherwise, creating a file without any stream would result
in an
invalid file, or the muxer would crash when trying to write
max_pts
in the index.
  
Re: libnut muxer: write at least one timebase
user name
2007-02-02 03:10:32
On Mon, Jan 22, 2007 at 02:24:07PM +0100, Clemens Ladisch
wrote:
> This patch adds code to make sure that there is at
least one timebase.
> Otherwise, creating a file without any stream would
result in an
> invalid file, or the muxer would crash when trying to
write max_pts
> in the index.

Is a file without any streams valid?..

- ods15
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

Re: libnut muxer: write at least one timebase
user name
2007-02-02 04:38:32
Hi

On Fri, Feb 02, 2007 at 11:10:32AM +0200, Oded Shimon
wrote:
> On Mon, Jan 22, 2007 at 02:24:07PM +0100, Clemens
Ladisch wrote:
> > This patch adds code to make sure that there is at
least one timebase.
> > Otherwise, creating a file without any stream
would result in an
> > invalid file, or the muxer would crash when trying
to write max_pts
> > in the index.
> 
> Is a file without any streams valid?..

hmm, i think we havent thought about that ...
at least such a file cannot contain any frames, stream
headers or syncpoints
and without timebases it cannot contain an (useless) index
and info packets

now the timebase less case really is useless because the
only thing which
you could store in the file would be the main header and
possibly future
new headers ...

in the streamless but not timebase less case you could store
an index which
would contain nothing and info packets iam not sure if
theres any use for
that? seperating info packets from actual streams like
providing just a
info packet file for some other file, like providing
detailed info for
a dvd, so someone could take th dvd remux it to nut and add
the info somehow
?

[...]
-- 
Michael     GnuPG fingerprint:
9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there
is freedom there
will be no State. -- Vladimir Lenin

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel
Re: libnut muxer: write at least one timebase
user name
2007-02-02 07:40:52
On Fri, Feb 02, 2007 at 11:38:32AM +0100, Michael
Niedermayer wrote:
> Hi
> 
> On Fri, Feb 02, 2007 at 11:10:32AM +0200, Oded Shimon
wrote:
> > On Mon, Jan 22, 2007 at 02:24:07PM +0100, Clemens
Ladisch wrote:
> > > This patch adds code to make sure that there
is at least one timebase.
> > > Otherwise, creating a file without any stream
would result in an
> > > invalid file, or the muxer would crash when
trying to write max_pts
> > > in the index.
> > 
> > Is a file without any streams valid?..
> 
> hmm, i think we havent thought about that ...
> at least such a file cannot contain any frames, stream
headers or syncpoints
> and without timebases it cannot contain an (useless)
index and info packets
> 
> now the timebase less case really is useless because
the only thing which
> you could store in the file would be the main header
and possibly future
> new headers ...
> 
> in the streamless but not timebase less case you could
store an index which
> would contain nothing and info packets iam not sure if
theres any use for
> that? seperating info packets from actual streams like
providing just a
> info packet file for some other file, like providing
detailed info for
> a dvd, so someone could take th dvd remux it to nut and
add the info somehow
> ?

I have no strong feeling on this. I would not be against a
'stream_count 
MUST be >0' ...

- ods15
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

Re: libnut muxer: write at least one timebase
user name
2007-02-05 03:32:02
> On Fri, Feb 02, 2007 at 11:38:32AM +0100, Michael
Niedermayer wrote:
> > On Fri, Feb 02, 2007 at 11:10:32AM +0200, Oded
Shimon wrote:
> > > On Mon, Jan 22, 2007 at 02:24:07PM +0100,
Clemens Ladisch wrote:
> > > > This patch adds code to make sure that
there is at least one timebase.
> > > > Otherwise, creating a file without any
stream would result in an
> > > > invalid file, or the muxer would crash
when trying to write max_pts
> > > > in the index.
> > > 
> > > Is a file without any streams valid?..
> > 
> > hmm, i think we havent thought about that ...
> > at least such a file cannot contain any frames,
stream headers or syncpoints
> > and without timebases it cannot contain an
(useless) index and info packets
> > 
> > now the timebase less case really is useless
because the only thing which
> > you could store in the file would be the main
header and possibly future
> > new headers ...

The spec explicitly forbids having no timebases.

> > in the streamless but not timebase less case you
could store an index which
> > would contain nothing and info packets iam not
sure if theres any use for
> > that? seperating info packets from actual streams
like providing just a
> > info packet file for some other file, like
providing detailed info for
> > a dvd, so someone could take th dvd remux it to
nut and add the info somehow
> > ?

In a video editor application, it would make sense to be
able to save a
file with some global metadata even when the user hasn't yet
created any
streams.  If streamless files were not allowed, the program
would have
to create a dummy stream, or say "I'm sorry Dave, I'm
afraid I cannot do
that".

Oded Shimon wrote:
> I have no strong feeling on this. I would not be
against a 'stream_count 
> MUST be >0' ...

This change to the spec would not be backwards compatible
...  

In practice, it wouldn't make much of a difference if the
error message
of a media player would be either "I cannot play a file
without any
data" or "A file without data is not a valid nut
file".


Regards,
Clemens
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

[1-5]

about | contact  Other archives ( Real Estate discussion Medical topics )