[Libav-user] Is there a way to discriminate metadata/sensors info packets? (read delay)

[Daneel V]

Hello,

I'm working on a basic video player that plays videoclips in real time. 
It works smooth and flawlessly with most media files.

But I have this videoclip (duration 90 seconds) from an action camera to 
be played. Streams 0:0 and 0:1 are video and audio respectively. But it 
also has three other streams with sensor info metadata from the camera:

     Stream #0:2(eng): Data: none (tmcd / 0x64636D74) (default)
     Metadata:
       creation_time   : 2019-05-24T11:57:55.000000Z
       handler_name    : GoPro TCD
       timecode        : 11:57:12:14
     Stream #0:3(eng): Data: bin_data (gpmd / 0x646D7067), 43 kb/s (default)
     Metadata:
       creation_time   : 2019-05-24T11:57:55.000000Z
       handler_name    : GoPro MET
     Stream #0:4(eng): Data: none (fdsc / 0x63736466), 10 kb/s (default)
     Metadata:
       creation_time   : 2019-05-24T11:57:55.000000Z
       handler_name    : GoPro SOS

After the first audio/video packets are read with av_read_frame, the 
next incoming packets are thousands of packets from stream 0:4 (that I 
obviously not process). That chunk of metadata packets takes a few 
seconds to be read causing a stop in playback. After a few seconds 
video/audio packets enters again and the playback resumes.

Even implementing a large packet queue won't solve the problem since the 
queue would take as long as the aforementioned delay to fill up and it 
would set a unusual, unacceptable delay before the videoclip start to play.

I've seen that FFplay, VLC and other players plays this videoclip smooth 
from the very beginning, with no delays and no feeling of queue preload. 
It seems like these apps are somehow discriminating and ignoring these 
0:4 packets somehow.

I've been studying FFplay code and examples but I've not been able to 
fathom how to solve this.

     Thanks in advance.