I'm no deinterlacer expert, but I think the plugin "yadif" is decent as a deinterlacer. I believe AviSynth comes with it already.

Script thingy:

DirectShowSource can be changed with AviSource.

Responded in Longplay submission requirements

General rules
- If you use a source port of the game, make sure it looks as closely to the original game as possible. No high-definition texture pack, no new 3D enemy models, no unofficial mods. This is all about being faithful to the original, NOT about looking as good as possible.
- Don't use cracked games. If you do, we don't want to know and it must absolutely not be visible in the video. No pirate intro or signature of any kind.
- Don't cheat. If you need to cheat (because of a bug in the game, for instance), make it so it's not visible, and indicate what you did and why you did it in the text file so that admins can decide whether to accept it or not. Indicating the time codes where cheats were used is requested but not mandatory.
- Don't skip intros and dialogs. You may know the game by heart, but people who watch the longplay don't. If it gets repetitive or boring, they will just go for the fast forward button on their video player.
- Don't rush through the game. Try to show everything that is essential to complete the game in its entirety, including all possible endings and unlockables. Longplays are not speedruns.
- You can cut grinding sequences from the longplay to avoid getting boring, but indicate it in the text file and summarize what happens during the cropped sequence.
- Use default options in the game. Choose the default character. Use the default route (unless you want to show every possible route).
- Use default gamma correction settings. Videos that appear too dark can be easily tweaked by video players.
- Don't go for the hardest difficulty level if it only means you have to grind through endless enemies that will only slow down the pace. Only exception to this rule is when the difficulty choice also affects the amount of content/levels the player can get access to (e.g. GoldenEye 007 on N64).
- Dying IS OK. We're all human. Just make sure you look like you know what you're doing, not running around playing the game for the first time. Look for walkthroughs on YouTube, Gamefaqs or IGN.com before actually recording.
- Don't add audio commentaries, unless you make them optional (as a second audio track). This is no "Let's Play" series.
- Text commentaries are fine as long as they are optional. External srt files are accepted.
- Refrain from adding custom signatures and introductions. You can do that on your own YouTube channel.
- First, look in our database if there's already an existing longplay for the game. Refrain from doing alternate longplays unless you can significantly improve the existing one. This does NOT apply to entries of the same game for other regions, fan translations or co-op longplays.


Capture Device
Quality is the key word!
When capturing real consoles, you should use top quality capture devices like Elgato 4K60 S+ or Avermedia Live Gamer.
Avoid using capture cards that do not have high bitrate support such as the Avermedia Live Gamer Portable 2 and Avermedia Live Gamer Mini, these are known to have terrible quality and are mainly meant for livestreaming instead of high quality recording.
Be sure to use official OEM component cables or HD Retrovision component cables whenever possible for older systems that do not support HDMI

When capturing from 480p consoles, please use the Retrotink 5X Pro since it gives excellent results at upscaling. Avoid the Retrotink 2X at all costs. That device is cheaper, but gives noticeably bad results. No longplays of that quality will be accepted anymore. Same thing with other cheap capture devices like those from Wish.

For older consoles and computers, the easiest way to get pixel perfect captures is to play the game in an emulator on your computer instead of the real console.


Frame rate (consoles, arcade)
The frame rate must be that of the original game, or one of the frame rates supported by the games if such option is available.


Frame rate (PC)
If the game you are capturing allows to set a specific frame rate, favor either 60 or 50 (depending on your location in the world).
Frame rates of 30 or 25 should be avoided on action games like FPS or shoot'em ups. Games with slow gameplay may accomodate lower frame rates, but keep in mind that the lower the frame rate, the less smooth the video is.
Videos that are not smooth are not pleasant to watch and thus they may get rejected. YouTube videos may be limited in framerate, but the downloadable version of the video is not. That makes a big difference.

If your computer is not powerful enough to record the game smoothly, you should choose a lower screen resolution. Jerky longplays may be rejected.


