Shrink playback at x2 is visibly sometimes not as good as original at x2

[Luke]

I’ve been running shrink against the worst offenders for waste of disk space.
For most of them everything appears fine, but there is one recording which is an exception
When I watch that shrunk recording at normal speed or x4 everything is fine. When I watch it at x2 speed it has black pixelation every few seconds, a bit like a borderline signal but black instead of coloured in the pixelated blocks.
The original recording is OK. Not that it really matters to me as if I watch in a fast mode I use x4 or x8. This are foreign films with hardcoded subtitles in the video image. I rarely need to slow down to x2 to read the subtitles, but I am curious about what has occurred here.

The recording was from the d3&4 mux which I have never had an issue with since DSO.
But just to check I put the original recording through ffmpeg converting the MPEG Audio Version 1 Layer 2 to WAV. It came up with 4 errors in the 70 minute recording. This showed that the mux isn’t quite as rock solid as I had previously thought.
To double check that there is not something wrong with that HDR/HDD that did the shrinking I also shrunk the recording using another HDR/HDD. The pixelation in both shrunk files match exactly.

I am presuming that the video stream for the recording will also contain other minor errors.
But why does it only show up on the shrunk file in x2, when viewing is fine on the original file at x2 and the default speed?

 

[af123]

I'm afraid I have no idea. The shrink process has to patch up the .nts file so that the frame numbers tie in with the right byte positions and this .nts file is instrumental in supporting trick play and FF/REW functions so I suspect that the process is introducing a mismatch somewhere here but I can't explain why it only shows up at x2.
It would be worth running the original file through the crop process and seeing if it exhibits the same problem. The crop process shrinks the file as a side effect but uses code written by Drutt rather than be me.

 

[Luke]

OK. I'll try that but it might have to wait until Boxing Day.
I'm after cropping and shrinking some Olympic red button stuff. So ideally I want to keep it his pristine as possible even if I can't see the difference! I think I recorded most of that on a grouped aerial so in theory most of it could be better quality at the micro level compared to the recording where the x2 artefacts were obvious.

 

[Black Hole]

Quantum video recording! Like it.

 

[Drutt]

Could the problem videos by any chance be timeshift recordings, ie where you retrospectively rewound to the start and then hit record? The nts files of these were a lot harder to piece together than normal recordings.

As af123 says, the .nts is used by the humax for quick random access into video (basically containing a file offset for every time frame), If the offsets are slightly wrong, it doesn't effect normal playback quality, as once past the initial lookup, its just playing the frames sequentially from the stream. The fact that only 2X is causing trouble implies that most of the fames match up - I wouldn't be surprised if at 4X+ it only displayed keyframes, so it maybe that the lookups to these are ok, but intermediate frames are not. If it was the mpeg stream being corrupted by shrink, I think you'd see significant errors in playback.

Be interesting to see whether you get the same problems with a crop (ie nicesplice), as af123 and I worked out the algorithms together, but have our own code implementations. From the command line you can use nicesplice to just shrink the file without any cropping. nicesplice -in [infile] -out [outfile] should do it. In theory this should do the same as shrink.

 

[Luke]

Could the problem videos by any chance be timeshift recordings, ie where you retrospectively rewound to the start and then hit record?

Bar one they were all from timers. The one which made me notice was from a timer, and there is 0% chance of me being mistaken for that one.

CFrom the command line you can use nicesplice to just shrink the file without any cropping. nicesplice -in [infile] -out [outfile] should do it. In theory this should do the same as shrink.

It did do some cropping as I’d left in the bookmark at the end of each advert break.
The pixelation is 100% identical to shrink. Fortunately it left in the segment where I now know the pixelation intimately.

If I put it though AVT2HDR-T2 first might that end up with a different result? In fact I could put it through AVT2HDR-T2 and see if without any further processing x2 is still OK. I’m working long hours the next 4 days and so that may have to what until Sunday.

If I can find time, and this will have to wait a few weeks, I'll:

• make a recording on a group aerial pointing towards the transmiter (! don't ask) on what appears and should be a good channel
• make a recordng via a wideband not pointing in the correct direction with a suitable channel that I know is near the cliff edge and I would expect the HDR would have to cover up imperfections.

Then I'll see what the outcome of shrinking the two files is. If imperfections in the receiption is triggering the issues with the internediate frames then on one file I should have great difficulty finding anything wrong and with the other one it should be very easy.
I'll also create and process a third recording. This will be as good a recording I can set-up but have metadata similar to the second of these three recordings.

 

[Luke]

The black pixalation on X2 is not due or aggravated by a weak signal.

In the end I used a group aerial on one HDR and a poorly positioned indoor aerial on a 2nd HDR (strength 10% quaility 70%). Both HDRs were tuned to the same transmitter. The black pixalation on X2 was identical. I would like to do some parallel recordings from different transmitters, but have some other priorities.

I run a pre-shrunk recording through AV2HDR-T2. This was one of the recordings which produced black pixalation on X2 after shrinking. The output of AV2HDR-T2 played on an HDR fine in X2 without any black pixalation.

So far I have not been able to predict which shrunk recordings will have a noticeable black pixalation on X2.
That's a pity as I wanted to use nicesplice on some Olympic recordings, and it would have been nice to have full flexibility on playback. The few I have put though any black pixalation is hard to find but I may have been just lucky on those.