[Mp4-tech] RE: Deblocking at slice level

[Gomathi Ramamoorthy]

Hi all,
I got the below statement from the standard 
"when disable_deblocking_filter_idc is equal to 2, macroblocks in different
slices are considered not available during specified
steps of the operation of the deblocking filter process".
Also in the JM reference code , when the disable_deblocking_filter_idc is
equal to 2 and the top and left neighbouring macroblocks are not available,
the flags 
filterLeftMbEdgeFlag and filterTopMbEdgeFlag  are disabled.
if (MbQ->LFDisableIdc==2)
             {
                        // don't filter at slice boundaries
                        filterLeftMbEdgeFlag = MbQ->mbAvailA;
                        // if this the bottom of a frame macroblock pair then
always filter the top edge
                         filterTopMbEdgeFlag  = MbQ->mbAvailB;
             }
So what is the significance of "disable_deblocking_filter_idc" being 2 then
Thanks and Regards,
Gomathi.
________________________________
From: LinCheng Wang [mailto:lcw95129 sbcglobal.net] 
Sent: Sunday, November 04, 2023 6:10 AM
To: Gomathi Ramamoorthy; mp4-tech lists.mpegif.org
Subject: RE: [Mp4-tech] RE: Deblocking at slice level
Gomathi,
disable_deblocking_filter_idc, specified in slice_header(), decides the
behavior of deblocking filter.
When disable_deblocking_filter_idc is 0, the deblocking process filters on MB
edges, regardless of slice boundaries.
It supports Gary's statement.
Bit-perfect decoded pictures are not guaranteed, if you perform deblocking at
slice level, on any of the following conditions:
1. FMO,
2. ASO,
3. Redundant coded pictures.
Regards,
LinCheng
________________________________
From: mp4-tech-bounces lists.mpegif.org
[mailto:mp4-tech-bounces lists.mpegif.org] On Behalf Of Gary Sullivan
Sent: Friday, November 02, 2023 6:12 PM
To: Gomathi Ramamoorthy; mp4-tech lists.mpegif.org
Subject: [Mp4-tech] RE: Deblocking at slice level
Gomathi Ramamoorthy et al,
I believe the statement saying that "the standard clearly tells that no need
of deblocking at slice boundaries " is false.
(at least when speaking something being always true from the decoding
perspective)
Best Regards,
Gary  Sullivan
________________________________
	From: mp4-tech-bounces lists.mpegif.org
[mailto:mp4-tech-bounces lists.mpegif.org] On Behalf Of Gomathi Ramamoorthy
	Sent: Thursday, November 01, 2023 10:25 PM
	To: mp4-tech lists.mpegif.org
	Subject: [Mp4-tech] Deblocking at slice level
	Dear all,
	In the JM reference code deblocking is being done at frame level.
I've changed the code such that deblocking slice after decoding one slice .
It holds good and bit exact with the Jm software output for normal files. For
FMO files since I'm deblocking at slice level the output doen't match but the
picture doen't have any blocking artifacts.
	Since  the standard clearly tells that no need of deblocking at slice
boundaries why the JM reference code depends on blocks from previous slice to
deblock ?
	Is there any reason to do deblocking at frame level rather than slice
level.
	Thanks & Regards,
	Gomathi Ramamoorthy| Senior Engineer | Mindtree Consulting Ltd |
Global Village , RVCE post , Mysore Road, Bangalore - 560059,India | Voice
+91 80 26264000 Extn 66521 | Fax +91 80 26264100 | Mob +91 9901074757 |
Email: gomathi_ramamoorthy mindtree.com
<mailto:gomathi_ramamoorthy mindtree.com>  | www.mindtree.com
<http://www.mindtree.com/> |  
	DISCLAIMER:
	This message (including attachment if any) is confidential and may be
privileged. If you have received this message by mistake please notify the
sender by return e-mail and delete this message from your system. Any
unauthorized use or dissemination of this message in whole or in part is
strictly prohibited.
	E-mail may contain viruses. Before opening attachments please check
them for viruses and defects. While MindTree Consulting Limited (MindTree)
has put in place checks to minimize the risks, MindTree will not be
responsible for any viruses or defects or any forwarded attachments emanating
either from within MindTree or outside.
	Please note that e-mails are susceptible to change and MindTree shall
not be liable for any improper, untimely or incomplete transmission.
	MindTree reserves the right to monitor and review the content of all
messages sent to or from MindTree e-mail address. Messages sent to or from
this e-mail address may be stored on the MindTree e-mail system or else
where.
DISCLAIMER:
This message (including attachment if any) is confidential and may be privileged. If you have received this message by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited.
E-mail may contain viruses. Before opening attachments please check them for viruses and defects. While MindTree Consulting Limited (MindTree) has put in place checks to minimize the risks, MindTree will not be responsible for any viruses or defects or any forwarded attachments emanating either from within MindTree or outside.
Please note that e-mails are susceptible to change and MindTree shall not be liable for any improper, untimely or incomplete transmission.
MindTree reserves the right to monitor and review the content of all messages sent to or from MindTree e-mail address. Messages sent to or from this e-mail address may be stored on the MindTree e-mail system or else where.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20071106/16e96647/attachment-0001.html