Deinterlacing
The submitted longplay must NOT be interlaced.
As a general rule, try to avoid interlaced resolutions in games whenever possible.
On current/next generation consoles, always choose the maximum resolution they can output. For PS5/Series X longplays for example, we require them to be recorded in 4K.
When recording older consoles on real hardware you must use an upscaler that has motion adaptive deinterlacing applied to the signal. Upscalers that support this are: Retrotink 5x Pro, OSSC Pro, Retrotink 4K, and Pixel FX Morph.
For bizhawk if a game is deinterlaced it is best to provide two copies, one with the original avidump which is most likely set to weave deinterlacing by default, and another with yadif deinterlacing applied. This can be done in the AviSynth script.

More information on deinterlacing vidos can be found here.
(TODO: write FAQ about deinterlacing and add link here)


Borders
The final video must not include black borders, either left and right or top and bottom.
One notable exception is borders that appear during only part of the game, like during intros and non interactive dialogs.
Only borders that appaear during the whole longplay need to be cropped.

More information on cropping borders can be found here.
(TODO: write FAQ about cropping borders and add link here)


Video resolution (consoles)
NOTE: Most rejected submissions are due to this very strict set of rules. If in doubt, please, please, PLEASE join our IRC channel and ask for any admin's advices.

The video must be captured using one of the native resolutions supported by the console the game is played on.
The video must not be rescaled afterwards.
Depending on your location in the world, consoles may use different native resolutions (NTSC / PAL standards, for instance). You may choose any of them.
One notable exception concerns older consoles. Their resolution must be doubled without smoothing. This general rule should be applied for all resolutions lower than 400 pixels high.

Note that if borders are cropped from the video (as required in the previous paragraph), the final resolution may be smaller and the video must not be rescaled to compensate for the "lost pixels".

The following list gives acceptable resolutions for most consoles:

Microsoft >> Xbox: 640x480 or 720x480 (480p), 960x720 or 1280x720 (720p). 480i only games can be recorded if using an upscaled with motion adaptive deinterlacing, however all games can be forced into 480p through modded software and it is recommended to do so. Recording from an original Xbox is a must here since the backward compatibility feature on X360 causes slowdown at random moments. Please avoid using interlaced resolutions as well. Backwards compatible Xbox games played on the Xbox One or Series consoles will be labeled as just Xbox One longplays and must be recorded at 1080p. If the game runs at 4:3 then you must crop the footage before submitting.
Microsoft >> Xbox 360: 1280x720 (720p), 1920x1080 (1080p). Most games run native 720p so it's best to record 360 titles that way, there are a few games that support 1080p but if set the console output to 1080p then make sure the game supports it otherwise there is bad scaling.
Microsoft >> Xbox One: 1920x1080 (1080p). If recording on an Xbox One X or backwards compatible title through Series X it is allowed for a game to be recorded in 4K if the game officially supports that resolution, but it is not recommended for Xbox One titles as the file size gets extremely large in 4K.
Microsoft >> Xbox Series: 3840x2160 (4K). This means you have to capture from a Series X unit since that model supports 4K TVs/displays. The Series S can only output up to 1440p and thus is NOT an option to record Series versions of longplays for this site, but is allowed for backwards compatible games at 1080p.
Sega >> Master System: 256x192 (rescaling to 512x384 required)
Sega >> Mega Drive / Genesis: 320x224 (rescaling to 640x448 required), 256x224 if cropping is needed because of black spaces at both sides (rescaling to 512x448 required)
Sega >> Dreamcast: 640x480, 640x512, 320x240 (Please avoid using interlaced resolutions whenever possible.) 240p exclusive games require rescaling to 640x480.
Sega >> Mega-CD: 320x224 (rescaling to 640x448 required), 256x224 if cropping is needed because of black spaces at both sides (rescaling to 512x448 required)
Sega >> Saturn: 320x240 (rescaling to 640x480 required), 352x240 (rescaling to 704x480 required). Make sure to enable Constant Framebuffer in SAT > Settings to avoid split avidumps product of resolution changes on the fly.
Sega >> Game Gear: 160x146 (rescaling to 640x584 required. Resizes lower than that do not give a nicer video quality.)
Nintendo >> NES: 256x224 for US/JP games (rescaling to 512x448 required), 256x240 for PAL games (rescaling to 512x480 required)
Nintendo >> SNES: 256x224 for US/JP games (rescaling to 512x448 required), 256x240 for PAL games (rescaling to 512x480 required). Using the double framebuffer option for the BSNES core is suggested since you get avidumps with 2x scaling.
Nintendo >> DS: 256x384 (rescaling to 512x768 required), 384x256 (rescaling to 768x512 required)
Nintendo >> Wii: either 640x480 or 824x480 depending on the game. For 480i games most can be forced to 480p through homebrew software, if it does not work then it must be done with an upscaler that supports motion adaptive deinterlacing. If recording on a Wii U then be sure to downsample to 480p for a valid submission. Avoid using interlaced resolutions if possible, if you record from Dolphin you do not need to worry about deinterlacing.
Nintendo >> 3DS: 400x480, no resizing needed as long as it is recorded from Citra or a BizHawk dev build that supports the 3DS core, but it is recommended to scale the resolution by 2x to 800x960. If recorded from a real unit then a 2x upscale is mandatory to avoid quality issues product of compression.
Nintendo >> Wii U: 1280x720 (720p), 1920x1080 (1080p) All Wii U games should support 1080p output so it is recommended to use that, unless there is a game that performs better in 720p.
Nintendo >> Switch: 1920x1080 (1080p), which means the game has to be run in docked mode. Recordings from a Switch Lite are not accepted at all.
Nintendo >> GameCube: 640x448, 640x480, 640x524 (it can even be 720x480 in exceptional cases). Please avoid using interlaced resolutions whenever possible. If you record from Dolphin you do not need to worry about deinterlacing.
Nintendo >> N64: 256x224 (rescaling to 512x448 required), 320x240 (rescaling to 640x480 required). Please avoid using interlaced resolutions whenever possible. As of right now if you want to record off real hardware then an N64 with an HDMI mod is acceptable, an UltraHDMI mod is acceptable for progressive scan games but not for interlaced due to it only having weave deinterlacing. An N64 Digital is acceptable for all N64 supported resolutions if using motion adaptive deinterlacing, recording at 480p output resolution with both UltraHDMI and N64 Digital is required and crop the output if necessary.
Nintendo >> Game Boy Color: 160x144 (rescaling to 640x576 required. Resizes lower than that do not give a nicer video quality.)
Nintendo >> Game Boy: 160x144 (rescaling to 640x576 required. Resizes lower than that do not give a nicer video quality.)
Nintendo >> Game Boy Advance: 240x160 (rescaling to 960x640 required. Resizes lower than that do not give a nicer video quality.)
Sony >> PS1: 320x240 (BizHawk will scale this to 640x480 in PixelPro mode), 640x480, 640x512, 512x480, 512x240 (BizHawk will scale this to 512x480 in PixelPro mode), 384x240 (BizHawk will scale this to 768x480 in PixelPro mode), and 384x480 (BizHawk will scale this to 786x480 in PixelPro mode)
Sony >> PS2: 640x480, 640x512, 512x480 (it can even be 720x480 in exceptional cases). Please avoid using interlaced resolutions. If using PCSX2 and gameplay is 512x480 but FMVs are 640x480 then it is best to record the gameplay at native resolution and separately record the FMVs at 640x480 to ensure the correct pixel aspect ratio.
Sony >> PS3: 1280x720 (720p), 1920x1080 (1080p). PS3 will automatically change output to 720p for games that don't support 1080p so be sure to find out the resolution of a game this way.
Sony >> PS4: 1920x1080 (1080p)
Sony >> PS5: 3840x2160 (4K)
Sony >> PSP: 480x272 (rescaling to 960x544 required), 320x240 (rescaling to 640x480 required)
Sony >> PS Vita: 960x544 (no rescaling needed though encouraged)
Mattel >> Intellivision: 318x192 after cropping (rescaling to 636x384 required)
Other >> FM-Towns: 352x232 (rescaling to 704x464 required), 640x480
Other >> PC Engine / TurboGrafx 16 / CD: 256x216 (rescaling to 512x432 required), 320x256 (rescaling to 640x512 required)
Other >> ColecoVision: 256x192 after cropping (rescaling to 512x384 required)

