Mailing List Archive

On Sun, 2009-09-20 at 00:41 +0200, Martin Dauskardt wrote:
> I finally I found a solution for my vdr pvr350-plugin to play DVB radio
> streams which have only audio, no video.
>
> For these streams I send a black video of 40ms lenght (1 frame) about every
> two audio frames (one audio frame = 24ms).
>
> vdr calls repeatedly this code:
>
> len = WriteAllOrNothing(fd_out, Data, Length, 1000, 10);
> if (len <= 0) {
> log(pvrERROR, "pvr350: PlayAudio(MP2 Audio only) written=%d error=%d:%s",
> len, errno, strerror(errno));
> }
> else {
> count += 24;
> }
> if (count >=40) {
> len = WriteAllOrNothing(fd_out, BlankScreen, sizeof(BlankScreen), 1000, 10);
> if (len <= 0) {
> log(pvrERROR, "pvr350: PlayAudio(Blackframe) written=%d error=%d:%s",
> len, errno, strerror(errno));
> }
> else {
> count -= 40;
> }
> }
>
> When I replay audio-only recordings and use fast foward/rewind (using
> different speeds) I get a lot of errors after returning to normal speed:
> pvr350: 21:26:41 pvr350: PlayAudio(MP2 Audio only) written=-1
> error=11:Resource temporarily unavailable
> pvr350: 21:26:41 pvr350: PlayAudio(MP2 Audio only) written=-1
> error=11:Resource temporarily unavailable
> pvr350: 21:26:41 pvr350: PlayAudio(MP2 Audio only) written=-1
> error=11:Resource temporarily unavailable
>
> WriteAllOrNothing trys repeatedly to write the data, and the result is endless
> EAGAIN. I never saw this with normal audio/video streams.
>
> The applications clears the decoder before returning to normal speed. This is
> done by a decoder stop/start. After this, VIDEO_CMD_PLAY with speed 1000 is
> called. This is the way it works fine with video/audio streams.
>
> The above mentioned EAGAIN errors do not happen, when I additionally call
> VIDEO_CMD_FREEZE, immidiately followed by a VIDEO_CMD_CONTINUE.
>
> Example: The order is
>
> -trickmode (speed != 1000)
>
> Function Clear:
> -VIDEO_CMD_STOP with flag VIDEO_CMD_STOP_IMMEDIATELY
> -VIDEO_CMD_PLAY (setting no speed)
>
> additional (Voodoo ?):
> -VIDEO_CMD_FREEZE
> -VIDEO_CMD_CONTINUE
>
> Fuction Play() (Resume with normal speed):
> -VIDEO_CMD_PLAY with speed 1000
> This is the point where the write EGAIN errors would appear if do not call
> the "Voodoo" ioctls before
>
> I have no explanation why only these two ioctl help to
> avoid the EAGAIN errors. (I tried delays with different usleep values without
> success)
>
> These streams have much less data, so it takes longer to fill the internal
> buffers. Maybe a point?

Maybe, I don't know.

I imagine that it could be the case that the Decoder firmware may not
gracefully handle very unusual streams, such as the one you are
creating. However a driver bug could also be to blame.

VIDEO_CMD_PLAY and VIDEO_CMD_CONTINUE both perform some sort of
operation that may (or may not) adjust the speed. For sure
VIDEO_CMD_CONTINUE will not manipulate the speed unless the decoder was
previously paused.

I'll have to look into this more. If you turn on the info and mailbox
flags with the debug module option to ivtv, then speed settings and
commands to the decoder will get logged. You can see the difference in
what is happening in the ioctl() command sequences you mention above.


> There is only one place in ivtv_v4l2_write where EAGAIN can be returned:
> if (filp->f_flags & O_NONBLOCK)
> return -EAGAIN;
>
> I open the /dev/video16 with O_WRONLY | O_NONBLOCK

When most people open with O_NONBLOCK, they call select() on the file
descriptor, to wait until it is ready and avoid EAGAIN. If you are not
already, maybe you should call select() to wait until the fd is
writable. If given a very long timeout, select() times out , then the
problem may be that the Decoder is stopped for some unknown reason.



> Now I see that mythtv is doing it differently:
> videofd = open(viddev.constData(), O_WRONLY | O_NONBLOCK, 0555);
>
> What does the 0555 mean ?

That's a file creation mode of r-xr-xr-x, which will then be modified by
the user's umask when O_CREAT is specified as a flag to the open() call.
Of course the file creation mode mask is ignored by open() when O_CREAT
is not present.

