On Tuesday 29 August 2006 20:52, Cyrus A wrote:
> Hans Verkuil wrote:
> > On Tuesday 29 August 2006 19:46, Cyrus A wrote:
> >> Hans Verkuil wrote:
> >>> On Sunday 27 August 2006 03:38, Cyrus A wrote:
> >>>> Here is my experience trying to encode into MPEG-4 on the fly
> >>>> while also recording closed captions on a PVR-250.
> >>>>
> >>>> First I tried 'cat /dev/video0 > outputfile.mpg' to get the
> >>>> hardware MPEG-2. That worked perfectly.
> >>>>
> >>>> Then I had some trouble encoding on the fly with ffmpeg. The
> >>>> audio was out of sync for some unknown reason. After a couple of
> >>>> days, I found that '-async 1' solved my problem. My ffmpeg
> >>>> command is ' ffmpeg -i /dev/video0 -async 1 -s 480x384 -b 1750
> >>>> outfile.mpg' I have thoroughly tested it and it works well for
> >>>> long periods of time (recording an hourlong show, for instance).
> >>>> Now onto closed captioning.
> >>>>
> >>>> zvbi-ntsc-cc doesn't work. I think the program "drives" the
> >>>> video device at the same time the drivers are trying to "drive"
> >>>> the device and it causes conflicts. This results in choppy,
> >>>> unusable video. The same thing happened with bttv.
> >>>>
> >>>> Then I tried the $ivtvhome/test/vbi program and VIOLA, I got the
> >>>> captions I needed and the video was unaffected.... or so I
> >>>> thought...
> >>>>
> >>>> After a short period, errors start showing up in the video
> >>>> encoding terminal:
> >>>>
> >>>> [mpeg2video @ 0x2aaaab031030]00 motion_type at 12
> >>>> 5=2091.2kbits/s [mpeg2video @ 0x2aaaab031030]Warning MVs not
> >>>> available
> >>>> [mpeg2video @ 0x2aaaab031030]concealing 1125 DC, 1125 AC, 1125
> >>>> MV errors [mpeg2video @ 0x2aaaab031030]00 motion_type at 33
> >>>> 11=2077.1kbits/s [mpeg2video @ 0x2aaaab031030]mb incr damaged
> >>>> [mpeg2video @ 0x2aaaab031030]mb incr damaged
> >>>> [mpeg2video @ 0x2aaaab031030]mb incr damaged
> >>>> [mpeg2video @ 0x2aaaab031030]mb incr damaged
> >>>> [mpeg2video @ 0x2aaaab031030]slice mismatch
> >>>> [mpeg2video @ 0x2aaaab031030]slice mismatch
> >>>> [mpeg2video @ 0x2aaaab031030]slice mismatch
> >>>> [mpeg2video @ 0x2aaaab031030]slice mismatch
> >>>> [mpeg2video @ 0x2aaaab031030]00 motion_type at 0 20
> >>>> [mpeg2video @ 0x2aaaab031030]invalid cbp at 11 21
> >>>> [mpeg2video @ 0x2aaaab031030]00 motion_type at 0 22
> >>>> [mpeg2video @ 0x2aaaab031030]mb incr damaged
> >>>> [mpeg2video @ 0x2aaaab031030]00 motion_type at 0 24
> >>>> [mpeg2video @ 0x2aaaab031030]slice mismatch
> >>>> [mpeg2video @ 0x2aaaab031030]mb incr damaged
> >>>> [mpeg2video @ 0x2aaaab031030]00 motion_type at 1 27
> >>>> [mpeg2video @ 0x2aaaab031030]00 motion_type at 0 28
> >>>> [mpeg2video @ 0x2aaaab031030]00 motion_type at 0 29
> >>>> [mpeg2video @ 0x2aaaab031030]concealing 855 DC, 855 AC, 855 MV
> >>>> errors [mpeg2video @ 0x2aaaab031030]00 motion_type at 19
> >>>> 22=2087.8kbits/s [mpeg2video @ 0x2aaaab031030]invalid mb type in
> >>>> B Frame at 13 23 [mpeg2video @ 0x2aaaab031030]mb incr damaged
> >>>> [mpeg2video @ 0x2aaaab031030]00 motion_type at 7 25
> >>>> [mpeg2video @ 0x2aaaab031030]00 motion_type at 3 26
> >>>> [mpeg2video @ 0x2aaaab031030]00 motion_type at 1 27
> >>>> [mpeg2video @ 0x2aaaab031030]00 motion_type at 1 28
> >>>> [mpeg2video @ 0x2aaaab031030]00 motion_type at 4 29
> >>>> [mpeg2video @ 0x2aaaab031030]Warning MVs not available
> >>>> [mpeg2video @ 0x2aaaab031030]concealing 360 DC, 360 AC, 360 MV
> >>>> errors [mpeg2video @ 0x2aaaab031030]00 motion_type at 1
> >>>> 12e=2086.9kbits/s [mpeg2video @ 0x2aaaab031030]00 motion_type at
> >>>> 1 13
> >>>> [mpeg2video @ 0x2aaaab031030]slice mismatch
> >>>> [mpeg2video @ 0x2aaaab031030]00 motion_type at 6 15
> >>>> [mpeg2video @ 0x2aaaab031030]00 motion_type at 1 16
> >>>> [mpeg2video @ 0x2aaaab031030]00 motion_type at 13 17
> >>>> [mpeg2video @ 0x2aaaab031030]ac-tex damaged at 1 18
> >>>> [mpeg2video @ 0x2aaaab031030]invalid mb type in B Frame at 34 19
> >>>> [mpeg2video @ 0x2aaaab031030]invalid cbp at 8 20
> >>>> [mpeg2video @ 0x2aaaab031030]slice mismatch
> >>>> [mpeg2video @ 0x2aaaab031030]00 motion_type at 3 22
> >>>> [mpeg2video @ 0x2aaaab031030]00 motion_type at 27 23
> >>>> [mpeg2video @ 0x2aaaab031030]00 motion_type at 16 24
> >>>> [mpeg2video @ 0x2aaaab031030]mb incr damaged
> >>>> [mpeg2video @ 0x2aaaab031030]00 motion_type at 28 26
> >>>> [mpeg2video @ 0x2aaaab031030]ac-tex damaged at 4 27
> >>>> [mpeg2video @ 0x2aaaab031030]invalid mb type in B Frame at 3 28
> >>>> [mpeg2video @ 0x2aaaab031030]mb incr damaged
> >>>> [mpeg2video @ 0x2aaaab031030]Warning MVs not available
> >>>> [mpeg2video @ 0x2aaaab031030]concealing 810 DC, 810 AC, 810 MV
> >>>> errors
> >>>>
> >>>> Normally I would just ignore the errors, but they corresponded
> >>>> with an audio desyncing from the video. The more errors
> >>>> appeared, the more the audio became de-synced from the video.
> >>>>
> >>>> If anyone can provide any insight, it would be greatly
> >>>> appreciated.
> >>>
> >>> Are you embedding the VBI data into the stream (using the ivtvctl
> >>> -x1 option) or just reading the VBI data as a separate stream
> >>> with the vbi tool?
> >>>
> >>> Please also give the INIT IVTV messages from the kernel log. Also
> >>> check the log for any other errors that it may have printed
> >>> during capturing.
> >>>
> >>> What command(s) do you use to get these results?
> >>>
> >>> Hans
> >>>
> >>> _______________________________________________
> >>> ivtv-users mailing list
> >>> [email protected]
> >>> http://ivtvdriver.org/mailman/listinfo/ivtv-users
> >>
> >> Here are my commands. In the first terminal window I used:
> >>
> >> ffmpeg -i /dev/video0 -async 1 -s 480x384 -b 1750 outfile.mpg
> >>
> >> and in the second:
> >>
> >> /usr/local/ivtv-0.7.0/test/vbi
> >>
> >> I have not attempted anything with ivtvctl. Should I?
> >>
> >> Dmesg had an interesting message:
> >>
> >> ivtv0 warning: Starting VBI after starting an encoding, seems to
> >> not work.
> >>
> >> However, starting vbi before the ffmpeg process didn't work
> >> either. But, the errors seemed different (at least to my untrained
> >> eye). What do you make of this?
> >
> > What happens if you don't do life transcoding but first record it
> > and at the same time capture the VBI, and do the ffmpeg transcoding
> > when the recording is finished? Do you still get the errors?
> >
> > I've recently discovered that when the hardware is under heavy load
> > all sorts of things may go wrong. I'm working on improving the
> > driver to be better and faster at handling DMA in an attempt to
> > minimize this from happening.
> >
> > Regards,
> >
> > Hans
> >
> > _______________________________________________
> > ivtv-users mailing list
> > [email protected]
> > http://ivtvdriver.org/mailman/listinfo/ivtv-users
>
> Using 'cat /dev/video0 > outfile.mpg', the audio and video did not
> desync as before. However, when I would start up the closed
> captioning (via the test/vbi script) I did notice the video would
> momentarily go nuts (random blocks of green and pink, etc) just as
> before. The video was mostly ok (and stayed in sync), but does have
> "blips" of encoding strangeness. When I stop the test/vbi program,
> the video is much more stable. dmesg had no additional information.
>
> I would shy away from assuming the audio desyncing with ffmpeg is a
> load problem. My computer has plenty of CPU and RAM to go around. I
> don't know anything about ivtv, but I know ffmpeg is very efficient.
> I've recorded 4 channels simultaneously with 4 bttv cards with ffmpeg
> (while also running voice recognition in the background).
>
> My guess would be that there is some sort of device sharing conflict
> between the video driver on the card and the test/vbi script. This
> conflict seems to cause the "blips" which screw up the video, which
> in turn mess up ffmpeg. It's not until ffmpeg is run on the output
> file (catted from /dev/video0) that the desyncing occurs.
>
> Here's the real kicker: After using cat /dev/video0 to get an MPEG-2
> file and running test/vbi off and on to generate some "blips" during
> the recording, I then tried to convert the resulting output file to
> MPEG-4 with ffmpeg. Lo and behold... the audio desync'd. This lends
> creedence to the idea that the encoding goofs resulting from the use
> of test/vbi cause ffmpeg to desync the audio, regardless if it's
> on-the-fly from /dev/video0 or simply used on a corrupted video file.
> I don't think that the load on the system is the problem.
>
> What do you suggest?
Wait. I think I know what is going on, and it has all to do with the way
DMA is handled by the card and the driver. However, before I can really
work on that I first need to refactor a big part of the driver that
currently makes it very difficult to actually debug and fix this stuff.
What makes this so frustrating is that a large part of these problems
seem to depend on the hardware and possibly software used. If you are
using any kind of CPU frequency changer tool I'd certainly suggest
disabling it. It looks like it's quite hard on DMA.
Anyway, in about two weeks time from now I hope to have a much better
idea on how to go forward. For now I'll just continue refactoring
several years worth of sometimes quite ugly code.
Hans
_______________________________________________
ivtv-users mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-users
