PDA

View Full Version : Shouldn't SE render what it shows?


Verlon
08-02-2008, 10:59 PM
I am working on a little superhero flight video for the amusement of my son.

It involves using some rather simple stuff, but he likes it. So I have a couple of clips of him with the background removed saved as *.tif files with alpha channel enabled.

I am placing these over regular video. In one case, it works like a charm. In the other, SE does not render the video underneath (*.avi uncompressed).

It displays just fine in the SE output window, but the render doesn't work. It just renders the *tif file for the duration of the video clip (even though the tif is hsorter than the video clip.

Strangely, I did another video the same way earleir today generating the video clip in the same program with the same settings (all shot with the same camera on the same day).

Seattle-HotShot
08-03-2008, 12:07 AM
WYSINWYG?
what you see is NOT what you get? Yeah, I run into that sometimes too.
Recent example, I had a project where I was mixing some 720P footage and 1080i footage. I needed a text caption, so I just created a quick PNG in a paint program, with alpha. not thinking, I made the caption 720x480, because that was the size I had used last time... anyway, on the SE preview, I had the text caption where I wanted it. On rendered out put, the text shifted and scaled. Glad I caught it before I encoded and burned a DVD.

I've quit using SE's character generator for the same reason. Its wrong more than its right for me. I think it defaults to SD vs HDV resolutions internally?
Carlin in Seattle

bbeanan
08-03-2008, 05:25 PM
I had a simular problem usig a Digital Jucie MDE right from the DVD.... it is a quicktime with Alpha... when placed on the time line and previewed all is fine looks great... Render it our and all I get is a black box where the Digital Jucie element should be...

ted
08-03-2008, 08:17 PM
Brett, we just discovered an odity with overlays not playing or rendering as expected. This started when we got a new GFX designer.
When he would drop his GFX out of "After Effects" onto VT-SE we would just get black. If we let BG or Force render compete, the overlay looked perfect.
Then we found that if you rendered the video with that file you would get black on the portion that had that GFX overlay.

Turned out if he let the After Effects GFX "pre-render" (I think), the file would give us no problem. We found out by accident. :) Both actual renders were identical. Something must be written to the file by doing the pre-render.
I wonder if there is a commonality between applications.

Jim_C
08-03-2008, 08:23 PM
I wonder if there is a commonality between applications.

Yes. Speed Edit.


:hey:

bbeanan
08-03-2008, 08:56 PM
Yea I ended up re-rendering the Digital Juice elements as RTVs with alpha at the same resolution as my project and it worked...
My element was like 1500 X 1500 pixels (spinning globe) I was thinking it may be due to the non-standard size??

It would be much nicer to just use the elements right off the Digital Jucie DVDs like every other editing system does... (not to mention it would have saved me like 20 minutes of rendering in Jucier)

Verlon
08-04-2008, 12:31 AM
The only commonality I see is SpeedEdit.

I shot from a Sony FX7. Captured with SE.

The tif was created in photoshop 7, and worked fine before in SpeedEdit.

SBowie
08-04-2008, 08:27 AM
Which Quicktime codec were the original DJ graphics?

bbeanan
08-04-2008, 09:27 AM
If I goto the Movie Inspector in Quicktime is says:
PNG, 1500X1500 60 FPS

You can download a free sample of one of the elements here:
http://www.digitaljuice.com/dj_downloads/detail.asp?page=1&sortby=&display=video&downloadid=76

SBowie
08-04-2008, 02:51 PM
Thanks Brett. That'll help me do a little testing.

John Perkins
08-04-2008, 03:47 PM
The clip you linked to isn't readable by SpeedEDIT, it uses JPEG2000 compression.

If someone will send me clips that are causing the problem I would like to look into the problem though.

Thanks,
John

ted
08-04-2008, 04:28 PM
I think we are talking about different things. But in our case, if we did a ram preview in AE before rendering it, the file worked fine on VT-SE. If we didn't do a ram preview we had all sorts of issues as described above.

Verlon
08-04-2008, 04:47 PM
Unfortunately, my files were avi uncompressed as I was trying to minimize impact of bouncing through applications. I could send it, but it would be gigantic.

I DID manage to narrow it down to the video clip, and not the tif image. At first I thought it might have to do with the alpha. When I tried rendering just the video, I got a black screen except for the last frame.

So...

Captured HD footage with SE and rendered avi uncompressed.

Processed in Visionlab Studio from www.fxhome.com, and rendered avi uncompressed.

Brought back to SE, and it would work with the video, but not render it.

loaded SAME video from Visionlab into Pinnacle Studio and rendered avi uncompressed.

Loaed video from Pinnacle, and all worked fine.

