magnatique
10th November 2011, 22:51
I have probably lost dozens of hours troubleshooting this + hundreds of hours re-encoding a ton of files so I figured I would post the information here in case it can help someone else :)
First, Info on the issue:
We usually encode a high quality 1080p x264 file (CRF12) that we use as backup/bluray/intermediary file for our web encodes. While I was authoring a dvd from those files, I noticed some weird noise on those, and in some instances I would have one frame, out of the blue and never at the same place, come up inverted, or in the wrong place (like from some frames before / after) so playback would sort of skip for one frame. I figured I'll update x264/ffvideosource and see if it would fix itself, which it did , or so I thought. (it's very hard to spot one frame that's bad out of a 20-30 mins long video, but it fixed the noise issues/color probs at the beginning of the scene I saw when encoding the mpeg2 files)
This week, one of our employee noticed one such bug again. since I had updated what I thought was the culprit, I re-encoded the scene and saw another inverted frame when playing it back. (see attached glitches.rar for an example of two consecutive frames being bogus)
So I figured I'll try to troubleshoot this once and for all. so I setup a test scene, I duplicated the avs into 4 different ones. 1 = original, 2 = without MT, 3 = Without FFT3DGPU, 4 with directshowsource instead of ffvideosource. I thought it could also be a hardware/software config, so I launched the tests on 5 encode boxes, all files copied locally to rule out network issues. I made 3 different encodes of each test avs to be sure as it is a random bug and not at the same frame .
When it came down to verifying the scenes, I started playing back the scenes and watching carefully. I thought the bug would usually happen in the first minute, so I started watching the first 2 mins of each file. that's 5 boxes x 4 different sources x 3 per sources = 60 files to verify. at 20 mins per scene, that would have been 20 hours of constant playback looking for a bad frame. That's what I call a needle in the hay sack :)
Second, Troubleshooting the issue
Now I'm not a very patient person... so I watched 2 files x 2 mins and stopped.
I figured these two files don't have bugs, I'm not going to waste time on this ... spotting a bug by "chance" is not very effective.
so I figured I might just think for a sec and find a more scientific approach. Now I'm not so bad at learning how people do things and replicating them, but I am definitely not advanced as the good people from these boards. I know just how powerful avisynth can be and what some of you do with new plugins and sometimes I cannot stay up to speed with you guys... so my method might be a hack of something already implemented, or there might be an easier way to test a source with the encoded version to spot errors... but this is what I came up with ...
I figured if we take the frame from the source and the frame from the encoded version and subtract one from the other, the result should be close enough that it'd give constantly a grey image. now on the other end, if it doesn't match like an inverted frame or a frame from 10-20 frames ago/forward, the subtract result would show considerably more details than the other subtracted frames. by exporting all frames to jpg, I would only need to sort by size and the larger thumbs would show when there would be such a bug/issue.
For this task, I have coded a simple .bat. it searches the directory where it's at, replaces 1920,1080 by 160,90 for a faster export / smaller image size. then it creates a temporary file which loads the encoded file (same name as avs file), subtract, then loads image writer. Finally the .bat saves the new temp file and creates another .nat that launches x264 with a --preset ultrafast -o NUL to export each frame to jpg.
In case someone finds it useful, I have attached the batch file. please note it's using my file structure and pointing to my own paths, which you can modify at the top. also the way I write my avs scripts permitted me to do it the way I did, so it might not be an out of the box solution for everyone... but still here are the batch scripts :)
[BTW, if someone has an idea on how I could script such a test to compare source/encoded version automatically upon completion of mp4 encode in order to trigger an automatic re-encode (or at least notification if bad), let me know I'd love to hear about your ideas].
What the problem was
Well, turned out ALL of my files were bug free in my test... but at least I didn't lose 20 hours watching them for no reason :)
having this way to quickly see bugs, I reduced my sample to a minute sample. I'm not going to go in details on all the steps I did as this post is already long enough... But bottomline is this :
The culprit was Remote Desktop and FFT3DGPU. knowing what it was I found a post about RDP in the fft3dgpu thread causing an error, but this instance doesn't cause errors.
If a computer is encoding a file and removing noise with FFT3DGPU, minimizing RDP WILL cause these discrepencies. not always mind you, not at the frame where it's encoding exactly (more like 20 frames ahead in my experience) but it does. For example if you want to replicate the issue, encode a sample and while it's encoding quickly minimize, maximize, minimize, maximize the rdp window and it will create these issues in the resulting mp4.
the same thing happens if someone disconnects the RDP session from you. On the other hand, if the RDP session is maximized, it will not do this.
For example a solution I found that works for us is to first RDP to an intermediary server. in our case, our win 2008 server. then from there, I'll launch a RDP to our 5 encode boxes. I'll launch encodes on these 5 boxes and I'll show the windows side by side. If I then close the win 2008 session or minimize it, it doesn't affect encoding on those other boxes.
I saw a post about VNC being a good alternative as well.
Also, if anyone has suggestions on other noise removal tools I should test and look into, let me know I am trying to update all my scripts since I'm in testing mode ;)
First, Info on the issue:
We usually encode a high quality 1080p x264 file (CRF12) that we use as backup/bluray/intermediary file for our web encodes. While I was authoring a dvd from those files, I noticed some weird noise on those, and in some instances I would have one frame, out of the blue and never at the same place, come up inverted, or in the wrong place (like from some frames before / after) so playback would sort of skip for one frame. I figured I'll update x264/ffvideosource and see if it would fix itself, which it did , or so I thought. (it's very hard to spot one frame that's bad out of a 20-30 mins long video, but it fixed the noise issues/color probs at the beginning of the scene I saw when encoding the mpeg2 files)
This week, one of our employee noticed one such bug again. since I had updated what I thought was the culprit, I re-encoded the scene and saw another inverted frame when playing it back. (see attached glitches.rar for an example of two consecutive frames being bogus)
So I figured I'll try to troubleshoot this once and for all. so I setup a test scene, I duplicated the avs into 4 different ones. 1 = original, 2 = without MT, 3 = Without FFT3DGPU, 4 with directshowsource instead of ffvideosource. I thought it could also be a hardware/software config, so I launched the tests on 5 encode boxes, all files copied locally to rule out network issues. I made 3 different encodes of each test avs to be sure as it is a random bug and not at the same frame .
When it came down to verifying the scenes, I started playing back the scenes and watching carefully. I thought the bug would usually happen in the first minute, so I started watching the first 2 mins of each file. that's 5 boxes x 4 different sources x 3 per sources = 60 files to verify. at 20 mins per scene, that would have been 20 hours of constant playback looking for a bad frame. That's what I call a needle in the hay sack :)
Second, Troubleshooting the issue
Now I'm not a very patient person... so I watched 2 files x 2 mins and stopped.
I figured these two files don't have bugs, I'm not going to waste time on this ... spotting a bug by "chance" is not very effective.
so I figured I might just think for a sec and find a more scientific approach. Now I'm not so bad at learning how people do things and replicating them, but I am definitely not advanced as the good people from these boards. I know just how powerful avisynth can be and what some of you do with new plugins and sometimes I cannot stay up to speed with you guys... so my method might be a hack of something already implemented, or there might be an easier way to test a source with the encoded version to spot errors... but this is what I came up with ...
I figured if we take the frame from the source and the frame from the encoded version and subtract one from the other, the result should be close enough that it'd give constantly a grey image. now on the other end, if it doesn't match like an inverted frame or a frame from 10-20 frames ago/forward, the subtract result would show considerably more details than the other subtracted frames. by exporting all frames to jpg, I would only need to sort by size and the larger thumbs would show when there would be such a bug/issue.
For this task, I have coded a simple .bat. it searches the directory where it's at, replaces 1920,1080 by 160,90 for a faster export / smaller image size. then it creates a temporary file which loads the encoded file (same name as avs file), subtract, then loads image writer. Finally the .bat saves the new temp file and creates another .nat that launches x264 with a --preset ultrafast -o NUL to export each frame to jpg.
In case someone finds it useful, I have attached the batch file. please note it's using my file structure and pointing to my own paths, which you can modify at the top. also the way I write my avs scripts permitted me to do it the way I did, so it might not be an out of the box solution for everyone... but still here are the batch scripts :)
[BTW, if someone has an idea on how I could script such a test to compare source/encoded version automatically upon completion of mp4 encode in order to trigger an automatic re-encode (or at least notification if bad), let me know I'd love to hear about your ideas].
What the problem was
Well, turned out ALL of my files were bug free in my test... but at least I didn't lose 20 hours watching them for no reason :)
having this way to quickly see bugs, I reduced my sample to a minute sample. I'm not going to go in details on all the steps I did as this post is already long enough... But bottomline is this :
The culprit was Remote Desktop and FFT3DGPU. knowing what it was I found a post about RDP in the fft3dgpu thread causing an error, but this instance doesn't cause errors.
If a computer is encoding a file and removing noise with FFT3DGPU, minimizing RDP WILL cause these discrepencies. not always mind you, not at the frame where it's encoding exactly (more like 20 frames ahead in my experience) but it does. For example if you want to replicate the issue, encode a sample and while it's encoding quickly minimize, maximize, minimize, maximize the rdp window and it will create these issues in the resulting mp4.
the same thing happens if someone disconnects the RDP session from you. On the other hand, if the RDP session is maximized, it will not do this.
For example a solution I found that works for us is to first RDP to an intermediary server. in our case, our win 2008 server. then from there, I'll launch a RDP to our 5 encode boxes. I'll launch encodes on these 5 boxes and I'll show the windows side by side. If I then close the win 2008 session or minimize it, it doesn't affect encoding on those other boxes.
I saw a post about VNC being a good alternative as well.
Also, if anyone has suggestions on other noise removal tools I should test and look into, let me know I am trying to update all my scripts since I'm in testing mode ;)