Post subject: AVI Capture in mupen64
Joined: 2/26/2009
Posts: 5
Location: United States
I usually use my own capturing tools, so I've never used mupen64's AVI capture before, but it seemed pretty straightforward. I can't capture anything in AVI that's too long. For example, mupen64 will make Movle.avi, then MovieA.avi all the way to MovieZ.avi, then Movie[.avi. It seems like after that, it runs out of file names that it can use and crashes. These files are roughly 1.93 GB with anywhere between 3,700 and 3,800 frames using HuffYUV. I wanted to encode it using H.264, but I rather not have to resort to using a lossy codec to capture into .avi and THEN convert it to .mp4. I guess I'll encode straight to XviD then. My problem is with the emulator running out of file names and crashing then. Is there a way to keep it from doing that? I don't mind (I would actually prefer) one huge file that I can work with.
Former player
Joined: 12/1/2007
Posts: 425
H.264 is a video standard, not an encoder. The H.264 standard does not explicit that H.264 streams must be lossy. .mp4 is a container; you can't "convert" a video to .mp4. XviD is an outdated encoder, use x264 instead. Anyway: I don't know the solution to the running out of file names problem, but if you capture with the more compact MSU screen capture lossless codec, running out of names shouldn't be a problem.
Joined: 2/26/2009
Posts: 5
Location: United States
I think you misunderstood what I wanted to do. Yes, I do use x264, but I need an AVI file to load with AVISynth to edit some things and bring into MeGUI. Unless there's a way for mupen64 Re-Record to somehow directly access x264, which I'm trying to find out, then I would have to use something else (hence XviD) since I can't use HuffYUV. And yes I know that mp4 is a container, but I meant converting through x264 into mp4, which is something that I said I would not do because constant decoding and re-encoding would kill video quality anyway. I tried x264 "lossless" encoding, and it's not lossless in areas of bright red. Thanks for the heads up on the new encoder, but I'm hoping that it's size and not the number of frames that does this. I only managed to get through about 1/5 of the run.
Joined: 11/1/2007
Posts: 100
Impact009 wrote:
Unless there's a way for mupen64 Re-Record to somehow directly access x264, which I'm trying to find out, then I would have to use something else (hence XviD)
Use the VfW version. It's not as efficient in encoding (meaning larger bitrates for the same quality), but it should work.
Former player
Joined: 12/1/2007
Posts: 425
Impact009 wrote:
I tried x264 "lossless" encoding, and it's not lossless in areas of bright red.
That's because of the YV12 conversion. x264 lossless is lossless YV12.
Impact009 wrote:
I think you misunderstood what I wanted to do
No. Use MSU screen capture lossless codec instead of Huffyuv for capturing, and the bitrates will be lower, which means fewer 2 GB chunks, which means the problem is solved, unless the movie is really long. Also, don't use the x264 VFW codec. It's maintained by third party developers, and squeezing H.264 into VFW limitations requires dirty hacks which most prominently affect the editing friendliness of the files.
Joined: 2/26/2009
Posts: 5
Location: United States
Post-capturing I meant. Well anyway, I tried MSU and YULS, and though the compression on both was twice as good compared to HuffYUV, I still got nowhere near towards the end of the movie. It was expected, since I barely got 1/5 of the way through with HuffYUV. I guess I'll sacrifice some quality, but I seriously wonder why the need for this many video segments...
Joined: 11/1/2007
Posts: 100
Impact009 wrote:
I seriously wonder why the need for this many video segments...
AVI files larger than 2GB have issues, so splitting them at recording and reassembling during encoding works around this.
Joined: 11/11/2006
Posts: 1235
Location: United Kingdom
ccfreak2k wrote:
Impact009 wrote:
I seriously wonder why the need for this many video segments...
AVI files larger than 2GB have issues, so splitting them at recording and reassembling during encoding works around this.
...and unfortunately the only way around this is to ditch VFW and use something else that supports OpenDML, though I think using VFW for AVI capture is (was?) a rule/guideline for rerecording emulators here.
<adelikat> I am annoyed at my irc statements ending up in forums & sigs