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.
_______________________________________________
Libav-user mailing list
[email protected]
https://ffmpeg.org/mailman/listinfo/libav-user
To unsubscribe, visit link above, or email
[email protected] with subject "unsubscribe".
