From Gomathi_Ramamoorthy mindtree.com Fri Nov 2 11:55:17 2007 From: Gomathi_Ramamoorthy mindtree.com (Gomathi Ramamoorthy) Date: Fri Nov 2 17:28:08 2007 Subject: [Mp4-tech] Deblocking at slice level Message-ID: <2C15D00D262B7245B1D8D1799F04D88F06E3F9EE@mtw01ex01.mindtree.com> 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 | 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20071102/aef55f2a/attachment.html From garysull windows.microsoft.com Fri Nov 2 19:11:39 2007 From: garysull windows.microsoft.com (Gary Sullivan) Date: Fri Nov 2 21:16:05 2007 Subject: [Mp4-tech] RE: Deblocking at slice level In-Reply-To: <2C15D00D262B7245B1D8D1799F04D88F06E3F9EE@mtw01ex01.mindtree.com> References: <2C15D00D262B7245B1D8D1799F04D88F06E3F9EE@mtw01ex01.mindtree.com> Message-ID: <21D067220A163E4BABC5C7A568A93B15C1638D1F92@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> 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 | 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20071102/cfd5a894/attachment.html From ziloot verat.net Sat Nov 3 08:35:50 2007 From: ziloot verat.net (laza) Date: Mon Nov 5 17:10:06 2007 Subject: [Mp4-tech] Skipping NALs in decoding process with JM 13 Message-ID: <001301c81de3$cffb8c50$0201a8c0@hal> Hello, currently I'm working on some JM13.00 testing, and I want to exploit the issue of error concealment in JM 13 decoder when some NAL units are lost. When I mark some NAL units in Anex B file stream as wrong (I do it manualy), I set header od NAL in way that forbdden bit is F=1, decoder doesnt want to decode stream and applies error Found NALU with forbidden_bit set, bit error? in config file for decoder Err Concealment(0:Off,1:Frame Copy,2:Motion Copy) is turned on. For example 1, or 2 So my question is how to make decoder to skip some NAL units (eventually recover them, and to apply error concealment), because I want to simulate network losses in decoding process. plaese help me. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20071103/59f55519/attachment.html From lcw95129 sbcglobal.net Sat Nov 3 18:39:43 2007 From: lcw95129 sbcglobal.net (LinCheng Wang) Date: Mon Nov 5 17:10:13 2007 Subject: [Mp4-tech] RE: Deblocking at slice level In-Reply-To: <21D067220A163E4BABC5C7A568A93B15C1638D1F92@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <2C15D00D262B7245B1D8D1799F04D88F06E3F9EE@mtw01ex01.mindtree.com> <21D067220A163E4BABC5C7A568A93B15C1638D1F92@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <004101c81e7b$31ef82d0$05000100@LENOVO6AED6AEB> 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 | 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20071103/a6957569/attachment.html From Gomathi_Ramamoorthy mindtree.com Tue Nov 6 09:35:41 2007 From: Gomathi_Ramamoorthy mindtree.com (Gomathi Ramamoorthy) Date: Tue Nov 6 02:16:07 2007 Subject: [Mp4-tech] RE: Deblocking at slice level In-Reply-To: <004101c81e7b$31ef82d0$05000100@LENOVO6AED6AEB> References: <2C15D00D262B7245B1D8D1799F04D88F06E3F9EE@mtw01ex01.mindtree.com> <21D067220A163E4BABC5C7A568A93B15C1638D1F92@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <004101c81e7b$31ef82d0$05000100@LENOVO6AED6AEB> Message-ID: <2C15D00D262B7245B1D8D1799F04D88F06E3F9FE@mtw01ex01.mindtree.com> 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 | 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 From Gomathi_Ramamoorthy mindtree.com Tue Nov 6 11:00:42 2007 From: Gomathi_Ramamoorthy mindtree.com (Gomathi Ramamoorthy) Date: Tue Nov 6 02:16:12 2007 Subject: [Mp4-tech] RE: Deblocking at slice level In-Reply-To: <00f301c82032$0fa4a080$1e021cac@LENOVO6AED6AEB> References: <2C15D00D262B7245B1D8D1799F04D88F06E3F9EE@mtw01ex01.mindtree.com> <21D067220A163E4BABC5C7A568A93B15C1638D1F92@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <004101c81e7b$31ef82d0$05000100@LENOVO6AED6AEB> <2C15D00D262B7245B1D8D1799F04D88F06E3F9FE@mtw01ex01.mindtree.com> <00f301c82032$0fa4a080$1e021cac@LENOVO6AED6AEB> Message-ID: <2C15D00D262B7245B1D8D1799F04D88F06E3F9FF@mtw01ex01.mindtree.com> Dear LinCheng, Thanks for your reply. So if that is the case, can we set the disable_deblocking_filter_idc as 2 for all cases so that for all cases slices are independent and can avoid unnessecary deblocking at slice boundaries. If this is correct, then output of Jm decoder with disable_deblocking_filter_idc = 2 and the output of slice level deblocking should match right ? Thanks and regards Gomathi. ________________________________ From: LinCheng Wang [mailto:lcw95129@sbcglobal.net] Sent: Tuesday, November 06, 2023 10:31 AM To: Gomathi Ramamoorthy Subject: RE: [Mp4-tech] RE: Deblocking at slice level Dear Gomathi, When disbale_deblocking_filter_idc is 2, deblocking filter process do not perform on MB edges on 2 MBs which are of different slices. In JM reference code, MbQ->mbAvailA is set to 0 if current MB Q and its left MB are not same slices. MbQ->mbAvailB is set to 0, if current MB Q and its top MB are not same slices. So filterLeftMbEdgeFlag is equal to MbQ->mbAvailA and filterTopMbEdgeFlag is equal to mbQ->mbAvailB. It is true only when disable_deblocking_filter_idc is 2. Do I answer your question? Or I misunderstand your quesiton? Regards, LinCheng ________________________________ From: Gomathi Ramamoorthy [mailto:Gomathi_Ramamoorthy@mindtree.com] Sent: Monday, November 05, 2023 8:06 PM To: LinCheng Wang; mp4-tech@lists.mpegif.org Subject: RE: [Mp4-tech] RE: Deblocking at slice level 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 | 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. 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/a4cbbe09/attachment-0001.html From alexis.tourapis dolby.com Tue Nov 6 00:24:12 2007 From: alexis.tourapis dolby.com (Tourapis, Alexis) Date: Wed Nov 7 10:10:08 2007 Subject: [Mp4-tech] RE: Deblocking at slice level In-Reply-To: <2C15D00D262B7245B1D8D1799F04D88F06E3F9FF@mtw01ex01.mindtree.com> References: <2C15D00D262B7245B1D8D1799F04D88F06E3F9EE@mtw01ex01.mindtree.com><21D067220A163E4BABC5C7A568A93B15C1638D1F92@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com><004101c81e7b$31ef82d0$05000100@LENOVO6AED6AEB><2C15D00D262B7245B1D8D1799F04D88F06E3F9FE@mtw01ex01.mindtree.com><00f301c82032$0fa4a080$1e021cac@LENOVO6AED6AEB> <2C15D00D262B7245B1D8D1799F04D88F06E3F9FF@mtw01ex01.mindtree.com> Message-ID: <2BAAC5E4AF2518459F0AB5D927942047C596AA@bur-exch-01.dolby.net> You can do this by setting LoopFilterParametersFlag to 1 and LoopFilterDisable to 2. This is clearly stated within the reference software manual which is included in the JM package. Best regards, Alexis ________________________________ From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Gomathi Ramamoorthy Sent: Monday, November 05, 2023 9:31 PM To: LinCheng Wang Cc: mp4-tech@lists.mpegif.org Subject: RE: [Mp4-tech] RE: Deblocking at slice level Dear LinCheng, Thanks for your reply. So if that is the case, can we set the disable_deblocking_filter_idc as 2 for all cases so that for all cases slices are independent and can avoid unnessecary deblocking at slice boundaries. If this is correct, then output of Jm decoder with disable_deblocking_filter_idc = 2 and the output of slice level deblocking should match right ? Thanks and regards Gomathi. ________________________________ From: LinCheng Wang [mailto:lcw95129@sbcglobal.net] Sent: Tuesday, November 06, 2023 10:31 AM To: Gomathi Ramamoorthy Subject: RE: [Mp4-tech] RE: Deblocking at slice level Dear Gomathi, When disbale_deblocking_filter_idc is 2, deblocking filter process do not perform on MB edges on 2 MBs which are of different slices. In JM reference code, MbQ->mbAvailA is set to 0 if current MB Q and its left MB are not same slices. MbQ->mbAvailB is set to 0, if current MB Q and its top MB are not same slices. So filterLeftMbEdgeFlag is equal to MbQ->mbAvailA and filterTopMbEdgeFlag is equal to mbQ->mbAvailB. It is true only when disable_deblocking_filter_idc is 2. Do I answer your question? Or I misunderstand your quesiton? Regards, LinCheng ________________________________ From: Gomathi Ramamoorthy [mailto:Gomathi_Ramamoorthy@mindtree.com] Sent: Monday, November 05, 2023 8:06 PM To: LinCheng Wang; mp4-tech@lists.mpegif.org Subject: RE: [Mp4-tech] RE: Deblocking at slice level 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 | 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. 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. ----------------------------------------- This message (including any attachments) may contain confidential information intended for a specific individual and purpose. If you are not the intended recipient, delete this message. If you are not the intended recipient, disclosing, copying, distributing, or taking any action based on this message is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20071106/c889fe86/attachment-0001.html From david_t_wu hotmail.com Tue Nov 6 22:24:50 2007 From: david_t_wu hotmail.com (David Wu) Date: Wed Nov 7 10:10:17 2007 Subject: [Mp4-tech] [H.264] Question about "Allowed collective macroblock types for slice types" Message-ID: Hi Experts, In section 7.4.5 Macroblock layer semantics, table 7-10 (h.264 03/2005), it is indictaed that, For P slice, a macrobloc type may be P (table 7-13) or I (table 7-11) For B slice, a macrobloc type may be B (table 7-14) or I (table 7-11) .................... My question is that, the mb_type code id used in 7-13 & 7-11 or 7-14 & 7-11 are ovelapped integers, so how can one tell whether a macroblock in P slice is of P or I macroblock types ? Thanks for your help. Regards David Wu david_t_wu@hotmail.com Fremont CA _________________________________________________________________ Peek-a-boo FREE Tricks & Treats for You! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us From daniele bsoft.info Wed Nov 7 16:31:04 2007 From: daniele bsoft.info (daniele renzi (bsoft)) Date: Wed Nov 7 10:52:18 2007 Subject: [Mp4-tech] [H.264] Question about "Allowed collective macroblocktypes for slice types" References: Message-ID: <001e01c82153$382b67b0$33010a0a@bsoft015> Hi David, in section 7.4.5 you can find for P and SP slices, right before table 7-13, the following sentence: "The macroblock types for P and SP slices are specified in Table 7-13 and 7-11. mb_type values 0 to 4 are specified in Table 7-13 and mb_type values 5 to 30 are specified in Table 7-11, indexed by subtracting 5 from the value of mb_type.", and for B and SB slices, right before table 7-14, the following sentence: "The macroblock types for B slices are specified in Table 7-14 and 7-11. The mb_type values 0 to 22 are specified in Table 7-14 and the mb_type values 23 to 48 are specified in Table 7-11, indexed by subtracting 23 from the value of mb_type." Hope this answer your question. Best regards, Daniele Daniele Renzi bSoft -- www.bsoft.info +39-0733-57707 (tel/fax) ----- Original Message ----- From: "David Wu" To: "mp4_h264" Sent: Tuesday, November 06, 2023 11:24 PM Subject: [Mp4-tech] [H.264] Question about "Allowed collective macroblocktypes for slice types" > > Hi Experts, > > In section 7.4.5 Macroblock layer semantics, table 7-10 (h.264 03/2005), > it is indictaed that, > > For P slice, a macrobloc type may be P (table 7-13) or I (table 7-11) > For B slice, a macrobloc type may be B (table 7-14) or I (table 7-11) > .................... > > My question is that, the mb_type code id used in 7-13 & 7-11 or 7-14 & > 7-11 are ovelapped integers, > so how can one tell whether a macroblock in P slice is of P or I > macroblock types ? > > Thanks for your help. > > Regards > > David Wu > > david_t_wu@hotmail.com > > Fremont CA > _________________________________________________________________ > Peek-a-boo FREE Tricks & Treats for You! > http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us > _______________________________________________ > 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 > > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.503 / Virus Database: 269.15.23/1114 - Release Date: 06/11/07 > 20.05 > >