qtdemux - unable to locate moov atom

[amitchawla]

Hi,

I am using qtdemux in my pipelines, and while playing MP4/MOV files, I see that few of the files fail to play, as qtdemux exits with ....error

"no moov atom within the first 10 MB" .

Clearly for those MP4/MOV files that moov atom is at the end of the file. Since I am streaming the file to qtdemux via tcpserversrc over a tcp connection, I see that in qtdemux.c, probably the upstream_seekable is FALSE.

My question is "Does qtdemux (version 1.2.4, 2014-04-18) that I have on my platform handles unoptimized MP4/MOV files where moov atom is not found at the start of the file? " or Do I have to implement that myself in qtdemux.c.  

I understand that I will have to implement this handling, considering my TCP streaming case (Push mode) as opposed to seeking moov atom from a file (Pull mode).

Many thanks for your inputs.

Amit

[Sebastian Dröge-3]

On Thu, 2016-12-22 at 02:45 -0800, amitchawla wrote:

> Hi,
>
> I am using qtdemux in my pipelines, and while playing MP4/MOV files, I see
> that few of the files fail to play, as qtdemux exits with ....error
>
> "no moov atom within the first 10 MB" .
>
> Clearly for those MP4/MOV files that moov atom is at the end of the file.
> Since I am streaming the file to qtdemux via tcpserversrc over a tcp
> connection, I see that in qtdemux.c, probably the upstream_seekable is
> FALSE. 
>
> My question is "Does qtdemux (version 1.2.4, 2014-04-18) that I have on my
> platform handles unoptimized MP4/MOV files where moov atom is not found at
> the start of the file? " or Do I have to implement that myself in qtdemux.c.  
>
> I understand that I will have to implement this handling, considering my TCP
> streaming case (Push mode) as opposed to seeking moov atom from a file (Pull
> mode).

If upstream is not seekable (tcpserversrc is not), then qtdemux can't
possibly do anything here. And tcpserversrc has no ways of allowing
seeking, that's something that requires a protocol on top of TCP.

You will have to implement a source element for this, that allows
seeking and implements some kind of protocol on top of TCP. Then
qtdemux can possibly make use of that and find the moov. qtdemux in
1.10 at least has support for this and the code for this seems to exist
at least since 2009.


Nonetheless, it's generally a bad idea to stream such MP4 files over a
PUSH based transport.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[amitchawla]

Hi Sebastian,

Thanks for your reply. It would be nice if you could put some light on the following - please correct me if I am wrong,

1) What is the concept of PUSH mode and PULL mode at the lowest level of implementation ? As I understand, PUSH mode transport means that the src pad (upstream element) is executing the loop thread, and the smooth flow of buffers depends on the SRC element (TCPSERVERSRC in my case) receiving the data from the network on time. Can TCPSERVERSRC operate in PULL mode ? Will that mean I have to make it seekable to operate in PULL mode?

2) PULL mode means that the streaming thread (loop thread) is implemented not by the SRC element but by a downstream element. So the onus of smooth flow is on the downstream element (like QTDEMUX in my case) to be able to pull the data from the SRC and pass it downstream. Is my understanding correct?

3) Can Gstreamer pipeline operate PULL mode in case of network streaming?

and Wish you a Merry Christmas and a Happy New Year 2017/

Many Thanks
Amit

[Sebastian Dröge-3]

On Thu, 2016-12-22 at 21:33 -0800, amitchawla wrote:
> Hi Sebastian,
>
> Thanks for your reply. It would be nice if you could put some light on the
> following - please correct me if I am wrong,
>
> 1) What is the concept of PUSH mode and PULL mode at the lowest level of
> implementation ? As I understand, PUSH mode transport means that the src pad
> (upstream element) is executing the loop thread

Correct. PUSH means that upstream runs a thread and just pushes data
downstream, PULL means that this element runs a thread and pulls data
from upstream instead.

> and the smooth flow of
> buffers depends on the SRC element (TCPSERVERSRC in my case) receiving the
> data from the network on time. Can TCPSERVERSRC operate in PULL mode ? Will
> that mean I have to make it seekable to operate in PULL mode?

As mentioned before, tcpserversrc can't do that. It can neither run in
PULL mode (in a meaningful way), nor can it provide any seeking
capabilities. You have to implement an actual protocol on top of TCP
for this.


> 2) PULL mode means that the streaming thread (loop thread) is implemented
> not by the SRC element but by a downstream element. So the onus of smooth
> flow is on the downstream element (like QTDEMUX in my case) to be able to
> pull the data from the SRC and pass it downstream. Is my understanding
> correct?

Yes

> 3) Can Gstreamer pipeline operate PULL mode in case of network streaming?

Yes, together with the downloadbuffer / queue2 elements that also
happens relatively often. In that case the source runs in PUSH mode,
but queue2 converts it into PULL mode.

In theory also network source elements themselves can work in PULL
mode, but generally it does not make sense as these protocols generally
work more in a PUSH way. You get data and don't request it block for
block.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel