Wmv

[rernst]

Really sad to see the small interest in Linux in these forums. It's really not that bad of a platform if you are trying to escape Microsoft.

Having done just that and converted a variety of my machines to PCLinuxOS (IMHO superior to Ubuntu, Suse, Fedora) I have had little problems ripping and authoring. (PCLinuxOS has Cinelerra in its repositories which is otherwise a pain to build).

One of Microsoft's lasts grips from the grave (in a manner of speaking) is my inability to convert WMV->Xvid cleanly. Sure, after installing W32-Codecs MPlayer can somehow render this stuff and mencoder attempts to convert a 29.97 fps piece but its audio starts off a second too early and drifts throughout. In addition mencode complains bitterly about duplicate and too many frames. I am using a constant bitrate and tries with and without the -ofps option and pretty much anything else that has been written about it in on the net.

Fact is that the piece I am looking at apparently uses the variable frame rate feature which mencoder cannot properly digest.

So I broke down and got the gstreamer filter from Fluendo (I don't know, 10 Euros or so) and Gstreamer can now nicely play the file, perfect A/V sync (I believe they license some of the code from MS).

Now GStreamer is not really a player but a ton of 'Linux Directshow filters' that like the Windoze stuff can be pipelined. The GStreamer site actually prominently features something that looks a lot like Graphedit but I don't think has been worked on in, oh, 5+ years.

That being said, I am certain that by pipelining the Fluendo input filter and then demultiplexing it and feeding it into the lame and Xvid output filters I can do a proper transcode (BTW, transcode has the same problems as mencoder as has ffmpeg which won't even read WMV properly).

There is almost no documentation on the XML file contents used with GStreamer or the pipelining commands (yes, a little bit sprinkled through 50-100 web pages).

Can someone either tell me or point me to the direction of good documentation that outlines this process?

A sample would be great, something along the lines of input WMV file -> XVid, quant 3, 128bit MP3 CBR.

I am really a bit out of my league there.

[nm]

As a disclaimer, I'm not really familiar with VFR encoding, so take the following with a grain of salt.

One of Microsoft's lasts grips from the grave (in a manner of speaking) is my inability to convert WMV->Xvid cleanly. Sure, after installing W32-Codecs MPlayer can somehow render this stuff and mencoder attempts to convert a 29.97 fps piece but its audio starts off a second too early and drifts throughout. In addition mencode complains bitterly about duplicate and too many frames. I am using a constant bitrate and tries with and without the -ofps option and pretty much anything else that has been written about it in on the net.
You should be able to avoid frame duplication and dropping with MEncoder options -mc 0 -noskip. If the input is really VFR video, this doesn't help keeping the sync, but at least you get all the frames once and only once. I'd suggest you to re-encode the video and audio first (use the average framerate to make the video codec happy)--then copy the framerate information from ASF/WMV to the target container as part of the muxing process. The target container must also support VFR and needs good tools to do these operations. Matroska is a very good option. VFR AVI is probably not a wise idea unless that's the only format that your player supports.

An outline of the process:

1. Re-encode video using the appropriate codec and allow no frame duplication or dropping (with mencoder -mc 0 -noskip, for example).

2. Demux and possibly re-encode audio (you can use mplayer -vo pcm:file=out.wav to decode WMA from the source file and then encode the output with a separate encoder such as Lame). This could be combined with step 1 by re-encoding the audio along with video, but only when using AVI output in MEncoder. If you want to encode with x264 at some point, you should use -of rawvideo and encode audio separately.

3. Extract timecodes from the WMV.

4. Mux video and audio to the target container along with the timecodes (use mkvmerge for Matroska output).


There are probably many threads on how to do this with AviSynth and Windows-based tools. Here's one worth taking a look at: http://forum.doom9.org/showthread.php?t=117318

WMVTIMES.exe (http://forum.doom9.org/showthread.php?p=827324#post827324) is useful for extracting timecodes from ASF/WMV files. On x86 Linux, it can be executed through Wine. There may be other tools if you look around.

An example for transcoding the Alexander trailer (http://download.microsoft.com/download/4/3/d/43dc9661-f69b-4735-9797-b3c98199085e/Alexander_Trailer_1080p.exe) (from the discussion I linked to above):

mencoder Alexander_Trailer_1080p.wmv -ofps 24000/1001 -mc 0 -noskip -nosound -vc ffwmv3 -vf scale=1280:720 -ovc lavc -lavcopts vcodec=mpeg4:v4mv:mbd=2:trell:vbitrate=5000 -o out.avi
mplayer -vc dummy -vo null -ao pcm:file=out.wav Alexander_Trailer_1080p.wmv
lame out.wav out.mp3
wine WMVTIMES.exe Alexander_Trailer_1080p.wmv out.txt
mkvmerge --timecodes 0:out.txt out.avi out.mp3 -o out.mkv

The output file had correct A/V sync (which would not be possible without timecodes), except for an off-by-one-frame error which caused the first frame of a following scene to be shown as a still picture for some time between scenes instead of an empty black frame. This was easily corrected by removing the first line (0) from the timecode file. I'm not sure which tool caused the problem, but I suspect MEncoder or WMVTIMES.exe.

So I broke down and got the gstreamer filter from Fluendo (I don't know, 10 Euros or so) and Gstreamer can now nicely play the file, perfect A/V sync (I believe they license some of the code from MS).
Also MPlayer should be able to play VFR WMV with perfect A/V sync--at least it does for me. It's just MEncoder that doesn't support VFR encoding. And you don't necessarily need Microsoft's WMV codecs since libavcodec already has pretty good decoders (ffwmv3, ffvc1). I'm not sure about the state of audio codecs (WMA) though.

That being said, I am certain that by pipelining the Fluendo input filter and then demultiplexing it and feeding it into the lame and Xvid output filters I can do a proper transcode (BTW, transcode has the same problems as mencoder as has ffmpeg which won't even read WMV properly).
I doubt that would work any better than MEncoder or transcode considering the currently available GStreamer-based encoding tools. The encoder software would still need to support VFR and since GStreamer apps are not very feature-complete, I doubt that kind of support exists.

[rernst]

I am afraid this does not help much, although your explanation was elaborate. WMVTimes reports an offset of 0 for the first frame. I used the mencoder -mc 0 -noskip options and generated the resulting xvid file without proper sync. It created a ton of messages about duplicate frames (why mencoder wants to drop frames in the first place).

While the MKV container sounds intriguing the current purpose of my exercise is that the desktop device only supports the avi or divx container with mpeg4. (I am considering one of the TVix boxes).

I could proceed by encoding video and audio separately and then muxing but this is not much different than what mencoder does to start with.

I am coming back to the statement that mplayer cannot properly play the WMV9 file in sync from the get go. *Only* the Fluendo codec (which is likely to be mostly MS code) can properly render it.

I have no doubts that there are WMV8 or lower files and *some* WMV9 files that can be properly transcoded by mencoder or played by mplayer.

Again, thanks for the help.

[nm]

I am afraid this does not help much, although your explanation was elaborate. WMVTimes reports an offset of 0 for the first frame. I used the mencoder -mc 0 -noskip options and generated the resulting xvid file without proper sync. It created a ton of messages about duplicate frames (why mencoder wants to drop frames in the first place).
MEncoder drops frames to try to keep A/V sync. Since it only supports fixed-framerate encoding, it needs to drop or duplicate frames to do that. Did you try with -nosound?

While the MKV container sounds intriguing the current purpose of my exercise is that the desktop device only supports the avi or divx container with mpeg4. (I am considering one of the TVix boxes).
Are you sure it supports VFR AVI? If not, the conversion is not simple and I'm not sure if it's possible even with Windows-based tools (which you could look for and try to use through Wine).

I could proceed by encoding video and audio separately and then muxing but this is not much different than what mencoder does to start with.
It is different if you can't get MEncoder to keep all the frames when encoding with audio.

I am coming back to the statement that mplayer cannot properly play the WMV9 file in sync from the get go. *Only* the Fluendo codec (which is likely to be mostly MS code) can properly render it.
Which MPlayer/MEncoder version are you using? Latest SVN is usually your best bet for these kind of tasks. If that's what you're using, those WMV sources are quite special. Any chance of uploading a sample somewhere?

I have no doubts that there are WMV8 or lower files and *some* WMV9 files that can be properly transcoded by mencoder or played by mplayer.
As far as I can tell, all WMV9 and VC-1 encodings that don't have DRM should be supported now. If not, there is a bug somewhere and the only chance of getting it fixed is by reporting the problem and providing samples to MPlayer or FFmpeg developers. Personally, I haven't encountered any WMV file that wouldn't play correctly.

[Reimar]

Are you sure it supports VFR AVI? If not, the conversion is not simple and I'm not sure if it's possible even with Windows-based tools (which you could look for and try to use through Wine).

There is no such thing as VFR AVI, though AVI has a somewhat efficient way of storing unchanged frames which together with very high fps values can emulate it.


As far as I can tell, all WMV9 and VC-1 encodings that don't have DRM should be supported now. If not, there is a bug somewhere and the only chance of getting it fixed is by reporting the problem and providing samples to MPlayer of FFmpeg developers. Personally, I haven't encountered any WMV file that wouldn't play correctly.

Actually even with DRM is supported via libavformat as long as you have the decryption key.
Either way I think the best chance would be to go with FFmpeg for VFR files, though I know I managed to encode the "Alexander" HDTV trailer (which uses VFR as well) with mencoder with perfect sync, I think the trick was to use -mc 10.

[bond]

try ffmpeg instead of mencoder. afaik ffmpeg can handle vfr

[nm]

There is no such thing as VFR AVI, though AVI has a somewhat efficient way of storing unchanged frames which together with very high fps values can emulate it.
Indeed. That's what I was referring to.

Actually even with DRM is supported via libavformat as long as you have the decryption key.
Either way I think the best chance would be to go with FFmpeg for VFR files, though I know I managed to encode the "Alexander" HDTV trailer (which uses VFR as well) with mencoder with perfect sync, I think the trick was to use -mc 10.
Ah, that -mc trick actually makes perfect sense and is worth trying if one can't use a container that actually supports variable framerates. You also need to supply the median framerate of the source as output framerate (-ofps) so that frame duplication and dropping is kept to minimum.

[Reimar]

I found the command-line that works for that Alexander trailer, it actually is a bit different than I thought:
mencoder -ovc lavc -oac mp3lame -lavcopts vqscale=6:vcodec=mpeg4 Alexander_Trailer_720p.wmv -ofps 24 -mc 0 -o test.avi

For long movies you may have to change -mc 0 to something like -mc 0.0001, this allows for a tiny correction by mencoder so audio and video will not run out of sync in the long term, but it increases jitter/short term desync a bit.

[rernst]

For an example try this:

Amazon sells for free (i.e. gives away) an intro to BG.

http://www.amazon.com/Battlestar-Galactica-Story-So-Far/dp/B000UU4IX0/ref=sr_1_5?ie=UTF8&s=digital-video&qid=1198466747&sr=1-5

It won't play properly with mplayer or encode properly. Actually, none of the Amazon files I have seen there play properly with anything *but* the Fluendo plugin. It's a bit mysterious - granted, but extremely annoying.

The above download is relatively short and should demonstrate it well.

If anyone could give me feedback on it, I'd appreciate it.

[rernst]

Ok, let me contradict myself (or better correct myself). I used KMPlayer as GUI wrapper for MPlayer and reported the results obtained in that fashion. I then proceeded to specify the -mc 0 option on playback off the shell prompt and -voila- the movie played back in perfect sync.

It clearly uses VFR - when examining the info that mencoder spits out while processing the file it begins with a frame rate of something like 50fps and then goes below 28 and then back up again to 32. This, in turn, causes problems when encoding. Apparently the file is not truly VFR (or just some mucking with the A/V interleave) because when I encode it this way the movie, of course, starts running off like mad. Explicitly specifying -ofps 30000/1001 corrects this problem. (or -fps for mplayer)

Unfortunately that makes any navigation in mplayer impossible. Skipping forward or backward gets things completely out of sync.

Well, anyhow, I seem to have solved the problem with your help.

[Reimar]

Ok, let me contradict myself (or better correct myself). I used KMPlayer as GUI wrapper for MPlayer and reported the results obtained in that fashion. I then proceeded to specify the -mc 0 option on playback off the shell prompt and -voila- the movie played back in perfect sync.

For MPlayer you should probably use -correct-pts here. Unfortunately that is not implemented for mencoder.
Unfortunately as well that "free" Amazon video is unavailable to both anyone outside the US as well as anyone without credit card, you could say I'm doubly excluded so I can't investigate that further.