CVS: main/DOCS/tech mpcf.txt,1.7,1.8
Update of /cvsroot/mplayer/main/DOCS/tech In directory mail:/var/tmp.root/cvs-serv28065 Modified Files: mpcf.txt Log Message: zero_bit for normal frames, so we can distinguish them from other packets Index: mpcf.txt =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/tech/mpcf.txt,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- mpcf.txt 7 Feb 2003 09:48:06 -0000 1.7 +++ mpcf.txt 7 Feb 2003 11:20:35 -0000 1.8 @@ -123,12 +123,13 @@ if(keyframe){ keyframe_startcode f(64) } - lsb_timestamp v - stream_id v + zero_bit f(1) priority u(2) checksum_flag u(1) msb_timestamp_flag u(1) - reserved u(4) + reserved u(3) + lsb_timestamp v + stream_id v if(msb_timestamp_flag) msb_timestamp v bitstream @@ -256,6 +257,11 @@ depth for compatibility with some win32 codecs +zero_bit + MUST be 0, its there to distinguish non keyframes from other packets, + Note: all packets have a 64-bit startcode except non-keyframes to reduce + their size, and all startcodes start with a 1 bit + priority if 0 then the frame isnt used as reference (b frame) and can be droped MUST be > 0 for keyframes @@ -325,6 +331,7 @@ Index the index can be repeated but there MUST be at least one at the end +Note: in case of realtime streaming there is no end, so no index there either Info packets the info_packet can be repeated, it can also contain different names & values
On Fri, Feb 07, 2003 at 12:20:55PM +0100, Michael Niedermayer CVS wrote:
Log Message: zero_bit for normal frames, so we can distinguish them from other packets
[...]
+zero_bit + MUST be 0, its there to distinguish non keyframes from other packets, + Note: all packets have a 64-bit startcode except non-keyframes to reduce + their size, and all startcodes start with a 1 bit +
What about VLFH (variable length frame headers ;-))? I think often there will be a long stream of frames with nearly the same header, where for example just the lsb_timestamp changes. So you can use a mask (something like 00010) to distinguish that a particular frame header consists of nothing more than the lsb_timestamp.
On Fri, Feb 07, 2003 at 12:20:55PM +0100, Michael Niedermayer CVS wrote:
Log Message: zero_bit for normal frames, so we can distinguish them from other packets
[...]
+zero_bit + MUST be 0, its there to distinguish non keyframes from other packets, + Note: all packets have a 64-bit startcode except non-keyframes to reduce + their size, and all startcodes start with a 1 bit +
What about VLFH (variable length frame headers ;-))? I think often there will be a long stream of frames with nearly the same header, where for example just the lsb_timestamp changes. So you can use a mask (something like 00010) to distinguish that a particular frame header consists of nothing more than the lsb_timestamp. yes, but there isnt that much in the frame header, its just
Hi On Friday 07 February 2003 12:39, Andreas Hess wrote: the pointers to the next/prev frames 8bit flags (the zero bit is here too) stream id (normally 1byte) lsb_timestamp (normally 1byte) the msb_timestamp & checksum are only coded for some frames so they dont count ... so only the stream id could be skiped, that could easily be done by a stream_id_flag in the flags byte, if noone disagrees then ill add that but the gain isnt as big as it seems as the streams are inteleaved ... [...] Michael
On Fri, Feb 07, 2003 at 01:35:23PM +0100, Michael Niedermayer wrote:
What about VLFH (variable length frame headers ;-))? I think often there will be a long stream of frames with nearly the same header, where for example just the lsb_timestamp changes. So you can use a mask (something like 00010) to distinguish that a particular frame header consists of nothing more than the lsb_timestamp. yes, but there isnt that much in the frame header, its just
On Friday 07 February 2003 12:39, Andreas Hess wrote: the pointers to the next/prev frames 8bit flags (the zero bit is here too) stream id (normally 1byte) lsb_timestamp (normally 1byte) the msb_timestamp & checksum are only coded for some frames so they dont count
Ok, but after reading your spec about MPCF the definition of and the difference between checksum and frame_checksum isn't clear. You say that frame_checksum depends on checksum_flag, but in the definition of frame you use checksum, when checksum_flag is set. And what about no checksum at all in plain frames, allowing the checksum (or frame_checksum) just in keyframes, and there the checksum is the checksum (or frame_checksum) over all previous frames.
Hi On Friday 07 February 2003 13:57, Andreas Hess wrote:
On Fri, Feb 07, 2003 at 01:35:23PM +0100, Michael Niedermayer wrote:
On Friday 07 February 2003 12:39, Andreas Hess wrote:
What about VLFH (variable length frame headers ;-))? I think often there will be a long stream of frames with nearly the same header, where for example just the lsb_timestamp changes. So you can use a mask (something like 00010) to distinguish that a particular frame header consists of nothing more than the lsb_timestamp.
yes, but there isnt that much in the frame header, its just the pointers to the next/prev frames 8bit flags (the zero bit is here too) stream id (normally 1byte) lsb_timestamp (normally 1byte) the msb_timestamp & checksum are only coded for some frames so they dont count
Ok, but after reading your spec about MPCF the definition of and the difference between checksum and frame_checksum isn't clear. You say that frame_checksum depends on checksum_flag, but in the definition of frame you use checksum, when checksum_flag is set. typo, fixed ...
And what about no checksum at all in plain frames, allowing the checksum (or frame_checksum) just in keyframes, and there the checksum is the checksum (or frame_checksum) over all previous frames.
hmm if only the keyframes contain the checksum, then each keyframe would contain the checksum for the previous frames ... the last frames after the last keyframe would have no checksum and if we cut the stream at a keyaframe than its checksum would cover frames which are no longer there, this seems bad, so IMHO the current way of requireing the checksum to be in the last frame before a keyframe (or more often) is better [...] Michael
On Fri, Feb 07, 2003 at 02:44:27PM +0100, Michael Niedermayer wrote:
And what about no checksum at all in plain frames, allowing the checksum (or frame_checksum) just in keyframes, and there the checksum is the checksum (or frame_checksum) over all previous frames. hmm if only the keyframes contain the checksum, then each keyframe would contain the checksum for the previous frames ...
On Friday 07 February 2003 13:57, Andreas Hess wrote: the last frames after the last keyframe would have no checksum and if we cut the stream at a keyaframe than its checksum would cover frames which are no longer there, this seems bad, so IMHO the current way of requireing the checksum to be in the last frame before a keyframe (or more often) is better
Ok, I see, but what about making the checksum forward calculated? And the checksum, over what part is it calculated, over the header, the payload or over the whole frame? Maybe it would just be enough to calculate the checksum over the headers to guarantee, that the structure of the file itself is ok, and leave the correctness of the payload to the respective codecs. Andreas
On Fri, Feb 07, 2003 at 02:44:27PM +0100, Michael Niedermayer wrote:
On Friday 07 February 2003 13:57, Andreas Hess wrote:
And what about no checksum at all in plain frames, allowing the checksum (or frame_checksum) just in keyframes, and there the checksum is the checksum (or frame_checksum) over all previous frames.
hmm if only the keyframes contain the checksum, then each keyframe would contain the checksum for the previous frames ... the last frames after the last keyframe would have no checksum and if we cut the stream at a keyaframe than its checksum would cover frames which are no longer there, this seems bad, so IMHO the current way of requireing the checksum to be in the last frame before a keyframe (or more often) is better
Ok, I see, but what about making the checksum forward calculated? u mean storing the checksum for the future frames ... seems difficult, for write only stuff like realtime streaming we cant write te checksum later into the previous keyframe, and i dont see any advantage in
Hi On Friday 07 February 2003 15:32, Andreas Hess wrote: this even if its possible, so iam against it unless u have some example where it would provide an advantage
And the checksum, over what part is it calculated, over the header, the payload or over the whole frame? Maybe it would just be enough
to calculate the checksum over the headers to guarantee, that the structure of the file itself is ok, and leave the correctness of the payload to the respective codecs.
whole frame, so damaged frames can be found and redownloaded ... the filestructure is very hard to trash, all packets except the frame headers have 64bit startcodes, so they can be found even if they get scrambled around randomly, all packets allso have forward & backward pointers, so if they get damaged then they wont match anymore, the demuxer then just has to search for 2 valid forw/backw pointer pairs to resume playback or follow the backward pointers from the next keyframe which can be found easily by searching for its 64bit startcode all headers except the (key)frame headers allso have checksums so we know if they got damaged, and the frame headers really dont contain that much which can be damaged, theres just the flags, stream id & timecode only a few stream ids are valid and the timecode allso wont be random normally so it might be detectable often, a crc32 checksum would be about as long as the whole frame header, so it seems like a bad idea IMHO, and another question is what should be done if the crc doesnt match, drop the frame? that would happen most of the time anyway if its start is trashed or we pass video packets to the audio decoder if teh stream_id got killed [...] Michael
On Fri, Feb 07, 2003 at 04:58:42PM +0100, Michael Niedermayer wrote:
Ok, I see, but what about making the checksum forward calculated? u mean storing the checksum for the future frames ... seems difficult, for write only stuff like realtime streaming we cant write te checksum later into the previous keyframe, and i dont see any advantage in this even if its possible, so iam against it unless u have some example where it would provide an advantage
The intention behind storing the checksum just in keyframes is to keep the frames as simple as possible. No exceptions like, the last frame before a keyframe has to have a checksum and things like that. The question regarding your example with realtime streaming is, has a checksum there any worth? What if the checksum doesn't match, retransmitting the frame (or the sequence of frames) isn't a possibility, it's _realtime_ streaming ;) . So if the checksum doesn't match, the only chance you have with realtime streaming is drop the frame, but on the other hand, you can't drop frames, you've already played ;) So what is the purpose of the checksum? IMHO the only purpose is to know that something went wrong while downloading or editing your video. So a checksum in every keyframe should be enough. If you have keyframes with a checksum every 3 seconds or if you have frames with a checksum maybe every 1.5 seconds, IMHO there isn't a big difference between downloading 3 or 1.5 new seconds. [...] Andreas
Hi On Friday 07 February 2003 17:56, Andreas Hess wrote:
On Fri, Feb 07, 2003 at 04:58:42PM +0100, Michael Niedermayer wrote:
Ok, I see, but what about making the checksum forward calculated?
u mean storing the checksum for the future frames ... seems difficult, for write only stuff like realtime streaming we cant write te checksum later into the previous keyframe, and i dont see any advantage in this even if its possible, so iam against it unless u have some example where it would provide an advantage
The intention behind storing the checksum just in keyframes is to keep the frames as simple as possible. No exceptions like, the last frame before a keyframe has to have a checksum and things like that. The question regarding your example with realtime streaming is, has a checksum there any worth? What if the checksum doesn't match, retransmitting the frame (or the sequence of frames) isn't a possibility, it's _realtime_ streaming ;) . So if the checksum doesn't match, the only chance you have with realtime streaming is drop the frame, but on the other hand, you can't drop frames, you've already played ;) yes ... no .... :) just imagine that ur saving the thing to disk, and other ppl watch the same stream & save it too, if u have checksums u can fix the stream by exchangeing a few data packets with the other person ...
So what is the purpose of the checksum? IMHO the only purpose is to know that something went wrong while downloading or editing your video. So a checksum in every keyframe should be enough. If you have keyframes with a checksum every 3 seconds or if you have frames with a checksum maybe every 1.5 seconds, IMHO there isn't a big difference between downloading 3 or 1.5 new seconds.
and "normal" videos have 10sec between keyframes, at 650mb per file & 90min thats 1.2mb, yes its tiny for any decent internet connection but there might be many damages and the connection might be less then decent, so imho we should keep the current way, perhaps with a recommandition that the crc should be stored every 64kb or so ... [...] Michael
participants (3)
-
Andreas Hess -
Michael Niedermayer -
Michael Niedermayer CVS