avformat: lowres does not work

[Tjoppen]

melt -producer avformat:any_imf_video_file.mxf lowres=3

Expected behavior: output is 1/8 the resolution, 480x270 for a 4K file

Actual behavior: output is full resolution

This is due to AVOptions being set after avcodec_open2() rather than before. This also affects thread_type. Option handling in the avformat module could use improving in general, since there is currently no way to set options for specific streams or to set options only for the demuxer. Getting this right is essential for being able to work with IMF files since they are 4K JPEG2000, which is very CPU intensive without lowres support.

[ddennedy]

This is due to AVOptions being set after avcodec_open2() rather than before.

Thanks for this hint, I am not sure if this is a long-standing problem or something that degraded while migrating to new APIs. Looks like an easy to change to make, but if you do not I have to find another test case because lowres is crashing ffplay v5 for me on my Meridian JPEG2000 IMX.

there is currently no way to set options for specific streams or to set options only for the demuxer

MLT and the avformat is not multi-stream except for the case of one audio and one video. In the avformat consumer you can use the "a" or "v" prefix on MLT properties to target a muxer or encoder. In the avformat producer you can select one audio stream using audio_index and/or one video stream using video_index (these default to first found). The MLT properties are applied as AVOptions indiscriminately: if the option is found on either the audio or video format or codec object, it is set. If this will be improved perhaps it should use the ":a" ":v" suffix convention like ffmpeg instead to prevent collisions with options that begin with "a" or "v." Also, it should adopt the MLT avfilter convention to only apply MLT properties that begin with "av." as an AVOption to qualify it: av.lowres:v=3. If this change is applied to the avformat consumer, then it might need to keep the old approach for backwards compatibility. (Specifying decoder and demuxer options is rare in my experience whereas exceptionally commonplace for encoder and muxer.) Not sure when I will get around to that and a pull request is welcomed.

[ddennedy]

This is working for me with HDV:

$ ffprobe '/home/ddennedy/net/media/unsorted/videos/test/hdv/rackfocus.mpg'
...
Input #0, mpegts, from '/home/ddennedy/net/media/unsorted/videos/test/hdv/rackfocus.mpg':
  Duration: 00:00:16.52, start: 827.840000, bitrate: 25789 kb/s
  Program 1 
  Stream #0:0[0x11]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, bt709, top first), 1440x1080 [SAR 4:3 DAR 16:9], 
...
$ melt '/home/ddennedy/net/media/unsorted/videos/test/hdv/rackfocus.mpg' lowres=2 -consumer xml | grep profile
  <profile description="automatic" width="360" height="270" progressive="0" sample_aspect_num="4" sample_aspect_den="3" display_aspect_num="16" display_aspect_den="9" frame_rate_num="25" frame_rate_den="1" colorspace="709"/>

Also, some other MPEG-2 MXF files work. I have not found jpeg2000 in my library except MERIDIAN_SHR_C_EN-XX_US-NR_51_LTRT_UHD_20160909_OV_01.mxf, which is crashing even after upgrading today to FFmpeg git master HEAD.

[Tjoppen]

If this will be improved perhaps it should use the ":a" ":v" suffix convention like ffmpeg instead to prevent collisions with options that begin with "a" or "v."

Yes please. I tried exactly this and melt thought I was specifying more producers instead of providing options for the avformat producer. Bringing the option parsing closer in line with ffmpeg would be nice. Multi-stream support in melt is iffy, but at least it works well enough for our use case.

This is working for me with HDV:

Right, it might work anyway with some formats. I forgot to mention these are JPEG 2000 / IMF files. Can't really upload them anywhere since they're absolutely massive.