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
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays!
+ Reply to Thread
Results 1 to 12 of 12
Thread
-
-
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-wdDzBxGgOZB3zIJz4qjO22tmTgNL5D95M82CiSbs8
AFTER:https://mega.co.nz/#!kRVX3YhK!3eqneHgtAjFA7v0lkJKLkptgeoqiylo4T0oDfnmtq7A
And to see the (slight) jerkiness that I'm talking about, here's a smaller clip: https://mega.co.nz/#!xd9XhZqI!i7Jla3gWY83qmxnISZTg1z9Ucn9kHAAvOgyXYguq8Uw
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. -
FWIW, I'm getting errors in several players when clicking around your original file. I suspect it has to do with the GOP and B-Frame structure of your captures. Even TMPGenc SMart Renderer could not properly handle the beginning of the file, but managed later internal cuts successfully.
-
I just ran your file through VRD again and it found and removed two audio resync frames, the irony is that when I went and googled Hauppauge HD PVR and resync frames I found this:
http://www.videoredo.net/msgBoard/showthread.php?29820-Audio-Resync-Frame-Removed-a-question
And it sounds awfully like the problem you're suffering.
It looks like it's not VRD with the problem it's Hauppauge devices (well, according to VRD team). A faulty time stamp issue.
The file played back fine after the error was quickstream fixed, by the way. -
You can run it through but it doesn't fix the problem. If you run it through tsmuxer, it will show the SEI problem. The problem isn't the playback because it plays back fine after it's captured. Zero problems whatsoever on this end through VLC or splash. It's only once it's been run through TSmuxer that it gets screwed because it sees the SEI problem.
The SEI clip that i uploaded (the last one) removed frames when it shouldn't have. That's what happens after you run it through VRD.
What I've noticed from playing around today is that if you take the initial file captured by the Hauppauge and, before doing anything else, run it through tsmuxer, it will fix the SEI issue. However, once you send it through VRD, you're screwed. The entire file gets screwed up. -
-
-
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.
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. -
What the hell is SEI/VUI. I am asking here. Because in my other thread I can wait for days I suppose.