Output image screwed up on iOS4.* about gpuimage HOT 21 CLOSED

I'm not seeing this with still images or with input movie sources on my one 4.0 test device here using the latest code in the repository. Unfortunately, I don't have a 4.0 device with a camera, so I can't test the live video input. However, disabling the iOS 5.0 texture caches manually on my 5.0 device seems to produce clean output.

What camera (front, rear), capture resolution, and filter are you trying to apply that is triggering this? Are you sure that you're using the latest code from the repository?

from gpuimage.

You were right. It's only when I'm rotating. I have this code:
GPUImageRotationFilter rotationFilter =nil;
AVURLAsset *inputAsset = [[AVURLAsset alloc] initWithURL:orig options:nil];
AVAssetTrack track = [[inputAsset tracksWithMediaType:AVMediaTypeVideo] objectAtIndex:0];
CGSize size = inputAsset.naturalSize;
if (!CGAffineTransformIsIdentity(track.preferredTransform)) {
//portrait
rotationFilter = [[GPUImageRotationFilter alloc] initWithRotation:kGPUImageRotateRight];
[rotationFilter addTarget:filter];
[movieFile addTarget:rotationFilter];
size = CGSizeMake(size.height, size.width);
}
else {
//landscape
[movieFile addTarget:filter];
}
To determine if the orig video was takin in portrait or landscape and rotate/change the size I send in for the output file.

PS: just pulled 5 mins ago to make sure. it's an ipad2 with the rear facing camera.
PPSL ios 4.3.5

from gpuimage.

Try this now. I've adjusted how filters and framebuffers are resized on removal and addition of other filters. I don't see any issues on my test devices, but none of them with cameras are running iOS 4.0.

from gpuimage.

Now it's messed up regardless of if it's rotated or not. If you want I can give you a link to a messed up video or a still.

from gpuimage.

btw, this is my last issue before publish ready^^ ... do you want any sort of mention in the app?

from gpuimage.

I was doing some work on the video encoding while I was adding the audio recording functionality. Perhaps that messed things up. However, things still seem to process correctly on my iPad running 4.2.

You say this occurs for your movie, no matter if it is rotated using a filter or not?

Don't worry about any mention or credit in the application.

from gpuimage.

Correct I'm still using the above code/hardware. The "filter" object is a GPUImageFilter that I polymorph basic on a button selection and then that code about will rotate the movie if it sees that it's portrait, and just use the filter selection otherwise.

Well, I'll let you know when it releases so you can try it out^^

from gpuimage.

I think I have some similar results on higher resolution (1280x720 @30fps) footage (all test were with footage loaded from roll ). I have uploaded an example of this on youtube (youtube.com/watch?v=CiKDzXg4Mos), I've used saturartion and vignetting filter in the same run. The artifacts are most noticable at the left side in the frame, it looks like certain render buckets from openGL are out of sync with the rest of the image. I dont see this artifact on 640x480 with the same filtering, also it doesn't appear all the time at the 1280x720 footage. At first I thought it had to do with the framerate I used some 24 fps stuff for my tests but I guess its unrelated?

Some questions:

• This movie from camera roll processing is not timing critical? (The source movie is already recorded)
• The AVAssetwriter just takes a frame whenever it is ready from the opengl framebuffer?

Also as I've read in another issue thread is the first black frame. I've seen in all my tests (all from movies from the roll) up to now that the first frame is partially or completely black. No matter if its 640x480 or 1280x720 pixels. Could it be that you dont't start the first frame not at kCMTimeZero?
Anyway thanks for your work Brad, it's really inspiring for me to see the things you created!

Regards Jeroen
Appjuice.com

from gpuimage.

Jeroen, was that recording on iOS 4.x or 5.x? I use a different capture path for both, and I'd like to look at the appropriate part of the code to see what triggers this.

You're definitely seeing some of the tiles from the tile-based deferred renderer of the iOS devices there, and it looks like the processing is only getting a portion of the way through the frame before that frame is grabbed. A larger frame might be causing this due to it being a little slower to process. A strategically placed flush of the scene might help here, but again I need to know if this is the 4.x or 5.x capture pathway to start debugging this.

from gpuimage.

That was on an Iphone 4S running iOS 5.1

from gpuimage.

Brad at one point or another you talked about disabling the fast texture cache for ios4 and I just assumed that the lib would check at runtime and disable it automatically, but is that true? I still haven't been able to figure this out. Hopefully tomorrow I can throw together a simple repeatable test case and will throw it up here on github so you can see if you can reproduce it on your iOS 4 device... I'm sure it's something simple, but I'm lost, so if you wouldn't mind I'll link it here when I get it up.

from gpuimage.

Yes, this capability is detected at runtime and enabled or disabled appropriately. Otherwise, it would throw an error and crash on iOS 4.0 devices.

For testing on my iOS 5.0 devices, I can manually disable the texture caches (by returning NO from GPUImageOpenGLESContext's +supportsFastTextureUpload method).

Note that your test case would need to come from a movie source, since my iOS 4.0 test device is an iPad 1, which lacks a camera. I'm trying to get an iPhone 3G S running 4.x to test against, but I don't have a camera-enabled 4.x device yet.

from gpuimage.

Gotcha, I'll keep that in mind.

from gpuimage.

Matt, try the latest recording code. I just got my hands on an iPhone 3G S running iOS 4.1, and I've been testing with it. I fixed an issue where the movie frames weren't being properly flushed on iOS 5.0, and tweaked one or two other recording options. When I try the SimpleVideoFilter sample on the 3G S, it records video without the artifacts you observed, so this might be fixed.

Jeroen, try the movie encoding now. I added a glFlush() before the reads from the fast texture caches when recording. I believe these were being read from while OpenGL ES was still writing to them, leading to the tile artifacts you observed. I saw none of that in my testing on my iPhone 4S running iOS 5.1.

from gpuimage.

I tried it and it didn't seem to change anything... :-/

from gpuimage.

OK, then I really need some sample code that exhibits this on 4.x, because I just can't make this appear in any of my examples on my new 4.1 test device.

from gpuimage.

Hello Brad, I'm not to savvy with git but I just downloaded the code as a zip, is that automatically including the latest commits? Anyways this new zip works pretty good on my phone at least for my first tests, not only is the issue of first frame :black frame fixed but also the render glitches appear to be gone, thank you!!

from gpuimage.

Good to hear it. Yes, the .zip file should automatically pull in the latest code. From what you described, it sounded like you were seeing some overlap from tiles in the previous frames, so I figured that the glFlush() I added in before each frame was read should synchronize things.

If you encounter any cases where this still glitches out, let me know and I'll look into it a little deeper.

from gpuimage.

I haven't been able to reproduce this on any other device or in my test code so even though all I did was copy and paste the relevant code. So I'm going to just close this...

from gpuimage.

If you do get it to break reproducibly again, let me know. There's probably something still wrong in there, but we have to figure out how to expose it.

from gpuimage.

Will do! Thanks anyways!^^

from gpuimage.