MEncoder Issues (Updated 20 Apr 2011)

[SubJunk]

"Update for libass" was fixed in r34383

[happy.neko]

Two small questions for SubJunk:

1. About mplayer-r34332-SB17.patch. What is it used for and is it needed for linux mplayer/mencoder build?

2. fixpts filter is now in the mplayer trunk. In MEncoderVideo.java it is limited for mpegts, wmv and Windows arch. Same question, is it useful for linux buidls?

Thanks.

[SubJunk]

1. About mplayer-r34332-SB17.patch. What is it used for and is it needed for linux mplayer/mencoder build?

It's mostly used to get good DVD ISO playback and I recommend it for all operating systems.

2. fixpts filter is now in the mplayer trunk. In MEncoderVideo.java it is limited for mpegts, wmv and Windows arch. Same question, is it useful for linux buidls?

It was mostly useful for ASS/SSA subtitle support back when that was broken, but now it's fixed so no, there's no need for fixpts with PS3MS

[ExSport]

• Audio delay setting ignored in MEncoder unless -ss has a value

With SB19 it still affects tsMuxeR engine but not MEncoder engine
Here is easy and tested patch how to fix it.
For now when tsMuxeR engine is used and video is started from beginning, -ss parameter is set to 0.
PMS creates temporary .meta file for own purpose and set timeshift(audio delay) there.
If audio is extracted with MEncoder(always) from beginning(-ss 0), delay is not automatically fixed.
Audio on renderer is OK because .meta file has info about detected delay so no problem here.
Unfortunatelly when -ss is not zero, MEncoder detects delay and fixes it so when rewinding or using chapters(starting point is not zero) audio gets out of sync.
It is because .meta file still defines delay which is already removed
Fix is by applying "timeshift=" parameter only when -ss is zero but not in any other cases.
I tried to fight with -edl and -hr-edl-seek parameters but it not stable for this purpose(very variable results)
So now the patch. Should work also for official build but patch crated for latest SubJunk build:

Code: Select all

Index: net/pms/encoders/TSMuxerVideo.java
===================================================================
--- net/pms/encoders/TSMuxerVideo.java   (revision 50)
+++ net/pms/encoders/TSMuxerVideo.java   (working copy)
@@ -429,7 +429,7 @@
                type = "A_DTS";
             }
          }
-         if (params.aid != null && params.aid.getDelay() != 0) {
+         if (params.aid != null && params.aid.getDelay() != 0 && params.timeseek == 0) {
             timeshift = "timeshift=" + params.aid.getDelay() + "ms, ";
          }
          pw.println(type + ", \"" + ffAudioPipe[0].getOutputPipe() + "\", " + timeshift + "track=2");
@@ -448,7 +448,7 @@
                   type = "A_DTS";
                }
             }
