[vdr] Re: vdr2divx suggestions ? (poll)

[ma.hoff@t-online.de (Martin Hoffmann)]

[...]
> > 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 cannot promise this, since it's not that easy to implement, since vdr2divx 
should "know" then is the first pass was really successfully ended (think of 
powefailure / crash / reset or something) unless it's second pass can really 
rely on the files there ! On the other hand vdr2divx should be sure that the 
relicts of the first pass really belong to this second pass :-)
So, you see there is some logistics to be done ...

So, that's why i think the always beginning_with_a_clean_job is the cleanest 
and safest method - even if this means that a reboot / crash or whatever 
sometimes means 1 or 2 hours of encoding to be done again !
However, i'll keep this feature in mind, but will surely not implement this in 
the first versions !

> > - i would not like to break between
> > pass1 and pass2 - sounds ugly to me :-), sorry !
see above !

> >
> > 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 ...
I havent looked into these things yet, so first version will most likely not 
feature these ...

> > 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.
see above

> > 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.
I don't agree in that point, i had certain recordings, where you could see a 
small glitch in picture in VDR, and mencoder tended to skip/duplicate several 
frames leading to a slowdown and jumping picture at this point - however 
PVAstrumento fixed this 100% (i don't know how) - so no picture was 
doubled/dropped and the scene was better than seeing the pure recording in 
VDR :-) 
Iknow this is rather a rare case, but if it appears, it's nice to have 
PVAstruemnto !
That's why i invented a repair_only mode for PVAstrumento in vdr2divx1.6.0pre2 
(the never released one ;-) where i first do a quick "encode test" (no video, 
and audio only copy) to analyze the source stream - if mencoder shows 
problems - skip/duplicate frames, where no cutting marks where found, then 
PVAstrumento is invoked ! 
However the output avi is cleaner (especially where cutting makrs are) when 
PVAstrumento is used always !!! 

> > 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.
see above

> > 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.
Agree

> > 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.
The quality is quite impressive, i use 2 Episodes of StarTrek on 1 CD-R80 
interlaced 480x576 at around 900kbit/s video rate ! And it gives me really 
nice quality with lavc ! Nearly no artefacts can be seen ! And interlacing 
gives me more smooth movements !

> > - 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.
Huh ?
See RTL and Premiere for instance ! They all cast with 480x576 !

> 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.
"displayed for control" is something that really breaks my fully automated 
conversion concept, you see !?
Thats a problem, since i want it all fully automated - vdr2divx should know 
(or guess) how to convert, if he cannot its not my concept ...
If you have an idea, how this can be automated - no manual control, then we 
can implement this ...

Martin



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