[theora] video quality problem,
encodeing with ffmpeg2theora -p pro
Peter Colton
theora at bissybox.com
Fri May 25 15:32:41 PDT 2007
Hello Conrad
Here some info about the menory useage of ffmpeg2theora -p pro
The tool I have used to get the menory useage is pmap
By the look of things there about 31 meg being used :
total 31936K
From top the cpu usage is about 90%
-------------------------------------------------------------------------------------
admin at apt-get:/mnt/data$ ffmpeg2theora -p pro vob-file.vob
Input #0, mpeg, from 'vob-file.vob':
Duration: 00:52:51.6, start: 0.078678, bitrate: 9328 kb/s
Stream #0.0[0x1e0]: Video: mpeg2video, yuv420p, 720x480, 9000 kb/s, 29.97
fps(r)
Stream #0.1[0x80]: Audio: ac3, 48000 Hz, stereo, 192 kb/s
Pixel Aspect Ratio: 0.89/1 Frame Aspect Ratio: 1.33/1
Resize: 720x480
-----------------------------------------------------------------------------------
admin at apt-get:~$ pmap 1051
1051: ffmpeg2theora -p pro vob-file.vob
08048000 28K r-x-- /usr/bin/ffmpeg2theora
0804f000 4K rw--- /usr/bin/ffmpeg2theora
08050000 6532K rw--- [ anon ]
b6667000 16908K rw--- [ anon ]
b76ea000 56K r-x-- /lib/tls/i686/cmov/libpthread-2.3.6.so
b76f8000 8K rw--- /lib/tls/i686/cmov/libpthread-2.3.6.so
b76fa000 8K rw--- [ anon ]
b76fc000 1180K r-x-- /lib/tls/i686/cmov/libc-2.3.6.so
b7823000 20K r---- /lib/tls/i686/cmov/libc-2.3.6.so
b7828000 8K rw--- /lib/tls/i686/cmov/libc-2.3.6.so
b782a000 12K rw--- [ anon ]
b782d000 16K r-x-- /usr/lib/libogg.so.0.5.3
b7831000 4K rw--- /usr/lib/libogg.so.0.5.3
b7832000 140K r-x-- /lib/tls/i686/cmov/libm-2.3.6.so
b7855000 8K rw--- /lib/tls/i686/cmov/libm-2.3.6.so
b7857000 104K r-x-- /usr/lib/libvorbis.so.0.3.1
b7871000 56K rw--- /usr/lib/libvorbis.so.0.3.1
b787f000 4K rw--- [ anon ]
b7880000 20K r-x-- /usr/lib/libavutil.so.0d.49.0.0
b7885000 4K rw--- /usr/lib/libavutil.so.0d.49.0.0
b7886000 20K r-x-- /usr/lib/libraw1394.so.8.1.1
b788b000 4K rw--- /usr/lib/libraw1394.so.8.1.1
b788c000 44K r-x-- /usr/lib/libvorbisenc.so.2.0.2
b7897000 956K rw--- /usr/lib/libvorbisenc.so.2.0.2
b7986000 8K rw--- [ anon ]
b7988000 8K r-x-- /lib/tls/i686/cmov/libdl-2.3.6.so
b798a000 8K rw--- /lib/tls/i686/cmov/libdl-2.3.6.so
b798c000 52K r-x-- /usr/lib/libdc1394_control.so.13.0.0
b7999000 4K rw--- /usr/lib/libdc1394_control.so.13.0.0
b799a000 60K r-x-- /usr/lib/libgsm.so.1.0.10
b79a9000 4K rw--- /usr/lib/libgsm.so.1.0.10
b79aa000 4K rw--- [ anon ]
b79ab000 36K r-x-- /usr/lib/liba52-0.7.4.so
b79b4000 4K rw--- /usr/lib/liba52-0.7.4.so
b79b5000 4K rw--- [ anon ]
b79b6000 76K r-x-- /usr/lib/libz.so.1.2.3
b79c9000 4K rw--- /usr/lib/libz.so.1.2.3
b79ca000 4028K r-x-- /usr/lib/libavcodec.so.0d.51.11.0
b7db9000 160K rw--- /usr/lib/libavcodec.so.0d.51.11.0
b7de1000 392K rw--- [ anon ]
b7e43000 496K r-x-- /usr/lib/libavformat.so.0d.50.5.0
b7ebf000 28K rw--- /usr/lib/libavformat.so.0d.50.5.0
b7ec6000 224K r-x-- /usr/lib/libtheora.so.0.2.0
b7efe000 4K rw--- /usr/lib/libtheora.so.0.2.0
b7f0e000 8K rw--- [ anon ]
b7f10000 4K r-x-- [ anon ]
b7f11000 84K r-x-- /lib/ld-2.3.6.so
b7f26000 8K rw--- /lib/ld-2.3.6.so
bfef8000 84K rw--- [ stack ]
total 31936K
Regards
Peter Colton
On Friday 25 May 2007 11:02, Conrad Parker wrote:
> Hi Peter,
>
> I think that the problems you're seeing are due to buffering
> requirements imposed by the stream. The file is legal Ogg (at least,
> it passes oggz-validate) but if the Ogg pages had been constructed
> differently then the buffering requirements would be smaller. This is
> something we should look at fixing in ffmpeg2theora and/or libogg.
>
> On a faster machine with 2GB RAM, the p_pro.ogg file plays ok (in vlc,
> xine and mplayer) -- which isn't to say you should get a beefier
> machine, just saying that the file is not corrupt or invalid.
>
> The following is an analysis of that stream to help us improve pagination:
>
> 1. Here's a 'hogg pagedump' of the file:
> http://snapper.kfish.org/~conrad/tmp/p_pro_dump.txt
>
> A couple of things are noticeable in that: firstly there are long
> stretches of only Theora pages (up to 20 or so in a row in some parts)
> in between Vorbis data. If instead, Vorbis pages were flushed more
> often, then the buffering requirements would be smaller.
>
> Secondly, almost every page ends with an incomplete packet, which
> means that the timestamping is often deferred. This may make correct
> audio/video sync harder than necessary for players. If instead Theora
> pages were flushed at the end of each packet, then the file would
> contain more timestamps (and fewer packets would be unnecessarily
> split across page boundaries).
>
> 2. This is the output of dump-stream-sync-info (a debug tool from
> liboggplay):
>
> ========================================
> Reading 2 tracks ...
> Theora: Track 0 ... ok ...
> Vorbis: Track 1 ... ok ...
> Total 3594 frames.
>
> Theora: Track 0
> Worst overrun: 32
> Average overrun: 6.105
> Histogram bucket size: 1.600
> Histogram: 259 724 356 703 345 642 397 58 40 11 14 12 6 12 7 1 2 1
> 2 2 SD of overrun: 3.605551
>
> Vorbis: Track 1
> Worst overrun: 47808
> Average overrun: 9224.708
> Histogram bucket size: 2390.400
> Histogram: 449 485 624 450 474 569 319 106 21 12 12 16 7 9 12 8 5 7
> 4 5 SD of overrun: 6248.535828
> ========================================
>
> The worst overruns are in the order of a second. If the players in
> question decode frames immediately on demux (and hence queue decoded
> frames) then we are looking at a potential queue of many MB of image
> data, which could explain the observed sync issues.
>
> Thanks for the file!
>
> cheers,
>
> Conrad.
>
> On 25/05/07, Peter Colton <theora at bissybox.com> wrote:
> > Hello Conrad and thanks,
> >
> > wget www.bissybox.com/p_preveiw.ogg
> >
> > wget www.bissybox.com/p_pro.ogg
> >
> > The p_pro.ogg file play a little better with kaffeine than vlc.
> >
> > I have used ffmpeg2theora-0.18.linux.bin.bz2 and had the same problem
> >
> > Regards
> >
> > Peter Colton
> >
> > admin at apt-get:/mnt/data$ ffmpeg2theora -p preview
> > vob-file.vob -o -p_preveiw.ogg
> > Input #0, mpeg, from 'CHAVEZ1-1.vob':
> > Duration: 00:52:51.6, start: 0.078678, bitrate: 9328 kb/s
> > Stream #0.0[0x1e0]: Video: mpeg2video, yuv420p, 720x480, 9000 kb/s,
> > 29.97 fps(r)
> > Stream #0.1[0x80]: Audio: ac3, 48000 Hz, stereo, 192 kb/s
> > Pixel Aspect Ratio: 1.00/1 Frame Aspect Ratio: 1.33/1
> > Resize: 720x480 => 320x240
> > No accelerated IMDCT transform found
> > 0:02:00.58 audio: 75kbps video: 167kbps
> >
> > admin at apt-get:/mnt/data$ ffmpeg2theora -p pro vob-file.vob -o -p_pro.ogg
> > Input #0, mpeg, from 'CHAVEZ1-1.vob':
> > Duration: 00:52:51.6, start: 0.078678, bitrate: 9328 kb/s
> > Stream #0.0[0x1e0]: Video: mpeg2video, yuv420p, 720x480, 9000 kb/s,
> > 29.97 fps(r)
> > Stream #0.1[0x80]: Audio: ac3, 48000 Hz, stereo, 192 kb/s
> > Pixel Aspect Ratio: 0.89/1 Frame Aspect Ratio: 1.33/1
> > Resize: 720x480
> > No accelerated IMDCT transform found
> > 0:02:00.20 audio: 101kbps video: 1869kbps
> >
> > On Friday 25 May 2007 04:28, you wrote:
> > > On 25/05/07, Peter Colton <theora at bissybox.com> wrote:
> > > > The problem I am having is when I encode a .vob with " ffmpeg2theora
> > > > -p pro ". The resulting .ogg will not play correctly with vlc or
> > > > kaffeine. The vedio is jerky and the sound go out of sycro just after
> > > > the start of the video. The video veiwer takes up all the cpu
> > > > resourses for the .ogg when encoded with " ffmpeg2theora -p pro ".
> > >
> > > Hi,
> > >
> > > any chance you could post say the first few MB of such a file
> > > somewhere? I've got a hunch it has something to do with the way the
> > > audio and video tracks are interleaved and timestamped (forcing the
> > > players to buffer much more than necessary), but I'm not sure ...
> > >
> > > cheers,
> > >
> > > Conrad.
More information about the theora
mailing list