-            if (lang.getDelay() != 0) {
+            if (lang.getDelay() != 0 && params.timeseek == 0) {
                timeshift = "timeshift=" + lang.getDelay() + "ms, ";
             }
             pw.println(type + ", \"" + ffAudioPipe[i].getOutputPipe() + "\", " + timeshift + "track=" + (2 + i));

Works flawlessly(A/V alternate sync have to be disabled!) for all combinations of replay(MKV tested).
Little bit off topic but when I tested this behavior I spotted other PMS bugs(already I mentioned them somewhere in past):

• When chapters used, goto or rewind will start video again from beginning
  It is because PMS ignores chapter time offset and didn't count with it so when we will start movie from 30min mark(-ss 1800) and FF/RW or PS3 goto is used, PMS will jump to e.g. 10min(-ss 600) which is replaced with chapter offset so it starts again from -ss 1800. If I used goto to 40min, -ss was 2400 so it started from there but it should start from 1800+2400

• -endpos parameter is added when MEncoder engine is used
  Maybe because of that sometimes some files are not complete because endpos value is not real "end time" of transcoded file. What about to remove it? Why is it used?

• vrc_buf_size=1835:vrc_minrate=15000:vrc_maxrate=15000:vbitrate=15000
  These parameters are used when ByteToTimeSeek conversion is used(for CBR stream so FF/RW can work on renderers which doesn't support TimeSeek[like PanTV])
  vrc_maxrate is also used when "Bandwidth limit" is not set to zero to limit final bandwidth what is very CPU aggresive.
  I spotted that in both cases vrc_buf_size=1835 is used which has big influence on transcoding speed.
  Test for 120s HD clip on dual core:
  - 107s without bandwidth limit
  - 221s with limit to 40-80Mbps(don't remember right now) and "vrc_buf_size=5000" used
  - 280s with limit to 40-80Mbps(don't remember right now) and "vrc_buf_size=1835" used
  Higher bufsize also lowers buffer underflows but I found that for some higher "vrc_maxrate" values, sometimes vrc_buf_size set to 10000 created jerky output(some slowness spotted), for other bitrates 7000 was ok, for others not but 5000 was OK for all my tests.
  Have to be tested by more people but I suppose it is worth of testing because it really makes faster transcoding so my CPU was OK for realtime transcoding where default value was unusable
  At home I have 4-core but also 3 renderers(two are using bandwidth limiting and/or Byte2TimeSeek FW/RW) so sometimes it starts to skip but with higher buffer(25% faster transcoding) it was OK

Ughhh so long post...
Waiting for feedback

[SubJunk]

Interesting, I'll test it. Thanks!

[Raptor399]

Nice work investigating there, ExSport!

[chocolateboy]

The latest MEncoder is choking on the two builtin WEB.conf videostreams:

viewtopic.php?f=6&p=66987#p66987

Code: Select all

+ /usr/lib/ps3mediaserver/linux/mencoder -msglevel all=2 -prefer-ipv4 -oac lavc -of lavf -lavfopts format=dvd -ovc lavc -lavcopts vcodec=mpeg2video:vbitrate=4096:threads=3:acodec=ac3:abitrate=128 -ofps 25 -cache 16384 -vf harddup -o deleteme.mencoder mms://stream1.france24.yacast.net/f24_liveen
MEncoder SB28 (C) 2000-2012 MPlayer Team
Custom build by SubJunk, http://www.spirton.com

connect error: Connection refused
** MUXER_LAVF *****************************************************************
REMEMBER: MEncoder's libavformat muxing is presently broken and can generate
INCORRECT files in the presence of B-frames. Moreover, due to bugs MPlayer
will play these INCORRECT files as if nothing were wrong!
*******************************************************************************
Requested video codec family [wmvvc1dmo] (vfm=dmo) not available.
Enable it at compilation.
Unsupported PixelFormat 61
Unsupported PixelFormat 53
Unsupported PixelFormat 81
[ac3 @ 0x8f6a8c0]channel_layout not specified
[ac3 @ 0x8f6a8c0]No channel layout specified. The encoder will guess the layout, but it might be incorrect.
Cache empty, consider increasing -cache and/or -cache-min. [performance issue]
Unsupported PixelFormat 61
Unsupported PixelFormat 53
Unsupported PixelFormat 81
[dvd @ 0x8ef6400]VBV buffer size not set, muxing may fail
Cache empty, consider increasing -cache and/or -cache-min. [performance issue]
Cache empty, consider increasing -cache and/or -cache-min. [performance issue]

1 duplicate frame(s)!
[mpeg2video @ 0x8f6a8c0]Error, Invalid timestamp=22, last=24532102
[dvd @ 0x8ef6400]Application provided invalid, non monotonically increasing dts to muxer in stream 0: 88315562250 >= 75600
Error while writing frame.
Cache empty, consider increasing -cache and/or -cache-min. [performance issue]

[...]

1 duplicate frame(s)!
[mpeg2video @ 0x8f6a8c0]Error, Invalid timestamp=72, last=24532162
[dvd @ 0x8ef6400]Application provided invalid, non monotonically increasing dts to muxer in stream 0: 88315778250 >= 255600
Error while writing frame.
[dvd @ 0x8ef6400]buffer underflow i=0 bufi=0 size=16012
[dvd @ 0x8ef6400]buffer underflow i=0 bufi=2011 size=16012


Both work fine with the stock Ubuntu 10.10 MEncoder:

Code: Select all

MEncoder 1.0rc4-4.4.5 (C) 2000-2010 MPlayer Team

[Raptor399]

I can't get the MPlayer source for SB31 to compile on OSX (based on revision d16c839c).

Code: Select all

Undefined symbols for architecture i386:
  "_MM_FIX_0_707106781", referenced from:
      _filter in vf_fspp.o
  "_MM_FIX_0_541196100", referenced from:
      _filter in vf_fspp.o
  "_GetFullPathNameA", referenced from:
      _init in vd_dsnative.o
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
make: *** [mencoder] Error 1
make: *** Waiting for unfinished jobs....
Undefined symbols for architecture i386:
  "_MM_FIX_0_707106781", referenced from:
      _filter in vf_fspp.o
  "_MM_FIX_0_541196100", referenced from:
      _filter in vf_fspp.o
  "_GetFullPathNameA", referenced from:
      _init in vd_dsnative.o
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
make: *** [mplayer] Error 1
Fatal error occurred, aborting build.

The MM_FIX symbols appear to come from FFmpeg, which compiles fine itself.
Not sure where "GetFullPathNameA" should come from.

[SubJunk]

I had problems with newer FFmpeg too, which is why I compiled with the same FFmpeg version I used with SB30, are you using the same one too?

[Raptor399]

I had problems with newer FFmpeg too, which is why I compiled with the same FFmpeg version I used with SB30, are you using the same one too?

Yep, I use the FFmpeg version mentioned in binaries-deps-versions:

Code: Select all

VERSION_FFMPEG=58c25724b7f921fdf3657fcb011b3bb3b7b353d4

This is the same version as used for SB30 and it compiles fine.