Problem of streaming h.264

[GoogleCodeExporter]

SDP file:
m=video 5006 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 
packetization-mode=1;profile-level-id=42c016;sprop-parameter-sets=aM4G4g==,Z0LAF
ukBQHsg;
a=control:trackID=1

vlc log:
sps_id out of range
live555 demux error: no data received in 10s, aborting

What version of the product are you using? On what operating system?
Spydroid 8.0/ Android 4.1

how to solve this problem?

Original issue reported on code.google.com by huangyin...@gmail.com on 26 Apr 2013 at 1:40

[GoogleCodeExporter]

it's my android log

Original comment by huangyin...@gmail.com on 26 Apr 2013 at 3:27

Attachments:

• android_log.txt

[GoogleCodeExporter]

Hi !
It seems that the client is not receiving anything :/ It could be a firewall 
issue...

Original comment by FyHertz on 27 Apr 2013 at 8:05

[GoogleCodeExporter]

Thank for your reply.
Stream h.263 is working, i might not be the firewall issue.
whether it is related to the h264 profile level or h264 rtp packet?

Original comment by huangyin...@gmail.com on 29 Apr 2013 at 12:27

[GoogleCodeExporter]

I had a similar issue. I could stream h.264 the first time, and never again. 
h.263 always worked. From debugging, I see that SpyDroid first records an MP4 
test file, then reads and stores the SPS and PPS as resX and resY in the app 
preferences. It initializes MP4Config using TESTFILE. On subsequent runs, it 
reads those values from preferences and uses them to initialize MP4Config. 
However, H264Stream.java creates MP4Config using (profile, SPS, PPS). Remember 
that resX == SPS, and resY == PPS. The arguments to the MP4Config constructor 
are (profile, PPS, SPS).
In conclusion, it's a simple transposition error. To fix it, modify 
MP4Config.java. Change the following line
from: public MP4Config(String profile, String pps, String sps) {
to: public MP4Config(String profile, String sps, String pps) {

I'm new to open-source development, but I'll try to commit this change.

Original comment by awoo...@gmail.com on 6 May 2013 at 9:14

[GoogleCodeExporter]

Hi all,
Thanks for noticing that, indeed the two parameters were not in the proper 
order. I commited the fix.

About the Sequence Parameter Set (SPS) and the Picture Parameter Set (PPS), the 
first one does not correspond to resX and the latter to resY. It's more 
complicated, those are structures containing information needed to decode the 
H.264 stream correctly. They are defined in part 10 of the ISO/IEC 14496 
standard and contains information such as the frame rate and the resolution of 
the stream, along with various other parameters.

As an example, here are all the possible fields of the SPS:
        profile_idc;
        constraint_set0_flag;
        constraint_set1_flag;
        constraint_set2_flag;
        constraint_set3_flag;
        reserved_zero_4bits;
        level_idc;
        seq_parameter_set_id;
        log2_max_frame_num_minus4;
        pic_order_cnt_type;
        log2_max_pic_order_cnt_lsb_minus4;
        delta_pic_order_always_zero_flag;
        offset_for_non_ref_pic;
        offset_for_top_to_bottom_field;
        num_ref_frames_in_pic_order_cnt_cycle;
        [] offset_for_ref_frame = new int[256];
        num_ref_frames;
        gaps_in_frame_num_value_allowed_flag;
        pic_width_in_mbs_minus1;
        pic_height_in_map_units_minus1;
        frame_mbs_only_flag;
        mb_adaptive_frame_field_flag;
        direct_8x8_inference_flag;
        frame_cropping_flag;
        frame_crop_left_offset;
        frame_crop_right_offset;
        frame_crop_top_offset;
        frame_crop_bottom_offset;
        vui_parameters_present_flag;

The resolution is, for example, indicated by pic_width_in_mbs_minus1 and 
pic_height_in_mbs_minus1.

Original comment by FyHertz on 9 May 2013 at 5:23