encoding 1080p wmv9 + 6ch wma wmv to 480p x264 + 6ch aac mp4

[chros]

I have tried to encode (with the help of megui) this trailer (it's a self-extracting exe, no drm, 1:53, 126MB) from microsoft, but I have 3 problems:

1. video duration
I have used this script (in MPC the decoders are: WMVideo decoder DMO and WMAudio decoder DMO ):

DirectShowSource("Alexander_Trailer_1080p.wmv", audio=False, fps=23.976)
crop( 0, 132, 0, -132)
LanczosResize(848,352)

In this case at the end of the resulted mp4 is a repeated section of the trailer (the end). It's like avisynth knows the duration (1:53), but the encoded frames are much less and then it repeats a section to correct the duration.

If I'm using the convertfps=true parameter too (to dssource function), then there are freezed frames: like avisynth adds still frames to get the correct duration.

If I'm using the seek=false parameter too, then I get a video as in the 1st case, but not repeated section in the end: so the duration is about 1:38 ...

(Of course the original wmv is perfectly played in MPC)

I have tried to create a graph with graphedit, like this:

file  -->  WMVideo Decoder DMO

No changes in the results (both 3 cases).
And I also tried to change the WMVideo DMO to ffdshow in the graph (enabling wmv3/wmv9 decodeing): resulting the same ...

So what can be the problem, and how can I get rid of that?

2. washed out colors
It's like when I switch from Overlay to VMR7 in MPC.
Can I do about it something or the original encode is just simlpy bad.

3. couldn't convert 6ch audio
2 channel works fine, but 6ch doesn't.
In MPC AC3filter connects to WMAudio DMO and results 6ch audio, but when I create the same graph it's only 2 channel. Strange ...

file  --> WMAudio DMO  -->  AC3filter

I have removed AC3 filter from the graph, but it resulted only 2ch.
I checked the PIN out0 info of WMAudio DMO in MPC:

- Connection media type:
Audio: WAVE_FORMAT_EXTENSIBLE 48000Hz 6ch 6912Kbps
...
- Enumerated media type 1:
Audio: WAVE_FORMAT_EXTENSIBLE 48000Hz stereo 2304Kbps
...
- Enumerated media type 2:
Audio: PCM 48000Hz stereo 1536Kbps

So what does it mean?
Is it means that the decoder can produces different outputs?
If it is, then in MPC AC3 filter can connect to 6ch waveformat_ex but not in graphedit ... Strange ...

Any idea ?
Thanks

[bond]

about 3: m$ blocks 6 channel output from their decoder if you are not using the decoder in windows media player iirc

someone posted a fix for this issue, but i dont remember whether this can help you

[communist]

Originally Posted by bond

about 3: m$ blocks 6 channel output from their decoder if you are not using the decoder in windows media player iirc

See http://forum.doom9.org/showthread.php?t=110449
and here fore solution (updated DirectShowSource.dll) http://forum.doom9.org/showthread.ph...961#post861961

[Wilbert]

In this case at the end of the resulted mp4 is a repeated section of the trailer (the end). It's like avisynth knows the duration (1:53), but the encoded frames are much less and then it repeats a section to correct the duration.

If I'm using the convertfps=true parameter too (to dssource function), then there are freezed frames: like avisynth adds still frames to get the correct duration.

If I'm using the seek=false parameter too, then I get a video as in the 1st case, but not repeated section in the end: so the duration is about 1:38 ...

Your wmv is probably variable framerate, that is the framerate is not constant during the clip. Apperently it's not even almost constant, but far from constant.

Using

DirectShowSource("Alexander_Trailer_1080p.wmv", audio=False, fps=23.976)
crop( 0, 132, 0, -132)
LanczosResize(848,352)

will give you all the frames, but the clip is being treated as having a constant framerate of 23.976, which implies that:

1) the during will be much shorter (well, in this case, since i guess that the average framerate is well below 23.976). Imo, this is a bit strange for a movie or a movietrailer, since normal movies are shot at 24 fps.

2) the audio will not be in sync as a result of (1).

To circumvent this issue you need to use convertfps=true, since it will add or remove frames to get a constant framerate of 23.976 fps (or whatever value the parameter fps is set).

