GNOME Bugzilla – Bug 759895
flv: need flvparse element
Last modified: 2015-12-28 20:44:56 UTC
I tried this but pipeline is not broadcasting anything and it is exiting very fast (<30sec). GST_DEBUG=3 gst-launch-1.0 filesrc location=live_cam.flv ! queue ! flvdemux name=demuxer ! queue ! aacparse ! muxer. demuxer. ! queue ! h264parse ! flvmux name=muxer streamable=true ! rtmpsink sync=true async=true location='rtmp://XXXXXXXXXXXXXXXX live=1' here is the flv file[1] which is not working with above pipeline: [1] https://drive.google.com/file/d/0BwVTSuISF3EcWWRDTnZJRXR1RTQ/view?usp=sharing I also verified that flv file [1] is working fine with below pipeline: gst-launch-1.0 filesrc location=live_cam.flv ! decodebin name=demux ! queue ! x264enc pass=pass1 threads=0 bitrate=900 tune=zerolatency ! flvmux name=mux ! rtmpsink location='rtmp://xxxxxxxxxxxxxxx live=1' demux. ! queue ! progressreport ! audioconvert ! audiorate ! audioresample ! faac bitrate=96000 ! audio/mpeg,mpegversion=4,stream-format=raw ! mux. But my goal is to make it work with flvdemux/flvmux without doing EXTRA decoding/encoding. But flvmux/flvdemux is failing to work. Please solve it .
Please marking all your bugs as blocker bugs. Blocker status is something maintainers set.
(In reply to Tim-Philipp Müller from comment #1) > Please marking all your bugs as blocker bugs. Blocker status is something > maintainers set. Thanks for the information. I have a question: Why we are unable to do streaming with flvdemux and flvmux element in current gstreamer ? Isn't that we should be able to do that ? Idea of new flvparse element is always welcome. But it is still unclear why we are unable to do streaming with flvdemux and flvmux element for flv file. Could you please clarify that ? I am also seeing some commits for gstflvparse.c in http://cgit.freedesktop.org/gstreamer/gst-plugins-good/log/?qt=grep&q=flvparse. But gstflvparse.c does not exist in source code tree now. Any ideas ?
To be fair, I got no idea where that flvparse thing comes from or why we'd need that element. Feel free to explain. I also done some tests, since I believe it should work. The provided flv has some "presumed" corruption, which seems to lead to issue "sometimes". It might be worth for you to have a look. Nevertheless, I've simulated a live transcoding to local streamable FLV (and played it back simultaneously). Everything works for me. gst-launch-1.0 filesrc location=live_cam.flv ! flvdemux name=demux demux. ! queue ! h264parse ! mux. demux. ! queue ! aacparse ! mux. flvmux streamable=1 name=mux ! identity sync=1 ! filesink location=result.flv I'm not constructing the pipeline like you do (with direct muxer/demuxer links), maybe that indicates some bug in parse_launch, though I found your way very confusing. Please provide additional information. I suspect we are facing a interoperability issue with your receiving server. I know some servers like youtube server are really picky about video encoding, distance between keyframes and stuff like this.
(In reply to Nicolas Dufresne (stormer) from comment #3) > To be fair, I got no idea where that flvparse thing comes from or why we'd > need that element. Feel free to explain. I also done some tests, since I > believe it should work. The provided flv has some "presumed" corruption, > which seems to lead to issue "sometimes". It might be worth for you to have > a look. > > Nevertheless, I've simulated a live transcoding to local streamable FLV (and > played it back simultaneously). Everything works for me. > > gst-launch-1.0 filesrc location=live_cam.flv ! flvdemux name=demux demux. ! > queue ! h264parse ! mux. demux. ! queue ! aacparse ! mux. flvmux > streamable=1 name=mux ! identity sync=1 ! filesink location=result.flv > I tried your pipeline by replacing filesink with rtmpsink and this is more stable than my pipeline in #comment 0. But I still see crash "RTMP send error" randomly after sometime. My question is why below pipeline which is doing extra work of encoding/decoding works fine without crash for same flv file: gst-launch-1.0 filesrc location=live_cam.flv ! decodebin name=demux ! queue ! x264enc pass=pass1 threads=0 bitrate=900 tune=zerolatency ! flvmux name=mux ! rtmpsink location='rtmp://xxxxxxxxxxxxxxx live=1' demux. ! queue ! progressreport ! audioconvert ! audiorate ! audioresample ! faac bitrate=96000 ! audio/mpeg,mpegversion=4,stream-format=raw ! mux. Does it mean that flvmux/flvdemux has some bug so it is not able to do its job when used standalone without encoding/decoding ?
It's most likely what Nicolas wrote before, and I wrote in some other bug you reported: (In reply to Nicolas Dufresne (stormer) from comment #3) > I suspect we are > facing a interoperability issue with your receiving server. I know some > servers like youtube server are really picky about video encoding, distance > between keyframes and stuff like this. To see if this is indeed the problem requires further debugging on your side, and ideally also on the receiver end.
> To be fair, I got no idea where that flvparse thing comes from or why we'd > need that element. Feel free to explain. The context for this comes from a IRC conversation. It just seemed to make the most sense, but we can also retitle it again and simply focus on the issue at hand which is something no one will really be able to figure out other than the reporter, as there's no particular evidence of a GStreamer issue other than "something doesn't work".
(In reply to Tim-Philipp Müller from comment #6) > It just seemed to make > the most sense, but we can also retitle it again and simply focus on the > issue at hand which is something no one will really be able to figure out > other than the reporter, as there's no particular evidence of a GStreamer > issue other than "something doesn't work". I reported this issue and I can provide you any log or test any patch for you. Please let me know what log do you need ? Should I collect with GST_DEBUG=6 ? I can also provide you remote vnc access to our system if needed.
"RTMP send error" is not a crash, neither a GStreamer specific error. This is what librtmp returns whenever the remote end shutdown the connection. This is common practice by server to throw away streams that do not follow server policies. To determine if a stream follow the policies, the server will let you stream for a little while, it will analyse the stream and then it may reject it. Reason for rejections can be unacceptable encoding profile, to few keyframes, presence of B-Frames, to high/low bandwidth etc. Only your service provider (or your server if you have direct access) can explain the reason for that. Transcoding is often the only way to fix the stream to satisfy server needs. Feel to come and chat with us on IRC (freenode #gstreamer) for further help. We reserve the bugzilla for actually problems with GStreamer implementation.