MantisBT - Issues

0000376: Error compiling project

Tue, 28 Mar 2023 00:06:02 +0200

$make
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:107: bin] Error 1
make[1]: se sale del directorio '/jm19/JM/lencod'
make: *** [Makefile:40: lencod] Error 2

0000373: Artefacts present on decoded sequence - Mismatch between encoder reconstruction & decoder

Wed, 17 Mar 2021 13:56:38 +0100

When encoding one specific operating point of the Starcraft sequence using JM 19.0, pink artefacts are present on the decoded sequence in the top left corner (see attached screenshot). These artefacts start with POC 137, then build up over time, and disappear again with POC 192. The artefacts are also present when using a different decoder than JM 19.0. However, the encoder reconstruction of JM does not show this issue.

0000370: Error “Duplicate frame_num in short-term reference picture buffer”

Wed, 24 Feb 2021 08:59:26 +0100

Dear Prof. Karsten Suehring:
Today, I want to report a bug, this bug has been bothering me frequently. In our experiment, we want to analyze the Error Concealment algorithm. The packet loss of the test video is set to 0.1%, 0.4%, 1%, 4%, 10% and so on. The total encoded frame is 200. In our experiment setting, when one packet is loss, it means the whole frame is loss. The Error Concealment mode is set to 1 (Frame copy). In one of our experiment, the total lost frame rate is 8%, the decoder can conceal the first 11 lost frames, but it can not conceal the twelfth frame. It throw an error message “Duplicate frame_num in short-term reference picture buffer”. I wonder if you can help us to correct this But. Thanks.

Your Sincerely
Jensen Chen

0000366: Error in deblocking process of mbaff frames

Wed, 25 Nov 2020 16:28:35 +0100

Hi,

It seems that there is a error in JM H.264 decoder in deblocking process of MbAff frames for luma field macroblocks. The following is for JM 11.0 but the same problem also exists in newer versions.

The error is in calculating pixQ.pos_y in loopfilter.c. In EdgeLoop() you use getNeighbour() for it.
Pos_y calculated in get_mb_pos(), get_mb_block_pos() as

y = (((mb_addr / 2) / PicWidthInMbs) * 2 + (mb_addr % 2)) * 16; i.e.
y = ((mb_addr / 2) / PicWidthInMbs) * 32 + ((mb_addr % 2) * 16)

It is a position of the upper-left luma sample of the macroblock CurrMbAddr and it is determined in standart (subclause 8.7.1) as inverse macroblock scanning process (6.4.1) and assigned to yI:

y = ((mb_addr / 2) / (PicWidthInSamples / 16)) * 32 + (mb_addr % 2); i.e.
y = ((mb_addr /2) / PicWidthInMbs) * 32 + (mb_addr % 2)

So for odd values of mb_addr the result in JM is wrong.

0000363: The vertical motion vector component range

Tue, 09 Oct 2018 14:44:13 +0200

Hallo.

I have interlaced stream in bitstream_1080i.h264 file.
To decode, I run the command:

ldecod.exe -i bitstream_1080i.h264

The decoding have following warnings:

WARNING! Vertical motion vector -1600 is out of allowed range {-1024, 1023} in picture 1, macroblock 763
WARNING! Vertical motion vector -1680 is out of allowed range {-1024, 1023} in picture 1, macroblock 2077
WARNING! Vertical motion vector -1696 is out of allowed range {-1024, 1023} in picture 1, macroblock 2423
WARNING! Vertical motion vector -1333 is out of allowed range {-1024, 1023} in picture 1, macroblock 3330
WARNING! Vertical motion vector -2048 is out of allowed range {-1024, 1023} in picture 1, macroblock 3422

The maximum absolute value of a decoded vertical or horizontal motion vector component is constrained by profile and level limits as specified in Annex A of the ITU-T Specification.
The vertical motion vector component range for level 4.0 does not exceed -512, +511.75 in units of luma frame samples, which is equal -2048, +2047 in 1/4 units.

In set_chroma_vector function in mb_prediction.c file, the maximum range is reduced from -2048, +2047 to -1024, +1023 for interlaced stream:

currSlice->max_mb_vmv_r = (currSlice->structure != FRAME || ( currMB->mb_field )) ? p_Vid->max_vmv_r >> 1 : p_Vid->max_vmv_r;

I did not find in the ITU-T Specification any information about the reduction of the maximum range for vertical motion vectors for interlaced streams.
Maybe this line is incorrect? And to avoid WARNINGS, just need to change it to:

currSlice->max_mb_vmv_r = p_Vid->max_vmv_r;

Best Regards,
Sergey

