Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
|
|
Thread Tools | Search this Thread | Display Modes |
5th June 2014, 23:37 | #1 | Link | |
Registered User
Join Date: May 2014
Location: Germany
Posts: 14
|
Optimal HI8 to MPEG2/MPEG4 workflow – facing a couple of problems
Hi everybody!
After gathering interesting and helpful information from this forum literally for years now, I came to a point where I have to ask you guys a couple of questions and thus write my first post. I acquired fairly decent skills in DVD conversion back in my old DVD-> AVI and later DVD->DVDr days ;-), but time has gone by and I did not too much follow the developments, so when I faced my current task, the conversion of old HI8 Videotapes there was a l o t of reading to do. Which I did! I put together a workflow with the aim of giving me the best possible results when transferring those old family memories into the digital world. At several steps of this workflow there arise problems or at least somehow unresolved issues/ questions on which I would like to have your advice! I’ll lay out the workflow step by step, assigning numbers to the issues, so it will be easy to comment on them. The 20 to 10 year old HI8 tapes are played back in the original camcorder that was used for the recording back in the days (Blaupunkt brand). Signal is passed via S-Video into Panasonic NV-GS 400 DV Camcorder and captured in realtime to the PC (Win7pro 64 bit i7quadcore 2,8 ghz HT enabled, 8gb ram) via firewire by means of Adobe Premiere pro 2.0, resulting in interlaced DV-avi files. Q1: Color information is always stored in YV12 in these files? I ask, because sometimes I read it would be YUY2… Assuming this, I figured it would be useful to completely stay in YV12, as target compression MPEG2/MPEG4 uses this colorformat as well. Therefore I use cedocida and unchecked every output option but YV12. Then there is YV12 Chroma sampling… Q2: Which is the correct Chroma sampling to be checked? Not going back to DV, so not the first one. Target compression should be MPEG4 rather than MPEG2 – a problem? Non interlaced or interlaced? At this step we are still before interlacing, so I guess “MPEG2 interlaced” is the one to go for? (read every of these options as the one to choose in other threads…) Choosing these options the video is imported into avisynth via AviSource() , given a chromashift-correction, to be then deinterlaced with QTGMC. --At this point I just HAVE to say: THANK YOU Vit, Didée and Co. for this AMAZING script!! I actually imported those tapes back in 2007/8 and postponed further editing because deinterlacing drove me mad and never gave results I could live with. When this time, after a night of reading, I saw the first frames of my footage properly deinterlaced, I could barely believe my eyes! Thank you, once again!!— As recommended, I used the HT enabled version of avisynth (by SEt) and put together a script like this (following the Multithread advises from QTGMC documentary): Code:
SetMTMode(3, 8) AviSource("D:\Reorganize\ORGANIZED\Homevideo\Familienfilme\(2) 8-93 bis 4-94 - Teil 1.avi") Chromashift(C=-6) SetMTMode(2) QTGMC( Preset="Slow", EdiThreads=4 ) #Distributor() # This line may or may not be necessary, try removing it and see if you get more speed crop(0,0,0,-8) AddBorders(0,0,0,8) trim(11795,74050) ISSUE 3: The rendered video (uncompressed or Lagarith Lossless in YV12 mode) showed completely scrambled frames every 100-200 frames or so, sometimes accompanied by a hiss in the audio. They looked like the attached image "scrambled.jpg" The confusing thing was, not only could none of these scrambled frames ever be seen when seeking frame-by-frame through the stream in VDub but they would magically appear at a completely different place when rendering the exact same sequence once again, leaving all the parameters untouched… When I accidentally had a render done in direct stream copy video mode (which results in an an audio-only clip) I was able to see these scrambled frames appear on the input pane of VDub while performing the rendering. This got me thinking it might have to do something with audio demuxing and sync-keeping… so I disabled audio in the AviSource command with audio=”false”. Et voilà: no more scrambled frames. Directshowsource() did not have this problem either, but I did not want to use it because I liked the idea of staying in YV12 from the very beginning, plus I kept on reading everywhere that Avisource would be preferable due to controllability and stability issues… While searching for a reason for the weird frame-error, I found out, that all of my DV avis had slightly off framerates: instead of 25fps they had either one of the following two values: 25.000375 or 25.000437 fps I could not think of any scenario that could explain this finding. Adding the AssumeFPS(25) command did not solve the scrambled-frame-issue. I ended up doing a re-mux with the audio from the original source-file at the end of the script- no bad frames here. Weird thing! The AssumeFPS(25) still active, I found the Audio running slightly (ca 2 frames) out of sync near the end of the video (one could probably live with that, but it is still annoying and bothers my perfection-seeking mind…) The final script looks like that (I’ll admit: I tried to avoid digging too deep in Avisynth and the whole routing something back to itself thing… I extrapolated this script from what I found In threads with a similar muxing task… might be a little dirty but it does what it is supposed to do…) Code:
SetMTMode(3, 8) Video = AviSource("D:\Reorganize\ORGANIZED\Homevideo\Familienfilme\(2) 8-93 bis 4-94 - Teil 1.avi", audio=false) Video= Video.Chromashift(C=-6) Video = Video.AssumeFPS(25) SetMTMode(2) Video = Video.QTGMC( Preset="Slow", EdiThreads=4 ) #Distributor() # This line may or may not be necessary, try removing it and see if you get more speed Video = Video.Letterbox(0,10) Audio = DirectShowSource("D:\Reorganize\ORGANIZED\Homevideo\Familienfilme\(2) 8-93 bis 4-94 - Teil 1.avi", video=false) AudioDub(Video, Audio) ISSUE 4: The Luma Range! I know this has been discussed over and over again and I have read a t o n about it throughout all the major videoboards and more, but it always seems to be kinda not really my point and I would be VERY grateful if some of the gurus could clarify this issue for my specific case. I eventually managed to find a logical pathway for what is happening with my signals, but at some points it’s just based on assumptions, because I was not able to find a valid statement about this or that , which left absolutely no room for interpretation- at least from my standpoint as being new to the concept. First of all, please set me straight here: Can the “Full Range 0-255” be seen as – in the world of analogue TV technique – some kind of grid that is also “there” for an analogue TV set, here defined by the two extremes that are technically/physically possible, involving voltage, analogue image creation, cathode ray tubes and stuff. On this “technically possible” range, some committee found that the value of 16 was just as black as 0 but not damaging the screen and the same for white and 235. So these values where marked as the “TV Range”, while the “Full Range” was kinda present all the time… If so, how do analogue recording devices like my old HI8 camcorder treat this issue? Is what they consider “black” stored as a value “0” on a scale that ends abruptly at “235” or are they calibrated, so their sensors output a “black” roundabout at the value of 16 on the always -in principle- present grid going from 0 to 255? The latter seems logic to me, as I read about the phenomenon of “overshoot” and “headroom”. In the Avisynth documentary (http://avisynth.nl/index.php/Luminance_levels) it is says: Quote:
Well- I played around with the histogram() command and the results are different from that! Maybe something goes wrong when digitizing the s-video signal but I get a picture like the attatchment histogram1.jpg. Almost no signal under 16. On the other hand, there is quite some overshoot in scenes like the attatchment overshoot.jpg. Out of curiosity I reviewed some real DV-footage (shot with the nvgs400) and this is even more irritating- what should be black seems to be located at about 32 (see DV-histogram.jpg) I’m not sure whether this is related to the findings on the HI8 footage, but I’d be glad if someone had an explanation for that, too! As for the range of the HI8: when scaling the range in the sense of 16->0 and 235 ->255 it seems to be oversaturated, and darker scenes tend to be muddy. So I’d rather stick to the normal look the image has when the values that can be extracted from the YV12 avi will be interpreted as being in PC range and not converted to it in the sense of 16->0, 235->255. This is in fact something I don’t quite understand- which of the following (and other…) commands does something, and what does it do to the YV12 source? ConverttoRGB(matrix="PC.601") -- hypothetically, would this command leave the levels as they are, assuming they are in PC scale? Or is the range expanded? Would …rec.601 scale things around? ConverttoYUY2() -- does it leave it the levels alone? (Q5: Conversion) The latter is important because for MPEG2 conversion I’d like to use CCE, which apparently (unlike contradicting information that from version 2.67.00.10 and higher it would natively support YV12) seems to only accept YUY2… Is the conversion YV12 –[ConverttoYUY2()]-> YUY2 -> [YV12 (within CCE)] lossy or not? Are there just some lines being duplicated and then discarded again or does this (basically unnecessary) step worsen the image quality? In the ‘video/mpeg video setting’ dialog, CCE offers the Luminance Levels selection 16-235 or 0-255, and we’re talking about the output here, right? What does it do to the YUY2 input (assuming this still has the original range)? Does it go “okay, YUY2 is YUV i.e. 16-235 (“normally”), let’s just leave the range as it is when 16-235 is selected and stretch it when 0-255 is selected”? Or will it leave things untouched in 0-255 mode and compress when 16-235 is selected? I know there is a bunch of formulas in the CCE manual on that, but I simply don’t get’em… And finally: When feeding this avs script (or one just containing Avisource(“an-intermediate-lagarith-YV12-file.avi”) ) into MeGui, will really no color conversion take place when encoding with x.264? I’m asking, because Staxrip prompted me to install a “YV12 Decoder” which I purposely avoided to have installed (xvid, ffdshow),to realize when other modules than avisynth try to interfere in the process… Well - I guess that’s about it :-) … I’m sorry, this became such an enormous post.. thank you for reading it, and again thanks for all the awesome stuff you guys developed!! Cheers! |
|
6th June 2014, 17:27 | #2 | Link | ||||||||||
Registered User
Join Date: Sep 2005
Location: Vancouver
Posts: 600
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Can you paste a MediaInfo log of one of these files that's giving you bad frame rates? Quote:
Ignore what you "should" be receiving from the camera, because you just aren't. Use ColorYUV's off_y and gain_y options to move and scale your luma such that black hovers around 16 and white peaks around 235. Quote:
Quote:
Quote:
Last edited by ChiDragon; 6th June 2014 at 17:29. |
||||||||||
6th June 2014, 18:49 | #3 | Link |
Registered User
Join Date: Mar 2009
Location: Germany
Posts: 5,769
|
Issue #3 - how did you find out?
The fps is 25Hz with quite a good precision. However, the audio is unlocked, that means it can be ahead or after, even oscillating, for a max. 1/3 of a frame. Maybe this is the reason why you have this fps, probably the software used to find it out uses also the audio for determining the duration, then fps=duration/frames.
__________________
Born in the USB (not USA) |
9th June 2014, 22:50 | #4 | Link | ||||
Registered User
Join Date: May 2014
Location: Germany
Posts: 14
|
Hey!
Thank you for your answers! Quote:
Code:
AviSource("D:\Reorganize\ORGANIZED\Homevideo\Familienfilme\(2) 8-93 bis 4-94 - Teil 1.avi") QTGMC( Preset="Slow") As the audio=false command in Avisource() helped to get rid of these frames, I guess my final 'workaround-remux-script' is a reasonable solution- alternatively I might just go for separate scripts for audio and video encoding or demux the audio via direct stream copy for further editing, what do you think? Speaking of Quote:
Quote:
Here is the MediaInfo Log of the original file I've been working on: Code:
General CompleteName : D:\Reorganize\ORGANIZED\Homevideo\Familienfilme\(2) 8-93 bis 4-94 - Teil 1.avi Format : AVI Format/Info : Audio Video Interleave Format_Commercial_IfAny : DVCPRO Format_Profile : OpenDML FileSize/String : 19.7 GiB Duration/String : 1h 33mn OverallBitRate_Mode/String : CBR OverallBitRate/String : 30.3 Mbps Recorded_Date : 2010-01-18 00:24:35.000 Video ID/String : 0 Format : DV Format_Commercial_IfAny : DVCPRO CodecID : dvsd CodecID/Hint : Sony Duration/String : 1h 33mn BitRate_Mode/String : CBR BitRate/String : 24.4 Mbps BitRate_Encoded/String : 28.8 Mbps Width/String : 720 pixel3 Height/String : 576 pixel3 DisplayAspectRatio/String : 4:3 FrameRate_Mode/String : CFR FrameRate/String : 25.000 fps3 Standard : PAL ColorSpace : YUV ChromaSubsampling : 4:2:0 BitDepth/String : 8 bit3 ScanType/String : Interlaced ScanOrder/String : BFF Compression_Mode/String : Lossy Bits-(Pixel*Frame) : 2.357 StreamSize/String : 18.7 GiB (95%) Audio ID/String : 1 Format : PCM Format_Settings_Endianness : Little Format_Settings_Sign : Signed CodecID : 1 Duration/String : 1h 33mn BitRate_Mode/String : CBR BitRate/String : 1536 Kbps Channel(s)/String : 2 channel2 SamplingRate/String : 48.0 KHz BitDepth/String : 16 bit3 StreamSize/String : 1023 MiB (5%) Alignment/String : Alignment_Aligned Interleave_Duration/String : 80 ms (2.00 video frames2) Quote:
For a deinterlaced testfile MediaInfo would not round, but give Code:
FrameRate/String : 50.000 fps3 Thanks for the input so far, and hopefully someone has some ideas concerning the remaining encoder-related questions, too. |
||||
13th June 2014, 12:27 | #5 | Link | ||||||||||
Registered User
Join Date: Dec 2007
Location: Germany
Posts: 632
|
Quote:
Quote:
I was using WinDV before which is great for capturing MiniDV but with analog passthrough I had the mentioned problem. Quote:
Anything a good chunk below 16 could theoretically be interpreted as a sync pulse, hence you will very rarely have signal below 16, unlike whites where it's quite different and very common to have signal above 235. Especially with consumer footage of any kind (even with modern cameras) there are super whites (>235/>100 IRE) which you don't want to miss. Since there's no hard limit preventing the CRT from displaying these, they display as if they were in legal range. You don't even notice. Quote:
Quote:
Quote:
This is normal and to be expected from a recording made with home equipment. Quote:
ConverttoRGB(matrix="PC.601") This keeps the entire range of 0-255 in YV12 and converts it to 0-255 RGB. Like you've learned now, this will leave the original blacks at 16 which will look washed out on a computer screen where black should be at 0. Super whites are kept. So you would want to have it followed by Levels(16,1,255, 0,255, false) to make things look correct on a computer display. ConverttoRGB(matrix="Rec601") Takes the legal range from your YV12 source (16-235) and outputs it as 0-255 RGB. In your case, since there are super whites, this is undesireable because they get lost. For video with standard levels this is exactly what you want to use. Yes. Quote:
Quote:
Add this to the end of your script and make sure to encode interlaced in CCE (no automatic detection). Code:
ConverttoYUY2(chromaresample="point", interlaced=true) MergeChroma(PointResize(width, height, 0, 2)) It's very important to have CCE's interlace option set to interlaced, not "auto-detect", because this setting affects which chroma resize is performed – interlaced or progressive. Quote:
Unfortunately I cannot help you with this because I never used MEGui... Last edited by TheSkiller; 14th June 2014 at 14:29. |
||||||||||
16th June 2014, 22:13 | #6 | Link | |||
Registered User
Join Date: May 2014
Location: Germany
Posts: 14
|
Thank you for this informative reply!
Quote:
What is strange though is, that every single of a total of about ten DV-avi files (being of different lenghts) has either one or the other of the two mentioned framerates. Quote:
Although I must admit, that I do not entirely understand how the 'interlaced' option deliveres the desired result, and- don't I end up with an MPEG2 stream flagged as 'interlaced' although it is actuelly progressive? Quote:
|
|||
17th June 2014, 11:13 | #7 | Link | |
Registered User
Join Date: Dec 2007
Location: Germany
Posts: 632
|
Quote:
In CCE you have three interlacing options: - auto detect [with some threshold to enter] - interlaced - progressive This setting does two things. First, it determines whether or not a flag inside every GOP of an MPEG stream is set or not (it's the "Frametype progressive" flag). And second, more importantly, it also determines which of these will be used inside CCE to downsample our "fake" YUY2 to YV12 again: Code:
ConvertToYV12(interlaced=false) ConvertToYV12(interlaced=true) Now the thing is, with interlaced video and our fake YUY2 you cannot use ConvertToYV12(interlaced=false) to undo and restore it to YV12 losslessly. The auto detect settings would try to do this with GOPs where there is no interlacing (movement), a static shot on a tripod for example. It would result in broken chroma. Progressive setting of course is completely wrong with interlaced video, it would produce badly broken chroma everywhere. That's why it really should be set to interlaced (auto detect is the default I think). This setting actually has only one purpose. It's meant to be used in the very rare case of full range YUY2 video, where black really is at 0 and white at 255. Based on this setting CCE will then take action and compress the range to 16-235 so that the output is in legal range. If you leave this setting on 16-235 CCE assumes the input range is already 16-235, so nothing needs to be done. CCE would encode the incoming range as is without changing it, even if it is not 16-235 but, like in your case, 16-255. CCE doesn't care or enforce legal range. That's up to you. That being said, I would advice you to compress your super whites into legal range using AviSynth before encoding. It's no problem to encode MPEG2 with super whites but PC playback and many DVD-players will clip those, that's why it's preferrable to compress your range from 16-255 to 16-235. Last edited by TheSkiller; 17th June 2014 at 11:17. |
|
17th June 2014, 17:58 | #8 | Link | ||
Registered User
Join Date: May 2014
Location: Germany
Posts: 14
|
Quote:
Would a chromaresample-tweak like that also be possible with progressive frames? Because that is what I think I read somewhere on the net- rather by chance and not realizing how useful this might be later on... Quote:
|
||
17th June 2014, 21:46 | #12 | Link | ||
Registered User
Join Date: Dec 2007
Location: Germany
Posts: 632
|
Quote:
Code:
AssumeTFF() SeparateFields().SelectEvery(4,0,3).Weave() Quote:
Code:
ConverttoYUY2(chromaresample="point", interlaced=false) MergeChroma(PointResize(width, height, 0, 1)) However, keep in mind typical camcorder footage will look just wrong deinterlaced to 25p. You're better off re-interlacing it. Last edited by TheSkiller; 17th June 2014 at 21:53. |
||
17th June 2014, 22:49 | #13 | Link | |
Registered User
Join Date: May 2014
Location: Germany
Posts: 14
|
Okay- honestly guys, you kinda lost me here!
Serious question, because if there is a good reason for it, I obviousely must have misunderstood the technical stuff in the background: Why would I want to re-interlace?! The whole aim of this was to -once and forever- get rid of it and generate flatscreen (PC, TV) -displayable footage without combing artifacts. This is why I let QTGMC chew on it for hours - to have it eventually come up with pleasing progressive footage in which this relict from analogue tv technique has been "removed" "as good as possible", and hopefully better than it ever could be removed by means of any realtime-filter implemented in a software-player or standalone dvd player (or probably rather the tv-sets attached to them) , as those - as far as I understood- just discard, blend or roughly interpolate stuff, because no other device than a CRT Monitor would actually benefit from the original idea behind interlacing: preserving vertical resolution while saving bandwith and still providing smooth motion. As far as I understood, any device that is not natively based on a line-based image creation will have to employ some kind of work-around. The footage I am working on will most probably never be viewed on a CRT again, so deinterlacing foor good seemed reasonable to me. Besides - if I wanted to go for interlaced MPEG2 I could have just encoded the original avi- no need for hours of QTGMC calculations then... or am I missing something here? Quote:
|
|
17th June 2014, 23:14 | #14 | Link | ||
Registered User
Join Date: Dec 2007
Location: Germany
Posts: 632
|
Quote:
Well, just try it and put the video in 25p on your DVD. You will probably find it looks stuttery and feels tiring to watch such video in 25p... It'll look very different from native 25p sources which were filmed with special techniques and appropriate shutter speeds. Think of it like this: you are throwing away half (yes, half) of the temporal information originally recorded by using SelectEven(). Quote:
See, DVD is meant to store video in a digital form which is compatible with it's original analogue counterpart. Hence it is only capable of what traditional SD TV is capable of. Last edited by TheSkiller; 17th June 2014 at 23:19. |
||
18th June 2014, 19:57 | #15 | Link | |
Registered User
Join Date: Sep 2005
Location: Vancouver
Posts: 600
|
Quote:
There are tons of players and TVs that do a poor job at interpolation, but they still create 50p video. |
|
19th June 2014, 13:40 | #16 | Link | |
Registered User
Join Date: May 2014
Location: Germany
Posts: 14
|
Quote:
I must admit though, most of the comparisons where done on my PC screen with softwareplayers like powerDVD or VLC rather than on the standalone TV/DVD-player... I don't want to fire up an emotional discussion about whether interlacing is "good" or "bad" ...although I obviousely am not its biggest fan ... I just want the stuff to "look good" - be it on the PC screen or the TV, and if keeping the frames in their original interlaced state is the way to go for the standalone combination TV+DVD this may be surprising (and somewhat frustrating) to me but still hold true if in the end the subjectiv viewing experience (when sitting a couple of meters away from the TV) would be more disturbed by stuttery motion than by the lack of detail/sharpness in the image when being compared to the QTGMC results... Frankly, I did not think of that in the first place... Anyway- in the end the MPEG4 version is more important to me, and as no DVD-standard restricions apply, the QTGMC 50fps version should be fine here. Actually I only whish to create the DVD versions for the sake of completeness as I want to give them to my parents who probably feel more comfortable with the handling of a "classic DVD" - plus I'm not sure about the mediaplayer capabilities of their rather old standalone DVD player ... So maybe I'll give an interlaced encoding another go, but first I'll try and check some x.264 encoded files on the standalone player... maybe in the end it's easier (and less time consuming...) to just buy them a new standalone player and forget about the whole DVD encoding... |
|
30th June 2014, 12:12 | #17 | Link |
Registered User
Join Date: Dec 2002
Location: UK
Posts: 1,673
|
I doubt you'll be back to read this, but...
If the only reason you are deinterlacing is for progressive encoding (i.e. you're not doing any processing or restoration after deinterlacing) then any interlaced encoding should normally be done before deinterlacing. Deinterlacers are not perfect - they all add their own "look" to the footage. You will damage the footage slightly by deinterlacing and then re-interlacing. It's not a lossless process (QTGMC has a lossless option for this reason, but my advice would be: don't use the lossless option because it makes the 50p result worse). You should certainly fix the luma range with like... levels(0,1.0,255,2,235,coring=false) ...as superwhites are routinely clipped by PCs and many modern TVs. Don't use the matrix=PC.601 and/or matrix=Rec601 to try to deal with 16-255 video because that's not what it's designed for. In most home movies, you will still have colours that are out of range, but it's harder to fix those. Cheers, David. |
12th July 2014, 10:16 | #18 | Link |
Registered User
Join Date: May 2014
Location: Germany
Posts: 14
|
Sure- I'm still here! But I'll admit, I did not focus too much on the project recently... too busy following the WorldCup
Thanks for your post. In fact, an interlaced DVD version is no longer planned. My parents got themselfs a fancy new bluray player that plays back 50fps MPEG4 just fine As for the levels- I considered leaving them as they are in the end, but I'll try the levels command. |
25th August 2015, 11:11 | #19 | Link | |
Registered User
Join Date: Aug 2015
Posts: 2
|
Quote:
|
|
1st December 2015, 01:18 | #20 | Link |
Registered User
Join Date: May 2014
Location: Germany
Posts: 14
|
Hey guys- it is me again!
When finally coming back to the project to finish processing the last tapes, I came to realize something very strange, that I need to ask your opinion on! The first tapes were captured using adobe premiere, which (as mentioned in the original post) ended me up with slightly off framerates (25.000375 or 25.000437 fps), and I was told to try Scenalyzer Live. It did indeed give me exactly 25 fps. Today I had to re-capture one of the original tapes and out of curiosity I captured the same scene three times to see If the images will look exactly the same or if there is any change to the appearance of grain/noise (as I read some people capture their tapes 10 times and overlay them as some sort of noise reduction because the actual image information does not move while some of the noise does in every instance and so in the end is less visible/clearly defined). It turned out that the frames of the 25fps interlaced dv avi did not look the same, but the fields could appear in different constellations. Its hard to describe- I'll attatch an image! The three instances on the left were captured using scanalizer, the one on the right is the original adobe premiere capture. There seem to be those two ways the frame can look. When beeing deinterlaced using qtgmc the new frames do only almost look the same- seems one of them is shifted one line. In the second image I layerd a stripe of the "identical "post-interlace" frame over the other. The arrows indicate where you can see the shift. Big question: How can that be?! Must be due to my setup: Hi8 Camcorder passed through MiniDV camcorder via s-video and captured realtime via firewire to pc. I always thought the DV camcorder receives static 25fps with a exactly reproducable line-pattern (interlaced image), but apparently they both mess with fields in a way these different outputs can result- well... by cance?! Other suggestions? Any way to influence this, to get the exaced same 25fps material over and over to try and pull off the overlay thing (as the noise does seem to move)? Thanks Last edited by Jordan; 1st December 2015 at 01:23. |
Thread Tools | Search this Thread |
Display Modes | |
|
|