anri-chan

2011-05-04 10:29:36 pm

Professional Second Banana

Sounds like you've basically got the same PC I do - like I said above, my computer becomes seemingly frozen for about 5 minutes when the NMF operation starts. After that, I regain control, but my RAM is completely maxed out until 2 or 3 of the 8 NMF tasks complete. If you're encoding longer videos like I am, I wouldn't recommend using your primary PC for NMF since you won't be able to run any other apps on your PC for quite a while (a ~5 hour run capture takes about 18-20 hours to NMF and encode for me, so I use my laptop that has 8GB and a similar processor for HQ encodes).

Carcinogen

Edit history:

Carcinogen: 2011-05-05 08:22:29 am

2011-05-05 08:21:31 am

I've been trying to make .avis in anri for a while, appending multiple videos to one file. The finished files don't have any data in them at all. Just says 0KB in Explorer.

This is what I get.

Wouldn't have anything to do with any of my capture settings, would it?

Attachment:

halp.png

rock1644

2011-05-05 09:22:49 pm

yes, a man carrying a gimp

Quote from puwexil:

Sounds like you've basically got the same PC I do - like I said above, my computer becomes seemingly frozen for about 5 minutes when the NMF operation starts. After that, I regain control, but my RAM is completely maxed out until 2 or 3 of the 8 NMF tasks complete. If you're encoding longer videos like I am, I wouldn't recommend using your primary PC for NMF since you won't be able to run any other apps on your PC for quite a while (a ~5 hour run capture takes about 18-20 hours to NMF and encode for me, so I use my laptop that has 8GB and a similar processor for HQ encodes).

It's weird that it would do this because it never used to do it before until last month. I could run other programs just fine while it was processing.

YoukaiDragoon

Edit history:

YoukaiDragoon: 2011-05-05 10:55:48 pm

YoukaiDragoon: 2011-05-05 10:55:27 pm

YoukaiDragoon: 2011-05-05 10:53:25 pm

2011-05-05 10:52:50 pm

Sorry if I'm jumping in and way off base but in reference to the NMF issue. If you are trying to create a NMF purely for concatenation reasons you should check out this post http://forum.speeddemosarchive.com/post/virtualdubavisynth_file_limit_16.html#virtualdubavisynth_file_limit_16 the utility there worked perfect for me and it does a direct copy of the source files so there is no re-encoding which means it's super fast. I'm not sure why your computer is locking up but that might work around it.

Also the utility in this thread might help: http://forum.speeddemosarchive.com/post/stopping_anri_midrender_and_continuing__solved.html If your computer is truly freezing then there's probably nothing that can be done but if it's just being bogged down terribly then opening that before you start the operation might help you see what's going on.

ballofsnow

2011-05-06 10:26:39 am

Carcinogen: I'll take a look at this probably sometime over the weekend. If it's a bug in Anri 3.2 I'll try to get it fixed for 3.3 which I'm trying to release this month.

ballofsnow

2011-05-07 06:52:30 pm

Carcinogen: it's saying error on stream #0.1 which is the audio. I just tested a clip and the problem is the high sampling frequency of 96 KHz. Try capturing at 44.1 KHz or 48 Khz instead, these are more typical.

To fix the existing captures, use virtualdub which is found in "anrichan3.2\VirtualDub-1.9.7\".

1. Load the video
2. Audio menu, choose full processing
3. Audio menu, conversion
4. Set the sampling rate to 48000Hz
5. Video menu, choose direct stream copy.
6. File -> Save as AVI.

nate

2011-05-08 08:08:05 am

haha yeah i've noticed that vdub has started defaulting to 96 khz with a lot of drivers (most notably the most common stk1160 driver for xp). great way to fuck you over.

gyth

2011-05-13 01:02:36 pm

Nero can handle 96kHz, the problem is with bepipe or directshow.

Piping to nero from wavi would fix that problem, but it might cause others.

http://wavi-avi2wav.sourceforge.net/

ballofsnow

2011-05-13 04:47:33 pm