0000362: 12 bit lossless compression mode in JM

Tue, 09 Oct 2018 08:16:09 +0200

Hi Experts,

I am stuck in making 12 bit lossless compression mode to work in JM encoder.
Wanted to confirm if JM encoder supports lossless compression in 12 bit mode for YUV.

For lossless mode I have done the following.

1) set all quantization parameters (i/p/b-frames) to 0
2) set the lossless flag to 1 (qpprime_y is zero)
3) set the profile to 244.

Please point me in the correct direction if I am missing anything.

Thank you.

Best Regards,
Sujith

0000361: Cannot find any input value to av,ac in ParseCommand() function

Fri, 17 Aug 2018 07:22:29 +0200

Although ParseCommand(InputParameters *p_Inp, int ac, char *av[]) has input parametrs, when the function is called, the caller does not pass the value but just pass the parameter names. ParseCommand(p_Inp,ac,av[]). I would like to know how the ac, av value is calculated and how ac,av value is initialized or added.

0000360: crash when encoding to intra profile

Wed, 05 Jul 2017 16:09:42 +0200

maybe I setup something wrong.
config file attached.

briefly about the config - High profile where all the frames should be IDR. Enabled Rate Control, and set bitrate to 1 Mbps.
Source and dest sizes are the same: 360x260

0000159: JM decoder crashes with a lost NAL unit... (erc_do_p.c)?

Mon, 24 Apr 2017 11:43:44 +0200

Hi,

I have encoded a YUV file with an H.264 encoder (x264). Then to simulate the channel error, I drop one of the NAL units of this encoded file (in the middle of the video, frame 150). But unfortunately, when I try to decode it with JM decoder I got the following errors:

> ldecod.exe decoder.cfg

case 1: in decoder.cfg we set Err Concealment mode = 0
in this case I got this error on frame 150 : An unintentional loss of pictures occures! Exit

case 2: in decoder.cfg we set Err Concealment mode = 1 or 2
in this case at the begining of the decoding process (at frame 1) I got the following error:

0000(I) 0 0 10 4:2:0 140
Assertion failed: conceal_from_picture != NULL, file c:\jm\lencode\src\erc_do_p.c, line 1725

Actually, in the second case JM crashes. Please note that I can play this encoded file (even in the case that some of its NAL units have been dropped) with VLC player with no error. But what is the problem? Could you please help me? Thank you in advance!

[Edited to avoid linking to unrelated bugs, KS]

0000358: leading_zero_8bits error incorrectly reported, decoder stops

Wed, 09 Mar 2016 14:54:45 +0100

Hi,

The following message is incorrectly displayed and the decoder stops:
GetAnnexbNALU: The leading_zero_8bits syntax can only be present in the first byte stream NAL unit, return -1
Error while getting the NALU in file format Annex B, exit

Since version JM 16.0 there is not initialized variable
'IsFirstByteStreamNALU' in the file ldecod/src/annexb.c
There is variable initialization in function init_annex_b:
void init_annex_b(ANNEXB_t *annex_b)
{
.......
annex_b->IsFirstByteStreamNALU = 1;
.......
}
however this function is never used.

Decoding of input file which has any number of leading_zero_8bits before NAL unit start indicator (0x00000001) ends with error.

Best Regards,
Pavel

0000357: RTP mode while decoding gives error "slice_qp_delta makes slice_qp_y out of range" in jm 19.0

Sun, 03 Jan 2016 00:02:23 +0100

I have been trying to encode a video then apply packet loss model after which I try to decode file but it gives error "slice_qp_delta makes slice_qp_y out of range".

The problem exists even If I don't apply packet loss model.

0000356: violated constraint in the section A.3.3 as specified in the point e)

Mon, 13 Jul 2015 18:02:35 +0200

Dear Karsten, Alexis, All,

I'm thinking there is another 'similar' violation in the JM but this one probably looks like more easily to be cleanly fixed.
Please take a look at statement in the section A.3.3 as specified in e):

e) In bitstreams conforming to the Main, High, Progressive High, High 10, High 4:2:2, High 4:4:4 Predictive, or Extended profiles, the value of sub_mb_type[ mbPartIdx ] with mbPartIdx = 0..3 in B macroblocks with mb_type equal to B_8x8 shall not be equal to B_Bi_8x4, B_Bi_4x8, or B_Bi_4x4 for the levels in which MinLumaBiPredSize is shown as 8x8 in Table A-4 for the Main, High, Progressive High, High 10, High 4:2:2, High 4:4:4 Predictive profiles and in Table A-5 for the Extended profile.

