First of all, do excuse me as I have absolutely no idea where to go to report bugs in either Windows Media Player, or the Microsoft's Media Foundation filters that most probably handle the actual parsing and decoding. I see that some related bug reports have gotten noticed here on the Technet forums, and thus ended up writing here.

Some time ago I helped a fellow internet user to update his encoding pipe line from quite an older version of ffmpeg and libx264 to a newer one. After some testing, I noticed him being unhappy with the result because of "black borders" around the video clip, but only in WMP12, not in other players. Being interested in what this was, I went on and started checking out the behavior.

What I found out is that, with the newer ffmpeg and libx264, WMP12 was only seeing the video resolution (which was 1440x1080) at first, and resized/matched the player window according to that. Only after that did it then, within this window, actually show the video and apply the correct aspect ratio to it (4:3 sample/pixel aspect ratio, or 16:9 display aspect ratio). In other words, the video would play correctly, but within a 4:3 display aspect ratio video surface, leading to black bars on the top and the bottom.

Now, if you manually resize the window, the black borders would of course go away. This is because they were not part of the video, but just something the player had based its window size calculations on originally. With the older ffmpeg + libx264 mix things would Just Work, and the auto-sizing worked.

So I went off to look up all the data in the files that could relate to aspect ratio :) .

1. [tkhd: Track Header Box] in the container has the width and height set to 1920x1080 in both files, so this is most probably ignored
2. [pasp: Pixel Aspect Ratio Box] in the container is only present in the new one, and thus most probably ignored. hSpacing and vSpacing are set to 4 and 3, thus becoming 4:3 (this is the pixel or sample aspect ratio, so this is correct for 1440x1080 to be shown as 16:9). This information, if available, should trump the aspect ratio information in the stream (a quote from ISO/IEC 14496-12: "These (pasp and clap boxes) are both optional; if present, they over-ride the declarations (if any) in structures specific to the video codec, which structures should be examined if these boxes are absent.") .
   
3. In the actual AVC/H.264 stream both files have aspect_ratio_idc set. The older file has the value set to 255 (Extended_SAR structure follows), and Extended_SAR then contains sar_width set to 4 and sar_height set to 3. On the newer file, on the other hand, we have a value of 14. Looking at the H.264 specification, value 14 is defined as "4:3 , 1440x1080 16:9 frame without horizontal overscan"

So... Since the pasp box seems to be completely irrelevant and ignored, and since the tkhd box contains exactly the same information in both cases and thus seems to be ignored, the only thing that comes to mind is that:

1. Only the information from the AVC/H.264 video stream is actually taken into mention at this stage.
2. The AVC/H.264 video stream parser does not know the aspect_ratio_idc value 14.

I haven't actually tried to change the values in the parameter set's VUI parameters around to be sure of this being the reason, but, unless WMP misunderstands what the pasp box's value means (4:3 read as the aspect ratio for the whole picture, instead of one sample/pixel), that's the only reason I can see this happening because of.

A small sample mp4 file for this issue is provided at fushizen.eu/samples/wmp12_mp4/merry_christmas.mp4 . Having the automatic zoom set to 50% does help replicating it with smaller displays :) . WMP will resize its video window to a 4:3 display aspect ratio, and then show the 16:9 display aspect ratio content within that. This happens with both Windows 8.1 as well as Windows 7, on Windows Media Player 12.

Now, if the issue is actually on ffmpeg's or libx264's side, feel free to note the technical problems with the sample, and I will review and then report them if I see the related specifications agreeing on the issue. So far this seems to be purely a problem with the related Media Foundation filters, and/or Windows Media Player 12.

I have a lot of grief with this version of Windows Media Player.

It is very buggy and frustrating to use.

I have my Music library on a QNAP NAS, which is as reliable as they come.

System notifications make it not save changes.  It also does not do a good job of interpreting albums and artists from folders.  Changes to track names are not saved, nor are tracks moved to other albums, renamed albums, changes to genre, artist or date.Some changes I've made up to 4 times, then closed WMP and re-started my machine to check if it has/hasn't saved the changes.  Often it has not.

This is the first time I've used WMP in this capacity, and I do not recommend it.

New service pack please.

I have a lot of grief with this version of Windows Media Player.

It is very buggy and frustrating to use.

I have my Music library on a QNAP NAS, which is as reliable as they come.

System notifications make it not save changes.  It also does not do a good job of interpreting albums and artists from folders.  Changes to track names are not saved, nor are tracks moved to other albums, renamed albums, changes to genre, artist or date.  It separates and merges albums/tracks without sense or reason.  Some changes I've made up to 4 times, then closed WMP and re-started my machine to check if it has/hasn't saved the changes.  Often it has not.

This is the first time I've used WMP in this capacity, and I do not recommend it.

New service pack please.

• Edited by robynnw 23 hours 22 minutes ago