[niza]

hi

When adding a m4v SD video to XBMC (624x272) it is not detected as such in the skin. As far I can see the problem is the ListItem.VideoResolution in the skin.

Examining the database 'streamdetails' I can see that XBMC detects two video streams: one the above 624x272 stream and another mjpeg stream at 763x1126.

Using ffmpeg I found the following details about the video file:

Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, smpte170m), 624x272, 1200 kb/s, 23.98 fps, 23.98 tbr, 90k tbn, 47.95 tbc (default)
Stream #0:1(fra): Audio: aac (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 163 kb/s (default)
Stream #0:2: Video: mjpeg, yuvj420p(pc), 763x1126 [SAR 72:72 DAR 763:1126], 90k tbr, 90k tbn, 90k tbc
Stream #0:3(eng): Subtitle: mov_text (tx3g / 0x67337874), 624x40, 0 kb/s (default)

The mjpeg stream (#0:2) is the cover art inserted with the meta data.

It seems that XBMC when resolving the ListItem.VideoResolution is using, either the wrong stream or is using the stream with the highest resolution. I did not dive into the code of XBMC to see how and where XBMC actually performs the resolving of the above.

I have not filed a BugReport as I am not sure this is actually a bug, since both multiple video streams and mjpeg streams should probably be allowed.

(XBMC 13.0 Beta 2 on OpenELEC 3.95.2 using default Confluence skin.)

[popcornmix]

I think is is a bug. It's related to this fix:
https://github.com/xbmc/xbmc/pull/4362

This is an (untested) patch that applies that video playback fix to the fileitems code:
https://github.com/popcornmix/xbmc/commi...ceed5ba2f1

If you are able to build xbmc you could try applying that patch.
When I get time I'll try testing it properly and submitting a PR.

[niza]

I think is is a bug. It's related to this fix:
https://github.com/xbmc/xbmc/pull/4362

This is an (untested) patch that applies that video playback fix to the fileitems code:
https://github.com/popcornmix/xbmc/commi...ceed5ba2f1

If you are able to build xbmc you could try applying that patch.
When I get time I'll try testing it properly and submitting a PR.

After hours and hours of compiling I can confirm that the above patch does solve the problem. The simple testing I did (scanning movies into the library, browsing the movies library), did not result in any misbehavior or other malfunctions.

Thanks.