Video preview thumbnail generation fails with certain Blu-ray rips (NOT re-encoded)

[Raelworld]

@ChuckPa, did you try to create video preview thumbnails (NOT chapter thumbnails or general thumbnails)? THAT IS WHERE THE PROBLEM LIES.

Let me try to explain the issue again. It seems like ffmpeg has a bug when attempting to pull keyframes from certain types of (legally) encoded files. Plex uses ffmpeg in some form. Therefore Plex has a problem with certain types of (legally) encoded files.

It is not about ripping. It is not about MKVs. It is not about chapter thumbnails. It is about the code that Plex uses to pull frames from x264 video during one specific process, that process being the generation of frames when creating a BIF file.

[Volts]

@ChuckPa

1. This is at the master encoding - FFMPEG level
2. I don’t see how this can be a Plex issue.
3. I do agree that FFMPEG upstream needs to handle such cases.
4. Given I can DirectPlay my rip on my iPad, I can speak to HOW it was ripped matters a great deal.

1. Yes, the number of IDR frames in a stream is determined at encoding time.

• Doesn’t change when remuxing, etc. Can’t be changed without reencoding.
• Reasons a stream could have fewer IDR frames:
  • Encoded with open GOP
  • I frames that are not IDR frames
  • Encoded using intra-refresh.
• Not sure what you mean by “FFMPEG level”.
• At least one of these streams was produced by the x264 encoder with validated-for-bluray settings.

2. It definitely is. These are valid streams, and Plex is failing.

• The way Plex extracts video preview thumbnails cannot handle these streams. It is taking a shortcut - skipping non-IDR frames.
• Plex could use a more reliable method (slower), or it could attempt the shortcut, and then use a more reliable method.
• Plex has changed the method for video preview thumbnail extraction in the past.
• We know that Plex uses FFmpeg internally, but that doesn’t give permission to pass the buck.

3. That would be great but isn’t the only solution.

• I submitted the bug to FFmpeg because it may impact other users too.
• I don’t think Plex usually imports FFmpeg changes immediately.
• Plex relies on this feature internally. I’m hoping Plex will take ownership.
• Plex could fix & patch this in their local FFmpeg src.
• Plex could fix & patch this and submit it back to FFmpeg upstream.

4. I think that’s mostly a non-sequitur.

• We know that basic ripping methods matter.
• These streams PLAY fine, they’re valid H.264.

If the conversation ends at “It’s a stream problem” or “It’s an FFmpeg problem”, the world will keep turning. These thumbnails are a nice-to-have feature. Most streams are encoded with plenty of IDR frames and closed GOP. If you see the other thread there are a number of people with the issue.

[Volts]

@Raelworld

did you try to create video preview thumbnails

Those work with his source disc. It’s a different disc.

[Volts]

@ChuckPa

Is there anything else I can do here?

Could you escalate internally to the devs responsible for video preview thumbnail generation?

@ChuckPa

What I was able to verify, what little it may seem matter, is that with this encoding, Plex was able to generate the chapter thumbs correctly.

Your sample produced both chapter thumbs and video preview thumbnails successfully for me. Agreed.

[ChuckPa]

How does escalating internally help the problem?

If you can give me a nice , clean, “Video Chapter thumbnail fail when GOP / IDR frames > X” statement of the problem (or the reverse logic) ,

along with the "works when — Condition Blah ---- " (show scope)

I can then take the two samples (failure & success) and escalate.
If FFMPEG core can’t handle is then there’s not much hope of a quick turnaround by our dev team (they’re good but must push any & all changes to core back upstream – the delay)

[Volts]

Maybe I think more highly of the devs! Hah.

This info is in the ffmpeg bug too.

• https://trac.ffmpeg.org/ticket/8820

Here’s a small sample file that exercises the problem.
unknown.opengop.mp4.zip (2.0 MB)

This is similar to how Plex extracts thumbnails. It fails by only producing 3 jpg files:

% ffmpeg -v0 -skip_frame nokey -i unknown.opengop.mp4 -vsync 0 img-%06d.jpg; ls *jpg | wc -l
3

