[Live-devel] Problems with MPEG-4 streaming...

[Clark N. Taylor]

Ross Finlayson wrote:

>
>> First, when trying to stream an MPEG-4 video with a fixed frame rate, 
>> I found that the timing was off (it would only serve a frame every 33 
>> seconds, instead of 30 per second). The problem was in the 
>> MPEG4VideoStreamFramer.cpp file, line 388.  Even at a fixed rate,  
>> the fFrameRate should be set to vop_time_increment_resolution, so the 
>> code now reads:
>>
>>       usingSource()->fFrameRate
>>     = vop_time_increment_resolution;
>
>
> But that's what the code currently *does* do (on line 389 of 
> "MPEG4VideoStreamFramer.cpp"), and that code hasn't changed in weeks.  
> Are you sure you're using a recent version of the source code??

In the most recent code (2004.01.19), the erroneous code is on line 390. 
 I am saying it should say the code I have here  whether the video is 
fixed rate or not.

>
>> The second problem is more puzzling.  When all I do is stream from 
>> testOnDemand... to openRTSP, the output file from openRTSP is not the 
>> same as the source file for testOnDemand....  I have looked at the 
>> output file, and for some reason it is sending some information at 
>> the beginning of the file twice.
>
>
> No, the information is being *sent* only once.  However, "openRTSP" 
> (the receiving client) is adding the information an extra time to the 
> start of the file (see "testProgs/playCommon.cpp", line 547).
>
> The reason it does this is that - for some live MPEG-4 streams - the 
> VisualObjectSequence etc. headers are not present in the stream.  
> Instead, those headers are described only in the "config" information 
> in the SDP description (returned by the RTSP "DESCRIBE" command).  In 
> order for the recorded MPEG-4 data to be useful, those headers need to 
> be present, so "openRTSP" adds them to the front of the file.
>
> Of course, this means that for those MPEG-4 streams (e.g., prerecorded 
> video) that *do* happen to include these headers, the output file will 
> contain them twice.  That shouldn't be a problem, though.

Makes sense.  Thanks.

>
>> Similarly, testOnDemand, when it finds the VisualObjectSequenceEnd  
>> header, does not send out the last 4 bytes of information (the end 
>> header).
>
>
> That appears to be a bug.  I'll take a look at this.
>
I just downloaded the code, ran it, but the last 4 bytes still are not 
received.  The new function you added is run on the server side (I can 
see it when DEBUG is defined), but for some reason the recipient doesn't 
seem to get it (the afterGetting function is never called with the 4 
byte input).  Something I did that works is, starting at line 562 (the 
case VISUAL_OBJECT_SEQUENCE_END_CODE)
    save4Bytes(VISUAL_OBJECT_SEQUENCE_END_CODE);
    setParseState(PARSING_VISUAL_OBJECT_SEQUENCE);
    break;

This transmits properly to the end receiver.  

Thanks for all your help and quick responses!

-- 
Clark N. Taylor
PhD Student and Research Assistant
University of California, San Diego
cntaylor at ece.ucsd.edu
http://esdat.ucsd.edu/~cntaylor