[Bug 783842] New: [REGRESSION] encodebin: Transcoding of several media streams (to h264 in mp4) fail

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 783842
           Summary: [REGRESSION] encodebin: Transcoding of several media
                    streams (to h264 in mp4) fail
    Classification: Platform
           Product: GStreamer
           Version: 1.x
                OS: Linux
            Status: NEW
          Severity: blocker
          Priority: Normal
         Component: gst-plugins-base
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: tsaunier at gnome.org
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Since:

> commit 25e0b77bbe596b8f53497d42f3fad4e5870a6d87 (origin/master, origin/HEAD)
> Author: Arun Raghavan <arun at arunraghavan.net>
> Date:   Thu Jun 8 12:35:23 2017 +0530
>
>    encodebin: Don't try rate adjustment before the first buffer
>    
>    With both audiorate and videorate, it seems more sensible to apply rate
>    adjustments after the first buffer appears. For example, with v4l2src,
>    there is often a small delay before the first video buffer turns up, and
>    this can cause a stuttery start because of videorate trying to ensure a
>    perfect stream.

Two validate tests started to fail:

 *
validate.file.transcode.to_mp3_and_h264_in_mp4.fragmented_nonseekable_sink_mp4
 *
validate.file.transcode.to_mp3_and_h264_in_mp4.samples_multimedia_cx_asf_wmv_elephant_asf

I started to investigate
validate.file.transcode.to_mp3_and_h264_in_mp4.fragmented_nonseekable_sink_mp4,
which can simply reproduced doing:

$ gst-validate-1.0 uridecodebin
uri=file://$HOME/gst-validate/gst-integration-testsuites/medias/defaults/mp4/fragmented_nonseekable_sink.mp4
! videorate skip-to-first=true ! x264enc ! h264parse ! qtmux ! filesink
location=$HOME/test.mp4


Basically qtdemux fails because an input buffer has an invalid timestamp (the
one right after h264parse receives it SEGMENT). The pts outputed by x264enc
looks correct and h264parse sets it back to NONE. It happens because for some
reason baseparse sets the frame->buffer->pts = NONE at some point. I have not
gone further in the investigation yet, will try to go back to it later (and
want to put up my findings here to not forget :)).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.