The problem is specific to creating the xvid avi version. The avisynth file is used as input to ffmpeg to create the audio, and apparently it can't handle 96 KHz.

gyth

Edit history:

gyth: 2011-05-16 01:20:48 am

2011-05-16 01:20:00 am

So I'm reading through (up to page 40/65) and one thing I found odd is that --qpmin is being set at all.

Quote:

Think of it this way: would it make sense to encode 1 minute of black at 2048 kbps and get a 15 MB file? Nope. That's why we use the minimum quantizer.

This might have been true before x264 had adaptive quantization, but I don't think it is valid anymore.
You can test it by encoding blankclip(), and while --qpmin 19 is slightly smaller they are both 10k files.

Code:

@echo off

IF [%1]==[] ECHO drag+drop .avi or .avs & pause & GOTO :EOF

call :2pass %1 0
call :2pass %1 19

pause
GOTO :EOF

:2pass
set x264="C:\Program Files (x86)\anrichan3.2\x264.exe"
set flags=--qpmin %2 --bitrate 2048 -o "%~n1_%2.mp4" %1

%x264% %flags% -p 1 && %x264% %flags% -p 2 

GOTO :EOF

ballofsnow

2011-05-16 10:14:45 am

It's not going to be used in 3.3 anyway. Instead, crf pass + 2nd bitrate pass if exceeded SDA bitrate caps.

gyth

2011-09-02 09:52:40 am

I have some questions about variable frame rate, so I'm asking them here rather than derailing the OoT thread.

I think I understand the advantages of vfr in a context where 24p film and 60i video are being mixed.
But what is the point for a video game that has a constant base frame rate, just with varying degree of duplications?
I couldn't tell a difference between the LaMulana samples, did I miss something, or was the point that they looked the same?

Is it a matter of vfr being better than constant decimation?
Because why are we decimating at all?
If the legacy gear the decimation is aimed at can't handle 60fps, how happy will it be with vfr?

Just getting rid of duplicate frames isn't helping the bitrate much (any?), x264 will encode duplicate frames to almost nothing.
If the goal of the decimation is to help the bitrate by getting rid of unique frames, then vfr isn't really helping that. Huh?

Mystery

2011-09-02 10:27:45 am

I wouldn't call myself an expert in the field, but I do know a thing or two, so I shall try to indulge you to the extent of my knowledge.

I don't know if you understand vfr correctly, so I shall attempt to explain it.
There are two ways to create a video: one way is to simply show a (fixed) number of frames each second. This has the drawback of having to duplicate frames in case the produced movie display less frames per second than the framerate of the video.
Another approach is to do away with the fixed framerate and instead use a timeline. With a timeline, we can specify exactly when in time a frame should be shown. This eliminates the need for duplicate frames and is called vfr (variable framerate).

You will most likely not notice any difference between cfr and vfr, since they do not change the contents of the video. And neither of the methods is a cure for jerkiness which is basically too few frames per second.
If done properly, you will notice nothing at all, since vfr affects neither quality nor motion (although, if vfr conversion is done improperly, valid frames might be dropped, causing jerkiness).

Legacy gear will most likely hate vfr since it's an entirely different ratecontrol system from cfr.

Duplicate frames do not help bitrate much because compression is efficient. One of the most basic forms of compression is to simply store the delta from frame to frame, and if the frame is an entire duplicate, then very little information needs to be stored and compressed. Nevertheless, the frame itself needs to be compressed even if it contains no data, I believe. Still, seeing as it's a timeline, it should help reduce the number of frames in a video and therefore reduce filesize (slightly) and decoding requirements.

I wouldn't call myself an expert in the field, but I do know a thing or two, so I shall try to indulge you to the extent of my knowledge.

I don't know if you understand vfr correctly, so I shall attempt to explain it.
There are two ways to create a video: one way is to simply show a (fixed) number of frames each second. This has the drawback of having to duplicate frames in case the produced movie display less frames per second than the framerate of the video.
Another approach is to do away with the fixed framerate and instead use a timeline. With a timeline, we can specify exactly when in time a frame should be shown. This eliminates the need for duplicate frames and is called vfr (variable framerate).

