libmpeg2-devel — main mailing list for libmpeg2 development

[mpeg2-dev] mpeg2dec bug report

[Ildar I. <ii...@is...>]

It is possible to create an input file (see the attach), which causes 
mpeg2dec (from libmpeg2-0.5.1) to crash with the floating point 
exception (division by zero).

This is how gdb output looks:

user@machine:$ gdb --args <libmpeg2_inst_dir>/bin/mpeg2dec -v exploit_0
...
This GDB was configured as "i486-linux-gnu"...
(gdb) run
Starting program: 
/space/iisaev/avalanche/libmpeg2-0.5.1/inst/bin/mpeg2dec -v 
exploits_libmpeg/exploit_0
libmpeg2-0.5.1 - by Michel Lespinasse <wa...@zo...> and Aaron Holtzman
      10 SEQUENCE PROG
Program received signal SIGFPE, Arithmetic exception.
dump_state (f=0x402e2560, state=<value optimized out>, info=0x91d3440, 
offset=16, verbose=1) at dump_state.c:349
349        fprintf (f, " %dx%d chroma %dx%d fps %.*f maxBps %d vbv %d "
(gdb) list
344                strncpy (matrix, colour[seq->matrix_coefficients], 15);
345            fprintf (f, " COLORS (prim %s trans %s matrix %s)",
346                 prim, trans, matrix);
347            }
348        }
349        fprintf (f, " %dx%d chroma %dx%d fps %.*f maxBps %d vbv %d "
350             "picture %dx%d display %dx%d pixel %dx%d",
351             seq->width, seq->height,
352             seq->chroma_width, seq->chroma_height,
353             27000000%seq->frame_period?2:0, 
27000000.0/seq->frame_period,
(gdb) p seq->frame_period
$1 = 0
(gdb) bt
#0  dump_state (f=0x402e2560, state=<value optimized out>, 
info=0x91d3440, offset=16, verbose=1) at dump_state.c:349
#1  0x08049b42 in decode_mpeg2 (current=<value optimized out>, 
end=<value optimized out>) at mpeg2dec.c:281
#2  0x0804b24f in main at mpeg2dec.c:758
(gdb)


As one may see, the essence of the bug is that the value 
seq->frame_period is used as a divisor without checking for being equal 
to 0.

Re: [mpeg2-dev] [RFC] [PATCH] ARM Advanced SIMD motion compensation

[Rémi Denis-C. <re...@vi...>]

On Wed, 16 Sep 2009 18:47:42 +0530 (IST), Giridhar Tammana
<gir...@ya...> wrote:
> On NEON alignment,
> There can be lot improvement in performance if buffers are aligned. Also
> interleaving stores would not throttle the store buffer.
> Maximum outstanding stores can be 8 dregisters.

IOW, we can spare one cycle per load or store with appropriate alignment.
That's what I said.

> There are no intrinsic for specifying alignment.

