View Full Version : Stuck while frame-stepping
First of all, I'd like to express how much I like VRD. :) I was looking high and low for a decent, working MPEG2 editor, and VRD fits the bill perfectly. The lack of bloat (in terms of unnecessary extras as well as price!) is also great. I'm currently a week or so into my evaluation, but I'm definitely considering buying a license.
Meanwhile I thought I'd report some bugs/annoyances I find... first one in this post.
What I'm doing is editing out camcorder glitches (in crappy VHS-C material from the 80's) that mostly occur around scene changes, and I need to pinpoint the Start and End with frame precision. So I move along each scene with I-frame stepping, and when I notice a scene change, I narrow it down by using single frame stepping.
While doing this, quite often VRD seems to get stuck on an I-frame while I'm stepping backwards. (that's my guess anyway, it just stops there - I can still move forward) Thus I can't move back to the last few frames of the previous scene to set my Start cut point. The workaround I'm using is to just skip back to the last I-frame and step forward again until I see artifacts.
Would be nice if it could be fixed though. It's hard to make an example video file as it doesn't happen all the time, and I dont think it's related to any particular files either... but if there's any extra information you need, just let me know!
/ Carl Ådahl
First of all, I'd like to express how much I like VRD. Thank you very much.
While doing this, quite often VRD seems to get stuck on an I-frame while I'm stepping backwards.I believe this has been addressed in a maintenance release. Please download Build 219 from ftp://videoredo:videoredo@ftp.drdsystems.com/Betas/ and give that a try. If it doesn't fix it then let me know. There is one instance where backwards I-Frame doesn't always work, which is when you have very large GOP sizes, > 30 frames / GOP. However, you can still use back by 1 sec and/or back by single frame.
Lets see what happens with the maintenance build and procedd from there.
I tried build 219, and I'm still experiencing the "freezes". Here's a slightly better explanation of what happens:
- I move along the captured video using the I-frame or second-skip mode until I find an in-camera cut with artifacts in the surrounding frames. (it's these that I'm editing out primarily)
- To set the start and end cut points in VRD, I move back and forward a bit using the frame stepping. Sometimes when I move back a frame, VRD gets stuck and just.. stops stepping. It sometimes also happens if I'm I-frame stepping backwards, but it seems to occur more often with single frame stepping.
- To work around the problem, it helps to instead move back an I-frame, a second etc... just what works varies randomly it seems. After that I move forward instead, using the frame stepping, to the target frame.
I don't think it has to do with the video being problematic, but I can't be sure. I'll post as soon as I find out more details.
Is this by any chance recorded with 3:2 pulldown? The ATI AIW can create 3:2 pulldown and even in build 219 there are some issues. I'm trying to get them all resolved for Build 220.
You might want to isolate the section of video where "back frame" gets stuck and upload it to the ftp site: ftp://videoredo:videoredo@ftp.drdsystems.com/
I can probably save you a lot of time if I look at the internals of the file.
Nope, this is true 50Hz PAL video captured from VHS-C camcorder with a WinTV PVR-250, and I keep the video interlaced through the entire process down to the authored DVD.
I'll try to find an isolated segment of video for you where the error occurs.
bitter_old_man
04-12-2004, 04:19 AM
I've seen the same behavior even with build 219. I'm capturing VHS with my PVR250. If the capture spans an area where two separate recordings are on the tape, or two recordings overlap, then this situation may arise. It happens at the beginning of the second recording.
Barry
I've seen the same behavior even with build 219. I'm capturing VHS with my PVR250. If the capture spans an area where two separate recordings are on the tape, or two recordings overlap, then this situation may arise. It happens at the beginning of the second recording.If you can upload a clip, I'd sure appreciate it
Here's something else to try. Remux the original file with VideoReDo. By that I mean open it, make sure the navigation bar is entirely green and save it. That will re-calculate and re-write all the internal timestamps (PTS and GOPs) in the new output file. These timestamps are used extensively for navigation.
I'll hopefully be able to find a clip later today to upload...
I've seen the same behavior even with build 219. I'm capturing VHS with my PVR250. If the capture spans an area where two separate recordings are on the tape, or two recordings overlap, then this situation may arise. It happens at the beginning of the second recording.
That's quite interesting, and it does seem like the nature of the 'gap' or 'overlap' matters... like if there is more "noise" it's more likely to be a problem. Could this have to do with how the PVR-250 captures the video sync signal on the tape? In the gaps or damaged areas between segments the sync would be missing if I understand composite video correctly.
I'll also try Dan's suggestion with remuxing.
Could this have to do with how the PVR-250 captures the video sync signal on the tape? In the gaps or damaged areas between segments the sync would be missing if I understand composite video correctly.
If you have lots of noise or frame loss on the source VHS tape, the PVR will drop videoframes, but not audio. The dropped frames might explain why the back frame is getting stuck. Its looking for the previous timecode and if it doesn't exist it find the next one (which is the same frame). If that's the case, a remux will do the trick. If you lose some audio frames in the remux that's an indication of dropped video frames.
I found a good example clip just now, see "aav_stuck_clip2.mpg" on the FTP. (I used the Trim and Copy Source feature in VRD to save it.)
The clip is mostly static, but there's a very clear case of a stuck frame if you start at the end and framestep backwards. At 00:00:06.19 the first obvious case occurs. I-frame skipping past it works, but it gets stuck again if you continue frame stepping at that I-frame.
Maybe there's nothing to do the besides remuxing the entire thing first, like you suggest, or can it be fixed transparently somehow?
I noticed that saving out the clip using the regular Save Video feature (remuxing) removes the problem, as does cutting in TMPGEnc (which also remuxes). TMPGEnc reports the audio is slightly longer than the video, so that would indeed indicate lost video frames?
I noticed that saving out the clip using the regular Save Video feature (remuxing) removes the problem, as does cutting in TMPGEnc (which also remuxes). TMPGEnc reports the audio is slightly longer than the video, so that would indeed indicate lost video frames?Thanks for the clip, I'll look at it later. If Remuxing fixes the problem then you've definately have one or more lost video frames. I would bet that VideoReDo removed some audio to keep everything in sync.
Maybe there's nothing to do the besides remuxing the entire thing first, like you suggest, or can it be fixed transparently somehow? I started thinking about this even before your msg was posted. :) There is definately a solution, don't know yet how hard it would be to implement.
bitter_old_man
04-12-2004, 09:19 PM
Dan,
Remuxing worked. The report at the end said "1 audio frame error" and 14 audio resync frames removed".
If you want another clip let me know.
Barry
I looked at your clip. The section you sent me was a real mess, lots and lots of video noise. The internals of the file match what you see on the screen. The video has consistent 15 frame GOPS, for PAL that means 600 Msec seperation between GOPS. The timecodes in the file jump around from 600 to 1,200 msec/GOP.
I'm glad the remuxing worked, am looking at what it will take to let the frame back work even in the presence of such bad data.
Yeah, that tape had some bad restarts/reshoots layered together.... maybe I should've picked a cleaner example. It's usually only one or a few frames of static between takes.
A solution would be great, thanks for looking at this. In the meantime, what should I do right now to be on the safe side? Should i remux all raw captures in VRD before attempting to edit, or is it a benign problem that won't affect the results? (assuming I cut out all the problematic areas in VRD)
This example was fine. I've put the fix in, and it will be in the next build (#220), which I hope to post tonight. It can be a little slow to go back one frame when so many frames are missing, but it no longer seems to get stuck which was the main objective. I'll post a msg here to let you know when the build is available.
In the meantime, what should I do right now to be on the safe side? Should i remux all raw captures in VRD before attempting to edit, or is it a benign problem that won't affect the results? (assuming I cut out all the problematic areas in VRD)In the meantime you don't need to do anything special. The frame positioning issue has no effect on the output as the problem is benign, as you say. The auto resyncing aspect of VideoReDo should put everything back together properly.
Build 220 is now available for testing. You can find it either on the FTP site in the betas folder or go to the download page at videoredo and click the download button on the right. This build addresses the frame back issue.
Wow, you're lightning fast. :) Thanks!
I'll give it a spin as soon as I can... I'm going out of town for a few days so might not be able to confirm the fix until this weekend.
Btw, the download link on the web site doesn't work, the install file seems to be missing.
Edit: My bad, was looking at the wrong URL: http://www.drdsystems.com/Product%20MPEG%20Editor.htm. That link is dead however.
I've tried build 220 a bit now and it no longer seems to get stuck. Awesome, thanks!
I've tried build 220 a bit now and it no longer seems to get stuck. Awesome, thanks!You're welcome. I think we are getting close. Most of the annoying issues should be resolved in this build. I'll try to get the complete release notes posted later today.
bitter_old_man
04-13-2004, 07:03 PM
Build 220 working fine for me too. The clip I tested it on was very noisy and I could step throught it with no problem. Thanks, Dan.
The more I use VideoReDo, the more I love it. Editing MPEGs used to be a chore, now it's a piece of cake (without the calories).
Barry
The more I use VideoReDo, the more I love it. Editing MPEGs used to be a chore, now it's a piece of cake (without the calories). Thanks, I'm glad you find it both useful and enjoyable. Now that the maintenance release is so close to being released, I can start to concentrate on the fun stuff like new features and capabilities.
vBulletin® v3.7.1, Copyright ©2000-2009, Jelsoft Enterprises Ltd.