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
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
