This one is for you NESVideo, tell me what does Mupen64Plus need in terms of this.

Needs to conform to the .m64 specs availible at http://tasvideos.org/M64.html

Needs to support storing of AVI with proper OpenDML support. Current version of Mupen64-rerecording has an audio drift bug in win32.

Soft reset feature that behaves as would a real N64.

Fix Legend of Zelda: Ocarina of Time pause bug.

As far as I know the LoZ:OOT pause bug has nothing to do with re-recording and deserves its own issue (its a timing issue). If you guys could link to the source of the latest Re-Recording, that would help out.

Sure. Mupen64-rerecording v8 source is here: http://bluetoaster.net/emu/source/mupen64_src-rerecording-v8.7z

The above has problems with audio drift and any avi larger than 2gb is corrupted. Upthorn 'fixed' this by splitting AVIs into 2gb segments (win32 only I believe). Source for that is here: http://bluetoaster.net/emu/source/mupen64_src-rerecording-v8-AVISplit.7z

While I admit the OoT pause bug isn't specifically a rerecording issue, it's a fix the TASvideos community would like as pausing currently causes valuble time to be wasted. I wasn't quite sure what okaygo wanted to be posted here so I thought I'd mention it.

Comment deleted

Comment deleted

Okay I'm most likely going to be incharge of this with the help of a few people... so I'll take the ownership

I have started a branch, but it might be a while before anything tangible comes from it. Currently setting up some pre-reqs.

I have successfully watched Mario64 0 star run in Mupen64Plus with a few workarounds to get to the actual data, and a quickfix for reading it. It synced no problems... however OOT well, I hope that it will eventually sync.

I'm not sure how up to date you are with the state of rerecording with the current version we use, but I thought I should mention that OoT rarely syncs without the same plugins used (notably the video plugin) as well as raw data unchecked in the input plugin. Sometimes even plugin options can affect sync also. If you have the ability to test it using the same plugins perhaps you might get it to sync (though I know this is less than ideal behaviour)

I wrote a lot of little hacks to even have playback work. Everything is so incomplete. Mupen64 automatically assumes one controller, right plugins, start from power, reads in the header, and then feeds the emulators 4bytes every time the rom wants input data.

I'm working on this. It's currently a work in progress. Many things are working, but no need to report bugs etc. yet...

To check it out: $svn://fascination.homelinux.net:7684/mupen64plus/branches/r0304-rerecording --username mupen64 --password Dyson5632-kart $cd r0304-rerecording $./configure --with-qt4 $make all $sudo make install $mupen64plus

Just in terms of the avi recording, the current version of mupen must be maximized and unblocked in order to capture avi and as a result nothing can be done while you are capturing the video.

Instead it would be nice if mupen could be minimized while the video is being captured like many of the other rerecording emulators out now

personally i don't think that avi recording is the primary concern, as rerecordings are mostly used for TASvideos and can only be validated through key-input files. if an avi (or other movie format) needs to be recorded a program like ishowu or a linux counterpart could be used in place of avi recording.

other than that i think this is a very important feature for mupen64plus and i'm glad the community thinks so too :)

Issue with ishowu: it's a screen capture device, so if the emulator lags at all due to processor load/memory latency/whatever, there will be hiccups in the video. Plus, if you want good quality, the video is captured at an enormous size and then sized down later, which is impossible to do in real time for most desktop computers, not to mention while an emulator is running at the same time.

Also, ishowu would have the same issues that Jpat91 mentioned, because you can't block the game window while the screen capture is running.

If the video recording did have issues, support for .kkapture would be a much better alternative than ishowu, since it is made for recording full screen demos frame by frame.

