ReRecording

[GoogleCodeExporter]

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

Original issue reported on code.google.com by [email protected] on 17 Apr 2008 at 7:58

[GoogleCodeExporter]

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.

Original comment by [email protected] on 17 Apr 2008 at 8:07

[GoogleCodeExporter]

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.

Original comment by [email protected] on 17 Apr 2008 at 8:10

[GoogleCodeExporter]

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.

Original comment by [email protected] on 17 Apr 2008 at 11:17

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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

Original comment by [email protected] on 23 Apr 2008 at 8:39

[GoogleCodeExporter]

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

Original comment by [email protected] on 25 Apr 2008 at 5:39

[GoogleCodeExporter]

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.

Original comment by [email protected] on 25 Apr 2008 at 10:14

[GoogleCodeExporter]

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)

Original comment by [email protected] on 25 Apr 2008 at 10:46

[GoogleCodeExporter]

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. 

Original comment by [email protected] on 25 Apr 2008 at 11:03

[GoogleCodeExporter]

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

Original comment by [email protected] on 12 Mar 2009 at 12:13

[GoogleCodeExporter]

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

Original comment by [email protected] on 19 Mar 2009 at 5:00

[GoogleCodeExporter]

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 :)

Original comment by [email protected] on 29 Jul 2009 at 7:07

[GoogleCodeExporter]

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.

Original comment by [email protected] on 29 Jul 2009 at 7:33

[GoogleCodeExporter]

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.

Original comment by [email protected] on 29 Jul 2009 at 7:34

[GoogleCodeExporter]

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.

Original comment by [email protected] on 29 Jul 2009 at 7:38

[GoogleCodeExporter]

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.

Original comment by [email protected] on 29 Jul 2009 at 7:51

[GoogleCodeExporter]

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!

Original comment by [email protected] on 29 Jul 2009 at 8:06

[GoogleCodeExporter]

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

Original comment by [email protected] on 29 Jul 2009 at 8:08

[GoogleCodeExporter]

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.

Original comment by [email protected] on 31 Jul 2009 at 6:37

[GoogleCodeExporter]

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

Original comment by [email protected] on 31 Jul 2009 at 12:29

[GoogleCodeExporter]

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).

Original comment by [email protected] on 31 Jul 2009 at 1:22

[GoogleCodeExporter]

What about GStreamer?

Original comment by [email protected] on 31 Jul 2009 at 4:47

[GoogleCodeExporter]

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.

Original comment by [email protected] on 31 Jul 2009 at 9:12

[GoogleCodeExporter]

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?

Original comment by [email protected] on 31 Jul 2009 at 9:24

[GoogleCodeExporter]

Sounds great to me. What do you encoders think?

Original comment by [email protected] on 31 Jul 2009 at 10:43

[GoogleCodeExporter]

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.

Original comment by [email protected] on 31 Jul 2009 at 11:01

[GoogleCodeExporter]

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/

Original comment by [email protected] on 31 Jul 2009 at 11:23

[GoogleCodeExporter]

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.

Original comment by [email protected] on 31 Jul 2009 at 11:45

[GoogleCodeExporter]

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

Original comment by [email protected] on 1 Aug 2009 at 12:08

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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

Original comment by [email protected] on 23 Feb 2012 at 1:04