ljwun / bra Goto Github PK

Current condition is:

FrameCenter.Load()
FrameCenter.Allocate() 
if FrameCenter.Finshed == True:
    # ending workflow
else:
    # normal workflow

To achieve the Finished condition, the End condition must have been achieved. However, when the last frame of FrameCenter.Load() is the last available frame, the End condition is not satisfied. This condition will be satisfied only when FrameCenter.Load() is called in the next iteration. And call to FrameCenter.Allocate() afterwards will return the data of zero length.

Third party data is basically not updated.
Once the files in this repository are modified. Rebuilding the docker image and pushing on the image registry will incur additional costs to process the third-party data.

But dockerfile not support "copy exclude" like this:

cp -d ./[^third_party]* /BRA/

only can use like this:

COPY ./[^third_party]* /BRA/

but it cannot keep directories structure.

[ENG]
In c6af8e8, work_dev.py uses Delgan/loguru to enhance the logging, hope to reduce amount of logs during deploying on K8S. Unfortunately, OpenCV will destroy our logs structure. OpenCV directly redirects ffmpeg error messages to stderr. Not sure if other OpenCV backends also have this problem.

[中文]
在 c6af8e8 中，work_dev.py使用了 Delgan/loguru 來強化日誌的表達能力，希望部署上K8S後能以少量日誌來記錄狀態即可，遺憾的是OpenCV的error會破壞我們的日誌結構，OpenCV直接將ffmpeg的錯誤訊息重導到stderr，不確定其他OpenCV後端是否也有這個問題。

In past, we observed a issue by stream from YouTube via ytdl-org / youtube-dl. Following command is we used in past:

python ./work_dev.py -vin $(youtube-dl -4g https://www.youtube.com/watch?v=BAr79bcSeMs) -io_backend MIXFG ...

This issue make wrong video result. The whole video result would been black. But duration of this video is still correct.

We even thought that this was caused by some privacy policies of YouTube in past. However, when we fixed and tested the features related to Gstreamer, we found that this occurred only in the Gstreamer settings.

We first tested this issue by downloading a video from YouTube and running it as a local video input. But there was no change. Then we tested a different stream on YouTube in the same way. But this stream worked fine.

The first one we thought might be a design issue. But when we traced the changes to the framework. We found everything before line 266 of work/work_dev.py is well:

266                self.writer.write(bfr)

Then we modified this line to:

266                self.writer.write(cv2.resize(bfr), (1920,1080, 3))

to verify that this issued is caused by different resolutions. The result shows that there is a problem at H:1080. W:1842 resolution, but not at H:1080,W:1920 resolution. Whether it's the first stream, or the second stream.

This means that the issue is mainly caused by the gstreamer writer or appsrc element.

FFmpeg

code

command = ['ffmpeg',
    '-hwaccel', 'cuda',
    '-i', f'{video_path}',
    '-f', 'rawvideo',
    '-pix_fmt', 'bgr24',
    '-'
]
vreader_process = subprocess.Popen(
    command, shell=False, 
    stdout=subprocess.PIPE, 
    stderr=vreader_logFile,
)

for i in range(1, 751):
    buf = vreader_process.stdout.read(frame_size*batch)
    if len(buf) != frame_size*batch:
        break
    img = np.frombuffer(buf, np.uint8).reshape(frame_dim)

result after decoding 750 frame

OpenCV

code

cap = cv2.VideoCapture(video_path)
for i in range(1, 751):
    ret, img = cap.read()

result after decoding 750 frame