Slim Black line....

Post your questions here and we'll all try to help.
paruschuh
Met Resolume in a bar the other day
Posts: 5
Joined: Thu Nov 26, 2009 21:03

Slim Black line....

Post by paruschuh »

Hey there !

I just started using resolume and got some problems importing quiktime files. I hope you can help me, i havent managed to find any answers to this problem till now...

Im editing my video files - Shot on a CanonEos5D with - AECS4 - exporting a Quiktime in 1920x1080 with a H264 Codec... While using this files in resolume a thin black line appears at the bottom of each frame while scaling them down....

Is there any simple solution for this ?
(heres a picture)

Thx
Attachments
problem.jpg
problem.jpg (182.02 KiB) Viewed 13452 times

Joris
Doesn't Know Jack about VJ'ing or Software Development and Mostly Just Gets Coffee for Everyone
Posts: 5185
Joined: Fri May 22, 2009 11:38

Re: Slim Black line....

Post by Joris »

Hey Paruschuh

Welcome to the world of Resolume!

From what I can tell from your post, one thing that could be the cause is that you're using H264 as a codec. H264 is a great codec for putting things online, but terrible to VJ with. I can be very short about it: DON'T USE IT! We suggest recompressing using the DXV codec.

If that doesn't fix things, could you send us (a short sample of) the file, so we can have a look at it?

Joris

paruschuh
Met Resolume in a bar the other day
Posts: 5
Joined: Thu Nov 26, 2009 21:03

Re: Slim Black line....

Post by paruschuh »

hey there... just got up and read your reply... well thx ill try a diffrent codec and see if the problem still exists..
Anyway it would be great if you could explain why the H264 codec is not that good for Vjing.

As i said i just got into this... I study at a filmacademy and im partly working as a director for commericals and documentarys (thats what i get paid for- fiction is quite hard)... Anyway i talked to my editor and he told me it would be probably the best way to keep up a high quality... - using the codec and quiktime....

is it because of the high data rate - and a reduced framerate as a possible result... ?
ohh.. and sorry for the bad english - its "beforecoffeetime"

Greets and thx a lot...

paruschuh
Met Resolume in a bar the other day
Posts: 5
Joined: Thu Nov 26, 2009 21:03

Re: Slim Black line....

Post by paruschuh »

hey... just tryed to render a DXV - same shit different colour... the problem with the thin black line at the bottom still appears...

here´s a sample....
http://filebase.to/files/1058834/schwarz_pilz_dxv.mov

could it be a matter of the pixel shape ? (like cubic..) or the safeframe or underscan ?

User avatar
bart
Team Resolume
Posts: 2223
Joined: Wed Sep 29, 2004 10:01
Location: Resolume HQ

Re: Slim Black line....

Post by bart »

Ja we discovered this also on a different movie this afternoon, we're working on a fix, can you email us on mail@resolume.com so we can send you a fixed version for testing?

Thanks!

paruschuh
Met Resolume in a bar the other day
Posts: 5
Joined: Thu Nov 26, 2009 21:03

Re: Slim Black line....

Post by paruschuh »

ok... thx !!! just send you an email - topic was - fixed version

Joris
Doesn't Know Jack about VJ'ing or Software Development and Mostly Just Gets Coffee for Everyone
Posts: 5185
Joined: Fri May 22, 2009 11:38

Re: Slim Black line....

Post by Joris »

As to the H264 codec question, I'm actually quite surprised to hear your editor suggested it. H264 is a great solution, but only for the right situation. It's great for delivery, but terrible for production. It's a common question though, so I took the liberty to copy/pasting this response from David over at Vidvox:
h.264 and similar codecs are were designed and really optimized for situations where bandwidth is the major limiting factor of the system, such as streaming or downloadable video on the web.

There is a however a significant trade-off; these small files sizes come at a cost.

In order to get the data-rate of the file down, h.264 uses a technique known as "temporal compression". Simply put, the information needed to draw an individual random frame from your movie file may not all be stored in a single easy to read package.

Instead, temporal compression usually involves using key-frames (a whole frame of video used as a reference point), and in between the file only contains the information that changes from one frame to the next. This is okay for playing back video normally, but extremely costly computationally if you want to access a random frame of video from the movie- the nearest key-frame has to be found and then each 'change' in between the reference and the frame you are requesting needs to be taken into account, otherwise you'd get all kind of garbage artifacts in your video. So that pretty much rules out scrubbing video.

The bottom line is that h.264 is more computationally expensive to decompress a single frame of video than a codec like PhotoJPEG, even when playing back at 1x. While your computer is probably fine at playing back one or two h.264 files at a time, it is a lot of extra work for your computer to do so and you are likely to hit a wall sooner than with your disk access. Also, it is often cheaper to buy a fast, large capacity external drive for your clips than to purchase a faster computer.
I find that even when doing normal non-linear editing for commercial work, H264 or other Long Gop formats are just a terrible strain on the system, and I usually take the extra time to convert everything, because it will save me time and hassle in the long run. When it's time to hand off the product to the client, it's the perfect solution though.

Anyway, I hope the new build works for you. Let us know if you have any more questions.

Joris

paruschuh
Met Resolume in a bar the other day
Posts: 5
Joined: Thu Nov 26, 2009 21:03

Re: Slim Black line....

Post by paruschuh »

hey !

im sure he gave me this advise because i told him that i already got problems playing the 1080 files with a normal framerate... In terms of "proffesional" productions your absolutly right...

so. i guess ill switch - and rerender my compositions

I havent got a fix for the "black line" but as soon as i get one - ill write an report...

Cheers...

Vidier
Met Resolume in a bar the other day
Posts: 3
Joined: Fri Dec 04, 2009 21:35

Re: Slim Black line....

Post by Vidier »

Hm I've run in to this problem too...

At first I thought it had something to do with the DXV codec, but now I also see it using the mjpeg codec (in avi files). I render practically all my video files with AE CS4, so it might have something to do with that, or it's a problem with Avenue. When I import the rendered file back into AE, and put an offset effect on it, the black line clearly shows up. (In Avenue, the most obvious effect to show the black line at the bottom is Slide)
I also tried rendering them in 1024x768 in stead of 800x600 because I read somewhere on the web that it might have something to do with 600 pixels not being dividible by 16, but it still showed a line

edit: hm, i've setup VFW to use the mjpeg codec from libavcoded, and the problem doesn't show itself anymore except in Avenue... I can't really see if the line shows up at the bottom of the video when I don't use slide, so I can't really conclude that it has to do something with the Slide effect or just the way it outputs the composition...

edwin
Team Resolume
Posts: 1202
Joined: Thu Oct 07, 2004 10:40

Re: Slim Black line....

Post by edwin »

The black line problem does have to do with the fact that sometimes the width and or/height are not dividable by 16. We are working on a fix and hopefully this will be included in the next release.

Post Reply