Thu 17 Mar 2011 01:08:58 PM UTC, comment #14:
Sorry I misunderstood.
I do not see the bar while the movie playback is going on. It is only there before movie starts and comes up again once it ends.
I am using Ubuntu 10.10
|
Wed 16 Mar 2011 10:08:48 PM UTC, comment #13:
> The permanent bar in the middle of the video does appears once the video ends.
I can see it during entire movie, that's why I called it permanent.
Either on debian squeeze or testing.
|
Wed 16 Mar 2011 02:28:15 AM UTC, comment #12:
Aha... I was thinking about those even as I posted.
The permanent bar in the middle of the video does appears once the video ends.
The time bar does progress, just that the colour is kind of light making it hard to perceive. However once the video ends it does not go back to the start position and neither does the play button show up (keep seeing the pause button). However am not sure what should ideally happen, yet to run it using the proprietary plug-in.
|
Wed 16 Mar 2011 01:13:23 AM UTC, comment #11:
Does perfectly mean that permanent bar in the middle of the video and time bar which doesn't work?
|
Tue 15 Mar 2011 11:16:53 PM UTC, comment #10:
Thanks for testing!
|
Tue 15 Mar 2011 11:14:22 PM UTC, comment #9:
I tested this with rc4 and works perfectly. Thanks a lot!!
- Dipto
|
Sun 13 Mar 2011 02:22:15 AM UTC, comment #8:
I would test soon and let know. Thanks - Dipto
|
Sun 13 Mar 2011 02:08:28 AM UTC, comment #7:
Fixed in ae867e6191a6014cb1f2a4739f275ef847eea787.
Dipto: This should be in rc4, but feel free to test using branch master from git.
Thanks for reporting!
|
Sun 13 Mar 2011 02:06:46 AM UTC, comment #6:
To amend comment #4, _parsingComplete's semantics (from MediaParser docs) indicate that after it indicates whether video frames can be returned; so MediaParserGst was setting it too early.
|
Sun 13 Mar 2011 12:35:38 AM UTC, comment #5:
The diagnosis is incorrect, because it only applies to the video from the Gnome bug tracker.
In the video from the original submission the problem is that the h264 parser element changes its GstCaps after a while, which is rejected by the pseudo element Gnash uses to receive buffers.
|
Sat 12 Mar 2011 08:59:57 PM UTC, comment #4:
The second bug is that _parsingComplete is used to determine whether the parser should be asked for more frames, but MediaParserGst sets it as soon as it has read to the end of the file, rather than when all the encoded frames have been emitted.
|
Sat 12 Mar 2011 08:50:26 PM UTC, comment #3:
Diagnosis:
With this type of video the parser has to download the entire file before it can find the types of audio and video inside the file. So when typefinding has finished, the parse has the whole video buffered up and ready to go.
MediaParserGst pushes all of its encoded audio frames to MediaParser, and then all of its encoded video frames.
The bug is that MediaParser locks the parsing thread after all the encoded audio frames are pushed, but before the video frames are pushed. MediaParser does not unlock the thread until Gnash terminates.
|
Sat 12 Mar 2011 08:31:00 PM UTC, comment #2:
Seems to be related to https://bugzilla.gnome.org/show_bug.cgi?id=587426 , i.e. the movie being played here also does not have a fast-start header.
|
Sat 12 Mar 2011 07:43:47 PM UTC, comment #1:
Works with FFMPEG, nog Gstreamer.
|
Sat 12 Mar 2011 07:40:01 PM UTC, original submission:
The latest 0.8.9 RC3 version of the Gnash does not seem to be able to play the below file, on yahoo emails login screen. Properties says that it is AVM1.
https://s.yimg.com/cv/eng/secure/yahoo/110106/video.swf
Thanks,
Dipto
(diptorupd@gmail.com)
|