Hi
On Sat, Nov 04, 2006 at 04:30:49PM +0200, Oded Shimon wrote:
> In my opinion it is all wrong.
> This loop deals with legality of file, not how the
demuxer reads the file.
>
> Current:
> > file:
> > file_id_string
> > while(!eof){
> > packet_header, main_header, packet_footer
> > reserved_headers
> > for(i=0; i<stream_count; i++){
> > packet_header, stream_header,
packet_footer
> > reserved_headers
> > }
> > while(next_code == info_startcode){
> > packet_header, info_packet,
packet_footer
> > reserved_headers
> > }
> > if(next_code == index_startcode){
> > packet_header, index_packet,
packet_footer
> > }
> > if (!eof) while(next_code !=
main_startcode){
> > if(next_code == syncpoint_startcode){
> > packet_header, syncpoint,
packet_footer
> > }
> > frame
> > reserved_headers
> > }
> > }
>
>
> The way it should be in my opinion:
> file:
> file_id_string
> while(!eof){
> packet_header, main_header, packet_footer
> for(i=0; i<stream_count; i++){
> packet_header, stream_header, packet_footer
> }
> reserved_headers
> while(next_code == info_startcode){
> packet_header, info_packet, packet_footer
> }
> reserved_headers
> if(next_code == index_startcode){
> packet_header, index_packet, packet_footer
> }
> if (!eof) while(next_code != main_startcode){
> packet_header, syncpoint, packet_footer
> do {
> frame
> } while (next_code == framecode)
> reserved_headers
> if (realtime_stream) {
> while(next_code == info_startcode){
> packet_header, info_packet,
packet_footer
> }
> reserved_headers
> }
> }
> }
>
>
> 1. no reserved headers allowed until end of stream
headers
> this offers absoloutely no disadvantage in
extendibility:
> a. new packets can still be written afterwards.
> b. if it is so important that it needs to be written
either next to the
> main header or next to the streams, it can be
written inside the main
> header or inside the stream headers (reserved_bytes)
no, there are cases where it makes sense
think about error correcting packets (with reed solomon
parity symbols for
example) yes its a silly example but its not entirly
unrealistic
and such error correcting packets pretty much must be after
the packet they
apply to as the info is needed for parsing of later packets
placing the stuff in the packet might cause some problems
with future
extendability ...
another similar example would be a signature to proof that a
header hasnt
been tampered with ...
also what is the problem with allowing such extra headers
there? just
disallowing something because we dont see an immedeate use
is not good
design
the same points apply to the other cases where you want
reserved_headers
removed
[...]
> 3. syncpoints must be written after any non frame
packets, before any
> frame packets.
i think that is required by other parts of the spec already
[...]
--
Michael GnuPG fingerprint:
9FF2128B147EF6730BADF133611EC787040B0FAB
In the past you could go to a library and read, borrow or
copy any book
Today you'd get arrested for mere telling someone where the
library is
_______________________________________________
NUT-devel mailing list
NUT-devel mplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/nut-devel
|