Closed ReubenM closed 7 years ago
Looking at ffmpeg's output, it uses the frame rate as the timescale, so for the 30000/1001 scan rate video (with 48k audio) it generates the following:
Video: Representation frameRate="30000/1001" SegmentTemplate timescale="30000"
Audio: Representation audioSamplingRate="48000" SegmentTemplate timescale="48000"
The timescale written by nginx-rtmp is always with a timescale a 1000. It was not relative to my fork. I suggest you to open an issue to the serguei github. btw : I ve use dashjs and have some issues too with timing operations...
Well I figured out the framerate part: In ngx_rtmp_dash_module.c the "case 29970:" was not evaluating to true because it was 29969. Fixed that.
I wasn't aware the timescale was hardcoded. For some reasons I thought I it had output something different in the past. Guess it does help to actually read the code. Sorry to pester you.
I patched ffmpeg to output valid dynamic dash, and the time/duration numbers in dash.js play nice with it. With the nginx-rtmp-dash, I would get weird numbers that were out of range of what it should have been, as well as the occasional NAN.
OK thanks for the info. If you read the code you will note that all timescale is hardcode to 1000. This is bad; but work for most case.
I've been testing this and I have a 30000/1001 scan rate stream where the rate is being written with a 1000 frame base:
frameRate="29969/1000" timescale="1000"
I'm trying to figure out why player.time() in dash.js does not match the actual time of the video. Doing a player.seek( 0 ) seems to have dash.js loose it's marbles as to where it is at, and I was wondering if the timescale at 1000 rather than 1001 might contribute to that.