You will most likely not notice any difference between cfr and vfr, since they do not change the contents of the video. And neither of the methods is a cure for jerkiness which is basically too few frames per second.
If done properly, you will notice nothing at all, since vfr affects neither quality nor motion (although, if vfr conversion is done improperly, valid frames might be dropped, causing jerkiness).

Legacy gear will most likely hate vfr since it's an entirely different ratecontrol system from cfr.

Duplicate frames do not help bitrate much because compression is efficient. One of the most basic forms of compression is to simply store the delta from frame to frame, and if the frame is an entire duplicate, then very little information needs to be stored and compressed. Nevertheless, the frame [i]itself[/i] needs to be compressed even if it contains no data, I believe. Still, seeing as it's a timeline, it should help reduce the number of frames in a video and therefore reduce filesize (slightly) and decoding requirements.

ballofsnow

2011-09-03 02:40:50 pm

Mystery pretty much explained it.

Some of my thoughts below.

Quote from gyth:

I think I understand the advantages of vfr in a context where 24p film and 60i video are being mixed.
But what is the point for a video game that has a constant base frame rate, just with varying degree of duplications?

There isn't much point. It's one reason we haven't bothered implementing vfr. I think it comes down to purism/perfectionism: even though the duplicate frames probably have little effect, they're still there and some people will take the time to get rid of them, some won't bother.

Quote from gyth:

I couldn't tell a difference between the LaMulana samples, did I miss something, or was the point that they looked the same?

That was the point. VFR was easy in the LaMulana sample since the picture was a Fraps recording and had 100% duplicates. The trouble comes when you're dealing with interlaced footage and now all of a sudden you have to play around with thresholds, but it won't be perfect and you'll probably get rid of unique frames.

Quote from gyth:

Is it a matter of vfr being better than constant decimation?
Because why are we decimating at all?

I think VFR is better - if you can pull it off - since you're completely removing frames that shouldn't be there. How much better it is and whether it's worth doing is another question, the answer is probably not much better, and not really worth it.

Quote from gyth:

If the legacy gear the decimation is aimed at can't handle 60fps, how happy will it be with vfr?

No idea, and I'd hate to guess. Only one way to know and that's to actually test it out.

Quote from gyth:

Just getting rid of duplicate frames isn't helping the bitrate much (any?), x264 will encode duplicate frames to almost nothing.
If the goal of the decimation is to help the bitrate by getting rid of unique frames, then vfr isn't really helping that. Huh?

I think you meant duplicate, not unique frames?
Again, I hate to guess and we should just do some tests, but you're probably right about x264 encoding duplicate frames to almost nothing. Though I think there will be different bitrate savings between, as mentioned earlier, a LaMulana sample and an interlaced footage sample.

Mystery pretty much explained it.

Some of my thoughts below.

[quote="gyth"]I think I understand the advantages of vfr in a context where 24p film and 60i video are being mixed.
But what is the point for a video game that has a constant base frame rate, just with varying degree of duplications?[/quote]
There isn't much point. It's one reason we haven't bothered implementing vfr. I think it comes down to purism/perfectionism: even though the duplicate frames probably have little effect, they're still [i]there[/i] and some people will take the time to get rid of them, some won't bother.

[quote="gyth"]I couldn't tell a difference between the LaMulana samples, did I miss something, or was the point that they looked the same?[/quote]
That was the point. VFR was easy in the LaMulana sample since the picture was a Fraps recording and had 100% duplicates. The trouble comes when you're dealing with interlaced footage and now all of a sudden you have to play around with thresholds, but it won't be perfect and you'll probably get rid of unique frames.

[quote="gyth"]Is it a matter of vfr being better than constant decimation?
Because why are we decimating at all?[/quote]
I think VFR is better - if you can pull it off - since you're completely removing frames that shouldn't be there. How much better it is and whether it's worth doing is another question, the answer is probably not much better, and not really worth it.

