[FFmpeg-user] new error

[Moritz Barsnick]

On Tue, Aug 09, 2016 at 19:47:21 +0200, juan carlos Rebate wrote:

Can we take this discussion away from all the debate, and get
technical? Juan Carlos asked:

> ffmpeg -i video.avi mime_type video/mp4 -listen 1 http://ip:80
[and yes, he forgot to quote the missing dash]

So I attempted:
$ ffmpeg -f lavfi -i testsrc=d=1 -c:v libx264 -mime_type application/foobar -listen 1 -f flv http://127.0.0.1:8999
ffmpeg version N-81308-g369ed11 Copyright (c) 2000-2016 the FFmpeg developers
  built with icc (ICC) 14.0.3 20140422
  configuration: --prefix=/usr/new/tools/video/install/ffmpeg/2016-08-09 --cc=icc --cxx=icpc --enable-gpl --enable-version3 --enable-nonfree --disable-shared --enable-gnutls --enable-libcdio --enable-libfreetype --enable-libx264 --enable-libvpx --enable-libmp3lame --enable-openal --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtwolame --enable-libopenjpeg --enable-librtmp --enable-libass --enable-libv4l2 --enable-libvidstab --enable-libfdk-aac --enable-libsmbclient --enable-libzvbi --enable-libtesseract --enable-libzmq
  libavutil      55. 28.100 / 55. 28.100
  libavcodec     57. 51.100 / 57. 51.100
  libavformat    57. 46.100 / 57. 46.100
  libavdevice    57.  0.102 / 57.  0.102
  libavfilter     6. 50.100 /  6. 50.100
  libswscale      4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  1.100
  libpostproc    54.  0.100 / 54.  0.100
Input #0, lavfi, from 'testsrc=d=1':
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24, 320x240 [SAR 1:1 DAR 4:3], 25 tbr, 25 tbn, 25 tbc
[http @ 0xbce0dc0] Error setting option mime_type to value application/foobar.
http://127.0.0.1:8999: Invalid argument

If I omit "-mime_type application/foobar", the http protocol works as
expected.

The error message does come from the http protocol (format?) as can be
seen from the context ("[http @ ...]"). The message text comes from the
generic option parser.

I believe the cause is that the "mime_type" option is flagged
"AV_OPT_FLAG_READONLY" - actually the only such option within all of
ffmpeg.

libavformat/http.c:137:
    { "mime_type", "export the MIME type", OFFSET(mime_type), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, AV_OPT_FLAG_EXPORT | AV_OPT_FLAG_READONLY },

Such an option is described as such:
 * The option may not be set through the AVOptions API, only read.

Removing the "AV_OPT_FLAG_READONLY" flag in http.c does allow the
option to be given on the command line without error, but the http
protocol doesn't do anything with it. It is indeed a read-only option.

The documentation says:
mime_type
    Export the MIME type.

But I think it's only designed for the http demuxer protocol, and it's
not useful for the command line, because it takes a string argument,
but you're not actually allowed to set it. So the documentation must be
misleading here.

And yes, I do understand that the mime_type is not the Content-Type.
It's probably an extracted interpretation of the Content-Type on the
HTTP receiving end, I guess. But the documentation is misleading anyway.

I looked at the alternatives:

headers
    Set custom HTTP headers, can override built in default headers. The value must be a string encoding the headers.

This does not work for the listen mode. That may be a bug.

content_type
    Set a specific content type for the POST messages.

This does not work for the listen mode (and it obviously isn't
documented to do so).

So, I don't currently see any way to set the Content-Type header for
listen mode, apart from expanding the code. My really easy suggestion
for a code change to support this:

--- ./libavformat/http.c.orig   2016-06-17 19:20:02.000000000 +0200
+++ ./libavformat/http.c        2016-08-10 15:50:17.000000000 +0200
@@ -355,7 +355,7 @@
     case 200:
         reply_code = 200;
         reply_text = "OK";
-        content_type = "application/octet-stream";
+        content_type = s->content_type ? s->content_type : "application/octet-stream";
         break;
     case AVERROR_HTTP_SERVER_ERROR:
     case 500:

(Works for me(TM).)
I might put this (plus a doc change) up for review on ffmpeg-devel,
unless someone quickly tells me it's nonsense. ;-)

Moritz

P.S.: I'm not sure whether changing the Content-Type was juan carlos's
      intention, he always forgets to write precisely what he wanted to
      achieve. Let's just pretent it was *my* intention now.