I am using DGDecNV 2036 and I noticed while encoding the Blu-ray version of Toy Story 3 that the frame count in the dgi file doesn't match the number of frames that x264 encodes. For example:
Oh, this report reminds me of .... when I did the stacked comparison of DGSource(deinterlace=2) with other bobbers, the GPU-bobbed stream was off by one frame compaired to all other filters which were fed by DGDecode_mpeg2source. Not sure anymore if it was one frame early or late, but off it was. (Encountered with the VOB sample I had uploaded.)
One frame of a bobbed stream means one field of the input stream, hence I assume it's not the source filter, but the deinterlacer.
neuron2 wrote:Load the AVS script in VirtualDub and do File/information. How many frames are shown.
Post a link to the complete DGI file.
I'll post the requested information tonight. Unfortunately I don't have access to the DGI file from work but I wanted to post so that you knew I was still following this thread.
Because POC=134 is missing I suppress 135 for display. Now the question is whether the file is really missing POC=134 or did DGIndexNV miss it. So please post a link to the last 50 MBytes of the source file.
Didée wrote:Oh, this report reminds me of .... when I did the stacked comparison of DGSource(deinterlace=2) with other bobbers, the GPU-bobbed stream was off by one frame compaired to all other filters which were fed by DGDecode_mpeg2source. Not sure anymore if it was one frame early or late, but off it was. (Encountered with the VOB sample I had uploaded.)
One frame of a bobbed stream means one field of the input stream, hence I assume it's not the source filter, but the deinterlacer.
That's a known quirk of PureVideo and not relevant here. But thanks for bringing it up as a possible theory.
Here ya go. I used DGSplit and set the chunks to 50 mb. The last file ended up being only 8.21 mb so I have zipped the last two files for you to investigate. Let me know if you need anything else.
Thank you for investigating the problem. I guess I need to spend a little time figuring out whether the problem is in the source or perhaps anydvd or eac3to caused the problem.
rack04 wrote:Thank you for investigating the problem. I guess I need to spend a little time figuring out whether the problem is in the source or perhaps anydvd or eac3to caused the problem.
So I can send a bug report to the appropriate person. They'll never know something is broken unless people report problems. Unless of course it is in the original stream.
Did you just cut the M2TS off the disk leaving the EOF completely intact, or did you demux or something? If it's a straight cut from the M2TS including the full EOF, then it's in the stream.