If you like, I can attempt to recreate the problem on a really short clip, but anything avi uncompressed is going to be really big. a handful of seconds is going to be in the gigabyte range.

Verlon
08-04-2008, 04:49 PM
oh, everything was 1440*1080....

tried interlaced and progressive.

ScorpioProd
08-04-2008, 08:06 PM
Yup, as John said, the clip that the link goes to is JPEG2000 compressed. I'm surprised, I didn't know DJ was using that compression codec.

SpeedEDIT won't be able to handle that till it switches over to fully using the real QuickTime in the future. (The clip did work in Vegas, I figured I should check that as well.)

BTW, John, how can one send you problem clips anyway? I was trying to help debug a problem for you a couple weeks ago, and I needed to send a rather large file to tech support. Needless to say, it bounced since you're e-mail server is very restrictive on file size.

So I asked the tech for a ftp site, and I was quite shocked to hear that you guys do not have an ftp site for users to get clips to you with.

That seems like a problem to getting things debugged, especially for problems where you need user clips to see the problem.

Jim_C
08-04-2008, 08:53 PM
Needless to say, it bounced since you're e-mail server is very restrictive on file size.


One option.
Use http://www.sendspace.com/
You can send/store 300mb files for free, no email or signup needed.
Just upload file but don't put an email name in, then leave browser open till it's finished and it will give you a download link and a delete link.
Email the dload link to John.

bbeanan
08-04-2008, 09:41 PM
I asked the Tech Support over at Digital Juice to chime in here on this thread and maybe we can get it to work...

SBowie
08-04-2008, 09:54 PM
I'm surprised, I didn't know DJ was using that compression codec.What surprised me most when I checked it was that JPEG2K does have an alpha channel. Interesting.

ted
08-04-2008, 11:05 PM
BTW, John, how can one send you problem clips anyway? I was trying to help debug a problem for you a couple weeks ago, and I needed to send a rather large file to tech support. Needless to say, it bounced since you're e-mail server is very restrictive on file size.


I've sent many DVD's of footage/files directly to NewTek. Sure it cost a few bucks, but they always get the issues resolved. Well worth the price.

mike mullings
08-05-2008, 09:52 AM
I asked the Tech Support over at Digital Juice to chime in here on this thread and maybe we can get it to work...

Hey Brett!

We did use JPEG2000 w/alpha on the Globe MDEs volume.
All other alpha channel animations were compressed with PNG w/alpha.
As far as I know that was the only product we used this on.

Michael Mullings
Technical Specialist
Digital Juice

John Perkins
08-05-2008, 11:42 AM
Just so that you know, TriCaster 2.0, VT5.2 and the next version of SE are able to read even the JPEG2000 clips including the alpha.

As for the current issue with the preview not matching the render, I have a suspicion that I would like someone to test.

Use a 3D DVE somewhere in the problematic project and then render. Make sure that you do not take the option to change DVEs into crossfades.

If this fixes the problem, then I know generally where to look for the bug.

I would still like to get footage that reproduces the problem though.

Thanks,

ted
08-05-2008, 12:11 PM
Thanks Mike for jumping in!
John, I got nothing. ;) I think my issue was resolved with the Ram Preview.

SBowie
08-05-2008, 12:51 PM
Just so that you know, TriCaster 2.0, VT5.2 and the next version of SE are able to read the even the JPEG2000 clips including the alpha.I can confirm this, though I had to throw a force render under that 1500 pixel square diamond to get it to run smoothly. (Very pretty though ... I love DJ!)

ScorpioProd
08-05-2008, 02:03 PM
I've sent many DVD's of footage/files directly to NewTek. Sure it cost a few bucks, but they always get the issues resolved. Well worth the price.
I did that in the past as well, Ted. But I don't see myself doing that in the future. One word: BROADBAND.

The Newtek guy did suggest a file transfer website, but I was skiddish about using one of those, I wasn't sure what was involved. But now I've got Jim's blessing on one, so I'll try it. :)

Though I'm still amazed Newtek doesn't have an ftp site for such things themselves, I mean, don't they make streaming systems, I would think they would have the bandwidth and server support for a site. I mean hey, I even recently doubled my bandwidth personally.

John Perkins
08-05-2008, 02:11 PM
It's not the bandwidth or storage, it's publishing a publicly available login.

We do have an ftp area that we use in some cases, but we try not to give the login to the world for security reasons. ftp isn't the most secure thing in the world.

It is a good suggestion that perhaps we should come up with something secure that is upload only for these situations though.

Verlon
08-05-2008, 05:13 PM
hmm, having trouble recreating the error, but working on it (I deleted the offending footage after getting versions that worked).

I'll try again this week.