More information on resolution doubling can be found here.
(TODO: write FAQ about properly doubling size and add link here)


Video resolution (arcade)
The video must be captured using the original game resolution.
If the game resolution is lower than 400 pixels high, the video resolution needs to be doubled without smoothing. Otherwise, the video must not be rescaled afterwards.

Note that if borders are cropped from the video (as required in the previous paragraph), the final resolution may be smaller and the video must not be rescaled to compensate for the "lost pixels".

More information on resolution doubling can be found here.
(TODO: write FAQ about properly doubling size and add link here)


Video resolution (PC)
The video should be captured using one of the resolutions supported by the game, and not rescaled afterwards.
A resolution compatible with the period the game went on sale is advised. For instance, capturing a game from 1995 in 1080p is not acceptable.
If the maximum resolution supported by the game is lower than 400 pixels high, the resolution must be doubled without smoothing.

In any case, the video resolution should not be higher than 2560x1440 (QHD). If you wish to use a higher resolution, ask the opinion of admins beforehand. Videos of very high resolutions require a powerful computer to play smoothly and thus will simply not display properly for most viewers. Many of them don't even have a monitor with a resolution above QHD. Not to mention that generates an unnecessary big file size to download. Oh! And you need an extra powerful computer to record the game smoothly too!

Note that if borders are cropped from the video (as required in the previous paragraph), the final resolution may be smaller and the video must not be rescaled to compensate for the "lost pixels".

More information on resolution doubling can be found here.
(TODO: write FAQ about properly doubling size and add link here)


Video resolution (other computers)
The video must be captured using one of the native resolutions supported by the computer the game is played on.
If the game resolution is lower than 400 pixels high, the video resolution needs to be doubled without smoothing. Otherwise, the video must not be rescaled afterwards.

Note that if borders are cropped from the video (as required in the previous paragraph), the final resolution may be smaller and the video must not be rescaled to compensate for the "lost pixels".

The following list gives acceptable resolutions for other computers:

Commodore >> C64: (TODO)
Microsoft >> MSX1: 256x192 after cropping (rescaling to 512x384 required)
Microsoft >> MSX2: 256x212 after cropping (rescaling to 512x424 required)
Other >> Atari ST: (TODO)
Other >> Amstrad CPC: 160x200 (rescaling to 320x400 required), 320x200 (rescaling to 640x400 required), 640x200 (rescaling to 1280x400 required)
Other >> Atari Jaguar: output is game dependent (2x rescaling required)


CODECs and file formats
The video track must be encoded using the h264 CODEC.
The sound track must be encoded using the AAC or MP3 CODECs.
Files can be either MP4 or MKV.
As a general rule, try not to split the video if you can avoid it. Let admins do it for you.

The following points are obsolete and no longer encouraged:
Video can be split in several parts if the files get too big (split every 2 or 4 GB, for instance). This is tolerated but not encouraged.
Video can be split in several parts if longplay gets too long. This is tolerated but not encouraged. In the end, the video will be split in 2:30 parts at most (more like 1:00 or 1:30 parts in general) when published on YouTube.

Reason behind the obsoletion of both rules is to keep your longplay as neat as possible, showing what it needs to be shown in one single video.


Video compression
When encoding the final video file, use higher quality settings. We don't mind big files, but we don't accept low video quality.
As a rule of thumb, choose your quality settings so that when the video is playing you can't notice any compression artifact.

More information on encoding your video can be found here.


Signature
Including our signature in the first seconds of the video is mandatory.
The signature contains the following text, which should appear horizontally centered on screen :



