From jmaneng2002 yahoo.com Wed May 2 23:49:29 2007 From: jmaneng2002 yahoo.com (jaafar mansoory) Date: Thu May 3 07:34:07 2007 Subject: [Mp4-tech] Question about H.264 Message-ID: <651831.35740.qm@web50303.mail.re2.yahoo.com> Dear All, I am a student of M.Sc in communication engineering. My project is video watermarking. I want to get DCT coefficients, motion vector and other information in a frame from the H.264 codec. The reference software is jm 12.2 ( http://iphome.hhi.de/suehring/tml/index.htm) . But I don?t know how can get those. I use C++ (6.0) and the operating system is Windows. I was wondering if you would mind helping me. With many thanks. Best regards, Jaafar Mansoory --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070502/0a9ba120/attachment.html From Vikas.Nayak lntinfotech.com Fri May 4 12:10:04 2007 From: Vikas.Nayak lntinfotech.com (Vikas Nayak) Date: Fri May 4 08:28:09 2007 Subject: [Mp4-tech] Aac or mp4 Files with channel coupling Message-ID: Greetings Everyone.. Is there a link which has files with channel coupling element (independent or dependent) or Is there any encoder which supports channel coupling so that i can generate them myself? Any help would be highly appreciated. Cheers Vikas ______________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070504/b2ca9f63/attachment.html From pchirag gmail.com Mon May 7 12:49:43 2007 From: pchirag gmail.com (Chirag Pujara) Date: Mon May 7 13:04:07 2007 Subject: [Mp4-tech] Gop definition in H.264 Message-ID: <6cb7f2550705062319o1872027fu16cfbf78728dc476@mail.gmail.com> Hello Experts, I am using JM11.0 reference code to encode yuv data to h264 encoded. If i would like to know whether the Intra period in the H264 encoder spec is the same as the GOP in Mpeg2 or it has some other meaning? For eg. If is spcify Intra period as 4 and if i dont enable the B frames the encoding order is " IPPPI' which is fine but if I specify one B frame then the encoding order is coming like " IBPBPBPBI". In this case the distance between consecutive I frames is now 8 instead of the specified value 4. I would like to know whether they consider B frames also while calculating the I frame distance or just P frames are only being considered. ---- Thanks and Regards Chirag Pujara -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070507/ddd7d756/attachment.html From r94942112 ntu.edu.tw Mon May 7 22:54:32 2007 From: r94942112 ntu.edu.tw (Yu-Wen Chen) Date: Mon May 7 13:04:13 2007 Subject: [Mp4-tech]Data Partition in JM Message-ID: <20070507215432.5y6y023o08wgkw8s@wmail1.cc.ntu.edu.tw> Dear all, I have a question about data partitioning in JM software: In JM software, there are three partitions if you enables data partitioning. And I use a variable "nalu->len" to find each partition size. I find that only one nal unit for I frame and two nal units for P frame. Based on the definition of DP, The decoder can decode part of a frame if it only received one or two of three partitions. Now there are two nal units in the P frame. The first case I met is that the decoder will discard this frame data if it only receives second unit. And the second case is that the decoder will meet error if only the first nal unit is received. So how to solve above problem I met and how to utilize data partition to improve video quality with loss rate in a correct way? Thx Best regards, Yu-Wen Chen From sriabtsev broadcom.com Mon May 7 09:07:47 2007 From: sriabtsev broadcom.com (Shevach Riabtsev) Date: Mon May 7 13:04:18 2007 Subject: [Mp4-tech] Ex-Golomb words longer than 32 bits Message-ID: <9110732D7E34E5459A92F96AEEDF829E01D84087@NT-SJCA-0751.brcm.ad.broadcom.com> Hi Daljit Could you elaborate under what circumstances Exp-Golomb codes in H.264 would exceed 32 bits. The only syntax element I have observed that gets a "huge" value is mb_skip_run in a HD resolution picture, say 8159. In this case, mb_skip_run Exp-Golomb code length is 25 bits. Regards, Shevach -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070507/1118b658/attachment.html From garysull windows.microsoft.com Mon May 7 11:24:55 2007 From: garysull windows.microsoft.com (Gary Sullivan) Date: Mon May 7 13:34:08 2007 Subject: [Mp4-tech] Ex-Golomb words longer than 32 bits In-Reply-To: <9110732D7E34E5459A92F96AEEDF829E01D84087@NT-SJCA-0751.brcm.ad.broadcom.com> References: <9110732D7E34E5459A92F96AEEDF829E01D84087@NT-SJCA-0751.brcm.ad.broadcom.com> Message-ID: <03CB47D9C3F8074498E4653F814D6E8F049F9072@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> Shevach Riabtsev et al, I suggest looking at some SEI messages and perhaps VUI syntax. In fact, there are reportedly a few cases in which the code can exceed 64 bits (pan_scan_rect_id, scene_id, snapshot_id, progressive_refinement_id etc, which have a stated range of 0 to 2^32 - 1). I believe we will fix those few cases in a future corrigendum (by limiting them to a range from 0 to 2^32 - 2 and thus limiting them to 64 bits in length). Best Regards, Gary Sullivan ________________________________ From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Shevach Riabtsev Sent: Monday, May 07, 2024 8:08 AM To: mp4-tech@lists.mpegif.org Subject: [Mp4-tech] Ex-Golomb words longer than 32 bits Hi Daljit Could you elaborate under what circumstances Exp-Golomb codes in H.264 would exceed 32 bits. The only syntax element I have observed that gets a "huge" value is mb_skip_run in a HD resolution picture, say 8159. In this case, mb_skip_run Exp-Golomb code length is 25 bits. Regards, Shevach -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070507/30cdca1f/attachment.html From garysull windows.microsoft.com Mon May 7 11:29:51 2007 From: garysull windows.microsoft.com (Gary Sullivan) Date: Mon May 7 13:40:06 2007 Subject: [Mp4-tech] Gop definition in H.264 In-Reply-To: <6cb7f2550705062319o1872027fu16cfbf78728dc476@mail.gmail.com> References: <6cb7f2550705062319o1872027fu16cfbf78728dc476@mail.gmail.com> Message-ID: <03CB47D9C3F8074498E4653F814D6E8F049F9081@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> Chirag Pujara et al, I suggest getting a copy of the JM reference software manual, the latest version of which can be found in JVT-W041. If you do not find the answer you seek in that document, let us know and we will take action to clarify it in the next version. Best Regards, Gary Sullivan ________________________________ From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Chirag Pujara Sent: Sunday, May 06, 2024 11:20 PM To: mp4-tech@lists.mpegif.org Subject: [Mp4-tech] Gop definition in H.264 Hello Experts, I am using JM11.0 reference code to encode yuv data to h264 encoded. If i would like to know whether the Intra period in the H264 encoder spec is the same as the GOP in Mpeg2 or it has some other meaning? For eg. If is spcify Intra period as 4 and if i dont enable the B frames the encoding order is " IPPPI' which is fine but if I specify one B frame then the encoding order is coming like " IBPBPBPBI". In this case the distance between consecutive I frames is now 8 instead of the specified value 4. I would like to know whether they consider B frames also while calculating the I frame distance or just P frames are only being considered. ---- Thanks and Regards Chirag Pujara -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070507/87c43f91/attachment.html From alexis.tourapis dolby.com Mon May 7 11:40:17 2007 From: alexis.tourapis dolby.com (Tourapis, Alexis) Date: Mon May 7 13:52:13 2007 Subject: [Mp4-tech] Ex-Golomb words longer than 32 bits In-Reply-To: <9110732D7E34E5459A92F96AEEDF829E01D84087@NT-SJCA-0751.brcm.ad.broadcom.com> References: <9110732D7E34E5459A92F96AEEDF829E01D84087@NT-SJCA-0751.brcm.ad.broadcom.com> Message-ID: <2BAAC5E4AF2518459F0AB5D927942047520391@bur-exch-01.dolby.net> Several of the HRD and VUI parameters may require 32 bits. Check Annexes D and E. Best regards, Alexis ________________________________ From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Shevach Riabtsev Sent: Monday, May 07, 2024 8:08 AM To: mp4-tech@lists.mpegif.org Subject: [Mp4-tech] Ex-Golomb words longer than 32 bits Hi Daljit Could you elaborate under what circumstances Exp-Golomb codes in H.264 would exceed 32 bits. The only syntax element I have observed that gets a "huge" value is mb_skip_run in a HD resolution picture, say 8159. In this case, mb_skip_run Exp-Golomb code length is 25 bits. Regards, Shevach ----------------------------------------- This message (including any attachments) may contain confidential information intended for a specific individual and purpose. If you are not the intended recipient, delete this message. If you are not the intended recipient, disclosing, copying, distributing, or taking any action based on this message is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070507/dc829717/attachment-0001.html From Veenit.Vora patni.com Tue May 8 10:40:06 2007 From: Veenit.Vora patni.com (Vora, Veenit) Date: Tue May 8 03:52:09 2007 Subject: [Mp4-tech] [MPEG-4 Audio] Error Concelament in MPEG-4 HEAAC Profile Message-ID: <87B7092E3762F8488DE6C3FEA50E0E3E730463@EXCHSPZ01.patni.com> Hello Everyone, I am working on the HEAAC profile (AAC-LC + SBR) of the MPEG-4 standard. I had the following queries regarding Error Concelament of an encoded bitstream which is obtained by applying the above-mentioned AOTs to the audio stream: 1. Is Error Concealment possible for this profile? 2. If Error Concelament is possible for this profile, is the procedure/algorithm for Error Concealment standardised by MPEG-4 (where can one find the standardised procedure for Error Concelament in the MPEG-4 standard or are there any other documents that give the proedure/algorithm for this profile)? 3. Are there test streams available to test the Error Concelament tool (for the HEAAC profile) and what would be its conformance criteria? Thanking everyone in advance. Awaiting an early reply. Regards, Veenit Vora. Patni Computer Systems Ltd., Unit No. 19, SDF 7, SEEPZ, Andheri (E), Mumbai - 400096. Tel: +91-22-28291454. Ext: 5806 http://www.patni.com World-Wide Partnerships. World-Class Solutions. _____________________________________________________________________ This e-mail message may contain proprietary, confidential or legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify us immediately at netadmin@patni.com and delete this mail. _____________________________________________________________________ From ssingh179 gmail.com Tue May 8 17:15:07 2007 From: ssingh179 gmail.com (Shailendra Singh) Date: Tue May 8 10:46:07 2007 Subject: [Mp4-tech] Clock rate used for RTP timestamps Message-ID: Hi All, For H.264 and H.263, the corresponding RFCs mandate that a clock rate (for RTP timestamping) of 90 kHz MUST be used. For MPEG-4, RFC 3016 (RTP Payload Format for MPEG-4 Audio/Visual Streams) says that the resolution of the RTP timestamp "is set to its default value of 90kHz, unless specified by an out-of-band means", i.e. a clock rate which is not 90 kHz is allowed if explicitly specified, for example, in a Session Description sent out with the "rate" parameter in the "a=rtpmap" line appropriately set. My questions are: (1) What is the need to allow a non 90 kHz clock rate for MPEG-4 when the other coding systems restrict it to 90 kHz? (2) RFC 3016 does not say anything explicitly, but is there an implied restriction on the range in which the clock rate should lie for MPEG-4? Any pointers will be appreciated. Thanks, Shailendra -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070508/e486eb32/attachment.html From Sachin.Kanade lntinfotech.com Tue May 8 18:39:30 2007 From: Sachin.Kanade lntinfotech.com (Sachin Kanade) Date: Tue May 8 10:46:14 2007 Subject: [Mp4-tech] Regarding FlexMux Message-ID: Hi everybody, Through the MPEG-4 knowledge base reading, I came to following queryes. 1) Is it any advantage of FlexMux other than to reduce the number of network connection? 2) If RTP is used as a TransMux instance, -- how will it be determined whether the payload has flexmux or not? -- If flexmux is not applicable to ES , will there be multiple RTP ports? Thanx in advance Regards Sachin Kanade ------------------------------------------------------------------------------------------ Never let the light of Hope diminishing. Everything is possible. ------------------------------------------------------------------------------------------ The information contained in this mail is classified as ( ) L&T Infotech Proprietary ( ) L&T Infotech Confidential (x) L&T Infotech Internal Use ( ) L&T Infotech General Business ______________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070508/a8252f2b/attachment.html From ssingh179 gmail.com Tue May 8 20:26:21 2007 From: ssingh179 gmail.com (Shailendra Singh) Date: Tue May 8 10:46:18 2007 Subject: [Mp4-tech] Clock rate used for RTP timestamps Message-ID: Hi All, For H.264 and H.263, the corresponding RFCs mandate that a clock rate (for RTP timestamping) of 90 kHz MUST be used. For MPEG-4, RFC 3016 (RTP Payload Format for MPEG-4 Audio/Visual Streams) says that the resolution of the RTP timestamp "is set to its default value of 90kHz, unless specified by an out-of-band means", i.e. a clock rate which is not 90 kHz is allowed if explicitly specified, for example, in a Session Description sent out with the "rate" parameter in the "a=rtpmap" line appropriately set. My questions are: (1) What is the need to allow a non 90 kHz clock rate for MPEG-4 when the other coding systems restrict it to 90 kHz? (2) RFC 3016 does not say anything explicitly, but is there an implied restriction on the range in which the clock rate should lie for MPEG-4? Any pointers will be appreciated. Thanks, Shailendra -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070508/21b6ba20/attachment.html From ratnesh.katiyar gmail.com Tue May 8 22:13:05 2007 From: ratnesh.katiyar gmail.com (Ratnesh Katiyar) Date: Wed May 9 01:52:16 2007 Subject: [Mp4-tech] Clock rate used for RTP timestamps In-Reply-To: References: Message-ID: Hi all, i m havng d mp4 parser filter code which is workng for aac audio format but while giving amr audio in mp4 this code is not workng .. could u plz help me out from this or let me now what changes i hav 2 do in my parser code. regards ratnesh On 5/8/07, Shailendra Singh wrote: > Hi All, > For H.264 and H.263, the corresponding RFCs mandate that a clock rate > (for RTP timestamping) of 90 kHz MUST be used. > For MPEG-4, RFC 3016 (RTP Payload Format for MPEG-4 Audio/Visual > Streams) says that the resolution of the RTP timestamp "is set to its > default value of 90kHz, unless specified by an out-of-band means", i.e. a > clock rate which is not 90 kHz is allowed if explicitly specified, for > example, in a Session Description sent out with the "rate" parameter in the > "a=rtpmap" line appropriately set. > > My questions are: > (1) What is the need to allow a non 90 kHz clock rate for MPEG-4 when the > other coding systems restrict it to 90 kHz? > (2) RFC 3016 does not say anything explicitly, but is there an implied > restriction on the range in which the clock rate should lie for MPEG-4? > > > Any pointers will be appreciated. > > Thanks, > Shailendra > _______________________________________________ > NOTE: Please use clear subject lines for your posts. Include [audio, > [video], [systems], [general] or another apppropriate identifier to indicate > the type of question you have. > > Note: Conduct on the mailing list is subject to the Antitrust guidelines > found at > http://www.mpegif.org/public/documents/vault/mp-out-30042-Antitrust.php > From Manish.Jalan patni.com Wed May 9 13:18:05 2007 From: Manish.Jalan patni.com (Jalan, Manish) Date: Wed May 9 09:46:07 2007 Subject: [Mp4-tech] Clock rate used for RTP timestamps In-Reply-To: Message-ID: <87B7092E3762F8488DE6C3FEA50E0E3E790197@EXCHSPZ01.patni.com> Hi Shailendra, No direct answers. Some personal thoughts. For first part of your query: Why to allow non 90 KHz clock? AFAIK, H.264 and H.263 are video only standards. Hence if their corresponding RTP payload format RFCs mandate a 90 KHz clock rate, makes sense. Coming to MPEG-4, it's not a video-only standard. If I know it right, it can be audio only, video only or audio video both. 90 KHz clock is justified / suggested for video. When audio is present, a different clock might be suitable that will ensure audio / video sync. For answering second part of your query, following might be useful. Quoting from RFC 1890, "...All current video encodings use a timestamp frequency of 90,000 Hz, the same as the MPEG presentation time stamp frequency. This frequency yields exact integer timestamp increments for the typical 24 (HDTV), 25 (PAL), and 29.97 (NTSC) and 30 Hz (HDTV) frame rates and 50, 59.94 and 60 Hz field rates. While 90 kHz is the recommended rate for future video encodings used within this profile, other rates are possible. However, it is not sufficient to use the video frame rate (typically between 15 and 30 Hz) because that does not provide adequate resolution for typical synchronization requirements when calculating the RTP timestamp corresponding to the NTP timestamp in an RTCP SR packet [15]. The timestamp resolution must also be sufficient for the jitter estimate contained in the receiver reports." Quoting from RFC 1889, "RTP timestamp: 32 bits Corresponds to the same time as the NTP timestamp (above), but in the same units and with the same random offset as the RTP timestamps in data packets. This correspondence may be used for intra- and inter-media synchronization for sources whose NTP timestamps are synchronized, and may be used by media-independent receivers to estimate the nominal RTP clock frequency. Note that in most cases this timestamp will not be equal to the RTP timestamp in any adjacent data packet. Rather, it is calculated from the corresponding NTP timestamp using the relationship between the RTP timestamp counter and real time as maintained by periodically checking the wallclock time at a sampling instant." Quotes from 'http://www.cs.columbia.edu/~hgs/rtp/faq.html' "In a multimedia conference, are the initial timestamp values related? No, initial time stamp values are picked randomly and independently for each RTP stream. (This is more or less unavoidable if different media types are generated by independent applications, whether these applications reside on the same host or not.) Synchronization (such as lip sync) between different media is performed by receivers through the NTP timestamps in the RTCP sender reports. This timestamp provides a common time reference that associates a media-specific RTP timestamp with the common "wallclock" time shared across media. The mechanism how end systems synchronize different media is not prescribed by RTP, however, a workable approach is to periodically exchange messages between applications to indicate what delay each application would impose on the stream (including any media decoding delays) if it were not to synchronize and then have all applications choose the maximum of these delays. What are the roles of the RTP timestamp and sequence numbers? The timestamp is used to place the incoming audio and video packets in the correct timing order (playout delay compensation). The sequence number is mainly used to detect losses. Sequence numbers increase by one for each RTP packet transmitted, timestamps increase by the time "covered" by a packet. For video formats where a video frame is split across several RTP packets, several packets may have the same timestamp. In some cases such as carrying DTMF (touch tone) data (RFC 2833), RTP timestamps may not be monotonic. What are the different clocks and how are they synchronized? RFC 1889 specifies one media-timestamp in the RTP data header and a mapping between such timestamp and a globally synchronized clock, carried as RTCP timestamp mappings. The NTP timestamps in the SR are assumed to be synchronized between all media senders within a single session. If the media sources come from the same network source, this is obviously not an issue. Receiver(s) synchronize to the sender, the only solution feasible for multicast. Experience has shown that all other cross-media, cross-host schemes end up doing clock synchronization, usually inferior to NTP and application-specific." Hope this helps. Regards, -Manish S. Jalan ________________________________ From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Shailendra Singh Sent: Tuesday, May 08, 2024 4:15 PM To: mp4-tech@lists.mpegif.org Subject: [Mp4-tech] Clock rate used for RTP timestamps Hi All, For H.264 and H.263, the corresponding RFCs mandate that a clock rate (for RTP timestamping) of 90 kHz MUST be used. For MPEG-4, RFC 3016 (RTP Payload Format for MPEG-4 Audio/Visual Streams) says that the resolution of the RTP timestamp "is set to its default value of 90kHz, unless specified by an out-of-band means", i.e. a clock rate which is not 90 kHz is allowed if explicitly specified, for example, in a Session Description sent out with the "rate" parameter in the "a=rtpmap" line appropriately set. My questions are: (1) What is the need to allow a non 90 kHz clock rate for MPEG-4 when the other coding systems restrict it to 90 kHz? (2) RFC 3016 does not say anything explicitly, but is there an implied restriction on the range in which the clock rate should lie for MPEG-4? Any pointers will be appreciated. Thanks, Shailendra http://www.patni.com World-Wide Partnerships. World-Class Solutions. _____________________________________________________________________ This e-mail message may contain proprietary, confidential or legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify us immediately at netadmin@patni.com and delete this mail. _____________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070509/960ae338/attachment-0001.html From mayank_2001 hotmail.com Wed May 9 15:25:35 2007 From: mayank_2001 hotmail.com (Mayank Agarwal) Date: Wed May 9 09:46:12 2007 Subject: [Mp4-tech] sampling formats Message-ID: Hi, Please if anyone can tell me what is the minimum size of the YUV image in various formats like 4:2:0,4:2:2,4:1:1 and how do we determine that. Regards, Mayank _________________________________________________________________ Sign in and get updated with all the action! http://content.msn.co.in/Sports/FormulaOne/Default -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070509/5c6e877f/attachment-0001.html From sriabtsev broadcom.com Wed May 9 03:11:56 2007 From: sriabtsev broadcom.com (Shevach Riabtsev) Date: Wed May 9 09:46:19 2007 Subject: [Mp4-tech] On cabac_zero_word in H.264 Message-ID: <9110732D7E34E5459A92F96AEEDF829E01D84323@NT-SJCA-0751.brcm.ad.broadcom.com> Dear experts According to AVC standard (section 7.4.1), one or more cabac_zero_word 16-bit syntax elements equal to 0x0000 may be present in some RBSPs after the rbsp_trailing_bits( ). The section 7.4.2.10 says: When entropy_coding_mode_flag is equal to 1, BinCountsInNALunits shall not exceed ( 32 ? 3 ) * NumBytesInVclNALunits+ ( RawMbBits * PicSizeInMbs ) ? 32. Here NumBytesInVclNALunits means the sum of the values of NumBytesInNALunit for all VCL NAL units of a coded picture and BinCountsInNALunits is the number of times that the parsing process function DecodeBin( ). If the actual number of bins exceeds the value specified by the above formula, then cabac_zero_words should be added (in this way NumBytesInVclNALunits is incremented). I don't understand completely why BinCountsInNALunits is restricted ? Why additional stuffing should be added to bit-stream to result BinCountsInNALunits shall not exceed ( 32 ? 3 ) * NumBytesInVclNALunits+ ( RawMbBits * PicSizeInMbs ) ? 32, it might hurt video quality? Regards, Shevach Broadcom -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070509/39522a42/attachment-0001.html From garysull windows.microsoft.com Wed May 9 12:06:39 2007 From: garysull windows.microsoft.com (Gary Sullivan) Date: Wed May 9 14:16:06 2007 Subject: [Mp4-tech] sampling formats In-Reply-To: References: Message-ID: <03CB47D9C3F8074498E4653F814D6E8F049F9B10@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> I think the minimum size of a 4:2:0 image would conceptually be six samples (4 luma and 2 chroma). The formula is height*width*1.5 (assuming height and width are even numbers). I think the minimum size of a 4:2:2 image would conceptually be eight samples (4 luma and 4 chroma). The formula is height*width*2 (assuming height and width are even numbers). I think the minimum size of a 4:1:1 image would conceptually be twelve samples (8 luma and 4 chroma) or perhaps only 6 samples (4 luma and 2 chroma). The formula is height*width*1.5 (assuming width is a multple of 4). I think the minimum size of a 4:4:4 image would conceptually be twelve samples (4 luma and 8 chroma) or perhaps only 3 samples (1 luma and 2 chroma). The formula is height*width*3. But somehow I suspect that is not the answer you are looking for. I suggest clarifying your question. Best Regards, Gary Sullivan ________________________________ From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Mayank Agarwal Sent: Wednesday, May 09, 2024 1:56 AM To: mp4-tech@lists.mpegif.org Subject: [Mp4-tech] sampling formats Hi, Please if anyone can tell me what is the minimum size of the YUV image in various formats like 4:2:0,4:2:2,4:1:1 and how do we determine that. Regards, Mayank ________________________________ Sign in and get updated with all the action! Formula One -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070509/25402716/attachment.html From garysull windows.microsoft.com Wed May 9 12:46:57 2007 From: garysull windows.microsoft.com (Gary Sullivan) Date: Wed May 9 14:52:09 2007 Subject: [Mp4-tech] On cabac_zero_word in H.264 In-Reply-To: <9110732D7E34E5459A92F96AEEDF829E01D84323@NT-SJCA-0751.brcm.ad.broadcom.com> References: <9110732D7E34E5459A92F96AEEDF829E01D84323@NT-SJCA-0751.brcm.ad.broadcom.com> Message-ID: <03CB47D9C3F8074498E4653F814D6E8F049F9B7F@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> Shevach et al, It doesn't actually hurt the quality of the video per se, but it does decrease the degree of compression. Indeed, that is sort of its purpose. We were worried that the compression design might be too good and would threaten our future careers, so we put this feature in as a hidden way to protect ourselves. Please keep that information hush-hush. :-) More seriously, the idea was that if there was no limit on the number of bins that a certain number of bits could generate, the decoder could be overwhelmed by an "evil bitstream" -- it was a fear of a sort of "drinking from a firehose" situation. The belief is that the constraint will rarely have any impact when actually coding typical video. But without the constraint, a decoder designer might have to consider worst-case scenarios where the effective incoming bin rate (due to an unlimited expansion from bits to bins) could become basically unlimited. So this aspect of the design ought to be considered to be good news to companies like Broadcom that want to make decoders that can work properly for any conforming bitstream. I believe this aspect evolved from proposal JVT-C038 by Frank Bossen, with subsequent contributions on the topic by Detlev Marpe, Gabi Bl?ttermann, Thomas Wiegand, Ali Tabatabai, Toby Walker, and Eric Viscito, and perhaps others. I think the final form was established at the Awaji "F" meeting in December 2002. Relevant documents may include JVT-C038, JVT-D019, JVT-D088, JVT-D114, JVT-F039, and JVT-F054. Best Regards, Gary Sullivan ________________________________ From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Shevach Riabtsev Sent: Wednesday, May 09, 2024 2:12 AM To: mp4-tech@lists.mpegif.org Subject: [Mp4-tech] On cabac_zero_word in H.264 Dear experts According to AVC standard (section 7.4.1), one or more cabac_zero_word 16-bit syntax elements equal to 0x0000 may be present in some RBSPs after the rbsp_trailing_bits( ). The section 7.4.2.10 says: When entropy_coding_mode_flag is equal to 1, BinCountsInNALunits shall not exceed ( 32 ? 3 ) * NumBytesInVclNALunits+ ( RawMbBits * PicSizeInMbs ) ? 32. Here NumBytesInVclNALunits means the sum of the values of NumBytesInNALunit for all VCL NAL units of a coded picture and BinCountsInNALunits is the number of times that the parsing process function DecodeBin( ). If the actual number of bins exceeds the value specified by the above formula, then cabac_zero_words should be added (in this way NumBytesInVclNALunits is incremented). I don't understand completely why BinCountsInNALunits is restricted ? Why additional stuffing should be added to bit-stream to result BinCountsInNALunits shall not exceed ( 32 ? 3 ) * NumBytesInVclNALunits+ ( RawMbBits * PicSizeInMbs ) ? 32, it might hurt video quality? Regards, Shevach Broadcom -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070509/dc178fb9/attachment.html From garysull windows.microsoft.com Wed May 9 13:30:32 2007 From: garysull windows.microsoft.com (Gary Sullivan) Date: Wed May 9 15:40:07 2007 Subject: [Mp4-tech] On cabac_zero_word in H.264 In-Reply-To: <03CB47D9C3F8074498E4653F814D6E8F049F9B7F@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> References: <9110732D7E34E5459A92F96AEEDF829E01D84323@NT-SJCA-0751.brcm.ad.broadcom.com> <03CB47D9C3F8074498E4653F814D6E8F049F9B7F@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <03CB47D9C3F8074498E4653F814D6E8F049F9BCE@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> I forgot to mention JVT-E086. Best Regards, Gary Sullivan ________________________________ From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Gary Sullivan Sent: Wednesday, May 09, 2024 11:47 AM To: Shevach Riabtsev; mp4-tech@lists.mpegif.org Subject: RE: [Mp4-tech] On cabac_zero_word in H.264 Shevach et al, It doesn't actually hurt the quality of the video per se, but it does decrease the degree of compression. Indeed, that is sort of its purpose. We were worried that the compression design might be too good and would threaten our future careers, so we put this feature in as a hidden way to protect ourselves. Please keep that information hush-hush. :-) More seriously, the idea was that if there was no limit on the number of bins that a certain number of bits could generate, the decoder could be overwhelmed by an "evil bitstream" -- it was a fear of a sort of "drinking from a firehose" situation. The belief is that the constraint will rarely have any impact when actually coding typical video. But without the constraint, a decoder designer might have to consider worst-case scenarios where the effective incoming bin rate (due to an unlimited expansion from bits to bins) could become basically unlimited. So this aspect of the design ought to be considered to be good news to companies like Broadcom that want to make decoders that can work properly for any conforming bitstream. I believe this aspect evolved from proposal JVT-C038 by Frank Bossen, with subsequent contributions on the topic by Detlev Marpe, Gabi Bl?ttermann, Thomas Wiegand, Ali Tabatabai, Toby Walker, and Eric Viscito, and perhaps others. I think the final form was established at the Awaji "F" meeting in December 2002. Relevant documents may include JVT-C038, JVT-D019, JVT-D088, JVT-D114, JVT-F039, and JVT-F054. Best Regards, Gary Sullivan ________________________________ From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Shevach Riabtsev Sent: Wednesday, May 09, 2024 2:12 AM To: mp4-tech@lists.mpegif.org Subject: [Mp4-tech] On cabac_zero_word in H.264 Dear experts According to AVC standard (section 7.4.1), one or more cabac_zero_word 16-bit syntax elements equal to 0x0000 may be present in some RBSPs after the rbsp_trailing_bits( ). The section 7.4.2.10 says: When entropy_coding_mode_flag is equal to 1, BinCountsInNALunits shall not exceed ( 32 ? 3 ) * NumBytesInVclNALunits+ ( RawMbBits * PicSizeInMbs ) ? 32. Here NumBytesInVclNALunits means the sum of the values of NumBytesInNALunit for all VCL NAL units of a coded picture and BinCountsInNALunits is the number of times that the parsing process function DecodeBin( ). If the actual number of bins exceeds the value specified by the above formula, then cabac_zero_words should be added (in this way NumBytesInVclNALunits is incremented). I don't understand completely why BinCountsInNALunits is restricted ? Why additional stuffing should be added to bit-stream to result BinCountsInNALunits shall not exceed ( 32 ? 3 ) * NumBytesInVclNALunits+ ( RawMbBits * PicSizeInMbs ) ? 32, it might hurt video quality? Regards, Shevach Broadcom -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070509/f115df93/attachment-0001.html From jclark metricsystems.com Wed May 9 12:09:37 2007 From: jclark metricsystems.com (John Clark) Date: Wed May 9 21:04:06 2007 Subject: [Mp4-tech] Multiplexing mpeg-4 streams with transcoding to a single Mpeg 2 TS. Message-ID: <46420E61.3070903@metricsystems.com> What I'm looking for is essentially a software 'mux' to combine a number of Mpeg-4 sources, into one single transport stream. Now, if there are tools that do that for Multipe Mpeg-4 to Mpeg-4 streams, I'd like to know about that as well. The reason for this need is to take a number of so called 'Internet cameras' which produce single Mpeg-4 streams, and then broadcast them to receivers which tune in to a particular channel, and sub-channel via program identifiers. The single streams are of a 'low bit' rate, say 1-2 Mbits/sec. So several can 'fit' on a single 19.4 Mb/s 'broadcast' stream. Hopefully this has enough details for someone to respond. Thanks John Clark. From pankaj_bajpai_iet operamail.com Thu May 10 06:59:47 2007 From: pankaj_bajpai_iet operamail.com (pankaj bajpai) Date: Thu May 10 03:28:06 2007 Subject: [Mp4-tech] sampling formats Message-ID: <20070510045947.DBBFC2477B@ws5-3.us4.outblaze.com> Dear Mayank YUV 420 : size : Y =w*h, U and V= w/2*h/2 YUV 422 : size : Y =w*h, U and V= w/2*h YUV411 i am not very sure but i think size is same as one of the above, but only difference is where to place the subsampled pixel. Please correct me if am wrong. With regards ========================================== From: Mayank Agarwal To: mp4-tech@lists.mpegif.org Subject: [Mp4-tech] sampling formats Date: Wed, 9 May 2024 14:25:35 +0530 Hi, Please if anyone can tell me what is the minimum size of the YUV image in various formats like 4:2:0,4:2:2,4:1:1 and how do we determine that. Regards, Mayank -- _______________________________________________ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze From shanmugavel.balasubramanian wipro.com Thu May 10 15:39:33 2007 From: shanmugavel.balasubramanian wipro.com (shanmugavel.balasubramanian@wipro.com) Date: Thu May 10 09:34:06 2007 Subject: [Mp4-tech] H.264 - Stream with multiple FMO types References: <200705091349.l49DmQBT013140@lists1.magma.ca> Message-ID: <70661EB74D51BD4889EE03CC34E733F50C5C71@blr-m2-msg.wipro.com> An embedded message was scrubbed... From: Subject: H.264 - Stream with multiple FMO types Date: Thu, 10 May 2024 14:39:33 +0530 Size: 6607 Url: /pipermail/mp4-tech/attachments/20070510/60532a7a/originalmail-0001.eml -------------- next part -------------- The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com From sriabtsev broadcom.com Thu May 10 03:38:17 2007 From: sriabtsev broadcom.com (Shevach Riabtsev) Date: Thu May 10 09:34:12 2007 Subject: [Mp4-tech] On cabac_zero_word in H.264 In-Reply-To: <03CB47D9C3F8074498E4653F814D6E8F049F9B7F@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <9110732D7E34E5459A92F96AEEDF829E01D84466@NT-SJCA-0751.brcm.ad.broadcom.com> Hi Gary First of all thanks for documents. I think that the "evil bitstream" fear is exaggerated. Simple entropy calculation shows that the theoretical limit for bin/bit ratio is 8:1. Indeed, the minimal probability value for LPS (least-probable symbol) is p=0.01875 . If we assume that all bins in a picture are coded with probability of LPS equal 0.01875, then the entropy H= -p log2(p) - (1-p) log2(1-p) = 0.1341 bit/bin Hence the maximal bin/bit ratio is 8:1 . So, if a decoder gets an access unit with bit size N, then the maximal number of bins shall not exceed 8N. The 8N limit is not so overwhelming (in my opinion). According to my experience I have never observed per single bin the bin/bit ratio exceeding 5:1 (5:1 bin/bit ratio can be observed on end_of_slice_flag syntax elements, since most time they are zero). Therefore the real bin/bit limit should be 5:1 or 6:1. Regards, Shevach Broadcom ________________________________ From: Gary Sullivan [mailto:garysull@windows.microsoft.com] Sent: Wednesday, May 09, 2024 9:47 PM To: Shevach Riabtsev; mp4-tech@lists.mpegif.org Subject: RE: [Mp4-tech] On cabac_zero_word in H.264 Shevach et al, It doesn't actually hurt the quality of the video per se, but it does decrease the degree of compression. Indeed, that is sort of its purpose. We were worried that the compression design might be too good and would threaten our future careers, so we put this feature in as a hidden way to protect ourselves. Please keep that information hush-hush. :-) More seriously, the idea was that if there was no limit on the number of bins that a certain number of bits could generate, the decoder could be overwhelmed by an "evil bitstream" -- it was a fear of a sort of "drinking from a firehose" situation. The belief is that the constraint will rarely have any impact when actually coding typical video. But without the constraint, a decoder designer might have to consider worst-case scenarios where the effective incoming bin rate (due to an unlimited expansion from bits to bins) could become basically unlimited. So this aspect of the design ought to be considered to be good news to companies like Broadcom that want to make decoders that can work properly for any conforming bitstream. I believe this aspect evolved from proposal JVT-C038 by Frank Bossen, with subsequent contributions on the topic by Detlev Marpe, Gabi Bl?ttermann, Thomas Wiegand, Ali Tabatabai, Toby Walker, and Eric Viscito, and perhaps others. I think the final form was established at the Awaji "F" meeting in December 2002. Relevant documents may include JVT-C038, JVT-D019, JVT-D088, JVT-D114, JVT-F039, and JVT-F054. Best Regards, Gary Sullivan ________________________________ From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Shevach Riabtsev Sent: Wednesday, May 09, 2024 2:12 AM To: mp4-tech@lists.mpegif.org Subject: [Mp4-tech] On cabac_zero_word in H.264 Dear experts According to AVC standard (section 7.4.1), one or more cabac_zero_word 16-bit syntax elements equal to 0x0000 may be present in some RBSPs after the rbsp_trailing_bits( ). The section 7.4.2.10 says: When entropy_coding_mode_flag is equal to 1, BinCountsInNALunits shall not exceed ( 32 ? 3 ) * NumBytesInVclNALunits+ ( RawMbBits * PicSizeInMbs ) ? 32. Here NumBytesInVclNALunits means the sum of the values of NumBytesInNALunit for all VCL NAL units of a coded picture and BinCountsInNALunits is the number of times that the parsing process function DecodeBin( ). If the actual number of bins exceeds the value specified by the above formula, then cabac_zero_words should be added (in this way NumBytesInVclNALunits is incremented). I don't understand completely why BinCountsInNALunits is restricted ? Why additional stuffing should be added to bit-stream to result BinCountsInNALunits shall not exceed ( 32 ? 3 ) * NumBytesInVclNALunits+ ( RawMbBits * PicSizeInMbs ) ? 32, it might hurt video quality? Regards, Shevach Broadcom -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070510/a81a2239/attachment-0001.html From garysull windows.microsoft.com Thu May 10 14:33:17 2007 From: garysull windows.microsoft.com (Gary Sullivan) Date: Thu May 10 16:40:06 2007 Subject: [Mp4-tech]Data Partition in JM In-Reply-To: <20070507215432.5y6y023o08wgkw8s@wmail1.cc.ntu.edu.tw> References: <20070507215432.5y6y023o08wgkw8s@wmail1.cc.ntu.edu.tw> Message-ID: <03CB47D9C3F8074498E4653F814D6E8F04A9E12D@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> Actually, I believe there should ordinarily be two data partitions per slice for an I slice and three for a P slice. They are referred to as data partitions A, B, and C. Data partition A contains header information. Data partition B contains intra residual data. Data partition C contains inter residual data. Best Regards, Gary Sullivan -----Original Message----- From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Yu-Wen Chen Sent: Monday, May 07, 2024 6:55 AM To: mp4-tech@lists.mpegif.org Subject: [Mp4-tech]Data Partition in JM Dear all, I have a question about data partitioning in JM software: In JM software, there are three partitions if you enables data partitioning. And I use a variable "nalu->len" to find each partition size. I find that only one nal unit for I frame and two nal units for P frame. Based on the definition of DP, The decoder can decode part of a frame if it only received one or two of three partitions. Now there are two nal units in the P frame. The first case I met is that the decoder will discard this frame data if it only receives second unit. And the second case is that the decoder will meet error if only the first nal unit is received. So how to solve above problem I met and how to utilize data partition to improve video quality with loss rate in a correct way? Thx Best regards, Yu-Wen Chen _______________________________________________ NOTE: Please use clear subject lines for your posts. Include [audio, [video], [systems], [general] or another apppropriate identifier to indicate the type of question you have. Note: Conduct on the mailing list is subject to the Antitrust guidelines found at http://www.mpegif.org/public/documents/vault/mp-out-30042-Antitrust.php From gouthamnvaidhya gmail.com Fri May 11 11:09:32 2007 From: gouthamnvaidhya gmail.com (goutham vaidhya) Date: Fri May 11 01:34:06 2007 Subject: [Mp4-tech] AAC LC problem with mannual decoding of raw_data_block() Message-ID: hi all, In aac lc profile i just tried to decode the raw data stream manually. In standard it states that we will get the spectral values till max_sfb, which can be less then num_swb(table 8.4 - 8.16 of mpeg2 aac). So i got 640 spectral values after hufmman decoding. BUt for doing IMDCT we need 1024 samples. Can anybody pls tell me what we should fill in the remaining spectral values. Pls tell me where in the specification does this is mentioned tnx in advance. -- Have a NICE day -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070511/50bb60d3/attachment.html From ralph.sperschneider iis.fraunhofer.de Fri May 11 12:28:11 2007 From: ralph.sperschneider iis.fraunhofer.de (Ralph Sperschneider) Date: Fri May 11 05:34:06 2007 Subject: [Mp4-tech] Re: [Audio] AAC LC problem with mannual decoding of raw_data_block() In-Reply-To: References: Message-ID: <4644372B.9060200@iis.fraunhofer.de> goutham vaidhya wrote: > hi all, > In aac lc profile i just tried to decode the raw data stream manually. > In standard it states that we will get the spectral values till > max_sfb, which can be less then num_swb(table 8.4 - 8.16 of mpeg2 aac). > So i got 640 spectral values after hufmman decoding. BUt for doing > IMDCT we > need 1024 samples. > Can anybody pls tell me what we should fill in the remaining > spectral values. > Pls tell me where in the specification does this is mentioned > tnx in advance. > > -- > Have a NICE day Dear Goutham Vaidhya, ISO/IEC 13818-7:2005, subclause 8.3.2.6 (Spectral Data Parsing and Decoding) states: " The spectral data is recovered ... It consists of all the non-zeroed coefficients remaining in the spectrum or spectra, ... " Furthermore, ISO/IEC 13818-7:2005, subclause 9.3 (Decoding Process) states: "The spectral information for all scalefactor bands at and above max_sfb, for which there is no section data, is zero." Those statements should clarify your question. Best regards, Ralph -- Dipl.-Ing. Ralph Sperschneider | Phone: +49 9131 776 344 Fraunhofer IIS | Fax: +49 9131 776 398 Am Wolfsmantel 33 | mailto:ralph.sperschneider@iis.fraunhofer.de D 91058 Erlangen | http://www.iis.fraunhofer.de/amm/ From seblopez iuma.ulpgc.es Tue May 8 17:06:15 2007 From: seblopez iuma.ulpgc.es (=?ISO-8859-1?Q?Sebasti=E1n_L=F3pez_Su=E1rez?=) Date: Sun May 13 09:04:06 2007 Subject: [Mp4-tech] [H264 video] Marker bit Message-ID: Dear experts, Could you tell me which is the functionality of the marker bit when using RTP packets? In addition, could you tell me why this bit is always set to 1 in the RTP headers when using the reference code? It not supposed to be 1 only for certain RTP packets? Thanks in advance. From thiago_hr yahoo.com.br Tue May 15 01:55:54 2007 From: thiago_hr yahoo.com.br (Thiago Henrique) Date: Tue May 15 08:16:10 2007 Subject: [Mp4-tech] CRC32 of a TS packet Message-ID: <004301c796c6$7ae41f10$0100000a@athlonxp> I have to write a program to calculate the CRC32 of Transport Stream packets but I had no success yet. For example: This is a sample PAT from a working TS: 47 60 00 10 00 00 B0 0D 00 00 C1 00 00 00 01 E1 E0 76 F1 A4 CE Where (76 F1 A4 CE) is the CRC32 I am trying to calculate using these bytes 00 B0 0D 00 00 C1 00 00 00 01 E1 E0 And I get 5D 67 ED 81 Does anyone know how to calculate the correct CRC32? Which bytes to use? Is it the same CRC32 of PKZIP ? Thanks Thiago -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070515/62ab4bf8/attachment.html From dsn2603 rediffmail.com Tue May 15 05:26:51 2007 From: dsn2603 rediffmail.com (sakthi narayanan) Date: Tue May 15 08:16:15 2007 Subject: [Mp4-tech] DRC in AAC Message-ID: <1178859007.S.2010.15828.webmail77.rediffmail.com.old.1179203219.28671@webmail.rediffmail.com>  Hi all, Can u explain me what is DRC?Why and When DRC  is used in AAC?How to test the aac bitstream with DRC  enable?With Regards,sakthi -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070515/ec0aeaab/attachment.html From kalasubramani yahoo.com Tue May 15 04:57:46 2007 From: kalasubramani yahoo.com (subramani nagammal) Date: Tue May 15 08:16:19 2007 Subject: [Mp4-tech] Re: Mp4-tech Digest, Vol 46, Issue 9 In-Reply-To: <200705131607.l4DG7LG5014727@lists1.magma.ca> Message-ID: <455720.74394.qm@web35606.mail.mud.yahoo.com> Experts, I want to know how we can do text overlay in H.264 ? It would be grateful if anyone replies. --- mp4-tech-request@lists.mpegif.org wrote: > Send Mp4-tech mailing list submissions to > mp4-tech@lists.mpegif.org > > To subscribe or unsubscribe via the World Wide Web, > visit > http://lists.mpegif.org/mailman/listinfo/mp4-tech > or, via email, send a message with subject or body > 'help' to > mp4-tech-request@lists.mpegif.org > > You can reach the person managing the list at > mp4-tech-owner@lists.mpegif.org > > When replying, please edit your Subject line so it > is more specific > than "Re: Contents of Mp4-tech digest..." > > > Today's Topics: > > 1. [H264 video] Marker bit (Sebasti?n L?pez > Su?rez) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 8 May 2024 16:06:15 +0100 (Hora de verano > GMT) > From: Sebasti?n L?pez Su?rez > > Subject: [Mp4-tech] [H264 video] Marker bit > To: mp4-tech@lists.mpegif.org > Message-ID: > > > Content-Type: TEXT/PLAIN; charset=US-ASCII > > Dear experts, > > Could you tell me which is the functionality of the > marker bit when using > RTP packets? > > In addition, could you tell me why this bit is > always set to 1 in the RTP > headers when using the reference code? It not > supposed to be 1 only for > certain RTP packets? > > Thanks in advance. > > > > ------------------------------ > > _______________________________________________ > Please use clear subject lines for your posts. > Include [audio, [video], [systems], [general] or > another apppropriate identifier to indicate the type > of question you have. > > Conduct on the mailing list is subject to the > Antitrust guidelines found at > http://www.mpegif.org/public/documents/vault/mp-out-30042-Antitrust.php > > End of Mp4-tech Digest, Vol 46, Issue 9 > *************************************** > ____________________________________________________________________________________ Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. http://autos.yahoo.com/green_center/ From sriabtsev broadcom.com Tue May 15 06:50:17 2007 From: sriabtsev broadcom.com (Shevach Riabtsev) Date: Tue May 15 09:34:06 2007 Subject: [Mp4-tech] Why MB-skip is not allowed in H.264 for I picture Message-ID: <9110732D7E34E5459A92F96AEEDF829E01ECE682@NT-SJCA-0751.brcm.ad.broadcom.com> Dear experts Unlike other standards (H.261, Mpeg2 and Mpeg4), spatial redundancy in H.264 is much more exploited. Indeed, there are 9 intra prediction modes for INTRA4x4, 4 modes for 16x16 versus DC/AC prediction of Mpeg4 or DC only prediction in Mpeg2. Consequently for smooth I-pictures zero coded_block_pattern is frequently observed. I wonder why mb-skip is forbidden in AVC for I-pictures. Is there any reason? Regards, Shevach Broadcom -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070515/daab70a6/attachment.html From ralph.sperschneider iis.fraunhofer.de Wed May 16 12:09:47 2007 From: ralph.sperschneider iis.fraunhofer.de (Ralph Sperschneider) Date: Wed May 16 05:22:07 2007 Subject: [Mp4-tech] Re: AAC LC mannual decoding of raw_data_block() In-Reply-To: References: <4649D20F.7080005@iis.fraunhofer.de> Message-ID: <464ACA5B.30101@iis.fraunhofer.de> goutham vaidhya wrote: > > > On 5/15/07, *Ralph Sperschneider* > > wrote: > > goutham vaidhya wrote: > > > > hi , > > The reply was very helpfull > > > > But I still have doubt.I have attached a file containing my > > understanding of windows, window groups , scalefactor bands & > sections. > > Could u pls have a look at it. > > > > one more thing, I want to mannually decode some more frames & > verify > > that it is right. > > So If u have any ADTS format file & the corresponding huffman > decoded > > spectral values pls send it. > > > > Thank you: > > Goutham N Vaidhya > > -- > > Have a NICE day > > Dear Goutham N Vaidhya, > > in your attachment, you refer to 13818-7:1999. This does not > exist. The > first edition of MPEG-2 AAC was issued 1997, the second edition was > issued 2003. Tables with the number format x.y exist only in the first > edition, so I assume that you refer to this. > > Your figure 4 is definitely wrong. Figures 2 and 3 are fine, if they > state the status prior to the deinterleaving process. Figure 1 is > fine, > if it states the process after the deinterleaving process > (although all > windows should then have the same size, but that might be just a > drawing > issue). > > In the case of short blocks, you always have to deal with eight > spectra, > each of which has 128 lines total. This is independent of any > grouping. > So if, as in your example, max_sfb=11 (sampling frequency = > 48kHz), then > in each spectrum the lines of the scale factor bands 12, 13 and 14 > ( i.e. > the lines 80 till 127) need to be set to zero. The grouping only > reduces > the number of scale factors to be transmitted, implying that the same > set of scale factors has to be applied several times. At the same > time, > grouping leads to sfb-wise interleaving of the codewords within > each group. > > For further details I would like to refer to ISO/IEC 13818-7:2005 > subclause 8.3.5 "Order of spectral coefficients in spectral_data" and > particularly Figure 6 "Spectral order of scalefactor bands in case of > EIGHT_SHORT_SEQUENCE" (in ISO/IEC 13818-7:1997 it is Figure 8.3). > > ADTS sequences can be found here: > > ftp://mpaudcon:adif2mp4@ftp.iis.fraunhofer.de/mpeg2aac-conformance/compressedAdts > . > > > The reference software can be found here: > > http://standards.iso.org/ittf/PubliclyAvailableStandards/c039486_ISO_IEC_13818-5_2005_Reference_Software.zip > > It should not that difficult to patch the AAC decoder so that it > outputs > the decoded spectral values. At the same time, the software should > help > you to figure out the correct interpretation of the AAC payload > and show > you the proper decoding steps. > > Best regards, > Ralph > > -- > Dipl.-Ing. Ralph Sperschneider | Phone: +49 9131 776 344 > Fraunhofer IIS | Fax: +49 9131 776 398 > Am Wolfsmantel 33 | > mailto:ralph.sperschneider@iis.fraunhofer.de > > D 91058 Erlangen | http://www.iis.fraunhofer.de/amm/ > > > > thanks for clearing my doubt. Now the concept is very clear. > The link u have sent me is asking for username & password. Sorry, the link should be: ftp://mpaudconf:adif2mp4@ftp.iis.fraunhofer.de/mpeg2aac-conformance/compressedAdts (username and pwd are already in the URL) Best regards, Ralph From bs.guru gmail.com Wed May 16 15:32:49 2007 From: bs.guru gmail.com (Gururaj Bhat) Date: Wed May 16 08:52:10 2007 Subject: [Mp4-tech] Format of stereo signal in AAC bitstream Message-ID: <6ff0db9f0705160202nb356f0s6a55656f26cdfef3@mail.gmail.com> Hi all, I have a query about the implementation of AAC. For a stereo signal , does the standard tell that it should be implemented as CPE? or two SCE's also allowed? (in a raw data block ) Thanks in advance, Gururaj Bhat -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070516/54ea639f/attachment.html From tsviatko playbox.tv Wed May 16 15:18:01 2007 From: tsviatko playbox.tv (Tsviatko Jongov) Date: Wed May 16 08:52:16 2007 Subject: [Mp4-tech] Re: CRC32 of a TS packet Message-ID: <464AE869.3050209@playbox.tv> Hi, First, the CRC polynomial for MPEG is 0x04C11DB7 (ISO/IEC 13818-1 or http://en.wikipedia.org/wiki/Crc32). For PAT, CAT and PMT, you must calculate the CRC of all bytes starting from "table_id" (inclusive) and finishing with the byte just before the CRC field in the PAT/CAT/PMT table. Then set the CRC32 value. You can check your calculations by running CRC on whole data including the CRC32 field - the result must be 0. Regards, Tsviatko Jongov http://tsviatko.jongov.com From sriabtsev broadcom.com Wed May 16 07:00:10 2007 From: sriabtsev broadcom.com (Shevach Riabtsev) Date: Wed May 16 09:40:08 2007 Subject: [Mp4-tech] Why MB-skip is not allowed in H.264 for I picture Message-ID: <9110732D7E34E5459A92F96AEEDF829E01ECE820@NT-SJCA-0751.brcm.ad.broadcom.com> Thanks John This is an interesting idea to hide the actual I picture in P-picture envelope. But I see two difficulties: 1 . How to provide IDR pictures and hence random access for a decoder. In other words an encoder has to produce IDR picture at the pre-defined interval for random access. 2. As a decoder sees a skip MB, it derives its MV (in the case when all MBs are Intra, MV=0) and copies the corresponding 16x16 region from the reference picture. In this case a spatial redundancy is not exploited. In some cases spatial redundancy gives more profit than temporal one, even for Inter pictures. Unfortunately in H.264 standard only Inter SKIP is defined. Intra Skip MB could have been defined as Intra16x16 MB with CBP=0 and with a prediction mode equal the prediction mode of top or left MB. Regards ________________________________ From: John Smith [mailto:jsmith911@gmail.com] Sent: Tuesday, May 15, 2024 9:06 PM To: Shevach Riabtsev Subject: RE: [Mp4-tech] Why MB-skip is not allowed in H.264 for I picture You may encode picture as P, using intra-only modes. There will be some overhead for mb_type but mb_skip will be available for use. ________________________________ From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Shevach Riabtsev Sent: Tuesday, May 15, 2024 3:50 PM To: mp4-tech@lists.mpegif.org Subject: [Mp4-tech] Why MB-skip is not allowed in H.264 for I picture Dear experts Unlike other standards (H.261, Mpeg2 and Mpeg4), spatial redundancy in H.264 is much more exploited. Indeed, there are 9 intra prediction modes for INTRA4x4, 4 modes for 16x16 versus DC/AC prediction of Mpeg4 or DC only prediction in Mpeg2. Consequently for smooth I-pictures zero coded_block_pattern is frequently observed. I wonder why mb-skip is forbidden in AVC for I-pictures. Is there any reason? Regards, Shevach Broadcom -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070516/186c034c/attachment.html From alexis.tourapis dolby.com Wed May 16 10:22:28 2007 From: alexis.tourapis dolby.com (Tourapis, Alexis) Date: Wed May 16 12:34:08 2007 Subject: [Mp4-tech] Why MB-skip is not allowed in H.264 for I picture In-Reply-To: <9110732D7E34E5459A92F96AEEDF829E01ECE820@NT-SJCA-0751.brcm.ad.broadcom.com> References: <9110732D7E34E5459A92F96AEEDF829E01ECE820@NT-SJCA-0751.brcm.ad.broadcom.com> Message-ID: <2BAAC5E4AF2518459F0AB5D9279420475958A3@bur-exch-01.dolby.net> Dear Shevach, As you have stated, in some cases this may be useful. However, in many cases this might not. Providing such a mode for example may hurt the performance for many video sequences since that would add additional overhead for every macroblock. Would this overhead be compensated by the presence of a good enough number of intra skip modes within the entire slice to justify its presence? That is difficult to say. And if it does help, how much benefit would it actually provide? Note that such an evaluation would also have to be made for several sequences with different types of spatial "activity" and for different QPs. Btw, I would also caution you checking only RD results when evaluating skip modes (if of course your question is based on an experiment that you may have already performed) since, if evaluating such modes within a Rate Distortion Optimized codec, their behavior is evaluated as a "thresholding" mode which could be emulated using other means (i.e. considering existing modes while dumping all coefficients). Distortion performance (i.e. PSNR) may also not match the subjective performance of the decoded picture. Finally, do note that there is already some activity within VCEG where new techniques are presented, including techniques for intra prediction/coding which probably would probably affect the behavior or performance of such a mode. Some of these suggest improvements of even more than 10%. If you are curious about this activity I would suggest checking the following link and examining some of the contributions (check mainly the latest one which is 0704_San) http://ftp3.itu.ch/av-arch/video-site/ Note, that If you think that this is something useful for future codecs maybe you can propose it within this activity as well. Best regards, Alexis ________________________________ From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Shevach Riabtsev Sent: Wednesday, May 16, 2024 6:00 AM To: mp4-tech@lists.mpegif.org Subject: RE: [Mp4-tech] Why MB-skip is not allowed in H.264 for I picture Thanks John This is an interesting idea to hide the actual I picture in P-picture envelope. But I see two difficulties: 1 . How to provide IDR pictures and hence random access for a decoder. In other words an encoder has to produce IDR picture at the pre-defined interval for random access. 2. As a decoder sees a skip MB, it derives its MV (in the case when all MBs are Intra, MV=0) and copies the corresponding 16x16 region from the reference picture. In this case a spatial redundancy is not exploited. In some cases spatial redundancy gives more profit than temporal one, even for Inter pictures. Unfortunately in H.264 standard only Inter SKIP is defined. Intra Skip MB could have been defined as Intra16x16 MB with CBP=0 and with a prediction mode equal the prediction mode of top or left MB. Regards ________________________________ From: John Smith [mailto:jsmith911@gmail.com] Sent: Tuesday, May 15, 2024 9:06 PM To: Shevach Riabtsev Subject: RE: [Mp4-tech] Why MB-skip is not allowed in H.264 for I picture You may encode picture as P, using intra-only modes. There will be some overhead for mb_type but mb_skip will be available for use. ________________________________ From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Shevach Riabtsev Sent: Tuesday, May 15, 2024 3:50 PM To: mp4-tech@lists.mpegif.org Subject: [Mp4-tech] Why MB-skip is not allowed in H.264 for I picture Dear experts Unlike other standards (H.261, Mpeg2 and Mpeg4), spatial redundancy in H.264 is much more exploited. Indeed, there are 9 intra prediction modes for INTRA4x4, 4 modes for 16x16 versus DC/AC prediction of Mpeg4 or DC only prediction in Mpeg2. Consequently for smooth I-pictures zero coded_block_pattern is frequently observed. I wonder why mb-skip is forbidden in AVC for I-pictures. Is there any reason? Regards, Shevach Broadcom ----------------------------------------- This message (including any attachments) may contain confidential information intended for a specific individual and purpose. If you are not the intended recipient, delete this message. If you are not the intended recipient, disclosing, copying, distributing, or taking any action based on this message is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070516/39e628f8/attachment.html From matthew ovt.com.cn Thu May 17 01:43:54 2007 From: matthew ovt.com.cn (Matthew Wang) Date: Wed May 16 13:10:09 2007 Subject: [Mp4-tech] About 14496-3 References: <6ff0db9f0705160202nb356f0s6a55656f26cdfef3@mail.gmail.com> Message-ID: <00b101c797d9$64ff2a50$3732a8c0@MatthewWang> Dear all: Could someone tell me that where I can get 14496-3 standard? Thanks best regards Yours Sincerely Matthew -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070517/b0465083/attachment.html From senthil vinjey.com Thu May 17 00:05:01 2007 From: senthil vinjey.com (Senthil) Date: Wed May 16 14:16:08 2007 Subject: [Mp4-tech] Format of stereo signal in AAC bitstream References: <6ff0db9f0705160202nb356f0s6a55656f26cdfef3@mail.gmail.com> Message-ID: <002f01c797e0$884fd430$321414c5@senthil> Hi Gururaj Bhat, For a stereo signal , does the standard tell that it should be implemented as CPE? or two SCE's also allowed? (in a raw data block ) There is no restriction like stereo signal should be coded as CPE only, it could be two separate SCE also. This kind of bit stream is called as dual mono streams. In these cases we will not apply Mid Stereo and Intensity Stereo >From raw data block itself it will come as a SCE only. I hope this answers for your question. Thanks Senthil. ----- Original Message ----- From: Gururaj Bhat To: mp4-tech@lists.mpegif.org Sent: Wednesday, May 16, 2024 2:32 PM Subject: [Mp4-tech] Format of stereo signal in AAC bitstream Hi all, I have a query about the implementation of AAC. For a stereo signal , does the standard tell that it should be implemented as CPE? or two SCE's also allowed? (in a raw data block ) Thanks in advance, Gururaj Bhat ------------------------------------------------------------------------------ _______________________________________________ NOTE: Please use clear subject lines for your posts. Include [audio, [video], [systems], [general] or another apppropriate identifier to indicate the type of question you have. Note: Conduct on the mailing list is subject to the Antitrust guidelines found at http://www.mpegif.org/public/documents/vault/mp-out-30042-Antitrust.php -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070516/0ed5a94d/attachment-0001.html From magarwal NeoMagic.com Thu May 17 19:25:32 2007 From: magarwal NeoMagic.com (Mohit Agarwal) Date: Thu May 17 10:04:10 2007 Subject: [Mp4-tech] About 14496-3 In-Reply-To: <00b101c797d9$64ff2a50$3732a8c0@MatthewWang> References: <6ff0db9f0705160202nb356f0s6a55656f26cdfef3@mail.gmail.com> <00b101c797d9$64ff2a50$3732a8c0@MatthewWang> Message-ID: <012801c79882$a8a31920$841fa8c0@pcmagarwal> You can purchase it from ISO Store. http://www.iso.org/iso/en/CatalogueListPage.CatalogueList Thanks, Mohit _____ From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Matthew Wang Sent: Wednesday, May 16, 2024 10:14 PM To: mp4-tech@lists.mpegif.org Subject: [Mp4-tech] About 14496-3 Dear all: Could someone tell me that where I can get 14496-3 standard? Thanks best regards Yours Sincerely Matthew -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070517/804fd392/attachment.html From pchirag gmail.com Thu May 17 20:37:45 2007 From: pchirag gmail.com (Chirag Pujara) Date: Thu May 17 10:34:07 2007 Subject: [Mp4-tech] relation between dpb size and level idc Message-ID: <6cb7f2550705170707m1ca44826k57b83bff22655779@mail.gmail.com> Hello experts, I am using the JM 11.0 code for H264 encoder. Can anyone please tell me is there any relation between dpb size and the number of reference frames defined. or it is only related with the level idc?? for your reference, for qcif image size I gave number of reference frame as 1 and level idc as 30 i.e 3.0, for this combination dpb size is coming as 16 and it is storing previous 16 frames in dpb. so is it any how related with the number of reference frames? -- Thanks and Regards Chirag Pujara -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070517/0a405666/attachment.html From sreejana.sharma intel.com Thu May 17 18:10:54 2007 From: sreejana.sharma intel.com (Sharma, Sreejana) Date: Fri May 18 08:28:06 2007 Subject: [Mp4-tech] Information on how to create AAC LC with LATM header Message-ID: <477457A8DCA386439DA800C066CF973E010D7FC5@azsmsx414.amr.corp.intel.com> Hello all, I am working on creating AAC LC audio content with LATM header. Is there any tool available that can help me create that content. Also are there any decoder available that can help me parse the LATM headers. Also can I have an AAC LC content with just LATM header and can any decoder decode it. Or does AAC with LATM have to be in some sort of file format such as 3gp or mp4 file format. Any help in this direction will be greatly appreciated. Thank you Sreejana -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070517/dcd11ef9/attachment.html From garg.rahul gmail.com Fri May 18 12:50:42 2007 From: garg.rahul gmail.com (Rahul Garg) Date: Fri May 18 08:28:13 2007 Subject: [Mp4-tech] multi sps and pps in MP4 file format In-Reply-To: References: <411.17161.qm@web56215.mail.re3.yahoo.com> Message-ID: <310d33020705172320i1a52cba0u6ccf3e8869c3c94@mail.gmail.com> Hi All, Where can I get specification of AVI file format for embeddeding MPEG-4 Part 2 and Part10 video and various audio contents ? Regards, Rahul -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070518/7b80ca11/attachment.html From Veenit.Vora patni.com Fri May 18 13:17:55 2007 From: Veenit.Vora patni.com (Vora, Veenit) Date: Fri May 18 08:28:18 2007 Subject: [Mp4-tech] [MPEG-4 Audio] Size mismatch when AAC-LC test vector is passed through HE-AAC decoder Message-ID: <87B7092E3762F8488DE6C3FEA50E0E3E94A030@EXCHSPZ01.patni.com> Hello Everyone, I am working on the HEAAC profile (AAC-LC + SBR) of the MPEG-4 standard. I am using the Reference Code for the decoder provided by ISO for this purpose. The version of the Reference Code is: ISO/IEC 14496-5:2001/Amd.6:2005. The decoder that I am using is located in the folder "mp4AudVm_Rewrite". To test the conformance of the "AAC-LC" part of the decoder, I am passing a reference vector for the AAC-LC AOT that is given by ISO, through the HEAAC profile decoder. It generates an output file whose size is larger than the size of the corresponding reference wav file that is provided by ISO. On viewing the data of the two files, I find that the test data exactly matches the reference data after a certain number of bytes are offseted from the start of the test file. My queries are: 1. Why would the HE-AAC decoder generate a test output whose size is larger than the reference output, for the AAC-LC test vector. (the size is not exactly double so this eliminates the possibility of this happening due to SBR tool being enabled in the decoder ( since SBR operates at twice the sampling freq of AAC))? 2. How can I eliminate this offset being written by the HEAAC decoder. On removal of these offset bytes at the start of my test output, my test output would be bit-match with my reference output. Thanking everyone in advance. Awaiting an early reply. Regards, Veenit Vora. Patni Computer Systems Ltd., Unit No. 19, SDF 7, SEEPZ, Andheri (E), Mumbai - 400096. Tel: +91-22-28291454. Ext: 5937 http://www.patni.com World-Wide Partnerships. World-Class Solutions. _____________________________________________________________________ This e-mail message may contain proprietary, confidential or legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify us immediately at netadmin@patni.com and delete this mail. _____________________________________________________________________ From singer apple.com Fri May 18 09:18:37 2007 From: singer apple.com (Dave Singer) Date: Fri May 18 11:28:09 2007 Subject: [Mp4-tech] multi sps and pps in MP4 file format In-Reply-To: <310d33020705172320i1a52cba0u6ccf3e8869c3c94@mail.gmail.com> References: <411.17161.qm@web56215.mail.re3.yahoo.com> <310d33020705172320i1a52cba0u6ccf3e8869c3c94@mail.gmail.com> Message-ID: At 11:50 +0530 18/05/07, Rahul Garg wrote: >Hi All, > >Where can I get specification of AVI file format for embeddeding >MPEG-4 Part 2 and Part10 video and various audio contents ? > >Regards, >Rahul I'm sorry, I don't know. I think there are various 'accepted practices' but as far as I know, no-one publishes formal specs for AVI any more. -- David Singer Apple Computer/QuickTime From sreejana.sharma intel.com Fri May 18 10:32:33 2007 From: sreejana.sharma intel.com (Sharma, Sreejana) Date: Fri May 18 14:22:07 2007 Subject: [Mp4-tech] [Audio] Information on how to create AAC LC with LATM header Message-ID: <477457A8DCA386439DA800C066CF973E010D81CD@azsmsx414.amr.corp.intel.com> Hello all, I am working on creating AAC LC audio content with LATM header. Is there any tool available that can help me create that content. Also are there any decoder available that can help me parse the LATM headers. Also can I have an AAC LC content with just LATM header and can any decoder decode it. Or does AAC with LATM have to be in some sort of file format such as 3gp or mp4 file format. Any help in this direction will be greatly appreciated. Thank you Sreejana -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070518/fd2f5804/attachment.html From Evan.Tan nicta.com.au Sat May 19 15:28:59 2007 From: Evan.Tan nicta.com.au (Evan Tan) Date: Sun May 20 16:46:07 2007 Subject: [Mp4-tech] Rate control model updating possible bugs? Message-ID: <32911.60.241.171.60.1179548939.squirrel@mailbag.nicta.com.au> Dear Experts, In rc_quadratic.c - updateRCModel(), the update history loop: for (i = (RC_MODEL_HISTORY-2); i > 0; i--) {// update the history ... } shouldn't it be: for (i = (RC_MODEL_HISTORY-1); i > 0; i--) ? and also in the updateRCModel(): for (i = 0; i < (RC_MODEL_HISTORY-1); i++) { m_rgRejected[i] = FALSE; } shouldn't it be: for (i = 0; i < RC_MODEL_HISTORY; i++) ? the same applies to updateMADModel() Thanks, Evan From aleon dolby.com Sun May 20 15:01:16 2007 From: aleon dolby.com (Leontaris, Athanasios) Date: Mon May 21 09:34:07 2007 Subject: [Mp4-tech] Rate control model updating possible bugs? In-Reply-To: <32911.60.241.171.60.1179548939.squirrel@mailbag.nicta.com.au> Message-ID: <2BAAC5E4AF2518459F0AB5D927942047595C38@bur-exch-01.dolby.net> Dear Evan, Your proposed changes should in theory work fine. If you could provide us with feedback whether the rate control operation remains correct, this would be greatly appreciated. Note that when the rate control code was modified in the JM 12.x versions an effort was made to keep the core functionality close to the pre-12.x versions. If you could take a look at the source code of, say, the JM 10.2, you will see the following lines: for (i = 19; i > 0; i--) {// update the history RC_MODE_HISTORY-2 = 19 for (i = 0; i < 20; i++) { RC_MODEL_HISTORY-1 = 20 When we rewrote the rate control source code, we also fixed a large number of problems apart from reorganizing it (see JVT contribution JVT-W042), however we took care not to alter the base rate control algorithm. Indeed, it would be really helpful if we could have feedback on these parameters from the original contributors of this algorithm. Again thank you for pointing this out as it helps improve the H.264/AVC reference software. Best regards, Thanasis -----Original Message----- From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Evan Tan Sent: Friday, May 18, 2024 9:29 PM To: mp4-tech@lists.mpegif.org Subject: [Mp4-tech] Rate control model updating possible bugs? Dear Experts, In rc_quadratic.c - updateRCModel(), the update history loop: for (i = (RC_MODEL_HISTORY-2); i > 0; i--) {// update the history ... } shouldn't it be: for (i = (RC_MODEL_HISTORY-1); i > 0; i--) ? and also in the updateRCModel(): for (i = 0; i < (RC_MODEL_HISTORY-1); i++) { m_rgRejected[i] = FALSE; } shouldn't it be: for (i = 0; i < RC_MODEL_HISTORY; i++) ? the same applies to updateMADModel() Thanks, Evan _______________________________________________ NOTE: Please use clear subject lines for your posts. Include [audio, [video], [systems], [general] or another apppropriate identifier to indicate the type of question you have. Note: Conduct on the mailing list is subject to the Antitrust guidelines found at http://www.mpegif.org/public/documents/vault/mp-out-30042-Antitrust.php ----------------------------------------- This message (including any attachments) may contain confidential information intended for a specific individual and purpose. If you are not the intended recipient, delete this message. If you are not the intended recipient, disclosing, copying, distributing, or taking any action based on this message is strictly prohibited. From Evan.Tan nicta.com.au Tue May 22 02:38:22 2007 From: Evan.Tan nicta.com.au (Evan Tan) Date: Mon May 21 15:46:07 2007 Subject: [Mp4-tech] Rate control model updating possible bugs? In-Reply-To: <2BAAC5E4AF2518459F0AB5D927942047595C38@bur-exch-01.dolby.net> References: <32911.60.241.171.60.1179548939.squirrel@mailbag.nicta.com.au> <2BAAC5E4AF2518459F0AB5D927942047595C38@bur-exch-01.dolby.net> Message-ID: <55521.60.241.171.60.1179761902.squirrel@mailbag.nicta.com.au> Dear Thanasis, I ran the changed code with the foreman sequence and compared it with the original code. The rate control operation appears to be correct after the change was applied, in fact, the selected QPs were exactly the same as the original code. I suspect the change will be more obvious if RC_MODEL_HISTORY is set to a smaller value. I've attached the results and the encoder configuration file as jm12.2_RC_MODEL_HISTORY_* And while we are on the subject of problems with the original rate control code: It appears that the variable 'QPLastPFrame' is not set correctly for the calculation of 'PAverageQp' in rc_init_GOP() when a frame-level rate control is enabled (i.e. BasicUnit==FrameSizeInMbs) and rc_init_GOP() is called more then once (i.e. RC_MODE_0 & RC_MODE_2). I believe this can be resolved by adding a line in updatePparams(): void updatePparams( rc_quadratic *prc, int complexity ) { ... prc->QPLastFrame=prc->m_Qc; <=added } I've also attached the results and the encoder configuration file for this as jm12.2_QPLastPFrame_* Regards, Evan > Dear Evan, > > Your proposed changes should in theory work fine. If you could provide us > with feedback whether the rate control operation remains correct, this > would be greatly appreciated. > > Note that when the rate control code was modified in the JM 12.x versions > an effort was made to keep the core functionality close to the pre-12.x > versions. If you could take a look at the source code of, say, the JM > 10.2, you will see the following lines: > > for (i = 19; i > 0; i--) > {// update the history > > RC_MODE_HISTORY-2 = 19 > > for (i = 0; i < 20; i++) > { > > RC_MODEL_HISTORY-1 = 20 > > When we rewrote the rate control source code, we also fixed a large number > of problems apart from reorganizing it (see JVT contribution JVT-W042), > however we took care not to alter the base rate control algorithm. Indeed, > it would be really helpful if we could have feedback on these parameters > from the original contributors of this algorithm. Again thank you for > pointing this out as it helps improve the H.264/AVC reference software. > > Best regards, > > Thanasis > > > -----Original Message----- > From: mp4-tech-bounces@lists.mpegif.org > [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Evan Tan > Sent: Friday, May 18, 2024 9:29 PM > To: mp4-tech@lists.mpegif.org > Subject: [Mp4-tech] Rate control model updating possible bugs? > > Dear Experts, > > In rc_quadratic.c - updateRCModel(), the update history loop: > for (i = (RC_MODEL_HISTORY-2); i > 0; i--) {// update the history ... > } > > shouldn't it be: > for (i = (RC_MODEL_HISTORY-1); i > 0; i--) ? > > and also in the updateRCModel(): > for (i = 0; i < (RC_MODEL_HISTORY-1); i++) { > m_rgRejected[i] = FALSE; > } > > shouldn't it be: > > for (i = 0; i < RC_MODEL_HISTORY; i++) ? > > > the same applies to updateMADModel() > > Thanks, > Evan > > _______________________________________________ > NOTE: Please use clear subject lines for your posts. Include [audio, > [video], [systems], [general] or another apppropriate identifier to > indicate the type of question you have. > > Note: Conduct on the mailing list is subject to the Antitrust guidelines > found at > http://www.mpegif.org/public/documents/vault/mp-out-30042-Antitrust.php > > ----------------------------------------- > This message (including any attachments) may contain confidential > information intended for a specific individual and purpose. If you > are not the intended recipient, delete this message. If you are > not the intended recipient, disclosing, copying, distributing, or > taking any action based on this message is strictly prohibited. > -------------- next part -------------- A non-text attachment was scrubbed... Name: tests.zip Type: application/x-zip-compressed Size: 37179 bytes Desc: not available Url : /pipermail/mp4-tech/attachments/20070522/8bb92939/tests-0001.bin From ashfiqua03 yahoo.com Mon May 21 12:38:40 2007 From: ashfiqua03 yahoo.com (ashfiqua tahseen) Date: Mon May 21 15:46:13 2007 Subject: [Mp4-tech] Bit rate in H.264 and 3GPP simulator In-Reply-To: <003701c79bad$0b616c10$1100000a@corp.intertrust.com> Message-ID: <699378.20997.qm@web53410.mail.re2.yahoo.com> Hi, Actually I am working on transmission of H.264 over 3G. Can you please tell me the relation of bit rate of JM to the 3GPP simulator? If from JM, I get the bit rate e.g. 259 then it should not be transmitted over the 128kbps channel, right? With regards, AT MPEGIF List Admins wrote: Thanks for your message. Please resubmit it to the list, making sure to send to mp4-tech@lists.mpegif.org and NOT to mp4-tech-owner@lists.mpegif.org Best, the list admins. --------------------------------- From: mailman-bounces@lists.mpegif.org [mailto:mailman-bounces@lists.mpegif.org] On Behalf Of ashfiqua tahseen Sent: Monday, 21 May 2024 00:10 To: mp4-tech-owner@lists.mpegif.org Subject: bit rate in H.264 and 3GP simulator Hi, Actually I am working on transmission of H.264 over 3G. Can you please tell me the relation of bit rate of JM to the 3GPP simulator? If from JM, I get the bit rate e.g. 259 then it should not be transmitted over the 128kbps channel, right? With regards, AT --------------------------------- Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. --------------------------------- Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070521/f1dea712/attachment.html From aleon dolby.com Mon May 21 12:55:13 2007 From: aleon dolby.com (Leontaris, Athanasios) Date: Mon May 21 15:46:17 2007 Subject: [Mp4-tech] Rate control model updating possible bugs? In-Reply-To: <55521.60.241.171.60.1179761902.squirrel@mailbag.nicta.com.au> Message-ID: <2BAAC5E4AF2518459F0AB5D927942047595CEE@bur-exch-01.dolby.net> Dear Evan, I just checked the code more carefully with regards to RC_MODEL_HISTORY and this is my conclusion: The results remain the same because the n_windowSize parameter that defines how many of the statistics are used to update the models is always bounded as follows: updateRCModel(): n_windowSize=imin(n_windowSize,(RC_MODEL_HISTORY-1)); updateMADModel(): n_windowSize=imin(n_windowSize, imin(20, prc->MADm_windowSize + 1)); Which could be changed to n_windowSize=imin(n_windowSize, imin(RC_MODEL_HISTORY-1, prc->MADm_windowSize + 1)); Since RC_MODEL_HISTORY is 21 then both are bounded by 20. Effectively, only slots 0 through 19 are used to update the rate control parameters. It appears that the original authors were a bit too cautious with the number of buffered statistics that were used for the regressions. Therefore, updating the code (including n_windowSize) would have somehow little impact in performance although it would make the code somehow a bit cleaner. Note also that the increase from 20 to 21 may in fact also affect at times the RC behavior negatively since the additional results may not be as correlated. With regards to QPLastPFrame, I agree on your conclusion, although this seems to only affect RC_MODE_0 and RC_MODE_2. Furthermore, it is used in rc_init_GOP() as follows to slightly tweak the average QP: if (prc->PAverageQp > (prc->QPLastPFrame - 2)) prc->PAverageQp--; In other parts of the source code the QPLastPFrame variable is used only in cases where either PicInterlace or MBInterlace are set. So it seems out of place that it is used to tweak PAverageQP in a general sense. Perhaps the solution to this problem is to simply allow the above tweak only when interlaced coding is used, as most probably the original authors intended. Best regards, Thanasis -----Original Message----- From: Evan Tan [mailto:Evan.Tan@nicta.com.au] Sent: Monday, May 21, 2024 8:38 AM To: Leontaris, Athanasios Cc: mp4-tech@lists.mpegif.org Subject: RE: [Mp4-tech] Rate control model updating possible bugs? Dear Thanasis, I ran the changed code with the foreman sequence and compared it with the original code. The rate control operation appears to be correct after the change was applied, in fact, the selected QPs were exactly the same as the original code. I suspect the change will be more obvious if RC_MODEL_HISTORY is set to a smaller value. I've attached the results and the encoder configuration file as jm12.2_RC_MODEL_HISTORY_* And while we are on the subject of problems with the original rate control code: It appears that the variable 'QPLastPFrame' is not set correctly for the calculation of 'PAverageQp' in rc_init_GOP() when a frame-level rate control is enabled (i.e. BasicUnit==FrameSizeInMbs) and rc_init_GOP() is called more then once (i.e. RC_MODE_0 & RC_MODE_2). I believe this can be resolved by adding a line in updatePparams(): void updatePparams( rc_quadratic *prc, int complexity ) { ... prc->QPLastFrame=prc->m_Qc; <=added } I've also attached the results and the encoder configuration file for this as jm12.2_QPLastPFrame_* Regards, Evan > Dear Evan, > > Your proposed changes should in theory work fine. If you could provide > us with feedback whether the rate control operation remains correct, > this would be greatly appreciated. > > Note that when the rate control code was modified in the JM 12.x > versions an effort was made to keep the core functionality close to > the pre-12.x versions. If you could take a look at the source code of, > say, the JM 10.2, you will see the following lines: > > for (i = 19; i > 0; i--) > {// update the history > > RC_MODE_HISTORY-2 = 19 > > for (i = 0; i < 20; i++) > { > > RC_MODEL_HISTORY-1 = 20 > > When we rewrote the rate control source code, we also fixed a large > number of problems apart from reorganizing it (see JVT contribution > JVT-W042), however we took care not to alter the base rate control > algorithm. Indeed, it would be really helpful if we could have > feedback on these parameters from the original contributors of this > algorithm. Again thank you for pointing this out as it helps improve the H.264/AVC reference software. > > Best regards, > > Thanasis > > > -----Original Message----- > From: mp4-tech-bounces@lists.mpegif.org > [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Evan Tan > Sent: Friday, May 18, 2024 9:29 PM > To: mp4-tech@lists.mpegif.org > Subject: [Mp4-tech] Rate control model updating possible bugs? > > Dear Experts, > > In rc_quadratic.c - updateRCModel(), the update history loop: > for (i = (RC_MODEL_HISTORY-2); i > 0; i--) {// update the history ... > } > > shouldn't it be: > for (i = (RC_MODEL_HISTORY-1); i > 0; i--) ? > > and also in the updateRCModel(): > for (i = 0; i < (RC_MODEL_HISTORY-1); i++) { > m_rgRejected[i] = FALSE; > } > > shouldn't it be: > > for (i = 0; i < RC_MODEL_HISTORY; i++) ? > > > the same applies to updateMADModel() > > Thanks, > Evan > > _______________________________________________ > NOTE: Please use clear subject lines for your posts. Include [audio, > [video], [systems], [general] or another apppropriate identifier to > indicate the type of question you have. > > Note: Conduct on the mailing list is subject to the Antitrust > guidelines found at > http://www.mpegif.org/public/documents/vault/mp-out-30042-Antitrust.ph > p > > ----------------------------------------- > This message (including any attachments) may contain confidential > information intended for a specific individual and purpose. If you > are not the intended recipient, delete this message. If you are not > the intended recipient, disclosing, copying, distributing, or taking > any action based on this message is strictly prohibited. > From gouthamnvaidhya gmail.com Tue May 22 10:23:26 2007 From: gouthamnvaidhya gmail.com (goutham vaidhya) Date: Tue May 22 05:04:07 2007 Subject: [Mp4-tech] regarding TNS and Dependent Coupling Message-ID: hi all, I have another doubt regaring TNS & DEPENDENTLY COUPLING BLOCK The CC_DOMAIN flag will tell if dependent coupling occurs before or after TNS block This is as shown in the figure My question is: when cc_domain==1 then The dependent coupling process explained in the function couple_channel() will access the data in an interleaved manner i,e, [g][win][sfb][bin] Could u pls tell if we can do it( when cc_domain ==1). if yes then how. Or is it mentioned anywhere in the document(13818-7:1997). could u pls throw some light on this. tnx in advance.awaiting earliest reply -- Have a NICE day -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070522/4d8fd56d/attachment.html From sriabtsev broadcom.com Mon May 21 23:22:39 2007 From: sriabtsev broadcom.com (Shevach Riabtsev) Date: Tue May 22 05:04:13 2007 Subject: [Mp4-tech] Bottom limit on bin/bit ratio in H.264 Message-ID: <9110732D7E34E5459A92F96AEEDF829E01ECEE05@NT-SJCA-0751.brcm.ad.broadcom.com> Dear experts According to JVT-C038 document, the theoretical upper bound on bin/bit ratio is 64:1. I am interested in the estimation of the bottom (floor) bound of the bin/bit ratio. Because of the adaptivity of CABAC probability models, the bottom limit should be aproximately 1:1 (and the limit is achived on uniformly distributed noise according to Information Theory). Therefore on slices with large number of MBs it is expected the bin/bit ratio is more 1:1 (since the adaptation period will require at most 64 MBs and this enough to tune to the actual source entropy). On the other hand the CABAC adaptivity is not perfect, there are bins coded as bypass (i.e. with the fixed model LPS=0.5), there is end_of_slice_flag syntax element that coded with a fixed non-uniform probability model, albeit its impact is minor. What happens on low-resolution pictures? Indeed, while the probability models are being tuned to the source entropy, the picture is finished. The above considerations cause me to think that the bottom limit of bin/bit ration might be much less 1:1. Are there any JVT documents or papers on the estimation of bottom bound of bin/bit ratio? Did someone experience streams with bin/bit ratio less 1:1? Regards, Shevach Broadcom -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070521/cac53987/attachment.html From Andreas.Schneider codingtechnologies.com Tue May 22 13:31:32 2007 From: Andreas.Schneider codingtechnologies.com (Andreas Schneider) Date: Tue May 22 06:40:06 2007 Subject: [Mp4-tech] [MPEG-4 Audio] Size mismatch when AAC-LC test vector is passed through HE-AAC decoder In-Reply-To: <87B7092E3762F8488DE6C3FEA50E0E3E94A030@EXCHSPZ01.patni.com> Message-ID: Hello Veenit, the size-mismatch you found doesn't seem to be related to the SBR decoder. If I build the reference decoder without SBR the size of the output is not affected. So apparently the reference wave-files provided by ISO have been created with a decoder that removes the first two frames, though, frankly, I have no idea why one would want to do that. Maybe other audio experts can shed more light on this. Best, Andreas mp4-tech-bounces@lists.mpegif.org wrote on 18.05.2024 08:47:55: > Hello Everyone, > > I am working on the HEAAC profile (AAC-LC + SBR) of the MPEG-4 > standard. I am using the Reference Code for the decoder provided by > ISO for this purpose. The version of the Reference Code is: ISO/IEC > 14496-5:2001/Amd.6:2005. The decoder that I am using is located in > the folder "mp4AudVm_Rewrite". > To test the conformance of the "AAC-LC" part of the decoder, I am > passing a reference vector for the AAC-LC AOT that is given by ISO, > through the HEAAC profile decoder. It generates an output file whose > size is larger than the size of the corresponding reference wav file > that is provided by ISO. On viewing the data of the two files, I > find that the test data exactly matches the reference data after a > certain number of bytes are offseted from the start of the test > file. My queries are: > 1. Why would the HE-AAC decoder generate a test output whose size is > larger than the reference output, for the AAC-LC test vector. (the > size is not exactly double so this eliminates the possibility of > this happening due to SBR tool being enabled in the decoder ( since > SBR operates at twice the sampling freq of AAC))? > 2. How can I eliminate this offset being written by the HEAAC > decoder. On removal of these offset bytes at the start of my test > output, my test output would be bit-match with my reference output. > Thanking everyone in advance. Awaiting an early reply. > > Regards, > Veenit Vora. > Patni Computer Systems Ltd., > Unit No. 19, SDF 7, > SEEPZ, Andheri (E), > Mumbai - 400096. > Tel: +91-22-28291454. Ext: 5937 > > > http://www.patni.com > World-Wide Partnerships. World-Class Solutions. > _____________________________________________________________________ > > This e-mail message may contain proprietary, confidential or legally > privileged information for the sole use of the person or entity to > whom this message was originally addressed. Any review, e-transmission > dissemination or other use of or taking of any action in reliance upon > this information by persons or entities other than the intended > recipient is prohibited. If you have received this e-mail in error > kindly delete this e-mail from your records. If it appears that this > mail has been forwarded to you without proper authority, please notify > us immediately at netadmin@patni.com and delete this mail. > _____________________________________________________________________ > _______________________________________________ > NOTE: Please use clear subject lines for your posts. Include [audio, > [video], [systems], [general] or another apppropriate identifier to > indicate the type of question you have. > > Note: Conduct on the mailing list is subject to the Antitrust > guidelines found at http://www.mpegif.org/public/documents/vault/mp- > out-30042-Antitrust.php -- Andreas Schneider Senior Research Engineer mailto:snd@CodingTechnologies.com +49 911 92891 -26 (phone) +49 911 92891 -99 (fax) Coding Technologies GmbH Deutschherrnstr. 15-19 D-90429 Nuernberg, Germany http://www.codingtechnologies.com HRB 17557, Amtsgericht N?rnberg, GF: Dipl.Ing. Martin Dietz (Managing Director) From ralph.sperschneider iis.fraunhofer.de Wed May 23 13:44:12 2007 From: ralph.sperschneider iis.fraunhofer.de (Ralph Sperschneider) Date: Wed May 23 07:10:08 2007 Subject: [Mp4-tech] Re: regarding TNS and Dependent Coupling In-Reply-To: References: Message-ID: <46541AFC.6050709@iis.fraunhofer.de> goutham vaidhya wrote: > hi all, > > I have another doubt regaring TNS & DEPENDENTLY COUPLING BLOCK > > The CC_DOMAIN flag will tell if dependent coupling occurs before or > after TNS block > This is as shown in the figure > > My question is: > > when cc_domain==1 then > The dependent coupling process explained in the function > couple_channel() > will access the data in an interleaved manner i,e, [g][win][sfb][bin] > Could u pls tell if we can do it( when cc_domain ==1). if yes then how. > Or is it mentioned anywhere in the document(13818-7:1997). > could u pls throw some light on this. > > tnx in advance.awaiting earliest reply > Dear Goutham Vaidhya, I am not sure I understand your problem. To my understanding, the representation of the spectrum should not be affected by the TNS block. Thus, the coupling routine should behave similar independent whether it is called before or after the TNS routine. Best regards, Ralph -- Dipl.-Ing. Ralph Sperschneider | Phone: +49 9131 776 344 Fraunhofer IIS | Fax: +49 9131 776 398 Am Wolfsmantel 33 | mailto:ralph.sperschneider@iis.fraunhofer.de D 91058 Erlangen | http://www.iis.fraunhofer.de/amm/ From yelite993 163.com Wed May 23 11:29:09 2007 From: yelite993 163.com (=?GBK?B?0ac=?=) Date: Wed May 23 08:28:06 2007 Subject: [Mp4-tech] Help: How to generate aac content with LATM header from aac content with ADTS header Message-ID: <20473900.3087611179887349324.JavaMail.coremail@bj163app32.163.com> hello all,Anybody who knows how to generate aac audio with LATM header from aac data with ADTS header? I can get some information which audioSpecificConfig() included in LATM header needs from ADTS header, such as audioDecoderType, samplingFreqencyIndex, samplingFrequency, channelConfiguration. But how can I fill the GASpecificConfig()/CelpSpecificConfig() included in audioSpecificConfig()..., I can't get the corresponding data form ADTS header?Thanks in advance, Yelite -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070523/3ab3369d/attachment.html From gilberto vista-silicon.com Wed May 23 09:37:28 2007 From: gilberto vista-silicon.com (Gilberto Rodriguez) Date: Thu May 24 06:40:06 2007 Subject: [Mp4-tech] [h264]-job offer. Message-ID: <003001c79d04$d619e600$2301a8c0@MERCURY> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: job_offers_video.doc Type: application/msword Size: 26624 bytes Desc: not available Url : /pipermail/mp4-tech/attachments/20070523/e49249dd/job_offers_video-0001.doc From kavita.chachadi1 wipro.com Thu May 24 15:29:12 2007 From: kavita.chachadi1 wipro.com (kavita.chachadi1@wipro.com) Date: Thu May 24 06:40:13 2007 Subject: [Mp4-tech] Rate control model(In H.264 reference software JM 11.0 0r 12.2) ? In-Reply-To: <2BAAC5E4AF2518459F0AB5D927942047595C38@bur-exch-01.dolby.net> Message-ID: <7B94B345F7956B468CD8E573655527D7765774@BLR-EC-MBX02.wipro.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/octet-stream Size: 3682 bytes Desc: oledata.mso Url : /pipermail/mp4-tech/attachments/20070524/991c975b/attachment-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/x-ms-wmz Size: 704 bytes Desc: image001.wmz Url : /pipermail/mp4-tech/attachments/20070524/991c975b/attachment-0004.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 363 bytes Desc: image002.gif Url : /pipermail/mp4-tech/attachments/20070524/991c975b/attachment-0004.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/x-ms-wmz Size: 972 bytes Desc: image003.wmz Url : /pipermail/mp4-tech/attachments/20070524/991c975b/attachment-0005.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 981 bytes Desc: image004.gif Url : /pipermail/mp4-tech/attachments/20070524/991c975b/attachment-0005.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/x-ms-wmz Size: 541 bytes Desc: image005.wmz Url : /pipermail/mp4-tech/attachments/20070524/991c975b/attachment-0006.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 166 bytes Desc: image006.gif Url : /pipermail/mp4-tech/attachments/20070524/991c975b/attachment-0006.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/x-ms-wmz Size: 667 bytes Desc: image008.wmz Url : /pipermail/mp4-tech/attachments/20070524/991c975b/attachment-0007.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 381 bytes Desc: image009.gif Url : /pipermail/mp4-tech/attachments/20070524/991c975b/attachment-0007.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 684 bytes Desc: image010.jpg Url : /pipermail/mp4-tech/attachments/20070524/991c975b/attachment-0001.jpe From ralph.sperschneider iis.fraunhofer.de Thu May 24 16:00:07 2007 From: ralph.sperschneider iis.fraunhofer.de (Ralph Sperschneider) Date: Thu May 24 09:10:06 2007 Subject: [Mp4-tech] Re: regarding TNS and Dependent Coupling In-Reply-To: References: <46541AFC.6050709@iis.fraunhofer.de> Message-ID: <46558C57.3060102@iis.fraunhofer.de> goutham vaidhya wrote: > hi , > Is these things right or wrong pls tell me. > 1) The input to the Dependent coupling block should it be interleaved > i,e, in coeff[g][win][sfb][bin]? > 2) The input to the TNS block should be deinterleaved i,e,, > coeff[win][bin] > In the function (given in standard 13818:1997) > --> couple_channel(source_spectrum[],dest_spectrum[],gain_list_index) > here the source_spectrum[] is what we get from > individual_channel_stream() from CCE right? > the dest_specrtum[] is what we get from the TNS block( assume > TNS block occurs) > What the spectrum we get from the TNS block is in the form of > coeff[win][bin] > But in the dependent coupling computation we access the > spectral coeffs in coeff[g][win][sfb][bin] right? > > i want to know if we can access the spectral values directly Or > is there some modifications that has to be applied to the function > couple_channel() > > awaiting earliest reply.Tnx > Dear Goutham Vaidhya, the issue you describe is an implementation issue. You might want to interleave and deinterleave the spectrum several times or you simply calculate the proper index depending on the kind of interleaving required in a particular signal processing block. The latter is done in the reference software. I already provided you with the appropriate link (http://standards.iso.org/ittf/PubliclyAvailableStandards/c039486_ISO_IEC_13818-5_2005_Reference_Software.zip). I suggest that you have a closer look into this software (in aacDec/src/adifdec.c, line 740ff, the functions coupling() and tns() are called). Best regards, Ralph -- Dipl.-Ing. Ralph Sperschneider | Phone: +49 9131 776 344 Fraunhofer IIS | Fax: +49 9131 776 398 Am Wolfsmantel 33 | mailto:ralph.sperschneider@iis.fraunhofer.de D 91058 Erlangen | http://www.iis.fraunhofer.de/amm/ From jianpengdong yahoo.com Thu May 24 21:39:13 2007 From: jianpengdong yahoo.com (James (Jianpeng) Dong) Date: Fri May 25 03:40:09 2007 Subject: [Mp4-tech] Rate control model(In H.264 reference software JM 11.0 0r 12.2) ? In-Reply-To: <7B94B345F7956B468CD8E573655527D7765774@BLR-EC-MBX02.wipro.com> Message-ID: <102511.38342.qm@web43146.mail.sp1.yahoo.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 363 bytes Desc: not available Url : /pipermail/mp4-tech/attachments/20070524/e889c40c/attachment-0004.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 981 bytes Desc: not available Url : /pipermail/mp4-tech/attachments/20070524/e889c40c/attachment-0005.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 166 bytes Desc: not available Url : /pipermail/mp4-tech/attachments/20070524/e889c40c/attachment-0006.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 381 bytes Desc: not available Url : /pipermail/mp4-tech/attachments/20070524/e889c40c/attachment-0007.gif From kavita.chachadi1 wipro.com Fri May 25 10:29:27 2007 From: kavita.chachadi1 wipro.com (kavita.chachadi1@wipro.com) Date: Fri May 25 03:40:14 2007 Subject: [Mp4-tech] Rate control model(In H.264 reference software JM 11.0 0r 12.2) ? In-Reply-To: <102511.38342.qm@web43146.mail.sp1.yahoo.com> Message-ID: <7B94B345F7956B468CD8E573655527D7765776@BLR-EC-MBX02.wipro.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 363 bytes Desc: image001.gif Url : /pipermail/mp4-tech/attachments/20070525/7deb7b13/attachment-0004.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 981 bytes Desc: image002.gif Url : /pipermail/mp4-tech/attachments/20070525/7deb7b13/attachment-0005.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 166 bytes Desc: image003.gif Url : /pipermail/mp4-tech/attachments/20070525/7deb7b13/attachment-0006.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 381 bytes Desc: image004.gif Url : /pipermail/mp4-tech/attachments/20070525/7deb7b13/attachment-0007.gif From aleon dolby.com Thu May 24 22:05:39 2007 From: aleon dolby.com (Leontaris, Athanasios) Date: Fri May 25 03:40:20 2007 Subject: [Mp4-tech] Rate control model(In H.264 reference software JM 11.0 0r 12.2) ? In-Reply-To: <7B94B345F7956B468CD8E573655527D7765776@BLR-EC-MBX02.wipro.com> Message-ID: <2BAAC5E4AF2518459F0AB5D927942047627259@bur-exch-01.dolby.net> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 363 bytes Desc: image001.gif Url : /pipermail/mp4-tech/attachments/20070524/34714b98/attachment-0004.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 981 bytes Desc: image002.gif Url : /pipermail/mp4-tech/attachments/20070524/34714b98/attachment-0005.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 166 bytes Desc: image003.gif Url : /pipermail/mp4-tech/attachments/20070524/34714b98/attachment-0006.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 381 bytes Desc: image004.gif Url : /pipermail/mp4-tech/attachments/20070524/34714b98/attachment-0007.gif From yong.xin radisys.com Fri May 25 09:37:16 2007 From: yong.xin radisys.com (Yong Xin) Date: Mon May 28 09:40:08 2007 Subject: [Mp4-tech] [general]: brand name case sensitive? Message-ID: <02f501c79ee2$92f3d7c0$6d0c14ac@radisys.com> Hi, Is the brand name specified in the file type box 'ftyp' case senstive? For example, is "3gp7" equivalent to "3GP7"? Thanks, Yong From sriabtsev broadcom.com Sun May 27 01:34:25 2007 From: sriabtsev broadcom.com (Shevach Riabtsev) Date: Mon May 28 09:40:16 2007 Subject: [Mp4-tech] On intra_chroma_pred_mode Message-ID: <9110732D7E34E5459A92F96AEEDF829E01ECF30E@NT-SJCA-0751.brcm.ad.broadcom.com> Dear experts In the H.264 standard apparently there is an misunderstanding concerning intra_chroma_pred_mode. On the one hand in 7.4.5.1 section is written: intra_chroma_pred_mode specifies the type of spatial prediction used for chroma in macroblocks using Intra_4x4 or Intra_16x16 prediction, as shown in Table 7-16. The value of intra_chroma_pred_mode shall be in the range of 0 to 3, inclusive. >From the above clause one cand derive that intra_chroma_pred_mode is not used for Intra8x8 MB types. On the other hand the flow-chart specified in 7.3.5.1 reveals that intra_chroma_pred_mode is transmitted for all Intra MBs (i.e. Intra4x4, Intra16x16 and Intra8x8). I think an omission occured in the formulation of intra_chroma_pred_mode, it should be intra_chroma_pred_mode specifies the type of spatial prediction used for chroma in macroblocks using Intra_4x4 or Intra_16x16 or Intra8x8 prediction Regards, Shevach Broadcom -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070527/e17572de/attachment.html From devilal gmail.com Wed May 30 18:24:21 2007 From: devilal gmail.com (Devilal) Date: Thu May 31 10:04:09 2007 Subject: [Mp4-tech] [Audio] PS decoding Message-ID: Hi, In the case of Parametric Stereo(PS) in HE-AAC, we get the bs_extended_data(1 bit) flag set to 1 and then bs_extension_id (2 bits) is read. Then the sbr_extension() is called, in which if bs_extension_id read is 2 (corresponding to EXTENSION_ID_PS) then we decode PS data ( ps_data() ) . All this parsing is done in the function sbr_single_channel_element () which in turn is called in sbr_data(), which is called independently from the fact that we get bs_header_flag = 0 or 1. Received bs_header_flag can be 1 with the frame( in that case we do HF Generation, HF Adjustment and then QMF Synthesis) OR can be 0 with the frame ( in that case we do upsampling by applying QMF Synthesis and we bypass HF Generation and HF Adjustment). In some of the implementations I have gone through (like 3gpp's fixed point and ISO's floating point reference code for HE-AAC), the sbr_data() is called only if the sbr header flag is set (bs_header_flag = 1 ) in the incoming frame. And hence, if the sbr header flag read is not set (bs_ header_flag = 0 ) then the decoder does not care about bs_extended_data and bs_extension_id and hence ps_data is not decoded. So, the decoder does not decode PS data and does not apply all the routines related to PS (like hybrid analysis, synthesis , decorrelation, rotaion etc. in the QMF Synthesis) and it simply does upsampling. In the case of bs_header_flag = 0 (or when we do not decode PS data) , we apply QMF Synthesis only once . On the other hand when bs_header_flag = 1 (or when we decode PS data) , we apply QMF Synthesis twice, first time with PS Active flag(so that it goes through PS routines and generate one channel data) and second time without PS flag(so, it apply QMF Synthesis as if there is no PS present in the stream and generate the second channel data). I am not able to understand how the second channel is generated in the first case when bs_header_flag = 0 and we do not do PS decoding. Please correct me if I am missing anything here. -- Regards, Devilal -------------------- Mobile: +91-9986423985 email: devilal@gmail.com ------- -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070530/d5c2931c/attachment.html From cpinaki rediffmail.com Thu May 31 12:40:25 2007 From: cpinaki rediffmail.com (Pinaki S. Chanda) Date: Thu May 31 10:04:18 2007 Subject: [Mp4-tech] AAC - dynamic range control Message-ID: <20070531114025.31091.qmail@webmail70.rediffmail.com> Dear group, This is regarding the excl_chn_mask[] bits in the dynamic-range_info() of the AAC bit stream. Assume the excl_chn_mask[] bit is set for a channel in the AAC bit stream. Does that mean? 1. we are not interested to change the DRC values (no. of bands, gain etc) for this channel using the recently transmitted DRC parameters but the DRC processing (spectral line multiplication) must go on this channel with the previously transmitted values. or 2. we would like to stop DRC processing for this channel from now on till we get the DRC parameters for this channel in a later frame. or 3. we would like to stop DRC processing (spectral line multiplication) on this frame for this channel but continue DRC processing from next frame using the previous value. Which one is correct ? Thanks and regards, Pinaki -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20070531/9a02a768/attachment.html