get_video_content raise error because of the mismatch Content-Type #175

Activity

1. stephendavidmarsh commented on May 14, 2026

   

   stephendavidmarsh

   on May 14, 2026

   More actions

   This error happened for me as well.

   To be specific, this line:
   

   python-sdk/src/openrouter/video_generation.py

   Line 758 in ec85ab2

   if utils.match_response(http_res, "200", "application/octet-stream"):

   is the offending line.

   👍React with 👍1Reacted by Ivo Stratev
2. mattapperson

   assigned

   abhinav-pola

   on May 19, 2026
3. mattapperson

   added

   bugSomething isn't workingSomething isn't working

   on Jun 17, 2026
4. adrian-85 commented on Oct 1, 2026

   

   adrian-85

   on Oct 1, 2026

   Last edited by adrian-85

   More actions

   Apologies for the noise if this is already known.

   The originally reported symptom looks fixed. get_video_content now sends Accept: video/mp4 and matches the 200 video/mp4 response, so the application/octet-stream vs video/mp4 mismatch from the original report is gone (see #363).

   There is a narrower remaining case that I think is worth fixing, because it is a spec problem rather than an SDK problem.

   What's still broken

   The spec declares exactly one media type for a successful response:

   .speakeasy/in.openapi.yaml, /videos/{jobId}/content:

   '200':
     content:
       video/mp4:
         schema: { format: binary, type: string }
     description: 'Video content stream. The body is the raw video bytes proxied
       from the upstream provider, and the Content-Type reflects the provider media
       type (video/mp4).'

   which generates an exact-match assertion:

   src/openrouter/video_generation.py:1028

   if utils.match_response(http_res, "200", "video/mp4"):
       return http_res

   utils.match_content_type is an exact match (plus * / <type>/* handling). So a 200 that carries a media type other than video/mp4 falls through every branch to:

   raise errors.OpenRouterDefaultError("Unexpected response received", http_res, http_res_text)

   Reproducing against the SDK's own match_response at v1.3.19:

   Content-Type	matches video/mp4	result
   video/mp4	yes	returns the httpx.Response
   video/mp4; charset=binary	yes	returns the httpx.Response
   video/webm	no	raises Unexpected response received
   video/quicktime	no	raises Unexpected response received
   application/octet-stream	no	raises Unexpected response received

   The last row is worth calling out: that is the exact Content-Type from the original report, so any provider or proxy pass that does not set a video/mp4 type still reproduces the original error.

   Suggested fix

   In the OpenAPI source (not in the generated SDK), widen the 200 response for /videos/{jobId}/content:

   '200':
     content:
       '*/*':
         schema: { format: binary, type: string }
     description: 'Video content stream. The body is the raw video bytes proxied from
       the upstream provider. Content-Type reflects the provider media type.'

   match_content_type already treats * and */* as an unconditional match, which is the same mechanism the generated 4XX/5XX fallbacks rely on.

   If */* is not accepted by the generator for a response body, video/* is the conservative alternative. /audio/speech already declares audio/* in the same spec and generates match_response(http_res, "200", "audio/*"), which matches every audio subtype. Note that video/* on its own would still not cover application/octet-stream, so it fixes the webm/quicktime cases but not the originally reported one.

   This is not Python-specific

   The same spec drives the other SDKs, and they carry the same exact-match assertion. In typescript-sdk v-current, src/funcs/videoGenerationGetVideoContent.ts:222:

   M.stream(200, z.custom<ReadableStream<Uint8Array>>(...), { ctype: "video/mp4" }),

   so a non-video/mp4 response surfaces there as a ResponseValidationError rather than a return value. A one-line spec change fixes all of them at once.