typefind does not find the correct media type for mpg with http streaming
Submitted by satish kumar
Link to original bug (#721676)
Description
Created attachment 265502
The patch analyzes the data to find the max probabiltity till the max data size is reached.
Sometimes for some mpg streams in http streaming case, only audio is decoded. Video is not displayed. streams has both audio/video content.
Analysis:
The issue is coming from typefind element. In this, minimum data size required for parsing is set to 2048 bytes and max as 128*1024.
Failing case: in this case, httpsrc (soup) source gives 2625 bytes to typefind as first buffer. This buffer is used for parsing to find the suitable data type for further auto plugging. For this size, five consecutive frames of mp3 are found. So typefind declares it as mpeg/audio with probability 99. This is maximum for current case. Hence only audio pipeline is created and so no video at all.
Passing case: when this passes ( showing video/audio both) then httpsrc(soup) gives 1165 bytes which are less than min size( 2048) so they are stored and soup again gives 4096 bytes which makes a total of 5261 bytes to typefind. With this data length video/mpeg-sys with probability 100 is declared as typefind output. This causes further auto plugging of demuxer and audio/video decoding path. Hence working fine.
These figures are based on some logs and may vary for different run case, but the issue should remain same. Main issue is that when some format is found then it does not check for case where some other format might be found with more probability if some more data is used for parsing.
Also proposed a patch to fix the issue.
Patch 265502, "The patch analyzes the data to find the max probabiltity till the max data size is reached. ":
0001-typefind-find-media-type-in-typefind-with-maximum-pr.patch