Hi currenbtly we have " max_distance max distance of syncpoints, the distance may only be larger if there is no more than a single frame between the two syncpoints. This can be used by the demuxer to detect damaged frame headers if the damage results in too long of a chain syncpoints SHOULD be placed immediately before a keyframe if the previous frame of the same stream was a non-keyframe, unless such non-keyframe - keyframe transitions are very frequent SHOULD be set to <=32768 if the stored value is >65536 then max_distance MUST be set to 65536 max_pts_distance max absoloute difference of pts of new frame from last_pts in the timebase of the stream, without a checksum after the frameheader Note that last_pts is not necessarily the pts of the last frame on the same stream, as it is altered by syncpoint timestamps. max_frame_size max frame size without a checksum after the frameheader. MUST be <=4*max_distance. If stored value is bigger then max_frame_size MUST be set to 4*max_distance " in the spec, there are several issues which need disscussion 1. no limit for max_pts_distance, users could set it to insane values and cause troubble on the demuxer side, yes theres the time rescaling issue 2. max_frame_size limit is too large, its practically 256k, i think 64k or less is more reasonable 3. what about droping one varaible and max_distance=max_frame_size? -- Michael
On Fri, Mar 10, 2006 at 02:30:18PM +0100, Michael Niedermayer wrote:
in the spec,
there are several issues which need disscussion 1. no limit for max_pts_distance, users could set it to insane values and cause troubble on the demuxer side, yes theres the time rescaling issue
IMO you just have to rely on file authors to pick something sane. Even if you did pick an arbitrary value, it would still be horribly wrong at some time scales. Consider for example a video of some micro-scale process recorded at tens of thousands of fps with real timestamps, and intended to be watched frame-by-frame or with -speed 0.001 or such. As long as the spec makes it clear that implementations may have trouble playing files with inappropriate max_pts_distance, I don't think people will set it wrong just for a 0.001% overhead reduction or whatever..
2. max_frame_size limit is too large, its practically 256k, i think 64k or less is more reasonable 3. what about droping one varaible and max_distance=max_frame_size?
I'm totally fine with 2 and 3. Rich
On Fri, Mar 10, 2006 at 08:50:11AM -0500, Rich Felker wrote:
On Fri, Mar 10, 2006 at 02:30:18PM +0100, Michael Niedermayer wrote:
in the spec,
there are several issues which need disscussion 1. no limit for max_pts_distance, users could set it to insane values and cause troubble on the demuxer side, yes theres the time rescaling issue
IMO you just have to rely on file authors to pick something sane. Even if you did pick an arbitrary value, it would still be horribly wrong at some time scales. Consider for example a video of some micro-scale process recorded at tens of thousands of fps with real timestamps, and intended to be watched frame-by-frame or with -speed 0.001 or such.
Or a common example for the opposite, a time lapse.... Though you probably wouldn't use real timestamps in that example. - ods15
On Fri, Mar 10, 2006 at 02:30:18PM +0100, Michael Niedermayer wrote:
Hi
currenbtly we have " max_distance max distance of syncpoints, the distance may only be larger if there is no more than a single frame between the two syncpoints. This can be used by the demuxer to detect damaged frame headers if the damage results in too long of a chain
syncpoints SHOULD be placed immediately before a keyframe if the previous frame of the same stream was a non-keyframe, unless such non-keyframe - keyframe transitions are very frequent
SHOULD be set to <=32768 if the stored value is >65536 then max_distance MUST be set to 65536
Any chance we can increase this to 128kb?
max_pts_distance max absoloute difference of pts of new frame from last_pts in the timebase of the stream, without a checksum after the frameheader Note that last_pts is not necessarily the pts of the last frame on the same stream, as it is altered by syncpoint timestamps.
max_frame_size max frame size without a checksum after the frameheader. MUST be <=4*max_distance. If stored value is bigger then max_frame_size MUST be set to 4*max_distance "
in the spec,
there are several issues which need disscussion 1. no limit for max_pts_distance, users could set it to insane values and cause troubble on the demuxer side, yes theres the time rescaling issue
I dislike it... You worry too much about broken muxers. :/ "SHOULD NOT be higher than 1/timebase" ....
2. max_frame_size limit is too large, its practically 256k, i think 64k or less is more reasonable 3. what about droping one varaible and max_distance=max_frame_size?
Hmm... I used to be against this, but I think now you feel stronger about this than I do, so no real objection... - ods15
Hi On Fri, Mar 10, 2006 at 03:52:43PM +0200, Oded Shimon wrote:
On Fri, Mar 10, 2006 at 02:30:18PM +0100, Michael Niedermayer wrote:
Hi
currenbtly we have " max_distance max distance of syncpoints, the distance may only be larger if there is no more than a single frame between the two syncpoints. This can be used by the demuxer to detect damaged frame headers if the damage results in too long of a chain
syncpoints SHOULD be placed immediately before a keyframe if the previous frame of the same stream was a non-keyframe, unless such non-keyframe - keyframe transitions are very frequent
SHOULD be set to <=32768 if the stored value is >65536 then max_distance MUST be set to 65536
Any chance we can increase this to 128kb?
iam weakly against it, rich whats your oppinion?
max_pts_distance max absoloute difference of pts of new frame from last_pts in the timebase of the stream, without a checksum after the frameheader Note that last_pts is not necessarily the pts of the last frame on the same stream, as it is altered by syncpoint timestamps.
max_frame_size max frame size without a checksum after the frameheader. MUST be <=4*max_distance. If stored value is bigger then max_frame_size MUST be set to 4*max_distance "
in the spec,
there are several issues which need disscussion 1. no limit for max_pts_distance, users could set it to insane values and cause troubble on the demuxer side, yes theres the time rescaling issue
I dislike it... You worry too much about broken muxers. :/
"SHOULD NOT be higher than 1/timebase" ....
so may i add SHOULT NOT be higher the 1second? [...] -- Michael
On Fri, Mar 10, 2006 at 03:30:32PM +0100, Michael Niedermayer wrote:
there are several issues which need disscussion 1. no limit for max_pts_distance, users could set it to insane values and cause troubble on the demuxer side, yes theres the time rescaling issue
I dislike it... You worry too much about broken muxers. :/
"SHOULD NOT be higher than 1/timebase" ....
so may i add SHOULT NOT be higher the 1second?
That was the idea I was getting at.. I preffer my notation for it... It's a unit-less integer, not a physical variable... - ods15
On Fri, Mar 10, 2006 at 03:30:32PM +0100, Michael Niedermayer wrote:
On Fri, Mar 10, 2006 at 03:52:43PM +0200, Oded Shimon wrote:
On Fri, Mar 10, 2006 at 02:30:18PM +0100, Michael Niedermayer wrote:
SHOULD be set to <=32768 if the stored value is >65536 then max_distance MUST be set to 65536
Any chance we can increase this to 128kb?
iam weakly against it, rich whats your oppinion?
Rich said OK on IRC. Committed. - ods15
participants (3)
-
Michael Niedermayer -
Oded Shimon -
Rich Felker