problems with MKV file

Hello:
I’ve installed mplayer (codecs installed in both /usr/lib/win32 and /usr/lib64/win32)and VLC in my 11.3 X64 OS, and it can play most of the media files. However, there is some problem with .mkv file:

the picture from mplayer lag behind the sound a lot; while there is no sound in VLC. When I play .mkv in VLC, it said:

 No suitable decoder module:
VLC does not support the audio or video format "cook". Unfortunately there is no way for you to fix this.

while mplayer claims:

Debug: BaseGui::updateWidgets
Debug: MplayerProcess::parseLine: '[ass] PlayResX undefined, setting to 384'
Debug: MplayerProcess::parseLine: 'Too many buffered pts'
Debug: MplayerProcess::parseLine: 'Too many buffered pts'
Debug: MplayerProcess::parseLine: 'Too many buffered pts'
Debug: MplayerProcess::parseLine: 'Too many buffered pts'
Debug: MplayerProcess::parseLine: 'Too many buffered pts'
Debug: MplayerProcess::parseLine: 'Too many buffered pts'
Debug: MplayerProcess::parseLine: 'Too many buffered pts'
Debug: MplayerProcess::parseLine: 'Too many buffered pts'
Debug: MplayerProcess::parseLine: 'Too many buffered pts'
Debug: MplayerProcess::parseLine: 'Too many buffered pts'
Debug: MplayerProcess::parseLine: 'Too many buffered pts'

THX

You should look at this
MMCHECK - Version 2.35 - Check Your Multimedia in 16 Steps - Bash Script File - Blogs - openSUSE Forums

IINM cook is an audio codec used in realmedia videos, either rm or rmvb (variable bitrate).

Note that mkv is just a (very good) wrapper, it encapsulates and interleave video, audio and text streams, and each one of these is encoded in it’s own specific format, like mp4, aac and utf-8.

Most mkv you see around are encoded in x264 (HD) and mp4 ASP (created by XviD/DivX encoders). Eventually you’ll cross paths with lesser common encodings, like you did now.

Lat time I wanted to play something with cook audio I had to download a codec package from the mplayer site and extract cook.so from the essential-amd64-20071007 package I got there. Note the architecture you use (in my case AMD64).

what are you saying brunomcl ? that suse12.1 didn’t bother to get a current and up-to date ffmpeg/avconv, x264 and related dependences for inclusion in the standard DVD etc ?

that really blows as everyone knows that ffmpeg/avconv code with their (sometimes nightly) AVX/SSE code is used by virtually all other 3rd party AV apps today…

…and OC if the standard suse repo ffmpeg and all the app’s dependant on that generic shared code cant even handle “cook” audio that’s been ffmpeg supported for a year or more then its really antiquated and should never be placed on any new DVD release…

whats the problem with the suse team simply pulling a current UP TO DATE Nov 2011 GIT head (as in stable) of ffmpeg and x264 etc and submitting patches back upstream as they got ready for the 12.1 release, why didn’t they ? as in people have sandy bridge etc with its AVX hardware, and people want to take advantage of that large speed increase in all their audio and video usage…

so the question remains where can the average end user get a working current NOV 2011 ffmpeg/x264 and related compiled VLC and avidemux that uses these current base librarys…

then the OP can simply transcode their cook.MKV into a real x264/AAC.mkv or mp4 with a

ffmpeg -i “infile.mkv” -f mp4 -vcodec libx264 -crf 18 -refs 3 -preset faster -vprofile high -strict experimental -acodec aac 2 -ab 128k “outfile.mp4”

@pip10
But you know that ffmpeg violates licenses and patents in many countries
all over the world and cannot be distributed without being sued for this
and none of the main linux distros I know of ships it out of the box? It
is in the packman repository for that reason and its two mouse clicks
add the repo to install it.
Packman ships 0.8.6 which was released 2011-11-04, not really old I
would say.


PC: oS 11.4 (dual boot 12.1) 64 bit | Intel Core i7-2600@3.40GHz | KDE
4.6.0 | GeForce GT 420 | 16GB Ram
Eee PC 1201n: oS 11.4 64 bit | Intel Atom 330@1.60GHz | KDE 4.7.3 |
nVidia ION | 3GB Ram

it’s my understanding that not setting “–enable-nonfree” in ./configure by-passes all these concerns for any distro …

and there are no issues as regards “violates licenses” if they are only supplying the source code the free binary compiled from GIT and NOT the “–enable-nonfree” version on the DVD.

so saying “you know that ffmpeg violates licenses and patents in many countries” seems a little OTT ( over the top) as regards any distro not getting a current Git pull… as the ffmpeg dev’s themselves advise everyone to upgrade to GIT master (or failing that as you say 0.8.6) on their front page if possible, wait a few days and that will be considered old OC LOL

it’s my understanding that not setting “–enable-nonfree” in ./configure by-passes all these concerns for any distro …

and there are no issues as regards “violates licenses” if they are only supplying the source code the free binary compiled from GIT and NOT the “–enable-nonfree” version on the DVD.

so saying “you know that ffmpeg violates licenses and patents in many countries” seems a little OTT ( over the top) as regards any distro not getting a current Git pull… as the ffmpeg dev’s themselves advise everyone to upgrade to GIT master (or failing that as you say 0.8.6) on their front page if possible, wait a few days and that will be considered old OC LOL

Am 18.11.2011 03:06, schrieb pip10:
>
> it’s my understanding that not setting “–enable-nonfree” in ./configure
> by-passes all these concerns for any distro …
>
Which useful things do you expect to see in ffmpeg when the configure
switch is set to disable the nonfree part, this has nothing to do with
patent and license (I think about the MPEG) it is a switch to make
gpl/lgpl compatibility possible nothing else.

> and there are no issues as regards “violates licenses” if they are only
> supplying the source code the free binary compiled from GIT and NOT the
> “–enable-nonfree” version on the DVD.
>
I fail to see how this applies to any binary rpm, the source code is not
what is distributed to the user in the first place.

> so saying “you know that ffmpeg violates licenses and patents in many
> countries” seems a little OTT ( over the top)

http://ffmpeg.org/legal.html

> as regards any distro not
> getting a current Git pull… as the ffmpeg dev’s themselves advise
> everyone to upgrade to GIT master
A Linux distro is not everyone it is something which is not based on
pulling daily from git (or any other vcs) to be daily bleeding edge, if
you want that use the source and forget about prebuilt binaries. I do
that myself for a handful of applications.

I do not see what your comments have in any way to do with the original
problem in this thread and hence I will myself also stop at this point
and not comment any further since it is OT.


PC: oS 11.4 (dual boot 12.1) 64 bit | Intel Core i7-2600@3.40GHz | KDE
4.6.0 | GeForce GT 420 | 16GB Ram
Eee PC 1201n: oS 11.4 64 bit | Intel Atom 330@1.60GHz | KDE 4.7.3 |
nVidia ION | 3GB Ram

i agree its getting OT so enough said on your initial raised point “ffmpeg violates licenses”…

non the less, with my ffmpeg line above, and your reference to “Packman ships 0.8.6” an almost current GIT (non-free!) as of today version, then the OP should hopefully be set to go with playback and re-coding his non standard AV collections, providing OC that version knows about those new re-factored -crf 18 -preset faster -vprofile high etc options.

i didn’t get a chance to set-up a virtual box for trying 12.1 so cant confirm ffmpeg/avconv works as expected yet…

“Which useful things do you expect to see in ffmpeg when the configure
switch is set to disable the nonfree part” .

the simple answer is obvious, by supplying a current GIT pull from master (Not a daily bleeding edge pull every time it changes as you say) just before the distro goes gold , means you as an “end user” if you choose, can simply (and easily with a supplied purpose made bat/sell script) take the supplied source code on their DVD and make fully working “non-free” binary versions to replace the free binary version they supplied directly off your new install, everyone’s then happier as all the other dependant app’s have access to that exact source and library’s.

but again as you say that’s also OT so enough said there too…