libmpeg2-devel — main mailing list for libmpeg2 development

Re: [mpeg2-dev] Patch to fix issues with Visual Studio

[Lionel D. <lio...@ya...>]

Hi,

> > This patch may fix vc++, but breaks all other platforms
> > because it moves ATTR_ALIGN which is used in different
> > places.
> It certainly shouldn't, the patch replaces ATTR_ALIGN
> taking 2 parameters which only works with gcc with
> DECLARE_ALIGNED which takes 3 parameters and supports
> both gcc and msvc syntax and also replaces all occurrences
> of ATTR_ALIGNED with DECLARE_ALIGNED.
Er, not quite ;)
After applying your patch, I can count 57 remaining occurrences
of ATTR_ALIGNED, in the following files:
include/mmx.h
include/sse.h
libmpeg2/convert/rgb.c
libmpeg2/convert/rgb_vis.c
libmpeg2/idct_altivec.c
libmpeg2/idct_mmx.c
libmpeg2/motion_comp_vis.c

You need to change those too, otherwise libmpeg2 cannot be built
with either MSVC or GCC.


Apart from that, I'd surround the GCC-specific declaration of
DECLARE_ALIGNED by a #ifdef __GNUC__, like this:

/* use GCC and MSVC attribs to align critical data structures */
#if (defined(ATTRIBUTE_ALIGNED_MAX) && defined(__GNUC__))
#define DECLARE_ALIGNED(n,t,v) ...

(Note that I updated the comment as well)


Regards, Lionel Debroux.

__________________________________________________
Do You Yahoo!?
En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible contre les messages non sollicités 
http://mail.yahoo.fr Yahoo! Mail 

Re: [mpeg2-dev] Patch to fix issues with Visual Studio

[John A. <Jo...@ad...>]

(Embarrassed answering of own question)
> Could you explain how this breaks other platforms and I'll happily update the patch.
by not changing all the instances of ATTR_ALIGN you fool.
 
I'll make an upadated patch this evening, apologies.
 
John

Re: [mpeg2-dev] Patch to fix issues with Visual Studio

[John A. <Jo...@ad...>]

> This patch may fix vc++, but breaks all other platforms because it
> moves ATTR_ALIGN which is used in different places.
It certainly shouldn't, the patch replaces ATTR_ALIGN taking 2 parameters which only works with gcc with DECLARE_ALIGNED which takes 3 parameters and supports both gcc and msvc syntax and also replaces all occurrences of ATTR_ALIGNED with DECLARE_ALIGNED.  Could you explain how this breaks other platforms and I'll happily update the patch.
 
John

Re: [mpeg2-dev] Patch to fix issues with Visual Studio

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

At 14:35 +0100 17/05/08, John Adcock wrote:
>The attached patch fixes support for compilation under Visual Studio
>using the project file in the vc++ directory.  The recent SSE2 IDCT
>patch requires some data to be aligned and this patch adds support for
>the alignment in MSVC as well as fixing a compilation error in for the
>obj files that need to be built in the vc++ directory.

This patch may fix vc++, but breaks all other platforms because it 
removes ATTR_ALIGN which is used in different places.

-- 
Christophe Massiot.

[mpeg2-dev] Patch to fix issues with Visual Studio

[John A. <Jo...@ad...>]

The attached patch fixes support for compilation under Visual Studio
using the project file in the vc++ directory.  The recent SSE2 IDCT
patch requires some data to be aligned and this patch adds support for
the alignment in MSVC as well as fixing a compilation error in for the
obj files that need to be built in the vc++ directory.

Thanks

John

Re: [mpeg2-dev] release?

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

On Wed, Apr 30, 2008, Jean-Baptiste Kempf wrote:
> On Wed, Apr 30, 2008 at 07:39:00PM +0200, Diego Biurrun wrote :
> > So, all patches that were posted recently have been applied.  How about
> > making a libmpeg2 release now?  A branch release would be very helpful
> > for me since it I could easily import it into MPlayer :)
> 
> I am for a release too. :D

