Archive Project - What am I doing wrong?

[Yoey]

So I've got a bunch of VHS and camcorder tapes that I'm going to digitize and I've finally figured out the following guide for myself to follow. I'm capturing on the s-video or composite input of a PCHDTV3000. I think I've learned quite a bit but I'd appreciate it if an expert could let me know if I'm missing any key settings or steps. As you can see from the bitrate, I'm not too worried about filesize, though I wouldn't want to go much bigger. I'm mainly interested in preserving the quality.

I've run this procedure on a tape or two and I'm pretty happy with the results.

Here's my 'procedure'

things I think I know
=====================
- data/detail is lost by de-interlacing so don't do it
- It sounds like it's best to end up in Matroska container (.mkv)
- okay with ending up with upto about 200 gigs of compressed video files for archive

- disable trellis (to keep interlace)
- no b-frames (to keep interlace)
- deblocking is good (with defaults)
- don't need 'postprocessing deblocker', instead use 'in-loop deblocker'
- I want at least 2 pass, probably 3 (assuming I can encode one 90 minute tape in 18 hours or so)
- q3 (128kbps) for audio is probably good enough, especiall considering it's mono


==========================================================
FINAL SET OF INSTRUCTIONS - MANUAL PROCEDURE
1. Capture initial super high quality copy of video by using the below command

mencoder \
-tv driver=v4l2:input=1:norm=ntsc:alsa:amode=0 tv:// \
-o /zSpace/temp/rawuncut.avi \
-ovc lavc \
-lavcopts vcodec=ffvhuff \
-oac copy


2. cut these raw captures into each segment, i.e. bday1, bday2, xmas, etc.
# be sure that you edit the output preferences so that it doesn't split up large AVI files (OpenDML)

- manually 'crop' out and save each segment in avidemux (copy, copy, avi)

3. Transcode the video-portion of files from step 2 into x264 using the below command(s)
# decided on bitrate of 5000 after a few tests (and noticing 500 gigs for $113)

mencoder "/zSpace/HomeVideoArchiveProject/2current/raw.avi" -vf harddup -nosound -ovc x264 -x264encopts pass=1:crf=19:me=umh:nodct_decimate:interlaced:8x8dct:nofast_pskip:nobrdo:trellis=0:nr=350:partitions=all:mixed_refs:noglobal_header:nobime:keyint=300:keyint_min=30:frameref=5:bframes=0:nob_adapt:nob_pyramid:noweight_b:subq=6:chroma_me:cabac:deblock -passlogfile /home/guest/.h264enc/h264.log -o /dev/null

mencoder "/zSpace/HomeVideoArchiveProject/2current/raw.avi" -vf harddup -nosound -ovc x264 -x264encopts pass=2:bitrate=5000:me=umh:nodct_decimate:interlaced:8x8dct:nofast_pskip:nobrdo:trellis=0:nr=350:partitions=all:mixed_refs:noglobal_header:nobime:keyint=300:keyint_min=30:frameref=5:bframes=0:nob_adapt:nob_pyramid:noweight_b:subq=6:chroma_me:cabac:deblock -passlogfile /home/guest/.h264enc/h264.log -o "/zSpace/HomeVideoArchiveProject/2current/video.avi"


4. Transcode the files from step 2 audio-portion into ogg using the below command(s)

mplayer raw.avi -vo null -ao pcm:file="audio.wav"
normalize-audio audio.wav
oggenc audio.wav


5. mux the above two files into a mkv

mkvmerge --nalu-size-length 0:3 -o final.mkv video.avi audio.ogg


6. cleanup - delete everything except final.mkv

rename final to something descriptive

7. make this all a script or something so I don't have to manually enter these commands for each video

- this is done, I have a script that takes raw.avi from step 2 and outputs final.mkv

==========================================================

I appreciate your input, even if it's just to say that what I've got looks good.

[Dark Shikari]

- data/detail is lost by de-interlacing so don't do itIncorrect--it depends on the type of deinterlacing. Since you must deinterlace on playback anyways, there is not much of a reason to not deinterlace in the first place!

- disable trellis (to keep interlace)
- no b-frames (to keep interlace)I don't know where this misconception came from... neither trellis no B-frames are at all related to interlacing, and work just fine with x264.
- deblocking is good (with defaults)
- don't need 'postprocessing deblocker', instead use 'in-loop deblocker'Correct.
- I want at least 2 pass, probably 3 (assuming I can encode one 90 minute tape in 18 hours or so)3 pass is basically pointless.
- q3 (128kbps) for audio is probably good enough, especiall considering it's monoQ3 is not a specific bitrate; if the sound is easier to encode (its mono) it will be a lower bitrate. But I agree with you, -q3 is probably fine.

