Problem with bumping process starting...

[Jamaika1]

[ 171] NALU --> B-slice (4971 bytes, poc=123, tid=4, [L0 122 120 ] [L1 124 128 ] End of file bumping process starting...

I don't know why the decoder stops working

[Jamaika1]

Why doesn't codec EVC have I frames as for VVC?

VVEncoderApp.exe -i "113.yuv" -o "output_10bit.vvc" -v 5 -t 4 -s 1280x720 -r 29 -c yuv420 -g 32 -ip 256 --internal-bitdepth 10 --bitrate 3Mbps --passes 1 -f 1000 --preset medium --level 6.3 --tier high

xeve_app.exe -i "113.yuv" -o "output_10bit.evc" --info 0 -v 3 -d 8 -m 4 -w 1280 -h 720 -z 29 -b 15 -I 256 --input-csp 1 --codec-bit-depth 10 --rc-type 1 --bitrate 3Mbps --frames 1000 --preset medium --level-idc 6.3 --profile main

POC   29 LId:  0 TId: 5 ( b-SLICE, QP 35 ) [DT  0.024] [L0 28 16 ] [L1  30c32 ]
POC   31 LId:  0 TId: 5 ( b-SLICE, QP 35 ) [DT  0.026] [L0  30c28 ] [L1 32 30 ]
POC   64 LId:  0 TId: 0 ( I-SLICE, QP 21 ) [DT  0.068] [L0 ] [L1 ]
POC   48 LId:  0 TId: 1 ( B-SLICE, QP 26 ) [DT  0.048] [L0  32c16 ] [L1 64 32 ]

[  14] NALU --> B-slice (117 bytes, poc=3, tid=4, [L0 2 0 ] [L1 4 8 ]
[  15] NALU --> Adaptation Parameter Set (52 bytes)
[  16] NALU --> B-slice (15375 bytes, poc=6, tid=3, [L0 4 0 ] [L1 8 16 ]
[  17] NALU --> B-slice (64 bytes, poc=5, tid=4, [L0 4 0 ] [L1 6 8 ]

[mss-park]

Why doesn't codec EVC have I frames as for VVC?

VVEncoderApp.exe -i "113.yuv" -o "output_10bit.vvc" -v 5 -t 4 -s 1280x720 -r 29 -c yuv420 -g 32 -ip 256 --internal-bitdepth 10 --bitrate 3Mbps --passes 1 -f 1000 --preset medium --level 6.3 --tier high

xeve_app.exe -i "113.yuv" -o "output_10bit.evc" --info 0 -v 3 -d 8 -m 4 -w 1280 -h 720 -z 29 -b 15 -I 256 --input-csp 1 --codec-bit-depth 10 --rc-type 1 --bitrate 3Mbps --frames 1000 --preset medium --level-idc 6.3 --profile main

POC   29 LId:  0 TId: 5 ( b-SLICE, QP 35 ) [DT  0.024] [L0 28 16 ] [L1  30c32 ]
POC   31 LId:  0 TId: 5 ( b-SLICE, QP 35 ) [DT  0.026] [L0  30c28 ] [L1 32 30 ]
POC   64 LId:  0 TId: 0 ( I-SLICE, QP 21 ) [DT  0.068] [L0 ] [L1 ]
POC   48 LId:  0 TId: 1 ( B-SLICE, QP 26 ) [DT  0.048] [L0  32c16 ] [L1 64 32 ]

[  14] NALU --> B-slice (117 bytes, poc=3, tid=4, [L0 2 0 ] [L1 4 8 ]
[  15] NALU --> Adaptation Parameter Set (52 bytes)
[  16] NALU --> B-slice (15375 bytes, poc=6, tid=3, [L0 4 0 ] [L1 8 16 ]
[  17] NALU --> B-slice (64 bytes, poc=5, tid=4, [L0 4 0 ] [L1 6 8 ]

Dear Jamaika1, I tried to check the problem, but it seems to work using a configuration similar to your command line on my side. Could you share the problematic bitstream?

And for I-frame issues, intra period setting seems to be the same as VVC and EVC is 256. However, the log you shared appears to be VVC and there may be a problem with the test. Please let me know if you have any other problems.

[Jamaika1]

Why is bumping process starting for VVC at the beginning of the video file and for evc at the end of encoding? How to decode video? xevd_app.exe -v 2 -i output_10bit.evc -o output_10bit.yuv --output-bit-depth 10

Example: https://www.sendspace.com/file/nlv75g

[mss-park]

I think it has different implementation of application. In the case of XEVE, bumping process works to input remaining picture into the codec, when picture reading is terminated but the already read picture remains. Thus, the process works at the end of the video file.

And your command for XEVD is working with shared bitstream on my side.

[kpchoi]

@Jamaika1 @mss-park

Could you decide whether this issue is still problem or not?

[Jamaika1]

My tests and latest codecs. https://www.sendspace.com/file/204ph0

I use gcc 12.0.1 20220429. http://msystem.waw.pl/x265/mingw-gcc1201-20220429.7z I use plugins for gcc thread/mutex/future/condition_variable https://github.com/Jamaika1/mingw_std_threads Currently no changes. The codec stops working if the movie ends in B-frames

[rwillenbacher]

I have a question.

Given Jamaika1's first Issue description it says: [ 171] NALU --> B-slice (4971 bytes, poc=123, tid=4, [L0 122 120 ] [L1 124 128 ]

So I am under the impression that the last POC in the stream is 123 but there is also a picture with POC 124 and 128.

Maybe it was supposed to be some GOP like this:

Display Order:
Actual:         [ 121 122 123 124 125 XXX XXX XXX ]
POC: prev 120 ] [ 121 122 123 124 XXX XXX XXX 128 ]
DOC: prev 120 ] [ 124 123 125 122 XXX XXX XXX 121 ]

With XXX not coded.

So Bumping is done in XEVD with this:

    for(i = 0; i < MAX_PB_SIZE; i++)
    {
        if(ps[i] != NULL && ps[i]->need_for_out)
        {
            any_need_for_out = 1;

            if((ps[i]->poc <= pm->poc_next_output))
            {
                ps[i]->need_for_out = 0;
                pm->poc_next_output = ps[i]->poc + pm->poc_increase;

                if(err) *err = XEVD_OK;
                return ps[i];
            }
        }
    }
    if(any_need_for_out == 0)
    {
        ret = XEVD_ERR_UNEXPECTED;
    }
    else
    {
        ret = XEVD_OK_FRM_DELAYED;
    }

If it hits POC 124 and pm->poc_increase is not 4 it will never reach POC 128, returning XEVD_OK_FRM_DELAYED which is not an error so it will get called again, endlessly returning XEVD_OK_FRM_DELAYED again and again.

I remember hitting the same spot when developing an EVC encoder and implemented closed GOP so it would encode such a partial GOP like this:

Display Order:
Actual:         [ 121 122 123 124 125 XXX XXX XXX ]
POC: prev 120 ] [ 121 122 123 124 125 XXX XXX XXX ]
DOC: prev 120 ] [ 123 122 124 121 125 XXX XXX XXX ]

Like, real decode order truncation to work around the POC derivation process and the subsequent bumping problems.

Maybe this was fixed indirectly in XEVE/XEVD with Closed GOP support ?

For example if I encode some stream with XEVE now:

xeveb_app.exe -i foreman_cif.yuv -w 352 -h 288 --fps 25 -o test.evc --ref 4 -v 3 --frames 129

POC   Tid   Ftype   QP   PSNR-Y    PSNR-U    PSNR-V    Bits      EncT(ms)  Ref. List
[...]
128    0    (B)     33   34.6260   40.1754   42.1861   20008     234       [L0 112 96 80 64 ] [L1 112 96 80 64 ]
120    1    (B)     35   34.4852   40.6687   42.8362   6592      187       [L0 112 96 80 64 ] [L1 128 112 96 80 ]
116    2    (B)     38   34.0315   40.7177   42.8273   2600      156       [L0 112 96 80 64 ] [L1 120 128 112 96 ]
124    2    (B)     38   33.7994   40.5131   42.5502   4280      172       [L0 120 112 96 80 ] [L1 128 120 112 96 ]
114    3    (B)     40   34.3449   40.7644   42.8069   880       125       [L0 112 96 80 64 ] [L1 116 120 128 112 ]
118    3    (B)     40   34.0557   40.8265   43.0769   1080      110       [L0 116 112 96 80 ] [L1 120 128 116 112 ]
122    3    (B)     40   33.7010   40.7021   43.1513   1304      125       [L0 120 112 96 80 ] [L1 124 128 120 112 ]
126    3    (B)     40   33.4066   40.4567   42.6778   2232      141       [L0 124 120 112 96 ] [L1 128 124 120 112 ]
113    4    (B)     41   34.3984   40.7811   42.8561   328       78        [L0 112 96 80 64 ] [L1 114 116 120 128 ]
115    4    (B)     41   34.0138   40.7859   42.7937   552       78        [L0 114 112 96 80 ] [L1 116 120 128 114 ]
117    4    (B)     41   34.0126   40.8164   42.9282   448       94        [L0 116 112 96 80 ] [L1 118 120 128 116 ]
119    4    (B)     41   34.1938   40.8612   43.2267   560       78        [L0 118 116 112 96 ] [L1 120 128 118 116 ]
121    4    (B)     41   33.9750   40.7226   43.1295   432       78        [L0 120 112 96 80 ] [L1 122 124 128 120 ]
123    4    (B)     41   33.5960   40.6847   42.9771   560       125       [L0 122 120 112 96 ] [L1 124 128 122 120 ]
125    4    (B)     41   33.2757   40.5222   42.8916   720       78        [L0 124 120 112 96 ] [L1 126 128 124 120 ]
127    4    (B)     41   33.6179   40.4415   42.6832   848       78        [L0 126 124 120 112 ] [L1 128 126 124 120 ]

And decode that with XEVD I get:

[ 130] NALU --> B-slice (90 bytes, poc=125, tid=4, [L0 124 120 112 96 ] [L1 126 128 124 120 ]
[ 131] NALU --> B-slice (106 bytes, poc=127, tid=4, [L0 126 124 120 112 ] [L1 128 126 124 120 ]
End of file
bumping process starting...
bumping process completed

But if I cut off the last NALU (106 bytes) and decode that I get:

[ 130] NALU --> B-slice (90 bytes, poc=125, tid=4, [L0 124 120 112 96 ] [L1 126 128 124 120 ]
End of file
bumping process starting...

and an endless loop.

But with the limited testing I did I was not able to get XEVE to produce a stream which had POC gaps in the last GOP. So maybe it works now ?

How is this supposed to work anyway ? I mean according to the standard document (which I don't have) ?

@Jamaika1 can you please recompile xeve and xevd in their respective latest versions and try again. The thing to look out for is the "POC" and "Tid" in the encode log. There should be no missing integer numbers in the POCs for the GOP at the end of stream. Tid going lower (like from =4 to =0 ) should mean a new GOP is starting.

[mss-park]

The display order and encoding(decoding) order is different when reordered B frames is used. And current application of XEVD requests frames as display order to XEVD library. Aand the coding order can be different based on the profile of EVC. (The encoding order can be configured according to the Spec. but it is not supported in XEVE yet. The changing GOP only works on the last GOP of sequence or last GOP of Intra period with closed GOP in XEVE.)

For example, in case of GOP16,

Display order is 0, 1, 2, 3, 4, 5, 6, …, 15, 16, 17… Coding order is 0, 16, 8, 4, 2, 1, 3, …, 15, 32, ...
(or 0, 16, 8, 4, 12, 2, 6, 10, 14, 1, 3, …, 15, 32, ... )

Thus, decoder has some remaining frames to be output before decoding is completed as

Buffer to be output [16, 8, 4, 2], output frames [0] after decoding frame 2 Buffer to be output [16, 8, 4, 2], output frames [0, 1] after decoding frame 1 Buffer to be output [16, 8, 4, 3], output frames [0, 1, 2] after decoding frame 3

In this case, when the coding is completed, the remaining buffer is outputted without decoding, and it is the meaning of bumping process in XEVD application.

And I think, the problem of endless loop can be caused by problem of bitstream. In the encoding command, the end of sequence is 1000, but decoding process ends after 123 frame. Thus, some frame, such as frame 125, are not decoded but POC of remaining frame in buffer is greater than 125 and previously decoded cannot be outputted, such as 128 frame. Please test it with latest XEVE and XEVD and let me know if you still have any problmes.

[Jamaika1]

New codecs GCC 13.0.0 https://forum.doom9.org/showthread.php?t=174300&page=24 https://www.sendspace.com/file/dakqxe