[Mp4-tech] [Mp-4][H.264]te(v) decoding problem in JM software

[Alexis Michael Tourapis]

Dear Gary and Mr. Xu
I am assuming that this case described here is for when there are only two reference frames in the reference buffer (CAVLC). This particular case corresponds to the following part of the text in section 9.1 :
-        If x is greater than 1, codeNum and the value of the syntax element shall be derived in the same way as for syntax elements coded as ue(v)
-        Otherwise (x is equal to 1), the parsing process for codeNum which is equal to the value of the syntax element is given by a process equivalent to:
         b = read_bits( 1 )
codeNum = !b
If you carefully examine the code you will notice that for this case the decoder calls the function readSyntaxElement_FLC. What is printed in the tracefile is however b and not !b (see line 1811 in macroblock.c) and as Gary suggested it is just an issue with the tracefile generation. 
Best regards,
Alexis
-------------- Original message -------------- 
> Sounds like a bug, but it's hard to believe a bug that severe could 
> exist in our software at this stage. I suspect that it is simply 
> printing something different than it is seeing, while its interpretation 
> is actually correct. 
> 
> I confirm what I previously said, and I point to subclause 9.1, which 
> provides the following pseudo-code for this case: b = read_bits( 1 ); 
> codeNum = !b. So the decoded value is the opposite of the value of the 
> bit that represents it in the bitstream. 
> 
> -Gary 
> 
> +> -----Original Message----- 
> +> From: mp4-tech-bounces lists.mpegif.org 
> +> [mailto:mp4-tech-bounces lists.mpegif.org] On Behalf Of Xu Ke 
> +> Sent: Monday, April 25, 2024 7:11 AM 
> +> To: mp4-tech 
> +> Subject: [Mp4-tech] [Mp-4][H.264]te(v) decoding problem in 
> +> JM software 
> +> 
> +> Dear experts, 
> +> When I am reading the trace file dumpped by the JM94 
> +> software,I am quite confused by the following decoding process: 
> +> 
> +> @25654 mb_type 011 ( 2) 
> +> @25657 ref_idx_l0 1 ( 1) 
> +> @25658 ref_idx_l0 0 ( 0) 
> +> @25659 mvd_l0 1 ( 0) 
> +> @25660 mvd_l0 1 ( 0) 
> +> @25661 mvd_l0 011 ( -1) 
> +> @25664 mvd_l0 1 ( 0) 
> +> @25665 coded_block_pattern 1 ( 0) 
> +> For ref_idx_l0,which is coded as te(v),if bitstream 
> +> is"1",the output syntax value is also "1". However,as in the 
> +> standard,that's should be "0" instead.(We can refer to Gary 
> +> Sullivan's previous email "In other words, the value 0 is 
> +> coded as 1 and the value 1 is coded as 0").Is this a bug in 
> +> JM software94? Would anybody be kind to make it clear to me? 
> +> 
> +> Many thanks!! 
> +> 
> +> Best regards, 
> +> XU Ke 
> +> 
> +> _______________________________________________ 
> +> NOTE: Please use clear subject lines for your posts. Include 
> +> [audio, [video], [systems], [general] or another 
> +> apppropriate identifier to indicate the type of question you have. 
> +> 
> +> Note: Conduct on the mailing list is subject to the 
> +> Antitrust guidelines found at 
> +> http://www.mpegif.org/public/documents/vault/mp-out-30042-Ant 
> +> itrust.php 
> +> 
> 
> _______________________________________________ 
> NOTE: Please use clear subject lines for your posts. Include [audio, [video], 
> [systems], [general] or another apppropriate identifier to indicate the type of 
> question you have. 
> 
> Note: Conduct on the mailing list is subject to the Antitrust guidelines found 
> at http://www.mpegif.org/public/documents/vault/mp-out-30042-Antitrust.php 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20050426/0ba519f9/attachment-0001.html