maninha22crazy / gecko-mediaplayer

Automatically exported from code.google.com/p/gecko-mediaplayer
GNU General Public License v2.0
0 stars 0 forks source link

do not start playing .avi files automatically #149

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Load an .avi file [1]
[1] http://vidxden.com/tlj1bjef8pyl/bbta306.avi.html
2. Wait for the buffer to fill
3. At this point the media cannot be scrolled (either hitting the scroll bar or 
by using in fullscreen bindings such as left/right)

What is the expected output? What do you see instead?
At least for .avi files (or perhaps for all) gecko-mp could simply inform the 
user when the initial buffer is full and the stream can be played. Then the 
user could hit play. In case of .avi files, the user could wait for the movie 
to fully download (hit 100%), and then hit play and have a scrollable media 
file. 

Now gecko-mp automatically starts playing and breaks the scrolling of .avi 
files. 

What version of the product are you using? On what operating system?
1.0.4. Xubuntu 10.04. Opera

Original issue reported on code.google.com by landroni...@gmail.com on 22 Jul 2011 at 9:27

GoogleCodeExporter commented 8 years ago
Seeking depends on if mplayer reports if the media is seekable or not. 
Upgrading mplayer may solve your problem.

Original comment by kdeko...@gmail.com on 23 Jul 2011 at 2:09

GoogleCodeExporter commented 8 years ago
I don't think that this issue has more to do with the peculiarities of the AVI 
format when a given .avi is truncated, than with the version of mplayer. By 
default media players (at least mplayer and vlc) cannot seek truncated .avi 
files. Since the 2% buffer is essentially a truncated .avi file, when playing 
starts automatically the ability to seek throughout the file is lost. (This 
doesn't hold for .flv format.) 

I have now tested with mplayer SVN 33891 and the problem persists. Waiting for 
the file to download completely before starting the playback may be the only 
way to enable seeking in such cases, and the user might want to do this. 

Original comment by landroni...@gmail.com on 23 Jul 2011 at 5:33

GoogleCodeExporter commented 8 years ago
Instead of treating .avi files differently (by not starting to play them prior 
a 100% download), perhaps would be better to propose an option in Preferences: 
"Automatically start playing media files in gecko-mp" (or similar). 

The idea is that this will cover not only the specific issue of .avi files, but 
also the more general one of (as it is now) having to wait until the 2% buffer 
has been filled and the video has started in order to hit pause and wait for 
the download to finish. This is especially troublesome when the internet 
connection is slow. 

Original comment by landroni...@gmail.com on 23 Sep 2011 at 6:34

GoogleCodeExporter commented 8 years ago
There are some workarounds to this issue, of which none of them are great.

One option is to add -forceidx to the mplayer command line in Edit->Preferences 
[mplayer] in gnome-mplayer. However, this can cause issues for other media 
files and will only allow seeking in the part of the file that was available 
when mplayer is started (ie the first 20%). 

Also some formats place the metadata about the file at the end of the file (I 
can't recall is AVI is one of those). Which is a problem if you want to start 
playing before the metadata is available. This data may include keyframe 
locations or other important data related to seeking.

With some quick time files I start playing them, but mplayer will give an error 
about a missing header (which is at the end of the file) and mplayer will exit. 
In this condition I will wait until the file is complete and then retry. Since 
mplayer does not give a similar message about these avi files it is hard to 
detect when I should wait for the file to be completely cached. Looking for an 
.avi extension and ID_SEEKABLE=0 is not reliable enough for consistent 
detection.

Original comment by kdeko...@gmail.com on 23 Sep 2011 at 12:51

GoogleCodeExporter commented 8 years ago
On the mplayer-dev list there are some patches to mplayer that help and solve 
this issue. I have heard that they work from a couple of users. So you may just 
need to upgrade mplayer to a newer version (within the last couple of weeks) 
and it may be fixed.

Original comment by kdeko...@gmail.com on 20 Apr 2012 at 8:15

GoogleCodeExporter commented 8 years ago
Nice to know. I'm currently experimenting with mplayer2 GIT. Do you know if 
they mirror MPlayer SVN? Or should I switch back to mplayer SVN? 

Thanks! 

Original comment by landroni...@gmail.com on 20 Apr 2012 at 8:33

GoogleCodeExporter commented 8 years ago
I know that many of the patches that get into mplayer usually end up in 
mplayer2, but for this specific one I would check with them. mplayer and 
mplayer2 are basically separate projects at this point.

Original comment by kdeko...@gmail.com on 20 Apr 2012 at 8:37