[quote="gyth"]If the legacy gear the decimation is aimed at can't handle 60fps, how happy will it be with vfr?[/quote]
No idea, and I'd hate to guess. Only one way to know and that's to actually test it out.

[quote="gyth"]Just getting rid of duplicate frames isn't helping the bitrate much (any?), x264 will encode duplicate frames to almost nothing.
If the goal of the decimation is to help the bitrate by getting rid of [color="red"]unique [/color]frames, then vfr isn't really helping that. ???[/quote]
I think you meant duplicate, not unique frames?
Again, I hate to guess and we should just do some tests, but you're probably right about x264 encoding duplicate frames to almost nothing. Though I think there will be different bitrate savings between, as mentioned earlier, a LaMulana sample and an interlaced footage sample.

gyth

2011-09-03 05:50:52 pm

Quote from ballofsnow:

Quote from gyth:

If the goal of the decimation is to help the bitrate by getting rid of unique frames, then vfr isn't really helping that.

I think you meant duplicate, not unique frames?

No, I meant that by getting rid of unique frames decimation could help hit low-end bitrate targets.

Looking at the sample in the bomberman thread I noticed a problem with duplicate identification. The "duplicate" fields were offset by one pixel, so they wouldn't match.Using simple f2 decimation the problem can be overlooked, but some parts (the zooms) are f3.

So what kind of testing should be done?

gyth

2011-09-03 06:15:32 pm

So x264 isn't as good as I thought for encoding duplicates.

Code:

LoadPlugin("C:\Program Files (x86)\dgmpgdec158\DGDecode.dll")
MPEG2Source("OoT.d2v")
separatefields
e=selecteven.spline36resize(320,240,7,0,-9,0)
o=selectodd.addborders(0,2,0,0).spline36resize(320,240,7,1.5,-9,-.5)
interleave(e,o)
assumeframebased

trim(5642,6106)
selectevery(3)
changefps(60000,1001)

The changefps turns the 20fps to 60fps by duplicating frames.
Ends up 27% file size encode.

Attachments:

oot20.mp4

oot60.mp4

ballofsnow

Edit history:

ballofsnow: 2011-09-05 07:26:45 pm

ballofsnow: 2011-09-03 07:13:56 pm

ballofsnow: 2011-09-03 07:13:14 pm

ballofsnow: 2011-09-03 07:09:37 pm

ballofsnow: 2011-09-03 07:09:24 pm

2011-09-03 06:40:26 pm

Quote from gyth:

Quote from ballofsnow:

Quote from gyth:

If the goal of the decimation is to help the bitrate by getting rid of unique frames, then vfr isn't really helping that.

I think you meant duplicate, not unique frames?

No, I meant that by getting rid of unique frames decimation could help hit low-end bitrate targets.

Ok. When I'm using VFR, I'm only trying to get rid of duplicate frames. Unique frame decimation is already happening, e.g. 60 fps 3D game usually is decimated to 30 fps for LQ/MQ.

I did another test of LaMulana with default x264 r2074 settings.

LaMulana_cfr - 2468 frames - final average bitrate 398 kbps
LaMulana_vfr - 1267 frames - final average bitrate 372 kbps

7% on this one.

Quote from gyth:

Looking at the sample in the bomberman thread I noticed a problem with duplicate identification. The "duplicate" fields were offset by one pixel, so they wouldn't match.Using simple f2 decimation the problem can be overlooked, but some parts (the zooms) are f3.

Can move it down. It's called 1 pixel bob in anri.

edit- I tried vfr on the bomberman sample. Huge problem is that since the picture is not perfect like a fraps recording of a PC game, I had to bump up dedup's threshold to 5.0 (from default 0.3(!)) for it to "see" the duplicates in F2/3. When you bump it up that high you do get rid of unique frames. You can set the maximum # of sequential drops, i.e. get rid of 2 at most, but still..

I don't see vfr happening for non-fraps recordings, unfortunately.