The signature should appear approximately 1 second after the start of the video and remain on screen over the game graphics for about 5 or 6 seconds.
If the game name is already visible on screen at that moment, you can skip the first line of the signature.
If the first few seconds are not favorable to adding the signature (for instance because display is too busy and the text would not stand out), you can delay it of a reasonable amount of time.
Colors and fonts are not mandatory, but don't get too creative, for the sake of homogeneity.

More information on how to add this signature and how it should look can be found here.
(TODO: write FAQ on signature, or link to part of the encoding FAQ that refers to signature)


Screenshot
It is mandatory to upload a screenshot of the game along with the video. It is strongly advised that you choose a typical gameplay sequence rather than simply the title screen. Don't forget this picture will be used by people who don't know the game to decide if they want to download the longplay or not. The title screen gives no useful information.
The image will be added to the game page on longplays.org, so choose it wisely!
If no screenshot is provided, an admin will extract one from the video, but this is not OUR job, so please take the time to do it yourself.

More information on how to take a screenshot of the game can be found here.
(TODO: write FAQ describing ways to get a screenshot, from best to worst, and add link here)


Registering
You are required to create a user account on the www.longplays.org website before submitting longplays. This will allow the publishing team to contact you in case your longplay needs to be fixed in some way before being published.
Besides, the longplay description page created on the website features your name, and that field can only contain one of the registered usernames.


SFV File
It is mandatory to upload a SFV file to check if files are not broken. To create a SFV file, install QuickSFV. After installing it, right-click the video file and choose "Create .SFV file". Upload this with your video.

PAR2 File
This step is optional.
You may want to upload a PAR2 file along with the video, so that admins can determine instantly if the upload is corrupt or not. PAR2 files are small checksum files, so the extra data is minimal.
To determine if the uploaded video is corrupt or not, only the smallest of the PAR2 files is required.

You also may want to upload all PAR2 files. In this case, the admin can fix the uploaded video if it needs to. Once again, PAR2 files are small, so the extra data shouldn't take more than 10% of your uploaded video.

More information on generating PAR2 files can be found here.

Responded in Longplay submission requirements

I'm not recommending anyone to use DSS, I'm just saying it has its uses and can be made to work relatively well.

Responded in Question on FRAPS

We are talking about files recorded with FRAPS here, not the HD PVR. The codec is well known, not exotic. The sound desync is probably linked to the FRAPS codec.
And as FRAPS splits the output video every 4 GB, you get a LOT of files (like 300 for Half-Life 2, for instance).

Indeed, the number of calls to DirectShowSource per AVS script is VERY limited (the DirectX DLL is loaded each time you call it or something), which means you can only have like 10-20 avi file appended in an AVS script (the limit seems to vary on every computer) and then you need to create a new one, and append the whole thing using mkvmerge, which is an additional hassle. AviSource, on the other hand, is documented to be limited to something like 60 calls per AVS script, and I have successfully used it to append 50 AVI files in every AVS script. Not perfect, but still better.

In my opinion, when it comes to FRAPS recording, you should definitely not advise people to use DirectShowSource.

By the way, there's a plugin for AviSynth named ffmpegsource that adds two new commands (FFVideoSource and FFAudioSource). They use ffmpeg, you guessed it. They can handle any exotic codecs AND are documented to be frame accurate, so I would advise to use that instead.

Responded in Question on FRAPS

