PLAY/LOADBG corrupted file returns 202 OK instead an error code

martastain commented 5 years ago

Expected behaviour

When PLAY/LOADBG command fails due to a corrupted media file, a server should respond with an error status.

Current behaviour

The server returns 200 OK and INFO command pretends video is loaded (with zero duration):

<?xml version="1.0" encoding="utf-8"?>
<channel>
   <framerate>50</framerate>
   <framerate>1</framerate>
   <mixer>
      <audio>
         <volume>0</volume>
         <volume>0</volume>
         <volume>0</volume>
         <volume>0</volume>
         <volume>0</volume>
         <volume>0</volume>
         <volume>0</volume>
         <volume>0</volume>
      </audio>
   </mixer>
   <stage>
      <layer>
         <layer_1>
            <background>
               <producer>empty</producer>
            </background>
            <foreground>
               <file>
                  <clip>0</clip>
                  <clip>0</clip>
                  <name>badfile.mxf</name>
                  <path>d:/media.dir/badfile.mxf</path>
                  <time>0</time>
                  <time>0</time>
               </file>
               <loop>false</loop>
               <paused>false</paused>
               <producer>transition</producer>
               <transition>
                  <frame>0</frame>
                  <frame>0</frame>
                  <type>cut</type>
               </transition>
            </foreground>
         </layer_1>
      </layer>
   </stage>
</channel>

There is however an exception in a console window.

play 1-1 badfile
[2019-01-03 13:38:49.888] [info]    Received message from Console: play 1-1 badfile\r\n
#202 PLAY OK
[2019-01-03 13:38:49.970] [error]   Exception: C:\Program Files (x86)\Jenkins\workspace\casparcg-ser
ver-dep\2.2.x\src\modules\ffmpeg\producer\av_input.cpp(121): Throw in function void __cdecl caspar::
ffmpeg::Input::reset(void)
[2019-01-03 13:38:49.970] [error]   Dynamic exception type: class boost::exception_detail::clone_imp
l<struct caspar::ffmpeg::ffmpeg_error_t>
[2019-01-03 13:38:49.970] [error]   [struct boost::errinfo_api_function_ * __ptr64] = avformat_open_
input(&ic, filename_.c_str(), nullptr, &options)
[2019-01-03 13:38:49.970] [error]   [struct boost::errinfo_errno_ * __ptr64] = 1094995529, "Unknown
error"
[2019-01-03 13:38:49.970] [error]   [struct caspar::tag_stacktrace_info * __ptr64] =  0# 0x000000013
FB998AE in casparcg
[2019-01-03 13:38:49.970] [error]    1# 0x000000013FBC8C50 in casparcg
[2019-01-03 13:38:49.970] [error]    2# 0x000000013FDA526A in casparcg
[2019-01-03 13:38:49.970] [error]    3# 0x000000013FD9ED37 in casparcg
[2019-01-03 13:38:49.970] [error]    4# 0x000000013FD98D82 in casparcg
[2019-01-03 13:38:49.970] [error]    5# 0x000000013FF195E3 in casparcg
[2019-01-03 13:38:49.970] [error]    6# crt_at_quick_exit in ucrtbase
[2019-01-03 13:38:49.970] [error]    7# BaseThreadInitThunk in kernel32
[2019-01-03 13:38:49.970] [error]    8# RtlUserThreadStart in ntdll
[2019-01-03 13:38:49.970] [error]
[2019-01-03 13:38:49.970] [error]
[2019-01-03 13:38:49.970] [error]    0# 0x000000013FB998AE in casparcg
[2019-01-03 13:38:49.970] [error]    1# 0x000000013FB991DF in casparcg
[2019-01-03 13:38:49.970] [error]    2# 0x00000001400BC7D7 in casparcg
[2019-01-03 13:38:49.970] [error]    3# _C_specific_handler in VCRUNTIME140
[2019-01-03 13:38:49.970] [error]    4# _FrameUnwindFilter in VCRUNTIME140
[2019-01-03 13:38:49.970] [error]    5# RtlRestoreContext in ntdll
[2019-01-03 13:38:49.970] [error]    6# 0x000000013FD98D82 in casparcg
[2019-01-03 13:38:49.970] [error]    7# 0x000000013FF195E3 in casparcg
[2019-01-03 13:38:49.970] [error]    8# crt_at_quick_exit in ucrtbase
[2019-01-03 13:38:49.970] [error]    9# BaseThreadInitThunk in kernel32
[2019-01-03 13:38:49.970] [error]   10# RtlUserThreadStart in ntdll
[2019-01-03 13:38:49.970] [error]

Steps to reproduce

Create a file with no or random content. eg. badfile.mxf
Execute AMCP command: PLAY/LOADBG 1-1 badfile
Server responds with 202 PLAY OK

Environment

Server version: e.g. v2.2 stable
Operating system: Windows 7

ronag commented 5 years ago

The OK only means that the server accepted the command.

Unfortunately, the AMCP protocol is a bit broken. The previous behavior was to wait for the file to start playing. However, that was a big problem since it could block the entire channel command queue until the file was loaded (if at all).

You need to use the OSC output to determine if the file was actually loaded or not...

premultiply commented 5 years ago

Well, but at least the INFO feedback is wrong.

CasparCG / server