[Bug 731352] flv: Container timestamp is DTS not PTS

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Thu Aug 28 10:16:30 PDT 2014


https://bugzilla.gnome.org/show_bug.cgi?id=731352
  GStreamer | gst-plugins-good | git

--- Comment #12 from Peter Maersk-Moller <pmaersk at gmail.com> 2014-08-28 17:16:26 UTC ---
Hi Nicolas

(In reply to comment #6)
> I've tested these changes on top of 1.5 with live Youtube, and it works for me.
> It is likely that the recent timestamp changes to x264 enc were needed.
> 
> gst-launch-1.0 \
>     videotestsrc is-live=1 \
>         ! video/x-raw,width=1280,height=720,framerate=30/1 \
>         ! timeoverlay \
>         ! x264enc bitrate=2000 ! video/x-h264,profile=main \ 
>       ! queue ! mux. \
>     audiotestsrc is-live=1 wave=12 ! faac ! queue ! mux. \
>     flvmux streamable=1 name=mux  \ 
>       ! rtmpsink location="rtmp://a.rtmp.youtube.com/live2/x/<name> app=live2"
> 
> To disable b-frames, simply select profile=constrained-baseline or bframes=0.
> The high profile (default) results in slightly choppy experience, though it's
> not rejected, so maybe it's due to my computer CPU being too slow for the task.
> It seems that adding flashVer and the datarate parameters (as described in
> Snowmix test documentation) may cause issues.

I have tested it with 1.4.0 version you send me the Git references for.

It is correct your solution will stream with YouTube Live with the 1.4.0
modified version. Your solution will however also stream with the parameters
set by the example on the Snowmix page
https://sourceforge.net/p/snowmix/wiki/Snowmix%20and%20CDNs/ so I guess the
extra parameters may no longer be required. Either an update in the librtmp or
perhaps on the YouTube/Google side of the things.

Anyway I suspect why your solution with or without the extra parameters works
is that both streams start at t=0.

Now if you use the following two pipelines, then it does NOT work with the
modified flvmux. The stream is accepted at YouTube as 'Good', but you never can
get to see the Preview nor actual start a Live session. This both applies if
bframes are present and bframes not present. I suspect this is a issue with
starting values of DTS and PTS.

The pipelines are:

The producer:

gst-launch-1.0 videotestsrc is-live=1 !\
    video/x-raw,width=1280,height=720,framerate=24/1 !\
    timeoverlay !\
    x264enc bitrate=4000 !\
    video/x-h264,profile=main !\
    queue !\
    mux. audiotestsrc is-live=1 wave=0 !\
    audio/x-raw,channels=2 !\
    faac !\
    queue !\
    mux. matroskamux name=mux streamable=true !\
    queue !\
    tcpserversink host=0.0.0.0 port=5010 sync-method=2 recover-policy=keyframe

The sender:

gst-launch-1.0 -v tcpclientsrc host=127.0.0.1 port=5010 do-timestamp=true !\
    queue !\
    matroskademux name=demuxer !\
    queue !\
    aacparse !\
    muxer. demuxer. !\
    queue !\
    h264parse !\
    flvmux name=muxer streamable=true !\
    queue !\
    rtmpsink location="rtmp://a.rtmp.youtube.com/live2/x/<YOUR_AUTH> app=live2"

It should be noted that IT DOES WORK with GStreamer 1.4.0 WITHOUT the modified
flvmux (ie. the old flvmux) as long as no bframes are present.

So I would say that the status = RESOLVED/FIXED is a little bit overstated.

If you have any questions, feel free to contact me directly or through here.

Is the modified flvmux I use was downloaded, compiled and installed using your
instructions being:

   git clone git://git.collabora.co.uk/git/user/nicolas/gst-plugins-good.git
   git checkout flv-ts-fix-1.4

Is this still the version I should be testing?
If I get Gitmaster, which I guess is 1.5.0, is it then the new not working
flvmux code or is it the old that works with non bframes streams?

Best regards
Peter Maersk-Moller

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.


More information about the gstreamer-bugs mailing list