If you encode it to MKV, you could create a timecodes file and encode your clip as having a variable framerate. But i'm afraid this only works for hybrid 24/30 fps stuff. (see docs->advanced topics->hybrid-video.htm), and not for general hybrid stuff.

This post contains WMVTIMES.exe which can be used to extract a timecodes file (for MKV) directly from the wmv and mux it with the video using mkvmerge.

2. washed out colors
It's like when I switch from Overlay to VMR7 in MPC.
Can I do about it something or the original encode is just simlpy bad.

Try ColorYUV(levels="PC->TV")

[Wilbert]

Ok, i tried this myself using several approaches, but i can't get satisfactory results (mkv encodings are always choppy). I will post my approaches later this evening.

[foxyshadis]

Actually in this case it's a perfect example of when DeDup would be useful, and none of the hybrid stuff applies. Still, there might be some deeper bizarro problem, I'll take a look at it tonight if you guys haven't solved it.

[Wilbert]

I tried the following two approaches without succes:

1) Using WMVTIMES.exe i created a MKV timecodes file. I encoded the content to XviD using:

DirectShowSource("F:\HDTV\WMV\Alexander_Trailer_1080p.wmv", fps=29.97, convertfps=true)

and

DirectShowSource("F:\HDTV\WMV\Alexander_Trailer_1080p.wmv", fps=29.97, convertfps=false, seek=false)

I'm not sure which of the two should be correct. Both resulted in a duration of 1:53. The latter should have resulted in a shorter duration, so i don't know what's going on here (even for seek=true). MKVMerge (i used version 1.7.0) complained (when adding the clip and the timecodes file):

"The number of external timecodes 2359 is smaller than the number of frames in this track. The remaining frames of this track might not be timestamped the way you intended them to be. mkvmerge might even crash."

which makes sense, because the number of frames is altered.

2) I used the scripts:

1st pass:

DirectShowSource("F:\HDTV\WMV\Alexander_Trailer_1080p.wmv", fps=29.97, convertfps=true)
TFM(mode=0,pp=0)
TDecimate(mode=4,output="stats.txt")

Note the docs says input="stats.txt" above, which is incorrect and should be corrected.

2nd pass:

DirectShowSource("F:\HDTV\WMV\Alexander_Trailer_1080p.wmv", fps=29.97, convertfps=true)
TFM(mode=0,pp=0)
TDecimate(mode=6,hybrid=2,input="stats.txt",mkvout="timecodes.txt")

when opening the encoding in MKVMerge with the timecode file, the resulting MKV is choppy.

I think method 2 should work, and method 1 should also work provided

DirectShowSource("F:\HDTV\WMV\Alexander_Trailer_1080p.wmv", fps=29.97, convertfps=false, seek=false)

gives the appropriate duration as 1:38.


I haven't tried DeDup yet.

[chros]

First of all, thanks for the answers, I managed to create the perfect encode (at least I think so).

A3: with the updated DirectShowSource.dll it's worked like a charm. Thanks!

A1: As it turned out it's vfr indeed ! (On the MS page: "To deliver ultra-high quality, these clips were encoded at 24 frames per second (fps)..." ) I never thought about it !
I thought the problem was that my computer is too slow (3Ghz + 1GB RAM) so it drops frames during encoding. So are directshowsource and avisynth intelligent enough to wait for the decoded frames???

So the process is the following:
1. create the timestamp file (Alexander_Trailer_1080p.txt) with:

WMVTIMES.exe Alexander_Trailer_1080p.wmv

2. create the 2 graph files with graphedit (a-a.GRF for audio, a-v.GRF for video):

wmv file   ->   WMVideo Decoder DMO
wmv file   ->   WMAudio Decoder DMO

3. create the avisynth script for audio:

DirectShowSource("a-a.GRF", fps=23.976, video=false)

4. create the avisynth script for video:

DirectShowSource("a-v.GRF", audio=false, fps=23.976)
crop( 0, 132, 0, -132)
LanczosResize(848,352)

This will result a clip which repeated itself at the end, but it's not important to us (see below...).
5. Do the audio and video encodes into mp4 (so we can decide later the container: mp4 or mkv) with megui (I used x264)...
6. And now the trick: we will cut out the repeated section at the end of the video file with Yamb/mp4box! So we'll get the 1:38 duration...
Only question remains: what time must we cut it?
Open the timecode file and see how many rows it has (format v2: 1 frame per row in milliseconds) so it equals to the frame number +1 of the clip (because of the first comment row), in our case: 2360-1=2359 (Avisynth sees it 2720 frames...)
We devided this with the framerate (23.976): 2359/23.976=98.390 (in seconds)
So:

MP4Box.exe -splitx 0:98.390 4-dmo-h264.mp4

7. choose a container:
7a. mux into mkv
- use mkvmerge GUI: add the video and audio track, and select the timecode file to the video stream -> mux
7b. mux into mp4
- we need this util to get the correct timecode for mp4 from the timecode file (it needs mp4box)

tc2mp4 -i 4-dmo-h264_0_98.mp4 -t Alexander_Trailer_1080p.txt -o 4-dmo-h264_0_98-vfr.mp4

- add the audio mp4 to this file

So we get a perfectly synched vfr mp4 or mkv file !!!
And plus: if you're using the CE-QuickTime profile in MeGUI, the resulted mp4 file can playback by QuickTime player v7.x !!! (at least 2ch sound). (BTW: can we produce a 6ch-mp4 file wich can be playable by QT? I have tried it, but with no luck.)

Q2:

Originally Posted by Wilbert

Try ColorYUV(levels="PC->TV")

It didn't help, the resulted image was way bad ... (resulted filesize without it: 23MB, with it: 8MB )
Any other idea?

[chros]

Originally Posted by chros

4. create the avisynth script for video:

I don't know how I missed this yesterday night (maybe I was too tired ), but we can use trim() to specify the correct number of frames, so in this case we don't need the 6. step (cutting) and we get smaller encoding time!

4. - Open the timecode file and see how many rows it has
(format v2: 1 frame per row in milliseconds) so it equals to the frame number +1 of the clip
(because of the first comment row) and we'll use it in trim so -1 yet, in our case: 2360-2=2358 (Avisynth sees it 2720 frames...)
- create the avisynth script for video:

DirectShowSource("a-v.GRF", audio=false, fps=23.976)
crop( 0, 132, 0, -132)
LanczosResize(848,352)
trim(0,2358)

