[YAMJ] Any reason VC-1 codec is being returned with a video codec entry of 'Microsoft'?

[plm]

Is there any particular reason the VC-1 codec is being returned in the XML files with a video codec of 'Microsoft'?

The other codecs you find in BluRays return more detailed information than a generic Microsoft codec which could actually refer to more than video codec type depending on the source video type.

As an example AVC returns the following:
<videoCodec>V_MPEG4/ISO/AVC</videoCodec>
<codec codecId="V_MPEG4/ISO/AVC" codecIdHint="UNKNOWN" format="AVC" formatProfile="High@L4.1" formatVersion="UNKNOWN">V_MPEG4/ISO/AVC</codec>

whereas VC-1 returns this:
<videoCodec>Microsoft</videoCodec>
<codec codecId="WVC1" codecIdHint="Microsoft" format="VC-1" formatProfile="AP@L3" formatVersion="UNKNOWN">WVC1</codec>

A return value of VC-1, in my opinion, would be far more informative and allow the skin to definitively return the proper codec rather than having to make an assumption that Microsoft means VC-1 or having to parse the individual codec lines.

[accident]

It's been that way since mediainfo was added to yamj..

It's only recently that the new codec section was added and still identifying the best way to utilize it.

[plm]

I'm just trying to figure out whether it would make sense to return VC-1 in this case in the video codec summary line since the other codecs seem to return that level of detail, and also whether this would likely break other skins.

If it looks good then I'll stick in an enhancement request, but I don't want to break things for everyone else just to make it easier for me!

[kollegah1338]

This was changed due to issues with other Codecs.
See here:
https://code.google.com/p/moviejukebox/i...il?id=2271
This broke most old skins so it was changed.

What does WMV video returns? Also "Microsoft"? If yes, this should be looked at and changed, if not then just think of Microsoft as VC1.

e:
The codec section has quite a lot of bugs anyway so maybe those should be fixed first before concentrating on these less important things.
(See here: https://code.google.com/p/moviejukebox/i...il?id=2269
Same problem exists for video too)

[plm]

(02-29-2012 11:43 PM)kollegah1338 Wrote:  What does WMV video returns? Also "Microsoft"? If yes, this should be looked at and changed, if not then just think of Microsoft as VC1.

I don't really use WMV for anything so I only have a handful of files on my PC.

The ones I looked at returned codecs as follows:

<videoCodec>WMV3</videoCodec>
<codec bitrate="1160" codecId="WMV3" codecIdHint="WMV3" format="VC-1" formatProfile="MP@ML" formatVersion="UNKNOWN">WMV3</codec>

<videoCodec>Windows</videoCodec>
<codec bitrate="96" codecId="MSS1" codecIdHint="Windows" format="Screen Video" formatProfile="UNKNOWN" formatVersion="UNKNOWN">MSS1</codec>

<videoCodec>WMV1</videoCodec>
<codec bitrate="1019" codecId="WMV1" codecIdHint="UNKNOWN" format="WMV1" formatProfile="UNKNOWN" formatVersion="UNKNOWN">WMV1</codec>

So it might be safe to assume to Microsoft = VC-1 but I've no idea how exhaustive this list is.

[accident]

It's not really that cut and dry but yes there is more information available now so it can be made more reliable to actually reflect the real codec in use. It's just a matter of skins adapting to it. Eversion already uses the new data for some of the audio, but this is the first case of someone noticing a video codec that could be improved.

[plm]

My personal take, and this is why I opened this for debate, is that YAMJ should put VC-1 in the summary codec line rather than Microsoft, because that represents a broadly similar level of detail to what it does for the other codecs that you'll find on DVDs and BluRays (excuse me not being interested in downloads and other sources, but I'm dealing with a library of commercial content only).

If that's likely to cause problems elsewhere then I can understand why we stick with Microsoft and try to do something in the skin from the detailed codec information, but otherwise I think this is a YAMJ feature request.

Anyone say different?

[accident]

Your idea was already tired, accidently, but it broke everything existing because suddenly there was different data. for the skins that just showed the data, it was better. for everything that translated it into icons or friendlier names completely broke all codec display.

The xml is also the "raw data" that yamj works with. Not the presentation that the skins turn it into. So the new codec information is the important few fields from mediainfo that are needed to correctly identify everything. But it's a procress for skinners, with no help, to figure out all the combinations and convert that into something useful. Your looking at the 1 or 2 codecs you have in your library but if you stretch it out, it's not as simple as "use this field" because on other codecs it's even more generic than the microsoft you in the case of vc-1.

nothing needs to change with yamj, just skinners working with the data to sort it all out to improve the skins with the new information available.

