GNOME Bugzilla – Bug 770314
oggdemux: Does not go back to beginning point on EOS when determining stream length
Last modified: 2016-09-30 07:04:17 UTC
I think this bug is closely related to ##767689. After I applied with #767689. It works well when it got the EOS event at the begging time. 0:00:01.161046371 GST_EVENT gstpad.c:5549:gst_pad_send_event_unchecked:<oggdemux0:sink> have event type segment event: 0x7fd594030010, time 99:99:99.999999999, seq-num 176, GstEventSegment, segment=(GstSegment)"GstSegment, flags=(GstSegmentFlags)GST_SEGMENT_FLAG_RESET, rate=(double)1, applied-rate=(double)1, format=(GstFormat)GST_FORMAT_BYTES, base=(guint64)0, offset=(guint64)0, start=(guint64)6578898, stop=(guint64)6644433, time=(guint64)6578898, position=(guint64)6578898, duration=(guint64)6644433;"; 0:00:01.181772860 GST_EVENT gstpad.c:5549:gst_pad_send_event_unchecked:<oggdemux0:sink> have event type eos event: 0x7fd59402ff10, time 99:99:99.999999999, seq-num 176, (NULL) 0:00:01.182334223 GST_EVENT gstpad.c:5507:gst_pad_send_event_unchecked:<oggdemux0:sink> have event type 2563 (FLUSH_START) 0:00:01.190530802 GST_EVENT gstpad.c:5549:gst_pad_send_event_unchecked:<oggdemux0:sink> have event type segment event: 0x7fd59402fea0, time 99:99:99.999999999, seq-num 220, GstEventSegment, segment=(GstSegment)"GstSegment, flags=(GstSegmentFlags)GST_SEGMENT_FLAG_RESET, rate=(double)1, applied-rate=(double)1, format=(GstFormat)GST_FORMAT_BYTES, base=(guint64)0, offset=(guint64)0, start=(guint64)1, stop=(guint64)18446744073709551615, time=(guint64)1, position=(guint64)1, duration=(guint64)6644434;"; 0:00:02.395998783 GST_EVENT gstpad.c:5549:gst_pad_send_event_unchecked:<oggdemux0:sink> have event type eos event: 0x7fd59402fe30, time 99:99:99.999999999, seq-num 220, (NULL) But the issued ogg streaming got the EOS event second time. After It got the EOS event second, It did not make pipeline normaly. I attatched the issued files and oggdemux log. I tested these files with souphttpsrc with a Queue2.
Is this a regression in git master then?
Can you explain what the problem is exactly ? EOS works fine here, with Ogg/Opus through HTTP.
@Tim No, It is not a regression. I think this issue is different issue with #767689. @Vincent Penquerc'h Ok, I attached full log and ogg file.
Where ?
I try to upload those files. But this space is limited size. So I cannot upload. @Tim Could you access this links? I upload these issue file through our Harmony system. Could you send these files to Vindent? Thanks.
@Vincent or I send this issued file to you through your e-mail. Thanks.
OK, please do that. The log file can probably be compressed well.
Created attachment 334214 [details] [review] increase EOS granpos detection chunk size
Created attachment 334215 [details] [review] safety check for not finding a valid granule in the detection chunk
This fixes playback via HTTP for this file. There was no valid granule found in the last 64 kB, and the rest of the code expected the duration to be known if seeking was not disabled.
Ok I confirmed your patch. When do you have plan to submit this code? Can you tell me about it?
I will merge it when it gets OK'd by a maintainer.
Thanks slomo :) commit 31438ef49b9bf4e4796c49f95cc33c8d4a7c0403 Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Fri Aug 26 11:30:16 2016 +0100 oggdemux: safety for failing to determine time length in push mode If we can't find a valid granule near the end of the file, we disable seeking. This guards against the whole file being then read and never going to PLAYING. https://bugzilla.gnome.org/show_bug.cgi?id=770314 commit 6f856cb54d7e628c904d2eb7a4caf77f3b2b6c79 Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Fri Aug 26 11:27:17 2016 +0100 oggdemux: increase EOS granpos detection chunk size This can be too small on some files to find a valid granule. https://bugzilla.gnome.org/show_bug.cgi?id=770314