Plex’s use of -skip_frame nokey is (or reveals) the problem.

When using a different mechanism, it succeeds - all 45 expected I frames are extracted.

% ffmpeg -v0 -i unknown.opengop.mp4 -vf "select=eq(pict_type\,PICT_TYPE_I)" -vsync 0 img-%06d.jpg ; ls *jpg | wc -l
      45

Plex uses some additional filters, but those aren’t necessary to reproduce the problem.

In the problem case, the `BaseIndexFrameFileManager: expected XXX images, but found X" error occurs, and no video preview thumbnails are generated.

[ChuckPa]

It’s now a “How highly do I think of the devs”,
it’s a “How much more work do they need on the pile?” reference

[ChuckPa]

I don’t know when the devs will have time to triage this but I have submitted an internal ticket.

I did my best to summarize that both samples which succeed and which fail are here as well as the Steps To Reproduce both

[TeknoJunky]

Chuck, its NOT video chapters.

It is video PREVIEWS that are having issues.

[Volts]

Additionally, this terrible hack, modifying the Plex Media Server so that it does not use “nokey”, immediately resolves the issue and causes it to generate video preview thumbnail files correctly.

Video Preview Thumbnail Generation Fails for Some Items

FYI, I modified a copy of the Plex Media Server binary to call the Plex Transcoder (which is really just a fancy FFmpeg) with "-skip_frame:v none " instead of “-skip_frame:v nokey”, and it worked. cp -a "Plex Media Server" "Plex Media Server.orig" sed "s/nokey/none /" "Plex Media Server.orig" > "Plex Media Server" Obviously it’s a lot slower, but if the only files in your library are these ones, it gets the job done until a real fix is available. Edit: scroll down to a lower post for a much b…

My point is that this is behavior Plex can address. (I’m not suggesting that’s the correct way to do so.)

I would understand if Plex chooses not to address this. I’m sure it’s not the most important thing in the queue. You might talk to the users in the other thread about how much it’s affecting them.

In my experience, there’s always Too Much Work for any development team, and the challenge is prioritizing which backlog items (features and defects) to work on. We didn’t put things on the queue if we were NEVER going to address them, but otherwise we did.

I’m frustrated to feel like I’ve been “deflected”:

1. The ripping must have been wrong
2. Just re-encode it, that fixes everything
3. It’s an ffmpeg problem
4. There’s nothing Plex can do

I’m sympathetic with #1 and #2; the same questions come up over and over again and that’s annoying. I would go mad asking people to share their file names and logs. I’m impressed y’all do it. I think we mostly got past that, eventually.

And there’s so much angry negative “Plex is dumb” ■■■■ on the forums lately. “Plex doesn’t do anything that matters” and “Plex doesn’t listen to what we want” and “Plex suxxx”. It makes me sad to see it - the amount of vitriol. It must be exhausting. Again, my compliments.

That said, #3 and #4 are frustrating. Your responses to us were a real let-down.

Plex is a commercial product that incorporates an open-source application (FFmpeg). If Ford sells a car with exploding airbags, Ford resolves the issue, not Takata. When the space shuttle blew up, we blamed NASA, not Morton-Thiokol. (Edit: ugh, I sound … I dunno. Sorry.)

(Yes, Plex is as important as Ford and NASA.)

I felt like you were saying the issue wasn’t that important, AND that it was somebody else’s problem, AND that Plex couldn’t do anything about it.

Just hearing “Oh hey, that looks like an issue, I’ll open something internally about it. Unless it becomes more common I can’t promise that it will receive time & attention.” I would have been 80% satisfied.

Anyway, I started venting. TYVM for your time.

[ChuckPa]

Can we let this last few posts sit so the dev team can easily find them (at the bottom) ?

[Volts]

@ChuckPa

I don’t know when the devs will have time to triage this but I have submitted an internal ticket.

I did my best to summarize that both samples which succeed and which fail are here as well as the Steps To Reproduce both

TYVM for that. It’s appreciated. Shutting up now.