After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 610857 - [assrender] noticeable delay in loading of files with ASS tracks
[assrender] noticeable delay in loading of files with ASS tracks
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 604067
 
 
Reported: 2010-02-23 17:21 UTC by Eric Appleman
Modified: 2011-08-19 05:02 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gst-debug of loading delay (332.64 KB, text/plain)
2010-02-23 17:22 UTC, Eric Appleman
Details
1st debug log with slomo's modification (161.39 KB, text/plain)
2010-02-24 01:26 UTC, Eric Appleman
Details
2nd debug log with slomo's modification (176.28 KB, text/plain)
2010-02-24 01:27 UTC, Eric Appleman
Details

Description Eric Appleman 2010-02-23 17:21:39 UTC
Let's say I have 350MB MKV with ASS tracks. When I attempt to load these files, there will be a delay of 1-3 seconds before the video and audio load.

If I use a 700MB MKV with an ASS track, that delay increases to around 5 seconds.

However, if I remove the ASS tracks from both files, they load more or less instantaneously.
Comment 1 Eric Appleman 2010-02-23 17:22:13 UTC
Created attachment 154521 [details]
gst-debug of loading delay
Comment 2 Eric Appleman 2010-02-23 18:35:14 UTC
After commenting out all references to ass_set_fonts, the delay disappears and files load within a second. Of course, doing this breaks proper assrender function.
Comment 3 Eric Appleman 2010-02-23 22:37:00 UTC
Not that it changes things, but upon more precise timing, my 700 MB file takes 8 seconds to display video if an ASS track is present.
Comment 4 Eric Appleman 2010-02-24 01:19:37 UTC
One more note, this delay does not occur with other libass implementations (VLC, MPlayer, etc).
Comment 5 Eric Appleman 2010-02-24 01:26:28 UTC
Created attachment 154556 [details]
1st debug log with slomo's modification
Comment 6 Eric Appleman 2010-02-24 01:27:04 UTC
Created attachment 154557 [details]
2nd debug log with slomo's modification
Comment 7 Sebastian Dröge (slomo) 2010-02-24 08:55:32 UTC
Ok, then we have to find the difference between our and their usage of libass. One thing I noticed is, that they only use a single ass_library_t and ass_renderer_t and one ass_track_t per stream.
Comment 8 Eric Appleman 2010-02-24 13:33:49 UTC
Not sure if it's related, but Greg has told me that the following lines are useless:

  ass_set_fonts (render->ass_renderer, NULL, "Sans");

  ass_set_fonts (render->ass_renderer, NULL, "Sans", 1, NULL, 1);
Comment 9 Sebastian Dröge (slomo) 2010-02-24 14:00:45 UTC
Does it make a difference if you remove these lines? :)
Comment 10 Eric Appleman 2010-03-01 05:53:00 UTC
Nope. Unfortunately...
Comment 11 Eric Appleman 2010-03-03 02:33:15 UTC
Commit d06e9c40e648a627b5b7c5b86c171bf84340530b is causing this.

The commit immediately prior allows for instant loading of ASS tracks.
Comment 12 Eric Appleman 2010-03-03 04:11:38 UTC
Hmmm. Even after altering the previous code to search for x-font-ttf instead of x-truetype-font, there is still a loading delay.
Comment 13 Sebastian Dröge (slomo) 2011-05-23 15:06:51 UTC
Is this still a problem with the latest releases?
Comment 14 Akhil Laddha 2011-07-07 05:43:06 UTC
Eric, can you please update the bug in case you are able to reproduce the problem with latest release ?
Comment 15 Akhil Laddha 2011-08-19 05:02:54 UTC
Please feel free to reopen this bug if the problem still occurs with a newer version of GStreamer Core 0.10.35, Base Plugins 0.10.35, Good Plugins 0.10.30 stable release, tia.