In my bitstreams, I’m certainly seeing ‘not to be used’ the B_Bi_8x4 and 4_8 subpartitions at the higher Levels >=3.1 per MinLumaBiPredSize = 8x8

After you’ll have a chance to confirm that the above check is not enforced in the JM19, I’ll report this into the BugTracker.

Best regards,

Andrew

0000355: MaxMvsPer2Mb constraint violated per the Table A-1 = Number of MVs per two consecutive MBs exceeded limit

Wed, 08 Jul 2015 19:23:01 +0200

Dear Karsten, Experts,

I have just encoded some 1080p video content at different frame rates using the JM 19.0. After checking for the bit-streams conformance, I'm getting a number of the messages: 'Number of MVs per two consecutive MBs exceeded limit. Max is 16, found 19. I suppose, that refers to the violated constraint for the MaxMvsPer2Mb in the Table A-1 Level limits. As expected that tend to happens at lower QP values, when better video quality is achievable.
Thanks!

ps. the example bitstream is type30QPB202020.h264 - but can't be uploaded due to size limit > 5000k below - will try to send it directly to Karsten

0000340: error in motion vector copy concealment at the decoder

Wed, 08 Jul 2015 16:27:36 +0200

Hi, there
we encode 10 frames in baseline profile and it gives us 12 RTP packets.
after that we run rtp_loss with 18% PLR the result is that the packet number 10 is lost that makes frame number 9 is lost. when we run ldecod.exe with frame copy concealment there isn't any problem but when we run it with motion vector copy then decoder can't decode video and rec file is then 0Kb. when we traced the ldecod.exe we found that when decoder reaches to frame number 9 that is lost and wants to conceal it in the function copy_to_conceal the value of p_Vid->dec_picture is null. in frame copy we don't have any problem (because there is no need to this parameter) but in motion vector copy because it uses this parameter in function buildPredblockRegionYUV then it can't continue it's concealing process. we want to ask that whether this issue is logical and we should repair it or not? thank's a lot if you help us to solve this issue.

Thanks A lot

0000330: use of >, >=, <, <= with profile_idc

Tue, 16 Jun 2015 14:08:42 +0200

H.264 profile_idc is not a monotonically increasing value, rather it is an enumeration.

use of >, >=, <, <= with profile_idc is NOT recommended.

In JM 18.5, use of >, >=, <, <= with profile_idc:
lines 271 and 272 in ldecod/inc/defines.h
lines 1091 and 1095 in ldecod/inc/global.h
lines 1609 in lencod/inc/global.h
line 1847 in ldecod/src/mbuffer.c
line 597 in ldecod/src/parset.c

0000351: Redundant Picture - unable to decode

Mon, 11 May 2015 15:09:03 +0200

I am encoding 25 frames of a 210x118 video in the baseline profile. The use of redundant pictures is enabled and it looks like the encoder is properly doing its job (no error message, neither any warnings).

However, as the decoder starts, it throws out an error and quit : " RefPicList0[ num_ref_idx_l0_active_minus1 ] is equal to 'no reference picture', invalid bitstream "

I attached the encoder config file.

0000350: new values of log2_max_frame_num are not accepted

Thu, 30 Apr 2015 08:57:08 +0200

Hi all

While working with JM18.0 decoder i encounter the following problem:

i have a h264-file test file (attached as test_max_frame_num_bug.264), the file consists of two GOPs (18 frames of each, totally 36 frames).
The first GOP has log2_max_frame_num_minus4=12 (MaxFrameNum=64k) while the second GOP has log2_max_frame_num_minus4=0 (MaxFrameNum=16).

The JM18.0 decoder fails processing the test file, it abnormally exits at frame 0000033 with the following error:
…..
Picture 32, Type P
00014( P ) 28 14 28 0.0000 0.0000 0.0000 4:2:0 1
Picture 33, Type P
00015( P ) 30 15 28 0.0000 0.0000 0.0000 4:2:0 1
An unintentional loss of pictures occurs! Exit

The test file is compliant, because it actually is a concatenation of two compliant self-contained GOPs.

The reason of failure is:
JM18.0 accepts log2_max_frame_num only at the start of stream, if a SPS with a different log2_max_frame_num is present in the middle of the stream, the new value of log2_max_frame_num is ignored (unlike to other parameters of SPS/PPS).

More precisely, the value of MaxFrameNum is assigned at the function ‘set_coding_par’ (parset.c) only:

cps->MaxFrameNum = 1<<(sps->log2_max_frame_num_minus4+4);

The function ‘set_coding_par’ in turn is called in the function ‘activate_sps’ only:

