This a puzzle. I’ll do my best to explain.
I have this situation:
http://thumbnails28.imagebam.com/13802/da85bd138018697.jpg](http://www.imagebam.com/image/da85bd138018697)
Gnome or kde makes no odds.
All other players: vlc, kaffeine, totem
All play the audio fine (aac).
Later I’ll upload a clip, if it helps?
If it were possible to post a clip some where it could help us see the problem. Otherwise, you would have to assume some sort of change occurred with the exact encoding method, though I am no expert on this issue. Perhaps if one could find a system where it works and were it does not, it could be helpful.
Thank You,
PS, that chart seemed more understandable after drinking a beer I noticed. Perhaps you might try that as well. lol!
If it were an encoding issue, why would a not updated openSUSE play it in SMPlayer?
I’ll PM you a link, as I’m unsure about copyright.
But then of course, I was asking, why does SMPlayer play the earlier encoded videos OK
OK
So here is the media info:
Format : MPEG-4Format profile : Base Media
Codec ID : isom
File size : 167 MiB
Duration : 29mn 13s
Overall bit rate : 800 Kbps
Writing application : Lavf53.2.0
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 29mn 13s
Bit rate mode : Variable
Bit rate : 699 Kbps
Width : 640 pixels
Height : 360 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.121
Stream size : 146 MiB (87%)
Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format version : Version 4
Format profile : LC
Format settings, SBR : Yes
Format settings, PS : No
Codec ID : 40
Duration : 29mn 13s
Bit rate mode : Constant
Bit rate : 96.0 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Stream size : 19.8 MiB (12%)
Format : MPEG-4Format profile : Base Media
Codec ID : isom
File size : 635 MiB
Duration : 59mn 7s
Overall bit rate : 1 502 Kbps
Genre : Factual
Encoded date : 2011-06-09T20:00:00+01:00
Tagged date : UTC 2011-06-10 02:59:08
Writing application : Lavf52.64.2
Cover : Yes
rtng : 2
stik : 10
tves : 2
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 59mn 7s
Duration_LastFrame : -40ms
Bit rate mode : Variable
Bit rate : 1 402 Kbps
Width : 832 pixels
Height : 468 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.144
Stream size : 593 MiB (93%)
Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format version : Version 4
Format profile : LC
Format settings, SBR : Yes
Format settings, PS : No
Codec ID : 40
Duration : 59mn 7s
Bit rate mode : Variable
Bit rate : 96.0 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Stream size : 40.1 MiB (6%)
caf4926, I looked at that sketch in your first post, and it does not make much sense to me, unless you are testing across multiple boot partitions (or PCs).
Are you saying the following ?
At the risk of stating the obvious which unfortunately may not even be relevant, I note this:
I think “Lavf”, is “LibAVFormat” which is the ffmpeg file parser. I don’t think its an encoder.
Ergo could it be that there is something with the file parsing ? ie the wrapper/packaging, where today’s mplayer/smplayer is a bit fussier than yesterday’s mplayer/smplayer, and the change in LibAVFormat has modified the wrapper/packaging (call it the file parsing).
My apologies for my horrible non-technical description and bad terminology.
Ergo to summarize my rather speculative look : today’s smplayer/mplayer has a problem with videos wrapped/parsed with Lavf53.2.0 ?
Ergo to summarize my rather speculative look : today’s smplayer/mplayer has a problem with videos wrapped/parsed with Lavf53.2.0
I think you hit right on the situation there Lee.
I am booting 3 installations of openSUSE 11.4 (2 are fully updated and have the problem) (1 is not quite so up to date and is OK)
These video files are downloaded with get_iplayer and ffmpeg is used in the conversion process.
So let me try and re-summarise:
The not so updated openSUSE can play all the files, old or newly downloaded.
The updated openSUSE can only play the older files.
When I say play, I mean the video does play, it’s just the audio that doesn’t work, the actual video is fine.
This confusing. It may be something other than s/mplayer. As a versioncheck shows:
Working Install:
smplayer-0.6.9+r3599-1.pm.3.1.x86_64
gnome-mplayer-1.0.2-1.pm.1.3.x86_64
gmplayer-1.0rc4_r33321-1.pm.1.4.x86_64
gnome-mplayer-lang-1.0.2-1.pm.1.3.noarch
Not Working:
smplayer-0.6.9+r3599-1.pm.3.1.x86_64
gnome-mplayer-1.0.2-1.pm.1.3.x86_64
gmplayer-1.0rc4_r33574-1.pm.1.3.x86_64
Those are just front ends.
Is it not the MPlayer version that is more important ?
I also assume with those front ends that you have the same output audio mode selected (for an apples to apples comparison).
So the link Carl sent plays just fine on two up to date openSUSE 11.4 64 bit PC’s, but I have updated to mplayer2 on both computers and no longer use the old mplayer2. Of course, from the link I got, I used Totem to actually play the video, if that makes any difference which was my only choice in Firefox.
Thank You,
Interesting that ‘mplayer2’ plays it.
Given mplayer2 does NOT include mencoder, I consider mplayer2 more an inferior software ‘fork’ than an update, although I can’t deny it may play some formats that mplayer fails to play.
Edit : I note the video (with audio) plays on my PC with xine, vlc and ffplay.
Interesting that ‘mplayer2’ plays it.
Given mplayer2 does NOT include mencoder, I consider mplayer2 more an inferior software ‘fork’ than an update, although I can’t deny it may play some formats that mplayer fails to play.
Edit : I note the video (with audio) plays on my PC with xine, vlc and ffplay.
So I do not know what the issue is, but with so many choices that do play, I am not sure how big a problem this might be. As for updating to mplayer2 from mplayer, I have had no issues with playing content online or offline but I did note the differences in a message oldcpu had posted elsewhere. I am thinking mplayer2 will at some point be the only real choice, but perhaps I don’t understand the issues for the fork.
Thank You,
if and when mencoder is included with mplayer2 I may update to mplayer2. But with no mencoder, I can’t honestly even consider updating to mplayer2. I use mencoder a fair amount.
Mencoder or no mencoder. (Edit - I’ve read the developers on the team of the mplayer2 fork are unhappy with the mencoder code - so much so they refuse to use it).
That’s the clear issue for me.
James and Lee.
That file doesn’t play in SMPlayer (well the audio doesn’t), on my updated 11.4 system.
Let me check what updates are in the system that hasn’t been updated very recently.
I also notice the progress bar doesn’t move, although the video plays —>
Is that the version of MPlayer version 1.0rc4_r33321-1.pm.1.4 where both the audio and video plays ?
I’m curious as to what version of MPlayer does work with it and what version it does NOT work.
Yes.
That’s a list of updates from the machine that plays the file in smplayer
Hmmm … looking at the changelog between 1.0rc4_r33321 and r33574
* Sun Jun 12 2011 pascal.bleser-at-opensuse.org
- update to 33574:
* fix segmentation fault when pressing U (stop playing) in GUI
* a GUI related option which corresponds to a MPlayer option '-optname' will
be named '-gui-optname' now
* rename option '-guiwid' '-gui-wid'
* add option '-gui-include'
* constrain libcdparanoia's caching which badly breaks playback with -nocache
* improve seeking for files where start_time is not (properly) set
* setup default speex modes, allows decoding of speex in flv which does not
contain a header packet
* fix #1442: do not remove video filters: If a video filter option isn't set,
it does not mean to remove the filter, but such option (if set) should only
cause adding the filter (if not already present). That way filters can be
specified in MPlayer's config or on the command line, too.
* support Etymonix MPEG-2 I-frame Video Codec
* Command Line Options: Support FFmpeg per-codec AVOptions: this change
extends the existing support for arbitrary FFmpeg options to also include
per-codec AVOptions. You can now pass per-codec options in the same way as
global options are passed: mplayer -lavdopts o=<option>
* increase the maximum value of the DVB timeout to 240 seconds: some devices
may need more time for the initial tune (e.g. firmware loading). Let the
user specify higher timeout value if there is need to. The default remains
30 seconds.
* fix #574: instead of exit_player(), exit with appropriate return code
* support up to 20 mouse buttons, there really seem to be input devices with
at least 12
* fix bug introduced in r25726 that would cause us to write uninitialized
data into buffer
* support displaying of 9- and 10-bit pixel formats, as used by v210 and H264
* support playback for more ffv1 pixel formats
* support S302M (with -demuxer lavf)
* support S302M in the native ts demuxer
* support FFmpeg r10k decoder
* support Digital Voodoo SD 8 Bit (DVOO)
* add MNG output support
* stream dump: print progress information
* allow directory selection with middle mouse button (single click)
* start playlist selection in same directory the file selector starts in
* support 9- and 10-bit YUV input for OpenGL vos
* fix clear/border color of chroma texture for 9- and 10-bit formats: avoids
pink borders for those formats
* workaround embedded ssa/ass never hiding with -noass
* only accept regular files as .bin files for .cue files
* remove a duplicated open() call that could lead to a file-descriptor leak
in some cases
* avoid possible crash if cue filename is very short
* take notice of MPlayer option '-display': if option '-display' is given,
initialize GTK in a way that the GUI will run on that display
* change -udp-slave code to temporarily fall back to normal timing after 30s
network timeout
- bump ffmpeg to d127d26997ff046a9f112643eebd1007590b4fa2
* Sun Apr 24 2011 pascal.bleser-at-opensuse.org
- update to 33321:
............
Its hard to say what caused it … there are many changes … some of them being (that maybe could be relevant):
… I’m guessing … possibly one of them.
My guess is this is an upstream bug. I’m in above my head in some other stuff right now, and don’t have time to search for upstream bug reports on this.
On my main Desktop, I had to use a solution because it was just ticking me off.
So I switched to a backup packman repo I had rsync’d to my HD
It’s all working fine now. And I’ll probably stick with it like this