[Freddo]

I know I'm probably the only person on the planet using it for video but if it wouldn't be too much bother could FLAC be a supported audio format for the flagging?



I'd really appreciate it.

[CapnBry]

Since information like mpeg4-xvid, mpeg4-dx50 wouldn't hurt the only real question is: How difficult is it to implement that? I wouldn't want you to do some crazy hacking just to dig out that information. But if it is easily available...

My argument is that it would hurt. You're now forcing anyone who wants to have their own skin flags to have all of them instead of just one mpeg4 one. Adding another ListItem.VideoFourCC is crappy because fourcc isn't present in a lot of content so now you're writing heavy conditionals in your skin as a workaround and amount of CPU time required to just render the skin is currently going through the roof. That's a trend I'd like to see stop.

Yes there are ways around these issues, believe me I've spent more time thinking about how this should work than anyone in this thread, but the more you want to add, the messier it gets in ways that make me feel like an awful VB programmer. So why don't we just stick with "keep it simple, stupid" and grow from there later.

[ronie]

LOL, sorry for that. Well those that want to check the container can at just use substring(listitem.filename,.mkv,Right)

well, there's nothing wrong with that. i'm using exactly this way in the Transparency! skin to display a codec logo for items in the music library. (me likes eye-candy) ;-)

My primary reason for having the icons based on the FOURCC would be diversity. Having ~95% of all movies showing the same ffmpeg image is kinda boring:

Code:

Video:    mpeg4        1027
    msmpeg4        348
    h264        75
    msmpeg4v2    1
    mpeg1video    9
    flv        1

You are of course right, that there needs to be a limit to what is available and what is just plain stupid additional information. Since many users might be used to the information which MIP makes available it could make adoption faster if the new code can provide the same information as a start.

couldn't have said it better myself. if you want people to adopt something new, just make it as good as (or possibly better) than what's already available.

Since information like mpeg4-xvid, mpeg4-dx50 wouldn't hurt the only real question is: How difficult is it to implement that? I wouldn't want you to do some crazy hacking just to dig out that information. But if it is easily available...

Well since CapnBry already said he didn't feel like doing this, i'm perfectly fine with his decision.
After all, it's his code, so he should take it any direction he sees fit.

[ccMatrix]

My argument is that it would hurt. You're now forcing anyone who wants to have their own skin flags to have all of them instead of just one mpeg4 one. Adding another ListItem.VideoFourCC is crappy because fourcc isn't present in a lot of content so now you're writing heavy conditionals in your skin as a workaround and amount of CPU time required to just render the skin is currently going through the roof. That's a trend I'd like to see stop.

Yes there are ways around these issues, believe me I've spent more time thinking about how this should work than anyone in this thread, but the more you want to add, the messier it gets in ways that make me feel like an awful VB programmer. So why don't we just stick with "keep it simple, stupid" and grow from there later.

Ok, fair enough. Since I'm currently renaming all the studio logo files to get rid of all the conditions in Aeons mediaflags file I can understand your reasoning of keeping just the mpeg4 one.

One small question about the currently returned codecs: What is the difference between the returned codecs mpeg4, msmpeg4 and msmpeg4v2 ?

[mkortstiege]

What about keeping this a development thread? If you would like to chat/discuss about the flagging feature please create a new one or use the aeon (if related) sub forum. Thanks.

[lx01]

My argument is that it would hurt. You're now forcing anyone who wants to have their own skin flags to have all of them instead of just one mpeg4 one.

But don't you do that yourself by differentiating between mpeg4 and h264 (which is also mpeg4, just a different part)?

I just think that the current solution is somewhat inconsistent:
For DivX/XVID you're displaying a whole family of coding standards ("mpeg4") for what is really just a part of that family (Part 2 "MPEG4 ASP"), while for another part of that family you're displaying the actual codec.

I think a more correct solution would be either:
- always display the actual codec used for encoding (like suggested before) or
- only display the used mp4 profile (rename "mpeg4" to "mpeg4 asp" and rename "h264" to "mpeg4 avc")

[ccMatrix]

But don't you do that yourself by differentiating between mpeg4 and h264 (which is also mpeg4, just a different part)?

I just think that the current solution is somewhat inconsistent:
For DivX/XVID you're displaying a whole family of coding standards ("mpeg4") for what is really just a part of that family (Part 2 "MPEG4 ASP"), while for another part of that family you're displaying the actual codec.

I think a more correct solution would be either:
- always display the actual codec used for encoding (like suggested before) or
- only display the used mp4 profile (rename "mpeg4" to "mpeg4 asp" and rename "h264" to "mpeg4 avc")

While h264 is basically just a synonym for "mpeg-4 part 10", divx, xvid etc. are just different codecs to create a "mpeg-4 part 2" compliant video. So it is ok to distinguish between h264 and mpeg4 (and mpeg2 and mpeg1).

[lx01]

While h264 is basically just a synonym for "mpeg-4 part 10", divx, xvid etc. are just different codecs to create a "mpeg-4 part 2" compliant video. So it is ok to distinguish between h264 and mpeg4 (and mpeg2 and mpeg1).

I didn't say they shouldn't be distinguished. What i wanted to say is that the current label used for mpeg4 part 2 is somewhat misleading because simply "mpeg4" is divx, xvid as well as h264.

[bertrand]

Stupid question here: what is the exact status of this feature ? Is this part of trunk ? If yes, is any specific action required to take advantage of it ? What is the skin status ?

Thanks for clarifying this up (probably the most expected feature as far as I'm concerned...)

[watzen]

Stupid question here: what is the exact status of this feature ? Is this part of trunk ? If yes, is any specific action required to take advantage of it ? What is the skin status ?

Thanks for clarifying this up (probably the most expected feature as far as I'm concerned...)

It's basically done, aside from bughunting. No it's not part of the trunk. Theres no official skin support yet. (read a couple of pages, and you'd know this)

you can however download a precompiled build thats been posted in this thread and play with it by yourself.

[blittan]

Not part of trunk yet, almost completed though. There aren't any skins supporting this yet (but they sure will do once this is complete)

[Gamester17]

From a skinning eye candy point of view it would sure be interesting to also have the FourCC information available for skinners.

http://en.wikipedia.org/wiki/FourCC

A FourCC (literally, four-character code) is a sequence of four bytes used to uniquely identify data formats. The concept originated in the OSType scheme used in the Macintosh system software and was adopted for the Amiga/Electronic Arts Interchange File Format and derivatives. The idea was later reused to identify compressed data types in QuickTime and DirectShow.

Four byte identifiers are useful because they can be made up of four human-readable characters with mnemonic qualities, while still fitting in the four byte memory space typically allocated for integers in 32-bit systems (although endian issues may make them less readable).

FourCC is a documented and well adopted standard for both Windows and Mac media files.

http://www.fourcc.org/codecs.php

I have to admit that that the Aeon views showing the codec types does look really good, they give it that extra 'Wow!' factor

[spiff]

serisously. do you EVER go

'hmm, i want to watch a xvid movie, not a silly divx one!'

[HexusOdy]

I see both sides of the argument, it's basically accuracy vs code vs benefit and finding the balance.

I agree that if you have XviD files or DiVX or x264 the ideal solution is for that to show accurately in the skin. But to do that there has to be a reliable way to get that info and insignificant hit in processing to make it worthwhile.

I think CapnBry is the one who can answer that question above all others.

[freezy]

+1 Gamester. However, if, as CapnBry pointed out, there are performance issues it may not be worth it.