The performance (and issues) of DirectShowSource depends on the codecs and splitters installed. AviSource uses AviSynth internal code and will have rather limited support for exotic stuff. For example, it refuses to load my M2TS-files the Hauppauge HD PVR creates (obviously, they're not even AVIs...)

I use ffdshow for all encoding and decoding on my Windows-machine, so they are used for DirectShowSource as well, and have absolutely no issues with sound synchronization. Although, I haven't tried THAT many clips appended, since I have other issues then (which, of course, could also be a DirectShowSource-problem), only ~10 in each AVS.

Responded in Question on FRAPS

Actually the FAQ indicating how to encode FRAPS movies takes multiple AVI files into account

And I wouldn't use DirectShowSource because it's not frame accurate, which leads to noticable sound desynchronization when encoding, especially when there are a lot of files to append (exactly the FRAPS scenario). I did that mistake at first, and won't do it again!

Responded in Question on FRAPS

Thanks for the answers, multiple avi files are OK so I won't panic 8)
I will translate all the tecnical info you gave me another time, while treasuring it.

Ivan

Responded in Question on FRAPS

That's really odd, since MeGUI uses mkvmerge for muxing to Matroska. But perhaps it's an older version, or has default settings to not use compressed headers (the new feature that made mkvmerge start failing on many devices).

I used mkvmerge for Uncharted, and there are no issues with audiosync on YT.

Oh, and if we're talking complicated AviSynth-scripts, I'm quite proud of the following snippet from my Valkyria Chronicles longplay, where I sped up the video for a grinding section, added background music and spliced that in between two other clips;

:-) :-)

Responded in Question on FRAPS

Sounds like something I always do.
Don't mean to echo, but what Connor said.

I, however, don't like MKVmerge as MKV files made from it won't play in Divx Video player. Plus, if it was to be uploaded on FailTube, the audio and video won't be synced (from my experience with uploading Cocorin on cubex and ZX on my personal channel).
What I do is use MKVmerge to make my one whole file, extract the video and audio fiile (h.264 and .aac), and then remux them in MeGUI. That is what I did with Valkyrie Profile: Lenneth and Chrono Trigger.

Also, AviSynth has a trim option for "cutting" out parts (it is more like "display these frames". I find it very easy to use. Use VirtualDub to find the frames. VirtualDub can also also "read" AVS files (drag and drop).

Dunno if this will help, but here is what I use for trimming:

X is the where you want to start and Y is where you want to stop. Say I want to display frames 234 to 43210. That will be e1=trim(234, 43210). The E1 plus E2 etc are to bring them together. You can also add stuff like dissolve and Fade in and Fade out.

Example of what I used for my [hopefully acceptable] Ape Escape 3 Longplay:


That is pretty much all 5 Ape Escape 3 clips put together and "edited".

How about a somewhat complicate one from doing Parasite Eve on a PSP with RemoteJoyLite:

Responded in Question on FRAPS

The easiest way to prevent the issues with appending many clips in AviSynth is to find a "good" cutpoint, such as the game fading to black and silence, and then end the AVS there, making a new one for the next section.

Then encode each AVS to proper formats, use mkvmerge as usual to create MKV-files, and finally append all MKV-files to each other, also using mkvmerge.

The reason I suggest finding good cutpoints is that I've notice some minor issues when merging MKV-files, it won't be a frame-perfect merge like you'd get with AviSynth, so it's safer to find cutpoints with no no audio and black/static video.

I did this with my Uncharted-run, since I had something like 30 clips. I did it in three steps and merged those at the end. I dare anyone to figure out where those merges are.

Responded in Question on FRAPS

I get it all the time. it isn't that bad. The only problem is renaming all the files so appending will be easier. If you need to append them together, use a script like this:

The "+" will add the next video. If you want to end, just don't add a "+".

You can substitute AviSource with DirectShowSource if you want. If you need to append more videos, just add more "AviSource("filepath" +". Note that appending too many videos will disable audio..unless it is a time thing (happened to me while I was doing Valkyrie Profile: Lenneth).

Edit: welp, Connor beat me...sorta. LOL And he has a WAY better explanation that what I could come up with. Oh, and this site also accepts MP4 as well.

Responded in Question on FRAPS

Long time since I used FRAPS, but I assume it writes AVI-files? "Normal" AVIs are limited to 4GB each. There are extensions that allow more, but it seems to be badly supported in many encoders, so they segment the file instead.

Since this site requires the upload to be H264/AAC in an MKV-container, neither of which have this problem, it's not really an issue. Just merge the files together before the final encoding.

Responded in Question on FRAPS

I have a problem with FRAPS: when i register something, I end up always with not one movie, but several ones each of 4180 mega in size, does anyone else experienced this? I already asked to FRAPS support, but still waiting an answer.
Any counsel will be welcome.
Thanks and bye,

Ivan

Responded in Question on FRAPS

A trick for extracting a sequence from the middle of a movie is to not use;


but instead use;



(by the way, shouldn't the first trim also use '0' not '1'? AviSynth indexes the frames beginning at 0, so that will drop the first frame of the clip.

Anyway, this only loads the clip once, which is a lot faster if it is big, and will also work very well if you have lots of small clips that need cutting, since it basically at least halves the amount of file-loads used.

The "a+b" at the end is used to actually output something, putting AviSource and Trim into a variable like I do doesn't give any output.

Also, by splitting the two sections into two variables, it becomes much easier to do things like;

which will merge the end of clip 'a' into the beginning of clip 'b' with a dissolve effect during 25 frames. Or;

to fade-to-black between the clips for a total of 24 frames.

Responded in [Howto] Encoding videos

Imagine you have recorded a longplay, and the video file is 1.5 GB. You painfully upload it to the Longplays.org ftp server using several resumes, and then an admin tells you your file is corrupt.
You can either reupload your whole movie, or you can use PAR2 files.

PAR2 files are small(er) files that can be used to repair a corrupt file. Thus it is faster to upload PAR2 files to correct the corrupt video than to reupload the whole thing.
Here's how to do that:

[size=large]QuickPar[/size]

Download and install the free QuickPar application. Find it here:
http://www.quickpar.org.uk/

[size=large]Generating PAR2 Files[/size]

[img width=500]http://www.longplays.org/uploads/newbb/486_4d370e3469150.gif[/img]

1) Run QuickPar. The first time, the configuration dialog box appears. Click OK.
2) Click Add Files. Browse and select your longplay file (let's call it my_longplay.mp4)
3) Click Create.