I do not think anyone proposed to use intrinsic functions. This patch uses
in-line assembly. Plain assembly should be used for further optimization
(I'd rather not unroll in-line assembly).

> So to get maximum memory bandwidth one has to align buffers and also use
> special instructions specifiers.

I think we cannot align buffers at least in some cases. Namely the X and XY
cases, some buffers are read with one byte offset... so at least one if not
both of the read must be unaligned.

That's why I'm asking if we can assume alignment in any case at all. The
SVN changelog mentions some aligned memory allocation, but I have not
looked at what that actually was about.

-- 
Rémi Denis-Courmont

Re: [mpeg2-dev] [RFC] [PATCH] ARM Advanced SIMD motion compensation

[Giridhar T. <gir...@ya...>]

On NEON alignment,
There can be lot improvement in performance if buffers are aligned. Also interleaving stores would not throttle the store buffer.
Maximum outstanding stores can be 8 dregisters.

Instructions in A8 are statically scheduled and hence there are two varieties of loads and stores one without specifying alignment restriction and other with alignment restriction (@64, @128, @256 bits alignment). There are no intrinsic for specifying alignment.

So to get maximum memory bandwidth one has to align buffers and also use special instructions specifiers.

Example:
Example:
VLD1    {d0},[pSrc]        ;// takes 2 cycles
VLD1    {d0,d1},[pSrc@64]  ;// takes 1 cycles
VST1    {d0},[pDst]        ;// takes 2 cycles
VST1    {d0,d1},[pDst@64]  ;// takes 1 cycles

VLD1    {d0,d1},[pSrc]     ;// takes 2 cycles
VLD1    {d0,d1},[pSrc@128] ;// takes 1 cycles
VST1    {d0,d1},[pDst]     ;// takes 2 cycles
VST1    {d0,d1},[pDst@128] ;// takes 1 cycles

For more information on code examples one can check 
http://www.arm.com/products/multimedia/openmax/index.html

Regards,
/G


--- On Wed, 9/16/09, Rémi Denis-Courmont <re...@vi...> wrote:

> From: Rémi Denis-Courmont <re...@vi...>
> Subject: [mpeg2-dev] [RFC] [PATCH] ARM Advanced SIMD motion compensation
> To: lib...@li...
> Date: Wednesday, September 16, 2009, 1:42 AM
>     Hello all,
> 
> ARMv7 includes an optional "Advanced SIMD" instructions
> set, commercially 
> known as NEON. This is included in the recent Cortex line
> of ARM processors. 
> In particular, Cortex-A8 is found on TI-OMAP3xxx boards
> such as BeagleBoard, 
> or the Nokia N900.
> 
> Attached is an intial patch against libmpeg2 trunk to use
> NEON for motion 
> compensation. This is preliminary. There are a bunch of
> known CPU stalls. 
> Those could probably be fixed using plain assembly and
> interleaving subsequent 
> loads. Also, iDCT is not optimized. Anyway, here are my
> results with an 
> OMA3430 board:
> 
> With C, no acceleration:
> 7305 frames in 19.87 sec (367.64 fps), 155 last 0.50 sec
> (310.00 fps)
> 7308 frames decoded in 19.88 seconds (367.61 fps) 
>                
>   
> 7288 frames in 19.88 sec (366.60 fps), 170 last 0.50 sec
> (340.00 fps)
> 7308 frames decoded in 19.95 seconds (366.32 fps) 
>                
>   
> 
> With ARM acceleration (current libmpeg2):
> 7254 frames in 18.88 sec (384.22 fps), 180 last 0.50 sec
> (360.00 fps)
> 7308 frames decoded in 19.04 seconds (383.82 fps)
> 7263 frames in 18.88 sec (384.69 fps), 175 last 0.50 sec
> (350.00 fps)
> 7308 frames decoded in 19.02 seconds (384.23 fps)
> 
> With NEON acceleration (this patch):
> 7129 frames in 15.39 sec (463.22 fps), 245 last 0.50 sec
> (490.00 fps)
> 7308 frames decoded in 15.85 seconds (461.07 fps)
> 7127 frames in 15.38 sec (463.39 fps), 245 last 0.50 sec
> (490.00 fps)
> 7308 frames decoded in 15.85 seconds (461.07 fps)
> 
> So, there is already quite a big improvement!
> 
> I wonder if there is any warranty on the memory alignment
> of some of the 
> buffers? NEON can save one cycle per load/store we use
> aligned-specific 
> opcodes. Currently, the code assumes no alignment.
> 
> Comments welcome!
> 
> -- 
> Rémi Denis-Courmont
> http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary
> 
> -----Inline Attachment Follows-----
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer
> Conference in SF, CA
> is the only developer event you need to attend this year.
> Jumpstart your
> developing skills, take BlackBerry mobile applications to
> market and stay 
> ahead of the curve. Join us from November 9-12, 2009.
> Register now!
> http://p.sf.net/sfu/devconf
> -----Inline Attachment Follows-----
> 
> _______________________________________________
> Libmpeg2-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmpeg2-devel
> 


      

Re: [mpeg2-dev] [RFC] [PATCH] ARM Advanced SIMD motion compensation

[Måns R. <ma...@ma...>]

Rémi Denis-Courmont <re...@vi...> writes:

> On Tue, 15 Sep 2009 22:18:22 +0100, Måns Rullgård <ma...@ma...> wrote:
>>> Attached is an intial patch against libmpeg2 trunk to use NEON for
>>> motion compensation. This is preliminary. There are a bunch of known
>>> CPU stalls. Those could probably be fixed using plain assembly and
>>> interleaving subsequent loads. Also, iDCT is not optimized.
>> 
>> Why don't you steal the functions from FFmpeg instead?  They are much
>> better optimised than this patch.
>
> FFmpeg-based MPEG2 decoding was so slow on the target, that I did not even
> consider the possibility that it might have been optimized. For whatever
> reason, it is (eye-)noticeably slower than current libmpeg2 with the
> non-SIMD ARM optimizations. Why is this so? I do not know. There could be

Even if the FFmpeg mpeg2 decoder is slow, the NEON MC and IDCT
functions should be fast.

> something wrong with VLC, but then again the FFmpeg h.264 decoding is
> accelerated fine. Or it could be a build problem, or it could be that I did
> not test properly, or it could be a FFmpeg problem in other part.

Can you reproduce the difference with ffmpeg and mpeg2dec called
directly, not from vlc?  Could you do a quick oprofile run?

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

Re: [mpeg2-dev] [RFC] [PATCH] ARM Advanced SIMD motion compensation

[Rémi Denis-C. <re...@vi...>]

On Tue, 15 Sep 2009 22:18:22 +0100, Måns Rullgård <ma...@ma...> wrote:
>> Attached is an intial patch against libmpeg2 trunk to use NEON for
>> motion compensation. This is preliminary. There are a bunch of known
>> CPU stalls. Those could probably be fixed using plain assembly and
>> interleaving subsequent loads. Also, iDCT is not optimized.
> 
> Why don't you steal the functions from FFmpeg instead?  They are much
> better optimised than this patch.

FFmpeg-based MPEG2 decoding was so slow on the target, that I did not even
consider the possibility that it might have been optimized. For whatever
reason, it is (eye-)noticeably slower than current libmpeg2 with the
non-SIMD ARM optimizations. Why is this so? I do not know. There could be
something wrong with VLC, but then again the FFmpeg h.264 decoding is
accelerated fine. Or it could be a build problem, or it could be that I did
not test properly, or it could be a FFmpeg problem in other part.

-- 
Rémi Denis-Courmont

[mpeg2-dev] [RFC] [PATCH] ARM Advanced SIMD motion compensation

[R. Denis-C. <re...@vi...>]

	Hello all,

ARMv7 includes an optional "Advanced SIMD" instructions set, commercially 
known as NEON. This is included in the recent Cortex line of ARM processors. 
In particular, Cortex-A8 is found on TI-OMAP3xxx boards such as BeagleBoard, 
or the Nokia N900.

Attached is an intial patch against libmpeg2 trunk to use NEON for motion 
compensation. This is preliminary. There are a bunch of known CPU stalls. 
Those could probably be fixed using plain assembly and interleaving subsequent 
loads. Also, iDCT is not optimized. Anyway, here are my results with an 
OMA3430 board:

With C, no acceleration:
7305 frames in 19.87 sec (367.64 fps), 155 last 0.50 sec (310.00 fps)
7308 frames decoded in 19.88 seconds (367.61 fps)                    
7288 frames in 19.88 sec (366.60 fps), 170 last 0.50 sec (340.00 fps)
7308 frames decoded in 19.95 seconds (366.32 fps)                    

With ARM acceleration (current libmpeg2):
7254 frames in 18.88 sec (384.22 fps), 180 last 0.50 sec (360.00 fps)
7308 frames decoded in 19.04 seconds (383.82 fps)
7263 frames in 18.88 sec (384.69 fps), 175 last 0.50 sec (350.00 fps)
7308 frames decoded in 19.02 seconds (384.23 fps)

With NEON acceleration (this patch):
7129 frames in 15.39 sec (463.22 fps), 245 last 0.50 sec (490.00 fps)
7308 frames decoded in 15.85 seconds (461.07 fps)
7127 frames in 15.38 sec (463.39 fps), 245 last 0.50 sec (490.00 fps)
7308 frames decoded in 15.85 seconds (461.07 fps)

So, there is already quite a big improvement!

I wonder if there is any warranty on the memory alignment of some of the 
buffers? NEON can save one cycle per load/store we use aligned-specific 
opcodes. Currently, the code assumes no alignment.

Comments welcome!

-- 
Rémi Denis-Courmont
http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary

Re: [mpeg2-dev] Fwd: segfault on bad pictures / low link power

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

Hello İşbaran,

If you feed libmpeg2 bad data (e.g., if you're dropping packets and not 
replacing them), you will certainly see green blotches -- that's generally 
what you see when there's missing intraframe data.

(There are more sophisticated ways of doing error concealment in the 
presence of unreliable transport, but this is the basic behavior.)

You shouldn't be able to make libmpeg2 segfault, though -- it should 
simply detect the invalid elementary stream. Can you capture the exact 
data you're feeding into it (after the UDP reception) and find a 
replicable segfault? Then we can debug it. Otherwise, no offense, it's 
probably a bug in VLC. :-)

Best,
Keith

On Tue, 8 Sep 2009, İşbaran Akçayır wrote:

> Hello everyone,
>
> i've accidentally sent this message to vlc development list, redirecting 
> here cause i guess its related to libmpeg2
>
> -------- Original Message --------
> Subject: segfault on bad pictures / low link power
> Date: Tue, 08 Sep 2009 15:31:17 +0300
> From: İşbaran Akçayır <is...@gm...>
> To: Mailing list for VLC media player developers <vlc...@vi...>
>
> Hello,
>
> Since i dont know when trac is going online, i'm posting this here with
> all debug i could get.
>
> I'm using vlc in a udp rtsp multicast mpeg2 network, and this is what
> happens if link power is low, after some time (1-3 minutes)
> pictures/video are distorted with green mosaics.
>
> I can reproduce this with previous versions of vlc and current 1.0
> release. Tried on Pardus and Ubuntu Linux so far.
>
> here is gdb out:
>
> http://pastebin.com/f3a8493c
>
> I can produce any other information you need
>
> Best regards,
> işbaran
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Libmpeg2-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmpeg2-devel

[mpeg2-dev] Fwd: segfault on bad pictures / low link power

[İşbaran A. <is...@gm...>]

Hello everyone,

i've accidentally sent this message to vlc development list, redirecting 
here cause i guess its related to libmpeg2

-------- Original Message --------
Subject: segfault on bad pictures / low link power
Date: Tue, 08 Sep 2009 15:31:17 +0300
From: İşbaran Akçayır <is...@gm...>
To: Mailing list for VLC media player developers <vlc...@vi...>

Hello,

Since i dont know when trac is going online, i'm posting this here with
all debug i could get.

I'm using vlc in a udp rtsp multicast mpeg2 network, and this is what
happens if link power is low, after some time (1-3 minutes)
pictures/video are distorted with green mosaics.

I can reproduce this with previous versions of vlc and current 1.0
release. Tried on Pardus and Ubuntu Linux so far.

here is gdb out:

http://pastebin.com/f3a8493c

I can produce any other information you need

Best regards,
işbaran

Re: [mpeg2-dev] MPEG files with audio

[Josh S. <sut...@gm...>]

>
> Date: Wed, 15 Jul 2009 20:33:42 -0400
> From: "Gus Issa" <gu...@gh...>
> Subject: [mpeg2-dev] MPEG files with audio
> To: <lib...@li...>
> Message-ID: <81152BDD268B472E900E6D3DE171CA26@gusbo>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hello,
>
> Does libmpeg2 decode MPEG files with audio in them? I know the library
> itself doesn't decode the audio but is there a way to get the audio data
> from the library since it is already parsing the MPEG file?
>
> Gus
>
> libmpeg2 itself won't extract the audio for you, but you can add it into
something like the demux function in the mpeg2dec example.  In the section
that starts  "switch (header[3]) {"  in mpeg2dec, header[3] will have a
value of not less than 0xe0 and not more than 0xef if it is a video stream.
 MPEG-1 and MPEG-2 audio streams will have a value >= 0xc0 and <= 0xcf.  I'm
pretty sure that everything else in the audio header will look the same as
if it were a video stream, so if you just make a copy of the section in the
demuxer from mpeg2dec and change the value for header[3] (and change where
you send the audio data as well), you should have a working demultiplexer
that will handle audio as well.
I hope that is helpful.

Josh

Re: [mpeg2-dev] Commercial license or LGPL

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

Hi Gus,

FFmpeg's libavcodec can also decode MPEG-2 video and is licensed under the 
LGPL.

Best,
Keith

On Thu, 16 Jul 2009, Gus Issa wrote:

> Hello,
>  
> Is there a library out there that is similar to libmpeg2 but available
> for commercial licensing (not GPL)? Or can libmpeg2 be licensed non-GPL?
> or even LGPL?
>  
> Thanks
>  
> Gus
>  
> 
>

[mpeg2-dev] Commercial license or LGPL

[Gus I. <gu...@gh...>]

Hello,

Is there a library out there that is similar to libmpeg2 but available for commercial licensing (not GPL)? Or can libmpeg2 be licensed non-GPL? or even LGPL?

Thanks

Gus

Re: [mpeg2-dev] unable to decode properly

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

Hi Gus,

If I had to make a wild guess, you're trying to play an MPEG-2 system 
stream (a transport stream or program stream).

sample2.c only works on an MPEG-2 video elementary stream -- the raw video 
that is multiplexed into the system stream.

Does the file play back properly with mplayer on a normal Linux x86 
machine? You might try playing with mpeg2dec and the "-s0" option to see 
if it's a program stream that you need to extract the video from.

Or can you post one of these files to the Web? We can take a look and tell 
you what's going on if you do that.

Best,
Keith

On Wed, 15 Jul 2009, Gus Issa wrote:

> Hello,
>  
> I have ported libmpeg2 to a small project running on 200Mhz ARM9. I must
> say it runs really fast, about 100 frames/sec for 320x240!
> The only problem I am having is errors in the generated frames. The
> pictures has too many little squares in it. They are randomly placed and
> of different sizes. It looks like just if I was receiving a bad MPEG file
> but I know my file is fine because I tried many files of different
> settings and I always get same thing (MPEG1 and MPEG2)
>  
> I am outputting a 16bit RGB to my display and using sample2.c file.
>  
> Any hints on what am I doing wrong or what file is responsible for this
> error would really help me. I tried standard and ARM motion_comp files
> and standard and ARM idct files but I always get the same results so I am
> assuming the error is not in motion or in idct?! I do not know anything
> about video compression.
>  
> Gus
> 
>

Re: [mpeg2-dev] MPEG files with audio

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

Hi Gus,

libmpeg2 itself can only parse an MPEG video elementary stream -- video 
only.

Within the MPEG-2 world, a stream that combines video and audio is an 
MPEG-2 systems stream -- either a transport stream or a program stream. 
You can demultiplex these with the mpeg2dec and extract_mpeg2 example 
programs that ship with libmpeg2.

They only pull out the video, but you can tweak them to do audio or a 
different stream. liba52 ships with extract_a52, which can pull out AC-3 
audio from an MPEG system stream like like extract_mpeg2 does for video.

Best,
Keith

On Wed, 15 Jul 2009, Gus Issa wrote:

> Hello,
>  
> Does libmpeg2 decode MPEG files with audio in them? I know the library
> itself doesn't decode the audio but is there a way to get the audio data
> from the library since it is already parsing the MPEG file?
>  
> Gus
> 
>

[mpeg2-dev] unable to decode properly

[Gus I. <gu...@gh...>]

Hello,

I have ported libmpeg2 to a small project running on 200Mhz ARM9. I must say it runs really fast, about 100 frames/sec for 320x240!
The only problem I am having is errors in the generated frames. The pictures has too many little squares in it. They are randomly placed and of different sizes. It looks like just if I was receiving a bad MPEG file but I know my file is fine because I tried many files of different settings and I always get same thing (MPEG1 and MPEG2)

I am outputting a 16bit RGB to my display and using sample2.c file.

Any hints on what am I doing wrong or what file is responsible for this error would really help me. I tried standard and ARM motion_comp files and standard and ARM idct files but I always get the same results so I am assuming the error is not in motion or in idct?! I do not know anything about video compression.

Gus

[mpeg2-dev] MPEG files with audio

[Gus I. <gu...@gh...>]

Hello,

Does libmpeg2 decode MPEG files with audio in them? I know the library itself doesn't decode the audio but is there a way to get the audio data from the library since it is already parsing the MPEG file?

Gus

[mpeg2-dev] [trunk/libvo/video_out_sdl.c] Patch: Include SDL.h

[Giovanni F. <gaf...@gm...>]

The include SDL.h is wrong, see:
http://www.libsdl.org/faq.php?action=listentries&category=2#19

Patch follows.

Best regards,
-- Giovanni Funchal

--- trunk/libvo/video_out_sdl.c.old
+++ trunk/libvo/video_out_sdl.c.new
@@ -31,7 +31,7 @@
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
-#include <SDL/SDL.h>
+#include "SDL.h"
 #include <inttypes.h>

 #include "video_out.h"

[mpeg2-dev] [unconfirmed] bug report: can you please check this bitstream?

[Giovanni F. <gaf...@gm...>]

Hi all,

The following MPEG2 bitstream contains alternating color bars/black.

http://www.w6rz.net/avsync.zip

There seems to be a problem with the decoding using libmpeg2, can
someone confirm the problem? Does anyone know why video is scrambled
(alignment problem?)

Thanks and best regards,
-- Giovanni Funchal

[mpeg2-dev] tests

[jim j. <tmp...@gm...>]

as title

[mpeg2-dev] how to extract the first I-frame

[jim j. <tmp...@gm...>]

Hi guys.
  I am new to the libmpeg2,(0.51).

  I follow the sample2.c try to extract the first I-frame
 But I found the problem

when looping mpeg2_parse (decoder)
1.
  STATE_PICTURE   found
  I check the flag to see if it is an I frame
  pic_coding_type = info->current_picture->flags & PIC_MASK_CODING_TYPE;

2. STATE_SLICE  found
   then i try to extract the data ,but  info->display_fbuf is NULL,so I can
get nothing.

How can I extract the first I-frame to ppm data?

source

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);
        break;
    case STATE_PICTURE:
      pic_coding_type = info->current_picture->flags & PIC_MASK_CODING_TYPE;
      break;
    case STATE_SLICE:
    case STATE_END:
    case STATE_INVALID_END:
        if (info->display_fbuf  && pic_coding_type == PIC_FLAG_CODING_TYPE_I
)
        save_ppm (info->sequence->width, info->sequence->height,
              info->display_fbuf->buf[0], framenum++);
        break;
    default:
        break;
    }

thanks in advance

[mpeg2-dev] mpeg2dec-streams tarball missing

[McLemon, S. <Sea...@an...>]

The tarball cited in the tests/README file doesn't seem to exist:

  * get the official suite of mpeg2 torture tests at
  http://libmpeg2.sourceforge.net/files/mpeg2dec-streams.tar.gz

Apologies if this is not the expected manner that bugs\problems should
be reported, or if this has previously been reported. I had a quick scan
around and this seemed the most appropriate channel.

- Sean

[mpeg2-dev] Query in MPEG-2 decoder

[Deepak G. <gde...@gm...>]

Hi,

I have a problem to be solved using MPEG-2 decoder. I would like
to extract the positions of the non-zero DCT coefficients in a macroblock.
Can anybody help me out in this or suggest how or where in libmpeg2
should i be extracting the DCT coefficient values.

Thanks and Regards
Deepak Gangadharan

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

[Michael N. <mic...@gm...>]

On Thu, Mar 19, 2009 at 07:35:49PM -0600, Bob Ingraham wrote:
> Good news!
> 
> Shortly after I wrote that last email I found that the cause of many (but not all,) of my major artifacts was my coding error in decoding the adaptation field length.
> 
> After re-reading the MPEG2 spec, I realized that I was one byte too short in calculating the byte offset of the payload when a adapation field was present in the TS packet. Hence, the frequent major artifacts were a result of one extra byte of data before the actual mpeg2 frame.
> 
> So, I am an idiot! How exciting is that? :-)
> 
> Anyway, the image is much more stable. However I still get a *lot* of artifacts when displaying a live shot of the ocean waves crashing onto a beach in California. (I work for a satellite company and we have some hi-def, fixed cameras at this particular beach...)
> 
> The edges of the waves, along with white caps on the waves definitely cause grief, but the biggest problem is the OSD of the clock-time superimposed on the frames (it changes every second,) - it looks like the time gets washed torwards the shore every time a wave passes through it. Also, the digits of the numbers are supposed to be white and they keep turning rainbow colors...
> 
> But, as sanity check, I a comparing the same satellite feed coming through libavcodec versus a commercial mpeg2 receiver, and the mpeg2 receiver has zero-problems with the OSD clock overlay. The time-digits are steady and white and the blockiness of the waves is finer grained.
> 
> Michael, I respect your work, knowledge and contributions to ffmpeg and would happy to post a stream capture of the live beach video tomorrow for folks to test with.
> 
> Based on the above descripton, do you have any recommendations for tweaking the CodecContext (or applying a post-processing filter to smooth-out the wave edges?)

You shouldnt draw into the internal buffers of libavcodec, it uses them for
predicting future frames. Also you likely want to read the docs about 
get/relealse_buffer()

about postprocessing, theres libpostproc and some filters in mplayers
libmpcodecs like vf_spp, later is significantly slower but higher quality


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct awnser.

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

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

Good news!

Shortly after I wrote that last email I found that the cause of many (but not all,) of my major artifacts was my coding error in decoding the adaptation field length.

After re-reading the MPEG2 spec, I realized that I was one byte too short in calculating the byte offset of the payload when a adapation field was present in the TS packet. Hence, the frequent major artifacts were a result of one extra byte of data before the actual mpeg2 frame.

So, I am an idiot! How exciting is that? :-)

Anyway, the image is much more stable. However I still get a *lot* of artifacts when displaying a live shot of the ocean waves crashing onto a beach in California. (I work for a satellite company and we have some hi-def, fixed cameras at this particular beach...)

The edges of the waves, along with white caps on the waves definitely cause grief, but the biggest problem is the OSD of the clock-time superimposed on the frames (it changes every second,) - it looks like the time gets washed torwards the shore every time a wave passes through it. Also, the digits of the numbers are supposed to be white and they keep turning rainbow colors...

But, as sanity check, I a comparing the same satellite feed coming through libavcodec versus a commercial mpeg2 receiver, and the mpeg2 receiver has zero-problems with the OSD clock overlay. The time-digits are steady and white and the blockiness of the waves is finer grained.

Michael, I respect your work, knowledge and contributions to ffmpeg and would happy to post a stream capture of the live beach video tomorrow for folks to test with.

Based on the above descripton, do you have any recommendations for tweaking the CodecContext (or applying a post-processing filter to smooth-out the wave edges?)

Best Regards,
Bob Ingraham


----- Original Message -----
From: "Michael Niedermayer" <mic...@gm...>
To: "Bob Ingraham" <bo...@br...>
Cc: lib...@li...
Sent: Thursday, March 19, 2009 6:39:05 PM GMT -07:00 US/Canada Mountain
Subject: Re: [mpeg2-dev] Decoding MPEG-TS stream

On Thu, Mar 19, 2009 at 05:55:09PM -0600, Bob Ingraham wrote:
> Thanks Måns.
> 
> The better result that I am seeking from libmpeg2 is better error detection and concealment.

I belive libmpeg2 does no error concealment


> 
> I don't know if it is better in this way or not, but I have tweaked various CodecContext variables in libavcodec and I am still getting too many artifacts.

This is strange, could you make a short piece of the stream available
for other to check (that is a part which shows too many artifacts)

also you should be able to test the stream with mplayer, mplayer supports
both libmpeg2 and libavcodec

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator

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

[Michael N. <mic...@gm...>]

On Thu, Mar 19, 2009 at 05:55:09PM -0600, Bob Ingraham wrote:
> Thanks Måns.
> 
> The better result that I am seeking from libmpeg2 is better error detection and concealment.

I belive libmpeg2 does no error concealment


> 
> I don't know if it is better in this way or not, but I have tweaked various CodecContext variables in libavcodec and I am still getting too many artifacts.

This is strange, could you make a short piece of the stream available
for other to check (that is a part which shows too many artifacts)

also you should be able to test the stream with mplayer, mplayer supports
both libmpeg2 and libavcodec

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator

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

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

Thanks Måns.

The better result that I am seeking from libmpeg2 is better error detection and concealment.

I don't know if it is better in this way or not, but I have tweaked various CodecContext variables in libavcodec and I am still getting too many artifacts.

Regarding non-compliant TS streams from LinuxDVB:

I am currently using a DMX_SET_PES_FILTER with its pes_type member set to DMX_PES_OTHER.

Since I a wanting video, perhaps I should change this to DMX_PES_VIDEO and perhaps I will get a standard TS/PES stream.

Or maybe that's how DMX_SET_PES_FILTER works.

All I know is that, after stripping-off the 4-byte TS header (and any adaption-field header, if present,) the remaining bytes are the raw compressed MPEG2 frames bytes.

When I get a complete frame and decode/render it, I see the picture I expect.

The libavcodec MPEG2 decoder is reporting normal sequences of I/P/B frames all along the way.

Strange...

Thanks for your insights.

Bob


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...