Hello,
I have a pipeline like this: appsrc->rtpjitterbuffer->rtpvp8depay->webmmux->filesink appsrc use push-buffer to push RTP header+payload to pipe line. I have some old VP8 pcap example that I am using as source - I extract RTP header+payload and use it as input. And it works well, I get .webm file that I can play. But VP8 .pcap that I created now and use it as source in the same way as above produce me this error: 0:00:02.287498382 10328 0000014BEC2044C0 INFO rtpvp8depay gstrtpvp8depay.c:197:gst_rtp_vp8_depay_process:<rtpvp8depay0> Dropping inter-frame before intra-frame Every packet is dropped and so webm file is without content. In both cases I use same code (application), just input file (RTP packets passing to appsrc) is different. I compare both GST_DEBUG outputs. When pipeline is change to PLAYING I get in both cases: 0:00:02.146507677 12124 0000019EC3594000 INFO GST_STATES gstelement.c:2419:gst_element_continue_state:<rtpjitterbuffer0> completed state change to PLAYING 0:00:02.146567270 12124 0000019EC3BF4540 INFO GST_EVENT gstevent.c:808:gst_event_new_caps: creating caps event application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)VP8 0:00:02.146720225 12124 0000019EC3594000 INFO GST_STATES gstelement.c:2324:_priv_gst_element_state_changed:<rtpjitterbuffer0> notifying about state-changed PAUSED to PLAYING (VOID_PENDING pending) On 1st input RTP packet these lines are very similar in both cases (working, non-working): 0:00:02.181052985 12124 0000019EC3BF4540 INFO GST_EVENT gstevent.c:889:gst_event_new_segment: creating segment event time segment start=0:00:00.000000000, offset=0:00:00.000000000, stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00, time=0:00:00.000000000, base=0:00:00.000000000, position 0:00:00.000000000, duration 99:99:99.999999999 0:00:02.183867423 12124 0000019EC3BF4540 INFO basesrc gstbasesrc.c:2847:gst_base_src_loop:<appsrc0> marking pending DISCONT 0:00:02.184271661 12124 0000019EC3BF4540 INFO rtpjitterbuffer rtpjitterbuffer.c:855:rtp_jitter_buffer_insert: resync to time 0:00:00.000000000, rtptime 11:34:16.601977777 0:00:02.184518640 12124 0000019EC3BF44C0 INFO rtpjitterbuffer gstrtpjitterbuffer.c:3788:do_deadline_timeout:<rtpjitterbuffer0> got deadline timeout 0:00:02.184999025 12124 0000019EC3BF4500 INFO GST_EVENT gstevent.c:889:gst_event_new_segment: creating segment event time segment start=0:00:00.000000000, offset=0:00:00.000000000, stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00, time=0:00:00.000000000, base=0:00:00.000000000, position 0:00:00.000000000, duration 99:99:99.999999999 But difference is on 2nd packet where I got these lines only with working example: 0:00:02.260681603 12124 0000019EC3BF4500 INFO GST_EVENT gstevent.c:808:gst_event_new_caps: creating caps event video/x-vp8, framerate=(fraction)0/1, height=(int)480, width=(int)640, profile=(string)0 0:00:02.263667204 12124 0000019EC3BF4500 FIXME basesink gstbasesink.c:3077:gst_base_sink_default_event:<filesink0> stream-start event without group-id. Consider implementing group-id handling in the upstream elements 0:00:02.263879421 12124 0000019EC3BF4500 INFO GST_EVENT gstevent.c:808:gst_event_new_caps: creating caps event video/webm 0:00:02.264077070 12124 0000019EC3BF4500 INFO matroskamux matroska-mux.c:2765:gst_matroska_mux_start:<ebmlwrite0> DocType: webm, Version: 2 0:00:02.264275713 12124 0000019EC3BF4500 INFO ebmlwrite ebml-write.c:216:gst_ebml_writer_send_segment_event: seeking to 0 0:00:02.264457471 12124 0000019EC3BF4500 INFO GST_EVENT gstevent.c:889:gst_event_new_segment: creating segment event time segment start=0:00:00.000000000, offset=0:00:00.000000000, stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00, time=0:00:00.000000000, base=0:00:00.000000000, position 0:00:00.000000000, duration 99:99:99.999999999 0:00:02.265983048 12124 0000019EC3BF4500 INFO GST_EVENT gstevent.c:808:gst_event_new_caps: creating caps event video/webm, streamheader=(buffer)< 1a45dfa301000000000000104282857765626d0042878102428581021853806701ffffffffffffff1549a96601000000000000562ad7b1830f42404d80a54753747265616d6572206d6174726f736b616d75782076657273696f6e20312e31302e32005741994753747265616d6572204d6174726f736b61206d7578657200446188071aea7b4fc28e001654ae6b010000000000003cae0100000000000033d7810183810173c588c328bb32a40e3376536e86566964656f00e00100000000000008b0820280ba8201e08686565f56503800 > Any idea why this last "creating caps" doesnt happen in non-working case? Is some info missing in RTP stream? Or do I have to set any additional caps for this case? Or GST_BUFFER_PTS or GST_BUFFER_DURATION are not calculated well before I push-buffer? ... Thanks a lot in advance for any hint! |
Just in case if anyone will have this problem ...
I got that error message because key frame was not sent and so every packet was dropped. After I manage that key frame was sent problem "VP8 - Dropping inter-frame before intra-frame" disappear what is logical. |
Free forum by Nabble | Edit this page |