JyotsnaT / xuggle

Automatically exported from code.google.com/p/xuggle
0 stars 0 forks source link

RTSP meta data is incorrect for width and height of video stream #161

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Setup container and create container format
IContainer inContainer = IContainer.make();
inContainer.setReadRetryCount(2);
IContainerFormat inFormat = IContainerFormat.make();

2. Set container input format to "rtsp"
inFormat.setInputFormat("rtsp");

3. Open the container
inContainer.open(url, IContainer.Type.READ, inFormat, true, false)

4. Loop through the container to get the first video stream
IStreamCoder inStreamCoder = null;
for (int i = 0; i < numStreams; i++) {
    inStream = inContainer.getStream(i);
    inStreamCoder = inStream.getStreamCoder();
    if (inStreamCoder.getCodecType() == ICodec.Type.CODEC_TYPE_VIDEO) {
        break;
    }
}

5. Look at the width and height
inStreamCoder.getWidth();
inStreamCoder.getHeight();

What is the expected output? 
Width and height should have been 176x144

What do you see instead?
Width and height return "invalid" sizes of 1x6.

What operating system and JVM version are you using.
WindowsXP x64, Java6 (32bit), Xuggler 3.0

A simple DESCRIBE returns:

RTSP/1.0 200 OK
Server: QTSS/6.0.2 (Build/526.2; Platform/MacOSX; Release/Mac OS X Server; 
)
Cseq:
Cache-Control: no-cache
Content-length: 784
Date: Thu, 11 Jun 2009 18:04:42 GMT
Expires: Thu, 11 Jun 2009 18:04:42 GMT
Content-Type: application/sdp
x-Accept-Retransmit: our-retransmit
x-Accept-Dynamic-Rate: 1
Content-Base: rtsp://video2.americafree.tv/AFTVSciFiH26496.sdp/

v=0
o=QTSS_Play_List 3483851267 3766309709 IN IP4 63.105.122.34
s=AFTVSciFiH26496
c=IN IP4 0.0.0.0
b=AS:101
t=0 0
a=x-broadcastcontrol:RTSP
a=maxprate:30.000000
a=isma-compliance:2,2.0,2
a=control:*
m=video 0 RTP/AVP 96
b=AS:67
b=TIAS:61
a=3GPP-Adaptation-Support:1
a=maxprate:30
a=rtpmap:96 H264/90000
a=control:trackID=1
a=cliprect:0,0,144,176
a=framesize:96 176-144
a=fmtp:96 packetization-mode=1;profile-level-id=4D400B;sprop-parameter-
sets=J01AC6kYWJmANQYBBrbehAxe98BA,KN4JiA==
a=mpeg4-esid:201
m=audio 0 RTP/AVP 97
b=AS:37
b=TIAS:34
a=3GPP-Adaptation-Support:1
a=maxprate:15
a=rtpmap:97 mpeg4-generic/16000/2
a=control:trackID=2
a=fmtp:97 profile-level-id=15;mode=AAC-
hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1410
a=mpeg4-esid:101

Original issue reported on code.google.com by mondain on 11 Jun 2009 at 6:59

GoogleCodeExporter commented 9 years ago
This is probably happening because you haven't yet received a packet of video 
when
you're querying the stream coder.

When you open a container where you don't read the header, and say dynamic 
streams
can be added (as you do), you can only query the stream coder once you've 
gotten at
least ONE packet for that stream.

So, in your code when you read packets, wait for the first video packet, and 
then get
the stream coder.  It should be probably configured then.

See the Red5 Transcoder.java for an example of doing that, or if you're brave
(because it does a lot more) see the MediaReader.java code which does that.

Basic rule: Don't ask for a stream coder for a stream until you've gotten at 
least
one packet from that stream.

If I'm wrong, please re-open, but I'll bet 1 chocolate cookie I'm right.

Original comment by art.cla...@gmail.com on 11 Jun 2009 at 7:05

GoogleCodeExporter commented 9 years ago
You were right, I owe you a cookie; can't say I'm surprised.

Original comment by mondain on 11 Jun 2009 at 8:16