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 119206 - mp1videoparse plugin doesnt perform its core function
mp1videoparse plugin doesnt perform its core function
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins
git master
Other Linux
: Normal normal
: 0.7.4
Assigned To: Ronald Bultje
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2003-08-05 20:50 UTC by Zeeshan Ali
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
see comment (4.92 KB, patch)
2004-01-20 15:41 UTC, Ronald Bultje
none Details | Review
new one (10.03 KB, patch)
2004-01-23 11:00 UTC, Ronald Bultje
none Details | Review
3 (5.51 KB, patch)
2004-01-24 23:52 UTC, Ronald Bultje
none Details | Review

Description Zeeshan Ali 2003-08-05 20:50:53 UTC
mp1videoparse is unable to do its main function: provide proper timestamps
on the buffers.
Comment 1 Ronald Bultje 2004-01-20 15:16:57 UTC
I'm working on this right now, so... What did you have in mind? MPEG
has three ways of providing timestamps:

* using mux_rate (very rough) in the demuxer
* using PTS, in the demuxer (the five bytes before the actual video
packet)
* using the time_code in the video packet. This is actually meant for
display only, not for actual reading, if I understand the specs
correctly. However, it's the only one that works without needing the
demuxer.

I prefer (2) if there's a demuxer involved, but (3) if there's no
demuxer involved, obviously.
Comment 2 Ronald Bultje 2004-01-20 15:41:28 UTC
Created attachment 23559 [details] [review]
see comment
Comment 3 Ronald Bultje 2004-01-20 15:45:00 UTC
Attached patch:

* improves parsing. We no longer cut solely based on picture
startcodes, but use gop/sequence startcodes and sequence endcodes,
too. The sequence/gop are for broken streams that don't use sequence
endcodes or not even sequence startcodes. The sequence endcode is a
valid end-of-picture, and after that, a new sequence will start
(which' header should be put in the next buffer, not the current one
like happened now).
* read timecode from GOP header and use that as timestamp if no PTS is
given.
* finetunings for (broken, but it happens a lot) streams that start
halfway a sequence rather than with a sequence start (mostly streaming
MPEG).

Please comment. :).
Comment 4 Ronald Bultje 2004-01-23 11:00:16 UTC
Created attachment 23665 [details] [review]
new one
Comment 5 Ronald Bultje 2004-01-23 11:01:09 UTC
The attached one loops over buffers so that we actually get multiple
MPEG blocks out of one buffer instead of only the first (discarding
the rest), this fixes green-block-playback. The rest is the same.

Seems to work fine for me.
Comment 6 Ronald Bultje 2004-01-24 23:52:46 UTC
Created attachment 23716 [details] [review]
3
Comment 7 Ronald Bultje 2004-01-24 23:53:21 UTC
This one fixes small parsing bug (we always write 4 bytes too much)
and the resulting potential segfault.
Comment 8 Ronald Bultje 2004-01-25 00:23:57 UTC
Added to CVS, closing this one.