an MPEG-TS stream consists of 188 byte chunks.  As default buffer size is 4096 bytes, the mpegtsdemux element is fed buffers containing fractional numbers of
unaligned MPEG-TS frames, which it apparently can't always cope with.  Among the symptoms, it reports "skipping, adaptation_field consumed all data", and drops some portion in the middle of the stream.  This badly garbles the content it is demuxing.  Forcing, eg, the hdv1394src to hand back buffers that are always integral multiples of 188 bytes avoids the behavior.  

Specifically the following script does not [always] work:

gst-launch \
	   hdv1394src \
             ! queue \
             ! mpegtsdemux \
             ! queue \
             ! mpeg2dec \
	     ! xvimagesink sync=false

The following change reliably eliminates the problem:

	   hdv1394src blocksize="4136" \
 
Unfortunately, the incorrect behavior has some timing component.  On (eg) an old dual core Thinkpad T61, the video reliably corrupts badly.  On a newer i7 quad-core, the problem doesn't seem to occur.

On the machine[s] where the blocksize change is needed to prevent HDV corruption, no other HDV application (eg, dvgrab) shows any trobule, nor has there ever been an observed failure using the forced blocksize with hdv1394src.