[Live-devel] testOnDemandRTSPServer always stream audio/MPA and video/MPV?

[Jonathan Granade]

I learned that I should not modify the source code Ross ;)

I did not modify any part of the code, anything change I need, I make 
subclasses.

I want to finish this to make a test and send it here, maybe you can add 
it to the lib or maybe it will be useful for somebody.

I need to check about fDurationInMicroseconds, I did not notice that 
before...

The problem I have now is other... Remember I was dealing with an 
infinite video loop? I want to stream a 15 secs video+audio in an 
infinite loop, so the stream will be seeking to the start over and over...

What I did was create a new object (subclass) 
OnDemandContinuousServerMediaSubsession and add a task to the scheduler 
that is called every ~1 second and compare the current stream progress 
with the video duration.

When progress >= duration I do a 'loop' on the stream, something like 
(sorry i dont have the code here):

pauseStream
seekStream (to the abs byte 0)
startPlaying

That work fine when I stream a MPEG1or2* file, but when I stream using 
the way I just mentioned (MPEG4 + ADTS), it does not work.

Do you have any idea about why this happen?

Thanks in advance

On 02/02/2011 01:55 AM, Ross Finlayson wrote:
>>
>> sms->addSubsession(MPEG4VideoFileServerMediaSubsession::createNew(*env, v_inputFileName,
>> reuseFirstSource));
>>
>> sms->addSubsession(ADTSAudioFileServerMediaSubsession::createNew(*env,
>> a_inputFileName, reuseFirstSource));
>
> [...]
>
>> And I have a stream that have MPEG4-GENERIC and MP4V-ES.
>>
>> The problem I got now is the duration... I found that in both
>> subsessiions the duration is 0... and I did not found code to retrieve
>> duration of MPEG4Video and ADTSAudio.
>
> No, the "fDurationInMicroseconds" field is set in both cases. For
> "MPEG4VideoFileServerMediaSubsession", it is set in
> "MPEG4VideoStreamFramer" (actually, in its parent class
> "MPEGVideoStreamFramer"). For "ADTSAudioFileServerMediaSubsession" it is
> set in "ADTSAudioFileSource".
>
> This is a 'wild goose chase'; the frame durations should be set
> properly. (You can verify this by noting the "durationInMicroseconds"
> parameter to each call to "MultiFramedRTPSink::afterGettingFrame()", for
> each of your two "RTPSink"s.)
>
> (As always, this assumes that you have not modified the supplied source
> code. If you have made *any* modification to the supplied source code,
> you can't expect any support on this mailing list.)