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

Thu Aug 28 11:48:07 PDT 2014

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

--- Comment #13 from Nicolas Dufresne <nicolas.dufresne at collabora.co.uk> 2014-08-28 18:48:00 UTC ---
(In reply to comment #12)
> 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 can't really work on 1.4 without also patching gst-plugins-ugly. flv
specific timestamp as dts and positive offset toward pts. x264enc was shifting
only the dts to make it positive, which would break the value for the offset.

As said, if you only have the two patch I suggested on top of 1.4 it will
likely not work. See patch 698714fc9781c614ea5d65744508d5db73f16066 from
gst-plugins-ugly. Along with the 4 patches in the bug report. To be on the same
page, I would recommend you to test on git master, these changes won't be
backported to 1.4 anyway.

> 
> 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.

I must admit I didn't test with re-adding these parameters (which are flash
specific, so if they are not needed, I just prefer not setting them), so indeed
it's likely working both ways now due to update on Google server side. 

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

No, that was my mistake. It's fixed now. Timestamp starts at 0 (first package
is header and has pts = dts = cts = 0). Then first stream packet is offset to
zero (in running time), and all following packet are offset from the first
packet timestamp. All timestamp where converted to stream-time before end, so
they correlate together and can be offset this way. This is to respect the
spec, unless the spec is proven wrong. If the spec was wrong, there is more
changes needed to get initial header timestamp right. 

> 
> 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.

I confirm this does not work for me either. I'll file a separate bug to address
this. It would seem that the dts is lost along the way in the matroskamux !
matroskademux. I'll re-add support for missing DTS of course (will use PTS as
DTS), but that will leave b-frames broken. Something is wrong in matroska. 

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

Well the bug report is about generating invalid flv stream in presence of
b-frames. There is good reason to achieve this work in development branch, and
good reason I'm not going to backport to 1.4. Thanks for reporting, I'll open
corresponding issues for matroska stipping off dts values.

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