[MPlayer-dev-eng] [PATCH]: dvb_in module fixes

Alban Bedel albeu at free.fr
Tue Apr 29 11:18:43 CEST 2003


Hi Nico,

on Tue, 29 Apr 2003 10:42:27 +0200 you wrote:

> 
> 
> Alban Bedel wrote:
> 
> >Hi Nico,
> >
> >on Mon, 28 Apr 2003 01:14:12 +0200 you wrote:
> >
> >  
> >
> >>Hi,
> >>actually the dvb-in module is broken because of the changes in the 
> >>option parsing code.
> >>    
> >>
> >Wich changes ? There where some changes a while back but it was mainly
> >new options type, so it shouldn't have affected this code.
> >But the stream opening have been hacked.
> >  
> >
> 
> If I  remember correctly there were some changes  in cfgparser, right?
Some month ago ... anyway i can't really tell more as i don't have the
needed info.

> >  
> >
> >>This patch for mplayer-cvs is to restore it, clean some code, fix some
> >
> >>bugs, remove some obsolete code and to add (partial) conformance with 
> >>the uri syntax both in mplayer and in mencoder:
> >>
> >>mplayer dvbin//Pro7
> >>mencoder dvbin://Pro7 -ovc xvid -oac copy -o film.avi -vop denoise3d
> >>    
> >>
> >
> >You reintroduced a cmd line parameter to enable dvbin ?
> >+#ifdef HAS_DVBIN_SUPPORT
> >+if(dvbin_param_on || (filename && !strncmp("dvbin://", filename, 8)))
> >+{
> >+
> >  
> >
> I didn't reintrduce it, it's been in cvs since my  patch was committed, 
> but in the last release all dvbin options and suboptions weren't 
> recognized anymore:
> mplayer didn't even recognize -dvbin as a valid parameter.
Actually that's sound really strange.

> BTW, later I realized that that block can be pushed back at the bottom 
> of the switch statement (where it was sooner), and  can be changed so:
> 
> if(strncmp("dvbin://", filename, 8)==0)
> 
> like the other ones.
Yes, that's way better but if you go for the new api you will have to
remove that from open.c anyway ;)

> 
> It seems that all functions in open.c do the sub-option parsing
> themselves. If I want to parse a string to extract my sub-parameters (
> i.e. 
>  dvbin://RaiLab:card=1:type=SAT) do I have to parse the string on my own
>  
> or is there
> some function that I can  call?
In the new api you can "define" a struct wich will contain all the
parameters you need. So on the open call you get this struct ready
to use. You just need to free it when you are done.

> >That's bad. Actually I'm trying to clean the stream stuff so that it's
> >possible to open sevral stream at the same time. And ultimatly it
> >should also be possible to open sevral stream of the same type at the
> >same time.
> >
> Nice, so we will have N windows open?
Maybe ;) But seriously i think it's important that the streams work well,
playlist are read from stream for example. They are not very much used
just bcs it was for long only possible to (reliably) open 1 stream at a
time :(

> >Currently i finished file, cdda, vcd and null (tv,mf). imho it would be
> >better if you ported dvbin to the new api
> >Mainly you have to replace the dvdin stuff from open.c/stream.c by the
> >callbacks used by the new api.
> >
> 
> Ok, I only need some documentation of the new api, where can I find it?
No doc atm :( stream_file.c is more or less the reference.
Ok, i'll start to write some.

> >It look like this stream type have a lot of options. 
> >
> I reduced them to five: dvb type, card number, vid/aid (just for 
> debugging and to avoid to re-tune) and program name
I never meant that you should reduce the number of options ;)
If they have some use you should keep them imho.

> >So not all can be
> >passed in the url. For such stream the currenttly existing options
> >should now set the "default value", so from the user pov these option
> >just still works. But they can still be overrided by the "per-instance"
> >parameters. You can look at the cdda stream as example.
> >Ok, options to set the "per-instance" parameters for the "main" stream
> >and the "audiofile" one are still missing but it not so important atm.
> >
> >  
> >
> >>There is some issue still to solve, but for the moment the code should
> >
> >>be acceptable.
> >>    
> >>
> >
> >I'm also wondering about the part where you touch the playtree in
> >mplayer.c I don't really understand what you are trying to do, but :
> >
> >+		entry = play_tree_new();
> >+		play_tree_add_file(entry, "dvbin://");
> >+		list = entry;
> >+		play_tree_append_entry(list,entry);
> >
> >is wrong.
> >
> 
> I  was trying to instruct mplayer to push back in  its playtree 
> "dvbin://" after a first opening of the device,
> otherwise if you change channel you pass to the next item in  the 
> playlist, which is either empty or something else:
> the result is that you don't see the next channel (dvbin:// is 
> considered played).
> Leaving alone for a moment the correctness of the hack, is the above 
> code the right one to push-back dvbin:// in the playlist?
No. The last line is eq. to play_tree_append_entry(entry,entry);
wich is just none sense. I thought to something, isn't it possible to
get a list of all channels ? If so we can just put something wich
automaticlly generate a playlist with all channels. That would be the
easyiest/cleanest way.

> >BTW the vo's should support multiple config call so having the stream
> >resolution to change should be possible (if the codec support it).
> >
> libmpeg2 doesn't seem to like it: it always crashes
and lavc ?

> >But for the audio it's probably completly impossible atm.
> >It just that i dont tkink that it's right to have a stream type wich
> >play with the user playlist. But atm such a hack is probably "simpler".
> >	Albeu
> >  
> >
> 
> I'm willing to use a better method, but since I don't know that part of 
> mplayer very much I need advices, so what do you suggest?
> 
> >_______________________________________________
> >MPlayer-dev-eng mailing list
> >MPlayer-dev-eng at mplayerhq.hu
> >http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
> >
> >  
> >
> 
> BTW, afaik you wrote the menu code; I was trying to add a DVB channels 
> menu, based on menu_filesel.
> I called the menu "dvbsel".
> Whenever in the config file appears such menu item mplayer crashes.
> Where can I get a description of the api?
> 
Again i wrote no doc for that either :(( And frankly i didn't touched
that code since a while but if you post the code i can have a look.
	Albeu



More information about the MPlayer-dev-eng mailing list