VideoHelp Forum
+ Reply to Thread
Results 1 to 11 of 11
Thread
  1. 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
    Quote Quote  
  2. i don't use those tools. but you could try and narrow down to the source of the problem. for instance, don't use VRD. find and use something else to edit. i suspect that VRD is causing that problem for your videos. otherwise, i don't know what else to tell you.

    VHELP's - Sample Clips [last: 12.29.06],
    my YouTube videos
    Quote Quote  
  3. 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.
    Quote Quote  
  4. Member
    Join Date: Sep 2007
    Location: Canada
    Search Comp PM
    You should report these to the videoredo forum so they can have a look and fix it
    Quote Quote  
  5. Originally Posted by poisondeathray View Post
    You should report these to the videoredo forum so they can have a look and fix it
    I did. No response.
    Quote Quote  
  6. Member
    Join Date: Jun 2012
    Location: USA
    Search Comp PM
    Originally Posted by digitalfreaknyc View Post
    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
    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.
    Quote Quote  
  7. 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.
    Quote Quote  
  8. Originally Posted by transporterfan View Post
    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.
    Quote Quote  
  9. Member
    Join Date: Sep 2007
    Location: Canada
    Search Comp PM
    Originally Posted by digitalfreaknyc View Post



    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.

    If it fixes it in tsmuxer , why not tsmuxer, then VRD ?
    Quote Quote  
  10. Originally Posted by poisondeathray View Post
    Originally Posted by digitalfreaknyc View Post



    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.

    If it fixes it in tsmuxer , why not tsmuxer, then VRD ?

    Well, obviously that fixes it from now on...
    However, I have a TON of files that have already been edited and run through VRD. I'd like to be able to burn and watch those but tsmuxer can't fix them once they've been edited.
    Quote Quote  
  11. 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.
    Quote Quote