Regards,
Andy

> Greets,
> Martin



_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On 9/20/09, Andy Walls <awalls@radix.net> wrote:
> On Sun, 2009-09-20 at 00:41 +0200, Martin Dauskardt wrote:
>> I finally I found a solution for my vdr pvr350-plugin to play DVB radio
>> streams which have only audio, no video.
>>
>> For these streams I send a black video of 40ms lenght (1 frame) about
>> every
>> two audio frames (one audio frame = 24ms).
>>
>> vdr calls repeatedly this code:
>>
>> len = WriteAllOrNothing(fd_out, Data, Length, 1000, 10);
>> if (len <= 0) {
>> log(pvrERROR, "pvr350: PlayAudio(MP2 Audio only) written=%d error=%d:%s",
>> len, errno, strerror(errno));
>> }
>> else {
>> count += 24;
>> }
>> if (count >=40) {
>> len = WriteAllOrNothing(fd_out, BlankScreen, sizeof(BlankScreen), 1000,
>> 10);
>> if (len <= 0) {
>> log(pvrERROR, "pvr350: PlayAudio(Blackframe) written=%d error=%d:%s",
>> len, errno, strerror(errno));
>> }
>> else {
>> count -= 40;
>> }
>> }
>>
>> When I replay audio-only recordings and use fast foward/rewind (using
>> different speeds) I get a lot of errors after returning to normal speed:
>> pvr350: 21:26:41 pvr350: PlayAudio(MP2 Audio only) written=-1
>> error=11:Resource temporarily unavailable
>> pvr350: 21:26:41 pvr350: PlayAudio(MP2 Audio only) written=-1
>> error=11:Resource temporarily unavailable
>> pvr350: 21:26:41 pvr350: PlayAudio(MP2 Audio only) written=-1
>> error=11:Resource temporarily unavailable
>>
>> WriteAllOrNothing trys repeatedly to write the data, and the result is
>> endless
>> EAGAIN. I never saw this with normal audio/video streams.
>>
>> The applications clears the decoder before returning to normal speed. This
>> is
>> done by a decoder stop/start. After this, VIDEO_CMD_PLAY with speed 1000
>> is
>> called. This is the way it works fine with video/audio streams.
>>
>> The above mentioned EAGAIN errors do not happen, when I additionally call
>> VIDEO_CMD_FREEZE, immidiately followed by a VIDEO_CMD_CONTINUE.
>>
>> Example: The order is
>>
>> -trickmode (speed != 1000)
>>
>> Function Clear:
>> -VIDEO_CMD_STOP with flag VIDEO_CMD_STOP_IMMEDIATELY
>> -VIDEO_CMD_PLAY (setting no speed)
>>
>> additional (Voodoo ?):
>> -VIDEO_CMD_FREEZE
>> -VIDEO_CMD_CONTINUE
>>
>> Fuction Play() (Resume with normal speed):
>> -VIDEO_CMD_PLAY with speed 1000
>> This is the point where the write EGAIN errors would appear if do not call
>>
>> the "Voodoo" ioctls before
>>
>> I have no explanation why only these two ioctl help to
>> avoid the EAGAIN errors. (I tried delays with different usleep values
>> without
>> success)
>>
>> These streams have much less data, so it takes longer to fill the internal
>>
>> buffers. Maybe a point?
>
> Maybe, I don't know.
>
> I imagine that it could be the case that the Decoder firmware may not
> gracefully handle very unusual streams, such as the one you are
> creating. However a driver bug could also be to blame.
>
> VIDEO_CMD_PLAY and VIDEO_CMD_CONTINUE both perform some sort of
> operation that may (or may not) adjust the speed. For sure
> VIDEO_CMD_CONTINUE will not manipulate the speed unless the decoder was
> previously paused.
>
> I'll have to look into this more. If you turn on the info and mailbox
> flags with the debug module option to ivtv, then speed settings and
> commands to the decoder will get logged. You can see the difference in
> what is happening in the ioctl() command sequences you mention above.
>
>
>> There is only one place in ivtv_v4l2_write where EAGAIN can be returned:
>> if (filp->f_flags & O_NONBLOCK)
>> return -EAGAIN;
>>
>> I open the /dev/video16 with O_WRONLY | O_NONBLOCK
>
> When most people open with O_NONBLOCK, they call select() on the file
> descriptor, to wait until it is ready and avoid EAGAIN. If you are not
> already, maybe you should call select() to wait until the fd is
> writable. If given a very long timeout, select() times out , then the
> problem may be that the Decoder is stopped for some unknown reason.
>
>
>
>> Now I see that mythtv is doing it differently:
>> videofd = open(viddev.constData(), O_WRONLY | O_NONBLOCK, 0555);
>>
>> What does the 0555 mean ?
>
> That's a file creation mode of r-xr-xr-x, which will then be modified by
> the user's umask when O_CREAT is specified as a flag to the open() call.
> Of course the file creation mode mask is ignored by open() when O_CREAT
> is not present.
>
> Regards,
> Andy
>
>> Greets,
>> Martin
>
>
>
> _______________________________________________
> ivtv-devel mailing list
> ivtv-devel@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
>


--
Tony (echo 'spend!,pocket awide' | sed 'y/acdeikospntw!, /l@omcgtjuba.phi/')

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Hi Andy,

>
> I'll have to look into this more. If you turn on the info and mailbox
> flags with the debug module option to ivtv, then speed settings and
> commands to the decoder will get logged. You can see the difference in
> what is happening in the ioctl() command sequences you mention above.

I never really understand this bitmask stuff
parm: debug:Debug level (bitmask). Default: 0
1/0x0001: warning
2/0x0002: info
4/0x0004: mailbox
8/0x0008: ioctl
16/0x0010: file
32/0x0020: dma
64/0x0040: irq
128/0x0080: decoder
256/0x0100: yuv
512/0x0200: i2c
1024/0x0400: high volume

What value do I need to activate both info and mailbox? Can I simply add 1 +
4, and use "modprobe ivtv debug= 5 " ?

What would be the value for info,mailbox, ioctl and decoder?
>
>
> > There is only one place in ivtv_v4l2_write where EAGAIN can be returned:
> > if (filp->f_flags & O_NONBLOCK)
> > return -EAGAIN;
> >
> > I open the /dev/video16 with O_WRONLY | O_NONBLOCK
>
> When most people open with O_NONBLOCK, they call select() on the file
> descriptor, to wait until it is ready and avoid EAGAIN. If you are not
> already, maybe you should call select() to wait until the fd is
> writable. If given a very long timeout, select() times out , then the
> problem may be that the Decoder is stopped for some unknown reason.

The /dev/video16 is opened only once at plugin start and keeps open during
runtime.

I should note that vdr is frequently calling VIDEO_GET_PTS during trickmode
playback.

Greets,
Martin

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Sun, 2009-09-20 at 20:50 +0200, Martin Dauskardt wrote:
> Hi Andy,
>
> >
> > I'll have to look into this more. If you turn on the info and mailbox
> > flags with the debug module option to ivtv, then speed settings and
> > commands to the decoder will get logged. You can see the difference in
> > what is happening in the ioctl() command sequences you mention above.
>
> I never really understand this bitmask stuff
> parm: debug:Debug level (bitmask). Default: 0
> 1/0x0001: warning
> 2/0x0002: info
> 4/0x0004: mailbox
> 8/0x0008: ioctl
> 16/0x0010: file
> 32/0x0020: dma
> 64/0x0040: irq
> 128/0x0080: decoder
> 256/0x0100: yuv
> 512/0x0200: i2c
> 1024/0x0400: high volume
>
> What value do I need to activate both info and mailbox? Can I simply add 1 +
> 4, and use "modprobe ivtv debug= 5 " ?

Martin,

Yes that is almost correct. Info => 2 and Mailbox => 4 so you would use
2 + 4 = 6

# modprobe ivtv debug=6

Also logging debug warnings usually doesn't hurt, so maybe you would
want to use debug=7.

> What would be the value for info,mailbox, ioctl and decoder?

2+4+8+128 = 142

# modprobe debug=142


Perhaps that will provide more insight. I won't have time to look into
any of this deeply until after I get back from the LPC this week.

> >
> > > There is only one place in ivtv_v4l2_write where EAGAIN can be returned:
> > > if (filp->f_flags & O_NONBLOCK)
> > > return -EAGAIN;
> > >
> > > I open the /dev/video16 with O_WRONLY | O_NONBLOCK
> >
> > When most people open with O_NONBLOCK, they call select() on the file
> > descriptor, to wait until it is ready and avoid EAGAIN. If you are not
> > already, maybe you should call select() to wait until the fd is
> > writable. If given a very long timeout, select() times out , then the
> > problem may be that the Decoder is stopped for some unknown reason.
>
> The /dev/video16 is opened only once at plugin start and keeps open during
> runtime.

