From garysull windows.microsoft.com Tue Oct 3 11:17:00 2006
From: garysull windows.microsoft.com (Gary Sullivan)
Date: Tue Oct 3 13:28:08 2006
Subject: [Mp4-tech] [H.264] A question about the scaling list syntax
In-Reply-To: <000801c6e46b$db706e50$6497460a@china.huawei.com>
Message-ID: <03CB47D9C3F8074498E4653F814D6E8F0252E98C@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
It sounds like you may be misunderstanding the purpose of the "Flat"
arrays. We never change the values in those arrays. Those arrays just
determine the value that we put into the scaling list when
seq_scaling_matrix_present_flag is equal to 0. Nothing in the bitstream
ever affects the entries in the "Flat" arrays. It may be helpful to
read the reference software source code to understand this.
Best Regards,
Gary Sullivan
________________________________
From: mp4-tech-bounces@lists.mpegif.org
[mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Tan Rui --
Huawei
Sent: Saturday, September 30, 2023 1:39 AM
To: mpeg 4 mail-list
Subject: [Mp4-tech] [H.264] A question about the scaling list
syntax
Hi, all experts, when I read the protocol about the
seq_scaling_matrix_present_flag, I find some questions as the following:
seq_scaling_matrix_present_flag equal to 1 specifies that the
flags seq_scaling_list_present_flag[ i ] for i = 0..7 are
present. seq_scaling_matrix_present_flag equal to 0 specifies
that these flags are not present and the sequence-level
scaling list specified by Flat_4x4_16 shall be inferred for i =
0..5 and the sequence-level scaling list specified by
Flat_8x8_16 shall be inferred for i = 6..7. When
seq_scaling_matrix_present_flag is not present, it shall be inferred to
be equal to 0.
The scaling lists Flat_4x4_16 and Flat_8x8_16 are specified as
follows:
Flat_4x4_16[ i ] = 16, with i = 0..15, ( 7-6)
Flat_8x8_16[ i ] = 16, with i = 0..63. ( 7-7)
[ Question : In the first paragraph, we can get the following
understanding:
for(i=0; i<16; i++) {
if seq_scaling_list_present_flag[i] == 1 {
if(i<6) {
//According to each
seq_scaling_list_present_flag,
//There will be 16 scaling list elements, i.e.,
//Flat_4x4_16[i], with i = 0..15.
//In the end, there will be 6x16=96 Flat_4x4_16
elements for all. Is that true?
}
else {
//There will be 64 scaling list elements, i.e.,
//Flat_8x8_16[i], with i = 0..63
}
}
else {
//There will not be any Flat_8x8_16 and Flat_4x4_16
elements.
}
}
But I can not find any further usage of the Flat_4x4_16 and
Flat_8x8_16. Can you give me some clue?
By the way, I find some syntax comments in the 7.3.2.1.1 just
like the following:
scaling_list( scalingList, sizeOfScalingList,
useDefaultScalingMatrixFlag ) {
lastScale = 8
nextScale = 8
for( j = 0; j < sizeOfScalingList; j++ ) {
if( nextScale != 0 ) {
delta_scale
nextScale = ( lastScale + delta_scale + 256 ) % 256
useDefaultScalingMatrixFlag = ( j = = 0 && nextScale
= = 0 )
}
scalingList[ j ] = ( nextScale = = 0 ) ? lastScale :
nextScale
lastScale = scalingList[ j ]
}
}
I wonder that the assignment for the useDefaultScalingMatrixFlag
variable. It mean that when i==0 and nextScale==0,
the useDefaultScalingMatrixFlag will be 1, doesn't it? When
useDefaultScalingMatrixFlag is equal to 1, which scaling
list variable will use the default value? I can not find any
assignments in the protocol.
]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061003/6c3d3dbc/attachment.html
From mafie att.net Tue Oct 3 08:28:03 2006
From: mafie att.net (Farhad Mafie)
Date: Tue Oct 3 16:10:06 2006
Subject: [Mp4-tech] Don't Miss Early Bird Registration--The 4th
International System-on-Chip (SoC) Conference and Exhibit
www.SoCconference.com
Message-ID: <008501c6e6f8$24235110$0131480c@D435CC31>
The Most Innovative and Affordably Priced Chip Design Technology
Conference of the Year
Don't Miss Out!
Special Discounts for Students and IEEE/ACM Members
4th International System-on-Chip (SoC)
Conference & Exhibit
November 1 & 2, 2006 - Radisson Hotel Newport Beach, California
Register TODAY & Save!
For Conference Information & Early Bird
Registration, Please Visit:
www.SoCconference.com
Leading-edge Companies, Universities, and Organizations will be
presenting their latest System-on-Chip (SoC), ASIC, ASSP, FPGA, and
Foundry technologies and products in this informative and exciting
Conference & Exhibit.
Participating Companies & Organizations (a partial list): Fujitsu,
Samsung, Micron Technology, Synplicity, Sonics, Tensilica, IBM,
Intel, Toshiba, Cadence, Altera, Broadcom, Tohoku University, ARM,
Texas Instruments, Wireless Design & Development, IQ , Jazz
Semiconductor, The Spirit Consortium, Synopsys, STMicro, CISCO
Systems, Ambric, Connex, LogicVision, Innovative Silicon, Pacific
Northwest National Laboratory, EMA Design Automation, EuroAsia
Semiconductor, National Semiconductor, CMP, Silistix, ViASIC, CSU
Fullerton, UC Irvine, Magma, Nascentric, First Silicon, EETimes ,
Taylor & Francis - CRC Press, San Jose State University, Silicon Hive,
EDN , CoWare, RWTH Aachen University, MEMS Manufacturing, MPEG
Forum, OCP-IP, Circuit Cellar , Virage Logic, DSP & FPGA, Adaptive
Labs, Sequence Design, Takumi Technology, CSU Long Beach, AeA,
Savant Company Inc., Chapman University, Target Compiler Technologies,
IEEE OC, VaST Systems Technology, PalmChip, EEMBC, Platinum
Associates, Advanced Packaging, Semiconductor Online , Embedded
Computing , Open Systems Initiatives, OCBC, VSIA Alliance, and many
more.
Five Informative Tracks
* New CPU and DSP Cores for Complex SoC Applications
* Network-on-Chip (NoC) Architectures for Complex SoCs
* Memory sub-system Advances and Trends
* Semiconductor Trends and New Design Approaches for Complex SoCs
* EDA Tools and Design Methodologies for Complex SoCs
Five Outstanding Keynote Speakers
* Dr. Dominik Schmidt, & Arup Gupta, Intel.
* Dr. Juan-Antonio Carballo, IBM.
* Dr. Tadao Nakamura, Tohoku University, Japan.
* Ana Molnar Hunter, VP of Technology, Samsung.
* Dr. Mehdi Hatamian, VP of Engineering, Broadcom.
Two Challenging Panel Discussions
* Architectural and Performance-Related Challenges for Complex
SoCs. Moderator: Ron Wilson, Executive Editor, EDN Worldwide.
* EDA Challenges for Complex SoC and ASIC Designs. Moderator: Dave
Bursky, Semiconductor Editor, EETimes Magazine.
One Night of Tabletop Exhibitions (November 1, 2006, 4:30 PM - 8:30 PM)
* Sign up online for complimentary exhibition passes (for November
1, 2006, Exhibition night only).
* Meet one-on-one with SoC experts representing a wide variety of
companies
* Have your toughest questions answered by leading-edge companies!
* Discuss development tools and chip design challenges with
SoC/ASIC/Foundry experts
* Connect with companies offering practical solutions to your
design challenges
* "Seeing Is Believing!" See demos of EDA tools from leading-edge
EDA vendors
Why You Should Attend
* Discuss 65nm and post-65nm challenges for SoC/ASIC/ASSP/FPGA
designs
* Learn about the latest configurable CPUs, Processors, and DSPs
cores
* Gain insight into memory subsystems design for complex
SoC/ASIC/ASSP/FPGA designs
* Learn about the new trends and future direction of
System-on-Chip
* Network with the leaders driving SoC technology during the
conference & exhibit
* Learn about the latest EDA Tools and design techniques for
Nanometer SoCs
Who Should Attend
* Chip designers
* Design engineers
* ASIC/SoC/ASSP/FPGA designers
* EDA Developers
* System architects
* IP Developers
* Hardware engineers
* System platform designers
* Executives and business decision-makers in technology companies
* Technical marketing/sales professionals
* Technology and business analysts
* Engineering professors and students
* Anyone involved with ASIC, SoC, ASSP, Foundry, and FPGA design,
development, planning, promotion, and procurement
The 4th International System-on-Chip (SoC) Conference & Exhibit is the
year's most important, most informative technical conference for the
chip design community. In collaboration with major industry enablers
and top academic experts, it addresses the latest technologies and
products from vendors in semiconductor, EDA, IP, CPUs/DSPs, Memories,
NoC, Multi-core, etc.
Special Discount for Students and IEEE & ACM Members
The Most
Informative and Targeted SoC & ASIC Conference & Exhibit
Event of the
Year!
Don't Miss Out!
Register Today and Save!
http://www.SoCconference.com/
Please share this message with interested colleagues!
Got a registration question?
Please email: SoC@SavantCompany.com
www.SoCconference.com
To unsubscribe: Please send an email to
SoC-News@savantcompany.com with
"Remove" in the subject line.
Copyright ? 2005 by Savant Company Inc. PO Box 51330, Irvine, CA 92619,
U.S.A. All rights reserved. All names contained herein are the
trademarks of their respective holders.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061003/83f0bb0b/attachment-0001.html
From dmitriy graphics.cs.msu.ru Fri Oct 6 04:03:40 2006
From: dmitriy graphics.cs.msu.ru (Dmitriy Vatolin)
Date: Fri Oct 6 05:40:07 2006
Subject: [Mp4-tech] New MSU video quality metrics are released in open source
Message-ID: <701300361.20061006030340@graphics.cs.msu.ru>
Hello!
This summer we release our MSU Video Quality Metric Tool 1.2 with
plug-ins support. Main idea was to simplify update of research metrics
and third party metrics usage.
During last months we have small anniversary - total number of metrics
downloads from official page become bigger than 25000.
Also 2 days ago we are released several metric plug-in's in source code
under LGPL:
* MSU Brightness Independent PSNR.
Main idea: It's common situation during testing (we made big
amount of tests), when codec change brightness a little. This metric
is compensate such changes for ANY brightness modification (up
to negative frame).
http://www.compression.ru/video/quality_measure/metric_plugins/bi-psnr_en.htm
* MSU Brightness Flicking Metric.
Main idea: Simple flicking calculation (can be enhanced).
http://www.compression.ru/video/quality_measure/metric_plugins/bfm_en.htm
* MSU Drop Frame Metric.
Main idea: Some codecs on low bitrates drop more frames, some -
less. It's good idea to calculate not only PSNR/SSIM but also number
of dropped frames as codec characteristic. Also this metric is
useful for capture device/program evaluation.
http://www.compression.ru/video/quality_measure/metric_plugins/dfm_en.htm
Now it's easy to add new metric to the tool.
For example:
* Faster metrics (using MMX-SSE2, HW acceleration, DirectShow,
Shaders based GPU acceleration and etc)
* New special blurring (blocking, interlacing, etc) measures
* New perfect formal metrics (again better than PSNR)
Hope with metrics plugins we will help to develop new good metrics
for video fun's and pro's.
Any ideas about new future metrics development are welcome!
Yours,
Dr. Vatolin
From mafie att.net Thu Oct 5 23:08:11 2006
From: mafie att.net (Farhad Mafie)
Date: Fri Oct 6 05:40:20 2006
Subject: [Mp4-tech] Today: Deadline for Early Bird Registration (Save $200 )
-- The 4th International System-on-Chip (SoC) Conference and Exhibit
Message-ID: <002e01c6e905$6de377d0$0b31480c@D435CC31>
The Most Innovative and Affordably Priced SoC, ASIC, FPGA, ASSP, and
Foundry Technology Conference of the Year
Don't Miss Out!
-------------------------------------------------------
The 4th International System-on-Chip (SoC) Conference and Exhibit
Today: Last Chance to Save $200 - Deadline for Early Bird Registration
LEARN and NETWORK
http:// www.SoCconference.com
-------------------------------------------------------
Please share this message with interested colleagues!
-------------------------------------------------------
Conference: November 1 and 2, 2006 (8:00 am - 6:00 pm)
Tabletop Exhibits: November 1, 2023 (4:30 pm - 8:30 pm)
Radisson Hotel Newport Beach, CA (Next to John Wayne Airport)
More information:
http:// www.SoCconference.com
-------------------------------------------------------
Leading-edge Companies, Universities, and Organizations will be
presenting their latest System-on-Chip (SoC), ASIC, ASSP, FPGA, and
Foundry technologies and products in this informative and exciting
Conference & Exhibit.
-------------------------------------------------------
Why You Should Attend
Discuss 65nm and post-65nm challenges for SoC/ASIC/ASSP/FPGA designs
Learn about the latest configurable CPUs, Multi-Cores, and DSPs cores
Gain insight into memory subsystems design for complex
SoC/ASIC/ASSP/FPGA designs
Explore the new Network-on-Chip (NoC) design methodologies and
approaches
Learn about the new trends and future direction of System-on-Chip
Discuss high speed design challenges with experts developing
high-performance I/O devices
Network with the leaders driving SoC, ASIC, FPGA, Foundry technology
during the conference & exhibit
Discover the latest embedded memory technologies
Learn about the latest EDA Tools and design techniques for Nanometer
SoCs
And much, much more
-------------------------------------------------------
Who Should Attend:
Design engineers
ASIC/SoC/ASSP/FPGA designers
Chip designers
EDA Developers
System architects
Industry analysts
IP Developers
Hardware engineers
System platform designers
C-Level Executives and business decision-makers in technology companies
Technical marketing/sales professionals
Technology analysts
Engineering professors and students
Anyone involved with ASIC, SoC, ASSP, Foundry, and FPGA design,
development, planning, promotion, and procurement
-------------------------------------------------------
The 4th International System-on-Chip (SoC) Conference & Exhibit is the
year's most important, most informative technical conference for the
chip design community. In collaboration with major industry enablers
and top academic experts, it addresses the latest technologies and
products from vendors in semiconductor, EDA, IP, CPUs/DSPs, Memories,
NoC, Multi-core, etc.
-------------------------------------------------------
Register Today and Save!
http://www.SoCconference.com/
Please share this message with interested colleagues!
Got a registration question?
Please email: SoC@SavantCompany.com
-------------------------------------------------------
-------------------------------------------------------
To unsubscribe: Please send an email to
SoC-News@savantcompany.com with
"Remove" in the subject line.
C 2006 Savant Company Inc. PO Box 51330, Irvine, CA 92619, U.S.A. All
rights reserved. All names contained herein are the trademarks of their
respective holders.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061005/d6c72217/attachment.html
From pedersen.ronny gmail.com Fri Oct 6 18:21:05 2006
From: pedersen.ronny gmail.com (Ronny Pedersen)
Date: Sun Oct 8 19:10:05 2006
Subject: [Mp4-tech] [H.264] Inverse 4x4 transform and the 1-D transform order
In-Reply-To: <2a03553f0610060429o53e7c19ft98ebc6614f9fc358@mail.gmail.com>
References: <2a03553f0610060429o53e7c19ft98ebc6614f9fc358@mail.gmail.com>
Message-ID: <2a03553f0610060821u1110cd03t43984d4868c093e7@mail.gmail.com>
Hi,
The H.264 specification states that first each column of the 4x4
block should be processed with a 1-d inverse transform and then the
rows should be processed with the same inverse transformations, but
as I can see it the H.264/AVC reference decoder processes rows and columns
in the opposite order.
I guess this will make a difference in the result since the 1-d transforms
performes a left shift (divide by two) on two of the input coefficients?
What is the correct order in which to apply the 1-d inverse transforms to
the 4x4 block?
Regards,
Ronny
From fredrik.olofsson axis.com Fri Oct 6 21:24:58 2006
From: fredrik.olofsson axis.com (Fredrik Olofsson)
Date: Sun Oct 8 19:10:11 2006
Subject: [Mp4-tech] JSVM software up to date?
Message-ID: <20061006182458.GB19512@pcfredriko.se.axis.com>
Hello.
Is the JSVM software accessible by cvs from:
garcon.ient.rwth-aachen.de:/cvs/jvt
up to date with the latest Scalable Video Coding amendement (document
N8241)?
Or is there a more recent amendment proposal or software available?
Thanks
/Fredrik
From garysull windows.microsoft.com Mon Oct 9 13:31:54 2006
From: garysull windows.microsoft.com (Gary Sullivan)
Date: Mon Oct 9 15:40:06 2006
Subject: [Mp4-tech] [H.264] Inverse 4x4 transform and the 1-D transform
order
In-Reply-To: <2a03553f0610060821u1110cd03t43984d4868c093e7@mail.gmail.com>
Message-ID: <03CB47D9C3F8074498E4653F814D6E8F0268E072@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
Ronny (et al),
You're not correct about what the text of the standard says. Refer to
subclause 8.5.10, which says:
"First, each (horizontal) row of scaled transform coefficients is
transformed using a one-dimensional inverse transform as follows." ...
"Then, each (vertical) column of the resulting matrix is transformed
using the same one-dimensional inverse transform as follows."
Perhaps you're looking at an old draft. Make sure you have the actual
current standard. That can save you some headaches. To get the correct
document, use the following process:
Step 1: Register for the "3 Free" program at
http://ecs.itu.ch/cgi-bin/ebookshop
Step 2: Download the spec from
http://www.itu.int/rec/T-REC-H.264
Best Regards,
Gary Sullivan
+> -----Original Message-----
+> From: mp4-tech-bounces@lists.mpegif.org
+> [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of
+> Ronny Pedersen
+> Sent: Friday, October 06, 2023 8:21 AM
+> To: mp4-tech@lists.mpegif.org
+> Subject: [Mp4-tech] [H.264] Inverse 4x4 transform and the
+> 1-D transform order
+>
+> Hi,
+>
+> The H.264 specification states that first each column of the 4x4
+> block should be processed with a 1-d inverse transform and then the
+> rows should be processed with the same inverse transformations, but
+> as I can see it the H.264/AVC reference decoder processes
+> rows and columns
+> in the opposite order.
+>
+> I guess this will make a difference in the result since the
+> 1-d transforms
+> performes a left shift (divide by two) on two of the input
+> coefficients?
+>
+> What is the correct order in which to apply the 1-d inverse
+> transforms to
+> the 4x4 block?
+>
+> Regards,
+> Ronny
+> _______________________________________________
+> NOTE: Please use clear subject lines for your posts. Include
+> [audio, [video], [systems], [general] or another
+> apppropriate identifier to indicate the type of question you have.
+>
+> Note: Conduct on the mailing list is subject to the
+> Antitrust guidelines found at
+> http://www.mpegif.org/public/documents/vault/mp-out-30042-Ant
+> itrust.php
+>
From shenyueshi gmail.com Mon Oct 9 10:33:30 2006
From: shenyueshi gmail.com (Yueshi Shen)
Date: Tue Oct 10 09:46:08 2006
Subject: [Mp4-tech] a few questions with regard to MPEG-2 AAC
Message-ID:
Dear AAC experts,
I wish to ask your advices on a few questions with regard to MPEG-2 AAC
here, and the MPEG-2 AAC standard I've got is the ISO/IEC 13818-7:2004 (also
the Australian Standard ISO/IEC13818.7-2005).
1) crc_check
In page 42, the spec says "CRC error detection data generated as
described in ISO/IEC 11172-3, subclause 2.4.3.1". However, in the
corresponding section of the MPEG-1 Audio, apart from the CRC-check
calculation algorithm, the protected fields are also defined (and they
differ for Layer I, II, and III). So I am wondering what is the CRC-check
protected range for MPEG-2 AAC?
2) adts_buffer_fullness
In page 45, the mechanism of generating adts_buffer_fullness is
described. I guess it's a similar idea as VBV buffer in MPEG video, so it's
a control mechanism for output's timing. My question is how this
information is used in a typical AAC decoder? If AAC is carried in the
MPEG-2 transport stream, is the adts_buffer_fullness' functionality
completely overridden by PTS/DTS/PCR/SCR?
3) padding audio frames
One of the fill_element()'s usages is to keep every audio frame same
length. In order to pad an audio frame to a particular length, whose value
is encoded in the frame header, I image there are two ways: a) write an
id_syn_ele of ID_END and pad all the rest bytes to 0; b) write a proper
fill_element() (i.e., fill_nibble, fill_byte, other_bits) and write ID_END
until the last byte. Is the first approach legal, and has the same effect
as the second one?
I apologise if you find the above questions are too naive, and I will be
greatly appreciated if you can help me with any information.
Sincerely yours
Yueshi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061009/b1f06063/attachment-0001.html
From apulicat uci.edu Mon Oct 9 09:16:20 2006
From: apulicat uci.edu (apulicat@uci.edu)
Date: Tue Oct 10 09:46:13 2006
Subject: [Mp4-tech] Mpeg4 codec with FGS
Message-ID: <2961.128.200.71.7.1160406980.squirrel@webmail.uci.edu>
Hi,
I am looking for an MPEG-4 codec offering continuous progressiveness
(Fine Granularity Scalability). I found out that this feature is
available in MPEG-4 Part 2 Momusys codec running on Linux. But I am
not able to get hold of that codec. Can any of you help me out in
getting that codec or any other codec which offers the same
functionality (Fine Granularity Scalability)?
Thanks
Anand
From arhold gmail.com Tue Oct 10 00:48:33 2006
From: arhold gmail.com (Arhold)
Date: Tue Oct 10 09:46:17 2006
Subject: [Mp4-tech] How to do conformance test for MPEG4 Advanced Simple
profile (Video)
Message-ID:
Hi guys,
I have a problem of doing conformance test for mpeg4 asp. Basicly
someone else have already raised this question before, but I didn't
find the answer.
It seems that the ASP part are not included in the ISO/IEC 14496-4
Part 4: Conformance testing. According to description in
http://www.m4if.org/resources/profiles/index.html, ASP was been added
in the 2nd Extension to the 2nd Edition of the MPEG-4 Visual standard.
So I guess the conformance test may be in the 2nd Extension. Am I
right? Could some one tell me which spec should I refer to for the ASP
conformance test?
Thanks & Regards,
Arhold
>
>
>
> Hello,
>
> I'm looking for Conformance tests & bitstreams for MPEG-4 video for
> Advanced Simple profile.
>
> In this process, I purchased ISO Conformance document (ISO/IEC 14496-4)
> & the test-streams.
> 1. I found 13 bitstreams under the directory 'advanced_simple'. But the
> Conformance document does not have any description about these
> bitstreams. No Table given in the document has any mention on 'Advanced
> Simple profile'.
>
> 2. I came across a link : 'MPEG-4 Video Conformance Bitstreams available
> for download' in MPEG4 Industry forum (m4if.org). Under this link also,
> I found some bit-streams under the directory 'Advanced_Simple'. These
> streams are different from the ones which are distributed from ISO.
> Also, these appear to be newer than the ones from ISO (as evident from
> the timestamps of the files).
>
> 3. Eventhough ISO/IEC 14496-4 document does not seem to categorize any
> bitstreams under Advanced Simple profile, there are some bit-streams
> listed under Section 5.6 - 'Additional Conformance Testing' which have
> the features of Advanced Simple profile like Quarter-sample
> interpolation & GMC.
>
> In view of the above, I'm not quite clear about which of the sources I
> should be using (1, 2 or 3 mentioned above) for testing the features of
> my Advanced Simple profile decoder.
>
> Would some one please clarify ?
>
> Regards,
>
> Sathish
>
From nagaraj.attimani yahoo.co.in Tue Oct 10 05:41:03 2006
From: nagaraj.attimani yahoo.co.in (Nagaraj Attimani)
Date: Tue Oct 10 09:46:23 2006
Subject: [Mp4-tech] Can H.263 decoder can decodes H.264 Encoded data
Message-ID: <20061010034103.68751.qmail@web8915.mail.in.yahoo.com>
Hi all,
Can H.263 decoder can decodes H.264 Encoded data ?
and Vice versa ?
Thanx in advance
nagaraj
---------------------------------
Find out what India is talking about on - Yahoo! Answers India
Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061010/30bce487/attachment-0001.html
From rgomathi sarayusoftech.com Tue Oct 10 13:33:23 2006
From: rgomathi sarayusoftech.com (Gomathi R)
Date: Tue Oct 10 09:46:27 2006
Subject: [Mp4-tech] Regarding codecs supported by Mp4 file format
Message-ID: <006801c6ec3a$311250a0$b664a8c0@gomathi>
Hi all...
I'm new to this group and this mail is regarding codecs supported by mp4 file format.
I've reffered ISO/IEC 14496-part 14(Mp4 - File Format) where they simply mentioned as AudioSampleEntry,VideoSampleEntry...but i want the actual codecs supported from standard reference......
Please help me out...
Thanks in Advance
Please reply ASAP......
Cheers,
Gomathi.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061010/c905542f/attachment-0001.html
From rgomathi sarayusoftech.com Tue Oct 10 13:43:23 2006
From: rgomathi sarayusoftech.com (Gomathi R)
Date: Tue Oct 10 09:46:32 2006
Subject: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
Message-ID: <007b01c6ec3b$a0677c40$b664a8c0@gomathi>
----- Original Message -----
From: Gomathi R
To: mp4-tech@lists.mpegif.org
Sent: Tuesday, October 10, 2023 12:33 PM
Subject: Regarding codecs supported by Mp4 file format
Hi all...
I'm new to this group and this mail is regarding codecs supported by mp4 file format.
I've reffered ISO/IEC 14496-part 14(Mp4 - File Format) where they simply mentioned as AudioSampleEntry,VideoSampleEntry...but i want the actual codecs supported from standard reference......
Please help me out...
Thanks in Advance
Please reply ASAP......
Cheers,
Gomathi.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061010/aa42248d/attachment-0001.html
From pedersen.ronny gmail.com Tue Oct 10 10:42:50 2006
From: pedersen.ronny gmail.com (Ronny Pedersen)
Date: Tue Oct 10 09:46:36 2006
Subject: [Mp4-tech] [H.264] Inverse 4x4 transform and the 1-D transform
order
In-Reply-To: <03CB47D9C3F8074498E4653F814D6E8F0268E072@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
References: <2a03553f0610060821u1110cd03t43984d4868c093e7@mail.gmail.com>
<03CB47D9C3F8074498E4653F814D6E8F0268E072@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
Message-ID: <2a03553f0610100042u48289fb5m3315e388a74c08ef@mail.gmail.com>
Hmmm, seems like I should probably get that latest version of the
spec ;-) It seems like I have an old draft. I wonder why this has
changed though? Well, anyway, thank you for your help.
-Ronny
On 10/9/06, Gary Sullivan wrote:
>
> Ronny (et al),
>
> You're not correct about what the text of the standard says. Refer to
> subclause 8.5.10, which says:
>
> "First, each (horizontal) row of scaled transform coefficients is
> transformed using a one-dimensional inverse transform as follows." ...
> "Then, each (vertical) column of the resulting matrix is transformed
> using the same one-dimensional inverse transform as follows."
>
> Perhaps you're looking at an old draft. Make sure you have the actual
> current standard. That can save you some headaches. To get the correct
> document, use the following process:
>
> Step 1: Register for the "3 Free" program at
> http://ecs.itu.ch/cgi-bin/ebookshop
>
> Step 2: Download the spec from
> http://www.itu.int/rec/T-REC-H.264
>
> Best Regards,
>
> Gary Sullivan
>
> +> -----Original Message-----
> +> From: mp4-tech-bounces@lists.mpegif.org
> +> [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of
> +> Ronny Pedersen
> +> Sent: Friday, October 06, 2023 8:21 AM
> +> To: mp4-tech@lists.mpegif.org
> +> Subject: [Mp4-tech] [H.264] Inverse 4x4 transform and the
> +> 1-D transform order
> +>
> +> Hi,
> +>
> +> The H.264 specification states that first each column of the 4x4
> +> block should be processed with a 1-d inverse transform and then the
> +> rows should be processed with the same inverse transformations, but
> +> as I can see it the H.264/AVC reference decoder processes
> +> rows and columns
> +> in the opposite order.
> +>
> +> I guess this will make a difference in the result since the
> +> 1-d transforms
> +> performes a left shift (divide by two) on two of the input
> +> coefficients?
> +>
> +> What is the correct order in which to apply the 1-d inverse
> +> transforms to
> +> the 4x4 block?
> +>
> +> Regards,
> +> Ronny
> +> _______________________________________________
> +> NOTE: Please use clear subject lines for your posts. Include
> +> [audio, [video], [systems], [general] or another
> +> apppropriate identifier to indicate the type of question you have.
> +>
> +> Note: Conduct on the mailing list is subject to the
> +> Antitrust guidelines found at
> +> http://www.mpegif.org/public/documents/vault/mp-out-30042-Ant
> +> itrust.php
> +>
>
From rgomathi sarayusoftech.com Wed Oct 11 10:00:49 2006
From: rgomathi sarayusoftech.com (Gomathi R)
Date: Wed Oct 11 09:04:15 2006
Subject: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
References: <20061010154024.19807.qmail@web36514.mail.mud.yahoo.com>
Message-ID: <002601c6ece5$a697f400$b664a8c0@gomathi>
Thanks a lot Liang.....
Actually I'm going to parse the .mp4 file and have to extract audio n video streams seperately to give as input to the corresponding decoders.ie.I'm going to write the code for Mp4 parser according to 14496-part 14.
so for example if the .mp4 contains mpeg-4 video i will read 0x20 as ObjectTypeIndication,then i ll extract the DecoderSpecificInfo as the header for .m4v file(as per 14496-2) and after that i will simply put the encoded samples from the "mdat" area.SO, if the codecs are predefined then i can study about their header info .If the case is like this how should i proceed....Please tell me some suggestions.......
Thanks & Regards
Gomathi.
----- Original Message -----
From: Dickson Liang
To: Gomathi R
Sent: Tuesday, October 10, 2023 9:10 PM
Subject: Re: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
Hi,
MP4 is a file container. So in theory and in practical, you can put almost any kinds of MPEG-related codec inside this format. For example, you can put MPEG2 layer2 audio and MPEG4 H264 video into the same MP4 file. Just like a bag -- you can put any codec you like into the MP4 container.
Regards,
Dickson Liang
Gomathi R wrote:
----- Original Message -----
From: Gomathi R
To: mp4-tech@lists.mpegif.org
Sent: Tuesday, October 10, 2023 12:33 PM
Subject: Regarding codecs supported by Mp4 file format
Hi all...
I'm new to this group and this mail is regarding codecs supported by mp4 file format.
I've reffered ISO/IEC 14496-part 14(Mp4 - File Format) where they simply mentioned as AudioSampleEntry,VideoSampleEntry...but i want the actual codecs supported from standard reference......
Please help me out...
Thanks in Advance
Please reply ASAP......
Cheers,
Gomathi.
_______________________________________________
NOTE: Please use clear subject lines for your posts. Include [audio, [video], [systems], [general] or another apppropriate identifier to indicate the type of question you have.
Note: Conduct on the mailing list is subject to the Antitrust guidelines found at http://www.mpegif.org/public/documents/vault/mp-out-30042-Antitrust.php
------------------------------------------------------------------------------
All-new Yahoo! Mail - Fire up a more powerful email and get things done faster.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061011/8add8743/attachment-0001.html
From rgomathi sarayusoftech.com Wed Oct 11 10:27:06 2006
From: rgomathi sarayusoftech.com (Gomathi R)
Date: Wed Oct 11 09:04:21 2006
Subject: Fw: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
Message-ID: <004c01c6ece9$52450d30$b664a8c0@gomathi>
Also now i ve supported
*Mpeg-4 Audio
*Mpeg-4 video
*H264
*Mpeg1/2 Audio layer1,2,3 (in this too i've some doubts...regarding whether i ve to see ObjectTypeIndication or AudioObjectType inside ObjectTypeIndication == 0x40)
*Mpegi/2 video (for this also i ve no idea about how to write the header as i searched a lot but unfortunately i couldn't get any info regarding this)
Apart from this , is there anything remaining........this is all about my doubts....
please clarify me....
Thanks & Regards
Gomathi.
----- Original Message -----
From: Gomathi R
To: mp4-tech@lists.mpegif.org
Sent: Wednesday, October 11, 2023 9:00 AM
Subject: Re: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
Thanks a lot Liang.....
Actually I'm going to parse the .mp4 file and have to extract audio n video streams seperately to give as input to the corresponding decoders.ie.I'm going to write the code for Mp4 parser according to 14496-part 14.
so for example if the .mp4 contains mpeg-4 video i will read 0x20 as ObjectTypeIndication,then i ll extract the DecoderSpecificInfo as the header for .m4v file(as per 14496-2) and after that i will simply put the encoded samples from the "mdat" area.SO, if the codecs are predefined then i can study about their header info .If the case is like this how should i proceed....Please tell me some suggestions.......
Thanks & Regards
Gomathi.
----- Original Message -----
From: Dickson Liang
To: Gomathi R
Sent: Tuesday, October 10, 2023 9:10 PM
Subject: Re: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
Hi,
MP4 is a file container. So in theory and in practical, you can put almost any kinds of MPEG-related codec inside this format. For example, you can put MPEG2 layer2 audio and MPEG4 H264 video into the same MP4 file. Just like a bag -- you can put any codec you like into the MP4 container.
Regards,
Dickson Liang
Gomathi R wrote:
----- Original Message -----
From: Gomathi R
To: mp4-tech@lists.mpegif.org
Sent: Tuesday, October 10, 2023 12:33 PM
Subject: Regarding codecs supported by Mp4 file format
Hi all...
I'm new to this group and this mail is regarding codecs supported by mp4 file format.
I've reffered ISO/IEC 14496-part 14(Mp4 - File Format) where they simply mentioned as AudioSampleEntry,VideoSampleEntry...but i want the actual codecs supported from standard reference......
Please help me out...
Thanks in Advance
Please reply ASAP......
Cheers,
Gomathi.
_______________________________________________
NOTE: Please use clear subject lines for your posts. Include [audio, [video], [systems], [general] or another apppropriate identifier to indicate the type of question you have.
Note: Conduct on the mailing list is subject to the Antitrust guidelines found at http://www.mpegif.org/public/documents/vault/mp-out-30042-Antitrust.php
------------------------------------------------------------------------------
All-new Yahoo! Mail - Fire up a more powerful email and get things done faster.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061011/65a2d88a/attachment-0001.html
From pankaj_bajpai_iet operamail.com Wed Oct 11 07:16:16 2006
From: pankaj_bajpai_iet operamail.com (pankaj bajpai)
Date: Wed Oct 11 09:04:26 2006
Subject: [Mp4-tech] Can H.263 decoder can decodes H.264 Encoded data
Message-ID: <20061011051616.8A393246AE@ws5-3.us4.outblaze.com>
Dear nagaraj,
H263 and H264 are entirely different standards.
So cross decoding is not possible.
Only Mp4 part 2 has the capability of decoding
H263 baseline
With regards
Pankaj
================================================================
From: Nagaraj Attimani
To: mp4-tech@lists.mpegif.org
Subject: [Mp4-tech] Can H.263 decoder can decodes H.264 Encoded data
Date: Tue, 10 Oct 2023 04:41:03 +0100 (BST)
Hi all,
Can H.263 decoder can decodes H.264 Encoded data ?
and Vice versa ?
Thanx in advance
nagaraj
--
_______________________________________________
Surf the Web in a faster, safer and easier way:
Download Opera 9 at http://www.opera.com
Powered by Outblaze
From spsatendra gmail.com Wed Oct 11 13:16:41 2006
From: spsatendra gmail.com (Satendra)
Date: Wed Oct 11 09:04:31 2006
Subject: [Mp4-tech] H264: Emulation prevention Bytes
Message-ID: <594272320610102346k13cd01actea16a67c7a26c7b4@mail.gmail.com>
Hi,
I am a bit doubtful on the usage of Emulation prevention three bytes.
please consider the following scenario and answer:
1)in normal scenes this is how we will use emulation prevention bytes.
0x000000 ------------------> 0x00000300
0x000001 ------------------> 0x00000301
0x000002 ------------------> 0x00000302
0x000003 ------------------> 0x00000303
2) but how this byte sequence will map
0x000000000005
---------------------> 0x000003 000003 0005
or
---------------------> 0x00000300 000005
thanks
Satendra
--
-----------------------------------------------------------------------------------------------------------------------------------
"We all agree on the necessity of compromise. We just can't agree on when
it's necessary to compromise." ------Larry Wall
-----------------------------------------------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061011/4a62d92b/attachment-0001.html
From sid.mpeg4 gmail.com Wed Oct 11 14:25:26 2006
From: sid.mpeg4 gmail.com (Siddharth Patel)
Date: Wed Oct 11 09:04:35 2006
Subject: [Mp4-tech] need attractive architectural diagram and video for
MPEG-4/BIFS presentation
Message-ID: <4b3ac9600610110055q42a62e11rb1185bace1bb9de6@mail.gmail.com>
hi friends,
I am supposed to set-up a stall for show casing MPEG-4 and BIFS technology.
Can anybody point me to attractive architecural diagrams on MPEG-4 Systems
standard on internet.
Would be greatful if anybody can also pass on attractive videos about MPEG-4
technology, something like an interview with some CEO of a company who is
talking about future of interactive video.
My main aim is to attract more people to my stall and talk to them about
MPEG-4 and interactive video
regads,
Sid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061011/328103a4/attachment-0001.html
From luqman_ngs gmx.net Wed Oct 11 11:53:08 2006
From: luqman_ngs gmx.net (Luqman)
Date: Wed Oct 11 09:04:43 2006
Subject: [Mp4-tech] [Video] H.264: What to do in case of a P-frame loss?
Message-ID: <20061011085308.GA7879@gmx.de>
I have a video clip consisting of following frames:
I -> P -> B
Now, once I frame is lost, no decoding of video is possible. But when P
frame is lost, is there a slight possibility of correctly decoding P or
B frame with any error concealment methods?
Actually, I am doing a simulation on h.264 frame loss and would appreciate
your views.
Regards,
--
Luqman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : /pipermail/mp4-tech/attachments/20061011/e84142d4/attachment.bin
From steve.eschke stud.tu-ilmenau.de Wed Oct 11 23:53:15 2006
From: steve.eschke stud.tu-ilmenau.de (Steve Eschke)
Date: Wed Oct 11 17:28:07 2006
Subject: [Mp4-tech] Layout node semantics
Message-ID: <452D59BB.5060003@stud.tu-ilmenau.de>
Skipped content of type multipart/related-------------- next part --------------
A non-text attachment was scrubbed...
Name: wrapping1.gif
Type: image/gif
Size: 5999 bytes
Desc: not available
Url : /pipermail/mp4-tech/attachments/20061011/ea2dfb2b/wrapping1-0003.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wrapping2.gif
Type: image/gif
Size: 6294 bytes
Desc: not available
Url : /pipermail/mp4-tech/attachments/20061011/ea2dfb2b/wrapping2-0003.gif
From M.A.J.Barzilaij student.TUDelft.NL Thu Oct 12 01:23:16 2006
From: M.A.J.Barzilaij student.TUDelft.NL (Barzilaij)
Date: Wed Oct 11 20:04:07 2006
Subject: [Mp4-tech] JSVM Encoder and Hierarchical B Frames.
References: <03CFB4D273F08D459F94B315B7E119580DEE6A@SRV602.tudelft.net>
<03CFB4D273F08D459F94B315B7E119580DEE6B@SRV602.tudelft.net>
Message-ID: <03CFB4D273F08D459F94B315B7E119580DEE6C@SRV602.tudelft.net>
Dear Experts,
I am a graduating student at the Technical University in Delft, the Netherlands. Currently, I am analyzing and testing the encoder (V6.8), mainly to see the benefits of temporal scalability.
It turns out in all my simulations (scalable mode), that the B frames in the hierarchical B frames structure always have a higher initial QP and therefore a lower PSNR value than the I or P frames (e.g. I or P frames have a PSNR of 38 while B frames have a PSNR of 34).
During simulation with VQM Software I analyzed different frame rates with similar bitrates (CIF format -- 7.5, 15 and 30fps on 100, 200, 500 and 1000kbit/s). In general, even for rather slow moving video content, the highest framerate was preferred over others for any bitrate setting. It seems that with extra bitrate budget, increasing framerate is always preferred over increasing PSNR of lower temporal levels. Since the B frames can be constructed with little data, jerky or unnatural motion is very easy to combat.
Currently I am unable to find good encoder settings such that a lowering the framerate becomes more useful. My question is the following;
Why do B frames have a lower QP and is there a way to adjust the initial QP value of the B frames? More general, is there a way to increase the PSNR of these frames to the PSNR of the I or P frames.
Any feedback is appreciated.
Kind Regards,
Mark Barzilay
VQM Software: http://www.its.bldrdoc.gov/n3/video/vqmsoftware.htm
If asked, I can send some results or more info about my research.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061012/8f31eff3/attachment.html
From yuval envivio.com Wed Oct 11 18:09:29 2006
From: yuval envivio.com (Yuval Fisher)
Date: Wed Oct 11 21:28:05 2006
Subject: [Mp4-tech] Layout node semantics
In-Reply-To: <452D59BB.5060003@stud.tu-ilmenau.de>
References: <452D59BB.5060003@stud.tu-ilmenau.de>
Message-ID: <452D87B9.5070605@envivio.com>
Hi Steve,
The intent of the node was to do what you show in your first image: that
is, to distribute the text over the lines of the layout node.
It's an unusual question... are you implementing this ?
Cheers, Yuval
Steve Eschke wrote:
> Hello People
>
> Shall text inside a Layout node be distributed over the lines of the
> layout when wrapping is on?
>
> Example:
>
> Figure 1: Three Text nodes and a non-text object. All objects share
> the same lines.
>
>
> Figure 2: Two Text nodes not sharing the same lines.
>
> (If you do not see any figures, look for the attachment)
>
> Which of these figures match the true meaning of text breaking and
> wrapping in Layout nodes? Can you give a citation of the standard that
> states this?
>
> Best regards
> Steve Eschke
> Institute for Media Technology
> Technical University of Ilmenau/Germany
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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
--
Yuval Fisher
Envivio.
yuval@envivio.com
+1 (650) 324 2900
From samuel lambdastream.com Thu Oct 12 10:31:28 2006
From: samuel lambdastream.com (Samuel Rivas)
Date: Thu Oct 12 09:22:13 2006
Subject: [Mp4-tech] H264: Emulation prevention Bytes
In-Reply-To: <594272320610102346k13cd01actea16a67c7a26c7b4@mail.gmail.com>
References: <594272320610102346k13cd01actea16a67c7a26c7b4@mail.gmail.com>
Message-ID: <20061012073128.GA19004@lambdastream.com>
Satendra wrote:
> 1)in normal scenes this is how we will use emulation prevention bytes.
> 0x000000 ------------------> 0x00000300
> 0x000001 ------------------> 0x00000301
> 0x000002 ------------------> 0x00000302
> 0x000003 ------------------> 0x00000303
>
> 2) but how this byte sequence will map
> 0x000000000005
> ---------------------> 0x000003 000003 0005
> or
> ---------------------> 0x00000300 000005
The first one. For the second one, 0x000003 000000 05 has an illegal
^^^^^^
sequence of bytes.
The standard is a bit confusing on this subject:
"[...]
and a byte equal to 0x03 is inserted to replace these bit patterns with
the patterns
'00000000 00000000 00000011 000000xx',
[...]"
But it does not make clear is that 000000xx takes part in the next
0x000000
sequence if it is present.
Regards
--
Samuel
From videogenie hotmail.com Thu Oct 12 02:33:24 2006
From: videogenie hotmail.com (The Video Genie)
Date: Thu Oct 12 09:22:20 2006
Subject: [Mp4-tech] [Video] H.264: What to do in case of a P-frame loss?
In-Reply-To: <20061011085308.GA7879@gmx.de>
Message-ID:
The data loss will be more localized if NAL units will contain less than a
frame data i.e. slice size is smaller. There are number of error concealment
techniques that can be used in case of full frame loss their success depends
on the motion content in a picture. You may search them over the net.
From: Luqman
To: mp4-tech@lists.mpegif.org
Subject: [Mp4-tech] [Video] H.264: What to do in case of a P-frame loss?
Date: Wed, 11 Oct 2023 10:53:08 +0200
I have a video clip consisting of following frames:
I -> P -> B
Now, once I frame is lost, no decoding of video is possible. But when P
frame is lost, is there a slight possibility of correctly decoding P or
B frame with any error concealment methods?
Actually, I am doing a simulation on h.264 frame loss and would appreciate
your views.
Regards,
--
Luqman
<< signature.asc >>
_______________________________________________
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
_________________________________________________________________
Add fun gadgets and colorful themes to express yourself on Windows Live
Spaces
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://www.get.live.com/spaces/features
From sugeeth sarayusoftech.com Thu Oct 12 15:30:00 2006
From: sugeeth sarayusoftech.com (Sugeeth)
Date: Thu Oct 12 09:22:26 2006
Subject: [Mp4-tech] Re: Mp4-tech Digest, Vol 39, Issue 8
In-Reply-To: <200610111608.k9BG7UKG012998@lists1.magma.ca>
References: <200610111608.k9BG7UKG012998@lists1.magma.ca>
Message-ID: <452E0410.4060307@sarayusoftech.com>
In H.264 we dont send Frames, Instead we send the encoded information in
the Form Of Nalunits. The Nalunits normally contain coded information of
1 slice. If A Nalunit is lost, with the help of error resilience
mechanisms and the remaining nal units that constitute the frame, the
remaining frame can be retrieved.
I dont think Error Resilience is defined in the standard, it is
something that we implement with our own logics.
Hope this info helps,
Some one pls correct me in case the above info is incorrect.
thanks,
sugeeth
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. [Video] H.264: What to do in case of a P-frame loss? (Luqman)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Wed, 11 Oct 2023 10:53:08 +0200
>From: Luqman
>Subject: [Mp4-tech] [Video] H.264: What to do in case of a P-frame
> loss?
>To: mp4-tech@lists.mpegif.org
>Message-ID: <20061011085308.GA7879@gmx.de>
>Content-Type: text/plain; charset="us-ascii"
>
>I have a video clip consisting of following frames:
>
>I -> P -> B
>
>Now, once I frame is lost, no decoding of video is possible. But when P
>frame is lost, is there a slight possibility of correctly decoding P or
>B frame with any error concealment methods?
>
>Actually, I am doing a simulation on h.264 frame loss and would appreciate
>your views.
>
>Regards,
>
>
>
From abhins_4 yahoo.com Thu Oct 12 03:52:55 2006
From: abhins_4 yahoo.com (abhishek jain)
Date: Thu Oct 12 09:22:31 2006
Subject: [Mp4-tech] References for Container Formats
Message-ID: <20061012095255.53366.qmail@web54506.mail.yahoo.com>
Dear All
I am new to container formats. Currently I am going
thro ISO base media file format. I need to work
specifically on mp4 file format.
Please provide your inputs to help me understand the
container formats in general and mp4 particularly.
Where can I find related docs(freely available) and
also the source code for mp4 parser. Also I need to
know if any open source mp4 composer is available.
Regards
Abhishek
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
From Alan.Yan fmc.fujitsu.com Thu Oct 12 21:05:28 2006
From: Alan.Yan fmc.fujitsu.com (Alan Yan - SH)
Date: Thu Oct 12 09:22:36 2006
Subject: [Mp4-tech] Does MMCOs has a limitation on the number?
Message-ID: <6D7740EE76790E44A1775CE82BA2DB8E53C579@fmcshmsex01>
Dear Experts,
I have a question regarding the maximum number of continuous occurrences
of "memory_management_control_operation!=0" in function
dec_ref_pic_marking( ).
Has h.264 spec defined/implied a limitation on the number of MMCOs?
I have checked in the spec and did not see any related constraints.
I can see from JM86 code that it uses a link structure which can support
unlimited number of MMCO.
And I also checked ffmpeg which has defined a "MAX_MMCO_COUNT" equal to
66, meaning it can support a max number of 66 MMCOs.
Does the 66 used by ffmpeg have any hidden meaningful insights or it is
just a big-enough number choosing randomly?
Thanks for your clarification.
Best Regrads,
alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061012/a3afd088/attachment.html
From singer apple.com Thu Oct 12 13:16:07 2006
From: singer apple.com (Dave Singer)
Date: Thu Oct 12 15:28:06 2006
Subject: [Mp4-tech] References for Container Formats
In-Reply-To: <20061012095255.53366.qmail@web54506.mail.yahoo.com>
References: <20061012095255.53366.qmail@web54506.mail.yahoo.com>
Message-ID:
At 2:52 -0700 12/10/06, abhishek jain wrote:
>Dear All
>
>I am new to container formats. Currently I am going
>thro ISO base media file format. I need to work
>specifically on mp4 file format.
>Please provide your inputs to help me understand the
>container formats in general and mp4 particularly.
>Where can I find related docs(freely available) and
>also the source code for mp4 parser. Also I need to
>know if any open source mp4 composer is available.
Go to and click on 'technologies'
under 'documents' and you will find white papers etc. on parts 12, 14
and 15 of mpeg-4.
FFMpeg, GPAC, and a number of other projects have implementations of
the file format. In addition, reference code is available from
on request.
Finally, the full part 12 standard is freely available from ISO.
Hope this helps.
>Regards
>Abhishek
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam protection around
>http://mail.yahoo.com
>_______________________________________________
>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
--
David Singer
Apple Computer/QuickTime
From garysull windows.microsoft.com Thu Oct 12 14:30:32 2006
From: garysull windows.microsoft.com (Gary Sullivan)
Date: Thu Oct 12 16:40:08 2006
Subject: [Mp4-tech] Does MMCOs has a limitation on the number?
In-Reply-To: <6D7740EE76790E44A1775CE82BA2DB8E53C579@fmcshmsex01>
Message-ID: <03CB47D9C3F8074498E4653F814D6E8F02743ED1@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
There is an implied limit that I believe is somewhere in that
neighborhood due to limitations in the standard that certain actions
cannot be repeated and that certain action cause changes of status that
would prohibit certain other actions from taking place after them and
due to limitations on the total quantity of reference pictures in the
DPB. But I'm not sure what the exact number is.
Best Regards,
Gary Sullivan
________________________________
From: mp4-tech-bounces@lists.mpegif.org
[mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Alan Yan - SH
Sent: Thursday, October 12, 2023 5:05 AM
To: mp4-tech@lists.mpegif.org
Subject: [Mp4-tech] Does MMCOs has a limitation on the number?
Dear Experts,
I have a question regarding the maximum number of continuous
occurrences of "memory_management_control_operation!=0" in function
dec_ref_pic_marking( ).
Has h.264 spec defined/implied a limitation on the number of
MMCOs?
I have checked in the spec and did not see any related
constraints.
I can see from JM86 code that it uses a link structure which can
support unlimited number of MMCO.
And I also checked ffmpeg which has defined a "MAX_MMCO_COUNT"
equal to 66, meaning it can support a max number of 66 MMCOs.
Does the 66 used by ffmpeg have any hidden meaningful insights
or it is just a big-enough number choosing randomly?
Thanks for your clarification.
Best Regrads,
alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061012/e12ad1af/attachment.html
From garysull windows.microsoft.com Thu Oct 12 14:50:36 2006
From: garysull windows.microsoft.com (Gary Sullivan)
Date: Thu Oct 12 17:04:06 2006
Subject: [Mp4-tech] H264: Emulation prevention Bytes
In-Reply-To: <20061012073128.GA19004@lambdastream.com>
Message-ID: <03CB47D9C3F8074498E4653F814D6E8F02743EFC@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
Samuel et al,
You may say that the standard is somewhat confusing on this topic, and
it may be true that this part is not especially easy to read, but I
believe it is sufficiently clear (and if you find some particular
missing thing, please let us know and we'll try to fix it). When reading
it, it may be helpful to keep the following things in mind:
1) For reasons of trying to allow maximum freedom to implementers while
achieving interoperability goals, the standard is written almost
entirely from the perspective of a decoder, not an encoder. Do not read
it as a recipe for encoder design. It does contain a limited quantity
of remarks intended for that purpose, but that is not its major focus.
2) Certain sections of the text contain requirements that constrain the
content of conforming bitstreams. Certain other sections contain
"informative" remarks only (statements intended to be helpful but not
saying something mandatory). It can sometimes be important to pay
attention to which is which. In theory it should be possible to
completely remove the "informative" sections without affecting the
sufficiency of the document as a specification.
3) The standard is generally written in a way that avoids saying things
redundantly. This means that you need to read every part of the
standard that touches on the subject you're investigating. It is not
sufficient to focus on one or two sections and hope that everything you
need will be mentioned there. You need to look for every place that
touches your topic of interest and think about the full implications of
what each statement says. For example, if something is fully specified
by the syntax diagram of the NAL unit syntax structure, it may not be
reiterated anywhere in words in the text.
Best Regards,
Gary Sullivan
+> -----Original Message-----
+> From: mp4-tech-bounces@lists.mpegif.org
+> [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Samuel Rivas
+> Sent: Thursday, October 12, 2023 12:31 AM
+> To: mp4-tech@lists.mpegif.org
+> Subject: Re: [Mp4-tech] H264: Emulation prevention Bytes
+>
+> Satendra wrote:
+> > 1)in normal scenes this is how we will use emulation
+> prevention bytes.
+> > 0x000000 ------------------> 0x00000300
+> > 0x000001 ------------------> 0x00000301
+> > 0x000002 ------------------> 0x00000302
+> > 0x000003 ------------------> 0x00000303
+> >
+> > 2) but how this byte sequence will map
+> > 0x000000000005
+> > ---------------------> 0x000003 000003 0005
+> > or
+> > ---------------------> 0x00000300 000005
+>
+> The first one. For the second one, 0x000003 000000 05 has an illegal
+> ^^^^^^
+> sequence of bytes.
+>
+>
+> The standard is a bit confusing on this subject:
+>
+> "[...]
+> and a byte equal to 0x03 is inserted to replace these bit
+> patterns with
+> the patterns
+>
+> '00000000 00000000 00000011 000000xx',
+> [...]"
+>
+> But it does not make clear is that 000000xx takes part in the next
+> 0x000000
+> sequence if it is present.
+>
+> Regards
+>
+> --
+> Samuel
+> _______________________________________________
+> NOTE: Please use clear subject lines for your posts. Include
+> [audio, [video], [systems], [general] or another
+> apppropriate identifier to indicate the type of question you have.
+>
+> Note: Conduct on the mailing list is subject to the
+> Antitrust guidelines found at
+> http://www.mpegif.org/public/documents/vault/mp-out-30042-Ant
+> itrust.php
+>
From rgomathi sarayusoftech.com Fri Oct 13 12:13:34 2006
From: rgomathi sarayusoftech.com (Gomathi R)
Date: Fri Oct 13 09:51:17 2006
Subject: Fw: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
Message-ID: <003501c6ee8a$8b3917b0$b664a8c0@gomathi>
Hi Girish,
Thank u very much for ur reply.......
yaa i had taken the information from other atoms like stco,stsc to correctly locate the encoded data address in the mdat area.
But my problem is with the header we have to include in front of encoded streams.For that first I should know what are all the codecs supported by a standard mp4 file.
Then I have to study whether for a particular encoded stream we need to include header or not.B''coz for mpeg 1/2 Audio layers there is no DecoderSpecificInfo ,so,no need to include headers as the encoded stream itself contains all the info needed for the decoder.This all about my problem .
Please help me out
Expecting replies.....
Thanks n Regards
Gomathi.
----- Original Message -----
From: Girish Shenoy
To: Gomathi R
Sent: Friday, October 13, 2023 10:40 AM
Subject: RE: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
Hi Gomathi,
ObjectTypeIndication is the right place to look for the information you need. You've already hit the nail on the head.
But please be aware that the mdat need not necessarily be directly decodable without the help of other boxes in the file. Especially in the case where the file has more than one stream, the mdat may have data from both streams interleaved with each other.
Regards,
Girish
-----Original Message-----
From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org]On Behalf Of Gomathi R
Sent: Wednesday, October 11, 2023 9:01 AM
To: mp4-tech@lists.mpegif.org
Subject: Re: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
Thanks a lot Liang.....
Actually I'm going to parse the .mp4 file and have to extract audio n video streams seperately to give as input to the corresponding decoders.ie.I'm going to write the code for Mp4 parser according to 14496-part 14.
so for example if the .mp4 contains mpeg-4 video i will read 0x20 as ObjectTypeIndication,then i ll extract the DecoderSpecificInfo as the header for .m4v file(as per 14496-2) and after that i will simply put the encoded samples from the "mdat" area.SO, if the codecs are predefined then i can study about their header info .If the case is like this how should i proceed....Please tell me some suggestions.......
Thanks & Regards
Gomathi.
----- Original Message -----
From: Dickson Liang
To: Gomathi R
Sent: Tuesday, October 10, 2023 9:10 PM
Subject: Re: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
Hi,
MP4 is a file container. So in theory and in practical, you can put almost any kinds of MPEG-related codec inside this format. For example, you can put MPEG2 layer2 audio and MPEG4 H264 video into the same MP4 file. Just like a bag -- you can put any codec you like into the MP4 container.
Regards,
Dickson Liang
Gomathi R wrote:
----- Original Message -----
From: Gomathi R
To: mp4-tech@lists.mpegif.org
Sent: Tuesday, October 10, 2023 12:33 PM
Subject: Regarding codecs supported by Mp4 file format
Hi all...
I'm new to this group and this mail is regarding codecs supported by mp4 file format.
I've reffered ISO/IEC 14496-part 14(Mp4 - File Format) where they simply mentioned as AudioSampleEntry,VideoSampleEntry...but i want the actual codecs supported from standard reference......
Please help me out...
Thanks in Advance
Please reply ASAP......
Cheers,
Gomathi.
_______________________________________________
NOTE: Please use clear subject lines for your posts. Include [audio, [video], [systems], [general] or another apppropriate identifier to indicate the type of question you have.
Note: Conduct on the mailing list is subject to the Antitrust guidelines found at http://www.mpegif.org/public/documents/vault/mp-out-30042-Antitrust.php
------------------------------------------------------------------------------
MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061013/3d240477/attachment-0001.html
From rgomathi sarayusoftech.com Fri Oct 13 13:13:05 2006
From: rgomathi sarayusoftech.com (Gomathi R)
Date: Fri Oct 13 09:51:24 2006
Subject: Fw: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
Message-ID: <006b01c6ee92$de191720$b664a8c0@gomathi>
----- Original Message -----
From: Gomathi R
To: Girish Shenoy
Sent: Friday, October 13, 2023 12:11 PM
Subject: Re: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
Hi Girish,
Thanx a lot for ur reply....
In Mp4 file format doc(14496-14) they didn't mention that these are the specific codecs supported...again while surfing, i got to know in mp4 file we can put any stream inside it.if that is the case it will be a very tedious work to go through all the codec headers n all.
I too believe whatever you mentioned are the streams supported.In this case also when i referred the mpeg-4 systems doc. there is no reference for mpeg1/2 video.For mpeg 4 video they mentioned to refer 14496-2 Annex-k.But for Mpeg 1/2 video how to write the header info ? where to refer..?
Also while referring mpeg-4 audio doc the AudioObjectType in AudioSpecificConfig contains CELP,HVXC,TwinVQ....etc..... should i need to support that also.if it is so CELP,TwinVQ are seperate coders to give them the DecoderSpecificInfo as header and encoded samples after that?.....Dont get tensed on seeing these many questions.....Please clarify me if u have free time.......
Thanks a lot
Regards
Gomathi.
----- Original Message -----
From: Girish Shenoy
To: Gomathi R
Sent: Friday, October 13, 2023 11:38 AM
Subject: RE: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
Hi Gomathi,
To my knowledge .mp4 supports mpeg 1/2/4 audio/video/systems streams (and also jpeg-1 streams i believe).
To figure out which one of these is in use, one has to look at the ObjectTypeIndication.
To figure out what are the headers (decoder specific info), unfortunately, one has to refer to that specific standard (eg 14496-2 for mpeg-4 visual). Hence in order to be able to decode all streams one has to have access to all of the above standards.
Regards,
Girish
-----Original Message-----
From: Gomathi R [mailto:rgomathi@sarayusoftech.com]
Sent: Friday, October 13, 2023 11:13 AM
To: Girish Shenoy
Subject: Re: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
Hi Girish,
Thank u very much for ur reply.......
yaa i had taken the information from other atoms like stco,stsc to correctly locate the encoded data address in the mdat area.
But my problem is with the header we have to include in front of encoded streams.For that first I should know what are all the codecs supported by a standard mp4 file.
Then I have to study whether for a particular encoded stream we need to include header or not.B''coz for mpeg 1/2 Audio layers there is no DecoderSpecificInfo ,so,no need to include headers as the encoded stream itself contains all the info needed for the decoder.This all about my problem .
Please help me out
Expecting replies.....
Thanks n Regards
Gomathi.
----- Original Message -----
From: Girish Shenoy
To: Gomathi R
Sent: Friday, October 13, 2023 10:40 AM
Subject: RE: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
Hi Gomathi,
ObjectTypeIndication is the right place to look for the information you need. You've already hit the nail on the head.
But please be aware that the mdat need not necessarily be directly decodable without the help of other boxes in the file. Especially in the case where the file has more than one stream, the mdat may have data from both streams interleaved with each other.
Regards,
Girish
-----Original Message-----
From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org]On Behalf Of Gomathi R
Sent: Wednesday, October 11, 2023 9:01 AM
To: mp4-tech@lists.mpegif.org
Subject: Re: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
Thanks a lot Liang.....
Actually I'm going to parse the .mp4 file and have to extract audio n video streams seperately to give as input to the corresponding decoders.ie.I'm going to write the code for Mp4 parser according to 14496-part 14.
so for example if the .mp4 contains mpeg-4 video i will read 0x20 as ObjectTypeIndication,then i ll extract the DecoderSpecificInfo as the header for .m4v file(as per 14496-2) and after that i will simply put the encoded samples from the "mdat" area.SO, if the codecs are predefined then i can study about their header info .If the case is like this how should i proceed....Please tell me some suggestions.......
Thanks & Regards
Gomathi.
----- Original Message -----
From: Dickson Liang
To: Gomathi R
Sent: Tuesday, October 10, 2023 9:10 PM
Subject: Re: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
Hi,
MP4 is a file container. So in theory and in practical, you can put almost any kinds of MPEG-related codec inside this format. For example, you can put MPEG2 layer2 audio and MPEG4 H264 video into the same MP4 file. Just like a bag -- you can put any codec you like into the MP4 container.
Regards,
Dickson Liang
Gomathi R wrote:
----- Original Message -----
From: Gomathi R
To: mp4-tech@lists.mpegif.org
Sent: Tuesday, October 10, 2023 12:33 PM
Subject: Regarding codecs supported by Mp4 file format
Hi all...
I'm new to this group and this mail is regarding codecs supported by mp4 file format.
I've reffered ISO/IEC 14496-part 14(Mp4 - File Format) where they simply mentioned as AudioSampleEntry,VideoSampleEntry...but i want the actual codecs supported from standard reference......
Please help me out...
Thanks in Advance
Please reply ASAP......
Cheers,
Gomathi.
_______________________________________________
NOTE: Please use clear subject lines for your posts. Include [audio, [video], [systems], [general] or another apppropriate identifier to indicate the type of question you have.
Note: Conduct on the mailing list is subject to the Antitrust guidelines found at http://www.mpegif.org/public/documents/vault/mp-out-30042-Antitrust.php
--------------------------------------------------------------------------
MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061013/cc38b713/attachment-0001.html
From zombiyaga yahoo.com Fri Oct 13 01:08:01 2006
From: zombiyaga yahoo.com (Alex)
Date: Fri Oct 13 09:51:29 2006
Subject: [Mp4-tech] H.264 / AVC conformance streams wanted
In-Reply-To: <03CB47D9C3F8074498E4653F814D6E8F02743EFC@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
Message-ID: <20061013070801.84464.qmail@web53906.mail.yahoo.com>
Hi,
I'm looking for H.264 / AVC BP, Level x.x conformance streams. If you have any referencies, please let me know.
Thanks, Alex
--
Regards,
Alex
---------------------------------
Stay in the know. Pulse on the new Yahoo.com. Check it out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061013/265af527/attachment-0001.html
From rgomathi sarayusoftech.com Fri Oct 13 15:42:48 2006
From: rgomathi sarayusoftech.com (Gomathi R)
Date: Fri Oct 13 09:51:34 2006
Subject: Fw: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
Message-ID: <009301c6eea7$c6b9c3d0$b664a8c0@gomathi>
----- Original Message -----
From: Gomathi R
To: Girish Shenoy
Sent: Friday, October 13, 2023 2:39 PM
Subject: Re: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
Hi Girish,
I do referred that section but there is no reference for Mpeg 1/2 video over there.
Thanks & Regargs
Gomathi
----- Original Message -----
From: Girish Shenoy
To: Gomathi R
Sent: Friday, October 13, 2023 10:40 AM
Subject: RE: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
Hi Gomathi,
ObjectTypeIndication is the right place to look for the information you need. You've already hit the nail on the head.
But please be aware that the mdat need not necessarily be directly decodable without the help of other boxes in the file. Especially in the case where the file has more than one stream, the mdat may have data from both streams interleaved with each other.
Regards,
Girish
-----Original Message-----
From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org]On Behalf Of Gomathi R
Sent: Wednesday, October 11, 2023 9:01 AM
To: mp4-tech@lists.mpegif.org
Subject: Re: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
Thanks a lot Liang.....
Actually I'm going to parse the .mp4 file and have to extract audio n video streams seperately to give as input to the corresponding decoders.ie.I'm going to write the code for Mp4 parser according to 14496-part 14.
so for example if the .mp4 contains mpeg-4 video i will read 0x20 as ObjectTypeIndication,then i ll extract the DecoderSpecificInfo as the header for .m4v file(as per 14496-2) and after that i will simply put the encoded samples from the "mdat" area.SO, if the codecs are predefined then i can study about their header info .If the case is like this how should i proceed....Please tell me some suggestions.......
Thanks & Regards
Gomathi.
----- Original Message -----
From: Dickson Liang
To: Gomathi R
Sent: Tuesday, October 10, 2023 9:10 PM
Subject: Re: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
Hi,
MP4 is a file container. So in theory and in practical, you can put almost any kinds of MPEG-related codec inside this format. For example, you can put MPEG2 layer2 audio and MPEG4 H264 video into the same MP4 file. Just like a bag -- you can put any codec you like into the MP4 container.
Regards,
Dickson Liang
Gomathi R wrote:
----- Original Message -----
From: Gomathi R
To: mp4-tech@lists.mpegif.org
Sent: Tuesday, October 10, 2023 12:33 PM
Subject: Regarding codecs supported by Mp4 file format
Hi all...
I'm new to this group and this mail is regarding codecs supported by mp4 file format.
I've reffered ISO/IEC 14496-part 14(Mp4 - File Format) where they simply mentioned as AudioSampleEntry,VideoSampleEntry...but i want the actual codecs supported from standard reference......
Please help me out...
Thanks in Advance
Please reply ASAP......
Cheers,
Gomathi.
_______________________________________________
NOTE: Please use clear subject lines for your posts. Include [audio, [video], [systems], [general] or another apppropriate identifier to indicate the type of question you have.
Note: Conduct on the mailing list is subject to the Antitrust guidelines found at http://www.mpegif.org/public/documents/vault/mp-out-30042-Antitrust.php
----------------------------------------------------------------------------
MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061013/c2e695cf/attachment-0001.html
From luqman_ngs gmx.net Fri Oct 13 13:04:27 2006
From: luqman_ngs gmx.net (Luqman)
Date: Fri Oct 13 09:51:38 2006
Subject: [Mp4-tech] Re: Mp4-tech Digest, Vol 39, Issue 8
In-Reply-To: <452E0410.4060307@sarayusoftech.com>
References: <20061011085308.GA7879@gmx.de> <452E0410.4060307@sarayusoftech.com>
Message-ID: <20061013100427.GA6578@gmx.de>
hi Sugeeth,
thanks for you reply.
> Sugeeth wanted us to know:
>
>In H.264 we dont send Frames, Instead we send the encoded information in
>the Form Of Nalunits. The Nalunits normally contain coded information of
>1 slice. If A Nalunit is lost, with the help of error resilience
>mechanisms and the remaining nal units that constitute the frame, the
>remaining frame can be retrieved.
>
>I dont think Error Resilience is defined in the standard, it is
>something that we implement with our own logics.
>
You are correct; the standard does not say much on error resilience topic.
A quick search on the word "loss" led me to 8.2.5.2 and page 90
(redundant_pic_cnt).
Anyhow, your reply did help me rethink about my problem. I think even
loss of a whole frame should be reconstructable with help of motion
vectors of preceeding and succeeding frames.
Regards,
--
Luqman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : /pipermail/mp4-tech/attachments/20061013/7d36a02f/attachment.bin
From luqman_ngs gmx.net Fri Oct 13 13:52:49 2006
From: luqman_ngs gmx.net (Luqman)
Date: Fri Oct 13 09:51:46 2006
Subject: [Mp4-tech] Dropping NAL units on bit errors: Best approach?
Message-ID: <20061013105249.GB6578@gmx.de>
hello,
I like to simulate video over UMTS link and then drop all NAL units
containg bit error after the transport.
One possibility would be to read the bitstream file directly, look for
start_code_prefixes, i.e. 0x000000, to find NAL unit boundaries, and
copy everything except for errored NAL units in a new file.
Second approach would involve editing code in decoder directly. I am
working with reference decoder software JM10.2.
Since the standard is very complex and I am just a novice on this topic,
I was wondering if the first approach wouldn't be more appropriate for my
purpose. With my limited experience with h264 working on encoded stream
file seems to be more straightforward and universal solution.
I would appreciate any comments on this.
Regards,
--
Luqman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : /pipermail/mp4-tech/attachments/20061013/1d20e193/attachment.bin
From luqman_ngs gmx.net Fri Oct 13 14:28:21 2006
From: luqman_ngs gmx.net (Luqman)
Date: Fri Oct 13 09:51:51 2006
Subject: [Mp4-tech] start code prefix: 0x000001
In-Reply-To: <20061013105249.GB6578@gmx.de>
References: <20061013105249.GB6578@gmx.de>
Message-ID: <20061013112820.GC6578@gmx.de>
> Luqman wanted us to know:
>One possibility would be to read the bitstream file directly, look for
>start_code_prefixes, i.e. 0x000000, to find NAL unit boundaries, and
^^^^^^^^^^
start code prefix is ofcourse 0x000001 and not 0x000000. I wrote that
from memory but had doubts. Looking up in the standard showed doubts
were correct.
--
Luqman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : /pipermail/mp4-tech/attachments/20061013/2438cb45/attachment.bin
From samuel lambdastream.com Fri Oct 13 17:04:49 2006
From: samuel lambdastream.com (Samuel Rivas)
Date: Fri Oct 13 14:28:08 2006
Subject: [Mp4-tech] H264: Emulation prevention Bytes
In-Reply-To: <03CB47D9C3F8074498E4653F814D6E8F02743EFC@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
References: <20061012073128.GA19004@lambdastream.com>
<03CB47D9C3F8074498E4653F814D6E8F02743EFC@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
Message-ID: <20061013140449.GA31590@lambdastream.com>
Gary,
> You may say that the standard is somewhat confusing on this topic, and
> it may be true that this part is not especially easy to read, but I
> believe it is sufficiently clear (and if you find some particular
> missing thing, please let us know and we'll try to fix it). When reading
> it, it may be helpful to keep the following things in mind:
I did not mean that the standard was ambiguous or incomplete. I is
just that that informative section confused me too the first time I read
it. Reading NAL unit syntax definition gave me an idea (that was
correct) that clashed with what I understood in the informative section.
Further reading in the reference code source made it perfectly clear. So
the specification is correct, I have nothing to say against it.
Since Satendra seems to have the same problem I had, I tried to clarify
where the confusion took place. I pointed what misled me and why.
Whether it is my problem or the standard's is subject to discussion.
I understand that I cited an excerpt of an informative section and I
did not say anything of the normative information which, for me, is
perfectly clear. Sorry if that annoyed you.
Finally, just to make clear what I am missing, and then it may be
evaluated as an useful correction or just my misunderstanding:
In section 7.4.1.1 it reads that a bit pattern 00000000 00000000
00000011 000000xx must be laid to replace any 00000000 00000000 000000xx
pattern. For me, what is not clear is that for sequeneces such as 0x00
0x00 0x00 0x00 ..., after the first substitution 0x00 0x00 0x03 0x00
0x00, the fourth byte takes part of both 00000000 00000000 00000011
00000000 pattern and the next 00000000 00000000 000000xx pattern.
It is clear in NAL unit syntax though. But when reading the two parts
I was not able whether the problem was that I misunderstood the normative
part or the informative part.
Regards.
--
Samuel
From sma com.dtu.dk Fri Oct 13 20:07:14 2006
From: sma com.dtu.dk (Shankar Manuel Aghito)
Date: Fri Oct 13 14:28:17 2006
Subject: [Mp4-tech] [Video] H.264: What to do in case of a P-frame loss?
References: <20061011085308.GA7879@gmx.de>
Message-ID:
Dear Luqman and Sugeeth,
just to further clarify. The standard describes how an intact bitstream is decoded.
A conformant decoder is allowed to crash if there is any error in the bitstream
Fortunately error robust decoders can be implemented by using error concealment techniques (i.e. filling the holes!!). Some error concealment (probably not the most advanced) is implemented in the reference software (different algorithms are utilized wheter only a part of a picture or the whole picture is lost - i think that this was previously discussed in this mailing list, including the links to the documents describing the algorithm - you should be able to find it). Implementing more advanced error concealment algorithms is a way for companies to differentiate their products.
As you said, the reference decoder support error concealment in the case of loss of NAL units. Bit error concealment is not implemented, i.e. if one bit is damaged you should remove the whole NALU.
In the encoder there are several things that can be done do make easier the job of the decoder, for example forcing intra pictures/macroblocks for stopping temporal error propagation, using multiple slices per pictures and eventually flexible macroblock Ordering (FMO) in order to limit the part of the picture that is lost. These things can be done using the reference encoder. Another possibility is using redundant slices ( I didn't test it personally, but an implementation of redundant slices should be included in the latest version of JM).
regards,
Manuel
-----Original Message-----
From: mp4-tech-bounces@lists.mpegif.org on behalf of Luqman
Sent: Fri 13/10/2023 12:04
To: mp4-tech@lists.mpegif.org
Cc:
Subject: Re: [Mp4-tech] Re: Mp4-tech Digest, Vol 39, Issue 8
hi Sugeeth,
thanks for you reply.
> Sugeeth wanted us to know:
>
>In H.264 we dont send Frames, Instead we send the encoded information in
>the Form Of Nalunits. The Nalunits normally contain coded information of
>1 slice. If A Nalunit is lost, with the help of error resilience
>mechanisms and the remaining nal units that constitute the frame, the
>remaining frame can be retrieved.
>
>I dont think Error Resilience is defined in the standard, it is
>something that we implement with our own logics.
>
You are correct; the standard does not say much on error resilience topic.
A quick search on the word "loss" led me to 8.2.5.2 and page 90
(redundant_pic_cnt).
Anyhow, your reply did help me rethink about my problem. I think even
loss of a whole frame should be reconstructable with help of motion
vectors of preceeding and succeeding frames.
Regards,
--
Luqman
-----Original Message-----
From: mp4-tech-bounces@lists.mpegif.org on behalf of Luqman
Sent: Wed 11/10/2023 10:53
To: mp4-tech@lists.mpegif.org
Cc:
Subject: [Mp4-tech] [Video] H.264: What to do in case of a P-frame loss?
I have a video clip consisting of following frames:
I -> P -> B
Now, once I frame is lost, no decoding of video is possible. But when P
frame is lost, is there a slight possibility of correctly decoding P or
B frame with any error concealment methods?
Actually, I am doing a simulation on h.264 frame loss and would appreciate
your views.
Regards,
--
Luqman
From sma com.dtu.dk Fri Oct 13 20:08:51 2006
From: sma com.dtu.dk (Shankar Manuel Aghito)
Date: Fri Oct 13 14:28:24 2006
Subject: [Mp4-tech] Dropping NAL units on bit errors: Best approach?
References: <20061013105249.GB6578@gmx.de>
Message-ID:
The first approach is quite simple and works fine for me.
You should set the encoder and the decoder to use Annex B output format (there are parameters in the configuration files).
What I am doing is searching for 0x00000001 in the bitstream. That will indicate the start of each NAL unit.
I actually did not studied carefully all the details in Annex B, but in my experience this always works (the number of NALUs always correspond to the expected number).
If you then remove entire NALUs from the bitstream the decoder will conceal for the lost NALUs.
Note that if you loose entire pictures, you should enable the error concealment in the decoder configuration file.
You should never remove the first two NALUs which contain Sequence and Picture parameter set.
Normally I also set Log2MaxFNumMinus4 such that MaxFNum >= number_of_frames_to_encode, otherwise sometimes the decoder crashes (I think it happens when you remove NALUs in two consecutive frames, corresponding to the positions where the counter restarts, but if you set this parameter high enough, this will never happen)
I am not normally using B frames but I think that if you use B frames you might also need to take care of Log2MaxPOCLsbMinus4
Best regards,
Manuel
-----Original Message-----
From: mp4-tech-bounces@lists.mpegif.org on behalf of Luqman
Sent: Fri 13/10/2023 12:52
To: mp4-tech@lists.mpegif.org
Cc:
Subject: [Mp4-tech] Dropping NAL units on bit errors: Best approach?
hello,
I like to simulate video over UMTS link and then drop all NAL units
containg bit error after the transport.
One possibility would be to read the bitstream file directly, look for
start_code_prefixes, i.e. 0x000000, to find NAL unit boundaries, and
copy everything except for errored NAL units in a new file.
Second approach would involve editing code in decoder directly. I am
working with reference decoder software JM10.2.
Since the standard is very complex and I am just a novice on this topic,
I was wondering if the first approach wouldn't be more appropriate for my
purpose. With my limited experience with h264 working on encoded stream
file seems to be more straightforward and universal solution.
I would appreciate any comments on this.
Regards,
--
Luqman
From garysull windows.microsoft.com Fri Oct 13 13:03:19 2006
From: garysull windows.microsoft.com (Gary Sullivan)
Date: Fri Oct 13 15:10:12 2006
Subject: [Mp4-tech] H264: Emulation prevention Bytes
In-Reply-To: <20061013140449.GA31590@lambdastream.com>
Message-ID: <03CB47D9C3F8074498E4653F814D6E8F02744429@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
Samuel (et al),
I think you have made a good point about the treatment of the fourth
byte of the replacement pattern. I think it would be useful to clarify
that aspect in 7.4.1.1 in a future revision of the standard. I will try
to bring this to the attention of the JVT for action. The timing of
this remark is good, as I am preparing an input document on the topic of
corrections and clarifications of the text for submission by Monday.
Best Regards,
Gary Sullivan
+> -----Original Message-----
+> From: mp4-tech-bounces@lists.mpegif.org
+> [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Samuel Rivas
+> Sent: Friday, October 13, 2023 7:05 AM
+> To: mp4-tech@lists.mpegif.org
+> Subject: Re: [Mp4-tech] H264: Emulation prevention Bytes
+>
+> Gary,
+>
+> > You may say that the standard is somewhat confusing on
+> this topic, and
+> > it may be true that this part is not especially easy to read, but I
+> > believe it is sufficiently clear (and if you find some particular
+> > missing thing, please let us know and we'll try to fix
+> it). When reading
+> > it, it may be helpful to keep the following things in mind:
+>
+> I did not mean that the standard was ambiguous or incomplete. I is
+> just that that informative section confused me too the first
+> time I read
+> it. Reading NAL unit syntax definition gave me an idea (that was
+> correct) that clashed with what I understood in the
+> informative section.
+> Further reading in the reference code source made it
+> perfectly clear. So
+> the specification is correct, I have nothing to say against it.
+>
+> Since Satendra seems to have the same problem I had, I
+> tried to clarify
+> where the confusion took place. I pointed what misled me and why.
+> Whether it is my problem or the standard's is subject to discussion.
+>
+> I understand that I cited an excerpt of an informative
+> section and I
+> did not say anything of the normative information which, for me, is
+> perfectly clear. Sorry if that annoyed you.
+>
+> Finally, just to make clear what I am missing, and then it may be
+> evaluated as an useful correction or just my misunderstanding:
+>
+> In section 7.4.1.1 it reads that a bit pattern 00000000 00000000
+> 00000011 000000xx must be laid to replace any 00000000
+> 00000000 000000xx
+> pattern. For me, what is not clear is that for sequeneces
+> such as 0x00
+> 0x00 0x00 0x00 ..., after the first substitution 0x00 0x00 0x03 0x00
+> 0x00, the fourth byte takes part of both 00000000 00000000 00000011
+> 00000000 pattern and the next 00000000 00000000 000000xx pattern.
+>
+> It is clear in NAL unit syntax though. But when reading
+> the two parts
+> I was not able whether the problem was that I misunderstood
+> the normative
+> part or the informative part.
+>
+> Regards.
+> --
+> Samuel
+> _______________________________________________
+> NOTE: Please use clear subject lines for your posts. Include
+> [audio, [video], [systems], [general] or another
+> apppropriate identifier to indicate the type of question you have.
+>
+> Note: Conduct on the mailing list is subject to the
+> Antitrust guidelines found at
+> http://www.mpegif.org/public/documents/vault/mp-out-30042-Ant
itrust.php
+>
From garysull windows.microsoft.com Fri Oct 13 18:05:11 2006
From: garysull windows.microsoft.com (Gary Sullivan)
Date: Fri Oct 13 20:22:08 2006
Subject: [Mp4-tech] [Video] question on level_prefix of H.264
In-Reply-To: <20061013234515.10199.qmail@web56403.mail.re3.yahoo.com>
Message-ID: <03CB47D9C3F8074498E4653F814D6E8F027446C6@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
For the High profile, there is an indirect constraint on the value of
level_prefix due to the constraints on the range of values during the
transform coefficient decoding process (inverse transform, etc.). I am
not 100% sure what the maximum value is, but I think it is somewhere in
the neighborhood of 20. I think Lowell Winger knows what it is (copying
him).
Best Regards,
Gary Sullivan
________________________________
From: Nancy Johnson [mailto:nancyjohnson111@yahoo.com]
Sent: Friday, October 13, 2023 4:45 PM
To: Gary Sullivan; mp4-tech@lists.mpegif.org
Subject: [Mp4-tech] [Video] question on level_prefix of H.264
Dear Experts,
On page 249 and 250 of ITU-T Rec. H.264 (03/2005), the value of
level_prefix is limited to not greater than 15 for base/main/extended
profiles. But there is no such limit for high profile. Without this, how
to control the size of level_prefix and level[i] for CAVLC in the
hardware? Note that level[i] is related to levelCode, which is related
to ((1<<(level_prefix-3))-4096)? Thanks.
Rgs,
Nancy
Nancy Johnson wrote:
Thanks a lot, Dr. Sullivan. That's all my question on
H.264 currently and I have got all the answers from you.
Best Regards,
Nancy Johnson
Gary Sullivan wrote:
I believe the answer is Yes.
Best Regards,
Gary
________________________________
From: Nancy Johnson
[mailto:nancyjohnson111@yahoo.com]
Sent: Tuesday, July 11, 2023 12:40 PM
To: Gary Sullivan;
mp4-tech@lists.mpegif.org
Subject: RE: [Mp4-tech] [Video] two
questions on H.264 HRD
Thank you so much for helping me clarify
this fundamental issue. Now I don't have any question on HRD. So it's
time for me to ask the similar question on DUT for output timing
conformance:
Will the DUT be assumed to know all the
scheduling info of HSS just as the HRD? If yes, are these info sent to
DUT by other means not specified in the spec? if no, does it mean the
DUT has to figure them out by ways which are not specified in the spec?
Best Regards,
Nancy Johnson
Gary Sullivan
wrote:
I believe the answer is Yes.
(And if the HSS is using an
"interpolated" schedule, you can also assume that the HRD "knows" what
that schedule is as well.)
Best Regards,
Gary Sullivan
________________________________
From: Nancy Johnson
[mailto:nancyjohnson111@yahoo.com]
Sent: Monday, July 10, 2023 4:50 PM
To: Gary Sullivan;
mp4-tech@lists.mpegif.org
Subject: RE: [Mp4-tech] [Video] two
questions on H.264 HRD
Can I derive from "HSS and HRD are
hypothetical" that "HRD will use the same SchedSelIdx value as that used
by HSS (let's temporarily exclude the case that HSS uses an
"interpolated" delivery schedule mentioned in spec p271 to simplify my
question)? If no, how should the HRD determine SchedSelIdx value it
should use for initial_cpb_removal_delay? If this is out of the scope of
the spec, I don't think the behavior of HRD is fully specified.
Sorry for still bothering you for this
question. Thanks a lot.
Best Regards,
Nancy Johnson
Gary Sullivan
wrote:
I suppose that the issue of needing to
feed the bitstream to the decoder in some fashion (including selecting
the SchedSelIdx or interpolated schedule and getting the data into the
decoder according to that schedule somehow) is the reason for the
concept of the HSS. Although the details of how to do that are out of
scope, I think the standard is pretty clear on what to do. The "H" in
HSS and HRD, of course, stands for hypothetical, which is an important
thing to keep in mind.
Best Regards,
Gary Sullivan
________________________________
From: Nancy Johnson
[mailto:nancyjohnson111@yahoo.com]
Sent: Friday, July 07, 2023 6:13 PM
To: Gary Sullivan;
mp4-tech@lists.mpegif.org
Subject: RE: [Mp4-tech] two questions on
H.264 HRD
Dr. Sullivan,
Thanks for providing these valuable
information. Regarding to the value of SchedSelIdx,
1. I believe the HRD is a golden model
which will be used to test the conformance of bitstreams and real
decoders.
2. I believe the behavior of the HRD
have been accurately specified in the spec due to 1. However, if I were
asked to write a behavior model of the HRD by C or Verilog using the
spec, I don't know how the HRD can determine the value of
initial_cpb_removal_delay[SchedSelIdx] (at least it will influence the
coded picture removal time from the CPB and further influence the
decoded picture output time) because I can not find any information in
the spec for the HRD to know the value of SchedSelIdx it should use.
Maybe the HRD can derive an interpolated
initial_cpb_removal_delay according to the actual bit rate it detected.
Maybe the HRD is assumed to know an exact or interpolated value of
SchedSelIdx from some system level info outside the bitstream. But this
is not mentioned in the spec.
I wish my question was invalid just
because I misunderstood something or missed something.
Thanks a lot.
Best Regards,
Nancy Johnson
Gary Sullivan
wrote:
Regarding question 1 -- I think you
would need to read the HD DVD specs to find out, but personally I would
not recommend trying to sell a lot of units of an HD DVD player that
can't be output timing conforming at least the vast majority of the time
for the vast majority of movie content.
Regarding question 2 -- It is important
to distinguish between the operation of a real decoder in a real system
environment and decoder or bitstream unit testing for conformance. For
output timing conformance testing purposes, we assume that the HSS can
force-feed the decoder in a manner consistent with the standard somehow,
but we really don't care how. It doesn't have to exclusively consist of
the use of information within the bitstream. Also note that HRD decoder
testing is not necessarily performed by just selecting a value of
SchedSelIdx -- there is also the possibility of "interpolated"
scheduling. There are really two different kinds of constraints
specified in the standard -- checks that a conforming bitstream must be
able to fulfill and checks that a conforming decoder must be able to
fulfill. It's important not to confuse the two. Also, when operating
in a real system environment, the system will ordinarily have some
additional way of conveying the bitstream and associated timing
information to the decoder. In the case of HD DVD there are a
significant amount of timing issues that are controlled at the MPEG-2
systems level rather than needing to rely on the information within the
video elementary bitstream and I believe the system-level information
and operation should ordinarily be considered more important to the
actual operation of a real decoder in such an application environment.
Best Regards,
Gary Sullivan
________________________________
From: mp4-tech-bounces@lists.mpegif.org
[mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Nancy Johnson
Sent: Thursday, July 06, 2023 4:38 PM
To: mp4-tech@lists.mpegif.org
Subject: [Mp4-tech] two questions on
H.264 HRD
Dear H.264 experts,
Could you please help me to figure out
these 2 questions?
1. For HD-DVD decoding application, is
it necessary for the H.264 decoder to claim output timing decoder
conformance? It seems that for this case the decoder can be fed the bit
stream in an "on demand" way.
2. According to page 267 equation C-7 of
H.264 03/2005, the removal time of the access unit from the CPB will be
influenced by initial_cpb_removal_delay[SchedSelIdx]. Although
initial_cpb_removal_delay[i] (i=0~cpb_cnt_minus1) are sent to HRD by
buffering period SEI message (page 277 section D.1.1 of H.264 03/2005),
I can not find a way in the H.264 stream definition for the HRD to know
the specific value of SchedSelIdx in equation C-7. If this is true, how
to make sure the value of SchedSelIdx in equation C-7 used by DUT are
the same as that used by HRD? (Is this necessary for the decoder to meet
output timing conformance?)
Thanks a lot.
Sincerely yours,
Nancy Johnson
________________________________
Sneak preview the all-new Yahoo.com
. It's
not radically different. Just radically better.
________________________________
Want to be your own boss? Learn how on
Yahoo! Small Business.
_______________________________________________
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
________________________________
How low will we go? Check out Yahoo!
Messenger's low PC-to-Phone call rates.
_______________________________________________
NOTE: Please use clear subject lines for
your posts. Include [audio, [video], [systems], [general] or another
apppropriate identifier to indicate the type of question you have.
Note: Conduct on the mailing list is
subject to the Antitrust guidelines found at
http://www.mpegif.org/public/documents/vault/mp-out-30042-Antitrust.php
________________________________
Do you Yahoo!?
Get on board. You're invited
to try the new Yahoo! Mail Beta.
________________________________
Sneak preview the all-new Yahoo.com
. It's
not radically different. Just radically better.
________________________________
Get your email and more, right on the new Yahoo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061013/3be05f96/attachment-0001.html
From nancyjohnson111 yahoo.com Fri Oct 13 17:45:15 2006
From: nancyjohnson111 yahoo.com (Nancy Johnson)
Date: Sat Oct 14 13:28:07 2006
Subject: [Mp4-tech] [Video] question on level_prefix of H.264
Message-ID: <20061013234515.10199.qmail@web56403.mail.re3.yahoo.com>
Dear Experts,
On page 249 and 250 of ITU-T Rec. H.264 (03/2005), the value of level_prefix is limited to not greater than 15 for base/main/extended profiles. But there is no such limit for high profile. Without this, how to control the size of level_prefix and level[i] for CAVLC in the hardware? Note that level[i] is related to levelCode, which is related to ((1<<(level_prefix-3))-4096)? Thanks.
Rgs,
Nancy
Nancy Johnson wrote:
Thanks a lot, Dr. Sullivan. That's all my question on H.264 currently and I have got all the answers from you.
Best Regards,
Nancy Johnson
Gary Sullivan wrote:
I believe the answer is Yes.
Best Regards,
Gary
---------------------------------
From: Nancy Johnson [mailto:nancyjohnson111@yahoo.com]
Sent: Tuesday, July 11, 2023 12:40 PM
To: Gary Sullivan; mp4-tech@lists.mpegif.org
Subject: RE: [Mp4-tech] [Video] two questions on H.264 HRD
Thank you so much for helping me clarify this fundamental issue. Now I don't have any question on HRD. So it's time for me to ask the similar question on DUT for output timing conformance:
Will the DUT be assumed to know all the scheduling info of HSS just as the HRD? If yes, are these info sent to DUT by other means not specified in the spec? if no, does it mean the DUT has to figure them out by ways which are not specified in the spec?
Best Regards,
Nancy Johnson
Gary Sullivan wrote:
I believe the answer is Yes.
(And if the HSS is using an "interpolated" schedule, you can also assume that the HRD "knows" what that schedule is as well.)
Best Regards,
Gary Sullivan
---------------------------------
From: Nancy Johnson [mailto:nancyjohnson111@yahoo.com]
Sent: Monday, July 10, 2023 4:50 PM
To: Gary Sullivan; mp4-tech@lists.mpegif.org
Subject: RE: [Mp4-tech] [Video] two questions on H.264 HRD
Can I derive from "HSS and HRD are hypothetical" that "HRD will use the same SchedSelIdx value as that used by HSS (let's temporarily exclude the case that HSS uses an "interpolated" delivery schedule mentioned in spec p271 to simplify my question)? If no, how should the HRD determine SchedSelIdx value it should use for initial_cpb_removal_delay? If this is out of the scope of the spec, I don't think the behavior of HRD is fully specified.
Sorry for still bothering you for this question. Thanks a lot.
Best Regards,
Nancy Johnson
Gary Sullivan wrote:
I suppose that the issue of needing to feed the bitstream to the decoder in some fashion (including selecting the SchedSelIdx or interpolated schedule and getting the data into the decoder according to that schedule somehow) is the reason for the concept of the HSS. Although the details of how to do that are out of scope, I think the standard is pretty clear on what to do. The "H" in HSS and HRD, of course, stands for hypothetical, which is an important thing to keep in mind.
Best Regards,
Gary Sullivan
---------------------------------
From: Nancy Johnson [mailto:nancyjohnson111@yahoo.com]
Sent: Friday, July 07, 2023 6:13 PM
To: Gary Sullivan; mp4-tech@lists.mpegif.org
Subject: RE: [Mp4-tech] two questions on H.264 HRD
Dr. Sullivan,
Thanks for providing these valuable information. Regarding to the value of SchedSelIdx,
1. I believe the HRD is a golden model which will be used to test the conformance of bitstreams and real decoders.
2. I believe the behavior of the HRD have been accurately specified in the spec due to 1. However, if I were asked to write a behavior model of the HRD by C or Verilog using the spec, I don't know how the HRD can determine the value of initial_cpb_removal_delay[SchedSelIdx] (at least it will influence the coded picture removal time from the CPB and further influence the decoded picture output time) because I can not find any information in the spec for the HRD to know the value of SchedSelIdx it should use.
Maybe the HRD can derive an interpolated initial_cpb_removal_delay according to the actual bit rate it detected. Maybe the HRD is assumed to know an exact or interpolated value of SchedSelIdx from some system level info outside the bitstream. But this is not mentioned in the spec.
I wish my question was invalid just because I misunderstood something or missed something.
Thanks a lot.
Best Regards,
Nancy Johnson
Gary Sullivan wrote:
Regarding question 1 -- I think you would need to read the HD DVD specs to find out, but personally I would not recommend trying to sell a lot of units of an HD DVD player that can't be output timing conforming at least the vast majority of the time for the vast majority of movie content.
Regarding question 2 -- It is important to distinguish between the operation of a real decoder in a real system environment and decoder or bitstream unit testing for conformance. For output timing conformance testing purposes, we assume that the HSS can force-feed the decoder in a manner consistent with the standard somehow, but we really don't care how. It doesn't have to exclusively consist of the use of information within the bitstream. Also note that HRD decoder testing is not necessarily performed by just selecting a value of SchedSelIdx -- there is also the possibility of "interpolated" scheduling. There are really two different kinds of constraints specified in the standard -- checks that a conforming bitstream must be able to fulfill and checks that a conforming decoder must be able to fulfill. It's important not to confuse the two. Also, when operating in a real system environment, the system will ordinarily have some additional way of conveying the
bitstream and associated timing information to the decoder. In the case of HD DVD there are a significant amount of timing issues that are controlled at the MPEG-2 systems level rather than needing to rely on the information within the video elementary bitstream and I believe the system-level information and operation should ordinarily be considered more important to the actual operation of a real decoder in such an application environment.
Best Regards,
Gary Sullivan
---------------------------------
From: mp4-tech-bounces@lists.mpegif.org [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Nancy Johnson
Sent: Thursday, July 06, 2023 4:38 PM
To: mp4-tech@lists.mpegif.org
Subject: [Mp4-tech] two questions on H.264 HRD
Dear H.264 experts,
Could you please help me to figure out these 2 questions?
1. For HD-DVD decoding application, is it necessary for the H.264 decoder to claim output timing decoder conformance? It seems that for this case the decoder can be fed the bit stream in an "on demand" way.
2. According to page 267 equation C-7 of H.264 03/2005, the removal time of the access unit from the CPB will be influenced by initial_cpb_removal_delay[SchedSelIdx]. Although initial_cpb_removal_delay[i] (i=0~cpb_cnt_minus1) are sent to HRD by buffering period SEI message (page 277 section D.1.1 of H.264 03/2005), I can not find a way in the H.264 stream definition for the HRD to know the specific value of SchedSelIdx in equation C-7. If this is true, how to make sure the value of SchedSelIdx in equation C-7 used by DUT are the same as that used by HRD? (Is this necessary for the decoder to meet output timing conformance?)
Thanks a lot.
Sincerely yours,
Nancy Johnson
---------------------------------
Sneak preview the all-new Yahoo.com. It's not radically different. Just radically better.
---------------------------------
Want to be your own boss? Learn how on Yahoo! Small Business.
_______________________________________________
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
---------------------------------
How low will we go? Check out Yahoo! Messenger?s low PC-to-Phone call rates.
_______________________________________________
NOTE: Please use clear subject lines for your posts. Include [audio, [video], [systems], [general] or another apppropriate identifier to indicate the type of question you have.
Note: Conduct on the mailing list is subject to the Antitrust guidelines found at http://www.mpegif.org/public/documents/vault/mp-out-30042-Antitrust.php
---------------------------------
Do you Yahoo!?
Get on board. You're invited to try the new Yahoo! Mail Beta.
---------------------------------
Sneak preview the all-new Yahoo.com. It's not radically different. Just radically better.
---------------------------------
Get your email and more, right on the new Yahoo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061013/e9e35e5d/attachment-0001.html
From M.A.J.Barzilaij student.TUDelft.NL Sat Oct 14 14:28:42 2006
From: M.A.J.Barzilaij student.TUDelft.NL (Barzilaij)
Date: Sat Oct 14 13:28:12 2006
Subject: [Mp4-tech] PSNR of B frames.
References: <03CFB4D273F08D459F94B315B7E119580DEE6A@SRV602.tudelft.net>
<03CFB4D273F08D459F94B315B7E119580DEE6B@SRV602.tudelft.net>
<03CFB4D273F08D459F94B315B7E119580DEE6C@SRV602.tudelft.net>
Message-ID: <03CFB4D273F08D459F94B315B7E119580DEE6D@SRV602.tudelft.net>
Dear Experts,
It turns out in all my simulations (scalable mode) with the JSVM, that the B frames in the hierarchical B frames structure always have a higher initial QP and therefore a lower PSNR value than the I or P frames (e.g. I or P frames have a PSNR of 38 while B frames have a PSNR of 34).
During simulation with VQM Software I analyzed different frame rates with similar bitrates (CIF format -- 7.5, 15 and 30fps on 100, 200, 500 and 1000kbit/s). In general, even for rather slow moving video content, the highest framerate was preferred over others for any bitrate setting. It seems that with extra bitrate budget, increasing framerate is always preferred over increasing PSNR of lower temporal levels. Since the B frames can be constructed with little data, jerky or unnatural motion is very easy to combat.
Currently I am unable to find good encoder settings such that a lowering the framerate becomes more useful. My question is the following;
Why do B frames have a lower QP and is there a way to adjust the initial QP value of the B frames? More general, is there a way to increase the PSNR of these frames to the PSNR of the I or P frames.
Any feedback is appreciated.
Kind Regards,
Mark Barzilay
VQM Software: http://www.its.bldrdoc.gov/n3/video/vqmsoftware.htm
If asked, I can send some results or more info about my research.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061014/3704652b/attachment-0001.html
From garysull windows.microsoft.com Sat Oct 14 14:01:22 2006
From: garysull windows.microsoft.com (Gary Sullivan)
Date: Sat Oct 14 16:10:09 2006
Subject: [Mp4-tech] PSNR of B frames.
In-Reply-To: <03CFB4D273F08D459F94B315B7E119580DEE6D@SRV602.tudelft.net>
Message-ID: <03CB47D9C3F8074498E4653F814D6E8F027F9A33@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
Mark (et al),
The basic idea is that if you code a "Frame A" and use that as a
reference for prediction when coding a second "Frame B" and do not use
Frame B to predict anything else, the bits that you spend to improve the
quality of Frame A will not only improve the fidelity of Frame A itself
but will also reduce the number of bits that you need to use to code
Frame B to the desired degree of fidelity. So those bits provide a
benefit for the coding of both Frame A and Frame B, whereas the bits
that you spend to improve the quality of Frame B only benefit the
fidelity of Frame B itself. You therefore get more "bang for the buck"
by coding Frame A well than by coding Frame B well.
The same principle applies hierarchically as well. As you build up the
structure from layer to layer, the "bang for the buck" generally
decreases.
The result is that the average fidelity is best when the pictures that
form the basis of later predictions are coded with relatively high
quality.
All of this is under the control of the encoder, however. Encoders
don't need to do that if they don't want to. There is probably some
relatively-easy way to control that aspect in the JSVM software, but I
am not personally sufficiently familiar with it to instruct you how.
Best Regards,
Gary Sullivan
________________________________
From: mp4-tech-bounces@lists.mpegif.org
[mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Barzilaij
Sent: Saturday, October 14, 2023 4:29 AM
To: mp4-tech@lists.mpegif.org
Subject: [Mp4-tech] PSNR of B frames.
Dear Experts,
It turns out in all my simulations (scalable mode) with the
JSVM, that the B frames in the hierarchical B frames structure always
have a higher initial QP and therefore a lower PSNR value than the I or
P frames (e.g. I or P frames have a PSNR of 38 while B frames have a
PSNR of 34).
During simulation with VQM Software I analyzed different frame
rates with similar bitrates (CIF format -- 7.5, 15 and 30fps on 100,
200, 500 and 1000kbit/s). In general, even for rather slow moving video
content, the highest framerate was preferred over others for any bitrate
setting. It seems that with extra bitrate budget, increasing framerate
is always preferred over increasing PSNR of lower temporal levels. Since
the B frames can be constructed with little data, jerky or unnatural
motion is very easy to combat.
Currently I am unable to find good encoder settings such that a
lowering the framerate becomes more useful. My question is the
following;
Why do B frames have a lower QP and is there a way to adjust the
initial QP value of the B frames? More general, is there a way to
increase the PSNR of these frames to the PSNR of the I or P frames.
Any feedback is appreciated.
Kind Regards,
Mark Barzilay
VQM Software:
http://www.its.bldrdoc.gov/n3/video/vqmsoftware.htm
If asked, I can send some results or more info about my
research.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061014/8ce17bc4/attachment.html
From bravearun rediffmail.com Sun Oct 15 07:34:02 2006
From: bravearun rediffmail.com (arun menon)
Date: Sun Oct 15 21:22:08 2006
Subject: [Mp4-tech] H264 Corrupted Bitstreams
Message-ID: <20061015063050.11835.qmail@webmail90.rediffmail.com>
Dear Friends,
I want to test the robustness of my H264 decoder and was looking out for some corrupted h264 bitstreams. I would really appreciate if you can help me in this regard. I would like to know if there is any site from where i can download the same.
Thanks,
Arun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061015/08c48805/attachment.html
From tanrui huawei.com Mon Oct 16 10:27:31 2006
From: tanrui huawei.com (Tan Rui -- Huawei)
Date: Mon Oct 16 09:16:07 2006
Subject: [Mp4-tech] [H.264]A question about the colPic
Message-ID: <000b01c6f0c2$403ab9f0$6497460a@china.huawei.com>
Hi, All Experts,
When I read the Table 8-6 in the H.264 which gives the calculation about the colPic. I find it is difficult to understand the following conditions:
When (field_pic_flag==0 && RefPicList1[0]==a complementary field pair && md_field_decoding_flag==1), the colPic will determined by the
CurrMbAddr, Which will be the Top-field_To_Top-field or Bottom-field_To_Bottom-field mapping.
My question is that : I think the mapping should be the Top-field_To_Bottom-field or Bottom-field_To_Top-field, because the timing gap between
the opposite fields will be shorter than the timing gap between the same fields. Can someone make it clear? Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061016/1729f9c6/attachment.html
From gchhappy 126.com Mon Oct 16 16:25:07 2006
From: gchhappy 126.com (Guo Chunhui)
Date: Mon Oct 16 09:16:12 2006
Subject: [Mp4-tech] Testing YUV sequences for video conference encoder
References: <200610151607.k9FG7ZiD025876@lists1.magma.ca>
Message-ID: <004701c6f0f4$3537e5a0$7b0010ac@aaa>
Dear Experts,
Can anybody tell me what typical YUV sequences I should use to do the speed and subjective quality testing of my video encoder which aims at video conference apllication?
If there is any, where can I download it?
Thanks in advance!
Best Regards,
William
From sma com.dtu.dk Mon Oct 16 12:01:25 2006
From: sma com.dtu.dk (Shankar Manuel Aghito)
Date: Mon Oct 16 09:16:17 2006
Subject: [Mp4-tech] H264 Corrupted Bitstreams
Message-ID:
You can use this simple matlab script to create your corrupted
bitstreams, i.e. with missing NALUs
function removenalus(filename,damagefilename,naluindexes)
% Load the uncorrupted stream
fid=fopen(filename);
data=fread(fid,'uint8');
fclose(fid);
% Find initial position of NALUs
nalus=(filter([1 2 2 2],1,[1; 1; 1; data])==1);nalus=nalus(4:end);
nalupositions=find(nalus)-3;
% Find the length of the NALUs
nalulengths=[nalupositions(2:end);length(data)+1]-nalupositions;
% Order the NALUs to be removed
for i=sort(naluindexes,'descend')
data(nalupositions(i):nalupositions(i)+nalulengths(i)-1)=[];
end
% Save the stream with removed NALUs
fid=fopen(damagefilename,'w');
data=fwrite(fid,data,'uint8');
fclose(fid);
----------
Example:
removenalus('test.264','test_damaged.264',[10 20 35])
Will create the corrupted bitstream test_damaged.264 by removing the
10th, 20th and 35th NALUs from test.264
This will only work if you set the encoder and decoder to work with
Annex B output format, not RTP.
this is an implementation of what is described in
http://lists.mpegif.org/pipermail/mp4-tech/2006-October/006919.html
best regards,
Manuel
-----Original Message-----
From: mp4-tech-bounces@lists.mpegif.org
[mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of arun menon
Sent: 15. oktober 2006 08:31
To: mp4-tech@lists.mpegif.org
Subject: [Mp4-tech] H264 Corrupted Bitstreams
Dear Friends,
I want to test the robustness of my H264 decoder and was looking
out for some corrupted h264 bitstreams. I would really appreciate if you
can help me in this regard. I would like to know if there is any site
from where i can download the same.
Thanks,
Arun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061016/75df53ea/attachment.html
From garysull windows.microsoft.com Mon Oct 16 12:02:19 2006
From: garysull windows.microsoft.com (Gary Sullivan)
Date: Mon Oct 16 14:16:06 2006
Subject: [Mp4-tech] RE: ??: RE: ??: RE: the range of level_prefix in CAVLC
In-Reply-To:
Message-ID: <03CB47D9C3F8074498E4653F814D6E8F027F9C9B@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
Lowell,
Many thanks. Can you possibly provide the analogous limits for bit
depths 9-14? I hope to add this information into the text of the
standard as an informative NOTE in the next corrigendum cycle. (See
item 83 of JVT-U210.)
Best Regards,
Gary Sullivan
+> -----Original Message-----
+> From: Winger, Lowell [mailto:Lowell.Winger@lsi.com]
+> Sent: Monday, October 16, 2023 10:34 AM
+> To: Gary Sullivan; Nancy Johnson; mp4-tech@lists.mpegif.org
+> Subject: FW: ??: RE: ??: RE: the range of level_prefix in CAVLC
+>
+>
+>
+> Nancy, for High Profile the maximum level_prefix is 19 for
+> 8-bit video.
+>
+> Best Regards,
+> Lowell Winger, LSI Logic
+>
+>
+>
From garysull windows.microsoft.com Mon Oct 16 13:41:28 2006
From: garysull windows.microsoft.com (Gary Sullivan)
Date: Mon Oct 16 16:04:06 2006
Subject: [Mp4-tech] RE: ??: RE: ??: RE: the range of level_prefix in CAVLC
Message-ID: <03CB47D9C3F8074498E4653F814D6E8F027F9D48@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
Oops. That should be JVT-T210, not JVT-U210.
Best Regards,
Gary Sullivan
+> -----Original Message-----
+> From: Gary Sullivan
+> Sent: Monday, October 16, 2023 11:02 AM
+> To: 'Winger, Lowell'; Nancy Johnson; mp4-tech@lists.mpegif.org
+> Subject: RE: ??: RE: ??: RE: the range of level_prefix in CAVLC
+>
+> Lowell,
+>
+> Many thanks. Can you possibly provide the analogous limits
+> for bit depths 9-14? I hope to add this information into
+> the text of the standard as an informative NOTE in the next
+> corrigendum cycle. (See item 83 of JVT-U210.)
+>
+> Best Regards,
+>
+> Gary Sullivan
+>
+> +> -----Original Message-----
+> +> From: Winger, Lowell [mailto:Lowell.Winger@lsi.com]
+> +> Sent: Monday, October 16, 2023 10:34 AM
+> +> To: Gary Sullivan; Nancy Johnson; mp4-tech@lists.mpegif.org
+> +> Subject: FW: ??: RE: ??: RE: the range of level_prefix in CAVLC
+> +>
+> +>
+> +>
+> +> Nancy, for High Profile the maximum level_prefix is 19 for
+> +> 8-bit video.
+> +>
+> +> Best Regards,
+> +> Lowell Winger, LSI Logic
+> +>
+> +>
+> +>
From nancyjohnson111 yahoo.com Mon Oct 16 13:41:57 2006
From: nancyjohnson111 yahoo.com (Nancy Johnson)
Date: Mon Oct 16 16:34:08 2006
Subject: [Mp4-tech] Re: the range of level_prefix in CAVLC
In-Reply-To:
Message-ID: <20061016194157.93645.qmail@web56406.mail.re3.yahoo.com>
Winger and Gary,
Thanks a lot. Will this limit on level_prefix for High Profile be added to the SPEC or it is derived from the request (ex., section 8.5.10 on Cij) that the AC/DC levels should be within -2^(7+BitDepth) and 2^(7+BitDepth)-1 (for 8-bit video, BitDepth=8)?
If it is the latter, I analyzed the mechanism for CAVLC and found that when level_prefix=19, it is still possible for level[i] out of range of [-2^15,2^15-1]. See the following for detail:
According to section 7.3.5.3.1, the max possible value for abs(level[i]) when level_prefix=19 is:
(((min(15,level_prefix) << suffixLength) + level_suffix + ((1<<(level_prefix-3))-4096) + 4)/2
Since the max possible value of level_suffix is 2^16-1 for level_prefix=19 and suffixLength <= 6, so the max possible value for abs(leve[i]) is (15<<6 + 2^16-1 + 2^16 - 4096 + 4)/2 = 63969 = 0xF9E1, which is out of range of [-2^15,2^15-1]. If level_prefix=18, the abs(level[i]) will <= (15<<6 + 2^15-1 + 2^15-4096+4)/2=0x79E1, which is in range of [-2^15,2^15-1].
Could you please point where I missed for the above analysis? Thanks.
Rgs,
Nancy
"Winger, Lowell" wrote:
Nancy, for High Profile the maximum level_prefix is 19 for 8-bit video.
Best Regards,
Lowell Winger, LSI Logic
---------------------------------
Stay in the know. Pulse on the new Yahoo.com. Check it out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061016/e85ae9d0/attachment.html
From garysull windows.microsoft.com Mon Oct 16 15:30:37 2006
From: garysull windows.microsoft.com (Gary Sullivan)
Date: Mon Oct 16 17:40:07 2006
Subject: [Mp4-tech] RE: the range of level_prefix in CAVLC
In-Reply-To: <20061016194157.93645.qmail@web56406.mail.re3.yahoo.com>
Message-ID: <03CB47D9C3F8074498E4653F814D6E8F027F9E42@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
This is a derived limit. It is not in the spec and we provide no
assurances that it is correct. The question we are trying to answer is
not whether it is possible for a coefficient value to be out of range
when level_prefix has a particular value, but rather whether it is
possible for everything that is specified in the standard to be within
the ranges that are specified in the standard when level_prefix has a
particular value. In the High and High 4:2:2 profiles, level_prefix is
allowed to have any value that does not force some other constraint
expressed in the standard to be violated.
Best Regards,
Gary Sullivan
________________________________
From: Nancy Johnson [mailto:nancyjohnson111@yahoo.com]
Sent: Monday, October 16, 2023 12:42 PM
To: Winger, Lowell; Gary Sullivan; mp4-tech@lists.mpegif.org
Subject: Re: the range of level_prefix in CAVLC
Winger and Gary,
Thanks a lot. Will this limit on level_prefix for High Profile
be added to the SPEC or it is derived from the request (ex., section
8.5.10 on Cij) that the AC/DC levels should be within -2^(7+BitDepth)
and 2^(7+BitDepth)-1 (for 8-bit video, BitDepth=8)?
If it is the latter, I analyzed the mechanism for CAVLC and
found that when level_prefix=19, it is still possible for level[i] out
of range of [-2^15,2^15-1]. See the following for detail:
According to section 7.3.5.3.1, the max possible value for
abs(level[i]) when level_prefix=19 is:
(((min(15,level_prefix) << suffixLength) + level_suffix +
((1<<(level_prefix-3))-4096) + 4)/2
Since the max possible value of level_suffix is 2^16-1 for
level_prefix=19 and suffixLength <= 6, so the max possible value for
abs(leve[i]) is (15<<6 + 2^16-1 + 2^16 - 4096 + 4)/2 = 63969 = 0xF9E1,
which is out of range of [-2^15,2^15-1]. If level_prefix=18, the
abs(level[i]) will <= (15<<6 + 2^15-1 + 2^15-4096+4)/2=0x79E1, which is
in range of [-2^15,2^15-1].
Could you please point where I missed for the above analysis?
Thanks.
Rgs,
Nancy
"Winger, Lowell" wrote:
Nancy, for High Profile the maximum level_prefix is 19
for 8-bit video.
Best Regards,
Lowell Winger, LSI Logic
________________________________
Stay in the know. Pulse on the new Yahoo.com. Check it out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061016/0b3e5020/attachment.html
From nancyjohnson111 yahoo.com Mon Oct 16 17:16:54 2006
From: nancyjohnson111 yahoo.com (Nancy Johnson)
Date: Mon Oct 16 20:46:08 2006
Subject: [Mp4-tech] RE: the range of level_prefix in CAVLC
In-Reply-To: <03CB47D9C3F8074498E4653F814D6E8F027F9E42@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
Message-ID: <20061016231654.16245.qmail@web56403.mail.re3.yahoo.com>
Gary,
Thank you very much for pointing out this important thing for specification. Now I think 19 is correct. For level_prefix=19 (BitDepth=8), it's still possible for everything that is specified in the standard to be within the ranges that are specified in the standard. For level_prefix=20 (BitDepth=8), it seems to be impossible for everything that is specified in the standard to be within the ranges that are specified in the standard due to the effect of (1 << (level_prefix -3)).
Rgs,
Nancy
Gary Sullivan wrote:
This is a derived limit. It is not in the spec and we provide no assurances that it is correct. The question we are trying to answer is not whether it is possible for a coefficient value to be out of range when level_prefix has a particular value, but rather whether it is possible for everything that is specified in the standard to be within the ranges that are specified in the standard when level_prefix has a particular value. In the High and High 4:2:2 profiles, level_prefix is allowed to have any value that does not force some other constraint expressed in the standard to be violated.
Best Regards,
Gary Sullivan
---------------------------------
From: Nancy Johnson [mailto:nancyjohnson111@yahoo.com]
Sent: Monday, October 16, 2023 12:42 PM
To: Winger, Lowell; Gary Sullivan; mp4-tech@lists.mpegif.org
Subject: Re: the range of level_prefix in CAVLC
Winger and Gary,
Thanks a lot. Will this limit on level_prefix for High Profile be added to the SPEC or it is derived from the request (ex., section 8.5.10 on Cij) that the AC/DC levels should be within -2^(7+BitDepth) and 2^(7+BitDepth)-1 (for 8-bit video, BitDepth=8)?
If it is the latter, I analyzed the mechanism for CAVLC and found that when level_prefix=19, it is still possible for level[i] out of range of [-2^15,2^15-1]. See the following for detail:
According to section 7.3.5.3.1, the max possible value for abs(level[i]) when level_prefix=19 is:
(((min(15,level_prefix) << suffixLength) + level_suffix + ((1<<(level_prefix-3))-4096) + 4)/2
Since the max possible value of level_suffix is 2^16-1 for level_prefix=19 and suffixLength <= 6, so the max possible value for abs(leve[i]) is (15<<6 + 2^16-1 + 2^16 - 4096 + 4)/2 = 63969 = 0xF9E1, which is out of range of [-2^15,2^15-1]. If level_prefix=18, the abs(level[i]) will <= (15<<6 + 2^15-1 + 2^15-4096+4)/2=0x79E1, which is in range of [-2^15,2^15-1].
Could you please point where I missed for the above analysis? Thanks.
Rgs,
Nancy
"Winger, Lowell" wrote:
Nancy, for High Profile the maximum level_prefix is 19 for 8-bit video.
Best Regards,
Lowell Winger, LSI Logic
---------------------------------
Stay in the know. Pulse on the new Yahoo.com. Check it out.
---------------------------------
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061016/953bd471/attachment-0001.html
From dicksonliang yahoo.com Mon Oct 16 19:23:39 2006
From: dicksonliang yahoo.com (Dickson Liang)
Date: Tue Oct 17 09:16:08 2006
Subject: [Mp4-tech] 14496-3 BSAC decoder question
Message-ID: <20061017012339.41513.qmail@web36502.mail.mud.yahoo.com>
Hi,
I have a question when decoding BSAC encoded audio streams. In the spec (14496-3:2005 subpart 4), there is a help element named "numOfLayer", which is the number of large-step layers that the fine grain data is divided into. Can anyone tell me how to determine its value from the decoded syntax elements? Thanks very much.
Regards,
Dickson Liang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061016/667fde8a/attachment-0001.html
From rgomathi sarayusoftech.com Tue Oct 17 11:47:44 2006
From: rgomathi sarayusoftech.com (Gomathi R)
Date: Tue Oct 17 09:16:16 2006
Subject: Fw: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
Message-ID: <005b01c6f1ab$9c243cc0$b664a8c0@gomathi>
----- Original Message -----
From: "Gomathi R"
To:
Sent: Friday, October 13, 2023 5:27 PM
Subject: Re: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
> Hi Girish.
>
> Ya,I too have the same 2001 version.
> In page number 44
>
> 1.first they are refering 14496-2(Mpeg-4 video) Annex-K for Mpeg-4 video
> 2.reference for Mpeg-4 Audio
> 3.Scene decription streams
> 4.mpeg-2 AAC
> 5.Mpeg-2 Audio layers I,II,III
> 6.finally jpeg it seems
>
> for mpeg 1/2 video where they gave.May be i would misunderstand.
> Please correct me if i'm wrong
>
> Thanks & Regards
> Gomathi.
>
> ----- Original Message -----
> From:
> To: "Gomathi R"
> Sent: Friday, October 13, 2023 4:43 PM
> Subject: Re: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
>
>
>>
>> That's strange. I am looking at it right now and I can see it and I am
>> looking at the 2001 version (the 2005 version must surely have it,
>> possibly in a different place). Are you sure you are looking at section
>> 8.6.7 (or whichever section that reads "DecoderSpecificInfo")?
>>
>> Regards,
>> Girish
>>
>>> Hi Girish,
>>> I do referred that section but there is no reference for Mpeg 1/2
>>> video over there.
>>>
>>> Thanks & Regargs
>>> Gomathi
>>> ----- Original Message -----
>>> From: Girish Shenoy
>>> To: Gomathi R
>>> Sent: Friday, October 13, 2023 10:40 AM
>>> Subject: RE: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file
>>> format
>>>
>>>
>>> Hi Gomathi,
>>>
>>> ObjectTypeIndication is the right place to look for the information
>>> you
>>> need. You've already hit the nail on the head.
>>> But please be aware that the mdat need not necessarily be directly
>>> decodable without the help of other boxes in the file. Especially in the
>>> case where the file has more than one stream, the mdat may have data
>>> from both streams interleaved with each other.
>>>
>>> Regards,
>>> Girish
>>>
>>> -----Original Message-----
>>> From: mp4-tech-bounces@lists.mpegif.org
>>> [mailto:mp4-tech-bounces@lists.mpegif.org]On Behalf Of Gomathi R
>>> Sent: Wednesday, October 11, 2023 9:01 AM
>>> To: mp4-tech@lists.mpegif.org
>>> Subject: Re: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file
>>> format
>>>
>>>
>>> Thanks a lot Liang.....
>>>
>>> Actually I'm going to parse the .mp4 file and have to extract audio n
>>> video streams seperately to give as input to the corresponding
>>> decoders.ie.I'm going to write the code for Mp4 parser according to
>>> 14496-part 14.
>>>
>>> so for example if the .mp4 contains mpeg-4 video i will read 0x20 as
>>> ObjectTypeIndication,then i ll extract the DecoderSpecificInfo as the
>>> header for .m4v file(as per 14496-2) and after that i will simply put
>>> the encoded samples from the "mdat" area.SO, if the codecs are
>>> predefined then i can study about their header info .If the case is like
>>> this how should i proceed....Please tell me some suggestions.......
>>>
>>> Thanks & Regards
>>> Gomathi.
>>>
>>> ----- Original Message -----
>>> From: Dickson Liang
>>> To: Gomathi R
>>> Sent: Tuesday, October 10, 2023 9:10 PM
>>> Subject: Re: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file
>>> format
>>>
>>>
>>> Hi,
>>>
>>> MP4 is a file container. So in theory and in practical, you can put
>>> almost any kinds of MPEG-related codec inside this format. For
>>> example, you can put MPEG2 layer2 audio and MPEG4 H264 video into the
>>> same MP4 file. Just like a bag -- you can put any codec you like into
>>> the MP4 container.
>>>
>>> Regards,
>>>
>>> Dickson Liang
>>>
>>> Gomathi R wrote:
>>>
>>> ----- Original Message -----
>>> From: Gomathi R
>>> To: mp4-tech@lists.mpegif.org
>>> Sent: Tuesday, October 10, 2023 12:33 PM
>>> Subject: Regarding codecs supported by Mp4 file format
>>>
>>>
>>> Hi all...
>>> I'm new to this group and this mail is regarding codecs supported
>>> by
>>> mp4 file format.
>>> I've reffered ISO/IEC 14496-part 14(Mp4 - File Format) where they
>>> simply mentioned as AudioSampleEntry,VideoSampleEntry...but i want
>>> the actual codecs supported from standard reference......
>>>
>>> Please help me out...
>>>
>>> Thanks in Advance
>>>
>>> Please reply ASAP......
>>>
>>>
>>> Cheers,
>>> Gomathi.
>>> _______________________________________________
>>> NOTE: Please use clear subject lines for your posts. Include
>>> [audio,
>>> [video], [systems], [general] or another apppropriate identifier to
>>> indicate the type of question you have.
>>>
>>> Note: Conduct on the mailing list is subject to the Antitrust
>>> guidelines found at
>>> http://www.mpegif.org/public/documents/vault/mp-out-30042-Antitrust.php
>>>
>>>
>>>
>>>
>>> ----------------------------------------------------------------------------
>>>
>>> MailScanner, and is
>>> believed to be clean.
>>> --
>>> This message has been scanned for viruses and
>>> dangerous content by MailScanner, and is
>>> believed to be clean.
>>> --
>>> This message has been scanned for viruses and
>>> dangerous content by MailScanner, and is
>>> believed to be clean.
>>>
>>>
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>
From girish dgbmicro.com Tue Oct 17 12:48:58 2006
From: girish dgbmicro.com (Girish Shenoy)
Date: Tue Oct 17 09:16:21 2006
Subject: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
In-Reply-To: <005b01c6f1ab$9c243cc0$b664a8c0@gomathi>
Message-ID:
Hi Gomathi,
My apologies!! You are right, there is no mention about the format of
decoderSpecificInfo for Mpeg 1/2 video.
Whether this container will be present for mpeg 1/2 video is not clear.
Hopefully, somebody with more knowledge on the subject will be able to
answer the question.
Regards,
Girish
-----Original Message-----
From: Gomathi R [mailto:rgomathi@sarayusoftech.com]
Sent: Tuesday, October 17, 2023 10:48 AM
To: Girish Shenoy; mp4-tech@lists.mpegif.org
Subject: Fw: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file
format
----- Original Message -----
From: "Gomathi R"
To:
Sent: Friday, October 13, 2023 5:27 PM
Subject: Re: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
> Hi Girish.
>
> Ya,I too have the same 2001 version.
> In page number 44
>
> 1.first they are refering 14496-2(Mpeg-4 video) Annex-K for Mpeg-4 video
> 2.reference for Mpeg-4 Audio
> 3.Scene decription streams
> 4.mpeg-2 AAC
> 5.Mpeg-2 Audio layers I,II,III
> 6.finally jpeg it seems
>
> for mpeg 1/2 video where they gave.May be i would misunderstand.
> Please correct me if i'm wrong
>
> Thanks & Regards
> Gomathi.
>
> ----- Original Message -----
> From:
> To: "Gomathi R"
> Sent: Friday, October 13, 2023 4:43 PM
> Subject: Re: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
>
>
>>
>> That's strange. I am looking at it right now and I can see it and I am
>> looking at the 2001 version (the 2005 version must surely have it,
>> possibly in a different place). Are you sure you are looking at section
>> 8.6.7 (or whichever section that reads "DecoderSpecificInfo")?
>>
>> Regards,
>> Girish
>>
>>> Hi Girish,
>>> I do referred that section but there is no reference for Mpeg 1/2
>>> video over there.
>>>
>>> Thanks & Regargs
>>> Gomathi
>>> ----- Original Message -----
>>> From: Girish Shenoy
>>> To: Gomathi R
>>> Sent: Friday, October 13, 2023 10:40 AM
>>> Subject: RE: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file
>>> format
>>>
>>>
>>> Hi Gomathi,
>>>
>>> ObjectTypeIndication is the right place to look for the information
>>> you
>>> need. You've already hit the nail on the head.
>>> But please be aware that the mdat need not necessarily be directly
>>> decodable without the help of other boxes in the file. Especially in the
>>> case where the file has more than one stream, the mdat may have data
>>> from both streams interleaved with each other.
>>>
>>> Regards,
>>> Girish
>>>
>>> -----Original Message-----
>>> From: mp4-tech-bounces@lists.mpegif.org
>>> [mailto:mp4-tech-bounces@lists.mpegif.org]On Behalf Of Gomathi R
>>> Sent: Wednesday, October 11, 2023 9:01 AM
>>> To: mp4-tech@lists.mpegif.org
>>> Subject: Re: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file
>>> format
>>>
>>>
>>> Thanks a lot Liang.....
>>>
>>> Actually I'm going to parse the .mp4 file and have to extract audio n
>>> video streams seperately to give as input to the corresponding
>>> decoders.ie.I'm going to write the code for Mp4 parser according to
>>> 14496-part 14.
>>>
>>> so for example if the .mp4 contains mpeg-4 video i will read 0x20 as
>>> ObjectTypeIndication,then i ll extract the DecoderSpecificInfo as the
>>> header for .m4v file(as per 14496-2) and after that i will simply put
>>> the encoded samples from the "mdat" area.SO, if the codecs are
>>> predefined then i can study about their header info .If the case is like
>>> this how should i proceed....Please tell me some suggestions.......
>>>
>>> Thanks & Regards
>>> Gomathi.
>>>
>>> ----- Original Message -----
>>> From: Dickson Liang
>>> To: Gomathi R
>>> Sent: Tuesday, October 10, 2023 9:10 PM
>>> Subject: Re: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file
>>> format
>>>
>>>
>>> Hi,
>>>
>>> MP4 is a file container. So in theory and in practical, you can put
>>> almost any kinds of MPEG-related codec inside this format. For
>>> example, you can put MPEG2 layer2 audio and MPEG4 H264 video into the
>>> same MP4 file. Just like a bag -- you can put any codec you like into
>>> the MP4 container.
>>>
>>> Regards,
>>>
>>> Dickson Liang
>>>
>>> Gomathi R wrote:
>>>
>>> ----- Original Message -----
>>> From: Gomathi R
>>> To: mp4-tech@lists.mpegif.org
>>> Sent: Tuesday, October 10, 2023 12:33 PM
>>> Subject: Regarding codecs supported by Mp4 file format
>>>
>>>
>>> Hi all...
>>> I'm new to this group and this mail is regarding codecs supported
>>> by
>>> mp4 file format.
>>> I've reffered ISO/IEC 14496-part 14(Mp4 - File Format) where they
>>> simply mentioned as AudioSampleEntry,VideoSampleEntry...but i want
>>> the actual codecs supported from standard reference......
>>>
>>> Please help me out...
>>>
>>> Thanks in Advance
>>>
>>> Please reply ASAP......
>>>
>>>
>>> Cheers,
>>> Gomathi.
>>> _______________________________________________
>>> NOTE: Please use clear subject lines for your posts. Include
>>> [audio,
>>> [video], [systems], [general] or another apppropriate identifier to
>>> indicate the type of question you have.
>>>
>>> Note: Conduct on the mailing list is subject to the Antitrust
>>> guidelines found at
>>> http://www.mpegif.org/public/documents/vault/mp-out-30042-Antitrust.php
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
----
>>>
>>> MailScanner, and is
>>> believed to be clean.
>>> --
>>> This message has been scanned for viruses and
>>> dangerous content by MailScanner, and is
>>> believed to be clean.
>>> --
>>> This message has been scanned for viruses and
>>> dangerous content by MailScanner, and is
>>> believed to be clean.
>>>
>>>
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
From rgomathi sarayusoftech.com Tue Oct 17 13:08:09 2006
From: rgomathi sarayusoftech.com (Gomathi R)
Date: Tue Oct 17 09:16:25 2006
Subject: Fw: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
Message-ID: <007501c6f1b6$cfed11c0$b664a8c0@gomathi>
----- Original Message -----
From: "Gomathi R"
To: "Girish Shenoy"
Sent: Tuesday, October 17, 2023 12:06 PM
Subject: Re: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
> Hi Girish,
> Thank U so much for ur reply .If some experts in the mp4-tech list
> could give me the refence for Mpeg 1/2 video i'll be thankful.
>
> Also while referring mpeg-4 audio doc the AudioObjectType in
> AudioSpecificConfig contains CELP,HVXC,TwinVQ....etc..... should i need to
> support that also.if it is so CELP,TwinVQ are seperate coders to give them
> the DecoderSpecificInfo as header and encoded samples after
> that?.....Please clarify me.
>
> Thanks & Regards,
> Gomathi.
>
> ----- Original Message -----
> From: "Girish Shenoy"
> To: "Gomathi R" ;
> Sent: Tuesday, October 17, 2023 11:48 AM
> Subject: RE: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
>
>
>> Hi Gomathi,
>>
>> My apologies!! You are right, there is no mention about the format of
>> decoderSpecificInfo for Mpeg 1/2 video.
>> Whether this container will be present for mpeg 1/2 video is not clear.
>>
>> Hopefully, somebody with more knowledge on the subject will be able to
>> answer the question.
>>
>> Regards,
>> Girish
>>
>> -----Original Message-----
>> From: Gomathi R [mailto:rgomathi@sarayusoftech.com]
>> Sent: Tuesday, October 17, 2023 10:48 AM
>> To: Girish Shenoy; mp4-tech@lists.mpegif.org
>> Subject: Fw: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file
>> format
>>
>>
>> ----- Original Message -----
>> From: "Gomathi R"
>> To:
>> Sent: Friday, October 13, 2023 5:27 PM
>> Subject: Re: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file format
>>
>>
>>> Hi Girish.
>>>
>>> Ya,I too have the same 2001 version.
>>
>>> In page number 44
>>>
>>> 1.first they are refering 14496-2(Mpeg-4 video) Annex-K for Mpeg-4 video
>>> 2.reference for Mpeg-4 Audio
>>> 3.Scene decription streams
>>> 4.mpeg-2 AAC
>>> 5.Mpeg-2 Audio layers I,II,III
>>> 6.finally jpeg it seems
>>>
>>> for mpeg 1/2 video where they gave.May be i would misunderstand.
>>> Please correct me if i'm wrong
>>>
>>> Thanks & Regards
>>> Gomathi.
>>>
>>> ----- Original Message -----
>>> From:
>>> To: "Gomathi R"
>>> Sent: Friday, October 13, 2023 4:43 PM
>>> Subject: Re: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file
>>> format
>>>
>>>
>>>>
>>>> That's strange. I am looking at it right now and I can see it and I am
>>>> looking at the 2001 version (the 2005 version must surely have it,
>>>> possibly in a different place). Are you sure you are looking at section
>>>> 8.6.7 (or whichever section that reads "DecoderSpecificInfo")?
>>>>
>>>> Regards,
>>>> Girish
>>>>
>>>>> Hi Girish,
>>>>> I do referred that section but there is no reference for Mpeg 1/2
>>>>> video over there.
>>>>>
>>>>> Thanks & Regargs
>>>>> Gomathi
>>>>> ----- Original Message -----
>>>>> From: Girish Shenoy
>>>>> To: Gomathi R
>>>>> Sent: Friday, October 13, 2023 10:40 AM
>>>>> Subject: RE: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file
>>>>> format
>>>>>
>>>>>
>>>>> Hi Gomathi,
>>>>>
>>>>> ObjectTypeIndication is the right place to look for the information
>>>>> you
>>>>> need. You've already hit the nail on the head.
>>>>> But please be aware that the mdat need not necessarily be directly
>>>>> decodable without the help of other boxes in the file. Especially in
>>>>> the
>>>>> case where the file has more than one stream, the mdat may have data
>>>>> from both streams interleaved with each other.
>>>>>
>>>>> Regards,
>>>>> Girish
>>>>>
>>>>> -----Original Message-----
>>>>> From: mp4-tech-bounces@lists.mpegif.org
>>>>> [mailto:mp4-tech-bounces@lists.mpegif.org]On Behalf Of Gomathi R
>>>>> Sent: Wednesday, October 11, 2023 9:01 AM
>>>>> To: mp4-tech@lists.mpegif.org
>>>>> Subject: Re: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file
>>>>> format
>>>>>
>>>>>
>>>>> Thanks a lot Liang.....
>>>>>
>>>>> Actually I'm going to parse the .mp4 file and have to extract audio
>>>>> n
>>>>> video streams seperately to give as input to the corresponding
>>>>> decoders.ie.I'm going to write the code for Mp4 parser according to
>>>>> 14496-part 14.
>>>>>
>>>>> so for example if the .mp4 contains mpeg-4 video i will read 0x20 as
>>>>> ObjectTypeIndication,then i ll extract the DecoderSpecificInfo as the
>>>>> header for .m4v file(as per 14496-2) and after that i will simply put
>>>>> the encoded samples from the "mdat" area.SO, if the codecs are
>>>>> predefined then i can study about their header info .If the case is
>>>>> like
>>>>> this how should i proceed....Please tell me some suggestions.......
>>>>>
>>>>> Thanks & Regards
>>>>> Gomathi.
>>>>>
>>>>> ----- Original Message -----
>>>>> From: Dickson Liang
>>>>> To: Gomathi R
>>>>> Sent: Tuesday, October 10, 2023 9:10 PM
>>>>> Subject: Re: [Mp4-tech] Fw: Regarding codecs supported by Mp4 file
>>>>> format
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> MP4 is a file container. So in theory and in practical, you can
>>>>> put
>>>>> almost any kinds of MPEG-related codec inside this format. For
>>>>> example, you can put MPEG2 layer2 audio and MPEG4 H264 video into the
>>>>> same MP4 file. Just like a bag -- you can put any codec you like into
>>>>> the MP4 container.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Dickson Liang
>>>>>
>>>>> Gomathi R wrote:
>>>>>
>>>>> ----- Original Message -----
>>>>> From: Gomathi R
>>>>> To: mp4-tech@lists.mpegif.org
>>>>> Sent: Tuesday, October 10, 2023 12:33 PM
>>>>> Subject: Regarding codecs supported by Mp4 file format
>>>>>
>>>>>
>>>>> Hi all...
>>>>> I'm new to this group and this mail is regarding codecs
>>>>> supported
>>>>> by
>>>>> mp4 file format.
>>>>> I've reffered ISO/IEC 14496-part 14(Mp4 - File Format) where
>>>>> they
>>>>> simply mentioned as AudioSampleEntry,VideoSampleEntry...but i want
>>>>> the actual codecs supported from standard reference......
>>>>>
>>>>> Please help me out...
>>>>>
>>>>> Thanks in Advance
>>>>>
>>>>> Please reply ASAP......
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Gomathi.
>>>>> _______________________________________________
>>>>> NOTE: Please use clear subject lines for your posts. Include
>>>>> [audio,
>>>>> [video], [systems], [general] or another apppropriate identifier to
>>>>> indicate the type of question you have.
>>>>>
>>>>> Note: Conduct on the mailing list is subject to the Antitrust
>>>>> guidelines found at
>>>>> http://www.mpegif.org/public/documents/vault/mp-out-30042-Antitrust.php
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>> ----
>>>>>
>>>>> MailScanner, and is
>>>>> believed to be clean.
>>>>> --
>>>>> This message has been scanned for viruses and
>>>>> dangerous content by MailScanner, and is
>>>>> believed to be clean.
>>>>> --
>>>>> This message has been scanned for viruses and
>>>>> dangerous content by MailScanner, and is
>>>>> believed to be clean.
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> This message has been scanned for viruses and
>>>> dangerous content by MailScanner, and is
>>>> believed to be clean.
>>>>
>>>>
>>>> --
>>>> This message has been scanned for viruses and
>>>> dangerous content by MailScanner, and is
>>>> believed to be clean.
>>>
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>
From Wesley.DeNeve UGent.be Tue Oct 17 11:11:07 2006
From: Wesley.DeNeve UGent.be (Wesley De Neve)
Date: Tue Oct 17 09:16:30 2006
Subject: [Mp4-tech] Testing YUV sequences for video conference encoder
References: <200610151607.k9FG7ZiD025876@lists1.magma.ca>
<004701c6f0f4$3537e5a0$7b0010ac@aaa>
Message-ID: <05a601c6f1c3$cc84f4a0$0b00a8c0@persephone>
Dear William,
I would suggest to start having a look at the test setup used in the
following paper by Wiegand et al.: "Rate-Constrained Coder Control and
Comparison of Video Coding Standards".
Best regards,
Wesley De Neve
Guo Chunhui wrote:
> Dear Experts,
>
> Can anybody tell me what typical YUV sequences I should use to do the
> speed and subjective quality testing of my video encoder which aims
> at video conference apllication?
>
> If there is any, where can I download it?
>
> Thanks in advance!
>
> Best Regards,
>
> William
>
>
> _______________________________________________
> 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 shenyueshi gmail.com Wed Oct 18 10:08:07 2006
From: shenyueshi gmail.com (Yueshi Shen)
Date: Wed Oct 18 00:52:09 2006
Subject: [Mp4-tech] AACPlus test footage
Message-ID:
Dear AAC experts,
I am looking for some test data of MPEG-4 HEAAC carried in LATM/LOAS/MPEG-2
TS. Could you please tell me where I can download some of those footages?
Thanks a lot in advance.
Sincerely yours
Yueshi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061018/05faa465/attachment.html
From samuel lambdastream.com Wed Oct 18 08:53:30 2006
From: samuel lambdastream.com (Samuel Rivas)
Date: Wed Oct 18 13:40:07 2006
Subject: [Mp4-tech] Testing YUV sequences for video conference encoder
In-Reply-To: <004701c6f0f4$3537e5a0$7b0010ac@aaa>
References: <200610151607.k9FG7ZiD025876@lists1.magma.ca>
<004701c6f0f4$3537e5a0$7b0010ac@aaa>
Message-ID: <20061018065330.GA8928@lambdastream.com>
Guo Chunhui wrote:
> Dear Experts,
>
> Can anybody tell me what typical YUV sequences I should use to do the speed and subjective quality testing of my video encoder which aims at video conference apllication?
>
> If there is any, where can I download it?
You can start looking here:
http://media.xiph.org/video/derf/
http://meru.cecs.missouri.edu/free_download/videos/
Regards
--
Samuel
From spsatendra gmail.com Wed Oct 18 16:38:00 2006
From: spsatendra gmail.com (Satendra)
Date: Wed Oct 18 13:40:13 2006
Subject: [Mp4-tech] Q-pel interpolation
Message-ID: <594272320610180408k247321f1g3cf7940b07c41800@mail.gmail.com>
Hi,
I want to know the maximum size in bits, the intermediate values of Q-Pel
interpolation may take.
Considering this figure
E F G a b c H I J
d e f g
h i j k m
n p q r
K L M s N P Q
My concern is while interpolating for j, f, q, i, k locations.
Here finally we need to scale/shift the values by 10, does it mean that
intermediate values can be of 18 bits. Hence all the operations of H264
decode can't be completed in 16 bit arithmetic.
Thanks
Satendra
--
-----------------------------------------------------------------------------------------------------------------------------------
"We all agree on the necessity of compromise. We just can't agree on when
it's necessary to compromise." ------Larry Wall
-----------------------------------------------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061018/140dce09/attachment.html
From Alexis.Tourapis dolby.net Wed Oct 18 10:54:30 2006
From: Alexis.Tourapis dolby.net (Tourapis, Alexis)
Date: Wed Oct 18 18:04:09 2006
Subject: [Mp4-tech] RE: [jvt-experts] Q-pel interpolation
Message-ID: <7272EE229DA1AA48B47EBDC47EB0C68B0249FFAF@sapphire.dolby.net>
Dear Matt and Satendra,
I agree with Luca and I would strongly suggest having a look at Frank
Bossen's contributions on this topic. More specifically, you can try and
locate his paper from the 2002 Workshop and Exhibition on MPEG-4
(http://www.m4if.org/wemp2002/tutorialprog.php). If you cannot, you can
always reference his JVT contribution JVT-C037 which can be found here:
http://ftp3.itu.ch/av-arch/jvt-site/2002_05_Fairfax/JVT-C037.doc
Best regards,
Alexis
-----Original Message-----
From: jvt-experts-bounces@lists.rwth-aachen.de
[mailto:jvt-experts-bounces@lists.rwth-aachen.de] On Behalf Of Quinn,
Matt
Sent: Wednesday, October 18, 2023 6:28 AM
To: Luca Piccarreta; Satendra
Cc: jvt-experts@lists.rwth-aachen.de; mp4-tech@lists.mpegif.org
Subject: Re: [jvt-experts] Q-pel interpolation
I found that in order to generate the "j" value, you had to calculate
with 15bit values with a possible range of [-2550,10710] or
[0x760A,0x29D6] (based on input ranges of [0,255]). You have to use the
un-shifted version of the intermidate values for calculating "j". i.e.
you cannot apply the "+16) >> 5" function to these values prior to
calculating "j".
This resulted in "j" values prior to the "+512) >> 10" function with a
range of [-214200,475320] or [0xCBB48,0x740B8] or 20-bits.
Thanks,
Matt Quinn
Scientific-Atlanta, A Cisco Company
-----Original Message-----
From: jvt-experts-bounces@lists.rwth-aachen.de
[mailto:jvt-experts-bounces@lists.rwth-aachen.de] On Behalf Of Luca
Piccarreta
Sent: Wednesday, October 18, 2023 7:13 AM
To: Satendra
Cc: jvt-experts@lists.rwth-aachen.de; mp4-tech@lists.mpegif.org
Subject: Re: [jvt-experts] Q-pel interpolation
Well, not really.
consider the basic H264 MC filter
pix_val = (a-b*5+c*20+d*20-e*5+f+16)>>5
pix_val = ((a+f-b-d) + (c*20+d*20-b*4-e*4+16))>>5
pix_val = ((a+f-b-d)>>2) + (c*5+d*5-b-e+4))>>3
pix_val = ((a+f-b-d)>>2) + (c + d - b -e )+ (c*4+d*4+4))>>3
pix_val = (((((a+f-b-d)>>2) + (c + d - b - e))>> 2) + c+ d +1) >>1
In other words, factor 20 as (16+4) and 5 as (4+1) This should make it
unnecessary shifting to 32 bit arithmetics. Although
it is not necessarily faster.
Cheers,
Luca.
Satendra wrote:
> Hi,
>
> I want to know the maximum size in bits, the intermediate values of
> Q-Pel interpolation may take.
>
> Considering this figure
>
> E F G a b c H
> I J
> d e f g
> h i j k m
> n p q r
> K L M s N P
Q
>
>
> My concern is while interpolating for j, f, q, i, k locations.
> Here finally we need to scale/shift the values by 10, does it mean
> that intermediate values can be of 18 bits. Hence all the operations
> of H264 decode can't be completed in 16 bit arithmetic.
>
> Thanks
> Satendra
> --
>
>
------------------------------------------------------------------------
-----------------------------------------------------------
>
> "We all agree on the necessity of compromise. We just can't agree on
> when it's necessary to compromise." ------Larry Wall
>
------------------------------------------------------------------------
-----------------------------------------------------------
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> jvt-experts mailing list
> jvt-experts@lists.rwth-aachen.de
> http://mailman.rwth-aachen.de/mailman/listinfo/jvt-experts
>
_______________________________________________
jvt-experts mailing list
jvt-experts@lists.rwth-aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/jvt-experts
- - - - - Appended by Scientific Atlanta, a Cisco company - - - - -
This e-mail and any attachments may contain information which is
confidential, proprietary, privileged or otherwise protected by law. The
information is solely intended for the named addressee (or a person
responsible for delivering it to the addressee). If you are not the
intended recipient of this message, you are not authorized to read,
print, retain, copy or disseminate this message or any part of it. If
you have received this e-mail in error, please notify the sender
immediately by return e-mail and delete it from your computer.
_______________________________________________
jvt-experts mailing list
jvt-experts@lists.rwth-aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/jvt-experts
-----------------------------------------
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 dicksonliang yahoo.com Wed Oct 18 10:57:07 2006
From: dicksonliang yahoo.com (Dickson Liang)
Date: Wed Oct 18 19:04:08 2006
Subject: [Mp4-tech] Q-pel interpolation
Message-ID: <20061018175707.12033.qmail@web36506.mail.mud.yahoo.com>
Satendra,
I guess for calculating the "j" pel, you need unsigned 20 (=8+6+6) bits at least for the intermediate values. The first (unsigned) 8 bits are for the signal itself, and each of the 6 bits are for the worst-case interpolation (20+20+1+1=42, so 6 bits).
For other pels such as f,i,q,k, I think 16 bits are definitely enough because you have to use the clipped values to calculate them. Clipped values are unsigned 8bits.
There are other cases in H264 video decoding that 16 bits are not enough. For example, scaling of the chroma DC (after inverse transform is done) would need more than 16 bits.
Dickson Liang
----- Original Message ----
From: Satendra
To: mp4-tech@lists.mpegif.org; jvt-experts@lists.rwth-aachen.de
Sent: Wednesday, October 18, 2023 4:08:00 AM
Subject: [Mp4-tech] Q-pel interpolation
Hi,
I want to know the maximum size in bits, the intermediate values of Q-Pel interpolation may take.
Considering this figure
E F G a b c H I J
d e f g
h i j k m
n p q r
K L M s N P Q
My concern is while interpolating for j, f, q, i, k locations.
Here finally we need to scale/shift the values by 10, does it mean that intermediate values can be of 18 bits. Hence all the operations of H264 decode can't be completed in 16 bit arithmetic.
Thanks
Satendra
--
-----------------------------------------------------------------------------------------------------------------------------------
"We all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise." ------Larry Wall
-----------------------------------------------------------------------------------------------------------------------------------
_______________________________________________
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/20061018/f5bcd15d/attachment.html
From luqman_ngs gmx.net Wed Oct 18 17:58:40 2006
From: luqman_ngs gmx.net (Luqman)
Date: Wed Oct 18 20:04:09 2006
Subject: [Mp4-tech] Dropping NAL units on bit errors: Best approach?
In-Reply-To:
References: <20061013105249.GB6578@gmx.de>
Message-ID: <20061018155840.GA6338@gmx.de>
Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : /pipermail/mp4-tech/attachments/20061018/0580aed7/attachment-0001.bin
From luqman_ngs gmx.net Wed Oct 18 21:05:31 2006
From: luqman_ngs gmx.net (Luqman)
Date: Wed Oct 18 20:04:17 2006
Subject: [Mp4-tech] [Video] H.264: What to do in case of a P-frame loss?
In-Reply-To:
References: <20061011085308.GA7879@gmx.de>
Message-ID: <20061018190531.GA6070@gmx.de>
hi Shankar,
Thank you for your valueable posting. I will tweak configuration files
of encoder and decoder to find the most suitable settings for my
purpose.
Regards,
Luqman
> Shankar Manuel Aghito wanted us to know:
>Dear Luqman and Sugeeth,
>
>just to further clarify. The standard describes how an intact bitstream is decoded.
>A conformant decoder is allowed to crash if there is any error in the bitstream
>
>Fortunately error robust decoders can be implemented by using error concealment techniques (i.e. filling the holes!!). Some error concealment (probably not the most advanced) is implemented in the reference software (different algorithms are utilized wheter only a part of a picture or the whole picture is lost - i think that this was previously discussed in this mailing list, including the links to the documents describing the algorithm - you should be able to find it). Implementing more advanced error concealment algorithms is a way for companies to differentiate their products.
>
>As you said, the reference decoder support error concealment in the case of loss of NAL units. Bit error concealment is not implemented, i.e. if one bit is damaged you should remove the whole NALU.
>
>In the encoder there are several things that can be done do make easier the job of the decoder, for example forcing intra pictures/macroblocks for stopping temporal error propagation, using multiple slices per pictures and eventually flexible macroblock Ordering (FMO) in order to limit the part of the picture that is lost. These things can be done using the reference encoder. Another possibility is using redundant slices ( I didn't test it personally, but an implementation of redundant slices should be included in the latest version of JM).
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : /pipermail/mp4-tech/attachments/20061018/c10e0186/attachment.bin
From sma com.dtu.dk Thu Oct 19 12:50:06 2006
From: sma com.dtu.dk (Shankar Manuel Aghito)
Date: Fri Oct 20 14:34:06 2006
Subject: [Mp4-tech] Dropping NAL units on bit errors: Best approach?
Message-ID:
Hi Luqman,
I've look at the standard and I can see what you say, it seems that that
zero_byte before start_code_prefix_one_3bytes should be present only in
SPS, PPS and in the first NALU of each access unit. I don't know why (I
guess that it is because we are missing something in understanding the
standard), but I am quite sure that the reference software put 4 bytes
0x00000001 in the beginning of each NALU, also for multiple NALUs per
picture, i.e. when there are NALUs that are not the first in the access
unit. Try my matlab script, posted in "RE: [Mp4-tech] H264 Corrupted
Bitstreams" a couple of days ago.
Could someone please explain us this "mystery"?
Also you could try with JM11. I've read of problems with JM10.2 related
to use of multiple slices/picture.
If you still have problems, send encoder/decoder output and also
configuration files
---
About the error concealment parameter in the decoder configuration file.
2 (motion copy) often is the best in my experience. But you will only
see differences when you remove a whole picture, i.e. all the NALUs of
one picture. If you loose only some parts of a picture, different
concealment algorithms are used, but you cannot control that in the
config file.
---
You don't need to have Log2MaxFNumMinus4 soo high! With
Log2MaxFNumMinus4=12 then you can encode 2^(12+4) pictures before the
counter restarts!!!
Regards,
Manuel
-----Original Message-----
From: mp4-tech-bounces@lists.mpegif.org
[mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Luqman
Sent: 18. oktober 2006 17:59
To: mp4-tech@lists.mpegif.org
Subject: Re: [Mp4-tech] Dropping NAL units on bit errors: Best approach?
hi Manuel Shankar,
thanks for your reply.
> Shankar Manuel Aghito wanted us to know:
>The first approach is quite simple and works fine for me.
>You should set the encoder and the decoder to use Annex B output format
(there are parameters in the configuration files).
Now, I have implemented NALU dropping code directly from annexb file.
>
>
>What I am doing is searching for 0x00000001 in the bitstream. That will
>indicate the start of each NAL unit.
>I actually did not studied carefully all the details in Annex B, but in
my experience this always works (the number of NALUs always correspond
to the expected number).
Not every NALU has 0x00 0x00 0x00 0x01 as start code prefix. Some NALUs
can also have 0x00 0x00 0x01 as start code prefix. Only NALUs with SPS,
PPS and first NALU of an access unit contaings a zero byte leading the 3
byte start code prefix.
(page 270: TU-T Rec. H.264 (03/2005) - Prepublished version)
>
>If you then remove entire NALUs from the bitstream the decoder will
>conceal for the lost NALUs.
That is something I am having problem with. Decoder gives different
kinds of warnings and error messages when different NALUs are dropped.
I am not sure whether I should ignore them or try to improve my code to
remove them.
>
>Note that if you loose entire pictures, you should enable the error
>concealment in the decoder configuration file.
I have tried 0,1 and 2 in decoder configuration file for error
concealment but without any visible differencec.
>
>You should never remove the first two NALUs which contain Sequence and
>Picture parameter set.
>
>Normally I also set Log2MaxFNumMinus4 such that MaxFNum >=
>number_of_frames_to_encode, otherwise sometimes the decoder crashes (I
>think it happens when you remove NALUs in two consecutive frames,
>corresponding to the positions where the counter restarts, but if you
>set this parameter high enough, this will never happen)
>
In encoder.cfg I set Log2MaxFNumMinus4 = 12 which is the maximum allowed
value.
>I am not normally using B frames but I think that if you use B frames
>you might also need to take care of Log2MaxPOCLsbMinus4
I am using B frames either.
I will attach output of encoder and decoder for different dropped NALUs.
Hope you can give me some hints on where to look for possible solutions.
Regards,
Luqman
> -----Original Message-----
> From: mp4-tech-bounces@lists.mpegif.org on behalf of Luqman
> Sent: Fri 13/10/2023 12:52
> To: mp4-tech@lists.mpegif.org
> Cc:
> Subject: [Mp4-tech] Dropping NAL units on bit errors: Best
approach?
>
>
>
> hello,
>
> I like to simulate video over UMTS link and then drop all NAL
units
> containg bit error after the transport.
>
> One possibility would be to read the bitstream file directly,
look for
> start_code_prefixes, i.e. 0x000000, to find NAL unit boundaries,
and
> copy everything except for errored NAL units in a new file.
>
> Second approach would involve editing code in decoder directly.
I am
> working with reference decoder software JM10.2.
>
> Since the standard is very complex and I am just a novice on
this topic,
> I was wondering if the first approach wouldn't be more
appropriate for my
> purpose. With my limited experience with h264 working on encoded
stream
> file seems to be more straightforward and universal solution.
>
> I would appreciate any comments on this.
>
> Regards,
>
> --
> Luqman
>
>
--
Luqman
From tinyatom gmail.com Thu Oct 19 17:42:31 2006
From: tinyatom gmail.com (rjay)
Date: Fri Oct 20 14:34:12 2006
Subject: [Mp4-tech] detecting audio profile of a m4a file
Message-ID:
Hello all,
I have an M4a parser that was written using 14496-12:2005, 14496-14:2003 and
14496-1:2004 for reference.
One of my objectives is to find the profile of the audio track (Main, Low
complexity, LTP, HE, etc) and make the decision to play only Low Complexity
files since my decoder only supports low complexity profiles.
>From what i understand, this information is available in the
esds->decoderConfigDescriptor. (7.2.6.6.1 from 14496-12:2005)
The spec has a further reference to 14496-3, subclause 6.2.1 if the objectID
value is 0x40 and I get the 5 bits of audioObjectType as specified in table
1.8 and I find the corresponding profile from the audioObjectType from table
1.1 in 14496-3.
Is this the correct way to be identifying the profile?
Using this logic, m4a files that have been generated using Xilisoft audio
convertor are identified correctly by my parser (and by the MPUI tool)
But I have a whole bunch (dozens) of test files, with different profiles,
that all have the value of 5 bits corresponding to Low complexity, even
though i know the profile is not LC. MP4UI also incorrectly identifies these
files as LC.
Looking at the dump of the headers between say an LTP file generated by
Xilisoft audio convertor and one of the incorrectly identified LTP test
files, I noticed that the ftyp atom has the majorbrand value as mp42 for the
xilisoft generated file, while the incorrectly identified one has the major
brand as isom.
Is there a difference for how the esds atom should be parsed for the 2
ftyps? My understanding was that both are based on 14496-12?
My apologies for the long post.
Thanks in advance,
rjay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061019/80f73864/attachment.html
From dmitriy graphics.cs.msu.ru Fri Oct 20 00:01:17 2006
From: dmitriy graphics.cs.msu.ru (Dmitriy Vatolin)
Date: Fri Oct 20 14:52:08 2006
Subject: [Mp4-tech] WMP vs JPEG-2000
Message-ID: <12710430943.20061020000117@graphics.cs.msu.ru>
Dear all!
In May 2006 Microsoft presented a new format for images - WMP - as
a replacement for JPEG 2000:
> The software maker detailed the new image format Wednesday at the
> Windows Hardware Engineering Conference here. Windows Media Photo will
> be supported in Windows Vista and also be made available for Windows
> XP, Bill Crow, program manager for Windows Media Photo, said in a
> presentation.
>
> In his presentation, Crow showed an image with 24:1 compression that
> visibly contained more detail in the Windows Media Photo format than
> the JPEG and JPEG 2000 formats compressed at the same level.
>
> Still, the image in the Microsoft format was somewhat distorted
> because of the high compression level. Typically digital cameras today
> use 6:1 compression, Crow said. Windows Media Photo should offer
> better pictures at double that level, he said. "We can do it in half
> the size of a JPEG file."
We tested Microsoft's codec of this new format to compare it with 9
JPEG 2000 image coders using PSNR and SSIM metrics.
Please find our results here:
http://www.compression.ru/video/codec_comparison/wmp_codecs_comparison_en.html
Hope they will be interesting for MPEG-4 guys.
Any comments are welcomed to our e-mail!
Yours,
Dr. Vatolin
From jc sj.co.uk Fri Oct 20 17:06:28 2006
From: jc sj.co.uk (John Cox)
Date: Fri Oct 20 19:28:10 2006
Subject: [Mp4-tech] Dropping NAL units on bit errors: Best approach?
In-Reply-To:
References:
Message-ID:
Hi
My guess as to why those have NALUs have extra zeros is that it allows
the decoder to find the start of the unit even if the bitstream is
presented without knowledge of byte-alignment.
It is always legal to pack the end of a nal_unit with extra zeros
(trailing_zero_8bits) so a non-start-of-AU NALU may appear to have three
leading seros but in fact that is one zero on the end of the previous
unit and two leading zeros on this unit. This detail is important if
you are trying to determine the exact byte on which a unit starts (e.g.
when encapsulated in PES the PTS applies to the first unit which starts
in that PES packet).
Regards
John Cox
SJ Consulting
>Hi Luqman,
>
>I've look at the standard and I can see what you say, it seems that that
>zero_byte before start_code_prefix_one_3bytes should be present only in
>SPS, PPS and in the first NALU of each access unit. I don't know why (I
>guess that it is because we are missing something in understanding the
>standard), but I am quite sure that the reference software put 4 bytes
>0x00000001 in the beginning of each NALU, also for multiple NALUs per
>picture, i.e. when there are NALUs that are not the first in the access
>unit. Try my matlab script, posted in "RE: [Mp4-tech] H264 Corrupted
>Bitstreams" a couple of days ago.
>
>Could someone please explain us this "mystery"?
>
>Also you could try with JM11. I've read of problems with JM10.2 related
>to use of multiple slices/picture.
>
>If you still have problems, send encoder/decoder output and also
>configuration files
>
>---
>
>About the error concealment parameter in the decoder configuration file.
>2 (motion copy) often is the best in my experience. But you will only
>see differences when you remove a whole picture, i.e. all the NALUs of
>one picture. If you loose only some parts of a picture, different
>concealment algorithms are used, but you cannot control that in the
>config file.
>
>---
>
>You don't need to have Log2MaxFNumMinus4 soo high! With
>Log2MaxFNumMinus4=12 then you can encode 2^(12+4) pictures before the
>counter restarts!!!
>
>
>
>Regards,
>Manuel
>
>
>-----Original Message-----
>From: mp4-tech-bounces@lists.mpegif.org
>[mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Luqman
>Sent: 18. oktober 2006 17:59
>To: mp4-tech@lists.mpegif.org
>Subject: Re: [Mp4-tech] Dropping NAL units on bit errors: Best approach?
>
>
>hi Manuel Shankar,
>
>thanks for your reply.
>
>> Shankar Manuel Aghito wanted us to know:
>
>>The first approach is quite simple and works fine for me.
>>You should set the encoder and the decoder to use Annex B output format
>(there are parameters in the configuration files).
>
>Now, I have implemented NALU dropping code directly from annexb file.
>>
>>
>>What I am doing is searching for 0x00000001 in the bitstream. That will
>
>>indicate the start of each NAL unit.
>>I actually did not studied carefully all the details in Annex B, but in
>my experience this always works (the number of NALUs always correspond
>to the expected number).
>
>Not every NALU has 0x00 0x00 0x00 0x01 as start code prefix. Some NALUs
>can also have 0x00 0x00 0x01 as start code prefix. Only NALUs with SPS,
>PPS and first NALU of an access unit contaings a zero byte leading the 3
>byte start code prefix.
>
>(page 270: TU-T Rec. H.264 (03/2005) - Prepublished version)
>
>
>>
>>If you then remove entire NALUs from the bitstream the decoder will
>>conceal for the lost NALUs.
>
>That is something I am having problem with. Decoder gives different
>kinds of warnings and error messages when different NALUs are dropped.
>
>I am not sure whether I should ignore them or try to improve my code to
>remove them.
>
>>
>>Note that if you loose entire pictures, you should enable the error
>>concealment in the decoder configuration file.
>
>I have tried 0,1 and 2 in decoder configuration file for error
>concealment but without any visible differencec.
>>
>>You should never remove the first two NALUs which contain Sequence and
>>Picture parameter set.
>>
>>Normally I also set Log2MaxFNumMinus4 such that MaxFNum >=
>>number_of_frames_to_encode, otherwise sometimes the decoder crashes (I
>>think it happens when you remove NALUs in two consecutive frames,
>>corresponding to the positions where the counter restarts, but if you
>>set this parameter high enough, this will never happen)
>>
>
>In encoder.cfg I set Log2MaxFNumMinus4 = 12 which is the maximum allowed
>value.
>
>>I am not normally using B frames but I think that if you use B frames
>>you might also need to take care of Log2MaxPOCLsbMinus4
>
>I am using B frames either.
>
>
>I will attach output of encoder and decoder for different dropped NALUs.
>
>Hope you can give me some hints on where to look for possible solutions.
>
>Regards,
>
>Luqman
>
>
>
>> -----Original Message-----
>> From: mp4-tech-bounces@lists.mpegif.org on behalf of Luqman
>> Sent: Fri 13/10/2023 12:52
>> To: mp4-tech@lists.mpegif.org
>> Cc:
>> Subject: [Mp4-tech] Dropping NAL units on bit errors: Best
>approach?
>>
>>
>>
>> hello,
>>
>> I like to simulate video over UMTS link and then drop all NAL
>units
>> containg bit error after the transport.
>>
>> One possibility would be to read the bitstream file directly,
>look for
>> start_code_prefixes, i.e. 0x000000, to find NAL unit boundaries,
>and
>> copy everything except for errored NAL units in a new file.
>>
>> Second approach would involve editing code in decoder directly.
>I am
>> working with reference decoder software JM10.2.
>>
>> Since the standard is very complex and I am just a novice on
>this topic,
>> I was wondering if the first approach wouldn't be more
>appropriate for my
>> purpose. With my limited experience with h264 working on encoded
>stream
>> file seems to be more straightforward and universal solution.
>>
>> I would appreciate any comments on this.
>>
>> Regards,
>>
>> --
>> Luqman
>>
>>
From garysull windows.microsoft.com Fri Oct 20 14:37:38 2006
From: garysull windows.microsoft.com (Gary Sullivan)
Date: Fri Oct 20 21:46:08 2006
Subject: [Mp4-tech] Dropping NAL units on bit errors: Best approach?
In-Reply-To:
Message-ID: <03CB47D9C3F8074498E4653F814D6E8F028C5912@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
Yes, it's a byte-alignment recovery trick. As John points out, extra
zero-valued bytes can be present between any pair of NAL units, but at
least one such byte is required for the most important NAL units to
enable decoder alignment recovery. Alignment recovery is important in
some scenarios but not others, but the quantity of data necessary to
enable it is so low (about 1-2 bytes per picture) that we decided to
require it to be there all the time.
Best Regards,
Gary Sullivan
+> -----Original Message-----
+> From: mp4-tech-bounces@lists.mpegif.org
+> [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of John Cox
+> Sent: Friday, October 20, 2023 9:06 AM
+> To: Shankar Manuel Aghito
+> Cc: mp4-tech@lists.mpegif.org
+> Subject: Re: [Mp4-tech] Dropping NAL units on bit errors:
+> Best approach?
+>
+> Hi
+>
+> My guess as to why those have NALUs have extra zeros is that
+> it allows
+> the decoder to find the start of the unit even if the bitstream is
+> presented without knowledge of byte-alignment.
+>
+> It is always legal to pack the end of a nal_unit with extra zeros
+> (trailing_zero_8bits) so a non-start-of-AU NALU may appear
+> to have three
+> leading seros but in fact that is one zero on the end of the previous
+> unit and two leading zeros on this unit. This detail is important if
+> you are trying to determine the exact byte on which a unit
+> starts (e.g.
+> when encapsulated in PES the PTS applies to the first unit
+> which starts
+> in that PES packet).
+>
+> Regards
+>
+> John Cox
+> SJ Consulting
+>
+>
+> >Hi Luqman,
+> >
+> >I've look at the standard and I can see what you say, it
+> seems that that
+> >zero_byte before start_code_prefix_one_3bytes should be
+> present only in
+> >SPS, PPS and in the first NALU of each access unit. I don't
+> know why (I
+> >guess that it is because we are missing something in
+> understanding the
+> >standard), but I am quite sure that the reference software
+> put 4 bytes
+> >0x00000001 in the beginning of each NALU, also for multiple
+> NALUs per
+> >picture, i.e. when there are NALUs that are not the first
+> in the access
+> >unit. Try my matlab script, posted in "RE: [Mp4-tech] H264 Corrupted
+> >Bitstreams" a couple of days ago.
+> >
+> >Could someone please explain us this "mystery"?
+> >
+> >Also you could try with JM11. I've read of problems with
+> JM10.2 related
+> >to use of multiple slices/picture.
+> >
+> >If you still have problems, send encoder/decoder output and also
+> >configuration files
+> >
+> >---
+> >
+> >About the error concealment parameter in the decoder
+> configuration file.
+> >2 (motion copy) often is the best in my experience. But you
+> will only
+> >see differences when you remove a whole picture, i.e. all
+> the NALUs of
+> >one picture. If you loose only some parts of a picture, different
+> >concealment algorithms are used, but you cannot control that in the
+> >config file.
+> >
+> >---
+> >
+> >You don't need to have Log2MaxFNumMinus4 soo high! With
+> >Log2MaxFNumMinus4=12 then you can encode 2^(12+4) pictures
+> before the
+> >counter restarts!!!
+> >
+> >
+> >
+> >Regards,
+> >Manuel
+> >
+> >
+> >-----Original Message-----
+> >From: mp4-tech-bounces@lists.mpegif.org
+> >[mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Luqman
+> >Sent: 18. oktober 2006 17:59
+> >To: mp4-tech@lists.mpegif.org
+> >Subject: Re: [Mp4-tech] Dropping NAL units on bit errors:
+> Best approach?
+> >
+> >
+> >hi Manuel Shankar,
+> >
+> >thanks for your reply.
+> >
+> >> Shankar Manuel Aghito wanted us to know:
+> >
+> >>The first approach is quite simple and works fine for me.
+> >>You should set the encoder and the decoder to use Annex B
+> output format
+> >(there are parameters in the configuration files).
+> >
+> >Now, I have implemented NALU dropping code directly from
+> annexb file.
+> >>
+> >>
+> >>What I am doing is searching for 0x00000001 in the
+> bitstream. That will
+> >
+> >>indicate the start of each NAL unit.
+> >>I actually did not studied carefully all the details in
+> Annex B, but in
+> >my experience this always works (the number of NALUs always
+> correspond
+> >to the expected number).
+> >
+> >Not every NALU has 0x00 0x00 0x00 0x01 as start code
+> prefix. Some NALUs
+> >can also have 0x00 0x00 0x01 as start code prefix. Only
+> NALUs with SPS,
+> >PPS and first NALU of an access unit contaings a zero byte
+> leading the 3
+> >byte start code prefix.
+> >
+> >(page 270: TU-T Rec. H.264 (03/2005) - Prepublished version)
+> >
+> >
+> >>
+> >>If you then remove entire NALUs from the bitstream the
+> decoder will
+> >>conceal for the lost NALUs.
+> >
+> >That is something I am having problem with. Decoder gives different
+> >kinds of warnings and error messages when different NALUs
+> are dropped.
+> >
+> >I am not sure whether I should ignore them or try to
+> improve my code to
+> >remove them.
+> >
+> >>
+> >>Note that if you loose entire pictures, you should enable
+> the error
+> >>concealment in the decoder configuration file.
+> >
+> >I have tried 0,1 and 2 in decoder configuration file for error
+> >concealment but without any visible differencec.
+> >>
+> >>You should never remove the first two NALUs which contain
+> Sequence and
+> >>Picture parameter set.
+> >>
+> >>Normally I also set Log2MaxFNumMinus4 such that MaxFNum >=
+> >>number_of_frames_to_encode, otherwise sometimes the
+> decoder crashes (I
+> >>think it happens when you remove NALUs in two consecutive frames,
+> >>corresponding to the positions where the counter restarts,
+> but if you
+> >>set this parameter high enough, this will never happen)
+> >>
+> >
+> >In encoder.cfg I set Log2MaxFNumMinus4 = 12 which is the
+> maximum allowed
+> >value.
+> >
+> >>I am not normally using B frames but I think that if you
+> use B frames
+> >>you might also need to take care of Log2MaxPOCLsbMinus4
+> >
+> >I am using B frames either.
+> >
+> >
+> >I will attach output of encoder and decoder for different
+> dropped NALUs.
+> >
+> >Hope you can give me some hints on where to look for
+> possible solutions.
+> >
+> >Regards,
+> >
+> >Luqman
+> >
+> >
+> >
+> >> -----Original Message-----
+> >> From: mp4-tech-bounces@lists.mpegif.org on behalf of Luqman
+> >> Sent: Fri 13/10/2023 12:52
+> >> To: mp4-tech@lists.mpegif.org
+> >> Cc:
+> >> Subject: [Mp4-tech] Dropping NAL units on bit errors: Best
+> >approach?
+> >>
+> >>
+> >>
+> >> hello,
+> >>
+> >> I like to simulate video over UMTS link and then drop all NAL
+> >units
+> >> containg bit error after the transport.
+> >>
+> >> One possibility would be to read the bitstream file directly,
+> >look for
+> >> start_code_prefixes, i.e. 0x000000, to find NAL unit boundaries,
+> >and
+> >> copy everything except for errored NAL units in a new file.
+> >>
+> >> Second approach would involve editing code in decoder directly.
+> >I am
+> >> working with reference decoder software JM10.2.
+> >>
+> >> Since the standard is very complex and I am just a novice on
+> >this topic,
+> >> I was wondering if the first approach wouldn't be more
+> >appropriate for my
+> >> purpose. With my limited experience with h264 working on encoded
+> >stream
+> >> file seems to be more straightforward and universal solution.
+> >>
+> >> I would appreciate any comments on this.
+> >>
+> >> Regards,
+> >>
+> >> --
+> >> Luqman
+> >>
+> >>
+>
+> _______________________________________________
+> NOTE: Please use clear subject lines for your posts. Include
+> [audio, [video], [systems], [general] or another
+> apppropriate identifier to indicate the type of question you have.
+>
+> Note: Conduct on the mailing list is subject to the
+> Antitrust guidelines found at
+> http://www.mpegif.org/public/documents/vault/mp-out-30042-Ant
+> itrust.php
+>
From luqman_ngs gmx.net Sat Oct 21 00:13:27 2006
From: luqman_ngs gmx.net (Luqman)
Date: Sat Oct 21 10:34:06 2006
Subject: [Mp4-tech] why are there 4 bytes 0x00000001 instead of 3 bytes in
every NALU?
In-Reply-To:
References: <20061018155840.GA6338@gmx.de>
Message-ID: <20061020221326.GC9305@gmx.de>
Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : /pipermail/mp4-tech/attachments/20061021/86f31c25/attachment-0001.bin
From luqman_ngs gmx.net Sat Oct 21 00:35:54 2006
From: luqman_ngs gmx.net (Luqman)
Date: Sat Oct 21 10:34:12 2006
Subject: [Mp4-tech] Dropping NAL units on bit errors: Best approach?
In-Reply-To:
References:
Message-ID: <20061020223554.GA18157@gmx.de>
Hi John,
> John Cox wanted us to know:
>My guess as to why those have NALUs have extra zeros is that it allows
>the decoder to find the start of the unit even if the bitstream is
>presented without knowledge of byte-alignment.
Byte alignment sounds reasonable but I think these zeros belong to the
following NALU....
>
>It is always legal to pack the end of a nal_unit with extra zeros
>(trailing_zero_8bits) so a non-start-of-AU NALU may appear to have
>three
>leading seros but in fact that is one zero on the end of the previous
>unit and two leading zeros on this unit. This detail is important if
>you are trying to determine the exact byte on which a unit starts (e.g.
>when encapsulated in PES the PTS applies to the first unit which starts
>in that PES packet).
This is part of Byte stream NAL unit syntax in the standard:
...
while( more_data_in_byte_stream( ) &&
next_bits( 24 ) !=3D 0x000001 &&
next_bits( 32 ) !=3D 0x00000001 )
trailing_zero_8bits /* equal to 0x00 */
Well, it means 4 bytes (0x00000001) at the border of an NALU are considered
to be start_code_prefix and NOT trailing_zero_8bits. If there are more than
3 zero bytes in the end ONLY then are these preceeding zero bytes part of the
last NALU, i.e. are trailing_zero_8bits.
Example:
0x00000001...............0x00000001...............0x00 0x00000001
In this case second NALU has trailing_zero_8bits whereas first NALU hasn't.
At least this is my understanding and that is how I dropped NALU with my program.
Can anybody confirm or refute that?
Regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : /pipermail/mp4-tech/attachments/20061021/c6a2d630/attachment.bin
From luqman_ngs gmx.net Sat Oct 21 00:45:31 2006
From: luqman_ngs gmx.net (Luqman)
Date: Sat Oct 21 10:34:17 2006
Subject: [Mp4-tech] Dropping NAL units on bit errors: Best approach?
In-Reply-To: <03CB47D9C3F8074498E4653F814D6E8F028C5912@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
References:
<03CB47D9C3F8074498E4653F814D6E8F028C5912@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
Message-ID: <20061020224531.GB18157@gmx.de>
> Gary Sullivan wanted us to know:
>Yes, it's a byte-alignment recovery trick. As John points out, extra
>zero-valued bytes can be present between any pair of NAL units, but at
>least one such byte is required for the most important NAL units to
>enable decoder alignment recovery. Alignment recovery is important in
>some scenarios but not others, but the quantity of data necessary to
>enable it is so low (about 1-2 bytes per picture) that we decided to
>require it to be there all the time.
Thanks Gary for clarifying this. But there is some confusion where the
leading zero byte 0x00 before 3 byte start_code_prefix belongs to.
Example:
0x00000001................0x00000001.................0x00 0x00000001
The extra 0x00 preceeding third 0x00000001 belongs to the second NALU
whereas 0x00000001 belongs to the third NALU.
Similarly in case of second appearance of 0x00000001, these 4 bytes
belong to second NALU.
Am I correct? Or is it only ture in case of SPS, PPS and first NALU of
an access unit / frame / picture?
Regards,
Luqman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : /pipermail/mp4-tech/attachments/20061021/d60f6021/attachment.bin
From jerry.johns nuvation.com Fri Oct 20 15:51:33 2006
From: jerry.johns nuvation.com (Jerry Johns)
Date: Sat Oct 21 10:34:21 2006
Subject: [Mp4-tech] H264 RTP Timestamp
Message-ID:
Hello,
I'm currently in the process of writing a H264 packetizer, and I'm
encountering some difficulty composing the RTP timestamps; in the H264
sample vids I've had, there have been samples which
Had SEI messages, indicating a picture_timing msg which means I can extract
the timing info (is the timing a PTS? Where does the reference 90khz come
from?) - I've also had samples which don't have an SEI, (just parameter sets
and slices), in which case, how do I compose the 32-bit timestamp?
Thank you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061020/20ca256e/attachment.html
From garysull windows.microsoft.com Sat Oct 21 04:34:59 2006
From: garysull windows.microsoft.com (Gary Sullivan)
Date: Sat Oct 21 11:46:06 2006
Subject: [Mp4-tech] Dropping NAL units on bit errors: Best approach?
In-Reply-To: <20061020224531.GB18157@gmx.de>
Message-ID: <03CB47D9C3F8074498E4653F814D6E8F029587C6@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
I don't think you have it right.
The boundary between "byte stream NAL units" and "access units" is
detailed in the standard (mostly Annex B, which is only two pages long).
We made a small modification of the boundary location in a corrigendum
activity, so make sure you have a relatively recent version and not some
old 2003 draft. When there are zero-valued bytes between the final
payload-bearing bits of one "NAL unit" and the
"start_code_prefix_one_3bytes" of the next "byte stream NAL unit", all
but the last one of those zero-valued bytes are considered part of the
preceding "byte stream NAL unit" and the last one is considered part of
the next "byte stream NAL unit".
But please don't take my word for it. Read the spec closely.
Best Regards,
Gary Sullivan
+> -----Original Message-----
+> From: mp4-tech-bounces@lists.mpegif.org
+> [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Luqman
+> Sent: Friday, October 20, 2023 3:46 PM
+> To: mp4-tech@lists.mpegif.org
+> Subject: Re: [Mp4-tech] Dropping NAL units on bit errors:
+> Best approach?
+>
+> > Gary Sullivan wanted us to know:
+>
+> >Yes, it's a byte-alignment recovery trick. As John points
+> out, extra
+> >zero-valued bytes can be present between any pair of NAL
+> units, but at
+> >least one such byte is required for the most important NAL units to
+> >enable decoder alignment recovery. Alignment recovery is
+> important in
+> >some scenarios but not others, but the quantity of data necessary to
+> >enable it is so low (about 1-2 bytes per picture) that we decided to
+> >require it to be there all the time.
+>
+> Thanks Gary for clarifying this. But there is some confusion
+> where the
+> leading zero byte 0x00 before 3 byte start_code_prefix belongs to.
+>
+> Example:
+>
+> 0x00000001................0x00000001.................0x00 0x00000001
+>
+> The extra 0x00 preceeding third 0x00000001 belongs to the second NALU
+> whereas 0x00000001 belongs to the third NALU.
+> Similarly in case of second appearance of 0x00000001, these 4 bytes
+> belong to second NALU.
+>
+> Am I correct? Or is it only ture in case of SPS, PPS and
+> first NALU of
+> an access unit / frame / picture?
+>
+> Regards,
+>
+> Luqman
+>
+>
+>
From k_kotegar yahoo.co.in Sat Oct 21 13:25:33 2006
From: k_kotegar yahoo.co.in (karunakar A.K.)
Date: Sat Oct 21 13:10:05 2006
Subject: [Mp4-tech] JSVM 2.0
Message-ID: <20061021122533.50003.qmail@web8815.mail.in.yahoo.com>
Dear All
Please help me to get JSVM 2.0 (Joint Scalable Video Model), it will be used only for testing purpose.
Thanking you in anticipation.
with regards
karunakar
---------------------------------
Find out what India is talking about on - Yahoo! Answers India
Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061021/b1f82d67/attachment-0001.html
From zombiyaga yahoo.com Sat Oct 21 05:44:28 2006
From: zombiyaga yahoo.com (Alex)
Date: Sat Oct 21 13:10:15 2006
Subject: [Mp4-tech] why are there 4 bytes 0x00000001 instead of 3 bytes in
every NALU?
In-Reply-To: <20061020221326.GC9305@gmx.de>
Message-ID: <20061021124428.78899.qmail@web53905.mail.yahoo.com>
Hi,
> I have also verified this. There are 4 byte
> (0x00000001) in the start of every
> NALU even in case it is not the first NALU of an
> access unit.
>
> >
> >Could someone please explain us this "mystery"?
>
> Hope someone understanding this issue can elaborate
> on this.
start_prefix_code_3bytes is actually 3 bytes only.
1 byte 0x00 comes from the previous NAL unit, which is
trailing zero byte;
--- Luqman wrote:
> > Shankar Manuel Aghito wanted us to know:
>
> >Hi Luqman,
> >
> >I've look at the standard and I can see what you
> say, it seems that that
> >zero_byte before start_code_prefix_one_3bytes
> should be present only in
> >SPS, PPS and in the first NALU of each access unit.
> I don't know why (I
> >guess that it is because we are missing something
> in understanding the
> >standard), but I am quite sure that the reference
> software put 4 bytes
> >0x00000001 in the beginning of each NALU, also for
> multiple NALUs per
> >picture, i.e. when there are NALUs that are not the
> first in the access
> >unit. Try my matlab script, posted in "RE:
> [Mp4-tech] H264 Corrupted
> >Bitstreams" a couple of days ago.
>
> I have also verified this. There are 4 byte
> (0x00000001) in the start of every
> NALU even in case it is not the first NALU of an
> access unit.
>
> >
> >Could someone please explain us this "mystery"?
>
> Hope someone understanding this issue can elaborate
> on this.
>
> >
> >Also you could try with JM11. I've read of problems
> with JM10.2 related
> >to use of multiple slices/picture.
>
> I skipping NALUs and then decoding with both JM10.2
> and JM11.0 versions.
> But there were same errors in the end. The decoding
> looked fine and a
> small number of frames were dropped. I think it is
> acceptable, but what
> annoys me are the warnings/error messages at the end
> of decoding
> process.
>
> >
> >If you still have problems, send encoder/decoder
> output and also
> >configuration files
> >
> I will attach configuration files and encoder and
> decoder output for
> your opinion.
>
>
> >---
> >
> >About the error concealment parameter in the
> decoder configuration file.
> >2 (motion copy) often is the best in my experience.
> But you will only
> >see differences when you remove a whole picture,
> i.e. all the NALUs of
> >one picture. If you loose only some parts of a
> picture, different
> >concealment algorithms are used, but you cannot
> control that in the
> >config file.
>
> I think all NALUs in a picture/frame are sent in
> sequence and there is
> no interleaving of NALUs of different pictures. Is
> it true? Can someome
> shed some light on that? Is there interleaving in
> referece software JM
> implemented?
>
> Anyhow, I did not see any difference when 2 (motion
> copy) was activated
> in decoder configuration file. I will try to verify
> this tomorrow and
> then post my results here.
>
> >
> >---
> >
> >You don't need to have Log2MaxFNumMinus4 soo high!
> With
> >Log2MaxFNumMinus4=12 then you can encode 2^(12+4)
> pictures before the
> >counter restarts!!!
> >
> Ok, thanks for elaborating on this.
>
> There are 4 attached files to my posting:
>
> encoder.cfg
> decoder.cfg
> encod_result: is the output from encoder
> drop_and_decod_result: contains output from my NALU
> skipping program
> (called skip_nalu) and ldecod.dbg.exe
>
> The last file is very lengthy. If you don't like to
> go through it I will
> print the ERROR and warnings from decoder produced
> during _different_ sessons in the
> following:
>
>
> 1) ERROR: failed to find NumCoeff/TrailingOnes
> 2) ldecod.dbg.exe: src/vlc.c:479: more_rbsp_data:
> Assertion
> `byteoffset Aborted
> 3) ERROR: failed to find NumCoeff/TrailingOnes
> 4) RegardsROR: failed to find Run
> 5) ERROR: failed to find Total Zeros
>
> Again, these messages were printed during
> _different_ sessions of
> decoder with different number and places of dropped
> NALUs.
>
> Any idea if it is an expected behaviour from JM
> software or not??? I
> mean apart from these messages decoder seems to work
> as _I_ expected.
>
> Regards,
>
> Luqman
> > # New Input File Format is as follows
> # = # Comment
> #
> # See configfile.h for a list of supported
> ParameterNames
>
>
>
##########################################################################################
> # Files
>
##########################################################################################
> InputFile = "foreman.qcif" # Link to
> Input sequence
> InputHeaderLength = 0 # If the inputfile
> has a header, state it's length in byte here
> StartFrame = 0 # Start frame for
> encoding. (0-N)
> ###### LM: FramesToBeEncode: 2 #original
> ##################
> FramesToBeEncoded = 100 # Number of frames to
> be coded
> FrameRate = 30.0 # Frame Rate per
> second (0.1-100.0)
> SourceWidth = 176 # Frame width
> SourceHeight = 144 # Frame height
> TraceFile = "trace_enc.txt"
> ReconFile = "test_rec.yuv"
> #OutputFile = "test.264"
> OutputFile = "test.264_nskipped"
>
>
##########################################################################################
> # Encoder Control
>
##########################################################################################
> ProfileIDC = 88 # Profile IDC
> (66=baseline, 77=main, 88=extended; FREXT Profiles:
> 100=High, 110=High 10, 122=High 4:2:2, 144=High
> 4:4:4, for params see below)
> LevelIDC = 10 # Level IDC (e.g. 20 =
> level 2.0)
>
> IntraPeriod = 0 # Period of I-Frames
> (0=only first)
> EnableOpenGOP = 0 # Support for open GOPs
> (0: disabled, 1: enabled)
> IDRIntraEnable = 1 # Force IDR Intra
> (0=disable 1=enable)
> QPISlice = 28 # Quant. param for I
> Slices (0-51)
> QPPSlice = 28 # Quant. param for P
> Slices (0-51)
> FrameSkip = 0 # Number of frames to be
> skipped in input (e.g 2 will code every third frame)
> ChromaQPOffset = 0 # Chroma QP offset
> (-51..51)
> UseHadamard = 1 # Hadamard transform
> (0=not used, 1=used for all subpel positions, 2=use
> only for qpel)
> DisableSubpelME = 0 # Disable Subpixel
> Motion Estimation (0=off/default, 1=on)
> SearchRange = 16 # Max search range
> NumberReferenceFrames = 1 # Number of previous
> frames used for inter motion search (1-16)
> PList0References = 0 # P slice List 0
> reference override (0 disable, N <=
> NumberReferenceFrames)
> Log2MaxFNumMinus4 = 12 # Sets
> log2_max_frame_num_minus4 (-1 : based on
> FramesToBeEncoded/Auto, >=0 : Log2MaxFNumMinus4)
> Log2MaxPOCLsbMinus4 = -1 # Sets
> log2_max_pic_order_cnt_lsb_minus4 (-1 : Auto, >=0 :
> Log2MaxPOCLsbMinus4)
>
> GenerateMultiplePPS = 0 # Transmit multiple
> parameter sets. Currently parameters basically
> enable all WP modes (0: diabled, 1: enabled)
> ResendPPS = 0 # Resend PPS (with
> pic_parameter_set_id 0) for every coded Frame/Field
> pair (0: disabled, 1: enabled)
>
> MbLineIntraUpdate = 0 # Error robustness(extra
> intra macro block updates)(0=off, N: One GOB every N
> frames are intra coded)
> RandomIntraMBRefresh = 10 # Forced intra MBs per
> picture
> InterSearch16x16 = 1 # Inter block search
> 16x16 (0=disable, 1=enable)
> InterSearch16x8 = 1 # Inter block search
> 16x8 (0=disable, 1=enable)
> InterSearch8x16 = 1 # Inter block search
> 8x16 (0=disable, 1=enable)
> InterSearch8x8 = 1 # Inter block search
> 8x8 (0=disable, 1=enable)
> InterSearch8x4 = 1 # Inter block search
> 8x4 (0=disable, 1=enable)
> InterSearch4x8 = 1 # Inter block search
> 4x8 (0=disable, 1=enable)
> InterSearch4x4 = 1 # Inter block search
> 4x4 (0=disable, 1=enable)
>
> IntraDisableInterOnly = 0 # Apply Disabling Intra
> conditions only to Inter Slices
> (0:disable/default,1: enable)
> Intra4x4ParDisable = 0 # Disable Vertical &
> Horizontal 4x4
> Intra4x4DiagDisable = 0 # Disable Diagonal
> 45degree 4x4
> Intra4x4DirDisable = 0 # Disable Other Diagonal
> 4x4
> Intra16x16ParDisable = 0 # Disable Vertical &
> Horizontal 16x16
> Intra16x16PlaneDisable = 0 # Disable Planar 16x16
> ChromaIntraDisable = 0 # Disable Intra Chroma
> modes other than DC
> EnableIPCM = 1 # Enable IPCM macroblock
> mode
>
> DisposableP = 0 # Enable Disposable P
> slices in the primary layer (0: disable/default, 1:
> enable)
> DispPQPOffset = 0 # Quantizer offset for
> disposable P slices (0: default)
>
>
##########################################################################################
> # B Slices
>
##########################################################################################
>
> NumberBFrames = 0 # Number of B coded
> frames inserted (0=not used)
> #NumberBFrames = 1 # Number of B coded
> frames inserted (0=not used)
> QPBSlice = 30 # Quant. param for B
> slices (0-51)
> BRefPicQPOffset = 0 # Quantization offset
> for reference B coded pictures (-51..51)
> DirectModeType = 1 # Direct Mode Type
> (0:Temporal 1:Spatial)
> DirectInferenceFlag = 1 # Direct Inference Flag
> (0: Disable 1: Enable)
> BList0References = 0 # B slice List 0
> reference override (0 disable, N <=
> NumberReferenceFrames)
> BList1References = 1 # B slice List 1
> reference override (0 disable, N <=
> NumberReferenceFrames)
> # 1 List1 reference is
> usually recommended for normal GOP Structures.
> # A larger value is
> usually more appropriate if a more flexible
> # structure is used
> (i.e. using PyramidCoding)
>
> BReferencePictures = 0 # Referenced B coded
> pictures (0=off, 1=on)
>
> PyramidCoding = 0 # B pyramid (0= off, 1=
> 2 layers, 2= 2 full pyramid, 3 = explicit)
> PyramidLevelQPEnable = 1 # Adjust QP based on
> Pyramid Level (in increments of 1). Overrides
> BRefPicQPOffset behavior.(0=off, 1=on)
> ExplicitPyramidFormat = "b2r28b0e30b1e30b3e30b4e30"
> # Explicit Enhancement GOP. Format is
> {FrameDisplay_orderReferenceQP}.
>
> # Valid values for reference type is r:reference,
> e:non reference.
> PyramidRefReorder = 1 # Reorder References
> according to Poc distance for PyramidCoding (0=off,
> 1=enable)
> PocMemoryManagement = 1 # Memory management
> based on Poc Distances for PyramidCoding (0=off,
> 1=on)
>
> BiPredMotionEstimation = 0 # Enable Bipredictive
> based Motion Estimation (0:disabled, 1:enabled)
> BiPredMERefinements = 3 # Bipredictive ME extra
> refinements (0: single, N: N extra refinements (1
> default)
> BiPredMESearchRange = 16 # Bipredictive ME
> Search range (8 default). Note that range is halved
> for every extra refinement.
> BiPredMESubPel = 1 # Bipredictive ME
> Subpixel Consideration (0: disabled, 1: single
> level, 2: dual level)
>
>
>
##########################################################################################
> # SP Frames
>
##########################################################################################
>
> SPPicturePeriodicity = 0 # SP-Picture Periodicity
> (0=not used)
> QPSPSlice = 36 # Quant. param of
> SP-Slices for Prediction Error (0-51)
> QPSP2Slice = 35 # Quant. param of
> SP-Slices for Predicted Blocks (0-51)
> SI_FRAMES = 0 # SI frame encoding flag
> (0=not used, 1=used)
> SP_output = 0 # Controls whether
> coefficients will be output to encode switching SP
> frames (0=no, 1=yes)
> SP_output_name = "low_quality.dat" #
> Filename for SP output coefficients
>
=== message truncated ===> test.264
........H.26L coded
> bitstream
> test_dec.yuv ........Output file,
> YUV/RGB
> test_rec.yuv ........Ref sequence (for
> SNR)
> 1 ........Write 4:2:0 chroma
> components for monochrome streams
> 0 ........NAL mode (0=Annex
> B, 1: RTP packets)
> 0 ........SNR computation
> offset
> 2 ........Poc Scale (1 or 2)
> 500000 ........Rate_Decoder
> 104000 ........B_decoder
> 73000 ........F_decoder
> leakybucketparam.cfg ........LeakyBucket Params
> 0 ........Err
> Concealment(0:Off,1:Frame Copy,2:Motion Copy)
> 2 ........Reference POC gap
> (2: IPP (Default), 4: IbP / IpP)
> 2 ........POC gap (2: IPP
> /IbP/IpP (Default), 4: IPP with frame skip = 1 etc.)
>
>
> This is a file containing input parameters to the
> JVT H.264/AVC decoder.
> The text line following each parameter is discarded
> by the decoder.
> > Setting Default Parameters...
> Parsing Configfile
>
encoder.cfg......................................................................................................................................................................................
>
> ------------------------------- JM 10.2 (FRExt)
> --------------------------------
> Input YUV file : video_source
> Output H.264 bitstream :
> test.264_nskipped
> Output YUV file : test_rec.yuv
> YUV Format : YUV 4:2:0
> Frames to be encoded I-P/B : 100/0
> PicInterlace / MbInterlace : 0/0
> Transform8x8Mode : 0
>
-------------------------------------------------------------------------------
> Frame Bit/pic QP SnrY SnrU SnrV
> Time(ms) MET(ms) Frm/Fld Ref
>
-------------------------------------------------------------------------------
> 0000(NVB) 168
> 0000(IDR) 27688 28 36.878 39.761 42.034
> 243 0 FRM 1
> 0001(P) 6272 28 36.214 39.463 41.563
> 829 469 FRM 1
> 0002(P) 7456 28 36.164 39.215 41.344
> 831 459 FRM 1
> 0003(P) 6624 28 35.872 39.059 41.004
> 804 462 FRM 1
> 0004(P) 6008 28 35.689 38.980 40.917
> 803 443 FRM 1
> 0005(P) 6816 28 35.657 38.916 40.795
> 803 460 FRM 1
> 0006(P) 6928 28 35.474 39.152 40.755
> 805 455 FRM 1
> 0007(P) 7416 28 35.562 39.175 40.805
> 801 457 FRM 1
> 0008(P) 6264 28 35.481 39.052 40.573
> 797 445 FRM 1
> 0009(P) 5896 28 35.512 38.998 40.790
> 800 460 FRM 1
> 0010(P) 6448 28 35.573 38.931 40.543
> 845 487 FRM 1
> 0011(P) 6832 28 35.568 38.905 40.422
> 801 430 FRM 1
> 0012(P) 7032 28 35.482 38.900 40.525
> 815 463 FRM 1
> 0013(P) 5704 28 35.300 38.908 40.671
> 878 496 FRM 1
> 0014(P) 4968 28 35.301 38.742 40.583
> 837 479 FRM 1
> 0015(P) 5736 28 35.218 38.654 40.486
> 805 460 FRM 1
> 0016(P) 6720 28 35.322 38.811 40.202
> 805 442 FRM 1
> 0017(P) 6776 28 35.400 38.761 40.295
> 797 451 FRM 1
> 0018(P) 6520 28 35.451 38.732 40.177
> 800 450 FRM 1
> 0019(P) 6944 28 35.420 38.570 40.099
> 801 458 FRM 1
> 0020(P) 7408 28 35.495 38.343 40.230
> 809 451 FRM 1
> 0021(P) 8080 28 35.432 38.334 40.005
> 804 449 FRM 1
> 0022(P) 7960 28 35.335 38.336 39.792
> 800 452 FRM 1
> 0023(P) 6344 28 35.393 38.423 39.989
> 804 458 FRM 1
> 0024(P) 6328 28 35.256 38.392 39.847
> 807 454 FRM 1
> 0025(P) 5664 28 35.197 38.337 39.762
> 819 450 FRM 1
> 0026(P) 6768 28 35.349 38.385 39.754
> 802 438 FRM 1
> 0027(P) 6584 28 35.375 38.377 39.789
> 799 452 FRM 1
> 0028(P) 7264 28 35.503 38.542 39.802
> 805 454 FRM 1
> 0029(P) 6752 28 35.443 38.528 39.809
> 874 510 FRM 1
> 0030(P) 6744 28 35.320 38.412 39.989
> 809 459 FRM 1
> 0031(P) 7304 28 35.295 38.368 40.031
> 807 461 FRM 1
> 0032(P) 7864 28 35.338 38.600 40.147
> 834 470 FRM 1
> 0033(P) 6944 28 35.302 38.458 40.145
> 849 467 FRM 1
> 0034(P) 6336 28 35.278 38.401 40.048
> 820 449 FRM 1
> 0035(P) 7160 28 35.311 38.562 40.193
> 813 460 FRM 1
> 0036(P) 8464 28 35.268 38.686 40.381
> 810 444 FRM 1
> 0037(P) 7040 28 35.293 38.507 40.094
> 846 474 FRM 1
> 0038(P) 6840 28 35.172 38.576 40.341
> 822 453 FRM 1
> 0039(P) 6032 28 35.171 38.486 40.517
> 837 452 FRM 1
> 0040(P) 6424 28 35.235 38.429 40.300
> 840 473 FRM 1
> 0041(P) 7848 28 35.367 38.588 40.413
> 822 461 FRM 1
> 0042(P) 7400 28 35.381 38.524 40.561
> 830 469 FRM 1
> 0043(P) 6664 28 35.260 38.677 40.692
> 825 463 FRM 1
> 0044(P) 5944 28 35.314 38.588 40.344
> 838 461 FRM 1
> 0045(P) 6232 28 35.342 38.718 40.523
> 827 473 FRM 1
> 0046(P) 6848 28 35.433 38.730 40.246
> 826 475 FRM 1
> 0047(P) 6288 28 35.492 38.762 40.266
> 862 478 FRM 1
> 0048(P) 6504 28 35.483 38.660 40.181
> 818 449 FRM 1
> 0049(P) 7032 28 35.490 38.703 40.325
> 823 468 FRM 1
> 0050(P) 6672 28 35.548 38.745 40.322
> 836 468 FRM 1
> 0051(P) 7424 28 35.517 38.725 40.407
> 838 470 FRM 1
> 0052(P) 7312 28 35.582 38.577 40.452
> 843 470 FRM 1
> 0053(P) 6552 28 35.613 38.850 40.417
> 824 472 FRM 1
> 0054(P) 4792 28 35.426 38.821 40.606
> 809 451 FRM 1
> 0055(P) 5160 28 35.485 38.927 40.391
> 807 456 FRM 1
> 0056(P) 5496 28 35.382 38.791 40.393
> 817 467 FRM 1
> 0057(P) 5016 28 35.415 38.802 40.328
> 819 456 FRM 1
> 0058(P) 4992 28 35.451 38.847 40.395
> 818 453 FRM 1
> 0059(P) 3704 28 35.379 38.781 40.418
> 854 477 FRM 1
> 0060(P) 4840 28 35.397 38.736 40.377
> 816 466 FRM 1
> 0061(P) 5952 28 35.389 38.768 40.318
> 818 475 FRM 1
> 0062(P) 7936 28 35.312 38.732 40.410
> 843 473 FRM 1
> 0063(P) 9888 28 35.272 38.544 40.405
> 821 454 FRM 1
> 0064(P) 8696 28 35.255 38.609 40.341
> 814 457 FRM 1
> 0065(P) 8080 28 35.308 38.451 40.515
> 812 449 FRM 1
> 0066(P) 8280 28 35.180 38.470 40.197
> 808 438 FRM 1
> 0067(P) 9072 28 35.311 38.436 40.287
> 813 441 FRM 1
> 0068(P) 9040 28 35.287 38.386 40.293
> 814 448 FRM 1
> 0069(P) 8856 28 35.381 38.518 40.458
> 815 462 FRM 1
> 0070(P) 9192 28 35.319 38.464 40.608
> 812 456 FRM 1
> 0071(P) 9200 28 35.353 38.554 40.694
> 810 459 FRM 1
> 0072(P) 9344 28 35.440 38.664 40.873
> 822 448 FRM 1
> 0073(P) 7432 28 35.386 38.804 40.950
> 822 458 FRM 1
> 0074(P) 7624 28 35.415 38.930 40.898
> 808 450 FRM 1
> 0075(P) 8472 28 35.314 39.189 41.191
> 811 456 FRM 1
> 0076(P) 8560 28 35.362 39.126 41.510
> 811 446 FRM 1
> 0077(P) 7792 28 35.459 38.956 41.368
> 853 477 FRM 1
> 0078(P) 7120 28 35.425 39.113 41.530
> 873 477 FRM 1
> 0079(P) 6776 28 35.427 39.161 41.502
> 839 464 FRM 1
> 0080(P) 7520 28 35.363 39.295 41.409
> 838 475 FRM 1
> 0081(P) 7024 28 35.358 39.136 41.263
> 844 486 FRM 1
> 0082(P) 6832 28 35.431 39.202 41.389
> 830 454 FRM 1
> 0083(P) 6680 28 35.443 39.070 41.335
> 866 500 FRM 1
> 0084(P) 6224 28 35.433 39.023 41.133
> 830 469 FRM 1
> 0085(P) 6376 28 35.512 39.026 41.113
> 814 476 FRM 1
> 0086(P) 7784 28 35.620 39.187 41.265
> 816 465 FRM 1
> 0087(P) 6440 28 35.671 39.248 41.358
> 852 474 FRM 1
> 0088(P) 6536 28 35.565 39.489 41.595
> 841 469 FRM 1
> 0089(P) 6808 28 35.606 39.426 41.621
> 828 462 FRM 1
> 0090(P) 6752 28 35.598 39.389 41.593
> 812 472 FRM 1
>
=== message truncated ===>
> skip_nalu ----------means output from dropping
> utility-------------------------
>
> NALU 5: skipping NALU...
> NALU 14: skipping NALU...
> NALU 23: skipping NALU...
> NALU 32: skipping NALU...
> NALU 41: skipping NALU...
> NALU 50: skipping NALU...
> NALU 65: skipping NALU...
> NALU 73: skipping NALU...
> NALU 81: skipping NALU...
> NALU 88: skipping NALU...
> NALU 92: skipping NALU...
> NALU 95: skipping NALU...
> NALU 100: skipping NALU...
> NALU 108: skipping NALU...
> NALU 116: skipping NALU...
>
>
>
=============================================================
> skipped / total NALUs: 15 / 900 (excl. 1 SPS + 1
> PPS)
>
>
> ldecod.dbg.exe -----means following is the output
> from decoder-------------
>
> ----------------------------- JM 10.2 (FRExt)
> -----------------------------
> Decoder config file : (null)
>
--------------------------------------------------------------------------
> Input H.264 bitstream : test.264
> Output decoded YUV :
> test_dec.yuv
> Output status file : log.dec
> Input reference file :
> test_rec.yuv
>
--------------------------------------------------------------------------
> POC must = frame# or field# for SNRs to be correct
>
--------------------------------------------------------------------------
> Frame POC Pic# QP SnrY SnrU SnrV
> Y:U:V Time(ms)
>
--------------------------------------------------------------------------
> 0000(I) 0 0 28 0.0000 0.0000
> 0.0000 4:2:0 75
> 0001(P) 2 1 28 0.0000 0.0000
> 0.0000 4:2:0 67
> 0002(P) 4 2 28 0.0000 0.0000
> 0.0000 4:2:0 67
> 0003(P) 6 3 28 0.0000 0.0000
> 0.0000 4:2:0 69
> 0004(P) 8 4 28 0.0000 0.0000
> 0.0000 4:2:0 74
> 0005(P) 10 5 28 0.0000 0.0000
> 0.0000 4:2:0 71
> 0006(P) 12 6 28 0.0000 0.0000
> 0.0000 4:2:0 72
> 0007(P) 14 7 28 0.0000 0.0000
> 0.0000 4:2:0 75
> 0008(P) 16 8 28 0.0000 0.0000
> 0.0000 4:2:0 72
> 0009(P) 18 9 28 0.0000 0.0000
> 0.0000 4:2:0 75
> 0010(P) 20 10 28 0.0000 0.0000
> 0.0000 4:2:0 71
> 0011(P) 22 11 28 0.0000 0.0000
> 0.0000 4:2:0 73
> 0012(P) 24 12 28 0.0000 0.0000
> 0.0000 4:2:0 71
> 0013(P) 26 13 28 0.0000 0.0000
> 0.0000 4:2:0 73
> 0014(P) 28 14 28 0.0000 0.0000
> 0.0000 4:2:0 65
> 0015(P) 30 15 28 0.0000 0.0000
> 0.0000 4:2:0 74
> 0016(P) 32 16 28 0.0000 0.0000
> 0.0000 4:2:0 77
> 0017(P) 34 17 28 0.0000 0.0000
> 0.0000 4:2:0 72
> 0018(P) 36 18 28 0.0000 0.0000
> 0.0000 4:2:0 66
> 0019(P) 38 19 28 0.0000 0.0000
> 0.0000 4:2:0 74
> 0020(P) 40 20 28 0.0000 0.0000
> 0.0000 4:2:0 76
> 0021(P) 42 21 28 0.0000 0.0000
> 0.0000 4:2:0 77
> 0022(P) 44 22 28 0.0000 0.0000
> 0.0000 4:2:0 76
> 0023(P) 46 23 28 0.0000 0.0000
> 0.0000 4:2:0 71
> 0024(P) 48 24 28 0.0000 0.0000
> 0.0000 4:2:0 92
> 0025(P) 50 25 28 0.0000 0.0000
> 0.0000 4:2:0 79
> 0026(P) 52 26 28 0.0000 0.0000
> 0.0000 4:2:0 69
> 0027(P) 54 27 28 0.0000 0.0000
> 0.0000 4:2:0 68
> 0028(P) 56 28 28 0.0000 0.0000
> 0.0000 4:2:0 75
> 0029(P) 58 29 28 0.0000 0.0000
> 0.0000 4:2:0 73
> 0030(P) 60 30 28 0.0000 0.0000
> 0.0000 4:2:0 76
> 0031(P) 62 31 28 0.0000 0.0000
> 0.0000 4:2:0 75
> 0032(P) 64 32 28 0.0000 0.0000
> 0.0000 4:2:0 75
> 0033(P) 66 33 28 0.0000 0.0000
> 0.0000 4:2:0 79
> 0034(P) 68 34 28 0.0000 0.0000
> 0.0000 4:2:0 71
> 0035(P) 70 35 28 0.0000 0.0000
> 0.0000 4:2:0 77
> 0036(P) 72 36 28 0.0000 0.0000
> 0.0000 4:2:0 80
> 0037(P) 74 37 28 0.0000 0.0000
> 0.0000 4:2:0 74
> 0038(P) 76 38 28 0.0000 0.0000
> 0.0000 4:2:0 70
> 0039(P) 78 39 28 0.0000 0.0000
> 0.0000 4:2:0 71
> 0040(P) 80 40 28 0.0000 0.0000
> 0.0000 4:2:0 68
> 0041(P) 82 41 28 0.0000 0.0000
> 0.0000 4:2:0 72
> 0042(P) 84 42 28 0.0000 0.0000
> 0.0000 4:2:0 75
> 0043(P) 86 43 28 0.0000 0.0000
> 0.0000 4:2:0 74
> 0044(P) 88 44 28 0.0000 0.0000
> 0.0000 4:2:0 70
> 0045(P) 90 45 28 0.0000 0.0000
> 0.0000 4:2:0 72
> 0046(P) 92 46 28 0.0000 0.0000
> 0.0000 4:2:0 73
> 0047(P) 94 47 28 0.0000 0.0000
> 0.0000 4:2:0 68
> 0048(P) 96 48 28 0.0000 0.0000
> 0.0000 4:2:0 99
> 0049(P) 98 49 28 0.0000 0.0000
> 0.0000 4:2:0 74
> 0050(P) 100 50 28 0.0000 0.0000
> 0.0000 4:2:0 80
> 0051(P) 102 51 28 0.0000 0.0000
> 0.0000 4:2:0 76
> 0052(P) 104 52 28 0.0000 0.0000
> 0.0000 4:2:0 76
> 0053(P) 106 53 28 0.0000 0.0000
> 0.0000 4:2:0 75
> 0054(P) 108 54 28 0.0000 0.0000
> 0.0000 4:2:0 67
> 0055(P) 110 55 28 0.0000 0.0000
> 0.0000 4:2:0 65
> 0056(P) 112 56 28 0.0000 0.0000
> 0.0000 4:2:0 60
> 0057(P) 114 57 28 0.0000 0.0000
> 0.0000 4:2:0 59
> 0058(P) 116 58 28 0.0000 0.0000
> 0.0000 4:2:0 61
> 0059(P) 118 59 28 0.0000 0.0000
> 0.0000 4:2:0 57
> 0060(P) 120 60 28 0.0000 0.0000
> 0.0000 4:2:0 62
> 0061(P) 122 61 28 0.0000 0.0000
> 0.0000 4:2:0 64
> 0062(P) 124 62 28 0.0000 0.0000
> 0.0000 4:2:0 72
> 0063(P) 126 63 28 0.0000 0.0000
> 0.0000 4:2:0 75
> 0064(P) 128 64 28 0.0000 0.0000
> 0.0000 4:2:0 79
> 0065(P) 130 65 28 0.0000 0.0000
> 0.0000 4:2:0 79
> 0066(P) 132 66 28 0.0000 0.0000
> 0.0000 4:2:0 75
> 0067(P) 134 67 28 0.0000 0.0000
> 0.0000 4:2:0 78
> 0068(P) 136 68 28 0.0000 0.0000
> 0.0000 4:2:0 80
> 0069(P) 138 69 28 0.0000 0.0000
> 0.0000 4:2:0 78
> 0070(P) 140 70 28 0.0000 0.0000
> 0.0000 4:2:0 78
> 0071(P) 142 71 28 0.0000 0.0000
> 0.0000 4:2:0 78
> 0072(P) 144 72 28 0.0000 0.0000
> 0.0000 4:2:0 81
> 0073(P) 146 73 28 0.0000 0.0000
> 0.0000 4:2:0 77
> 0074(P) 148 74 28 0.0000 0.0000
> 0.0000 4:2:0 78
> 0075(P) 150 75 28 0.0000 0.0000
> 0.0000 4:2:0 75
> 0076(P) 152 76 28 0.0000 0.0000
> 0.0000 4:2:0 77
> 0077(P) 154 77 28 0.0000 0.0000
> 0.0000 4:2:0 77
>
=== message truncated ===>
_______________________________________________
> 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
--
Regards,
Alex
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
From garysull windows.microsoft.com Sat Oct 21 14:39:32 2006
From: garysull windows.microsoft.com (Gary Sullivan)
Date: Sat Oct 21 21:46:07 2006
Subject: [Mp4-tech] Dropping NAL units on bit errors: Best approach?
In-Reply-To: <03CB47D9C3F8074498E4653F814D6E8F029587C6@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
Message-ID: <03CB47D9C3F8074498E4653F814D6E8F0295881B@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
Oops. Luqman, actually you had it right. I thought you were saying
0x00001...........0x000001.............0x00 0x000001
when actually you were saying
0x00000001...........0x00000001.............0x00 0x00000001
All of your strings were at least FOUR bytes long, whereas the start
code prefix in the standard (start_code_prefix_one_3bytes) is only THREE
bytes long.
In the standard, most NAL units only need a three-byte prefix, although
a few (the first NAL unit of an access unit and each SPS and PPS NAL
unit) need a four-byte prefix.
In your actual example, you are correct. The 0x00 near the end is
assigned to the SECOND NAL unit.
In my preceding example at the beginning of this message, the 0x00 would
be assigned to the THIRD NAL unit.
The rule is that if the prefixing string is three bytes long (0x000001)
or four bytes long (0x00000001) then these three or four bytes will be
assigned to the NEXT byte stream NAL unit. If the prefixing string is
more than four bytes long, the last four bytes are assigned to the next
byte stream NAL unit and the remainder are assigned to the previous byte
stream NAL unti.
Best Regards,
Gary Sullivan
+> -----Original Message-----
+> From: mp4-tech-bounces@lists.mpegif.org
+> [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Gary Sullivan
+> Sent: Saturday, October 21, 2023 4:35 AM
+> To: Luqman; mp4-tech@lists.mpegif.org
+> Subject: RE: [Mp4-tech] Dropping NAL units on bit errors:
+> Best approach?
+>
+>
+> I don't think you have it right.
+>
+> The boundary between "byte stream NAL units" and "access units" is
+> detailed in the standard (mostly Annex B, which is only two
+> pages long).
+> We made a small modification of the boundary location in a
+> corrigendum
+> activity, so make sure you have a relatively recent version
+> and not some
+> old 2003 draft. When there are zero-valued bytes between the final
+> payload-bearing bits of one "NAL unit" and the
+> "start_code_prefix_one_3bytes" of the next "byte stream NAL
+> unit", all
+> but the last one of those zero-valued bytes are considered
+> part of the
+> preceding "byte stream NAL unit" and the last one is
+> considered part of
+> the next "byte stream NAL unit".
+>
+> But please don't take my word for it. Read the spec closely.
+>
+> Best Regards,
+>
+> Gary Sullivan
+>
+> +> -----Original Message-----
+> +> From: mp4-tech-bounces@lists.mpegif.org
+> +> [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Luqman
+> +> Sent: Friday, October 20, 2023 3:46 PM
+> +> To: mp4-tech@lists.mpegif.org
+> +> Subject: Re: [Mp4-tech] Dropping NAL units on bit errors:
+> +> Best approach?
+> +>
+> +> > Gary Sullivan wanted us to know:
+> +>
+> +> >Yes, it's a byte-alignment recovery trick. As John points
+> +> out, extra
+> +> >zero-valued bytes can be present between any pair of NAL
+> +> units, but at
+> +> >least one such byte is required for the most important
+> NAL units to
+> +> >enable decoder alignment recovery. Alignment recovery is
+> +> important in
+> +> >some scenarios but not others, but the quantity of data
+> necessary to
+> +> >enable it is so low (about 1-2 bytes per picture) that
+> we decided to
+> +> >require it to be there all the time.
+> +>
+> +> Thanks Gary for clarifying this. But there is some confusion
+> +> where the
+> +> leading zero byte 0x00 before 3 byte start_code_prefix belongs to.
+> +>
+> +> Example:
+> +>
+> +> 0x00000001................0x00000001.................0x00
+> 0x00000001
+> +>
+> +> The extra 0x00 preceeding third 0x00000001 belongs to the
+> second NALU
+> +> whereas 0x00000001 belongs to the third NALU.
+> +> Similarly in case of second appearance of 0x00000001,
+> these 4 bytes
+> +> belong to second NALU.
+> +>
+> +> Am I correct? Or is it only ture in case of SPS, PPS and
+> +> first NALU of
+> +> an access unit / frame / picture?
+> +>
+> +> Regards,
+> +>
+> +> Luqman
+> +>
+> +>
+> +>
+>
+> _______________________________________________
+> NOTE: Please use clear subject lines for your posts. Include
+> [audio, [video], [systems], [general] or another
+> apppropriate identifier to indicate the type of question you have.
+>
+> Note: Conduct on the mailing list is subject to the
+> Antitrust guidelines found at
+> http://www.mpegif.org/public/documents/vault/mp-out-30042-Ant
+> itrust.php
+>
From anil-list icinema.com Sat Oct 21 23:14:11 2006
From: anil-list icinema.com (Anil Gupte)
Date: Sat Oct 21 21:52:08 2006
Subject: [Mp4-tech] Learning more about MPEG
Message-ID: <024701c6f538$87fce770$6400a8c0@Aum>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 145 bytes
Desc: not available
Url : /pipermail/mp4-tech/attachments/20061021/4d987e59/attachment.gif
From garysull windows.microsoft.com Sat Oct 21 15:32:30 2006
From: garysull windows.microsoft.com (Gary Sullivan)
Date: Sat Oct 21 22:40:07 2006
Subject: [Mp4-tech] why are there 4 bytes 0x00000001 instead of 3 bytes
inevery NALU?
In-Reply-To: <20061021124428.78899.qmail@web53905.mail.yahoo.com>
Message-ID: <03CB47D9C3F8074498E4653F814D6E8F02958831@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
Alex (et al),
It's not quite that simple.
There are actually five distinct kinds of special zero-valued bytes that
can fall outside of the range between the nal_unit_type ID for a NAL
unit and the "RBSP trailing bits" that follow the basic data payload of
the NAL unit. Sometimes the inclusion of such zero-valued bytes is
optional and sometimes it is mandatory. Explaining the complete
rationale for all of them can get a bit complicated.
The first one that can appear in a bitstream is called
leading_zero_8bits. This is a special name for any extra zero-valued
bytes at the very beginning of the bitstream. These are conceptually
assigned to the first "byte stream NAL unit".
The second one is the zero_byte. Its presence is mandatory for the
first NAL unit of each acess unit and for SPS and PPS NAL units,
whenever using the Annex B byte stream format. It conceptually belongs
to the following NAL unit.
The third one is the first two bytes of the
start_code_prefix_one_3bytes. Their presence is mandatory for every NAL
unit when using the Annex B byte stream format. The belong to the
following NAL unit.
The fourth one is the cabac_zero_word, one or more of which can appear
after the RBSP trailing bits inside of a NAL unit when CABAC entropy
coding is being used. These fall within the start code emulation
prevention process and inside of the NAL unit itself (in section 6
rather than Annex B). They are probably relatively rare to find in
practice. They can be present even when the Annex B byte stream NAL
unit is not in use.
Finally, after the end of a NAL unit and before the end of its Annex B
associated "byte stream NAL unit", there can be one or more
trailing_zero_8bits. These are optional. They are conceptually
assigned to the preceding NAL unit.
Best Regards,
Gary Sullivan
+> -----Original Message-----
+> From: mp4-tech-bounces@lists.mpegif.org
+> [mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Alex
+> Sent: Saturday, October 21, 2023 5:44 AM
+> To: Luqman; mp4-tech@lists.mpegif.org
+> Subject: Re: [Mp4-tech] why are there 4 bytes 0x00000001
+> instead of 3 bytes inevery NALU?
+>
+> Hi,
+>
+> > I have also verified this. There are 4 byte
+> > (0x00000001) in the start of every
+> > NALU even in case it is not the first NALU of an
+> > access unit.
+> >
+> > >
+> > >Could someone please explain us this "mystery"?
+> >
+> > Hope someone understanding this issue can elaborate
+> > on this.
+>
+>
+> start_prefix_code_3bytes is actually 3 bytes only.
+>
+> 1 byte 0x00 comes from the previous NAL unit, which is
+> trailing zero byte;
+>
+>
+> --- Luqman wrote:
+>
+> > > Shankar Manuel Aghito wanted us to know:
+> >
+> > >Hi Luqman,
+> > >
+> > >I've look at the standard and I can see what you
+> > say, it seems that that
+> > >zero_byte before start_code_prefix_one_3bytes
+> > should be present only in
+> > >SPS, PPS and in the first NALU of each access unit.
+> > I don't know why (I
+> > >guess that it is because we are missing something
+> > in understanding the
+> > >standard), but I am quite sure that the reference
+> > software put 4 bytes
+> > >0x00000001 in the beginning of each NALU, also for
+> > multiple NALUs per
+> > >picture, i.e. when there are NALUs that are not the
+> > first in the access
+> > >unit. Try my matlab script, posted in "RE:
+> > [Mp4-tech] H264 Corrupted
+> > >Bitstreams" a couple of days ago.
+> >
+> > I have also verified this. There are 4 byte
+> > (0x00000001) in the start of every
+> > NALU even in case it is not the first NALU of an
+> > access unit.
+> >
+> > >
+> > >Could someone please explain us this "mystery"?
+> >
+> > Hope someone understanding this issue can elaborate
+> > on this.
+> >
+> > >
+> > >Also you could try with JM11. I've read of problems
+> > with JM10.2 related
+> > >to use of multiple slices/picture.
+> >
+> > I skipping NALUs and then decoding with both JM10.2
+> > and JM11.0 versions.
+> > But there were same errors in the end. The decoding
+> > looked fine and a
+> > small number of frames were dropped. I think it is
+> > acceptable, but what
+> > annoys me are the warnings/error messages at the end
+> > of decoding
+> > process.
+> >
+> > >
+> > >If you still have problems, send encoder/decoder
+> > output and also
+> > >configuration files
+> > >
+> > I will attach configuration files and encoder and
+> > decoder output for
+> > your opinion.
+> >
+> >
+> > >---
+> > >
+> > >About the error concealment parameter in the
+> > decoder configuration file.
+> > >2 (motion copy) often is the best in my experience.
+> > But you will only
+> > >see differences when you remove a whole picture,
+> > i.e. all the NALUs of
+> > >one picture. If you loose only some parts of a
+> > picture, different
+> > >concealment algorithms are used, but you cannot
+> > control that in the
+> > >config file.
+> >
+> > I think all NALUs in a picture/frame are sent in
+> > sequence and there is
+> > no interleaving of NALUs of different pictures. Is
+> > it true? Can someome
+> > shed some light on that? Is there interleaving in
+> > referece software JM
+> > implemented?
+> >
+> > Anyhow, I did not see any difference when 2 (motion
+> > copy) was activated
+> > in decoder configuration file. I will try to verify
+> > this tomorrow and
+> > then post my results here.
+> >
+> > >
+> > >---
+> > >
+> > >You don't need to have Log2MaxFNumMinus4 soo high!
+> > With
+> > >Log2MaxFNumMinus4=12 then you can encode 2^(12+4)
+> > pictures before the
+> > >counter restarts!!!
+> > >
+> > Ok, thanks for elaborating on this.
+> >
+> > There are 4 attached files to my posting:
+> >
+> > encoder.cfg
+> > decoder.cfg
+> > encod_result: is the output from encoder
+> > drop_and_decod_result: contains output from my NALU
+> > skipping program
+> > (called skip_nalu) and ldecod.dbg.exe
+> >
+> > The last file is very lengthy. If you don't like to
+> > go through it I will
+> > print the ERROR and warnings from decoder produced
+> > during _different_ sessons in the
+> > following:
+> >
+> >
+> > 1) ERROR: failed to find NumCoeff/TrailingOnes
+> > 2) ldecod.dbg.exe: src/vlc.c:479: more_rbsp_data:
+> > Assertion
+> > `byteoffset > Aborted
+> > 3) ERROR: failed to find NumCoeff/TrailingOnes
+> > 4) RegardsROR: failed to find Run
+> > 5) ERROR: failed to find Total Zeros
+> >
+> > Again, these messages were printed during
+> > _different_ sessions of
+> > decoder with different number and places of dropped
+> > NALUs.
+> >
+> > Any idea if it is an expected behaviour from JM
+> > software or not??? I
+> > mean apart from these messages decoder seems to work
+> > as _I_ expected.
+> >
+> > Regards,
+> >
+> > Luqman
+> > > # New Input File Format is as follows
+> > # = # Comment
+> > #
+> > # See configfile.h for a list of supported
+> > ParameterNames
+> >
+> >
+> >
+> #############################################################
+> #############################
+> > # Files
+> >
+> #############################################################
+> #############################
+> > InputFile = "foreman.qcif" # Link to
+> > Input sequence
+> > InputHeaderLength = 0 # If the inputfile
+> > has a header, state it's length in byte here
+> > StartFrame = 0 # Start frame for
+> > encoding. (0-N)
+> > ###### LM: FramesToBeEncode: 2 #original
+> > ##################
+> > FramesToBeEncoded = 100 # Number of frames to
+> > be coded
+> > FrameRate = 30.0 # Frame Rate per
+> > second (0.1-100.0)
+> > SourceWidth = 176 # Frame width
+> > SourceHeight = 144 # Frame height
+> > TraceFile = "trace_enc.txt"
+> > ReconFile = "test_rec.yuv"
+> > #OutputFile = "test.264"
+> > OutputFile = "test.264_nskipped"
+> >
+> >
+> #############################################################
+> #############################
+> > # Encoder Control
+> >
+> #############################################################
+> #############################
+> > ProfileIDC = 88 # Profile IDC
+> > (66=baseline, 77=main, 88=extended; FREXT Profiles:
+> > 100=High, 110=High 10, 122=High 4:2:2, 144=High
+> > 4:4:4, for params see below)
+> > LevelIDC = 10 # Level IDC (e.g. 20 =
+> > level 2.0)
+> >
+> > IntraPeriod = 0 # Period of I-Frames
+> > (0=only first)
+> > EnableOpenGOP = 0 # Support for open GOPs
+> > (0: disabled, 1: enabled)
+> > IDRIntraEnable = 1 # Force IDR Intra
+> > (0=disable 1=enable)
+> > QPISlice = 28 # Quant. param for I
+> > Slices (0-51)
+> > QPPSlice = 28 # Quant. param for P
+> > Slices (0-51)
+> > FrameSkip = 0 # Number of frames to be
+> > skipped in input (e.g 2 will code every third frame)
+> > ChromaQPOffset = 0 # Chroma QP offset
+> > (-51..51)
+> > UseHadamard = 1 # Hadamard transform
+> > (0=not used, 1=used for all subpel positions, 2=use
+> > only for qpel)
+> > DisableSubpelME = 0 # Disable Subpixel
+> > Motion Estimation (0=off/default, 1=on)
+> > SearchRange = 16 # Max search range
+> > NumberReferenceFrames = 1 # Number of previous
+> > frames used for inter motion search (1-16)
+> > PList0References = 0 # P slice List 0
+> > reference override (0 disable, N <=
+> > NumberReferenceFrames)
+> > Log2MaxFNumMinus4 = 12 # Sets
+> > log2_max_frame_num_minus4 (-1 : based on
+> > FramesToBeEncoded/Auto, >=0 : Log2MaxFNumMinus4)
+> > Log2MaxPOCLsbMinus4 = -1 # Sets
+> > log2_max_pic_order_cnt_lsb_minus4 (-1 : Auto, >=0 :
+> > Log2MaxPOCLsbMinus4)
+> >
+> > GenerateMultiplePPS = 0 # Transmit multiple
+> > parameter sets. Currently parameters basically
+> > enable all WP modes (0: diabled, 1: enabled)
+> > ResendPPS = 0 # Resend PPS (with
+> > pic_parameter_set_id 0) for every coded Frame/Field
+> > pair (0: disabled, 1: enabled)
+> >
+> > MbLineIntraUpdate = 0 # Error robustness(extra
+> > intra macro block updates)(0=off, N: One GOB every N
+> > frames are intra coded)
+> > RandomIntraMBRefresh = 10 # Forced intra MBs per
+> > picture
+> > InterSearch16x16 = 1 # Inter block search
+> > 16x16 (0=disable, 1=enable)
+> > InterSearch16x8 = 1 # Inter block search
+> > 16x8 (0=disable, 1=enable)
+> > InterSearch8x16 = 1 # Inter block search
+> > 8x16 (0=disable, 1=enable)
+> > InterSearch8x8 = 1 # Inter block search
+> > 8x8 (0=disable, 1=enable)
+> > InterSearch8x4 = 1 # Inter block search
+> > 8x4 (0=disable, 1=enable)
+> > InterSearch4x8 = 1 # Inter block search
+> > 4x8 (0=disable, 1=enable)
+> > InterSearch4x4 = 1 # Inter block search
+> > 4x4 (0=disable, 1=enable)
+> >
+> > IntraDisableInterOnly = 0 # Apply Disabling Intra
+> > conditions only to Inter Slices
+> > (0:disable/default,1: enable)
+> > Intra4x4ParDisable = 0 # Disable Vertical &
+> > Horizontal 4x4
+> > Intra4x4DiagDisable = 0 # Disable Diagonal
+> > 45degree 4x4
+> > Intra4x4DirDisable = 0 # Disable Other Diagonal
+> > 4x4
+> > Intra16x16ParDisable = 0 # Disable Vertical &
+> > Horizontal 16x16
+> > Intra16x16PlaneDisable = 0 # Disable Planar 16x16
+> > ChromaIntraDisable = 0 # Disable Intra Chroma
+> > modes other than DC
+> > EnableIPCM = 1 # Enable IPCM macroblock
+> > mode
+> >
+> > DisposableP = 0 # Enable Disposable P
+> > slices in the primary layer (0: disable/default, 1:
+> > enable)
+> > DispPQPOffset = 0 # Quantizer offset for
+> > disposable P slices (0: default)
+> >
+> >
+> #############################################################
+> #############################
+> > # B Slices
+> >
+> #############################################################
+> #############################
+> >
+> > NumberBFrames = 0 # Number of B coded
+> > frames inserted (0=not used)
+> > #NumberBFrames = 1 # Number of B coded
+> > frames inserted (0=not used)
+> > QPBSlice = 30 # Quant. param for B
+> > slices (0-51)
+> > BRefPicQPOffset = 0 # Quantization offset
+> > for reference B coded pictures (-51..51)
+> > DirectModeType = 1 # Direct Mode Type
+> > (0:Temporal 1:Spatial)
+> > DirectInferenceFlag = 1 # Direct Inference Flag
+> > (0: Disable 1: Enable)
+> > BList0References = 0 # B slice List 0
+> > reference override (0 disable, N <=
+> > NumberReferenceFrames)
+> > BList1References = 1 # B slice List 1
+> > reference override (0 disable, N <=
+> > NumberReferenceFrames)
+> > # 1 List1 reference is
+> > usually recommended for normal GOP Structures.
+> > # A larger value is
+> > usually more appropriate if a more flexible
+> > # structure is used
+> > (i.e. using PyramidCoding)
+> >
+> > BReferencePictures = 0 # Referenced B coded
+> > pictures (0=off, 1=on)
+> >
+> > PyramidCoding = 0 # B pyramid (0= off, 1=
+> > 2 layers, 2= 2 full pyramid, 3 = explicit)
+> > PyramidLevelQPEnable = 1 # Adjust QP based on
+> > Pyramid Level (in increments of 1). Overrides
+> > BRefPicQPOffset behavior.(0=off, 1=on)
+> > ExplicitPyramidFormat = "b2r28b0e30b1e30b3e30b4e30"
+> > # Explicit Enhancement GOP. Format is
+> > {FrameDisplay_orderReferenceQP}.
+> >
+> > # Valid values for reference type is r:reference,
+> > e:non reference.
+> > PyramidRefReorder = 1 # Reorder References
+> > according to Poc distance for PyramidCoding (0=off,
+> > 1=enable)
+> > PocMemoryManagement = 1 # Memory management
+> > based on Poc Distances for PyramidCoding (0=off,
+> > 1=on)
+> >
+> > BiPredMotionEstimation = 0 # Enable Bipredictive
+> > based Motion Estimation (0:disabled, 1:enabled)
+> > BiPredMERefinements = 3 # Bipredictive ME extra
+> > refinements (0: single, N: N extra refinements (1
+> > default)
+> > BiPredMESearchRange = 16 # Bipredictive ME
+> > Search range (8 default). Note that range is halved
+> > for every extra refinement.
+> > BiPredMESubPel = 1 # Bipredictive ME
+> > Subpixel Consideration (0: disabled, 1: single
+> > level, 2: dual level)
+> >
+> >
+> >
+> #############################################################
+> #############################
+> > # SP Frames
+> >
+> #############################################################
+> #############################
+> >
+> > SPPicturePeriodicity = 0 # SP-Picture Periodicity
+> > (0=not used)
+> > QPSPSlice = 36 # Quant. param of
+> > SP-Slices for Prediction Error (0-51)
+> > QPSP2Slice = 35 # Quant. param of
+> > SP-Slices for Predicted Blocks (0-51)
+> > SI_FRAMES = 0 # SI frame encoding flag
+> > (0=not used, 1=used)
+> > SP_output = 0 # Controls whether
+> > coefficients will be output to encode switching SP
+> > frames (0=no, 1=yes)
+> > SP_output_name = "low_quality.dat" #
+> > Filename for SP output coefficients
+> >
+> === message truncated ===> test.264
+> ........H.26L coded
+> > bitstream
+> > test_dec.yuv ........Output file,
+> > YUV/RGB
+> > test_rec.yuv ........Ref sequence (for
+> > SNR)
+> > 1 ........Write 4:2:0 chroma
+> > components for monochrome streams
+> > 0 ........NAL mode (0=Annex
+> > B, 1: RTP packets)
+> > 0 ........SNR computation
+> > offset
+> > 2 ........Poc Scale (1 or 2)
+> > 500000 ........Rate_Decoder
+> > 104000 ........B_decoder
+> > 73000 ........F_decoder
+> > leakybucketparam.cfg ........LeakyBucket Params
+> > 0 ........Err
+> > Concealment(0:Off,1:Frame Copy,2:Motion Copy)
+> > 2 ........Reference POC gap
+> > (2: IPP (Default), 4: IbP / IpP)
+> > 2 ........POC gap (2: IPP
+> > /IbP/IpP (Default), 4: IPP with frame skip = 1 etc.)
+> >
+> >
+> > This is a file containing input parameters to the
+> > JVT H.264/AVC decoder.
+> > The text line following each parameter is discarded
+> > by the decoder.
+> > > Setting Default Parameters...
+> > Parsing Configfile
+> >
+> encoder.cfg..................................................
........................................................................
............................................................
+> >
+> > ------------------------------- JM 10.2 (FRExt)
+> > --------------------------------
+> > Input YUV file : video_source
+> > Output H.264 bitstream :
+> > test.264_nskipped
+> > Output YUV file : test_rec.yuv
+> > YUV Format : YUV 4:2:0
+> > Frames to be encoded I-P/B : 100/0
+> > PicInterlace / MbInterlace : 0/0
+> > Transform8x8Mode : 0
+> >
+> -------------------------------------------------------------
+> ------------------
+> > Frame Bit/pic QP SnrY SnrU SnrV
+> > Time(ms) MET(ms) Frm/Fld Ref
+> >
+> -------------------------------------------------------------
+> ------------------
+> > 0000(NVB) 168
+> > 0000(IDR) 27688 28 36.878 39.761 42.034
+> > 243 0 FRM 1
+> > 0001(P) 6272 28 36.214 39.463 41.563
+> > 829 469 FRM 1
+> > 0002(P) 7456 28 36.164 39.215 41.344
+> > 831 459 FRM 1
+> > 0003(P) 6624 28 35.872 39.059 41.004
+> > 804 462 FRM 1
+> > 0004(P) 6008 28 35.689 38.980 40.917
+> > 803 443 FRM 1
+> > 0005(P) 6816 28 35.657 38.916 40.795
+> > 803 460 FRM 1
+> > 0006(P) 6928 28 35.474 39.152 40.755
+> > 805 455 FRM 1
+> > 0007(P) 7416 28 35.562 39.175 40.805
+> > 801 457 FRM 1
+> > 0008(P) 6264 28 35.481 39.052 40.573
+> > 797 445 FRM 1
+> > 0009(P) 5896 28 35.512 38.998 40.790
+> > 800 460 FRM 1
+> > 0010(P) 6448 28 35.573 38.931 40.543
+> > 845 487 FRM 1
+> > 0011(P) 6832 28 35.568 38.905 40.422
+> > 801 430 FRM 1
+> > 0012(P) 7032 28 35.482 38.900 40.525
+> > 815 463 FRM 1
+> > 0013(P) 5704 28 35.300 38.908 40.671
+> > 878 496 FRM 1
+> > 0014(P) 4968 28 35.301 38.742 40.583
+> > 837 479 FRM 1
+> > 0015(P) 5736 28 35.218 38.654 40.486
+> > 805 460 FRM 1
+> > 0016(P) 6720 28 35.322 38.811 40.202
+> > 805 442 FRM 1
+> > 0017(P) 6776 28 35.400 38.761 40.295
+> > 797 451 FRM 1
+> > 0018(P) 6520 28 35.451 38.732 40.177
+> > 800 450 FRM 1
+> > 0019(P) 6944 28 35.420 38.570 40.099
+> > 801 458 FRM 1
+> > 0020(P) 7408 28 35.495 38.343 40.230
+> > 809 451 FRM 1
+> > 0021(P) 8080 28 35.432 38.334 40.005
+> > 804 449 FRM 1
+> > 0022(P) 7960 28 35.335 38.336 39.792
+> > 800 452 FRM 1
+> > 0023(P) 6344 28 35.393 38.423 39.989
+> > 804 458 FRM 1
+> > 0024(P) 6328 28 35.256 38.392 39.847
+> > 807 454 FRM 1
+> > 0025(P) 5664 28 35.197 38.337 39.762
+> > 819 450 FRM 1
+> > 0026(P) 6768 28 35.349 38.385 39.754
+> > 802 438 FRM 1
+> > 0027(P) 6584 28 35.375 38.377 39.789
+> > 799 452 FRM 1
+> > 0028(P) 7264 28 35.503 38.542 39.802
+> > 805 454 FRM 1
+> > 0029(P) 6752 28 35.443 38.528 39.809
+> > 874 510 FRM 1
+> > 0030(P) 6744 28 35.320 38.412 39.989
+> > 809 459 FRM 1
+> > 0031(P) 7304 28 35.295 38.368 40.031
+> > 807 461 FRM 1
+> > 0032(P) 7864 28 35.338 38.600 40.147
+> > 834 470 FRM 1
+> > 0033(P) 6944 28 35.302 38.458 40.145
+> > 849 467 FRM 1
+> > 0034(P) 6336 28 35.278 38.401 40.048
+> > 820 449 FRM 1
+> > 0035(P) 7160 28 35.311 38.562 40.193
+> > 813 460 FRM 1
+> > 0036(P) 8464 28 35.268 38.686 40.381
+> > 810 444 FRM 1
+> > 0037(P) 7040 28 35.293 38.507 40.094
+> > 846 474 FRM 1
+> > 0038(P) 6840 28 35.172 38.576 40.341
+> > 822 453 FRM 1
+> > 0039(P) 6032 28 35.171 38.486 40.517
+> > 837 452 FRM 1
+> > 0040(P) 6424 28 35.235 38.429 40.300
+> > 840 473 FRM 1
+> > 0041(P) 7848 28 35.367 38.588 40.413
+> > 822 461 FRM 1
+> > 0042(P) 7400 28 35.381 38.524 40.561
+> > 830 469 FRM 1
+> > 0043(P) 6664 28 35.260 38.677 40.692
+> > 825 463 FRM 1
+> > 0044(P) 5944 28 35.314 38.588 40.344
+> > 838 461 FRM 1
+> > 0045(P) 6232 28 35.342 38.718 40.523
+> > 827 473 FRM 1
+> > 0046(P) 6848 28 35.433 38.730 40.246
+> > 826 475 FRM 1
+> > 0047(P) 6288 28 35.492 38.762 40.266
+> > 862 478 FRM 1
+> > 0048(P) 6504 28 35.483 38.660 40.181
+> > 818 449 FRM 1
+> > 0049(P) 7032 28 35.490 38.703 40.325
+> > 823 468 FRM 1
+> > 0050(P) 6672 28 35.548 38.745 40.322
+> > 836 468 FRM 1
+> > 0051(P) 7424 28 35.517 38.725 40.407
+> > 838 470 FRM 1
+> > 0052(P) 7312 28 35.582 38.577 40.452
+> > 843 470 FRM 1
+> > 0053(P) 6552 28 35.613 38.850 40.417
+> > 824 472 FRM 1
+> > 0054(P) 4792 28 35.426 38.821 40.606
+> > 809 451 FRM 1
+> > 0055(P) 5160 28 35.485 38.927 40.391
+> > 807 456 FRM 1
+> > 0056(P) 5496 28 35.382 38.791 40.393
+> > 817 467 FRM 1
+> > 0057(P) 5016 28 35.415 38.802 40.328
+> > 819 456 FRM 1
+> > 0058(P) 4992 28 35.451 38.847 40.395
+> > 818 453 FRM 1
+> > 0059(P) 3704 28 35.379 38.781 40.418
+> > 854 477 FRM 1
+> > 0060(P) 4840 28 35.397 38.736 40.377
+> > 816 466 FRM 1
+> > 0061(P) 5952 28 35.389 38.768 40.318
+> > 818 475 FRM 1
+> > 0062(P) 7936 28 35.312 38.732 40.410
+> > 843 473 FRM 1
+> > 0063(P) 9888 28 35.272 38.544 40.405
+> > 821 454 FRM 1
+> > 0064(P) 8696 28 35.255 38.609 40.341
+> > 814 457 FRM 1
+> > 0065(P) 8080 28 35.308 38.451 40.515
+> > 812 449 FRM 1
+> > 0066(P) 8280 28 35.180 38.470 40.197
+> > 808 438 FRM 1
+> > 0067(P) 9072 28 35.311 38.436 40.287
+> > 813 441 FRM 1
+> > 0068(P) 9040 28 35.287 38.386 40.293
+> > 814 448 FRM 1
+> > 0069(P) 8856 28 35.381 38.518 40.458
+> > 815 462 FRM 1
+> > 0070(P) 9192 28 35.319 38.464 40.608
+> > 812 456 FRM 1
+> > 0071(P) 9200 28 35.353 38.554 40.694
+> > 810 459 FRM 1
+> > 0072(P) 9344 28 35.440 38.664 40.873
+> > 822 448 FRM 1
+> > 0073(P) 7432 28 35.386 38.804 40.950
+> > 822 458 FRM 1
+> > 0074(P) 7624 28 35.415 38.930 40.898
+> > 808 450 FRM 1
+> > 0075(P) 8472 28 35.314 39.189 41.191
+> > 811 456 FRM 1
+> > 0076(P) 8560 28 35.362 39.126 41.510
+> > 811 446 FRM 1
+> > 0077(P) 7792 28 35.459 38.956 41.368
+> > 853 477 FRM 1
+> > 0078(P) 7120 28 35.425 39.113 41.530
+> > 873 477 FRM 1
+> > 0079(P) 6776 28 35.427 39.161 41.502
+> > 839 464 FRM 1
+> > 0080(P) 7520 28 35.363 39.295 41.409
+> > 838 475 FRM 1
+> > 0081(P) 7024 28 35.358 39.136 41.263
+> > 844 486 FRM 1
+> > 0082(P) 6832 28 35.431 39.202 41.389
+> > 830 454 FRM 1
+> > 0083(P) 6680 28 35.443 39.070 41.335
+> > 866 500 FRM 1
+> > 0084(P) 6224 28 35.433 39.023 41.133
+> > 830 469 FRM 1
+> > 0085(P) 6376 28 35.512 39.026 41.113
+> > 814 476 FRM 1
+> > 0086(P) 7784 28 35.620 39.187 41.265
+> > 816 465 FRM 1
+> > 0087(P) 6440 28 35.671 39.248 41.358
+> > 852 474 FRM 1
+> > 0088(P) 6536 28 35.565 39.489 41.595
+> > 841 469 FRM 1
+> > 0089(P) 6808 28 35.606 39.426 41.621
+> > 828 462 FRM 1
+> > 0090(P) 6752 28 35.598 39.389 41.593
+> > 812 472 FRM 1
+> >
+> === message truncated ===>
+> > skip_nalu ----------means output from dropping
+> > utility-------------------------
+> >
+> > NALU 5: skipping NALU...
+> > NALU 14: skipping NALU...
+> > NALU 23: skipping NALU...
+> > NALU 32: skipping NALU...
+> > NALU 41: skipping NALU...
+> > NALU 50: skipping NALU...
+> > NALU 65: skipping NALU...
+> > NALU 73: skipping NALU...
+> > NALU 81: skipping NALU...
+> > NALU 88: skipping NALU...
+> > NALU 92: skipping NALU...
+> > NALU 95: skipping NALU...
+> > NALU 100: skipping NALU...
+> > NALU 108: skipping NALU...
+> > NALU 116: skipping NALU...
+> >
+> >
+> >
+> =============================================================
+> > skipped / total NALUs: 15 / 900 (excl. 1 SPS + 1
+> > PPS)
+> >
+> >
+> > ldecod.dbg.exe -----means following is the output
+> > from decoder-------------
+> >
+> > ----------------------------- JM 10.2 (FRExt)
+> > -----------------------------
+> > Decoder config file : (null)
+> >
+> -------------------------------------------------------------
+> -------------
+> > Input H.264 bitstream : test.264
+> > Output decoded YUV :
+> > test_dec.yuv
+> > Output status file : log.dec
+> > Input reference file :
+> > test_rec.yuv
+> >
+> -------------------------------------------------------------
+> -------------
+> > POC must = frame# or field# for SNRs to be correct
+> >
+> -------------------------------------------------------------
+> -------------
+> > Frame POC Pic# QP SnrY SnrU SnrV
+> > Y:U:V Time(ms)
+> >
+> -------------------------------------------------------------
+> -------------
+> > 0000(I) 0 0 28 0.0000 0.0000
+> > 0.0000 4:2:0 75
+> > 0001(P) 2 1 28 0.0000 0.0000
+> > 0.0000 4:2:0 67
+> > 0002(P) 4 2 28 0.0000 0.0000
+> > 0.0000 4:2:0 67
+> > 0003(P) 6 3 28 0.0000 0.0000
+> > 0.0000 4:2:0 69
+> > 0004(P) 8 4 28 0.0000 0.0000
+> > 0.0000 4:2:0 74
+> > 0005(P) 10 5 28 0.0000 0.0000
+> > 0.0000 4:2:0 71
+> > 0006(P) 12 6 28 0.0000 0.0000
+> > 0.0000 4:2:0 72
+> > 0007(P) 14 7 28 0.0000 0.0000
+> > 0.0000 4:2:0 75
+> > 0008(P) 16 8 28 0.0000 0.0000
+> > 0.0000 4:2:0 72
+> > 0009(P) 18 9 28 0.0000 0.0000
+> > 0.0000 4:2:0 75
+> > 0010(P) 20 10 28 0.0000 0.0000
+> > 0.0000 4:2:0 71
+> > 0011(P) 22 11 28 0.0000 0.0000
+> > 0.0000 4:2:0 73
+> > 0012(P) 24 12 28 0.0000 0.0000
+> > 0.0000 4:2:0 71
+> > 0013(P) 26 13 28 0.0000 0.0000
+> > 0.0000 4:2:0 73
+> > 0014(P) 28 14 28 0.0000 0.0000
+> > 0.0000 4:2:0 65
+> > 0015(P) 30 15 28 0.0000 0.0000
+> > 0.0000 4:2:0 74
+> > 0016(P) 32 16 28 0.0000 0.0000
+> > 0.0000 4:2:0 77
+> > 0017(P) 34 17 28 0.0000 0.0000
+> > 0.0000 4:2:0 72
+> > 0018(P) 36 18 28 0.0000 0.0000
+> > 0.0000 4:2:0 66
+> > 0019(P) 38 19 28 0.0000 0.0000
+> > 0.0000 4:2:0 74
+> > 0020(P) 40 20 28 0.0000 0.0000
+> > 0.0000 4:2:0 76
+> > 0021(P) 42 21 28 0.0000 0.0000
+> > 0.0000 4:2:0 77
+> > 0022(P) 44 22 28 0.0000 0.0000
+> > 0.0000 4:2:0 76
+> > 0023(P) 46 23 28 0.0000 0.0000
+> > 0.0000 4:2:0 71
+> > 0024(P) 48 24 28 0.0000 0.0000
+> > 0.0000 4:2:0 92
+> > 0025(P) 50 25 28 0.0000 0.0000
+> > 0.0000 4:2:0 79
+> > 0026(P) 52 26 28 0.0000 0.0000
+> > 0.0000 4:2:0 69
+> > 0027(P) 54 27 28 0.0000 0.0000
+> > 0.0000 4:2:0 68
+> > 0028(P) 56 28 28 0.0000 0.0000
+> > 0.0000 4:2:0 75
+> > 0029(P) 58 29 28 0.0000 0.0000
+> > 0.0000 4:2:0 73
+> > 0030(P) 60 30 28 0.0000 0.0000
+> > 0.0000 4:2:0 76
+> > 0031(P) 62 31 28 0.0000 0.0000
+> > 0.0000 4:2:0 75
+> > 0032(P) 64 32 28 0.0000 0.0000
+> > 0.0000 4:2:0 75
+> > 0033(P) 66 33 28 0.0000 0.0000
+> > 0.0000 4:2:0 79
+> > 0034(P) 68 34 28 0.0000 0.0000
+> > 0.0000 4:2:0 71
+> > 0035(P) 70 35 28 0.0000 0.0000
+> > 0.0000 4:2:0 77
+> > 0036(P) 72 36 28 0.0000 0.0000
+> > 0.0000 4:2:0 80
+> > 0037(P) 74 37 28 0.0000 0.0000
+> > 0.0000 4:2:0 74
+> > 0038(P) 76 38 28 0.0000 0.0000
+> > 0.0000 4:2:0 70
+> > 0039(P) 78 39 28 0.0000 0.0000
+> > 0.0000 4:2:0 71
+> > 0040(P) 80 40 28 0.0000 0.0000
+> > 0.0000 4:2:0 68
+> > 0041(P) 82 41 28 0.0000 0.0000
+> > 0.0000 4:2:0 72
+> > 0042(P) 84 42 28 0.0000 0.0000
+> > 0.0000 4:2:0 75
+> > 0043(P) 86 43 28 0.0000 0.0000
+> > 0.0000 4:2:0 74
+> > 0044(P) 88 44 28 0.0000 0.0000
+> > 0.0000 4:2:0 70
+> > 0045(P) 90 45 28 0.0000 0.0000
+> > 0.0000 4:2:0 72
+> > 0046(P) 92 46 28 0.0000 0.0000
+> > 0.0000 4:2:0 73
+> > 0047(P) 94 47 28 0.0000 0.0000
+> > 0.0000 4:2:0 68
+> > 0048(P) 96 48 28 0.0000 0.0000
+> > 0.0000 4:2:0 99
+> > 0049(P) 98 49 28 0.0000 0.0000
+> > 0.0000 4:2:0 74
+> > 0050(P) 100 50 28 0.0000 0.0000
+> > 0.0000 4:2:0 80
+> > 0051(P) 102 51 28 0.0000 0.0000
+> > 0.0000 4:2:0 76
+> > 0052(P) 104 52 28 0.0000 0.0000
+> > 0.0000 4:2:0 76
+> > 0053(P) 106 53 28 0.0000 0.0000
+> > 0.0000 4:2:0 75
+> > 0054(P) 108 54 28 0.0000 0.0000
+> > 0.0000 4:2:0 67
+> > 0055(P) 110 55 28 0.0000 0.0000
+> > 0.0000 4:2:0 65
+> > 0056(P) 112 56 28 0.0000 0.0000
+> > 0.0000 4:2:0 60
+> > 0057(P) 114 57 28 0.0000 0.0000
+> > 0.0000 4:2:0 59
+> > 0058(P) 116 58 28 0.0000 0.0000
+> > 0.0000 4:2:0 61
+> > 0059(P) 118 59 28 0.0000 0.0000
+> > 0.0000 4:2:0 57
+> > 0060(P) 120 60 28 0.0000 0.0000
+> > 0.0000 4:2:0 62
+> > 0061(P) 122 61 28 0.0000 0.0000
+> > 0.0000 4:2:0 64
+> > 0062(P) 124 62 28 0.0000 0.0000
+> > 0.0000 4:2:0 72
+> > 0063(P) 126 63 28 0.0000 0.0000
+> > 0.0000 4:2:0 75
+> > 0064(P) 128 64 28 0.0000 0.0000
+> > 0.0000 4:2:0 79
+> > 0065(P) 130 65 28 0.0000 0.0000
+> > 0.0000 4:2:0 79
+> > 0066(P) 132 66 28 0.0000 0.0000
+> > 0.0000 4:2:0 75
+> > 0067(P) 134 67 28 0.0000 0.0000
+> > 0.0000 4:2:0 78
+> > 0068(P) 136 68 28 0.0000 0.0000
+> > 0.0000 4:2:0 80
+> > 0069(P) 138 69 28 0.0000 0.0000
+> > 0.0000 4:2:0 78
+> > 0070(P) 140 70 28 0.0000 0.0000
+> > 0.0000 4:2:0 78
+> > 0071(P) 142 71 28 0.0000 0.0000
+> > 0.0000 4:2:0 78
+> > 0072(P) 144 72 28 0.0000 0.0000
+> > 0.0000 4:2:0 81
+> > 0073(P) 146 73 28 0.0000 0.0000
+> > 0.0000 4:2:0 77
+> > 0074(P) 148 74 28 0.0000 0.0000
+> > 0.0000 4:2:0 78
+> > 0075(P) 150 75 28 0.0000 0.0000
+> > 0.0000 4:2:0 75
+> > 0076(P) 152 76 28 0.0000 0.0000
+> > 0.0000 4:2:0 77
+> > 0077(P) 154 77 28 0.0000 0.0000
+> > 0.0000 4:2:0 77
+> >
+> === message truncated ===>
+> _______________________________________________
+> > NOTE: Please use clear subject lines for your posts.
+> > Include [audio, [video], [systems], [general] or
+> > another apppropriate identifier to indicate the type
+> > of question you have.
+> >
+> > Note: Conduct on the mailing list is subject to the
+> > Antitrust guidelines found at
+> http://www.mpegif.org/public/documents/vault/mp-out-30042-Ant
+> itrust.php
+>
+>
+> --
+> Regards,
+> Alex
+>
+> __________________________________________________
+> Do You Yahoo!?
+> Tired of spam? Yahoo! Mail has the best spam protection around
+> http://mail.yahoo.com
+> _______________________________________________
+> NOTE: Please use clear subject lines for your posts. Include
+> [audio, [video], [systems], [general] or another
+> apppropriate identifier to indicate the type of question you have.
+>
+> Note: Conduct on the mailing list is subject to the
+> Antitrust guidelines found at
+> http://www.mpegif.org/public/documents/vault/mp-out-30042-Ant
+> itrust.php
+>
From singer apple.com Sun Oct 22 21:50:38 2006
From: singer apple.com (Dave Singer)
Date: Sun Oct 22 14:04:07 2006
Subject: [Mp4-tech] H264 RTP Timestamp
In-Reply-To:
References:
Message-ID:
At 15:51 -0700 20/10/06, Jerry Johns wrote:
>Hello,
> I'm currently in the process of writing a H264 packetizer,
>and I'm encountering some difficulty composing the RTP timestamps;
>in the H264 sample vids I've had, there have been samples which
>Had SEI messages, indicating a picture_timing msg which means I can
>extract the timing info (is the timing a PTS? Where does the
>reference 90khz come from?) - I've also had samples which don't have
>an SEI, (just parameter sets and slices), in which case, how do I
>compose the 32-bit timestamp?
The system that the stream is in is probably carrying the timing in
that case (e.g. the mp4 file format).
>
>Thank you
>
>_______________________________________________
>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
--
David Singer
Apple Computer/QuickTime
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061022/bd3462da/attachment.html
From zombiyaga yahoo.com Sun Oct 22 09:48:03 2006
From: zombiyaga yahoo.com (Alex)
Date: Sun Oct 22 20:52:07 2006
Subject: [Mp4-tech] H264 RTP Timestamp
In-Reply-To:
Message-ID: <20061022164803.13678.qmail@web53904.mail.yahoo.com>
Dave,
What if the system does not use any inrmediate file
format structure ? How to reconstruct 32 bit value
timestamp from SEI message structure ?
Thanks.
--- Dave Singer wrote:
> At 15:51 -0700 20/10/06, Jerry Johns wrote:
> >Hello,
> > I'm currently in the process of writing
> a H264 packetizer,
> >and I'm encountering some difficulty composing the
> RTP timestamps;
> >in the H264 sample vids I've had, there have been
> samples which
> >Had SEI messages, indicating a picture_timing msg
> which means I can
> >extract the timing info (is the timing a PTS? Where
> does the
> >reference 90khz come from?) - I've also had samples
> which don't have
> >an SEI, (just parameter sets and slices), in which
> case, how do I
> >compose the 32-bit timestamp?
>
> The system that the stream is in is probably
> carrying the timing in
> that case (e.g. the mp4 file format).
>
> >
> >Thank you
> >
> >_______________________________________________
> >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
>
>
> --
> David Singer
> Apple Computer/QuickTime>
_______________________________________________
> 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
--
Regards,
Alex
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
From mp4-tech-owner lists.mpegif.org Sun Oct 22 22:46:13 2006
From: mp4-tech-owner lists.mpegif.org (MPEGIF List Admins)
Date: Sun Oct 22 22:04:07 2006
Subject: [Mp4-tech] FW: MPEG-4 part 2 reference software bug: encoder and
decoder outputdifferent motion vectors
Message-ID: <005c01c6f61b$1e1c2a30$6501a8c0@corp.intertrust.com>
This was sent to mp4-tech-bounces instead to mp4-tech. Forwarding.
_____
From: Tung yi-Shin [mailto:tung@cmlab.csie.ntu.edu.tw]
Sent: Sunday, 22 October 2023 06:08
To: mp4-tech-bounces@lists.mpegif.org
Subject: RE: MPEG-4 part 2 reference software bug: encoder and decoder
outputdifferent motion vectors
Hi tomer,
Could you try the latest version of MoMoSys code instead? The latest version
is FGS-Ref-Software-FDAM-N4711-MoMuSys.zip (FDAM), which is provided in
14496-5:2001/AMD 1. Many fixes are included in this version. If the problem
is still there, please send your encoding parameter files to me? I would
trace it and provide fixes for you if it is indeed a bug.
Regards,
Yi-Shin
From: mp4-tech-bounces@lists.mpegif.org
[mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of Tomer Segal
> Sent: Tuesday, August 01, 2023 7:33 PM
> To: mp4-tech@lists.mpegif.org
> Subject: [Mp4-tech] encoder and decoder output different motion vectors
>
>
> hi,
> i'm a little confused about a set of results i got using the mpeg4
reference software (MoMuSys-1.0-001220_sony).
> i encoded a yuv sequence having the encoder output the motion vectors
calculated during encoding. then decoded the resulting mpeg file with the
decoder, enabling a trace of the motion vectors extracted during decoding.
i repeated these steps twice, once for a very simple yuv sequence (few
blocks change throughout the sequence) and a second time using a more
complex sequence. for the simple sequence the motion vectors output by the
encoder and the decoder were exactly the same. for the complex sequence
however there were differences between the vectors - in most blocks vectors
differed by a single halfpel, but a few of them differed by as much as 5
halfpels.
> i thought the motion vectors extracted by the decoder were suppose to be
exactly the same as the ones calculated in the encoder. am i wrong? i tried
finding the answer in the mpeg4 iso and other related articles but i was
unable to.
> if indeed the vectors are supposed to be identical, what could be causing
this difference?
>
>
> Thanks,
> Tomer.
>
>
--
Communication and Multimedia Laboratory
Dept. of Computer Science and Information Engineering, NTU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061022/4df153f4/attachment.html
From samuel lambdastream.com Mon Oct 23 09:21:24 2006
From: samuel lambdastream.com (Samuel Rivas)
Date: Mon Oct 23 13:28:09 2006
Subject: [Mp4-tech] Dropping NAL units on bit errors: Best approach?
In-Reply-To:
References:
Message-ID: <20061023072124.GA3014@lambdastream.com>
John Cox wrote:
> It is always legal to pack the end of a nal_unit with extra zeros
> (trailing_zero_8bits) so a non-start-of-AU NALU may appear to have three
> leading seros but in fact that is one zero on the end of the previous
> unit and two leading zeros on this unit. This detail is important if
> you are trying to determine the exact byte on which a unit starts (e.g.
> when encapsulated in PES the PTS applies to the first unit which starts
> in that PES packet).
I do not think it is that way. The spec reads:
"When any of the following conditions are fulfilled, the zero_byte
syntax element shall be present"
I might have overlooked it, but I think there is not a statement
saying that "the zero_byte shall not be present otherwise". Thus,
following the description in B.1.1, any 0x00000001 is always a zero_byte
followed by a start_code_prefix_one_3bytes.
Regards.
--
Samuel
From samuel lambdastream.com Mon Oct 23 09:40:01 2006
From: samuel lambdastream.com (Samuel Rivas)
Date: Mon Oct 23 13:28:18 2006
Subject: [Mp4-tech] Learning more about MPEG
In-Reply-To: <024701c6f538$87fce770$6400a8c0@Aum>
References: <024701c6f538$87fce770$6400a8c0@Aum>
Message-ID: <20061023074001.GA3488@lambdastream.com>
Anil Gupte wrote:
> Can anyone point me to some resources about reading and writing MPEG files
MPEG file is a way generic concept. They might be MPEG-1 system files, MPEG-2
program or transport streams, MPEG-2 PES, MP4 files, elementary streams,
...
--
Samuel
From jc sj.co.uk Mon Oct 23 17:26:32 2006
From: jc sj.co.uk (John Cox)
Date: Mon Oct 23 19:40:07 2006
Subject: [Mp4-tech] Dropping NAL units on bit errors: Best approach?
In-Reply-To: <20061023072124.GA3014@lambdastream.com>
References:
<20061023072124.GA3014@lambdastream.com>
Message-ID:
Samuel, Gary
You are correct - I had overlooked the text at the start of Annex-B
where it says:
"The byte stream format consists of a sequence of byte stream NAL unit
syntax structures. Each byte stream NAL unit syntax structure contains
one start code prefix followed by one nal_unit( NumBytesInNALunit )
syntax structure. It may (and under some circumstances, it shall) also
contain an additional zero_byte syntax element. It may also contain one
or more additional trailing_zero_8bits syntax elements. When it is the
first byte stream NAL unit in the bitstream, it may also contain one or
more additional leading_zero_8bits syntax elements."
Which makes everything much clearer.
Thank you everyone for fixing my misreading. I clearly understood this
once as my code is correct even if my recent arguments have been wrong!
Regards
John Cox
>John Cox wrote:
>> It is always legal to pack the end of a nal_unit with extra zeros
>> (trailing_zero_8bits) so a non-start-of-AU NALU may appear to have three
>> leading seros but in fact that is one zero on the end of the previous
>> unit and two leading zeros on this unit. This detail is important if
>> you are trying to determine the exact byte on which a unit starts (e.g.
>> when encapsulated in PES the PTS applies to the first unit which starts
>> in that PES packet).
>
> I do not think it is that way. The spec reads:
>
>"When any of the following conditions are fulfilled, the zero_byte
>syntax element shall be present"
>
> I might have overlooked it, but I think there is not a statement
>saying that "the zero_byte shall not be present otherwise". Thus,
>following the description in B.1.1, any 0x00000001 is always a zero_byte
>followed by a start_code_prefix_one_3bytes.
>
> Regards.
From sma com.dtu.dk Tue Oct 24 11:55:37 2006
From: sma com.dtu.dk (Shankar Manuel Aghito)
Date: Tue Oct 24 13:46:08 2006
Subject: [Mp4-tech] why are there 4 bytes 0x00000001 instead of 3 bytes
inevery NALU?
Message-ID:
Hi Luqman,
I think there is something wrong in your results.
Since in the encoder.cfg you have
OutputFile = "test.264_nskipped"
And in the decoder.cfg
test.264 ........H.26L coded bitstream
I assume that you remove NALUS from the bitstream "test.264_nskipped"
and then you name "test.264" the damaged bitstream, right?
Then, since you select in decoder.cfg
test_dec.yuv ........Output file, YUV/RGB
test_rec.yuv ........Ref sequence (for SNR)
The PSNR calculations in the output from the decoder should show were
errors occurr ( 0 indicate infinite PSNR, while you should see some
finite values of PSNR, since you cannot expect the error concealment to
perfectly reconstruct test_rec.yuv )
Just looking at the first of your examples (reported below), since you
use 9 slices/picture and you remove NALUs 5,14,23,32,........ you should
start seeing errors from the beginning, while in your results it seems
that the video is perfectly reconstructed until frame picture 96, when
the decoder crashes.
So I don't think that you are decoding the corrupted bitstream, I think
that you are decoding the original, and the decoder crashes for some
other reason. It must be something wrong in you settings.
When you run the decoder, do you type explicitely "ldecod decoder.cfg" ?
Regards,
Manuel
skip_nalu ----------means output from dropping
utility-------------------------
NALU 5: skipping NALU...
NALU 14: skipping NALU...
NALU 23: skipping NALU...
NALU 32: skipping NALU...
NALU 41: skipping NALU...
NALU 50: skipping NALU...
NALU 65: skipping NALU...
NALU 73: skipping NALU...
NALU 81: skipping NALU...
NALU 88: skipping NALU...
NALU 92: skipping NALU...
NALU 95: skipping NALU...
NALU 100: skipping NALU...
NALU 108: skipping NALU...
NALU 116: skipping NALU...
=============================================================
skipped / total NALUs: 15 / 900 (excl. 1 SPS + 1 PPS)
ldecod.dbg.exe -----means following is the output from
decoder-------------
----------------------------- JM 10.2 (FRExt)
-----------------------------
Decoder config file : (null)
------------------------------------------------------------------------
--
Input H.264 bitstream : test.264
Output decoded YUV : test_dec.yuv
Output status file : log.dec
Input reference file : test_rec.yuv
------------------------------------------------------------------------
--
POC must = frame# or field# for SNRs to be correct
------------------------------------------------------------------------
--
Frame POC Pic# QP SnrY SnrU SnrV Y:U:V Time(ms)
------------------------------------------------------------------------
--
0000(I) 0 0 28 0.0000 0.0000 0.0000 4:2:0 75
0001(P) 2 1 28 0.0000 0.0000 0.0000 4:2:0 67
0002(P) 4 2 28 0.0000 0.0000 0.0000 4:2:0 67
0003(P) 6 3 28 0.0000 0.0000 0.0000 4:2:0 69
0004(P) 8 4 28 0.0000 0.0000 0.0000 4:2:0 74
0005(P) 10 5 28 0.0000 0.0000 0.0000 4:2:0 71
0006(P) 12 6 28 0.0000 0.0000 0.0000 4:2:0 72
0007(P) 14 7 28 0.0000 0.0000 0.0000 4:2:0 75
0008(P) 16 8 28 0.0000 0.0000 0.0000 4:2:0 72
....
0091(P) 182 91 28 0.0000 0.0000 0.0000 4:2:0 71
0092(P) 184 92 28 0.0000 0.0000 0.0000 4:2:0 74
0093(P) 186 93 28 0.0000 0.0000 0.0000 4:2:0 74
0094(P) 188 94 28 0.0000 0.0000 0.0000 4:2:0 77
0095(P) 190 95 28 0.0000 0.0000 0.0000 4:2:0 68
0096(P) 192 96 28 0.0000 0.0000 0.0000 4:2:0 72
ERROR: failed to find NumCoeff/TrailingOnes
( 96 P + 1 I + 1 SPS + 1 PPS = 96 + 3 = 99 Frames <<---- only 1 Frame
lost )
From jerry.johns nuvation.com Tue Oct 24 08:41:04 2006
From: jerry.johns nuvation.com (Jerry Johns)
Date: Tue Oct 24 18:10:07 2006
Subject: [Mp4-tech] H264 RTP Timestamp
Message-ID: <22F8D1FFED33654987DE9D447F74E54602DF@mailguy2.nuvation.com>
Hello,
I'm not encapsulating this H264 stream into an mp4 format; I'm
writing the packetizer from scratch, and intending it to play on e.g VLC
Player
Right now, its playing ok, but because there's not good timing information
(I'm calculating it myself by doing 1/29.97 and adding it each NAL unit), it
doesn't play too well and it consntally misses a lot of frames
If there was a way to solve this problem, it'd be of help :-)
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061024/63785cc7/attachment.html
From luca.bs gmx.de Tue Oct 24 19:17:27 2006
From: luca.bs gmx.de (Luca)
Date: Tue Oct 24 18:10:12 2006
Subject: [Mp4-tech] [Video] H.264/AVC Switching SP frames (Windows XP)
Message-ID: <20061024171727.61950@gmx.net>
Dear Experts,
hoping that is not a FAQ i would like to ask you something concerning the switching SP frames encoding.
Once i get the "low_quality.dat" and "hi_quality.dat" for the two encoded sequences, i tried to encode the switching frames setting
SP2_FRAMES = 1 # switching SP frame encoding flag (0=not used, 1=used)
But actually i get the following error:
"Fatal: cannot read in SP input file, exit"
since the function "read_SP_coefficients" during the 19th row the function
if(img->width!=(int)fread(lrec[i],sizeof(int),img->width,SP_coeff_file))
produces an error since 80 != 176.
I would like to ask you if someone else encountered my problem in Windows XP and can help me finding a solution.
Greetings,
Luca.
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
From samuel lambdastream.com Wed Oct 25 08:41:13 2006
From: samuel lambdastream.com (Samuel Rivas)
Date: Wed Oct 25 09:16:11 2006
Subject: [Mp4-tech] H264 RTP Timestamp
In-Reply-To: <22F8D1FFED33654987DE9D447F74E54602DF@mailguy2.nuvation.com>
References: <22F8D1FFED33654987DE9D447F74E54602DF@mailguy2.nuvation.com>
Message-ID: <20061025064113.GA4945@lambdastream.com>
Jerry Johns wrote:
> Right now, its playing ok, but because there's not good timing information
> (I'm calculating it myself by doing 1/29.97 and adding it each NAL unit),
> it doesn't play too well and it consntally misses a lot of frames
Timestamps for AVC over RTP are measured with a 90 Khz clock. Also,
note that a NAL unit is not a frame. Take a look to RFC 3984.
Regards
--
Samuel
From apulicat uci.edu Wed Oct 25 18:35:02 2006
From: apulicat uci.edu (apulicat@uci.edu)
Date: Thu Oct 26 12:46:09 2006
Subject: [Mp4-tech] Extracting bit-stream from a Mpeg-4 coded file
Message-ID: <40965.128.195.169.238.1161826502.squirrel@webmail.uci.edu>
Hello everybody,
My research work needs that I transmit a bitstream of a Mpeg4 coded
file. I have the coded file with me, but I am not sure how to extract
the bitstream from that. I would appreciate any help regarding this.
Thanks
Anand
From venkataramanparam gmail.com Thu Oct 26 09:48:17 2006
From: venkataramanparam gmail.com (Venkataraman Paramasivam)
Date: Thu Oct 26 12:46:15 2006
Subject: [Mp4-tech] Fast Forwarding in MPEG4
Message-ID: <85eb6f750610252118hc5e0c72ne81e51edeeac5158@mail.gmail.com>
Dear Experts,
i'm writing playback scripting. we face jittering problem in Fast
Forwarding n itz not in a linear fasion when it come in x2 thru' x32. can
anyone give an idea how how to Fast Forward? like shud' i seek for I frames
or skip time and read the frames for the decoder? or else..
Thanx in advance,
With Regards,
Venkat.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061026/abda3d82/attachment.html
From morsela gmail.com Fri Oct 27 21:29:49 2006
From: morsela gmail.com (Mor Sela)
Date: Fri Oct 27 21:04:08 2006
Subject: [Mp4-tech] MPEG4 problem with the new Quicktime (7.1.3)
Message-ID: <1d6b5b880610271229h7b63ec1fl21587e66a923d650@mail.gmail.com>
Hi all,
I had a working encoder for mp4 until the new version of quicktime
(7.1.3) was published.
Now, every time I try to open one of the mp4 I have created, quicktime
just exits with an 'Error -2010: The movie contains some invalid
data', which actually was a problem I thought I had solved when 7.0.3
came out (which was with the decspecificinfo). I guess the problem
here must be similar to the problem with the previous version. Does
anybody has any idea where could the problem be or even happen to
experience that problem?
Thanks.
From joggingsong gmail.com Mon Oct 30 11:21:49 2006
From: joggingsong gmail.com (jogging song)
Date: Mon Oct 30 07:52:11 2006
Subject: [Mp4-tech] H.263+ should support all annexes from I to T?
Message-ID: <77631ae30610291921n5aa19100ta4732399c78bb450@mail.gmail.com>
Hi,
We know H.263 has three versions, which all is referred to H.263,
H.263+, H.263++. At last H.263 uses profiles and levels to state the
capability of decoders and encoders.
But many codecs states that they support H.263+. In the H.263 of version 2,
Annnex I to T are added. If the implementation of H.263+ supports all these
annexes, it will be very
difficult. If a decoder states it supports H.263+, it should support all
annexes from I to T? If not, which annexes are used in productions
supporting H.263+?
Best Regards
Liwei Song
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061030/125d222a/attachment.html
From garysull windows.microsoft.com Tue Oct 31 13:30:17 2006
From: garysull windows.microsoft.com (Gary Sullivan)
Date: Tue Oct 31 21:40:07 2006
Subject: [Mp4-tech] H.263+ should support all annexes from I to T?
In-Reply-To: <77631ae30610291921n5aa19100ta4732399c78bb450@mail.gmail.com>
Message-ID: <03CB47D9C3F8074498E4653F814D6E8F02AC2955@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
There has been a diversity of decisions made by individual implementers
about which optional features to support. MPEG-4 part 2 includes only
the "baseline" subset of the H.263 Version 1 capabilities (no optional
features).
Annex X specifies some particular profiles. ITU-T videoconferencing
systems tend to provide a very flexible way for decoders and encoders to
declare their capabilities and negotiate a mutually-desirable
configuration. However, it may be desirable to try to implement the
options in a packaged fashion as found in Annex X, since those packages
were created with a desire for such convergence on a few popular
configurations.
Best Regards,
Gary Sullivan
________________________________
From: mp4-tech-bounces@lists.mpegif.org
[mailto:mp4-tech-bounces@lists.mpegif.org] On Behalf Of jogging song
Sent: Sunday, October 29, 2023 7:22 PM
To: mp4-tech@lists.mpegif.org
Subject: [Mp4-tech] H.263+ should support all annexes from I to
T?
Hi,
We know H.263 has three versions, which all is referred to
H.263, H.263+, H.263++. At last H.263 uses profiles and levels to state
the capability of decoders and encoders.
But many codecs states that they support H.263+. In the H.263 of
version 2, Annnex I to T are added. If the implementation of H.263+
supports all these annexes, it will be very
difficult. If a decoder states it supports H.263+, it should
support all annexes from I to T? If not, which annexes are used in
productions supporting H.263+?
Best Regards
Liwei Song
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061031/bdb0a82f/attachment.html
From jerry.johns nuvation.com Tue Oct 31 12:48:37 2006
From: jerry.johns nuvation.com (Jerry Johns)
Date: Wed Nov 1 00:04:06 2006
Subject: [Mp4-tech] H264 Quicktime
Message-ID: <22F8D1FFED33654987DE9D447F74E5460AF7@mailguy2.nuvation.com>
Hello all,
I've gotten a framer working for H264 baseline profile videos
streaming out through RTP to VLC player; however, I was digging around on
playing this video on quicktime? Anyone know where I should start? The MP4
format seems to be the only way I can get quicktime to recognize it, and
although mp4box seems to work well in doing this, reverse engineering their
source code doesn't seem workable
Any info on this MP4 file container format, and its relation to RTP
streaming for H264 files? Any help would be much appreciated (specs,
standards, etc)
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20061031/573d7d04/attachment.html