From rkoenen intertrust.com Wed May 1 13:19:33 2002 From: rkoenen intertrust.com (Rob Koenen) Date: Wed Jul 30 14:07:55 2003 Subject: [M4IF Technotes] Question MPEG-2 vs MPEG-4. Message-ID: <3C124172E7FDD511B510000347426D59AF5354@exchange.epr.com> You are better off starting with an MPEG-4 open source project or the MPEG-4 REference code. See http://www.m4if.org/resources.php for pointers Kind Regards, Rob > -----Original Message----- > From: Alejandro RAMIREZ [mailto:aara10@hotmail.com] > Sent: Tuesday, April 30, 2024 11:44 > To: martinf@dvd.panasonic.com; technotes@lists.m4if.org > Subject: [M4IF Technotes] Question MPEG-2 vs MPEG-4. > > > Hi, > > I am confronted with the following problem: > I must implement a coder MPEG-4 starting from a coder MPEG-2. > I have the > source code of the coder MPEG-2. Initially I would have liked > to know if > that were possible. > In the second time, if that is possible, the reasoning below > is it correct? > I thought to change VLC part of coder MPEG-2 by VLC part of > the coder MPEG-4 > who is specified in the standard 14496-2(version paper) and > also to implant > the headings specified inside. And to keep the DCT, the > quantification, the > RL, the movement estimation, and the rate control(TM5) by the > coder MPEG-2 > which I have already. > > The reasoning is it good? or requires it more work? > Is this better to start from a coder MPEG-4 directly because > the differences > between coder MPEG-2 and MPEG-4 are too significant? > > Thank you for your answers, > > Alejandro > > > _________________________________________________________________ > MSN Photos est le moyen le plus simple de partager et > d'imprimer vos photos > : http://photos.msn.com/support/worldwide.aspx > > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes > From sps iis.fhg.de Thu May 2 14:16:45 2002 From: sps iis.fhg.de (Ralph Sperschneider) Date: Wed Jul 30 14:07:55 2003 Subject: [M4IF Technotes] Re: Question MPEG-2 vs MPEG-4. References: Message-ID: <3CD1201D.D3BDC728@iis.fhg.de> Dear Alejandro, all, may I kindly suggest to distinguish more clearly between Systems, Video, Audio, or any other part of MPEG-2/4 already in the Subject? It would help to find out more easily whether one can or cannot comment on the topic. Best regards, Ralph Alejandro RAMIREZ wrote: > > Hi, > > I am confronted with the following problem: > I must implement a coder MPEG-4 starting from a coder MPEG-2. I have the > source code of the coder MPEG-2. Initially I would have liked to know if > that were possible. > In the second time, if that is possible, the reasoning below is it correct? > I thought to change VLC part of coder MPEG-2 by VLC part of the coder MPEG-4 > who is specified in the standard 14496-2(version paper) and also to implant > the headings specified inside. And to keep the DCT, the quantification, the > RL, the movement estimation, and the rate control(TM5) by the coder MPEG-2 > which I have already. > > The reasoning is it good? or requires it more work? > Is this better to start from a coder MPEG-4 directly because the differences > between coder MPEG-2 and MPEG-4 are too significant? > > Thank you for your answers, > > Alejandro > > _________________________________________________________________ > MSN Photos est le moyen le plus simple de partager et d'imprimer vos photos > : http://photos.msn.com/support/worldwide.aspx > > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes -- Dipl.-Ing. Ralph Sperschneider | Phone: +49 9131 776 344 FhG IIS-A | Fax: +49 9131 776 398 Am Weichselgarten 3 | mailto:sps@iis.fhg.de D 91058 Erlangen | http://www.iis.fhg.de/amm/ -------------- next part -------------- A non-text attachment was scrubbed... Name: sps.vcf Type: text/x-vcard Size: 336 bytes Desc: Card for Ralph Sperschneider Url : /pipermail/mp4-tech/attachments/20020502/71a381aa/sps.bin From anil.kumar ittiam.com Thu May 2 17:16:18 2002 From: anil.kumar ittiam.com (Anil Kumar) Date: Wed Jul 30 14:07:55 2003 Subject: [M4IF Technotes] mpeg-4 AAC conformance bit-streams Message-ID: <45A1F95BB9D7D84FAB0A1EB4D67EEF9638CA61@IS01EX01.ittiam.com> Hi all, I am searching for the mpeg-4 AAC PNS conformance bit-streams. Also, if anybody can tell me where to find the error-resiliance code for mpeg-4 AAC and Low delay AAC, it will be very helpful thanks in advance, Anil From axel.binder philips.com Thu May 2 14:20:09 2002 From: axel.binder philips.com (axel.binder@philips.com) Date: Wed Jul 30 14:07:55 2003 Subject: [M4IF Technotes] unsubscribe exkoda Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20020502/037bd579/attachment.html From sps iis.fhg.de Thu May 2 15:56:26 2002 From: sps iis.fhg.de (Ralph Sperschneider) Date: Wed Jul 30 14:07:55 2003 Subject: [M4IF Technotes] Re: mpeg-4 AAC conformance bit-streams References: <45A1F95BB9D7D84FAB0A1EB4D67EEF9638CA61@IS01EX01.ittiam.com> Message-ID: <3CD1377A.140B3CE8@iis.fhg.de> Dear Anil, Anil Kumar wrote: > > Hi all, > I am searching for the mpeg-4 AAC PNS conformance bit-streams. There are two sequences defined, al09 and al10. These sequences can be found here: ftp://mpaudcon:adif2mp4@ftp.iis.fhg.de:/guests/mpeg4audio/incoming/testSequences/mpeg4audio-conformance/compressedMp4/al09* ftp://mpaudcon:adif2mp4@ftp.iis.fhg.de:/guests/mpeg4audio/incoming/testSequences/mpeg4audio-conformance/compressedMp4/al10* > Also, if anybody can tell me where to find the error-resiliance code for > mpeg-4 AAC and Low delay AAC, it will be very helpful Assuming that you are not an MPEG member, I can just state that this code is part of the reference software being available by ISO (ISO/IEC 14496-5:2001). The error-resilience code is available in the subdirectory aacErrRobTrans (encoding part) and in the subdirectory mp4AudVm (decoding part). The low delay AAC code is available in the subdirectory mp4AudVm (encoding and decoding part). Best regards, Ralph -- Dipl.-Ing. Ralph Sperschneider | Phone: +49 9131 776 344 FhG IIS-A | Fax: +49 9131 776 398 Am Weichselgarten 3 | mailto:sps@iis.fhg.de D 91058 Erlangen | http://www.iis.fhg.de/amm/ -------------- next part -------------- A non-text attachment was scrubbed... Name: sps.vcf Type: text/x-vcard Size: 336 bytes Desc: Card for Ralph Sperschneider Url : /pipermail/mp4-tech/attachments/20020502/0923f0e9/sps.bin From pforman sbcglobal.net Thu May 2 09:42:55 2002 From: pforman sbcglobal.net (Peter Forman) Date: Wed Jul 30 14:07:55 2003 Subject: [M4IF Technotes] Motion vectors and Modes In-Reply-To: Message-ID: <000701c1f1f0$07724960$87011eac@demografx.com> Does anyone know of any papers documenting the similarities and differences in motion vectors and modes between MPEG2 and MPEG4? Or between MPEG4 and H.26L/JVT WD? Pointers to any such work would be appreciated. Peter From the_ether btinternet.com Thu May 2 18:11:57 2002 From: the_ether btinternet.com (the_ether) Date: Wed Jul 30 14:07:55 2003 Subject: [M4IF Technotes] Motion vectors and Modes References: <000701c1f1f0$07724960$87011eac@demografx.com> Message-ID: <007101c1f1f4$2d8268c0$1f0823d9@home> There's always, "Multimedia systems, standards and networks" by Atul Puri and Tsuhan Chen. V pricey though: about $150 if I remember correctly. But it starts with h323 and goes all the way to MPEG4 ----- Original Message ----- From: "Peter Forman" To: Sent: Thursday, May 02, 2024 4:42 PM Subject: [M4IF Technotes] Motion vectors and Modes > > Does anyone know of any papers documenting the similarities and > differences in motion vectors and modes between MPEG2 and MPEG4? Or > between MPEG4 and H.26L/JVT WD? Pointers to any such work would be > appreciated. > > Peter > > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes > From wjf NetworkXXIII.com Thu May 2 12:46:12 2002 From: wjf NetworkXXIII.com (William J. Fulco) Date: Wed Jul 30 14:07:55 2003 Subject: [M4IF Technotes] Motion vectors and Modes In-Reply-To: <000701c1f1f0$07724960$87011eac@demografx.com> Message-ID: Peter, Here's a handy-dandy article I have in the files.... (I cut/paste the bib reference) "Transcoding" should give you good insights into difference/similarities (if you want I can copy and run it over :-)... ++Bill 1. Motion vector synthesis algorithm for MPEG2-to-MPEG4 transcoder Takahashi, K.;(Shirota Digital Systems Laboratory, Info. and Network Technologies Lab., Sony Corporation, Tokyo, Japan);Satoh, K.;Suzuki, T.;Yagasaki, Y.; Source: Proceedings of SPIE - The International Society for Optical Engineering, v 4310, 2001, Visual Communications and Image Processing 2001, Jan 24-26 2001, San Jose, CA, p 872-882 Sponsored by: SPIE ISSN: 0277-786X CODEN: PSISDG In English Abstract: We have developed a Motion Vector (MV) Synthesis algorithm for an MPEG2-to-MPEG4 transcoder. MPEG2 bitstream parameters are utilized to adaptively scale and refine the MPEG2 MVs to synthesize MPEG4 MVs. The simulation results show that our MV Synthesis algorithm produces results that are equivalent to VM Full Search in both coding efficiency and subjective image quality, with significant reduction in complexity. William J. Fulco wjf@NetworkXXIII.com 310-927-4263 Cell --------------------------------- Logic: When you absolutely, positively have to refute every fallacy in the room. > -----Original Message----- > From: technotes-admin@lists.m4if.org > [mailto:technotes-admin@lists.m4if.org]On Behalf Of Peter Forman > Sent: Thursday, May 02, 2024 8:43 AM > To: technotes@lists.m4if.org > Subject: [M4IF Technotes] Motion vectors and Modes > > > > Does anyone know of any papers documenting the similarities and > differences in motion vectors and modes between MPEG2 and MPEG4? Or > between MPEG4 and H.26L/JVT WD? Pointers to any such work would be > appreciated. > > Peter > > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes > From sps iis.fhg.de Thu May 2 21:47:12 2002 From: sps iis.fhg.de (Ralph Sperschneider) Date: Wed Jul 30 14:07:55 2003 Subject: [M4IF Technotes] Re: mpeg-4 AAC conformance bit-streams References: <45A1F95BB9D7D84FAB0A1EB4D67EEF9638CA61@IS01EX01.ittiam.com> <3CD1377A.140B3CE8@iis.fhg.de> Message-ID: <3CD189B0.BCFD4A50@iis.fhg.de> Dear Anil, all, sorry for any inconvenience. There is an "f" missing at the end of the accont name. The link is actually: ftp://mpaudconf:adif2mp4@ftp.iis.fhg.de/guests/mpeg4audio/incoming/testSequences/mpeg4audio-conformance/ The subdirectory compressedMp4 contains the compressed data in mp4 file format. The subdirectory referenceWavZip contains the uncompressed but ziped waveforms in 24 bit resolution. Best regards, Ralph Ralph Sperschneider wrote: > > Dear Anil, > > Anil Kumar wrote: > > > > Hi all, > > I am searching for the mpeg-4 AAC PNS conformance bit-streams. > > There are two sequences defined, al09 and al10. These sequences can be found here: > > ftp://mpaudcon:adif2mp4@ftp.iis.fhg.de:/guests/mpeg4audio/incoming/testSequences/mpeg4audio-conformance/compressedMp4/al09* > ftp://mpaudcon:adif2mp4@ftp.iis.fhg.de:/guests/mpeg4audio/incoming/testSequences/mpeg4audio-conformance/compressedMp4/al10* > > > Also, if anybody can tell me where to find the error-resiliance code for > > mpeg-4 AAC and Low delay AAC, it will be very helpful > > Assuming that you are not an MPEG member, I can just state that this code is part of the reference software being available by ISO (ISO/IEC 14496-5:2001). The error-resilience code is available in the subdirectory aacErrRobTrans (encoding part) and in the subdirectory mp4AudVm (decoding part). The low delay AAC code is available in the subdirectory mp4AudVm (encoding and decoding part). > > Best regards, > > Ralph > -- > Dipl.-Ing. Ralph Sperschneider | Phone: +49 9131 776 344 > FhG IIS-A | Fax: +49 9131 776 398 > Am Weichselgarten 3 | mailto:sps@iis.fhg.de > D 91058 Erlangen | http://www.iis.fhg.de/amm/ -- Dipl.-Ing. Ralph Sperschneider | Phone: +49 9131 776 344 FhG IIS-A | Fax: +49 9131 776 398 Am Weichselgarten 3 | mailto:sps@iis.fhg.de D 91058 Erlangen | http://www.iis.fhg.de/amm/ -------------- next part -------------- A non-text attachment was scrubbed... Name: sps.vcf Type: text/x-vcard Size: 336 bytes Desc: Card for Ralph Sperschneider Url : /pipermail/mp4-tech/attachments/20020502/c58c3967/sps.bin From aara10 hotmail.com Fri May 3 03:07:20 2002 From: aara10 hotmail.com (Alejandro RAMIREZ) Date: Wed Jul 30 14:07:56 2003 Subject: [M4IF Technotes] More MPEG-2 vs MPEG-4 Message-ID: Hi, _________________________________________________________________ Envoyez et recevez des messages Hotmail sur votre p?riph?rique mobile : http://mobile.msn.com -------------- next part -------------- A non-text attachment was scrubbed... Name: MPEG2vsMPEG4.doc Type: application/msword Size: 22528 bytes Desc: not available Url : /pipermail/mp4-tech/attachments/20020503/08c03bdb/MPEG2vsMPEG4.bin From gnitin noida.hcltech.com Fri May 3 12:01:13 2002 From: gnitin noida.hcltech.com (Nitin Gupta--DSP, Noida) Date: Wed Jul 30 14:07:56 2003 Subject: [M4IF Technotes] Stuffing Bit Pattern for Start Codes Message-ID: Hi Neelkanth & all, Q :- I parsed 4 bits to reach the byte aligned position, shall I now look for 8 bit stuffing if the start code is not present? To this the answer in all probability is NO .. u need not look for any more stuffing bits once u have reached a byte aligned position .. so if u don't find the start marker (it can be a user_data_start_code , vop_start_code or it can be the resync marker as resync markers are also byte aligned in case of video packets being present in the vop ) , then the most probable condition is that there is an error present in the bitstream. This can be concluded from the fact that the standard never says at any point of time that u need to go to the next byte aligned position in case u don't find a marker after u have reached a particular byte aligned position. Also with the experience of decoding more than 100 mpeg4 conformance streams, i never confronted such a case. I replied to this query as there is no reply from anyone for some time. Plz correct me if i m wrong. Hope my reply helps u. Thanx & Regards, Nitin Gupta HCL Technologies, Noida, India. -----Original Message----- From: Neelakanth [mailto:neel2265@yahoo.com] Sent: Friday, April 26, 2024 12:25 PM To: technotes@lists.m4if.org Subject: [M4IF Technotes] Stuffing Bit Pattern for Start Codes Hi, Please refer to 5.2.4 (Definition of next_start_code() function) of ISO/IEC 14496-2 (MPEG-4 Video Standard). In this function stuffing bit are parsed to go to next byte aligned position. The stuffing bits can be upto 8 ( 8 if position is already byte-aligned ). I want to know that once we have reached the byte aligned position then also shall we look for stuffing bits? For example I parsed 4 bits to reach the byte aligned position, shall I now look for 8 bit stuffing if the start code is not present? Thanks and Regards Neelakanth _____ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20020503/278ea408/attachment.html From i.g.richardson rgu.ac.uk Fri May 3 10:21:35 2002 From: i.g.richardson rgu.ac.uk (Iain Richardson (ensigr)) Date: Wed Jul 30 14:07:56 2003 Subject: [M4IF Technotes] Motion vectors and Modes Message-ID: <9B4C0CE0F5BE4E4F83226707BFA0D1B42D07A2@EXVS001.rgu.ac.uk> [Shameless plug] There is an overview of the motion models & mode decisions of MPEG2, MPEG4 and H.26L/AVC in my new book, "Video CODEC Design" www.vcodex.com/videocodecdesign/ www.wileyeurope.com/cda/product/0,,0471485535,00.html Regards Iain Richardson Message: 6 Reply-To: From: "Peter Forman" To: Date: Thu, 2 May 2024 08:42:55 -0700 Organization: Peter Forman Subject: [M4IF Technotes] Motion vectors and Modes Does anyone know of any papers documenting the similarities and differences in motion vectors and modes between MPEG2 and MPEG4? Or between MPEG4 and H.26L/JVT WD? Pointers to any such work would be appreciated. Peter From sps iis.fhg.de Fri May 3 13:26:19 2002 From: sps iis.fhg.de (Ralph Sperschneider) Date: Wed Jul 30 14:07:56 2003 Subject: [M4IF Technotes] Re: mpeg-4 AAC conformance bit-streams References: Message-ID: <3CD265CB.AEBDDEA6@iis.fhg.de> Dear Munsi, all, sorry for bothering you again. You might not use the IE to browse the ftp server, since it has problems with the servers configuration. Just use the Communicator, or any plain ftp client. Hope this helps, Ralph > Munsi Haque wrote: > > Hi > > I can see some file names, but cannot copy, etc. > > ... > Munsi Haque > > -----Original Message----- > From: Ralph Sperschneider [mailto:sps@iis.fhg.de] > Sent: Thursday, May 02, 2024 11:47 AM > To: Anil Kumar; technotes@lists.m4if.org > Subject: [M4IF Technotes] Re: mpeg-4 AAC conformance bit-streams > > Dear Anil, all, > > sorry for any inconvenience. There is an "f" missing at the end of the accont name. The link is actually: > > ftp://mpaudconf:adif2mp4@ftp.iis.fhg.de/guests/mpeg4audio/incoming/testSequences/mpeg4audio-conformance/ > > The subdirectory compressedMp4 contains the compressed data in mp4 file format. > The subdirectory referenceWavZip contains the uncompressed but ziped waveforms in 24 bit resolution. > > Best regards, > > Ralph > > Ralph Sperschneider wrote: > > > > Dear Anil, > > > > Anil Kumar wrote: > > > > > > Hi all, > > > I am searching for the mpeg-4 AAC PNS conformance bit-streams. > > > > There are two sequences defined, al09 and al10. These sequences can be found here: > > > > ftp://mpaudcon:adif2mp4@ftp.iis.fhg.de:/guests/mpeg4audio/incoming/testSequences/mpeg4audio-conformance/compressedMp4/al09* > > > ftp://mpaudcon:adif2mp4@ftp.iis.fhg.de:/guests/mpeg4audio/incoming/testSequences/mpeg4audio-conformance/compressedMp4/al10* > > > > > > Also, if anybody can tell me where to find the error-resiliance code for > > > mpeg-4 AAC and Low delay AAC, it will be very helpful > > > > Assuming that you are not an MPEG member, I can just state that this code is part of the reference software being available by ISO (ISO/IEC 14496-5:2001). The error-resilience code is available in the subdirectory aacErrRobTrans (encoding part) and in the subdirectory mp4AudVm (decoding part). The low delay AAC code is available in the subdirectory mp4AudVm (encoding and decoding part). > > > > > Best regards, > > > > Ralph > > -- > > Dipl.-Ing. Ralph Sperschneider | Phone: +49 9131 776 344 > > FhG IIS-A | Fax: +49 9131 776 398 > > Am Weichselgarten 3 | mailto:sps@iis.fhg.de > > D 91058 Erlangen | http://www.iis.fhg.de/amm/ > > -- > Dipl.-Ing. Ralph Sperschneider | Phone: +49 9131 776 344 > FhG IIS-A | Fax: +49 9131 776 398 > Am Weichselgarten 3 | mailto:sps@iis.fhg.de > D 91058 Erlangen | http://www.iis.fhg.de/amm/ -- Dipl.-Ing. Ralph Sperschneider | Phone: +49 9131 776 344 FhG IIS-A | Fax: +49 9131 776 398 Am Weichselgarten 3 | mailto:sps@iis.fhg.de D 91058 Erlangen | http://www.iis.fhg.de/amm/ -------------- next part -------------- A non-text attachment was scrubbed... Name: sps.vcf Type: text/x-vcard Size: 336 bytes Desc: Card for Ralph Sperschneider Url : /pipermail/mp4-tech/attachments/20020503/0382f4df/sps.bin From harinarayan_s hotmail.com Fri May 3 12:16:05 2002 From: harinarayan_s hotmail.com (Hari Narayan S.) Date: Wed Jul 30 14:07:56 2003 Subject: [M4IF Technotes] VTC... regarding initialization of arithmetic coder for SQ mode Message-ID: Hello! I have some problems with the VTC part given in the FDIS. For single quant mode and tree-depth scanning, I beleive that there can't be any bit planes since according to ZTE, the quant_byte is transmitted and based on that we can do the decoding. Now the problem lies in the FDIS which asks us to read max_bitplane in TextureLayerSQ(). For the DC band, according to FDIS, the arithmetic coder is initialized after finding band_max_value. What about the AC bands... how is the arithmetic coder initialized (for SQ and tree-depth scanning)? Can anyone clear my confusion ;-) Thanks! Bye! Hari _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From a.ilangovan gdatech.co.in Fri May 3 23:08:58 2002 From: a.ilangovan gdatech.co.in (A.Ilangovan) Date: Wed Jul 30 14:07:56 2003 Subject: [M4IF Technotes] Request for clarifications while decoding backward using RVLC Message-ID: <001001c1f2c1$07be3380$de00a8c0@ilangovan> Dear friends, 1) For RVLC backward decoding also, we require the DC values of Ref blocks "A" and "C". To be assured of these Ref Blocks' DC values in the data_partitioned (DP) header, only the DC VLC table must be used and AC VLC table must not be used (If AC VLC table is used for DC coef, the DC is treated with other AC coeffs in the texture info and would have got corrupted in errors and also not available in DP header). The safer / simpler way to ensure this is to make "intra_dc_vlc_thr" equal to "0" in VOP header (ofcourse in VP header also), which always forces the DC VLC table for DC coefficients of all the blocks. To the extent I tried to confirm this from the standard, I am not able to find it. Am I missing it or it is missed in the standard? However, all the test bitstreams provided by the standard has "intra_dc_vlc_thr" equals "0" in such cases. But, I don't want to infer this way, and may I request confirmation from experts? Also, if this is the true and is not mentioned in the standard, it should be added in the amendments to avoid this ambiguity. 2) This confusion can be further fuelled by E.1.4.4.2.2 (page:425) which says INTRA MBs in a DP VP must be discarded even though they could have been decoded! Again, I have infered from the context that, this is applicable for INTRA MBs in P-VOPs only!! Can experts confirm this also? If this is also correct, one more item for amendments? Thank you in advance A.Ilangovan =========================================== From ramki emuzed.com Sat May 4 18:33:06 2002 From: ramki emuzed.com (Ramkishor Korada) Date: Wed Jul 30 14:07:56 2003 Subject: [M4IF Technotes] Request for clarifications while decoding backward using RVLC References: <001001c1f2c1$07be3380$de00a8c0@ilangovan> Message-ID: <010401c1f363$aafc2e10$1b0aa8c0@blr.emuzed.com> Hi, ----- Original Message ----- From: "A.Ilangovan" To: Sent: Friday, May 03, 2024 10:08 PM Subject: [M4IF Technotes] Request for clarifications while decoding backward using RVLC > Dear friends, > > 1) For RVLC backward decoding also, we require the > DC values of Ref blocks "A" and "C". To be assured of these > Ref Blocks' DC values in the data_partitioned (DP) header, > only the DC VLC table must be used and AC VLC table must > not be used (If AC VLC table is used for DC coef, the DC is > treated with other AC coeffs in the texture info and would have > got corrupted in errors and also not available in DP header). > > The safer / simpler way to ensure this is to make "intra_dc_vlc_thr" > equal to "0" in VOP header (ofcourse in VP header also), which > always forces the DC VLC table for DC coefficients of all the blocks. > > To the extent I tried to confirm this from the standard, I am not able > to find it. Am I missing it or it is missed in the standard? However, > all the test bitstreams provided by the standard has "intra_dc_vlc_thr" > equals "0" in such cases. But, I don't want to infer this way, and may > I request confirmation from experts? Also, if this is the true and is > not > mentioned in the standard, it should be added in the amendments to > avoid this ambiguity. > In simple profile at level 0, intra_dc_vlc_thr should be zero. Level 0 is aimed for wireless channels, where bit corruption is possible. > 2) This confusion can be further fuelled by E.1.4.4.2.2 (page:425) which > says INTRA MBs in a DP VP must be discarded even though they > could have been decoded! > > Again, I have infered from the context that, this is applicable for > INTRA MBs in P-VOPs only!! Can experts confirm this also? > If this is also correct, one more item for amendments? > Discaridng of INTRA MBs is recommendation only not normative. > Thank you in advance > > A.Ilangovan > =========================================== > regards, ramkishor Architect - Video Multimedia Technologies Division Emuzed India Bangalore www.emuzed.com From nigupta yahoo.com Tue May 7 05:12:21 2002 From: nigupta yahoo.com (Nitin Gupta) Date: Wed Jul 30 14:07:56 2003 Subject: [M4IF Technotes] What is 2 state Markov model for burst Error Message-ID: <20020507111221.69941.qmail@web20510.mail.yahoo.com> Hi ! I am working on the verificaion of the mpeg 4 video. Can someone explain and send links on What is 1. 2 state markov model for the burst errors 2. What is the BER 10E-2 for random noise How can I generate such errors? Links to sites , codes etc.? regards nitin __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com From i.g.richardson rgu.ac.uk Thu May 9 09:57:22 2002 From: i.g.richardson rgu.ac.uk (Iain Richardson (ensigr)) Date: Wed Jul 30 14:07:56 2003 Subject: [M4IF Technotes] Picture Coding Symposium Message-ID: <9B4C0CE0F5BE4E4F83226707BFA0D1B464D026@EXVS001.rgu.ac.uk> Hello, Apologies, this is slightly off topic - Can anyone point me towards details of the next Picture Coding Symposium ? I think it's in France in 2003 but I haven't been able to find any detailed information on the web. A related question - any good email lists for general image and video coding discussions ? I subscribe to the M4IF and VCEG lists but I'm wondering whether there is a more general list that's suitable for "serious" questions. Many thanks Iain Richardson --- Dr Iain E G Richardson Lecturer and Researcher School of Engineering, The Robert Gordon University, Aberdeen, UK Tel +44 1224 262403; Fax +44 1224 262444 i.g.richardson@rgu.ac.uk www.rgu.ac.uk/eng/ict/ From giuseppe.spampinato st.com Fri May 10 16:54:17 2002 From: giuseppe.spampinato st.com (giuseppe.spampinato@st.com) Date: Wed Jul 30 14:07:56 2003 Subject: [M4IF Technotes] How can I convert a m4v to mp4 stream? Message-ID: Hi everybody, I have elementary bitstreams .m4v (compliancy with ISO standard MPEG-4) and I want to obtain an mp4 complete stream. Could someone please say to me exactly which information I have to add before (and maybe at the end) of the mp4 stream? Is there an automatic program to do this? Thank you very much!!! Giuseppe Spampinato From dmackie cisco.com Fri May 10 12:37:45 2002 From: dmackie cisco.com (David Mackie) Date: Wed Jul 30 14:07:56 2003 Subject: [M4IF Technotes] How can I convert a m4v to mp4 stream? In-Reply-To: Message-ID: Giuseppe, I believe the mp4creator tool from our mpeg4ip open source package can do what you want. It will take a MPEG-4 video ES from a file, and create an .mp4 file from it. The mp4 file will have the video track, minimal OD and BIFS tracks (as per ISMA 1.0), and optionally an RFC 3016 hint track so the video can be streamed over IP networks. If that matches your needs, you can download the package from http://sourceforge.net/projects/mpeg4ip Dave Mackie > -----Original Message----- > From: technotes-admin@lists.m4if.org > [mailto:technotes-admin@lists.m4if.org]On Behalf Of > giuseppe.spampinato@st.com > Sent: Friday, May 10, 2024 6:54 AM > To: technotes@lists.m4if.org > Subject: [M4IF Technotes] How can I convert a m4v to mp4 stream? > > > Hi everybody, > I have elementary bitstreams .m4v > (compliancy with ISO standard MPEG-4) > and I want to obtain an mp4 complete stream. > > Could someone please say to me exactly which > information I have to add before (and maybe > at the end) of the mp4 stream? > > Is there an automatic program to do this? > > > Thank you very much!!! > > Giuseppe Spampinato > > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes From krangam lsil.com Fri May 10 15:45:53 2002 From: krangam lsil.com (Kasturi Rangam) Date: Wed Jul 30 14:07:56 2003 Subject: [M4IF Technotes] GMC Message-ID: <3CDC3F91.7BC48C97@lsil.com> I am trying to under GMC in MPEG4. Looks like you can have 0, 1, 2 or 3 sprite_warping_points. To decode a 0 and 1 sprite_warping_points macroblock, you can fetch the whole macroblock data from the reference to do pixel prediction. However, for 2 and 3 warping_points, the motion vector for each pixel can be anywhere in the reference frame. Thus we might need to perform 64 data fetches to predict one macroblock. Is there a range that can be calculated for each macroblock, so that we can fetch data only once? Thanks, Kasturi From sorin mobilygen.com Sun May 12 01:00:04 2002 From: sorin mobilygen.com (Sorin C. Cismas) Date: Wed Jul 30 14:07:56 2003 Subject: [M4IF Technotes] GMC In-Reply-To: <3CDC3F91.7BC48C97@lsil.com> Message-ID: <005301c1f982$a6e62590$8a28a8c0@C1143306A> I don't think there are any restrictions on the motion vectors. I have the same concern about the need to fetch 64 non-contiguous 2x2 pels to predict a macroblock. To reduce complexity and bandwidth requirements, it is highly desirable to put some limits on du[i] and dv[i] for i>0. 2 and 3 warping points are usefull for zoom-in and zoom-out, however, it is not realistic to assume, for example, a 10x zoom-out on an S(GMC) prediction. A 50% or even 25% zoom-out restriction will be more than sufficient. For 50%, this will translate to du[i]0. For 25%, this will translate to du[i]0. The 50% restriction will limit the macroblock luma prediction to 25x25. The 25% restriction will limit the macroblock luma prediction to 21x21. Can these or similar restrictions be considered for a future corrigendum? Thanks, Sorin Cismas > -----Original Message----- > From: technotes-admin@lists.m4if.org > [mailto:technotes-admin@lists.m4if.org]On Behalf Of Kasturi Rangam > Sent: Friday, May 10, 2024 2:46 PM > To: technotes@lists.m4if.org > Subject: [M4IF Technotes] GMC > > > I am trying to under GMC in MPEG4. > Looks like you can have 0, 1, 2 or 3 sprite_warping_points. > > To decode a 0 and 1 sprite_warping_points macroblock, you can > fetch the whole macroblock data from the reference to do pixel > prediction. > > However, for 2 and 3 warping_points, the motion vector for each > pixel can be anywhere in the reference frame. Thus we might need > to perform 64 data fetches to predict one macroblock. > > Is there a range that can be calculated for each macroblock, so that > we can fetch data only once? > > Thanks, > > Kasturi > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes From sorin mobilygen.com Sun May 12 01:01:09 2002 From: sorin mobilygen.com (Sorin C. Cismas) Date: Wed Jul 30 14:07:56 2003 Subject: [M4IF Technotes] Warping equations for 2 warping points Message-ID: <005401c1f982$cc2cfe50$8a28a8c0@C1143306A> I think the warping equations for 2 warping points in Section 7.8.5 of N4350 are incorrect. Can anybody confirm this? Thanks, Sorin Cismas From khuber sorenson.com Mon May 13 11:24:04 2002 From: khuber sorenson.com (Kris Huber) Date: Wed Jul 30 14:07:57 2003 Subject: [M4IF Technotes] Warping equations for 2 warping points Message-ID: <70A238C106788B49A1B7B46C050DEDFE228E35@pandora.sorenson.com> I can't confirm this, but can deny it :-). I think the only error (other than some grammar errors) is that W'=2*alpha and H'=2*beta should be W'=2^alpha and H'=2^beta (exponents) at the end of 7.8.4. Without understanding this error, the "fast version" of 2, 3, and 4 warping points equations can't be interpreted correctly. There is a sign-change on some of the coefficients when you compare the 2 warping points equations with the 3 warping points equations that generalize them, but as long as encoder and decoder use same 2 warping points equations, there should be no problem. I found a perfect match between the reference software implementations and independent implementation of the equations based directly on the text for 1 through 3 warping points (the microsoft reference software, I think it was, doesn't implement the near-useless 0 warping points model correctly, if I recall). I think perhaps the equations for 2 warping points could have been formulated in an alternative way, but that they are not in error. If you still believe they are in error, more detail would be helpful. Regards, Kris Huber -----Original Message----- From: "Sorin C. Cismas" To: Date: Sun, 12 May 2024 00:01:09 -0700 Subject: [M4IF Technotes] Warping equations for 2 warping points I think the warping equations for 2 warping points in Section 7.8.5 of N4350 are incorrect. Can anybody confirm this? Thanks, Sorin Cismas From krangam lsil.com Mon May 13 11:19:48 2002 From: krangam lsil.com (Kasturi Rangam) Date: Wed Jul 30 14:07:57 2003 Subject: [M4IF Technotes] GMC References: <005301c1f982$a6e62590$8a28a8c0@C1143306A> Message-ID: <3CDFF5B4.CD5FE0B2@lsil.com> Thanks for the information. I was wondering if we could calculate the motion vector range based on du[i] and dv[i] range. Of course if this range is more than the reference frame, then there is no point. --Kasturi "Sorin C. Cismas" wrote: > > I don't think there are any restrictions on the motion vectors. I have > the same concern about the need to fetch 64 non-contiguous 2x2 pels > to predict a macroblock. To reduce complexity and bandwidth requirements, > it is highly desirable to put some limits on du[i] and dv[i] for i>0. > > 2 and 3 warping points are usefull for zoom-in and zoom-out, however, it is > not realistic to assume, for example, a 10x zoom-out on an S(GMC) prediction. > A 50% or even 25% zoom-out restriction will be more than sufficient. > For 50%, this will translate to du[i]0. > For 25%, this will translate to du[i]0. > The 50% restriction will limit the macroblock luma prediction to 25x25. > The 25% restriction will limit the macroblock luma prediction to 21x21. > > Can these or similar restrictions be considered for a future corrigendum? > > Thanks, > Sorin Cismas > > > -----Original Message----- > > From: technotes-admin@lists.m4if.org > > [mailto:technotes-admin@lists.m4if.org]On Behalf Of Kasturi Rangam > > Sent: Friday, May 10, 2024 2:46 PM > > To: technotes@lists.m4if.org > > Subject: [M4IF Technotes] GMC > > > > > > I am trying to under GMC in MPEG4. > > Looks like you can have 0, 1, 2 or 3 sprite_warping_points. > > > > To decode a 0 and 1 sprite_warping_points macroblock, you can > > fetch the whole macroblock data from the reference to do pixel > > prediction. > > > > However, for 2 and 3 warping_points, the motion vector for each > > pixel can be anywhere in the reference frame. Thus we might need > > to perform 64 data fetches to predict one macroblock. > > > > Is there a range that can be calculated for each macroblock, so that > > we can fetch data only once? > > > > Thanks, > > > > Kasturi > > _______________________________________________ > > Technotes mailing list > > Technotes@lists.m4if.org > > http://lists.m4if.org/mailman/listinfo/technotes > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes From krangam lsil.com Mon May 13 16:17:41 2002 From: krangam lsil.com (Kasturi Rangam) Date: Wed Jul 30 14:07:57 2003 Subject: [M4IF Technotes] GMC References: <005301c1f982$a6e62590$8a28a8c0@C1143306A> <3CDFF5B4.CD5FE0B2@lsil.com> Message-ID: <3CE03B85.1CB629A4@lsil.com> Is there some statistics regarding number of GMC macroblocks for a MPEG4 bitstream. This will be useful to calculate the bandwidth requirements. Thanks, Kasturi Kasturi Rangam wrote: > > Thanks for the information. I was wondering if we could calculate > the motion vector range based on du[i] and dv[i] range. Of course > if this range is more than the reference frame, then there is no > point. > > --Kasturi > > "Sorin C. Cismas" wrote: > > > > I don't think there are any restrictions on the motion vectors. I have > > the same concern about the need to fetch 64 non-contiguous 2x2 pels > > to predict a macroblock. To reduce complexity and bandwidth requirements, > > it is highly desirable to put some limits on du[i] and dv[i] for i>0. > > > > 2 and 3 warping points are usefull for zoom-in and zoom-out, however, it is > > not realistic to assume, for example, a 10x zoom-out on an S(GMC) prediction. > > A 50% or even 25% zoom-out restriction will be more than sufficient. > > For 50%, this will translate to du[i]0. > > For 25%, this will translate to du[i]0. > > The 50% restriction will limit the macroblock luma prediction to 25x25. > > The 25% restriction will limit the macroblock luma prediction to 21x21. > > > > Can these or similar restrictions be considered for a future corrigendum? > > > > Thanks, > > Sorin Cismas > > > > > -----Original Message----- > > > From: technotes-admin@lists.m4if.org > > > [mailto:technotes-admin@lists.m4if.org]On Behalf Of Kasturi Rangam > > > Sent: Friday, May 10, 2024 2:46 PM > > > To: technotes@lists.m4if.org > > > Subject: [M4IF Technotes] GMC > > > > > > > > > I am trying to under GMC in MPEG4. > > > Looks like you can have 0, 1, 2 or 3 sprite_warping_points. > > > > > > To decode a 0 and 1 sprite_warping_points macroblock, you can > > > fetch the whole macroblock data from the reference to do pixel > > > prediction. > > > > > > However, for 2 and 3 warping_points, the motion vector for each > > > pixel can be anywhere in the reference frame. Thus we might need > > > to perform 64 data fetches to predict one macroblock. > > > > > > Is there a range that can be calculated for each macroblock, so that > > > we can fetch data only once? > > > > > > Thanks, > > > > > > Kasturi > > > _______________________________________________ > > > Technotes mailing list > > > Technotes@lists.m4if.org > > > http://lists.m4if.org/mailman/listinfo/technotes > > _______________________________________________ > > Technotes mailing list > > Technotes@lists.m4if.org > > http://lists.m4if.org/mailman/listinfo/technotes > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes From moez_tarzi excite.com Tue May 14 07:22:40 2002 From: moez_tarzi excite.com (TARZI Moez) Date: Wed Jul 30 14:07:57 2003 Subject: [M4IF Technotes] need help Message-ID: <20020514102240.B57633D16@xmxpita.excite.com> Hello, I have seen that you used MoMuSys before, I have this source code but i does not knew how to use it for encoding MPEG4 file or all the beautiful options shown on the official site. Can you please help me to understand how to use the MoMuSys softwere. Thank you in advance. TARZI Moez. ------------------------------------------------ Join Excite! - http://www.excite.com The most personalized portal on the Web! -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20020514/8cf72309/attachment.html From khuber sorenson.com Tue May 14 20:19:36 2002 From: khuber sorenson.com (Kris Huber) Date: Wed Jul 30 14:07:57 2003 Subject: [M4IF Technotes] RE: Technotes digest, Vol 1 #243 - 4 msgs Message-ID: <70A238C106788B49A1B7B46C050DEDFE228E3E@pandora.sorenson.com> Hello Tarzi Moez, You first have to compile the software then run the resulting executable files. The program reads filenames and settings out of a parameter file that you have to prepare. I believe there are a few example parameter files in a directory of the source code distribution that you modify. By default, the reference software will only read raw video data sequences in a simple format. To handle anything else you will need to modify the I/O routines to read/write formats other than that one. There should be some comments in the code or in a "readme" file about that. Regards, Kris Huber -----Original Message----- To: rkoenen@intertrust.com, tomotohara@yahoo.com, khuber@sorensontech.com, technotes@lists.m4if.org Reply-To: moez_tarzi@excite.com From: "TARZI Moez" Cc: Date: Tue, 14 May 2024 06:22:40 -0400 (EDT) Subject: [M4IF Technotes] need help Hello, I have seen that you used MoMuSys before, I have this source code but i does not knew how to use it for encoding MPEG4 file or all the beautiful options shown on the official site. Can you please help me to understand how to use the MoMuSys softwere. Thank you in advance. TARZI Moez. From khuber sorenson.com Tue May 14 20:28:00 2002 From: khuber sorenson.com (Kris Huber) Date: Wed Jul 30 14:07:57 2003 Subject: [M4IF Technotes] GMC Message-ID: <70A238C106788B49A1B7B46C050DEDFE228E3F@pandora.sorenson.com> Soren, This idea sounds interesting for limiting complexity of GMC. Are any limitations on the negative side of du[i] and dv[i] needed? Once fully fleshed out I think it possibly could be added as corrigendum. It is one more thing that encoder tools would have to worry about, though. But the constraints might be loose enough that nobody would be concerned. Regards, Kris -----Original Message----- From: "Sorin C. Cismas" To: Subject: RE: [M4IF Technotes] GMC Date: Sun, 12 May 2024 00:00:04 -0700 I don't think there are any restrictions on the motion vectors. I have the same concern about the need to fetch 64 non-contiguous 2x2 pels to predict a macroblock. To reduce complexity and bandwidth requirements, it is highly desirable to put some limits on du[i] and dv[i] for i>0. 2 and 3 warping points are usefull for zoom-in and zoom-out, however, it is not realistic to assume, for example, a 10x zoom-out on an S(GMC) prediction. A 50% or even 25% zoom-out restriction will be more than sufficient. For 50%, this will translate to du[i]0. For 25%, this will translate to du[i]0. The 50% restriction will limit the macroblock luma prediction to 25x25. The 25% restriction will limit the macroblock luma prediction to 21x21. Can these or similar restrictions be considered for a future corrigendum? Thanks, Sorin Cismas > -----Original Message----- > From: technotes-admin@lists.m4if.org > [mailto:technotes-admin@lists.m4if.org]On Behalf Of Kasturi Rangam > Sent: Friday, May 10, 2024 2:46 PM > To: technotes@lists.m4if.org > Subject: [M4IF Technotes] GMC > > > I am trying to under GMC in MPEG4. > Looks like you can have 0, 1, 2 or 3 sprite_warping_points. > > To decode a 0 and 1 sprite_warping_points macroblock, you can > fetch the whole macroblock data from the reference to do pixel > prediction. > > However, for 2 and 3 warping_points, the motion vector for each > pixel can be anywhere in the reference frame. Thus we might need > to perform 64 data fetches to predict one macroblock. > > Is there a range that can be calculated for each macroblock, so that > we can fetch data only once? > > Thanks, > > Kasturi > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes From khuber sorenson.com Tue May 14 20:34:14 2002 From: khuber sorenson.com (Kris Huber) Date: Wed Jul 30 14:07:57 2003 Subject: [M4IF Technotes] GMC Message-ID: <70A238C106788B49A1B7B46C050DEDFE228E40@pandora.sorenson.com> I noticed that some, if not all, of the base layer bitstreams in ftp://ftp.tnt.uni-hannover.de/pub/MPEG/video/conformance/version_2/Advanced_ Simple/ (linked to from the M4IF web site) have a complexity estimation_method=='11' (if I remember correctly--it's been a few months). This made them not decode with the earlier reference software (not the PDAM executables there, but earlier standardized versions that should have worked). I didn't look into it more, but all I see defined in the standard is estimation_method being '00' or '01', and don't see any new ones in the amendments. Tihao, maybe you have seen this inconsistency in the reference software versions? Kasturi, your question made me want to ask the above, because one way to transmit GMC statistics from encoder to decoder would be through header information indicating the percentage of macroblocks of GMC macroblocks, for example. An earlier scheme can be followed to define such info S(GMC)-VOPs, similar to how it was done for P-VOPs and others. A new value for estimation_method would need to be added. I'm wondering if that was done in the reference software at the ftp link above and someone intended to submit text about it. As for statistics of GMC usage in general, I think it could vary quite a lot from sequence to sequence and the algorithms used by the encoder tools. At times an encoder may wisely encode a large fraction of the macroblocks in GMC mode, such as when zooming a scene of almost no motion, for example. How often such a scene occurs in content I don't know, and I suspect such statistics are non-stationary, bound to vary with time and content author. Thanks for any info, Kris -----Original Message----- Date: Mon, 13 May 2024 15:17:41 -0700 From: Kasturi Rangam To: "Sorin C. Cismas" , technotes@lists.m4if.org Subject: Re: [M4IF Technotes] GMC Is there some statistics regarding number of GMC macroblocks for a MPEG4 bitstream. This will be useful to calculate the bandwidth requirements. Thanks, Kasturi Kasturi Rangam wrote: > > Thanks for the information. I was wondering if we could calculate > the motion vector range based on du[i] and dv[i] range. Of course > if this range is more than the reference frame, then there is no > point. > > --Kasturi > > "Sorin C. Cismas" wrote: > > > > I don't think there are any restrictions on the motion vectors. I have > > the same concern about the need to fetch 64 non-contiguous 2x2 pels > > to predict a macroblock. To reduce complexity and bandwidth requirements, > > it is highly desirable to put some limits on du[i] and dv[i] for i>0. > > > > 2 and 3 warping points are usefull for zoom-in and zoom-out, however, it is > > not realistic to assume, for example, a 10x zoom-out on an S(GMC) prediction. > > A 50% or even 25% zoom-out restriction will be more than sufficient. > > For 50%, this will translate to du[i]0. > > For 25%, this will translate to du[i]0. > > The 50% restriction will limit the macroblock luma prediction to 25x25. > > The 25% restriction will limit the macroblock luma prediction to 21x21. > > > > Can these or similar restrictions be considered for a future corrigendum? > > > > Thanks, > > Sorin Cismas > > > > > -----Original Message----- > > > From: technotes-admin@lists.m4if.org > > > [mailto:technotes-admin@lists.m4if.org]On Behalf Of Kasturi Rangam > > > Sent: Friday, May 10, 2024 2:46 PM > > > To: technotes@lists.m4if.org > > > Subject: [M4IF Technotes] GMC > > > > > > > > > I am trying to under GMC in MPEG4. > > > Looks like you can have 0, 1, 2 or 3 sprite_warping_points. > > > > > > To decode a 0 and 1 sprite_warping_points macroblock, you can > > > fetch the whole macroblock data from the reference to do pixel > > > prediction. > > > > > > However, for 2 and 3 warping_points, the motion vector for each > > > pixel can be anywhere in the reference frame. Thus we might need > > > to perform 64 data fetches to predict one macroblock. > > > > > > Is there a range that can be calculated for each macroblock, so that > > > we can fetch data only once? > > > > > > Thanks, > > > > > > Kasturi > > > _______________________________________________ > > > Technotes mailing list > > > Technotes@lists.m4if.org > > > http://lists.m4if.org/mailman/listinfo/technotes > > _______________________________________________ > > Technotes mailing list > > Technotes@lists.m4if.org > > http://lists.m4if.org/mailman/listinfo/technotes > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes From yosinori crl.hitachi.co.jp Wed May 15 11:55:50 2002 From: yosinori crl.hitachi.co.jp (Yoshinori Suzuki) Date: Wed Jul 30 14:07:57 2003 Subject: [M4IF Technotes] Warping equations for 2 warping points References: <70A238C106788B49A1B7B46C050DEDFE228E35@pandora.sorenson.com> Message-ID: <3CE1C026.50AC30E8@crl.hitachi.co.jp> Dear all, Kris Huber wrote: > > I can't confirm this, but can deny it :-). I think the only error (other > than some grammar errors) is that W'=2*alpha and H'=2*beta should be > W'=2^alpha and H'=2^beta (exponents) at the end of 7.8.4. Without > understanding this error, the "fast version" of 2, 3, and 4 warping points > equations can't be interpreted correctly. I think that this error will be corrected by the corrigendum. These changes are covered in the first version of DCOR1 to the ISO/IEC 14496-2:2001 (Fairfax Output N4740). Best regards, Yoshinori Suzuki Hitachi, Ltd. From yosinori crl.hitachi.co.jp Wed May 15 13:05:21 2002 From: yosinori crl.hitachi.co.jp (Yoshinori Suzuki) Date: Wed Jul 30 14:07:57 2003 Subject: [M4IF Technotes] GMC References: <70A238C106788B49A1B7B46C050DEDFE228E3F@pandora.sorenson.com> Message-ID: <3CE1D071.D4917675@crl.hitachi.co.jp> Dear Sorin and Kris, Kris Huber wrote: > > Soren, > > This idea sounds interesting for limiting complexity of GMC. Are any > limitations on the negative side of du[i] and dv[i] needed? Once fully > fleshed out I think it possibly could be added as corrigendum. It is one > more thing that encoder tools would have to worry about, though. But the > constraints might be loose enough that nobody would be concerned. I basically agree to adding the limitation on the memory access for GMC. However the standard has been already released, and it could not be added as corrigendum, but may be as the new amendment since it is a technical issue. So, I think that such the limitation had better be set by each association specifying the application, e.g. ISMA, for avoiding the problem on encoding pointed out by Kris if it is necessary. I think that this is a realistic solution in the current situation. Best regards, Yoshinori Suzuki Hitachi, Ltd. > -----Original Message----- > From: "Sorin C. Cismas" > To: > Subject: RE: [M4IF Technotes] GMC > Date: Sun, 12 May 2024 00:00:04 -0700 > > I don't think there are any restrictions on the motion vectors. I have > the same concern about the need to fetch 64 non-contiguous 2x2 pels > to predict a macroblock. To reduce complexity and bandwidth requirements, > it is highly desirable to put some limits on du[i] and dv[i] for i>0. > > 2 and 3 warping points are usefull for zoom-in and zoom-out, however, it is > not realistic to assume, for example, a 10x zoom-out on an S(GMC) > prediction. > A 50% or even 25% zoom-out restriction will be more than sufficient. > For 50%, this will translate to du[i]0. > For 25%, this will translate to du[i]0. > The 50% restriction will limit the macroblock luma prediction to 25x25. > The 25% restriction will limit the macroblock luma prediction to 21x21. > > Can these or similar restrictions be considered for a future corrigendum? > > Thanks, > Sorin Cismas > > > -----Original Message----- > > From: technotes-admin@lists.m4if.org > > [mailto:technotes-admin@lists.m4if.org]On Behalf Of Kasturi Rangam > > Sent: Friday, May 10, 2024 2:46 PM > > To: technotes@lists.m4if.org > > Subject: [M4IF Technotes] GMC > > > > > > I am trying to under GMC in MPEG4. > > Looks like you can have 0, 1, 2 or 3 sprite_warping_points. > > > > To decode a 0 and 1 sprite_warping_points macroblock, you can > > fetch the whole macroblock data from the reference to do pixel > > prediction. > > > > However, for 2 and 3 warping_points, the motion vector for each > > pixel can be anywhere in the reference frame. Thus we might need > > to perform 64 data fetches to predict one macroblock. > > > > Is there a range that can be calculated for each macroblock, so that > > we can fetch data only once? > > > > Thanks, > > > > Kasturi > > _______________________________________________ > > Technotes mailing list > > Technotes@lists.m4if.org > > http://lists.m4if.org/mailman/listinfo/technotes > > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes From rkoenen intertrust.com Tue May 14 21:28:46 2002 From: rkoenen intertrust.com (Rob Koenen) Date: Wed Jul 30 14:07:57 2003 Subject: [M4IF Technotes] GMC Message-ID: <3C124172E7FDD511B510000347426D59AF546A@exchange.epr.com> > I basically agree to adding the limitation on the memory access for GMC. > However the standard has been already released, and it could not be added > as corrigendum, but may be as the new amendment since it is a technical > issue. Indeed. Changing the standard in this way would be an amendment, not a corrigendum. It is not common to change a standard in retrospect, if it breaks existing products. > So, I think that such the limitation had better be set by each association > specifying the application, e.g. ISMA, for avoiding the problem on encoding > pointed out by Kris if it is necessary. > I think that this is a realistic solution in the current situation. With all respect for that suggestion, it would pose interoperability problems, as it would amount to an external body defining its own Levels. (ISMA already sort of did that once, but then went to MPEG to ask to formalize this new definition, which becomes Level 3b for Advanced Simple) If anyone, MPEG should fix its own levels (if there is indeed a problem) or create additional ones if fixes would create problems for existing products. Kind Regards, Rob > > Best regards, > > Yoshinori Suzuki > Hitachi, Ltd. > > > -----Original Message----- > > From: "Sorin C. Cismas" > > To: > > Subject: RE: [M4IF Technotes] GMC > > Date: Sun, 12 May 2024 00:00:04 -0700 > > > > I don't think there are any restrictions on the motion > vectors. I have > > the same concern about the need to fetch 64 non-contiguous 2x2 pels > > to predict a macroblock. To reduce complexity and > bandwidth requirements, > > it is highly desirable to put some limits on du[i] and > dv[i] for i>0. > > > > 2 and 3 warping points are usefull for zoom-in and > zoom-out, however, it is > > not realistic to assume, for example, a 10x zoom-out on an S(GMC) > > prediction. > > A 50% or even 25% zoom-out restriction will be more than sufficient. > > For 50%, this will translate to du[i]0. > > For 25%, this will translate to du[i]0. > > The 50% restriction will limit the macroblock luma > prediction to 25x25. > > The 25% restriction will limit the macroblock luma > prediction to 21x21. > > > > Can these or similar restrictions be considered for a > future corrigendum? > > > > Thanks, > > Sorin Cismas > > > > > -----Original Message----- > > > From: technotes-admin@lists.m4if.org > > > [mailto:technotes-admin@lists.m4if.org]On Behalf Of Kasturi Rangam > > > Sent: Friday, May 10, 2024 2:46 PM > > > To: technotes@lists.m4if.org > > > Subject: [M4IF Technotes] GMC > > > > > > > > > I am trying to under GMC in MPEG4. > > > Looks like you can have 0, 1, 2 or 3 sprite_warping_points. > > > > > > To decode a 0 and 1 sprite_warping_points macroblock, you can > > > fetch the whole macroblock data from the reference to do pixel > > > prediction. > > > > > > However, for 2 and 3 warping_points, the motion vector for each > > > pixel can be anywhere in the reference frame. Thus we might need > > > to perform 64 data fetches to predict one macroblock. > > > > > > Is there a range that can be calculated for each > macroblock, so that > > > we can fetch data only once? > > > > > > Thanks, > > > > > > Kasturi > > > _______________________________________________ > > > Technotes mailing list > > > Technotes@lists.m4if.org > > > http://lists.m4if.org/mailman/listinfo/technotes > > > > _______________________________________________ > > Technotes mailing list > > Technotes@lists.m4if.org > > http://lists.m4if.org/mailman/listinfo/technotes > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes > From yosinori crl.hitachi.co.jp Wed May 15 14:28:56 2002 From: yosinori crl.hitachi.co.jp (Yoshinori Suzuki) Date: Wed Jul 30 14:07:58 2003 Subject: [M4IF Technotes] GMC References: <70A238C106788B49A1B7B46C050DEDFE228E40@pandora.sorenson.com> Message-ID: <3CE1E408.9755A9A2@crl.hitachi.co.jp> Dear all, Kris Huber wrote: > > I noticed that some, if not all, of the base layer bitstreams in > ftp://ftp.tnt.uni-hannover.de/pub/MPEG/video/conformance/version_2/Advanced_ > Simple/ (linked to from the M4IF web site) have a complexity > estimation_method=='11' (if I remember correctly--it's been a few months). > This made them not decode with the earlier reference software (not the PDAM > executables there, but earlier standardized versions that should have > worked). I didn't look into it more, but all I see defined in the standard > is estimation_method being '00' or '01', and don't see any new ones in the > amendments. Tihao, maybe you have seen this inconsistency in the reference > software versions? The directory of version_2/Advanced_Simple is not for conformacne bitstreams of the Advanced Simple. I will request to delete that directory and to create the new directory. Best regards, Yoshinori Suzuki Hitachi, Ltd. From yosinori crl.hitachi.co.jp Wed May 15 15:06:29 2002 From: yosinori crl.hitachi.co.jp (Yoshinori Suzuki) Date: Wed Jul 30 14:07:58 2003 Subject: [M4IF Technotes] GMC References: <3C124172E7FDD511B510000347426D59AF546A@exchange.epr.com> Message-ID: <3CE1ECD5.4C9DFE82@crl.hitachi.co.jp> Dear Rob and all, Thank you for the comment. > With all respect for that suggestion, it would pose interoperability > problems, as it would amount to an external body defining its own Levels. > (ISMA already sort of did that once, but then went to MPEG to ask to > formalize this new definition, which becomes Level 3b for Advanced Simple) > > If anyone, MPEG should fix its own levels (if there is indeed a problem) > or create additional ones if fixes would create problems for existing > products. ISMA is just example, not generic. My suggestion is not to add its own levels, that is to define the limitation for the current levels. I think that 1. the limitation on encoding defined by an assosiation does not cause the prombles for existing products, and 2. the limitation on decoder in the specific association does not cause the prombles, though such decoder could not decode all standard bitstreams. Of course, I also think that MPEG should create the new amendment if the reasonable request is raised. Best regards, Yoshinori Suzuki Hitachi, Ltd. From sorin mobilygen.com Wed May 15 01:01:25 2002 From: sorin mobilygen.com (Sorin C. Cismas) Date: Wed Jul 30 14:07:58 2003 Subject: [M4IF Technotes] GMC In-Reply-To: <70A238C106788B49A1B7B46C050DEDFE228E3F@pandora.sorenson.com> Message-ID: <000a01c1fbde$57098e00$c41a420c@C1143306A> Kris and all, Indeed, limitations on the negative side are needed too. The restriction should apply to the absolute value of du[i] and dv[i]. My interest is mainly in the ASP. I'm implementing the ASP@L5 with some hardware support and I'm looking at complexity issues and memory bandwidth utilization. If it will be up to me to decide what GMC to support in ASP, it will be only with one warping point. If that's not acceptable, the next complexity level will be to support only rectangle based prediction with some decent limitations on du[i] and dv[i]. This will support independent stretch/shrink on both directions (zoom is a particular case) but without any rotation. In this case, the restrictions will be: Abs(du[1]) < W//2; dv[1] = 0 ; // +-25% limitation du[2] = 0 ; Abs(dv[2]) < H//2; // +-25% limitation The current GMC is beautiful in its generality, but lacks some practicality. GMC can support 10x zoom and mirrored prediction (for example, 2 warping points with du[1] = -4*W and dv[1] = 0). GMC is usefull to transmit only once a motion vector that applies or can be extrapolated by simple scaling to several macroblocks. Beyond that, I'm not sure about its real life usefullness. Without apriori knowledge, it will be quite difficult for the encoder to figure out how to use this feature. And even if it does, I'm not sure how many bits are saved. But on the downside, an MPEG4 decoder which claims to be ASP compliant, has to support these features even if all commercial encoders will never use affine based prediction in all its generality. Regards, Sorin Cismas -----Original Message----- From: technotes-admin@lists.m4if.org [mailto:technotes-admin@lists.m4if.org]On Behalf Of Kris Huber Sent: Tuesday, May 14, 2024 6:28 PM To: 'sorin@mobilygen.com' Cc: 'technotes@lists.m4if.org' Subject: RE: [M4IF Technotes] GMC Soren, This idea sounds interesting for limiting complexity of GMC. Are any limitations on the negative side of du[i] and dv[i] needed? Once fully fleshed out I think it possibly could be added as corrigendum. It is one more thing that encoder tools would have to worry about, though. But the constraints might be loose enough that nobody would be concerned. Regards, Kris -----Original Message----- From: "Sorin C. Cismas" To: Subject: RE: [M4IF Technotes] GMC Date: Sun, 12 May 2024 00:00:04 -0700 I don't think there are any restrictions on the motion vectors. I have the same concern about the need to fetch 64 non-contiguous 2x2 pels to predict a macroblock. To reduce complexity and bandwidth requirements, it is highly desirable to put some limits on du[i] and dv[i] for i>0. 2 and 3 warping points are usefull for zoom-in and zoom-out, however, it is not realistic to assume, for example, a 10x zoom-out on an S(GMC) prediction. A 50% or even 25% zoom-out restriction will be more than sufficient. For 50%, this will translate to du[i]0. For 25%, this will translate to du[i]0. The 50% restriction will limit the macroblock luma prediction to 25x25. The 25% restriction will limit the macroblock luma prediction to 21x21. Can these or similar restrictions be considered for a future corrigendum? Thanks, Sorin Cismas > -----Original Message----- > From: technotes-admin@lists.m4if.org > [mailto:technotes-admin@lists.m4if.org]On Behalf Of Kasturi Rangam > Sent: Friday, May 10, 2024 2:46 PM > To: technotes@lists.m4if.org > Subject: [M4IF Technotes] GMC > > > I am trying to under GMC in MPEG4. > Looks like you can have 0, 1, 2 or 3 sprite_warping_points. > > To decode a 0 and 1 sprite_warping_points macroblock, you can > fetch the whole macroblock data from the reference to do pixel > prediction. > > However, for 2 and 3 warping_points, the motion vector for each > pixel can be anywhere in the reference frame. Thus we might need > to perform 64 data fetches to predict one macroblock. > > Is there a range that can be calculated for each macroblock, so that > we can fetch data only once? > > Thanks, > > Kasturi > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes _______________________________________________ Technotes mailing list Technotes@lists.m4if.org http://lists.m4if.org/mailman/listinfo/technotes From yosinori crl.hitachi.co.jp Wed May 15 20:49:49 2002 From: yosinori crl.hitachi.co.jp (Yoshinori Suzuki) Date: Wed Jul 30 14:07:58 2003 Subject: [M4IF Technotes] GMC References: <000a01c1fbde$57098e00$c41a420c@C1143306A> Message-ID: <3CE23D4D.FEB4CC36@crl.hitachi.co.jp> Dear Dr. Cismas and all, > GMC is usefull to transmit only once a motion vector that applies or > can be extrapolated by simple scaling to several macroblocks. Beyond > that, I'm not sure about its real life usefullness. Without apriori > knowledge, it will be quite difficult for the encoder to figure out how > to use this feature. And even if it does, I'm not sure how many bits > are saved. But on the downside, an MPEG4 decoder which claims to be > ASP compliant, has to support these features even if all commercial > encoders will never use affine based prediction in all its generality. In my experience on the MPEG-4 standard activities, the affine based prediction provides 10-30% bit saving compared with the Version 1 tool sets of MPEG-4 Video at low bitrate if the sequence has zooming scene and the actual global motion is detected. And some methods for the global motion estimetion have been developed and made public. I understand that the encoding techniques on GMC are not familier to the hardware implementers, since its features are not found in the MPEG-2 and MPEG-4 Version 1 standard. However, I believe that it will be available in the near future, and the functions for affine tranform in the ASP decoder will be useful. Best regards, Yoshinori Suzuki Hitachi, Ltd. From wuks bhnec.nec.co.jp Tue May 14 20:32:56 2002 From: wuks bhnec.nec.co.jp (wuks@bhnec.nec.co.jp) Date: Wed Jul 30 14:07:58 2003 Subject: [M4IF Technotes] (no subject) Message-ID: hi, what's the meaning of terms "Rate control averaging period,frames" and "Rate control reaction period,frames" in the DivX? thank for your help! From khuber sorenson.com Wed May 15 12:17:55 2002 From: khuber sorenson.com (Kris Huber) Date: Wed Jul 30 14:07:58 2003 Subject: [M4IF Technotes] GMC Message-ID: <70A238C106788B49A1B7B46C050DEDFE228E42@pandora.sorenson.com> Sorin, Thanks for your clarifications. I think the rotation aspect of GMC prediction is important. In my opinion, commercial encoders are more likely to restrict the searched parameter space to a region small enough to accomodate a 25% per frame zoom than they are to restrict the parameters to have zero tolerance for rotation and skew. A zero rotation and skew constraint doesn't occur so naturally in an encoder, since the estimation involved may be about the same complexity without that constraint--I suppose it depends on encoder estimation method. Note that with zoom-out restricted to 25%, with rotation it seems to me that you can still predict that a block of reference memory no bigger than NxN where N=ceil(1+(16*1.25)*sqrt(2))=29 will be needed to compute the predicted macroblock, and you could at least get that block into some faster memory ahead of time. I'm not sure how you'd limit skew of the 3 warping points model. As for mirrored prediction, I can imagine it being useful for interesting special effects. And I suppose how frequently mirrored prediction is used may depend upon how frequently users of encoder tools decide to use the special effects built from it. I wouldn't argue as much about the value of mirrored prediction as I would about the value of some rotation and skew. For example, rotation of 90 degrees from frame to frame seems more than necessary for natural video and useful only for special effects like mirrored prediction. Of course, for encoder implementers it seems most convenient to have no restrictions in order to allow for maximum innovation and product distinction. Best Regards, Kris -----Original Message----- From: "Sorin C. Cismas" Cc: Subject: RE: [M4IF Technotes] GMC Date: Wed, 15 May 2024 00:01:25 -0700 Kris and all, Indeed, limitations on the negative side are needed too. The restriction should apply to the absolute value of du[i] and dv[i]. My interest is mainly in the ASP. I'm implementing the ASP@L5 with some hardware support and I'm looking at complexity issues and memory bandwidth utilization. If it will be up to me to decide what GMC to support in ASP, it will be only with one warping point. If that's not acceptable, the next complexity level will be to support only rectangle based prediction with some decent limitations on du[i] and dv[i]. This will support independent stretch/shrink on both directions (zoom is a particular case) but without any rotation. In this case, the restrictions will be: Abs(du[1]) < W//2; dv[1] = 0 ; // +-25% limitation du[2] = 0 ; Abs(dv[2]) < H//2; // +-25% limitation The current GMC is beautiful in its generality, but lacks some practicality. GMC can support 10x zoom and mirrored prediction (for example, 2 warping points with du[1] = -4*W and dv[1] = 0). GMC is usefull to transmit only once a motion vector that applies or can be extrapolated by simple scaling to several macroblocks. Beyond that, I'm not sure about its real life usefullness. Without apriori knowledge, it will be quite difficult for the encoder to figure out how to use this feature. And even if it does, I'm not sure how many bits are saved. But on the downside, an MPEG4 decoder which claims to be ASP compliant, has to support these features even if all commercial encoders will never use affine based prediction in all its generality. Regards, Sorin Cismas -----Original Message----- From: technotes-admin@lists.m4if.org [mailto:technotes-admin@lists.m4if.org]On Behalf Of Kris Huber Sent: Tuesday, May 14, 2024 6:28 PM To: 'sorin@mobilygen.com' Cc: 'technotes@lists.m4if.org' Subject: RE: [M4IF Technotes] GMC Soren, This idea sounds interesting for limiting complexity of GMC. Are any limitations on the negative side of du[i] and dv[i] needed? Once fully fleshed out I think it possibly could be added as corrigendum. It is one more thing that encoder tools would have to worry about, though. But the constraints might be loose enough that nobody would be concerned. Regards, Kris -----Original Message----- From: "Sorin C. Cismas" To: Subject: RE: [M4IF Technotes] GMC Date: Sun, 12 May 2024 00:00:04 -0700 I don't think there are any restrictions on the motion vectors. I have the same concern about the need to fetch 64 non-contiguous 2x2 pels to predict a macroblock. To reduce complexity and bandwidth requirements, it is highly desirable to put some limits on du[i] and dv[i] for i>0. 2 and 3 warping points are usefull for zoom-in and zoom-out, however, it is not realistic to assume, for example, a 10x zoom-out on an S(GMC) prediction. A 50% or even 25% zoom-out restriction will be more than sufficient. For 50%, this will translate to du[i]0. For 25%, this will translate to du[i]0. The 50% restriction will limit the macroblock luma prediction to 25x25. The 25% restriction will limit the macroblock luma prediction to 21x21. Can these or similar restrictions be considered for a future corrigendum? Thanks, Sorin Cismas > -----Original Message----- > From: technotes-admin@lists.m4if.org > [mailto:technotes-admin@lists.m4if.org]On Behalf Of Kasturi Rangam > Sent: Friday, May 10, 2024 2:46 PM > To: technotes@lists.m4if.org > Subject: [M4IF Technotes] GMC > > > I am trying to under GMC in MPEG4. > Looks like you can have 0, 1, 2 or 3 sprite_warping_points. > > To decode a 0 and 1 sprite_warping_points macroblock, you can > fetch the whole macroblock data from the reference to do pixel > prediction. > > However, for 2 and 3 warping_points, the motion vector for each > pixel can be anywhere in the reference frame. Thus we might need > to perform 64 data fetches to predict one macroblock. > > Is there a range that can be calculated for each macroblock, so that > we can fetch data only once? > > Thanks, > > Kasturi > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes From rkoenen intertrust.com Wed May 15 11:33:10 2002 From: rkoenen intertrust.com (Rob Koenen) Date: Wed Jul 30 14:07:58 2003 Subject: [M4IF Technotes] GMC Message-ID: <3C124172E7FDD511B510000347426D59AF5471@exchange.epr.com> Suzuki-san, > ISMA is just example, not generic. > My suggestion is not to add its own levels, that is to define > the limitation for the current levels. A limitation on the current Level definitions is axactly the same as defining new Levels ... > I think that > 1. the limitation on encoding defined by an assosiation does not > cause the prombles for existing products, and I agree in principle. However, the limitation will then also be exploited in the decoder, which then does go on to cause problems, because, as you rightly say below, such a decoder will then not be able to decode all permitted bitstreams anymore ... If it is just a limitation on the encoder without consequences for the decoder then there is no problem at all. There are people today that claim they support Advanced Simple Profile, while they do not implement e.g. B frames or 1/4 pel motion compensation. As long as this is only the encoder, there is no problem with interoperability. The only problem is with the quality of the encoded video, which is not nearly as good as it could have been. If these tools, however, are not implemented in the DEcoder, then a claim to support Advanced Simple is simply a false statement (also called "lie"). > 2. the limitation on decoder in the specific association does not > cause the prombles, though such decoder could not decode all > standard bitstreams. Best, Rob From rkoenen intertrust.com Wed May 15 11:40:40 2002 From: rkoenen intertrust.com (Rob Koenen) Date: Wed Jul 30 14:07:58 2003 Subject: [M4IF Technotes] (no subject) Message-ID: <3C124172E7FDD511B510000347426D59AF5474@exchange.epr.com> While someone from DivX may be listening, it may be a wise idea to (also) direct product-specific questions directly to the company that makes the product. Best Rob > -----Original Message----- > From: wuks@bhnec.nec.co.jp [mailto:wuks@bhnec.nec.co.jp] > Sent: Tuesday, May 14, 2024 4:33 > To: technotes@lists.m4if.org > Subject: [M4IF Technotes] (no subject) > > > hi, > > what's the meaning of terms "Rate control averaging > period,frames" and > "Rate control reaction period,frames" in the DivX? > > thank for your help! > > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes > From jgreenhall divxnetworks.com Wed May 15 11:47:24 2002 From: jgreenhall divxnetworks.com (Jordan Greenhall) Date: Wed Jul 30 14:07:58 2003 Subject: [M4IF Technotes] (no subject) In-Reply-To: <785C7AF49DC3514B98BF059A8ECBC772578822@mrsmith.divxnetworks.com> Message-ID: <785C7AF49DC3514B98BF059A8ECBC77248B5CE@mrsmith.divxnetworks.com> We are indeed listening. "Wuks", you should be getting a contact from our technology team today. Jordan -----Original Message----- From: Rob Koenen [mailto:rkoenen@intertrust.com] Sent: Wednesday, May 15, 2024 10:41 AM To: 'wuks@bhnec.nec.co.jp'; technotes@lists.m4if.org Cc: Jordan "Logos" Greenhall (E-mail) Subject: RE: [M4IF Technotes] (no subject) While someone from DivX may be listening, it may be a wise idea to (also) direct product-specific questions directly to the company that makes the product. Best Rob > -----Original Message----- > From: wuks@bhnec.nec.co.jp [mailto:wuks@bhnec.nec.co.jp] > Sent: Tuesday, May 14, 2024 4:33 > To: technotes@lists.m4if.org > Subject: [M4IF Technotes] (no subject) > > > hi, > > what's the meaning of terms "Rate control averaging > period,frames" and > "Rate control reaction period,frames" in the DivX? > > thank for your help! > > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes > From krangam lsil.com Wed May 15 12:07:25 2002 From: krangam lsil.com (Kasturi Rangam) Date: Wed Jul 30 14:07:58 2003 Subject: [M4IF Technotes] GMC References: <000a01c1fbde$57098e00$c41a420c@C1143306A> <3CE23D4D.FEB4CC36@crl.hitachi.co.jp> Message-ID: <3CE2A3DD.3BFAAE9D@lsil.com> Yoshinori Suzuki wrote: > > Dear Dr. Cismas and all, > > > GMC is usefull to transmit only once a motion vector that applies or > > can be extrapolated by simple scaling to several macroblocks. Beyond > > that, I'm not sure about its real life usefullness. Without apriori > > knowledge, it will be quite difficult for the encoder to figure out how > > to use this feature. And even if it does, I'm not sure how many bits > > are saved. But on the downside, an MPEG4 decoder which claims to be > > ASP compliant, has to support these features even if all commercial > > encoders will never use affine based prediction in all its generality. > > In my experience on the MPEG-4 standard activities, the affine based > prediction provides 10-30% bit saving compared with the Version 1 tool sets > of MPEG-4 Video at low bitrate if the sequence has zooming scene and > the actual global motion is detected. And some methods for the global motion > estimetion have been developed and made public. I understand that > the encoding techniques on GMC are not familier to the hardware implementers, > since its features are not found in the MPEG-2 and MPEG-4 Version 1 standard. > However, I believe that it will be available in the near future, and > the functions for affine tranform in the ASP decoder will be useful. Thanks for the great responses for my question. I am investigating hardware implementation of GMC. It looks like it's going to take quite a bit of hardware and bandwidth to support this feature and to claim GMC decode support. As Sorin mentioned we would like to have additional levels in ASP to have some restrictions on GMC. What reasonable request does it take for the MPEG to create it's own amendment? I strongly request for this. Thanks, --Kasturi From rkoenen intertrust.com Wed May 15 12:21:04 2002 From: rkoenen intertrust.com (Rob Koenen) Date: Wed Jul 30 14:07:58 2003 Subject: [M4IF Technotes] GMC Message-ID: <3C124172E7FDD511B510000347426D59AF547C@exchange.epr.com> > What reasonable request does it take for the MPEG to create it's own > amendment? I strongly request for this. It takes a techically documented request supported by as many companies as you can find, although requests by a single company will surely be considered. The request should be aimed at the Reqquirements Group. Fernando Pereira (CC-ed) chairs that group. The next MPEG meeting is end of July, see http://mpeg.tilab.com Because the amount of Levels should be kept to a minimum, I would not fully rule out an amendment on the existing levels. Perhaps the parties that have already implemented the decoders can live with that. If none of the existing encoders exceeds these limits, and future ones won't either (because of such an amendment) then no encoders or decoders will ever be broken. There are precedents for such amendments, even though they are fairly rare and MPEG is very careful doeing these things. Best, Rob From krangam lsil.com Wed May 15 18:30:17 2002 From: krangam lsil.com (Kasturi Rangam) Date: Wed Jul 30 14:07:58 2003 Subject: [M4IF Technotes] sprite_brightness_change_factor Message-ID: <3CE2FD99.A924AF20@lsil.com> Hi All, I remember someone mentioning that the sprite_brightness_change_factor must be '0' for GMC. Is it true? Where does it say so if it is? Thanks, Kasturi From yosinori crl.hitachi.co.jp Thu May 16 11:02:34 2002 From: yosinori crl.hitachi.co.jp (Yoshinori Suzuki) Date: Wed Jul 30 14:07:58 2003 Subject: [M4IF Technotes] sprite_brightness_change_factor References: <3CE2FD99.A924AF20@lsil.com> Message-ID: <3CE3052A.1081E82F@crl.hitachi.co.jp> Dear Dr. Rangam, Kasturi Rangam wrote: > > I remember someone mentioning that the sprite_brightness_change_factor > must be '0' for GMC. Is it true? Where does it say so if it is? Yes. This is an editorial issue. This revision will be covered by the corrigendum. The revised text will be made public after the MPEG meeting in October. At the MPEG meeting in May, the draft text for corrigendum including this revision was approved, but it is not public one. Best regards, Yoshinori Suzuki Hitachi, Ltd. From yosinori crl.hitachi.co.jp Thu May 16 14:00:03 2002 From: yosinori crl.hitachi.co.jp (Yoshinori Suzuki) Date: Wed Jul 30 14:07:59 2003 Subject: [M4IF Technotes] GMC References: <3C124172E7FDD511B510000347426D59AF5471@exchange.epr.com> Message-ID: <3CE32EC3.314E74A@crl.hitachi.co.jp> Dear Rob, Thank you for the correction. I fully agree to your suggestion. All the decoders should support all functions in standard. And I hope that the all tools in adavanced simple are implemented in an encoder for taking advantage of the feature of Advanced Simple on the visual quality. Best regards, Yoshinori Suzuki Hitachi, Ltd. Rob Koenen wrote: > > Suzuki-san, > > > ISMA is just example, not generic. > > My suggestion is not to add its own levels, that is to define > > the limitation for the current levels. > > A limitation on the current Level definitions is axactly the same > as defining new Levels ... > > > I think that > > 1. the limitation on encoding defined by an assosiation does not > > cause the prombles for existing products, and > > I agree in principle. > However, the limitation will then also be exploited in the decoder, > which then does go on to cause problems, because, as you rightly say below, > such a decoder will then not be able to decode all permitted bitstreams > anymore ... > > If it is just a limitation on the encoder without consequences for the > decoder then there is no problem at all. There are people today that > claim they support Advanced Simple Profile, while they do not implement > e.g. B frames or 1/4 pel motion compensation. As long as this is only > the encoder, there is no problem with interoperability. The only problem > is with the quality of the encoded video, which is not nearly as good > as it could have been. If these tools, however, are not implemented in > the DEcoder, then a claim to support Advanced Simple is simply a false > statement (also called "lie"). > > > 2. the limitation on decoder in the specific association does not > > cause the prombles, though such decoder could not decode all > > standard bitstreams. > > Best, > Rob > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes From giuseppe.spampinato st.com Fri May 17 16:55:28 2002 From: giuseppe.spampinato st.com (giuseppe.spampinato@st.com) Date: Wed Jul 30 14:07:59 2003 Subject: [M4IF Technotes] MPEG-4 video stuffing bits Message-ID: Hi everybody, in the MPEG-4 standard at the end of each frame you have to insert stuffing bits to be byte-aligned. But could you insert also different consecutive bytes in this manner? And which value these bytes must contain? Reading the standard this seems to be possible and the value of the stuffing bytes should be "011111111", but Momusys decoder does not support this feature, while Microsoft decode these bytes correctly. Is it a bug in Momusys decoder (also in the last version contained in the file w4711.zip) or it is not allowed by the standard. If it is not allowed by the standard, where can I insert other bytes to satisfy the Video Buffer Verifier and avoid underflow? Many thanks!!! Giuseppe Spampinato From raghu hmus.net Fri May 17 17:44:20 2002 From: raghu hmus.net (Raaghu Nagaraj) Date: Wed Jul 30 14:07:59 2003 Subject: [M4IF Technotes] MPEG4 AC Prediction Question Message-ID: <30A6344AEBFC85429C30FF6C9C501CD102AC66@bays02.mediator.com> Hello, I would really appreciate if someone could point me to any standard/non-standard based studies done on AC Prediction in terms of the quality gain and/or computational complexity. Thanks, Raghu From wuks bhnec.nec.co.jp Mon May 20 21:23:28 2002 From: wuks bhnec.nec.co.jp (wuks@bhnec.nec.co.jp) Date: Wed Jul 30 14:07:59 2003 Subject: [M4IF Technotes] (no subject) Message-ID: hi, what's the code of the EOB in the MPEG-4 visual? thank for your help! From luca.celetto st.com Mon May 20 16:07:14 2002 From: luca.celetto st.com (Luca Celetto) Date: Wed Jul 30 14:07:59 2003 Subject: [M4IF Technotes] (no subject) References: Message-ID: <3CE8F502.FA4F1F6D@st.com> Hi, there is no EOB code as in MPEG-2, because in MPEG-4 codes are organized in triplets LAST-RUN-LEVEL where "LAST=1" indicates the last coefficient of the block (otherwise "LAST=0"). See tables B-16, B-17, B-22 of visual. wuks@bhnec.nec.co.jp wrote: > hi, > > what's the code of the EOB in the MPEG-4 visual? > > thank for your help! > > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes From the_ether btinternet.com Mon May 20 19:21:59 2002 From: the_ether btinternet.com (the_ether) Date: Wed Jul 30 14:07:59 2003 Subject: [M4IF Technotes] Offscreen MVs Message-ID: <003701c20022$dae69db0$910c27d9@home> Is it possible to have a motion vector to point outside the screen? I know you can point outside a VOP (with long header only if I remember correctly), but off-screen? Say there is a feature at position (0,0) in frame 1 (F1) and in F2 that feature moves up by 1 pixel so that we lose the top row. What I'd like to do is to signal the decoder a motion vector of (0,-1), but the decoder would then need to know what pixels to put in the bottom row of the macroblock in F2. I could always just pass a MV of (0,0) buit if we take the worst case whereby every row of that feature had a different luminance value (eg stripped) then I would get a larger error value than if I sent a MV of (0,-1) and the decoder put in some random pixels into the lowest row of that macroblock. I don't think I can pass MVs that point off screen but I thought I'd check. regards Graham From Peter.Haighton m4if.org Mon May 20 17:28:31 2002 From: Peter.Haighton m4if.org (Peter Haighton) Date: Wed Jul 30 14:07:59 2003 Subject: [M4IF Technotes] Offscreen MVs In-Reply-To: <003701c20022$dae69db0$910c27d9@home> Message-ID: Graham, Yes, it is possible for a motion vector to point off the screen. The off screen pixels are duplicated from the edge of the on screen pixels. Peter -----Original Message----- From: technotes-admin@lists.m4if.org [mailto:technotes-admin@lists.m4if.org]On Behalf Of the_ether Sent: Monday, May 20, 2024 1:22 PM To: technotes@lists.m4if.org Subject: [M4IF Technotes] Offscreen MVs Is it possible to have a motion vector to point outside the screen? I know you can point outside a VOP (with long header only if I remember correctly), but off-screen? Say there is a feature at position (0,0) in frame 1 (F1) and in F2 that feature moves up by 1 pixel so that we lose the top row. What I'd like to do is to signal the decoder a motion vector of (0,-1), but the decoder would then need to know what pixels to put in the bottom row of the macroblock in F2. I could always just pass a MV of (0,0) buit if we take the worst case whereby every row of that feature had a different luminance value (eg stripped) then I would get a larger error value than if I sent a MV of (0,-1) and the decoder put in some random pixels into the lowest row of that macroblock. I don't think I can pass MVs that point off screen but I thought I'd check. regards Graham _______________________________________________ Technotes mailing list Technotes@lists.m4if.org http://lists.m4if.org/mailman/listinfo/technotes From the_ether btinternet.com Mon May 20 23:03:51 2002 From: the_ether btinternet.com (the_ether) Date: Wed Jul 30 14:07:59 2003 Subject: [M4IF Technotes] Offscreen MVs References: Message-ID: <010201c20041$d9573300$081127d9@home> Thank you Peter. > Yes, it is possible for a motion vector to point off the screen. The off > screen pixels are duplicated from the edge of the on screen pixels. Just so I'm absolutely sure I understand, in my example which edge is filled? If I start with the following feature at (0,0): 1 1 1....1 2 2 2....2 3 3 3....3 16 16 16 ...16 and if this feature moves up by one pixel so that the motion vector is (0,-1), what will the 1st and last rows of the corresponding macroblock look like? What I want to decribe to the decoder by sending a MV of (0,-1) is that the first 2 rows should be 2222... 3333... the fifteenth should be 16 16 16... and the last row could be anything. if instead the first two rows are 2222... 2222... and the last row 16 16 16... then only the first row would be correct. My guess is that the last is the behaviour that would occur. From Peter.Haighton m4if.org Mon May 20 22:01:05 2002 From: Peter.Haighton m4if.org (Peter Haighton) Date: Wed Jul 30 14:07:59 2003 Subject: [M4IF Technotes] Offscreen MVs In-Reply-To: <010201c20041$d9573300$081127d9@home> Message-ID: Graham, If I understand you correctly, the values that you are mentioning are coming from the reference frame. So by moving the block up by one pixel, you would get 1 1 2 3 . . . 15 Peter -----Original Message----- From: technotes-admin@lists.m4if.org [mailto:technotes-admin@lists.m4if.org]On Behalf Of the_ether Sent: Monday, May 20, 2024 5:04 PM To: Peter Haighton; technotes@lists.m4if.org Subject: Re: [M4IF Technotes] Offscreen MVs Thank you Peter. > Yes, it is possible for a motion vector to point off the screen. The off > screen pixels are duplicated from the edge of the on screen pixels. Just so I'm absolutely sure I understand, in my example which edge is filled? If I start with the following feature at (0,0): 1 1 1....1 2 2 2....2 3 3 3....3 16 16 16 ...16 and if this feature moves up by one pixel so that the motion vector is (0,-1), what will the 1st and last rows of the corresponding macroblock look like? What I want to decribe to the decoder by sending a MV of (0,-1) is that the first 2 rows should be 2222... 3333... the fifteenth should be 16 16 16... and the last row could be anything. if instead the first two rows are 2222... 2222... and the last row 16 16 16... then only the first row would be correct. My guess is that the last is the behaviour that would occur. _______________________________________________ Technotes mailing list Technotes@lists.m4if.org http://lists.m4if.org/mailman/listinfo/technotes From the_ether btinternet.com Tue May 21 03:16:56 2002 From: the_ether btinternet.com (the_ether) Date: Wed Jul 30 14:07:59 2003 Subject: [M4IF Technotes] Offscreen MVs References: Message-ID: <000d01c20065$5f9f0870$081127d9@home> Yes it was the reference frame I was referring to. So with the result as you described I would get a macroblock (MB) that is misaligned by 2 rows of pixels. If the feature had moved offscreen by (0,-1), in frame 2, without using mpeg compression, I would see 2 3 4 .. 15 So in such a situation it would best to use a MV of (0,0) as I'd only be wrong by one row of pixels. Well, I guess it's not such a big problem as it's not that common on occurrence. the most likely would be camera movement instead of feature movement at the edge of frame. ----- Original Message ----- From: "Peter Haighton" To: "the_ether" ; Sent: Tuesday, May 21, 2024 2:01 AM Subject: RE: [M4IF Technotes] Offscreen MVs > Graham, > > If I understand you correctly, the values that you are mentioning are > coming from the reference frame. So by moving the block up by one pixel, > you would get > > 1 > 1 > 2 > 3 > . > . > . > 15 > > Peter > > -----Original Message----- > From: technotes-admin@lists.m4if.org > [mailto:technotes-admin@lists.m4if.org]On Behalf Of the_ether > Sent: Monday, May 20, 2024 5:04 PM > To: Peter Haighton; technotes@lists.m4if.org > Subject: Re: [M4IF Technotes] Offscreen MVs > > > Thank you Peter. > > > Yes, it is possible for a motion vector to point off the screen. The off > > screen pixels are duplicated from the edge of the on screen pixels. > > Just so I'm absolutely sure I understand, in my example which edge is > filled? > > If I start with the following feature at (0,0): > > 1 1 1....1 > 2 2 2....2 > 3 3 3....3 > 16 16 16 ...16 > > and if this feature moves up by one pixel so that the motion vector is > (0,-1), what will the 1st and last rows of the corresponding macroblock > look > like? > > What I want to decribe to the decoder by sending a MV of (0,-1) is that > the > first 2 rows should be > > 2222... > 3333... > > the fifteenth should be > > 16 16 16... > > and the last row could be anything. > > if instead the first two rows are > > 2222... > 2222... > > and the last row > > 16 16 16... > > then only the first row would be correct. My guess is that the last is the > behaviour that would occur. > > > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes > > From Max.Griessl dynapel.de Tue May 21 10:32:24 2002 From: Max.Griessl dynapel.de (Max Griessl) Date: Wed Jul 30 14:07:59 2003 Subject: [M4IF Technotes] MPEG-4 video stuffing bits References: Message-ID: <3CE9F808.2060408@dynapel.de> There exists a possibility after VOP's in some cases (see document N4350, syntax description of VideoObjectLayer()): if ((preceding_vop_coding_type == "B" || preceding_vop_coding_type == "S" || video_object_layer_shape != "rectangular") && next_bits() == stuffing_start_code) { stuffing_start_code while (next_bits() != 0000 0000 0000 0000 0000 0001 ) stuffing_byte } stuffing_byte is '11111111'. The other possibility is to use stuffing macro blocks, which works for all VOP types. Bye, Max Griessl giuseppe.spampinato@st.com wrote: > Hi everybody, > in the MPEG-4 standard > at the end of each frame you have to insert > stuffing bits to be byte-aligned. > > But could you insert also different consecutive > bytes in this manner? > And which value these bytes must contain? > > Reading the standard this seems to be possible > and the value of the stuffing bytes should be "011111111", > but Momusys decoder does not support this feature, > while Microsoft decode these bytes correctly. > > Is it a bug in Momusys decoder (also in the last version > contained in the file w4711.zip) or it is not allowed > by the standard. > > If it is not allowed by the standard, where can I > insert other bytes to satisfy the Video Buffer Verifier > and avoid underflow? > > > Many thanks!!! > Giuseppe Spampinato > > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes > > -- Max Griessl DynaPel Laboratories GmbH Software Design Fraunhoferstr. 9/2 Tel: +49 (0) 89 96242812 D-85737 Ismaning, Germany Fax: +49 (0) 89 96242890 http://www.dynapel.de From uday.k ap.sony.com Tue May 21 14:39:52 2002 From: uday.k ap.sony.com (Uday Kiran) Date: Wed Jul 30 14:07:59 2003 Subject: [M4IF Technotes] Conformance tests for MPEG-2/4 AAC Message-ID: <5.1.0.14.0.20020521133731.00a11b80@43.88.102.8> Hello, Does anyone have the conformance test utlity for testing MPEG-2/4 AAC bitstreams?. What are the different conformance tests available for MPEG-2/4 AAC?. Warm Regards, Uday Sony India Software Centre Software Architecture Division No.1, "Adarsh Opus", 2nd Floor Campbell Road, Austin Town, Bangalore - 47 Phone: +91-80-5546825 / 6 / 7 ext 246 Fax: +91-80-5546828 From arvind_raman_tech yahoo.com Tue May 21 03:57:32 2002 From: arvind_raman_tech yahoo.com (Arvind Raman) Date: Wed Jul 30 14:07:59 2003 Subject: [M4IF Technotes] (video_object_layer_width / height) not a multiple of 16 Message-ID: <20020521095732.60067.qmail@web12406.mail.yahoo.com> I am trying to decode a MPEG4 simple profile bitstream with dimensions 352 x 242. My understanding of the standard is that for all decoding operations (Motion compensation etc.) the video_object_layer_height / width should be rounded off to the next multiple of 16 ; in this case 352 x 256. Whereas for display purposes the dimesions as sent in the bitstream (i.e 352 x 242)should be used. Using the above strategy results in some artifacts in the decoded output. Could anybody let me know where I could be going wrong. The decoder I am using has passed all the conformance test vectors and hence I dont expect any major / fundamental bugs in the implementation. Thanks and regards Arvind __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From r.beattie indigovision.com Tue May 21 12:22:55 2002 From: r.beattie indigovision.com (Robert Beattie) Date: Wed Jul 30 14:07:59 2003 Subject: [M4IF Technotes] (video_object_layer_width / height) not a mu ltiple of 16 Message-ID: <1F3071585480D5118B8E00B0D0AA311406AF99@ThisAddressDoesNotExist> Could it possibly be due to unrestricted motion vectors. That is predicted data from lines > 241 should be copied from line 241 rather than just using the previously decoded (junk) data ? Cheer's Dr Rob Beattie Indigo > I am trying to decode a MPEG4 simple profile bitstream > with dimensions 352 x 242. My understanding of the > standard is that for all decoding operations (Motion > compensation etc.) the video_object_layer_height / > width should be rounded off to the next multiple of 16 > ; in this case 352 x 256. Whereas for display purposes > the dimesions as sent in the bitstream (i.e 352 x > 242)should be used. > Using the above strategy results in some artifacts in > the decoded output. Could anybody let me know where I > could be going wrong. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on the above detailed phone number and delete the message from your computer: you may not copy or forward this e-mail, or use or disclose its contents to any other person. We thank you in anticipation for your assistance. As internet communications are capable of data corruption no responsibility is accepted for changes made to this message after it was sent. For this reason it may be inappropriate to rely on information contained in this e-mail without obtaining written confirmation of it. In addition, no liability or responsibility is accepted for viruses and it is your responsibility to scan any attachments to this e-mail. Nothing in this e-mail shall constitute or be construed as constituting an offer, obligation or an acceptance of any offer previously made. Opinions, comments and other information in this e-mail that do not relate to the business of IndigoVision Group plc, IndigoVision Limited and/or IndigoVision, Inc. shall be understood as neither given nor endorsed by the companies or any of them. From r.beattie indigovision.com Tue May 21 12:56:48 2002 From: r.beattie indigovision.com (Robert Beattie) Date: Wed Jul 30 14:07:59 2003 Subject: [M4IF Technotes] (video_object_layer_width / height) not a mu ltiple of 16 Message-ID: <1F3071585480D5118B8E00B0D0AA311406AF9A@ThisAddressDoesNotExist> > Well I tried that too, but the artifacts seem to exist > even then. This is what I did: > I allocated frame buffers to store 22 x 16 MB data > And tried clipping the motion vectors when they > pointed to regions beyond 241 and 256 lines. By clipping I take it you mean you padded the data from outside the active image area with the boundary value ? Just clipping the vectors is not really sufficient. > What surprises me most is that the artifacts are not > limited to the last row of MBs but are present over > the entire VOP. Sound's worryingly like a proper bug rather than just a misinterpretation of the standard. I cant think why it would get through the conformance tests though. Sorry I cant be more help, Dr Rob Beattie Indigo The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on the above detailed phone number and delete the message from your computer: you may not copy or forward this e-mail, or use or disclose its contents to any other person. We thank you in anticipation for your assistance. As internet communications are capable of data corruption no responsibility is accepted for changes made to this message after it was sent. For this reason it may be inappropriate to rely on information contained in this e-mail without obtaining written confirmation of it. In addition, no liability or responsibility is accepted for viruses and it is your responsibility to scan any attachments to this e-mail. Nothing in this e-mail shall constitute or be construed as constituting an offer, obligation or an acceptance of any offer previously made. Opinions, comments and other information in this e-mail that do not relate to the business of IndigoVision Group plc, IndigoVision Limited and/or IndigoVision, Inc. shall be understood as neither given nor endorsed by the companies or any of them. From sps iis.fhg.de Tue May 21 16:43:44 2002 From: sps iis.fhg.de (Ralph Sperschneider) Date: Wed Jul 30 14:08:00 2003 Subject: [M4IF Technotes] Re: Conformance tests for MPEG-2/4 AAC References: <5.1.0.14.0.20020521133731.00a11b80@43.88.102.8> Message-ID: <3CEA4F10.AAA44C32@iis.fhg.de> Dear Uday, the conformance test tools are part of MPEG-4 Part-5 (reference software). The individual conformance tests are described in MPEG-4 Part-4 (conformance). Best regards, Ralph Uday Kiran wrote: > > Hello, > Does anyone have the conformance test utlity for testing MPEG-2/4 > AAC bitstreams?. What are the different conformance tests available for > MPEG-2/4 AAC?. > > Warm Regards, > Uday > > Sony India Software Centre > Software Architecture Division > No.1, "Adarsh Opus", 2nd Floor > Campbell Road, Austin Town, Bangalore - 47 > Phone: +91-80-5546825 / 6 / 7 ext 246 > Fax: +91-80-5546828 > > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes -- Dipl.-Ing. Ralph Sperschneider | Phone: +49 9131 776 344 FhG IIS-A | Fax: +49 9131 776 398 Am Weichselgarten 3 | mailto:sps@iis.fhg.de D 91058 Erlangen | http://www.iis.fhg.de/amm/ -------------- next part -------------- A non-text attachment was scrubbed... Name: sps.vcf Type: text/x-vcard Size: 336 bytes Desc: Card for Ralph Sperschneider Url : /pipermail/mp4-tech/attachments/20020521/e820fb50/sps.bin From ravi_biju yahoo.com Wed May 22 04:47:48 2002 From: ravi_biju yahoo.com (Biju Ravindran) Date: Wed Jul 30 14:08:00 2003 Subject: [M4IF Technotes] (video_object_layer_width / height) not a mu ltiple of 16 In-Reply-To: <1F3071585480D5118B8E00B0D0AA311406AF99@ThisAddressDoesNotExist> Message-ID: <20020522104748.39519.qmail@web12103.mail.yahoo.com> Hi, If we do motion estimation on outside the boundry after extending the edge pels, it can give a match which will result in reduced bit rate. So there is no need of restricting the motion vector if the edge pels are copied outside the effective area. -biju --- Robert Beattie wrote: > Could it possibly be due to unrestricted motion > vectors. That is predicted > data from lines > 241 should be copied from line 241 > rather than just using > the previously decoded (junk) data ? > > Cheer's > > Dr Rob Beattie > Indigo > > > I am trying to decode a MPEG4 simple profile > bitstream > > with dimensions 352 x 242. My understanding of the > > standard is that for all decoding operations > (Motion > > compensation etc.) the video_object_layer_height / > > width should be rounded off to the next multiple > of 16 > > ; in this case 352 x 256. Whereas for display > purposes > > the dimesions as sent in the bitstream (i.e 352 x > > 242)should be used. > > Using the above strategy results in some artifacts > in > > the decoded output. Could anybody let me know > where I > > could be going wrong. > The information in this e-mail is confidential and > for use by the > addressee(s) only. If you are not the intended > recipient (or responsible for > delivery of the message to the intended recipient) > please notify us > immediately on the above detailed phone number and > delete the message from > your computer: you may not copy or forward this > e-mail, or use or disclose > its contents to any other person. We thank you in > anticipation for your > assistance. As internet communications are capable > of data corruption no > responsibility is accepted for changes made to this > message after it was > sent. For this reason it may be inappropriate to > rely on information > contained in this e-mail without obtaining written > confirmation of it. In > addition, no liability or responsibility is accepted > for viruses and it is > your responsibility to scan any attachments to this > e-mail. Nothing in this > e-mail shall constitute or be construed as > constituting an offer, obligation > or an acceptance of any offer previously made. > Opinions, comments and other > information in this e-mail that do not relate to the > business of > IndigoVision Group plc, IndigoVision Limited and/or > IndigoVision, Inc. shall > be understood as neither given nor endorsed by the > companies or any of them. > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes ===== ciao, ..ju __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From r.beattie indigovision.com Wed May 22 13:41:36 2002 From: r.beattie indigovision.com (Robert Beattie) Date: Wed Jul 30 14:08:00 2003 Subject: [M4IF Technotes] (video_object_layer_width / height) not a mu ltiple of 16 Message-ID: <1F3071585480D5118B8E00B0D0AA311406AF9C@ThisAddressDoesNotExist> > If we do motion estimation on outside the boundary > after extending the edge pels, it can give a match > which will result in reduced bit rate. So there is no > need of restricting the motion vector if the edge pels > are copied outside the effective area. This is true Biju. What I am saying is that edge pels should be extended from line 241 rather than line 255 for the image resolution described. My understanding of the standard is that the decoder can not treat a 352x256 and 352x242 in the same way when extending the boundary. I have a concern with this as our (vhdl / fpga) decoder successfully passed the compliance tests even though it did not (in my understanding) support this case correctly. This being the case is the coverage of the conformance streams really adequate ? There are several other similar cases which cause me concern. I would be interested if anyone else has found possible holes in the conformance tests ? Your's waiting to be corrected, Dr Rob Beattie Indigo The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on the above detailed phone number and delete the message from your computer: you may not copy or forward this e-mail, or use or disclose its contents to any other person. We thank you in anticipation for your assistance. As internet communications are capable of data corruption no responsibility is accepted for changes made to this message after it was sent. For this reason it may be inappropriate to rely on information contained in this e-mail without obtaining written confirmation of it. In addition, no liability or responsibility is accepted for viruses and it is your responsibility to scan any attachments to this e-mail. Nothing in this e-mail shall constitute or be construed as constituting an offer, obligation or an acceptance of any offer previously made. Opinions, comments and other information in this e-mail that do not relate to the business of IndigoVision Group plc, IndigoVision Limited and/or IndigoVision, Inc. shall be understood as neither given nor endorsed by the companies or any of them. From wuks bhnec.nec.co.jp Thu May 23 16:26:36 2002 From: wuks bhnec.nec.co.jp (wuks@bhnec.nec.co.jp) Date: Wed Jul 30 14:08:00 2003 Subject: [M4IF Technotes] (no subject) Message-ID: hi, when encode a video_packet,is the code macroblock_number numbers of macroblock in the video_packet or the first encoded in the video_packet macroblock's address? thank for your help! From gnitin noida.hcltech.com Thu May 23 14:25:22 2002 From: gnitin noida.hcltech.com (Nitin Gupta--DSP, Noida) Date: Wed Jul 30 14:08:01 2003 Subject: [M4IF Technotes] (no subject) Message-ID: Hi, The code macroblock_number is the number of the first encoded macroblock in the video packet. Thanx & Regards, Nitin. -----Original Message----- From: wuks@bhnec.nec.co.jp [mailto:wuks@bhnec.nec.co.jp] Sent: Thursday, May 23, 2024 12:57 PM To: technotes@lists.m4if.org Subject: [M4IF Technotes] (no subject) hi, when encode a video_packet,is the code macroblock_number numbers of macroblock in the video_packet or the first encoded in the video_packet macroblock's address? thank for your help! _______________________________________________ Technotes mailing list Technotes@lists.m4if.org http://lists.m4if.org/mailman/listinfo/technotes From s.voukelatos indigovision.com Thu May 23 10:03:06 2002 From: s.voukelatos indigovision.com (Stathis Voukelatos) Date: Wed Jul 30 14:08:01 2003 Subject: [M4IF Technotes] (no subject) Message-ID: <1F3071585480D5118B8E00B0D0AA3114738F59@ThisAddressDoesNotExist> Hi, The macroblock_number is the address of the first macroblock in the video packet. Regards, Stathis Stathis Voukelatos, PhD Software Engineer IndigoVision Ltd The Edinburgh Technopole Bush Loan, Edinburgh Scotland, UK EH26 0PJ +44 (0)131 4757345 +44 (0)131 4757201 (Fax) http://www.indigovision.com > -----Original Message----- > From: wuks@bhnec.nec.co.jp [mailto:wuks@bhnec.nec.co.jp] > Sent: Thursday, May 23, 2024 8:27 AM > To: technotes@lists.m4if.org > Subject: [M4IF Technotes] (no subject) > > > hi, > > when encode a video_packet,is the code macroblock_number > numbers of > macroblock in the video_packet or the first encoded in the > video_packet > macroblock's address? > > thank for your help! > > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes > The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on the above detailed phone number and delete the message from your computer: you may not copy or forward this e-mail, or use or disclose its contents to any other person. We thank you in anticipation for your assistance. As internet communications are capable of data corruption no responsibility is accepted for changes made to this message after it was sent. For this reason it may be inappropriate to rely on information contained in this e-mail without obtaining written confirmation of it. In addition, no liability or responsibility is accepted for viruses and it is your responsibility to scan any attachments to this e-mail. Nothing in this e-mail shall constitute or be construed as constituting an offer, obligation or an acceptance of any offer previously made. Opinions, comments and other information in this e-mail that do not relate to the business of IndigoVision Group plc, IndigoVision Limited and/or IndigoVision, Inc. shall be understood as neither given nor endorsed by the companies or any of them. From gnitin noida.hcltech.com Thu May 23 15:24:35 2002 From: gnitin noida.hcltech.com (Nitin Gupta--DSP, Noida) Date: Wed Jul 30 14:08:01 2003 Subject: [M4IF Technotes] Reverse Decoding in DP mode Message-ID: Hi all, I have doubts regarding the reverse decoding which we do for error resilience in the DP mode having reversible_vlc. I want to know why the ac_pred_flag in the DP mode having reversible_vlc should not be 0 for all the macroblocks ? If we consider a case that a video packet consist of 3 or more macroblock rows. Then if we encounter an error in the forward direction lets say in the first row, we would go to the end of the video packet & would start reverse decoding from there. Now if we once again encounter error in that row only, then the middle row is not decoded in the forward or the reverse direction. So now if we find ac_pred_flag = 1 in the macroblocks that were decoded in the reverse direction, then how can we do AC Prediction as there might be the case that the prediction is done from the above row & in such a case we don't have any data for the above row. Plz advise how to proceed in such a case as i am stuck in its implementation & i am unable to move further forward now. Thanx & Regards, Nitin Gupta. From hagai enquad.com Thu May 23 13:06:50 2002 From: hagai enquad.com (hagai folkman) Date: Wed Jul 30 14:08:01 2003 Subject: [M4IF Technotes] MPEG-4 ASIC Video Cores Message-ID: <000e01c20241$8f4d8ff0$e300000a@HagaiFolkman> Hi, Do you knows where I can find ASIC CoDEC core or DSP ASIC core dedicated to video ? Is anyone working on that ? -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20020523/133ad248/attachment.html From sundar tataelxsi.co.in Thu May 23 16:23:49 2002 From: sundar tataelxsi.co.in (T Sundar Murthy) Date: Wed Jul 30 14:08:02 2003 Subject: [M4IF Technotes] Reverse Decoding in DP mode References: Message-ID: <3CECBC2D.1E9A1C3E@tataelxsi.co.in> Hi, In case of Reverse decoding, all the intra MBs are not displayed instead concealed (decode and discard. decoding is required to get the next MB position).. Only inter MBs are decoded and there will not be AC/DC prediction in case of inter MBs.section E.1.4.4.2.2 of ISO/IEC 14496-2 Second Edition. Sundar "Nitin Gupta--DSP, Noida" wrote: > Hi all, > I have doubts regarding the reverse decoding > which we do for error resilience in the DP mode having > reversible_vlc. I want to know why the ac_pred_flag > in the DP mode having reversible_vlc should not be > 0 for all the macroblocks ? > If we consider a case that a video packet consist > of 3 or more macroblock rows. Then if we encounter an > error in the forward direction lets say in the first row, > we would go to the end of the video packet & would start > reverse decoding from there. Now if we once again encounter > error in that row only, then the middle row is not decoded > in the forward or the reverse direction. So now if we find > ac_pred_flag = 1 in the macroblocks that were decoded in > the reverse direction, then how can we do AC Prediction > as there might be the case that the prediction is done > from the above row & in such a case we don't have any data for > the above row. > Plz advise how to proceed in such a case as i am stuck > in its implementation & i am unable to move further forward > now. > > Thanx & Regards, > Nitin Gupta. > > > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes -- From gnitin noida.hcltech.com Thu May 23 17:22:13 2002 From: gnitin noida.hcltech.com (Nitin Gupta--DSP, Noida) Date: Wed Jul 30 14:08:02 2003 Subject: [M4IF Technotes] Reverse Decoding in DP mode Message-ID: Thanx Sundar for ur response .. But still i would like to ask somethin .. that wht we have to display in the case of intra MBs in P-VOP i.e how do we do the concealment .. also wht happens in the case of an I-VOP ?? Thanx & Regards, Nitin Gupta. -----Original Message----- From: T Sundar Murthy [mailto:sundar@tataelxsi.co.in] Sent: Thursday, May 23, 2024 3:24 PM To: Nitin Gupta--DSP, Noida Cc: technotes@lists.m4if.org Subject: Re: [M4IF Technotes] Reverse Decoding in DP mode Hi, In case of Reverse decoding, all the intra MBs are not displayed instead concealed (decode and discard. decoding is required to get the next MB position).. Only inter MBs are decoded and there will not be AC/DC prediction in case of inter MBs.section E.1.4.4.2.2 of ISO/IEC 14496-2 Second Edition. Sundar "Nitin Gupta--DSP, Noida" wrote: > Hi all, > I have doubts regarding the reverse decoding > which we do for error resilience in the DP mode having > reversible_vlc. I want to know why the ac_pred_flag > in the DP mode having reversible_vlc should not be > 0 for all the macroblocks ? > If we consider a case that a video packet consist > of 3 or more macroblock rows. Then if we encounter an > error in the forward direction lets say in the first row, > we would go to the end of the video packet & would start > reverse decoding from there. Now if we once again encounter > error in that row only, then the middle row is not decoded > in the forward or the reverse direction. So now if we find > ac_pred_flag = 1 in the macroblocks that were decoded in > the reverse direction, then how can we do AC Prediction > as there might be the case that the prediction is done > from the above row & in such a case we don't have any data for > the above row. > Plz advise how to proceed in such a case as i am stuck > in its implementation & i am unable to move further forward > now. > > Thanx & Regards, > Nitin Gupta. > > > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes -- From n2689440 sparc1.cc.ncku.edu.tw Thu May 23 15:59:11 2002 From: n2689440 sparc1.cc.ncku.edu.tw (Gigi) Date: Wed Jul 30 14:08:02 2003 Subject: [M4IF Technotes] MPEG-4 Simple profile ? Message-ID: <002e01c20227$58b719d0$cd48748c@Iris> Hello, Would you mail me MPEG-4 Simple profile source code ? And the simple profile is the same as H.263++ ? Best regard Gigi -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20020523/da687444/attachment.html From rkoenen intertrust.com Thu May 23 08:59:40 2002 From: rkoenen intertrust.com (Rob Koenen) Date: Wed Jul 30 14:08:02 2003 Subject: [M4IF Technotes] MPEG-4 Simple profile ? Message-ID: <3C124172E7FDD511B510000347426D59AF55D8@exchange.epr.com> It's the same as H.263 baseline, not H.263++ SW and other resrouces are here: http://www.m4if.org/resources.php Best, Rob -----Original Message----- From: Gigi [mailto:n2689440@sparc1.cc.ncku.edu.tw] Sent: Wednesday, May 22, 2024 23:59 To: technotes@lists.m4if.org Subject: [M4IF Technotes] MPEG-4 Simple profile ? Hello, Would you mail me MPEG-4 Simple profile source code ? And the simple profile is the same as H.263++ ? Best regard Gigi -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20020523/7f647a13/attachment.html From DeepaliA improvsys.com Thu May 23 14:13:38 2002 From: DeepaliA improvsys.com (Deepali Arya) Date: Wed Jul 30 14:08:03 2003 Subject: [M4IF Technotes] High definition support Message-ID: <775BE9D2D47B434B8FA092E0980A3A2C03375E@improv_server> Hi all, Is there a level and profile of MPEG-4 that can be used for supporting high definition resolution ? Thanks. Deepali Arya Improv Systems Inc, Beverly. Email: deepalia@improvsys.com Tel: (978) 927-0555 x18 From neff PacketVideo.COM Thu May 23 12:23:58 2002 From: neff PacketVideo.COM (Ralph Neff) Date: Wed Jul 30 14:08:03 2003 Subject: [M4IF Technotes] MPEG-4 Simple profile ? Message-ID: <72263E8E8622D611975C0002B32C19D837E908@misty.packetvideo.com> Hi Gigi, Visual Simple Profile isn't identical to H.263 baseline, but there is a subset (called "short header mode") that is the same. So if you have an MPEG-4 Simple Profile decoder, you should be able to decode an H.263 baseline bitstream (minor header conversion may be needed, but it's easy). In general, a Simple Profile Bitstream won't work on an H.263 decoder, unless it's specifically restricted to short header mode. -Ralph -----Original Message----- From: Rob Koenen [mailto:rkoenen@intertrust.com] Sent: Thursday, May 23, 2024 8:00 AM To: 'Gigi'; technotes@lists.m4if.org Subject: RE: [M4IF Technotes] MPEG-4 Simple profile ? It's the same as H.263 baseline, not H.263++ SW and other resrouces are here: http://www.m4if.org/resources.php Best, Rob -----Original Message----- From: Gigi [mailto:n2689440@sparc1.cc.ncku.edu.tw] Sent: Wednesday, May 22, 2024 23:59 To: technotes@lists.m4if.org Subject: [M4IF Technotes] MPEG-4 Simple profile ? Hello, Would you mail me MPEG-4 Simple profile source code ? And the simple profile is the same as H.263++ ? Best regard Gigi -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20020523/9b8254d7/attachment.html From garysull microsoft.com Thu May 23 13:32:09 2002 From: garysull microsoft.com (Gary Sullivan) Date: Wed Jul 30 14:08:03 2003 Subject: [M4IF Technotes] MPEG-4 Simple profile ? Message-ID: <0170DDAD0BADFA4CBEC3B55A0748DCCC05B67233@red-msg-02.redmond.corp.microsoft.com> Skipped content of type multipart/alternative From rkoenen intertrust.com Thu May 23 14:02:44 2002 From: rkoenen intertrust.com (Rob Koenen) Date: Wed Jul 30 14:08:04 2003 Subject: [M4IF Technotes] MPEG-4 Simple profile ? Message-ID: <3C124172E7FDD511B510000347426D59AF55E7@exchange.epr.com> Thanks for the further explanation - I was in (too) short header mode. Rob -----Original Message----- From: Ralph Neff [mailto:neff@PacketVideo.COM] Sent: Thursday, May 23, 2024 11:24 To: 'Gigi' Cc: 'Rob Koenen'; technotes@lists.m4if.org Subject: RE: [M4IF Technotes] MPEG-4 Simple profile ? Hi Gigi, Visual Simple Profile isn't identical to H.263 baseline, but there is a subset (called "short header mode") that is the same. So if you have an MPEG-4 Simple Profile decoder, you should be able to decode an H.263 baseline bitstream (minor header conversion may be needed, but it's easy). In general, a Simple Profile Bitstream won't work on an H.263 decoder, unless it's specifically restricted to short header mode. -Ralph -----Original Message----- From: Rob Koenen [mailto:rkoenen@intertrust.com] Sent: Thursday, May 23, 2024 8:00 AM To: 'Gigi'; technotes@lists.m4if.org Subject: RE: [M4IF Technotes] MPEG-4 Simple profile ? It's the same as H.263 baseline, not H.263++ SW and other resrouces are here: http://www.m4if.org/resources.php Best, Rob -----Original Message----- From: Gigi [mailto:n2689440@sparc1.cc.ncku.edu.tw] Sent: Wednesday, May 22, 2024 23:59 To: technotes@lists.m4if.org Subject: [M4IF Technotes] MPEG-4 Simple profile ? Hello, Would you mail me MPEG-4 Simple profile source code ? And the simple profile is the same as H.263++ ? Best regard Gigi -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20020523/1d7cdd83/attachment.html From bylee intellix.co.kr Fri May 24 09:37:25 2002 From: bylee intellix.co.kr (=?ks_c_5601-1987?B?wMy6tMCx?=) Date: Wed Jul 30 14:08:04 2003 Subject: [M4IF Technotes] S/W encoding(DSP) VS. H/W ASIC encoding Message-ID: hi, In order to implement the MPEG-4 simple visual profile, not for mobile system, what are the main evaluation points to decide which is better between S/W encoding based on DSP and H/W ASIC encoding? The codec will be embedded into the digital survaillence system as an video commpression methods. As far as I know there are some MPEG-4 ASIC codec not for mobile solution. Which method do you recommend? Why? Thanks for your time! From wuks bhnec.nec.co.jp Fri May 24 09:58:38 2002 From: wuks bhnec.nec.co.jp (wuks@bhnec.nec.co.jp) Date: Wed Jul 30 14:08:04 2003 Subject: [M4IF Technotes] DC prediction Message-ID: 1) is there a code in the bitstream to flag DC prediction? In other words,in intra DC vlc, the DC of a intra MB are always coded in DC prediction mode? 2)what's use mcroblock's stuffing mode? 3)the mcroblock number of the top_lest is 0 or 1? In the standard ,it's told 1, is right? thank for your help! From ramki emuzed.com Fri May 24 11:01:50 2002 From: ramki emuzed.com (Ramkishor Korada) Date: Wed Jul 30 14:08:05 2003 Subject: [M4IF Technotes] DC prediction References: Message-ID: <01d301c202db$f2a68d50$1b0aa8c0@blr.emuzed.com> Hi, ----- Original Message ----- From: To: Sent: Friday, May 24, 2024 6:28 AM Subject: [M4IF Technotes] DC prediction > 1) is there a code in the bitstream to flag DC prediction? In other > words,in intra DC vlc, the DC of a intra MB are always coded in DC > prediction mode? > There is no flag to indicate DC prediction direction. It is adaptively decided depending on the correlation of DC coefficients in horizontal and vertical direction. > 2)what's use mcroblock's stuffing mode? > To avoid VBV overflow at decoder. > 3)the mcroblock number of the top_lest is 0 or 1? In the standard ,it's > told 1, is right? > It is 0 > thank for your help! > regards, ramkishor Architect - Video Multimedia Technologies Division Emuzed India Bangalore www.emuzed.com From rkoenen intertrust.com Fri May 24 00:38:46 2002 From: rkoenen intertrust.com (Rob Koenen) Date: Wed Jul 30 14:08:05 2003 Subject: [M4IF Technotes] High definition support Message-ID: <3C124172E7FDD511B510000347426D59AF5616@exchange.epr.com> That question is answered here: http://www.m4if.org/resources/profiles/index.html I appreciate that this essay is fairly technical, so the summary is * Advanced COding Efficiency (ACE) supports at least 1920 x 1088 at LEvel 4 * Same for Main Profile at Level 4 Advanced Coding Efficiency is a superset of Advanced Simple, and supports arbitrary shape objects in addition to the tools that make Advanced Simple the Profile of choice for e.g. ISMA (www.isma.tv) MPEG has considered etending Advanced Simple to HD, but has reasoned that by the time that this is done, there will be MPEG-4 part 10 (Advanced Video Coding) / H.264 and the new AS level would compete with the Profiles/Levels in part 10. In other words: there is support now, and more is coming in H.264 / MPEG-4 part 10 AVC. Rob > -----Original Message----- > From: Deepali Arya [mailto:DeepaliA@improvsys.com] > Sent: Thursday, May 23, 2024 10:14 > To: technotes@lists.m4if.org > Subject: [M4IF Technotes] High definition support > > > > Hi all, > > Is there a level and profile of MPEG-4 that can be used for > supporting high > definition resolution ? > > Thanks. > > Deepali Arya > Improv Systems Inc, Beverly. > Email: deepalia@improvsys.com > Tel: (978) 927-0555 x18 > > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes > From rkoenen intertrust.com Fri May 24 01:45:33 2002 From: rkoenen intertrust.com (Rob Koenen) Date: Wed Jul 30 14:08:05 2003 Subject: [M4IF Technotes] MPEG-4 ASIC Video Cores Message-ID: <3C124172E7FDD511B510000347426D59AF561E@exchange.epr.com> Hagai, good to hear from you. Pace Soft Silicon is one company that does IP cores. http://www.pace-softsilicon.com/ Send me a personal mail if you need a contact. If there are others on this list that are in the same area I assume they will speak up. Rob -----Original Message----- From: hagai folkman [mailto:hagai@enquad.com] Sent: Thursday, May 23, 2024 3:07 To: tech notes M4IF Subject: [M4IF Technotes] MPEG-4 ASIC Video Cores Hi, Do you knows where I can find ASIC CoDEC core or DSP ASIC core dedicated to video ? Is anyone working on that ? -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20020524/a28953c8/attachment.html From arcangelo.bruna st.com Fri May 24 11:17:18 2002 From: arcangelo.bruna st.com (arcangelo.bruna@st.com) Date: Wed Jul 30 14:08:05 2003 Subject: [M4IF Technotes] VBV underflow problems Message-ID: Hi. I'm implementing a real time Simple Profile encoder. I have a problem in the VBV implementation. The standard says to use the stuffing bits (bytes) to avoid underflow, but, in this profile, only the stuffing MB are allowable, because the stuffing_start_code can not be used. Unfortunately, for a real time implementation, it is not really a simple thing: in fact, they can not introduced in the next frame because it will be inserted in the VB surely when it is already empty. So we must insert them only in the already encoded frame, so the frame size become bigger. But what happen if the frame size become too bigger so that when the decoder requires it the frame it is not transmitted at all? Another problem: we can not re-encode the frame (due to the real time encoding constraints), so we will insert the stuffing MB at the end of the frame. But what happen if, using the Video Packet, the last video packet become bigger than the profile's constraints (2048 bits for the SP@L1)? All these problems could be avoided allowing the stuffing_start_code in each profiles & levels. Is there a reason why it is not so? Is possible to suggest it to the standardization committee? Thanks, Arcangelo. From r.beattie indigovision.com Fri May 24 11:00:45 2002 From: r.beattie indigovision.com (Robert Beattie) Date: Wed Jul 30 14:08:05 2003 Subject: [M4IF Technotes] MPEG-4 ASIC Video Cores Message-ID: <1F3071585480D5118B8E00B0D0AA311406AFA1@ThisAddressDoesNotExist> You might want to have a look at: http://www.indigovision.com/site/sections/silicon/default.asp Regard's, Dr Rob Beattie Indigo The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on the above detailed phone number and delete the message from your computer: you may not copy or forward this e-mail, or use or disclose its contents to any other person. We thank you in anticipation for your assistance. As internet communications are capable of data corruption no responsibility is accepted for changes made to this message after it was sent. For this reason it may be inappropriate to rely on information contained in this e-mail without obtaining written confirmation of it. In addition, no liability or responsibility is accepted for viruses and it is your responsibility to scan any attachments to this e-mail. Nothing in this e-mail shall constitute or be construed as constituting an offer, obligation or an acceptance of any offer previously made. Opinions, comments and other information in this e-mail that do not relate to the business of IndigoVision Group plc, IndigoVision Limited and/or IndigoVision, Inc. shall be understood as neither given nor endorsed by the companies or any of them. From ramki emuzed.com Fri May 24 17:10:15 2002 From: ramki emuzed.com (Ramkishor Korada) Date: Wed Jul 30 14:08:06 2003 Subject: [M4IF Technotes] VBV underflow problems References: Message-ID: <03c101c2030f$67c06510$1b0aa8c0@blr.emuzed.com> Hi, One solution is do not wait till the underflow actually happens. Predict the buffer underflow ahead and start reacting i.e., start stuffing. regards, ramkishor Architect - Video Multimedia Technologies Division Emuzed India Bangalore www.emuzed.com ----- Original Message ----- From: To: Sent: Friday, May 24, 2024 1:47 PM Subject: [M4IF Technotes] VBV underflow problems > Hi. > I'm implementing a real time Simple Profile encoder. > I have a problem in the VBV implementation. > The standard says to use the stuffing bits (bytes) to avoid underflow, > but, in this profile, only the stuffing MB are allowable, because the > stuffing_start_code can not be used. > > Unfortunately, for a real time implementation, it is not really a > simple thing: in fact, they can not introduced in the next frame > because it will be inserted in the VB surely when it is already empty. > So we must insert them only in the already encoded frame, so the frame > size become bigger. > But what happen if the frame size become too bigger so that when the > decoder requires it the frame it is not transmitted at all? > > Another problem: we can not re-encode the frame (due to the real time > encoding constraints), so we will insert the stuffing MB at the end of > the frame. But what happen if, using the Video Packet, the last video > packet become bigger than the profile's constraints (2048 bits for the > SP@L1)? > > All these problems could be avoided allowing the stuffing_start_code > in each profiles & levels. Is there a reason why it is not so? Is > possible to suggest it to the standardization committee? > > Thanks, > Arcangelo. > > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes > > From luca.celetto st.com Fri May 24 14:54:07 2002 From: luca.celetto st.com (Luca Celetto) Date: Wed Jul 30 14:08:06 2003 Subject: [M4IF Technotes] Video Packet length and Profile-Level constraints Message-ID: <3CEE29DE.48DB55BB@st.com> Table N.1 in MPEG-4 Visual standard lists the maximum size in bits for Video Packets Simple Profile @ Level 1 : 2048 bits Simple Profile @ Level 2 : 4096 bits Simple Profile @ Level 3 : 8192 bits According to pen and paper computation (and some simulations), it is not impossible that at least Level 1 constraint is overcome by a single macroblock when QP is very low. For instance, worst case when all DCT coefficients are ESCAPEd 6: blocks in macroblock 63: AC coefficients 24: bit for worse case ESCAPE sequence total 9072 bits (without adding headers and DC coefficients!). My conclusion is that it is compulsory to check each macroblock length and eventually re-encode it with less bits. This seems to me a big waste of computation, expecially if you have real-time constraints and you need to ensure certain timings. Any suggestion? From tamer.shanableh motorola.com Fri May 24 15:10:59 2002 From: tamer.shanableh motorola.com (Shanableh Tamer-BTS027) Date: Wed Jul 30 14:08:06 2003 Subject: [M4IF Technotes] 'vop_coded' for enhancement layers Message-ID: Hi, I am having a bit of difficulty understanding the 'vop_coded' field for the enhancement layers. In the case of Simple Profile the immediately preceding VOP is copied, provided that its vop_coded=1. But what about the enhancement layer of the Simple Scalable Profile, how do I interpret "preceding VOP"? is it the forward reference VOP? is it the preceding VOP in the same layer? I would appreciate your views and explanations on this, thanks Tamer From samar_y hotmail.com Fri May 24 12:41:11 2002 From: samar_y hotmail.com (samar yassin) Date: Wed Jul 30 14:08:06 2003 Subject: [M4IF Technotes] vop_coded for enhancement layers Message-ID: Hi, I am having a bit of difficulty understanding the 'vop_coded' field for the enhancement layers. In the case of Simple Profile the immediately preceding VOP is copied, provided that its vop_coded=1. But what about the enhancement layer of the Simple Scalable Profile, how do I interpret "preceding VOP"? is it the forward reference VOP? is it the preceding VOP in the same layer? I could appreciate your views and explanations on this, thanks T. Jamal _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From padhu_sn lycos.com Tue May 28 13:32:18 2002 From: padhu_sn lycos.com (Padmanabhan S N) Date: Wed Jul 30 14:08:06 2003 Subject: [M4IF Technotes] MP4 File Format Message-ID: Hi all, I'm currently working on streaming a mpeg4 file. I have some queries regarding the MP4 file format : 1. Is there any document which describes the MP4 file format ? 2. Are there any SDKs available for interpreting MP4 file ? Any information / pointers on ** streaming an mpeg4 file ** would be greatly appreciated. Thanks for your time, Paddu. ________________________________________________________ Outgrown your current e-mail service? Get a 25MB Inbox, POP3 Access, No Ads and No Taglines with LYCOS MAIL PLUS. http://login.mail.lycos.com/brandPage.shtml?pageId=plus From frans inwind.it Tue May 28 15:13:11 2002 From: frans inwind.it (Francesco Falconi) Date: Wed Jul 30 14:08:06 2003 Subject: [M4IF Technotes] Trouble with Bframe: size goes bigger Message-ID: <002f01c20641$09fcab70$49662dd5@francesc0h4ebp> Hello to everyone, I hope someone can find two minutes to answer me. I show you this test: they are only 8 frames to compress, (frame base cosing). My test is about advantage in size compression using more bframe than Pframe. The GOP is 8 frame and i try to change the number of P-B frame (fixing numer of Iframe). So i change the value of Motion.PBetweenICount and Motion.BBetweenPCount These are the results: P= B= GOP Size cmp fps 0 6 I B B B B B B I 15944 0,4097 1 3 I B B B P B B I 14804 1,3095 3 1 I B P B P B P I 14065 2,4133 6 0 I P P P P P P I 14023 2,8229 I cant't understand why adding Bframe the size goes bigger, it could be the opposite (accordin Mpeg Theory). I try to make other test, the same results. Could you explain me the reason? Thank you vaery much, this is for my university thesis. Francesco Falconi -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20020528/4b56c7df/attachment.html From ramki emuzed.com Tue May 28 19:32:27 2002 From: ramki emuzed.com (Ramkishor Korada) Date: Wed Jul 30 14:08:06 2003 Subject: [M4IF Technotes] Trouble with Bframe: size goes bigger References: <002f01c20641$09fcab70$49662dd5@francesc0h4ebp> Message-ID: <03a401c20647$f034c4f0$1b0aa8c0@blr.emuzed.com> Hi, There could be some problem with the rate control. You did not mention the PSNR achieved for different cases. As the details are not sufficient, difficult to analyze this problem. Realizing more compression efficiency by using more number of B frames is dependant on the temporal correlation in the sequence. Increasing the number of B frames does not improve compression efficiency always. regards, ramkishor Architect - Video Multimedia Technologies Division Emuzed India Bangalore www.emuzed.com ----- Original Message ----- From: Francesco Falconi To: technotes@lists.m4if.org Sent: Tuesday, May 28, 2024 5:43 PM Subject: [M4IF Technotes] Trouble with Bframe: size goes bigger Hello to everyone, I hope someone can find two minutes to answer me. I show you this test: they are only 8 frames to compress, (frame base cosing). My test is about advantage in size compression using more bframe than Pframe. The GOP is 8 frame and i try to change the number of P-B frame (fixing numer of Iframe). So i change the value of Motion.PBetweenICount and Motion.BBetweenPCount These are the results: P= B= GOP Size cmp fps 0 6 I B B B B B B I 15944 0,4097 1 3 I B B B P B B I 14804 1,3095 3 1 I B P B P B P I 14065 2,4133 6 0 I P P P P P P I 14023 2,8229 I cant't understand why adding Bframe the size goes bigger, it could be the opposite (accordin Mpeg Theory). I try to make other test, the same results. Could you explain me the reason? Thank you vaery much, this is for my university thesis. Francesco Falconi -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20020528/1a496c0f/attachment.html From julien resonate-mp4.com Tue May 28 16:12:46 2002 From: julien resonate-mp4.com (Julien Boeuf) Date: Wed Jul 30 14:08:07 2003 Subject: [M4IF Technotes] MP4 File Format References: Message-ID: <010701c20649$5c494480$0300a8c0@herreweghe> Hi, You can find an open source project providing a reading/writing as well as hinting API for MP4 files on http://www.sourceforge.net/projects/mpeg4ip it's really good. For the doc, the document specifying the MP4 file format is MPEG-4 system ISO/IEC 14496-1, chapter 13: it's really close to the QuickTime file format specification you can download freely on the web. The doc explaining how to stream an MP4 file and the hint track specification is the ISMA 1.0 specs http://www.isma.tv. Once again, it's really close to the QuickTime Streaming specs. King regards, Julien. ----- Original Message ----- From: "Padmanabhan S N" To: Sent: Tuesday, May 28, 2024 9:02 AM Subject: [M4IF Technotes] MP4 File Format | Hi all, | | I'm currently working on streaming a mpeg4 file. I have some queries regarding the MP4 file format : | | 1. Is there any document which describes the MP4 file format ? | | 2. Are there any SDKs available for interpreting MP4 file ? | | Any information / pointers on ** streaming an mpeg4 file ** would be greatly appreciated. | | Thanks for your time, | Paddu. | | | ________________________________________________________ | Outgrown your current e-mail service? | Get a 25MB Inbox, POP3 Access, No Ads and No Taglines with LYCOS MAIL PLUS. | http://login.mail.lycos.com/brandPage.shtml?pageId=plus | _______________________________________________ | Technotes mailing list | Technotes@lists.m4if.org | http://lists.m4if.org/mailman/listinfo/technotes From piccarre mail2.elet.polimi.it Tue May 28 16:14:39 2002 From: piccarre mail2.elet.polimi.it (Luca Piccarreta) Date: Wed Jul 30 14:08:07 2003 Subject: [M4IF Technotes] Trouble with Bframe: size goes bigger References: <002f01c20641$09fcab70$49662dd5@francesc0h4ebp> Message-ID: <002b01c20649$9f99ef00$4b7baf83@piccarreta> The question is a little bit ill-posed. May be you're using less bit, but the quality is better. And what's the measure for quality? MAD, PSNR subjective tests? In my experience, B frames don't give any improvement in coding efficiency (read: MAD at same bitrate). It may be was true for MPEG2, but new tools, like 4MV and OBMC, have improved the quality of P compressed frames. Moreover, one should never use more than 2 or 3 consecutive B, as the motion estimation algorithms could easily fail. And even if they don't fail, very large motion vectors consume bits. One could argue that in Direct MBs (MPEG4 tool) the coding efficiency is very high... On the other side, BVOPs are useful to minimize mismatches between different decoders (too many consecutive PVOPs can easily cause visible differencies between different implementations) and make random access faster. I would appreciate other opinions, though. Luca Piccarreta. ----- Original Message ----- From: Francesco Falconi To: technotes@lists.m4if.org Sent: Tuesday, May 28, 2024 2:13 PM Subject: [M4IF Technotes] Trouble with Bframe: size goes bigger Hello to everyone, I hope someone can find two minutes to answer me. I show you this test: they are only 8 frames to compress, (frame base cosing). My test is about advantage in size compression using more bframe than Pframe. The GOP is 8 frame and i try to change the number of P-B frame (fixing numer of Iframe). So i change the value of Motion.PBetweenICount and Motion.BBetweenPCount These are the results: P= B= GOP Size cmp fps 0 6 I B B B B B B I 15944 0,4097 1 3 I B B B P B B I 14804 1,3095 3 1 I B P B P B P I 14065 2,4133 6 0 I P P P P P P I 14023 2,8229 I cant't understand why adding Bframe the size goes bigger, it could be the opposite (accordin Mpeg Theory). I try to make other test, the same results. Could you explain me the reason? Thank you vaery much, this is for my university thesis. Francesco Falconi -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20020528/b7c47fbd/attachment.html From gchandra tataelxsi.co.in Tue May 28 20:16:43 2002 From: gchandra tataelxsi.co.in (Chandra Sekhar Reddy G) Date: Wed Jul 30 14:08:07 2003 Subject: [M4IF Technotes] MP4 File Format References: <010701c20649$5c494480$0300a8c0@herreweghe> Message-ID: <011401c2064e$1c2f68c0$cc28010a@gchandra> hi, MP4 file format is given inside the following MPEG-4-Systems doc: http://mpeg.telecomitalialab.com/working_documents/mpeg-04/systems/3rd_editi on_wd.zip regards, chandra > Hi, > > You can find an open source project providing a reading/writing as well > as hinting API for MP4 files on http://www.sourceforge.net/projects/mpeg4ip > it's really good. > For the doc, the document specifying the MP4 file format is MPEG-4 > system ISO/IEC 14496-1, chapter 13: it's really close to the QuickTime file > format specification you can download freely on the web. The doc explaining > how to stream an MP4 file and the hint track specification is the ISMA 1.0 > specs http://www.isma.tv. Once again, it's really close to the QuickTime > Streaming specs. > > King regards, > > Julien. > > ----- Original Message ----- > From: "Padmanabhan S N" > To: > Sent: Tuesday, May 28, 2024 9:02 AM > Subject: [M4IF Technotes] MP4 File Format > > > | Hi all, > | > | I'm currently working on streaming a mpeg4 file. I have some queries > regarding the MP4 file format : > | > | 1. Is there any document which describes the MP4 file format ? > | > | 2. Are there any SDKs available for interpreting MP4 file ? > | > | Any information / pointers on ** streaming an mpeg4 file ** would be > greatly appreciated. > | > | Thanks for your time, > | Paddu. From kenny.chen intel.com Tue May 28 23:09:29 2002 From: kenny.chen intel.com (Chen, Kenny) Date: Wed Jul 30 14:08:07 2003 Subject: [M4IF Technotes] Trouble with Bframe: size goes bigger Message-ID: <957BD1C2BF3CD411B6C500A0C944CA260140441A@pdsmsx32.pd.intel.com> I think if you've used a lot of B-frames in between I/P frames, the size of cmp will increase in most cases. Because the compression rate mostly depends on the efficiency of motion estimation. If the reference frame is several frames away from current frame, the compression rate decreases in most cases. -----Original Message----- From: Francesco Falconi [mailto:frans@inwind.it] Sent: 2002?5?28? 20:13 To: technotes@lists.m4if.org Subject: [M4IF Technotes] Trouble with Bframe: size goes bigger Hello to everyone, I hope someone can find two minutes to answer me. I show you this test: they are only 8 frames to compress, (frame base cosing). My test is about advantage in size compression using more bframe than Pframe. The GOP is 8 frame and i try to change the number of P-B frame (fixing numer of Iframe). So i change the value of Motion.PBetweenICount and Motion.BBetweenPCount These are the results: P= B= GOP Size cmp fps 0 6 I B B B B B B I 15944 0,4097 1 3 I B B B P B B I 14804 1,3095 3 1 I B P B P B P I 14065 2,4133 6 0 I P P P P P P I 14023 2,8229 I cant't understand why adding Bframe the size goes bigger, it could be the opposite (accordin Mpeg Theory). I try to make other test, the same results. Could you explain me the reason? Thank you vaery much, this is for my university thesis. Francesco Falconi -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20020528/9a537d6f/attachment.html From singer apple.com Tue May 28 10:47:49 2002 From: singer apple.com (Dave Singer) Date: Wed Jul 30 14:08:07 2003 Subject: [M4IF Technotes] MP4 File Format In-Reply-To: <010701c20649$5c494480$0300a8c0@herreweghe> References: <010701c20649$5c494480$0300a8c0@herreweghe> Message-ID: At 15:12 +0200 5/28/02, Julien Boeuf wrote: >Hi, > > You can find an open source project providing a reading/writing as well >as hinting API for MP4 files on http://www.sourceforge.net/projects/mpeg4ip >it's really good. > For the doc, the document specifying the MP4 file format is MPEG-4 >system ISO/IEC 14496-1, chapter 13: it's really close to the QuickTime file >format specification you can download freely on the web. The doc explaining >how to stream an MP4 file and the hint track specification is the ISMA 1.0 >specs http://www.isma.tv. Once again, it's really close to the QuickTime >Streaming specs. > >King regards, > > Julien. > >----- Original Message ----- >From: "Padmanabhan S N" >To: >Sent: Tuesday, May 28, 2024 9:02 AM >Subject: [M4IF Technotes] MP4 File Format > > >| Hi all, >| >| I'm currently working on streaming a mpeg4 file. I have some queries >regarding the MP4 file format : >| >| 1. Is there any document which describes the MP4 file format ? >| >| 2. Are there any SDKs available for interpreting MP4 file ? There is reference software available to MPEG members, yes. >| >| Any information / pointers on ** streaming an mpeg4 file ** would be >greatly appreciated. Have a look at the hint track format specified for QuickTime; we are following a similar approach in MP4. >| >| Thanks for your time, >| Paddu. >| >| >| ________________________________________________________ >| Outgrown your current e-mail service? >| Get a 25MB Inbox, POP3 Access, No Ads and No Taglines with LYCOS MAIL >PLUS. >| http://login.mail.lycos.com/brandPage.shtml?pageId=plus >| _______________________________________________ >| Technotes mailing list >| Technotes@lists.m4if.org >| http://lists.m4if.org/mailman/listinfo/technotes > >_______________________________________________ >Technotes mailing list >Technotes@lists.m4if.org >http://lists.m4if.org/mailman/listinfo/technotes -- David Singer Apple Computer/QuickTime From gnitin noida.hcltech.com Wed May 29 17:36:07 2002 From: gnitin noida.hcltech.com (Nitin Gupta--DSP, Noida) Date: Wed Jul 30 14:08:08 2003 Subject: [M4IF Technotes] Latest Mpeg4 Video Source code Message-ID: Hi all, Plz let me know where i can find the latest source codes for Mpeg4 video encoder & decoder of both ISO & Microsoft. That would be of grt help. Thanx & Regards, Nitin Gupta. From kenny.chen intel.com Wed May 29 22:07:58 2002 From: kenny.chen intel.com (Chen, Kenny) Date: Wed Jul 30 14:08:08 2003 Subject: [M4IF Technotes] Question on error resilience for wireless chann el Message-ID: <957BD1C2BF3CD411B6C500A0C944CA26014046D9@pdsmsx32.pd.intel.com> Hi, There are many methods in the MPEG4 standard for error resilience, but is there any reference that for a specific channel, say the wireless one, which group of methods should be used? Rgds, Ken From ramki emuzed.com Wed May 29 20:10:50 2002 From: ramki emuzed.com (Ramkishor Korada) Date: Wed Jul 30 14:08:08 2003 Subject: [M4IF Technotes] Question on error resilience for wireless channel References: <957BD1C2BF3CD411B6C500A0C944CA26014046D9@pdsmsx32.pd.intel.com> Message-ID: <03ea01c20716$76718020$1b0aa8c0@blr.emuzed.com> Hi, Data partitioning, RVLC, Resync marker enable, HEC, adaptive Intra refresh are useful for wireless channels. On top of these methods, some more innovative algos can be implemented to improve the resilience further. regards, ramkishor Architect - Video Multimedia Technologies Division Emuzed India Bangalore www.emuzed.com ----- Original Message ----- From: "Chen, Kenny" To: Sent: Wednesday, May 29, 2024 6:37 PM Subject: [M4IF Technotes] Question on error resilience for wireless channel > Hi, > > There are many methods in the MPEG4 standard for error resilience, but is > there any reference that for a specific channel, say the wireless one, which > group of methods should be used? > > Rgds, > Ken > _______________________________________________ > Technotes mailing list > Technotes@lists.m4if.org > http://lists.m4if.org/mailman/listinfo/technotes > > From frans inwind.it Thu May 30 16:55:24 2002 From: frans inwind.it (Francesco Falconi) Date: Wed Jul 30 14:08:08 2003 Subject: [M4IF Technotes] ISO Encoder: Cutting off yuv preview. Message-ID: <003201c207e1$a74099e0$49662dd5@francesc0h4ebp> Hello to everyone, I'd like to know if you know if there is the possibility to cut off the preview of the .yuv files created during encoding (this prewview is generated decoding cmp file, with loss of useless time). In other words to obtain only .cmp files. I hope there is a quicker solution then looking to all source code and delete all part of reconstructed yuv. Thank you, with regards, Francesco Falconi -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20020530/07dde9f9/attachment.html From neff PacketVideo.COM Thu May 30 12:55:08 2002 From: neff PacketVideo.COM (Ralph Neff) Date: Wed Jul 30 14:08:08 2003 Subject: [M4IF Technotes] MPEG-4 Audio Message-ID: <72263E8E8622D611975C0002B32C19D837E931@misty.packetvideo.com> Hi Arcin, MPEG-4 doesn't currently include AMR in any of its specifications. If you're coming from the MPEG-4 world and you want to stream speech, you'd use MPEG-4 CELP. (This is what you'd find if you picked up the ISMA spec, for example). If you're interested in streaming AMR along with MPEG-4 visual, for example, you should take a look at the 3GPP Packet-Switched Streaming specification. This describes audio/visual streaming over wireless (e.g. UMTS) connections. 3GPP has for example defined extensions to allow AMR and H.263 tracks to be included in an MP4 file. The streaming itself is based on the various IETF payload formats (so AMR isn't "in an MPEG-4 stream" as you posed in your question). -Ralph -----Original Message----- From: Arcin Bozkurt [mailto:arcin@atsana.com] Sent: Thursday, May 30, 2024 10:59 AM To: technotes@lists.m4if.org Subject: [M4IF Technotes] MPEG-4 Audio Can GSM-AMR be transmitted in an MPEG-4 stream? Does have to be MPEG-4 Celp that has to be transmitted? -arcin _______________________________________________ Technotes mailing list Technotes@lists.m4if.org http://lists.m4if.org/mailman/listinfo/technotes From gnitin noida.hcltech.com Fri May 31 11:50:20 2002 From: gnitin noida.hcltech.com (Nitin Gupta--DSP, Noida) Date: Wed Jul 30 14:08:08 2003 Subject: [M4IF Technotes] Short Video header code in Microsoft Decoder Message-ID: Hi all, I have the source code of Microsoft Mpeg4 decoder. I used it to decode the conformance streams provided by ISO. But while decoding the short header streams, namely mit022.m4v & mit024.m4v, the MS decoder just exits out flagging some error. The version that i am using is Microsoft FPDAM1-1.0-000403. Is there any bug or something else ? Thanx & Regards, Nitin Gupta. From jwalant.desai wipro.com Fri May 31 13:04:17 2002 From: jwalant.desai wipro.com (Jwalant Sumantrai Desai) Date: Wed Jul 30 14:08:08 2003 Subject: [M4IF Technotes] Short Video header code in Microsoft Decoder In-Reply-To: Message-ID: <001e01c2086d$30795270$cfeca8c0@wipro.com> Hi, The Microsoft decoder (July 3rd 2000 version 2 FDAM1-2.3-001213) fails on the following streams: 1. short\hit035.m4v 2. short\mit021.m4v 3. short\mit022.m4v 4. short\mit023.m4v 5. short\mit024.m4v However my decoder was able to decode these streams successfully and the subjective video quality also looks fine. Rgds Jwalant -----Original Message----- From: technotes-admin@lists.m4if.org [mailto:technotes-admin@lists.m4if.org] On Behalf Of Nitin Gupta--DSP, Noida Sent: Friday, May 31, 2024 10:50 AM To: technotes@lists.m4if.org Subject: [M4IF Technotes] Short Video header code in Microsoft Decoder Hi all, I have the source code of Microsoft Mpeg4 decoder. I used it to decode the conformance streams provided by ISO. But while decoding the short header streams, namely mit022.m4v & mit024.m4v, the MS decoder just exits out flagging some error. The version that i am using is Microsoft FPDAM1-1.0-000403. Is there any bug or something else ? Thanx & Regards, Nitin Gupta. _______________________________________________ Technotes mailing list Technotes@lists.m4if.org http://lists.m4if.org/mailman/listinfo/technotes -------------- next part -------------- **************************Disclaimer************************************************** Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. **************************************************************************************** From ykgupta noida.hcltech.com Fri May 31 18:57:38 2002 From: ykgupta noida.hcltech.com (Yogendra Kumar Gupta, Noida) Date: Wed Jul 30 14:08:08 2003 Subject: [M4IF Technotes] QUERRY ON MPEG4 IMPLEMENTATION Message-ID: Hi all, I have a querry on implementation of simple profile mpeg4 encoder and decoder. 1. If I have to encode a frame whose height and widths are not multiples of 16 do I need to pad these frames to make the width and height multiples of 16. Do I need to pad only by extending the image or can I also use mirroring for padding. 2. My other question is regarding the reconstruction of the reconstructed frame. Does the reconstructed frame need to be of the size of the original image width and height or a multiple of the width and the height. Also in this case should I actually extend the last row and the column as per the original width and height of the image or can I use the data from the remaining rows or columns which I get after doing the Inverse DCT instead of padding (I would get a multiple of 8) Regards Yogender Kumar Gupta