During playback of progressive content, I tried to
save the content to disk as well. But the result is strange: Some contents are saved
correctly, some contents are saved but can’t playback again; some
contents even can’t playback during progressive downloaded. ## most ogg contents work
well, the saved contents can playback again gst-launch-0.10
souphttpsrc location=http://10.238.37.11/share/media/video/test.ogv ! tee
name=t ! decodebin ! ffmpegcolorspace ! xvimagesink t. ! queue ! filesink
location=test.ogv ## some mp4 saved contents
can’t playback again, the saved contents differ from the original one;
even the following test.mp4 and test2.mp4 are different gst-launch-0.10
souphttpsrc location=http:// 10.238.37.11/share/media/video/test.mp4 ! tee
name=t ! decodebin ! ffmpegcolorspace ! xvimagesink t. ! queue ! filesink
location=test.mp4 gst-launch-0.10
souphttpsrc location=http:// 10.238.37.11/share/media/video/test.mp4 ! filesink
location=/home/halley/swap/streaming/test2.mp4 ## some wmv contents even
can’t playback during progressive downloaded (though some saved wmv
contents can playback again) gst-launch-0.10 -v -v
souphttpsrc location=http:// 10.238.37.11/share/media/test.wmv ! tee name=t !
queue ! decodebin ! ffmpegcolorspace ! xvimagesink t. ! queue ! filesink
location=test.wmv thanks in advance for your
help. ZHAO,
Halley (Aihua) Email: halley.zhao<a href="blocked::mailto:aihua.zhao@intel.com"
title="mailto:aihua.zhao@intel.com mailto:hui.xue@intel.com">@intel.com Tel:
+86(21)61166476 iNet: 8821-6476 SSG/OTC/Moblin 3W038
Pole: F4 ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
On Tue, Sep 7, 2010 at 6:45 PM, Zhao, Halley <[hidden email]> wrote:
> During playback of progressive content, I tried to save the content to disk > as well. > > But the result is strange: > > Some contents are saved correctly, some contents are saved but can’t > playback again; some contents even can’t playback during progressive > downloaded. What you describe sounds like what's expected. True streaming formats (like ogg) work fine. Formats that may have the headers at the start OR the end vary - some have the headers at the end, so they're not playable until you've downloaded the entire file. Some have them at the start, so progressive download/playback works. This doesn't have anything to do specifically with GStreamer, it's simply how the formats work. Mike ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Thanks.
I understand that there are possible headers at the START or the END, however my question is about the saved contents, not playback itself during progressive downloaded. If I don't add a tee and filesink to save the content, all my mentioned contents can playback in progressive downloaded well. Especially for the mp4 contents mentioned, files are different (even file size) between save during playback and save directly from souphttpsrc: gst-launch-0.10 souphttpsrc location=http:// 10.238.37.11/share/media/video/test.mp4 ! tee name=t ! decodebin ! ffmpegcolorspace ! xvimagesink t. ! queue ! filesink location=test.mp4 gst-launch-0.10 souphttpsrc location=http:// 10.238.37.11/share/media/video/test.mp4 ! filesink location=/home/halley/swap/streaming/test2.mp4 I suspect soup request header at the END of the mp4 file when playback starts, but this header isn't save to file by filesink. -----Original Message----- From: Michael Smith [mailto:[hidden email]] Sent: 2010年9月8日 10:02 To: Discussion of the development of GStreamer Subject: Re: [gst-devel] some issues when trying to save content to disk during http progressive downloaded On Tue, Sep 7, 2010 at 6:45 PM, Zhao, Halley <[hidden email]> wrote: > During playback of progressive content, I tried to save the content to disk > as well. > > But the result is strange: > > Some contents are saved correctly, some contents are saved but can’t > playback again; some contents even can’t playback during progressive > downloaded. What you describe sounds like what's expected. True streaming formats (like ogg) work fine. Formats that may have the headers at the start OR the end vary - some have the headers at the end, so they're not playable until you've downloaded the entire file. Some have them at the start, so progressive download/playback works. This doesn't have anything to do specifically with GStreamer, it's simply how the formats work. Mike ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Based on some finding in previous thread,
I doubt the possibility to save file on disk during playback of progressive downloaded. For the mp4 file mentioned below, some bytes differ from original file at the beginning of test.mp4, and test.mp4 also loses hundreds of bytes at the end of file. Since there are many cases that parsers don't read file in serial order, saved file from souphttpsrc in gst pipeline often differ from original file. -----Original Message----- From: Zhao, Halley [mailto:[hidden email]] Sent: 2010年9月8日 10:21 To: Discussion of the development of GStreamer Subject: Re: [gst-devel] some issues when trying to save content to disk during http progressive downloaded Thanks. I understand that there are possible headers at the START or the END, however my question is about the saved contents, not playback itself during progressive downloaded. If I don't add a tee and filesink to save the content, all my mentioned contents can playback in progressive downloaded well. Especially for the mp4 contents mentioned, files are different (even file size) between save during playback and save directly from souphttpsrc: gst-launch-0.10 souphttpsrc location=http:// 10.238.37.11/share/media/video/test.mp4 ! tee name=t ! decodebin ! ffmpegcolorspace ! xvimagesink t. ! queue ! filesink location=test.mp4 gst-launch-0.10 souphttpsrc location=http:// 10.238.37.11/share/media/video/test.mp4 ! filesink location=/home/halley/swap/streaming/test2.mp4 I suspect soup request header at the END of the mp4 file when playback starts, but this header isn't save to file by filesink. -----Original Message----- From: Michael Smith [mailto:[hidden email]] Sent: 2010年9月8日 10:02 To: Discussion of the development of GStreamer Subject: Re: [gst-devel] some issues when trying to save content to disk during http progressive downloaded On Tue, Sep 7, 2010 at 6:45 PM, Zhao, Halley <[hidden email]> wrote: > During playback of progressive content, I tried to save the content to disk > as well. > > But the result is strange: > > Some contents are saved correctly, some contents are saved but can’t > playback again; some contents even can’t playback during progressive > downloaded. What you describe sounds like what's expected. True streaming formats (like ogg) work fine. Formats that may have the headers at the start OR the end vary - some have the headers at the end, so they're not playable until you've downloaded the entire file. Some have them at the start, so progressive download/playback works. This doesn't have anything to do specifically with GStreamer, it's simply how the formats work. Mike ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
In reply to this post by Zhao, Halley
Am 08.09.2010 04:45, schrieb Zhao, Halley:
> During playback of progressive content, I tried to save the content to disk as well. > > But the result is strange: > > Some contents are saved correctly, some contents are saved but can’t playback > again; some contents even can’t playback during progressive downloaded. > > > > ## most ogg contents work well, the saved contents can playback again > > gst-launch-0.10 souphttpsrc > location=http://10.238.37.11/share/media/video/test.ogv ! tee name=t ! decodebin > ! ffmpegcolorspace ! xvimagesink t. ! queue ! filesink location=test.ogv > > > > ## some mp4 saved contents can’t playback again, the saved contents differ from > the original one; even the following test.mp4 and test2.mp4 are different > > gst-launch-0.10 souphttpsrc location=http:// > 10.238.37.11/share/media/video/test.mp4 ! tee name=t ! decodebin ! > ffmpegcolorspace ! xvimagesink t. ! queue ! filesink location=test.mp4 > > gst-launch-0.10 souphttpsrc location=http:// > 10.238.37.11/share/media/video/test.mp4 ! filesink > location=/home/halley/swap/streaming/test2.mp4 > At first use decodebin2! If the http source is seekable, the muxer in decodebin will do pull. You could try: gst-launch-0.10 souphttpsrc location=http://10.238.37.11/share/media/video/test.mp4 ! queue ! tee name=t ! decodebin2 ! ffmpegcolorspace ! xvimagesink t. ! queue ! filesink location=test.mp4 Stefan > > > ## some wmv contents even can’t playback during progressive downloaded (though > some saved wmv contents can playback again) > > gst-launch-0.10 -v -v souphttpsrc location=http:// > 10.238.37.11/share/media/test.wmv ! tee name=t ! queue ! decodebin ! > ffmpegcolorspace ! xvimagesink t. ! queue ! filesink location=test.wmv > > > > thanks in advance for your help. > > > > > > *ZHAO, Halley (Aihua)* > > Email: [hidden email] <blocked::mailto:[hidden email]> > > Tel: +86(21)61166476 iNet: 8821-6476 > > SSG/OTC/Moblin 3W038 Pole: F4 > > > > > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > > > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Thanks Stefan.
After add a 'queue' after 'souphttpsrc' and use 'decodebin2'; I still got same result. I think the possible solution is to enhance souphttpsrc to save content to disk after some refractor, because souphttpsrc does some seek following the command of parser. Attached mp4.log is the log of souphttpsrc, it seek to the end of the mp4 file at the beginning of playback. Finally, tail of the original mp4 file is missing in downloaded mp4 file. halley@halley-lucid:~/swap/streaming/mp4$ ls -l total 5216 -rwxr--r-- 1 halley halley 1776915 2010-09-08 23:08 download.mp4 -rw-r--r-- 1 halley halley 1773281 2010-09-08 18:15 original.mp4 -----Original Message----- From: Stefan Kost [mailto:[hidden email]] Sent: 2010年9月11日 1:27 To: Discussion of the development of GStreamer Cc: Zhao, Halley Subject: Re: [gst-devel] some issues when trying to save content to disk during http progressive downloaded Am 08.09.2010 04:45, schrieb Zhao, Halley: > During playback of progressive content, I tried to save the content to disk as well. > > But the result is strange: > > Some contents are saved correctly, some contents are saved but can’t playback > again; some contents even can’t playback during progressive downloaded. > > > > ## most ogg contents work well, the saved contents can playback again > > gst-launch-0.10 souphttpsrc > location=http://10.238.37.11/share/media/video/test.ogv ! tee name=t ! decodebin > ! ffmpegcolorspace ! xvimagesink t. ! queue ! filesink location=test.ogv > > > > ## some mp4 saved contents can’t playback again, the saved contents differ from > the original one; even the following test.mp4 and test2.mp4 are different > > gst-launch-0.10 souphttpsrc location=http:// > 10.238.37.11/share/media/video/test.mp4 ! tee name=t ! decodebin ! > ffmpegcolorspace ! xvimagesink t. ! queue ! filesink location=test.mp4 > > gst-launch-0.10 souphttpsrc location=http:// > 10.238.37.11/share/media/video/test.mp4 ! filesink > location=/home/halley/swap/streaming/test2.mp4 > If the http source is seekable, the muxer in decodebin will do pull. You could try: gst-launch-0.10 souphttpsrc location=http://10.238.37.11/share/media/video/test.mp4 ! queue ! tee name=t ! decodebin2 ! ffmpegcolorspace ! xvimagesink t. ! queue ! filesink location=test.mp4 Stefan > > > ## some wmv contents even can’t playback during progressive downloaded (though > some saved wmv contents can playback again) > > gst-launch-0.10 -v -v souphttpsrc location=http:// > 10.238.37.11/share/media/test.wmv ! tee name=t ! queue ! decodebin ! > ffmpegcolorspace ! xvimagesink t. ! queue ! filesink location=test.wmv > > > > thanks in advance for your help. > > > > > > *ZHAO, Halley (Aihua)* > > Email: [hidden email] <blocked::mailto:[hidden email]> > > Tel: +86(21)61166476 iNet: 8821-6476 > > SSG/OTC/Moblin 3W038 Pole: F4 > > > > > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > > > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel mp4.log (258K) Download Attachment |
Hi,
2010/9/13 Zhao, Halley <[hidden email]> Thanks Stefan. It looks like you're not re-muxing the content. Are you simply storing the raw mp4 data to a file or are you using a muxer before the filesink? What does mp4info tell about your output file? You may try and recover the saved files with mp4mux using the option "moov-recovery-file". What happens if you transmux the files using it? Regards halley@halley-lucid:~/swap/streaming/mp4$ ls -l ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Your suggestion may be helpful, But I expect a solution needn’t care about demux/mux, because
all these data are passed through souphttpsrc, save the data from souphttpsrc
shouldn’t care about mux/demux. From: Marco Ballesio
[mailto:[hidden email]] Hi, 2010/9/13 Zhao, Halley <[hidden email]> Thanks Stefan.
------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Hi,
2010/9/20 Zhao, Halley <[hidden email]>
As you wrote: "it seek to the end of the mp4 file at the beginning of playback." the seek operation is performed from the demuxer (qtdemux), which identifies essential meta-data present at the end of the file. This data will not be transferred again at the end of the playback, so *in this case* you can't consider souphttpsrc as just a mere data pipe through which you get the complete clip. Said so, you have many ways to address this: - You can (try and) use the "moov-recovery-file" transmuxing the file after having saved it. It will restore the missing meta-info. - You can re-mux on-the-file the file while you're getting it from souphttpsrc. Again, it will rebuild the lost meta-infos. - You can use only progressive-download compliant files: they will have all the meta-information stored at the beginning and no seek will be needed. Regards
------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
However, I think it in another way, the way like most bittorrent
tools does. At the start of progressive downloaded, a dummy file is created
on disk; When there is seek operation requested from parser, souphttpsrc
will write bunk of data to file with offset as well. Then I will get the entire file after finish playback. From: Marco Ballesio
[mailto:[hidden email]] Hi, 2010/9/20 Zhao, Halley <[hidden email]> Your suggestion may be
helpful, But I expect a solution needn’t care about
demux/mux, because all these data are passed through souphttpsrc, save the data
from souphttpsrc shouldn’t care about mux/demux.
------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Hi,
2010/9/25 Zhao, Halley <[hidden email]>
I agree such an approach may be useful for a few cases where you want to save the file while playing it, but it can bring to really bad performances in some others: think e.g. about an embedded device using a slow flash as mass storage device. Caching everything on a file may either not be possible because of the narrow size usually these devices have or, if possible, it would be really slow at the risk of saturating the flash chip bandwidth when e.g. both reading the file and swapping. Btw I'd still like to have somebody prototyping an (optional) behaviour like the one you're suggesting. Adding a way to store to file all the contents httpsrc reads the way you point out may be really interesting at least for debugging purposes. Unfortunately, I've the feeling that getting it accepted in the "official" souphttpsrc would be a completely separate beast. Writing a custom element (such an evolved tee) may help to work around the issue. Regards
------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Free forum by Nabble | Edit this page |