libmpeg2-devel — main mailing list for libmpeg2 development

[mpeg2-dev] Update to config.{guess,sub} needed

[Eric L. <i...@ha...>]

Hello, I'm building libmpeg2 on riscv64, and the configure script is 
too old to know such a new architecture.

Running `autoreconf -fi` fixes the problem, but an update to those 
scripts should be a better solution (if someone with write access is 
active, which probably won't be).

Thank you anyway for developing this project!

[mpeg2-dev] libmpeg2 fails to compile on MacBook M1 (AArch64)

[John K. <jk...@gm...>]

It doesn't look like libmpeg2 is being maintained but it's still used
in a few projects including ScummVM.

I'm trying to compile this on the new Apple MacBook M1 (AArch64) and
it looks like the assembly in motion_comp_arm_s.S needs to be updated?

I'm not familiar with assembly at all but I'm hoping somebody might be
willing to look at this and see if it can be fixed?

Thanks so much for your help

Re: [mpeg2-dev] Some patches

[Christophe M. <ma...@vi...>]

Hi,

I don’t think there is any active development at present on libmpeg2, so feel free to implement it if you like.

Best regards

> On 10 May 2018, at 17:25, Ivan Maguidhir <iv...@ma...> wrote:
> 
> Hi Christophe
> 
> I sent you an email privately but I'm not sure if you got it. The first patch was based on my erroneous belief that the library was only allocating memory for one line of chroma for each frame. Looking at the code again now I can see that the library is allocating exactly the right amount of memory. Both of my patches and my original message should therefore be disregarded.
> 
> I have some useful modifications to libmpeg2 which report decoding errors to the user via a flag in the mpeg2_info_t struct, however I want to test them more and write some documentation for the README before submitting them. I would also be interested in attempting to write error concealment code for libmpeg2 if nobody else is doing it.
> 
> All the best,
> Ivan
> 
> 
> On 05/05/18 22:54, Christophe Massiot wrote:
>> Hi,
>> 
>> Can you provide a sample to reproduce the crash supposedly fixed by your first patch? Privately if needed.
>> 
>> Thanks in advance
>> 
>>> On 19 Apr 2018, at 00:50, Ivan Maguidhir <iv...@ma...> wrote:
>>> 
>>> Dear libmpeg2 developers,
>>> 
>>> Find attached two patches which fix problems that I encountered while
>>> processing MPEG2 streams from a large number of DVD-Video discs using the
>>> library. The P0_buffer_overflow.patch fixes bugs to do with the allocation
>>> of memory for each frame's chroma information. The
>>> P1_unexpected_gop_header.patch causes the parser to accept a GOP header when
>>> a picture has already started. This can happen where streams have been
>>> spliced together, for example. I hope these are of some use.
>>> 
>>> Kind regards,
>>> Ivan Maguidhir
>>> 
>>> <P0_buffer_overflow.patch><P1_unexpected_gop_header.patch>------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
>>> Libmpeg2-devel mailing list
>>> Lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/libmpeg2-devel
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Libmpeg2-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmpeg2-devel
> 

Re: [mpeg2-dev] Some patches

[Ivan M. <iv...@ma...>]

Hi Christophe

I sent you an email privately but I'm not sure if you got it. The first 
patch was based on my erroneous belief that the library was only 
allocating memory for one line of chroma for each frame. Looking at the 
code again now I can see that the library is allocating exactly the 
right amount of memory. Both of my patches and my original message 
should therefore be disregarded.

I have some useful modifications to libmpeg2 which report decoding 
errors to the user via a flag in the mpeg2_info_t struct, however I want 
to test them more and write some documentation for the README before 
submitting them. I would also be interested in attempting to write error 
concealment code for libmpeg2 if nobody else is doing it.

All the best,
Ivan


On 05/05/18 22:54, Christophe Massiot wrote:
> Hi,
>
> Can you provide a sample to reproduce the crash supposedly fixed by your first patch? Privately if needed.
>
> Thanks in advance
>
>> On 19 Apr 2018, at 00:50, Ivan Maguidhir <iv...@ma...> wrote:
>>
>> Dear libmpeg2 developers,
>>
>> Find attached two patches which fix problems that I encountered while
>> processing MPEG2 streams from a large number of DVD-Video discs using the
>> library. The P0_buffer_overflow.patch fixes bugs to do with the allocation
>> of memory for each frame's chroma information. The
>> P1_unexpected_gop_header.patch causes the parser to accept a GOP header when
>> a picture has already started. This can happen where streams have been
>> spliced together, for example. I hope these are of some use.
>>
>> Kind regards,
>> Ivan Maguidhir
>>
>> <P0_buffer_overflow.patch><P1_unexpected_gop_header.patch>------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
>> Libmpeg2-devel mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libmpeg2-devel

Re: [mpeg2-dev] Some patches

[Christophe M. <ma...@vi...>]

Hi,

Can you provide a sample to reproduce the crash supposedly fixed by your first patch? Privately if needed.

Thanks in advance

> On 19 Apr 2018, at 00:50, Ivan Maguidhir <iv...@ma...> wrote:
> 
> Dear libmpeg2 developers,
> 
> Find attached two patches which fix problems that I encountered while
> processing MPEG2 streams from a large number of DVD-Video discs using the
> library. The P0_buffer_overflow.patch fixes bugs to do with the allocation
> of memory for each frame's chroma information. The
> P1_unexpected_gop_header.patch causes the parser to accept a GOP header when
> a picture has already started. This can happen where streams have been
> spliced together, for example. I hope these are of some use.
> 
> Kind regards,
> Ivan Maguidhir
> 
> <P0_buffer_overflow.patch><P1_unexpected_gop_header.patch>------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
> Libmpeg2-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmpeg2-devel

Re: [mpeg2-dev] Some patches

[Ivan M. <iv...@ma...>]

Dear libmpeg2 developers,

Further to my previous message. I think my P1_unexpected_gop_header.patch
might be incorrect and that the original parser behaviour of entering a
STATE_INVALID state might be correct.

Kind regards,
Ivan Maguidhir

-----Original Message-----
From: Ivan Maguidhir <iv...@ma...> 
Sent: Wednesday 18 April 2018 23:51
To: lib...@li...
Subject: [mpeg2-dev] Some patches

Dear libmpeg2 developers,

Find attached two patches which fix problems that I encountered while
processing MPEG2 streams from a large number of DVD-Video discs using the
library. The P0_buffer_overflow.patch fixes bugs to do with the allocation
of memory for each frame's chroma information. The
P1_unexpected_gop_header.patch causes the parser to accept a GOP header when
a picture has already started. This can happen where streams have been
spliced together, for example. I hope these are of some use.

Kind regards,
Ivan Maguidhir
 

[mpeg2-dev] Some patches

[Ivan M. <iv...@ma...>]

Dear libmpeg2 developers,

Find attached two patches which fix problems that I encountered while
processing MPEG2 streams from a large number of DVD-Video discs using the
library. The P0_buffer_overflow.patch fixes bugs to do with the allocation
of memory for each frame's chroma information. The
P1_unexpected_gop_header.patch causes the parser to accept a GOP header when
a picture has already started. This can happen where streams have been
spliced together, for example. I hope these are of some use.

Kind regards,
Ivan Maguidhir
 

[mpeg2-dev] libmpeg2 over ethernet

[Ran S. <ran...@gm...>]

Hello,

I'm new with libmpeg2.
Is there an example for using libmpeg2 over Ethernet ?

Thank you,
Ran

Re: [mpeg2-dev] [PATCH] motion_comp_arm_s.S is not PIC enough

[Rafaël C. <fu...@vi...>]

Le 2012-07-17 23:08, John Reiser a écrit :
> On 07/17/2012 10:19 AM, Rafaël Carré wrote:
>> Hello,
>>
>> Le 2012-07-16 00:09, John Reiser a écrit :
>>> Functions MC_put_o_16_arm, MC_put_o_8_arm, MC_put_x_16_arm, MC_put_x_8_arm
>>> in libmpeg2/motion_comp_arm_s.S have addresses in .text, which is bad
>>> for shared libraries.  Some environments demand that .text actually be
>>> read-only all the time, yet MC_put_o_16_arm etc require that the addresses
>>> be modified by the dynamic linking mechanism (dlopen, LoadLibrary, etc.)
>>> Even in those environments which permit the dynamic linker to modify the
>>> .text segment, the runtime cost of doing the relocation can be noticeable.
>>>
>>> The attached patch rewrites the linkage, discarding the tables of addresses
>>> in favor of tables of offsets.  All transfers are local within each individual
>>> function, so there can be no interference by processing that occurs
>>> after assembly, such as link-time re-ordering (even of individual functions.)
>>>
>>> -- John Reiser
>>>
>>>
>>> libmpeg2.patch
>>>
>>>
>>> Index: libmpeg2/motion_comp_arm_s.S
>>> ===================================================================
>>> --- libmpeg2/motion_comp_arm_s.S	(revision 1205)
>>> +++ libmpeg2/motion_comp_arm_s.S	(working copy)
>>> @@ -29,9 +29,13 @@
>>>  	pld [r1]
>>>          stmfd sp!, {r4-r11, lr} @ R14 is also called LR
>>>  	and r4, r1, #3
>>> -	adr r5, MC_put_o_16_arm_align_jt
>>> -	add r5, r5, r4, lsl #2
>>> -	ldr pc, [r5]
>>> +	ldrb r4, [pc, r4]
>>> +	add pc, pc, r4, lsl #2
>>
>> Is this instruction available on all ARM variants?
> 
> The "add pc, pc, r4, lsl #2" has the same _form_ as the replaced
>     "add r5, r5, r4, lsl #2".
> The patched code will assemble correctly for all variants where the
> unpatched code will assemble correctly.
> In particular, all ARM CPU back to at least armv4 have both instructions
> in ARM mode.  The code also executes correctly in ARM mode on armv4 and later.
> Using armv5tel I ran "make check" successfully against all the streams
> when the working directory was  libmpeg2/trunk/test .
> 
> The unpatched file motion_comp_arm_s.S uses
>         stmfd sp!, {r4-r11, lr} @ R14 is also called LR
> which because of the use of 'r11' and 'lr' is ARM-only, not Thumb1, not Thumb2.
> Thus we don't need to consider _any_ Thumb variants for the patch.
> 
> However, *just* for the sake of complete analysis:
> ----- begin analysis of Thumb modes; *NOT NEEDED* by patch
> The unpatched "add r5, r5, r4, lsl #2" does not exist in Thumb ("Thumb1"),
> but does exist in Thumb2.  It is not available on armv5t, but is available
> on all higher armv?t CPU because Thumb2 is very desirable and not
> too expensive (in any of chip area, power, licensing fees.)
> 
> The remaining question is whether "add pc, pc, r4, lsl #2" executes correctly
> in Thumb2.  What value is read from register r15, as input to the 'add'?
> My reference is:
> 
>   ARM Architecture Reference Manual, ARM DDI 0100E, July 2000
>   Section 6.1 About the Thumb instruction set
> 
>   When R15 is read, bit[0] is zero and bits[31:1] contain the PC. When R15
>   is written, bit[0] is IGNORED and    bits[31:1] are written to the PC.
>   Depending on how it is used, the value of the PC is either the address
>   of the instruction plus 4 or is UNPREDICTABLE.
> 
> Because the Thumb sequence
>   L99:
>      mov lr, pc
>      b.n  foo
>   L100:
> may be used to record a continuation address (it sets r14 to &L100, which is
> (4 + &L99)), then I believe that the value fetched from r15 is 4+(&opcode & ~1),
> and not UNPREDICTABLE.
> This also agrees with the exposed 3-stage pipelining of original ARM, where
> the value fetched from r15 is is two words (2*2 in Thumb mode, 2*4 in ARM
> mode) ahead.
> 
> So, in Thumb2 mode I believe that the value fetched from r15 by
> "add pc, pc, r4, lsl #2" is the address of the byte which immediately follows
> the 'add' instruction, namely byte 0 of the table.  However, the address that
> the patch wants is the address of the "0:" just _beyond_ the table.  Therefore
> *IF* we want the same code to be correct for both ARM and Thumb2 at the same time,
> then we must use another register to handle the different value fetched from r15
> by Thumb2 vs ARM:
> 
> 	adr r5, 0f
>         ldrb r4, [r5, r4]
>         add pc, r5, r4, lsl #2
> 0:
>         .byte (MC_put_o_16_arm_align0 - 0b)>>2
>         .byte (MC_put_o_16_arm_align1 - 0b)>>2
>         .byte (MC_put_o_16_arm_align2 - 0b)>>2
>         .byte (MC_put_o_16_arm_align3 - 0b)>>2
> 
> In Thumb2 mode only (not Thumb1, not ARM), the sequence
> 	adr r5, 0f
> 	tbb [r5, r4]  # Table Branch Byte
> 0:
> 	.byte ...
> is equivalent, and shorter by 4 bytes and faster by two [?] cycles.
> ----- end analysis of Thumb modes; *NOT NEEDED* by patch
> 
> 
>>
>> I have to ask because I found some restrictions on:
>> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0068b/BABDCBAB.html
> 
> I see a background watermark "Superseded" on that page.  Also, the document is
> for Thumb1 and not Thumb2.  Therefore I believe that the document does not apply,
> because the unpatched "add r5, r5, r4, lsl #2" would require Thumb2.  [Remember
> also that the unpatched code won't assemble for Thumb2 anyway because of the
> references to r11 and lr in the 'stml '.]
> 
>>
>> Although here it should be the form "ADD Rd, Rn, #imm8m" which works
>> everywhere.

Thanks for the details, patch committed to SVN.

Re: [mpeg2-dev] [PATCH] motion_comp_arm_s.S is not PIC enough

[John R. <jr...@bi...>]

On 07/17/2012 10:19 AM, Rafaël Carré wrote:
> Hello,
> 
> Le 2012-07-16 00:09, John Reiser a écrit :
>> Functions MC_put_o_16_arm, MC_put_o_8_arm, MC_put_x_16_arm, MC_put_x_8_arm
>> in libmpeg2/motion_comp_arm_s.S have addresses in .text, which is bad
>> for shared libraries.  Some environments demand that .text actually be
>> read-only all the time, yet MC_put_o_16_arm etc require that the addresses
>> be modified by the dynamic linking mechanism (dlopen, LoadLibrary, etc.)
>> Even in those environments which permit the dynamic linker to modify the
>> .text segment, the runtime cost of doing the relocation can be noticeable.
>>
>> The attached patch rewrites the linkage, discarding the tables of addresses
>> in favor of tables of offsets.  All transfers are local within each individual
>> function, so there can be no interference by processing that occurs
>> after assembly, such as link-time re-ordering (even of individual functions.)
>>
>> -- John Reiser
>>
>>
>> libmpeg2.patch
>>
>>
>> Index: libmpeg2/motion_comp_arm_s.S
>> ===================================================================
>> --- libmpeg2/motion_comp_arm_s.S	(revision 1205)
>> +++ libmpeg2/motion_comp_arm_s.S	(working copy)
>> @@ -29,9 +29,13 @@
>>  	pld [r1]
>>          stmfd sp!, {r4-r11, lr} @ R14 is also called LR
>>  	and r4, r1, #3
>> -	adr r5, MC_put_o_16_arm_align_jt
>> -	add r5, r5, r4, lsl #2
>> -	ldr pc, [r5]
>> +	ldrb r4, [pc, r4]
>> +	add pc, pc, r4, lsl #2
> 
> Is this instruction available on all ARM variants?

The "add pc, pc, r4, lsl #2" has the same _form_ as the replaced
    "add r5, r5, r4, lsl #2".
The patched code will assemble correctly for all variants where the
unpatched code will assemble correctly.
In particular, all ARM CPU back to at least armv4 have both instructions
in ARM mode.  The code also executes correctly in ARM mode on armv4 and later.
Using armv5tel I ran "make check" successfully against all the streams
when the working directory was  libmpeg2/trunk/test .

The unpatched file motion_comp_arm_s.S uses
        stmfd sp!, {r4-r11, lr} @ R14 is also called LR
which because of the use of 'r11' and 'lr' is ARM-only, not Thumb1, not Thumb2.
Thus we don't need to consider _any_ Thumb variants for the patch.

However, *just* for the sake of complete analysis:
----- begin analysis of Thumb modes; *NOT NEEDED* by patch
The unpatched "add r5, r5, r4, lsl #2" does not exist in Thumb ("Thumb1"),
but does exist in Thumb2.  It is not available on armv5t, but is available
on all higher armv?t CPU because Thumb2 is very desirable and not
too expensive (in any of chip area, power, licensing fees.)

The remaining question is whether "add pc, pc, r4, lsl #2" executes correctly
in Thumb2.  What value is read from register r15, as input to the 'add'?
My reference is:

  ARM Architecture Reference Manual, ARM DDI 0100E, July 2000
  Section 6.1 About the Thumb instruction set

  When R15 is read, bit[0] is zero and bits[31:1] contain the PC. When R15
  is written, bit[0] is IGNORED and    bits[31:1] are written to the PC.
  Depending on how it is used, the value of the PC is either the address
  of the instruction plus 4 or is UNPREDICTABLE.

Because the Thumb sequence
  L99:
     mov lr, pc
     b.n  foo
  L100:
may be used to record a continuation address (it sets r14 to &L100, which is
(4 + &L99)), then I believe that the value fetched from r15 is 4+(&opcode & ~1),
and not UNPREDICTABLE.
This also agrees with the exposed 3-stage pipelining of original ARM, where
the value fetched from r15 is is two words (2*2 in Thumb mode, 2*4 in ARM
mode) ahead.

So, in Thumb2 mode I believe that the value fetched from r15 by
"add pc, pc, r4, lsl #2" is the address of the byte which immediately follows
the 'add' instruction, namely byte 0 of the table.  However, the address that
the patch wants is the address of the "0:" just _beyond_ the table.  Therefore
*IF* we want the same code to be correct for both ARM and Thumb2 at the same time,
then we must use another register to handle the different value fetched from r15
by Thumb2 vs ARM:

	adr r5, 0f
        ldrb r4, [r5, r4]
        add pc, r5, r4, lsl #2
0:
        .byte (MC_put_o_16_arm_align0 - 0b)>>2
        .byte (MC_put_o_16_arm_align1 - 0b)>>2
        .byte (MC_put_o_16_arm_align2 - 0b)>>2
        .byte (MC_put_o_16_arm_align3 - 0b)>>2

In Thumb2 mode only (not Thumb1, not ARM), the sequence
	adr r5, 0f
	tbb [r5, r4]  # Table Branch Byte
0:
	.byte ...
is equivalent, and shorter by 4 bytes and faster by two [?] cycles.
----- end analysis of Thumb modes; *NOT NEEDED* by patch


> 
> I have to ask because I found some restrictions on:
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0068b/BABDCBAB.html

I see a background watermark "Superseded" on that page.  Also, the document is
for Thumb1 and not Thumb2.  Therefore I believe that the document does not apply,
because the unpatched "add r5, r5, r4, lsl #2" would require Thumb2.  [Remember
also that the unpatched code won't assemble for Thumb2 anyway because of the
references to r11 and lr in the 'stml '.]

> 
> Although here it should be the form "ADD Rd, Rn, #imm8m" which works
> everywhere.

-- 
John Reiser

Re: [mpeg2-dev] [PATCH] motion_comp_arm_s.S is not PIC enough

[Rafaël C. <fu...@vi...>]

Hello,

Le 2012-07-16 00:09, John Reiser a écrit :
> Functions MC_put_o_16_arm, MC_put_o_8_arm, MC_put_x_16_arm, MC_put_x_8_arm
> in libmpeg2/motion_comp_arm_s.S have addresses in .text, which is bad
> for shared libraries.  Some environments demand that .text actually be
> read-only all the time, yet MC_put_o_16_arm etc require that the addresses
> be modified by the dynamic linking mechanism (dlopen, LoadLibrary, etc.)
> Even in those environments which permit the dynamic linker to modify the
> .text segment, the runtime cost of doing the relocation can be noticeable.
> 
> The attached patch rewrites the linkage, discarding the tables of addresses
> in favor of tables of offsets.  All transfers are local within each individual
> function, so there can be no interference by processing that occurs
> after assembly, such as link-time re-ordering (even of individual functions.)
> 
> -- John Reiser
> 
> 
> libmpeg2.patch
> 
> 
> Index: libmpeg2/motion_comp_arm_s.S
> ===================================================================
> --- libmpeg2/motion_comp_arm_s.S	(revision 1205)
> +++ libmpeg2/motion_comp_arm_s.S	(working copy)
> @@ -29,9 +29,13 @@
>  	pld [r1]
>          stmfd sp!, {r4-r11, lr} @ R14 is also called LR
>  	and r4, r1, #3
> -	adr r5, MC_put_o_16_arm_align_jt
> -	add r5, r5, r4, lsl #2
> -	ldr pc, [r5]
> +	ldrb r4, [pc, r4]
> +	add pc, pc, r4, lsl #2

Is this instruction available on all ARM variants?

I have to ask because I found some restrictions on:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0068b/BABDCBAB.html

Although here it should be the form "ADD Rd, Rn, #imm8m" which works
everywhere.

> +	.byte (MC_put_o_16_arm_align0 - 0f)>>2
> +	.byte (MC_put_o_16_arm_align1 - 0f)>>2
> +	.byte (MC_put_o_16_arm_align2 - 0f)>>2
> +	.byte (MC_put_o_16_arm_align3 - 0f)>>2
> +0:

[mpeg2-dev] [PATCH] motion_comp_arm_s.S is not PIC enough

[John R. <jr...@bi...>]

Functions MC_put_o_16_arm, MC_put_o_8_arm, MC_put_x_16_arm, MC_put_x_8_arm
in libmpeg2/motion_comp_arm_s.S have addresses in .text, which is bad
for shared libraries.  Some environments demand that .text actually be
read-only all the time, yet MC_put_o_16_arm etc require that the addresses
be modified by the dynamic linking mechanism (dlopen, LoadLibrary, etc.)
Even in those environments which permit the dynamic linker to modify the
.text segment, the runtime cost of doing the relocation can be noticeable.

The attached patch rewrites the linkage, discarding the tables of addresses
in favor of tables of offsets.  All transfers are local within each individual
function, so there can be no interference by processing that occurs
after assembly, such as link-time re-ordering (even of individual functions.)

-- 
John Reiser

Re: [mpeg2-dev] Playing Live DVBT

[Piyush V. <piy...@gm...>]

Dear Janne,

Thanks a lot for your valuable information.

Finally I have fixed that issue.

I have tried probsize but it was not working before.

The problem was only this that I was using depricted API.

I just change open call from av_open_input_file to avformat_open_input and
it's start respecting "probsize".

where av_open_input_file was overwriting my probsize with default value.

I come to know that with some debugging message and with DEPRICTED_API
warning  message.

Thanks again to everybody and hope above information could help other in
that issue.


Thanks & Regards

Piyush Verma



On Sat, Jun 16, 2012 at 3:22 AM, Janne Grunau <jan...@gr...> wrote:

> Hey,
>
> On 2012-06-16 02:23:08 +0800, Piyush Verma wrote:
> >
> > I was working on DVBT for android.
> >
> > libmpeg2 looks interesting for that application. How ever I found some
> > issue while tyring to use it.
> >
> > I have compiled some test program like extract_mpeg2 and mpeg2dec.
> >
> > When I run extract_mpeg2 /dev/dvb0.dvr0. I am getting contentiously
> message
> > "looks like a video stream, not system stream"
>
> DVB-T uses a MPEG transport stream and extract_mpeg2 seems to expect
> a system stream. This is not going to work well.
>
> > Just for information. Before I was trying ffmpeg but the problem there I
> > got is av_open_input_file takes approx 12 to 15 sec. which is very long.
>
> av_open_input_file() with default options is optimized for fast random
> file access. It doesn't work well on the dvr device. The biggest
> problem is probably the size of the probe buffer (iirc 5 mega byte).
> Try setting probesize to something more reasonable, 100 kilo byte
> should be safe for SD mpeg2 program.
>
> If you have further question regarding libavcodec/format usage please
> ask on the libav-api mailing list
> https://lists.libav.org/mailman/listinfo/libav-api/
>
> I would recommend using Libav over FFmpeg because the developers
> caring about Arm and embedded systems are in the Libav project.
>
> HTH
>
> Janne, Libav developer
>



-- 
Thanks & Regards

Piyush Verma

Re: [mpeg2-dev] Playing Live DVBT

[Janne G. <jan...@gr...>]

Hey,

On 2012-06-16 02:23:08 +0800, Piyush Verma wrote:
> 
> I was working on DVBT for android.
> 
> libmpeg2 looks interesting for that application. How ever I found some
> issue while tyring to use it.
> 
> I have compiled some test program like extract_mpeg2 and mpeg2dec.
> 
> When I run extract_mpeg2 /dev/dvb0.dvr0. I am getting contentiously message
> "looks like a video stream, not system stream"

DVB-T uses a MPEG transport stream and extract_mpeg2 seems to expect
a system stream. This is not going to work well.

> Just for information. Before I was trying ffmpeg but the problem there I
> got is av_open_input_file takes approx 12 to 15 sec. which is very long.

av_open_input_file() with default options is optimized for fast random
file access. It doesn't work well on the dvr device. The biggest
problem is probably the size of the probe buffer (iirc 5 mega byte).
Try setting probesize to something more reasonable, 100 kilo byte
should be safe for SD mpeg2 program.

If you have further question regarding libavcodec/format usage please
ask on the libav-api mailing list
https://lists.libav.org/mailman/listinfo/libav-api/

I would recommend using Libav over FFmpeg because the developers
caring about Arm and embedded systems are in the Libav project.

HTH

Janne, Libav developer

Re: [mpeg2-dev] Playing Live DVBT

[Janne G. <jan...@gr...>]

Hey,

On 2012-06-16 02:23:08 +0800, Piyush Verma wrote:
> 
> I was working on DVBT for android.
> 
> libmpeg2 looks interesting for that application. How ever I found some
> issue while tyring to use it.
> 
> I have compiled some test program like extract_mpeg2 and mpeg2dec.
> 
> When I run extract_mpeg2 /dev/dvb0.dvr0. I am getting contentiously message
> "looks like a video stream, not system stream"

DVB-T uses a MPEG transport stream and extract_mpeg2 seems to expect
a system stream. This is not going to work well.

> Just for information. Before I was trying ffmpeg but the problem there I
> got is av_open_input_file takes approx 12 to 15 sec. which is very long.

av_open_input_file() with default options is optimized for fast random
file access. It doesn't work well on the dvr device. The biggest
problem is probably the size of the probe buffer (iirc 5 mega byte).
Try setting probesize to something more reasonable, 100 kilo byte
should be safe for SD mpeg2 program.

If you have further question regarding libavcodec/format usage please
ask on the libav-api mailing list
https://lists.libav.org/mailman/listinfo/libav-api/

I would recommend using Libav over FFmpeg because the developers
caring about Arm and embedded systems are in the Libav project.

HTH

Janne, Libav developer

[mpeg2-dev] Playing Live DVBT

[Piyush V. <piy...@gm...>]

Hello All,


I was working on DVBT for android.

libmpeg2 looks interesting for that application. How ever I found some
issue while tyring to use it.

I have compiled some test program like extract_mpeg2 and mpeg2dec.

When I run extract_mpeg2 /dev/dvb0.dvr0. I am getting contentiously message
"looks like a video stream, not system stream"

Same when I try to run with mpeg2dec it's able to parse but when it display
result on screen it's not clear.  it looks like mixed tile.


Just for information. Before I was trying ffmpeg but the problem there I
got is av_open_input_file takes approx 12 to 15 sec. which is very long. So
hope libmpeg2 would have solution for it.


-- 
Thanks & Regards

Piyush Verma

Re: [mpeg2-dev] [PATCH] move some inline keywords

[Jean-Baptiste K. <jb...@vi...>]

On Mon, Jan 16, 2012 at 10:26:59AM +0100, Diego Biurrun wrote :
> Here is a small patch to move inline keywords to the front of function
> declarations.  This fixes some warnings with gcc and -Wextra where it
> complains about the 'static' keyword not being at the beginning of a
> function declaration.  Apparently gcc gets tripped up and complains
> about 'static' instead of 'inline', but hey, it's easy enough to fix.

Seems harmless to me.

Best regards,

-- 
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device

[mpeg2-dev] [PATCH] move some inline keywords

[Diego B. <di...@bi...>]

Here is a small patch to move inline keywords to the front of function
declarations.  This fixes some warnings with gcc and -Wextra where it
complains about the 'static' keyword not being at the beginning of a
function declaration.  Apparently gcc gets tripped up and complains
about 'static' instead of 'inline', but hey, it's easy enough to fix.

Diego

[mpeg2-dev] (no subject)

[uros d. <ur...@ya...>]

http://madonnajane.com/wp-content/themes/canvas/mmkfot.htm

Re: [mpeg2-dev] How to reduce Intra block DC bits prior to IDCT

[Keith W. <ke...@mi...>]

Hi pebble,

I'm not sure exactly where you're getting the [0, 32768] (the DC
component can be negative), but I think you may probably barking up
the wrong tree. IEEE 1180 only defines the IDCT statistically, so
different MPEG-2 decoders can produce slightly different output.
libmpeg2 may even produce slightly different output depending on
whether you're using the C IDCT, MMX, SSE2, etc. The precision is
probably not the issue; both libmpeg2 and the reference decoder use
the precision specified in the coded bitstream for each component.

You might find that switching the IDCT in use (look at
mpeg2_idct_init() in idct.c, or modify cpu_accel.c) gives you
something closer to the results of the reference decoder. In the end,
though, these are all conforming decoders. Trying to get one to match
the other _exactly_ may require swapping out one IDCT for another and
tracking exactly where the divergence occurs.

Good luck!

Best,
Keith

On Wed, Aug 3, 2011 at 11:03 PM, pebble <sod...@ya...> wrote:
>
> Hi there,
>
> I need to hook into libmpeg2 so that I may do some processing on mpeg2 bitstream level. I have a working algorithm developed with the reference decoder (mssg's mpeg2v12.zip), but I would like to try on libmpeg2 because of its very fast decoding speed.
>
> To decode the same mpeg2 video file, I have tried the reference decoder and libmpeg2's mpegdec. I found that both decoders have produced nonidentical frames (a few pixels at various position gets different values). Furthermore, by checking the IDCT process, I found that, for Intra block, DC value in DCT coefficient matrix, the reference decoder (getpic.c) is using signed 11 bits [-1024, +1024] but libmpeg2 (slice.c) is using unsigned 15 bits [0, 32768].
>
> I thought this could be one of the reasons why the decoded frames are nonidentical.
>
> Why libmpeg2 needs to use a larger bit size ? Is there any way to configure libmpeg2 to use signed 11 bits for Intra block DC value, so that its behavior could become a bit closer to that of reference decoder?
>
> Thanks.
>
> Best Regards,
>
> pebble
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Libmpeg2-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmpeg2-devel
>

[mpeg2-dev] How to reduce Intra block DC bits prior to IDCT

[pebble <sod...@ya...>]

Hi there,

I need to hook into libmpeg2 so that I may do some processing on mpeg2 bitstream level. I have a working algorithm developed with the reference decoder (mssg's mpeg2v12.zip), but I would like to try on libmpeg2 because of its very fast decoding speed.

To decode the same mpeg2 video file, I have tried the reference decoder and libmpeg2's mpegdec. I found that both decoders have produced nonidentical frames (a few pixels at various position gets different values). Furthermore, by checking the IDCT process, I found that, for Intra block, DC value in DCT coefficient matrix, the reference decoder (getpic.c) is using signed 11 bits [-1024, +1024] but libmpeg2 (slice.c) is using unsigned 15 bits [0, 32768].

I thought this could be one of the reasons why the decoded frames are nonidentical.

Why libmpeg2 needs to use a larger bit size ? Is there any way to configure libmpeg2 to use signed 11 bits for Intra block DC value, so that its behavior could become a bit closer to that of reference decoder?

Thanks.

Best Regards,

pebble

Re: [mpeg2-dev] mpeg2_parse always returns STATE_INVALID

[Daniel T. <dt....@gm...>]

I've debugged it a bit an I think I've found the problem.

I did some comparing between my copy of libmpeg compiled for my computer and the compiled copy for my ARM processor. 

I found that STATE_INTERNAL_NORETURN was defined as ((mpeg2_state_t)-1). On x86 processors, gcc makes the mpeg2_state_t enumeration a signed type while on my ARM processor, it's an unsigned type. So, because -1 is cast to an unsigned type, it's value (in my case) was 255 instead of -1. That probably was the reason why it worked on my computer and not my ARM processor. I simply changed the cast to a signed character type and recompiled.

Now, I'm getting, presumably, a stack overflow somewhere on the second call to mpeg_parse() (after calling mpeg_buffer()). If anyone can shed some light, that would be great.


On 15/06/2011, at 4:38 PM, Daniel Tang wrote:

> Hi,
> 
> I've just compiled libmpeg2 for an embedded platform and have written some code for decoding. But the call to mpeg2_parse in this code seems to always return STATE_INVALID. 
> 
> int play(FILE * mpgfile)
> {
> 	mpeg2dec_t * decoder;
>   const mpeg2_info_t * info;
>   mpeg2_state_t state;
>   size_t size = 1;
> 	unsigned char *buffer = malloc(BUFFER_SIZE);
> 	
> 	char debug[20];
> 	if (!buffer) {
> 		show_msgbox("NspireMoviePlayer","NULL ptr from Malloc");
> 		return 1;
> 	}
> 	
> 	decoder = mpeg2_init ();
>   if (!decoder) {
>   	show_msgbox("NspireMoviePlayer","Could not init mpeg2");
> 		return 1;
> 	}
> 
>   info = mpeg2_info (decoder);
> 	do
> 	{
> 		state = mpeg2_parse (decoder);
> 		switch (state) {
> 			case STATE_BUFFER:
> 		    	size = fread (buffer, 1, BUFFER_SIZE, mpgfile);
> 		    	mpeg2_buffer (decoder, buffer, buffer + size);
> 		    	break;
> 			case STATE_SEQUENCE:
> 		    	mpeg2_convert (decoder, mpeg2convert_rgb24, NULL);
> 		    	settimerperiod(info->sequence->frame_period);
> 		    	break;
> 			case STATE_SLICE:
> 			case STATE_END:
> 				if (info->sequence->width  != SCREEN_WIDTH ||
> 					info->sequence->height != SCREEN_HEIGHT)
> 				{
> 					show_msgbox("NspireMoviePlayer","Screen size mismatch");
> 					goto die;
> 				}
> 				else {
> 					waittimerperiod();
> 					renderframe(info->display_fbuf->buf[0]);
> 				}
> 				break;
> 			case STATE_INVALID:
> 				goto die;
> 		    	break;
> 			default:
> 		    	break;
> 		}
> 	} while(size);
> 	
> 	mpeg2_close(decoder);
> 	return 0;
> 	
> 	die:
> 	mpeg2_close(decoder);
> 	return 1;
> }
> 
> I dug around decode.c and added some debugging messages and it seems it's conking out in this piece of code at the bottom of mpeg2_parse:
> 
> mpeg2dec->action = mpeg2_seek_header;
>   switch (mpeg2dec->code) {
>   case 0x00:
>   show_msgbox("libmpeg2","case 0 mpeg2dec->code");
> 	return mpeg2dec->state;
>   case 0xb3:
>   case 0xb7:
>   case 0xb8:
>   show_msgbox("libmpeg2","case b8 mpeg2dec->code");
> 	return (mpeg2dec->state == STATE_SLICE) ? STATE_SLICE : STATE_INVALID;
>   default:
> 	mpeg2dec->action = seek_chunk;
> 	show_msgbox("libmpeg2","default mpeg2dec->code"); // This is where it returns
> 	return STATE_INVALID;
>   }
> 
> Does anyone have any ideas on what could be causing this? The code isn't very well documented and it's hard to follow.
> 
> Cheers,

Re: [mpeg2-dev] mpeg2_parse always returns STATE_INVALID

[Keith W. <ke...@mi...>]

Daniel,

It's hard to help you debug this without knowing what you are feeding
in. To be clear -- you are using a valid MPEG-2 video elementary
stream that plays perfectly fine with mpeg2dec and the other sample
decoders distributed with libmpeg2? Maybe if you can post a sample of
your file, I can help you debug why your code gives STATE_INVALID
while the sample decoders don't, if that's what's happening.

Best,
Keith

On Mon, Jun 13, 2011 at 3:27 AM, Daniel Tang <dt....@gm...> wrote:
> Hi,
>
> I've just compiled libmpeg2 for an embedded platform and have written some code for decoding. But the call to mpeg2_parse in this code seems to always return STATE_INVALID.
>
> int play(FILE * mpgfile)
> {
>        mpeg2dec_t * decoder;
>   const mpeg2_info_t * info;
>   mpeg2_state_t state;
>   size_t size = 1;
>        unsigned char *buffer = malloc(BUFFER_SIZE);
>
>        char debug[20];
>        if (!buffer) {
>                show_msgbox("NspireMoviePlayer","NULL ptr from Malloc");
>                return 1;
>        }
>
>        decoder = mpeg2_init ();
>   if (!decoder) {
>        show_msgbox("NspireMoviePlayer","Could not init mpeg2");
>                return 1;
>        }
>
>   info = mpeg2_info (decoder);
>        do
>        {
>                state = mpeg2_parse (decoder);
>                switch (state) {
>                        case STATE_BUFFER:
>                        size = fread (buffer, 1, BUFFER_SIZE, mpgfile);
>                        mpeg2_buffer (decoder, buffer, buffer + size);
>                        break;
>                        case STATE_SEQUENCE:
>                        mpeg2_convert (decoder, mpeg2convert_rgb24, NULL);
>                        settimerperiod(info->sequence->frame_period);
>                        break;
>                        case STATE_SLICE:
>                        case STATE_END:
>                                if (info->sequence->width  != SCREEN_WIDTH ||
>                                        info->sequence->height != SCREEN_HEIGHT)
>                                {
>                                        show_msgbox("NspireMoviePlayer","Screen size mismatch");
>                                        goto die;
>                                }
>                                else {
>                                        waittimerperiod();
>                                        renderframe(info->display_fbuf->buf[0]);
>                                }
>                                break;
>                        case STATE_INVALID:
>                                goto die;
>                        break;
>                        default:
>                        break;
>                }
>        } while(size);
>
>        mpeg2_close(decoder);
>        return 0;
>
>        die:
>        mpeg2_close(decoder);
>        return 1;
> }
>
> I dug around decode.c and added some debugging messages and it seems it's conking out in this piece of code at the bottom of mpeg2_parse:
>
> mpeg2dec->action = mpeg2_seek_header;
>   switch (mpeg2dec->code) {
>   case 0x00:
>   show_msgbox("libmpeg2","case 0 mpeg2dec->code");
>        return mpeg2dec->state;
>   case 0xb3:
>   case 0xb7:
>   case 0xb8:
>   show_msgbox("libmpeg2","case b8 mpeg2dec->code");
>        return (mpeg2dec->state == STATE_SLICE) ? STATE_SLICE : STATE_INVALID;
>   default:
>        mpeg2dec->action = seek_chunk;
>        show_msgbox("libmpeg2","default mpeg2dec->code"); // This is where it returns
>        return STATE_INVALID;
>   }
>
> Does anyone have any ideas on what could be causing this? The code isn't very well documented and it's hard to follow.
>
> Cheers,
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Libmpeg2-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmpeg2-devel
>

[mpeg2-dev] mpeg2_parse always returns STATE_INVALID

[Daniel T. <dt....@gm...>]

Hi,

I've just compiled libmpeg2 for an embedded platform and have written some code for decoding. But the call to mpeg2_parse in this code seems to always return STATE_INVALID. 

int play(FILE * mpgfile)
{
	mpeg2dec_t * decoder;
   const mpeg2_info_t * info;
   mpeg2_state_t state;
   size_t size = 1;
	unsigned char *buffer = malloc(BUFFER_SIZE);
	
	char debug[20];
	if (!buffer) {
		show_msgbox("NspireMoviePlayer","NULL ptr from Malloc");
		return 1;
	}
	
	decoder = mpeg2_init ();
   if (!decoder) {
   	show_msgbox("NspireMoviePlayer","Could not init mpeg2");
		return 1;
	}

   info = mpeg2_info (decoder);
	do
	{
		state = mpeg2_parse (decoder);
		switch (state) {
			case STATE_BUFFER:
		    	size = fread (buffer, 1, BUFFER_SIZE, mpgfile);
		    	mpeg2_buffer (decoder, buffer, buffer + size);
		    	break;
			case STATE_SEQUENCE:
		    	mpeg2_convert (decoder, mpeg2convert_rgb24, NULL);
		    	settimerperiod(info->sequence->frame_period);
		    	break;
			case STATE_SLICE:
			case STATE_END:
				if (info->sequence->width  != SCREEN_WIDTH ||
					info->sequence->height != SCREEN_HEIGHT)
				{
					show_msgbox("NspireMoviePlayer","Screen size mismatch");
					goto die;
				}
				else {
					waittimerperiod();
					renderframe(info->display_fbuf->buf[0]);
				}
				break;
			case STATE_INVALID:
				goto die;
		    	break;
			default:
		    	break;
		}
	} while(size);
	
	mpeg2_close(decoder);
	return 0;
	
	die:
	mpeg2_close(decoder);
	return 1;
}

I dug around decode.c and added some debugging messages and it seems it's conking out in this piece of code at the bottom of mpeg2_parse:

mpeg2dec->action = mpeg2_seek_header;
   switch (mpeg2dec->code) {
   case 0x00:
   show_msgbox("libmpeg2","case 0 mpeg2dec->code");
	return mpeg2dec->state;
   case 0xb3:
   case 0xb7:
   case 0xb8:
   show_msgbox("libmpeg2","case b8 mpeg2dec->code");
	return (mpeg2dec->state == STATE_SLICE) ? STATE_SLICE : STATE_INVALID;
   default:
	mpeg2dec->action = seek_chunk;
	show_msgbox("libmpeg2","default mpeg2dec->code"); // This is where it returns
	return STATE_INVALID;
   }

Does anyone have any ideas on what could be causing this? The code isn't very well documented and it's hard to follow.

Cheers,

Re: [mpeg2-dev] Crashes in sse2_idct x86_64

[Matthew M. <mmc...@gm...>]

Hi John,

I revisited the problem early this year, and while I made a little more
progress, I didn't solve it.

I did make find that changing line 100 in mpeg_internal.h from:

int16_t DCTblock[64] ATTR_ALIGN(64);
to
__declspec(align(64)) int16_t DCTblock[64];

stopped it crashing in _mpeg2_idct_copy_sse2() and it actually started
producing images.
But, alas, the images were corrupted with vertical streaks.

But that would be my suggestion for a starting point.. check the data
alignment.

Matt
ps.
I never managed to even get close to compiling  idct_mmx.c
and motion_comp_mmx.c in Visual Studio.
I then tried using the sse2 functions that come with MediaPlayerClassic.
I remember this also almost worked, but suffered from different kinds of
image defects.
In the end I found versions of libmpeg2-0.dll and mpeg2.lib in the GStreamer
project that had been compiled with SSE2, and just went with those.


On 31 May 2011 00:02, John Stebbins <ste...@je...> wrote:

> Have there been any new developments on this problem?
> http://sourceforge.net/mailarchive/message.php?msg_id=25140766
>
> I am seeing similar (if not identical) behavior from libmpeg2 compiled with
> the mingw64 cross tools for fedora
> (available here http://build1.openftd.org/mingw-w64/)
> After disabling gcc optimizations and enabling debug, gdb indicates the
> crash happens in sse2_idct at the first movdqa_m2r.
>
> There are also reports of similar crashes in sse2_idct due to recent gcc
> 4.6 changes.
> http://comments.gmane.org/gmane.linux.mandrake.bugs/201430
> The patches in this thread fix the problem on fedora 15 where this is
> reproducible, but not for mingw64 builds
> unfortunately.
>
>
>
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Libmpeg2-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmpeg2-devel
>