can multi-thread encoding be used in real time video recording?

[stoneiii]

Hello, everyone. I meet a problem when I use x264 in realtime video producing. In my application, the x264 encodes one frame just after the frame is captured and then the next frame.

When I set b_sliced_threads to 1, I find encoding errors when I check the recorded video.

I set the encoding parameters as follows:

/*use default setting*/
x264_param->i_fps_den=1;
x264_param->i_fps_num=10; /*--keyint 100*/
x264_param->b_vfr_input=0; /*--force-cfr*/

x264_param->i_keyint_max=100; /*--keyint 100*/
x264_param->i_bframe=0; /*--bframes 0*/
x264_param->i_frame_reference=3; /*--ref 3*/
/*slow-firstpass: b_turbo=0*/

x264_param->rc.i_rc_method=X264_RC_ABR;
x264_param->rc.i_vbv_max_bitrate=200; /*--vbv-maxrate 200*/
x264_param->rc.i_vbv_buffer_size=100; /*--vbv-bufsize 2000*/

x264_param->rc.b_stat_read=0; /*--pass 1*/
x264_param->rc.b_stat_write=0; /*fix me*/
x264_param->rc.b_mb_tree=0; /*--no-mbtree*/
x264_param->rc.i_lookahead=0; /*--rc-lookahead 0*/
x264_param->i_sync_lookahead=0; /*--sync-lookahead 0*/

x264_param->i_width=width_edged; /*--input-res 800x600*/
x264_param->i_height=height_edged;

x264_param->b_intra_refresh=0;
x264_param->b_sliced_threads=1;
//x264_param->i_threads=1;

The video is ok when I set i_threads to 1 or b_sliced_threads to 0.

The incorrect decoded picture can be found here
https://blufiles.storage.live.com/y1pq-WEuAPYQyNoarcBKo8c5vYnUqWnMai994okXFkfLi5I8_5X0w2EORiPtFF4lRBk6X0-PHWDrDaQPkJoby7TeA/x264_b_sliced_threads.PNG?psid=1

[Blue_MiSfit]

It certainly can be used for real-time recording. In fact, I've recorded an HD-SDI feed at 1080i60 using the VFW interface through Digital Rapids' Stream software. This required 4 or 6 threads if I recall correctly, and I believe they were sliced.

So, it's definitely possible. I'm not sure how to help you accomplish your goal though :)

[Dark Shikari]

When I set b_sliced_threads to 1, I find encoding errors when I check the recorded video.What does this mean? If you have "encoding errors", it sounds like your decoder is broken. We regression-test x264's slice threading with every release.

[stoneiii]

What does this mean? If you have "encoding errors", it sounds like your decoder is broken. We regression-test x264's slice threading with every release.

the broken image is illustrated on the first floor.

I try decoding again by the JM17.2 decoder and the result is still wrong.

I upload a broken raw encoded video into my google docs.

https://docs.google.com/leaf?id=0B6VbQJgJB8hmZjZmMzg1OGQtMjY0Mi00Y2E0LWExNjctNDA0MWFhMzZiOTI1&hl=en_GB

b_sliced_threads is very important to me project. I really very need your help. Thanks!

[Dark Shikari]

the broken image is illustrated on the first floor.Do you mean the first post? The image link you posted requires a Live login of some sort. Use a free image hosting site.

If you have a corrupt file, please post the file itself, not some screenshot of the file.

Also, JM>16.2 is known to have bugs in sliced decoding.

[stoneiii]

Do you mean the first post? The image link you posted requires a Live login of some sort. Use a free image hosting site.

If you have a corrupt file, please post the file itself, not some screenshot of the file.

Also, JM>16.2 is known to have bugs in sliced decoding.

Thank you for reminding me.

Now, is the picture in the first post available?

I post a corrupt file in the third post. Is it accessible? https://docs.google.com/leaf?id=0B6VbQJgJB8hmZjZmMzg1OGQtMjY0Mi00Y2E0LWExNjctNDA0MWFhMzZiOTI1&hl=en_GB

[Dark Shikari]

I don't see any "corruption" in that video. It decodes without errors here.

[stoneiii]

I don't see any "corruption" in that video. It decodes without errors here.

and what decoder do you use?

I have tried ffmpeg r26400 and also find the corruption since the 35th frame.

[MasterNobody]

Make sure that you talking about decoding corruption (which I don't see) and not corruption of frames before libx264 gets them to encode (which is most probably the reason for artefacts in video).

[stoneiii]

Make sure that you talking about decoding corruption (which I don't see) and not corruption of frames before libx264 gets them to encode (which is most probably the reason for artefacts in video).

Yes, I am sure that the corruption happens after the libx264 gets the yuv.

I have conducted another recording to capture both the orginal yuv and the encoded bitstream. I only find corruption in the latter one.

In addition, I encoded this yuv file by orginal x264.exe with sliced threads. The output bitstream has no corruption.

My application with libx264 changes nothing but sending one yuv frame to libx264, waiting for the encoded data and the sending it another. The screen caputure part is single-threaded.
Does this lead to the current corruption?

[MasterNobody]

In addition, I encoded this yuv file by orginal x264.exe with sliced threads. The output bitstream has no corruption.
That means that something wrong in your app, either the way you use libx264 API (may be incorrect i_pts or something other) or with params you set (you didn't provide your params and there was none in file). Make sure that you use sane VBV limits (try to disable VBV if you use it).

[stoneiii]

That means that something . Make sure that you use sane VBV limits (try to disable VBV if you use it).

What is the "sane VBV limits"? How to set VBV max bitrate and VBV buffer size? Would you please give me some tips?

In the app above, I set VBV max bitrate to 1000kps and set VBV buffer size to 1000k and fps is 10.

[Blue_MiSfit]

Try with no VBV values to start, to eliminate that as a possible cause.