[bug] Video upload recorded with an iPhone results in 422 Unprocessable entity

[kensanata]

Describe the bug with a clear and concise description of what the bug is.

I'm on an iPhone 11 and use Toot! to upload a video somebody sent me from a newer iPhone. On the phone the info I see is:

• Apple iPhone 14 HEVC
• 1080p 1080×1920 25MB Dolby Vision
• 30 FPS
• 00:23

On the client, I'm getting a message that the upload failed.

On the server, config.yaml says media-video-max-size: 41943040 so size should not be a problem.

The log file says:

timestamp="10/04/2023 17:09:02.737" func=middleware.Logger.func1.1 level=INFO latency=2.359508383s clientIP=… userAgent="Toot!/172 CFNetwork/1404.0.5 Darwin/22.3.0" method=POST statusCode=422 path=/api/v1/media requestID=b6abctw704000xr29nsg msg="Unprocessable Entity: wrote 650B"

Next, I shared the video to a mail that I sent to myself (which reduces the file size by a factor of 10), saved it again, and tried to upload that, from my iPhone 11, same problem.

Next, I downloaded that file to my laptop running a Debian-derived operating system and used Pinafore to upload the video, same problem.

So this problem is unrelated to the client, or the operating system, but it's something about the video file itself. Encoding? I don't know.

IMG_3618.MOV

I attached the second, smaller file.

What's your GoToSocial Version?

v0.7.1

GoToSocial Arch

arm64 Binary

What happened?

I get an error when uploading a short video.

What you expected to happen?

The video to upload successfully.

How to reproduce it?

No idea. But you can take a look at the video here: https://alexschroeder.ch/pics/IMG_3618.MOV

Anything else we need to know?

Nope.

[kensanata]

Doing some re-encoding myself results in an MP4 file that I can upload (using Pinafore, same setup that fails with the MOV file).

ffmpeg -i IMG_3618.MOV -q:v 0 IMG_3618.MP4

[NyaaaWhatsUpDoc]

The issue is that for now we only support mp4 :)

[kensanata]

Ah, that explains it. Would it be possible to say this in the 422 message and the log? That would have helped me understand what is happening, at least. Something like: “422 Video format not supported (currently supported: video/mpg4)” – or whatever the correct wording would be? Perhaps this can then be extended over time. Some clients might show the message text, and I would have found it in the logs for sure.

[daenney]

I'm looking at the code, and I think I've figured out why this happens. All the links are to v0.7.1 versions of the code, but it's largely the same in main.

All the way down the call chain, an error will get raised by store:

gotosocial/internal/media/processingmedia.go

Lines 190 to 209 in adb5966

	switch info.Extension {
	case "mp4":
	p.media.Type = gtsmodel.FileTypeVideo
	case "gif":
	p.media.Type = gtsmodel.FileTypeImage
	case "jpg", "jpeg", "png", "webp":
	p.media.Type = gtsmodel.FileTypeImage
	if sz > 0 {
	// A file size was provided so we can clean exif data from image.
	r, err = terminator.Terminate(r, int(sz), info.Extension)
	if err != nil {
	return fmt.Errorf("error cleaning exif data: %w", err)
	}
	}
	default:
	return fmt.Errorf("unsupported file type: %s", info.Extension)
	}

That gets bubbled back up (as far as I can see) to

gotosocial/internal/media/processingmedia.go

Line 85 in adb5966

func (p *ProcessingMedia) load(ctx context.Context) (*gtsmodel.MediaAttachment, bool, error) {

and then

gotosocial/internal/media/processingmedia.go

Line 58 in adb5966

func (p *ProcessingMedia) LoadAttachment(ctx context.Context) (*gtsmodel.MediaAttachment, error) {

until we finally get to

gotosocial/internal/processing/media/create.go

Lines 54 to 57 in adb5966

	attachment, err := media.LoadAttachment(ctx)
	if err != nil {
	return nil, gtserror.NewErrorUnprocessableEntity(err)
	}

That NewUnprocessableEntity retains the original error, and then we get back to

gotosocial/internal/api/client/media/mediacreate.go

Lines 126 to 130 in adb5966

	apiAttachment, errWithCode := m.processor.MediaCreate(c.Request.Context(), authed, form)
	if errWithCode != nil {
	apiutil.ErrorHandler(c, errWithCode, m.processor.InstanceGetV1)
	return
	}

Almost there now, back up

gotosocial/internal/api/util/errorhandling.go

Lines 106 to 108 in adb5966

	} else {
	genericErrorHandler(c, instanceGet, accept, errWithCode)
	}

That lands us in

gotosocial/internal/api/util/errorhandling.go

Lines 67 to 85 in adb5966

	func genericErrorHandler(c *gin.Context, instanceGet func(ctx context.Context) (*apimodel.InstanceV1, gtserror.WithCode), accept string, errWithCode gtserror.WithCode) {
	switch accept {
	case string(TextHTML):
	ctx := c.Request.Context()
	instance, err := instanceGet(ctx)
	if err != nil {
	panic(err)
	}
	c.HTML(errWithCode.Code(), "error.tmpl", gin.H{
	"instance": instance,
	"code": errWithCode.Code(),
	"error": errWithCode.Safe(),
	"requestID": middleware.RequestID(ctx),
	})
	default:
	c.JSON(errWithCode.Code(), gin.H{"error": errWithCode.Safe()})
	}
	}

Since we don't pass a helpText to NewErrorUnprocessableEntity, you end up with just the generic message for the 422 status code.

gotosocial/internal/gtserror/withcode.go

Lines 153 to 163 in adb5966

	func NewErrorUnprocessableEntity(original error, helpText ...string) WithCode {
	safe := http.StatusText(http.StatusUnprocessableEntity)
	if helpText != nil {
	safe = safe + ": " + strings.Join(helpText, ": ")
	}
	return withCode{
	original: original,
	safe: errors.New(safe),
	code: http.StatusUnprocessableEntity,
	}
	}

If we returned a more specific error from store, we could detect the unsupported file type in the media processor's Create and include a help text that reflects that issue when we create the NewErrorUnprocessableEntity. That would then result in a more helpful message in the API response which should also be displayed in the clients.

[erasmas]

Surprisingly, I'm not able to upload an MP4 video either. The video is recorded on iPhone and converted to MP4 specifically for gotosocial but I'm getting HTTP 422. 😕

[Ben02]

I'm not able to upload an MP4 video which is a screen record by iOS. I got HTTP 422 too.

[meljoann]

Could be related to H.265 vs H.264? I was trying to get my file size down, so tried both. Used Handbrake to compress & encode.

• H.265 wouldn't upload, with "unprocessable" error message on Elk. ioS 11+ support H.265, so maybe...
• H.264 worked.

[tsmethurst]

The newest release of the Go mp4 library we use adds a few more mp4 box types to its decodable formats, so that should help a bit: https://github.com/abema/go-mp4/releases/tag/v0.12.0

[tsmethurst]

For future reference, there's a list here of box types that are and aren't currently supported: abema/go-mp4#13

[erasmas]

Verified that this issue is still present in 0.11.0. Is there any information that I can provide to help with the fix?

[tsmethurst]

This should be closed by #3090 (tested with the video in the OP)