Beware unwanted side-effects of SHRINK

fenlander

Active Member
For some time I've been trying to track down the cause of some issues I have with manipulating Hummy .ts files and have now discovered (I think) a possible trouble maker lurking in the tool box.

As I have written in other threads, I often edit files to remove ads and transfer them to my NAS library. To do this I use Avidemux for editing the .ts file. The .ts files, shrunk and decrypted, are downloaded to the pc for processing and saved - until recently - using the mkv output option in Avidemux. The video and audio streams are saved as copies, without recoding.

I began to notice a small problem with the mkv files. When jumping to different points in the file, there was always a double-flash, a screen glitch of some sort. I also found that these files often could not be reliably opened by Handbrake. When I switched to using the mp4 container in Avidemux the video glitch disappeared and the files appear to open correctly.

Now Handbrake. I have found this to be a useful tool, but when used with files from the Hummy, raw or edited, ts, mp4 or mkv, the sound output always slips further and further out of sync as the file plays. For completeness, I should add that I am using Intel QSV to encode.

Here's the kicker. Working through the variables that might cause these behaviours, I reached the point where I tried turning off recursive auto-shrink on the Hummy. The initial result suggests that this has eliminated the visual glitch when jumping within files converted to mkv and the sound-sync drift in files recoded with Handbrake. I haven't repeated this process sufficiently often to be able to claim a definite result just yet, but if other users have encountered similar issues to myself, please try removing auto-shrink and see if things improve.

I can't remember who originally authored the shrink code but if you're out there and reading this, it would be interesting to know if you can suggest any reason why shrink might have the side effects I describe.
 
I can't remember who originally authored the shrink code but if you're out there and reading this, it would be interesting to know if you can suggest any reason why shrink might have the side effects I describe.
That would be me. Shrink removes packets from the .ts file and also updates the associated .nts file so that it doesn't go out of sync. Looks like you've found a bug in this somewhere.
 
When manipulating files off the box, only the .ts file is involved. If there is essential sync data in the .nts file, that could be the problem.
 
Back
Top