GStreamer-devel

Re: How to append one mp4 file to another?

classic Classic list List threaded Threaded
♦
♦
 3 messages Options
sonntex
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: How to append one mp4 file to another?

sonntex
on Wed, 02 Nov 2016 09:50:31 +0200, Sebastian Dröge wrote:
> Maybe you'd like to use the splitmuxsink element (and then splitmuxsrc)
> for generating your files? Alternatively you will have to demux them
> (all in one pipeline) and mux them again with (the same) mp4mux.

Thank you! So, I write some chunks using splitmuxsink. Chunks are valid and have correct pts, pts_time, dts, dts_time, duration and duration_time for each packet.

sonntex@home ~/video0 $ ls -l
total 3696
-rw-r--r-- 1 sonntex sonntex 1890215 Nov 18 16:58 video-chunk-00.mp4
-rw-r--r-- 1 sonntex sonntex 1891161 Nov 18 16:58 video-chunk-01.mp4

sonntex@home ~/video0 $ ffprobe -show_packets video-chunk-01.mp4 2>&1 | tail -n 30
[PACKET]
codec_type=video
stream_index=0
pts=124771
pts_time=12.477100
dts=124771
dts_time=12.477100
duration=98
duration_time=0.009800
convergence_duration=N/A
convergence_duration_time=N/A
size=10329
pos=1866712
flags=_
[/PACKET]
[PACKET]
codec_type=video
stream_index=0
pts=124869
pts_time=12.486900
dts=124869
dts_time=12.486900
duration=697
duration_time=0.069700
convergence_duration=N/A
convergence_duration_time=N/A
size=10478
pos=1877041
flags=_
[/PACKET]

But result of the merge is incorrect!

sonntex@home ~/video0 $ GST_DEBUG=3 gst-launch-1.0 splitmuxsrc location="video-chunk-*.mp4" ! splitmuxsink location="video.mp4"
Setting pipeline to PAUSED ...
0:00:00.010555250 29243      0x1a28500 WARN                 basesrc gstbasesrc.c:3491:gst_base_src_start_complete:<filesrc0> pad not activated yet
0:00:00.012274605 29243 0x7fc71c0200f0 WARN                 qtdemux qtdemux.c:2886:qtdemux_parse_trex:<qtdemux0> failed to find fragment defaults for stream 1
0:00:00.012340497 29243 0x7fc71c0200f0 WARN                 basesrc gstbasesrc.c:2400:gst_base_src_update_length:<filesrc0> processing at or past EOS
0:00:00.013333616 29243      0x1a28500 WARN                 basesrc gstbasesrc.c:3491:gst_base_src_start_complete:<filesrc1> pad not activated yet
0:00:00.014049112 29243      0x19150f0 WARN                 qtdemux qtdemux.c:2886:qtdemux_parse_trex:<qtdemux1> failed to find fragment defaults for stream 1
0:00:00.014108777 29243      0x19150f0 WARN                 basesrc gstbasesrc.c:2400:gst_base_src_update_length:<filesrc1> processing at or past EOS
Pipeline is PREROLLING ...
0:00:00.015955797 29243 0x7fc71c020370 FIXME               basesink gstbasesink.c:3077:gst_base_sink_default_event:<sink> stream-start event without group-id. Consider implementing group-id handling in the upstream elements
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
0:00:00.016233204 29243      0x1a28500 WARN                     bin gstbin.c:2796:gst_bin_do_latency_func:<pipeline0> did not really configure latency of 0:00:00.000000000
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:00.006390800
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

sonntex@home ~/video0 $ ls -l
total 7372
-rw-r--r-- 1 sonntex sonntex 1890215 Nov 18 16:58 video-chunk-00.mp4
-rw-r--r-- 1 sonntex sonntex 1891161 Nov 18 16:58 video-chunk-01.mp4
-rw-r--r-- 1 sonntex sonntex 3761145 Nov 18 21:20 video.mp4

sonntex@home ~/video0 $ ffprobe -show_packets video.mp4 2>&1 | tail -n 30
[PACKET]
codec_type=video
stream_index=0
pts=124416
pts_time=24.883200
dts=124416
dts_time=24.883200
duration=652
duration_time=0.130400
convergence_duration=N/A
convergence_duration_time=N/A
size=10139
pos=3734207
flags=_
[/PACKET]
[PACKET]
codec_type=video
stream_index=0
pts=125068
pts_time=25.013600
dts=125068
dts_time=25.013600
duration=49
duration_time=0.009800
convergence_duration=N/A
convergence_duration_time=N/A
size=10329
pos=3744346
flags=_
[/PACKET]

As you can see, pts, dts and duration do not correspond to pts_time, dts_time and duration_time.

It is not a problem for VLC in some cases, but I have one usb camera for which VLC does not work. Chunks are also valid and have correct pts, pts_time, dts, dts_time, duration and duration_time for each packet.

sonntex@home ~/video1 $ ls -l
total 132
-rw-r--r-- 1 sonntex sonntex 67913 Nov 18 17:32 video-chunk-00.mp4
-rw-r--r-- 1 sonntex sonntex 62051 Nov 18 17:32 video-chunk-01.mp4

sonntex@home ~/video1 $ ffprobe -show_packets video-chunk-01.mp4 2>&1 | tail -n 30
[PACKET]
codec_type=video
stream_index=0
pts=145692
pts_time=14.569200
dts=145692
dts_time=14.569200
duration=130
duration_time=0.013000
convergence_duration=N/A
convergence_duration_time=N/A
size=12
pos=54537
flags=_
[/PACKET]
[PACKET]
codec_type=video
stream_index=0
pts=145822
pts_time=14.582200
dts=145822
dts_time=14.582200
duration=1
duration_time=0.000100
convergence_duration=N/A
convergence_duration_time=N/A
size=12
pos=54549
flags=_
[/PACKET]

Result of the merge is incorrect too! But, probably, there are overflows and some of the values are negative (not for each packet). It's enough for VLC to not play this file.

sonntex@home ~/video1 $ GST_DEBUG=3 gst-launch-1.0 splitmuxsrc location="video-chunk-*.mp4" ! splitmuxsink location="video.mp4"
Setting pipeline to PAUSED ...
0:00:00.010366521 29326       0xaf6500 WARN                 basesrc gstbasesrc.c:3491:gst_base_src_start_complete:<filesrc0> pad not activated yet
0:00:00.012163232 29326 0x7f63a00200f0 WARN                 qtdemux qtdemux.c:2886:qtdemux_parse_trex:<qtdemux0> failed to find fragment defaults for stream 1
0:00:00.012269707 29326 0x7f63a00200f0 WARN                 basesrc gstbasesrc.c:2400:gst_base_src_update_length:<filesrc0> processing at or past EOS
0:00:00.013142921 29326       0xaf6500 WARN                 basesrc gstbasesrc.c:3491:gst_base_src_start_complete:<filesrc1> pad not activated yet
0:00:00.013882447 29326       0x9e30f0 WARN                 qtdemux qtdemux.c:2886:qtdemux_parse_trex:<qtdemux1> failed to find fragment defaults for stream 1
0:00:00.013956282 29326       0x9e30f0 WARN                 basesrc gstbasesrc.c:2400:gst_base_src_update_length:<filesrc1> processing at or past EOS
Pipeline is PREROLLING ...
0:00:00.015247807 29326 0x7f63a0020370 FIXME               basesink gstbasesink.c:3077:gst_base_sink_default_event:<sink> stream-start event without group-id. Consider implementing group-id handling in the upstream elements
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
0:00:00.015483003 29326       0xaf6500 WARN                     bin gstbin.c:2796:gst_bin_do_latency_func:<pipeline0> did not really configure latency of 0:00:00.000000000
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:00.008565126
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

sonntex@home ~/video1 $ ls -l
total 260
-rw-r--r-- 1 sonntex sonntex  67913 Nov 18 17:32 video-chunk-00.mp4
-rw-r--r-- 1 sonntex sonntex  62051 Nov 18 17:32 video-chunk-01.mp4
-rw-r--r-- 1 sonntex sonntex 130286 Nov 18 21:29 video.mp4

sonntex@home ~/video1 $ ffprobe -show_packets video.mp4 2>&1 | tail -n 30
[PACKET]
codec_type=video
stream_index=0
pts=-161503839
pts_time=-140438.120870
dts=-161503839
dts_time=-140438.120870
duration=1
duration_time=0.000870
convergence_duration=N/A
convergence_duration_time=N/A
size=12
pos=114820
flags=_
[/PACKET]
[PACKET]
codec_type=video
stream_index=0
pts=-161503775
pts_time=-140438.065217
dts=-161503775
dts_time=-140438.065217
duration=1
duration_time=0.000870
convergence_duration=N/A
convergence_duration_time=N/A
size=12
pos=114832
flags=_
[/PACKET]

I wrote you so many logs to show that the same problem can occur in very different ways.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Jan Schmidt-6
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: How to append one mp4 file to another?

Jan Schmidt-6
On 19/11/16 05:43, sonntex wrote:

Hi,

Some comments in-line below.

> on Wed, 02 Nov 2016 09:50:31 +0200, Sebastian Dröge wrote:
>> Maybe you'd like to use the splitmuxsink element (and then splitmuxsrc)
>> for generating your files? Alternatively you will have to demux them
>> (all in one pipeline) and mux them again with (the same) mp4mux.
>
> Thank you! So, I write some chunks using splitmuxsink. Chunks are valid
> and have correct pts, pts_time, dts, dts_time, duration and
> duration_time for each packet.
>
> sonntex@home ~/video0 $ ls -l
> total 3696
> -rw-r--r-- 1 sonntex sonntex 1890215 Nov 18 16:58 video-chunk-00.mp4
> -rw-r--r-- 1 sonntex sonntex 1891161 Nov 18 16:58 video-chunk-01.mp4
>
> sonntex@home ~/video0 $ ffprobe -show_packets video-chunk-01.mp4 2>&1 |
> tail -n 30
> [PACKET]
> codec_type=video
> stream_index=0
> pts=124771
> pts_time=12.477100
> dts=124771
> dts_time=12.477100
> duration=98
> duration_time=0.009800
> convergence_duration=N/A

*snip*

>
> But result of the merge is incorrect!
>
> sonntex@home ~/video0 $ GST_DEBUG=3 gst-launch-1.0 splitmuxsrc

*snip*

> sonntex@home ~/video0 $ ls -l
> total 7372
> -rw-r--r-- 1 sonntex sonntex 1890215 Nov 18 16:58 video-chunk-00.mp4
> -rw-r--r-- 1 sonntex sonntex 1891161 Nov 18 16:58 video-chunk-01.mp4
> -rw-r--r-- 1 sonntex sonntex 3761145 Nov 18 21:20 video.mp4
>
> sonntex@home ~/video0 $ ffprobe -show_packets video.mp4 2>&1 | tail -n 30
> [PACKET]
> codec_type=video
> stream_index=0
> pts=124416
> pts_time=24.883200
> dts=124416
> dts_time=24.883200
> duration=652
> duration_time=0.130400
> convergence_duration=N/A
> convergence_duration_time=N/A
> size=10139
> pos=3734207
> flags=_
> [/PACKET]
> [PACKET]
> codec_type=video
> stream_index=0
> pts=125068
> pts_time=25.013600
> dts=125068
> dts_time=25.013600
> duration=49
> duration_time=0.009800
> convergence_duration=N/A
> convergence_duration_time=N/A
> size=10329
> pos=3744346
> flags=_
> [/PACKET]
>
> As you can see, pts, dts and duration do not correspond to pts_time,
> dts_time and duration_time.


What's happened here is that qtmux has used a timescale of 5000 when
muxing the 2nd time. The pts_time, dts_time and duration_time match
exactly if you divide the pts/dts/duration by 5000 instead of 10000. I
think what's happening is that you muxed the first time using caps of
fps=100/1, and so qtmux picked 10000 (100 Hz * 100) as a timescale. But,
I guess the mux only has 50Hz worth of captured frames in it - which
makes qtdemux probably output caps with fps=50/1, and the 2nd mux
therefore picks a timescale of 5000 (50Hz * 100).

> It is not a problem for VLC in some cases, but I have one usb camera for
> which VLCdoes not work. Chunks are also valid and have correct pts,
> pts_time, dts, dts_time, duration and duration_time for each packet.
>
> sonntex@home ~/video1 $ ls -l
> total 132
> -rw-r--r-- 1 sonntex sonntex 67913 Nov 18 17:32 video-chunk-00.mp4
> -rw-r--r-- 1 sonntex sonntex 62051 Nov 18 17:32 video-chunk-01.mp4
>
> sonntex@home ~/video1 $ ffprobe -show_packets video-chunk-01.mp4 2>&1 |
> tail -n 30
> [PACKET]
> codec_type=video
> stream_index=0
> pts=145692
> pts_time=14.569200
> dts=145692
> dts_time=14.569200
> duration=130
> duration_time=0.013000
> convergence_duration=N/A
> convergence_duration_time=N/A
> size=12
> pos=54537
> flags=_
> [/PACKET]
> [PACKET]
> codec_type=video
> stream_index=0
> pts=145822
> pts_time=14.582200
> dts=145822
> dts_time=14.582200
> duration=1
> duration_time=0.000100
> convergence_duration=N/A
> convergence_duration_time=N/A
> size=12
> pos=54549
> flags=_
> [/PACKET]
>
> Result of the merge is incorrect too! But, probably, there are overflows
> and some of the values are negative (not for each packet). It's enough
> for VLC to not play this file.


I think the overflows are the only real problem here. Would you like to
file a bug and make available a couple of input chunk files plus the
resulting broken merge and I can take more of a look at that to figure
out what calculation is overflowing where?

Cheers,
Jan.