[Sagekilla]

Indeed, unless you're aiming for very specific size constraints there's no reason to use 3-pass. There's very little, if any, quality gain over 2-pass and the only time you'd use it is if you're having trouble hitting a target size.

[Adub]

I would almost recommend using x264 directly, as it easier to manage with updates, plus IMHO I think that quality encodes are easier to attain.

If you are not using a batch script or anything, you may want to look into a tool such as MeGUI or AutoMKV, as it can do most of the stuff you are trying to do automatically.

[nm]

I would almost recommend using x264 directly, as it easier to manage with updates, plus IMHO I think that quality encodes are easier to attain.
Apparently he's using Linux, so MEncoder is as easy to update as x264 (just takes a few more minutes to compile, updating both can be scripted into a one-command task). There is no difference in quality unless you need to use x264 patches that add new command-line options. On the other hand, using MPlayer/MEncoder just for filtering is also quite possible and it takes only a bit more figuring out to pipe the output to x264 through a FIFO. Or for more advanced filtering, you could hack AviSynth to work through Wine.

If you are not using a batch script or anything, you may want to look into a tool such as MeGUI or AutoMKV, as it can do most of the stuff you are trying to do automatically.Currently they may be more painful to install and use on Linux than the alternatives (like Avidemux and MEncoder, which is fully scriptable for this kind of task).


@Yoey:

Concerning MEncoder usage, I'd recommend you to avoid using AVI output for H.264 video. Use "-of rawvideo -o file.264" instead. Mkvmerge can mux .264 streams just fine.

Instead of going straight to encode interlaced video, I'd suggest experimenting a bit with MEncoder's deinterlacers, such as -vf yadif=3,mcdeint=0:1:10 (or 0:0:10, depending on the field order). To halve the resulting framerate to 30000/1001 fps, add framestep=2 at the end of the filter chain.

I'd also recommend using -vf hqdn3d instead of x264's built-in nr filter (if you insist on interlaced encoding, take a look at this discussion (http://lists.mplayerhq.hu/pipermail/mencoder-users/2007-July/006434.html)). There are much better denoisers available in AviSynth, if you feel like installing it.

Finally, you might want to do a single CRF encoding pass instead of 2-pass. That way the average quality of your videos will be higher considering the disk space used.

[Yoey]

Thanks for your input but here's where I got some of my info on these issues...

Incorrect--it depends on the type of deinterlacing. Since you must deinterlace on playback anyways, there is not much of a reason to not deinterlace in the first place!

see the Interlace section at this page
http://www.digitalfaq.com/dvdguides/capture/understandsource.htm
I think the idea is that on non-progressive displays it will look better if you don't de-interlace, and on progressive displays, let hardware/software de-interlace on playback... and that these hardware and software de-interlacers will only get better over time.


I don't know where this misconception came from... neither trellis no B-frames are at all related to interlacing, and work just fine with x264.

See the point in this guide about 'interlacing'
http://gabextreme.googlepages.com/DeathTheSheep_x264_VfW_guide.html
also
http://forum.doom9.org/showthread.php?t=111527
Though it may be old information, perhaps trellis and b-frames are now compatible with interlaced content.

[Yoey]

Concerning MEncoder usage, I'd recommend you to avoid using AVI output for H.264 video. Use "-of rawvideo -o file.264" instead. Mkvmerge can mux .264 streams just fine.

I remember trying this at some point and ran into some problem. I'll try it again I suppose. Any particular reason to avoid avi? syncing issues? the 30 min videos I've done using the above method have been synced fine.

I'd also recommend using -vf hqdn3d instead of x264's built-in nr filter (if you insist on interlaced encoding, take a look at this discussion (http://lists.mplayerhq.hu/pipermail/mencoder-users/2007-July/006434.html)). There are much better denoisers available in AviSynth, if you feel like installing it.

I also remember playing with hqdn3d at some point, nr was just a whole lot easier (one setting), but maybe I'll try it again.

Finally, you might want to do a single CRF encoding pass instead of 2-pass. That way the average quality of your videos will be higher considering the disk space used.

I don't really understand this one. Subjectively, won't the video look worse?

[Dark Shikari]

Thanks for your input but here's where I got some of my info on these issues...


see the Interlace section at this page
http://www.digitalfaq.com/dvdguides/capture/understandsource.htm
I think the idea is that on non-progressive displays it will look better if you don't de-interlace, and on progressive displays, let hardware/software de-interlace on playback... and that these hardware and software de-interlacers will only get better over time.
Most people here will probably agree that interlacing is an unnecessary relic of the past... and displays in the future are less and less likely to support it. More importantly, slow encode-time deinterlacing (e.g. MCBob) will always be superior to playback deinterlacing. And most importantly, if your source has been telecined or the like rather than true interlaced, encoding it as interlaced would be extremely stupid. And, of course, x264's interlaced support leaves much to be desired.
See the point in this guide about 'interlacing'
http://gabextreme.googlepages.com/DeathTheSheep_x264_VfW_guide.html
also
http://forum.doom9.org/showthread.php?t=111527
Though it may be old information, perhaps trellis and b-frames are now compatible with interlaced content.They never were incompatible; it was only true in a specific patch for interlaced support that was fixed before it even hit the real builds.
I remember trying this at some point and ran into some problem. I'll try it again I suppose. Any particular reason to avoid avi? syncing issues? the 30 min videos I've done using the above method have been synced fine.Because H.264 in AVI is a complete mess of hacks and is guaranteed to break on many players.
I don't really understand this one. Subjectively, won't the video look worse?CRF is basically always better than 2-pass if you don't care about file size. That is, if what you want is a specific quality, not a specific file size, CRF lets the size vary so that harder-to-encode videos get more bits, and easier ones gets fewer, while keeping the quality constant on all of them.

[nm]

I remember trying this at some point and ran into some problem. I'll try it again I suppose. Any particular reason to avoid avi? syncing issues? the 30 min videos I've done using the above method have been synced fine.
You'll have sync problems when you start using more advanced b-frame settings (which is a good idea even with interlaced encoding).

I don't really understand this one. Subjectively, won't the video look worse?
No, CRF by itself is almost as good as 2-pass with the same encoding settings, and you avoid having to do a compression check to find out what bitrate to use for each source video. What I meant is that if you encode 100 files with a fixed bitrate of 5000 kbps, some files will have very good quality and some much worse than the others because of differences in source videos. You end up "misplacing" disk space when considering the results over multiple files. To avoid this problem, you would need to find out which specific bitrate to use for each source to get the desired quality level. This could be done for example by encoding parts of the video with a constant quantizer and measuring the resulting file size.

CRF is much easier: you can decide on a quality level and x264 will do the rest, giving as good results as a two-pass encoding at the same final average bitrate. Of course, metrics sometimes fail to meet human preferences, so inspecting the results is still a good idea.

Since you aim for a more or less automatic encoding process and you don't need to have specific file sizes, CRF is in my opinion definitely the way to go. If you're still unsure, just search for previous discussions about CRF or constant quality on this forum and find the comments of other converts. :)

see the Interlace section at this page
http://www.digitalfaq.com/dvdguides/...tandsource.htm
I think the idea is that on non-progressive displays it will look better if you don't de-interlace, and on progressive displays, let hardware/software de-interlace on playback... and that these hardware and software de-interlacers will only get better over time.
That is true and I think that interlaced encoding may be a valid idea in your case. Dark Shikari has good counter arguments there though.

See the point in this guide about 'interlacing'
http://gabextreme.googlepages.com/De...VfW_guide.html
also
http://forum.doom9.org/showthread.php?t=111527
Though it may be old information, perhaps trellis and b-frames are now compatible with interlaced content.
That is old information, see this comment (http://forum.doom9.org/showthread.php?p=1062323#post1062323).
However, you'll probably want to use a mod 32 height for libavcodec decoding support (http://forum.doom9.org/showthread.php?t=120410).

[Manao]

and displays in the future are less and less likely to support it.Wrong argument. All progressive TVs support interlaced content, and that won't change anytime soon.
More importantly, slow encode-time deinterlacing (e.g. MCBob) will always be superior to playback deinterlacingSome TVs come with quite good real time deinterlacers. And bobbing doubles the framerate, making you encode useless unexistant information. If you consider the following processing chains :
[1]interlaced source -> bob -> encode @ XX mbps -> decode -> playback
[2]interlaced source -> encode @ XX mbps -> decode -> bob -> playbackThe second one will have the highest quality.

Now, since x264 is particularly inefficient when it comes to encoding interlaced content, I would go the bobbing way. But that wouldn't be true without another encoder.

[Dark Shikari]

Wrong argument. All progressive TVs support interlaced contentI said displays, you restricted that to TVs. I have never seen a computer display, for example, that supported interlaced content.
Now, since x264 is particularly inefficient when it comes to encoding interlaced content, I would go the bobbing way. But that wouldn't be true without another encoder.This was my main point. And of course if his sources are telecined rather than interlaced, encoding them as interlaced as I said would be silly.

[nm]

And of course if his sources are telecined rather than interlaced, encoding them as interlaced as I said would be silly.
His sources were VHS and camcorder tapes, which implies home video and therefore interlaced content.

[Jay Bee]

Why would interlacing go any time soon? Do you think HDTV will just disappear in a couple of months or what? 1080i is an industry standard that will for sure be better supported in general than some of the other stuff that's popular around here (mkv etc.).

Keeping interlaced as it is before encoding is the only thing that makes sense IMO. Realtime hardware deinterlacers will have much higher quality than comparable speed pre-encode deinterlacers. And there's no doubling of the amount of data.

Problem is that x264 interlacing support is poor. You either need to pay for mainconcept/elecard or do what I'm doing, which is stay with MPEG-2 until AVC or VC-1 has matured which means simple, affordable, bugfree, HD optical compliant interlaced encoding.

[Manao]

stay with MPEG-2 until AVC or VC-1 has maturedI disagree. AVC makes you gain enough bitrate to make bobbing + encoding with x264 more efficient than encoding with mpeg2 + bobbing. And that's even truer for HD.

[Adub]

Oops sorry, my mistake. I didn't realize he was on linux. Then yes, nm is right.

[Yoey]

Thanks for the info... but also... ahh crap... I really thought I was pretty close to nailing down the final procedure I was going to have for converting these vids... but it sounds like I still have a ways to go.

I have to:
- not use avi, instead get a raw h264 file
- use CRF instead of 2-pass
- turn on some b-frame settings and possibly trellis
- figure out what to do about interlacing

I'm totally unsure about deinterlacing now. It's quite tempting to just deinterlace now, take the detail/information/quality loss, and then never really have to worry about it again. It sounds like that's what I should do if I stick with x264 (because of the current interlaced support)... So I guess the only question left is should I use x264 for this project or would some other codec do the job better?

As for the mod 32 thing... I'm capturing at 640x480 (yes interlaced) with no plans to scale so as far as I know, I should be ok.

[Dark Shikari]

- not use avi, instead get a raw h264 file
x264 can directly mux to MKV/MP4.
- use CRF instead of 2-passThis makes the process easier, not harder :).
I'm totally unsure about deinterlacing now. It's quite tempting to just deinterlace now, take the detail/information/quality loss, and then never really have to worry about it again.There is no quality loss with a bobber, only a bit loss (it takes more bits to encode 50 FPS). If you want to drop half of those frames and encode at just 25 FPS, then there will be a quality loss.

[Yoey]

x264 can directly mux to MKV/MP4.
Hmm... I think maybe mencoder can't mux to mkv and that's why I need to go to a 'raw h264 stream' first.

There is no quality loss with a bobber, only a bit loss (it takes more bits to encode 50 FPS). If you want to drop half of those frames and encode at just 25 FPS, then there will be a quality loss.
Okay, I looked into this a little, so now I'm looking for a bob+weave "smooth" deinterlacer for mencoder... any ideas there? This should give me a 640x480 60fps progressive video that will require more space to encode but I'm not worried too much about space.

[Dark Shikari]

Hmm... I think maybe mencoder can't mux to mkv and that's why I need to go to a 'raw h264 stream' first.A common method of encoding with mplayer and x264 separately is to make a FIFO, and then do x264 <options> && mplayer <options>, with mplayer dumping raw yuv to the fifo and x264 reading from it.

[akupenguin]

x264 <options> && mplayer <options>
That's single &.
&& runs them sequentially.

[Yoey]

So I'm still looking into deinterlacers... but it seems that most everything is for windows/avisynth/virtualDUB

Does anyone know how yadif and mcdeint (for mencoder) would compare to some of the 'best' deinterlacers I've heard about like "Deinterlace Smooth" Filter for Virtualdub, or TomsMoComp?

Otherwise I might have to install WINE and run virtual dub through that... I'd rather not though.

[Manao]

yadif/dcdeint are better than Deinterlace Smooth or TomsMoComp, but those two aren't considered good deinterlacers either.

Avisynth's most popular deinterlacers are scripts (search MCBob for example), they are quite good, but quite slow (they'll be slower than the actual encoding, for example).

[Adub]

Frankly, go with yadif, as it is probably the easiest/best solution for you on linux.

Although, I don't know anything about mcdeint. If it is anything like MCBob, then it will give you high quality output, but out the steep steep price of speed.

[nm]

Does anyone know how yadif and mcdeint (for mencoder) would compare to some of the 'best' deinterlacers I've heard about like "Deinterlace Smooth" Filter for Virtualdub, or TomsMoComp?
Michael Niedermayer, author of yadif and mcdeint, has made a small comparison of some filters that are natively available on Linux: http://guru.multimedia.cx/deinterlacing-filters/

The difference between -vf yadif and -vf yadif,mcdeint can be seen in moving detailed textures if the interlaced source is good enough. Yadif will add an oil-painting effect, while mcdeint preserves the texture better. However, both of them have problems with staircasing of edges at some angles, which is avoided by the very best deinterlacers.

Mcdeint is much slower than plain yadif, even with light settings (0:x:10). It may not be worth the time since your sources are probably quite undetailed.

Otherwise I might have to install WINE and run virtual dub through that... I'd rather not though.
Wine+AviSynth would make more sense. Then you could use a better denoiser too (after deinterlacing), because that may be the most important part of getting good quality out of old analog tapes.

[Dark Shikari]

Wine+AviSynth would make more sense. Then you could use a better denoiser too (after deinterlacing), because that may be the most important part of getting good quality out of old analog tapes.Agreed; Avisynth's suites of filters and ability to combine filters is critical to getting good quality out of old sources.

[Jay Bee]

I disagree. AVC makes you gain enough bitrate to make bobbing + encoding with x264 more efficient than encoding with mpeg2 + bobbing. And that's even truer for HD.

Not quite sure that's true for the content I encode (high motion, sometimes noisy, SD) but close, yeah, can be a good idea. But that still leaves easy HD Optical compatibility before I'm happy. :)

It's quite tempting to just deinterlace now, take the detail/information/quality loss, and then never really have to worry about it again.

As Dark Shikari has already pointed out you don't really suffer any loss if you deinterlace to 50 fps. Yadif in mode 1 (mode 0 is only 25 fps) is great for this.

[Adub]

Is there a guide somewhere for setting up Avisynth with Wine? This would help both the original poster and myself.

[nm]

I don't remember seeing guides, but you'll want to search for threads discussing avs2yuv, starting with the most recent one:
http://forum.doom9.org/showthread.php?t=131554

[Adub]

Thanks, will do. I was hoping that there was a little more versatility than just avs2yuv, but thats cool too.

[Yoey]

Thread revival! ... or more like project revival. I got really busy a while ago so I kind of put this down for a bit. But I came back to it recently and after a few attempts and almost giving up, I got some good deinterlacing going.

It is as you guys said, the gains from x264 encoding of non interlaced content largely canceled out the loss of doubling the frames/information with yadif=1. It only went up to 43 megs/minute for a 60fps progressive video from 36 megs/minute for a 30fps interlaced video.

Here's my mencoder command if anyone is interested or has any comments
mencoder "/home/media/Desktop/HomeVideoArchiveProject/2current/raw.avi" -vf yadif=1:1,mcdeint=2:1,hqdn3d=4:3:6,harddup -nosound -ovc x264 -x264encopts crf=21:me=umh:me_range=16:dct_decimate:nointerlaced:8x8dct:nofast_pskip:brdo:trellis=0:nr=350:partitions=all:mixed_refs:noglobal_header:bime:keyint=600:keyint_min=60:frameref=8:bframes=3:b_adapt:b_pyramid:weight_b:direct_pred=auto:subq=6:chroma_me:cabac:deblock -o "/home/media/Desktop/HomeVideoArchiveProject/2current/out.avi" -fps 60000/1001 -ofps 60000/1001

The only other issue that has come up now is that it takes quite a bit of CPU power to decode 640x480 60fps h264... but it's not 100% and it will only get easier for CPUs in the future so it's not that big of a deal

[Yoey]

hmmm... totally unsure and flip flopping on the interlacing again. It turns out that large part of the reason that the filesize hadn't increased much is because I had also added some denoise filters.

After many test encodes and long, detailed subjective comparisons, I'm leaning heavily back towards encoding interlaced. For a given filesize I can get substantially better quality out of encoding interlaced.

for example I was pretty sure I'd found my settings with a 60p, crf 21 encode resulting in a 51 mb file... but then for 53 mb I can encode a 30i, crf 18 video that has noticeably better quality. For reference a 60p, crf 18 video is 85 mb.

So I think I'm going to take comfort in this comment and encode interlaced
That is true and I think that interlaced encoding may be a valid idea in your case. Dark Shikari has good counter arguments there though.

Dark Shikari's only applicable arguments are that x264s support is not the greatest. Yes interlacing is a relic of the past but the solution is to create no more interlaced content, not to convert interlaced content to progressive. Slow encode time de-interlacing will always be better than playback deinterlacing at any given time, but I would guess that playback deinterlacing now may be quite similar or better than 'slow encode time de-interlacing' that was encoded 10 years ago. Anyways, subjectively, the interlaced crf 18 file with deinterlacing on playback, looks superior to the crf 21 progressive file. Since both files are the almost the same size I can't see why I should go with the deinterlaced one.

[Dark Shikari]

Dark Shikari's only applicable arguments are that x264s support is not the greatest. Yes interlacing is a relic of the past but the solution is to create no more interlaced content, not to convert interlaced content to progressive. Slow encode time de-interlacing will always be better than playback deinterlacing at any given time, but I would guess that playback deinterlacing now may be quite similar or better than 'slow encode time de-interlacing' that was encoded 10 years ago. Anyways, subjectively, the interlaced crf 18 file with deinterlacing on playback, looks superior to the crf 21 progressive file. Since both files are the almost the same size I can't see why I should go with the deinterlaced one.I would agree that x264 60i is likely going to be more efficient than x264 60p, no question about it.

If you were willing to decimate down to 30p, there would be an advantage, but otherwise no.

[Sagekilla]

I would agree that x264 60i is likely going to be more efficient than x264 60p, no question about it.

If you were willing to decimate down to 30p, there would be an advantage, but otherwise no.

I'm dealing with my first few instances of interlaced content (After being sheltered in the warmth of DVD movies for so long..) and I have to say that decimating down to 30p doesn't look any worse than 60p after deinterlacing. In fact, the 30p content managed to be much higher quality per bitrate since it used literally half the bitrate to encode the video.

[nm]

I'm dealing with my first few instances of interlaced content (After being sheltered in the warmth of DVD movies for so long..) and I have to say that decimating down to 30p doesn't look any worse than 60p after deinterlacing.
30p is probably better when encoded at the same bitrate, but surely interlaced sports video has much better motion fluidity and accuracy when properly deinterlaced to 60p instead of 30p.

[Sagekilla]

30p is probably better when encoded at the same bitrate, but surely interlaced sports video has much better motion fluidity and accuracy when properly deinterlaced to 60p instead of 30p.

True, sports it is but I'm not dealing with sports video at all. I'm dealing with lower motion video where the loss in motion fluidity is pretty much negligible.

[Manao]

In fact, the 30p content managed to be much higher quality per bitrate since it used literally half the bitrate to encode the video.Not half actually. If bframes are used, all additionnal frames ought to be bframes, and bframes' size is quite lower than other frames' size.

Which makes me wonder whether bframes are used or not. The given command line makes me dubious, but I'm not a mencoder's cli guru either.

[akupenguin]

Not half actually.
agreed.
If bframes are used, all additionnal frames ought to be bframes, and bframes' size is quite lower than other frames' size.
Not all. Sequences that were optimally coded with only P-frames at 30fps might contain more than twice the threshold amount of motion, and thus even when slowed to 60fps they could still be optimally only P. And those are the frames that get the most visual benefit from higher framerate, i.e. the new frames contain a significant amount of information.
Also, if you're already using B-pyramid, then adding more frames in between would require multilevel pyramid, which I haven't implemented.

[Sagekilla]

Not half actually. If bframes are used, all additionnal frames ought to be bframes, and bframes' size is quite lower than other frames' size.

Which makes me wonder whether bframes are used or not. The given command line makes me dubious, but I'm not a mencoder's cli guru either.

Yes my video was half the bitrate at 30p, lower even (48% if you wanna get really technical.) I encoded using the same exact settings (16 B-frames for that matter) and I ended up with half the size.