[plm]

(03-01-2012 05:15 AM)accident Wrote:  Your idea was already tired, accidently, but it broke everything existing because suddenly there was different data. for the skins that just showed the data, it was better. for everything that translated it into icons or friendlier names completely broke all codec display.

I hardly think it would 'break everything' by changing the behaviour for this one, specific codec. The worst case is HTML skins which don't recognise the VC-1 codec would display blank, like evstreamed does for Microsoft now.

You've said yourself that you don't want to associate Microsoft with VC-1 because it's too generic and could refer to other codecs from Microsoft, so by that token other skins shouldn't either. And the data YAMJ returns should be broadly uniform whatever the codec, i.e. returning the codec type rather than the vendor.

The worst I could see happening would be a few HTML skins probably ought to be updated would fail to display an image when they encountered a genuine VC-1 file if they didn't already have an icon for this file type alongside the Microsoft one. Or am I missing something?

[Omertron]

(03-01-2012 08:02 AM)plm Wrote:  

(03-01-2012 05:15 AM)accident Wrote:  Your idea was already tired, accidently, but it broke everything existing because suddenly there was different data. for the skins that just showed the data, it was better. for everything that translated it into icons or friendlier names completely broke all codec display.

I hardly think it would 'break everything' by changing the behaviour for this one, specific codec. The worst case is HTML skins which don't recognise the VC-1 codec would display blank, like evstreamed does for Microsoft now.

[/quote]
I'm not changing the behaviour for a single codec. The information that is provided in the "videocodec" and "audiocodec" sections of the XML are the same as they always have been, they are derived from a best guess about the level of importance of the data available for a given codec.

Newer skins should not be using that field, as you've pointed out, it's inaccurate in some cases. All the information that YAMJ can get about the codec is now in the video section of the codec part of the XML. The choice is then up to the skin on how they present that information to the user.

Quote:The worst I could see happening would be a few HTML skins probably ought to be updated would fail to display an image when they encountered a genuine VC-1 file if they didn't already have an icon for this file type alongside the Microsoft one. Or am I missing something?

The worst for you. Not for the people that use those skins.

[plm]

(03-01-2012 10:40 AM)Omertron Wrote:  I'm not changing the behaviour for a single codec. The information that is provided in the "videocodec" and "audiocodec" sections of the XML are the same as they always have been, they are derived from a best guess about the level of importance of the data available for a given codec.

Newer skins should not be using that field, as you've pointed out, it's inaccurate in some cases. All the information that YAMJ can get about the codec is now in the video section of the codec part of the XML. The choice is then up to the skin on how they present that information to the user.

Okay, it's your call, but you are currently presenting different data depending on the codec. You're returning codecIdHint for VC-1 and codecID for others, so it's inconsistent. And if Eversion, which is probably the newest skin out there, is using it then it sounds like no-one's told Accident he shouldn't be using this field.

But, that aside, the individual video codec information in the XML files might not be 100% reliable at the moment.

Here's the mediainfo for one file I pulled at random:

Code:

General
Unique ID                                : 66742821165764788192189571856596489220 (0x3236332526367F86A96F883177585404)
Format                                   : Matroska
Format version                           : Version 2
File size                                : 1.07 GiB
Duration                                 : 42mn 1s
Overall bit rate                         : 3 643 Kbps
Encoded date                             : UTC 2011-08-09 02:49:45
Writing application                      : mkvmerge v4.8.0 ('I Got The...') built on Jun 13 2011 20:36:23
Writing library                          : libebml v1.2.0 + libmatroska v1.1.0

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4.1
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 5 frames
Muxing mode                              : Header stripping
Codec ID                                 : V_MPEG4/ISO/AVC
Duration                                 : 42mn 1s
Bit rate                                 : 3 187 Kbps
Width                                    : 1 280 pixels
Height                                   : 714 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 23.976 fps
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.145
Stream size                              : 958 MiB (87%)
Writing library                          : x264 core 116 r2044 392e762
Encoding settings                        : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=16 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=20.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Language                                 : English
Default                                  : Yes
Forced                                   : No

Audio
ID                                       : 2
Format                                   : AC-3
Format/Info                              : Audio Coding 3
Mode extension                           : CM (complete main)
Muxing mode                              : Header stripping
Codec ID                                 : A_AC3
Duration                                 : 42mn 1s
Bit rate mode                            : Constant
Bit rate                                 : 384 Kbps
Channel(s)                               : 6 channels
Channel positions                        : Front: L C R, Side: L R, LFE
Sampling rate                            : 48.0 KHz
Bit depth                                : 16 bits
Compression mode                         : Lossy
Stream size                              : 115 MiB (11%)
Default                                  : Yes
Forced                                   : No

and here's the corresponding XML section:

Code:

<video count="2">
            <codec codecId="UNKNOWN" codecIdHint="UNKNOWN" format="UNKNOWN"
                   formatProfile="UNKNOWN"
                   formatVersion="UNKNOWN">H.264</codec>
            <codec codecId="V_MPEG4/ISO/AVC" codecIdHint="UNKNOWN" format="AVC"
                   formatProfile="High@L4.1"
                   formatVersion="UNKNOWN">V_MPEG4/ISO/AVC</codec>
         </video>

You can see that there are two video codec entries despite the single one returned by mediainfo, which doesn't make presenting the information any easier.

I'm not actually massively concerned whether the solution needs to be in YAMJ or Eversion but I do care about whether I get accurate information returned and displayed since, when I have issues with files, I shouldn't have to need to dive into the xml (or seemingly mediainfo) to find out what the file actually contains.

So if you're saying that VideoCodec is deprecated and shouldn't be used then this should really be communicated so skin builders change their operational behaviour to parse the individual video codec lines, which I think is a shame since new skins (certainly any for the Popcorn Hour family) are all likely to be Flash-based, which means more processing time taken on the fly to delve into the codec list when generating pages rather than just picking off what should be the helpful summary line that's already provided.

[kollegah1338]

(03-01-2012 06:59 PM)plm Wrote:  [...]
and here's the corresponding XML section:

Code:

<video count="2">
            <codec codecId="UNKNOWN" codecIdHint="UNKNOWN" format="UNKNOWN"
                   formatProfile="UNKNOWN"
                   formatVersion="UNKNOWN">H.264</codec>
            <codec codecId="V_MPEG4/ISO/AVC" codecIdHint="UNKNOWN" format="AVC"
                   formatProfile="High@L4.1"
                   formatVersion="UNKNOWN">V_MPEG4/ISO/AVC</codec>
         </video>

You can see that there are two video codec entries despite the single one returned by mediainfo, which doesn't make presenting the information any easier.
[...]

I already pointed out that there is an issue with the codec section in my post and even gave a link to the logged issue @Google Code. Why don't you just read your own thread?
Because of that bug most skin makers (or Eversion specifically) probably didn't implement this. At the moment you'd have to implement a workaround to exclude the "UNKNOWN" codecs, both for video and for audio. If this bug is fixed, you don't need that anymore. Until then the "old" videoCodec will be enough.

[plm]

(03-01-2012 07:21 PM)kollegah1338 Wrote:  I already pointed out that there is an issue with the codec section in my post and even gave a link to the logged issue @Google Code. Why don't you just read your own thread?

Yes, I did read it. Thanks for your condescension.

The point is Omertron is telling skin users not to use the VideoCodec line because it may be unreliable and he doesn't want to change it but the data he's saying to use is unreliable unless you implement a workaround too.

All this means more processing time spent in the XML files by Eversion when trying to render pages, which would be better dealt with by fixing the data at source.

(03-01-2012 07:21 PM)kollegah1338 Wrote:  Until then the "old" videoCodec will be enough.

Enough for you, maybe. But who made you the arbiter of what's enough for everyone? I want to know specifically which codec is in each of my files. I use it for testing. The information currently available doesn't tell me that, so it's not enough.

[kollegah1338]

(03-01-2012 07:44 PM)plm Wrote:  [...]
Yes, I did read it. Thanks for your condescension.

The point is Omertron is telling skin users not to use the VideoCodec line because it may be unreliable and he doesn't want to change it but the data he's saying to use is unreliable unless you implement a workaround too.

All this means more processing time spent in the XML files by Eversion when trying to render pages, which would be better dealt with by fixing the data at source.
[...]

It will be fixed eventually. It also won't change processing time in a measurable way if you use the more detailed codec block instead of the videocodec field.

(03-01-2012 07:44 PM)plm Wrote:  [...]
Enough for you, maybe. But who made you the arbiter of what's enough for everyone? I want to know specifically which codec is in each of my files. I use it for testing. The information currently available doesn't tell me that, so it's not enough.

YAMJ is open source for a reason. If you desperately need that bug fixed go ahead and change it yourself or pay someone to do it.

[halfelite]

All the mediainfo data is unreliable, anything VC-1 made with mkvtoolnix reports back as VC-1 (Microsoft) then mux VC-1 with tsmuxer and it will just report back VC-1

There is no one fix will fix everything. Different tools report different information in different fields that best you can do is try to work around it. In eversion you can always do if then, If codecid = WVC1 then display.........