Video-hub-app: Files with audio streams ordered before video streams do not detect resolution properly

Created on 11 Jan 2020  Β·  9Comments  Β·  Source: whyboris/Video-Hub-App

https://github.com/whyboris/Video-Hub-App/blob/97e3ebb368876b1c068e1d387210e95944ce8ac1/main-support.ts#L412

I noticed VHA was not detecting resolution for some of my files and did some digging to figure out why. The code in question notes that ffprobe has trouble with some MKV streams; the files I had problems with are actually h264 in mp4 container, not sure that changes much though.

I think you can avoid this issue by either iterating the metadata.streams and checking if it is a video or audio stream before grabbing height // width , or just checking stream 1 if stream 0 doesn't contain the height/width property. I'm not sure what the limit is on number of streams, if a file could contain a bunch of audio streams for different languages before you find a video stream, I guess you'd need to implement something more complex.

I fixed it locally with something like this:

const getPropFromStreams = (metadata, propName) => {
  for (const stream of metadata.streams) {
    if (stream.codec_type === 'audio') {
      continue
    }
    if (stream.hasOwnProperty(propName)) {
      return stream[propName]
    }
  }
  return 0
};

imageElement.height = getPropFromStreams(metadata, 'height');
imageElement.width = getPropFromStreams(metadata, 'width');

Most helpful comment

πŸ•΅ @kevinseelbach has the right idea, although I would change it slightly - I would iterate all steams available and look for the greatest width and height. I believe mkv files sometimes embeds the thumbnails too, which could be a lower resolution than the actual video. πŸ‘ This may not work if there's some funny streams with large resolutions, but I think it should be a pretty good option.

They can contain unlimited audio and video steams, as well as subtitle streams.

All 9 comments

Thank you so much for investigating and for sharing the code that may/could/will fix the problem πŸ™‡

Feel free to open a PR; alternatively I'll add it sometime before I release 2.1.0 πŸŽ‰

You’re welcome. I wasn’t sure if it is the best solution, since not
knowing much about video formats, I’m not sure if there are some hidden
intricacies I might not be aware of.

@cal2195 -- would be great if you weighed in when you have a chance -- you know more about this piece of code / ffmpeg functionality than I do πŸ₯‡

πŸ•΅ @kevinseelbach has the right idea, although I would change it slightly - I would iterate all steams available and look for the greatest width and height. I believe mkv files sometimes embeds the thumbnails too, which could be a lower resolution than the actual video. πŸ‘ This may not work if there's some funny streams with large resolutions, but I think it should be a pretty good option.

They can contain unlimited audio and video steams, as well as subtitle streams.

Ah ha! Past-me already figured this out, but didn't do it for ffprobe! πŸ˜‚ See #128 πŸŽ‰

We just need to add the parameter -select_streams V to the ffprobe command above, which will only return streams that are video, not cover art, thumbnails, audio etc... πŸ˜„ Then just select the first one, or largest resolution!

https://github.com/whyboris/Video-Hub-App/blob/97e3ebb368876b1c068e1d387210e95944ce8ac1/main-support.ts#L402

@kevinseelbach If you get a chance, could you try that, and see if it fixes your issue? πŸ˜„

@cal2195 I'm reviewing now, I looked back at #128 and #103 though and I don't think that was the exact same issue - in my case, thumbnails were visible, but the resolution was marked as SD for videos that have audio in the first stream.

That said, your proposed change sounds like an ideal fix - the -select_streams V change. I'll play with it locally and check back here or make a PR if all goes well.

Sorry about the double PR, I pushed the first one as the wrong git author (work).

Thank you @kevinseelbach for the #338 PR -- it successfully closes this issue πŸ™‡β€β™‚οΈ

Was this page helpful?
0 / 5 - 0 ratings