[quote="gyth"][quote="ballofsnow"][quote="gyth"]If the goal of the decimation is to help the bitrate by getting rid of [color="red"]unique [/color]frames, then vfr isn't really helping that.[/quote]
I think you meant duplicate, not unique frames?[/quote]
No, I meant that by getting rid of unique frames decimation could help hit low-end bitrate targets.[/quote]
Ok. When I'm using VFR, I'm only trying to get rid of duplicate frames. Unique frame decimation is already happening, e.g. 60 fps 3D game usually is decimated to 30 fps for LQ/MQ.

I did another test of LaMulana with default x264 r2074 settings.

LaMulana_cfr - 2468 frames - final average bitrate 398 kbps
LaMulana_vfr - 1267 frames - final average bitrate 372 kbps

7% on this one.

[quote="gyth"]Looking at the sample in the [url=http://forum.speeddemosarchive.com/post/bomberman_64_quality_test.html]bomberman[/url] thread I noticed a problem with duplicate identification. The "duplicate" fields were offset by one pixel, so they wouldn't match.Using simple f2 decimation the problem can be overlooked, but some parts (the zooms) are f3.[/quote]
Can move it down. It's called 1 pixel bob in anri.

edit- I tried vfr on the bomberman sample. Huge problem is that since the picture is not perfect like a fraps recording of a PC game, I had to bump up dedup's threshold to 5.0 (from default 0.3(!)) for it to "see" the duplicates in F2/3. When you bump it up that high you do get rid of unique frames. You can set the maximum # of sequential drops, i.e. get rid of 2 at most, but still..

I don't see vfr happening for non-fraps recordings, unfortunately.

Attachments:

LaMulana_cfr.mp4

LaMulana_vfr_mc20_md20_th0.3.mp4

ballofsnow

Edit history:

ballofsnow: 2011-09-05 07:41:39 pm

2011-09-05 07:40:45 pm

In case anyone wants to give the bomberman sample a try, including myself as I'll inevitably revisit this in the future, see attached zip. ~40 MB

Attachment:

Bomberman.zip

Spirituosa

2011-09-25 01:28:43 pm

(╯°□°)╯︵ ┻━┻

hey,
i don't really have an idea about that whole encode stuff (with anri-chan) and i just wanted to encode a test vid recorded with camstudio (avi.file) but when i start to encode the vid i'm getting this error

(sry about german text :s)

nate

2011-09-25 08:22:46 pm

sometimes, there are errors because of extended latin characters (mit umlaut usw) in the pathname. unfortunately, the desktop directory is below a directory that usually has extended latin characters in it - your username. can you change anri's "project_parentdir" to a different directory? it is in the file ini.bat in the anri program files directory, under "SET project_parentdir=". you will need to remove the REM at the beginning of the line for the change to take effect.

bos

2011-09-25 09:35:53 pm

Nah, no more of that ini.bat stuff in 3.3. Can be accessed from Anri's main menu.

nate

2011-09-25 09:41:30 pm

oooh, cool.

Spirituosa

2011-09-26 07:23:00 am

(╯°□°)╯︵ ┻━┻

so do you mean "project parent folder" in the options menu? i changed it to "D:\anri" but still the same error and sth else ... i can't change or input the video properties
anri-chan sets them automatically to D1 F1 3D

Exo

2011-09-26 07:25:42 am

Sandbagging

Quote from Spirituosa:

so do you mean "project parent folder" in the options menu? i changed it to "D:\anri" but still the same error and sth else ... i can't change or input the video properties
anri-chan sets them automatically to D1 F1 3D

Whats the name of the file youre trying to encode ?

Spirituosa

Edit history:

Spirituosa: 2011-09-26 07:42:30 am

2011-09-26 07:28:16 am

(╯°□°)╯︵ ┻━┻

1st it was like 20110925_1933_29.avi and i renamed it also to nezu.avi but no difference

edit:
here is the file i want to encode

http://www.mediafire.com/?p08b2n6mkdocrpd
if u want to try it yourself (maybe sth is wrong with it?)