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 138435 - [TRACKER] My media file doesn't playback!
[TRACKER] My media file doesn't playback!
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins
git master
Other All
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 310611 (view as bug list)
Depends on: 126922 132341 135052 135145 135862 137724 137746 137748 138664 138666 138669 138671 138672 138676 138678 138680 139547 140058 140128 140137 140139 140141 140146 140147 140411 140878 141176 141189 141539 142320 142712 143553 143555 144384 144510 148287 149158 149742 151192 151398 151952 152688 152798 153263 155008 155163 159059 159327 160116 160665 161262 161435 161726 162184 162417 162638 166031 166491 166747 166748 166749 166750 168035 171371 173007 302606 307353 307801 307826 310053 313266 313838 315557 317310 317539 317780 318663 320114 320984 321650 321917 325552
Blocks:
 
 
Reported: 2004-03-29 17:43 UTC by Ronald Bultje
Modified: 2008-04-06 22:30 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ronald Bultje 2004-03-29 17:43:00 UTC
This is a general tracker for files that fail to playback with GStreamer and
spider (libgspltay, gst-player, totem).

Guidelines:
* make sure there's no other similar bug for the same media type
(codec/format/symptom combination).
* make a separate bug for your file that refuses to playback. Ask for a bugsquad
or GStreamer developer to confirm and make this bug depend on it. Please don't
do that yourself unless you know what you're doing.
* if it fails using opt but works using basicgthread, it doesn't belong here.
*ALWAYS* test with basicgthread.
* provide a link to a file or another way of obtaining the file.
Comment 1 Benjamin Otte (Company) 2004-03-29 17:45:35 UTC
adding first bug and myself to CC
Comment 2 Stephane Loeuillet 2004-03-31 21:38:29 UTC
for bugs  138664 138666 138669 138671 138672 138676 138678 138680 : ask ronald
for login/pass FTP access on leroutier.net

all files are under /riff-avi/_bad_/
Comment 3 Johan (not receiving bugmail) Dahlin 2004-05-07 11:06:46 UTC
So, I'm considering reopening all bugs that does not have a test in the media
testsuite attached. 

That way we can make sure that they always keep on working. It's really no point
fixing stuff at one point and noone noticing that they breaks at a later point.
I can help adding stuff to the testsuite, but I need media files (hopefully
small ones) and a pipeline which can do the playback. We should also separate
the muxing from the decoding and have separate tests for each stream in the
container format.
Comment 4 Ronald Bultje 2004-05-07 14:56:31 UTC
Add them to the testsuite, and if they fail, reopen them. Please note that I
don't know how the testsuite works. Please document that. I didn't even know
people wanted me to add those files to the testsuite.
Comment 5 Andy Wingo 2006-01-27 14:51:30 UTC
*** Bug 310611 has been marked as a duplicate of this bug. ***
Comment 6 David Schleef 2007-05-13 21:57:12 UTC
We've done a really stellar job at using this bug for tracking broken media files.  Do we want to continue to use it, or should I just close this bug?
Comment 7 Tim-Philipp Müller 2007-05-13 22:41:52 UTC
> We've done a really stellar job at using this bug for tracking broken media
> files.  Do we want to continue to use it, or should I just close this bug?

I don't use it, and I don't have the impression anyone else does, so IMHO it should just be closed.


Comment 8 Edward Hervey 2007-05-14 09:27:58 UTC
We should set up a public/automated gst-media-test before closing this IMHO. So we know these (and future) regressions of file playback don't go unnoticed...

... Or we could create a new bug for that and close this one.
Comment 9 Tim-Philipp Müller 2008-04-06 22:30:16 UTC
No one's using this any longer, closing.