how to fix these weird 1440x1080 wmv's

[jagabo]

In gspot 2.70a, it shows a PAR of 4:3 and DAR of 1.78. Are you using a different file?

Weird, GSpot 2.70a on my computers says it 1.0 PAR:



And WMP 11 plays it 4:3.

[poisondeathray]

So the plot thickens. Can you open your stream in graphstudio ? There's probably some system installed codec differences. I'm using WMAudio and WMVideo Decoder DMO, splitter/source filter is qasf.dll.

Also MPCHC, the way I have it configured plays it as 4:3 - how do you have it configured jagabo?

[poisondeathray]

The way I would generate non square pixel WMV would be avisynth, wmnicenc, wm stream editor, and wmarchanger

Here is 1sec of that clip re-encoded, and the 1440x1080 plays 1920x1080 in all players I tested.

Why your original clip can't be "fixed" with wmarchanger is beyond me. It might be because it's truncated?

re-encoded.wmv

[deadrats]

In gspot 2.70a, it shows a PAR of 4:3 and DAR of 1.78. Are you using a different file?

nope, same file, both the source and the sample show as having a PAR of 1:1 and a DAR of 4:3.

What encoder are you using? Are you encoding to WMV again?

tmpg express and target's i have tried are mpeg-2, h264 (main concept's) and divx, haven't tried wmv yet.

[jagabo]

So the plot thickens. Can you open your stream in graphstudio ? There's probably some system installed codec differences. I'm using WMAudio and WMVideo Decoder DMO, splitter/source filter is qasf.dll.

Same here. WM ASF Reader (qasf.dll) is version 9.0.0.4503.

Before rendering the graph VIDEOINFOHEADER2 indicates dwPictAspectRatioX is 0x5a0, and dwPictAspectRatioY is 0x438 (1440:1088 --> 4:3). After rendering the graph they change to 0x1680 and 0xca0 (5760:3240 --> 16:9). That information passed to the input pin of WMV Video Decoder DMO (same version number) but the output pin from that filter remains 1440x1080.

Also MPCHC, the way I have it configured plays it as 4:3 - how do you have it configured jagabo?

MPCHC is using WM ASF Reader to open the file but is using its internal WMV1/2/3 decoder. If I disable the internal WMV decoder it uses WMV Video Decoder DMO and displays 4:3 instead of 16:9.

[poisondeathray]

my qasf.dll version is 11.0.5721.5145 ; I'm assuming the 11 means from WMP11, and your 9.X is from WMP9 ?

My dwPictAspectRatioX is 0x5a0, and dwPictAspectRatioY is 0x438 all the way through, even the output of WMVideo Decoder DMO, and to the renderer input

My WMVideo Decoder DMO version is 11.0.5721.5145 as well

[deadrats]

deadrats - you seem to be using words you don't understand. the PAR - pixel aspect ratio - of a 1440x1080 widescreen video is 1.33333 so it's not "lying" to the encoder, but telling it to treat the video properly.

and no, before you whine that 1.33333 is 4:3, it's not in pixel aspect ratio terms. par only relates to the shape of the pixel not it's output on a monitor.

you seem to have misread what i wrote, thereby leading you to the erroneous conclusion that i use words i don't understand, so if you will indulge me:

pixel aspect ratio refers to the ratio between the length and the height of a pixel, i think we can all agree on this. if you have a file with a resolution of 1440x1080 with square pixels the display aspect ratio is 1440/1080 or 1.333, if a 1440x1080 file is using the correct 4:3 shaped pixels then the display aspect ratio is (1440*4)/(1080*3) or 1.778.

in the case of these files the only way the final encode comes out with a display aspect ratio of 1.778, which is the dar of a file with a resolution of 1280x720, 1920x1080, 960x540, if they are using square pixels (1280/720, 1920/1080 and 960/540 all equal 1.778, if you do the math) is by telling the encoder that the source has a resolution of 1440x1080 and is using 16:9 pixels, which, if that were the case, would result in a video with an aspect ratio of (1440*16)/(1080*9) or a final dar of 2.37.

in other words the only way i can seem to get the encoder to treat my source as having a dar of 1.78 is if i in fact tell it that the dar is 2.37, in which case it treats it like a properly encoded 1440x1080 with 4:3 pixels, when in fact it shouldn't, it should treat it as a 1440x1080 16:9, which it's not, as evidenced by the fact that it plays back pillar boxed and gspot says that it's an incorrect aspect ratio.

capice?

[deadrats]

The way I would generate non square pixel WMV would be avisynth, wmnicenc, wm stream editor, and wmarchanger

Here is 1sec of that clip re-encoded, and the 1440x1080 plays 1920x1080 in all players I tested.

Why your original clip can't be "fixed" with wmarchanger is beyond me. It might be because it's truncated?

re-encoded.wmv

ok, now how did you pull that off?

[jagabo]

my qasf.dll version is 11.0.5721.5145 ; I'm assuming the 11 means from WMP11, and your 9.X is from WMP9 ?

Yes, I suspect the 9x version number means it's from WMP9. But I have WMP 11 installed. I suspect the 9x filters come from the WMV 9 VCM I installed to get the VFW encoder. Maybe deadrats did the same.

[poisondeathray]

The way I would generate non square pixel WMV would be avisynth, wmnicenc, wm stream editor, and wmarchanger

Here is 1sec of that clip re-encoded, and the 1440x1080 plays 1920x1080 in all players I tested.

Why your original clip can't be "fixed" with wmarchanger is beyond me. It might be because it's truncated?

re-encoded.wmv

ok, now how did you pull that off?

I encoded a 1:1 square pixel 1440x1080 wmv file using avisynth and wmnicenc, used wm stream editor to make the stream "legit", then used wmvarchanger to specify the PAR to 4:3. This is the way I would do it. There is definitely something funky going on with that sample, but it does play properly in WMP11 for me. I would always avoid WMM if that is indeed what they used to make the file

Almost another topic, but if you look above, there are some differences in how our systems are rendering the file. My gspot is reading differently than yours, probably because of the installed filter differences.

[poisondeathray]

my qasf.dll version is 11.0.5721.5145 ; I'm assuming the 11 means from WMP11, and your 9.X is from WMP9 ?

Yes, I suspect the 9x version number means it's from WMP9. But I have WMP 11 installed. I suspect the 9x filters come from the WMV 9 VCM I installed to get the VFW encoder. Maybe deadrats did the same.

Interesting theory, but I have WMV9 VCM installed as well...

[jagabo]

Interesting theory, but I have WMV9 VCM installed as well...

Are you running XP or something newer? I'm running XP Pro SP3.

[poisondeathray]

Interesting theory, but I have WMV9 VCM installed as well...

Are you running XP or something newer? I'm running XP Pro SP3.

No, I have XP on this one

[jagabo]

Uninstalled WMP 11, reinstalled WMP 11. GraphStudio shows version 11 filters. Still 4:3 display. Fiddled with WMP Tools -> Options -> Performance -> Video Acceleration -> Advanced... and found that disabling "Turn on DirectX Video Acceleration" finally gave a 16:9 display in WMP. But GSpot still says PAR 1.0. And GraphStudio still renders 4:3 DAR. Very strange.

[aedipuss]

1440x1080 w/1.3333 par is the standard wmv9 HD template in vegas. the piece of file we have to play with doesn't have all the video info normally stored at the end of a wmv. that seems to be why most software can't get a grip on it.



deadrats-
a 1440x1080 video with a par of 1.333 is = a 1920x1080 video with a par of 1.0(square pixels) and both videos have a DAR of 1.78(16/9)

[jagabo]

1440x1080 w/1.3333 par is the standard wmv9 HD template in vegas.

Probably because it matches HDV.

[poisondeathray]

Sorry I made a mistake with the gspot screenshot . It was actually patched with wmarchanger - this program doesn't rename the file or make a copy of the output so I forgot that I overwrote it (and deadrats said it didn't work). If you compare jagabo's screenshot, his says "file truncated", but mine didn't - so that clued me in on something was different. When I re-downloaded the file from mediafire it has PAR of 1.0 too in gspot

The native unpatched file still renders 16:9 in graphstudio, wmp11, kmplayer for me, but not the other players. I wonder if patching it with the full file (instead of a cut/truncated one) would work? deadrats said it didn't, but I'm not sure if that was the full file or a cut file

[aedipuss]

1440x1080 w/1.3333 par is the standard wmv9 HD template in vegas.

Probably because it matches HDV.

makes sense. you could shoot in HDV and encode to HD wmv with no resizing.

[El Heggunte]

Q.: how to fix these weird 1440x1080 wmv's ?

A.:: It depends.

If you intend to view them with WMP 9 or higher, then they don't need to be "fixed".

BTW, don't ever dare to cut/join ASF files with any other tool than AsfBin.

(the header of your sample video says it's 24-minute long,
even though it has less than 1000 frames).

But if you're sane enough to disapprove the WMP way of doing things ,
then there are only two viable options: a) remux the "bad" videos into MKV files;
b) re-encode them.

Another BTW: if someone really wants/needs to encode video with non-square pixels,
the only safe choice, AFAIK, is to choose MPEG-2 compression.

[deadrats]

1440x1080 w/1.3333 par is the standard wmv9 HD template in vegas. the piece of file we have to play with doesn't have all the video info normally stored at the end of a wmv. that seems to be why most software can't get a grip on it.

deadrats-
a 1440x1080 video with a par of 1.333 is = a 1920x1080 video with a par of 1.0(square pixels) and both videos have a DAR of 1.78(16/9)

i am well aware of this, a PAR of 4:3 is the same as a PAR of 1.333, it's just a different way of expressing the same idea. as i already stated, HD video streams, at least as far as HDTV is concerned, are supposed to have a DAR of 1.78, 720p/i and 1080p/i both use square pixels to achieve this DAR, 1440x1080 uses 4:3 pixels to achieve a DAR of 1.78, but as i have already pointed out, these files seem to be using square pixels which results in an incorrect DAR and complicating matters, the only way i can seem to get the encoder to produce output with a proper 1.78 ratio is if i trick it into believing that the source has a DAR of 2.37, when it clearly does not.

that's what's driving me up the wall.

[deadrats]

I wonder if patching it with the full file (instead of a cut/truncated one) would work? deadrats said it didn't, but I'm not sure if that was the full file or a cut file

i actually didn't try patching the cut file, i only tried to patch the full file, it "pretends" to make the changes but when i try it out nothing has changed.

if it wasn't against the rules of this forum, i would just upload the whole thing so that you guys could play with it, er, i am talking about playing with the file, not anything else.

[deadrats]

If you intend to view them with WMP 9 or higher, then they don't need to be "fixed".

as i already noted i need them to be blu-ray compliant files, which means eventually they have to be in a m2ts container, at a blu-ray compliant resolution and codec. vc-1 is fine, i just need to fix that weird aspect ratio problem.

then there are only two viable options: a) remux the "bad" videos into MKV files;
b) re-encode them.

how would i go about remuxing them into mkv's?

Another BTW: if someone really wants/needs to encode video with non-square pixels,
the only safe choice, AFAIK, is to choose MPEG-2 compression.

kind of perplexed by this statement, i have no problem with re-encoding to mpeg-2 but why would you say that mpeg-2 is the only safe choice when using non-square pixels, i have seen plenty of h264, mpeg-4 and wmv files with non-square pixels that are perfectly fine.

[aedipuss]

1440x1080 w/1.3333 par is the standard wmv9 HD template in vegas. the piece of file we have to play with doesn't have all the video info normally stored at the end of a wmv. that seems to be why most software can't get a grip on it.

deadrats-
a 1440x1080 video with a par of 1.333 is = a 1920x1080 video with a par of 1.0(square pixels) and both videos have a DAR of 1.78(16/9)

i am well aware of this, a PAR of 4:3 is the same as a PAR of 1.333, it's just a different way of expressing the same idea. as i already stated, HD video streams, at least as far as HDTV is concerned, are supposed to have a DAR of 1.78, 720p/i and 1080p/i both use square pixels to achieve this DAR, 1440x1080 uses 4:3 pixels to achieve a DAR of 1.78, but as i have already pointed out, these files seem to be using square pixels which results in an incorrect DAR and complicating matters, the only way i can seem to get the encoder to produce output with a proper 1.78 ratio is if i trick it into believing that the source has a DAR of 2.37, when it clearly does not.

that's what's driving me up the wall.

no that's not correct HDTV can use non-square pixels. 1440x1080 is allowed.

[jagabo]

aedipuss is correct. 1440x1080 with 4:3 PAR is valid for Blu-ray and is often used in production. Dish, DirecTV, and cable companies also use it.

[deadrats]

aedipuss is correct. 1440x1080 with 4:3 PAR is valid for Blu-ray and is often used in production. Dish, DirecTV, and cable companies also use it.

very good, so 1440x1080 with 4:3 pixels is valid for blu-ray, fabulous, maybe i'll just trick tmpg express and re-encode them to with the correct par.

[El Heggunte]

If you intend to view them with WMP 9 or higher, then they don't need to be "fixed".

as i already noted i need them to be blu-ray compliant files, which means eventually they have to be in a m2ts container, at a blu-ray compliant resolution and codec. vc-1 is fine, i just need to fix that weird aspect ratio problem.

So you'll have to re-encode that video anyhow, really. As its 4cc says, it's not WVC1,
but WMV3, and WMV3-compression is not "Blu-Ray compliant".
Besides, I'd recommend H264 instead of VC-1, unless you manage to find an encoder
which uses a "non-Microsoftic" implementation of the VC-1 standard. As it was already stated in
this thread, the "Microsoft way" does have "optimized the VC-1 codec for the ASF container",

which means your VC-1 encodes possibly will have dropped and duplicate frames
(OK, you might not even notice the issue while watching the re-encoded video,
but hey, ...)

P.S.: Also, it seems you want to make things more complicated than they are.
If you feed your chosen encoder with a properly-written Avisynth script,
there is no need for finding out "tricks", hex edits, and other "exotic" workarounds.

then there are only two viable options: a) remux the "bad" videos into MKV files;
b) re-encode them.

how would i go about remuxing them into mkv's?

Another BTW: if someone really wants/needs to encode video with non-square pixels,
the only safe choice, AFAIK, is to choose MPEG-2 compression.

kind of perplexed by this statement, i have no problem with re-encoding to mpeg-2 but why would you say that mpeg-2 is the only safe choice when using non-square pixels, i have seen plenty of h264, mpeg-4 and wmv files with non-square pixels that are perfectly fine.

I was thinking about playback on a PC --- apologies for not being clear enough.

[duhmez]

It sounds like perhaps a wrong checkbox was clicked in the "source aspect ratio" and or "pixel aspect ratio" setting, resulting in extra black bars being inserted.

I first ran into this problem way back when I was a noob using Tmpgenc and mpeg 2. Very squishy vids with extra black bars.