1. 05 Jun, 2019 2 commits
    • Mart Raudsepp's avatar
      qtdemux: Provide a 2 frames lead-in for audio decoders · cbfa4531
      Mart Raudsepp authored
      AAC and various other audio codecs need a couple frames of lead-in to
      decode it properly. The parser elements like aacparse take care of it
      via gst_base_parse_set_frame_rate, but when inside a container, the
      demuxer is doing the seek segment handling and never gives lead-in
      data downstream.
      Handle this similar to going back to a keyframe with video, in the
      same place. Without a lead-in, the start of the segment is silence,
      when it shouldn't, which becomes especially evident in NLE use cases.
      cbfa4531
    • Mart Raudsepp's avatar
      qtdemux: remove indent exception and reindent · 9b348e75
      Mart Raudsepp authored
      As the indent disabling isn't playing along for a following fix,
      remove the indent disabling and reindent in a way that doesn't
      look too stupid.
      9b348e75
  2. 03 Jun, 2019 1 commit
  3. 25 May, 2019 1 commit
  4. 13 May, 2019 3 commits
  5. 19 Mar, 2019 1 commit
    • Seungha Yang's avatar
      qtdemux: Don't pass zero to denominator for framerate · 63bb1e3a
      Seungha Yang authored
      Need to respect return of gst_video_guess_framerate() to ensure
      non-zero denominator.
      
      This patch is to fix below error with an abnormal (but has valid frame) file.
      (gst-play-1.0:17940): GStreamer-CRITICAL **: passed '0' as denominator for `GstFraction'
      63bb1e3a
  6. 15 Mar, 2019 1 commit
    • Charlie Turner's avatar
      qtdemux: Find mp4a esds atoms in protected streams sample description tables. · 39d32b23
      Charlie Turner authored
      This problem was found in Test. 2 of the YouTube 2018 EME
      tests[1]. The code was accidentally not finding an mp4a's esds atom in
      the sample description table when the stream was encrypted. It assumed
      that if the stream is protected, then only an enca atom will be found
      here. What happens with YouTube is they often provide protected
      content with a few seconds of clear content, and then switch to the
      encrypted stream.
      
      The failure case here was an incorrect codec_data field being sent
      into aacparse. The advertisement of stereo audio @ 44.1kHz for the
      mp4a (unprotected) stream was incorrect. As usual, the esds contained
      the real values here which were mono at 22050 Hz.
      
      Here's what the MP4 tree looks like for these types of files,
      demonstrating why the code was making a wrong assumption (or maybe
      YouTube is being unusual),
      
      [ftyp] size=8+16
      ...
      [moov] size=8+1571
      ...
        [trak] size=8+559
      ...
                [stsd] size=12+234
                  entry-count = 2
                  [enca] size=8+147
                    channel_count = 2
                    sample_size = 16
                    sample_rate = 44100
                    [esds] size=12+27
                      ...
                  ...
                  [mp4a] size=8+67
                    channel_count = 2
                    sample_size = 16
                    sample_rate = 44100
                    [esds] size=12+27
                      ...
      
      In addition to fixing this, the checks for esds atoms in mp4a and mp4v
      have been made symmetrical. While I haven't seen a test case for video
      with the same problem, it seemed better to make the same checks. This
      also fixes a crash reported from another user[2], they also noted the
      asymmetry with mp4v and mp4a.
      
      [1] https://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/2018.html?test_type=encryptedmedia-test
      [2] #398
      39d32b23
  7. 08 Feb, 2019 1 commit
  8. 05 Feb, 2019 1 commit
  9. 02 Jan, 2019 3 commits
  10. 22 Dec, 2018 1 commit
  11. 15 Dec, 2018 1 commit
  12. 06 Dec, 2018 2 commits
  13. 30 Nov, 2018 2 commits
    • Alicia Boya García's avatar
      qtdemux: set need_segment after a second moov · 38b553dd
      Alicia Boya García authored
      stream.segment should be updated with the values of the current edit
      list, also when a new `moov` is received. Unfortunately this was not
      being the case because of an early return.
      
      As a consequence of this bugs, no end of movie clipping was being
      performed on the new moov and no segment event was being emitted.
      
      When performing stream switching (e.g. in MSE) the new moov may have a
      different edit list. This is often the case when switching between
      baseline H.264 (which lacks B-frames) and more demanding profiles. For
      this reason it's important to emit a new segment in order to be able
      to get matching stream times.
      38b553dd
    • Alicia Boya García's avatar
      qtdemux: Initialize QtDemuxStream.segment in its constructor · 26cc201c
      Alicia Boya García authored
      This patch moves the initialization of QtDemuxStream.segment from
      gst_qtdemux_add_stream() to _create_stream(). This ensures the segment
      is always initialized when the stream is created.
      
      Otherwise the segment format is left as GST_FORMAT_UNDEFINED in the case
      were a track is reparsed and qtdemux_reuse_and_configure_stream() is
      called instead of gst_qtdemux_add_stream(). (See
      qtdemux_expose_streams() in the non streams-aware case.)
      26cc201c
  14. 07 Nov, 2018 1 commit
  15. 01 Nov, 2018 1 commit
  16. 27 Oct, 2018 1 commit
    • Alicia Boya García's avatar
      qtmux: round to nearest when computing mehd and tkhd duration · 5fcb7f71
      Alicia Boya García authored
      This fixes a bug where in some files mehd.fragment_duration is one unit
      less than the actual duration of the fragmented movie, as explained below:
      
      mehd.fragment_duration is computed by scaling the end timestamp of
      the last frame of the movie in (in nanoseconds) by the movie timescale.
      
      In some situations, the end timestamp is innacurate due to lossy conversion to
      fixed point required by GstBuffer upstream.
      
      Take for instance a movie with 3 frames at exactly 3 fps.
      
      $ gst-launch-1.0 -v videotestsrc num-buffers=3 \
        ! video/x-raw, framerate="(fraction)3/1" \
        ! x264enc \
        ! fakesink silent=false
      
      dts: 999:59:59.333333334,  pts: 1000:00:00.000000000, duration: 0:00:00.333333333
      dts: 999:59:59.666666667,  pts: 1000:00:00.666666666, duration: 0:00:00.333333334
      dts: 1000:00:00.000000000, pts: 1000:00:00.333333333, duration: 0:00:00.333333333
      
      The end timestamp is calculated by qtmux in this way:
      
      end timestamp = last frame DTS + last frame DUR - first frame DTS =
        = 1000:00:00.000000000 + 0:00:00.333333333 - 999:59:59.333333334 =
        = 0:00:00.999999999
      
      qtmux needs to round this timestamp to the declared movie timescale, which can
      ameliorate this distortion, but it's important that round-neareast is used;
      otherwise it would backfire badly.
      
      Take for example a movie with a timescale of 30 units/s.
      
      0.999999999 s * 30 units/s = 29.999999970 units
      
      A round-floor (as it was done before this patch) would set fragment_duration to
      29 units, amplifying the original distorsion from 1 nanosecond up to 33
      milliseconds less than the correct value. The greatest distortion would occur
      in the case where timescale = framerate, where an entire frame duration would
      be subtracted.
      
      Also, rounding is added to tkhd duration computation too, which
      potentially has the same problem.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=793959
      5fcb7f71
  17. 22 Oct, 2018 2 commits
  18. 20 Oct, 2018 1 commit
  19. 19 Oct, 2018 5 commits
  20. 17 Oct, 2018 1 commit
  21. 16 Oct, 2018 1 commit
  22. 25 Sep, 2018 1 commit
  23. 24 Sep, 2018 1 commit
  24. 20 Sep, 2018 1 commit
  25. 18 Sep, 2018 1 commit
  26. 13 Sep, 2018 1 commit
    • Vivia Nikolaidou's avatar
      qtmux: Allow up to 1 trak timescale unit of lateness in prefill mode · 94f86034
      Vivia Nikolaidou authored
      For 59.94 FPS, it's common to set 60000 as timescale. For that
      timescale, if the audio is late by as little as 0:00:00.000016666
      (definitely less than one audio sample), lateness gets rounded to 1.
      Added a safeguard that allows lateness up to 1 sample with the specific
      trak's timescale, to make sure that values less than e.g. one audio
      sample won't break the prefill mode. What will happen in this case is
      that the audio will get squeezed back to the video's timestamp, which in
      practice means that the audio will be 0.000016666 seconds early (with
      the patch).
      
      https://bugzilla.gnome.org/show_bug.cgi?id=797133
      94f86034
  27. 06 Sep, 2018 1 commit
  28. 03 Sep, 2018 1 commit