I send video stream using gstreamer using the below pipeline from desktop
gst-launch-1.0 v4l2src ! video/x-raw,width=640,height=480 ! x264enc ! h264parse ! rtph264pay pt=96 ! udpsink host=ip_address port=5000 and then receive and save the stream using the below pipeline on another desktop gst-launch-1.0 -e udpsrc port=5000 ! application/x-rtp,clock-rate=90000,payload=96 ! rtph264depay ! h264parse ! mp4mux ! filesink location=a.mp4 But when I transfer this saved video to android phone this video is not playable using default media player. But is playable on other media players like vlc or mx player. If I decode and re-encode the stream on the receiver then the saved video is playable on android using default media player. The modified receiver pipeline is as below gst-launch-1.0 -e udpsrc port=5000 ! application/x-rtp,clock-rate=90000,payload=96 ! rtph264depay ! h264parse ! avdec_h264 ! x264enc ! mp4mux ! filesink location=aa.mp4 I don't wanna do this decode/re-encode thing. So can you tell me why this weird issue is happening or where do I need to change in the pipelines? -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Hi, do you know if the video is being streamed with stream-format=byte-stream. Maybe with the first pipeline it is being stored to file as byte-stream. If this were the case, a caps-filter after the h264parser, converting the stream-format to avc might help.
-----Ursprüngliche Nachricht----- Von: gstreamer-devel [mailto:[hidden email]] Im Auftrag von k4ustav Gesendet: Dienstag, 10. April 2018 14:52 An: [hidden email] Betreff: Video saved using mp4mux is not playable in android default media player I send video stream using gstreamer using the below pipeline from desktop gst-launch-1.0 v4l2src ! video/x-raw,width=640,height=480 ! x264enc ! h264parse ! rtph264pay pt=96 ! udpsink host=ip_address port=5000 and then receive and save the stream using the below pipeline on another desktop gst-launch-1.0 -e udpsrc port=5000 ! application/x-rtp,clock-rate=90000,payload=96 ! rtph264depay ! h264parse ! mp4mux ! filesink location=a.mp4 But when I transfer this saved video to android phone this video is not playable using default media player. But is playable on other media players like vlc or mx player. If I decode and re-encode the stream on the receiver then the saved video is playable on android using default media player. The modified receiver pipeline is as below gst-launch-1.0 -e udpsrc port=5000 ! application/x-rtp,clock-rate=90000,payload=96 ! rtph264depay ! h264parse ! avdec_h264 ! x264enc ! mp4mux ! filesink location=aa.mp4 I don't wanna do this decode/re-encode thing. So can you tell me why this weird issue is happening or where do I need to change in the pipelines? -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Administrator
|
In reply to this post by k4ustav
Your pipeline seems to be missing EOS. Add -e to the pipeline
~BO -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
In reply to this post by Thornton, Keith
Yes, the video is being streamed with stream-format=byte-stream. So as
suggested by you, I modified the receiver pipeline to add caps-filter video/x-h264, stream-format=avc after the h264parser. But it still doesn't work. -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
In reply to this post by Baby Octopus
-e is already there in the receiver pipeline. That's why the video is not a
corrupted one. My problem here is the video is not playable in android default media player, but can be played in other media player apps like vlc or mx player. -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Hi, this is a bit of a guessing game but is alignment=au or alignment=nal. Try adding alignment=au to the caps after h264parser
-----Ursprüngliche Nachricht----- Von: gstreamer-devel [mailto:[hidden email]] Im Auftrag von k4ustav Gesendet: Mittwoch, 11. April 2018 08:12 An: [hidden email] Betreff: Re: Video saved using mp4mux is not playable in android default media player -e is already there in the receiver pipeline. That's why the video is not a corrupted one. My problem here is the video is not playable in android default media player, but can be played in other media player apps like vlc or mx player. -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Hi,
I modified both the sender and receiver pipeline and still it doesn't work. The modified pipelines are below, gst-launch-1.0 v4l2src ! video/x-raw,width=640,height=480 ! x264enc ! video/x-h264,stream-format=byte-stream,alignment=au ! h264parse ! rtph264pay pt=96 ! udpsink host=192.168.2.203 port=5005 gst-launch-1.0 -e udpsrc port=5005 ! application/x-rtp,media=video,encoding-name=H264,clock-rate=90000,payload=96 ! rtph264depay ! h264parse ! video/x-h264,stream-format=avc,alignment=au ! mp4mux ! filesink location=a.mp4 -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
In reply to this post by Thornton, Keith
Hi,
I found the issue. I compared the logs generated by ffprobe of the streams of one working video using the decoding/re-encoding elements and non-working video. This is the diff of the two log files 30c30 < avg_frame_rate=109500/3667 --- > avg_frame_rate=1236000/41417 32,36c32,36 < start_pts=-1 < start_time=-0.000333 < duration_ts=7334 < duration=2.444667 < bit_rate=1985134 --- > start_pts=0 > start_time=0.000000 > duration_ts=41417 > duration=13.805667 > bit_rate=1968052 39c39 < nb_frames=73 --- > nb_frames=412 53c53 < TAG:creation_time=2018-04-11 08:26:33 --- > TAG:creation_time=2018-04-11 08:37:46 So, from the diff we can see that start_pts time is -1 and start_time is negative for the non-working video. So can you please tell me why start_pts and start_time is getting invalid or how can I fix this? -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Yes even I am facing same issue. But for my use case the .mp4 file does not
play out on Chrome browser via HTML5 <video> tag. If I ffprobe the mp4 file the output shows as below, *ffprobe -i 10__467118902.mp4 -v quiet -print_format json -show_format -show_streams -hide_banner* /{ "streams": [ { "index": 0, "codec_name": "h264", "codec_long_name": "H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10", "profile": "Baseline", "codec_type": "video", "codec_time_base": "1001/30000", "codec_tag_string": "avc1", "codec_tag": "0x31637661", "width": 3840, "height": 2160, "coded_width": 3840, "coded_height": 2160, "has_b_frames": 0, "sample_aspect_ratio": "1:1", "display_aspect_ratio": "16:9", "pix_fmt": "yuvj420p", "level": 51, "color_range": "pc", "color_space": "bt709", "color_transfer": "bt709", "color_primaries": "bt709", "chroma_location": "left", "refs": 1, "is_avc": "1", "nal_length_size": "4", "r_frame_rate": "30000/2002", "avg_frame_rate": "80802120/5392049", "time_base": "1/1498", *"start_pts": -226, "start_time": "-0.150868",* "duration_ts": 5392049, "duration": "3599.498665", "bit_rate": "3067876", "bits_per_raw_sample": "8", "nb_frames": "53940", "disposition": { "default": 1, "dub": 0, "original": 0, "comment": 0, "lyrics": 0, "karaoke": 0, "forced": 0, "hearing_impaired": 0, "visual_impaired": 0, "clean_effects": 0, "attached_pic": 0 }, "tags": { "creation_time": "2019-05-06 15:02:06", "language": "und", "handler_name": "VideoHandler" } } ], "format": { "filename": "13162491-8246-4f51-a37a-32fd56a87b91__9a0ad778-f8d5-4ae8-b74d-735609784cb7__HD_CAM-10__467118902.mp4", "nb_streams": 1, "nb_programs": 0, "format_name": "mov,mp4,m4a,3gp,3g2,mj2", "format_long_name": "QuickTime / MOV", "start_time": "-0.150868", "duration": "3599.498665", "size": "1416353518", "bit_rate": "3147890", "probe_score": 100, "tags": { "major_brand": "mp42", "minor_version": "0", "compatible_brands": "mp42mp41isomiso2", "creation_time": "2019-05-06 15:02:06" } } }/ And I tried to fix the file by moving the start time with command as below, *ffmpeg -i 10__467118902.mp4 -vcodec copy -ss -0.08 10__467118902_fixed.mp4* And now the generated/fixed mp4 has ffprobe summary as, /{ "streams": [ { "index": 0, "codec_name": "h264", "codec_long_name": "H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10", "profile": "Baseline", "codec_type": "video", "codec_time_base": "1001/30000", "codec_tag_string": "avc1", "codec_tag": "0x31637661", "width": 3840, "height": 2160, "coded_width": 3840, "coded_height": 2160, "has_b_frames": 1, "sample_aspect_ratio": "1:1", "display_aspect_ratio": "16:9", "pix_fmt": "yuvj420p", "level": 51, "color_range": "pc", "color_space": "bt709", "color_transfer": "bt709", "color_primaries": "bt709", "chroma_location": "left", "refs": 1, "is_avc": "1", "nal_length_size": "4", "r_frame_rate": "15000/1001", "avg_frame_rate": "10100265/674006", "time_base": "1/11984", * "start_pts": 959, "start_time": "0.080023",* "duration_ts": 43136384, "duration": "3599.497997", "bit_rate": "3067876", "bits_per_raw_sample": "8", "nb_frames": "53940", "disposition": { "default": 1, "dub": 0, "original": 0, "comment": 0, "lyrics": 0, "karaoke": 0, "forced": 0, "hearing_impaired": 0, "visual_impaired": 0, "clean_effects": 0, "attached_pic": 0 }, "tags": { "language": "und", "handler_name": "VideoHandler" } } ], "format": { "filename": "13162491-8246-4f51-a37a-32fd56a87b91__9a0ad778-f8d5-4ae8-b74d-735609784cb7__HD_CAM-10__467118902_fixed.mp4", "nb_streams": 1, "nb_programs": 0, "format_name": "mov,mp4,m4a,3gp,3g2,mj2", "format_long_name": "QuickTime / MOV", "start_time": "0.080023", "duration": "3599.498000", "size": "1381447545", "bit_rate": "3070311", "probe_score": 100, "tags": { "major_brand": "isom", "minor_version": "512", "compatible_brands": "isomiso2avc1mp41", "encoder": "Lavf56.40.101" } } } / And its perfectly playable now on Chrome browser. But I am looking for a stable fix by source at GStreamer muxer itself rather than employing another library/ffmpeg as post processing step to handle this I have seen an issue on Chrome in regard to this, https://bugs.chromium.org/p/chromium/issues/detail?id=715398 But its commented that issue is with mp4mux and has to be fixed on source while recording by muxer itself. Chrome logs error as below, *[6448:20468:0408/123832.116:VERBOSE1:network_delegate.cc(32)] NetworkDelegate::NotifyBeforeURLRequest: http://127.0.0.1:8445/10__467118902.mp4 [10356:8540:0408/123832.215:ERROR:render_media_log.cc(30)] MediaEvent: MEDIA_ERROR_LOG_ENTRY {"error":"FFmpegDemuxer: unfixable negative timestamp."} [10356:8540:0408/123832.215:ERROR:render_media_log.cc(30)] MediaEvent: MEDIA_ERROR_LOG_ENTRY {"error":"FFmpegDemuxer: demuxer error: 13"} [10356:5076:0408/123832.215:ERROR:render_media_log.cc(30)] MediaEvent: PIPELINE_ERROR DEMUXER_ERROR_COULD_NOT_PARSE* Any help/suggestions in highly appreciated Thanks -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Le mer. 8 mai 2019 06 h 55, chakra <[hidden email]> a écrit : Yes even I am facing same issue. But for my use case the .mp4 file does not Just a guess, but have you considered adding an rtpjitterbuffer in your receiver. One of its roles is to fix the timestamps. That being said, RTP CTS (PTS / DTS delta) are not accurate, so I'd recommend not using b-frames. "duration_ts": 5392049, _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Thanks Nocolas,
The exact pipeline I have is as below, *rtspsrc->rtph264depay->tee->queue->h264parse->splitmuxsink(mp4mux)* Here tee is used to other use cases like live broadcast etc. And properties of mp4mux and splitmuxsink as below, ///Create mp4mux tmp = g_strdup_printf("mp4mux-%s", "recorder"); mp4mux = gst_element_factory_make("mp4mux", tmp); g_object_set(mp4mux, "reserved-bytes-per-sec", 5000, NULL); g_object_set(mp4mux, "reserved-max-duration", (2 * GST_SECOND), NULL); g_object_set(mp4mux, "reserved-moov-update-period", (30 * GST_SECOND), NULL); g_free(tmp); //Create filesink tmp = g_strdup_printf("splitmuxsink-%s", "recorder"); splitmuxsink = gst_element_factory_make("splitmuxsink", tmp); g_object_set(splitmuxsink, "muxer", mp4mux, NULL); g_object_set(splitmuxsink, "max-size-time", (30 * GST_SECOND), NULL); g_object_set(splitmuxsink, "use-robust-muxing", TRUE, NULL); g_signal_connect(splitmuxsink, "format-location-full", G_CALLBACK(splitmuxsink_on_format_location_full), NULL);/ *splitmuxsink_on_format_location_full* -> is a method to return new file name as gchar* each time based on some increment counter The issue exactly is On Google Chrome browser with HTML5 <video> tag, the first file recorded in the above is playable and rest are not. Like for example, //mnt/av/testvideo-1__1887930741.mp4 -> Playing on Chrome /mnt/av/testvideo-2__1358928742.mp4 -> Not Playing on Chrome /mnt/av/testvideo-3__1125121133.mp4 -> Not Playing on Chrome /mnt/av/testvideo-4__1673889000.mp4 -> Not Playing on Chrome / I am not using explicit rtpjitterbuffer, its same as the one default in rtspsrc My input is RTSP with H.264 Baseline 30 fps 3M bit rate What I think is splitmuxsink/mp4mux is adding some negative start timestamp on second mp4 file onward based on buffer time from udpsrc, when the file is changed for 2nd file on wards. But not sure of it exactly Any suggestions to find exact root cause/fix would be helpful -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
You could check this using ffprobe -show_frames | grep PTS_TIME on the files. It would be enough to output the first few frames
-----Ursprüngliche Nachricht----- Von: gstreamer-devel <[hidden email]> Im Auftrag von chakra Gesendet: Freitag, 7. Juni 2019 10:14 An: [hidden email] Betreff: Re: AW: Video saved using mp4mux is not playable in android default media player Thanks Nocolas, The exact pipeline I have is as below, *rtspsrc->rtph264depay->tee->queue->h264parse->splitmuxsink(mp4mux)* Here tee is used to other use cases like live broadcast etc. And properties of mp4mux and splitmuxsink as below, ///Create mp4mux tmp = g_strdup_printf("mp4mux-%s", "recorder"); mp4mux = gst_element_factory_make("mp4mux", tmp); g_object_set(mp4mux, "reserved-bytes-per-sec", 5000, NULL); g_object_set(mp4mux, "reserved-max-duration", (2 * GST_SECOND), NULL); g_object_set(mp4mux, "reserved-moov-update-period", (30 * GST_SECOND), NULL); g_free(tmp); //Create filesink tmp = g_strdup_printf("splitmuxsink-%s", "recorder"); splitmuxsink = gst_element_factory_make("splitmuxsink", tmp); g_object_set(splitmuxsink, "muxer", mp4mux, NULL); g_object_set(splitmuxsink, "max-size-time", (30 * GST_SECOND), NULL); g_object_set(splitmuxsink, "use-robust-muxing", TRUE, NULL); g_signal_connect(splitmuxsink, "format-location-full", G_CALLBACK(splitmuxsink_on_format_location_full), NULL);/ *splitmuxsink_on_format_location_full* -> is a method to return new file name as gchar* each time based on some increment counter The issue exactly is On Google Chrome browser with HTML5 <video> tag, the first file recorded in the above is playable and rest are not. Like for example, //mnt/av/testvideo-1__1887930741.mp4 -> Playing on Chrome /mnt/av/testvideo-2__1358928742.mp4 -> Not Playing on Chrome /mnt/av/testvideo-3__1125121133.mp4 -> Not Playing on Chrome /mnt/av/testvideo-4__1673889000.mp4 -> Not Playing on Chrome / I am not using explicit rtpjitterbuffer, its same as the one default in rtspsrc My input is RTSP with H.264 Baseline 30 fps 3M bit rate What I think is splitmuxsink/mp4mux is adding some negative start timestamp on second mp4 file onward based on buffer time from udpsrc, when the file is changed for 2nd file on wards. But not sure of it exactly Any suggestions to find exact root cause/fix would be helpful -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
In reply to this post by k4ustav
May be andriod is unable to decode the high profile video. Test with
baseline with no bframes. ! x264enc bframes=0 ! video/x-h264,profile=baseline -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
I've had the same issue. Recorded mp4 file was not playable in Google
Chrome. The problem seemed to be with ctts atom, it contained negative values for sample CTS entries. Here is example decoded ctts atom: {'entries': [{'sample_count': 1, 'sample_cts': -24}, {'sample_count': 1, 'sample_cts': -6}, {'sample_count': 1, 'sample_cts': 2}, {'sample_count': 1, 'sample_cts': -29}, {'sample_count': 1, 'sample_cts': -21}, {'sample_count': 1, 'sample_cts': -16}, {'sample_count': 1, 'sample_cts': -12}, {'sample_count': 1, 'sample_cts': -29}, {'sample_count': 1, 'sample_cts': -13}, ... The gstreamer version I used was 1.16.2. I tried on gstreamer 1.17.1 and it appears the issue is somewhat fixed there. In this version generated mp4 file does not contain ctts atom, and file is playable in Chrome. So if you experience same issue upgrading to gstreamer 1.17 might fix it for you. -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Free forum by Nabble | Edit this page |