Are transcoding AV-sync errors caused by hardware or software?

[MarcMiller]

Hello
I purchased a computer television tuner which I love both for delay live television broadcasts and archiving television programs. The trouble is when I want to archive programs they are too large to archive very many programs because the file format is MPEG-TS at about 4.7 GB per hour. My computer isn't up to the task of transcoding to many of these files because it is too slow to do so. Consequently I am planning on building a new system as soon as the next generation Intel CPUs come out. My question now is will this hardware change stop the transcoding AV-sync errors which I get on some of the my present transcoding, but not all?

I recently transcode 2 files of about two hours duration of the PBS television program Woody Allen which came in 2 2 two-hour episodes. The first of these did not have significant AV-sync errors transcoding with FormatFactory from its 1080X1920 MPEG-TS to 1280x720 Matroska mkv file format. But the second did no matter what I tried like 2 pass transcoding at a higher bit per second rate or other transcoding programs altogether. So can I just bide my time by doing things like burning the expensive to burn large files until I am ready to make my CPU upgrade to a new computer system? Or is there things I should be figuring out about transcoding software right now?

[poisondeathray]

Usually transmission drop outs, recording errors, stream errors - part of the initial recording process, or due to the transmission end

The actual encoding process after it's been recorded doesn't affect sync. Changing #passes or bitrate or any other encoding parameter doesn't affect sync. Hardware used for encoding doesn't affect encoding sync after it's been recorded (even on a 10year old computer) - it will just be slower to get end results

Sometimes you can fix the errors with programs before you encode e.g. videoredo's quickstream fix

And sometimes you can fix the errors after, but you have to provide more details on the type of desync. eg. progressively worsening ? constant desync amount ? etc...

[MarcMiller]

And sometimes you can fix the errors after, but you have to provide more details on the type of desync. eg. progressively worsening ? constant desync amount ? etc...

Well on the second file I mentioned the synchronization error is definitely progressively worsening, but it is not noticeable if you leave the file in its original form and just watch it.

[poisondeathray]

Well on the second file I mentioned the synchronization error is definitely progressively worsening, but it is not noticeable if you leave the file in its original form and just watch it.

Progressively worsening means A/V lengths don't match. Usually from a dropout , discontinunity or "blip" or similar error. So it maybe in sync until that point, but after that point, either A/V isn't aligned, or they are different lengths

Quite common for original file to play in sync. The reason is transport stream contains timing information and recovery information with timestamps, so if a "blip" occurs, it can recover during playback, either by speeding up, dropping frames or similar techniques

But audio and/or video encoder will pause at that point, and there will be a desync point. The number of desync points can cause it to worsen at each point

The normal procedure is manually identify and edit those out , and resync the sections after the "blip". If there are lots of dropouts, it will be very tedious

Most people try repair software first, like videoredo's fix, or ts doctor or similar software, because it's way easier than manual fix

[MarcMiller]

Most people try repair software first, like videoredo's fix, or ts doctor or similar software, because it's way easier than manual fix

I've only taken a very quick look at the webpages of the two products you suggested, but neither looks like they definitely convert formats to a format which is much smaller than the original. So is this first impression wrong? And must doing the transcoding and synchronization error correction, be a two-step process or is there software that will let me just sit back and let the software do it all?

[poisondeathray]

Correct, those don't encode. The idea is to fix the stream with a 1 click application and then "sit back" with the encoding application if the fix works

But usually there is no sitting back. Encoding recorded transport streams are tough to get working because of discontinunities. Usually spend hours of manually syncing streams

You can try other encoding software, but likely result in same desync issues

[MarcMiller]

Encoding recorded transport streams are tough to get working because of discontinunities. Usually spend hours of manually syncing streams

I don't think I will often be ambitious enough to spend hours resynchronize in recorded videos, but if it happens that I record a file which makes me that ambitious where can I find out more about the whole manual resynchronization process?

[poisondeathray]

I don' t think there are any guides. It's a basic editing skill, something you do in a NLE (non linear editor) . There is no "recipe" . A lot of it is see what you have and make stuff up as you go. What you do depends on what the exact problem is

I should mention that I'm making a lot of assumptions here, and stating what commonly occurs, and the reasons why - there might be something else going on in your specific case. It might be worth trying other conversion software for example. Might be a lot of trial & error with this

eg. format factory is ffmpeg based, you might try something else non-ffmpeg based

But in my experience, from what you describe, the desync is probably caused by discontinunities. Look for parts that are pixellated, even for a split second. Those are the "blip" points

But progressive desync always means a A/V length mismatch. Theoretically, if you had no errors or "blips", you could just stretch/shrink either the audio or video to match. e.g. 1hr video, but 1hr 1second audio. If you shrunk the audio to 1hr it would match up the video exactly. This rarely happens in recorded streams, but it's a "dream" scenario , because it's so easy to fix. The more common case is the situation described earlier, where multiple points of failure cause multiple desync points. So you have to divide up and manually sync up, then rejoin

[MarcMiller]

Well how do you see/locate points of failure?

[poisondeathray]

Something like pixellated image , or picture slows then speeds up a bit as it recovers. Or it might be an audio glitch, or both.

If you look at the encoded desynced version, it's sometimes easier to identify the points there

If you certain you cannot find any glitches, figure out the lengths of audio & video, then you can either change the fps of video or shrink/stretch the audio to match in an audio editor. This dream scenario rarely happens

[MarcMiller]

Quite common for original file to play in sync. The reason is transport stream contains timing information and recovery information with timestamps, so if a "blip" occurs, it can recover during playback, either by speeding up, dropping frames or similar techniques

So does that mean it will always be possible to create a screen capture of the original file which will still be old digital in nature since a computer does everything digitally including right to the screen? And will this screen capture be completely resynchronize by the video player taking advantage of the features mentioned above?

[poisondeathray]

Quite common for original file to play in sync. The reason is transport stream contains timing information and recovery information with timestamps, so if a "blip" occurs, it can recover during playback, either by speeding up, dropping frames or similar techniques

So does that mean it will always be possible to create a screen capture of the original file which will still be old digital in nature since a computer does everything digitally including right to the screen? And will this screen capture be completely resynchronize by the video player taking advantage of the features mentioned above?

It's dangerous to use the word "always"

But yes it should work, if your hardware is up to snuff (you don't drop frames or insert dup frames). It won't be the same digital format. You wouldn't capture to a compressed final format (because risk of dropping frames), you would normally capture to a lowly compressed lossless format like huffyuv , edit, then encode to final format .

How did you record this? What format is it? use mediainfo view=>text & copy back the info on the source file
https://www.videohelp.com/tools/MediaInfo

[MarcMiller]

How did you record this? What format is it? use mediainfo view=>text & copy back the info on the source file
https://www.videohelp.com/tools/MediaInfo

I use the Hauppauge WinTV-HVR-2250 PC tuner. The info from
MediaInfo is

ID : 49 (0x31)
Menu ID : 1 (0x1)
Format : MPEG Video
Format version : Version 2
Format profile : Main@High
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : M=3, N=30
Codec ID : 2
Duration : 1h 29mn
Bit rate mode : Variable
Bit rate : 8 806 Kbps
Maximum bit rate : 19.4 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Active Format Description : Full frame 16:9 image
Frame rate : 29.970 fps
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.142
Stream size : 5.53 GiB (90%)
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

[poisondeathray]

were there any glitches you could see?

you can try non-ffmpeg method of encoding , maybe something like xvid4psp , or use dgindex with avisynth

a free way to fix mpeg2 streams is projectx (instead of videoredo, etc...)

[MarcMiller]

were there any glitches you could see?

No glitches I could see.

Thanks I will try come of those things.