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

[Simone Gotti]

Hi all,

I opened bug #476149.

I attached there an updated patch.

I started testing also dvdspu form gst-plugins-bad and it's working
quite well with this updated patch.

These are the new changes:

*) Change the use of tmaps based on hints from bugzilla #372797
*) Add locking on tmaps use.
*) Send application/x-gst-dvd as Out of Band events. As during the menus
there's no subpicture sent to the subpicture sink pad of the spu decoder
and they aren't received until the next subpicture comes.

About the problems and questions on position queries I'll open new
threads on this ML for every question so everything will be clear.

Thanks!
Bye!

On Tue, 2007-09-11 at 12:47 +0200, Simone Gotti wrote:
> 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!
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________ gstreamer-devel mailing list gstreamer-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
-- 
Simone Gotti
-------------- 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/20070912/86229f48/attachment.pgp>