But the way it stands should be ok, especially if the encoder had a dual monitor system so they could carefully do other things at the same time (carefully meaning don't open any new windows just in case they appear on the wrong window). It would be nice if the recording didn't need the visuals to be displayed on the screen though, but it's not a major problem if you let it run and walk away for a while.

You are very well right that TASVideos validates the submitted speedruns by input. After those submissions were accepted, they are published via some avi or mkv file of the run. This media file must have all frames in it, not one of them should be dropped or duplicated. How do you want to achieve this without grabbing the video buffer every frame? Fraps? How do you want to make sure the quality is alright? Windows Movie Maker? No. You need the raw video and audio data and a reasonable encoder such as mencoder or the x264 binary in order to do so. Thus, grabbing the raw data and exporting either an avi or dumping this data to a fifo file is very important. From how I understand it, Mupen can't be minimized because it's an OpenGL application, Dolphin (a Gamecube emulator) shares the same "feature". If there was a way to work around this, I'd be more than happy to see it, yet I somehow doubt it is possible.

Could be the chosen container format Ogg, MKV (Matroska) or NUT? Could be the chosen video codec Dirac, Theora or Xvid? The audio codec shall be the high-quality vorbis.

vini, It should allow the user to choose container between AVI and MKV at least, and the user should be able to use any codec they have installed for the video and audio streams.

Then the rerecording would use something like gstreamer? Would be very nice.

DirectShow is windows-specific and GStreamer is multi-plataform, then I think that could use GStreamer.

And... AVI is poor! Ogg and MKV are nice!

Sorry by the english last comment, I forgot I was wrinting in English. Retrying: "Then could the rerecording use something like GStreamer?"

yes, i suppose i was proven wrong. i only wanted to suggest screen capturing as an alternative to avi capturing, since the priority should be the rerecording itself. it would be nice to see some Ogg output rather than avi. although i think most of the TAS users are on windows. on a side not do you think this will ever be worked into the gtk gui? qt4 is a bitch.

Many of the encoders are actually running linux (from a comment i saw in their forum)

This is a true statement. Only one or two encoders on the website could encode Mupen64 videos because it only ran on Windows (and I don't think it worked too well in WINE...). IIRC, one of these people ran Mupen64 on a Windows box and had it send the raw audio/video stream over the local network to a Linux box for encoding (instead of encoding it directly in Windows).

What about GStreamer?

From what little I read on the website, GStreamer sure seems like a very versatile platform for something like this. If I'm reading it correctly, it can send mutlimedia streams to anything for processing. If that is correct, we could process the video using any method that accepts a media stream. I think an encoder should take a look at it though before that is declared the replacement for whatever is done now. Someone would also need to build a Windows version of GStreamer (which is possible according to the website) to make Mupen64+ work on both platforms with video encoding capabilities.

Good news! GStreamer is like DirectShow, but better and with plugins ease to found.

The SongBird uses GStreamer as core in all plataforms (win, lin and mac). Maybe we will can use the GStreamer build packed in SongBird.

What do you think?

Sounds great to me. What do you encoders think?

What I don't understand is, what would you stream it to? Or is gstreamer an encoder in itself? Also, I'd like to raise the question of which GUI it will be in. I hope it'll be worked into the gtk GUI.

GStream takes the raw media and streams it to a plug-in. GStream is essentially the middle man between the emulator and the encoder plug-in (in actuality the plugin can do anything with the data, but whatever). The website for it is http://www.gstreamer.net/

While GStreamer might be useful for direct encoding for uploading your run on YouTube or the like, but it's most pointless if you're trying to do a high quality encode (e.g. for publication on tasvideos.org) where you need the raw and lossless video and audio data in BGR24 or I420 for further processing. What's the point in pushing this data through multiple plugins when you could just access it directly and thus much faster? If this is to be implemented, please leave an option where you can just dump raw video and audio data to some fifo file for using it with mencoder.

We can use Lagarith (lossless video codec) and FLAC (lossless audio codec). After this we can convert for others codecs (or not).

Comment deleted

Comment deleted

Has there been any progress on re-recording? Many N64 games are begging to be TASed, but only emulate properly in mupen64plus.