[Bug 758384] dashdemux: tests: refactor into adaptive_engine components

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Tue Nov 24 10:07:33 PST 2015


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

--- Comment #12 from Florin Apostol <florin.apostol at oregan.net> ---
(In reply to Florin Apostol from comment #11)
> (In reply to Thiago Sousa Santos from comment #9)
> > Review of attachment 315946 [details] [review] [review]:
> > 
> > ::: tests/check/elements/adaptive_demux_common.c
> > @@ +171,3 @@
> > +  if (testOutputStreamData->expected_data) {
> > +    gsize size = gst_buffer_get_size (buffer);
> > +    fail_unless ((streamOffset + size) <=
> > testOutputStreamData->expected_size);
> > 
> > Not sure I understand this.
> > 
> > What happens if you would seek to byte=100 and was only expecting to receive
> > 10 bytes after it.
> > 
> > What would expected_size contain in this case and how streamOffset + size
> > can be smaller than the expected size?
> 
> The seek function currently seeks only at the beginning of the file. The
> seek test waits for some data to be sent, then generates a seek to the
> beginning of the file. 
> The seek request will make adaptive demux push a new segment event
> downstream. The test detects it and in on_demuxReceivesEvent function adds
> stream->segment_received_size to total_received_size and resets
> segment_received_size to 0. It also sets segment_start to segment->start, so
> I think seeks to the middle of the file will also work OK. I did not test
> them yet.
> 
> expected_size is the size of expected_buffer (which is defined and filled by
> the test). Only hls tests are using expected_buffer. The dash tests use a
> pattern for the generated data in order to check that the correct data is
> received.
> 
> expected_size might be a confusing name (you thought is the number of bytes
> we expect to receive, but it's not. It's the size of expected_data buffer).
> 
> The fail_if is an assert so that memcmp below will not make an illegal
> memory access. The test needs to define an expected_buffer big enough to
> contain the data corresponding to all the positions that could be played.
> For example, if you want to play the first 10s and then seek forward to
> position 1 minute, I think the expected buffer should contain the data for
> the whole minute, even if some of it will not be checked.


Disregard the above comment, its wrong. 
expected_size is indeed the size expected to be received.

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


More information about the gstreamer-bugs mailing list