[vdr] Re: vdr2divx suggestions ? (poll)

["Rene Bartsch" <vdr@bartschnet.de>]

----- Original Message -----
From: "Martin Hoffmann" <ma.hoff@t-online.de>
To: <vdr@linuxtv.org>
Sent: Wednesday, October 30, 2002 9:54 PM
Subject: [vdr] Re: vdr2divx suggestions ? (poll)


> [...]
> > > 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 ...
>

With mencoder, you have to start the 2 or 3 passes by own command-lines. So
you could simply copy the conversion-directory to a backup-directory after
every pass.

> 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

You don't need a JVM. Instead of interpreter you can also compile Java with
gcc.

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

MPlayer hat the cropdetect-function. Cropdetect checks the video for
vertical or horizontal black bands and outputs their coordinates to stdout.
But you should do this at several positions in the video and compare the
values in case advertisement with other values is in the recording.

Rene



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