Transcoding continues with unfilled video packet

[t.rapp]

When I try to transcode a loss-less input file to MXF/IMX30 having the "-xerror" command-line option set the transcoding continues even in cases when the video packet is not complete. Apparently the error is detected as the debug log output contains the following messages:

[mpeg2video @ 0x32e7f60] rc buffer underflow
[mxf_d10 @ 0x32e6d00] cannot fill d-10 video packet

but the error is not propagated.

How to reproduce:

% ./ffmpeg -f rawvideo -video_size pal -pixel_format yuv420p \
 -framerate 25 -i /dev/urandom  -f mxf_d10 -c:v mpeg2video \
 -pix_fmt yuv422p -b:v 30000k -minrate 30000k -maxrate 30000k \
 -g 1 -flags +ildct+low_delay -intra_vlc 1 -non_linear_quant 1 \
 -ps 1 -qmin 1 -qmax 12 -dc 10 -bufsize 1200000 \
 -rc_init_occupancy 1200000 -rc_max_vbv_use 1 -rc_min_vbv_use 1 \
 -t 1 -y ffmpeg-imx30-test01.mxf -xerror

ffmpeg version N-74305-g94c0df7 Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04)
  configuration: --cc='ccache gcc' --enable-debug --disable-optimizations --enable-version3 --enable-sdl
  libavutil      54. 30.100 / 54. 30.100
  libavcodec     56. 57.100 / 56. 57.100
  libavformat    56. 40.101 / 56. 40.101
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 32.100 /  5. 32.100
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  2.101 /  1.  2.101
Input #0, rawvideo, from '/dev/urandom':
  Duration: N/A, start: 0.000000, bitrate: 124416 kb/s
    Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 720x576, 124416 kb/s, 25 tbr, 25 tbn, 25 tbc
Output #0, mxf_d10, to 'ffmpeg-imx30-test01.mxf':
  Metadata:
    encoder         : Lavf56.40.101
    Stream #0:0: Video: mpeg2video, yuv422p, 720x576, q=1-12, 30000 kb/s, 25 fps, 25 tbn, 25 tbc
    Metadata:
      encoder         : Lavc56.57.100 mpeg2video
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> mpeg2video (native))
Press [q] to stop, [?] for help
[swscaler @ 0x32d3840] Warning: data is not aligned! This can lead to a speedloss
[mpeg2video @ 0x32e7f60] rc buffer underflow
[mxf_d10 @ 0x32e6d00] cannot fill d-10 video packet
[mpeg2video @ 0x32e7f60] rc buffer underflow
[mxf_d10 @ 0x32e6d00] cannot fill d-10 video packet
[mpeg2video @ 0x32e7f60] rc buffer underflow
[mxf_d10 @ 0x32e6d00] cannot fill d-10 video packet
[mpeg2video @ 0x32e7f60] rc buffer underflow
[mxf_d10 @ 0x32e6d00] cannot fill d-10 video packet
...
[mpeg2video @ 0x32e7f60] rc buffer underflow
[mxf_d10 @ 0x32e6d00] cannot fill d-10 video packet
frame=   25 fps=1.9 q=31.1 Lsize=    4510kB time=00:00:01.00 bitrate=36942.2kbits/s
video:4484kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.570479%

[t.rapp]

Log output from a run with "-loglevel repeat+debug"

[Carl Eugen Hoyos]

Could you explain your use-case?

[t.rapp]

I'm transcoding video files that are itself recorded from SDI input (AVI, HuffYUV, yuv422p) into MXF/IMX30 target format. The target files are intended for long-term preservation.

Some of the recorded files contained a few noisy frames (maybe due to loose SDI contact) which seemingly were transcoded successfully by FFmpeg but caused problems during playback. Luckily the erroneous files have been caught by IRT MXF Analyser before putting the files into archive.

[Carl Eugen Hoyos]

If only I could understand why you are using a format that is known to have compatibility issues for archiving...

More important: Could you provide real-world content that could not be encoded so the underlying issue can (also) be fixed?

[t.rapp]

I have uploaded file "ffmpeg-ticket-4759_cannot-fill-video-packet.avi" to upload.ffmpeg.org/incoming .

Unfortunately I notice now that using the sample file apparently the error only occurs on Windows (tested Zeranoe + own build) but not on GNU/Linux. On Linux some "stuffing too large" error message is printed and the transcoding aborted (error propagation works in this case).

[t.rapp]

As discussed on the mailing list no "error out on rc buffer underflow" flag will be implemented (see https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/181067.html).

Anyway I cannot reproduce the original issue with current git-master, possibly due to improved mpeg2 rate-control.