The current behaviour of splitting into the MPEG packets might be useful to have but splitting into something like AUs would be at least useful as a new stream-format.

Actually, it does split in complete frame, most of the time. What I observer is a broken frame (without discont !?! and before reset), right after a seek. That seems to be the real issue.

You might be right, for both mpeg4 and mpeg2. Could you check if the code does that too?

I'm quite sure that mpeg4videoparse at least used to not output complete frames some months ago.

I've checked the code and mpeg4 parse split in complete frames.

Fixed by the patch in #672701 from my understanding... let's close this as a duplicate?

I don't think that #672701 has to do with this.

However, it more seems like most of the parsing code in _check_valid_frame expects the frame to start at offset 0, but I don't see anything that actually enforces that (like skipping to the first start code).  That could lead to all sorts of confusion and initial broken frame stuff, particularly following a seek which is likely to end up at a non-startcode position (contrary to normal sequential scan).

Continuing the above, following should handle some corner case misparsing so as not to end up with broken frames

commit e283460c784f7c5b98aaffa7c2ccbf4a722cfee4
Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk>
Date:   Mon May 21 19:22:19 2012 +0200

    mpegvideoparse: unobfuscate frame parsing
    
    ... and add comments and debug statements.
    
    Fixes #674202.

[and in 0.11]

commit 1f0c18daf295b06cc9d8f285d47e49cf7cff389b
Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk>
Date:   Mon May 21 19:22:19 2012 +0200

    mpegvideoparse: unobfuscate frame parsing
    
    ... and add comments and debug statements.
    
    Fixes #674202.
    
    Conflicts:
    
        gst/videoparsers/gstmpegvideoparse.c