Problems Retiming Recording

[JDW13]

I've been using the PVR150 2.0.48.24227 drivers (without the registry fix) for a long time without timestamp problems, but last week the issue turned up, when a 2:30h recording showed up as only 0:21h. (I recorded in GBPVR 1.1.5, though I'm now running 1.2.9).

Fortunately I found the Timestamp Issue page in the wiki
http://gbpvr.com/pmwiki/pmwiki.php/Tips/TimeStampIssue
and have added the registry fix, so I hope not to run into the problem again.

But I wanted to fix the mis-timestamped file. I first tried the ffmpeg fix

Code:

ffmpeg.exe -y -i "%~dpn1_faulty.mpg" -vcodec copy -acodec copy “%~dpn1.mpg”

thinking a single stage fix would be faster than the 3 steps in retime.bat. The result was a file that seems fine (and has the correct length) when I scan it in MPEG Video Wizard (and I'm now burning it to DVD), but the remuxed file doesn't "work" when I try to view it in GBPVR. The timeline shows the correct 2:30 length, but there is no video (black screen) and only intermittent audio (plus maxed CPU use by GBPVR).

The most important question is why would GBPVR have trouble with this apparently good remuxed file?

Looking for a solution what would work in GBPVR, I then tried the retime.bat method (on the original mis-stamped file), which seemed to run fine except for a warning (?) from bbdmux

Code:

File F:\Video\Record\Frontline\Frontline_20080324_21002330_faulty.mpg is an MPEG-2 Program Stream
   pack header field flag value not allowed in program streams

but mplex1 then went on to say

Code:

Scanning video stream for pictures ...
Scanning video stream: 99% - byte offset 1373101984 of 1386971136.99  Found 95028 picture headers.
Video stream information
Stream length : 1386967416
Total time (seconds) : 3170

but 3170s is only about 0:52, and that was the size of file it produced (or about 1/3 the size it should be.)

Finally I tried using the mencoder fix:

Code:

mencoder.exe -of mpeg -ovc copy -oac copy "%~dpn1_faulty.mpg" -o "%~dpn1.mpg"

which didn't work well at all. It started with a series of

Code:

WARNING: OUTPUT FILE FORMAT IS _AVI_. See -of help.
success: format: 0  data: 0x0 - 0x0
Cannot seek backward in linear streams!
Seek failed

then went on to report -ve quantities as it went past the 2^31 point in the file, finally producing a file that MPEG Video Wiz showed as still having the same wrong length, but now also missing the audio...

Does anyone have any explanations for these remuxing problems, and/or better solutions?

Thanks! (if only for reading to the end)

[vmq]

I never had the timestamp problem, but you could try the method described here.

The file is split in audio and video parts by ProjectX (that usually does a great job fixing sync problems) and then multiplexed back into a MPEG file.

[HtV]

You can also try Videoredo, which will very probably do the job., but it is not freeware. Or try MpegStreamClip, it's free. I use it for cutting mpg's, it does this very well. It does have a repair-function aswell, but I don't know how well it works.

[mikiem]

DGPulldown, ProjectX, &/or there are a few other apps that re-write without re-encoding like Cuttermaran, restream, or even DVD Patcher?

[zehd]

In my experience, if the retime batch file, that has the three steps, won't fix the timestamp issue, (and it truly is the timestamp issue, it could still be something else) then your video probably can't be fixed.

I have found the QuickStream fix with Video Redo does a very good, quick job too, but I any video that exhibited the timestamp error could have been fixed with the retime.bat

[JDW13]

Thanks for all the suggestions for alternatives.

It seems the ffmpeg remux version is fine. I can view it in VLC (with the correct timeline), and I've burned it to DVD (via MPEG Video Wizard). So I'm back to the question of why GBPVR can't display it.

And then, if ffmpeg was able to remux the file, why did retime.bat and mencoder each give different (and incorrect) results?

[mikiem]

Disclaimer: I'm far from any sort of expert on GB-PVR... But I'm not a virgin with mpg2 if that means anything.

Mpg2 is simply put, a decoder standard -- There's nothing anywhere that dictates how the file is encoded or written as long as a std. decoder can, well, decode it. When/if a file won't play back, it's because either the file's bad, or there's something about it that your *chosen* decoder doesn't like.

If GB-PVR won't play the file, AFAIK that means the decoder you've chosen to use in GB-PVR won't play the file. If you want to double-check your other settings, can you use the decoder outside of GB-PVR, i.e. if you use the Cyberlink decoder, does the file play in Power DVD?

Otherwise can't begin to guess what's wrong with the file, though there's free software that might at videohelp.com &/or doom9.org. OR, if you do't want to fool with it that much, use DGIndex & either VFAPI or AVISynth to re-encode; DGIndex will produce an index file that one of the other two will use to render the video, frame by frame, & your choice of encoder can then do it's job. Takes about the same amount of time or less than a std. re-encode.

[zehd]

There is supposed to be this thing in the file, I think of it as sprockets, I guess it's a TimeStamp (but it's supposedly called something else) that when it gets messed up, is hard to fix.

During on-the-fly transcoding with ZProcess/Mencoder/FFmpeg, many people are unhappy with shuttling back and forth a transcoded file, because it loses audio sync. This is actually related. The reason a mpg recorded with a 150 usually works better than a transcoded (or in this case, remuxed, retimed) is that FFmpeg or MEncoder do not currently handle those sprockets very well.

Again, I keep forgetting the technical term, because I'm old and I like to connect to other analogies that I was familiar with - like when film was film...

I have been searching high and low for a transcoder that would do this correctly and found that the very best thing is VideoRedo. That's why I built the feature into ZProcess. But you have to have it for it to work. And it costs money...

I have tried ffmpeg and mencoder copy-through remuxing and it has all been hit and miss, even though I will also be adding them as retiming options.

One thing I will be playing with, (as you said that VLC is playing the file correctly) is working on using VLC as the actual retime engine...

>>on a side note, I have rebuilt my server (two 150s) and used the latest drivers BUT NO TimeStamp Fix... I'm hoping to get so frustrated by losing shows that I will find or create a fix for it... (wish me luck)

[JDW13]

[...]
When/if a file won't play back, it's because either the file's bad, or there's something about it that your *chosen* decoder doesn't like.

Thanks for the reminder! I haven't had to fiddle with GBPVR for so long I'd forgotten that I get to tell it which decoder to use.

I changed GBPVR's choice from System Default (not sure what it was using) to "Nero Video Decoder" (since the retimed file had also played fine in Nero ShowTime) and the remuxed file then played fine in GBPVR. (The InterVideo decoder also worked, but the MainConcept/Hauppauge one didn't.)

[JDW13]

[...]on a side note, I have rebuilt my server (two 150s) and used the latest drivers BUT NO TimeStamp Fix... I'm hoping to get so frustrated by losing shows that I will find or create a fix for it... (wish me luck)

Thanks, and good luck! But if this timestamp problem continues for me after adding the registry fix, I'll probably be looking at a different capture card...