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 310996 - problem when retrieving the data of a frame (seek problem)
problem when retrieving the data of a frame (seek problem)
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.8.10
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-07-20 13:04 UTC by Vincent Torri
Modified: 2006-01-12 19:27 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
small test program (4.46 KB, text/plain)
2005-07-20 13:06 UTC, Vincent Torri 		Details
improved test program (6.42 KB, text/plain)
2005-07-27 16:39 UTC, Vincent Torri 		Details

Description Vincent Torri 2005-07-20 13:04:36 UTC 
With a basic pipeline (see the file main.c in the attachment below), when I try
to retrieve the frame data, I only get a black image. You can use  the file
http://www.iecn.u-nancy.fr/~torri/files/gstreamer_pb/blood.mkv to test the program.

The program seeks to frame #175 and creates a test.ppm file that should be the
frame. I only get black image. The name of the file is hardcoded.
Comment 1 Vincent Torri 2005-07-20 13:06:34 UTC 
Created attachment 49456 [details]
small test program

video filename and frame number are hardcoded. The video is supposed to be in
I420. If it's in YV12, U and V must be swapped.
Comment 2 Vincent Torri 2005-07-27 16:38:02 UTC 
i have added an avi test file
(http://www.iecn.u-nancy.fr/~torri/files/gstreamer_pb/blood.avi) and i have
improved a bit the test program (see attachment below)
It seems that it's more a seek problem. With this avi file:

1) If I seek to frame 175 (that is, 7s) the buffer timestamp is 171798696.135s
and the frame is black.
2) If I seek to frame 1000 (that is, 40s), the buffer is good, but the buffer
timestamp is 38.655s, so a shift of 1.345s. So i think that I do not display the
 frame # 1000.
Comment 3 Vincent Torri 2005-07-27 16:39:57 UTC 
Created attachment 49848 [details]
improved test program

Usage : ./main /path/to/file frame_number
Comment 4 Andy Wingo 2006-01-12 19:27:08 UTC 
Seeking was improved quite a bit in 0.10. I don't think anyone is going to look at this one in 0.8. Give 0.10 a try, and if you find problems please file new bugs.