Is this macro-blocking?

[txporter]

I am trying to see what I can do to improve the quality of some HD captures since I am thinking about re-encoding them to hardsub them and possibly resize from 1080 to 720. At any rate, I am seeing this type of blocking, or at least what I am calling blocking. Is this what everyone refers to as macro-blocking? From what I have seen from the threads I have seen on blocking, I thought it was usually almost the entire frame. At any rate, I am seeing this in these captures every second or so (every 30 to 100 frames, approximately). I have seen some limited success with using cpu=3/4 in MPEG2Source, Deblock (which I think is basically the same thing), and Deblock_QED. I can't really get rid of them (which is probably to be expected), but I am wondering if what I am seeing is actually something else and if I should be using something else to fix it.

This picture is just a capture of the source video from AvsP only running through MPEG2Source(cpu=0).TFM().Tdecimate()

[poisondeathray]

It's blocking , but the pattern isn't the usual typical for MPEG2 type compression artifacts

This looks like something else, like from the transmission end.

Since the size (it's tough to tell size, because your screen shot wasn't 1:1 or it might have been, but cropped) & pattern/distribution isn't typical for macroblocking , you will find your filters less useful as they are more geared to that specific type of macroblocking

[txporter]

Ok. Guess I won't spend a lot of time on them then. They aren't horribly noticeable when played at full speed. I hate to over-soften the whole picture just to chase blocks on ~1% of the frames.

[poisondeathray]

I guess it depends how picky you are, or your tolerance for these things , and how much effort you are willing to expend

You could apply filters in sections, or even sections of indivudual frames in compositing applications. My guess is you don't really care since these are TV caps.

[txporter]

Yeah, I am not looking for perfect here. Just checking to see if there was something fairly easy to run (meaning avisynth filter) to fix/minimize the problem since I was thinking about processing the video anyhow. I don't have any interest in stepping through the video and fixing each individual frame. I am going to watch the show eventually and then just delete it.

[themaster1]

Let me guess, you have recorded this video with an analog cable (YUV) true or false?

[lordsmurf]

That's an interference pattern. It's H.264 blocking, as it's not checkerboard like MPEG-2.

[txporter]

Let me guess, you have recorded this video with an analog cable (YUV) true or false?

I recorded this with a standard RF cable to a TivoHD with cable cards. It is a digital signal capture. Not sure if there are any analog conversions that go on within the Tivo, but I am 99% certain that the Tivo is simply capturing what is broadcast and is recording it as-is (the processor isn't very powerful internally). I do display through both component and HDMI, but I don't think that is relavent since I am transferring the show to my PC for processing. It does remux the stream into a .tivo wrapper which is basically a .mpg container with a header telling which tivo it came from.

[txporter]

That's an interference pattern. It's H.264 blocking, as it's not checkerboard like MPEG-2.

That is interesting. I suppose that Time Warner could be storing the shows as H.264 and then converting to MPEG2 as it broadcasts? It is definitely MPEG2 when I capture it and I am re-encoding to MPEG2.

[lordsmurf]

That's an interference pattern. It's H.264 blocking, as it's not checkerboard like MPEG-2.

That is interesting. I suppose that Time Warner could be storing the shows as H.264 and then converting to MPEG2 as it broadcasts? It is definitely MPEG2 when I capture it and I am re-encoding to MPEG2.

Possible, yes. That might even be the method TW received it in, from wherever.

[vhelp]

Your broadcast source could be h264 format but it is hard to say because you are not clear in your setup and how you actually obtain the final source, hence the image you are presenting.

What do you have ?

cable box
cable dvr
satellite receiver
OTA receiver

and, how are they connected ?

cable box -> tivo unit
receiver box -> tivo unit

and, how are you obtaining exactly ?

through the box, or tivo ?
with a dvm card
with a hd card

And, can you accurately determine the broadcast source type as h264 or mpeg2 ?

I didn't see any usual mpeg-2 artifacts. It looks more h264 related, however, it could and more than likely be a transmission error: where the signal borderlines minimum acceptance before the decoder tries to decode properly. You are probably getting "glitches" inside the signal reception and the decoder can't decode it cleanly, so you are getting the usualt hickups in this case. Its smilar in any OTA and HD type receiver. This is the new wave of errors/artifacts for HD, unlike SD, where we would get analog noise. Its a new breed.

Still, it would be better if you had posted a short clip for more accurate determination of the error..a scene with from-to-bad-to-good would do. We need the complete cyle, not the perceived error.

Anyway.. .. ..

Here's my take on this whole nonsense.

That is more than likely correct. I mean, lets use directv as an example, they use mpeg4 (h264) as their program content format, for the simple matter that it is much more space savings, mpeg2 is gone--too much noise and easier to pixelate at pretty much all mpeg bitrate level setups. Anyway. When they broadcast it over air, it is in this format, (h264) but what determines or makes it a final format is the device or equipment it is to be received on.

For example, they currently have two standard in receiver models, one for SD and HD.

In the case of the SD receiver (i have their model R16 unit right now) it sends it in SD, but I suspect that for their HD receiver, because directv don't supply full hd on every channel, (some chan are SD only) there only choice is to send the signal in its original format and the customers unit do the conversion according to the units set limits or progam package. So, I suspect that some of these units (HD for example) convert to MPEG-2, in either TS or PS format container (I dont' know which one they use) at the home user's level, not at the broadcasters. These units get programmed to do all sorts of things, and its impossible to maintain 10 million ports with 10 million programm parameters for each 10 million customers. It is easier to program the customers unit to do the conversion.

