Fix ffmpeg_reader: reshape order, frame-success return, and tuple check

[ds17f]

The ffmpeg recorder has three bugs that prevent it from supplying usable frames to the recognition pipeline. With these fixes, switching recording_plugin = ffmpeg actually works; without them, it silently breaks recognition.

The bugs

1. Reshape transposes spatial dimensions

.reshape([-1, self.width, self.height, 3])

ffmpeg's rgb24 output is row-major: (height, width, 3). Using width as the row axis transposes every frame.

2. Successful reads return 0

read() returns (0, ...) on its success paths. Callers in compare.py and add.py treat the first value as a boolean success flag (matching cv2.VideoCapture.read()), so successful frames are always discarded.

3. if self.video == (): becomes ambiguous after the first record

Once self.video is a numpy array, equality returns an element-wise array and triggers ValueError: The truth value of an array with more than one element is ambiguous.

This is exactly the failure reported in #835:

File "...recorders/ffmpeg_reader.py", line 109, in read
    if self.video == ():
ValueError: operands could not be broadcast together with shapes (10,720,1280,3) (0,)

isinstance(self.video, tuple) matches the pre-record sentinel without depending on equality.

Scope

• One file, four lines changed.
• Only affects users who set recording_plugin = ffmpeg in config.ini. Default (opencv) is unchanged.
• Cannot regress anyone, since the ffmpeg recorder is currently broken in master for everyone who tries it (ValueError: operands could not be broadcast together with shapes (10,360,640,3) (0,)  #835, Cannot use ffmpeg backend #1019).

Fixes #835.