From dmitriy at graphics.cs.msu.ru Mon Feb 1 17:28:13 2010 From: dmitriy at graphics.cs.msu.ru (Dmitriy Vatolin) Date: Tue, 2 Feb 2010 01:28:13 +0300 Subject: [Mp4-tech] MSU MPEG4-AVC/H.264 codecs comparison Message-ID: <608777852.20100202012813@graphics.cs.msu.ru> Dear Experts, As usual Moscow State University Graphics & Multimedia Laboratory starts next 6-th H.264 codecs comparison. 1. We received results for subjective comparison of several selected codecs. As was promised they was compared: * On sequence with frequent fade effect. * On sport event sequence. * On HD sequences. * On cartoon sequence. Tested codecs: * x264 * Elecard H.264 * Mainconcept H.264 * DivX H.264 * DivX ASP - as reference (pretty good MPEG-4 ASP implementation) Also we received psychovisial presets for x264, Elecard H.264 and Mainconcept H.264 from codec developers. For x264 psychovisial presets was tested and interesting results received (not so obvious). Also visual comparison of 4 good implementation of H.264 provide material for analysis. Other results will be published with objective part. 2. As was noted in "Call for codecs" in this year we will use our new system of exhaustive options analysis, so we can select reasonable options (sometimes better, than developers). So our question for experts: What codecs are the most interesting for you for including into this year comparison? 3. Also for the future questions for companies: What usecases are the most interesting for you? Please answer to Thank you! Also do not hesitate to ask any questions. Yours, Dr. Vatolin -------------- next part -------------- A non-text attachment was scrubbed... Name: H264_2010_subjective.pdf Type: application/pdf Size: 39826 bytes Desc: not available Url : /pipermail/mp4-tech/attachments/20100202/9d65c586/attachment-0001.pdf From cristina.gil at sumenor.com Tue Feb 2 05:38:30 2010 From: cristina.gil at sumenor.com (Cristina Gil) Date: Tue, 2 Feb 2010 11:38:30 +0100 Subject: [Mp4-tech] H264 NAL Header Message-ID: <334C0F5C677B4293A6515DDCD7BB98B6@SUMENORSCS.LOCAL> Hello, I program in vb.net so I have used "some" code to make it works. I have: NAL_forbidden = data(aSkip) And &H80 'NAL_forbidden NAL_nri = (data(aSkip) >> 5) And &H3 'NAL_nri NAL_type = data(aSkip) And &H1F 'NAL_type aSkip += 1 'next byte Select Case NAL_type Case 24 Console.Out.WriteLine("STAP-A") Case 28 FU_indicator = (NAL_forbidden << 7) Or (NAL_nri << 5) Or (28) '28 is FU-A type startBit = data(aSkip) And &H80 'startBit endBit = data(aSkip) And &H40 'endBit If startBit Then 'start data(aSkip) = (data(aSkip - 1) And &HE0) + (data(aSkip) And &H1F) Else 'end End If Case Else Console.Out.WriteLine("else") End Select As result, i get: RTP packet, size: 1400 NAL forbidden zero: 0 NAL nri: 3 NAL Type: FU FU_indicator: 124 Startbit RTP packet, size: 1400 NAL forbidden zero: 0 NAL nri: 3 NAL Type: FU FU_indicator: 124 Endbit RTP packet, size: 1400 NAL forbidden zero: 0 NAL nri: 3 NAL Type: FU FU_indicator: 124 Endbit [.] RTP packet, size: 1400 NAL forbidden zero: 0 NAL nri: 2 NAL Type: FU FU_indicator: 92 Startbit RTP packet, size: 1400 NAL forbidden zero: 0 NAL nri: 2 NAL Type: FU FU_indicator: 92 Endbit RTP packet, size: 1400 NAL forbidden zero: 0 NAL nri: 2 NAL Type: FU FU_indicator: 92 Endbit [.] I think Im doing something wrong, it could be the meaning I give to the parameters. RTP packets are always <= 1400, I always have FU-A units (for one startbit I get a few end bits in the FU indicator, could that be???) and there isn't any non-IDR frames (cause they have to be "NAL nri: 0", in a few packets the value is "NAL nri: 2", but its still a non-IDR, isn't it???). Could you please help me?? Is the data I get correct? What is the next step I have to do to know which kind of frame is? Thanks!!! AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100202/4ef13991/attachment-0001.html From mkaregou at gmail.com Tue Feb 2 09:37:31 2010 From: mkaregou at gmail.com (Malatesh Karegoudar) Date: Tue, 2 Feb 2010 20:07:31 +0530 Subject: [Mp4-tech] AVC Intra coded frame size query Message-ID: <1412b2081002020637r168acfcexaf4ed747e12b3a23@mail.gmail.com> Hello All, The SMPTE Standard RP 2027-2207 mentions limitations on the coded frame size for class 50(High 10 Intra) and class 100 (High 4:2:2 Intra) specifications What does coded frame size mean? Does it include the slice header data? Or only slice_data()? Thanks and regards, Malate -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100202/9bb5af20/attachment.html From vlyamtsev at gmail.com Tue Feb 2 10:14:31 2010 From: vlyamtsev at gmail.com (Victor lyamtsev) Date: Tue, 2 Feb 2010 10:14:31 -0500 Subject: [Mp4-tech] mpegts payload type -?? Message-ID: <76224b101002020714l49ffe641y27ea23c9ae2b13dc@mail.gmail.com> seems as i have some problem with finding how to specify payload type ( codec type ) for mpegts... Can it only be mpeg2 video / mpeg2 audio, or is it possible to specify an arbitrary type? i would appreciate if someone points me to the right rfc... Thank you... -V From ypitrey at gmail.com Tue Feb 2 11:56:37 2010 From: ypitrey at gmail.com (Yohann Pitrey) Date: Tue, 2 Feb 2010 17:56:37 +0100 Subject: [Mp4-tech] JSVM exit code Message-ID: <5c573fd51002020856i36f633b5pb4e5bb4c298dc373@mail.gmail.com> hi all, is there any documentation on the exit codes of the JSVM reference software? i guess that 0 means everything is ok, but i cannot figure out what the other codes mean. for example i often get the -3 error code and i don't know what it means. obviously this can be solved by tracing the execution of the encoder. it would be more convenient to have a rough idea of what caused the crash though. thanks a lot in advance, yohann pitrey. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100202/d64227c4/attachment.html From cristina.gil at sumenor.com Wed Feb 3 06:43:21 2010 From: cristina.gil at sumenor.com (Cristina Gil) Date: Wed, 3 Feb 2010 12:43:21 +0100 Subject: [Mp4-tech] Number of bytes in NAL Unit Message-ID: Hello, I read the RFC3984 document which says the RTP header its 12bytes, but how can i know when the FU-As or NAL units are finished, in other words how many bytes of the RTP payload are padding (which makes the rtp packet header + payload (NAL + Padding) =1400). I read the ISO/IEC 14496 part 10: nal_unit( NumBytesInNALunit ) { forbidden_zero_bit //--->1bit nal_ref_idc //--->2bit nal_unit_type //--->5bit NumBytesInRBSP = 0 for( i = 1; i < NumBytesInNALunit; i++ ) { if( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) { rbsp_byte[ NumBytesInRBSP++ ] rbsp_byte[ NumBytesInRBSP++ ] i += 2 emulation_prevention_three_byte /* equal to 0x03 */ } else rbsp_byte[ NumBytesInRBSP++ ] } } How can i get NumBytesInNALunit? What does next_bits( 24 ) means? Thanks!!! AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100203/0e56bf26/attachment.html From pradeep.puthiyaveetil at patni.com Wed Feb 3 06:43:30 2010 From: pradeep.puthiyaveetil at patni.com (Puthiyaveetil, Pradeep) Date: Wed, 3 Feb 2010 17:13:30 +0530 Subject: [Mp4-tech] Mp4-tech Digest, Vol 79, Issue 3: mpegts payload type -?? (Victor lyamtsev) In-Reply-To: References: Message-ID: The Program Map table (PMT) in the TS stream specifies the stream_type, which specifies the codecs to be used in the MPEG2TS. Refer to the MPEG-2 standard : ISO 13818-1 2000 (E) Regards Pradeep -----Original Message----- From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of mp4-tech-request at lists.mpegif.org Sent: Tuesday, February 02, 2010 10:32 PM To: mp4-tech at lists.mpegif.org Subject: Mp4-tech Digest, Vol 79, Issue 3 Send Mp4-tech mailing list submissions to mp4-tech at 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 at lists.mpegif.org You can reach the person managing the list at mp4-tech-owner at 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. AVC Intra coded frame size query (Malatesh Karegoudar) 2. mpegts payload type -?? (Victor lyamtsev) Message: 2 Date: Tue, 2 Feb 2010 10:14:31 -0500 From: Victor lyamtsev Subject: [Mp4-tech] mpegts payload type -?? To: mp4-tech at lists.mpegif.org Message-ID: <76224b101002020714l49ffe641y27ea23c9ae2b13dc at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 seems as i have some problem with finding how to specify payload type ( codec type ) for mpegts... Can it only be mpeg2 video / mpeg2 audio, or is it possible to specify an arbitrary type? i would appreciate if someone points me to the right rfc... Thank you... -V ------------------------------ This e-mail message may contain proprietary, confidential or legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify us immediately at netadmin at patni.com and delete this mail. From Shevach.Riabtsev at zoran.com Wed Feb 3 09:05:18 2010 From: Shevach.Riabtsev at zoran.com (Shevach Riabtsev) Date: Wed, 3 Feb 2010 16:05:18 +0200 Subject: [Mp4-tech] Number of bytes in NAL Unit Message-ID: <91C4B16D6D58C541BF2F841D27F8253601A91876@zmlex.zml.zoran.com> Dear Cristina Gil If a stream obeys Annex B constraints then the size of NAL unit is determined by next start code. In other words the distance between the current start code and next one is actually NAL unit size. So, for determination of NAL unit size it is required to look ahead in the stream. I read the RFC3984 document which says the RTP header its 12bytes, but how can i know when the FU-As or NAL units are finished, in other words how many bytes of the RTP payload are padding (which makes the rtp packet header + payload (NAL + Padding) =1400). I read the ISO/IEC 14496 part 10: nal_unit( NumBytesInNALunit ) { forbidden_zero_bit //--->1bit nal_ref_idc //--->2bit nal_unit_type //--->5bit NumBytesInRBSP = 0 for( i = 1; i < NumBytesInNALunit; i++ ) { if( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) { rbsp_byte[ NumBytesInRBSP++ ] rbsp_byte[ NumBytesInRBSP++ ] i += 2 emulation_prevention_three_byte /* equal to 0x03 */ } else rbsp_byte[ NumBytesInRBSP++ ] } } How can i get NumBytesInNALunit? What does next_bits( 24 ) means? Regards Shevach Riabtsev Video compressionist -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100203/ef5cb789/attachment.html From cristina.gil at sumenor.com Wed Feb 3 09:54:35 2010 From: cristina.gil at sumenor.com (Cristina Gil) Date: Wed, 3 Feb 2010 15:54:35 +0100 Subject: [Mp4-tech] Number of bytes in NAL Unit In-Reply-To: <91C4B16D6D58C541BF2F841D27F8253601A91876@zmlex.zml.zoran.com> References: <91C4B16D6D58C541BF2F841D27F8253601A91876@zmlex.zml.zoran.com> Message-ID: <5AEA95A17E77465891272008D203939D@SUMENORSCS.LOCAL> Hello, Thanks Shevach Riabtsev for your help, if me stream obeys to Annex B, my delimiter will be: - 1byte 0x00 (leading _zero_8bits) - 1byte 0x00 (zero_byte) - 3bytes 0x01 (start_code_prefix_one_3bytes) - 1byte 0x00 (trailing_zero_8bits) But I checked it and it isn?t. I think my stream comes as ?pure? RTP?, is there another way to get the NAL size? _____ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: mi?rcoles, 03 de febrero de 2010 15:05 Para: mp4-tech at lists.mpegif.org Asunto: [Mp4-tech] Number of bytes in NAL Unit Dear Cristina Gil If a stream obeys Annex B constraints then the size of NAL unit is determined by next start code. In other words the distance between the current start code and next one is actually NAL unit size. So, for determination of NAL unit size it is required to look ahead in the stream. I read the RFC3984 document which says the RTP header its 12bytes, but how can i know when the FU-As or NAL units are finished, in other words how many bytes of the RTP payload are padding (which makes the rtp packet header + payload (NAL + Padding) =1400). I read the ISO/IEC 14496 part 10: nal_unit( NumBytesInNALunit ) { forbidden_zero_bit //--->1bit nal_ref_idc //--->2bit nal_unit_type //--->5bit NumBytesInRBSP = 0 for( i = 1; i < NumBytesInNALunit; i++ ) { if( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) { rbsp_byte[ NumBytesInRBSP++ ] rbsp_byte[ NumBytesInRBSP++ ] i += 2 emulation_prevention_three_byte /* equal to 0x03 */ } else rbsp_byte[ NumBytesInRBSP++ ] } } How can i get NumBytesInNALunit? What does next_bits( 24 ) means? Regards Shevach Riabtsev Video compressionist AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100203/08292e22/attachment-0001.html From Shevach.Riabtsev at zoran.com Wed Feb 3 10:14:36 2010 From: Shevach.Riabtsev at zoran.com (Shevach Riabtsev) Date: Wed, 3 Feb 2010 17:14:36 +0200 Subject: [Mp4-tech] Number of bytes in NAL Unit In-Reply-To: <5AEA95A17E77465891272008D203939D@SUMENORSCS.LOCAL> References: <91C4B16D6D58C541BF2F841D27F8253601A91876@zmlex.zml.zoran.com> <5AEA95A17E77465891272008D203939D@SUMENORSCS.LOCAL> Message-ID: <91C4B16D6D58C541BF2F841D27F8253601A91878@zmlex.zml.zoran.com> Cristina I define NAL unit delimiter for Annex_B compliant streams as the following regular expression - '[0]*000001' . Unfortunately the standard does not specify demarcation of NAL boundaries for streams which don't obey Annex B. Apparently RTP header does not contain NAL unit size/boundary information. If true then many trick modes (e.g. fast forward, fast resync. due to syntax errors) are unfeasible or challenging for implementations. Regards ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 4:55 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Hello, Thanks Shevach Riabtsev for your help, if me stream obeys to Annex B, my delimiter will be: - 1byte 0x00 (leading _zero_8bits) - 1byte 0x00 (zero_byte) - 3bytes 0x01 (start_code_prefix_one_3bytes) - 1byte 0x00 (trailing_zero_8bits) But I checked it and it isn't. I think my stream comes as "pure" RTP", is there another way to get the NAL size? ________________________________ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: mi?rcoles, 03 de febrero de 2010 15:05 Para: mp4-tech at lists.mpegif.org Asunto: [Mp4-tech] Number of bytes in NAL Unit Dear Cristina Gil If a stream obeys Annex B constraints then the size of NAL unit is determined by next start code. In other words the distance between the current start code and next one is actually NAL unit size. So, for determination of NAL unit size it is required to look ahead in the stream. I read the RFC3984 document which says the RTP header its 12bytes, but how can i know when the FU-As or NAL units are finished, in other words how many bytes of the RTP payload are padding (which makes the rtp packet header + payload (NAL + Padding) =1400). I read the ISO/IEC 14496 part 10: nal_unit( NumBytesInNALunit ) { forbidden_zero_bit //--->1bit nal_ref_idc //--->2bit nal_unit_type //--->5bit NumBytesInRBSP = 0 for( i = 1; i < NumBytesInNALunit; i++ ) { if( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) { rbsp_byte[ NumBytesInRBSP++ ] rbsp_byte[ NumBytesInRBSP++ ] i += 2 emulation_prevention_three_byte /* equal to 0x03 */ } else rbsp_byte[ NumBytesInRBSP++ ] } } How can i get NumBytesInNALunit? What does next_bits( 24 ) means? Regards Shevach Riabtsev Video compressionist ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100203/c1da9c78/attachment.html From cristina.gil at sumenor.com Wed Feb 3 11:04:12 2010 From: cristina.gil at sumenor.com (Cristina Gil) Date: Wed, 3 Feb 2010 17:04:12 +0100 Subject: [Mp4-tech] Number of bytes in NAL Unit In-Reply-To: <91C4B16D6D58C541BF2F841D27F8253601A91878@zmlex.zml.zoran.com> References: <91C4B16D6D58C541BF2F841D27F8253601A91876@zmlex.zml.zoran.com> <5AEA95A17E77465891272008D203939D@SUMENORSCS.LOCAL> <91C4B16D6D58C541BF2F841D27F8253601A91878@zmlex.zml.zoran.com> Message-ID: <2E8E1FFCA77B40FF9AA2CBD7D9395AF1@SUMENORSCS.LOCAL> Thanks again for your answer!!! I have now a very silly question maybe is because of all these 0s and 1s make me feel confused One RTP message could carry many NAL units, and each unit many type of images, right or wrong?? _____ De: Shevach Riabtsev [mailto:Shevach.Riabtsev at zoran.com] Enviado el: mi?rcoles, 03 de febrero de 2010 16:15 Para: Cristina Gil CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit Cristina I define NAL unit delimiter for Annex_B compliant streams as the following regular expression - ?[0]*000001? . Unfortunately the standard does not specify demarcation of NAL boundaries for streams which don?t obey Annex B. Apparently RTP header does not contain NAL unit size/boundary information. If true then many trick modes (e.g. fast forward, fast resync. due to syntax errors) are unfeasible or challenging for implementations. Regards _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 4:55 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Hello, Thanks Shevach Riabtsev for your help, if me stream obeys to Annex B, my delimiter will be: - 1byte 0x00 (leading _zero_8bits) - 1byte 0x00 (zero_byte) - 3bytes 0x01 (start_code_prefix_one_3bytes) - 1byte 0x00 (trailing_zero_8bits) But I checked it and it isn?t. I think my stream comes as ?pure? RTP?, is there another way to get the NAL size? _____ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: mi?rcoles, 03 de febrero de 2010 15:05 Para: mp4-tech at lists.mpegif.org Asunto: [Mp4-tech] Number of bytes in NAL Unit Dear Cristina Gil If a stream obeys Annex B constraints then the size of NAL unit is determined by next start code. In other words the distance between the current start code and next one is actually NAL unit size. So, for determination of NAL unit size it is required to look ahead in the stream. I read the RFC3984 document which says the RTP header its 12bytes, but how can i know when the FU-As or NAL units are finished, in other words how many bytes of the RTP payload are padding (which makes the rtp packet header + payload (NAL + Padding) =1400). I read the ISO/IEC 14496 part 10: nal_unit( NumBytesInNALunit ) { forbidden_zero_bit //--->1bit nal_ref_idc //--->2bit nal_unit_type //--->5bit NumBytesInRBSP = 0 for( i = 1; i < NumBytesInNALunit; i++ ) { if( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) { rbsp_byte[ NumBytesInRBSP++ ] rbsp_byte[ NumBytesInRBSP++ ] i += 2 emulation_prevention_three_byte /* equal to 0x03 */ } else rbsp_byte[ NumBytesInRBSP++ ] } } How can i get NumBytesInNALunit? What does next_bits( 24 ) means? Regards Shevach Riabtsev Video compressionist _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100203/8ae541ea/attachment-0001.html From mzanaty at cisco.com Wed Feb 3 11:04:05 2010 From: mzanaty at cisco.com (Mo Zanaty (mzanaty)) Date: Wed, 3 Feb 2010 10:04:05 -0600 Subject: [Mp4-tech] Number of bytes in NAL Unit In-Reply-To: <91C4B16D6D58C541BF2F841D27F8253601A91878@zmlex.zml.zoran.com> Message-ID: H.264 RTP streams do not use H.264 Annex B start codes (000001) to delimit NAL units. The RTP packet itself delimits each NAL unit. There are also special NAL units (type 24-29) defined in RFC3984 which extend the H.264 standard NAL units (type 0-23). The RTP header does not include payload size because it assumes the application can use the length in the UDP header (or other transport layer) to determine the payload size. The RTP header does include padding information, see the excerpt below from RFC3550. 5. RTP Data Transfer Protocol 5.1 RTP Fixed Header Fields The RTP header has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... padding (P): 1 bit If the padding bit is set, the packet contains one or more additional padding octets at the end which are not part of the payload. The last octet of the padding contains a count of how many padding octets should be ignored, including itself. Padding may be needed by some encryption algorithms with fixed block sizes or for carrying several RTP packets in a lower-layer protocol data unit. Regards, Mo Zanaty ________________________________ From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Shevach Riabtsev Sent: Wednesday, February 03, 2010 10:15 AM To: Cristina Gil Cc: mp4-tech at lists.mpegif.org Subject: Re: [Mp4-tech] Number of bytes in NAL Unit Cristina I define NAL unit delimiter for Annex_B compliant streams as the following regular expression - '[0]*000001' . Unfortunately the standard does not specify demarcation of NAL boundaries for streams which don't obey Annex B. Apparently RTP header does not contain NAL unit size/boundary information. If true then many trick modes (e.g. fast forward, fast resync. due to syntax errors) are unfeasible or challenging for implementations. Regards ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 4:55 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Hello, Thanks Shevach Riabtsev for your help, if me stream obeys to Annex B, my delimiter will be: - 1byte 0x00 (leading _zero_8bits) - 1byte 0x00 (zero_byte) - 3bytes 0x01 (start_code_prefix_one_3bytes) - 1byte 0x00 (trailing_zero_8bits) But I checked it and it isn't. I think my stream comes as "pure" RTP", is there another way to get the NAL size? ________________________________ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: mi?rcoles, 03 de febrero de 2010 15:05 Para: mp4-tech at lists.mpegif.org Asunto: [Mp4-tech] Number of bytes in NAL Unit Dear Cristina Gil If a stream obeys Annex B constraints then the size of NAL unit is determined by next start code. In other words the distance between the current start code and next one is actually NAL unit size. So, for determination of NAL unit size it is required to look ahead in the stream. I read the RFC3984 document which says the RTP header its 12bytes, but how can i know when the FU-As or NAL units are finished, in other words how many bytes of the RTP payload are padding (which makes the rtp packet header + payload (NAL + Padding) =1400). I read the ISO/IEC 14496 part 10: nal_unit( NumBytesInNALunit ) { forbidden_zero_bit //--->1bit nal_ref_idc //--->2bit nal_unit_type //--->5bit NumBytesInRBSP = 0 for( i = 1; i < NumBytesInNALunit; i++ ) { if( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) { rbsp_byte[ NumBytesInRBSP++ ] rbsp_byte[ NumBytesInRBSP++ ] i += 2 emulation_prevention_three_byte /* equal to 0x03 */ } else rbsp_byte[ NumBytesInRBSP++ ] } } How can i get NumBytesInNALunit? What does next_bits( 24 ) means? Regards Shevach Riabtsev Video compressionist ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100203/965ac0bb/attachment-0001.html From Shevach.Riabtsev at zoran.com Wed Feb 3 11:06:29 2010 From: Shevach.Riabtsev at zoran.com (Shevach Riabtsev) Date: Wed, 3 Feb 2010 18:06:29 +0200 Subject: [Mp4-tech] Number of bytes in NAL Unit In-Reply-To: <2E8E1FFCA77B40FF9AA2CBD7D9395AF1@SUMENORSCS.LOCAL> References: <91C4B16D6D58C541BF2F841D27F8253601A91876@zmlex.zml.zoran.com> <5AEA95A17E77465891272008D203939D@SUMENORSCS.LOCAL> <91C4B16D6D58C541BF2F841D27F8253601A91878@zmlex.zml.zoran.com> <2E8E1FFCA77B40FF9AA2CBD7D9395AF1@SUMENORSCS.LOCAL> Message-ID: <91C4B16D6D58C541BF2F841D27F8253601A91879@zmlex.zml.zoran.com> Unfortunately I am not so familiar with RTP in order to provide reliable answer. ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 6:04 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks again for your answer!!! I have now a very silly question maybe is because of all these 0s and 1s make me feel confused... One RTP message could carry many NAL units, and each unit many type of images, right or wrong?? ________________________________ De: Shevach Riabtsev [mailto:Shevach.Riabtsev at zoran.com] Enviado el: mi?rcoles, 03 de febrero de 2010 16:15 Para: Cristina Gil CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit Cristina I define NAL unit delimiter for Annex_B compliant streams as the following regular expression - '[0]*000001' . Unfortunately the standard does not specify demarcation of NAL boundaries for streams which don't obey Annex B. Apparently RTP header does not contain NAL unit size/boundary information. If true then many trick modes (e.g. fast forward, fast resync. due to syntax errors) are unfeasible or challenging for implementations. Regards ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 4:55 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Hello, Thanks Shevach Riabtsev for your help, if me stream obeys to Annex B, my delimiter will be: - 1byte 0x00 (leading _zero_8bits) - 1byte 0x00 (zero_byte) - 3bytes 0x01 (start_code_prefix_one_3bytes) - 1byte 0x00 (trailing_zero_8bits) But I checked it and it isn't. I think my stream comes as "pure" RTP", is there another way to get the NAL size? ________________________________ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: mi?rcoles, 03 de febrero de 2010 15:05 Para: mp4-tech at lists.mpegif.org Asunto: [Mp4-tech] Number of bytes in NAL Unit Dear Cristina Gil If a stream obeys Annex B constraints then the size of NAL unit is determined by next start code. In other words the distance between the current start code and next one is actually NAL unit size. So, for determination of NAL unit size it is required to look ahead in the stream. I read the RFC3984 document which says the RTP header its 12bytes, but how can i know when the FU-As or NAL units are finished, in other words how many bytes of the RTP payload are padding (which makes the rtp packet header + payload (NAL + Padding) =1400). I read the ISO/IEC 14496 part 10: nal_unit( NumBytesInNALunit ) { forbidden_zero_bit //--->1bit nal_ref_idc //--->2bit nal_unit_type //--->5bit NumBytesInRBSP = 0 for( i = 1; i < NumBytesInNALunit; i++ ) { if( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) { rbsp_byte[ NumBytesInRBSP++ ] rbsp_byte[ NumBytesInRBSP++ ] i += 2 emulation_prevention_three_byte /* equal to 0x03 */ } else rbsp_byte[ NumBytesInRBSP++ ] } } How can i get NumBytesInNALunit? What does next_bits( 24 ) means? Regards Shevach Riabtsev Video compressionist ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100203/2c8fd594/attachment-0001.html From garysull at microsoft.com Wed Feb 3 12:02:57 2010 From: garysull at microsoft.com (Gary Sullivan) Date: Wed, 3 Feb 2010 17:02:57 +0000 Subject: [Mp4-tech] Number of bytes in NAL Unit In-Reply-To: <91C4B16D6D58C541BF2F841D27F8253601A91878@zmlex.zml.zoran.com> References: <91C4B16D6D58C541BF2F841D27F8253601A91876@zmlex.zml.zoran.com> <5AEA95A17E77465891272008D203939D@SUMENORSCS.LOCAL> <91C4B16D6D58C541BF2F841D27F8253601A91878@zmlex.zml.zoran.com> Message-ID: Ms. Gill et al, I am confident that RFC 3984 provides the information necessary to determine the NAL unit size, although I'm not very familiar with that spec. I think there may not be such a thing as "padding" when RFC 3984 is used, although I'm not sure about that. Forget about Annex B - it is not relevant when RFC 3984 is used. There is no such thing as "start codes" when RFC 2984 is used. The idea of "looking ahead" within the data to find the boundary of the next NAL unit does not apply when RFC 3984 is used. The idea that the packets have a fixed size equal to 1400 bytes as you reported does not sound correct to me. Possibly, on some network from some particular encoder, many of the packets will have that size. But I doubt that all of them will. (I also suggest not to necessarily assume that the behavior that you are seeing from some particular encoder is correct.) My suggestion would be to carefully read RFC 3984 (and the related RFC's that it depends on, such as the RFC's that define RTP). Best Regards, Gary Sullivan From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Shevach Riabtsev Sent: Wednesday, February 03, 2010 7:15 AM To: Cristina Gil Cc: mp4-tech at lists.mpegif.org Subject: Re: [Mp4-tech] Number of bytes in NAL Unit Cristina I define NAL unit delimiter for Annex_B compliant streams as the following regular expression - '[0]*000001' . Unfortunately the standard does not specify demarcation of NAL boundaries for streams which don't obey Annex B. Apparently RTP header does not contain NAL unit size/boundary information. If true then many trick modes (e.g. fast forward, fast resync. due to syntax errors) are unfeasible or challenging for implementations. Regards ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 4:55 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Hello, Thanks Shevach Riabtsev for your help, if me stream obeys to Annex B, my delimiter will be: - 1byte 0x00 (leading _zero_8bits) - 1byte 0x00 (zero_byte) - 3bytes 0x01 (start_code_prefix_one_3bytes) - 1byte 0x00 (trailing_zero_8bits) But I checked it and it isn't. I think my stream comes as "pure" RTP", is there another way to get the NAL size? ________________________________ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: mi?rcoles, 03 de febrero de 2010 15:05 Para: mp4-tech at lists.mpegif.org Asunto: [Mp4-tech] Number of bytes in NAL Unit Dear Cristina Gil If a stream obeys Annex B constraints then the size of NAL unit is determined by next start code. In other words the distance between the current start code and next one is actually NAL unit size. So, for determination of NAL unit size it is required to look ahead in the stream. Regards Shevach Riabtsev Video compressionist From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Cristina Gil Sent: Wednesday, February 03, 2010 3:43 AM To: mp4-tech at lists.mpegif.org Subject: [Mp4-tech] Number of bytes in NAL Unit Hello, I read the RFC3984 document which says the RTP header its 12bytes, but how can i know when the FU-As or NAL units are finished, in other words how many bytes of the RTP payload are padding (which makes the rtp packet header + payload (NAL + Padding) =1400). I read the ISO/IEC 14496 part 10: nal_unit( NumBytesInNALunit ) { forbidden_zero_bit //--->1bit nal_ref_idc //--->2bit nal_unit_type //--->5bit NumBytesInRBSP = 0 for( i = 1; i < NumBytesInNALunit; i++ ) { if( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) { rbsp_byte[ NumBytesInRBSP++ ] rbsp_byte[ NumBytesInRBSP++ ] i += 2 emulation_prevention_three_byte /* equal to 0x03 */ } else rbsp_byte[ NumBytesInRBSP++ ] } } How can i get NumBytesInNALunit? What does next_bits( 24 ) means? Thanks!!! ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100203/9db68161/attachment.html From mzanaty at cisco.com Wed Feb 3 12:10:51 2010 From: mzanaty at cisco.com (Mo Zanaty (mzanaty)) Date: Wed, 3 Feb 2010 11:10:51 -0600 Subject: [Mp4-tech] Number of bytes in NAL Unit In-Reply-To: <91C4B16D6D58C541BF2F841D27F8253601A91879@zmlex.zml.zoran.com> Message-ID: This depends on the "packetization-mode" of the RTP stream, which is defined in RFC3984, and indicated via SDP, not within the RTP stream itself. One RTP packet can only contain a single NAL unit if the packetization-mode is 0 or unspecified. Other packetization-mode values allow fragmentation of a single NAL unit over multiple RTP packets, and aggregation of multiple NAL units into a single RTP packet. Regards, Mo Zanaty ________________________________ From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Shevach Riabtsev Sent: Wednesday, February 03, 2010 11:06 AM To: Cristina Gil Cc: mp4-tech at lists.mpegif.org Subject: Re: [Mp4-tech] Number of bytes in NAL Unit Unfortunately I am not so familiar with RTP in order to provide reliable answer. ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 6:04 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks again for your answer!!! I have now a very silly question maybe is because of all these 0s and 1s make me feel confused... One RTP message could carry many NAL units, and each unit many type of images, right or wrong?? ________________________________ De: Shevach Riabtsev [mailto:Shevach.Riabtsev at zoran.com] Enviado el: mi?rcoles, 03 de febrero de 2010 16:15 Para: Cristina Gil CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit Cristina I define NAL unit delimiter for Annex_B compliant streams as the following regular expression - '[0]*000001' . Unfortunately the standard does not specify demarcation of NAL boundaries for streams which don't obey Annex B. Apparently RTP header does not contain NAL unit size/boundary information. If true then many trick modes (e.g. fast forward, fast resync. due to syntax errors) are unfeasible or challenging for implementations. Regards ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 4:55 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Hello, Thanks Shevach Riabtsev for your help, if me stream obeys to Annex B, my delimiter will be: - 1byte 0x00 (leading _zero_8bits) - 1byte 0x00 (zero_byte) - 3bytes 0x01 (start_code_prefix_one_3bytes) - 1byte 0x00 (trailing_zero_8bits) But I checked it and it isn't. I think my stream comes as "pure" RTP", is there another way to get the NAL size? ________________________________ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: mi?rcoles, 03 de febrero de 2010 15:05 Para: mp4-tech at lists.mpegif.org Asunto: [Mp4-tech] Number of bytes in NAL Unit Dear Cristina Gil If a stream obeys Annex B constraints then the size of NAL unit is determined by next start code. In other words the distance between the current start code and next one is actually NAL unit size. So, for determination of NAL unit size it is required to look ahead in the stream. I read the RFC3984 document which says the RTP header its 12bytes, but how can i know when the FU-As or NAL units are finished, in other words how many bytes of the RTP payload are padding (which makes the rtp packet header + payload (NAL + Padding) =1400). I read the ISO/IEC 14496 part 10: nal_unit( NumBytesInNALunit ) { forbidden_zero_bit //--->1bit nal_ref_idc //--->2bit nal_unit_type //--->5bit NumBytesInRBSP = 0 for( i = 1; i < NumBytesInNALunit; i++ ) { if( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) { rbsp_byte[ NumBytesInRBSP++ ] rbsp_byte[ NumBytesInRBSP++ ] i += 2 emulation_prevention_three_byte /* equal to 0x03 */ } else rbsp_byte[ NumBytesInRBSP++ ] } } How can i get NumBytesInNALunit? What does next_bits( 24 ) means? Regards Shevach Riabtsev Video compressionist ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100203/6d539f96/attachment-0001.html From herbert.thoma at iis.fraunhofer.de Wed Feb 3 12:21:36 2010 From: herbert.thoma at iis.fraunhofer.de (Herbert Thoma) Date: Wed, 03 Feb 2010 18:21:36 +0100 Subject: [Mp4-tech] Number of bytes in NAL Unit In-Reply-To: <2E8E1FFCA77B40FF9AA2CBD7D9395AF1@SUMENORSCS.LOCAL> References: <91C4B16D6D58C541BF2F841D27F8253601A91876@zmlex.zml.zoran.com> <5AEA95A17E77465891272008D203939D@SUMENORSCS.LOCAL> <91C4B16D6D58C541BF2F841D27F8253601A91878@zmlex.zml.zoran.com> <2E8E1FFCA77B40FF9AA2CBD7D9395AF1@SUMENORSCS.LOCAL> Message-ID: <4B69B0A0.9010201@iis.fraunhofer.de> Cristina Gil schrieb: > > One RTP message could carry many NAL units, and each unit many type of > images, right or wrong?? What do you mean with RTP message? A single RTP packet or an RTP stream? An RTP packet can contain a single NAL unit or multiple NAL units, this is called aggregation. Or a single NAL unit can be fragmented to multiple RTP packets. See RFC3984. A single NAL unit can represent at most one coded picture. Usually a coded picture is divided into more than one NAL unit. HErbert. > > > ------------------------------------------------------------------------ > > *De:* Shevach Riabtsev [mailto:Shevach.Riabtsev at zoran.com] > *Enviado el:* mi?rcoles, 03 de febrero de 2010 16:15 > *Para:* Cristina Gil > *CC:* mp4-tech at lists.mpegif.org > *Asunto:* RE: [Mp4-tech] Number of bytes in NAL Unit > > > > Cristina > > > > I define NAL unit delimiter for Annex_B compliant streams as the > following regular expression - ?[0]*000001? . > > > > Unfortunately the standard does not specify demarcation of NAL > boundaries for streams which don?t obey Annex B. > > > > Apparently RTP header does not contain NAL unit size/boundary > information. If true then many trick modes (e.g. fast forward, fast > resync. due to syntax errors) are unfeasible or challenging for > implementations. > > > > Regards > > > > > > > > ------------------------------------------------------------------------ > > *From:* Cristina Gil [mailto:cristina.gil at sumenor.com] > *Sent:* Wednesday, February 03, 2010 4:55 PM > *To:* Shevach Riabtsev > *Cc:* mp4-tech at lists.mpegif.org > *Subject:* RE: [Mp4-tech] Number of bytes in NAL Unit > > > > Hello, > > Thanks Shevach Riabtsev for your help, if me stream obeys to Annex B, my > delimiter will be: > > - 1byte 0x00 (leading _zero_8bits) > > - 1byte 0x00 (zero_byte) > > - 3bytes 0x01 (start_code_prefix_one_3bytes) > > - 1byte 0x00 (trailing_zero_8bits) > > But I checked it and it isn?t. I think my stream comes as ?pure? RTP?, > is there another way to get the NAL size? > > ------------------------------------------------------------------------ > > *De:* mp4-tech-bounces at lists.mpegif.org > [mailto:mp4-tech-bounces at lists.mpegif.org] *En nombre de *Shevach Riabtsev > *Enviado el:* mi?rcoles, 03 de febrero de 2010 15:05 > *Para:* mp4-tech at lists.mpegif.org > *Asunto:* [Mp4-tech] Number of bytes in NAL Unit > > > > Dear Cristina Gil > > If a stream obeys Annex B constraints then the size of NAL unit is > determined by next start code. > > In other words the distance between the current start code and next one > is actually NAL unit size. So, for determination of NAL unit size it is > required to look ahead in the stream. > > I read the RFC3984 document which says the RTP header its 12bytes, but how > > can i know when the FU-As or NAL units are finished, in other words how many > > bytes of the RTP payload are padding (which makes the rtp packet header + > > payload (NAL + Padding) =1400). > > I read the ISO/IEC 14496 part 10: > > nal_unit( NumBytesInNALunit ) { > > forbidden_zero_bit //--->1bit > > nal_ref_idc //--->2bit > > nal_unit_type //--->5bit > > NumBytesInRBSP = 0 > > for( i = 1; i < NumBytesInNALunit; i++ ) { > > if( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) { > > rbsp_byte[ NumBytesInRBSP++ ] > > rbsp_byte[ NumBytesInRBSP++ ] > > i += 2 > > emulation_prevention_three_byte /* equal to 0x03 */ > > } else > > rbsp_byte[ NumBytesInRBSP++ ] > > } > > } > > How can i get NumBytesInNALunit? > > What does next_bits( 24 ) means? > > Regards > > Shevach Riabtsev > > Video compressionist > > > > ------------------------------------------------------------------------ > > AVISO LEGAL > La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. > > > > ------------------------------------------------------------------------ > AVISO LEGAL > La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. > > > ------------------------------------------------------------------------ > > _______________________________________________ > NOTE: Please use clear subject lines for your posts. Include [audio, [video], [systems], [general] or another appropriate identifier to indicate the type of question you have. > > Note: Conduct on the mailing list is subject to the Antitrust guidelines found at http://www.mpegif.org/public/documents/vault/mp-out-30042-Antitrust.php -- Herbert Thoma Dipl.-Ing., MBA Head of Video Group Multimedia Realtime Systems Department Fraunhofer IIS Am Wolfsmantel 33, 91058 Erlangen, Germany Phone: +49-9131-776-6130 Fax: +49-9131-776-6099 email: tma at iis.fhg.de www: http://www.iis.fhg.de/ From cristina.gil at sumenor.com Wed Feb 3 12:33:12 2010 From: cristina.gil at sumenor.com (Cristina Gil) Date: Wed, 3 Feb 2010 18:33:12 +0100 Subject: [Mp4-tech] Number of bytes in NAL Unit In-Reply-To: References: <91C4B16D6D58C541BF2F841D27F8253601A91879@zmlex.zml.zoran.com> Message-ID: Thanks for all your answers I appreciated them very much. Sorry Herbert, what I meant to say was RTP packet. I have packetization-mode=1 that means i can have IDR, non-IDR and FU-A (and STAP-A which I don?t receive from the camera), so I will only have I and P images, do I need to decode the nal unit to know which kind of frame(s) I have or is there another way to know it? _____ De: Mo Zanaty (mzanaty) [mailto:mzanaty at cisco.com] Enviado el: mi?rcoles, 03 de febrero de 2010 18:11 Para: Shevach Riabtsev; Cristina Gil CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit This depends on the ?packetization-mode? of the RTP stream, which is defined in RFC3984, and indicated via SDP, not within the RTP stream itself. One RTP packet can only contain a single NAL unit if the packetization-mode is 0 or unspecified. Other packetization-mode values allow fragmentation of a single NAL unit over multiple RTP packets, and aggregation of multiple NAL units into a single RTP packet. Regards, Mo Zanaty _____ From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Shevach Riabtsev Sent: Wednesday, February 03, 2010 11:06 AM To: Cristina Gil Cc: mp4-tech at lists.mpegif.org Subject: Re: [Mp4-tech] Number of bytes in NAL Unit Unfortunately I am not so familiar with RTP in order to provide reliable answer. _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 6:04 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks again for your answer!!! I have now a very silly question maybe is because of all these 0s and 1s make me feel confused One RTP message could carry many NAL units, and each unit many type of images, right or wrong?? _____ De: Shevach Riabtsev [mailto:Shevach.Riabtsev at zoran.com] Enviado el: mi?rcoles, 03 de febrero de 2010 16:15 Para: Cristina Gil CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit Cristina I define NAL unit delimiter for Annex_B compliant streams as the following regular expression - ?[0]*000001? . Unfortunately the standard does not specify demarcation of NAL boundaries for streams which don?t obey Annex B. Apparently RTP header does not contain NAL unit size/boundary information. If true then many trick modes (e.g. fast forward, fast resync. due to syntax errors) are unfeasible or challenging for implementations. Regards _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 4:55 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Hello, Thanks Shevach Riabtsev for your help, if me stream obeys to Annex B, my delimiter will be: - 1byte 0x00 (leading _zero_8bits) - 1byte 0x00 (zero_byte) - 3bytes 0x01 (start_code_prefix_one_3bytes) - 1byte 0x00 (trailing_zero_8bits) But I checked it and it isn?t. I think my stream comes as ?pure? RTP?, is there another way to get the NAL size? _____ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: mi?rcoles, 03 de febrero de 2010 15:05 Para: mp4-tech at lists.mpegif.org Asunto: [Mp4-tech] Number of bytes in NAL Unit Dear Cristina Gil If a stream obeys Annex B constraints then the size of NAL unit is determined by next start code. In other words the distance between the current start code and next one is actually NAL unit size. So, for determination of NAL unit size it is required to look ahead in the stream. I read the RFC3984 document which says the RTP header its 12bytes, but how can i know when the FU-As or NAL units are finished, in other words how many bytes of the RTP payload are padding (which makes the rtp packet header + payload (NAL + Padding) =1400). I read the ISO/IEC 14496 part 10: nal_unit( NumBytesInNALunit ) { forbidden_zero_bit //--->1bit nal_ref_idc //--->2bit nal_unit_type //--->5bit NumBytesInRBSP = 0 for( i = 1; i < NumBytesInNALunit; i++ ) { if( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) { rbsp_byte[ NumBytesInRBSP++ ] rbsp_byte[ NumBytesInRBSP++ ] i += 2 emulation_prevention_three_byte /* equal to 0x03 */ } else rbsp_byte[ NumBytesInRBSP++ ] } } How can i get NumBytesInNALunit? What does next_bits( 24 ) means? Regards Shevach Riabtsev Video compressionist _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100203/36bc5ea5/attachment-0001.html From singer at apple.com Wed Feb 3 12:57:40 2010 From: singer at apple.com (David Singer) Date: Wed, 3 Feb 2010 09:57:40 -0800 Subject: [Mp4-tech] Number of bytes in NAL Unit In-Reply-To: <91C4B16D6D58C541BF2F841D27F8253601A91876@zmlex.zml.zoran.com> References: <91C4B16D6D58C541BF2F841D27F8253601A91876@zmlex.zml.zoran.com> Message-ID: RFC 3984 doesn't use start-codes; all NAL units have a length field either explicit (all the aggregation units) or implied (the single NAL unit packet). "Annex B of H.264 defines an encapsulation process to transmit such NAL units over byte-stream oriented networks. In the scope of this memo, Annex B is not relevant." "3. Scope This payload specification can only be used to carry the "naked" H.264 NAL unit stream over RTP, and not the bitstream format discussed in Annex B of H.264." On Feb 3, 2010, at 6:05 , Shevach Riabtsev wrote: > Dear Cristina Gil > > > If a stream obeys Annex B constraints then the size of NAL unit is determined by next start code. > > In other words the distance between the current start code and next one is actually NAL unit size. So, for determination of NAL unit size it is required to look ahead in the stream. > > > I read the RFC3984 document which says the RTP header its 12bytes, but how > > can i know when the FU-As or NAL units are finished, in other words how many > > bytes of the RTP payload are padding (which makes the rtp packet header + > > payload (NAL + Padding) =1400). > > I read the ISO/IEC 14496 part 10: > > nal_unit( NumBytesInNALunit ) { > > forbidden_zero_bit //--->1bit > > nal_ref_idc //--->2bit > > nal_unit_type //--->5bit > > NumBytesInRBSP = 0 > > for( i = 1; i < NumBytesInNALunit; i++ ) { > > if( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) { > > rbsp_byte[ NumBytesInRBSP++ ] > > rbsp_byte[ NumBytesInRBSP++ ] > > i += 2 > > emulation_prevention_three_byte /* equal to 0x03 */ > > } else > > rbsp_byte[ NumBytesInRBSP++ ] > > } > > } > > How can i get NumBytesInNALunit? > > What does next_bits( 24 ) means? > > > Regards > > Shevach Riabtsev > > Video compressionist > > > _______________________________________________ > NOTE: Please use clear subject lines for your posts. Include [audio, [video], [systems], [general] or another appropriate 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 Multimedia and Software Standards, Apple Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100203/a38a217c/attachment.html From mzanaty at cisco.com Wed Feb 3 13:12:05 2010 From: mzanaty at cisco.com (Mo Zanaty (mzanaty)) Date: Wed, 3 Feb 2010 12:12:05 -0600 Subject: [Mp4-tech] Number of bytes in NAL Unit In-Reply-To: Message-ID: IDR frames contain all I slices, so only decoding the NAL header is sufficient to know this. Non-IDR frames can contain I, P or B slices which can be determined by decoding the slice header. FU-A packets can contain anything, so decoding the byte after the FU-A NAL unit type (28) is required to get the true NAL unit type (0-23), which can then be decoded as IDR or non-IDR slice. Regards, Mo Zanaty ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 12:33 PM To: Mo Zanaty (mzanaty); 'Shevach Riabtsev'; 'Herbert Thoma' Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks for all your answers I appreciated them very much. Sorry Herbert, what I meant to say was RTP packet. I have packetization-mode=1 that means i can have IDR, non-IDR and FU-A (and STAP-A which I don't receive from the camera), so I will only have I and P images, do I need to decode the nal unit to know which kind of frame(s) I have or is there another way to know it? ________________________________ De: Mo Zanaty (mzanaty) [mailto:mzanaty at cisco.com] Enviado el: mi?rcoles, 03 de febrero de 2010 18:11 Para: Shevach Riabtsev; Cristina Gil CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit This depends on the "packetization-mode" of the RTP stream, which is defined in RFC3984, and indicated via SDP, not within the RTP stream itself. One RTP packet can only contain a single NAL unit if the packetization-mode is 0 or unspecified. Other packetization-mode values allow fragmentation of a single NAL unit over multiple RTP packets, and aggregation of multiple NAL units into a single RTP packet. Regards, Mo Zanaty ________________________________ From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Shevach Riabtsev Sent: Wednesday, February 03, 2010 11:06 AM To: Cristina Gil Cc: mp4-tech at lists.mpegif.org Subject: Re: [Mp4-tech] Number of bytes in NAL Unit Unfortunately I am not so familiar with RTP in order to provide reliable answer. ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 6:04 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks again for your answer!!! I have now a very silly question maybe is because of all these 0s and 1s make me feel confused... One RTP message could carry many NAL units, and each unit many type of images, right or wrong?? ________________________________ De: Shevach Riabtsev [mailto:Shevach.Riabtsev at zoran.com] Enviado el: mi?rcoles, 03 de febrero de 2010 16:15 Para: Cristina Gil CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit Cristina I define NAL unit delimiter for Annex_B compliant streams as the following regular expression - '[0]*000001' . Unfortunately the standard does not specify demarcation of NAL boundaries for streams which don't obey Annex B. Apparently RTP header does not contain NAL unit size/boundary information. If true then many trick modes (e.g. fast forward, fast resync. due to syntax errors) are unfeasible or challenging for implementations. Regards ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 4:55 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Hello, Thanks Shevach Riabtsev for your help, if me stream obeys to Annex B, my delimiter will be: - 1byte 0x00 (leading _zero_8bits) - 1byte 0x00 (zero_byte) - 3bytes 0x01 (start_code_prefix_one_3bytes) - 1byte 0x00 (trailing_zero_8bits) But I checked it and it isn't. I think my stream comes as "pure" RTP", is there another way to get the NAL size? ________________________________ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: mi?rcoles, 03 de febrero de 2010 15:05 Para: mp4-tech at lists.mpegif.org Asunto: [Mp4-tech] Number of bytes in NAL Unit Dear Cristina Gil If a stream obeys Annex B constraints then the size of NAL unit is determined by next start code. In other words the distance between the current start code and next one is actually NAL unit size. So, for determination of NAL unit size it is required to look ahead in the stream. I read the RFC3984 document which says the RTP header its 12bytes, but how can i know when the FU-As or NAL units are finished, in other words how many bytes of the RTP payload are padding (which makes the rtp packet header + payload (NAL + Padding) =1400). I read the ISO/IEC 14496 part 10: nal_unit( NumBytesInNALunit ) { forbidden_zero_bit //--->1bit nal_ref_idc //--->2bit nal_unit_type //--->5bit NumBytesInRBSP = 0 for( i = 1; i < NumBytesInNALunit; i++ ) { if( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) { rbsp_byte[ NumBytesInRBSP++ ] rbsp_byte[ NumBytesInRBSP++ ] i += 2 emulation_prevention_three_byte /* equal to 0x03 */ } else rbsp_byte[ NumBytesInRBSP++ ] } } How can i get NumBytesInNALunit? What does next_bits( 24 ) means? Regards Shevach Riabtsev Video compressionist ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100203/2588c9c8/attachment-0001.html From cristina.gil at sumenor.com Wed Feb 3 13:26:08 2010 From: cristina.gil at sumenor.com (Cristina Gil) Date: Wed, 3 Feb 2010 19:26:08 +0100 Subject: [Mp4-tech] Number of bytes in NAL Unit In-Reply-To: References: Message-ID: <6E262D9404564240A42B726D52D20D29@SUMENORSCS.LOCAL> Thanks Mo!! What do you mean with ?slice header?? how can I get it.. do I need a decoder (like ipp or DS filter ) or can I do it reading ?x? bytes of the NAL? I read in the RFC3984, i have concatenate FU-As so i can have a NAL, that means split the FU-A indicator and FU-A header and then concatenate? _____ De: Mo Zanaty (mzanaty) [mailto:mzanaty at cisco.com] Enviado el: mi?rcoles, 03 de febrero de 2010 19:12 Para: Cristina Gil; Shevach Riabtsev; Herbert Thoma CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit IDR frames contain all I slices, so only decoding the NAL header is sufficient to know this. Non-IDR frames can contain I, P or B slices which can be determined by decoding the slice header. FU-A packets can contain anything, so decoding the byte after the FU-A NAL unit type (28) is required to get the true NAL unit type (0-23), which can then be decoded as IDR or non-IDR slice. Regards, Mo Zanaty _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 12:33 PM To: Mo Zanaty (mzanaty); 'Shevach Riabtsev'; 'Herbert Thoma' Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks for all your answers I appreciated them very much. Sorry Herbert, what I meant to say was RTP packet. I have packetization-mode=1 that means i can have IDR, non-IDR and FU-A (and STAP-A which I don?t receive from the camera), so I will only have I and P images, do I need to decode the nal unit to know which kind of frame(s) I have or is there another way to know it? _____ De: Mo Zanaty (mzanaty) [mailto:mzanaty at cisco.com] Enviado el: mi?rcoles, 03 de febrero de 2010 18:11 Para: Shevach Riabtsev; Cristina Gil CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit This depends on the ?packetization-mode? of the RTP stream, which is defined in RFC3984, and indicated via SDP, not within the RTP stream itself. One RTP packet can only contain a single NAL unit if the packetization-mode is 0 or unspecified. Other packetization-mode values allow fragmentation of a single NAL unit over multiple RTP packets, and aggregation of multiple NAL units into a single RTP packet. Regards, Mo Zanaty _____ From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Shevach Riabtsev Sent: Wednesday, February 03, 2010 11:06 AM To: Cristina Gil Cc: mp4-tech at lists.mpegif.org Subject: Re: [Mp4-tech] Number of bytes in NAL Unit Unfortunately I am not so familiar with RTP in order to provide reliable answer. _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 6:04 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks again for your answer!!! I have now a very silly question maybe is because of all these 0s and 1s make me feel confused One RTP message could carry many NAL units, and each unit many type of images, right or wrong?? _____ De: Shevach Riabtsev [mailto:Shevach.Riabtsev at zoran.com] Enviado el: mi?rcoles, 03 de febrero de 2010 16:15 Para: Cristina Gil CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit Cristina I define NAL unit delimiter for Annex_B compliant streams as the following regular expression - ?[0]*000001? . Unfortunately the standard does not specify demarcation of NAL boundaries for streams which don?t obey Annex B. Apparently RTP header does not contain NAL unit size/boundary information. If true then many trick modes (e.g. fast forward, fast resync. due to syntax errors) are unfeasible or challenging for implementations. Regards _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 4:55 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Hello, Thanks Shevach Riabtsev for your help, if me stream obeys to Annex B, my delimiter will be: - 1byte 0x00 (leading _zero_8bits) - 1byte 0x00 (zero_byte) - 3bytes 0x01 (start_code_prefix_one_3bytes) - 1byte 0x00 (trailing_zero_8bits) But I checked it and it isn?t. I think my stream comes as ?pure? RTP?, is there another way to get the NAL size? _____ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: mi?rcoles, 03 de febrero de 2010 15:05 Para: mp4-tech at lists.mpegif.org Asunto: [Mp4-tech] Number of bytes in NAL Unit Dear Cristina Gil If a stream obeys Annex B constraints then the size of NAL unit is determined by next start code. In other words the distance between the current start code and next one is actually NAL unit size. So, for determination of NAL unit size it is required to look ahead in the stream. I read the RFC3984 document which says the RTP header its 12bytes, but how can i know when the FU-As or NAL units are finished, in other words how many bytes of the RTP payload are padding (which makes the rtp packet header + payload (NAL + Padding) =1400). I read the ISO/IEC 14496 part 10: nal_unit( NumBytesInNALunit ) { forbidden_zero_bit //--->1bit nal_ref_idc //--->2bit nal_unit_type //--->5bit NumBytesInRBSP = 0 for( i = 1; i < NumBytesInNALunit; i++ ) { if( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) { rbsp_byte[ NumBytesInRBSP++ ] rbsp_byte[ NumBytesInRBSP++ ] i += 2 emulation_prevention_three_byte /* equal to 0x03 */ } else rbsp_byte[ NumBytesInRBSP++ ] } } How can i get NumBytesInNALunit? What does next_bits( 24 ) means? Regards Shevach Riabtsev Video compressionist _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100203/9433bfee/attachment-0001.html From mzanaty at cisco.com Wed Feb 3 13:57:54 2010 From: mzanaty at cisco.com (Mo Zanaty (mzanaty)) Date: Wed, 3 Feb 2010 12:57:54 -0600 Subject: [Mp4-tech] Number of bytes in NAL Unit In-Reply-To: <6E262D9404564240A42B726D52D20D29@SUMENORSCS.LOCAL> Message-ID: The slice header is immediately after the NAL header byte (if the NAL unit type is slice data). It is simple to decode, although you do need to understand exponential-Golomb coding which is described in H.264 (or more simply on the web/wikipedia/etc.). If all you care to decode from FU-A packets is what type of frame they carry, you only need to look at the second byte of the RTP payload (the byte after the FU-A NAL type 28) to decode the true H.264 NAL header. If the true H.264 NAL unit type is IDR, then it is all I slices, otherwise you need to decode the slice header to determine the frame type. Regards, Mo Zanaty ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 1:26 PM To: Mo Zanaty (mzanaty); 'Shevach Riabtsev'; 'Herbert Thoma' Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks Mo!! What do you mean with "slice header"? how can I get it.. do I need a decoder (like ipp or DS filter...) or can I do it reading "x" bytes of the NAL? I read in the RFC3984, i have concatenate FU-As so i can have a NAL, that means split the FU-A indicator and FU-A header and then concatenate? ________________________________ De: Mo Zanaty (mzanaty) [mailto:mzanaty at cisco.com] Enviado el: mi?rcoles, 03 de febrero de 2010 19:12 Para: Cristina Gil; Shevach Riabtsev; Herbert Thoma CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit IDR frames contain all I slices, so only decoding the NAL header is sufficient to know this. Non-IDR frames can contain I, P or B slices which can be determined by decoding the slice header. FU-A packets can contain anything, so decoding the byte after the FU-A NAL unit type (28) is required to get the true NAL unit type (0-23), which can then be decoded as IDR or non-IDR slice. Regards, Mo Zanaty ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 12:33 PM To: Mo Zanaty (mzanaty); 'Shevach Riabtsev'; 'Herbert Thoma' Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks for all your answers I appreciated them very much. Sorry Herbert, what I meant to say was RTP packet. I have packetization-mode=1 that means i can have IDR, non-IDR and FU-A (and STAP-A which I don't receive from the camera), so I will only have I and P images, do I need to decode the nal unit to know which kind of frame(s) I have or is there another way to know it? ________________________________ De: Mo Zanaty (mzanaty) [mailto:mzanaty at cisco.com] Enviado el: mi?rcoles, 03 de febrero de 2010 18:11 Para: Shevach Riabtsev; Cristina Gil CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit This depends on the "packetization-mode" of the RTP stream, which is defined in RFC3984, and indicated via SDP, not within the RTP stream itself. One RTP packet can only contain a single NAL unit if the packetization-mode is 0 or unspecified. Other packetization-mode values allow fragmentation of a single NAL unit over multiple RTP packets, and aggregation of multiple NAL units into a single RTP packet. Regards, Mo Zanaty ________________________________ From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Shevach Riabtsev Sent: Wednesday, February 03, 2010 11:06 AM To: Cristina Gil Cc: mp4-tech at lists.mpegif.org Subject: Re: [Mp4-tech] Number of bytes in NAL Unit Unfortunately I am not so familiar with RTP in order to provide reliable answer. ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 6:04 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks again for your answer!!! I have now a very silly question maybe is because of all these 0s and 1s make me feel confused... One RTP message could carry many NAL units, and each unit many type of images, right or wrong?? ________________________________ De: Shevach Riabtsev [mailto:Shevach.Riabtsev at zoran.com] Enviado el: mi?rcoles, 03 de febrero de 2010 16:15 Para: Cristina Gil CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit Cristina I define NAL unit delimiter for Annex_B compliant streams as the following regular expression - '[0]*000001' . Unfortunately the standard does not specify demarcation of NAL boundaries for streams which don't obey Annex B. Apparently RTP header does not contain NAL unit size/boundary information. If true then many trick modes (e.g. fast forward, fast resync. due to syntax errors) are unfeasible or challenging for implementations. Regards ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 4:55 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Hello, Thanks Shevach Riabtsev for your help, if me stream obeys to Annex B, my delimiter will be: - 1byte 0x00 (leading _zero_8bits) - 1byte 0x00 (zero_byte) - 3bytes 0x01 (start_code_prefix_one_3bytes) - 1byte 0x00 (trailing_zero_8bits) But I checked it and it isn't. I think my stream comes as "pure" RTP", is there another way to get the NAL size? ________________________________ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: mi?rcoles, 03 de febrero de 2010 15:05 Para: mp4-tech at lists.mpegif.org Asunto: [Mp4-tech] Number of bytes in NAL Unit Dear Cristina Gil If a stream obeys Annex B constraints then the size of NAL unit is determined by next start code. In other words the distance between the current start code and next one is actually NAL unit size. So, for determination of NAL unit size it is required to look ahead in the stream. I read the RFC3984 document which says the RTP header its 12bytes, but how can i know when the FU-As or NAL units are finished, in other words how many bytes of the RTP payload are padding (which makes the rtp packet header + payload (NAL + Padding) =1400). I read the ISO/IEC 14496 part 10: nal_unit( NumBytesInNALunit ) { forbidden_zero_bit //--->1bit nal_ref_idc //--->2bit nal_unit_type //--->5bit NumBytesInRBSP = 0 for( i = 1; i < NumBytesInNALunit; i++ ) { if( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) { rbsp_byte[ NumBytesInRBSP++ ] rbsp_byte[ NumBytesInRBSP++ ] i += 2 emulation_prevention_three_byte /* equal to 0x03 */ } else rbsp_byte[ NumBytesInRBSP++ ] } } How can i get NumBytesInNALunit? What does next_bits( 24 ) means? Regards Shevach Riabtsev Video compressionist ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100203/06b0a86d/attachment-0001.html From ramanujam at ti.com Thu Feb 4 01:28:33 2010 From: ramanujam at ti.com (Srinivasan, Ranga) Date: Thu, 4 Feb 2010 11:58:33 +0530 Subject: [Mp4-tech] Number of bytes in NAL Unit In-Reply-To: References: Message-ID: Gary and all, I have two questions, - Annex B format: Why is that size of NAL unit not present, as part of NAL unit header? Any specific reasons? I believe having the NAL unit size up-front will be useful. - RFC defining RTP payload format of SVC: Is it available? I see a draft version in this link, http://tools.ietf.org/html/draft-ietf-avt-rtp-svc-20. Thanks, Ranga -----Original Message----- From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of mp4-tech-request at lists.mpegif.org Sent: Wednesday, February 03, 2010 11:46 PM To: mp4-tech at lists.mpegif.org Subject: Mp4-tech Digest, Vol 79, Issue 8 Send Mp4-tech mailing list submissions to mp4-tech at 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 at lists.mpegif.org You can reach the person managing the list at mp4-tech-owner at 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. Re: Number of bytes in NAL Unit (Gary Sullivan) 2. Re: Number of bytes in NAL Unit (Mo Zanaty (mzanaty)) ---------------------------------------------------------------------- Message: 1 Date: Wed, 3 Feb 2010 17:02:57 +0000 From: Gary Sullivan Subject: Re: [Mp4-tech] Number of bytes in NAL Unit To: Shevach Riabtsev , Cristina Gil Cc: "mp4-tech at lists.mpegif.org" Message-ID: Content-Type: text/plain; charset="iso-8859-1" Ms. Gill et al, I am confident that RFC 3984 provides the information necessary to determine the NAL unit size, although I'm not very familiar with that spec. I think there may not be such a thing as "padding" when RFC 3984 is used, although I'm not sure about that. Forget about Annex B - it is not relevant when RFC 3984 is used. There is no such thing as "start codes" when RFC 2984 is used. The idea of "looking ahead" within the data to find the boundary of the next NAL unit does not apply when RFC 3984 is used. The idea that the packets have a fixed size equal to 1400 bytes as you reported does not sound correct to me. Possibly, on some network from some particular encoder, many of the packets will have that size. But I doubt that all of them will. (I also suggest not to necessarily assume that the behavior that you are seeing from some particular encoder is correct.) My suggestion would be to carefully read RFC 3984 (and the related RFC's that it depends on, such as the RFC's that define RTP). Best Regards, Gary Sullivan From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Shevach Riabtsev Sent: Wednesday, February 03, 2010 7:15 AM To: Cristina Gil Cc: mp4-tech at lists.mpegif.org Subject: Re: [Mp4-tech] Number of bytes in NAL Unit Cristina I define NAL unit delimiter for Annex_B compliant streams as the following regular expression - '[0]*000001' . Unfortunately the standard does not specify demarcation of NAL boundaries for streams which don't obey Annex B. Apparently RTP header does not contain NAL unit size/boundary information. If true then many trick modes (e.g. fast forward, fast resync. due to syntax errors) are unfeasible or challenging for implementations. Regards ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 4:55 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Hello, Thanks Shevach Riabtsev for your help, if me stream obeys to Annex B, my delimiter will be: - 1byte 0x00 (leading _zero_8bits) - 1byte 0x00 (zero_byte) - 3bytes 0x01 (start_code_prefix_one_3bytes) - 1byte 0x00 (trailing_zero_8bits) But I checked it and it isn't. I think my stream comes as "pure" RTP", is there another way to get the NAL size? ________________________________ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: mi?rcoles, 03 de febrero de 2010 15:05 Para: mp4-tech at lists.mpegif.org Asunto: [Mp4-tech] Number of bytes in NAL Unit Dear Cristina Gil If a stream obeys Annex B constraints then the size of NAL unit is determined by next start code. In other words the distance between the current start code and next one is actually NAL unit size. So, for determination of NAL unit size it is required to look ahead in the stream. Regards Shevach Riabtsev Video compressionist From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Cristina Gil Sent: Wednesday, February 03, 2010 3:43 AM To: mp4-tech at lists.mpegif.org Subject: [Mp4-tech] Number of bytes in NAL Unit Hello, I read the RFC3984 document which says the RTP header its 12bytes, but how can i know when the FU-As or NAL units are finished, in other words how many bytes of the RTP payload are padding (which makes the rtp packet header + payload (NAL + Padding) =1400). I read the ISO/IEC 14496 part 10: nal_unit( NumBytesInNALunit ) { forbidden_zero_bit //--->1bit nal_ref_idc //--->2bit nal_unit_type //--->5bit NumBytesInRBSP = 0 for( i = 1; i < NumBytesInNALunit; i++ ) { if( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) { rbsp_byte[ NumBytesInRBSP++ ] rbsp_byte[ NumBytesInRBSP++ ] i += 2 emulation_prevention_three_byte /* equal to 0x03 */ } else rbsp_byte[ NumBytesInRBSP++ ] } } How can i get NumBytesInNALunit? What does next_bits( 24 ) means? Thanks!!! ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100203/9db68161/attachment-0001.html From cristina.gil at sumenor.com Thu Feb 4 06:58:48 2010 From: cristina.gil at sumenor.com (Cristina Gil) Date: Thu, 4 Feb 2010 12:58:48 +0100 Subject: [Mp4-tech] nal_ref_idc Vs. nal_unit_type Message-ID: Hello, Im checking "nal_ref_idc" and "nal_unit_type". In the ISO/IEC 14496-10: "nal_ref_idc shall not be equal to 0 for IDR NAL units, i.e., NAL units with nal_unit_type equal to 5." In my code: aSkip=12 'skip first 12 bytes of the RTP header NAL_forbidden = data(aSkip) And &H80 'NAL_forbidden NAL_nri = (data(aSkip) >> 5) And &H3 'NAL_nri NAL_type = data(aSkip) And &H1F 'NAL_type Where data is the array containing the RTP+H.264 bytes, and then sometimes I get "nal_ref_idc=0" "nal_unit_type=5" which can't be posible. - Do I have to rule out the packet? - Is because I do something wrong? Thank you in advance for your help. AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100204/cfa501bd/attachment.html From cristina.gil at sumenor.com Thu Feb 4 12:02:24 2010 From: cristina.gil at sumenor.com (Cristina Gil) Date: Thu, 4 Feb 2010 18:02:24 +0100 Subject: [Mp4-tech] Number of bytes in NAL Unit In-Reply-To: References: <6E262D9404564240A42B726D52D20D29@SUMENORSCS.LOCAL> Message-ID: <9F40F319D2AB48DA8C94660C5CCE9130@SUMENORSCS.LOCAL> Hello, Mo Zanaty told me ?Non-IDR frames can contain I, P or B slices which can be determined by decoding the slice header? I?ve been reading the ISO/IEC 14496-10 (7.3.3 Slice header syntax) and googling, but I didn?t find the answer I hope you can help me with this, I know I have to decode the slice header with exp-golomb algorithm to get the slice type. But how can I know the slice header size? So I can read it and pass the slice header stream to the exp-golomb algorithm. Thanks for your help!! _____ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Mo Zanaty (mzanaty) Enviado el: mi?rcoles, 03 de febrero de 2010 19:58 Para: Cristina Gil; Shevach Riabtsev; Herbert Thoma CC: mp4-tech at lists.mpegif.org Asunto: Re: [Mp4-tech] Number of bytes in NAL Unit The slice header is immediately after the NAL header byte (if the NAL unit type is slice data). It is simple to decode, although you do need to understand exponential-Golomb coding which is described in H.264 (or more simply on the web/wikipedia/etc.). If all you care to decode from FU-A packets is what type of frame they carry, you only need to look at the second byte of the RTP payload (the byte after the FU-A NAL type 28) to decode the true H.264 NAL header. If the true H.264 NAL unit type is IDR, then it is all I slices, otherwise you need to decode the slice header to determine the frame type. Regards, Mo Zanaty _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 1:26 PM To: Mo Zanaty (mzanaty); 'Shevach Riabtsev'; 'Herbert Thoma' Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks Mo!! What do you mean with ?slice header?? how can I get it.. do I need a decoder (like ipp or DS filter ) or can I do it reading ?x? bytes of the NAL? I read in the RFC3984, i have concatenate FU-As so i can have a NAL, that means split the FU-A indicator and FU-A header and then concatenate? _____ De: Mo Zanaty (mzanaty) [mailto:mzanaty at cisco.com] Enviado el: mi?rcoles, 03 de febrero de 2010 19:12 Para: Cristina Gil; Shevach Riabtsev; Herbert Thoma CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit IDR frames contain all I slices, so only decoding the NAL header is sufficient to know this. Non-IDR frames can contain I, P or B slices which can be determined by decoding the slice header. FU-A packets can contain anything, so decoding the byte after the FU-A NAL unit type (28) is required to get the true NAL unit type (0-23), which can then be decoded as IDR or non-IDR slice. Regards, Mo Zanaty _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 12:33 PM To: Mo Zanaty (mzanaty); 'Shevach Riabtsev'; 'Herbert Thoma' Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks for all your answers I appreciated them very much. Sorry Herbert, what I meant to say was RTP packet. I have packetization-mode=1 that means i can have IDR, non-IDR and FU-A (and STAP-A which I don?t receive from the camera), so I will only have I and P images, do I need to decode the nal unit to know which kind of frame(s) I have or is there another way to know it? _____ De: Mo Zanaty (mzanaty) [mailto:mzanaty at cisco.com] Enviado el: mi?rcoles, 03 de febrero de 2010 18:11 Para: Shevach Riabtsev; Cristina Gil CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit This depends on the ?packetization-mode? of the RTP stream, which is defined in RFC3984, and indicated via SDP, not within the RTP stream itself. One RTP packet can only contain a single NAL unit if the packetization-mode is 0 or unspecified. Other packetization-mode values allow fragmentation of a single NAL unit over multiple RTP packets, and aggregation of multiple NAL units into a single RTP packet. Regards, Mo Zanaty _____ From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Shevach Riabtsev Sent: Wednesday, February 03, 2010 11:06 AM To: Cristina Gil Cc: mp4-tech at lists.mpegif.org Subject: Re: [Mp4-tech] Number of bytes in NAL Unit Unfortunately I am not so familiar with RTP in order to provide reliable answer. _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 6:04 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks again for your answer!!! I have now a very silly question maybe is because of all these 0s and 1s make me feel confused One RTP message could carry many NAL units, and each unit many type of images, right or wrong?? _____ De: Shevach Riabtsev [mailto:Shevach.Riabtsev at zoran.com] Enviado el: mi?rcoles, 03 de febrero de 2010 16:15 Para: Cristina Gil CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit Cristina I define NAL unit delimiter for Annex_B compliant streams as the following regular expression - ?[0]*000001? . Unfortunately the standard does not specify demarcation of NAL boundaries for streams which don?t obey Annex B. Apparently RTP header does not contain NAL unit size/boundary information. If true then many trick modes (e.g. fast forward, fast resync. due to syntax errors) are unfeasible or challenging for implementations. Regards _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 4:55 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Hello, Thanks Shevach Riabtsev for your help, if me stream obeys to Annex B, my delimiter will be: - 1byte 0x00 (leading _zero_8bits) - 1byte 0x00 (zero_byte) - 3bytes 0x01 (start_code_prefix_one_3bytes) - 1byte 0x00 (trailing_zero_8bits) But I checked it and it isn?t. I think my stream comes as ?pure? RTP?, is there another way to get the NAL size? _____ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: mi?rcoles, 03 de febrero de 2010 15:05 Para: mp4-tech at lists.mpegif.org Asunto: [Mp4-tech] Number of bytes in NAL Unit Dear Cristina Gil If a stream obeys Annex B constraints then the size of NAL unit is determined by next start code. In other words the distance between the current start code and next one is actually NAL unit size. So, for determination of NAL unit size it is required to look ahead in the stream. I read the RFC3984 document which says the RTP header its 12bytes, but how can i know when the FU-As or NAL units are finished, in other words how many bytes of the RTP payload are padding (which makes the rtp packet header + payload (NAL + Padding) =1400). I read the ISO/IEC 14496 part 10: nal_unit( NumBytesInNALunit ) { forbidden_zero_bit //--->1bit nal_ref_idc //--->2bit nal_unit_type //--->5bit NumBytesInRBSP = 0 for( i = 1; i < NumBytesInNALunit; i++ ) { if( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) { rbsp_byte[ NumBytesInRBSP++ ] rbsp_byte[ NumBytesInRBSP++ ] i += 2 emulation_prevention_three_byte /* equal to 0x03 */ } else rbsp_byte[ NumBytesInRBSP++ ] } } How can i get NumBytesInNALunit? What does next_bits( 24 ) means? Regards Shevach Riabtsev Video compressionist _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100204/1dc2b8a5/attachment-0001.html From singer at apple.com Thu Feb 4 12:09:16 2010 From: singer at apple.com (David Singer) Date: Thu, 4 Feb 2010 09:09:16 -0800 Subject: [Mp4-tech] Number of bytes in NAL Unit In-Reply-To: References: Message-ID: On Feb 3, 2010, at 22:28 , Srinivasan, Ranga wrote: > Gary and all, > I have two questions, > > - Annex B format: Why is that size of NAL unit not present, as part of NAL unit header? Any specific reasons? I believe having the NAL unit size up-front will be useful. well, there are two ways to do framing: size-based, or start-code based. Annex B documents the latter. If you prefer size-based, then you look at the size given by the framing system (e.g. MP4 file format, RTP payload format). > - RFC defining RTP payload format of SVC: Is it available? I see a draft version in this link, http://tools.ietf.org/html/draft-ietf-avt-rtp-svc-20. I think the IETF is trying to wrap this up now. > > Thanks, > Ranga > > -----Original Message----- > From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of mp4-tech-request at lists.mpegif.org > Sent: Wednesday, February 03, 2010 11:46 PM > To: mp4-tech at lists.mpegif.org > Subject: Mp4-tech Digest, Vol 79, Issue 8 > > Send Mp4-tech mailing list submissions to > mp4-tech at 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 at lists.mpegif.org > > You can reach the person managing the list at > mp4-tech-owner at 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. Re: Number of bytes in NAL Unit (Gary Sullivan) > 2. Re: Number of bytes in NAL Unit (Mo Zanaty (mzanaty)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 3 Feb 2010 17:02:57 +0000 > From: Gary Sullivan > Subject: Re: [Mp4-tech] Number of bytes in NAL Unit > To: Shevach Riabtsev , Cristina Gil > > Cc: "mp4-tech at lists.mpegif.org" > Message-ID: > > > Content-Type: text/plain; charset="iso-8859-1" > > Ms. Gill et al, > > I am confident that RFC 3984 provides the information necessary to determine the NAL unit size, although I'm not very familiar with that spec. > > I think there may not be such a thing as "padding" when RFC 3984 is used, although I'm not sure about that. > > Forget about Annex B - it is not relevant when RFC 3984 is used. There is no such thing as "start codes" when RFC 2984 is used. The idea of "looking ahead" within the data to find the boundary of the next NAL unit does not apply when RFC 3984 is used. > > The idea that the packets have a fixed size equal to 1400 bytes as you reported does not sound correct to me. Possibly, on some network from some particular encoder, many of the packets will have that size. But I doubt that all of them will. (I also suggest not to necessarily assume that the behavior that you are seeing from some particular encoder is correct.) > > My suggestion would be to carefully read RFC 3984 (and the related RFC's that it depends on, such as the RFC's that define RTP). > > Best Regards, > > Gary Sullivan > > From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Shevach Riabtsev > Sent: Wednesday, February 03, 2010 7:15 AM > To: Cristina Gil > Cc: mp4-tech at lists.mpegif.org > Subject: Re: [Mp4-tech] Number of bytes in NAL Unit > > Cristina > > I define NAL unit delimiter for Annex_B compliant streams as the following regular expression - '[0]*000001' . > > Unfortunately the standard does not specify demarcation of NAL boundaries for streams which don't obey Annex B. > > Apparently RTP header does not contain NAL unit size/boundary information. If true then many trick modes (e.g. fast forward, fast resync. due to syntax errors) are unfeasible or challenging for implementations. > > Regards > > > > ________________________________ > From: Cristina Gil [mailto:cristina.gil at sumenor.com] > Sent: Wednesday, February 03, 2010 4:55 PM > To: Shevach Riabtsev > Cc: mp4-tech at lists.mpegif.org > Subject: RE: [Mp4-tech] Number of bytes in NAL Unit > > > Hello, > > Thanks Shevach Riabtsev for your help, if me stream obeys to Annex B, my delimiter will be: > > - 1byte 0x00 (leading _zero_8bits) > > - 1byte 0x00 (zero_byte) > > - 3bytes 0x01 (start_code_prefix_one_3bytes) > > - 1byte 0x00 (trailing_zero_8bits) > > But I checked it and it isn't. I think my stream comes as "pure" RTP", is there another way to get the NAL size? > > ________________________________ > De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev > Enviado el: mi?rcoles, 03 de febrero de 2010 15:05 > Para: mp4-tech at lists.mpegif.org > Asunto: [Mp4-tech] Number of bytes in NAL Unit > > > Dear Cristina Gil > > If a stream obeys Annex B constraints then the size of NAL unit is determined by next start code. > > In other words the distance between the current start code and next one is actually NAL unit size. So, for determination of NAL unit size it is required to look ahead in the stream. > > Regards > > Shevach Riabtsev > > Video compressionist > > > From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Cristina Gil > Sent: Wednesday, February 03, 2010 3:43 AM > To: mp4-tech at lists.mpegif.org > Subject: [Mp4-tech] Number of bytes in NAL Unit > > > Hello, > > I read the RFC3984 document which says the RTP header its 12bytes, but how can i know when the FU-As or NAL units are finished, in other words how many bytes of the RTP payload are padding (which makes the rtp packet header + payload (NAL + Padding) =1400). > > I read the ISO/IEC 14496 part 10: > > nal_unit( NumBytesInNALunit ) { > forbidden_zero_bit //--->1bit > nal_ref_idc //--->2bit > nal_unit_type //--->5bit > > NumBytesInRBSP = 0 > > for( i = 1; i < NumBytesInNALunit; i++ ) { > if( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) { > rbsp_byte[ NumBytesInRBSP++ ] > rbsp_byte[ NumBytesInRBSP++ ] > i += 2 > emulation_prevention_three_byte /* equal to 0x03 */ > } else > rbsp_byte[ NumBytesInRBSP++ ] > } > } > > How can i get NumBytesInNALunit? > > What does next_bits( 24 ) means? > > Thanks!!! > > ________________________________ > AVISO LEGAL > La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: /pipermail/mp4-tech/attachments/20100203/9db68161/attachment-0001.html > > > _______________________________________________ > NOTE: Please use clear subject lines for your posts. Include [audio, [video], [systems], [general] or another appropriate 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 Multimedia and Software Standards, Apple Inc. From garysull at microsoft.com Thu Feb 4 14:32:37 2010 From: garysull at microsoft.com (Gary Sullivan) Date: Thu, 4 Feb 2010 19:32:37 +0000 Subject: [Mp4-tech] nal_ref_idc Vs. nal_unit_type In-Reply-To: References: Message-ID: Cristina Gil et al, I think that shouldn't be possible, so it would appear that you either are looking at data from a bad encoder or you have some bug in your software that is leading you to read the wrong bits. Best Regards, Gary Sullivan From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Cristina Gil Sent: Thursday, February 04, 2010 3:59 AM To: mp4-tech at lists.mpegif.org Subject: [Mp4-tech] nal_ref_idc Vs. nal_unit_type Hello, Im checking ?nal_ref_idc? and ?nal_unit_type?. In the ISO/IEC 14496-10: ?nal_ref_idc shall not be equal to 0 for IDR NAL units, i.e., NAL units with nal_unit_type equal to 5.? In my code: aSkip=12 'skip first 12 bytes of the RTP header NAL_forbidden = data(aSkip) And &H80 'NAL_forbidden NAL_nri = (data(aSkip) >> 5) And &H3 'NAL_nri NAL_type = data(aSkip) And &H1F 'NAL_type Where data is the array containing the RTP+H.264 bytes, and then sometimes I get ?nal_ref_idc=0? ?nal_unit_type=5? which can?t be posible. - Do I have to rule out the packet? - Is because I do something wrong? Thank you in advance for your help. ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100204/8e310e37/attachment.html From garysull at microsoft.com Thu Feb 4 14:58:16 2010 From: garysull at microsoft.com (Gary Sullivan) Date: Thu, 4 Feb 2010 19:58:16 +0000 Subject: [Mp4-tech] Number of bytes in NAL Unit In-Reply-To: References: Message-ID: One reason that there is no size parameter within the NAL unit header is delay minimization. In designing the video coding syntax, we generally try to lay out the syntax in the order in which the information may be generated by a minimal-delay encoder. The encoder won't know how big the NAL unit is until it has finished encoding the whole thing. This means that if it needed to put a size parameter in the header, the encoder would have to buffer up all of the data of entire NAL unit before it could determine what that value should be, and it could not start output of any of the bits of the NAL unit until it finished figuring out that value and writing it into the size parameter. We try to never make a decoder read something that arrives later in the bitstream in order to understand something else that arrived earlier in the bitstream, and we try to never make an encoder need to write something early in the bitstream that it won't know until it has finished generating the data for later information in the bitstream. The system-level method of carrying the encoded video data might impose such out-of-order processing requirements, but the video syntax is designed to be possible to be carried in a wide variety of system environments, so we try not to impose such requirements there. This allows the video to work as well as possible in any particular system - not burdening behavior in some system environments (e.g., H.320 or MPEG-2 mux) with issues relevant only in others (e.g. RTP). And vice versa (e.g., not requiring RTP to use start codes, which aren't needed there). Another reason for not having a size parameter in the NAL unit header is minimizing potential redundancy. Some systems would already have a way to signal how big a NAL unit is that is defined as part of the system specifications (e.g. a packet header). If we also put a size parameter within the video syntax, that would become a waste of bits in such a scenario. Best Regards, Gary Sullivan -----Original Message----- From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Srinivasan, Ranga Sent: Wednesday, February 03, 2010 10:29 PM To: mp4-tech at lists.mpegif.org Subject: Re: [Mp4-tech] Number of bytes in NAL Unit Gary and all, I have two questions, - Annex B format: Why is that size of NAL unit not present, as part of NAL unit header? Any specific reasons? I believe having the NAL unit size up-front will be useful. - RFC defining RTP payload format of SVC: Is it available? I see a draft version in this link, http://tools.ietf.org/html/draft-ietf-avt-rtp-svc-20. Thanks, Ranga -----Original Message----- From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of mp4-tech-request at lists.mpegif.org Sent: Wednesday, February 03, 2010 11:46 PM To: mp4-tech at lists.mpegif.org Subject: Mp4-tech Digest, Vol 79, Issue 8 Send Mp4-tech mailing list submissions to mp4-tech at 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 at lists.mpegif.org You can reach the person managing the list at mp4-tech-owner at 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. Re: Number of bytes in NAL Unit (Gary Sullivan) 2. Re: Number of bytes in NAL Unit (Mo Zanaty (mzanaty)) ---------------------------------------------------------------------- Message: 1 Date: Wed, 3 Feb 2010 17:02:57 +0000 From: Gary Sullivan Subject: Re: [Mp4-tech] Number of bytes in NAL Unit To: Shevach Riabtsev , Cristina Gil Cc: "mp4-tech at lists.mpegif.org" Message-ID: Content-Type: text/plain; charset="iso-8859-1" Ms. Gill et al, I am confident that RFC 3984 provides the information necessary to determine the NAL unit size, although I'm not very familiar with that spec. I think there may not be such a thing as "padding" when RFC 3984 is used, although I'm not sure about that. Forget about Annex B - it is not relevant when RFC 3984 is used. There is no such thing as "start codes" when RFC 2984 is used. The idea of "looking ahead" within the data to find the boundary of the next NAL unit does not apply when RFC 3984 is used. The idea that the packets have a fixed size equal to 1400 bytes as you reported does not sound correct to me. Possibly, on some network from some particular encoder, many of the packets will have that size. But I doubt that all of them will. (I also suggest not to necessarily assume that the behavior that you are seeing from some particular encoder is correct.) My suggestion would be to carefully read RFC 3984 (and the related RFC's that it depends on, such as the RFC's that define RTP). Best Regards, Gary Sullivan From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Shevach Riabtsev Sent: Wednesday, February 03, 2010 7:15 AM To: Cristina Gil Cc: mp4-tech at lists.mpegif.org Subject: Re: [Mp4-tech] Number of bytes in NAL Unit Cristina I define NAL unit delimiter for Annex_B compliant streams as the following regular expression - '[0]*000001' . Unfortunately the standard does not specify demarcation of NAL boundaries for streams which don't obey Annex B. Apparently RTP header does not contain NAL unit size/boundary information. If true then many trick modes (e.g. fast forward, fast resync. due to syntax errors) are unfeasible or challenging for implementations. Regards ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 4:55 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Hello, Thanks Shevach Riabtsev for your help, if me stream obeys to Annex B, my delimiter will be: - 1byte 0x00 (leading _zero_8bits) - 1byte 0x00 (zero_byte) - 3bytes 0x01 (start_code_prefix_one_3bytes) - 1byte 0x00 (trailing_zero_8bits) But I checked it and it isn't. I think my stream comes as "pure" RTP", is there another way to get the NAL size? ________________________________ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: mi?rcoles, 03 de febrero de 2010 15:05 Para: mp4-tech at lists.mpegif.org Asunto: [Mp4-tech] Number of bytes in NAL Unit Dear Cristina Gil If a stream obeys Annex B constraints then the size of NAL unit is determined by next start code. In other words the distance between the current start code and next one is actually NAL unit size. So, for determination of NAL unit size it is required to look ahead in the stream. Regards Shevach Riabtsev Video compressionist From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Cristina Gil Sent: Wednesday, February 03, 2010 3:43 AM To: mp4-tech at lists.mpegif.org Subject: [Mp4-tech] Number of bytes in NAL Unit Hello, I read the RFC3984 document which says the RTP header its 12bytes, but how can i know when the FU-As or NAL units are finished, in other words how many bytes of the RTP payload are padding (which makes the rtp packet header + payload (NAL + Padding) =1400). I read the ISO/IEC 14496 part 10: nal_unit( NumBytesInNALunit ) { forbidden_zero_bit //--->1bit nal_ref_idc //--->2bit nal_unit_type //--->5bit NumBytesInRBSP = 0 for( i = 1; i < NumBytesInNALunit; i++ ) { if( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) { rbsp_byte[ NumBytesInRBSP++ ] rbsp_byte[ NumBytesInRBSP++ ] i += 2 emulation_prevention_three_byte /* equal to 0x03 */ } else rbsp_byte[ NumBytesInRBSP++ ] } } How can i get NumBytesInNALunit? What does next_bits( 24 ) means? Thanks!!! ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100203/9db68161/attachment-0001.html _______________________________________________ NOTE: Please use clear subject lines for your posts. Include [audio, [video], [systems], [general] or another appropriate 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 cristina.gil at sumenor.com Thu Feb 4 15:16:50 2010 From: cristina.gil at sumenor.com (Cristina Gil) Date: Thu, 04 Feb 2010 21:16:50 +0100 Subject: [Mp4-tech] nal_ref_idc Vs. nal_unit_type In-Reply-To: ED47CB8A7957C54B854EFF043DFA54922021E5D7@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com Message-ID: <20100204201650.c7d2b715@host1.alta-electric.com> Thanks Gary for your answer, i have already fixed, i skip 13bytes instead of 12bytes. Buy i still have the problem to know how many bytes the slice header are and then do the exp-golomb... _____ From: Gary Sullivan [mailto:garysull at microsoft.com] To: Cristina Gil [mailto:cristina.gil at sumenor.com], mp4-tech at lists.mpegif.org [mailto:mp4-tech at lists.mpegif.org] Sent: Thu, 04 Feb 2010 20:32:37 +0100 Subject: RE: [Mp4-tech] nal_ref_idc Vs. nal_unit_type Cristina Gil et al, I think that shouldn't be possible, so it would appear that you either are looking at data from a bad encoder or you have some bug in your software that is leading you to read the wrong bits. Best Regards, Gary Sullivan From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Cristina Gil Sent: Thursday, February 04, 2010 3:59 AM To: mp4-tech at lists.mpegif.org Subject: [Mp4-tech] nal_ref_idc Vs. nal_unit_type Hello, Im checking ?nal_ref_idc? and ?nal_unit_type?. In the ISO/IEC 14496-10: ?nal_ref_idc shall not be equal to 0 for IDR NAL units, i.e., NAL units with nal_unit_type equal to 5.? In my code: aSkip=12 'skip first 12 bytes of the RTP header NAL_forbidden = data(aSkip) And &H80 'NAL_forbidden NAL_nri = (data(aSkip) >> 5) And &H3 'NAL_nri NAL_type = data(aSkip) And &H1F 'NAL_type Where data is the array containing the RTP+H.264 bytes, and then sometimes I get ?nal_ref_idc=0? ?nal_unit_type=5? which can?t be posible. - Do I have to rule out the packet? - Is because I do something wrong? Thank you in advance for your help. _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100204/9f4fedf1/attachment-0001.html From mzanaty at cisco.com Thu Feb 4 15:51:56 2010 From: mzanaty at cisco.com (Mo Zanaty (mzanaty)) Date: Thu, 4 Feb 2010 14:51:56 -0600 Subject: [Mp4-tech] Number of bytes in NAL Unit In-Reply-To: <9F40F319D2AB48DA8C94660C5CCE9130@SUMENORSCS.LOCAL> Message-ID: Cristina, Exp-golomb codes are inherently variable length, so there is no fixed slice header size. Just start decoding it using exp-golomb rules. Wikipedia has a very simple explanation. http://en.wikipedia.org/wiki/Exponential-Golomb_coding You can use wireshark to see how I/P/B slice type is decoded from the slice header of non-IDR slice NAL units. http://www.wireshark.org/download.html (use Development Release 1.3.2) Thanks, Mo Zanaty ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Thursday, February 04, 2010 12:02 PM To: Mo Zanaty (mzanaty); 'Shevach Riabtsev'; 'Herbert Thoma' Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Hello, Mo Zanaty told me "Non-IDR frames can contain I, P or B slices which can be determined by decoding the slice header" I've been reading the ISO/IEC 14496-10 (7.3.3 Slice header syntax) and googling, but I didn't find the answer I hope you can help me with this, I know I have to decode the slice header with exp-golomb algorithm to get the slice type. But how can I know the slice header size? So I can read it and pass the slice header stream to the exp-golomb algorithm. Thanks for your help!! ________________________________ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Mo Zanaty (mzanaty) Enviado el: mi?rcoles, 03 de febrero de 2010 19:58 Para: Cristina Gil; Shevach Riabtsev; Herbert Thoma CC: mp4-tech at lists.mpegif.org Asunto: Re: [Mp4-tech] Number of bytes in NAL Unit The slice header is immediately after the NAL header byte (if the NAL unit type is slice data). It is simple to decode, although you do need to understand exponential-Golomb coding which is described in H.264 (or more simply on the web/wikipedia/etc.). If all you care to decode from FU-A packets is what type of frame they carry, you only need to look at the second byte of the RTP payload (the byte after the FU-A NAL type 28) to decode the true H.264 NAL header. If the true H.264 NAL unit type is IDR, then it is all I slices, otherwise you need to decode the slice header to determine the frame type. Regards, Mo Zanaty ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 1:26 PM To: Mo Zanaty (mzanaty); 'Shevach Riabtsev'; 'Herbert Thoma' Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks Mo!! What do you mean with "slice header"? how can I get it.. do I need a decoder (like ipp or DS filter...) or can I do it reading "x" bytes of the NAL? I read in the RFC3984, i have concatenate FU-As so i can have a NAL, that means split the FU-A indicator and FU-A header and then concatenate? ________________________________ De: Mo Zanaty (mzanaty) [mailto:mzanaty at cisco.com] Enviado el: mi?rcoles, 03 de febrero de 2010 19:12 Para: Cristina Gil; Shevach Riabtsev; Herbert Thoma CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit IDR frames contain all I slices, so only decoding the NAL header is sufficient to know this. Non-IDR frames can contain I, P or B slices which can be determined by decoding the slice header. FU-A packets can contain anything, so decoding the byte after the FU-A NAL unit type (28) is required to get the true NAL unit type (0-23), which can then be decoded as IDR or non-IDR slice. Regards, Mo Zanaty ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 12:33 PM To: Mo Zanaty (mzanaty); 'Shevach Riabtsev'; 'Herbert Thoma' Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks for all your answers I appreciated them very much. Sorry Herbert, what I meant to say was RTP packet. I have packetization-mode=1 that means i can have IDR, non-IDR and FU-A (and STAP-A which I don't receive from the camera), so I will only have I and P images, do I need to decode the nal unit to know which kind of frame(s) I have or is there another way to know it? ________________________________ De: Mo Zanaty (mzanaty) [mailto:mzanaty at cisco.com] Enviado el: mi?rcoles, 03 de febrero de 2010 18:11 Para: Shevach Riabtsev; Cristina Gil CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit This depends on the "packetization-mode" of the RTP stream, which is defined in RFC3984, and indicated via SDP, not within the RTP stream itself. One RTP packet can only contain a single NAL unit if the packetization-mode is 0 or unspecified. Other packetization-mode values allow fragmentation of a single NAL unit over multiple RTP packets, and aggregation of multiple NAL units into a single RTP packet. Regards, Mo Zanaty ________________________________ From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Shevach Riabtsev Sent: Wednesday, February 03, 2010 11:06 AM To: Cristina Gil Cc: mp4-tech at lists.mpegif.org Subject: Re: [Mp4-tech] Number of bytes in NAL Unit Unfortunately I am not so familiar with RTP in order to provide reliable answer. ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 6:04 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks again for your answer!!! I have now a very silly question maybe is because of all these 0s and 1s make me feel confused... One RTP message could carry many NAL units, and each unit many type of images, right or wrong?? ________________________________ De: Shevach Riabtsev [mailto:Shevach.Riabtsev at zoran.com] Enviado el: mi?rcoles, 03 de febrero de 2010 16:15 Para: Cristina Gil CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit Cristina I define NAL unit delimiter for Annex_B compliant streams as the following regular expression - '[0]*000001' . Unfortunately the standard does not specify demarcation of NAL boundaries for streams which don't obey Annex B. Apparently RTP header does not contain NAL unit size/boundary information. If true then many trick modes (e.g. fast forward, fast resync. due to syntax errors) are unfeasible or challenging for implementations. Regards ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 4:55 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Hello, Thanks Shevach Riabtsev for your help, if me stream obeys to Annex B, my delimiter will be: - 1byte 0x00 (leading _zero_8bits) - 1byte 0x00 (zero_byte) - 3bytes 0x01 (start_code_prefix_one_3bytes) - 1byte 0x00 (trailing_zero_8bits) But I checked it and it isn't. I think my stream comes as "pure" RTP", is there another way to get the NAL size? ________________________________ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: mi?rcoles, 03 de febrero de 2010 15:05 Para: mp4-tech at lists.mpegif.org Asunto: [Mp4-tech] Number of bytes in NAL Unit Dear Cristina Gil If a stream obeys Annex B constraints then the size of NAL unit is determined by next start code. In other words the distance between the current start code and next one is actually NAL unit size. So, for determination of NAL unit size it is required to look ahead in the stream. I read the RFC3984 document which says the RTP header its 12bytes, but how can i know when the FU-As or NAL units are finished, in other words how many bytes of the RTP payload are padding (which makes the rtp packet header + payload (NAL + Padding) =1400). I read the ISO/IEC 14496 part 10: nal_unit( NumBytesInNALunit ) { forbidden_zero_bit //--->1bit nal_ref_idc //--->2bit nal_unit_type //--->5bit NumBytesInRBSP = 0 for( i = 1; i < NumBytesInNALunit; i++ ) { if( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) { rbsp_byte[ NumBytesInRBSP++ ] rbsp_byte[ NumBytesInRBSP++ ] i += 2 emulation_prevention_three_byte /* equal to 0x03 */ } else rbsp_byte[ NumBytesInRBSP++ ] } } How can i get NumBytesInNALunit? What does next_bits( 24 ) means? Regards Shevach Riabtsev Video compressionist ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100204/021dd6f3/attachment-0001.html From cristina.gil at sumenor.com Thu Feb 4 16:05:34 2010 From: cristina.gil at sumenor.com (Cristina Gil) Date: Thu, 04 Feb 2010 22:05:34 +0100 Subject: [Mp4-tech] Number of bytes in NAL Unit In-Reply-To: B2DE0AFA86565C47BD3A8435550F95535DA5AF@XMB-RCD-201.cisco.com Message-ID: <20100204210534.19539f3b@host1.alta-electric.com> Thanks Mo!! _____ From: Mo Zanaty (mzanaty) [mailto:mzanaty at cisco.com] To: Cristina Gil [mailto:cristina.gil at sumenor.com], Shevach Riabtsev [mailto:Shevach.Riabtsev at zoran.com], Herbert Thoma [mailto:herbert.thoma at iis.fraunhofer.de] Cc: mp4-tech at lists.mpegif.org Sent: Thu, 04 Feb 2010 21:51:56 +0100 Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Cristina, Exp-golomb codes are inherently variable length, so there is no fixed slice header size. Just start decoding it using exp-golomb rules. Wikipedia has a very simple explanation. http://en.wikipedia.org/wiki/Exponential-Golomb_coding You can use wireshark to see how I/P/B slice type is decoded from the slice header of non-IDR slice NAL units. http://www.wireshark.org/download.html (use Development Release 1.3.2) Thanks, Mo Zanaty _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Thursday, February 04, 2010 12:02 PM To: Mo Zanaty (mzanaty); 'Shevach Riabtsev'; 'Herbert Thoma' Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Hello, Mo Zanaty told me ?Non-IDR frames can contain I, P or B slices which can be determined by decoding the slice header? I?ve been reading the ISO/IEC 14496-10 (7.3.3 Slice header syntax) and googling, but I didn?t find the answer I hope you can help me with this, I know I have to decode the slice header with exp-golomb algorithm to get the slice type. But how can I know the slice header size? So I can read it and pass the slice header stream to the exp-golomb algorithm. Thanks for your help!! _____ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Mo Zanaty (mzanaty) Enviado el: mi?rcoles, 03 de febrero de 2010 19:58 Para: Cristina Gil; Shevach Riabtsev; Herbert Thoma CC: mp4-tech at lists.mpegif.org Asunto: Re: [Mp4-tech] Number of bytes in NAL Unit The slice header is immediately after the NAL header byte (if the NAL unit type is slice data). It is simple to decode, although you do need to understand exponential-Golomb coding which is described in H.264 (or more simply on the web/wikipedia/etc.). If all you care to decode from FU-A packets is what type of frame they carry, you only need to look at the second byte of the RTP payload (the byte after the FU-A NAL type 28) to decode the true H.264 NAL header. If the true H.264 NAL unit type is IDR, then it is all I slices, otherwise you need to decode the slice header to determine the frame type. Regards, Mo Zanaty _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 1:26 PM To: Mo Zanaty (mzanaty); 'Shevach Riabtsev'; 'Herbert Thoma' Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks Mo!! What do you mean with ?slice header?? how can I get it.. do I need a decoder (like ipp or DS filter?) or can I do it reading ?x? bytes of the NAL? I read in the RFC3984, i have concatenate FU-As so i can have a NAL, that means split the FU-A indicator and FU-A header and then concatenate? _____ De: Mo Zanaty (mzanaty) [mailto:mzanaty at cisco.com] Enviado el: mi?rcoles, 03 de febrero de 2010 19:12 Para: Cristina Gil; Shevach Riabtsev; Herbert Thoma CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit IDR frames contain all I slices, so only decoding the NAL header is sufficient to know this. Non-IDR frames can contain I, P or B slices which can be determined by decoding the slice header. FU-A packets can contain anything, so decoding the byte after the FU-A NAL unit type (28) is required to get the true NAL unit type (0-23), which can then be decoded as IDR or non-IDR slice. Regards, Mo Zanaty _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 12:33 PM To: Mo Zanaty (mzanaty); 'Shevach Riabtsev'; 'Herbert Thoma' Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks for all your answers I appreciated them very much. Sorry Herbert, what I meant to say was RTP packet. I have packetization-mode=1 that means i can have IDR, non-IDR and FU-A (and STAP-A which I don?t receive from the camera), so I will only have I and P images, do I need to decode the nal unit to know which kind of frame(s) I have or is there another way to know it? _____ De: Mo Zanaty (mzanaty) [mailto:mzanaty at cisco.com] Enviado el: mi?rcoles, 03 de febrero de 2010 18:11 Para: Shevach Riabtsev; Cristina Gil CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit This depends on the ?packetization-mode? of the RTP stream, which is defined in RFC3984, and indicated via SDP, not within the RTP stream itself. One RTP packet can only contain a single NAL unit if the packetization-mode is 0 or unspecified. Other packetization-mode values allow fragmentation of a single NAL unit over multiple RTP packets, and aggregation of multiple NAL units into a single RTP packet. Regards, Mo Zanaty _____ From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Shevach Riabtsev Sent: Wednesday, February 03, 2010 11:06 AM To: Cristina Gil Cc: mp4-tech at lists.mpegif.org Subject: Re: [Mp4-tech] Number of bytes in NAL Unit Unfortunately I am not so familiar with RTP in order to provide reliable answer. _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 6:04 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks again for your answer!!! I have now a very silly question maybe is because of all these 0s and 1s make me feel confused? One RTP message could carry many NAL units, and each unit many type of images, right or wrong?? _____ De: Shevach Riabtsev [mailto:Shevach.Riabtsev at zoran.com] Enviado el: mi?rcoles, 03 de febrero de 2010 16:15 Para: Cristina Gil CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit Cristina I define NAL unit delimiter for Annex_B compliant streams as the following regular expression - ?[0]*000001? . Unfortunately the standard does not specify demarcation of NAL boundaries for streams which don?t obey Annex B. Apparently RTP header does not contain NAL unit size/boundary information. If true then many trick modes (e.g. fast forward, fast resync. due to syntax errors) are unfeasible or challenging for implementations. Regards _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 4:55 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Hello, Thanks Shevach Riabtsev for your help, if me stream obeys to Annex B, my delimiter will be: - 1byte 0x00 (leading _zero_8bits) - 1byte 0x00 (zero_byte) - 3bytes 0x01 (start_code_prefix_one_3bytes) - 1byte 0x00 (trailing_zero_8bits) But I checked it and it isn?t. I think my stream comes as ?pure? RTP?, is there another way to get the NAL size? _____ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: mi?rcoles, 03 de febrero de 2010 15:05 Para: mp4-tech at lists.mpegif.org Asunto: [Mp4-tech] Number of bytes in NAL Unit Dear Cristina Gil If a stream obeys Annex B constraints then the size of NAL unit is determined by next start code. In other words the distance between the current start code and next one is actually NAL unit size. So, for determination of NAL unit size it is required to look ahead in the stream. I read the RFC3984 document which says the RTP header its 12bytes, but how can i know when the FU-As or NAL units are finished, in other words how many bytes of the RTP payload are padding (which makes the rtp packet header + payload (NAL + Padding) =1400). I read the ISO/IEC 14496 part 10: nal_unit( NumBytesInNALunit ) { forbidden_zero_bit //--->1bit nal_ref_idc //--->2bit nal_unit_type //--->5bit NumBytesInRBSP = 0 for( i = 1; i < NumBytesInNALunit; i++ ) { if( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) { rbsp_byte[ NumBytesInRBSP++ ] rbsp_byte[ NumBytesInRBSP++ ] i += 2 emulation_prevention_three_byte /* equal to 0x03 */ } else rbsp_byte[ NumBytesInRBSP++ ] } } How can i get NumBytesInNALunit? What does next_bits( 24 ) means? Regards Shevach Riabtsev Video compressionist _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100204/df7f218c/attachment-0001.html From mina_ayman at yahoo.com Fri Feb 5 14:47:23 2010 From: mina_ayman at yahoo.com (Mina Makar) Date: Fri, 5 Feb 2010 11:47:23 -0800 (PST) Subject: [Mp4-tech] problem with long term reference Message-ID: <714469.31073.qm@web57416.mail.re1.yahoo.com> I am trying to make all P-frames in a GOP predict from the first I-frame in this GOP. I'm using JM 16.1 software. i'm not using B-frames I thought of the following idea: 1. making every GOP start with an IDR instead of I frame 2. using only one reference frame. 3. Using this IDR as long term reference. I expected this way all P-frames will predict from the first frame in the GOP. In the cfg file, I made these modifications: IntraPeriod?????????? = 0 IDRPeriod???????????? = 30???????? (GOP size) SetFirstAsLongTerm??? =? 1 ReferenceReorder????? =? 0 I get this error "Max. number of reference frames exceeded. Invalid stream. I would like to know if there is something not standard compliant with my idea?. if it is standard compliant, how can i fix this problem and make it work? is there a better idea to achieve the same target? Thanks a lot. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100205/80d985d2/attachment.html From aleon at dolby.com Fri Feb 5 19:29:24 2010 From: aleon at dolby.com (Leontaris, Athanasios) Date: Fri, 5 Feb 2010 16:29:24 -0800 Subject: [Mp4-tech] problem with long term reference In-Reply-To: <714469.31073.qm@web57416.mail.re1.yahoo.com> References: <714469.31073.qm@web57416.mail.re1.yahoo.com> Message-ID: <2BAAC5E4AF2518459F0AB5D92794204702D834BA@bur-exch-01.dolby.net> Dear Mina, It seems you are also setting NumberReferenceFrames=1. Even though the specification should not have an issue with such a prediction configuration, the JM software does not currently support it. If you want to simulate the performance you could perhaps set the number of references to two and then disallow the motion estimation unit from selecting the reference index that corresponds to the short-term frame. An additional "solution" is to use the following parameters: "-p NumberBFrames=10 -p IDRPeriod=12 -p PReplaceBSlice=1 -p PreferDispOrder=0 -p EnableIDRGOP=1 -p FramesToBeEncoded=40 -p NumberReferenceFrames=1 -p SetFirstAsLongTerm=0 -p DisposableP=1" These parameters will yield a structure that is very close to your intended one. You could also use the Explicit coding functionality in the software but you would have to do this for the entire sequence. Best regards, Thanos ________________________________ From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Mina Makar Sent: Friday, February 05, 2010 11:47 AM To: mp4-tech at lists.mpegif.org Subject: [Mp4-tech] problem with long term reference I am trying to make all P-frames in a GOP predict from the first I-frame in this GOP. I'm using JM 16.1 software. i'm not using B-frames I thought of the following idea: 1. making every GOP start with an IDR instead of I frame 2. using only one reference frame. 3. Using this IDR as long term reference. I expected this way all P-frames will predict from the first frame in the GOP. In the cfg file, I made these modifications: IntraPeriod = 0 IDRPeriod = 30 (GOP size) SetFirstAsLongTerm = 1 ReferenceReorder = 0 I get this error "Max. number of reference frames exceeded. Invalid stream. I would like to know if there is something not standard compliant with my idea?. if it is standard compliant, how can i fix this problem and make it work? is there a better idea to achieve the same target? Thanks a lot. From mina_ayman at yahoo.com Sat Feb 6 15:17:43 2010 From: mina_ayman at yahoo.com (Mina Makar) Date: Sat, 6 Feb 2010 12:17:43 -0800 (PST) Subject: [Mp4-tech] problem with long term reference In-Reply-To: <2BAAC5E4AF2518459F0AB5D92794204702D834BA@bur-exch-01.dolby.net> Message-ID: <973861.90573.qm@web57408.mail.re1.yahoo.com> Dear Thanos, Thanks a lot for your reply. I have one more question. If i still want to use long term reference, you mentioned that i can use 2 reference frames and disallow motion estimation from short term ref. i think this will cause a problem with P_Skip mode since this mode automatically selects the first frame in the reference list which will be the short term one in my case. Do you agree on this point? I tried also your second idea. It works but it causes a huge increase in bit-rate. I think there is a lot of bits spent on signalling that the frame is B first and then converted to P. I think the resulting stream is different from declaring a frame to be P-frame directly. thanks again. Regards, Mina --- On Sat, 2/6/10, Leontaris, Athanasios wrote: From: Leontaris, Athanasios Subject: RE: [Mp4-tech] problem with long term reference To: "Mina Makar" , mp4-tech at lists.mpegif.org Date: Saturday, February 6, 2010, 2:29 AM Dear Mina, It seems you are also setting NumberReferenceFrames=1. Even though the specification should not have an issue with such a prediction configuration, the JM software does not currently support it. If you want to simulate the performance you could perhaps set the number of references to two and then disallow the motion estimation unit from selecting the reference index that corresponds to the short-term frame. An additional "solution" is to use the following parameters: "-p NumberBFrames=10 -p IDRPeriod=12 -p PReplaceBSlice=1 -p PreferDispOrder=0 -p EnableIDRGOP=1 -p FramesToBeEncoded=40 -p NumberReferenceFrames=1 -p SetFirstAsLongTerm=0 -p DisposableP=1" These parameters will yield a structure that is very close to your intended one. You could also use the Explicit coding functionality in the software but you would have to do this for the entire sequence. Best regards, Thanos ________________________________ From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Mina Makar Sent: Friday, February 05, 2010 11:47 AM To: mp4-tech at lists.mpegif.org Subject: [Mp4-tech] problem with long term reference I am trying to make all P-frames in a GOP predict from the first I-frame in this GOP. I'm using JM 16.1 software. i'm not using B-frames I thought of the following idea: 1. making every GOP start with an IDR instead of I frame 2. using only one reference frame. 3. Using this IDR as long term reference. I expected this way all P-frames will predict from the first frame in the GOP. In the cfg file, I made these modifications: IntraPeriod? ? ? ? ???= 0 IDRPeriod? ? ? ? ? ???= 30? ? ? ???(GOP size) SetFirstAsLongTerm? ? =? 1 ReferenceReorder? ? ? =? 0 I get this error "Max. number of reference frames exceeded. Invalid stream. I would like to know if there is something not standard compliant with my idea?. if it is standard compliant, how can i fix this problem and make it work? is there a better idea to achieve the same target? Thanks a lot. ??? -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100206/eab46add/attachment.html From sadafahmad7 at gmail.com Sun Feb 7 22:38:29 2010 From: sadafahmad7 at gmail.com (Sadaf Ahmad) Date: Sun, 7 Feb 2010 19:38:29 -0800 Subject: [Mp4-tech] Decoding H.264/AVC with errors in SPS, PPS and slice header. Message-ID: <9ec60e7a1002071938m1919d20etd2f33b36ca5963ec@mail.gmail.com> Hi all, I am using JM16.1 and want to able to decode a erroneous .264 file. I have inserted errors into the payload and have been able to get it to work, however, if there is an error in the SPS, PPS and NAL unit slice header, the decoder crashes. How can I tackle these error patterns, if it is possible at all, in the simplest way? Also, does a patch exist for JM software which does this, or if anyone has it? Thanks a lot, Sadaf -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100207/fed706c0/attachment.html From aleon at dolby.com Tue Feb 9 20:10:06 2010 From: aleon at dolby.com (Leontaris, Athanasios) Date: Tue, 9 Feb 2010 17:10:06 -0800 Subject: [Mp4-tech] problem with long term reference In-Reply-To: <973861.90573.qm@web57408.mail.re1.yahoo.com> References: <2BAAC5E4AF2518459F0AB5D92794204702D834BA@bur-exch-01.dolby.net> <973861.90573.qm@web57408.mail.re1.yahoo.com> Message-ID: <2BAAC5E4AF2518459F0AB5D92794204702D8395B@bur-exch-01.dolby.net> Dear Mina, Regarding your first question you can still use two reference frames (NumberReferenceFrames=2) and then set PList0References=1 to force using only the reference frame with ref_idx 0. To ensure that this reference is the long-term reference frame you have to send reference reordering/modification commands that will place the long-term reference frame in ref_idx 0 and move the short-term reference frame to position 1. Versus which reference bitstream or coding structure are you getting the increase in bit rate? To my knowledge the only thing that is different from your intended coding structure is the coding order. Note also that there is no such thing as first signaling a frame as B and then sending some additional information to convert it to a P frame within the bitstream. PReplaceBSlice is just an encoder parameter that instructs the encoder to code P slices in the place of B. There may be a difference with respect to the calculation of lambda parameters used for rate-distortion optimization, but these should not cause a huge increase in bit rate. Best regards, Thanos ________________________________ From: Mina Makar [mailto:mina_ayman at yahoo.com] Sent: Saturday, February 06, 2010 12:18 PM To: Leontaris, Athanasios; mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] problem with long term reference Dear Thanos, Thanks a lot for your reply. I have one more question. If i still want to use long term reference, you mentioned that i can use 2 reference frames and disallow motion estimation from short term ref. i think this will cause a problem with P_Skip mode since this mode automatically selects the first frame in the reference list which will be the short term one in my case. Do you agree on this point? I tried also your second idea. It works but it causes a huge increase in bit-rate. I think there is a lot of bits spent on signalling that the frame is B first and then converted to P. I think the resulting stream is different from declaring a frame to be P-frame directly. thanks again. Regards, Mina --- On Sat, 2/6/10, Leontaris, Athanasios wrote: From: Leontaris, Athanasios Subject: RE: [Mp4-tech] problem with long term reference To: "Mina Makar" , mp4-tech at lists.mpegif.org Date: Saturday, February 6, 2010, 2:29 AM Dear Mina, It seems you are also setting NumberReferenceFrames=1. Even though the specification should not have an issue with such a prediction configuration, the JM software does not currently support it. If you want to simulate the performance you could perhaps set the number of references to two and then disallow the motion estimation unit from selecting the reference index that corresponds to the short-term frame. An additional "solution" is to use the following parameters: "-p NumberBFrames=10 -p IDRPeriod=12 -p PReplaceBSlice=1 -p PreferDispOrder=0 -p EnableIDRGOP=1 -p FramesToBeEncoded=40 -p NumberReferenceFrames=1 -p SetFirstAsLongTerm=0 -p DisposableP=1" These parameters will yield a structure that is very close to your intended one. You could also use the Explicit coding functionality in the software but you would have to do this for the entire sequence. Best regards, Thanos ________________________________ From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Mina Makar Sent: Friday, February 05, 2010 11:47 AM To: mp4-tech at lists.mpegif.org Subject: [Mp4-tech] problem with long term reference I am trying to make all P-frames in a GOP predict from the first I-frame in this GOP. I'm using JM 16.1 software. i'm not using B-frames I thought of the following idea: 1. making every GOP start with an IDR instead of I frame 2. using only one reference frame. 3. Using this IDR as long term reference. I expected this way all P-frames will predict from the first frame in the GOP. In the cfg file, I made these modifications: IntraPeriod = 0 IDRPeriod = 30 (GOP size) SetFirstAsLongTerm = 1 ReferenceReorder = 0 I get this error "Max. number of reference frames exceeded. Invalid stream. I would like to know if there is something not standard compliant with my idea?. if it is standard compliant, how can i fix this problem and make it work? is there a better idea to achieve the same target? Thanks a lot. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100209/4485524c/attachment.html From cristina.gil at sumenor.com Thu Feb 11 12:11:05 2010 From: cristina.gil at sumenor.com (Cristina Gil) Date: Thu, 11 Feb 2010 18:11:05 +0100 Subject: [Mp4-tech] Number of bytes in NAL Unit In-Reply-To: References: <9F40F319D2AB48DA8C94660C5CCE9130@SUMENORSCS.LOCAL> Message-ID: Hello, I decoded successfully the SPS and PPS messages both are needed to get the slice header, I have probed the exp-golomb algorithm code I did its working (thanks Mo for your help!! Wireshark really helped me) but I don?t know how to get the parameters with the u(v) descriptor which are defined for the Slice Header, for example: slice_header( ) { first_mb_in_slice --> ue(v) (exp-golomb) slice_type --> ue(v) ) (exp-golomb) pic_parameter_set_id --> ue(v) ) (exp-golomb) frame_num --> u(v) ????? if( !frame_mbs_only_flag ) { field_pic_flag --> u(1) (read_bit(number of bits to be read = 1)) if( field_pic_flag ) bottom_field_flag --> u(1) (read_bit(number of bits to be read = 1)) How do I read u(v) parameters? Thank in advance for your help _____ De: Mo Zanaty (mzanaty) [mailto:mzanaty at cisco.com] Enviado el: jueves, 04 de febrero de 2010 21:52 Para: Cristina Gil; Shevach Riabtsev; Herbert Thoma CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit Cristina, Exp-golomb codes are inherently variable length, so there is no fixed slice header size. Just start decoding it using exp-golomb rules. Wikipedia has a very simple explanation. http://en.wikipedia.org/wiki/Exponential-Golomb_coding You can use wireshark to see how I/P/B slice type is decoded from the slice header of non-IDR slice NAL units. http://www.wireshark.org/download.html (use Development Release 1.3.2) Thanks, Mo Zanaty _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Thursday, February 04, 2010 12:02 PM To: Mo Zanaty (mzanaty); 'Shevach Riabtsev'; 'Herbert Thoma' Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Hello, Mo Zanaty told me ?Non-IDR frames can contain I, P or B slices which can be determined by decoding the slice header? I?ve been reading the ISO/IEC 14496-10 (7.3.3 Slice header syntax) and googling, but I didn?t find the answer I hope you can help me with this, I know I have to decode the slice header with exp-golomb algorithm to get the slice type. But how can I know the slice header size? So I can read it and pass the slice header stream to the exp-golomb algorithm. Thanks for your help!! _____ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Mo Zanaty (mzanaty) Enviado el: mi?rcoles, 03 de febrero de 2010 19:58 Para: Cristina Gil; Shevach Riabtsev; Herbert Thoma CC: mp4-tech at lists.mpegif.org Asunto: Re: [Mp4-tech] Number of bytes in NAL Unit The slice header is immediately after the NAL header byte (if the NAL unit type is slice data). It is simple to decode, although you do need to understand exponential-Golomb coding which is described in H.264 (or more simply on the web/wikipedia/etc.). If all you care to decode from FU-A packets is what type of frame they carry, you only need to look at the second byte of the RTP payload (the byte after the FU-A NAL type 28) to decode the true H.264 NAL header. If the true H.264 NAL unit type is IDR, then it is all I slices, otherwise you need to decode the slice header to determine the frame type. Regards, Mo Zanaty _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 1:26 PM To: Mo Zanaty (mzanaty); 'Shevach Riabtsev'; 'Herbert Thoma' Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks Mo!! What do you mean with ?slice header?? how can I get it.. do I need a decoder (like ipp or DS filter ) or can I do it reading ?x? bytes of the NAL? I read in the RFC3984, i have concatenate FU-As so i can have a NAL, that means split the FU-A indicator and FU-A header and then concatenate? _____ De: Mo Zanaty (mzanaty) [mailto:mzanaty at cisco.com] Enviado el: mi?rcoles, 03 de febrero de 2010 19:12 Para: Cristina Gil; Shevach Riabtsev; Herbert Thoma CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit IDR frames contain all I slices, so only decoding the NAL header is sufficient to know this. Non-IDR frames can contain I, P or B slices which can be determined by decoding the slice header. FU-A packets can contain anything, so decoding the byte after the FU-A NAL unit type (28) is required to get the true NAL unit type (0-23), which can then be decoded as IDR or non-IDR slice. Regards, Mo Zanaty _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 12:33 PM To: Mo Zanaty (mzanaty); 'Shevach Riabtsev'; 'Herbert Thoma' Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks for all your answers I appreciated them very much. Sorry Herbert, what I meant to say was RTP packet. I have packetization-mode=1 that means i can have IDR, non-IDR and FU-A (and STAP-A which I don?t receive from the camera), so I will only have I and P images, do I need to decode the nal unit to know which kind of frame(s) I have or is there another way to know it? _____ De: Mo Zanaty (mzanaty) [mailto:mzanaty at cisco.com] Enviado el: mi?rcoles, 03 de febrero de 2010 18:11 Para: Shevach Riabtsev; Cristina Gil CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit This depends on the ?packetization-mode? of the RTP stream, which is defined in RFC3984, and indicated via SDP, not within the RTP stream itself. One RTP packet can only contain a single NAL unit if the packetization-mode is 0 or unspecified. Other packetization-mode values allow fragmentation of a single NAL unit over multiple RTP packets, and aggregation of multiple NAL units into a single RTP packet. Regards, Mo Zanaty _____ From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Shevach Riabtsev Sent: Wednesday, February 03, 2010 11:06 AM To: Cristina Gil Cc: mp4-tech at lists.mpegif.org Subject: Re: [Mp4-tech] Number of bytes in NAL Unit Unfortunately I am not so familiar with RTP in order to provide reliable answer. _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 6:04 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks again for your answer!!! I have now a very silly question maybe is because of all these 0s and 1s make me feel confused One RTP message could carry many NAL units, and each unit many type of images, right or wrong?? _____ De: Shevach Riabtsev [mailto:Shevach.Riabtsev at zoran.com] Enviado el: mi?rcoles, 03 de febrero de 2010 16:15 Para: Cristina Gil CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit Cristina I define NAL unit delimiter for Annex_B compliant streams as the following regular expression - ?[0]*000001? . Unfortunately the standard does not specify demarcation of NAL boundaries for streams which don?t obey Annex B. Apparently RTP header does not contain NAL unit size/boundary information. If true then many trick modes (e.g. fast forward, fast resync. due to syntax errors) are unfeasible or challenging for implementations. Regards _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 4:55 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Hello, Thanks Shevach Riabtsev for your help, if me stream obeys to Annex B, my delimiter will be: - 1byte 0x00 (leading _zero_8bits) - 1byte 0x00 (zero_byte) - 3bytes 0x01 (start_code_prefix_one_3bytes) - 1byte 0x00 (trailing_zero_8bits) But I checked it and it isn?t. I think my stream comes as ?pure? RTP?, is there another way to get the NAL size? _____ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: mi?rcoles, 03 de febrero de 2010 15:05 Para: mp4-tech at lists.mpegif.org Asunto: [Mp4-tech] Number of bytes in NAL Unit Dear Cristina Gil If a stream obeys Annex B constraints then the size of NAL unit is determined by next start code. In other words the distance between the current start code and next one is actually NAL unit size. So, for determination of NAL unit size it is required to look ahead in the stream. I read the RFC3984 document which says the RTP header its 12bytes, but how can i know when the FU-As or NAL units are finished, in other words how many bytes of the RTP payload are padding (which makes the rtp packet header + payload (NAL + Padding) =1400). I read the ISO/IEC 14496 part 10: nal_unit( NumBytesInNALunit ) { forbidden_zero_bit //--->1bit nal_ref_idc //--->2bit nal_unit_type //--->5bit NumBytesInRBSP = 0 for( i = 1; i < NumBytesInNALunit; i++ ) { if( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) { rbsp_byte[ NumBytesInRBSP++ ] rbsp_byte[ NumBytesInRBSP++ ] i += 2 emulation_prevention_three_byte /* equal to 0x03 */ } else rbsp_byte[ NumBytesInRBSP++ ] } } How can i get NumBytesInNALunit? What does next_bits( 24 ) means? Regards Shevach Riabtsev Video compressionist _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100211/7e2fe6cf/attachment-0001.html From singer at apple.com Thu Feb 11 12:59:29 2010 From: singer at apple.com (David Singer) Date: Thu, 11 Feb 2010 09:59:29 -0800 Subject: [Mp4-tech] Number of bytes in NAL Unit In-Reply-To: References: <9F40F319D2AB48DA8C94660C5CCE9130@SUMENORSCS.LOCAL> Message-ID: <53DA0194-C425-4F20-A4F1-AFE8F6E4D142@apple.com> I think the documentation of frame_num makes it clear; frame_num is used as an identifier for pictures and shall be represented by log2_max_frame_num_minus4 + 4 bits in the bitstream. in general, I think all u(v) parameters have their bit-count defined in some way. On Feb 11, 2010, at 9:11 , Cristina Gil wrote: > Hello, > > I decoded successfully the SPS and PPS messages both are needed to get the slice header, I have probed the exp-golomb algorithm code I did its working (thanks Mo for your help!! Wireshark really helped me) but I don?t know how to get the parameters with the u(v) descriptor which are defined for the Slice Header, for example: > > slice_header( ) { > > first_mb_in_slice ? ue(v) (exp-golomb) > slice_type ? ue(v) ) (exp-golomb) > pic_parameter_set_id ? ue(v) ) (exp-golomb) > frame_num ? u(v) ????? > if( !frame_mbs_only_flag ) { > field_pic_flag ? u(1) (read_bit(number of bits to be read = 1)) > if( field_pic_flag ) > bottom_field_flag ? u(1) (read_bit(number of bits to be read = 1)) > ? > > How do I read u(v) parameters? > > Thank in advance for your help > De: Mo Zanaty (mzanaty) [mailto:mzanaty at cisco.com] > Enviado el: jueves, 04 de febrero de 2010 21:52 > Para: Cristina Gil; Shevach Riabtsev; Herbert Thoma > CC: mp4-tech at lists.mpegif.org > Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit > > Cristina, > Exp-golomb codes are inherently variable length, so there is no fixed slice header size. Just start decoding it using exp-golomb rules. Wikipedia has a very simple explanation. > http://en.wikipedia.org/wiki/Exponential-Golomb_coding > > You can use wireshark to see how I/P/B slice type is decoded from the slice header of non-IDR slice NAL units. > http://www.wireshark.org/download.html (use Development Release 1.3.2) > > Thanks, > Mo Zanaty > > From: Cristina Gil [mailto:cristina.gil at sumenor.com] > Sent: Thursday, February 04, 2010 12:02 PM > To: Mo Zanaty (mzanaty); 'Shevach Riabtsev'; 'Herbert Thoma' > Cc: mp4-tech at lists.mpegif.org > Subject: RE: [Mp4-tech] Number of bytes in NAL Unit > > Hello, > > Mo Zanaty told me ?Non-IDR frames can contain I, P or B slices which can be determined by decoding the slice header? > > I?ve been reading the ISO/IEC 14496-10 (7.3.3 Slice header syntax) and googling, but I didn?t find the answer I hope you can help me with this, I know I have to decode the slice header with exp-golomb algorithm to get the slice type. > > But how can I know the slice header size? So I can read it and pass the slice header stream to the exp-golomb algorithm. > > Thanks for your help!! > > De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Mo Zanaty (mzanaty) > Enviado el: mi?rcoles, 03 de febrero de 2010 19:58 > Para: Cristina Gil; Shevach Riabtsev; Herbert Thoma > CC: mp4-tech at lists.mpegif.org > Asunto: Re: [Mp4-tech] Number of bytes in NAL Unit > > The slice header is immediately after the NAL header byte (if the NAL unit type is slice data). It is simple to decode, although you do need to understand exponential-Golomb coding which is described in H.264 (or more simply on the web/wikipedia/etc.). > > If all you care to decode from FU-A packets is what type of frame they carry, you only need to look at the second byte of the RTP payload (the byte after the FU-A NAL type 28) to decode the true H.264 NAL header. If the true H.264 NAL unit type is IDR, then it is all I slices, otherwise you need to decode the slice header to determine the frame type. > > Regards, > Mo Zanaty > > From: Cristina Gil [mailto:cristina.gil at sumenor.com] > Sent: Wednesday, February 03, 2010 1:26 PM > To: Mo Zanaty (mzanaty); 'Shevach Riabtsev'; 'Herbert Thoma' > Cc: mp4-tech at lists.mpegif.org > Subject: RE: [Mp4-tech] Number of bytes in NAL Unit > > Thanks Mo!! > > What do you mean with ?slice header?? how can I get it.. do I need a decoder (like ipp or DS filter?) or can I do it reading ?x? bytes of the NAL? > > I read in the RFC3984, i have concatenate FU-As so i can have a NAL, that means split the FU-A indicator and FU-A header and then concatenate? > De: Mo Zanaty (mzanaty) [mailto:mzanaty at cisco.com] > Enviado el: mi?rcoles, 03 de febrero de 2010 19:12 > Para: Cristina Gil; Shevach Riabtsev; Herbert Thoma > CC: mp4-tech at lists.mpegif.org > Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit > > IDR frames contain all I slices, so only decoding the NAL header is sufficient to know this. Non-IDR frames can contain I, P or B slices which can be determined by decoding the slice header. FU-A packets can contain anything, so decoding the byte after the FU-A NAL unit type (28) is required to get the true NAL unit type (0-23), which can then be decoded as IDR or non-IDR slice. > > Regards, > Mo Zanaty > > From: Cristina Gil [mailto:cristina.gil at sumenor.com] > Sent: Wednesday, February 03, 2010 12:33 PM > To: Mo Zanaty (mzanaty); 'Shevach Riabtsev'; 'Herbert Thoma' > Cc: mp4-tech at lists.mpegif.org > Subject: RE: [Mp4-tech] Number of bytes in NAL Unit > > Thanks for all your answers I appreciated them very much. > > Sorry Herbert, what I meant to say was RTP packet. > > I have packetization-mode=1 that means i can have IDR, non-IDR and FU-A (and STAP-A which I don?t receive from the camera), so I will only have I and P images, do I need to decode the nal unit to know which kind of frame(s) I have or is there another way to know it? > > > > De: Mo Zanaty (mzanaty) [mailto:mzanaty at cisco.com] > Enviado el: mi?rcoles, 03 de febrero de 2010 18:11 > Para: Shevach Riabtsev; Cristina Gil > CC: mp4-tech at lists.mpegif.org > Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit > > This depends on the ?packetization-mode? of the RTP stream, which is defined in RFC3984, and indicated via SDP, not within the RTP stream itself. One RTP packet can only contain a single NAL unit if the packetization-mode is 0 or unspecified. Other packetization-mode values allow fragmentation of a single NAL unit over multiple RTP packets, and aggregation of multiple NAL units into a single RTP packet. > > Regards, > Mo Zanaty > > From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Shevach Riabtsev > Sent: Wednesday, February 03, 2010 11:06 AM > To: Cristina Gil > Cc: mp4-tech at lists.mpegif.org > Subject: Re: [Mp4-tech] Number of bytes in NAL Unit > > Unfortunately I am not so familiar with RTP in order to provide reliable answer. > > From: Cristina Gil [mailto:cristina.gil at sumenor.com] > Sent: Wednesday, February 03, 2010 6:04 PM > To: Shevach Riabtsev > Cc: mp4-tech at lists.mpegif.org > Subject: RE: [Mp4-tech] Number of bytes in NAL Unit > > Thanks again for your answer!!! > > I have now a very silly question maybe is because of all these 0s and 1s make me feel confused? > > One RTP message could carry many NAL units, and each unit many type of images, right or wrong?? > > > De: Shevach Riabtsev [mailto:Shevach.Riabtsev at zoran.com] > Enviado el: mi?rcoles, 03 de febrero de 2010 16:15 > Para: Cristina Gil > CC: mp4-tech at lists.mpegif.org > Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit > > Cristina > > I define NAL unit delimiter for Annex_B compliant streams as the following regular expression - ?[0]*000001? . > > Unfortunately the standard does not specify demarcation of NAL boundaries for streams which don?t obey Annex B. > > Apparently RTP header does not contain NAL unit size/boundary information. If true then many trick modes (e.g. fast forward, fast resync. due to syntax errors) are unfeasible or challenging for implementations. > > Regards > > > > From: Cristina Gil [mailto:cristina.gil at sumenor.com] > Sent: Wednesday, February 03, 2010 4:55 PM > To: Shevach Riabtsev > Cc: mp4-tech at lists.mpegif.org > Subject: RE: [Mp4-tech] Number of bytes in NAL Unit > > Hello, > > Thanks Shevach Riabtsev for your help, if me stream obeys to Annex B, my delimiter will be: > > - 1byte 0x00 (leading _zero_8bits) > > - 1byte 0x00 (zero_byte) > > - 3bytes 0x01 (start_code_prefix_one_3bytes) > > - 1byte 0x00 (trailing_zero_8bits) > > But I checked it and it isn?t. I think my stream comes as ?pure? RTP?, is there another way to get the NAL size? > > De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev > Enviado el: mi?rcoles, 03 de febrero de 2010 15:05 > Para: mp4-tech at lists.mpegif.org > Asunto: [Mp4-tech] Number of bytes in NAL Unit > > Dear Cristina Gil > > If a stream obeys Annex B constraints then the size of NAL unit is determined by next start code. > > In other words the distance between the current start code and next one is actually NAL unit size. So, for determination of NAL unit size it is required to look ahead in the stream. > > I read the RFC3984 document which says the RTP header its 12bytes, but how > > can i know when the FU-As or NAL units are finished, in other words how many > > bytes of the RTP payload are padding (which makes the rtp packet header + > > payload (NAL + Padding) =1400). > > I read the ISO/IEC 14496 part 10: > > nal_unit( NumBytesInNALunit ) { > > forbidden_zero_bit //--->1bit > > nal_ref_idc //--->2bit > > nal_unit_type //--->5bit > > NumBytesInRBSP = 0 > > for( i = 1; i < NumBytesInNALunit; i++ ) { > > if( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) { > > rbsp_byte[ NumBytesInRBSP++ ] > > rbsp_byte[ NumBytesInRBSP++ ] > > i += 2 > > emulation_prevention_three_byte /* equal to 0x03 */ > > } else > > rbsp_byte[ NumBytesInRBSP++ ] > > } > > } > > How can i get NumBytesInNALunit? > > What does next_bits( 24 ) means? > > Regards > > Shevach Riabtsev > > Video compressionist > > > > AVISO LEGAL > La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. > > > AVISO LEGAL > La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. > > > AVISO LEGAL > La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. > > > AVISO LEGAL > La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. > > > AVISO LEGAL > La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. > > > AVISO LEGAL > La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. > _______________________________________________ > NOTE: Please use clear subject lines for your posts. Include [audio, [video], [systems], [general] or another appropriate 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 Multimedia and Software Standards, Apple Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100211/c3ad4d99/attachment-0001.html From garysull at microsoft.com Thu Feb 11 13:28:38 2010 From: garysull at microsoft.com (Gary Sullivan) Date: Thu, 11 Feb 2010 18:28:38 +0000 Subject: [Mp4-tech] Number of bytes in NAL Unit In-Reply-To: <53DA0194-C425-4F20-A4F1-AFE8F6E4D142@apple.com> References: <9F40F319D2AB48DA8C94660C5CCE9130@SUMENORSCS.LOCAL> <53DA0194-C425-4F20-A4F1-AFE8F6E4D142@apple.com> Message-ID: Cristina, Dave, et al, Exactly - Dave is correct. Any u(v) syntax element is just a fixed-length coded unsigned integer, where the number of bits is specified in the corresponding semantics section (7.4.3 in this case). See subclause 7.2, which is the first thing you'll find if you start at the beginning of the spec and search for "u(", although I suppose you won't find it if you search for "u(v)": - u(n): unsigned integer using n bits. When n is "v" in the syntax table, the number of bits varies in a manner dependent on the value of other syntax elements. The parsing process for this descriptor is specified by the return value of the function read_bits( n ) interpreted as a binary representation of an unsigned integer with most significant bit written first. Best Regards, Gary Sullivan From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of David Singer Sent: Thursday, February 11, 2010 9:59 AM To: mp4-tech at lists.mpegif.org Subject: Re: [Mp4-tech] Number of bytes in NAL Unit I think the documentation of frame_num makes it clear; frame_num is used as an identifier for pictures and shall be represented by log2_max_frame_num_minus4 + 4 bits in the bitstream. in general, I think all u(v) parameters have their bit-count defined in some way. On Feb 11, 2010, at 9:11 , Cristina Gil wrote: Hello, I decoded successfully the SPS and PPS messages both are needed to get the slice header, I have probed the exp-golomb algorithm code I did its working (thanks Mo for your help!! Wireshark really helped me) but I don't know how to get the parameters with the u(v) descriptor which are defined for the Slice Header, for example: slice_header( ) { first_mb_in_slice --> ue(v) (exp-golomb) slice_type --> ue(v) ) (exp-golomb) pic_parameter_set_id --> ue(v) ) (exp-golomb) frame_num --> u(v) ????? if( !frame_mbs_only_flag ) { field_pic_flag --> u(1) (read_bit(number of bits to be read = 1)) if( field_pic_flag ) bottom_field_flag --> u(1) (read_bit(number of bits to be read = 1)) ... How do I read u(v) parameters? Thank in advance for your help ________________________________ De: Mo Zanaty (mzanaty) [mailto:mzanaty at cisco.com] Enviado el: jueves, 04 de febrero de 2010 21:52 Para: Cristina Gil; Shevach Riabtsev; Herbert Thoma CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit Cristina, Exp-golomb codes are inherently variable length, so there is no fixed slice header size. Just start decoding it using exp-golomb rules. Wikipedia has a very simple explanation. http://en.wikipedia.org/wiki/Exponential-Golomb_coding You can use wireshark to see how I/P/B slice type is decoded from the slice header of non-IDR slice NAL units. http://www.wireshark.org/download.html (use Development Release 1.3.2) Thanks, Mo Zanaty ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Thursday, February 04, 2010 12:02 PM To: Mo Zanaty (mzanaty); 'Shevach Riabtsev'; 'Herbert Thoma' Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Hello, Mo Zanaty told me "Non-IDR frames can contain I, P or B slices which can be determined by decoding the slice header" I've been reading the ISO/IEC 14496-10 (7.3.3 Slice header syntax) and googling, but I didn't find the answer I hope you can help me with this, I know I have to decode the slice header with exp-golomb algorithm to get the slice type. But how can I know the slice header size? So I can read it and pass the slice header stream to the exp-golomb algorithm. Thanks for your help!! ________________________________ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Mo Zanaty (mzanaty) Enviado el: mi?rcoles, 03 de febrero de 2010 19:58 Para: Cristina Gil; Shevach Riabtsev; Herbert Thoma CC: mp4-tech at lists.mpegif.org Asunto: Re: [Mp4-tech] Number of bytes in NAL Unit The slice header is immediately after the NAL header byte (if the NAL unit type is slice data). It is simple to decode, although you do need to understand exponential-Golomb coding which is described in H.264 (or more simply on the web/wikipedia/etc.). If all you care to decode from FU-A packets is what type of frame they carry, you only need to look at the second byte of the RTP payload (the byte after the FU-A NAL type 28) to decode the true H.264 NAL header. If the true H.264 NAL unit type is IDR, then it is all I slices, otherwise you need to decode the slice header to determine the frame type. Regards, Mo Zanaty ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 1:26 PM To: Mo Zanaty (mzanaty); 'Shevach Riabtsev'; 'Herbert Thoma' Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks Mo!! What do you mean with "slice header"? how can I get it.. do I need a decoder (like ipp or DS filter...) or can I do it reading "x" bytes of the NAL? I read in the RFC3984, i have concatenate FU-As so i can have a NAL, that means split the FU-A indicator and FU-A header and then concatenate? ________________________________ De: Mo Zanaty (mzanaty) [mailto:mzanaty at cisco.com] Enviado el: mi?rcoles, 03 de febrero de 2010 19:12 Para: Cristina Gil; Shevach Riabtsev; Herbert Thoma CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit IDR frames contain all I slices, so only decoding the NAL header is sufficient to know this. Non-IDR frames can contain I, P or B slices which can be determined by decoding the slice header. FU-A packets can contain anything, so decoding the byte after the FU-A NAL unit type (28) is required to get the true NAL unit type (0-23), which can then be decoded as IDR or non-IDR slice. Regards, Mo Zanaty ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 12:33 PM To: Mo Zanaty (mzanaty); 'Shevach Riabtsev'; 'Herbert Thoma' Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks for all your answers I appreciated them very much. Sorry Herbert, what I meant to say was RTP packet. I have packetization-mode=1 that means i can have IDR, non-IDR and FU-A (and STAP-A which I don't receive from the camera), so I will only have I and P images, do I need to decode the nal unit to know which kind of frame(s) I have or is there another way to know it? ________________________________ De: Mo Zanaty (mzanaty) [mailto:mzanaty at cisco.com] Enviado el: mi?rcoles, 03 de febrero de 2010 18:11 Para: Shevach Riabtsev; Cristina Gil CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit This depends on the "packetization-mode" of the RTP stream, which is defined in RFC3984, and indicated via SDP, not within the RTP stream itself. One RTP packet can only contain a single NAL unit if the packetization-mode is 0 or unspecified. Other packetization-mode values allow fragmentation of a single NAL unit over multiple RTP packets, and aggregation of multiple NAL units into a single RTP packet. Regards, Mo Zanaty ________________________________ From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Shevach Riabtsev Sent: Wednesday, February 03, 2010 11:06 AM To: Cristina Gil Cc: mp4-tech at lists.mpegif.org Subject: Re: [Mp4-tech] Number of bytes in NAL Unit Unfortunately I am not so familiar with RTP in order to provide reliable answer. ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 6:04 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks again for your answer!!! I have now a very silly question maybe is because of all these 0s and 1s make me feel confused... One RTP message could carry many NAL units, and each unit many type of images, right or wrong?? ________________________________ De: Shevach Riabtsev [mailto:Shevach.Riabtsev at zoran.com] Enviado el: mi?rcoles, 03 de febrero de 2010 16:15 Para: Cristina Gil CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit Cristina I define NAL unit delimiter for Annex_B compliant streams as the following regular expression - '[0]*000001' . Unfortunately the standard does not specify demarcation of NAL boundaries for streams which don't obey Annex B. Apparently RTP header does not contain NAL unit size/boundary information. If true then many trick modes (e.g. fast forward, fast resync. due to syntax errors) are unfeasible or challenging for implementations. Regards ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 4:55 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Hello, Thanks Shevach Riabtsev for your help, if me stream obeys to Annex B, my delimiter will be: - 1byte 0x00 (leading _zero_8bits) - 1byte 0x00 (zero_byte) - 3bytes 0x01 (start_code_prefix_one_3bytes) - 1byte 0x00 (trailing_zero_8bits) But I checked it and it isn't. I think my stream comes as "pure" RTP", is there another way to get the NAL size? ________________________________ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: mi?rcoles, 03 de febrero de 2010 15:05 Para: mp4-tech at lists.mpegif.org Asunto: [Mp4-tech] Number of bytes in NAL Unit Dear Cristina Gil If a stream obeys Annex B constraints then the size of NAL unit is determined by next start code. In other words the distance between the current start code and next one is actually NAL unit size. So, for determination of NAL unit size it is required to look ahead in the stream. I read the RFC3984 document which says the RTP header its 12bytes, but how can i know when the FU-As or NAL units are finished, in other words how many bytes of the RTP payload are padding (which makes the rtp packet header + payload (NAL + Padding) =1400). I read the ISO/IEC 14496 part 10: nal_unit( NumBytesInNALunit ) { forbidden_zero_bit //--->1bit nal_ref_idc //--->2bit nal_unit_type //--->5bit NumBytesInRBSP = 0 for( i = 1; i < NumBytesInNALunit; i++ ) { if( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) { rbsp_byte[ NumBytesInRBSP++ ] rbsp_byte[ NumBytesInRBSP++ ] i += 2 emulation_prevention_three_byte /* equal to 0x03 */ } else rbsp_byte[ NumBytesInRBSP++ ] } } How can i get NumBytesInNALunit? What does next_bits( 24 ) means? Regards Shevach Riabtsev Video compressionist ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. _______________________________________________ NOTE: Please use clear subject lines for your posts. Include [audio, [video], [systems], [general] or another appropriate 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 Multimedia and Software Standards, Apple Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100211/b5e915a0/attachment-0001.html From cristina.gil at sumenor.com Thu Feb 11 15:37:35 2010 From: cristina.gil at sumenor.com (Cristina Gil) Date: Thu, 11 Feb 2010 21:37:35 +0100 Subject: [Mp4-tech] Number of bytes in NAL Unit In-Reply-To: 53DA0194-C425-4F20-A4F1-AFE8F6E4D142@apple.com Message-ID: <20100211203735.b853b0dc@host1.alta-electric.com> Ok! Thanks for your answers, sorry i think i didnt explain myself properly, i dont understand very well the standard, what i mean: - frame_num is used as an identifier for pictures and shall be represented by log2_max_frame_num_minus4 + 4 bits in the bitstream. frame_num is constrained as follows: an ue(v) number plus 4 bits which are 0000?? i get from the "log2_max_frame_num_minus4" definition: log2_max_frame_num_minus4 specifies the value of the variable MaxFrameNum that is used in frame_num related derivations as follows: MaxFrameNum = 2^( log2_max_frame_num_minus4 + 4 ) The variable PrevRefFrameNum is derived as follows. --> ??? - If the current picture is an IDR picture, PrevRefFrameNum is set equal to 0. - Otherwise (the current picture is not an IDR picture), PrevRefFrameNum is set as follows - idr_pic_id identifies an IDR picture. The values of idr_pic_id in all the slices of an IDR picture shall remain unchanged. The value of idr_pic_id shall be in the range of 0 to 65535, inclusive. which is more than 4bytes to be read... where do i stop? Thanks again for all your patience... _____ From: David Singer [mailto:singer at apple.com] To: mp4-tech at lists.mpegif.org Sent: Thu, 11 Feb 2010 18:59:29 +0100 Subject: Re: [Mp4-tech] Number of bytes in NAL Unit I think the documentation of frame_num makes it clear; frame_num is used as an identifier for pictures and shall be represented by log2_max_frame_num_minus4 + 4 bits in the bitstream. in general, I think all u(v) parameters have their bit-count defined in some way. On Feb 11, 2010, at 9:11 , Cristina Gil wrote: Hello, I decoded successfully the SPS and PPS messages both are needed to get the slice header, I have probed the exp-golomb algorithm code I did its working (thanks Mo for your help!! Wireshark really helped me) but I don?t know how to get the parameters with the u(v) descriptor which are defined for the Slice Header, for example: slice_header( ) { first_mb_in_slice ? ue(v) (exp-golomb) slice_type ? ue(v) ) (exp-golomb) pic_parameter_set_id ? ue(v) ) (exp-golomb) frame_num ? u(v) ????? if( !frame_mbs_only_flag ) { field_pic_flag ? u(1) (read_bit(number of bits to be read = 1)) if( field_pic_flag ) bottom_field_flag ? u(1) (read_bit(number of bits to be read = 1)) ? How do I read u(v) parameters? Thank in advance for your help _____ De: Mo Zanaty (mzanaty) [mailto:mzanaty at cisco.com] Enviado el: jueves, 04 de febrero de 2010 21:52 Para: Cristina Gil; Shevach Riabtsev; Herbert Thoma CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit Cristina, Exp-golomb codes are inherently variable length, so there is no fixed slice header size. Just start decoding it using exp-golomb rules. Wikipedia has a very simple explanation. http://en.wikipedia.org/wiki/Exponential-Golomb_coding You can use wireshark to see how I/P/B slice type is decoded from the slice header of non-IDR slice NAL units. http://www.wireshark.org/download.html (use Development Release 1.3.2) Thanks, Mo Zanaty _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Thursday, February 04, 2010 12:02 PM To: Mo Zanaty (mzanaty); 'Shevach Riabtsev'; 'Herbert Thoma' Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Hello, Mo Zanaty told me ?Non-IDR frames can contain I, P or B slices which can be determined by decoding the slice header? I?ve been reading the ISO/IEC 14496-10 (7.3.3 Slice header syntax) and googling, but I didn?t find the answer I hope you can help me with this, I know I have to decode the slice header with exp-golomb algorithm to get the slice type. But how can I know the slice header size? So I can read it and pass the slice header stream to the exp-golomb algorithm. Thanks for your help!! _____ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Mo Zanaty (mzanaty) Enviado el: mi?rcoles, 03 de febrero de 2010 19:58 Para: Cristina Gil; Shevach Riabtsev; Herbert Thoma CC: mp4-tech at lists.mpegif.org Asunto: Re: [Mp4-tech] Number of bytes in NAL Unit The slice header is immediately after the NAL header byte (if the NAL unit type is slice data). It is simple to decode, although you do need to understand exponential-Golomb coding which is described in H.264 (or more simply on the web/wikipedia/etc.). If all you care to decode from FU-A packets is what type of frame they carry, you only need to look at the second byte of the RTP payload (the byte after the FU-A NAL type 28) to decode the true H.264 NAL header. If the true H.264 NAL unit type is IDR, then it is all I slices, otherwise you need to decode the slice header to determine the frame type. Regards, Mo Zanaty _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 1:26 PM To: Mo Zanaty (mzanaty); 'Shevach Riabtsev'; 'Herbert Thoma' Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks Mo!! What do you mean with ?slice header?? how can I get it.. do I need a decoder (like ipp or DS filter?) or can I do it reading ?x? bytes of the NAL? I read in the RFC3984, i have concatenate FU-As so i can have a NAL, that means split the FU-A indicator and FU-A header and then concatenate? _____ De: Mo Zanaty (mzanaty) [mailto:mzanaty at cisco.com] Enviado el: mi?rcoles, 03 de febrero de 2010 19:12 Para: Cristina Gil; Shevach Riabtsev; Herbert Thoma CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit IDR frames contain all I slices, so only decoding the NAL header is sufficient to know this. Non-IDR frames can contain I, P or B slices which can be determined by decoding the slice header. FU-A packets can contain anything, so decoding the byte after the FU-A NAL unit type (28) is required to get the true NAL unit type (0-23), which can then be decoded as IDR or non-IDR slice. Regards, Mo Zanaty _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 12:33 PM To: Mo Zanaty (mzanaty); 'Shevach Riabtsev'; 'Herbert Thoma' Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks for all your answers I appreciated them very much. Sorry Herbert, what I meant to say was RTP packet. I have packetization-mode=1 that means i can have IDR, non-IDR and FU-A (and STAP-A which I don?t receive from the camera), so I will only have I and P images, do I need to decode the nal unit to know which kind of frame(s) I have or is there another way to know it? _____ De: Mo Zanaty (mzanaty) [mailto:mzanaty at cisco.com] Enviado el: mi?rcoles, 03 de febrero de 2010 18:11 Para: Shevach Riabtsev; Cristina Gil CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit This depends on the ?packetization-mode? of the RTP stream, which is defined in RFC3984, and indicated via SDP, not within the RTP stream itself. One RTP packet can only contain a single NAL unit if the packetization-mode is 0 or unspecified. Other packetization-mode values allow fragmentation of a single NAL unit over multiple RTP packets, and aggregation of multiple NAL units into a single RTP packet. Regards, Mo Zanaty _____ From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Shevach Riabtsev Sent: Wednesday, February 03, 2010 11:06 AM To: Cristina Gil Cc: mp4-tech at lists.mpegif.org Subject: Re: [Mp4-tech] Number of bytes in NAL Unit Unfortunately I am not so familiar with RTP in order to provide reliable answer. _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 6:04 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Thanks again for your answer!!! I have now a very silly question maybe is because of all these 0s and 1s make me feel confused? One RTP message could carry many NAL units, and each unit many type of images, right or wrong?? _____ De: Shevach Riabtsev [mailto:Shevach.Riabtsev at zoran.com] Enviado el: mi?rcoles, 03 de febrero de 2010 16:15 Para: Cristina Gil CC: mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] Number of bytes in NAL Unit Cristina I define NAL unit delimiter for Annex_B compliant streams as the following regular expression - ?[0]*000001? . Unfortunately the standard does not specify demarcation of NAL boundaries for streams which don?t obey Annex B. Apparently RTP header does not contain NAL unit size/boundary information. If true then many trick modes (e.g. fast forward, fast resync. due to syntax errors) are unfeasible or challenging for implementations. Regards _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 03, 2010 4:55 PM To: Shevach Riabtsev Cc: mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] Number of bytes in NAL Unit Hello, Thanks Shevach Riabtsev for your help, if me stream obeys to Annex B, my delimiter will be: - 1byte 0x00 (leading _zero_8bits) - 1byte 0x00 (zero_byte) - 3bytes 0x01 (start_code_prefix_one_3bytes) - 1byte 0x00 (trailing_zero_8bits) But I checked it and it isn?t. I think my stream comes as ?pure? RTP?, is there another way to get the NAL size? _____ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: mi?rcoles, 03 de febrero de 2010 15:05 Para: mp4-tech at lists.mpegif.org Asunto: [Mp4-tech] Number of bytes in NAL Unit Dear Cristina Gil If a stream obeys Annex B constraints then the size of NAL unit is determined by next start code. In other words the distance between the current start code and next one is actually NAL unit size. So, for determination of NAL unit size it is required to look ahead in the stream. I read the RFC3984 document which says the RTP header its 12bytes, but how can i know when the FU-As or NAL units are finished, in other words how many bytes of the RTP payload are padding (which makes the rtp packet header + payload (NAL + Padding) =1400). I read the ISO/IEC 14496 part 10: nal_unit( NumBytesInNALunit ) { forbidden_zero_bit //--->1bit nal_ref_idc //--->2bit nal_unit_type //--->5bit NumBytesInRBSP = 0 for( i = 1; i < NumBytesInNALunit; i++ ) { if( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) { rbsp_byte[ NumBytesInRBSP++ ] rbsp_byte[ NumBytesInRBSP++ ] i += 2 emulation_prevention_three_byte /* equal to 0x03 */ } else rbsp_byte[ NumBytesInRBSP++ ] } } How can i get NumBytesInNALunit? What does next_bits( 24 ) means? Regards Shevach Riabtsev Video compressionist _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. _______________________________________________ NOTE: Please use clear subject lines for your posts. Include [audio, [video], [systems], [general] or another appropriate 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 Multimedia and Software Standards, Apple Inc. AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100211/0eb7a67f/attachment-0001.html From ranjani.hg at ittiam.com Thu Feb 11 06:44:44 2010 From: ranjani.hg at ittiam.com (Ranjani H G) Date: Thu, 11 Feb 2010 17:14:44 +0530 Subject: [Mp4-tech] [Audio] MPEG Surround decoder conformance testing Message-ID: <904DEC693BE1AB429622C6F5ABA7E0B8070FFEE8@is01ex02.ittiam.com> Hi all, I am using MPEG Surround decoder reference software version 1.10. For the MPEG Surround decoder conformance testing, the outputs of the above decoder are not bit-exact with the reference wave files provided at ftp://mpaudconf:adif2mp4 at ftp.iis.fraunhofer.de/mpegDmps-conformance/. Can I know what could be reason? And, from which version of the MPEG Surround decoder are the reference wave files generated? Regards, Ranjani _________________________________________________________________________________________________________________________________________________________ Please do not print this email unless it is absolutely necessary. This email and any files transmitted with it are confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this e-mail is prohibited. If you have received this information in error, please notify the sender immediately and destroy all copies of this message and any attachments. Warning: Computer viruses can be transmitted via email. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed or incomplete. The recipient should check this email and any attachments for the presence of viruses. Ittiam therefore does not accept any liability for damage caused by virus, errors or omissions in the content, which may arise as a result of e-mail transmission. www.ittiam.com -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100211/06c9405a/attachment.html From dirosen at optonline.net Thu Feb 11 10:29:59 2010 From: dirosen at optonline.net (Dan Rosen) Date: Thu, 11 Feb 2010 10:29:59 -0500 Subject: [Mp4-tech] Suggestions for maximum pic_order_count and frame nums. In-Reply-To: References: <9F40F319D2AB48DA8C94660C5CCE9130@SUMENORSCS.LOCAL> Message-ID: <003001caab2f$1422d480$3c687d80$@net> I'm curious if there's any logic on setting the values for log2_max_frame_num_minus4 and log2_max_pic_order_cnt_lsb_minus4. Since the reference lists are limited to 32 frames, is there any reason to have either of these values exceed 1 i.e. 2^(4+1)? Thanks, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100211/8fb50401/attachment.html From michael.haertl at iis.fraunhofer.de Fri Feb 12 13:22:11 2010 From: michael.haertl at iis.fraunhofer.de (Michael Haertl) Date: Fri, 12 Feb 2010 19:22:11 +0100 Subject: [Mp4-tech] [Audio] MPEG Surround decoder conformance testing In-Reply-To: <904DEC693BE1AB429622C6F5ABA7E0B8070FFEE8@is01ex02.ittiam.com> References: <904DEC693BE1AB429622C6F5ABA7E0B8070FFEE8@is01ex02.ittiam.com> Message-ID: <4B759C53.5060303@iis.fraunhofer.de> hi Ranjani, Ranjani H G wrote: > Hi all, > > I am using MPEG Surround decoder reference software version 1.10. > > For the MPEG Surround decoder conformance testing, the outputs of the > above decoder are not bit-exact with the reference wave files provided > at ftp://mpaudconf:adif2mp4 at ftp.iis.fraunhofer.de/mpegDmps-conformance/. > > Can I know what could be reason? You said "not bit-exact", so the difference seems to be pretty small ? Different compilers with different optimization can produce differences in the LSB range. > And, from which version of the MPEG Surround decoder are the reference > wave files generated? Sorry, I don't know. > Regards, > Ranjani Best regards, Michael -- /* Michael Haertl, Fraunhofer IIS http://www.iis.fraunhofer.de/amm */ From garysull at microsoft.com Fri Feb 12 13:34:17 2010 From: garysull at microsoft.com (Gary Sullivan) Date: Fri, 12 Feb 2010 18:34:17 +0000 Subject: [Mp4-tech] Suggestions for maximum pic_order_count and frame nums. In-Reply-To: <003001caab2f$1422d480$3c687d80$@net> References: <9F40F319D2AB48DA8C94660C5CCE9130@SUMENORSCS.LOCAL> <003001caab2f$1422d480$3c687d80$@net> Message-ID: Dan Rosen et al, Loss resilience is a very good reason to use larger values for those parameters. Their primary purpose is really not just for reference list construction. Using a large value can help prevent the decoder from getting confused in lossy situations (and perhaps for random access or other "trick mode" uses). In most situations, the quantity of extra bits consumed by using larger values for those parameters is negligible, and there can be a benefit to having a longer-term ability to confidently track the position of pictures in the coded video sequence. Also, you should keep in mind that people don't always use the sliding window reference picture marking mode. MaxFrameNum affects how long a picture can stay in the DPB marked as "used for short-term reference". And MaxPicOrderCntLsb affects the degree of allowed reordering of output pictures. Actually the limit on maximum reference list size is 16 frames, not 32. And when picture sizes are large (relative to the effective Level) the limit is much smaller (2-6 frames at maximum allowed picture size, depending on the Level). Best Regards, Gary Sullivan From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Dan Rosen Sent: Thursday, February 11, 2010 7:30 AM To: mp4-tech at lists.mpegif.org Subject: [Mp4-tech] Suggestions for maximum pic_order_count and frame nums. I'm curious if there's any logic on setting the values for log2_max_frame_num_minus4 and log2_max_pic_order_cnt_lsb_minus4. Since the reference lists are limited to 32 frames, is there any reason to have either of these values exceed 1 i.e. 2^(4+1)? Thanks, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100212/0e0ff60c/attachment.html From resmi.rajendran at gmail.com Mon Feb 15 01:44:57 2010 From: resmi.rajendran at gmail.com (Resmi Ashok) Date: Mon, 15 Feb 2010 12:14:57 +0530 Subject: [Mp4-tech] [Audio] MPEG Surround decoder conformance testing In-Reply-To: <4B759C53.5060303@iis.fraunhofer.de> References: <904DEC693BE1AB429622C6F5ABA7E0B8070FFEE8@is01ex02.ittiam.com> <4B759C53.5060303@iis.fraunhofer.de> Message-ID: Hi, I doubt it may be due to IDCT implementation difference as in MPEG-4. If the pixel difference is only +/-1 for I frames, it is definitely due to this. The output from different decoders need not bit-match for MPEG-4, it only needs to be within this range. Regards, Resmi On Fri, Feb 12, 2010 at 11:52 PM, Michael Haertl < michael.haertl at iis.fraunhofer.de> wrote: > hi Ranjani, > > Ranjani H G wrote: > > Hi all, > > > > I am using MPEG Surround decoder reference software version 1.10. > > > > For the MPEG Surround decoder conformance testing, the outputs of the > > above decoder are not bit-exact with the reference wave files provided > > at ftp://mpaudconf:adif2mp4 at ftp.iis.fraunhofer.de/mpegDmps-conformance/. > > > > Can I know what could be reason? > > You said "not bit-exact", so the difference seems to be pretty small ? > Different compilers with different optimization can produce differences > in the LSB range. > > > And, from which version of the MPEG Surround decoder are the reference > > wave files generated? > > Sorry, I don't know. > > > Regards, > > Ranjani > > Best regards, > Michael > > -- > /* Michael Haertl, Fraunhofer IIS > http://www.iis.fraunhofer.de/amm */ > _______________________________________________ > NOTE: Please use clear subject lines for your posts. Include [audio, > [video], [systems], [general] or another appropriate 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/20100215/eae2e84f/attachment.html From dirosen at optonline.net Fri Feb 12 14:05:14 2010 From: dirosen at optonline.net (Dan Rosen) Date: Fri, 12 Feb 2010 14:05:14 -0500 Subject: [Mp4-tech] Suggestions for maximum pic_order_count and frame nums. In-Reply-To: References: <9F40F319D2AB48DA8C94660C5CCE9130@SUMENORSCS.LOCAL> <003001caab2f$1422d480$3c687d80$@net> Message-ID: <006301caac16$4f6d46a0$ee47d3e0$@net> Can you explain this? << MaxFrameNum affects how long a picture can stay in the DPB marked as "used for short-term reference". >> In reading the H.264 standard its not clear to me whether the short-term reference lists keep track of the frame number or are just have their own index. Even though the max for a short-term reference is 16 frames, can't reflist[0] and reflist[1] contain different frames in effect doubling the number of reference frames from 16 to 32 ( or whatever the max is for the level)? Thanks, Dan From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Gary Sullivan Sent: Friday, February 12, 2010 1:34 PM To: Dan Rosen; mp4-tech at lists.mpegif.org Subject: Re: [Mp4-tech] Suggestions for maximum pic_order_count and frame nums. Dan Rosen et al, Loss resilience is a very good reason to use larger values for those parameters. Their primary purpose is really not just for reference list construction. Using a large value can help prevent the decoder from getting confused in lossy situations (and perhaps for random access or other "trick mode" uses). In most situations, the quantity of extra bits consumed by using larger values for those parameters is negligible, and there can be a benefit to having a longer-term ability to confidently track the position of pictures in the coded video sequence. Also, you should keep in mind that people don't always use the sliding window reference picture marking mode. MaxFrameNum affects how long a picture can stay in the DPB marked as "used for short-term reference". And MaxPicOrderCntLsb affects the degree of allowed reordering of output pictures. Actually the limit on maximum reference list size is 16 frames, not 32. And when picture sizes are large (relative to the effective Level) the limit is much smaller (2-6 frames at maximum allowed picture size, depending on the Level). Best Regards, Gary Sullivan From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Dan Rosen Sent: Thursday, February 11, 2010 7:30 AM To: mp4-tech at lists.mpegif.org Subject: [Mp4-tech] Suggestions for maximum pic_order_count and frame nums. I'm curious if there's any logic on setting the values for log2_max_frame_num_minus4 and log2_max_pic_order_cnt_lsb_minus4. Since the reference lists are limited to 32 frames, is there any reason to have either of these values exceed 1 i.e. 2^(4+1)? Thanks, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100212/fbaba220/attachment.html From garysull at microsoft.com Mon Feb 15 03:28:03 2010 From: garysull at microsoft.com (Gary Sullivan) Date: Mon, 15 Feb 2010 08:28:03 +0000 Subject: [Mp4-tech] Suggestions for maximum pic_order_count and frame nums. In-Reply-To: <006301caac16$4f6d46a0$ee47d3e0$@net> References: <9F40F319D2AB48DA8C94660C5CCE9130@SUMENORSCS.LOCAL> <003001caab2f$1422d480$3c687d80$@net> <006301caac16$4f6d46a0$ee47d3e0$@net> Message-ID: <0ABA7B9B054CF94BA95E013D1EE0DBDA02D144@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> Dan Rosen et al, The way that the reference picture lists are constructed from the pictures that are in the DPB marked as "used for short-term reference" is based on their frame_num value (see 8.2.4). (I'm neglecting the consideration of coded fields in the next paragraphs for the sake of simplifying this discussion - the concepts are analogous, but going into that extra level of detail would be confusing and time-consuming.) The value of frame_num increments by 1 (or possibly more, if gaps_in_frame_num_value_allowed_flag is equal to 1) after each reference frame arrives, modulo MaxFrameNum. When a new frame arrives, there cannot be another old picture still sitting in the DPB that has the same frame_num value that it has (or any other value between the value of frame_num for the previous reference picture and the value for the new arriving frame). See the subclause 7.4.3 semantics surrounding the variables PrevRefFrameNum and UnusedShortTermFrameNum. So there is a limit on how long a picture can sit in the DPB marked as "used for short-term reference" - because eventually the frame_num value will roll around past its value again, and when that happens, that picture is not allowed to still be sitting there anymore. Most of that only matters when the "adaptive memory control decoded reference picture marking process" is being used by the encoder, because if the "sliding window decoded reference picture marking process" is being used, the FIFO sliding window will kick out the old picture long before its frame_num value rolls around again. As for the other issue - No, the encoder can't use the fact that there are two reference picture lists as a way to get around the limit of 16 frames (or fewer, depending on the frame size and the bitstream Level) for maximum DPB capacity. The maximum number of reference frames that the decoder can ever be holding onto for referencing purposes is given by the syntax element max_num_ref_frames. It cannot have a value that exceeds max_dec_frame_buffering, and max_dec_frame_buffering cannot have a value that exceeds MaxDpbFrames, and MaxDpbFrames cannot have a value that exceeds 16 (or fewer, depending on the frame size and the bitstream Level - see A.3.1 item h and A.3.2 item f). So the total number of frames that are ever sitting in the DPB marked as "used for reference" at any given moment cannot ever exceed 16 (and when the frame size is relatively large for the Level, the limit is smaller). Having two reference picture lists has no effect whatsoever on the required storage capacity - those two lists are just two different ways of indexing into the same pool of stored reference pictures. Footnote: If you're looking at an older version of the spec, a couple of those syntax elements may have had slightly different names (without the "max_" at the beginning) and some of the constraints relating to those syntax elements may have been expressed a little differently, although they were the same in principle. Best Regards, Gary Sullivan From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Dan Rosen Sent: Friday, February 12, 2010 11:05 AM To: mp4-tech at lists.mpegif.org Subject: Re: [Mp4-tech] Suggestions for maximum pic_order_count and frame nums. Can you explain this? << MaxFrameNum affects how long a picture can stay in the DPB marked as "used for short-term reference". >> In reading the H.264 standard its not clear to me whether the short-term reference lists keep track of the frame number or are just have their own index. Even though the max for a short-term reference is 16 frames, can't reflist[0] and reflist[1] contain different frames in effect doubling the number of reference frames from 16 to 32 ( or whatever the max is for the level)? Thanks, Dan From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Gary Sullivan Sent: Friday, February 12, 2010 1:34 PM To: Dan Rosen; mp4-tech at lists.mpegif.org Subject: Re: [Mp4-tech] Suggestions for maximum pic_order_count and frame nums. Dan Rosen et al, Loss resilience is a very good reason to use larger values for those parameters. Their primary purpose is really not just for reference list construction. Using a large value can help prevent the decoder from getting confused in lossy situations (and perhaps for random access or other "trick mode" uses). In most situations, the quantity of extra bits consumed by using larger values for those parameters is negligible, and there can be a benefit to having a longer-term ability to confidently track the position of pictures in the coded video sequence. Also, you should keep in mind that people don't always use the sliding window reference picture marking mode. MaxFrameNum affects how long a picture can stay in the DPB marked as "used for short-term reference". And MaxPicOrderCntLsb affects the degree of allowed reordering of output pictures. Actually the limit on maximum reference list size is 16 frames, not 32. And when picture sizes are large (relative to the effective Level) the limit is much smaller (2-6 frames at maximum allowed picture size, depending on the Level). Best Regards, Gary Sullivan From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Dan Rosen Sent: Thursday, February 11, 2010 7:30 AM To: mp4-tech at lists.mpegif.org Subject: [Mp4-tech] Suggestions for maximum pic_order_count and frame nums. I'm curious if there's any logic on setting the values for log2_max_frame_num_minus4 and log2_max_pic_order_cnt_lsb_minus4. Since the reference lists are limited to 32 frames, is there any reason to have either of these values exceed 1 i.e. 2^(4+1)? Thanks, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100215/4b6b1e23/attachment-0001.html From cristina.gil at sumenor.com Mon Feb 15 09:56:19 2010 From: cristina.gil at sumenor.com (Cristina Gil) Date: Mon, 15 Feb 2010 15:56:19 +0100 Subject: [Mp4-tech] NAL Unit slice header/data In-Reply-To: <0AE1CEBE-0B2D-42E4-A1B4-A4C8EF428AA5@apple.com> References: <20100211220047.17cdaf5f@host1.alta-electric.com> <7895822D-530C-4691-A78C-E3EE509EB03B@apple.com> <0AE1CEBE-0B2D-42E4-A1B4-A4C8EF428AA5@apple.com> Message-ID: <28D3CAD7E1DD4C11A69F239628753E44@SUMENORSCS.LOCAL> Hello, >From SDP message I get packetization mode 1 so I will have in FU-A IDR images type I and in FU-A non-IDR type I and P (I also have baseline profile) and so on. Please correct me if im wrong: A RTP message could have many NAL units A FU-A unit only have a part of the NAL unit In the standard: slice_layer_without_partitioning_rbsp( ) { slice_header( ) slice_data( ) rbsp_slice_trailing_bits( ) } So, its only ONE slice header and MULTIPLE pictures coded in ONE slice data?? If this is true, I have to parse the slice data in order to get each picture, haven't i? Thanks in advance for your help. AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100215/ce000303/attachment.html From dmitriy at graphics.cs.msu.ru Mon Feb 15 16:47:31 2010 From: dmitriy at graphics.cs.msu.ru (Dmitriy Vatolin) Date: Tue, 16 Feb 2010 00:47:31 +0300 Subject: [Mp4-tech] CALL FOR MPEG4-AVC/H.264 CODECS - last chance In-Reply-To: <1976396892.20100109005505@graphics.cs.msu.ru> References: <1976396892.20100109005505@graphics.cs.msu.ru> Message-ID: <662537149.20100216004731@graphics.cs.msu.ru> Dear Experts, H.264 Comparison 2010 codecs submission deadline last time extended to February 18, 2010. * Please appease your managers: We understand that only few real leaders are interested in results publication. But also partial and private participation is possible. So you can show results only in those nominations where results of your codec satisfy you. * Developers provide us pretty fresh versions sometimes essentially better, than publicly available from site for purchase (we cross-check this). So you can compare you codec not only with old version available from site (and pretty good for complacency :), but with pretty fresh versions, that will be available several month later. * Please do not worry about potential bugs in hot builds - in case of crashes or another obvious problems you will have time (a week) to provide us updated fixed versions and all results will be remeasured. If even now you are afraid about quality of you codec, that there are no reason to compare - please let us know. We are interested in bigger number of good codecs and can measure weak and strong points of your codec to help you tune it efficiently. If you think, that all objective measures are obsolete in XXI century and your codec essentially tuned for visual results - please let us know. We plan to include visual comparison of codecs with turned on and off psychovisual options. If you have another reason to avoid external evaluation please let us know - this is VERY interesting! Please contact videocodec-testing at graphics.cs.msu.ru ================8<==============Original message text=============== As usual Moscow State University Graphics & Multimedia Laboratory starts next 6-th H.264 codecs comparison. Most interesting features this year: * Objective comparison will be extended with subjective with leading codecs visual comparison. Also will be testes psycho-visual options and visual quality during fade effects. * We release system of extensive tests of codecs with improper interface (like GUI only). ALL available options of such codecs will be tested, so option choice for comparison will be correct now. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! If you want to see some codec in our comparison - please let us know! We will summarize votes and will add the most interesting codecs. Please write us now. This can be not only H.264, but also VC-1 or another (even proprietary). !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Below is information for codec developers: =========================================================================== CALL FOR MPEG4-AVC/H.264 CODECS Sixth H.264 video codec comparison For practical researchers and developers in the field of high-end video compression =========================================================================== Scope of Test ------------- * Encoding time, speed/quality analysis * Objective quality measurements (PSNR, SSIM, Average Advantage, etc.) * Analysis of averaged objective results * Leaders in different areas Important Dates --------------- February,18 - Deadline for receipt of a H.264 codec with required presets March, 2 - Deadline for settling technical problems with codec?s functioning March, 24 - Draft version of report that will be sent to all participants April, 1 - Deadline for reception of comments to the draft April, 7 - Comparison report release Enhancements in comparison to Previous H.264/AVC Comparison ----------------------------------------------------------- This comparison will includes some new features, that previous comparisons do not include * Subjective comparison for the codes * More codecs - we will include codecs available from the Internet and will choose optimal presets by Option Analysis * Comparison between Pareto optimal presets between different codecs * Effectiveness analysis of some encoder options (see example at Options Analysis of MPEG-4 AVC/H.264 Codec x264) http://compression.ru/video/codec_comparison/x264_options_analysis_08_en.html * New video sequences Developer Deliverables ---------------------- The following deliverables should be provided by each developer: * Codec files (CLI executable file is preferable) * Short description of codec parameters * Codec's presets with mentioning what H.264/AVC profiles are used The full text of Call for Codecs is available at http://compression.ru/video/codec_comparison/call_for_codecs_10.html Variants of Participation ------------------------- There are two variants for companies to participate in our comparison: 1. Participation for free. All results of your codec will be published, except special cases of measurements problems due to codec instability. 2. Private participation. A special report will be prepared only for your company. This report contains: * Your codec results and all material from the free version * Special additional analysis of your codec If you are interested in the private participation, please contact us for details. Also codec can be added into comparison by votes of professional auditory. Useful Links ------------ * Call for codecs-2010 http://compression.ru/video/codec_comparison/call_for_codecs_10.html * Fifth Annual MSU MPEG-4 AVC/H.264 Video Codec Comparison http://www.compression.ru/video/codec_comparison/mpeg-4_avc_h264_2009_en.html * Options Analysis of MPEG-4 AVC/H.264 Codec x264 http://compression.ru/video/codec_comparison/x264_options_analysis_08_en.html Sincerely yours, Dr. Vatolin ===8<===========End of original message text=========== Sincerely yours, Dr. Vatolin From smurti1983 at gmail.com Mon Feb 15 21:09:52 2010 From: smurti1983 at gmail.com (Seethal Paluri) Date: Mon, 15 Feb 2010 18:09:52 -0800 Subject: [Mp4-tech] Extract Motion Vectors Message-ID: Hi Experts, I am trying to extract Motion Vectors from JM 14.2 Encoder. If my understanding is correct, for every Macroblock, the codec evaluates the RD cost to encode the MB and chooses the best_mode (which corresponds to the smallest cost). So for a single MB, it will evaluate RD cost for 16x16, 16x8, 8x16, 8x8, 8x4, 4x8, 4x4. *My question is, where is the best place to extract the Motion Vectors for each MB/ each sub partition? * In the function *set_stored_macroblock_parameters()* there is a function * SetMotionVectorsMB()* which stores the motion vectors belonging to the best_mode. However, it looks like no matter the best_mode type, the motion vectors are stored for each 4x4 sub partition. So even if the best_mode is 16x8 ( 2MVs), I will still have 16 (4x4 MVs). Am I interpreting this correctly? Also, I read that the encoder only transmits the difference between the predicted and computed motion vectors. Does, this mean that the MVs stored through *set_stored_macroblock_parameters*() are the difference between the computed MVs and the Predicted MVs or are they the actual MVs of the MB? Also, for *PartitionMotionSearch*() (16x16, 16x8 and 8x16 modes), calculates the MVs to 1/4 pixel accuracy. Would it be reasonable if I just extract the MVs from *assign_enc_picture_parms* or *SetRefMotionVectors as *i*t is easier.* For the remaining mode, submacroblock_mode_decision() will perform the ME and generate MV. Where would the best place be to extract MVs? Thank you, Smruti -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100215/a3cd2a28/attachment.html From rossellafortuna at libero.it Tue Feb 16 10:55:25 2010 From: rossellafortuna at libero.it (Rossella Fortuna) Date: Tue, 16 Feb 2010 16:55:25 +0100 Subject: [Mp4-tech] FGS mpeg-4 codec Message-ID: <4B7ABFED.2000504@libero.it> Hi all could you suggest me a free, open source FGS mpeg-4 codec, possibily running on linux? I'm searching for a codec in which error concealment has been implemented. I was using JSVM but decoder crashes if an IDR frame gets lost during video transmission. Thank you so much RF From smurti1983 at gmail.com Tue Feb 16 11:48:40 2010 From: smurti1983 at gmail.com (Seethal Paluri) Date: Tue, 16 Feb 2010 08:48:40 -0800 Subject: [Mp4-tech] How to extract Motion vectors from JM 14.2 encoder Message-ID: Hi Experts, I am trying to extract Motion Vectors from JM 14.2 Encoder. If my understanding is correct, for every Macroblock, the codec evaluates the RD cost to encode the MB and chooses the best_mode (which corresponds to the smallest cost). So for a single MB, it will evaluate RD cost for 16x16, 16x8, 8x16, 8x8, 8x4, 4x8, 4x4. *My question is, where is the best place to extract the Motion Vectors for each MB/ each sub partition? * In the function *set_stored_macroblock_parameters()* there is a function * SetMotionVectorsMB()* which stores the motion vectors belonging to the best_mode. However, it looks like no matter the best_mode type, the motion vectors are stored for each 4x4 sub partition. So even if the best_mode is 16x8 ( 2MVs), I will still have 16 (4x4 MVs). Am I interpreting this correctly? Also, I read that the encoder only transmits the difference between the predicted and computed motion vectors. Does, this mean that the MVs stored through *set_stored_macroblock_parameters*() are the difference between the computed MVs and the Predicted MVs or are they the actual MVs of the MB? Also, for *PartitionMotionSearch*() (16x16, 16x8 and 8x16 modes), calculates the MVs to 1/4 pixel accuracy. Would it be reasonable if I just extract the MVs from *assign_enc_picture_parms* or *SetRefMotionVectors as *i*t is easier.* For the remaining mode, submacroblock_mode_decision() will perform the ME and generate MV. Where would the best place be to extract MVs? Thank you, Smruti -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100216/87b78f5d/attachment.html From Shevach.Riabtsev at zoran.com Tue Feb 16 12:03:51 2010 From: Shevach.Riabtsev at zoran.com (Shevach Riabtsev) Date: Tue, 16 Feb 2010 19:03:51 +0200 Subject: [Mp4-tech] NAL Unit slice header/data Message-ID: <91C4B16D6D58C541BF2F841D27F8253601A9188D@zmlex.zml.zoran.com> Cristine, Actually multiple slices composes a single picture or a picture can be divided into multiple slices. In order to find start picture it is not needed to parse slice data. You can look for start code then according to nal_unit_type you can determined whether a current NAL unit is slice or not. If the current NAL is slice and the syntax element fisrt_mb_in_slice is 0 then the current NAL unit is picture start. Notice that in Baseline profile the above trick does not work due to ASO. Regards Shevach Riabtsev Video compressionist So, its only ONE slice header and MULTIPLE pictures coded in ONE slice data?? If this is true, I have to parse the slice data in order to get each picture, haven't i? -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100216/1021feec/attachment.html From cristina.gil at sumenor.com Tue Feb 16 13:03:15 2010 From: cristina.gil at sumenor.com (Cristina Gil) Date: Tue, 16 Feb 2010 19:03:15 +0100 Subject: [Mp4-tech] NAL Unit slice header/data In-Reply-To: <91C4B16D6D58C541BF2F841D27F8253601A9188D@zmlex.zml.zoran.com> References: <91C4B16D6D58C541BF2F841D27F8253601A9188D@zmlex.zml.zoran.com> Message-ID: Thanks Shevach! Could you please explain me a little bit: "If the current NAL is slice and the syntax element fisrt_mb_in_slice is 0 then the current NAL unit is picture start. Notice that in Baseline profile the above trick does not work due to ASO." I read from the standard: "baseline profile: NAL unit streams shall not contain nal_unit_type values in the range of 2 to 4, inclusive" and "Main profile: Arbitrary slice order is not allowed", so when I get a nal_unit_type 1 (non IDR) or 5 (IDR) and first_mb_in_slice = 0, I could say it's the first slice of the image and when I get another NAL unit with the same parameters nal_unit_type=1 or =5 and first_mb_in_slice = 0 it's a new picture?? I have checked from the stream I get and the NAL Units are idr/non-idr and fu-a and the slice header is always first_mb_in_slice = 0. for each packet I get with first_mb_in_slice = 0 im getting the picture start, don't i? this confuse me a little bit... And about FU-As.. I read from the RFC3984 document, as they are fragmented units I have to concatenate them. So, the start bit will tell me the NAL unit contains the slice data, til the next FU-A (start) I only have to remove FU-A indicator-header and concatenate (checking the timestamp) to the last one. _____ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: martes, 16 de febrero de 2010 18:04 Para: mp4-tech at lists.mpegif.org Asunto: [Mp4-tech] NAL Unit slice header/data Cristine, Actually multiple slices composes a single picture or a picture can be divided into multiple slices. In order to find start picture it is not needed to parse slice data. You can look for start code then according to nal_unit_type you can determined whether a current NAL unit is slice or not. If the current NAL is slice and the syntax element fisrt_mb_in_slice is 0 then the current NAL unit is picture start. Notice that in Baseline profile the above trick does not work due to ASO. Regards Shevach Riabtsev Video compressionist So, its only ONE slice header and MULTIPLE pictures coded in ONE slice data?? If this is true, I have to parse the slice data in order to get each picture, haven't i? AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100216/654c126c/attachment.html From Shevach.Riabtsev at zoran.com Wed Feb 17 04:14:35 2010 From: Shevach.Riabtsev at zoran.com (Shevach Riabtsev) Date: Wed, 17 Feb 2010 11:14:35 +0200 Subject: [Mp4-tech] NAL Unit slice header/data In-Reply-To: References: <91C4B16D6D58C541BF2F841D27F8253601A9188D@zmlex.zml.zoran.com> Message-ID: <91C4B16D6D58C541BF2F841D27F8253601A9188E@zmlex.zml.zoran.com> Cristina Nal_unit_type equal 1 or 5 specify picture data, all other NAL units are SPS,PPS, SEI messages and so on (with exception of data partitioning, but data partitioning is not popular feature in H264). Each picture can consist of a variable number of NAL units or slices. Notice also that the standard disallows to insert NAL units other than 1 or 5 within picture data. I provide a pseudo-code for detection of start picture (with assumption that profile is not Baseline and data partitioning is not used): Int DetectStartPicture() { // read first byte after Start Code (0x000001) from the stream, in case of RFC read first byte of NAL unit. Byte=ReadByte() // pick nal_unit_type Nal_unit_type=byte & 0x1F If(nal_unit_type==1 or nal_unit_type==5) { // current NAL contains picture data // determine whether current NAL is the first NAL of current picture // read single bit in order to determine whether first_mb_in_slice is zero or not Bit=PeekOneBit() If (bit==1) Return 1 // in exp-Golomb if first bit is one then code-word is zero } // else current NAL is SPS,PPS and so on Return 0 } Regards ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Tuesday, February 16, 2010 8:03 PM To: Shevach Riabtsev; mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] NAL Unit slice header/data Thanks Shevach! Could you please explain me a little bit: "If the current NAL is slice and the syntax element fisrt_mb_in_slice is 0 then the current NAL unit is picture start. Notice that in Baseline profile the above trick does not work due to ASO." I read from the standard: "baseline profile: NAL unit streams shall not contain nal_unit_type values in the range of 2 to 4, inclusive" and "Main profile: Arbitrary slice order is not allowed", so when I get a nal_unit_type 1 (non IDR) or 5 (IDR) and first_mb_in_slice = 0, I could say it's the first slice of the image and when I get another NAL unit with the same parameters nal_unit_type=1 or =5 and first_mb_in_slice = 0 it's a new picture?? I have checked from the stream I get and the NAL Units are idr/non-idr and fu-a and the slice header is always first_mb_in_slice = 0... for each packet I get with first_mb_in_slice = 0 im getting the picture start, don't i? this confuse me a little bit....... And about FU-As.. I read from the RFC3984 document, as they are fragmented units I have to concatenate them. So, the start bit will tell me the NAL unit contains the slice data, til the next FU-A (start) I only have to remove FU-A indicator-header and concatenate (checking the timestamp) to the last one. ________________________________ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: martes, 16 de febrero de 2010 18:04 Para: mp4-tech at lists.mpegif.org Asunto: [Mp4-tech] NAL Unit slice header/data Cristine, Actually multiple slices composes a single picture or a picture can be divided into multiple slices. In order to find start picture it is not needed to parse slice data. You can look for start code then according to nal_unit_type you can determined whether a current NAL unit is slice or not. If the current NAL is slice and the syntax element fisrt_mb_in_slice is 0 then the current NAL unit is picture start. Notice that in Baseline profile the above trick does not work due to ASO. Regards Shevach Riabtsev Video compressionist So, its only ONE slice header and MULTIPLE pictures coded in ONE slice data?? If this is true, I have to parse the slice data in order to get each picture, haven't i? ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100217/f952fbe6/attachment-0001.html From cristina.gil at sumenor.com Wed Feb 17 06:58:28 2010 From: cristina.gil at sumenor.com (Cristina Gil) Date: Wed, 17 Feb 2010 12:58:28 +0100 Subject: [Mp4-tech] NAL Unit slice header/data In-Reply-To: <91C4B16D6D58C541BF2F841D27F8253601A9188E@zmlex.zml.zoran.com> References: <91C4B16D6D58C541BF2F841D27F8253601A9188D@zmlex.zml.zoran.com> <91C4B16D6D58C541BF2F841D27F8253601A9188E@zmlex.zml.zoran.com> Message-ID: <4EDE8CD81F93443AAB2598510ED036B3@SUMENORSCS.LOCAL> Thanks Shevach for your help, this mailing list is really helping me! I have baseline profile, so it will be more difficult but now I don?t understand if I read the start packet of a FU-A (i.e non idr NAL type) and the slice header is marked with first_mb_in_slice = 0, what does it mean? Sorry if I insist on this question but I don?t understand what this parameter tells me. Another doubt If the RTP padding field is equal to zero and I get the last byte of the NAL unit that should have the rbsp trailing bits. Does the last byte must have a ..xx10xx (rbsp_stop_one_bit + rbsp_alignment_zero_bit)? _____ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: mi?rcoles, 17 de febrero de 2010 10:15 Para: Cristina Gil; mp4-tech at lists.mpegif.org Asunto: Re: [Mp4-tech] NAL Unit slice header/data Cristina Nal_unit_type equal 1 or 5 specify picture data, all other NAL units are SPS,PPS, SEI messages and so on (with exception of data partitioning, but data partitioning is not popular feature in H264). Each picture can consist of a variable number of NAL units or slices. Notice also that the standard disallows to insert NAL units other than 1 or 5 within picture data. I provide a pseudo-code for detection of start picture (with assumption that profile is not Baseline and data partitioning is not used): Int DetectStartPicture() { // read first byte after Start Code (0x000001) from the stream, in case of RFC read first byte of NAL unit. Byte=ReadByte() // pick nal_unit_type Nal_unit_type=byte & 0x1F If(nal_unit_type==1 or nal_unit_type==5) { // current NAL contains picture data // determine whether current NAL is the first NAL of current picture // read single bit in order to determine whether first_mb_in_slice is zero or not Bit=PeekOneBit() If (bit==1) Return 1 // in exp-Golomb if first bit is one then code-word is zero } // else current NAL is SPS,PPS and so on Return 0 } Regards _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Tuesday, February 16, 2010 8:03 PM To: Shevach Riabtsev; mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] NAL Unit slice header/data Thanks Shevach! Could you please explain me a little bit: ?If the current NAL is slice and the syntax element fisrt_mb_in_slice is 0 then the current NAL unit is picture start. Notice that in Baseline profile the above trick does not work due to ASO.? I read from the standard: ?baseline profile: NAL unit streams shall not contain nal_unit_type values in the range of 2 to 4, inclusive? and ?Main profile: Arbitrary slice order is not allowed?, so when I get a nal_unit_type 1 (non IDR) or 5 (IDR) and first_mb_in_slice = 0, I could say it?s the first slice of the image and when I get another NAL unit with the same parameters nal_unit_type=1 or =5 and first_mb_in_slice = 0 it?s a new picture?? I have checked from the stream I get and the NAL Units are idr/non-idr and fu-a and the slice header is always first_mb_in_slice = 0 for each packet I get with first_mb_in_slice = 0 im getting the picture start, don?t i? this confuse me a little bit . And about FU-As.. I read from the RFC3984 document, as they are fragmented units I have to concatenate them. So, the start bit will tell me the NAL unit contains the slice data, til the next FU-A (start) I only have to remove FU-A indicator-header and concatenate (checking the timestamp) to the last one. _____ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: martes, 16 de febrero de 2010 18:04 Para: mp4-tech at lists.mpegif.org Asunto: [Mp4-tech] NAL Unit slice header/data Cristine, Actually multiple slices composes a single picture or a picture can be divided into multiple slices. In order to find start picture it is not needed to parse slice data. You can look for start code then according to nal_unit_type you can determined whether a current NAL unit is slice or not. If the current NAL is slice and the syntax element fisrt_mb_in_slice is 0 then the current NAL unit is picture start. Notice that in Baseline profile the above trick does not work due to ASO. Regards Shevach Riabtsev Video compressionist So, its only ONE slice header and MULTIPLE pictures coded in ONE slice data?? If this is true, I have to parse the slice data in order to get each picture, haven't i? _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100217/ed58a899/attachment-0001.html From Shevach.Riabtsev at zoran.com Wed Feb 17 08:21:02 2010 From: Shevach.Riabtsev at zoran.com (Shevach Riabtsev) Date: Wed, 17 Feb 2010 15:21:02 +0200 Subject: [Mp4-tech] NAL Unit slice header/data In-Reply-To: <4EDE8CD81F93443AAB2598510ED036B3@SUMENORSCS.LOCAL> References: <91C4B16D6D58C541BF2F841D27F8253601A9188D@zmlex.zml.zoran.com> <91C4B16D6D58C541BF2F841D27F8253601A9188E@zmlex.zml.zoran.com> <4EDE8CD81F93443AAB2598510ED036B3@SUMENORSCS.LOCAL> Message-ID: <91C4B16D6D58C541BF2F841D27F8253601A91890@zmlex.zml.zoran.com> Cristine In baseline due to ASO the parameter first_mb_in_slice can't be used for the detection of picture start. For example let's suppose that a picture is divided into two slices top and bottom. If the bottom slice (which of course has first_mb_in_slice!=0) is sent prior to the top slice then the bottom slice is actually the picture start. Perhaps your stream obeys Constrained Baseline Profile (Baseline Profile with constraint_set1_flag=1). In such case neither ASO nor FMO are allowed and you can detect picture start by inspecting of first_mb_in_slice. So, for Constrained Baseline, Main, High profiles first_mb_in_slice=0 denotes picture start. As for your doubts on rbsp trailing bits. I use rbsp_stop_one_bit + rbsp_alignment_zero_bit(s) to determine where a slice ends or what bit is the last bit of the slice. For example in the following stream pattern: ....3c a7 80 00 00 00 00 00 01xxxxx What is the last byte of slice data - 0xa7, 0x80 or 0x00? The correct answer is 0xa7 (since 0x80 is use rbsp_stop_one_bit + 7 rbsp_alignment_zero_bits). Moreover in the above case the picture ends at byte boundary, i.e. the last bit of 0xa7 is the last bit of slice data. In the next example: ....3c a7 c0 00 00 00 00 00 01xxxxx The last byte is 0xc0 but the last bit of slice data is most-significant bit of 0xc0 followed by rbsp_stop_one_bit + 6 rbsp_alignment_zero_bits . The last example (related to your last question): ....3c af 00 00 00 00 00 00 01xxxxx The last byte is 0xaf but only 7 most-significant bits belongs to slice data, the least-significant bit is rbsp_stop_one_bit. So, the last byte of slice data can be '11111111' . Regards ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 17, 2010 1:58 PM To: Shevach Riabtsev; mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] NAL Unit slice header/data Thanks Shevach for your help, this mailing list is really helping me! I have baseline profile, so it will be more difficult...but now I don't understand if I read the start packet of a FU-A (i.e non idr NAL type) and the slice header is marked with first_mb_in_slice = 0, what does it mean? Sorry if I insist on this question but I don't understand what this parameter tells me. Another doubt... If the RTP padding field is equal to zero and I get the last byte of the NAL unit that should have the rbsp trailing bits. Does the last byte must have a ..xx10xx...(rbsp_stop_one_bit + rbsp_alignment_zero_bit)? ________________________________ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: mi?rcoles, 17 de febrero de 2010 10:15 Para: Cristina Gil; mp4-tech at lists.mpegif.org Asunto: Re: [Mp4-tech] NAL Unit slice header/data Cristina Nal_unit_type equal 1 or 5 specify picture data, all other NAL units are SPS,PPS, SEI messages and so on (with exception of data partitioning, but data partitioning is not popular feature in H264). Each picture can consist of a variable number of NAL units or slices. Notice also that the standard disallows to insert NAL units other than 1 or 5 within picture data. I provide a pseudo-code for detection of start picture (with assumption that profile is not Baseline and data partitioning is not used): Int DetectStartPicture() { // read first byte after Start Code (0x000001) from the stream, in case of RFC read first byte of NAL unit. Byte=ReadByte() // pick nal_unit_type Nal_unit_type=byte & 0x1F If(nal_unit_type==1 or nal_unit_type==5) { // current NAL contains picture data // determine whether current NAL is the first NAL of current picture // read single bit in order to determine whether first_mb_in_slice is zero or not Bit=PeekOneBit() If (bit==1) Return 1 // in exp-Golomb if first bit is one then code-word is zero } // else current NAL is SPS,PPS and so on Return 0 } Regards ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Tuesday, February 16, 2010 8:03 PM To: Shevach Riabtsev; mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] NAL Unit slice header/data Thanks Shevach! Could you please explain me a little bit: "If the current NAL is slice and the syntax element fisrt_mb_in_slice is 0 then the current NAL unit is picture start. Notice that in Baseline profile the above trick does not work due to ASO." I read from the standard: "baseline profile: NAL unit streams shall not contain nal_unit_type values in the range of 2 to 4, inclusive" and "Main profile: Arbitrary slice order is not allowed", so when I get a nal_unit_type 1 (non IDR) or 5 (IDR) and first_mb_in_slice = 0, I could say it's the first slice of the image and when I get another NAL unit with the same parameters nal_unit_type=1 or =5 and first_mb_in_slice = 0 it's a new picture?? I have checked from the stream I get and the NAL Units are idr/non-idr and fu-a and the slice header is always first_mb_in_slice = 0... for each packet I get with first_mb_in_slice = 0 im getting the picture start, don't i? this confuse me a little bit....... And about FU-As.. I read from the RFC3984 document, as they are fragmented units I have to concatenate them. So, the start bit will tell me the NAL unit contains the slice data, til the next FU-A (start) I only have to remove FU-A indicator-header and concatenate (checking the timestamp) to the last one. ________________________________ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: martes, 16 de febrero de 2010 18:04 Para: mp4-tech at lists.mpegif.org Asunto: [Mp4-tech] NAL Unit slice header/data Cristine, Actually multiple slices composes a single picture or a picture can be divided into multiple slices. In order to find start picture it is not needed to parse slice data. You can look for start code then according to nal_unit_type you can determined whether a current NAL unit is slice or not. If the current NAL is slice and the syntax element fisrt_mb_in_slice is 0 then the current NAL unit is picture start. Notice that in Baseline profile the above trick does not work due to ASO. Regards Shevach Riabtsev Video compressionist So, its only ONE slice header and MULTIPLE pictures coded in ONE slice data?? If this is true, I have to parse the slice data in order to get each picture, haven't i? ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100217/dc4989f5/attachment-0001.html From cristina.gil at sumenor.com Wed Feb 17 11:55:53 2010 From: cristina.gil at sumenor.com (Cristina Gil) Date: Wed, 17 Feb 2010 17:55:53 +0100 Subject: [Mp4-tech] NAL Unit slice header/data In-Reply-To: <91C4B16D6D58C541BF2F841D27F8253601A91890@zmlex.zml.zoran.com> References: <91C4B16D6D58C541BF2F841D27F8253601A9188D@zmlex.zml.zoran.com> <91C4B16D6D58C541BF2F841D27F8253601A9188E@zmlex.zml.zoran.com> <4EDE8CD81F93443AAB2598510ED036B3@SUMENORSCS.LOCAL> <91C4B16D6D58C541BF2F841D27F8253601A91890@zmlex.zml.zoran.com> Message-ID: <698D0D3F5040428A85CF5AED996911A2@SUMENORSCS.LOCAL> Hello, I appreciate very much your explanation, shevach. As a newbie I have more questions My rbsp trailing bits don?t seem to follow the same rule as yours When I get the last byte of the FU-A header with end_bit=1, I get: FU NAL TYPE idr, start_bit>0 slice_type I frame_num 0 FU NAL TYPE idr, end_bit>0 num last byte hex:f8 - bin:11111000 FU NAL TYPE non idr, start_bit>0 slice_type P frame_num 1 FU NAL TYPE non idr, end_bit>0 num last byte hex:30 - bin:110000 FU NAL TYPE non idr, start_bit>0 slice_type P frame_num 2 FU NAL TYPE non idr, end_bit>0 num last byte hex:93 - bin:10010011 [ ] FU NAL TYPE non idr, start_bit>0 slice_type P frame_num 5 FU NAL TYPE non idr, end_bit>0 num last byte hex:3f - bin:111111 [ ] FU NAL TYPE non idr, start_bit>0 slice_type P frame_num 15 FU NAL TYPE non idr, end_bit>0 num last byte hex:60 - bin:1100000 FU NAL TYPE non idr, start_bit>0 slice_type P frame_num 0 FU NAL TYPE non idr, end_bit>0 num last byte hex:fc - bin:11111100 [ ] FU NAL TYPE non idr, start_bit>0 slice_type P frame_num 15 FU NAL TYPE non idr, end_bit>0 num last byte hex:7e - bin:1111110 FU NAL TYPE idr, start_bit>0 slice_type I frame_num 0 FU NAL TYPE idr, end_bit>0 num last byte hex:c0 - bin:11000000 FU NAL TYPE non idr, start_bit>0 slice_type P frame_num 1 a) It seems my rbsp trailing bits ends with 10xxx but sometimes it ends with xxx1 I don?t really know why, could it have an explanation? b) The value of frame_num = 15 (P) and the next one frame_num=0 (P), I don?t understand because: The value of frame_num is constrained as follows. - If the current picture is an IDR picture, frame_num shall be equal to 0. - Otherwise (the current picture is not an IDR picture), referring to the primary coded picture in the previous accessunit in decoding order that contains a reference picture as the preceding reference picture, the value of frame_num for the current picture shall not be equal to PrevRefFrameNum unless all of the following three conditions are true. - the current picture and the preceding reference picture belong to consecutive access units in decoding order - the current picture and the preceding reference picture are reference fields having opposite parity - one or more of the following conditions is true ? the preceding reference picture is an IDR picture ? the preceding reference picture includes a memory_management_control_operation syntax element equal to 5 Thanks for your help!!!! _____ De: Shevach Riabtsev [mailto:Shevach.Riabtsev at zoran.com] Enviado el: mi?rcoles, 17 de febrero de 2010 14:21 Para: Cristina Gil; mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] NAL Unit slice header/data Cristine In baseline due to ASO the parameter first_mb_in_slice can?t be used for the detection of picture start. For example let?s suppose that a picture is divided into two slices top and bottom. If the bottom slice (which of course has first_mb_in_slice!=0) is sent prior to the top slice then the bottom slice is actually the picture start. Perhaps your stream obeys Constrained Baseline Profile (Baseline Profile with constraint_set1_flag=1). In such case neither ASO nor FMO are allowed and you can detect picture start by inspecting of first_mb_in_slice. So, for Constrained Baseline, Main, High profiles first_mb_in_slice=0 denotes picture start. As for your doubts on rbsp trailing bits. I use rbsp_stop_one_bit + rbsp_alignment_zero_bit(s) to determine where a slice ends or what bit is the last bit of the slice. For example in the following stream pattern: .3c a7 80 00 00 00 00 00 01xxxxx What is the last byte of slice data ? 0xa7, 0x80 or 0x00? The correct answer is 0xa7 (since 0x80 is use rbsp_stop_one_bit + 7 rbsp_alignment_zero_bits). Moreover in the above case the picture ends at byte boundary, i.e. the last bit of 0xa7 is the last bit of slice data. In the next example: .3c a7 c0 00 00 00 00 00 01xxxxx The last byte is 0xc0 but the last bit of slice data is most-significant bit of 0xc0 followed by rbsp_stop_one_bit + 6 rbsp_alignment_zero_bits . The last example (related to your last question): .3c af 00 00 00 00 00 00 01xxxxx The last byte is 0xaf but only 7 most-significant bits belongs to slice data, the least-significant bit is rbsp_stop_one_bit. So, the last byte of slice data can be ?11111111? . Regards _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 17, 2010 1:58 PM To: Shevach Riabtsev; mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] NAL Unit slice header/data Thanks Shevach for your help, this mailing list is really helping me! I have baseline profile, so it will be more difficult but now I don?t understand if I read the start packet of a FU-A (i.e non idr NAL type) and the slice header is marked with first_mb_in_slice = 0, what does it mean? Sorry if I insist on this question but I don?t understand what this parameter tells me. Another doubt If the RTP padding field is equal to zero and I get the last byte of the NAL unit that should have the rbsp trailing bits. Does the last byte must have a ..xx10xx (rbsp_stop_one_bit + rbsp_alignment_zero_bit)? _____ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: mi?rcoles, 17 de febrero de 2010 10:15 Para: Cristina Gil; mp4-tech at lists.mpegif.org Asunto: Re: [Mp4-tech] NAL Unit slice header/data Cristina Nal_unit_type equal 1 or 5 specify picture data, all other NAL units are SPS,PPS, SEI messages and so on (with exception of data partitioning, but data partitioning is not popular feature in H264). Each picture can consist of a variable number of NAL units or slices. Notice also that the standard disallows to insert NAL units other than 1 or 5 within picture data. I provide a pseudo-code for detection of start picture (with assumption that profile is not Baseline and data partitioning is not used): Int DetectStartPicture() { // read first byte after Start Code (0x000001) from the stream, in case of RFC read first byte of NAL unit. Byte=ReadByte() // pick nal_unit_type Nal_unit_type=byte & 0x1F If(nal_unit_type==1 or nal_unit_type==5) { // current NAL contains picture data // determine whether current NAL is the first NAL of current picture // read single bit in order to determine whether first_mb_in_slice is zero or not Bit=PeekOneBit() If (bit==1) Return 1 // in exp-Golomb if first bit is one then code-word is zero } // else current NAL is SPS,PPS and so on Return 0 } Regards _____ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Tuesday, February 16, 2010 8:03 PM To: Shevach Riabtsev; mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] NAL Unit slice header/data Thanks Shevach! Could you please explain me a little bit: ?If the current NAL is slice and the syntax element fisrt_mb_in_slice is 0 then the current NAL unit is picture start. Notice that in Baseline profile the above trick does not work due to ASO.? I read from the standard: ?baseline profile: NAL unit streams shall not contain nal_unit_type values in the range of 2 to 4, inclusive? and ?Main profile: Arbitrary slice order is not allowed?, so when I get a nal_unit_type 1 (non IDR) or 5 (IDR) and first_mb_in_slice = 0, I could say it?s the first slice of the image and when I get another NAL unit with the same parameters nal_unit_type=1 or =5 and first_mb_in_slice = 0 it?s a new picture?? I have checked from the stream I get and the NAL Units are idr/non-idr and fu-a and the slice header is always first_mb_in_slice = 0 for each packet I get with first_mb_in_slice = 0 im getting the picture start, don?t i? this confuse me a little bit . And about FU-As.. I read from the RFC3984 document, as they are fragmented units I have to concatenate them. So, the start bit will tell me the NAL unit contains the slice data, til the next FU-A (start) I only have to remove FU-A indicator-header and concatenate (checking the timestamp) to the last one. _____ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: martes, 16 de febrero de 2010 18:04 Para: mp4-tech at lists.mpegif.org Asunto: [Mp4-tech] NAL Unit slice header/data Cristine, Actually multiple slices composes a single picture or a picture can be divided into multiple slices. In order to find start picture it is not needed to parse slice data. You can look for start code then according to nal_unit_type you can determined whether a current NAL unit is slice or not. If the current NAL is slice and the syntax element fisrt_mb_in_slice is 0 then the current NAL unit is picture start. Notice that in Baseline profile the above trick does not work due to ASO. Regards Shevach Riabtsev Video compressionist So, its only ONE slice header and MULTIPLE pictures coded in ONE slice data?? If this is true, I have to parse the slice data in order to get each picture, haven't i? _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. _____ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100217/39e76361/attachment-0001.html From fido.genial at gmail.com Wed Feb 17 17:09:29 2010 From: fido.genial at gmail.com (Genial Fido) Date: Wed, 17 Feb 2010 14:09:29 -0800 Subject: [Mp4-tech] Mp4 container stream analyzer Message-ID: Hi All, Is there any Mp4 Container stream analyzer with H.264 video as an elementary stream . I am more interested in Mp4 encapsulation stream analyzer and also is there any document with specifies the header or encapsulation format of Mp4. Thanks fido -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100217/509ab091/attachment.html From singer at apple.com Wed Feb 17 17:54:31 2010 From: singer at apple.com (David Singer) Date: Wed, 17 Feb 2010 14:54:31 -0800 Subject: [Mp4-tech] Mp4 container stream analyzer In-Reply-To: References: Message-ID: <42B41896-FD05-4776-BE16-9F922F732CCD@apple.com> You seem to be asking for two things (a) something that will inspect an MP4 file that contains H.264 (AVC) and (b) the format of MP4 files. The second is mostly covered by ISO/IEC 14496-12, which is freely available from www.iso.ch on the freely available standards page. For the details of how AVC is put in this container, you'll need 14496-15, which is not free, alas. The reference software can dump a trace of an MP4 file as it opens it; reference software is freely available on request from www.mp4ra.org. ISMA is no longer active, but they maintained a validation tool for MP4 files, as well. On Feb 17, 2010, at 14:09 , Genial Fido wrote: > Hi All, > > Is there any Mp4 Container stream analyzer with H.264 video as an elementary stream . I am more interested in Mp4 encapsulation stream analyzer and also is there any document with specifies the header or encapsulation format of Mp4. > > Thanks > fido > > _______________________________________________ > NOTE: Please use clear subject lines for your posts. Include [audio, [video], [systems], [general] or another appropriate 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 Multimedia and Software Standards, Apple Inc. From Shevach.Riabtsev at zoran.com Thu Feb 18 02:30:28 2010 From: Shevach.Riabtsev at zoran.com (Shevach Riabtsev) Date: Thu, 18 Feb 2010 09:30:28 +0200 Subject: [Mp4-tech] NAL Unit slice header/data In-Reply-To: <698D0D3F5040428A85CF5AED996911A2@SUMENORSCS.LOCAL> References: <91C4B16D6D58C541BF2F841D27F8253601A9188D@zmlex.zml.zoran.com> <91C4B16D6D58C541BF2F841D27F8253601A9188E@zmlex.zml.zoran.com> <4EDE8CD81F93443AAB2598510ED036B3@SUMENORSCS.LOCAL> <91C4B16D6D58C541BF2F841D27F8253601A91890@zmlex.zml.zoran.com> <698D0D3F5040428A85CF5AED996911A2@SUMENORSCS.LOCAL> Message-ID: <91C4B16D6D58C541BF2F841D27F8253601A91892@zmlex.zml.zoran.com> Cristine As for question (a): Upon the finish of slice data an encoder has to pad bits till byte boundary. Therefore the encoder puts rbsp_stop_bit ('1') and checks whether byte boundary reached or not. If not the encoder puts rbsp_alignment_zero_bits until byte boundary reached. In your case: "FU NAL TYPE non idr, end_bit>0 num last byte hex:3f - bin:111111" the last byte of slice data is 0011 111x . So, the last bit has the index 6. Then the encoder puts rbsp_stop_bit and reaches the byte boundary. Thus no additional padding is required. This explains why trailing bits ends with xxx1 pattern and not xxx10 one. As for question (b): Frame_num is incremented by modulo 2^(log2_max_frame_num_minus4+4). Apparently in your stream log2_max_frame_num_minus4=0 therefore after frame_num=15 the next frame_num should be 0. I deliberately use the word "apparently" in the above sentence. Because if the SPS syntax element gaps_in_frame_num_value_allowed_flag is 1 then frame_num of the following frame can be an arbitrary number in the range [0.. 2^(log2_max_frame_num_minus4+4)-1] . Regards ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 17, 2010 6:56 PM To: Shevach Riabtsev; mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] NAL Unit slice header/data Hello, I appreciate very much your explanation, shevach. As a newbie I have more questions... My rbsp trailing bits don't seem to follow the same rule as yours... When I get the last byte of the FU-A header with end_bit=1, I get: FU NAL TYPE idr, start_bit>0 slice_type I frame_num 0 FU NAL TYPE idr, end_bit>0 num last byte hex:f8 - bin:11111000 FU NAL TYPE non idr, start_bit>0 slice_type P frame_num 1 FU NAL TYPE non idr, end_bit>0 num last byte hex:30 - bin:110000 FU NAL TYPE non idr, start_bit>0 slice_type P frame_num 2 FU NAL TYPE non idr, end_bit>0 num last byte hex:93 - bin:10010011 [...] FU NAL TYPE non idr, start_bit>0 slice_type P frame_num 5 FU NAL TYPE non idr, end_bit>0 num last byte hex:3f - bin:111111 [...] FU NAL TYPE non idr, start_bit>0 slice_type P frame_num 15 FU NAL TYPE non idr, end_bit>0 num last byte hex:60 - bin:1100000 FU NAL TYPE non idr, start_bit>0 slice_type P frame_num 0 FU NAL TYPE non idr, end_bit>0 num last byte hex:fc - bin:11111100 [...] FU NAL TYPE non idr, start_bit>0 slice_type P frame_num 15 FU NAL TYPE non idr, end_bit>0 num last byte hex:7e - bin:1111110 FU NAL TYPE idr, start_bit>0 slice_type I frame_num 0 FU NAL TYPE idr, end_bit>0 num last byte hex:c0 - bin:11000000 FU NAL TYPE non idr, start_bit>0 slice_type P frame_num 1 a) It seems my rbsp trailing bits ends with 10xxx... but sometimes it ends with ...xxx1 I don't really know why, could it have an explanation? b) The value of frame_num = 15 (P) and the next one frame_num=0 (P), I don't understand because: The value of frame_num is constrained as follows. - If the current picture is an IDR picture, frame_num shall be equal to 0. - Otherwise (the current picture is not an IDR picture), referring to the primary coded picture in the previous accessunit in decoding order that contains a reference picture as the preceding reference picture, the value of frame_num for the current picture shall not be equal to PrevRefFrameNum unless all of the following three conditions are true. - the current picture and the preceding reference picture belong to consecutive access units in decoding order - the current picture and the preceding reference picture are reference fields having opposite parity - one or more of the following conditions is true - the preceding reference picture is an IDR picture - the preceding reference picture includes a memory_management_control_operation syntax element equal to 5 Thanks for your help!!!! ________________________________ De: Shevach Riabtsev [mailto:Shevach.Riabtsev at zoran.com] Enviado el: mi?rcoles, 17 de febrero de 2010 14:21 Para: Cristina Gil; mp4-tech at lists.mpegif.org Asunto: RE: [Mp4-tech] NAL Unit slice header/data Cristine In baseline due to ASO the parameter first_mb_in_slice can't be used for the detection of picture start. For example let's suppose that a picture is divided into two slices top and bottom. If the bottom slice (which of course has first_mb_in_slice!=0) is sent prior to the top slice then the bottom slice is actually the picture start. Perhaps your stream obeys Constrained Baseline Profile (Baseline Profile with constraint_set1_flag=1). In such case neither ASO nor FMO are allowed and you can detect picture start by inspecting of first_mb_in_slice. So, for Constrained Baseline, Main, High profiles first_mb_in_slice=0 denotes picture start. As for your doubts on rbsp trailing bits. I use rbsp_stop_one_bit + rbsp_alignment_zero_bit(s) to determine where a slice ends or what bit is the last bit of the slice. For example in the following stream pattern: ....3c a7 80 00 00 00 00 00 01xxxxx What is the last byte of slice data - 0xa7, 0x80 or 0x00? The correct answer is 0xa7 (since 0x80 is use rbsp_stop_one_bit + 7 rbsp_alignment_zero_bits). Moreover in the above case the picture ends at byte boundary, i.e. the last bit of 0xa7 is the last bit of slice data. In the next example: ....3c a7 c0 00 00 00 00 00 01xxxxx The last byte is 0xc0 but the last bit of slice data is most-significant bit of 0xc0 followed by rbsp_stop_one_bit + 6 rbsp_alignment_zero_bits . The last example (related to your last question): ....3c af 00 00 00 00 00 00 01xxxxx The last byte is 0xaf but only 7 most-significant bits belongs to slice data, the least-significant bit is rbsp_stop_one_bit. So, the last byte of slice data can be '11111111' . Regards ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Wednesday, February 17, 2010 1:58 PM To: Shevach Riabtsev; mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] NAL Unit slice header/data Thanks Shevach for your help, this mailing list is really helping me! I have baseline profile, so it will be more difficult...but now I don't understand if I read the start packet of a FU-A (i.e non idr NAL type) and the slice header is marked with first_mb_in_slice = 0, what does it mean? Sorry if I insist on this question but I don't understand what this parameter tells me. Another doubt... If the RTP padding field is equal to zero and I get the last byte of the NAL unit that should have the rbsp trailing bits. Does the last byte must have a ..xx10xx...(rbsp_stop_one_bit + rbsp_alignment_zero_bit)? ________________________________ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: mi?rcoles, 17 de febrero de 2010 10:15 Para: Cristina Gil; mp4-tech at lists.mpegif.org Asunto: Re: [Mp4-tech] NAL Unit slice header/data Cristina Nal_unit_type equal 1 or 5 specify picture data, all other NAL units are SPS,PPS, SEI messages and so on (with exception of data partitioning, but data partitioning is not popular feature in H264). Each picture can consist of a variable number of NAL units or slices. Notice also that the standard disallows to insert NAL units other than 1 or 5 within picture data. I provide a pseudo-code for detection of start picture (with assumption that profile is not Baseline and data partitioning is not used): Int DetectStartPicture() { // read first byte after Start Code (0x000001) from the stream, in case of RFC read first byte of NAL unit. Byte=ReadByte() // pick nal_unit_type Nal_unit_type=byte & 0x1F If(nal_unit_type==1 or nal_unit_type==5) { // current NAL contains picture data // determine whether current NAL is the first NAL of current picture // read single bit in order to determine whether first_mb_in_slice is zero or not Bit=PeekOneBit() If (bit==1) Return 1 // in exp-Golomb if first bit is one then code-word is zero } // else current NAL is SPS,PPS and so on Return 0 } Regards ________________________________ From: Cristina Gil [mailto:cristina.gil at sumenor.com] Sent: Tuesday, February 16, 2010 8:03 PM To: Shevach Riabtsev; mp4-tech at lists.mpegif.org Subject: RE: [Mp4-tech] NAL Unit slice header/data Thanks Shevach! Could you please explain me a little bit: "If the current NAL is slice and the syntax element fisrt_mb_in_slice is 0 then the current NAL unit is picture start. Notice that in Baseline profile the above trick does not work due to ASO." I read from the standard: "baseline profile: NAL unit streams shall not contain nal_unit_type values in the range of 2 to 4, inclusive" and "Main profile: Arbitrary slice order is not allowed", so when I get a nal_unit_type 1 (non IDR) or 5 (IDR) and first_mb_in_slice = 0, I could say it's the first slice of the image and when I get another NAL unit with the same parameters nal_unit_type=1 or =5 and first_mb_in_slice = 0 it's a new picture?? I have checked from the stream I get and the NAL Units are idr/non-idr and fu-a and the slice header is always first_mb_in_slice = 0... for each packet I get with first_mb_in_slice = 0 im getting the picture start, don't i? this confuse me a little bit....... And about FU-As.. I read from the RFC3984 document, as they are fragmented units I have to concatenate them. So, the start bit will tell me the NAL unit contains the slice data, til the next FU-A (start) I only have to remove FU-A indicator-header and concatenate (checking the timestamp) to the last one. ________________________________ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: martes, 16 de febrero de 2010 18:04 Para: mp4-tech at lists.mpegif.org Asunto: [Mp4-tech] NAL Unit slice header/data Cristine, Actually multiple slices composes a single picture or a picture can be divided into multiple slices. In order to find start picture it is not needed to parse slice data. You can look for start code then according to nal_unit_type you can determined whether a current NAL unit is slice or not. If the current NAL is slice and the syntax element fisrt_mb_in_slice is 0 then the current NAL unit is picture start. Notice that in Baseline profile the above trick does not work due to ASO. Regards Shevach Riabtsev Video compressionist So, its only ONE slice header and MULTIPLE pictures coded in ONE slice data?? If this is true, I have to parse the slice data in order to get each picture, haven't i? ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. ________________________________ AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100218/e80d0a26/attachment-0001.html From boulabiar at gmail.com Fri Feb 19 10:21:43 2010 From: boulabiar at gmail.com (Mohamed Ikbel Boulabiar) Date: Fri, 19 Feb 2010 16:21:43 +0100 Subject: [Mp4-tech] CALL FOR MPEG4-AVC/H.264 CODECS - last chance In-Reply-To: <662537149.20100216004731@graphics.cs.msu.ru> References: <1976396892.20100109005505@graphics.cs.msu.ru> <662537149.20100216004731@graphics.cs.msu.ru> Message-ID: <45cc95261002190721w52ec7369u27e0d87d24df2ed2@mail.gmail.com> Hi all, Is there any comparison/benchmark that also include Scalable Video Coding results ? Thanks, ________________________________ Mohamed-Ikbel BOULABIAR Ing?nieur Informatique ENSI - Tunisie Master M2 en IHM, Telecom-Bretagne GnuPG key id: 1024D/0C4B7DC4 2010/2/15 Dmitriy Vatolin > Dear Experts, > > H.264 Comparison 2010 codecs submission deadline last time extended > to February 18, 2010. > > * Please appease your managers: We understand that only few real > leaders are interested in results publication. But also partial and > private participation is possible. So you can show results only in > those nominations where results of your codec satisfy you. > > * Developers provide us pretty fresh versions sometimes essentially > better, than publicly available from site for purchase (we > cross-check this). So you can compare you codec not only with old > version available from site (and pretty good for complacency :), but > with pretty fresh versions, that will be available several month > later. > > * Please do not worry about potential bugs in hot builds - in case > of crashes or another obvious problems you will have time (a week) > to provide us updated fixed versions and all results will be > remeasured. > > If even now you are afraid about quality of you codec, that there > are no reason to compare - please let us know. We are interested in > bigger number of good codecs and can measure weak and strong points > of your codec to help you tune it efficiently. > > If you think, that all objective measures are obsolete in XXI > century and your codec essentially tuned for visual results - please > let us know. We plan to include visual comparison of codecs with > turned on and off psychovisual options. > > If you have another reason to avoid external evaluation please let > us know - this is VERY interesting! > > Please contact videocodec-testing at graphics.cs.msu.ru > > ================8<==============Original message text=============== > > As usual Moscow State University Graphics & Multimedia Laboratory > starts next 6-th H.264 codecs comparison. > > Most interesting features this year: > > * Objective comparison will be extended with subjective with > leading codecs visual comparison. > > Also will be testes psycho-visual options and visual quality > during fade effects. > > * We release system of extensive tests of codecs with improper > interface (like GUI only). ALL available options of such codecs > will be tested, so option choice for comparison will be correct > now. > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > If you want to see some codec in our comparison - please let us > know! We will summarize votes and will add the most interesting > codecs. Please write us now. This can be not only H.264, but also > VC-1 or another (even proprietary). > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > Below is information for codec developers: > > =========================================================================== > CALL FOR MPEG4-AVC/H.264 CODECS > Sixth H.264 video codec comparison > For practical researchers and developers in the field of high-end video > compression > =========================================================================== > > Scope of Test > ------------- > > * Encoding time, speed/quality analysis > * Objective quality measurements (PSNR, SSIM, Average Advantage, etc.) > * Analysis of averaged objective results > * Leaders in different areas > > Important Dates > --------------- > > February,18 - Deadline for receipt of a H.264 codec with required > presets > March, 2 - Deadline for settling technical problems with codec?s > functioning > March, 24 - Draft version of report that will be sent to all > participants > April, 1 - Deadline for reception of comments to the draft > April, 7 - Comparison report release > > > Enhancements in comparison to Previous H.264/AVC Comparison > ----------------------------------------------------------- > > This comparison will includes some new features, that previous comparisons > do not include > > * Subjective comparison for the codes > > * More codecs - we will include codecs available from the Internet and > will choose optimal presets by Option Analysis > > * Comparison between Pareto optimal presets between different codecs > > * Effectiveness analysis of some encoder options > (see example at Options Analysis of MPEG-4 AVC/H.264 Codec x264) > > http://compression.ru/video/codec_comparison/x264_options_analysis_08_en.html > > * New video sequences > > > Developer Deliverables > ---------------------- > > The following deliverables should be provided by each developer: > * Codec files (CLI executable file is preferable) > * Short description of codec parameters > * Codec's presets with mentioning what H.264/AVC profiles are used > > The full text of Call for Codecs is available at > http://compression.ru/video/codec_comparison/call_for_codecs_10.html > > Variants of Participation > ------------------------- > > There are two variants for companies to participate in our comparison: > > 1. Participation for free. All results of your codec will be published, > except special cases of measurements problems due to codec > instability. > > 2. Private participation. A special report will be prepared only for your > company. This report contains: > * Your codec results and all material from the free version > * Special additional analysis of your codec > > If you are interested in the private participation, please contact us > for details. > > Also codec can be added into comparison by votes of professional > auditory. > > Useful Links > ------------ > > * Call for codecs-2010 > http://compression.ru/video/codec_comparison/call_for_codecs_10.html > > * Fifth Annual MSU MPEG-4 AVC/H.264 Video Codec Comparison > > http://www.compression.ru/video/codec_comparison/mpeg-4_avc_h264_2009_en.html > > * Options Analysis of MPEG-4 AVC/H.264 Codec x264 > > http://compression.ru/video/codec_comparison/x264_options_analysis_08_en.html > > > Sincerely yours, > Dr. Vatolin > > > ===8<===========End of original message text=========== > > > > Sincerely yours, > Dr. Vatolin > > > _______________________________________________ > NOTE: Please use clear subject lines for your posts. Include [audio, > [video], [systems], [general] or another appropriate 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/20100219/827a168c/attachment.html From Shevach.Riabtsev at zoran.com Tue Feb 23 03:16:00 2010 From: Shevach.Riabtsev at zoran.com (Shevach Riabtsev) Date: Tue, 23 Feb 2010 10:16:00 +0200 Subject: [Mp4-tech] [MP4-Tech][H264] Should delta_pic_order_cnt[0] zeroed in IDR picture? Message-ID: <91C4B16D6D58C541BF2F841D27F8253601A91898@zmlex.zml.zoran.com> Dear experts According to the reference decoder when pic_order_cnt_type is 1 the syntax element delta_pic_order_cnt[0] is cleared for IDR picture: if(img->idr_flag) { img->FrameNumOffset=0; // first pix of IDRGOP, img->delta_pic_order_cnt[0]=0; //ignore first delta if(img->frame_num) error("frame_num != 0 in idr pix", -1020); } On the other hand in the H.264 spec. we can't find any explicit mention why delta_pic_order_cnt[0] shall be cleared for IDR picture. Generally speaking, in IDR picture the derived POC can be non-zero (unlike frame_num which is mandated to be zero in IDR pictures). Therefore delta_pic_order_cnt[0] can be non-zero. I wonder why in the reference decoder this syntax element is cleared? Indeed, if a decoder enforces delta_pic_order_cnt[0] to zero then the derived POC values on encoder and decoder sides might be different. Regards Shevach Riabtsev Video compressionist -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100223/ccc7b009/attachment.html From cristina.gil at sumenor.com Tue Feb 23 05:33:51 2010 From: cristina.gil at sumenor.com (Cristina Gil) Date: Tue, 23 Feb 2010 11:33:51 +0100 Subject: [Mp4-tech] howto decode h.264 image Message-ID: <89052A152F634514A9B88244ACA3562E@SUMENORSCS.LOCAL> Hello, I get the SPS, PPS, the nal type, and the slice type. Now I want to decode the slice header-data in order to get the image and then the video.. im a newbie to do that myself so I ask, is there any library or DS filter I can give the nal unit and decode de image for me?? Or, which solution can I do to decode the stream? Thanks for your help! AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100223/1245dbb6/attachment.html From Shevach.Riabtsev at zoran.com Wed Feb 24 09:35:17 2010 From: Shevach.Riabtsev at zoran.com (Shevach Riabtsev) Date: Wed, 24 Feb 2010 16:35:17 +0200 Subject: [Mp4-tech] howto decode h.264 image Message-ID: <91C4B16D6D58C541BF2F841D27F8253601A9189C@zmlex.zml.zoran.com> Cristine I suggest you take H264 Reference SW from http://iphome.hhi.de/suehring/tml/ In file header.c you can find two routines: 'FirstPartOfSliceHeader' and 'RestOfSliceHeader'. You should implement the same logic as in the above routines in order to parse/decode slice header. Regards Shevach Riabtsev I get the SPS, PPS, the nal type, and the slice type. Now I want to decode the slice header-data in order to get the image and then the video.. im a newbie to do that myself so I ask, is there any library or DS filter I can give the nal unit and decode de image for me?? Or, which solution can I do to decode the stream? -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100224/d5853e3d/attachment.html From cristina.gil at sumenor.com Wed Feb 24 10:29:23 2010 From: cristina.gil at sumenor.com (Cristina Gil) Date: Wed, 24 Feb 2010 16:29:23 +0100 Subject: [Mp4-tech] howto decode h.264 image In-Reply-To: <91C4B16D6D58C541BF2F841D27F8253601A9189C@zmlex.zml.zoran.com> References: <91C4B16D6D58C541BF2F841D27F8253601A9189C@zmlex.zml.zoran.com> Message-ID: <4EE5B11032E64E8D9FADC35D4CF93490@SUMENORSCS.LOCAL> Hello, Thanks shevach for your reply, but i get the slice header, and now i want to get the picture so I have to decode the slice data and I think if I do it from the standard it would be too difficult for me because my h264 knowledge is limited. That?s why I looking for a library or so.., I saw the H264 Reference SW implements a ?decode_one_frame? function. Do you think I can use it? Do you recommend something else? _____ De: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] En nombre de Shevach Riabtsev Enviado el: mi?rcoles, 24 de febrero de 2010 15:35 Para: mp4-tech at lists.mpegif.org Asunto: [Mp4-tech] howto decode h.264 image Cristine I suggest you take H264 Reference SW from http://iphome.hhi.de/suehring/tml/ In file header.c you can find two routines: ?FirstPartOfSliceHeader? and ?RestOfSliceHeader?. You should implement the same logic as in the above routines in order to parse/decode slice header. Regards Shevach Riabtsev I get the SPS, PPS, the nal type, and the slice type. Now I want to decode the slice header-data in order to get the image and then the video.. im a newbie to do that myself so I ask, is there any library or DS filter I can give the nal unit and decode de image for me?? Or, which solution can I do to decode the stream? AVISO LEGAL La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100224/d6b0d33e/attachment.html From dirosen at optonline.net Wed Feb 24 12:40:56 2010 From: dirosen at optonline.net (Dan Rosen) Date: Wed, 24 Feb 2010 12:40:56 -0500 Subject: [Mp4-tech] Byte alignment of slice data syntax. In-Reply-To: <4EE5B11032E64E8D9FADC35D4CF93490@SUMENORSCS.LOCAL> References: <91C4B16D6D58C541BF2F841D27F8253601A9189C@zmlex.zml.zoran.com> <4EE5B11032E64E8D9FADC35D4CF93490@SUMENORSCS.LOCAL> Message-ID: <003a01cab578$85809560$9081c020$@net> In looking at the reference decoder and when the entropy coding_mode_flag is one I can't seem to find where the byte alignment occurs. Could someone please point me to the appropriate code? Can I also assume that for CAVLC that the there is no byte alignment of the slice data following the slice header data? Thanks, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100224/56482554/attachment.html From thang_dth at yahoo.com Wed Feb 24 21:11:07 2010 From: thang_dth at yahoo.com (Wintnt) Date: Wed, 24 Feb 2010 18:11:07 -0800 (PST) Subject: [Mp4-tech] which parameter of PSNR or bit rate is more important ? Message-ID: <15341.78017.qm@web111505.mail.gq1.yahoo.com> Dear Experts; In comparison of video quality, which parameter of PSNR or bit rate is more important ? For example: + method 1: PSNR degradation is -0.07dB and incresing bit rate is +1.9% + method 2: PSNR degradation is -0.05dB and incresing bit rate is +2.2% How do I know which method is better? Many thanks N. Chien -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100224/4908c2df/attachment.html From garysull at microsoft.com Wed Feb 24 22:45:56 2010 From: garysull at microsoft.com (Gary Sullivan) Date: Thu, 25 Feb 2010 03:45:56 +0000 Subject: [Mp4-tech] which parameter of PSNR or bit rate is more important ? In-Reply-To: <15341.78017.qm@web111505.mail.gq1.yahoo.com> References: <15341.78017.qm@web111505.mail.gq1.yahoo.com> Message-ID: <0ABA7B9B054CF94BA95E013D1EE0DBDA041D45@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> N. Chien, I suggest for you to study the concept of what we often call Bj?ntegaard-delta measurements. Reference link: http://wftp3.itu.int/av-arch/video-site/0104_Aus/VCEG-M33.doc There have been some subsequent refinements that may also be worth studying, and there is some software available (including Excel spreadsheet format) that can help make these measurements for you, but that VCEG-AM33 document is good for understanding the background of the concept. Best Regards, Gary Sullivan From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Wintnt Sent: Wednesday, February 24, 2010 6:11 PM To: Helper Subject: [Mp4-tech] which parameter of PSNR or bit rate is more important ? Dear Experts; In comparison of video quality, which parameter of PSNR or bit rate is more important ? For example: + method 1: PSNR degradation is -0.07dB and incresing bit rate is +1.9% + method 2: PSNR degradation is -0.05dB and incresing bit rate is +2.2% How do I know which method is better? Many thanks N. Chien -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100225/c867dd3e/attachment.html From thang_dth at yahoo.com Fri Feb 26 02:29:50 2010 From: thang_dth at yahoo.com (Wintnt) Date: Thu, 25 Feb 2010 23:29:50 -0800 (PST) Subject: [Mp4-tech] which parameter of PSNR or bit rate is more important ? In-Reply-To: <0ABA7B9B054CF94BA95E013D1EE0DBDA041D45@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <164866.11947.qm@web111515.mail.gq1.yahoo.com> Dear Sir. Gary; Your suggestions are very informative to me, and I also found other docs that I am interesting in. Thank you very much. Best regards Ng Chien --- On Thu, 2/25/10, Gary Sullivan wrote: From: Gary Sullivan Subject: RE: [Mp4-tech] which parameter of PSNR or bit rate is more important ? To: "N. Chien" , "MPEG4 tech reflector" Date: Thursday, February 25, 2010, 10:45 AM N. Chien, ? I suggest for you to study the concept of what we often call Bj?ntegaard-delta measurements. ? Reference link: http://wftp3.itu.int/av-arch/video-site/0104_Aus/VCEG-M33.doc ? There have been some subsequent refinements that may also be worth studying, and there is some software available (including Excel spreadsheet format) that can help make these measurements for you, but that VCEG-AM33 document is good for understanding the background of the concept. ? Best Regards, ? Gary Sullivan ? From: mp4-tech-bounces at lists.mpegif.org [mailto:mp4-tech-bounces at lists.mpegif.org] On Behalf Of Wintnt Sent: Wednesday, February 24, 2010 6:11 PM To: Helper Subject: [Mp4-tech] which parameter of PSNR or bit rate is more important ? ? Dear Experts; In comparison of video quality, which parameter of PSNR or bit rate is more important ? For example: + method 1: PSNR degradation is -0.07dB and incresing bit rate is +1.9% + method 2: PSNR degradation is -0.05dB and incresing bit rate is +2.2% How do I know which method is better? Many thanks N. Chien ? -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100225/7c891b59/attachment.html From fful at conncoll.edu Sat Feb 27 12:35:00 2010 From: fful at conncoll.edu (Frank Fulchiero) Date: Sat, 27 Feb 2010 12:35:00 -0500 Subject: [Mp4-tech] Interactivity within the MPEG4 container In-Reply-To: References: Message-ID: One puzzling aspect of the current debates on Flash-vs-HTML5 is that MPEG4 is never mentioned as a possible container to support "rich media experiences" I understand that the MPEG4 container has provisions for interactivity within it, as Flash and QT (used to), both with and without JavaScript, using, I think, BIFS, LASeR, GPAC, and possibly other technologies I don't know about . There is still room for interactivity control from within containers, it does not all have to be from HTML5. I therefore am curious as to the state of development of interactive control of audio, video, image, text, etc. objects or tracks using the MPEG4 container. Not knowing much about this, am wondering if there are web sites regarding the current state of development of interactivity within MPEG4. It seems a timely topic, given the Flash- vs-HTML5 debates. Thanks, Frank Fulchiero Digital Media Specialist Connecticut College From Shevach.Riabtsev at zoran.com Sun Feb 28 09:24:09 2010 From: Shevach.Riabtsev at zoran.com (Shevach Riabtsev) Date: Sun, 28 Feb 2010 16:24:09 +0200 Subject: [Mp4-tech] Byte alignment of slice data syntax. Message-ID: <91C4B16D6D58C541BF2F841D27F8253601A918A4@zmlex.zml.zoran.com> Dan In CAVLC mode slice data is immediately followed by slice header without byte alignment. On the other hand in CABAC mode the slice header is byte-aligned by cabac_alignment_one_bit(s). The reason why the slice header in CABAC mode is appended by one bits until byte boundary reached is not clear for me. This is a good opportunity to ask experts the slice header in CABAC mode shall be padded? Regards Shevach Riabtsev Video compressionist In looking at the reference decoder and when the entropy coding_mode_flag is one I can't seem to find where the byte alignment occurs. Could someone please point me to the appropriate code? Can I also assume that for CAVLC that the there is no byte alignment of the slice data following the slice header data? -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/mp4-tech/attachments/20100228/052c5c26/attachment.html