GNOME Bugzilla – Bug 710623
qtdemux: Video captured by iPad couldn't play in push mode
Last modified: 2013-11-09 09:26:30 UTC
Gst-launch-1.0 play video which captured by iPad failed while play correctly in pull mode; I check the vide, I found where is mvex atom in moov, but there is no moof atom. Could you help check the problem? Thanks.
http://developer.longtailvideo.com/trac/browser/testing/files/fragmented.mp4?rev=1411 You can get fragmented mp4 file using above URL. Play fragmented.mp4 in push mode, also failed. Please check, thank you.
The mdats are coming before the moofs for this sample. It says it was created by gpac, IIRC the ipad adds something else to the metadata of the file. Is this the sample you wanted to attach? Anyway, I'm working on a patch.
Created attachment 258146 [details] [review] qtdemux: When using a buffered mdat, store all received data for later use In push mode, when qtdemux can't use a seek to skip the mdat buffer it has to buffer it for later use. The issue is that after parsing the next moov/moof, there might be some trailing bytes from the next atom in the file. This data was being discarded along with the already parsed moov/moof and playback would fail to continue after the contents of this moov/moof are played. This is particularly bad on fragmented files that have the mdat before the corresponding moof. So you'd get: mdat|moof|mdat|moof ... When a moof was received, it usually came with some extra bytes that would belong to the next mdat (because upstream doesn't care about atoms alignment). So those bytes were being discarded and playback would fail. This patch makes qtdemux store those extra bytes to reuse them later after the mdat is emptied.
Created attachment 258147 [details] [review] qtdemux: handle fragmented files with mdat before moofs Assume a file with atoms in the following order: moov, mdat, moof, mdat, moof ... The first moov usually doesn't contain any sample entries atoms (or they are all set to 0 length), because the real samples are signaled at the moofs. In push mode, qtdemux parses the moov and then finds the mdat, but then it has 0 entries and assumes it is EOS. This patch makes it continue parsing in case it is a fragmented file so that it might find the moofs and play the media.
0e78ffc9d61ffa0adca14be6e4214c8b08450b57 33ebda8ecfd976ab28879ea7fd232572d0cb1ace Fixed by those commits, thanks for reporting this bug.