>
> sonntex@home ~/video1 $ GST_DEBUG=3 gst-launch-1.0 splitmuxsrc
> location="video-chunk-*.mp4" ! splitmuxsink location="video.mp4"
> Setting pipeline to PAUSED ...
> 0:00:00.010366521 29326       0xaf6500 WARN                 basesrc
> gstbasesrc.c:3491:gst_base_src_start_complete:<filesrc0> pad not
> activated yet
> 0:00:00.012163232 29326 0x7f63a00200f0 WARN                 qtdemux
> qtdemux.c:2886:qtdemux_parse_trex:<qtdemux0> failed to find fragment
> defaults for stream 1
> 0:00:00.012269707 29326 0x7f63a00200f0 WARN                 basesrc
> gstbasesrc.c:2400:gst_base_src_update_length:<filesrc0> processing at or
> past EOS
> 0:00:00.013142921 29326       0xaf6500 WARN                 basesrc
> gstbasesrc.c:3491:gst_base_src_start_complete:<filesrc1> pad not
> activated yet
> 0:00:00.013882447 29326       0x9e30f0 WARN                 qtdemux
> qtdemux.c:2886:qtdemux_parse_trex:<qtdemux1> failed to find fragment
> defaults for stream 1
> 0:00:00.013956282 29326       0x9e30f0 WARN                 basesrc
> gstbasesrc.c:2400:gst_base_src_update_length:<filesrc1> processing at or
> past EOS
> Pipeline is PREROLLING ...
> 0:00:00.015247807 29326 0x7f63a0020370 FIXME               basesink
> gstbasesink.c:3077:gst_base_sink_default_event:<sink> stream-start event
> without group-id. Consider implementing group-id handling in the
> upstream elements
> Pipeline is PREROLLED ...
> Setting pipeline to PLAYING ...
> 0:00:00.015483003 29326       0xaf6500 WARN                     bin
> gstbin.c:2796:gst_bin_do_latency_func:<pipeline0> did not really
> configure latency of 0:00:00.000000000
> New clock: GstSystemClock
> Got EOS from element "pipeline0".
> Execution ended after 0:00:00.008565126
> Setting pipeline to PAUSED ...
> Setting pipeline to READY ...
> Setting pipeline to NULL ...
> Freeing pipeline ...

There's no useful information in that log at level 3.

Regards,
Jan.

> sonntex@home ~/video1 $ ls -l
> total 260
> -rw-r--r-- 1 sonntex sonntex  67913 Nov 18 17:32 video-chunk-00.mp4
> -rw-r--r-- 1 sonntex sonntex  62051 Nov 18 17:32 video-chunk-01.mp4
> -rw-r--r-- 1 sonntex sonntex 130286 Nov 18 21:29 video.mp4
>
> sonntex@home ~/video1 $ ffprobe -show_packets video.mp4 2>&1 | tail -n 30
> [PACKET]
> codec_type=video
> stream_index=0
> pts=-161503839
> pts_time=-140438.120870
> dts=-161503839
> dts_time=-140438.120870
> duration=1
> duration_time=0.000870
> convergence_duration=N/A
> convergence_duration_time=N/A
> size=12
> pos=114820
> flags=_
> [/PACKET]
> [PACKET]
> codec_type=video
> stream_index=0
> pts=-161503775
> pts_time=-140438.065217
> dts=-161503775
> dts_time=-140438.065217
> duration=1
> duration_time=0.000870
> convergence_duration=N/A
> convergence_duration_time=N/A
> size=12
> pos=114832
> flags=_
> [/PACKET]
>
> I wrote you so many logs to show that the same problem can occur in very
> different ways.
>
>
> _______________________________________________
> 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
sonntex
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: How to append one mp4 file to another?

sonntex
In reply to this post by sonntex
On Sat, 19 Nov 2016 22:38:40 +1100, Jan Schmidt wrote:

Hi!

> What's happened here is that qtmux has used a timescale of 5000 when
> muxing the 2nd time. The pts_time, dts_time and duration_time match
> exactly if you divide the pts/dts/duration by 5000 instead of 10000. I
> think what's happening is that you muxed the first time using caps of
> fps=100/1, and so qtmux picked 10000 (100 Hz * 100) as a timescale. But,
> I guess the mux only has 50Hz worth of captured frames in it - which
> makes qtdemux probably output caps with fps=50/1, and the 2nd mux
> therefore picks a timescale of 5000 (50Hz * 100).

How can I setup timescale for qtmux or mp4mux through splitmuxsink? I tried to use mp4mux and qtmux for splitmuxsink. Results are same.

> I think the overflows are the only real problem here. Would you like to
> file a bug and make available a couple of input chunk files plus the
> resulting broken merge and I can take more of a look at that to figure
> out what calculation is overflowing where?

https://bugzilla.gnome.org/show_bug.cgi?id=774716

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Free forum by Nabble Edit this page