N-VOPs byte data and relation to packed BS null frames?

[shae]

Is byte data of N-VOPs the same regardless of encoding parameters? And more specifically, is it valid to copy an N frame from one encoding to another?

What sort of frames are the empty ones used with packed bitstream? Are they N-VOPs with special handling by the decoder, or something else?

[Moitah]

NVOPs will actually vary throughout a video because they contain a timestamp.

In the case of the "dummy" NVOPs used for packed bitstream, I'm pretty sure decoders depend on the timestamp being correct, so no, you can't just copy them around. The time_inc_bits value for dummy NVOPs should be the same as the backwards reference VOP. For example, with these frames:

IP B B N

The NVOP would have the same time_inc_bits value as the PVOP. modulo_time_base is always 0 for the NVOP. Another thing, and I'm not sure if decoders care about this, but the vop_coding_type should be the same as the backwards reference VOP (this is PVOP usually, but can be SVOP if GMC was used).

With real NVOPs it might not matter so much if you copy them around within a file and time_inc_bits is wrong. However, you'd have to be careful about copying them between files with different framerates, since the size of the time_inc_bits field will usually be different depending on the framerate.

[shae]

So the only differece between real and "filler" ones is the vop_coding_type?

If vop_coding_type is set to the ref frame type, how is the frame identified as N? The fact that it has 0 data?

Also, can't the decoder figure out the correct order without a timestamp? It knows a few future refs were already decoded, so the next filler N should just pop a frame out of the "stack". But maybe this is a problem with multiple Bs...

EDIT: Are time codes significant for other frame types?

[Moitah]

vop_coding_type is usually PVOP for real NVOPs as well. There is no vop_coding_type that indicates an NVOP, this is done by a flag called vop_coded. The start of every VOP looks like this:

vop_start_code (32 bits - 0x000001B6)
vop_coding_type (2 bits - 0=I, 1=P, 2=B, 3=S)
modulo_time_base (length varies)
marker_bit (1 bit - always 1)
vop_time_increment (length varies)
marker_bit (1 bit - always 1)
vop_coded (1 bit - 0 for NVOPs, 1 otherwise)

The decoder uses the timestamp to find dummy NVOPs because it's possible for real NVOPs to be used with packed bitstream as well.

I'm not sure if the timestamps are significant for other frame types. My guess is no, but it's been a while since I've thought about this type of stuff so I could be forgetting something. I'm referring only to the AVI container since it defines a framerate in the header, the timestamps could be critical in an MP4 container if that is the only method of keeping time (I don't know). And it's possible that some decoders are pickier than others.

[shae]

I think I'll leave N-VOPs alone for now. Moving other frame types around (in unpacked AVI form) didn't seem to have adverse effects so far. Even ffmpeg didn't complain (it tends to be a better analyzer than normal VFW/DS decoders which just hide errors), so it appears to be valid.

If something looks okay in unpacked form, can repacking thru MPEG4 Modifier cause unforeseen problems? I'm not sure WHAT I moved around, so maybe this will lead to some odd inter-frame dependencies that don't make sense in packed form?

By the way, is there a source for this sort of info other than ISO 14496-2 (and other parts, if at all relevant to ASP)? It looks like they don't generally have it online, so I couldn't find the more recent revisions. (And all that info on non-video data... what's the point?)