Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[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 ...
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.
> > 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
Iknow this is rather a rare case, but if it appears, it's nice to have
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.
> > 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
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.
See RTL and Premiere for instance ! They all cast with 480x576 !
> 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 ...
To unsubscribe send a mail to firstname.lastname@example.org with "unsubscribe vdr" as subject.
Main Index |