So, that would mean that the units have onboard, decoder and encoder, where one decodes the original source comming in through directv pathway (satelite) and then, depending on the customers unit format (SD or HD) the program content gets re-encoded on-the-fly to the appropriate format. Since HD and standard is the current format, it will ultimately be converted to that format, in the mpeg2 standard but also wrapped in the latest continer being TS or PS, thus:

HD: directv[h264] -> [h264]receiver -> {convert to ts/ps} -> output -> ts or ps
SD: directv[h264] -> [h264]receiver -> {downconvert to SD 720x480} -> output

I would suspect that timer warner and others are following similarly. And this would undoubtedly explain why you have to have their cable box in most cases, because it has to do these downconvert to SD or (downconvert or convert) into an HD container, ts or ps.

However, in some cases, the source may already be completed converted to the final destination format, at the broadcasters facility, cable or time warner's for instanace, and all your boxes do is receive and broadcast, already in some Transport or Program stream format.

I know that OTA signals are already in mpeg2 (ts) format, but the boxes or receivers or capture cards in many cases take the ts and re-convert (re-wrap) it into a ps (program stream) container, for whatever the reasons. That's the mystery part, why--i don't know. Must be for DMR purposes, is all I can think of at the momnet, unless the ts main purpose was only to house multiple video formats as a standard, and the ps is the secondary to that but more closely suited for the mpeg2 source, i don't know for sure, but that could explain the reason for, ps.

So, for directv, in the case of their SD models, their is little conversions if any.

But in the HD, there is more conversions going on though not as lossy as you might expect in some. The conversion, in some cases are just re-wrappers expect for the mpeg-2 (ts or ps, depending on the model) so some re-conversions in that case.

feel free to add/correct/fill-in more details of what I just commented on

-vhelp 5350

[2Bdecided]

Assuming the Tivo saves the transport stream straight to disc, then it's either broadcast like that, or there are errors (bad signal, faulty demodulator, Tivo can't quite keep up, data errors during transfer to PC etc), or the decoder on your PC can't cope properly with that specific stream for some reason. You can trouble shoot some of these by simply watching the original recording on your Tivo - are these errors visible there?

They're quite subtle errors - it could have been broadcast like that, for various reasons.


I can't believe consumer boxes are re-encoding HD MPEG-2 on-the-fly. I'm prepared to be proved wrong (I live on a different continent, after all!) but that's some serious horse power.

Cheers,
David.

[lordsmurf]

Further upstream it may be H.264. I doubt the box is re-encoding HD, too.