[img width=500]http://www.longplays.org/uploads/newbb/486_4d370e507da89.gif[/img]

A set of files will be generated in the same folder as my_longplay.mp4, named something like this (this is just an example, filenames may vary according to the size of your longplay):


The total size of the PAR2 files is smaller than the original video file. In this case, you get something like 150 MB. Notice that the first files are very small, and they get bigger and bigger near the end.

[img width=402]http://www.longplays.org/uploads/newbb/486_4d370e5912c62.gif[/img]

[size=large]Uploading PAR2 Files[/size]

If you upload all PAR2 files to the same folder as your longplay, admins can use them to repare any corruption in the longplay file.
If you can afford it, that's the recommended procedure.

If you have a very slow connection, however, you can try and upload the first few (smaller) PAR2 files and keep the larger ones for later. There are chances that admins will be able to fix your longplay anyway. But it's rather a matter of luck, and you might be asked to upload more PAR2 files.

Responded in [Howto] Fixing a corrupt longplay upload

Yeah, they're both the old links. I think geekmeister said he was going to replace them with a new discworld video sometime, since the old one had problems.

Responded in Discworld Download 404

I believe Discworld for PC download and mirror are both non-working.

Verify?

Responded in Discworld Download 404

Just for the record, I started recording Lost Horizon and at 60 FPS and my resolution of 1680x1050, it uses 4GB for every 45 seconds.
I'll have to make it in 30FPS!

Responded in Guide to recording/editing video games

Thanks man!!

I'm familiar with using fraps and then reediting with videopad and uploading to youtube.

That whole scripting thing is very new to me, but nothing some reading (lot of reading actually), questions and practice won't do.

Another thing that will be a step learning curve is the Virtual Dub, but the video merging was the biggest question of them all, the rest is more a logical thing.

About the reencode videoparts and sizes, I'll see what I can manage over here.

Thanks for the info, coming soon Dead Space (maybe, I may not have the guts to do it...) and Lost Horizon. Don't know in wich order.

Responded in Guide to recording/editing video games