if(p_Vid->dpb_layer_id==0 && is_BL_profile(sps->profile_idc) &&
!p_Vid->p_Dpb_layer[0]->init_done)
{
set_coding_par(sps, p_Vid->p_EncodePar[0]);
setup_layer_info( p_Vid, sps, p_Vid->p_LayerPar[0]);
}
else if(p_Vid->dpb_layer_id==1 && is_EL_profile(sps->profile_idc) &&
!p_Vid->p_Dpb_layer[1]->init_done)
{
set_coding_par(sps, p_Vid->p_EncodePar[1]);
setup_layer_info(p_Vid, sps, p_Vid->p_LayerPar[1]);
}

Upon activation of the very first SPS, MaxFrameNum is set and the flag p_Vid->p_Dpb_layer[0]->init_done is set to 1. As a result new values of log2_max_frame_num are ignored. Actually the decoder processes a stream with obsolete log2_max_frame_num.

Regarding to the failure of the test file, log2_max_frame_num in the first SPS is 16 (or MaxFrameNum=64k) and this value is adopted (since it is present in the very first SPS). When the JM18.0 decoder starts processing the second GOP
it expects that after frame_num=15 the following frame_num is 16, however frame_num values in the second GOP are incremented modulo 16, hence the following frame_num is 0. Consequently the decoder considers the situation as frame(s) loss and reports error respectively.

We suggest removing the condition !p_Vid->p_Dpb_layer[0]->init_done in activate_sps function. We propose to replace the condition:

if(p_Vid->dpb_layer_id==0 && is_BL_profile(sps->profile_idc) && !p_Vid->p_Dpb_layer[0]->init_done)
{
set_coding_par(sps, p_Vid->p_EncodePar[0]);
setup_layer_info( p_Vid, sps, p_Vid->p_LayerPar[0]);
}
else if(p_Vid->dpb_layer_id==1 && is_EL_profile(sps->profile_idc) && !p_Vid->p_Dpb_layer[1]->init_done)
{
set_coding_par(sps, p_Vid->p_EncodePar[1]);
setup_layer_info(p_Vid, sps, p_Vid->p_LayerPar[1]);
}

With

if(p_Vid->dpb_layer_id==0 && is_BL_profile(sps->profile_idc) )
{
set_coding_par(sps, p_Vid->p_EncodePar[0]);
setup_layer_info( p_Vid, sps, p_Vid->p_LayerPar[0]);
}
else if(p_Vid->dpb_layer_id==1 && is_EL_profile(sps->profile_idc))
{
set_coding_par(sps, p_Vid->p_EncodePar[1]);
setup_layer_info(p_Vid, sps, p_Vid->p_LayerPar[1]);
}

0000348: Static buffer overflow in function biari_init_context() on arrays INIT_FLD_MAP_I and INIT_FLD_LAST_I

Thu, 16 Apr 2015 12:28:30 +0200

The static global array INIT_FLD_MAP_I[1][8][15][2] is read past its boundary in function biari_init_context() on line 299 using the ini pointer:

int pstate = ((ini[0]* qp )>>4) + ini[1];

On line 90 in ldecod/src/context_ini.c the following macro is expanded with the NUM_BLOCK_TYPES argument equal to 22.

IBIARI_CTX_INIT2 (NUM_BLOCK_TYPES, NUM_MAP_CTX, tc->map_contexts[1], INIT_FLD_MAP, model_number, qp);

This NUM_BLOCK_TYPES argument specifies the number of i loop iterations in the macro definition, where i indexes the second dimension of the array. The second dimension of INIT_FLD_MAP_I[1][8][15][2] has only 8 entries and array accesses with the i values between 8 and 21 quickly cause out of bound memory reads.

The same problem occurs on line 91 in ldecod/src/context_ini.c for the INIT_FLD_LAST_I[1][8][15][2] array.

This bug was detected by Pareon Verify, a software verification tool from Vector Fabrics, http://www.vectorfabrics.com/products/pareon_verify. The report Pareon Verify generated for JMDecode is attached as jmdecode.verify.log.

0000345: MBAFF loopfilter mismatch with standard

Mon, 13 Apr 2015 15:46:15 +0200

In function edge_loop_luma_ver_MBAff, all filter process is disable by
if(MbQ->DFDisableIdc ==0)
when MbQ->DFDisableIdc equals to 2.

0000347: "double free" crash in the low-delay mode

Mon, 13 Apr 2015 15:06:45 +0200

The encoder crashes after encoding the first IDR frame when I'm trying to implement a low-delay hierarchical-P coding structure. The configuration file I'm using is attached. Below is the terminal output:

00000(IDR) 47904 168 0 28 6 39.002 43.168 42.430 52 0 FRM 396 0 0 0 0 3
*** Error in `./lencod.exe': double free or corruption (fasttop): 0x0000000002dc7260 ***
Aborted (core dumped)

0000302: Cannot run lencod

Sat, 28 Feb 2015 19:37:10 +0100

I wish get file.264 but i can not because this error is showed when i try to do

C:\Users\Gloria\Desktop\JM1\bin>lencod -d encoder.cfg
Setting Default Parameters...
Parsing Configfile encoder.cfg..................................................
................................................................................
................................................................................
................................................................................
................................................................................
.............................

Warning: Hierarchical coding or Referenced B slices used.
Make sure that you have allocated enough references
in reference buffer to achieve best performance.
AdaptiveRounding is disabled when RDO Quantization is used
Warning: CRA can only be used for IntraPeriod > 0, set CRA to 0
Warning: HM50LikeMMCO can only be used for random access case with GOP size equa
l to 8 and HM-5.0 coding order
If it used for other coding structure, the performance may loss
Warning: useF701RefForLD can only be used for low delay case with GOP size equal
to 4 and 4 reference frames as HM-5.0 low delay
If other GOP size or number of reference frames are used, the performan
ce may be loss with useF701RefForLD
useF701RefForLD can only be used when LowDelay is 1

0000346: The decoder does not support a bitstream with change of resolution

Fri, 13 Feb 2015 21:34:09 +0100

If a bitstream contains a new SPS/PPS and IDR pic in the middle of the stream for a new resolution, the decoder will fail to continue to decode. This seems to be due to the last frame before the new SPS/PPS and IDR pic doesn't get properly decoded. The last frame seems to incorrectly use the new SPS.

This problem goes away if we insert either end of sequence or end of stream NAL before the new SPS/PPS and IDR pic. But I think the decoder should function properly even without the EOS NALs.

0000344: Error in assignment of PMVy

Tue, 08 Jul 2014 18:21:49 +0200

in function "UMHEXSetMotionVectorPredictor()" of file me_umhex.c, line 1271:
if (!p_Vid->mb_aff_frame_flag || hv==0)
forces the PMVy to get the X value of its neighbors instead of Y, when the frame is in progressive format.
it should change to:
if (hv==0)

0000343: program does not create result histogram for single yuv-image

Thu, 19 Jun 2014 07:27:19 +0200

the configuration encoder file for yuv file is:
2143.yuv width=240 and height=512

hand image size -which is one of MRI medical image of IRMA (ImageCLEFmed2009_train)- is 247 *512.
I set width and height -240*512- in configuration encoder for mod 8.
but It doesn't work and result in histogram.

0000342: CAVLC_LEVEL_LIMIT fixed for all profiles while it should be dependent on the PROFILE

Fri, 06 Jun 2014 11:04:02 +0200

In the current JM18.6 version CAVLC_LEVEL_LIMIT is fixed in defines.h files:

This value should be limited only for some profiles mentioned in the standard and not limited for other profile.

NOTE 1 – When entropy_coding_mode_flag is equal to 0 and qP is less than 10 and profile_idc is equal to 66, 77, or 88, the range of values that can be represented for the elements cij of c is not sufficient to represent the full range of values of the elements dcYij of dcY that could be necessary to form a close approximation of the content of any possible source picture by use of the Intra_16x16 macroblock type.

NOTE 2 – Since the range limit imposed on the elements dcYij of dcY is imposed after the right shift in Equation 8-322, a larger range of values must be supported in the decoder prior to the right shift.

NOTE 1 – When entropy_coding_mode_flag is equal to 0 and qP is less than 4 and profile_idc is equal to 66, 77, or 88, the range of values that can be represented for the elements cij of c in clause 8.5.11.1 may not be sufficient to represent the full range of values of the elements dcCij of dcC that could be necessary to form a close approximation of the content of any possible source picture.

NOTE 2 – Since the range limit imposed on the elements dcCij of dcC is imposed after the right shift in Equation 8-326 or 8-329, a larger range of values must be supported in the decoder prior to the right shift.

NOTE – The value of level_prefix is constrained to not exceed 15 in bitstreams conforming to the Baseline, Constrained Baseline, Main, and Extended profiles, as specified in clauses A.2.1, A.2.1.1, A.2.2, and A.2.3, respectively. In bitstreams conforming to other profiles, it has been reported that the value of level_prefix cannot exceed 11 + bitDepth with bitDepth being the variable BitDepthY for transform coefficient blocks related to the luma component and being the variable BitDepthCfor transform coefficient blocks related to a chroma component.