Record to file h264 + aac in mp4 produce only partially playable file.

Thiago Santos thiagoss at osg.samsung.com
Mon Apr 13 20:24:20 PDT 2015


On 04/13/2015 12:54 PM, KPAXIT wrote:
> Hi list,
>
> I'm using following pipeline to record in file:
>
> gst-launch-1.0 -e --gst-debug=**:4 videotestsrc is-live=true \
> ! queue ! videoconvert \
> ! videorate silent=false \
> ! videoscale \
> ! "video/x-raw, width=1280, height=720, framerate=25/1" \
> ! queue ! x264enc speed-preset=3 tune=zerolatency bitrate=3800 key-int-max=0
> \
> ! queue ! muxer.video_0 \
> audiotestsrc is-live=true \
> ! audioconvert ! audioresample ! audiorate ! "audio/x-raw, rate=48000,
> channels=2" \
> ! queue ! faac bitrate=128000 rate-control=2 \
> ! queue ! muxer.audio_0 \
> mp4mux name=muxer streamable=true \
> ! queue ! filesink location="/home/myenc/mystream.mp4" sync=false
>
> *Q/Problem:*
> It seems that there are no problems with given pipeline if we run it for
> short session e.a. ~1-2 hour(s) or so.
> But when we run it a bit longer (4-10h), recording file get broken somewhere
> around ~4GB in file (equals to physical RAM!?)
> For example: if we capture 360p 1Mbit then file is playable until 4 hours
> and if we capture in 720p 4Mbit then file is playable until 1 hour in file.
>
> Did anyone experienced same issue or maybe somebody can reproduce it?
> Is this a normal behavior of qt/mp4mux like  'ensonic' mentioned here for
> example?
> Is there a workaround for it?
>
> After a lot of testing I made a hypothesis that it has something to do with
> physical memory and how mp4mux works.
> However putting and/or removing extra RAM from machine did not had any
> affect on broken files(still only playable until 4GB)
>
> Any suggestion, example, point to right direction would be very much
> appreciated.
>
>
> *Please note:*
> * the only playable recording file after 4GB I was able to generate, is when
> we DO NOT use any muxer at all (aka byte-stream=true filename.h264)
> * or we use mpegtsmux, which doesn't make use of index tables in memory (?)
> * Because theora+vorbis+oggmux produced same broken result as h264+mp4 did,
> it sounds like a general muxer issue and not only mp4mux/qtmux, but that is
> only a guess.
>
>
> OS: Ubuntu 14.04
> Gstreamer: 1.4.5 (also tested with 1.3.90)
> Proc: i5-3570 @ 3.4Ghz
> Ram: 4GB (also tested with 2GB, 8GB)
Could you try with git master? There were some fixes regarding 32/64 bit 
variables in some places in qtmux/mp4mux. I just recorded a 3h / 5.2gb 
file and it seems to play fine here.

I think this bug was already fixed.

>
>
>
> --
> View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Record-to-file-h264-aac-in-mp4-produce-only-partially-playable-file-tp4671554.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


-- 
Thiago Sousa Santos
Senior Multimedia Engineer, Open Source Group
Samsung Research America - Silicon Valley



More information about the gstreamer-devel mailing list