-
Bug
-
Resolution: Cannot Reproduce
-
P2
-
None
-
fx1.2.1
-
Windows XP / Windows Vista
Especially on windows fxm/flv Media creation fails during initialization on slow networks (or VPN) and causes a freeze of the whole application.
The following video fails with a probability of 60% on a simulated 256kbit/s link (using Charles Debugging Proxy):
http://cdn.ubivent.com/wifo/videos/becker_interview.fxm
The freeze may also happen on Mac, but with much lower probability.
On Windows the thread hangs in _Open or _ndsGetDuration of the native directshow jmc plugin.
The likeliness of a freeze correlates directly with the size of the first video tag in the FLV file. Other videos with even larger first keyframe had a chance of nearly 100% to fail. Adding a black frame at the beginning of the video (and therefore a much better compressable keyframe) lowers the fail rate to < 5%. It seems that the parse/decoder expects the first frame to be delivered in full with the first chunk of data.
Dump of the first few frames:
#1 Meta Tag (onMetaData): timestamp 0, size 355, data size 344
#2 Video Tag (Keyframe): timestamp 0, size 20896, data size 20885
#3 Audio Tag: timestamp 5, size 534, data size 523
#4 Audio Tag: timestamp 31, size 847, data size 836
#5 Video Tag (Interframe): timestamp 40, size 1240, data size 1229
#6 Audio Tag: timestamp 57, size 534, data size 523
#7 Video Tag (Interframe): timestamp 80, size 1560, data size 1549
#8 Audio Tag: timestamp 83, size 534, data size 523
With a black image the first Keyframe has a size of 71byte.
MetaData / Tag Structure of video files with higher failure rate are available via email on request.
The following video fails with a probability of 60% on a simulated 256kbit/s link (using Charles Debugging Proxy):
http://cdn.ubivent.com/wifo/videos/becker_interview.fxm
The freeze may also happen on Mac, but with much lower probability.
On Windows the thread hangs in _Open or _ndsGetDuration of the native directshow jmc plugin.
The likeliness of a freeze correlates directly with the size of the first video tag in the FLV file. Other videos with even larger first keyframe had a chance of nearly 100% to fail. Adding a black frame at the beginning of the video (and therefore a much better compressable keyframe) lowers the fail rate to < 5%. It seems that the parse/decoder expects the first frame to be delivered in full with the first chunk of data.
Dump of the first few frames:
#1 Meta Tag (onMetaData): timestamp 0, size 355, data size 344
#2 Video Tag (Keyframe): timestamp 0, size 20896, data size 20885
#3 Audio Tag: timestamp 5, size 534, data size 523
#4 Audio Tag: timestamp 31, size 847, data size 836
#5 Video Tag (Interframe): timestamp 40, size 1240, data size 1229
#6 Audio Tag: timestamp 57, size 534, data size 523
#7 Video Tag (Interframe): timestamp 80, size 1560, data size 1549
#8 Audio Tag: timestamp 83, size 534, data size 523
With a black image the first Keyframe has a size of 71byte.
MetaData / Tag Structure of video files with higher failure rate are available via email on request.