Hallo
> >> actually flip the scanlines to fix it. There are tools which do this;
> >> for example, "y4mscaler -S mode=lineswitch".
> >And yuvcorrect.
>
> yuvcorrect needs a manpage.
And so do: y4mspatialfilter, y4mshift.
But y4mshift is not that hard to understand.
auf hoffentlich bald,
>> Debugging the temporal order (addressed in the MJPEG Howto):
>Do you mean that I should write a better decription there. Or is it
>enougth ?
I'll have to take a better look. I remember that section of the
"MJPEG Howto" being kind of MJPEG-centric, mixing together some
phenomena and missi
Hallo
> >I used the utilities from mjpegtools (whose names elude me at present) in
> >pretty much the same way as described in the mjpeg howto. In short, the
> >mjpegtools output the fields as individual pnm files which were loaded into
> >xv for viewing.
>
> Yep --- that'll work.
>
> Remem
>> Is there a way of telling how a DVD has been encoded in terms of field
>> order?
>
> For that I use a program called "dvdview" against the decrypted
> .vob file. At log level 3 (-v 3) you get info like this:
...
>PictureHeader:
...
> top field first: false
...
> r
>> Check cinelerra --- see what it says about your video's field order. (If
>> it doesn't say anything, then you *know* it is broken.) The source DVD
>> is not necessarily bottom-field first (or even top-field first); if not,
>> cinelerra needs to account for that when it produces a DV fi
On Tue, 11 May 2004, Jonathan Woithe wrote:
> Correct. mpeg2enc claimed the input was bottom-first so I used the -z flag
> to override this. I was not aware (until you mentioned it) that DV is
> exclusively bottom first, but that at least means the "bottom first" input
Oh, I thought e
> >I think I've at least partially solved this problem. Over the weekend I
> >tried encoding with the the "-z t" mpeg2enc option and the result was
> >noticeably better when played back on the hardware player. ...
>
> By default, mpeg2enc gets the field order from the header of the input
> st
>I think I've at least partially solved this problem. Over the weekend I
>tried encoding with the the "-z t" mpeg2enc option and the result was
>noticeably better when played back on the hardware player. mpeg2enc claimed
>the frame order of the incoming stream was bottom first, so the above
Jonathan Woithe wrote:
>
> Hi all
>
> > I've been running some more tests using mjpegtools 1.6.2 and have a couple
> > of questions regarding some odd effects I've seen when the result was played
> > on a PAL DVD player. ...
> > :
> > Another thing I noticed about this DVD is that motion is somet
Hi all
> I've been running some more tests using mjpegtools 1.6.2 and have a couple
> of questions regarding some odd effects I've seen when the result was played
> on a PAL DVD player. ...
> :
> Another thing I noticed about this DVD is that motion is sometimes
> noticeably jerky on hardware play
10 matches
Mail list logo