From pasquale.corvasce hotmail.it Wed Nov 1 11:53:58 2006 From: pasquale.corvasce hotmail.it (Pasquale Corvasce) Date: Wed Nov 1 13:40:07 2006 Subject: [Mp4-tech] MoMuSys and video streaming Message-ID: Hello I'm working with the FGS_Ref_Software - MoMuSys-FPDAM1-FPDAM4-001231. I'll ask you to help me about the streaming of a video. Starting from a single .yuv video file, I produced two file with the encoder, the first containing the base layer (with .bits extension) and the second containing the enhancement layer ( with .bits_enh extension) and using Temporal scalability . I'll ask you about the existance of any kind of open source streaming solution that let me download these two file simultaneously and, at the same time, let me watch the video. If anyone has any suggestions or if anyone has any expirience, I'd be very grateful, Thanks, Pasquale Corvasce pasquale.corvasce@hotmail.it _________________________________________________________________ Chiama gratis con Windows Live Messenger http://imagine-msn.com/messenger/launch80/?locale=it-it&TAB=2 From garima.singh tivr.co.in Wed Nov 1 05:07:45 2006 From: garima.singh tivr.co.in (Garima Singh) Date: Wed Nov 1 13:40:15 2006 Subject: [Mp4-tech] RTP Dump files In-Reply-To: Message-ID: <20061101130745.53022.qmail@web214.biz.mail.re2.yahoo.com> Hi All, Could anyone please tell me from where can I get the RTP dump files for H.264, MPEG-4 and H.263 (according to respective RFCs) ? Is there any way i can create these files with any tool ? Thanks and Regards, Garima Regards, Garima Singh TIVR Communications - Delivering Efficient Solutions for Mobile Multimedia www.tivr.co.in -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061101/f82dac76/attachment.html From anil-list icinema.com Wed Nov 1 22:01:29 2006 From: anil-list icinema.com (Anil Gupte) Date: Wed Nov 1 19:10:07 2006 Subject: [Mp4-tech] Learning more about MPEG References: <024701c6f538$87fce770$6400a8c0@Aum> <20061023074001.GA3488@lambdastream.com> Message-ID: <017901c6fdd3$31a5bcf0$640fa8c0@Aum> Sorry, I have been away. I know there are many versions of MPEG, but are there any resources for writing code to read these files and begin to parse them. Perhaps the code can figure out what versions and how to handle each (or not handle them as the case may be). In fact, I will most likely be dealing only with MPEG-2 video files and later with MPEG-2 DVB-S transmissions. Any pointers on where to start? Are there any libraries? Tutorials etc? Thanx, Anil Gupte www.keeninc.net www.icinema.com ----- Original Message ----- From: "Samuel Rivas" To: Sent: Monday, October 23, 2023 1:10 PM Subject: Re: [Mp4-tech] Learning more about MPEG > Anil Gupte wrote: >> Can anyone point me to some resources about reading and writing MPEG files > > MPEG file is a way generic concept. They might be MPEG-1 system files, MPEG-2 > program or transport streams, MPEG-2 PES, MP4 files, elementary streams, > ... > > -- > Samuel > _______________________________________________ > 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 > From singer apple.com Wed Nov 1 11:26:52 2006 From: singer apple.com (Dave Singer) Date: Wed Nov 1 19:34:11 2006 Subject: [Mp4-tech] Re: RTP Dump files In-Reply-To: <20061101130745.53022.qmail@web214.biz.mail.re2.yahoo.com> References: <20061101130745.53022.qmail@web214.biz.mail.re2.yahoo.com> Message-ID: At 5:07 -0800 1/11/06, Garima Singh wrote: >Hi All, > >Could anyone please tell me from where can I get the RTP dump files >for H.264, MPEG-4 and H.263 (according to respective RFCs) ? Is >there any way i can create these files with any tool ? You imply that there is a standard set of RTP dump files, and I am not aware of one. Google 'rtpdump' and you'll find the software at > > >Thanks and Regards, >Garima > > >Regards, >Garima Singh > >TIVR Communications - Delivering Efficient Solutions for Mobile Multimedia >www.tivr.co.in -- David Singer Apple Computer/QuickTime -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061101/8afa603c/attachment.html From tsviatko playbox.tv Thu Nov 2 09:49:28 2006 From: tsviatko playbox.tv (Tsviatko Jongov) Date: Thu Nov 2 15:34:10 2006 Subject: [Mp4-tech] Re: H264 Quicktime Message-ID: <4549A308.20206@playbox.tv> Dear Mr Johns, I've developed a tool that can help you investigate your quicktime based containers (mov, mp4...). You can download it free from http://tsviatko.jongov.com - "Projects" - "QuickTime Atom Viewer". I hope it will help you understand the QuickTime container. Regards, Tsviatko Jongov http://tsviatko.jongov.com From samuel lambdastream.com Thu Nov 2 09:03:29 2006 From: samuel lambdastream.com (Samuel Rivas) Date: Thu Nov 2 15:34:15 2006 Subject: [Mp4-tech] Learning more about MPEG In-Reply-To: <017901c6fdd3$31a5bcf0$640fa8c0@Aum> References: <024701c6f538$87fce770$6400a8c0@Aum> <20061023074001.GA3488@lambdastream.com> <017901c6fdd3$31a5bcf0$640fa8c0@Aum> Message-ID: <20061102080329.GA20441@lambdastream.com> Anil Gupte wrote: > Sorry, I have been away. I know there are many versions of MPEG, but are > there any resources for writing code to read these files and begin to parse > them. Perhaps the code can figure out what versions and how to handle each > (or not handle them as the case may be). In fact, I will most likely be > dealing only with MPEG-2 video files and later with MPEG-2 DVB-S > transmissions. Any pointers on where to start? Are there any libraries? > Tutorials etc? You can start here: http://www.mpeg.org/MPEG/starting-points.html#faqs Regards -- Samuel From jerry.johns nuvation.com Thu Nov 2 08:47:32 2006 From: jerry.johns nuvation.com (Jerry Johns) Date: Thu Nov 2 17:28:09 2006 Subject: [Mp4-tech] Re: H264 Quicktime Message-ID: <22F8D1FFED33654987DE9D447F74E5460DA8@mailguy2.nuvation.com> Hey Tsviatko, I cant seem to download your QTAtomViewer.zip; seems its corrupted and i've tried a few times; is it possible for you to email it to me? I'd appreciate it a lot :-) Thanks! You can email it to me at jerry.johns@gmail.com Thank you once again Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061102/53bb13ae/attachment.html From jerry.johns nuvation.com Thu Nov 2 09:37:31 2006 From: jerry.johns nuvation.com (Jerry Johns) Date: Thu Nov 2 18:46:09 2006 Subject: [Mp4-tech] Re: H264 Quicktime Message-ID: <22F8D1FFED33654987DE9D447F74E5460DD6@mailguy2.nuvation.com> Hey Tsviatko, Yup I tried your link on your site, but I cant download it as I mentioned in my previous email - could you email it to me if its not too big of a hassle? It'd be much appreciated Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061102/efbc4e2a/attachment.html From pasquale.corvasce hotmail.it Fri Nov 3 10:15:05 2006 From: pasquale.corvasce hotmail.it (Pasquale Corvasce) Date: Fri Nov 3 10:16:07 2006 Subject: [Mp4-tech] MoMuSys FGS Ref Software Message-ID: Hi, I'm working with the FGS_Ref_Software - MoMuSys-FPDAM1-FPDAM4-001231. I'll ask you to help me about the streaming of a video. Starting from a single .yuv video file, I produced two file with the encoder, the first containing the base layer (with .bits extension) and the second containing the enhancement layer (with .bits_enh extension) and using Temporal scalability. I'll ask you about the existance of any kind of open source streaming solution that let me download these two file simultaneously and, at the same time, let me watch the video. If anyone has any suggestions or if anyone has any expirience, I'd be very grateful Thanks Pasquale Corvasce pasquale.corvasce@hotmail.it _________________________________________________________________ I campionati di calcio sono iniziati.Sei pronto alla sfida? http://www.msn.it/messengerleague/home/ From lakshminarayanan.83 gmail.com Sat Nov 4 17:07:28 2006 From: lakshminarayanan.83 gmail.com (lakshminarayanan) Date: Sat Nov 4 21:40:07 2006 Subject: [Mp4-tech] The number of streams encoded Message-ID: <5d4b07070611040337n1fb75c32od92ba740d7bc6072@mail.gmail.com> Dear experts, 1. If I encode 25 frames using the "H.264" encoder how many frames will i be getting as output from the encoder.Will it be less than the 25 frames. 2. For h.264 encoder we are giving ".yuv" file as input in real time should i use RGB to YUV convertor for encoding the input stream.for e.g.when i catch a picture using digital camera will it be having a convertor inbuilt into it. -- LAKSHMINARAYANAN -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061104/e2cce325/attachment.html From ilyes.gouta gmail.com Sun Nov 5 19:23:17 2006 From: ilyes.gouta gmail.com (Ilyes Gouta) Date: Mon Nov 6 00:22:07 2006 Subject: [Mp4-tech] MoMuSys FGS Ref Software Message-ID: <454E2C15.4070405@gmail.com> Hi, I'm working on the ref implementation for the MPEG-4 part-2 (ASP) profile, that's ISO_IEC_14496_5_2001_Amd_1_2002_Reference_Software. I'm using MoMuSys's implementation, not Microsoft's. I successfully imported/compiled the source code under Win32 using MSVC. I'm looking now for some raw input content (YUV files) to feed the encoder. Does anybody have any URLs for some CIF, SIF sized content (no HD stuff please!) which is compliant to the MoMuSys's ref code? Best regards, Ilyes Gouta. From Alan.Yan fmc.fujitsu.com Mon Nov 6 11:17:03 2006 From: Alan.Yan fmc.fujitsu.com (Alan Yan - SH) Date: Mon Nov 6 14:16:11 2006 Subject: [Mp4-tech] Limitation of Max Bin Number For One MB Message-ID: <6D7740EE76790E44A1775CE82BA2DB8E579A4B@fmcshmsex01> Dear Experts, I have a question regarding the restriction of max bin number when CABAC is used. I can see from the spec, there is a limitation on the max bin number in a NALU, but I'd like to find out if there is also a limitation for one MB. I searched in the spec and did not find it (there are limitations for number of times read_bits( 1 ) is called, but it is not limitations for number of times DecodeBin() is called). Maybe the two have some relationship which imposed an implied limitation on the number of times DecodeBin() is called for one MB? I have a feeling that if there is no such limitation on the max bin number for one MB, the time for decoding a MB will be hard to estimate and this have a bad influence on the real-time pipeline decoding architecture. In this way, a decoded-buffer of NALU for CABAC decoding will be needed to balance the influence. Thanks in advance for your help. Best Regards, alan -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061106/41339ee0/attachment.html From senthilr_pava rediffmail.com Mon Nov 6 05:29:25 2006 From: senthilr_pava rediffmail.com (senthil k) Date: Mon Nov 6 14:16:16 2006 Subject: [Mp4-tech] [MP4_tech][audio]MPEG4 HE-AAC test Procedure Message-ID: <20061106052600.31793.qmail@webmail29.rediffmail.com> ? Hi, I am looking to get the conformance test procedure for MPEG4 HE-AAC. I am not able to get it from anywhere. I have got the conformance test sequences from the fraunhofer website, But i did not get the document which describes the test procedure. Is there any standard i need to buy from the ISO? If at all can you please send me the name of ISO standard and URL for that page. It will be lot more helpful to me. Thanks, Senthil. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061106/9006bbdc/attachment.html From anirudh_radhak yahoo.co.in Mon Nov 6 07:06:47 2006 From: anirudh_radhak yahoo.co.in (anirudh radhakrishnan) Date: Mon Nov 6 14:16:20 2006 Subject: [Mp4-tech] info on test streams to test specific modules of H264 decoder Message-ID: <20061106070647.56065.qmail@web7906.mail.in.yahoo.com> Hi all, I have a H264 decoder for which I want to test the performance. I have 'foreman' and 'soccer' (few children playing soccer) test streams encoded at different bit rate and frame rate. I wanted to know, whether there are any test streams which i can use to test performance of specific modules of the decoder. I mean are there test streams which can test the performace of motion compensation, or idct or deblocking? Thanks and regards Ani --------------------------------- Find out what India is talking about on - Yahoo! Answers India Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061106/8f09f2ac/attachment.html From girishht bluebottle.com Mon Nov 6 00:39:37 2006 From: girishht bluebottle.com (Girish) Date: Mon Nov 6 14:16:24 2006 Subject: [Mp4-tech] MoMuSys FGS Ref Software In-Reply-To: <454E2C15.4070405@gmail.com> References: <454E2C15.4070405@gmail.com> Message-ID: <200611060839.kA68dhda014698@mi0.bluebottle.com> Hi Ilyes Gouta, You can find RAW YUV sequences at this site. The sequences are all in the common YUV 4:2:0 format, widely used in the video research community. All files are compressed in the ZIP format and come with an overview for all YUVs currently available from our site. http://trace.eas.asu.edu/yuv/cif.html Regards Girish Quoting Ilyes Gouta : > Hi, > > I'm working on the ref implementation for the MPEG-4 part-2 (ASP) > profile, that's > ISO_IEC_14496_5_2001_Amd_1_2002_Reference_Software. I'm using > MoMuSys's implementation, > not Microsoft's. I successfully imported/compiled the source code > under Win32 using MSVC. > I'm looking now for some raw input content (YUV files) to feed the > encoder. > > Does anybody have any URLs for some CIF, SIF sized content (no HD > stuff please!) which is > compliant to the MoMuSys's ref code? > > Best regards, > Ilyes Gouta. > _______________________________________________ > 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 > -------------------------------------------------------------------------- From Andreas.Schneider codingtechnologies.com Mon Nov 6 18:14:05 2006 From: Andreas.Schneider codingtechnologies.com (Andreas Schneider) Date: Mon Nov 6 17:22:11 2006 Subject: [Mp4-tech] [MP4_tech][audio]MPEG4 HE-AAC test Procedure In-Reply-To: <20061106052600.31793.qmail@webmail29.rediffmail.com> Message-ID: Hello Senthil, The document that describes the SBR conformance test procedure is ISO/IEC 14496-4:2004/AMD8:2005. The MPEG-4 Audio reference software contains the reference implementation of this procedure. The corresponding standard as of today is ISO/IEC 14496-5:2001/Amd.6:2005. Although I think a new release of the entire reference sotware is just around the corner. The links to the ISO store for both of these standards can be found here: http://www.itscj.ipsj.or.jp/sc29/29w42911.htm#MPEG-4 Best, Andreas mp4-tech-bounces@lists.mpegif.org wrote on 06.11.2023 06:26:00: > > Hi, > I am looking to get the conformance test procedure for MPEG4 HE- > AAC. I am not able to get it from anywhere. > I have got the conformance test sequences from the fraunhofer > website, But i did not get the document which describes the > test procedure. > > Is there any standard i need to buy from the ISO? > > If at all can you please send me the name of ISO standard and URL > for that page. It will be lot more helpful to me. > > Thanks, > Senthil. > > > [image removed] _______________________________________________ > 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 -- Andreas Schneider Senior Research Engineer mailto:snd@CodingTechnologies.com +49 911 92891 -26 (phone) +49 911 92891 -99 (fax) Coding Technologies GmbH Deutschherrnstr. 15-19 D-90429 Nuernberg, Germany http://www.codingtechnologies.com From garysull windows.microsoft.com Mon Nov 6 11:37:29 2006 From: garysull windows.microsoft.com (Gary Sullivan) Date: Mon Nov 6 19:46:07 2006 Subject: [Mp4-tech] Limitation of Max Bin Number For One MB In-Reply-To: <6D7740EE76790E44A1775CE82BA2DB8E579A4B@fmcshmsex01> Message-ID: <03CB47D9C3F8074498E4653F814D6E8F02C212D2@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> There is a restriction on the total number of bits of data for one MB (e.g., see item "n" of subclause A.3.1), but I believe there is no direct limit on bin count per macroblock (except in aggregate as a per-picture limit). Regarding the time for decoding on MB - It may be advisable to structure a decoder such that the entropy decoding process of a slice is operated on a separate thread or as a first stage prior to the operation of the remainder of the decoding processes for the macroblocks in the slice, rather than trying to operate entropy decoding and other steps sequentially on a per-macroblock basis. Best Regards, Gary Sullivan ________________________________ From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Alan Yan - SH Sent: Sunday, November 05, 2023 7:17 PM To: mp4-tech@lists.mpegif.org Subject: [Mp4-tech] Limitation of Max Bin Number For One MB Dear Experts, I have a question regarding the restriction of max bin number when CABAC is used. I can see from the spec, there is a limitation on the max bin number in a NALU, but I'd like to find out if there is also a limitation for one MB. I searched in the spec and did not find it (there are limitations for number of times read_bits( 1 ) is called, but it is not limitations for number of times DecodeBin() is called). Maybe the two have some relationship which imposed an implied limitation on the number of times DecodeBin() is called for one MB? I have a feeling that if there is no such limitation on the max bin number for one MB, the time for decoding a MB will be hard to estimate and this have a bad influence on the real-time pipeline decoding architecture. In this way, a decoded-buffer of NALU for CABAC decoding will be needed to balance the influence. Thanks in advance for your help. Best Regards, alan -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061106/e2122b29/attachment.html From sundar.aparna gmail.com Tue Nov 7 10:25:57 2006 From: sundar.aparna gmail.com (Aparna Sundar) Date: Tue Nov 7 06:10:08 2006 Subject: [Mp4-tech] Blockiness in Macroblocks Message-ID: Hi all, Iam working on a H.263 decoder implementation.I have a strange problem....particular macroblocks in the decoded frame get discoloured...i get violet and red blocks in the image actually...as the decoding goes on,this influences the subsequent P frames and finally when the decoding ends 1 frame is always missed out...Though this is happening for a H.263decoder, I want to know if any particular component could cause this kind of error...any idea's anyone on hw i can go about solving this?I have tried checking the parsing process by comparing intermediate values with those from a reference implementation but to no avail... Thanks in advance, Aparna -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061107/d4a470c9/attachment.html From rawekumar gmail.com Tue Nov 7 11:10:11 2006 From: rawekumar gmail.com (Kannan Ravikumar) Date: Tue Nov 7 06:10:12 2006 Subject: [Mp4-tech] H264 & AAC Message-ID: Hi All, I need test streams for AAC & H.264. Where can I get it. What are all the factors need to be tested in it other than normal DVB / ATSC streams. Do send me some test streams if anybody have it. cheers, Ravikumar -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061107/73685a48/attachment.html From ilyes.gouta gmail.com Tue Nov 7 11:17:31 2006 From: ilyes.gouta gmail.com (Ilyes Gouta) Date: Tue Nov 7 14:10:07 2006 Subject: [Mp4-tech] YUV source files format Message-ID: <45505D3B.70808@gmail.com> Hi all, I downloaded some raw YUV files that I will use to feed the MoMuSys ref encoder. I would like to know what's the format of these files. How the Y, U/V information is coded in those raw files? Is it planar 4:2:0? Can somebody describe to me how physically the information is laid on those files? Thanks! Best regards, Ilyes Gouta. From sundarhills hotmail.com Tue Nov 7 11:46:31 2006 From: sundarhills hotmail.com (A R) Date: Tue Nov 7 14:10:14 2006 Subject: [Mp4-tech] About calculation of SAD in JM10.2 Message-ID: Hi dear researchers ! I am working on H.264's reference model JM10.2 . In this reference code I want to change the SAD with my own method. As a big picture I know that, in SAD, two image values(as parameters) are required in calculating SAD between them. The problems I am facing right now are: 1- I could not find/identify these two parameters in this reference code. 2- I could not find/Identify the methods or functions in the code which are dedicated to calculate the SAD.Note: I found three functions/Methods namely SATD() , SATD8X8() and find_SAT() but they do not answer any of the questions above. I'll really be grateful if someone can help in this regard. Thanks. Kind Regards, Amir Raza. (LUMS, Lahore, Pakistan) _________________________________________________________________ Personalize your Live.com homepage with the news, weather, and photos you care about. Try it. http://www.live.com/getstarted.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061107/353a3abc/attachment.html From ilyes.gouta gmail.com Tue Nov 7 15:59:00 2006 From: ilyes.gouta gmail.com (Ilyes Gouta) Date: Tue Nov 7 17:16:06 2006 Subject: [Mp4-tech] MoMuSys MPEG-4 part2 encoder Message-ID: <45509F34.2030108@gmail.com> Hi all, I would like to ask about the alpha layer found in the raw YUV files. Why does the MoMuSys encoder takes such an additional input from the YUV files? How this additional data is stored within the input files? What happens if I fake the encoder to read a completely zeroed alpha channel? Best regards, Ilyes Gouta. From nikhil_parvatikar yahoo.com Tue Nov 7 09:01:18 2006 From: nikhil_parvatikar yahoo.com (nikhil parvatikar) Date: Tue Nov 7 17:16:12 2006 Subject: [Mp4-tech] YUV source files format In-Reply-To: <45505D3B.70808@gmail.com> Message-ID: <20061107170119.18266.qmail@web35009.mail.mud.yahoo.com> Hi Ilyes, Yes its usually the planar storage. The "Y" data is followed by the "U" and then the "V" (in case of 4:2:0). For Ex, if the YUV is CIF (352x288), then for every frame, the first 352x288 (101376 bytes) of Y data are followed by "U" and then "V". Note the U and V data size per frame for a CIF will be 25344 (176x144) Hope this info helps ! Regards, Nikhil --- Ilyes Gouta wrote: > Hi all, > > I downloaded some raw YUV files that I will use to > feed the MoMuSys ref encoder. I would > like to know what's the format of these files. How > the Y, U/V information is coded in > those raw files? Is it planar 4:2:0? Can somebody > describe to me how physically the > information is laid on those files? > > Thanks! > > Best regards, > Ilyes Gouta. > _______________________________________________ > 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 > ____________________________________________________________________________________ Sponsored Link Try Netflix today! With plans starting at only $5.99 a month what are you waiting for? http://www.netflix.com/Signup?mqso=80010030 From andrewk vbrick.com Tue Nov 7 12:07:34 2006 From: andrewk vbrick.com (Andrew Krupiczka) Date: Tue Nov 7 18:52:07 2006 Subject: [Mp4-tech] About calculation of SAD in JM10.2 In-Reply-To: Message-ID: <56B63B22AC99FB469170277B7B5E059C14B49E@VBMAIL.vb.loc> Amir, I feel like you might have some misconceptions here. Typically, you want to know SAD on block basis i.e. you compute pixels difference (byte_abs[ *orig_line++ - *ref_line++ ];) from two different frames for multiple pixels e.g. rectangular block of pixels. In JM software, you should be able to find a multiple for(;;) loops iterating through multiple pixels positions in two different frames (pointed to as in the example below by ref_line and orig_line pointers). SAD values as in the example below are cumulated on top of initial motion cost mcost value if you want to get a better trade-off between a target bitrate and video quality, but you may want to have a separate routine for computation of SAD (and eventually modifying) like in the SATD(); for (y=0; y -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061107/aa2488b6/attachment.html From Alexis.Tourapis dolby.net Tue Nov 7 16:42:50 2006 From: Alexis.Tourapis dolby.net (Tourapis, Alexis) Date: Wed Nov 8 00:52:07 2006 Subject: [Mp4-tech] About calculation of SAD in JM10.2 Message-ID: <7272EE229DA1AA48B47EBDC47EB0C68B02518BDA@sapphire.dolby.net> In the updated (not yet released) reference software we have completely rehashed the motion estimation process. The code makes it way simpler to add your own distortion model (currently it supports SAD, MSE, and SATD for all possible refinements). Chroma can also be optionally used for distortion computation as well. You may be able to contact Karsten Suehring if you would like to get a hold of the software before its release. Best regards, Alexis _____ From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Andrew Krupiczka Sent: Tuesday, November 07, 2023 9:08 AM To: A R; mp4-tech@lists.mpegif.org Subject: RE: [Mp4-tech] About calculation of SAD in JM10.2 Amir, I feel like you might have some misconceptions here. Typically, you want to know SAD on block basis i.e. you compute pixels difference (byte_abs[ *orig_line++ - *ref_line++ ];) from two different frames for multiple pixels e.g. rectangular block of pixels. In JM software, you should be able to find a multiple for(;;) loops iterating through multiple pixels positions in two different frames (pointed to as in the example below by ref_line and orig_line pointers). SAD values as in the example below are cumulated on top of initial motion cost mcost value if you want to get a better trade-off between a target bitrate and video quality, but you may want to have a separate routine for computation of SAD (and eventually modifying) like in the SATD(); for (y=0; y ----------------------------------------- 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/20061107/65a818d8/attachment-0001.html From Alan.Yan fmc.fujitsu.com Wed Nov 8 15:28:15 2006 From: Alan.Yan fmc.fujitsu.com (Alan Yan - SH) Date: Wed Nov 8 15:16:07 2006 Subject: [Mp4-tech] Question on the mb_field_decoding_flag Message-ID: <6D7740EE76790E44A1775CE82BA2DB8E579CF0@fmcshmsex01> Dear Experts, When MbaffFrameFlag==1, there is one syntax "mb_field_decoding_flag" in MB layer for each MB pair. In case of entropy_coding_mode_flag==0, when the first MB (top MB) in the MB pair is skipped, mb_field_decoding_flag (MBFDF) is also skipped for the top MB. For following decoding process like B_DIRECT_16X16(for B_SLICE) and Boundary Strength calculation, MBFDF is necessary. And according to the spec 7.4.4, the derivation of MBFDF is performed after we know both MB of an MB pair are skipped. Does it mean that if the top MB is skipped, the spec do not have any default or temporary value defined for MBFDF and so we can not start following decoding process like B_DIRECT_16X16 and BS calculation for this top MB? We must wait till the bottom MB is parsed and the final MBFDF is decoded or derived? And when entropy_coding_mode_flag==1, I see the derivation process is always performed before decoding any syntax element, is this statement correct? And it is possible that the before-anything-derived value for MBFDF can be different from the value parsed later from the bit-stream, is it correct? In this situation and if mb_skip_flag is 1 for the top MB, can we use this temporarily derived MBFDF to start following decoding process like B_DIRECT_16X16 and BS calculation for this top-skipped MB or should we wait and use the final MBFDF? Thanks for your kindly help! (To Mr. Gary Sullivan: Thank you!) Best Regards, alan -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061108/31046121/attachment.html From Stephane.Pechard univ-nantes.fr Wed Nov 8 10:08:54 2006 From: Stephane.Pechard univ-nantes.fr (=?iso-8859-1?Q?St=E9phane_PECHARD?=) Date: Wed Nov 8 15:16:13 2006 Subject: [SPAM] Re: [Mp4-tech] YUV source files format In-Reply-To: <20061107170119.18266.qmail@web35009.mail.mud.yahoo.com> References: <45505D3B.70808@gmail.com> <20061107170119.18266.qmail@web35009.mail.mud.yahoo.com> Message-ID: <3697.172.20.0.4.1162976934.squirrel@webmail.univ-nantes.fr> there are several YUV formats existing, planar is only one of them (maybe the most popular indeed) some information are available here : http://www.fourcc.org/ Regards Le DATE, vous avez ?crit : nikhil parvatikar > Hi Ilyes, > Yes its usually the planar storage. The "Y" data is > followed by the "U" and then the "V" (in case of > 4:2:0). > > For Ex, if the YUV is CIF (352x288), then for every > frame, the first 352x288 (101376 bytes) of Y data are > followed by "U" and then "V". Note the U and V data > size per frame for a CIF will be 25344 (176x144) > > Hope this info helps ! > Regards, > Nikhil > > --- Ilyes Gouta wrote: > >> Hi all, >> >> I downloaded some raw YUV files that I will use to >> feed the MoMuSys ref encoder. I would >> like to know what's the format of these files. How >> the Y, U/V information is coded in >> those raw files? Is it planar 4:2:0? Can somebody >> describe to me how physically the >> information is laid on those files? >> >> Thanks! >> >> Best regards, >> Ilyes Gouta. >> _______________________________________________ >> 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 >> > > > > > > ____________________________________________________________________________________ > Sponsored Link > > Try Netflix today! With plans starting at only $5.99 a month what are you > waiting for? > http://www.netflix.com/Signup?mqso=80010030 > _______________________________________________ > 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 > -- ~ st?phane p?chard ~ phd student | irccyn-ivc | france ~ http://www.irccyn.ec-nantes.fr/~pechard ~~~~~~ pgp : hkp://subkeys.pgp.net ~~~~~~ From garysull windows.microsoft.com Wed Nov 8 10:47:52 2006 From: garysull windows.microsoft.com (Gary Sullivan) Date: Wed Nov 8 19:04:07 2006 Subject: [Mp4-tech] Question on the mb_field_decoding_flag References: <6D7740EE76790E44A1775CE82BA2DB8E579CF0@fmcshmsex01> Message-ID: <03CB47D9C3F8074498E4653F814D6E8F9771B3@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> Alan Yan et al, In either case for which the first macroblock of a macroblock pair is skipped and the second one is not, I think you should wait until mb_field_decoding_flag is determined from the syntax associated with the second macroblock before attempting to perform the decoding process for the first macroblock. The field/frame decoding mode is a macroblock pair attribute -- it must be the same for both macroblocks. I have not double-checked the text to see exactly how this intent is expressed (and to determine whether it is expressed well), but I am pretty confident that this is the intent. It may also be helpful to consult the reference software, but I doubt that is necessary in this instance. I'll try to remember to check how well the text is written on this issue later. If you have further pointers to specific places in the text where you think you see incorrect or vague aspects, please let me/us know. Best Regards, Gary Sullivan ________________________________ From: mp4-tech-bounces@lists.mpegif.org on behalf of Alan Yan - SH Sent: Tue 11/7/2023 11:28 PM To: mp4-tech@lists.mpegif.org Subject: [Mp4-tech] Question on the mb_field_decoding_flag Dear Experts, When MbaffFrameFlag==1, there is one syntax "mb_field_decoding_flag" in MB layer for each MB pair. In case of entropy_coding_mode_flag==0, when the first MB (top MB) in the MB pair is skipped, mb_field_decoding_flag (MBFDF) is also skipped for the top MB. For following decoding process like B_DIRECT_16X16(for B_SLICE) and Boundary Strength calculation, MBFDF is necessary. And according to the spec 7.4.4, the derivation of MBFDF is performed after we know both MB of an MB pair are skipped. Does it mean that if the top MB is skipped, the spec do not have any default or temporary value defined for MBFDF and so we can not start following decoding process like B_DIRECT_16X16 and BS calculation for this top MB? We must wait till the bottom MB is parsed and the final MBFDF is decoded or derived? And when entropy_coding_mode_flag==1, I see the derivation process is always performed before decoding any syntax element, is this statement correct? And it is possible that the before-anything-derived value for MBFDF can be different from the value parsed later from the bit-stream, is it correct? In this situation and if mb_skip_flag is 1 for the top MB, can we use this temporarily derived MBFDF to start following decoding process like B_DIRECT_16X16 and BS calculation for this top-skipped MB or should we wait and use the final MBFDF? Thanks for your kindly help! (To Mr. Gary Sullivan: Thank you!) Best Regards, alan -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061108/95b92bab/attachment.html From garysull windows.microsoft.com Wed Nov 8 14:02:38 2006 From: garysull windows.microsoft.com (Gary Sullivan) Date: Wed Nov 8 22:10:08 2006 Subject: [Mp4-tech] Question on the mb_field_decoding_flag References: <006401c7037f$234bd250$aa0ba8c0@DZUNGLAPTOP> Message-ID: <03CB47D9C3F8074498E4653F814D6E8F9771B5@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> "not present for either macroblock" = "not present for the top macroblock and not present for the bottom macroblock" If that is not the way everyone understands the statement to mean, perhaps we need to clarify eventually. But to me that is clear. Best Regards, Gary Sullivan ________________________________ From: Dzung Hoang [mailto:dthoang@yahoo.com] Sent: Wed 11/8/2023 1:44 PM To: Gary Sullivan; 'Alan Yan - SH'; mp4-tech@lists.mpegif.org Subject: RE: [Mp4-tech] Question on the mb_field_decoding_flag Gary et al, Section 7.4.4 specifies the process for inferring mb_field_decoding_flag when it is not present for either MB of a MB pair. I have a concern about the text of this section. When mb_field_decoding_flag is not present for either macroblock of a macroblock pair, the value of mb_field_decoding_flag is derived as follows. - If there is a neighbouring macroblock pair immediately to the left of the current macroblock pair in the same slice, the value of mb_field_decoding_flag shall be inferred to be equal to the value of mb_field_decoding_flag for the neighbouring macroblock pair immediately to the left of the current macroblock pair, - Otherwise, if there is no neighbouring macroblock pair immediately to the left of the current macroblock pair in the same slice and there is a neighbouring macroblock pair immediately above the current macroblock pair in the same slice, the value of mb_field_decoding_flag shall be inferred to be equal to the value of mb_field_decoding_flag for the neighbouring macroblock pair immediately above the current macroblock pair, - Otherwise (there is no neighbouring macroblock pair either immediately to the left or immediately above the current macroblock pair in the same slice), the value of mb_field_decoding_flag shall be inferred to be equal to 0. What happens if the top MB is skipped and the bottom MB is present? The syntax table 7.3.4 contains this. if( MbaffFrameFlag && ( CurrMbAddr % 2 = = 0 | | ( CurrMbAddr % 2 = = 1 && prevMbSkipped ) ) ) mb_field_decoding_flag There is a potential conflict. The text of 7.4.4 says to infer the mb_field_decoding_flag because it is not present for the skipped top MB. However, the syntax table says to take the mb_field_decoding_flag from the bitstream. Does this mean that the value for mb_field_decoding_flag must be equal to the inferred value? If so, then is a waste of bits. Regards, - Dzung Hoang ________________________________ From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Gary Sullivan Sent: Wednesday, November 08, 2023 10:48 AM To: Alan Yan - SH; mp4-tech@lists.mpegif.org Subject: RE: [Mp4-tech] Question on the mb_field_decoding_flag Alan Yan et al, In either case for which the first macroblock of a macroblock pair is skipped and the second one is not, I think you should wait until mb_field_decoding_flag is determined from the syntax associated with the second macroblock before attempting to perform the decoding process for the first macroblock. The field/frame decoding mode is a macroblock pair attribute -- it must be the same for both macroblocks. I have not double-checked the text to see exactly how this intent is expressed (and to determine whether it is expressed well), but I am pretty confident that this is the intent. It may also be helpful to consult the reference software, but I doubt that is necessary in this instance. I'll try to remember to check how well the text is written on this issue later. If you have further pointers to specific places in the text where you think you see incorrect or vague aspects, please let me/us know. Best Regards, Gary Sullivan ________________________________ From: mp4-tech-bounces@lists.mpegif.org on behalf of Alan Yan - SH Sent: Tue 11/7/2023 11:28 PM To: mp4-tech@lists.mpegif.org Subject: [Mp4-tech] Question on the mb_field_decoding_flag Dear Experts, When MbaffFrameFlag==1, there is one syntax "mb_field_decoding_flag" in MB layer for each MB pair. In case of entropy_coding_mode_flag==0, when the first MB (top MB) in the MB pair is skipped, mb_field_decoding_flag (MBFDF) is also skipped for the top MB. For following decoding process like B_DIRECT_16X16(for B_SLICE) and Boundary Strength calculation, MBFDF is necessary. And according to the spec 7.4.4, the derivation of MBFDF is performed after we know both MB of an MB pair are skipped. Does it mean that if the top MB is skipped, the spec do not have any default or temporary value defined for MBFDF and so we can not start following decoding process like B_DIRECT_16X16 and BS calculation for this top MB? We must wait till the bottom MB is parsed and the final MBFDF is decoded or derived? And when entropy_coding_mode_flag==1, I see the derivation process is always performed before decoding any syntax element, is this statement correct? And it is possible that the before-anything-derived value for MBFDF can be different from the value parsed later from the bit-stream, is it correct? In this situation and if mb_skip_flag is 1 for the top MB, can we use this temporarily derived MBFDF to start following decoding process like B_DIRECT_16X16 and BS calculation for this top-skipped MB or should we wait and use the final MBFDF? Thanks for your kindly help! (To Mr. Gary Sullivan: Thank you!) Best Regards, alan -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061108/c52e7a30/attachment-0001.html From garysull windows.microsoft.com Wed Nov 8 14:53:17 2006 From: garysull windows.microsoft.com (Gary Sullivan) Date: Wed Nov 8 23:04:07 2006 Subject: [Mp4-tech] Question on the mb_field_decoding_flag References: <006d01c70385$cc01eb40$aa0ba8c0@DZUNGLAPTOP> Message-ID: <03CB47D9C3F8074498E4653F814D6E8F9771B6@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> On the other hand, "not present for both" could easily be interpreted using the interpretation that the sub-string "present for both" = "present for A and present for B", and therefore "not present for both" = "not ((present for A) and (present for B))" = "(not present for A) OR (not present for B)". Whatever the solution, I think you have convinced me that some clarification would be a good idea. Best Regards, Gary Sullivan ________________________________ From: Dzung Hoang [mailto:dthoang@yahoo.com] Sent: Wed 11/8/2023 2:32 PM To: Gary Sullivan; 'Alan Yan - SH'; mp4-tech@lists.mpegif.org Subject: RE: [Mp4-tech] Question on the mb_field_decoding_flag Gary, When I read "either" I immediately think "or" not "and." I think the phrase "not present for both macroblocks" more clearly states the intent. The dictionary does not help either. -adjective 1. one or the other of two: You may sit at either end of the table. 2. each of two; the one and the other: There are trees on either side of the river. Using "both" should eliminate any ambiguity. Regards, - Dzung Hoang -----Original Message----- From: Gary Sullivan [mailto:garysull@windows.microsoft.com] Sent: Wednesday, November 08, 2023 2:03 PM To: dthoang@yahoo.com; Alan Yan - SH; mp4-tech@lists.mpegif.org Subject: RE: [Mp4-tech] Question on the mb_field_decoding_flag "not present for either macroblock" = "not present for the top macroblock and not present for the bottom macroblock" If that is not the way everyone understands the statement to mean, perhaps we need to clarify eventually. But to me that is clear. Best Regards, Gary Sullivan _____ From: Dzung Hoang [mailto:dthoang@yahoo.com] Sent: Wed 11/8/2023 1:44 PM To: Gary Sullivan; 'Alan Yan - SH'; mp4-tech@lists.mpegif.org Subject: RE: [Mp4-tech] Question on the mb_field_decoding_flag Gary et al, Section 7.4.4 specifies the process for inferring mb_field_decoding_flag when it is not present for either MB of a MB pair. I have a concern about the text of this section. When mb_field_decoding_flag is not present for either macroblock of a macroblock pair, the value of mb_field_decoding_flag is derived as follows. - If there is a neighbouring macroblock pair immediately to the left of the current macroblock pair in the same slice, the value of mb_field_decoding_flag shall be inferred to be equal to the value of mb_field_decoding_flag for the neighbouring macroblock pair immediately to the left of the current macroblock pair, - Otherwise, if there is no neighbouring macroblock pair immediately to the left of the current macroblock pair in the same slice and there is a neighbouring macroblock pair immediately above the current macroblock pair in the same slice, the value of mb_field_decoding_flag shall be inferred to be equal to the value of mb_field_decoding_flag for the neighbouring macroblock pair immediately above the current macroblock pair, - Otherwise (there is no neighbouring macroblock pair either immediately to the left or immediately above the current macroblock pair in the same slice), the value of mb_field_decoding_flag shall be inferred to be equal to 0. What happens if the top MB is skipped and the bottom MB is present? The syntax table 7.3.4 contains this. if( MbaffFrameFlag && ( CurrMbAddr % 2 = = 0 | | ( CurrMbAddr % 2 = = 1 && prevMbSkipped ) ) ) mb_field_decoding_flag There is a potential conflict. The text of 7.4.4 says to infer the mb_field_decoding_flag because it is not present for the skipped top MB. However, the syntax table says to take the mb_field_decoding_flag from the bitstream. Does this mean that the value for mb_field_decoding_flag must be equal to the inferred value? If so, then is a waste of bits. Regards, - Dzung Hoang _____ From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Gary Sullivan Sent: Wednesday, November 08, 2023 10:48 AM To: Alan Yan - SH; mp4-tech@lists.mpegif.org Subject: RE: [Mp4-tech] Question on the mb_field_decoding_flag Alan Yan et al, In either case for which the first macroblock of a macroblock pair is skipped and the second one is not, I think you should wait until mb_field_decoding_flag is determined from the syntax associated with the second macroblock before attempting to perform the decoding process for the first macroblock. The field/frame decoding mode is a macroblock pair attribute -- it must be the same for both macroblocks. I have not double-checked the text to see exactly how this intent is expressed (and to determine whether it is expressed well), but I am pretty confident that this is the intent. It may also be helpful to consult the reference software, but I doubt that is necessary in this instance. I'll try to remember to check how well the text is written on this issue later. If you have further pointers to specific places in the text where you think you see incorrect or vague aspects, please let me/us know. Best Regards, Gary Sullivan _____ From: mp4-tech-bounces@lists.mpegif.org on behalf of Alan Yan - SH Sent: Tue 11/7/2023 11:28 PM To: mp4-tech@lists.mpegif.org Subject: [Mp4-tech] Question on the mb_field_decoding_flag Dear Experts, When MbaffFrameFlag==1, there is one syntax "mb_field_decoding_flag" in MB layer for each MB pair. In case of entropy_coding_mode_flag==0, when the first MB (top MB) in the MB pair is skipped, mb_field_decoding_flag (MBFDF) is also skipped for the top MB. For following decoding process like B_DIRECT_16X16(for B_SLICE) and Boundary Strength calculation, MBFDF is necessary. And according to the spec 7.4.4, the derivation of MBFDF is performed after we know both MB of an MB pair are skipped. Does it mean that if the top MB is skipped, the spec do not have any default or temporary value defined for MBFDF and so we can not start following decoding process like B_DIRECT_16X16 and BS calculation for this top MB? We must wait till the bottom MB is parsed and the final MBFDF is decoded or derived? And when entropy_coding_mode_flag==1, I see the derivation process is always performed before decoding any syntax element, is this statement correct? And it is possible that the before-anything-derived value for MBFDF can be different from the value parsed later from the bit-stream, is it correct? In this situation and if mb_skip_flag is 1 for the top MB, can we use this temporarily derived MBFDF to start following decoding process like B_DIRECT_16X16 and BS calculation for this top-skipped MB or should we wait and use the final MBFDF? Thanks for your kindly help! (To Mr. Gary Sullivan: Thank you!) Best Regards, alan -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061108/1b1116a6/attachment.html From dthoang yahoo.com Wed Nov 8 13:44:55 2006 From: dthoang yahoo.com (Dzung Hoang) Date: Thu Nov 9 01:16:08 2006 Subject: [Mp4-tech] Question on the mb_field_decoding_flag In-Reply-To: <03CB47D9C3F8074498E4653F814D6E8F9771B3@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <006401c7037f$234bd250$aa0ba8c0@DZUNGLAPTOP> Gary et al, Section 7.4.4 specifies the process for inferring mb_field_decoding_flag when it is not present for either MB of a MB pair. I have a concern about the text of this section. When mb_field_decoding_flag is not present for either macroblock of a macroblock pair, the value of mb_field_decoding_flag is derived as follows. - If there is a neighbouring macroblock pair immediately to the left of the current macroblock pair in the same slice, the value of mb_field_decoding_flag shall be inferred to be equal to the value of mb_field_decoding_flag for the neighbouring macroblock pair immediately to the left of the current macroblock pair, - Otherwise, if there is no neighbouring macroblock pair immediately to the left of the current macroblock pair in the same slice and there is a neighbouring macroblock pair immediately above the current macroblock pair in the same slice, the value of mb_field_decoding_flag shall be inferred to be equal to the value of mb_field_decoding_flag for the neighbouring macroblock pair immediately above the current macroblock pair, - Otherwise (there is no neighbouring macroblock pair either immediately to the left or immediately above the current macroblock pair in the same slice), the value of mb_field_decoding_flag shall be inferred to be equal to 0. What happens if the top MB is skipped and the bottom MB is present? The syntax table 7.3.4 contains this. if( MbaffFrameFlag && ( CurrMbAddr % 2 = = 0 | | ( CurrMbAddr % 2 = = 1 && prevMbSkipped ) ) ) mb_field_decoding_flag There is a potential conflict. The text of 7.4.4 says to infer the mb_field_decoding_flag because it is not present for the skipped top MB. However, the syntax table says to take the mb_field_decoding_flag from the bitstream. Does this mean that the value for mb_field_decoding_flag must be equal to the inferred value? If so, then is a waste of bits. Regards, - Dzung Hoang _____ From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Gary Sullivan Sent: Wednesday, November 08, 2023 10:48 AM To: Alan Yan - SH; mp4-tech@lists.mpegif.org Subject: RE: [Mp4-tech] Question on the mb_field_decoding_flag Alan Yan et al, In either case for which the first macroblock of a macroblock pair is skipped and the second one is not, I think you should wait until mb_field_decoding_flag is determined from the syntax associated with the second macroblock before attempting to perform the decoding process for the first macroblock. The field/frame decoding mode is a macroblock pair attribute -- it must be the same for both macroblocks. I have not double-checked the text to see exactly how this intent is expressed (and to determine whether it is expressed well), but I am pretty confident that this is the intent. It may also be helpful to consult the reference software, but I doubt that is necessary in this instance. I'll try to remember to check how well the text is written on this issue later. If you have further pointers to specific places in the text where you think you see incorrect or vague aspects, please let me/us know. Best Regards, Gary Sullivan _____ From: mp4-tech-bounces@lists.mpegif.org on behalf of Alan Yan - SH Sent: Tue 11/7/2023 11:28 PM To: mp4-tech@lists.mpegif.org Subject: [Mp4-tech] Question on the mb_field_decoding_flag Dear Experts, When MbaffFrameFlag==1, there is one syntax "mb_field_decoding_flag" in MB layer for each MB pair. In case of entropy_coding_mode_flag==0, when the first MB (top MB) in the MB pair is skipped, mb_field_decoding_flag (MBFDF) is also skipped for the top MB. For following decoding process like B_DIRECT_16X16(for B_SLICE) and Boundary Strength calculation, MBFDF is necessary. And according to the spec 7.4.4, the derivation of MBFDF is performed after we know both MB of an MB pair are skipped. Does it mean that if the top MB is skipped, the spec do not have any default or temporary value defined for MBFDF and so we can not start following decoding process like B_DIRECT_16X16 and BS calculation for this top MB? We must wait till the bottom MB is parsed and the final MBFDF is decoded or derived? And when entropy_coding_mode_flag==1, I see the derivation process is always performed before decoding any syntax element, is this statement correct? And it is possible that the before-anything-derived value for MBFDF can be different from the value parsed later from the bit-stream, is it correct? In this situation and if mb_skip_flag is 1 for the top MB, can we use this temporarily derived MBFDF to start following decoding process like B_DIRECT_16X16 and BS calculation for this top-skipped MB or should we wait and use the final MBFDF? Thanks for your kindly help! (To Mr. Gary Sullivan: Thank you!) Best Regards, alan -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061108/b3880b87/attachment-0001.html From dthoang yahoo.com Wed Nov 8 14:32:38 2006 From: dthoang yahoo.com (Dzung Hoang) Date: Thu Nov 9 01:16:13 2006 Subject: [Mp4-tech] Question on the mb_field_decoding_flag In-Reply-To: <03CB47D9C3F8074498E4653F814D6E8F9771B5@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <006d01c70385$cc01eb40$aa0ba8c0@DZUNGLAPTOP> Gary, When I read "either" I immediately think "or" not "and." I think the phrase "not present for both macroblocks" more clearly states the intent. The dictionary does not help either. -adjective 1. one or the other of two: You may sit at either end of the table. 2. each of two; the one and the other: There are trees on either side of the river. Using "both" should eliminate any ambiguity. Regards, - Dzung Hoang -----Original Message----- From: Gary Sullivan [mailto:garysull@windows.microsoft.com] Sent: Wednesday, November 08, 2023 2:03 PM To: dthoang@yahoo.com; Alan Yan - SH; mp4-tech@lists.mpegif.org Subject: RE: [Mp4-tech] Question on the mb_field_decoding_flag "not present for either macroblock" = "not present for the top macroblock and not present for the bottom macroblock" If that is not the way everyone understands the statement to mean, perhaps we need to clarify eventually. But to me that is clear. Best Regards, Gary Sullivan _____ From: Dzung Hoang [mailto:dthoang@yahoo.com] Sent: Wed 11/8/2023 1:44 PM To: Gary Sullivan; 'Alan Yan - SH'; mp4-tech@lists.mpegif.org Subject: RE: [Mp4-tech] Question on the mb_field_decoding_flag Gary et al, Section 7.4.4 specifies the process for inferring mb_field_decoding_flag when it is not present for either MB of a MB pair. I have a concern about the text of this section. When mb_field_decoding_flag is not present for either macroblock of a macroblock pair, the value of mb_field_decoding_flag is derived as follows. - If there is a neighbouring macroblock pair immediately to the left of the current macroblock pair in the same slice, the value of mb_field_decoding_flag shall be inferred to be equal to the value of mb_field_decoding_flag for the neighbouring macroblock pair immediately to the left of the current macroblock pair, - Otherwise, if there is no neighbouring macroblock pair immediately to the left of the current macroblock pair in the same slice and there is a neighbouring macroblock pair immediately above the current macroblock pair in the same slice, the value of mb_field_decoding_flag shall be inferred to be equal to the value of mb_field_decoding_flag for the neighbouring macroblock pair immediately above the current macroblock pair, - Otherwise (there is no neighbouring macroblock pair either immediately to the left or immediately above the current macroblock pair in the same slice), the value of mb_field_decoding_flag shall be inferred to be equal to 0. What happens if the top MB is skipped and the bottom MB is present? The syntax table 7.3.4 contains this. if( MbaffFrameFlag && ( CurrMbAddr % 2 = = 0 | | ( CurrMbAddr % 2 = = 1 && prevMbSkipped ) ) ) mb_field_decoding_flag There is a potential conflict. The text of 7.4.4 says to infer the mb_field_decoding_flag because it is not present for the skipped top MB. However, the syntax table says to take the mb_field_decoding_flag from the bitstream. Does this mean that the value for mb_field_decoding_flag must be equal to the inferred value? If so, then is a waste of bits. Regards, - Dzung Hoang _____ From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Gary Sullivan Sent: Wednesday, November 08, 2023 10:48 AM To: Alan Yan - SH; mp4-tech@lists.mpegif.org Subject: RE: [Mp4-tech] Question on the mb_field_decoding_flag Alan Yan et al, In either case for which the first macroblock of a macroblock pair is skipped and the second one is not, I think you should wait until mb_field_decoding_flag is determined from the syntax associated with the second macroblock before attempting to perform the decoding process for the first macroblock. The field/frame decoding mode is a macroblock pair attribute -- it must be the same for both macroblocks. I have not double-checked the text to see exactly how this intent is expressed (and to determine whether it is expressed well), but I am pretty confident that this is the intent. It may also be helpful to consult the reference software, but I doubt that is necessary in this instance. I'll try to remember to check how well the text is written on this issue later. If you have further pointers to specific places in the text where you think you see incorrect or vague aspects, please let me/us know. Best Regards, Gary Sullivan _____ From: mp4-tech-bounces@lists.mpegif.org on behalf of Alan Yan - SH Sent: Tue 11/7/2023 11:28 PM To: mp4-tech@lists.mpegif.org Subject: [Mp4-tech] Question on the mb_field_decoding_flag Dear Experts, When MbaffFrameFlag==1, there is one syntax "mb_field_decoding_flag" in MB layer for each MB pair. In case of entropy_coding_mode_flag==0, when the first MB (top MB) in the MB pair is skipped, mb_field_decoding_flag (MBFDF) is also skipped for the top MB. For following decoding process like B_DIRECT_16X16(for B_SLICE) and Boundary Strength calculation, MBFDF is necessary. And according to the spec 7.4.4, the derivation of MBFDF is performed after we know both MB of an MB pair are skipped. Does it mean that if the top MB is skipped, the spec do not have any default or temporary value defined for MBFDF and so we can not start following decoding process like B_DIRECT_16X16 and BS calculation for this top MB? We must wait till the bottom MB is parsed and the final MBFDF is decoded or derived? And when entropy_coding_mode_flag==1, I see the derivation process is always performed before decoding any syntax element, is this statement correct? And it is possible that the before-anything-derived value for MBFDF can be different from the value parsed later from the bit-stream, is it correct? In this situation and if mb_skip_flag is 1 for the top MB, can we use this temporarily derived MBFDF to start following decoding process like B_DIRECT_16X16 and BS calculation for this top-skipped MB or should we wait and use the final MBFDF? Thanks for your kindly help! (To Mr. Gary Sullivan: Thank you!) Best Regards, alan From nagaraj.attimani yahoo.co.in Thu Nov 9 04:54:04 2006 From: nagaraj.attimani yahoo.co.in (Nagaraj Attimani) Date: Thu Nov 9 07:22:08 2006 Subject: [Mp4-tech] Difference in DCI string for Mpeg4 and H.264 codec. In-Reply-To: <200611090122.kA91LJvC002535@lists1.magma.ca> Message-ID: <20061109045404.84037.qmail@web8908.mail.in.yahoo.com> Dear all, Please let me know, what difference in DCI string for Mpeg4 and H.264 codec. rgds nagaraj --------------------------------- Find out what India is talking about on - Yahoo! Answers India Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061109/76600862/attachment.html From Alan.Yan fmc.fujitsu.com Thu Nov 9 13:18:32 2006 From: Alan.Yan fmc.fujitsu.com (Alan Yan - SH) Date: Thu Nov 9 07:22:13 2006 Subject: [Mp4-tech] Question on the BS value grouping of edges Message-ID: <6D7740EE76790E44A1775CE82BA2DB8E579DEC@fmcshmsex01> Dear Experts, While reading deblocking parts, there is a BS calculation. In the reference code JM86, I see it iterates for each 16 pixels of the whole horizontal or vertical edge. But we know it can be simplified, for example maybe the 4 pixels of one 4x4 block edge of internal edges share the same BS value, so they can be grouped to use one same BS value. When it comes to the left vertical MB boundary edge, the situation is kind of complicated when MBAFF mode is used. I think it may have a maximum of 8 different BS group value for this edge, is it correct? And from top to bottom, the BS values for pixel position of 0, 3, 4, 7, 8, 11, 12, 15 seem to be representative BS values for this edge, is it right? And the other couple pixel of these 8 pixels can change with different neighbor MBFDF situations, is it correct? Can you point me to some valuable documents which help to clarify and conclude different situations on the "BS value grouping of edges" topic? Best Regards, alan -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061109/d3f7b965/attachment.html From cassjo inwind.it Thu Nov 9 12:15:39 2006 From: cassjo inwind.it (Fabrizio) Date: Thu Nov 9 18:04:07 2006 Subject: [Mp4-tech] Question on JM residual coding Message-ID: <006001c703f0$ad7440e0$58cc1897@acerae863c6296> Dear expert, I would like to extract the residual of luminance energy for each P codified frame. I think that to do this I should consider the single MB and then sum the results. In particular I'm working on the function "LumaResidualCoding8x8" but I don't understand where the calculus of the residue is done. Could someone of you tell me in which variable the residue is stored? Many thanks in advance. Best regards, Fabrizio -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061109/330442d8/attachment.html From Madhurima.A aricent.com Fri Nov 10 12:01:16 2006 From: Madhurima.A aricent.com (Madhurima.A@aricent.com) Date: Fri Nov 10 13:52:07 2006 Subject: [Mp4-tech] AAC file duration Message-ID: Hi I am implemneting AAC player. But I am facing problems in extracting the file duration. If I go and parse the whole file, time calculated is approximately same, but this takes considerable amount of time. Can anybody help me on this. How can I know the bit rate in case of a VBR file with ADTS/ADIF formats Regards, Madhurima *********************** Aricent-Unclassified *********************** "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061110/fc19dde5/attachment.html From Alan.Yan fmc.fujitsu.com Tue Nov 14 11:08:01 2006 From: Alan.Yan fmc.fujitsu.com (Alan Yan, Ying Rui - SH) Date: Tue Nov 14 13:52:07 2006 Subject: [Mp4-tech] a doubt about a statement in the spec Message-ID: <6D7740EE76790E44A1775CE82BA2DB8E57A1C1@fmcshmsex01.fmc.fujitsu.com> Dear Experts, I have a doubt about this statement in the spec. In 8.4.1.2.1, it said that, The motion vector mvCol and the reference index refIdxCol are derived as follows. - If the macroblock mbAddrCol is coded in Intra macroblock prediction mode or both prediction utilization flags, predFlagL0Col and predFlagL1Col are equal to 0, both components of mvCol are set equal to 0 and refIdxCol is set equal to -1. About the red highlighted words, is it possible that an MB which is not coded in Intra macroblock have both prediction utilization flags equal to 0? I had thought that only Intra MB will have both prediction utilization flags equal to 0. Could you please help to give an example please? Best Regards, alan -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061114/d904e2a6/attachment.html From Danijel.Domazet zg.t-com.hr Tue Nov 14 17:00:48 2006 From: Danijel.Domazet zg.t-com.hr (Danijel Domazet) Date: Wed Nov 15 15:34:06 2006 Subject: [Mp4-tech] Chinese AVS codec - audio? References: <6D7740EE76790E44A1775CE82BA2DB8E57A1C1@fmcshmsex01.fmc.fujitsu.com> Message-ID: <001501c70806$0d736200$0401a8c0@FERGUSON> Hi all, Does anyone know which audio codec is used inside Chinese AVS codec? Is it 'similar' to AAC as they say AVS video is to H264? I guess the specs are not publicaly available... Thanks, Danijel Domazet From danicamps81 yahoo.com Wed Nov 15 01:55:31 2006 From: danicamps81 yahoo.com (Dani Camps) Date: Wed Nov 15 15:34:12 2006 Subject: [Mp4-tech] Getting frames belonging to different partition using data-partitioning Message-ID: <20061115095531.63420.qmail@web32002.mail.mud.yahoo.com> Dear all, I am using the JM11 H264 encoder. I use the option of data partitioning, and I am interested in obtaining the traces (time size) of the frames belonging to each partition, afterwards I will input these traces to a simulator. My problem is that I can encode the video using data partitioing but from the log I can not distinguish to which partition (A,B or C) each frame belongs. The output I can read from the log for each frame at maximum verbose mode is: Frame Bit/pic WP QP SnrY SnrU SnrV Time(ms) MET(ms) Frm/Fld I D L0 L1 RDP Ref But none of these fields is telling me if the frame belongs to partition A, B or C. I can see that I am encoding with data partitioning because I have in the log: Data Partitioning Mode : 3 partitions Is there any way to know from the log which partition each frame belongs to or I am doing something completely wrong? Thanks in advance Daniel Camps ____________________________________________________________________________________ Sponsored Link Mortgage rates near 39yr lows. $310k for $999/mo. Calculate new payment! www.LowerMyBills.com/lre From Wesley.DeNeve UGent.be Wed Nov 15 19:09:26 2006 From: Wesley.DeNeve UGent.be (Wesley De Neve) Date: Wed Nov 15 19:10:08 2006 Subject: [Mp4-tech] Getting frames belonging to different partition usingdata-partitioning References: <20061115095531.63420.qmail@web32002.mail.mud.yahoo.com> Message-ID: <03e001c708e1$30075840$0200a8c0@persephone> Dear Dani, To know the partition the coded data of a slice belongs to, you need to know the value of the nal_unit_type syntax element (each partition is put into a separate NAL unit, where each such NAL unit is characterized by a different NAL unit type). The H.264/AVC defines the following mapping: nal_unit_type 1 denotes 'Coded slice of a non-IDR picture' nal_unit_type 2 denotes 'Coded slice data partition A' nal_unit_type 3 denotes 'Coded slice data partition B' nal_unit_type 4 denotes 'Coded slice data partition C' Best regards, Wesley De Neve Dani Camps wrote: > Dear all, > > I am using the JM11 H264 encoder. I use the option of > data partitioning, and I am interested in obtaining > the traces (time size) of the frames belonging to each > partition, afterwards I will input these traces to a > simulator. My problem is that I can encode the video > using data partitioing but from the log I can not > distinguish to which partition (A,B or C) each frame > belongs. > > The output I can read from the log for each frame at > maximum verbose mode is: > > Frame > Bit/pic > WP QP > SnrY > SnrU > SnrV > Time(ms) > MET(ms) > Frm/Fld > I > D > L0 > L1 > RDP > Ref > > But none of these fields is telling me if the frame > belongs to partition A, B or C. I can see that I am > encoding with data partitioning because I have in the > log: > > Data Partitioning Mode : 3 partitions > > Is there any way to know from the log which partition > each frame belongs to or I am doing something > completely wrong? > > Thanks in advance > > Daniel Camps > > > > > > > > > ____________________________________________________________________________________ > Sponsored Link > > Mortgage rates near 39yr lows. > $310k for $999/mo. Calculate new payment! > www.LowerMyBills.com/lre > _______________________________________________ > 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 From garysull windows.microsoft.com Wed Nov 15 12:02:46 2006 From: garysull windows.microsoft.com (Gary Sullivan) Date: Wed Nov 15 20:10:08 2006 Subject: [Mp4-tech] a doubt about a statement in the spec In-Reply-To: <6D7740EE76790E44A1775CE82BA2DB8E57A1C1@fmcshmsex01.fmc.fujitsu.com> Message-ID: <03CB47D9C3F8074498E4653F814D6E8F02E24179@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> At first glance, it looks like this says "If A or B" where A and B are synonymous, and therefore the form of the expression is useless/confusing. Best Regards, Gary Sullivan ________________________________ From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Alan Yan, Ying Rui - SH Sent: Monday, November 13, 2023 7:08 PM To: mp4-tech@lists.mpegif.org Subject: [Mp4-tech] a doubt about a statement in the spec Dear Experts, I have a doubt about this statement in the spec. In 8.4.1.2.1, it said that, The motion vector mvCol and the reference index refIdxCol are derived as follows. - If the macroblock mbAddrCol is coded in Intra macroblock prediction mode or both prediction utilization flags, predFlagL0Col and predFlagL1Col are equal to 0, both components of mvCol are set equal to 0 and refIdxCol is set equal to -1. About the red highlighted words, is it possible that an MB which is not coded in Intra macroblock have both prediction utilization flags equal to 0? I had thought that only Intra MB will have both prediction utilization flags equal to 0. Could you please help to give an example please? Best Regards, alan -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061115/0ad0591a/attachment.html From dmitriy graphics.cs.msu.ru Tue Nov 14 17:01:26 2006 From: dmitriy graphics.cs.msu.ru (Dmitriy Vatolin) Date: Thu Nov 16 10:46:06 2006 Subject: [Mp4-tech] Call for lossless video codecs Message-ID: <1042599334.20061114170126@graphics.cs.msu.ru> Dear all! ------------------------------------------------------------------- CALL FOR LOSSLESS VIDEO CODECS ------------------------------------------------------------------- We are planning to update our old comparison of lossless video codecs (see http://www.compression.ru/video/codec_comparison/index_en.html ). We are looking for the new lossless video codecs or competitive video codecs which were not included in the existing comparison document. We are interested in general-purpose codecs right now (e.g. screen capture codecs is out of scope of this comparison). It is planned to compare codecs within "video capture&editing" and "maximum compression" areas. Currently we are aware of the following codecs: 1. Alpary 2. AVIzlib 3. CamStudio GZIP 4. CorePNG 5. FFV1 ffdshow 6. GLZW 7. HuffYUV 8. Lagarith 9. LEAD JPEG 10. LOCO 11. MindVid 12. MSUlab 13. PicVideo JPEG 14. VBLE 15. Arithyuv 16. Sheervideo 17. FastCodec 18. x264 lossless Please let us know about other good lossless codecs by replaying this message. Also you can add link to Compression-links catalog: http://www.compression-links.info/Lossless_Video_Codecs Thank you! Yours, Dr. Vatolin From awells ambarella.com Wed Nov 15 16:51:46 2006 From: awells ambarella.com (Aaron Wells) Date: Thu Nov 16 10:46:11 2006 Subject: [Mp4-tech] Field VOPs in MPEG-4 part 2? Message-ID: <90B0CE4312136749B97EBEAF5764F87401323F35@ambarella-ex.ambarella.net> Hi Gary, So, just to clarify, Is it the case that, apart from the Studio profiles, MPEG4 part 2 has no support for "picture-adaptive-field/frame" coding such as one can do in MPEG2 or H.264? Thanks Aaron Barry et al, Regarding your remark: +> Field VOPs seems to be allowed only in the Advanced Coding +> Efficiency +> profile. See Tables V2-39 and V2-40 in Sec. 9 profiles and levels That doesn't sound right. The ACE profile was in the 2001 edition, but I don't think field VOPs were defined yet in that edition. As far as I can tell, they arrived in the Studio Profile amendment -- they were added later. And those tables that you refer to don't actually say "field VOPs". They just say "interlace". As it existed at the time of the 2001 edition, I believe "interlace" did not include field VOPs. As discussed in the Alito hearings today, sometimes we must go back and do research to try to figure out what the original framers intended. :-) Table 9-3 of the 2003 edition says that Simple Studio and Core Studio include "Frame/Field Structure". The phrase "frame/field structure" is not defined in the standard. However, I think it refers to frame and field VOP support. And I think those are the only profiles that contain them. Best Regards, Gary Sullivan +> -----Original Message----- +> From: bhaskell [mailto:bhaskell apple.com ] +> Sent: Tuesday, January 10, 2024 11:48 AM +> To: Gary Sullivan +> Cc: mpeg-video lists.rwth-aachen.de ; mp4-tech lists.mpegif.org +> Subject: Re: [Mp4-tech] Field VOPs in MPEG-4 part 2? +> +> Gary Sullivan wrote: +> +> >Yes, I see it now. I guess this was part of the Studio Profile +> >amendment - I hadn't looked in there for it before. It +> seems to only be +> >supported in the Studio Profiles? (e.g., not in the Advanced Simple +> >Profile) +> > +> > +> +> Field VOPs seems to be allowed only in the Advanced Coding +> Efficiency +> profile. See Tables V2-39 and V2-40 in Sec. 9 profiles and levels +> +> +> >Best Regards, +> > +> >-Gary +> > +> >+> -----Original Message----- +> >+> From: bhaskell [mailto:bhaskell apple.com ] +> >+> Sent: Monday, January 09, 2024 11:55 AM +> >+> To: Gary Sullivan +> >+> Cc: mpeg-video lists.rwth-aachen.de ; mp4-tech lists.mpegif.org +> >+> Subject: Re: [Mp4-tech] Field VOPs in MPEG-4 part 2? +> >+> +> >+> Gary Sullivan wrote: +> >+> +> >+> >At first glance, it appears that MPEG-4 part 2 does not +> support VOPs +> >+> >that represent a single field of an interlaced frame. +> >+> > +> >+> >Can anyone confirm or refute that assertion? +> >+> > +> >+> > +> >+> Well, there are field VOPs ( top field VOPs and bottom field +> >+> VOPs), but +> >+> they are constrained to occur in pairs. See Sec. 6.1.3.4.1 +> >+> Field VOPs +> >+> +> >+> >Best Regards, +> >+> > +> >+> >Gary Sullivan +> >+> > +> >+> +> > +> +> +> -- +> Barry G. Haskell tel +1 408 974 6333 +> Apple Computer Inc. fax " " " 1756 +> 2 Infinite Loop MS: 302-3KS +> Cupertino, CA 95014 +> bhaskell apple.com (also B.Haskell ieee.org ) +> +> +> -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061115/919d55d0/attachment.html From garysull windows.microsoft.com Thu Nov 16 11:05:37 2006 From: garysull windows.microsoft.com (Gary Sullivan) Date: Thu Nov 16 20:04:07 2006 Subject: [Mp4-tech] Field VOPs in MPEG-4 part 2? In-Reply-To: <90B0CE4312136749B97EBEAF5764F87401323F35@ambarella-ex.ambarella.net> Message-ID: <03CB47D9C3F8074498E4653F814D6E8F02E246BC@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> I think that is true (although the last quoted message on this thread was from nearly a year ago, so the subject is not especially fresh in my mind). Best Regards, Gary Sullivan ________________________________ From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Aaron Wells Sent: Wednesday, November 15, 2023 4:52 PM To: mp4-tech@lists.mpegif.org Subject: [Mp4-tech] Field VOPs in MPEG-4 part 2? Hi Gary, So, just to clarify, Is it the case that, apart from the Studio profiles, MPEG4 part 2 has no support for "picture-adaptive-field/frame" coding such as one can do in MPEG2 or H.264? Thanks Aaron Barry et al, Regarding your remark: +> Field VOPs seems to be allowed only in the Advanced Coding +> Efficiency +> profile. See Tables V2-39 and V2-40 in Sec. 9 profiles and levels That doesn't sound right. The ACE profile was in the 2001 edition, but I don't think field VOPs were defined yet in that edition. As far as I can tell, they arrived in the Studio Profile amendment -- they were added later. And those tables that you refer to don't actually say "field VOPs". They just say "interlace". As it existed at the time of the 2001 edition, I believe "interlace" did not include field VOPs. As discussed in the Alito hearings today, sometimes we must go back and do research to try to figure out what the original framers intended. :-) Table 9-3 of the 2003 edition says that Simple Studio and Core Studio include "Frame/Field Structure". The phrase "frame/field structure" is not defined in the standard. However, I think it refers to frame and field VOP support. And I think those are the only profiles that contain them. Best Regards, Gary Sullivan +> -----Original Message----- +> From: bhaskell [mailto:bhaskell apple.com ] +> Sent: Tuesday, January 10, 2024 11:48 AM +> To: Gary Sullivan +> Cc: mpeg-video lists.rwth-aachen.de ; mp4-tech lists.mpegif.org +> Subject: Re: [Mp4-tech] Field VOPs in MPEG-4 part 2? +> +> Gary Sullivan wrote: +> +> >Yes, I see it now. I guess this was part of the Studio Profile +> >amendment - I hadn't looked in there for it before. It +> seems to only be +> >supported in the Studio Profiles? (e.g., not in the Advanced Simple +> >Profile) +> > +> > +> +> Field VOPs seems to be allowed only in the Advanced Coding +> Efficiency +> profile. See Tables V2-39 and V2-40 in Sec. 9 profiles and levels +> +> +> >Best Regards, +> > +> >-Gary +> > +> >+> -----Original Message----- +> >+> From: bhaskell [mailto:bhaskell apple.com ] +> >+> Sent: Monday, January 09, 2024 11:55 AM +> >+> To: Gary Sullivan +> >+> Cc: mpeg-video lists.rwth-aachen.de ; mp4-tech lists.mpegif.org +> >+> Subject: Re: [Mp4-tech] Field VOPs in MPEG-4 part 2? +> >+> +> >+> Gary Sullivan wrote: +> >+> +> >+> >At first glance, it appears that MPEG-4 part 2 does not +> support VOPs +> >+> >that represent a single field of an interlaced frame. +> >+> > +> >+> >Can anyone confirm or refute that assertion? +> >+> > +> >+> > +> >+> Well, there are field VOPs ( top field VOPs and bottom field +> >+> VOPs), but +> >+> they are constrained to occur in pairs. See Sec. 6.1.3.4.1 +> >+> Field VOPs +> >+> +> >+> >Best Regards, +> >+> > +> >+> >Gary Sullivan +> >+> > +> >+> +> > +> +> +> -- +> Barry G. Haskell tel +1 408 974 6333 +> Apple Computer Inc. fax " " " 1756 +> 2 Infinite Loop MS: 302-3KS +> Cupertino, CA 95014 +> bhaskell apple.com (also B.Haskell ieee.org ) +> +> +> -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061116/61a33491/attachment.html From danicamps81 yahoo.com Fri Nov 17 16:12:05 2006 From: danicamps81 yahoo.com (Dani Camps) Date: Sat Nov 18 16:34:07 2006 Subject: [Mp4-tech] Integrating encoder input and output with network simulator Message-ID: <20061118001205.50687.qmail@web32014.mail.mud.yahoo.com> Dear all, I am trying to input the video stream generated with JM11 into a network simulator and then reconstruct a video from the output packets. The network simulators I want to consider are both OPNET and NS-2. Do you have specific solutions to integrate an encoder/decoder with any of these simulators ? Regarding OPNET there is an extension called "System-In-The-Loop" that allows to input real IP packets from a physiscal interface in the simulator and write the output of the simulator into another real physical interface, so that could be a solution, anyone has experience with it? Any solution regarding NS ? >From the encoder log I can obtain the information I need to input in the simulator, packet time and size, but the problem is how to modify the binary generated by the encoder according to the output of the simulator to view the result after the decoder, and compute for instance PSNR. Any existent tool that allows for doing this? Best Regards Dani ____________________________________________________________________________________ Sponsored Link Mortgage rates near 39yr lows. $420k for $1,399/mo. Calculate new payment! www.LowerMyBills.com/lre From Alexis.Tourapis dolby.net Sun Nov 19 12:33:08 2006 From: Alexis.Tourapis dolby.net (Tourapis, Alexis) Date: Sun Nov 19 20:40:06 2006 Subject: [Mp4-tech] RE: [jvt-experts] why B frames bitrates must be smaller than P framesbitrates? Message-ID: <2BAAC5E4AF2518459F0AB5D9279420475C33@bur-exch-01.dolby.net> Dear Bita, The Lagrangian costs for motion estimation and Rate Distortion Optimized mode decision are also different (higher) by default in the reference software. Their values tend to give higher priority to inter modes and in particular skip since they tend to give a preference to modes that result in fewer bits instead of lower distortion. The general assumption (right or wrong) is that for B slices you can sacrifice a bit more in terms of quality and have savings on bitrate which would translate to bigger savings and smaller impact in quality on the overall sequence. You can change the lagrangian costs either by modifying the software or by using the explicit lagrangian parameters in the configuration file (UseExplicitLambdaParams) Furthermore you may wish to set the following flags DisableThresholding = 1 DisableBSkipRDO = 1 The second one can be especially important since it avoids forcing the test of skip modes in B slices (normally the encoder will test if the motion vectors corresponding to skip/direct also result in a coded residual and based on that determine if mode is skip or direct). Although bipredictive ME could improve the chances of getting skip/direct modes and of course bi-predictive partitions, I do not understand your reasoning of disabling this. Are you trying to bias intra modes during fading transitions? Furthermore, I am also assuming that you are not using weighted prediction which was introduced in the standard for this particular reason. Finally, I am assuming you are talking about the encoder.cfg file in terms of defined QP values for P and B slices. The reference software does not specify any such condition in general. Best regards, Alexis ________________________________ From: jvt-experts-bounces@lists.rwth-aachen.de [mailto:jvt-experts-bounces@lists.rwth-aachen.de] On Behalf Of bita damghanian Sent: Sunday, November 19, 2023 12:02 PM To: jvt-experts@lists.rwth-aachen.de Cc: mp4-tech@lists.mpegif.org Subject: [jvt-experts] why B frames bitrates must be smaller than P framesbitrates? Dear all experts, my experiments show that in fade out sequences(where the frames luminance decrease in consequetive frames), the P frames macroblocks are mostly Intra coded. the case is also true for B frames. but in long fades where the luminance decrease between two consequetive frames is so small, the B frames MBs are mostly Skipped. but in this situation the P frames macroblocks are still mostly Intra coded. I don't know why when P frames MBs are intra coded, the B frames MBs are skip coded. I found 3 reasons for this: 1- Bi-predictive ME for B frames and being able to be predicted from different directions, make B frames be coded more optimum. to omit thit effect, I disabled Bi-predictive ME and defined 1 number of reference frames for B frames. 2- In jm10.2 the QP defind for B frames are greater than the QP defind for P frames and thus B frames are mostly prefer to be skipprd. to omit thit effect, I defined equal QPs for P and B frames 3-rate control should be off but still the problem remains: what are the other factors which make B frames MBs to be more skipped rather than to be Intra coded like P frames MBs? in other words, why B frames bitrates must be smaller than P frames bitrates? what are the parameters in the encoder which force this? thanks in advance for your attention and help, Bita Damghanian ----------------------------------------- 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/20061119/462ca76f/attachment.html From garysull windows.microsoft.com Sun Nov 19 12:53:33 2006 From: garysull windows.microsoft.com (Gary Sullivan) Date: Sun Nov 19 21:04:07 2006 Subject: [Mp4-tech] RE: [jvt-experts] why B frames bitrates must be smaller than P framesbitrates? In-Reply-To: <2BAAC5E4AF2518459F0AB5D9279420475C33@bur-exch-01.dolby.net> Message-ID: <03CB47D9C3F8074498E4653F814D6E8F02ED4716@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> Bita et al, If you're working on sequences that include fades, it might be a good idea to try using weighted prediction. Best Regards, Gary Sullivan ________________________________ From: jvt-experts-bounces@lists.rwth-aachen.de [mailto:jvt-experts-bounces@lists.rwth-aachen.de] On Behalf Of Tourapis, Alexis Sent: Sunday, November 19, 2023 12:33 PM To: bita damghanian; jvt-experts@lists.rwth-aachen.de Cc: mp4-tech@lists.mpegif.org Subject: Re: [jvt-experts] why B frames bitrates must be smaller than P framesbitrates? Dear Bita, The Lagrangian costs for motion estimation and Rate Distortion Optimized mode decision are also different (higher) by default in the reference software. Their values tend to give higher priority to inter modes and in particular skip since they tend to give a preference to modes that result in fewer bits instead of lower distortion. The general assumption (right or wrong) is that for B slices you can sacrifice a bit more in terms of quality and have savings on bitrate which would translate to bigger savings and smaller impact in quality on the overall sequence. You can change the lagrangian costs either by modifying the software or by using the explicit lagrangian parameters in the configuration file (UseExplicitLambdaParams) Furthermore you may wish to set the following flags DisableThresholding = 1 DisableBSkipRDO = 1 The second one can be especially important since it avoids forcing the test of skip modes in B slices (normally the encoder will test if the motion vectors corresponding to skip/direct also result in a coded residual and based on that determine if mode is skip or direct). Although bipredictive ME could improve the chances of getting skip/direct modes and of course bi-predictive partitions, I do not understand your reasoning of disabling this. Are you trying to bias intra modes during fading transitions? Furthermore, I am also assuming that you are not using weighted prediction which was introduced in the standard for this particular reason. Finally, I am assuming you are talking about the encoder.cfg file in terms of defined QP values for P and B slices. The reference software does not specify any such condition in general. Best regards, Alexis ________________________________ From: jvt-experts-bounces@lists.rwth-aachen.de [mailto:jvt-experts-bounces@lists.rwth-aachen.de] On Behalf Of bita damghanian Sent: Sunday, November 19, 2023 12:02 PM To: jvt-experts@lists.rwth-aachen.de Cc: mp4-tech@lists.mpegif.org Subject: [jvt-experts] why B frames bitrates must be smaller than P framesbitrates? Dear all experts, my experiments show that in fade out sequences(where the frames luminance decrease in consequetive frames), the P frames macroblocks are mostly Intra coded. the case is also true for B frames. but in long fades where the luminance decrease between two consequetive frames is so small, the B frames MBs are mostly Skipped. but in this situation the P frames macroblocks are still mostly Intra coded. I don't know why when P frames MBs are intra coded, the B frames MBs are skip coded. I found 3 reasons for this: 1- Bi-predictive ME for B frames and being able to be predicted from different directions, make B frames be coded more optimum. to omit thit effect, I disabled Bi-predictive ME and defined 1 number of reference frames for B frames. 2- In jm10.2 the QP defind for B frames are greater than the QP defind for P frames and thus B frames are mostly prefer to be skipprd. to omit thit effect, I defined equal QPs for P and B frames 3-rate control should be off but still the problem remains: what are the other factors which make B frames MBs to be more skipped rather than to be Intra coded like P frames MBs? in other words, why B frames bitrates must be smaller than P frames bitrates? what are the parameters in the encoder which force this? thanks in advance for your attention and help, Bita Damghanian ________________________________ 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/20061119/a3893330/attachment-0001.html From dthoang yahoo.com Mon Nov 20 09:41:32 2006 From: dthoang yahoo.com (Dzung Hoang) Date: Mon Nov 20 16:34:08 2006 Subject: [Mp4-tech] RE: [jvt-experts] why B frames bitrates must be smaller than P framesbitrates? In-Reply-To: <8f3991e30611191201r5d9cdce5kce687b81b9a7df7e@mail.gmail.com> Message-ID: <007501c70cba$5b1ff5a0$6401a8c0@DZUNGLAPTOP> One reason not mentioned is that the distance to the nearest reference frame is larger for P frames than for B frames. Therefore what looks like a slow fade to B frames looks like a quick fade to P frames. Regards, - Dzung Hoang _____ From: jvt-experts-bounces@lists.rwth-aachen.de [mailto:jvt-experts-bounces@lists.rwth-aachen.de] On Behalf Of bita damghanian Sent: Sunday, November 19, 2023 2:02 PM To: jvt-experts@lists.rwth-aachen.de Cc: mp4-tech@lists.mpegif.org Subject: [jvt-experts] why B frames bitrates must be smaller than P framesbitrates? Dear all experts, my experiments show that in fade out sequences(where the frames luminance decrease in consequetive frames), the P frames macroblocks are mostly Intra coded. the case is also true for B frames. but in long fades where the luminance decrease between two consequetive frames is so small, the B frames MBs are mostly Skipped. but in this situation the P frames macroblocks are still mostly Intra coded. I don't know why when P frames MBs are intra coded, the B frames MBs are skip coded. I found 3 reasons for this: 1- Bi-predictive ME for B frames and being able to be predicted from different directions, make B frames be coded more optimum. to omit thit effect, I disabled Bi-predictive ME and defined 1 number of reference frames for B frames. 2- In jm10.2 the QP defind for B frames are greater than the QP defind for P frames and thus B frames are mostly prefer to be skipprd. to omit thit effect, I defined equal QPs for P and B frames 3-rate control should be off but still the problem remains: what are the other factors which make B frames MBs to be more skipped rather than to be Intra coded like P frames MBs? in other words, why B frames bitrates must be smaller than P frames bitrates? what are the parameters in the encoder which force this? thanks in advance for your attention and help, Bita Damghanian -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061120/cda8de03/attachment.html From nitin_wfd rediffmail.com Mon Nov 20 17:41:26 2006 From: nitin_wfd rediffmail.com (nitin ashok) Date: Mon Nov 20 19:04:07 2006 Subject: [Mp4-tech] question regarding prediction error Message-ID: <20061120173752.3326.qmail@webmail28.rediffmail.com> ? Dear Experts, i am trying to find the prediction error for a macroblock,i am using the JM 10.2 reference software.i am looking at the dct_luma() function in block.c,where the residual goes for transformation,but since the rdopt is enabled, i am not sure of how to find the prediction error for the best mode,please guide thanks nitin -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061120/f4e5c220/attachment.html From garima.singh tivr.co.in Mon Nov 20 22:15:53 2006 From: garima.singh tivr.co.in (Garima Singh) Date: Tue Nov 21 08:16:06 2006 Subject: [Mp4-tech][Audio]: ADTS Audio in MPEG-2 TS In-Reply-To: Message-ID: <20061121061553.19708.qmail@web215.biz.mail.re2.yahoo.com> Hi All, Can anybody please explain me how ADTS audio data (MPEG-2 AAC/ MPEG-4 AAC) is packetized in MPEG-2 TS ? I know that there is ADTS header present in each audio frame while storing file in adts format but does the header exists while packetizing this frame in a MPEG-2 TS ? Where can I find syntax of packaging ADTS packets in MPEG-2 TS? Thanks, Garima Regards, Garima Singh TIVR Communications - Delivering Efficient Solutions for Mobile Multimedia www.tivr.co.in -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061120/3b4dc6d1/attachment.html From rgomathi sarayusoftech.com Tue Nov 21 15:58:41 2006 From: rgomathi sarayusoftech.com (rgomathi@sarayusoftech.com) Date: Tue Nov 21 13:22:07 2006 Subject: [Mp4-tech] how to play .aac fille with adif header Message-ID: <58873.212.25.82.227.1164104921.squirrel@203.101.43.195> Hi all...... I badly want to know how to play .aac file with adif header.for the same raw data with adts header most of the players like vlc,quick time players play exactly well.but if i put adif header for the same even VLC 8.5 doen't play.would i do somthing special to play this in vlc....please guide me experts...expecting replies asap... Thanks in advance Gomathi From mp3.aac.mp4 gmail.com Tue Nov 21 18:33:01 2006 From: mp3.aac.mp4 gmail.com (tech list) Date: Tue Nov 21 13:22:12 2006 Subject: [Mp4-tech] youtube Message-ID: <409a09b90611210503l6472bac2u3a8463999ce04475@mail.gmail.com> Kinda off topic, but does anyone know the codec and container being used by youtube? And if anyone has implemented it on an ARM platform? -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061121/28465789/attachment.html From fful conncoll.edu Tue Nov 21 12:58:54 2006 From: fful conncoll.edu (Frank Fulchiero) Date: Tue Nov 21 20:28:07 2006 Subject: [Mp4-tech] Re: Mp4-tech] youtube In-Reply-To: <200611211707.kALH7XRg011690@lists1.magma.ca> References: <200611211707.kALH7XRg011690@lists1.magma.ca> Message-ID: <380E76DA-042F-4282-ABDA-F4677B25F6A2@conncoll.edu> It's the Spark codec in a Flash container. Spark was developed by Sorenson, and based on H.263 Flash now has a better codec, On2's VP6 Both are proprietary. Frank Fulchiero Digital Media Specialist Connecticut College > From: "tech list" > Subject: [Mp4-tech] youtube > To: mp4-tech@lists.mpegif.org > Message- > > Kinda off topic, but does anyone know the codec and container being > used by > youtube? > And if anyone has implemented it on an ARM platform? From Danijel.Domazet zg.t-com.hr Tue Nov 21 23:12:57 2006 From: Danijel.Domazet zg.t-com.hr (Danijel Domazet) Date: Wed Nov 22 00:04:07 2006 Subject: [Mp4-tech] youtube References: <200611211707.kALH7XRg011690@lists1.magma.ca> <380E76DA-042F-4282-ABDA-F4677B25F6A2@conncoll.edu> Message-ID: <006901c70dba$337e6cb0$6401a8c0@FERGUSON> Why not H264? What's the reason for using proprietary codecs? ----- Original Message ----- From: Frank Fulchiero To: mp4-tech@lists.mpegif.org Cc: mp3.aac.mp4@gmail.com Sent: Tuesday, November 21, 2023 6:58 PM Subject: [Mp4-tech] Re: Mp4-tech] youtube It's the Spark codec in a Flash container. Spark was developed by Sorenson, and based on H.263 Flash now has a better codec, On2's VP6 Both are proprietary. Frank Fulchiero Digital Media Specialist Connecticut College > From: "tech list" > Subject: [Mp4-tech] youtube > To: mp4-tech@lists.mpegif.org > Message- > > Kinda off topic, but does anyone know the codec and container being used > by > youtube? > And if anyone has implemented it on an ARM platform? _______________________________________________ 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 From fful conncoll.edu Tue Nov 21 20:22:51 2006 From: fful conncoll.edu (Frank Fulchiero) Date: Wed Nov 22 08:40:24 2006 Subject: [Mp4-tech] youtube In-Reply-To: <006901c70dba$337e6cb0$6401a8c0@FERGUSON> References: <200611211707.kALH7XRg011690@lists1.magma.ca> <380E76DA-042F-4282-ABDA-F4677B25F6A2@conncoll.edu> <006901c70dba$337e6cb0$6401a8c0@FERGUSON> Message-ID: <7821AEF3-A671-4902-A384-C06A4D7CAA3E@conncoll.edu> All I know is what is here: http://www.kaourantin.net/2005/08/quest-for-new-video-codec-in- flash-8.html (copy/paste in browser and eliminate spaces if the URL breaks up) I would not be surprised if it ended up being a political decision... Frank Fulchiero Digital Media Specialist Connecticut College On Nov 21, 2006, at 5:12 PM, Danijel Domazet wrote: > Why not H264? > What's the reason for using proprietary codecs? From Peter.Parnes ltu.se Wed Nov 22 08:52:09 2006 From: Peter.Parnes ltu.se (Peter Parnes) Date: Wed Nov 22 08:52:09 2006 Subject: [Mp4-tech] youtube In-Reply-To: <006901c70dba$337e6cb0$6401a8c0@FERGUSON> References: <200611211707.kALH7XRg011690@lists1.magma.ca> <380E76DA-042F-4282-ABDA-F4677B25F6A2@conncoll.edu> <006901c70dba$337e6cb0$6401a8c0@FERGUSON> Message-ID: <456401A9.2000102@ltu.se> > Why not H264? > What's the reason for using proprietary codecs? A guess. MPEG-LA? I.e. they have to pay royalties for patents to use H.264. -Peter Parnes, PhD Associate Professor Media Technology Lule? University of Technology From rgomathi sarayusoftech.com Wed Nov 22 14:37:02 2006 From: rgomathi sarayusoftech.com (rgomathi@sarayusoftech.com) Date: Wed Nov 22 10:16:22 2006 Subject: [Mp4-tech] how to play .aac fille with adif header In-Reply-To: <20061121150134.69466.qmail@web90515.mail.mud.yahoo.com> References: <20061121150134.69466.qmail@web90515.mail.mud.yahoo.com> Message-ID: <41117.212.25.82.227.1164186422.squirrel@203.101.43.195> > Hi all.... Thanks a lot for ur replies.can i know the reason behind why only certain players could play the .acc with ADIF header.B'coz both ADIF and ADTS headers can be used to create .aac file in general.I think the only difference being one time ADIF header for the whole stream and ADTS for every frame.If i'm correct why the normal players couldn't play that.is there any special thing the decoder should do to decode aac stream with adif.....expecting replies... Thanks in advance, regards, Gomathi. Hi, > > You can use Cool Edit to play that, > > -Vishvanath > > > > ----- Original Message ---- > From: "rgomathi@sarayusoftech.com" > To: mp4-tech@lists.mpegif.org; mp4-tech-request@lists.mpegif.org > Sent: Tuesday, 21 November, 2006 3:58:41 PM > Subject: [Mp4-tech] how to play .aac fille with adif header > > > Hi all...... > I badly want to know how to play .aac file with adif header.for the > same raw data with adts header most of the players like vlc,quick time > players play exactly well.but if i put adif header for the same even > VLC 8.5 doen't play.would i do somthing special to play this in > vlc....please guide me experts...expecting replies asap... > > Thanks in advance > Gomathi > _______________________________________________ > 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 > > Send instant messages to your online friends http://uk.messenger.yahoo.com > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > From Apoorva soc-soft.com Wed Nov 22 16:50:53 2006 From: Apoorva soc-soft.com (Apoorva@soc-soft.com) Date: Wed Nov 22 12:22:07 2006 Subject: [Mp4-tech] how to play .aac fille with adif header Message-ID: <4BF47D56A0DD2346A1B8D622C5C5902C01F683D5@soc-mail.soc-soft.com> Hello Gomathi, AAC bit stream according to the standard, contains only syntactic elements (SCE, CPE, LFE, DSE, PCE, FILL, CCE, TERM). So if an AAC decoder is developed, it will be implemented to support and decode the syntactic elements compulsorily. Let us call the AAC containing only syntactic elements as "Raw AAC". When we consider ADTS or ADIF, these are headers which provide information about the bit stream like sampling rate, channels, etc. And these headers (ADTS, ADIF) are not the only format, AAC bit stream could be encapsulated in. Raw AAC can even be a part of MP4 transport stream, in which the data like Sampling rate and channels will be a part of configuration information. So, if a player has AAC decoder but, do not have the implementation to decode the headers (ADTS, ADIF) then, the player can very well decode the "Raw AAC" (information of Sampling rate will have to be provided by the user) but, will not be in a position to decode the AAC with ADTS or ADIF header. Hope this helps, Apoorva Ankad -----Original Message----- From: rgomathi@sarayusoftech.com [mailto:rgomathi@sarayusoftech.com] Sent: Wednesday, November 22, 2023 2:37 PM To: Deshpande, Vishvanath; mp4-tech@lists.mpegif.org; mp4-tech-request@lists.mpegif.org Subject: Re: [Mp4-tech] how to play .aac fille with adif header > Hi all.... Thanks a lot for ur replies.can i know the reason behind why only certain players could play the .acc with ADIF header.B'coz both ADIF and ADTS headers can be used to create .aac file in general.I think the only difference being one time ADIF header for the whole stream and ADTS for every frame.If i'm correct why the normal players couldn't play that.is there any special thing the decoder should do to decode aac stream with adif.....expecting replies... Thanks in advance, regards, Gomathi. Hi, > > You can use Cool Edit to play that, > > -Vishvanath > > > > ----- Original Message ---- > From: "rgomathi@sarayusoftech.com" > To: mp4-tech@lists.mpegif.org; mp4-tech-request@lists.mpegif.org > Sent: Tuesday, 21 November, 2006 3:58:41 PM > Subject: [Mp4-tech] how to play .aac fille with adif header > > > Hi all...... > I badly want to know how to play .aac file with adif header.for the > same raw data with adts header most of the players like vlc,quick time > players play exactly well.but if i put adif header for the same even > VLC 8.5 doen't play.would i do somthing special to play this in > vlc....please guide me experts...expecting replies asap... > > Thanks in advance > Gomathi > _______________________________________________ > 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 > > Send instant messages to your online friends http://uk.messenger.yahoo.com > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ 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 From rickard.sjoberg ericsson.com Wed Nov 22 14:35:46 2006 From: rickard.sjoberg ericsson.com (=?iso-8859-1?Q?Rickard_Sj=F6berg_=28KI/EAB=29?=) Date: Wed Nov 22 13:52:09 2006 Subject: [Mp4-tech] Regarding padding in MPEG-4 part 2 Message-ID: <6BEB5EE4BAF7EB4EA6CC5CEC2AB38546049E30DB@esealmw103.eemea.ericsson.se> Dear experts, assume that a simple profile video stream with height and width of 120 and 170 pixels respectively shall be decoded. The bounding rectangle of the reference VOP is 128x176. Now my question is whether you should pad outside of 120x170 or 128x176 when referencing pixels for motion compensation? The relevant part of the standard is section 7.6.4 i believe (I looking at the 3rd edition, that's ISO/IEC 14496-2:2004, N5515): The coordinates of a reference sample in the reference VOP, (yref, xref) is determined as follows : xref = MIN ( MAX (xcurr+dx, vhmcsr), xdim+vhmcsr-1 ) yref = MIN ( MAX (ycurr+dy, vvmcsr), ydim+vvmcsr-1) My interpretation of this is that padding should be done outside of 128x176 (this means that the pixels outside of 120x170 but inside of 128x176 shall be left as they were decoded), is this correct? Is there any conformance bitstream that tests this behaviour? / Rickard Sjoberg Ericsson From garysull windows.microsoft.com Wed Nov 22 06:32:57 2006 From: garysull windows.microsoft.com (Gary Sullivan) Date: Wed Nov 22 14:40:08 2006 Subject: [Mp4-tech] Regarding padding in MPEG-4 part 2 In-Reply-To: <6BEB5EE4BAF7EB4EA6CC5CEC2AB38546049E30DB@esealmw103.eemea.ericsson.se> Message-ID: <03CB47D9C3F8074498E4653F814D6E8F02ED4EC7@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> Rickard et al, For a long time, I was pretty sure that I knew what the answer was, and my interpretation agreed with yours. Certainly that is the way the similar feature works in H.263 (although that fact is not directly relevant to the question at hand, since "motion vectors over picture boundaries" is a non-Baseline feature of H.263 Annex D, while MPEG-4 part 2 only tries to be compatible with the Baseline). I vaguely recall that at one time one implementation of the reference software was doing it one way and the other was doing it the other way, and I believe MPEG eventually approved a corrigendum to Part 2 and a bug fix to the software to clarify it. Unfortunately, I believe the clarification was according to the other interpretation. There was a corrigendum finalized in 2004, which I think corresponded to MPEG output document N6362. I believe this subject was addressed in that corrigendum. If I was making an encoder, I might design it to avoid motion vectors reaching beyond the bottom and right edges of the reference pictures to be sure that I would work with decoders that used either interpretation. I guess another decent encoder approach would be to use padding in the source for those areas before encoding too, so that the only difference between the two interpretations would be the quantization error. With that approach, a little drift might not produce very bad artifacts. Best Regards, Gary Sullivan +> -----Original Message----- +> From: mp4-tech-bounces@lists.mpegif.org +> [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of +> Rickard Sj?berg (KI/EAB) +> Sent: Wednesday, November 22, 2023 5:36 AM +> To: mp4-tech@lists.mpegif.org +> Subject: [Mp4-tech] Regarding padding in MPEG-4 part 2 +> +> +> Dear experts, +> +> assume that a simple profile video stream with height and +> width of 120 and 170 pixels respectively shall be decoded. +> The bounding rectangle of the reference VOP is 128x176. Now +> my question is whether you should pad outside of 120x170 or +> 128x176 when referencing pixels for motion compensation? +> +> The relevant part of the standard is section 7.6.4 i believe +> (I looking at the 3rd edition, that's ISO/IEC 14496-2:2004, N5515): +> +> The coordinates of a reference sample in the reference VOP, +> (yref, xref) is determined as follows : +> xref = MIN ( MAX (xcurr+dx, vhmcsr), xdim+vhmcsr-1 ) +> yref = MIN ( MAX (ycurr+dy, vvmcsr), ydim+vvmcsr-1) +> +> My interpretation of this is that padding should be done +> outside of 128x176 (this means that the pixels outside of +> 120x170 but inside of 128x176 shall be left as they were +> decoded), is this correct? +> +> Is there any conformance bitstream that tests this behaviour? +> +> / +> Rickard Sjoberg +> Ericsson +> +> _______________________________________________ +> 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 +> From fful conncoll.edu Wed Nov 22 08:48:47 2006 From: fful conncoll.edu (Frank Fulchiero) Date: Wed Nov 22 15:28:06 2006 Subject: [Mp4-tech] youtube In-Reply-To: <456401A9.2000102@ltu.se> References: <200611211707.kALH7XRg011690@lists1.magma.ca> <380E76DA-042F-4282-ABDA-F4677B25F6A2@conncoll.edu> <006901c70dba$337e6cb0$6401a8c0@FERGUSON> <456401A9.2000102@ltu.se> Message-ID: <78E00119-1CFA-480A-BDD3-DC23567A3535@conncoll.edu> Yes, I forgot to say, that could be the other reason, or a combination of both. But there is no charge, I believe, if you stay under a certain amount/ purpose. Never could understand the pricing structure clearly. Frank Fulchero Digital Media Specialist Connecticut College On Nov 22, 2006, at 2:52 AM, Peter Parnes wrote: >> Why not H264? >> What's the reason for using proprietary codecs? > > A guess. MPEG-LA? I.e. they have to pay royalties for patents to > use H.264. > > -Peter Parnes, PhD > Associate Professor > Media Technology > Lule? University of Technology From Peter.Parnes ltu.se Wed Nov 22 14:59:57 2006 From: Peter.Parnes ltu.se (Peter Parnes) Date: Wed Nov 22 15:28:13 2006 Subject: [Mp4-tech] youtube In-Reply-To: <78E00119-1CFA-480A-BDD3-DC23567A3535@conncoll.edu> References: <200611211707.kALH7XRg011690@lists1.magma.ca> <380E76DA-042F-4282-ABDA-F4677B25F6A2@conncoll.edu> <006901c70dba$337e6cb0$6401a8c0@FERGUSON> <456401A9.2000102@ltu.se> <78E00119-1CFA-480A-BDD3-DC23567A3535@conncoll.edu> Message-ID: <456457DD.2060308@ltu.se> > But there is no charge, I believe, if you stay under a certain amount/purpose. > Never could understand the pricing structure clearly. There are different levels for the licensing but basically if you have more than 100K users you have to pay up. -Peter Parnes, PhD Associate Professor Media Technology Lule? University of Technology From fful conncoll.edu Wed Nov 22 09:05:14 2006 From: fful conncoll.edu (Frank Fulchiero) Date: Wed Nov 22 15:28:18 2006 Subject: [Mp4-tech] youtube In-Reply-To: <456457DD.2060308@ltu.se> References: <200611211707.kALH7XRg011690@lists1.magma.ca> <380E76DA-042F-4282-ABDA-F4677B25F6A2@conncoll.edu> <006901c70dba$337e6cb0$6401a8c0@FERGUSON> <456401A9.2000102@ltu.se> <78E00119-1CFA-480A-BDD3-DC23567A3535@conncoll.edu> <456457DD.2060308@ltu.se> Message-ID: <3AEEB1ED-43DA-46E9-BF88-8A57D9F69E22@conncoll.edu> Sounds like YouTube would burn up the freebies pretty fast. How are you supposed to keep track of the number of users? Is that unique users for many movies, or one user/one movie? Sorry, I should RTFM, just don't have the time, and we don't anticipate 100K users for our content (yet)! Frank Fulchiero Digital Media Specialist Connecticut Collge On Nov 22, 2006, at 8:59 AM, Peter Parnes wrote: >> But there is no charge, I believe, if you stay under a certain >> amount/purpose. >> Never could understand the pricing structure clearly. > > There are different levels for the licensing but basically if you > have more than 100K users you have to pay up. > > -Peter Parnes, PhD > Associate Professor > Media Technology > Lule? University of Technology From Peter.Parnes ltu.se Wed Nov 22 15:42:07 2006 From: Peter.Parnes ltu.se (Peter Parnes) Date: Wed Nov 22 15:28:22 2006 Subject: [Mp4-tech] youtube In-Reply-To: <3AEEB1ED-43DA-46E9-BF88-8A57D9F69E22@conncoll.edu> References: <200611211707.kALH7XRg011690@lists1.magma.ca> <380E76DA-042F-4282-ABDA-F4677B25F6A2@conncoll.edu> <006901c70dba$337e6cb0$6401a8c0@FERGUSON> <456401A9.2000102@ltu.se> <78E00119-1CFA-480A-BDD3-DC23567A3535@conncoll.edu> <456457DD.2060308@ltu.se> <3AEEB1ED-43DA-46E9-BF88-8A57D9F69E22@conncoll.edu> Message-ID: <456461BF.4080309@ltu.se> The whole licensing system is rather "bad" where it is directed for either streaming or hardware devices. More info can be found here: http://www.mpegla.com/m4v/m4vweb.ppt (slides 8-9). I come from the web conferencing side (Marratech is my company) and the licensing system doesn't really match this business with many active senders and receivers in the same session. We (marratech again) count downloads of our products that contain H264. Of course, the same user can download the same software more than once (it is free). -Peter Parnes, PhD Associate Professor Media Technology Lule? University of Technology From Daniel.Luo thomson.net Wed Nov 22 09:55:37 2006 From: Daniel.Luo thomson.net (Luo Daniel) Date: Wed Nov 22 15:28:30 2006 Subject: [Mp4-tech] Transport stream analyer Message-ID: <8FC831532CEE564AB88AC1D999C29DEB02DACE11@prinsmail01.am.thmulti.com> Dear all, Do you know if there is any free software TS analyzer that can perform buffer verification? Thanks! Jiancong Luo -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061122/6f35eeb4/attachment.html From sagar sarayusoftech.com Thu Nov 23 10:56:13 2006 From: sagar sarayusoftech.com (sagar) Date: Thu Nov 23 07:04:06 2006 Subject: [Mp4-tech] Why only low frequeny is considered in DCT? In-Reply-To: <8FC831532CEE564AB88AC1D999C29DEB02DACE11@prinsmail01.am.thmulti.com> Message-ID: Hi Xperts, I wanted to know when we do DCT ( video preocessing), we only consider the Low frequency elements. Why? DCT is used for taking out spatial reduncies, and DCT is basically used to decorrelate energy in the image. And other fact being low frequency contains high energy, If anybody could answer my question, i would be thankful. Warm Regards, Sagar -----Original Message----- From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org]On Behalf Of Luo Daniel Sent: Wednesday, November 22, 2023 8:26 PM To: mp4-tech@lists.mpegif.org Cc: Luo Daniel Subject: [Mp4-tech] Transport stream analyer Dear all, Do you know if there is any free software TS analyzer that can perform buffer verification? Thanks! Jiancong Luo -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061123/b62a8b59/attachment.html From ashishgupta01 gmail.com Thu Nov 23 11:13:04 2006 From: ashishgupta01 gmail.com (GUPTA, ASHISH) Date: Thu Nov 23 07:04:11 2006 Subject: [Mp4-tech] Information Required for MPEG4 SDK Message-ID: <27a246190611222143i2c32a2c6tc0e4d58d96ec0db3@mail.gmail.com> We are developing an audio-video platform using which we could send a MPEG4 stream to remote clients.We are looking for an SDK which can capture screen on a PC and create a MPEG4 stream for that. Some of the basic question that we need for SDK? 1) Can it capture the desktop (or an application running on it) of a PC along with audio and then convert it into a continuous MPEG4 stream? 2) If yes, then does it guarantee video and audio sync? 3) Is it mandatory to use the some server for pushing the MPEG4 stream to a remote machine or can the stream be directly send without a server? Please let us know if somebody is aware about any such SDK. Thanks, Ashish -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061123/600e255c/attachment.html From garysull windows.microsoft.com Thu Nov 23 02:15:32 2006 From: garysull windows.microsoft.com (Gary Sullivan) Date: Thu Nov 23 10:22:07 2006 Subject: [Mp4-tech] Why only low frequeny is considered in DCT? In-Reply-To: Message-ID: <03CB47D9C3F8074498E4653F814D6E8F02ED5044@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> Sagar et al, It sounds like you have been reading some pooly-written tutorial(s) about how DCT coding works. I have seen some pretty bad descriptions of the concepts of DCT coding. (Hopefully, you won't respond by saying you learned what you know by reading my papers on the subject. :-) One important thing to keep in mind is the difference between what we expect will happen most of the time and what might possibly occur on some specific set of worst-case input data. Actually, when we use DCT coding (e.g., for ordinary JPEG 1 still-image coding), we ordinarily *do* consider *all* frequency components. We transform each block of data and quantize the resulting frequency-domain coefficients - that includes quantization of both the low-frequency and high-frequency components. All of them. Usually that quantization process involves the application of what is known as a "mid-tread" scalar quantizer. In other words, the quantizer is structured such that one of the selectable output reconstruction values is exactly equal to 0. See, for example, the book by Jayant and Noll for some discussion of such quantizers. Actually you can still perform effective data compression even if you use a "mid-rise" quantizer and it will still function just fine for high bit rate coding. But such a design would have difficulty operating at low bit rates, since a mid-rise quantizer tends to have an output entropy exceeding one bit per sample. Anyhow, what happens is that for image and video coding at relatively low bit rates, we can observe that when we apply a mid-tread scalar quantizer to the transform coefficients, we observe that many of the high-frequency components usually end up with a quantized value of 0. That doesn't mean that we force them to be zero. It just means that this is what tends to happen most of the time. So when we use the pdf of the quantized transform coefficients to perform entropy coding of their values, they compress rather well since many of them tend to be equal to 0 most of the time. This is a consequence of the cross-correlation properties of image and video data. Such data tends to contain more low-frequency content than high-frequency content most of the time. Another way to express that is to say that the input data tends to be highly correlated. But the coding technology design does not force that. If you feed a low-correlation input image to a good JPEG coder, it will still be able to represent the image (although it might require more bits to code with reasonable fidelity than a smoother image would). If you want to really understand this stuff, study up on what a KLT is, and perhaps read some things like the book by Jayant and Noll and perhaps the paper by Huang and Shultheiss and perhaps the original papers and books by Rao et al on the development of the DCT. There are probably also lots of other places where such things are described well. Best Regards, Gary Sullivan ________________________________ From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of sagar Sent: Wednesday, November 22, 2023 9:26 PM To: mp4-tech@lists.mpegif.org Subject: [Mp4-tech] Why only low frequeny is considered in DCT? Hi Xperts, I wanted to know when we do DCT ( video preocessing), we only consider the Low frequency elements. Why? DCT is used for taking out spatial reduncies, and DCT is basically used to decorrelate energy in the image. And other fact being low frequency contains high energy, If anybody could answer my question, i would be thankful. Warm Regards, Sagar -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061123/809fb740/attachment.html From garysull windows.microsoft.com Thu Nov 23 02:19:45 2006 From: garysull windows.microsoft.com (Gary Sullivan) Date: Thu Nov 23 10:28:07 2006 Subject: [Mp4-tech] Regarding padding in MPEG-4 part 2 In-Reply-To: <4565739B.3010202@iis.fraunhofer.de> Message-ID: <03CB47D9C3F8074498E4653F814D6E8F02FBF875@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> Have you looked at N6362? Best Regards, -Gary Sullivan +> -----Original Message----- +> From: Herbert Thoma [mailto:herbert.thoma@iis.fraunhofer.de] +> Sent: Thursday, November 23, 2023 2:11 AM +> To: Gary Sullivan +> Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org +> Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 +> +> Gary, Rickard, +> +> I am pretty sure that the padding from 128x176 is the +> correct interpretation +> (meaning that the pixels outside of 120x170 but inside of +> 128x176 shall be left +> as they were decoded). +> +> I remember the discussion in MPEG very well, because I +> originally implemented +> it the other way in my encoder and decoder and changed that +> after the corrigendum. +> +> I don't konw if there are any comformance bitstreams +> available, but I attached +> a few frames of forman cropped to 170x120 and encoded with +> my encoder. (I can +> not guarantee that there are actually motion vectors that +> test the problem +> in there, though.) +> +> Kind regards, +> Herbert. +> +> Gary Sullivan wrote: +> > Rickard et al, +> > +> > For a long time, I was pretty sure that I knew what the +> answer was, and my interpretation agreed +> > with yours. Certainly that is the way the similar feature +> works in H.263 (although that fact is +> > not directly relevant to the question at hand, since +> "motion vectors over picture boundaries" is +> > a non-Baseline feature of H.263 Annex D, while MPEG-4 part +> 2 only tries to be compatible with the +> > Baseline). I vaguely recall that at one time one +> implementation of the reference software was +> > doing it one way and the other was doing it the other way, +> and I believe MPEG eventually approved +> > a corrigendum to Part 2 and a bug fix to the software to +> clarify it. Unfortunately, I believe the +> > clarification was according to the other interpretation. +> > +> > There was a corrigendum finalized in 2004, which I think +> corresponded to MPEG output document +> > N6362. I believe this subject was addressed in that corrigendum. +> > +> > If I was making an encoder, I might design it to avoid +> motion vectors reaching beyond the bottom +> > and right edges of the reference pictures to be sure that +> I would work with decoders that used +> > either interpretation. +> > +> > I guess another decent encoder approach would be to use +> padding in the source for those areas before +> > encoding too, so that the only difference between the two +> interpretations would be the quantization +> > error. With that approach, a little drift might not +> produce very bad artifacts. +> > +> > Best Regards, +> > +> > Gary Sullivan +> > +> > +> -----Original Message----- +> > +> From: mp4-tech-bounces@lists.mpegif.org +> > +> [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of +> > +> Rickard Sj?berg (KI/EAB) +> > +> Sent: Wednesday, November 22, 2023 5:36 AM +> > +> To: mp4-tech@lists.mpegif.org +> > +> Subject: [Mp4-tech] Regarding padding in MPEG-4 part 2 +> > +> +> > +> +> > +> Dear experts, +> > +> +> > +> assume that a simple profile video stream with height and +> > +> width of 120 and 170 pixels respectively shall be decoded. +> > +> The bounding rectangle of the reference VOP is 128x176. Now +> > +> my question is whether you should pad outside of 120x170 or +> > +> 128x176 when referencing pixels for motion compensation? +> > +> +> > +> The relevant part of the standard is section 7.6.4 i believe +> > +> (I looking at the 3rd edition, that's ISO/IEC +> 14496-2:2004, N5515): +> > +> +> > +> The coordinates of a reference sample in the reference VOP, +> > +> (yref, xref) is determined as follows : +> > +> xref = MIN ( MAX (xcurr+dx, vhmcsr), xdim+vhmcsr-1 ) +> > +> yref = MIN ( MAX (ycurr+dy, vvmcsr), ydim+vvmcsr-1) +> > +> +> > +> My interpretation of this is that padding should be done +> > +> outside of 128x176 (this means that the pixels outside of +> > +> 120x170 but inside of 128x176 shall be left as they were +> > +> decoded), is this correct? +> > +> +> > +> Is there any conformance bitstream that tests this behaviour? +> > +> +> > +> / +> > +> Rickard Sjoberg +> > +> Ericsson +> > +> +> > +> _______________________________________________ +> > +> 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-Ant +> itrust.php +> > +> +> -- +> Herbert Thoma +> Head of Video Group +> Multimedia Realtime Systems Department +> Fraunhofer IIS +> Am Wolfsmantel 33, 91058 Erlangen, Germany +> Phone: +49-9131-776-323 +> Fax: +49-9131-776-399 +> email: tma@iis.fhg.de +> www: http://www.iis.fhg.de/ +> From garysull windows.microsoft.com Thu Nov 23 03:49:04 2006 From: garysull windows.microsoft.com (Gary Sullivan) Date: Thu Nov 23 12:04:07 2006 Subject: [Mp4-tech] Regarding padding in MPEG-4 part 2 Message-ID: <03CB47D9C3F8074498E4653F814D6E8F02FBF882@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> Copying Yi-Shin and Jens, who perhaps remember this topic, Actually the action I discussed may have happened longer ago than that. I looked in N6362 and although it touched on some relevant sections (I think including 7.6.3) I did not quite find an answer to the question there. I also looked in N3664 and didn't find it there either. I then looked in the text of the 2nd (2001) edition and although I got a bit confused by what it says in various plances (although I haven't really studied the topic fully yet), I think I found it. What I think I see supports what I said on this thread. At the end of 7.6.4 in the 2nd edition it says the following: xref = MIN ( MAX (xcurr+dx, vhmcsr), xdim+vhmcsr-1 ) yref = MIN ( MAX (ycurr+dy, vvmcsr), ydim+vvmcsr-1 ) and "(ydim, xdim) are the dimensions of the bounding rectangle of the reference VOP" and "Note that for rectangular VOP, a reference VOP is defined by video_object_layer_width and video_object_layer_height." Now we know that video_object_layer_width and video_object_layer_height might not be multiples of 16. Based on those equations and quoted sentences, it sounds to me like padding is applied for any location beyond the rectangle having (width, height) = (video_object_layer_width, video_object_layer_height). This is not something that I am happy about, but I think it is what is currently written and I think there was some historical corrigendum action that changed it to say that. There has been a long history of confusion over this issue. I am not entirely sure that I have read all relevant parts of the spec, but I don't see how the above quoted statements can be interpreted any other way. Best Regards, Gary Sullivan +> -----Original Message----- +> From: Gary Sullivan +> Sent: Thursday, November 23, 2023 2:20 AM +> To: 'Herbert Thoma' +> Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org +> Subject: RE: [Mp4-tech] Regarding padding in MPEG-4 part 2 +> +> Have you looked at N6362? +> +> Best Regards, +> +> -Gary Sullivan +> +> +> -----Original Message----- +> +> From: Herbert Thoma [mailto:herbert.thoma@iis.fraunhofer.de] +> +> Sent: Thursday, November 23, 2023 2:11 AM +> +> To: Gary Sullivan +> +> Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org +> +> Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 +> +> +> +> Gary, Rickard, +> +> +> +> I am pretty sure that the padding from 128x176 is the +> +> correct interpretation +> +> (meaning that the pixels outside of 120x170 but inside of +> +> 128x176 shall be left +> +> as they were decoded). +> +> +> +> I remember the discussion in MPEG very well, because I +> +> originally implemented +> +> it the other way in my encoder and decoder and changed that +> +> after the corrigendum. +> +> +> +> I don't konw if there are any comformance bitstreams +> +> available, but I attached +> +> a few frames of forman cropped to 170x120 and encoded with +> +> my encoder. (I can +> +> not guarantee that there are actually motion vectors that +> +> test the problem +> +> in there, though.) +> +> +> +> Kind regards, +> +> Herbert. +> +> +> +> Gary Sullivan wrote: +> +> > Rickard et al, +> +> > +> +> > For a long time, I was pretty sure that I knew what the +> +> answer was, and my interpretation agreed +> +> > with yours. Certainly that is the way the similar feature +> +> works in H.263 (although that fact is +> +> > not directly relevant to the question at hand, since +> +> "motion vectors over picture boundaries" is +> +> > a non-Baseline feature of H.263 Annex D, while MPEG-4 part +> +> 2 only tries to be compatible with the +> +> > Baseline). I vaguely recall that at one time one +> +> implementation of the reference software was +> +> > doing it one way and the other was doing it the other way, +> +> and I believe MPEG eventually approved +> +> > a corrigendum to Part 2 and a bug fix to the software to +> +> clarify it. Unfortunately, I believe the +> +> > clarification was according to the other interpretation. +> +> > +> +> > There was a corrigendum finalized in 2004, which I think +> +> corresponded to MPEG output document +> +> > N6362. I believe this subject was addressed in that +> corrigendum. +> +> > +> +> > If I was making an encoder, I might design it to avoid +> +> motion vectors reaching beyond the bottom +> +> > and right edges of the reference pictures to be sure that +> +> I would work with decoders that used +> +> > either interpretation. +> +> > +> +> > I guess another decent encoder approach would be to use +> +> padding in the source for those areas before +> +> > encoding too, so that the only difference between the two +> +> interpretations would be the quantization +> +> > error. With that approach, a little drift might not +> +> produce very bad artifacts. +> +> > +> +> > Best Regards, +> +> > +> +> > Gary Sullivan +> +> > +> +> > +> -----Original Message----- +> +> > +> From: mp4-tech-bounces@lists.mpegif.org +> +> > +> [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of +> +> > +> Rickard Sj?berg (KI/EAB) +> +> > +> Sent: Wednesday, November 22, 2023 5:36 AM +> +> > +> To: mp4-tech@lists.mpegif.org +> +> > +> Subject: [Mp4-tech] Regarding padding in MPEG-4 part 2 +> +> > +> +> +> > +> +> +> > +> Dear experts, +> +> > +> +> +> > +> assume that a simple profile video stream with height and +> +> > +> width of 120 and 170 pixels respectively shall be decoded. +> +> > +> The bounding rectangle of the reference VOP is 128x176. Now +> +> > +> my question is whether you should pad outside of 120x170 or +> +> > +> 128x176 when referencing pixels for motion compensation? +> +> > +> +> +> > +> The relevant part of the standard is section 7.6.4 i believe +> +> > +> (I looking at the 3rd edition, that's ISO/IEC +> +> 14496-2:2004, N5515): +> +> > +> +> +> > +> The coordinates of a reference sample in the reference VOP, +> +> > +> (yref, xref) is determined as follows : +> +> > +> xref = MIN ( MAX (xcurr+dx, vhmcsr), xdim+vhmcsr-1 ) +> +> > +> yref = MIN ( MAX (ycurr+dy, vvmcsr), ydim+vvmcsr-1) +> +> > +> +> +> > +> My interpretation of this is that padding should be done +> +> > +> outside of 128x176 (this means that the pixels outside of +> +> > +> 120x170 but inside of 128x176 shall be left as they were +> +> > +> decoded), is this correct? +> +> > +> +> +> > +> Is there any conformance bitstream that tests this behaviour? +> +> > +> +> +> > +> / +> +> > +> Rickard Sjoberg +> +> > +> Ericsson +> +> > +> +> +> > +> _______________________________________________ +> +> > +> 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-Ant +> +> itrust.php +> +> > +> +> +> +> -- +> +> Herbert Thoma +> +> Head of Video Group +> +> Multimedia Realtime Systems Department +> +> Fraunhofer IIS +> +> Am Wolfsmantel 33, 91058 Erlangen, Germany +> +> Phone: +49-9131-776-323 +> +> Fax: +49-9131-776-399 +> +> email: tma@iis.fhg.de +> +> www: http://www.iis.fhg.de/ +> +> From garysull windows.microsoft.com Thu Nov 23 04:05:22 2006 From: garysull windows.microsoft.com (Gary Sullivan) Date: Thu Nov 23 12:16:05 2006 Subject: [Mp4-tech] Regarding padding in MPEG-4 part 2 In-Reply-To: <45658B08.4060000@iis.fhg.de> Message-ID: <03CB47D9C3F8074498E4653F814D6E8F02FBF88A@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> Oops. It sounds like your quotes from a 2004 edition (N5546?) are different than my quotes from the 2001 edition! So maybe something else happened after what I remember happening. Hopefully you're right. I don't like what it said in the 2001 edition. (Don't blame this topic on H.263+. I think there was never any confusion about the definition of this aspect of that standard. I think.) Best Regards, Gary Sullivan +> -----Original Message----- +> From: Herbert Thoma [mailto:tma@iis.fhg.de] +> Sent: Thursday, November 23, 2023 3:51 AM +> To: Gary Sullivan +> Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org +> Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 +> +> Gary Sullivan wrote: +> > Have you looked at N6362? +> +> I just did. The only item about padding I see is +> "In subclause 7.6.4, clarify the padding process in case of +> interlaced sequences" +> +> We keep the sentence: "... A bounding rectangle is defined +> by vop_width and +> vop_height extended to multiple of 16 ..." +> +> And in ISO/IEC 14496-2:2004 subclause 7.6.4 states later: +> "... Note that for a rectangular VOP, a reference VOP is defined by +> video_object_layer_width and video_object_layer_height, extended to +> a multiple of 16 ..." +> +> So I don't think that we changed anything regarding padding +> with N6362. +> +> Things were so easy with H.263: you got SQCIF, QCIF, CIF, +> 4CIF and 16CIF. +> That's it, and all are multiples of 16. With H.263+ we got +> custom picture +> formats ... +> +> Kind Regards, +> Herbert. +> +> > Best Regards, +> > +> > -Gary Sullivan +> > +> > +> -----Original Message----- +> > +> From: Herbert Thoma [mailto:herbert.thoma@iis.fraunhofer.de] +> > +> Sent: Thursday, November 23, 2023 2:11 AM +> > +> To: Gary Sullivan +> > +> Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org +> > +> Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 +> > +> +> > +> Gary, Rickard, +> > +> +> > +> I am pretty sure that the padding from 128x176 is the +> > +> correct interpretation +> > +> (meaning that the pixels outside of 120x170 but inside of +> > +> 128x176 shall be left +> > +> as they were decoded). +> > +> +> > +> I remember the discussion in MPEG very well, because I +> > +> originally implemented +> > +> it the other way in my encoder and decoder and changed that +> > +> after the corrigendum. +> > +> +> > +> I don't konw if there are any comformance bitstreams +> > +> available, but I attached +> > +> a few frames of forman cropped to 170x120 and encoded with +> > +> my encoder. (I can +> > +> not guarantee that there are actually motion vectors that +> > +> test the problem +> > +> in there, though.) +> > +> +> > +> Kind regards, +> > +> Herbert. +> > +> +> > +> Gary Sullivan wrote: +> > +> > Rickard et al, +> > +> > +> > +> > For a long time, I was pretty sure that I knew what the +> > +> answer was, and my interpretation agreed +> > +> > with yours. Certainly that is the way the similar feature +> > +> works in H.263 (although that fact is +> > +> > not directly relevant to the question at hand, since +> > +> "motion vectors over picture boundaries" is +> > +> > a non-Baseline feature of H.263 Annex D, while MPEG-4 part +> > +> 2 only tries to be compatible with the +> > +> > Baseline). I vaguely recall that at one time one +> > +> implementation of the reference software was +> > +> > doing it one way and the other was doing it the other way, +> > +> and I believe MPEG eventually approved +> > +> > a corrigendum to Part 2 and a bug fix to the software to +> > +> clarify it. Unfortunately, I believe the +> > +> > clarification was according to the other interpretation. +> > +> > +> > +> > There was a corrigendum finalized in 2004, which I think +> > +> corresponded to MPEG output document +> > +> > N6362. I believe this subject was addressed in that +> corrigendum. +> > +> > +> > +> > If I was making an encoder, I might design it to avoid +> > +> motion vectors reaching beyond the bottom +> > +> > and right edges of the reference pictures to be sure that +> > +> I would work with decoders that used +> > +> > either interpretation. +> > +> > +> > +> > I guess another decent encoder approach would be to use +> > +> padding in the source for those areas before +> > +> > encoding too, so that the only difference between the two +> > +> interpretations would be the quantization +> > +> > error. With that approach, a little drift might not +> > +> produce very bad artifacts. +> > +> > +> > +> > Best Regards, +> > +> > +> > +> > Gary Sullivan +> > +> > +> > +> > +> -----Original Message----- +> > +> > +> From: mp4-tech-bounces@lists.mpegif.org +> > +> > +> [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of +> > +> > +> Rickard Sj?berg (KI/EAB) +> > +> > +> Sent: Wednesday, November 22, 2023 5:36 AM +> > +> > +> To: mp4-tech@lists.mpegif.org +> > +> > +> Subject: [Mp4-tech] Regarding padding in MPEG-4 part 2 +> > +> > +> +> > +> > +> +> > +> > +> Dear experts, +> > +> > +> +> > +> > +> assume that a simple profile video stream with height and +> > +> > +> width of 120 and 170 pixels respectively shall be decoded. +> > +> > +> The bounding rectangle of the reference VOP is +> 128x176. Now +> > +> > +> my question is whether you should pad outside of +> 120x170 or +> > +> > +> 128x176 when referencing pixels for motion compensation? +> > +> > +> +> > +> > +> The relevant part of the standard is section 7.6.4 +> i believe +> > +> > +> (I looking at the 3rd edition, that's ISO/IEC +> > +> 14496-2:2004, N5515): +> > +> > +> +> > +> > +> The coordinates of a reference sample in the +> reference VOP, +> > +> > +> (yref, xref) is determined as follows : +> > +> > +> xref = MIN ( MAX (xcurr+dx, vhmcsr), xdim+vhmcsr-1 ) +> > +> > +> yref = MIN ( MAX (ycurr+dy, vvmcsr), ydim+vvmcsr-1) +> > +> > +> +> > +> > +> My interpretation of this is that padding should be done +> > +> > +> outside of 128x176 (this means that the pixels outside of +> > +> > +> 120x170 but inside of 128x176 shall be left as they were +> > +> > +> decoded), is this correct? +> > +> > +> +> > +> > +> Is there any conformance bitstream that tests this +> behaviour? +> > +> > +> +> > +> > +> / +> > +> > +> Rickard Sjoberg +> > +> > +> Ericsson +> > +> > +> +> > +> > +> _______________________________________________ +> > +> > +> 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-Ant +> > +> itrust.php +> > +> > +> > +> +> > +> -- +> > +> Herbert Thoma +> > +> Head of Video Group +> > +> Multimedia Realtime Systems Department +> > +> Fraunhofer IIS +> > +> Am Wolfsmantel 33, 91058 Erlangen, Germany +> > +> Phone: +49-9131-776-323 +> > +> Fax: +49-9131-776-399 +> > +> email: tma@iis.fhg.de +> > +> www: http://www.iis.fhg.de/ +> > +> +> > +> +> -- +> Herbert Thoma +> Head of Video Group +> Multimedia Realtime Systems Department +> Fraunhofer IIS +> Am Wolfsmantel 33, 91058 Erlangen, Germany +> Phone: +49-9131-776-323 +> Fax: +49-9131-776-399 +> email: tma@iis.fhg.de +> www: http://www.iis.fhg.de/ +> +> From garysull windows.microsoft.com Thu Nov 23 04:11:28 2006 From: garysull windows.microsoft.com (Gary Sullivan) Date: Thu Nov 23 12:22:09 2006 Subject: [Mp4-tech] Why only low frequeny is considered in DCT? In-Reply-To: <03CB47D9C3F8074498E4653F814D6E8F02ED5044@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <03CB47D9C3F8074498E4653F814D6E8F02FBF88C@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> I want to further clarify my statement saying "So when we use the pdf of the quantized transform coefficients to perform entropy coding of their values, they compress rather well since many of them tend to be equal to 0 most of the time." To be more precise, they compress rather well since the pdf of the quantized transform coefficients is a highly non-uniform distribution and also since the variance of the transform coefficients for high frequencies is much smaller than the variance of the transform coefficients for low frequencies. It is not just a matter of zero values versus non-zero values. In fact there is nothing special about the zero value. It is just one of the values in the pdf and it is only particularly interesting because it is the most common value. What matters most is that 1) small values are much more likely to occur than large values, and 2) low frequencies are much more likely to have large amplitudes than high frequencies. For a more proper understanding, read Jayant & Noll or Huang & Schultheiss or similar stuff. Perhaps I should also correct my poorly-written typing of the phrase "poorly-written". :-) Best Regards, Gary Sullivan ________________________________ From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Gary Sullivan Sent: Thursday, November 23, 2023 2:16 AM To: sagar; mp4-tech@lists.mpegif.org Subject: RE: [Mp4-tech] Why only low frequeny is considered in DCT? Sagar et al, It sounds like you have been reading some pooly-written tutorial(s) about how DCT coding works. I have seen some pretty bad descriptions of the concepts of DCT coding. (Hopefully, you won't respond by saying you learned what you know by reading my papers on the subject. :-) One important thing to keep in mind is the difference between what we expect will happen most of the time and what might possibly occur on some specific set of worst-case input data. Actually, when we use DCT coding (e.g., for ordinary JPEG 1 still-image coding), we ordinarily *do* consider *all* frequency components. We transform each block of data and quantize the resulting frequency-domain coefficients - that includes quantization of both the low-frequency and high-frequency components. All of them. Usually that quantization process involves the application of what is known as a "mid-tread" scalar quantizer. In other words, the quantizer is structured such that one of the selectable output reconstruction values is exactly equal to 0. See, for example, the book by Jayant and Noll for some discussion of such quantizers. Actually you can still perform effective data compression even if you use a "mid-rise" quantizer and it will still function just fine for high bit rate coding. But such a design would have difficulty operating at low bit rates, since a mid-rise quantizer tends to have an output entropy exceeding one bit per sample. Anyhow, what happens is that for image and video coding at relatively low bit rates, we can observe that when we apply a mid-tread scalar quantizer to the transform coefficients, we observe that many of the high-frequency components usually end up with a quantized value of 0. That doesn't mean that we force them to be zero. It just means that this is what tends to happen most of the time. So when we use the pdf of the quantized transform coefficients to perform entropy coding of their values, they compress rather well since many of them tend to be equal to 0 most of the time. This is a consequence of the cross-correlation properties of image and video data. Such data tends to contain more low-frequency content than high-frequency content most of the time. Another way to express that is to say that the input data tends to be highly correlated. But the coding technology design does not force that. If you feed a low-correlation input image to a good JPEG coder, it will still be able to represent the image (although it might require more bits to code with reasonable fidelity than a smoother image would). If you want to really understand this stuff, study up on what a KLT is, and perhaps read some things like the book by Jayant and Noll and perhaps the paper by Huang and Shultheiss and perhaps the original papers and books by Rao et al on the development of the DCT. There are probably also lots of other places where such things are described well. Best Regards, Gary Sullivan ________________________________ From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of sagar Sent: Wednesday, November 22, 2023 9:26 PM To: mp4-tech@lists.mpegif.org Subject: [Mp4-tech] Why only low frequeny is considered in DCT? Hi Xperts, I wanted to know when we do DCT ( video preocessing), we only consider the Low frequency elements. Why? DCT is used for taking out spatial reduncies, and DCT is basically used to decorrelate energy in the image. And other fact being low frequency contains high energy, If anybody could answer my question, i would be thankful. Warm Regards, Sagar -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061123/e027363b/attachment-0001.html From garysull windows.microsoft.com Thu Nov 23 06:08:20 2006 From: garysull windows.microsoft.com (Gary Sullivan) Date: Thu Nov 23 14:16:13 2006 Subject: [Mp4-tech] Regarding padding in MPEG-4 part 2 In-Reply-To: <45658D10.2060209@iis.fhg.de> Message-ID: <03CB47D9C3F8074498E4653F814D6E8F02FBF894@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> +> I guess this schould make you happy, Gary :-) Yes, I am now *very* happy. So I am happy and Herbert is happy and I hope we are all happy. And thankful. It's Thanksgiving Day, after all. (Although they aren't making a very big deal about that here in Geneva during the closing working party plenaries of the ITU-T SG 16 meeting.) Actually, it appears that my memory was partly wrong. In fact I guess my opinion was the one that actually prevailed on this topic. I found the topic discussed in the list of problem reports found in N4924, saying that I was the one who reported the problem in section 7.6.4. It was noted that section 7.5.1.1 of the standard seemed to support my interpretation although 7.6.4 conflicted with that interpretation. The problem in section 7.6.4 was then promptly corrected as item 8 of the N5158 corrigendum which soon became part of the 3rd edition N5546. Best Regards, Gary Sullivan +> -----Original Message----- +> From: Herbert Thoma [mailto:tma@iis.fhg.de] +> Sent: Thursday, November 23, 2023 3:59 AM +> To: Gary Sullivan +> Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org; +> Tung yi-Shin; Yi-Shin Tung; ohm@ient.rwth-aachen.de +> Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 +> +> Gary, Yi-Shin, Jens, +> +> Please look at the 3rd (2004) edition: +> +> The sentence +> "Note that for rectangular VOP, a reference VOP is defined by +> video_object_layer_width and video_object_layer_height." +> in the 2nd edition was changed to +> "Note that for a rectangular VOP, a reference VOP is defined by +> video_object_layer_width and video_object_layer_height, extended to +> a multiple of 16" +> in the 3rd edition. +> +> I guess this schould make you happy, Gary :-) +> +> Regards, +> Herbert. +> +> Gary Sullivan wrote: +> > Copying Yi-Shin and Jens, who perhaps remember this topic, +> > +> > Actually the action I discussed may have happened longer +> ago than that. I looked in N6362 +> > and although it touched on some relevant sections (I think +> including 7.6.3) I did not quite +> > find an answer to the question there. I also looked in +> N3664 and didn't find it there either. +> > I then looked in the text of the 2nd (2001) edition and +> although I got a bit confused by what it +> > says in various plances (although I haven't really studied +> the topic fully yet), I think I found it. +> > +> > What I think I see supports what I said on this thread. +> At the end of 7.6.4 in the 2nd edition +> > it says the following: +> > +> > xref = MIN ( MAX (xcurr+dx, vhmcsr), xdim+vhmcsr-1 ) +> > yref = MIN ( MAX (ycurr+dy, vvmcsr), ydim+vvmcsr-1 ) +> > +> > and +> > +> > "(ydim, xdim) are the dimensions of the bounding rectangle +> of the reference VOP" +> > +> > and +> > +> > "Note that for rectangular VOP, a reference VOP is defined +> by video_object_layer_width and video_object_layer_height." +> > +> > +> > Now we know that video_object_layer_width and +> video_object_layer_height might not be multiples of 16. +> > +> > Based on those equations and quoted sentences, it sounds +> to me like padding is applied for any location beyond the +> rectangle having (width, height) = +> (video_object_layer_width, video_object_layer_height). +> > +> > This is not something that I am happy about, but I think +> it is what is currently written and I think there was some +> historical corrigendum action that changed it to say that. +> > +> > There has been a long history of confusion over this +> issue. I am not entirely sure that I have read all relevant +> parts of the spec, but I don't see how the above quoted +> statements can be interpreted any other way. +> > +> > Best Regards, +> > +> > Gary Sullivan +> > +> > +> > +> -----Original Message----- +> > +> From: Gary Sullivan +> > +> Sent: Thursday, November 23, 2023 2:20 AM +> > +> To: 'Herbert Thoma' +> > +> Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org +> > +> Subject: RE: [Mp4-tech] Regarding padding in MPEG-4 part 2 +> > +> +> > +> Have you looked at N6362? +> > +> +> > +> Best Regards, +> > +> +> > +> -Gary Sullivan +> > +> +> > +> +> -----Original Message----- +> > +> +> From: Herbert Thoma [mailto:herbert.thoma@iis.fraunhofer.de] +> > +> +> Sent: Thursday, November 23, 2023 2:11 AM +> > +> +> To: Gary Sullivan +> > +> +> Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org +> > +> +> Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 +> > +> +> +> > +> +> Gary, Rickard, +> > +> +> +> > +> +> I am pretty sure that the padding from 128x176 is the +> > +> +> correct interpretation +> > +> +> (meaning that the pixels outside of 120x170 but inside of +> > +> +> 128x176 shall be left +> > +> +> as they were decoded). +> > +> +> +> > +> +> I remember the discussion in MPEG very well, because I +> > +> +> originally implemented +> > +> +> it the other way in my encoder and decoder and changed that +> > +> +> after the corrigendum. +> > +> +> +> > +> +> I don't konw if there are any comformance bitstreams +> > +> +> available, but I attached +> > +> +> a few frames of forman cropped to 170x120 and encoded with +> > +> +> my encoder. (I can +> > +> +> not guarantee that there are actually motion vectors that +> > +> +> test the problem +> > +> +> in there, though.) +> > +> +> +> > +> +> Kind regards, +> > +> +> Herbert. +> > +> +> +> > +> +> Gary Sullivan wrote: +> > +> +> > Rickard et al, +> > +> +> > +> > +> +> > For a long time, I was pretty sure that I knew what the +> > +> +> answer was, and my interpretation agreed +> > +> +> > with yours. Certainly that is the way the similar feature +> > +> +> works in H.263 (although that fact is +> > +> +> > not directly relevant to the question at hand, since +> > +> +> "motion vectors over picture boundaries" is +> > +> +> > a non-Baseline feature of H.263 Annex D, while MPEG-4 part +> > +> +> 2 only tries to be compatible with the +> > +> +> > Baseline). I vaguely recall that at one time one +> > +> +> implementation of the reference software was +> > +> +> > doing it one way and the other was doing it the other way, +> > +> +> and I believe MPEG eventually approved +> > +> +> > a corrigendum to Part 2 and a bug fix to the software to +> > +> +> clarify it. Unfortunately, I believe the +> > +> +> > clarification was according to the other interpretation. +> > +> +> > +> > +> +> > There was a corrigendum finalized in 2004, which I think +> > +> +> corresponded to MPEG output document +> > +> +> > N6362. I believe this subject was addressed in that +> > +> corrigendum. +> > +> +> > +> > +> +> > If I was making an encoder, I might design it to avoid +> > +> +> motion vectors reaching beyond the bottom +> > +> +> > and right edges of the reference pictures to be sure that +> > +> +> I would work with decoders that used +> > +> +> > either interpretation. +> > +> +> > +> > +> +> > I guess another decent encoder approach would be to use +> > +> +> padding in the source for those areas before +> > +> +> > encoding too, so that the only difference between the two +> > +> +> interpretations would be the quantization +> > +> +> > error. With that approach, a little drift might not +> > +> +> produce very bad artifacts. +> > +> +> > +> > +> +> > Best Regards, +> > +> +> > +> > +> +> > Gary Sullivan +> > +> +> > +> > +> +> > +> -----Original Message----- +> > +> +> > +> From: mp4-tech-bounces@lists.mpegif.org +> > +> +> > +> [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of +> > +> +> > +> Rickard Sj?berg (KI/EAB) +> > +> +> > +> Sent: Wednesday, November 22, 2023 5:36 AM +> > +> +> > +> To: mp4-tech@lists.mpegif.org +> > +> +> > +> Subject: [Mp4-tech] Regarding padding in MPEG-4 part 2 +> > +> +> > +> +> > +> +> > +> +> > +> +> > +> Dear experts, +> > +> +> > +> +> > +> +> > +> assume that a simple profile video stream with +> height and +> > +> +> > +> width of 120 and 170 pixels respectively shall +> be decoded. +> > +> +> > +> The bounding rectangle of the reference VOP is +> 128x176. Now +> > +> +> > +> my question is whether you should pad outside +> of 120x170 or +> > +> +> > +> 128x176 when referencing pixels for motion compensation? +> > +> +> > +> +> > +> +> > +> The relevant part of the standard is section +> 7.6.4 i believe +> > +> +> > +> (I looking at the 3rd edition, that's ISO/IEC +> > +> +> 14496-2:2004, N5515): +> > +> +> > +> +> > +> +> > +> The coordinates of a reference sample in the +> reference VOP, +> > +> +> > +> (yref, xref) is determined as follows : +> > +> +> > +> xref = MIN ( MAX (xcurr+dx, vhmcsr), xdim+vhmcsr-1 ) +> > +> +> > +> yref = MIN ( MAX (ycurr+dy, vvmcsr), ydim+vvmcsr-1) +> > +> +> > +> +> > +> +> > +> My interpretation of this is that padding +> should be done +> > +> +> > +> outside of 128x176 (this means that the pixels +> outside of +> > +> +> > +> 120x170 but inside of 128x176 shall be left as +> they were +> > +> +> > +> decoded), is this correct? +> > +> +> > +> +> > +> +> > +> Is there any conformance bitstream that tests +> this behaviour? +> > +> +> > +> +> > +> +> > +> / +> > +> +> > +> Rickard Sjoberg +> > +> +> > +> Ericsson +> > +> +> > +> +> > +> +> > +> _______________________________________________ +> > +> +> > +> 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-Ant +> > +> +> itrust.php +> > +> +> > +> > +> +> +> > +> +> -- +> > +> +> Herbert Thoma +> > +> +> Head of Video Group +> > +> +> Multimedia Realtime Systems Department +> > +> +> Fraunhofer IIS +> > +> +> Am Wolfsmantel 33, 91058 Erlangen, Germany +> > +> +> Phone: +49-9131-776-323 +> > +> +> Fax: +49-9131-776-399 +> > +> +> email: tma@iis.fhg.de +> > +> +> www: http://www.iis.fhg.de/ +> > +> +> +> > +> +> -- +> Herbert Thoma +> Head of Video Group +> Multimedia Realtime Systems Department +> Fraunhofer IIS +> Am Wolfsmantel 33, 91058 Erlangen, Germany +> Phone: +49-9131-776-323 +> Fax: +49-9131-776-399 +> email: tma@iis.fhg.de +> www: http://www.iis.fhg.de/ +> +> From rgomathi sarayusoftech.com Thu Nov 23 12:34:20 2006 From: rgomathi sarayusoftech.com (rgomathi@sarayusoftech.com) Date: Thu Nov 23 15:04:10 2006 Subject: [Mp4-tech] how to play .aac fille with adif header In-Reply-To: <4BF47D56A0DD2346A1B8D622C5C5902C01F683D5@soc-mail.soc-soft.com> References: <4BF47D56A0DD2346A1B8D622C5C5902C01F683D5@soc-mail.soc-soft.com> Message-ID: <39379.212.25.82.227.1164265460.squirrel@203.101.43.195> >Hi Apoorva..... Thanks for your reply..... Actually I'm working in Mp4 file format.In the mpeg systems doc....in object type indication it is given that for 0x6b,0x69 the stream comply to mpeg1 audio and mpeg2 audio.....So once i got that info i came to know that the audio stream is mpeg1 or mpeg2 audio and i'll parse the stream as such without any decoderSpecificInfo as the mpeg1,mpeg2 (layers I,II,III) audio streams itself contains all the info needed for decoder. I do see streams (.mp4 file) with .mp3(inside the moov atom) and there is no esds atom....so how to parse this stream..... is there any more codec like this....please guide me experts ..... Thanks in advance Regards, Gomathi. Hello Gomathi, > > AAC bit stream according to the standard, contains only syntactic > elements (SCE, CPE, LFE, DSE, PCE, FILL, CCE, TERM). So if an AAC > decoder is developed, it will be implemented to support and decode the > syntactic elements compulsorily. Let us call the AAC containing only > syntactic elements as "Raw AAC". > > When we consider ADTS or ADIF, these are headers which provide > information about the bit stream like sampling rate, channels, etc. And > these headers (ADTS, ADIF) are not the only format, AAC bit stream could > be encapsulated in. Raw AAC can even be a part of MP4 transport stream, > in which the data like Sampling rate and channels will be a part of > configuration information. > > So, if a player has AAC decoder but, do not have the implementation to > decode the headers (ADTS, ADIF) then, the player can very well decode > the "Raw AAC" (information of Sampling rate will have to be provided by > the user) but, will not be in a position to decode the AAC with ADTS or > ADIF header. > > Hope this helps, > Apoorva Ankad > > -----Original Message----- > From: rgomathi@sarayusoftech.com [mailto:rgomathi@sarayusoftech.com] > Sent: Wednesday, November 22, 2023 2:37 PM > To: Deshpande, Vishvanath; mp4-tech@lists.mpegif.org; > mp4-tech-request@lists.mpegif.org > Subject: Re: [Mp4-tech] how to play .aac fille with adif header > >> > Hi all.... > Thanks a lot for ur replies.can i know the reason behind why only > certain players could play the .acc with ADIF header.B'coz both ADIF > and ADTS headers can be used to create .aac file in general.I think the > only difference being one time ADIF header for the whole stream and > ADTS for every frame.If i'm correct why the normal players couldn't > play that.is there any special thing the decoder should do to decode > aac stream with adif.....expecting replies... > > Thanks in advance, > > regards, > Gomathi. > > > Hi, >> >> You can use Cool Edit to play that, >> >> -Vishvanath >> >> >> >> ----- Original Message ---- >> From: "rgomathi@sarayusoftech.com" >> To: mp4-tech@lists.mpegif.org; mp4-tech-request@lists.mpegif.org >> Sent: Tuesday, 21 November, 2006 3:58:41 PM >> Subject: [Mp4-tech] how to play .aac fille with adif header >> >> >> Hi all...... >> I badly want to know how to play .aac file with adif header.for the >> same raw data with adts header most of the players like vlc,quick time >> players play exactly well.but if i put adif header for the same even >> VLC 8.5 doen't play.would i do somthing special to play this in >> vlc....please guide me experts...expecting replies asap... >> >> Thanks in advance >> Gomathi >> _______________________________________________ >> 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 >> >> Send instant messages to your online friends > http://uk.messenger.yahoo.com >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >> >> > > _______________________________________________ > 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 > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > From prabhakar.pasunuti gdatech.co.in Thu Nov 23 13:14:39 2006 From: prabhakar.pasunuti gdatech.co.in (prabhakar) Date: Thu Nov 23 15:04:18 2006 Subject: [Mp4-tech] Why only low frequeny is considered in DCT? References: Message-ID: <007501c70ed3$3b01cad0$e800a8c0@prabhakar> It is possible to reconstruct an approximate copy of the block from the low frequency coefficients. Adding more coefficients produces more accurate reconstruction of the original block. Thanks & Regards --------------------------------- P. Prabhakar Digital Video Group GDA Technologies Ltd 32 & 46 North Phase Thiru Ve Ka Industrial Estate Ekkatuthangal Chennai - 600 097 India Email: prabhakar.pasunuti@gdatech.co.in Mobile: 09840517282 Office : 044-30613429 ----- Original Message ----- From: sagar To: mp4-tech@lists.mpegif.org Sent: Thursday, November 23, 2023 10:56 AM Subject: [Mp4-tech] Why only low frequeny is considered in DCT? Hi Xperts, I wanted to know when we do DCT ( video preocessing), we only consider the Low frequency elements. Why? DCT is used for taking out spatial reduncies, and DCT is basically used to decorrelate energy in the image. And other fact being low frequency contains high energy, If anybody could answer my question, i would be thankful. Warm Regards, Sagar -----Original Message----- From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org]On Behalf Of Luo Daniel Sent: Wednesday, November 22, 2023 8:26 PM To: mp4-tech@lists.mpegif.org Cc: Luo Daniel Subject: [Mp4-tech] Transport stream analyer Dear all, Do you know if there is any free software TS analyzer that can perform buffer verification? Thanks! Jiancong Luo -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------------------------------------------------------------------------------ _______________________________________________ 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.1.409 / Virus Database: 268.14.14/547 - Release Date: 11/22/2006 -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061123/1ebe4946/attachment-0001.html From shiva_chikkalli yahoo.com Wed Nov 22 23:38:08 2006 From: shiva_chikkalli yahoo.com (Shivalingappa Chikkalli) Date: Thu Nov 23 15:04:23 2006 Subject: [Mp4-tech] Why only low frequeny is considered in DCT? Message-ID: <20061123073809.5545.qmail@web52510.mail.yahoo.com> Sagar, Let me partially answer to your question: This is because, human eye is more sensitive to the information contained in low frequency DCT coefficients than information contained in High frequency DCT coefficients. Regards, Shiva Chikkalli ----- Original Message ---- From: sagar To: mp4-tech@lists.mpegif.org Sent: Thursday, November 23, 2023 10:56:13 AM Subject: [Mp4-tech] Why only low frequeny is considered in DCT? _filtered { font-family:SimSun; } _filtered { font-family:SimSun; } _filtered {margin:1.0in 1.25in 1.0in 1.25in;} P.MsoNormal { FONT-SIZE:12pt;MARGIN:0in 0in 0pt;FONT-FAMILY:"Times New Roman";} LI.MsoNormal { FONT-SIZE:12pt;MARGIN:0in 0in 0pt;FONT-FAMILY:"Times New Roman";} DIV.MsoNormal { FONT-SIZE:12pt;MARGIN:0in 0in 0pt;FONT-FAMILY:"Times New Roman";} A:link { COLOR:blue;TEXT-DECORATION:underline;} SPAN.MsoHyperlink { COLOR:blue;TEXT-DECORATION:underline;} A:visited { COLOR:purple;TEXT-DECORATION:underline;} SPAN.MsoHyperlinkFollowed { COLOR:purple;TEXT-DECORATION:underline;} SPAN.EmailStyle17 { COLOR:windowtext;FONT-FAMILY:Arial;} DIV.Section1 { } Hi Xperts, I wanted to know when we do DCT ( video preocessing), we only consider the Low frequency elements. Why? DCT is used for taking out spatial reduncies, and DCT is basically used to decorrelate energy in the image. And other fact being low frequency contains high energy, If anybody could answer my question, i would be thankful. Warm Regards, Sagar -----Original Message----- From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org]On Behalf Of Luo Daniel Sent: Wednesday, November 22, 2023 8:26 PM To: mp4-tech@lists.mpegif.org Cc: Luo Daniel Subject: [Mp4-tech] Transport stream analyer Dear all, Do you know if there is any free software TS analyzer that can perform buffer verification? Thanks! Jiancong Luo -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ 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 ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061122/1f5dd9d7/attachment-0001.html From jonas unicorn.tv Thu Nov 23 09:20:53 2006 From: jonas unicorn.tv (Jonas Dahlberg) Date: Thu Nov 23 15:04:28 2006 Subject: [Mp4-tech] youtube In-Reply-To: <456461BF.4080309@ltu.se> References: <200611211707.kALH7XRg011690@lists1.magma.ca> <380E76DA-042F-4282-ABDA-F4677B25F6A2@conncoll.edu> <006901c70dba$337e6cb0$6401a8c0@FERGUSON> <456401A9.2000102@ltu.se> <78E00119-1CFA-480A-BDD3-DC23567A3535@conncoll.edu> <456457DD.2060308@ltu.se> <3AEEB1ED-43DA-46E9-BF88-8A57D9F69E22@conncoll.edu> <456461BF.4080309@ltu.se> Message-ID: <456559E5.5000500@unicorn.tv> Re: PPT Isn't the end of "free" broadcast year 2010? It says 2008 in the PPT. A lot of hassle with these fees though... Peter Parnes wrote: > The whole licensing system is rather "bad" where it is directed for > either streaming or hardware devices. More info can be found here: > http://www.mpegla.com/m4v/m4vweb.ppt (slides 8-9). > > I come from the web conferencing side (Marratech is my company) and > the licensing system doesn't really match this business with many > active senders and receivers in the same session. We (marratech again) > count downloads of our products that contain H264. Of course, the same > user can download the same software more than once (it is free). > > -Peter Parnes, PhD > Associate Professor > Media Technology > Lule? University of Technology > _______________________________________________ > 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 > > From amankar sarnoff.com Thu Nov 23 15:24:53 2006 From: amankar sarnoff.com (Anup Mankar) Date: Thu Nov 23 15:04:34 2006 Subject: [Mp4-tech] Why only low frequeny is considered in DCT? References: Message-ID: <45656FED.5B3EE3A@sarnoff.com> Hi Sagar, To answer your question, let me take you through the very basic reason to perform a transform. 1. How does a transform achieve compression? A. What is compression? Expressing something in the least possible bits. Take for example, a point in a 2D space. We need to have an component along the x-axis and a component along the y-axis. Say we need an integer (32 bits) to store each of these. For simplicity, let's say the max. component fits within those 32 bits. That makes 64 bits. But if we twist the axes such that the point lies on the x-axis, we do not need the component along the y-axis. This is how decorrelation of information takes place in a transform. But if you observe closely, we have successfully eliminated the need for the redundant 32 bits and voila, we've achieved compression. 2. Why the DCT? A. The Kahrunen-Loeve is one such transform which decorrelates information without loss, transforming signal information from the spatial to the frequency domain. But the Markov chain (since we are working in discrete time) involved needs a lot of processing. Hence we make use of the poor lossy cousin, the Type II DCT in real world image processing, majorly due to it's energy compaction property. 3. Why are the lower frequency components more important? A. As described in the answer to the 1st question a transform should ideally allow us to depict the signal information in the least possible components. The DCT by it's nature compacts the energy of the signal into the lower frequency components. Since the least frequency is 0, the DC component is of utmost importance. However the DCT being an approximation to the KLT, we do get components along the other axes. Hence even some non-zero frequency components could retain some signal energy. Hence we perform a zig-zag scan to get the higher energy (low frequency) components so as to preserve maximum information. Hope this answers your query. Regards, Anup -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061123/a99abde5/attachment-0001.html From mp4-tech-owner lists.mpegif.org Thu Nov 23 15:43:38 2006 From: mp4-tech-owner lists.mpegif.org (MPEGIF List Admins) Date: Thu Nov 23 15:04:39 2006 Subject: FW: [Mp4-tech] Regarding padding in MPEG-4 part 2 Message-ID: <000301c70f0d$c36a3ee0$6401a8c0@corp.intertrust.com> Forward of bounced email from non-subscribed address. -----Original Message----- From: Herbert Thoma [mailto:tma@iis.fhg.de] Sent: Thursday, 23 November 2023 11:58 To: mp4-tech@lists.mpegif.org Cc: mp4-tech@lists.mpegif.org Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 Gary, Rickard, I am pretty sure that the padding from 128x176 is the correct interpretation (meaning that the pixels outside of 120x170 but inside of 128x176 shall be left as they were decoded). I remember the discussion in MPEG very well, because I originally implemented it the other way in my encoder and decoder and changed that after the corrigendum. I don't konw if there are any comformance bitstreams available, but I attached a few frames of forman cropped to 170x120 and encoded with my encoder. (I can not guarantee that there are actually motion vectors that test the problem in there, though.) Kind regards, Herbert. Gary Sullivan wrote: > Rickard et al, > > For a long time, I was pretty sure that I knew what the answer was, and my interpretation agreed > with yours. Certainly that is the way the similar feature works in H.263 (although that fact is > not directly relevant to the question at hand, since "motion vectors over picture boundaries" is > a non-Baseline feature of H.263 Annex D, while MPEG-4 part 2 only tries to be compatible with the > Baseline). I vaguely recall that at one time one implementation of the reference software was > doing it one way and the other was doing it the other way, and I believe MPEG eventually approved > a corrigendum to Part 2 and a bug fix to the software to clarify it. Unfortunately, I believe the > clarification was according to the other interpretation. > > There was a corrigendum finalized in 2004, which I think corresponded to MPEG output document > N6362. I believe this subject was addressed in that corrigendum. > > If I was making an encoder, I might design it to avoid motion vectors reaching beyond the bottom > and right edges of the reference pictures to be sure that I would work with decoders that used > either interpretation. > > I guess another decent encoder approach would be to use padding in the source for those areas before > encoding too, so that the only difference between the two interpretations would be the quantization > error. With that approach, a little drift might not produce very bad artifacts. > > Best Regards, > > Gary Sullivan > > +> -----Original Message----- > +> From: mp4-tech-bounces@lists.mpegif.org > +> [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of > +> Rickard Sj?berg (KI/EAB) > +> Sent: Wednesday, November 22, 2023 5:36 AM > +> To: mp4-tech@lists.mpegif.org > +> Subject: [Mp4-tech] Regarding padding in MPEG-4 part 2 > +> > +> > +> Dear experts, > +> > +> assume that a simple profile video stream with height and > +> width of 120 and 170 pixels respectively shall be decoded. > +> The bounding rectangle of the reference VOP is 128x176. Now > +> my question is whether you should pad outside of 120x170 or > +> 128x176 when referencing pixels for motion compensation? > +> > +> The relevant part of the standard is section 7.6.4 i believe > +> (I looking at the 3rd edition, that's ISO/IEC 14496-2:2004, N5515): > +> > +> The coordinates of a reference sample in the reference VOP, > +> (yref, xref) is determined as follows : > +> xref = MIN ( MAX (xcurr+dx, vhmcsr), xdim+vhmcsr-1 ) > +> yref = MIN ( MAX (ycurr+dy, vvmcsr), ydim+vvmcsr-1) > +> > +> My interpretation of this is that padding should be done > +> outside of 128x176 (this means that the pixels outside of > +> 120x170 but inside of 128x176 shall be left as they were > +> decoded), is this correct? > +> > +> Is there any conformance bitstream that tests this behaviour? > +> > +> / > +> Rickard Sjoberg > +> Ericsson > +> > +> _______________________________________________ > +> 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 > -- Herbert Thoma Head of Video Group Multimedia Realtime Systems Department Fraunhofer IIS Am Wolfsmantel 33, 91058 Erlangen, Germany Phone: +49-9131-776-323 Fax: +49-9131-776-399 email: tma@iis.fhg.de www: http://www.iis.fhg.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: forman_crop_170x120.m4v Type: application/octet-stream Size: 4113 bytes Desc: not available Url : /pipermail/mp4-tech/attachments/20061123/bb712dfc/forman_crop_170x120-0001.obj From mp4-tech-owner lists.mpegif.org Thu Nov 23 15:45:13 2006 From: mp4-tech-owner lists.mpegif.org (MPEGIF List Admins) Date: Thu Nov 23 15:04:46 2006 Subject: FW: [Mp4-tech] Regarding padding in MPEG-4 part 2 Message-ID: <000801c70f0d$fcc292f0$6401a8c0@corp.intertrust.com> Another forward. (Herbert - please subscribe with your sending address or send with the subscribed address ... Thanks.) -----Original Message----- From: Herbert Thoma [mailto:tma@iis.fhg.de] Sent: Thursday, 23 November 2023 12:51 To: Gary Sullivan Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 Gary Sullivan wrote: > Have you looked at N6362? I just did. The only item about padding I see is "In subclause 7.6.4, clarify the padding process in case of interlaced sequences" We keep the sentence: "... A bounding rectangle is defined by vop_width and vop_height extended to multiple of 16 ..." And in ISO/IEC 14496-2:2004 subclause 7.6.4 states later: "... Note that for a rectangular VOP, a reference VOP is defined by video_object_layer_width and video_object_layer_height, extended to a multiple of 16 ..." So I don't think that we changed anything regarding padding with N6362. Things were so easy with H.263: you got SQCIF, QCIF, CIF, 4CIF and 16CIF. That's it, and all are multiples of 16. With H.263+ we got custom picture formats ... Kind Regards, Herbert. > Best Regards, > > -Gary Sullivan > > +> -----Original Message----- > +> From: Herbert Thoma [mailto:herbert.thoma@iis.fraunhofer.de] > +> Sent: Thursday, November 23, 2023 2:11 AM > +> To: Gary Sullivan > +> Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org > +> Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 > +> > +> Gary, Rickard, > +> > +> I am pretty sure that the padding from 128x176 is the > +> correct interpretation > +> (meaning that the pixels outside of 120x170 but inside of > +> 128x176 shall be left > +> as they were decoded). > +> > +> I remember the discussion in MPEG very well, because I > +> originally implemented > +> it the other way in my encoder and decoder and changed that > +> after the corrigendum. > +> > +> I don't konw if there are any comformance bitstreams > +> available, but I attached > +> a few frames of forman cropped to 170x120 and encoded with > +> my encoder. (I can > +> not guarantee that there are actually motion vectors that > +> test the problem > +> in there, though.) > +> > +> Kind regards, > +> Herbert. > +> > +> Gary Sullivan wrote: > +> > Rickard et al, > +> > > +> > For a long time, I was pretty sure that I knew what the > +> answer was, and my interpretation agreed > +> > with yours. Certainly that is the way the similar feature > +> works in H.263 (although that fact is > +> > not directly relevant to the question at hand, since > +> "motion vectors over picture boundaries" is > +> > a non-Baseline feature of H.263 Annex D, while MPEG-4 part > +> 2 only tries to be compatible with the > +> > Baseline). I vaguely recall that at one time one > +> implementation of the reference software was > +> > doing it one way and the other was doing it the other way, > +> and I believe MPEG eventually approved > +> > a corrigendum to Part 2 and a bug fix to the software to > +> clarify it. Unfortunately, I believe the > +> > clarification was according to the other interpretation. > +> > > +> > There was a corrigendum finalized in 2004, which I think > +> corresponded to MPEG output document > +> > N6362. I believe this subject was addressed in that corrigendum. > +> > > +> > If I was making an encoder, I might design it to avoid > +> motion vectors reaching beyond the bottom > +> > and right edges of the reference pictures to be sure that > +> I would work with decoders that used > +> > either interpretation. > +> > > +> > I guess another decent encoder approach would be to use > +> padding in the source for those areas before > +> > encoding too, so that the only difference between the two > +> interpretations would be the quantization > +> > error. With that approach, a little drift might not > +> produce very bad artifacts. > +> > > +> > Best Regards, > +> > > +> > Gary Sullivan > +> > > +> > +> -----Original Message----- > +> > +> From: mp4-tech-bounces@lists.mpegif.org > +> > +> [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of > +> > +> Rickard Sj?berg (KI/EAB) > +> > +> Sent: Wednesday, November 22, 2023 5:36 AM > +> > +> To: mp4-tech@lists.mpegif.org > +> > +> Subject: [Mp4-tech] Regarding padding in MPEG-4 part 2 > +> > +> > +> > +> > +> > +> Dear experts, > +> > +> > +> > +> assume that a simple profile video stream with height and > +> > +> width of 120 and 170 pixels respectively shall be decoded. > +> > +> The bounding rectangle of the reference VOP is 128x176. Now > +> > +> my question is whether you should pad outside of 120x170 or > +> > +> 128x176 when referencing pixels for motion compensation? > +> > +> > +> > +> The relevant part of the standard is section 7.6.4 i believe > +> > +> (I looking at the 3rd edition, that's ISO/IEC > +> 14496-2:2004, N5515): > +> > +> > +> > +> The coordinates of a reference sample in the reference VOP, > +> > +> (yref, xref) is determined as follows : > +> > +> xref = MIN ( MAX (xcurr+dx, vhmcsr), xdim+vhmcsr-1 ) > +> > +> yref = MIN ( MAX (ycurr+dy, vvmcsr), ydim+vvmcsr-1) > +> > +> > +> > +> My interpretation of this is that padding should be done > +> > +> outside of 128x176 (this means that the pixels outside of > +> > +> 120x170 but inside of 128x176 shall be left as they were > +> > +> decoded), is this correct? > +> > +> > +> > +> Is there any conformance bitstream that tests this behaviour? > +> > +> > +> > +> / > +> > +> Rickard Sjoberg > +> > +> Ericsson > +> > +> > +> > +> _______________________________________________ > +> > +> 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-Ant > +> itrust.php > +> > > +> > +> -- > +> Herbert Thoma > +> Head of Video Group > +> Multimedia Realtime Systems Department > +> Fraunhofer IIS > +> Am Wolfsmantel 33, 91058 Erlangen, Germany > +> Phone: +49-9131-776-323 > +> Fax: +49-9131-776-399 > +> email: tma@iis.fhg.de > +> www: http://www.iis.fhg.de/ > +> > -- Herbert Thoma Head of Video Group Multimedia Realtime Systems Department Fraunhofer IIS Am Wolfsmantel 33, 91058 Erlangen, Germany Phone: +49-9131-776-323 Fax: +49-9131-776-399 email: tma@iis.fhg.de www: http://www.iis.fhg.de/ From mp4-tech-owner lists.mpegif.org Thu Nov 23 15:45:13 2006 From: mp4-tech-owner lists.mpegif.org (MPEGIF List Admins) Date: Thu Nov 23 15:04:52 2006 Subject: FW: [Mp4-tech] Regarding padding in MPEG-4 part 2 Message-ID: <000701c70f0d$fc6b7240$6401a8c0@corp.intertrust.com> another forward of a bounced email. -----Original Message----- From: Herbert Thoma [mailto:tma@iis.fhg.de] Sent: Thursday, 23 November 2023 12:59 To: Gary Sullivan Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org; Tung yi-Shin; Yi-Shin Tung; ohm@ient.rwth-aachen.de Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 Gary, Yi-Shin, Jens, Please look at the 3rd (2004) edition: The sentence "Note that for rectangular VOP, a reference VOP is defined by video_object_layer_width and video_object_layer_height." in the 2nd edition was changed to "Note that for a rectangular VOP, a reference VOP is defined by video_object_layer_width and video_object_layer_height, extended to a multiple of 16" in the 3rd edition. I guess this schould make you happy, Gary :-) Regards, Herbert. Gary Sullivan wrote: > Copying Yi-Shin and Jens, who perhaps remember this topic, > > Actually the action I discussed may have happened longer ago than that. I looked in N6362 > and although it touched on some relevant sections (I think including 7.6.3) I did not quite > find an answer to the question there. I also looked in N3664 and didn't find it there either. > I then looked in the text of the 2nd (2001) edition and although I got a bit confused by what it > says in various plances (although I haven't really studied the topic fully yet), I think I found it. > > What I think I see supports what I said on this thread. At the end of 7.6.4 in the 2nd edition > it says the following: > > xref = MIN ( MAX (xcurr+dx, vhmcsr), xdim+vhmcsr-1 ) > yref = MIN ( MAX (ycurr+dy, vvmcsr), ydim+vvmcsr-1 ) > > and > > "(ydim, xdim) are the dimensions of the bounding rectangle of the reference VOP" > > and > > "Note that for rectangular VOP, a reference VOP is defined by video_object_layer_width and video_object_layer_height." > > > Now we know that video_object_layer_width and video_object_layer_height might not be multiples of 16. > > Based on those equations and quoted sentences, it sounds to me like padding is applied for any location beyond the rectangle having (width, height) = (video_object_layer_width, video_object_layer_height). > > This is not something that I am happy about, but I think it is what is currently written and I think there was some historical corrigendum action that changed it to say that. > > There has been a long history of confusion over this issue. I am not entirely sure that I have read all relevant parts of the spec, but I don't see how the above quoted statements can be interpreted any other way. > > Best Regards, > > Gary Sullivan > > > +> -----Original Message----- > +> From: Gary Sullivan > +> Sent: Thursday, November 23, 2023 2:20 AM > +> To: 'Herbert Thoma' > +> Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org > +> Subject: RE: [Mp4-tech] Regarding padding in MPEG-4 part 2 > +> > +> Have you looked at N6362? > +> > +> Best Regards, > +> > +> -Gary Sullivan > +> > +> +> -----Original Message----- > +> +> From: Herbert Thoma [mailto:herbert.thoma@iis.fraunhofer.de] > +> +> Sent: Thursday, November 23, 2023 2:11 AM > +> +> To: Gary Sullivan > +> +> Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org > +> +> Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 > +> +> > +> +> Gary, Rickard, > +> +> > +> +> I am pretty sure that the padding from 128x176 is the > +> +> correct interpretation > +> +> (meaning that the pixels outside of 120x170 but inside of > +> +> 128x176 shall be left > +> +> as they were decoded). > +> +> > +> +> I remember the discussion in MPEG very well, because I > +> +> originally implemented > +> +> it the other way in my encoder and decoder and changed that > +> +> after the corrigendum. > +> +> > +> +> I don't konw if there are any comformance bitstreams > +> +> available, but I attached > +> +> a few frames of forman cropped to 170x120 and encoded with > +> +> my encoder. (I can > +> +> not guarantee that there are actually motion vectors that > +> +> test the problem > +> +> in there, though.) > +> +> > +> +> Kind regards, > +> +> Herbert. > +> +> > +> +> Gary Sullivan wrote: > +> +> > Rickard et al, > +> +> > > +> +> > For a long time, I was pretty sure that I knew what the > +> +> answer was, and my interpretation agreed > +> +> > with yours. Certainly that is the way the similar feature > +> +> works in H.263 (although that fact is > +> +> > not directly relevant to the question at hand, since > +> +> "motion vectors over picture boundaries" is > +> +> > a non-Baseline feature of H.263 Annex D, while MPEG-4 part > +> +> 2 only tries to be compatible with the > +> +> > Baseline). I vaguely recall that at one time one > +> +> implementation of the reference software was > +> +> > doing it one way and the other was doing it the other way, > +> +> and I believe MPEG eventually approved > +> +> > a corrigendum to Part 2 and a bug fix to the software to > +> +> clarify it. Unfortunately, I believe the > +> +> > clarification was according to the other interpretation. > +> +> > > +> +> > There was a corrigendum finalized in 2004, which I think > +> +> corresponded to MPEG output document > +> +> > N6362. I believe this subject was addressed in that > +> corrigendum. > +> +> > > +> +> > If I was making an encoder, I might design it to avoid > +> +> motion vectors reaching beyond the bottom > +> +> > and right edges of the reference pictures to be sure that > +> +> I would work with decoders that used > +> +> > either interpretation. > +> +> > > +> +> > I guess another decent encoder approach would be to use > +> +> padding in the source for those areas before > +> +> > encoding too, so that the only difference between the two > +> +> interpretations would be the quantization > +> +> > error. With that approach, a little drift might not > +> +> produce very bad artifacts. > +> +> > > +> +> > Best Regards, > +> +> > > +> +> > Gary Sullivan > +> +> > > +> +> > +> -----Original Message----- > +> +> > +> From: mp4-tech-bounces@lists.mpegif.org > +> +> > +> [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of > +> +> > +> Rickard Sj?berg (KI/EAB) > +> +> > +> Sent: Wednesday, November 22, 2023 5:36 AM > +> +> > +> To: mp4-tech@lists.mpegif.org > +> +> > +> Subject: [Mp4-tech] Regarding padding in MPEG-4 part 2 > +> +> > +> > +> +> > +> > +> +> > +> Dear experts, > +> +> > +> > +> +> > +> assume that a simple profile video stream with height and > +> +> > +> width of 120 and 170 pixels respectively shall be decoded. > +> +> > +> The bounding rectangle of the reference VOP is 128x176. Now > +> +> > +> my question is whether you should pad outside of 120x170 or > +> +> > +> 128x176 when referencing pixels for motion compensation? > +> +> > +> > +> +> > +> The relevant part of the standard is section 7.6.4 i believe > +> +> > +> (I looking at the 3rd edition, that's ISO/IEC > +> +> 14496-2:2004, N5515): > +> +> > +> > +> +> > +> The coordinates of a reference sample in the reference VOP, > +> +> > +> (yref, xref) is determined as follows : > +> +> > +> xref = MIN ( MAX (xcurr+dx, vhmcsr), xdim+vhmcsr-1 ) > +> +> > +> yref = MIN ( MAX (ycurr+dy, vvmcsr), ydim+vvmcsr-1) > +> +> > +> > +> +> > +> My interpretation of this is that padding should be done > +> +> > +> outside of 128x176 (this means that the pixels outside of > +> +> > +> 120x170 but inside of 128x176 shall be left as they were > +> +> > +> decoded), is this correct? > +> +> > +> > +> +> > +> Is there any conformance bitstream that tests this behaviour? > +> +> > +> > +> +> > +> / > +> +> > +> Rickard Sjoberg > +> +> > +> Ericsson > +> +> > +> > +> +> > +> _______________________________________________ > +> +> > +> 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-Ant > +> +> itrust.php > +> +> > > +> +> > +> +> -- > +> +> Herbert Thoma > +> +> Head of Video Group > +> +> Multimedia Realtime Systems Department > +> +> Fraunhofer IIS > +> +> Am Wolfsmantel 33, 91058 Erlangen, Germany > +> +> Phone: +49-9131-776-323 > +> +> Fax: +49-9131-776-399 > +> +> email: tma@iis.fhg.de > +> +> www: http://www.iis.fhg.de/ > +> +> > -- Herbert Thoma Head of Video Group Multimedia Realtime Systems Department Fraunhofer IIS Am Wolfsmantel 33, 91058 Erlangen, Germany Phone: +49-9131-776-323 Fax: +49-9131-776-399 email: tma@iis.fhg.de www: http://www.iis.fhg.de/ From mp4-tech-owner lists.mpegif.org Thu Nov 23 15:56:02 2006 From: mp4-tech-owner lists.mpegif.org (MPEGIF List Admins) Date: Thu Nov 23 15:22:08 2006 Subject: FW: [Mp4-tech] Regarding padding in MPEG-4 part 2 Message-ID: <000901c70f0f$7f015bb0$6401a8c0@corp.intertrust.com> another forward of a bounced email. -----Original Message----- From: Herbert Thoma [mailto:tma@iis.fhg.de] Sent: Thursday, 23 November 2023 12:59 To: Gary Sullivan Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org; Tung yi-Shin; Yi-Shin Tung; ohm@ient.rwth-aachen.de Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 Gary, Yi-Shin, Jens, Please look at the 3rd (2004) edition: The sentence "Note that for rectangular VOP, a reference VOP is defined by video_object_layer_width and video_object_layer_height." in the 2nd edition was changed to "Note that for a rectangular VOP, a reference VOP is defined by video_object_layer_width and video_object_layer_height, extended to a multiple of 16" in the 3rd edition. I guess this schould make you happy, Gary :-) Regards, Herbert. Gary Sullivan wrote: > Copying Yi-Shin and Jens, who perhaps remember this topic, > > Actually the action I discussed may have happened longer ago than that. I looked in N6362 > and although it touched on some relevant sections (I think including 7.6.3) I did not quite > find an answer to the question there. I also looked in N3664 and didn't find it there either. > I then looked in the text of the 2nd (2001) edition and although I got a bit confused by what it > says in various plances (although I haven't really studied the topic fully yet), I think I found it. > > What I think I see supports what I said on this thread. At the end of 7.6.4 in the 2nd edition > it says the following: > > xref = MIN ( MAX (xcurr+dx, vhmcsr), xdim+vhmcsr-1 ) > yref = MIN ( MAX (ycurr+dy, vvmcsr), ydim+vvmcsr-1 ) > > and > > "(ydim, xdim) are the dimensions of the bounding rectangle of the reference VOP" > > and > > "Note that for rectangular VOP, a reference VOP is defined by video_object_layer_width and video_object_layer_height." > > > Now we know that video_object_layer_width and video_object_layer_height might not be multiples of 16. > > Based on those equations and quoted sentences, it sounds to me like padding is applied for any location beyond the rectangle having (width, height) = (video_object_layer_width, video_object_layer_height). > > This is not something that I am happy about, but I think it is what is currently written and I think there was some historical corrigendum action that changed it to say that. > > There has been a long history of confusion over this issue. I am not entirely sure that I have read all relevant parts of the spec, but I don't see how the above quoted statements can be interpreted any other way. > > Best Regards, > > Gary Sullivan > > > +> -----Original Message----- > +> From: Gary Sullivan > +> Sent: Thursday, November 23, 2023 2:20 AM > +> To: 'Herbert Thoma' > +> Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org > +> Subject: RE: [Mp4-tech] Regarding padding in MPEG-4 part 2 > +> > +> Have you looked at N6362? > +> > +> Best Regards, > +> > +> -Gary Sullivan > +> > +> +> -----Original Message----- > +> +> From: Herbert Thoma [mailto:herbert.thoma@iis.fraunhofer.de] > +> +> Sent: Thursday, November 23, 2023 2:11 AM > +> +> To: Gary Sullivan > +> +> Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org > +> +> Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 > +> +> > +> +> Gary, Rickard, > +> +> > +> +> I am pretty sure that the padding from 128x176 is the > +> +> correct interpretation > +> +> (meaning that the pixels outside of 120x170 but inside of > +> +> 128x176 shall be left > +> +> as they were decoded). > +> +> > +> +> I remember the discussion in MPEG very well, because I > +> +> originally implemented > +> +> it the other way in my encoder and decoder and changed that > +> +> after the corrigendum. > +> +> > +> +> I don't konw if there are any comformance bitstreams > +> +> available, but I attached > +> +> a few frames of forman cropped to 170x120 and encoded with > +> +> my encoder. (I can > +> +> not guarantee that there are actually motion vectors that > +> +> test the problem > +> +> in there, though.) > +> +> > +> +> Kind regards, > +> +> Herbert. > +> +> > +> +> Gary Sullivan wrote: > +> +> > Rickard et al, > +> +> > > +> +> > For a long time, I was pretty sure that I knew what the > +> +> answer was, and my interpretation agreed > +> +> > with yours. Certainly that is the way the similar feature > +> +> works in H.263 (although that fact is > +> +> > not directly relevant to the question at hand, since > +> +> "motion vectors over picture boundaries" is > +> +> > a non-Baseline feature of H.263 Annex D, while MPEG-4 part > +> +> 2 only tries to be compatible with the > +> +> > Baseline). I vaguely recall that at one time one > +> +> implementation of the reference software was > +> +> > doing it one way and the other was doing it the other way, > +> +> and I believe MPEG eventually approved > +> +> > a corrigendum to Part 2 and a bug fix to the software to > +> +> clarify it. Unfortunately, I believe the > +> +> > clarification was according to the other interpretation. > +> +> > > +> +> > There was a corrigendum finalized in 2004, which I think > +> +> corresponded to MPEG output document > +> +> > N6362. I believe this subject was addressed in that > +> corrigendum. > +> +> > > +> +> > If I was making an encoder, I might design it to avoid > +> +> motion vectors reaching beyond the bottom > +> +> > and right edges of the reference pictures to be sure that > +> +> I would work with decoders that used > +> +> > either interpretation. > +> +> > > +> +> > I guess another decent encoder approach would be to use > +> +> padding in the source for those areas before > +> +> > encoding too, so that the only difference between the two > +> +> interpretations would be the quantization > +> +> > error. With that approach, a little drift might not > +> +> produce very bad artifacts. > +> +> > > +> +> > Best Regards, > +> +> > > +> +> > Gary Sullivan > +> +> > > +> +> > +> -----Original Message----- > +> +> > +> From: mp4-tech-bounces@lists.mpegif.org > +> +> > +> [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of > +> +> > +> Rickard Sj?berg (KI/EAB) > +> +> > +> Sent: Wednesday, November 22, 2023 5:36 AM > +> +> > +> To: mp4-tech@lists.mpegif.org > +> +> > +> Subject: [Mp4-tech] Regarding padding in MPEG-4 part 2 > +> +> > +> > +> +> > +> > +> +> > +> Dear experts, > +> +> > +> > +> +> > +> assume that a simple profile video stream with height and > +> +> > +> width of 120 and 170 pixels respectively shall be decoded. > +> +> > +> The bounding rectangle of the reference VOP is 128x176. Now > +> +> > +> my question is whether you should pad outside of 120x170 or > +> +> > +> 128x176 when referencing pixels for motion compensation? > +> +> > +> > +> +> > +> The relevant part of the standard is section 7.6.4 i believe > +> +> > +> (I looking at the 3rd edition, that's ISO/IEC > +> +> 14496-2:2004, N5515): > +> +> > +> > +> +> > +> The coordinates of a reference sample in the reference VOP, > +> +> > +> (yref, xref) is determined as follows : > +> +> > +> xref = MIN ( MAX (xcurr+dx, vhmcsr), xdim+vhmcsr-1 ) > +> +> > +> yref = MIN ( MAX (ycurr+dy, vvmcsr), ydim+vvmcsr-1) > +> +> > +> > +> +> > +> My interpretation of this is that padding should be done > +> +> > +> outside of 128x176 (this means that the pixels outside of > +> +> > +> 120x170 but inside of 128x176 shall be left as they were > +> +> > +> decoded), is this correct? > +> +> > +> > +> +> > +> Is there any conformance bitstream that tests this behaviour? > +> +> > +> > +> +> > +> / > +> +> > +> Rickard Sjoberg > +> +> > +> Ericsson > +> +> > +> > +> +> > +> _______________________________________________ > +> +> > +> 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-Ant > +> +> itrust.php > +> +> > > +> +> > +> +> -- > +> +> Herbert Thoma > +> +> Head of Video Group > +> +> Multimedia Realtime Systems Department > +> +> Fraunhofer IIS > +> +> Am Wolfsmantel 33, 91058 Erlangen, Germany > +> +> Phone: +49-9131-776-323 > +> +> Fax: +49-9131-776-399 > +> +> email: tma@iis.fhg.de > +> +> www: http://www.iis.fhg.de/ > +> +> > -- Herbert Thoma Head of Video Group Multimedia Realtime Systems Department Fraunhofer IIS Am Wolfsmantel 33, 91058 Erlangen, Germany Phone: +49-9131-776-323 Fax: +49-9131-776-399 email: tma@iis.fhg.de www: http://www.iis.fhg.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 5774 bytes Desc: not available Url : /pipermail/mp4-tech/attachments/20061123/c3d01c79/winmail-0001.bin From mp4-tech-owner lists.mpegif.org Thu Nov 23 15:56:02 2006 From: mp4-tech-owner lists.mpegif.org (MPEGIF List Admins) Date: Thu Nov 23 15:22:13 2006 Subject: FW: [Mp4-tech] Regarding padding in MPEG-4 part 2 Message-ID: <001101c70f0f$801f00b0$6401a8c0@corp.intertrust.com> Another forward. (Herbert - please subscribe with your sending address or send with the subscribed address ... Thanks.) -----Original Message----- From: Herbert Thoma [mailto:tma@iis.fhg.de] Sent: Thursday, 23 November 2023 12:51 To: Gary Sullivan Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 Gary Sullivan wrote: > Have you looked at N6362? I just did. The only item about padding I see is "In subclause 7.6.4, clarify the padding process in case of interlaced sequences" We keep the sentence: "... A bounding rectangle is defined by vop_width and vop_height extended to multiple of 16 ..." And in ISO/IEC 14496-2:2004 subclause 7.6.4 states later: "... Note that for a rectangular VOP, a reference VOP is defined by video_object_layer_width and video_object_layer_height, extended to a multiple of 16 ..." So I don't think that we changed anything regarding padding with N6362. Things were so easy with H.263: you got SQCIF, QCIF, CIF, 4CIF and 16CIF. That's it, and all are multiples of 16. With H.263+ we got custom picture formats ... Kind Regards, Herbert. > Best Regards, > > -Gary Sullivan > > +> -----Original Message----- > +> From: Herbert Thoma [mailto:herbert.thoma@iis.fraunhofer.de] > +> Sent: Thursday, November 23, 2023 2:11 AM > +> To: Gary Sullivan > +> Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org > +> Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 > +> > +> Gary, Rickard, > +> > +> I am pretty sure that the padding from 128x176 is the > +> correct interpretation > +> (meaning that the pixels outside of 120x170 but inside of > +> 128x176 shall be left > +> as they were decoded). > +> > +> I remember the discussion in MPEG very well, because I > +> originally implemented > +> it the other way in my encoder and decoder and changed that > +> after the corrigendum. > +> > +> I don't konw if there are any comformance bitstreams > +> available, but I attached > +> a few frames of forman cropped to 170x120 and encoded with > +> my encoder. (I can > +> not guarantee that there are actually motion vectors that > +> test the problem > +> in there, though.) > +> > +> Kind regards, > +> Herbert. > +> > +> Gary Sullivan wrote: > +> > Rickard et al, > +> > > +> > For a long time, I was pretty sure that I knew what the > +> answer was, and my interpretation agreed > +> > with yours. Certainly that is the way the similar feature > +> works in H.263 (although that fact is > +> > not directly relevant to the question at hand, since > +> "motion vectors over picture boundaries" is > +> > a non-Baseline feature of H.263 Annex D, while MPEG-4 part > +> 2 only tries to be compatible with the > +> > Baseline). I vaguely recall that at one time one > +> implementation of the reference software was > +> > doing it one way and the other was doing it the other way, > +> and I believe MPEG eventually approved > +> > a corrigendum to Part 2 and a bug fix to the software to > +> clarify it. Unfortunately, I believe the > +> > clarification was according to the other interpretation. > +> > > +> > There was a corrigendum finalized in 2004, which I think > +> corresponded to MPEG output document > +> > N6362. I believe this subject was addressed in that corrigendum. > +> > > +> > If I was making an encoder, I might design it to avoid > +> motion vectors reaching beyond the bottom > +> > and right edges of the reference pictures to be sure that > +> I would work with decoders that used > +> > either interpretation. > +> > > +> > I guess another decent encoder approach would be to use > +> padding in the source for those areas before > +> > encoding too, so that the only difference between the two > +> interpretations would be the quantization > +> > error. With that approach, a little drift might not > +> produce very bad artifacts. > +> > > +> > Best Regards, > +> > > +> > Gary Sullivan > +> > > +> > +> -----Original Message----- > +> > +> From: mp4-tech-bounces@lists.mpegif.org > +> > +> [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of > +> > +> Rickard Sj?berg (KI/EAB) > +> > +> Sent: Wednesday, November 22, 2023 5:36 AM > +> > +> To: mp4-tech@lists.mpegif.org > +> > +> Subject: [Mp4-tech] Regarding padding in MPEG-4 part 2 > +> > +> > +> > +> > +> > +> Dear experts, > +> > +> > +> > +> assume that a simple profile video stream with height and > +> > +> width of 120 and 170 pixels respectively shall be decoded. > +> > +> The bounding rectangle of the reference VOP is 128x176. Now > +> > +> my question is whether you should pad outside of 120x170 or > +> > +> 128x176 when referencing pixels for motion compensation? > +> > +> > +> > +> The relevant part of the standard is section 7.6.4 i believe > +> > +> (I looking at the 3rd edition, that's ISO/IEC > +> 14496-2:2004, N5515): > +> > +> > +> > +> The coordinates of a reference sample in the reference VOP, > +> > +> (yref, xref) is determined as follows : > +> > +> xref = MIN ( MAX (xcurr+dx, vhmcsr), xdim+vhmcsr-1 ) > +> > +> yref = MIN ( MAX (ycurr+dy, vvmcsr), ydim+vvmcsr-1) > +> > +> > +> > +> My interpretation of this is that padding should be done > +> > +> outside of 128x176 (this means that the pixels outside of > +> > +> 120x170 but inside of 128x176 shall be left as they were > +> > +> decoded), is this correct? > +> > +> > +> > +> Is there any conformance bitstream that tests this behaviour? > +> > +> > +> > +> / > +> > +> Rickard Sjoberg > +> > +> Ericsson > +> > +> > +> > +> _______________________________________________ > +> > +> 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-Ant > +> itrust.php > +> > > +> > +> -- > +> Herbert Thoma > +> Head of Video Group > +> Multimedia Realtime Systems Department > +> Fraunhofer IIS > +> Am Wolfsmantel 33, 91058 Erlangen, Germany > +> Phone: +49-9131-776-323 > +> Fax: +49-9131-776-399 > +> email: tma@iis.fhg.de > +> www: http://www.iis.fhg.de/ > +> > -- Herbert Thoma Head of Video Group Multimedia Realtime Systems Department Fraunhofer IIS Am Wolfsmantel 33, 91058 Erlangen, Germany Phone: +49-9131-776-323 Fax: +49-9131-776-399 email: tma@iis.fhg.de www: http://www.iis.fhg.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 4986 bytes Desc: not available Url : /pipermail/mp4-tech/attachments/20061123/8582537e/winmail-0001.bin From mp4-tech-owner lists.mpegif.org Thu Nov 23 15:56:02 2006 From: mp4-tech-owner lists.mpegif.org (MPEGIF List Admins) Date: Thu Nov 23 15:22:18 2006 Subject: FW: [Mp4-tech] Regarding padding in MPEG-4 part 2 Message-ID: <000d01c70f0f$7fadef60$6401a8c0@corp.intertrust.com> Forward of bounced email from non-subscribed address. -----Original Message----- From: Herbert Thoma [mailto:tma@iis.fhg.de] Sent: Thursday, 23 November 2023 11:58 To: mp4-tech@lists.mpegif.org Cc: mp4-tech@lists.mpegif.org Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 Gary, Rickard, I am pretty sure that the padding from 128x176 is the correct interpretation (meaning that the pixels outside of 120x170 but inside of 128x176 shall be left as they were decoded). I remember the discussion in MPEG very well, because I originally implemented it the other way in my encoder and decoder and changed that after the corrigendum. I don't konw if there are any comformance bitstreams available, but I attached a few frames of forman cropped to 170x120 and encoded with my encoder. (I can not guarantee that there are actually motion vectors that test the problem in there, though.) Kind regards, Herbert. Gary Sullivan wrote: > Rickard et al, > > For a long time, I was pretty sure that I knew what the answer was, and my interpretation agreed > with yours. Certainly that is the way the similar feature works in H.263 (although that fact is > not directly relevant to the question at hand, since "motion vectors over picture boundaries" is > a non-Baseline feature of H.263 Annex D, while MPEG-4 part 2 only tries to be compatible with the > Baseline). I vaguely recall that at one time one implementation of the reference software was > doing it one way and the other was doing it the other way, and I believe MPEG eventually approved > a corrigendum to Part 2 and a bug fix to the software to clarify it. Unfortunately, I believe the > clarification was according to the other interpretation. > > There was a corrigendum finalized in 2004, which I think corresponded to MPEG output document > N6362. I believe this subject was addressed in that corrigendum. > > If I was making an encoder, I might design it to avoid motion vectors reaching beyond the bottom > and right edges of the reference pictures to be sure that I would work with decoders that used > either interpretation. > > I guess another decent encoder approach would be to use padding in the source for those areas before > encoding too, so that the only difference between the two interpretations would be the quantization > error. With that approach, a little drift might not produce very bad artifacts. > > Best Regards, > > Gary Sullivan > > +> -----Original Message----- > +> From: mp4-tech-bounces@lists.mpegif.org > +> [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of > +> Rickard Sj?berg (KI/EAB) > +> Sent: Wednesday, November 22, 2023 5:36 AM > +> To: mp4-tech@lists.mpegif.org > +> Subject: [Mp4-tech] Regarding padding in MPEG-4 part 2 > +> > +> > +> Dear experts, > +> > +> assume that a simple profile video stream with height and > +> width of 120 and 170 pixels respectively shall be decoded. > +> The bounding rectangle of the reference VOP is 128x176. Now > +> my question is whether you should pad outside of 120x170 or > +> 128x176 when referencing pixels for motion compensation? > +> > +> The relevant part of the standard is section 7.6.4 i believe > +> (I looking at the 3rd edition, that's ISO/IEC 14496-2:2004, N5515): > +> > +> The coordinates of a reference sample in the reference VOP, > +> (yref, xref) is determined as follows : > +> xref = MIN ( MAX (xcurr+dx, vhmcsr), xdim+vhmcsr-1 ) > +> yref = MIN ( MAX (ycurr+dy, vvmcsr), ydim+vvmcsr-1) > +> > +> My interpretation of this is that padding should be done > +> outside of 128x176 (this means that the pixels outside of > +> 120x170 but inside of 128x176 shall be left as they were > +> decoded), is this correct? > +> > +> Is there any conformance bitstream that tests this behaviour? > +> > +> / > +> Rickard Sjoberg > +> Ericsson > +> > +> _______________________________________________ > +> 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 > -- Herbert Thoma Head of Video Group Multimedia Realtime Systems Department Fraunhofer IIS Am Wolfsmantel 33, 91058 Erlangen, Germany Phone: +49-9131-776-323 Fax: +49-9131-776-399 email: tma@iis.fhg.de www: http://www.iis.fhg.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 9030 bytes Desc: not available Url : /pipermail/mp4-tech/attachments/20061123/8ebe6161/winmail-0001.bin From garysull windows.microsoft.com Thu Nov 23 18:55:33 2006 From: garysull windows.microsoft.com (Gary Sullivan) Date: Fri Nov 24 03:04:06 2006 Subject: [Mp4-tech] Regarding padding in MPEG-4 part 2 In-Reply-To: <00ed01c70f6e$f6c2a8c0$0301a8c0@cmls7> Message-ID: <03CB47D9C3F8074498E4653F814D6E8F02FBF8D3@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> Yi-Shen, I think it is a great idea to check whether the conformance bitstreams test this feature, and to fix that someday if they don't. Best Regards, -Gary Sullivan +> -----Original Message----- +> From: Yi-Shin Tung [mailto:tung@setabox.com.tw] +> Sent: Thursday, November 23, 2023 6:19 PM +> To: Herbert Thoma; Gary Sullivan +> Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org; +> Tung yi-Shin; ohm@ient.rwth-aachen.de +> Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 +> +> Hi Rickard, Gary, Herbert and Jens, +> +> I think both versions of RefSW had been changed to +> consistent with what +> specified in the 3rd version. +> +> I do not remember there exists some bitstreams available for +> this test in +> the current conformance set. If you can provide some, I +> could put them in +> the extended list in the future. +> +> Regards, +> Yi-Shin +> +> ----- Original Message ----- +> From: "Herbert Thoma" +> To: "Gary Sullivan" +> Cc: ""Rickard Sj?berg (KI/EAB)"" ; +> ; "Tung yi-Shin" +> ; +> "Yi-Shin Tung" ; +> Sent: Thursday, November 23, 2023 7:59 PM +> Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 +> +> +> > Gary, Yi-Shin, Jens, +> > +> > Please look at the 3rd (2004) edition: +> > +> > The sentence +> > "Note that for rectangular VOP, a reference VOP is defined by +> > video_object_layer_width and video_object_layer_height." +> > in the 2nd edition was changed to +> > "Note that for a rectangular VOP, a reference VOP is defined by +> > video_object_layer_width and video_object_layer_height, extended to +> > a multiple of 16" +> > in the 3rd edition. +> > +> > I guess this schould make you happy, Gary :-) +> > +> > Regards, +> > Herbert. +> > +> > Gary Sullivan wrote: +> >> Copying Yi-Shin and Jens, who perhaps remember this topic, +> >> +> >> Actually the action I discussed may have happened longer +> ago than that. +> >> I looked in N6362 +> >> and although it touched on some relevant sections (I +> think including +> >> 7.6.3) I did not quite +> >> find an answer to the question there. I also looked in +> N3664 and didn't +> >> find it there either. +> >> I then looked in the text of the 2nd (2001) edition and +> although I got a +> >> bit confused by what it +> >> says in various plances (although I haven't really +> studied the topic +> >> fully yet), I think I found it. +> >> +> >> What I think I see supports what I said on this thread. +> At the end of +> >> 7.6.4 in the 2nd edition +> >> it says the following: +> >> +> >> xref = MIN ( MAX (xcurr+dx, vhmcsr), xdim+vhmcsr-1 ) +> yref = MIN ( MAX +> >> (ycurr+dy, vvmcsr), ydim+vvmcsr-1 ) +> >> +> >> and +> >> +> >> "(ydim, xdim) are the dimensions of the bounding rectangle of the +> >> reference VOP" +> >> +> >> and +> >> +> >> "Note that for rectangular VOP, a reference VOP is defined by +> >> video_object_layer_width and video_object_layer_height." +> >> +> >> +> >> Now we know that video_object_layer_width and +> video_object_layer_height +> >> might not be multiples of 16. +> >> +> >> Based on those equations and quoted sentences, it sounds +> to me like +> >> padding is applied for any location beyond the rectangle +> having (width, +> >> height) = (video_object_layer_width, video_object_layer_height). +> >> +> >> This is not something that I am happy about, but I think +> it is what is +> >> currently written and I think there was some historical +> corrigendum +> >> action that changed it to say that. +> >> +> >> There has been a long history of confusion over this +> issue. I am not +> >> entirely sure that I have read all relevant parts of the +> spec, but I +> >> don't see how the above quoted statements can be +> interpreted any other +> >> way. +> >> +> >> Best Regards, +> >> +> >> Gary Sullivan +> >> +> >> +> >> +> -----Original Message----- +> >> +> From: Gary Sullivan +> Sent: Thursday, November 23, +> 2006 2:20 AM +> >> +> To: 'Herbert Thoma' +> >> +> Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org +> >> +> Subject: RE: [Mp4-tech] Regarding padding in MPEG-4 part 2 +> >> +> +> Have you looked at N6362? +> >> +> +> Best Regards, +> >> +> +> -Gary Sullivan +> >> +> +> +> -----Original Message----- +> >> +> +> From: Herbert Thoma +> [mailto:herbert.thoma@iis.fraunhofer.de] +> +> +> >> Sent: Thursday, November 23, 2023 2:11 AM +> >> +> +> To: Gary Sullivan +> >> +> +> Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org +> >> +> +> Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 +> >> +> +> +> +> Gary, Rickard, +> >> +> +> +> +> I am pretty sure that the padding from +> 128x176 is the +> +> +> >> correct interpretation +> >> +> +> (meaning that the pixels outside of 120x170 but +> inside of +> +> +> >> 128x176 shall be left +> >> +> +> as they were decoded). +> >> +> +> +> +> I remember the discussion in MPEG very well, +> because I +> +> +> >> originally implemented +> >> +> +> it the other way in my encoder and decoder and +> changed that +> +> +> >> after the corrigendum. +> >> +> +> +> +> I don't konw if there are any comformance +> bitstreams +> +> +> >> available, but I attached +> >> +> +> a few frames of forman cropped to 170x120 and +> encoded with +> +> my +> >> encoder. (I can +> >> +> +> not guarantee that there are actually motion +> vectors that +> +> +> >> test the problem +> >> +> +> in there, though.) +> >> +> +> +> +> Kind regards, +> >> +> +> Herbert. +> >> +> +> +> +> Gary Sullivan wrote: +> >> +> +> > Rickard et al, +> >> +> +> > +> +> > For a long time, I was pretty sure that I +> knew what the +> >> +> +> answer was, and my interpretation agreed +> >> +> +> > with yours. Certainly that is the way the +> similar feature +> +> +> >> works in H.263 (although that fact is +> >> +> +> > not directly relevant to the question at hand, +> since +> +> +> >> "motion vectors over picture boundaries" is +> >> +> +> > a non-Baseline feature of H.263 Annex D, while +> MPEG-4 part +> +> +> >> 2 only tries to be compatible with the +> >> +> +> > Baseline). I vaguely recall that at one time one +> +> +> >> implementation of the reference software was +> >> +> +> > doing it one way and the other was doing it the +> other way, +> +> +> >> and I believe MPEG eventually approved +> >> +> +> > a corrigendum to Part 2 and a bug fix to the +> software to +> +> +> >> clarify it. Unfortunately, I believe the +> >> +> +> > clarification was according to the other interpretation. +> >> +> +> > +> +> > There was a corrigendum finalized in +> 2004, which I think +> >> +> +> corresponded to MPEG output document +> >> +> +> > N6362. I believe this subject was addressed in that +> +> >> corrigendum. +> >> +> +> > +> +> > If I was making an encoder, I might +> design it to avoid +> +> >> +> motion vectors reaching beyond the bottom +> >> +> +> > and right edges of the reference pictures to be +> sure that +> +> I +> >> would work with decoders that used +> >> +> +> > either interpretation. +> +> > +> +> > I guess +> another decent +> >> encoder approach would be to use +> +> padding in the +> source for those +> >> areas before +> >> +> +> > encoding too, so that the only difference between +> the two +> +> +> >> interpretations would be the quantization +> >> +> +> > error. With that approach, a little drift might +> not +> +> +> >> produce very bad artifacts. +> >> +> +> > +> +> > Best Regards, +> >> +> +> > +> +> > Gary Sullivan +> >> +> +> > +> +> > +> -----Original Message----- +> >> +> +> > +> From: mp4-tech-bounces@lists.mpegif.org +> +> > +> +> >> [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of +> +> +> > +> +> >> Rickard Sj?berg (KI/EAB) +> >> +> +> > +> Sent: Wednesday, November 22, 2023 5:36 AM +> >> +> +> > +> To: mp4-tech@lists.mpegif.org +> >> +> +> > +> Subject: [Mp4-tech] Regarding padding in MPEG-4 part 2 +> >> +> +> > +> +> +> > +> +> +> > +> Dear experts, +> >> +> +> > +> +> +> > +> assume that a simple profile video +> stream with +> >> height and +> +> > +> width of 120 and 170 pixels +> respectively shall be +> >> decoded. +> +> > +> The bounding rectangle of the +> reference VOP is +> >> 128x176. Now +> +> > +> my question is whether you should +> pad outside of +> >> 120x170 or +> +> > +> 128x176 when referencing pixels for motion +> >> compensation? +> >> +> +> > +> +> +> > +> The relevant part of the standard +> is section 7.6.4 +> >> i believe +> +> > +> (I looking at the 3rd edition, +> that's ISO/IEC +> +> +> >> 14496-2:2004, N5515): +> >> +> +> > +> +> +> > +> The coordinates of a reference +> sample in the +> >> reference VOP, +> +> > +> (yref, xref) is determined as follows : +> >> +> +> > +> xref = MIN ( MAX (xcurr+dx, vhmcsr), xdim+vhmcsr-1 ) +> >> +> +> > +> yref = MIN ( MAX (ycurr+dy, vvmcsr), ydim+vvmcsr-1) +> >> +> +> > +> +> +> > +> My interpretation of this is that +> padding should be +> >> done +> +> > +> outside of 128x176 (this means that the +> pixels outside of +> >> +> +> > +> 120x170 but inside of 128x176 shall be left as +> they were +> +> +> >> > +> decoded), is this correct? +> >> +> +> > +> +> +> > +> Is there any conformance bitstream +> that tests this +> >> behaviour? +> >> +> +> > +> +> +> > +> / +> >> +> +> > +> Rickard Sjoberg +> >> +> +> > +> Ericsson +> >> +> +> > +> +> +> > +> +> _______________________________________________ +> >> +> +> > +> 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-Ant +> >> +> +> itrust.php +> >> +> +> > +> +> +> +> -- +> >> +> +> Herbert Thoma +> >> +> +> Head of Video Group +> >> +> +> Multimedia Realtime Systems Department +> >> +> +> Fraunhofer IIS +> >> +> +> Am Wolfsmantel 33, 91058 Erlangen, Germany +> >> +> +> Phone: +49-9131-776-323 +> >> +> +> Fax: +49-9131-776-399 +> >> +> +> email: tma@iis.fhg.de +> >> +> +> www: http://www.iis.fhg.de/ +> >> +> +> +> > +> > -- +> > Herbert Thoma +> > Head of Video Group +> > Multimedia Realtime Systems Department +> > Fraunhofer IIS +> > Am Wolfsmantel 33, 91058 Erlangen, Germany +> > Phone: +49-9131-776-323 +> > Fax: +49-9131-776-399 +> > email: tma@iis.fhg.de +> > www: http://www.iis.fhg.de/ +> > +> +> +> +> From kaustubh.patankar vsnl.net Fri Nov 24 07:14:30 2006 From: kaustubh.patankar vsnl.net (kaustubh.patankar@vsnl.net) Date: Fri Nov 24 13:52:09 2006 Subject: [Mp4-tech] Why only low frequeny is considered in DCT? In-Reply-To: <007501c70ed3$3b01cad0$e800a8c0@prabhakar> References: <007501c70ed3$3b01cad0$e800a8c0@prabhakar> Message-ID: Hi The low frequencey components in an image are used becuase of the HVS. (Human Visual System) The high frequency components are noise for the human eye and can be filtered out. regards Kaustubh ----- Original Message ----- From: prabhakar Date: Thursday, November 23, 2023 8:47 pm Subject: Re: [Mp4-tech] Why only low frequeny is considered in DCT? To: sagar , mp4-tech@lists.mpegif.org > It is possible to reconstruct an approximate copy of the block > from the low frequency coefficients. Adding more coefficients > produces more accurate reconstruction of the original block. > > Thanks & Regards > --------------------------------- > P. Prabhakar > Digital Video Group > GDA Technologies Ltd > 32 & 46 North Phase > Thiru Ve Ka Industrial Estate > Ekkatuthangal > Chennai - 600 097 India > Email: prabhakar.pasunuti@gdatech.co.in > Mobile: 09840517282 > Office : 044-30613429 > > > ----- Original Message ----- > From: sagar > To: mp4-tech@lists.mpegif.org > Sent: Thursday, November 23, 2023 10:56 AM > Subject: [Mp4-tech] Why only low frequeny is considered in DCT? > > > Hi Xperts, > > I wanted to know when we do DCT ( video preocessing), we only > consider the Low frequency elements. Why? > DCT is used for taking out spatial reduncies, and DCT is > basically used to decorrelate energy in the image. > And other fact being low frequency contains high energy, > > If anybody could answer my question, i would be thankful. > > Warm Regards, > Sagar > > > -----Original Message----- > From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech- > bounces@lists.mpegif.org]On Behalf Of Luo Daniel > Sent: Wednesday, November 22, 2023 8:26 PM > To: mp4-tech@lists.mpegif.org > Cc: Luo Daniel > Subject: [Mp4-tech] Transport stream analyer > > > Dear all, > > > > Do you know if there is any free software TS analyzer that can > perform buffer verification? > > > > Thanks! > > Jiancong Luo > > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > > ------------------------------------------------------------------- > ----------- > > > _______________________________________________ > 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.1.409 / Virus Database: 268.14.14/547 - Release Date: > 11/22/2006 From denim83 yahoo.com Thu Nov 23 21:49:15 2006 From: denim83 yahoo.com (Abhishek Ballaney) Date: Fri Nov 24 13:52:16 2006 Subject: [Mp4-tech] aac doubt Message-ID: <416061.14079.qm@web34811.mail.mud.yahoo.com> dear all, am working on mpeg4 aac lc decoder. how many sections can be there inside a group? this would help me in defining the array sizes. regards, abhi /\ |_ |_ ' _ |_ __ | /--\|_)| ||_\ | ||-_ |< --------------------------------- Everyone is raving about the all-new Yahoo! Mail beta. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061123/0ff02f70/attachment-0001.html From raghav.km gmail.com Fri Nov 24 17:59:09 2006 From: raghav.km gmail.com (Raghavendra K M) Date: Fri Nov 24 13:52:22 2006 Subject: [Mp4-tech] how to play .aac fille with adif header In-Reply-To: <39379.212.25.82.227.1164265460.squirrel@203.101.43.195> References: <4BF47D56A0DD2346A1B8D622C5C5902C01F683D5@soc-mail.soc-soft.com> <39379.212.25.82.227.1164265460.squirrel@203.101.43.195> Message-ID: <8280f09c0611240429u6c90e0c3u33d20be6794e6906@mail.gmail.com> i had added adif ( adts too )header to raw encoded bitstream ..and was able to play with latest version of winamp... this was for mpeg2 AAC- LC hope this solves ur problem -Raghu On 11/23/06, rgomathi@sarayusoftech.com wrote: > > >Hi Apoorva..... > Thanks for your reply..... > Actually I'm working in Mp4 file format.In the mpeg systems doc....in > object type indication it is given that for 0x6b,0x69 the stream > comply to mpeg1 audio and mpeg2 audio.....So once i got that info i > came to know that the audio stream is mpeg1 or mpeg2 audio and i'll > parse the stream as such without any decoderSpecificInfo as the > mpeg1,mpeg2 (layers I,II,III) audio streams itself contains all the > info needed for decoder. > I do see streams (.mp4 file) with .mp3(inside the moov atom) and > there is no esds atom....so how to parse this stream..... is there any > more codec like this....please guide me experts ..... > > Thanks in advance > Regards, > Gomathi. > > > > Hello Gomathi, > > > > AAC bit stream according to the standard, contains only syntactic > > elements (SCE, CPE, LFE, DSE, PCE, FILL, CCE, TERM). So if an AAC > > decoder is developed, it will be implemented to support and decode the > > syntactic elements compulsorily. Let us call the AAC containing only > > syntactic elements as "Raw AAC". > > > > When we consider ADTS or ADIF, these are headers which provide > > information about the bit stream like sampling rate, channels, etc. And > > these headers (ADTS, ADIF) are not the only format, AAC bit stream could > > be encapsulated in. Raw AAC can even be a part of MP4 transport stream, > > in which the data like Sampling rate and channels will be a part of > > configuration information. > > > > So, if a player has AAC decoder but, do not have the implementation to > > decode the headers (ADTS, ADIF) then, the player can very well decode > > the "Raw AAC" (information of Sampling rate will have to be provided by > > the user) but, will not be in a position to decode the AAC with ADTS or > > ADIF header. > > > > Hope this helps, > > Apoorva Ankad > > > > -----Original Message----- > > From: rgomathi@sarayusoftech.com [mailto:rgomathi@sarayusoftech.com] > > Sent: Wednesday, November 22, 2023 2:37 PM > > To: Deshpande, Vishvanath; mp4-tech@lists.mpegif.org; > > mp4-tech-request@lists.mpegif.org > > Subject: Re: [Mp4-tech] how to play .aac fille with adif header > > > >> > > Hi all.... > > Thanks a lot for ur replies.can i know the reason behind why only > > certain players could play the .acc with ADIF header.B'coz both ADIF > > and ADTS headers can be used to create .aac file in general.I think the > > only difference being one time ADIF header for the whole stream and > > ADTS for every frame.If i'm correct why the normal players couldn't > > play that.is there any special thing the decoder should do to decode > > aac stream with adif.....expecting replies... > > > > Thanks in advance, > > > > regards, > > Gomathi. > > > > > > Hi, > >> > >> You can use Cool Edit to play that, > >> > >> -Vishvanath > >> > >> > >> > >> ----- Original Message ---- > >> From: "rgomathi@sarayusoftech.com" > >> To: mp4-tech@lists.mpegif.org; mp4-tech-request@lists.mpegif.org > >> Sent: Tuesday, 21 November, 2006 3:58:41 PM > >> Subject: [Mp4-tech] how to play .aac fille with adif header > >> > >> > >> Hi all...... > >> I badly want to know how to play .aac file with adif header.for the > >> same raw data with adts header most of the players like vlc,quick time > >> players play exactly well.but if i put adif header for the same even > >> VLC 8.5 doen't play.would i do somthing special to play this in > >> vlc....please guide me experts...expecting replies asap... > >> > >> Thanks in advance > >> Gomathi > >> _______________________________________________ > >> 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 > >> > >> Send instant messages to your online friends > > http://uk.messenger.yahoo.com > >> -- > >> This message has been scanned for viruses and > >> dangerous content by MailScanner, and is > >> believed to be clean. > >> > >> > > > > _______________________________________________ > > 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 > > > > > > > > -- > > This message has been scanned for viruses and > > dangerous content by MailScanner, and is > > believed to be clean. > > > > > > _______________________________________________ > 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/20061124/21f7f016/attachment-0001.html From Omar.Niamut tno.nl Fri Nov 24 13:58:54 2006 From: Omar.Niamut tno.nl (Niamut, O.A. (Omar)) Date: Fri Nov 24 13:52:27 2006 Subject: [Mp4-tech] Why only low frequeny is considered in DCT? Message-ID: <42F3BE57026C6E49B09E267EEF639D56018EADEA@ms-dt01thalia.tsn.tno.nl> Hi Anup, Thank you for the explanation you provided. I'd like to comment on some of your basic reasons. 2. Why the DCT? A. The Kahrunen-Loeve is one such transform which decorrelates information without loss, transforming signal information from the spatial to the frequency domain. But the Markov chain (since we are working in discrete time) involved needs a lot of processing. Hence we make use of the poor lossy cousin, the Type II DCT in real world image processing, majorly due to it's energy compaction property. R: The DCT is not a lossy transform (unless you consider its usage with integer arithmetic). The KLT is indeed the optimally decorrelating transform, however is basis functions depend on and thus vary with the autocorrelation of the input signal. For a time-varying input signal, you would have to send (some description for reconstruction of) the basis functions along with the transform coefficients, which leads to ppor compression perfomance. The DCT is an approximation of the KLT in the sense that for some (often encountered) sources, the decorrelation is nearly as good. Nevertheless, both the forward and inverse DCT are completely lossless. Thus, it is a good alternative for the KLT. Both transform lead to energy compaction, that is, the major part of signal energy is distributed over a few transform coefficients. 3. Why are the lower frequency components more important? A. As described in the answer to the 1st question a transform should ideally allow us to depict the signal information in the least possible components. The DCT by it's nature compacts the energy of the signal into the lower frequency components. Since the least frequency is 0, the DC component is of utmost importance. However the DCT being an approximation to the KLT, we do get components along the other axes. Hence even some non-zero frequency components could retain some signal energy. Hence we perform a zig-zag scan to get the higher energy (low frequency) components so as to preserve maximum information. R: The DCT has good energy compaction properties, as stated above. Since (for image and video coding) it transforms a spatial source signal to the frequency domain, it depicts an energy distribution in the frequency domain. The first component represents the DC level (think of this as the average brightness). The distribution of the energy over the DCT coefficients depends entirely on the energy distribution within the source signal. If the source signal has more energy at low spatial frequencies, the DCT will have most of the energy concentrated in the first coefficients. If the source signal has a lot of energy at high spatial frequencies, the DCT will show high values for the higher coefficients. Furthermore, by using the knowledge that the high spatial frequency information is less visible to the eye than low frequency we can quantize the high frequency parts using fewer bits. Regards, Omar ------------------------------------------------------------ Dr. ir. O.A. Niamut TNO Information and Communication Technology Broadband and Voice Solutions (Wireline) Brassersplein 2 P.O. Box 5050 2600GB Delft The Netherlands Tel : +31 15 285 72 18 Mobile : +31 6 519 162 42 Fax : +31 15 28 631 66 E-mail : Omar.Niamut@tno.nl This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html ------------------------------------------------------------ This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061124/499b3638/attachment.html From rickard.sjoberg ericsson.com Fri Nov 24 15:50:27 2006 From: rickard.sjoberg ericsson.com (=?iso-8859-1?Q?Rickard_Sj=F6berg_=28KI/EAB=29?=) Date: Fri Nov 24 15:52:08 2006 Subject: [Mp4-tech] Regarding padding in MPEG-4 part 2 In-Reply-To: <00ed01c70f6e$f6c2a8c0$0301a8c0@cmls7> Message-ID: <6BEB5EE4BAF7EB4EA6CC5CEC2AB3854604A196F7@esealmw103.eemea.ericsson.se> Thank you for resolving this issue. I am happy to see that MPEG-4 part 2 and H.263 Annex D treats this in the same way. FYI, I have tested the Microsoft reference software and I can confirm that there has been a change in the source code to pad outside the bounding rectangle. Apparently a fix was done to the Amendment 5 source code. (ISO/IEC 14496-5:2001/Amd.5:2004). I have not looked at the Momusys code so I can't say anything about padding changes there. / Regards Rickard > -----Original Message----- > From: Yi-Shin Tung [mailto:tung@setabox.com.tw] > Sent: den 24 november 2023 03:19 > To: Herbert Thoma; Gary Sullivan > Cc: Rickard Sj?berg (KI/EAB); mp4-tech@lists.mpegif.org; Tung > yi-Shin; ohm@ient.rwth-aachen.de > Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 > > Hi Rickard, Gary, Herbert and Jens, > > I think both versions of RefSW had been changed to consistent > with what specified in the 3rd version. > > I do not remember there exists some bitstreams available for > this test in the current conformance set. If you can provide > some, I could put them in the extended list in the future. > > Regards, > Yi-Shin > > ----- Original Message ----- > From: "Herbert Thoma" > To: "Gary Sullivan" > Cc: ""Rickard Sj?berg (KI/EAB)"" > ; ; > "Tung yi-Shin" ; "Yi-Shin Tung" > ; > Sent: Thursday, November 23, 2023 7:59 PM > Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 > > > > Gary, Yi-Shin, Jens, > > > > Please look at the 3rd (2004) edition: > > > > The sentence > > "Note that for rectangular VOP, a reference VOP is defined by > > video_object_layer_width and video_object_layer_height." > > in the 2nd edition was changed to > > "Note that for a rectangular VOP, a reference VOP is defined by > > video_object_layer_width and video_object_layer_height, > extended to a > > multiple of 16" > > in the 3rd edition. > > > > I guess this schould make you happy, Gary :-) > > > > Regards, > > Herbert. > > > > Gary Sullivan wrote: > >> Copying Yi-Shin and Jens, who perhaps remember this topic, > >> > >> Actually the action I discussed may have happened longer > ago than that. > >> I looked in N6362 > >> and although it touched on some relevant sections (I think > including > >> 7.6.3) I did not quite > >> find an answer to the question there. I also looked in N3664 and > >> didn't find it there either. > >> I then looked in the text of the 2nd (2001) edition and although I > >> got a bit confused by what it says in various plances (although I > >> haven't really studied the topic fully yet), I think I found it. > >> > >> What I think I see supports what I said on this thread. > At the end > >> of > >> 7.6.4 in the 2nd edition > >> it says the following: > >> > >> xref = MIN ( MAX (xcurr+dx, vhmcsr), xdim+vhmcsr-1 ) yref = MIN ( > >> MAX (ycurr+dy, vvmcsr), ydim+vvmcsr-1 ) > >> > >> and > >> > >> "(ydim, xdim) are the dimensions of the bounding rectangle of the > >> reference VOP" > >> > >> and > >> > >> "Note that for rectangular VOP, a reference VOP is defined by > >> video_object_layer_width and video_object_layer_height." > >> > >> > >> Now we know that video_object_layer_width and > >> video_object_layer_height might not be multiples of 16. > >> > >> Based on those equations and quoted sentences, it sounds > to me like > >> padding is applied for any location beyond the rectangle having > >> (width, > >> height) = (video_object_layer_width, video_object_layer_height). > >> > >> This is not something that I am happy about, but I think > it is what > >> is currently written and I think there was some historical > >> corrigendum action that changed it to say that. > >> > >> There has been a long history of confusion over this > issue. I am not > >> entirely sure that I have read all relevant parts of the > spec, but I > >> don't see how the above quoted statements can be interpreted any > >> other way. > >> > >> Best Regards, > >> > >> Gary Sullivan > >> > >> > >> +> -----Original Message----- > >> +> From: Gary Sullivan +> Sent: Thursday, November 23, 2023 2:20 AM > >> +> To: 'Herbert Thoma' > >> +> Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org > >> +> Subject: RE: [Mp4-tech] Regarding padding in MPEG-4 part 2 > >> +> +> Have you looked at N6362? > >> +> +> Best Regards, > >> +> +> -Gary Sullivan > >> +> +> +> -----Original Message----- > >> +> +> From: Herbert Thoma > [mailto:herbert.thoma@iis.fraunhofer.de] +> > >> +> +> +> > >> Sent: Thursday, November 23, 2023 2:11 AM > >> +> +> To: Gary Sullivan > >> +> +> Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org > >> +> +> Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 > >> +> +> +> +> Gary, Rickard, > >> +> +> +> +> I am pretty sure that the padding from 128x176 > is the +> > >> +> +> +> +> +> > >> correct interpretation > >> +> +> (meaning that the pixels outside of 120x170 but > inside of +> +> > >> 128x176 shall be left > >> +> +> as they were decoded). > >> +> +> +> +> I remember the discussion in MPEG very well, > because I +> > >> +> +> +> +> +> > >> originally implemented > >> +> +> it the other way in my encoder and decoder and > changed that +> > >> +> +> +> > >> after the corrigendum. > >> +> +> +> +> I don't konw if there are any comformance > bitstreams +> > >> +> +> +> +> +> > >> available, but I attached > >> +> +> a few frames of forman cropped to 170x120 and > encoded with +> > >> +> +> +> my > >> encoder. (I can > >> +> +> not guarantee that there are actually motion vectors > that +> +> > >> test the problem > >> +> +> in there, though.) > >> +> +> +> +> Kind regards, > >> +> +> Herbert. > >> +> +> +> +> Gary Sullivan wrote: > >> +> +> > Rickard et al, > >> +> +> > +> +> > For a long time, I was pretty sure that I > knew what > >> +> +> > +> +> > the > >> +> +> answer was, and my interpretation agreed > >> +> +> > with yours. Certainly that is the way the similar > feature +> > >> +> +> > +> > >> works in H.263 (although that fact is > >> +> +> > not directly relevant to the question at hand, since +> +> > >> "motion vectors over picture boundaries" is > >> +> +> > a non-Baseline feature of H.263 Annex D, while > MPEG-4 part +> > >> +> +> > +> > >> 2 only tries to be compatible with the > >> +> +> > Baseline). I vaguely recall that at one time one +> +> > >> implementation of the reference software was > >> +> +> > doing it one way and the other was doing it the > other way, +> > >> +> +> > +> > >> and I believe MPEG eventually approved > >> +> +> > a corrigendum to Part 2 and a bug fix to the > software to +> > >> +> +> > +> > >> clarify it. Unfortunately, I believe the > >> +> +> > clarification was according to the other interpretation. > >> +> +> > +> +> > There was a corrigendum finalized in 2004, which I > >> +> +> > +> +> > think > >> +> +> corresponded to MPEG output document > >> +> +> > N6362. I believe this subject was addressed in that +> > >> corrigendum. > >> +> +> > +> +> > If I was making an encoder, I might design it to > >> +> +> > +> +> > avoid +> > >> +> motion vectors reaching beyond the bottom > >> +> +> > and right edges of the reference pictures to be > sure that +> > >> +> +> > +> I > >> would work with decoders that used > >> +> +> > either interpretation. +> +> > +> +> > I guess another > >> +> +> > decent > >> encoder approach would be to use +> +> padding in the source for > >> those areas before > >> +> +> > encoding too, so that the only difference between > the two +> > >> +> +> > +> > >> interpretations would be the quantization > >> +> +> > error. With that approach, a little drift might not +> +> > >> produce very bad artifacts. > >> +> +> > +> +> > Best Regards, > >> +> +> > +> +> > Gary Sullivan > >> +> +> > +> +> > +> -----Original Message----- > >> +> +> > +> From: mp4-tech-bounces@lists.mpegif.org +> +> > +> > >> [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of +> +> > +> > >> Rickard Sj?berg (KI/EAB) > >> +> +> > +> Sent: Wednesday, November 22, 2023 5:36 AM > >> +> +> > +> To: mp4-tech@lists.mpegif.org > >> +> +> > +> Subject: [Mp4-tech] Regarding padding in MPEG-4 part 2 > >> +> +> > +> +> +> > +> +> +> > +> Dear experts, > >> +> +> > +> +> +> > +> assume that a simple profile video > stream with > >> height and +> +> > +> width of 120 and 170 pixels > respectively shall > >> be decoded. +> +> > +> The bounding rectangle of the > reference VOP is > >> 128x176. Now +> +> > +> my question is whether you should > pad outside > >> of 120x170 or +> +> > +> 128x176 when referencing pixels > for motion > >> compensation? > >> +> +> > +> +> +> > +> The relevant part of the standard is section > >> +> +> > +> +> +> > +> 7.6.4 > >> i believe +> +> > +> (I looking at the 3rd edition, that's > ISO/IEC +> > >> +> 14496-2:2004, N5515): > >> +> +> > +> +> +> > +> The coordinates of a reference sample in the > >> reference VOP, +> +> > +> (yref, xref) is determined as follows : > >> +> +> > +> xref = MIN ( MAX (xcurr+dx, vhmcsr), > xdim+vhmcsr-1 ) yref > >> +> +> > +> = MIN ( MAX (ycurr+dy, vvmcsr), ydim+vvmcsr-1) > >> +> +> > +> +> +> > +> My interpretation of this is that padding > >> +> +> > +> +> +> > +> should be > >> done +> +> > +> outside of 128x176 (this means that the pixels > >> outside of > >> +> +> > +> 120x170 but inside of 128x176 shall be left as > they were > >> +> +> > +> +> +> > >> > +> decoded), is this correct? > >> +> +> > +> +> +> > +> Is there any conformance bitstream > that tests > >> +> +> > +> +> +> > +> this > >> behaviour? > >> +> +> > +> +> +> > +> / > >> +> +> > +> Rickard Sjoberg > >> +> +> > +> Ericsson > >> +> +> > +> +> +> > +> > _______________________________________________ > >> +> +> > +> 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-Ant > >> +> +> itrust.php > >> +> +> > +> +> +> +> -- > >> +> +> Herbert Thoma > >> +> +> Head of Video Group > >> +> +> Multimedia Realtime Systems Department Fraunhofer IIS Am > >> +> +> Wolfsmantel 33, 91058 Erlangen, Germany > >> +> +> Phone: +49-9131-776-323 > >> +> +> Fax: +49-9131-776-399 > >> +> +> email: tma@iis.fhg.de > >> +> +> www: http://www.iis.fhg.de/ > >> +> +> > > > > -- > > Herbert Thoma > > Head of Video Group > > Multimedia Realtime Systems Department Fraunhofer IIS Am > Wolfsmantel > > 33, 91058 Erlangen, Germany > > Phone: +49-9131-776-323 > > Fax: +49-9131-776-399 > > email: tma@iis.fhg.de > > www: http://www.iis.fhg.de/ > > > > > From dthoang yahoo.com Fri Nov 24 10:18:58 2006 From: dthoang yahoo.com (Dzung Hoang) Date: Fri Nov 24 17:34:08 2006 Subject: [Mp4-tech] Regarding padding in MPEG-4 part 2 In-Reply-To: <000901c70f0f$7f015bb0$6401a8c0@corp.intertrust.com> Message-ID: <00e801c70fe4$3f6c49d0$6701a8c0@DZUNGLAPTOP> So this means that each interpretation is compliant to a different version of the spec. Is there a version number in the bitstream that can be used to properly decode bitstreams compliant to a specific version? Should a newer version of a standard obsolete older versions and render existing bitstreams non-compliant? Regards, - Dzung Hoang -----Original Message----- From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of MPEGIF List Admins Sent: Thursday, November 23, 2023 8:56 AM To: mp4-tech@lists.mpegif.org Cc: 'Herbert.Thoma.'@lists1.magma.ca Subject: FW: [Mp4-tech] Regarding padding in MPEG-4 part 2 another forward of a bounced email. -----Original Message----- From: Herbert Thoma [mailto:tma@iis.fhg.de] Sent: Thursday, 23 November 2023 12:59 To: Gary Sullivan Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org; Tung yi-Shin; Yi-Shin Tung; ohm@ient.rwth-aachen.de Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 Gary, Yi-Shin, Jens, Please look at the 3rd (2004) edition: The sentence "Note that for rectangular VOP, a reference VOP is defined by video_object_layer_width and video_object_layer_height." in the 2nd edition was changed to "Note that for a rectangular VOP, a reference VOP is defined by video_object_layer_width and video_object_layer_height, extended to a multiple of 16" in the 3rd edition. I guess this schould make you happy, Gary :-) Regards, Herbert. Gary Sullivan wrote: > Copying Yi-Shin and Jens, who perhaps remember this topic, > > Actually the action I discussed may have happened longer ago than that. I looked in N6362 > and although it touched on some relevant sections (I think including 7.6.3) I did not quite > find an answer to the question there. I also looked in N3664 and didn't find it there either. > I then looked in the text of the 2nd (2001) edition and although I got a bit confused by what it > says in various plances (although I haven't really studied the topic fully yet), I think I found it. > > What I think I see supports what I said on this thread. At the end of 7.6.4 in the 2nd edition > it says the following: > > xref = MIN ( MAX (xcurr+dx, vhmcsr), xdim+vhmcsr-1 ) > yref = MIN ( MAX (ycurr+dy, vvmcsr), ydim+vvmcsr-1 ) > > and > > "(ydim, xdim) are the dimensions of the bounding rectangle of the reference VOP" > > and > > "Note that for rectangular VOP, a reference VOP is defined by video_object_layer_width and video_object_layer_height." > > > Now we know that video_object_layer_width and video_object_layer_height might not be multiples of 16. > > Based on those equations and quoted sentences, it sounds to me like padding is applied for any location beyond the rectangle having (width, height) = (video_object_layer_width, video_object_layer_height). > > This is not something that I am happy about, but I think it is what is currently written and I think there was some historical corrigendum action that changed it to say that. > > There has been a long history of confusion over this issue. I am not entirely sure that I have read all relevant parts of the spec, but I don't see how the above quoted statements can be interpreted any other way. > > Best Regards, > > Gary Sullivan > > > +> -----Original Message----- > +> From: Gary Sullivan > +> Sent: Thursday, November 23, 2023 2:20 AM > +> To: 'Herbert Thoma' > +> Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org > +> Subject: RE: [Mp4-tech] Regarding padding in MPEG-4 part 2 > +> > +> Have you looked at N6362? > +> > +> Best Regards, > +> > +> -Gary Sullivan > +> > +> +> -----Original Message----- > +> +> From: Herbert Thoma [mailto:herbert.thoma@iis.fraunhofer.de] > +> +> Sent: Thursday, November 23, 2023 2:11 AM > +> +> To: Gary Sullivan > +> +> Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org > +> +> Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 > +> +> > +> +> Gary, Rickard, > +> +> > +> +> I am pretty sure that the padding from 128x176 is the > +> +> correct interpretation > +> +> (meaning that the pixels outside of 120x170 but inside of > +> +> 128x176 shall be left > +> +> as they were decoded). > +> +> > +> +> I remember the discussion in MPEG very well, because I > +> +> originally implemented > +> +> it the other way in my encoder and decoder and changed that > +> +> after the corrigendum. > +> +> > +> +> I don't konw if there are any comformance bitstreams > +> +> available, but I attached > +> +> a few frames of forman cropped to 170x120 and encoded with > +> +> my encoder. (I can > +> +> not guarantee that there are actually motion vectors that > +> +> test the problem > +> +> in there, though.) > +> +> > +> +> Kind regards, > +> +> Herbert. > +> +> > +> +> Gary Sullivan wrote: > +> +> > Rickard et al, > +> +> > > +> +> > For a long time, I was pretty sure that I knew what the > +> +> answer was, and my interpretation agreed > +> +> > with yours. Certainly that is the way the similar feature > +> +> works in H.263 (although that fact is > +> +> > not directly relevant to the question at hand, since > +> +> "motion vectors over picture boundaries" is > +> +> > a non-Baseline feature of H.263 Annex D, while MPEG-4 part > +> +> 2 only tries to be compatible with the > +> +> > Baseline). I vaguely recall that at one time one > +> +> implementation of the reference software was > +> +> > doing it one way and the other was doing it the other way, > +> +> and I believe MPEG eventually approved > +> +> > a corrigendum to Part 2 and a bug fix to the software to > +> +> clarify it. Unfortunately, I believe the > +> +> > clarification was according to the other interpretation. > +> +> > > +> +> > There was a corrigendum finalized in 2004, which I think > +> +> corresponded to MPEG output document > +> +> > N6362. I believe this subject was addressed in that > +> corrigendum. > +> +> > > +> +> > If I was making an encoder, I might design it to avoid > +> +> motion vectors reaching beyond the bottom > +> +> > and right edges of the reference pictures to be sure that > +> +> I would work with decoders that used > +> +> > either interpretation. > +> +> > > +> +> > I guess another decent encoder approach would be to use > +> +> padding in the source for those areas before > +> +> > encoding too, so that the only difference between the two > +> +> interpretations would be the quantization > +> +> > error. With that approach, a little drift might not > +> +> produce very bad artifacts. > +> +> > > +> +> > Best Regards, > +> +> > > +> +> > Gary Sullivan > +> +> > > +> +> > +> -----Original Message----- > +> +> > +> From: mp4-tech-bounces@lists.mpegif.org > +> +> > +> [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of > +> +> > +> Rickard Sj?berg (KI/EAB) > +> +> > +> Sent: Wednesday, November 22, 2023 5:36 AM > +> +> > +> To: mp4-tech@lists.mpegif.org > +> +> > +> Subject: [Mp4-tech] Regarding padding in MPEG-4 part 2 > +> +> > +> > +> +> > +> > +> +> > +> Dear experts, > +> +> > +> > +> +> > +> assume that a simple profile video stream with height and > +> +> > +> width of 120 and 170 pixels respectively shall be decoded. > +> +> > +> The bounding rectangle of the reference VOP is 128x176. Now > +> +> > +> my question is whether you should pad outside of 120x170 or > +> +> > +> 128x176 when referencing pixels for motion compensation? > +> +> > +> > +> +> > +> The relevant part of the standard is section 7.6.4 i believe > +> +> > +> (I looking at the 3rd edition, that's ISO/IEC > +> +> 14496-2:2004, N5515): > +> +> > +> > +> +> > +> The coordinates of a reference sample in the reference VOP, > +> +> > +> (yref, xref) is determined as follows : > +> +> > +> xref = MIN ( MAX (xcurr+dx, vhmcsr), xdim+vhmcsr-1 ) > +> +> > +> yref = MIN ( MAX (ycurr+dy, vvmcsr), ydim+vvmcsr-1) > +> +> > +> > +> +> > +> My interpretation of this is that padding should be done > +> +> > +> outside of 128x176 (this means that the pixels outside of > +> +> > +> 120x170 but inside of 128x176 shall be left as they were > +> +> > +> decoded), is this correct? > +> +> > +> > +> +> > +> Is there any conformance bitstream that tests this behaviour? > +> +> > +> > +> +> > +> / > +> +> > +> Rickard Sjoberg > +> +> > +> Ericsson > +> +> > +> > +> +> > +> _______________________________________________ > +> +> > +> 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-Ant > +> +> itrust.php > +> +> > > +> +> > +> +> -- > +> +> Herbert Thoma > +> +> Head of Video Group > +> +> Multimedia Realtime Systems Department > +> +> Fraunhofer IIS > +> +> Am Wolfsmantel 33, 91058 Erlangen, Germany > +> +> Phone: +49-9131-776-323 > +> +> Fax: +49-9131-776-399 > +> +> email: tma@iis.fhg.de > +> +> www: http://www.iis.fhg.de/ > +> +> > -- Herbert Thoma Head of Video Group Multimedia Realtime Systems Department Fraunhofer IIS Am Wolfsmantel 33, 91058 Erlangen, Germany Phone: +49-9131-776-323 Fax: +49-9131-776-399 email: tma@iis.fhg.de www: http://www.iis.fhg.de/ From cassjo inwind.it Fri Nov 24 11:25:41 2006 From: cassjo inwind.it (Fabrizio) Date: Fri Nov 24 20:04:07 2006 Subject: [Mp4-tech] question regarding prediction error References: <20061120173752.3326.qmail@webmail28.rediffmail.com> Message-ID: <000601c70ffe$73736280$ddc81897@acerae863c6296> Dear Nitin, I think you try to find prediction error in the "LumaResidualCoding8x8" function. In particular you have to look img->m7[j][i], in wich I think is stored the difference between original image and predicted for each pixel. Best regards, Fabrizio ----- Original Message ----- From: nitin ashok To: mp4-tech@lists.mpegif.org Sent: Monday, November 20, 2023 6:37 PM Subject: [Mp4-tech] question regarding prediction error Dear Experts, i am trying to find the prediction error for a macroblock,i am using the JM 10.2 reference software.i am looking at the dct_luma() function in block.c,where the residual goes for transformation,but since the rdopt is enabled, i am not sure of how to find the prediction error for the best mode,please guide thanks nitin ------------------------------------------------------------------------------ _______________________________________________ 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/20061124/d3676a75/attachment.html From garysull windows.microsoft.com Fri Nov 24 17:02:36 2006 From: garysull windows.microsoft.com (Gary Sullivan) Date: Sat Nov 25 01:10:06 2006 Subject: [Mp4-tech] Regarding padding in MPEG-4 part 2 In-Reply-To: <00e801c70fe4$3f6c49d0$6701a8c0@DZUNGLAPTOP> Message-ID: <03CB47D9C3F8074498E4653F814D6E8F02FBF95D@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> Dzung Hoang et al, Actually it's not as simple as saying that the standard said to do one thing and then was changed to say to do something else. In this case there was actually a lack of clarity and apparent conflict between what different parts of the document (and software) said. For something like this, the intent is that the newer version should be interpreted as the proper actual *original* intent. This is equivalent to saying that the new version *obsoletes* the old one. This sort of thing is one reason that companies that implement standards should keep a close eye on what the standardization committee is doing (and considering to do) on an ongoing basis, and should voice their opinion as that work progresses. When we write a standard, we try to write it perfectly without errors, but such issues do unavoidably arise. No, there is no version number in the syntax. I don't think it would make any difference if there was, since (due to the prior state of confusion) it was not clear what an older encoder would expect the decoder to be doing. Of course, there is an understanding that some people may have made products prior to the corrigendum action in which the problem with the prior version of the standard might manifest itself in the product behavior. It may be advisable for encoders to consider this in their encoder design, such as by using certain encoding techniques that are designed to mitigate or avoid the problem (as I previously advised on this thread). Best Regards, Gary Sullivan +> -----Original Message----- +> From: mp4-tech-bounces@lists.mpegif.org +> [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Dzung Hoang +> Sent: Friday, November 24, 2023 8:19 AM +> To: mp4-tech@lists.mpegif.org +> Subject: RE: [Mp4-tech] Regarding padding in MPEG-4 part 2 +> +> So this means that each interpretation is compliant to a +> different version +> of the spec. Is there a version number in the bitstream that +> can be used to +> properly decode bitstreams compliant to a specific version? +> +> Should a newer version of a standard obsolete older versions +> and render +> existing bitstreams non-compliant? +> +> Regards, +> - Dzung Hoang +> +> +> -----Original Message----- +> From: mp4-tech-bounces@lists.mpegif.org +> [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of +> MPEGIF List Admins +> Sent: Thursday, November 23, 2023 8:56 AM +> To: mp4-tech@lists.mpegif.org +> Cc: 'Herbert.Thoma.'@lists1.magma.ca +> Subject: FW: [Mp4-tech] Regarding padding in MPEG-4 part 2 +> +> another forward of a bounced email. +> +> -----Original Message----- +> From: Herbert Thoma [mailto:tma@iis.fhg.de] +> Sent: Thursday, 23 November 2023 12:59 +> To: Gary Sullivan +> Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org; +> Tung yi-Shin; +> Yi-Shin Tung; ohm@ient.rwth-aachen.de +> Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 +> +> Gary, Yi-Shin, Jens, +> +> Please look at the 3rd (2004) edition: +> +> The sentence +> "Note that for rectangular VOP, a reference VOP is defined by +> video_object_layer_width and video_object_layer_height." +> in the 2nd edition was changed to +> "Note that for a rectangular VOP, a reference VOP is defined by +> video_object_layer_width and video_object_layer_height, extended to +> a multiple of 16" +> in the 3rd edition. +> +> I guess this schould make you happy, Gary :-) +> +> Regards, +> Herbert. +> +> Gary Sullivan wrote: +> > Copying Yi-Shin and Jens, who perhaps remember this topic, +> > +> > Actually the action I discussed may have happened longer +> ago than that. I +> looked in N6362 +> > and although it touched on some relevant sections (I think +> including +> 7.6.3) I did not quite +> > find an answer to the question there. I also looked in +> N3664 and didn't +> find it there either. +> > I then looked in the text of the 2nd (2001) edition and +> although I got a +> bit confused by what it +> > says in various plances (although I haven't really studied +> the topic fully +> yet), I think I found it. +> > +> > What I think I see supports what I said on this thread. +> At the end of +> 7.6.4 in the 2nd edition +> > it says the following: +> > +> > xref = MIN ( MAX (xcurr+dx, vhmcsr), xdim+vhmcsr-1 ) +> > yref = MIN ( MAX (ycurr+dy, vvmcsr), ydim+vvmcsr-1 ) +> > +> > and +> > +> > "(ydim, xdim) are the dimensions of the bounding rectangle of the +> reference VOP" +> > +> > and +> > +> > "Note that for rectangular VOP, a reference VOP is defined by +> video_object_layer_width and video_object_layer_height." +> > +> > +> > Now we know that video_object_layer_width and +> video_object_layer_height +> might not be multiples of 16. +> > +> > Based on those equations and quoted sentences, it sounds to me like +> padding is applied for any location beyond the rectangle +> having (width, +> height) = (video_object_layer_width, video_object_layer_height). +> > +> > This is not something that I am happy about, but I think +> it is what is +> currently written and I think there was some historical +> corrigendum action +> that changed it to say that. +> > +> > There has been a long history of confusion over this +> issue. I am not +> entirely sure that I have read all relevant parts of the +> spec, but I don't +> see how the above quoted statements can be interpreted any other way. +> > +> > Best Regards, +> > +> > Gary Sullivan +> > +> > +> > +> -----Original Message----- +> > +> From: Gary Sullivan +> > +> Sent: Thursday, November 23, 2023 2:20 AM +> > +> To: 'Herbert Thoma' +> > +> Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org +> > +> Subject: RE: [Mp4-tech] Regarding padding in MPEG-4 part 2 +> > +> +> > +> Have you looked at N6362? +> > +> +> > +> Best Regards, +> > +> +> > +> -Gary Sullivan +> > +> +> > +> +> -----Original Message----- +> > +> +> From: Herbert Thoma [mailto:herbert.thoma@iis.fraunhofer.de] +> > +> +> Sent: Thursday, November 23, 2023 2:11 AM +> > +> +> To: Gary Sullivan +> > +> +> Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org +> > +> +> Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 +> > +> +> +> > +> +> Gary, Rickard, +> > +> +> +> > +> +> I am pretty sure that the padding from 128x176 is the +> > +> +> correct interpretation +> > +> +> (meaning that the pixels outside of 120x170 but inside of +> > +> +> 128x176 shall be left +> > +> +> as they were decoded). +> > +> +> +> > +> +> I remember the discussion in MPEG very well, because I +> > +> +> originally implemented +> > +> +> it the other way in my encoder and decoder and changed that +> > +> +> after the corrigendum. +> > +> +> +> > +> +> I don't konw if there are any comformance bitstreams +> > +> +> available, but I attached +> > +> +> a few frames of forman cropped to 170x120 and encoded with +> > +> +> my encoder. (I can +> > +> +> not guarantee that there are actually motion vectors that +> > +> +> test the problem +> > +> +> in there, though.) +> > +> +> +> > +> +> Kind regards, +> > +> +> Herbert. +> > +> +> +> > +> +> Gary Sullivan wrote: +> > +> +> > Rickard et al, +> > +> +> > +> > +> +> > For a long time, I was pretty sure that I knew what the +> > +> +> answer was, and my interpretation agreed +> > +> +> > with yours. Certainly that is the way the similar feature +> > +> +> works in H.263 (although that fact is +> > +> +> > not directly relevant to the question at hand, since +> > +> +> "motion vectors over picture boundaries" is +> > +> +> > a non-Baseline feature of H.263 Annex D, while MPEG-4 part +> > +> +> 2 only tries to be compatible with the +> > +> +> > Baseline). I vaguely recall that at one time one +> > +> +> implementation of the reference software was +> > +> +> > doing it one way and the other was doing it the other way, +> > +> +> and I believe MPEG eventually approved +> > +> +> > a corrigendum to Part 2 and a bug fix to the software to +> > +> +> clarify it. Unfortunately, I believe the +> > +> +> > clarification was according to the other interpretation. +> > +> +> > +> > +> +> > There was a corrigendum finalized in 2004, which I think +> > +> +> corresponded to MPEG output document +> > +> +> > N6362. I believe this subject was addressed in that +> > +> corrigendum. +> > +> +> > +> > +> +> > If I was making an encoder, I might design it to avoid +> > +> +> motion vectors reaching beyond the bottom +> > +> +> > and right edges of the reference pictures to be sure that +> > +> +> I would work with decoders that used +> > +> +> > either interpretation. +> > +> +> > +> > +> +> > I guess another decent encoder approach would be to use +> > +> +> padding in the source for those areas before +> > +> +> > encoding too, so that the only difference between the two +> > +> +> interpretations would be the quantization +> > +> +> > error. With that approach, a little drift might not +> > +> +> produce very bad artifacts. +> > +> +> > +> > +> +> > Best Regards, +> > +> +> > +> > +> +> > Gary Sullivan +> > +> +> > +> > +> +> > +> -----Original Message----- +> > +> +> > +> From: mp4-tech-bounces@lists.mpegif.org +> > +> +> > +> [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of +> > +> +> > +> Rickard Sj?berg (KI/EAB) +> > +> +> > +> Sent: Wednesday, November 22, 2023 5:36 AM +> > +> +> > +> To: mp4-tech@lists.mpegif.org +> > +> +> > +> Subject: [Mp4-tech] Regarding padding in MPEG-4 part 2 +> > +> +> > +> +> > +> +> > +> +> > +> +> > +> Dear experts, +> > +> +> > +> +> > +> +> > +> assume that a simple profile video stream with +> height and +> > +> +> > +> width of 120 and 170 pixels respectively shall +> be decoded. +> > +> +> > +> The bounding rectangle of the reference VOP is +> 128x176. Now +> > +> +> > +> my question is whether you should pad outside +> of 120x170 or +> > +> +> > +> 128x176 when referencing pixels for motion compensation? +> > +> +> > +> +> > +> +> > +> The relevant part of the standard is section +> 7.6.4 i believe +> > +> +> > +> (I looking at the 3rd edition, that's ISO/IEC +> > +> +> 14496-2:2004, N5515): +> > +> +> > +> +> > +> +> > +> The coordinates of a reference sample in the +> reference VOP, +> > +> +> > +> (yref, xref) is determined as follows : +> > +> +> > +> xref = MIN ( MAX (xcurr+dx, vhmcsr), xdim+vhmcsr-1 ) +> > +> +> > +> yref = MIN ( MAX (ycurr+dy, vvmcsr), ydim+vvmcsr-1) +> > +> +> > +> +> > +> +> > +> My interpretation of this is that padding +> should be done +> > +> +> > +> outside of 128x176 (this means that the pixels +> outside of +> > +> +> > +> 120x170 but inside of 128x176 shall be left as +> they were +> > +> +> > +> decoded), is this correct? +> > +> +> > +> +> > +> +> > +> Is there any conformance bitstream that tests +> this behaviour? +> > +> +> > +> +> > +> +> > +> / +> > +> +> > +> Rickard Sjoberg +> > +> +> > +> Ericsson +> > +> +> > +> +> > +> +> > +> _______________________________________________ +> > +> +> > +> 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-Ant +> > +> +> itrust.php +> > +> +> > +> > +> +> +> > +> +> -- +> > +> +> Herbert Thoma +> > +> +> Head of Video Group +> > +> +> Multimedia Realtime Systems Department +> > +> +> Fraunhofer IIS +> > +> +> Am Wolfsmantel 33, 91058 Erlangen, Germany +> > +> +> Phone: +49-9131-776-323 +> > +> +> Fax: +49-9131-776-399 +> > +> +> email: tma@iis.fhg.de +> > +> +> www: http://www.iis.fhg.de/ +> > +> +> +> > +> +> -- +> Herbert Thoma +> Head of Video Group +> Multimedia Realtime Systems Department +> Fraunhofer IIS +> Am Wolfsmantel 33, 91058 Erlangen, Germany +> Phone: +49-9131-776-323 +> Fax: +49-9131-776-399 +> email: tma@iis.fhg.de +> www: http://www.iis.fhg.de/ +> +> +> _______________________________________________ +> 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 +> From mp4-tech-owner lists.mpegif.org Fri Nov 24 15:48:54 2006 From: mp4-tech-owner lists.mpegif.org (MPEGIF List Admins) Date: Sat Nov 25 10:10:08 2006 Subject: FW: [Mp4-tech] Regarding padding in MPEG-4 part 2 Message-ID: <002501c70fd7$a9c4a2d0$6401a8c0@corp.intertrust.com> Another bounced mail from anon-subsribed address (different than yesterday's). Yi Shin - please subscribe your sending address. See http://www.m4if.org/public/publiclistreg.php Thanks. -----Original Message----- From: Yi-Shin Tung [mailto:tung@setabox.com.tw] Sent: Friday, 24 november 2023 03:19 To: Herbert Thoma; Gary Sullivan Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org; Tung yi-Shin; ohm@ient.rwth-aachen.de Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 Hi Rickard, Gary, Herbert and Jens, I think both versions of RefSW had been changed to consistent with what specified in the 3rd version. I do not remember there exists some bitstreams available for this test in the current conformance set. If you can provide some, I could put them in the extended list in the future. Regards, Yi-Shin ----- Original Message ----- From: "Herbert Thoma" To: "Gary Sullivan" Cc: ""Rickard Sj?berg (KI/EAB)"" ; ; "Tung yi-Shin" ; "Yi-Shin Tung" ; Sent: Thursday, November 23, 2023 7:59 PM Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 > Gary, Yi-Shin, Jens, > > Please look at the 3rd (2004) edition: > > The sentence > "Note that for rectangular VOP, a reference VOP is defined by > video_object_layer_width and video_object_layer_height." > in the 2nd edition was changed to > "Note that for a rectangular VOP, a reference VOP is defined by > video_object_layer_width and video_object_layer_height, extended to > a multiple of 16" > in the 3rd edition. > > I guess this schould make you happy, Gary :-) > > Regards, > Herbert. > > Gary Sullivan wrote: >> Copying Yi-Shin and Jens, who perhaps remember this topic, >> >> Actually the action I discussed may have happened longer ago than that. >> I looked in N6362 >> and although it touched on some relevant sections (I think including >> 7.6.3) I did not quite >> find an answer to the question there. I also looked in N3664 and didn't >> find it there either. >> I then looked in the text of the 2nd (2001) edition and although I got a >> bit confused by what it >> says in various plances (although I haven't really studied the topic >> fully yet), I think I found it. >> >> What I think I see supports what I said on this thread. At the end of >> 7.6.4 in the 2nd edition >> it says the following: >> >> xref = MIN ( MAX (xcurr+dx, vhmcsr), xdim+vhmcsr-1 ) yref = MIN ( MAX >> (ycurr+dy, vvmcsr), ydim+vvmcsr-1 ) >> >> and >> >> "(ydim, xdim) are the dimensions of the bounding rectangle of the >> reference VOP" >> >> and >> >> "Note that for rectangular VOP, a reference VOP is defined by >> video_object_layer_width and video_object_layer_height." >> >> >> Now we know that video_object_layer_width and video_object_layer_height >> might not be multiples of 16. >> >> Based on those equations and quoted sentences, it sounds to me like >> padding is applied for any location beyond the rectangle having (width, >> height) = (video_object_layer_width, video_object_layer_height). >> >> This is not something that I am happy about, but I think it is what is >> currently written and I think there was some historical corrigendum >> action that changed it to say that. >> >> There has been a long history of confusion over this issue. I am not >> entirely sure that I have read all relevant parts of the spec, but I >> don't see how the above quoted statements can be interpreted any other >> way. >> >> Best Regards, >> >> Gary Sullivan >> >> >> +> -----Original Message----- >> +> From: Gary Sullivan +> Sent: Thursday, November 23, 2023 2:20 AM >> +> To: 'Herbert Thoma' >> +> Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org >> +> Subject: RE: [Mp4-tech] Regarding padding in MPEG-4 part 2 >> +> +> Have you looked at N6362? >> +> +> Best Regards, >> +> +> -Gary Sullivan >> +> +> +> -----Original Message----- >> +> +> From: Herbert Thoma [mailto:herbert.thoma@iis.fraunhofer.de] +> +> >> Sent: Thursday, November 23, 2023 2:11 AM >> +> +> To: Gary Sullivan >> +> +> Cc: "Rickard Sj?berg (KI/EAB)"; mp4-tech@lists.mpegif.org >> +> +> Subject: Re: [Mp4-tech] Regarding padding in MPEG-4 part 2 >> +> +> +> +> Gary, Rickard, >> +> +> +> +> I am pretty sure that the padding from 128x176 is the +> +> >> correct interpretation >> +> +> (meaning that the pixels outside of 120x170 but inside of +> +> >> 128x176 shall be left >> +> +> as they were decoded). >> +> +> +> +> I remember the discussion in MPEG very well, because I +> +> >> originally implemented >> +> +> it the other way in my encoder and decoder and changed that +> +> >> after the corrigendum. >> +> +> +> +> I don't konw if there are any comformance bitstreams +> +> >> available, but I attached >> +> +> a few frames of forman cropped to 170x120 and encoded with +> +> my >> encoder. (I can >> +> +> not guarantee that there are actually motion vectors that +> +> >> test the problem >> +> +> in there, though.) >> +> +> +> +> Kind regards, >> +> +> Herbert. >> +> +> +> +> Gary Sullivan wrote: >> +> +> > Rickard et al, >> +> +> > +> +> > For a long time, I was pretty sure that I knew what the >> +> +> answer was, and my interpretation agreed >> +> +> > with yours. Certainly that is the way the similar feature +> +> >> works in H.263 (although that fact is >> +> +> > not directly relevant to the question at hand, since +> +> >> "motion vectors over picture boundaries" is >> +> +> > a non-Baseline feature of H.263 Annex D, while MPEG-4 part +> +> >> 2 only tries to be compatible with the >> +> +> > Baseline). I vaguely recall that at one time one +> +> >> implementation of the reference software was >> +> +> > doing it one way and the other was doing it the other way, +> +> >> and I believe MPEG eventually approved >> +> +> > a corrigendum to Part 2 and a bug fix to the software to +> +> >> clarify it. Unfortunately, I believe the >> +> +> > clarification was according to the other interpretation. >> +> +> > +> +> > There was a corrigendum finalized in 2004, which I think >> +> +> corresponded to MPEG output document >> +> +> > N6362. I believe this subject was addressed in that +> >> corrigendum. >> +> +> > +> +> > If I was making an encoder, I might design it to avoid +> >> +> motion vectors reaching beyond the bottom >> +> +> > and right edges of the reference pictures to be sure that +> +> I >> would work with decoders that used >> +> +> > either interpretation. +> +> > +> +> > I guess another decent >> encoder approach would be to use +> +> padding in the source for those >> areas before >> +> +> > encoding too, so that the only difference between the two +> +> >> interpretations would be the quantization >> +> +> > error. With that approach, a little drift might not +> +> >> produce very bad artifacts. >> +> +> > +> +> > Best Regards, >> +> +> > +> +> > Gary Sullivan >> +> +> > +> +> > +> -----Original Message----- >> +> +> > +> From: mp4-tech-bounces@lists.mpegif.org +> +> > +> >> [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of +> +> > +> >> Rickard Sj?berg (KI/EAB) >> +> +> > +> Sent: Wednesday, November 22, 2023 5:36 AM >> +> +> > +> To: mp4-tech@lists.mpegif.org >> +> +> > +> Subject: [Mp4-tech] Regarding padding in MPEG-4 part 2 >> +> +> > +> +> +> > +> +> +> > +> Dear experts, >> +> +> > +> +> +> > +> assume that a simple profile video stream with >> height and +> +> > +> width of 120 and 170 pixels respectively shall be >> decoded. +> +> > +> The bounding rectangle of the reference VOP is >> 128x176. Now +> +> > +> my question is whether you should pad outside of >> 120x170 or +> +> > +> 128x176 when referencing pixels for motion >> compensation? >> +> +> > +> +> +> > +> The relevant part of the standard is section 7.6.4 >> i believe +> +> > +> (I looking at the 3rd edition, that's ISO/IEC +> +> >> 14496-2:2004, N5515): >> +> +> > +> +> +> > +> The coordinates of a reference sample in the >> reference VOP, +> +> > +> (yref, xref) is determined as follows : >> +> +> > +> xref = MIN ( MAX (xcurr+dx, vhmcsr), xdim+vhmcsr-1 ) >> +> +> > +> yref = MIN ( MAX (ycurr+dy, vvmcsr), ydim+vvmcsr-1) >> +> +> > +> +> +> > +> My interpretation of this is that padding should be >> done +> +> > +> outside of 128x176 (this means that the pixels outside of >> +> +> > +> 120x170 but inside of 128x176 shall be left as they were +> +> >> > +> decoded), is this correct? >> +> +> > +> +> +> > +> Is there any conformance bitstream that tests this >> behaviour? >> +> +> > +> +> +> > +> / >> +> +> > +> Rickard Sjoberg >> +> +> > +> Ericsson >> +> +> > +> +> +> > +> _______________________________________________ >> +> +> > +> 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-Ant >> +> +> itrust.php >> +> +> > +> +> +> +> -- >> +> +> Herbert Thoma >> +> +> Head of Video Group >> +> +> Multimedia Realtime Systems Department >> +> +> Fraunhofer IIS >> +> +> Am Wolfsmantel 33, 91058 Erlangen, Germany >> +> +> Phone: +49-9131-776-323 >> +> +> Fax: +49-9131-776-399 >> +> +> email: tma@iis.fhg.de >> +> +> www: http://www.iis.fhg.de/ >> +> +> > > -- > Herbert Thoma > Head of Video Group > Multimedia Realtime Systems Department > Fraunhofer IIS > Am Wolfsmantel 33, 91058 Erlangen, Germany > Phone: +49-9131-776-323 > Fax: +49-9131-776-399 > email: tma@iis.fhg.de > www: http://www.iis.fhg.de/ > From behrooz_ca yahoo.ca Fri Nov 24 20:45:19 2006 From: behrooz_ca yahoo.ca (behrooz hamidian) Date: Sat Nov 25 10:10:13 2006 Subject: [Mp4-tech] MbLineIntraUpdate parameter Message-ID: <279820.76413.qm@web34412.mail.mud.yahoo.com> Dear experts I am currently running some simulation using the JM.11 source code for H.264 codec. I need to encode a sequence such that in each frame a minimum number of macroblocks are coded in intra mode.I tried to use the parameter "MbLineIntraUpdate" in the encoder config file for this purpose.This parameter must be set to a value in the interval [0,1].My initial guess was that this value should represents the percentage of the macroblocks coded in intra mode. My problem is that the encoder only mind this parameter when it is set to 1, and with "MbLineIntraUpdate=1" I got 22 intra coded macroblocks in each frame of a CIF file (which has 396 MBs per frame). So the simulation results completely contradicts my initial guess. I am wondering if anyone could give me some information on the "MbLineIntraUpdate" parameter in encoder config file. thank you in advance , Behrooz Behrooz Hamidian Ph.D. Candidate School of Engineering Science Simon Fraser University Vancouver, Biritish Columbia, V5B 1S6 --------------------------------- Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061124/d4275c60/attachment.html From mp4-tech-owner lists.mpegif.org Sat Nov 25 15:10:22 2006 From: mp4-tech-owner lists.mpegif.org (MPEGIF List Admins) Date: Sat Nov 25 21:28:07 2006 Subject: FW: [Mp4-tech] MbLineIntraUpdate parameter Message-ID: <002601c7109b$7282d2a0$6401a8c0@corp.intertrust.com> Another message that was discarded because it was sent from an address that is not on the list. Please do remember to send from a subscribed address, or to subbscribe with your sending address. (In this case, the "elis" server name in the email address is the problem.) In incredible amount of spam mail gets sent to this list. You never see any of it, though, and a strict sender policy is part of keeping the list spam-free. thanks. _____ From: Wesley De Neve [mailto:Wesley.DeNeve@elis.ugent.be] Sent: Saturday, 25 November 2023 12:43 To: behrooz hamidian; mp4-tech@lists.mpegif.org Subject: Re: [Mp4-tech] MbLineIntraUpdate parameter Dear Behrooz, The parameter RandomIntraMBRefresh is probably of more interest to you. I would also suggest to have a look at the JM Reference Software Manual, which can be found on the following URL: http://iphome.hhi.de/suehring/tml/ This manual contains information about the different parameters used by the H/264/AVC reference software. Best regards, Wesley De Neve ----- Original Message ----- From: behrooz hamidian To: mp4-tech@lists.mpegif.org Sent: Saturday, November 25, 2023 2:45 AM Subject: [Mp4-tech] MbLineIntraUpdate parameter Dear experts I am currently running some simulation using the JM.11 source code for H.264 codec. I need to encode a sequence such that in each frame a minimum number of macroblocks are coded in intra mode.I tried to use the parameter "MbLineIntraUpdate" in the encoder config file for this purpose.This parameter must be set to a value in the interval [0,1].My initial guess was that this value should represents the percentage of the macroblocks coded in intra mode. My problem is that the encoder only mind this parameter when it is set to 1, and with "MbLineIntraUpdate=1" I got 22 intra coded macroblocks in each frame of a CIF file (which has 396 MBs per frame). So the simulation results completely contradicts my initial guess. I am wondering if anyone could give me some information on the "MbLineIntraUpdate" parameter in encoder config file. thank you in advance , Behrooz Behrooz Hamidian Ph.D. Candidate School of Engineering Science Simon Fraser University Vancouver, Biritish Columbia, V5B 1S6 _____ Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail _____ _______________________________________________ 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/20061125/74408ab3/attachment.html From mrivers06 gmail.com Tue Nov 28 12:49:26 2006 From: mrivers06 gmail.com (Michael Rivers) Date: Tue Nov 28 14:16:09 2006 Subject: [Mp4-tech] Skip frames in H.264 Message-ID: Hello Everyone, Is there a way in H.264 to report the skip of the encoding of a frame without having to use Annex D or Annex E (VUI and SEI) and without relaying on levels above H.264, like RTP for example. From what I understand framenum can not be used for those purposes, is that correct? Thanks and best regards, Gorka -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061128/549ed6bd/attachment.html From ralph.sperschneider iis.fraunhofer.de Tue Nov 28 14:28:16 2006 From: ralph.sperschneider iis.fraunhofer.de (Ralph Sperschneider) Date: Tue Nov 28 14:16:15 2006 Subject: [Mp4-tech] Re: [audio] AAC with LATM decoding? In-Reply-To: <000c01c6a42b$5a98a520$6401a8c0@FERGUSON> References: <03CB47D9C3F8074498E4653F814D6E8F0144A901@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> <000c01c6a42b$5a98a520$6401a8c0@FERGUSON> Message-ID: <456C3970.105@iis.fraunhofer.de> Danijel Domazet wrote: > Hi all, > Is there an AAC decoder/player capable of decoding aac with LATM headers? > > Danijel Dear Danijel, the MPEG-4 Audio reference software decoder is capable to decode aac with LATM header. This software (the latest publicly available version) can be retrieved here: http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_IEC_14496-5_2001_Amd_6_Reference_Software/audio.zip Run "make mp4audec" in the subdirectory audio/natural/mp4AudVm_Rewrite. Best regards, Ralph -- Dipl.-Ing. Ralph Sperschneider | Phone: +49 9131 776 344 Fraunhofer IIS | Fax: +49 9131 776 398 Am Wolfsmantel 33 | mailto:ralph.sperschneider@iis.fraunhofer.de D 91058 Erlangen | http://www.iis.fraunhofer.de/amm/ From garysull windows.microsoft.com Tue Nov 28 10:05:08 2006 From: garysull windows.microsoft.com (Gary Sullivan) Date: Tue Nov 28 18:16:07 2006 Subject: [Mp4-tech] Skip frames in H.264 In-Reply-To: Message-ID: <03CB47D9C3F8074498E4653F814D6E8F02FC01A1@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> If you have fixed_frame_rate_flag = 0, there is really no need to indicate that you are "skipping" a frame -- to skip a frame you simply don't send it. If you have fixed_frame_rate_flag = 1, the best method is perhaps to send a slice in which all macroblocks of the entire picture are coded in P_Skip mode. Such a slice would be representable with very few bits. Best Regards, Gary Sullivan ________________________________ From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Michael Rivers Sent: Tuesday, November 28, 2023 3:49 AM To: mp4-tech@lists.mpegif.org Subject: [Mp4-tech] Skip frames in H.264 Hello Everyone, Is there a way in H.264 to report the skip of the encoding of a frame without having to use Annex D or Annex E (VUI and SEI) and without relaying on levels above H.264, like RTP for example. From what I understand framenum can not be used for those purposes, is that correct? Thanks and best regards, Gorka -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061128/988e67d7/attachment.html From ralph.sperschneider iis.fraunhofer.de Wed Nov 29 07:38:51 2006 From: ralph.sperschneider iis.fraunhofer.de (Ralph Sperschneider) Date: Wed Nov 29 06:46:07 2006 Subject: [Mp4-tech] Re:[audio] AAC file duration In-Reply-To: References: Message-ID: <456D2AFB.8080207@iis.fraunhofer.de> Madhurima.A@aricent.com wrote: > > > Hi > > I am implemneting AAC player. > But I am facing problems in extracting the file duration. If I go and > parse the whole file, time calculated is approximately same, but this > takes considerable amount of time. > > Can anybody help me on this. > How can I know the bit rate in case of a VBR file with ADTS/ADIF formats > > > Regards, > Madhurima > > Dear Madhurima! For ADIF, I do not see a simple solution in the case of VBR. In the case of CBR the file duration can be derived based on the file length (the only uncertainty is the difference of the bit reservoir stages at the begin and the end of the file): file_duration [s] = file_len [bit] / bitrate [bit/s] For ADTS, you can count the available AAC frames (in the case of VBR and CBR). This should be easy since the length of the frames is given in the headers (only the header needs to be parsed in order to identify the location of the next header). Based on the number of frames and the sampling rate you can then derive the file duration: frame_duration [s/frame] = 1024 [sample/frame] / sampling_rate [sample/s] file_duration [s] = frame_duration [s/frame] * frame_cnt [frame] Best regards, Ralph -- Dipl.-Ing. Ralph Sperschneider | Phone: +49 9131 776 344 Fraunhofer IIS | Fax: +49 9131 776 398 Am Wolfsmantel 33 | mailto:ralph.sperschneider@iis.fraunhofer.de D 91058 Erlangen | http://www.iis.fraunhofer.de/amm/ From gvgrao_spl yahoo.com Tue Nov 28 21:59:02 2006 From: gvgrao_spl yahoo.com (venu rao) Date: Wed Nov 29 08:22:10 2006 Subject: [Mp4-tech] Re: [audiodsp] aac doubt In-Reply-To: <416061.14079.qm@web34811.mail.mud.yahoo.com> Message-ID: <219752.33413.qm@web53212.mail.yahoo.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: grouping_sectioning.pdf Type: application/pdf Size: 408082 bytes Desc: 2362668756-grouping_sectioning.pdf Url : /pipermail/mp4-tech/attachments/20061128/9c35cdb4/grouping_sectioning-0001.pdf From rgomathi sarayusoftech.com Wed Nov 29 15:17:24 2006 From: rgomathi sarayusoftech.com (rgomathi@sarayusoftech.com) Date: Wed Nov 29 14:10:09 2006 Subject: [Mp4-tech] AVI File Parser Message-ID: <38926.192.168.100.222.1164793644.squirrel@192.168.100.222> Dear all, Is there any open source code for AVI file parser(in C).If it is so,please let me know where to get it. I will be thankful if somebody replies as soon as possible. Thanks in advance Regards, Gomathi. From Anshuman.Goyal hcl.in Thu Nov 30 11:07:00 2006 From: Anshuman.Goyal hcl.in (Anshuman Goyal, Noida) Date: Thu Nov 30 08:46:07 2006 Subject: [Mp4-tech] Information On ASP Testing Clips Message-ID: <539C0A297AA0C74581CB5AF82D53729104203F3C@HSDLNTD1110010.noida.hcltech.com> Hi, I am working on Advanced Simple Profile for MPEG-4. The following ASP clips mentioned in ASP standard for testing have OBMC enabled in them, while it has been mentioned that the OBMC mode is not present in the ASP Profile. Please let me know if there is any revised version for these clips to fix this problem and also the place where I can download the updated versions. 1. vcon-ge18.cmp 2. vcon-ge24.cmp 3. vcon-ge25.cmp 4. vcon-ge3.cmp Also I was not able to find the following 14 clips mentioned in the ASP standard for testing. Please let me know where I can download these clips from: 1. A1GE-11-L0.cmp 2. a1ge-4_ace.bits 3. a1ge-9_ace_l0.bits 4. a1ge-9_ace_l5.bits 5. vcon-ge13-L0.bits 6. vcon-ge13-L4.bits 7. vcon-ge13-L5.bits 8. vcon-ge16-L0.bits 9. vcon-ge16-L4.bits 10. vcon-ge16-L5.bits 11. vcon_a1ge_10_ace_l0.bits 12. vcon_a1ge_13_ace_l0.bits 13. vcon_a1ge_13_ace_l5.bits 14. con_a1ge_1_ace_l5.bits Warm Regards, Anshuman Goyal Member Technical Staff, HCL Technologies Limited A-5, Sector - 24 | Noida - 201301 (U.P, India)| Mob: +91-99113-95854 Office: +91-120-2411502 x 2547 anshumangoyal@gmail.com DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20061130/af15832f/attachment.html From rgomathi sarayusoftech.com Thu Nov 30 19:04:56 2006 From: rgomathi sarayusoftech.com (rgomathi@sarayusoftech.com) Date: Thu Nov 30 15:52:12 2006 Subject: [Mp4-tech] Re: [audiodsp] AVI File Parser In-Reply-To: <7.0.1.0.2.20061129104207.0284b0d0@sbcglobal.net> References: <38926.192.168.100.222.1164793644.squirrel@192.168.100.222> <7.0.1.0.2.20061129104207.0284b0d0@sbcglobal.net> Message-ID: <38390.192.168.100.222.1164893696.squirrel@192.168.100.222> > Dear all, Thanks a lot for ur replies.and i have another doubt...is there anything to convert c++ code to c.I know only c that's why i'm asking..and if it is of no sense please forgive me.....expecting replies... thanks in advance Gomathi. Gomathi: > > You can take a look at: > http://avifile.sourceforge.net/ > > There are probably many others that you can look for at: > http://freshmeat.net/ > > By the way, the specification for the AVI file format is at: > http://www.wotsit.org/ > > HTH, > g. > > At 03:47 AM 11/29/2006, rgomathi@sarayusoftech.com wrote: > > >>Dear all, >>Is there any open source code for AVI file parser(in C).If it is >>so,please let me know where to get it. I will be thankful if somebody >>replies as soon as possible. >> >>Thanks in advance >>Regards, >>Gomathi. >>__._,_.___ >>Messages >>in this topic (1) >>Reply >>(via web post) | >>Start >>a new topic >>Messages >> >>NEW! You can now post a message or access and search the archives >>of this group on DSPRelated.com: >>http://www.dsprelated.com/groups/audiodsp/1.php >> >>_____________________________________ >>Note: If you do a simple "reply" with your email client, only the >>author of this message will receive your answer. You need to do a >>"reply all" if you want your answer to be distributed to the entire >> group. >> >>_____________________________________ >>About this discussion group: >> >>Archives: >>http://www.dsprelated.com/groups/audiodsp/1.php >> >>To Post: Send an email to audiodsp@yahoogroups.com >> >>Other DSP Related Groups: >>http://www.dsprelated.com/groups.php >> >>Yahoo! Groups >> >>Change >>settings via the Web (Yahoo! ID required) >>Change settings via email: >>>Digest>Switch delivery to Daily Digest | >>>Format: Traditional>Switch format to Traditional >>Visit >>Your Group | Yahoo! Groups Terms >>of Use | >> Unsubscribe >>Recent Activity >> * 3 >> New >> Members >>Visit >>Your Group >>SPONSORED LINKS >> * >> Digital >> signal processing >> * >> Signal >> processing >> * >> Computer >> job >> * >> Communication >> and networking >> * >> Computer >> technician jobs >>New business? >> >>Get >>new customers. >> >>List your web site >> >>in Yahoo! Search. >>Y! Messenger >> >>Instant >>smiles >> >>Share photos while >> >>you IM friends. >>Yahoo! Groups >> >>Start >>a group >> >>in 3 easy steps. >> >>Connect with others. >>. >> >>__,_._,___ > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > >