libmpeg2-devel — main mailing list for libmpeg2 development

Re: [mpeg2-dev] Decoding MPEG-TS stream

[Måns R. <mr...@in...>]

Bob Ingraham <bo...@br...> writes:

> Hi All,
>
> I've written an app which uses the Linux DVB API to pull down an MPEG2-TS.
>
> Currently it:
>
> 1. Decodes the TS header
> 2. Extracts the MPEG2 encoded frame
> 3. Decompresses it with libavcodec (an ffmpeg library)
> 4. Renders it with SDL
>
> But I wanted to try libmpeg2 to see if it's decoder will yield
> better results than libavcodecs.

Better in what way?

> Questions:
>
> 1. Does libmpeg2 perform steps 1 through 3 above?

No, it only does step 3.

> 2. Can I just pass an compressed MPEG2 frame to libmpeg2 (without
> any PS, TS or PES headers?)

Yes, in fact you have to.

> 3. Apparently, the Linux DVB API filter removes all PES headers and
> hands me a TS stream with just the raw mpeg2 frames after the
> TS/adaption field header.

No, this is incorrect.

> I don't think this is normal, because the MPEG2 spec says that mpeg2
> frames should be encapsulated within PES packets within the TS
> frames.
>
> Does this seem odd that there are no PES header?

Check again or change some setting.  I know I have got proper TS
streams from the Linux DVB interface.

-- 
Måns Rullgård
ma...@ma...

[mpeg2-dev] Decoding MPEG-TS stream

[Bob I. <bo...@br...>]

Hi All,

I've written an app which uses the Linux DVB API to pull down an MPEG2-TS.

Currently it:

1. Decodes the TS header
2. Extracts the MPEG2 encoded frame
3. Decompresses it with libavcodec (an ffmpeg library)
4. Renders it with SDL

But I wanted to try libmpeg2 to see if it's decoder will yield better results than libavcodecs.

Questions:

1. Does libmpeg2 perform steps 1 through 3 above?

2. Can I just pass an compressed MPEG2 frame to libmpeg2 (without any PS, TS or PES headers?)

3. Apparently, the Linux DVB API filter removes all PES headers and hands me a TS stream with just the raw mpeg2 frames after the TS/adaption field header.

I don't think this is normal, because the MPEG2 spec says that mpeg2 frames should be encapsulated within PES packets within the TS frames.

Does this seem odd that there are no PES header?

Thanks,
Bob

[mpeg2-dev] video data missing/corruption

[Simon T. <sim...@ya...>]

If mpeg2 video data has missing/corruption during decoding, is any way to know the mpeg2 data missing/corruption? I have tried to look through the mpeg2 source code and cannot find where the library report video data missing (or corruption).


      

[mpeg2-dev] speed increase!?

[Jan P. <pet...@ya...>]

Hello, i took one of your samples and included a small linux framebuffer output routine to it.
Now i can watch mpeg2 videos on console.
My problem is, i use a very slow cpu (blackfin architecture) and the video is slow.
If i use the mplayer on the same system, the video is a little bit faster, but the mplayer uses the same library.
Is there a way to increase the speed of my video using libmpeg2?
Or if someone have a better working framebuffer routine can he post it to me?

thats mine:

static void print_screen (int width, int height, uint8_t * buf)
{    
a=0;
for(y=0;y<height;y++)
    for(x=0;x<width;x++){

    location = (x+vinfo.xoffset) * (vinfo.bits_per_pixel/8) +
            (y+vinfo.yoffset) * finfo.line_length;

        *(fbp + location) = buf[a];
        *(fbp + location + 1) = buf[a+1];
      
    a=a+2;
}
}
greetings jan


      

Re: [mpeg2-dev] MPEG-PS (DVD) Atomizer?

[Hibiki K. <hib...@gm...>]

Let me see if I can sort of prioritize things, or
at least give a partial ordering of priorities.

In a perfect world, I would extract every single
frame/field/picture into a separate file along
with a duration that frame should be shown, and
similarly, the audio could be split up so there
are Ki (K is some whole number) independent audio
samples which go with picture i.

Then I could totally shuffle around all the
individual frames/pictures, put them back together
in a different permutation, and put it back into
a new MPEG-PS which has the same duration as the
original, and has all the same frames (with both
the video and the sound which was playing during
that frame), but in a different order. since no
information has been lost, I could later unshuffle
everything and get back the original MPEG-PS.

This is not my end goal, but if I had a choice
between either having this capability but having to
re-encode everything, or only having a granularity
of several seconds between cuts, I would prefer the
former.  Maybe a way to put it succinctly is that I
/need/ the ability to cut/splice at a frame/picture
level, but I /want/ to avoid (lossily) re-encoding.

Presuming I can lossily split any segment into single
frames keeping exact timing information, and lossily
put it back together again, I will ballpark estimate
that if the stream was split into segments of 15
seconds each, the probability I would want to cut a
given segment is 10%, for 1 minute each, 25%, and for
4 minutes each, 50%.  I am just trying to give a rough
idea of how much compromise there would need to be,
presuming if I am going to make a cut, I will have to
lossily convert that whole segment into single frames.
So if the average length of each segment was going to
be 5 minutes, I might was well just split the whole
file into individual frames, because I am going to
have to do that for most of the frames anyway.

A couple mitigating factors are that I am not worried
much about time and space issues.  If I need 50GiB to
unpack a 1GiB VOB, that would be ok, and 0.5 seconds
per frame to decode/encode would be ok.  Also, as far
as the audio, it is ok of the sample duration for the
audio and the frame duration for the video are coprime.
I do not mind fudging the audio.

Another thing is I do not /anywhere/ have any
sort of hard constraint of /no/ loss of video
information.  In other words I am not going to, for
example, try to find the correlation between two
video streams by comparing individual frames, so if
as a practical matter there is enough information
in a segment to re-encode it in an "in effect,
visually lossless" way, that would be ok.  I think
there is an option with mplayer (mencoder) to split
a stream into one PNG file per (what it thinks is
a) frame/field/picture, and (presumably) to create
a new stream from that.  I am hoping to find a
significantly better approach than that.

I am not sure if I want to "[re-encode] frames
around the edges while still producing a conforming
MPEG-2 program stream with the VBV and all that".  I
do want to be able to split a VOB into segments with
minimal loss of information ("minimal" meaning "as
little as I can feasibly achieve"), re-encode some
of the segments, and put it back together into a
valid MPEG-PS stream (eg that a typical consumer DVD
player can successfully play).

If there was already a simple command-line tool, or if
I got to wave my magic wand to create one, it would
be nice if I could tell it to start by splitting a
VOB into segments "visually losslessly", and then
to be able to take a particular segment, and tell
it to split that segment further, such that all the
segments have at least N quality, where "N" is similar
to saving a raster image as JPEG, and if the "quality"
is set to "1", there is a file for every frame.

Re: [mpeg2-dev] MPEG-PS (DVD) Atomizer?

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

Hi Hibiki,

We can help walk you through this, and I'm happy to help you with some 
demo code if you'd like. I don't know of any existing program that meets 
your needs.

It might help if you explained what the overarching goal is.

The problem is that MPEG-2 may be more interdependent than you realize. In 
general, GOPs (groups of pictures) are "open" -- meaning the first 
B-pictures in a GOP generally depend on reference frames coded within the 
previous GOP.

Thus, in general, there is no place you can split an MPEG-2 video 
bitstream have the two segments each be independent. The earliest few 
pictures in the second part will depend on the latest reference frame 
coded in the first part.

DVDs do have chapters, and chapters generally start with a "closed" GOP so 
the DVD player can seek directly to them and start playing immediately. So 
you could split a DVD on the chapter boundaries in the manner you're 
describing.

If that's good enough for you (splitting every 20 minutes or so, or 
however the DVD chapters are divided up), then we can help you write a 
program that splits the video bitstream everywhere it finds a "closed" 
GOP. This is easy and under 50 lines of C.

The audio and video partitions won't match exactly, since audio and video 
frames don't coincide. But if we split a program stream everywhere we see 
the start of a closed GOP, for example, you'll be splitting the audio at 
places close by, and if you reassemble the fragments, it will match up 
again.

Let me know if this is what you had in mind (splitting only on closed 
GOPs, or basically just at chapter boundaries) and I can help you with it 
further.

If you want to start re-encoding frames around the edges while still 
producing a conforming MPEG-2 program stream with the VBV and all that, 
well, that's a lot harder.

Best,
Keith

On Thu, 26 Feb 2009, Hibiki Kanzaki wrote:

> I am interested in taking a DVD, or lets say an MPEG-PS VOB
> file from a DVD, and splitting it up into as many separate
> video segment files as I can (as few fields/frames/pictures
> per file) without splitting interdependent pictures...
> essentially without losing any information.
>
> As I am doing that, I would like to write a log of how many
> frames are in each segment, and what the framerate in it is,
> so I have a running total of the elapsed time, which I can
> use for synchronizing those segments with everything else.
>
> Or I guess I could wait to do the actual splitting and just
> write the log file along with corresponding byte offsets
> into the stream, and have something separate which can use
> the log file as an index to do splitting or extracting a
> set of frames based on the byte offset.
>
> I want to make sure I get all the information I need to
> line up all the streams in the program (video, audio,
> subtitles, etc), and make as precise incisions as I can
> without having to re-encode the video.  I do expect for
> a select few segments I will actually split them into
> individual frames and have to re-encode them.
>
> As trivial as I expect this would be for somebody familiar
> with the low level details, I am having trouble finding
> a set of programs which provide it out of the box.  Is
> something equivalent to this already available using the
> existing tools (like mpeg2dec), or trivial to build on
> libmpeg2?  Or maybe there is something like the transcode
> tcprobe and avisplit stuff which can already do this?
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Libmpeg2-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmpeg2-devel
>

[mpeg2-dev] MPEG-PS (DVD) Atomizer?

[Hibiki K. <hib...@gm...>]

I am interested in taking a DVD, or lets say an MPEG-PS VOB
file from a DVD, and splitting it up into as many separate
video segment files as I can (as few fields/frames/pictures
per file) without splitting interdependent pictures...
essentially without losing any information.

As I am doing that, I would like to write a log of how many
frames are in each segment, and what the framerate in it is,
so I have a running total of the elapsed time, which I can
use for synchronizing those segments with everything else.

Or I guess I could wait to do the actual splitting and just
write the log file along with corresponding byte offsets
into the stream, and have something separate which can use
the log file as an index to do splitting or extracting a
set of frames based on the byte offset.

I want to make sure I get all the information I need to
line up all the streams in the program (video, audio,
subtitles, etc), and make as precise incisions as I can
without having to re-encode the video.  I do expect for
a select few segments I will actually split them into
individual frames and have to re-encode them.

As trivial as I expect this would be for somebody familiar
with the low level details, I am having trouble finding
a set of programs which provide it out of the box.  Is
something equivalent to this already available using the
existing tools (like mpeg2dec), or trivial to build on
libmpeg2?  Or maybe there is something like the transcode
tcprobe and avisplit stuff which can already do this?

[mpeg2-dev] MPEG-PS (DVD) Atomizer?

[Hibiki K. <hib...@gm...>]

I am interested in taking a DVD, or lets say an MPEG-PS VOB
file from a DVD, and splitting it up into as many separate
video segment files as I can (as few fields/frames/pictures
per file) without splitting interdependent pictures...
essentially without losing any information.

As I am doing that, I would like to write a log of how many
frames are in each segment, and what the framerate in it is,
so I have a running total of the elapsed time, which I can
use for synchronizing those segments with everything else.

Or I guess I could wait to do the actual splitting and just
write the log file along with corresponding byte offsets
into the stream, and have something separate which can use
the log file as an index to do splitting or extracting a
set of frames based on the byte offset.

I want to make sure I get all the information I need to
line up all the streams in the program (video, audio,
subtitles, etc), and make as precise incisions as I can
without having to re-encode the video.  I do expect for
a select few segments I will actually split them into
individual frames and have to re-encode them.

As trivial as I expect this would be for somebody familiar
with the low level details, I am having trouble finding
a set of programs which provide it out of the box.  Is
something equivalent to this already available using the
existing tools (like mpeg2dec), or trivial to build on
libmpeg2?  Or maybe there is something like the transcode
tcprobe and avisplit stuff which can already do this?

[mpeg2-dev] PLD instruction in motion_comp_arm_s.S instruction doesn't work on armv4

[<GN...@no...>]

Hello,
I tried to include a patch in mplayer but they told me that:
<DonDiego> this should really become part of upstream libmpeg2...
<DonDiego> we've been working hard to reduce the upstream diff...

Basically libmpeg2 can't be compiled on a toolchain made for armv4(and
obviously can't run on armv4) because the armv4 lacks the pld instruction.

see page 240 in http://www.arm.com/miscPDFs/14128.pdf

Armv4 is still used as today,such as in the openmoko(about 10 000 sales
according to
http://lists.openmoko.org/nabble.html#nabble-td2103754|a2103754)

could something like the following code be ok?

#ifndef HAVE_PLD
.macro pld reg
.endm
#endif

Thanks in advance for your advises

Re: [mpeg2-dev] PATCH: Fix public symbols on ARM

[Loïc M. <lo...@vi...>]

 poke!  (and happy new year!)

On Sat, Dec 20, 2008, Loïc Minier wrote:
> Set visibility of global symbols used in ARM specific assembly file to
> internal; spotted my make check on armel; thanks Riku Voipio for the report.
...
> Rewrite the public symbol check to verify the shared libraries, to check for
> more things, and to avoid duplication; fixes make check on ARM

-- 
Loïc Minier

[mpeg2-dev] PATCH: Fix public symbols on ARM

[Loïc M. <lo...@vi...>]

        Hi,

 Riku Voipio told me make check was failing on ARM; see:
 http://experimental.debian.net/fetch.php?&pkg=mpeg2dec&ver=0.5.1-1&arch=armel&stamp=1229436558&file=log&as=raw
 these are symbols in an ARM specific assembly file.  See attached patch
 60_arm-private-symbols for a fix.

 However even with this patch, the testsuite doesn't pass because a) it
 checks all object files instead of the final object files (i.e. the
 libs) and b) it uses nm which will report all global symbols in object
 files, ignoring the visibility attribute (these symbols are necessarily
 globals, yet aren't part of the ABI because they are of internal
 visibility).

 So I rewrote the globals test to verify the shared libraries, to check
 for more things, and to avoid duplication.  See attached patch
 61_global-symbol-test.  Note however than in a --disable-shared build,
 this test is now a no-op.  I think that's good enough as I expect
 distros and upstream releases to make check with shared libs enabled.
 If we want to run this check on static libraries, it will need to be
 based on something else than nm, perhaps objdump, and is likely to be
 more complex (objdump output is more complex and we need to test for
 scope and visibility ourselves).

   Cheers,
-- 
Loïc Minier

Re: [mpeg2-dev] Buffer Queues and libmpeg2

[Michel L. <wa...@zo...>]

On Wed, Nov 19, 2008 at 09:29:07AM +0100, Martin Hering wrote:
> I am currently experimenting with libmpeg2 for use in a video player
> project. I am currently using it straight out of the box and it works
> fine. When the decoder is finished and gives me back a display picture I
> just copy the display_fbuf to another buffer which can be queued for
> later playback. However this method is not very efficient since copying
> a block of memory as huge as a picture always imposes the burden of a
> big system load. I was wondering if I could simply switch the buffer
> pointers, say I give display_fbuf->buf[...] the pointers to the memory
> region that I would normaly queue up and queue up the display_fbuf->buf
> instead. However this is currently not possible due to being
> display_fbuf defined as const. I removed the const for testing only, but
> it seems that this is not a valid method, since my app crashes at some
> point. My question now is, is there a legal method of switching buffers
> or does anybody have a better solution?

Look at doc/sample5.c and doc/sample6.c, they do what you want, with the
app picking a new buffer at every STATE_PICTURE state and passing it to
the decoder.

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.

[mpeg2-dev] Buffer Queues and libmpeg2

[Martin H. <mar...@ma...>]

Hi,

I am currently experimenting with libmpeg2 for use in a video player
project. I am currently using it straight out of the box and it works
fine. When the decoder is finished and gives me back a display picture I
just copy the display_fbuf to another buffer which can be queued for
later playback. However this method is not very efficient since copying
a block of memory as huge as a picture always imposes the burden of a
big system load. I was wondering if I could simply switch the buffer
pointers, say I give display_fbuf->buf[...] the pointers to the memory
region that I would normaly queue up and queue up the display_fbuf->buf
instead. However this is currently not possible due to being
display_fbuf defined as const. I removed the const for testing only, but
it seems that this is not a valid method, since my app crashes at some
point. My question now is, is there a legal method of switching buffers
or does anybody have a better solution?

Best regards
Martin

Re: [mpeg2-dev] [PATCH] fix incorrect FSF address in license headers

[Michel L. <wa...@zo...>]

On Thu, Oct 09, 2008 at 08:57:18PM +0200, Lionel Debroux wrote:
> Nope, I meant replacing getopt.{c,h} with more recent versions that seem
> to have compatibility / portability improvements:
> * getopt.c: libmpeg2 has v1.37 (Sat Feb 12 07:33:25 2000 UTC), upstream
> has v1.57 (Sat Mar 29 20:19:18 2008 UTC);
> * getopt.h: libmpeg2 has v1.12 (Sun Nov 8 12:01:34 1998 UTC), upstream
> has v1.21 (Fri Mar 19 00:19:32 2004 UTC).
> (I've checked the versions for this mail, I hadn't done it before
> suggesting upgrading in my first mail.)

I don't know what the issues are with the old version, but I don't mind
upgrading either.

I'll ask though - it does not seem to make much sense to have externally
maintained source files in our version control tree. Maybe we could remove
these, and have the bootstrap script install these files from a pristine
source, like possibly /usr/share/gnulib/lib/getopt.c or something ?
This would mean that gnulib must be installed on the computer where
bootstrap is run. The tar.gz release files would not have that dependancy
though. Or, there might be other projects we can depend on, I'm not stuck
on gnulib, in fact I have never used it so far.

I dont have the time or inclination to deal with this, but I'd be open
to such changes if someone does.

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.

Re: [mpeg2-dev] [PATCH] fix incorrect FSF address in license headers

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

Diego Biurrun wrote:

> > What do you, and others, think about upgrading the getopt files ?
> 
> If by upgrading you mean fixing the license header like I just did
> for libmpeg2 then my answer is: I would leave the files untouched
> since they are externally imported files.
Nope, I meant replacing getopt.{c,h} with more recent versions that seem
to have compatibility / portability improvements:
* getopt.c: libmpeg2 has v1.37 (Sat Feb 12 07:33:25 2000 UTC), upstream
has v1.57 (Sat Mar 29 20:19:18 2008 UTC);
* getopt.h: libmpeg2 has v1.12 (Sun Nov 8 12:01:34 1998 UTC), upstream
has v1.21 (Fri Mar 19 00:19:32 2004 UTC).
(I've checked the versions for this mail, I hadn't done it before
suggesting upgrading in my first mail.)

> It's incredibly lame that not even the core GNU projects get
> this right.
Agreed.


Lionel.

Re: [mpeg2-dev] [PATCH] fix incorrect FSF address in license headers

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

On Thu, Oct 09, 2008 at 05:16:50PM +0200, Lionel Debroux wrote:
> Diego Biurrun wrote:
> 
> > > A nitpick about your patch that updates the FSF address: I
> > > noticed that trunk/src/getopt.{c,h} remain untouched.
> > 
> > Yes, that was done on purpose,
> Ah, OK.
> > these files are from glibc, not libmpeg2.
> Indeed, but is there something that prevents the libmpeg2 project from
> updating the FSF address in files originating from glibc and contained
> in libmpeg2, on the occasion of the same correction of factual
> information that has become wrong, in other files of the libmpeg2 project ?

Only the fact that the diff to the upstream versions of the files gets
bigger.

> >> What do people think ?
> > 
> > Your patch is wrong.
> > [snip]
> > Before your change this file was licensed LGPL, now it is a weird
> > mix of GPL and LGPL.  Also, before it said the file pertained to
> > the GNU C library, now it claims to belong to the GNU C library
> > in two places and to mpeg2dec in another place.
> Doh. Screw copy&paste without re-reading. Thanks for pointing out my
> mistake.
> 
> 
> What do you, and others, think about upgrading the getopt files ?

If by upgrading you mean fixing the license header like I just did for
libmpeg2 then my answer is: I would leave the files untouched since
they are externally imported files.

You could of course send the GNU C library people a patch to fix this.
It's incredibly lame that not even the core GNU projects get this right.

Diego

Re: [mpeg2-dev] [PATCH] fix incorrect FSF address in license headers

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

Diego Biurrun wrote:

> > A nitpick about your patch that updates the FSF address: I
> > noticed that trunk/src/getopt.{c,h} remain untouched.
> 
> Yes, that was done on purpose,
Ah, OK.
> these files are from glibc, not libmpeg2.
Indeed, but is there something that prevents the libmpeg2 project from
updating the FSF address in files originating from glibc and contained
in libmpeg2, on the occasion of the same correction of factual
information that has become wrong, in other files of the libmpeg2 project ?

>> What do people think ?
> 
> Your patch is wrong.
> [snip]
> Before your change this file was licensed LGPL, now it is a weird
> mix of GPL and LGPL.  Also, before it said the file pertained to
> the GNU C library, now it claims to belong to the GNU C library
> in two places and to mpeg2dec in another place.
Doh. Screw copy&paste without re-reading. Thanks for pointing out my
mistake.


What do you, and others, think about upgrading the getopt files ?


Lionel.

Re: [mpeg2-dev] [PATCH] fix incorrect FSF address in license headers

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

On Thu, Oct 09, 2008 at 03:12:15PM +0200, Lionel Debroux wrote:
> 
> A nitpick about your patch that updates the FSF address: I noticed that
> trunk/src/getopt.{c,h} remain untouched.

Yes, that was done on purpose, these files are from glibc, not libmpeg2.

> What do people think ?

Your patch is wrong.

> --- a/trunk/src/getopt.c
> +++ b/trunk/src/getopt.c
> @@ -16,10 +16,9 @@
>  
> -   You should have received a copy of the GNU Library General Public
> -   License along with the GNU C Library; see the file COPYING.LIB.  If not,
> -   write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
> -   Boston, MA 02111-1307, USA.  */
> +   You should have received a copy of the GNU General Public License along
> +   with mpeg2dec; if not, write to the Free Software Foundation, Inc.,
> +   51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.  */

Before your change this file was licensed LGPL, now it is a weird mix of
GPL and LGPL.  Also, before it said the file pertained to the GNU C
library, now it claims to belong to the GNU C library in two places and
to mpeg2dec in another place.

Diego

Re: [mpeg2-dev] [PATCH] fix incorrect FSF address in license headers

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

Hi Diego,

A nitpick about your patch that updates the FSF address: I noticed that
trunk/src/getopt.{c,h} remain untouched.

But anyway, judging from the log, these two files have been untouched
since their introduction in the libmpeg2 repository on 2001-07-23. Since
then, they have been modified upstream.
Therefore, maybe they could be upgraded, using e.g. CVS HEAD of
http://sourceware.org/cgi-bin/cvsweb.cgi/libc/posix/?cvsroot=glibc

What do people think ?


FWIW, the patch to update the FSF address of the getopt.{c,h} embedded
in libmpeg2 is attached.


Regards,
Lionel.

Re: [mpeg2-dev] [PATCH] fix incorrect FSF address in license headers

[Michel L. <wa...@zo...>]

On Thu, Oct 09, 2008 at 11:56:07AM +0200, Diego Biurrun wrote:
> The FSF changed headquarters a long time ago.  Here is a patch to update
> the license headers in libmpeg2 to reflect that change.  It also
> includes a similar change for the COPYING file.  I just replaced yours
> with the copy in /usr/share/common-licenses/GPL-2 on my Debian system.
> 
> Please apply.

Why not. Thanks!

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.

[mpeg2-dev] [PATCH] fix incorrect FSF address in license headers

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

The FSF changed headquarters a long time ago.  Here is a patch to update
the license headers in libmpeg2 to reflect that change.  It also
includes a similar change for the COPYING file.  I just replaced yours
with the copy in /usr/share/common-licenses/GPL-2 on my Debian system.

Please apply.

Diego

[mpeg2-dev] patch - code samples

[Michel L. <wa...@zo...>]

The attached diff modifies the code samples as follows:

* Allocate aligned buffers using mpeg2_malloc(), to avoid reimplementing
  this in the samples (and demonstrate usage - mpeg2_malloc() is public
  just so people can do this)

* In a few places, remove the local 'sequence' variable and replace with
  info->sequence - the main reason here being to limit differences between
  the various code samples.

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.

[mpeg2-dev] patch - compile code samples as part of the build

[Michel L. <wa...@zo...>]

The attached patch makes sure code samples will get compiled when
typing 'make'. This is both to test that they do compile, and to give
easy access to the binaries for running them.

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.

Re: [mpeg2-dev] [PATCH] remove a set of braces for consistency

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

On Sat, Sep 13, 2008 at 05:27:36PM +0200, Diego Biurrun wrote:
> Here is a small patch to remove an extra set of braces from
> libmpeg2/motion_comp.c in order to keep things consistent with the rest
> of the file.

Applied by Jean-Baptiste Kempf.

Diego

Re: [mpeg2-dev] general doubt about PES packetization.

[Michel L. <wa...@zo...>]

On Mon, Sep 15, 2008 at 07:21:46PM +0200, Michael Niedermayer wrote:
>> I believe mplayer violates this - it seems to mostly get away with
>> it, though.
> 
> Iam pretty sure mplayers demuxer does not violate this. Besides mplayer
> can use libavformat for demuxing (-demuxer lavf) which does also not depend
> on 1 picture per PES either.

Good, I was not sure about the above, so thanks for the clarification.

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.