The maths of video resync errors

cp2

Member
i am currently running 822a.
I edited a file to remove adverts but 25 video resync errors were reported.
So I ran the file again but this time using the split scenes option so that I could see which of the 5 sections that I had created contained the errors. Usually I would get a four green and one yellow return indicating that there had been an error in just one of the sections. This time I got 25 errors in each section.
I did go back to 819 and got the same outcome at which point I stopped.
What I can't decide is whether this is "new math", a characteristic of this particular file or a bug. I am now waiting for another file with errors to see if I can reproduce the error.
 

cp2

Member
I've just processed another file in the same manner and got a total of 2 video resync errors. The split scenes options showed that 2 of the 4 sections had one error each. Traditional maths has prevailed and VRD seems capable of processing a file logicailly.
Apart from crossing my fingers and hoping that it doesn't happen again I'm at a loss as to what else to try.
 

Dan203

Senior Developer
Staff member
It's possible it's caused by the audio and not the video. What format was the audio on the original file that had the weird math? Was it AAC LATM?
 

cp2

Member
It's possible it's caused by the audio and not the video. What format was the audio on the original file that had the weird math? Was it AAC LATM?
No, AC3:
Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Format settings, Endianness : Big
Codec ID : A_AC3
Duration : 45 min 32 s
Bit rate mode : Constant
Bit rate : 384 kb/s
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 spf)
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 104 MiB (8%)
Language : English
Service kind : Complete Main
Default : Yes
Forced : No

The broadcast is sourced from a sattelite tuner card in my PC. Unfortunately this is the after VRD information though I didn't tweak it in any way apart from converting the video from H264 to H265! The errors were all reported in H264 Intelligent Recode mode. If it happens again I'll hang on to the H264 files.
In case it helps this is the audio from a similar recorded file (same tuner, same channel, part of same series) that I haven't processed yet.
Audio
ID : 2310 (0x906)
Menu ID : 55271 (0xD7E7)
Format : AC-3
Format/Info : Audio Coding 3
Format settings, Endianness : Big
Codec ID : 6
Duration : 1 h 7 min
Bit rate mode : Constant
Bit rate : 320 kb/s
Maximum bit rate : 42.5 Mb/s
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 spf)
Bit depth : 16 bits
Compression mode : Lossy
Delay relative to video : -868 ms
Stream size : 156 MiB (4%)
Language : English
Service kind : Complete Main
 

Dan203

Senior Developer
Staff member
That frame rate is really odd. Can you open the file in MediaInfo and post here? I want to see what it thinks the frame rate is
 

cp2

Member
My previous post included an extract of the MediaInfo file but I will post the full MediaInfo.
Just to emphasise, this is not from the actual problem file - that's gone - but of a same source, same recording approach file. I've processed over 70 of these files over the past few months without the problem I encountered this time round.
I realised that I had another version of the problem file - same satellite broadcast but a different transfer route into my PC - and that transferred without error. So, the original broadcast was blemish free.
On reflection I think that we should close this as an issue unless it happens again, in which case I will hang on to the original files and processing data.
 

Attachments

Dan203

Senior Developer
Staff member
I didn’t notice you were posting just the audio portion. I thought that was the video frame rate when it said 31.25fps that's why I was confused. And my original theory about the audio doesn’t apply to AC3 so honest I have no idea why you'd get that issue. I still think it has something to do with frames being thrown out at the start/end of each segment, and that's why it wasn’t there in the full output version, but I can’t explain exactly why that would be. Just keep in mind that "split" option isn’t actually splitting the file up like it's name suggest. It's basically a macro that's outputting each segment as it's own file using the full Save routine. So the numbers are guaranteed to line up like you're expecting.
 

cp2

Member
Hopefully this will be a one off occurrence driven by a number of clashing circumstances that will not occur again. Yes, I do feel that there is something funny going on here but unless it happens again there is nothing that can be done.
 
Top Bottom