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?
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
Now I see that mythtv is doing it differently:
videofd = open(viddev.constData(), O_WRONLY | O_NONBLOCK, 0555);
What does the 0555 mean ?
Greets,
Martin
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
