[gst-devel] [RFC][PATCH] Fix and add needed features to dvdnavsrc

[Simone Gotti]

Hi all,

I worked in the past days to fix dvdnavsrc as it wasn't working (at
least for me) and missing some important features like seeking. I did an
initial patch that I'm attaching here and I'll really appreciate any
comment.

To test all I used this simple pipeline (hadn't tested subpicture
again):

gst-launch dvdnavsrc ! dvddemux name=demux .video_00 ! { queue !
mpeg2dec ! xvimagesink } { demux.current_audio ! queue ! a52dec !
audioconvert ! audioresample ! alsasink }


I'll try to list all the changes I did plus some problems and questions:

*) Add still frame management:
It uses gst_clock_new_single_shot_id on the system clock to wait. The
user operation works correctly during still frames.

*) Add query convert ability.
The functions converts between sectors, bytes and time.
The sector/bytes to time conversion and the opposite con be done in 2
ways:
using the DVD time maps if available (like dvdreadsrc does) or using
time/sector interpolation.

Looks like there a bug in dvdnav_get_position where the pos and length
values aren't correctly calculated. I did a patch that will fix it and
I'll submit it for discussion to the dvdnav developers. In the mean time
dvdnavsrc does a check and if the max sector reported by the tmaps is
less or equal that the one reported by dvdnav_get_position the tmaps
aren't used.

*) Add seeking ability.

*) Also the NAV packets needs to be sended to the demuxer as they
carries
data.

*) Fix chapter number retrieve call (it was using
dvdnav_get_number_of_titles instead of dvdnav_get_number_of_parts).

*) In gst_dvd_nav_src_tca_seek rename program variable to chapter
variable.

*) Remove did_seek gboolean as it's not used anymore.


TODO:
*) Handle seek on title chapter angle: easy to do, I'm waiting to look
if what I did until now is right or it simply sucks :D


Problems / Questions:

1) I removed a lot of segment events as the seek ones are already
managed by the parent basesrc. The other one doesn't do any effect
because looks like dvddemux (and it's parent class) prefer to use the
SRC/pts times provided by the strean to report newsegments downstream.

2) Now, the use of SCR/pts for syncronization is the unique and right
way so no problem.
But I don't think that they are the right way when we are doing position
queries.
The problem is that I have some DVD where the SCR and pts restarts from
0 after some time:

t1: 0
...
tX: 342242432
...
tX+Y: 0 (again)


As a query on the pipeline is asked starting from the sinks a
position query with a time format is reported in the wrong way as the
position time will restart from 0.

By now the unique right way to get a position is asking directly to the
dvdnavsrc. The position will be an aproximation but it will be quite
right and continous. Looking at various codes this way to get the
position is the same done by other projects like VLC and xine.

What do you think about this? The applications that uses dvdnavsrc (but
this problem also affects dvdreadsrc) should do the query directly on it
instead of the pipeline? But how to handle this with
playbin?

Thanks!
Bye!

-- 
Simone Gotti
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dvdnavsrc-megafix-20070911-1227.patch
Type: text/x-patch
Size: 29170 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20070911/c0ffb0fa/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20070911/c0ffb0fa/attachment.pgp>