Anyone else ever see minor blocking artifacts in VideoRedo output? (with screenshots)

[Avisynth_challenged]

Hi all,

I record OTA HD in the US using a PC-based ATSC tuner card. I then use VideoRedo TVSuite 3 to edit out commercials from the recordings. However, in very rare instances, my edited output from VRD TVS3 exhibits minor blocking artifacts. The affected frames are usually less than 10 (roughly 1/3 second at 29.97fps) and they only appear in edited 1080i content. AFAIK, the problem hasn't been observed in edited 720p/480p/480i material.

Anyway, here are two screengrabs showing the issue:

Raw input into VRD TVS3 (good frame):
http://i64.photobucket.com/albums/h183/partingshot/pixelation01.png

Edited output from VRD TVS3 (with blocking artifacts):
http://i64.photobucket.com/albums/h183/partingshot/pixelation02.png
*Note: Images scaled down from 1920x1080 to 853x480


The artifacts appear at random points in the edited video. There is no correlation to "nearness" or "proximity" to edit points. VRD should be copying the frames without altering them in any way, but that isn't the case in these instances.

Has anyone else here ever seen the same? I'm wondering if there is any resolution to this issue. Thank you very much for your help!

[laserfan]

No, never seen such pixellation, my OTA HD grabs having come from an MDP130, HDHomeRun, and HD-TiVo. Honestly it suggests to me a PC hardware problem (have you done a memtest lately?) but if you want help your best bet is to post on the VideoReDo forums. They'll likely want a source sample to try to duplicate your results.

I have never gotten anything but perfect edits and perfect output from VRD TVS3.

[Mixer73]

I definitely get it the explanation is that there are errors in the stream the player can deal with but can't be re-edited into a new stream.

[laserfan]

I definitely get it the explanation is that there are errors in the stream the player can deal with but can't be re-edited into a new stream.You're saying you've confirmed this with the VRD support team?

Have you ever tried running Quickstream Fix first on one of the originals you had trouble with, to see if there is any difference in the edited output? @OP have you tried this?

[Mixer73]

You're saying you've confirmed this with the VRD support team? Have you ever tried running Quickstream Fix first on one of the originals you had trouble with, to see if there is any difference in the edited output? @OP have you tried this?

Yes - I have confirmed it. And No, QSF does not make it any better, if the video needs QSF, it will get worse.

[laserfan]

OK. Well I don't know how that can happen (an error that exists-but-doesn't-display does then show-up as pixellation in an edited version) but would expect the VRD guys to want to fix it if they can.

@Avisynth_challenged If you want to get this fixed your best bet is to contact VRD support, and submit a sample of your recording above to see if they can determine the cause and get after it.

[Ghitulescu]

Have you tried another smart cutter? Artefacts like these are generally given by a por reception and they are generally corrected in software. It shouldn't appear in the unprocessed frame/s, if they are invisible in the original. That means that VRD reencodes everything without carrying out any correction beforehand.

[Mixer73]

Have you tried another smart cutter? Artefacts like these are generally given by a por reception and they are generally corrected in software. It shouldn't appear in the unprocessed frame/s, if they are invisible in the original. That means that VRD reencodes everything without carrying out any correction beforehand.

That's not true at all, transmission loss is normal even if invisible in normal viewing.

Players will tolerate all sorts of corrupt streams but any editing tool which wants to produce a usable output has to be more strict and will show more artefacts.

[Ghitulescu]

Sorry, you're wrong.

Any software that passes the stream unaltered from input to output would overlook the possible defects within the stream, as it doesn't touch them. If the software or hardware player can correct the original stream it can correct the output stream exactly as well. Because of the same reason.
Believe me.

It's either that VRD reencodes everything (and kicks out at the stream errors) or simply removes the defect information from the file* (and the player is no longer able to recover the errors). Both ways wrong. Use a real stream corrector before using any 1-in-all / complete solutions. Or use something smaller, like smartcutter which can keep all streams (all audios, but I think this is of interest only in Europe, and the subtitles, again useful mostly in Europe).

The way I do without any error at all by a signal quality a bit more than 50% (which is the limit for HDTV) is to parse the M2TS stream for errors (delayed packets, missing packets etc.) and let them be corrected (reconstructed) before going to any editing.

*I just realized that VRD can simply renumber/retime the delayed packets without actually putting them into the right position. This could give the artefacts.
I don't use VRD as I don't like one in all solutions, mostly because their companies think that I am just another stupid customer that has no idea what's about and try to take decisions in my place, usually wrong or at least unappropriate. What I use are simpler software that do one thing and they do it well. Being simple has a secondary advantage, they're more or less bugfree, because it's easy to make a shorter program bugfree than a longer one.

[dumbledore]