Me too. Walken, is there still work to be done in TRUNK ?
-- 
Christophe Massiot.

Re: [mpeg2-dev] extract duration from MPEG files

[Burkhard P. <pl...@ip...>]

Hi,

lib...@li... schrieb:

> Is the total stream duration stored somewhere in the file? 

No

> If so, is
> there an easy method to extract it?

Parse the whole stream and catch the STATE_PICTURE states.

Burkhard

Re: [mpeg2-dev] extract duration from MPEG files

[Thomas R. <tho...@pe...>]

Hello,


Thanks again for the feedback. After a bit more experimentation, I've come to the following conclusions:

1) The source of my poor performance is the fact that the files are being streamed across the network. This is a requirement for the application I'm building, so i can't get around that easily.

2) Due to the above, any method that requires reading the entire file is going to be slow.

So, for constant bit-rate encodings, would it be possible / sensible to just read enough to determine the bitrate of the video and audio stream(s), and use that and the total file size to determine the duration of the video streams? 

For example, if there's one video stream at 1.5Mbps, and an audio stream at 0.5Mbps, and the file is 2GB large, that must give us 1.5 GB of video stream,a dn 500MB of audio stream. Dividing 1.5Gb by 1.5Mbps gives us 8000 seconds of video.

Ummmm, is this a valid calculation? If so, how accurate is it likely to be?

If it is a valid calculation, could I apply a similar formula to variable bit-rate encodings? If so, what's a typical margin of error one could expect?

I realize that this is now drifting slightly off-topic... but any help would be much appreciated!

Thanks once again!

Re: [mpeg2-dev] frame_rate_extension_n

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

Hi Craig,

On #1, I think we're good -- you can only have one sequence_extension 
following a sequence_header. See 13818-2, clause 6.3.1 
("sequence_extension() shall only occur immediately following a 
sequence_header()").

On #2, I think that's a real bug (that would, as you point out, only 
affect bitstreams not conforming to a defined profile). I agree it should 
be (((buffer[ 5 ] >> 5) & 0x03) + 1).

-Keith

On Sat, 3 May 2008, Craig Milo Rogers wrote:

> 	Hello.  I'm browsing through the SVN trunk for libmpeg2,
> revision 1171.  My reference document is ISO 13818-2.  I'm looking at the
> frame rate calculation in "libmpeg2/header.c".  I understand that
> libmpeg2 calculates a reciprocal, called frame_period.  What bothers
> me is the frame rate extension adjustment in the routine sequence_ext,
> in the following line:
>
>    sequence->frame_period =
>        sequence->frame_period * ((buffer[5]&31)+1) / (((buffer[5]>>2)&3)+1);
>
>
> 1)	It modifies frame_period in place.  If it is possible to have
> 	two or more extension headers after a single sequence header
> 	(I haven't yet figured out if the ISO spec says anything about
> 	this possibility), then it seems to me that each frame rate
> 	(frame_period) adjustment should start with the value from the
> 	last sequence header (from my reading of section 6.3.3 of the spec).
> 	The current libmpeg2 code would compound them, and this seems
> 	incorrect.
>
> 2)	Based on section 6.2.2.3 of ISO 13818-2, frame_rate_extension_n
> 	is a 2-bit field located before the 5-bit frame_rate_extension_d
> 	field.  That implies that the correct way to extract this field
> 	is:
>
>        ((buffer[5]>>5)&3)
>
> 	not:
>
> 	((buffer[5]>>2)&3)
>
>
> 	According to the standard, these fields should be 0 for
> standard profiles (table 8-5, table E-3), but I imagine that libmpeg2
> should apply these adjustment factors as defined by the specification
> in case there are video streams in which they are nonzero (Sony comes
> to mindm based on patent applications).
>
> 					Craig Milo Rogers
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Libmpeg2-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmpeg2-devel
>

[mpeg2-dev] frame_rate_extension_n

[Craig M. R. <ro...@IS...>]

	Hello.  I'm browsing through the SVN trunk for libmpeg2,
revision 1171.  My reference document is ISO 13818-2.  I'm looking at the
frame rate calculation in "libmpeg2/header.c".  I understand that
libmpeg2 calculates a reciprocal, called frame_period.  What bothers
me is the frame rate extension adjustment in the routine sequence_ext,
in the following line:

    sequence->frame_period =
        sequence->frame_period * ((buffer[5]&31)+1) / (((buffer[5]>>2)&3)+1);


1)	It modifies frame_period in place.  If it is possible to have
	two or more extension headers after a single sequence header
	(I haven't yet figured out if the ISO spec says anything about
	this possibility), then it seems to me that each frame rate
	(frame_period) adjustment should start with the value from the
	last sequence header (from my reading of section 6.3.3 of the spec).
	The current libmpeg2 code would compound them, and this seems
	incorrect.

2)	Based on section 6.2.2.3 of ISO 13818-2, frame_rate_extension_n
	is a 2-bit field located before the 5-bit frame_rate_extension_d
	field.  That implies that the correct way to extract this field
	is:

        ((buffer[5]>>5)&3)

	not:

	((buffer[5]>>2)&3)


	According to the standard, these fields should be 0 for
standard profiles (table 8-5, table E-3), but I imagine that libmpeg2
should apply these adjustment factors as defined by the specification
in case there are video streams in which they are nonzero (Sony comes
to mindm based on patent applications).

					Craig Milo Rogers

Re: [mpeg2-dev] extract duration from MPEG files

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

On Fri, 2 May 2008, Thomas Richards wrote:

> I now have a first-pass solution working. Basically I iterate over the 
> entire file, and count the number of times I get STATE_PICTURE from the 
> mpeg2_parse function.
>
> This works, but it's horribly slow. A 24 minute clip (400 MB on disk) 
> takes over a minute to parse (84 seconds).

> I was hoping someone here would know a few tricks to speed up this 
> performance. One thing I have thought of is increasing the size of my 
> memory buffer from 4KB to some larger value, but it doesn't seem to help 
> that much (using 8KB reduces the time from 84 to 81 seconds).

Hi Thomas,

Certainly, decoding the entire stream with libmpeg2 is not going to get 
you the best performance if you just want to measure the duration. 
Experimenting with mpeg2_skip() will probably speed things up, but a 
dedicated program to do this will probably be faster still.

And mmap()ing the file will probably improve performance as well.

Also keep in mind -- counting Pictures is not enough. You need to count 
frames. A Picture can last 0.5, 1, 1.5, 2, or 3 frames, depending on 
progressive_sequence, picture_structure, progressive_frame, 
top_field_first, and repeat_first_field. (libmpeg2 helpfully does all the 
logic and puts it in the nb_fields field.)

Here's a simple example program that does this standing alone. On a 3 GHz 
Pentium 4, it takes about 4.1 seconds to do a 1 GB, 35,919-picture, 
1,498-second slice from a DVD. That's about 27 times faster than libmpeg2 
decoding the whole thing.

http://web.mit.edu/keithw/www/mpegduration.c

(On 32-bit Linux, the example only works on files smaller than 2 GB.)

Regards,
Keith

========================

/* http://web.mit.edu/keithw/www/mpegduration.c */

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <stdint.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

/* compile with: gcc -g -Wall -O2 -o mpegduration mpegduration.c */

/* MPEG-2 tables */
const char type[ 4 ] = { 'X', 'I', 'P', 'B' };
const double frame_rate_value[ 9 ] = { 0, 24000.0/1001.0, 24, 25,
 				       30000.0/1001.0, 30, 50, 60000.0/1001.0,
 				       60 };

/* Check for picture start code */
inline int picture_coding_extension_start_code( uint8_t *buf ) {
   if ( (buf[ 0 ] == 0) &&
        (buf[ 1 ] == 0) &&
        (buf[ 2 ] == 1) &&
        (buf[ 3 ] == 0xB5) &&
        ((buf[ 4 ] >> 4) == 8) )
     return 1;

   return 0;
}

/* Check for sequence header code */
inline int sequence_header_code( uint8_t *buf ) {
   if ( (buf[ 0 ] == 0) &&
        (buf[ 1 ] == 0) &&
        (buf[ 2 ] == 1) &&
        (buf[ 3 ] == 0xB3) )
     return 1;

   return 0;
}

/* Check for sequence extension start */
inline int sequence_extension_start_code( uint8_t *buf ) {
   if ( (buf[ 0 ] == 0) &&
        (buf[ 1 ] == 0) &&
        (buf[ 2 ] == 1) &&
        (buf[ 3 ] == 0xB5) &&
        ((buf[ 4 ] >> 4) == 1) )
     return 1;

   return 0;
}

int main( int argc, char *argv[] ) {
   int fd;
   uint8_t *mpeges;
   struct stat thestat;
   off_t i = 0;
   char progressive_sequence = 0;
   uint8_t frame_rate_code = 0;
   char frame_rate_extension_n = 0, frame_rate_extension_d = 0;
   char sequence_header_hit = 0, sequence_extension_hit = 0;
   int pictures = 0;
   double seconds = 0;
   double frame_rate = 0;
   double field_duration = 0;

   /* Check arguments */
   if ( argc != 2 ) {
     fprintf( stderr, "Usage: %s FILENAME\n", argv[ 0 ] );
     exit( 1 );
   }

   /* Open MPEG-2 video elementary stream */
   /* On a 32-bit system, this will not open files bigger than 4 GB. */
   fd = open( argv[ 1 ], O_RDONLY );
   if ( fd < 0 ) {
     perror( "open" );
     exit( 1 );
   }

   /* Get size of file */
   if ( fstat( fd, &thestat ) < 0 ) {
     perror( "fstat" );
     exit( 1 );
   }

   /* Memory-map file */
   mpeges = mmap( NULL, thestat.st_size, PROT_READ, MAP_SHARED, fd, 0 );
   if ( mpeges == MAP_FAILED ) {
     perror( "mmap" );
     exit( 1 );
   }

   /* Iterate through every byte of file */
   while( i < thestat.st_size - 10 ) {
     if ( sequence_header_code( mpeges + i ) ) {
       /* Get first part of frame rate from the Sequence header */
       frame_rate_code = mpeges[ i + 7 ] & 0x0F;

       sequence_header_hit = 1;
     } else if ( sequence_header_hit
 		&& sequence_extension_start_code( mpeges + i ) ) {
       /* From Sequence extension, get progressive_sequence and */
       /* other components of true frame rate. */
       /* (Streams at common frame rates leave these at 0.) */
       progressive_sequence = (mpeges[ i + 5 ] >> 3) & 0x01;
       frame_rate_extension_n = (mpeges[ i + 9 ] >> 5) & 0x03;
       frame_rate_extension_d = mpeges[ i + 9 ] & 0x1F;

       frame_rate = frame_rate_value[ frame_rate_code ]
 	* (frame_rate_extension_n + 1.0) / (frame_rate_extension_d + 1.0);
       field_duration = 0.5 / frame_rate;

       sequence_extension_hit = 1;
     } else if ( sequence_header_hit
 		&& sequence_extension_hit
 		&& picture_coding_extension_start_code( mpeges + i ) ) {
       /* Get variables from Picture coding extension */
       /* These determine duration of picture */
       int picture_structure, top_field_first,
 	repeat_first_field, progressive_frame;
       int fields = -1;
       int frame_picture = 0;

       picture_structure = mpeges[ i + 6 ] & 0x03;
       top_field_first = mpeges[ i + 7 ] >> 7;
       repeat_first_field = (mpeges[ i + 7 ] >> 1) & 0x01;
       progressive_frame = mpeges[ i + 8 ] >> 7;

       if ( picture_structure == 3 ) frame_picture = 1;

       /* Calculate how many fields picture is */
       if ( frame_picture == 0 ) {
 	fields = 1;
       } else if ( progressive_sequence ) {
 	if ( repeat_first_field == 0 ) fields = 2;
 	if ( (repeat_first_field == 1) && (top_field_first == 0) ) fields = 4;
 	if ( (repeat_first_field == 1) && (top_field_first == 1) ) fields = 6;
       } else { /* interlaced sequence */
 	if ( progressive_frame == 0 ) fields = 2;
 	if ( (progressive_frame == 1) && (repeat_first_field == 0) ) fields = 2;
 	if ( (progressive_frame == 1) && (repeat_first_field == 1) ) fields = 3;
       }

       if ( fields == -1 ) {
 	fprintf( stderr, "Warning: illegal flags on picture #%d\n", pictures );
       } else {
 	seconds += field_duration * fields;
       }

       pictures++;
     }

     i++;
   }

   printf( "MPEG-2 file contained %d pictures. Total duration: %.3f seconds.\n",
 	  pictures, seconds );

   return 0;
}

[mpeg2-dev] libmpeg-0.4.1: dropping b-frames. when sequence information changes

[Tomi O. <tom...@gu...>]

On Thu 01 May 2008 17:51, Tomi Ollila <tom...@gu...> writes:

Continuing my monology (with modified subject) :)

> On Thu 01 May 2008 16:16, Tomi Ollila <tom...@gu...> writes:
>
>> Hi
>>
>>
>> Is this known issue? If not, I can do more detailed study on the
>> problem.

.. it seems this is known...

>
> Hmm, the 'new sequence' has something to do with my problem: When
> I get 'SEQUENCE_END' (or 'SEQUENCE_INVALID_END'), I (currently) refuse to
> decode anything more (the one display_fbuf which might be there is used)
> ... but If I did -- next (display) frame is a 'B' -frame, 
> according to sample* examples I should release buffers from libmpeg, 
> losing the one reference frame from previous gop for that frame (?).

... I compiled svn revision 1171 of libmpeg2 and linked my software against
it and my problem vanished away. 

Now when do we get a release?

>> Tomi
>>  

Thank you, libmpeg2 has been very useful.

Tomi

Re: [mpeg2-dev] extract duration from MPEG files

[Tomi O. <tom...@gu...>]

On Fri 02 May 2008 13:20, "Thomas Richards" <tho...@pe...> writes:

> Hi Everyone,
>
>
> Thanks for your replies!
>
> I now have a first-pass solution working. Basically I iterate over the
> entire file, and count the number of times I get STATE_PICTURE from the
> mpeg2_parse function.
>
> This works, but it's horribly slow. A 24 minute clip (400 MB on disk)
> takes over a minute to parse (84 seconds).

Does it help if you execute 'mpeg_skip(decoder, 1);' ?

> However, I notice that when I open the file in a media player (VLC for
> example), it displays the duration instantly.

Maybe that does some educated quess from bitrate of first sequence header, 
or from file size, or it seeks to the end of file and check the time
last GOP header contains.

> I was hoping someone here would know a few tricks to speed up this
> performance. One thing I have thought of is increasing the size of my
> memory buffer from 4KB to some larger value, but it doesn't seem to help
> that much (using 8KB reduces the time from 84 to 81 seconds).
>
> Is there something I'm missing? I can't help but feel that my algorithm
> is horribly naïve - there must be a better way to do this. Is this the
> best performance I can reasonably expect?

My http://www.iki.fi/too/sw/m2vmp2cut/mpeg2info.c, which just scanned
2,3Gib m2v file in around 80 seconds on a 2Ghz Intel Pentium M processor
(well, the execution was disk access bound, 'top' show 10% CPU usage).
That tool is (currenty) somewhat dummy, it can scan m2v elementary streams
OK, but there is things that are not done for other kind of mpeg2 video
files (work-in-progress, but sloooowly).

>
>
> Thanks again!
>
> --
> Thomi Richards
> Programmer
>

Tomi

Re: [mpeg2-dev] extract duration from MPEG files

[Thomas R. <tho...@pe...>]

Hi Everyone,


Thanks for your replies!

I now have a first-pass solution working. Basically I iterate over the entire file, and count the number of times I get STATE_PICTURE from the mpeg2_parse function.

This works, but it's horribly slow. A 24 minute clip (400 MB on disk) takes over a minute to parse (84 seconds).

However, I notice that when I open the file in a media player (VLC for example), it displays the duration instantly.

I was hoping someone here would know a few tricks to speed up this performance. One thing I have thought of is increasing the size of my memory buffer from 4KB to some larger value, but it doesn't seem to help that much (using 8KB reduces the time from 84 to 81 seconds).

Is there something I'm missing? I can't help but feel that my algorithm is horribly naïve - there must be a better way to do this. Is this the best performance I can reasonably expect?


Thanks again!

--
Thomi Richards
Programmer

[mpeg2-dev] Re: extract duration from MPEG files

[Lionel D. <lio...@ya...>]

Hello Thomas,

> I'm attempting to write a small application that extracts the durations
> from MPEG2 files. I've been looking at the documentation and the
> samples, and have come up with a simple app that calls "mpeg2_parse()"
> until it returns "STATE_GOP", and when it does, looks at the
> "info->gop->*" members.
> 
> I have two small problems:
> 
> The first is that the gop information seems to be the current position
> in the stream, which means that the only way I can read the entire
> stream length is to read the entire file, and save the last result.
> 
> The second problem I have is that some files don't seem to have a GOP
> section.
> 
> Is the total stream duration stored somewhere in the file?
Not as far as I know.
> If so, is there an easy method to extract it?
I think you can compute the stream duration using the framerate 
information contained in the stream header, and the number of pictures 
in the stream.
See the second line of the output of `mpeg2dec -vvvv <file.m2v>`:

       5a S- --- --- - SEQUENCE MPEG2 MP@ML PROG 352x240 chroma 176x120 
fps 29.97 maxBps 187500 vbv 135168 picture 352x240 display 352x240 pixel 1x1
[...]

The code which prints this line is in trunk/src/dump_state.c, and the 
frame rate determination code is in trunk/libmpeg2/header.c 
(mpeg2_header_sequence).


Regards, Lionel Debroux.

Re: [mpeg2-dev] extract duration from MPEG files

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

On Thu, 1 May 2008, Thomas Richards wrote:

> I'm attempting to write a small application that extracts the durations
> from MPEG2 files. I've been looking at the documentation and the
> samples, and have come up with a simple app that calls "mpeg2_parse()"
> until it returns "STATE_GOP", and when it does, looks at the
> "info->gop->*" members.
>
> I have two small problems:
>
> The first is that the gop information seems to be the current position
> in the stream, which means that the only way I can read the entire
> stream length is to read the entire file, and save the last result.
>
> The second problem I have is that some files don't seem to have a GOP
> section.
>
> Is the total stream duration stored somewhere in the file? If so, is
> there an easy method to extract it?

Hi Thomas,

You will have to read the entire file (or at least until a Sequence end 
code), if you want this to work on MPEG-2 video elementary streams or 
MPEG-2 system streams.

The reason is that MPEG-2 really specifies a syntax for video streams or 
sequences -- think an HDTV broadcast that goes on forever. There's no 
notion of a "file" in the specification. Some non-MPEG-2 container 
formats, obviously, do have a notion of "file" and total duration.

I believe the only real way to do it is to count up the number of frames 
and multiply by the frame rate given in the Sequence header.

