Quantcast

VP8 - Dropping inter-frame before intra-frame

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

VP8 - Dropping inter-frame before intra-frame

bojan74
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!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: VP8 - Dropping inter-frame before intra-frame

bojan74
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.
Loading...