[vdr] Re: vdr2divx suggestions ? (poll)

[Steffen Barszus <st_barszus@gmx.de>]

On Tuesday 29 October 2002 20:17, you wrote:
> Thanks for those many answers :-)
>
> So here are my thoughts summarizing a little bit:
>
> Yes, i want to use c++, because i'm just in the learning process of c++ and
> this project gives me the chance to relly learn c++ - sounds funny, but as
> i started vdr2divx project i had nearly no knowledge about bash scripting
> and now i know quite well. Since i'm just learning c++ (self study guide)
> this practical thing really helps me ... :-)
> The disadvantage of needing to recompile everything for changes and the
> more complex structure for people not knowing c++ ist there of course, but
> i think everyone able to change the "/usr/local/bin/mencoder Bla bal bla"
> line in a shell / perl script is able to change those syntax things in a c
> source aswell - and i guess those are the only things that change (mencoder
> option -a is now named -b ;-) Besides AFAIK there are alot of you out there
> using vdr and vdr2divx who have good c knowledge aswell ...
>
Agree with that. And I think c++ is a littlebit more powerful, so some 
features could be add easier later.

> The positive effect of c++ is that integrating vdr2divx as some kind of VDR
> plugin is easier than it would be with a script !???
>
Agree

> Now to the features:
> Yes i like the idea of "profiles" for conversion - this is really a feature
> i like to integrate - however the main concept behind vdr2divx was and
> still is the fully automated conversion - no user interaction !
> So there will be a default profile - for auto conversion and some other to
> chose for conversion!

Maybe configuring trough a conf file is the solution. with having a default 
conf file , nothing changed at the first look

> I must admit i never thought of the possibility to chose which cutted
> recording to convert and which not - since i convert all !
> I guess a solution that would fit my needs would be a "sub" menue in VDR
> that appears in VDR after pressing "2" for the cutting process. This menue
> should ask if this recording should be converted at all and if with which
> profile or which parameters ...

Sounds good.

> I do not like the "extra" menue, from vdr main menue, where i have to
> select all my cutted recordings each by each to convert - it should be
> integrated into the "2" dialog :-) I don't know if the VDR concept allows
> this extension ?

If you take the command you could define for after cutting and this is calling 
the plugin, this should be possible at least other svdrp, but I think there 
will be a cleaner solution.


> Klaus ? Maybe the plugin concept isn't that flexible (yet)
> !?
> Why this ? I often only find the time at the weekend to cut all my
> recordings from the week (up to 10 sometimes) an using an extra menue to
> mark all of them for conversation [;-)] is really annoying - i like the
> automatism - as said above i would like a new menue that would appear after
> pressing "2" - however i don't know if this can be implemented that easy!
>
Hope this is possible

> So, yes, i see a plugin for VDR, but this is just somekind of wrapper
> around my vdr2divx - maybe someone likes to participate in my project !? Or
> i will do later on my own - i just don't know !
> The first 2.0 version should be as the current bash version is - running
> from commandline processing files in the JobQ !

Yes , should not be made more complicated for having more features

> However i really like the idea of certain quality profiles to chose from
> via osd !
>
> Okay a progress bar or something would be nice - but it depends on the
> implementation of the whole thing (plugin / standalone) ...

Don't like a progressbar. Maybe calling the status over the plugins-osd would 
be enough. A statusbar over the whole time of converting would mean that you 
will look at it for several hours. No need for it in my opinion. Further 
converting don't have the same speed other the whole converting time. the 
first pass is a lot faster on my machine ( around 5 or 6 frames per second)

> Restarting conversion from a break is nice, but without this feature in
> mencoder, i think it's quite hard to do 

Maybe saving the status after pass one, pass two, and so on, so that once a 
step is be done it don't has to be done a second time.

> - i would not like to break between
> pass1 and pass2 - sounds ugly to me :-), sorry !
>
> Yes other formats like VCD/SVCD are possible, however i will first
> concentrate on mpeg4, since this is the format i prefer !

and tosvcd is available too ...

> AFAIK it's possible to create VCD content with mencoder aswell, so it
> should be possible to create a profile (see above) for VCD conversion !
> Maybe you got me wrong i'm not using ffmpeg itself, but it libavcodec,
> which is a part of mencoder (mpeg4 encoding)!
>

No it is not possible. In the mplayer package is a perlscript, which uses 
mplayer for the yuv conversion and recompressing it to mpeg1 or 2 using the 
mjpegtools. mencoder is not involved here. 

> Leading to the external programs:
> I guess using mencoder is quite allright - it always worked very good for
> me ! 

Yes and has no problems with .vdr files.

> PVAstruento with wine is a little ugly, but i'm not sure, if the
> author is willing to build a pure linux version - we had that discussion
> about a year ago - but we should try anyway!

I think no need for that, since mplayer/mencoder should not have problems with 
vdr files at all. And if there is a problem,  asking for fixing it in mplayer 
should be a lot faster than fixing it in pvastrumento. pvastrumento is only 
needed if you want to burn the mpeg2 as it is as video-dvd, and here 
shouldn't be the goal oft vdr2divx.

> Regarding ds.jar - has anyone tested this ? Does it repair broken streams
> really as good as PVAstruemnto ? AFAIK it cannot create PS - so an external
> muxer is needed !?

Java is needed for it, have not tested it, but don't like it and as written 
above is not needed at all.

> I don't think inventing such a "repair" util is trivial - i have used
> PVAstruemnto from it's very first versions (with windows) and it took quite
> some time since all errors that could appear in a stream could be fixed !
> However mencoder does repair streams itself - but sometimes some pictures
> get doubled or dropped where it's not necessary with PVAstrumento - and
> mencoder does "repair" streams depending on the PTS - so i guess there must
> be some more magic to it than this ;-)

mplayer does a great job on that. And for performance issues you need a lot of 
c and assembler knowledge IMHO.

> But these are no decisions regarding design of vdr2divx - changing this
> later on is not that hard, since they are all just calls of external
> programs...
>
> Finally one suggestion for resizing the output avi via profile was sent to
> me via PM - the main problem is that i tend to encoding interlaced
> (preserving quality) 

Don't know, but can the encoders do a good compression on interlaced files ? 
Don't think so. Resizing should be done depending on the quality-level. If 
you want to store 2 h on one cd you have to resize for getting high quality.

> - which forbids resizing - the other argument is that
> a fixed size - of e.g. 640xY probably means upscaling for certain
> recordings (480x576) 

wrong, since 480x576 isn't a resolution in which videos appear on dvb. At 
least there will be black borders to cut away, and don't know but maybe 
resizing to get correct AR is needed too.

> - so maybe just a 75% value for scaling down by this
> factor !??
> Don't get me wrong - Implementing scaling to fixed size is easy, but the
> quality won't be that good ....
>

Scaling should be done depending on the quality level. (e.g. full width on the 
highest level( maybe br=1000), 512xY at the medium (br=800), 320xY (br=600)  
on the lowest level or something like that)

> Now throw stones at me,
>
> Martin ;-)
>

Don't know how it is handled now, but cropping could be done with cropdetect, 
and displayed for control other a switch of mplayer (-rectangle ... , have to 
look in the manual) and we have to make sure to cut on the borders of 
macroblocks (depends on the codec, don't know the sizes of macroblocks of 
lavc) and to have no black borders in the resultin video frame, to preserve 
the quality and speed. 


Greets

Steffen


--
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe vdr" as subject.