File errors (Bad SEI detected/too short?)

[DigitalfreakNYC]

I'm desperate for some help on this. I have about 60 files that are just sitting on my PC that I can't burn because of this error.

I'm having a ton of problems with some files that I have. They were originally captured with my Hauppauge HD PVR and then edited with VRD. Once I author my Blu-ray with MultiAVCHD, I get a files that "jump" (for lack of a better word) a second or two after they start. It's not huge but it's about 2-3 frames, I would say.
When I ran them through tsmuxer, I got an error that said "Bad SEI detected. SEI too short." If I select "Do Not Change SEI," it processes fine but the jump is still there.
Is there any way to fix this? Is re-encoding the only option? Since MultiAVChd uses tsmuxer to create the discs, this anomaly is there on all of them.
The odd thing is that I've done nothing different with these files than I normally do when recording. Is this something that VRD entered into the equation? Or is there any chance of it fixing it?

Here's an example of one of the files:

General
ID : 1 (0x1)
Complete name : J:\Test
Format : MPEG-TS
File size : 442 MiB
Duration : 4mn 26s
Overall bit rate mode : Variable
Overall bit rate : 13.9 Mbps

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Format settings, GOP : M=3, N=24
Codec ID : 27
Duration : 4mn 26s
Bit rate mode : Variable
Bit rate : 13.0 Mbps
Maximum bit rate : 20.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.210
Stream size : 414 MiB (94%)
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Audio
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : 129
Duration : 4mn 26s
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 6.10 MiB (1%)
Language : English

[DigitalfreakNYC]

OK so I was just able to reproduce the error. It *IS* definitely a problem in videoredo. It's not a problem with the master file.

I've uploaded both the original recording and the edit and the errors are introduced AFTER videoredo.

ORIGINAL: https://mega.co.nz/#!xRFXmLRD!4-wdDz...L5D95M82CiSbs8
AFTER:https://mega.co.nz/#!kRVX3YhK!3eqneH...lo4T0oDfnmtq7A
And to see the (slight) jerkiness that I'm talking about, here's a smaller clip: https://mega.co.nz/#!xd9XhZqI!i7Jla3...AAvOgyXYguq8Uw

And, to be clear, this has happened with various versions of VRD. It's not just one. The files that I initially noticed this on were recorded several years ago. The files I uploaded were recorded today.

[Groucho2004]

Originally Posted by DigitalfreakNYC

Once I author my Blu-ray with MultiAVCHD, I get a files that "jump" (for lack of a better word) a second or two after they start.

Could it be a similar issue as this one?

[DigitalfreakNYC]

There's some more info from VRD at this point. It seems that ALL of the Hauppauge recordings that are edited with VRD are screwed up. Because (I guess) the SEI is unstable due to the way the Hauppauge makes recordings, it is only made even worse by VRD. They're recommending running it through TSmuxer FIRST before editing so that the SEI will be re-written and everything will be fine once it's edited.

A few frames are recoded around every edit point with VRD so there will likely be some sort of problem at every edit with Hauppauge files. It also depends from player to player how it will manifest itself.

From one of the authors:

The problem is likely a mismatch between the few frames we have to recode for the edit and the original stream. Our encoder doesn't support every possible H.264 option, so if your source stream is using something it can't support then there will be a slight mismatch which could cause the error you're seeing.

They're (hopefully) working on a fix for it but there's no guarantee that they'll be able to fix the files that are already screwed up. Although TSmuxer can fix short files (probably around 1-2 minutes), anything longer it crashes. I'm hopeful that there's a way to fix it for larger files. *fingers crossed*

However, from this point forward, I'll run every recording through TSmuxer FIRST and then go from there with regards to editing and burning. It's just shocking that it's taken 4 years to find this problem.