Default compression h264 doesn't result in h264 compressed video

[BigRoy]

Problem

The default value of h264 of compression does not result (on Windows) in a video stream with H.264 compression. Instead the compression is JPEG.

For the playblast command the h264 compression is unknown because the compression string should actually be H.264 on Windows. So it seems to fallback on its default compression (since the same happens if you pass it a random compression string value, e.g. aaaaaaa). I'm unable to test this on Linux/Mac to see if it's also the case for those platforms.

Tested with Maya 2016 Ext 1 SP6 on Windows 7.

Note that H.264 compression suffers from bugs on hardware with more than 16 cores (also described here) resulting in errors randomly stopping midway or errors about disk size full (even when plenty of disk space available). This is the reason we actually spotted it was not compressing to H.264.

[mottosso]

Oh snap, well caught.

[mottosso]

Should we add constants to the module, to prevent this from happening again?

import capture
capture.capture(compression=capture.H264)

Which is just the string H.264, that can be passed in its place.

import capture
capture.capture(compression="H.264")

[BigRoy]

Should we add constants to the module, to prevent this from happening again?

We could, but I'm wondering how much constants we should offer. Especially since the amount is so dynamic. It's even dependent on codecs installed. I believe on a Windows installation without Quicktime H.264 codec isn't even available?

How about logging a warning if the provided formatting isn't a valid option. It can continue playblasting for when a codec isn't installed and this way we stay backwards compatible. Here's an example on how to get available compressions for a format: https://github.com/BigRoy/maya-capture-gui/blob/master/capture_gui/lib.py#L249.

As such we could just do a check like:

if compression not in set(list_compressions(format)):
    log.warning("%s is not a valid compression for format %s", compression, format)

This way it's at least clear that the output could be fishy.

If we find out it's slow we could also store the available formats and compressions upon import of capture, since codecs shouldn't change during a Maya session.

Something like:

FORMATS = dict((format, set(list_compressions(format))) for format in list_formats())

A full check would then become:

if format not in FORMATS:
    raise ValueError("{0} is not a valid format".format(format))

if compressions not in FORMATS[format]:
    log.warning("%s is not a valid compression for format %s", compression, format)

But that's merely an optimization.

[BigRoy]

@mottosso did you give this some more thought?

As first step we could at least correct the default argument from "h264" to "H.264" assuming it's the same value under all platforms (Windows, Linux, Mac).

[mottosso]

I'm not too sure how to best approach it.

What I would like is get to the bottom of exactly how many compressions there are, guaranteed. Then look at getting some clarity on how dynamic it can really get.

You're right that we can't provide constants for everything, especially if it depends on things out of our control.

I'd imagine we support a small subset of the most common ones in capture.py, as constants, and let the user pass an arbitrary string for special cases.

What do you think?

As first step we could at least correct the default argument from "h264" to "H.264" assuming it's the same value under all platforms (Windows, Linux, Mac).

Yes, that seems like a big miss on my part.

Let's PR that.

[BigRoy]

The problem of the default argument is now fixed (with add44d6).

Nevertheless the issue of maintainability remains as is. Storing constants for formats and their codecs could still be an option or we can investigate other solutions. I'll leave this issue closed for now, but feel free to continue discussion.