Thumbnail-Extraction: Avoid extra work for 3d MVC Movies

[loki42 0]

Hi,

while reorganizing my Movie library, i wondered why Thumbnail generation takes much longer then before on some movies.

If i place a movie with a "- 3d.mvc.*" suffix inside the folder, the image extraction process uses:

/bin/ffmpeg -f matroska -threads 1 -i file:/path/to/movie - 3d.mvc.mkv -an -sn -threads 0 -vf fps=fps=1/10,scale=min(iw\,320):trunc(ow/dar/2)*2 -f image2 /cache/path/img_%05d.jpg

But for the same procedure, on a movie file NOT recognizable as 3D, the process is much faster and uses

/bin/ffmpeg -f matroska -threads 1 -skip_interval 10 -copyts -i file:"/path/to/my/movie - 1080p.mkv" -an -sn -vf "scale=w=320:h=180" -vsync cfr -r 0.1 -f image2 "/cache/path/img_%05d.jpg"

The later one is about 30x quicker, and produces the same result. As 3D MVC movies are composed of a Regular stream + a sub stream for the other eye, ffmpeg does not care about the substream and will happly extract good looking thumbnails without this heavy conversion.

 

 

EDIT: I just have seen, that the HSBS and more 3D-Movies have thumbnails containing also the whole screen. So, there should be no reason at all to use the first variant every. I assumed until now, that the thumbnails are "repaired", so take only one half of the image, and stretch it.

Edited July 13, 2025 by loki42

[Luke 42077]

Hi, what do you mean by "ffmpeg does not care about the substream" ?

[loki42 0]

As H264/MVC encoded streams are backwards compatible with H264/AVC, all H264 capable players will play and handle those streams just fine.

In short: Inside an H264 streams, bits are organized in "NAL" units. Those units have a type, unknown types are ignored.

The ffprobe output of an mvc 3D movie looks like this for the video stream:

  Stream #0:0(eng): Video: h264 (High), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn
    Metadata:
      stereo_mode     : block_lr
    Side data:
      stereo3d: frame alternate

ffmpeg is no able to decode the side data, but can (and will) handle the primary stream just fine. 

On that node: Currently, emby also seems to transcode h264 to h264 if a 3D movie is presented. This is not required (maybe to safe some bandwidth) and breaks 3D Playback on comaptible players, like a KODI on a 3D/MVC enabled Set-Top Box, as ffmpeg can not transcode the alternate view.

So, my suggestion would be to treat an h264 video stream always the same, regardless if 3D or not. 

 

[softworkz 5066]

@loki42

When we introduced the quick image series extraction, 3D files have been spared out for later implementation due to the complex scaling logic. Those below are for when the target width and height is known:

...but during image extraction, we only have a max-width, which makes these filters even longer and more complex.

 

Shortly after, 3D videos had massiely dropped in popularity and afaik, not a single user has come since then to ask for proper image series extraction for 3d videos - not even for MVC coded 3D videos - for which it doesn't matter anyway of course.

We'll enable quick extraction for MVC 3D videos in the next beta.

Thanks a liot for reporting!