Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vdr] Re: vdr2divx suggestions ? (poll)



On Wednesday 30 October 2002 21:54, you wrote:
> [...]
>
> > > 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 ...
>

Fore sure f.i. the frameno.avi and the stat-files have to be saved, and the 
status if a step is done, after doing it, but I agree , it is not that 
important for a first release.

> So, that's why i think the always beginning_with_a_clean_job is the
> cleanest and safest method -

For sure, before it breaks something, such a feature should not be added.

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

> > > - i would not like to break between
> > > pass1 and pass2 - sounds ugly to me :-), sorry !
>
sounds not that ugly, but seems too not important to me.

>
> > > 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 ...
>
You got me wrong. tosvcd is a extension like your vdr2divx and did what the 
name says. So this seems not to be so important for you right now. Like you 
said.



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

i have not did long term tests , didn't had such a case yet. There should be 
done a bugreport on mplayer with a exemple-file if anyone is able to do so.

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

Ok seems to me I have to test this a lot more. I've done a lot of encodings , 
from dvd, svcd,vcd and so on, have to take a look at vdr  files I guess

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

For sure, but the picture can't be in that format. At least it must be 4:3 and 
480:576 is  ... strange for mpeg4. Maybe the stream is in that format, they 
have added some black borders or stretched the picture or ..don't know. 
Will do a research on that topic till tomorow evening , Ok ? 

>
> > 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 !?

Don't have to be done, could be done if wished. 

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

The guesses are quite good. Try a mplayer -cropdetect on some sources, you 
will see you just have to trough the value in the -vop crop x:x:x:x parameter 
and allmost all is fine. For being on the save side, we have to know the 
macroblock size of lavc for cutting on macroblock edges. This should make 
encoding faster and the quality better. 2 episodes of tsrtrek should be 
around  one and a half hour I guess, and a bitrate of 900 should be no 
problem. If you try to store more than that on one CD as mentioned for lower 
priority or sharing in the net, you will run into problems without cropping 
and resizing, I guess. Will do some researches on that topic as I said, if 
you are interested.

> If you have an idea, how this can be automated - no manual control, then we
> can implement this ...

Tommorow will give you details on that.

Steffen


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



Home | Main Index | Thread Index