QSF-induced Judder?

George

New member
#1
I recently burning an mpg file to a DVD, after editing it with VRD, when I noticed a "juddering" which seemed to be caused by the Panasonic player skipping frames consistently at a couple of specific points. I was surprised, because I'd viewed the unedited file, and hadn't noticed any juddering. I went back to the original and re-checked with several software players - no judder. I also found that one software player (Nero Showtime) also judders at exactly the same point on the VRD-edited file, so it's definitely not just an artifact from the DVD burning process.

Having carried out a lot of tests, the problem seems to be that QSF induces this juddering, whereas a simple "remux" (saving the original file without any edits) doesn't. QSFing the remuxed file doesn't judder, so it's something in the original file that QSF doesn't like.

I've tried VRD 479, 501, 512 and 602 and all exhibit the same problem. As far as I can tell, when QSF or remux are used on this file with "No Change" option selected for aspect ratio, judder always occurs. The only "safe" case seems to be remux, with 4:3 aspect ratio selected. There also seems to be some slight variation in behaviour between versions, though I haven't pinned it down exactly (these tests take a long time, and there are a lot of permutations).

I've tried looking at the output files using GSpot, but there don't seem to be any differences in GOP structure between the juddering and non-juddering versions.

Unfortunately, the source file is over 2Gb, and any attempt to cut it down seems to change the behaviour (even just brute-force truncation using dd), so uploading a "cut down" version doesn't seem possible.

This is quite a concern, since I've burned dozens of DVDs that I've entrusted to QSF, and when I've noticed similar problems on playback, I've put it down to defects in the original source. I'm coming to the conclusion that this might not be the case - QSF looks guilty in this case, even though it might just be triggered by something "strange" in the source file.

Has anyone seen anything similar, or have any suggestions (other than "always remux before QSF")?

Thanks,

George.
 

phd

Super Moderator
#2
We haven't heard of this issue.

Can you enable "Output Diagnostic Data To Log File" in Tools>Options>Stream Parameters

Clear the log file and try processing the file again through both QSF and remux and send us the log file as an attachment to Support @ VideoReDo.com

To clear or view the log file and save it to a new location for submission by email, click on the menu: Help>Display VideoReDo.log

Also include a reference to this topic number: 12874
 

George

New member
#3
We haven't heard of this issue.

Can you enable "Output Diagnostic Data To Log File" in Tools>Options>Stream Parameters

Clear the log file and try processing the file again through both QSF and remux and send us the log file as an attachment to Support @ VideoReDo.com

To clear or view the log file and save it to a new location for submission by email, click on the menu: Help>Display VideoReDo.log

Also include a reference to this topic number: 12874
I already have the "Output Diagnostic Data To Log File" enabled, and I've looked over the output, but can't see any meaningful differences.

I'll separate out the relevant sections from the log and send them to you, along with a summary of the tests that I've done.

Just a side-issue : VRD doesn't make a note of the program version in the log file when it starts processing a file, which makes it difficult to sort out which test is which (I have to rely on the file names). It does note the version number when the program is started initially, but if you have more than one instance of VRD running (but not actively processing), with different versions, I can't see any way to figure out which instance was used for any particular processing action.

Regards,

George
 

George

New member
#4
I've sent the log file and test schedule/results to support@videoredo.com.

For anyone else following this issue, here's are the highlights:

I ran 16 tests and forwarded the details and logs to VRD.

All of the tests are conducted on the same input file. The tests are split into 4 groups of 4. Each group consists of the following tests:
  • remux and output with unchanged aspect ratio
  • remux and output with aspect ratio 4:3
  • QSF and output with aspect ratio 4:3
  • QSF and output with unchanged aspect ratio

The 4 groups are as follows
C1-C4 - the 4 tests, in the sequence shown above, performed using a single instance of VRD, without closing VRD between tests.
C5-C8 - the 4 tests, in the reverse of the sequence shown above, performed using 4 separate instances of VRD, closing VRD between tests.
C9-C12 - the 4 tests, in the sequence shown above, performed using 4 separate instances of VRD, closing VRD between tests.
C13-C16 - exactly the same as C1-C4.​

Results are surprising -
Code:
						Version	Op	O/p Aspect	Behav	Chcksum	Length
The original source file - from TyTool (TyTool log shows no defects)								
		TestFile.mpg	Original					OK	40604	
	Note - repeated 8 times to check consistency of input							

These 4 tests carried out with a single instance of VRD (512), one after another, without closing VRD								
C1		TestFile.512.remux.NoChange.mpg	512	Remux	No Change	OK	50231	4032001
C2		TestFile.512.remux.4-3.mpg	512	Remux	4:3		OK	50231	4032001
C3		TestFile.512.4-3.mpg		512	QSF	4:3		OK	50231	4032001
C4		TestFile.512.NoChange.mpg	512	QSF	No Change	Judder	1102	4032001
								
These 4 tests carried out with individual instances of VRD (512), opening VRD, performing the operation, then closing VRD								
C5		TestFile.512.NoChange.mpg	512	QSF	No Change	Judder	53966	4032001
C6		TestFile.512.4-3.mpg		512	QSF	4:3		Judder	53966	4032001
C7		TestFile.512.remux.4-3.mpg	512	Remux	4:3		OK	50231	4032001
C8		TestFile.512.remux.NoChange.mpg	512	Remux	No Change	OK	50231	4032001
								
These 4 tests carried out with individual instances of VRD (512), opening VRD, performing the operation, then closing VRD								
Note that these tests (C9-C12) were carried out in exact reverse order of those in C5-C8								
C9		TestFile.512.remux.NoChange.mpg	512	Remux	No Change	OK	50231	4032001
C10		TestFile.512.remux.4-3.mpg	512	Remux	4:3		OK	50231	4032001
C11		TestFile.512.4-3.mpg		512	QSF	4:3		Judder	53966	4032001
C12		TestFile.512.NoChange.mpg	512	QSF	No Change	Judder	53966	4032001
								
These 4 tests carried out with a single instance of VRD (512), one after another, without closing VRD								
C13		TestFile.512.remux.NoChange.mpg	512	Remux	No Change	OK	50231	4032001
C14		TestFile.512.remux.4-3.mpg	512	Remux	4:3		OK	50231	4032001
C15		TestFile.512.4-3.mpg		512	QSF	4:3		OK	50231	4032001
C16		TestFile.512.NoChange.mpg	512	QSF	No Change	Judder	1102	4032001


Using Remuxed (50231) version as INPUT:								
		TestFile.512.4-3.QSF.mpg	512	QSF	4:3		OK	50231	4032001
In addition to noting that judder results from using QSF. it is very worrying to note that the output is different if a single VRD session is used to conduct the tests one after another, as opposed to closing VRD between tests. This is such an unexpected result that I double-checked this by carrying out tests C9-C16 to confirm it.

Hope you can make some sense out of all this, Pat and Dan.

Regards,

George
 

George

New member
#5
QSF-induced Judder - The Smoking Gun??

I've been doing a little digging...

This is an analysis of the "juddering" QSF'd file (checksum 53966), at the point where it's binary first differs from the "OK" remuxed file (the files are identical except for relatively few frames). This is the point where the first judder occurs.



There is a bit that should be a mandatory "1" is a "0", but this seems to occur throughout this and other VRD output.

However, the first bytes that differ from the "good" file form the letters "VRD$G_t".

These bytes are interpreted as vbv-buffer-size-extension=86, frame-rate-extension-n=2 and frame-rate-extension-d=2. These values don't occur anywhere else in the file (as far as I can see, they are always zero, other than here).

Could be coincidence, but it looks very odd. Any thoughts?

Regards,

George
 

George

New member
#6
I just tried zeroing the unexpected "VRD$G_t" string that occurs in the QSF'd output file using a hex editor.

Result - plays perfectly (at that point), where it juddered before.

Over to you, Pat and Dan.

Regards,

George
 

George

New member
#7
I've looked back through a lot of files that I've processed with QSF and found the same issue occuring in many of them.

QSF seems to insert the characters "VRD$" into the output periodically, causing "unexpected" values (vbv-buffer-size-extension=86, frame-rate-extension-n=2 and frame-rate-extension-d=2) to be set. It's not clear what exactly triggers this string to be output, but the input files seem to have valid values for these parameters at this point. This string isn't inserted when VideoReDo does a "remux" operation - only on a QSF.

When some software players (and my Panasonic DVD player) encounter this "VRD$", it causes a visible "judder".

Incidentally, I noticed that TMPGenc also inserts some "TMPGenc" text strings into its output, but this seems to be always at a point where it doesn't affect the playback. Is the "VRD$" intended to be a marker of some kind, that's been offset in some way so as to make it affect the video stream?

I'm kind of surprised that no-one seems to be reacting to this issue - it's affected a lot of files that I've processed and already burned to DVD.

Regards,

George
 
Last edited:

Danr

Administrator
Staff member
#8
George, Can you upload a short source file that contains the VRD$ in the output of a QSF. The VRD$ is temporarily inserted into the stream during internal processing but removed soon after and should never remain in the output file.

This is the first report we've had of this and I'm thinking that some wierd combination of events, QSF + your source files are triggering this.

BTW, what hex editor are you using that dumps the frame information?
 
Last edited:

bkh

New member
#9
George has done a really good job of investigating his output files. Impressive.

I did a quick check to see if this issue may be universal to all (in particular, I'm using TVS, not Plus). I ran a 6GB .mpg through QSF using TVS .579. Then I looked for VRD embedded in the file and got this:

arete$ strings qsf.mpg | egrep 'VRD'
$VRD
VRD*
ZC:68bVRD
FVRDE
VRD-
VRD$Z
VRDXB
})@VRD
%VRD
VRD-=h

This looks like 'random' binary to me, which I confirmed by running the original source .mpg through strings: the list of embedded 'VRD' was identical (i.e., no instance of 'VRD' was added by the QSF run, they were already present in the source file).

From this I would say that the TVS .579 version of VRD is not putting 'VRD$' periodically into the output of QSF, so George's issue isn't universal to all flavors of VRD. Unfortunately I no longer have VRD+ installed to do this simple check on that one....
 

Danr

Administrator
Staff member
#10
I agree George's work is impressive. The VRD$ which, as mentioned before, serves as a temporary placeholder is only inserted after a picture start code, x0 x0 x1 x0, and is followed by 8 bytes of timing information. After the timing is verfieid, the 12 bytes are removed. Any other occurence of VRD$ is purely coincidental as noted by bkh.

Now, the VRD$, if left untouched translates into a temporal reference of 345 and there is special code to account for that occurence, which is pretty rare. Both remux and QSF use exactly the same code path, so that's probably not the issue either.

I really hope that George can get a sample source file to us so we can investigate his findings here.
 

Danr

Administrator
Staff member
#12
Any update on this? I thought QSF is supposed to be lossless.
QSF is loseless, there's no recoding going on. I think we were waiting for a sample file. If you want to re-open this issue, we would be glad to look at it. Can you get us a sample that illustrates the problem?
 
#13
I have just started to run the trial version, so I have not run into this problem. But to hear someone has this issue makes me concerned that I could also run into it in the future.
 
Top