MPEG2Repair: New Tool for Error Detection (also improves 169time compatibility) - Page 2

I'm aware of that issue. It's one of the reasons I stopped using HDTVtoMPEG2 for editing my recordings. I have not used it in a long time but last I checked it also didn't always properly trim the video on GOP boundaries either. I've been using Womble's MPEG Wizard instead. If you enable the 'GOP Trim' option, it produces decent results. But you definitely need to remux the output because it strips all null packets and does some funky things to the data alignment. I also heard it doesn't handle field repeat flags (3:2 pulldown) but that shouldn't matter if you're remuxing.

I wish I could help out on that project but I just don't have the time. Luckily (or not depending how you see it), I was between jobs when I started MPEG2Repair so I had more time to kill. Unfortunately, my program doesn't have the infrastructure necessary to do anything useful with audio data (other than check for continuity errors). To make any audio changes/repair would take a lot of work. I'll keep it on the "to-do" list for the future.

I think the current H2M author is on the right track... so hopefully it will get fixed eventually.

-Mark

It would be relatively easy to make a command-line version since that's how it started originally. It also used to process mpeg2 elementary streams but I dropped that support because it didn't seem useful for HD (which usually comes in TS files).

Do you actually need a text-mode version of the tool, or can I simply add command-line arguments for input/output paths to the existing GUI version? The only thing missing from a GUI version would be the error return codes that one normally tests in batch files.

Well... I can't really get into the details but patching things after-the-fact like my tool does is really not the appropriate solution. Once data is missing/corrupted there's really no way to restore 100% of the original. If the AVX is still introducing errors (and I'm not saying it is), then it's something that needs to be fixed by Richard/169time. I also feel that my tool should remain an optional process because it is not necessary for all decoders and may not do as good of a job in some situations.

-Mark

Version 1.0.0.4 is now available. Very minor/quick changes (see first post). Fixed a crash bug which appeared in one of my recordings and improved default program selection for OTA. It should now pick the first program found instead of the last (usually weather, spanish, etc.).

Have fun.

-Mark

If you don't change any of the default INI file settings, then repair should be very safe. My program will never introduce glitches that were not there to begin with (at least nobody has ever reported such a bug). The reason I would make repair optional is because a good decoder can recover some errors in ways that I can't. Here's an example:

Let's say you have an error in an I-Frame. According to the mpeg2 spec, you're not allowed to skip any macroblocks in such pictures. So when I detect an error on this type of frame, I'm forced to replace any missing/corrupted macroblocks with something valid - I use black macroblocks. But in theory, a decoder could do something else such as skipping the rest of that slice/row and moving on to the next one. If there is no motion in the scene and the decoding buffers contain a previous frame, you may not even notice that those pixels were never updated. But you may notice if black pixels appear there as a result of my repair. Of course for many/most people here their decoder isn't this intelligent and would skip that entire frame, display random garbage, or worse.

My program does its best to regenerate a file that follows the ISO 13818-1, 13818-2 specs. I suggest people look at the log and watch those spots for themselves to determine if they prefer how their decoder handles the error compared to mine. For what it's worth - I watch 169time/Dish6000 recordings on a JVC30K and always run them through my program first. I have yet to find a case where an error looked worse after my program.

-Mark

Unfortunately, no. That's why I wrote the extra NullPacketSaver program. Due to the way my program does the repair, it often needs to go over and patch the output file in random places. It would complicate things too much if the output file was split into several segments. It's something I'll look into for the future but it's not likely to be added any time soon.

The reason I said "in theory" is because most of the PC decoders designed for DVD playback don't follow this rule. The Intervideo ones for example, just skip the entire frame. When watching, it shows up as random pauses as it waits to sync up with audio. I guess it depends on the user but I find random black squares less distracting than those pauses. Then there's other errors like bad motion vectors. In theory those should be ignored, but I've seen decoders that simply crash because they don't do any bounds checks on memory buffer access during motion compensation. People really need to check their particular decoder to see what it does.



Yeah... that's something I'm going to look into for the future. Main problem is that there's no guarantee that the previous p-picture has an intra-coded block in that position and the previous i-picture is likely too far away in time to provide a useful sample. The tool is already doing a re-encode of sorts in order to bring the luminance of the corrupted macroblock down to black. It was the simplest fix I could think of and similar to the DC only intra-blocks originally suggested by Ron. If you check the screen positions of 169time errors (at least on the old software versions) you will see why that strategy usually results in an invisible/perfect repair.



Well, you can keep doing what you're doing. If the optical devices down the road have problems, you can then run your archives through my tool before storing them to disc. In my experience, most of the hardware decoders should deal with errors. After all, errors are pretty much expected for OTA transmission. This whole issue is more of a problem for the DVD decoders because they expect perfect data to be coming off the disc. While on the archiving topic, I will say that I've had very bad experience with DVHS. I have a refurbished JVC 30K (with all the updates) and have rarely seen a recording without problems. Maybe it's my choice of tape - Fuji SVHS. In any event, I always record directly to hard-drive and archive to DVD-R to avoid introducing additional errors due to tape. I do still use the JVC to watch all my recordings by streaming files to it via firewire. I'm seriously considering getting a MyHD card to replace the JVC.

-Mark

I think you guys probably need a text-mode version. If you're going to launch it from a batch file, how will you know when it's done so you can proceed with the script? The GUI version would return instantly and then continue the repair/scan in the background. You probably need something that doesn't return when executed until it's done. Or are you using a more complex scripting system than simple DOS batch files?