A device node being open for a long time doesn't mean the driver is
always ready to accept more data for writing.

As you hypothesized earlier, if the decoder hardware and firmware "owns"
all the buffers at a moment in time, there is no buffer into which an
application can write data. If you try an write(), when the driver is
not ready to accept write() data, the application will either block in
the write() call or, if you have O_NONBLOCK set on the fd, the write()
call will return immediately with an errno of EAGAIN.

Regards,
Andy

> I should note that vdr is frequently calling VIDEO_GET_PTS during trickmode
> playback.
>
> Greets,
> Martin
>
> _______________________________________________
> ivtv-devel mailing list
> ivtv-devel@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
>


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Hi Andy,

the problem is solved since I improved the dummy black video frames. Now they
have the PTS from the audio packets. It is no longer necessary to
freeze/continue the decoder before resuming to normal speed.

Nevertheless, it may be interesting to see what went wrong here. This is the
log with debug=142 (using the old dummy black video frames)

Greets,
Martin

Sep 21 13:46:39 ubuntuvdr vdr: [4300] dvbplayer thread started (pid=4287,
tid=4300)
Sep 21 13:46:39 ubuntuvdr vdr: [4300] resuming replay at index 9205
(0:22:05.05)
Sep 21 13:46:39 ubuntuvdr vdr: [4301] non blocking file reader thread started
(pid=4287, tid=4301)
Sep 21 13:46:39 ubuntuvdr vdr: [4300] cPvr350Device::SetAudioChannelDevice
(stereo)
Sep 21 13:46:39 ubuntuvdr vdr: [4300] cPvr350Device::SetAudioChannelDevice
(stereo)
Sep 21 13:46:39 ubuntuvdr vdr: [4300] cPvr350Device::Set_wss_mode()
Sep 21 13:46:39 ubuntuvdr vdr: [4300] pvr350: Set wss mode 4:3
Sep 21 13:46:39 ubuntuvdr vdr: [4300] cPvr350Device::detected Audio-only
stream
Sep 21 13:46:39 ubuntuvdr kernel: [13799.097956] ivtv0 ioctl:
AUDIO_CHANNEL_SELECT
Sep 21 13:46:39 ubuntuvdr kernel: [13799.097965] ivtv0 mb: MB Call:
CX2341X_DEC_SET_AUDIO_MODE
Sep 21 13:46:39 ubuntuvdr kernel: [13799.097972] ivtv0 ioctl:
AUDIO_BILINGUAL_CHANNEL_SELECT
Sep 21 13:46:39 ubuntuvdr kernel: [13799.097976] ivtv0 mb: MB Call:
CX2341X_DEC_SET_AUDIO_MODE
Sep 21 13:46:39 ubuntuvdr kernel: [13799.098089] ivtv0 ioctl:
AUDIO_CHANNEL_SELECT
Sep 21 13:46:39 ubuntuvdr kernel: [13799.098093] ivtv0 mb: MB Call:
CX2341X_DEC_SET_AUDIO_MODE
Sep 21 13:46:39 ubuntuvdr kernel: [13799.098098] ivtv0 ioctl:
AUDIO_BILINGUAL_CHANNEL_SELECT
Sep 21 13:46:39 ubuntuvdr kernel: [13799.098101] ivtv0 mb: MB Call:
CX2341X_DEC_SET_AUDIO_MODE
Sep 21 13:46:39 ubuntuvdr kernel: [13799.098868] ivtv0 decoder VOUT:
VIDIOC_S_FMT type=sliced-vbi-out
Sep 21 13:46:39 ubuntuvdr kernel: [13799.098881] ivtv0 decoder VOUT:
VIDIOC_G_FMT type=sliced-vbi-out
Sep 21 13:46:39 ubuntuvdr kernel: [13799.099103] ivtv0 mb: MB Call:
CX2341X_DEC_PAUSE_PLAYBACK
Sep 21 13:46:39 ubuntuvdr kernel: [13799.099270] ivtv0 mb: MB Call:
CX2341X_DEC_SET_PLAYBACK_SPEED
Sep 21 13:46:39 ubuntuvdr kernel: [13799.099435] ivtv0 info: Setting Speed to
0x00000000 0x00000000 0x00000007 0x00000002 0x00000000 0x00000000 0x00000000
Sep 21 13:46:39 ubuntuvdr vdr: [4299] TS buffer on device 1 thread ended
(pid=4287, tid=4299)
Sep 21 13:46:39 ubuntuvdr vdr: [4298] buffer stats: 3572 (0%) used
Sep 21 13:46:39 ubuntuvdr vdr: [4298] receiver on device 1 thread ended
(pid=4287, tid=4298)
Sep 21 13:46:39 ubuntuvdr vdr: [4293] changing pids of channel 240 from
0+0=2:3808:0:0 to 0+0=0:3808:0:0
Sep 21 13:46:39 ubuntuvdr vdr: [4293] changing pids of channel 241 from
0+0=2:3816:0:0 to 0+0=0:3816:0:0
Sep 21 13:46:40 ubuntuvdr kernel: [13799.558808] ivtv0 info: Stereo mode
changed
Sep 21 13:46:45 ubuntuvdr kernel: [13804.849584] ivtv0 ioctl: VIDEO_GET_PTS
Sep 21 13:46:45 ubuntuvdr kernel: [13804.849595] ivtv0 mb: MB Call:
CX2341X_DEC_GET_TIMING_INFO
Sep 21 13:46:45 ubuntuvdr vdr: [4287] cPvr350Device::GetSTC(): PTS=536726300
Sep 21 13:46:45 ubuntuvdr vdr: [4287] cPvr350Device::GetSTC(): PTS=536726300
Sep 21 13:46:45 ubuntuvdr vdr: [4287] cPvr350Device::Clear()
Sep 21 13:46:45 ubuntuvdr kernel: [13804.873152] ivtv0 ioctl: VIDEO_GET_PTS
Sep 21 13:46:45 ubuntuvdr kernel: [13804.873202] ivtv0 ioctl: VIDEO_COMMAND 1
Sep 21 13:46:45 ubuntuvdr kernel: [13804.873208] ivtv0 info: Stop Decode at 0,
flags: 2
Sep 21 13:46:45 ubuntuvdr kernel: [13804.873213] ivtv0 mb: MB Call:
CX2341X_DEC_STOP_PLAYBACK
Sep 21 13:46:45 ubuntuvdr kernel: [13804.873544] ivtv0 mb: MB Call:
CX2341X_DEC_SET_EVENT_NOTIFICATION
Sep 21 13:46:45 ubuntuvdr kernel: [13804.873853] ivtv0 ioctl: VIDEO_COMMAND 0
Sep 21 13:46:45 ubuntuvdr kernel: [13804.873859] ivtv0 info: Starting decode
stream decoder MPG (gop_offset 0)
Sep 21 13:46:45 ubuntuvdr kernel: [13804.873863] ivtv0 info: Setting some
initial decoder settings
Sep 21 13:46:45 ubuntuvdr kernel: [13804.873867] ivtv0 mb: MB Call:
CX2341X_DEC_SET_AUDIO_MODE
Sep 21 13:46:45 ubuntuvdr kernel: [13804.873872] ivtv0 mb: MB Call:
CX2341X_DEC_SET_DISPLAY_BUFFERS
Sep 21 13:46:45 ubuntuvdr kernel: [13804.873877] ivtv0 mb: MB Call:
CX2341X_DEC_SET_PREBUFFERING
Sep 21 13:46:45 ubuntuvdr kernel: [13804.873881] ivtv0 mb: MB Call:
CX2341X_DEC_EXTRACT_VBI
Sep 21 13:46:45 ubuntuvdr kernel: [13804.874179] ivtv0 info: Decoder VBI
RE-Insert start 0x0019ac00 size 0x0000be00
Sep 21 13:46:45 ubuntuvdr kernel: [13804.874183] ivtv0 mb: MB Call:
CX2341X_DEC_SET_DECODER_SOURCE
Sep 21 13:46:45 ubuntuvdr kernel: [13804.874492] ivtv0 mb: MB Call:
CX2341X_DEC_SET_DMA_BLOCK_SIZE
Sep 21 13:46:45 ubuntuvdr kernel: [13804.874498] ivtv0 mb: MB Call:
CX2341X_DEC_SET_EVENT_NOTIFICATION
Sep 21 13:46:45 ubuntuvdr kernel: [13804.874937] ivtv0 mb: MB Call:
CX2341X_DEC_START_PLAYBACK
Sep 21 13:46:46 ubuntuvdr vdr: [4300] pvr350: PlayAudio(Blackframe) written=-1
error=11:Resource temporarily unavailable

Last message continues many hundred times.

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel