ffmux_mpeg output has severe syntax errors

[Bob Forsman]

  Should I be at all surprised that the ffmux_mpeg generates what seems to be garbage?

gst-launch-0.10 -v filesrc location=/home/dvds/thoth/myth-mirror/The\ Drinky\ Crow\ Show\ -\ Tunnel\ Girls.mpeg ! decodebin name=db ! videoscale ! "video/x-raw-yuv, width=352, height=480, pixel-aspect-ratio=1920/1056" ! ffenc_mpeg2video ! ffmux_mpeg ! filesink location=/tmp/x  db.! fakesink

  I'm trying to put some reencoded video into a program stream to
preserve the PTSs.  It's not working so well.

  The program stream pack header seems to be short and contains
nonsensical values.  ISO 13818-1 table 2-33 leads me to believe that the
smallest PS pack header is (including start code) 112 bits, but based on
the stream, I think it's 2 bytes too short.  

The mux rate on the packets appears to be uniformly 336870400bps.

All but one of the marker bits are wrong.

The time code appears to be monotonically increasing, but bears no
relation to the SCRs or PTSs in the source stream.



The PES headers also appear to be flawed.

I found a couple of instances where the PTS_DTS_flag was 01, which isn't
even permitted by the syntax of table 2-17.  The PTS values themselves
were quite random.

  The stream DOES play in mplayer, but this is probably more a function
of mplayer not caring about clocks or bit rates that are mostly of
interest to multiplexers.



  Is there someone I can work with to help improve the quality of the
packets?

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[michael smith-6-3]

On Mon, Feb 9, 2009 at 9:05 AM, Bob Forsman <[hidden email]> wrote:
>  Should I be at all surprised that the ffmux_mpeg generates what seems to be garbage?

Probably not. The ffmpeg muxers are generally of low quality to begin
with. The gst-ffmpeg wrapper may also have problems that make it even
worse.

The recommended approach is to use a 'native' gstreamer muxer. I'm not
sure if there is one publically available; you might need to write
one.

Mike

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Edward Hervey]

On Mon, 2009-02-09 at 10:34 -0800, Michael Smith wrote:
> On Mon, Feb 9, 2009 at 9:05 AM, Bob Forsman <[hidden email]> wrote:
> >  Should I be at all surprised that the ffmux_mpeg generates what seems to be garbage?
>
> Probably not. The ffmpeg muxers are generally of low quality to begin
> with. The gst-ffmpeg wrapper may also have problems that make it even
> worse.

  As a side note, I am (and will be) spending some time making sure the
gst-ffmpeg wrapper code for (de)muxers improves. The ffmpeg team have
actually put in a lot of effort over the past 6-12 months to make
libavformat friendler to use and we can already see the benefits (like
push-based support for demuxers working properly).

  That does not go against the recommendation below to use 'native'
gstreamer (de)muxers whenever available, but improving the current
gst-ffmpeg situation will be mutually beneficial to both GStreamer and
FFmpeg.

   Edward
 
P.S. Oh, did you know FFmpeg are going to do a release (scheduled for
around the 21st of Feb) ? I kid you not !

>
> The recommended approach is to use a 'native' gstreamer muxer. I'm not
> sure if there is one publically available; you might need to write
> one.
>
> Mike
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel