GNOME Bugzilla – Bug 788777
rtpjitterbuffer/h264parse timestamp issue (regression)
Last modified: 2018-11-03 15:23:00 UTC
Created attachment 361248 [details] logs that show the issue In a pipeline like this: rtspsrc ! rtph264depay ! h264parse ! ... using rtsp over tcp can happen that rtspsrc outputs buffers with the same timestamp, when this happen h264parse outputs buffer with invalid timestamps. Please take a look at the attached logs, you can see: rtpjitterbuffer.c:916:rtp_jitter_buffer_calculate_pts:[00m backwards timestamps, using previous time so different buffers with pts 0:15:23.020362975 are sended. Not sure how to handle this case, we need to change rtpjitterbuffer or h264parse? This problem seems to happen only using rtsp over tcp, I'm unable to reproduce it using rtsp over udp.
this problem does not happen in 1.6 branch, while I can reproduce it in 1.12 and git master, the main difference seems that in 1.6 when a backward timestamp is detected a resync is scheduled, while in 1.12 the previous timestamp is used, tomorrow I'll do some other tests to better understand the different behaviour
Do you have a pcap capture or so to reproduce the issue?
It seems to happen with any rtsp camera, here is a capture from an axis one (that use gst-rtsp-server) http://94.177.162.225/temp/788777_full.pcapng please look at the end of the capture between timestamp 664022331083 and 664048333625 and between timestamp 670648340011 and 670127771194 thanks!
this regression start to happen with 1.10, I'm now trying to identify the commit
this is the commit that introduce the regression https://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?h=1.10&id=5db8ce66d0d6d426b8406d651238381217006eda
One thing that jumps out from the logs is the lack of dts on the buffer. pop_and_push_next:<rtpjitterbuffer0>[00m Pushing buffer 49694, dts 99:99:99.999999999, pts 0:15:23.020362975 Now, udpsrc sets dts as "arrival time" and the jitterbuffer sort of assumes this being the arrival time, and calculates the pts. Maybe there are some improvements that could be done in terms of dts being CLOCK_TIME_NONE? Alternatively, maybe the tcpsrc should be setting dts in the same way udpsrc does it.
Over TCP it works intentionally like that. TCP is not very regular with packet arrival times, things arrive in batches usually due to how TCP works and buffering everywhere along the path. With TCP the idea is that the first buffer has timestamps, and from then on we simply interpolate based on the RTP timestamps.
Maybe we even could use the arrival time in the jitterbuffer as "dts" when dts is -1? @Nicola: you feel like getting down and dirty with the jitterbuffer-tests? A quick scan reveals that we indeed have no tests that pass in -1 (GST_CLOCK_TIME_NONE) as dts, so you could write a simple test that: 1. Pushes some buffers with dts set to GST_CLOCK_TIME_NONE (generate_test_buffer_full) 2. Increments the time on the clock (with, say, 20ms), for each buffer pushed, simulating that the buffers are arriving at appropriate times. 3. Verifies that the output pts on the buffers are indeed incrementing (which they might not be now)
(In reply to Håvard Graff (hgr) from comment #8) > Maybe we even could use the arrival time in the jitterbuffer as "dts" when > dts is -1? > > @Nicola: you feel like getting down and dirty with the jitterbuffer-tests? A > quick scan reveals that we indeed have no tests that pass in -1 > (GST_CLOCK_TIME_NONE) as dts, so you could write a simple test that: > > 1. Pushes some buffers with dts set to GST_CLOCK_TIME_NONE > (generate_test_buffer_full) > 2. Increments the time on the clock (with, say, 20ms), for each buffer > pushed, simulating that the buffers are arriving at appropriate times. > 3. Verifies that the output pts on the buffers are indeed incrementing > (which they might not be now) Sorry for the delay, I'll try to write a test case, probably I can find some spare time the next week, but I don't think will be easy, the problem does not happen for each buffer but happens randomically (probably when the camera burst data), 10-15 buffers are sended with the same timestamp and after that the stream works normally for 10-15 minutes and so on
I did some quick experiments, the point is to generate something that triggers the condition here: https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtpmanager/rtpjitterbuffer.c#n907 for example: for (b = 1; b < 5; b++) { gst_harness_set_time (h, 10 * GST_SECOND + 20 * GST_MSECOND * b); if (b < 2){ fail_unless_equals_int (GST_FLOW_OK, gst_harness_push (h, generate_test_buffer_full (-1, b, b * TEST_RTP_TS_DURATION))); } else { fail_unless_equals_int (GST_FLOW_OK, gst_harness_push (h, generate_test_buffer_full (-1, b, (b-1) * TEST_RTP_TS_DURATION))); } } so the buffer pushed when b = 1 and b = 2 will have the same timestamp the real logs shows that one of the other conditions was met. I'm a bit busy these days hope this is enough
Nicola, any news on this? Can you provide a patch against the existing jitterbuffer tests to show this problem? Also is it still a problem with latest GIT? Håvard, any ideas what to do about this one? Your commit introduced it back then :)
(In reply to Sebastian Dröge (slomo) from comment #11) > Håvard, any ideas what to do about this one? Your commit introduced it back > then :) If there is a failing test-case I am happy to take a look. I guess the hardest bit here is to decide what is the correct behavior in this case, and a well written test can provide that. And for the record: My commit fixed a regression introduced in 1.x with mixing dts and pts for lost-events, back in 0.10 this was done correctly since there was only one timestamp. :)
Ok so will have to wait until after 1.14 then :)
I've hit what I think is this bug trying to do rtsp streaming from an IP camera. For example: $ gst-launch-1.0 --gst-debug-level=2 uridecodebin uri="rtsp://xxx" caps="video/x-h264" ! h264parse ! mp4mux ! filesink location=test.mp4 Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Progress: (open) Opening Stream Progress: (connect) Connecting to rtspu://10.23.67.76/user=admin&password=&channel=1&stream=0.sdp?real_stream Progress: (open) Retrieving server options Progress: (open) Retrieving media info Progress: (request) SETUP stream 0 Progress: (open) Opened Stream Setting pipeline to PLAYING ... New clock: GstSystemClock Progress: (request) Sending PLAY request Progress: (request) Sending PLAY request Progress: (request) Sent PLAY request 0:00:02.155699947 19264 0x7f1fe4003630 WARN qtmux gstqtmux.c:4553:gst_qt_mux_add_buffer:<mp4mux0> error: Buffer has no PTS. ERROR: from element /GstPipeline:pipeline0/GstMP4Mux:mp4mux0: Could not multiplex stream. Additional debug info: gstqtmux.c(4553): gst_qt_mux_add_buffer (): /GstPipeline:pipeline0/GstMP4Mux:mp4mux0: Buffer has no PTS. Execution ended after 0:00:02.061331145 Setting pipeline to PAUSED ... Setting pipeline to READY ... 0:00:02.156376777 19264 0x55a03c547370 WARN rtspsrc gstrtspsrc.c:5915:gst_rtsp_src_receive_response:<source> receive interrupted 0:00:02.156393147 19264 0x55a03c547370 WARN rtspsrc gstrtspsrc.c:8242:gst_rtspsrc_pause:<source> PAUSE interrupted Setting pipeline to NULL ... Freeing pipeline ... Using matroskamux instead of mp4mux appears to work but only because instead of failing it creates a file without any I-frames: $ gst-launch-1.0 --gst-debug-level=2 uridecodebin uri="rtsp://xxx" caps="video/x-h264" ! h264parse ! matroskamux ! filesink location=test.mp4 Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Progress: (open) Opening Stream Progress: (connect) Connecting to rtspu://10.23.67.76/user=admin&password=&channel=1&stream=0.sdp?real_stream Progress: (open) Retrieving server options Progress: (open) Retrieving media info Progress: (request) SETUP stream 0 Progress: (open) Opened Stream Setting pipeline to PLAYING ... New clock: GstSystemClock Progress: (request) Sending PLAY request Progress: (request) Sending PLAY request Progress: (request) Sent PLAY request 0:00:02.176154384 19308 0x7fad98003f70 WARN matroskamux matroska-mux.c:3685:gst_matroska_mux_write_data:<matroskamux0:video_0> Invalid buffer timestamp; dropping buffer 0:00:02.181343483 19308 0x7fad98003f70 WARN matroskamux matroska-mux.c:3685:gst_matroska_mux_write_data:<matroskamux0:video_0> Invalid buffer timestamp; dropping buffer 0:00:04.182640326 19308 0x7fad98003f70 WARN matroskamux matroska-mux.c:3685:gst_matroska_mux_write_data:<matroskamux0:video_0> Invalid buffer timestamp; dropping buffer 0:00:06.180916572 19308 0x7fad98003f70 WARN matroskamux matroska-mux.c:3685:gst_matroska_mux_write_data:<matroskamux0:video_0> Invalid buffer timestamp; dropping buffer 0:00:08.181572733 19308 0x7fad98003f70 WARN matroskamux matroska-mux.c:3685:gst_matroska_mux_write_data:<matroskamux0:video_0> Invalid buffer timestamp; dropping buffer 0:00:10.181878193 19308 0x7fad98003f70 WARN matroskamux matroska-mux.c:3685:gst_matroska_mux_write_data:<matroskamux0:video_0> Invalid buffer timestamp; dropping buffer (...) I added a probe to the h264parser src and it seems that all the I-frames end up with broken pts values (each line is a buffer): flags: DISCONT | HEADER | DELTA_UNIT pts 00:00:00.130488980 dts 00:00:00.132701175 flags: (empty) pts 99:99:99.999999999 dts 00:00:00.144599571 flags: DELTA_UNIT pts 00:00:00.170488896 dts 00:00:00.172938726 flags: DELTA_UNIT pts 00:00:00.210488559 dts 00:00:00.212886204 flags: DELTA_UNIT pts 00:00:00.250487801 dts 00:00:00.252749559 flags: DELTA_UNIT pts 00:00:00.290486458 dts 00:00:00.292753600 flags: DELTA_UNIT pts 00:00:00.330484373 dts 00:00:00.332698810 flags: DELTA_UNIT pts 00:00:00.370481400 dts 00:00:00.373815622 flags: DELTA_UNIT pts 00:00:00.410477411 dts 00:00:00.412160732 flags: DELTA_UNIT pts 00:00:00.450472303 dts 00:00:00.452277058 flags: DELTA_UNIT pts 00:00:00.490466004 dts 00:00:00.492262089 flags: DELTA_UNIT pts 00:00:00.530458479 dts 00:00:00.532317524 flags: DELTA_UNIT pts 00:00:00.570449738 dts 00:00:00.572483015 flags: DELTA_UNIT pts 00:00:00.610439839 dts 00:00:00.612719141 flags: DELTA_UNIT pts 00:00:00.650428891 dts 00:00:00.652659546 flags: DELTA_UNIT pts 00:00:00.690417052 dts 00:00:00.692286976 flags: DELTA_UNIT pts 00:00:00.730404526 dts 00:00:00.732778163 flags: DELTA_UNIT pts 00:00:00.770391557 dts 00:00:00.772393936 flags: DELTA_UNIT pts 00:00:00.810378416 dts 00:00:00.812636200 flags: DELTA_UNIT pts 00:00:00.850365386 dts 00:00:00.852443918 flags: DELTA_UNIT pts 00:00:00.890352749 dts 00:00:00.893038377 flags: DELTA_UNIT pts 00:00:00.930340769 dts 00:00:00.932568091 flags: DELTA_UNIT pts 00:00:00.970315534 dts 00:00:00.972372486 flags: DELTA_UNIT pts 00:00:01.010292724 dts 00:00:01.012433147 flags: DELTA_UNIT pts 00:00:01.050272620 dts 00:00:01.052350431 flags: DELTA_UNIT pts 00:00:01.090255361 dts 00:00:01.092344823 flags: DELTA_UNIT pts 00:00:01.130240949 dts 00:00:01.132636784 flags: DELTA_UNIT pts 00:00:01.170229258 dts 00:00:01.172454366 flags: DELTA_UNIT pts 00:00:01.210220059 dts 00:00:01.213108059 flags: DELTA_UNIT pts 00:00:01.250213051 dts 00:00:01.253091072 flags: DELTA_UNIT pts 00:00:01.290207891 dts 00:00:01.292905405 flags: DELTA_UNIT pts 00:00:01.330204227 dts 00:00:01.333063222 flags: DELTA_UNIT pts 00:00:01.370201723 dts 00:00:01.372836432 flags: DELTA_UNIT pts 00:00:01.410200080 dts 00:00:01.412488087 flags: DELTA_UNIT pts 00:00:01.450199049 dts 00:00:01.452409799 flags: DELTA_UNIT pts 00:00:01.490198431 dts 00:00:01.492800029 flags: DELTA_UNIT pts 00:00:01.530198079 dts 00:00:01.532800996 flags: DELTA_UNIT pts 00:00:01.570197889 dts 00:00:01.573130835 flags: DELTA_UNIT pts 00:00:01.610197792 dts 00:00:01.612535500 flags: DELTA_UNIT pts 00:00:01.650197746 dts 00:00:01.655823246 flags: DELTA_UNIT pts 00:00:01.690197725 dts 00:00:01.692281451 flags: DELTA_UNIT pts 00:00:01.730197717 dts 00:00:01.732738014 flags: DELTA_UNIT pts 00:00:01.770197713 dts 00:00:01.772335278 flags: DELTA_UNIT pts 00:00:01.810197712 dts 00:00:01.812399785 flags: DELTA_UNIT pts 00:00:01.850197712 dts 00:00:01.852435838 flags: DELTA_UNIT pts 00:00:01.890197712 dts 00:00:01.893547681 flags: DELTA_UNIT pts 00:00:01.930197712 dts 00:00:01.932689090 flags: DELTA_UNIT pts 00:00:01.970197712 dts 00:00:01.972465099 flags: DELTA_UNIT pts 00:00:02.010197712 dts 00:00:02.012648985 flags: DELTA_UNIT pts 00:00:02.050197712 dts 00:00:02.053152003 flags: DELTA_UNIT pts 00:00:02.090197712 dts 00:00:02.093963961 flags: HEADER | DELTA_UNIT pts 00:00:02.130197711 dts 00:00:02.130642509 flags: (empty) pts 99:99:99.999999999 dts 00:00:02.144220304 flags: DELTA_UNIT pts 00:00:02.170197711 dts 00:00:02.172837551 (...) I found a workaround (that I haven't yet figured out how to enable in the rust bindings) which is to do set_pts_interpolation(h264parser, true). That seems to fix the issue. I haven't bee able to grab a raw rtp or h264 stream to a file that I can then reproduce this at will from. Let me know what kind of extra information would help. If any one the gstreamer developers wants one of these cameras to test I can also have it shipped to you. There seems to be a recent wave of cheap 2-4MP cameras with h264 (and supposedly h265 as well). They're probably all using the same encoder chips so this is likely to be a common issue.
Thanks to Sebastian I've been able to enable interpolation in the rust code. Here's the result: flags: DISCONT | HEADER | DELTA_UNIT pts 00:00:00.261462431 dts 00:00:00.263152518 flags: (empty) pts 00:00:00.274878421 dts 00:00:00.274878421 flags: DELTA_UNIT pts 00:00:00.301462431 dts 00:00:00.304715236 flags: DELTA_UNIT pts 00:00:00.341462431 dts 00:00:00.343545874 flags: DELTA_UNIT pts 00:00:00.381462431 dts 00:00:00.383407293 flags: DELTA_UNIT pts 00:00:00.421462431 dts 00:00:00.423277810 flags: DELTA_UNIT pts 00:00:00.461462431 dts 00:00:00.463337810 flags: DELTA_UNIT pts 00:00:00.501462431 dts 00:00:00.503497098 flags: DELTA_UNIT pts 00:00:00.541462431 dts 00:00:00.547031050 flags: DELTA_UNIT pts 00:00:00.581462431 dts 00:00:00.583345253 flags: DELTA_UNIT pts 00:00:00.621462431 dts 00:00:00.623342326 flags: DELTA_UNIT pts 00:00:00.661462431 dts 00:00:00.663315179 flags: DELTA_UNIT pts 00:00:00.701462431 dts 00:00:00.703462505 flags: DELTA_UNIT pts 00:00:00.741462431 dts 00:00:00.743970603 flags: DELTA_UNIT pts 00:00:00.781462431 dts 00:00:00.783335348 flags: DELTA_UNIT pts 00:00:00.821462431 dts 00:00:00.823293648 flags: DELTA_UNIT pts 00:00:00.861462431 dts 00:00:00.863326481 flags: DELTA_UNIT pts 00:00:00.901462431 dts 00:00:00.903385915 flags: DELTA_UNIT pts 00:00:00.941462431 dts 00:00:00.943352480 flags: DELTA_UNIT pts 00:00:00.981462431 dts 00:00:00.983493392 flags: DELTA_UNIT pts 00:00:01.021462431 dts 00:00:01.023313135 flags: DELTA_UNIT pts 00:00:01.061462431 dts 00:00:01.063276491 flags: DELTA_UNIT pts 00:00:01.101462431 dts 00:00:01.103391895 flags: DELTA_UNIT pts 00:00:01.141462431 dts 00:00:01.143395879 flags: DELTA_UNIT pts 00:00:01.181462431 dts 00:00:01.183290100 flags: DELTA_UNIT pts 00:00:01.221462431 dts 00:00:01.223348690 flags: DELTA_UNIT pts 00:00:01.261462431 dts 00:00:01.263373463 flags: DELTA_UNIT pts 00:00:01.301462431 dts 00:00:01.304241082 flags: DELTA_UNIT pts 00:00:01.341462431 dts 00:00:01.343400175 flags: DELTA_UNIT pts 00:00:01.381462431 dts 00:00:01.383383311 flags: DELTA_UNIT pts 00:00:01.421462431 dts 00:00:01.423801744 flags: DELTA_UNIT pts 00:00:01.461462431 dts 00:00:01.463330093 flags: DELTA_UNIT pts 00:00:01.501462431 dts 00:00:01.503430315 flags: DELTA_UNIT pts 00:00:01.541462431 dts 00:00:01.543366482 flags: DELTA_UNIT pts 00:00:01.581462431 dts 00:00:01.584078245 flags: DELTA_UNIT pts 00:00:01.621462431 dts 00:00:01.623450738 flags: DELTA_UNIT pts 00:00:01.661462431 dts 00:00:01.663463921 flags: DELTA_UNIT pts 00:00:01.701462431 dts 00:00:01.703523269 flags: DELTA_UNIT pts 00:00:01.741462431 dts 00:00:01.743462150 flags: DELTA_UNIT pts 00:00:01.781462431 dts 00:00:01.783394769 flags: DELTA_UNIT pts 00:00:01.821462431 dts 00:00:01.823449308 flags: DELTA_UNIT pts 00:00:01.861462431 dts 00:00:01.863591417 flags: DELTA_UNIT pts 00:00:01.901462431 dts 00:00:01.903516378 flags: DELTA_UNIT pts 00:00:01.941462431 dts 00:00:01.943498889 flags: DELTA_UNIT pts 00:00:01.981462431 dts 00:00:01.983434396 flags: DELTA_UNIT pts 00:00:02.021462431 dts 00:00:02.023455491 flags: DELTA_UNIT pts 00:00:02.061462431 dts 00:00:02.063458245 flags: DELTA_UNIT pts 00:00:02.101462431 dts 00:00:02.103519384 flags: DELTA_UNIT pts 00:00:02.141462431 dts 00:00:02.143711913 flags: DELTA_UNIT pts 00:00:02.181462431 dts 00:00:02.183479301 flags: DELTA_UNIT pts 00:00:02.221462431 dts 00:00:02.224441922 flags: HEADER | DELTA_UNIT pts 00:00:02.261462431 dts 00:00:02.261688725 flags: (empty) pts 00:00:02.281857150 dts 00:00:02.281857150 flags: DELTA_UNIT pts 00:00:02.301463400 dts 00:00:02.305059963 flags: DELTA_UNIT pts 00:00:02.341464362 dts 00:00:02.343595702 flags: DELTA_UNIT pts 00:00:02.381465316 dts 00:00:02.383605776 flags: DELTA_UNIT pts 00:00:02.421466262 dts 00:00:02.424238691 flags: DELTA_UNIT pts 00:00:02.461467201 dts 00:00:02.463484227 flags: DELTA_UNIT pts 00:00:02.501468132 dts 00:00:02.503617245 flags: DELTA_UNIT pts 00:00:02.541469056 dts 00:00:02.543589840 flags: DELTA_UNIT pts 00:00:02.581469972 dts 00:00:02.583406674 flags: DELTA_UNIT pts 00:00:02.621470881 dts 00:00:02.623393752 flags: DELTA_UNIT pts 00:00:02.661471783 dts 00:00:02.663436755 flags: DELTA_UNIT pts 00:00:02.701472678 dts 00:00:02.703473183 flags: DELTA_UNIT pts 00:00:02.741473565 dts 00:00:02.743609305 flags: DELTA_UNIT pts 00:00:02.781474445 dts 00:00:02.783423319 flags: DELTA_UNIT pts 00:00:02.821475318 dts 00:00:02.823385178 flags: DELTA_UNIT pts 00:00:02.861476184 dts 00:00:02.863378073 flags: DELTA_UNIT pts 00:00:02.901477043 dts 00:00:02.903474673 flags: DELTA_UNIT pts 00:00:02.941477896 dts 00:00:02.943363251 flags: DELTA_UNIT pts 00:00:02.981478742 dts 00:00:02.983381692 flags: DELTA_UNIT pts 00:00:03.021479581 dts 00:00:03.023401156 flags: DELTA_UNIT pts 00:00:03.061480413 dts 00:00:03.063378192 flags: DELTA_UNIT pts 00:00:03.101481239 dts 00:00:03.103433214 flags: DELTA_UNIT pts 00:00:03.141482058 dts 00:00:03.143495895 flags: DELTA_UNIT pts 00:00:03.181482870 dts 00:00:03.183510019 flags: DELTA_UNIT pts 00:00:03.221483676 dts 00:00:03.223407398 flags: DELTA_UNIT pts 00:00:03.261484475 dts 00:00:03.263987352 flags: DELTA_UNIT pts 00:00:03.301485268 dts 00:00:03.304303148 flags: DELTA_UNIT pts 00:00:03.341486055 dts 00:00:03.343456637 flags: DELTA_UNIT pts 00:00:03.381486835 dts 00:00:03.383475190 flags: DELTA_UNIT pts 00:00:03.421487609 dts 00:00:03.423318451 flags: DELTA_UNIT pts 00:00:03.461488377 dts 00:00:03.463354330 flags: DELTA_UNIT pts 00:00:03.501489139 dts 00:00:03.503489793 flags: DELTA_UNIT pts 00:00:03.541489895 dts 00:00:03.543482092 flags: DELTA_UNIT pts 00:00:03.581490645 dts 00:00:03.583399527 flags: DELTA_UNIT pts 00:00:03.621491389 dts 00:00:03.624278414 flags: DELTA_UNIT pts 00:00:03.661492127 dts 00:00:03.663512520 flags: DELTA_UNIT pts 00:00:03.701492859 dts 00:00:03.703616479 flags: DELTA_UNIT pts 00:00:03.741493585 dts 00:00:03.743561367 flags: DELTA_UNIT pts 00:00:03.781494305 dts 00:00:03.783531420 flags: DELTA_UNIT pts 00:00:03.821495019 dts 00:00:03.823463372 flags: DELTA_UNIT pts 00:00:03.861495728 dts 00:00:03.863532045 flags: DELTA_UNIT pts 00:00:03.901496431 dts 00:00:03.903624667 flags: DELTA_UNIT pts 00:00:03.941497128 dts 00:00:03.943561047 flags: DELTA_UNIT pts 00:00:03.981497820 dts 00:00:03.983542823 flags: DELTA_UNIT pts 00:00:04.021498506 dts 00:00:04.023509947 flags: DELTA_UNIT pts 00:00:04.061499187 dts 00:00:04.063684982 flags: DELTA_UNIT pts 00:00:04.101499862 dts 00:00:04.104242408 flags: DELTA_UNIT pts 00:00:04.141500532 dts 00:00:04.143758055 flags: DELTA_UNIT pts 00:00:04.181501197 dts 00:00:04.183498000 flags: DELTA_UNIT pts 00:00:04.221501856 dts 00:00:04.224864948 flags: HEADER | DELTA_UNIT pts 00:00:04.261502510 dts 00:00:04.261748079 flags: (empty) pts 00:00:04.275363628 dts 00:00:04.275363628 (...) Seems like interpolation just sets pts=dts. The end result is a fully playable file with apparently no issues.
Although the end result is a playable file it seems there are still some issues. matroskamux generates a playable file with errors: $ vlc test.mkv VLC media player 3.0.2 Vetinari (revision 3.0.2-0-gd7b653cf14) [h264 @ 0x7fd7ccc35320] no frame! [h264 @ 0x7fd7ccc47040] no frame! [h264 @ 0x7fd7ccc8cdc0] no frame! [h264 @ 0x7fd7ccca8fe0] no frame! [h264 @ 0x7fd7cccc52e0] no frame! [h264 @ 0x7fd7ccc35320] no frame! [h264 @ 0x7fd7ccc47040] no frame! [h264 @ 0x7fd7ccc8cdc0] no frame! [h264 @ 0x7fd7ccca8fe0] no frame! (end of stream) But with mp4mux the file is broken: $ vlc test.mp4 VLC media player 3.0.2 Vetinari (revision 3.0.2-0-gd7b653cf14) [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fa7b8c5ed60] moov atom not found [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fa770c12060] moov atom not found [00007fa770c18260] avformat demux error: Could not open /home/pedrocr/data/core/Projects/vsurv/test.mp4: Unknown error 1094995529 Let me know if there's anything else I can provide or if this is actually a different bug and I'll open a new one.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/410.