I'm using GPAC rev4989 with patch for aac encoding (https://sourceforge.net/p/gpac/discussion/287547/thread/0c6a9e71/#87a0), ffmpeg 2.1.2 on a Linux Mageia 3.
Francesc
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
More info about this issue.
At certain point (usually different from run to run), it seems that
no more frames are decoded, and the threads of video encoding keep
encoding the same frame:
... [DashCast] Video Frame TS 154624 decoded at UTC 1390392163850 ms [DashCast] Video v1 Frame TS 154624 encoded at UTC 1390392163852 ms [DashCast] Video v2 Frame TS 154624 encoded at UTC 1390392163853 ms
[DashCast] Video Frame TS 155136 decoded at UTC 1390392163892 ms [DashCast] Video v1 Frame TS 155136 encoded at UTC 1390392163894 ms [DashCast] Video v2 Frame TS 155136 encoded at UTC 1390392163896 ms
[DashCast] Video Frame TS 155648 decoded at UTC 1390392163933 ms [DashCast] Video v1 Frame TS 155648 encoded at UTC 1390392163935 ms [DashCast] Video v2 Frame TS 155648 encoded at UTC 1390392163936 ms
[DashCast] Video Frame TS 156160 decoded at UTC 1390392163975 ms [DashCast] Video v1 Frame TS 156160 encoded at UTC 1390392163977 ms [DashCast] Video v2 Frame TS 156160 encoded at UTC 1390392163978 ms
[DashCast] Video Frame TS 156672 decoded at UTC 1390392164017 ms [DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164018 ms [DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164019 ms [DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164021 ms [DashCast] Video v2 Frame TS 156672 encoded at UTC 1390392164021 ms [DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164022 ms [DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164023 ms [DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164024 ms [DashCast] Video v2 Frame TS 156672 encoded at UTC 1390392164025 ms [DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164026 ms [DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164027 ms [DashCast] Video v2 Frame TS 156672 encoded at UTC 1390392164027 ms [DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164028 ms [DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164029 ms [DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164029 ms [DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164030 ms [DashCast] Video v2 Frame TS 156672 encoded at UTC 1390392164030 ms [DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164030 ms [DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164031 ms
...
I'm using GPAC svn rev 5000 with aac patch and ffmpeg 2.1.2.
Francesc
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I think the issue comes from a lack of CPU power.
With a slower computer (Genuine Intel(R) CPU T2400 @ 1.83GHz, 2 cores),
the problem of "[dashcast] Live system dropped a video frame" can appear even with one representation, if the CPU achieves 100%.
Hi,
When running DashCast with only one representation in conf file, the result is ok:
DashCast -av sintel/sintel-1024-stereo.mp4 -live-media -seg-dur 10000 -time-shift -1 -dynamic-ast -conf dashcast_aac.conf -ast-offset 5000
dashcast_aac.conf:
[v1]
type=video
bitrate=400000
framerate=25
width=640
height=480
crop_x=0
crop_y=0
codec=libx264
[a1]
type=audio
bitrate=192000
samplerate=48000
channels=2
codec=aac
However, when trying to use it with two different representatations:
DashCast -av sintel/sintel-1024-stereo.mp4 -live-media -seg-dur 10000 -time-shift -1 -dynamic-ast -conf dashcast_aac_2r.conf -ast-offset 5000
dashcast_aac_2r.conf:
[v1]
type=video
bitrate=400000
framerate=25
width=320
height=240
crop_x=0
crop_y=0
codec=libx264
[a1]
type=audio
bitrate=192000
samplerate=48000
channels=2
codec=aac
[v2]
type=video
bitrate=400000
framerate=25
width=640
height=480
crop_x=0
crop_y=0
codec=libx264
[a2]
type=audio
bitrate=192000
samplerate=48000
channels=2
codec=aac
I get a lot of warnings:
[dashcast] Live system dropped a video frame
[dashcast] Live system dropped a video frame
...
and video segments are not created.
But if I use a conf file with exactly the same size for both video representations:
[v1]
type=video
bitrate=400000
framerate=25
width=640
height=480
crop_x=0
crop_y=0
codec=libx264
[a1]
type=audio
bitrate=192000
samplerate=48000
channels=2
codec=aac
[v2]
type=video
bitrate=400000
framerate=25
width=640
height=480
crop_x=0
crop_y=0
codec=libx264
[a2]
type=audio
bitrate=192000
samplerate=48000
channels=2
codec=aac
it works fine.
I'm using GPAC rev4989 with patch for aac encoding (https://sourceforge.net/p/gpac/discussion/287547/thread/0c6a9e71/#87a0), ffmpeg 2.1.2 on a Linux Mageia 3.
Francesc
Hi!
Working with mp2, without the patch for aac, the problem is the same:
"Live system dropped a video frame" and then segments are not created.
dashcast_mp2_2r.conf
[v1]
type=video
bitrate=400000
framerate=25
width=320
height=240
crop_x=0
crop_y=0
codec=libx264
[a1]
type=audio
bitrate=192000
samplerate=48000
channels=2
codec=mp2
[v2]
type=video
bitrate=400000
framerate=25
width=640
height=480
crop_x=0
crop_y=0
codec=libx264
[a2]
type=audio
bitrate=192000
samplerate=48000
channels=2
codec=mp2
Francesc
Ok, I think I could reproduce. Does it go very fast at your place too?
Romain
Hi,
Yes the problem appears after few seconds.
Francesc
El dia 17/01/2014 14:38, "Romain Bouqueau" rbouqueau@users.sf.net va
escriure:
Hi,
More info about this issue.
At certain point (usually different from run to run), it seems that
no more frames are decoded, and the threads of video encoding keep
encoding the same frame:
DashCast -logs dash@info -av sintel/sintel-1024-stereo.mp4 -live-media -seg-dur 10000 -time-shift -1 -dynamic-ast -conf dashcast_aac_2r.conf -ast-offset 5000
...
[DashCast] Video Frame TS 154624 decoded at UTC 1390392163850 ms
[DashCast] Video v1 Frame TS 154624 encoded at UTC 1390392163852 ms
[DashCast] Video v2 Frame TS 154624 encoded at UTC 1390392163853 ms
[DashCast] Video Frame TS 155136 decoded at UTC 1390392163892 ms
[DashCast] Video v1 Frame TS 155136 encoded at UTC 1390392163894 ms
[DashCast] Video v2 Frame TS 155136 encoded at UTC 1390392163896 ms
[DashCast] Video Frame TS 155648 decoded at UTC 1390392163933 ms
[DashCast] Video v1 Frame TS 155648 encoded at UTC 1390392163935 ms
[DashCast] Video v2 Frame TS 155648 encoded at UTC 1390392163936 ms
[DashCast] Video Frame TS 156160 decoded at UTC 1390392163975 ms
[DashCast] Video v1 Frame TS 156160 encoded at UTC 1390392163977 ms
[DashCast] Video v2 Frame TS 156160 encoded at UTC 1390392163978 ms
[DashCast] Video Frame TS 156672 decoded at UTC 1390392164017 ms
[DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164018 ms
[DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164019 ms
[DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164021 ms
[DashCast] Video v2 Frame TS 156672 encoded at UTC 1390392164021 ms
[DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164022 ms
[DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164023 ms
[DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164024 ms
[DashCast] Video v2 Frame TS 156672 encoded at UTC 1390392164025 ms
[DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164026 ms
[DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164027 ms
[DashCast] Video v2 Frame TS 156672 encoded at UTC 1390392164027 ms
[DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164028 ms
[DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164029 ms
[DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164029 ms
[DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164030 ms
[DashCast] Video v2 Frame TS 156672 encoded at UTC 1390392164030 ms
[DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164030 ms
[DashCast] Video v1 Frame TS 156672 encoded at UTC 1390392164031 ms
...
I'm using GPAC svn rev 5000 with aac patch and ffmpeg 2.1.2.
Francesc
Hi,
I've found that this problem appears at rev 4929.
https://sourceforge.net/p/gpac/code/4929/
Francesc
Hi,
I think the issue comes from a lack of CPU power.
With a slower computer (Genuine Intel(R) CPU T2400 @ 1.83GHz, 2 cores),
the problem of "[dashcast] Live system dropped a video frame" can appear even with one representation, if the CPU achieves 100%.
I've done the following:
DashCast -logs dash@info -av sintel/sintel-1024-stereo.mp4 -live-media -seg-dur 10000 -time-shift -1 -conf dashcast_aac_24.conf -ast-offset 5000
Configuration file contains only one representation:
[v1]
type=video
bitrate=800000
framerate=24
width=512
height=218
crop_x=0
crop_y=0
codec=libx264
[a1]
type=audio
bitrate=192000
samplerate=48000
channels=2
codec=aac
Without any other CPU-consuming process, both cores are at about 50%.
Everything is fine. No dropped video frames.
When I also run MP4Client in the same computer, both cores achieve 100%, and
DashCast starts complaining about dropped frames.
Previously reported problem with two representations was observed on
an Intel i7 CPU (4 cores x 2 (hyperthreading) = 8 threads).
I'm using GPAC svn rev 5191M (with aac patch), ffmpeg 2.1.4 on a Linux
Mageia 4.
Francesc
Francesc,
Thanks for reporting the result of your investigations.
Cyril