(you need a super long DV file for this bug to potentially appear. been having it consistently with files longer than 50G or so)

I'm using the following pipeline to tranform the dv file into a nice ogg/theora/vorbis file

gst-launch-0.10 -v -v \
        filesrc location=$1 ! decodebin name=demux \
        \
        demux. ! \
        queue ! ffmpegcolorspace ! 'video/x-raw-yuv,format=(fourcc)I420' ! \
        ffvideoscale ! 'video/x-raw-yuv,width=384,height=288' ! \
        queue ! theoraenc keyframe-force=8 ! mux. \
        \
        demux. ! queue ! audioconvert ! vorbisenc ! mux. \
        \
        oggmux name=mux ! filesink location=$2

this works for a while, but eventually crashes :

+ Trace 67023

at this point, frame #2 has the following information :
(gdb) print dvdec->decoder
$1 = (dv_decoder_t *) 0x81afa00
(gdb) print inframe
$2 = (guint8 *) 0xb5758d80 <Address 0xb5758d80 out of bounds>
(gdb) print outframe_pitches
$3 = {1440, 288, 288}

which seems to point to a bug somewhere prior to getting into this function (demuxer maybe).
here's the buffer passed to the function :
(gdb) print buf
$7 = (GstBuffer *) 0x81c34b0
(gdb) print *buf
$8 = {mini_object = {instance = {g_class = 0x8064638}, refcount = 1, flags = 1, _gst_reserved = 0x0},
  data = 0xb5758d80 <Address 0xb5758d80 out of bounds>, size = 144000, timestamp = 3737560000000,
  duration = 40000000, caps = 0x824acc0, offset = 93439, offset_end = 93440, malloc_data = 0x0,
  _gst_reserved = {0x0, 0x0, 0x0, 0x0}}

in which the data is broken already