Roman Shaposhnik schrieb:
>> Yes, I do refer to massive quality-loss I have observed in such an
>> "encoder-stress-test". I can, if you wish, do this test again.
>>
>
> That'll be *very* much appreciated (if not the tests themselves,
> then just a complete recipe for reproducing your result
I am amazed. After 10 times DV re-encoding with ffmpeg, the file at a
first glance looks like it was unaltered. WOW. I hardly believe that the
Canopus DV-Codec can be that much better (*if* it is...). I will see
that tomorow...
cu
Stefan
On Fri, Nov 24, 2006 at 11:08:20AM +0100, Linetec wrote:
> ...
> > > Example of the render pipe command:
> > > yuvcorrect -v 0 -T INTERLACED_BOTTOM_FIRST | mpeg2enc -M 2 -v 0 -r 32 -4
> > > 1 -2 1 -D 10 -g 15 -G 15 -q 5 -b 9600 -f 8 -o %
> >
> > For one thing you could speed up the coding by d
BTW, here's what's written in the Cinelerra CV manual about exporting to
mpeg2 using mpeg2enc:
http://cvs.cinelerra.org/docs/split_manual/cinelerra_cv_manual_19.html#SEC257
Any comment appreciated. ;-)
Nicolas.
--
~~
~ BOYCOTT SUSE & NOVELL (C)(TM)(R
Hello list!
I'm pondering a little thingy, a video sequence recognizer. I've thought about
looking for variations in luminance and/or chrominance in the image, but come
to the conclusion that my TV providers, at least, have none or very little
consistency in their settings when broadcasting the
On Sun, 26 Nov 2006, Nicolas Maufrais wrote:
> BTW, here's what's written in the Cinelerra CV manual about exporting to
> mpeg2 using mpeg2enc:
>
> http://cvs.cinelerra.org/docs/split_manual/cinelerra_cv_manual_19.html#SEC257
>
> Any comment appreciated. ;-)
Looks OK. I would alter th
On Sun, 26 Nov 2006 19:41:35 +0100
stefan <[EMAIL PROTECTED]> wrote:
> I am amazed. After 10 times DV re-encoding with ffmpeg, the file at a
> first glance looks like it was unaltered. WOW.
Looks like this is going to make all parties happy. Good. :)
/Sam
--
On Sun, Nov 26, 2006 at 11:40:13AM -0800, Steven M. Schultz wrote:
>
> On Sun, 26 Nov 2006, Nicolas Maufrais wrote:
>
> > BTW, here's what's written in the Cinelerra CV manual about exporting to
> > mpeg2 using mpeg2enc:
> >
> > http://cvs.cinelerra.org/docs/split_manual/cinelerra_cv_manual_19.h
Op zo, 26-11-2006 te 20:01 +0100, schreef Nicolas:
> On Fri, Nov 24, 2006 at 11:08:20AM +0100, Linetec wrote:
> > ...
> > > > Example of the render pipe command:
> > > > yuvcorrect -v 0 -T INTERLACED_BOTTOM_FIRST | mpeg2enc -M 2 -v 0 -r 32 -4
> > > > 1 -2 1 -D 10 -g 15 -G 15 -q 5 -b 9600 -f 8 -o %
Hi Roman
> > The very noticeable degradation comes about due to a bug in libdv which is
> > used to do the encoding to DV from cinelerra. When I last looked into this
> > about 2 years ago ffmpeg's DV codec wasn't as badly affected but it still
> > wasn't great. AFAIK libdv is in deep maintenanc
> PS: if you want to have the best video-quality you can get out of
> cinelerra then export your projekt to a y4m-stream and a wav-stream
> seperately and encode this with mpeg2enc and mp2enc (or if ac3 needed
> with ffmpeg...).
This is essentially what my revised workflow has been since early
Roman
> > > The very noticeable degradation comes about due to a bug in libdv which is
> > > used to do the encoding to DV from cinelerra. When I last looked into
> > > this
> > > about 2 years ago ffmpeg's DV codec wasn't as badly affected but it still
> > > wasn't great.
> > hmm, great? Great
> There is the possibility that the field order was set incorrectly
> by Cinelerra (it's happened in the past as I recall) and that you
> were correcting it after the rendering.
I have had some cases where the y4m stream coming out of cinelerra either
specifies the wrong field or
13 matches
Mail list logo
