Repeated saves give different results

lennich

New member
Here's something that has me puzzled: I edit an MPEG-2 TS file and save it (again as MPEG-2 TS). When the saving is finished I get the usual box of info telling me about video resync frames removed etc.. If I immediately save the file again I get different numbers in the info box. I tried this on one file last night and saving it five times gave video resync frames removed ranging from 88 to 239.

This isn't just, or even, an error in reporting. The resultant output files are different sizes.

I don't understand why the output is not the same every time since nothing should have changed, even if it clearly has.

Cheers,
Len
 

Dan203

Senior Developer
Staff member
That is odd. Is there any chance that the drive the file is stored on is having trouble that could be producing read errors?

Dan
 

lennich

New member
That is odd. Is there any chance that the drive the file is stored on is having trouble that could be producing read errors?
Dan
There's no indication of that. However, I did a test tonight using a different source drive. This time I didn't do any edits on the file before saving. Same thing happened i.e. the numbers varied. I did a series of saves and sometimes the numbers repeated but not in a consistent way, at least not in a pattern that made sense to me.

After that I did a series of Quickstream fixes on the source with the same result i.e. the numbers varied.

Cheers,
(A still baffled) Len
 

Dan203

Senior Developer
Staff member
OK I'll do some more testing next week and see if I can reproduce the problem.

Dan
 
Here's something that has me puzzled: I edit an MPEG-2 TS file and save it (again as MPEG-2 TS). When the saving is finished I get the usual box of info telling me about video resync frames removed etc.. If I immediately save the file again I get different numbers in the info box. I tried this on one file last night and saving it five times gave video resync frames removed ranging from 88 to 239.
What happens if you close VRD after saving each time and then restart VRD and then save the file again. Do you get the same results?

Mike
 

lennich

New member
What happens if you close VRD after saving each time and then restart VRD and then save the file again. Do you get the same results?

Mike
The same sort of thing happens, if that's what you mean i.e.number of frames removed varies.

I tried some more experimenting today and the 'omit null packet' feature seems to be connected. I tried de-selecting this and my file saved without any re-sync frames being removed. The resultant file was ten times the size of the original. I then took that file and saved it with 'omit null packet' re-instated. No re-sync frames were reported to be removed but the file returned to a size close to the original (82 bytes shorter) and it looked OK on playback.

Len
 

Dan203

Senior Developer
Staff member
The Ommit Null Packets will always effect the size. Null packets stuff the stream with fake data so that it maintains a constant data rate equivalent to the mux rate setting. With that option checked you only get the real audio/video data. With it unchecked you get a bunch of 0s stuffing the stream which is why the file size is so much larger. Null packets are only necessary in broadcasting, so for local playback files you should always leave that option checked.

I'll try to run some tests today and see if I can reproduce your problem. If I can't then I may need you to send me a sample.

Dan
 

lennich

New member
I'll try to run some tests today and see if I can reproduce your problem. If I can't then I may need you to send me a sample.

Dan
I can certainly send an example file.

I've always used the 'omit null' option in the past but my workround, which so far has always worked, is first to create a file with nulls included, using the ATSC option (which I understand from the help file uses a different buffer setup from the other options). Since the actual rate is much smaller this 'intermediate' file is much bigger, as you explain. Anyway, taking this file as the source and saving with nulls omitted gives a (reported as) error free output of reasonable size. Without this intermediate step I get variable errors. Not using the ATSC option for the intermediate step also gives variable errors.

The files I'm editing are UK broadcast files if that helps.

Cheers,
Len
 

lennich

New member
I can't reproduce this so I'm going to need a sample. Can you please use Trim & Copy to grab a small chunk (<100MB) of the original file that reproduces this problem and upload it to our FTP...

http://www.videoredo.net/msgBoard/showthread.php?t=15807