And in avisynth 2.57 (I haven't installed the RC1 yet, but see in the docs), there's a framecount parameter, which we may need (but we solved this with trim() ):
"framecount (in v2.57): This is sometimes needed to specify the framecount of the video. If the framerate or the number of frames is incorrect (this can happen with asf or mov clips), use this option to force the correct number of frames. If fps is also specified the length of the audio stream is also adjusted."

[zambelli]

Originally Posted by bond

about 3: m$ blocks 6 channel output from their decoder if you are not using the decoder in windows media player iirc

No, you don't recall correctly. Multichannel output isn't blocked - it merely needs to be requested programmatically by the app that's building the graph. That's what IanB's modified DirectShowSource.dll does - it just sets the necessary decoder property, as is documented on MSDN.

Originally Posted by chros

2. washed out colors
It's like when I switch from Overlay to VMR7 in MPC.
Can I do about it something or the original encode is just simlpy bad.

The source is most likely encoded with black at 16 and white at 235, as calibrated for TVs. Try adding this at the end of your script:

Histogram("levels")

Then scan through the video in VDub and note whether there is any valid luma info below 16 and above 235. I would guess not. Anyway, what's happening is that somewhere in your playback pipeline YUV 16..235 is getting mapped to RGB 16..235. As your computer monitor is configured for black=0, white=255 - the video looks washed out.

[chros]

Originally Posted by zambelli

The source is most likely encoded with black at 16 and white at 235, as calibrated for TVs. Try adding this at the end of your script:

Histogram("levels")

Then scan through the video in VDub and note whether there is any valid luma info below 16 and above 235. I would guess not.

You are right ! Thanks. I didn't know about Histogram().
And I apologize to Wilbert for being stupid:
ColorYUV(levels="TV->PC") solved the problem, the opposite you have suggested, which I haven't tried.
I think I can put this ColorYUV() right after the crop() function.
Question: is there any quality loss during this conversion ?

Originally Posted by zambelli

Anyway, what's happening is that somewhere in your playback pipeline YUV 16..235 is getting mapped to RGB 16..235. As your computer monitor is configured for black=0, white=255 - the video looks washed out.

Strange thing was that I have tried different trailers whith the above mentioned method (so the pipelines are the same), and there were no such problem...

Regardning 7b (when muxing into mp4):
there are some clips, where after the encoding the audio isn't synched (7a works perfectly, when we mux into mkv the same encoded clip).
So I don't know if tc2mp4 or mp4box mistaken ...
The clips are in common: they have 2ch 44100 Hz audio.
Godsend
The Punisher

But with this clip, it's ok too (it has 2ch 48000 Hz audio):
Serenity trailer 3

After the tc2mp4 step, the video duration is correct, so maybe mp4box's muxing the 44100 Hz audio badly.

[zambelli]

Originally Posted by chros

ColorYUV(levels="TV->PC") solved the problem, the opposite you have suggested, which I haven't tried.
I think I can put this ColorYUV() right after the crop() function.
Question: is there any quality loss during this conversion ?

The question is not so much whether it's lossy, but whether it's the right thing to do. Most broadcast video is YUV 16..235, as defined by ITU.601. So technically the WMV is correctly encoded. The issue is a much broader one: what's the correct way to decode video on a PC? Most PC displays are calibrated for 0..255. If YUV 16..235 is decoded as RGB 16..235, then it looks washed out. However, if you take the same video and play it back through your card's S-video out, it will probably look correct because your TV is (hopefully) calibrated for 16..235.

I would recommend leaving the luma range as is and compensating in your decoder, video driver or display instead.

[chros]

Originally Posted by zambelli

I would recommend leaving the luma range as is and compensating in your decoder, video driver or display instead.

Can you describe how? In the case wmvideo decoder?
And there are other sources from Apple (eg. Eragon 132MB, District B13, and the others), where the black is non-black.
I have tried this function, but I don't know if it's reliable. If I'm right it's strechs out the black range... Or the whole range?

Levels(3, 1, 255, 0, 255, coring=false)

Originally Posted by chros

Regardning 7b (when muxing into mp4):
there are some clips, where after the encoding the audio isn't synched...
So I don't know if tc2mp4 or mp4box mistaken ... The clips are in common: they have 2ch 44100 Hz audio.

I have upsampled the audio with this, but it's the same, so I don't know what is going on.:

SSRC(last, 48000)

Strange is that when I mux with mkvmerge the tc2mp4 craeted vfr video and the audio: it's perfectly synched. So it seems that mp4box creates something wrong ...

Originally Posted by foxyshadis

Still, there might be some deeper bizarro problem...

To summarize when we come across a vfr content: it seems that if directshowsource() gets a frame it encode it, and it doesn't know about how long it must be displayed (like a player). So it encodes all the gotten frames. And we must later specify that which frame how long must be displayed through the timcode file.

The tricky part is how can we gain the timecode file from the source.
wmv: WMVTIMES.exe
mkv: mkvextract.exe

Is there any tool for this in case of mp4 and realmedia?

@Wilbert: I have find your Variable FrameRate Video tutorial - thanks for it - (in google cache, since avisynth.org is down, date: 10 May 2006, so I don't know if these infos are up-to-date, but if they are)
You can update the following sections:
- Encoding to vfr (mp4)
- Opening non-avi vfr content in AviSynth and - reencoding to vfr

[zambelli]

Originally Posted by chros

Can you describe how? In the case wmvideo decoder?

If you use MPC or Zoom or some other player that lets you pick the video renderer, try switching between Overlay and VMR9, apparently it makes a difference. See:
http://forum.doom9.org/showthread.ph...362#post808362

I have tried this function, but I don't know if it's reliable. If I'm right it's strechs out the black range... Or the whole range?

Levels(3, 1, 255, 0, 255, coring=false)

If you want to adjust the levels in preprocessing, use:

PHP Code:

ColorYUV(levels="TV->PC") 


But like I said, a 16..235 encoded luma range is not wrong - it's the expected way to encode video.

[IanB]

Try this updated DSS.dll http://forum.doom9.org/showthread.php?t=118715

[chros]

Originally Posted by IanB

Try this updated DSS.dll http://forum.doom9.org/showthread.php?t=118715

Thanks!