[MPlayer-dev-eng] [PATCH]: dvb_in module fixes
Nico
nsabbi at libero.it
Tue Apr 29 11:34:18 CEST 2003
Hi, Alban
tonight I'll look at the new code and give it a try.
The channels list is available (get_dvb_channels in dvbin.c) so it's
possible to push them in the playlist, but this way we are in the same
situation, right?
Thanks,
Nico
>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
>
>_______________________________________________
>MPlayer-dev-eng mailing list
>MPlayer-dev-eng at mplayerhq.hu
>http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
>
>
>
More information about the MPlayer-dev-eng
mailing list