Dan
Will do. Just to be clear: it's not just *one* file, it's *every* MPEG2 file from my recorder that shows variable errors on output if nulls are omitted. If nulls are included the errors are consistent (and vastly fewer - I'm assuming genuine). Once the file is saved with nulls I can then reload it and save without nulls without errors being reported.

Cheers,
Len
 

Anole

Moderator
If you click on (not copy) that link, it'll take you to a page showing how to upload to the FTP server.
I just checked it now. ;)
 

lennich

New member
If you click on (not copy) that link, it'll take you to a page showing how to upload to the FTP server.
I just checked it now. ;)
Yes, it was the first link from that page that threw me.

Anyway, now fired up an FTP client and file (STestUpload.mpg - 64Mb) uploaded to directory 'Lennich' so think that's what was required :cool:

Len
 
Last edited:

lennich

New member
I had a play with the file I uploaded. I loaded it then saved it five times as a TS file without nulls.

Video Resync Frames Removed: 265,546,337,291,399
Audio Resync Frames Removed: 436,901,556,476,656
Audio Resync Frames Added: 1,1,1,1,1

With the original file still loaded I saved it five times as a PS file. This time the output was consistent:

VRFR: 3
ARFR: 0 (I assume since not reported)
ARFA: 1

Since outputting as TS gives me the inconsistent results reported and using PS was consistent on the uploaded file, I tried saving a project with edits as a PS file. If that had worked I would then have converted that to a TS file, but it wasn't consistent. It's a long file so I only did it three times:

Input Sequence Errors: 113,113,113
VRFR: 104,354,274
ARFR: 108,527,387
ARFA: 2,4,7

I then fell back on saving as TS with nulls:

Input Sequence Errors: 113,113,113
VRFR: 65,65,65
ARFR: 87,97,95
ARFA: 37,47,45

I still don't understand why the numbers aren't the same on every save of the same type. I'd be tempted to re-install the software if I could find my key.

Cheers,
Len
 
Last edited:

phd

Super Moderator
If you're missing your key, write to me at support and I can send you a copy.

Please include the email address used to purchase.
 

lennich

New member
If you're missing your key, write to me at support and I can send you a copy.

Please include the email address used to purchase.
Many thanks for that. I was looking in the wrong place.

I'll give it a little longer. In the meantime I've had an 'Audio Ring Buffer Overflow' message a few times (when cropping). This terminates a save, naturally not near the beginning. :)

Can't find a reference to that in the help file but it does firm up my suspicion that buffer handling is at the heart of this.

Cheers,
Len
 

Dan203

Senior Developer
Staff member
An audio ring buffer overflow occurs for one of two reasons...

1) The muxing of the original file is bad and it's grouped too many audio frames together without interleaving video frames. We basically buffer both frame types until we receive a full GOP of video. So if there are too many audio frames before we receive a full GOP of video it can cause this problem. You can actually increase the size of the audio buffer to work around this problem in most cases. It's in the hidden Shift+Tools->Options menu, around #15 I think.

2) There is an error in the audio data itself that is preventing our logic from properly diving the audio data into frames. We have logic that breaks the stream of audio data into individual frames. Each audio type has it's own function which uses that audio standard to determine the end of one frame and the start of the next. If there are errors in the audio stream which cause false end of frames then it could create more frames in the buffer and overflow it. This one can sometimes also be fixed by adjusting the setting mentioned above, but it depends on how badly the audio is damaged.

Dan
 

lennich

New member
An audio ring buffer overflow occurs for one of two reasons...

Dan
OK. Many thanks for the full explanations. It's another odd one since the original file was QSFed, then edited and output as PS without a problem. It was only when I tried cropping that file that I got the error.

Since I'm getting these irritations I'm going to re-install the software. With a bit of luck the variable error problem will also go away. :)

BTW, all of this is not to say that I'm anything other than pleased with the program generally.

Cheers,
Len
 

lennich

New member
Has anyone looked at the file I submitted? If so to what effect?

Not a complaint, you understand, just an interested inquiry. :)

Cheers,
Len
 
Top Bottom