GNOME Bugzilla – Bug 778690
qtdemux: Possible bug on gst-1.11 gst_element_seek
Last modified: 2018-11-03 15:16:32 UTC
Created attachment 345845 [details] media sample with problem. Just found an issue when using : example in code . " if (!gst_element_seek (m_gst_playbin, m_currentTrickRatio, GST_FORMAT_TIME, (GstSeekFlags)(GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_KEY_UNIT), GST_SEEK_TYPE_SET, m_last_seek_pos, GST_SEEK_TYPE_NONE, GST_CLOCK_TIME_NONE))" By some media it always jump back to media start position. (while it for that media works when using gstreamer-0.1 and same seek procedure is followed) I also tried to add the flag GST_SEEK_FLAG_SNAP_AFTER , then it jumps to so what 2/3 of the movie further (89 minutes). What is typic on the media is that for example it has a video start segment at 41711111 while the audio start segment is 0. When using flag GST_SEEK_FLAG_ACCURATE instead of KEY_UNIT it works but to slow. A media example is : I added the torrent download tracker. Note we are working on a stb so the basesink runs with sync and async false. By gst-0.1 this problem does not occur.
Note this problem also did not occured on gst version-1.8.2 has just been reported to me.
Please provide a testcase and instructions to reproduce the behaviour.
I just made a log. From the specific media start, then I did one jump which is suposed to be 6 minutes further into the movie. I have here the combined log application enigma2, stb is a GIGABLUE Quad(mips32) . gst release-1.11.1 . I added extra debug output where You can see that we asked the jump in stb pts and set the seek into nanoseconds position seek (is stb pts * 11111) is time in nanoseconds. Instead of jumping to the requested position it restarted the movie. The movie self has for video a start position of 41711111 audio 0. h264 codec and aac audio (they are all passtrough.) Log included
Created attachment 345854 [details] jump log the log is made with GST_DEBUG=*:4,bin:1 the bin does have an very ugly debug output with fixme something with cache. So intensif that it would make the log unreadable and actually to big.
actually its a requested jump off 89 seconds
Created attachment 345860 [details] jump log 5 minutes jump. actually here the jump log of 5 minutes further jump. only the jump here. But as can be seen it creates a knew segment start movie.
Ter info at this time I also can't reproduce it with the test player : gst-play-1.0 since the funktion chapter jump should we have a mkv container with chapter is not suported there, ok this last fragment is well m4v and gstreamer can't parse the chapter info by MP4 so it would not work anyway. But eventually add extra commands like for example jump of 60 seconds further in movie or 9 key 5 minutes further or so could help. I will see see if that can be added as extra function to gst-play-1.0. a couple of time jumps with keyboard keys, that simulates a bit the chapter or movie resume points.
Created attachment 345896 [details] [review] gst-player-jump patch I for test builded the very last master git of gstreamer. Then I created a jump-seek into gst-player-1.0. Now when gst-player-1.0 is running , it is only made for and tested with player in normal play mode. You can do a jump of 60 seconds with keyboard key 6 or 5 minutes with keyboard key 9. This simulates the most common used jump mode for chapter jumps or movie resume positions. And indeed with the movie sample I posted here it will always jump to start of movie. But with other movies it works. That is clearly a bug introduced in gstreamer between version 1.8.2 and the current master. By gst-1.8.2 this movie jumps fine (is reported to me by others) by gst-0.1 it also works fine. But if You use this patch You have the tools to investigate in gst-play-1.0 It is clearly not a stb related issue since it's the same on ubuntu 16.04 pc.
If I've understood all the above correctly, this is a bug that is reproducable by doing a KEY_UNIT seek in a specific MP4 file containing H.264 and AAC. The most useful debug log is probably from qtdemux via GST_DEBUG=*qtdemux*:6
Hello, Yes indeed. I self I'm bussy with main e2 player for stb's, called a bit odd servicemp3.cpp. Since on a stb we only can with sync false for video (stb does not have enough cpu power to handle the vsync on streams higher then sd resolutions) and the quit high audio queue mem (up to +60 seconds on aac audio) and up to 90 seconds by some video codecs. We must work with sync false and async false. Up on pausing media to avoid a to long wait on the state change of the pipeline we do a such seek-flush a seek based on the real playposition which is polled in the video mem by ioctl command. and audio mem for audio only media. But indeed it took me quit a while to find out why in some cases I had reports of such strange issues with a movie restart or .. And then the discovering that with gst-0.1 no problems. But now I'm happy I self have a tool to investigate some working ways or actions on ubuntu pc with last master git. I will check with qtdemux, hope that in that log can be found why it does not find a KEY_UNIT by some media , think it is related to the difference in video start segment and audio start segment. By the media I posted here we do have a video start segment of 41711111 and audio start segment off 0 .so here almost 42 ms difference. That is quit typic for a lot off HD media using h264 or h265 codecs. up to gst-1.8.2 this was no problem at all, the problem must come from some changes between 1.8.2 and the currently used master git.
p.s. how can we again launch the debug whitout colors, qtdemux 6 is to heavy but 5 ok then can be indeed seen that qtdemux does not find the key. I tried to run : to have a log instead of terminal output : GST_DEBUG=*qtdemux*:5 gst-play-1.0 Arrival720pHD.m4v 2> problem-media.txt But I must be rid of the colors how can I do that.
(In reply to christophe vr from comment #11) > p.s. how can we again launch the debug whitout colors, > > qtdemux 6 is to heavy but 5 ok then can be indeed seen that qtdemux does not > find the key. > > I tried to run : to have a log instead of terminal output : > > GST_DEBUG=*qtdemux*:5 gst-play-1.0 Arrival720pHD.m4v 2> problem-media.txt > > But I must be rid of the colors how can I do that. GST_DEBUG_NO_COLOR=1
Thanks , in the mean time I used --gst-debug-no-color worked also (I made a mistake with that by using the one I used on stb for e2 whitout color) sorry not used to debug gstreamer on pc.
Well I tried to make a log so short as possible on the media. media start once it runs ok direct a jump of 5 minutes forward once it played again (here with problem media it back to movie start) quit the gst-player. But the log is still 305 Mb of size. It can't be opened with reqular gedit or so to big. But think with vim in terminal it should work. Sin even copmpressed it is 29 Mb I can post it here but I put it on my drop box here the link. Looks like the qtdemux has a general problem with indexing. for such media type. So it will be quit common by a lot of HD media using h264 I gues. link : https://www.dropbox.com/s/2k66nu89gcbzj3u/problem-media-log.tar.bz2?dl=1
Created attachment 345933 [details] problem-media-just-start Hi improved the debug. first just the start log of media only until playing in debug5 for stdemux. And here the link of just a single jump from request till the media instead of jumping restarted. This is stil big but now around 64 mb so You can already work with it en emacds and even gedit. https://www.dropbox.com/s/h5m1dc3aeftafxs/problem-media-just-jump-log.tar.gz?dl=1 the jump is one for 60 seconds which I requested.
I raised the level from normal to major, Since it breaks the use of a lot off players installed on devices who all use the GST_SEEK_FLAG_KEY_UNIT and need to do that. cause GST_SEEK_FLAG_ACCURATE is far to slow and cpu intensif for such devices. At least for hd media with several audio tracks sub tracks.
Is it not time to change this bug into something else then need info ? It is a very severe one and : !!!!! It was NEVER PRESENT ON gst VERSION UP TO 1.8.2 then it started. I give really all you need + extra tools that every developer can test self with gst-play-1.0 . More I can't do . But that NEED INFO NOW IS REALLY WRONG and the bug IS REALLY MAJOR (not critical since there is no crash , but seeing the logs self we are on the edge of a sever crash)
As last This bug maybe not critical cause it does not crash the application and or device. But it is 100 % critical up on use off any gstreamer version above 1.8.2 the day a stb image or any application based on gstreamer is going from beta to final release phase. It is very very high in importance to solve this asap (so important it had to be solved yesterday) So i'm very very insulted that this bug is still on need info while I proved by 100 % it is true and a very very very severe bug
Sorry but just cause the state in the mean time is still at info, While more info as what I did can't be provided, but the info i give is 100 % true and it proves by 100 % that there is a severe bug into gstreamer which came up between version 1.8.2 and the current master it is still present I raised the level to critical. Quit simple a gstreamer versions which can't make a jump like it always has done in the past is a unusable version. The last descent gstreamer version is 1.8.2 concerning file media. off course we then again face the problem that hls media almost does not work. So yes I think I'm loosing my time in e2 images off stb's as gstreamer is has very severe problems overall. In gst 1.8.2 the hls hardly works in gst1.11.1 the hls is ok but you can not jump anymore with GST_SEEK_FLAG_KEY_UNIT so ... unusable gstreamer version . **** WE ARE FACING A CRITICAL BUG IN GSTREAMER ***** !!!!!!! and developers do nothing else then saying need info ??????
Well still no answer , ? Do not make a effort anymore, I'll give up on gstreamer (like several persons already told me since long its' true the gstreamer team makes bug on bug and does only react with need info on every descent 100 % good documented and explained report) I indeed like they advised me since long will more study the use off ffmpeg. Since the fact that this very severe report and true facts extremely high documented and proved , causes the idiot reaction NEEDINFO ????? wel sorry but on any version of gst 1.8.2 and below all media can handle this seek. Inclusive the media I posted over here. I Also posted the tools since Mister Sebastian asked instruction to reproduce, .... all this is done, and still ...... NOOP As long this VERY VERY SEVERE BUG is not solved it does not make ANY ANY sence to make an application using gstreamer as it always will suck on seek . Sorry I was one of the biggest defenders of gstreamer in e2 but unfortunately this extreme poor reaction on the bug report more documented and proved then many others but it is a very very very critical issue in e2 and it will anyway show up on the majority of devices in future is just a 100% NO GO for gstreamer. And should have been solved yesterday. So yes finally merge to ffmpeg becomes a considerable option as long as such a extremely important seek can't be done GST_SEEK_FLAG_KEY_UNIT . And yes all other work should be suspend until this issue is solved so important it is. It is just simply break down of main working off gst .
Again no answer for such a very extreme bug. Note that the majority of devices do use a gstreamer version up or far below 1.8.2 and they DO NOT HAVE THIS VERY SEVERE ISSUE . So the day they upgrade for example media resume will be broken by 100 % (for such media which worked very well on gst-0.1 and ok til 1.8.2 !!!) Good luck in explaining why ...... without lies.
You do realize that what you get here is free support by volunteers in their spare time? If this issue is very urgent for you, all the source code is available for you to solve the problem yourself or you could contract someone to solve it for you, in which case you can demand some fast response times (depending on your actual contract then). If you think your problems are important enough for myself or someone else to immediately (or at all) spend their spare time on it, may I ask you to come over and solve some things I wanted to get done in my apartment? No? Then reconsider your tone in the future, why do you think you're entitled to someone else's time? Are you sitting all day in front of your computer and just waiting to jump on some problem some random stranger on the Internet is sending your way? I'm sure there's something broken here. But there are lots of other bugs in Bugzilla that are equally important for whoever reported them as this specific one is for you. Help to get some out of the way, fewer bugs means it's more likely that someone gets interested in fixing yours. Considering your behaviour so far you can however be glad if someone ever wants to spend time on anything you report. Nonetheless I'm marking this bug as "NEW" again, you provided the information that was asked for but I (and apparently nobody else) did get to that since you provided that info.
I think the problem with this stream is that qtdemux snaps the seek using the earliest keyframe of all the streams, which ends up being time 0 because it contains text subtitles. The packets for those should probably be treated as all keyframes, or else subtitle streams should be ignored entirely for the purposes of key-unit seeks. I'm not sure why that's different to 1.8, but there were changes around how the key-unit snapping is calculated in qtdemux so it's probably in there.
My commit 107902ec is the root cause. That commit attempts to make sure that a snapping seek actually starts at the start of a keyframe instead of in the middle of one, but doesn't cope when streams are sparse or (as in this stream) there's a track with a single JPEG image cover art "keyframe" that starts at time 0 and covers the whole stream. Revert 107902ec in gst-plugins-good for a workaround.
commit 488e8edba4527d7e8da9b45a42ffd3927f7ac449 Author: Jan Schmidt <jan@centricular.com> Date: Fri Feb 17 13:07:05 2017 +1100 Revert "qtdemux: Always snap to the start of the keyframe" This reverts commit 107902ec514bd826aa29d2298107e2c091e1c779. This commit intended to ensure that keyframe seeks land at the start timestamp of a keyframe, rather than in the middle of one, but they cause trouble on files with sparse streams, or with JPEG 'cover art' tracks that have only one or a few JPEG samples with very long durations. That's still desirable for doing seamless cutting of videos, but needs a rethink for implementation. https://bugzilla.gnome.org/show_bug.cgi?id=778690 Leaving the bug open, because just reverting that commit breaks the seamless cutting use case.
Review of attachment 345896 [details] [review]: Please !! don't panic !!, I am just marking this patch, which purpose if for testing, so we don't confuse it with patches to be reviewed and merged. Though, if you feel like fixing this regression, this is the right way to submit patch.
Christophe, you posted EIGHTEEN comments within the span of a day, some of them offensive. Developers have a life too. This is not a chat room, and you're not paying them on a support contract to answer your issues within the hour. What you're doing here is *harassment*. Stop that and be respectful in the future, or I'm pretty sure you will get banned. Premier et dernier avertissement.
(In reply to Jean-François Fortin Tam from comment #27) > Christophe, you posted EIGHTEEN comments within the span of a day, some of > them offensive. Developers have a life too. This is not a chat room, and > you're not paying them on a support contract to answer your issues within > the hour. What you're doing here is *harassment*. Stop that and be > respectful in the future, or I'm pretty sure you will get banned. Premier et > dernier avertissement. Ok I did go to far on some points, but only 5 of the messages (this even does not approach you're 18) are of the type which could be considered as spam. And yes I do present my a apologies for it more I can't, I was wrong impatient and unfortunately was so occupied with this issue that I could not sleep and posted this after having spend over 48 hours non stop behind a keyboard. I'll anyway will watch out to not post anything when I'm to tired. But for the rest this bug report is a more then standard issue, it is really a severe one.
(In reply to Jan Schmidt from comment #25) > commit 488e8edba4527d7e8da9b45a42ffd3927f7ac449 > Author: Jan Schmidt <jan@centricular.com> > Date: Fri Feb 17 13:07:05 2017 +1100 > > Revert "qtdemux: Always snap to the start of the keyframe" > > This reverts commit 107902ec514bd826aa29d2298107e2c091e1c779. > > This commit intended to ensure that keyframe seeks land at the > start timestamp of a keyframe, rather than in the middle of one, > but they cause trouble on files with sparse streams, or with > JPEG 'cover art' tracks that have only one or a few JPEG samples > with very long durations. > > That's still desirable for doing seamless cutting of videos, > but needs a rethink for implementation. > > https://bugzilla.gnome.org/show_bug.cgi?id=778690 > > Leaving the bug open, because just reverting that commit breaks the seamless > cutting use case. I've investigated further, indeed it is not easy to solve here. But Yes if a media sample does have a image/ codec track that image codec track is like it told and in some cases is one single image one buffer and yes does only have one key-unit holder which covers so what the whole media length. Perhaps limit the keyframe seek only to the real audio:video tracks could solve. The audio/video needs somehow to be threaded together (at last the active ones) think about for example dts audio does have two key frames for one video key frame (or perhaps the opposed). Also think it's best to exclude the subtitles complete from this key-unit seek, there as well we do have key units which may differ from the one by video or audio. It is even possible to have a pts on a srt sub which needs algnement on frame 2 off the three frames some h264 may contain. for one pts. But well do a kind of async seek on the subtitle which after all is an overlay.
-- 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/347.