You can't rely on the GOP header -- it's optional.

Hope this helps.

Best,
Keith

Re: [mpeg2-dev] libmpeg-0.4.1: SEQUENCE_END missing -> dropping pictures.

[Tomi O. <tom...@gu...>]

On Thu 01 May 2008 16:16, Tomi Ollila <tom...@gu...> writes:

> Hi
>
> ... I have one m2v elementary stream recorded from DVB-T source and the
> demuxed with ProjectX. Just after commercial break aspect ratio is changed
> from 4:3 to 16:9. At this point libmpeg2 does not return last 2 4:3 frames
> to me. Interestingly enough, the first gop in this 16:9 sequence is open
> (ok, the 2 dropped pictures are from this new sequence but this should not
> matter -- and the movie continues w/ frame 11 (P) from previous
> (4:3)gop, which contents are almost identical with frame 2 (I) from current
> (16:9) gop).
>
> Is this known issue? If not, I can do more detailed study on the problem.

Hmm, the 'new sequence' has something to do with my problem: When
I get 'SEQUENCE_END' (or 'SEQUENCE_INVALID_END'), I (currently) refuse to
decode anything more (the one display_fbuf which might be there is used)
... but If I did -- next (display) frame is a 'B' -frame, 
according to sample* examples I should release buffers from libmpeg, 
losing the one reference frame from previous gop for that frame (?).

>
> Tomi
>  

[mpeg2-dev] libmpeg-0.4.1: SEQUENCE_END missing -> dropping pictures.

[Tomi O. <tom...@gu...>]

Hi

I've noticed if input for libmpeg2 before EOF is missing SEQUENCE_END (00 00 01 b7)
last 2 pictures do not come out from libmpeg2.

This is usually not a problem as it is easy to provide that data when input
source ends, but there are at least one other case as well...

... I have one m2v elementary stream recorded from DVB-T source and the
demuxed with ProjectX. Just after commercial break aspect ratio is changed
from 4:3 to 16:9. At this point libmpeg2 does not return last 2 4:3 frames
to me. Interestingly enough, the first gop in this 16:9 sequence is open
(ok, the 2 dropped pictures are from this new sequence but this should not
matter -- and the movie continues w/ frame 11 (P) from previous
(4:3)gop, which contents are almost identical with frame 2 (I) from current
(16:9) gop).

Is this known issue? If not, I can do more detailed study on the problem.

Tomi
 

[mpeg2-dev] extract duration from MPEG files

[Thomas R. <tho...@pe...>]

Hello List,


I'm attempting to write a small application that extracts the durations
from MPEG2 files. I've been looking at the documentation and the
samples, and have come up with a simple app that calls "mpeg2_parse()"
until it returns "STATE_GOP", and when it does, looks at the
"info->gop->*" members.

I have two small problems:

The first is that the gop information seems to be the current position
in the stream, which means that the only way I can read the entire
stream length is to read the entire file, and save the last result.

The second problem I have is that some files don't seem to have a GOP
section.

Is the total stream duration stored somewhere in the file? If so, is
there an easy method to extract it?


Thanks!

--
Thomi Richards
Programmer

Re: [mpeg2-dev] release?

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

On Wed, Apr 30, 2008 at 07:39:00PM +0200, Diego Biurrun wrote :
> So, all patches that were posted recently have been applied.  How about
> making a libmpeg2 release now?  A branch release would be very helpful
> for me since it I could easily import it into MPlayer :)

I am for a release too. :D

Best Regards,

-- 
Jean-Baptiste Kempf
http://www.jbkempf.com/

[mpeg2-dev] release?

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

So, all patches that were posted recently have been applied.  How about
making a libmpeg2 release now?  A branch release would be very helpful
for me since it I could easily import it into MPlayer :)

Diego

Re: [mpeg2-dev] [updated PATCH] Re: [PATCH] warning fixes

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

At 13:47 +0200 13/04/08, Lionel Debroux wrote:

>>  > Here's a patch that fixes a number of warnings triggered by uncommon
>  > > GCC switches such as -Wshadow and -Wwrite-strings.
>>You will likely have more luck if you split this patchset. There are
>>fixes for multiple issues in it, some of which might not be acceptable.
>Splitting the patchset makes it easier to do a bisect for searching 
>regressions. However, the patchset is small, and since all chunks 
>but possibly two (the fixes for signed/unsigned mismatches in 
>conditional operators) are no-ops, I didn't feel that splitting the 
>patch was really necessary :)
>I have split the patch in 3 parts.

Applied (all of them).

Thanks,
-- 
Christophe Massiot.

[mpeg2-dev] Libmpeg2 questions.

[Алекс П. <ass...@ma...>]

Hi, everyone!
 I found this lib just recently, and unfortunately for me, all my program is made under vs2005. I managed to link prebuild lib files for WinCE, and now sample1.c runs fine for me on mobile 2003 device (well, with few exceptions). But, sample2.c outputs this error:

error LNK2019: unresolved external symbol mpeg2convert_rgb24 referenced in function "void __cdecl sample6(void *)" (?sample6@@YAXPAX@Z)

There was more of such errors before for #include "mpeg2.h" , but I fixed them this way:
extern "C" {
#include <inttypes.h>
#include "mpeg2.h"
#include "mpeg2convert.h"
}
The same solution is not working for mpeg2convert.h , so I can not use mpeg2convert_rgb24 function at all.
Maybe someone can point me into something clever? 0_0
Regards, Konstantin.

Re: [mpeg2-dev] "dest" parameter in mpeg2_idct_copy and mpeg2_idct_add functions

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

Hi Mateus,

You're right that the literal output of the inverse DCT is saturated to 
the range [-256 .. 255]. MPEG-2 pt. 2 calls this the "transform data," 
f[y][x]. See clause 7.5.

Meanwhile, the motion vectors are applied to other pictures to produce 
blocks of "prediction samples," p[y][x].

The "final decoded samples," d[y][x], are computed by adding together 
f[][] and p[][] and then clipping to the range [0 .. 255]. See clause 
7.6.8.

The output of mpeg2_idct_add...() isn't the transform data f[][] -- it's 
the final decoded samples d[][], after adding in the prediction samples. 
So that's why it's okay to clip to [0 .. 255].

I think mpeg2_idct_copy...() is the same deal, except you use it in cases 
without any prediction samples to add in (i.e. an intra-coded block). But 
its output is still d[][], not f[][], so that's why the output is clipped 
to be positive.

Best,
Keith

On Wed, 16 Apr 2008, Mateus Krepsky Ludwich wrote:

> Hello,
>    I have a doubt about the "dest" parameter in mpeg2_idct_copy and
> mpeg2_idct_add functions: according to IEEE STD 1180 the output of IDCT
> after
> clipping must be in range (-256, 255), i.e. 9 bits. The dest parameter is a
> array of uint8_t, range(0, 255). How it can be? If is used another variable
> that
> indicates the signal, with 8 bits we can represent (-255, 255) even in this
> case
> the number -256 can't be represented. Someone can help me here?
>
> Greetings,
>
> Mateus Krepsky Ludwich.
>

[mpeg2-dev] "dest" parameter in mpeg2_idct_copy and mpeg2_idct_add functions

[Mateus K. L. <mkl...@gm...>]

Hello,
    I have a doubt about the "dest" parameter in mpeg2_idct_copy and
mpeg2_idct_add functions: according to IEEE STD 1180 the output of IDCT
after
clipping must be in range (-256, 255), i.e. 9 bits. The dest parameter is a
array of uint8_t, range(0, 255). How it can be? If is used another variable
that
indicates the signal, with 8 bits we can represent (-255, 255) even in this
case
the number -256 can't be represented. Someone can help me here?

Greetings,

Mateus Krepsky Ludwich.