On 9/20/09, Andy Walls <[email protected]> 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 > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-devel >
-- Tony (echo 'spend!,pocket awide' | sed 'y/acdeikospntw!, /[email protected]/') _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
