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 752521 - validate: error when seek_forward with mp3 file
validate: error when seek_forward with mp3 file
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-devtools
git master
Other Linux
: Normal normal
: 1.5.90
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-07-17 08:15 UTC by Vineeth
Modified: 2015-08-16 13:41 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
get duration from media-info if query fails (1.87 KB, patch)
2015-07-17 14:45 UTC, Vineeth
committed Details | Review

Description Vineeth 2015-07-17 08:15:01 UTC
In case of mp3 files which don't have duration in header.
So base parse starts the estimation of the duration after 1.5 second.

When i run the following validate scenario
GST_VALIDATE_SCENARIO=seek_forward gst-validate-1.0 playbin uri=file:///home/user/gst/master/test/1.mp3

it fails like this
Starting pipeline
Pipeline started
Trace/breakpoint trap (core dumped)


This is happening because,
GST_MESSAGE_ASYNC_DONE is being posted by playsink, before the duration is estimated(1.5 second)..
and _set_action_playback_time is getting called in gst-validate-scenario.c
which fails because duration is not available and it crashes with g_error...


do we need to call _set_action_playback_time for GST_MESSAGE_ASYNC_DONE??
and if needed, does it really need to crash, or we can just print error, and return FALSE, thus letting the tests to continue.
Comment 1 Thibault Saunier 2015-07-17 08:34:49 UTC
I guess the only choice we have here is to let the pipeline play regularly trying to get the duration and start executing actions as soon as we have the duration.

Another option would be to make use of the duration from the media_info file and force the usage of such a file (through the --set-media-info option in gst-validate-1.0) in case we could no query duration on ASYNC_DONE.

I like that second option :)
Comment 2 Vineeth 2015-07-17 11:29:59 UTC
Any pointers on how to achieve second option? :)
media-info will be available in gst-validate.c and being set to mediadescriptor..
but not able to figure out how to get the information in gst-validate-scenarios :(
Comment 3 Thibault Saunier 2015-07-17 12:37:17 UTC
'algo':

GST_VALIDATE_MONITOR(scenario.pipeline.get_data("validate-monitor")).media_descriptor
Comment 4 Vineeth 2015-07-17 14:45:10 UTC
Created attachment 307622 [details] [review]
get duration from media-info if query fails

When duration query fails, trying to get the duration from media-info, if called using --set-media-info.
If media info is not set, printing error message and throwing error.
Comment 5 Thibault Saunier 2015-07-17 15:35:04 UTC
Review of attachment 307622 [details] [review]:

Looks good :)
Comment 6 Luis de Bethencourt 2015-07-22 15:46:48 UTC
Review of attachment 307622 [details] [review]:

commit 7e91f73c76d39dacdce26e0a509523e0014123b7
Author: Vineeth T M <vineeth.tm@samsung.com>
Date:   Fri Jul 17 23:42:22 2015 +0900

    validate-scenario: get duration from media_info if not able to query

    In case of files, which don't have duration in header, baseparse
    estimates the duration only after 1.5 seconds. But Async_done event
    is sent before the duration is estimated, which results in error.
    If duration query fails, getting the duration from the media-info being
    passed through --set-media-info. If media-info is also not set,
    printing an error message and throwing error.

    https://bugzilla.gnome.org/show_bug.cgi?id=752521