View Full Version : WMV for VFR Anime content?
osgZach
16th January 2010, 22:07
I keep seeing references out there on the web, to WMV supporting (or is?) Variable Frame Rate.. Is there a known, easy way to rip a DVD with VFR content to WMV (VFR intact of course)? Just figured I might as well ask and get my hopes crushed sooner rather than later... :thanks:
I wouldn't care about the fact it's WMV/Microsoft, so long as it would potentially work and come out smaller than a VOB set, with comparable quality.
Been having a hell of a time trying to figure out why MKV's I am making (w/AnimeIVTC + timecodes) are stuttering specifically in parts of a video that have panning. Both full scene, or foreground object "panning" across a background (i.e moving across the screen very smoothly when viewed as intended)
So, can WMV really handle VFR content, and if getting that content into a WMV going to be hard? (or at least more involved than using AnimeIVTC and subsequent tools). Really interested to see how it will playback if so.
Keiyakusha
17th January 2010, 20:58
If you have such problems with MKV, most likely the same will be with WMV (if it possible to create such files at all). In case of anime, parts of the video with panning can be 30fps or even 60fps in some endings and the difference between frames is small. Or the main episode can be close to 12real fps but panning obviously true 24fps. Some good frames dropped during creating vfr = stuttering.
Forget about vfr, if you can use x264. Because it almost not helps with compression.
Midzuki
17th January 2010, 22:10
Well, AFAIK, it takes a lot of effort to make a WMV-encode *not* be VFR. :devil: The ASF container does support variable frame rate and variable (audio) sample rate. But if you think it will be easy to create a WMV file with the same timecodes as an MKV source, then you are wrong. Tools which depend on Microsoft 's proprietary codec (WME, WmvMuxer, WmNicEnc, and ASF2VC1) "by default" produce VFR output from CFR inputs, therefore, ...
roozhou
18th January 2010, 04:34
Some good frames dropped during creating vfr = stuttering.
Forget about vfr, if you can use x264. Because it almost not helps with compression.
I can easily reduce 10%~15% bitrate with x264 using deldup on animes without quality loss.
See this tool (http://forum.doom9.org/showthread.php?t=141441)
Yes avisynth messes things up if you either import from vfr source or want to export vfr, but other tools may handle it well.
roozhou
18th January 2010, 04:37
Well, AFAIK, it takes a lot of effort to make a WMV-encode *not* be VFR. :devil: The ASF container does support variable frame rate and variable (audio) sample rate. But if you think it will be easy to create a WMV file with the same timecodes as an MKV source, then you are wrong. Tools which depend on Microsoft 's proprietary codec (WME, WmvMuxer, WmNicEnc, and ASF2VC1) "by default" produce VFR output from CFR inputs, therefore, ...
To produce a TRUE VFR wmv:
1) Encode a CFR wmv
2) Mux it into mkv with timecode files
3) Remux to wmv with ffmpeg/mencoder
Keiyakusha
18th January 2010, 04:48
I can easily reduce 10%~15% bitrate with x264 using deldup on animes without quality loss.
See this tool (http://forum.doom9.org/showthread.php?t=141441)
Yes avisynth messes things up if you either import from vfr source or want to export vfr, but other tools may handle it well.
But as long as we have threshold, this is tradeoff between low benefit and dropped frames. So basically you saying that Deldup does better job than available avisynth filters?
roozhou
18th January 2010, 05:03
But as long as we have threshold, this is tradeoff between low benefit and dropped frames. So basically you saying that Deldup does better job than available avisynth filters?
Of course, this is based on avisynth's dedup and mplayer's decimate, plus fade dectection. It knows the timestamp of each frame so it can easily limit minimum fps. And it does everything in one pass.
benwaggoner
19th January 2010, 21:21
Well, AFAIK, it takes a lot of effort to make a WMV-encode *not* be VFR. :devil: The ASF container does support variable frame rate and variable (audio) sample rate. But if you think it will be easy to create a WMV file with the same timecodes as an MKV source, then you are wrong. Tools which depend on Microsoft 's proprietary codec (WME, WmvMuxer, WmNicEnc, and ASF2VC1) "by default" produce VFR output from CFR inputs, therefore, ...
If you use the free Expression Encoder 3, use VC-1 Advanced Profile and set stream type to Elementary Stream Sequence Header. With that, it'll use repeat_frame tags for identical frames instead of extending the duration of the previous frame, which is probably what you want, and how the original MPEG-2 source probably worked as well.
roozhou
20th January 2010, 03:06
If you use the free Expression Encoder 3, use VC-1 Advanced Profile and set stream type to Elementary Stream Sequence Header. With that, it'll use repeat_frame tags for identical frames instead of extending the duration of the previous frame, which is probably what you want, and how the original MPEG-2 source probably worked as well.
There is a frame type called "Skipped frame" in VC1, right?
osgZach
25th January 2010, 21:34
If you have such problems with MKV, most likely the same will be with WMV (if it possible to create such files at all). In case of anime, parts of the video with panning can be 30fps or even 60fps in some endings and the difference between frames is small. Or the main episode can be close to 12real fps but panning obviously true 24fps. Some good frames dropped during creating vfr = stuttering.
Forget about vfr, if you can use x264. Because it almost not helps with compression.
Heh I forgot about this thread. A while after I posted it, I decided to test out WMV and it did encode with perfectly smooth playback. However I doubt I am gonna find a good medium of quality / file size with VC-1 as MS is implementing it right now.
Anyhow the original problem has been isolated to the way the files are being done w/TFM (which AnimeIVTC uses). For whatever reason they'll play fine on the PC but not my WDTV Live. However I got some help with Yatta and I'm using that to make VFR files that playback fine on both platforms. I suspect the Live's MKV support may not exactly be within spec (found out it also can't play linked segment sets either, bummer). But the Yatta solution seems to be working for now so I'll just go with it :p
I do wish VC-1 would get more attention though.. Its an open standard, so I don't see why it couldn't be tweaked around and improved to make it more in line with H.264 (don't want a clone, just want similar quality / size). Because the VFR support would make Anime so much easier to deal with..
I wish H.264 had written that kind of support in to the specs. Although I'm just a bitchy end-user so I have no idea what it takes to really make a codec as impressive as it already is.
But yeah, it seems to work, hopefully not an isolated case.. If VC-1 ever improves substantially in the quality/file size area that would be great. Although I am kind of itching to play around with the Expression encoder to see if it can give better results than the aging WMV sofotware out there.
edit: For the record. I was never talking about MKV timecodes or anything inside a WMV container. I was talking about a straight DVD/VOB -> WMV encode of the content, with the encoder presumably handling all the IVTC issues, etc to get the proper playback output.
nm
26th January 2010, 00:19
I do wish VC-1 would get more attention though.. Its an open standard, so I don't see why it couldn't be tweaked around and improved to make it more in line with H.264 (don't want a clone, just want similar quality / size). Because the VFR support would make Anime so much easier to deal with..
I wish H.264 had written that kind of support in to the specs.
VFR support is up to the container. Both MP4 and MKV support VFR as well as ASF/WMV.
WDTV should also support VFR in MKV, but apparently some firmware versions are buggy. Which version do you have?
But yeah, it seems to work, hopefully not an isolated case.. If VC-1 ever improves substantially in the quality/file size area that would be great. Although I am kind of itching to play around with the Expression encoder to see if it can give better results than the aging WMV sofotware out there.
Indeed. You should always try the latest or recommended encoder version before complaining about quality.
osgZach
26th January 2010, 17:55
If I wanted to "comaplain" about VC-1 I would just say it sucks, poo poo poo. It's lack of a variety of optimized / better encoders does not invalidate my opinion. It's a question of consumer access. If Expression is that much better than the current crop of older utilities out there - then I will be more than happy to sing its praises as well.
And yeah my WDTV Live does play VFR content just fine. For the most part. I have grabbed some VFR's from here and there to test with it, as well as tested my own attempts at VFR through Yatta.
My Yatta versions do work perfectly that I can tell. However my attempts through TFM/Tdecimate came out with the jerky playback issues. I am supposing it is up to the tools and the methods and perhaps error resilience or deviations from whatever specs, may be an issue as well. As for numerous test files, they will either play fine. Not play at all due to a codec support issue (GMC in Xvid, etc) or appear fine but start to horrendously lose sync and playback some frames are faster rates, or combinations of everything I just listed.
I'm very happy with the WDTV Live, no question of that. I am using the latest official firmware release (forgot the number), its the one they sent out after the pulled FW that was bricking peoples units. No further update notices as of yet.
However as of now, getting WMV's from TMPGEnc Xpress 4, is not really gonna work. They will just come out too big for the perceptible quality I am looking for. But I will reserve final judgement for when I give Expression encoder a try, hopefully soon.
Midzuki
26th January 2010, 18:32
If you use the free Expression Encoder 3, use VC-1 Advanced Profile and set stream type to Elementary Stream Sequence Header. With that, it'll use repeat_frame tags for identical frames instead of extending the duration of the previous frame, which is probably what you want, and how the original MPEG-2 source probably worked as well.
First of all, apologies for the long delay, and for the possible "off-topic~ness" as well.
Second: what I really wanted is,
«source video has NMOPQ frames, VC-1 encoded video also has NMOPQ frames, without any dropped/repeated frames, and with B-frames allowed».
«That» never has hapenned with all the noisy-&&-non-HD videos I have re-encoded with Microsoft's version of the VC-1 standard (yes, both my PC and its video card are too old and too slow for 720p and above, but I'm always wanting to learn as much as I can anyway :) ). It does appear Microsoft's VC-1 encoders do not know very well the difference between background noise and motion vectors... :devil: :D
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.