try running it through mpeg2repair and see if it logs any stream errors.

[matt163201]

This is completely a problem with VRD

Original stream shows no problem playing, but then if its run thru quick stream fix or if its loaded into the program and saved, the error will show up

And it is very annoying

This happens whenever there is a "TemporalRef Gap" MPEG2Repair error

Unless VRD fixes this, there is no way around this....and it is completely ridiculous.

Once again, the original capture stream shows no pixelation but once you run it thru VRD or thru QSF then the error is in the result at those timepoints given by MPEG2Repair that say "TemporalRef Gap"

[Mixer73]

OK well go post to VRD forums and get some other guys to back you up on it, I've found them to be pretty responsive if you put details in.

[Ghitulescu]

*I just realized that VRD can simply renumber/retime the delayed packets without actually putting them into the right position. This could give the artefacts.

Original stream shows no problem playing, but then if its run thru quick stream fix or if its loaded into the program and saved, the error will show up

....

This happens whenever there is a "TemporalRef Gap" MPEG2Repair error
....

Once again, the original capture stream shows no pixelation but once you run it thru VRD or thru QSF then the error is in the result at those timepoints given by MPEG2Repair that say "TemporalRef Gap"

What I said, the incoming stream is defect. Don't blame VRD for your fault. Use a stream corrector, not an MPEG corrector. Something like TS doctor or the like, and not last, try to improve your reception.

[matt163201]

What I said, the incoming stream is defect. Don't blame VRD for your fault. Use a stream corrector, not an MPEG corrector. Something like TS doctor or the like, and not last, try to improve your reception.

The incoming stream is not defective. Period. I dont need to improve my reception because its not coming thru antenna, and the quality of signal from my line is well above the good range, as I have check in the hidden menu settings of said STB.

I have tried EVERY program to fix the stream, including the one you mentioned, and the resulting "fixed" stream still has the error occur in VRD at said timepoint.

The original stream plays fine, it has been capped numerous times, it happens at the same point in said capture, it has happend in other captures as well, again not affecting playback UNTIL it reaches VRD, which means it plays back 100% fine before any editing/ manipulation.

And we are not the only people to complain of these things on VRD, it is a known problem for some time now. The problem is how VRD handles the TemporalRef Gap, because other MPEG applications such as Womble dont show this error at the same point.

So please know what you are talking about before you respond. Asking me to improve my reception and that the stream is defective is just wrong.

[Ghitulescu]

I know what I'm talking. There are various sources of this gap, the most usual being reception problems (quality drops, interferences, this is valid for all media carriers, including cable). This was the opinion of other members as well. How do you know that the original stream is not defective, apparently Avisynth_challenged is the OP not you and he didn't post so far any sample thereof?

Besides I learned only few seconds ago that you used stream correctors (on probably another sample) - this was an undisclosed info or you simply didn't do this before otherwise you'd have already mentioned this.
I don't have my crystal ball with me, I can't read minds either. Don't accuse people based on info known only to you...

It never happened to me that a stream parsed by ts doctor be rejected by any software I used (including several HD authoring software). If VRD has been documented to produce this error, use another cutter (try smartcutter, it keeps all the streams, including the subtitles which most other cutters reject).

[matt163201]

PM sent to you with sample of source

[Mixer73]

And we are not the only people to complain of these things on VRD, it is a known problem for some time now. The problem is how VRD handles the TemporalRef Gap, because other MPEG applications such as Womble dont show this error at the same point.

Be careful what you wish for Womble also loses AV sync at any of these points, personally I'd rather have video in-sync with a small artefact, which I see extremely rarely.

[Ghitulescu]

See the file and the log and pay attention to TEI info in that log -> "Transport Error Indicator (TEI) -=- Set by demodulator if can't correct errors in the stream, to tell the demultiplexer that the packet has an uncorrectable error"

[link removed upon request]

So, once you have at least one TEI, then you have a bad reception or any other similar condition, that the demodulator cannot correct it and flags the stream accordingly.

[matt163201]

So break it down for me like Im a four year old.

It plays fine, other editors edit it fine, videoredo pixels out a segment even with fast frame copy or quick stream fix

This question still goes unanswered

[Ghitulescu]

The answer has already been given 3 times: the stream has an error or at least is flagged as having an error - other video processors/editors either ignore it or do not touch it but VRD drops the affected packet in an attempt to repair the stream.

[matt163201]

Ok, so final answer is

Yes, the streams do have an error in them, probably from the broadcaster
But also
Yes, VideoReDo has a problem handling these errors where other applications do not

Solution: Either use another application to edit your content if you have these errors in your stream or get VideoReDo to incorporate an option to ignore these errors and not fix them automatically / do an actualy direct stream copy